Tychlog

很多人觉得，前后端的差异主要是分别承载了数据和样式，功能和皮肤。前端就是视觉方面的，后端是实质性的。追溯到很多年前，确实是这样的，所谓的前端只是由于后端MVC中的View过于复杂，为了提升用户体验，提高加载速度，以及降低服务器压力，所衍生出的一些优化技术。

真的很久没写博客了，一直提不起兴趣，总觉得写一些代码如何写，工具如何用，过一阵子就不是很有用了，所以想写一些自己的心得体会，但又很难总结成文章。这几天突然间想通了一些，也许我是时候抛开前端这个枷锁了，今天我们来谈谈敏捷开发的结对编程。

想当年（然而并没有几年）刚来到ThoughtWorks的时候，除了英语，我最不适应的就是pair，即结对编程。因为刚上项目的我只能跟着结对对象的思维走，即使我思路正确了也无非是在我的结对对象写的代码上印证了一下，少有的贡献就是不时的提醒他一下typo之类无关紧要的错误。然后当我拿到键盘时，还是因为信息的不对等，我无法在全局层面上做出贡献，因为我必须非常熟悉整个项目才能说服我的pair，修改一些架构上的代码，否则只能改进一些细节上的代码片段。这种毫无创造性的工作方式让我昏昏欲睡，说好的挑战，困难，压力呢？我感到了一种可有可无的迷茫。

从去年春天就开始翻译这本《Pro AngularJS》，前前后后将近1年半总算是正式出版。从最初的兴奋，到期间的苦逼，最后拿到样书，还是很满足的。这本书由浅入深的详细介绍了AngularJS的各种功能和原理，以及大量示例贯穿全书，开头甚至还有一些JavaScript的基础。原书一共600多页，我和同事各翻译了300多页，我主要是翻译的关于Services的第三部分以及第一部分的后几章。

总的来说收获很多，对AngularJS有了更深入的理解，虽然书中使用的AngularJS版本已经比较旧了，但是对很多方法的使用以及原理的解读还是非常不错的。并且英语阅读能力也感到有明显提升，许多长句子一开始完全不知所云，花了好几个小时通过上下文和代码才慢慢理解其中深意。当然就翻译本来说，也是有许多感想，所以才写了这篇文章总结一下翻译一本书所需要注意的地方。

相信大多数人都有过关于CSS的痛苦经历，从我加入公司到现在，不到两年的时间里，听到最多CSS相关的讨论就是‘很难调’。所以我也一直在探究这其中有怎样的问题，为什么很多人觉得CSS很难写，如何才能让其他人更优雅的写CSS。在Code Review的时候，我渐渐的发现了问题所在，其实很多人已经掌握了丰富的CSS知识，但却不知道如何分组属性写成class。最后只好在需要改变样式的元素上随意起个名字做class然后把所有要写的属性丢进这个class里，如果优先级不够，再把前面的选择器都加上。结果就是CSS代码不断堆积，重复和冗余不断增多，维护也变得举步维艰。

前一阵子在项目组中讲了一个关于CSS的Session，在讲之前我曾收到了许多意见，大部分是希望能讲讲CSS实用性的技术，比如盒模型，CSS3之类的。干货人人都喜欢，因为看得见摸得着，拿来就有用，但我最后还是决定讲一些”湿货“。因为在Code Diff的时候我发现了许多样式的问题不是由于不会写CSS导致的，而是由于在错误的地方使用了写在错误地方的样式。

其实CSS很简单，没有计算没有流程，只是一直描述，无论什么复杂的效果，你只要Google一下就知道怎么写了，甚至可以直接copy。但CSS又很复杂，一个元素的表现会受到它旁边的兄弟元素，也会受到内部的子元素影响，还会受到父元素影响，在这种多重影响下，一个元素的显示逻辑会变得错综复杂。有没有面对塌陷的块级元素而束手无策？无论怎么改它的属性就是得不到自己想要的，但看看似乎一模一样的示例程序却安然无恙，是不是恨得咬牙切齿？我想这就是本文所要解决的主要问题，让你学会如何优雅的写CSS。

