1. 很早以前有个日本作家来上海“放荡形骸”了一番，回岛国后写了本叫《魔都》的书，记录了那段时间在上海的各种腐败体验。于是现在上海不情不愿地被冠以了“魔都”的称号。相对于魔都上海，我们还有帝都北京、妖都广州。我居住过的另一座城市南京也有个叫魔都的称号，所以一般称南京为小魔都，上海为大魔都。而无锡又不情不愿地被称为“小上海”，所以我从无锡滚到南京，再从南京滚到上海，就是从小小魔都滚到小魔都再滚到大魔都的过程。
   
2. 网上流传着一篇很长的叫《魔都生存指南》的东西。作为一个标准吃货的作者，花了百分之四十的篇幅介绍了上海的公厕、语言、建筑、交通、气候、治安、休闲、购物等方面，剩下百分之六十的文字都用来介绍各种边边脚脚的腐败去处。作为一名偏居魔都东部小镇的IT民工兼吃货，只能含泪将网页收下，放入“以后再看”的文件夹中。有个地方我倒是天天可以经过，可以去试试：
   

   魔都生存指南：张江地铁站美食点评特别篇–好吃的芝士蛋糕和面包“毂屋”其实真不需要多介绍了网上对他家的芝士蛋糕好评太多了，中午的意面或者三明治套餐也非常棒。特别推荐袋包装的野生酵母面包，发的不是很蓬松特别好吃，下班顺便带一袋回去吧

   魔都生存指南：张江地铁站美食点评特别篇–地道的台湾小炒“龙门客栈”算是地铁站里比较精致的一家饭店了，比费尼阁要好吃不知道多少，基本上在张江中餐也就百草的味道可以和他比一比了，但是价格就划算大多了。我特别推荐一个菜单上没有的–九层塔菜圃蛋

3. 我住的那地方和生存指南没什么关系。周围有跟你同样的一大群人，和你揣同样的梦想，同样的早起，去同一个包子铺买肉包，挤同一辆公车，盯着同一个漂亮姑娘看，脸上都写着牛逼或装逼，流同样多的汗，进满是IT民工的企业，对着同样尺寸的显示屏，吃同样价格的便当，加同样时间的班。偶尔会坐地铁去趟城里或回趟家，偶尔错过了最末班公车跟人拼车打的或坐小黑车，偶尔去小饭馆腐败下，偶尔自己买三两小菜小试牛刀。这里不需要什么生存指南，生活在这里，就好像是你站在原地不动，人群也会带着你去买包子挤公交上班，而你如果稍不留神的话，会发现，咦，自己又满身臭汗地回到家了。人群会指着你一路向南的。
   
4. 说到生活，其实我想说“生活在拉稀，而我在便秘”。用这两个吸引眼球的词语无他意，只是想说生活节奏有点快，我有些不适应，思维有些阻塞。也许原来在南京懒散惯了，享受惯了上班只要走五分钟的轻松，可以打一天酱油毫无愧疚感的惬意。其实现在这样真是好事，要学游泳还是要去深水区学，在儿童区打打闹闹是学不会的。王朔的小说《橡皮人》描述过这样一群在都市生活的年轻人，他们如同工艺品，“被高高在上的观赏者轮流捏拿玩弄，被生活的泥匠用压力捏成各种形态”。我想我是不会成为橡皮人的，要做就做弹簧人。
   
5. 如果每个人都是在自己的那条船上漂，如果那些点点滴滴的小事那些说过的云飞雪落不经意却记得的话是海上的风，那么一个人不属于平静的情绪便是由风吹起的浪花了。如果浪涛的拍打让坐船的你左右摇摆翻江倒海，如果你架起双桨劈风斩浪，如果你足够幸运很快迎来风平浪静，你拍拍胸脯骄傲地说，也就这样嘛。这时候你转过身发现，自己早就不在原来的地方，那些风和那些景一去不复返。然后你笑了，站在船头高唱“两岸猿声啼不住，轻舟已过万重山”。唱完，然后你泪流满面。
   
6. 一个人一生到底会有百分之多少的时间花在路上。去学院自习室的路上，去厕所的路上，去汇杰广场的路上，去张江高科地铁站的路上，去喜欢的姑娘楼下的路上，去火车站北广场的路上，去玉兰四期家乐福买烤鸡的路上，去孟猪家蹭饭的路上，去茶水间泡杯饮料的路上，去超市买柠檬的路上，去邮局拿家里寄过来的被子的路上。知道了这个比例，我估计自己会蛋疼菊紧发誓珍惜时间云云。可是人活着并不是目的而是个过程，在路上也是属于这个过程的一部分，而不仅仅是为了达到一个目的。身体在赶路，脑子不一定要跟着赶路。
   
7. 我想成为什么样的人。人傻，钱多，很多很多的钱。和人讨论PS3, iPhone, iPad, iMac, Wii, 蓝光，背投，机械鼠标，概念鼠标，GFW，宽带山。穿大裤衩人字拖，读GReader南方周末上推特，去哪都扛个iPad N代。征婚时介绍：人傻，钱多，速来。
   
8. 毕业之前我想我会一个人出去旅行一次。要去就去远一点的地方，问谁借个单反装下样子，抓个破一点的包，要是iPad 2已经出了，买了塞包里，再塞两件衣服。多走路，多看，多拍，多吃。想想就来感。
   
9. 没想到米兰昆德拉30多年前就帮我拟好了文章的题目。拿来一用，倒也切合现在的生活。现在是生活在别处，我希望将来能够变成生活在别墅。等到风景都看透，也许会最后回去看看细水长流。

　　胸中那可爱的洪水猛兽们，拿早点醒过来好伐啦~

