这是 2011 年最大的收获。感谢老婆。
我非常庆幸我能陪着她成长。感谢 App Store 提供的机会。
2012，继续居家抱娃陪老婆，做一个翻得了墙下得了厨房写得了代码的全职奶爸。
今年的目标，创造一个有那么点牛逼的应用程序，熟悉 Lisp.
2003 年，我从网吧淘回了属于自己的第一台电脑，每天安装十数个 Linux 发行版，自此开启了非 Windows 操作系统的旅程。作为 Linux 菜鸟，最爱折腾的是美化桌面。不知为何，我最在意的是字体的呈现效果，以各种 Mac OS X 的截图作为参照，常常赞叹她能把字体表现得如此优美。这大概就是我跟苹果结缘的肇始。
2006 年，我开始学习编程。其时流行 Ruby on Rails. 大家知道，RoR 的很多示例视屏都是以 Mac OS X 上的一个编辑器 TextMate 来演示的。第一次看到代码编辑器可以如此好用，亦见识了 Mac OS X 操作系统优雅的介面。自此将购买 MacBook 作为自己的一个目标，在 2008 年 2 月份实现了。拿到机器以后，觉得不为它开发些软件实是人生遗憾，于是开始学习 Cocoa, 并在 2009 年初发布了一款很烂的饭否客户端 CocoaFan. 随后，我又给饭否写了一个 iOS 客户端。
自由职业一直是我的梦想，2010 年初，我决定离开服务两年多的饭否，迈上独立开发者之路。作为“标准”的程序员，我不擅长销售，但得益于 App Store, 我只需专注我的开发工作，每个月坐等比很多公司员工工资发放更准时的销售结算汇款。这一切，都仰赖乔布斯的创举——革命性的手机 iPhone 和 App Store.
今天，世界失去了你。
当这篇 blog 发布，我决定抹去伤悲，更加努力地工作和发挥创意，即便不能像你一样改变世界，但若能给使用各种苹果设备的人带来更多软件使用便利，亦已满足。
谢谢你，乔布斯！！！
年初发生两件大事：结婚（虽然还没空去注册领证）和辞职。
年末发生一件大事：老婆意外怀孕了。2011年夏天我升级成爸爸，嗯，也就是大叔了。
而今年也是我收获还凑合的一年，无论是经济上，还是我的编程技能上。自学通了很多计算机基础知识，终于能看通一些算法教材了。
大叔2011年计划的事情：
- 争取不用上班，能在默默（嘿嘿，我宝贝的名，男女通用）出生前攒够一套南宁房产的首付。
- 学习设计，提高设计感。平时没事要练练素描。
- 继续学习计算机基础知识，深入算法，钻钻汇编。
至于做奶爸，那已经是板上钉钉，不用计划的了。
为给 HTML 5 让路，W3C 解散了 XHTML 2.0 工作组。这造成了对 XTHML 和 HTML 之间的很多误解，所以就有人画了漫画来解释（英文，中文）。为了避免更大的混乱，我就不多作评论了。
关于本书，可以参考一下我去年的书评。对于前端工程师来说，很多情况下都需要重新捡起以前的代码，不管是不是自己写的，都会面临抉择：重新来过还是基于现状？大部分情况下，后者是唯一选择。勿怨天尤人，重构是你的好朋友。即便是在全新的工作进程中，当你闻到坏坏味道时，也需要很多小型的重构。那么，到底什么是重构？这可不是前几年流行的《网站重构（Designing with Web Stardards）》那本书里说的“重构”，而是”Refactor”，编程术语上的“重构”……说到底，还是得买一本才能了解透彻的，哈哈。
随着网页的程序化（就是 Web Application 越来越多了），眼观六路，耳听八方，前端工程师跟浏览器打交道，除了在掌握浏览器在展示页面上的知识，还需要有浏览器跟后台交互的基本知识，本书涉猎 HTTP 的基本要点，虽不深入但亦可管中窥豹了。
作为第一本在 HTML 领域探讨重构的《重构 HTML: 改善 Web 应用的设计》终于上市了，各大网上书店均已铺货。
拥有 MacBook 已经一年半了吧，有机会接触 Mac 的编程环境，兴趣盎然，一发不可收拾，经过一年的 C 和 Objective-C 语言入门，今年初即开始一些最基本的 Mac 编程，先后做了可可饭和饭否 iPhone 客户端。
有一天想用 iPhone 看一本只有 CHM 格式的电子书（Quartz 2D Graphics for Mac OS X’s Developers），发现 App Store 存在两款软件，试用其中一款，觉得非常不满意，甚至无法满足最基本的阅读需求，就产生了做一个更好的 CHM 阅读器的念头。满足自己的需求，也希望藉此赚点零花钱买个 iPhone 3GS.
于是有了 CHMate, 今天已经可在 App Store 安装，定价 $4.99. 如果有机会对比一下 CHMate 跟其他 iPhone CHM 阅读器，你会发现 $4.99 不会花得冤枉。根据我的老本行积攒的知识，我可以对 CHM 文件内的 HTML 做到最适合 iPhone 的屏幕阅读。CHMate 的优势是：对文档进行了重排，原来文档内的样式，除了那些依附在标签（tag）上的，基本上都被重写优化了，而且通过设置让你有控制样式的机会。当前尚未有同类产品有这个功能，这是我作为一个前端开发者所引以自豪的一件事情。
入行已久，做的领域也从浏览器扩展到桌面端甚至是手机端，对 Web 标准多少有些自己的看法，今日斗胆一说。
两种家
我们困惑不解、迷惑不安，很大程度上源于没有指导思想。要摆正自己的位置，我们究竟是想做科学家，还是想做工程师。简明扼要，科学家经常要问“为什么”，他们关心了解人类不懂的知识；工程师则利用科学家发现的知识，制造对人类有用的物体或工具。前者研究，后者实战。很明显，我们大多数人属于工程师，W3C 那一群才是科学家。端正自己的态度，很多疑问就会迎刃而解。
两种用法
HTML 生为标记语言，是组织文档的一种格式。随着技术和社会的不断进步，HTML 的用途也逐渐升级。今天它不仅出现在浏览器上（普通网页），它还出现在桌面程序上（Adobe AIR），出现在手机程序上（PalmPre WebOS）；它不仅用来展示网页，也用来构建程序的用户界面。Web 标准要求我们，HTML 必须有良好的语义化，对于展示内容的文档来说，这是毋庸置疑的，但对于只是作为构建用户界面的程序来说，强调语义是没有多大意义的。要注重语义的时候一定不能松懈，只是用户界面而已的话，怎么方便怎么来，利用最方便的手段做最适合的布局。
实用主义的前提
工程师信奉的是实用主义，但不等于可以放弃原则和规范。工程师关键任务是在遵守规范的前提下，发现、理解并结合实际的局限来达到满意的结果。作为一个流量巨大的网站，Google 对待 HTML 的态度是一个非常好的例子，省略</body> 和 </html> 的做法我们何曾想过呢？但这却是符合 HTML 4 规范的。详见： http://code.google.com/speed/articles/optimizing-html.html（需自行翻墙）。
最近总算有精力投入到 Cocoa 的学习了，做了一个饭否专用的客户端，名曰可可饭，倒腾了一个多月算是有了一个基本可用的版本：http://code.google.com/p/cocoafan/.
门还在入，欢迎各界人士多多指教。
C 可能是世界上最简洁且功能强大的语言，同为 C 的超集（C++现在可能不认为自己是 C 的超集或者相反，我们姑且如此认为吧，至少历史上有过这样的共识），Objective-C 比 C++ 要简洁得多。Objective, 顾名思义，对象者也，为不提供面向对象编程基本功能的 C 添加面向对象的支持，但它不像 C++ 繁冗复杂，最大限度上保持 C 的简洁性。
Objective-C 不像 C 有国际标准，它和 C++ 一样不存在标准。目前主要是 Apple 在维护，最近衍生了 Objective-C 2.0. 使用 Objective-C 的大户也当属 Apple, 因此 Apple 提供的库属于准标准库了。对于开发 Mac 内在观感(native)的 UI 程序来说，使用的是 Cocoa 这个框架，包含 Foundation 和 Application Kit (AppKit).
Objective-C 也使用头文件(header files)，后缀为 .h, 但使用 .m（即 message, 其他面向对象编程语言也叫 method），作为源文件的后缀。
Objective-C 引入了 #import 指令，它的作用不仅解决头文件重复包含的问题，而且只要引入框架的单个主头文件，就可以使用框架的所有功能。
使用和查看 Cocoa 提供的 API 时，通常会发现它们大部分以 NS 打头，它是 NeXTStep 的缩写，至于 NeXTStep 和 Apple 的渊薮，大家还是自己 Wikipedia 吧。这是因为 Objective-C 没有命名空间（name space），为避免冲突而加上的。作为一个良好的编程习惯，开发者不应再以 NS 开头命名自己的类和函数等，通常的习惯是使用自己或公司名称的缩写（Realazy 是否可以缩写成 RZ? 呵呵）。
另外，Cocoa 的编程风格鼓励表达清晰而非含糊的命名，所以你会看到 Cocoa 中非常长的、极少看到缩写的类名或消息名。
最近利用 Adobe AIR 做了一个饭否客户端：爱饭，并将之开源。使用 HTML, CSS 和 JavaScript 对着 API 文档照虎画猫，大概三个星期完工，有一些感想和总结。
- AIR 的开发对 Web 开发者非常友好，基本上不需要额外的程序知识了，甚至可以使用已有的 JS 库，爱饭就使用了 YUI。但是生成的程序有一通病，那就是占用内存高（爱饭在 Windows 下占用 40m 左右），而且不存在优化之说。做严肃的应用 AIR 还是上不了台面。很多时候觉得，打开一个 AIR 程序，其实就是打开了一个浏览器。
- absolute 的 CSS 布局方式非常灵活，对窗口缩放这种情况具有非常好的适应性。使用 webkit 引擎的 AIR 对 absolute 完全支持。如果是 IE 这种支持残缺的引擎，那得费非常多的 JS 代码。在 AIR 下写 CSS 有一种莫名的快感。正好 24ways 上发布了一篇关于 absolute 方式布局的文章，免却了我的罗嗦，见：Absolute Columns。
- AIR 对 Linux 的支持还是存在缺失，比如无法给窗口加阴影，看来是 Linux 下的 Flash 支持跟不上。
完毕。
异步操作数据的方式有两种常见的方式：XMLHttpRequest 和 iframe. 孰优孰劣在此我们不争论，只是想举一个例子说明在获取网片片段上，使用 iframe 有一个比 XMLHttpRequest 更易企及的好处。
Ajax 常见的一种使用方法是加载网页片段填充某个区域。假设我们要在网页 foo.com/index 上请求 foo.com/partial。我们假设 partial 就是 HTML，不涉及 JSON 或 XML 格式。在这种情况下：
- 使用
XMLHttpRequest直接访问 partial，获取 responseText 后赋予 index 页面上某个元素的 innerHTML 即可完成。partial 必须是一个纯粹的 HTML 片段（基于以上假设）。 - 在页面上创建一个隐藏的 iframe, 使用 iframe 的 src 请求 partial, partial 可以作为一个完整的页面，里面包含 JavaScript，由 partial 里的 JS 完成替换 index 上页面片段替换。
第二种看起来更繁琐，但能给我们更多控制权。例如，假如用户直接访问 foo.com/partial（这种情况很容易发生，假设您是 unobtrusive 的拥护者，机会更大，例如需要点击网页上的链接更新某部分内容时，用户使用新窗口打开了改链接）, 你希望她看到的是什么内容呢？
在第一种情况中，用户看到的是代码片段，绝大部分下没有任何样式，也没有任何额外提示，导致用户体验的下降。因为只是一个 HTML 片段，你什么事都干不了。
但在第二种情况下，用户看到内容可能也只是 HTML 片段，但这却是一个完整的页面，一个可以执行 JS 的完整页面。我们只需检查这个页面的 parent 对象有没有我们预设的值，就可以判断它是不是在 iframe 之内了，然后我们可以让它跳转到正常的页面。
