“菜鸟”和“大神”刚刚走出就业的程序员，技术是刚刚起步的基点。那下面我们就聊一聊有关技术的东西。首先请您先想想这几个问题。现在社会上有很多程序员，CSDN就是我们程序员的家，那您是否可想过程序员为什么会有不同的水平？你又是哪一类的程序员？“菜鸟”程序员和“大神”程序员差在哪里？真是差在技术上了吗？那不是差在技术上那差在了哪里？
上面很多一连串的问题，没有把你搞晕吧！那就听我一一给您分析这个问题背后的答案。确切的说程序员分为“菜鸟”程序员和“大神”程序员。
一个程序员有多优秀，就得看他写的代码！程序员自己的代码才是自己工作状态的真实体现。
“菜鸟”程序员和“大神”程序员到底有什么区别哪，那我们就来看看。
代码的展现，网络的应用展现题目：一个很小的功能，比如说一个当鼠标移动到一个标题下，在下面显示其可选菜单。
“菜鸟”程序员的代码是什么样子，自己想一下。“菜鸟”程序员的代码往往会会写的比较冗余，而且这些代码不是从书上找来的就是从网上找来的还有可能就是自己会这一部分代码（仅存记忆的提取，真正的原理似懂非懂，好像雾里看花）。
“大神”的代码会写成什么哪？“大神”程序员的代码，当你看的第一眼：简 ...
gzdd
未读我的同事朋友Chris Eargle写了一篇关于新年计划的有趣文章。他让我想到了，没有出现那场世界末日是我们多么大的幸运呀(还有其他我这45年中躲过的天灾)，于是，我也有了一些我自己的以程序员为主题的新年计划。
我的同事朋友Chris Eargle写了一篇关于新年计划的有趣文章。他让我想到了，没有出现那场世界末日是我们多么大的幸运呀(还有其他我这45年中躲过的天灾)，于是，我也有了一些我自己的以程序员为主题的新年计划。
找到一名导师/成为一名导师
在你的职业生涯中，你能做的会给你带来最多麻烦的事就是成为屋里最聪明的人。我说的并不是你坚信自己你就是屋里最聪明的人。我的意思是你成为团队里真正的万事通。问题终结者。终极疑难解答者。
于是，这就有了另外一个问题：你有疑问了去问谁呢？
如果你的回答是“谷歌”，那你是不思进取。去到那些你认识的(或不认识的)最聪明的人中间去。参加你们的本地社团。去你们本地的编程活动中发言，去和其他的讲演者一起喝酒聊天。找那些你可以接触到的人，让他们成为你的导师。
找到一名导师
我在生活中有好几位导师。他们是我尊敬的人和能让我轻松问问题的人。有些人甚至非常 ...
一、结构介绍高层结构图：
wrappers包：
handlers包（部分）:
二、功能介绍commons.dbutils是一个对JDBC操作进行封装的类集，其有如下几个优点：
（1）没有可能的资源泄漏，避免了繁锁的JDBC代码
（2）代码更整洁
（3）从ResultSet自动生成JavaBeans属性
（4）无其他依赖包
三、基本使用基本用到的类有：QueryRunner、ResultSetHandler及其子类等
QueryRunner – 执行查询的类，可以执行SELECT、INSERT、UPDATE、DELETE等语句，QueryRunner用ResultSetHandler的子类来处理ResultSet并返回结果；而包提供的ResultSetHandler子类使用RowProcessor的子类来处理ResultSet中的每一行；RowProcessor的默认实现为BasicRowProcessor；BeanProcessor不是RowProcessor，可以看作一个工具类
ResultHandler及其子类 – 实现了Object handle(ResultSet rs) ...
从上百幅架构图中学大型网站建设经验（上）
引言近段时间以来，通过接触有关海量数据处理和搜索引擎的诸多技术，常常见识到不少精妙绝伦的架构图。除了每每感叹于每幅图表面上的绘制的精细之外，更为架构图背后所隐藏的设计思想所叹服。个人这两天一直在搜集各大型网站的架构设计图，一为了一饱眼福，领略各类大型网站架构设计的精彩之外，二来也可供闲时反复琢磨体会，何乐而不为呢?特此，总结整理了诸如国外**wikipedia，Facebook，Yahoo！，YouTube，MySpace，Twitter**，国内如**优酷网**等大型网站的技术架构（本文重点分析优酷网的技术架构），以飨读者。
本文着重凸显每一幅图的精彩之处与其背后含义，而图的说明性文字则从简从略。ok，好好享受此番架构盛宴吧。当然，若有任何建议或问题，欢迎不吝指正。谢谢。
1、WikiPedia 技术架构
WikiPedia 技术架构图Copy @Mark Bergsma
来自wikipedia的数据：峰值每秒钟3万个 HTTP 请求 ...
java
未读Java 的性能有某种黑魔法之称。部分原因在于 Java 平台非常复杂，很多情况下问题难以定位。然而在历史上还有一种趋势，人们靠智慧和经验来研究 Java 性能，而不是靠应用统计和实证推理。在这篇文章中，我希望拆穿一些最荒谬的技术神话。
1.Java 很慢关于 Java 的性能有很多谬论，这一条是最过时的，可能也是最为明显的。
确实，在上世纪 90 年代和本世纪初处，Java 有时是很慢。
然而从那以后，虚拟机和 JIT 技术已经有了十多年的改进，Java 的整体性能现在已经非常好了。
在 6 个独立的 Web 性能基准测试中，Java 框架在 24 项测试中有 22 项位列前四。
尽管 JVM 利用性能剖析仅优化常用的代码路径，但这种优化效果很明显。很多情况下，JIT 编译的 Java 代码和 C++ 一样快，而且这样的情况越来越多了。
尽管如此，依然有人认为 Java 平台很慢，这或许源自体验过 Java 平台早期版本的人的历史偏见。
在下结论之前，我们建议保持客观的态度，并且评估一下最新的性能结果。
2. 可以孤立地看待单行 Java 代码考虑下面这行短小的代码：
MyObjec ...
gzdd
未读导读：本文是从《Great code is written twice (or more)》这篇文章翻译而来。
文章内容如下：
最近这些年，越来越多的人开始转向敏捷开发。各种敏捷开发技术并不新鲜，大多是在80和90年代发展形成。但只是在最近这些年，程序员和（更重要的是）一些商业顾问，架构师，客户开始变得喜欢和拥抱敏捷开发。
进化中的需求
现在的一种普遍的认识是，在开始编码前，你不可能把所有的需求都写完备。这些需求的确定是一个逐渐发展进化的过程。使用短开发周期/springts，我们一步步的开发程序，使用多次迭代的方式完成从客户方得到的最新需求。这些都是基于一个进化的思想。就像生活中，我们总是通过一步步的改进来达到最好一样。
进化中的代码！
可是，这就完事了吗？如今大部分的程序员都认识到了需求必定是一步步的挖掘出来的。但他们却忘了自己的工作！？他们仍然认为他们的框架和架构在项目开始之初就定型了。同样，代码一旦写成，程序就完成了…不是吗？
错。 以我的经验，所有好的程序都至少要写两遍。第一编是你过于仓促，不能很好的理解需求、实现需求。不错，当看到了某种业务模式，我们知道要提炼出方 ...
O/R Mapping 是 Object Relational Mapping（对象关系映射）的缩写。通俗点讲，就是将对象与关系数据库绑定，用对象来表示关系数据。在O/R Mapping的世界里，有两个基本的也是重要的东东需要了解，即VO，PO。VO，值对象(Value Object)，PO，持久对象(Persisent Object)，它们是由一组属性和属性的get和set方法组成。从结构上看，它们并没有什么不同的地方。但从其意义和本质上来看是完全不同的。1．VO是用new关键字创建，由GC回收的。PO则是向数据库中添加新数据时创建，删除数据库中数据时削除的。并且它只能存活在一个数据库连接中，断开连接即被销毁。2．VO是值对象，精确点讲它是业务对象，是存活在业务层的，是业务逻辑使用的，它存活的目的就是为数据提供一个生存的地方。PO则是有状态的，每个属性代表其当前的状态。它是物理数据的对象表示。使用它，可以使我们的程序与物理数据解耦，并且可以简化对象数据与物理数据之间的转换。3．VO的属性是根据当前业务的不同而不同的，也就是说，它的每一个属性都一一对应当前业务逻辑所 ...
作为面试官从在大学里面试社团大一新生，到加入百度后帮公司面试候选人，我觉得我对面试这件事一直不得要领。百度提供面试培训，也允许参考或使用题库，但我还是觉得不知道如何判断给不给一名候选人通过我这关。偶尔我会遇到非常优秀的实习生候选人，我能十分确定我要给他过，甚至想方设法确保他能来。其它时候，我觉得我的判断随机性太大，或许还不如一枚硬币做得好。
在百度做二面的时候，我往往会问一些组合问题，就是候选人需要有扎实的基础加上一定的解题能力才能做出来的。我假设一面的面试官已经问过基础问题，所以我不会再问基础问题。结果通常是，候选人的基础不够扎实，会作出一些错误的假设，甚至面对组合问题就无从下手，不知道如何分解为更小的问题然后再一步一步来解决。我不知道是否应该期望候选人全部答对，但答对小部分的状况让我无从判断。
为此我开始跟其它人讨论面试经验。Acumon 说应该针对候选人说他擅长的领域来提问，而且使用开放性问题以便了解候选人的思考方式，但我发现我遇见的大多数候选人都不清楚自己擅长什么，或者是他们自认为的强项无法达到我的预期。后来在上海跟 Winter 和 Hax 聊天时发现一个可怕的现实：大多数前 ...
看到这个标题大家一定会想到这篇神文《How Browsers Work》，这篇文章把浏览器的很多细节讲得很细，而且也被翻译成了中文。为什么我还想写一篇呢？因为两个原因，
1）这篇文章太长了，阅读成本太大，不能一口气读完。
2）花了大力气读了这篇文章后可以了解很多，但似乎对工作没什么帮助。
所以，我准备写下这篇文章来解决上述两个问题。希望你能在上班途中，或是坐马桶时就能读完，并能从中学会一些能用在工作上的东西。
浏览器工作大流程
废话少说，先来看个图：
从上面这个图中，我们可以看到那么几个事：
1）浏览器会解析三个东西：
一个是 HTML/SVG/XHTML，事实上，Webkit 有三个 C++ 的类对应这三类文档。解析这三种文件会产生一个 DOM Tree。
CSS，解析 CSS 会产生 CSS 规则树。
Javascript，脚本，主要是通过 DOM API 和 CSSOM API 来操作 DOM Tree 和 CSS Rule Tree.
2）解析完成后，浏览器引擎会通过 DOM Tree 和 CSS Rule Tree ...
英文原文：11 Laws of The System Thinking in Software Development
“我会更加努力地工作” —— 一匹名叫Boxer的马（出自乔治·奥威尔的《动物农庄》）
彼得·圣吉在其著作《第五项修炼》中提到的系统思维定律同样适用于软件开发。
1. 今日的问题源于昨日的解决方案（Today’s problems come from yesterday’s solutions）
当解决问题时，我们会感到很高兴。我们经常不考虑后果。令人感到意外的是，我们提出的解决方案可能会产生反作用，并带来新问题。
作为对取得巨大成功的团队的奖励，公司决定为团队中的少数骨干成员发放奖金并晋升职位。团队中的其他成员会感到不公平，并且会丧失积极性。最终使团队成员之间的关系更加紧张，后续项目也就很难再取得成功。
项目经理频繁要求开发者修复一个新的软件Bug，或者处理客户的紧急需求，而开发者尽力满足这些要求。但是，过于频繁地分散精力会妨碍他们完成迭代过程中的主要任务。因此，项目进展很慢。
2. 用力越大，系统的反作用力也越大（The harde ...
