6月 トム・デマルコのもとに

プロジェクト管理の権威トム・デマルコの本を読みあさっては、開発プロジェクトの進め方を振り返って修正を行っていた。コードの実装よりも、ロジックと仕様の見直し。そして、ハンズフリー再生機能を備えたPiyoCast v2.0は、ついに一般公開にたどり付くのだった。

PiyoCast配布開始

配布開始しました。

PiyoCast:未対応プラットッフォーム再生時の警告メッセージサポート

PiyoCast未対応のOS(Windows系)およびiPodで再生した時に、 

「このプラットフォームはPiyoCastが稼働してないから曲が鳴らないよ〜ん」 

というメッセージを再生する機能を追加した。いや、正確に言えばPiyoCastのコンテンツは冒頭にこの文言が音声で入っている必要があり、PiyoCastでは制御コードでその再生時間分だけ、スタート時のポジションを変更するのだ。 

関係者に聞かせて回った「試聴コンテンツ」にBGMをつけたりジングルをつけたりして完成度を高めたバージョンを用意。これで配布しよう。 

しかし、こーゆーのに興味がない層にはめっぽうウケないPiyoCast。まあ、そういう人たちには何を見せても関心を持たないので仕方が無いのだが。

PiyoCast〜そろそろいけるかな

PiyoCastの最初のα版(人前でみせびらかすバージョン)で、Podcastingから曲を呼び出して、曲の再生が終わったあとの処理で、iTunes側で再生がストップしないことがあったので、それを徹底的につぶしていた。 

iTunesが最前面にいるかぎりは大丈夫になったようだ。iTunesをバックグラウンドに持ってきて、最前面でテキスト打ちなどを行っていると制御をヘマることがある。実に不可思議だ。 

ともかく、放置状態ならずーーっとラジオのように再生できている。 

そんなわけで、大物の不具合はなんとかなったので、あとはいくつかマイナーな機能アップさえ行ってしまえば大丈夫。PiyoCastが動作していない環境で再生を行ったときだけに再生されるメッセージを作る機能〜 

「このPodcastはPiyoCast対応コンテンツです。現在お使いの環境ではPiyoCastが起動していないか、PiyoCastが現時点でサポートしていないプラットフォーム(Windows)であったり、あるいはiPodで聴いている場合にはPiyoCastは有効になりません。音声部分のみお楽しみください。 

こういうのを流す機能を付けておけばよかろう。 

