Category: Tech.技术

The technologies related part of my blog posts. If you are a programmer or geek, I think you will only interested in this part of my blog.

Output ISO 8601 format datetime string in UTC timezone

I hate timezone. Especially for python, since python’s timezone is not in standard library, I always need to install pytz. I know it make sense, since timezone db changes sometimes, and it make no sense to put it in python standard library. But this make life harder. Every time when I work on timezone aware datetime, it will #FML.

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.

Web语义化真的是Web开发人员表现出来的可贵的人性！

在 知乎上面扯得比较长 ，所以也发到自己博客一份。

语义网是让机器可以理解数据。语义网技术，它包括一套描述语言和推理逻辑。它包通过一些格式对本体（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开发人员表现出来的可贵的人性！

相关词条链接：

Optimize Sparrow.app’s sparrowdb data file size

Intrepid Blog has a blog post about how to optimize Mac’s popular mail app sparrow.app’s sparrowdb data file size.

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.

Why I move to SublimeText 2?

Writing a blog post is hard, because you need to prevent the gravity of laziness. This time I want to talk about why I move to SublimeText 2?

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.

Screen Shot 2012 08 01 at 2 42 18 PM

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.

#BackboneConf2012 参加了Backbone.js Conference 2012

Backbone Conf 2012

Screen Shot 2012 07 24 at 6 04 40 PM

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

Tin 和 Jeremy Ashkanas 大神合影

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

The conference room

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

第一日的话题

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

第一日话题后的酒会

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

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

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

Outlook

第二日的话题

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

第二日话题后的论坛

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

The Future of Javascript Panel

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

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

The Panel host

我记得的一些点是：

  • 所有人都同意框架不是作者凭空想出来的，都是他们把实际交付的项目的代码中可以复用的部分抽出的结果。也就是说成功的框架都不是为了写一个框架而写出来的，而是为了解决某一种实际问题的解决方案。所以停止根据某个灵感而发明一种框架这种想法了。
  • 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

杏子艾尔

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

Backbone Conf 2012

有幸去美国波士顿参加了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

Brandon Keepers

Links

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 笑着说：“看我回去教这帮坏小子如何写测试去……”

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

Backbone Conf 2012

有幸去美国波士顿参加了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

Eric Ferraiuolo

Links

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 来处理初始状态的导航和组装。

#BackboneConf2012 Airbnb’s Journey Into Mobile Web by Harrison Shoff

Backbone Conf 2012

有幸去美国波士顿参加了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

Harrison Shoff

Links

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流程对于交付一个好的产品是多么重要。

#BackboneConf2012 Real-World Realtime with Backbone by Henrik Joreteg

Backbone Conf 2012

有幸去美国波士顿参加了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

Henrik Joreteg

Links

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生命周期的那个问题

#BackboneConf2012 Migrating a Large Project to Backbone.js by Sam Clay

Backbone Conf 2012

有幸去美国波士顿参加了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

Sam Clay

Links

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）。