def.rem

祝! iPhone 3GS!!

2009-07-01T20:15:00.001+09:00

Mac Pro と同様満を持しての iPhone 購入。

iPod touch より若干重たくなったものの、携帯が不要になった点が非常によい。
後は動作速度の向上、カメラ、ビデオ、ボイスレコーダー、GPS などハードウェア機能の充実が日々の不便を色々と解消してくれそう。

さて、ソフトウェア開発を本格的に始めねば。

UIViewController Class Reference

2009-06-21T11:13:00.001+09:00

今回は iPhone のプログラムのために必要なリファレンス情報を翻訳する。
Java などはその初期から日本語訳された API ドキュメントが存在していたが、英語がメインのこの業界では今更ながら希な例であることを認識する。なお、翻訳は少しずつ追加していきたい。

原文「UIViewController Class Reference」2009-06-17

概要

UIViewController クラスは、基本的なビュー管理モデルを iPhone アプリケーションに提供する。基本ビューコントローラクラスは、モーダルビューと装置の方向変化に応じて回転するビューを管理する基本的なサポートに加えて、関連するビューの表示をサポートする。UINavigationControllerと UITabBarController のようなサブクラスは、ビューや複雑で階層的なビューコントローラを管理するためにさらなるふるまいを提供する。

フルスクリーンのビューを管理するために、UIViewController の各々のインスタンスを使う。単純なビューコントローラのために、アプリケーション内容を表示することに対して責任がある表示階層を管理することを伴う。典型的なビュー階層は、このクラスのビュープロパティが有効になっている参照ルートビューと１つ以上の当面の内容を表示するサブビューから成り立つ。ナビゲーションとタブバーコントローラの場合、ビューコントローラは、ナビゲーションコントロールを提供している高水準ビュー階層だけでなく、アプリケーション内容の表示をハンドリングする１つ以上のさらなるビューコントローラも管理する。

注意：そのウィンドウの一部分だけ（すなわち、アプリケーション内容の長方形によって定義された領域の一部分だけ）を埋めるビューを管理するために、ビューコントローラを使うべきではない。いくつかの小さなビューを構成してインターフェイスを使う場合、全てを１つのルートビューに埋め込んでビューコントローラで管理する。

ビューコントローラーはそれが管理するビューと密接に関係しているため、それらはまたイベントをハンドリングするための応答連鎖の一部である。ビューコントローラーはそれ自体 UIResponder クラスの継承クラスであり、管理されたビューと親クラスのビューとの間に応答連鎖が挿入されている。そのため、ビューコントローラーによって管理されているビューがイベントをハンドリングしない場合は、そのイベントをビューコントローラーに受け渡す。その際にビューコントローラーには、イベントをハンドリングするかそのビューの親のビューにイベントを受け渡すかの選択権がある。

UIViewController クラスは、装置の方向変化に応じて、そのビューコントローラーのビューを回転することを自動的にサポートすることを提供する。自動的な方向変化のふるまいの一部として、ビューコントローラーはビューの外部のタブ・バーやナビゲーション・バーをスライドしたり、隠れているビューを変化させたり、バーの背景をスライドする。ビューの自動的なリサイズのプロパティーが既に設定されている場合、このふるまいは本来は制約がない。しかし、同様に実行させたい追加のアニメーションを指定することによって、方向変化のふるまいをカスタマイズできる。

ビューコントローラーは大半の iPhone アプリケーションのデザインの基礎となっている。これ以降のセクションでは、UIViewController クラスのメソッドやプロパティーを使用するための基本的な情報を提供する。アプリケーションのユーザーインターフェースを管理、構築するためにビューコントローラーを使用する際の追加情報として、『iPhone OS のためのビューコントローラー・プログラミングガイド』を参照する。

幻想曲風ソナタ Op.27

2009-05-31T10:53:00.001+09:00

今回は「月光」として知られるベートーヴェンの名曲を取り上げる。

「月光」は実際は連作の一部で、「幻想曲風ソナタ」作品２７の２として作曲されたものである。
また「月光」という標題もベートーヴェン自身が付けたものではなく、死後に同時代の詩人によって付けられたものだ。
確かに「幻想曲風ソナタ２番」や「作品２７の２」などと呼ぶよりもその曲をイメージしやすいし、記憶にも残る。
ただそのイメージ対象は、３楽章全体というより第１楽章に限定されている点で、曲全体を表したものだと思うと誤解を招く。

