CD 30,000枚分のメンテナンス

今日は少し遅めの夏休み（たった一日ですが）をとって、のんびりしています。

iBPM Counter も長く使っていただくようになり、Webでのデータベースもおかげさまで約47,000曲を超えました。
データベースの中身を CD の枚数としてカウントしなおすと、約30,000枚分のデータが入っていることが確認されています。


さて、記事タイトルにもありますとおり、今回はこのデータベース「メンテナンス」のお話です。


このサイトのデータベースは自動収集なので、ムダな情報や重複している情報もたくさんあります。
また、サイトを充実していくにあたって、追加したい情報などもたくさんでてきます。



ところが、1曲1曲手作業で修正していったら、時間がいくらあっても足りません。

例えば、「アルバムのジャケット画像を表示したい」とします。
Amazon のサービスには（ある一定の条件で）アルバムジャケットを表示してくれる機能があります。

1曲あたり、アルバムジャケットを検索する作業時間は（私の場合は）約2分。

30,000曲、手作業でやると 60,000分かかります。
時間でなおすと約 1,000時間になります。
毎日、なんとか時間を見つけて1時間がんばると1,000日間。
・・登録されているアルバムにジャケット画像を（手作業で）加えようとすると、約3年かかります。


メンテナンスを自動化するとしても、「間違えて昔のデータを消さないように」とか「途中で問題が発生してもゼロからやりなおしにならないように」などなど、うっかりしていると「1週間分の作業がパー」なんてことも「しばしば」あります。


iBPM Counter を使ってくださるユーザの方や、サイトにいらっしゃる方からすれば、「すばやく」「簡単に」「きれいに」使えるようにしたいですよね。

亀以下の「のろさ」かと思いますが、日々少しずつ勉強しています。
今後も気長におつきあいいただければ幸いです。続きを読む

西村さんという先生がiBPM Counterについて書いてくれていた

今日は4つも記事を書いているので、これで終わりにします。

同じくWebでリサーチしていたら、西村さんという方がiBPM Counterについて記事を書いてくれていたことが判明（2007年9月ころなので去年（爆））。

>nisimura | diary
http://www.nisimura.info/diary3/d200709.html

私自身がiBPM Counterを使ってムダにこだわっていたことを文章にしてくれていて二度爆。

（以下、引用）
----------------------------
で（ここからが本題です）。

曲を聴きながらカチカチやってると、まー私のクリックなもんで、たとえばBPM=128くらいの曲があったとすると、125〜130くらいの範囲で値が変動してしまうのですね。

で、だいたいこの位だろうというところでヨシとしているわけなんですが、数曲やって気付いたこと。

「奇数、キモチワルイ」

131なんて最強にキモチワルイです。

125〜130くらいでばらついているとき、127か128が安定値（ずっと出続けることが多い値：当者比）なわけなんですが、127だと気持ち悪いので、128が表示されたところで[SET]。
120や144がすっとでると気持ちいい。メトロノームで見慣れてる（ような気がする）値なんだろうな。

もともとがアバウトな目的なのでこんなもんでいいやと思ってます。

しかし、BPM奇数表示がこんなにキモチワルイとは思いませんでした。

※あくまでも表示だけの問題です。まぁ当然ですが。

※しばらくしたら慣れました。
----------------------------

・・・そうなんです。キモチワルイんです。

（全然関係ないけど）別のユーザさんが11,656なんてBPM登録してくると「どうやってこんな超速連射で登録したんだ！？」なんてキモチワルクなります。

思わず偶数しか表示されないように機能を改変しようかと思ったくらいですが、さすがにこれは【改悪】かと思いとどまりました。続きを読む

iBPM Counterが雑誌に掲載されていた

ネットリサーチしていたら、ネトランという雑誌にiBPM Counterが掲載されていたことが判明。

光栄かつちょっと嬉しかったのでご紹介。

ネトラン1月号
http://www.oshiete-kun.net/tools/0803/toku1.html