Tag: 计算机与 Internet

计算一下备份的成本

现在1.5T硬盘的价格是899（以前几日购入的价格），现在的市场价可能已经可以接近800。它格式化后容量是1.36TB（以我格式化为Mac使用的HFS+计算）。1.36TB应该等于1392GB。1GB的价格是899/1392 = 0.6458（元/GB）。目前DVD盘片，三菱的50P桶装盘片价格是95，而威宝（三菱子品牌）的价格是75，太阳锈电的盘片已经买不到了（按理说价格更高一些），这样我们可以按照居中的80元一桶基本靠谱的DVD+R盘片（50P）。我这里使用每张盘片4.25GB计算（可以刻录4.3xG，不过个人习惯是小于4.3G，而且由于文件大小不一，经常会有浪费，所以这种计算这理想个值），那么1GB的价格是80 / 4.25 / 50 = 0.3765 （元/GB）。这样计算的话两种存储方式的价格在一个数量级。

作为数据存储，以前我的习惯是重要的盘片刻两张，而且使用两种不同的盘片品牌（因为它们不同批次的衰老曲线完全不同，我遇到过很多批次的DVD盘片会在几个月后出现大量数据坏块），这样存储价格就要翻番。而硬盘存储也会遇到同样的问题，我们一般会使用Raid解决。如果使用简单的Raid 1或者JBOD则也同样是存储成本翻番，如果使用Raid5的话（3+1，利用率62%，则成本会好一些），但是加上支持Raid的设备的话Raid 5可能比翻番还要贵一些（Raid 5控制器比较贵，因为基本上只能见到硬Raid 5）。这段考虑的问题基本上不会对两者的对比产生太大影响，但是证明两者如果要相对于自己来说保证它们的可靠性要花费的成本都基本上要翻番。

但是我们这里要对比另外一个成本。使用成本。由于DVD刻录无法无人值守，所以时间成本非常高。在工作以后，我们的剩余时间很少，时间就更加宝贵。我观察到一个现象，就是我刻录的光盘大都出现在我的高中后2年（99-2000）还有大学4年与研究生的前一年半（2000-2006）中。后来刻盘的数量就直线下降了，大部分数据都留在了硬盘里面。主要就是没有那么多时间整理数据并刻盘，一般来说刻录只占准备时间的1/4，另外1/4可能在寻找刻盘的资源（如电影、软件等），2/4的时间在整理和享受这些资源，最后的1/4是刻盘的时间。但是由于把数据切分为适合刻录的容量是很费时间和精力的，而这部分又没有直接的经济价值，所以这个浪费是一定要想办法消除的。消除的最有效办法是不制造这么多数据，不去备份它们，这个我们另说。主要说是否可以不刻录，而让他们在硬盘上等待被删除或者享受后删除。大部分时间，我遇到的问题是硬盘不够用，所以我的cache就不够用，这些资源经常要被我暂时移动到光盘上，这是我刻盘的主要理由。但是不幸的是，这些盘一般也是最早被我抛弃的。

下面进入正题，由于前面分析的存储成本上硬盘已经不到光盘存储成本的2倍（我的计算结果是1.7倍），而硬盘会极大的缩短备份时间，所以已经完全没有必要选择使用光盘备份了（光盘目前只适合分发）。下面是一些原因：

  1. 光盘的可靠性太差，而硬盘在使用Raid后可靠性会比光盘强很多（这个待我差好资料再讨论）。
  2. 硬盘存储在5年左右后完全可以通过非常廉价的转存来实现升级，而光盘不可以（如果把几百张DVD转存到蓝光是多么的可怕？）。
  3. 硬盘的传输速率比光盘高很多，现在的硬盘在使用SATA的时候可以达到90MB/s以上，而DVD+R在16x下的速度是6分钟刻录4.7GB（也就是0.78G每分钟，合成13.312MB/s）。在使用USB接口的时候硬盘一般也可以达到40MB/s以上的速度，比DVD要快很多很多。而且由于不用切分，硬盘备份是非常简单的。
  4. 硬盘是随机读写设备，而光盘是顺序只读设备。所以硬盘可以方便的管理，删除、移动、重命名，好比写程序的时候可以实现不断的重构。而光盘则只能整张扔掉或者重写（可读写的光盘由于速度和可靠性的原因这里就不讨论了），这是最为讨厌的Bad smell。
  5. 体积！1.5TB硬盘在Raid 1以后的体积一般是18cm x 18cm x 18cm。但是这些数据需要326张DVD……326张DVD的体积大概是15cm x 15cm x 58.56cm，这个是不装在盘包里面的价格，装到盘包里面体积会翻翻。那么大概是5倍的体积……
  6. 在搜索的时候，硬盘可以使用操作系统提供的搜索功能。而光盘你需要使用where is it这样的软件来管理，其麻烦程度比使用操作系统的索引查找要高上很多，主要是这会浪费掉你很多宝贵的时间。

经过分析，我决定以后放弃使用光盘存储。光盘存储只会作为暂时的数据分享和重要数据的异地备份。这样我一年就可以节省下相当可观的时间了。而且也可以给我的笔记本剩下几个光驱的钱，何乐而不为？

1.5T硬盘到手

我的硬盘总是不够用，因为以前有集图的习惯，也有收集音乐的习惯，再加上现在高清电影的泛滥，还有吃空间的TimeMachine，所以硬盘吃紧是没办法的事情。正巧赶上硬盘再一次降价，1.5T的Seagate 7200.11系列单碟375G的硬盘只要899，所以赶快再上一块（小插曲是，老婆说这个算是生日礼物，sigh~）。配合3个月前入手的1T那块，基本解决现在的硬盘不够的问题了。