作品全体を通して聴いてみると、「幻想曲風ソナタ１番」は２番との関連性を見出すのが難しいほど曲調が異なる。
昨年 Leif Ove Andsnes のリサイタルに行った際に、プログラムで行われた「２番」に対してアンコールでこの１番が演奏されたのだが、その時はまだ聴いたことがなかったため、演奏前に「ベートーヴェン」と奏者自身が言っていたものの、なぜこの曲が？という感想しかなかった。抑え気味ながら全体を通して明るく軽快な曲調は、続く陰鬱で感情的な２番とはまるで似つかわない、平穏な時間が流れている。

そして２番は「月光」という標題も影響してか、非常にゆっくりとしたテンポでシンプルな和音が刻まれる。
第１楽章だけで聴いてみると、確かに「ルツェルン湖の月光の波に揺らぐ小舟のよう」というイメージにも納得するのだが、第２、第３楽章はそのイメージからはほど遠く、自分がイメージする限りでは第１楽章は「しめやかな小雨」、第２楽章は「つかの間の晴れ間」、そして第３楽章は「急転の嵐」という感じだった。雨の風景描写としての一貫性がそこにはある。

ただ、こうした一般的な自然描写のイメージに対して、そうではない解釈もある。

「月光」はピアノ・ソナタとして最も好きな曲であるため、何人もの演奏者のＣＤを持っているのだが、その中でも András Schiff の演奏は衝撃的だった。テンポが非常に速く、通常第１楽章に 5 分 30 秒〜6 分 30 秒程度かかるところ、たったの 4 分 30 秒にまとめているのである。Schiff 自身はその解説で、「むやみに詩的になることは避け、リストの風景画よりはバッハの前奏曲を思う方が有益でしょう」と語っている。バッハの前奏曲がそう意図しているかどうかは分からないが、確かにこうした方が自然描写というよりも、悶々とした人間の感情をよく表現しているように思った。もともと伯爵令嬢であったジュリエッタ・グイチャルディに捧げるために作曲されたものということや、第３楽章にかけての感情の高ぶりといったものが、この構成によってよく分かる。

よく「女心と秋の空」という言い方をするが、人間の感情と自然描写は近い関係にあるということだろう。
絵画における自然描写にしても、実際はそれを描いている描き手の心理を表現していたりするものだ。
音楽の場合、それが演奏者の解釈で表現できる点が面白い。
テンポを遅くすることで自然描写が可能になる点は、自然の方が人間より大きな時間で流れていることを感じとっているためだろう。
たったそれだけのことで人間の感情をより普遍的、一般的なものに昇華させ、それは万人の共感を得ることに繋がる。

たったそれだけのこと、といったが、名曲だからこそそれが可能なのかも知れない。
クラシックが聴き継がれる理由のひとつがここにあるように思う。

自然描写の一枚

人間描写の一枚

Still Alive, Never be Zombie!

2009-05-20T21:20:00.001+09:00

『より効果的な学習を行うための 10＋のティップス』

１回の学習時間よりも頻度の方が重要である
受動的な態度ではなく、能動的な態度で学習する
自分自身の経験に結びつける
既存の知識を利用する
学んだ知識を実際に使う
学んだことを教える
学んだ結果を誰かに見てもらう
現実的な目標を設定する
ただ読むのではなく、メモをとる
学んだことについて書籍を執筆する
iPodを活用する
ものごとを細分化する

1〜4 は脳の特性の生かし方。5〜10 は効果的なフィードバックの受け方。
11、12 がティップス。

学習の入り口として１がなければその後が続かない点で、１が最も重要であると思う。
重要であるが故かどうかは分からないが、最も実践が困難なのも１である。
（10 は内容的に他との重複があり、著者の自慢気によるものと推測する）

ただ、一度習慣にしてしまえばその後の困難さはなくなる。
まだまだ習慣の域にまでは達していないが、兎に角５分でも３分でも定期的に行うことが大切だ。
始めるまでのハードルが心理的に一番高い。ながら始めが効果的だと思う。

量産型の自分

