不是不能喷，但喷的点实在有问题（很多实际上是 mac 的强项），要喷还是要抓住重点：游戏性、办公 /工业软件、性价比、反人类的鼠标滚动方向之类

前端，个人，开发爽上天但无法推广到大公司的技术：

- 前后端都用 JavaScript ，一个代码仓库，代码和类型共用。
- 前端代码通过 rpc 调用（封装 http 请求）访问后端方法，后端接口类型变更可以触发前端类型错误。
- 部署用 rsync 增量传输，用 yarn 增量安装，秒级更新上线
- git 提交信息一般只写一个字母

不正规但爽

@FallenMax 说错了，新版是 yabai

https://github.com/saforem2/chunkwm

类似 i3 的平铺式窗口管理器，你值得拥有

跑

珍惜独处时光吧，前进容易，回退困难

@subpo https://github.com/microsoft/WSL/issues/4150#issuecomment-504209723

用这个用户给的 powershell 脚本，把 wsl 内指定端口转发到 windows 上

弄前端开发的，目前没太大问题，已知的几个问题可以处理或绕过

1. windows 的 vpn，在 wsl 内不生效
2. wsl 内起的服务，在局域网里无法访问
3. systemmd 不能用

有个额外加分项：wslg 上了以后，可以起 wsl 内的 chrome，跑 cypress 用例什么的

老实说不太理解：除了要翻墙，有什么理由不用 Chrome 而用 Edge ？引擎是一样的，隐私保护方面更差，还是说有别的理由？

推荐写脚本，不要依赖 webpack 专门特性

一定要自己想清楚。糊里糊涂上船，就是一种无端走入监狱的感觉。People don't think much before they are in deep shit.

补充一个角度。除了提示和补全这类便利特性外，类型系统对于解决软件工程一个重要问题--可维护性，是一个性价比极高的工具。

为什么可维护性是最重要的问题之一？关于这一点可以去看《代码大全》《 clean architecture 》之类经典著作。但从实际观察，对于这么重要的问题，反而没什么「很容易推而广之」并且「行之有效」的解决方案：懂设计 /架构 /具备好的品味的人很少（也很难遴选），设计的好坏很难像性能 /代码体积一样随时度量（圈复杂度这种真没什么用），deadline 和不负责任每天都在导致代码腐坏，堆成屎山。

对于这个问题，类型系统提供的帮助是：（强制要求用户）把更多必要信息（类型，调用，关联，一致性约束）嵌入到代码本身，从而可以被外部工具利用，也被人阅读。且不说一致性约束能被工具自动检查和维护，仅仅信息不丢失本身，就很大的提升了代码的可理解性。

至于架构，现在即便我们一开始无法为手头的问题设计一个好的「架构」，也不必特别担心。只要把足够的信息内嵌到代码中（少用 any/as ），后面从「坏架构」重构为「好架构」，从「架构 A 」重构为「架构 B 」，成本都比动态语言显著降低。

这种重构成本的降低还带来一个额外的好处：我们可以在开始时放心地使用「比较专门」的「不符合开闭原则」的设计，在实际需要时再通过重构来扩展为「比较通用」的设计。这种做法的好处有两个：1. 专门的设计针对眼前的问题，往往更简单实际 2. 没有足够的用例，就试图设计地通用，往往有「过度优化」的负面作用。

最后谈谈性价比，提升可维护性不是没有其他方式：大量的单元测试，注释，代码审查等方式我们都在用，但这些方法是否容易推行，效果是否好，相信大家各有感触。

1976f.com 正在开发的日记 app，提前借楼推广一下：

- 多端同步+端到端加密，服务端无法解读笔记内容、图片内容
- 随机好友分享，可以加好友，和特定好友分享特定笔记，但能否投递成功、耗时多久会由算法+随机决定
- 随时导出为 json
- （开发中）导入，从多种源(html/json/xml/txt)导入，并且不假定源数据格式和来源，这是野心最大的一项，目前进度 80%
- 不错的 UI

1976f.com - try this

@luckyx 已修，thx!

brew 内部用的是 git (github)，git 需要配置代理（ https/ssh): https://gist.github.com/chuyik/02d0d37a49edc162546441092efae6a1

回头看看自己发的帖，虽然这么说有点不厚道，但是：

虽然说「不敢保证长期可用」，但 notepad.1976f.com 直到现在都是可用的，与此同时，敢于保证长期可用的服务反而。。

把已有项目代码合成一个 commit：'legacy code'，force push