All posts in 杂

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年计划的事情：

1. 争取不用上班，能在默默（嘿嘿，我宝贝的名，男女通用）出生前攒够一套南宁房产的首付。
2. 学习设计，提高设计感。平时没事要练练素描。
3. 继续学习计算机基础知识，深入算法，钻钻汇编。

至于做奶爸，那已经是板上钉钉，不用计划的了。

如题，这是一个在北京的工作机会。

工作职责：

• 使用 HTML/CSS/Javascript 开发符合 W3C 标准的网站前端页面；
• 使用AJAX，Flash等技术丰富网站功能，增强用户体验；
• 和后台工程师一起研讨技术实现方案，制定服务接口等；
• 积累并完善自己的前端WEB开发框架，Javascript开发框架；
• 积极探索并积累前端开发模式和规范。

职位要求：

• 本科以上学历，能熟练阅读英文技术文档；
• 具备良好的团队合作精神和积极主动的沟通意识；
• 具有强烈的进取心和求知欲，勇于挑战；
• 精通HTML/CSS/Javascript等前端技术，习惯于手写符合W3C标准、兼容多种浏览器的前端页面代码，而不是依赖IDE；
• 有Flash，ActionScript开发经验者优先；
• 有设计经验，熟悉Photoshop、Illustrator者优先；
• 计算机相关专业毕业者优先。

有意者请致信 job(a)hainei.com.

另外还招聘产品经理、研发工程师和高级研发工程师/架构师。详情见 http://hainei.com/job.

不经意，又到了一年一度的总结和展望时间了。

2006末，在不懂MySQL, Ruby的情况下，用RoR折腾出一个十分简单的jobz board, 向世界宣布我“会”编程了。侥幸进入中国雅虎（已在8月份离职），虽大部分时间还是折腾HTML和CSS, 但也有了练习JavaScript的机会，怎么说，以前玩linux积累一些非编程但有助于了解编程的经验，在练习过程中得以入门编程，还写得真像那么回事了。

记得2007的展望是精通JavaScript，这个完成得有60%吧，对PHP和MySQL也有一定的了解。至于Ruby，没地方用，所以顶多掌握了一些概念和语法，倒是Python，用得还多点，年末用webpy和SQLite3写了一个blog程序，算是对Python入了点门。

还好，不经意间踏上了编程之路。

但一提到“编程”二字，常常让我觉得汗颜。程序者，经典公式为程序＝算法+数据结构。但是我既不懂算法，也不懂数据结构。我说我在编程（programming），实在是跟全天下的程序员（programmer）过不去，我顶多是个编码者（coder）而已。

因此，2008, 北京要举办奥运会，我要学习算法和数据结构。从而需要自补高等数学（不好意思，我是文科生 ），也从而需要学好C语言。高数、C语言、算法和数据结构，用我党的话说，这是2008的主旋律。

如果时间充足的话，还计划使用Python做些GUI应用。计算机的精彩决不仅仅局限于web.

回顾一下年初，有些话说过了头，但基本上都履行了。虽然没法攒够钱给支持家庭，但也算是最有力度的一年了。

2007年10月，我奶奶安详辞世，享86岁。愿往者安息，生者健康，以奋斗来慰藉往者的关怀与爱护！

忘了从哪看到的一句话，印象挺深：Frontend engineering rocks right now. 没错，随着用户体验等课题的不断发展，如何能够把需求更完美在前端中实现的重担，已经由过去兼职的后端工程师转向了专职的前端工程师。作为一名前端工程师，除了在开发上，必须比后端工程师更关注用户体验，因为用户最终使用中，第一接触UI界面，然后操作，进行交互。能否保证用户友好的界面和交互，除了产品相关人员的功能策划，还有前端工程师对功能在前端中的具体表现的深刻理解，对技术壁垒的一一攻破。前端开发到了rocks的时代了。

但是或许我们会在用户友好中迷失自己。一件产品的诞生，凝聚的是整个团队的努力，所以，前端开发必须注意到自己代码应该是清晰紧凑的，这样，无论是市场的广告投放，后端的数据输送等开发，都可以最佳的方式来配合前端，即需做到开发者友好；我们的代码，不管是由浏览器来处理，还是搜索引擎的检索，都必须尽量做到符合语义，使用当代的开发思想（如web标准）来要求前端的代码，即做到机器友好。

前端开发的任务就是做到：用户友好，开发者友好和机器友好。

