身旁的朋友网友们好像越来越钟情于摄影了，器材越买越多也越高级，甚至开始用摄影来兼职赚钱了。DSLR 的价钱也渐渐大众化，大家都有本事入门体验摄影的乐趣，所以网路上的摄影论坛雨后春笋般冒出，大家兴高采烈讨论器材交流技术分享作品。也许有一天摄影会是众乐乐的全民嗜好。
而我的摄影热情还在这里沉淀着，除了近来的忙碌于工作之外，心底也有一种对之前的摄影追求的目标的厌倦，美丽之外，我觉得自己还要一些东西，一些触动人心，甚至是触发想像空间的元素。我在沉淀着，把心放空，未知的以后，可以在作品里头容纳更纯粹的，超越言语甚至是影像的直接沟通。
柯锡杰在《心的视界》说：[拍风景，不能只是大自然给什么，我就原封不动的拍下来，而是要看这个风景给我什么感觉，然后再把这个风景，变成内心想要的一个影像。好比数学里的减法。如果你看到的是五，一口气把五通通拍出来，结果是寻常的风景明信片；如果你用你的心、眼去体会，拍的是五减二只后的三，才是你自己的风景。一个人的心灵有太多东西的时候，其实什么也体会不到。简单的时候，我们的心才活在一个更大的空间。]
应当如此，“一个人的心灵有太多东西的时候”，真的是体会不到，甚至连摄影的热情都无法维持。可是，那些所谓的“东西”也是很重要的东西，我工作之外，也要跟进业界的动态，各类电脑编程技术和科学技术期刊必须要读。还要学习新的编程语言，那本N年前买的Design Patterns秘笈也还没修炼完成。难道不能够同时专注两件事情？难道艺术的追求一定要一心一意？摄影的艺术，编程的艺术，我只能选择一样？可是我相信，所有各行各业一旦到了最深入的境界，我称它为“道”，都是一致的，纯粹的体会和简洁的表现。正如最出色的照片和最出色的电脑程序，都不繁复。见山还是山，艺术于是成形。
Python 善用双核心？
今天用家里的Intel Core 2 Duo 电脑来处理一些从公司带回来的数据，第一部分是从6GB的数据里头分析出两种不同应用的数据，再分别写入不同的文件，这个部分由java程序负责。最后得到数据文件两份，1.1GB和18GB。接下来要把每一份文件，根据里头的24种数据组别分割成24份文件，这里用上了Python脚本语言。很简单的，从源文件读取每一行数据，再根据数据的组别字符串分别写入相关的文件。处理那份18GB的源文件比较费时，我让电脑运行着，随便看看Task Manager，竟然发现有两个python的程序在运行，其中一个占用比较多处理器资源，另一个不停的写入I/O。是不是python善用了双核心的处理器，大家分工合作，一个处理算法一个处理写入文件的动作？或者，这只是python的一贯作风，分成不同的子程序来处理不同的动作，不过是刚好碰到了双核心的处理器而更好的发挥？
2005年的回顾 (软件技术篇)
站在这个瞬息千变的时代，我是战战兢兢的。尤其是电脑软件的各种技术层出不穷，新的业界标准新的编程语言新的概念甚至是悄悄酝酿的新一波软件革命，知觉的或不知觉的打我眼皮子下走过，我很想努力捕捉一些线索或眉目，却觉眼花缭乱，一眨眼那些热腾腾的新鲜名词已经走远，更新鲜的陆续来着。
繁华也许只是一种假象，那是因为你看不透他们背后相同的本质。
所以我静下心来，尝试整理自己的定位：2005年，我并不完全待在软件工程的领域。我的工作只有一半是在软件工程里头，另一半在文本和语义的研究和实验。虽然说所有的研究和实验是为了语义学的应用软件的核心技术，我总觉得自己在编程或软件的技术上没什么长足的进步。我再回顾2005年里关于软件的领域我的身影：由于公司的项目关系，我完全没接触到microsoft的技术，我荒废了dotnet平台，也没有跟进他的最新发展。我罔顾MS SQL资料库，不曾追踪longhorn和其XAML的发展，甚至对Herb Shutter 和 Stan Lippman 改进的基于dotnet平台的C++/CLI语言也只是匆匆掠过。google 等致力推行的AJAX，我也不曾好好研究。OMG当红的软件开发框架MDA (Model Driven Architecture)我也迟至近几个月才稍微了解。MDA也许是下一波编程革命，就像当年pascal等第三代编程语言对汇编的冲击。MDA的影响也许更大，那些只能够把设计文档转变成源代码的程序员在MDA的架构里的也许无处可站。我身为一个程序员，必然要对这种趋势思量一番，接纳和消化其带来的思维上的冲击。还有书桌上那本几近封尘的Design Patterns工具书，物件导向的发展已经去到模型导向了，我却还没有好好摸索物件导向的设计模式。是技术的前进步伐太快，还是我的脚步太慢？去年曾经拍下胸口说要学以致用的template programming，泛型（generic）, STL库，boost库等等没一件做到。
还好，没接触到microsoft的日子让我亲近了linux。公司里的开发都基于一台64-bits的Itanium伺服器，所以我接触了GCC 编译器，makefile 指令，gdb 除错器等等unix社区熟悉的工具。为了方便在windows和linux平台下编写程序还尝试了IBM的开源软件，Eclipse，从此不再用Borland C++ Builder，直接以Eclipse + GCC + msys 编写通用linux 和 windows的 C++和Java程式。我开始了解32-bits 和 64-bits 编程的一些不同之处。并在一些处理大量生物基因数据的项目里学到一些低阶至bit单位的处理和压缩技巧。也有幸学了python这个高效率的动态语言，虽只是初级的运用，已经能够感受到她在国外流行的魅力了。
就是这样，学到的永远比没学到的少。但这是必然的，创新和生产是一大群人努力的成果，吸收到自己的脑袋是一个人的事情，而时间的流量却是一样的。
当了程序员三年，期间常听见身旁的人说：程序员不能够长久做下去，一定要逐步跳跃至管理层的位置，摆脱写源代码的工作内容。我问为什么，他们说那才能够挣得高收入啊。有时候我一笑置之，有时候我会说一些自身的理念。我说了传承的重要性。
我想编程是一种不停进步的技艺，要到达一定的高度必然需要一段长时间的锻炼和累积，如果只做了五年十年就转入管理层而不事编程的话，又怎么能够有高质量的编程专才诞生？没有高质量的编程专才，也就没有高质量的软件。所以我们第三世界的软件工业其实不是软件工业，因为我们没有产生核心技术，我们只是运用别人的核心技术来生产应用软件，整体上的软件工业可说是偏向服务性质的。他们可以在c++ 0x 标准里增加或删减一些C++的特性或库，他们可以在未来的互联网标准semantic web 设定新的语言 OWL (Web Ontology Language)。我们只能够跟随，并在他们发现先前的设计缺陷而发布新的标准后怨声载道但还是乖乖追随。我们只能够在他们的牵引下走一些已经大概被设定好的路径，用他们提供的工具做一些多只能够在区域内销售的应用软体。我们跨不过那个门褴和他们站在同一条线上有更宽阔的视野，甚至打不开门，他们稳稳把持着那扇门的钥匙。为什么他们有这样子的实力？我想这是环境和教育的缘故。环境来说，他们有很多超过10年经验的优秀程序员，这些优秀的程序员备受重视，除了担任技术或软件项目的管理人之外也勃勃不倦的埋首新技术或写源代码，这直接或间接的也灌溉了其它的年轻程序员。教育来说，他们的大学注重研究，政府也大量拨款各学术机构做各种专门项目的研究，这样子的循环造成了源源不绝的创意和专利的核心技术。这一年里我做研究时常常上网搜寻相关的研究报告或论文，找到的多数是西方大学的，也有少数是亚洲的，譬如中国韩国台湾日本甚至新加坡，就是没有马来西亚的。我不敢下什么定论，也许是我们的研究题目冷门。
新的一年里，我为自己做了一些期许：
1。学习一个新的编程语言，就学dotnet 平台的 C++/CLI吧。
2。多了解MDA。
3。善用python。
4。继续去年的期许：学以致用的template 和好好阅读design patterns。
5。多读业界的杂志和期报，以开拓自己的视野。
共勉之。
繁华也许只是一种假象，那是因为你看不透他们背后相同的本质。
所以我静下心来，尝试整理自己的定位：2005年，我并不完全待在软件工程的领域。我的工作只有一半是在软件工程里头，另一半在文本和语义的研究和实验。虽然说所有的研究和实验是为了语义学的应用软件的核心技术，我总觉得自己在编程或软件的技术上没什么长足的进步。我再回顾2005年里关于软件的领域我的身影：由于公司的项目关系，我完全没接触到microsoft的技术，我荒废了dotnet平台，也没有跟进他的最新发展。我罔顾MS SQL资料库，不曾追踪longhorn和其XAML的发展，甚至对Herb Shutter 和 Stan Lippman 改进的基于dotnet平台的C++/CLI语言也只是匆匆掠过。google 等致力推行的AJAX，我也不曾好好研究。OMG当红的软件开发框架MDA (Model Driven Architecture)我也迟至近几个月才稍微了解。MDA也许是下一波编程革命，就像当年pascal等第三代编程语言对汇编的冲击。MDA的影响也许更大，那些只能够把设计文档转变成源代码的程序员在MDA的架构里的也许无处可站。我身为一个程序员，必然要对这种趋势思量一番，接纳和消化其带来的思维上的冲击。还有书桌上那本几近封尘的Design Patterns工具书，物件导向的发展已经去到模型导向了，我却还没有好好摸索物件导向的设计模式。是技术的前进步伐太快，还是我的脚步太慢？去年曾经拍下胸口说要学以致用的template programming，泛型（generic）, STL库，boost库等等没一件做到。
还好，没接触到microsoft的日子让我亲近了linux。公司里的开发都基于一台64-bits的Itanium伺服器，所以我接触了GCC 编译器，makefile 指令，gdb 除错器等等unix社区熟悉的工具。为了方便在windows和linux平台下编写程序还尝试了IBM的开源软件，Eclipse，从此不再用Borland C++ Builder，直接以Eclipse + GCC + msys 编写通用linux 和 windows的 C++和Java程式。我开始了解32-bits 和 64-bits 编程的一些不同之处。并在一些处理大量生物基因数据的项目里学到一些低阶至bit单位的处理和压缩技巧。也有幸学了python这个高效率的动态语言，虽只是初级的运用，已经能够感受到她在国外流行的魅力了。
就是这样，学到的永远比没学到的少。但这是必然的，创新和生产是一大群人努力的成果，吸收到自己的脑袋是一个人的事情，而时间的流量却是一样的。
当了程序员三年，期间常听见身旁的人说：程序员不能够长久做下去，一定要逐步跳跃至管理层的位置，摆脱写源代码的工作内容。我问为什么，他们说那才能够挣得高收入啊。有时候我一笑置之，有时候我会说一些自身的理念。我说了传承的重要性。
我想编程是一种不停进步的技艺，要到达一定的高度必然需要一段长时间的锻炼和累积，如果只做了五年十年就转入管理层而不事编程的话，又怎么能够有高质量的编程专才诞生？没有高质量的编程专才，也就没有高质量的软件。所以我们第三世界的软件工业其实不是软件工业，因为我们没有产生核心技术，我们只是运用别人的核心技术来生产应用软件，整体上的软件工业可说是偏向服务性质的。他们可以在c++ 0x 标准里增加或删减一些C++的特性或库，他们可以在未来的互联网标准semantic web 设定新的语言 OWL (Web Ontology Language)。我们只能够跟随，并在他们发现先前的设计缺陷而发布新的标准后怨声载道但还是乖乖追随。我们只能够在他们的牵引下走一些已经大概被设定好的路径，用他们提供的工具做一些多只能够在区域内销售的应用软体。我们跨不过那个门褴和他们站在同一条线上有更宽阔的视野，甚至打不开门，他们稳稳把持着那扇门的钥匙。为什么他们有这样子的实力？我想这是环境和教育的缘故。环境来说，他们有很多超过10年经验的优秀程序员，这些优秀的程序员备受重视，除了担任技术或软件项目的管理人之外也勃勃不倦的埋首新技术或写源代码，这直接或间接的也灌溉了其它的年轻程序员。教育来说，他们的大学注重研究，政府也大量拨款各学术机构做各种专门项目的研究，这样子的循环造成了源源不绝的创意和专利的核心技术。这一年里我做研究时常常上网搜寻相关的研究报告或论文，找到的多数是西方大学的，也有少数是亚洲的，譬如中国韩国台湾日本甚至新加坡，就是没有马来西亚的。我不敢下什么定论，也许是我们的研究题目冷门。
新的一年里，我为自己做了一些期许：
1。学习一个新的编程语言，就学dotnet 平台的 C++/CLI吧。
2。多了解MDA。
3。善用python。
4。继续去年的期许：学以致用的template 和好好阅读design patterns。
5。多读业界的杂志和期报，以开拓自己的视野。
共勉之。
阅读源代码
这是吃力不讨好的事情。
我从一个人最初的语言开始摸索进入弯弯曲曲的程式迷宫，企图正确无误的为程式外表和执行结果之间的黑箱作业摹拟一份亮丽的地图。所有的关键地用简单易明的注释发亮，河道和山川一律蓝黄层次铺展。
尤其是没有注释(comment)的源代码,揣测作者的心机象一场远程的捉迷藏，通常要去到很远的地方发现到你要找的人不在那边后折回来再追随另一条路重复又重复，你觉得与其花时间决定要走那一条路，不如每一条路都去走走看，用结果来证明正确的路(Trial and error)。
还有语言的复杂性，如果你从低级语言出发，前路必然崎岖 （不说汇编，看看C++就好，regular expression的函数库我还没看到就要哭了）。还好这几天我走的是高级语言路线，python，最难懂的莫过于连在一起内含3，4个lambda 语法的map 函数，层层叠叠、所谓的抽象化到此地步着实得费一番脑力解读。
其实受到最多好处的人还是自己，好像上了一课python语法的范例，受益无穷啊。
我从一个人最初的语言开始摸索进入弯弯曲曲的程式迷宫，企图正确无误的为程式外表和执行结果之间的黑箱作业摹拟一份亮丽的地图。所有的关键地用简单易明的注释发亮，河道和山川一律蓝黄层次铺展。
尤其是没有注释(comment)的源代码,揣测作者的心机象一场远程的捉迷藏，通常要去到很远的地方发现到你要找的人不在那边后折回来再追随另一条路重复又重复，你觉得与其花时间决定要走那一条路，不如每一条路都去走走看，用结果来证明正确的路(Trial and error)。
还有语言的复杂性，如果你从低级语言出发，前路必然崎岖 （不说汇编，看看C++就好，regular expression的函数库我还没看到就要哭了）。还好这几天我走的是高级语言路线，python，最难懂的莫过于连在一起内含3，4个lambda 语法的map 函数，层层叠叠、所谓的抽象化到此地步着实得费一番脑力解读。
其实受到最多好处的人还是自己，好像上了一课python语法的范例，受益无穷啊。
突发任务
星期一临下班时被老板叫入房间，说有一些紧急的数据需要被处理好以在周末前寄去美国﹔处理数据的程序已经就绪，只差源数据的格式不是预期的ＦＡＳＴＡ格式。所以我的第一个任务是把所有的源数据转换成ＦＡＳＴＡ格式。好的我开始构思，源数据是一个２０Ｇ的压缩档，解压后有太约４５Ｇ。心里略有定案，决定用Memory File Mapping 的放式把整个档案映射到一个unsigned char 的指针，然后所有的转换手续在记忆体完成，这样子的速度会快过从档案里读出、写入记忆体再转换。起初我还淡定的套用OOP的方式来分类、封装等。后来酲悟这是一个针对目前特定情况也许只用这么一回的程式，实在不需要顾虑易用、重用和维护性。再加上解压出来的源档案是一百多个，最大的不过３Ｇ。而且我也懒得实现用指针的方式寻找字串这类的低阶算法。决定转用高级语言脚本Phyton，现成的函数加上简易方便的语法，一小时左右就完成了，再花一些时间调试、修改后就丢进伺服器执行，预期第二天清晨可以拿到结果。事情没有这么顺利，第二天回到公司看见程式在转换到第一百多个档案时挂掉，原因是硬盘的储存空间用完了（如果我事先仔细做个评估就好了）后来换另一个硬盘空间做为输出，两个小时后顺利完成格式转换。心底暗为Phyton的威力赞叹，实在是简单好用的语言，而且多数Linux系统都是缺省安装，也可以当作Shell script来使唤。
然后是第二个程式，用来做一些数据的后期处理，也即是接受另一个程式的输出数据，处理后再输出。我继续用Phyton，测试后发觉Phyton的速度不足以应付３Ｏ０Ｇ的数据（费时太久，而我这Phyton初学者的功力不足以优化程式）。于是花了一些时间用传统的Ｃ语言写了相同的程式，速度快了将近五倍。毕竟脚本语言在处理如此庞大数据下无法比拟编译语言的速度。如果说脚本语言在处理１ＯＯＭＢ的数据比编译语言慢了３Ｏ秒，乍看之下也许没什么要紧，也不过是半分钟的差别，热腾腾的咖啡还在冒烟呢！就算是１Ｇ的数据也还只是等多五分钟而已。可是３Ｏ０Ｇ的话呢？所以那晚在公司呆到十一点半。
来到第四个程式已经是星期四的事情了。是一个简单的验证用途的程式，是要在第一个程式输出的数据里找出重复的数据单位（fasta header）。笨方法是用一个迥圈来检视每个单位，再用一个内迥圈来检视接下来的每一个单位是否和迥圈外的单位重复。如果数据不多的话两个迥圈都不会太久。可是目前数据有二千万个单位，我只好花时间想一个有效率的算法来处理。
无论如何，最终还是做完了这些紧急工作。伺服器开足马力处理着数据，期待明天早上能够拿到完整的结果，也算值得。
然后是第二个程式，用来做一些数据的后期处理，也即是接受另一个程式的输出数据，处理后再输出。我继续用Phyton，测试后发觉Phyton的速度不足以应付３Ｏ０Ｇ的数据（费时太久，而我这Phyton初学者的功力不足以优化程式）。于是花了一些时间用传统的Ｃ语言写了相同的程式，速度快了将近五倍。毕竟脚本语言在处理如此庞大数据下无法比拟编译语言的速度。如果说脚本语言在处理１ＯＯＭＢ的数据比编译语言慢了３Ｏ秒，乍看之下也许没什么要紧，也不过是半分钟的差别，热腾腾的咖啡还在冒烟呢！就算是１Ｇ的数据也还只是等多五分钟而已。可是３Ｏ０Ｇ的话呢？所以那晚在公司呆到十一点半。
来到第四个程式已经是星期四的事情了。是一个简单的验证用途的程式，是要在第一个程式输出的数据里找出重复的数据单位（fasta header）。笨方法是用一个迥圈来检视每个单位，再用一个内迥圈来检视接下来的每一个单位是否和迥圈外的单位重复。如果数据不多的话两个迥圈都不会太久。可是目前数据有二千万个单位，我只好花时间想一个有效率的算法来处理。
无论如何，最终还是做完了这些紧急工作。伺服器开足马力处理着数据，期待明天早上能够拿到完整的结果，也算值得。
Split
分开其实是另一种合成，一栋栋不同功能的建筑物分开放在土地的不同角落，合成了城市。恋人分开形体，合成了思念。我把文章分开来，合成了藕断丝连的句子， 再进一步把句子分开来，一地散落的物体（noun）和动作(verb)，我端详了好久，合成是一则失传的故事，隐隐约约自凌乱的文字尸体间传来一阵笑声。
我从恍惚回来，面对分开(split)的力量不可自拔的留恋起来。其实很早以前就已经看过split这则咒语了，VB Script里就含有这道咒语。却一直到今天我在Python里把一篇篇文章拆散成句子的时候才发觉这到咒语的妙用，仿佛进化成一种亮丽的魔法，悄悄一声呼唤，连亮光都来不及现身，一堆我要的句子列队空降，纪律严明。
尤其是拆解HTML tag 时，譬如：
就 这样子我得到了所有网页里(HTML Page)的段落(Paragraph)。当然split 这道魔法里头必然包含了先前我依赖已久的 strstr() 或 == 或 指标 (pointer)等等基本法运用。可是在Python的宝典里头另有高人用最优化的法术浓缩了这一系列咒语，给我们一个高级的咒语。简明又有效。
于是我何乐不为，继续用这道咒语寻找那些被标签的符号。
我从恍惚回来，面对分开(split)的力量不可自拔的留恋起来。其实很早以前就已经看过split这则咒语了，VB Script里就含有这道咒语。却一直到今天我在Python里把一篇篇文章拆散成句子的时候才发觉这到咒语的妙用，仿佛进化成一种亮丽的魔法，悄悄一声呼唤，连亮光都来不及现身，一堆我要的句子列队空降，纪律严明。
尤其是拆解HTML tag 时，譬如：
list_P = htmlSource.split("<p>")
list_P = list_P[1:]
for i in list_P:
list_Q = i.split("</p>")
print list_Q[0]
就 这样子我得到了所有网页里(HTML Page)的段落(Paragraph)。当然split 这道魔法里头必然包含了先前我依赖已久的 strstr() 或 == 或 指标 (pointer)等等基本法运用。可是在Python的宝典里头另有高人用最优化的法术浓缩了这一系列咒语，给我们一个高级的咒语。简明又有效。
于是我何乐不为，继续用这道咒语寻找那些被标签的符号。
訂閱：
