#17 楼 @huacnlee 这个就怕一些 gem 里有坑。。。

#7 楼 @psvr 以前有个很老的项目 websocket-rails，每个连接都是通过 em 进行的，这两个思路是一致的，都是用 em 处理，然后将链接信息存到 redis 中。

#9 楼 @darkbaby123 深得我心 :plus1:

#6 楼 @ericguo Web 的本质，无缝和跨平台。Native 的本质就是可以方便调用系统资源的调用。Web 的 UI 体验度和速度其实都不是问题。Native 做到无缝和跨平台基本不可能。

#2 楼 @billy 是的，原生的优势就在于体验和有硬件支持性。但是用 Web 同样可以做出体验和交互极佳的 App，这样的例子非常多的。我想表达的也是，Web 慢这个问题实际可以完全解决。Native 的优势最终可能只会剩下一个问题，就是硬件优势。而这个优势我觉得将来也可以解决，这只是一个过渡期。

这也不是 comfortable zone 的问题，这些只是我的一些个人见解，肯定有人会同意，会有人反对。

:plus1:

感觉变化不大。。。

:plus1: 健身设施还是挺全的

#3 楼 @luikore

不过 coffee 的源码更新已经很少了，babel 现在还是很活跃的，es7 也是指日可待。

es6 不是挺好的么？

#3 楼 @happyming9527 rubyweekly 有一篇文章是专门介绍缓存的，写的非常好。其中一部分也是介绍到了 redis 和 memcached 的优缺点。 http://www.nateberkopec.com/2015/07/15/the-complete-guide-to-rails-caching.html?utm_source=rubyweekly&utm_medium=email#memcache-and-dalli

redis 对比 memcached memcached 缺点：

Cache values are limited to 1MB. In addition, cache keys are limited to 250 bytes.

redis 的优点：

Allows different eviction policies beyond LRU Redis allows you to select your own eviction policies, which gives you much more control over what to do when the cache store is full. For a full explanation of how to choose between these policies, check out the excellent Redis documentation.

redis 支持的数据结构类型非常丰富，而且支持多种缓存的失效策略。

Can persist to disk, allowing hot restarts Redis can write to disk, unlike Memcache. This allows Redis to write the DB to disk, restart, and then come back up after reloading the persisted DB. No more empty caches after restarting your cache store!

支持持久化操作，可以进行日志 aof 及 rdb 数据持久化到磁盘。

#5 楼 @quakewang

运动，每周二，四中午打羽毛球，下班回家每周游泳 1~2 次，周末玩玩皮划艇

运动好多啊！佩服。

@psvr 区块链 blockchain

@42thcoder 肯定要去

:plus1:

#3 楼 @xieyunzi http://dev.mysql.com/doc/refman/5.1/en/mysql-use-result.html

After invoking mysql_query() or mysql_real_query(), you must call mysql_store_result() or mysql_use_result() for every statement that successfully produces a result set (SELECT, SHOW, DESCRIBE, EXPLAIN, CHECK TABLE, and so forth). You must also call mysql_free_result() after you are done with the result set.

MySql 在的mysql_query 或mysql_real_query时候，会调用的mysql_store_result，会将结果保存到内存中。

mysql_use_result() initiates a result set retrieval but does not actually read the result set into the client like mysql_store_result() does. Instead, each row must be retrieved individually by making calls to mysql_fetch_row(). This reads the result of a query directly from the server without storing it in a temporary table or local buffer, which is somewhat faster and uses much less memory than mysql_store_result().

而mysql_use_result跳过了这步mysql_store_result，直接是mysql_fetch_row，所以会节省很多内存，也不会出现内存不足的情况。

另外一篇文章： http://marksverbiage.blogspot.com/2010/04/streaming-data-from-mysql.html

Unfortunately, this does not do streaming in most cases. Normally most client libraries (which call mysql_store_result) will read the entire result into memory, and you're just going through an already-in-memory data set. This will fail if it doesn't fit in memory. Enter mysql_use_result - if your library can use this instead of mysql_store_result, you can then skip through the records without needing to keep them all in ram at once.

:plus1:

如果一个人在 2000 年 2 月 29 日出生，到了 2001 年 2 月 28 日，算几岁几月几天？

