#4 楼 @linjunhalida

部分不再渲染的内容，基本都是可以直接扔到 memcache 里的内容。

CSS/JS 不会产生 HTTP HEAD 请求，因为 Expire 直接设置成无限了。直接就在浏览器缓存里了。

#36 楼 @zw963 什么叫踏实。如果不断地降低抽象层次叫踏实，那么你的确应该去学怎么提纯硅啊。这么说有问题么？

而且，ORM 那个问题和要不要学底层的东西，也没任何关系。只是说，当你想学 SQL 的时候，从 ORM 出发去学，学习曲线会更加平滑一点。

所以你们都该去用 Django ...

#35 楼 @ruchee 所以能不学就尽量不学

#33 楼 @zw963 基础是无底洞，为了学写程序先去学提纯硅？

#27 楼 @zw963 Django 里面，默认数据库表是根据 model 里的定义生成的，migration 官方推荐用 South 来做，South 会根据你 model 定义的变化，有可能就自动生成 migration 脚本了。你就观察一下生成的 SQL，就已经能把基本的 SQL 学会了。Rails 官方不知道咋想的，就是不去集成这样的功能。

#42 楼 @sunfmin 这点小 Bug 就不用再演示了吧

#23 楼 @ruchee 那你举一个比 Python 更适合折腾一般 Web 应用的语言出来。

必须反对你说的两点好处啊。

用户体验是下降而不是提升。首先，慢就是慢，不可能因为你换个呈现方式原来不能容忍的就能容忍了。其次，违背传统使用习惯。所以还是尽量限制在只有点击显示更多之类的地方使用。另外，客户端的开销可能增大了不少，毕竟现在改用 JavaScript 去更新页面了。

减少没多少带宽消耗和服务器消耗。css/js 之类的静态文件在第一次访问后就缓存在浏览器里了。

#10 楼 @ruchee

我觉得从 ORM 学习 SQL 比较靠谱。直接看 ORM 输出的 SQL，不就很快能学会了。

没有多少 Web 是单纯的 Web。事实上，对于很一般的 Web 应用，除了 Python，找不到更合适的语言了。

PHP 真的很难。我从来就没学会用 PHP 写点东西出来。

昨天演示到那里不行是因为 git-receive-pack 不知道咋回事变成 git-receive_pack 了，囧

谁留个邮箱，我直接把代码发过去

#8 楼 @lgn21st #10 楼 @ruohanc

时间？地点？ 我没笔记本演示咋办？ 有晚饭可以蹭么？

还是我来讲一下如何轻松搞定 git hosting，比如 SSH 或者 HTTPS Client Authentication 之类的？

@ruohanc 要不就明天？

底下实现类似。都是 prototype-based。无非 Python 函数必须要给个名字，scope 是 local by default，而 JavaScript 是 global by default。

后面新加的不少功能，JavaScript 是刻意和 Python 类似的，比如 http://brendaneich.com/2006/02/python-and-javascript/

你们人也不少了吧

#31 楼 @ruohanc 等有机会吧

难道需要我来分享一下如何轻松搞定 git hosting，比如 SSH 和 HTTPS Client Authentication 之类的。

我一直以为这两个 ID 是同一个人...

#8 楼 @ShiningRay CouchDB 早就已经作为一个 Apache 基金会的项目存在，创始人离开并不会导致 CouchDB 开发突然停止，你可以在 CouchDB 的 JIRA 上看到，开发还是在继续的。

个人感觉 CouchBase 和 CouchDB 定位不一样，没自己动手试过 CouchBase，这个可能只是我的偏见。

https://issues.apache.org/jira/browse/COUCHDB?report=com.atlassian.jira.plugin.system.project:roadmap-panel#selectedTab=com.atlassian.jira.plugin.system.project%3Asummary-panel

2010 年选 Django 也没啥好奇怪的。那时候，disqus 那帮人在 DjangoCon 上做了个分享，介绍了他们 scaling 的经验，他们同时也在 GitHub 上分享了他们的一些补丁以及 Django app。Disqus 的应用类型和 instagram 也没相差太远。你可以在 instagram 的架构上找到一些 disqus 的痕迹的。2011 年，Mozilla 也分享了他们 scaling 的经验，还有代码。instagram 也在 2011 年介绍了一下他们的经验。

相比 rails ...

参考 http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus http://blog.mozilla.org/webdev/2011/07/26/scaling-django-to-a-global-audience-with-playdoh/

至少从我看来，MongoDB 是首先排除掉的选择，你要考虑到 instagram 开始做的时候，即便是现在，我也更愿意选择 CouchDB，毕竟数据库还是要的，MongoDB 的功能跟常见的 RDBMS 还是太接近了。CouchDB，在运行效率和开发效率上的平衡上做得更好。permanent views 都会因为 map reduce 这样的写法，有很好的 index。当你想做的事情确定了，你可以在浏览器里，用 JavaScript 写 (有些东西用 Erlang 写不方便的话)，把逻辑实现对了之后，再改用 Erlang 写一遍，这样就好了。水平扩展也有现成方案可以用。而在 MongoDB 里，为你的查询定制索引就没那么直接了。

参考 http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

这让 1:1177 的 sqlite 情何以堪哪 http://www.sqlite.org/testing.html

其实，就一个 parent_id 就好了，查询的时候用 WITH RECURSIVE，传说还是这样效果最好

其中一个方案是 google "MPTT"

#17 楼 @huacnlee

Django View 用起来很蛋疼，得自定义很多 filter

Rails 的 View 对应到 Django 是 Template。

是的，是要定义 filter。但是你用 Rails 的时候，你也会做同样的事情，你管那叫 reopen class。

比如，你打算对代码语法高亮。

Rails

class String
    def syntax_highlight
            do_syntax_highlight self
    end
end

<%= source.syntax_highlight %> 

Django

@register.filter
@stringfilter
def syntax_highlight(value):
    return do_syntax_highlight(value)

{% source|syntax_highlight %}

ORM 不完善

是的，和 SQLAlchemy 没法比。但我相信 Rails 的 Active Record 可以更烂。

Form 需要定义一个单独的类，蛋疼

不同的表单要操作同一个 Model 的不同 Attribute。你用 mass assignment 不也要加个 role。 表单处理处于 Model 和 Controller(Rails)/View(Django) 的中间地带，无论是放在 Controller(Rails)/View(Django) 里，还是放在 Model 里，还是独立成 Form，都很碰到蛋疼的时候。

Django Admin 是个花瓶

就当是个界面更容易定制的，对 ForeignKey 理解更好的 PHPMyAdmin 用就是了。

用 screen 啊

python 和 ruby 只是选择了不同的语法，谁比谁呆板还很难说

http://stackoverflow.com/questions/1113611/what-does-ruby-have-that-python-doesnt-and-vice-versa

有人推荐 ruby-china，一进来竟然就看见这帖子，作为 Rails 黑必须来吐槽一下 Rails。

就算除掉 Python 对 Ruby 的优势 (其实 Python 的优势也就是库多样性总体来说比 Ruby 好一点)，Rails 还是不如 Django。