1. 科健——这是我上初中时爸爸用的手机，可能是他的第一部手机，也是我玩过的第一部。网上已经不可能找到图片了，找了张样子相像的放下面，不过颜色是黑色的。
    
   特意查了下，科健公司在1984年就成立了。当时貌似科健还不错的，现在还不知道有没有人去买了。这玩意麻雀虽小五脏俱全，不像现在有些手机啥功能都有就是不能打电话（我不是说iPhone4）。窄窄的蓝色液晶屏幕，按键饱满，音量适中，质感柔和，机身呈流线型……可惜早已断货，不然实属馈赠亲友之上品。此手机第一次让我感到了科技的力量，因为它所具备的语音拨号功能是当时计算机白痴的我前所未见的。虽然爸爸经常对着喇叭喊半天它也识别不出来。
2. 熊猫——爸爸用的第二款手机，我高中时候他用的，是翻盖手机，16和弦。当时觉得从单调的电子音过度到和弦太酷了，这款手机肯定特牛逼。以至于高考结束后的日子还带着它出去参加各种同学聚会，太囧了。样子大概是这样：
    
   貌似熊猫现在倒闭了吧，搜出来两个像官网的网址都打不开，淘宝上搜熊猫手机也没有卖的，这张图也是找了好久才找到的一张。
   对它的记忆并不多，现在只记得它爽朗的铃声了。但是看到它就会想起高中那段青葱岁月。
3. 迪比特——高中里妈妈用的手机。通体红色，信号不好，响应慢，系统落后。现在只记得来短信时那一短促的嘀声。网上找到了它的图片：
    
   妈妈用的第一部手机，舅妈给她的，她没买过手机，现在用的都是爸爸和我用下来的手机。她用手机的目的有两个，一个是给我发几个字提醒我注意身体，一个是带在身上方便我和爸爸找她。
4. 松下X300——属于我自己的第一款手机。高考结束后买的，当时价格是2500左右。可以翻开屏幕拍照摄像。样子如下图：
    
   我用它用了两年，最后被我自己忘在了软院的自习室里，第二天一大早赶过去发现已经没有了。那一个月是我本科时最倒霉的一个月，连着丢了两个手机，自行车轮胎被人拆了，教材被人偷了，笔记本被人偷了。
   我挺喜欢这手机的，外观小巧，五官精致，拍摄有dv的感觉，唯一的缺点是不是诺基亚系统。当时周围人都是诺基亚，觉得自己从来没用过手机中的王者及传说中的塞班系统，还是有些羡慕的。所以最后手机丢了也不是很心疼，囧。。 这款手机不支持数据的导入和导出，所以没法把里面的短信导出来，铃声也只能用GPRS下载。我记得大一刚刚进大学，还没开始上课的那段日子里，我经常拿着我的手机，跟yxy一起校园里到处乱转，手机里装上唐伯虎点秋香里周星驰烤鸡翅膀的那段很聒噪的音乐，两个混球走到星湖边，往湖边看星星看月亮的情侣堆里一屁股坐下来，很拉风地拿出手机，很拉风地调大音量，轻巧地按下播放按钮……
5. 诺基亚3110E——这款就是上文提到的那个杯具手机。
   
   松下被偷后，父母都很不悦，我也有些愧疚就买了个便宜点的诺基亚，1100左右。打算用到大学毕业再说吧。可仅仅10天就在回家的公交上被摸走了。我和另一个同学大包小包挤159去南京火车站，我手机就放在上衣的口袋里，满腔的回家热情，毫无戒备的心理，终于让我献出了处女被偷手机经历。从此以后，我就只买那些有内袋的上衣了。
6. 三星SGH-Z150——那个月被偷了两个手机后，我老老实实去国网三百块钱拿了个这个。好像还送了多少话费。
    
   虚荣如我，上课时都不好意思拿出来放桌上，忍辱负重地过了段日子。它也是命途多舛，从我手中到了我妈手中，现在又轮回般回到了我身边，活得还好好的。当然是静静躺在我的G3身边，插了张可以报销话费的卡，充当专用的电话机。
7. 诺基亚5700——传说中的变形金刚。这是我感情最深印象最深刻的一款手机。要不是被我摔得摇杆坏了，修过一次还是不行以后，我才不会想用G3去代替它。它是这样子的：
    
   我第一次用上了真正意义上的智能手机。其实我对手机的要求不高，除了基本的两个功能外，有关机闹铃，能看电子书，能导出短信，数据传输，简单的备忘录。感谢它陪伴了我的考研生涯、本科最快乐的时光和在鼓楼的那段日子。
8. G3——现在用的。还没研究过。以后可以写点Android程序放进去玩玩。我也挺喜欢的。
   
   这一年我还碰到了一个让自己心动的女孩。

Android2.2（开发代号：Froyo）是个次要SDK版本，但它仍然很有影响力，给开发者及用户提供了一些期待已久的特性。在参加了Google I/O会议，见证了Froyo的宣告之后，我们认为有10个特性（排名不分先后）是开发者最迫不及待跃跃欲试的。

1.Flash10.1及AIR支持
对于手机上Flash的可行性可能有一些争议，但它即将登陆Android手机。未来是否属于Flash真的不重要，眼下看来，Flash在web上相当流行，因此排斥Flash实际上就相当于排斥了许多用户已经乐在其中的动态web应用。
从Froyo版本开始，Android用户将能够从Android市场下载Flash10.1及AIR支持（以Android应用程序的形式）的公开测试版。这个决定实质上扩大了Android用户可访问的web应用和站点的数量，扩大了Android开发社区的队伍。
然而这也可能成为Android开发者的一把双刃剑。这将如何改变Android市场的内容呢？外面有那么多的Flash应用（如德州扑克，每个人都有吧？），谁还会去创建一个本地Android应用版本呢？好吧，理由当然是能想出来的，但是我们认为这样一来，很多公司要有足够的理由才会去创建本地应用了，因为本地应用需要他们针对不同平台满足客户要求。也许Flash应用可以帮助清除掉那些写得糟糕的本地Android应用程序的竞争，但它能够增强Android开发社区的整体实力吗？让我们拭目以待吧。

