程序员最要学好的语言是什么

程序员最要学好的语言是什么?多年前我的回答是C语言,因为C语言很接近机器的执行方式,又不像汇编那样枯燥和繁琐。而现在,对这个问题,我有了不同的答案。

程序员最需要学好的语言是:英语

在程序员的世界里,几乎所有的技术都是来自英语国家,特别是美国。在学习新技术的时候,技术文档和书籍一定是英文先出来,等着翻译版出来,某些细节可能已经改版了。而且读翻译的质量取决于译者的水平,国内真正高水平的译者就那么几个,相对整个技术领域来说,能翻译好的内容简直是九牛一毛。目前市面上的很多技术翻译作品都很烂,甚至会误导你的思路。

在实际工作中需要解决问题时,搜索和社区是少不了的。而Web上的技术内容,绝大多数也都是英语,著名的程序员社区 StackOverflow 、 GitHub 等几乎是全英文的。你真的想用百度来解决一个技术问题吗,搜一个问题可能出来十几个相关的结果,点进去一看,都是同一个转载的。你在 CSDN 问一个问题,很快就得到了10个回答,其中9个是顶,另一个是“同求”。中文的Web内容在解决技术问题上很难真正帮到你(倒是很可能找到一段不明来历的代码copy下来,但你依然不知道为什么)。想真正解决问题,就要来到英语世界。

对一个程序员来说,英语水平会严重影响你学习技术的速度和解决问题的能力。所以,英语是程序员最需要学好的语言。

程序员第二要学好的语言是:汉语

这个还用说,汉语谁不会?可是你真的学好汉语了吗?你有没有遇到过类似的情形?

  • 直到开始写代码了,才开始后悔,我为什么会答应产品经理这么傻X的需求?
  • 这个老板真是太弱了,无论我怎么说他都不明白,这玩意是无法实现的
  • 那个傻X就是会忽悠,什么都不干,还升职这么快,世界太不公平了

在工作中,我们交流和沟通主要还都是用汉语,你有没有想过上面这些其实这都是因为你汉语不好造成的?你是否真正读懂和听懂了产品经理的需求?你能否把一个技术问题清楚的描述给非技术人员让他们轻松理解?你能否理解到真正的问题所在而提出一个非技术的解决方案让上司听懂还能避免自己苦逼的码代码?所有这些,其实都是沟通问题,而沟通问题,对我们来说,就是汉语的能力,理解汉语和用汉语表达的能力。

在程序员的职业发展道路上,从普通的工程师,到项目经理,到技术总监,到架构师,到CTO,对沟通能力的要求越来越高。沟通能力,或者说汉语能力,在很大程度上限制了一个程序员的职业发展。

可以说,英语决定了一个程序员学习技术的深度,汉语决定了一个程序员职业发展的高度。现在你是否也认为英语和汉语是程序员最应该学好的语言了 :- )

《Understanding Comics》——产品经理必读

小时候比较喜欢看漫画书,而这是一本关于漫画的漫画,读了之后,才发现这是一本关于认知心理学的”正儿八经”的书。

我之所以在标题中加入“产品经理必读”字样,是因为:

  • 我做标题党了,也许这样能带来更多点击
  • 本书在对漫画表达和理解过程的分析中,也分析了人类对不同媒体的认知过程和特点。这对数字化产品设计,会有很大的帮助。
  • 本书剖析的漫画创作的六个步骤,也是产品研发的六个层面。

认知分析

有一张图,见过不少产品经理引用:

enter image description here

哈哈,是不是也见过!原来这个图就是来自于这本书?

书中用这张图来解释“卡通化”的过程:逐步去掉各种细节,从而让核心概念变得更加清晰。这也是卡通吸引人的地方,让我们直接感受核心的概念和情感,而不是像观察现实那样,通过大脑的处理,从各种细节中整理和归纳出核心概念来。

产品经理经常用这张图来描述用户范围:最左侧是一个具体的人,从左到右,抽象层度越来越高,所能代表的人群范围也越来越大(一个男人->一群长相类似的男人->某个地区或民族的男人->男人->人)

这个图体现出来的认知特性,还可以用来说明线框图的重要性。在产品设计过程中,线框图把颜色、字体、图片等一些细节简化掉,只表现最核心的产品功能和操作过程。线框图不仅是为了简单,更是为了放大其表现,通过对线框图的讨论和分析,就能比较容易的发现产品设计的问题和不足。