2009-05-16T11:21:00.001+09:00

『自分と同じものをつくりたい業』

ITmedia で「人とロボットの秘密」という連載が始まった。

まだ前書きの段階だが、ダヴィンチに関する解釈など早速興味深い内容だった。
ダヴィンチが自ら人体解剖を行っていたことについては有名な話だが、なぜ子宮や胎児の解剖まで行っていたのかこれで理解できた。
絵を描くという行為も自然科学と同様に、造物主である神のメッセージを理解することであり、人間を描くにはその全ての仕組みを明らかにしなければならないと考えていたようである。

彼が書き残したテキストでは、腕を描くのならば骨を知り、筋肉を知り、それらの結合と分岐を知る必要がある。そして人の形を知るためには子宮や胎児、どのようにして人間がこの世に宿るかというところから、理解する必要があると記され、そして次のような言葉が語られている。

われわれの造物主は、私がその形態を描くという方法で人間の性質、さらに進んでその風習も明らかならしめることを嘉し給うに違いない。（杉浦明平訳）

また、心と体に関する最近の日本人研究者の仮説についても面白い。

たとえば、知能とは実体ではなく、コミュニケーションが行われている際に観察される「現象」であるという指摘。
あるいは人間の意識は実はなにも決めていない。実は意識とは「結果」なのであるという意識のモデル。
あるいは機械の中に、生物のDNAに相当するものを持たせようとする設計論。
あるいは人間の情動を微分で記述してしまう方程式など。

今回のタイトルは手塚治虫の言葉の引用であるが、これについても知らなかった。
押井守の「イノセンス」やロボット観はそういう大きな下地の上に再構成されている。

自らの再構成を模索することは、結局人間とは物質に還元されるロボットなのか。
あるいは「神」という超物質的な存在なのかを見極めたいということなのだろう。

これで物質に還元され再生産、あるいは大量生産できるという結論に至った場合はどうなるのか？
少なくとも「人の命は地球より重い」などと発言する人は確実にいなくなるだろう。

Hello, iPhone!

2009-05-14T00:55:00.003+09:00

無事に iPhone Developer Program の登録が完了したため早速アプリを作成してみた。

アプリ自体は Developer Program に登録しなくても作成可能だが、やはり実機で動かせるという魅力は捨てがたい。
参考書は『サンプルプログラムから学ぶ iPhoneSDK プログラミングガイド初版』（酒井祐司：著）だ。
この本に記載されている最初のサンプルプログラムを少しいじって、シンプルなカウンターソフトとしてみた。

送信者 def.rem

こういったサンプルプログラムを元に作成する場合、本に記載している通りには作成しないことが効果的だ。プロジェクト名やクラス名、変数名といった命名レベルでも、ロジックレベルでも構わない。とにかくまるっきり同じにしないことによって、想定外のつまずきが発生し、そこから多くのフィードバックを得られることが多い。

自分の場合は変数をカウントアップするため、文字列を数値化しようとしたのだが、たったそれだけのことが中々上手くいかなかった。

まず文字列を数値化する手段が分からない。これについてはコード補完機能によって NSString クラスのメソッドに intValue メソッドがあることがすぐに分かった。ここら辺は Java＋Eclipse と殆ど変わりがないものの、リストの候補が大量に表示される点で余り補完機能の意味合いをなしてないと感じた。intValue をすぐに見つけられたのは、Java の API 利用の経験から類推できたからだ。

IDE によるこういったサポートが難しい点は、実行時に型付けを行う動的言語の弱点の一つである。

送信者 def.rem

次に数値化した値をカウントアップまたはカウントダウンし、再び文字列化する手段がまた分からない。あれこれと型のキャストを行ってみてもダメで、結局 Web 検索でそういう場合は NSNumber を使うということが分かってすんなり解決した。ここら辺も Java の Number クラスと良く似ている（実際は NSNumber クラスの方が誕生は早いと思うが）。

数値化、文字列操作に関わる API は、プログラミング上最も良く使うことになる部分である。
今回実際に Objective-C のプログラミングをすることによって、多少なりともその言語を理解できたのが収穫だった。

以下のコードはこのソフトウェアのメインロジックｗ

