KEEP K.I.S.S.

tk's blog

<转载>我的一些“偏见”

转自:庄周梦蝶
作者:dennis

    在豆瓣发了一些牢骚,索性多说一些我个人对人对事的偏见,既然是偏见,就不会让人舒服,事先声明是扯淡,不想浪费时间的人略过。

1.我们要远离新浪微博,新浪微博跟twitter不一样,twitter是为了让每个人的信息的更好更快地传播而设计的,而新浪微博是为了让权威的声音更好更快地传播而设计的。迷恋上新浪微博,你要么是权威,要么是跟随权威。成为权威的,免不了沾沾自喜,真以为自己成了“权威”。更可怕的是你不可避免地要生活在相互吹捧和喧嚣中。

2.在编写代码之外,我们可能需要更多的手艺傍身,例如木匠或者厨师,以免在乱世的时候因为不需要程序员而饿死。ps.计算弹道轨迹的程序员除外。

3.据说真正的牛人从不跳槽,作为大多数不是牛人,以及已经远离牛人行列的我们(跳槽超过3次以上),跳槽仍然是你提升自己的有效途径,无论是薪水还是技术。

4.写简历的技巧,我慢慢领悟到了,少点技术术语,多点成效和应用,打动了HR过了第一关之后,再去跟技术人员扯淡。

5.简历要定时更新,你可以理解成定时提醒下猎头和HR,关注我啊,关注我啊。

6.强烈地拥抱文本化,配置文本化(没人会脑残地用二进制当配置文件吧?),协议文本化,婚姻文本化。

7.一切不以加薪为目的的挽留,都是耍流氓,这不是我的原创。

8.有趣比实用重要,没趣味的东西,给钱也不去做(好吧,我说假话)。

9.对新潮的东西保持一点警惕,如果这个东西三个月后还有人在谈论,那可以关注下

10.代码永远比文档、博客真实和靠谱,阅读代码习惯了,跟阅读文档没啥区别。

11.少关注博客和新闻,戒掉看google reader的习惯。现在更多地看maillist上的讨论和问题,真正重要的东西你永远不会错过。

12.不追求完美,等你完美的时候别人已经是事实标准。

13.大型的技术聚会不是为技术人员准备的,这是大公司给员工的度假福利和领导们的吹水时间。只有在小型的技术聚会上才能看到一些有价值的东西,任何稍微跟商业沾一点边的几乎都没有太大价值,我说的是国内。

14.80%的分享都只对演讲者有益,该sb的还是sb,该牛b的还是牛b。最有效的分享是结对编程和结对review。分享和培训最大的意义是让行政们觉的自己的存在价值很大。

15.国内翻译国外经典>国内原创精品>国外原版,这个原则对英语好的人除外。

16.极其讨厌要求强制缩进的语言,比如python。

17.标榜是一种人生态度,装B装久了你就真牛B了。

18.凭啥不造轮子,你们造轮子舒坦了,爽快了,就不让别人造了。我造轮子我快乐。

19.偏见不全是坏事,坏的是不愿意改变偏见。


    扯淡时间结束。

 

Simple, not simpler

好久没有写小结型的文章了,主要是这段时间以来感觉自己稍微有些混乱,思绪繁飞不得掌控。

这段时间主要是看《代码大全》(第二版),内容很细致,包括从思路设计到实际编码各个环节,有很多常用的技巧以及注意事项。

开始看 Lua 的相关书籍了,这主要是受到最近一直泛起的“simple”的思绪,渴望回归“简单”。《Programming in Lua》这书很不错,目前看到 chapter 7,重大的收获是 对于函数式编程的的一些较深的理解,比如 closure 和 tail call。

之前学习的 Ruby 在目前工作中最主要的用途还是 正则表达式,用来处理文本数据。主要是自己弱爆了,不想去学 grep,sed 这些更为适合的工具,不过好在 Ruby 用的也是 Perl 风格的正则表达式。Ruby 的主张是 Coding for fun, Ruby 很容易学,也很容易用,主要是因为 面向对象设计完全和多种多样的方法风格。我现在就主要靠 irb (Interactive Ruby Shell) 来做计算器,功能强大,方便实用。 [Θ▽Θ]

