技术读物

对于程序开发者来说，有两种技术需要我们掌握，一个是技术上的能力，另一个是非技术上的能力。不幸的是，许多程序员过多地关注了技术上的能力，而忽略了非技术上的能力的培养，因此，我们的程序员们经常会有一些很不好的习惯，这里我们例举了程序员们最常犯的5个非技术的错误，与大家共勉。 目录 1.- 缺乏团队纪律 2.- 过度自负 3.- 沟通不畅 4.- 忘了用户 5.- 不懂工作的轻重缓急 1.- 缺乏团队纪律 “Discipline is the bridge between goals and accomplishment.” Jim Rohn. 纪律是一个最有价值的技能，不仅仅只是在软件开发领域，同样在其它领域也是一样的。但对于现实来说，我们很难找到即有才华又有纪律的人。这正如足球队一样，非洲的球员们才华相当的出众，可惜他们总是独自为阵，团队纪律性不足，所以可以有好的成绩，但却无法赢得最后的胜利；而德国队的队员个人技能平平，但其有很强大的团队纪律性，所以，总是能打入最后的决赛并获得冠军 ...

题外话：剑桥大学出版社很有意思，允许作者把书的全部内容放在网上，例如：Christopher D. Manning, Prabhakar Raghavan and Hinrich Schütze, Introduction to Information Retrieval, Cambridge University Press. 2008. 《搜索的用户界面》的作者Marti Hearst是加州大学伯克利分校研究信息可视化的一位大儒，她有很多带有认知心理学加设计的尝试，在信息检索这门学科里的信息可视化领域很有地位。我斗胆把她的新书的梗概在这里描述一下，习惯看英文的朋友们可以点击链接去看英文原文，不喜欢看英文的朋友们可以有选择的看看我这里的总结，然后硬硬头皮，跳进去啃一些具体章节吧。本书可能收益的人有：对搜索有兴趣的学生，工业界做设计和评估的专业人士，对技术中的人本主义感兴趣的人，书痴。 译文：本书综述 本书概括了信息寻找过程中人的方面，并专注于其中被用户界面可以支持的方面。本书描述一些用户界面的一般方法论，尤其是搜索的用户界面以及如何评估好的搜索界面。本书 ...

虽然这样的文章非常的多，并且，就算是对于编程新手来说，也是非常的简单和显而见，但是，在我们进行Code Review过程中，我们还是能够看到那些非常混乱的代码，所以，有些时候，你会在想，是不是这样的规则太多了，导致我们的程序员记不住。虽然我们在以前的文章中一遍又一遍的说过（比如：《优质代码的十诫》），千言万语总结一下，无论你用什么样的语言，最最基本的编程原则就是下面这四条。 1 – 简短的方法 简单才会易读，简单才会容易，简单才能重用，简单才能保证质量。把一件事搞复杂，是一件简单的事；而把一件事变简单，这则是一件复杂的事。KISS-Keep it Simple Stupid是一种哲学，Do one thing, Do it best也是一种哲学。这些都是在告诉我们，做设计，做产品，不要把所有的东西一下子都考虑进来，否则将会让你的事情变成一团糟，剪不断理还乱，就是这样道理。把复杂的事情，困难的事情，逐步细化，分解成一个一个简单而单一的事情，然后再把他们拼装起来完成一个复杂的事情，是我们如何完成一个巨大并复杂的项目的通用方法。 编程也是这个道理，维护代码的成本会比你创造代码的成本要大得 ...

本文源自这里，文中列出了全球前200名的开发者的BLOG。有的可能你很熟悉，有的你可能还不知道。这些BLOG的排名通过查看，Google PageRank, Technorati Authority, Alexa Rank, Google links, Twitter Grader Rank等等，形成的综合排名。如果你对此感兴趣的话，你可以看看这篇文章——《如何制作一个Blog排名》 下面是前200名的排名。希望对那些有日常浏览Blog习惯的人有帮助。大家可以下载更为详细的Excel表格。 本排名截止至：2009年第二季度 其中：TT = This Time 本次名次LT = Last Time 上次名次 TT LT Blog Author Twitter 1 6 Scott Hanselman’s Computer Zen Scott Hanselman shanselman 2 2 Coding Horror Jeff Atwood codinghorr ...

