Category Archives: 科技评论

软件工程的经验教训

  很早起来开车送家人去医院看病。到单位的时候,牙齿还在打战,北京的天气凉下来了。这周安排和zk一起双人编程,他还没到,我先上来看看Google Reader写点BLOG。

  作为所里的内部培训师,我常被各个中心和课题组请去分享软件工程的经验。这是上周刚做完的一次报告的ppt。我会不断更新内容,感兴趣的同志可以隔三差五地关注我的工作主页的Technical Reports栏,下载最新版。

  收到越来越多的同事的邮件,和我讨论软件工程、系统架构和设计模式。作为国立学术研究机构,我们所处的环境的确不同于商业机构的软件研发团队。但从另一方面来说,总是有更多共性的问题在里面:如何挑选、培训和激励人才,如何做计划并执行……总可以做的更好,更有效率,更有成就感。

  我PPT里没深入写PM自己的心态问题。这是最近两年切身体会到的一个重点。软件项目压力很大,极端情况下,甚至会造成心理伤害。优秀的PM必须有器量和涵养,懂得欣赏优点,愿意信任同伴,既有发自内心的称赞,也有就事论事的提醒,还有开诚布公的道歉,在团队里营造出和谐的气氛来。如果碰到一个鸡贼刻薄的PM,大家心里充满恐惧和抱怨,就会只顾着关注PM想什么,逐渐丧失专业人士的主动性和独立见解。更深入点来说,是否愿意信任他人,也许正反映了PM本人内心深处的安全感。态度决定命运,对周围世界的基本看法,会决定一个人能否得到同事的尊重和喜爱。我最后悔的、常常反省的事,就是有几次在种种压力下冲别人吼,这往往有很大的负面影响。当然,人不是机器,情绪都是波动的,需要恰当的释放,也需要逐渐成熟。总之,PM要提高自我修养,防止负面情绪泄漏给无辜的同伴。

  刚好前两天网上到处都是创新工厂的那副“PM跪求研发”的图片,PM的心态好一点,项目就会顺利很多。zk来了,下次再聊。

PM跪求

PM跪求

