存档

2013年3月 的存档

Chrome和goagent的配置方法,你懂的

2013年3月31日 2 条评论

1、注册GAE帐号

gae

2、在GAE创建一个新的application

3、下载goagent最新版本

goagent 阅读全文…

分类: 互联网 标签: ,

Hacker News排名算法分析

2013年3月31日 没有评论

Hacker News使用Paul Graham开发的Arc语言编写,源码可以从https://github.com/nex3/arc/下载。下图是其排名算法实现:

arc

数学公式为:

score

P表示帖子的得票数,减去1是为了忽略发帖人的投票。在其他条件不变的情况下,得票越多,排名越高。
T表示距离发帖的时间(单位为小时),加上2是为了防止最新的帖子导致分母过小(之所以选择2,可能是因为从原始文章出现在其他网站,到转贴至Hacker News,平均需要两个小时)。在其他条件不变的情况下,越是新发表的帖子,排名越高。或者说,一个帖子的排名,会随着时间不断下降。
G表示”重力因子”(gravityth power),即将帖子排名往下拉的力量,默认值为1.8。它的数值大小决定了排名随时间下降的速度。

分类: 互联网 标签: , ,

中国黑客传说:游走在黑暗中的精灵

2013年3月26日 1 条评论

V

他是我所认识的最强大的地下黑客之一,在本文中我姑且称他为V。

之所以是之一,是因为我还认识另外一个叫A的黑客,A宣称自己成功入侵了包括Google、Facebook、Twitter等你几乎能叫得上名字的所有大型互联网公司。

而V要低调的多。

我认为V已经是地下黑客世界中的王者,虽然他从不肯告诉我他入侵的那些公司的名字,但我仍然会毫不犹豫的将他列为当今世界上最强大的黑客之一。

V至今仍恪守着古老的黑客守则,就如同中世纪的骑士们执着于骑士精神一般。他从不在任何公众场合谈论入侵了什么网站,入侵后也从不删除数据或是进行破坏,他也不会用入侵获得的成果来牟利。

V只是一个人,他的身后没有任何的机构或组织,因此才更加的难能可贵。

幽灵

“我曾经持续观察了一个女孩3年,3年中一直看着她和男朋友谈情说爱。她是个美女,我只见过她两次,是朋友的朋友。

最后她没有选择一直在谈情说爱的男朋友,而是和一个比她大了8岁的男人结婚。当她和那个比她大8岁的男人的结婚照出现在相册时,我彻底被现实社会给击败了。”

V坦诚,有时候他喜欢窥探他人的隐私。我告诉他,窥私欲是人类的天性,是所有黑客走上黑客之路的源动力。

QQ查找好友的“可能认识的人”,把女孩推荐给了V(朋友的朋友)。女孩用自己的照片做了头像,所以一眼就能认出来。随后V查看了女孩的个人资料,知道了女孩的邮箱地址。V查出了女孩用的网易邮箱的密码(下文会解释),发现密码很有规律,是“姓名全拼+!@#”,或者“woaini+生日+姓名全拼”。

V进入女孩的邮箱后,发现女孩注册了12306用来订火车票。V通过这个注册邮箱,获取了女孩在12306的密码。登录12306后,V得到了女孩和她家人的所有身份证信息以及出行记录。同时女孩在携程上预订的机票信息也会发送到这个邮箱。自此,女孩只要出行想去什么地方,去过哪里,全都在V的掌控之中。 阅读全文…

分类: 互联网 标签: ,

信用卡校验位算法THE LUHN MOD-10

2013年3月26日 没有评论

1. 对卡号上的每位数字乘以权重。其规则是,如果卡号数字个数是偶数,则第一位乘以2,否则就乘以1,然后以后分别是,1,2,1,2,1,2;
2. 如果每位数字乘以权重后超过9 ,则需要减去 9;
3. 将所有的处理过的加权数字求和,用 数字 10 求模运算;
4. 余数应该是0,否则可能是输入错误。也可能是一个假号。

分类: 算法 标签: , ,

提高代码可读性的注释技巧

2013年3月23日 没有评论

1. 逐层注释