我家两块外置硬盘，一块被命名为DeepForrest (1.5T, USB)，也就是现在这块。令一块被命名为BlueRay (1T, USB+1394a)。上图：

P1110155.jpg 一块儿到来的还有一个Tp-Link的WL-841N的802.11n路由器，300Mbps的无限连接，评测的数据是可以达到100Mbps也就是我家有线网的速率。

P1110157.jpg 型号是ST31500341AS，就是1500GB空间，375G单碟，4碟装，台式机硬盘。听说CC1G这个固件版本不是很好，我做外置硬盘倒是无所谓。

P1110159.jpg 现在的Seagate使用了和WD一样的反装电路板，两年以来这个技术已经普及了。

P1110162.jpg 装到盒子里面去。我使用的是WD的硬盘盒，实际上是拆机货。WD的外置盒子其实质量很好，没有访问的时候会自动断电休眠，还有个好处就是便宜。

P1110167.jpg控制芯片是目前高端盒子常见的Oxford semiconductors出的OX921S，这个盒子是三个里面最简单的，单USB。

P1110151.jpg 他们叠放在我的桌子上就是这么个效果，就是那个破音箱上面的三个发光的小家伙。这个照片是上周日的，实际上硬盘还不是1.5T的，不过意思是一样的。

现在正在迁移数据中（mv -v）。以前很喜欢玩硬件，常去Q3ACN雷神硬派玩，也经常写评测，但是现在已经没有那个闲心了。但是我依然喜欢玩硬件，我依然对它们充满好奇心。^___^

我的书柜

看到Fenng同学共享了自己的书柜的照片，我也想把我的书柜照个像放上去。

这几年买书也上万了，当然不都是计算机的书，还有很多闲书 P1110170.jpg

经典的技术书籍占了我的书柜的绝大部分区域。还有一些漫画书，大都是大学时代留下来的。 P1110173.jpg

一些放不下的书就随手放在转角的书柜里。 P1110171.jpg

为书花钱大都值得，不过技术书容易过时，处理的时候又舍不得。即使是好书，它也会对你的移动性产生不良的影响，搬家的时候这些东西可是太沉了。

工具－不会用不丢人，怕会用才丢人

工具就是进行生产劳动时所使用的器具。工具的目的在于提高生产劳动的效率。感慨于一些真正的Geek的blog，我也想了一些工具对于我的重要意义，用来作为下一段的目标。

人家说工欲善其事必先利其器，还有磨刀不误砍柴工，实际上在说明工具对提高工作效率真的非常有意义。

今年的我，上游离于前端开发和后端开发之间，同时我还要在两个不同的团队（ThoughtWorks Studio的Cruise和Mingle两个产品开发团队）之间切换，所以对于我来说频繁的需要Context Switch（工作环境切换）。两个团队所使用的技术也不同。

  • Cruise是一个标准的Java团队，大家的开发工作站都是Ubuntu环境，IDE是Intellij IDEA，源代码控制是Mercurial（aka. HG），自动化构建脚本基于Ant，持续集成工具就是自己开发的Cruise。
  • Mingle团队是标准的JRuby on Rails团队，大家开发机器是Macbook pro或者Mac mini，编辑器是TextMate（JRuby部分有IntelliJ IDEA的工程），源代码控制是Git，自动化构建脚本基于Rake，持续集成工具有两个，其中提交前使用的precommit CI是基于我们公司的开源产品CruiseControl.rb，而主持续集成服务器是基于Cruise（也就是前面那个团队的产品）。
  • 两个团队所使用的敏捷环境是Mingle，用过Mingle的朋友知道，这个NB的工具的可配置性很高，这两个团队的Mingle项目模板区别很大。
  • 这两个环境的区别还是相当大的，而且每次我切换了团队（大约2个月的周期），我很有可能就需要很大的更新我的Macbook pro上面的各种库。
  • 当我做前端开发的时候，我还要切换与我的Mac上的Photoshop CS3和Mac的VMWare Fusion上的Fireworks中（使用Windows的Fireworks的原因是授权，我的正版授权是Windows的）。使用Fireworks的原因是我们的设计师使用它，所以我需要使用它来调整一些小的设计。
  • 在做Javascript逻辑的部分，我需要在Firefox 3/2、Safari 3、IE6/7（VMWare Fusion）之间切换，每个浏览器都有不同的附加调试工具（主要的三个Firebug、Inspector、IE Dev toolbar）。

我想对于一个强悍的程序员（最近比较崇拜的delphij、hdcola、云风等神人）来说做这样的环境切换也许还是可以的。可是对于我这个不善于multi-task工作的人来说，马上让脑子适应不同环境，熟练使用不同的工具就成为了一个挑战。

所以，结果是，这一年中，我基本上对于这些工具很少深入学习，基本上就是凑合着使用，如果没有通用的快捷键我就懒得去翻手册学习了。结果就是使用HG的queue功能（超级有用的qnew、qrm、qpop、qpush系列）的时候经常把自己搞崩溃（今年居然有和李彦辉教授在pair的时候搞丢了2个小时内的修改，相当丢人），所以后来在使用HG的时候异常小心，生活在心理阴影下面。而对于Git，我居然完全没有使用过stash功能（和HG的queue类似）。昨天胡凯还问我是否用过bisect，是一个折半查找坏提交的功能（在HG和Git里面有等价的功能），我完全没有使用过。因为这些精巧的基于命令行的源代码控制工具对于程序员来说非常之重要，从这个角度体现了我对于工具的不求甚解达到了什么程度。突然想到梅兰芳里面十三燕那个很棒的台词“输不丢人，怕才丢人”，用不好工具没事，但是害怕学习用工具那就是很丢人的问题了。

