原文链接：論理と直感とiBooks Author

译文

说起“逻辑”和“直觉”，人们通常认为这是两个相互对立的概念。关于这两者，可以讨论的方面有许多，在这篇博客中，我想就文书的格式和版式展开些讨论。

从文脉的技术角度来说，所有的文章其构造都应该具有逻辑性。计算机很喜欢这种逻辑结构鲜明的文章。具体说来，写文章的时候，先有标题，对吧？然后是章，每章也有自己的标题，而章又由节构成，节也有标题，其次才是正文…… 作者就是根据这样树状的逻辑结构将文章一点一点堆砌起来的。这样写文章，诸如抽出文章的大纲、简便地生成目录、明确检索目标这样的任务都会变得很方便。这是对于计算机而言的。

那么，文章要给别人看的时候呢？这就需要直觉上的版式了。在页面上布置标题的位置、设计页眉、正文分成四栏、给需要强调的内容配上插图…… 安排各种有助于阅读的要素。这些设计是为读者服务的。在这个过程中，会破坏文章的逻辑结构。心中想着文章的逻辑结构，默念“啊！绝对不能破坏逻辑结构！”，同时，直觉却告诉自己“这样改不是更有助于理解吗？” 于是，逻辑和直觉形成了一种对立。

现在的Web就是这样一个逻辑和直觉互不相容的常见例子。HTML是用于表述文章逻辑结构的格式，但尽管如此，为了实现复杂的版式，人们将各种排版技巧发挥到了极致。当前的Web是充满了各种碎片信息的集合，很难将这些碎片还原成原有的语义信息。

再来看看iBooks Author。iBooks Author的魅力在于能通过直觉化的方式方便地进行排版。使用拖拽的方式就能为文章配上插图，对于任何人来说，上手都很容易。而且，做出的书相当具有表现力。通常，引入这类功能的同时，文章的逻辑结构就会变得支离破碎。最早看到iBooks Author的演示时，我心里想的是：哎呀！这样岂不是把课本的逻辑结构完全给破坏了吗！

亲自体验过后，我还是发现了课本中的逻辑结构。最粗的结构是：书 →章→节。再细分下去，通过指定段落的样式，又可以为其增加次级的逻辑结构。插图和图表看似可以自由安排，但实际上是跟段落关联在一起的。从体裁分类上讲，就是从属于某个段落的插图。

其次，将iPad转为纵向时，这种iBooks Author做的易于阅读的版式就会发生变化。旋转至纵向后，插图就会出现在左侧的边栏中，完全从正文中独立出来。也就是说，横向布局的版式是直觉式的阅读模式，而纵向布局的版式则是展现课本逻辑结构的俯瞰模式。这种让两种对立的结构共存的方式是我之前完全没有想到的。真叫人佩服。

让阅读体验“在逻辑和直觉的狭缝间游刃有余（Between Logic and Intuition）”。这是真正激动人心的本质所在。我希望使用这些电子课本的学生朋友们也能体会到这一点。

看了本文后的感想

我想到了数年前，曾尝试过使用LaTeX排版，写文章。因为很多用过的人说，LaTeX系统很强调文章的逻辑结构。只要逻辑结构正确，排版引擎会自动完成许多工作，产生漂亮的版式。可我既不是数学系学生那种重度LaTeX使用者，也没有花时间去记去练习。要掌握LaTeX实在有点力不从心，最终还是放弃了。

另外，iBooks Author不同于MS Word/Pages这种泛用的排版工具，它是一款专用工具，其出版的目标媒体仅限于iPad。虽然这一点遭到不少指责和批评，但站在作者和读者的立场上，我觉得就目前而言，这种限制对于良好的阅读体验来说是很必要的。

我还是耐心等待iPad 3吧！

最近在构思一个用于Mac/iOS开发的工具。感觉比较庞大，脑子里的东西比较混乱，决定先把最初的设想写下来，然后再一步步细化。

问题的由来

这个构思的起因是2011年底前的一个iOS项目。设计MM为了吸引用户，在UI中设计了各种可爱的元素。也差不多在这同时，Path 2登场了。其精致的动画让设计MM意识到动画也是体现UI表现力的重要手段。于是，她就开始设计中增加动画元素。

围绕这这些动画效果，我发现在设计和开发过程中有不少问题：

• UI设计师如何描述动画
  动画与传统的静态UI不同，单单凭借静态的设计是很难把问题说清楚的。如果采用关键帧的方式去绘制一些分镜头的脚本，会给设计师增加不少工作压力。
