FoxさんがWaveについてブログに書いている。http://blog.pamelafox.org/2010/12/why-i-loved-wave.html読んでみて、今まで自分はWaveについてちゃんと理解していなかったんだなぁと思った。Waveの本質ってなんだろうか。them.Waveは柔軟で汎用的なプラットフォームで、グループの掲示板、日記帳、イベントの感想ノート、アンケートなどが出来るの。これらの事が出来る個別のソリューションはこれまでにもあったけど、全部の事が出来る単一のソリューションと言うものは存在しなかったわ。became.私がWaveを好きなのは、ひとつのトピックを開始したら、それが徐々に単なる質問からディスカッションに変わったり、さらに写真アルバムになったり(私が髪の色をどうしようかってみんなに尋ねた時みたいにね)、それら全部の組み合わせに発展したりするからなの。最初から「どんな風にしようか」って考えたり注意深く別の選択肢を検討したりしないと行けない訳じゃなくって、単にwaveを作ってそれがどうなって行くか見ればいいのよ。colleagues.例えばイベントの企画を単に文章だけでする事も出来るけど、日付選択用のガジェットを貼りつけたり、RSVP用のガジェットや地図を付け加えたりすれば、それだけで企画がずっと魅力的なものになるでしょう。Waveのネイティブな機能だけを使ってブログの原稿を保存しておく事も出来るけど、投稿を承認する為のガジェットと実際にブログに投稿してくれるロボットを付け加れば、完全なブログ投稿システムが出来上がるわ。それを同僚達に使ってもらう事も簡単に出来るの。内容のフォーマットが柔軟。定型処理の自動化、システム化が出来る。他人と簡単にシェア出来る。いう辺りがポイントになるのかな。引用した部分に続いて、Waveを使って実現した2つの事例を紹介している。Waveのチーム内で、サーバーのサポート業務のシステム化をガジェットを組み合わせて行った例。外部の開発者がWaveエクステンションをギャラリーに投稿してから一般公開されるまでのプロセスでのコミュニケーションをWaveで管理した例。最後は、次の言葉で締めくくっている。them.Googleの他の製品、あるいはどんどん大きくなって来つつあるオープンソースWaveのコミュニティを通してWaveの数々のアイデアが続いて行く事を願っています。それらが無くなった世界でなんて生きたくないから。Waveに対する愛情がひしひしと感じられる。彼女の願う通り、Waveで培われたアイデアや技術はこれからも生かされて行くだろう。追記:早くもこんなのを作り始めている模様。Spacesはたったの5000行と言うのも面白い。コード派(ユニークになるものは出来るだけ主キーとする)の2つに分かれる様だ。Railsに代表される様に数値型の単一キーの存在を前提として作られているFrameworkが増えて来た事もあって、ID派の存在感が増しているらしい。それぞれメリット・デメリットがあってどちらがいいのかはケースバイケースになるのかも知れないが、自分の場合はこれまでの業務システム開発の経験から、どちらかと言うと自動採番のIDを使う方がメリットが多いのではないかと思っている。かんだ言っても、「どうしてもこのマスターのコードを変えたいんだけど」と言われるケースが何度かあって、コードを主キーにしている場合に結構面倒な作業になってしまった事があるからだ。今回はあるプロジェクトにおいて「コード派」の技術者の方をやんわりと説得する必要があったので、「ID派」の根拠になりそうな情報を少し調べて見た。今回参考にさせてもらったサイトの引用とURLなどをまとめておこうと思う。Key)」と呼ぶ方がしっくり来る気がするという事だ。引用は原文のままにしておいた。テーブル設計」テーブル設計上、どっちが良いか(...)ですが、私はお客様の要望が無ければサロゲートキーを採用します。先程も書いたようにお客様(直接でなく間接的な意味も含め)が決めたものです。その決め方、不変である保証はいつ(お客様の都合により)変わるともしれないのです。業務で利用するコードをテーブルの主キーとして利用することは、コード体系とデータベース設計を独立させるという観点からできるだけ避けるべきです。ERDレッスンを読んでいます」アプリ側の視点からすれば、業務コードを主キーに使うような下のような設計はもうありえないと思います。(...)主キーには業務上で一意に識別されているコードではなく、意味もないIDを使いましょうというのが今の主流だと思います。主キーの設計1」これはかなり以前からある論争で、大雑把にいうとコード派とID派という二つの立場の間で戦われている。ユーザの目に触れるデータ項目(典型的にはコード)を主キーとする。ユーザの目に触れないデータ項目(自動生成したID)を主キーとする。複合主キーを許さない。ID」たしかにDB直接見て何かするような運用だと、複合主キーの方がわかりやすかったりするのはたしか。複雑なシステムで他のテーブルへの関連が沢山あるような場合、いったいいくつ項目持てばいいのかわからないくらい項目が増える場合がある(まぁ大半は設計が悪いだけだったりするのだけど、ID派の立場を取ればそもそもそのような状況はおこらないことを考えれば欠点には違いない)。個人的には、複合主キーだとマスタに履歴を持つようなケースで変な主キーを選択しなければならなかったり、主キーを更新せざるを得ない場合があって気持ち悪いので、ID派ではあるけど、絶対にIDじゃなければダメだということを説得できるだけの論点が見出せないのが実情。直結しているがために業務の変更の影響をもろに食らうということにつながります。その影響は最小限にしたいものです。そのためには、テーブル間の依存関係を薄くすることが重要です。サロゲートキーを導入することで、テーブル間の依存度合いは減り、業務変更のインパクトも(何もしない状態よりは)少ないものになります。複合主キーの場合の方が効果は顕著ですが、単一キーでも同じ話です。商品テーブルは、単一のナチュラルキーである商品ハンドルコードでユニークですが、商品IDというサロゲートキーを利用しています。商品ハンドルコードは、業務で利用する値であり、業務変更でコード値の構成変更が発生する可能性があると想定したものです。共有2010年12月13日AndroidでiPhoneに匹敵する楽器アプリの作成が困難な理由Androidでも楽器アプリが出ているけど、試してみるとどれも今ひとつ反応が鈍い、というか画面をタップしてから実際に音が出るまでにタイムラグがあるのがはっきりと感じられる。Touchだとほとんどタイムラグは感じられないので、この差は何なんだろうと気になった。Androidの仕様上の制限なのか、アプリに原因があるのか。自分でも音楽関係のアプリはいつか作ってみたいリストに入っているので、Androidで任意の音を自由なタイミングで鳴らす方法を調べて見た。Google検索で一応大雑把な所は分かったので、とりあえずメモしておこう。以下、自分でコーディングして試した結果ではないので「~らしい」「~みたい」ばかりになって恐縮ですが。下の4つの方法があるとの事。それぞれ向き不向きがあるみたいだが、「リアルタイムで任意の音を鳴らす」という用途にはどれもいま一つらしい。(少なくともタイムラグを無くすのは困難みたい。MediaPlayer予め作成された音楽を鳴らすのに向いている。MIDIファイルの演奏も可能。メモリ上に動的に生成されたMIDIデータを演奏させる事は出来ない。一時ファイルに保存する必要がある。JetPlayer「JetCreator」というツールを使って予めMIDIデータから「JETファイル」という形式に変換しておくと、そのファイルの任意の部分を演奏させる事が出来る。ゲームの効果音などを出すのに向いている様だが、楽器アプリとして自由な演奏をするのにどこまで向いているかは、試して見ないと何とも言えない。SoundPoolMIDIではなくOGGやWAVなどのサウンドファイルを使った効果音を再生出来る。しずくくんのAndroidでゲームプログラミングしてみたいなblogむずかしいことはわかりません。AudioTrackPCMデータを直に操作して音を鳴らす場合に使う。(実は良く分からない。^^;)下のソースコードとかを見ると面白そうではあるけど、楽器の音を作るのはかなり大変かも。AudioTrackをAudioQueueのように使うさらに英語でも検索して見た。英語だと結構核心に踏み込んだ(と思われる)情報があった。libraries?やっぱりMIDI音源に対して直接リアルタイムでコマンドを送信する為のAPIが用意されていないというのが致命的なようだ。2.2以下の場合)で結局、今の所はこちらに書いてある通りAndroidの仕様上の理由からiPhoneに匹敵するようなレスポンスの良い楽器アプリを作るのはかなり厳しいようだ。2.4とか3.0が出てきたので、現在は状況が変わっているかも知れない。変化がめまぐるしいので最新情報を追いかけるのも大変だ。4.0でもまだ改善されていないみたいだ。追記:4.2になって少し改善されたみたいだ。追記:最近はこんな感じらしい。今日、社内の勉強会を開催した。一応主催者という事で内容の企画とメインのプレゼンテーションは自分で行った。(デモ作成・プレゼンは別の人にしてもらった)その他IT関連で気になったニュースなどと言った感じで、かなりGoogleのサービスに偏った内容だった。(まあ一応意図的にGoogle特集的にして見たのだけど。)個人的にはAppEngineのデモに力を入れたかったけれど、準備があまり出来なくて結局ほんの触りの部分だけで、中途半端な印象になってしまったかも知れないとちょっと反省している。普段うちの会社ではASP.NET(VB)での開発が多いのでJavaでのデモにはみんなあまり興味を惹かれなかったかも知れない。それだけにもう少しデモアプリの内容を面白くすれば良かったかも知れない。次回はもっとしっかりと準備をしようと思う。それにしても思うのは、規模はどうであれ勉強会でのプレゼンテーションというのは大変だけども、やっぱりやれば他の誰の為でもなく最も自分の為になるという事。準備段階で考えを整理出来るし、技術的な事も人に説明する為に調べていると自然に頭に残る様になる。話したいネタは山ほどあるので、これからも続けて行きたい。共有2010年11月30日Androidアプリの開発。この本を買おうかどうか思案中。Amazonに誰かレビュー書いてくれないかなー。初歩からわかるAndroid最新プログラミング実はもう他にも結構Androidの本は買い込んでいるのに、結局サンプルを軽く弄る程度の事しか出来ていない。マーケットに公開出来る様なアプリが作れるのはいつになる事やら。始めるなら今しかない様な気がして、結構焦ってはいるんですが。会社では今の開発プロジェクトが大忙しだし、家に帰れば帰ったで2人の子育てで手一杯だし、一体どうすればいいのかな。新しい開発マシン新しい開発マシンを購入した。今回は予算に限りがあるながらも出来る限り最強スペックを目指してオーダーした。DELLかHPかでちょっと迷ったけど、僅差でHPを選んだ。HPにはドライブにSSDを選べるオプションがあったのにDELLのデスクトップには無かったからだ。自分で後付けすれば問題無いのだけど、最近はいちいちハードウェアの事に時間をとられるのが面倒になって来た。そんな時間があれば新しい技術の勉強とそれを使った開発の時間に充てたい。一日が30時間あったとしてもまだ足りない感じがする日々なのだから。これで税金・送料込みで約2200ドル。64bit版のWindows7がプリインストールされているけど、それだとおそらく諸々の32bitのライブラリとかコンポーネントとかが動かないので、Linux+KVMで32bit版Windows仮想マシンを動かして開発環境を用意しようと思っている。前に削除してしまった事を思い出した。最初から開発環境の作り直しだな。今回一番興味があったSSDのパフォーマンス。CrystalDiskMark3.0で測ってみた所、シーケンシャル・リードで290MB/s以上が出ている。500GBのHDDの方が大体178MB/sだから、約1.6倍のパフォーマンスだ。ランダムアクセスだともっと差が出るはず。(2)Androidアプリの開発。