常常被天才的人们感动

29 Dec 2009 In: NEWS

这次是一篇旧帖:

[转帖]北大“关机山”事件

http://cul.qidian.com/#Show.aspx?mid=12&rid=151403

奇人异士何其多。

每一篇都超强,尤赞其中的“加州州版”和“程序员版”。

:-)

研究GO两天了

27 Dec 2009 In: Go

编译。与C相类的速度。
非托管但指针安全。
极佳的多线程支持。
极度简洁,引入了动态语言的主要优点,让编程不再是和语言的斗争。
开源。

既然它看起来和动态语言差不多。如果可能,企盼有一些将其放在web领域的尝试--就象Gwan对C所做的那样。

谢天谢地。

 

09-12-27 0:59,补充

看到这个位置,有人评论说:

Now Google will create a dominance not only by its acquisition of Admob, and the success of Droid phone but now hitting a sixer the GO language could shape the web 3.0

<敏捷无敌>

13 Dec 2009 In: Project Management

一个冬日下午。从书架上抽出躺书架上月余的书塞包里。步行到附近星巴克。

一口气读完。这是一个关于探索,学习和发现的故事。

经验成为原则,原则成为理论,理论果然就能有效解决问题。

问题和我们遇到的何其相似。这里有聪明勤奋的人们。

这里有智慧和人性的光芒闪耀。

这是我所痴迷的技术。

十三日 十一月 零九年 。于solana星巴克咖啡。
ipod

玩玩G-Wan:kolidon的人生悲喜剧

6 Dec 2009 In: FRAMEWORK, NEWS

WEB服务器当然很多。

张宴同学对nginx的研究让我领悟了应该抓住好机会来出名上位。

但是,这个会不会是一个机会?

——G-wan,直接使用原始C脚本来处理请求响应的WEB应用系统(当然,系统会自动预编译它,一如Java虚拟机和.NET所做的那样)。 http://www.g-wan.com

并发连接数可达10几万的系统。

速度据称可与静态页媲美,简单页面生成所耗时间可以用100还是200CPU循环来计算的系统。

小至200K,一个下载包里同时有window/linux平台执行文件,免费的系统。

 

我下载下来,安装,试了它们的demo。也试着vi了一个C文件放进去,果然很好很强大。

C脚本不用编译,看起来,似乎比PHP脚本快得多,特别地,受限于PHP和服务器间,及PHP本身的模型。普通server单机每秒500-1500请求似乎是极限。

 

那么,这么棒的一套系统,为什么它没有流行?出来也有好几个月了,竟然没有张宴2号同学来介绍它,试用它。

如果我们忘了CGI是怎样没落的话,看起来 G-wan声称已经解决了这个问题。

唔,C,这看起来不是个问题,大量人使用C。

 

但是,kolidon发现,函数原来好少,库原来也很少(虽然官方说放dll进去就能被使用,但我放了个pdflite进去,呼呼,使用不了)。

这个平台上的C,比PHP快400倍,比C#快5倍,比Java快8倍,我强烈相信。——但是,没有常用函数怎么办?怎么做快速开发?没有包和面向对象怎么办?怎么做企业级开发?

我不想每天25-30行代码地去写。我想每天200行代友。

我不想错过wordpress还有joomla还有drupal还有jeecms还有dotnetnuke。

 

不过,转回来,很多公司发现nginx/php/membercache/mysql的链条中,PHP才是最弱的一环,因为它在请求处理能图上差了一个数量级。

于是他们构建了自己的方案,来替代php做脚本处理。有更多,有了自己的memcache变体。

那么,如果用G-wan,会怎样?专用来处理切割困难、逻辑相对简单但耗时的大请求代码代码?

听起来,似乎是个好主意。

但是,就如某些人在PHP里掺Python还有scala/java一样。把我们的服务器平台搞得这么复杂有什么好处?我们来看看这样一个系统:它混合了NetScale, F5一类的硬件平台,squid,nginx,还有apache,现在我们加上上G-wan。当然,有PHP,还有JAVA,还有Mysql,还有Oracle,我们的逻辑也有一部分在Oracle和Mysql里面,触发器,存储过程等等,SQL也是一种灰常重要的语言哦——虽然它们在不同的平台上有大不一样的面貌。当然,有时候,还有一些Python和Scala。

多么美好,从此所有人都有了饭碗。

多么恐怖,从此我们需要让更多不同经验的家伙在一个项目里面和谐相处并且进度上齐头并进。

不过,其实我一直疑心,不同的位置用不同的解决方案或许正是复杂系统所需要的。有时候技术人员需要把架构搞得更复杂一点因为技术已经成为商业模型中的重要组成部分了。外面太多人有了金钢钻准备复制商业模式,我们就整复杂点拼拼人品拼拼细节吧。

杯具啊杯具。泪奔呀泪奔。

ps: G-wan不是开源,这里的free是免费,不是自由,当然,更没有公开源代码。如果开源,这个东西确实会,很好玩。

某友,在某大型组织的国内总部做manager,周五晚十一点四十忽然电话我,让我跑他办公室去帮忙搞定内部系统的收发邮件问题,因为他们的邮件系统近几天切换到了EXchange2007,导致现有的WEB系统平台亦需升级。他已经为此事折腾了十多小时了,情况没有任何改善。这个内部办公和信息化平台以邮件聚合为信息的核心,他确实需要整个系统在下周一恢复以便中国办公室数百员工能够在下周一正常使用此系统。

