Sale重构记录

---

针对目前手机业管多处用到各种情况下面获取不同的车源信息、原来手机业管接口中存在许多冗余的获取车源信息的地方、各取各自所需。

现改进如下：

1. 在公共interface中存在一个获取车源所以信息的方法就可以了。
2. 其他所有需要获取车源信息的地方都必须通过配置的方式来获取车源信息，可以配置自己需要车源的哪些信息。
3. 该统一接口返回的每个车源字段都是用统一命名。
4. 如果有些外部逻辑需要用到别的名字（比如之前客户端用了名字，现在不能发版。那么名称兼容在取得数据后各自逻辑块中自行处理。
5. 将原来直接数字写的一些常量配置到公共配置文件中

7月17日google发布了Chrome 36正式版，这个版本正式支持了HTML imports，这意味着Web Components的全面实现已经不再是遥远的未来了。
身为一个Web开发者怎么不來体验一下这些面向未来的组件标准呢？果断升级了Chrome 36，抢先体验一把。

如果还不是很了解什么是Web Components的话，可以看看components-introduction。

Templates

Chrome 26开始支持template标签，这个标签可以看做是客户端的模板，我们在服务器端和客户端的模板引擎层出不穷，想必大家也都用过不少了，两边各有特点。

服务器端模板引擎

在服务器端将模板和数据合成，返回最终的HTML页面

优点

1. 渲染过程不执行JavaScript脚本？
2. SEO友好

缺点

1. 客户端模板的优点就是它的缺点

客户端模板引擎

将模板和数据分别传送到客户端，在客户端由JavaScript模板引擎渲染出最终的HTML视图。

优点

1. 可以将静态的模板文件进行缓存和负载均衡，对于流量大的网站很有价值。
2. 模板渲染过程转移到客户端，减轻服务器的负荷。
3. 可复用性高。一个页面的前端内容可能来自不同后台，用了不同的架构，甚至是不同的语言。他们的模板引擎可能五花八门根本不能复用共享。
   客户端不存在这个问题，不同的架构，不同的语言可以使用相同的客户端渲染引擎，从而实现模板共用，结构统一，易于修改和扩展。
4. 从职责区分来说，模板渲染其实算是前端开发的工作。长久以来后端工程师一直苦于需要在处理数据的同时还要参与页面上的展示逻辑。 前后端的工作一直紧紧的耦合在一起，使用客户端模板从一定程度上解决了这个问题。
   后端工程师只需要专注于底层业务逻辑和数据的处理，而前端工程师也不需要再和后端工程师在HTML结构上苦苦纠结。

缺点

1. SEO不友好？

我们再来看看template，它不但拥有上述客户端模板引擎的所有优点，最重要的是它是Web Components的一个标准， 这意味着未来的某一天，所有主流的浏览器都可以使用它来做模板引擎而不用下来多余的模板引擎框架文件，不需要担心找不到会使用它的人！

上面我打上了问号（？）的地方其实算是一种讹传，他们在某些搜索引擎下（某度）的时候是成立的，但Google是可以执行Javascript脚本的，所以不存在SEO不友好的问题。 技术都是一直向前进步的，不是吗？

正式上场之前

在我们正式使用前，先写个小函数来判断你的浏览器是否支持tamplate。

function supportsTemplate() {
   return 'content' in document.createElement('template');
}
 
if (supportsTemplate()) {
   //支持
} else {
   //不支持
}

接下来实现一个小例子。 JS Bin

<template>标签中的所有元素都会由解析器解析，但仅仅只是解析。中间如果有脚本，脚本不会马上执行，图片也不会下载，而<template>本身也不会被显示出来。
只有在把<template>中的元素复制插入或直接插入页面时，其中的内容才会被运行。 在上面的例子中就是这一句。

document.body.appendChild(content.cloneNode(true));

可以想象他配合上 imports 可以很轻松实现按需加载js的功能，而且从也很符合逻辑，先加载对已模板需要的js再渲染模板，是不是很赞呢？

昨天同事告诉我公司的M站在 IPhone 手机上的Javascript全部都无法执行，让我帮忙看看出了什么问题。
听到在IPhone上出问题也是见怪不怪了，把手机连接上电脑调试了下发现报了如下错误：

QuotaExceededError: Dom exception 22: An attempt was made to add something to storage that exceeded the quota