2.推送消息
开发者现在可以利用谷歌的另一项服务了，即Android Cloud to Device Messaging(C2DM) 框架。这个框架提供了一项服务可以通过谷歌的服务（负责发送至设备的轻量级消息的排队以及安全交付）使Android设备支持有限的推送功能。在解决框架问题的同时，开发者可以在Google Labs网站上注册。谷歌的一些应用程序，例如Web版的Android Market将很快使用这个特性把用户通过Web购买的Android应用程序通过无线电推送至手机上。这项技术能帮助解决目前由Android应用程序产生的严重的轮询拥堵问题（导致电池寿命减少、性能降低等问题）。

3.全新的企业级特性
Android终于将自身定位于重要的企业级应用了。Android2.2 SDK包括了全新的设备管理API，用于远程设备管理和设备的安全管理。你可以看到用来管理设备安全的API，包括密码策略实施、远程锁定及抹除设备的能力。举个例子，如果有员工丢失了他或她的带有敏感数据及凭证的手机，手机会迅速锁定并清除掉那些数据。
Froyo还引进了健壮性更强的Microsoft Exchange支持（见第9个特性）。我们也听到了一些关于类似Android市场的企业及部署方案的声音，但这些特性可能以后会有的（Froyo中没有）。

4.性能提升
开发者和用户能够从Froyo巨大而深远的性能提升中受益。谷歌的那些极度追求质量和性能的极客们似乎曾经把这个平台贬作“垃圾”（这个词是从谷歌哥们那里听来的，意味着很差的性能和响应性），并在后台内置了很多性能的测量仪和基准。这种急需的性能大检查最终诞生了一个更为流畅简洁的活跃平台，以及一份保持平台今后也同样简洁快速的计划。
性能的提升部分原因是Dalvik虚拟机中包括了一个JIT编译器。据谷歌Android团队所说，Froyo运行时的性能比之前的Android平台快了2到5倍。你可以在应用程序的Android清单文件中关闭JIT优化。Android浏览器由于使用了V8 Javascript引擎，速度也显著提升，比起Android2.1浏览器在性能提升了2到3倍（见第10个特性）。

5.声音和媒体API改进
随着Froyo版本的发布，人们也提出了很多关于Android媒体API的问题。举个例子，其中加入了声音聚焦API来管理竞争应用间的声音播放规范。声音池API也进行了更新，其中加入了一个回调函数当某项加载完毕时调用，也融入了暂停和继续所有流的能力，这样应用程序不再需要跟踪每个流的状态，也不需要在单独的流上进行操作。这些改进简化了实现，提高了效率。

6.全面的SDK改进
许多Android API加进了2.2发布版中。图像和游戏开发者们将为OpenGL ES2.0及ETC1向量纹理压缩的支持而欢呼雀跃。像语音识别（android.speech）这样的服务取得了实质性的进展，其他一些如支持拍照和摄像的API也改进很多。全新的UI模式管理器（android.app.UIModeManager）服务能将设备的配置调整为支持夜间模式、汽车模式以及桌面模式（停靠状态）。（译者注：最后一句不会翻）
从Android2.2开始，应用程序不光可以安装在主设备上，还可以安装在SD卡等外部存储上。Android应用还可以使用全新的通用数据备份服务让用户无缝地在Android设备间迁移。
就合理但令人沮丧的API变更来说，布局属性fill_parent已重命名为match_parent（是的，目前还不会影响你原有的那些应用程序）。通过使用按照DropBoxManager的形式且基于blob的“logcat”风格的数据队列，调试功能甚至也得到了改进。这份列表还会继续。（译者注：猜想意思是还有很多SDK的改进之处，就先不列举了）

7.Android市场更新
随着Froyo版本的发布，Android市场也有不少更新。对发布者而言最有用的新特性之一便是内建的错误报告了。如果你的应用程序在用户的手机里崩溃了，用户可以选择是否将错误报告通过Android市场发回给相应的发布者。这样开发者和用户之间便形成了一个反馈的良性循环，使得发布者可以设法解决问题（可以收到有价值的崩溃诊断信息，比如设备配置和堆栈跟踪），避免被打低分。

让我们始终把Android开发者和用户放在心上。除了大家所期待的性能改进以及加入到Froyo平台中的“Chrome”浏览器外，Froyo中还有很多让人欲罢不能的用户特性，比如：

8.数据系链及便携式热点
Froyo发布了USB数据系链和将Android设备变为便携式Wi-Fi热点的功能。这是个很酷的特性，但我们不清楚有多少使用者/携带者会隐藏且/或关闭此功能，因为有些人已经在竞争者的平台上实现了类似的特性。如果不得不让我们来猜的话，我们觉得这是个迷人的特性，也许能够增加Android的使用者数量（尽管每天增加100000个新用户，对Android来说还不算太差），但如果这群用户无法在他们的航程中使用这个特性的话，也很有可能让他们感到失望。我们走着瞧吧。

9.Microsoft Exchange支持
没有人会喜欢根据工作用途还是私人用途等不同的使用目的来在不同的手机间捣腾。有相当一类人由于他们公司的IT需求–显而易见是对Microsoft Exchange的支持，在选择他们的手机时觉得捉襟见肘。（坦白说，如果手机不支持Microsoft Exchange的话，我们都不好意思称之为“智能手机”，但这仅仅是我们的观点。）
Android2.2包括许多新的Microsoft Exchange特性，比如：

• 增强的安全特性，允许管理员强制密码策略
• 对Exchange管理员来说，在设备丢失或被盗时可以远程抹除其数据
• Exchange日历支持目前已和Android日历应用相兼容
• 使用自动发现简化账户建立及同步
• 使用Microsoft Exchange Global Address Lists使Android Email支持自动补全收信人姓名及地址