用户友好毋须多言，这是我们的首要任务。如果可能，我建议所有的前端工程师都能够把自己定位为用户体验设计师的一员，而且是不可或缺的重要一员。只要是用户体验设计师，无论是谁，都想最佳的体验呈现在用户面前，这个愿望是好的，但是，在这个不是那么美好的时代，我们会受到许多客观条件的制约，如浏览器的支持不足，或者某个重要特性的缺乏，让我们本来预计的美好愿望编程肥皂泡。如果前端工程师在产品设计初期未参与进去，原有的完美设计，在进行到开发的阶段才发现某个不可实现的功能变得四不像。我们可以利用我们的专业技能明确判断哪些可以实现哪些不能实现，那么就能避免很多问题。

开发者友好是前端开发的第二个任务。在讲究流水作业的今天，保证开发者友好的代码、接口等是提高产品开发速度和质量的一个有效途径。开发者友好，意味着降低沟通的成本，意味着合作的顺利进行。不要认为世界上的人都像您这么厉害，即使是最简单的HTML，写上最详尽的注释，这样其他开发者在接手的时候就不必满天查找开始与闭合的div。就算您是多面手，您也必须注意您的前端开发必须开发者友好，否则可能过个个把月您连自己的代码都不认识。

至于机器友好，其实也是保证用户友好的一个前提。如何能保障我们中的特殊群体——残障人士的友好性，机器友好是最重要的一条途径。他们使用的设备，受限于他们的生理条件，同时就受限于处理信息的灵活度。如果不能保证机器友好，那么这些设备就不能保证能正确处理我们提供的信息。即使是普通用户，机器友好的代码也能降低他客户端的资源消耗，提升使用的速度，从而提升用户友好度。我们的用户中也有机器，比如搜索引擎，它们往往是用户找到我们提供的服务的关键。机器友好的一大意义还在于，搜索引擎能更好得处理信息。

用比较商业的术语说，前端开发的客户是：用户，开发者以及机器。我们的价值观的第一条：客户第一。既然如此，我们前端开发的任务，非用户友好、开发者友好、机器友好莫属。

2007的计划

虽然有点迟，但还是来了

1. 省钱，攒钱，2008年到来前能达3w给家里
2. 精通JavaScript
3. 适应公司需要，优先学习PHP + MySQL, 要求到达熟悉
4. 掌握Ruby语言，熟悉Ruby on Rails框架
5. 初步学习一些设计理论

Wishlist

没啥，希望今年能有一台MacBook.

我其实在2006年的某段时间预计在春节时能够买到一台MacBook, 当时把希望寄托于年终的双薪上。后不爽跳槽，几近一月无收入，年终奖更是水中花。手机被扒购置新机又花一笔（莫非是本命年我没穿过红色内裤的缘故 orz）因此这个计划在2006是不能实现的了。因为上面计划第一条的缘故，3w已经是我的极限，而且必须全数归家。我不能再攒多1w来在2007实现MacBook的愿望了。那么为什么我2007的wishlist还是MacBook?

受DBA Notes的启发，我也打算依靠出售本blog的广告位来实现。当然，比起DBA notes来，我的blog微不足道，所以人家要MacBook Pro, 我要MacBook就好了

如果您觉得本blog上唯一的广告位连续两年不断的投放还值得一台MacBook的话，热切盼望您联系我：xianan.chen AT gmail.com商讨具体事宜。

注：广告形式由您定，当然得合法健康，跟本blog的内容相关的最好啦，连续两年是指除非不可避免的因素如地震或者我身亡等否则不会中断。具体详谈。

P.S. 虽然我比较低调，但能在一个还算小有名气的国外网站上投稿成功，国际化的第一小步迈出成功了，倍高兴。所以在这里 P.S. 炫耀一下 详情请看：Coloring text-decoration. 这个tips其实是我老大kejun传授的，在此感谢。

离职在家半月有余，趁难得机会把相关的Rails书籍看了一遍，参考37Signals Jobs Board练习了一下Rails，很高兴，一介文夫的我终于能写出一些有用的东西，实现了我多年的梦想（是啊，我一直嚷嚷要学编程，直到现在才有所进步）。

为什么我要参考37Signals Jobs Board做这个东西，原因不仅是练习如此简单而已。我的blog读者中，很多人都向我咨询人才方面的事情，无论是找工作还是猎工作。半年前，我就有开个工作板方便大伙的打算，但一直没有机会。因为我才不想用手工添加的方式来处理各种工作需求，所以一定得写个程序来处理。

约10天前，得知qyb的空间可以安装ruby，这个消息真实让人振奋，我的热情空前高涨，一头扎进去，并最终形成了这个网站：Jobz Board（感谢X-Noise绘制的logo）。