意思是Storage超出了配额，我只想说，你是在开玩笑嘛，公司的M站只在storage初始化的时候添加了一条key/value而已啊。
我的直觉告诉我这肯定又是IPhone上坑爹的设计（bug）中的一个，果不其然，我在stackoverflow上找到了这么一个回答： stackoverflow。

原来Safari在所谓的private mode下不允许使用Storage功能，只有在用户自身开启non-private mode的情况下才可以正常使用Storage。
所谓的non-private mode就是中文safari下的无痕模式，敢问正常的用户有几个人会去开启这个模式？ 既然不让人使用就不要把Storage开放出来啊。。。囧死个人，没办法只好我们自己去判断Storage功能是否可用了。
正常情况下我们会这么判断Storage是否可用：

if ( !window.localStorage ) {
    //ie6，ie7 使用UserData替代实现
    //...
} else {
    //使用storage
}

可惜的是这种判断方法在safari上不适用，localStroage，sessionStroage和Storage在safari上都是存在的，只是不让使用而已（就不让你用，来打我啊~O(∩_∩)O哈哈~） 不过因为在使用的时候会报QuotaExceedError，利用这一点我们可以通过try/catch来判断。代码如下：

if ( !window.localStorage ) {
    //ie6，ie7 使用UserData替代实现
    //...
} else {
    //判断是否Storage是否真的可用
    var localStorage = window.localStorage;
    var test = 'test';
        try {
            storage.setItem(test, '1');
            storage.removeItem(test);
            //使用Storage
        } catch (e) {
            //使用cookie替代实现
        }
}

这里就不把全部代码写下来了，因为大家的Storage封装可能都不太一样。

不得不说不管是在开发Wap还是Web App，IPhone上的坑都是多的惊人，明明在android上能完美运行的代码在IPhone上就是出各种莫名其妙问题，果然我是没办法喜欢上IPhone啊。

PS:关于Web App开发能使用的UI框架，最近百度的团队正要开源一个Web App的框架blend UI，在演示现场运行的时候确实有着不错的效果。
经常要做Web App的人可以关注一下blend UI的开源进度，相信肯定会对提高大家在开发Web App时的效率上有一定的帮助。

最近和我们公司负责切图工作的同事那边要了一些psd来学习切图。好久没有做过关于CSS方面的工作，写起来憋手蹩脚的。
最近打算研究一些CSS相关的东西来练练手，免得到要用的时候才发现自己已经忘得差不多了。

在制作Web页面时大家或多或少都有碰到CSS制作水平垂直居中的问题，特别的其中的垂直居中，更是让人烦恼。
用CSS来实现元素的垂直居中效果是件苦差事，这里我总结了一下几种不同实现的方法和他们的优缺点和适用场景。

垂直居中

方法一：

这种方法适合只有单行内容的情况。只要保证元素内容是单行。并且高度是不变的。将height和line-height的值设置成一样就可以了。

JS Bin

适用场景

1. 能在所有浏览器下工作，没有足够空间时，内容不会被切掉（没有足够空间就不属于单行了）。
2. 对运用在小元素上是非常有用，比如说让图片或者单行文本字段垂直居中。

优点

1. 实现简单。
2. 结构简单。

缺点

只能在单行时适用，多行时效果很差。

方法二：

这种方法要实现垂直居中首先要满足有一个固定的高度，并且父容器需要设置相对定位（position: relative）。
给需要垂直居中的容器设置绝对定位（position:absolute,并且定位高度（top:50%）和margin-top为负的高度的一半（margin-top:-height/2）。

JS Bin

适用场景

1. 能在所有浏览器下工作。

优点

1. 不需增加额外的标签。
2. 结构简单。

缺点

1. 只能支持固定高度的情况。
2. 需要父标签配合设置相对定位。
3. 固定高度导致内容溢出时会出现滚动条或隐藏，不会配合内容高度变化。

方法三：

这种方法是通过让div去模拟表格的效果，从而通过使用table-cell的vertical-align属性来实现垂直居中。

JS Bin

适用场景

1. 不兼容ie6，ie7

优点

1. 可以自适应高度，不会出现滚动条。
2. 高度不足不会被切断。

缺点

1. 兼容问题，不兼容ie6，ie7。display: table 在ie6，ie7下无效（不能强行装table了，好忧伤）

怎么做兼容？

要兼容蛋疼的ie6，ie7，需要在原本的table-cell里面再套一层div，并且针对ie6，ie7使用hack。

