译自：Writing Testable JavaScript - A List Apart
这篇文章算是 A List Apart 系列文章中，包括滑动门在内，令我印象最深刻的文章之一。最近有时间翻译了一下，分享给更多人，希望对大家有所帮助！
我们已经面对到了这一窘境：一开始我们写的 JavaScript 只有区区几行代码，但是它的代码量一直在增长，我们不断的加参数、加条件。最后，粗 bug 了…… 我们才不得不收拾这个烂摊子。
如上所述，今天的客户端代码确实承载了更多的责任，浏览器里的整个应用都越变越复杂。我们发现两个明显的趋势：1、我们没法通过单纯的鼠标定位和点击来检验代码是否正常工作，自动化的测试才会真正让我们放心；2、我们也许应该在撰写代码的时候就考虑到，让它变得可测试。
神马？我们需要改变自己的编码方式？是的。因为即使我们意识到自动化测试的好，大部分人可能只是写写集成测试(integration tests)罢了。集成测试的侧重点是让整个系统的每一部分和谐共存，但是这并没有告诉我们每个独立的功能单元运转起来是否都和我们预期的一样。
这就是为什么我们要引入单元测试。我们已经准备好经历一段痛苦的撰写单元测试的过程了，但最终我们能够撰写可测试的 JavaScript。
阅读剩余部分...
译自：语义化版本管理 2.0.0
摘要
对于一个给定的版本号 MAJOR.MINOR.PATCH (主、次、补丁)，其变化的规律是：
- MAJOR version (主版本) 会在 API 发生不可向下兼容的改变时增大。
- MINOR version (次版本) 会在有向下兼容的新功能加入时增大。
- 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 改变会增大主版本。
我把这套系统称作“语义化版本管理”。在这套系统之下，版本号及其改变传递了代码背后的含义，以及每个相邻版本之间的变化。
阅读剩余部分...
译自：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
本次开发者工具的改进中有几项新特性是针对性能的：
- 持续绘制模式
- 显示绘制矩形及其层的边框
- 每秒帧数的测量仪
- 找到强制同步布局(layout thrashing)
- 对象分配跟踪
阅读剩余部分...
“国足打出了精气神儿”
相关新闻：东亚杯-王永珀2球孙可建功 中国两球落后3-3日本
当我再一次看到这样的标题的时候，我就知道，言外之意是国足的状况一定非常糟糕。
精气神儿是个什么东西？我觉得是一种最基本的态度，它只是个精神层面的很虚的过程。我举个例子，当你一无所有的时候，你只能说：哦，至少我还有节操。——这就是拿精气神儿说事儿的节奏。
国足说我们努力了，大家说其实人家从上到下还是很努力的，这一点我们还是要认可的……好吧你们确实真的很努力，但为时已晚。而且国足真的很差，现在才知道努力有个屁用？未雨绸缪的事情怎么从来没见足协做过？
以前国足被叫作头球队，叫热身赛之王，如今头球也没了，热身赛也能输个精光，连博彩公司的小伙伴们都惊呆了。
以前几年赢不了韩国就说恐韩，如今15年不胜日本了，也没人造出个什么恐日了，因为觉得跟人家比不自量力，丢不起那人。
以前国足98年，当时还叫东亚四强赛，国足在日本的主场2比0羞辱对手，范志毅还踢飞丢了一个点球，不然就是3比0的大胜（对，两边都是成人队，而且都是男足）。如今在一片铺天盖地的唾骂声中，国足才开始努力，开始打出精气神儿，勉强在最后时刻，逼平了日本二线队。
国足的努力掩盖不了一个事实，那就是战绩糟糕，排名持续下滑，多年无缘各项国际大赛。
这有什么可高兴的？
所以请别扯淡！拿成绩说话！！
看看今天的国足，还剩下什么？答：“只剩下两滴冰冷的泪水：一滴化斗酒添一份麻醉；一滴沉落于岁月的潮水。”
好。我这里对国足的吐槽完毕。
其实我没想太多聊国足。
接下来，请把“国足”二字换成你看到“其实很努力”之后首先联想到的事物，然后把上面全文的“国足”二字换掉重读一遍。相信你会很有乐趣和感悟。
吐在前面的槽……
今年，在老罗锤子手机一路跳票、累不死手机活蹦乱跳、魅族手机版本号即将输给小米、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 马上开始
目录
- 开箱/外观
- 屏幕
- 主界面
- 基本功能 (电话/短信/通讯录)
- 特色功能
- 实用工具
- 性能/续航能力
- 综述
阅读剩余部分...
- 工体上空飘扬着“傻X”的洪亮口号，晚上天津牌照的车又被砸了不少
- 比赛收视率直线下降——比赛才开始了13分钟，还有80分钟呢
- 赞助商的脸全都绿了，下次国足的比赛就没有再打广告了，不过无非是又有别的厂商挨宰了
- 谭晶从此霉运不断
- 看台上两国外交部长正在谈一个上百亿的项目，荷兰大爷若有所思的说：这个我们回去再考虑考虑…… 对面：恩，下次我们还是改一起看乒乓球吧
- 刘建宏紧紧攥着双拳：完了完了，今天这场球大Boss都在看啊，这种球我该肿么说比较得体呢？肿么办肿么办……
- 小区里：还是很安静的，现在大家看球都不是看彩电了，要么是笔记本电脑，不舍得扔下去，要么是大平板电视，扔不动
阅读剩余部分...
远远关注Sass很久了，今天终于鼓起勇气写了我的第一个Sass文件
Sass简介
一种CSS的预处理程序，基于Ruby运行。安装过程和相关的准备工作非常简单：
- 当然首先要安装Ruby
gem install ruby，必要的环境下需要在命令前加上sudo- 进入我的博客主题文件夹，运行
sass-convert style.css style.sass，把我的css文件先转换成sass文件
- 运行
sass --watch style.sass:style.css，使得程序自动把style.sass文件接下来的任何改动自动同步转换到style.css
这时，新的Sass文件就创建完毕了！^_^ 去碎觉……
呵呵，开个玩笑。其实这样的Sass文件虽然格式上没有任何问题，但和直接撰写CSS几乎没区别。而Sass除了可以让我们少写几个花括号和分号之外，其实还有很多实用的特性是我们真正需要的。
无论如何，现在的这个Sass文件是一个整理的基础，接下来，我们就来一步一步整理这个文件，同时也一步一步熟悉Sass的特性。
阅读剩余部分...
«1234567»