The formal way is name your timezone in config file, but for the case of output iso 8601 format datetime in UTC timezone, it’s not elegant to ask for this information. The tricky part is get your local timezone. Since timezone is not in system environment variable, so it’s kind of hack to let it work with small code footprint. I know I’m stupid, but let me post my solution here. If you know better solution, please let me know.

try:
    local_tz = pytz.build_tzinfo('localtime', open('/etc/localtime', 'rb'))
except:
    from .poorman_tz import LocalTimezone
    local_tz = LocalTimezone()

def isoformat(dt):
    if dt:
        return local_tz.localize(dt).replace(microsecond=0).astimezone(pytz.utc).isoformat()
    return None

The LocalTimezone is from python’s datetime document, just copy that section of code and you get this poorman’s implementation of LocalTimezone. Thanks my coworker Stan pointing me out the solution to build a timezone from /etc/localtime, also for this smart guy answer that stackoverflow thread. BTW: python’s datetime has microsecond information, I don’t need them so I replace them with 0, it makes the datetime string shorter.

首先要明确 饮酒 和 品酒 的区别。品酒应该是饮酒的一个子集，因为不喝下去完全闻味不是靠谱的品酒方式。品酒最大的区别在于为什么 (Why) 和如何做 (How) 不同，品酒的目的是分辨、欣赏、交流。

品酒是对模式识别的锻炼。模式识别是心智模式中的R模式，也就是一种基于图像的思维，模式识别是一种直觉。品酒必须要用语言记录，可以是和朋友在一起交流感受，或者写下来分享给更多的人。为什么品酒必须要交流呢？因为模式识别是R模式，但是人和人交流要使用语言逻辑，但是这种逻辑使用的是心智模式中的L模式。但是根据心智模型的理论L模式和R模式往往不能同步工作，如果一个人两个模式之间交流迅速和频繁，那么这个人表现出来就是 聪明。R模式和L模式交互有一种形象的表示法，我们管它叫做“比喻”。使用比喻能力强的人，我们一般说是文学能力强，但是其实更广义的说使用比喻能力强的人 聪明 。我们有一个更时髦的词叫“隐喻”，这是在各种专业能力中非常重要的一种基于直觉的技能，我们常说一个领域的大师具有的就是过人的直觉。或者说过人的 模式识别 和使用 隐喻 的能力。所以那本书说，幽默其实是一种使用 隐喻 的特殊能力，不管是使用幽默还是感受幽默都需要这种 隐喻 的能力。

如果大家读过酒评就知道为什么我说 模式识别 和 隐喻 了。这里举个例子：

花香显著，并带有新鲜果香：柑橘、杏桃、荔枝、麦香，些许糖香。深琥珀色片红，入口时的发泡感强烈，使酒体感觉轻盈。酒液有些浑浊，泡沫丰富有粘性。酒体的厚度中等，酒感稍若，具有相当的苦涩感。苦味强劲，有酸味的错觉。烧烤饼干，红色果香，榛果杏仁。回香中有花香，苦味显著。余韵甘苦带涩，有果香，麦香与啤酒花香。又有非常好的复杂度。

摘自《比利时啤酒——品饮与风味指南》

这里用到了很多的隐喻。经常交流的啤酒爱好者可以看到大家使用的不同隐喻，并把他们使用到自己的语言中。这个过程还培养了对味道细节发现的能力，因为经常品酒后对很多味道的轻微痕迹描述的能力会增强，所以就可以更好的发现原来不能描述的味道。这其实就印证了很多朋友学习中的一个感受，当你能够定义和命名一种现象以后，你在遇到问题的时候识别的能力增强了，最后解决问题的能力也增强了。在搞编程的朋友中，都知道Martin Fowler，他就是以这种能力著称。

最后，我想强调我说的是 品酒 ，很多极端的品酒者品尝酒品后会吐掉，以防止对辨别能力的影响。我们需要强调这样的精神，不要陷入把饮酒作为简单的习惯的地步，那样很容易酗酒，结果是很严重的。要保持 Know How 的同时 Know Why，这样可以长期健康的品酒。

我目前品酒主要使用Instagram，照下酒评和酒杯，可以观察酒体和泡沫。然后在评论里面写下对啤酒味道的品评笔记。我主要使用 #mahbeer 这个标签分享，这个标签下有很多非常棒的啤酒的分享。而查啤酒比较重要的工具是 Ratebeer ，上面有大部分你能喝到的啤酒的信息和众多酒友的评价。

附上我非常早期的一个酒评：

• 使用的是和Duvel类似的高级蛇麻草，非陈年款，味道比较鲜明，微苦
• 有麦香味，水果味收敛，味甘甜，回味发甜
• 香味不太明显，不酸，也不太苦，没有特别突出的单种口感
• 泡沫丰富，细密，泡沫很白，大约有酒体的一半高
• 酒色金黄，略微浑浊（雾）
• 有肉蔻的香味留下，酒通过喉咙感觉酒精刺激明显，留下微微的薄荷的味道
• 酒后口内没有酸和苦的回味，说明酒不是很甜酒花量也不是很大

能猜到这是啥啤酒不？（是Westmalle Blone，一种修道院啤酒 Trappist beer，不过属于没啥特点的一种）

语义网是让机器可以理解数据。语义网技术，它包括一套描述语言和推理逻辑。它包通过一些格式对本体（Ontology）进行描述。如W3C的 RDF就是这样一种描述规范，它描述这些数据所表达的含义还有这些词之间可能产生的关系（动词？），那么计算机就可以通过查询（推理规则）来产生我们需要的数据视图了。也就是说如果你对计算机提问，因为计算机理解数据，所以可以推理出你所想要的答案，即使这个答案不是预先准备好的。大部分的语义网的表示规范都基于XML，因为它是一种完备的通用描述语言。

HTML选择文本协议是因为文本协议便于人类与计算机阅读。其实要注意一个重要的历史细节，是email激发并帮助产生了互联网技术。email相关的第一个RFC（RFC 561）在1973年就有了，而TBL大神在1989年提出超链接技术才标志着WWW的产生。

使用文本协议是因为原先传递消息不是为了让计算机存储和理解的。最早的email就和我们现在的短信的想法差不多，两个计算机同时在线用modem传递一些文本信息给使用计算机的人去读，这个时候的文本信息没有链接（没有链接就不是网），纯粹就是文本块。

而后来为了让email里面能保存非文本的数据，并且不破坏原来的协议兼容性，所以催生了非常非常重要的MIME协议（Multipurpose Internet Mail Extensions）。

因为有了email的协议族（包括传输协议和MIME）以后，在计算机之间通过纯文本消息体已经可以交换各种数据了。但是这个时候传递的只是数据，数据之间是没有关系的。

Hypertext是在文本协议上面扩展了表示文档关系（超链接）的能力，它就让原先的文本变成了网络（关系）。这种文本表述协议HTML的第一个RFC是1995年的RFC 1866。而我们可爱的HTTP在1996年才有了HTTP 1.0（RFC 1945）。

