忙活了一个多月，博客总算完工了！哈哈
回顾一下整个开发过程：后端用了python flask框架，sqlalchemy作为数据库接口。一个是简洁的微框架，一个有强大的ORM数据库引擎，所以整个后端比较干净简洁，上手和开发速度都很快，占整个工作量的比重很小。唯一值得提的就是博客评论和回复的设计，一开始不顾效率设计了文章->评论->评论的回复 三个表逐层索引，后来发现这是个很不好的设计，评论越多数据库查询工作量就越大，会导致页面延迟，因为每条评论都要查询一次自身的回复。最后费了一番功夫将评论和回复表合一了，这说明了任何项目开始前都需要有清晰的思路和良好的设计。
很多人用flask-sqlalchemy的时候一定用过SQLALCHEMY_COMMIT_ON_TEARDOWN=True，从字面就可以看出来，这是当request请求销毁的时候提交数据库更改。例如：我需要统计博客文章的阅读量，每个请求到来，我就把文章的阅读数字段+1，然后提交数据库，再渲染页面返回给对端。有了 SQLALCHEMY_COMMIT_ON_TEARDOWN ，那么我就可以不提交数据库，直接渲染页面就行了，当本次请求结束的时候，flask-sqlalchemy装饰器注册的函数就会自动提交数据库了。我一开始以为是异步提交的，会先返回渲染页面，但其实不然，仍然是在本次request上下文中、在response之前进行的数据库提交，延时一点不会减少，sqlite提交一次可是需要近100ms啊！如果你问那这个定义有什么用呢？我想应该是在当你的视图逻辑中修改数据库比较多的时候吧，它会替你一次性提交更新。
后来发现了blinker信号，是一个很好的消息发送和订阅模型，将发送者和订阅者从代码逻辑上很好的解耦了。但我发现他也是同步模型。于是我做了一个不规范解法：起一个线程和Queue,接收固定数据库事件，然后异步提交，保证每个request的快速响应。
再聊下前端：前端我没有用任何前端流行框架，只用最简单的html+css，没有任何图片，部分页面用了少量的js，尽量做到极简。开发过程中反复调试，做到了兼容ie6 。要知道，对于一个业余玩家，ie6可是有无数大坑啊！经常做着做着发现，ie6下显示又不正常了！然后调试，修复。没过几天，又再抽风一次。。。左右margin计算会双倍：导致我能用padding就尽量不用margin；行内元素右浮动会换行：将该元素放在最左边；ajax 请求遇到302跳转，如果跳转地址有cache记录ie 6/7/8会从cache读取导致脏页面。。。等等等等
前端调试工作量占了一大半，我的测试数据库统计显示，页面刷新了近3000次。。。当然，作为新手，经验不足效率低下是主要原因，页面做的也不专业，不够美观。这次发现前端开发的确头疼，需要想尽办法兼容各种浏览器，这要怪就怪微软捆绑了落后的ie，导致目前仍然有比例惊人的ie用户。不过随着时间推移，ie终归是要淡出，就跟技术一样，新的不断淘汰旧的，而我们呢，在后面学习着，奔跑着。
最后，上图，部分svn log：
