说一说适合俱乐部的网站

在校读书的时候,我主要关注的是网络以及Web应用方面。毕业前没能做好微软俱乐部的网站是我的遗憾。这些想法其实在学校的时候就有考虑,现在作为十周年的征文写下来,算是一种补偿。

作为一个偏向于软件开发的学生社团,什么样的网站是我们需要的?这个问题可能每个人都有自己的想法。我的观点是:高效的内部协作、友善的对外展示。这里我以产品的形式逐一介绍。

1. Wiki

Wiki是一种面向社区的、开放的协同写作方式,每个人都可以根据自己的理解去编辑某一个词条。Wiki非常适合用来书写诸如办事指南、开发工具介绍、技术追踪等等可以被当作“常识”一类的东西,也就是知识库。理想的知识库可以找到办每一件事情的方法指南。

或许会有人担心,由于每个人都有独立的见解,共同编辑会让条目变得凌乱不堪。这个问题有两点来共同保障。第一,所有的编辑记录都会被完整的保存,也就是说只要大家愿意,文章可以轻易回朔到之前的任意版本,这是技术方式。第二,就是鼓励大家尽量以客观的语言去描述,尽可能脱离主观色彩,这其实也是一种信任,相信Wiki在大多数人的共同维护下可以自发、稳定、健康的发展。

推荐程序:MediaWiki

运行环境:PHP+MySQL

2. Blog

刚刚提到写Wiki的时候要尽可能脱离主观色彩,那么自我观点的展示放在哪里呢?答案就是Blog。很难想象在一篇没有署名的文章中出现“我认为”一词到底有什么含义。而Blog就不同。这是一个完全属于个人的空间,在这里,你需要做的只有一件事:好好的整理你的思绪,将你的见闻、感悟分享给你的读者。

我们应该敬佩那些认真并且坚持书写Blog的同学。无论是针对某一现象的思考,还是认真记录技术学习的点滴,甚至是把自己遇到的困难完整的通过文字记载下来,这些其实都是向读者传递一些非常有用的信息。Blog一定要设置为允许留言,这样你才能在Blog里接收到读者的反馈,才能促使自己向着更好的方向发展。

顺便提一句,Blog留言也是很有讲究的。如果真的想留下自己的见解,请一定不要吝惜笔墨。任何人在没有能领悟你的意思前,都有可能把这些话当作含有负面情绪的文字。

推荐程序:WordPress

运行环境:PHP+MySQL

3. 源代码管理器

说了两个关于如何整理知识的,该开始讨论如何帮助我们开展业务的了。

可能很多新人在面对团队开发的时候都想知道怎样将两个人工作的代码合并到一起。最直接的方法是:拿U盘拷来拷去。如果事情真的这么简单,我也愿意这么干。可是如果有一天你突然发现,以前删除的那些代码还是需要使用的,或者合并的时候不知道该以哪个版本为基准。

作为程序员,我们怎能这样机械?是的,我们需要更好的解决办法,那就是使用版本控制工具,来管理源代码。

版本控制工具的实现原理差不多是这个样子。

在服务器中,存放有一套源代码;而在每个开发人员的计算机上,也存放有一套源代码。我们称前者为代码仓库,后者为工作目录。

每一次编辑代码的时候,请严格遵循这样的步骤:先从服务器下载或者同步源代码,然后开始编辑,编辑完成再将代码上传到服务器上,这样你的代码就可以被别人获取到。这里我使用的是下载、上传这样移动的词语,其实准确的词汇会随着不同的版本控制工具略有不同。在Subversion中,第一次的下载叫做签出(Check Out),此后的下载叫做更新(Update),而上传则叫做提交(Commit),相信很好理解。

版本控制工具是个很神奇的家伙,它从来只做加法。也就是说,每次提交会创建一个新的版本,新版本号会在原有版本上增加1。而以前的版本依旧保存在服务器上,只是由于更新的时候默认获取当前代码仓库里最新的版本。和Wiki一样,我们不用刻意去保存任何的历史版本,哪怕有人在本地执行了删除的操作并提交给代码仓库,仓库会记录下这个版本,但是不会覆盖以前的内容。我们随时都可以去查阅以往的资料。

再确保了安全性后,我们再来看看代码仓库是如何实现协作的。

假设一个场景,当前服务器上最新的代码版本号是12。开始工作的时候,A和B都会更新各自的本地代码。OK, it’s CODING time now。A完成任务,将自己的代码提交给代码仓库,代码仓库会接收这些变更,版本号变更为13,同时A本地的代码版本号也会变更到13。当B完成工作打算提交给代码仓库的时候,问题就出现了,一般将这种问题称之为冲突。服务器上的版本号是13,而B本地代码是基于版本12修改的。如果直接覆盖,那么A变动的部分就会从最新版本中“消失”。请记住,这里有一个额外的操作叫做合并。目前有这样的工具,可以帮你完成自动合并,只有极少数情况下,需要手动介入合并过程。合并完成后,服务器会允许B提交他的变更,并且版本号会增加为14。

