Original Post:Interviewing the front-end engineer
Nicholas C. Zakas,2010年1月5日
翻译完成:2010年1月7日,最后更新:2010年1月10日

面试前端工程师对我来说是一件非常有意思的事,因为面试过程很大程度上也是自我提升的过程。无论大公司还是小公司,之所以在如何招聘到真正有能力的前端工程师方面会遇到同样的问题,就是因为负责招聘的那些人不知道自己公司需要什么样的人,结果问问题时也问不到点子上。经过这几年在行业里的摸索,我总结出了自己的一套很有效的面试前端工程的方法。

有的应聘者说我不好对付,但留给他们这样的印象也并非我所愿。我觉得之所以他们说我不好对付,主要是因为我问他们问题时问得太细了。以前我曾专门写过一些东西,告诉应聘者怎么才能通过我的面试以及怎样才能成为优秀的前端工程师应该具备什么样的素质,而我的面试可以说完全是按照那两篇文章的标准进行的。我不会问一些特别偏门的问题,也不认为出几道逻辑题就能考出人的真实水平。我唯一的想法就是确定你能否胜任我们要招的这个职位。为此,我需要简单地考察如下几个方面。

基本知识

我们生活在互联网时代,你想知道的任何事情几乎都能在15分钟内找到相关信息。可是,能找到信息并不等于你会使用它。我认为所有前端工程师至少都应该掌握某些基本的知识,才能有效地完成自己的工作。如果一遇到问题,就停下工作上网四处搜索解决方案,怎么可能保证按期完成工作呢?听听,还有谁在说“我不知道,但我可以上网搜到。”请这些同学把手举起来,让大家认识一下(immediately raises a flag for me.)。下面我列出一些基本的知识点,这些都是我认为一名前端工程师(无论工作年头长短)在没有任何外来帮助的情况下就应该知道的。

  • DOM结构——两个节点之间可能存在哪些关系以及如何在节点之间任意移动。
  • DOM操作——怎样添加、移除、移动、复制、创建和查找节点。
  • 事件——怎样使用事件以及IE和DOM事件模型之间存在哪些主要差别。
  • XMLHttpRequest——这是什么、怎样完整地执行一次GET请求、怎样检测错误。
  • 严格模式与混杂模式——如何触发这两种模式,区分它们有何意义。
  • 盒模型——外边距、内边距和边框之间的关系,IE < 8中的盒模型有什么不同。
  • 块级元素与行内元素——怎么用CSS控制它们、它们怎样影响周围的元素以及你觉得应该如何定义它们的样式。
  • 浮动元素——怎么使用它们、它们有什么问题以及怎么解决这些问题。
  • HTML与XHTML——二者有什么区别,你觉得应该使用哪一个并说出理由。
  • JSON——它是什么、为什么应该使用它、到底该怎么使用它,说出实现细节来。

重申一下,上述这些知识点都应该是你“想都不用想”就知道的东西。我一开始问的所有问题都是想摸清你对所有这些领域知识的掌握程度。虽然上面列出的这些知识点并没有面面俱到,但我觉得你至少应该掌握这些,才有可能跟我坐到一间办公室里来。

少量提问

我非常赞同面试者问的问题越少越好。反复问应聘者各种问题既不公平,也很无聊。我在任何一次面试中,通常只问三个大问题,但每个问题又会涉及我所能想到的多个方面。回答每个大问题一般要经过几个步骤,这样我就可以在每个步骤中穿插着问一些小问题。比如说: 查看全文 »

函数声明与函数表达式的有什么区别?
命名函数表达式的语义及其适用场景有哪些?
JScript、WebKit在实现命名函数表达式时“创造”了哪些bug?
SpiderMonkey在实现命名函数表达式是如何对规范“言听计从”的?

请看
命名函数表达式探秘

原文链接:http://yura.thinkweb2.com/named-function-expressions/
本文链接:http://www.cn-cuckoo.com/2009/12/22/named-function-expressions-demystified-1320.html

Table of Contents

  1. 前言
  2. 函数表达式与函数声明
  3. 函数语句
  4. 命名函数表达式
  5. 调试器中的函数名
  6. JScript的bug
  7. JScript的内存管理
  8. 测试
  9. Safari中存在的bug
  10. SpiderMonkey的怪癖
  11. 解决方案
  12. 替代方案
  13. WebKit的displayName
  14. 对未来的思考
  15. 致谢

原文地址:http://weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html

看来(根据一位专家的说法是这样,不过还是感觉有点言不由衷),JavaScript最后真的流行起来了

[此处是youtub.com中一段视频,可惜被"墙"了]

对我这个从小就呆头呆脑的人来说,这段视频像是咒语又像是玩笑。(这要看你是否跟我站在了相同的立场上:绿壳鸡蛋不就流行过吗?)

