Views: 15Yesterday, a colleague asked me how to load classes from a jar file (of course, I’m talking about java). All most information from internet tell us how to load java classes from a folder or class files. Less talk about how to load java classes from a jar. Actually, the thought to load classes [...]
Views: 8我一次拥有自己的计算机还是在96年，那时候计算机对我的作用就是能让我用Foxbase弄个通讯录，要不就使用QBasic算个二次函数。那时候我的机器在世界上是孤独的，只有我能和它用简单的DOS或者QBasic的方式交流交流。别人很难理解这个方盒子里面到底是什么东西。 那时候，我毫无互联网这个概念。有次去我一个哥哥家里，看到他正在用term泡BBS，一个黑底黄边白字的界面，我还以为是个某个单机DOS程序，当时表示对此毫无兴趣。那时候我还不知道这种程序加了个猫和电话线的程序将改变大多数人对那个方盒子的认识和使用方式。 98年，上了大学以后，我开始上网了。最初上网的原因是，自己学VB，周围资料太少，就去一些杂志和报纸上的推荐网页去找资料。后来有了叫CSDN的网站，就彻底开始了泡网生涯。（那时候的CSDN有很多牛人。好像VB的版主是个微软的技术人员）。 那年，当我扎入网络的时候，见识到了当年的网络风潮。那时候，互联网上到处都是免费的host服务，从html网页到asp/php服务一应俱全。那时候就有了免费给你送钱的广告链：只要你把广告放在你的页面上，甚至浏览者不用点击你都可以赚钱。看着满天飞的概念、热词，和各类层出不穷的网站，我傻眼了，我当时感觉真的是：IT这个行业真的是“钱多，人傻！”，于是立志要一头扎进去，奋斗一把，然后开始苦学编程。 可到2002年，我大学毕业的时候，第一次网络泡沫开始次第破灭。犹如冰川纪的突然降临，互联网好像被冻住了，各类网站，关门的关门，整合的整合，转型的转型。编程的找个工作也如“多收了三五斗”一般，落差很大。 这段历史，我一直都记在心里。它就像我心中的“淘金热”，这种行为和时期吸引人的不是单纯的“金”、利益，而是人们的狂热精神以及这种精神背后的向往和追求。我记着这份狂热，记着这种向往，然后几经辗转，我进了IT这个行业，但我没有去创富，也没有成为一个勤恳的程序员，而是在写了几年代码之后，搭了外包的快车，成了个咨询师（consultant）。 这三年来，我做的工作是我们上学时不断在讨论的“企业级”产品，包括安全方面的SSO，中间件的ESB。不断的学习新的商业系统、企业应用模式，不断的了解别人的设计思想，并用来解决问题，工作、生活倒也安逸。技术上也有了满足感，毕竟当我和别人聊起某种价格不菲的服务器或者商业产品的时候，别人偶尔也会给个向往的媚眼。 做了咨询师以后，一个毛病就是技术细节不再是主要关心的问题，而更关心产品的价值与风险预估的比例以及如何调节。用这个观点来审视自己现在的技术生涯，到底什么是我技术生涯的价值，什么是我的风险。 我想这么多年来，有一个念头在我心里始终没有按下去，就是能在某个产品上留下自己的名字。刚开始鼓捣计算机的时候，其中有一个乐趣就是在各种软件中寻找各种复活节彩蛋，比如Delphi中Hejlsberg的照片，MS Excel中的赛车游戏。我期待有一天我自己也能做一个有广泛用户的产品，然后恶搞式的留个彩蛋在里面。这是我认为的我的技术生涯的价值：做一个有人用的东西；然后在里面留下自己的名字，至少弄一个Credits列表。 做咨询师以来，在我心里这种可能性在不断降低。我现在的尴尬就是对于一个系统，我比客户都要了解，但客户结帐以后，我就变得和这个系统毫无关系。这让我毫无成就感。 现在新的网络风潮带着成熟和务实的气质再次到来，新的网络创富神话又开始层出不穷。相比之下这次新的创业风潮要成熟了不少：要有别出心裁的点子，要有出奇制胜的产品，还要有实打实的技术实践和拓展能力。技术上也有ASP/PHP的应用级别提高到了高负载、大吞吐架构，大型分布式系统，和各种各样的系统级概念。要是这些名词还不够刺激，那还有云计算这种buzz word。每个词都代表了在某种条件下的极致追求和创新思路。 看着现在的年轻人不断在创造着刻着自己名字的产品，我越来越坐不住了。这又让我内心泛起了那点小“狂热”：再年轻一把，去投入一次！。 没想到自己的30岁就这么开始了。自己20岁的时候没有解决的问题，现在又开始刺激我。打开音箱，听听歌，做个梦。 I was lyin’ in a burned out basement With a full moon in my eyes I was hopin’ for a replacement When the sun burst through the skies There was a band playin’ in my head And I felt [...]
Views: 1豆瓣电台上线以后，有人在twitter上问了一句douban.com和douban.fm之间的相互认证是怎么做的，是不是用到了cross-domain cookie。 实际上，cookie本身就不是为了跨域访问的设计的，我现在还不知道有真正的跨域cookie访问存在。如果存在，在一定程度上，我也认为那是个安全漏洞。 豆瓣的这个多个域名的共享认证是个典型的跨域SSO（单点登录）案例。虽然中间机关众多，但说一下其中的道理还是很简单的。 SSO，单点登录，有几个前提概念需要先说清楚： 1. 现在的SSO，大部分场景，都由一个专门的应用来提供认证。认证功能不像以前一样是内嵌在具体应用内部的。这个提供认证的应用一般都叫做identity provider，它所在的域我们称为认证域。这个应用会在你访问的时候简历你的基础认证信息，表明你在这个域里有个基础账户和基础权限。豆瓣的identity provider是http://www.douban.com/service/account/ 2. 具体的应用，比如douban.fm，称作service provider。service provider里会有一个优先级相当高的模块负责检查用户请求是否是认证过的。如果不是，它会将当前用户请求用某种方式保留并重新导向用户到认证域去做认证。这种模块在apache里设置在最前的mod，在IIS里就是一个priority是High的ISAPI filter。它能在一切应用处理以前检查请求内的认证信息。 3. 虽然说cookie不是跨域认证的解决方案，但cookie在跨域认证的过程中却是必需的。因为HTTP协议的无状态特性，服务器端要知道新收到的请求是不是来自于过去认证过的用户，它必须在客户端留下一些信息，一般就是cookie的方式保存。也有例外，比如HTTP Basic的认证方式，cookie不参与认证，但用户名和密码是被浏览器保存在内存里的，每次都会跟随请求发送。 4. 关于整个认证流程，浏览器可能会在identity provider和service provider之间跳转多次，一些HTTP的监视工具可以帮助你发现这些跳转，比如ieHTTPHeaders。 一个简单跨域SSO的认识过程应该是这样的（以豆瓣的域名为例，但并不是说豆瓣一定就是这么做的）： 用户发请求到douban.fm。douban.fm就是一个service provider，它上面的那个检查模块会先检查这个请求里有没有有效的认证信息。如果没有，它就把用户导向到http://www.douban.com/service/account/去做认证。这时的跳转URL类似http://www.douban.com/service/account/?return_to=http://douban.fm/ 。 最后的参数告诉identity provider，认证完要回到什么地方。 http://www.douban.com/service/account/作为identity provider会提示用户登录，并建立本地的认证信息，包括本域的认证cookie，和本域的session。然后根据跳转过来的URL return_to参数再把用户送回去。这时，除了return_to参数的URL以外，它还会附加一些认证相关的信息，比如在本域的认证id或者session id之类的。我刚登录的时候豆瓣重新导向我的url是http://douban.fm?sig=c3a7f19879&response_nonce=1269147513&data=%C9%ACVt%60%2C%C4K%89c%BD%07%B0Al%25%DD%F6%5D%D2%B2%E0%AC%16W%D9znW%935%AF%84%D4Vz%8C%9B%85g+%C3%C6%5D%FED9%96%84%D4Vz%8C%9B%85g+%C3%C6%5D%FED9%96&mode=id_res&return_to=http%3A%2F%2Fdouban.fm 后面的sig和response_nonce，data三个字段估计就是用于验证登录的相关信息。 当用户通过这个URL再次回到douban.fm的时候，那个检查认证的模块会发现这次回来的时候sig，response_nonce，data三个字段，然后用这三个信息从后台去identity provider寻求认证（比如socket去链接identity provider上的认证信息提供端口）。如果有效，就马上建立本地session和相关cookie信息以完成认证。然后再将请求放进具体的应用中去。这时候这个应用就得到了认证的用户信息了。 另一种常见也是标准方式之一，就是Identity Provider生成SAML Assertion页面，通过HTTP-POST的方式提交到Service Provider。一般来讲SAML Assertion都会经过PKI方式的加密，所以也可以防止中间人攻击。Service Provider通过HTTP协议收到了SAML Assertion，然后构造本地Session。这种方式更有效的解开Identity Provider和Service Provider的耦合。 完整的跨域SSO应用场景： 上述只是一个简单的跨域SSO场景。真正的跨域场景还是要复杂很多。比如Google有自己的identity provider，service provider。但它收购一个不同域名的新公司，这个公司也有自己的identity provider和service provider，这种集成就要复杂一层，但大体流程还是这样的，只不过service provider和identity provider的概念稍微有些改变。双方需要有公认的IDP，而针对于这个IDP，其他的IDP就成了SP。而如果只在自己的域内，自己的IDP还是IDP，SP还是SP。 SSO的其它问题： SSO是个安全问题。安全肯定是第一位的，信息传递时如何加密，如何仿冒，如何防止各种攻击（比如跨站脚本攻击）。还有各种服务器的集成。 [...]
Views: 0近来依然忙于SSO和ESB两个项目。这两个项目基本都不需要手写什么代码。SSO只需要从web console里配置好服务器和相关的安全策略。额外做的工作最多是用工具或者找个页面检查一下HTTP Head和Cookie里的安全信息。ESB需要的可能要复杂点，需要手写一些Xquery，甚至Java代码，而整个流程只需要在web console或者workshop里像visio一样拖拽节点就可以了，简单明了。我旁边的哥们不无沮丧的给我说：“唉，整天的任务就是连连看”。 我也已经记不起自己的上一行JAVA代码是什么时候写的了，可能是一年半以前写了一个更新LDAP信息的JAVA模块。我曾向Mr. V抱怨：唉，我离代码已经太远了，我可能已经什么都不会写了。Mr.V的回应向我传达了两个信息：第一，写代码的思想和能力就像骑自行车，一旦你学会了，就算很久不骑也不会忘记；第二，谁想一遍一遍的重复写那些代码。 我曾经也很纳闷，编码这么有创造性的事，为什么我们不干呢。有人也建议我们自己使用甚至写个domain specified language来处理web service可能还会比从头开始学ALSB，WLI更直观更顺手更快更令人兴奋。但谁会去做呢。 原因很简单：第一，我们不想重复发明轮子。既然已经有了ALSB，WLI这么成熟的Web Service集成模式，我们没必要从头开始按照自己的习惯早一个不知道会不会圆的新轮子。第二，手写的代码越多，项目的风险越大。项目的进程多多少少都是悲观的，最后我们往往会被淹没在漫无边际的代码里。ALSB和WLI这种开发模式只是让我们有了更好的方式去关注我们的处理流程，而不是代码细节。 重复每天的CRUD的java代码很难说就比画画节点的WLI强多少，但风险却很大。而在WLI过程中，我们同样会面对很多更深层次的技术设计和分析。不落窠臼的创造性更来源于对技术的挖掘，而不是门类。
Views: 0雷人的事很多，IT界也不甘落后。 今天忘了从哪里得到的信息，知道了Falcon这门新型语言。这门语言号称整合了当前所有流行的编程范式，包括过程式的，函数式的，基于类的面向对象，基于原型的面向对象，面向消息式和表格式的编程方式。它也是一个无类型的脚本式语言。听起来这个东西像什么？Python，Ruby，Lua，Javascript，PHP，Perl的结合体？很疯狂。
Views: 0在很久很久以前，DOS的年代，编译器技术还没那么高超的时候，有个叫Watcom C/C++的编译器可以提供极其高效的优化代码。记得很久以前看一个Geek写的编译器比较，他赞叹Watcom编译生成的代码竟然比手动优化的效率还要高。在DOS年代，Watcom更是占据了大半游戏开发的江山。由于DOS下面有640K内存限制而游戏运行往往需要更大内存，所以Watcom和自带的DOS/4GW（用于突破DOS的640K内存限制）的组合便是DOS下游戏开发的不二之选。在93-96年间，几乎所有的游戏都是使用Watcom C开发的，包括大名鼎鼎的Duke Nukem 3D和Doom。 但在微软淘汰DOS的过程以及Windows上的各种C/C++编译器的圣战中，Watcom转型很不成功，最终败下阵来，被Sybase收购，随后又被抛弃。这段历史在李维先生的《Borland传奇》中又比较细腻的描述。 Sybase对Watcom做的最正确的一件事就是在2000年的时候将Watcom编译器开源为OpenWatcom项目。正是这一无奈之举延续了Watcom的生命，使它脱离了混乱的组件规范和平台特性的恶意竞争，而在一片僻静之地靠社区的号召力和热情活了下来。打开OpenWatcom的新闻组，用户讨论区里面虽然不是特别火热，但一个星期总有3、4个topic，而且基本没有0回复。
Views: 0译注：本文译自linuxdevcenter.com上的一篇文章《Linux Performance: Different Distributions, Very Different Results》（原文作者Caitlyn Martin发表于2009年3月9号。）翻译此文仅为英语与技术学习。转载请注明原文出处与作者。如有翻译不当欢迎指正交流。（Garriot Zhang译注） 【Caitlyn Martin于2009年3月9号发表于linuxdevcenter.com】 【Garriot Zhang译于2009年6月17号】 当我给不同的Linux发行版写评论并且阐述他们性能差异的时候，我总是给这些感想加一个注释：所有的Linux发行版本质上都是一样的，一样的内核，一样的库，一样的文件系统。性能在根本上应该也是一样的，对吗？答案是一个响亮的“不”。不同发行版，就算他们用的是一样的版本的内核，一样的核心库，一样的文件系统，性能也是非常非常的不同。 我看到在无数的Linux论坛上这个问题被争论不休，但往往没有真凭实据。“对我来说它更快”，这种理由不会说服任何人。在LXer.com的一个讨论中，一个叫herzeleid的用户问了一个关键问题：“我纳闷为什么会这样呢？”于是这篇文章就由此而生。 不同的发行版是为了更好地适应不同的硬件。这种情况最明显的例子就是，无论家用的桌面系统还是企业机房里的机器，都有不同的处理器架构。对于大多数桌面用户来说这个问题可以归结为你用的是32位CPU还是64位CPU。（现在的双核和四核机器一般来讲是加倍64位CPU的个数。）是的，一个32位的发行版可以在64位的机器上很好的完成大多数日常任务。而且实际上性能也不会有太大差别。那些CPU密集型的任务会体现出64位CPU的优势，而32位的操作系统就不能很好地执行。我一个艺术家朋友，做了很多3D图形渲染的工作。对她而言，32位的发行版运行这种任务要比64位的发行版耗费很多的时间。任何需要大量数值运算的任务都会让人难以忍受，比如高端的多媒体任务，和高端的游戏。一个64位的发行版还能正确的识别和利用大规模的系统内存。 当一个系统被推到它的极限的时候，性能差异就变得非常明显。一直以来这种情况经常发生中等配置的机器上。其实这也包括从日益流行上上网本到老式的遗留硬件的所有机器。在这个经济困难的时期，这种情况也像影响家用用户一样影响到了商业领域。据我所知，为了节省开支，很多商业公司现在购买上网本而不是常规的笔记本。还有很多其他的公司正试图用一些老硬件，有些已经非常陈旧，来延缓购买新硬件的经济压力。Linux理想地被用于为老系统延续寿命，甚至包括那些都不能满足当前版本的Windows最小系统要求的机器。在这种情况下，我们一般只谈32位的处理器和32位的Linux发行版，所以处理器架构不是问题。这些32位发行版的性能差异可能是巨大的。
Views: 4译注：本文译自linuxforums.org上的一篇文章《Linux Performance Tuning》（原文作者Fernando Apesteguia发表于2006年）翻译此文仅为英语与技术学习。转载请注明原文出处与作者。如有翻译不当欢迎指正交流。（Garriot Zhang译注）。 Fernando Apesteguia的结论是：“当一个发行版打包发送到客户手中的时候，它是为了完全兼容市场中大部分计算机而设计的。这是一个相当混杂的硬件集合（硬盘，显卡，网卡，等等）。所以Red Hat， Suse，Mandriva和其他的一些发行版厂商选择了一些保守的设置来确保安装成功。” 为什么要系统调优？ 这可能是第一件你想知道的事。当一个发行版打包发送到客户手中的时候，它是为了完全兼容市场中大部分计算机而设计的。这是一个相当混杂的硬件集合（硬盘，显卡，网卡，等等）。所以Red Hat， Suse，Mandriva和其他的一些发行版厂商选择了一些保守的设置来确保安装成功。 简单地说：你的发行版运行的很好，但是它可以运行地更好！ 比如，你可能有一个具体一些特殊特性的高级硬盘，而这些特性在标准配置的情况下可能就没被启用。
Views: 0注：本文译自LWN.net的介绍性文章《A general caching filesystem》,corbet发表于2004年9月1日。翻译这篇文章没有任何目的，纯粹为了周末脑力活动。文章内容可能已过时。在Linux上，VFS是更好的选择。 一个通用的缓存文件系统 【corbet 发表于2004年9月1号，Garriot Zhang翻译】 很多文件系统都与一个相关的慢速后台存储一起运行。网络文件系统依赖于一个网络连接和一个远程服务器；从一个这样的文件系统中读取文件明显会比从本地读取慢。使用慢速本地介质（比如CDROM）的文件系统也会比那些使用快速硬盘的慢。正因为这个原因，缓存从这些文件系统获得的数据到本地硬盘成为一种必需。 然而，Linux却没有一种机制能让文件系统执行本地磁盘缓存。或者，至少它过去一直没有这样一种机制。David Howells的CacheFS补丁改变了这种状况。 使用CacheFS，系统管理员可以在块设备上分配一个分区用于文件缓存。CacheFS会提供一个供其他文件系统使用的接口。其中有一个基本的注册接口，和一个相当精致的索引分配机制。不同的文件系统用不同的方式来创建文件标志符，所以CacheFS尽可能地减少强加的策略，让这些文件系统代码想干什么就干什么。最终，当然，有一个接口用于缓存文件分页，记录改动，从缓存中移除分页，等等。 CacheFS的目的不是缓存整个文件；它必须能应付这种可能：有人想操作一个比整个缓存还要大的文件。实际上，它也不能保证能缓存所有东西；它必须能执行自己的空间管理，而且就算是缺少真正的缓存设备所有东西也能工作。这对大多数文件系统来说这都不应该是一个障碍；就本质而言，文件系统首先必须要准备好处理他们文件的真正来源。 CacheFS的目的是与其他文件系统协作，而不是作为一个独立文件系统使用。它的分区必须在使用前挂载，CascheFS使用挂载点向被缓存的文件系统提供一个视图。系统管理员甚至能通过简单地从被挂载的文件系统中删除文件的方式来手动地从缓存中将他们移除。 在用户和真正的文件系统中间插入一个缓存，明显的增加了一个可能导致数据丢失的破坏点。CacheFS通过缓存内容日志来处理这个问题。如果发生意外停机的情况，CacheFS可以重复执行所有的丢失操作直到所有的服务恢复工作。 现在，CacheFS只被AFS文件系统使用，但是兼容其他系统的工作也在进行中。NFS更是会从CacheFS得到很大好处，特别是当NFSv4开始使用的时候（NFSv4的设计允许本地缓存）。期待这个补丁能相对容易地被主流内核接受。如果想获得更多信息，请看补丁中的文档文件。
Views: 06月9号，Fedora 11终于在跳票两次以后正是发布了。 这一个版本的Fedora好像备受期盼。刚发布，就有人说这是最好的Fedora。 网上找了找相关信息，想看看这个Release到底好在哪里。发现有人早在5月底就写了Fedora11的使用感受。 Steven J Vaughan-Nicolas在《Fedora11最好的五个特性》里，先赞扬了Fedora11基于Gnome2.26的新视觉感受以后，又说明了Fedora11采用的PulseAudio音量调节器。（我对这个不太感冒，不过感觉这好像是个趋势，Ubuntu Geek在Ubuntu9.04放出来以后就马上有一篇配置PulseAudio的文章跟进）。 Steven同学总结的Fedora11的最好的五个特性如下： 1）快速引导：Fedora的开发者终于实现了20秒启动的承诺。Steven同志亲自测试：18.9秒完成启动。 2）Ext4成为默认的文件系统：Ext4的好处是大大的，支持1EB的文件系统，单个文件16TB， 没有子目录数量限制，更高的磁盘性能，更好的磁盘空间管理，等等。Ext4成为主流已是必然。（现在还是有defect的，比如现在GRUB还不支持Ext4，也就是说GRUB＋Ext4的时候，/boot需要是Ext3。不过估计这个问题会在GRUB2应该中解决（Ubuntu9.10将使用GRUB2作为引导））。 3）更好的图像与显示：Fedora11里用了1.6版的x.server，更好更稳定的显示系统。一般来说至少显示速度比原来更快了，另外如果使用多显示输出的话，这个版本的优势将更加明显。（这个版本的问题就是强制结束x.server的ctrl+alt+backspace组合键被取消了，其实9.04的ubuntu就已经默认取消了这个组合键） 4）点触板的支持大大改善：如果你使用笔记本的点触板的话，这个理由足以让你换到Fedora11上来。 5）DNSSEC（DNS Security Extensions：DNS安全扩展）：Fedora11默认加入了DNS安全扩展，防止DNS仿冒攻击。无论怎么样，这个特性在安全方面还是有很大意义的。 简言之：Fedora就是一个快，稳定，有融合了很多新技术的版本，值得一试。 BTW：使用Redhat的发行版，最好还是要搞清楚Redhat相关发行版的支持周期：RHEL的支持周期是7年，与之对应的CentOS也是7年；而Fedora的支持周期只有1年。Fedora还真是一个相当激进的产品。
