囧克斯

译自: https://medium.com/make-better-software/apple-is-about-to-do-something-their-programmers-definitely-dont-want-fc19f5f4487

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》——该书已经出版了三十年。所以这其实不是什么全新的观点。当然在这数十年里，也已经有无数的学术研究确认了同一个结论：人们在开放式空间办公是烦躁的、注意力不集中的、常常不开心的。

这不是说开放式办公环境一无是处——它能够营造很好的协作和联络的氛围。对于市场或销售团队来说，共享空间是非常有意义的。但是对于需要身处某种工作流状态的任务来说呢？这个问题从科学的角度是有定论的。

那就是把门关上。

译自：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 小时差不多。

译自：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]两种角色之间的不同：

(大图)

译自：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

你更喜欢读哪个呢？

译自：Principles for C programming

按照 Doug Gwyn 的话说：“Unix 不会阻止你做愚蠢的事情，因为那会同样阻止你做聪明的事情”。C 是一个非常强大的工具，但使用它的时候需要非常小心和[自律][discipline]。学习这些纪律是绝对值得的，因为 C 是所有程序语言中最优秀的。一个自律的 C 程序员将会……

终于发布了！

原文：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 建议——在此为每一位参与者致以大大的感谢！

本文早些时候发表在 weexteam 的博客 https://github.com/weexteam/article/issues/73

仅从我个人角度跟大家分享一下自己参与 Weex 开源这几个月以来的感受，中间可能会有写观点是偏颇的或者片面的，希望大家指正，另外不论怎样，这些都是我心里真实的想法和感受。

本文早些时候发表在 weexteam 的博客 https://github.com/weexteam/article/issues/71

Weex 的技术架构和传统的客户端渲染机制相比有一个显著的差别，就是引入了 JavaScript，通过 JS Runtime 完成一些动态性的运算，再把运算结果和外界进行通信，完成界面渲染等相关操作指令。而客户端面对多个甚至可能同时共存的 Weex 页面时，并没有为每个 Weex 页面提供各自独立的 JS Runtime，相反我们只有一个 JS Runtime，这意味着所有的 Weex 页面共享同一份 JS Runtime，共用全局环境、变量、内存、和外界通信的接口等等。这篇文章会循序渐进的介绍 Weex JS Runtime 这部分的内容，大概的章节设计是这样的：

1. 为什么需要多实例
2. 多实例管理面临的挑战
3. 解决问题的思路
4. 几个特殊处理的地方
5. 总结

如题，SPA (Single Page Application - 单页应用) 这个话题已经在 Weex 社区讨论了有一段时间，在传统的前端开发领域中大家也在长期探讨这个话题。这里谈谈我个人的理解和看法。

SPA 的背景 ​

SPA 往往和 Router、页面间通信、页面间数据共享这些词汇联系在一起，不少同学直接问到这些词汇，实际上都是以 SPA 为前提的，因为脱离 SPA 的概念，这些词汇将失去它原有的意义，或者变成了完全不同的东西。

那 SPA 不是理所当然、天经地义、不容挑战的吗？干嘛要脱离 SPA 的概念讨论这些问题？

我觉得不是

SPA 背后的命题是如何管理复杂的页面关系，最终构成一个产品的整体。传统的页面之间是通过简单粗暴的“页面跳转”和“浏览器前进/后退”建立联系的，SPA 提出的观念是在浏览器中模拟页面的跳转、切换和前进/后退，相关的很多周边命题也随之而生。

(其实你不觉得这也是个"全家桶"么……)

所以我们先把问题回归到如何管理复杂的页面关系