前几天，网易公司声明将停止与中国红十字总会的合作，理由是对方不接受网易在线捐赠系统。
评论：或许，我们当初也应当把钱捐入“廖冰兄人文基金”，而不是什么“中国红十字会总会”。
出处：http://www.scmbbs.com/cn/othertp/2008/5/othertp46.php
您可能不信，早在17世纪中国古籍中就有“昼中或日落之后，天际晴朗，而有细云如一线，甚长，震兆也”的记载，1935年我国宁夏的隆德县《重修隆德县志》中记载有“天晴日暖，碧空清净，忽见黑云如缕，婉如长蛇，横卧天际，久而不散，势必为地震” 之语。
但是，世界各国对于地震云的研究还是最近几年的事，其中以我国和日本处于领先地位，我国对地震云的研究始于1976年唐山大地震之后，目前成功的例证有十余个，日本利用地震云预报地震成功的例证有上百个，有趣的是，首先提出“地震云”这个名字的不是地震学者，而是一政治家，他就是日本前福冈市市长键田忠三郎，他曾经亲身经历过日本福冈1956年的7级地震，并且在地震时亲眼看到天空中有一种非常奇特的云，以后只要这种云出现，总有地震相应发生，所以他就把这样的云称为“地震云”。
那么，什么样的云才是地震云呢？这种云的最大特点在于“奇”，与一般的云有着明显的区别。
地震云出现的时间以早上和傍晚居多，地震云持续的时间越长，则对应的震中就越近，地震云的长度越长，则距离发生地震的时间就越近，地震云的颜色看上去越令人恐怖，则所对应的地震强度就越强。
条状震云
扇状震云
排骨状震云
这两天正忙于项目的验收提交工作，哎，我们公司有个近乎变态的规定：阁下提交的项目文件、安装文件要由项目无关的人员，甚至是完全不懂技术的人员按照编译说明进行编译。为简化编译过程，同时也为减少麻烦，俺决定编写批处理文件来搞定这一切。以下是需要注意的内容：
这个不用说了，.Sln是Visual Studio的解决方案文件，编译的时候只需要安装.Net Framework后就可以使用MSBuild可编辑.Sln文件。不过按照官方的文档说明，MSBuild目前只支持7.0~9.0版本（即Visual Studio 2002~2005生成）的.Sln文件。如果你用的是Visual Studio2008，需要做以下处理：
.Wse是Wise Install System工具的项目文件（即安装脚本），原来一直以为只能通过Wise的GUI来进行手动编译，查了它的帮助文件后发现在命令行中亦执行编译命令。下面的内容摘自Wise自带的帮助文件：
补充说明
根据“buxiangliumingzi ”网友的提示，发现其实Framework 3.5中的MSBuild支持Visual Studio 2008生成的.Sln和.csproj项目文件。
中国科学院工程地质力学重点实验室 李世煇
在西方现代科学技术主导下，破坏性地震（5级以上）的预报，特别是临震预报是不可能的。这是国内外地震界主流的共识。从这个角度看，42年前的唐山地震和今天的汶川地震都是不能准确预报的。凤凰卫视“有报天天读”提到：有的报纸说唐山地震是“三分天灾，七分人祸”；“时事辩论会主持人说：如果唐山地震时不拒绝外援，不会死几十万人。这些是看法不符合实际。实际情况是，如果尊重中西文化优势互补的科学家的意见，这些灾难倒是可以避免的。请参阅本人博客上转载的有关文章。
在中国，一批（1970年代）年轻的中国地震工作者学习中国传统文化的精华（包括充分利用历史文献记载和“取象比类”的方法等），取得遥遥领先国际的科研成果。例如，耿庆国根据历代(包括1956-1970年)大旱与地震关系的统计，发现“6级以上大地震的震中区，震前1-3.5年往往是旱区。旱区越大，干旱时间越长，相应的震级越高”的统计规律（公元512年-1879年中国大旱后2-3.5年，发生了7次7.5-8级大地震）。1972年耿庆国提出“旱震关系大地震中期预报方法”，根据这一规律，耿庆国预报了1975年的海城地震，特别是1976年的唐山地震。在1980年代出版了专著《中国旱震关系》（科学出版社）。这些成果触犯了地震界当权者的利益，耿庆国被调出预报队伍，去了地震报社。
今天，2008年5月12日，听到四川汶川发生7.8级强震，中国的地震科学家耿庆国欲哭无泪，心里在流血。2006年他根据旱震关系提出中期预报，近年阿坝地区将发生7级以上地震。4月26日和27日中国地球物理学会下属的“天灾预测委员会”上，以委员会的名义，作出“在一年内（2008.5-2009.4）仍应注意兰州以南，川、甘、青交界附近可能发生6-7级地震”的预报（文字报告已报中国地震局等，4月30日密件发出），而且，根据强磁暴组合，明确提出“阿坝地区7级以上地震的危险点在5月8日前后10天以内”（以上地震预报三要素均已明确）。明明是国宝，却受到当权的主流地震科学家的排斥，只能靠微薄的退休费坚持搞科研。可惜这位退休的地震科学家的话，没有起到作用。
我的感觉是满腔悲愤。什么时候耿庆国、汪成民、任振球、王迪兴等一批国宝才能不受排挤，放开手脚为振兴中华效力呢？
摄于2006年12月17日“从海诚地震到青龙奇迹研讨会（第20次天地生人学术会议）”会前，左为耿庆国，右为汪成民，中为李世煇。
首发在博客园
我这些年来用过的UML工具加起来没有几十个也有十几个，觉得其中最好用的仅有两个：其一为Visual Paradigam，其二为MagicDraw UML。至于大名鼎鼎的Rational Rose（现在是IBM Rational Rose），乃是我见过的最大、最难用的怪兽，嘿嘿。
什么是好用？在我的经验中，所谓好用须满足两个条件：首先是快，其次是漂亮。
1、快，也就是使用便捷。想象一下，自己在舞动鼠标之前想好了一打的类图、用例关系、协作关系，但一旦坐在电脑前打开你伟大的建模工具，却一直等到把构思忘得一干二净还怎么也画不出两个方格（类图），这样的工具你会用吗？所以，这建模工具的第一个必要特征是快；
2、漂亮，恐怕不少兄弟对这点不以为然——我们使用UML建模的时候，首先得对自己所画出来的东西感到赏心悦目不是？别千辛万苦画出一堆很“精确”的图形出来，看起来却惨不忍睹，够打击人的吧，嘿嘿。
至于其它功能，比如说生成代码、逆向工程、双向同步什么的就不提了，因为咱也没几个人用这些复杂的玩意，是吧。下面我们介绍两个工具：
Visual Paradigm（以下简称VP）
VP作为SDE的组成部分，曾获得过第15届Jolt震撼大奖，这个工具好在哪里呢？
首先当然是“快”，它能快到什么程度？这么说吧，你的思维有多快，它就能工作得多快！呵呵，我的同事曾戏言：使用VP，一会儿就能画出一大堆UML图来。我们看看VP如何工作（以画类图为例）：
第一步，从工具箱里把一个Class拽出来放置到工作区域中，然后输入类名，然后一切就搞定了——开玩笑的，呵呵；
第二步，把鼠标放在你刚才放置的Class上头，看见什么了？嗯，这个Class的周围出现了可用关系的快捷链接，如下图1所示，阁下要做的只不过是用鼠标把这些快捷链接上拖一下，然后在新产生的对象上做一下类似于第一步的操作而已。
我们再来说说它的“漂亮”——实际上，兄弟我对VP自己使用的图标异常不满：什么嘛，入眼的全是蓝色而且图标很土。我所言“漂亮”指的是我们可以使用VP画出符合自己审美观的UML图来，看看下面这张图：
是不是感觉世界很美好？
MagicDraw UML（以下简称MagicDraw）
MagicDraw是No Magic公司的产品（名字有点意思），曾得过多届Jolt大奖中的生产力奖（Productivity），我知道的有第15、17两届。上面说Rose是一个大怪兽，实际上单从体积上说来MagicDraw其实也不小，其12.0版的安装文件就达168M之多。要不是好用，俺早就把它扔到不知哪个角落里头啦。
MagicDraw又好在哪里呢？先说快，它只比VP慢一点点，嘿嘿——我们来看看MagicDraw如何工作（以画类图为例）：
第一步，从工具箱里把一个Class拽出来放置到工作区域中，然后输入类名——你看到什么了吗？类似于VP的快捷链接出现在这个类的右侧，所以这第二步的操作其实与在VP里头一样，如下图
这MagicDraw只为当前具有焦点的项显示快捷链接，而在VP里只要鼠标移动到图形的上快捷链接就会显示出来——这就是我所说的，MagicDraw要比VP慢上一点点。
说到漂亮，我觉得MagicDraw要比VP要好上一点点：感觉界面上要协调一些，至于画出来的图嘛，两个工具差不多。下面是MagicDraw画出来的整张图：
最后得告诉大家一声：这两个工具都有公众版（Community Edition），大家可以自由使用。VP的官方网站是http://www.visual-paradigm.com，MagicDraw的官方网站是http://www.magicdraw.com。
今天在CSDN上看到一篇文章，题为“微软专家承认Vista保护系统安全能力有限”，其内容无非是微软的人承认Vista并不是完全安全的、通过什么什么方法可以如何取得系统控制权等等。
这个题目起得真是让人迷糊，问题是：你见过安全能力无限的操作系统吗？
首发在博客园
RssBandit项目中的CollapsibleSplitter作为Splitter控件的改进版，提供了我梦寐以求的功能：可以像Splitter控件一样分割两个相邻控件，允许在运行时调整他们的大小，还提供了单击时最小化指定控件的功能，并在小小的分隔条上画出了相当直观的精细图案。哦？你还没有这个控件，可以到这里找到它。
这个控件有不太令人满意的地方吗？嗯，有的。它永远只能有8个像素宽（纵向摆放的时候），不能将它设成Splliter默认的4个像素宽，也不能异想天开的将它设成16个像素宽。
打开CollapsibleSplitter的代码文件——我怎么闻到了一股不太美妙的气味呢？哦，那边Martin Fowler同志说了：这是代码的坏气味，该给它除除臭。
那么我们就来给它消除异味吧。
先来看看这个玩意到底有些什么坏气味：
这是ToggleSplitter()方法里的代码，这个控件中还有很多这样的代码：if(controlToHide.Visible)
{
if(useAnimations)
{
...
if(parentForm != null)
{
if(this.Dock == DockStyle.Left || this.Dock == DockStyle.Right)
{
...
}
else
{
...
}
}
...
}
else
{
...
if(expandParentForm && parentForm != null)
{
if(this.Dock == DockStyle.Left || this.Dock == DockStyle.Right)
{
...
}
else
{
...
}
}
}
}
else
{
// control to hide is collapsed
if(useAnimations)
{
...
if(this.Dock == DockStyle.Left || this.Dock == DockStyle.Right)
{
if(parentForm != null)
{
...
}
...
}
else
{
if(parentForm != null)
{
...
}
...
}
...
}
else
{
// no animations, so just toggle the visible state
...
if(expandParentForm && parentForm != null)
{
if(this.Dock == DockStyle.Left || this.Dock == DockStyle.Right)
{
...
}
else
{
...
}
}
}
}
下面的是animationTimerTick()方法的代码（实际上还被俺去掉了几个if...else...嵌套），有这样代码的方法还有三四个：
switch(currentState)
{
case SplitterState.Collapsing:
if(this.Dock == DockStyle.Left || this.Dock == DockStyle.Right)
{
...
}
else
{
...
}
break;
case SplitterState.Expanding:
if(this.Dock == DockStyle.Left || this.Dock == DockStyle.Right)
{
...
}
else
{
...
}
break;
}
...
臭味如此明显，更显除臭工作之必要，呵呵。那我们就开始伟大的除臭工作吧，还有呢，刚才说了“它永远只能有8个像素宽”，这个特性也不太好啊：对于视力好的人，这个分割条显得如此之大；而对于优点近视的人呢，它又显得如此之小。如此，我们自然应该把这个8像素限制去掉。
那现在我们的除臭工作目标订好了，如下：
好吧，那我们就开始工作工作吧——还是下一篇文章再来吧，上班时间文章写得太长会被老板K的...