10.“世界上最快的移动浏览器”
在Google I/O主题会上，谷歌全球副总裁Vic Gundotra宣布Android2.2使用了全球最快的移动浏览器。他用行动来证明一点，他让iPad浏览器和Android浏览器在一个基于SunSpider JavaScript标准的比赛中“赛跑”（之后甚至让iPad浏览器先跑，在这里可以尝试下）。不管这是不是一个公平的比较，大家都接受了这么一个观点：对Froyo的性能改进使它变得速度奇快。Android浏览器的性能让大家都很开心（好吧，竞争对手除外…），随着HTML5的成熟会得到大家的认可。

好啦！这些就是让我们迫不及待想得到的Android2.2特性了。你们的看法呢？新的SDK可以通过更新机制来下载，更多的信息可以在Android2.2平台主页上找到。

=================================================================

简介

撰写技术文档比较困难，而阅读一份糟糕的技术文档就更加困难了，甚至可能比写文档还要痛苦。写出一份清晰准确、引人入胜的技术文档是要投入很多精力的。因而为了让人们省点事儿，我将与你们分享我在创作一份技术文档时遵循的7条规则。我并非自个儿想出了这些规则，而是得益于我与许多有才华的技术文字编辑长达十多年的共事。我所理解的这些都源自于他人为我指明了道路，我万分感谢他们。
我希望在读完这篇文章以后，你在自己的技术写作工具箱里又多了一些利器，它们能帮助你创作出更清晰、更吸引人、更易懂和更有趣的技术文档。我还为大家在结尾额外附送了一段内容，介绍了我创作一篇技术文档的过程。
好吧，下面就是这7条规则：

1. 枯燥即糟糕
2. 在开始之前，搞清楚你想要你的读者读完你的文章后能做什么
3. 始终按照形式良好的提纲来写
4. 避免不明确的代词
5. 清晰性=图示+文字
6. 当处理概念时…逻辑图示及例子，逻辑图示及例子
7. 拥抱修改

1.枯燥即糟糕

这也许是最难成文的一条规则，也是最重要的一条。当今的因特网世界有太多的东西可以抢走你读者的目光。乏味、平淡的文章是不行的。不论好坏，你的读者在长见识的同时需要被娱乐。因此，如果你的文章难以理解且了然无趣，读者便会直接点那个传说中的“下一页”按钮，去看另一个网页、另一个电视节目或者他或她的Facebook页面。
我发现能娱乐读者的最简单的方法是先娱乐自己。为了总能写出一篇我自己想读的文章，我做了很多努力。我写作时力求做到心情愉悦。如果我感到厌倦，读者也会厌倦。如果我感到困惑，扶着也会困惑。如果我不真正在意手边的话题，读者也不会在意。就是这么简单。
我喜欢幽默，所以在力保清晰性的同时我尽量使我的文章有幽默感。我在文中尽量和读者对话，而不是向他们喋喋不休。我写的话题都是自认为重要的。为了避免使读者困惑，我大量使用图解说明。
再说一次，我尽量使阅读体验总是有趣。我一直清楚自己是在一个充满竞争的环境里写作。外面充斥着大量内容，会分掉我的一杯羹——读者。因此，对于规则1我的建议是，如果你的文章对你来说是有趣的，那么对读者来说也是。

2.在开始之前，搞清楚你想要你的读者读完你的文章后能做什么

技术文章是要对读者阅读后的行为产生影响的。读者之所以花时间来阅读你的作品是因为他或她想在阅读之后有能力做某些事。这些事可能是学着制作手工巧克力曲奇，关闭一个核反应堆或者启动Hadoop cluster。你要记住的是，读者把你的文章作为实现他目的的一种手段。你的文章是通往另一个定义良好的行为的媒介。
因而，搞清楚你想要你的读者读完你的文章后能做什么，你会从中获益的。在开头便说明你的意图，不要让读者来猜。你可以像这样来简洁明了地声明：“在读完本文后，你将能够[在此填空]。”如果很清楚你想要你的读者读完你的文章后能做什么，你写起文章来就会觉得越发容易。

3.始终按照形式良好的提纲来写

形式良好的提纲是你文档的骨架。写技术文档如果不用提纲，就像不用地图在纽约地铁系统里寻找方向。你可能最终到达任何一个你并不想去的地方。
按照形式良好的提纲来写并没有增加你的工作量，反之能帮你省事儿。当你按照提纲来写，你很清楚你已经写了什么以及你将要写什么。
我有两个一直使用的写提纲的规则：

1. 子层次的话题至少需要两个。
2. 任意一个提纲层次至少需要两句话。

请允许我娓娓道来。下面的列表1是一个提纲示例，它违反了规则1：子层次的话题至少需要两个。

列表1：一个形式糟糕的提纲
1.制作一个Orange Cranberry Tangerine Fizzle（译者注：某种饮料，不会翻译，下同）
1.1.制作Fizzle的步骤
1.1.1.准备配料
1.1.2.混合Fizzle
1.1.3.端上Fizzle

注意，在列表1中，层次1有单一的子层次1.1-制作Fizzle的步骤。这种结构违反了规则1。为了使子层次形式良好，必须至少还有一个对等的话题。换句话说，这意味着任何一个给定的层次必须有至少两个子层次。
请看下面的列表2。注意现在层次1有了三个子层次，其中，混合Fizzle这个子层次现在有了其对等层次。制作Fizzle的步骤这一单一层次现在被删除了。
你可能会问：“制作Fizzle的步骤这一话题去哪里了？”答案是该话题已经不再是提纲项了，而是其父话题的内容了，如下面的列表2所示。

列表2：一个形式良好的提纲，但违反了两句话规则
1.制作一个Orange Cranberry Tangerine Fizzle
下面的段落描述了制作orange cranberry tangerine fizzle需要遵循的过程。
1.1.准备配料
1.2.混合Fizzle
1.3.端上Fizzle

请注意，虽然列表2展示了有正确子层次结构的提纲，但层次1的话题内容只有一句话。提纲的话题内容只有一句话违反的是列提纲的第二条规则，任意一个提纲层次至少需要两句话。
下面的列表3展示了将Orange Cranberry Tangerine Fizzle这部分调整到支持两句话规则以后的样子。

