囧克斯

这里是勾三股四的家

  • Vue + webpack 项目实践

    最近在内部项目中做了一些基于 vue + webpack 的尝试,在小范围和同事们探讨之后,还是蛮多同学认可和喜欢的,所以通过 blog 分享给更多人。

    首先,我会先简单介绍一下 vue 和 webpack:

    (当然如果你已经比较熟悉它们的话前两个部分可以直接跳过)

    介绍 vue

    _2015_06_25_12_37_36

    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 已经全部帮你做好了。

    _2015_06_24_11_00_20

  • 用 Koa 写服务体验

    Koa

    晒一下自己用 Koa next generation web framework for node.js 写的一个 web 服务

    这个 web 服务主要是做内容的列表展示和搜索的 (可能说得比较抽象,但确实是 web 服务最常需要做的事情) 主要的文件一共就2个:

    • app.js 主程序
    • lib/model.js 数据层

    其中 model.js 是和具体业务逻辑相关的,就不多介绍了,这也不是 Koa 的核心;而 app.js 的代码可以体现 Koa 的很多优点,也使得代码可以写得非常简练而去清晰——这是我自己都完全没有想到的事情

  • webcomponents 笔记 之 配置管理

    话说上周末看到一个吐槽腾讯“内部开源”的微博,后来我想了想,自己那么骚包的在项目还没做完之前,就在 CSSConf 上说我们将来要开源一个名叫 Zorro 的库。结果好几个月过去了还是没有准备好,也就不敢再笑话别人了……

    我觉得把东西开源出来之前,有几件事要准备好,不然除了自己刷存在感之外,真的没意义。比如:

    1. 是否有了 (或阐述清楚了) 明确的目标和方向,不然找不到合适的合作者和贡献者
    2. 是否有了 (或阐述清楚了) 明确的设计哲学和开发原则,不然大家无法形成合力,项目很容易陷入混乱
    3. 是否有了最小的可工作版本,不然雪球滚不起来
    4. 是否有了充分的文档、demo和测试用例,让大家更直观的了解项目,利用项目,也对项目的质量更有信心

    印象中我见到的优秀的开源项目,基本都在被大家广泛认识之前,都已经把这些事情打理好了——这也是我一直推崇的。
    好吧很惭愧,这几点我还都没有做到……

    不过在这之前,我愿意在此分享一些自己开发中的心得,跟大家一起探讨相关的话题。

    -- 以上是一些比较啰嗦的铺陈 --

    组件分解的方式及其衍变

    在开发大型应用的时候,难免要用到一些组件化的分解方式。比如:把一个相册浏览界面分解成:“相册列表”和“大图预览”两个区域,“相册列表”又由一个个“相册缩略图”组成,每个“相册缩略图”包含了一个“小图片”以及“预览按钮”、“删除按钮”、“排序按钮”等操作按钮……

    而如何管理和划分组件逐渐变成了前端工程里的一门学问。

  • [译]CSS命名神马的真心难

    译自:Naming CSS Stuff Is Really Hard

    找到的这篇文章算是对我之前写的 《标签?ID?还是CLASS?》 的再深入。我当时写那篇文章的时候,就有朋友提出了“非语义化”的 class 命名的问题,我当时确实觉得很纠结,简单的想法是“框架性质的表象 class 我没异议……框架的实质是通过降低灵活性达成更广泛的共识,我们个人不要再创造这样的样式就好了”,但没有想到特别好的“套路”,更多的是在实际情况中再分辨。看过这篇文章,我似乎找到了更好的答案。同时顺着文中提到的 Nicolas 那篇文章看下去,也对 OOCSS、BEM 之类的提法有了更多的认同感。特译给大家参考。

  • [译]撰写可测试的 JavaScript

    译自:Writing Testable JavaScript - A List Apart

    这篇文章算是 A List Apart 系列文章中,包括滑动门在内,令我印象最深刻的文章之一。最近有时间翻译了一下,分享给更多人,希望对大家有所帮助!


    我们已经面对到了这一窘境:一开始我们写的 JavaScript 只有区区几行代码,但是它的代码量一直在增长,我们不断的加参数、加条件。最后,粗 bug 了…… 我们才不得不收拾这个烂摊子。

    如上所述,今天的客户端代码确实承载了更多的责任,浏览器里的整个应用都越变越复杂。我们发现两个明显的趋势:1、我们没法通过单纯的鼠标定位和点击来检验代码是否正常工作,自动化的测试才会真正让我们放心;2、我们也许应该在撰写代码的时候就考虑到,让它变得可测试。

    神马?我们需要改变自己的编码方式?是的。因为即使我们意识到自动化测试的好,大部分人可能只是写写集成测试(integration tests)罢了。集成测试的侧重点是让整个系统的每一部分和谐共存,但是这并没有告诉我们每个独立的功能单元运转起来是否都和我们预期的一样。

    这就是为什么我们要引入单元测试。我们已经准备好经历一段痛苦的撰写单元测试的过程了,但最终我们能够撰写可测试的 JavaScript

  • [译]语义化版本管理

    译自:语义化版本管理 2.0.0

    摘要

    对于一个给定的版本号 MAJOR.MINOR.PATCH (主、次、补丁),其变化的规律是:

    1. MAJOR version (主版本) 会在 API 发生不可向下兼容的改变时增大。
    2. MINOR version (次版本) 会在有向下兼容的新功能加入时增大。
    3. PATCH version (补丁版本) 会在bug以向下兼容的方式被修复时增大。

    我们还可以根据预发布、构建元数据 (build metadata) 的实际需求,在 MAJOR.MINOR.PATCH 格式之上扩展出额外的标记。

    介绍

    在软件管理领域,存在一个叫做“dependency hell (依赖地狱)”的坑。随着系统越变越大,你集成了越多的软件包,也越发觉得,有一天,你会陷入绝望。

    对于有很多依赖关系的系统来说,发布新版本的软件包会迅速变成一场噩梦。如果依赖性规定得太紧,你会陷入 version lock (版本锁,即每次软件包的升级无法产生新的版本)。如果依赖性规定得太松,你会不可避免的面对 version promiscuity (版本泛滥,假设未来版本是需要考虑兼容性的)。当 version lock 和 version promiscuity 让你的项目无法安全而又轻松的向前推进时,这就是所谓的 dependency hell。

    作为一种解决问题的办法,我提出了一套简单的规则和要求来表明版本号该如何确定和增加。这套规则基于但不仅限用于已经广泛存在的开源闭源软件的一般实践。为了让这个系统工作起来,你首先需要声明一个公有的 API,它可以由文档组成或在代码层面强制实现,且必须是清晰准确的。一旦你标识了你的公有 API,你就可以通过不同的版本号的增加来交流 API 的各种改变。设想一个形如 X.Y.Z 的版本,不影响 API 的 bug 修复会增大补丁版本,向下兼容的 API 增加或改变会增大次版本,而不兼容的 API 改变会增大主版本。

    我把这套系统称作“语义化版本管理”。在这套系统之下,版本号及其改变传递了代码背后的含义,以及每个相邻版本之间的变化。