• 开发人员如何实现动画
  在Mac/iOS平台上，实现动画主要靠的是Core Animation框架。然而Core Animation比较底层，因此Apple对其进行了封装，提供了Cocoa Animation以方便开发人员实现动画。但不论在Mac还是iOS上，通过编程方式实现动画效果依然需要大量的代码，而且对于比较复杂的动画，开发人员还是需要直接通过Core Animation操纵CALayer、CAAnimation来实现。在我的项目中，最重的view controller里，居然有80%的代码用于实现动画效果。

于是我意识到，这样的开发是有问题的。理由很简单，设计师所设计的是动画，既然是动画，就不应该是几个分镜，几个关键帧这样的半成品。更不应该等到开发人员将代码写出来，再就具体的效果进行讨论。而开发人员也不应该堆砌大量的代码用于动画，因为同时具有艺术感和代码实现能力的开发人员真的非常少。想要做出高质量的动画，这样的过程没有几个回合是搞不定的。总之一句话：

Does real animator write codes? Definitely NOT!

在设计师和开发人员之间必须有个工具扮演桥梁的角色。类似于Flash上的工作流，设计师能够通过该工具直接做出大部分动画效果，而开发人员则在项目中导入这些预先定义好的动画脚本，并根据需要进行一些优化和微调。

如果存在这样的工具，不仅能有效简化设计师和程序员之间的沟通过程，实现工作职责的更合理分配。更重要的是，它还能使代码变得干净，提升代码和动画的可复用性。

方案构想

以我目前对Cocoa/Cocoa Touch的理解，这个工具应该包括以下几个部分

1. 一种用于描述动画以及相关project的数据格式
   暂时并没有夸平台的想法，所以初步考虑采用Cocoa的Archiving机制实现。
2. 一套用于Cocoa/Cocoa Touch的框架
   该框架用于将保存在文件中的动画脚本还原为代码，并通过回调等形式与应用代码进行数据绑定。最后通过Core Animation框架执行动画。
3. 一个用于设计动画的桌面应用
   该应用的目标是让设计人员能够直观地设计动画，并能够保存读取1所提到的数据格式。具体的功能可能包括：
   • 一个静态编辑器，用于编辑CALayer及其子类的实例（设置背景、透明度、阴影、过滤器等）。
   • 一个动画编辑器，用于生成简单动画或是复杂的关键帧动画、AnimationGroup等对象。
   • 辅助对象编辑器，用于编辑动画图层的约束关系、MediaTimingFunction等辅助对象。
   • …… （余下的仍在设想）

目前的状况

这个构想是去年末渐渐浮现出来的。于是最近开始系统地围绕着Core Animation相关技术以以及Mac桌面应用的开发开始调查和学习。目前的感觉是与iOS相比，Mac OS X的技术平台要复杂得多。为了了解Core Animation的来龙去脉，连2006/2007年苹果的Mac技术讲座都翻出来了，由于苹果在技术架构上秉承实用主义的原则，在这几年的时间里，整个技术体系的更新非常快（当时还有不少视频讲如何使用GC的……） 因此，技术准备的时间会比较长，在把相关的问题理清楚之前，不打算贸然开始开发工作。

鉴于最近看了不少Core Animation的资料，我也打算将这些资料整理成博客陆续放出。

因为最近想尝试一些OpenGL ES的开发，所以想找本入门+进阶的书。在amazon上找到几本，但仅凭preview和review没有办法确定这些书是否适合我，于是去书店逛了逛。

到了书店的计算机部，有好多书吸引了我，有的是因为主题，有的则是因为别致的设计。

令人震撼的骨董计算机之美

摄影和计算机让人联想起什么？如果你想到的只是PS，那么你绝对应该看看O’Reilly的这本 Core Memory : a visual survey of vintage computers （目前还没有中文版，我称之为《Core Memory：骨董计算机之美》），这是摄影艺术对于计算机之美的诠释、对于机器和人类智慧之美的诠释！

我从time.com上找来了一些书中的图片，在这里引用两幅。

Eniac的电子管阵列

Core Memory 肉眼能够看到的1比特

这本书是2007年出版的，这么久了，在国内却一直不知道……

游戏书

日本在游戏市场和游戏开发领域都在世界的前列。游戏方面自然也有不少书（当然不是指游戏攻略……）。

最注目的是这本 《死ぬまでにやりたいゲーム1001》（到死也想玩的1001款游戏），看封面就知道这是本纵贯游戏史的作品了。960页的容量，让其成为名副其实的砖头。看着这些亲切的画面，确实能引起70、80年代的人很强烈的共鸣。这些游戏不仅在当时是划时代的创新，也为后来整个游戏行业的发展奠定了基础。

另外一个书架上有许多游戏开发的书，主要都是与游戏相关的数学、物理、AI方面的书。其中有一本叫《弾幕 最強のシューティングゲームを作る！》（弹幕 制作最强的射击游戏）吸引了我。翻开一看，其实都是些公式和程序，顾名思义，就是教你怎么设计弹幕的。以前只知道很多射击游戏的弹幕很变态，原来弹幕的设计也有这么多学问…… 那些骨灰级玩家是不是都研究过弹幕的算法的呀？

