Willingness to participate in a 24/7 system infrastructure monitoring and support team -----------我汗

siqian 于 2008-7-21 17:27 发表
楼上这个赞美太地道了 [/quote]

我差点让人家打死。。。。

既然要玩博客，选择什么程序搭建平台？ 我的要求很简单：

* 稳定承担低、中负载的访问，能生成静态页面当然更好 * 功能完整，可订制性强 * 良好的支持 * 每次版本更新不仅仅是版本号的更新 * 最好是多用户版本（大概会提供 10 用户左右的服务）

首选的对象是 MovableType。

能生成静态页面，新版本 3.3 安装起来感觉很方便。即便我的 APACHE 原始日志/错误日志只能用 https 进行访问，多少感觉有点儿慢，调试起来有点儿吃力，也是小事一桩。

可是很遗憾是它的许可证。

也许有人会告诉我，现在 MovableType 对个人是免费的，但是 Six Apart 的许可证政策明天怎么样，谁又能告诉我呢？如果更新了安全特性的新版本的许可证发生了变化，我应该升级还是坐以待毙？

实际上，从我的需求分析，静态的页面对于只要求中负载的我来说可有可无，要得到对搜索引擎友好的页面通过 apache 的 UrlRewrite 也许是更方便的方法。而且正是由于静态页面，随着文章增多，生成过程也逐渐成为负担。

另外在 Google 的时候发现，最近关于将 MovableType 迁移至 WordPress 的教程类文章特别多;;)

WordPress、LifeType 是同时进入我的视线的。 我只能说 LifeType 很不错，但我对它的发展前景并不是很明确。由于支持多用户，在 plog 时代，我想它应该是我的唯一选择，但 WordPress 到了 2.0.* 以后，两者之间的差距就拉大了。

尤其是当我试用 LifeType 时，它过于阳春的界面深深的 “震撼” 了我，因此它得的 UI 印象分是最低的。 WordPress 富有魅力的插件系统、模板结构（LifeType 对此有不同意见，认为不含有 php 代码的模版更安全）是吸引我的主要因素。

针对寥寥的几个用户，我更喜欢多装几个重复的 WordPress——不要和我提 WordPress MU，虽然 1.0 发布了，但还是一个半成品的样貌，但以后也许会用——而且经过试用 WordPress 2.1 beta，对它的发展概况了解后，更坚定了使用它的信心。

结论：

1. 如果负载是决定你选择的主要原因，那么，去找 BSP！
2. 如果超多用户使用，建议使用 MovableType。
3. 如果像我一样的需求，WordPress 是不二之选。
4. 实话实说，用 LifeType 不如去用 WordPress MU 或者 WordPress 的一些 hack 多用户版本。

我知道像这样的对比文一向都喜欢遭口水，那么，建议有不同意见的各位使用 Google 趋势中的数据，也许能更简单地得出结论

由于 WordPress 多用户版并不是 WordPress 开发团队开发的，是由几个 PHP 业余爱好者负责，所以开发进度慢，很多 bug 一直没有修复，不过现在 bug 已经比较少了，最近多用户版官方论坛讨论的人越来越多了，所以 bug 比较好解决。

官方网站：[url]http://mu.wordpress.org/forums//url][ 论坛：[url]http://mu.wordpress.org/forums//url][ 下载地址：[url]http://mu.wordpress.org/nightly-builds//url][ cvs 每天更新 简体中文语言包见附件（这是我偷 donews 的）

目前 PHP 开源世界里只有 WordPress 和 Lifetype(以前的 plog) 还算不错，商业的也有很多，比如 Pmachine、bloghost 之类的。

WordPress 多用户版每个用户都是单独的表，互不影响，当然这也有很大的弊端，如果用户多了数据表将是一个很大的数量级，一个用户 10 个表，在服务器里就是 30 个文件 (.frm,.MYD,.MYI)，10000 个用户就是 300000 个文件，不断读取这么多文件对 mysql 和服务器硬盘也是一个很大的考验，所以这种数据存储方式并不适合做大量用户的 blog。

WordPress 多用户版比 Lifetype 还像多用户，数据表独有，再用 rewrite 可以做到让别人看不出是用多用户 blog，后台也是用自己的二级域名访问，自己 blog 上的文件，图片，附件路径都是自己的二级域名。