ものすごく安心してバラ撒けそうな気配になってまいりました(^ー^;;;; 

PiyoCast:完全バックグラウンドでクリックレス再生ができた!

ついさきほど、PiyoCast ver.2でバックグラウンド動作によるクリックレス再生で番組の再生ができました。わーーい!(^ー^)/

■後日談

しかし、問題なのは「再生を行うこと」ではなく「再生を停止させること」であることが後になって判明する。Appleのバグによるトラップがまたここにも。

トム・デマルコのプロジェクト管理の観点から、自分のソフトウェア開発プロセスを再検討する

プロジェクト管理の権威、トム・デマルコの書籍を買って、電車の中、喫茶店、休み時間などずーっと没頭して読んでいた。面白いし、値段以上の価値があったと思わせる本だ。いや、これまで読んでいなかったことが逆に恥ずかしいと思えるほどだ。 

これらは、純粋に「プロジェクト管理」について書かれているものであって、会社の上司をどーするとか、社内政治でどーにもならないケースについての対処方法が書かれているとかいうものではない。割とそのへんは本文中でも「お手上げ」といっており、さらに「知的労働者は職場を移動する権利を有している」といっているあたり、どうにもならないことにエネルギーを割くよりは新天地をさがしたほうがよい、という見解を垣間見ることができる。 

トム・デマルコの本をじっくりと読み、分析を行い、自分の行っているソフトウェア開発のプロセスでいくつか試してみようと思えるものがあった。 


(1)いきなりコーディングに入らない 

仕事でプログラムを組む場合は、きっちり仕様を決めて作るのだが、個人プロジェクトのプログラムは、やおら勢いにまかせてコーディングから始まることが多い。 

簡単な試作品を作って、技術的にアイデアの実現が可能であることが実証できたら、既存の機能ライブラリをガンガンつなげていって短時間で完成レベルに持っていく。 

それぞれの部分についてコメントはつけておくが、「どーしてこういう処理を付けようと思ったのか」とか「現在このような課題を抱えている」といった大局的な見地からのコメントがなかったりする。 

仕様を万全なものにしてから組み出す、というのは悪くはない方法だ。DB上でシミュレーションを行ってからコーディングする、ぐらいの勢いでもよいだろう。 


(2)余裕のあるコードを書く 

本に書かれていたことではないが、自分が作るコードは「最短距離で目的を達成する」という種類のものが多く、あとから手を加えようとすると、ものすごく苦労させられることが多々ある。 

後になって機能の変更や拡張が可能なように、若干余裕をもった設計を行っておくことが重要であるように思える。 

通常のScript Editor上で書いている際には問題になりにくいのだが、Xcode上に移してしまうとデバッグ機能の貧弱さから(機能していないに等しい)、問題が発生した時に対応し切れなくなったりする。そうした場合には、Xcode上からAppleScriptをScript Editor用に書き換えて、分解修理を行うことがある(仕事のプログラムはいつでもXcodeのプロジェクトから分離できるように書くことが多い)。 

個人プロジェクトでも、いつでも分解修理できるようにしておくことが必要になるだろう。 


(3)短期間で大幅な機能アップを行わない 

いつも、ものすごく短い期間に大量の機能を実装してしまうのだが、これも善し悪しである。思うに、プログラムによって実現された「機能」には慣性が働いており、短期間のうちに巨大な機能を実装してしまうと、慣性が大きくなってなかなか方向転換などが行いにくいように見受けられる。 

短期間のうちに作成した大量の機能は、あとで自分の首をしめることになりかねない。プログラムを進化させるのに適したスピードというのは、自分が実装するよりももう少しゆっくり目ではないかと思うようになった。 

とくに、AppleScriptのプログラムは、Objective-Cなどよりも急速にプログラムを高機能化させることが可能な割に、プログラミング環境そのものが貧弱だったりして(とくにXcode上で書き出すと、その貧弱さに泣きたくなるほどだ)、おまけにXcode上で書けるプログラムの行数に制限がある。1つのScriptでだいたい1000行を超えると、いろいろと不具合に直面し……4000行ぐらいも書けば構文確認時に原因不明のエラーやクラッシュなどが頻発する。 


AppleScript環境で仕事をしている人間がまず最初にすべきなのは、US Appleにバグの所在などを繰り返し声高に主張することなのかもしれない。

iTSのアフィリエイトを蹴られた

PiyoCast 2.0の開発を行うかたわら、Webサイト「www.piyocast.com」の整備を行っていた。ぴよまるソフトウェアのWebサイトは「piyo.piyocast.com」。ドメインのトップをわざわざ避けてWebサイトを構築しているのは、このPiyoCast Webを立ち上げるためである。 

とりあえず、PiyoCast対応のPodcasting中から呼び出す楽曲については、気に入ったら買ってくださいねということで、アフィリエイトのリンクを入れてみることにした。 

iTMS(今はiTSか)のアフィリエイトはLinkShareという会社が扱っているらしい。そこの登録は通った。 

しかし、iTSの審査で落ちたらしい。理由はよく分からないが、要約すると「ページ少なすぎなんじゃ、ボケ」ということのようだ。 

目下、PiyoCast.comのコンテンツはトップページが1枚あるだけで、ほかにページらしきものは用意していない。いや、用意はしているのだが掲載はまだ行っていないのだ。 

ページが増えてアクセス数が増えたら考えてやる、それまでは相手にせんからよろしくな 

ということのようだ。うーーむ、オープン時に一気にコンテンツをアップして、スタートダッシュをかけるといった手法はとれないようだ。もう、コンテンツを作ったら、順次アップしていかないとLinkShare様やらiTS様は相手にしてくれないらしい。 

トップページ1枚しかないサイトが「アフィリエイトしたいんですけど〜」といっても世迷い事にしか受け取られないものだろう。どうせ審査する側もマニュアルに基づいて見ているだけのロボットだ。 

……そんなわけで、かったるい事にソフトの開発を行うために充実したWebサイトを用意しなくてはならなくなった。ものすごく本末転倒のような気もするのだが、あとでさんざんネタにしてやろうと思う今日このごろである。(ーー;;;;;;

Copyright by Piyomaru Software, all rights reserved.