为每个代码块添加注释,并在每一层使用统一的注释方法和风格。例如:
针对每个类:包括摘要信息、作者信息、以及最近修改日期等;
针对每个方法:包括用途、功能、参数和返回值等。
在团队工作中,采用标准化的注释尤为重要。当然,使用注释规范和工具(例如Java里的Javadoc)可以更好的推动注释工作完成得更好。

代码可读性 阅读全文…

分类: 项目管理 标签:

为什么程序员总是不能准确预估工作量

2013年3月22日 1 条评论

一个经验丰富的项目经理声称,他拿到程序员的时间估算以后,先将它乘以π,然后单位变为下一个时间数量级后,才能得到真正的值。即1天转化成3.14周。他过去因为程序员不擅长估算时间而吃尽了苦头。我创建了一个用来翻译程序员时间估算的表格,来尽量缩小估算错误。

 time

时间估算是困难的。每一个程序员都有一个现实的估计区间。低于这个区间的估计意味着(构件,测试,检查代码的)时间开销被低估了。超过这个区间的估计意味着这个任务太大而很难预估。

对于初级开发者来说,这个区间甚至都不存在。他们忽略(构件,测试,检查代码的)时间开销,同时困难的任务他们却又无法预估。我想说一个有经验的开发者应该在0.5至24小时将事情做完。超过24小时,就需要细分。这项工作应该在开发者的头脑中完成,然后总和到60小时。但是即使是有一些有经验的开发者也需要有利用管理时间块来思考。

同样重要的是明白:编程经验不等同于估算经验。一个不被包含在估算流程中的开发者将不会擅长估算。同样,如果实际的时间花费不被测量和用于与估算比较,那么将没有反馈来学习。

最后,每个程序员都应该具备估算的技能。为磨练这个技能,接手每个任务时,先决定你要做什么。然后在开始之前估算任务所需时间。最后测量实际花费时间,并与估算相比较。同样比较你实际完成的与计划完成的。这样你将会既提高你对一个任务包含细节的理解,同样也提高了你的估算技能。

HTTP协议状态码

2013年3月21日 1 条评论

HTTP协议状态码,是指在HTTP协议运行中由客户端发出请求连接,服务端建立连接;客户端发出HTTP请求(Request),服务端返回响应信息(Respond),而在这个过程中由于客户端或服务端的问题会返回相应的错误代码并显示给用户,对应的错误代码表示不同的错误信息,根据这个信息用户可以调整相应的操作来修改出现的错误,最终避免错误的再现。

http

http协议状态码一共有五种类别,分别是1XX,2XX,3XX,4XX,5XX。用三位数字来表示不同的错误。
1XX类状态码信息表示:临时的响应。客户端在收到常规响应之前,应准备接收一个或多个1xx响应。
2xx类状态码信息表示:服务器成功地接受了客户端请求。
3xx类状态码信息表示:客户端浏览器必须采取更多操作来实现请求。例如,浏览器可能不得不请求服务器上的不同的页面,或通过代理服务器重复该请求。
4xx类状态码信息表示:发生错误,客户端似乎有问题。例如,客户端请求不存在的页面,客户端未提供有效的身份验证信息。
5xx类状态码信息表示:服务器由于遇到错误而不能完成该请求。

HTTP协议状态码的含义 阅读全文…

分类: http 标签:

Java方法不应超过15行

2013年3月20日 没有评论

大多数人都会说,方法不能太长,但也不能定死,要具体问题具体分析。再追问一下,有人会说,不超过200行,100行,50行,30行都有。另有人说,面向对象风格的可以短些,面向过程风格的可以长些。也有人说,一个方法不超过一屏幕就行(姑且不论显示器大小,字体大小和分辨率问题)。

先摘录一段Martin Fowler《重构》P110-P111 中的一段话:

人们有时会问我,一个函数多长才合适?在我看来,长度不是问题,关键在于函数名称和函数本体之间的语义距离(semantic distance)。如果提炼动作(extracting)可以强化代码的清晰度,那就去做,就算函数名称比提炼出来的代码还长也无所谓。