开发人员工作方法

有几本关于工作方法的书不错，不过鉴于时间原因，没有细看。

1.《リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法》

• 中文版《程序员的思维修炼》
• 原版      Pragmatic Thinking and Learning: Refactor Your Wetware

2. 《ゲームストーミング ―会議、チーム、プロジェクトを成功へと導く87のゲーム》

• Game Storming: A Playbook for Innovators, Rulebreakers, and Changemakers

3. 《エンジニアとして生き方》(IT工程师的生活方式)

离2011年结束只有几小时了。就以这篇日志送走2011迎来新的一年吧！

2011年是我人生中重要的一年，因为这一年，我满30岁了。中国人说三十而立，虽然只有四个字，却着实带有分量，这一年中我有了不少变化。这些变化和经历也让今年变得精彩纷呈。

新的生活

首先，也是最重要的，在生活上，我开始学习怎么做一个父亲。不过，说实在的，我在这方面做得很不够，除了逗绯麟玩，其他很多事情都是太太在操心着，这真的非常感谢太太为这个家庭所付出的一切！不过好在在逗小孩方面，我貌似比我爹强一点（根据我妈口述的历史推断的），在怎么当一个好爸爸方面，我会加油的。

在业余爱好方面，我开始了解摄影。其实对于摄影，我本来并不是兴趣很浓，很多都是源于太太的爱好。但是当我读了Joe McNally的《瞬间的背后（The moment it clicks）》之后，我感受到了摄影的魅力，一副好的照片不仅仅定格了一个瞬间，更重要的是它承载了一种意义，试图让观众产生思考和共鸣，告诉他们照片背后的故事。于是我开始学着在按下快门的时候去思考，尽管现在还只是业余中的业余，但是我觉得我的方向是正确的，我不烧器材，最重要的限制并不是器材，而是自己。

另外，自从买了一台咖啡机，我还喜欢上了拿铁艺术，咖啡师的精湛技艺让我着迷，于是我学者自己做咖啡，了解牛奶的特性。5月份在东京还去了WBC世界冠军澤田洋史的咖啡馆，亲自体验到了大师的手艺～ 也因为如此，我知道了像星巴克这样的量产式连锁咖啡店是很少能做出像样的意式咖啡的，因为从那些店员的手势中可以看出他们大多对咖啡没有爱，他们只把在咖啡机前萃取咖啡当成日常工作。所以，要喝好咖啡，就应该找一个有barista而不是waiter/waitress的地方。就像程序员应该与程序员为伍，而要远离打字员。

新的工作

新的工作并不是说我又换工作了，只是多了些不同的工作经历。继去年的互联网社交平台之后，我依旧为公司在互联网方面的发展服务着。

在年中的时候，公司在互联网方面的战略有了变化。由于此前在社交平台方面的尝试并不是很成功，所以公司将主要方向有转回了比较稳定且熟悉的广告行业。这一变化一度使得上海分公司失去了清晰的角色定位。受此影响，上海方面的开发团队终止了很多原有的开发计划，转变为维护体制，时忙时闲。

6月份的时候，由于日本方面的智能手机出现了井喷式增长的苗头（各大厂商纷纷推出自己的Android智能终端），公司决定将传统的广告业务向智能手机拓展。机缘巧合地，我开始了iOS的开发。得到这个机会，也许是因为我此前曾提出过想尝试iOS开发，也许是没有选择的选择，因为相比之下，我实在对perl没什么兴趣。

成为苹果开发者，可以说是我职业生涯中一段奇妙的旅程。正如我在微博上所说的：“转眼已经年底了，还记得半年前复活了那台老MBP，看着CS193P，开始学写语法怪异的Objective-C的日子。那种神奇的感觉，就像15年前误打误撞地接触到了VB 4.0……” 是的，没错，我感觉自己又回到了那个充满好奇心和探索欲望的时代。

年底前，为了一个新项目，一直忙到全公司放假的那天。虽然忙碌，但是我学到了很多。趁着年假之际，我正在补习WWDC 2011的讲座，这些东西让我有了不少想法，接下来是要稳扎稳打一步一步去实现。

我们公司的工程师团队氛围十分自由，并不像传统的日本式的SI公司，大家经常会办些交流活动，业余时间大家基本也都有自己的项目。在工作的余暇，我也尝试着做些有意思、有意义的事情。

