前端的业务逻辑和交互效果越来越复杂，代码量也随之越来越大，伴随着越来越大的代码量而来的还有代码的管理和部署的问题。模块化和预处理框架大行其道，新框架的出现让前端的开发环境越来越高大上了，但是部署到线上就越来越费劲了。在开发环境中模块化会将原本的大型应用分割成很多小模块，但是在上线的时候考虑到这些静态资源对 HTTP 请求数和请求体积的开销，很多小模块都需要合并然后再进行压缩。在 node.js 火起来之前，比较常见的处理工具有 ant，但是 ant 是基于 java 的，对于前端工程师来说使用起来很费劲。
node.js 火起来之后，出现了很多用于处理前端静态资源的优秀模块，还有专门用于前端静态资源构建的框架，如鼎鼎大名的 grunt，但是 grunt 由于其基于配置的设计模式和构建模式基于文件的限制，对于复杂一点的构建逻辑配置起来就会比较繁琐。
需求描述：从一组数组中找出一组按不同顺序排列的字符串的数组元素。假如有这样一个数组：
[ 'abcd', 'hello', 'bdca', 'olleh', 'cadb', 'nba', 'abn', 'abc' ]
需要找出的结果是：
[ 'abcd', 'bdca', 'cadb' ]
那么这里的关键点其实是判断一组字符串是否是否只是字符的顺序不同，只要解决整个关键点其他都好办了。
var stringClassify = function( arr ){
var arrLength = arr.length,
obj = {},
i = 0,
num, item, name, strLength;
for( ; i < arrLength; i++ ){
item = arr[i];
strLength = item.length;
num = 0;
// 将单个的字符转换成 Unicode 编码
// 对编码进行取和计算
for( j = 0; j < strLength; j++ ){
num += item.charCodeAt( j );
}
if( !obj[num] ){
obj[ num ] = [];
}
obj[ num ].push( item );
}
for( name in obj ){
console.log( obj[name] );
}
};
需求描述：从一组有序的数据中生成一组随机并且不重复的数，类似于简单的抽奖程序的实现。
先来生成一个有序的数组：
var arr = [],
length = 100,
i = 0;
for( ; i < length; i++ ){
arr.push( i );
}
从一个长度为 100 的有序数组中随机拿出 10 个随机的数，并且不能有重复。
在触屏设备上，一些比较基础的手势都需要通过对 touch 事件进行二次封装才能实现。
zepto 是移动端上使用率比较高的一个类库，但是其 touch 模块模拟出来的一些事件存在一些兼容性问题，如 tap 事件在某些安卓设备上存在事件穿透的 bug，其他类型的事件也或多或少的存在一些兼容性问题。
于是乎，干脆自己动手对这些常用的手势事件进行了封装，由于没有太多真实的设备来进行测试，可能存在一些兼容性问题，下面的代码也只是在 iOS 7、Andorid 4 上的一些比较常见的浏览器中测试通过。
tap 事件相当于 pc 浏览器中的 click 效果，虽然在触屏设备上 click 事件仍然可用，但是在很多设备上，click 会存在一些延迟，如果想要快速响应的 “click” 事件，需要借助 touch 事件来实现。
之前有写过一篇非等宽图片列表的布局的博文，那只是这种布局之前的叫法，为了和常规的等宽瀑布流布局做区分，根据这种布局的特性（整行是等高的），那么就叫等高瀑布流布局吧。
怎么又拿这种布局出来说事？最近几天在对以前开发的360图片搜索结果列表页的图片尺寸和交互效果做一些细节上的调整。同时也对布局的算法做了优化，之前采用的是以宽度裁切为主和夹杂着一些等比缩放的算法，当时是为了让每一行看起来高度都一致。由于宽度裁切的效果会让图片左右边缘部分有损失，而且当时也有图片 hover 时的放大效果在一定程度上弥补了这种损失。这次放弃了宽度裁切，也去掉了 hover 时放大图片的效果，全部采用了等比缩放的算法。
在上一篇博文中谈到的等比缩放的算法其实并不是最优的，还是会有一定的上下或者左右的裁切。研究了一下 Google+ 的相册使用的等高瀑布流布局的缩放，发觉还有一种更优的缩放计算的算法，于是花了两个小时将这种算法推演了出来。这里先检讨下，由于智商上的缺陷，数学绝对是我的弱项，这种算法比之前的要简单得多，之前是走了弯路了。