http://wiki.woodpecker.org.cn/moin/ThePythonParadox

http://forum.javaeye.com/viewtopic.php?t=21245&sid=75490b7bdd393902d2f1775079ba67f2

将近两个月没有写任何东西了，上一篇东西还是四月在匈牙利的时候写的，发了一阵牢骚以后，就被卷入了无休无止的会议，文档和debug过程中。
所幸做这些事情的时候到还比较顺利，我们在匈牙利用的是迭代开发，反馈的非常及时，在开发和设计的过程中受到的压力和干扰非常小，结果也不坏，回来的时候软件已经能够正常工作了，只是有一些轻微的bug。而采用了很多过程、方法和手段的另外一组却遇到了很大的麻烦：用了一些不很合适的人手，在实际的开发之前浪费了太多的时间写文档和开会，在编码的时候遇到了很多没有预料到的问题……基本上都是人的问题。无论如何不应该把开发者只当作开发环节上可以随时替换的零件，就是我对目前这个项目的体会。
年初的计划看来要落空了，心里也千头万绪的，还老是劝人该这样那样，自己还没有别人走的踏实，想来真是惭愧。工作以后没有人监督，做事情也变得有一搭没一搭的，坚持写点东西应该是个不错的主意，可惜没有坚持住。还有小半年时间，抓紧时间吧。

以下宣言来自http://agilemanifesto.org.

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.
我不知道被标红的这四条在今天还有多少人持反对的态度，对于我而言，敏捷宣言带来的软件开发价值观念实际上是一种价值的回归，我们需要能够工作，运转良好的软件，我们需要为客户带来价值，我们需要适应这个变化多端的世界。软件的内在复杂性决定了我们只能运用我们的聪明才智来克服开发过程中的种种艰难险阻，所以我们强调人的协作和互动，强调个人的充分发挥和团队的紧密配合的和谐统一，强调代码作为设计最终体现的重要意义，强调软件设计的简单和灵活性的完美结合。说到底软件的开发是为了最终的使用，为了不断的提供价值，为了不停的适应变化，为了给客户带来更大的经济效益，离开了这些直接而赤裸裸的指导原则，一切的所谓文档、流程、计划和工具都是空对空的扯淡。换言之，如果像TDD,结对编程、持续构建这些XP实践不能给我带来实质性的好处，没有让我们的软件能够更加容易的开发，能够为客户提供更多的价值，我为什么还要做一个XP的实践者？
如果简单的赞成或者反对敏捷而没有任何的经验或者证据来支撑我们的观点，无疑我们会落入非此即彼的认识怪圈，我们会成为所谓大师言论的奴隶和盲从者，如果没有认真的思考和仔细的观察，我们永远也不会得到对我们自身真正有益的东西。在这一点上，敏捷宣言也无法帮助我们，我们必须更加仔细的寻找适合的开发方法，用一种更加实用的眼光来看待我们的软件开发和新的工具、方法和开发理论。保持怀疑不是一件坏的事情，在日新月异的技术领域尤其如此。
说到这里，我觉得有一点跑题了，但是我本来要表达的意思已经很明确了，在SCIP的教学录像里面，professor Sussman有一句话很有意思，作为今天的结束吧：Computers to make people happy, not people to make computers happy。

http://blog.donews.com/limodou/archive/2006/04/02/808281.aspx