今年翻译了两本书，一本与互联网广告和营销有关，另一本与云计算平台中的应用开发有关，翻译工作确实很辛苦。幸运的是，这两本书多少都与我的工作经验有点关系，也正好能够填补我在工作中的一些知识断层。不过由于本人语言文字的基础并不是很扎实，所以语言方面还是处理得比较直白，也可能不够风趣幽默引人入胜，不知道最后反响会怎样。

在体验OS X Lion时，感觉在全屏模式的下确认输入法有些不便，于是我抽空写了isHUD，并开放了全部核心代码，后来包装了一下界面，把它放到Mac App Store上去了。尽管销售方面基本无人问津，但这整个过程让我收获颇多。也为我在明年做些业余小作品增加了不少信心。

新的朋友

要感谢微博，今年通过这个平台结识了很多新朋友。有爱好柯基的狗友，有出版社的编辑老师，有技术圈中的活跃人士…… 人数众多，在此就不一一点名列举了。要感谢这些朋友，他们跟我一起分享快乐，一起分享新的知识、探讨问题。这是互联网的力量，就像n年前网易的广告词“网聚人的力量”。

新的装备

在今年夏天，陪伴我多年的T61因显卡门问题多次故障，前前后后修理了三次，最后我放弃了，于是，我的第一台Thinkpad（可能也是最后一台，因为现在的联想似乎已经失去了对Thinkpad产品线的关注）就那么静静地躺在那儿休息，或许什么时候我还会召唤他，复活他，但不是现在。

后来，我买了一台Macbook Air，这是个称手的好工具，干活娱乐两不误。作为长期的Linux用户，切换到Mac基本没有什么障碍。

没有相机的日子总觉得缺点什么，比较再三，入了一台E-PL3（谁知相机刚到手，奥林巴斯就曝出丑闻……囧rz），用着很称手，非常喜欢这台机器。

新的坐标

8月底的时候，我来到了日本，开始了长期单身赴任的生活。

现在我住在川崎市，每天挤小田急电铁上下班，挤到什么程度我就不形容了，呵呵～

刚到日本时遇到不少麻烦，因为信用卡总是办不下来，很多东西都不方便。后来东西慢慢置办齐了，生活也渐渐步入正轨了。也请国内的家人和朋友放心，现在一切都挺好的。

One More Thing

本年度对我影响最大的书有两本，一本是之前提到过的《瞬间的背后》。另一本是《黑客与画家》，具体为什么就不说了，相信看过的人会有共鸣的。感谢图灵和阮一峰老师给我带来此优秀的作品！

2012

2012，我有很多想做的。所以，首先希望世界不要终结！

然后，就相信自己去做吧！我要不断寻找真正的自己！

最后，祝愿家人和朋友们新年快乐！健康、幸福！

原文链接：アーキテクトの選択（あるいは覚悟）

架构师的工作大部分时间都是在“做选择”，这些选择都是在一切发生之前所做出的，因此，一旦决定就不能更改了。

架构师所要选择的是静态的结构。方案一旦确定，就开始转入退化过程。随着时间的推移，系统的适应性会变差，对做出的决定进行修改往往要付出巨大的代价。

当然，项目经理对于进度计划以及项目人员体制等方面的安排也属于“事先选择”。但是，这些选择对象都属于动态的过程。

动态的过程能够随着时间的推移适应其过程中出现的变化。包括敏捷等迭代式过程在内的开发过程，它们都推荐在开发过程中设立短期目标并根据实际作业情况做出调整。这是非常有效的方法。动态过程承认事先选择中所发生的过失和偏差，且允许在事情发生之后做出改变。

有这么一说：“Good managers do things right （优秀的管理者会做正确的事）”，项目经理所做的是把握事先选择（计划）和事后情况（实际）两者之间的偏差，针对这些偏差对各种各样的参数做出调整，将项目的发展方向始终沿着预定的轨道不断进行修正。

然而，架构师的选择却是静态的结构，敏捷的推进方式无法适用于这些静态结构。

对于静态结构而言，PO（Proof of concept/概念验证）或是建立原型等“基于尝试进行评价”的方法才是有效的。PO或原型等手段能够降低风险，促成事先选择，尽管如此，要让选择后的结果能够适应事后的变化，这些方法仍然无能为力。

那么，在这种情况下，架构师该如何做出选择呢？

《软件架构师应该知道的97件事》 中有篇文章：“24：重视不确定性 ”。

Confronted with two options, most people think that the most important thing to do is to make a choice between them. In design (software or otherwise), it is not. The presence of two options is an indicator that you need to consider uncertainty in the design. Use the uncertainty as a driver to determine where you can defer commitment to details and where you can partition and abstract to reduce the significance of design decisions. If you hardwire the first thing that comes to mind you’re more likely to be stuck with it, so that incidental decisions become significant and the softness of the software is reduced.

