$ open journal://jinjiang
这里是勾三股四的家
译自：Naming CSS Stuff Is Really Hard
找到的这篇文章算是对我之前写的 《标签？ID？还是CLASS？》 的再深入。我当时写那篇文章的时候，就有朋友提出了“非语义化”的 class 命名的问题，我当时确实觉得很纠结，简单的想法是“框架性质的表象 class 我没异议……框架的实质是通过降低灵活性达成更广泛的共识，我们个人不要再创造这样的样式就好了”，但没有想到特别好的“套路”，更多的是在实际情况中再分辨。看过这篇文章，我似乎找到了更好的答案。同时顺着文中提到的 Nicolas 那篇文章看下去，也对 OOCSS、BEM 之类的提法有了更多的认同感。特译给大家参考。
译自：A successful Git branching model» nvie.com
本文将展示我一年前在自己的项目中成功运用的开发模型。我一直打算把这些东西写出来，但总是没有抽出时间，现在终于写好了。这里介绍的不是任何项目的细节，而是有关分支的策略以及对发布的管理。
在我的演示中，所有的操作都是通过 git 完成的。
译自：Writing Testable JavaScript - A List Apart
这篇文章算是 A List Apart 系列文章中，包括滑动门在内，令我印象最深刻的文章之一。最近有时间翻译了一下，分享给更多人，希望对大家有所帮助！
我们已经面对到了这一窘境：一开始我们写的 JavaScript 只有区区几行代码，但是它的代码量一直在增长，我们不断的加参数、加条件。最后，粗 bug 了…… 我们才不得不收拾这个烂摊子。
如上所述，今天的客户端代码确实承载了更多的责任，浏览器里的整个应用都越变越复杂。我们发现两个明显的趋势：1、我们没法通过单纯的鼠标定位和点击来检验代码是否正常工作，自动化的测试才会真正让我们放心；2、我们也许应该在撰写代码的时候就考虑到，让它变得可测试。
神马？我们需要改变自己的编码方式？是的。因为即使我们意识到自动化测试的好，大部分人可能只是写写集成测试(integration tests)罢了。集成测试的侧重点是让整个系统的每一部分和谐共存，但是这并没有告诉我们每个独立的功能单元运转起来是否都和我们预期的一样。
这就是为什么我们要引入单元测试。我们已经准备好经历一段痛苦的撰写单元测试的过程了，但最终我们能够撰写可测试的 JavaScript。
译自：语义化版本管理 2.0.0
对于一个给定的版本号 MAJOR.MINOR.PATCH (主、次、补丁)，其变化的规律是：
我们还可以根据预发布、构建元数据 (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 改变会增大主版本。
我把这套系统称作“语义化版本管理”。在这套系统之下，版本号及其改变传递了代码背后的含义，以及每个相邻版本之间的变化。
译自：Adjusting Image Brightness and Color Using the HTML5 Canvas API
你曾否需要调节一张图片的亮度？或者增强红色通道让它变得温暖一些？
这是我之前两篇文章“如何通过HTML5 Canvas处理图片酷效”和“如何创建一个HTML5的大头贴应用”的后续。在之前的那些文章里，我提供了一些可分离的颜色滤镜代码：灰度、灰褐色、红色、变亮、变暗等。这些滤镜都是经典的颜色滤镜，每个像素点的颜色都是独立运算的，互不影响。我们的可以将其建模成一个单独数据驱动的称为颜色矩阵滤镜(Color Matrix Filter)的东西。这一概念将会遍布本文。这种滤镜将会以一个包含权重(即系数)的颜色矩阵作为输入，并决定输出的颜色组件(color component)如何和输入的颜色组建相对应。
译自：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小贴士。
译自：https://www.html5rocks.com/en/tutorials/speed/parallax/
现在满大街都是视觉差(parallax)网站了，我们随便看几个：
也许你对这玩意儿还不太熟，视觉差其实就是它的视觉结构会随着页面的滚动而变化。通常情况下页面里的元素会根据页面的滚动位置而缩放、旋转或移动。
我们的视觉差demo的完整效果
不管你喜不喜欢视觉差网站，有一件事毫无疑问，它是一个性能的黑洞。因为当页面滚动时，浏览器的优化都倾向于新内容随滚动而出现于屏幕的最上方或最下方的情况。一般来说，内容改变得越少浏览器性能越高。而对于一个视觉差网站来说，在页面滚动时，好多元素都在发生改变，大多数情况下整个页面的大块可视元素都在发生变化，所以浏览器不得不重绘整个页面。
我们有理由这样归纳一个视觉差的网站：
建议大家先阅读我们之前介绍过的滚动性能来改进你的app的响应速度。本篇文章是基于那篇文章所写的。
所以文字是如果你在建立一个视觉差网站，那么你是否受困于高昂的重绘开销？有没有别的改进建议使得性能最大化？让我们看看这几个方案：
摘自：Chrome DevTools Revolutions 2013
本次开发者工具的改进中有几项新特性是针对性能的：
今年，在老罗锤子手机一路跳票、累不死手机活蹦乱跳、魅族手机版本号即将输给小米、iOS被拍扁、Windows Phone在卖萌、安卓在卖身等诸多鸟事相继雷到众生之后，人们无不感叹，手机这个行业还有救吗？站在智能和愚蠢的十字路口，我们该何去何从？囧rz
就在大家迷茫之时，Nokia发布了它的又一力作——1050！整个业界犹如刮来了一股春风，无不感到清新舒畅。大家纷纷感叹，那个曾经的科技巨人就要王者归来鸟！这个夏天，This summer，最受瞩目的大事件，big event！就是：
Nokia 1050 的发布！！！
作为一个反智能化手机操作系统的支持者，我很自豪的宣布，经历了前两轮的预定失败之后，我终于在上周成功订到了这款神机——要不要卖得这么好啊 - -
我之前用的手机是Nokia 1202，2008年的神机，其实也不算太老，要不是1050发布，它也其实已经是一个非常现代化、非常新款的愚蠢手机了，无奈在这个1050的时代趋势下也不得不接受停产的命运。
1050基本上继承了1202所有的成员函数和成员变量，小巧大方，简单易用，低碳环保，超长待机，便宜实惠，这已经足以吊起广大消费者的胃口了。然而真正的1050到底表现如何？它能否在1202的光环之下更进一步再创辉煌？带着这些疑问，记者走访了不少xxx，挖掘出了很多珍贵的xxxx，也听到了各种xxxxxxxx……
OK 马上开始