之前本站发表过《优秀程序员的十个习惯》以及《程序员需要具备的基本技能》，那是我们需要去学习和培养的。这里，我们主要讨论十个糟糕程序员的特征，主要是需要让我们去避免和小心的。 1) 情绪化的思维 如果你开始使用不同颜色的眼光来看待这个世界的话，那么你可能会成为一个很糟糕的程序员。情绪化的思维或态度很有可能会把自己变成一个怪物。相信你经常可以看到很多很糟糕的程序会使用下面的这些语句： 我的程序不可能有这种问题。 Java就是shit。 我最恨的就是使用UML做设计。 需求怎么老在变，没办干了。 受不了这些人，他们到底懂不懂啊。 …… …… 这些带着情绪化的思维和态度，不但可以让你成为一个很糟糕的程序员，甚至可以影响你的前途。因为，情绪化通常都是魔鬼，会让你做出错误的判断和决定，错误码率的判断和决定直接决定了你的人生。 2) 怀疑别人 糟糕的程序总是说：“我的代码一定是正确的，我怀疑编译器有问题”，“我这应该没有问题吧，STL库怎么这么难用啊”。我曾经见过有程序员这样使用STL类：map<char*, char*>，当他发现这样放入字符串后却取不出来，觉得那是 ...

质量管理在软件工程中是非常非常重要的一个环节，无论你有多么精妙的算法，或是使用了多么先进的技术，还是拥有了多少强的设计，在质量控制或质量管理面前，这些都可能什么都不是。这里，有一些质量管理的法则，可以让软件的用户从中受益。如果对质量管理一言以蔽之：面对一个长期不断需要改善的软件，当其用户或是管理者们来说，他们对某个组织所提供的标准有一种完全和最基本的信任。 下面，我们给出8个质量管理的法则： 1. 始终从用户角度出发: “无论何时何地，我们都需要明白用户当前的或未来的需求，并能够达到用户的需求，甚至超出用户的期望。” 这是整个软件工程的重中之重。质量管理从某种意义上来说，就是实现用户需求的质量的管理。这需要我们的质量管理管理和用户的关系，以及把用户的需求和整个团队（开发组，测试组，产品组，项目组等等）进行有些的沟通管理。 2. 领导能力: “领导者需要建立一个团结统一的有明确方向的团队。这个团队可以创造并维护一种良好的内部气氛，这种氛围可以使得所有的人都能参与进来，从而达到整个团队的目标。” 对此，我们需要有一个有前瞻性的领导能为整个团队创建一种相互信任的环境。提倡诚实，并积极引导 ...

下面的这些经典的引言来自英文，也许有些我翻译的是不很好，所以，我提供了中英对照，如果有问题，请大家指正。   过早的优化是万恶之源。Premature optimization is the root of all evil!– Donald Knuth   在水里行走和以一个需求规格进行软件开发，有一点是相同的，那就是如果水或需求都被冻住不了，那么行走和软件开发都会变得容易。Walking on water and developing software from a specification are easy if both are frozen– Edward V Berard   Hofstadter 定理：“一件事情总是会花费比你预期更多的时间，就算是你已经考虑过本条Hofstadter 定理”。It always takes longer than you expect, even when you take into account Hofstadter’s Law.– Hofstadter’s Law   有些遇到问题 ...

这是一本关于编译器设计原理的书，让我又想起了大学时的《编译原理》还有那长篇长篇的作业，以及几个方法分析器的上机实习。现在基本上都全部还给老师了。 Basics of Compiler Designhttp://www.diku.dk/hjemmesider/ansatte/torbenm/Basics/ PDF下载

英国权威消费数码杂志T3评出了有史以来十大最失水准的科技预测。比尔·盖茨也占了其中2项。预测未来的确是一件很难的事情，即便是最聪明的人也会马失前蹄。 1.  下一个圣诞节，iPod将会死去，完蛋，过时。 Allan Sugar爵士（一个很著名的英国企业家，和BBC合作一个著名的节目《学徒》）, 2005.2.  家庭不需要有一台电脑。  Ken Olsen, Digital Equipment简称DEC的创始人, 1977. 3.  核能吸尘器将在10年内成为现实。  Alex Lewyt（真空吸尘器公司Lewyt Corp的CEO）, 1955. 4.  电视不可能兴盛起来，因为人们“很快就会因为每晚盯着一个胶合板盒子而感到厌烦”。 Darryl Zanuck（ 好莱坞多栖明星）, 1946. 5.  1933年，在可容纳10名乘客的波音247首航之后，一名自豪的波音工程师曾表示：“永远不可能制造出比247更大的飞机”。 Boeing engineer, 1933. 6.  我们已处在 ...