怎样测量算法的性能?

  先写一句题外话,我是玩社交网络的,例如豆瓣LinkedIn42区,俺只是不玩新浪微博而已。

  LinkedIn的多核与并行计算讨论组(Multicore & Parallel Computing Group)里,刚刚发生了一次讨论,内容很有价值,尤其是对刚踏入这个领域的新人而言。所以转载到BLOG上。

  一开始,是印度小姑娘Ratika Agarwal问了个基本问题:

 

  How to measure the performance of any working algorithm? do any body know?

 

  Darryl Gove提到了各种经典工具,例如Linux下的Oprofile、Solaris下的DTrace和MDB、AMD的Code Analyst,还有Intel的VTune:

 

  If, by performance, you mean “How long does it take”, then you could use the time command, print out the number of units of work completed and divide one by the other. However, that doesn’t guaranty that your implementation of the algorithm is efficient.

  So I’d recommend profiling. On Linux look at Oprofile, on Solaris (or Linux) you can use the performance analyzer from Solaris Studio (just announced the beta programme for 12.3), on Windows with AMD chips they have a Code Analyst, Intel you probably want to look at VTune.

  Most of these tools will give you time based profiles and hardware performance counter data. So you can look into things like the instruction count, cache misses etc.

 

  John Lilley又提到了Visual Studio Team edition里面的profiler工具。他总结了影响性能的主要因素,优化的时候往往是在各个因素之间寻求平衡。

 

  Also on Windows, Visual Studio Team edition 2008 and 2010 has a built-in code profiler for native code. I think you might get managed code profiling in the Professional versions; however I am unsure about that. However, there are many dimensions to consider when talking about “performance” in addition to CPU. For example, you may want any of the following to optimize:

  1) Memory usage

  2) Disk usage

  3) Wall-clock time (as opposed to CPU loading, which is what a profiler will give you)

  There are many examples of such tradeoffs. For example consider the problem of sorting a file of records. The fastest sort algorithm will probably load the entire file into memory, perform a parallel sort that utilizes all CPU cores as much as possible, and will probably make a complete copy of the data (or perhaps just a copy of pointers to the data), and then write the output file. However, there are many tradeoffs to consider. What if the file is 100GB and you only have 8GB of memory? Then you must store some intermediate results on disk. You might then consider the CPU/disk tradeoff of compressing the temporary data. These are just some suggestions.

 

  Jim Dempsey进一步提醒,优化更多是一项工程活儿,程序性能往往受到具体环境影响:如果数据集中在内存里,那么提高缓存的本地性往往比减少需执行的指令数更重要;而如果面临I/O密集型的应用,选择适当的负载均衡技术是最重要的。

 

  The performance of a given algorithm is not necessarily an absolute property. In reading the prior posts you will find that there are various factors that can affect performance and therefore one algorithm is not always superior to another without considering the runtime circumstances. When your working dataset fits within memory then paying attention to improving cache locality may be more important than reducing instruction count. When I/O is involved then choosing a technique that permits computation overlapped with I/O usually is superior. Overlapping I/O or sequencing the data that is fed into an algorithm is generally not considered part of “the algorithm” but may have more of an impact on application performance than the algorithm itself.

 

  John Lilley顶贴,对此表示同意。

 

  Jim is absolutely right. The “performance” of an algorithm must be judged within the context of the program’s requirements. The kind of performance you want out of a program on a multi-CPU server with virtual memory and a fast SAN might be completely different than what you want from a similar algorithm running on a smart phone. On the server, you might optimize for performance and scalability, On the smartphone, you might optimize for power conservation, memory, and storage use.

 

  Ratika Agarwal表示压力很大,自己是个新手,不知道从哪里开始。

 

  But I’m a beginner.I’m just going to start implementing the comparative analysis of algorithms.actually I need to do a project for my M.Tech thesis.

  Thus I am thinking about, to construct some parallel algorithms of the existing sequential ones. Is that the right path what i am following, for my M.Tech project and thesis?

  Also I am a very new user for parallel programming. Don’t know from where to start.

 

  于是John Lilley给她推荐了书和其他学习资料。

 

  This book: http://books.google.com/books/about/The_Art_of_Concurrency.html?id=rU68SYVS7S8C is a good primer to parallel programming, if you have access. Also read Dmitry’s blog: http://www.1024cores.net. A goodle search on “parallel programming blog” yields good forums in the top 10. Depending on your programming language of choice, I would use “Thread Building Blocks” from Intel for C++, or Cilk++, or if you are C#/.Net, use PLINQ and TPL. On the Mac, there is Grand Central Dispatch. I’m not sure what Java people use. The maintream programming wisdom today is to think in terms of sub-tasks to execute in parallel, not in terms of threads. The aforementioned tools are all parallel task models. This is a concise illustration of parallelizing quicksort using cilk++: http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/cpp/lin/cref_cls/common/cilk_convertcpp.htm. There are many interesting problems out there that that benefit from efficient parallel implementations, especially in the realm of graph analysis, sorting, searching, indexing, and so on.

 

  Jeff Kenton又给了些建议。

 

  Your original question was about ” how to measure the performance”. So, what you need to know is how much faster your parallel algorithm is than the sequential one? And how well does it scale with the addition of more cores / threads? The bottlenecks will likely turn out to be communication between the pieces, and sequential parts that you can’t eliminate.

  You will need to choose a suitable problem to solve. Implement it sequentially first so that you understand the simple version. Then decide what can be done in parallel and how to combine and communicate the results at the end. And also figure out how you will measure your results and how you will instrument the various parts so that you understand what the issues are.

  Good luck.

 

  Christopher Aziz提到了LINPACK指标和openMP。

 

  ”performance measurement” is an important, frequently misrepresented and often misunderstood topic usually associated with “timing”. Notionally, “timing” a race is simple. You click the stop watch when the starter’s gun fires and then stop it when the first runner or horse crosses the finish line. This is the lay person’s view: ” Where is the hard part?”. Certainly not in this simplistic notion. Now a 6 dimensional race with variable non-continuous environmental conditions and a difficult to calculate “finish line” boundary condition might be closer to the practical reality but is far beyond the common conception of “timing”.

  The hard part is knowing what to measure and developing a process model that let’s you confirm the sensitivity, variability, repeatability and ability to extrapolate or predict results in other cases from your measurements.

  Shifting from abstract to practical, I’d suggest taking a look at the netlib.org/benchmark suite. My favorites are the LINPACK variants. Leave the HPL for last. To get a handle on factors affecting results start scalar (1 core) and try different compiler options, machines, size of problem effects and look at run to run variation. As you posted to this multicore group, I’d suggest next converting the codes to openMP.

  For timing consistency, I like the openMP elapsed timer, omp_get_wtime, regardless of how you may effect parallelization. It is portable and generally reliable.

  You are stepping into a huge space. It is a personal favorite. To get a “feel” for the subject area, I think your best first step is to pick a small corner and get deep with it rather than survey the broader domain.

  Good Hunting.

 

  Eugenio Villar进一步补充

 

  In practice, the performance of an algorithm strongly depends on the run-time conditions on a certain processor. The problem becomes harder in multi-processing platforms. And even harder in heterogeneous multi-processing platforms. When your target is the same as the host on which you are developing the code, some of the techniques commented already can be used. If your target is different, then an ISS or a virtualization-based simulator (www.ovpworld.org) can be used. A more abstract technology not requiring the complete compilable code is native simulation (www.teisa.unican.es/scope). We are now working in keeping the accuracy even when the OS calls are removed…

 

  Rick Peralta耐心地逐句解答了Ratika Agarwal的困惑

 

  Performance is relative some metric. There is no absolute performance. You can measure performance relative computations per second. You can measure the relative computations per second based on single or multi-threaded implementations. Of you could measure the ratio of computations to space. Or the quality of the computations (e.g. bits of resolution).

