务实的小而美

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

人不够?

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

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

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

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

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

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

从社区汲取最好的技术

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

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

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

有的时候觉得社区化的技术发展也有它残酷的一面,同类的方案或工具库基本上也就全球数一数二的几个能生存下来,并且体现出可观的价值,稍微差一点的,也许绝对实力没有差很多,但只要不是第一,所产生的价值和影响力就少得可怜了。所以想掂量掂量自己,看看是不是这块料,不妨放到社区里跟大家一起来一场真正的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 重设计的同学们——没有来自社区的贡献这是不可能完成的。

模板语法改进

1.0 的模板语法解决了很多微小的一致性问题,并使得 Vue 的模板更加简洁且易于阅读。最值得留意的新特性就是 v-onv-bind 的语法简写:

<!-- 简写版 v-bind:href -->
<a :href="someURL"></a>

<!-- 简写版 v-on:click -->
<button @click="onClick"></button>

当使用一个子组件的时候,v-on 用来监听自定义事件,v-bind 用来绑定属性 (props)。这些简写让子组件变得更易用:

<item-list
  :items="items"
  @ready="onItemsReady"
  @update="onItemsUpdate">
</item-list>

API 清理

Vue.js 1.0 的总体目标是使其适用于更大型的项目。这也是很多 API 被弃用的原因。在被弃用的 API 中,除了很少被用及之外,最常见的理由就是它会导致可维护性被破坏。特别是,我们弃用了难以维护的功能,并把组件提炼隔离开,使其不会对项目其它部分产生影响。

比如,在 0.12 中默认资源 (asset) 方案会隐性降级到组件树中的父级。这使得组件中的可用资源非常不确定,并且取决于在运行时的用法。在 1.0 中,所有的资源都基于严格模式进行解析,也没有了隐性降级。inherit 选项也被移除了,因为它很容易导致组件强耦合,无法提炼。

更快的初始化渲染

1.0 用 v-for 指令 (directive) 取代了 v-repeat。除了提供相同的功能和更直观的作用域之外,v-for 将初始化渲染大列表和大表格时的性能提升了 100%

更强大的工具

在 Vue.js core 之外,还有很多令人激动的东西:vue-loadervueify 的新升级,包括:

  • 组件热加载。当一个 *.vue 组件被编辑之后,其所有活跃实例都可以在页面不刷新的情况下完成热转换。这意味着你不需要重新加载 app 就可以完成诸如样式或模板的小调整;而 app 本身及其被转换的组件的状态可以被保留,这大大提升了开发体验。

  • 局部 CSS。通过在你的 *.vue 组件的 style 标签上简单加入一个 scoped 特性,该组件的模板和最终生成的 CSS 就会被奇妙的重写以保证组件的样式只被应用在其自身的元素上。最重要的是,父组件的特殊样式不会泄露到嵌套的子组件当中。

  • 默认支持 ES2015。JavaScript 一直在进化。你可以用最新的语法写出更简洁生动的代码。vue-loadervueify 现在会直接转换你的 *.vue 组件中的 JavaScript,无需额外的设置。今天,就来写未来的 JavaScript 吧!

结合 vue-router,Vue.js 现在不只是一个库了——它提供了一个构建复杂单页应用的稳固基础。

下一步?

如一般 1.0.0 所提倡的,核心 API 将会保持稳定服务于可预见的未来,库也做好了产品级别的准备。未来的开发会专注于:

  1. 改善 vue-loader 并使其做好产品级别的准备。

  2. 捋顺开发体验,比如更好的开发者工具和 Vue.js 项目/组件脚手架的 CLI。

  3. 提供更多诸如教程和示例的学习资料。

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

译自 Philip Walton 的博客

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


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

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

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

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

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

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

阅读剩余部分...

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

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

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

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

图片!图片!图片!

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

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

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

  1. “切图”的效率并不高,而且每一步都很容易出现返工或再沟通
  2. 打开 TPS 网站上传图片放到前端开发流程中并不是一个连贯流畅的步骤,而且 GUI 相比于命令行工具的缺陷在于无法和其它工具更好的集成
  3. 替换 CDN 图片路径的工作机械而繁琐,并且代码中替换后的图片地址失去了原本的可读性,非常容易造成后期的维护困惑甚至混乱
  4. 适配工作异常繁杂和辛苦,也很容易漏掉其中的某个环节
  5. 视觉变更的成本高,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 们往往会直接助涨政治行为。

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

阅读剩余部分...