那么自我分析的结果就是，由于环境切换，我缺少了专注，形成了对学习环境中的工具的恐惧，最后影响了我的工作效率。

下面的内容用来自勉，分析一下工具对于我到底有多么的重要（也就是说这个是我使用和学习工具中比较Happy的部分）。对于还没有注意到工具重要性的朋友，可以关注一下，看看是否有所借鉴。

  2. 关于GTD：去年看了不少退墨的文章，我深感这种意为减轻压力的“Todo list“对我的重要。最早我使用了文本文件来记录，每天一个文件。但是后来发现跨天完成的任务使用这种方式不好，需要手工拷贝。所以后来按照每个Context（家、单位、电脑、手机…）放一个文件，然后使用日期作为风格，跨天的任务我就拷贝一下，这个文件本身放在EverNote里面实现多平台共享。但是后来我发现这样也不好，因为不明显，也不好做计划。再后来我开始使用iGTD，发现似乎不错，它的结构比较简单，而且它分开了context和project两个概念，所以像“OpenParty、Mingle、Cruise、梦想”也有了自己的归宿。GTD的做法，please google之。
  3. 关于工作和休息的切换：一开始我惊艳于Livid修改过的TimeOut这个软件，但是它运行的经常很慢。后来我使用了原版的AntiRSI这个抗劳损软件，它的原理就是根据你设定的时间提醒你做短休息（一般是15分钟，站起来休息30秒），还有长休息（一般是45分钟，站起来休息5分钟）。再做结对编程的时候弹出它可能你的pair会有意见，但是你需要通过它的实际效果来感动他们。结果是Mingle的队友已经基本上都在使用它了。
  4. 分布式版本控制工具：DVCS可以帮助你更好的管理本地分支，让分支变得轻量，而且它还可以帮助较大的分布式团队更好的管理自己的本地主干。而且他们里面还有很多帮你管理提交习惯的工具，比如前面提到的提交队列工具，可以鼓励你使用更加频繁的本地提交。当然使用分布式版本控制工具的前提就是你要仔细阅读一下hand book，学习一下他们的基本概念和原理，这样才能达到更好的效果。
  5. Feeds工具：我使用Google Reader阅读文字型RSS Feeds，使用iTunes订阅Podcast。
    • 阅读工具多了去了，你的选择很多。但是要做的是学会更好的使用这些工具。今年从Patrik lightbody那里学会了重构Rss Feed订阅的重要性，要减少一个feed使用多个tag进行管理，因为一般鼓励在一定时间段里面保持未读feed不要积攒太多（这就失去了持续阅读的能力），但是如果使用多个Tag标记feed，那么在统计未读条目的时候往往会重复统计，会造成很大的阅读压力，而且对于给自己的不同feed组定不同的优先级也不利。
    • 所以我首先做的是将所有的订阅单一化，分类清晰了很多。分类有一个小技巧，不要对个人博客按照主题打标签，比如以前我给robbin的博客打上java的标签，而livid打上了apple的标签，那么在我决定要看哪个标签下的主题的时候就会感觉很迷惑，因为个人博客都没有固定主题，所以这些标签就编程没有意义的误导了，所以我现在对于这类feed直接标记为“Interesting Person（有意思的人）”，我可以给这些人很高的优先级。
    • 另一类是如Gizmodo、Lifehacker这种信息门户型，他们每天要更新50+的新条目，所以我把他们放到一个单独的如news portal这样的分类里面，我可以给他们很低的阅读优先级。
    • 不同优先级的条目在Google reader里面还可以对应列表/展开的方式查看，可以很好的提高使用效率。再有就是Google Reader的快捷键，在吃午饭的时候，右手用来吃饭，左手可以通过一个空格健来实现滚动和查看下一条，s是标星，Shift+S是共享，这个基本上就可以实现单手阅读了，很方便。
    • Podcast是坐地铁上班时很重要的学习工具：因为地铁和很多交通工具非常拥挤，即使带上书也没有空间看（尤其时备上电脑上班的我们）。所以在非常拥挤的时候我会选择听音频的Podcast，如锵锵三人行（了解时事）、开卷八分钟（了解好书，不过越来越没意思了）、Ruby on Rails Podcast（Rails的）、RailsEnvy、TackSharp（JDD主讲的关于摄影）等等。在不是那么拥挤，也就是胸前有10厘米以上空间的时候，我会选择看视频Podcast，最精彩的是TED Talks的演讲，不错的有Apple Quick Tips、X-Play Game Previews等。用这种方式消磨时间比用PSP好很多。这是一个购买iPod touch 2的理由^__^
  6. 信息分享服务：这个又是一个很大的话题。大家在聊天的时候经常感觉很有收获，原因是兴趣相投的人在互通有无可以带来很多的有用信息，而不是像电视的新闻节目或者报纸那样给你带来没有针对性的噪音。社会化网络SNS实际上是个很好的分享有用信息的平台，可是我不是很喜欢facebook等给我带来的参与压力，所以我一般通过一些通用的分享服务来满足自己的需求。
    • 我一般通过Last.fm来实现音乐播放历史的跟踪，通过它的推荐服务来发现一些我喜欢的音乐。这实际是一个相关度算法的应用场景，它不同于简单的试听型的网站（现在国内的xiami.com、kedou.com我觉得基本上属于这种类型），它的目的不是给你知道的音乐听，而是根据你听过的音乐推荐你一些音乐听，收集音乐品味的过程叫scrobbler，我在使用iTunes放音乐以后会被自动同步到last.fm并用来做数据挖掘。使用Last.fm服务需要注意的就是要及时更正你的mp3-tag信息，这样你提交的数据就不会是垃圾，这对未来享用推荐服务非常重要。但是现在我发现的一个问题是，由于中文有简体和繁体，所以很和多时候Last.fm的亚洲歌手的名字都会出现多个版本，这给推荐带来了难度，也许国内的服务上可以帮我们解决这个问题吧。使用iTunes的朋友可能苦恼于mp3-tag信息乱码，那么使用Glider开发的ID3Mod2这个软件。
    • 看电影和看书通过豆瓣就很爽了，我对它使用的很初级，但是豆单等已经聚合过的相关分组已经可以给我看电影很多启发了。使用豆瓣这样的工具我们要做的就是尽量及时的更新你的阅读列表，这样豆瓣得到你的更多数据，那么推荐也会更加准确。
    • 我非常珍惜Google Reader的share功能，尤其是share with note。因为这个几乎是最好的和靠谱的朋友分享信息的手段，我一直认为这个是最好的一个人肉过滤器，你的朋友圈子越准确，得到的share也就更符合你的品味。自己在share的同时，可以看到你的share的朋友就和你做了非面对面的交流。而且有的时候如果你1个月没有读feed，已经无从看起的时候，完全可以把他们置为已读，然后去看朋友的分享。这减少了很多信息过滤的成本。
    • 最后一个重要的分享服务就是Twitter了。Twitter解决了你不能和所有的你想交朋友的人聊天的缺憾，这样你可以轻松的follow业界大牛，如d2h、kent beck等。它也是一些重要信息的最快速发布场所，同时也是一个重要的社交场所。在使用Twitter以后我发现我甚至越来越少的在使用IM软件了。使用Twitter这个工具你需要做的就是有节奏的发信息，而不是三天打鱼两天晒网，这样大家不会因为你太贫而退订你，也不会因为常年见不到你的twitt而忘记你。
  7. 信息存储服务：网上看到好东西我们经常想收藏，这种行为叫做网摘，最早我使用CyberArticle（荣幸的买了正版，用的很High），而后用了Linux，所以改用Scrapbook，作为firefox的插件它是跨平台的。此时我的同时推荐我使用在线的Google记事本，这几个软件都能很好的做网摘。但是这几个软件的缺点是缺少协作，那么后来最常见的就是社会化书签应用，delicious，在浏览器装个插件以后它可以帮你用tag管理书签，好处是还顺便帮你做推荐服务，很方便。后来我发现并非只有这些数据需要存储，我们还需要网络磁盘服务，这类服务很多，我个人倾向于使用Dropbox，它的好处是各个平台都有客户端（Win、Mac、Linux），而且是用户空间磁盘系统，用起来和本地磁盘一样，它同样可以用来在项目组之间共享一些文档、电子书等。最后，我还推荐一个类似M$的OneNote的免费在线文档、及数据存储服务EverNote，我用它来存储一些简单的文本文档，还有用它写一些视频note，因为它有一些方便的工具帮你来做音频或者视频的记录。（对了，还有梦断代码里面描述的难产的软件Chandler，它是一个本地的数据中心软件）
  8. 快速启动服务：就是使用键盘快捷索引的启动工具，有代表性的是QuickSilver（是Mac下的，详情看Robbinlu的这篇blog），它显然比Mac自己的Spotlight好用（而它又比win下的很多桌面搜索强很多很多）。通过培养这样的软件可以帮你极大的提高效率。Windows下有launchy也很不错。
  9. 还有很多，但是我没有必要一次全部说完……