此文来自Marshall Goldsmith的博客，此人曾任Peter Drucker Foundation 的Board  member（实在不知道怎么翻译），49年出生，生平中是一系列管理学方面的成就，是一位罕见的高产的，大师型的博主。 显然，我所翻译的标题有些夸张（原标题是“spotting the uncoachables”）。 职场上除了职位所确立的关系之外，还有一种重要的关系，那就是“师徒关系”。如果幸运，大家会遇到有人愿意 coach 自己，给自己传递技能或者指点职场之道。等我们在一个地方呆久了，也会有时候 coach 一些新入道的同事，甚至有时候为了达到团队目的，需要用自己的经验和技能影响自己的同僚。 此文提到的了4种很难coach的情形，大家可以拿来参考。但是这并不代表我们遇到觉得“朽木不可雕也”的人的时候就应该彻底放弃。如果我们无可避免的需要影响他们的行为，我们需要更有技巧的选择自己的方式。 四类不可coach的人： 自己并没意识到有任何问题的人 其努力方向和公司战略相左的人 入错行的人（也许我们应该引导他们去发现自己才能所属的领域） ...

OpenESB项目实现了一个运行期企业服务总线(Enterprise Service Bus:ESB)使用JBI(Java业务集成)作为核心基础。OpenESB可以让你集成企业应用与Web Service松散地连接成复合的应用程序。这使得你可以无缝地组合与拆解该复合应用程序，并认识到一个真正面向服务架构(SOA)的优点。 BPEL是一种编程语言，它明确定义了基于Web服务的业务流程。BPEL在支持业务伙伴间的长时间会话方面表现尤为卓越。BPEL将成为基于Web服务的业务流程最广泛采用的标准，这一趋势早在该标准正式发布前就已经非常明显。 BPEL适用于支持业务流程逻辑的“宏观编程”。这些业务流程均是完整而独立的应用，它们将Web服务作为实现其业务功能的“活动”。BPEL不致力于成为通用的编程语言，相反，它的应用设想就是与其他实现业务功能（“微观编程”）的编程语言结合使用。 OpenESB上有一些BPEL教程都是非常有趣的，下面一些教程的例子： http://wiki.open-esb.java.net/attach/OpenESBIntroductionTutorial/openes ...