- (IBAction)doCountUp:(id)sender {
　　NSNumber *wrappedInt = [NSNumber numberWithInt:[[label text] intValue] + 1];
　　[label setText:[wrappedInt stringValue]];
}
- (IBAction)doCountDown:(id)sender {
　　NSNumber *wrappedInt = [NSNumber numberWithInt:[[label text] intValue] - 1];
　　[label setText:[wrappedInt stringValue]];
}

ソフトウェアの本質とは

2009-05-09T00:43:00.030+09:00

「HMDT」の木下さんのインタビュー記事に触発された。
『木下誠氏インタビュー。HMDT流iPhoneアプリ開発とビジネス。』

この中で木下さんは以下のように言っている。

プラットフォームを理解してもらいたい。iPhone アプリ開発において、たまに聞かれる質問や話題として盛り上がるものとして「別の言語で iPhone アプリ作れますよね。」「Java で作れますか？」というものがあります。Objective-C、Cocoa Touch、これらのシステムを支える仕組みの理解を放棄しています。自分が取り組むプラットフォームなのだから逃げないで正面から理解してほしい。サービスの利用者のことを考えたらプラットフォームに対して最適なことをするのが当然かと思います。

ある意味格好がいい言葉だ。
いかにも技術力満点、どんなプラットフォームでも、言語でも、優秀なプログラマーであれば可能だろう？といわんばかりの勢いだ。

確かに iPhone はハードウェアとしての魅力がある。今はまだ持っていないが、自分もそのうち買うことになるだろう。iPod touch は既に持っているし、何よりもマカーだからだｗ。ただ、ハードウェアや独自のプラットフォームに合わせて、その仕組みを覚えることを強制するのはいかにも時代錯誤という気がする。現状 Objective-C などというマイナー言語を使用しているのは Apple ぐらいのものだ。そんな他に使い道のない言語を誰が覚えるだろう。いくら美しい言語だろうと、話されなければその言語に価値はない。

その昔ソフトウェアがハードウェアのおまけと言われていた時代のように、特定のハードウェアでしか動かないプログラム作成を強要されることほど馬鹿なことはない。ハードウェアの仕様の変更に合わせて、プログラムの修正を強要され、実装方法を強要される。いわばプログラマーはハードウェアの奴隷状態だ。

そんな奴隷状態からソフトウェアの解放を成し遂げたのが Java である。仮想マシンという媒介層をハードウェアとの間に構築して、そのくびきからソフトウェアを解き放った。「Java で作れますか？」という問いかけはオープンなマインドを持つプログラマーであれば至極当然のことだ。実際 iPhone の競合となり得るだろう Google の Android プラットフォームはこの発想の延長線上にあり、完全ではないものの Java を利用している。Android の原点には Java と同じように、使い捨てのように世代交代する携帯というハードウェアから、ソフトウェアを解放するという目的があるためだ。

と、ここまで反論のような形で書いてきてちゃぶ台をひっくり返すわけではないが、先日 iPhone Developer Program に申し込んだ。噂通りの酷い手続きだったが、それはまた別の機会に取り上げることにして、

結局、ソフトウェアの本質とは何なのだろうか？

自由を得た代わりに汎用的・抽象的で面白味のないものになっていくプログラミング。
片や魅力的なハードウェアを操作可能だが、他では使うことのできないソフトウェア。
Android であればあるいは解決が可能なのかも知れない。

今は趣味として iPhone Developer となり、自分なりにもう少し試行錯誤してみたい。

Software in the Wetware

2009-04-27T00:02:00.018+09:00

「安藤日記」でも紹介されている『リファクタリング・ウェットウェア』を購入した。

まだ始めの数章しか読めてないけど、『The Pragmatic Programmer』（邦題「達人プログラマー」）の著者の一人だけあって、「実践」に重きを置いている点は好感できる。

この業界、UML や MDA、CMMI などファッション業界なみに「モデル」が持て囃されるきらいがあるけど、そのモデルが往々にして一人歩きをし始めるという点には大いに納得が行く。CMMI なんてその最たるものだろう。

