好玩

吃的这一点，也就跟北京这个地方能比吧，你要有手艺来北京开饭馆我相信是能赚钱的。上广不缺好吃的，深不了解。其他二线城市，在吃的上都不会逊色。

37 楼基本总结完了。个人感觉除了第一第二点，其他的都还好。
1 。 04 年在武汉入学大学，哪儿哪儿都在修路盖楼。到现在还一样。（家是湖北的所以经常经过武汉）
2 。大学的时候，夏天宿舍敞开门，地上洒凉水，铺上凉席，没睡着就给热醒了。冬天只好门窗全封死，然后那味儿。。。就这样手摸一会儿鼠标还得插兜暖和以下。

string + int 为什么要等于 int ？百撕不得骑姐

还是应该仔细看评价，这也是在淘宝上生存的基本手段之一。
官方现在充值都挺方便的，在这一个购物项上，可以以后换用别的方式。

楼上的喷子们确实没必要吧。。。

怕有人瞎搞，在运行过程中，把$换了。用方法包一下，可以尽量保证方法体里的$都是 jQuery 。
所以就是：把不可控尽量变得可控。

追？不应该是 npm 学习了诸多包管理生态（包括 easy_install,pip 等）吗？

网宿

agar.io 就是用的 web socket 。单房间上万人都没啥问题。前端需要做一些向量计算。
排行榜上的这个游戏还是分房的，虽然不知道具体能容纳多少人。

PD 就够了， LOL 毫无压力，不用 bootcamp 。再需求硬件点的游戏你机器也不一定带的起来。

目前在 windows 下，用微软拼音新体验 2010 。。。其他什么乱七八糟的输入法，都不够好，所以偷懒用原生。

@Pseric 这个不错，值得一试

keepass 大家都是怎么管理数据库文件的？

列举的语言挺有帮助的，收藏。

https://developer.mozilla.org/en-US/Apps/Build/Audio_and_video_delivery/buffering_seeking_time_ranges#Seekable

不给你看 Flash 的只给你看 HTML5 的。 MDN 的这段说的并不详细，但是意思是说明白了。

还是有话说对了，不切片确实办不到缓冲控制。 Flash 办不到， HTML5 也办不到。
但是 Seek 是利用的服务器端功能（不管是哪个部分-nginx 还是 FMS 等-来实现）。

我非要撕是看在一点上：既然不懂 Flash ，甚至某些基本的不涉及 Flash 的部分都有知识疏漏，为什么要强行黑？瞎扯的部分，老老实实说，我没调查过，不就好了吗？

居然可以不戴手套手持相机拍照。我敬这妹子。。。

@AnyOfYou
纯学术讨论哈：看优酷时试一下 F12 。另外 Flash 的 API 本身就是支持文件播放时缓冲的。另外跟这个相关的是他还有一点说的不正确， Flash 的 seek 需要服务器支持不假，但是 html5 的 seek 居然不需要服务器支持？不懂怎么做到的。因为不管分片不分片两者 seek 的原理都可以一模一样。

另外 stats for nerds 假如是你设计的话，应该也不会把这个功能做成在没下载时也强行把空着的时间段统计进去吧。。。那个显示的应该是统计出来的平均码率，个人感觉不仅仅是通过计算下载数据的，也会通过测速接口判断。

@typcn
喂喂喂， Flash 不支持缓冲控制是从哪儿得来的结论，你不看优酷的吗？全文件下载播放的方式，缓冲支持得很好啊！
另外下载速度快，跟耗费更多流量看更多内容有半毛钱关系？楼主说的速度快，应该是相对它的带宽来说的吧？这么误读真的好吗？
从编码的方面来说，既然是 Google 自家的编码格式，用 Flash 写点代码解开也是分分钟的事，为什么到 Flash 这儿就一定要多花流量啦？

哥们你也是大牛加 v2 活跃用户，这种不负责任的说法，我虽然觉得自己会挨喷但是还是忍不住。

反倒是 23L 的同学用的背锅方式稍微合理一点，然而 html5 播放器在 JS 的支持下一样可以 P2P ，另外个人怀疑在果然不提醒用户的方式进行 P2P 加速应该是会被告的，所以 youtube 应该没有使用 P2P 。所以还是甩错了锅。。

写代码已转战 code 。
随手记用 st 。
atom 对这两者暂时找不到优势。