Archive for the ‘Uncategorized’ Category

ZT: 20 Pieces of Programming Wisdom

  1. Set a duration of how long you think it should take to solve a problem – C’mon, admit it! I’m just as guilty as the next programmer. I’ve seen programmers sit in front of a monitor for eight hours at a time trying to solve a particular problem. Set a time table for yourself of 1 hour, 30 minutes, or even 15 minutes. If you can’t figure out a solution to your problem within your time frame, ask for help or research your problem on the Internet instead of trying to be super-coder.
  2. A language is a language is a language – Over time, once you understand how one language works, you’ll notice similarities between other languages. The language you choose should provide you with a suitable “comfort” level, the ability to produce efficient (and clean) code, and, above all, allow the language to suit the project and vice-versa.
  3. Don’t over-”design pattern” applications – Sometimes it’s just easier to write a simple algorithm than it is to incorporate a singleton or facade pattern. For the most part, it even allows for cleaner, understandable code. 🙂
  4. Always backup your code – I’ve experienced a complete hard drive failue and lost a lot of code when I was younger and felt horrible because of what had happened. The one time you don’t back up your data may be the one time where you have a strict deadline with a client and they need it tomorrow. Source code/version control applies here as well.
  5. You are not the best at programming. Live with it. – I always thought that I knew so much about programming, but there is always someone out there better than you. Always. Learn from them.
  6. Learn to learn more – With number five explained, I’ve always had a magazine or book in my hand about computers or programming (ask my friends, they’ll confirm). True, there is a lot of technology out there and keeping up with it is a fulltime job, but if you have a smart way of receiving your news, you’ll learn about new technology every single day.
  7. Change is constant – Your knowledge of technology and/or programming should be similar to how you treat stocks: Diversify. Don’t get too comfortable with a particular technology. If there’s not enough support for that language or technology, you might as well start updating your resume now and start your training period. My general rule of thumb that has kept me going? Know at least two or three languages, so if one dies off, you have another one to fall back on while you train for a new technology.
  8. Support Junior – Assist and train the junior/entry-level developers on good programming guidelines and techniques. You never know…you may move up in rank and you’ll feel more confident having personally trained and prepared them for their next position.
  9. Simplify the algorithm – Code like a fiend, but once you’re done, go back through your code and optimize it. A little code improvement here and there will make support happier in the long run.
  10. Document your code – Whether its documenting a Web Service API or documenting a simple class, document as you go. I’ve been accused of over-commenting my code and that’s something I’m proud of. It only takes a second to add an additional comment line for each 3 lines of code. If it’s a harder technique to grasp, don’t be afraid to over-comment. This is one problem most architects, backup coders, and support groups don’t complain about if you’ve done your job right.
  11. Test, Test, Test – I’m a fan of Black Box Testing. When your routine is finished, your “stamp of approval” period starts. If you have a Quality Assurance department, you may be talking more to them than your project manager regarding errors in your code. If you don’t test your code thoroughly, you may develop more than code. Possibly a bad reputation.
  12. Celebrate every success – I’ve met a lot of programmers who have conquered headache-style problems with a great programming technique and celebrated with a fellow programmer by doing the “shake”, the high-five, or even a “happy dance.” Everyone has enlightening periods in their life and even though that one happy coder asked you to come and see his extraordinary piece of code and you’ve seen that one piece of code over 100 times in your experiences, celebrate the success of a fellow developer for the 101-st time.
  13. Have Code Reviews Frequently – On projects and personally. In the company, you will always have code reviews of how well you coded something. Don’t look at it as people crucifying your coding style. Think of it as constructive criticism. On the personal front, review your code and always ask, “How could I have done it better?” This will accelerate your learning and make you a better programmer.
  14. Reminisce about your code – There are two ways to looking at old code: “I can’t believe I wrote this code” and “I can’t believe I wrote this code.” The first statement is often of disgust and wondering how you can improve it. You’d be surprised at how old code can be resurrected into a possible and better routine, or maybe even an entire product. The second statement is of amazement and achievement. Developers have their one or two project code achievements that they completed and had everyone standing up and taking notice. Again, based on your excellent coding ability, you could take those past routines or projects and update them into a better product or idea.
  15. Humor is necessary – In my 20 years of development, I have never met a programmer who hasn’t had a decent sense of humor. Actually, in this industry, it’s a requirement.
  16. Beware the know-it-all, possessive coder, and the inexperienced coder – Humble yourself when you meet these types of coders. The know-it-all tries to upstage you instead of working as a team player, the defensive coder created code that he doesn’t want to share with anyone, and the inexperienced coder constantly asks for assistance every ten minutes where the finished code developed is yours, not theirs.
  17. No project is ever simple – I’ve been asked by friends, family, and associates to just “whip something up for me.” To “whip” up a program or web site, it takes planning from both parties to complete something that both sides can appreciate. If someone needs a 3-page web site with Microsoft Access from the start, it winds up becoming a 15-page web site with SQL Server, a forum, and a custom CMS (Content Management System).
  18. Never take anything for granted – If you take on a simple project, you may think that a certain section will be easy to complete. Don’t think that even for a moment. Unless you have a class, component, or piece of code already coded…and has been tested thoroughly…and is in production from an existing project, don’t think it will be easy.
  19. Software is never finished – A fellow programmer once told me that software is never finished, it’s “temporarily completed.” Sound advice. If the client is still using a program you wrote and has stood the test of time, chances are, you are still updating it, which isn’t a bad thing. It keeps you working. 🙂
  20. Patience is definitely a virtue – When clients, friends, or family members use a PC, they get frustrated and proceed to hit a component of the PC or storm off. I keep telling everyone, “you are controlling the computer not the other way around.” You need to have a certain level of patience for programming computers. As soon as programmers understand what they did wrong, they look at it from the computers point of view and say, “Oh, that’s why it was doing that.”

