我对技术会议的一些看法

如题,今年陆续参加了一些技术会议,有些新的感触,尤其是今年第一次尝试多参加了一些境外的会议,有在 HK 的,有在 TW 的,有在 JP 的,感受很不一样,当然也参加了年初的厦门 CSSConfCN 和刚结束的 VueConfCN。另外网上越来越多人在讨论或是质疑参加技术会议到底有什么意义、好的技术会议应该是什么样子的,我也以写这篇博客的方式参与一下。

阅读剩余部分...

VueConf Hangzhou 见闻

先说分享一些自己参加 VueConf Hangzhou 的流水账见闻。

阅读剩余部分...

第四届 CSSConf CN 见闻

上周末作为一名分享者参加了 CSSConf CN,在厦门。

其实除了自己的分享内容,这次我是带着很明确的目的参会的,因为有两个主题我特别关注,就是:

  • 第一个:响应式的组件
  • 第三个:从 API 的角度看组件的 CSS

(两个分享的标题都被我稍微“演绎”了一下)

这两件事都是自己工作上正在特别关注的事情,一方面,我们很少从 API 的角度去理解一个组件的 CSS 该如何组织和管理,所以这个标题就特别吸引我,另一方面响应式组件的分享者是来自新加坡的前端工程师 Zell (我个人一直觉得国内的响应式都是在瞎搞,看了很多周围团队都没有认真做这件事,甚至不相信响应式的价值,从设计师到工程师),因此非常珍惜这个机会能近距离学习一些国外的同行们是怎么看待和实践响应式的。

所以尽管我们团队的差旅经费已经用完了,还是决定自费来厦门近距离交流一下。

现在证明这次真的不虚此行。

当然参加这种线下活动,“面基”的目的是一定有的……恩,这个不值一提。

阅读剩余部分...

Web 表单的未来

译自: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.

和许多数字化的东西一样,表单已经被之前的形态严重影响。我们之所以往线框里填东西是因为我们以前在纸上就是这么画的。

阅读剩余部分...

苹果正在做一些他们的程序员明摆着不想要的东西

译自: 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 小时的经历,这在行业里面并不常见,但是我很难因此而得到更多的薪水。

总之,我现在发现整个做法很恶心

我并不是针对自营或创业等多干活儿就能得到更多回报的情况。我曾经在 80 年代中期到 90 年代开过两个小的软件公司,并且工作时间也很长,但是我们会共享全部的成果,而第二家公司我们在合同里就定好了多劳多得的规矩。当然这不是我们今天讨论的重点。

如果我为一家大公司工作并且谈好了薪水,那我的预期就是我在标准的时间内,即公认的 (至少在美国) 一天 8 小时一周 5 天,尽我所能完成工作。如果他们希望我每周工作 70 个小时或有些主管期望团队每天都来上班,现在的我是会拒绝的。为什么呢?

当我们决定工作赚钱的时候,我们假定工作的主要原因是为了换取我们生活所需的开销。雇员的预期是他们会获得等价于这笔薪水的产出。但问题在于,雇主概念中的价值经常和雇员的不一样,尤其在美国和亚洲。许多公司期望薪水是固定的,但是他们创造这些价值需要完成的工作是不确定的。雇主觉得只要提高对雇员的预期和要求,就能够获得更大的回报,这样他们就可以通过为每份薪水延长工作时间来降低实质的劳动成本。

这对于雇员来说意味着什么?如果你同意了,那么你实际上就认同了自己的工作更廉价。甚至这种工作其实就是无偿的。那么作为雇员你在这样的无偿工作中收获了什么呢?在绝大多数雇主面前,你什么也没有得到。如果你是一个主管,也许会得到晋升,但是作为程序员你职业发展的道路不只是做管理这一条。如果你连续几个月每周编码超过 80 个小时,通常情况下得到的回报和一周努力工作 40 小时差不多。

阅读剩余部分...

寄语应届生:走出校园的几个人生转变

最近收到个邀请,有机会和大学生的在线互动交流,体裁不限。我选了上面这个题目,整理了一些心得感想,虽然活动很快就结束了,但是这些想法我打算还是以文字形式备忘一下。如果能给更多人帮助或参考,我会倍感欣慰。

目标的转变

