什么是哈希（Hash）函数
理想情况是希望不通过任何比较，一次存取便能得到所查记录，那就必须在记录的存储位置和他的关键字之间建立一个确定的对应关系f，使得每个关键字和结构中一个唯一的存储位置相对应。因而在查找时，只要根据这个对应的关系f找到给定值K的像f(K)。若结构中存在关键字和K相等的记录，则必定在f(K)的存储位置上，由此不需要比较便可以直接取得所查记录。在此，我们称这个对应关系为哈希(Hash)函数，按这个思想建立的表为hash表。
哈希函数是一个映象，因此哈希函数的设定可以很灵活，只要使得任何关键字由此得到的哈希函数值都落在表长的允许的范围之内即可。
对于不同的关键字可能得到同一哈希地址，即key1<>key2,而f(key1)=f(key2),这种现象称为冲突collision。具有相同函数值的关键字对该哈希函数来说称同义词。然而，在一般情况下，冲突只能尽可能的少，而不能完全避免。因为，哈希函数是从关键字集合到地址集合的映象。通常，关键字集合比较大，而地址集合的元素仅为哈希表中的的地址值。
什么是好的哈希函数
若对于关键字集合中的任一个关键字，经哈希函数映象到地址集合中任何一个地址的概率是相等，则称此类哈希函数为均匀的哈希函数。
处理冲突的方法
- 开放定址法
- 再哈希法
- 链地址法
- 建立一个公共溢出区
Hash表的查找及分析
在哈希表上尽心查找的过程和哈希造表过程基本一致。给定K值，根据造表时设定的哈希函数求得哈希地址，若表中此位置没有记录，则查找不成功；否则比较关键字，若给定值相等，则查找成功；否则根据造表时设定的处理冲突的方法找“下一个地址”，直至哈希表中某个位置为空或者表中所填的关键字等于给定值为止。
参考资料
hash算法和常见的hash函数
Scalability
多IDC的数据分布设计(一)
多IDC的数据分布设计(二)
CAP原理与最终一致性
OO & Design Pattern
视角的力量–再说OO设计原则
Martin Fowler在他的著作 《UML Distilled》中提到了三层视角（perspective）：概念视角，规约视角，实现视角。
使用三种视角看软件开发，我们可以得到这样的描述：
概念视角：呈现所研究领域中的各种概念，得出概念模型的时候应该尽量少德或者不考虑它的实现，这个视角要回答的问题是：软件要负责什么？是策略性的结论
规约视角：我们现在考虑的是软件，但是我们关注的是软件的接口而不是实现。规约视角要回答的问题是：怎么使用软件？这个层次关注的是软件各部分的交流。
实现：这时我们考虑的是代码本身但是许多方面我们使用规约视角可能会更好，软件在规约层交流在实现层执行。
视角帮助我们将问题划分层次，隔离
从上面的描述我们很明显得看到“软件开发”所设计牵扯的问题已经被划分到三个不同的层次，在每一个层次我们都要有特定的思考成果。在高层没有思考成熟的时候我们不往下一个层次进行，按照这样一个原则，细节被隔离在思维的围墙之外。
Active Object 并发模式在 Java 中的应用
Architecture
如何做好软件系统的架构设计？
Tomcat 系统架构与设计模式，第 1 部分: 工作原理
Tomcat 系统架构与设计模式，第 2 部分: 设计模式分析
Java
Installing Multiple Eclipse Plugins with Ease
NOSQL
MapReduce: 一个巨大的倒退
Algorithm
拜占庭将军问题
拜占庭假设是对现实世界的模型化，由于硬件错误、网络拥塞或断开以及遭到恶意攻击，计算机和网络可能出现不可预料的行为。拜占庭容错协议必须处理这些失效，并且这S些协议还要满足所要解决的问题要求的规范。这些算法通常以其弹性t作为特征，t表示算法可以应付的错误进程数。 很多经典算法问题只有在t<n/3是才有解，如拜占庭将军问题，其中n是系统中进程的总数
如果要想容忍m个判国者，必须保证总的将军的个数大于3m。
产品
新浪内部对腾讯公司的深度解析.pdf
学习腾讯的产品管理之道
其他
如何让PPT的备注演示者看到而观众看不到
Scalability
Applying Scalability Patterns to Infrastructure Architecture
Load distribution – Spread the system load across multiple processing units
缓存技术浅谈
UML
UML建模之时序图
Algorithm
数组与链表的区别
算法
LRU算法的实现
Agile
http://www.thoughtworks-studios.com/mingle-agile-project-management
Scrum is Suffocating（使窒息） Me
When a team adopts Scrum or Agile, management too often buys an "Agile Tool", and expects it to drive the team. Unfortunately, people drive Agile, not tools. Tools support the effort, not the other way around.
If you’re wanting to drive Agile adoption, you’ve got to be sure your team trained and share your motivations with them. If management is driving Agile adoption, it’s to address some type of pain. Either they don’t know what your team is doing and they want insight to the development lifecycle, or they need to get a smaller feature set to market more often, or they want to boost quality. Whatever the motivations, they need to share them with the team.
