1。最初接触python是一个很偶然的机会，2000年大四毕业设计，接触到zope，后来知道zope背后是python，因为额外的功能需求，所以在很无知的情况下修改了zope的一个源代码，当时看完成了要求的功能，可是后来却使另外一个同学大伤脑筋，这是后话，暂且不表。当时还有一个很重要的需求，就是将一堆文件打包成zip格式，一次上载，然后自动解开。当时觉得很新鲜，也无从下手。还是那位伤脑筋的同学有办法，他自己学习的python的部分知识，用了大概三天时间解决的这一难题，给所有人留下很深的印象。
2。2000年毕业后去的那家通信公司以严格和高强度的工作著称，所以根本没有什么实践进行兴趣学习，更不用提什么python之类的东西。
3。2001年因为个人的一些原因来到北京，进了一家作数字电视、机顶盒开发的公司，因为各方面的原因，工作比较轻松，所以有了接触python的机会。大概是一个周末的上午，一个人在家，闲的无聊，不知怎么，开始学习python，学习的资料是“dive into python”以及“how to think like a scientist”。大概一个上午的时间，就初步的接触到了python语言的基本元素，其丰富，实用的基本数据结构，list，tuple，dictionary给我留下很深的印象。
4。那一年，有一段时间上班时也比较闲，所以借着机会就操起了《编译原理》，也不知怎么的，就突然想起以前上大学时老师布置的project，由于上学时对开发幼稚的认识，把大量的时间花在一些边脚的处理上，结果直到deadline，也没有完成作业，是为一个遗憾。由于正好有两三天的闲暇，就抓起算法，用python开发起来。结果，出奇的顺，很快就写完了程序。在开发思想没有飞跃的情况下，对比两种体会，只能说是工具带来的变化。现在回想起来，如果在大学的早期接触到python，然后用python去完成相关作业，那么很多情况下，作业都会变成乐趣。我们大学时语言主要是C，无疑C是强大的，而且是计算机系本科生的必备技能。但是，C语言的基本数据类型过于简单原始，任何高级一点的数据结构都需要用指针。简单一点的数据结构比如链表，复杂一点的数据结构如list，集合，字典都得花大功夫去构建。所以，很多时候，大部分精力不是放在最重要的逻辑上，而是放在这方面上，舍本逐末，痛苦不已。C语言的另外一个致命问题是缺少足够的库，很多基本功能得亲历亲为，很不爽。而用了python，这些都不是问题，需要链表吗，list就可以，既可以作队列，又可以作桟。需要集合吗，tuple就可以。需要字典吗，dictionary直接对应。正如很多人强调的，python使你可以把注意力集中在问题本身。
5。还是在那家公司，一个周五下午的事情给我留下很深的印象，当时有一个同事的程序需要将一批二进制文件合并成一个大文件。他们以前熟知的copy方法不管用，我就试着用python写了几行程序，15分钟内搞定了。这时大家都来问我python是什么。其实，我也是一个python的新手。
6。在目前的这个公司，工作很忙，所以工作中不会有太多时间学习python，但是由于各种机会，还是能不时体会到python的好处。我们由于在linux下作开发，所以接触shell脚本的机会比较多，我有意识的多去使用python，感到基本可以替代c-shell，当然，这是一个习惯和意识的问题，在这方面，python并没有多大的优势（相比于其他的shell脚本语言以及perl)
7。在工作中接触的一个美国公司，他们提供的一些包管理工具是用python开发的，有GUI界面的，感觉到比较亲切。工作中还接触到另外一个工具－libopt，是用来优化动态库的一个工具，居然也是用python开发的，当时兴冲冲的打出代码，准备分析，由于某些原因，未能如愿。
8。在开发中，遇到一个地方对正则表达式有一定要求，于是学习正则表达式。由于学习这个东西需要接触很多的实例，所以拼命想用什么办法能获得更多的练习。后来想到写一个工具，可以首先输入一个正则表达式，然后下面输入一些实际的例子，从匹配的结果来看正则表达式是否选用正确。当然，熟悉python的人都知道，python本身有re模块，是专门来处理正则表达式的库。所以，这个需求几行程序就完成了。后来在网上搜了一下，发现有很多类似的，更成熟和复杂的工具。但是从学习的效果上来说，其实又差不多，所以，我还是喜欢用现在的这个工具。命令行下使用，简单，快捷，又有成就感，虽然只是简单的程序。
9。由于这一年来，耳濡目染，对XP有愈发浓厚的兴趣，而我自己认为，对我目前的工作实践指导意义更强的是其中的“测试优先”的思想，具体到实践上，就是TDD，即测试驱动开发。一个周末，又下载了新的dive into python，发现其中有了这方面的内容，完全符合我实践结合理论的胃口。所以就照猫画虎的将其中所有的例子敲了一遍，走完了全过程，大呼过瘾。试想一下，如果例子都是C、C＋＋的，我很可能只是看看而已，仅仅是编译错误就够我受的，哪有机会去体会TDD的乐趣呢？由于今年的工作目标中已经把XP的相关实践写了进去，所以在今年适当时候，我还要重新复习一下这些例子，然后再着手开展在C＋＋方面的TDD实践。
10。今年春节，假期较长，所以就把笔记本背了回来。春节期间姚明表现的不错，所以上网看网友评论的机会就比较多了。比较爱去的是rockets的官方网站，www.chron.com（休斯顿纪事报），以及www.yaomingmania.com，一个不错的专著于姚明的英文网站。看的多了，就突然想，每天看这么多英文资料，但是为什么单词不见飞跃呢？我阅读有一个习惯，就是从来不查字典，所以阅读速度比较快。这是一个优点，但是从另外一个方面，也有问题，即我能很快的捕捉文章的大意但是却错过了很多学习的机会。所以，我需要一个工具，一个简单的工具，它能帮助我记单词！我的需求很简单，用一种简单的方法来记录单词，同时不影响阅读速度。阅读完后，使用这个工具，可以回顾这个单词，协助记忆。其实最初的需求也很模糊，所以就着手写起来。三四天下来，我的需求逐渐明确，工具也可以基本投入使用。我准备先投入使用一段实践，然后根据使用中的问题再修改这个工具，将来的有趣想法包括
a。将它和dict.org的API结合起来，需要的时候可以自动查词
b。将他和IE等浏览器结合起来，能更方便的使用
c。提供GUI界面，目前还是命令行下使用，虽然我比较习惯于命令行界面，但是GUI还是有必要的，尤其是问题和过程已经超出线性范畴时 d。将他移到手机上，这对我每天来回一个多小时的地铁生活来说是不错的选择。
比较高兴的一点是，以前由于程序规模和问题本身的问题，我基本上都是以过程性的编程完成任务的，而这次，由于时间比较充分，而且问题有后继的需求，所以就用了OO的方法。这是我第一次用python进行OO编程，感觉不错。我的一小步，但却是小小的飞跃。
11。还有一些零星的应用，我没有计算在内，总的体会是：
python是唯一一种我愿意在非工作场合使用，投入业余时间去学习，而且的的确确获得乐趣的工具。它能使我真正关注于问题本身，并在很短的时间内获得问题的解决，体会到解决问题的乐趣。
我知道有很多其他的工具可供选择，但是python从来没有让我失望过。我很满意它的学习曲线，初步接触之后对他强大的能力也有较深刻的认识。只需要很小的磁盘空间，只要有命令行环境就可以使用绝大部分功能，能在linux和windows等平台无障碍的使用。而且，它遵循GNU，使用时非常舒畅，很少有人说自己VC或者delphi是正版的，但是，我的python永远不会有这方面的担心。
前几个月看《software craftman》，里面提到真正高效的team都是人少而精的。里面特别提到一个故事，讲的是一个小公司正在做一种软件的研发，突然有一天，他们看到报纸上讲一个大公司也准备开发这种产品，于是很担心。但是接下来，他们又笑了，因为报纸上写道，那个大公司准备用500个人做这项开发。
现在发现大的team真的是比较可怕，很多时间都浪费在communication上，真正用心写code的时间比较少。当然，抱怨是没有用的，关键是自己如何适应，如何调整，抓住重点。当然，从另外一个方面说，凡是有缺陷，有不足的地方都孕育着很多机会，一个已经十全十美的地方反而缺乏生机。关键在自己，在于自己怎么想，怎么做。
在这一期《程序员》中有一篇对PowerDesigner设计师王晓军的采访，其中王提到“测试方面除了人工测试外，还引进了自动测试，我们用的是WinRunner，每天晚上进行自动测试，这样可以大大提高工作效率，自动测试的越多，质量也就越高”
我认为，自动测试的前提条件是实现了nightly build。两年前听微软工程师讲课时，他们就特别强调nightly build和自动测试。看来，这是大型项目提高质量的一个必由之路。当然，由于这件事情超出我个人的scope，所以不在研究之列。但是对于自己，我想，首先掌握Test Driven Development的技巧是非常关键的，个人的东西首先做到自动测试自己的代码，提高自己的自动化程度，成熟程度。
何谓大规模，无外乎两个方面
1。人多
2。模块多
这就导致了复杂的，繁多的依赖，而依赖性管理是这些项目成功的关键。我这几天正在思考这方面的问题，希望能有一些有力的武器，处理目前工作中遇到的问题。发现了《大规模C++程序设计》一书，同时也看到了一篇不错的评论，copy如下，链接：
“前段时间翻阅了《大规模C＋＋程序设计》一书，里面的主要内容是关于依赖性管理方面的技术的，我觉得这可能也是该书起名为大规模的原因，因为对于大规模的程序来说，依赖性管理是至关重要的。最近在研读uncle bob的《敏捷软件开发》一书，看完后大呼过瘾，本书对于依赖性管理方面的论述可以说是精彩绝伦。所给出的类以及包方面的设计原则非常的清晰、深刻又非常具有实用性。更不用说其中有关模式以及敏捷过程方面的论述。书中所讲述的有关设计方面的张力和平衡，在同类书籍中更是不多见。我强烈向大家推荐这本书。如果你还在犹豫着是否看《大规模C＋＋程序设计》一书（如果是几年前，我会大力向你推荐此书），我建议改看uncle bob的《敏捷软件开发》。《大规模C＋＋程序设计》一书中的内容虽然不像amazon上说的有点dated，但是和uncle bob的《敏捷软件开发》一书相比就显的逊色不少。真不知道出版社为何给《大规模C＋＋程序设计》定这么高的价格。另外，uncle bob的《敏捷软件开发》的翻译绝对值得信任，而且很流畅”
这到给我一个启发，因为我手头就有《敏捷软件开发》，当然，我现在不会对谁顶礼膜拜，所以，《大规模》一书还是要买的，有那么一两章能给我以启发就知足了。希望能在做下一个产品时能有更好的武器！
如何更好的写python中的main()函数，Guido van Rossum给出一些很好的建议
这个标题要解释一下，具体点说是“欲望和现实的差距”＝“潜在的机会和机遇”。什么是欲望和现实的差距？举个例子，早晨打球归来，路上有些感想，突然想把这些想法放在blog上，可是无法？！这就是“差距”。这不是我的错，我的无能。这是因为还缺少合适的工具。是想一下，如果有一个小巧的工具，能提供这种功能，那么我一定会买一个。（题外话，我对blog的一个预测就是blog无处不在，无时不在，无他，人本性所致）
诸如此类还有很多例子，当你不能遂愿之时，不妨暗喜，因为新的机会来了，新的想法来了。接下来的就是实现和推动。
有一个名词专门描述这种思维，叫什么来着？好像是“克弱转换”。
