三月...好漫长...整个 2 月不是过年走亲戚就是在家看 PDF,鸟哥的 Linux 私房菜,虽然自己用了一年多 Linux 桌面了,但是感觉知识还是 不够系统,于是又去把鸟哥的 Linux 私房菜好好读一遍去了...

感觉鸟哥的 Linux 私房菜写的超小白,有时候想跳着读,但又怕错过了什么...又放弃了,感觉读的有点很浮躁,说实话很多功能如果不常用 的话,也会慢慢忘记,不过还是有印象的,但是就不知道在哪个位置,这就是 PDF 的缺点了,如果是纸质书的话很容易再去翻阅需要的知识点, 虽然 Ctrl+F 搜索很好用,但是得到的结果总是不尽如人意,我个人还是喜欢纸质书.

光看书真的很没劲,于是我又开坑了...为了练习 python,我想当后端工程师啊!IE 一天不死我写前端就不会痛快! 新项目就这么愉快的开坑了,前端懒的设计就直接用Bootstrap了,感觉 Bootstrap 也就只能用些组件的 UI, 布局神马的还是不符合我的胃口.项目部署的网址是:http://netkuu.icehoney.me/ 目前还是绝赞填坑中~ 前端后端全部自己一个人写,希望能把自己锻炼成 full stack developer~ 现在就差数据库练手了,好久没玩数据库了.

大家肯定会好奇为啥到现在还不去上学或工作,一直在家,其实由于种种原因,上了手术台,在家养病中.希望能尽快康复.我想出去挣钱啊 QAQ

每月一篇文章任务完成~

每年寒假总是要读完一本书,去年寒假读的是白帽子讲 Web 安全.今年读的是程序员修炼之道:从小工到专家.去年那时候估计没有搭建好博客. 所以没有写点什么,今年还是写一下读完的感受吧.

这本书说实话我大一就买了,但是那时候没有一点项目经验.读起来宛如天书,没读一半就放弃了.因为那个看起来不知所云的目录让我顿时失去了兴趣. 大一的我确实无知,自负,浮躁,没有认真读下去.当时就沉迷于学习各种编程语言...没有审视到这本书的价值.如今我已大四,也算有了不少项目编程 经验,写过上万行代码,对于这本书的感受就是爱不释手.这本书用非常幽默的方式简述很多朴素而真挚,简单而有效的编程哲学.

全书基本是经验之谈,经验往往不能告诉我什么一定对,但是可以告诉我们什么一定不对.在提示 36 中讲述了需求之坑.告诉我们一个注重实效的程序员 应该需要挖掘需求而不是搜集它们.确实,客户往往不能很好的阐述需求,需要程序员进行深入挖掘才能使项目顺利进行.文中也举了很简单的例子进行阐述. 我一开始做项目的时候很顽固的要求需要明确的需求文档,现在想想这完全就是个笑话.因为客户自己都不清楚到底要做成什么样子.

本书的涉猎范围很广,也有很多专业名词.每个章节都可以延展出很多内容.我不认为这是一本只需读一遍的书.在每个编程阶段去读这本书都会有不同的感受. 这本书我肯定会珍藏,以后也会反复读的.这是一本程序员必须读的书,希望大家可以耐心的读一下这本书.

这本书的精彩之处只可意会不可言传,本人文采不好,但是极力推荐.最后摘抄下这本书阐述的注重实效的程序员的特征:

• 早期的采纳者/快速的改编者. 你具有技术和技巧上的直觉,你喜欢试验各种事物.给你一样新东西,你很快能把握它,并把它与你的知识的其余部分结合在一起.你的自信出自经验.
• 好奇. 你喜欢提问.那很漂亮--你是怎么做的? 你用那个库时有问题吗?我听说的这个 BeOS 是什么? 符号链接是怎样实现的?你是收集小知识的林鼠(pack rat),每一条小知识都可能会影响今后几年里的某项决策.
• 批判的思考者. 你不会不首先抓住事实而照搬别人的说法.当同事说"因为就该那么做"或者供应商允诺为你的全部问题提供解决方案时,你就会嗅到挑战的气息.
• 有现实感. 你会设法理解你面临的每个问题的内在本质.这样的现实主义给了你良好的感知能力:事情有多困难,需要多长时间? 让你自己了解某个过程会有困难,或是要用一点时间才能完成,能够给予你坚持不懈的毅力.
• 多才多艺. 你尽力熟悉广泛的技术和环境,并且努力工作,以与各种新发展并肩前行.尽管你现在的工作也许只要求你成为某方面的专才,你却总是能够转向新的领域和新的挑战.

