open party(2010 05-15)-蒋鑫-开源软件定制开发中的软件工程

北京群英汇信息技术有限公司北京群英汇信息技术有限公司http://www.ossxp.com

2005-2010

版本号 :

开源软件定制中的软件工程

Hacking CoSign...

0.1-5

蒋鑫

http://www.ossxp.com

北京群英汇信息技术有限公司 Project Management inspired by open source practice —— Hacking CoSign 2

北京群英汇信息技术有限公司

我们是开源软件的产品和服务提供商

看出 LOGO 的奥秘？奔跑的　角马　 — 开源软件生生不息的脚步；

整体的　邮戳　 — 品质的保证，服务快捷、方便；

“汇”字的两层含义：“汇聚”— 群英汇聚之地；

“汇递”— 开源软件汇递八方；


北京群英汇信息技术有限公司 Project Management inspired by open source practice —— Hacking CoSign

3

开源启示——个人

程序员的需求：新技术，技巧，好的习惯，好的工作

研究开源软件，与技术高手为伍

参与开源软件，在软件过程的实践中养成习惯

立即行动

使用开源软件

参与开源社区：报告问题 , 参与讨论

贡献翻译 , 文档和代码

创立开源项目



4

开源启示——企业 / 组织

企业的需求：低成本，高效工作流，质量高

企业的开源经济模式

嵌入式开发

非核心业务开源： NVIDIA ， IBM eclipse

开源软件整合： Redhat

定制和支持：群英汇 @ossxp.com

其他获益方式

使用开源软件，采购开源软件服务

借鉴开源项目的管理模式



5

开源软件打造——群英汇研发协同管理平台

1 2

11010111011010110100110001101111010101011100100010001101010101011010100101010101101110101010100101010101010101010010101001010100010101010110000000

101010101100001001011

4 56

7 1.知识管理

2.沟通系统

3.搜索引擎

4.版本控制

5.测试管理

6.持续集成

7.缺陷跟踪

8.集中管理

3



6

开源藏宝图

ProjectMgmt _,-> (Redmine) <-._ * Redmine * CoSign _/ \_ Trac _/ \_ Mantis VCS CI TestMgmt (SVN,pySvnMager -> (CruiseControl) -> (Testlink) * Subversion * GOsa Git ...) pySvnManager Git (topgit,gitosis) o o \ o / o o /|\ /|\ | /|\ /|\ * Testlink * CruiseControl / \ / \ / \ / \ / \ +----------------------------------------------------+ * MoinMoin * Nutch | Search Engine | MediaWiki Lucene +----------------------------------------------------+ | Knowledge Base Communication | * WordPress | (Moin+WordPress) (Mailman+IM?) | Typo +----------------------------------------------------+ | UserMgmt + Single Signon | * Mailman +----------------------------------------------------+ phpBB SMF



开源软件定制的软件工程学

需求管理

需求管理

版版本本控控制制

缺陷跟踪

缺陷跟踪

代码评审代码评审

持持续续集集成成

文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



目录

需求管理

需求管理


缺陷跟踪

缺陷跟踪



文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



9

认识一下 CoSign

单点登录平台



10

认识一下 CoSign

登录成功，显示服务列表



11

CoSign 的组成

APPS --> Filter (IIS)------+APPS --> Filter (Java)-----+APPS --> Filter (Apache)---+

./ |

./ |

./ V

login ---+ / +--> Daemon (tcp/6663)

|--> CGI --|

logout --+ +--> Factors -> AuthSource(DB, LDAP)



12

CoSign 的原理

参见

CoSign 2.x 协议介绍

http://blog.ossxp.com/2010/03/824/

CoSign 3.x 介绍及与 CoSign 2.x 的协议比较








目录

需求管理

需求管理


缺陷跟踪

缺陷跟踪



文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



14

定制的需求

不说中国话，以及改说中国话的问题



15

定制的需求 ( 续 )

需要增加邀请码认证

需要客户 / 亲朋无须注册即可访问

增加邮件地址登录

既可以用 ID 登录，也可以邮件地址登录

双因子认证

来自于 OpenSesame 的需求

请求认证因子的或运算

来自于邮件列表审核的授权需求

其它痒痒的小问题

认证因子的本地化

登录对话框无关认证方式的隐藏



16

需求管理