レベル取りのために使いもしないドキュメントを作成し管理運用する。本来「ツール」であるはずのモデルが目的となるバカバカしさ。まあ、目的を格付けのためと割り切ればよいのだろうが、本来ソフトウェア開発とは何の関係もない。ソフトウェアが大量生産できる工業製品のように扱えるのであれば話が違ってくるのかも知れないが、そのように扱おうとしてきて、この数十年未だに成功していないという現実がある。

ハードウェア、工業製品は基本的に大量生産が可能だ。本質的に物質の組み合わせで構成できる以上、人手を省くほど規格化され均一化したものが生産できる。だがソフトウェアは現状、人間の思考＝「ウェットウェア」からしか生み出すことができない。本質的にウェットウェアの組み合わせで構成される以上、個々のウェットウェアを省くことはできず、改善＝「リファクタリング」することでしかソフトウェア開発をより良いものにできない。

今までは組み合わせといった観点から組織論的方法論が多かったが、結局は個々人のレベルを上げることの方がソフトウェア開発には効果的なのかも知れない。

ただ、よく言われるように「達人プログラマー」は初心者に比べて生産性がウン十倍といった議論がされるが、本書にもあるように「達人」の域に到達できるのはほんの数％の割合に過ぎない。これが現実であるならば、「達人プログラマー」となることを前提に「リファクタリング」することなどは到底実践的とは言えない。

「実践」可能な内容であることを期待しつつ、業務に役立つヒントを探して行きたい。

Oracle Eats Sun!

2009-04-21T01:45:00.006+09:00

2009/04/20 は業界として歴史的な一日となるはずだ。

仕事中にこの速報をみて思わず絶句してしまった。既にエントリとしても挙げているが、当初は IBM に買収されるという話が専らだった。それが Oracle である。

Oracle 自体は現在のプロジェクトでも使用している主要な外部ソフトウェアだ。
というより、そこそこ大きな企業向けのソフトウェアであれば Oracle は標準と言ってもいい存在である。いわば企業向けソフトウェアの Microsoft 的存在である。そういった存在が Sun を、Java を飲み込んだのである。絶句した理由はそこにある。

Oracle も Microsoft もソフトウェアの基幹部分を握り発展してきた。そしてその発展の過程で様々な企業買収を繰り返してきた。両者ともその基幹部分を握るが故に、最初から勝利が約束されているような競争の中で巨大になってきたに過ぎない。そしてその買収が単純に競争相手だったものを自社に取り込む以上の成果をみせていないために、絶句するのだ。
PowerPoint、Visio、SQL Server しかり。BEA WebLogic、Berkley DB しかり。

まあこの点は IBM も似たり寄ったりだが、まだソフトウェアの理念であるオープンソースの活動に功績がある。Eclipse や Jazz はその成果である。

Oracle が Java をどのように用いるかは分からない。もともと技術を育てるというイメージが Microsoft と共に薄いため、PL/SQL の後継言語的な扱いをされないか心配だ。
より心配なのは MySQL の方だが、こちらは直接的に競合している以上 Java よりも悲壮だ。

桂枝雀

2009-04-08T00:07:00.010+09:00

テレビをみていたら桂枝雀がこんなことを言っていた。

「自分のことばかりを思っていたら、自分を滅ぼす」
「他人のことを思うことが、自分を思うことになる」

鬱病を患っていたという経験からくる言葉の含蓄もあるが、本人はその死まで遂に鬱病を克服できなかったようだ。

聞いた当初は「なるほど確かに」と思う部分もあったのだが、こういった言い回しにどこか違和感を感じる自分もいた。
「他人のため」「家族のため」「子供のため」。〜のため、と色々と理由は付けてみても、結局は自分を隠すオブラートに過ぎないのではないのかと。

桂枝雀は、今までは自分にあう仕事を選り好みしてきたが、他人のことを思うならばなんでもござれで仕事をしなければならない、というような発言もしていた。それも極端な話だと思う。面倒な自我を捨て去って、聖人よろしく他者の視点から自分をみることで自分をより良く生かすということなのだろうが、自分という存在が消せる訳でもないし、結局は上でも言った「他者からの視点」というものに擬態した自分からの逃避に過ぎないのではないか。

社会通念上「他人のため」という言葉は非常に耳障りがよい。「自己犠牲」も同じようにもてはやされる概念だ。
ただ、それらがもてはやされる理由も同じように考えなければならない。

Closures for Java