Read Full Post »







































你的心里空落落的 ,我感觉你还爱着她,我没信心取代这个位置。她眼红红的,临走还给我一拥抱。















Read Full Post »



如果自己和女孩在一起共事,常常在她的身边,了解她是否单身就不是难题了。可是死理性派们要完成的高难度任务是:作为一个与女孩保持距离的陌生人, 在女孩毫无察觉的情况下,就可以用手头有限的信息判断出女孩的单身情况,不仅如此,死理性派追求的结果一定是量化的,计算出的mm单身概率还要保留两位小 数。

做法是这样的:第一步,要相信直觉。死理性派可以考虑多找几个朋友一起秘密观察一下目标女孩,当然找的人不要都是死理性派,什么心事鉴定组、谣言粉 碎机、自然控、犯罪法医谜最好都找几个来,已婚人士、情场老手、采花大盗也要找一下,人越多越好,越多样化越好。然后大家根据自己对mm的印象从各自的角 度估计一下目标mm单身的概率是多少,投一下票,最后的结果一定会有差异了,仁者见仁,智者见智,可能心事鉴定组觉着女孩单身可能性是90%,谣言粉碎娘 却觉着mm单身只是谣言。死理性派根据这些人平时一贯的靠谱程度,把每个人说出的概率平均一下,原则是平时比较靠谱的人给出的结果考虑的比重就要大一些, 不靠谱的人给的数字就要小一些,假设最后得到的结果是:该女孩单身概率为65.65%,我们就完成了第一步。


就像做科学研究一样,可以先查一下资料,google上随便一搜就可以找到不少寂寞人士多年潜心研究的简单易用的单身判别标准,比如手机原则(恋爱 中的女生手机使用频率会比较高),自习原则(单身的女孩常常和几个女生结伴上自习的话)。之后,在自己身边已经知道是否单身的女孩人群中做一下统计实验, 当然样本越大越好了,得到


当这些“实验数据”都到手了,我们就可以继续了,对刚刚投票出来的概率值65.65%进行修正和优化。依靠的是什么呢? 自然是目标女孩在各项标准上的表现。比如发现目标mm喜欢和朋友一起去上自习,而根据自己的“统计研究结果”:在已经恋爱的mm中,喜欢和朋友一起去上自 习的女孩大约占其中的60%;在没有恋爱的女孩中,喜欢和朋友一起去上自习的女孩大约占其中的30%;




这回mm单身的概率又悲剧地降回了56.02%,死理性派可以去找更多的“评核标准”,做更多的研究,不断更新女孩的单身概率值,让它越来越贴近事 实,不过在得到最后的结果之前,自己要先定一个阈值:女孩单身概率超过这个阈值(比如90%),自己才值得出手表白,否则,还是直接死心吧。

