画一化されたカレンダーの提供方法

生活に関連する一般的な要素として、カレンダーがある。
連絡に用いる電子メールや情報を発信するWeb等がユーザレベルでも広く広まっているが、それらと比べるとカレンダーの標準化という点ではあらゆるユーザが統一した方法でアクセスするようにはなっていないと感じる。
標準化されるための方式自体は標準化されている(iCalendar、CalDAV等)が、よくある施設のイベントの一覧は大抵はHTMLでブラウザからアクセスする事だけを目的としており、ユーザは複数の施設の予定を確認するには施設ごとのサイトにアクセスする必要があり、予定が競合するかどうかの確認は

• 並べて表示する
• メモしておく

等の操作を行ったうえで自分のスケジュールを突き合わせる必要があり、二次加工の容易さをもっと求めた方がユーザのためになるのは明白だと考えている。

そのための提供方法の統一化を考えた場合、とりあえずGoogleカレンダーは以下の点から便利に使えるのではいかと考えている。

• ひとつのアカウントで複数のカレンダーを保持できる
• カレンダー毎に第三者に公開でき、権限(閲覧・参照など)を設定できる
• HTML、iCalendarなど、さまざまなアクセス方式が用意されている

なお、Googleカレンダーの操作をするためのAPIが公開されており、プログラムから操作する事が可能なため、調査結果を報告したい。

ログの設計(考え方)

あらゆるシステムを作成する際に重要な役割を果たすのがログであり、概ね開発段階・運用段階において以下の目的で使用される。

開発段階(テスト段階)でログ出力を行う目的

• 処理呼び出しの契機の確認(システム外部からの呼び出し確認)
• 処理結果(正常終了・異常終了)確認
• 処理通過ルートの確認
• 性能計測(ログ出力時刻を基準にして計算)

運用段階でログ出力を行う目的

• 障害発生の検出
• 障害発生箇所の局所化
• 障害発生原因の推定

目的の違いや、むやみに出力を行うとログ出力量が膨大になり、またログ出力自体もひとつの処理なので、出力を増やしすぎると性能に影響する事も避けられず、たいていの場合はシステム内でログレベルが決められている(決めないと後工程に推移するにつれて大変なことになる)。
大抵の場合、ログレベルは重要度に応じて定義される。最低でも以下のログレベルは用意すべきである。

• エラー(重要・復旧不可能)
• エラー(軽微・復旧可能)
• システム外との入出力ログ
• システム内部(機能単位)の入出力ログ
• デバッグログ(結合試験の結果確認で必要な情報)
• トレースログ(単体試験の結果確認で必要な情報)

運用レベルではエラーログとシステム間の入出力があれば、そこから何が起こっているのかは類推できるはずなので、試験終了まではそれ以外も出力してよいと個人的に考えている。また、入出力ログのタイムスタンプからどの程度の処理性能なのかは確認できるので、運用試験の工程にて確認する目的でも使用可能であると考える。

テスト投稿(日付フォーマット)

W3CDTFというフォーマットがあり、以下の６タイプが規定されている。

1. 年のみ YYYY（例：2001）
2. 年月 YYYY-MM（例：2001-08）
3. 年月日 YYYY-MM-DD（例：2001-08-02）
4. 年月日および時分 YYYY-MM-DDThh:mmTZD（例：2001-08-02T10:45+09:00）
5. 年月日および時分秒 YYYY-MM-DDThh:mm:ss.sTZD（例：2001-08-02T10:45:23.5+09:00）
6. 年月日および時分秒および小数部分 YYYY-MM-DDThh:mm:ss.sTZD（例：2001-08-02T10:45:23.5+09:00）

TZDにはUTCからの時差を示すか、UTCの場合はZの一文字を記述する。
XML SchemaのXSDTYPEは、上記のうちの5と6が使用可能である。(ただし、TZD部分は省略可能)


参考：http://www.kanzaki.com/docs/html/dtf.html