使用项目管理工具来记录需求



17

需求管理要点

需求以功能的方式建立

设置里程碑，让团队看到目标

每个功能都归属于某个里程碑

一个里程碑不要包含太多功能。

快速迭代：小步快跑

程序员开发，提交说明要引用

到需求编号

See #123: 实现 xxx 的部分功

能 ...

Fixes #123: 完成 xxx 功能的

全部实现 ...



18

需求管理要点 ( 续 )

甘特图：为功能需求设定预期的开发时间



需求的变更历史



20

看看 CoSign最终的实现

需要增加邀请码认证

只需知道邀请码，如 test123增加邮件地址登录

如 [email protected]双因子认证

其它应用自动登录：如 wiki访问 : https://weblogin.moon.ossxp.com/opensesame/

请求认证因子的或运算

邮件列表审核授权：http://list.moon.ossxp.com/mailman/admindb/dev

实现过程大揭密

即将拉开大幕 ...

http://www.moon.ossxp.com/bj/action/login/Main?action=login&login=1

https://weblogin.moon.ossxp.com/opensesame/

http://list.moon.ossxp.com/mailman/admindb/dev



目录

需求管理

需求管理


缺陷跟踪

缺陷跟踪



文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



22

Let's hack...

在部署路径中，直接修改页面模板

hacking...

如何保存部署目录的现场修改？

使用版本控制系统

Hg, Git 等最适合用做 on the spot 版本控制

修改导出为 patch 文件

现场修改不等于定制开发

现场修改是不完整的代码修改

现场修改是临时性修改，会被新的部署覆盖



目录

需求管理

需求管理


缺陷跟踪

缺陷跟踪



文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



24

自有项目开发和二次开发区别

开发模式的区别，导致版本控制上的区别



25

定制开发中的版本控制

使用 Subversion 的卖主分支管理定制开发

X 合并冲突（所有的 hack混杂在一起的合并，痛苦有谁知？）

|