列表3：一个形式良好的提纲，且支持两句话规则
1.制作一个Orange Cranberry Tangerine Fizzle
在炎炎夏日，Orange Cranberry Tangerine Fizzle是招待朋友的必备。该饮料取材天然，不加人工香料。Orange Cranberry Tangerine Fizzle不光味道好，对身体同样有益！
下面的段落描述了制作orange cranberry tangerine fizzle需要遵循的过程。
1.1.准备配料
1.2.混合Fizzle
1.3.端上Fizzle

为什么我要如此强调恰当的提纲结构以及每个层次至少两句话呢？首先，遵循子层次规则迫使我对自己文章的逻辑分段做到心中有数。子层次规则也可以确保我的文章以一种有意义且简单的方式传达出我的观点。
其次，两句话规则迫使我创作出引人入胜、详尽而有意义的文章。“一句话”文章常常缺少细节。并且，除了俏皮话喜剧之外，“一句话”风格的文章读来不会是最有趣的。

4.避免不明确的代词

不明确代词的引用可能是技术写作实践中造成困惑的最典型的原因了。
考虑列表4中的段落。

列表4:一个有不明确代词的段落
Trafalgabors（译者注：故意没翻译，也没法翻译）是Weebietatas（同上）框架的基本组件。本文将介绍它们是什么，以及如何使用它们。

上面这个段落看起来有些可笑，但说明了一些要点。首先，此段落尝试把你放到一个读者的位置上。读者想要理解发生了什么事，但他对语言不熟悉。并且因为对语言不熟悉，读者感到自己既无知又脆弱，想要一些新的信息，他或她要变得更聪明些。但是读者同样有些焦虑。承认自己的无知，即使是对自己，即使在潜意识里，也会令读者感到不安。读者的认知能力是经不起折腾的。一些对作为作者的你来说理所当然的概念和单词可能对于读者完全陌生。一个解释得糟糕的概念或一个没有正确说明的单词就可能使读者感到厌烦。（译者注：作者这段不知道有没有逻辑，反正我是没看懂）。
至于上面的那个段落，我不奇怪有人会问：“什么是Trafalgabor？什么是Weebietata？这一段说的是什么？怎样使用Trafalgabors？怎样使用Weebietatas？它们两者怎么使用？太难以理解了，我还是回去看我的Facebook主页吧。”
如果读者要从阅读你的文章中抽出时间来想你究竟要表达什么，那么说明你解释得不够，读者很可能会陷入困惑。一旦你使读者困惑了，你就输了。世界上其他需要读者注意的东东便趁虚而入，抢走读者对你作品的注意力。因此，他们按下“下一页”按钮，你的作品便无人问津了。
在上面的列表4的例子里，困惑是由不明确地使用了代词——第二句中的“它们”造成的。“它们”指代的是Trafalgabors，是Weebietatas或者是两者？请记住，读者对Trafalgabors或Weebietatas一无所知。（请见下面的图1。）

图1：使用不明确的代词使得技术文章令人困惑

解决该问题的办法很简单。请看下面的列表5。不明确代词移除了。段落又恢复了清晰性。

列表5：不明确代词的改进方案
Trafalgabors是Weebietatas框架的基本组件。本文将介绍Trafalgabors是什么，以及其如何使用。
小心！不明确地使用代词是通往难以理解的技术文档的地标。

5.清晰性=图示+文字
 
请看下面的照片。告诉我此图啥意思？

我并不惊奇于你的困惑。这是张令人费解的照片。你认识里面的每一样东西，但你就是不知道它们是什么意思。这就是图示的本质。一张没有文字说明的图片是缺少上下文语境的。
当提到图示，读者需要上下文语境来避免困惑。读者不应该浪费时间和脑细胞来猜想图表是什么意思。避免难以理解的图示的最简单方法就是给图示加一个标题。
请看下面的图2。同样一张图，现在就没有疑问了。
图2：制作Orange Cranberry Tangerine Fizzle需要的工具和配料

当涉及到技术写作，我发现给所有图表加上有序的、说明性的标题是一个好习惯。
请不要仅仅创建标有序号的标题。序号和描述性注解都要使用。同样地，要避免使用孤儿图示。孤儿图示是指一张出现在技术文档里而在文中却没有引用指向它的图示。
如果你在文中插入了一个图表，确保在文中引用它，使用图片序号以及类似“上面的”和“下面的”这种词语所描述的位置。你不会想要读者从阅读你的文章中抽出时间来将图表和文章关联起来，或者在你文中定位一个图表的位置。如果你在文中加了一个叫“图4”的图，那么请确保你的文中有类似这样的句子，“请参考下面的图4”。
注意：眼睛会被图片所吸引
十年前我在一个给一家很大很大的计算机生产商写硬副本用户手册的组里工作。所有的手册都要遵循正式的定量可用性研究。用户体验博士们教给我的东西之一便是当一个人读一份文档时，读者的眼睛会首先注意到图片。然后读者才去读图片周围的文字。因此，手册的作者一直确保手册的每一页都至少有一张图片。

6.当处理概念时…逻辑图示及例子，逻辑图示及例子

概念是难以理解的…这就是它们被称为概念的原因。因此，当我需要解释一个概念的时候，不管它是什么，热力学第二定律也好，一种编程技术也好，或者某个成熟的软件框架也好，我都在写作中使用以下的模式：概念-逻辑图示-例子。我试着如果要引入一个概念，就必须用逻辑图表以及示例来证实这个概念。
让我们应用这个规则来描述一个初等代数的概念。
等式的传递性质如下：
如果A=B，且B=C，那么A=C。
现在让我们用逻辑图示来描述这个概念。（请看图3）
 
图3：等式的传递性是初等代数的基本原则。

下面的列表6展示了一些具体例子来加强对此概念的理解。

列表6：一些等式传递性的具体例子

