刚才要下载Mac版本的Mysql，所以去Google搜索Mysql，不过突然搜索结果右边的广告吸引了我。微软买了Mysql这个关键字，还要在广告里跟IBM的数据产品叫板多好玩啊。
可是，我点了之后，居然只看到一条错误信息：
Database not found!totaldb=0 dbname[1]=
我靠，难道是跟IBM比谁更幽默么？那估计微软要赢了。仔细一看地址是
http://mccannafa7.allyes.cn/main/adfclick?db=mccannafa7&bid=12680,6073,50&cid=6371,289,1&sid=12210&show=ignore&url=http://www.microsoft.com/china/sql/prodinfo/compare/default.mspx
原来问题出在好耶身上，微软的地址 http://www.microsoft.com/china/sql/prodinfo/compare/default.mspx 其实可以访问。
只是在宣传数据库的广告上，广告系统的数据库崩溃了，总让我觉得很有点黑色幽默。这更说明了数据库的重要性，不过好耶的数据库用的是谁家的，我还真是不太清楚，哈哈。
标签： google , 好耶 , 微软
之前有不少Blog用了
DreamHost ，还做了推荐，我的Blog一直在国外，所以也就没有凑热闹。
所以，头些日子听说DreamHost摆了一个大乌龙的时候，我自然可以幸灾乐祸一番。上次的乌龙不清楚的朋友，可以看看这篇文章《
DreamHost 大乌龙事件及众生相 》。大概过程就是DreamHost的联合创始人乔希·琼斯在对2007年欠费用户催缴时，写错了程序的参数，把2007写成了2008，这样本来不需要付款的无数用户就自动被扣了11个月的租用费，这是个 7,500,000 美元，甚至引发了些用户对网络服务自动扣款是否安全的讨论。
这当然是无心之失，虽然对很多客户损失重大（可能会造成一些客户信用卡透支），但是我认为还是可以原谅的，因为总归不是故意的，成熟商业社会里，只要生意还做得下去，估计没人会白痴到故意提前扣款，那么多用户，与其提前扣款赚一笔跑路，自然不如老老实实的服务客户，争取让客户多享受几年服务。
问题是这样的，头两天有个朋友告诉我他的blog被Google清出索引有些日子了，他怀疑是Google认为他的链接太多了。
我看了看链接其实不算多，而且也没有任何明显的作弊的迹象，这位哥们人品虽然谈不上值得称道，但是多半也是不会作弊的。
那么帮他申请个
Google Sitemap ，看看他的网站到底出了什么问题吧。谁知道，一确认，才发现GoogleBot报警说，无法访问他的网站，错误号是403。
网站访问毫无问题，那么看来这个403是专门针对GoogleBot的，你不让人家抓你，人家凭什么索引你呢，呵呵。
问问哥们，他说自己没做过任何的设置，那么多半就是空间服务商干的了。哥们说，他在用DreamHost，在Google一搜“
dreamhost 403 googlebot ”，马上就找到了两篇文章《
Errors with .htaccess : Site Down with 403 Forbidden Errors 》和《
Is Dreamhost support stupid or am i missing something? 》。
一看才知道，果然是DreamHost干的，他们刻意在一些客户的根目录的.htaccess文件中加入
<limit> 服务器有过多的GoogleBot访问造成压力，临时做些解决方案，暂时封锁GoogleBot倒是不稀奇的。但是，一来，做这个操作完全不通知客户，太不负责任；二来，我那哥们的blog已经很久不能被Google访问了，看来DreamHost的如意算盘是如果客户不知道，就这么一辈子节省流量，反正客户发现Google不收录，多半以为自己有什么操作过分了，或者直接以为Google抽风了。
So，DreamHost的行为是故意的，而且完全不考虑客户的利益和感受，十分卑鄙，值得鄙视，不值得推荐。另外，DreamHost中国人用得极多，容易被GFW，也不值得被推荐。
标签： DreamHost , google , htaccess
原文：
程序员的成长从开窍开始系列 一、如何摆脱低级错误的困扰 最近，有两位
Google Maps API 的初学者向我请教他们按照最简单例子写的程序为什么不能正常的运行。
其中一位用GTalk跟我交流，我仔细了看了他的代码，没看出问题，把代码保存在本地，打开Firefox的错误控制台，用Firefox打开他的页面。出错的那一行被清晰的显示出来，我再仔细端详那句话，原来有两个应该是英文逗号的地方，写上了中文逗号。
另一位，
在我的论坛跟我交流他的Google Maps API中遇到的问题 ，我看他代码的时候也没有马上发现问题。然而，同样在用Firefox打开后，问题很明显的找到了，原来是一个方法openInfoWindow被他写成OpenInfoWindow了。
在我帮助别人解决的程序调试问题中，这是非常常见的。人人都可能打出中文逗号，人人都可能把大小写写错。但是在我帮助他们解决问题以后，他们总是感慨的说，谢谢我解决了这个问题，这个问题困扰了他们几个小时，甚至是几天。
这其实并不是只有初学者才会遇到的问题，我还帮助过些有非常丰富经验的工程师解决问题，有时候问题仅仅出自某个参数没有传递进来，或者是拼接字符串的时候少些了一个冒号，或者是拼接地址的时候漏掉了http:。我甚至帮助一些人调试一些我根本不懂的语言的程序，因为多半出现的问题，都和语言特性无关，不是程序员写错了字符，就是写错了逻辑，或者是错误理解了一个函数。
出问题是正常的，写程序是一个复杂的边思考边打字的过程，笔误和一时糊涂都是难以避免的。程序员一般把这种问题叫做低级问题，因为这类问题跟你的智商完全无关，任何人都可能犯。
但是，问题在于，有时候即使是很优秀的程序员，也会被一个低级错误困扰，可能会几天都解决不了。所以，关键在于，如何找到问题。
遇到问题的时候：
不要怨天怨地。 出了问题，当然有可能是系统的bug，API的问题，但是那些几率往往比你犯低级错误的几率要低多了，先从自己身上找原因，是不是自己写错了。要掌握工具。 最低限度你要会写Log，最好是Log和调试器结合。好 的工具可以大大的提高效率。以前有人跟我说，Dll不能调试，我发现可以；有人说多线程不能调试，我发现可以；有人说COM不能调试，我发现可以；有人说 IE插件不能调试，我发现可以；有人说OE插件不能调试，我发现也可以。当然，你确实会遇到不能调试的时候，当年我们做东芝芯片的嵌入程序，一个组都没有 一个仿真器和调试器，但是至少可以用Log嘛，无非是麻烦点。分析问题要有逻辑。 遇到问题可以先把所有的可能性都列出来，然后一个一个分析，肯定能找到原因的。要学会隔离问题。 问题涉及到的代码越多，越难以理解，问题越难以解决。遇到这样的情况，可以利用Log或者调试器，一行代码一行代码的给它们洗清嫌疑，这样很快你就可以找到出问题的地方。如果代码特别长，程序特别复杂，可以用二分法来做，效率很高。千万不要懒惰，不要事事求别人。 一次复杂的调试过程就像一部侦探剧，如果你有非常好的逻辑性，那这部剧的主角就是福尔摩斯，剧情一定非常精彩。我说这个是有巨大风险的，说真的我帮人调东西挺上瘾的，很有意思。但是我还是要告诉大家，一次高难度的调试之后，你的满足感绝对不亚于写了一个伟大的程序。要想不遇到问题，写代码的时候：
要对写出来的代码负责。 我很佩服那些写代码写100行都不执行一次的 高手，如果他们最后不被低级错误困扰的话我就更加的佩服了。我写程序几乎是写一行两行就要执行一次，每句话我都要确保执行效果跟我的预期一致。没错这样写的时候 可能慢一些，但是调试的时候很轻松，我可以很简单的确定哪些代码绝对没有问题。所以我写代码整体速度比一般人高。很多人学习新东西的时候喜欢把例子抄一遍，运行一下，改改，再运行。我喜欢一句一句的抄例子，抄一句两句执行一次，这样可以把例子透彻的理解，而且很难会遇到出现了问题找不到原因的时候。函数体功能块不要过长。 我认为我的智商并不高，我很难接受一个程序的一个函数体或者一个功能块超越3屏（当然逻辑真的有那么复杂除外，你会发现越是简单的逻辑越是容易被人写的冗长）。很多人对面向对象耳熟能详，对封装继承看起来驾轻就熟。但是动不动就写出来个函数体超长的程序。这就像写本书从头到尾不点句号一样，会累死读者的。自己看的时候，估计也会被累的喘不过来气。这是我对基础教育的微词所在，他们连教会学生写函数都没教会，虽然表面上他们连面向对象这么高深的东西都教。缩进要对。 这点很重要，虽然大部分语言不是像Python那样用缩进来决定逻辑块的位置，但是人看到缩进的时候，总是会以为这些缩进位置跟逻辑相关。尤其是在有大量的ifelse或者for循环等等的嵌套逻辑的时候，如果缩进错了，可能会直接让人把程序的逻辑读错。所以我拿到别人的代码，第一件事情就是整理缩进。我见过一些比较优秀的页面工程师，他们会在div结束的位置用注释写上这个div的id，这样层级关系就一目了然了。不断重构。 随着程序的不断修改，有些部分会不断的增长，原来看着清晰的架构可能因为问题的复杂而慢慢模糊，也可能被修正bug的权宜之计弄的面目全非。不信你找一个经过多次修改的程序看看，是不是满目疮痍，是不是都很难认出是你自己的作品了。这在多人参与的项目中更加严重，每个人有不同的代码风格，经过多次杂交后，你肯定认不出你的代码是骡子是马，还是四不像了。随着程序的慢慢成长，原来有些函数体会慢慢膨胀，需要拆分；有些原来简单的功能块四处都需要，应该被提炼成函数或者方法，等等。现在不重构，未来等到代码复杂到无法控制的时候，重构的工作就会变得更加困难。我见过最强的案例是，一个几千行的电子辞典配套联机软件，经过无数次的改版，变成了一个几乎无法维护的主窗体的cpp有1万8千行的怪物。最后经过复杂的重构，才变成一个出新版本只需要新增一个驱动程序的可以维护的几千行的程序。这个故事详见：一个具体项目的重构（一） ，一个具体项目的重构（二） ，一个具体项目的重构（三） 。
标签： log , 调试 , 重构
测试数据是结构很简单的一个20M的XML文档，里面的数据来自我的一个项目。测试程序很简单，就是读取这个XML文件，把里面的链接写入到一个文本文件。然后把数据原样重复了一遍，然后又测试了一次，下面是测试结果。
方法 数据大小 内存峰值 CPU峰值 耗时 SAX 20M 20M 30% 142秒 DOM 20M 152M 100% 171秒 SAX 40M 20M 30% 290秒 DOM 40M 345M 100% 376秒
表1 SAX和DOM的性能比较
结论：SAX的内存消耗稳定，CPU占用率低，耗时短，大数据量XML的简单处理一定首选SAX。DOM的性能受到内存的严重影响，内存消耗受到数据量的影响，大数据量XML的读处理最好不要用DOM。
标签： dom , sax , xml
上周六，也就是10月27日，应
CSDN 之邀做了
一个Google Maps API的简单讲座 。讲得很粗，一方面是我的准备有点仓促（最近对Hadoop/
Mapreduce 太着迷，一天到晚的在研究），一方面是我对下面听众的JavaScript应用水平不甚了解，再有一方面，我觉得
Google Maps API 实际上太简单，而且概念少，代码多，讲座的形式不太好交流（下面的听众都说看不请投影的代码，这我可怎么办）。
但是还是承蒙很多听众的厚爱，写信跟我索要讲座的ppt，我本无藏私之念，只是总是觉得自己的东西写得太粗陋进不得高人的法眼，所以没有把
ZMap 开源。这次讲座，我把ZMap的核心代码全盘拖出，心中释然，丑已经丢了，就不畏惧开源了，这个事情总算可以放到议事日程里了。但是，诚心请求直接扒ZMap的JavaScript代码的朋友们，注意把我的Google统计代码去掉，这多让人啼笑皆非啊。
ppt的下载地址为：
http://www.zmap.org/temp/ppt.zip
标签： csdn , google maps api , ppt , zmap
最近一段日子的深夜或者凌晨，我总是在美剧的陪伴下仔细阅读和翻译
《Google文件系统》的论文 。翻译我做得不够完美，甚至谈不上好，但是这份工作带来的巨大的得道般的满足感一直支撑着我，让我不觉得疲倦。这本是我觉得自己不可能读懂的文档，但是真正深入的时候，我发现阅读它令我很快乐。
倒推10个月，在我和
霍炬 创办
银杏技术咨询 之前，我一直认为自己的性格不适合创业。但是现在我们用10个月良好的收入状况和日益增长的口碑，证明了我的论断是错误的。
再倒推到我的大学时代，我曾经认为自己会永远仅是一个VB高手。事实上后来，我轻松的学会了Asp，用它在大学赢了一个网站设计比赛，轻松学会BCB用它找了我职业生涯的前两个工作，轻松学会了Vc开发了365kit的outook插件，等等。而VB几乎已经7-8年没怎么用过了。
甚至，在某次刻骨铭心的恋爱失败后，6年中我以为自己会孤独一生，但我现在还是找到了相信可以步入结婚殿堂的人。
每次回想到这些，还有其他的一些另我自己唏嘘的往事，发现原来阻碍自己进步的，往往不是自己的能力和机遇，而是自己给自己设置的极限，而是自己以为的自己可以做到的最高点。
记得好像是
李卫公同志 哪篇blog提过龟兔佯谬，话说是只有学了极限才能最好的理解这个问题的实质。其实，这个有问题有个思维逻辑上面的解决方法，那就是你把过程抛弃，直接看N秒后，按速度×时间，很容易算出兔子一定在乌龟前面。
那么中间是怎么超越的呢，可以给出的一个简单的答案是，如果你太关心怎么超越的细节，你可能就真的很难超越了。So，把对手先隐去，跑吧！
所以，最好的对手是自己，最好的目标是无限远处……
标签： 极限 , 目标
最近一个处理非常大的XML的程序遭遇了如下的异常：
org.xml.sax.SAXParseException:Parser has reached the entity expansion limit "64,000" set by the Application.
查了查，原来是在单个xml文件中实体引用超过了默认值64000个。你用dom和sax解析XML都可能会遇到这个问题，这印证了我的猜测，java的dom是用sax来实现的。
解决方法很简单，运行Java的时候，加上参数
-DentityExpansionLimit=xxxxx ，你也可以在代码中解析XML前，用代码设置这个参数
System.setProperty("entityExpansionLimit", "xxxxx"); 。xxxxx代表设定的单文件实体引用数最大值。
--------
那么这个xxxxx该怎么选择呢？
其实也很简单，选择你认为可能出现的最大值就好了，比你的文件里面的实体数多，自然就没问题了。
--------
那么如果你想知道某个文件里面有多少个实体引用该怎么办呢（放心我肯定不建议你去数）？
对，也很简单，首先我们知道实体引用都是“&"开头“;”结尾，所以我们可以用如下命令来计算：
grep -c "&.*;" yourfile.xml
其实，&在xml里表示为&的形式，所以，一个合法的xml内，有多少&就有多少实体引用，so，上面的命令效率更高的版本是：
grep -c "&" yourfile.xml
--------
为什么会对最大的实体引用数做出限制呢？这点我有些疑惑，难道要为解析实体引用准备缓存空间？但是做出来自动增长的缓存也不是不可能的啊。DentityExpansionLimit参数的问题是，如果要处理无法预期大小的xml文件怎么办？你设置为100万，xml文件里面有200万个实体引用，你有办法么？
标签： DentityExpansionLimit , dom , Javascript , java异常 , sax , SAXParseException , xml
今天，把Code里面的e.printStackTrace全部用自己的log函数替换掉了，因为貌似System.out.println很浪费时间，而且大量的异常输出到控制台会降低程序的稳定性。
我们的项目里面需要一个webserver，但是我实在对Jsp+Tomcat的性能不放心，自己写了一个非常精简的webserver。性能我很满意，用ab进行测试，速度可以跟同台服务器上lighttpd静态文件的速度媲美。
在每日访问量10万以内的情况下，服务两个星期左右会产生一次锁死，kill也无法关闭进程。只有利用kill -9才能关闭进程。说实话，这种锁死频率倒还可以接受。然而在每日访问量峰值达到20万的时候，高峰日可能会有2-3次的锁死，这让我很挠头。我想了很多办法，还是没有明显的改善。
今天去掉了e.printStackTrace，希望明天webserver的稳定性可以提高。
有对这方面经验丰富的朋友么？请告诉我Java网络服务如何能长时间稳定运行呢？谢谢！
标签： java , log , printStackTrace , System.out.println , webserver
查看地址：
Google混搭编辑器(Google Mashup Editor)中文文档 Google混搭编辑器(Google Mashup Editor) 是一套用来开发混搭应用的Web开发工具，它是一套函数库，也是一个IDE。不管你的应用本身多复杂，用了多高深的技术，值得庆幸的的是我们有Rss/ATOM，利用他们我们可以举重若轻的把不同公司，不同利益集团的产品粘合在一起，创造新的视角，新的应用模式。这就是
Google混搭编辑器(Google Mashup Editor) 的意义。
为了便于国内的开发者使用Google混搭编辑器(Google Mashup Editor)，我在学习过程中制作了
这个中文文档 ，完全翻译了
产品概述 和
入门指南 两个部分，因为这两个部分可以让你充分了解
Google混搭编辑器(Google Mashup Editor) 的思想和用法。标签参考文档、操作数据、过滤数据、事件处理以及JavaScript API，留待日后慢慢翻译完善。
之前，我还翻译了Google Maps API的文档，地址在
Google Maps API中文同步文档 。欢迎有兴趣的朋友查看。
今后的翻译计划是
Google AJAX Search API 文档和
Google AJAX Feed API 。
标签： ajax , document , feed , maps , Mashup , search
[搜索引擎友好之路]是我准备写的一本书，现在大部分网站都有丰富的内容，但是他们为了得到流量去尝试那些搜索引擎作弊方法，往往是一时得到好处，最后被搜索引擎屏蔽。我们倡导的与搜索引擎友好的优化方式就是试图更好的展现你的内容，达到网站和搜索引擎共赢的局面。下面的问题是一次去给客户做培训后，客户提出的问题和我们的回答。
1、程序生成很多的静态内容链接自己，算不算作弊？ 一个行为算不算作弊，主要是度的问题。生成很多垃圾的静态内容（采集来的，胡乱生成的），只要达到一定的量，一般是会被判定为内容重复或者作弊的，可能会 被降低权重或者删除索引。实际上我们知道现在很多网站自己的内容很丰富，把自己的内容展现好了，就会带来很多好处，不需要去胡乱采集。
2、flash对网站收录的影响 flash本身没有任何不好的影响。而常见的错误的行为是对flash的滥用。
比如，整站全部用flash，设计者或者唯界面论者可能会这么做。其实这样并不好，第一是速度往往会很慢，而且有可能会长时间等待；第二是干扰用户习惯， 很多人打着提高用户感受的旗号去滥用flash，那样做出来的作品，如果说欣赏或者只是试用往往还不错，长期使用用户往往忍受不了；第三是整站所有的内容 无法被搜索引擎收录。
还有很常见的滥用是内容页面很丰富，但是首页只有一个flash而没有任何文本链接可以帮助用户进入下一级页面。这类问题往往出现在一些大公司的网站中。 虽然确实很美观，但是问题也很多。第一也是速度，网民多数没有耐心，看到一个长长的loading条就会迅速离开；第二，如果用户不安装flash插件， 就无法看到首页，从而无法进入本无需flash的内容页；第三，搜索引擎无法穿过首页去访问后面的页面。所以我们会发现很多公司的网站pagerank很 高，但是内容页面完全没有pagerank。所以在搜索引擎搜索产品名字，往往是第三方的网站排在前面。这类网站最好在下端放一个二级栏目的导航条，至少 也要放一个“点击这里跳过flash直接进入内容”的链接。
3、no script有用么？ 当然有用。现在很多网站喜欢用Javascript特殊效果或者Ajax，这本身没并不是问题。但是，如果用Javascript来显示网站的导航，就有 两个问题，第一，对于不打开Javascript的用户，他们无法进入网站的内部；第二，搜索引擎往往无法收录Javascript展现的链接。no script可以解决这个问题。
包含在 noscript标记内的代码会在不打开Javascript的用户的浏览器上面展现，搜索引擎也可以从中获取导航信息。
但是，最好的选择还是，导航本身使用标准HTML代码，导航的特殊效果用css和Javascript实现。以后我们会有专门的文章阐述Ajax网站如何进行搜索引擎优化。
4、更新频率应该多高才适合？ 更新频率理论上当然是越快越好，但是并不推荐没有内容胡乱更新。现在大部分网站的内容都很丰富，更新频率已经足够了。
5、js生成的更新，能不能被收录？ 跟Javascript有关的问题，答案其实都一样，用Javascript生成的链接，大部分搜索引擎的爬虫不会去抓取，自然也就不会被收录了。
6、不愿和外部网站交换链接会有什么影响？ 不愿意交换链接自然对Pagerank有不好的影响。但是如果你的内容确实好，自然会有用户主动链接你的页面，这样你的PageRank自然会得到提高。
7、抓外站新闻对SEO有用么？ 用处不大，抓外站新闻得到的内容实际上都是所谓的重复内容，价值并不高。
8、和外站交换链接，放什么位置重要么？ 重要，当然是Pagerank越高的页面越好，位置越前越好。
9、大型网站会给其他网站做链接么？要多少钱？ 交换链接一般是双赢，所以只要你的网站质量达到一定水平，交换链接并不难。一般不要钱，要钱的反而需要警惕，这是搜索引擎禁止的行为。
10、在网站中，同一级的页面，是PageRank越高，抓取频率越高么？ 对，Pagerank、整站信用级别和页面更新频率共同影响抓取频率，所以Pagerank越高抓取频率越高。
11、Robot.txt对SEO有什么影响？ Robot.txt很有价值，但是一般被站长低估和误解。很多人认为只有防止搜索引擎技术抓取的时候才有用。但是实际上正确使用Robot.txt对 SEO很有好处，比如重复内容用不同形式表现是经常需要的，而这种情况很容易被搜索引擎判定为重复内容堆砌。正确利用Robot可以引导搜索引擎只收录首 选内容这样就不会有作弊嫌疑了。（参见：google网站管理员blog的文章“
巧妙地处理内容重复 ”）
除了处理重复外，Yahoo允许你在Robot.txt文件里面用Crawl-delay:参数设定抓取频率（参看：
如何控制Yahoo! Slurp蜘蛛的抓取频度 ）。Sitemap协议支持你在Robot.txt文件里填写Sitemap参数（参看：
Specifying the Sitemap location in your robots.txt file ）。
12、二级域名能有多大的好处？ 好处不大，如果用户喜欢的话，就用吧。
13、用户页面的url，用文字还是数字好？ 如果用户名不允许中文，那么文字比较好，虽然汉字也可以用在url中，但是总是有些浏览器的支持不够好。如果用户名允许中文，就用数字吧。基本上这不是一个很重要的选择，虽然搜索引擎技术也会把url里面的文字当作可被查询的内容。
14、flash meta data对SEO有何影响？ 未来可能很重要，但是现在应该还没有多少搜索引擎支持这项技术。
15、爬虫有没有关于Ajax的抓取计划？ Googlebot也就是Google的标准蜘蛛，是不支持Javascript的。但是Mediapartners-Google也就是Google Adsense的爬虫，实际上是支持Javascript的。这也就是说技术层面考虑支持Javascript并不是一个问题。但是限于效率和任务优先级 的考虑，Google暂时还没打算让标准蜘蛛Googlebot支持Javascript。
百度的爬虫支持一部分Javascript，但是由于技术和效率的限制，相信百度也不能抓取100%的Javascript内容。
16、在js代码中放url有用么？ 答案显而易见，没用。
Virushuo对本文亦有贡献
标签： flash , Javascript , noscript , Pagerank , Robot.txt , seo , 搜索引擎优化 , 搜索引擎友好
我提的问题是：
1、在我看来Borland曾经的危机，主要来自于产品过渡绑定于Windows平台，而这个平台的控制者也在做开发工具生意。请问Code Gear认同这个观点么？
2、基于前面的看法，我认为Code Gear想要发展壮大，应该努力让自己的产品不在依赖于单一平台。而且刚才David I谈到了两点，Code Gear百分之百关注开发者，以及Code Gear开始关注web开发者。基于这个观点，我认为Code Gear更需要努力扩展到更多的平台。因为Php的开发者/Ruby on rails开发者中非Windows平台的开发者比例都是比较高的。我个人就是一个例子，自从把个人主要技术方向转移到Web方向后，立刻就买了一个MacBook。请问David I怎么看这点？
他的回答太长了，我记不住，所以等到Csdn出了新闻稿，我再贴出来。
大意是：
1、他不认为Borland曾经有了一场危机，只是Borland准备更加关注企业级应用，项目生命周期管理，而成立Code Gear是为了关注于开发者的需求。
2、太长了，实在记不住。
标签： borland , code gear , csdn , David
貌似比较有意思，有兴趣的朋友可以考虑参加，地点和联系方式如下：