打车赶到他们大院,朋友在大院门口高兴地等待他想像中的救星。这次没有像以前一样被登记。在办公室坐定,没有理会以zend framework为框架开发的一大坨文件,按错误提示Google之,发现是zf的 bug,mail/protolcol/pop3.php,此文件中某处换行符写列为\n。而针对exchange这种windows系统,\n可能不能在任何时候都顶用。当然,一分钟后,系统从服务器自动抓取和分析邮件的功能就恢复了。

这时朋友的MSN中有家伙在欢呼——是他们系统承包商的工程师,也是最初此系统的开发者,他已经帮着折腾了一整天,这时仍蹲在MSN上保持热线联系试图解决问题——可惜的是,他们都没有试着把一个德语的站用google译成英文,当然也没有看到这种小众问题。我试了,于是成功了。

如此easy呀,终于有闲暇看看他新换的合用办公室了,大屋子里还从着另一位实习生美眉在加夜班,唔,忙碌着往欧洲打电话,年轻、漂亮,让人惊艳。

且慢,因为有些文件中的smtp配置是单独的,也需要修改。那么,问题出现了,系统以前收邮件用的是ZF的mail,发邮件用的是Swift,很奇怪的选择。

更奇怪的是,我竟然搞不定它。

1. 改配置后仍不能再发,内网电脑outlook测试帐号没问题,远程到我的某台windows服务器,oe测试亦无问题

2. telnet建立smtp服务器初始连接,starttls然后提示验证方式gssapi ntlm,这表明是可以正常到这一步的,当然没有继续试因为swift应该能搞定接下来的步骤

3. 继续折腾swift,有意义的google结论几乎没有

4.决定换成PHPMailer,仍然无法连接,这下主要是两种错误:

Unable to authenticate SMTP/Failed to connect to server/unable to relay

不用说,第三种故障可以很快解决,一般需验证才能向域外发信,测试果然是无ssl、无用户名密码时只能向域内发信。

5. 开始和前两种情况博斗但已经很累了,因为认识事情很简单但偏偏无法搞定,故费了大量的时间在日常检查上。也跑了swift和phpMailer的官方DEMO和自制demo,试过所有配置方式,均告失败。

6. 天色近亮,朋友还要上法语课。于是安慰他说当然还可以让邮件服务器管理员将此服务器ip设为不需验证。但我们都知道这种方式很愚蠢。

7. 回家睡了半天,下午参加了个活动。

8.晚上忙完例行的背单词任务,继续奋战。这次在自己机器上远程搞,因此可以利用机器上的十八般武器了——当然主要还是SmartSniff,在自己的outlook上配置然后试发,然后看抓到的包里的那一大坨smtp会话。

9.暂时不管抓到的东东,继续折腾配置,检查和确认几个测试服务器上的OpenSSL扩展都是开着的。

9.折腾一小时,老路看来是走不通了。可能是睡足了的缘故,忽然灵光一现,重新留意到STARTTLS和接下来的GSAPI还有NLTM,等等,为什么没有LOGIN?

9.妈的,Swift以前能发的原因是不是因为其默认验证方式是符合旧邮件系统的LOGIN?

10.好吧,仍然不行,虽然看起来似乎是解决了整个问题中最愚蠢的部分。虽然事实证明前面的一晚上其实是在更愚蠢的基本配置和代码检查、环境检查上转圈。

11.等等,telnet中的IP为什么和ping的IP不一致?妈的,我很清楚他们有很严密的防火墙,并且内外网解析成不同的IP,但我昨天在内网关了测试WEB服务器的防火墙也一样搞不定呀。并且嗅探到的dns解析过程也很他妈正常,也非常能确定这是一个被验证过的邮件服务器主机名。

12.死马当活马医,将配置文件中的domain name换成IP,结束了。

于是扔邮件给朋友,告诉他不用紧张了,现在是周日凌晨4点但我们已经把事情搞定了,早上当然可以多睡一会儿白天当然可以继续安心学法语。

那么,这就是一个从一分钟变成十小时的故事。这样的奇遇和巧合,不论在我还是菜鸟时,还是现在自以为是WEB及周边问题解决专家时,一直上演。

得承认,很多时候,除了使用基本功、我引以为自豪的想像力、无穷无尽的工具,还有他妈的——运气。

好运的是,如果想要解决一个问题,无论花了多少时间,我总能得到一个让同事/客户满意的解决方案——因为,如果从理论上可行,我会去找一解决这个问题的google记录档,或者,自己开始,如果从理论上不可行,那么,在最早回复他们。

Google不能告诉你一切,唔,至少,不能告诉你基于基本功的直觉,也不能告诉你分析、研究和解决问题的思路。

kolidon

About this blog

致谢:
本博客近日收到第一笔捐赠 200元 人民币。
一旦捐赠人愿意公开昵称或姓名,将开设专门页面记录。


关注WEB应用系统架构,侧重效能、可用性研究。欢迎访问treeber.com查看本站整理自网络的非原创精华(筹建中)。