囧克斯
这里是勾三股四的家
[译]如果管理是唯一可走的路,那就完蛋了
译自: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]两种角色之间的不同:
(大图)[译]如何撰写 Git 提交信息
译自: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
你更喜欢读哪个呢?
[译]C 程序的原则
译自:Principles for C programming
按照 Doug Gwyn 的话说:“Unix 不会阻止你做愚蠢的事情,因为那会同样阻止你做聪明的事情”。C 是一个非常强大的工具,但使用它的时候需要非常小心和[自律][discipline]。学习这些纪律是绝对值得的,因为 C 是所有程序语言中最优秀的。一个自律的 C 程序员将会……
Vue 2.0 来了!
终于发布了!
原文: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 建议——在此为每一位参与者致以大大的感谢!
Weex 近 4 个月的开源之路
本文早些时候发表在 weexteam 的博客 https://github.com/weexteam/article/issues/73
仅从我个人角度跟大家分享一下自己参与 Weex 开源这几个月以来的感受,中间可能会有写观点是偏颇的或者片面的,希望大家指正,另外不论怎样,这些都是我心里真实的想法和感受。
Weex 在 JS Runtime 内的多实例管理
本文早些时候发表在 weexteam 的博客 https://github.com/weexteam/article/issues/71
Weex 的技术架构和传统的客户端渲染机制相比有一个显著的差别,就是引入了 JavaScript,通过 JS Runtime 完成一些动态性的运算,再把运算结果和外界进行通信,完成界面渲染等相关操作指令。而客户端面对多个甚至可能同时共存的 Weex 页面时,并没有为每个 Weex 页面提供各自独立的 JS Runtime,相反我们只有一个 JS Runtime,这意味着所有的 Weex 页面共享同一份 JS Runtime,共用全局环境、变量、内存、和外界通信的接口等等。这篇文章会循序渐进的介绍 Weex JS Runtime 这部分的内容,大概的章节设计是这样的:
- 为什么需要多实例
- 多实例管理面临的挑战
- 解决问题的思路
- 几个特殊处理的地方
- 总结
我理解的 SPA
如题,SPA (Single Page Application - 单页应用) 这个话题已经在 Weex 社区讨论了有一段时间,在传统的前端开发领域中大家也在长期探讨这个话题。这里谈谈我个人的理解和看法。
SPA 的背景 ​
SPA 往往和 Router、页面间通信、页面间数据共享这些词汇联系在一起,不少同学直接问到这些词汇,实际上都是以 SPA 为前提的,因为脱离 SPA 的概念,这些词汇将失去它原有的意义,或者变成了完全不同的东西。
那 SPA 不是理所当然、天经地义、不容挑战的吗?干嘛要脱离 SPA 的概念讨论这些问题?
我觉得不是
SPA 背后的命题是如何管理复杂的页面关系,最终构成一个产品的整体。传统的页面之间是通过简单粗暴的“页面跳转”和“浏览器前进/后退”建立联系的,SPA 提出的观念是在浏览器中模拟页面的跳转、切换和前进/后退,相关的很多周边命题也随之而生。
(其实你不觉得这也是个"全家桶"么……)
所以我们先把问题回归到如何管理复杂的页面关系
我理解的 Flux 架构
本文早些时候发表在 云栖社区 https://yq.aliyun.com/articles/59357
之前 review 业务代码的时候就一直想说写一篇自己对 Flux 的理解和看法,不知不觉也过去蛮久了,于是这周末打起精神写了这么一篇。
这篇文章将谈一些我对 Flux 的理解和个人看法。如果您还不太了解什么是 Flux,请先移步这里。
另外文中没有特别大段的代码,以讨论架构设计和背后的道理为主,可能会显得有点枯燥,大家可以选个不太困的时候耐心读读看:)
Flux 中的几个基本概念 ​
这是 Flux 官方提供的一张说明图:
图中有四个名词:
- View
- Store
- Action
- Dispatcher
下面逐个以我的角度做个讲解:
【整理】Vue 2.0 自 beta 1 到 beta 4 以来的主要更新
主要内容来自 https://github.com/vuejs/vue/releases
之前 Vue 2.0 发布技术预览版 到现在差不多三个月了,之前写过一篇简单的 code review,如今三个月过去了,Vue 2.0 在这个基础之上又带来了不少更新,这里汇总 beta 以来 (最新的版本是 beta 4) 的主要更新,大家随意学习感受一下
alpha 和 beta 版本的侧重点会有所不同 ​
首先 Vue 2.0 对 alpha、beta 有自己的理解和设定:alpha 版本旨在完善 API、考虑所需的特性;而来到 beta 版则会对未来的正式发布进行充分的“消化”,比如提前进行一些必要的 breaking change,增强框架的稳定性、完善文档和周边工具 (如 vue-router 2.0 等)
最后的几个 alpha 版本主要更新 ​
Vue 本身的语法基础这里就不多赘述了,网上有很多资料可以查阅,我们已经假定你比较熟悉 Vue 并对 2.0 的理念和技术预览版的状态有一定的了解。