自己的第一张信息图。
大概7月中下旬产生的想法，体验一下做信息图的完整过程，并且尝试学习一些新的技术。选择下厨房是因为自己还挺 喜欢这个网站，而且觉得它有那么多菜谱，或许能回答出“哪道菜最复杂”或者“什么食材出现频率最高”之类的问题。后来又仔细看了看该网站的HTML结构， 还算简单，就是它了。
对于技术、框架的选择，因为完全是自己做着玩，所以更多的是凭兴趣。比如我喜欢Python，查了下Scrapy就是 Python做网络爬虫的不错选择；在考虑数据存储的时候，最初其实只是想简单来存成json文件就行了，后来朋友说SQLLite来存吧，自己想了想， 一直是在“听说”NoSQL，何不自己试试呢？看了看目前比较火的几种选择，最后在MongoDB和CouchDB之间选了后者，因为觉得本身 RESTful、json支持都很好（用的功能比较浅显，也确实没法比较二者孰优孰劣）；本打算展现用D3来做，后来太<del> 懒</del>赶没时间学，把数据整理好之后就直接用ppt里面的图表来做了。
我把需要抓取的网页分为三大 类，category、subject和recipe。category只有一个网页，记录了所有的菜单分类；subject数目也不多（但后来发现废数 据最多），30000不到，属于对同一个菜不同做法的主题分类；recipe就是真正的菜单了。Scrapy基本功能非常容易上手，再加上下厨房的网页结 构不复杂，很快其实就写好了。之后抓去网页，性能成了瓶颈，调整设置，发现DOWNLOAD_DELAY是对我影响最大的参数，其实是害怕抓网页被捉，所 以才设置了这个参数，后来放大胆子直接设置为0，效率高了好多（最开始想过要不要把爬虫部署到哪个服务器？或者搞个Raspberry Pi？其实这些都不重要……直到最后都是在mbp上和公司的thinkpad上爬）。scrapy抓取的网页，可以有很多数据存储的选择，我存过json，后来写了个很简单的pipeline就能存到CouchDB里面了。
CouchDB 让我第一次真正用上了NoSQL，而且还是基于Map-Reduce的。思路上就要有所调整，从最初进行查询时候的不适应——脑子里还在想其实 select的话会很好查呀——到后来开始接受Map-Reduce的方式去做查询，这种转变可以说是很大的。很简单可以将Map-Reduce理解为分 而治之（Devide & Conquer）再汇总，可真正用起来还是要想下、多尝试。其实到最后使用它的时候依然没那么熟练，就用了一些笨方法去做统计，这些技能在制作下一个信息 图的时候都要提升。坦白讲我对CouchDB的查询效率不是特别满意，也可能是自己写的map、reduce方法不够聪明，总觉得区区10w量级的数据， 查询、汇总起来应该可以更快些吧。当然，也不能排除是我机器不够强大的原因。
用ppt做图表这事儿就没什么好说的了，数据准备好，该算的都 算出来，ppt的图表其实很方便就能做出一堆基础图形。在向ppt妥协之前，我找过一些网上专门用来作infograph的在线工具，尝试了2、3种后发 觉要么不够灵活，要么需要付费导出图片……总之还是有些限制的。接下来自己想试试highcharts和d3js，看看真的去做个网页版、更漂亮的出来。
下 厨房的数据质量比较一般，一方面是不少废网页（subject中好多办证网页），另一方面，由于菜单是人人都能创建的，菜单质量真的参差不齐，步骤多的菜 单可能是“过于详细”，步骤少的又真的没什么参考价值，总的来说，这张图更多是对我自身的意义大一些，其实无论是制作难度还是信息质量都不算高。
其他：
- 一开始还想用个git工具来同步、备份、管理代码，最后全是在dropbox中进行了
- 代码都是在Sublime Text中写的，太爱这工具了
- 真希望Windows上能有个iTerm
- 图片做的很山寨，因为用ppt做好了图表之后，图片编辑工作全是在Windows的绘图板中做的
我是个崇尚“能用大于好用”的人，但每每会想“要不用个xxx弄好看点”之类，这大概是一种自我拖延的方式，其实做infograph有太多种方式，可以简单可以复杂，对我来说，最重要的是学了新的技术（尽管目前很浅显）而且动手去做了，最后做得还算让自己满意，足矣。
