群件很强大也很重要。如果需要，可以购买一个群件系统。或者可能是一个集群 —— 有一个使用了 RAID 的专用的数据库服务器，以及磁带备份的保证，还有单独的机器来运行界面。为什么？当然是因为它更可靠，而且可以根据负载扩展！
不过，您可能不会处理非常多的调度任务，以至于需要使用消耗大量内存的应用程序。可能只是需要某种基于 Web 的日程表界面，以及核查需要做的项目的能力。
可能并不需要 30 兆字节大小的类库、由一组本体专家（ontologists）来设计对象模型，或者依赖 15 个其他软件包。这里是我的目标：尽可能只使用系统附带的功能来运行那些应用程序。
业务的第一个步骤
首先，需要确保老机器可以运行某个 Web 服务器和某些 CGI 脚本。方便的是，我们的机器已经拥有了一个 Web 服务器，其根位于 /var/www/htdocs.检查配置文件（/etc/apache/httpd.conf），可以发现默认把 ExecCGI 和 Includes 都关闭了 —— 不过我想把它们打开，让我的 Web 页面华丽而生动。
之后的 Options 那一行是相关的设置。我添加了 ExecCGI 和 Includes 选项。如果没有服务器端解析的文件的支持，Includes 不会做什么事情；在 httpd.conf 中有一些注释掉的行将完成此任务。我去掉了这三行的注释（但仍让那些真正的注释保持被注释）：
[...] AddHandler cgi-script .cgi # # To use server-parsed HTML files # AddType text/html .shtml AddHandler server-parsed .shtml [...] |
完成后，执行 apachectl restart，让 Apache 重新加载其配置文件。为节约以 root 身份登录的时间，可以将 /var/www/htdocs 的所有者设置为您的个人帐号。我这样做了，而且还删除了在线手册和默认的索引页。
在计算机科学中有一句谚语，“百分之十的工作可以解决百分之九十的问题”。就此想法，我为这个应用程序制作了一个首页草稿，囊括了这个程序预期的主要工作：
Yo! Do the dishes. |
现在只需要测试 CGI 处理。我的测试叫做 env.cgi，并不大，但是很实用：
#!/usr/bin/perl -w
use Env;
use CGI;
print "Content-Type: text/plainnn";
foreach $k (sort keys %ENV) {
print "$k: $ENVn";
}
exit 0; |
您会注意到，我实际上并没有使用 CGI 模块；之所以引用它，是为了确保它已经安装。将它放在适当的位置，我可以确认 CGI 脚本正在运行。我将机器在网络上命名为“crate”，所以，对 http://crate/env.cgi 的访问结果如我所想：
[...] REMOTE_ADDR: 205.166.146.66 REMOTE_PORT: 62594 REQUEST_METHOD: GET REQUEST_URI: /env.cgi SCRIPT_FILENAME: /var/www/htdocs/env.cgi SCRIPT_NAME: /env.cgi SERVER_ADDR: 205.166.146.93 SERVER_ADMIN: root@midas.slackware.lan SERVER_NAME: crate.plethora.net SERVER_PORT: 80 SERVER_PROTOCOL: HTTP/1.1 |
那非常有利于调试 —— 它发现我那部分有一个错误。我忘记去修改 httpd.conf 中的 ServerAdmin 行了。很容易修改。您的用户名不存在。请走开。
安全性是早期出现的问题之一。您不会希望让所有人都可以留下关于午餐所有者的危险记录。进入访问控制。
这需要对 httpd.conf 进行更多修改，允许 .htaccess 文件限制对站点的访问。那表示要向允许访问列表中添加“Limit AuthConfig”，覆盖顶层配置文件。
接下来需要一个 .htaccess 文件。从这里开始：
AuthUserFile /var/www/htpasswd AuthGroupFile /dev/null AuthName "Roommates Only" AuthType Basic require valid-user |
htpasswd 文件并不是以普通形式存在于文档树中。那样做是有目的的；不能为攻击者创造有利条件。可以使用 htpasswd 命令初始化 htpasswd 文件：
# htpasswd -c ./htpasswd seebs New password: Re-type new password: Adding password for user seebs |
-c 选项让 htpasswd 创建一个新文件。当创建另外的用户时不要使用它；否则，只有最新的用户才能够登录。完成后，尝试访问页面将会要求输入口令。给出用户名和密码，然后就能进入了。 $REMOTE_USER 将被设置为用户名，以使得脚本可以知道谁在使用它们。
我不喜欢漫长的告别
于是，您可以登录进入。不能登录出去 —— 出于未知的原因，多数浏览器通常不允许刷新所请求的用户名/口令组合的内存。可以刷新 cookies，可以刷新缓存 —— 但是浏览器可能仍然认为它知道您要做什么。
所以，如果登录到公用的计算机，那么在离开之前一定要关闭整个浏览器。否则，人们可能碰巧会看到您的家务杂事列表，而不是他们自己的，这样就会出笑话了。如果这确实是个问题，那么可使用 cookies.
尽管如此，这使得系统允许用户使用他们自己的用户名登录，对于让用户添加记录来说就足够了。只要有添加记录的途径！
室友记录
实现此目标的基本概念很简单：公开地张贴有时间标记的消息，用户可以读取。 Berkeley msgs 工具刚好是所需的复杂程度（也就是说，几乎根本就不难）。每个文件将包含一个名称、一个时间标记以及一些文本。系统将向用户显示特定时间段的消息，或者将用户最后一次访问之后张贴的消息显示给他们。
要读取的消息的数目应该暂时不重要，所以我将使用最简单的所有文件格式：目录中的全部文件，每个文件中，第一行是一个时间标记和一个用户名，然后是一些文本。这甚至不需要为文件准备数据库；文件系统的灵活性就足够了。（您可能会问我为什么不直接使用文件系统中的时间标记；答案是我并不相信它，因为粗心的用户会破坏它。我的很多目录中所有的文件都拥有相同的时间标记。）我确实需要某种类型的数据库，用于用户以及他们的最近的时间标记，所以每个用户都将拥有一个数据文件，现在其中包含有一个时间标记。
整个项目很小，只使用一个 CGI 脚本就可以借助 Perl 的标准 CGI 模块来实现。目标是折衷所需附加代码（尽可能少）以及所需开发时间（尽可能短）。在本例中，系统所附带的功能是足够的。
/var/www/msgs 是一个新目录，用于保存消息（以数字命名的文件）和用户记录（使用 .htaccess 文件中给出的用户名作为文件名）。CGI 脚本会识别自身，执行被请求的动作，并展现出相当简单的界面；它所需要的只是一些按钮和一个文本区域。 为了表示尊敬，这个脚本命名为 msgs.cgi.
开发过程中涉及了一些设计方面的考虑。
甚至不需要去解析日期，因为在大部分情况下可以简单地让用户使用按钮（最近 24 小时、上一周、自上一次访问，以及所有消息）。
以数字为名称的文件可以简单地由内置的 glob 来识别，它能够方便地整理文件。不过，如果数字的位数发生了变化，整理就会发生错误，所以要给出前导的零。脚本并没有精心地去分辨主题，而只是为每条消息的第一行使用了 H3 标签。程序假定输入消息的全部 HTML 都是没有恶意的。如果室友没有足够的幽默感，那么用户在写入时应该仔细检查。
这个脚本非常短小，只有 2K 多一点。不过，它也有潜在的开销，因为 CGI 库实际上很大。但是相对于更大的系统，它还是非常小的，而且它提供了一个适当的途径让用户张贴消息并让其他人方便地进行查看。
谁知道 Sam 去哪儿了？
偶尔室友的问题会是他们到底去哪里了。我并不是要讨论，当要付房租或者分担公共费用时，某些人却不得不离开房间 —— 而只是说某个人，比如一个朋友，打电话过来问“您知道他在哪儿吗？”或者“您知道他什么时候回来吗？”
要说有什么不同之处，那么就是这个脚本更短小，写起来更简单。遵循相同的基本方法：只需要创建名字为用户名的文件，其中包含有时间标记、可能要离开多少小时以及简短描述。然后，每找到这样一个文件，打印一个简要描述。
“I'm back！”按钮会删除那个文件，因为可能人们并不需要知道您曾经 在哪儿（如果有意外，这有助于证明您不是帮凶）。与之相对照，能知道某人曾经要去哪里是 有用的，所以文件不会因为变成老文件而被删掉。
我觉得一个好的、简单的群组日程安排软件非常类似于 Harry Potter 丛书中 Weasley 的起居室里的那个时钟。它有九个黄金指针，每个上面刻有一个家庭成员的名字。边缘上没有数字，而是标记为位置和状态 —— 家、工作、学校、旅行、走失、致命危险，等等。（还有一个厨房时钟，它有一个指针以及“time for this”和“you're late”标记。）
日程计划任务
所需要的最后一件事情是日程计划。我们如何处理家务事的常规提示？轮到谁来洗衣服？轮到谁来涮碗？不需费力就可以定期地安排这些任务。
处理垃圾可能对每个人来说都是琐碎的工作，但是我们所需要的只是张贴公开提示的某种方法。现在您应该对此有了一些想法。当然是使用另外一个脚本以及它自己的自定义数据库文件。
只是目前还不需要它。这个项目的难点在于调度任务。要编写能够表达类似于“every Thursday is trash night”或“someone needs to do the dishes every night”等想法的代码一点都不简单。
不过这些代码已经编写好了，叫做 cron.我们所需要的只是公布消息的某种途径。可以知道，为本月项目的第一部分已经编写的消息程序，可以正确地满足我们的要求。为消息目录赋与写权限（例如，root 有令人羡慕的特权），尝试这个命令：
$ REMOTE_USER=bob /var/www/htdocs/msgs.cgi "action=Post Message" "message=Test message" |
现在，去查看那些消息。很酷，不是吗？ 已经能够通过运行命令添加新消息，也就是说 cron（可以根据日程安排运行命令）满足了我们全部的需求。
有一个小型的 Web 界面来创建这些任务可能会更好，但是由于这些东西很少修改，所以可能并不需要。这将处理所有需要常规提示的任务。不需要常规提示的任务可以手工输入，或者使用 at（1） 设置为在适当的时候输入。
总结与说明
本月支出为 ，这非常好。没有进行任何下载，只是要在本地进行一些输入。应用程序有一些简单，但是它们能完成应该做的事情，而且代价低廉。
进一步讲，它们足够简单，能方便地更新。最大的弱点是安全性；没有投入任何精力来保护这些程序不受最常见入侵的危害。其中一方面原因是，在大部分情况下那不是个大问题。
不过，如果您计划与懂技术的室友一起使用这些，那么有很多种方法可以让程序更加安全。例如，如果不允许通过命令行运行 msgs.cgi 脚本，那么需要考虑使用另外的方法来调度任务。（实际上有一个非常简单的方法，就是使用命令行浏览器以及精心构造的 URL，这些留给读者去练习）。
古老的机器 的下一篇文章：使用 Web 页开灯。可用的 x10 硬件和 Linux 驱动程序使得我们能够完成所有那些有用的事情，比如在起床前半小时打开咖啡壶（coffee maker）。