下面的这些排名并不是非常科学的，它们只是从某种方面表现出了编程语言的流行程度。仅供参考。 Yahoo Search 这里，我们使用了Yahoo Search API，简单地搜索了一下相关的编程语言。收搜字样是”language programming”，下面是搜索到的页面结果。也许这能够说明语言的流行程度。 　　 工作相关 接下来，我们来看看与工作相关的页面。也是从Yahoo Search API中从Craigslist.org网站中取得这些数据。搜索模型如下：language programmer -“job wanted” site:craigslist.org。这个结果可以看到全球的雇主在雇佣技术人员的时候所要求的编程语言的数量分布。 　　 技术书籍 下面是由Amason所提供的搜索API中得到的目前出版物中的编程语言相关的统计数据，一般来说，越流行的语言通常会有更多的书籍。我们来看看书籍方面的各语言的书籍数量的排行榜。 　　 Google Code 开源项目 下面的结果取自Googel Code (http://www ...

MyISAM 是MySQL中默认的存储引擎，一般来说不是有太多人关心这个东西。决定使用什么样的存储引擎是一个很tricky的事情，但是还是值我们去研究一下，这里的文章只考虑 MyISAM 和InnoDB这两个，因为这两个是最常见的。 下面先让我们回答一些问题： 你的数据库有外键吗？ 你需要事务支持吗？ 你需要全文索引吗？ 你经常使用什么样的查询模式？ 你的数据有多大？ 思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引，那么通常来说 MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从InnoDB中获得全文索引。 数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要几个小时甚至几天来干这些事，InnoDB ...

下面是14件如何有效编程的方法： 目录 计划(Plan) 使用伪代码 书写清楚的注释 使用自动的编辑工具 减少代码 代码重用 代码重构 使用设计模式 使用程序框架Framework 泛型编程 使用开源的代码 完善开发环境 使用调试器 使用版本管理工具 计划(Plan) 所谓Plan，其实就是对应于编程中的“设计”阶段，当然，这里的Plan并不像设计那样重量级。它要求我们程序员在正式编程前至少要考虑一下下面的问题： 你这个程序，工具或是项目的目的，究竟是用来干什么的。你只有知道做什么，要达到什么样的目的，你才能做得对，做得好。 需要有什么样的功能。需要你给出来个功能列表。这样可以保证我们不会遗露了什么。 准备好一些技术难题的前期调查和解决方案。不要等到开始编程的时候才去想。 下面这你因为有“Plan”而得到的好处： 你 ...

这个是一本关于CORBA技术的中文文档，原文是Ciaran McHale《CORBA Explained Simply》，我将其翻译成中文形式，并首发在酷壳之上，现在先提供一个PDF的文件形式下载，关于html形式的下载或在线阅读形式以后再慢慢整理。CORBA有可能是一门将要过时的技术，但是它的思想却仍然被当今一些流行的分布式架构所借鉴。所以通过学习CORBA，也许我们可以更好的去理解EJB，去理解Web Service，或者SOA…… 译序 从wiki上找到此书的链接，初读之下，感觉此文讲解的非常清楚，大量丰富的图例说明，于是就有了将此书翻译成中文的冲动。至于书名本应该是《简单地解释CORBA概念》，但是最后还是起了一个比较容易吸引人眼球的标题。 本书原文行文非常流畅，用词也相当通俗易懂，建议有英文基础的同行直接阅读原文。 本书第二十三章的内容，涉及到安全的一些概念和术语，翻译也相对比较困难，我虽然给它翻完，但是最后还是不敢发布出来，因为此章需要对安全相关知识要有全面的理解，最后我将此章翻译的内容省略。 在翻译过程，有一些特殊的名词采用意译的方式，比如IDL的 ...

由于最近经济形势的变化，很多开发人员只关注他们短期的工作前景。与此同时，把时间和精力花在学习最能带来回报的新技术上是件非常重要的事情。这里是我们列举的10种你需要马上开始学习的技术，让你的简历在未来5年不会落伍。这个列表并不完全，有很多业界的领域（比如大型机开发人员）没有涉及。尽管如此，对通常的主流开发来说，学习其中至少7项技能肯定不会错 ——不但要达到能在面试时侃侃而谈的程度，还得能在工作中运用自如。 1) 编程语言三选一 (.NET, Java, PHP) 除非开发世界有根本的改变（类似小行星击中雷德蒙），在不远的将来，大部分开发人员将需要了解三大开发平台——.NET (VB.NET或者C#), Java, 或者PHP——中的至少一个。并且只了解核心语言也是不够的。因为项目会包含越来越多不同的功能，你需要对相关框架和库有深入的了解。（本人以为C/C++可能比这三个语言更有竞争力） 2) 互联网Rich Application (RIAs) 不管爱她还是恨她，最近几年，Flash的用途突然间不仅仅是制作政治人物弱智歌曲演唱动画而已了。Flash也萌生出了以Fle ...

软件开发是一个跨度很大的技术工作，在语言方面，有C，C++，Java，Ruby等等等等，在环境方面，又分嵌入式，桌面系统，企业级，WEB，基础系统，或是科学研究。但是，不管是什么的情况，总是有一些通用的基本职业技能。 这些最基本的职业技能通常决定了一个程序员的级别，能否用好这些技能，直接关系到了程序员的职业生涯。很多程序新手也是因为缺少、达不到或是不熟悉在这些基本技能，所以，他们需要有老手带，需要努力补齐这些技能。而高级程序员应该非常熟悉这些基本技能，而且有能力胜任并带领其他经验不足的程序员。 下面这些基本职业技术可以用来做为对一个程序员的评估，很明显，下面的这些技能都可以用来做面试。虽然，还有很多非技术的因素，但对于评估一个程序员的技术能力来说，其应该是足够的了。 下面是程序员所应该具备的基本职业技能： 基本技能 技能描述 阅读代码 这个技能需要程序员能够具备读懂已经存在的代码的能力，这样的能力可以让程序员分析程序的行为，了解程序，这样才能和开发团队一起工作，继承维护或是改进现有的程序。 编写程序 编写程序并 ...

Computer World上有人评出了有史以来十大臭名照著的操作系统，我们来看看倒底有那些，顺便也回顾一下操作系统的历史。下面的顺序通过时间顺序由古至今。 目录 OS/360, 1964 ITS(Incompatible Timesharing System), 60年代后期 GNU Hurd, 1983启动，至今也没有完成 Windows 1.01, 1985 MS-DOS 4.0, 1988 SCO Open Desktop, 1989 JavaOS, 1996 Windows Me (Millennium Edition千禧版), 2000 Lindows/Linux XP Desktop, 2001/2006 Windows Vista, 2006 OS/360, 1964 这里，说的不是后面新版的OS/360，这里说的是60年代未70年代初的第一版的OS/360。当时的Project Manager，Fred Brooks， 《人月神话》 The Mythical Man-Mo ...