囧克斯

务实的小而美

随意分享几则自己近期的感悟

人不够？

我自己发现周围的同学越来越把一句话挂在嘴边，那就是：我们就这么些人，想搞定这件事情是远远不够的

说白了，大家觉得“人多好办事”，“规模”这个词很多情况下几乎就是个褒义词。

但是今天有些变化正在悄然发生，比如人类的学习能力越来越强，同时信息技术越来越发达，学习新知识的门槛越来越低，比如各技术领域的成熟度越来越高，比如移动时代前所未有的技术挑战，在有限的硬件性能和网络带宽的情况下，越是“规模”的东西越难以维持；比如体力和知识都逐渐远离核心竞争优势等等

拥抱社区，“我们有更多人”

一件事搞得起来搞不起来，逐渐不取决于我们的团队有多少人，而取决于我们有没有让这件事情发生在最广阔的舞台上，因为一个技术团队再多人，哪怕一百多人，相比起任何一个知名技术社区都是九牛一毛，而一个集团、一个国家、一门语言的社区，相比起全球的互联网社区，也都是渺小的。所以今天，我们想在技术上成就一件事，未必需要很大的团队，未必需要很多人在身边

同时，我们也不能小看个体在科技发展中所起到的关键作用。技术的不断融合和碰撞也加速了这件事情。所以更重要的不是团队有多少人，而是团队有没有能够真正起到关键作用的个体，找到对的人，比组建一支上百人的团队要重要得多

从社区汲取最好的技术

我敢说，抛开具有真正技术驱动力的公司，绝大多数公司的技术工作都能够在社区找到现成并且适合的方案，也都不太需要最高精简的科研探索。一个务实的技术方案，一定是在大量的社区成熟技术基础上建立起来的，再加上一点点针对自身业务独特性的技术实践。不过看上去“没什么自己的东西”罢了，如果大家很介意这东西“得是我自己的”，那么你需要继续考虑这个问题：自己搞出来的东西能不能比今天社区的更好，能不能发展成更好的社区，是否可以在社区中的深度参与从而把“别人的”变成“自己的”

在社区中施展+检验自己的技术

然而社区不应该只有索取，还应该有奉献，如果你发现有件事情是别人也会再次遇到的那种事情，但社区没有合适现成的东西，那么恭喜你，赶紧开工吧

有的时候觉得社区化的技术发展也有它残酷的一面，同类的方案或工具库基本上也就全球数一数二的几个能生存下来，并且体现出可观的价值，稍微差一点的，也许绝对实力没有差很多，但只要不是第一，所产生的价值和影响力就少得可怜了。所以想掂量掂量自己，看看是不是这块料，不妨放到社区里跟大家一起来一场真正的PK吧！也别自己憋着，别觉得“等我弄得再完善一点再给你们看”，因为在社区化的技术发展中，这样做只会让自己越来越没有价值和勇气把它拿出来了。当然也不必贪多，哪怕是一个小小的功能，如果做到最好，能够被全球的开发者使用，那也是极好的

合理的把技术运用在工作中

我们在工作中逐渐对人的评价，会由评价其绝对的技术实力，转向评价其运用各方面技术解决实际问题的能力。这两者之间有一个比较形象的比喻，就好比我们学生时期背单词，拿出任何一个单词来，都能立刻说出它的含义、发音、常用短语、同义词、反义词、各种形态，但面对具体的对话场景不知道该用哪个词最合适最得体，这是比较典型的一种现象。其实前者就像是一个人的技术实力，后者就像是一个人的解决实际问题的能力。所以新知识新技术不光要学，还要学以致用，如何合理运用技术解决实际问题才是我们真正希望看到的。

把工作中的必经之路和常见任务萃取出来沉淀为最佳实践

现在回到“小而美的务实方案”这件事情上。我们认为看上去很重要、工作量很大、需要很多人来做的工作，是可以充分拥抱社区，汲取最好的技术，同时发挥关键角色的关键作用，并把技术合理运用在实际需求上。整件事情的成败有很多因素，但是“规模”这个因素显然不在考前的位置了

基于这样的思考，我觉得，自己喜欢的团队，是一个小而美的团队

Vue.js 1.0.0 发布了！

作为“打入敌人内部”的第一件事，转载一下 Vue.js 1.0.0 新世纪福音战士 (其实发这篇文章的时候已经 1.0.3 了) 正式发布的博文 ^_^

Vue.js

Hi HN (Hacker News)! 如果你还不熟悉 Vue.js 的话，可以通过这篇文章 (英文)对其有个总体印象。

在经历了 300+ 次提交、8 次 alpha、4 次 beta 和 2 次 rc 之后，今天我很荣幸的向大家宣布 Vue.js 1.0.0 Evangelion 正式发布了！非常感谢所有参与 API 重设计的同学们——没有来自社区的贡献这是不可能完成的。

