这倒不是作死，这只是削减成本罢了。

以前开发 unity，是希望搞一个独特的 UI 体验来吸引桌面用户，希望重复苹果的成功。

现在 Ubuntu 桌面用户主流恐怕还是当所谓生产力工具用，
独特的 UI 体验对生产力工具来说不是刚需，
何况这些用户量根本撑不起 Ubuntu 复制苹果的梦。
连苹果的笔记本都开始往平板方向靠了。
C 家就更要战略撤退了。

楼主你既然相信数理化，就要讲道理，也要讲可读性。

比如你最后讲亚伦斯沃茨的那段，道理不通啊。难道你是希望亚伦斯沃茨从墓地里爬出来反驳一下？

这么一大篇，又涉及时代的方方面面，需要非常精心地安排、承接、过渡，才可读，
或者你拆成几篇也可以，围绕背离时代、不再年轻分几个子主题，一篇讲一个。

如果你不想讲道理，只是希望宣泄一些情绪，那还是要改。
不要说太多的事，把情绪宣泄出来就可以了，讲太多反而削弱了力度，
文笔也要打磨，现在的文字太沉闷，心里有火的人读了火气也降下去了，
更别说勾出没火的人心里的火了。
如果你实在发展不出自己的风格，可以模仿咪蒙。

jsFiddle 之类的网站很多。

@chaleaoch 网易云音乐的全局快捷键，比如 ctrl+p （播放）之类的捣的乱。去网易云音乐设置里干掉快捷键就行了。

@blankme 高中抄作业，选择题随机改几个，大题找两个上家，一样就抄，不一样的话就编一个跟他们都不一样的。只要上家靠谱的话，我这样抄出来和自己做的正确率的偏差不大，老师不会怀疑（除非他真的非常细的分析对比，但老师不会有这个闲心的）。

你的需求是免费打工还是别的什么？

如果你的需求真的是免费打工，
比如「我想体验一下给别人免费打工是什么感觉」，
那恐怕很难找到企业，
因为免费打工对企业来说并不是免费的，
企业要确保你不是来添乱的，
那么面试，协作流程的培训都需要企业出人工，
和招人的成本是一样的。

如果你是想锻炼写代码的能力，那自己写项目啊。
如果想锻炼协作的能力，也可以去参与别人的开源项目。

`String rec`和`convert`不明确。`rec` 必然是有格式的。`convert`肯定不能转换任意字符串吧。
所以 convert 实际做的是 parse 的活。

如果`rec`包含的信息比较复杂，优先考虑用 JSON、CSV 之类通用格式，而不是特定的格式。
因为要健壮，parser 肯定要处理校验，包括输出良好的报错，方便快速定位格式错误的地方。
用通用格式，可以直接用现成的 parser （别人的代码，或者是自己积累的历史代码）。

如果`rec`包含的信息非常简单，而且能保证不出现格式错误（比如 rec 本身就是通过程序生成的），
那也可以自己写 parse 函数。
但是`rec`的格式需要注明，
或者是用长变量名，比如`rec`改成`spaceSeparatedNames`，
或者是写注释。

`convert`同样写长，比如 `parseStudents`.
然后 `parseStudents` 直接返回 List 或 ArrayList
（ Arrays.asList 和 new ArrayList 返回的类型是不同的，根据需求统一到一种），
包括处理 students 为空的代码都是放到 `parseStudents` 函数里。

另外，`parseStudents`一般拒绝 null，比如用 IntelliJ 的话，参数加 @NotNull，
同理，`rec`如果没有特别的理由，也拒绝 null。

如果 IDE 不支持，写个检测 Object 是否 Null 的方法，`parseStudents` 先用这个函数检测参数，
是 null 就报错，要啰嗦一点，效果也是一样的。

@vishun 如果发送方不保存发信的话，风险略有不同。

@xixibb Cotard syndrome 患者可能认为自己已经死了、自己不存在、只是一个躯壳等等，我想他们不会喜欢被称为「 xxx 项目的**人**」的。

@Lucups 别想太多。词义扩大罢了。类似地，基友、面基的词义都扩大了。说面基可不是说可以分分钟出柜。其实兄弟的词义已经扩大过一次了，兄弟最早可是要有血缘关系的。

@F0nebula Fixed in [a577129]. Thanks.

[a577129]: https://github.com/weakish/fm163/commit/a57712931916593e9a6da67bbe492ed63410a107

@lilydjwg 换端口呢？

翻译不准确，但算不上坑。因为类型参数和泛型或者 parametric polymorphism 密切相关。

Java 类语言里的 generics，Map<K, V>，这 K 和 V 就是 type parameter.
ML 类语言里的 parametric polymorphism, 'a -> 'a，这 'a 就是 type parameter.

@booxood 不是账号的问题，所有公开 repo 的读写权限，这个权限要求不合理。当然这不是评论系统的问题，是 GitHub 自己权限设计不合理。GitHub 不能仅授权读写某个 repo 的 issue. 所以要么要不合理的权限，要么重定向到 issue 页面手动提交内容。

@tamlok 可能快递员不知道这是客气话，可能以为是表示理解他不投柜的原因。正好满肚子牢骚没人说呢，有人理解他的苦衷了，赶紧倒倒苦水，也可能顺便再解释一下「我不是不想投柜，哪怕少赚一点也行啊，一分都没有我实在不愿意投」。放地毯下则显然不负责，没什么好讨论的。体验不好换别家也很合理，至于到底是员工个人的问题也好，公司制度设计的问题也好，都不是用户要考虑的问题，毕竟这些用户都没办法改变，换别家是唯一能做的事。