MagSite1の開発、進めています。
進めていますという割に、あまり成果が表に出てこないので、本当にやっているのかと思う人もいると思いますが、確かに進んでいます。
現在、TrackBack送信機能を開発中です。
こんなに短い仕様なのに? §
TrackBackの仕様書は短いものです。こんなに短い仕様を実装するために、こんな時間が掛かるわけがない、と思っている人もいるかもしれませんが、これは違います。
より正確に言えば、実験的にTrackBackを送受信するだけ、つまりただ単にただ単に送受信するだけの話なら、簡単と言えるかも知れません。しかし、実用的に使いやすく運用するとなると話は別です。
なぜ、話が別になるかというと、TrackBackが未知の不特定多数のシステムと通信を発生させるからです。
たとえば、TrackBack pingを送信しようとして、相手のシステムが応答しなかったらどうするのか。実験的な実装であれば、ただ単に通信エラーとして処理を終了しても良いでしょう。しかし、実用システムでは、それは便利とは言えません。まず、通信エラーへの対処として、そこでTrackBack pingを取りやめてしまうのか、あるいはあとで再挑戦するのかを選択できる必要があります。
また、送信したTrackBack URLの履歴を保存して、過去に既に送信した対象に対して再送信しようとした場合に、確認を行う必要もあるでしょう。
これらはTracBack送信そのものというよりも、ユーザーインターフェース(UI)の問題と言えます。それらをしっかり作るとなると、簡単なプログラムでは済みません。
TrackBack ping送信ユーザーインターフェースも凝ってます §
TrackBack送信機能のUIは、約8割ほどできています。
おおむね、上に書いたような問題への対処が完成しつつあります。
それを実現するために、MagSite1では4つのURLリストをコンテンツに持たせるようにしています。
4つは、以下の役割ごとに分けられています。
- これから送信したいTrackBack ping URLのリスト
- 現在送信処理中のTrackBack ping URLのリスト
- ペンディングと指定されたTrackBack ping URLのリスト
- 送信完了したTrackBack ping URLのリスト
最初のものは、書き手がコンテンツ作成ページで書き込んだURLを保持します。
2番目は、乱暴に操作しても2重送信しないために用意したリストです。Webブラウザでリロードや前後移動などを連続して行うと、同じ機能が重複して起動してしまう可能性があります。これは、同じTrackBack pingを複数回送信してしまう危険を意味します。そこで、現在送信処理中のTrackBack ping URLを管理するリストを特に用意しました。このリストに入っているURLは、既に送信処理に取りかかっているわけで、それをもう一度送信しようと試みることが無いようになっています。
3番目は、TrackBack ping送信がエラーになったあと、書き手が「あとから送信を試みるためにペンディングリストに入れると選択したURLを保存するリストです。このリストのURLは、コンテンツの編集画面に行けば、いつでも「これから送信したいTrackBack ping URLのリスト」に移動させたり、削除することができます。
4番目は、既に送信に成功したURLのリストです。同じURLに再送信しようとしたときに、確認を求めるために保存されます。コンテンツの編集画面に行けば、いつでも内容を確認することができます。
プログラムを書くのが遅い理由 §
最近、私自身がプログラムを書くのが遅い、という状況が確かにあります。これらのUIのソースも、全体としてはかなりの時間を掛けて作成しています。
その理由の1つに、明らかに汎用性のあるコードを、AWebProcedureFrameworkのようなライブラリの形に整備したりする手間があります。
しかし、もっと大きな理由は、コードを書く前に考える時間が馬鹿にならないという状況があります。現在、完璧なプログラムを事前に設計することはできないという考え方を支持して、より良くユーザーニーズに適合するために、作りながら仕様が変化し続けるという方法論を採っています (エクストリーム プログラミングなどと近い考え方)。そういう意味では、考えるより、とりあえずソースを書いて使ってみるところから始める方が、より適切であるかのように思えます。
それにも関わらず、手を動かす前に長考するのは、明らかに予測可能な問題に対して試行錯誤をする時間は無駄である、と思うからです。今回のTrackBack送信UIで、4つのリストが必要であるということは、考えることによって明瞭になりました。その結果、最初から4つのリストを実装して、作業の手間を小さくすることができたはずです。もちろん、予測できない要素がある場合には、考えすぎることは毒にしかならないと思いますが、考えて分かることは考えておくべきだと思います。結果として、今回も、試行錯誤の迷宮を彷徨うことに比べれば、より短い時間でコンパクトなコードを作成できたと思います。
(でも、本当はそれだけでなく、コードを書き換える恐怖感のようなものが残るという部分もあって、それで手が止まる状況もあったり……。これは全く心理的な側面ですが)