大家可以看到我上一篇文章加了密码，事情是这样的，听我解释。这是我们课内的作业，贴上来的东西分分钟就是我自己的实验报告，并且deadline还远着。然后我是很相信我同学的“正确使用搜索引擎”的能力的，并且我之前装了一个插件可以帮助google搜索抓取我的页面使之更易被检索到，所以，这只是为了避免不必要的悲剧发生，等到deadline过去以后自然会解放权限。密码是，我的高中校名的拼音。如果不知道是众多校名称呼的哪一个，多试几次就好了，毕竟我只读过一个高中。
孟祥武孟爷爷老是说：“你们不能只用一个操作系统啊，除了windows，还应该多试试别的。如果只用一个操作系统，你就会觉得windows就是操作系统，操作系统就是windows——这是不对的。”
类似的，孟爷爷还有“不能只学一门语言啊”，“不能只用一种浏览器啊”的谆谆教导。
于是下定决心在自己电脑上装了个虚拟机，先装了ubuntu kylin 15.04，但是觉得不流畅，网上评价也很一般，于是转ubuntu kylin 14.04，使用至今感觉不错。之所以不用原版ubuntu，是因为麒麟版本对于中文更加友好，并且跟原版也没什么差别。网上有人在撕麒麟是不是国产的，其实明显它并不是国产，说是联合开发，实际上kylin只是ubuntu一个子分支，用起来不用心存芥蒂。
顺手贴个很著名的很洗脑的文章，《完全用Linux工作》。书架上还有一本《鸟哥私房菜》嗷嗷待操。
转型的过程总体还算顺利，装codeblocks写c++，然后g++和gcc系统是没有自带的，所以顺手装了好多东西。换语言的时候出了问题，出了一个“源引用”错误（提示信息： “ubuntu kylin It is impossible to install or remove any software”），需要打开某个属性栏然后勾选或者是删除某个选项才行，具体的记不清了（翻了一下历史记录没找到），似乎没什么遇到跟我一样的情况；再就是选择简体中文的时候，如下图
一开始那个“汉语（中国）”的选项是在下面，而且是浅色的，常识告诉我它仍不能选。google了以后发现正确的打开方式是：点住他、拖动到语言栏的最上方。太魔性，别人不跟我说的话真是一辈子都找不出来毛病。
eclipse至今没有建起来，原因是我搜的那个办法有一步是在shell内使用vim修改一个源文件，当场我就萌比了。还有github理论上是可以直接用shell去push和pull的然而也还没学会（因为暂时还不知道怎么用shell往git直接提交，所以我是开了github的网页然后直接粘上去的）。shell命令也基本不懂，而这才是linux的精髓。以上，列入TODOLIST了。
linux部分大概就这些，使用了半个月，用户体验非常好。因为里面没有qq没有qq音乐也没有全家桶们没有弹窗们，没有任何可以打扰我的东西，做事效率高一点，并且是不是能骗取路人们的仰慕，无形装逼。
之前在windows上配好了github没用过，这次在linux上也配了一下（但是还不懂怎么push和pull），然后写作业的时候就真正用github做版本管理了。放几张效果图
github的界面简洁明了
上图为各个版本
版本管理非常方便，点开以后可以看到当前版本与上一版本相比做了什么修改，红色行为原来的写法，其中深红色（此图没有）是具体的修改或删除的地方；绿色行为该版本的修改，深绿色标明了修改或添加的地方。没有改动的代码段自动折叠。最左有新旧两版本的行号对照。支持多人管理同一文档，每一个改动都会标明修改者id、修改内容的题目、修改内容的简要说明等关键信息。
实在很强大，难怪田队年初的时候决心在ACM校队内普及git的用法。今年北邮的校赛的出题验题工作就都是在git上完成的。
总之，github是一个强大的工具。
最后做一点个人的读书笔记。
关于如何写注释。
1.不要为那些从代码本身就能快速推断的事实写注释。eg:构造函数就不用再写 //constructor了
2.不要给不好的名字加注释，即注释不应用于粉饰不好的名字。一个好的名字比一个好的注释更重要，因为在任何用到这个函数的地方都能看见它。好代码 > 坏代码 + 好注释。
3.不要写废话。如果一定要解释一个函数，请尝试给出它的逻辑细节。
4.记录你的思想，克服“作者心理阻值”。例如，假如你正在写一个函数，然后心想：“哦，天啊，如果一旦这东西在列表中有重复的话会变得很难处理的”，不如把它写下来：
|
1 |
//哦，天啊，如果一旦这东西在列表中有重复的话会变得很难处理的 |
It does help. 并且最后review的时候你可以尝试改一下这句话，把具体问题解释得更清楚一点。
5.在代码中加入注释记录你对代码有价值的见解。例如，
|
1 2 3 4 5 |
//出乎意料的是，对于这些数据用二叉树比哈希表快40% //作为整体可能会丢掉几个词。但这不是问题，实际上要100%解决太难了 ... |
6.为代码中的瑕疵写注释。
|
1 2 3 4 5 |
//TODO: 采用更快的算法 //TODO：处理除JPEG以外的图像格式 ... |
尝试使用标记。书里给出一种流行的写法。“TODO”：我还没有处理的事情。“FIXME”：已知的无法运行的代码。“HACK”：对于一个问题不得不采用的比较粗糙的解决方案。“XXX”：危险！这里有重要的问题。
7.当定义常量时，通常背后有一个关于它是什么或者为什么它是这个值的“故事”。
|
1 2 3 4 5 |
NUM_THREADS = 8 # as long as it's >= 2 * num_processors, that's good enough image_quality = 0.72; // users thought 0.72 gave the best size/quality tradeoff ... |
这可以让读代码的人有了调整这个值的指南。经验告诉我们，很多常量可以通过加注释得到改进，而这只不过是匆匆记下你在决定这个常量值时的想法而已。
8.可能需要一些高级别的注释，比如文件级别的：
|
1 2 |
//这个文件包含了一些辅助函数，为我们的文件系统提供了更便利的接口 //它处理了文件权限及其他基本的细节 |
——以上摘自DB & TF 的<The Art of Readable Code>
45个习惯。
7.懂得丢弃。敏捷的根本之一就是拥抱变化。在学习一门新技术的时候，多问问自己，是否把太多旧的态度和方法用在了新技术上。例如，学习一门新的编程语言时，应该使用推荐的集成开发环境，而不是你过去开发时用的工具插件。转换的时候，完全不要使用过去的语言开发工具。只有更少被旧习惯牵绊，才更容易养成新习惯。对旧习惯不是完全摒弃，如果环境合适，可以举一反三地灵活应用。
9.把我开发节奏。以固定、有规律的长度运行迭代。
14.提早集成，频繁集成。在产品的开发过程中，集成是一个主要的风险区域。让你的子系统不停地增长，不去做系统集成，就等于一步一步把自己置于越来越大的风险中。而若在早期就进行集成，你会更清晰地看到子系统之间的交互和影响，就可以估算它们之间的通信和共享的数据信息。如果落实得好，集成就不再会是一个繁重的任务。它只是编写代码周期中的一部分，集成时产生的问题都会是小问题并且容易解决
——以上摘自VS & AH 的 <Practices of an Agile Developer>
0 等你来赞