在以前做项目过程中,有人提出这样的观点,在产品设计文档中把大概的颜色和图片都加进来,尽可能的接近最终的产品,这样不是更好吗?当时只是感觉怪怪的,但一时没有发现理论上的错误之处。其实,在设计产品的功能和交互过程中,线框要比带有颜色和图片的“示意图”好很多,像上面说的,线框更突出产品的功能核心,免除不必要干扰,从而更容易发现问题。颜色带来的冲击过于强烈,大脑要努力抗衡颜色带来的冲击,才能看清楚本质,也就是说,有颜色的情况下,更难看清楚产品功能和交互表达的本质。像书中说的,漫画也是这样,多数漫画都是黑白的,不仅是因为彩色漫画成本高,也因是因为颜色有时候反而消弱了漫画自身的表达能力。

创作步骤

书中关于漫画的六个步骤(或者说六个层次),也是关于艺术创作和产品研发的六个层面。这让我们更能清楚的理解:为什么有些巨资投入的画面超炫的3D大片看起来依然空洞无物,反而不如一些小成本故事片那样直指心灵;为什么多次越来越炫的界面改版依然无法挽救一个网站,而有些明显跟时代不符的简陋到连图片都没有的页面却能让我们流连忘返;为什么一款画面粗糙没有音效的卡牌游戏,可以狂卷数十亿美金,而不少聚光灯下出身名门的游戏大作,只有在我们多年后搬家时才发现它在一个被遗忘的角落里落满了灰尘…

书中提到的漫画创作六个步骤(层次)是:
1. 点子(IDEA/PURPOSE)
2. 形式 (FORM)
3. 风格(IDIOM)
4. 结构(STRUCTURE)
5. 工艺(CRAFT)
6. 外表(SURFACE)

我们来向数字产品研发过程做个类比:
1. 点子(IDEA/PURPOSE):点子还是点子,很多人每天都会有很多点子冒出来,但大多数人止步于此了。
2. 形式 (FORM):实现一个点子,需要做什么类型的产品?是做一个网站?还是做一个手机App?还是做一个微信公众号就够了?
3. 风格(IDIOM) 这一点我觉得在产品中,可以对应到一个流行的词——“情怀”。这个词有点大,目前行业中也看不到多少“情怀”,可能在这个互联网初级阶段,还没有多少产品能到达这里。
4. 结构(STRUCTURE)这个应该是行业中狭义的“产品”,也就是产品设计:产品的核心功能是什么,通过什么样的形式来表达这个核心功能?产品需要设计哪些特性,各个不同特性之间的关系是怎么样的?什么方面应该强化,什么方面应该弱化?产品应该怎么样发展和变化,等各种设计问题。
5. 工艺(CRAFT),产品研发中,就是“技术”,通俗说就是编程了。从这个层次也可以看到,技术对产品来说,是相对表层的部分,对产品的影响力有限。
6. 外表(SURFACE),数字产品中,就是“界面(UI)”。这个层次中所指的UI,是比较狭义的UI,指界面的视觉效果等。例如:扁平化啦,毛玻璃效果啦,阴影啦 等等。在实际中,界面往往和交互紧密相连,而交互一般都带有产品设计思路,属于层次4的内容。这部分是最容易做到的,但对于产品来说,影响是比较小的。

这六个步骤,像书中说的,实际的发生顺序是 1,2,6,5,4,3 ,对比下数字化产品,多数产品能做到5,能把4做好的,就是比较成功的产品了,而做到3的还很少。

看来这真是一本产品经理必读的漫画哎。

最后,我非常喜欢书中对艺术一词的解释 :)

Art, as I see it, is any human activity which doesn’t grow out of either of our species’ two basic instincts: survival and reproduction!

《YC 创业营》

最早知道YC(Y Combinator),是在09年,当时我们计划做一个基于地理位置的社交App,当时我们研究一个已有的类似应用,这个应用叫Loopt . 于是,我们知道了 Y Combinator 这个著名的孵化器,也知道了硅谷的创业教父 Paul Graham. 那时候,我才发现,原来自己一直使用的 Dropbox,也是从YC孵化出来的,还有著名的 reddit,也是YC的项目。同样09年,李开复创建创新工场,认为是参考YC模式。YC在国内逐步被广为了解。

11年,我一直订阅的“阮一峰的网络日志”作者阮一峰翻译了 Paul Graham 的文集《黑客与画家》。在国内程序员圈内立即流行开来,这本书让我对这位创业教父充满敬仰。