交叉看的其他一些书籍有《代码整洁之道》(看书名就知道是干嘛的了,书中的语气措辞我比较喜欢,偏激进)、《深入理解计算机系统》(真的是“深入”,好书不需要解释,看完前言估计你就很有胃口了)、《OpenGL 超级宝典》(偏向工具库方面。。。)

当前最大的问题是心态噪杂,难以平复,想沉浸如那种简简单单的状态却感到困难。看来自己当前悟性还是不够,也许是自己太过心急了。

贴一句爱因斯坦的话共勉:Make things as simple as possible, but not simpler.

对于断言 ASSERT 的理解

昨天看了《代码大全》的“防御式编程”章节,解惑了长期以来自己对于断言的理解。

书中给了使用断言的指导意见,如下

  1. 用错误处理代码来处理预期会发生的状况,用断言来处理绝不应该发生的状况。
  2. 避免把需要执行的代码放到断言中
  3. 用断言来注解并验证前条件和后条件
  4. 对于高健壮性的代码,应该先使用断言再处理错误
其中有一段话,很清晰地说出了断言的典型使用情况:
对来源于内部系统的可靠的数据使用断言,而不要对外部不可靠的数据使用断言,对于外部不可靠数据,应该使用错误处理代码。断言可以看成可执行的注释。
系统外部的数据(用户输入,文件,网络读取等等)都是不可信的,需要严格检查(通常是错误处理)才能放行到系统内部,这相当于一个守卫。而对于系统内部的交互(比如子程序调用),如果每次也都去处理输入的数据,也就相当于系统没有可信的边界了,会让代码变的臃肿复杂;而事实上,在系统内部,传递给子程序预期的恰当数据应该是调用者的责任,系统内的调用者应该确保传递给子程序的数据是恰当可以正常工作的。这样一来,就隔离了不可靠的外部环境和可靠的系统内部环境,降低复杂度。
 
但是在开发阶段,代码极可能包含缺陷,也许是处理外部数据的程序考虑的不够周全,也许是调用系统内部子程序的代码存在错误,造成子程序调用失败。这个时候,断言就可以发挥作用,用来确诊到底是那部分出现了问题而导致子程序调用失败。在清理了所有缺陷之后,内外有别的信用体系就建立起来。等到发行版时候,这些断言就应该没有存在必要。
 
附一个C++可以用的自定义断言
#ifndef _ASSERT_EX_H
#define _ASSERT_EX_H

#include <stdlib.h>
#include <stdio.h>

#ifdef _DEBUG
#define _ASSERT(exp, message) { \
if (!(exp)) {		\
        fprintf(stdout, "Assertion failed: \"%s\"\nMessage: \"%s\"\nline: %d\nfile: \"%s\"\n", \
                #exp, message, __LINE__, __FILE__); \
	exit(EXIT_FAILURE);						\
	 }     \
}
#else
#define _ASSERT(exp, message)
#endif

#endif //_ASSERT_EX_H
 

感慨一下

今天继续看了点SICP的内容,有个习题有点难度就网上搜索了下,又发现了一个牛人的博客。

链接在此:http://www.blogjava.net/killme2008

不管是涉及的领域知识,还是写文章的态度,都是很值得佩服的。

他的文章列表已经52页了!!! 基本上是从 07年到现在的,不得不佩服至极。

坚持做一件事情,也是一种强大的力量。

不应如此

最近越来越感到一种恐惧,对于自已选择的领域。

学编程这么久,真的没有拿过一个特定领域来仔细钻研,都是泛泛的涉猎。

程序真的只是个工具而已,没有应用领域的话,各种奇淫逸巧也不过是镜月水花。

自己该好好反思一下了。

是不是走入了一个死胡同。