2009年7月19日

RubyKaigi 2009 お疲れ様でした

今年は(無職中でお財布が厳しいため)Ustream.tvでの視聴での参加になりました。

1日目

朝から待機していたのですが、配信の調子が悪く視聴に耐えなかったため、1時間足らずで撤退しました。配信側のネットワークトラブルだったそうなのですが、すぐに原因を究明して、2日目からは快適な視聴にしてくれたKaigiFreaksに感謝します。

2日目

朝からまつもとさんの基調講演まで参加しました。

Ruby 1.8 のゆくえ(卜部 昌平さん)

Ruby 1.8の今後の予定のお話でした。未だに1.8をメインで使っているので、しっかりと聞かせてもらいました。

Ruby 1.9.2ロードマップ(園田 裕貴さん)

今度は1.9のお話。スピーカーの園田さんはお話がおもしろい方なので、今年も楽しませて頂きました。話している内容は固いんですが、口調と時々言うジョークだけでこれだけおもしろくなるとは。

Ruby リファレンスマニュアル刷新計画 2009 夏(okkezさん)

今年中に重要度の低い部分を省き、いったんクローズさせるという発表がありました。あと、青木さん、本の執筆お疲れ様でした。

基調講演(まつもとゆきひろさん)

質疑応答で「アメリカだとすごい勢いで質問されるんだけど」とおっしゃっていたのがおもしろかったです。RubyConf(アメリカのRubyイベント)にも一度は行ってみたいです。

3日目

朝までボードゲームをやっていたので、お昼から参加です。

RubyならMacでしょう(Vincent Isambartさん)

外国の方なんですが、日本語でセッションしてくださいました。快適すぎる。MacRubyの紹介でした。MacRubyの開発中バージョンである0.5は、かなり期待されているらしく、この後のセッションでもよく名前が出てきました。

RubyCocoa/HotCocoa(RHC) 〜RubyではじめるMac OS Xデスクトップアプリケーション開発〜(高尾 宏治さん)

RubyCocoaとその周辺技術であるObject-CやCocoaのお話。Macにおけるプログラミング入門としても分かり易かったと思います。各技術の登場背景と役割がわかりました。9月にRubyCocoaの本を出されるそうなので、購入決定です。

RubyをつかったiPhoneアプリケーション開発(森 琢磨さん)

ハッキング魂が見ることができました。iPhoneでRubyを動かして、Telnetサーバを起動してリモートからｉｒｂで動作中のプログラムを変更とか。すごいの一言です。

Take the Red Pill(角谷 信太郎さん)

角谷さんのセッションも毎回、楽しみにしています。1時間枠なのに、本編が30分で終わった時はどうしようかと思いましたが、質問がバンバン出てきて、予定時間までしっかり埋まっていました。中盤あたりはRubyに対するスタンスの違いでの議論もありました。

基調講演: Rubyと私、そして日本Rubyの会(高橋 征義さん)

最終セッションです。総括と日本Rubyの会をよりよくするためのお話でした。最後のセッションに相応しいないようだったと思います。

Reject Kaigi

今年で3回目を迎えるRejectKaigi。本編やTLで採択されなかったセッションや小ネタを話す1本3分のセッションです。今回は24本だったようです。色んな内容がありますし、短くて飽きが来ないので、毎回楽しみにしています。今年も楽しめました。

お疲れ様でした

スピーカー、スタッフ、参加者の皆さん、お疲れ様でした。来年はまた現地で参加したいと思います。

2009年7月20日

iPhone Appの勉強を始めました

RubyKaigiで熱をもらったので、冷めないうちに。

とりあえず定期購読しているMacFanのバックナンバーのサンプルプログラムを全部、作ってみたのですが、Objective-Cの構文に慣れず、知識の応用がきかない状態です。まずはObjective-Cを簡単にでも勉強した方がいいかもしれないです。

お薦めの書籍やサイトなどがありましたら、コメントで教えて頂けるとうれしいです。

ドミニオン得点計算機 for iPhone 作った