当眼前出现两个选项的时候，基本上任何人都会将选择哪个作为最重要的事情去考虑。但是，在设计（软件也不例外）中却不是这样。出现两个选项的情况就是一种信号，告诉你应该考虑该设计中所潜藏着的不确定性。

这一篇的作者Kevlin提到“在无法做出选择时，要先停一停，退回去想想”。虽然这一点非常重要，但是在项目中，无论如何，让别人停下等是不行的。就这么等着，直到某一天做出选择，进度上就难以保证了。

正因为如此，为了做出“必须这么做才行”的决定，架构师要尽其所能地做到眼前所能做的一切，这一点就显得格外重要了。

对于不同的选择项，真正让你无从选择的原因是因为你无法确定判断的基准。因此，问题的重点在于寻找判断基准。

优秀的架构师总是能够缩小“判断”其本身对整个过程的影响。不管选择哪种架构，多少都是带着自信去选择的。但是，仅仅这样是无法得到“必须这么做才行”的理由的。

也就是说，要做出判断，不能仅凭眼前的基准，而是一定要找到某些能够起到决定性作用的参数。这些参数应该兼顾对时间和空间上的考虑。

1年后会怎么样？2年后呢？3年呢？

程序员的观点是什么？PM的观点是什么？用户的观点是什么？运维人员的观点是什么？

带着这些问题去考虑，拓展利益相关人（stakeholder）的观点，寻找用于判断的基准。单凭想象是不够的，所以亲自去了解一下各方的意见吧。这些利益相关人自身的行事原理和依据是什么？确立一个能提炼出判断基准的行动方针，去寻找答案吧！

这样，才能得到“必须这么做才行”的理由。

倘若不论怎么努力都无法得到“必须这么做才行”的理由，你一定会意识到其中所存在的不足。 这样就无法为这个选择而负责，或直面未来会产生的风险。

也许你会做出的选择并不正确。但是，一定要有“必须这么做才行”的绝对自信。为了做出“必须这么做才行的决定”而不断努力，最后选择了与自己的直觉最接近的方案，要坚定这样的想法。

如果没有这样的觉悟，是无法说服自己做出“必须这么做才行”的抉择的。不论项目的规模是大是小，架构方面的决定都将影响到与项目有关的很多人。架构师应该始终牢记这一点。

权力并不是事先给予你的，而是随着责任意识越来越强，权力会越来越大。架构师有了这种意识，无论面对谁，都能胸有成竹地回答：“这是正确的选择/这样做没错的。”

未来总是不确定的。但是，我们只能在现有的选项中进行取舍。为了做出“必须这么做才行”的抉择，要对战略方针进行推敲，而这不正是被称为“架构师”的这群人们其工作的本质吗？

isHUD v0.2发布声明

目的

作为一个多语言的Mac OS X用户，我使用系统默认的快捷键（Command+空格, Option+Command+空格）切换输入法。但是，当我按下Option+Command+空格（即选择下一个输入源）的时候，系统并不会出现输入法选择框（按Command+空格时候出现的那个列表）。当启用的Lion的全屏模式的时候，要确认当前所使用的输入法十分不便。

于是isHUD诞生了！isHUD是“input source HUD”的缩写。

有了isHUD，每当切换输入法的时候，屏幕中央就会出现一个HUD窗口，提示选中的输入法，这样，你无须移动视线就能知道所选的输入法了。

如果你想要更快捷地切换输入法，那么这篇博客也许对你有用。其中也提到了为什么要做isHUD。

相关链接

• isHUD 下载链接：isHUD-v0.2.zip
• github主页
• 中文README
• 日语README

系统运行环境

• Mac OS X 10.6.x(Snow Leopard)+

构建环境

• Mac OS X 10.7.2(Lion)
• XCode 4.2

许可证

isHUD 基于 MIT 许可证。你可以随意使用该应用程序以及相关的源码。

反馈

如果你觉得isHUD不错或是有什么问题，请发邮件告诉我 。我会进一步对其进行改进。另外，除了汉语之外，我还使用日语和英语，所以请使用这些语言发邮件。谢谢！

接下来的计划

• 把图标做得漂亮些，欢迎有灵感的朋友帮忙！
• 考虑是不是要增加一个偏好设置，增加一些自定义的设置。

工作的时候，我常常需要在多个输入法之间切来切去。

Mac默认的输入法切换是Command+空格和Option+Command+空格。虽然默认也没有什么不方便的，但是，我发现在我的键盘上有个键几乎从来没用过，那就是右侧的Option键，于是我想能不能通过这个键实现一键切换输入法呢？

答案当然是肯定的！

我找到了一个mac下的神器——KeyRemap4Macbook。这工具名称好长，确实，用起来也有够复杂的。基本上，就是一组组键盘映射规则，可以重定义键盘上任何一个键或组合键！而且还可以根据需要追加新的映射规则！