JS Bin

ie6下的效果图：

方法四：

这种方法是通过在居中元素前放置一个空的块元素，设置块元素的高度为50%，margin-bottom为居中元素负的高度的一半，居中元素清除浮动来实现的。

JS Bin

适用场景

1. 能在所有浏览器下工作。

优点

1. 在没有足够空间的情况下不会被自动切割。
2. 比上一个模拟table实现起来更简单。

缺点

1. 元素高度固定。
2. 元素溢出时只能在父元素上设置overflow属性，出现滚动条或切割。
3. 增加了一个多余的块元素，为了保证ie6，ie7下的兼容性，div必须是有内容的块元素，这里用了&nbsp;填充。

ie6下的效果图：

方法五

当我们只需要一个简单的多行文本垂直居中而且父容器的高度没有要求时，可以很简单的用设置上下相同的padding值来做到。

JS Bin

适用场景

1. 能再所有浏览器下工作。

优点

1. 结构简单。

缺点

1. 父容器不能有固定高度。

上面讲了5种不同的垂直水平居中的方法，其实还有非常多的实现方法，这里就不一一总结了，我们还是在这展望一下未来我们所希望的垂直居中的方法吧。
现在所使用的垂直水平居中的方法，绝大部分都是通过各种奇妙的写法来达到效果的，我们想要的是更简单的写法。比如：

position：center;

希望css未来的发展能够满足大家这个迫切的需求，不用再在各种各样的垂直居中方案中纠结了。(╯‵□′)╯︵┻━┻

有兴趣继续了解的可以去w3cplus看看，上面有更多更加完善、碉堡的总结。

最近参加了第三届JSConf中国开发者大会，这里谈谈两天下来自己的一些感受。
首先不得不说一下主办方还是很厚道的，大会的内容很紧凑，涵盖了各个方面的内容。
对于我才刚刚毕业一年时间的新人来说，确实是开了不少眼界。也再一次感受到了自己的经验还很不足。
这里谈谈一些印象比较深刻的部分，以下意见仅代表个人观点，有错的地方请大家指正。。。

Then.js 异步库的实现原理及优缺点 – 严清

大家在只写过前端JavaScript，没有真正写过Node的项目的时候，可能体会不到什么叫做callback hell。
前端JavaScript很少会出现一个callback套了很多层callback的情况。而Node由于异步I/O的存在，Node几乎所有的函数都有callback。
这就导致了Node代码入门容易，想写好却很不容易。

第一个speaker最先分享了关于callback hell的一些解决方案和他们的优缺点

Event模式

使用JavaScript中最重要的模式来解嵌套，这个方案的原理是使用EventEmitter来解嵌套。
实际使用中感觉这个方案并不是很适合来解决嵌套问题(虽然可以解决)， 它更适合做它原本应该做的事 – 实现事件发布和订阅机制

Promise/Deferred模式

这个模式其实绝大部分前端都使用过，最常见的例子就是JQuery中封装的$.ajax了，它允许我们先发送请求，而后再确定如何处理数据。

var promise = $.ajax('get/something');
//do something...
promise.success(function() {
    //...
});

他的缺点是每个业务都要单独封装(比如ajax业务， fs业务等)

Generator， Thunk等模式

这些模式还没有实际使用经验，不做评论，等有机会实践后在评论。

then.js

现场没有听明白，下载了ppt结果发现ppt也没说明白，坑爹。先follow下有机会再试用。
据作者描述性能远超其他所有库，而且代码简短，写出来的代码风格也好。如果真是这样那还真是解决了一大难题了= =

淘宝前后端分离实践(中途岛) – 赫门

长久以来，MVC中的所有部分都是交给后端工程师去实现，而前端工程师负责的部分往往就是切图。
这种职责划分不得不说是欠妥的。后端不单包办了数据库交互，控制器，数据输出，甚至还去实现了大部分的前端效果。
而前端由于只负责了切图，导致时常出现html结构和实际前端效果所需要的html结构有很大的出入，出现需要返工重写结构，css的情况时有发生。

当然不单单只有这么些问题，后端需要将静态页面改成动态模板也导致了前后端的信息不统一。
在之后的更新改动中，前端改动的是静态页面，后端则需要去观察静态页面的改动，再把改动移到模板中，这中间可能发生的各种各样麻烦事。