你基本上可以按照RFC来排这些技术的辈份……

强调这个历史是想说明计算机可理解不是这组协议的目的，因为计算机可以解析二进制，用二进制更高效（传输和解析）。这些协议最早是为了人类可读而设计的，所以都基于对计算机不那么有好的文本协议。文本协议人类调试起来会高效很多。

那么这和语义网有什么关系呢？

因为HTML不是为了计算机可读而优化，所以HTML的解析实际上是一个比较头疼的地方，这个是所有写过HTML解析器的朋友都知道的。HTML很多时候真的是一锅粥，模糊的语义很多时候靠猜。

所以，有了著名XHTML，它的目的是让HTML套上XML的外衣。XML是啥呢？XML的最初目的就是设计一种计算机和人类都可读的协议，由于人也就能读文本，所以它是一种文本描述语言。让HTML符合XML的规范就计算机（机器人）和人类都皆大欢喜了。而后有了XHTML 1.0，当时的“网站重构”活动所有经历过那个时代的朋友都亲身体会到了。多了一些强制的写法，写XHMTL解析器的朋友们就不用哭泣了。不过后来大家发现写XHTML的朋友经常会有语法错误，另外一些朋友则对HTML 4.x灵活（模糊）的语法恋恋不忘。

由于还是有很多朋友发现XHTML让计算机真的跟容易理解文本的结构，所以那些人继续狂热的做XHMTL 2.0，但是这是个不归路。而且对于消费HTML的大部分人类来说这都没有爱，所以最后这个标准被抛弃了。

人类理解文本字面以外更重要的是把这些概念抽出来理解，人类需要知道文档的结构是什么。研究协议的人们都是高端人才，天天写paper……（我这个是纯演绎）所以他们觉得应该让HTML能够很好的展现他们的写的字（文本）的这种章回的结构，所以就把文档的结构的隐喻放在了HTML的文档模型（BOM和DOM）上面，所以HTML协议里面是包括tag和tag所表述的文档中的隐喻的定义的，这样人类阅读这些文本的时候就把文本和一个文档（某个paper）的结构映射出来了，那么浏览器就可以把他渲染的让这些标准制定者高兴了。

但是后来大家发现光有文档没有索引不行，所以搜索引擎越来越重要。可是搜索引擎不是都像Yahoo那样是人肉编辑的，后来的主流搜索引擎都是基于对查询文本和网络上的文本的相关度进行搜索的。但是网络上的文本要取下来并按照文档结构解析是需要机器人(爬虫）的。所以机器人读网页的权利被越来越多的重视起来，那些搜索引擎优化不就是想骗过这些机器人的算法么。

当然这里又回到一开始的语义网了，因为人们的查询不光是字面匹配，人们希望使用更聪明的搜索引擎。那么搜索引擎应该知道用户的意图，这不是什么人工智能，而是一些基于统计的算法。但是这些算法都和语义网中的一些东西有相关性，因为人们需要得到数据，并且找到这些数据的本体，通过一些预先定义好的本体之间的关系进行逻辑推演（目前都是写死的算法，而没有使用语义网里面的推演系统）。也就是说这个模型从概念上和语义网相似，但是由于技术上还不太可行，所以走了其它的路。不过从理解文本的这个地方来说，所有的现代搜索引擎都有这方面的逻辑。它希望把搜集到的文本描述成一种可以推演的数据，在语义网里面描述这些数据的方式之一是RDF。RDF基于XML，而HTML中的XHTML是一种XML。通过HTML的attribute储存语义网数据叫RDFa（Resource Description Framework – in – attributes），这就把HTML/XHTML和语义网技术拉到了一起，当然光表示数据只是语义网的一部分。

和RDFa相似的东西还有microformats（老早我就力挺microformats，不过后来这东西被好多人断言说已经死了，还好后来micro-data火起来了），它把语义数据放在node text或者属性里面，并且通过css class来表达数据结构。但是他们只表示了结构，我们还没法映射到本体。那么Microdata就是这样的尝试，它定义了一些词汇表，表达某一些常见的格式，通过这些词汇表就对应到了数据的本体。

到这里这个圈子就转好了。语义化需要让数据和表述的本体的映射成为可能，那么结构首先要可以表达出来，并且通过一些结构的约定俗成（或者直接声明）让计算机可以找到这些结构的本体，然后计算机就可以通过本体的关系来进行逻辑演绎。目前我们能真的达到约定俗称的东西还很少，大家看看micro data。但是先不要说终极理想，也就是让我们的大网成为语义网。我们目前可用的技术里面应该充分的考虑到可怜的机器人非常弱的理解能力，尽量说一些约定俗称的东西，这样机器人就可以帮我们进行一些我们人类不太擅长但是它很擅长的推理计算了。那么最好我们能够让我们的文档在描述相关的本体的时候使用计算机更容易理解的结构，这就是语义化。也就是说用某一种模式来表达计算机可以理解的词汇，这就是HTML的语义化。

当然现在又一个巨大的问题，那就是HTML的文档模型和我们平常要表达的映射直接没有隐喻的关系，而且这个差距是巨大的。我们开发Web Application无处不受这种限制的影响，所以性急的人们才把HTML5变成一个永远演化的协议，来保证我们更及时的把我们想要的一些新的结构、语义加入到HTML这个文本描述协议里面。

那么最后强调一下，语义化真的不是为了我们人类。语义化是我们人类博爱的体现，我们也要照顾可怜的机器人，让他们能够很好的通过自描述的结构逐渐掌握我们人类的词汇，理解我们人来在说什么，这样它就可以更好的为我们服务。语义化真的是Web开发人员表现出来的可贵的人性！

相关词条链接：

• Semantic Web
• Email
• World Wide Web
• HTML
• Hypertext Transfer Protocol
• XML
• RDFa
• XHTML+RDFa
• Microdata (HTML))
• Microformat

Good to know that sparrow is using tokyo-cabinet. And it sounds like a great way to optimize tha data file safely.

Please quite sparrow.app before you run this.

But when I run: tchmgr optimize ~/Library/Application\ Support/Sparrow/my.email.account.sparrowdb/data.db/data.tch

I got this error:

tchmgr: ~/Library/Application\ Support/Sparrow/my.email.account.sparrowdb/data.db/data.tch: 6: invalid record header

After a googling, I found the parameter -nl should fix it.

So I tried run this command again:

tchmgr optimize -nl ~/Library/Application\ Support/Sparrow/my.email.account.sparrowdb/data.db/data.tch

now it fix the db and renamed the original file with a temporary name:

data.tch                    data.tch.tmp.1209295.broken

Please open Sparrow to check if the db is OK. If you can see your message then you can delete the .broken file. Otherwise, please copy the borken file back.

In my case it do reduced the db size:

-rw-r--r--  1 tin  staff   1.7G Aug 21 13:12 data.tch
-rw-r--r--  1 tin  staff   2.6G Aug 21 13:14 data.tch.tmp.1209295.broken