说了直白点,函数名是干什么,函数体是怎么干。当2者不是那么能容易分辨出来时,就需要提炼出函数来,让代码更好懂。

既然大师都说了,长度不是问题了吗,那干吗还要追究函数长度规范呢?
其实大师讲的是对于懂得编程之道的人而言,不用关心长度,因为小函数是必然的结果。但在开发实践中,适当的函数长度限制值,可以给予我们警示,为什么这个方法写长了?哪里不对劲了?
对于这个问题我的回答是:Java函数不应超过15行。
为什么定这个数呢?
一方面,这个是基于多年开发实践的总结。15行其实已经是一个比较宽松的标准,开发人员稍加培训就可以实际贯彻,而符合这个标准的函数也能达到良好的可读性。

另一方面,这是基于对函数复杂度和代码行数之间关联关系的认识。
我采用一个简单的数学公式:

方法复杂度 >= 代码行数^2 (该公式参考于 gerald m. weinberg 《质量·软件·管理(第1卷)——系统思维》)

以下为了简化,只以最低增长方式,平方数进行计算。
以一个函数的行数,从1行到20行为例,见下图:

java

当函数行数到达10行以上,函数复杂度就开始大幅度攀升。
当代码行数达到20行时(复杂度400),其复杂度已经是14行时(复杂度 196)的2倍。
因此我将代码规范定在15行。

下面我们运行此公式,来分析一下提炼小函数的好处。
例如,有1个100行的函数,分解为11(含自身)个10行的函数。
原复杂度= 100^2=10000。
分解后复杂度= 11×(10^2)= 1100。
分解后的复杂几乎是分解前的 1/9,几乎降低了1个数量级。这就解释了为什么长方法分解之后,可维护性大幅度提高。

也就无怪乎有同学表示维护1000行以上的函数,有种生不如死的感受。

 

分类: java, 项目管理 标签:

Tomcat内存溢出的原因

2013年3月19日 没有评论

在生产环境中tomcat内存设置不好很容易出现内存溢出。造成内存原因是不一样的,当然处理方式也不一样。 这里根据平时遇到的情况和相关资料进行一个总结。常见的一般会有下面三种情况:

1.OutOfMemoryError: Java heap space

2.OutOfMemoryError: PermGen space

3.OutOfMemoryError:unable to create new native thread.

tomcat

对于前两种情况,在应用本身没有内存泄露的情况下可以用设置tomcat jvm参数来解决。(-Xms, -Xmx, -XX:PermSize, -XX:MaxPermSize),最后一种可能需要调整操作系统和tomcat jvm参数同时调整才能达到目的。

第一种:是堆溢出。

在JVM中如果98%的时间是用于GC且可用的Heap size 不足2%的时候将抛出此异常信息。没有内存泄露的情况下,调整-Xms,-Xmx参数可以解决。

-Xms:初始堆大小

-Xmx:最大堆大小

但堆的大小受下面三方面影响:

1.相关操作系统的数据模型(32-bt还是64-bit)限制;(32位系统下,一般限制在1.5G~2G;我在2003 server 系统下(物理内存:4G和6G,jdk:1.6)测试 1612M,64为操作系统对内存无限制。)

2.系统的可用虚拟内存限制;

3.系统的可用物理内存限制。

堆的大小可以使用 java -Xmx***M version 命令来测试。支持的话会出现jdk的版本号,不支持会报错。

-Xms, -Xmx一般配置成一样比较好比如set JAVA_OPTS= -Xms1024m -Xmx1024m 阅读全文…

分类: java, jvm 标签: , ,

mysql中处理未知大小的varchar

2013年3月18日 1 条评论

如果MySQL中varchar(M)M设置的太大,在磁盘上表占用空间大小只跟varchar中实际存放内容大小有关

但是如果查询要生成临时表,无论临时表是放在内存还是磁盘上,varchar都会扩张成M大小。这样将会消耗更多内存或者磁盘,对性能有严重的影响。

另外能用varchar就不要使用text,text性能很差,而且非常占磁盘空间。

varchar的长度是列共享的,一张表不要超过65535字节,对utf8编码约21485个字符

分类: mysql 标签: ,