取决于自己，取决于项目，取决于公司。
如果项目有意义，我是无所谓的，反正我平时没事也是写代码玩。
如果项目就是毫无意义的重复劳动，加班纯粹是因为公司管理、决策混乱导致的，就算给加班费我也不会在这种地方待。

这并不难，从你的好友关系+IP数据就能推算出来，就跟当年QQ某个版本自动分组一样。
比如可以了解一下HMM（Hidden Markov Model），众多方法之中比较基础的一种。

不是有没有可能的问题，你以为墙会没有这个功能么。墙连关键字过滤都做了，白名单有多难，也就一个配置选项分分钟搞定的事情。
就算没有墙，关闭海外出口，然后国内机房物理切断，搞定。

发生突发事件第一件事情就是断网，TG才不会傻到重蹈某些国家被SNS颠覆的覆辙。
这事已经发生过，参见某个帖子，关于新疆当年被断网，然后有限恢复白名单的过程。

Git的pack策略：

<gitster> The quote from the above linus should be rewritten a
bit (wait for it):
- first sort by type. Different objects never delta with
each other.
- then sort by filename/dirname. hash of the basename
occupies the top BITS_PER_INT-DIR_BITS bits, and bottom
DIR_BITS are for the hash of leading path elements.
- then if we are doing "thin" pack, the objects we are _not_
going to pack but we know about are sorted earlier than
other objects.
- and finally sort by size, larger to smaller.

<gitster> That's the sort order. What this means is:
- we do not delta different object types.
- we prefer to delta the objects with the same full path, but
allow files with the same name from different directories.
- we always prefer to delta against objects we are not going
to send, if there are some.
- we prefer to delta against larger objects, so that we have
lots of removals.

The penultimate rule is for "thin" packs. It is used when
the other side is known to have such objects.

@yxz00 压缩后文件大小只是一方面，还有一个很重要的点就是存取效率、传输效率。
一堆分离的delta小文件，比起良好的pack成一坨的大文件，IO pattern要差得多
Git pack的算法专门就有策略保证pack出来的文件locality良好。

另外一点就是传输的时候，Git可以先双方协商，看对方缺什么文件，有什么文件，然后总是在对方已有文件的基础上，寻找最优的pack策略，在有的时候就能获得比全局diff更低的带宽占用。

@dogfeet 所以我能用Coffee就用Coffee，虽然只是用语法糖解决了问题，但的确省了不少事。
有说法就是JS是Web界的汇编语言，直接用JS找虐，不如用编译到JS的语言。

@generic

git的底层(plumbing layer)*接口*处理的单位是整个文件（以及整个目录树等等），这并不意味着底层*实现*直接在磁盘上存快照而不使用delta压缩。
--------------------------------------------------------------------

底层实现的确是直接在磁盘上存快照，pack不是必须，并且总是离线发生。而存blob总会立即发生，并且总是先于pack发生。在任何情况下，git总是会先**直接**存储两份物理意义上的文件。

物理文件和概念文件是否一一对应并不值得纠结，就好比讨论Linux文件系统的文件时，你不会纠结inode在哪个扇区、是否和文件一一对应。

真正决定Git本质的，就是概念上的存文件快照而不存差异。

Git唯一会计算差异的地方就是pack，关于pack算法，参见：
https://github.com/git/git/blob/master/Documentation/technical/pack-heuristics.txt

要真正理解的话，了解一下Git内部实现，并且亲自从Git最底层的命令撸一次常见命令：
http://git-scm.com/book/en/Git-Internals

简单的说，Git把文件的每一个版本存储为blob文件，并不做diff，只有在pack的时候，才会有算法按一定的策略计算delta。

说明新人多了。
随便有点经验的开发者都知道，语言这种东西，也就几小时能学会的，争论无益，纠结无益。
内功强大才是王道，谁关心穿什么衣服出去打架。

因为电子产品毫无新鲜感了，不就是触屏么，不就是智能么，几年没变过的东西，早就审美疲劳了。
只要再出一个革命性的电子产品，热情自然就点燃了。

其实进来就是为了看看有多少人无脑跟风唱衰node。
知道有坑绕过去，觉得不适用就换别的，多简单的道理。
No silver bullet.

个人痛恨callback，但转念一想，node用了js这种入门门槛低的语言，callback的坑恰好能过滤掉一堆低质量开发者。

语言有什么好纠结的，任何语言花一小时看看文档就能拿来开发了。
数据结构算法，体系结构，图形学，编译原理，计算机网络，数据库，这些内功才是最重要的。

看定位，除非专业瞄准小白用户，除非是一字拼音，除非是很火的亚文化词汇（比如jiong，meng），拼音总是摆脱不了low b的身份。

一旦不发帖顶贴去各种论坛社交网站宣传，或者一旦没有打折活动，就买的人很少。
----------------------------------------
你总得等买了的人先吃完吧？

lz就是太心急了，正如前面说的，酱牛肉不是刚需，必然是慢热的。
任何非成瘾性的商品都不可能100%回头客，回头客二次购买也不是立即发生。
至于推广的转化率不可能100%，这个就更不用说了。
短期推广的半衰期本来就很短，活动结束立即冷却是正常现象。
长期推广的就是为了混个眼熟，而不是立即转化。
能一次营销到位的，是少之又少的个例，往往是可以复制，但不能粘贴的模式，不要把希望寄托在这上面。

比如到现在我都没去看过lz的酱牛肉店，但印象是有了。除非v2有第二个做酱牛肉的，什么时候我想起要吃了，必然回去看看，什么时候哪个朋友聊到酱牛肉了，我必然会提起lz转行卖牛肉的“奇葩”，具体是几天后还是几年后没有保证。

Commit前review是必须的，我个人经常用pre-commit hook执行build和test，测试不通过直接就不能commit。

静音耳塞对低频噪声没用，因为那货是可以骨骼传导的。
我都是把耳塞中间挖个洞，入耳式耳机取掉原有的罩子，然后塞进去。

@alcarinque 眼抖看错，=_=