安装完成后，需要重新启动系统。然后，就能在系统偏好设置中看到KeyRemap4Macbook的图标了，点击进入后，能看到密密麻麻的预定义规则。

在默认的映射规则中寻找了一番，发现并没有一键切换输入法的相关规则。于是，决定照着官方的手册，自己写一个映射规则。折腾了一阵之后，规则就出炉了～ 切换到“Misc & Uninstall”页面，然后点击“Custom Setting”中的“Open private.xml”按钮，打开自定义规则文件。初次使用的时候，这是一个空的xml文档。将下面这段规则贴进去，并保存。

<?xml version="1.0"?>
<root>
  <item>
    <name>Switch Input Source</name>
    <appendix>Use the right Option key to select the next input source</appendix>
    <identifier>private.switch_input_source_with_right_option</identifier>
    <autogen>--KeyToKey-- KeyCode::OPTION_R, KeyCode::SPACE, ModifierFlag::OPTION_L | ModifierFlag::COMMAND_L</autogen>
  </item>

  <item>
    <name>Switch Input Source</name>
    <appendix>Use the right Command key to select the next input source</appendix>
    <identifier>private.switch_next_input_source_with_right_command</identifier>
    <autogen>--KeyToKey-- KeyCode::COMMAND_R, KeyCode::SPACE, ModifierFlag::OPTION_L | ModifierFlag::COMMAND_L</autogen>
  </item>
</root>

然后，再回到“Change Key”，点击“ReloadXML”按钮后，自定义的规则就出现在规则列表中了。

按一下右侧的Option键，输入法就成功切换了。
上面这段private.xml中还包括了一个使用右侧Command键实现输入法切换的规则，如果有兴趣的话，也可以参照官方的自定义指南设计自己的映射规则。

尚未解决的问题

由于映射的是“切换到下一个输入源”的功能，所以OS X不会在屏幕中央出现当前选中的输入法的提示信息，一帮情况下并没有什么问题，但是在全屏模式下工作时，就不太容易知道自己当前在用哪个输入法了，目前还无法解决这个问题。我正在考虑学习一下OS X的开发，做一个监听器，常驻系统，接收到输入源变换事件后在屏幕某处显示一个视觉提示。

基于上述想法的小工具已经做好啦～ 需要的朋友请看这里 isHUD v0.2发布声明。欢迎反馈！

Mac用户应该都知道，就像下面这张图片那样，Apple的键盘最顶上一排默认情况下是多媒体控制键，而不是传统PC上所使用的F1~Fx功能键，要使用功能键的时候需要配合Fn键。

对于原生的Mac应用来说，这并不成问题。但是如果像我这样时不时要用到终端（iTerm2）、虚拟机什么的，那么在这些环境中能无须使用Fn键就能得到F1~Fx键就会方便不少（比如vim的快捷键绑定）。当然，你可以通过“系统偏好设置”将功能键默认修改为传统的Fx键，不过这样的话，在Mac应用中调节音量，打开mission control什么的又不太方便了。

经过一番搜索，我找到了圆满解决这个问题的方法。答案就是——Palua，一款自动切换功能键行为的工具。

Palua的图标已经非常直白地解释了它是做什么用的了。下面就简单介绍一下自动切换功能键的设置方法。安装好Palua之后，就能在系统菜单栏中看到其状态指示图标了。

要让Palua根据应用程序自动切换工作模式，需要进入其偏好窗口增加一些配置。很简单，看图，一目了然！

首先，要启用“Smart Mode”。然后，在应用程序列表中添加需要的应用程序，再设置对应的功能键的默认行为即可。完成后立即会生效，把应用程序开起来试试，方便多了吧～

最后，别忘记将Palua设置为开机自动启动。

美中不足的是，Palua并不是免费工具，在App Store上的价码是$0.99，不过只要花不到1美元就能解决问题的话，对于有需要的用户来说也不是很贵啦，毕竟有了它确实很方便！

原文：モックによるインターフェイスの発見

引言

前几天，《Mock Roles, not Objects》一文的日语版《ロールをモックせよ（对角色进行模拟）》公开发表了。这是篇发表于2004年的论文，作者阵容相当豪华，他们是：Steve Freeman、Nat Pryce、Tim Mackinnon、Joe Walnes。另外，Steve Freeman和Nat Pryce还是《Growing Object-Oriented Software, Guided by Tests (Addison-Wesley 大师签名系列)》（即GOOS）的作者，《Mock Roles, not Object》可谓GOOS的思想根基。

在这篇文章中，我想就《Mock Roles, not Object》（以下略称为MRnO）所提到的使用Mock的基本思想，顺着GOOS的思路继续深入挖掘一下。

把Mock作为一种设计手段

