2017年3月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

最近のトラックバック

無料ブログはココログ

2007年12月25日 (火)

OuDia開発の経緯-17 OuDia Ver.0.04 リリース(2006年3月7日)


 これを書いている2007年12月現在、OuDiaの最新バージョンは0.04.08 となっています。

 このバージョンのベースとなる OuDia Ver.0.04 は、2006年3月7日 にリリースされました。このバージョンは、僕自身がOuDia本格着工時にやりたかった機能が一応満たされたものであり、ひとつのマイルストーンとなるものであると思っています。OuDiaを本格着工したのは2005年5月ですから、ここまで来るのに約8ヶ月が経っていました。

 作者自身はこのバージョンをリリースした後、再就職を行いました。その後はまたまた本業多忙になってしまっており、OuDiaの開発にはなかなか時間をかけられなくなってしまいました。結果、バージョン0.04以降のバージョンアップの間隔は開いてしまい、規模的にも小改造にとどまっています。

 こんな状況ではありますが、OuDia Ver.0.04.08 のダウンロード回数は 2000 以上となり、ユーザーの方は当初よりもずいぶん増えました。また、実験的に開設したブログやメールでも、OuDiaに対するご要望を頂戴しております。まあ、時には「過去をふりかえっているだけ」などという手厳しいお言葉を頂戴することもありますが・・・(^^; 。

 今のところ、 OuDia に対する次の大きな展開の予定を考えることは難しい状況ではあります。でも、これからもできる範囲で、ユーザーの皆様のご期待に応えられる方策を考えていきたいと思っています。

2007年12月16日 (日)

OuDia開発の経緯-16 Vectorへの登録(2006年1月17日)

 Vector は、日本最大規模の、オンラインソフトウエアライブラリです。OuDiaも、この Vector に登録しています。

 当初はあまり深く考えず、お試しのつもりでの登録でした。が、Vector の宣伝効果たるや大変なもので、これをきっかけに OuDia のユーザーが大きく増加しました。同時に、このサイトへの来訪者も、Vectorの掲載を機に増加しました。

 OuDia Ver.0.03.01 は、このサイトで 1/17~2/25 の間公開していましたが、ほぼ同時期に並行してVectorでも公開していました。Vectorでの公開期間は1/27~3/14 でしたが、これはVectorの場合、申請から掲載までの間に1週間程度の時間がかかるためです。
 期間中のこのサイトからのダウンロード数は 150 。これに対して Vector からのダウンロード数は 386 と、何と倍以上でした。Vectorの露出度たるや大変なものです。しかも、Vectorにソフトウエアを登録すると、
 『gooダウンロード』(http://download.goo.ne.jp/
 『Yahoo!コンピュータ - ソフトウエアダウンロード』
 『@nifty:ダウンロード@nifty』
といったサイトにも、Vectorのダウンロードページへのリンクが自動的に掲載されました。これらを含めたトータルの宣伝効果は、想像以上のものがありました。

 この経験から思ったことは、一個人のWebサイトを高アクセス数の人気サイトにするのは大変だ、ということです。特に、近年はブログの普及もあり、WWW上にはサイトが溢れすぎています。その中で多くの人に気づいてもらうのは並大抵なことではなくなっています。『OuDiaのホームページ』の場合は、『ソフトウエアの提供』という特性があったがために Vector という宣伝媒体を利用することができましたが、一般的な、情報提供のみの個人Webサイトを人気サイトに育てるのは、非常に困難な時代になっているように思います。

 

2007年12月 9日 (日)

OuDia開発の経緯-15 時刻入力高速化の試み(2006年1月9,10日)

 OuDia公開後、動作チェックを兼ねて自分でも結構列車本数の多い大手私鉄の路線のデータを入力してみました。しかし、時刻表データの入力は結構な時間がかかりました。編集動作をかなり工夫したつもりだったのですが、自分で使って見て「まだ工夫の余地がある」と感じました。

 OuDiaは、完全なパターンダイヤの作成はかなり簡単にできるのですが、多くの大手私鉄の路線は、完全なパターンダイヤになっているのはデータイムだけで、朝ラッシュ時・夕ラッシュ時には完全なパターンダイヤになっていないケースがほとんどです。この朝夕ラッシュ時においては、同じ列車種別でも発着時刻・所要時分に1~2分のずれが多発し、これらを手作業で修正するのに時間がかかるのでした。こういう1~2分のずれの修正を容易にするにはどのようにすればよいか・・・を主体に考えることにしました。

 まず面倒だったのは、[駅時刻]ダイアログへの時刻入力です。
 当時の[駅時刻]ダイアログは、必ず時と分の入力をしなくてはならない仕様でした。これを、時を省略して分だけを入力できるようにしました。
 また、当時の[駅時刻]ダイアログは、着時刻を修正しても発時刻が変化しませんでした。このため、ある駅の着時刻・発時刻両方を繰上げ・繰下げするのが面倒でした。これも、着時刻を繰上げ・繰下げすれば発時刻も自動的に繰上げ・繰下げになるように変更しました。
【参照】2.3.1. [駅時刻]ダイアログの便利な使い方(http://homepage2.nifty.com/take-okm/oudia/oudia_manual/c02_usersguide/c03_ressyanyuuryoku/c01_ekijikokudlg/ekijikokudlg.html)

 これで少しは楽になったものの、まだ物足りません。[駅時刻]ダイアログを使って駅時刻を変更するには、キー操作が2~3回必要になります。

 「やはり1分の時刻変更はキー操作1回で実行できるべきではないか」ということで考えたのが、『2.3.11. 列車の駅時刻の連続1分修正』(http://homepage2.nifty.com/take-okm/oudia/oudia_manual/c02_usersguide/c03_ressyanyuuryoku/c11_renzoku1syuusei/renzoku1syuusei.html)機能でした。これにより、駅時刻の微調整はかなり素早くできるようになりました。

 しかしながら、これでもまだ時刻表データの入力が面倒なことには変わりないですね。でも、今のところ、これ以上の入力省力化の方法は思いつかないところに来ています(「駅時刻を入力しない」という解決方法は除きます)。

 極めつけは「駅時刻を入力しないこと」なのでしょう。その方法の一つとして「『駅から時刻表』のデータを読み込めるようにしてほしい」という要望を挙げる方も昔からいらっしゃいます。しかし、『駅から時刻表』はデータの加工を認めていないようですし、そもそもそんな機能を作ったところで、『駅から時刻表』のサイトが模様替えされてしまえば、『駅から時刻表』を読み込むプログラムは一瞬にして使い物にならないゴミになってしまいます。『駅から時刻表』の模様替えのたびにプログラムを作り直す作業は明らかに不毛です。このため、そのような機能を追加する予定はありません。



 

2007年11月25日 (日)

OuDia開発の経緯-14 OuDiaの本格公開・・・『OuDiaのホームページ』の一般公開(2005年11月)

 当初は機能・動き共にいまいちだったOuDiaも、いろいろな方からの感想・ご意見を受けながら改良を重ねていき、4ヵ月後の11月にはバージョン Ver.0.02.03 となりました。
 この頃には、「OuDiaがダイヤに関心をお持ちの鉄道ファンの皆様に受け入れていただけるソフトになっている」との手ごたえを持てるようになってきました。
 そこで 2005年11月17日、このサイト『OuDiaのホームページ』の一般公開を開始しました。

 公開はしたものの、当初は来訪者がほとんどいない状態がでした。
 宣伝活動として、とりあえず Google などの検索サイトに登録してみたものの、訪問者は1日にほんの0~4人、という状態でした。OuDiaのホームページには当初からアクセスカウンタを表示していましたが、その数のあまりの少なさに恥ずかしくなり、一時はアクセスカウンタの表示をやめたこともありました。


 

2007年10月21日 (日)

OuDia開発の経緯-13 Undoの最適化(2005年9月8日)

 以前も記しましたが、初期のOuDiaは現在のものに比べてかなり動作が重いものでした。特に重かったのが [編集]-[元に戻す] の動作、いわゆるUndo(アンドゥ)機能でした。

 当時のUndo機能が遅い理由は明白でした。このころのOuDiaは、編集動作ごとに路線データ全部をメモリ上に保存し、Undo動作が行われた時には路線データ全部をUndoデータから読み出して上書きしていたからです。
 補足しますと、『路線データ全部』というのは、全部の駅・全列車種別のデータ・及び全ダイヤの全列車の全駅の発車時刻を含みます。また、『編集動作』とは駅の追加・削除・修正から列車の駅時刻の1分の変更までを含めた、『路線ファイル』に保存されるデータのあらゆる変更動作を指します。
 列車本数の多い路線のデータを入力していると、データ量は次第に多くなっていき、それに従って編集動作が遅くなっていくのでした。

 解決方法も明白です。編集動作ごとに保存するデータを、Undoに最低限必要なデータに減らせばいいのです。たとえばある列車のある駅の時刻を変更した場合、Undoに最低限必要なデータは、『どのダイヤのどの列車のどの駅の時刻を何分変更したか』ということだけです。これなら、『路線データ全部』に比べてデータ量は大幅に減らせます。
 しかし、OuDiaの『編集動作』は、小は列車の駅時刻の1分の変更から、大は駅の追加までいろんな種類があり、それによって『Undoに最低限必要なデータ』は変わります。特に駅の追加・削除は、その時点で存在する全ダイヤ・全列車の駅時刻の変更につながります。これらをうまく管理できるような設計を考える必要がありました。

 そんななか、大阪の某大型書店のコンピュータのフロアで、『デザインパターン』に関する書籍を目にしました。『デザインパターン』とは、ソフトウエアの設計ノウハウをまとめたものです。
 このうち、Undoの最適化に役立つものはないかと探した結果、OuDiaでは『 Memento パターン』と『Command パターン』を参考にしてUndoの再設計を行いました。これがうまく当たり、Undoを含めた編集動作全体を軽快にすることができたのでした。

2007年10月13日 (土)

OuDia開発の経緯-12
OuDia の最初の限定公開(2005年8月5日)


OuDia の最初の限定公開(2005年8月5日)

 最初の OuDia は7月末に動作し始めましたが、その後自分でデータ入力を行って不具合を修正し、8月5日に OuDia Ver. 0.1.805.1 をネット上で公開しました。はじめての OuDia の公開です。

 このころの OuDia は今よりずっと完成度は低く、インターネットで不特定多数に公開するほどの自信は持てない状態でした。このため、『@nifty 鉄道フォーラム』という、会員制フォーラムのデータライブラリで公開しました。

※ 『@nifty 鉄道フォーラム』は現在では運営形態が変わり、『有限会社鉄道フォーラム (http://www.railforum.jp/) 』 となっています。

 これとは別に、当『OuDiaのホームページ』の試作も始めており、そちらでの公開も行っていました。が、これはあくまで知り合いに OuDia を試してもらうためのものでした。このころの『OuDiaのホームページ』は、検索サイトに登録していなかったので、知らない人が訪れることは事実上不可能でした。

 このバージョンは結構多くの方にダウンロードしていただき、多くの方からフォーラムに、ご意見・ご感想をお寄せ頂きました。多数の好意的な感想をお寄せいただき、開発者として非常に嬉しく感じました。モノ作りの喜びを再認識させていただけたと思います。

 僕はプログラマを職業としていましたが、プログラムを作る仕事の現場の多くは、最終的にプログラムを使う人と接する機会がほとんどありません。多くの場合、プログラマはユーザーからはその存在を感じられない『裏方』なのです。特に、下請けとして開発を受注するような会社にいるプログラマは、エンドユーザーと直に接する機会はなく、苦情だけが特定の『担当者』から伝えられる、という状況になっています。

 そういう意味では、作ったものを使ってくれた人の生の声を聞けるというのは、とても新鮮な経験でした。

 その後、OuDiaは、皆さんからお寄せいただいた意見や、自分がデータを作成してみて不便だと感じた点をもとに、機能向上を重ねていきました。
 また、重い動作を軽快にするための設計の見直しも繰り返していきました。今のOuDiaはこのころに比べるとずいぶん軽快な動作になったと思いますが、この軽快さはある日突然実現したわけではなく、工夫を重ねて徐々に軽快になっていったのでした。

2007年10月 6日 (土)

OuDia開発の経緯-11
ダイヤグラムビューで編集操作(2005年7月23日)


ダイヤグラムビューで編集操作(2005年7月23日)

  『10.ダイヤグラムビュー・まっすぐな列車線』で述べたような工夫を重ねて、ようやくダイヤグラムビューに、それなりに見栄えのするダイヤグラムが表示できるようになりました。
 が、この時点でのダイヤグラムビューの機能は、「ただ表示するだけ」でした。時刻表ビューにはそこそこ力を入れて編集機能を充実させてきたのに、ダイヤグラムが「ただ表示するだけ」では、何か物足りないものが感じられました。

 また、WinDIAのダイヤグラムウインドウも、機能は「ただ表示するだけ」であり、時刻表ウインドウに連携するような機能はありません。僕自身が以前WinDIAを利用した時には、「ダイヤグラムの表示結果をもとに発着時刻を修正するのが不便だなあ」と感じられました。このため、このような作業をサポートする機能が何か欲しいな、と思いました。

 まず思いつくのは、「ダイヤグラムビュー上でダイヤの編集」という機能です。具体的には、ドローソフト(Microsoft Word や Excel の『図形描画』みたいなもの)のように、ダイヤグラムビュー上のマウス操作で列車線を引いたり修正したりできるようなものです。
 しかし、これは作るのに相当手間がかかり、すぐにできるようなものではありませんでした。
 また、「どのような操作方法にすればいいのか?」というところを、仕様としてうまくまとめることができませんでした。一般のドローソフトで図形を作成する場合とは異なり、ダイヤグラムはウインドウ上を直線が高密度で交錯します。その高密度の列車線の中から、目的の列車線をマウスでクリックして選択するだけでも難しく、快適な編集作業とはいかないのではないか?と思われました。
 このような経緯で、このアイデアは没になりました。

 「ダイヤグラムを見ながらダイヤデータを修正」という作業をサポートでき、しかも比較的簡単に実現できる機能として考えついたのが、

 ダイヤグラムビューの列車線をダブルクリックすると、時刻表ビューが開き、ダブルクリックされた列車にフォーカスが設定される

という機能でした。
 当初は「本当に便利なのかなあ?」と半信半疑で作成した機能でしたが、動作してみると結構便利で、僕自身のお気に入りの機能になりました。

 OuDiaは一言でいうなら「ファイル編集ソフト」です。そもそも画面そのものが地味ですし、動画再生ソフトなどのような動きはありません。このため、それを使った作業も非常に地味で飽きやすいものです。そんな中で、「ダイヤグラムビューの列車線ダブルクリックによる時刻表ビューへのジャンプ」という機能は、OuDiaではほとんど唯一の、派手な動きを伴う機能であり、OuDiaのアクセントになっていると思うのですが、いかがでしょうか。

2007年9月 8日 (土)

OuDia開発の経緯-10
ダイヤグラムビュー・まっすぐな列車線(2005年7月8~16日,7月30日)

 話が前後して、これはダイヤグラムビューを作成していたころの話です。

 ダイヤグラムビューは、時刻表ビューで入力された全部の列車の駅時刻を線で結べばいいだけだ、と当初僕は思っていました。

 ところが、実際の鉄道時刻表を見ると、同じ各駅停車列車でも、列車によって駅間所要時分に±1分の差が散在しています。これは、実際の列車ダイヤは秒単位(10秒単位や5秒単位)であり、時刻表に表示される時刻は秒以下を切り捨てたものになるためです(着時刻については秒以下を切り上げている時刻表もあるようです)。

 問題は、ダイヤグラムビューにおいて、駅間所要時分に±1分の差が散在する駅時刻を正直に線で結ぶと、列車線は屈折が多くて見苦しいものになるということです。

 言葉ではうまく伝わっているかどうか自信がないので、例を挙げましょう。

 A駅~E駅の5駅があり、各駅の駅間所要時分が1分30秒の区間があったとします。
 この路線で、A駅発時刻が 0:00:00 と 0:07:30 の2本の列車がある場合、時刻表ビューは以下のようになります。


OuDia_ikisatsu_10_02.gif

 この時刻表ビューの入力どおりに列車線を引くと、ダイヤグラムビューは以下のようになってしまいます。


OuDia_ikisatsu_10_03.gif

 しかし、以下のダイヤグラムの方が、見た目に見やすいですし、本物に近いはずです。

OuDia_ikisatsu_10_05.gif 

このため、ダイヤグラムの列車線をより真っ直ぐにするにはどのようにすればよいのかについて、いろいろ考えました。その結果、

 発時刻しか入力されていない一般駅(主要駅以外の駅)の駅時刻は無視して、主要駅から主要駅までの駅時刻を直線で結ぶ方がよい

という結論に達しました。


 現在のOuDiaのダイヤグラムビューは、上記の結論を原則として列車線を結んでいます(実際には、もう少し複雑なルールになっています)。
 但し、主要駅間を結ぶ直線が、駅時刻ビューで入力されている時刻から1分以上離れている場合は、入力されている駅時刻に従って線を結ぶようになっています。

 時折ユーザーの方から「入力した駅時刻が、ダイヤグラムビューでは無視されて線が引かれてしまう」というご指摘を頂戴しますが、それはこの仕組みが原因です。
 ダイヤグラムビュー上の列車線が駅時刻上を正確に通り過ぎるようにしたい場合は、

  • その駅の駅規模を主要駅にする
  • その駅の駅時刻に着時刻・発時刻の両方を入力する

のいずれかを試して見てください。

2007年8月 4日 (土)

OuDia開発の経緯-9
プログラミング作業~最初の OuDia の完成(2005年5月23日~7月30日)


プログラミング作業~最初の OuDia の完成(2005年5月23日~7月30日)

 設計が終わると、いよいよプログラミングの作業になりました。

 前にも述べましたが、設計段階で「何を作るか」が明確になっていれば、プログラミングの作業は設計作業よりは単純作業に近くなります。
 もっとも、プログラムを作るためには知識が必要ですし、必要とされる動作の実現方法に関する知識を持っていない場合は、調べるという作業が発生します。が、どちらかというと、創意工夫よりは、仕事を効率よくこなすための経験がモノを言います。
 ソフトウエア開発はよく、建築に喩えられます。建築でも「何を作ればいいのか」を明確にする設計がきちんと行われれば、実際の大工仕事は比較的単純作業に近いものになる、そんな感じかもしれません。もちろん、大工仕事にも知識と経験が必要ですよね。

 開発メモによれば、プログラミングを開始したのは2005年5月23日、一通りのプログラムが終了して最初の OuDia が動作するようになったのは 7月20日ですから、ほぼ2ヶ月かかったことになります。
 OuDia のプログラムの行数は、約87000行です。ただし、これらすべてをこの2ヶ月で作ったわけではありません。『グリッド形式ビュー』の開発で述べましたが、OuDiaを本格的に作り始める以前から、かなりの構成要素の蓄積を行っています。このような部分を除いた、純粋にこの2ヶ月で作ったプログラムの行数は、大体57000行といったところです。

 このころの OuDia は、基本コンセプトや画面の見た目は現在とほぼ同じでしたが、動作が重いという大欠点を持っていました。現在のOuDiaに比べると、すべての動作が重く、使っていてストレスを感じるものでした。
 特に重かったのが [編集]-[元に戻す] の動作。いわゆるアンドゥ機能でした。ある程度の編集データになると、アンドゥ動作に3秒以上もかかることもありました。当時はアンドゥ動作中に砂時計カーソルの表示を行っていなかったので、作者ですら「フリーズか?」と思うこともありました。

 OuDia と同じ分野のソフトウエアに WinDIA があります。このため、あらゆる面において、どうしても OuDia と WinDIA を比較してしまいます。
 この頃の OuDia は、WinDIAと比較しても相当動作が重いものでした。というより、作ってみてはじめて WinDIA がいかに軽快なソフトウエアなのかがわかり、驚嘆してしまいました。パソコンの性能が今とは比較にならないほど低く、ソフトウエア開発環境も今とは比較にならないほど貧弱な時代において、 WinDIA ほどのソフトを開発なさった ふゆき 氏には只々脱帽という思いでした。


 

2007年7月29日 (日)

OuDia開発の経緯-8
UIの設計(2005年5月20~22日)

 『UI』は User Interface (ユーザーインターフェース)の略です。ユーザーインターフェースは、ソフトウエアがユーザーとの対話を行う機構・つまり画面設計のことです。
 画面設計は通常、ドメインモデリングの結果をもとに行います。画面の種類や機能は通常、ドメインモデリング上での『クラス』と対応関係を持ちます。例えば、

  •  『路線』クラスの属性を設定するための画面・・・『路線ファイルのプロパティ』ダイアログ
  •  『路線』クラスに含まれる『駅』を追加・削除する画面・・・『駅ビュー』
  •  『駅』の属性(プロパティ)を編集する画面・・・『駅のプロパティ』ダイアログ

という具合です。各画面に入力可能な項目も、ドメインモデリングの結果であるクラスの属性をもとにすれば、大筋は自然に決まります。
 こうして、全12個の画面の仕様をある程度決定したところで、ようやくプログラミング言語でプログラムの動作を記述していく作業(プログラミング)に着手できるわけです。

 プログラミングという作業は、通常はそれほど創意工夫を必要とする作業ではありません。設計段階で「何を作るのか」が明確になっていれば、あとはそれにしたがってこつこつ進めていくような作業です。しかし、作業にはどうしてもパソコンが必要なため、屋内にこもっての作業にならざるを得ません。
 これに対して、モデリングや設計といった作業は、コーディングの何倍も頭をひねる作業になりますし、ひらめきも必要です。しかし、この作業は紙と鉛筆があればできるため、あまり場所を選びません。むしろ、デスクに向かいっぱなしよりも、環境が変わった方が、いい考えが浮かぶこともあります。

 僕は、電車やバスに乗っている間に設計を行うことが多かったと思います。家のデスクだと、ついついテレビを見てしまうことがあったりします(お昼の連続ドラマにハマってしまいます・・・)。が、昼間の空いている電車なら、テレビは見られないし、周りに知っている人もいない空間なので、結構集中できるんですね。幸い僕は京阪神在住なので、JRでいわゆる『大回り乗車』をすれば、少ないお金で長時間、電車に座っていられます。また、ときどき流れる景色を見るのも気分転換になります。
 あと、OuDiaを作っている時期には愛知県で『愛・地球博』が開催されており、僕も何度か訪れました(平日に行けるのは失業者の強みでした)。人気パビリオンに入るために長時間並ぶことが何度かありましたが、そんなときは行列待ちをしながら、ノートパッド片手に設計を考えていました。このため、2時間程度の行列は、あまり苦にならなかったように思います。もっとも、こんなことができたのは6月まででして、7月以降は猛暑のため、屋外で行列しながらの考え事はとてもできなくなりましたが・・・。