不知道哪里去找coolcode的官网了，今天要贴个VBA的代码，发现似乎不支持该语言的着色。

baidu后做个备案～

coolcode支持语言有：
actionscript
cpp
css
df
dtd
html
java
javascript
mysql
perl
php
python
ruby
sql
xml

★ 用ghost光盘安装系统时，找不到硬盘或者光驱中的内容。
可能原因：因为SATA设置为ACHI模式。导致在dos下无法识别到该设备
解决方案：设置为IDE或者兼容模式（视不同BIOS描述）或者使用PE系统进行安装，使用一键备份软件同样需要注意该问题。

★ 500G的移动硬盘在DOS下无法识别。
解决方案：使用PE，或者分成若干个较小的分区（100G左右吧）

★ 旧设备需要串口，新笔记本未提供。
解决方案：购买一个USB hub+USB转串口的线来实现，需要折腾的是，串口有若干个COM1…COM8，很多软件只考虑到了某个COM口，所以必要时候还要调整为相应的口即可。

★ AOC的一体机未提供驱动。
解决方案：用雨林木风的ghost安装后，应该找不到无线网卡驱动，用随机带的vista的无线网卡驱动狸猫换太子

★ window下设置双网关。
解决方案：因为内外网使用不同网关，所以需要设置修改路由表，命令为：
route -p add 192.168.0.0 mask 255.255.0.0 192.168.11.253
-p参数为，永久性修改

★ 手机WIFI需要访问内外网。
解决方案：内外网网关不同，手机无法设置网关。买个DLINK的DIR-685（不是广告，我暂时遇到只有这个路由器有这个功能)，其中可以设置路由表。（还有NAS。。。非常虎的路由器，就是太贵了）

★ python读取Unicode编码文件，中文乱码。
解决方案：不知如何下手，改成gbk先完成任务再说。。。

设计Qt风格的C++API

作者Matthias Ettrich，译者Googol Lee，原文地址在这里。

在奇趣（Trolltech），为了改进Qt的开发体验，我们做了大量的研究。这篇文章里，我打算分享一些我们的发现，以及一些我们在设计Qt4时用到的原则，并且展示如何把这些原则应用到你的代码里。

• 好的API的六个特性
• 便利陷阱
• 布尔参数陷阱
• 静态多态
• 命名的艺术
• 指针还是引用？
• 例子：QProgressBar
• 如何把API设计好

设计应用程序接口，API，是很难的。这是一门和设计语言同样难的艺术。这里可以选择太多的原则，甚至有很多原则和其他原则有矛盾。

现在，计算机科学教育把很大的力气放在算法和数据结构上，而很少关注设计语言和框架背后的原则。这让应用程序员完全没有准备去面对越来越重要的任务：创造可重用的组件。

在面向对象语言普及之前，可重用的通用代码大部分是由库提供者写的，而不是应用程序员。在Qt的世界里，这种状况有了明显的改善。在任何时候，用Qt编程 就是写新的组件。一个典型的Qt应用程序至少都会有几个在程序中反复使用的自定义组件。一般来说，同样的组件会成为其他应用程序的一部分。KDE，K桌面 环境，走得更远，用许多追加的库来扩展Qt，实现了数百个附加类。（一般来说，一个类就是一个可重用组件，原文这里没有写清楚。）

但是，一个好的，高效的C++ API是由什么组成的呢？是好还是坏，取决于很多因素——比如，手头的工作和特定的目标群体。好的API有很多特性，一些特性是大家都想要的，而另一些则是针对特定问题域的。

好的API的六个特性

API是面向程序员的，用来描述提供给最终用户的GUI是什么样子。API中的P带表程序员（Programmer），而不是程序（Program），用来强调API是给程序员用的，给人类的程序员用的。

我们坚信API应该是最小化且完整的，拥有清晰且简单的语义，直觉化，容易记忆，并且引导人写出易读的代码。

• 最小化：最小化的API是指一个类尽可能只拥有最少的公开成员且尽可能只拥有最少的类。这个原则可以让API更简单易懂，更好记，更容易除错，且更容易改变。
• 完整的：完整的API是指要提供所有期望的功能。这个可能与最小化原则相冲突。另外，如果一个成员函数属于一个不应该属于的类，很多潜在的使用者都会找不到这个函数。
• 拥有清晰且简单的语义：就像其他设计工作一样，你必须遵守最小惊奇原则（the principle of least surprise）。让常见的任务简单易行。不常见的工作可行，但不会让用户过分关注。解决特殊问题时，不要让解决方案没有必要的过度通用。（比如，Qt3中的QMimeSourceFactory可以通过调用QImageLoader来实现不同的API。）
• 直觉化：就 像电脑上的其他东西一样，API必须是直觉化的。不同的经验和背景会导致在判断什么是直觉而什么不是时不同的感觉。如果 一个中级用户不读文档就可以使用（a semi-experienced user gets away without reading the documentation，没懂这里的get away该怎么翻译），并且一个程序员不懂API就可以理解缩写的代码，这种API就是直觉化的。
• 易于记忆：让API易于记忆，使用统一且精确的命名方法。使用可识别的模式和概念，并且避免缩写。
• 引导易读的代码（Lead to readable code）：代码一经写就，会读（并且除错和修改）多次。易读的代码可能会花点时间来写，但是可以节省产品周期中的其他时间。

最后，记住，不同类型的用户会用到API的不同部分。虽然简单的实例化一个Qt类是非常直觉化的，让资深专家在试图子类化之前读一遍文档，是很合理的。
继续阅读

前不久，好朋友钟文将一篇谈Braid艺术风格的文章打印出来，给我看，我从那时起便多 方收集Braid的资料。直到最近，才在Xbox360上玩了它的试玩版，作者（Jonathan Blow对待这部作品的态度更像是一位作家，而不是游戏开发者）和画家David Hellman的完美配合更令我深深感动。也许不久后会有机会在PC或360上玩到这款出类拔萃的个人作品的完整版，不过，我迫不及待的要将这篇出自 David Hellman的文章介绍给你，希望你能喜欢这款作品。由于译者并不从事美术相关工作，有错漏之处，还请行家不吝指出。

Who has seen the wind?
Neither you nor I.
But when the trees bow down their heads,
The wind is passing by.

谁见到过风？
你没有，我也没有。
但当树儿低下头，
便是风儿经过的时候。

明天发布版本，由于前期测试没有做好，今天反馈回来不少棘手的bug，一直从下午改到了现在

发现自己代码写的真的不够细心，偷懒复制粘帖代码真的很容易出问题，特别精神不集中的话
继续阅读

在公司接手一个新项目的开发，一个很小的模块，却被我折腾一直到现在，终于基本稳定成型了，没有很好发挥leaderShip的能力啊（应该是缺乏，自己说自己就不损自己了 ^_^）。。。基本搭建完框架，菜单模块是hm和fjz做的，前台入口是hm，xjy写的大部分，然后后台DirectDraw特效基本都是xjy的代码了，基本解码库前人已经完成了，我只是做了表现的逻辑，然后都基本在fix bugs了-_-！ 难怪项目被我delay了。。。。。原来我在偷懒，呵呵

那就把bug的经验分享下
继续阅读