branch A branch is a revision path that diverges from the main line of development (or trunk) in a member or project history.

分支:一个分支就是一个修改路径，它在成员历史或者项目历史上与主开发路线 (主干 trunk) 分离。

[b] Sandbox[/b] Sandboxes can reside on the client machines and allow you to work locally in your own workspace, without interfering with the work of others. You can think of the Sandbox as a local pointer to the project residing on the MKS Integrity Server. A Sandbox is a mirror image of a MKS Source project. Although it looks and acts like the project it mirrors, it is actually a collection of pointers to its real-life counterparts in the master project. 沙箱 (sandbox) 存在于客户机器上，并且允许你在自己拥有的工作空间上本地工作，而不会干扰其他人的工作。你可以认为沙箱是作为本地的一个指向 MKS integrity server 上项目的本地指针。一个沙箱是一个 MKS source 上项目的镜像文件。虽然它看起来象也确实担当着它的镜像项目，但是事实上它是一个指向主项目（master project）的实在的副本。

注：在平时开发中，我们一般都采用的是离线开发方式（当然我们有的时候需要在线开发）。也就是我们把代码从代码库中 check out 到本地的一个目录中，然后进行开发，开发之后在提交到版本库中去。那么在 MKS 中，这个本地的工作目录就称之为沙箱 (sandbox)

附：Sandbox(沙坑) 的概念在于确保使用者下载 Java 小程序 (即 applets) 后，程序只能在限定的环境下执行。 Sandbox 原字面意思即为儿童游戏用的沙坑，相当类似游戏床。在 Java 概念下，我们可用亲戚的概念来看 sandbox，假设你亲戚的小孩来你家玩，你会把她放在沙坑 (或说游戏床中)，一方面不但可保护她，另一方面也是避免她乱跑打坏家中的贵重物品。 同理，使用者虽然喜欢下载各式 Java 小程序，但也不希望不小心遭到不本份的程序的趁机入侵，搞坏系统.

[[i] 本帖最后由 laofo 于 2008-7-21 12:58 编辑 ]

The files under version control in a project are known as members. A member’s content is stored in an archive. MKS Source creates a history file for each project member where its history of changes is stored. Each submitted update is recorded in a member’s history as a revision and given a sequential number for reference. The original version is numbered 1.1, and each subsequent revision increases the number to the right of the decimal point by one. Each member revision can be viewed individually.

在一个项目中处于版本管理的文件被成为成员 (member), 一个成员的内容以存档的形式进行存储。MKS Source 为每一个项目成员 (project member) 创建一个历史文件来存储这个成员的更改历史。每一次提交更新都会在成员的历史中以一个修订本 (reversion) 记录下来，并且会有一个序列号进行索引。初始的版本号是 1.1， 每一个后续的修订都会在这个数字小数点的右边增加 1。每一个成员的修订（记录）都可以单独的被查看。

change package A change package is a group of changes made by a single user that can be considered a logical unit of work. Only the creator of a change package may add entries to that change package. Change package entries take the form of operations, both deferred and committed. When reviews are mandatory, change package entries take the form of pending entries before they are committed.

更改包：一个更改包是一个用户所作更改的集合，这些更改的集合是一个逻辑上的工作单元。只有更改包的创建者才可以向自己的更改包中添加条目。更改包同时可以采用延期的（deferred）和提交的（committed）方式。当检查 (review) 是必须的时候，更改包在他们被提交之前采用的是未决的条目（pending entries）

注：我自己的理解是，当我们需要更改一个 bug，或者增加一个 feature 的时候，我们所作的更改在逻辑上属于一个集合（在物理上涉及到多个文件的更改），那么我们把这个集合叫做一个 change package

development path: A development path is an identifier given to a new branch of software development. Changes made through the new development path are kept separate from the main development trunk unless you choose to merge them later.

开发路径是一个新的软件开发分支的标识符。在新开发路径上所作的更改都会与主干保持独立，除非你选择在后期合并他们。

渐渐的发现自己原来都快成 CIO 了，哈哈哈哈

我们还可以用 CI 来自动打包，直接作出安装程序 每次测试之前删除数据库，重建数据库等等 。。。。。