下面要分析一下我做的不好的地方，迎来跟踪我的改进：

  • 没有认真的学习Git和HG的用法，没有很好的贯彻他们的最佳实践。
  • 没有很好的学习shell。很少给自己写脚本来提高每天工作的效率。对很多*nix命令还很不了解，如wc、du……，对于微语言awk等不了解，这就限制了我制造自己的组合工具的能力。
  • 没有学习如何使用Mac的automator和appleScript。
  • 对于C语言的了解太初级，还是大学上课的水平，而它又是读懂很多code的关键（我并不想成为c程序员）。
  • 没有很好的整理好自己在各个网站的帐号。所以经常忘记去使用这些服务。
  • 没有很好的整理自己家的硬盘，没有对里面的电影和音乐进行过删减。因为数据也会过期，如果总是舍不得那么它们都被积累为工作噪音。所以要勇于与过去告别。
  • 没有好好学习Photoshop和Fireworks的使用，总是在使用低效的重复劳动。
  • 没有管理好自己的博客。我今年做了的事情就是把blog从BlogJava和Live Space移动到了朋友的机器上的wordpress上，但是由于访问速度比较慢，而且离线的时候写东西不方便，我今年也很少写blog post。
  • 没有学会使用一个有效的照片库软件，iPhoto的分库功能我最近才知道，不过没有认真整理（要减少单个iPhoto Lib的大小，这算个最佳实践）。我也应该学会使用一个LightRoom或者Apeture那样的面向摄影的后期软件。
  • 没有学会使用图片分享服务，我游离于flickr、picasa web和好看簿之间，前两者现在都有了iPhoto客户端，但是我还没有很好的使用。在9的内容做好后，我要更好的利用图片分享服务。
  • 没有很好的学习Ruby on rails，虽然一开始仔细阅读并且也用1.0的rails写了些小应用，但是我的知识没有及时更新。
  • 没有很好的清理自己的数据遗迹，我这个人很注意备份，但是没有注意清理过期的备份，想个好的工具来解决它，如TimeMachine。
  • 没有使用好Facebook和Linkedin这两种SNS，它们实际上能够帮助我很多
  • 没有利用好我买的图书，书是学习工具，而不是收藏品，我没能很好的阅读它们。