不过要注意的是,不管计算次数多少,得到的终归是一个概率值,不是事实,就算经过多次研究,已经可以将目标女孩的单身概率确定到99.9%,马上就 准备向她表白了,可是在最后一次对女孩的观察研究中,发现人家和一个男生手挽手的有说有笑,拥抱在一起,那么,女孩的单身概率值会立刻从99.9%掉到接 近于0,后果可想而知了……

本文告诉大家的这种判断mm是否单身的科学而严谨的死理性方法称为贝叶斯统计方法。贝叶斯方法简单的说就是“先验概率+新得到的证据=更正后的概 率”,可以不受信息量多少的限制,将各种来源的结果,包括主观判断和有限的客观信息,综合到一起,得到最后的结论。这里严正声明,本方法存在一定风险,尝 试时需谨慎,小朋友就不要尝试了。


1966年1月的一天,美国一架B-52轰炸机在西班牙的帕洛玛雷斯上空飞过,飞机上的几位飞行员在执行着空军司令部安排给他们的空中加油任务。按 理说这次飞行称不上危险,据说机长还是个很淡定的人,没事儿喜欢拿个大烟斗抽两口,甚至在飞机飞行舱里也不例外。可是这一会机长和他的几个部下可遇到大麻 烦了,以后能不能再享用大烟斗都难说了。在一次加油的时候,负责加油的运输机试图从其右后侧方接近B-52轰炸机,以便把柔性输油管送至对方飞机上。两机 速度没有控制好,互相撞擦了一下,这一“亲密接触”不要紧,加油机的油立刻起火爆炸,B-52也被撞的不轻,两架飞机的飞行员当场死的死,跳伞的跳伞……


为了找那一枚丢失的氢弹,美国赶紧从国内调集了包括了多位专家的搜索部队前往现场,其中也包括一位名为John Craven的数学家,头衔是“美国海军特别计划部首席科学家”,既然是特别的,那就不是一般的,Craven博士做的工作到底有什么特别之处呢?

【John Craven】

在寻找氢弹的问题上,Craven提出的方案使用了刚刚提到的贝叶斯方法,他召集了各方面的专家,不过每个专家都有自己擅长的领域,并非通才。有的 对于B-52轰炸机了解甚多,却对于氢弹的特性知之甚少。氢弹如何储存在飞机上是一个问题,氢弹怎么从飞机上掉下来又是一个问题;氢弹会不会和飞机残骸在 一起也没有答案;氢弹上的两个降落伞各自打开的概率是多少?风的流速和方向?氢弹落到地上之后会被埋到土里吗?



Craven得到了从专家那里“招供”的结果后,综合到一起,画了一张氢弹位置的概率图:把整个可能的区域划分成了很多个小方格,每一个小方格有不 同的概率值,有高有低,如同地图上表示山峰和山谷的等高线一样。像判断女孩是否单身的死理性派们一样,Craven完成了贝叶斯方法的第一步。

之后,Craven和搜索部队的指挥官一起开始了对氢弹的搜索,在搜索的过程中同时对每个格子的概率进行更新,不过,概率最大的方格子指示的位置常 常是陆地上险峻的峡谷和深海区,即使氢弹真的在那里,也未必找得到,所以需要绘制另一张概率图,表示“氢弹已经在那里,能找到的概率”而不是氢弹位置的概 率。最后氢弹被找到,Craven的两张概率图和他的贝叶斯方法发挥了不小作用。



为了寻找天蝎号的位置,美国海军进行了大规模的搜索,Craven自然也参与其中。由于失事时潜艇航行的速度快慢,方向,爆炸冲击力的大小方向,爆 炸时潜艇方向舵的指向都是未知量,即使知道潜艇在哪里爆炸,也很难确定潜艇残骸最后被海水冲到哪里。Craven初略地估计一下,在半径20英里的圆圈内 的海底,天蝎潜艇都有可能躺在那里,要在这么大的范围内、这么深的海底找到潜艇几乎成了不可能完成的任务。

没有专家能准确的估计到,在出事前后潜艇到底发生了什么,和搜索氢弹的时候一样,Craven咨询了数学家、潜艇专家、海事搜救各个领域的专家,编 写了各种可能的“剧本”,让他们按照自己的知识和经验对于情况会向哪一个方向发展进行猜测。据说,为了给枯燥的工作增加一些趣味,Craven还准备了威 士忌酒作为“投注”正确的奖品。