習作アプリ一本目。ドミニオンも拡張パックが増えて得点計算が面倒になったので、作ってみました。40分ぐらいで出来ました。しかし、アップルにお金を払っていないので、実機での動作テストが出来ません。セグメンテッドコントロールが小さすぎて押し間違いばかりでキレそうな気もします。

ドミニオン得点計算機 for iPhone

2009年7月22日

iPhoneアプリケーションプログラミングガイド 読了

全176ページ。このドキュメントは概要で、詳細は各リファレンスガイドに書いてある感じ。概要なので、一応全部読んだ方が良いだろうと、グラフィックやサウンドの章も読みました。あまり理解出来てはいませんが、勉強中は愚直にやる方が良い場合もあるんで、頑張ります。

iPhoneヒューマンインターフェイスガイドライン 読了

パート1が概要、パート2がネイティブアプリケーション、パート3がWebアプリケーションという内容だった。パート1は勢いで、パート2は楽しく、パート3は惰性で読んだという感じ。一番長いパート2が興味深い内容だったので、全体としてサクッと読めた印象です。

2009年7月23日

iPhone OSテクノロジーの概要 読了

50ページ弱なので、サクッと読了。しかし、テクノロジーレイヤー説明や、フレームワーク一覧があるので、たびたび参照することになりそうなドキュメントでした。

iPhone開発ガイド 読了

アプリケーション開発からテスト、チューニング、テスターへの配布までの概要資料。いずれ使うことになりそう。まだiPhoneデベロッパプログラムに加入していないのです＞＜

2009年7月24日

Objective-C 2.0プログラミング言語 読了

今までのドキュメントが良質だったので、「Appleやるじゃん」と思っていたのですが、難解なObjective-Cのドキュメントがハズレでした。クラスの説明の前にクラス変数への言及があったりして、まず構成がおかしい。文章も読みにくいので、きっとAppleの技術責任者(ドキュメント書きのプロではない)あたりが書いたのだろうなぁ、と推測されます。

なんとか読み終えまして、どうにかObjective-Cは使うことが出来そうな雰囲気です。しかし、愛せる言語ではないですね。

Cocoaメモリ管理プログラミングガイド 読了

参照カウンタ方式だけど、カウンタの増減はプログラマが意識して行う必要がある・・・と言ったところかな。参照のコピーではカウンタ数は増加せず、retainメソッドを使用すると、参照カウンタの増加と所有権の取得(概念的なモノで動作には関わりなし？)が出来る。使い終わったら、releaseメソッドで参照カウンタの減少と所有権の放棄を行う。参照カウンタが0になったら即座に解放される・・・のかな？それに関する言及は見つからなかった気がする。

自動開放プール(Autorelease Pools)という機能があって、autoreleaseメソッドを使用するとこの自動開放プールにオブジェクトが登録される。あとは自動開放プールの有効範囲を抜ける際にreleaseメソッドが呼ばれる仕組み。その際に参照カウンタが0になったら解放される。おもしろいのは、この自動開放プールがスタック可能なこと。新しい自動開放プールを作成すると(スタックなので当たり前ではありますが)スタックの最上位に置かれ、以後のautoreleaseメソッドは新しい自動開放プールへの登録となる。多数のオブジェクトの作成と解放を行う処理の前に自動開放プールを作っておくと、そこで作成したオブジェクトだけ早めに解放できたりしそうですね。この機能がiPhoneで使えるのかは不明です。

C,C++のようにプログラマに全部任せるわけでもなく、Java,Rubyのようにプログラムが全部やってくれるわけでもない。どういう意図でこういう設計になったのか知りたい設計です。ガベージコレクタは重い処理なので、iPhoneでは使いにくいのは分かるんですが、Cocoa自体はMac OS Xでも使いますしねぇ。違和感はありますが、慣れてしまえば、プログラマは適切な位置で参照カウンタを更新するメソッドを呼ぶだけで良いので、楽そうではあります。

iPhone OS View Controllerプログラミングガイド 読了