图片可以更新了

罕见啊，我也是庄里的。

@pynix 哈哈 @msg7086 不是你一个人，哈哈。

#44 楼 @rasefon

比起静态语言，写的时候很开心，重构起来就直接等死了。 会么？你直接一锤子否定了 Rails，从你这句话推断而来，过去 Rails 火也是不合理的。

#1 楼 @chiangdi 这个不是模拟。ES6 的很多语法糖只是更直观表达代码含义，实现上仍然采用原型继承的方式。

#32 楼 @blackanger 视频也看过了，多线程的处理也是很难的，完全解决会是个漫长的过程。不过就语言发展来看，近几年来 Ruby 更新速度还是非常乐观的。

#8 楼 @rei 惭愧，一直不知道 :plus1:

https://ruby-china.org/topics/27492

Points 1 and 2 are unarguably correct. Rails isn't hot any more and is not evolving at the pace it used to be. But this isn't a bad thing. It's a sign that Rails has matured, it's now an adult framework and not the spotty teenager who grows taller by an inch every month.

http://www.bootstrap.me.uk/bootstrapped-blog/why-you-should-use-rails-for-your-new-company

文章后面的讨论更有意思些。

Paweł Nowak9

I think you are agreeing with Jared even if you don't know it. The main point in Jared's blog post is that being a hotness, being the first, was everything that Rails had going for it. The performance issues always existed with Ruby, the architectural issues in Rails have been extensively discussed for years at this point. The only thing that kept Rails ahead of everyone else was the fact there was nothing quite like it, it was literally years ahead of everything else. However, times are changing. There are many alternatives out there as good as Rails, others innovating more than Rails, and many of them in better VMs and runtimes than Ruby (disclaimer: I don't consider Node.JS better than Ruby). Seriously, in the last 10 years, things changed dramatically, from the number of CPUs to web development itself. Ruby is horribly delayed in the concurrency game. Rails is playing catch up with Action Cable, APIs, ES6 and others when compared to alternatives in Clojure, Go and Elixir, like Phoenix. So when you agree Rails is becoming stable, you are agreeing that Rails lost its main competitive advantage. At this point, you should be considering and evaluating other alternatives. It doesn't mean you'll necessarily replace Rails, but for your own sake, you should be looking at them.

Fred Heath

Hi Pawel. Yes, there are many alternatives out there as good as Rails, or may be even better. But Jared's first argument is that we should switch because these frameworks have more rising mind-share and will cover our needs better in 3 years time. My argument is that if you're a start-up and you worry about which tech you should be using 3 years down the line then you're either extremely confident or extremely naive and neither is a good thing. Rails is a proven start-up bootstrapper and until something comes that blows it out of the water, switching would be an un-necessary risk. Jared's second argument is that we should switch because Ruby is slow. I have hopefully shown that this is largely irrelevant. In most Rails apps I've worked on, latency is 90% of the time caused by some db transaction or some external service call, not by Ruby itself. If you need something like parallel processing of massive data sets then you wouldn't be using Rails in the first place, so I find this to be a moot point. Same with concurrency. I am very familiar with concurrency and its issues, but since I've been using Ruby I never had to worry about it because I didn't need to. For web apps I let the web/app server stress about it. For non-web apps I get by with forking processes and avoiding shared resources or using Redis or a queue. It's seriously never been an issue. For the record, I am evaluating other alternatives, namely Elixir and Phoenix. But these are a complement to Rails, not a replacement. Rails will be my default choice for building something quickly, unless there is a specific need for elixir's performance. YAGNI.

Why is ruby so slow? Some people will point to language design characteristics, which are part of the story, but I think the deeper reason is that ruby does not have a serious corporate sponsor.

martini 好像也没怎么维护了

#1 楼 @hulajesus

git checkout <commit> <file> 

是暂存区吧？你用git diff看下就知道了。只有用git diff --cached能看到暂存区的内容。

git checkout HEAD file 同时也会清空暂存区

是的。

想去，+1

#20 楼 @msg7086 嗯，如果这样应该还是一个很不错的选择。 以前公司用过也是一个第三方的 gem 还有就是同事自己写的一些唯一序列号生成规则，出了好多问题，说出来都是泪。