Something you should know, Google give us “Google 编程学院”：
该网站提供辅导手册和示例课程内容，以便 CS 学生和教师可以了解有关当前计算技术和范例的详情。尤其是，该内容获得了创造性共用许可，使 CS 教师可以轻松地在他们各自的课堂上使用。
课程部分包含各种主题领域的教程、演讲幻灯片和问题集。
- AJAX 编程
- 算法
- 分布式系统
- 网络安全
- 语言
在“工具 101”部分，您将找到一系列说明，对计算机科学中的一些常用工具（例如版本控制系统和数据库）进行解释。
CS 课程搜索将帮助您找到发布到网络上的教学资料，这些资料由来自世界各地的 CS 部门的教员发布。您可以细分搜索，以仅显示课程、作业，或一组课程的参考资料。
我们期待收到您的反馈。如果您有疑问、建议或可供分享的材料，请访问Google 代码教育版论坛。
这个副标题，本来是想放到文章标题的，但是太长了，只好作罢。
同学通过新浪微博推荐了这篇文章，我就不再重复叙述原文的内容，只写我的感受。
文中提到Dropbox成功的原因除了其公关策略的成功外，还着重提到了一点：产品功能的控制。Syncplicity提供了多文件夹同步的功能。而Dropbox却简化了这一个功能，只因为其无法让用户易于使用而且存在无法完全修复的问题。
如果你刚刚建立起公司，那么最好保持产品简洁，并专注于现有功能，将一件事做到极致。用户永远会要求更多功能，提出他们的问题并期待你修复。我的观点是，如果他们提出的问题在 80% 的用户中存在，那么才值得去做。除非你资源充足，否则最好还是专注于核心竞争力。
保持产品简洁的另一个优势是，这使得销售和客户支持变得简单。如果你的产品太复杂，势必意味着你将花费更多时间用于客户支持和 Bug 修复。“我时刻在此等候您的反馈”——这并不好玩。
联想到最近正在进行的一个项目，系统规划的时候预计的模块很多，本来是要分为多个版本阶段来实现的。可是最后项目实施的时候，却把大部分的模块都同时进行了。导致开发的时候，开发人员的时间和人力都分散了，每个模块都无法做到最好，甚至于有些模块的功能需求有膨胀起来，使得项目更加的复杂。
看来，有的时候还是要像Apple Inc.学习，简洁才是美。一开始不要把事情搞得太复杂，千里之行始于足下，从最开始就应该一步一个脚印好好的走好。先实现基本的功能，新的功能如果80%的用户都需要，那么才有必要去做。
前情提要：最近开始好好的学习Zend Framework(zf)。其实以前也学了一阵子zf（再之前学的就是FleaPHP了），那还是1.5版本的时候，可惜忙着其它事情，就没有学下去，一个项目也就扔了一个半成品在那里。暑假开始做一个单位的项目，就重新把zf捡了起来，当然现在用的是1.8.4了（虽然zf版本已经到了1.9.1，可是zend-ce用的还是1.8.4，它什么时候才更新呢？）。
项目是还一边学着一边做的，同时看着的有快速入门（也是Zend Studio上的example项目），参考手册，入门教程（从1.5.2到1.6.3），以及www.phpchina.com上多模块应用程序的相关文章（如：用Zend_Application实现多模块(modules)及多模板(templates)应用程序）。本来是希望多学些东西，然后直接写出理想的程序雏形，可惜这些从简单到复杂的教程内容混杂在一起，自己的代码也就不在纯洁了，开始互相干扰了。
经过几天的努力建立了简单的MVC雏形，主要是写了一个统一通用的EntityManager（我的目标是能像Java的EJB 3.0一样管理Entity，只是不明白Zend为什么没有提供这样的结构）花了比较长的时间。
Layout是参考着入门教程来写的，当写完Bootstrap的_initViewHelpers()时，我想为什么不把view的一些设定放在application.ini中去呢？于是便参考了phpchina.com上面的文章设置了resources.view.*的内容，其中包括resources.view.encoding=”UTF-8″。
这样问题就来了。
开始往layout.phtml中写入$this->baseUrl()时，发现系统不能正常显示：
Fatal error: Uncaught exception ‘Zend_Loader_PluginLoader_Exception’ with message ‘Plugin by name ‘BaseUrl’ was not found in the registry; used paths: Zend_View_Helper_: Zend/View/Helper/:./views/helpers/’
虽然路径是对的但是就是找不到BaseUrl助手；与此同时，在Controller中设定的title变量也不显示。然后，这两个内容在views/scripts/index.phtml中是可以正常显示的。
开始以为是入门教程有问题，认为可能是Layout和View的调用顺序不一样，有些东西在layout中没有初始化。于是到处查Layout和View的差别，甚至试图在layout和view script中分别把$this变量打印出来比较差别，最终还是徒劳，还在想是不是该好好将参考手册乃至于API精读一下。
今天下午，不知怎的，突然开窍了。心想，既然人家的入门教程写了这么多人看都没有问题，那么上面的东西应该是对的，为什么不放弃自己项目中杂七杂八的想法，老老实实的遵循教程中简单的思路试试看行不行呢？
于是重新新建一个项目，遵照入门教程的步骤一步步进行（当然由于是测试layout，数据库以及Model就没有建立了），发现这样就不存在之前的问题。这说明问题是我自己项目中混乱的代码引起的，就开始排查。
最后，发现问题就出在resources.view.encoding=”UTF-8″这句话上面，即便是我将值改成默认的ISO-8859-1，错误依旧。解决办法就是将这句话去掉。
至于为什么这句话会引起这么大的问题，暂时先不管了，以后深入使用View的时候应该就会了解了吧。
思考：
这次错误虽然只是短短的一句话，但是却让项目陷入了停顿状态，让我近一个礼拜都心神不宁。写下这篇文章目的一个是让其它人遇到相同问题的时候，能搜到解决方案；此外，也在此审视一下自己的一些态度方法。
首先，是自己贪快、贪多。一开始就没有好好遵照某一个教程完成一个项目，很多方法只是看了文章还没有实践，就想着开始改进它。教程看到一半，就想依照心中实际项目的需要，又从其它教程中拉入自己还不是很熟悉的内容进来，最终让代码失去了控制。就好像，一种内功连到一半还不熟练，就想把另一种不熟练的内功融合进来，这样轻则神志大乱，重则吐血而亡。这个似乎是我性格中的毛病，在很多方面都有类似的例子，以后一定要切记、切记呀。
其次，当发生错误的时候，始终在自己的思路中钻牛角尖。老是想在一团混乱中找到一丝线索，乃至于把简单的事情复杂化，要去追寻事物的原理。事实上，这样一个简单的东西，人家教程里的东西就已经是一种经验（模式），不会错的，就是大家该遵循的。如果我及早放弃自己的思路，老老实实按照人家经验的做法，问题就能提早解决。其实我也经常说别人不肯放弃自己的思路而遵循别人的思路去解决问题，只是没想到自己也犯了这样的毛病，以后切记、切记呀。
今天为了发一批作业给老师，为了统一将压缩包都改成了zip格式。
整理的时候发现一个zip文件居然有16M多，只好先单独发送。后来Gmail发现这个zip里有可执行文件便不给发送（这个问题一直很烦恼，有时为了发送安全的程序也没有办法。不知道有无办法可以规避么？），只好再想起使用rar格式。找出原始文档，发现rar格式的就只有9M多，这个差别可真够大了，几乎是zip格式的一半大小了（解压后原文档时21M多）。
我使用的是7-Zip软件，就再用极限压缩的方式进行压缩，也还是在16M多。看来Zip也就只能这样了。
另外有试了一下7z格式，发现只有6M多。看来不同的压缩算法还真的是差别好多哦。
环境：操作系统-Windows XP SP2 CHS；MS Visual Studio 2005 Team Suite CHS；MS Visual Studio 2008 Team Suite; Intel C++ Compiler 10.1.021。
Intel C++ Compiler只要加入编译参数就可以支持OpenMP，仅仅使用了OpenMP的一些API调用的时候，才需要include omp.h；而MS Vistual Studio支持OpenMP的时候，除了要加入编译参数，源代码还必须include omp.h，否则执行的时候会出错。对于MS VS 2005，是提示“没有找到vcomp.dll，因此这个应用程序未能启动。重新安装应用程序可能会修复此问题”；而对于MS VS 2008 则提示的是“VCOMP90.dll”，其实这些DLL在redist目录下都能找到，就是不知道MS为什么非要加上omp.h后才能去找到。
此外使用集成在MS VS 2008里的Intel C++ Compiler编译代码的话，如果没有omp.h，执行还会出现找不到libgguide40.dll（记得不大清楚了）文件。
也正是如此，才迫使我卸载掉MS VS 2008，重新使用2005。
由 WordPress 所驱动