作为最流行的MVVM（Model-View-View-Model）框架之一，相信大部分前端对AngularJS都不会陌生，我也一样久仰大名。不得不说，AngularJS所带来的改变是巨大的，被称为未来浏览器的模式一点也不为过，尤其是思维上的转变。

作为一个常年挥舞着jQuery去指挥无穷无尽的DOM的前端，初次接触AngularJS是有困难的，许多先贤警告我们不要在AngularJS中使用jQuery，不是没有道理的。即使AngularJS中带有jQlite对象，也仅仅是为了弥补一些地方AngularJS的局限性。AngularJS操作UI的方式与jQuery有着极大区别，在深入学习之后，我渐渐的发现了这点。过去使用jQuery的前端就像一个操纵提线木偶的傀儡师，而手握AngularJS的前端简直是不折不扣的魔法师。前端开发者不再需要根据数据去改变DOM，然后填入数据，我们所要做的仅仅是决定数据的表现形式后等待数据的注入。文档流中的元素就像活过来了一样，根据数据表现出了对应的样子。

这一切的核心除了匪夷所思的DOM监听机制，还有就是AngularJS的模板（template）以及其中多不胜数的内置指令（directive）了。因此，我将在本文中谈谈AngularJS的模板以及其思维模式。

很久没有写博客了，一是刚入职比较忙，二是因为总有学到新的有趣的东西，停不下脚步来总结一下。最近出差到了帝都，反而能挤出些时间来写点什么了，也正好趁着出差做的这个项目讨论一下CSS理论。

我现在面对的CSS基本上就是一个三头六臂的怪物，一点不夸张，因为真的是三头六臂，同一个样式在同一个element上作用了好几遍，而同一个样式又分散在4，5个class上，优先级有很多层。可以看得出这个怪物不是一个人造就的，早期的开发者选择了SCSS技术，但混乱的import导致了一些基本的样式被多次调用，而后面的开发者又为了摆脱之前的混乱引入了其他共用样式，但无济于事。原因出在HTML上，CSS依托于HTML没有被正确的抽象，而HTML又完全的依赖业务，所有class以业务取名，HTML和CSS基本没有复用，最终抽出的共用样式也仅仅是又一次的重复。CSS重构最难的地方在于没有脚手架，即测试。虽然有一些方法来测试，比如reftest，但还不够成熟。抱着有总比没好的心态，CSS被一层又一层的覆盖了上去。

这本书读了许久才读了一遍，不同于之前读到的一些方法性的书籍，该书有更多的细节，但其中又存在许多理论性的东西，要消化它们可不是很容易。读完一遍后又快速回顾了一遍，马上又会发现很多新的东西并有一些新的理解，甚至让我觉得写这篇文章有点太急了，不过我还是应该尝试收集一些有营养的东西，至少记录现在的想法，相信对之后的第二遍阅读会更有益处。

书名其实有点误导我，或者说它不仅仅是其字面意思那样简单，‘整洁’不是简单的清洁，其主旨在于一种设计上的精巧。书的开篇就引用了几位大牛对代码整洁的解释来描述其意义。从抽象的描述中说，整洁代表着优雅、愉悦、精巧、简单，具体来说我觉得有以下几点：

• 易于维护，依赖简单。
• 设计精巧，没有改进的余地。
• 高可读性，意图一目了然。
• 完善的测试与错误处理。
• 没有重复，最精简的实体。

最后作者总结为深合已意，其实说起来简单，可做起来却不是这么容易的。代码可不是一块光秃秃的地板，只要使劲擦总能变整洁的。

Stylus似乎并不是很有名，以至于很多人不知道它是做什么的，但提到SASS相信有不少人听说过甚至使用过很长时间。其实无论是LESS、SASS还是Stylus甚至是Absurd这些预处理工具，都是对CSS的一种延伸和强化。出现这些工具的原因很简单，CSS本身只是一种描述性质的东西，甚至它不能算是语言而是样式表，所以我们需要一个有条件语句和变量甚至是函数的东西去动态生成CSS代码来达到提高效率和增强可维护性的目的。

本文主要以Stylus语法本身和简单的使用为主要内容，它的目的是介绍和简单指南。将不会过多涉及Javascript的API调用等问题。

介绍

官方的介绍非常简短而精炼：

Expressive, dynamic, robust CSS