Unfortunetely I saw some message can’t be rendered anymore, so I copy that db back again.

If the db is borken and can’t be recovered, Sparrow has a official way to reset a local cache and synching that again. Just delete the Info.plist file in your sparrwodb folder.

OK, the simple reason is everyone move to SublimeText 2. You will see almost every developer at Backbone.js conference using SublimeText 2 to do live coding demo. That’s cool, just because those speaker is cool. OK, cooler thing is half of developers at that conference is using SublimeText 2 (BTW: there is a developer using Windows). I was using TextMate 2 alpha when I was at that conference.

Why I’m not moving? Since I’m not a hipster, I ask reason for a move. The de-facto editor of choice is TextMate if you develop on a Mac. Used to be. But the developer abandon users, and it’s a typical vapoware. That’s sad. So smart people go to try alternatives, and smart people change their muscle memory quickly. But I’m a slow guy, I was hijacked by the bundles and themes and all muscle memory. But I do ask my colleague and developer friends which alternative editor they are using. But unforturnately there are no reason move my mind (gravity of laziness).

So, why I need a reason? Since the most dangrous thing is lost your introspect abbility. We call something science. But the sarcasm aspect is there is theory said there is no truth but only explanation. An explanation is a saying (theory) describing what’s beneath the truth, and we will using our sensation to test (or set a lab to prove it, test it) it. If that explanation match the fact we sensated, then we call it science. So this is a process of proving a explanation is close to fact or truth. This process is all about asking why on something even you know how or what (a defination, or explanation). Forget asking why means lost mind. Zen has some practice on observing the detail of feeling and thinking, for me that is keep asking why, know why on details. So sounds like this approach is close to science.

Until my colleague point this on that conference. He said “SublimeText is blazing fast, see how smooth it is to open and preview source codes…”. Then I realize I got a reason in that moment. TextMate is slow now. Actually TextMate 2 got slower than TextMate I feel. Since TextMate 2 solve the Chinese character display issue, so I found it’s better than TextMate 1.5, that missing feature is the worst one I had. So feature shouldn’t be reason for moving SublimeText 2. I don’t use split panes regularly, use json as preference is not attractive …

But let’s back to a perquisite question on editor war. Why we want to use editor over IDE? Since IDE is fat, bloated, vendor locked, slow. Since IDE is not (simple, small, flexible), but every developer love (simple, small, flexible). Jeremy Ashkanas said (simple, small, flexible) are traits of Backbone.js library. So, text editor is (simple, small, flexible), that’s a reason I’ll buy. So when my colleague told me how fast is SublimeText 2, I was moved.

The main reason of writing this post is not tell some hipster I was allied. I’m asking myself why, and ask you to ask yourself why. Recently I read a book called The Shape of Design, that’s a good book indeed. It use a metaphor of mockingbird, so that bird learn some sounds and song, but it never know why mocking like that. Only know how and what is dangrous, keep searching why is vital. That’s a why of being interest driven, or at least make sure you are driving by something you know. So you know why of each details, you know how to explain to other people. And you knwo why you are wrong, since every piece of change will notify you do a full introspection again. This helps, let you thinking independently, since you know why. Hope you always know why, I know that’s totally impossible, we never know the truth.

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

这一个 Post 是所有 Talk 所做的笔记的索引。

第一日的话题

每个 Talk 我都做了比较详细笔记，下面是链接，请点开查看：

• #BackboneConf2012 Keynote for BackboneConf by Jeremy Ashkenas
• #BackboneConf2012 Ember.js by Yehuda Katz
• #BackboneConf2012 How to Argue about Javascript by Andrew Dupont
• #BackboneConf2012 MVC Module Magic (through require.js) by Alex Sexton-
• #BackboneConf2012 Testability in Mind by Vojta Jina
• #BackboneConf2012 New Dog, Old Tricks by Rebecca Murphey

第一日话题后的酒会

第一天的内容就结束了，当天的酒会很成功。很多前端程序员都是Beer geek或者Scotch geek。

就会上逮到了 Jeremy 本人，我记得趁着酒劲我问了几个问题：

• 您这代码都怎么写出来的？您有没有TDD呀？ Jeremy 说我一般不写测试，不过为了保证质量，他会补充一些测试。他说我就是 write codes which make sense ……好的，Make sense是对直觉型程序员常说的。彪悍是不需要解释的。
• 您平常也看别人的开源项目获取灵感么？您如何平衡写自己的东西和看别人的东西？ Jeremy说，啥？我写代码那是为了糊口，看别人的代码那不挣钱呀。所以我一般不怎么看别人的东西，我就写我自己的东西，我觉得 make sense 的东西，当然要写的 make sense ……
• 我还问了一些问题，酒劲比较大，我忘记了

第二日的话题

每个 Talk 我都做了比较详细笔记，下面是链接，请点开查看：

• #BackboneConf2012 Lumbar Support by Brad Dunbar
• #BackboneConf2012 Migrating a Large Project to Backbone.js by Sam Clay
• #BackboneConf2012 Real-World Realtime with Backbone by Henrik Joreteg
• #BackboneConf2012 Airbnb’s Journey Into Mobile Web by Harrison Shoff
• #BackboneConf2012 Y.App: Coordinating URL Navigation, Routing, and Managing Views by Eric Ferraiuolo
• #BackboneConf2012 The Plight of Pinocchio: JavaScript’s quest to become a real language by Brandon Keepers

第二日话题后的论坛

我去，第二天最重要的是一个Panel，不过非常倒霉，我的飞机不允许我听完全部。

参与Panel的有：Jeremy Ashkanas、Yehuda Katz、Vojta Jina、Eric Ferraiuolo、Andrew Dupont
主题是Javascript’s Future

主持（@BoazSender）很弱，问了一堆很弱的问题。

我记得的一些点是：

• 所有人都同意框架不是作者凭空想出来的，都是他们把实际交付的项目的代码中可以复用的部分抽出的结果。也就是说成功的框架都不是为了写一个框架而写出来的，而是为了解决某一种实际问题的解决方案。所以停止根据某个灵感而发明一种框架这种想法了。
• Yehuda Katz 很擅长吵架，死磕 Jeremy ……（@wycats says he agrees with @jashkenas in principle, but he thinks it’s been taken to a place that neither of them like）
• Jeremy 强调了 Node.js 社区烦的一个错误。Javascript 是为浏览器而生，并且繁荣的。所以 Node.js 的 Javascript 应该尽量兼容在浏览器里面可以运行，尤其是一些通用的工具库最好不要忘记浏览器。
• Jeremy 承认 CoffeeScript 是有人喜欢有人恨，但是它最杰出的地方就是真正影响了 Javascript 下一版本的语法。开发者有权决定自己用什么，只要他觉得自己的工具 make sense 就可以了。
• Jeremy 认为 HTML 并非为application设计，所以HTML的元模型并不完全匹配application，这是个未解决的问题
• 我们应该如何选择框架呢？研究所有的框架找到你要的，还是学好一个框架并使用下去。因为框架是作者的美学取舍的结果，这是不好评价的。Yehuda说应该看api的数量和它能做的事情的比率，api数量大做不了事情的东西是不好的。Jeremy说傻X才写那样的框架呢。
• 如何区分框架和库呢？”a framework calls you, you call a library” 这是 Jeremy 和 Vojta 的答案。

