丁宇 | blog

前端开发正变得越来越复杂，随着软件和应用逐渐Web化，可以想见以后前端开发将会成为一个独立的部门，它将拥有现在软件开发部门所拥有的全套人员，如架构师、系统分析员、开发工程师和测试人员等等。

我blog上有一位朋友留言询问我如何定义“前端架构师”这样一个职位。虽然我没做过专职的前端开发，但一直都在参与相关的工作，甚至还曾经面试过“前端架构师”这个职位。因此结合我的个人经验，我理想中的前端架构师，应该是如下这个样子的：

职责：

1. 提升网站的前端性能，保证前端应用具有跨浏览器和跨平台兼容性及可访问性

2. 保证前端团队的编码质量，提升其工作效率

3. 创建并完善内部所使用的前端工具和框架

4. 定义与后端工程师合作的边界、标准化与后端程序的接口

技能：

1. 精通前端开发技术和Web标准

2. 至少精通一门后端程序语言，如PHP、Ruby、Python或Java等等

3. 精通面向对象和各种设计模式

4. 理解Web如何工作，如HTTP协议、Apache或Nginx等等

5. 熟练使用各种相关的工具，如Subversion、Unix/Linux shell、VI或Emacs等等

6. 了解交互设计的基本知识

7. 沟通能力强，能够领导团队共同进步

我分别解释一下。

首先说职责。其中前两条应该算是架构师的一个基本职责了，无须赘述；第三条“工具和框架”很重要，有了好的工具和框架，网站的设计规范才能更顺利的得以实施，这点在以前的两篇文章中谈到过（说说互联网公司内设计师的分工和为什么网页设计不应强调分工1、2）；第四条“边界和接口”实际上以前也谈到过，这个意思就是说，后端程序只给数据，所有的页面逻辑和展现都交给前端来做。现在许多新兴的Javascript框架（如JavascriptMVC和SproutCore）都号称可以脱离后端程序、直接靠test fixtures就能独立运行，我觉得这就是对我这个观点的最好证明。

接下来说技能。技能确实没什么好说的，大部分都是一个前端开发工程师所应具备的技能。其中第二条对后端语言的掌握和第三条对设计模式的理解，实际上是相当一部分前端工程师所欠缺的（我就不懂设计模式），因此特别加上。

最后要说的是，各个团队需求不同，对工程师的要求也就不同。如果你不同意上文中的某些地方，可以留言说说你遇到的情况。

Cappuccino

Cappuccino是一个非常别致的Javascript框架，它由一群前Apple工程师开发，力图在Web上通过Javascript来重写Objective-C语言，他们把这个语言称为Objective-J。这样原有的Cocoa程序员就可以继续使用他们熟悉的语法来开发Web应用程序，Cappuccino内建的解析器将在浏览器端负责解析。

我不得不说这个想法很疯狂，和Bindows、Qooxdoo这些框架比起来，Cappuccino走得相当的远。不过这群天才做得不错！从官方文档来看，Cappuccino已经逐渐成形：兼容所有主流浏览器（包括该死的IE 6）、有知名的演示站点280 Slides、有Cocoa那丰富的资源和完善的文档支撑、控件库漂亮且齐全，它甚至有一个名为“Atlas”的可视化IDE（这个一会儿详细说）。

我前一阵子花了不少时间研究Cappuccino和SproutCore，总的感觉是这两个框架有很多好玩的东西，表面看起来也很是惊艳，可小问题很多，离实用还有一段距离。

回过头来说几句Atlas，这是个很强悍的可视化IDE，它完全用Cappuccino构建，包含了代码编辑器和界面编辑器两个部分－听起来很像XCode和Interface Builder的组合，对吧？实际也是如此，它的界面编辑器简直就是Interface Builder在浏览器上的翻版！而且从视频来看，还保留了Interface Builder的一些界面特效。

应该说他们能做到这步非常不容易，毕竟浏览器的能力在那儿摆着呢。可是我搞不懂Atlas中界面编辑器的意义何在，因为愿意使用Cappuccino的几乎肯定是Objective-C程序员，而目前Objective-C程序员必定用的是Mac，他们完全可以使用Interface Builder，然后用Cappuccino提供的nib2cib把Interface Builder界面文件转换为Cappuccino模板。既然如此谁还愿意用浏览器上的编辑器呢？

Atlas本月13号发布开发者预览版，具体有何独到之处，让我们拭目以待吧。

Mockingbird

最近冒出了不少基于浏览器的原型制作工具，比如Lovely Chart和Balsamiq Mockups，这两个都是用Flash做的，Mockingbird是第一个也是目前唯一的一个用JS做的工具。我曾和@soulhacker在Twitter上讨论过制作一个Web版的OmniGraffle克隆，在技术上遇到的问题就是，这东西必须得用Flash来做，否则辛辛苦苦写的JS很容易就被拿走了。因此我非常不解Mockingbird为什么选择用JS来做这事儿。

同Lovely Chart和Balsamiq Mockups比起来，Mockingbird在功能上并没有什么特别之处，基本上可以说它有的功能别的工具也都有，但，除了以下两个：

链接

用鼠标把界面左面pages中的页面图标拖到编辑区的某个元素上，就代表这个元素将会链接到这个页面。这不仅可以生成链接，更重要的是，通过这个功能你可以让你的原型具备交互能力！

分享

原型图做好了以后，可以按右上角的Share按钮，Mockingbird会生成一个链接地址，把这个地址发给同事，就可以直接看到效果了。这功能其实挺方便的，不用再把原型图上传到服务器上了。