首先，让我们看一下“MrnO”中介绍的范例的具体代码（不过，这篇博客中的范例代码已经将“MRnO”中的范例移植到了jMock2上）。我们要实现的功能如下：

对于一个用于加载对象的框架，利用键值进行查询，要考虑将搜索结果缓存起来的做法。对象加载后，经过一定时间，其实例会无效。因此，需要经常重新加载对象。

Mock Roles, not Objects（p.7）

首先，写一个简单的正常处理。

@Test
public void 加载未缓存的对象() throws Exception {

    final ObjectLoader mockLoader = context.mock(ObjectLoader.class);

    context.checking(new Expectations() {
        {
            oneOf(mockLoader).load("KEY1");
            will(returnValue("VALUE1"));
        }
    });

    TimedCache cache = new TimedCache(mockLoader);
    assertThat((String) cache.lookup("KEY1"), is("VALUE1"));
}

上述代码的行为是这样的：调用cache.lookup()的时候，会调用传入TimedCache构造方法的mockLoader对象的load方法，这时，mockLoader会返回“VALUE1”，所以lookup方法的返回值也是“VALUE1”。要点在于，这个时候，我们已经发现了ObjectLoader这样一个协作对象（邻接对象）。就如下图这样：

这里要补充一点，虽然ObjectLoader在这里是一个mock，但是并不能认为它是一个通过外部资源访问的对象，或是由第三方类库所提供的对象。为了让测试目标能够工作，一边写测试一边发现其必要的协作对象，这是以mock为基础的TDD过程的核心思想。
然后，第二次调用cache.loader()方法时，应该直接访问缓存而不是再次调用ObjectLoader，这样的测试也是必须的，因为只是重复了一下断言语句（asertion），所以就不在此重复其代码了。实现了缓存后的代码如下：

public class TimedCache {

    final private ObjectLoader loader;
    final private Map cachedValues = new HashMap();

    public TimedCache(ObjectLoader loader) {
        this.loader = loader;
    }

    public Object lookup(String key) {
        if (!cachedValues.containsKey(key)) {
            cachedValues.put(key, loader.load(key));
        }
        return cachedValues.get(key);
    }
}

接着，我们再引入时间的概念。需求中提到：“对象加载后，经过一定时间，其实例会无效。因此，需要经常重新加载对象。”与之对应的测试代码如下：

@Test
public void 超时后重新加载缓存中的对象() throws Exception {

    final Clock mockClock = context.mock(Clock.class);
    final ObjectLoader mockLoader = context.mock(ObjectLoader.class);
    final ReloadPolicy mockPolicy = context.mock(ReloadPolicy.class);

    final Timestamp loadTime = new Timestamp("2011/09/17 00:00:00.000");
    final Timestamp fetchTime = new Timestamp("2011/09/17 00:00:01.000"); // 1秒后
    final Timestamp reloadTime = new Timestamp("2011/09/17 00:00:02.000"); // 2秒后

    context.checking(new Expectations() {
        {
            exactly(3).of(mockClock).getCurrentTime();
            will(onConsecutiveCalls(returnValue(loadTime), returnValue(fetchTime), returnValue(reloadTime)));

            exactly(2).of(mockLoader).load("KEY");
            will(onConsecutiveCalls(returnValue("VALUE"), returnValue("NEW-VALUE")));

            atLeast(1).of(mockPolicy).shouldReload(loadTime, fetchTime);
            will(returnValue(true));
        }
    });

    TimedCache cache = new TimedCache(mockLoader, mockClock, mockPolicy);
    assertThat("被加载的对象", (String) cache.lookup("KEY"), is("VALUE"));
    assertThat("缓存中的对象", (String) cache.lookup("KEY"), is("NEW-VALUE"));
}

这里就能看出使用mock的TDD过程中的单元测试与普通的TDD过程中最大的不同点。普通的TDD过程中，是通过“红灯、绿灯、重构”，尤其是“重构”，渐渐提炼出这样的协作对象的。首先是要让代码能够执行，其次再考虑合理分配对象的职责。

与此不同的是，使用mock时，在编写测试的阶段，也就是“红灯”状态之前就已经出现协作对象了。实际上，按部就班地尝试一下你就会发现，如果测试目标和协作对象之间的交互行为不考虑清楚的话，是没有办法写测试的。

也就是说，使用mock进行测试驱动开发时，写测试的过程亦即设计的过程。但是，在这个过程中所做的设计只有对象之间的交互行为，而没有出现类的概念。“那么，该如何设计类呢？”出现这样的疑问是理所应当的，看了GOOS后就会明白，书中采用的方式是先临时用匿名类实现接口，以后再为这些匿名类附上合理的名称，提炼出类。通过这种方式所提炼出来的类，如果仍然觉得其内部的职责比较模糊，那么就要再次写单元测试，发现其中的协作关系，如此反复对类进行精炼。