Jobz Board很简单，但够用了。如果您需要找人才，不如来发个招聘贴？免费的（看样子我也不敢收费，呵呵）。如果您在找工作，何不瞧瞧是否有适合您的？当然，现在还没有人发……

希望能够对您有所帮助。请访问Jobz Board.

需要注意的是，为了方便大家，请按照格式书写，请不要发布垃圾信息，请发布正确的而不是测试的信息，必要的时候请与我联系。所有信息都必须经过审核才能发布。

p.s. 在一天中连续发两篇blog真是历史罕见啊，呵呵。

我自己时常会被各种Web应用所困惑。我自己的观点也时常也会被某些现实中的应用所推倒。比如，我一向所持的观点是，在JavaScript横行的时代尤其需要注意网站的无障碍，就是说，没有/禁止JavaScript的情况下保证信息的可传达。但是，可以看到很多应用，比如Gmail, 比如Google Reader等，都是两极的做法，提供一个不需要JavaScript的基本视图或者干脆明白地告诉你不开JavaScript不给你用。

那么我一直提倡的Unobtrusive JavaScript还有什么意义？其实跟人交流的时候我的底气也不足，因为，确实，不Unobtrusive也不见得有什么坏处啊，最典型的例子就是前面所举的Gmail例子。跟人论战，若有人举出如此例子，我一般也只能缴械，确实，我没能找到合适的理由来反驳。

不断地翻资料，终于在非技术层面找到一些看起来应该算是比较可靠的理由，不敢独吞，遂分享。不敢保证正确，如有任何想法，务必留言交流，谢谢！

WWW（你可以叫它互联网，但也有人称之为万维网）诞生之时，只是一个超文本（hypertext）的系统，所担负的任务只有一个，依靠线性的超连接来传递信息，这是一个典型的信息系统体系。

随着各种前端，后端技术的飞速发展和成熟，加上商业的介入，人们不再满足WWW作为一个信息系统而已。很多人尝试将常规软件，特别是桌面应用软件的设计的规则搬到WWW中并针对其弱点（比如无状态的传输协议HTTP）进行改良，使得WWW俨然成为一种软件性的应用，即使说， 不停留在信息传播的层面上而已，而是让人们能够依靠它完成某些任务。这就是任务型的WWW，最典型的，还是前面所举的例子，Gmail和Google Reader，人们依赖它们去完成收信，抓取Feed等的任务，而且是建立在一种比较直观的交互方式上，没错，跟桌面软件一样直观。

这种利用WWW的优势（跨平台，跨时空）可以说是WWW的一个发展趋势。因为它能把人们从对某个特定环境（比如特定的计算机，特定的操作系统等）的依赖解放出来。RIA（富互联网应用）的概念兴起已有一段时日， 但真正引爆流行的是Ajax概念的出现。这个概念更容易让人把某些WWW应用设计成桌面程序，而不分青红皂白，哦，不，是不分自己所做的项目到底是面向任务还是面向信息的。

面向信息是WWW天生就具备的功能，可以说现在的WWW大部分应用依然如此，比如门户网站，比如电子商务，这是我为什么每次都强调要保证信息的可传达性，不管在什么情况下。但是就如前所提到，WWW已经有了新的发展模式， 尽管未来可能有更多的面向任务型的Web应用，但不论如何，这两条线是平衡发展的，不会有谁取代谁的机会，顶多是综合运用。

问题就出在综合运用这里。很多人一听说Ajax，毫无考虑，虽然心中无面向信息或者面向任务的概念，但一开始就认为这是面向任务的，因为Ajax的概念先入为主了。在面向信息的应用中，比如门户网站，比如政府公告，使用Ajax或者其他JavaScript来增色应用是没有问题的，但要确保信息的无障碍（貌似我强调了好多遍了）。

当然，在面向任务型的应用中，这只是把浏览器当成是一个软件的运行环境( Runtime Environment? )，就如同Java程序需要JRE一样，只不过面向任务的WWW应用充分利用WWW作为数据保存、输送的纽带而已， 因此，假如运行出错或者环境限制，我们只能告知用户，你用不了我们的程序，请检查哪里哪里，如果还不行只能抱歉了。

但是在面向信息的应用中，请问，假如用户在受限的环境下获取不了信息，这说得过去吗？面向信息就是以信息的传达为目标，不应该有所限。

所以，在项目的开始之初，我们需要必须明确的第一件事情是，我们是面向信息还是面向任务，这才能让项目的方向明确，不至于让各种貌似很高级的东西迷惑了我们的决策。