当然用 CI 也是有限制的，比如有一些项目 build 的过程中需要太多的手工参与的过程，而这些手工参与的过程又是不能用脚本实现的，那么这样的项目做起 CI 来就很困难。比如我们 公司有个项目就是需要手工参与的地方太多了，build 过程太复杂了，现在还处于最原始的 build 状态。

如果想做持续集成（CI），我自己感觉分以下几个步骤：

1 理顺现在公司的 build 流程 看看现在所有的项目的 build 过程都是一个什么样子。有没有利用脚本组织，例如是否通过 makefile，Nant,ant 脚本等组织起来的，可否在命令行运行一个命令，哪怕可以输入 1－2 个参数，就可以 build 整个项目。

1. 如果公司现在的项目还没有利用脚本组织起来。那么先从用脚本组织 build 流程开始做起 .net 环境，建议用 Nant 组织 java 环境，用 ant 事实上用脚本组织这些项目的 build 过程是很容易的，有的时候就是一个 target 就完成了
2. 如果公司现在的项目已经利用脚本组织起来了，那么剩下的事情就好做多了。 搭建一个 CI 服务器，可以用 ruisecontrol 或者 cruisecontrol.net，这个仅限于 java/.net 平台下 如果是 C/C++ 的可以考虑其它的，不过 Cruisecontrol 或者 Cuisecontrol.net 也可以 build C/C++ 的项目 大家服务器之后，添加项目，利用 CI 服务器配置文件中提供的 target 等，取代码库中的代码。 取代码的 target 也很好写的，一般你告诉 CI 服务器你的代码库地址，访问用的账户密码什么的，CI 服务器就可以自动取出当前代码库中的最新的代码，同步到本地

同步到本地后就开始 build 代码

build 成功后把代码和输出结果都 copy 到另外的一个 server 上。这些结果你可能要给测试组。

然后 CI 服务器，或者 Nant，ant 脚本中利用邮件通知相关人等，这次 build 的结果。

[indent] 大概就是这么个过程，当然等第一次成功之后，你可以慢慢的加入更多的功能，比如 每隔 10 分钟 build 一次，每次 check in 就 incremental build 一次，每天夜里做一次 full build 每次 build 之后，运行 test case,做一遍测试，每次测试后，得到这次测试的覆盖率 每次 build，都检查代码规范（事实上这部分，可以用一些 trigger，让他不符合规范的 code 都不让 check in 到代码库中） 检查代码质量，命名规范，注释率 [/indent]。。。。。。

总之，CI 做的 build，可以做的更多更好，做的比手工的更强大。

[[i] 本帖最后由 laofo 于 2008-7-19 21:14 编辑 ]

CMing 于 2008-7-19 10:03 发表
clearcase clearquest 最新补丁包下载地址：