作为学生,毫无疑问是以学业为重。在校园里,大家不出意外都会把学习定为最大的目标,围着功课转。但是工作之后,你可能面对很多事情要处理,怎么有所成就?怎么赚钱?怎么照顾好自己?怎么照顾好家庭……除了目标本身不同之外,我觉得更大的不一样在于,在相当长且连续的学生生涯中,我们没有太多选择的余地和必要,即便是有什么目标,也基本上是被动接受或被灌输的。但是走出校园之后,你面对的是一个无比自由开放的社会。这个时候你需要的不是意见,而是主见。甚至你是否做好了准备,有了足够的本事从事一项工作,还是继续学习深造修炼自我,直到自己准备好为止再工作?这也需要你的主见 (并为这个主见承担相应的后果,某种角度上)。最终很多选择是开放的,权衡的,遵从自己内心的结果。

还有一点我想说的是,因为你拥有了新的目标,而且不再会有人逼着你学习,从外部给你学习上的压力,所以客观上学习的环境也没有那么好那么纯粹了,学习这件事情会逐渐变得让你渴望、珍惜、喜欢。希望你还没有因为繁重的学业对新事物新知识,尤其是表面上枯燥但实际上对你有很多帮助的东西,失去动力。我们在校园里更多的是学习知识,然后推导这些知识可以用在什么地方;走出校园之后更多的需要思考,我遇到一个问题想解决它,究竟有多少知识哪些知识可以为我所用?也许在未来的某一天你会突然觉得,当时在校园里,学习环境那么好,怎么没有多看两本书,多做些训练。所以最好不要丢下自己看书学习的习惯,给自己定个长期的学习计划,有空就多看两本书。

学会社交

坦白地讲我觉得这在校园里并不是必备的技能。但是走出校园之后,它非常非常重要。这也是为什么几乎所有的公司都会给员工做沟通培训 (尽管那并不一定管用)。社交并不只是沟通而已,也不只是表达,更是聆听,是待人接物的每一个细节。我发现很多人在工作中,最简单的两件事情做不好,也不知道该怎么做,那就是:1 如何写邮件、2 如何开会。这表面上是职场礼数的范畴,也有很多文章介绍这些职场礼数,看上去就是个知识点罢了。但实际上一个人在理解和实践它的背后,反映的是修养,甚至是教养。这不是一两篇文章能够教会你的,是你平时为人处事方式的积累和感悟。

另外社交能力的重要性不止体现在工作中,体现在你步入社会之后可能会面对的各种场合的各种人,比如和同事下班之后一起组织些活动放松消遣一下,和老乡或老同学叙叙旧——这些也都是我刚毕业的时候经常会做的事情。但是这里我认为更重要的场景是:学会如何跟陌生人打交道,如何更主动的和陌生人交流,和这个社会交流。从最简单的跟陌生人问路、跟陌生的房东租房子、甚至搭讪对吧 ^_^,到跟不同性格的服务员、乘务员、售票员、公交车司机、出租车司机沟通或寻求帮助,再到你如何主动但又不会让对方和周围人尴尬的帮助别人,包括你是否会本能的路见不平挺身而出……抱歉这可能有点超出社交这个话题了。但这些都是有关联的不是吗?每个人在这个社会中都是一个独立的个体,但又是相互依赖相互依靠的一个集体社会。想真正融入这个社会,我觉得这些都是必须的。

最后,关于社交,还有一点很重要,就是在你刚刚加入一个公司或团队的时候,你周围的人一开始对你来说都是陌生人。这个社会上可能有很多适合你的机会,但它们不会主动找到你头上,这个时候需要你学会跟陌生人打交道。好的社交能力会让你的人生更有安全感,对自己办好一件事更有信心。和别人交流同样是一个完善自我认知的过程,尝试接受更多不同的观点,发现并理解不同的看问题的角度,有助于更认清自己,避免自以为是 (相信我,这种事情别人帮不上忙的,只能你自己领悟)。

个人发展