大家可以看 @knowtheory 的 twitter ，在5月31和6月1两天有很多tweets报道 #backboneconf

BTW: Beer

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

The Plight of Pinocchio: JavaScript’s quest to become a real language by Brandon Keepers

Links

• Slides

Notes

这为是 Github 的前端工程师。

不好意思，这个话题的时候我实在坚持不住，一直在打瞌睡和惊醒间切换。

If we are going to use JavaScript to do real work, then we have to do the things that we do with real languages.

这就包括这些Buzz word：抽象、TDD、关注点分离、DRY、重构、解耦、设计模式、封装……

目的是可维护和容易扩展。

然后作者开始演示哪些设计模式有意义（着重介绍 MVC ），重构，DDD，并且 TDD 这个过程。

Test driven development is a design process. （我深表同意，不过最近连 Dan North 也就是 BDD 作者都来拆台）

整个 Slides 还是很好的，充满了各种重构的例子，使用 jasmine 写的测试。

不过真正有趣的部分出现在 Q&A 阶段：

某人站起来问 @bkeepers 请问 Github 是如何测试（人家没问如何TDD）的呢？

然后 @bkeepers 说一线的代码不是我写的，然后叫了现场的一个 Github 同事回答这个问题。然后他的同事非常尴尬的站起来很不好意思的说：”大哥，咱 Github 不写测试的“……全场哄笑。

然后 @bkeepers 笑着说：“看我回去教这帮坏小子如何写测试去……”

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Y.App: Coordinating URL Navigation, Routing, and Managing Views by Eric Ferraiuolo

Links

• Slides

Notes

这个哥们是YUI团队的，推荐大家 Follow （@ericf），非常有见解。

他整个话题的核心问题是URLs，是很讲究的地方：

• http://example.com/foo/
• http://example.com/#/foo/
• http://example.com/#!/foo/

这是个争论的地方，也就是著名的 hash bang (ref Backbone.js: From Hashbangs to HTML5 PushState)。很多人都表示 #! 是很讨厌的东西，它让妨碍了对于数据（视图）的直接访问。因为 hash 的语义不是 path。

但是很多人会提出一个真正的问题，如果只做了一个 single-paged app，但是如果你部署在一个 Dumb server（只能服务静态文件的服务器）怎么办？这种情况下你只能使用 hash url 了。

Hash Bang 问题的另外一个核心是初始状态的问题，也就是第一次 http 传输给用户的内容。传统的 hash bang 只返回静态页面，ajax call 再去取 hash 对应的 data 进行渲染。也就是说初始化的数据是不完备的，需要更多的 http 请求才给用户传输了真正有意义的内容。

所以，最好预先把数据在服务器端渲染好，直接传输给用户。减少 http 请求对于 mobile 用户就更加重要了，因为 Radio (手机无线数据连接) 的省电算法，还有无线数据传输通道建立的延迟达到数秒，http 传输的额外开销（延迟）非常恐怖。这就显得更加重要。这也就是为什么最近 Twitter 写了一个博客说他们已经改为预先在服务器端渲染好 Twitter 而不使用客户端模板引擎去渲染了。Twitter 放弃 hash bang 以后第一次数据载入的快了5倍！

而且，用渐进增强的思路，使用传统的页面预先渲染（URL 转换页面）的模型很容易使用 pjax+pushState 增强。比如 github 就是用这种方式实现的，它结合了 ajax 的保持当前页面状态（减少 parse 和初始化事件，不需要重新载入整个页面）、局部更新等很多好处，给用户的感觉就是快。而且 URL 上面它保留了每个页面 path 的可访问性。

pjax就是截获了 <a> 元素的点击事件，这是完全渐进增强的。

还有一个好处就是你可以控制页面 cache，页面局部缓存，返回可以变得很快（没有 http 请求）。

但是，这里还有一个分裂：

/foo/ 和 /#/foo/

如何统一两种风格呢？（这样无论是否是 dumb server 都可以让你的 app 正常运行，在可以不用hash的场合使用更好的 path 取代 hash）

你需要一个更强的客户端 Route Handler，作者的 Y.App（包括 Y.PjaxBase、Y.Router、Y.View）是个例子……余下就是 Y.app 的一段 demo，也算广告。

这个话题非常好，因为它解决了 Hash bang 的争论，我们是应该让 Web 的最基本的 hypelink 不被破坏，应该正确的使用 URL 的语义。但是我们也应该用渐进增强的思想利用我们强大的前端的状态管理功能，让 Router 来处理初始状态的导航和组装。

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Airbnb’s Journey Into Mobile Web by Harrison Shoff

Links

• Slides

Notes

注意，作者不是所谓的前端工程师，而是前端设计师（作者自称doodler）！！！设计师也可以用好Backbone.js的。

Airbnb是个很酷的东西，团队也很酷。他们的基础设施几乎完全基于Amazon的云服务。
Server放EC2，负载均衡用ELB，Hadoop用EMR，存储用S3，数据库用RDS，监控用CloudWatch，Cache用Elasticache

他们的前端是CoffeeScript + SASS + Backbone.js

这个项目比较有趣，因为他们的mobile website很丑，所以他们决定在他们的主力前端休假的时候由作者这个半吊子前端重写这个很独立的mobile website。实际上他们有10%的流量到那个很丑陋的网站。

他们准备在6周内（新年前）完成这个项目。项目的两个人完全没有做Mobile website的经验。然后他们碰巧看到了Backbone.js和coffeescript，看起来不错就用了。你看……不较真的人多好，运气好就能选对东西。

然后，你就会惊讶到做好一个产品是在是很看人的，他们的设计过程非常棒……请参看slides

具体的技术内容都是大路货，就不赘述了。这个例子很好，首先是从无到有如何用好Backbone.js。其次是如何在秘密飞行模式再公司内部做一个Startup工程，还有如何画原型如何自己写代码做好一个产品。最重要的是，一个设计的靠谱的UX流程对于交付一个好的产品是多么重要。

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Real-World Realtime with Backbone by Henrik Joreteg

Links

• Slides

Notes

这是一个非常酷的Talk，节奏紧张，华丽。

Backbone makes doing that (build complex stuff with javascript) cleaner and more fun!

Single-page app && Realtime app?

如果你是一个Javascript developer，你早晚会接到这样一份工作的。

作者的公司叫做&yet，他们做了很多实时应用。他们当然走过很多弯路，罄竹难书呀~

