Posts archived in Cool Stuff

24 comments

September 4, 2008

完全用命令行工作-1: 拔掉你的鼠标

(本文可能不适合windows用户, 也不适合美工设计人员)

我觉得, 工作效率低下的原因很简单: 精力没有集中. 在计算机前工作的时候, 我发现一个提高精力集中度的最好办法: 拔掉鼠标.

拔掉鼠标意味着上网的时候不到处乱点链接, 书写的时候不简单的拷贝粘帖以及不会先想着格式和排版以干扰思路, 阅读的时候不动个不停的指向正在读的词(很差的阅读习惯), , 编程的时候不会老拷贝粘帖而是使用重构, 打开应用程序的时候不会误点到魔兽, 无聊的时候不会在联系人列表上找个人就随便海侃. 总之, 做一件事情的时候被限制在当前的窗口中, 注意力必然会提升. 具体来说, 不用鼠标意味着只用键盘来操作应用程序, 优点至少有以下几个.

1. 做正事时, 完全使用键盘能强迫人使用高效简洁和正确的工具. 我认为, 现在大多数应用程序都是堆砌一辈子用不到的功能, 而不是直截了当的解决问题. 那些工具窗口, 菜单栏, 状态栏等等到处都是, 想要完成一个任务必须在很多的工具中选择一个按钮点击. 其实选择和点击按钮只是完成操作的手段而已, 而不是必须步骤. 假如能够直接告诉计算机我想要做什么, 而不是先翻译成”我要点这个你才能做什么”, 效率会高很多. 而命令行就是直截了当的解决方法, 通常老手会选择使用快捷键, 这比点鼠标速度要快, 效率要高. 其实一般的应用程序, 核心功能不会超过20个, 这样20个核心功能用键盘操作完全有可能. 我甚至认为, 不能用键盘完全控制功能的程序, 可能本身就是不够简洁的. 使用这样的工具, 可能本身就是一个错误.

2. 处理零碎任务时, 使用命令行效率比鼠标点击简洁高效. 这是我观察到的一个具体的例子, 我想要看2009年1月4日是星期几, 在图形界面下, 我需要点击日历, 通过下拉选择2009 和 01 这两个选项, 然后才能看到日历. 鼠标输入2009和01是很费事的事情, 而在命令行下面我只要 cal 1 2009 就可以直接看到日历. 命令行能够直指问题本身, 绕开不良窗口界面设计造成的很多操作负担. 再比如说, 在使用网上日历和提醒的时候, 一句”have lunch tomorrow at 12:00pm with X” 显然要比用鼠标一个一个选择日期, 时间, 地点和事件来得直接. 在这方面, Gtalk 有很多的机器人可供大家选用, 比如查字典, 直接给字典机器人发送一个单词就能获得翻译, 比点一下字典程序等着启动然后输入单词要快太多了. 所有的这些目的性明确的小任务, 耽误的时间都不应该超过10秒钟. 如果使用命令行, 这个时间可以继续减少, 而使用鼠标点来点去, 至少要30秒. 而日常的零碎事务往往全是这类. (比如写一行备忘, 发一个小文件, 加一个提醒, 查一个单词或者维基, 标记一个日历, 控制一个远程服务等等).

3. 完全使用命令行, 使得浏览网页和无聊闲逛的时候注意力也集中. 我观察自己发现, 在电脑前面最浪费时间的事情就是顺着一个有趣链接点下去, 无穷无尽. 看上去获取了很多信息, 其实过眼即忘. 聊天也是, 往往一个爱说话的哥们上线聊上了, 一晃时间就过去好大一会儿了. 而完全使用命令行, 就强迫自己得用无穷多次的Tab才能点击那些链接. 这样, 就不会去主动点击那些链接. 聊天的时候也一样, 在命令行下面的会话没表情没声音也没提醒, 上线也没提醒, 干扰少很多.

再说我自己的具体的实现方法

1. 邮件和日常事务

Gmail 网络效率也不完全高. 最好用 Mutt. 快速发送文件附件的情况下 Mutt 是瑞士军刀, 参见我以前的叙述. 编程和文本编辑器随便是vim, emacs 都用不着鼠标的, 而且效率高. 浏览器一般使用 elinks, 遇到非Ajax 不可的才搬出 Firefox. 排版和做演示都使用LaTeX, 这个大家做科研的都知道. 另外, 把一些日常要做的任务写成make 脚本, 效率的提高是超出想象的.

2. 零碎小事