就跟代码为什么要重构一样，前后端的关注点和职责也应该更加分离。
我们不应该从硬件环境来区分职责(browser和web server)，而应该从工作职责上来区分。
现在有了Node，前端有了接触后端业务的良好环境。
而且，更因为Node在处理I/O密集型的业务时更胜PHP/JAVA这些语言一筹，View和Controller的任务交由前端来做也是有理有据的。

目前，淘宝首页和详情页正是采用了这种后端负责数据和业务逻辑， 前端负责路由设计，控制逻辑和浏览器端的html，css和js的设计。
并且已经有更多地项目开始实践这种职责分工， 相信他们的实践会给我们指明今后的道路。

Peer-Directed Collaborative Projects – 大神James Halliday

他的分享我觉得比起这个题目更应该说是他个人一年内所做的项目的总结，内容很多，每个项目都非常有创意，很抱歉大部分我都没太听懂。。。
唯有browserify总算是懂了一些。

现在在浏览器前端，主要流行的模块化方案主要有两种RequireJS和seaJS。
RequireJS(定义了AMD规范)是提前执行，推崇依赖前置。
seaJS(定义了CMD规范)是延时执行，推崇依赖就近。 这里吐槽一下我们的G。js的简介是A AMD implementation inspired by seaJS。
明明是实现了AMD规范，却表示自己灵感来自seaJS，囧。

这两种方式各有千秋，但是都和Node实现的CommonJS有差别，其中最明显的就是多了用define函数来包覆js文件了。
而browserify则是实现了前后端JavaScript统一规范的写法。他可以让浏览器端一样可以使用形如

var module1 = require('module1');

这种形式来引入模块，甚至可以把npm包和Node原生模块一起封装到前端真正做到前后端代码可以复用。
只能说大神的想法，你不服不行，别人也是真正做到了消灭前后端代码差异。browserify绝对是大会上的一个亮点。

目前所了解到的一个缺点是，browserify由于采用的是预编译的形式来封装代码，相比RequireJS和seaJS来说，可能在合并公共JS代码的时候会比较不方便。 而这种all-in-one的js封装形式，因为经常要下载更新后的JS文件，在代码频繁修改的时候也会影响到用户加载速度。

如果browserify能推出封装公共代码的封装方式的话，肯定会更加完美。

ps:大神真不愧是大神，自带unix小本本，大会期间代码写的飞起，单身20多年的手速什么的。。。

如何持续技术学习 – 玉伯

一个乍看没什么技术含量的标题和乍听之下不怎么滴的口才，却是我当时很关注的一个分享。所以也来说说
如何持续技术学习难道不是每个技术最应该关心的话题吗?

时间管理 情绪管理

“其实我们并不需要时间管理 需要的是情绪管理与适量自律” 我本身是一个很情绪化的人，所以我很同意情绪不但会影响我的效率，也会影响我的学习积极性。
保持一个愉快的心情去学习去工作远比，什么年度计划表有意义的多。
适当地自律远比用什么番茄工作法来强迫自己来遵守时间来的有效。 毕竟学习不是用逼就能学好的。

知识管理

1. “投入在 Input 上的时间越多，知识管理越差”
2. “最好的阅读是产出。”

这个简直不能同意更多，其实很多时候我们mark了很多技术文章，其中派上用场的却寥寥无几，
更多的是mark下来的时候那爽快感，就好像mark了，看了一遍，就学会了一样，殊不知还没等到睡觉你已经全忘光了。 最好的学还是去用，去产出。被动的接受知识远没有抱着疑问去寻求答案来的有效率。

梦想

梦想不是空头支票，需要你投入相当的时间和知识，再加上一个平和的情绪去实现它，要做一个有追求的程序员。

总体感受

国内倾向于分享实际应用中的产物，比如异步库then。js，淘宝前后端分离实践，BlendUI等。
而国外的分享感觉更加天马行空一些，比如James Halliday的所有分享trumpets，browserify， Jacob GroundWater的NodeOS等。
有很多其他分享也不错，时间不多这里就不一一回顾了。 顺便感慨下，James Halliday大神的手速真是吊的一b，光凭他能一边演讲一边以打字聊天般的手速写演示代码就足够让我五体投地了。
晚上回旅馆follow了他的github，看到那满满的几乎没有断过的提交后更是哭晕在厕所。
未来应该更多地参与开源的项目，学好英语，有益于别人，更有益于自己进步。