那么如何定义实时应用呢？他们的定义就是”Push not poll”……这虽然比较tricky，不过在http模型下这是接近realtime的关键。

那么，他们不使用Backbone.sync支持的这些被动的fetch（因为这样是pull，模型就会是polling）。

他们使用了socket.io，所以可以socket.on(‘someEvent’, do something)了。

不过没有了sync，Backbone还剩啥？

一般实时应用的流程是：

• Auth / Connect
• 获取初始化数据
• subscribe一些事件的更新
• 调用服务器上面的一些 RPC或者script

他们的例子是一个实时的地图应用：https://go.recondynamics.com

然后，他提出了一个被众人热烈鼓掌的Slogan：

“State duplication is EVIL”

Henrik（@henrikjoreteg）曾经推过：

“In a big single-page JS app, how far should I go to store all state in outside of the DOM? For example, checkboxes are stateful by design.”

Jeremy Ashkenas（@jashkenas）回复：

“In my opinion, precisely zero state should be stored in the DOM. What if you have more than a single checkbox for the option?”

Backbone正是在这种思想下产生的，Model是single truth of page。

实时应用的传输的方式有很多选择，传输过来的东西都是修改Model状态的就好。也就是说Backbone.js的应用如果写的好，转到实时会是很简单的事情。因为大家都围绕Model进行操作（传输Model，用户交互，服务器事件修改Model），所有的其它组件监听Model的event消费Model的数据就可以了。

所以，作者推荐要早一点重构、经常重构、更好的重构。

不过，这样说做实时应用就太没有挑战了。实际上主要的挑战是timing的控制、Event相关性（前端后端、各个系统）、UI组件复杂，系统的Event和Model之间没有关联…… 所以实际上实时应用的挑战还是很大的。

那么为什么不去用一个实时Web应用框架呢？如：SocketStream、Derby.js、Meteor.js、Capsule.js

这些框架都承诺了很多：

• 共享前后端代码
• 前后端无缝的状态控制
• 自动更新的模板
• 自动的冲突解决
• 热部署

听起来很Cool，不是真的有那么 Practicool（实际上有那么酷）？

作者解释了他们尝试在Node.js上面通过Socket.io共享Backbone.js Model的尝试，结果是失败的：

• It’s hard to manage data (Backbone Model)
• Very little structure (Backbone Model)
• It makes partial sync state hard
• Very good for prototyping
• Backbone isn’t a great way to define your data schema
• Benefits from code sharing were minimal (On server/client model sharing, that’s so true)

然后作者介绍了他们尝试Backbone.js（前端）配合Capsule和Thoonk的实时应用架构。Backbone.js在后端完全不存在了，前后端没有任何共享代码。

因为服务器端和客户端处理的问题其实是不同的，所以应该使用不同的解决方案，不共享Code。

最重要的原因是 Security！！！

然后整个会议上面最重要的一个Slogan出现：

Sharing code is cool.

Sharing underwear?

Not so much.

也就是著名的在服务器端和客户端共享代码就好比共享内裤一样……

因为数据和传输（接口，或者按照REST的说法，那叫视图）是应该独立的。否则，当你需要不同的视图的时候，会更加灵活。

作者提出了在Backbone.js实现实时应用时候遇到的一些问题，希望大家帮忙找到更好的解决方案，wishlist：

• 清晰区分传输的app状态，和View端的app状态
• unbind view，也就是view destroy，也就是View生命周期的那个问题

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Migrating a Large Project to Backbone.js by Sam Clay

Links

• Slides

Notes

Sam Clay是Jeremy的同事，是DocumentCloud的前雇员。
他的项目叫NewsBlur，是一个开源的Web版RSS阅读器。他展示了一些不错的工具，展示了一个阅读器上面的UI Widget是如何映射到Backbone View的。他正在把这个“遗留”项目用Backbone.js重写。

他描述了如何在不Break原来代码的情况下渐进的讲一个非Backbone项目用Backbone重构。

迁移routers。将所有和url打交道的部分用router管理起来，可以有多个router。
迁移Model。可能需要对服务器api做versioning（就是?v2返回不同的结果）。迁移代码的时候可以将model.attributes未改写的方法，这样迁移比较平滑。使用{silent: yes}初始化，手动触发model的change方法。
迁移Views。主要的改变是讲event binding改为event delegating。作者比较喜欢将View拆成粒度比较细的sub views，里面比较有趣的是提到了View collections的概念。

作者提醒这个错误很常见：

TypeError: ‘undefined’ is not an object (evaluating ‘func.bind’)

这个东西是由于想要绑定一个不存在的方法……（如_.bindAll）

另外一个得到共鸣的问题是ghost view的问题，也就是绑定了方法的view的element被删除或者被复用后，原先绑定的方法会带来不可知的影响。这个也是Backbone.js目前正在努力解决的地方，增加View的生命周期管理能力（destroy method）。

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Lumbar Support by Brad Dunbar

Links

• Slides

Notes

这个标题是个隐喻。脊椎不爽需要腰部支撑！

作者来自pathable，他们的 github

Dos and Don’ts

• Don’t reference elements by class
• Do use data attributes
• Don’t replace elements
• Do use existing dom elements
• Don’t specify tagname
• Don’t reuse views
• Do reuse do elements (safely)
• Do be careful with innerhtml
• Don’t _.bindall
• Do use envent contexts
• Do destroy views
• Do wrap router#route
• Do keep route handlers simple
• Do wrap backbone.sync
• Don’t prevent consistent events
• Do use custom options
• Don’t use mutable attributes
• Do fire custom dom events
• Do whitelist

重点是SuperModel.js

• Track Unique Models
• Maintain Model Relationships
• pathable.github.com/supermodel

很不错的扩展

他推荐了HTML semantics and front end architecture这篇文章，作者是Nicolas Gallagher

还有kinetic.js（注意有一个同名的Canvas library，不是那个。这个库也是Pathable的，不过暂时还没有开源。）

• Testable (isolated) views
• HTML interface
• Render/Cleanup Conventions

看起来像Vaporware……

作者 @braddunbar ，他说话不太清楚，不过他的库显然挺不错的。

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

New Dog, Old Tricks (Or: Dojo Already Did That) ( Or: Integrating Dojo concepts into Backbone.js ) by Rebecca Murphey

Links

• Slides

Notes

演讲者是一位女性，我记得是那两天唯一的一位，非常值得尊敬。她是bocoup的JS dev，之前做过咨询工作。

作者是Dojo的一位资深用户（2年），使用Backbone.js几个月。

由于Dojo的沉重的口碑，所以看出大家都不怎么感兴趣。不过说实话这个Talk还是不错的。

作者举了Dojo的基于Widget的例子，可以看到模板和View的绑定还是比较厉害（虽然模板引擎比较容易替换）。但是Backbone.js讨好的地方就在于它强调了Model的核心作用（Single truth，Domain Driven Design），但是Backbone.js的模板是空的，这点让作者很怀念Dojo方便的widget。

