2010年12月31日

Waveとは何か (pamela fox's blog - Why I Love(d) Wave より)

GoogleのPamela FoxさんがWaveについてブログに書いている。

http://blog.pamelafox.org/2010/12/why-i-loved-wave.html

読んでみて、今まで自分はWaveについてちゃんと理解していなかったんだなぁと思った。Waveの本質ってなんだろうか。

Wave is a flexible and generic platform, one that can be used for groups discussion, for diary entries, for event commentary, for surveys. Of course, there are existing solutions for doing each of those things - but there is not one solution that does all of them.

Waveは柔軟で汎用的なプラットフォームで、グループの掲示板、日記帳、イベントの感想ノート、アンケートなどが出来るの。もちろん、これらの事が出来る個別のソリューションはこれまでにもあったけど、全部の事が出来る単一のソリューションと言うものは存在しなかったわ。

The thing I loved about Wave is that I could start a wave about a topic, and that wave could evolve from a survey to a discussion to a photo album (like when I asked folks what color I should dye my hair next), or be a combination of all three at once. I didn't have to know at the beginning what it would be, I didn't have to carefully weigh all the different options, I could just start a wave and see what it became.

私がWaveを好きなのは、ひとつのトピックを開始したら、それが徐々に単なる質問からディスカッションに変わったり、さらに写真アルバムになったり(私が髪の色をどうしようかってみんなに尋ねた時みたいにね)、それら全部の組み合わせに発展したりするからなの。最初から「どんな風にしようか」って考えたり注意深く別の選択肢を検討したりしないと行けない訳じゃなくって、単にwaveを作ってそれがどうなって行くか見ればいいのよ。

Sure, you can do event planning with just text, but throw in a date picker gadget, RSVP gadgets and maps, and you've made planning that much more compelling. You can write your blog post drafts with just the native features of Wave, but after you throw in an approval gadget and blog post publishing robot, you've got a full blog post workflow in Wave, one that can be easily shared with your colleagues.

例えばイベントの企画を単に文章だけでする事も出来るけど、日付選択用のガジェットを貼りつけたり、RSVP用のガジェットや地図を付け加えたりすれば、それだけで企画がずっと魅力的なものになるでしょう。Waveのネイティブな機能だけを使ってブログの原稿を保存しておく事も出来るけど、投稿を承認する為のガジェットと実際にブログに投稿してくれるロボットを付け加れば、完全なブログ投稿システムが出来上がるわ。そしてそれを同僚達に使ってもらう事も簡単に出来るの。


なるほど、そう言う事だったのか。

- 内容のフォーマットが柔軟。
- 定型処理の自動化、システム化が出来る。
- 他人と簡単にシェア出来る。

という辺りがポイントになるのかな。

引用した部分に続いて、Waveを使って実現した2つの事例を紹介している。

- Google Waveのチーム内で、サーバーのサポート業務のシステム化をガジェットを組み合わせて行った例。
- 外部の開発者がWaveエクステンションをギャラリーに投稿してから一般公開されるまでのプロセスでのコミュニケーションをWaveで管理した例。


そして最後は、次の言葉で締めくくっている。

I hope that the ideas of Wave keep going, whether through other Google products or the ever-growing Wave open-source community, because I don't want to live in a world without them.

Googleの他の製品、あるいはどんどん大きくなって来つつあるオープンソースWaveのコミュニティを通してWaveの数々のアイデアが続いて行く事を願っています。だってそれらが無くなった世界でなんて生きたくないから。


Waveに対する愛情がひしひしと感じられる。
彼女の願う通り、Waveで培われたアイデアや技術はこれからも生かされて行くだろう。


追記:
早くもこんなのを作り始めている模様。
http://blog.pamelafox.org/2010/12/google-shared-spaces-why.html
http://blog.pamelafox.org/2010/12/google-shared-spaces-how.html

Waveのコードが25万行なのに対してShared Spacesはたったの5000行と言うのも面白い。







.

2010年12月26日

商品コードを主キーにするべきではない理由

リレーショナルデータベースのテーブルの主キーの設計については「ユニークになる項目だから必ず主キーにしないと行けない」というわけではなく、多くのDB設計者の間でも

- ID派(あえて別に自動採番のIDを付ける)
- コード派(ユニークになるものは出来るだけ主キーとする)

の2つに分かれる様だ。特に近年はRuby on Railsに代表される様に数値型の単一キーの存在を前提として作られているFrameworkが増えて来た事もあって、ID派の存在感が増しているらしい。

それぞれメリット・デメリットがあってどちらがいいのかはケースバイケースになるのかも知れないが、自分の場合はこれまでの業務システム開発の経験から、どちらかと言うと自動採番のIDを使う方がメリットが多いのではないかと思っている。やっぱりなんだかんだ言っても、「どうしてもこのマスターのコードを変えたいんだけど」と言われるケースが何度かあって、コードを主キーにしている場合に結構面倒な作業になってしまった事があるからだ。

ただ今回はあるプロジェクトにおいて「コード派」の技術者の方をやんわりと説得する必要があったので、「ID派」の根拠になりそうな情報を少し調べて見た。せっかくなので今回参考にさせてもらったサイトの引用とURLなどをまとめておこうと思う。

まずその前にひとつ思った事は、「主キーにする為にあえて付与したID」の事は「サロゲートキー(代理キー)」と言うよりも、「人工キー(Artificial Key)」と呼ぶ方がしっくり来る気がするという事だ。もちろん引用は原文のままにしておいた。


「サウスポーなSEの独り言 - テーブル設計」
テーブル設計上、どっちが良いか(…)ですが、私はお客様の要望が無ければサロゲートキーを採用します。
ナチュラルキーの代表的なものである顧客IDや社員番号、商品番号等は先程も書いたようにお客様(直接でなく間接的な意味も含め)が決めたものです。そしてその決め方、不変である保証はいつ(お客様の都合により)変わるともしれないのです。...

「ぼそっと - 人は何故PKに人工キーを用いるのか」
メリット
- 変更に強い
- 自然キーの場合、複合キーがめんどくさい
- 最近のデータベースアクセスソリューションもの(平たく言うと、広義の意味でのORM)と相性が良い
デメリット
- 関連が分かりづらい
- ベテランの技術者は自然キーに慣れている人が多く、なかなかコミットしてくれない
- 既存システムはまだまだ自然キーのものが多いので、他システム連携的なところとは相性が悪いことが多いくらいにしか思っておらず、ようするにビジネス的な変更がシステムに与える影響を小さくする、一種の粗結合的なものだと思うのですが、...

「@IT - システムの寿命はコードで決まる!」
業務で利用するコードをテーブルの主キーとして利用することは、コード体系とデータベース設計を独立させるという観点からできるだけ避けるべきです。...

「Life goes on - 楽々ERDレッスンを読んでいます」
アプリ側の視点からすれば、業務コードを主キーに使うような下のような設計はもうありえないと思います。(...)主キーには業務上で一意に識別されているコードではなく、意味もないIDを使いましょうというのが今の主流だと思います。...

「Hot Heart, Cool Mind. - 主キーの設計①」
これはかなり以前からある論争で、大雑把にいうとコード派とID派という二つの立場の間で戦われている。
コード派 ... ユーザの目に触れるデータ項目(典型的にはコード)を主キーとする。複合主キーを許す。
ID派 ... ユーザの目に触れないデータ項目(自動生成したID)を主キーとする。複合主キーを許さない。...

「A.R.N [日記] - ID or not ID」
たしかにDB直接見て何かするような運用だと、複合主キーの方がわかりやすかったりするのはたしか。でも複雑なシステムで他のテーブルへの関連が沢山あるような場合、いったいいくつ項目持てばいいのかわからないくらい項目が増える場合がある(まぁ大半は設計が悪いだけだったりするのだけど、ID派の立場を取ればそもそもそのような状況はおこらないことを考えれば欠点には違いない)。
個人的には、複合主キーだとマスタに履歴を持つようなケースで変な主キーを選択しなければならなかったり、主キーを更新せざるを得ない場合があって気持ち悪いので、ID派ではあるけど、絶対にIDじゃなければダメだということを説得できるだけの論点が見出せないのが実情。...

「DBFlute - サロゲートキーと複合主キー」
ナチュラルキーをPKにするということは、業務に直結していて実装上でも直感的でありながら、 直結しているがために業務の変更の影響をもろに食らうということにつながります。確かに変更が発生するのは仕方のないことではありますが、 その影響は最小限にしたいものです。そのためには、テーブル間の依存関係を薄くすることが重要です。
サロゲートキーを導入することで、テーブル間の依存度合いは減り、業務変更のインパクトも(何もしない状態よりは)少ないものになります。 複合主キーの場合の方が効果は顕著ですが、単一キーでも同じ話です。例えば、ExampleDB の商品テーブルは、単一のナチュラルキーである商品ハンドルコードでユニークですが、商品IDというサロゲートキーを利用しています。 商品ハンドルコードは、業務で利用する値であり、業務変更でコード値の構成変更が発生する可能性があると想定したものです。

2010年12月13日

AndroidでiPhoneに匹敵する楽器アプリの作成が困難な理由

Androidでも楽器アプリが出ているけど、試してみるとどれも今ひとつ反応が鈍い、というか画面をタップしてから実際に音が出るまでにタイムラグがあるのがはっきりと感じられる。

iPod Touchだとほとんどタイムラグは感じられないので、この差は何なんだろうと気になった。Androidの仕様上の制限なのか、アプリに原因があるのか。。。

自分でも音楽関係のアプリはいつか作ってみたいリストに入っているので、Androidで任意の音を自由なタイミングで鳴らす方法を調べて見た。Google検索で一応大雑把な所は分かったので、とりあえずメモしておこう。

以下、自分でコーディングして試した結果ではないので「~らしい」「~みたい」ばかりになって恐縮ですが。

Androidで音を鳴らす方法


下の4つの方法があるとの事。それぞれ向き不向きがあるみたいだが、「リアルタイムで任意の音を鳴らす」という用途にはどれもいま一つらしい。(少なくともタイムラグを無くすのは困難みたい。)

1. MediaPlayer

予め作成された音楽を鳴らすのに向いている。
MIDIファイルの演奏も可能。ただしメモリ上に動的に生成されたMIDIデータを演奏させる事は出来ない。一旦一時ファイルに保存する必要がある。

2. JetPlayer

「JetCreator」というツールを使って予めMIDIデータから「JETファイル」という形式に変換しておくと、そのファイルの任意の部分を演奏させる事が出来る。ゲームの効果音などを出すのに向いている様だが、楽器アプリとして自由な演奏をするのにどこまで向いているかは、試して見ないと何とも言えない。
hidecheckの日記 - AndroidでmidiとかJetCreatorとかで鍵盤アプリとか作成
3. SoundPool

MIDIではなくOGGやWAVなどのサウンドファイルを使った効果音を再生出来る。
しずくくんのAndroidでゲームプログラミングしてみたいなblog
むずかしいことはわかりません。

(2011/05/11 追加)
SoundPool使用上の注意点 - Hacking My Way ~ itogのhack日記
4. AudioTrack

PCMデータを直に操作して音を鳴らす場合に使う。(実は良く分からない。^^;)下のソースコードとかを見ると面白そうではあるけど、楽器の音を作るのはかなり大変かも。
にュウさいと - AudioTrackを使う
Androidアプリ開発 / 夢見る少女の開発メモ - 音を作ってみる

(2011/05/11 追加)
たいてい自宅で迷想中 AudioTrackをAudioQueueのように使う

さらに英語でも検索して見た。


英語だと結構核心に踏み込んだ(と思われる)情報があった。
Umito - The state of MIDI support on Android

Stack Overflow - Dynamic Midi generation and playback on Android: Possible?

Google Code - Expose Midi Streaming capability of Sonivox Synthesizer.

Pragmatic Bookshelf - Java SE5 javax.sound (MIDI) classes removed from Android libraries?
やっぱりMIDI音源に対して直接リアルタイムでコマンドを送信する為のAPIが用意されていないというのが致命的なようだ。


現時点での結論(Android 2.2以下の場合)


で結局、今の所はこちらに書いてある通りAndroidの仕様上の理由からiPhoneに匹敵するようなレスポンスの良い楽器アプリを作るのはかなり厳しいようだ。
【combuのDTM & ミキシング 】 脱初心者を目指す音楽制作 - DTMやるならAndroidを買ってはいけない





2/21/2011 追記:
Android2.3, 2.4とか3.0が出てきたので、現在は状況が変わっているかも知れない。
変化がめまぐるしいので最新情報を追いかけるのも大変だ。。。



10/21/2011 追記:
Android 4.0でもまだ改善されていないみたいだ。
Android 4.0で反応の良い楽器アプリは可能になるのか



11/20/2012 追記:
4.2になって少し改善されたみたいだ。

Android 4.2で今度こそ反応の良い楽器アプリは可能になるのか!?


10/25/2013 追記:
最近はこんな感じらしい。
このレイテンシー、Nexus10はDTM用途に使えるかも!? : 藤本健の“DTMステーション”