2009-04-06T23:01:00.029+09:00

最近 IBM による Sun の買収話が盛り上がっているが、正直 Java の将来性を考えると IBM に買収された方がいいんだろうなと思う。

IBM の巨大企業というイメージからくる「帝国」的イメージと、Sun のオープンソース戦略からくる「同盟軍」的イメージからすると必ずしも良く思えないが、Java を育て、商売としても確立してきたのは明らかに IBM の方だと思うからだ。

Java のオープンソース化を求めてきたのは IBM だったし、ハードウェア企業からソフトウェア企業として脱却するためのインテグレーション・ソリューション・サービスの中核は、「WebSphere」という Java EE アプリケーション・サーバーだ。

そして、Java の普及に大きく貢献してきたのが言わずと知れた「Eclipse」である。Eclipse は元々 IBM の「VisualAge」という IDE 製品群から生まれたもので、1.0 の頃からインターフェイスの秀逸さと SWT を用いた軽快さ、にもかかわらず無料で使用できる点で幅広い開発者の支持を集めてきた。

っと、タイトルにもあるように当初クロージャの話に持って行くつもりだったが、長くなりそうなので次の機会に。

以下はリンク集。

http://journal.mycom.co.jp/news/2008/12/17/031/
・Java 7 は OpenJDK をベースにして登場するメジャーアップグレード版になるとみられる。

http://openjdk.java.net/projects/jdk7/
・JDK 7 のリリースは 2010 年第２四半期ごろ。
・JDK 7 の機能にクロージャは入っていない。

https://jdk7.dev.java.net/
・JDK 7 Project

http://www.javac.info/
・Closures for the Java Programming Language

タピオラ幻景 Op.92

2009-03-28T22:11:00.005+09:00

『THE BEST 舘野泉』に収録されている吉松隆の「タピオラ幻景」がいい。

３楽章にわたって静かな情景をピアノで表現しており、ピアノの音の清冽さと良く合う。
吉松隆という作曲家は『西村朗と吉松隆のクラシック大作曲家診断』という本で知っていたが、今回その音楽を聴いて他の曲も聴いてみたいと思った。そういえば、本の共著者でもある西村朗は４月からＮ響アワーの新しいパーソナリティになる。

日本の現代の作曲家については知らないというか、興味の対象にならなかったが、その作品に触れてみたり、テレビで視る機会が増えると、情報量が積み重なり自然に親しみが出てくる。

クラシックの世界では作曲家は殆ど故人となってしまっている分、同時代を生きているというリアルタイム性も面白い。

祝! Mac Pro!!

2009-03-24T01:51:00.011+09:00

最近 Mac Pro(MB535J/A) BTO を購入した。

去年から新型が出たら買おうと決めていたのだが、結局１年ほど待たされてしまった。
念願のタワー筐体、サーバー並のパワー。

これで自作の頃と同様に、パーツのバージョンアップで長く付き合うことができる。
多分もう新たにコンピューターを欲しいとは思わないだろうな。

８コア１６スレッド。現状用途が殆どない。でも遊んでる CPU があるっていうのは精神的に気持ちがいい。
後はこれに見合うディスプレイ。これで完成。

プロジェクトの現状

2009-03-22T23:01:00.022+09:00

『IT マネージャの犯しやすい 10 の失敗』

事業よりも技術を重視する
「目に入らないものは気にもならない」式の考え方
チームに任せた仕事を確認しない
自分が期待していることを点検しない
事業部門の責任者と協力関係を作らない
自分を消耗させてしまう
バックアップソリューションのテストをしない
助けを求めない
自己啓発に時間をかけない
メンターやコーチを見つけていない

ほとんど当てはまるものばかり。
特に８の次の言葉は知ってはいても中々実行に移すことが難しい。

IT マネジメントの成功とは、正しい答えを知っていることではない。正しい答えを探し出し、ソリューションをできる限り素早く実行し、できる限り効果的にコストを見積もることができることを言うのだ。必要なら、ためらわずに専門家を連れてくるべきだ。

なぜなら、リーダーは多くの場合チーム内のスーパープレイヤーがその地位に就くことを求められるためだ。
名選手が名監督とは限らない。ポジションに合わせたスキルチェンジを行うことは、難しい。