布兰登·艾奇深得他那尖脑壳老板的信任,Navigator浏览器应该有自己的脚本语言,只有开发一门新语言才可行,必须在短时间内设计和实现这门语言,现有的任何语言都不能充当该角色。

我搞不清楚为什么道格(Doug)要编故事。他并不在网景公司。他亲耳听到过我回忆JavaScript诞生的经过,我在Ajax大会的发言中也讲过了。难道是想混淆视听,想在Web开发人员中掀起一股提前讨论MicroHoo C#语言的风潮?

谁知道呢,要计较这些就没完了。不过,鉴于本周是我参与创立的mozilla.org 10周年,我打算讲一点历史。

正如我多次重申过的,而且Netscape的其他人也可以证明,我是因为Netscape要在浏览器中“实现Scheme”才被招聘进公司的。当时,至少负责客户端技术的汤姆·帕坎(Tom Paguin)迈克尔·托伊(Michael Toy)瑞克·谢尔(Rick Schell),以及一个叫马克·安德森(Marc Andreessen)的家伙认为Netscape应该在HTML中嵌入一种语言,一种源程序式的编程语言。而我这个新人要去说服“尖脑壳”的老板几乎是不可能的——实际上更多的则是他们在向我解释问题。

到底是不是要基于Scheme并没有定论,但Scheme确实是吸引我加入Netscape的一个原因。在此之前,我在SGI公司期间,尼克·汤普森(Nick Thompson)引导我学习了SICP(Structure and Interpretation of Computer Programs《计算机程序的构造和解释》)。

当时真正需要的是一种有说服力的概念验证,也就是一个演示程序。在我交付演示程序之后,这个程序在极短的时间内就变为了既成事实。

没错,在加入Netscape后不久,我被调出服务器团队——由于人员不足,我在这个团队干了一段时间,在那里与麦库尔·吐温斯(McCool Twins)阿瑞·卢奥托嫩(Ari Luotonen)有了一段时间不长但很快乐的合作;1995年下半年,阿瑞和我创建了PAC(Proxy Auto Config,代理自动配置)——的时候,Oak语言已经改名为Java,而Netscape正与Sun协商将该语言包含在Navigator中。

Netscape公司内部争论的最大焦点变成了:“为什么要包含两种语言?为什么不只用Java?”得到的回答是:必须有两种语言分别面向编程圣殿中的两类最不可能走到一块的开发人员:组件开发人员——这类人使用C++或(我们希望的)Java和脚本开发人员(爱好者或专业人员)——这类人编写直接嵌入在HTML中的代码。

至于是否使用已有的语言,而不发明一门新语言,也不是我说了算的。上峰的“军令”就是这门语言必须“看起来像Java”。这样,不仅排除了Perl、Python和Tcl,也排除了Scheme。后来,1996年,约翰·奥斯特豪特(John Ousterhout)前来推广TK时,还曾因Tcl错过机会而惋惜过。

谈不上自鸣得意,但我确实为自己吸收了Scheme式的一类函数和Self式的原型(尽管不那么主流)而感到高兴。至于Java的影响,特别是Date的Y2K bug和原始类型与对象类型(如string与String)差异的影响则是非常不幸的。

时光倒转回1995年春天:我记得在此期间见到了比尔·乔伊(Bill Joy),我和他讨论了垃圾收集的细节(card marking for efficient write barriers)。比尔一上来就完全理解了我们所说的一门易用的“脚本语言”与Java的关系,他还拿微软平台的VB与C++之间的关系作类比。据我所知,比尔是我们在Sun公司的支持者。

基普·希克曼(Kipp Hickman)和我在1995年4到5月间研究了Java,基普也开始写他自己的JVM。他和我编写了NSPR的第一个版本,作为他的JVM之下的可移植层。而我在5月中上旬创建Mocha的原型时,也将该版本用作了相同的目的。

比尔说服我们放弃基普的JVM,因为它会导致与Sun的JVM中的bug无法兼容(在那个时候可谓智慧的预言)。而此时此刻,Mocha已经通过在Netscapte Navigator 2.0(的初期测试版)中的快速原型和嵌入证明它自己。

除此之外,应该说都是对历史的歪曲和调侃。JS在客户端打败了Java,只有Flash能与其竞争,而Flash又支持JS的一个衍生品——ActionScript

现在再回到流行的问题上。其实谈不谈这个问题都无所谓。然而,那些散布于互联网的流行的Ajax库,却经常以被掰碎了、压扁了,然后再以链接形式挑出来的纯文本的形式存在。难道不可以共享吗?

有一种想法——受到了不少人的质疑,最近一次发出质疑声音的人是道格——在可能将会非常长寿的script标签属性中嵌入“神秘的散列码”(crypto-hashes)。这是个好主意吗?