最近的任务是做一个jni的接口给我们用java开发的产品使用，于是有机会体验了一把Win32 API。
不得不说一句的是，MSDN确实是个巨大的宝库，其他公司、组织、开源社区的文档资源，确实无法和windows平台相提并论。
首先找了几本书看看，基本上都是按照侯捷先生网站推荐来看的，基本的概念都是了解的，缺少的就是实战编码和排错的实践，所幸任务也不是很艰巨，java和本地的Win32 api的接口非常简单，所有的任务就是查找API，然后写代码，编译测试。
我的c编程经验基本上都是纸上谈兵，虽然也看过c traps and pitfalls这样的进阶读物，也仔细的做过The c Programming Language上大部分的习题，可是确实没有任何实际的跟平台相关的编码经验。在java里面工作的时间看来是过于长久了，牵涉到自己管理内存的地方就会非常的没有自信，总是害怕会出什么乱子，幸亏MSDN上面的例子极为全面，参考书也是非常权威，有看着像的代码，先贴到编辑器里编译一下看看再说，就这么边学边做了。
最大的感觉是know how在Windows平台上也是一件不太容易的事情，因为Windows操作系统本身就非常复杂的这个事实，蔡学镛的“lots of APIs”成了一件让人羡慕的事情，如果没有IDE和MSDN的帮助，找到需要的API还真是一件让人无比头疼的事情，这个没有什么办法，程序写得不够，也只能摸着石头过河了。
其次是对于基本概念的理解。这个差不多是重点中的重点，如果关于计算机的基础知识能够再厚实一些，如果对于编译器工作的原理和链接的原理有一个扎实的认识，如果对于c语言外表下的那个冯诺伊曼体系有一个更扎实的理解，我想在任何平台上都能写出高效漂亮的程序。从这个角度上来讲，c语言的高手会轻视其他高级语言程序员的这种心态，多少是可以理解的，也可以这么说，精通c语言和c语言表层下的那个计算环境的基本概念，是成为一个优秀程序员的必由之路。
当然了，我没有万般皆下品，唯有读书高的意思，我的路还很长，我不想就这样把自己禁锢在一个过于狭窄的圈子里，我的理想就是万能程序员，在任何平台上，使用任何编程语言，写出任何用途的程序，要做到这一点，我就得珍惜我目前能抓住的所有的写代码的机会。我想梦想不是用来实现的，而是用来追随的，对吧。

http://www.paulgraham.com/love.html
The essay was made by Paul Graham, I am afraid many of us don't know the man very well, and so do I. The article is very long and I have not finished it by far. But I expect we could get something useful from it.

    基本上转换erwin的xml文件的python程序已经就绪了，但是在写程序和考虑问题的这几天里我反而有些糊涂起来，关于程序的设计和设计的选择一直困扰着我。
    说到那个python程序，我已经重写了很多遍了，Martin最初的那个程序其实很简单，他的需求其实也没有那么难，但是我把程序写过几遍以后发现了一个问题：我每一次都可以用完全不同的思路来解决这个问题，以至于我的程序都完全不一样。我可以完全使用python内置的dict和tuple对象来存储所有的Entity、Attribute、Key和Relation的信息，我也可以做一个Classitis，把所有能看到的结构都映射成为class defination，我甚至也想过functional的解法：利用一个map结构，让每一个节点的数据通过一个方法的管道，然后在管道的另外一边读取我需要的信息……
    在Java里面，一切都很简单，我只需要定义interfaces，他们必须遵守的契约，然后我可以在实现类里面实现我的解析过程，构造出我想要的对象结构，一切都顺理成章，我可以利用interface来隔离各个模块之间的耦合，比如对某一个parser的依赖关系，对于特定dom版本的依赖关系，对于dom的依赖（我想这个需求是合理的，因为我们完全可能因为内存消耗的原因而转换到sax），甚至对于xml文件的依赖（当然，这样我的设计就走得太远了），然后通过IOC的方式把他们粘合在一起，我的程序就完成了。甚至于我可以这样说，也许我的实现是naive的，也许我的代码是低效的，但是我的思路是正确的，至少，reasonable。
    在python里面我找不到这种感觉：我觉得无论哪一条路都是可行的，OO的方法,functional的方法，甚至于过程化的方法都是可行的，然而又都是不太完美的，我也许可以使用在java里的经验，但是我隐隐约约觉得会有更好地解决方案，由于这样的原因（也许因为懒惰），我没有做那样的尝试，怎么说呢，我觉得那样兴师动众的方法在一个动态语言里太——不优雅了。在我多少了解一点functional语言和方法之后我尤其感到如此，那么我是不是在一条正确的道路上行走呢？我是不是应该继续我的杞人忧天，还是埋头在代码之中，直到“理性之光”突然降临呢？
    总有一天，我会弄明白的。

http://www.xprogramming.com/testfram.htm
基本上覆盖了单元测试的每一个大的方面，使用smalltalk描述和实现，虽然语法比较奇怪，但还是能看出和JUnit和python的unittest framework的一脉相承的结构和思想，一个如此简单的框架和思想，能够在如此广泛的范围内影响软件的开发，确实不简单。