1. 敲一个命令后知道将发生什么，包括Shell、程序和内核都做了什么；
2. 改一行配置后知道将发生什么，包括配置被哪个进程读入、解析、生效；
3. 看一眼日志后知道已经发生什么。

看过源码只是加分项。关键在于知道整个系统都做了什么。

sed -n '/[0-9]\{6\}/p' a.txt

http://invisible-island.net/ncurses/man/ncurses.3x.html

这算文档不全么？

设计模式并不如想象中那么重要。

命令替换，将``中的命令的输出结果原地替换。

针对问题1有如下问题需要考虑：
1. 交通状况信息的数据来源与量级？数据的采集方式是来自路段监测点还是来自移动设备？数据的真实性（伪造/篡改/破坏）？数据的判断方法？
2. 通信方式与能力（带宽/流量）是否能满足？
3. 同步速率与成功率（局部节点群里的全连接）？

我可以包教基础知识部分（含PS）。XD

建立一个新模块，接口保持一致，是以重建。

计算机方面的技能？PS系最合适。

printf + 二分法。

@vking 只是一个思路罢了。

有一种在图片中藏匿信息的方法，前提是图片不会被修改。

人眼对某种波长的颜色是不敏感的，这种颜色量化成RGB之后，可以对G分量做细小的改变而不被人眼觉察出来，从而实现信息藏匿。

把视线从纯技术转向其它领域，便能看出一个公司能给喜欢学习的人提供什么必需之物：
1. 折腾的空间，或者说可容忍的试错成本：想想吧，如果是搞大规模服务器运维，任何运维子系统的构建都离不开足够多的软硬件资源，否则就只能学到一些皮毛的东西，而接触不到真实的规模化层次的难题，更别提去思考应对方法；
2. 领域专家与业务专家的聚集地：没有什么地方能比在公司里更容易地找着这些人了，自己去论坛翻、看微博、看博客都不如这个快；
3. 一份足够养活自己的薪水。

我是七牛的运维主管。