《黑客与画家》让我大快朵颐,可惜当时并没有看到YC更为充分的描述,近日闲暇,怀着对硅谷创业教父 Paul Graham 不减的敬仰,读了下《YC 创业营》

这本书很单纯的记录了 YC 某一期的创业学员的学习过程,没有多少理论和观点。然而每一个鲜活的创业故事还是会让有类似经历的创业者感到共鸣。在目前铺天盖地的创业“神话”的狂轰滥炸下,这种真实的记录显得更有价值。

很多所谓的创业者,是听着无数的创业“神话”或长大的。社会用这些神话来鼓励人们创业,投资人用这些神话来诱惑人们创业,人们都喜欢听“神话”,”神话”总是会让人热血沸腾跃跃欲试。好听的神话,多数是在创业成功之后整理出来的故事,而和这位成功的创业者同时开始创业的另外99位失败的创业者,就成了沉默的证据,没有人为他们写故事。

《YC 创业营》做到了这一点,它在这些创业者刚刚开始的时候,就开始记录他们的故事,没有人知道他们当中谁会成为下一个Google或Facebook。这种纪实看起来似乎有些枯燥,缺少传奇色彩,缺少振奋人心,但这才是真实的创业,真实的生活,不是吗?

在2010年冬季项目中得到 YC 资助的独立创业者 Chad Etzel 在离开 YC 一年后写了一篇文章,讲述了自己的后 YC 经历, 题为《Startups Are Hard》。他说,他是在那些让人以为“任何人都可以在一念之间动起创业想法,然后不出几天就能在来自天使/风投的钞票的海洋中遨游”的阳光故事中,给人看一点现实的写照。

这篇 “Startups Are Hard” 我也找了一下,在这里 http://blog.jazzychad.net/2011/05/02/startups-are-hard.html

Markdown 编辑器 Mou 和 StackEdit