有人说过程序员和码农的本质区别就是程序员会不断探索提高生产力的方法。思维模式的转变是提高生产力的最好方式，但打磨我们的工具也是十分有意义的事，本文将从开发环境，自动化开发，开发工具等几个方面针对前端开发效率的提升和代码质量的提高来展开讨论。

每件事都是一个程序，开发也像程序一样，每个步骤都是一段代码，当开发规模随着文档、代码、需求而增加时，重复的步骤变得越来越多。此时，如果可以像抽象代码一样抽象出一些相同操作就可以大大提升开发效率。因此，出现了更多更优质的工具来代替人工做一些不断重复的开发以减少程序员的工作量。

最近公司项目准备更换图片上传的插件，原来的是一个Flash控件，其实用起来还是不错的，还有进度条，浏览器支持情况也不错。不过因为某些页面的图片上传涉及到了跨域的问题，Flash似乎解决不了了，所以准备索性换成HTML5的，高端大气上档赤。然后这个HTML5上传图片功能自然落到了我的手上了。

一般来说图片上传无非就是文件操作的问题，本来这是服务器对文件流的一个操作问题，前端应该是管不上的，不过HTML5再次赋予了我们前端神圣而伟大的权利，有了HTML5部分后端失业了lol。

其实以前写过一个上传图片的插件，不过那时还活在IE6年代，只能用iframe搞定，虽然还挺好使的，不过在HTML5面前就是一个战斗力负5的渣渣，不仅需要后端返回各项数据，还必须把保存的临时图片地址再发给后端保存，实际请求是2次，而且还无法告诉用户上传进度与速度。

单元测试Unit Test

很早就知道单元测试这样一个概念，但直到几个月前，我真正开始接触和使用它。究竟什么是单元测试？我想也许很多使用了很久的人也不一定能描述的十分清楚，所以写了这篇文章来尝试描述它的特征和原则，以帮助更多人。

什么是单元测试？

先来看看单元测试的定义，在维基百科英文版中可以找到Kolawa Adam在 Automated Defect Prevention: Best Practices in Software Management 一书中对单元测试的定义：

In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures are tested to determine if they are fit for use.

重点在于最后，单元测试的目的显而易见，用来确定是否适合使用。而测试的方法则包括控制数据，使用和操作过程。那么以我的理解，每个单元测试就是一段用于测试一个模块或接口是否能达到预期结果的代码。开发人员需要使用代码来定义一个可用的衡量标准，并且可以快速检验。

很快我发现有一个误区，许多人认为单元测试必须是一个runner集中运行所有单元的测试，并一目了然。不，这仅仅是一种自动化单元测试的最佳实践，在一些小型项目中单元测试可能仅仅是一组去除其他特性的接口调用。甚至在一些图形处理或布局的项目中单元测试可以结合自身特性变的十分有趣，比如Masonry，一个网格布局库，在它的单元测试中不是一个红或绿的条目，而是一行一行的小格布局用以说明布局被完成的事实，这样比代码检查布局是否正确再以颜色显示结果来得更直观高效，也避免了测试程序本身的bug导致的失误。

打个比方，单元测试就像一把尺子，当测量的对象是一个曲面时，也许可以花费大力气去将它抽象成平面，但我更提倡量身定做一把弯曲的尺子去适应这个曲面。无论怎样，单元测试是为了生产代码而写，它应当足够的自由奔放，去适应各种各样的生产代码。

keyup和keydown事件以及keyCode和which属性

我想关于键盘事件最常见的实例就是回车提交表单了，恐怕每个前端都有一段烂熟于胸的代码用来实现这个功能。以前我也只是做了这样一个功能，也许它的代码是这样的：

function enter (p_event) {
    var _keyCode = p_event.which ? p_event.which : p_event.keyCode;
    var _ENTER_CODE = 13;
    if (_ENTER_CODE === _keyCode) {
        //enter code...
    }
}

如果需要兼容ie8及以下，那还需要这几行代码：

if (typeof p_event === 'undefined') {
    p_event = window.event;
}

当然，enter还需要绑定到一个键盘事件中，键盘事件有三种，我以前倾向于使用keyup [1]，这样的体验比较好，符合人的习惯，在松开按键的时候生效。不过有时候keydown也是很棒的选择，比如说用户希望可以快速触发时，比如游戏中，我还记得WOW有一款插件是专门修改为按下触发技能的。