日常事务可借助形形色色的 Gtalk 机器人, 以及 Twitter 上一些特别的机器人. 其中Gtalk 客户端最好使用 GNU Freetalk, 可以自定义钩子(使用史上最优雅的 LISP 语言噢). 从而可以通过解析 Gtalk 消息调用系统程序. 比如我家有一台破电脑, 一直挂着Gtalk, 我在学校要回家之前就可以给这个Gtalk 发送信息让他提前打开我们家的空调或者电灯. 这些零碎的小事情的处理在 Web 背景下特别好解决. 如果你不是深度网络用户, 使用shell 脚本也能完成大多数工作. 比如日历, Linux 下面的日历管理工具都是支持命令行的. 其他如提醒啊, 日记啊, 字典啊, 都有工具. 除此之外, sed/awk, wget/curl 等等都有想不到的妙用, 完全可以把日常事务中的零碎小事处理得井井有条 (要知道, 当年贝尔实验室的科学家们就仅用这些工具辅助炸药奖研究的, 当时候微软还在做DOS呢).

如果你是Firefox 用户, 最近的一个 Ubiquity 的确是杀手级别的应用. 除了能控制网络服务外, 你也可以自己写个脚本, 把消息转解析到本机端口, 本机开一个简单的HTTP服务把消息代理给其他应用程序, 这样, 理论上, 在Firefox 里面也能控制整个计算机. 我也尝试了在学校Firefox里面控制我家的空调, 看上去很酷. 苹果用户也有福气, QuickSilver 这样的杀手级程序早就红遍大江南北, 我就不多说了(你要是苹果用户又不用QuickSilver或命令行, 那你真是把苹果当Windows用了, 暴殄天物啊!)

虽然没有严格的证明说鼠标一定浪费时间, 但是浪费时间的应用通常都需要鼠标支持. 我因为鼠标坏了舍不得买, 无意发现了这个结论. 如果你不相信我说的, 不妨尝试一下强迫自己不用鼠标一天, 看看自己是不是浪费的时间少了很多.

7 comments

July 9, 2008

Dreaming in Code 书评

软件, 没有圣杯的荣耀, 只有梦萦的代码 — “Dreaming in Code”书评

code2.jpg当日我读完第三遍 “Dreaming in Code“,  是夜, 代码冰山入梦来. 我想, 应该整理一下我的读书笔记, 写一篇书评了.

两打程序员, 三年的时间, 4,732 个 Bug, 以及一个愿望: 打造一个卓越的软件. 这就是 “Dreaming in Code” 所描述的故事. 而这个故事, 却没有 “新机器的灵魂 (The soul of a new machine)” 那样波澜壮阔, 甚至没有 “人月神话 (The Mythical Man-Month)”  那样告诉你一个明确的教训. 单论情节,  这就是一个沉郁到极点的故事. 没有英雄人物, 没有情节跌宕, 所有的人草草的出场, 草草的收场. 可是依旧一个梦在那里. 这个梦让全世界的程序员心动, 萦绕每个敲下过 Hello World 的人 — 怎样打造卓越软件.

软件难做,  高德纳 (D. E. Knuth) 这样写道. 为何难, 他没有回答. 而 “Dreaming in Code” 带来了一个具体的例子, 一个鲜活的, 几乎失败了的例子. 一个有资金, 有优秀程序员, 有开放的管理文化和明确的雄心的项目, Chandler, 曾经如恒星一样耀眼, 又如流星一样湮没. 不禁要问: 为什么? “幸福的家庭是相似的, 不幸的家庭各有各的不幸”. 这句话用来解释失败的项目再合适不过了.  如 Fred Brooks 那个著名的论文 “没有银弹 (No Silver Bullet)”[PDF] 揭示的一样, 这个问题, 没有一个明确的答案.

即使没有答案, 人们也在求索. 这本书, 和 “人月神话” 一样, 都是探索怎样打造优秀软件的著作. 不同的是 “人月神话” 近似于总结, 而这本书, 却只有问题,  无数的问题: 为什么不能像架设桥梁一样打造软件? 为什么构建软件不能像搭乐高积木一样? 为什么一个创造奇迹的人不能再次创造奇迹? 为什么有的开源软件成功了, 有的却失败了? 太多的为什么, 太多的问题. 而这个问题的答案, 不在书上, 确在书的字里行间, 在读者的思考里.

我是个天天写代码的程序员, 也是个常常在开源社区参与项目的程序员, 说起来再熟悉不过代码这个东西了. 可是怎样编写代码来组建卓越的软件, 我没有答案, 谁都没有答案. 可是这本书能帮助你找答案. 我极其推崇这本书的原因是, 读完之后, 你能问自己一些问题, 答案是这个么, 是那个么? 这本书本身, 不是答案, 而是获得答案的钥匙. 随着记者特有的写实的文风, 你会在书的字里行间, 跟着作者找到这把钥匙.

