千万别惹程序员
酷壳好久没有发娱乐性质的技术文章了,搞得气氛有点严肃了,考虑到程序员们都是比较严肃和容易较真的类书呆子的群体,所以,需要更新一个有娱乐性质的文章了。正好最近看到了两个比较有趣的图,在新浪微博上都得到了比较不错的反响,因此,更新到酷壳上来。
如果编程语言是一种刀
下面这个图是把编程语言看做是一种刀,那么会是什么样的。这个图我个人感觉很有意思。
对于这个图,最好不要解释,意会就好。不过,我却有点想不解风情,忍不住想解释一下。
酷壳好久没有发娱乐性质的技术文章了,搞得气氛有点严肃了,考虑到程序员们都是比较严肃和容易较真的类书呆子的群体,所以,需要更新一个有娱乐性质的文章了。正好最近看到了两个比较有趣的图,在新浪微博上都得到了比较不错的反响,因此,更新到酷壳上来。
下面这个图是把编程语言看做是一种刀,那么会是什么样的。这个图我个人感觉很有意思。
对于这个图,最好不要解释,意会就好。不过,我却有点想不解风情,忍不住想解释一下。
因为又有人邀请我去Quora的C2C网站去回答问题去了,这回是 关于 @laiyonghao 的这篇有点争议的博文《2012 不宜进入的三个技术点》ActionScript,Thread 和 C++, C++争议的争议最大。(要我说,.NET比C++更需要慎重进入,呵)。我就在这里回复一下这个问题吧。
正好我一个月前看到一个视频,这个演讲视频还比较著名,这个演讲者是Exceptional C++ 和 C++ Coding Standards 的作者,还是ISO C++ 委员会的Chair,C++/CLI首席架构师,还是Microsoft的软件架构师,他叫Herb Sutter,他的这个演讲视频是 C++ and Beyond 2011上的一次公开演讲,题目是——Why C++? (如果你觉得那里的视频比较慢,你可以看优酷上的视频)(英文听力好的同学可以看一样,因为都没有中文字幕)
我觉得这篇文章就足够可以说明很多问题了,所以,我把Herb的演讲幻灯片截了几页放到这里,并做上一些注释,算是一个演讲内容摘要吧。
1) 为什么C++?因为 Performance per $,也就是说performance 就是钱,这个分成三个方面,
移动设备上的耗电量相信用过智能手机的人都知道吧,Android手机的耗电量实在是太大了。就算是iPhone在开启Wifi和3G的情况下耗电量也很快。
自从上次写了“程序员技术练级攻略” 以来,就觉得似乎还有很多东西没有谈到,但当时没有继续思考了。而春节前有人问我,是做底层技术,还是做业务。这问题让我思考了很多,不由自主地回顾了一 下我这十多年的软件开发经历,并顺着整理分类了一下自己解决过的若干问题,还发散想了很多,经过了一个春节假期的发酵,产生了下面这篇文章。
这篇文章必然是通过我的个人经历来写的。所以,我先说说个人经历吧。我的经历基本分成三个阶段。
第一阶段:我 刚毕业时在家乡的某银行工作,做些银行的业务系统,还搞些网络,电子邮件系统,OA什么的,因为大四的时候在老师的公司里实习,银行里的人际关系太复杂, 而且技术都包给了产商,所以在银行的每一天都觉得不能适应里面的工作环境。两年后离职,单位分的房也不要了,直接去了上海,在上海呆了两年,本来想做互联 网的,但是泡沫来了,最终去了一家做系统集成的国企公司还是继续做银行业务。这四年来,主要解决的都是一些业务上的问题,银行里的会计业务,OA业务,国 际业务,中间对公业务都非常地复杂,而且因为当时的软件开发相当的不规范,所以基本上是在一种比较混乱的状态下度过的,而银行方面又很强势,所以,这段时 间主要是做业务。所以,技术上主要是积累了如何使用那些技术。C+/Java, Windows编程,Unix编程,网络编程主要是这段时间学的,看了太多的书(我大学课程里没有C++和Java,也没有Windows/Unix和网 络编程,所以,只能拼命地看书和自学)。
第二阶段:然后,我来了北京,到了一家做分布式计算系统的公 司,整天和一个高性能技术高可用性的企业级的集群式的软件产品打交道(这家公司去年被IBM收购了),在这家公司把Windows/Unix和网络编程有 了更深入的了解,对我长进比较大的是明白了怎么做一个性能高,可用性高的集群式的系统,天天和底层打交道,干了4年多。然后去了一家金融信息公司,这家金 融公司主要做全球的金融信息数据处理,而我主要还是做核心数据发布系统的性能调优的项目,金融数据的实时性要求的高,数据量非常地大,高可用性要求得高, 得想尽一切办法省网络带宽,增加系统性能,还要保持高的可用性,不当机,不丢包。又干了4年多,入职的时候从国外接过来两个系统,其性能单机每秒可处理 120K message,我走的时候,我和团队把其优化到了每秒1.4M messages 的吞吐,另一个系统,从接手时的100k message/s优化到了500k message/s。这八年多的时候,全是在和这些高计算高性能的项目打交量,几乎没有什么业务,都是纯技术,积累到了很多和性能有关的高并发高计算系统 架构级的知识。
12306.cn网站挂了,被全国人民骂了。我这两天也在思考这个事,我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促,而且完全基于本人有限的经验和了解,所以,如果有什么问题还请大家一起讨论和指正。(这又是一篇长文,只讨论性能问题,不讨论那些UI,用户体验,或是是否把支付和购票下单环节分开的功能性的东西)
任何技术都离不开业务需求,所以,要说明性能问题,首先还是想先说说业务问题。
Javascript是一个类C的语言,他的面向对象的东西相对于C++/Java比较奇怪,但是其的确相当的强大,在 Todd 同学的“对象的消息模型”一文中我们已经可以看到一些端倪了。这两天有个前同事总在问我Javascript面向对象的东西,所以,索性写篇文章让他看去吧,这里这篇文章主要想从一个整体的角度来说明一下Javascript的面向对象的编程。(成文比较仓促,应该有不准确或是有误的地方,请大家批评指正)
另,这篇文章主要基于 ECMAScript 5, 旨在介绍新技术。关于兼容性的东西,请看最后一节。
我们知道Javascript中的变量定义基本如下:
var name = 'Chen Hao';; var email = 'haoel(@)hotmail.com'; var website = 'https://coolshell.cn';
如果要用对象来写的话,就是下面这个样子:
var chenhao = { name :'Chen Hao', email : 'haoel(@)hotmail.com', website : 'https://coolshell.cn' };
于是,我就可以这样访问:
//以成员的方式 chenhao.name; chenhao.email; chenhao.website; //以hash map的方式 chenhao["name"]; chenhao["email"]; chenhao["website"];
关于函数,我们知道Javascript的函数是这样的:
最近,除了国内明文密码的安全事件,还有一个事是比较大的,那就是 Hash Collision DoS (Hash碰撞的拒绝式服务攻击),有恶意的人会通过这个安全弱点会让你的服务器运行巨慢无比。这个安全弱点利用了各语言的Hash算法的“非随机性”可以制造出N多的value不一样,但是key一样数据,然后让你的Hash表成为一张单向链表,而导致你的整个网站或是程序的运行性能以级数下降(可以很轻松的让你的CPU升到100%)。目前,这个问题出现于Java, JRuby, PHP, Python, Rubinius, Ruby这些语言中,主要:
注意,Perl没有这个问题,因为Perl在N年前就fix了这个问题了。关于这个列表的更新,请参看 oCERT的2011-003报告,比较坑爹的是,这个问题早在2003 年就在论文《通过算法复杂性进行拒绝式服务攻击》中被报告了,但是好像没有引起注意,尤其是Java。
你可以会觉得这个问题没有什么大不了的,因为黑客是看不到hash算法的,如果你这么认为,那么你就错了,这说明对Web编程的了解还不足够底层。
(感谢网友 liuxiaori 继续分享其经历)这样的详细的图文并茂的文章让我很佩服!
接上文“由一个问题到Resin ClassLoader的学习”,本文将以this.getClass().getResource(“/”).getPath()和this.getClass().getResourceAsStream(“/a.txt”)为例,一步步解析加载的过程。
问题来了,无论如何也模拟不出来<compiling-loader>所造成的影响,一直输出:/D:/work_other/project/resin-3.0.23/bin/ 。无奈之下,采用了这种方式:使用两个eclipse,一个使用发布版本的,部署EhCacheTestAnnotation进行调试;另外一个部署resin3.0.23源码,调试到哪里对照看源码。
本次调试涉及的所有类加载器为:
EnvironmentClassLoader$24156236[web-app:http://localhost:8787/EhCacheTestAnnotation]
EnvironmentClassLoader$7806641[host:http://localhost:8787]
EnvironmentClassLoader$22459270[servlet-server:]
sun.misc.Launcher$AppClassLoader@7259da
sun.misc.Launcher$ExtClassLoader@16930e2
首先进入Class的getResource(String name)方法,如下图:
女程序员是程序员里美丽的风景线,我希望这些女程序员的经历能让我们在这个“重男轻女”的社会中可以给女程员有更多平等的机会和条件,以及相应的尊重。因为,她们其中不乏优秀的程序员,而且在心态、态度和努力上还强过很多男性程序员,很多东西都值得我们大家向她们学习。
这篇文章的来由是因为Eva在“三个事和三个问题”的评论里问我女孩子是否能做技术,她说她的很多师兄都告诉他不要做技术,所以,她有些不坚定了。我的回复是告诉了她我工作经历中的两个技术很牛的女孩,并且我从她们身上学到了多技术。但是,后面有一些人回复说我误导了别人。所以,我在新浪微博和twitter上征集女程序员的故事和想法。我一共收到了19封邮件,其中有17封邮件来自女程序员。其中有一个已经发布了(一个女程序员的故事),其中的一些观点已经在网上传播,并得到了大家的刮目和称赞。但这并不是特例,因为下面的这些故事中,还有很多令人刮目相看的东西。
说明:先说明一下,这篇文章并不想讨论女孩子是不是适合做技术,这不值得讨论,因为,在“一个女程序员的故事”中我们已经知道,态度和努力才是原因,而不是性别。这里,也只是想告诉那些有“性别歧视”、“看不起女程序员”、“骄傲自大”的男程序员们,那些女程序员不为所知的一面。我把几乎所有的故事都列在这篇文章里了,我觉得我不用再多说什么了,这些故事组成的风景线,可以让你充分地了解女程序员。
在看到那些故事之前,我们需要了解这样的现实——
因为有人在酷壳里评论里说我给一个女程序员的建议不靠谱,我不服,因为我的工作经历中的一些女程序员都很不错,比那些男程序员都强,所以,我在新浪微博和twitter上征集女程序员的故事和想法,这两天来,我收到了好几封邮件,让我很感动。其中,有一个故事让我回味很久,在脑海里挥之不去,可能是因为她的经历和我很相似,她的想法和我很有共鸣。
本来,我想通过收到的这些故事然后编辑成一篇关于女程序员的文章,但是我觉得这个故事已经足够好了,任何的编辑都是对这个故事的不尊重,所以,我原封不动,一字不改地把这个故事转到这里。我把一些我认为精彩的地方加了粗。
当然,我还是会再写一篇关于女程序员的文章,酷壳2011年底的最后篇文章和2012年的第一篇文章都是给女程序员的,因为,我为你们骄傲!
从哪里说起呢,我的程序员之路。有些话只是自己心里想的很明白,还从没说过。希望你有耐心看完,因为我的故事不精彩,也算不上奋斗史。我的文笔和叙事能力也很差。
高中报志愿的时候坚定的报了计算机技术及应用,当时对计算机的认识只是机房里的苹果机,和老师教的用basic 输出一个正方形之类的。 我当时觉得我对计算机一无所知,我想了解他,就选择了这个专业,当然当时程序员的收入也是可观的。 :)
大学四年下来,我的成绩不好,基础也不好,没拿过奖学金。大学的课程很多不喜欢,我不知道为什么计算机系还要学高等物理,和马列毛邓。这是题外话。说实在的,很多课上的我一头雾水。毕业后找工作不满意,我直接去读了软件工程(考研的专业课成绩没到线)。两年制,一年上课,一年实习。我想给自己的履历上增加一些至少能给我面试机会的经历。(我仔细思考过我成绩不好的原因,心里因素是主要的,高中在重点中学,我不能接受自己不是尖子生的事实,总在想自己为什么这么差,以至于这样的心情影响了我很多年,一直到工作后的几年)
(感谢网友 liuxiaori 分享其经历)
某日临近下班,一个同事欲取任何类中获取项目绝对路径,不通过Request方式获取,可是始终获取不到预想的路径。于是晚上回家google了一下,误以为是System.getProperty(“java.class.path”)-未实际进行测试,早上来和同事沟通,提出了使用这个内置方法,结果人家早已验证过,该方法是打印出CLASSPATH环境变量的值。
于是乎,继续google,找到了Class的getResource与getResourceAsStream两个方法。这两个方法会委托给ClassLoader对应的同名方法。以为这样就可以搞定(实际上确实可以搞定),但验证过程中却发生了奇怪的事情。
软件环境:Windows XP、Resin 3、Tomcat6.0、Myeclipse、JDK1.5
我的验证思路是这样的:
由于时间匆忙,代码没有好好去组织。大致能看出上述两个功能,很简单不做解释。