恐怕不是。一方面因为“神秘的散列码”理论上的完备性问题,另一方面则因为其广为人知的药饵攻击(poisoning attacks)。

还有一个主意倒是不错,这个主意我是先从罗布·塞尔(Rob Sayre)那里听说的:通过HTML5中script标签的share属性支持一种可选的“公认的URL”:
<script src=”http://my.edge.cached.startup.com/dojo-1.0.0.js”
shared=”http://o.aolcdn.com/dojo/1.0.0/dojo/dojo.xd.js”>
</script>

如果浏览器首先下载了共享的URL,而且根据HTTP的缓存规则它依然有效,那么就可以使用缓存(及预编译)的脚本,而不必从src属性指定的URL中下载。

这就避免了散列药饵的问题。这个方案只要求内容作者保证src属性指向的文件与share属性指定的这个库的公认(或流行)的版本相同即可。不过当然,我们必须信得过相应的DNS。(Ulp.)

这个方案可以避免在script标签属性值中嵌入不可预测的散列码。

欢迎大家就此问题给我留言。

好了,这次真的回到JavaScript流行的问题上了。我们都知道有些Ajax库的确流行。那JavaScript流行吗?很难说。有些Ajax开发人员表示(也证明)了对它的喜爱。但也有很多人骂它,也骂我。我依然认为JavaScript是C和Self草草结合的结果(或一个私生子)。我又想起了约翰逊博士(http://en.wikipedia.org/wiki/Dr._Samuel_Johnson)的那句话:“好的不是原创的,而原创的都不好。”

不过,这没什么。Web总要发展,否则只有死路一条。JS也一样,要不就不会有ES4了。说到ES4,很快将有下文。

Firefox 3好像也会流行的, 它的空间与时间性能测试预示了这一点。相关内容呢,我以后还会陆续地谈到。

提示:由于目前正在抓紧时间翻译Professional JavaScript, 2nd,预计春节之前没有时间翻译这份论文了。对自己,也对大家,更对“CSS之父”说声抱歉吧!

中文链接:www.cn-cuckoo.com/css/thesis-of-Hakon-Wium-Lie/

原文链接:people.opera.com/howcome/2006/phd/

查看全文 »

想知道怎样在今天的Web上创造伟大的用户体验吗?UI专家Bill Scott和Theresa Neil通过本书向读者展示了超过75种基于富交互构建Web界面的模式。作者以自己在Sabre、Yahoo!和Netflix多年的工作经验为依托,把精挑细选的各种最佳实践归结为6个重要原理,深入浅出地向读者阐释了如何有效利用当前的Web技术。本书每一部分都围绕一个设计原理展开讨论,通过学习本书,读者可以掌握以下原理。

直截了当:通过页内编辑、拖放和直接选择等模式实现基于上下文的内容编辑。
简化交互:借助“轻量级”上下文工具,有效减少用户与站点的不必要交互。
足不出户:采用覆盖层、嵌入层、动态内容和页内流程模式保证访问者不离开当前页面。
提供邀请:向用户发出进入下一级交互的邀请,帮助用户发现站点的功能。
巧用变换:学习何时、何地、以何种方式使用动画、电影转场效果及其他变换手段。
即时反应:以实时搜索、实时建议、实时预览及更多模式,为用户提供丰富的交互式体验。

本书以当前最流行的Web站点为例,介绍了大量行之有效的Web界面设计模式。如果你想构建或重构站点,并希望站点以丰富的交互为特色,那本书就是你出奇制胜的宝典。

“本书提供了富因特网应用程序(RIA)设计人员和开发人员(或开发团队)作出明智选择时必须知道的一切。对于当今主流的Web设计师而言,(本书)应该人手一册。”

——Erin Malone,Tangible UX负责人

当当网读者评论

读者:Drek
来自:广州市
标题:很多新的,流行的理念
评分:4星
发表于 2009-10-11 23:53
我是个程序员,可惜在的公司太小,美工,前台,后台,设计,样式都要一手包办。其实挺郁闷的,为了在点脱离这情况,学多点广博的知识,早日飞翔,成就梦想。
而涉及到的知识都要去看,去学。
界面也要自己去处理。所以看到了本书,站在一个程序员的角度考虑,里面的设计思想其实很潮的。没有你想不到,只有你做不到的。书是针对界面设计,没有任何提及程序,代码如何实现的,也没有提及美工方面如何处理的。
可以说同一个设计相思,可以用不同东西去实现,只要你会的。
所以感觉如果作为程序员,又要考虑界面设计的朋友,本书值得一看。如果就美工和单纯是界面设计的,也给予了你不同的设计思想。
当然,世事没有完美的,程序,界面或者流行一时,2,3年间也许变化很大,为了适应自己的工作,或者适应这个时代,可以得到的资源都不要放过哦 查看全文 »