Git 分支的最佳实践

译自:A successful Git branching model » nvie.com


本文将展示我一年前在自己的项目中成功运用的开发模型。我一直打算把这些东西写出来,但总是没有抽出时间,现在终于写好了。这里介绍的不是任何项目的细节,而是有关分支的策略以及对发布的管理。

在我的演示中,所有的操作都是通过 git 完成的。

阅读剩余部分...

撰写可测试的 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 改变会增大主版本。

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

阅读剩余部分...

通过HTML5 Canvas API调节图像的亮度和颜色

译自:Adjusting Image Brightness and Color Using the HTML5 Canvas API

你曾否需要调节一张图片的亮度?或者增强红色通道让它变得温暖一些?

这是我之前两篇文章“如何通过HTML5 Canvas处理图片酷效”和“如何创建一个HTML5的大头贴应用”的后续。在之前的那些文章里,我提供了一些可分离的颜色滤镜代码:灰度、灰褐色、红色、变亮、变暗等。这些滤镜都是经典的颜色滤镜,每个像素点的颜色都是独立运算的,互不影响。我们的可以将其建模成一个单独数据驱动的称为颜色矩阵滤镜(Color Matrix Filter)的东西。这一概念将会遍布本文。这种滤镜将会以一个包含权重(即系数)的颜色矩阵作为输入,并决定输出的颜色组件(color component)如何和输入的颜色组建相对应。

阅读剩余部分...

JavaScript V8性能小贴士

译自:Performance Tips for JavaScript in V8

简介

关于如何巧妙提高V8 JavaScript性能的话题,Daniel Clifford在Google I/O上做了一次非常精彩的分享。Daniel鼓励我们“追求更快”,认真的分析C++和JavaScript之间的性能差距,根据JavaScript的工作原理撰写代码。在Daniel的分享中,有一个核心要点的归纳,我们也会根据性能指导的变化保持对这篇文章的更新。

最重要的建议

最重要的是要把任何性能建议放在特定的情境当中。性能建议是附加的东西,有时一开始就特别注意深层的建议反而会对我们造成干扰。你需要从一个综合的角度看待你的Web应用的性能——在关注这些性能建议之前,你应该找PageSpeed之类的工具大概分析一下你的代码,也算是跑个分先。这会防止你过度优化。

对Web应用的性能优化,几个原则性的建议是:

  • 首先,未雨绸缪
  • 然后,找到症结
  • 最后,修复它

为了完成这几个步骤,理解V8如何优化JS是一件很重要的事情,这样你就可以根据其对JS运行时的设计撰写代码。同样重要的是掌握一些帮得上忙的工具。Daniel也交代了一些开发者工具的用法,它们刚好抓住了一些V8引擎设计上最重要的部分。

OK。开始V8小贴士。

阅读剩余部分...