-----下面帮朋友发条广告---------

注重独立的生活观念，关注服装、影像、时尚，以轻松的视角体察城市生活 www.ochosto.com

有人写了一篇非常详尽且图文并茂的博客，介绍了25个常见的IE6的bug及其解决方法。如果你还在IE6的泥海中挣扎，不妨看看这篇"Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs"。

读了老鱼的《前后端分离开发模式初体验》，暂时没有和他见面详聊的机会，所以就把读后感和想法写在这里。

08年春天我离开支付宝之前，曾和资金线的同事（主要是夏天）讨论过这种做法，即把view的部分完全交给前端开发，java程序员只需给出逻辑、接口、变量和数据。双方以接口文档为工作基础，用统一的开发平台（Eclipse＋SVN）来协调工作。另一方面，前端开发则不断地将Velocity/HTML封装成一个个的helpers，从而提高代码的可重用性，并以此降低编码难度（关于封装helpers这点，我曾在一次技术分享中谈过，不知老鱼是否还有印象）。我给这套方案起的名字是“开往中国的慢船”，在《为什么网页设计不应强调分工 2》一文中，我简要的介绍过。

从支付宝的情况来看，这种做法有比较大的可行性，既可以提高开发效率，又能把双方的工作边界定义的比较清楚。不过我当时即将离职，也就没有推动下去。这次看到老鱼的项目实践，很高兴。对于他说的那4点问题，我觉得：

1. 不知道这个白板究竟“白”到了什么程度？做html的时候运行调试ajax了吗？有没有和开发约定好往返的数据内容及格式？
2. 这个问题确实比较头疼，因为系分阶段根本不可能细化到变量名都定下来的程度。可能的解决办法有三个：一是考虑周全所有的流程分支，不能遗漏；二是管后台程序员要需要的数据，而不是被他的数据追着跑。比如这篇Creating Reusable Elements with requestAction所介绍的方法，就是让view在程序中占有了一个比较重要的位置（有点像web service）；三是逐渐把复杂的逻辑从view中提出来，返回到后台去，简言之让view变得更单纯一些。我觉得如果有必要的话，甚至可以引入“数据源”（datasource）的概念，把数据统一交到数据源中去处理，然后再让数据源和view交互。可以参考SproutCore的做法。
3. 问题C和D基本上基本上可以靠沟通和协调解决。另外对于问题D，或许前端开发可以考虑转到Eclipse上来。

简言之，“开往中国的慢船”这套方案的核心之一，就是把view让前端开发来创建和管理，在项目的前期及中期，前端开发就已经利用test fixtures创建出可以正常运行、几近真实、但又只包含view的应用程序来。

注：“开往中国的慢船”来自于村上春树的同名作品。我发起的项目或技术方案都以村上的作品作为代号，个人习惯。

写了一个新的jQuery插件，作用是根据你输入的文章标题，自动地将其中的英文字母和数字提取出来，然后生成一个slug。slug通常的作用是给blog文章一个漂亮的网址，比如你现在看到的这篇文章，它的网址是 http://dingyu.me/blog/posts/view/jquery-simpleslug-plugin，它的slug就是jquery-simpleslug-plugin。

这个插件在jQuery Plugin上的主页是http://plugins.jquery.com/project/jquery-simpleslug，觉得好用就投上一票 :D

演示

http://dingyu.me/blog/files/jquery-simpleslug-plugin/demo.html

用法

用法很简单，比如你blog编辑界面上用来输入slug的文本框的id为slug，用来输入文章标题的文本框的id为title，则只要如下一行代码即可：

$('input#slug').simpleslug({
	source: 'input#title'
});

source的意思就是生成slug的源文本框。除了这个参数以外，还支持以下两个参数

preview

你可以在input的旁边放一个id为preview的span，然后这样用preview：

$('input#slug').simpleslug({
	source: 'input#title',
	preview: 'span#preview'
});

这样插件会实时地把生成的slug显示出来，用处就是告诉用户这篇blog文章的完整的网址。比如你可以在span前面写上 http://dingyu.me/blog/posts/view/。

replacement

默认情况下单词或数字之间的间隔符是“-”。比如你输入“Hello world”，那么出来的slug就是“hello-world”。你可以改成你喜欢的，比如：

$('input#slug').simpleslug({
	source: 'input#title',
	preview: 'span#preview',
	replacement: '_'
});

和Wordpress集成

默认情况下，Wordpress会把文章标题整个作为slug，而有些人只想要其中的英文和数字。利用SimpleSlug的slugify()方法，这很容易：

1. 修改 wp-includes/js/autosave.js
2. 在文件开头加入如下代码：

   function slugify(str, replacement) {
   		//replace everything that is not a word character
   		slug = str.replace(/[^0-9a-zA-Z]/g, replacement);
    
   		//replace mutilple continous replacements
   		slug = slug.replace(eval("/"+replacement+"{2,}/g"), replacement);
    
   		//replace the beginning and ending replacement(s)
   		slug = slug.replace(eval("/(^"+replacement+")|("+replacement+"$)/g"), '');
   		//convert the slug to lower case
   		slug = slug.toLowerCase();
    
   		return slug;
   }

3. 找到文件中的

   jQuery("#title").val()

   替换为

   slugify(jQuery("#title").val(),'-')

4. 保存文件，搞定！

下载

http://dingyu.me/blog/files/jquery-simpleslug-plugin/jquery.simpleslug.0.1.js