做开源的东西已经一段时间了，从微软阵营转到开源的几个月是非常痛苦的。

曾经一直认为学好了一门语言之后，其他的语言学起来都是相通的，但是现在觉得这句话还是有失偏颇的，因为一门语言背后的是一个社区的风格习惯，这样的风格习惯会导致项目开发产生不同的编码，生产风格，最后导致项目中出现一些问题。

其实，了解这些差异也是很重要的。

当然，选择的路不同，到最后的习惯和方向也会很不同，这也就是前面说的那句话有失偏颇的问题。如果.Net接触多了，你写web service会考虑使用WCF之流，自然也会做出“相应”的社区中认为较好的应用或框架，但是拿到另一个社区可能完完全全就是垃圾，因为信奉的“宗教”不同，自然就会有问题。

当然，世界上还是有一些公理的，如如何写一个好的软件，设计模式等。

经常需要写一些小工具，这些工具有时候简单的就用python，性能高一点的就需要c，而我又喜欢用命令行和vi写程序，所以写makefile自然就成了麻烦中的麻烦了，不过好在可以使用automake，不过网上并没有很详细的说automake如何使用（都是东说一块西说一块的），查了一下然后整理了一下，发上来，就当自己做笔记，也方便了后面的人，高手自然自动飘过即可。

由于使用了Google App Engine，而且也经常使用Mako，觉得Mako的语法其实挺不错的，而且也比较容易理解，性能也不错，所以就想在Google App Engine上使用Mako，尝试了一下，并不是很难，具体做法如下。

1.下载mako http://www.makotemplates.org/downloads/Mako-0.2.5.tar.gz，可以使用wget url命令获取，Mac下需要下载一个wget，我习惯用wget了。
2.解压缩。
3.安装应该在/资源库/Python/2.5（或你使用的版本）/site-packages/Makoxxxxxx/mako。
4.拷贝上面的资源到你的应用程序目录下。

当然，还要写一点代码去使用mako，如果你不愿意去实现，可以看看我怎么做，Go on

今天有点时间，于是想找一个支持Python的服务器，后来很失望，因为国内几乎没有Python的服务器，好吧，只能说我自己的期望有点高，但是又不想自己弄一个机器当服务器还配置很多东西，于是就选择了Google App Engine。

Google App Engine可以当作是一个托管的开发平台，有一套自己的环境，我们只需要下载SDK安装并且使用相应的工具开发，然后部署即可，非常简单，因为我喜欢Python，于是就使用Python作为开发环境。

首先注册一个App Engine帐户，如果有Google帐户的话，那么就很容易，直接创建一个应用。创建很简单，就如下图即可，创建之后就有控制板等告诉你谁访问过之类的，这里我就不废话了。

已经工作了很长时间，一直也没有说一下这个“关于程序员坚守的思考”的问题，这个问题不是针对现在的公司，只是我这么长时间来工作的一些心得，特别是关于做为一个程序员一些心得。

在产品开发过程中，肯定是会有不同的人承担不同的职责并在团队中做自己相应的任务，每个人的目的都不同，比如产品的目的是要尽快的发布产品，而程序员的目的是要写出高质量的代码等等。实际上，写出高质量的代码并不是一件很难的事情，随着经验的增长和阅历的丰富，高质量的代码并不是一个难以攀爬的高峰，但是为什么产品会出现越来越慢或者越来越差的局面呢，我觉得这是有几个因素造成的。

首先是程序员的能力，虽然我们这个地方主要不会探讨程序员的能力。因为我们首先将程序员当成是有责任心，能力可佳的人，至少这样的人不在少数，如果说程序员不能在相应的时间里（并不是开会所说的时间）完成相应难度的任务，那么这个程序员本身就是不可靠的，其他，我们都至少能够相信程序员是可以靠的住的（虽然代码性能和优化上不会太完美）。

当程序员这一方面没有问题之后，又是什么导致产品出现走下坡路的局面呢？我个人认为是沟通和计划，一个好的产品一定要有一个好的计划，并不能只局限于（或者说着重于）所谓的“快速发布”和“敏捷开发”，如果在整个团队中，使用了错误的“敏捷开发”并以“快速发布”作为指导的话，那么这个产品肯定会有局限性，因为速度和质量并不能完全的达到一致。