主旨就是很多人都发现Backbone.js里面View没有生命周期管理，所以很多人都觉得View的依赖清理（unbind）工作非常头大。不过这些东西在dojo里面都很好的解决了，而且dojo还有widget框架dijit，解决了布局、View依赖、View声明周期等众多问题。

Rebecca讲了它觉得Dojo有，但是Backbone没有的东西，她的SuperView帮助解决了这几个问题（提供一些rails）

• rendering: serializing, template, placing
• binding: memory-safe setup & teardown
• lifecycle: react when things happen

Dojo在很久以前就有Module机制，这个是很超前的。

这个话题本身当然是Backbone.js相关的，基于Rebecca写的一个Demo项目：https://github.com/rmurphey/srchr-demo

这个小项目写的很好，展示了如何写一个Backbone.js应用，并且借鉴Dojo的一些已有的模式。其中她主要战士的是SuperView这部分，定义了一些声明周期，使用它来解决View的依赖关系。

SuperView的代码docco注视版本

这个Slides涉及到的一些链接

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Angular.js – Testability in Mind by Vojta Jina

Links

• Slides

Notes

Vojta Jina 来自Google，所以这个框架也很有google风格。

Angular.js 是一个很有特点的框架，很不同。

提供双向数据绑定。

最有特点的是“依赖注入”，你没有听错，这个在Java社区几乎尽人皆知的东西。Angular.js使用的是编译期依赖注入来实现它的“黑魔法”。

依赖注入其实是一个不错的东西，因为双向数据绑定的时候代码需要做很多wiring的工作，进行编译期增强可以让源代码看起来可读、简单。它进行了默认的基于名字的wiring，也可以用其它方式wiring（待求证）。

目前双向数据绑定的MVWTF框架都在模板上下功夫，和ember.js类似，你可以在模板里面绑定model的属性和事件，模板本身声明了model和View的动态依赖。而且和ember.js类似，它都使用了dirty check的方法解决事件风暴带来的UI过于频繁的更新，作者说实现的思路几乎都是定时的dirty check然后更新stale的部分。

很有趣的是作者的Demo非常酷，完全的TDD，非常流畅。前面三个Talk让现场的很多人惊叹Live coding是目前好的会议的一个重要组成部分。

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

MVC Module Magic (through require.js) by Alex Sexton

副标题APP structurizer, build easifier, and middleware magician

Links

• Slides

Notes

Sexton这个姓很有趣吧？他在Slides里面提到了MVWTF这个叫法，满场大笑。这个说法就是Controller还是Router还是Whatever都没关系，大家都统一MV应该是大部分逻辑的所在就对了。

Module是很多语言内置的特性，实际上就是一个返回对象的函数。难点是如何设计一个nice和neat的api。Module可以帮助你整理/分解你的系统。因为大家认为把相关的内容放在一起可以帮助你的大脑在更小的上下文中工作，让你的大脑工作的更高效（但是上下文也可以理解为一个视图，也许有其它更好的方法解决它，如Kickstarter上面Chris Granger正在实现的Light Table。不过分开的文件起码在目前的Cmd+T支持下非常好用）。有个曾经流行过的词形容Module，那就是“关注点分离”。

由于MVWTF是关注点分离，Module系统可以说是为了代码复用和关注点分离而存在，所以两者简直就是天生的一对。

Alex举的例子是如何组织一个项目的Module结构，能否每个model或者每个view是一个单独的js文件？这样的好处是报错的时候可以直接跟踪到某个文件的某一行，而不会对package过的assets的行号搞晕。Module里面声明依赖的好处是可以按需下载，如果没有需要的时候不会去解析额外的内容。当然，你还可以给module加alias，这样就可以简单的替换掉一个库的依赖（如lodash替代underscore）。

template也是一种依赖，把他们作为dom元素夹带document里面不能cache。作为类似Module的依赖可以带来性能提升。所以有了text!的前缀（不会被eval，只作为string返回）。style也是一种依赖，它可以作为template的依赖，还有其它以文本形式存在的依赖。

Alex原话

“I prefer AMD and I specifically use RequireJS. I think it’s the best solution for modules on the web that we currently have.”

AMD嘛……Async，The web is ASYNC

AMD包会改变一个Module的声明语法，所以如果不愿意直接修改你的源文件，那么完全可以加入一个编译任务来生成AMD兼容的文件。当然，这只是可以……后面有更好的方法

当然，社区里面关于AMD有很多的FUD（绝对比分号之争要鲜明，很多人明确表示AMD的语法太二而不愿意改变），Alex尽力解释了其实它的语法挺简洁的（比Node.js的require）。

然后Alex介绍了重头的Use.js，它是一个帮助使用AMD的语法引用不兼容AMD的Module的工具。这样就不需要强制人家把自己的库修改为AMD兼容的方式（对于非AMD环境不可用），或者fork一个AMD版本的库一直跟着原来库的发布（这是非常非常二的做法，后患无穷！）。其实这个工具就是动态的注入了AMD需要的前面和后面的那一丁点wrapper js code。

Plugins是在return object之前动态修改的一个机制。

Plugins是一种很好的思路：可以动态修改不支持AMD的代码，可以动态增加依赖（如template依赖于handlebar，自动插入这个依赖），自动预先编译template（这个需要 build process帮助），注入检查点或者编译期优化什么的，可以自动分析template依赖的css，可以自动inline css和images，可以动态删除用不到的代码（根据某些runtime变量的状态决定，has.js）。最终的目的甚至包括直接把整个应用的依赖变成一个单一请求发出去（当然服务器也要支持对这个请求做响应）。

透明的预编译操作包括：

• templates
• i18n
• i18n in templates
• configurable apps
• multi-profile apps
• coffeescript
• less.js or sass or jade or what ever

这些预编译和运行时优化帮助提升编码者的体验，在预编译阶段可以为浏览器和其它环境做动态适配。

作者总结用Require.js的主要好处（这里其实主要指的是plugins机制）：Happiness, Speed, Modularity, Magic

作者后来被问到Require.js会增加http请求对于mobile web怎么办的问题。Alex说在最终部署的时候是要有真正的预编译阶段的。这和Rails的asset pipeline是类似的，在开发的时候方便看到到底是哪个文件的哪一行有问题，但是部署的时候可以通过预编译减少请求。

另外一个问题是Module切分的粒度的问题。Module如果划分的比较细的时候依赖的声明会非常长，比较靠谱的解决方法是通过plugins进行动态注入依赖。但是多个相关的文件被分在不同的Module并主动声明依赖的时候需要平衡这个粒度问题，这是个个人问题，不过由于粒度不容易掌握暂时还是一个没有定论的问题。现场很多大牛表示自己的项目切分的粒度比较粗，这样不需要在不同的文件中跳来跳去，而且强依赖的逻辑块放在一个文件暂时还是天经地义的。

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

How to Argue about Javascript by Andrew Dupont

Links

• Slides

Notes