简单吧,团队协作编码三步曲:更新 – 检查冲突 – 提交。

在罗嗦一下,我使用的小标题是“源代码管理器”,这是一个不严谨的说法。准确的讲,是版本控制,源代码只是版本控制中的一部分。

以下的这些文件是需要纳入版本控制的:

  • 源代码
  • 第三方构件库
  • 项目文档(开发计划、需求说明、设计书)
  • 脚本(数据库生成脚本、编译脚本、自动化测试脚本)
  • 项目的配置文件

以下这些最好不要纳入版本控制:

  • 开发工具的配置文件
  • 编译生成的二进制文件(.exe、dll之类)
  • 数据库文件(.mdf之类)

推荐书目:《版本控制之道》

推荐程序:VisualSVN Server

运行环境:Win 32bit/64bit

4. 持续集成

紧接着版本控制。我们怎样知道提交给仓库的代码是可以正常运行的?每次提交前在本地编译通过,当然可以保证自己项目的正常。但通常的情况都是,大项目都由n多子项目构成,每个团队只负责一个或几个子项目。但是自己的代码提交上去,对整个项目有什么影响就不得而知了。以Windows开发为例,你总不至于每次提交后就在本机完整编译一次Windows吧?估计那时候 Intel i7 的 CPU 已经作古了。

开个玩笑,只是为了引出持续集成这个环境。持续集成工具可以自动的从代码仓库中取出最新的代码编译,将编译出的二进制包以及编译过程中输出的警告、错误都放到网站上。如果愿意,你也可以设置,让它将编译结果汇总,以邮件的形式发送给项目团队或者感兴趣的朋友们。

如果大家使用了自动化测试,那么还有更多。持续集成会自动的跑一遍脚本,将为通过的测试用例一同输出。纪炜和我曾经很好奇,微软水房旁边的每日Bug曲线是怎么统计的。原理就是这样,但是中间有很多与软件工程相关的理论,在这里就不多说,换个时间探讨下。

推荐程序:CruiseControl.NET

运行环境:IIS/.NET

5. 门户

放到这里才说这个门户不是因为不重要,而是因为太重要。门户可以放非常多的信息,包括Blog的聚合内容、Wiki的推荐词条、版本控制工具里最活跃的项目进展情况。这只是一种思路。记得将门户设计得简洁、友好,突出最重要的内容。参与过BMY进站设计的同学应该很容易理解这一点。

推荐程序:(自写)

6. 搜索引擎

这个不是很重要,但是随着Wiki和Blog页面的增加,保证有效的信息获取方式是比不可少的。一种解决方案是安装WordPress和MediaWiki的插件,直接索引数据库;另一种解决方案就是使用爬虫去抓取,然后索引页面,做一些类似于Google/Baidu之类的事情。

推荐程序:Nutch+Lucene

运行环境:Java

7. 身份验证

说了很多应用,都没有提到用户注册的模块。不觉得每个网站注册一个很麻烦?而且,直接应用这些网站,不觉得太没挑战性了?这个不展开描述,举几个例子大家就懂:

  • 通过校园网关(http://cas.xjtu.edu.cn)登录邮箱、教务处等等校园系统
  • 通过Google账户,不仅可以访问Gmail、GTalk、Google Docs等等Google自己的服务外,还能访问其他站点,例如stackoverflow.com

我们自己的身份验证就不用那么考虑这么细致了。最核心的部分我建议有三点:

  • 使用Active Directory存放用户信息,而不是通过SQL Server数据库;
  • 基于HTTP Basic方式验证用户信息;
  • 方便关联到@xjtu.mstechclub.cn邮箱

其中,第三点是锦上添花的成分,什么意思呢?例如,俱乐部成员有一个账号,在我们自己的网站上提交@xjtu.mstechclub.cn邮箱的申请,网站管理员可以点击批准直接创建邮箱,而不用每次通过剑雄或者其他人员登录到outlook.com手工填写。

推荐程序:(自己写)

8. 论坛

这其实是我最不建议引入的产品。论坛的定位在于讨论,初衷是好的。但是论坛的实效性有待商榷。谁都不愿意看到论坛里提一堆的问题没人理,或者认真的帖子下面一堆灌水的。国内做好论坛不容易。严格意义上来说,这些帖子都属于带有负面情绪的,因为你没有向大家传达最有效的信息。我的更建议大家采纳Wiki+Blog的形式。在自己的Blog里描述问题、记录解决步骤并将结果整理到Wiki中,成为可以被别人引用的文字,是不是更有价值?

推荐程序:(不推荐)

结语

好了,就是以上这些。一个一个的去实现很有压力,也会很有成就感。希望能参与到其中的一些项目中。

本文谨献给西安交通大学微软俱乐部。祝俱乐部十岁生日快乐!

《说一说适合俱乐部的网站》有1个想法

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>