> I’m a beginner.I’m just going to start implementing the comparative analysis of algorithms.

  The first step is to determine what you want to measure. Then look for ways to measure and represent it. Often performance is multi-dimensional and multi-modal, so there is not necessarily a single optimal solution.

  Assuming you are looking for simple computations per second, for various solutions, the wall clock method is a good first step. How long does it take to complete some fixed bit of work. Compile various solutions and see what the run time is. Run the same test for different implementations. On a finer resolution, a profiler can give comparable information for various parts of the code.

> Don’t know from where to start.

  For your research, I’d suggest that you build a benchmark framework that monitors whatever you are looking at (wall clock time, CPU time, memory usage, external I/O, et cetera) and drop in the various solutions. The standard framework will help keep the comparisons comparable.

  Consider the traveling salesman problem. Is it better to do the whole job single threaded, perhaps using the stack to handle branches or to drop each branch to a thread thread or queue to a pool of threads? Code up each and see what the results are. Try to keep the test environment the same, as largely invisible characteristics (such as pipeline behavior or other activity on the system) can significantly impact the results.

  As a general rule, if things are not clear, simplify. Look at a simpler problem, use simpler tools. Too often people get lost in their own sophistication.

  - Rick Keep It Simple Silly ;^)

 

  Eduardo Grosclaude介绍了几本参考书

 

  You may find Grama/Gupta/Karypis/Kumar’s book very enlightening.http://www-users.cs.umn.edu/~karypis/parbook/

 

  Jonathan Beard又给了不少参考资料网址,他同意Rick的说法:“Keep It Simple”

 

  Here’s a few books I’ve found useful that I used for class that are relatively cheap (although I find it best to check out library editions until i really find I can’t live without a book):

  The Art of Multiprocessor Programming – http://bit.ly/pd3fz9

  Computer Architecture: A quantitative approach – http://bit.ly/o7PGoD , although if you don’t have much hardware experience I’d recommend the other book as well Computer Organization and Design.

  You mention creating parallel algorithms from sequential ones, are you planning on an automated process? If so I’d recommend a compiler book, Advanced Compiler Design (http://bit.ly/qK7wm2).

  There are tons of languages to implement parallel algorithms, the choice of which I think should be left to the algorithm and how the author can best express the idea…in other words, don’t get hung up on one language or the next.

  I agree with Rick on the keep it simple. I’d also go one step further and say turn off hyperthreading (not to knock it, but it’s easier to reason about performance without it), speed stepping, synchronize clocks across cores, and when possible tie threads/processes to a specific processor so you know exactly what data you are collecting. Nothing is more frustrating than performing multiple tests only to find out that part of your data must be thrown out because a context swap or frequency increase gave inconsistent results.

  Good luck.

 

  Houmad Tighezza引用了1978年的一本老书里的一段话

 

  The question is simple but the answer good be very complex, the answer depend witch performance you want to know: numerical performance, fault tolerance, CPU, memory, vectorization/ parallelization, speed up, MPIS, MACS, etc.?

  In my opinion, the first book all about the performance evaluation techniques and they application was Wright by DOMENICO FERRARI in 1978 (PRENTICE-HALL).

  Computer Systems Performance Evaluation by Domenico Ferrari 1978 : “The author argues that systems performance evaluation, in the first twenty years of its existence, has developed in substantial isolation with respect to such disciplines as computer architecture, system organization, operating systems, and software engineering. The possible causes for this phenomenon, which seems to be unique in the history of engineering, are explored. Its positive and negative effects on computer science and technology, as well as on performance evaluation itself, are discussed. In the author’s opinion, the drawbacks of isolated development outweigh its advantages. Thus, the author proposes instructional and research initiatives to foster the rapid integration of the performance evaluation viewpoint into the main stream of computer science and engineering.”

 

  Antonio M Flores建议多查查Wiki,上面全是宝

 

  Strictly speaking, algorithms are measured by an analisys of complexity, which is a computer science mathematical concept, so it is irrelevant to the hardware platform. I suggest that you take a deep reading to the article in Wikipedia for a first insight: http://en.wikipedia.org/wiki/Analysis_of_algorithms and http://en.wikipedia.org/wiki/Time_complexity. Of course, for the same complexity algorithms, you can later do profiling, which is a programming concept and for which there is plenty of software tools available: http://en.wikipedia.org/wiki/Profiling_(computer_programming), as well to do a measure of efficiency: http://en.wikipedia.org/wiki/Algorithmic_efficiency

  For parallel versus sequential algorithms, you should be using the concept of speed-up and related: http://en.wikipedia.org/wiki/Speed_up

  Good Luck and Success!!

 

  最后Ratika Agarwal表示感谢。又有一个叫Agnaldo Pereira的新手感谢Ratika Agarwal问了这个好问题,看来对他也帮助很大。

不完备性定理和创业

  忙碌的假期,回来了。这些天买了刘未鹏的《暗时间》村上春树的《地下》黄铁鹰的《海底捞你学不会》。前两本强烈推荐。

    

  最近创业者言必称保罗·格雷厄姆和Y Combinator基金。而Y Combinator这个词源于lambda函数不动点。看看刘未鹏这篇《康托尔、哥德尔、图灵——永恒的金色对角线》能了解更多。简单说,哥德尔对不完备性定理的证明,意味着不可能单纯用一套逻辑系统解释整个宇宙。这不仅仅对数学,甚至对哲学和艺术也产生了重大影响。

  假期结束前一天,参加42qu.com的“42区 . 技术 . 创业”活动。有两个报告人,一位是Resys的创始人xlvector,另一位是PE.VC的投资人Luc Lan。

  两年前听过xlvector的讲座,那时候他还在搞学术,重点是Netflix百万大奖的推荐算法比赛。这次再听,他已经加入工业界,所以就有更多实用化、架构,以及产品的商业效果的考虑。非常期待他的新书。

  Luc Lan的讲座也很有内容。对想创业的程序员来说,“shut up, just code”做出可用的原型来的确是最关键的。至于要不要寻找天使和风投,是根据情况具体分析的。例如:如果自己能筹措资金(互联网创业,启动资金不会太多,一台服务器,机房托管,必要的执照……具体内容张教主都回答过)支撑过最初的一段时间,甚至能熬到有现金收入,就不必付出代价很高的原始干股了;再例如,有的具体行业,资金并不是最大的瓶颈,如海底捞的老板就强调,无法那么快的培训出合格的二级店长和领班,是他们扩张的瓶颈。只有必须用钱来当催化剂,想迅速把现有的已经掌握窍门的业务扩大一百倍的时候,找投资才是对双方有利的事情。对一些参加的朋友有个建议,很多资料是可以通过网络查到或问到的。例如Luc Lan投过哪些项目,给张教主投了多少万,张教主一个月烧多少钱等等……做好功课,是高质量交流的前提。

Microsoft祝贺Linux诞生20周年

  嗯,你没看错。是Microsoft,他们制作了下面这个释放善意的视频。

  自1998年万圣节文档全面宣战之后,Microsoft对开源阵营的态度都很敌视。2000年,史蒂夫·鲍尔默还在说:“Linux is communism”;2001年,他又说:“Linux is a cancer”……

  直到2006年,IE团队和Firefox团队才开始礼尚往来。到了今年,刚发布的Linux 3.0中,Microsoft已经悄然位列RedHat、Intel、Novell与IBM之后,成为第五大Linux Kernel代码贡献者。

招聘程序员、《北京沉没》和Go语言性能

  先转发一篇招聘,我的朋友在做云计算方面的创业,招Flex/Erlang/Python程序员。工作地点在北京,有兴趣的人可以点进去看一看

  5、6月BLOG更新频率明显变慢了,有人问我是不是开始玩微博了,还有人问是不是在准备跳槽。都不是,最近公私事都有些忙,懈怠了,不好意思。另外随着年龄变老,似乎越来越倾向更长篇幅的写作,零碎的想法大多懒得动手敲(记得科学松鼠会上翻译过一篇报道,研究人员发现年龄和写作博客的长度成正比,没搜索到链接)。还是该放松点儿,有长则长,可短就短。只要写出来,总会有价值。

  前两天北京下大雨内涝。豆瓣上马上出现了一篇与此有关的小说《北京沉没》,得到众多推荐,大家都在殷切等待小说的后续情节。

  关于编程语言的性能向来是个大水坑,有诸多争论。前不久,Google公司的Robert Hundt刚刚发表了一篇论文 Loop Recognition in C++/Java/Go/Scala.,,发布了一个简明而紧凑的Performance Benchmarks,分别对C++, Go, Java, Scala四种语言进行性能比较。测试包使用的loop finding算法实现中不涉及任何高级语言特性,只使用了各语言的基础设施:基本容器类、循环和选择、内存分配机制等。文中的主要结论是在32位系统下C++程序最快,常规条件下Java语言运行时间是C++程序的12.6倍,Go语言为7倍;相同的语言条件,不同实现效果差距很大,例如:C++语言如果采用一般教科书知识的“学生式”实现,会比有经验工程师精心优化后的结果慢8倍以上。而Java语言的主要瓶颈在于其内存回收机制,如果采用SPEC优化,则速度起码提高3倍,如果在64位系统下,性能比32位系统提高超过1倍。更多细节,大家可以直接看论文。

  论文对Google自己人发明的Go语言并没有太推崇,认为其性能还比不上C++,开发难度又高于Java。于是Go语言的团队来劲了,刚在官方BLOG上指出,Go语言版本的算法还有很大的优化余地。他们使用了Go开发包里提供的性能测试工具对代码进行了改善,运行速度提高了10倍以上,而申请的内存降低了6倍。

  这篇论文在其他语言社群内也掀起不少讨论。编程语言的性能比较往往涉及到很多因素(编程者的经验和风格,比较题目与不同语言的特性之间的契合等)。对于实际工程而言,选择编程语言的着眼点应该是现有资源和经验,并考虑混合编程。我个人在pFind项目的经验是,保守些,尽量利用团队内多数人熟悉的技术。如果项目负责人只顾着添经验追时髦,把手头的正事当作尝试新技术的小白鼠,十有八九要坏事。

流水帐.2011.6.11

  哪吒系统的云服务,这个月底应该可以开始试运行。

  前一阵发生了很多与驾驶汽车有关的案件:药家鑫、陈家、高晓松……驾驶里程超过6000公里了,不再像磨合期那么诚惶诚恐。北京的路面又像战场,开着开着总会生出些懈怠、暴躁和狂妄来。握着方向盘,就应保持敬畏之心,对自己和别人的性命负责。反省中。

  Bitcoin迅速热起来。范围远远超出了技术圈子《时代周刊》和《三联生活周刊》上都见到了报道评论。前天下载了中本聪(Satoshi Nakamoto)的论文《Bitcoin: A Peer-to-Peer Electronic Cash System》读了一遍。关于其负面评价,张沈鹏向我推荐了张志强的这篇《bitcoin的技术和金融缺陷》。很多人认为,由于严重挑战了各国央行的权威,Bitcoin将会很快受到政府的限制

Linux内核即将进入3.0时代

  昨天Lyz美女编译Linux内核panic了,今天早上和她一起冲进机房去重启。每次进机房都觉得轰鸣声好像飞机的发动机。空调太冷,打喷嚏。

  5月30日,Linus在动身前往日本参加LinuxCon 会议前,将他的Kernel git tree 打上了3.0-rc1标签。漫长的2.6时代终于要结束了。

  2.4内核历时4年24个版本。2.6内核历时6年40个版本。这是关键性的10年,Linux内核已经成为互联网服务的基石,虽然PC桌面进展不明显,但在智能手机领域Android系统大红大紫。回想起99年在rainbow的机器上安装红帽子,那时候Linux刚刚摆脱黑客面纱,被IBM和Oracle等商业公司支持,很多大学老师也没听过。大学生只有在蓝宝石和AKA这类爱折腾的草根技术组织里才有机会接触开源的世界。如今计算机专业科班出身的孩子们,若没用过Linux都不好意思和别人打招呼。

生物数据处理和分布式并行计算

  写一点我对生物信息云计算的粗浅认识。首先,所谓云计算是一个商业模式的概念,其内涵里Saas占很大比重,网络服务代替软件产品。另一方面,技术角度的个人观点,一个Web服务的后台涉及到了大规模分布式并行的基础设施,才有资格被称为“云计算”(当然,这一定义有争议)。这篇Blog先写技术观点,后面再加关于用户和服务的讨论。

  技术上,大规模分布式并行计算被分为计算密集型和数据密集型两类。

  很多物理、地质和气象等领域的科学计算都是典型的计算密集型问题,CPU是瓶颈,涉及到外存I/O量相对不高。对这类问题的解决思路就是传统的“数据找CPU”。具体一点说,目前编程实现的工业标准是MPI,利用MPI提供的Master/Slave模式启动和调度集群上各个节点上的进程,数据传输共享常利用NFS,底层可以用硬件手段提高数据I/O性能。像Fold@home这一类志愿计算项目,往往本质上也是计算密集型的,当然软件架构有所不同。

  而Web领域的计算问题,例如搜索引擎的信息检索,主要是数据密集型问题(或者也称为IO密集型问题),这种情况下,CPU不再稀缺,海量数据的内外存交换的性能成了的焦点。对此MapReduce模式给出了很有效的解决思路,也就是所谓“CPU找数据”。具体来说,Hadoop是目前最热门的主流框架,先对查询对象进行索引,通过分布式文件系统备份到集群各处,再调度相对轻量的进程,分阶段执行查找和归并操作。

  那么有没有这样的需求:输入输出的数据很海量,其处理过程的算法复杂性又很高,很占CPU。有的,例如现代天文学需要对成T甚至成P的哈勃望远镜图片进行搜索过滤……面对这一类的问题,MapReduce模型就不一定适用,其瓶颈出现在海量数据的传输性能上(Web搜索模型里,尽管是数据密集型应用,但被检索的关键词和输出结果是相对很小的,而在很多科学应用里,往集群提交的待查询本身就是海量数据)。Secter/Sphere在其论文和技术报告里总结,它对Hadoop有明显性能优势的原因之一,就是专门开发的底层传输协议UDT比后者使用的通用TCP/IP要高效。

  对Hadoop这个特定产品来说,由于它是Java实现的,相对于C/C++有性能劣势,这个短板对CPU耗费型的应用来说很要命(这也是Secter/Sphere快的另一个原因)。有很多解决方案,例如Yahoo!开发了MPI on Hadoop,用MPI具体负责干活,Hadoop包裹在上层负责宏观调度和容错;而百度实现了Hadoop C++ Extension,把Hadoop里面的关键瓶颈部件都换成了C++的;前不久刚刚发布的Hadoop下一个版本的Roadmap里,也宣布要进行彻底重构,重点解决性能问题。

  生物信息领域,无论是基因测序还是质谱鉴定蛋白,产生出来的数据量巨大,其处理运算又吃CPU。对现有的分布式计算模型是个挑战。其实分布式计算领域,从来都是应用拖着技术走的。例如是物理学家发明了集群运算,是信息检索工业逼出了MapReduce模式。所以,生物领域的挑战也许可以反过来给计算领域一个发展的机会。

关于志愿计算

  3月份,尤其是最后两周,开发‘哪吒’进度压力很大,每天回到家脑袋都木木的。关于上次提到的Mozilla Drumbeat大会,那天有个小花絮:23日和zf双人编程一整天,晚饭都没吃就听workshop,晚上10点钟才筋疲力竭地开车回家。因为疲惫所以车速放得很慢。恰好四环上发生了严重的十几辆车的追尾事故,我却因为开得慢,幸运地躲过去了。

  所以就一直没有在BLOG写,时间一拉长,印象就淡了,现在好像写不出有趣的文字了。不好意思。科学松鼠会刚发表了一篇《志愿计算:足不出户,窥探星辰》,值得推荐,大家不妨看看。

  我个人而言,感觉David Anderson 、Carl Christensen和Elizabeth Cochran的QCN项目(通过大量志愿者的笔记本收集地震波信号)最有趣。尽管普通笔记本电脑安装的廉价震动传感器比不上专业的地震仪器,而且数据里会有日常使用的噪音,但是架不住志愿者数量众多,通过合适的统计工具,就能得到很多有意义的工作成果。23日在北京workshop,他们只给出年初新西兰大地震的数据和分析成果。上网跟进搜索了一下,稍后在台北的Asia@Home workshop里就给出了这次日本地震的数据。

  很多人对报告当天最后一个提问者不满:那个人长篇大论提了很多未必高明的空泛观点,要求在研究成果中占有股份,还建议研究者们把帮助他们的志愿者电脑上的个人隐私信息卖给Google赚钱。且不说Google到底需不需要,会不会买,感觉这个年轻人对商业、法律、科研、公益似乎都缺乏常识,完全丧失了好奇心和想象力。这又让人联想起《非诚勿扰》里那位美国博士安田的事

Android开发和暴雪故事

  最近满世界都是iPhone、Android和《疯狂的小鸟》。就连陪着老婆回娘家,遇到邻居美女来串门,听说我是程序员以后,居然都会被问:“你会Android开发吗,我正在找人……”

  私下里以为,这乌洋乌洋的激动者里99.9%从一开始就注定要失败。很多人并不真正理解这个领域,不知道最出色的技术领跑者拥有什么特质。手头的正事没做踏实,被别人挣大钱的传奇故事刺激一下,开始浮想联翩。我所知道的国内早期靠Apple手持设备挣到真金白银的那些市场嗅觉灵敏的狐狸们,07年就退出这个市场去搞汽车买卖和长期租赁的网站了。(这不,这个领域去年开始热起来,尤其是年底北京摇号限牌政策出台之后。好像联想的风投最近投了一笔)

  话说回来,智能手机时代的确刚开始,让我们对创业、对未来的可能性保持敬畏吧。推荐下面暴雪geek们的故事。