58 O 导入上游新版本 v3.x AMD /branches/upstream/* |57 O hack 55: M /trunk/src/zzz | ... | 4 O hack 02: A /trunk/include/bbb | 3 O hack 01: M /trunk/src/aaa |

2 O 建立卖主分支 cp /trunk /branches/upstream |

1 O 导入上游版本 v2.x A /trunk/*



26

用 SVN这么实现可以么？

+--------------------O(v3.x)--------- upstream

/ \

---O(v2.x)..................\............. /trunk

\``\``\ \

\ \ +--O--------------X----------- hack1

\ +---O------O-+------O-X---------- hack2

+--O------O-----\------\-X--------- hack3

\ \ \

+--O---Y-X------- hack4

你可以一试

但是 SVN 分支合并的难度，以及分支依赖关系难以解决，补丁导出工具的缺乏，会让你放弃这个想法



27

Subversion 好坏说

优点：

基于路径的授权，适合企业应用在公司纷纷将代码开源的背景下，严格授权是否具有实际意义

代码评审，结对编程等实践，实际上源码已在公司内部开源

适合原生代码的版本控制

缺点：

不适合现场 hacking 的版本控制

受网络限制，分处异地团队的协同，以及移动办公受限

分支合并的成本高

不适合用做二次开发的版本控制



28

什么样的版本控制，是定制开发需要的呢？

每个 Hack拥有一个独立的分支

每个分支的产出是一个补丁文件

不需要所有 Hack都合并到一起的分支，因为徒增烦恼！

分支合并的成本高，不如补丁来得直接

补丁队列 (patch queue) 的管理

quilt 是最通用的补丁列表管理工具

quilt 的输入源码目录

补丁文件：每个补丁即为对源码的一个 hack补丁队列： series 文件，即补丁文件安装的先后次序

quilt 两种最主要的用法quilt pushquilt pop



29

Thank you, OpenSource

从来就不会只有唯一的包治百病的解决方案

每个解决方案都会在适于特定环境

选择开源，很多时候是在选型

换手机时，幸福的烦恼：太多的选择



30

Hg/MQ 为定制做版本控制：一人独享式

实际上是两个 Hg 库完成的版本控制

O'(patch2 cont.)

| \ series

O (patch2) \ + patch1

| +-- > patch2

O (patch1) - patch3

| - patch4

O (v2.x)

/ \

O O

|

O

版本库 1 版本库 2



31

Hg/MQ 的工作过程

初始状态

series

- patch1

- patch2

- patch3

- patch4

O (v2.x)

/ \

O O

|

O



32


$ hg qpush

series

> patch1

- patch2

O (patch1) - patch3

| - patch4

O (v2.x)

/ \

O O

|

O



33


$ hg qpush

series

O (patch2) + patch1

| > patch2

O (patch1) - patch3

| - patch4

O (v2.x)

/ \

O O

|

O



34


modify

O' modify... series

O (patch2) + patch1

| > patch2

O (patch1) - patch3

| - patch4

O (v2.x)

/ \

O O

|

O



35

$ hg qref

O' modify...-\__ series

O (patch2) \__ + patch1

| \--> patch2

O (patch1) - patch3

| - patch4

O (v2.x)

/ \

O O

|

O




36

$ hg qref

series

O'(patch2) + patch1

| > patch2'

O (patch1) - patch3

| - patch4

O (v2.x)

/ \

O O

|

O




38


$ hg qpop -a

series

- patch1

- patch2'

- patch3

- patch4

O (v2.x)

/ \

O O

|

O



39


$ hg pull upstream

series

- patch1

- patch2'

O (v3.x) - patch3

/ \ - patch4

O (v2.x)

/ \ \

O O O

| | \

O O O



40


$ hg qpush

series

O (patch1) > patch1

| - patch2'

O (v3.x) - patch3

/ \ - patch4

O (v2.x)

/ \ \

O O O

| | \

O O O



42

Hg/MQ 好坏说

优点

简单

Hg 的使用习惯和 SVN 接近

MQ库的工作区实际上就是 Quilt 补丁文件

与上游新版本的合并是非混杂模式，易实现

缺点

补丁之间依赖关系不清，难以独立发布

不适合团队协同开发

两个版本库，部署复杂

补丁的冲突！老天



43

群英汇用 Git + Topgit对定制进行版本控制

Topgit主要为 Git 提供了增强的和更加便捷的分支管理

+--------------------O(v3.x)--------- master

/ \

---O(v2.x) \

\``\``\ \

\ \ +--O--------------X----------- t/hack1

\ +---O------O-+------O-X--+------- t/hack2

+--O------O-----\--------X--\------ t/hack3

\ \

+--O--------Y---- t/hack4

附加的管理文件 : .topmsg, .topdeps

附加的管理分支 : top-bases/*



44

Git + Topgit 的好坏说

优点：

每个 hack 一个分支（功能分支）

显式的依赖关系：可通过 .topdeps 设置多个依赖缺省依赖master（当前工作分支）

便于独立的 hack（功能）补丁导出

适合团队协同开发

缺点：

Git具有独特的使用习惯， SVN 用户需要更多时间的学习



45

Git + Topgit 演示 (1)

查看 topgit 分支$ tg summary r t/auth_log_for_fail2ban [PATCH] t/auth_log_for_fail2ban

r t/autotools_for_setup [PATCH] t/autotools_for_setup

r t/bugfix_cosign_httponly_quirk [PATCH] t/bugfix_cosign_httponly_quirk

r t/bugfix_no_retry_report [PATCH] t/bugfix_no_retry_report

r t/custom_cosign_path [PATCH] t/custom_cosign_path

r t/factor_admin [PATCH] t/factor_admin

r t/factor_invite [PATCH] t/factor_invite

r t/factor_ldap [PATCH] t/factor_ldap

r t/include_macro_for_templates [PATCH] t/include_macro_for_templates

r t/javascript [PATCH] t/javascript

r t/message_localize [PATCH] t/message_localize

r t/message_translation [PATCH] t/message_translation

r t/multi_language [PATCH] t/multi_language

r t/new_factor_with_flag_3 [PATCH] t/new_factor_with_flag_3

r t/real_remote_user [PATCH] t/real_remote_user

r t/services_template [PATCH] t/services_template

r t/static_htmls_to_templates [PATCH] t/static_htmls_to_templates

...



46


将某个分支所有改动显示为补丁$ git co t/unittestSwitched to branch 't/unittest'$ tg patchFrom: Jiang <[email protected]>Subject: [PATCH] t/unittest

Unit test framework.

Signed-off-by: Jiang <[email protected]>

--- Makefile.in | 6 +- cgi/lang.c | 31 ++++- cgi/lang.h | 2 + cgi/subfile.c | 14 ++- tests/Makefile | 112 +++++++++++++++++++ tests/check_lang.c | 296 +++++++++++++++++++++++++++++++++++++++++++++++++ tests/check_subfile.c | 128 +++++++++++++++++++++ 7 files changed, 578 insertions(+), 11 deletions(-)

diff --git a/Makefile.in b/Makefile.in...



47


导出全部功能分支为 Quilt补丁队列$ tg export --all --quilt patchesExporting t/auth_log_for_fail2banExporting t/autotools_for_setupExporting t/bugfix_cosign_httponly_quirkExporting t/bugfix_no_retry_reportExporting t/custom_cosign_pathExporting t/factor_adminExporting t/factor_inviteExporting t/factor_ldapExporting t/multi_languageExporting t/include_macro_for_templatesExporting t/javascriptExporting t/message_localize...$ ls -1R patches/patches/:seriest

patches/t:auth_log_for_fail2ban.diffautotools_for_setup.diff...



目录

需求管理

需求管理


缺陷跟踪

缺陷跟踪



文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



Bug迟早来相见

最近发现的一个 Bug (#165) ，记录在缺陷跟踪系统中

重现方法：

登录后，更换 IP 地址

访问单点登录界面

提示重新认证

点击切换用户

显示空白页面(段错误 )



Debug 过程好辛苦



代码改动却一点点



目录

需求管理

需求管理


缺陷跟踪

缺陷跟踪



文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



假如之前就实施代码评审 / 代码复查？

针对代码提交建立评审任务



代码评审发现错误



结对编程是更好的复查？

结对编程来自敏捷软件方法的 XP

代码复查是“小鸡”，结对编程是“猪”

投入不同，产出必然不同

事不关己，高高挂起：代码复查很容易流于形式

结对的代码质量是最高的，评审是实时在进行

如何选择？

工作在同一个地点，选择结对

开发者分处异地，选择代码复查

如：大多数开源项目



目录

需求管理

需求管理


缺陷跟踪

缺陷跟踪



文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



57

预分配字串数组

获取环境变量 HTTP_ACCEPT_LANGUAGES

字串数组动态扩增

填充至字串数组

字串规范化处理分割结束？

以逗号分割

是

否

返回字串数组

char **get_accept_language()

没有单元测试的教训

Bug！浏览器语种支持的数量若达到某个值，可能导致异常。

gdb调试，发现问题出现在新增的 get_accept_language函数

calloc(sizeof(char*),SIZE+1) getenv( "HTTP_ACCEPT_LANGUAGE" ) eg: zh,zh-cn;q=0.8,en;q=0.5,zh-sg;q=0.3

realloc(...)



58

编写测试代码（非 xUnit框架） # 1

代码中使用 _DEBUG宏，进行条件编译

getenv被桩函数mygetenv替换

从数组而非环境变量获取浏览器支持语种

参见分支 t/multi_language 中 cgi/lang.c代码#ifdef _DEBUG

#define getenv mygetenv

char *my_lang_buff[] = {

"zz",

"it,en_us,en,zh-sg,zh,zh-sg,zh-cn,zh,zh-tw,ar,it,zr1,zr2,zr3,zr4",

... };

char *mygetenv( char *ignore) {

static int loop = -1;

int num = sizeof(my_lang_buff)/sizeof(*my_lang_buff);

return ++loop < num ? my_lang_buff[loop] : NULL;

}

#endif



59


条件编译的 main函数，执行测试#ifdef _DEBUG

int main()

{

char **lang, **orig;

while (lang = get_accept_language())

{

if (*lang == NULL)

break;

orig = lang;

while (*(lang++) != NULL);

printf ("num: %d. ", lang - orig -1);

lang = orig;

while (*lang != NULL) {

printf("%s,", *lang);

lang++;

}

printf("\n");

}

}

#endif



60


Makefilelang: lang.c

gcc -g3 -D_DEBUG \

-D_LOCALEDIR=\"${LOCALEDIR}\" \

-D_TEMPLATE_LOCALEDIR=\"${COSIGNTMPLDIR}-local/locale\" \

-o $@ $^

在 t/message_localize分支下运行测试用例$ git co t/message_localize

$ cd cgi

$ make -f Makefile.in lang

$ ./lang



61


$ make -f Makefile.in lang

gcc -g3 -D_DEBUG \

-D_LOCALEDIR=\"@localedir@\" \

-D_TEMPLATE_LOCALEDIR=\"@prefix@/templates-local/locale\" \

-o lang lang.c

$ ./lang

num: 1. zz,

num: 1. zh,

...

Environment : zz.

locale : C.

Environment : zh.

locale : zh_CN.UTF-8.

Environment : zh-tw.

locale : zh_TW.UTF-8.

Environment : zh-sg.


...

Environment : it,zh-sg,en_us,en,zh,zh-sg,zh-cn,zh,zh-tw,ar,it.


...



62

为什么不使用 xUnit 单元测试框架呢？

带有个人风格的单元测试的缺点：

没有使用断言。测试用例通过与否，不易验证

不能自动化运行

不能在敏捷实践中推广，难以实现测试先行

解决方案：

采用单元测试框架 xUnit对于 C语言，选择 check 单元测试框架

check 单元测试用例框架特点

启动子进程运行测试用例，避免由于段错误导致测试用例运行无结果返回

使用宏定义单元测试用例

支持 autotools参见：http://blog.ossxp.com/2010/05/1211/




63

编写测试代码（ xUnit框架） # 1

代码重构，以便提高代码的可测试性

要撰写可测试性代码测试先行，能够确保代码的可测试性

可以避免过度使用桩函数

mygetenv 的替代

原来的一个函数char ** get_accept_language()

改用两个函数实现char ** get_accept_language()char ** _get_accept_language( char *env )

测试针对 _get_accept_language 函数直接通过参数赋值

不使用 getenv 获取环境变量



64


单元测试架构 (tests/check_lang.c)Suite *

ossxp_suite (void) {

Suite *s = suite_create ("Language");

TCase *tc_lang = tcase_create ("Lang");

tcase_add_test (tc_lang, test_lang_one);

tcase_add_test (tc_lang, test_lang_many);

suite_add_tcase (s, tc_lang);

return s;

}

int

main (void) {

int number_failed;

Suite *s = ossxp_suite ();

SRunner *sr = srunner_create (s);

srunner_run_all (sr, CK_NORMAL);

number_failed = srunner_ntests_failed (sr);

srunner_free (sr);

return (number_failed == 0) ? EXIT_SUCCESS : EXIT_FAILURE;

}



65


单元测试用例示例 (tests/check_lang.c)START_TEST (test_lang_many){ char **lang; char *env; int i = 0;

lang = _get_accept_language( "zz,zz ;q=3,zz ;q=2, zz ;q=1," ); fail_if ( get_lang_size(lang) != 1, "wrong size: %d", get_lang_size(lang));

lang = _get_accept_language( "l1;q=1,l2;q=2,l2,l3" ); fail_if ( get_lang_size(lang) != 3, "wrong size: %d", get_lang_size(lang));

lang = _get_accept_language( "l1;q=1,l2;q=2,l2,l3,l4" ); fail_if ( get_lang_size(lang) != 4, "wrong size: %d", get_lang_size(lang));

env = malloc(200*5+10); strcpy(env, "l0"); for (i=1; i< 200; i++) { sprintf(env, "%s,l%d", env, i); lang = _get_accept_language( env ); fail_if ( get_lang_size(lang) != i+1, "Lang %s.\nWrong size: %d != %d", env, get_lang_size(lang), i); }}END_TEST



66

运行测试用例

$ cd tests

$ make

cc -c -o check_lang.o check_lang.c

cc -o check_lang check_lang.o ../cgi/lang.o -lcheck

cc -c -o check_subfile.o check_subfile.c

cc -o check_subfile check_subfile.o ../cgi/subfile.o ../cgi/lang.o -lcheck

$ make check

Running suite(s): Language

100%: Checks: 5, Failures: 0, Errors: 0

PASS: check_lang

Running suite(s): Subfile

100%: Checks: 2, Failures: 0, Errors: 0

PASS: check_subfile

==================

All 2 tests passed

==================



67

OVER?

辛苦写的单元测试仅供一个人把玩？

加入软件集成，即所为冒烟测试

Next...



目录

需求管理

需求管理


缺陷跟踪

缺陷跟踪



文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



69

持续集成

重复性劳动，交给机器去做

避免集成环境差异破坏产品

能够让拥有部分代码的提交者及时发现集成错误

测试用例在集成中自动运行

及时的反馈

交付构建给测试团队



70

持续集成：自动构建

代码变更的自动构建，或手动构建



71

持续集成：开发和测试的接口

构建结果，是开发的输出和测试的输入



72

持续集成：测试用例在集成时自动执行

单元测试失败，导致的集成失败



73

持续集成：测试用例在集成时自动执行

单元测试失败，导致的集成失败



目录

需求管理

需求管理


缺陷跟踪

缺陷跟踪



文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



75

测试过程管理

减少测试过程的随意性

编写测试用例

测试用例的维护

整个测试生命周期管理

测试计划

测试需求

测试用例

测试报告



76

测试用例维护

测试套件和测试用例：让测试过程可重复



77

测试报告

测试用例覆盖度



目录

需求管理

需求管理


缺陷跟踪

缺陷跟踪



文档文档

单元测试

单元测试

on the spot

on the spot

hacking

hacking

CoSignupstream

测试管理

测试管理



79

文档

关于文档的需求

需要哪些文档？用户手册和管理员手册

文档格式有几种？ HTML, PDF写可维护的文档？纯文本写文档，进行版本控制

文档的版本？版本要随着软件走

可行的文档方案reST : 《The Definitive Guide to Pylons》markdown: 《The Git Community Book》Docbook : 《Version Control with Subversion》

群英汇的方案

reST + 自行开发的 Docbones特色：

HTML 输出增加灯箱效果

HTML 输出的样式表定制

PDF 输出的中文和格式规范化



80

文档源码（ Docbones 管理的 Rakefile）

doc/user-guide/Rakefile

require 'docbones'

source_suffix = '.rst'

::Docbones.setup source_suffix

PROJ.root= "."

PROJ.name = "user-guide"

PROJ.index = "user-guide"

PROJ.output = "../output/user-guide"

PROJ.css_path = "/stylesheet/lightbox/nf.lightbox.css,/stylesheet/ossxp/doc.css"

PROJ.js_path = "/javascript/jquery/1.4.2.js,/javascript/lightbox/nf.lightbox.js,/javascript/lightbox/load-nf.lightbox.js"

PROJ.pdf_style = "style/ossxp.style"

task:default



81

文档源码（文本式的 WYSIWYG）

doc/user-guide/user-guide.rst

================单点登录用户手册================

:作者 : 北京群英汇信息技术有限公司

:网址 : http://www.ossxp.com/:版本 : 3.1.1-1:日期 : |date|:版权信息 : Creative Commons

.. contents:: 目录

.. sectnum::

.. header:: 单点登录用户手册

.. footer:: 北京群英汇信息技术有限公司

.. |date| date:: %Y-%m-%d %H:%M

访问单点登录系统================单点登录即 Single Sign-On，多个 web 应用仅需登录一次，是群英汇众多 web 应用的唯一登录入口。

...



82

编译后的文档

HTML 文档的 CSS样式



83

编译后的文档

图片放大——灯箱效果



84

个人文档习惯

你是如何记笔记的？

blog ？ wiki ？ mindmap?

FreeMind-MMX

freemind.sf.net

freemind-mmx.sf.net

http://freemind-mmx.sourceforge.net/



85

参考及版权说明

我们对 CoSign 的改进，参见我们提交到Github上的代码库

http://github.com/ossxp-com/cosign-ossxp-hacks

您可以 ...可以任意散发本文档，但必须保持本文档的完整性

可以下载我们改进的 CoSign可以在您的公司 /团队部署我们改进的 CoSign可以向我们报告 Bug可以向我们提出需求

可以向我们购买开源软件部署和技术支持等服务

您不可以 ...不可以破坏开源软件的版权和游戏规则

不可以 steal 我们的劳动成果

http://github.com/ossxp-com/cosign-ossxp-hacks



86

联系我们

马上联系我们马上联系我们

北京群英汇信息技术有限公司

网址： http://www.ossxp.com/

Email: [email protected]

　　　 [email protected]

电话 : 010-51262007

　　　 13801210969



87

open party(2010 05-15)-蒋鑫-开源软件定制开发中的软件工程

Technology