去年初,我开始用 Markdown 写 blog (Markdown 是什么和我为什么用 Markdown). 我使用过很多Markdown编辑器,到目前为止,我使用最多和最喜欢的还是 Mou (http://25.io/mou/

Mou 是一个国产独立软件,最早是天津程序员 Chen Luo 的个人业余项目。随着 Mac 和 Markdown 的普及,Mou 也得到了更多人的喜爱,三年间,Mou积累了30多万用户。去年底, Chen Luo 完成了一个众筹 (https://www.indiegogo.com/projects/mou-1-0-markdown-editor-on-os-x-for-you),建立了正式的团队来全职进行 Mou 的开发,其中,知乎和 Coding.net 是这个众筹中出资最多的,分别为 $5000.

最近,我又发现一个很好用的 Markdown 编辑器,StackEdit(https://stackedit.io/),这是一个在线的编辑器(当然,也可以在浏览器中离线操作)。作为一个浏览器中的编辑器,StackEdit 的用户体验也基本到了极致,和原生的App已经差别很小。另外,StackEdit 是真正Web思维的编辑器,所有的操作都是Web:内容保存在Web上,可以“另存为”到GoogleDrive,Dropbox等,其中,我最喜欢的功能是可以直接发布到我的 wordpress 。

StackEdit 使用了一个叫做 MonetizeJS(https://monetizejs.com/) 的支付服务,这个服务让开发者可以不用做服务器端集成就实现支付功能,看起来非常不错,这个思路很让人喜欢。

扯远点,09 年的时候,我写过一篇 blog 开放的WEB才精彩,那个时候,我觉得真正的开放式Web已经初具雏形,一个充分互通互联的web即将形成,全新的开发思路和软件使用模式马上就会逐步建立,展现在大家面前的,将是一个全新的时代。

然而,5年过去了,我的“预言“似乎还没有完全应验。要知道,在互联网的世界,5年就是一个时代。一个时代都过去了,还没有应验的”预言“,那不是很愚蠢吗?

我没有预期到的,正是目前所有人都知道的,这5年,或者这个互联网时代发生的事情——移动互联网。没错,就是这个移动互联网,它如此的火爆,以至于吸引了所有人的眼球,绝大多数的资源和程序员(包括我自己),都被吸引到了移动互联网上来,创造了这次让所有人都震惊的移动互联的革命。这5年里,移动互联网发生了太多的故事,几乎所有的聚光灯都投降了移动互联网。然而那个造就和孕育了移动互联网的传统互联网,似乎在不经意间被冷落了,5年来,传统互联网的发展真是超级缓慢,几乎所有传统互联网服务在这5年内做的,就是占据移动端,发展app。新诞生的互联网服务,多数也是围绕移动端,为移动开发生态圈服务。因此,对于传统互联网来说,虽然一个时代过去了,但并没有得到应有的发展。

很无耻的解释了自己的愚蠢,脸皮又厚了一层,更像个创业者了。

扯这些,主要是试试这个编辑器,来吧,发布下看看。

Written with StackEdit.

Shellshock 再次震惊全球

我们都是人性这部巨大躯体之中的细胞

这两天,Linux 又爆出了一个非常严重的漏洞 —— Shellshock (CVE-2014-6271)。 之所以用“又”,是因为就在今年 4 月,Linux 才刚刚爆出了 openssl 的“心沥”漏洞 ( 关于 Heartbleed(心沥) 漏洞 ),想必大家还心有余悸。

这个漏洞是由 Linux 上广泛使用 Bash shell 引起的,因此称为“Shellshock”,不知道是不是可以译为“壳震”,也有中文报道翻译为“破壳”和“壳裂”。

Shell Shock 一词,还有一个意思是“战争后遗症”或“弹震症”。一般指那些参加过战争的士兵,在经历过战争的精神和身体的折磨回到和平之后,还会经常出现的紧张、恐惧、失眠、疼痛等症状,严重的甚至出现无法自控的情况。

漏洞原理

这个漏洞的原理依然很简单,一句话就可以说明:Bash 在处理环境变量的时候,对其中函数定义后的内容,会继续作为代码来执行。例如:

$ env var='() { ignore this;}; echo vulnerable' bash -c /bin/true  

这个漏洞看起来还是很低级,但是比起前面的“心沥” 来说,还是要好一些,造成“心沥”的,可谓是一个最最低级的代码错误(长度检查)。而这里,应该是逻辑上没有考虑严谨。

小心余震!

早先的关于这个漏洞的修复,并没有完全修复完整,又引入了另一个漏洞 (CVE-2014-7169), 被称为 “Aftershock” ,也就是“余震”。

Mac OS 未能幸免

OS X 使用的 shell 是bash的变种,也带有同样的漏洞。可以使用如下的代码来测试改漏洞是否已经修复:

$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'

如果shell输出了 vulnerable,那么,你的系统还是带有漏洞的。如果没有,也不要高兴太早,因为还有可能有“余震”。

关于余震漏洞的测试和漏洞修复参见 http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-shellshock-the-remote-exploit-cve-2014-6271-an/146851#146851

Windows 逃过一劫

就想逃过上次 “心沥” 一样,Windows 又逃过了 “壳震”。Windows 做的更安全吗?不是,只不过 Windows 没有使用 linux 上被广泛使用的技术而已。如果你认为更多的不被广泛知道的漏洞会更安全,那这样说的话,Windows 更安全。

互联网还靠得住吗

今年接连爆出的超级严重的漏洞,让我们不禁感慨:互联网还靠得住吗?

我的态度是:互联网靠不住,但我却愿意依赖它。

作为一个程序员,我可以深刻体会到,软件开发不过就是这样一个过程:后来的程序员修复前面的程序员留下的漏洞,同时又造成新的漏洞,让再后来的程序员来修复,如此循环,无穷尽也。

程序员这么容易出问题,真是很差劲呀。没错,程序员是很容易出问题,但这却不应该责怪程序员。并非为程序员辩护,任何一个职业都是如此。程序员作为普通的人类,无法超越人类自身的局限,人类总是会犯错。而因为互联网的影响之大,程序员犯的一个小错可能带来非常严重的后果。这就像,驾驶员的错误会引起车祸,飞机机长的错误会让数百人丧命,而一个国家元首如果犯个错误,后果可能是数百万人的生命。

我们通过提高汽车性能和智能来减少和避免驾驶员的犯错;我们通过增加副机长、自动驾驶、地面控制等方式来减少机长的犯错;我们通过智囊、增加流程和议会等方式来减少一个国家元首的犯错。但是,在软件开发中,对于程序员的犯错,尤其是会产生严重影响的软件的程序员的犯错,我们做的还非常原始。

只有我们更多的关注互联网,更关注程序开发工作,让关键的程序有更多的人来审查和测试,才有可能降低出现错误的概率。但如同其他所有的行业一样,错误和事故却不可能完全杜绝。希望最近这些不断爆出的安全漏洞,能让我们更加严肃的看待软件开发。

参考资料

无觅相关文章插件,快速提升流量