我觉得找工作这件事情,更多的要从兴趣出发,而不是所谓的“前途”。我逐渐越来越认同和相信一句老话:“三百六十行,行行出状元”。首先,如果对这件事情没有兴趣,你很难“用心”做好它,这样的状态也不是长久的;第二,我们已经看得见摸得着的“前途”和“机会”,往往已经不是什么好机会了,尤其是如今互联网时代事情变化发展这么快。而且那些真正抓住机会的人往往都是在完全没人看好的时候就开始全身心的投入在这个行业或方向上,才能在“机会”来临的时候抓住它,我不觉得这些人只是更厉害的“投机主义者”,如果没有兴趣在背后趋势着这些人,他们又是怎样才能在枯燥 (往往还伴随着高风险和不确定性) 的领域里这么坚定的做到今天呢?所以我的个人建议是,找工作,就完全追随自己的兴趣和内心就好了,不要想太多“这个行业比较赚钱比较有前途”之类的——它最多是你的一个参考项。找到自己的兴趣所在,相信它,相信自己,保持专注,一定有最好的回报,剩下的东西交给运(时)气(间)就好了。

再有就是要相信专业的力量,对学问保有“敬畏之心”。这里的学问不只是纯职业技术,也包括做事方式方法等等一切社科类的研究。如果一个行业的专业性丢掉了,整个行业也就被毁掉了,最后大家会一起丢掉工作,一起失败。

这种东西我觉得跟很多已经被一份工作或长期不良型的环境所固化思想的“老家伙”们讲已经不一定有意义和效果了。但是对于打算或刚刚从校园步入社会,有理想,有抱负,承载着社会的未来的大学生们来说,我希望有机会在这方面多呼吁一下。尊重和相信专业的力量,耐得住性子,不要被一时的挫折、不走运或委屈左右,多多磨练自己,你一定不会后悔。

So Are You Ready?

:)

如果管理是唯一可走的路,那就完蛋了

译自: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 的工作 (西雅图的桌游初创公司,在 Hasbro 收购他们并裁员之前)。她为桌游撰写问题,并为包装盒和营销材料撰写文案。她很擅长这个。但是发生了一些奇怪的事情——他们想让她晋升。我记得她晚上回家后非常的苦恼。她不想让人们向她汇报。她不想在团队中拥有更大的责任。她只想写写东西。

这很奇怪。当我们审视一家公司的结构时,很容易发现团队需要很多高质量的一线员工 (IC) 以及少数高质量的经理人。然而我们的公司文化和这个世界的“模式”已经让我觉得除非你要带人,否则你的影响力、薪水、利益、职位和自我价值都不会增长。

这都什么乱七八糟的。

我过去写过关于多样化成长轨迹的重要性——一线员工和经理人——但是我们最近在 Moz 花了大量的时间碰撞想法,很快会实施一个新的职位/团队的结构,最终付诸实践,我对此充满期待。

现在我会为一个在其工作岗位上做的很优秀的一线员工表达对管理的兴趣而担心。我担心这种渴望的很重要的一部分不源自真正的管理责任感,而是因为他们想要在职业生涯和/或影响力上得到提高,并且认为这是唯一的办法。

我画了这张图来辅助说明两种角色之间的不同:

ics-vs-pws-small
(大图)

阅读剩余部分...

如何撰写 Git 提交信息

译自:https://chris.beams.io/posts/git-commit/


介绍:为什么好的提交信息非常重要

如果你浏览任何 Git 仓库的日志,你可能会发现那些提交信息多少有些混乱。比如,看看这些我早年提交给 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

,比较一下这个仓库最近的提交

$ 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 程序的原则

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

喜欢可维护性。不要在不必要的地方自作聪明。取而代之的是,找出最简单最易懂的满足需求的方案。诸如性能之类考量是放在第二位的。你应该为你的代码做一个性能预算,并自在的支配它。

随着你对这门语言越来越了解,掌握了越来越多能够从中获益的特性,你也应该学会什么时候不能使用它们。相比用到了很多新奇的方式去解决问题,易于新手理解是更重要的。最好是让一个新手理解你的代码并从中有所收获。像你大概去年就在维护它一样去撰写代码。

避免使用魔法。不要使用宏 (macros)——尽管用它定义常量是没问题的。不要使用 typedef 来隐藏指针或回避撰写“结构”。避免撰写复杂的抽象。保持你的构建系统简单透明。不要因为一个愚蠢的 hacky 的废物解决问题的方式酷炫就使用它。你的代码在行为之下应该是明显的,甚至不需要上下文。

