最近饶有兴致的又把最新版 Vue.js 的源码学习了一下，觉得真心不错，个人觉得 Vue.js 的代码非常之优雅而且精辟，作者本身可能无 (bu) 意 (xie) 提及这些。那么，就让我来吧：）
程序结构梳理
Vue.js 是一个非常典型的 MVVM 的程序结构，整个程序从最上层大概分为
- 全局设计：包括全局接口、默认选项等
- vm 实例设计：包括接口设计 (vm 原型)、实例初始化过程设计 (vm 构造函数)
这里面大部分内容可以直接跟 Vue.js 的官方 API 参考文档对应起来，但文档里面没有且值得一提的是构造函数的设计，下面是我摘出的构造函数最核心的工作内容。
整个实例初始化的过程中，重中之重就是把数据 (Model) 和视图 (View) 建立起关联关系。Vue.js 和诸多 MVVM 的思路是类似的，主要做了三件事：
- 通过 observer 对 data 进行了监听，并且提供订阅某个数据项的变化的能力
- 把 template 解析成一段 document fragment，然后解析其中的 directive，得到每一个 directive 所依赖的数据项及其更新方法。比如
v-text="message" 被解析之后 (这里仅作示意，实际程序逻辑会更严谨而复杂)：
- 所依赖的数据项
this.$data.message，以及
- 相应的视图更新方法
node.textContent = this.$data.message
- 通过 watcher 把上述两部分结合起来，即把 directive 中的数据依赖订阅在对应数据的 observer 上，这样当数据变化的时候，就会触发 observer，进而触发相关依赖对应的视图更新方法，最后达到模板原本的关联效果。
所以整个 vm 的核心，就是如何实现 observer, directive (parser), watcher 这三样东西
阅读剩余部分...
这篇文章将会记录我自己最近一周时间里，从产生“团队时间线”这个想法，到产品设计、交互设计、开发、迭代、再到 1.0 发布的整个过程。整件事情跨越了多个分工职能，所以这件事情虽然并不大，但对我来说是一种不一样的做事方式和经历，所以觉得应该记录下来。
“团队时间线”是个可视化展示团队所有同学时间分配/管理的平台。每个人都可以在“我的时间管理”页面极简的记录自己的时间，比如从某天到另外一天做了一个项目、或者昨天开了一个重要的会等等。
阅读剩余部分...
最近在内部项目中做了一些基于 vue + webpack 的尝试，在小范围和同事们探讨之后，还是蛮多同学认可和喜欢的，所以通过 blog 分享给更多人。
首先，我会先简单介绍一下 vue 和 webpack：
(当然如果你已经比较熟悉它们的话前两个部分可以直接跳过)
介绍 vue
Vue.js 是一款极简的 mvvm 框架，如果让我用一个词来形容它，就是 “轻·巧” 。如果用一句话来描述它，它能够集众多优秀逐流的前端框架之大成，但同时保持简单易用。废话不多说，来看几个例子：
<script src="vue.js"></script>
<div id="demo">
{{message}}
<input v-model="message">
</div>
<script>
var vm = new Vue({
el: '#demo',
data: {
message: 'Hello Vue.js!'
}
})
</script>
首先，代码分两部分，一部分是 html，同时也是视图模板，里面包含一个值为 message 的文本何一个相同值的输入框；另一部分是 script，它创建了一个 vm 对象，其中绑定的 dom 结点是 #demo，绑定的数据是 {message: 'Hello Vue.js'}，最终页面的显示效果就是一段 Hello Vue.js 文本加一个含相同文字的输入框，更关键的是，由于数据是双向绑定的，所以我们修改文本框内文本的同时，第一段文本和被绑定的数据的 message 字段的值都会同步更新——而这底层的复杂逻辑，Vue.js 已经全部帮你做好了。
阅读剩余部分...
晒一下自己用 Koa next generation web framework for node.js 写的一个 web 服务
这个 web 服务主要是做内容的列表展示和搜索的 (可能说得比较抽象，但确实是 web 服务最常需要做的事情) 主要的文件一共就2个：
app.js 主程序lib/model.js 数据层
其中 model.js 是和具体业务逻辑相关的，就不多介绍了，这也不是 Koa 的核心；而 app.js 的代码可以体现 Koa 的很多优点，也使得代码可以写得非常简练而去清晰——这是我自己都完全没有想到的事情
阅读剩余部分...
话说上周末看到一个吐槽腾讯“内部开源”的微博，后来我想了想，自己那么骚包的在项目还没做完之前，就在 CSSConf 上说我们将来要开源一个名叫 Zorro 的库。结果好几个月过去了还是没有准备好，也就不敢再笑话别人了……
我觉得把东西开源出来之前，有几件事要准备好，不然除了自己刷存在感之外，真的没意义。比如：
- 是否有了 (或阐述清楚了) 明确的目标和方向，不然找不到合适的合作者和贡献者
- 是否有了 (或阐述清楚了) 明确的设计哲学和开发原则，不然大家无法形成合力，项目很容易陷入混乱
- 是否有了最小的可工作版本，不然雪球滚不起来
- 是否有了充分的文档、demo和测试用例，让大家更直观的了解项目，利用项目，也对项目的质量更有信心
印象中我见到的优秀的开源项目，基本都在被大家广泛认识之前，都已经把这些事情打理好了——这也是我一直推崇的。
好吧很惭愧，这几点我还都没有做到……
不过在这之前，我愿意在此分享一些自己开发中的心得，跟大家一起探讨相关的话题。
—- 以上是一些比较啰嗦的铺陈 —-
组件分解的方式及其衍变
在开发大型应用的时候，难免要用到一些组件化的分解方式。比如：把一个相册浏览界面分解成：“相册列表”和“大图预览”两个区域，“相册列表”又由一个个“相册缩略图”组成，每个“相册缩略图”包含了一个“小图片”以及“预览按钮”、“删除按钮”、“排序按钮”等操作按钮……
而如何管理和划分组件逐渐变成了前端工程里的一门学问。
阅读剩余部分...
去年年底的时候刚换了工作，刚到杭州，一到杭州就赶上996，匆匆忙忙，年底就稀里糊涂过去了
紧接着就是忙碌的一整年，忙工作，忙生活，各种忙
今天晚上，改完了自己名下的最后一个bug，也算是给2014简单收个尾吧，也突然觉得自己有一点时间回顾一下了
先从13年说起吧，最大的变化就是我换工作了，也搬家了，从北京搬到了杭州，从此过上了南方人的生活：
- 夏天更热，冬天屋里更冷，这一点嘛，已经差不多习惯了。无非是多开空调呗……
- 空气更好，雨水更多
- 交通更好，上班路上很畅通，而且有班车坐很方便
- 也赶在限牌之前买到了自己心仪已久的那款车
- 有了车以后，生活确实方便了许多，晚上或者周末出门有了更多选择，近郊出游也很方便，还去了一趟上海、去了一趟宁波、去了一趟横店 (说道横店，我超喜欢秦宫，气势恢宏，有刀枪剑戟的感觉)
- 杭州本来也是个旅游城市，西湖、龙井、西溪湿地，也给平日的生活增添了很多乐趣
- 饮食方面，这边吃海鲜/日料的机会比在北京的时候多多了，相对的火锅和面食少了
- 运动比以前少了，以前在北京常踢球的，来杭州之后几乎没怎么踢，可能是因为自己没找对组织，现在逐渐开始多游泳了
经过了1年多的时间，我想说，我很喜欢杭州这个地方。
然后说说工作吧。
这一年多时间我其实没做太多事情，更多的还是在熟悉环境，熟悉人、熟悉业务、熟悉流程、熟悉沟通方式、熟悉做事风格。阿里确实是个巨大的集团，有超过十年的历史和沉淀。我希望可以帮助团队做得更好，但首当其冲的事情是要先弄清楚游戏规则，努力找到问题的症结，谨慎的提出可实施方案，然后循序渐进的往前走。可以说每一步都要走得小心谨慎，稍有疏漏，可能就前功尽弃了，这一点在阿里可能体现的尤为明显。我想这也正是我之前的工作经验可以体现出价值的地方。
从工程和管理的角度，我今年主要是以培训或布道的方式为大家分享一些系统而又务实的最佳实践，包括如何高效开会、合作、项目管理、代码管理、时间管理，也包括组织团队讨论编码规范、项目目录结构、文档格式、工具链使用等。希望可以全面的提升团队的工作效率和效果。这些工作会继续延续到2015年。
团队的技术视野也是一个亟待提高的地方，这同时也和团队每一位同学的职业发展有着密切的联系，这也是在新的一年我希望可以做好的一件事。
技术上，今年我主要的精力聚焦在了2件事情上：前半年花了一些时间在触摸屏幕操作上，研究了几个手势库，也尝试自己写，不过没有太像样的成果，算是个失败的过程吧，我今天回顾这件事情，主要是没有抓到重点，上来就研究多点复杂操作，也许这些东西在未来可能会显得更有价值，还是决定放一放，什么时候有了更成熟的思路，再考虑拿起来；后半年花了更多时间在 web components 上，还有 polymer 框架，我觉得这是我们看得见的未来，非常值得投入进去看一看，我和几个同事一起做了些实践，也有很多心得。
在全年技术探索和实践的过程中，我有一个深刻的感悟，是和“造轮子”这件事有关系的，在今天这个技术世界里，与其说“不要重复造轮子”，不如说“造轮子”的和“用轮子”的已经是两种性质的工作了。我们今天很多人选择的工作，首要任务是造汽车而不是造轮子。我觉得这是很多讨论“到底要不要造轮子”的问题的根源。造汽车和造轮子有各自的技术含量，有各自需要认真思考的问题，如果没有认清这个问题，明明是造汽车的，结果觉得造轮子更牛掰而去造轮子，必定没有好结果，或者事倍功半；如果真想造轮子，应该好好找个造轮子的地方，才会造出最好的轮子，不然也只会做个半调子。篇幅有限，这事儿暂不细说了……
技术方面还有一件事，就是开始组织 W3C 中文兴趣组的技术讨论，我们这一年组织了几次《ig在线talk》，也发起了一些标准翻译，也讨论了一些诸如首屏渲染的提案，还有中文字体和排版的制定，有的时候电话会议的时间已经超了，但是大家还会津津有味的在技术的领域里讨论闲聊，这种感觉是很少有的，相信经历过这些讨论的同学们也感受得到。
另外自己在2014年初暗自下决心要看10本以上的书——这对于我这种平时没有看书习惯的人来说其实并不容易——这个目标算是已经达成了。这里面《习惯的力量》、《合作的进化》、《反脆弱》、《rework》、《remote》都是令我印象深刻的书，看过之后有非常多的收获。
2015年，我有这么几个简单的想法：
- 第一，要有健康的身体。这似乎是我从来没有过的对健康如此重视，也是因为现在工作和生活能够协调的更好的一个结果吧。不要连续熬夜或者休息不够，更重要的是保持运动，控制饮食，眼睛、颈椎、牙齿和肝这4个上班族体检最多出现的问题都要特别注意起来。
- 第二，多花时间陪家人、老同学、周围的朋友，多参与一些社交活动
- 第三，要把自己的编码量降下来，把团队打理好。我也深刻的感觉到，自己应该花更多的时间关怀身边的每一位同事，业务上的、技术上的、心态上的，都有很多值得去做的事情。让团队每一个人更好，比自己一个人更好重要的多。
- 第四，把有限的个人精力集中投入在1件或几件事上
- 第五，看15本书
到明年这个时候，我会把这篇blog翻出来看看完成的怎么样：）
2 年前曾经也发过几张自己拍的照片，似乎大家对于我的拍照技术还是蛮宽容的。下面几张同样是我认真挑选过的这 2 年来拍的，同样求轻拍 ^_^
p.s. 这 2 年真的经历了不少事情
港版风景
阅读剩余部分...
之前参加过 2 次，今年的 D2 是我第一次以“自己人”的身份参加的。和往年一样，受益匪浅，但也有了一些不一样的想法。
阅读剩余部分...
译自：Naming CSS Stuff Is Really Hard
找到的这篇文章算是对我之前写的 《标签？ID？还是CLASS？》 的再深入。我当时写那篇文章的时候，就有朋友提出了“非语义化”的 class 命名的问题，我当时确实觉得很纠结，简单的想法是“框架性质的表象 class 我没异议……框架的实质是通过降低灵活性达成更广泛的共识，我们个人不要再创造这样的样式就好了”，但没有想到特别好的“套路”，更多的是在实际情况中再分辨。看过这篇文章，我似乎找到了更好的答案。同时顺着文中提到的 Nicolas 那篇文章看下去，也对 OOCSS、BEM 之类的提法有了更多的认同感。特译给大家参考。
阅读剩余部分...
译自：A successful Git branching model » nvie.com
本文将展示我一年前在自己的项目中成功运用的开发模型。我一直打算把这些东西写出来，但总是没有抽出时间，现在终于写好了。这里介绍的不是任何项目的细节，而是有关分支的策略以及对发布的管理。
在我的演示中，所有的操作都是通过 git 完成的。
阅读剩余部分...
«1234567»