最后,你是一个注重实效的程序员吗?

GUI 和 CLI 也算是使用软件的两大流派吧,Win 下几乎都是 GUI 程序,Linux 下几乎都是 CLI 程序.因为两者面向的用户不同, 初衷也不同.今天看了<程序员修炼之道>这本书,可谓是有了更深入的了解.GUI 侧重于易用,CLI 则侧重于效率.

对于使用 Linux 的程序员,工作台就是命令 shell.在 shell 提示下,你可以调用你的全套工具,并使用管道,以这些开发者从未想过的方式 把他们组合在一起.在 shell 下,你可以启动应用、调试器、浏览器、编辑器以及各种实用程序.你可以搜索文件、查询系统状态、过滤输出. 通过对 shell 进行编程,你可以构建复杂的宏命令,用来完成你经常进行的各种活动.在 shell 下面,可以高效率的处理事务,并且 shell 可以完成 在 GUI 下几乎所有的任务.GUI 和 IDE 会让程序员变得更懒,更无知,各种辅助工具,例如自动补全可能让某些程序员连 asynchronous 这个单词都无法完整的拼写出来.

对于在 GUI 界面和集成开发环境(IDE)上成长起来的程序员,这似乎显得很极端.毕竟,用鼠标指指点点,你不是也同样能把这些事情做好吗?

简单的回答:"不能".GUI 界面很奇妙,对于某些简单操作,它们可能更快、更方便.移动文件、阅读 MIME 编码的电子邮件以及写信,这些都是你可能想要 在图形环境中完成的事情.但如果你使用 GUI 完成所有的工作,你就会错过你的环境的某些能力.你将无法使常见任务自动化,或是利用各种可用工具的全部 力量.同时,你也将无法组合你的各种工具,创建定制的宏工具. GUI 的好处是 WYSIWYG--所见即所得(what you see is what you get).缺点是 WYSIAYG--所见即全部所得(what you see is all you get).

GUI 环境通常受限于它们的设计者想要提供的能力.如果你需要超越设计者提供的模型,你大概不会那么走运--而且很多时候,你确实需要超越这些模型.注重实效的程序员 并非只是剪切代码、或是开发对象模型、或是撰写文档、或是构建过程自动化--所有这些事情我们全都要做.通常,任何一样工具的适用范围都局限于该工具预期要完成的任务. 例如,假定你需要把代码预处理器集成进你的 IDE 中(为了实现按合约设计、多处理编译指示,等等).除非 IDE 的设计者明确地为这种能力提供了挂钩,否则,你无法做到这一点.

你也许已经习惯于在命令提示下工作,这种情况下,本文就可以忽略啦~ 否则,你也许还需要我们向你证明,shell 是你的朋友.

作为注重实效的程序员,你不断的想要执行特别的操作--GUI 可能不支持的操作.当你想要快速地组合一些命令,以完成一次查询或某种其他的任务时,命令行要更为适宜. 例如:

在上周哪些 Java 文件没有改动过?

Shell

find . -name '*.java' -mtime +7 -print

GUI

点击并转到"查找文件",点击"文件名"字段,敲入"*.java",选择"修改日期"选项卡. 然后选择"介于".点击"开始日期",敲入项目开始的日期.点击"结束日期",敲入 1 周以前的日期(确保手边有日历).点击"开始查找".

这样的例子很多.shell 命令可能很晦涩,或是太简略,但却很强大,也很简练.同时,因为 shell 命令可被组合进脚本文件中,你可以构建命令序列,使你常做的事情自动化. 希望你看完这篇文章能逐渐接受 CLI 并熟悉 shell.多用你的命令 shell,你会惊讶他能使你的生产率得到怎样的提高.