最近对Web前端有很多想法，刚好看到这篇文章，跟我想法不谋而合，所以翻译出来与大家分享。许久没翻译了，里面多少还是有些我没能完全理解，意译过来，如果错误，请务必指出和修改，谢谢。

原文The Time is Now for Front-End Architects， 来自：Garrett Dimon，感谢作者的许可。

去年，我在YTS发表了前端架构师的想法，之后花更多时间来思考，现在更坚信这是一个不可或缺的角色。

当后端技术伴随.Net, Rails和Java之类的框架发展得越来越抽象和强大，前端技术的潜在发展也日益复杂。在束缚前端技术潜在好处的差劲实现之前， Web需要更多的前端架构师。

多亏了诸如跨浏览器支持的先进技术的发展，用户体验、更多有意义的主题比如无障碍都拨云见日，这个世界再也不仅仅就HTML和CSS如此简单，因此，绝大部分的团队都需要一个真正理解和实践涉及到前端的一切的人。

角色

这并不是一个扼要和简单的清单，对于下面的主题／技术，前端架构师也不能仅仅满足于了解一下里里外外而已，而是需要足够的深入研究，并有自己出色的见解。

• XHTML
• CSS(1, 2, 3)
• 跨浏览器和跨平台
• DOM脚本编程
• AJAX
• Flash
• 渐进增强和适度降级
• 无障碍
• 可用性
• 信息架构
• 界面设计
• 视觉设计
• 表现层逻辑（ASPX, Rails视图等）
• 商业规则和逻辑

作为一个前端架构师，必须拥有这些领域的绝对执行力。例如，前端架构师能够决定某个特性是使用AJAX还是传统的页面刷新。哪个更便于使用？对无障碍的影响如何？改用Flash有意义吗？

拨乱反正

表现，结构，行为和商业逻辑的混杂，导致不必要的复杂，导致难以维护的怪胎解决方案。就如后端需要正确地划分为数据层，商业逻辑，表现逻辑等，前端开发复杂到是时候调整其架构了。

编写良好结构或者说避免使用表格布局是远远不够的。这是第一步，前端架构的哆咧咪而已。现在是时候关注DOM脚本编程，AJAX, 无障碍等，该升级了。

非编程不可

我主张前端架构师必须懂得真正的编程知识，而这正是很多自封为前端架构师的人所缺乏的。我的意思不是能够剪切粘贴改进代码就行了，而是能够跟老练的工程师商讨如何能够最好地结合前端。

这就是说，前端架构师需要真正理解结构遭遇商业逻辑的问题。如果工程师说某些东西使用ASP.Net DataGrid是不可能实现的，前端架构师必须能够解释如何与为何要使用DataList或Repeater取代，解释为何DataGrid在该情景下是个错误的选择……

这只是个例子，问题还在于仅知道客户端编程也是不够的。能够使用与工程师相同的术语，能够讨论（前后端）关键集成的最佳解决方案，这是绝对必须的。

断线的风筝

我们今天正处在一个不妙的处境中，原因在于几乎没有人能够为前后端的沟壑搭桥。一般工程师不会有兴趣或实践标记，CSS, 或DOM脚本编程，大部分客户端开发者也没有与后端技术协作的经验。几周入门PHP不会成为程序员，几周入门XHTML也不会成为真正的客户端开发者。

罪魁祸首

我首先想到的十足例子是，ASP.Net完全漠视Web标准，同样地，web氛围（我们指表格和占位gif）让Web标准郁闷。企业项目的大多数框架输出的标记，即使使用1999年的标准来衡量，都是糟糕无比的。

如此巨大和“专业”的产品怎么能才够不忽视，按理说是整个项目最简单的方面？只有静态代码。理由是，基于技术的立场衡量产品，结构，CSS和其他客户端技术都是“事后诸葛亮”。表现逻辑，结构和行为混杂，压根无助于无障碍，Web标准，或者前端技术干净的分离。抬起你的头来，就在2006，这些都成受欢迎的惯例了。

总结

如果这个世界上姿态最鲜明的产品和项目都如此低劣的方式来处理事情，其他的还有什么好说？毫无疑问，我们需要前端架构师，而且就在昨天。

归结于归结，我们有一堆相互关联的技术，很少人能够埋头钻研它们之间的关系，这很不幸。正确做事的真正价值在于容易的维护和长期的适应性。虽然在关键时刻，有些方式更容易选择其他的方法和拼凑起另外的东西。对某些人来说，这可能是可接受的做事方式。但是，对我们大部分人来说，这是拙劣的抉择，也非常不专业。

我交给你去想了。我假设你把车交给技工修理，修好了时候，瞧瞧引擎罩内大量的输送管，我不知道你对技工作何感想？