首先写验收测试

这也就是为什么将这种方法称为“由外及内”的理由。从离外部（即系统的入口）较近的地方开始些单元测试，一边寻找接口，一边向系统内部深入。要这样做，当然会对“首先从哪里开始入手写测试”产生疑问，答案就是“首先写验收测试”。用图示来说明的话是这样的吧：

实际上，为了通过验收测试，有两点是必须的，一是要边写单元测试边寻找接口，二是要对职责含糊不清的类反复进行单元测试和提炼，这是一个二重循环。乍看之下，验收测试和单元测试是完全不同的过程。但是，使用mock的单元测试，既需要考虑与对象之间交互有关的内部关注点，同时又需要考虑让系统整体正常运作的外在的明确意图，从这两点必要性去考虑的的话，这两个关注点能融为一个过程，这样的想法也就顺理成章了吧。如果把“验收测试+使用mock的单元测试”作为一整套过程去考虑，写单元测试的行为本来就相当于重构中的一个环节，也许这么说也不为过吧。

而且，从验收测试开始入手这样的想法，与行为驱动开发（BDD:behaviour-driven development）之间有很强的亲和力。也就是说，问题变成了“用测试来展现系统该做什么”，这样，该从哪里开始入手、一个特性怎样才算完成，同时就能对这两个问题给出答案了。

总结

对于开发人员而言，通过编写代码发现系统架构的过程，确实感觉非常振奋。但是就现实问题而言，对系统一无所知就开始入手，何时怎样才算终点也一无所知，确实会有这样的恐惧感。所以，事先进行一定程度的分析及设计，对系统大体上的组成设立目标是有必要的。要避免饱受批判的“Big Design Up Front”，掌握好事先分析及设计的平衡感是很重要的啊。（这些工作能让你事半功倍）。

对mock有兴趣的读者，一定要看看《Mock Roles, not Objects》。除了本文中提到的思想外，原文中还有许多重要的启示。另外，点击这里可以下载本文中的源代码。

译注

1. 原文链接
2. 《Mock Roles, not Objects》原版
3. 《Growing Object-Oriented Software, Guided by Tests 》（即GOOS）已经引进，中文版名称是《测试驱动的面向对象软件开发》
4. 图示部分的没有翻译，给出图中用于的对照表：
   • テスト 测试
   • 受け入れテスト 验收测试
   • ユニットテスト 单元测试

入手了一台心仪已久的MBA， 因为硬盘比较小，所以打算入一台NAS。因为用了Mac，所以想找款支持Time Machine的。比较了一下，发现Synology的DS110j是比较理想的家用机型，外形好看且功能齐全，可就是买起来不方便，所以只能选了第二方案——Baffalo的Linkstation ls-v1.5tl。后者整体上也还不错，唯一比较遗憾的是没有内建电驴的支持，也许是因为日本国内对电驴的争议吧。

但是，没关系，这种小问题是难不倒爱折腾的人们的～ 我就自己动手丰衣足食吧！

Google了一下，发现LS系列的NAS很早就有了，相关的改机方案也有许多，甚至还有专门的改机wiki。总体上有两种方案：保留原有的固件，在此基础上安装新软件；彻底改用第三方固件，和厂商说拜拜。鉴于原厂的固件对OS X Lion新采用的AFP 3.3协议支持良好，我也不是什么改机控，于是就选择了前者。虽然简单，可没想到还是折腾了一下午，期间几乎搜遍了google，就流水账地记录一番吧。

首先，就是要开启sshd服务。虽然都要使用acp_commander.jar，但在LS-VL系列上，传统的方法已经无效了，好在官网给出了详细的指南，照着做就能顺利通过ssh登录了。

登录后，安装mldonkey就可以了，原本以为这步很简单，可实际非常不顺利。我先是按照官网上给出的简单方法，尝试安装现成的预编译包。结果却始终无法启动，经过一番搜索，发现了这篇自行编译mldonkey的指南。立即动手，安装了ipkg和编译工具，配置源代码，开始编译，经过长达1个多小时的编译，总算完成了，结果一运行，出现segmentation fault，再搜索也没找到什么线索，顿时头皮发麻……

没办法，再装上gdb，用backtrace找到了出问题的地方，居然是libcrypto++的问题，又是一阵狂搜，又找到一篇博客，今天运气不是一般好啊～ 照做，运行下面这段命令进行配置和编译

$ CXXFLAGS="-DCRYPTOPP_DISABLE_ASM" ./confgiure
...
$ make

又经过漫长的编译，终于启动了mlnet！

服务器启动后，接下来就好办了，打开浏览器，对设置稍作调整就完成了。