暂时先准备写到这里，其它的关于工具的话题我会另开post来总结。（最后更新于2008年12越21日）

[转载］Ruby的并发的一些基本限制

因为是feedburner的feeds，所以我就转过来。

Concurrency is a Myth in Ruby

by Ilya Grigorik

Concurrency introduces parallelism into our applications, and threading is, of course, one way to achieve concurrency. But it turns out that in Ruby, this relation is not transitive: execution parallelism is not the same thing as threading. In fact, if you’re looking for parallelism in your Ruby application, you should be looking at process parallelism instead. So why is that?

Ruby under the covers: Global Interpreter Lock

To understand what’s going on, we need to take a closer look at the Ruby runtime. Whenever you launch a Ruby application, an instance of a Ruby interpreter is launched to parse your code, build an AST tree, and then execute the application you’ve requested – thankfully, all of this is transparent to the user. However, as part of this runtime, the interpreter also instantiates an instance of a Global Interpreter Lock (or more affectionately known as GIL), which is the culprit of our lack of concurrency:

Global Interpreter Lock is a mutual exclusion lock held by a programming language interpreter thread to avoid sharing code that is not thread-safe with other threads. There is always one GIL for one interpreter process.Usage of a Global Interpreter Lock in a language effectively limits concurrency of a single interpreter process with multiple threads — there is no or very little increase in speed when running the process on a multiprocessor machine.

Deciphering the Global Interpreter Lock

To make this a little less abstract, let’s first look at Ruby 1.8. First, a single OS thread is allocated for the Ruby interpreter, a GIL lock is instantiated, and Ruby threads (‘Green Threads‘), are spooled up by our program. As you may have guessed, there is no way for this Ruby process to take advantage of multiple cores: there is only one kernel thread available, hence only one Ruby thread can execute at a time.

Ruby 1.9 looks much more promising! Now we have many native threads attached to our Ruby interpreter, but now the GIL is the bottleneck. The interpreter guards itself against non thread-safe code (your code, and native extensions) by only allowing a single thread to execute at a time. End effect: Ruby MRI process, or any other language which has a Global Interpreter Lock (Python, for example, has a very similar threading model to Ruby 1.9) will never take advantage of multiple cores! If you have a dual core CPU, you’ll have to run two separate processes.

JRuby is, in fact, the only Ruby implementation that will allow you to natively scale your Ruby code across multiple cores. By compiling Ruby to bytecode and executing it on the JVM, Ruby threads are mapped to OS threads without a GIL in between – that’s at least one reason to look into JRuby.

Process parallelism

The implications of the GIL are surprising at first, but it turns out the solution to this problem is not all that complex: instead of thinking in threads, think how you could split the workload between different processes. Not only will you bypass an entire class of problems associated with concurrent programming (it’s hard!), but you are also much more likely to end up with a horizontally scalable architecture for your application. Here are the steps:

  2. Partition the work, or decompose your application
  3. Add a communications / work queue (Starling, Beanstalkd, RabbitMQ)
  4. Fork, or run multiple instances of you application
  5. Not surprisingly, many of the Ruby applications have already adopted this strategy: a typical Rails deployments is powered by a cluster of app servers (Mongrel, Ebb, Thin), and alternative strategies like EventMachine, and Revactor (equivalents of Twisted in Python) are gaining ground as a simple way to defer and parallelize your network IO without introducing threads into your application.

虽然本文是介绍Ruby1.8、1.9和JRuby对线程的不同实现。但是却清晰的解释了线程安全的意义，还有为什么MRI（或者同样使用GIL的CPython）需要使用多进程模型部署。再延伸我们可以知道Apach上面的Mod_rails(Passenger和Ruby Enterprise Edition）还有Mod_python的神奇之处，他们都hack并实现了使用fork让进程共享内存。最后本文还同样引出了为什么传统Ruby和Python应用只有使用多进程才可以利用多个CPU，还有为什么Twisted和EventMachine使用了单进程单线程+event IO的模型。

InfoQ“构建的可伸缩性”文摘

InfoQ上面的一篇文章《构建的可伸缩性和达到的性能：一个虚拟座谈会》
http://www.infoq.com/cn/articles/scalability-panel
这篇文章很好，给了你很多做可伸缩性的线索，记录下这些点滴。推荐感兴趣的人去InfoQ阅读原文。

  • ab & httperf: 它给我们提供了一些自动化的负载测试，因此对比于我们从firebug中获得页面级的计时，使用这个工具可以获得会话级的计时。
  • firebug:
  • Ganglia是非常优秀的。同时Nagios或Zabbix（举个例子）将告诉你何时资料遭到破坏，使用少量加工你就能够让ganglia给你提供任何东西。
  • 对于MySQL，Innotop + slow query log 帮了大忙
  • GDB和DTrace是用于C++的基础架构。core或 pstack是个颇有价值的工具
  • 我们使用各种工具来重现问题并调试它们（包括栈的问题）——Visual Studio、 Eclipse、WinDbg、cdb、Purify、Fortify、dtrace以及许多定制的东西，为我们的架构所构建的东西
  • 从某点上讲，伸缩性已经从领域问题（即，如果你不使用内存缓存或者一个等价的分布式哈希表和基于内存的缓存）转移了，而你仍然处于“领域”范围
  • 当今静态内容的可伸缩性已不那么重要了，那只是花钱的问题并需要公司有好的社会组织的问题
  • 不要试图在部署之前就捕获性能问题。你不可能重建真实环境中的条件，因此你不可能得到真实可靠的测量结果
  • 监测。非常仔细的监测
  • 墨菲法则（一种幽默的规则，它认为任何可能出错的事终将出错）确保了你没有严密跟踪的衡量标准就是那个对你不利的标准！
  • 除非你知道当时正在执行什么业务功能，否则一个CPU测量是无意义的
  • 你只能通过使用软件实现伸缩性。“语言是不能伸缩的。框架是不能伸缩的。而架构是可以伸缩的。”

说说我以为的RIA与Rich client

中午徐X和米高讲了一下Rich client的架构。其中徐X讲的是如何从单机分层系统到Rich client。

实际上最早的单机分层系统的UI部分激发了OO作为界面的编程模型。然后分层模型为了C/S结构发生了一些变化，目的是共享数据和通信，但是由于OO在远程调用上面的失败应用（Corba，EJB，Dcom），所以让人对OO产生了怀疑（实际上只是用错了地方）。而后又发生了B/S的变化，是一种完全的中心共享方式，原因是HTTP的无状态性造成客户端很难保存state，所以就有了完全中心共享状态的架构。而后通过通讯的增强（Ajax），客户端的状态保持逻辑通过异步通信来增强，所以产生了更好的用户体验。但是对状态同步的进一步要求和对会话状态保持的进一步要求让Ajaxian了的应用还是有点难以承受，所以Rich client又回归了。当然回归的时候同时带来的还有新的编程模型，如基于标记的声明式编程模型，还有更方便View-Model同步（通知）的数据binding机制，布局管理器，绘图支持能力，多线程能力，内嵌的视频编解码能力。其实WPF作为Windows上的新型UI编程模型他的确从Mozzila的XUL还有Adobe的mxml吸取了一些经验。上面这些是徐X阐述的主要内容，很精彩（最后的编程模型是我加的注释）。

而后米高做了一些技术层面的对比，主要是对比了Web和rich client的区别，不过我比较失望^___^，因为对比有失偏颇，原因是米高只用了5分钟准备ppt。

最后是我的意见。我现在已经不想割裂的分开Rich client和Web上的RIA，实际上目前他们已经有走向统一模型的趋势。

去年在InfoQ写文章的时候我就表达过这个意见。今天徐X也强调了，经典的MVC实际上很重要的是解决了数据共享（同步通知问题）与状态（会话）保持的问题，所有的架构问题其实都围绕了这个问题。首先RIA里面已经开始了layout数据分离的加强过程，比较明显的就是声名式的组件组合配置，还有数据绑定模型，这个在Flash和Silverlight还有JavaFx都有着重的解决，而且方向都很类似。其中Silverlight其实是一个减缩版的WPF。然后我们从架构方面来思考，解决状态共享和传递是通过增强的双向通信能力来完成的，很多RIA框架在开始提供web socket模型，这样让通讯超过无状态的且单向的HTTP，包括HTML5（目的是扩展Web上常用的一些Object，增强Web的编程能力，且让很多元素得到正确的语义，这个与XHTML2的关注点不同）的草案里面也有Web socket（类似socket的编程对象，可以实现二进制协议的面向连接的通讯）的提案。当然些努力就是让实现消息传递的开销更小，时效性更高，配合线程概念的支持，就可以实现复杂的基于消息的异步界面逻辑（这会极大的扩展RIA应用的能力）。因为通讯其实是解决状态共享的一个方向，通过高效的消息通知达到多个消费端的状态共享。另外一种解决Browser端状态同步（这里主要指客户端与服务器的数据库同步）的方法就是离线存储能力，这样削弱客户端对服务器的依赖。这种解决方案的代表就是各种Gears，Google gears，dojo offline等等，他们在浏览器里面嵌入sql lite一类的数据库，让客户端有自己的结构化存储能力，对于没有多客户端数据同步要求的应用来说离线方式可以让客户端形成完整的编程模型，通过sync机制在连线的时候进行数据同步是一种非常帮的RIA发展方向，从这个角度它已经是Rich client了。

那么可以扩展一下。我们知道Lotus Notes有服务器端replication的模式，离线会存在本地，连线的时候再同步。而对于另一些应用，极端地如Skype，他对实时的同步要求很高（当然它属于通讯类应用，也就是3C中的Communicate，而不是Content system），Skype的解决方案就是p2p。如果RIA有了socket（当然还有跨域支持），有了多线程，那么p2p是不是也不算难事了呢？状态同步通过p2p来实现，虽然不是可靠的通讯方式，但是却符合Internet的最大努力原则，所以我觉得这两种技术的结合的确很容易让RIA和Rich client不在有明显的界限，未来的目的就是融合。所以，要注意的是为什么微软拼了命在推Silverlight，而且拼了命的公布了Mac和Linux版本的Silverlight，其重要原因就是让WPF的模型渗透到RIA，用Rich client围攻RIA，来解决Adobe用超级NB的Air这个RIA衍生来围攻Rich client的困难。

这样，我们知道2年前开始声音渐强的Offline storage和越来越强的绘图，data binding的意图了吧，融合已经开始了，目标当然就是吃下这个大平台，然后成为最大的赢家！

中文网志年会2007


中文网志年会2007

跟大野狼、蚂蚁、二傻参加了今年的网志年会。这里记录下我的见闻。这不是一篇时效性很强的故事，但是看完以后你会回忆起网志年会的点点滴滴。



第一天最精彩的Session-第一天最精彩的Session 飞猪为反波做了一个Keynote。非常酷！Keynote比PPT更容易做出酷的东西。



反波是关于博客Podcast的，会场的整体效果-反波是关于博客Podcast的，会场的整体效果



会场提供的演示用电脑是个Mac MB063，让我看了感觉很激动，不过这个对于居大多数的Windows用户并不怎么友好-会场提供的演示用电脑是个Mac MB063，让我看了感觉很激动，不过这个对于居大多数的Windows用户并不怎么友好



反波的banner做的很吸引眼球-反波的banner做的很吸引眼球



会场的边上有朋友躺着听keynote-会场的边上有朋友躺着听keynote



穿插场中有大量使用Mac的用户-穿插场中有大量使用Mac的用户



中文网志年会到场的也有很多国外友人-中文网志年会到场的也有很多国外友人



换个角度看会场，可以说这次的会演讲的人数与质量成反比，几个论坛形式的话题感觉都是各说各的，没有意思-换个角度看会场，可以说这次的会演讲的人数与质量成反比，几个论坛形式的话题感觉都是各说各的，没有意思



现场的叽歪借机火了一把，想模仿Twitter一夜走红的路子。但是会议有这样的互动方式的确是个亮点。-现场的叽歪借机火了一把，想模仿Twitter一夜走红的路子。但是会议有这样的互动方式的确是个亮点。



这位大哥也用小白，在处理照片，很艺术，他的照片也都很不错。认识这位大哥的朋友可以介绍一下。-这位大哥也用小白，在处理照片，很艺术，他的照片也都很不错。认识这位大哥的朋友可以介绍一下。



VAIO和MAC。感觉还是用黑苹果那位大哥姿势比较牛！叔叔练过是吧…… -VAIO和MAC。感觉还是用黑苹果那位大哥姿势比较牛！叔叔练过是吧……



一位以无影手使用Macbook Pro的老大，英文纯正，拜一个-一位以无影手使用Macbook Pro的老大，英文纯正，拜一个



译言的老大也是标准的小海龟，这个网站绝对是口碑绝佳，所以他一上台就受到了极大的关注！这也是很多人反映的第一天最期待的Session。不负众望，这个演讲也很成功，思路清晰，老大是风流倜傥呀。-译言的老大也是标准的小海龟，这个网站绝对是口碑绝佳，所以他一上台就受到了极大的关注！这也是很多人反映的第一天最期待的Session。不负众望，这个演讲也很成功，思路清晰，老大是风流倜傥呀。



Google docs目前真的是我们的自来水，用它来做演示真的好聪明-Google docs目前真的是我们的自来水，用它来做演示真的好聪明



互动的价值就在这里，活跃气氛呀。玛丽是那位号称台湾Twitter女王的网友，后面有提到。zola是周曙光。-互动的价值就在这里，活跃气氛呀。玛丽是那位号称台湾Twitter女王的网友，后面有提到。zola是周曙光。



现场的笔记也是Google docs，他们在组织杀人……-现场的笔记也是Google docs，他们在组织杀人……



这位大哥的头巾吸引了我的眼球，相当彪悍-这位大哥的头巾吸引了我的眼球，相当彪悍



中间我去照了夕阳，第二天大野狼请我到这里吃了french tea pot，好好吃呀。-中间我去照了夕阳，第二天大野狼请我到这里吃了french tea pot，好好吃呀。



会场后面很多人找Twitter女王签名……那两天相当冷，佩服她的裤袜。-会场后面很多人找Twitter女王签名……那两天相当冷，佩服她的裤袜。



互动网的老大PHD在讲的时候有人去访问了一下互动网……结果出现了有些暴露的美女图，相当的不协调。不过这样的场面倒是挺有趣的。这图明显不够猛，很多人评论说……-互动网的老大PHD在讲的时候有人去访问了一下互动网……结果出现了有些暴露的美女图，相当的不协调。不过这样的场面倒是挺有趣的。这图明显不够猛，很多人评论说……



这个关于大硬盘的评论，汗-这个关于大硬盘的评论，汗



Twitter女王特写……旁边的那位美女是维基百科的台湾区工作人员。那个不是mac小白，而是一个ASUS。-Twitter女王特写……旁边的那位美女是维基百科的台湾区工作人员。那个不是mac小白，而是一个ASUS。 我不是好色之徒，全世界的女人我只欣赏我老婆……
但是不得不佩服人家的生活态度，大冬天串薄薄的，然后坐地上，那小PP是什么感觉呢？想来难受……莫想歪……



这个是Day2了，出席人数少了很多。不过这个logo我比较欣赏。-这个是Day2了，出席人数少了很多。不过这个logo我比较欣赏。



这个还是第一天的……我喜欢这种动中取静的感觉，Laptop会改变你的生活。-这个还是第一天的……我喜欢这种动中取静的感觉，Laptop会改变你的生活。



第一天结尾的时候关于维基百科的附加值开发的论坛，据大野狼说给他启发不小。-第一天结尾的时候关于维基百科的附加值开发的论坛，据大野狼说给他启发不小。



这个是Day2里面最精彩最精彩的Session，个人认为也算是两天最精彩的！Ito博士讲共享经济。-这个是Day2里面最精彩最精彩的Session，个人认为也算是两天最精彩的！Ito博士讲共享经济。 Ito弄出了last.fm等一大堆我很喜欢的网站，拜拜。而且他的英语日本腔不是很重，这个赞一下。
而后有有人问了他The next big thing是什么，他说是mobile设备和video game。感慨人家眼光毒辣呀。
而后又得知，问问题的人是Livid，一直非常仰慕的一位比我年轻的开发者……剃了头不认识了，后悔当时没有过去认识他。



还是Day2，开始的时候一直放这个Clone星球大战splash的video session。-还是Day2，开始的时候一直放这个Clone星球大战splash的video session。



Ito博士的共享经济Topic-Ito博士的共享经济Topic



给本本贴贴纸是一个很酷的行为艺术，GNU和firefox还有Ubuntu估计所有这样的本子上面都会有的贴纸。-给本本贴贴纸是一个很酷的行为艺术，GNU和firefox还有Ubuntu估计所有这样的本子上面都会有的贴纸。



伊藤Ito博士的Topic讲的很好，不过翻译的阿姨表现不是很好，明显很多词都翻译的不对。有点Bilingual能力的人都会不爽，下次推荐让IT业内人士做翻译。-伊藤Ito博士的Topic讲的很好，不过翻译的阿姨表现不是很好，明显很多词都翻译的不对。有点Bilingual能力的人都会不爽，下次推荐让IT业内人士做翻译。



另外一个布满贴纸的Dell laptop-另外一个布满贴纸的Dell laptop



还是MBP养眼，说mac改变生活那绝对不是盖的，想起土老冒罗永浩批评苹果鼠标只有一个键的事……感慨呀。-还是MBP养眼，说mac改变生活那绝对不是盖的，想起土老冒罗永浩批评苹果鼠标只有一个键的事……感慨呀。



大野狼的主要任务就是与各大网站的老大交流-大野狼的主要任务就是与各大网站的老大交流



这个关于CC的图释非常到位，我们很多时候都在fair use，这个的规范过程就是CC要解决的。-这个关于CC的图释非常到位，我们很多时候都在fair use，这个的规范过程就是CC要解决的。



这个Panel是开源软件社区的一个讨论，不过还是有点Boring，但是这几位都是值得敬佩的朋友！-这个Panel是开源软件社区的一个讨论，不过还是有点Boring，但是这几位都是值得敬佩的朋友！ 正在发言的是啄木鸟社区的创始人之一，黄东，他也是从高中毕业就以程序员为职业放弃求学过程的成功人士。他对我有知遇之恩，非常感谢。那天和他讨论了有一个小时，谈好看簿性能扩展的事情，很有启发，感谢老黄。
最右边的Bill Xu，是给招商银行写公开信的GNU教徒，曾经是我的直属上司，以前感觉想法有点偏激，这次感觉明显务实了一些，很高兴看到这种改变。



这个Panel好像是关于内容创造的？keso很多人都眼熟。其它人不认识，基本上这个session比较boring。-这个Panel好像是关于内容创造的？keso很多人都眼熟。其它人不认识，基本上这个session比较boring。



这位是可敬的庄老师！那天的topic得到了现场很多朋友的认可。图上有好看簿logo，庄老师讨论了使用好看簿作为教学工具的好处。-这位是可敬的庄老师！那天的topic得到了现场很多朋友的认可。图上有好看簿logo，庄老师讨论了使用好看簿作为教学工具的好处。 有人这样评价庄老师的Topic：“正统学校的老师做的PPT就是脚踏实地。内容非常扎实，无懈可击。”



keso的设备并不专业，也是拍友-keso的设备并不专业，也是拍友 咳嗽居然用的是sigma的头，机身好像是400D or 40D，没看太清楚。不过镜头如果没猜错是17-50，素质还是相当一般的。这个DSLR估计也就是个拉风的小DC替代品。



托laptop的板子不错，边听讲边用笔记本-托laptop的板子不错，边听讲边用笔记本



还是场外的自由感觉比坐在椅子上还有趣-还是场外的自由感觉比坐在椅子上还有趣



女王拍咳嗽-女王拍咳嗽



继哲Bill Xu在发炎-继哲Bill Xu在发炎



大野狼和诸位名人坐在一起，鹰眼发光呀-大野狼和诸位名人坐在一起，鹰眼发光呀



刚才提到的用小白的大哥在演示iPhone，iPhone在那天出镜率很高。-刚才提到的用小白的大哥在演示iPhone，iPhone在那天出镜率很高。



女王被围拍，这部分俨然是个小王国了-女王被围拍，这部分俨然是个小王国了



老黄发炎-老黄发炎



这位外国友人是个摄影师，同时使用MBP，可惜此时网络连不通……-这位外国友人是个摄影师，同时使用MBP，可惜此时网络连不通……



大野狼所处环境，女孩子用小黑不怎么搭配-大野狼所处环境，女孩子用小黑不怎么搭配



会场的外景，相当壮观！-会场的外景，相当壮观！

以上内容由Diamond Tin!于2007年11月27日创建于好看簿。 点击此处访问原始链接，或此用户的更多内容。

好看簿：用照片记录和分享生活的图片博客”

解决Hg在MacOSX leopard上的locale问题

简短说，因为重新在新mac上装mercurial，没有装macports也没有fink，这次也不想自己编，所以选择了预编译的package。但是后来发现报错！
我用的是http://mercurial.berkwood.com/这里的包，1.0.1的mercurial package，是08-05-25出的那个包。

line 373, in _parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: UTF-8

那么，如何解决呢？这里找到了答案：
http://www.selenic.com/pipermail/mercurial/2007-October/015296.html
解决的方法就是在你的.profile加入下面这样的声明，如果你用的是bash的话。

export LC_ALL=es_ES.UTF-8
export LANG=es_ES.UTF-8

然后就工作正常了，如果想知道为什么，可以看看这里有更详细的原理介绍，LC_ALL是给字体字符集使用的环境变量。
http://www.madboa.com/geek/utf8/

结绳记事，希望有帮助。