• 如果7=3+4，且3+4=5+2，那么7=5+2
• 如果12+5=7+10，且7+10=6+11，那么12+5=6+11
• 如果x+y=z，且z=2a，那么x+y=2a

就这样，这条规则满足了。我们展示了等式的传递性这一概念，提供了描述性的图示，并且进一步用具体示例来证实了这个概念。
让我们继续来看一个和软件开发更加相关并且更难理解的概念。这个概念是Maven POM的继承机制。在下面的展示1中，你将首先看到这个概念，然后是一张逻辑图表来描述此概念。最后，你将看到另一张图表，展示了在继承的情况下POM文件的具体使用方法。

展示1：描述Maven POM的继承机制的技术文档节选

理解POM文件的继承机制

一个POM（项目对象模型）文件是一个XML文件，描述和使用在Maven项目中。你可以建立一个Maven项目来从一个单独的父POM文件中继承其设置。从父POM文件中继承设置的能力就被称为POM继承。你可以在POM文件中使用<parent>元素来定义父POM文件。
下面的图4说明了一个虚构的项目体系结构，其展示了你如何建立一个主POM文件，使得其他POM文件可以继承其通用设置。
 
图4：你可以指定一个主POM供其他继承其通用设置

下面的图5展示了Maven项目stooges-web、stooges-api和stooges-dal的POM.xml文件的内容。每个项目都配置为使用<parent>元素来从stooges-project继承设置。
 
图5：使用<parent>元素来指定Maven项目从外部POM文件继承设置

上面的例子严重依赖于图来提供逻辑证明和具体示例。设计出有趣、吸引人、准确的图示和示例是一项艰巨的任务，但很值得去努力。为一篇技术文档多次设计图示并且提供示例代码很耗时，如果不比真正稿子的撰写更费时，那也差不多了。因而，我制定相应的计划以确保我的时间分配能满足最后期限。
当论及如何将一个概念阐述得水晶般透彻，那么就用图解法，并举一个示例吧。

7.拥抱修改

一蹴而就一篇优秀的技术文档是很罕见的。理解你的话题，组织你的观点，寻找语言清晰准确地表达观点需要耗费大量的时间和精力。因此，不要因为期待着第一次就能万事俱备而束缚了自己的手脚。相反，计划写出至少三个版本。第一个版本只是写一些草稿以便弄清楚自己的意图。第二版在你的作品中融入清晰性和准确性。然后，一旦你事实确凿，图示清晰，并且组织合理，那么就创建第三版，使你的作品引人入胜而别致。
篡改下爱迪生的名言：“技术文档是10%的创作和90%的修改！”

附送段

既然你已经了解了创建世界级技术文档的7条规则，那么我就和你分享下我创作一篇技术文档的过程吧。很简明，但是扼要。我把这个过程称作是，制作技术文档的7步。开始了：

1. 我列出提纲，至少到第二个层次，如果顺利的话到第三个层次。
2. 在提纲中为每个概念加入我的图解。
3. 为我的图解配上标题。
4. 按照提纲填充内容，遵循两句话规则，并根据手边的内容调整我的提纲。
5. 修改。
6. 我把文章发给和主题相关的专家来复审。（和主题相关的专家指的是可以识别出文中不准确和不清晰之处的人）
7. 根据复审者的反馈再次修改。

这样便搞定了。7条规则，7个步骤。谁还能再要求什么呢？因此，既然你已经学会了我所有技巧，大胆地往前走吧，让这个世界变得更加准确、吸引人、形象和有趣。值得我们去努力。

由于国内Android官网（developer.android.com）没法访问（当然google下还是能找到访问的办法），图省事就找了公司文件服务器上的老版本sdk（android-sdk-1.5_r2-windows）装上，结果发现只要一用SensorManager.getSystemService(SENSOR_SERVICE)这句，程序就死了，折腾半天发现是sdk版本问题，说是1.5r3版本（不包括r3）以前的版本在传感器这块有bug，在r3开始以后的版本中已经修复，又搜遍了服务器没发现有更新的版本，只好自己去网上（http://androidappdocs.appspot.com/）下一个。 更多的废话请看下面……

=======================================================================

配置Android开发环境

1. 下载eclipse3.5版（当然其他版本也可以，文中用的是此版本，其他版本情况基本类似）。当然jdk之类的是先要安装的。

2. 在这里（http://androidappdocs.appspot.com/sdk/index.html）下载android sdk的安装程序

并点AndroidSDKSetup.exe进行安装，注意勾选这个：

这玩意的安装过程就是从网上下载你选择的sdk放到它自己的目录里，所以装完后你将这整个文件android-sdk_r5-windows随便放到你喜欢的路径下，并在环境变量Path后加上“……\android-sdk-windows\tools”

3. 接下来要安装的是ADT（Android Development Tool），是个eclipse插件，所以可以依次在eclipse里点击Help->Install new software->Add，按下图所示输入Name和Location：

OK，在下拉列表里选择刚加入的站点，并勾选要下载的文件：

一路next。要是有问题把站点路径的https改成http。要是还有问题的话，就先下载ADT的zip包（Android2.1要求ADT-0.9.6，在http://androidappdocs.appspot.com/sdk/eclipse-adt.html上有下载），然后在刚刚输入Location的界面点击Archive选择zip包安装：

4. 装完ADT，eclipse依次点击Window->Preferences->Android，选择SDK根目录。这样便装完了，可以新建个Android Project跑个helloworld看看效果。

ps:
1. 要是启动simulator有问题，在命令行中输入android create avd –name mySimulatorName –target 2先创建AVD。

2. 要是控制台出现错误信息Android requires .class compatibility set to 5.0. Please fix project properties，选择 project -> Android Tools ->Fix Project Properties。

3. Android界面可视化编辑工具——>DroidDraw，可以拖出界面，生成的XML布局文件拷贝进自己的工程里。

4. 模拟器要记得定时清理文件，不然有可能会占很多空间：c:\documents and settings\Administrator\Local Settings\Temp\AndroidEmulator中的.tmp文件都可以删除。

