去年年底的时候刚换了工作，刚到杭州，一到杭州就赶上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 完成的。
阅读剩余部分...
译自：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的响应速度。本篇文章是基于那篇文章所写的。
所以文字是如果你在建立一个视觉差网站，那么你是否受困于高昂的重绘开销？有没有别的改进建议使得性能最大化？让我们看看这几个方案：
阅读剩余部分...
«1234567891011121314151617181920»