C 最大的优势之一就是透明和简单。这应该被信奉,而不是被颠覆。但是 C 的优良传统是给你足够的空间施展自己,所以你可以为了一些魔术般的目的使用它。但最好还是不要这样,做个麻瓜挺好的。

辨识并回避危险的模式。不要使用固定尺寸的 buffers (有人指出这种说法并不是完全正确。我之前打草稿的时候提到了这些,但还是删掉了)——始终计算你需要分配的空间。阅读你使用的函数的 man 手册并掌握他的成功有出错模式。立刻把不安全的用户输入转换为干净的 C 结构。如果你之后会把这些数据展现给用户,那么尽可能把 C 结构保持到最后。要学会在使用例如 strcat 的敏感函数时多加留意。

撰写 C 有的时候像握着一把枪。枪是很重要的工具,但是和枪有关的事故都是非常糟糕的。你对待枪要非常小心:不要用枪指着任何你喜爱的东西,要有好的用枪纪律,把它当作始终上膛一样谨慎。而就像枪善于拿来打孔一样,C 也善于用来撰写内核。

用心组织代码。永远不要把代码写到 header 里。永远不要使用 inline 关键字。把独立的东西分开写成不同的文件。大量使用静态方法组织你的逻辑。用一套编码规范让一切都有足够的空间且易于阅读。当目的显而易见的情况下使用单字符变量名,反之则使用描述性的变量名。

我喜欢把我的代码组织成目录,每个目录实现一组函数,每个函数有属于自己的文件。这些文件通常会包含很多静态函数,但是它们全部用于组织这个文件所要实现的行为。写一个 header 允许这个模块被外部访问。并使用 Linux 内核编码规范,该死

只使用标准的特性。不要把平台假设为 Linux。不要把编译器假设为 gcc。不要把 libc 假设为 glibc。不要把架构假设为 x86 的。不要把核心工具假设为 GNU。不要定义 _GNU_SOURCE

如果你一定要使用平台相关的特性,为这样的特性描述一个接口,然后撰写各自平台相关的支持代码。在任何情况下都不要使用 gcc 扩展或 glibc 扩展。GNU 是枯萎的,不要让它传染到你的代码。

使用严谨的工作流。也要有严谨的版本控制方法。撰写提交记录的时候要用心——在第一行简短解释变动,然后在扩展提交记录中加上改变它的理由。在 feature 分支上工作要明确定义目标,不要包含和这个目标不相关的改动。不要害怕在 rebase 时编辑你的分支的历史,它会让你的改动展示得更清晰。

当你稍后不得不回退你的代码时,你将会感激你之前详尽撰写的提交记录。其他人和你的代码互动时也同样会心存感激。当你看到一些愚蠢的代码时,也可以知道这个白痴当时是怎么想的,尤其是当这个白痴是你自己的时候。

严格测试和回顾。找出你的改动可能会经过的代码路径。测试每条路径的行为是正确的。给它不正确的输入。给它“永远不可能发生”的输入。对有错误倾向的模式格外小心。寻找可以简化代码的地方并让过程变得更清晰。

接下来,把你的改动交给另外一个人进行回顾。这个人应该运用相同的程序并签署你的改动。而且回顾严格,标准始终如一。回顾的时候应该想着,如果由于这些代码出了问题,自己会感到耻辱

从错误中学习。首先,修复 bug。然后,修复实际的 bug:你的流程允许里这个错误的发生。拉回顾你代码的人讨论——这是你们共同的过错。严格的检查撰写、回顾和部署这些代码的流程,找出根源所在。

解决方案可以简单,比如把 strcat 加入到你的触发“认真回顾”条件反射的函数列表。它可以通过电脑进行静态分析,帮你检测到这个问题。可能这些代码需要重构,这样找出问题变得简单容易。疏于避免未来的错误才是真的大错


重要的是记住规则就是用来打破的。可能有些情况下,不被鼓励的行为是有用的,被鼓励的行为是应该被忽视的。你应该力争把这些情况当作例外而不是常态,并当它们发生时仔细的证明它们。

C 是狗屎。我爱它,并希望更多的人可以学到我做事的方式。祝好运!