不用 WSL ，就直接用宿主机就好。毕竟 wsl 还是远程开发范畴，而且还有各种问题。

我个人的经验：
1 、配置好系统代理和命令行代理，代理比各种换源方便太多
2 、用 winget 装软件（虽然比较新，但不少软件都有），部分软件自己去官网下载安装
3 、调整应用设置。chrome 、vscode 的同步功能很强（插件数据不太行），jetbrain 系有同步功能但比较弱。
4 、把文件放在家目录下，这样更通用，能省不少麻烦。
5 、用坚果云或其它同步工具同步一些附加的资源文件，如果有需要，配置一个类似于 NUTSTORE_FILES 的环境变量指向对应文件夹。
6 、写一个文档，记录一下配置过程，以备不时之需。

其实上面这个步骤在其它操作系统上也差不多，windows 需要做一些对应的调整而已。

Java 。但是，你这真的有必要问吗？
写业务代码，可维护性和可拓展性，语言本身的生态，好招人，这几点就够明白了吧。
敏捷性：spring boot 一把梭快，还能快速整合其它模块。
非计算要求极高的场景：看你还提到了 asyncio 的 python 和 ts ，我估计你是想用异步来提升 io 性能。那 netty 了解下？

@Meteorite 哦哦哦，感谢。
是时候把卸掉的 java 扩展装回来了。

解决问题的方法就是把鼠标接收器放在离鼠标接收器旁边。
上面有人提了，powerplay 就是这么干的，实际上我印象中似乎你买鼠标的时候罗技好像也会送延长线来着。总之就算好的鼠标，也只能这么解决。

还有，restful 是个好的参考标准。虽然实际中设计的 api 很难完全符合 restful 标准（有个词叫“反模式”？），但在能使用 restful 的时候就应该使用。

为什么？因为每个人的设计思路都不一样，不遵照一个标准就会遇到各种牛鬼蛇神。
你今天可以抛弃 http method 不用。推而广之：
1 、url 只有一个请求路径字符串，太弱了，我要定义自己的结构，自己写请求分发器发到不同的处理方法。
2 、https 是公开的，安全性不行，我要用自己的加密方法。
3 、反正是传递信息，websocket 双向通讯，不比你 http 强

restful 能在各种 api 设计里脱颖而出，如果真的有人认为自己的接口标准能打败他，那自然更好，赶紧亮出来给大家开开眼。

先不说 restful 的事，“https 用 post 更安全”这个论点是错的。因为 https 里，信息都加密了，外部甚至连用的什么请求方法都不知道，要有问题就是加密前解密后的问题。

比较安全性必须得说清楚原因。

post 比 get 安全是真的，因为请求参数如果放在 url 里，那么浏览器的收藏功能啥的就有可能把这个 url 记录下来，而不是因为 https 传输过程的问题。而且，对于用户名密码这种场景 get 不适用，但对分享链接就很合适（比如搜索引擎，把关键字放在 url 的查询参数就很合适）。因此，对应的场景使用对应的请求方法是有道理的。

但 post 和 put 、patch 什么的，把信息放请求体里就没有这个问题。

想咨询下，vscode 的 java 扩展会生成.classpath 、.eclipse 什么的文件吗？之前项目里经常看到这些，但应该 idea 生成的

没有用过 go ，稍微尝试过 nodejs 和 python 的 web 框架。
真的不能和 java 的打，感觉楼主被喷是因为指向性太强了，干脆说“在场的各位都是垃圾”算了。

@infinityv 要推荐的话我就推荐现在的 35 克 82 键了。
布局的话，我认为 82 键应该是最好的了。全键盘太长了，每次打完字，右手去摸鼠标都得移动好长一段距离，非常的费力，而且主键盘区得往左放，要不然鼠标就得放得很右边，非常不舒服。
换了 87 键上这个问题缓解了一些，但还不够彻底。目前在用的 82 键，主键盘区就在正前方，感觉挺好。（感觉 87 键的控制键区浪费了不少空间，82 键的就是一个竖条，挺好的）
再往下缩就是垂直方向去掉 f1~f12 了，这个我不能接受，所以就选 82 的了。

