@9hills Um... 我去调查一下。因为我浏览器默认是翻墙的，所以没遇到这个问题。感谢反馈。 //bow

@9hills 估计是cloudflare受干扰的原因。你是用的Chrome插件还是Userscript？应该是异步加载不影响GitHub才对。

@tini9 你说的有道理，所以不能乱用封装，把所有东西都揉在一起。

但是django以及django的第三方库解决的一个核心问题是快速开发。把各种功能封装成一个个独立的app，然后开发者只需要根据自己的需要来使用是django的开发模式。那如何解决在app当中实现业务逻辑，在项目中根据需要来设置以及重载是django作为一个框架需要解决的问题。而class based view则是解决这个问题的一个办法。

另外 @yueyoum 提到的signal解耦也是为了app的复用，独立app是不可能知道使用它的项目环境的，也不可能主动来调用项目的代码，这个时候就需要使用signal来把各个app整合起来。

最大的区别是function based view整个view的逻辑被包在了一整个function里面，要实现view的复用，只能定义很多的参数，然后在view当中用参数判断来执行不同的逻辑。当参数多了，整个view就会变得非常巨大以及难以维护。

而class based view则将整个view的逻辑拆成了class下的多个函数，依靠函数调用来实现完整的逻辑。复用的时候要修改某一部分的逻辑就只需要重载特定的函数就可以了，可以写出复用性更好的view，同时项目当中也可以根据要求实现重载，更加灵活。

当然class based view也不是万能的，当继承关系很复杂，代码又不是特别规整的时候，要去找某一个函数到底是被哪一个parent重载也是一个麻烦事。这个时候就会怀念全部写在一起的function based view了。

所以还是要理解当中的区别，在合适的时候用合适的方法，千万不要听说某个方法好，就把它奉为唯一。

@faceair 这是个bug造成的，我们最近在加推荐news以及trending repo，判断空邮件的算法给漏掉了。这个bug已经修复，感谢你的反馈。如果有其他任何不满意的地方，还请多多提意见。

@hester 貌似同学们的参与热情不太高，需要好好总结下原因。估摸着应该不是周五的锅吧。

@ylhawj 如果有任何改进意见，欢迎反馈 :)

@adjusted 哈哈，这是跟娱乐圈学坏了啊。传说中的周一见 :)

@adjusted 是么？那这篇帖子属于误打误撞发在了一个好时间。周中和周末应该是有区别的。周一到周五的区别就太难测试了。

@PaulKing 明白了。trending的repo推荐在我们的开发计划当中。因为数据我们已经有了，要统计和推送并不难。但是我们想做的更好一些，从trending的repo当中筛选出来跟用户最相关的那些进行推送，所以把它排在了推荐算法之后。能否再给我们一两周的时间，我们应该可以推送给你符合需求的数据。另外如果对其他数据有需求，也请随时反馈。感谢。

@PaulKing 呼，总算有反馈了。不管是正向还是负向都非常感谢。现在系统里面还没有管理订阅的功能，我们很快就会加上，这样用户可以根据自己的需要来设置邮件的各种偏好。请问您原本想订阅哪些信息，最后收到的邮件当中包含的哪些信息不符合你的期望呢？您的反馈可以帮助我们改进算法，也许之后我们就可以推送给您符合期望的信息了。

另外还推荐 https://pragprog.com/book/dnvim/practical-vim 这本书，以及作者的 http://vimcasts.org/ 这个视频教学站

可以参考下这个问题的第一个回答 http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim 较深对vim的理解。

当理解了作者的设计思路之后，再试用vim就会顺手很多了。插件的话更多的是起到辅助效果，可以参考这两篇帖子：

- http://mirnazim.org/writings/vim-plugins-i-use/
- http://www.sontek.net/blog/2011/05/07/turning_vim_into_a_modern_python_ide.html

如果google一下的话会找到更多的参考帖子，就不多列了。

@victor 感谢，之前确实不知道。我们是希望通过Github Repo的方式来组织新闻，然后根据我Star的项目来表示我的兴趣，再个性化的聚合相关的新闻，用来解决信息过载的问题。在我们的博客中有关于我们设计思路的解释。usepanda更多的侧重在信息聚合，并没有解决信息过载的问题，而我们的思路跟它还有点区别。

我弄过，不过已经忘了具体的流程了。看报错貌似是tuntap_osx.o没有64位版本。可以考虑强行用32位来编译。

@awanabe 我本来想讲我们在用django+jsonb做的sql+nosql实现的，不过思前想后感觉不太适合pycon的听众，所以还是选择了一个偏保守的入门路线。不过上面提到的每条真的都是经验之谈啊。如果需要更加深入的交流欢迎私下联系:)

@mtglichking 既然叫跳线，本来定位就是短距离连接用的。不过5米应该不止，10米左右的应该也有。它在工厂里面批量生产，主要解决了人工用压线钳制作的水晶头不达标的问题。
网络是个系统过程，在整个连接过程中，一个环节没做好，可能整体的网速就上不去。而越高速的网络，对每个环节的要求就越高，线材只是其中一个环节而已。可以想象，如果每个环节都要达标，成本就飕飕的上去了。
所以在家庭网络中，其实不用那么讲究。预埋的线材用好一点，留一点余地，想升级的时候升的上去。剩下的就可以随便一点，该打水晶头还是打。哪天觉得性能不够了再想办法换掉。
我家里也用的六类线，但是我模块面板用的都是超五类的，水晶头也是我自己打的，都是为了节约成本。现在用的很开心，离瓶颈也很远。如果哪一天确实遇到瓶颈了，那大不了把现在的模块换掉，速度就上去了。
当然这还是基于理性考量，如果是土豪型的就无视我吧 :)