阅读剩余部分...

[译]如何成为一名卓越的前端工程师

译自 Philip Walton 的博客

看过之后非常有感触，很多观点都是自己长期非常坚持和认同的，所以翻译出来分享给更多的前端同学！

最近我收到一封读者来信让我陷入了思考，信是这么写的：

Hi Philip，您是否介意我问您是如何成为一名卓越 (great) 的前端工程师的？对此您有什么建议吗？

我不得不承认，我很惊讶被问这样的问题，因为我从来不觉得自己是个很卓越的前端工程师。甚至我入行头几年时并不认为自己可以做好这一行。我只确定自己比自己想象中还才疏学浅，而且大家面试我的时候都不知道从何问起

话虽这么说，我到现在做得还算不错，而且成为了团队中有价值的一员。但我最终离开 (去寻求新的挑战——即我还不能够胜任的工作) 的时候，我经常会被要求招聘我的继任者。现在回看这些面试，我不禁感叹当我刚开始的时候自己在这方面的知识是多么的匮乏。我现在或许不会按照我自己的模型进行招聘，即便我个人的这种经历也有可能成功。

我在 web 领域工作越长时间，我就越意识到区分人才和顶尖人才的并不是他们的知识——而是他们思考问题的方式。很显然，知识在很多情况下是非常重要而且关键的——但是在一个快速发展的领域，你前进和获取知识的方式 (至少在相当长的一段时间里) 会比你已经掌握的知识显得更加重要。更重要的是：你是如何运用这些知识解决每天的问题的。

这里有许许多多的文章谈论你工作中需要的语言、框架、工具等等。我希望给一些不一样的建议。在这篇文章里，我想谈一谈一个前端工程师的心态，希望可以帮助大家找到通往卓越的道路。

阅读剩余部分...

手机淘宝前端的图片相关工作流程梳理

本文首发自阿里无线前端博客

注：本文摘自阿里内网的无线前端博客《无线前端的图片相关工作流程梳理》。其实是一个月前写的，鉴于团队在中国第二届 CSS Conf 上做了《手机淘宝 CSS 实践启示录》的分享，而图片工作流程梳理是其中的一个子话题，故在此一并分享出来，希望仍可以给大家一些经验和启发。另外，考虑到这是一篇公开分享，原版内容有部分删节和调整，里面有一些经验和产出是和我们的工作环境相关的，不完全具有普遍性，还请见谅。

今天很荣幸的跟大家分享一件事情，就是经过差不多半年多的努力，尤其是最近 2 周的“突击扫尾”，无线前端团队又在工具流程方面有了一个不小的突破：我们暂且称其为“图片工作流”梳理。

图片！图片！图片！

要说最近 1 年里，无线前端开发的一线同学最“难搞”的几件事，图片处理绝对可以排在前三。

首先，我们首先要从视觉稿 (绝大部分出自 photoshop) 里把图片合理的分解、测量、切割、导出——俗称“切图”
然后，我们要把切好的图放入页面代码中，完成相关的本地调试
第三步，把本地图片通过一个内部网站 (名叫 TPS) 上传到我们的图片 CDN 上，并复制图片的 CDN 地址，把本地调试用的相对路径替换掉
第四步，不同的图片、不同的外部环境下 (比如 3g 还是 wifi)，我们需要给图片不一样的尺寸、画质展现，并有一系列的配置需要遵循
如果视觉稿有更改 (不要小看这件事，微观上还是很频繁的哦)，不好意思，从第一步开始再重新走一遍……

这里面“难搞”在哪些地方呢？我们逐一分析一下：

“切图”的效率并不高，而且每一步都很容易出现返工或再沟通
打开 TPS 网站上传图片放到前端开发流程中并不是一个连贯流畅的步骤，而且 GUI 相比于命令行工具的缺陷在于无法和其它工具更好的集成
替换 CDN 图片路径的工作机械而繁琐，并且代码中替换后的图片地址失去了原本的可读性，非常容易造成后期的维护困惑甚至混乱
适配工作异常繁杂和辛苦，也很容易漏掉其中的某个环节
视觉变更的成本高，web 的快速响应的特点在丧失

所以可能把这些东西画成一张图表的话：

团队的单点突破

在最近半年的一段时间里，无线前端团队先后发起了下面几项工作，从某个点上尝试解决这些问题：

阅读剩余部分...

[译]如何让办公室政治最小化

来来来，看看办公室政治是个什么东西，以及如何将其最小化
翻译如有疏漏还请指正

译自：How to Minimize Politics in Your Company via www.bhorowitz.com

更新：跟身边一些朋友讨论之后，觉得之前翻译的标题“杜绝”言过了，还是规规矩矩翻译成了“最小化”

Who the f@#k you think you f$&kin’ with
I’m the f%*kin’ boss

—Rick Ross, Hustlin’