至于克数，这个我觉得确实看个人喜好更多一点，有人觉得 35 轻，有人觉得 45 重，我是后一种。

目前有 4 把键盘：赛睿 Apex Pro 104 键（非静电容）、宁芝 35g87 键、燃风 45g87 键、宁芝 35g82 键（购买时间顺序）。最终选择宁芝，手感最喜欢。
说真的，网上看视频、听人描述、读评论其实都不准确，键盘体验店又没有。估摸着楼主最终还是要买几块自己来试试才知道。

@Newyorkcity 不了解 angular ，但看起来是用了跟 vue 一样的属性选择器实现的，我就按 vue 的猜了。

你写的一个组件，有类似 html 的结构和对应的 css 。它只会给你写的 html 里加上_ngcontent-fqf-c83 属性（和你的组件对应），然后给你写的 css 里加上[_ngcontent-fqf-c83]选择器，你引用的 select 组件内部的 html 里并不会有_ngcontent-fqf-c83 这个东西。

所以，你最终生成的 css 选择器应该是.specific[_ngcontent-fqf-c83] .mat-select-panel 这样的，这样既能给当前组件里面的 select 换样式，又不会影响其它地方的 select 。所以主要问题就是要告诉编译器.mat-select-panel 是子组件里面的，不需要加[_ngcontent-fqf-c83]

@Newyorkcity angular ？搜一下对应的深度选择器语法吧

单身， 衣服是我妈买的

我之前也纠结过，现在认为针对这种缩写形式，可能看成一个单词更好。
参考 Url （ Uniform Resource Locator ）、Id （ Identity ）、Http （ Hyper Text Transfer Prtcl ），虽然是缩写，但含义已经极其明确，你全大写和首字母大写都可以。
个人感觉 Dto 、Vo 、Bo 的形式比较合理。（在一定上下文环境中省略前缀后）变量就是 dto 、vo 、bo （这里要特别吐槽一下阿里的 DO ，如果全小写会变成关键字 do ，所以我用对应的 PO ），要不然变量叫 dTO 、vO 、bO ，总感觉怪怪的。
写到这里，回去看了一下自己的项目，发现目前用的是 UserVO 这种写法，一般对应的变量直接叫 vo ，如果多个 VO 同时出现，那么会写成 userVo ，感觉也挺舒服。。。

个人来说，喜欢 Linux 区分大小写的设计，但考虑收益，在重装 macos 时我选了 case-insensitive 的。
1 、大小写不敏感的设计并没有给我带来太多负面影响，因为绝大多数情况下，我都不会建两个只有大小写有差别的文件（如果不是有人提，我可能一辈子不会注意到 windows 和 macos 是大小写不敏感的，毕竟大小写不敏感不等于没有大小写）
2 、如其它人说的，macos 上 steam 等软件可能会在 Case-sensitive 的环境中出现问题，这是一个明显的减分项
3 、考虑到 macos 和 windows 默认都是大小写不敏感的，那么也就意味着其它人的电脑最有可能是大小写不敏感的，那即使我在用 Linux ，也会尽量避免分享给别人 a 和 A 这样的两个文件
4 、建立 Git 仓库时、npm init 时、设计 api 时，写 maven 的 groupId 时，一般建议使用中划线命名法，所以我大概也已经习惯了
总体来说，我个人感觉，大小写不敏感的设置不会对开发造成明显影响。调整一下你自己的命名方法可能相对来说更好、更方便，收益更佳

看了一下，感觉问题不大。
人家估计没想过要做一个 youtube 的国内版，估计只是“领导让做个网页版，咋做？抄抄 youtube 吧”这种

没坑，这么好的软件，一年才 200 多美元，续费还有优惠，简直是超值

最烂：《超能查派》，真 tm 后悔熬夜看这种 XXX

火星了。2020.1 刚出的时候就装了，更新到现在，翻译的质量已经挺好的了，不是纯机翻
总体来说，装了以后开发效率提升很大（看的懂英文，但没法快速把单词映射到意思）