这个是个老问题了，会检查一下有没有弄断塑料，如果没有，就原样装回去。如果有，小心的拆一个不用的键（比 print screen 或 scroll lock ）装过去，把坏的那个放那边。

用 Slate 自己写个绑定就行。它是用 JavaScript 设置的。

告诉大家一个冷知识：

土豆网 于 2005 年 4 月 15 日上线
YouTube 于 2005 年 4 月 23 日上线

时间隔这么短也不存在谁抄谁，不过土豆网确实是原创的。

如果是喜欢打篮球的话，还是送鞋好了。
至于机械键盘，我觉得喜欢的已经买了。没买可能是因为不喜欢，或者怕影响办公室的其他人吧。

没必要这么说吧，jd 本来就是红色系。

服务器上的命令行操作不记下来。

代码是用 git 管理的，但是有些服务器上的 build 命令啊、参数啊什么的，手动登录进去执行。执行完了也不记下来，如果是稍微复杂一点的命令，下次或者换个人肯定忘记。

这些东西和代码一样重要，确完全没有保存下来。我认为维护一个文档是最起码的，但文档可能会忘了更新或写错。

最好是做到命令即代码，不手动在服务器上执行任何命令，一律用 provisioning 工具并提交到专门的 git 仓库里面去。

@linkfan 做个能复现问题的假的

方便的话把网站发上来大家看看呗

或者给机械加 O 圈

@qgy18 会啊，所以要换掉。另外因为现在是纸包的聚合物电池，爆炸威力不会像铁壳包的锂离子电池那么大。

我淘宝买了个电池照着 ifixit 的步骤自己换了。

是不是扩展名被你删掉了……

需要。2 到 3 千。

代码首先要反映程序员的逻辑，怎么想就怎么写。

两种常见情景：

1 ）写到这里，哎呀这个变量如果是 b 就不对了，先 return 掉
2 ）写到这里，发现有以下两种可能的情况

显然 1 ）应该用 early return，2 ）应该用 if else

@omsfuk 如果像 React Components 一样可以带逻辑，就有其他的配置方法。是的，一个好的 UI 库肯定是要经过科学合理的设计的，就像好的代码工具库一样。

@orzzyd 对。是否应该复用不是取决于他们是不是很像，而是取决于他们是不是逻辑上是一样的东西。

这和跨项目的代码复用是一样的。如果你想写一个跨项目使用的工具库，肯定是会覆盖一些通用的功能，并提供一些配置选项。如果你要做一个跨项目使用的 UI 库，当然也是覆盖一些通用的 UI 组件，并提供一些配置选项。

@omsfuk 菜单栏可以接受 items，其中的一个 item 可以是个下拉菜单啊。