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,见到了coffeescriptunderscore.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 AshkanasYehuda KatzVojta JinaEric FerraiuoloAndrew 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” 这是 JeremyVojta 的答案。

大家可以看 @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,见到了coffeescriptunderscore.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,见到了coffeescriptunderscore.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,见到了coffeescriptunderscore.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,见到了coffeescriptunderscore.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,见到了coffeescriptunderscore.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)。

#BackboneConf2012 Lumbar Support by Brad Dunbar

Backbone Conf 2012

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

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

Lumbar Support by Brad Dunbar

The rest between talks

Links

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 ,他说话不太清楚,不过他的库显然挺不错的。

#BackboneConf2012 New Dog, Old Tricks by Rebecca Murphey

Backbone Conf 2012

有幸去美国波士顿参加了2012年的 Backbone.js Conference,见到了coffeescriptunderscore.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

Rebecca Murphy

Links

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涉及到的一些链接