というコマンドはご存知ですね.
yuji@aya:~/text%date +%j -d "Oct 25 2000" 298
これは, じつはけっこう多機能で, 上のように 日付の出力フォーマットなんかを変えたり いろいろできる. 「3日まえ」とかの指定なんかできたりして.
閏年なんかもだいたいうまく動くんですが, 先程, 若干面白いところを発見しました. 上の例は, 一年の何日め (day of the year) という指定なのだが, たとえばこんなことができる.
yuji@aya:~%date +%j -d "jan 38 2000" 038
1月 38日は存在しないが, それに関する文句は言って来ないのである. 普通の年では, 2月 29日は存在しないが, それも関係なく day of the year を計算しれくれる.
では, 閏年ではどうだろうか？
yuji@aya:~%date +%j -d "feb 29 2000" 060 yuji@aya:~%date +%j -d "mar 1 2000" 060
てなぐあいで, 閏年でも 2月 29日は 3月 1日と同じ日になってしまうんです. これは 2000年が 400の倍数だからではなく, どうも day of the year の閏年の計算をやってないから みたいですね. 2000年 12月31日の day of the year が 365 になっているのを見て 気づきました. 曜日の計算も同様に間違えます.
なんでこんなことに気づいたかと言うと, ノートパソコンを 2000年 10月25日に起動してからこっち 再起動してないのですが, その日数を計算してたのです. ノートですから suspend しますが, すると uptime が動かないわけで, この計算には使えないわけですよ.
もっとも, その日数の計算結果自体は, 起動した日が 閏日よりも後なので, date コマンドの day of the year の 出力が閏年の計算が原因で誤っていたとしても, 正しい値が出るわけですが. 笑.
起動してから, 現在(2001/03/06)で 132日 です.
コンパイルしまくってますが, 自分の書いたものとか セキュリティ上の不具合の修正とかで, ここに書くようなことは特に何もないんですよ. セキュリティ上のあれこれは, wloj のセキュリティのページに書いてますし, そっちの方がここよりもずっと早いしマジメに書いてありますから 見てね. しかし, 俺ごときがセキュリティの記事を書いてますが, そんなんで良いんですかね？ と思った人は, Webmasters に入れ！ 行け GO！
そうそう. このほど web アプリケーション (とか言うのか？) の開発を やることになってしまいました. といっても仕事じゃなくて趣味方面のボランティアなんですが.
私, クライミングなんかもやってまして, その方面の団体などに遭難救助やパートナーを捜す関連から所属しております. このところ, 全然登ってないわけですが, そういう登れてないヘナチョコな奴にも, イット革命 のおかげで, こういう貢献の仕方が可能になったというわけです. イソパク万歳！
メンバーが, 山行の計画を web あるいはメールのインターフェースで 申告できるようにし, それら計画は DB で管理する. この DB の用途は, 例えば申告された下山時刻を 48時間経過しても 下山報告が無い場合に, 自動的に 「このメンバーの下山報告が, 下山予定時刻を過ぎてもありません」 みたいなメールがクラブのメンバーに送信されたりといった具合です. 遭難対策の補助ですな.
もちろん, 通常の DB 的な, 検索とかなんかイロイロ (良く判ってない. 笑) できるようには する予定.
データベースってのは, 入力されるデータがいっぱい無いとつまらないんですが, これを自分で入力するのでは, めんどくさくてやってらんないわけで, やっぱり面白くないわけです. データの入力や検索の敷居がどれだけ低いかが, こういうものの成否の鍵の一つですな.
今のところ, 検索は, 多分 web が一番簡単で無難だと思うんですよ. 問題は入力ですな. メールかなー. もちろん, web からもできるようにはするわけですが, さて, どういうふうに作るのが, 使いやすいのかなあ？ 検索する方としては, 詳しい情報が欲しいが, 入力する側としてはめんどくさいのは嫌です. これが難しいですねえ.
もう一つは, データベースの, データの設計をどうすりゃ良いのかの 見当がつきかねているんですな. 計画と下山の報告は無関係ではないが, 天候の具合なんかで全然違うところに出かけたりして まるきり無関係になる場合もある. そういう依存関係をうまく利用しつつ, できるだけ入力の手間が省けて, かつ, 有用な情報が入力されるように 作りたいわけです. もちろん, 拡張に対して柔軟に対応できるようにもしたい.
イキナリそんなにうまく作れるわけ無い んだけど, 自分以外の人も利用するとなると, やっぱりちゃんと作らなきゃいけないわけで, 今までみたいに 「とりあえず動けば良い」みたいなのは, ややマズイわけです. それに, 他人の計画や報告を捏造できないように, セキュリティとかも考えないといけないから, 調べることも多い. つまり, 私が知らん事が多いんで, こりゃかなりめんどくさいです.
そうだ. 今, ちょっと考えてみよう.
まず, クラブのメンバーのデータベースがある. たとえば, メニューその他はこのデータベースからの情報をもとに 生成する.
計画の申告は, 何かテンプレートを用意しておいて, その空欄を埋めるのが良い. 報告は, テンプレートを計画の申告から生成すると 入力の手間が省ける.
あとは, ユーザ管理が欲しい. 仕様としては, いろんなユーザのデータベースを検索／閲覧できるが, レコードを追加したり削除できるのは, そのユーザだけでないと だめだ. なんせクラブは動物園みたいな団体で, いろんな獣が居ますので.
ユーザの登録と削除も, わしがやるんじゃなくて, 各自でやって欲しい. 削除と改変は, 登録した本人だけに可能にする. というか, データの維持や操作に関連する作業は一切, 管理者など特定の人物に負荷を集中させてはならない. メーリングリストの運営は, このユーザ情報を元に 動的に行うようにしよう.
クライミングは複数のメンバーで行くわけだが, 報告その他レコードの追加や更新は同行した全員にできるのが望ましいのかな？ よくわかんねえや.
著作権の問題とかは, 動いてから考えよう.
計画のテンプレートはこんな感じかな？
報告のテンプレートは, 上記に対して, それぞれのフィールドには 計画の内容がデフォルトで入っていて,
こんな感じかな？
フリーの人は, 登った最高グレードとか, グレードの分布とか平均とかも見たいだろうな. そういうのは, どうするかな.
他に, もしデータがあれば, 写真とかを入れたいねえ. その場合, 写真のデータは url として保持するか, それとも写真のデータも DB に格納してしまうか, どうすべきかねえ.
で, 「自分の今までの記録」とか速攻で見れたら, それはそれでベソリかもな. 「自分の, 計画倒れに終わった妄想」とかも見れたら それはそれでセツナイな. 笑.
つうか, 検索というか, なんつうか, そういう方面のインターフェースはムズイなあ.