“初心社区”的部分技术总结

临近毕业，为了学习python和web开发，和同学一起开发了初心社区，是一个二手交易平台。 关于初心社区，可以点这里

改完了一些代码，看了太郎的文章初心社区——校园产品的尝试和分析，觉得自己也该在技术上总结一下，免得以后自己忘了。又得重新学一遍。

andy说，做技术总结其实是最难的，相当与重新学一遍，那现在我就重新学一遍吧，努力不写的太乱。

技术选型：Django1.3 + MySQL + Solr + rabbitmq

1.Web框架：Django。
只所以选Django，一是去公司之后，肯定会有很多用python的地方，还不如这次做项目的同时就顺便把Python和Web开发多学一下；二是Django在公司实习的时候用过一点点，虽然这个框架在Python的Web框架中，算是很heavy的，但是一旦准备就绪后，能给我这样的新手带来不少好处。 不过后来的使用过程中，我也一度蛋疼过，很多地方都恨不得去重写它的代码。特别是，我很想吐槽它的template，render的效率低，模板语法让人蛋疼：if a == b 非得写 ifequal a b。。。

2.数据库：MySQL
选择原因很简单，我用过的数据库除了MySQL之外只有2种：SQL SERVER 这个排除不需要理由；SQLite 一直以来用这个，除了Android上的，其他地方都只是写demo才用，虽然有文章说SQLite对大数据量的支持很不错，但我觉得还是在服务器上不用为妙。

3.搜索：Solr
实际上用的是haystack（1.2.7），这个是针对django搜索的third-party app，它的引擎可以选择solr，xapian，whoosh等等，不过我还是选择了solr。 因为我开始选择搜索的时候，就试了django-solr，在自己实验和看了一些文章之后，还是决定用了haystack。 不过目前的中文分词，我是找了一个Java的分词库IKAnalyzer，直接丢在solr的配置里面，搜索结果完全看它的分词功效了。囧～ 目前，网站流量很小，数据量很少，solr索引的更新，我cron设置的1h一次。
小插曲：solr建index的时候，会有个text字段，建立那个之后，可以在某个目录下面，建一个txt文档，里面放上你会传到template的object属性。 这个地方，我很蛋疼的用了MutliValueField，重写了prepare_XX方法，返回一个values list。 在模板里面，按照它蛋疼的语法，就是去values.0, values.1等等。。

4.MQ：rabbitmq
其实，最初去阅读这方面的资料，是刚开始讨论产品功能的时候，我觉得可能会有消息推送，于是就查了些资料，搜到了这玩意儿。 到现在，用到这个的地方，就是一些需要大批量插入数据而不会在乎小差错的时候，放给它去异步执行，减轻数据库的压力。
rabbitmq与django的结合，还安装了celery，用的djcelery app。

5.代码管理工具：SVN
说起这个，真汗颜。
刚开始，在googlecode上开的项目，我先把项目划分好app，所需要的目录都建好，然后丢在gcode上，不过后来发现，只有我提交代码，索性就不再提交了（原因太多～）。后来带来的麻烦可想而知。。 后来，去服务器部署的时候。在服务器上依然用的是SVN。
小插曲：在服务器上部署SVN服务器之后，我本地co，ci，up都很正常，但是为了方便和服务器代码同步，我需要在服务器端也co一个版本，却死都co不下来，询问多人未果，在stackoverflow上找类似的问题也木有找到。后来看到一个不相干的答案是有用file协议，而不是svn协议，嘿，在我这边试了一下，就好了。

6.上线环境： 无。
蛋疼蛋疼。。现在fix bug和加新特性之后，只能在半夜上线，如果后台代码动的多，还需要停一会服务器，免得和用户使用产生冲突。。。。。 如果可能，以后有两台服务器了，一定要学一下怎么建立很好的上线环境。现在只有一台，还是Vps，想搞这个，估计是奢望了。

7.开发过程中遇到的一些比较菊紧的问题：
（1）.这次用Django，和form打交道很多，包括自己写valid规则，自定义form样式（自定义id和class的时候，有时候还要考虑前端js。。。），最蛋疼的是，页面传过来的数据，有时候明明是unvalid的时候，还需要在views里面，自己给copy赋值，把它变成valid. 最最蛋疼的是，动态改变form的自定义样式（特别是使input disabled后，还需要能够使用页面传来的数据），在官网上查不到相应的API， 又懒得去一行行的去看源码，就用dir出来的，看着像的一个个试出来。

（2）第一次把代码部署到服务器上进行联合测试的时候，有反映只要是中文，就会报错，但实际上入库了。突然一拍大腿，我草，我原来搞的时候，把本地MySQL编码方式改了，服务器上忘了搞。。。
（3）. 上线后才发现，建的联合索引出问题了，插入的数据，除了主键不一样、其他都一样的时候，插不进去啊啊啊。解决方案之一:把主键也索引进去，可是我之前是用的django自动生成的autoincrement字段，已经上线了，这一改就蛋疼了。木有办法，就先删了那些联合索引。。。

 （4）. Ubuntu没升级到12.04之前，突然一次update之后，我的Chrome不能用了，卸载N次无果后，只好选择用FF，而我的FF，死都装不上Firebug啊，，，还装不上Flash插件。。。导致的直接结果就是：调js，我要用alert，，半夜写代码，得用pad在旁边放歌。。。
 
  （5）. 项目里面，目前选择的排序是很简单的按照帖子/交易 的更新时间排序，有的从数据库取出来直接order by一下，就可以了， 但是有的，搞出来之后，还得自己写个cmp function。

   （6）. 网站上有很多地方需要分页，再取count的时候，如果去count某个字段，等到数据量真大起来会很蛋疼，于是，我更蛋疼的，把那些需要count的字段，单独搞出来，建了一个单记录表。 这个解决方案，不知道有什么太大的弊端，，看到文章的大大，能指点一下就好了。

   （7） 今天晚上，想把profile页面的分页给加上，然后发现依然要按照（6）说的，单独建表，但是profile里面的数据是“我发布的交易”，那么建的count表，就不是单记录的，而是单单记录，one user，one count吧。 在我本地搞，可以，但是服务器上肿么办，原来的数据木有加上呀。。 哎，用户量凄惨也是有好处的，insert into XXXX(f1,f2) select f1,count(f1) from XXX2 group by f1; 这样的语句，我也就可以大胆的在db server上跑一下。 ～。～

还需要做的事情：

1.上站内信，尽量保护用户隐私吧
2.把一些不需要马上执行的、频繁操作DB的操作，放到mq吧
3.找时间优化数据库吧
4.有些地方，不用ORM了，自己写sql吧
5.有可能的话，把Django自带的template换成mako或者jinja吧。
6.如果有一天，真的有再搞一台服务器的必要，我就上缓存，我就折腾上线环境吧。
7.如果有一天，有做移动客户端的必要了，我希望我会写做iOS吧。
7.如果有一天，网站死掉了，我就把代码重构，写的好看点，开源出去，那样应该可以让自己学到更多吧。

努力努力让自己写的东西不要太语无伦次，争取让大多数人包括自己看懂，如果你真的看懂了，那希望你能够在技术上给我一些指导，不胜感激。