#python 写的 插入排序和 快速排序
def insert_sort(seq): for i in range(len(seq)): j=i-1 value=seq[i] while(j>=0and seq[j]>value): seq[j+1]=seq[j] j=j-1 seq[j+1]=value return seq def quick_sort(seq): if(len(seq)<=1):return seq #把seq[0]作为中值 left=[y for y in seq[1:] if y < seq[0]] right=[y for y in seq[1:] if y >= seq[0]] return quick_sort(left)+[seq[0]]+quick_sort(right) if __name__ == "__main__": seq=[5,3,6,7,1,9,3] print insert_sort(seq) print quick_sort(seq)
算法：Java 版 汉诺塔
package test; public class Tower { public static void main(String[] args)throws Exception{ move(4,'A','B','C'); } public static void move(int n,char from,char to,char mid){ if(n==1){ System.out.println("把盘子"+n+"从"+from+"移动到"+to); return; } move(n-1,from,mid,to); System.out.println("把盘子"+n+"从"+from+"移动到"+to); move(n-1,mid,to,from); } }
package test; public class BitAdd { /** * 算法，给定一个二进制数n中1所在的位置，求3*n的二进制表达式中1的所在位置 * 例如 50 的二进制位110010 那么这个二进制数1的位置为{1,4,5}，50*3=150 求150的二进制数的1所在位置 * 先利用2*n等于n左移以为，计算出2*n，再2*n+n 得出解，解最终打印出来了。关键步骤就是二进制加法。 */ public static void main(String[] args) { int[] A={1,4,5}; int[] B={2,3,4,5}; Bit3Times(A); System.out.println(""); Bit3Times(B); } public static void Bit3Times(int[] A){ int[] B=new int[A.length]; int[] C=new int[A.length+1]; for(int i=0;i<A.length;i++){ B[i]=A[i]+1; C[i]=A[i]; } for(int i=0;i<C.length;i++){ if(i<B.length){ for(int j=0;j<B.length;j++){ if(C[i]==B[j]){ C[i]=C[i]+1; break; }else if(B[j]<C[i+1]&&B[j]>C[i]){ C[B.length+i]=B[j]; } } } } if(C[B.length-1]==B[B.length-1]){ C[B.length-1]++; } int num=0; for(int i=0;i<C.length;i++){ if(C[i]>0) num++; System.out.printf("%s,", C[i]); } } }
nginx是俄罗斯出品的注明的反向代理服务器，是apache的替代品之一。目前包括sina，腾讯在内的多家互联网公司都在用这个产品。
最近nginx发布了windows下的程序。
nginx的官网下载稳定版本。
之后修改配置文件conf/nginx.conf
找到server哪一行，配置如下
server { listen 8099; server_name localhost; location / { root html; index index.html index.htm index.php index.jsp; proxy_pass http://127.0.0.1:8080; }
由于我的机器上80端口跑的apache，所以我就用8099来拍nginx,并将请求都发给了8080端口上的resin。如果你只需要将jsp请求发过去，那么你还要在location哪一行上用正则表达式写下你的匹配模式。
总而言之，配置真的好简单。
之后启动resin，再启动nginx就ok了
《EJB 3 in Action》中文版
优点：
这是一本好书，浅显易懂，翻译的也不错，入门的经典书籍。
缺点：
不够深入，基本点到为止，特别是关于配置，集群，测试这些内容介绍的太少，或者根本就没有。
《Java 学习笔记 jdk6》
优点：
浅显易懂，涉及的面比较广，有些章节写的引人入胜（我一般很少用这个词形容技术书籍的），特别是关于class loader的章节。
缺点：
大部分章节太浅了，而关于JDBC等章节，我认为可以删掉了，这些根本就是JavaEE的范畴，没必要强插进来。而且例子中使用jdk新特性太少了，一本介绍jdk的书，你自己都不用还指望读者用吗？
《Spring Pro 中文版》
优点：
其中有大段大段的代码，写的太好了，一个字 赞！
缺点：
版本太老了，是spring1.2
《Spring 技术手册》
优点：
书很薄，介绍性的，可以翻翻
缺点：
基本就是翻译的api，其中的例子简直太SB了
《精通Hibernate,孙卫琴》
优点：
我看过写Hibernate的书里面，写的最好的。
缺点：
有一点浅显，而且也没有针对Hibernate3再版过，当时还用的是Hibernate2
《Java参考大全jdk1.3》
优点：
我的java入门书，好书，就是太厚
缺点：
很难适应老外写的教材，不过内容还不错
《Hibernate实战，第二版》
优点：
英文版是圣经
缺点：
中文版是垃圾
《Java web 开发(孙鑫)》
优点：
好书，入门经典
缺点：
太厚了，前面写xml的部分完全可以删掉
《Hand First Serverlet and Jsp》
优点：
好书，入门经典
缺点：
没有
《Hand First 设计模式》
优点：
名气大，浅显易懂
缺点：
怎么说呢，该有的没有，不该有的太多了。
《POJO in action》
优点：
绝对经典，对于2005年以后入门的JavaEE程序员，建议人手一本
缺点：
几乎没什么缺点
《Spring in action2》
优点：
绝对经典
缺点：
但是和其他讲解spring的书没多大差别，而且大部分例子都没有用Annotation，还是xml。
如果利用SSL协议来访问网页，其步骤如下：
用户：在浏览器的地址栏里输入https://www.sslserver.com
HTTP层：将用户需求翻译成HTTP请求，如
GET/index.htmHTTP/1.1
Hosthttp://www.sslserver.com
SSL层：借助下层协议的的信道安全的协商出一份加密密钥，并用此密钥来加密HTTP请求。
TCP层：与webserver的443端口建立连接，传递SSL处理后的数据。
接收端与此过程相反。
SSL在TCP之上建立了一个加密通道，通过这一层的数据经过了加密，因此达到保密的效果。
SSL协议分为两部分：HandshakeProtocol和RecordProtocol,。其中HandshakeProtocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。
需要的加密方面的基础知识
了解SSL原理需要一点点加密的概念，这里把需要的概念做一下简单阐述：
加密一般分为三类，对称加密，非对称加密及单向散列函数。
对称加密：又分分组密码和序列密码。
分组密码是将明文按一定的位长分组，明文组经过加密运算得到密文组，密文组经过解密运算（加密运算的逆运算），还原成明文组。
序列密码是指利用少量的密钥（制乱元素）通过某种复杂的运算（密码算法）产生大量的伪随机位流，用于对明文位流的加密。
解密是指用同样的密钥和密码算法及与加密相同的伪随机位流，用以还原明文位流。
CBC(CipherBlockChaining)模式这个词在分组密码中经常会用到，它是指一个明文分组在被加密之前要与前一个的密文分组进行异或运算。当加密算法用于此模式的时候除密钥外，还需协商一个初始化向量（IV），这个IV没有实际意义，只是在第一次计算的时候需要用到而已。采用这种模式的话安全性会有所提高。
分组密码的典型例子为DES、RC5、IDEA。
序列密码的典型例子为RC4。
公钥加密：
简单的说就是加密密钥与解密密钥不同，分私钥和公钥。这种方法大多用于密钥交换，RSA便是一个我们熟知的例子。
还有一个常用的称作DH，它只能用于密钥交换，不能用来加密。
单向散列函数：
由于信道本身的干扰和人为的破坏，接受到的信息可能与原来发出的信息不同，一个通用的办法就是加入校验码。
单向散列函数便可用于此用途，一个典型的例子是我们熟知的MD5,它产生128位的摘要，在现实中用的更多的是安全散列算法（SHA），SHA的早期版本存在问题，目前用的实际是SHA－1，它可以产生160位的摘要，因此比128位散列更能有效抵抗穷举攻击。
由于单向散列的算法都是公开的，所以其它人可以先改动原文，再生成另外一份摘要。解决这个问题的办法可以通过HMAC（RFC2104）,它包含了一个密钥，只有拥有相同密钥的人才能鉴别这个散列。
密钥协商过程
由于对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。
SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图（摘自TLS协议）。
ClientServer
Clienth*llo——–>
Serverh*llo
Certificate*
ServerKeyExchange*
CertificateRequest*
<--------Serverh*lloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished-------->
[ChangeCipherSpec]
<--------Finished
ApplicationData<------->Application Data
简单的说便是：SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个Clienth*llo来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个Serverh*llo，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。
密钥协商的形象化比喻
如果上面的说明不够清晰，这里我们用个形象的比喻，我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。
A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。
B：我们用DES－RSA－SHA这对组合好了。
这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。
目前没有别的可说的了。
A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）
（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量和hmac的密钥。将这份秘密消息-协议中称为 per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）
[我说完了]
B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]
A:[我的秘密是...]
B:[其它人不会听到的...]
加密的计算
上一步讲了密钥的协商，但是还没有阐明是如何利用加密密钥，加密初始化向量和hmac的密钥来加密消息的。
其实其过程不过如此：
1借助hmac的密钥，对明文的消息做安全的摘要处理，然后和明文放到一起。
2借助加密密钥，加密初始化向量加密上面的消息。
安全性
SecurityPortal在2000年底有一份文章《TheEndofSSL and SSH?》激起了很多的讨论，目前也有一些成熟的工具如dsniff可以通过man in the middle攻击来截获https的消息。
从上面的原理可知，SSL的结构是严谨的，问题一般出现在实际不严谨的应用中。常见的攻击就是middleinthemiddle攻击，它是指在A和B通信的同时，有第三方C处于信道的中间，可以完全听到A与B通信的消息，并可拦截，替换和添加这些消息。
1SSL可以允许多种密钥交换算法，而有些算法，如DH，没有证书的概念，这样A便无法验证B的公钥和身份的真实性，从而C可以轻易的冒充，用自己的密钥与双方通信，从而窃听到别人谈话的内容。
而为了防止middleinthemiddle攻击，应该采用有证书的密钥交换算法。
2有了证书以后，如果C用自己的证书替换掉原有的证书之后，A的浏览器会弹出一个警告框进行警告，但又有多少人会注意这个警告呢？
3由于美国密码出口的限制，IE，netscape等浏览器所支持的加密强度是很弱的，如果只采用浏览器自带的加密功能的话，理论上存在被破解可能。
代理
下面探讨一下SSL的代理是怎样工作的。当在浏览器里设置了https的代理，而且在浏览器里输入了https://www.example.com之后，浏览器会与proxy建立tcp链接，然后向其发出这么一段消息：
CONNECTserver.example.com:443HTTP/1.1
Host:server.example.com:443
然后proxy会向webserver端建立tcp连接,之后，这个代理便完全成了个内容转发装置。浏览器与webserver会建立一个安全通道，因此这个安全通道是端到端的，尽管所有的信息流过了proxy，但其内容proxy是无法解密和改动的（当然要由证书的支持，否则这个地方便是个 maninthe middle攻击的好场所，见上面的讨论）。
关于证书
注意，如果对于一般的应用，管理员只需生成“证书请求”（后缀大多为.csr），它包含你的名字和公钥，然后把这份请求交给诸如verisign等有CA 服务公司（当然，连同几百美金），你的证书请求经验证后，CA用它的私钥签名，形成正式的证书发还给你。管理员再在webserver上导入这个证书就行了。如果你不想花那笔钱，或者想了解一下原理，可以自己做CA。
从ca的角度讲，你需要CA的私钥和公钥。从想要证书的服务器角度将，需要把服务器的证书请求交给CA。
如果你要自己做CA，别忘了客户端需要导入CA的证书（CA的证书是自签名的，导入它意味着你“信任”这个CA签署的证书）。
而商业CA的一般不用，因为它们已经内置在你的浏览器中了。