上周介绍了几种配色工具，这次要介绍的是一些图片和图标的生成工具。

就算你熟练掌握Photoshop之类的图片处理工具，要制作一个小小的图标还是挺费时费力的。可是网上下载的话，颜色尺寸又不一定能适合，所以制作图片的工具将是非常必要的。

Online Generator

Online Generator包括好几个很棒的工具，首先是Preloaders，它用于制作loading图片，它的图片种类很齐全，还有大量的3D图片，最重要的是它可以任意改变尺寸，当然也包括颜色，动画。动画可以选择方向频率等等，功能十分强大，基本上只要你能找到喜欢的图案，它就一定能制作出你想要的loading图片。

《编程珠玑》这本书读完感觉很诡异，在读的过程中感觉很有收获，但是却说不清从书中获得了什么，好像什么也没读懂。说实话，很难对这本书归类，有时它告诉你的是实际操作的性能问题，有时又在讲算法或者数据结构。不过确切的说，它告诉我们的是一种无招胜有招的境界。无论是实际操作、算法还是数据结构都是在为项目服务的，我们的目的只有一个，那就是完成项目。

一个项目与一个科研课题的区别就是它需要被实践，需要一种行之有效的解决方案。在一个系统被部署到实际环境中时，有时可能需要它无比精准，有时是快速运行，有时是超低成本，或者也有可能是兼而有之的权衡。此时工程师就需要调整一切可以调整的东西去满足这些需求，这些东西自然就是硬件环境、算法、数据结构了。作者Jon Bentley要告诉读者的就是这些调整所需要的手段。

作为一名前端工程师，或多或少都会接触到设计，虽然我很讨厌有人把前端和美工等同，但是我仍然很喜欢设计，这是一个Web必不可少的环节。

不过毕竟不是专业的设计师，不可能什么都靠自己，我相信工具的帮助将会让前端做起一般的设计来游刃有余。

首先介绍简单而常用的工具，颜色选择工具。

Kuler

Kuler是adobe的一款在线配色方案分享服务，上面有海量的设计师们的配色方案，最多有5种颜色，有详细的颜色代码，HSV，RGB，CMKY，LAB，HEX。每一个配色方案都可以收藏，只有你有adobe的帐户，还可以随意修改。

以前上学的时候其实大概读过这本书，但是那时没有什么项目经验，对于重构还很难理解其意义，最近因为又读了一遍这本书，发现确实是很棒的一本书，虽然现在写javascript，而这本书是以java为基础的，但仍然有很多值得参考的地方，尤其是一些常见的重构手法，让人看的时就会觉得对对对，确实经常这么干，比如Extract method还有Replace array with object等等都可以应用到其他环境中。

阅读这本书最重要的首先是需要理解的是什么是重构，以前也自诩会定期重构代码，但现在想想，其实真正算作重构的时候并不多，大部分时候我们其实只是在重写，只是因为项目规模较小，所以许多问题并没有暴露出来罢了。

先看看重构的定义：“对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本”

##创建##

使用Github创建博客，项目名必须是username.github.io，然后直接使用主分支master即可。github使用的jekyll会自动根据相关文件生成一个_site文件夹，包括整个blog的静态文件用于访问。

_layouts文件夹为模板文件夹，可以创建一个default(自定)的html文件作为模板，并使用作为模板接受的内容变量，另外还有在Github上创建一个博客之类的变量。 _posts文件夹为博客文章文件夹，发布文章的格式为yyyy-mm-dd-blogname，也就说文章的日期是自定的。格式可以使用html、md、textile。当然更易于管理的方式是建立Year>Month>Day这样的目录结构。

所谓的mouselook其实就是第一人称视角，而pointerlock技术（其实和第一人称没什么关系,只是说这个技术可以用来实现第一人称）其核心就是让鼠标隐藏并且无论怎么拖动鼠标，鼠标指针都不会跑出目标区域。

今天在segmentfault上和某人探讨了一下这个https的握手流程，其实我一开始也不是很清楚，也没有好好去思考过，通过回答这个问题，对https有了更深的认识。

首先我搜索到的流程正规说法是：