热爱编程、足球和音乐的前端开发者，曾在傲游、淘宝和阿里云工作。
RSS 地址: https://jiongks.name/atom.xml
请复制 RSS 到你的阅读器，或快速订阅到 :
1970-01-01 08:00:00
本文是我在 VueConf 24 CN 的开场演讲稿，分享我和 Vue.js 的十年的故事。
文中截图来自我的幻灯片。另外我试着挑战了一下 Paper Mario 的主题风格，希望大家喜欢。
- VueConf 24 CN 官网：https://vueconf.cn/
- 在线幻灯片地址：https://jinjiang.dev/slides/my-10-years-with-vuejs/
- 演讲 B 站视频地址：https://www.bilibili.com/video/BV16W421R7ga/
一转眼，Vue.js 已经十周年了，这同时也几乎是我个人参与 Vue.js、参与开源项目的十年。
我和 Vue 缘分的开始应该是自己 2014 年在阿里内部创建的一个项目，名字如果没有记错的话叫 lib-noble。这个库算是一个 data observer 的 JavaScript 实现，后来我们管这种东西叫 reactivity API，再后来叫 signals。在我看来大同小异。写了这个库没多久，我就在 GitHub 上发现了 Vue.js，其中数据处理的相关设计和实现都跟我自己写的东西不谋而合。我当时的第一反应是，这个库比我写的好多了，而且还有很多其他功能，比如组件系统、模板编译等等。于是我就开始关注 Vue.js，并一路参与到了今天。
在这十年里，Vue.js 本身，包括团队，都经历了很多事情。我自己所经历的故事，已经出圈且被大家熟知或调侃的，也许就是自己在 Vue 的第一个 PR (只改了两个空格)、维护中文官网 (今年愚人节我们玩了个“威优易”的彩蛋)、创建了开源项目 Weex 并和 Vue 有一段时间的双向官方合作、以及在 Vue 的纪录片中出镜等等。相关的内容不打算赘述了。这次我主要想分享几则背后发生在 Vue 和我自己身上的小故事。尽可能还原一个更加立体的历经 10 年的开源项目。
1970-01-01 08:00:00
关注我的人可能已经知道我最近作为常驻嘉宾加入了一个叫做《代码之外 Beyond Code》的播客节目。
这里简单分享一些我参与《代码之外》的故事：
1970-01-01 08:00:00
(本文写于 2022 年 11 月)
大约一周之前，我突然接到父母亲的消息，说九十多岁高龄的奶奶身体突然变得非常不好，感觉很难坚持了，虽然立刻飞回去不太现实，但还是希望可以安排个远程视频，见一面。
我非常清楚这意味着什么，这一面就是最后一面了。
隔天早上，我们安排了视频见面。我们上一次见面也是视频见面，当时我们还能相互交谈个几句。这一次，奶奶的身体靠在家人身旁勉强可以坐起来，除了睁大眼睛看着屏幕对面的我，已经动弹不得，也说不出话了。我不确定她还能不能听到我说话，总之我努力说了很多。那一刻，自己心里特别难受——一是不愿看到这一幕，二是悔自己没有办法来得及回去亲自看看或身体力行帮着做点什么。
除了伤感，我决定写一点关于我奶奶的东西，让更多人认识和记住她。
1970-01-01 08:00:00
介绍要给小工具给大家：zhlint
这个工具可以帮助你快速格式化中文或中英混排的文本。比如常见的中英文之间要不要用空格、标点符号要用全角字符之类的。
看上去这工具似乎和自己的工作和职业关系不大，但其实也是有一定由来的。
1970-01-01 08:00:00
为大家介绍一个刚刚开源，但其实自己已经使用超过 5 年的小工具：vue-mark-display。你可以用它把 markdown 格式的文本转换成幻灯片并在浏览器中播放和控制。
我自己工作中经常需要准备各式各样的幻灯片，所以逐渐觉得用 PowerPoint 或 Keynote 来做幻灯演示略微显得有些笨重。这体现在板式和样式设计、文件大小、打开、编辑和播放的方式等很多方面。加上我从事的就是前端开发的工作，对语义化的信息格式非常敏感，深刻的认为，那些你表面上想编辑的“样式”其实是信息的“类型”+“配套的样式”罢了。所以决定用 markdown 外加自己扩展的一些小功能，来撰写幻灯片，并研发了相应的工具，也就是最近开源的 vue-mark-display。
最早这个工具是用 vue v0.10 写的，当时源代码里还有像 v-attr, v-repeat, v-transition 这样的“古董级”语法，而且还在依赖 Zepto。最近准备开源这个项目的时候，我也基于最新的前端知识和技能进行了重构。所以大家看到的是比较新的版本。
其实在此之前，我也写过很多类似的小工具了，但都没有坚持使用很久，这次开源的 vue-mark-display 我差不多持续使用了 5 年。经历了差不多这 5 年时间，准备过了无数的幻灯片和公开演讲，我想说基于 markdown 以及这些小功能撰写幻灯片真的很酷。如果你也有兴趣试一试用 markdown 为主体来撰写自己的幻灯片，那么不妨了解并体验一下 vue-mark-display。
另外，事实上，如果只是想使用它，你是不需要学习任何关于 Vue 的知识的 —— 文章最后会提供一个不需要 Vue 知识的开箱即用的办法 —— 所以它也对 React、Angular 等社区的同学友好 —— 只要你会写 markdown 和简单的 HTML5 代码，你就可以使用 vue-mark-display 制作出非常精美的幻灯片。
1970-01-01 08:00:00
如题，今年陆续参加了一些技术会议，有些新的感触，尤其是今年第一次尝试多参加了一些境外的会议，有在 HK 的，有在 TW 的，有在 JP 的，感受很不一样，当然也参加了年初的厦门 CSSConfCN 和刚结束的 VueConfCN。另外网上越来越多人在讨论或是质疑参加技术会议到底有什么意义、好的技术会议应该是什么样子的，我也以写这篇博客的方式参与一下。
1970-01-01 08:00:00
上周末作为一名分享者参加了 CSSConf CN，在厦门。
其实除了自己的分享内容，这次我是带着很明确的目的参会的，因为有两个主题我特别关注，就是：
(两个分享的标题都被我稍微“演绎”了一下)
这两件事都是自己工作上正在特别关注的事情，一方面，我们很少从 API 的角度去理解一个组件的 CSS 该如何组织和管理，所以这个标题就特别吸引我，另一方面响应式组件的分享者是来自新加坡的前端工程师 Zell (我个人一直觉得国内的响应式都是在瞎搞，看了很多周围团队都没有认真做这件事，甚至不相信响应式的价值，从设计师到工程师)，因此非常珍惜这个机会能近距离学习一些国外的同行们是怎么看待和实践响应式的。
所以尽管我们团队的差旅经费已经用完了，还是决定自费来厦门近距离交流一下。
现在证明这次真的不虚此行。
当然参加这种线下活动，“面基”的目的是一定有的……恩，这个不值一提。
1970-01-01 08:00:00
译自：https://blog.prototypr.io/the-future-of-web-forms-4578485e1461 Matt West 的 The Future of Web Forms
license: CC BY-SA 4.0
如何通过会话式的界面让数据收集更加人性化。
Web 表单是从纸质媒介进化而来的。即设计一组标签和线框来限制输入，同时让数据处理变得跟容易。
毕竟，表单的目的是收集数据，以便执行操作。为了执行该操作，我们需要把收集的数据统一汇总。我们在界面上设计了一些约束以便达到统一汇总的目的。表单旨在符合流程上的需求，而非用户本身。
表单经常给人的感觉是冷冰冰的，没有人情味。因此，我们得到的回应往往也是冷酷和不人性的。我们不深入细节，如果一个朋友问你相同的问题，你可能会多一些回复，但这是一台电脑。他想要的只是数据，别的不在乎。就好像你在跟人说话但是人家并没有在听。为什么没人听的话说出来会让人觉得烦呢？
Image by Ken Teegardin.
和许多数字化的东西一样，表单已经被之前的形态严重影响。我们之所以往线框里填东西是因为我们以前在纸上就是这么画的。
1970-01-01 08:00:00
Jul 29, 2017
作者 Anil Dash 是 Fog Creek Software 的 CEO，致力于让科技变得更人性和道德一些，同时他也是 Medium 的顾问。
苹果在 Apple Park 这个漂亮的新办公楼上花了 50 亿美金，却犯了一个完全可以避免的极其昂贵的错误：让他们的程序员工作在一个开放式的格局中。这真让人惊讶。
我在 Fog Creek Software 工作，我们的联合创始人兼前 CEO Joel Spolsky 在至少 17 年前就已经针对开放式办公室对于程序员产能的糟糕影响撰文了。他在这方面的洞察基于了 Tom DeMarco 和 Tim Lister 的经典书籍《Peopleware》——该书已经出版了三十年。所以这其实不是什么全新的观点。当然在这数十年里，也已经有无数的学术研究确认了同一个结论：人们在开放式空间办公是烦躁的、注意力不集中的、常常不开心的。
这不是说开放式办公环境一无是处——它能够营造很好的协作和联络的氛围。对于市场或销售团队来说，共享空间是非常有意义的。但是对于需要身处某种工作流状态的任务来说呢？这个问题从科学的角度是有定论的。
那就是把门关上。
1970-01-01 08:00:00
译自：http://thecodist.com/article/why_i_don_39_t_do_unpaid_overtime_and_neither_should_you
原文写于 2012 年，至今已经有一段时间了，前段时间这篇文章又被大家翻出来热烈讨论，看过之后有些感触，所以翻译了一下
我是一个在美国待了 30 年的程序员，我有过一周工作超过 40 小时的经历，这在行业里面并不常见，但是我[很难][rarely]因此而得到更多的薪水。
总之，我现在发现整个做法[很恶心][nauseating]。
我并不是针对自营或创业等多干活儿就能得到更多回报的情况。我曾经在 80 年代中期到 90 年代开过两个小的软件公司，并且工作时间也很长，但是我们会共享全部的成果，而第二家公司我们在合同里就定好了多劳多得的规矩。当然这不是我们今天讨论的重点。
如果我为一家大公司工作并且谈好了薪水，那我的预期就是我在标准的时间内，即公认的 (至少在美国) 一天 8 小时一周 5 天，尽我所能完成工作。如果他们希望我每周工作 70 个小时或有些主管期望团队每天都来上班，现在的我是会拒绝的。为什么呢？
当我们决定工作赚钱的时候，我们假定工作的主要原因是为了换取我们生活所需的开销。雇员的预期是他们会获得等价于这笔薪水的产出。但问题在于，雇主概念中的价值经常和雇员的不一样，尤其在美国和亚洲。许多公司期望薪水是固定的，但是他们创造这些价值需要完成的工作是不确定的。雇主觉得只要提高对雇员的预期和要求，就能够获得更大的回报，这样他们就可以通过为每份薪水延长工作时间来降低实质的劳动成本。
这对于雇员来说意味着什么？如果你同意了，那么你实际上就认同了自己的工作更廉价。甚至这种工作其实就是无偿的。那么作为雇员你在这样的无偿工作中收获了什么呢？在绝大多数雇主面前，你什么也没有得到。如果你是一个主管，也许会得到晋升，但是作为程序员你职业发展的道路不只是做管理这一条。如果你连续几个月每周编码超过 80 个小时，通常情况下得到的回报和一周努力工作 40 小时差不多。
1970-01-01 08:00:00
1970-01-01 08:00:00
译自：https://moz.com/rand/if-management-is-the-only-way-up-were-all-fd/
注：作者 Rand 是 Moz 的 CEO，文中反复出现两个词：IC (Individual Contributor) 和 PW (People Wrangler)，分别翻译成了一线员工和经理人。
Geraldine 很喜欢她曾经在 Cranium 的工作 (西雅图的[桌游][board game]初创公司，在 Hasbro 收购他们并[裁员][layoffs][之前][prior])。她为桌游撰写问题，并为包装盒和营销材料撰写[文案][copy]。她很擅长这个。但是发生了一些奇怪的事情——他们想让她晋升。我记得她晚上回家后[非常的][endlessly][苦恼][fretting]。她不想让人们向她汇报。她不想在团队中拥有更大的责任。她只想写写东西。
这很奇怪。当我们审视一家公司的结构时，很容易发现团队需要很多高质量的一线员工 (IC) 以及少数高质量的[经理人][wranglers]。然而我们的[公司][corporate]文化和这个世界的“模式”已经让我觉得除非你要带人，否则你的影响力、薪水、利益、职位和自我价值都不会增长。
[这都什么乱七八糟的。][im calling bs]
我过去写过关于多样化成长轨迹的重要性——一线员工和经理人——但是我们最近在 Moz 花了大量的时间碰撞想法，很快会实施一个新的职位/团队的结构，最终付诸实践，我对此充满期待。
现在我会为一个在其工作岗位上做的很优秀的一线员工表达对管理的兴趣而担心。我担心这种渴望的很[重要的][significant][一部分][portion]不源自真正的管理责任感，而是因为他们想要在职业生涯和/或影响力上得到提高，并且认为这是唯一的办法。
我画了这张图来辅助[说明][illustrate]两种角色之间的不同：
(大图)
1970-01-01 08:00:00
译自：https://chris.beams.io/posts/git-commit/
如果你浏览任何 Git 仓库的日志，你可能会发现那些提交信息多少有些[混乱][mess]。比如，看看这些我早年提交给 Spring 的精品：
$ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009"
e5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle downstream effects, breaking unrelated tests. The test method is still useful, but should only be run on a manual basis to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build.
2db0f12 fixed two build-breaking issues: + reverted ClassMetadataReadingVisitor to revision 794 + eliminated ConfigurationPostProcessorTests until further investigation determines why it causes downstream tests to fail (such as the seemingly unrelated ClassPathXmlApplicationContextTests)
147709f Tweaks to package-info.java files
22b25e0 Consolidated Util and MutableAnnotationUtils classes into existing AsmUtils
7f96f57 polishing
[呀][Yikes]，比较一下这个仓库最近的提交：
$ git log --oneline -5 --author pwebb --before "Sat Aug 30 2014"
5ba3db6 Fix failing CompositePropertySourceTests
84564a0 Rework @PropertySource early parsing logic
e142fd1 Add tests for ImportSelector meta-data
887815f Update docbook dependency and generate epub
ac8326d Polish mockito usage
你更喜欢读哪个呢？
1970-01-01 08:00:00
译自：Principles for C programming
按照 Doug Gwyn 的话说：“Unix 不会阻止你做愚蠢的事情，因为那会同样阻止你做聪明的事情”。C 是一个非常强大的工具，但使用它的时候需要非常小心和[自律][discipline]。学习这些纪律是绝对值得的，因为 C 是所有程序语言中最优秀的。一个自律的 C 程序员将会……
1970-01-01 08:00:00
终于发布了！
原文：https://medium.com/the-vue-point/vue-2-0-is-here-ef1f26acf4b8#.6r9xjmu6x
今天我非常兴奋的官宣 Vue.js 2.0 的发布：Ghost in the Shell。历经 8 个 alpha 版本、8 个 beta 版本和 8 个 rc 版本 (矮油好巧！)，Vue.js 2.0 已经为生产环境准备好了！我们的官方教程 vuejs.org/guide 也已经全面更新。
2.0 的工作自今年 4 月启动以来，核心团队为 API 设计、bugfix、文档、类型声明做出了很重要的贡献，社区中的同学们也反馈了很多有价值的 API 建议——在此为每一位参与者致以大大的感谢！
1970-01-01 08:00:00
本文早些时候发表在 weexteam 的博客 https://github.com/weexteam/article/issues/73
仅从我个人角度跟大家分享一下自己参与 Weex 开源这几个月以来的感受，中间可能会有写观点是偏颇的或者片面的，希望大家指正，另外不论怎样，这些都是我心里真实的想法和感受。
1970-01-01 08:00:00
本文早些时候发表在 weexteam 的博客 https://github.com/weexteam/article/issues/71
Weex 的技术架构和传统的客户端渲染机制相比有一个显著的差别，就是引入了 JavaScript，通过 JS Runtime 完成一些动态性的运算，再把运算结果和外界进行通信，完成界面渲染等相关操作指令。而客户端面对多个甚至可能同时共存的 Weex 页面时，并没有为每个 Weex 页面提供各自独立的 JS Runtime，相反我们只有一个 JS Runtime，这意味着所有的 Weex 页面共享同一份 JS Runtime，共用全局环境、变量、内存、和外界通信的接口等等。这篇文章会循序渐进的介绍 Weex JS Runtime 这部分的内容，大概的章节设计是这样的：
1970-01-01 08:00:00
如题，SPA (Single Page Application - 单页应用) 这个话题已经在 Weex 社区讨论了有一段时间，在传统的前端开发领域中大家也在长期探讨这个话题。这里谈谈我个人的理解和看法。
SPA 往往和 Router、页面间通信、页面间数据共享这些词汇联系在一起，不少同学直接问到这些词汇，实际上都是以 SPA 为前提的，因为脱离 SPA 的概念，这些词汇将失去它原有的意义，或者变成了完全不同的东西。
那 SPA 不是理所当然、天经地义、不容挑战的吗？干嘛要脱离 SPA 的概念讨论这些问题？
我觉得不是
SPA 背后的命题是如何管理复杂的页面关系，最终构成一个产品的整体。传统的页面之间是通过简单粗暴的“页面跳转”和“浏览器前进/后退”建立联系的，SPA 提出的观念是在浏览器中模拟页面的跳转、切换和前进/后退，相关的很多周边命题也随之而生。
(其实你不觉得这也是个"全家桶"么……)
所以我们先把问题回归到如何管理复杂的页面关系
1970-01-01 08:00:00
本文早些时候发表在 云栖社区 https://yq.aliyun.com/articles/59357
之前 review 业务代码的时候就一直想说写一篇自己对 Flux 的理解和看法，不知不觉也过去蛮久了，于是这周末打起精神写了这么一篇。
这篇文章将谈一些我对 Flux 的理解和个人看法。如果您还不太了解什么是 Flux，请先移步这里。
另外文中没有特别大段的代码，以讨论架构设计和背后的道理为主，可能会显得有点枯燥，大家可以选个不太困的时候耐心读读看：）
这是 Flux 官方提供的一张说明图：
图中有四个名词：
下面逐个以我的角度做个讲解：
1970-01-01 08:00:00
主要内容来自 https://github.com/vuejs/vue/releases
之前 Vue 2.0 发布技术预览版 到现在差不多三个月了，之前写过一篇简单的 code review，如今三个月过去了，Vue 2.0 在这个基础之上又带来了不少更新，这里汇总 beta 以来 (最新的版本是 beta 4) 的主要更新，大家随意学习感受一下
首先 Vue 2.0 对 alpha、beta 有自己的理解和设定：alpha 版本旨在完善 API、考虑所需的特性；而来到 beta 版则会对未来的正式发布进行充分的“消化”，比如提前进行一些必要的 breaking change，增强框架的稳定性、完善文档和周边工具 (如 vue-router 2.0 等)
Vue 本身的语法基础这里就不多赘述了，网上有很多资料可以查阅，我们已经假定你比较熟悉 Vue 并对 2.0 的理念和技术预览版的状态有一定的了解。
1970-01-01 08:00:00
1970-01-01 08:00:00
是的！Vue 2.0 发布了！ 源代码仓库在此
首先，当我第一次看到 Vue 2.0 的真面目的时候，我的内心是非常激动的
来个简单的 demo，首先把 dist/vue.js 导入到一个空白的网页里，然后写：
当然，在大家阅读下面所有的内容之前，先想象一下，这是一个运行时 min+gzip 后只有 12kb 大小的库
<script src="./dist/vue.js"></script>
<div id="app">
Hello {{who}}
</div>
<script>
new Vue({
el: '#app',
data: {who: 'Vue'}
})
</script>
你将看到 "Hello Vue"
然后再看一个神奇的：
<script src="./dist/vue.js"></script>
<div id="app"></div>
<script>
new Vue({
el: '#app',
render: function () {
with (this) {
__h__('div',
{staticAttrs:{"id":"app"}},
[("\n Hello "+__toString__(who)+"\n")],
''
)
}
}
data: {who: 'Vue'}
})
</script>
这个是 compile 过后的格式，大家会发现首先 #app 下不需要写模板了，然后 <script> 里多了一个 render 字段，Vue 在运行时其实是会把模板内容先转换成渲染方法存入 render 字段，然后再执行，如果发现 render 已经存在，就跳过模板解析过程直接渲染。所以在 Vue 2.0 中写一段模板和写一个 render option 是等价的。为什么要这样设计，稍后会我们会涉及到。
1970-01-01 08:00:00
原文：https://medium.com/the-vue-point/announcing-vue-js-2-0-8af1bde7ab9#.cyoou0ivk
今天我们非常激动的首发 Vue 2.0 preview 版本，这个版本带来了很多激动人心的改进和新特性。我们来看看这里面都有些什么！
1970-01-01 08:00:00
1970-01-01 08:00:00
作为“打入敌人内部”的第一件事，转载一下 Vue.js 1.0.0 新世纪福音战士 (其实发这篇文章的时候已经 1.0.3 了) 正式发布的博文 ^_^
Hi HN (Hacker News)! 如果你还不熟悉 Vue.js 的话，可以通过这篇文章 (英文)对其有个总体印象。
在经历了 300+ 次提交、8 次 alpha、4 次 beta 和 2 次 rc 之后，今天我很荣幸的向大家宣布 Vue.js 1.0.0 Evangelion 正式发布了！非常感谢所有参与 API 重设计的同学们——没有来自社区的贡献这是不可能完成的。
1970-01-01 08:00:00
看过之后非常有感触，很多观点都是自己长期非常坚持和认同的，所以翻译出来分享给更多的前端同学！
最近我收到一封读者来信让我陷入了思考，信是这么写的：
Hi Philip，您是否介意我问您是如何成为一名卓越 (great) 的前端工程师的？对此您有什么建议吗？
我不得不承认，我很惊讶被问这样的问题，因为我从来不觉得自己是个很卓越的前端工程师。甚至我入行头几年时并不认为自己可以做好这一行。我只确定自己比自己想象中还才疏学浅，而且大家面试我的时候都不知道从何问起
话虽这么说，我到现在做得还算不错，而且成为了团队中有价值的一员。但我最终离开 (去寻求新的挑战——即我还不能够胜任的工作) 的时候，我经常会被要求招聘我的继任者。现在回看这些面试，我不禁感叹当我刚开始的时候自己在这方面的知识是多么的匮乏。我现在或许不会按照我自己的模型进行招聘，即便我个人的这种经历也有可能成功。
我在 web 领域工作越长时间，我就越意识到区分人才和顶尖人才的并不是他们的知识——而是他们思考问题的方式。很显然，知识在很多情况下是非常重要而且关键的——但是在一个快速发展的领域，你前进和获取知识的方式 (至少在相当长的一段时间里) 会比你已经掌握的知识显得更加重要。更重要的是：你是如何运用这些知识解决每天的问题的。
这里有许许多多的文章谈论你工作中需要的语言、框架、工具等等。我希望给一些不一样的建议。在这篇文章里，我想谈一谈一个前端工程师的心态，希望可以帮助大家找到通往卓越的道路。
1970-01-01 08:00:00
本文首发自阿里无线前端博客
注：本文摘自阿里内网的无线前端博客《无线前端的图片相关工作流程梳理》。其实是一个月前写的，鉴于团队在中国第二届 CSS Conf 上做了《手机淘宝 CSS 实践启示录》的分享，而图片工作流程梳理是其中的一个子话题，故在此一并分享出来，希望仍可以给大家一些经验和启发。另外，考虑到这是一篇公开分享，原版内容有部分删节和调整，里面有一些经验和产出是和我们的工作环境相关的，不完全具有普遍性，还请见谅。
今天很荣幸的跟大家分享一件事情，就是经过差不多半年多的努力，尤其是最近 2 周的“突击扫尾”，无线前端团队又在工具流程方面有了一个不小的突破：我们暂且称其为“图片工作流”梳理。
要说最近 1 年里，无线前端开发的一线同学最“难搞”的几件事，图片处理绝对可以排在前三。
这里面“难搞”在哪些地方呢？我们逐一分析一下：
所以可能把这些东西画成一张图表的话：
在最近半年的一段时间里，无线前端团队先后发起了下面几项工作，从某个点上尝试解决这些问题：
1970-01-01 08:00:00
来来来，看看办公室政治是个什么东西，以及如何将其最小化
翻译如有疏漏还请指正
译自：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 们往往会直接助涨政治行为。
我这里说的政治，就是指员工追求自我职业发展多于价值产出和贡献。也许还有别样的政治类型，但是这类政治行为真的很烦。
1970-01-01 08:00:00
最近饶有兴致的又把最新版 Vue.js 的源码学习了一下，觉得真心不错，个人觉得 Vue.js 的代码非常之优雅而且精辟，作者本身可能无 (bu) 意 (xie) 提及这些。那么，就让我来吧：）
Vue.js 是一个非常典型的 MVVM 的程序结构，整个程序从最上层大概分为
这里面大部分内容可以直接跟 Vue.js 的官方 API 参考文档对应起来，但文档里面没有且值得一提的是构造函数的设计，下面是我摘出的构造函数最核心的工作内容。
整个实例初始化的过程中，重中之重就是把数据 (Model) 和视图 (View) 建立起关联关系。Vue.js 和诸多 MVVM 的思路是类似的，主要做了三件事：
v-text="message" 被解析之后 (这里仅作示意，实际程序逻辑会更严谨而复杂)：
this.$data.message，以及node.textContent = this.$data.message所以整个 vm 的核心，就是如何实现 observer, directive (parser), watcher 这三样东西
1970-01-01 08:00:00
这篇文章将会记录我自己最近一周时间里，从产生“团队时间线”这个想法，到产品设计、交互设计、开发、迭代、再到 1.0 发布的整个过程。整件事情跨越了多个分工职能，所以这件事情虽然并不大，但对我来说是一种不一样的做事方式和经历，所以觉得应该记录下来。
“团队时间线”是个可视化展示团队所有同学时间分配/管理的平台。每个人都可以在“我的时间管理”页面极简的记录自己的时间，比如从某天到另外一天做了一个项目、或者昨天开了一个重要的会等等。
1970-01-01 08:00:00
最近在内部项目中做了一些基于 vue + webpack 的尝试，在小范围和同事们探讨之后，还是蛮多同学认可和喜欢的，所以通过 blog 分享给更多人。
首先，我会先简单介绍一下 vue 和 webpack：
(当然如果你已经比较熟悉它们的话前两个部分可以直接跳过)
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 已经全部帮你做好了。
1970-01-01 08:00:00
晒一下自己用 Koa next generation web framework for node.js 写的一个 web 服务
这个 web 服务主要是做内容的列表展示和搜索的 (可能说得比较抽象，但确实是 web 服务最常需要做的事情) 主要的文件一共就2个：
app.js 主程序lib/model.js 数据层其中 model.js 是和具体业务逻辑相关的，就不多介绍了，这也不是 Koa 的核心；而 app.js 的代码可以体现 Koa 的很多优点，也使得代码可以写得非常简练而去清晰——这是我自己都完全没有想到的事情
1970-01-01 08:00:00
话说上周末看到一个吐槽腾讯“内部开源”的微博，后来我想了想，自己那么骚包的在项目还没做完之前，就在 CSSConf 上说我们将来要开源一个名叫 Zorro 的库。结果好几个月过去了还是没有准备好，也就不敢再笑话别人了……
我觉得把东西开源出来之前，有几件事要准备好，不然除了自己刷存在感之外，真的没意义。比如：
印象中我见到的优秀的开源项目，基本都在被大家广泛认识之前，都已经把这些事情打理好了——这也是我一直推崇的。
好吧很惭愧，这几点我还都没有做到……
不过在这之前，我愿意在此分享一些自己开发中的心得，跟大家一起探讨相关的话题。
-- 以上是一些比较啰嗦的铺陈 --
在开发大型应用的时候，难免要用到一些组件化的分解方式。比如：把一个相册浏览界面分解成：“相册列表”和“大图预览”两个区域，“相册列表”又由一个个“相册缩略图”组成，每个“相册缩略图”包含了一个“小图片”以及“预览按钮”、“删除按钮”、“排序按钮”等操作按钮……
而如何管理和划分组件逐渐变成了前端工程里的一门学问。
1970-01-01 08:00:00
1970-01-01 08:00:00
2 年前曾经也发过几张自己拍的照片，似乎大家对于我的拍照技术还是蛮宽容的。下面几张同样是我认真挑选过的这 2 年来拍的，同样求轻拍 ^_^
p.s. 这 2 年真的经历了不少事情
港版风景
1970-01-01 08:00:00
译自：Naming CSS Stuff Is Really Hard
找到的这篇文章算是对我之前写的 《标签？ID？还是CLASS？》 的再深入。我当时写那篇文章的时候，就有朋友提出了“非语义化”的 class 命名的问题，我当时确实觉得很纠结，简单的想法是“框架性质的表象 class 我没异议……框架的实质是通过降低灵活性达成更广泛的共识，我们个人不要再创造这样的样式就好了”，但没有想到特别好的“套路”，更多的是在实际情况中再分辨。看过这篇文章，我似乎找到了更好的答案。同时顺着文中提到的 Nicolas 那篇文章看下去，也对 OOCSS、BEM 之类的提法有了更多的认同感。特译给大家参考。
1970-01-01 08:00:00
译自：A successful Git branching model» nvie.com
本文将展示我一年前在自己的项目中成功运用的开发模型。我一直打算把这些东西写出来，但总是没有抽出时间，现在终于写好了。这里介绍的不是任何项目的细节，而是有关分支的策略以及对发布的管理。
在我的演示中，所有的操作都是通过 git 完成的。
1970-01-01 08:00:00
译自：Writing Testable JavaScript - A List Apart
这篇文章算是 A List Apart 系列文章中，包括滑动门在内，令我印象最深刻的文章之一。最近有时间翻译了一下，分享给更多人，希望对大家有所帮助！
我们已经面对到了这一窘境：一开始我们写的 JavaScript 只有区区几行代码，但是它的代码量一直在增长，我们不断的加参数、加条件。最后，粗 bug 了…… 我们才不得不收拾这个烂摊子。
如上所述，今天的客户端代码确实承载了更多的责任，浏览器里的整个应用都越变越复杂。我们发现两个明显的趋势：1、我们没法通过单纯的鼠标定位和点击来检验代码是否正常工作，自动化的测试才会真正让我们放心；2、我们也许应该在撰写代码的时候就考虑到，让它变得可测试。
神马？我们需要改变自己的编码方式？是的。因为即使我们意识到自动化测试的好，大部分人可能只是写写集成测试(integration tests)罢了。集成测试的侧重点是让整个系统的每一部分和谐共存，但是这并没有告诉我们每个独立的功能单元运转起来是否都和我们预期的一样。
这就是为什么我们要引入单元测试。我们已经准备好经历一段痛苦的撰写单元测试的过程了，但最终我们能够撰写可测试的 JavaScript。
1970-01-01 08:00:00
译自：语义化版本管理 2.0.0
对于一个给定的版本号 MAJOR.MINOR.PATCH (主、次、补丁)，其变化的规律是：
我们还可以根据预发布、构建元数据 (build metadata) 的实际需求，在 MAJOR.MINOR.PATCH 格式之上扩展出额外的标记。
在软件管理领域，存在一个叫做“dependency hell (依赖地狱)”的坑。随着系统越变越大，你集成了越多的软件包，也越发觉得，有一天，你会陷入绝望。
对于有很多依赖关系的系统来说，发布新版本的软件包会迅速变成一场噩梦。如果依赖性规定得太紧，你会陷入 version lock (版本锁，即每次软件包的升级无法产生新的版本)。如果依赖性规定得太松，你会不可避免的面对 version promiscuity (版本泛滥，假设未来版本是需要考虑兼容性的)。当 version lock 和 version promiscuity 让你的项目无法安全而又轻松的向前推进时，这就是所谓的 dependency hell。
作为一种解决问题的办法，我提出了一套简单的规则和要求来表明版本号该如何确定和增加。这套规则基于但不仅限用于已经广泛存在的开源闭源软件的一般实践。为了让这个系统工作起来，你首先需要声明一个公有的 API，它可以由文档组成或在代码层面强制实现，且必须是清晰准确的。一旦你标识了你的公有 API，你就可以通过不同的版本号的增加来交流 API 的各种改变。设想一个形如 X.Y.Z 的版本，不影响 API 的 bug 修复会增大补丁版本，向下兼容的 API 增加或改变会增大次版本，而不兼容的 API 改变会增大主版本。
我把这套系统称作“语义化版本管理”。在这套系统之下，版本号及其改变传递了代码背后的含义，以及每个相邻版本之间的变化。
1970-01-01 08:00:00
译自：Adjusting Image Brightness and Color Using the HTML5 Canvas API
你曾否需要调节一张图片的亮度？或者增强红色通道让它变得温暖一些？
这是我之前两篇文章“如何通过HTML5 Canvas处理图片酷效”和“如何创建一个HTML5的大头贴应用”的后续。在之前的那些文章里，我提供了一些可分离的颜色滤镜代码：灰度、灰褐色、红色、变亮、变暗等。这些滤镜都是经典的颜色滤镜，每个像素点的颜色都是独立运算的，互不影响。我们的可以将其建模成一个单独数据驱动的称为颜色矩阵滤镜(Color Matrix Filter)的东西。这一概念将会遍布本文。这种滤镜将会以一个包含权重(即系数)的颜色矩阵作为输入，并决定输出的颜色组件(color component)如何和输入的颜色组建相对应。
1970-01-01 08:00:00
译自：Performance Tips for JavaScript in V8
关于如何巧妙提高V8 JavaScript性能的话题，Daniel Clifford在Google I/O上做了一次非常精彩的分享。Daniel鼓励我们“追求更快”，认真的分析C++和JavaScript之间的性能差距，根据JavaScript的工作原理撰写代码。在Daniel的分享中，有一个核心要点的归纳，我们也会根据性能指导的变化保持对这篇文章的更新。
最重要的是要把任何性能建议放在特定的情境当中。性能建议是附加的东西，有时一开始就特别注意深层的建议反而会对我们造成干扰。你需要从一个综合的角度看待你的Web应用的性能——在关注这些性能建议之前，你应该找PageSpeed之类的工具大概分析一下你的代码，也算是跑个分先。这会防止你过度优化。
对Web应用的性能优化，几个原则性的建议是：
为了完成这几个步骤，理解V8如何优化JS是一件很重要的事情，这样你就可以根据其对JS运行时的设计撰写代码。同样重要的是掌握一些帮得上忙的工具。Daniel也交代了一些开发者工具的用法，它们刚好抓住了一些V8引擎设计上最重要的部分。
OK。开始V8小贴士。
1970-01-01 08:00:00
译自：https://www.html5rocks.com/en/tutorials/speed/parallax/
现在满大街都是视觉差(parallax)网站了，我们随便看几个：
也许你对这玩意儿还不太熟，视觉差其实就是它的视觉结构会随着页面的滚动而变化。通常情况下页面里的元素会根据页面的滚动位置而缩放、旋转或移动。
我们的视觉差demo的完整效果
不管你喜不喜欢视觉差网站，有一件事毫无疑问，它是一个性能的黑洞。因为当页面滚动时，浏览器的优化都倾向于新内容随滚动而出现于屏幕的最上方或最下方的情况。一般来说，内容改变得越少浏览器性能越高。而对于一个视觉差网站来说，在页面滚动时，好多元素都在发生改变，大多数情况下整个页面的大块可视元素都在发生变化，所以浏览器不得不重绘整个页面。
我们有理由这样归纳一个视觉差的网站：
建议大家先阅读我们之前介绍过的滚动性能来改进你的app的响应速度。本篇文章是基于那篇文章所写的。
所以文字是如果你在建立一个视觉差网站，那么你是否受困于高昂的重绘开销？有没有别的改进建议使得性能最大化？让我们看看这几个方案：
1970-01-01 08:00:00
摘自：Chrome DevTools Revolutions 2013
本次开发者工具的改进中有几项新特性是针对性能的：
1970-01-01 08:00:00
1970-01-01 08:00:00
今年，在老罗锤子手机一路跳票、累不死手机活蹦乱跳、魅族手机版本号即将输给小米、iOS被拍扁、Windows Phone在卖萌、安卓在卖身等诸多鸟事相继雷到众生之后，人们无不感叹，手机这个行业还有救吗？站在智能和愚蠢的十字路口，我们该何去何从？囧rz
就在大家迷茫之时，Nokia发布了它的又一力作——1050！整个业界犹如刮来了一股春风，无不感到清新舒畅。大家纷纷感叹，那个曾经的科技巨人就要王者归来鸟！这个夏天，This summer，最受瞩目的大事件，big event！就是：
Nokia 1050 的发布！！！
作为一个反智能化手机操作系统的支持者，我很自豪的宣布，经历了前两轮的预定失败之后，我终于在上周成功订到了这款神机——要不要卖得这么好啊 - -
我之前用的手机是Nokia 1202，2008年的神机，其实也不算太老，要不是1050发布，它也其实已经是一个非常现代化、非常新款的愚蠢手机了，无奈在这个1050的时代趋势下也不得不接受停产的命运。
1050基本上继承了1202所有的成员函数和成员变量，小巧大方，简单易用，低碳环保，超长待机，便宜实惠，这已经足以吊起广大消费者的胃口了。然而真正的1050到底表现如何？它能否在1202的光环之下更进一步再创辉煌？带着这些疑问，记者走访了不少xxx，挖掘出了很多珍贵的xxxx，也听到了各种xxxxxxxx……
OK 马上开始
1970-01-01 08:00:00
1970-01-01 08:00:00
远远关注Sass很久了，今天终于鼓起勇气写了我的第一个Sass文件
一种CSS的预处理程序，基于Ruby运行。安装过程和相关的准备工作非常简单：
gem install ruby，必要的环境下需要在命令前加上sudosass-convert style.css style.sass，把我的css文件先转换成sass文件sass --watch style.sass:style.css，使得程序自动把style.sass文件接下来的任何改动自动同步转换到style.css这时，新的Sass文件就创建完毕了！^_^ 去碎觉……
呵呵，开个玩笑。其实这样的Sass文件虽然格式上没有任何问题，但和直接撰写CSS几乎没区别。而Sass除了可以让我们少写几个花括号和分号之外，其实还有很多实用的特性是我们真正需要的。
无论如何，现在的这个Sass文件是一个整理的基础，接下来，我们就来一步一步整理这个文件，同时也一步一步熟悉Sass的特性。
1970-01-01 08:00:00
以下内容大多译自Connect官网 2013-06-02
Connect是基于Node的中间件框架(middleware framework)，提供超过18种官方中间件以及更多的第三方中间件。
示例：
var app = connect()
.use(connect.logger('dev'))
.use(connect.static('public'))
.use(function(req, res){
res.end('hello world\n');
})
.listen(3000);
安装方式：
$ npm install connect
依次介绍官方中间件
1970-01-01 08:00:00
1970-01-01 08:00:00
r.js 本是 RequireJS 的一个附属产品，支持在 NodeJS、Rhino 等环境下运行 AMD 程序，并且其包含了一个名为 RequireJS Optimizer 的工具，可以为项目完成合并脚本等优化操作。
r.js 的介绍中明确写道它是 RequireJS 项目的一部分，和 RequireJS 协同工作。但我发现，RequireJS Optimizer 提供了丰富的配置参数，可以让我们完全跳出 AMD 和 RequireJS 程序的束缚，为我们的前端程序服务。
1970-01-01 08:00:00
我在侧边栏放了一阵子编辑器的小调查，时间过去比较久了，是时候统计一下了，供大家参考：
我一共放了5个默认选项，使用情况排名依次是：
1970-01-01 08:00:00
译自：https://www.jslint.com/lint.html
JSLint？ JSLint 是一个用来查找各种 JavaScript 程序中的问题的 JavaScript 程序。它是一个代码之类工具。
在早些年的 C 语言中，有些程序的常见错误是主流的编译器无法抓住的。所以出现了一个名叫 lint 的附带程序，可以通过搜索源文件寻找错误。
随着语言的成熟，其定义的健壮性足以消除一些不安因素，编译器也在问题警告方面越做越好，lint 也不再需要了。
JavaScript 是一个年轻的语言。它原本只是用在网页上完成一些无需劳驾 Java 的小任务。但 JavaScript 是一个强大得惊人的语言，现在它已经在大项目中派上用场了。当项目变得复杂之后，之前从易用角度出发的语言特性就带来了一些麻烦。这是一个为 JavaScript 而生的 lint 呼之欲出：它就是 JSLint，一个检查 JavaScript 语法、判断 JavaScript 语法有效性的工具。
JSLint 会拿来一段 JavaScript 源代码并对其进行检索。一旦发现问题，它就会返回一则消息，用来描述这个问题以及源代码中的大概位置。发现的问题不一定是，但通常是语法上的错误。JSLint 通过一些代码规范来杜绝结构性的问题。这并不证明你的程序是正确的，只是提供另一种发现问题的眼光。
JSLint 定义了一个专业的 JavaScript 的子集，它比 ECMAScript 标准第三版的定义更严格，和 JavaScript 编码规范中的建议相对应。
JavaScript 是一个粗中有细的语言，它比你想象中的更好。JSLint 帮助你回避很多问题，在这个更好的语言中撰写程序。JSLint 会拒绝一些浏览器支持的程序，因为浏览器并不关心代码的质量。你应该接受 JSLint 的所有建议。
JSLint 在 JavaScript 源代码、HTML 源代码、CSS 源代码或 JSON 文本中都可以运行。
1970-01-01 08:00:00
1970-01-01 08:00:00
今年年初家里买了台微单相机，外加一台iPhone，我也算是个曾经摸了摸镜头的人。相比起周遭的摄影发烧友，我觉得自己真的很业余，以至于我自己说出摄影作品这个词的时候都有点心虚：不就是拍了几张照片么。还整的跟是回事儿似的。
不久之前刚在自己微博上晒了几张自己拍照片时的个人恶趣味，算娱乐一下吧。下面几张是我真的认真挑选过的，如果诸位摄影达人看到觉得拍得太烂，还求轻拍 ^_^
车水马龙
1970-01-01 08:00:00
1970-01-01 08:00:00
1970-01-01 08:00:00
1970-01-01 08:00:00
这次 @HTML5梦工场 的活动真是太棒了！我们了解企业，了解同行，了解技术，了解趋势，吃喝玩乐，雅俗共赏，天南海北共聚一堂，还有什么活动能跟这样的 #html5峰会# 相媲美呢？！虽然2天脚都站酸了，但真心觉得值！
这次峰会上，诸多企业都在会场搭建了属于自己的展台：有浏览器，有应用平台、有技术图书出版社，这样不够，后台技术来了，电视来了，物联网来了，广告服务来了，这样还不够，更夸张的是眼镜和糕点也来了。其实仔细想想，中间这部分领域是早晚要和HTML5打交道的，而后面这部分呢，也几乎是每一个前端工程师生活的一部分(你看，干这行的视力都不太好，还经常以庆祝xxx为借口买蛋糕吃)。我们了解形形色色的行业和企业，体验工程师生活的每一部分。
当然说到企业展台，这也包括我的老东家傲游。今年公司启动了全平台的浏览器研发项目，除了已经有的PC、安卓版本，还陆续发布了Mac、iPad、iPhone版本。所以这次的展台内容很丰富，有些朋友甚至来到展台前把所有的设备都试用一遍，才意尤未尽的离开，这让我们这两天“辛苦站台”的同事们倍感欣慰。
我想说第二天的HTML5作品展真棒！一口气看58份优秀作品，结识58组前端精英，感受大家的创意和热情！这次给我印象深刻的，有一个是用Canvas写毛笔字的，可以根据书写的速度模拟出毛笔的力道来，非常神奇；还有一个作品用到了最新的摄像头媒介接口，做出了类似Kinect的游戏体验，他们的作者自豪的说：“我们的目标就是秒杀Kinect！”；另外我非常有幸结识到了HTML5图形库ichartjs的作者，我觉得他的作品像一阵及时雨，刚好填补了图表制作这个HTML5非常大的领域空白。除此之外的其它作品也都各有千秋，看得出他们呕心沥血的投入和付出。
我也有机会展示了自己参与的一个开源项目：就是H5Slides，我们专门为了这次的峰会搭建了一个供大家试用和体验的网站。不少开发者也对我们的作品产生了浓厚的兴趣。还有些人在网上看到过，现场认出我来了，哈哈好害羞滴说！
1970-01-01 08:00:00
这款bookmarklet是我对主流阅读模式智能识别规则的一种吐槽。
当然，首先，阅读模式本身是一项非常棒的功能！他可以增强文章的阅读体验，统一不同页面的视觉风格。可以让人专注在文章内容中。等等。 而我要吐槽的点，是这个所谓的“智能判断文章内容”的算法。
阅读模式的核心任务之一，就是能够找出我们在各种凌乱广告、装饰物、页眉页脚之中的正文内容。在找内容这件事上，大家不约而同的使用了智能分析的路数。这里是早期开源的Readability脚本库的核心代码，我们可以看到其中包含着大量用来识别某dom结点是否是正文根结点的算法公示。而这套算法，又是从大量已存在的网页中归纳而来的。
既然是归纳的结果，而现如今已存在的网页已经数以亿计五花八门了，那不可避免的会存在判断误差。我们希望把内容识别的准确率提到最高，但会遇到一个问题：就是广告主、站长都有各自的小算盘，他们时刻准备着违背这些智能，降低判别的准确率，不让它正常工作，以谋取自己更高的收益或二次点击率。因此，这一智能的识别规则无法完全公开(Readability随后停止了开放源代码，我猜也有这方面的考量)。
可黑盒的智能规则又导致了另外一个问题：智能识别如果出现判断误差，对于那些希望支持阅读模式的网站，又无奈于找不到这些计算规则去适配。于是我们又会看到类似“how to enable safari reader”这样的问题满天飞。
最后阅读模式的识别规则、支持者、反对者扭打在了一起。
1970-01-01 08:00:00
直观的感觉是这次“冷”敦奥运会上，国际上对中国集体发难。这样的感觉起码有这些因素作祟：第一，自从北京奥运会中国在家门口历史上首次拿到金牌第一，国际媒体就开始越来越关注中国；第二，以前我们都陶醉在某些洗脑工具中，听不到国外的声音；第三，称赞中国的声音不够劲爆，我们的舆论也有选择性的把更多偏激的言论带回了国内；第四，新媒体全面占领传统媒体，消息更快速，也更不准确；第五，我们喜欢“拿来”，却不喜欢回馈。
图片来自和讯新闻
话说这次奥运会4对羽毛球选手被判消极比赛取消资格一事，绝对是国际羽联对中国长期以来忍无可忍的一次报复。毫无疑问中国现在在羽毛球这个项目上太过强大，尤其是女双，强大到对手连打败你的信心都没有了。这样的话选手的成绩在淘汰赛制中变得偶然性很大：第一轮就碰中国，名次肯定倒数，晚点碰中国，甚至可以拿奖牌。
我猜国际羽联把羽毛球由纯淘汰赛改成循环赛加淘汰赛，这也直接导致了这一出闹剧的出现。其实规则的改变就是给那些名次不好的人更多机会，给中国队更多危险。但我不认为这是一种良性的改变。
1970-01-01 08:00:00
如题，周末抽空学习了一下。
ZeroClipboard是在桌面电脑的浏览器上，通过flash技术实现“复制到剪切板”功能的一个程序。它的好处是可以兼容所有浏览器，完成剪切板的操作。
我们在使用的时候主要就用到两个文件：一个是js文件ZeroClipboard.js，用来引用在网页中；另一个则是swf文件ZeroClipboard.swf，它无需我们在代码里引用，而是被之前的那个ZeroClipboard.js二次调用的。
ZeroClipboard的工作原理大概是，在网页的“复制”按钮上层遮罩一个透明的flash，这个flash在被点击之后，会调用其的剪切板处理功能，完成对特定文本的复制。这里有几件事需要我们来完成：
对于这几件事，ZeroClipboard分别提供了不同的api，来完成整个需求。
1970-01-01 08:00:00
前几天欧洲杯，“巴神”巴洛特利一个散步式单刀被后卫回追成功，解说员戏称他停下来思考人生了，一时间“思考人生”变成了个热门词，以至于我们看到谁发呆、低头，都说他们在“思考人生”。其实我最近也在思考人生，也许比他们的严肃一些了。
来北京的第6年，同时也是在傲游的第6年，一转眼小半年快过去了。
这半年过得算是波澜不惊吧，事情异常多，公司的，家里的，亲戚朋友的，各种活动的，还狗屎运出了一趟国。总会有些事情照顾不周，处理不妥，也在意料之中。我只想说：感谢经历，你就自己想办法挺过去吧。
在这不到6年的时间里，我一直没有停止做一件事，就是不断努力发现自己的问题和不足，并尝试改变它——相信很多人也都会这样。这期间有些改变是令我兴奋的；有些事情是立竿见影的，富有成就感的；还有很多事情，在潜移默化的发生着，你无法通过一两件事情看清楚，但经过长时间的积累，暮然回首，你会发现，它真的变了，有好的也有不好的。
1970-01-01 08:00:00
这是一个灰常活泼并且有怀旧感的标题。
原本打算记我上周末成都之行的一篇日志，我觉得除了参加HTML5梦工厂成都站的技术交流活动之外，最大的收获，莫过于同杨东杰童鞋的畅谈。另外今天连续在微博上看了两个罗纳尔多和萨内蒂年轻时候的足球集锦，突然觉得这几年间，很多事情在发生着悄然的改变，比如曾经有个美少女组合叫S.H.E，昨天在地铁外看到Ella的一个活动海报，才发觉，这个团早已淡出了我们的视野。我们上大学的时候，有几个舍友特别喜欢挺S.H.E，导致我也比较熟悉他们的歌曲，后来让我对他们真正产生印象的是《Play》那张专辑，觉得它的概念蛮有意思的，整张唱片都是轻松欢快的气氛。于是《听袁惟仁弹吉他》这首歌一闪而过，于是就有了这个标题……
有点扯远了
1970-01-01 08:00:00
1970-01-01 08:00:00
1970-01-01 08:00:00
1970-01-01 08:00:00
1970-01-01 08:00:00
1970-01-01 08:00:00
1970-01-01 08:00:00
演示地址：https://jiongks.name/demos/css3-tag/
如图的效果。标签有背景色，且左侧有一个三角形，三角形中间有个白色的圆圈。
你一定在想这个效果是背景图切出来的吧——答案是没有用到任何图片
那你会不会在想这个效果的html结构很复杂呢——答案是最简单的html结构
<p>
<a href="#">Tag1</a>
<a href="#">Tag2</a>
<a href="#">Tag3</a>
<a href="#">Tag4</a>
<a href="#">Tag5</a>
</p>
之所以可以达到这样的效果，是因为我们运用了一些比较巧妙的技术。接下来告诉你实现方式：
1970-01-01 08:00:00
1970-01-01 08:00:00
1970-01-01 08:00:00
新网站开张总得找点东西充数，刚好我这阵子集中看了一些w3c关于html5的文档，所以顺道把之前看过的东西汇总了一下。这些内容如果今后继续有积累的话，还会保持更新。
另外诸位对哪些html5新特性有科普需求的，不妨留言在下面，我会尽力而为 😃
目前这些内容的最近更新时间是2012年3月
1970-01-01 08:00:00
1970-01-01 08:00:00