標準的な画面構成のガイドラインかと思ったら、思った以上に機能豊富でビックリした。例えばTab Bar Controllerに6個以上のView Controllerを追加すると自動的に最後のタブを「その他(More)」にしてくれてタブの入れ替え機能まで付けてくれたりする。しかし、完全に動作するサンプルはなかったので、100%理解できている実感はない。あとでサンプルコードを探さねば。

iPhone OS Table Viewプログラミングガイド 読了

これまた良くできたフレームワークだなぁ、と感心。iPhone関連のフレームワークは命名規則はイマイチに思えるけど、設計思想は良くできているように思います。

これで一通りドキュメントは読了。アドレスブック、アニメーション、サウンドは読んでいないけど、利用するつもりもないので、良しとします。

次はサンプルアプリケーションをいくつか作って、いよいよ自作アプリの開発ですかね。アイディアはいくつかあるんですが、まだ煮詰めていないので、頑張らなくては。

2009年7月25日

SimpleDrillDownを再実装しました

iPhone Dev CenterのSample Codeを自分の手で入力しています。プログラミングの勉強の基本は写経(お経を写すかのようにソースコードを写すこと)だと思っています。

対象はTable View Controllerを利用しているものにしました。8つ見つかったので、全部やろうと思います。まずは一番簡単そうなSimpleDrillDownに挑みました。

急がずに理解出来ないコードは今までに読んだドキュメントに戻って丁寧に作業しました。いくつも理解が浅かった箇所を発見でき、とても有意義な時間を過ごせました。

問題はユーザーインターフェイスの部分です。Interface BuilderというGUIツールで作成するのですが、どこがデフォルトから変更されたのか、とてもわかりにくいのです。MicrosoftのVisual Studioなら変更された項目は太字で表示されるため、わかりやすいのですが・・・。設定箇所もインスペクタウインドウだったり、オブジェクトを右クリックだったり、煩雑な感じです。対象ファイルをテキストとして開くとXML形式で閲覧できましたが、とても人間が読めるものではなく・・・。結局、トライ・アンド・エラーでかなりの時間をかけることになりました。

最初のサンプルコードを試してみての感想ですが、Cocoaの開発環境ではボトムアップによる開発はあまり向いていない印象を受けました。まず最低限の機能を作ってビルド&テスト。その後に拡張とやりたいのですが、最初の実行までに実装しなければならない部分が多く、うまくいきませんでした。環境になれてくると必要最低限の部分が割り出せるようになり、うまく出来るのかも知れませんが、自分が今までに触ってきた開発環境よりは敷居が高いのは間違いないと思います。

もう1つ気になったのが、メソッドのシグネチャの自動入力がないところです。Cocoaフレームワークから指定されているメソッド名、引数でメソッドを実装するのが基本作業なのですが、Objective-Cはメソッド定義がかなり長いのに手で入力するしか方法がないようなのです。一文字でも間違うとシグネチャが違うため、実行されません。問題なのは、必要となるメソッドだけ実装すれば良いため、実行時にメソッドが見つからなくてもエラーにならないところです。結局、デバッガでメソッドが実行されていることを確認するしかなく、デバッグ作業が長引くことになります。Visual Studioですと、ドロップダウンリストから実装したいメソッドを選ぶと自動で入力されます。これと同等の機能は欲しいところです。

2009年7月27日

HeaderFooterを再実装しました

iPhone Dev CenterのSample Code、HeaderFooterを再実装しました。

前回苦戦したメソッドシグネチャですが、エスケープキーを押すと補完候補が表示されることがわかりました。コンテキストに応じて自動的に補完候補を絞ってくれているので、入力ミスは無くなりそうです。どうせなら引数名まで補完して欲しいところですが、そういう機能はないみたいです。

インターフェイスビルダーによる作業は相変わらずもたつきます。Windows-based Application(一番ピュアなテンプレート)から作成しているのですが、以下の手順でやると良さそうです。

  1. ルートコントローラを決める。例えばNavigation Controllerとか、Tab Bar Controllerとか。
  2. 決めたルートコントローラをライブラリウインドウからメインウインドウへ追加する(ドラッグ・アンド・ドロップ)。
  3. メインウインドウに追加されたルートコントローラを右クリックし、デリゲート先を設定する。

