concrete5

こんな要件を満たすために、CMSツールを探してました。
・CMSサイトそのものは、自分が構築する
・しかしCMSサイトの記事を投稿するのは別の人（つまり管理者じゃない人）
・別の人は、あまりＩＴには詳しくない若者（もっといえば、現役の高校生）
・記事の公開には、別途責任者（＝顧問の先生）の許可が必要

検討したのは次のCMS
・SOY CMS
・Movable Type
・Wordpress
・concrete5

SOY CMSは、自分で運営するには構成がシンプル（特にテンプレートがほぼHTMLなところ）が気に入っているのですが、実際にメンテナンスする人にもそれなりの知識が必要そうなのでNG。
Movable Typeは、個人が情報を発信する以外のときはお金がかかりそうなのでNG。
Wordpressは、「CMSで使うこともできますよ」と謳うわりにはそれ用のテンプレートがなく、ずいぶんと構築に手間がかかりそうなのでNG。

というわけでconcrete5がなかなかよさそうなので、採用となりました。良い点としては
・WYSISWYGな編集画面があること→素人にはとっつきやすい。
・CMSの約束事が少ないこと→イコール共通化に関する機能が少ないということですが、そこが却ってよい。
・記事の公開に承認プロセスが踏めること→必須機能なので。

しかし感じたのは、どのツールも導入がかなり考えられているということ。導入がとっつきにくいものは、やはりデファクトスタンダードや大きなシェアを占めるのは難しいということなのでしょう。どのツールも大体５～１０個の質問に答えるだけで、最初のサイトが構築できます。これは見習うべきところでしょう。

ちなみに作ったページは、これになる予定です。
http://www.ostmeerphilharmoniker.com/tokai/

さくらの専用サーバー

若手を集めて「技術部」を作ろうと思う。いわゆる部活動だ。
その本気度を示すために、まずは自腹で専用サーバーを契約してみた。
OpenVZやXenなどで仮想化などをやってみたい。
オリジナルサービスとか作って公開して、友達に自慢してみたい。

そんなこんなが月々7,800円なら安いもんだ。

centos5.3でmysqld起動時にyumが実行できない

mysqldが起動中にyumを実行すると、次のエラーが出てきます。

[root@lunch /]# yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in ?
yummain.user_main(sys.argv[1:], exit_code=True)
File "/usr/share/yum-cli/yummain.py", line 229, in user_main
errcode = main(args)
File "/usr/share/yum-cli/yummain.py", line 104, in main
result, resultmsgs = base.doCommands()
File "/usr/share/yum-cli/cli.py", line 339, in doCommands
self._getTs(needTsRemove)
File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 101, in _getTs
self._getTsInfo(remove_only)
File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 112, in _getTsInfo
pkgSack = self.pkgSack
File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 591, in
pkgSack = property(fget=lambda self: self._getSacks(),
File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 434, in _getSacks
self.repos.populateSack(which=repos)
File "/usr/lib/python2.4/site-packages/yum/repos.py", line 223, in populateSack
self.doSetup()
File "/usr/lib/python2.4/site-packages/yum/repos.py", line 71, in doSetup
self.ayum.plugins.run('postreposetup')
File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 176, in run
func(conduitcls(self, self.base, conf, **kwargs))
File "/usr/lib/yum-plugins/fastestmirror.py", line 181, in postreposetup_hook
all_urls = FastestMirror(all_urls).get_mirrorlist()
File "/usr/lib/yum-plugins/fastestmirror.py", line 333, in get_mirrorlist
self._poll_mirrors()
File "/usr/lib/yum-plugins/fastestmirror.py", line 376, in _poll_mirrors
pollThread.start()
File "/usr/lib/python2.4/threading.py", line 416, in start
_start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread

現在、調べているところです。

作成情報と更新情報

近頃はすべてのテーブルに、作成日・作成者・更新日・更新者の４フィールドを持たせる設計が多いです。この列を持たせる理由としては、おもにデータの作成された状態をトレースするためですが、改めてこの列の存在価値を考えたいと思います。

メリットとしては、論理的に間違ったデータが入った時にその登録経路のヒントとなることです。更新時間や更新者（あるいは更新モジュール）が分かれば、プログラムのどの場所に間違いがあるのか簡単に判明することがあります。
しかしデメリットも考えると多々あります。
まずこの情報は、最初と最後しか記録していません。そのため時間の経ってしまったデータについては、間でどのような書き換えが行われたかが不明です。
次に、データを書き出すプログラムが更新者や更新日を正しく書き出しているという前提も必要です。更新者や更新日情報を更新せずにデータだけ更新していたら、かえって問題の発見を遅らせてしまいます。
さらには、OracleでいうSQL-Plusのようなクライアントツールで直接SQL文を発行したときの情報も取得できません。

それらも踏まえると、次のような作戦もありなのではないでしょうか？
・トリガーを使って、履歴用のテーブルに更新者と更新日を記録する。
→テーブル名、操作(CRUD)、更新日、更新者、更新モジュールID、主キーを列とする履歴テーブルにとにかく記録していく。履歴は追えるが内容までは追えない。パフォーマンスに難あり？
・記録しない
中途半端な情報ならば、いっそ記録しないという手もあります。Oracleなどであれば、その気になればアーカイブログやREDOログなどから更新履歴を取得することも可能です。

何のために情報を残すのかを改めて考え直せば、どのレベルまで履歴を取っておくべきか答えは見えてくるはず。

トレーサビリティ

ここ数年間の間、システム開発をするには「トレーサビリティ」が重要だという思いが強くなっている。
たとえばコードを書いたときには、それが設計書のどの部分に対応しているのか？
たとえばテスト設計を書いたときには、それが設計書のどの部分に対応しているのか？
これがきちんと説明できないときには、そのコードやテスト設計を書いた人はたぶんわかっていないまま書いている。
そういう非連続性を見つけ出すためには、レビューが重要。というかレビューの重要な観点の一つがトレーサビリティ。