clearquest7.0.1.1 [url=ftp://ftp.software.ibm.com/software/rational/clearquest/7.0.1/7.0.1.1-RATL-RCQ/7.0.1.1-RATL-RCQ-WIN-zh-CN-FP01.mspftp://ftp.software.ibm.com/software/rational/clearquest/7.0.1/7.0.1.1-RATL-RCQ/7.0.1.1-RATL-RCQ-WIN-zh-CN-FP01.msp[/url]]

clearcase7.0.1.1 ftp://f ... [/quote] 哇，你给的这个链接里边内容好丰富啊

AIX，websphere，clearcase，clearrequest。。。。都有

上次我赞美一个女生：

你长得好胖啊。。。。:( :(

CMing 于 2008-7-19 10:12 发表
呵呵,欢迎你的到来,同时希望您能为我们的论坛做出一份贡献. [/quote] 支持～～

CMing 于 2008-7-19 10:32 发表
LZ 翻译的 不错,向你学习了! [/quote] 哈哈哈，我只是看到了，想翻译一下。顺便整理下自己的思路。

事实上这些想法，我们也可以用来说服公司的决策层，你的 manager 等等

CMing 于 2008-7-18 18:14 发表
楼主公司有没有在做 DadilyBuild?

跟你好好学习学习. [/quote]

有，我觉得做的还是相当不错的。的确很不错的实践。

把公司的 build 流程做成自动的，不但省去了一部分人工的成本，而且更快的给项目组项目进行的反馈，更容易 control 这个项目，也有利于提高产品的质量。

我的公司正在用 MKS（Source Integrity 和 Integrity Manager）以及 WSAD，我们的开发人语对于集成（的工具）非常满意。我也搭建了 Clearcase 和 Synergy，和 WSAD 一起用，也有不错的效果。 基于价格的考虑，我认为你可以仔细考虑一下 MKS，但是当你评估一个工具的时候，多看看 corssroads 上的讨论，你就可以得到更多的信息和其它人的看法。 －－－Leighton

我支持 Leighton 的看法。我们已经用 MKS Source Integrity 五年了。并且我们发现它已经完全满足项目硬件和软件的需求。我也有 Rational ClearQuest 的经验。在我看来，它更像是在用 DTP 软件（desktop publishing software），这点依赖于你怎么期待它去工作和你怎么想去做，然后两者都支持它。

然后，基于你觉得怎么规定 SCM 的流程，公司的整体策略等等，你需要去选择那些预定义更接近，或者不用裁减（公司流程？）很多的工具。这些工具都会支持他们认为的什么是最好的实践，这也不是件坏事。（这些工具都有一套自己的流程，他们认为这些流程是最好的实践）

然后，你需要从公司和开发团队的角度去衡量，接受这些。

希望这些能对你有用 －－－－Stephen Fisher

虽然我们正在向 SIEE8.x 转换的过程中，并且我们大约有一半的本地用户，但是我有一些自己的看法。

我坚信 SIEE 在扩展方面进行了特定的设计。除了提供一个有足够流量和存储空间之外，我认为有两方面你应该考虑

1 你应该制订配置管理的决心和决定，这些规定可能依赖于那些喜欢去同时修改一个文件的用户的数量；在开发依然进行的时候，是否你需要支持补丁（例如，你是否会用一个分支或者用分支合并的功能？）；你的开发流程（你是否有设计者，开发者，测试人员等等，这些人可能会影响你怎样去用状态提升）。

你也需要去决定是否用和怎么去用冻结（freezing)/解冻（thawing）.我认为没有唯一的最好实践，因为每个公司的环境都是不一样的。

2。其它主要的问题是权限 (access control List) 的管理。如果你支持大量的用户，并且你有一些特定的角色，如果这些角色每个项目（或者每个合同）都是不同的，那么相对于角色定义组那么会显著的降低管理中的工作量。

我们花了大量的时间思考这个问题，并且依然在摸索，还在不断的在改进。我认为你不能期待它一次就走上正确的路。比较有意义的是，我建议你提供更多的信息，例如你是否支持多个合同.这些项目是全新项目，还是正在运行项目的维护？一个商业的产品的项目还是一个内部的产品等等。

－－－ 简单翻译了下，意译，可能不正确，凑合着看吧

CMing 于 2008-7-17 14:58 发表
autodesk 公司不了解, 但是 Cadence 办公的地方似乎很小. 对技术要求很高,招聘信息上的基本上都要求精通. [/quote] 招聘的时候如果到了面试阶段，基本就靠感觉了。

因为东西可以学，但是有一些气质，思考方式是难学的。所以面试多看重这个，否则也不会要面试了。

当然基础知识，肯定要有。

CMing 于 2008-7-18 17:16 发表
写的很有内涵,学习了! [/quote] 那个回答的人的确讲的不错

CMing 于 2008-7-18 16:12 发表
目前我这里还没有 CM 方面的的人,如果遇到合适的,我会尽快把他们介绍的这里来的. [/quote]

Cool. Thanks very much

CMing 于 2008-7-17 14:45 发表
希望管理员尽快招聘斑竹,让他们各尽所职,把论坛迅速规范化,专业化,这样才能把论坛的访问量. [/quote]

一直在招聘，只不过网站刚刚成立，现在还要多积累，多宣传。如果你认识其它的 CM，不妨推荐推荐

CMing 于 2008-7-17 11:59 发表

呵呵,laofo 也学习 clearcase 和 clearquest? [/quote] 一天不学习，赶不上刘少奇啊

一个国家为了自己的利益，肯定一开始要把好的域名保留下来，否则等别人注册了，自己再想要就要不难了。 要回来的途径有 2 1。仲裁 2。花钱买。

今天晚上 11 点以后就可以注册.me 的域名了