在我所有的从商经历中，我从没听过有人说：“我喜欢办公室政治”。但在我们的周围，令人深恶痛绝的政治又到处都是，甚至自己的公司就是如此。既然大家都不喜欢政治，那为什么它无处不在呢？

政治行为几乎都源自 CEO。也许你会觉得：“我讨厌政治，我也不关心政治，但是我的周围充满了政治气味。这显然不是我造成的。”很遗憾，你并不需要怎么关心政治就会让你的周围充斥政治手段。实际上，很少关心政治的 CEO 才会让办公室充斥政治手段。不关心政治的 CEO 们往往会直接助涨政治行为。

我这里说的政治，就是指员工追求自我职业发展多于价值产出和贡献。也许还有别样的政治类型，但是这类政治行为真的很烦。

阅读剩余部分...

Vue.js 源码学习笔记

最近饶有兴致的又把最新版 Vue.js 的源码学习了一下，觉得真心不错，个人觉得 Vue.js 的代码非常之优雅而且精辟，作者本身可能无 (bu) 意 (xie) 提及这些。那么，就让我来吧：）

程序结构梳理

Vue 程序结构

Vue.js 是一个非常典型的 MVVM 的程序结构，整个程序从最上层大概分为

全局设计：包括全局接口、默认选项等
vm 实例设计：包括接口设计 (vm 原型)、实例初始化过程设计 (vm 构造函数)

这里面大部分内容可以直接跟 Vue.js 的官方 API 参考文档对应起来，但文档里面没有且值得一提的是构造函数的设计，下面是我摘出的构造函数最核心的工作内容。

Vue 实例初始化

整个实例初始化的过程中，重中之重就是把数据 (Model) 和视图 (View) 建立起关联关系。Vue.js 和诸多 MVVM 的思路是类似的，主要做了三件事：

通过 observer 对 data 进行了监听，并且提供订阅某个数据项的变化的能力
把 template 解析成一段 document fragment，然后解析其中的 directive，得到每一个 directive 所依赖的数据项及其更新方法。比如 v-text="message" 被解析之后 (这里仅作示意，实际程序逻辑会更严谨而复杂)：
1. 所依赖的数据项 this.$data.message，以及
2. 相应的视图更新方法 node.textContent = this.$data.message
通过 watcher 把上述两部分结合起来，即把 directive 中的数据依赖订阅在对应数据的 observer 上，这样当数据变化的时候，就会触发 observer，进而触发相关依赖对应的视图更新方法，最后达到模板原本的关联效果。

所以整个 vm 的核心，就是如何实现 observer, directive (parser), watcher 这三样东西

阅读剩余部分...

从原型到发布——“团队时间线” 1.0 开发心得

这篇文章将会记录我自己最近一周时间里，从产生“团队时间线”这个想法，到产品设计、交互设计、开发、迭代、再到 1.0 发布的整个过程。整件事情跨越了多个分工职能，所以这件事情虽然并不大，但对我来说是一种不一样的做事方式和经历，所以觉得应该记录下来。

_2015_06_27_2_11_23

“团队时间线”是个可视化展示团队所有同学时间分配/管理的平台。每个人都可以在“我的时间管理”页面极简的记录自己的时间，比如从某天到另外一天做了一个项目、或者昨天开了一个重要的会等等。

阅读剩余部分...

Vue + webpack 项目实践

最近在内部项目中做了一些基于 vue + webpack 的尝试，在小范围和同事们探讨之后，还是蛮多同学认可和喜欢的，所以通过 blog 分享给更多人。

首先，我会先简单介绍一下 vue 和 webpack：

(当然如果你已经比较熟悉它们的话前两个部分可以直接跳过)

介绍 vue

_2015_06_25_12_37_36

Vue.js 是一款极简的 mvvm 框架，如果让我用一个词来形容它，就是 “轻·巧” 。如果用一句话来描述它，它能够集众多优秀逐流的前端框架之大成，但同时保持简单易用。废话不多说，来看几个例子：

<script src="vue.js"></script>

<div id="demo">
  {{message}}
  <input v-model="message">
</div>

<script>
  var vm = new Vue({
    el: '#demo',
    data: {
      message: 'Hello Vue.js!'
    }
  })
</script>

首先，代码分两部分，一部分是 html，同时也是视图模板，里面包含一个值为 message 的文本何一个相同值的输入框；另一部分是 script，它创建了一个 vm 对象，其中绑定的 dom 结点是 #demo，绑定的数据是 {message: 'Hello Vue.js'}，最终页面的显示效果就是一段 Hello Vue.js 文本加一个含相同文字的输入框，更关键的是，由于数据是双向绑定的，所以我们修改文本框内文本的同时，第一段文本和被绑定的数据的 message 字段的值都会同步更新——而这底层的复杂逻辑，Vue.js 已经全部帮你做好了。

_2015_06_24_11_00_20