Andrew说话比较慢（尤其是没有预先准备的时候），但是他的语言很睿智。他的话题也很睿智，讲的不是具体的框架或者技术，而是软技巧“如何争论？”。他讨论了如何好好的辩论，而如何辩论是不好的。

核心的事件就是社区内火热的Semicolon问题~

How not to argue about semicolons?

• Our arguments should be purposeful

要有目的，就是说为了解决实际的问题。比如科学研究符合这点，不过很多政治争论不符合这点（政见之争是狗屁？）。他引用了Carl Sagan说的一段话，大意是科学家比较可能会放弃自己的立场并被说服，但是政治和宗教之争很难看到放下武器站到对方一边的场景。

这些是常见的一些场景：

• “Whoe the hell are you?” – 你微不足道
• “Whre do you get off censoring me, you fascist?” – 你凭什么管我，你个法西斯

• Motives for having a code argument：那么我们为什么在代码问题上争论呢？

其实不应该是为了显摆你自己，也不应该为了说服别人认同你的想法。

争论的目的应该是更好的了解你们争论的主题

有一本很有名的书叫”Getting to yess”，副标题是Negotiating agreement without giving in。

An argument has 3 goals:

• It should produce a wise agreement, if possible 应该达成聪明的一致
• It should be efficient 有效率
• It should not damage the relationship between parties 不破坏各方的关系

Tactics for arguments: 争论的战术

• Separate the people from the problem 就事不对人，必须区分问题的目的（本质）和你对这件事的情感因素
• Focus on interests, not positions 注重共同的利益，而不是自己的立场（位置）
• Invent options for mutual gain 创造一些方案来达到共同受益
• Insist on objective criteria 只坚持客观的条件（如标准、benchmarks）

这个例子很逗，分号之争来自github上面的一个bug。有人报了bug，然后 @fat 说这不是他代码的bug，而是 JSMIN 的bug。然后 douglas crockford大神 蹦出来说这不是 JSMIN 的bug，而是 @fat 对js分隔符理解有问题（其实不完全是），然后 @fat 就反驳说我就这样写你怎么地吧？

zzzzing! 这梁子就算是结上了！

另外一个例子是Selector引擎战争，这源自moo.tools作者写的一个benchmark，职责JQuery的selector引擎比较弱，因为它的选择器在这个benchmark的很多场景下都是比较慢的。

然后John Resig就写了一篇犀利的博客 “Selectors that people actually use“，职责这个benchmark里面的很多场景并非人类常用……

那我们应该怎样办呢？我们应该以愿意被说服的态度去讨论，思考对方为什么持不同的简介，考虑品味的不同，考虑情绪的问题。

他举了John的另外一个例子，他如何回答 “JQuery steals code” 和 “JQuery hates developers, love companies” 这两个问题。他的博客犀利、幽默，是解决这种问题的一个典范。他没有直接争论，而是用有趣的方式去化解自己的被动。

后面回到例子的主线，就是Bootstrap是否应该为了 JSMIN 去增加一个分号呢？库的作者是否应该为了 JSMIN 兼容性去做一些让步呢？还是 JSMIN 应该主动改变（Crockford 觉得那样做很没品）。

有趣的句子：

“People who don’t use semicolons are Javascript hipsters.”

“No, people who are fanatical about semicolons are just spreading FUD.”

“@fat is being a jackass and a bad project steward.”

“No, people like you are bitching about a library they got for free.”

“Semicolon or not, that line should still be rewritten.”

“JSMin sucks anyway. People should use some other minifier.”

“Who cares about minification? Everyone’s got a fast connection now.”

争论愈演愈烈，慢慢变成各种人身攻击和开玩笑，很多人抱怨这个ticket不停的给他发邮件……

最搞笑的是 @fat 本人在中间留言，新版的Bootstrap已经修正了这个问题了……后面还是继续 shit storm

但是后面还是各种人身攻击……

作者用了一个特别贴切的形容词”Shit-storm”！

这说明跑题了，如何不跑题呢？

要温和一些（和谐），be nice！ 说话要精确，不要扫射……

作者举了一些委婉的表达的例子……很委婉。

javascript社区还有很多例子

• Ember vs. Backbone
• Mico-frameworks
• Coffeescript!
• Douglas Crockford vs. the world 这个是开玩笑的

总的来说，社区里面争论真的是一个非常重要的事情，避免Shit-storm的发生对社区有益。

知乎里面就有这个争论的延伸，虽然这里没有脏字，但是大部分人也一样是被卷入这个争论……

我的回答：

加与不加是风格问题，风格争议不需要有个定论。关键的问题在于如何“争论”，处理好冲突，学会组织语言减少争议是最重要的。因为分号问题在社区内部造成了很多况日持久的口水战，这些口水战是社区的损失……因为大家在这个时候可以写更多的代码带来更多的功能。

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Ember.js by Yehuda Katz

Links

• Slides

Notes

Ember.js的主力开发者和鼓吹者是Yehuda Katz，这个框架来自于他们团队所咨询的项目。所以这也是由实际需求催生的一个项目。

Ember.js expectations

• bidirectional data binding, it’s special
• View hierarchy
• Structure and Widgets
• Routing

Ember’s Bindings are backed into the object model.

bindings are always async. It guarantees you the ability to make all necessary changes before side-effects occur.

它很智能的解决了单个属性changes造成的event雪崩。若干Model set只会集中触发一次UI update。Guarantees a single DOM update per turn in the browser’s event loop.

它的Template组合方式保证子template的渲染只有一次Dom update。

它的View hierarchy也就是CompositeView处理了子View的状态清理（双向unbind，释放资源），并且提供了一些Lifecycle events（很有价值）。

Template的渲染过程隐含了Collection和Model的事件绑定，Template里面的action可以在Router触发事件并且可以生成对应的url。

Ember.js的特点就是用黑魔法（black magic，注：这是我说的，是我的偏见 ;-D）帮你默认做了很多事情，作者管这个叫“Does the right thing by default”，这是一个双刃剑。但是对于有很多雷同的页面和功能的项目来说它可以保证write less do more，并且平均的代码质量会提高（因为复杂逻辑完全被框架所封装好了）。

Backbone.js的一个重要买点是View的Stateless，而ember.js则通过Routing主动的负担起了State Management的责任。Router里面定义了系统的各种State，用户点击action或者通过URL跳转实际上是改变了状态机的状态，router定义了这些状态和状态转换。因为UI状态机实际上是一个非常复杂的建模方式，因为状态的转换组合可以让系统处于很多复杂和混乱的情境中，当然ember.js这样做也是有理由的，它的好处包括logging、对生产应用进行debugging，避免不可能的情况（通过定义所有可能的情况！）。

对于状态机这个表述，Yehuda在现场被很多“大牛”质疑了，获得了不少的嘘声。不过这的确是解决非常复杂的问题的一种标准的解决方法，但是由于这种分析方式本身（定义状态，把不同的状态正交的解开）有很大的难度，所以它有可能会让你陷身泥潭。这就是很多注重简单的MVWTF框架会选择不去管理状态，而选择Stateless的原因。

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Keynote for BackboneConf by Jeremy Ashkenas

