原文：Fuji F70EXR — How to Shoot It MkII 作者：Kim Letkeman
我已经在这篇文章中涵盖了我关于这款相机中各种模式的思索。我甚至今天还更新过那篇文章，根据一个读者在邮件中的建议，增加了关于电影模式相关的部分。
不过，在那篇文章中，我涵盖了几乎所有的东西，并在我的学习和掌握过程中不断的附加补充，因此读起来可能会比较难跟上其中的逻辑。所以，我在这里再用简洁的方式介绍一下F70EXR的拍摄技术。
第一件事情：先调低一两档你的液晶屏亮度，这样通常可以让图像看起来像比较真实。但你还是经常需要通过回放中的缩放以确认关键局部的曝光程度，因为富士相机的固件没有提供这方面的辅助。
保持在以下3种主拍摄模式间用拨盘切换：
下面这个嵌入式的Wave就是Google Wave团队的官方公告Wave，现在你不用登录Wave就能看到它了。不过匿名用户还只能浏览，参与互动仍然需要登录。但这样已经让Google Wave的可用性大大增强了，可以在更多Web领域发挥它应有的价值。
结合Google Wave API的Proxying-for，我们也可以自己实现匿名式交互，或者与其它身份系统集成（比如OpenID）。有时间的话，我会尝试做一个OpenID Proxy的Sample。
昨天的“地球一小时”，熄灯的时候，你是否有所思考，或已决定行动？节能、环保，需要从身边的点滴行动开始。
前不久，我在淘宝上买了一个50元左右的计量插座，可以监测即时功率、分时段用电量（最近1小时、1天、1月），最大功率2200W，夜光显示也很实用。适合用来评估家里各种用电设备的耗电情况，尤其是电脑。以下是初步测量的一些个人数据，供参考：
冰箱：运转功率70w，平均每天耗电0.6度
电脑（包括显示器）：200-230w，节能（显示器待机、华硕 EPU-6激活） 130w，待机（S3） 4w，关机 2w
音箱：空载 18w，关闭 18w（说明这个开关纯粹只是个mute……）
无线路由器（D-Link DIR-615）：6w
ADSL Modem：3.5w
电视机（老20吋）：约 50w，关机 2w
电热毯：66w
（待补完）
从收集的数据来看，和我原本的预期有些出入。总结下来：
· 冬天的主要耗电大户还是空调和电热水器。
· 冰箱虽然也不省电，但不如我想象的那么耗。
· 电脑的功率中，显示器占据了大约1/3（可能因为24″更耗电吧……），所以尽可能在系统的电源设置中包含“关闭显示器”。
· 音箱关机不关机的耗电量没差别，所以平时务必要断开电源。
另外，再提供一些节能的实用技巧：
· 调低显示器亮度，可显著节能（对笔记本尤其适用）
· 如果你的主机有节能功能（如华硕的EPU），请将其置为自动节能状态（空闲时，功耗可下降5-15W）。
· 通宵下载时，请配合实用DShutdown软件，自动在下载完成或网络拥塞时关机。（通过网卡流量监测）
· 热水器、加湿器等使用频率较高的用电器，可以考虑配备一个定时插座（机械式/数字式），合理节能。
· 冰箱冷藏室一般下层较上层更冷，所以合理放置冷藏的物品，可以不必将冰箱温度调的很低。
· 电脑周边最好在关机后也一并切断电源。如果有关闭插排电源的习惯最好，没有习惯的话，可以考虑用这种“智能插排”。
一直以来，Symbian都是基于OS + UI体系分离的设计，这种分离又不同于Android，后者的不同UI只是视觉呈现的差异，对应用而言，是完全兼容的。但Symbian的不同UI体系，如S60、S80、UIQ、QT等，彼此间连UI的API都不兼容，对应用开发者来说，这真是一个噩梦。虽然也可以通过将UI API的使用限定于Uikon UI（S60、S80、UIQ等当代UI体系共同的继承源），从而实现最大程度的兼容，但这样做是以牺牲广泛的可用UI元素为代价的，对稍复杂的应用而言都不太现实。况且即将取代现有各种UI体系的QT，又是一次颠覆性的变革，不用指望任何的兼容可能了。
那么，在这样一个变革到来之前的暗夜，如何开发一款可跨UI体系的Symbian应用呢？这并非没有可能，但有着诸多的限制。如果你的应用能满足这些限制的话，那么完全可以成为真正意义上的跨UI体系的Symbian应用。
Google发布Buzz后，网络上迅速出现了大量对Buzz的评论，有正面的，有负面的，有炒作概念的，有跟着起哄的，甚至引发了大家对Gmail安全的担忧。这其中不乏一些对Buzz的误读，所以，在这里以我个人的理解来解释一下。
“Google Buzz是Twitter杀手！”
这是大多数媒体最喜欢的炒作方式，又一个Killer App出现了，于是编辑们都兴奋了，又可以赚足眼球了。事实上，Google Buzz和Twitter总体来看并不是一个层面上的应用，还构不成真正意义上的Killer。一些冷静的分析还是看的比较清楚，Google Buzz其实主要针对的是FriendFeed，因为它们都是聚合平台，让不同源头的信息聚合在一起。Buzz相对于FriendFeed的最大进步在于，它除了聚合信息之外，还创造性的利用Social Graph来聚合人际关系。
当然，Google Buzz除了聚合功能外，自身也充当了一个简单的信息源，可以在Buzz上发表富媒体信息。但事实上，你有自己充分的选择权，完全可以保持原有的习惯，在WordPress上写Blog，在Twitter上唠叨几句，这些信息最终都会自动被汇总到Buzz中来。
“我们不需要又一个社交网络”
当你迫不及待的跑来Buzz上兴奋的吼了几句后，才意识到它和Twitter也没多少差，反而在这里找不到Twitter上那种“振臂一呼，Follower百应”的成就感了。没过多久，你就会逐渐淡忘掉Buzz。这是因为，你把Buzz当成了一个和Twitter、Facebook、MySpace一样的社交网络。“又一个新的SNS，我不得不又一次花费时间从头建立我的关系网络。”其实这不奇怪，不光是你，连Microsoft也这么认为。
本质上，Buzz并不想打造一个新的社交网络，恰恰相反，它的目的是推进一系列开放标准，使用户不必在各个SNS维护一个又一个彼此独立的关系网络，使人际关系得以重用和汇聚，进而构造起一个去中心化的Social Graph，不依附于某一个特定的SNS。
Buzz倡导运用XHTML Friends Network (XFN) 和 Friend of a Friend (FOAF) 挖掘和汇聚用户既有的关系网，实现SNS间的互操作性。如果各个开放SNS都能响应这一号召的话，那么将来我们就再也不用担心自己的人际关系被锁死在某个SNS中，甚至还可以借助新的SNS发现原有SNS中漏掉的好友。
“Buzz让信息的回复和评论更加破碎了”
这一点确实是目前不争的事实，因为无论你从Twitter往Buzz同步也好，还是打算反过来从Buzz发布到Twitter，你都得面对一个问题，回复和评论的不同步。你很可能因为只在Twitter上读消息而遗漏了Buzz里别人的评论，或许在习惯了Buzz后，又冷落了Twitter上的Followers。在Web应用越来越多的引入“聚合（Aggregation）”功能后，这个问题逐渐凸显出来。Google Buzz现在没有解决这个问题，但这只是因为目前的Buzz还尚不完整。Buzz的API文档中有一节“Coming Soon”，其中提到了Buzz未来对这一问题的解决之道——Salmon。
之所以现在没有推出Salmon支持，我猜想，一方面是由于这个规范尚处在Draft阶段，另一方面它无法从Google单方面实现，因为信息源和聚合者都必须遵从Salmon协议，才能完整的实现评论同步。这个事情倘若让任何一家其它互联网公司来推，可能都收效甚微，但由Google Buzz倡导，其影响力就不可同日而语了。因此，Google在完成Salmon的支持前，先放出Roadmap来，让大家都意识到Google开放的心态和坚定的决心，这样Salmon才有机会得到广泛的认可和支持。
所以，就如同Wave对大多数人来说也不过尔尔，只有当你透过API去洞察其背后所希望表达的真正意图后，才能深刻理解Google每一款产品的前瞻和愿景。在大多数人被Buzz的优雅与便捷所打动时，我更看重的是它将对整个SNS生态圈所产生的深远影响，和它在推动开放和标准化上的显著贡献。
自从习惯了Twitter后，Blog写的是越来越少了。Twitter虽好，但相对于Blog，它其实很不利于内容的沉淀，再加上因国情问题而导致很多朋友无法访问，有价值的信息就此流失。为此，我准备尝试每周做一个Tweets的合辑，让这周中那些不是废话的内容能有机会沉淀下来，并且让更多人有机会从中获取有用的信息。当然，也随时欢迎在Twitter上Follow我。
Google App Engine（以下简称GAE）除了支持自有的appspot.com域名外，借助Google Apps，它还允许用户配置自己的独立域名提供服务。但之前使用过独立域名的朋友可能都遇到过一个相同的困扰：你可以用指定一个特定的二级域名访问你的应用，但却无法使用泛域二级域名（wildcard sub-domain）。对泛域支持的社区呼声一直都很强烈，Google也声称将要支持这一特性，但却未给出具体的时间表。
前两天为了解决tb.ly的泛域二级域名，折腾了很久。因为虚拟主机服务商Dreamhost不对非Private Server用户支持DNS泛域解析，所以我不得不另谋它策。在GAE上的一次没头没脑的尝试，居然意外的让我发现GAE已悄然支持了泛域二级域名。配置过程稍微有些复杂，所以在这里完整整理出来，以tb.ly的真实案例，分享给各位研究GAE的朋友。
相信大部分用过Everything的朋友们都再也离不开它了，我也一样。作为一个现今已不多见的“键盘流”，日常的大部分程序我基本都直接从Everything中启动，少了纷乱的快捷方式，桌面也清爽了不少。
Everything由于核心原理建立在NTFS的底层机制上，所以在Vista/Win7中不可避免的必须以提升的权限运行（UAC），不过这对与大多数PC玩家来说早已不算什么障碍。但你是否留意过，通过Everything启动的任何程序或打开的任何文件，也都继承了其拥有的提升权限，这对于重度依赖它的玩家来说，却是一个非常致命的隐患。当你从Everything中启动了Total Commander，又从Total Commander中启动其它应用，这整个程序链全都跑在不受约束的管理员权限下，对系统安全构成了严重的威胁。
那么，如何才能避免这种权限提升的传递呢？
先来看一下Google的愿景及其诞生至今的战略布局。Google的终极愿景很明确，也几乎没有改变过，那就是：“整合全球信息，使人人皆可访问并从中受益。” 这句话讲的挺有技巧，整合全球信息，并非简单的供你们搜索和访问，“从中受益”，那前提是Google需要充分从这些信息中挖掘出价值，而后才能造福大众。“掌握和控制信息”是Google所有从属战略的核心。
第一代搜索引擎所代表的是“整合互联网静态信息”的愿景，Google借助其强大的搜索引擎和海量存储成功的树立了搜索领域的霸主地位。在这个年代，整合互联网信息的方式相对比较直接了当，那就是“蜘蛛+索引+搜索”。大部分静态内容都是可以方便的直接访问到的，因此Google只需要构建一个巨型索引就可以达到整合信息的战略目的了。
前段时间，有一个朋友借我的相机去用。回头来还给我时，抱怨说他不小心把拍的很出彩的一张照片给误删除了。我琢磨了一下，富士这款F31fd上，删除相片也是有个二次确认的过程呀，而且二次确认的默认选项还是“停止”。难不成我这个朋友能短路到义无反顾的程度？不过当听完他道出苦水后，才意识到，原来这都是用户交互体验设计失误惹的祸。看似万无一失的“二次确认”，一样拯救不了你的照片。
事情的经过是这样的：当我的朋友在拍完那张照片后细细欣赏时，不小心按到了“上方向键”，这是删除当前照片的快捷键。而后，看到屏幕上显示出的删除确认提示，我这个朋友一阵紧张，先是连按返回键，发现取消不了又忙不迭的切换选择框到“停止”上，并匆匆按下“确认”。哪知道，却依旧眼睁睁的看着喜爱的照片香消玉殒……