记得有个 陌生人 短信拦截

我尽量少写这关键词重复性的注释

另外考虑过自己实现一个插件

还有一个办法是写一个命令行工具：先过滤掉注释但是保留换行符, 能凑合用
cat code | trim-comment | ag -w Target

这问得太偏了

我这儿面 golang 主要是做 2-3 道代码实现的题。不过有 golang 经验的候选人好少，基本上 java 经验来的最多

想学 js, 用 deno 、node 甚至只用 chrome 无所谓，都差不多的
学 ts 的话，用 deno 会更方便一点

学工程化，deno 现在就几乎没有工程化配套项目，有一个项目 alphejs 框架值得学一下。
你要是能写一个或封装个更好的 deno web 框架、UI 组件库、puppeteer ，那都是极大的贡献了

@darklights 下次要是重启的话我试试

前端工程的概念很多都麻烦要死，还不通用，
webpack 什么的概念太多了，哪年就淘汰了，增加不少调试的复杂性，调试 async-wait 编译后的代码我就遇到不少断点错误的问题。

不过我想说基于 deno 的框架可能是未来 比如 https://alephjs.org/ 看起来还不错

不过现在 deno 没有任何生态可言，千万别用于生产。目前适合喜欢造轮子的把玩

@Elietio 另外按目录选 commit 命令行很方便的：

git log dir1 dir2
git log --oneline dir1 dir2
git log --since=20.days dir1 dir2; # 20 天内的

@Elietio
这样子呢：

git checkout -b mergeBC B
git merge C
git commit -am "merge B and C"; # 现在的 mergeBC 就有全部的记录，且包含所有的目录

git checkout -b mergePartialBC mergeBC
git checkout C -- <B 不想合并的目录>
git commit -am "merge partial B and C"; # 现在的 mergePartialBC 就有全部的记录，且只包含你只想合并的目录

git checkout -b restB mergePartialBC
git checkout B -- <B 不想合并的目录>
git commit -am "merge rest B" ;# 现在 restB 有全部的记录，以及 B 剩余未合并的目录

@a132811 "基本 C" -> 基于 C

把 B 的部分目录合并到 C?

考虑一下这样做吧

```
# 基本 C 创建一个分支 mergeC
git checkout mergeC C

# 把 B 的指定目录，copy 到 mergeC
git checkout B -- <path/to/(指定目录)>

# 检查一下 diff 确认一下
git diff

## 最后提交 mergeC
git commit -am 'merge: merge 部分目录'
git push origin mergeC:mergeC

```

@geist 遇到一点 error
error: TS2304 [ERROR]: Cannot find name 'ScrollToOptions'.
scrollTo?: (options?: ScrollToOptions) => void;
~~~~~~~~~~~~~~~
at https://cdn.esm.sh/v66/@geist-ui/[email protected]/esm/select/select.d.ts:6:27

terminal 有几个好像是没有的，iterm2 提供了：
1. 不能上下、垂直分屏 (split panes)
2. 不支持 iterm2 选中即复制

其它默认配置包括 ctrl+d 退出、字体、快捷键等都需要修改定制，不是开机即用

@geist alephjs/deno 没有 build 的，import anywhere ，抛弃了 webpack/rollup/babel 。
不支持 esm 还要手动转，有点麻烦

没有提供 esm 吧？
我有一个基于 alephjs 项目倒想用一下

@herozzm 将部分文字转换成图片，文字扭曲变形

话说，你怎么识别出某查查的？这个访问特征不可以作为封禁指标么？

可以，你要先熟悉一下关于 excel 的 sdk （主要是 openpyxl ），就是 @kilasuelika 给的例子那样

另外我写过一个 excel 解析、保存工具： https://github.com/ahuigo/xlparser 或许对你有帮助

@no1xsyzy 我觉得 Copilot 应该不会自取灭亡，即使灭亡了，也还会有新的更智能的工具出来，有可能会更好的解决版权问题。

关于 Review 成本：Copilot 是否明显增加 bug 产生的风险，可能影响没有想像的那么大。我更相信大部分人写的代码、复制来自 stackoverflow 的代码片段、迭代修改的代码，都是 bug 四溢的。。我个人更头疼一个项目引入大量的开源库、闭源库出现的未知 bug 、feature 支持（无论是自己还是等官方，一般都要较长的时间）

关于版权：我想起谷歌抄的那几行 API 代码，最终被判合理引用。如果参数命名相似就算抄袭，写代码就是一件充满风险的东西——如果过去看过一些开源代码，后来脑子想起来可以这么实现，不知道算侵权不？ Copilot 做的就是类似的事情。

@iConsLii 查看接口实现有哪些或实现了哪些接口
在 vscode 中不是右键 或者 F12 或者 Fn+F12 找 Go to Implementations 吗？

初步认识许可证： https://www.ruanyifeng.com/blog/2017/10/open-source-license-tutorial.html