自分で使うアプリを複数作って使っている。
公開しているものもあるけれども、誰かが使っている形跡はない。
今手がけているのは、iTunes & iPodの再生履歴を自宅サーバに送信してデータベースに蓄積して、どうにかするシステム。Webアプリで実装していて、PHP+ZendFramework+PostgreSQLで構築した。クライアントアプリは、今はMac用だけあるけれども、前はWindows用にC# .NETでも作ったので直せば使えるはずだ。
これ、気合入れれば、Last.fm並（ラジオとか、アーティスト情報、楽曲情報の提供は無理としても）のモノに育てられるのだけど、Web側にもアプリ側にも「ユーザ情報を設定する仕組みを作りこんでいない」ため、新しいユーザが使えない。要するに、IDの取得（登録）〜アプリのダウンロード（起動）〜音楽再生（データ送信）〜データ閲覧という流れがないのだ。
データベースの作り的にはマルチユーザを意識しているので、インタフェースを用意すれば対応可能なのだが、作業が進まない。デザインの心がないので、ビューのレイアウトにも苦心している。
もう一つのアプリケーションがMac用のTwitterクライアントアプリ。MacネイティブのCocoaアプリケーション。Core Dataを使ってObjective-Cでバリバリ書いている。Twitterのアカウント取得の直後から作り始めた自分用のアプリケーション。形が整ったところで、自宅サーバに専用ページを作って公開もしている。ダウンロードはポータルサイトのボットしかしてくれていないが。
これのバージョンアップがまた、難しい。Twitter歴が浅いので、どんな機能が必要かがわかっていない。多機能なアプリケーションは世に溢れている。また、便利と言われつつOAuth対応を諦めて消えていったアプリもある。Twitterでできることをすべて実装しようと思っても、自分が使わない機能はテストできないから実装できないのだ。
例えば、ダイレクトメールの受信機能。これは最初、作らなかったし、作る気もなかった。送る相手もいなければ、送ってくれる相手もいなかったから。ある日突然、フォローしている相手から一通届いた。それはブラウザで読んだのだけれども、とりあえず、届いたものは読めないといけないだろうと、いうことで実装した。
今の状態は、ほぼすべてこんな感じで機能追加してきたもの。整理がされていない。ソフトウェアには要求があって、そこから仕様を決めて作る。Twitterのクライアントであれば、Twitterで何をするか、何をしたいかということが要求になる。Twitterの全機能を使うこと、というのは要求にならないし、ブラウザと同じ、も要求にならない。ブラウザよりも便利に使うためにアプリケーションをわざわざ作る。要求は、Twitterの機能の中で、必要とする機能の部分集合をブラウザよりも便利にできる、となる。
この「部分集合」が、Twitterを使っていくうちに変わってくるのだ。上記のDMもそうだし、その後の話だと、リストを見る機能もない。最近になって初めてブラウザからリストを作った。それを見る機能はまだアプリには実装していない。また、フォローしていないあいてからのmension（@メッセージ）が読めない。自分のフォロワーから一方的に送られてきた場合（自分が相手をフォローしていない場合）はタイムラインに乗らないので、別に取得しなければならないようだ（APIドキュメントに別にインタフェースがあったからおそらくそうなのだろう）。
といった具合に作りたいものが複数あって、優先順位が日々、刻一刻と変わってくるし、気分で、PHPしたかったり、CSS調整したかったり、Xcodeさわりたかったりするので、作業がどっちつかずになるのであった。
コメント