CMS漂流

被SD2.0大会折腾了几天，云计算总算作为一个包罗万有的概念深入俺的脑海了。

这儿有冯神的风计算，很好很强大——不许笑：

http://www.dbanotes.net/Keynotes/WindComputing.pdf

SD大会赠送了180块的书劵，但跑到博文视点的摊位时，选好了书，然后被告知劵能选的只是批定范围的。然后看到所谓的指定范围，和网站上预先公布的可选书单完全不同，几乎，全是，垃圾。

无奈之下选了微软出版社的两本说明书，一本Windows Server 2008 Administrator’s Pocket Consultant，647P，$34.99，一本Internet Information Services (IIS) 7.0 Resource Kit，779P，$49.99，均折价RMB 80，算是把劵花掉了。

然后刚从SD2.0大会回到家，即把选好的书在China-pub下了订单：

一线架构师实践指南（China-pub上竟然尚需预订，大会现场已经有了，郁闷没在会场买签售版） 温昱 电子工业出版社 RMB 35

敏捷无敌

观止--微软创建NT和未来的夺命狂奔 (SHOW STOPPER!中文版)(揭示微软鲜为人知的秘密)

软件开发沉思录--THOUGHTWORKS文集(CHINA-PUB首发)（来自软件界思想领袖们的经验心得）

程序员修炼之道--从小工到专家(十周年纪念版)

MYSQL性能调优与架构设计(CHINA-PUB首发)

还看到这本：

深入理解MYSQL核心技术 (UNDERSTANDING MYSQL INTERNALS)  原版似乎是2007年的，Amazon上评价很高，但评价者很少，中文版2009年9月才出，很便宜，但最近不打算读，等一阵再说

现在，最最期待的是，CSDN尽快发布各讲座的PPT，太多内容需要对着PPT逐页复习了。

感觉今年SD大会官网好破，英文版就一页，弄得跟老板报告都不好意思。所谓的在线支付更是个笑话，弄得俺下来还是得换招行支付，然后支付完了确认总要自己打电话，折腾了一天半才终于被确认给他们汇了钱。

云计算，移动开发，大型架构，然后再是某厂商推的下一代语言。邀了几个知名博客作者。当然，还有挺多项目管理与敏捷的话题。

没有开源趋势，没有产业研究，没有文化和互动。

反正前一个项目刚差不多快结束。去观赏一下其他技术人员的脸也好。

不管怎样，10月22-24，在温都水城。

有朋友公差匈牙利，回国，在北京转机逗留几个小时，正是中午，于是到三元桥来看我，吃饭，谈到他们的daily report，再比照我们公司的每月自主回顾估测项目耗时。才知道严肃的管理和欧洲式的放松真是天差地别的。

做软件，公司靠管理，个人靠钻研。这也是欧洲的好软件公司不多的原因。

不过，中国人狡诈，欧洲人诚实，这也是欧洲公司管理里面框框少的原因。

软件需要发明创造，但将发明创造整合起来，非得有大量的规矩不可。

这兄弟木讷，智商从初中到高中一向被我们认为是75，但在HW某关键产品线某小组，是绝对主力。

兄弟送我一盒巧克力，8.5欧，礼轻情意重。

kolidon原作于2009年9月24日

1. 模板一致性
此问题并不是指模板风格和CSS一致，虽然这也很重要但是并不困难。Drupal中模板的问题在于因为系统模板的灵活，模板很难集中控制。即，模块中代码未模板化，或模板置于多个目录位置。

习惯以自有框架特别是某一种特定模板方案比如smarty一类，并且对模板进行集中处理的团队，转入Drupal后往往会对此迷惑。

实际上，这个问题是一个技术问题。

实施中解决办法是：制定出团队自己的模板命名，控制规范并不断修订完善。在每个项目中，对模板、自定义模板函数、自定模块中的模板以表格视图进行跟踪。

虽然Drupal系统提供了大量可能的模板化实施可能性，但对此系统了解越多，越能发现最简单的往往是最可靠的：仅使用模块内模板结构+模板目录内统一控制。

2. CCK及Views的使用

我们发现，基本上所有情况下Views殾能满足我们的需求——如果善用其Api文档的话，kolidon所在团队亦在学习如何将更多block也Views化——当然是不是一些其他页面也Panel化就有待考虑了（因为莫须有的性能问题）。

但我们偶尔会需要添加自定义的扩展模块来对其功能进行更改或扩展。

3. 权限问题

我们有时会需要在term页列出所有文章及其teaser但一个常用模块Content Access可能阻止那些无权限的文章出现在此页面，而此模块可能在其他页面会能用到（当然若不使用此模块此处不会用问题但会对项目其他需求造成不便）。

此时我们常做的时完全放开此content type的权限改由自定义模块来控制其全文存取。

4. Input format

输入格式对不同roles的授权也是需要较长时间试验才能获得满意结果的位置。

5. 开源模块质量

开源模块并非拿来就能用，最好看看其是否对性能造带来多大问题：比如某个模块og content admin就可能是一场华丽的性能灾难。

6. Menu及Breadcrumb系统

这个不用说，在任何系统中都是重中之重。若你使用了大量的第三方模块，然后又使用了大量的自定义模块，然后又企盼能将它们无缝组合起来：指的是在外部表现、菜单和Breadcrumb上的完全按业务需求而非模块的目录和自命名结构，那么，多考查几种相关模块，再多花点时间反复试验以便最终熟练吧。

7. 请尊重garland模板

这套模板，实际上，已经帮助我们完成了任何自定义模板工作的80%。所剩的唯有考查是否需要新增area，对原style.css作何种重规划和改进了。但对其整体结构的改变，试过后才会知道，意义不大。

8. locale问题

多语言在任何系统中都会是一个问题，kolidon并不认为Drupal在解决此问题上就已经完美了。

如果你仅仅是需要开发一种特定语言的系统，那么事情不会特别复杂（虽然也会出现一些莫名其妙的问题需要耗费大量时间去调试，比如关闭原生的English时你会发现部分页面会变成blank）。若需要开发多语言而且需要它们能正常切换，那么，诸天神佛保佑，但愿你的团队中有人研究过所有源代码，对这一部分的系统实际有深入了解并随时愿意解决各第三方模块中可能出现的语言问题。

9. Messaging和Notification

这部分也很好玩，如果你花了很多精力玩转了的话，另外，当然Cron不会是一个大问题但同样需要我们保持关注。但是当Messaging、Notification与Locale问题纠缠在一起，特别是不同的用户需要不同的Messaging的时候，我不知道它们是不是仍然让人喜欢。:-)

10. JS问题

如果团队中没有人精通JS，那么至少需要了解Jquery的用法和Drupal的JS框架。上天保佑，这么多Js不会产生冲突。

11. 性能问题

这个实际上如果没有太变态的第三方块的话，不会有什么问题，但若对性能要求较高的话，在登录状态，会需要所有人来贡献智慧以便解决周边的性能问题比如数据库、Gzip压缩、图片大小、背景图片或装饰图片数字，Js性能等等。最后，你会发现，转了一圈，回来了——我们终将面对的是登录状态下的Drupal核心的性能问题。若到了这一步，基本上，团队就开始专业起来了。