对于想找钥匙的人, 这本书有两个优点. 一是提出问题多, 资料多. 都说提出问题是解决问题的一半, 这本书在这一半做得相当好. 问题的另一半, 也就是答案, 这本书没有具体给出. 但是这就给了读者独立思考的余地. 有人会说是因为没有风险投资的压力, 有人说是前期需求不明确, 有人认为管理混乱. 无论怎样的答案, 你都会找到翔实的资料来佐证, 或者推翻. 这是一部活生生的不带评论的记录片. 这样的一手资料, 是极其有价值的.  第二个优点是故事的本身. 这是一个让人郁闷的故事, 一个失败的故事. 成功的故事通常激动人心, 但成功的光环往往掩盖了很多问题. 在成功的耀眼光芒下, 即使钥匙就在阳光下, 也很难找到光闪闪的它. 而在失败的废墟和尘土中, 钥匙如小钻石一样藏着, 细微的光芒引导勇敢的探索者, 并给他高价的回报. 失败总是比成功, 更加容易获取教训.

这是一本文笔优雅, 细节具体的书. 可是缺点也是显而易见的. 最明显的就是琐碎八卦太多. 作者是一个知识面很广的人, 能够从日历软件扯到图灵机和停机问题, 也称得上科班出身. 但是有时候可能也是为了显示知识面宽广吧, 把不相干的概念堆砌在一起到了没有边际的程度了. 比如第九章, 完全就是软件工程领域的最最基本的知识, 从软件工程到GOTO大战, 再说到 Ajax 和 Google 的崛起, 这之间的逻辑线就完全是天马行空了. 任何一个称得上关心现代开发技术, 或者科班出身的开发人员, 对于书里面提到的这些琐碎的事情, 都是烂熟于心的. 概念的过分堆砌和琐碎事情的描述至少占了这本书的1/2. 幸好这本书是值得读很多遍的, 再次阅读的时候, 跳过去就好了.

如果这篇书评能有副标题的话, 我愿意写上: “五个月的时间, 三遍阅读, 三十二页的读书笔记和无数的批注, 以及一个萦绕在脑海中的思考: 如何打造卓越的软件?” 这就是我这个读者的故事. 这本书国内的翻译是韩磊老师做的. 他翻译做 “梦断代码“. 我更加喜欢 “梦萦代码” 这个名字 (Dreaming 翻译成梦萦, 意音俱佳).  当年希尔伯特被问起, 五百年后若是他重回世间, 第一件事情是什么. 他说, “我要一定问黎曼猜想有没有被证明”. 相似的是, 宋朝僵卧孤村壮志未酬的陆游, 当年眼见收复中原无望, 梦里恍惚见到铁马冰河,  一梦醒来后对子女说: 王师北定中原日, 家祭无忘告乃翁.  无数的开发者梦萦代码, 一梦醒来, 就想问一个问题: 软件工程有没有找到银弹? 这个银弹之梦, 打造卓越软件之梦, 会一直萦绕着开发人员, 直到永恒.

情系软件, 梦萦代码

0 comments

November 13, 2006

SUN Open Sources Java

This news is cited from Techtree.com. To see the original post, please click here
All the rights may be reserved by the original publisher, this citation is only for study and communication.Finally, Sun Open Sources Java!
Techtree News Staff
Nov 13, 2006

Seems Sun Microsystems has finally relented under pressure to open source its Java programming language and associated software.

Today, the company will be releasing the first Java code under version 2 of the General Public License (GPLv2), which governs Linux and other open source products.

According to Sun, this move will promote Java and make it easier to bundle with Linux.

The Sun-hosted Java.net Web site will offer access to Java Platform Micro Edition (Java ME) software for mobile phones and Java Platform Standard Edition (Java SE) software for desktop applications.

Commenting on the development, Rich Green, Executive Vice President of Software, Sun, said, this is a milestone for the whole industry, and that not only are they making an influential and widely-used software platform for the Web available under open source, but that they are paving the way for a paradigm shift in how software is enhanced and developed.

While additions to software available under GPL have to also use the license, Sun is making an exception in the case of Java Standard Edition (Java SE). Meaning, programmers creating applications using Java SE will not be required to use the GPL license, and can instead opt for any other license for their applications.

Also, Sun will continue to offer commercial licenses that give other software vendors legal indemnification and official standards certification.

All in all, Sun’s move comes as a pleasant surprise, considering the company has continually resisted calls to open source Java, citing fears that such an action would cause incompatibilities among “forked” versions of the code.

[Added by me:] After SUN opened the Solaris x86 edition, now SUN make the JAVA, another weapon on its left hand open. It’s the winning of the Open Source Movement, and of course we can anticipate a more stable GCJ in the next year. Now everyone can redistribute Java with Linux and other GPLed code. We can anticipate that Python+Java will be the two most popular programming languages in the future based on the *nix platform including MacOS. I can also image that Jython and other combinations of Java+Python will flourish again. Java can never be so powerful as it is now.