Links

• slides
• Video
• some notes

Notes

• Backbone.js成长的非常快，只用了1.5年就在社区内引起了巨大的反响
• Backbone是来自真实的项目，满足真实的需求，这个框架只是一个副产品
• Backbone.js是抽出DocumentCloud项目可复用的部分的产物
• Backbone.js的用户很大牌

Backbone.js是一个small、simple、flexible的框架，所以没有典型的Backbone应用，我们现在看到的例子只是冰山的一角。

传统的JQuery的一个大的问题就是它面对的是获取文本，更新HTML上的另外一些文本。但是这个过程中我们没有明确的获取和渲染数据模型。

Avoid jQuery hell by getting your state of out of the DOM

因为JQuery更新的Dom本身就是有状态的，所以代码尝尝混杂者状态判断的逻辑，这是很让人头疼的状态。

Model is where your data lives, source of truth for application. UI only knows about the truth in the models. UI can’t conflict with others

数据模型应该表示状态，让UI与状态分离，这样UI之间就不会因为复杂的状态而纠缠不清。

在Backbone.js里面，我们修改Model的状态。而其它的组件监听Model的事件。

ClientSide的collection一般是整体Model的repository的一个子集。Model是个体，而collection是集合。他们是保持客户端状态的基础。Underscore.js用来访问Model和Collection，它是Backbone.js的魅力的体现。

Ashkenas演示了他们使用namespace，把系统中所有的Model和View实例全部都放在一个树型数据结构上，可以看到View的实例一般是绑定在相应的Collection和Model下面。这个树形数据结构保存了客户端的所有状态和实例，对于debug非常有利。View放在Collection和Model下面是因为View是无状态的（它依附于相应的Collection和Model的状态）。

Changes

一般的模式是Model被set后View就re-render，View会监听change事件。Model和Collection的save的语义是将变化传递到服务器（持久化），而set只是修改状态并触发change。

Model和Collection初始化的时候可能需要逐层载入，这个时候可能会触发多次change，可以使用参数{silent: true}。它是专门应对触发change的中间状态而设计的，当需要触发View的re-render时再trigger change事件。这样的设计可以保证View是完全无状态的。

有人问客户端Model会有一些对服务器端没有意义的属性，如selected表示一个模型是否是被选中的状态，这可以么？
因为Model是用来保存系统状态的，所以这些状态属性就应该放在Model里面。

View的更新是应该使用乐观模式还是悲观模式呢？（是否等待状态保存到服务器后再更新UI）。
这个要看场景，Instagram就做了很多这样的trick。避免状态不一致是最重要的，所以对于不太可靠的更新需要使用悲观方式。

Model之间的关系如何传递？Model的属性是否可以是collection。
可以，通过Model和它的属性间的event proxy传递event。（第二天的SuperModel，还有其它解决方案，可以用声明的方式绑定Model和sub models之间的关系，自动proxy event）

change event的listener可以通过this.get(‘prop’)和this.previous(‘prop’)来获取修改的属性的变化情况。

Views

Views should be stateless!!!

• View is stateless if it always has a dom element at all times
• Did my view render in a particular mode when it doesn’t exist? No, elem is always there and events are always delegated

View在它被初始化的时候它的element就应该已经存在，这样它的render和re-render就不会依赖于其它先置条件，从而保持stateless。

Backbone.js的哲学Philosophy

Take the truth out of the DOM.

• So the only truth is the model

Intentionally minimal

• Small, Simple, Flexible

Resited Router for a while. Jeremy still thinks Router may be overreaching

Tries to be driven by use cases, not gospel. If you open ticket on GitHub without use cases, you’ll get ignored

Is Backbone.js MVC, MV+, MVP?

• It’s MVWhatever
• Important thing is that UI and Models are the common denominator. Build interesting UI without breaking app and build interesting business logic without breaking UI.
• 最重要的分离是Model和View的分离，Model是保持状态的核心，View是无状态的

Statelessness

• Backbone doesn’t do it for you
• Exponential states of UI should be avoided. Don’t enumerate every state
  • UI因为是一种组合视图，所以它的状态是指数式增长的，所以要避免枚举UI的状态组合，保证UI是无状态的
• Models contain state, UI listens to models, but UI doesn’t care about what is going on with rest of app

Other things discussed in this session

• 在客户端和服务器端共享代码？Jeremy觉得这好像不是个好主意，但是在服务器和客户端建立一种Event传递机制似乎是一个可以考虑的方向。
• 大家公认View的unload是一个痛点：大家发现View的初始化往往比较容易，但是View在不活跃或者需要被替换掉的时候如何unbind事件，如何处理已经渲染过的Dom，解除所有其它的双向依赖是个问题。因为View和子View的生命周期和他们的依赖关系目前还没有被建模，所以没有统一的解决方法。Jeremy透露目前他们的解决方法是通过namespace下面的遍历来unbind所有的sub-view，这种方法在不是非常复杂的情况下是可行的。不过由于这个公认痛点的存在，社区内大家都在尝试找到一种比较通用的简单解决方法。

在啤酒爱好者普遍认可的Ratebeer的综合排名里面，目前第一的是Westvleteren 12。它代表了Trappist修道院啤酒的最高水准，它的风格叫做Abt/Quadrupel，常见的Trappist风格是Blone/Brown (Dubble)/Trippel，Quadrupel应该翻译做四料啤酒吧，是超越Trippel的有更加丰富的酚和酯的极品啤酒。Trappist 目前比利时有6家，是Chimay、Rochefort、Achel、Westvleteren、Orval、Westmalle，还有一家在荷兰叫Koningshoeven。不过Trappist并非都是口味丰富的，比如Chimay、Achel、Westmalle都相对温和。Quadrupel则是味道层次最丰富，味道强烈的极品，据我所知只有Rochefort 10和Westvletern 12属于Trappist授权修道院生产的Quadrupel。修士在为上帝服务至于投入了毕生精力不断的优化提升啤酒酿造艺术，才有了这样的极品，所以……我就不多说了。

但是很不幸的是Westvleteren 12很难买到。能买到的Quadrupel是Rochefort 10，目前它也是我的最爱。这里和 @大Joy 不谋而合。

美国的同事比较一致的认为Russian River Pliny the elder是最好的美国啤酒，这个也供参考。因为北京是绝对买不到的。

但是我同意口味不应该排名，所以……我应该闭嘴。

我在slideshare分享过一个比利时啤酒的slides，里面有很多不准确的信息，不过还是可以参考。

你的孩子并不是你的。

他们是“生命”对它自身的渴慕所生的子女。

他们经你而生，却不是你所造生。

虽然他们与你同在，却不属于你。

你可以给他们你的爱，却非你的思想。

因为他们的灵魂居住的明日之屋，甚至在你的梦中亦无法探访。