これでベースは出来るので、あとはコントローラなりサブビューなりを追加していけば良さそうです。

Accessoryを再実装しました

カスタムのインディケータを実装するサンプルだったんですが、本題とは別にプロパティリストからのテーブルデータのロードのサンプルにもなっており、一粒で二度おいしいサンプルでした。プロパティリスト内の各要素を文字列ではなく辞書として定義しておいて、テーブルデータの読み込みだけではなく、現在の選択状況の保存にも使用しているのは、是非真似をしたいと思いました。

2009年7月29日

FirefoxのSQLiteデータベース再構築は効果絶大でした

Firefoxは情報の保存にSQLiteというデータベースを使っており、このデータベースの肥大化がFirefoxが遅くなる原因のひとつ・・・という情報は以前から知っていたのですが、「そんなに差が出るものじゃないだろう」と特に対策を取らずにいました。

ちょうどTwitterでこの話題を見かけたので、良い機会だし、やってみたところ、CPU使用率が激減しました。再構築前はCPU使用率８０％ぐらいだったのですが、1０％ぐらいに減りました。

デュアルコアなのですが、1コアはFirefox、もう1コアはVMware Fusion、余りのCPU時間でそれ以外のタスクをこなす・・・という状況だったので、非情に快適になりました。重たい作業をする時はFirefox落としたりしていたんですけど、今後はその必要も無さそうです。

モンハン3を予約しました

1→P2→P2Gと買っていますが、全然ハマれていないシリーズです。名作と名高いのでおもしろさを理解しようと購入するのですが、序盤の単調なクエストに嫌気が差して辞めること4回。3本しか買っていないのに4回とな？実は1が2本あるんですよ。発売日に買ったのを忘れて、ずっとあとに同じを買ったらしいです。先日、部屋のあちこちに散らばっていたPS2ソフトを整理していた時に発見して、唖然としました。

3は腰を据えて頑張りたいと思います。死にゲーは苦手なんですけど、死んで当たり前ぐらいの心づもりで頑張っていきたいです。

DrillDownSaveを再実装しました

画面状態保存のサンプルプログラムでした。UserDefaultsと言うところに保存するのが簡単みたいです。iPhoneではディクショナリを保存するのが一般的なのかな。プログラムからも利用しやすいクラスですし、アプリを作る際にはお世話になりそうです。

アプリを作成する際に各コンポーネントの編集順なのですが、ヘッダファイル→NIBファイル→ソースファイルの順が良さそうだと思いました。ヘッダファイルとNIBファイルを編集しないと変数名の自動補完が効きません。なので、ソースファイルは最後。ヘッダとNIBではヘッダにてIBOutletを定義しておかないと、コンポーネントのリンクが張れないので、ヘッダが最初。

そういえばNIBファイルからソースファイルの生成も出来るんでしたっけ。ただ、Visual Studioほど賢くないので、2回目以降の更新ではマージコマンドで差分を自分で合成することになるようです。やっぱりマイクロソフトはすごいなぁ、と思いました。

話は変わりまして、UIApplicationDelegateプロトコルを実装したクラスの差し替え方法を調べました。デフォルトで生成されるものはクラス名が長すぎて使いにくいんですよね。Interface Builderでクラス名の後ろが省略されてしまう。新しく自分で作ったクラスを利用したいのですが、Interface Builderに認識させる方法がわからない。15分ほどハマってようやくわかりました。Interface BuilderでライブラリウインドウからObjectを選び、メインウインドウ？に追加し、クラスを自分が作ったクラスに変更すれば良いようです。その後、File's Ownerのdelegate先として指定してやればオッケーです。

Interface Builderにも少しずつ慣れてきた今日この頃です。まだ使いやすいとは思えませんけどね・・・。アプリがアクティブじゃないと閉じるウインドウが多いのが鬱陶しいです。ブラウザで調べようと思っても勝手に非表示になってしまうのは使いにくいです。2つ以上のNIBファイルを開くとどのウインドウがどのNIBファイルのものかわかりにくいのも困りものです。XCodeみたいに1ウインドウですべてをこなせる方が好きです。