5. 每个SDK版本都有其相应的ADT版本。

简单的helloworld程序

1.

2. 包的目录结构如下所示：

3. 对项目右键Run as-> Android Application，等模拟器启动，第一次启动要很久（google上有解决办法），启动完毕运行应用程序，Hello World !

ps:
1. 如何看到System.out.println打印的信息？

不像普通的java程序可以在控制台中看到，我们需要在logcat里查看调试信息。具体方法如下：

　　1) 点击Window->Show View->Other->Android->Logcat

　　2) 于是在应用程序运行过程中所有的调试信息都可以在这里看到：

2. 在这里（http://androidappdocs.appspot.com/reference/packages.html）可以查看到Android API。

用SensorSimulator向Android模拟器发送模拟信号

Android中传感器的类型有方向、加速度、光线、磁场、临近性、温度等，本文以较有代表性的加速度传感器为例，旨在说清传感器应用开发的流程。

我们要想办法向Android模拟器传送加速度改变的信号，以便让应用程序监控到事件并作出响应。Android SDK中貌似没有和模拟器搭配使用的类似工具，幸运的是国外有个OpenIntents团队开发的Sensor simulator工具（可以在http://code.google.com/p/openintents/downloads/ list上找到sensorsimulator-1.0.0-beta1.zip下载，在http://openintents.org/en/node/6上可以看到在线的Applet演示程序）可以解决这个问题。

关于加速度传感器是怎么回事，这里就不多解释了，有兴趣可以参考下这个网页（说的是iphone的，但Android原理类似，http://www.riameeting.com/node/538）。

首先介绍下加速度传感器Demo的应用场景：把手机当做一个平面，平面上有个小球在滚动，Demo中模拟出现实世界球在重力作用下的滚动轨迹。由于没有真机，要在模拟器上实现，所以必须有工具能制造出使模拟器“上下左右前后旋转”的错觉，Sensor simulator便是通过调整虚拟手机的摆放位置向Android模拟器传达信息。

下面介绍如何使用Sensor Simulator：

1. 将文件解压，打开bin下的sensorsimulator.jar

2. 将bin下的SensorSimulatorSettings.apk安装到模拟器中，具体方法是先打开模拟器，然后在命令行中输入adb install SensorSimulatorSettings.apk，如图安装成功：

3. 在模拟器中打开Sensor Simulator Settings，在模拟器中将IP配置为和PC上Sensor Simulator中的IP相同，如图所示：

4. 在Sensor Simulator Settings中点击Testing，点击Connect，勾选几种传感器类型使之enable，如下图所示：

加速度传感器演示程序

Sensor Simulator配置完毕了，我们可以建个小项目来验证下：

1. 新建个SensorBall的项目，通过Add jars的方法将sensorsimulator-1.0.0-beta1\lib下的sensorsimulator-lib.jar添加到工程中来

2. 在AndroidManifest.xml中添加

<uses-permission android:name=”android.permission.INTERNET”/>

3. 跟传统的mSensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);方式获取传感器服务不同，这里要用

mSensorManager = SensorManagerSimulator.getSystemService(this, SENSOR_SERVICE);这种方式

4. 使用mSensorManager.connectSimulator();连接到Sensor simulator

由于代码不是自己写的，网上看到的，就不在这里贴代码了，有兴趣的可以参考这里：

http://ophonesdn.com/article/show/183

最后的效果如下图所示：

当调整Sensor simulator中虚拟手机位置时，Android模拟器中的小球位置也会发生变化。

关于Sensor simulator的更详细的介绍和使用方法，可以参考下面这两个网页：http://openintents.org/en/node/23
http://code.google.com/p/openintents/wiki/SensorSimulator

（完）

====================================================================

英文自我介绍
My name is Xiaojiayi. I’m now a graduate student in my first year in Software Institute, Nanjing University for my master’s degree. My major is software engineering. I got my bachelor’s degree also in software institute, Nanjing University in July, 2009. I have strong interest in c++ now, and I wanna devote myself to the development of c++ applications. In my spare time, I like basketball, reading and blogging. Ok, that’s all.

英文项目介绍
1) Android Exam Review System
I’ll say something about the Android exam review system. The system is designed for those who want to do tests on their mobile phones at any time and anywhere. The test type includes GRE, TOFEL, IELTS and so on. Function modules of the system include practice mode, test mode, error problem mode, and history analysis. I got familiar with the development of the Android machine man interaction application through this project. 2) Movie Tickets Booking System Based on Java Web
I’ll say something about the Movie Tickets Booking System Based on Java Web. The project is completed on my own as my graduation project, which took me several months to finish it. It’s used for demo only without any commercial value. Function modules of the system include booking tickets online, browsing film information, back-stage management and so on. It is developed by Ajax, integrated with Struts framework and Hibernate framework. Through this project I got familiar with the developing process of J2EE applications.

设计模式

1. 简单工厂模式

一个Simple Factory生产成品，而对客户端隐藏产品产生的细节。实作时定义一个产品介面，并透过特定静态方法来建立成品

2. 抽象工厂模式

将具体的Product封装在具体Factory实现中，而客户仍只要面对Factory与Product的抽象介面，避免依赖于具 体的Factory与Product，由于Factory封装了所必须的Product，所以要更换掉所有的元件，只要简单的抽换掉Factory就可以了，不用修改客户端的代码

如果要更换所有的视感元件，就只要抽象掉具体的Factory就可以了，例如：

   1: CustomDialog windowsDialog =

   2:       new CustomDialog(new WindowsWidgetFactory());

   3: windowsDialog.showDialog();

   4: CustomDialog macDialog =

   5:       new CustomDialog(new MacWidgetFactory());

   6: macDialog.showDialog();

在CustomDialog类中保存IButton和ITextField两个引用，在其构造函数中调用setWidgetFactory函数：

   1: public void setWidgetFactory(IWidgetFactory widgetFactory) {

   2: setButton(widgetFactory.getButton());

   3: setTextField(widgetFactory.getTextField());

   4: }

