RedMine是领先的软件项目管理软件,基于MySQL和Ruby on Rails。
我在实验室项目管理中架设了RedMine开发版。
基于个人信息化策略的需求,希望当某个issue更新的时候能获得一个邮件通知。还好,RedMine提供了这项功能。
在管理->配置->邮件通知中可以管理发信信息。

[singlepic=15537]

1. 配置SMTP服务器
不打算用外面免费邮箱的SMTP服务器。在Windows Server 2003上使用Manage Your Server为服务器添加SMTP和POP的邮件服务器角色。没什么好说的,Server 2003这一点很方便,装好之后也不需要重启。

2. 配置RedMine Email配置脚本
在RedMine的config目录中,有一个email.yml.example文件,重命名为email.yml后用文本编辑器打开,更改production段的内容。因为我是用本机做SMTP,我是这样改的:

[code=’css’]
# Outgoing email settings
production:
delivery_method: :smtp
smtp_settings:
address: 127.0.0.1
port: 25
domain: hpcc.tongji.edu.cn
[/code]

根据你的情况修改即可。需要登录的话可能要这样:

[code=’css’]
# Outgoing email settings
production:
delivery_method: :smtp
smtp_settings:
address: 127.0.0.1
port: 25
domain: hpcc.tongji.edu.cn
authentication: :login
user_name: redmine@somenet.foo
password: redmine
[/code]

保存后需要重启RedMine的Ruby服务器。

3. 管理->配置->邮件通知
到这里去发测试邮件,一般就没问题了。我是新架,出现一个错误:550 5.7.1 Uable to relay user@domain.com。
这是SMTP服务器的典型错误,一般情况如果你新配置的SMTP服务器默认配置下出现,只说明一个问题,MX记录未正确设置。我想看这篇文章的人一定懂得什么是MX记录了。去你的域控制器DNS中添加一条MX记录,指向你的SMTP服务器就可以了。
再次发送测试邮件,我的Gmail瞬间收到了邮件通知:

[singlepic=15538]

Have fun!

环境说明
我们项目中使用了一个Web Service,返回List对象,在SOAP中即构成了XML格式字符串返回客户端。
客户端使用WebServiceSoapClient类调用Web Methods。
使用的开发环境是Visual Studio 2008,.NET Framework 3.0,部署在Windows Server 2003上。全部采用英文版。

问题说明
某个返回List的Web Method,一向工作正常。某日在数据库添加了一条记录之后,开始出现Exception。Visual Studio 2008调试报错:
A first chance exception of type ‘System.ServiceModel.CommunicationException’ occurred in mscorlib.dll

然后我们分析认为,是这条记录格式有问题,我们把原记录中“BLACKMAGIC”字符串改成“BLACKMAGIC2”,问题依旧;改成“BLACKMAGI”,问题不见了…
于是第一次就这样了。

过几天又插入一堆记录,CommunicationException又出现了。这一次我试图调整List中包含元素的个数,发现134个可以,而135个不行。猜测Web Service返回的XML字符串有长度限制。本地调试,手动保存了134个和135个返回的XML文件,查看大小,134条记录的文件大小,著名的81,920 bytes给了我重要的猜测证据。

经过一番Google,翻了几个网站,整理得到的解决方案如下:
之前我们使用简单的WebServiceSoapClient构造,会导致81,920 bytes是Web Service XML返回值的最大大小限制:

[code=’c#’]
WebServiceSoapClient proxy = new ITS.ServiceReference.WebServiceSoapClient();
[/code]

使用另一种构造函数并设置返回消息最大值:

[code=’c#’]
System.ServiceModel.BasicHttpBinding binding = new System.ServiceModel.BasicHttpBinding();
binding.MaxReceivedMessageSize = int.MaxValue;
System.ServiceModel.EndpointAddress address = new System.ServiceModel.EndpointAddress(“http://serveraddress/webservicename.asmx”);
WebServiceSoapClient proxy = new ITS.ServiceReference.WebServiceSoapClient(binding, address);
[/code]

则问题解决。原来第一次去掉一个字符,刚刚好够81,920 bytes。

先看一篇瘾科技的《小姜杂谈:PB 的挑战》

[singlepic=15462]

什么是 PB?抱歉,各位苹科科的爱好者们,我说的不是 PowerBook;抱歉,各位化学爱好者们,我说的也不是铅。这里想说的是 PetaByte (也就是 1000 TB,或 1,000,000 GB)的纪元来临时的挑战。1 PB 的纪元?现在就想这个做啥?毕竟现在硬盘主流连 1TB 都还不到不是吗?从数据储存的角度来看,这样说是没错,七月号的 Wired 杂志上举了几个很生动的例子告诉我们,其实要用光 1000TB 的容量还蛮困难的:

  • 现在出去买一台玩家级的新电脑,容量大约是 1TB(或者,小姜库存的*哔*片也大约这个数)。
  • 每周上传到社交网站 Facebook 上的照片总量是 20TB。
  • 哈柏太空望远镜从发射以来产生的总数据量大约是 120TB
  • 大型强子碰撞器每周产生的数据量大约是 330TB。
  • 美国国家气候中心所以收集下来的资料总量约是 460TB。
  • Youtube 上所有的影片的总量约是 530TB(比想象中小?)。
  • Ancestry.com(一个家族追根数据库)加上内附的 1790-2000 人口普查数据大约是 600 TB。

看吧!PB 的事还是留给后代子孙去烦恼好了,看起来要一次用掉 1PB 还早呢!是啦,要变出 1PB 的数据看起来是有困难,但从数据处理的角度来说,1PB 只是 Google 服务器每 72 分钟处理的数据量而已。虽然从数据储存的角度来看,我们还处在 TB 时代,但已经有很多预兆告诉我们,下一个量级单位带来的会是完全不同的一组新挑战。小姜在后面想了五个可能:

PB 时代的第一大挑战是什么?就是数据的过滤。就算人类已经有产生 PB 级数据量的能力,但事实是我们并没有把这些数据全部有效地存取的技术。因此选择哪些数据更有价值,就成为了很重要的课题。之前就有提过的大型强子碰撞器, 事实上因为是在观测为时非常短的现象,因此每秒大约要拍下十亿张的照片,才能确保不漏掉什么重要的事情。如果全部的数据都要保留的话,每秒钟就必须储存 10PB 左右的数据 — 也就是说每秒钟会塞满 10,000 颗 1TB 容量的硬盘。这是一个靠现有技术绝对不可能办到的事情,所以必须靠硬件和软件的过滤,找出每秒大约 100 个值得关注的事。即使如此,一年仍将产生约 15PB 的数据,或 15,000 颗 1TB 的硬盘,藏在这些数据里头的,有黑洞、异次元、平行宇宙,还有两三个诺贝尔奖吧?

第二个挑战,是资料的分析。 分析和过滤不一样,过滤是试图减少数据量,但分析却是变出更多的资料来。一个例子是选举结果的预测 — 一个仔细想想并没有意义,但无论候选人、选举人还是媒体都乐此不疲的游戏。美国在 2004 年时,候选人 Howard Dean 收集了 100GB 的资料来分析,当时被认为是一个很恐怖的大数据库。今年的总统选举,Catalist 公司收集了一个 15TB 的超大数据库,详细分析每个人的性别、婚姻、年龄、种族、收入等各种资料,并且从中获得判断一个人会投给共和党还是民主党的重要信息。依照同样的比例增加 下去,下一次美国总统选举时的资料量和分析结果肯定会达到数 PB 之谱,届时对数据探勘、分析所需的运算资源的要求会非常可怕,或许非要用 Cloud Computing 的方式才能运算的地步。嘿嘿,或许到时候预测系统都比你自已清楚你会投给谁…

第三个挑战,是数据的呈现。 这是一个比较抽象的关念,举个例子来说好了,目前的数码相机分辨率都高达 10mp 或更多,但一般人用的屏幕就算是最常见的高档屏幕分辨率(1920×1200)事实上才 2.3mp 而已。那多的那些资料不就可惜了?Wikipedia 现在就有点这种感觉,很多很好的文章和内容因为不容易取得,很难发挥它应有的真正价值。

第四个挑战,是数据的传输。 之前在网络上看过一个很有趣的问题:将 1PB 的资料从美国西岸送到中国,是用传输的快,还是用帆船把整个服务器运过去快?一点简单的数学告诉我们,要在合理的时间范围内把数据传完…就假设三个月 好了。要在三个月内把 1PB 的数据传完,传输送率要大约 1Gb/s 才行。这个数字不是特别的不可能(学术单位间常常有这么大量数据来往),但绝对不是一般民众能负担得起的。以目前的技术来说,如果你要传 1PB 的超高画质*哔*片给在美国的朋友的话,绝对是用海运的比较快…

最后,第五个挑战,是数据的搜寻。 拜 Google 大神所赐,这或许是我们最不须要要担心的一环了。但 Google 的强大也仅限于公开的网络而已,自已电脑上的档案要能分类清楚依然是很困难的一件事。Windows Vista 本来想要加入的 WinFS 档案系统和随之而来的关连式档案架构似乎带来了一线曙光,但最后我们还是被卡在树状结构的 NTFS 里。当个人电脑数据量也到 1PB 的时候,嗯,真难想象到时候会是个怎么样的恶梦。

个人电脑容量跨越 1GB 门坎是多久以前?好像差不多是十年前左右,所以如果发展方向不变的话,再十年我们就会进入全面 PB 的时代。但在那之前,就们就已经有够多要担心的事了:在上面的五个问题当中,小姜最担心的是数据的传输,因为传输频宽的建立要时间和金钱的投入。要能够顺 利地提升到下一个阶段,现在就要开始做准备啰!

信息技术或者说计算机技术在发展过程当中遇到了若干个瓶颈,我之前在《SMP in Linux》一文中提到过这些瓶颈以及解决方法。现在看起来,CPU多核和众核已经成了趋势,在Intel的驱动下普及应该不会有太大问题,硬盘也开始以难以置信的速度迅速扩张,希捷一年出货硬盘1.83亿块, 每秒钟近6块。看起来,网络速度已经成最近相当一段时间内的最大瓶颈。正如小姜提到的,1PB的资料从美国西岸送到中国,是用传输的快,还是用帆船把整个服务器运过去快?这个问题现实中我真的是天天面对着。
我的DreamHost硬盘很大很大,2TB大,而传输速度实在不敢恭维,在中国,我需要先把数据传到一个骨干网服务器上,然后挂着传到美国的服务器。即便这样,一个月我也只传了几十GB数据而已。
纵然技术迅速发展,无良的ISP依然收着难以置信的价格,甚至奥运村也不放过。与美国日本韩国相比,我们的宽带速度甚至连人家小灵通上网速度都不如。
我有一个梦想,睡在凉爽的骨干机房里,享用着100MB直接连接到骨干网的网速,该有多爽~

大家通常使用的32bit Windows系统最大内存限制基本均为4GB,64bit的Vista Ultimate则最高使用到128GB。但在服务器领域,这样的规模显然是不够的。虽然Windows Server 2008 32bit标准版内存限制同为4GB,但到了数据中心版,32bit系统也能够达到64GB。至于64bit,Windows Server 2008标准版支持32GB,数据中心板更是达到惊人的2TB。早期的Windows Server 2003也能通过更新支持2TB内存。
市面上拥有2TB内存的系统并不多,但微软的Windows Server性能优化团队肯定要有一台。一位微软工程师近期在博客上探讨Windows内存支持问题时,就贴出了这样一张震撼截图:64处理器核心+2TB内存的Windows Server系统。

[singlepic=15461]

去年在MSRA曾经见到过几台8核32GB内存的Server,存储都是TB级别。这一台似乎更牛一些~
我的梦啊。当年还疑惑,这么大内存是怎么插上去的?还曾经问过几个微软员工,他们也都不清楚。研究生一年让我知道了这个问题…

最近的上海一直晴天,除了温度稍微高了一点(38度左右,睡觉有点困难),天色还是很不错的。蓝天白云,往窗外望望看上去真的很舒服,景物的对比度也超高,感觉置身国外了。

今天早晨Wendy忽然说,我的Google主页怎么变成这样了?
我跑过去看,赶紧截图,不过还是犯了错误,应该打开源程序看看啊…
我观察到的情况几秒钟之后就恢复了正常,猜测应该是某员工更新服务器的时候失手犯了个小错误。

[singlepic=15449,600,450]

换域名到现在两个月整,Google PageRank迎来了又一次更新。
这一次我的域名从没有PageRank资料一下到了3,算是个相当不错的成长。
越来越有经验了~