其实很早就想写HTML5和CSS3的文章了，但是一直都没什么时间写，最近闲下来了，于是就写一下HTML5和CSS3的文章。HTML5出来了有一段时间了，各个主流浏览器基本上都能够支持HTML5，HTML5能够为我们做很多事情，并且轻松的就能够实现非常酷的效果。我们不仅能在网页前端制作上面可以使用HTML5和CSS3，我们还能够在浏览器插件中使用HTML5和CSS3（因为Chrome和Firefo浏览器都支持HTML5），那么我们不如来尝试写一个HTML5的网页或插件。

这是一本一年多以前我写的一本书，但是没想到过了一段时间还是有人需要，这本书估计已经下市了，很多人直接给我发短信说买不到了，然后说找不到源代码以及光盘里的东西。我这里有一本作者用书，所以我这里有一点源代码，由于一开始不在我的手上，现在拿回来了，方便广大网友，所以就在这里提供源代码下载。本来有一个人说拿去做教材的，买不到书，说是要给他邮寄过去的，可惜我媳妇不想，于是作罢，对这个网友是非常不好意思，这里就提供源代码下载吧。

今天在微软年终Party中分享了敏捷开发的观点，让我真正的开始反思敏捷开发这个词，原来我一直都不知道自己的公司是在进行敏捷开发，不知道是喜是悲。也从这一段时间的开发过程中知道，其实敏捷并不是万能的，项目的速度和质量最重要的还是靠整个团队的协作。有人曾经说微软的敏捷做的不好，其实仔细想想自己的敏捷实践其实更烂，因为敏捷有几点是需要关注的。

合格的自觉的编码规范。
TDD，先写单元测试再编码。
客户参与项目。
团队的平等性。

其实要做到上面的很难，无论是大公司还是小公司，其中最有趣的一点是，敏捷的团队要保持创新力和持久力，每周不能工作超过40小时，相比起来，不加班已经够幸运了，更不要说那种没有理由的或者瞎编理由让你加班的了。
所以，要知道敏捷并不是万能的，实践敏捷之前，还要考虑自己的团队能不能敏捷起来。另外要提醒一点的是，如果不能真正保证自己能实践的成功，就不要在实践之前鄙视某些其他的公司，其实以五十步笑百步才是最让人鄙视的，谦虚一点也没什么不好的。

本来想写这样一篇文章很久了，虽然也有时间去写，但是这样的貌似纯理论的东西感觉还是很难下笔，今天晚上想着还是写下来好，以后自己看也是一个值得回忆的技术过程。因为我自己使用命令行比较多，所以对我来说，任何机器首先最重要的是命令行环境了，在Windows下面，使用cmd和一些alias工具去使用命令行，在Mac或者Linux下面，命令行更是鼓励的一种方式，可见命令行虽然在历史上很久了，但还是非常重要的。
其实我原来一直都是在微软的.net平台下进行开发的，C#固然强大，但是帮你做的事情太多了，你不需要关心内存泄露，也不需要关心垃圾释放，也不需要关心指针问题，更不用关心自动化等等了。当然，好是很好，但是对程序员的自身提高还是有一定阻碍的，特别是对那些从C#入门的开发人员来说更是这样，所以就会很难理解命令行和自动化为什么好了。当有一个新语言或者新的东西发布的时候，如Chrome插件，iPhone开发等等，很多依赖平台或者IDE 很强的人就茫然了，无从下手了。

第一就是关于内存的速度的，其实不难，但是开发的时候想到的很少，能想到的优化的就是高人，我也是路过看到不错，觉得很有用，就贴过来了。

另一个就是《算法导论》了，国外的教材，也是MIT的标准教材，很好很强大，昨天看到了堆排序和快速排序（100页），用了好多张纸证明线性比较排序的上界和下界，堆排序和快速排序的最好的速度是nlogn，从数学角度上证明了线性比较排序（如判断a[1]>a[0]）的最快就是nlogn，也就是说只要你是比较的，而且还是线性的，nlogn就是最快的了。
数学公式太复杂，什么期望啊，概率啊，极限啊，记的不是很清楚，让我自己推倒也没这个能力，不过倒是让我知道了，以后别想线性快速的排序还能超过nlogn了。：）