3. 工厂方法模式

在一个抽象类中留下某个创建元件的抽象方法没有实现，其它与元件操作相关联的方法都先依赖于元件所定义的接口，而不是依赖于元件的实现，当成品中有一个或多个元件无法确定时，您先确定与这些元件的接口，然后用元件的抽象接口先完成其它的工作，元件的实现则推迟至实现元件接口的子类完成，一旦元件加入，即可完成您的成品。

假设要完成一个文件编辑器，希望这个编辑器可以适用于所有类型的档案编辑，例如RTF、DOC、TXT等等，尽管这些文件有着不同的格式，先确定的是这些文件必然具备的一些接口，例如储存、开启、关闭等等，您用一个IDocument类型来进行操作，这么一来这个框架就无需考虑实 际的储存、开启等细节是如何进行的。

   1: public void newDocument() { 

   2:         document = createDocument(); 

   3:         document.open();

   4:     }

   5:     public void saveDocument() { 

   6:         if(document != null) 

   7:             document.save(); 

   8:     }

4. 单件模式

   1: public class Singleton {

   2:     private static Singleton instance = new Singleton();

   3:     private Singleton() {

   4:         // ....

   5:     }

   6:     public static Singleton getInstance() {

   7:         return instance;

   8:     }

   9: } //可以避免多线程问题

5. 组合模式

将对象表示成树形结构来表示整体-部分的层次结构，使得用户对单个对象和组合对象的处理具有一致性。

6. 装饰者模式

动态地给一个对象增加一些额外的职责。

   1: public abstract class Decorator extends VisualComponent {

   2:     protected VisualComponent component;

   3:     public Decorator(VisualComponent component) {

   4:         this.component = component;

   5:     }

   6:     public void draw() {

   7:         component.draw();

   8:     }

   9: }

  10: public class ScrollDecorator extends Decorator {

  11:     public ScrollDecorator(VisualComponent component) {

  12:         super(component);

  13:     }

  14:     public void draw() {

  15:         super.draw();

  16:         scrollTo();

  17:     }

  18:     public void scrollTo() {

  19:         // ....

  20:     }

  21: }

  22:  

  23: ScrollDecorator scrollDecorator = 

  24:                     new ScrollDecorator(new TextView());

7. 策略模式

定义一系列的算法，把它们一个个封装起来，并使它们可互相替换，使算法可以独立于使用它的客户而变化。

   1: public abstract class TextStrategy { 

   2:     protected String text;

   3:     public TextStrategy(String text) { 

   4:         this.text = text; 

   5:     }

   6:     public abstract String replace(); 

   7: } public class LinuxStrategy extends TextStrategy { 

   8:     public LinuxStrategy(String text) { 

   9:         super(text); 

  10:     }

  11:     public String replace() { 

  12:         preOperation(); 

  13:         System.out.println(

  14:              text = text.replaceAll("@r@n", "@n")); 

  15:         postOperation(); 

  16:         return text; 

  17:     }

  18:     private void preOperation() { 

  19:         System.out.println("LinuxStrategy preOperation"); 

  20:     }

  21:     private void postOperation() { 

  22:         System.out.println("LinuxStrategy postOperation"); 

  23:     } 

  24: } public class TextCharChange { 

  25:     public static void replace(TextStrategy strategy) { 

  26:         strategy.replace(); 

  27:     } 

  28: }

8. 命令模式

   1: public class Invoker {  

   2:         private Command command;  

   3:         public void setOrder(Command command) {  

   4:             this.command = command;  

   5:         }  

   6:         public void ExecuteCommand() {  

   7:             command.ExecuteCommand();  

   8:         }  

   9:     }

  10:  

  11:     public abstract class Command {  

  12:         protected Receiver receiver;  

  13:         public Command(Receiver receiver){  

  14:             this.receiver = receiver;  

  15:         }  

  16:         public abstract void ExecuteCommand();  

  17:     } 

  18:  

  19:     public class ConcreteCommand extends Command {  

  20:         public ConcreteCommand(Receiver receiver){  

  21:             super(receiver);  

  22:         }  

  23:         @Override  

  24:         public void ExecuteCommand() {  

  25:             receiver.Execute();  

  26:         }  

  27:     } 

  28:  

  29:     public class Receiver {  

  30:         public void Execute(){  

  31:             System.out.println("Receiver excute!");  

  32:         }  

  33:     } 

  34:  

  35:     public class Client {  

  36:         public static void main(String[] args) {  

  37:             Receiver r = new Receiver();  

  38:             Command c = new ConcreteCommand(r);   

  39:             Invoker i = new Invoker();  

  40:             i.setOrder(c);  

  41:             i.ExecuteCommand();  

  42:         }  

  43:     } 

9. 适配器模式

将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。

10. Façade模式

为子系统中的一组接口提供一个一致的界面，定义了一个高层接口，此接口使得这个子系统更加容易使用

Façade：为调用方法定义简单的调用接口

Client：通过Façade接口调用提供某功能的内部类群

Package：提供功能的模块或子系统

11. 模板方法模式

定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

   1: public abstract class AbstractClass {     public void templateMethod() {         // step by step template to solve something 

   2:         // implementor should follow those step 

   3:         opStep1(); 

   4:         opStep2(); 

   5:         opStep3();         } 

   6:     public abstract void opStep1();     public abstract void opStep2();     public abstract void opStep3(); 

   7: } public class ConcreteClass extends AbstractClass {     public abstract void opStep1() { 

   8:         // implement the real operation 

   9:     } 

  10:     public abstract void opStep2() {         // implement the real operation     } 

  11:     public abstract void opStep3() {         // implement the real operation     } }

对于一些程序而言，我们希望规定一些处理的步骤、流程或骨架，就像是上例中的step1到step3一样，至于流程中的step1到step3如何实现并不规定，而留给实现的人自行决定，这就是Template Method模式的目的