最后,Craven得到了一张20英里海域的概率图。整个海域被划分成了很多个小格子,每个小格子有两个概率值p和q,p是潜艇躺在这个格子里的概 率,q是如果潜艇在这个格子里,它被搜索到的概率。按照经验,第二个概率值主要跟海域的水深有关,在深海区域搜索时失事潜艇“漏网”的可能性会更大。如果 一个格子被搜索后,没有发现潜艇的踪迹,按照贝叶斯原理更新后,这个格子潜艇存在的概率就会降低:



最初的时候,海军人员凭经验估计潜艇是在爆炸点的东侧海底,对于Craven和其它数学家的建议嗤之以鼻,但是几个月的搜索后一无所获。后来海军不 得不听从了Craven的建议,按照概率图,失事后的潜艇应该在爆炸点的西侧。经过几次搜索,潜艇果然在爆炸点西南方的海底被找到了。

经过两次给力的表现,Craven在海事搜索中使用的贝叶斯方法逐渐被广为接受,从此,贝叶斯方法意想不到地常常和氢弹、核潜艇一起成为关键词在各 处出现。几十年间,贝叶斯方法应用越来越广泛,从google搜索筛选词条到无人驾驶汽车综合判断自己的行驶位置,钻进了各个角落。当然,这个神奇的方法 用在追女上实在是大材小用了。


Read Full Post »

ref: http://community.topcoder.com/tc?module=Static&d1=tutorials&d2=planApproach1

Here’s your first exercise: take any problem in the Practice Rooms that you
haven’t done. Fight through it, no matter how long it takes, and figure it
out (use the editorial from the competition as a last resort). Get it to
pass system tests, and then note how long you took to solve it. Next, clear
your solution out, and try to type it in again (obviously cutting and
pasting will ruin the effect). Again, get it to pass system tests. Note how
long it took you to finish the second time. Then, clear it out and do the
problem a third time, and again get it to pass system tests. Record this
final time.

The time it takes for your first pass is how long it takes you when you have
no expectations of the problem and no approach readily in mind. Your time
on the second pass is usually the first time minus the amount of time it
took you to understand the problem statement. (Don’t be surprised at the
number of bugs you’ll repeat in the second pass.) That final recorded time
is your potential, for you can solve it this fast in competition if you see
the correct approach immediately after reading it. Let that number encourage
you; it really is possible to solve some of these problems this quickly,
even without super fast typing ability. But what you should also learn from
the third pass is the feeling that you knew a working strategy, how the code
would look, where you would tend to make the mistakes, and so on. That’s
what it feels like to have the right approach, and that feeling is your goal
for future problems in competition.

In most martial arts, there’s a practice called kata where the martial
artist performs a scripted series of maneuvers in order, usually pretending
to defend (or sometimes actually defending) against an onslaught of fighters
, also scripted to come at the artist predictably. At first this type of
practice didn’t make any sense, because it didn’t seem realistic to the
chaotic nature of battle. Furthermore it seems to encourage the type of
pattern mining mentioned in the previous section. Only after triple-coding
many problems for a while can one comprehend the true benefit of this coding
kata. The kata demonstrates to its practitioners the mental experience of
having a plan, encouraging the type of discipline it takes to sit and think
the problem through. This plan of attack is your approach, and it carries
you through your coding, debugging, and submission.


Read Full Post »


– 即使你名花有主,我也要移花接木,行吗?

– 為什麼我這麼帥 難道是命運的安排?哦,我的天哪 每天都被自己帥醒 鸭梨真的好大!我急死了,我该怎么办?

– 住在我心里,你交房租了吗?

– 我颠倒了整个世界,只为摆正你的倒影。

– 等哥这次挣钱,咱买棒棒糖。买两根,一根你看着我吃,另一根,我吃给你看。

– 有福同享,有难同当。大大泡泡糖,迷你真知棒。

– 你不要这么悲观,用扯蛋的态度,面对操蛋的人生。那是行不通的。

– 如果不是哥长年潜水,变得这么有深度有内涵,早变成蝴蝶飞走了。

– 真相会让我们痛苦一阵,谎言会让我们痛苦一生。

Read Full Post »


Read Full Post »

Stevey’s Google Platforms Rant

I was at Amazon for about six and a half years, and now I’ve been at Google for that long. One thing that struck me immediately about the two companies — an impression that has been reinforced almost daily — is that Amazon does everything wrong, and Google does everything right. Sure, it’s a sweeping generalization, but a surprisingly accurate one. It’s pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn’t let me show it to anyone, even though recruiting loved it.

Read Full Post »

Older Posts »