メモリ管理が不要になった

Xcode 4.2.1以降ではプロジェクト作成時に「Use Automatic Reference Counting (ARC)」にチェックを付けると自前でメモリ管理しなくてもよくなった。

Objective-CをRubyMotionに書き換えるときメモリ管理に由来するコードをバッサリ削るのが楽しかったが、Objective-Cでも今ならバッサリいける。

メモリ管理の煩わしさがなくなると同時にコードの見通しも大分よくなる。
またオブジェクトのリファレンスカウントを気にしなくてよくなったので、メソッドやクラスの抽出が割と気軽にできるようになったのは大きい。

テストが実行しやすくなった

以前はユニットテストを実行するのに自分でターゲットを作ったりとかしちめんどくさい手続きが必要だったが、現在ではプロジェクト作成時に自動で環境を整えられるほか、「Command+U」ですぐに実行できるようになっている。

実際に本格的なテストを書き始めたらどんな具合なのかはわからないが、とりあえずテストを走らせるのが簡単になったのはとてもいい。

Xcode4.4から各種リテラルが導入される

もうすぐ配列、ハッシュ、数値などが簡単に定義できるようになる。
メモリ管理の件もあってこれら基本的なオブジェクトを使うのも一仕事といったかんじだったが、これで大分気楽になりそう。

参考

• CocoaHeads • Objective-C literals for NSDictionary, NSArray, and NSNumber

Storyboard

InterfaceBuilderに画面遷移まで管理できる仕組みが加わってGUIのプロダクトを作るIDEとしての完成度が高まった。
個人的にはコードでUIを組み立てるやり方で不足を感じていないので使う予定はないけれど、かつて自分のようにInterfaceBuilderを投げ捨てた人がStoryboardの登場により戻っている例もあるようなので、もしかするとかなりいいものなのかもしれない。

ちなみにStoryboardはRubyMotionでも1.4でサポートされた。

まとめ

変更点を網羅したわけではなくちょっとぐぐったり手を動かしてみただけだけど、Xcodeでの開発も以前に比べてやりやすくなっていると感じた。
特にメモリ管理の負担がなくなったのが大きい。XcodeとObjective-Cを使った開発も苦痛ってほどではなくなったように見える。

正直勢いがありすぎて自分では追い切れてないが、公式ブログにリリース後一週間の熱狂が綴られていたので抄訳してみる。

RubyMotion’s Blog — What a week!

コミュニティ

• 今日までにユーザーによる約55のRubyMotion関連リポジトリがGitHubにできている
• GLKit/OpenGL, Facebook, Parse, cocos2d等の特殊なフィーチャーやフレームワークのサンプルデモ
• CoreDataやUIKit等の抽象化
• Redcar、TextMate、Vimのコード補完を含むRubyMotionサポート
• RailsFactoryの人々によるRubyMotionに関連する諸々のトラッキングは素晴らしい仕事だ

アップデート

• 簡単なバグ修正のために3回のアップデートを行った
• 4つめのアップデートも週末前に予定している

エデュケーションライセンス

• エデュケーションライセンスの問い合わせを多数受けている
• 学生がRubyMotionを使ってくれるのは喜ばしい
• レスポンスが遅れていてすまないが来週から順次連絡させてもらう

メンテナンス更新料

• 購入から一年の間はアップデートとサポートは無料
• それ以降のアップデートとサポートにはメンテナンスプログラムの更新が必要
• 価格は今のところ新規購入の半額の$99/年を考えている

先行者ディスカウント

• 現在行っている25%のディスカウントはあと3週間続けようと思っている

以上。
各種リンクなどは原文からどうぞ。

メンテナンス更新料の情報なども出ている。価格はまあ妥当なところかな？と思う。
それはさておきRubyMineもRubyMotionサポートはやく！

取っつきやすさ

iOS SDK開発未経験者がとっつきやすいのはTitanium。おそらくRuby経験者でも。
逆にiOS SDK経験者ならばRubyMotionの方が入って行きやすいかもしれない。

RubyMotionはiOS SDKのAPIをタイトになぞっているためにiOS SDKのAPIに関する知識が必要だが、iOS SDKのAPIには直感的じゃない部分が多々あって、それに馴染むまでけっこう時間がかかる。その学習コストがけっこう高い。
TitaniumのAPIはTitanium独自のものだが整理されていて扱いやすい。学習コストは皆無ではないがiOS SDKに比べればずっと楽。

またObjective-Cよりマシとは言えRubyMotionで何かを実現するために必要なコード量はTitaniumのそれよりも概して多い。
例えばアラート一つ表示するにしても以下のような差がある。

Titanium

alert('HOGEHOGE');

RubyMotion

alert = UIAlertView.new
alert.message = 'HOGEHOGE'
alert.addButtonWithTitle 'OK'
alert.show

4倍の差ですよ。

ただ書き味はRubyそのものでさくさくプログラミングしていくことができる。
そのためオレオレ仕様のラッパーをどんどん作っていくのも簡単で、例えば上記のアラートの例ではショートカットの定義なども容易にできる。

class Shortcut
  def self.alert(message)
    av = UIAlertView.new
    av.message = message
    av.addButtonWithTitle 'OK'
    av.show
  end
end

これをアプリケーションコードのどこかに書いておけば、Titaniumには及ばないが以下のごとく大分短く記述できる。

Shortcut.alert('HOGEHOGE')

こうしたラッパーライブラリのようなものが充実してくれば、RubyMotionのiOS SDKの知識が必須という話は変わってくるかもしれない。
そしてRubyの柔軟性とRubyMotionのパワフルさにはそれを実現する可能性が十分にあると思う。
走りとしてすでにBubbleWrapといったものができていたりする。

機能性

思い通りのことができるかという意味で。かゆいところに手が届きやすいかどうか。
これはiOS SDKのすべての機能が使えるRubyMotionの方が上。

Titaniumでも通り一遍のことはできるのでほとんどの場合それで不自由を感じないが、今一歩手が届かないというギャップにはまってしまう時もある。モジュールを作ったり生成されたObjective-Cのコードにパッチを当てるといったフォローの手段はあるので、そうしたギャップもだいたいは解決できるが乗り越えるのにちょっと苦労するということで減点。

パフォーマンス

これはRubyのコードからバイナリにコンパイルしてしまうRubyMotionの方が上。
TitaniumはJavaScriptをインタプリタで動かしているのでどうしても遅くなり、パフォーマンスが要求されるアプリケーションには対応が難しい。

ユーザー

Titaniumはすでにかなりのユーザーがいて日本でのコミュニティ活動も活発。開発実績も揃ってきている。JavaScript自体のユーザー数が多く、今後もJavaScriptで開発できるという特徴は人気を集めそう。

一方でリリースされたばかりのRubyMotionは興味を持っている人はともかくユーザー数はまだ少なそう。有償と言うこともあるし。
見込みユーザー的に言うと既存のRubyプログラマーでiOS開発に強いモチベーションを持っている人間というのはそれほど数がいない気がする。どちらかと言うと現在Objective-CでiOS開発をしていて、Objective-Cにはもううんざりだよ、という人達がターゲットなのかなという気がする。

ライブラリ

Titaniumは多くのJavaScriptのライブラリのほか、ネイティブ言語で書かれたモジュールにより機能拡張ができる。そうしたライブラリをマーケットプレイスで売ったり買ったりできる仕組みがあるのも面白い。

RubyMotionはCocoaPodsによってObjective-Cで書かれたライブラリが使えるほか、Rubyで書かれたライブラリもapp以下に設置すればビルド時にコンパイルされる。
ただしRubyの既存のGemはほぼ使えない。例えばRubyMotionはアプリケーションコード内でのrequireをサポートしていないのでrequireが含まれたものは全滅するなど。

追記

RubyMotion用のGemが作れると言うけどドキュメントにはないなと思っていたら書き途中と言うことみたい。

https://twitter.com/#!/lrz/status/198781031619379202

TDD

TitaniumはJavaScriptのテスティングフレームワークが使えるが定番のものはなく、各自それぞれ試行錯誤している模様。Jasmine Titaniumとか作っていた時期が俺にもありました。

RubyMotionは標準でMacBaconというRSpecクローンを用いたテストをサポートしている。標準のものがあるというのは大きい。

デバッグ

TitaniumはTitanium StudioというIDEがあってデバッガ完備。でも自分はそれを使いこなせないオールドタイプなんだけど。

RubyMotionはコンソールにログがでるだけだけど、クラッシュしたときのエラーメッセージがObjective-Cでの開発に比べると分かりやすく出るようになっていて助かる（それでもたまに黙って死ぬけど）。
それからインタラクティブシェルが面白すぎる。rakeした後のコンソールにプロンプトが表示されるのだけど、ここにコードを打ち込むとシミュレータ上で動いているアプリケーションをいろいろと操作することが可能。iOS SDKのAPIの挙動のテストなどもいちいち再コンパイルすることなくできるの超便利。

プラットフォーム

TitaniumはiOSとAndroidのクロスプラットフォーム対応。
RubyMotionはiOSのみ。RubyでAndroid開発したいならRobotoがあるよとのこと。

安定度

RubyMotionはこのあたりが未知数。個人的に過去に作ったアプリを移植してみて様子を見てみたい。
Titaniumは開発中は様々不思議に出くわすが、出来てしまえば不安定と言うことはない印象。

将来性

Titaniumはこの点心配なさそう。

RubyMotionは未知数。有償版のみということでユーザー数の伸びがどうなるのかわからないし、RubyでiOSアプリが作れるということであればMobiRubyという競合が今夏リリース予定だったりもする。

サンプルコードを眺めるとMobiRubyはRubyそのままというわけでもないようなのでRubyMotionの方が使いやすそうではあるが。

最後に

色々比較してみたけど特に結論は無い。
つらつら書いたことが何かの参考になればこれ幸いと行ったところ。

とりあえずすでにObjective-Cで書いてる人にはiOS SDKの壁はないと思うのでRubyMotionマジオススメ。

Rubyが使えるからとRubyMotionを買った人は思ったより簡単じゃないのでちょっとがっかりするかもしれないけど、せっかく買ったんだからお金がもったいないし、がんばってiOS SDKの壁に挑んで欲しい。
ついでにMacRubyに目覚めたりすると世界が広がるかもしれないし。

RubyMotionでもこのCocoaPodsを利用できる。
以下だいたい公式のドキュメント通り。

CocoaPodsのインストール

まずはCocoaPodsを入れてセットアップする。sudoはRVMを使っているなら不要。

$ [sudo] gem install cocoapods
$ pod setup

motion-cocoapodsのインストール

次にRubyMotionからCocoaPodsを使うためのmotion-cocoapodsを入れる。

$ [sudo] gem install motion-cocoapods

Rakefileの修正

RubyMotionプロジェクト内のRakefileを修正する。

$:.unshift("/Library/RubyMotion/lib")
require 'motion/project'
require 'motion-cocoapods'

Motion::Project::App.setup do |app|
  # Use `rake config' to see complete project settings.
  app.name = 'Hello'
  app.identifier = 'jp.brassworks.Hello'
  app.pods do
    dependency 'JSONKit'
    dependency 'Reachability'
    dependency 'FMDB'
  end
end

これで指定したライブラリが使えるようになる。
podはrakeした時に自動的にダウンロードおよびビルドされるので、このほかには何もしなくて良い。

これはいろいろと捗る。

不具合への対応

現時点でのmotion-cocoapodsには不具合があってちょっと細工をしないとうまく動かない。レポートは上がっているので早晩この問題はなくなると思うが、とりあえずその場しのぎに。

/Library/RubyMotion/lib/motion/project/vendor.rbの修正

77行目を以下のように書き換える

- objs = Dir.glob('*/**/*.o')
+ objs = (Dir.glob('*/**/*.o') + Dir.glob("*.o") + Dir.glob("*/*.o")).uniq

rake –traceで実行する

この状態でrakeしてもなにやらエラーが出てうまくいかないが、rake –traceで実行するとうまく動く。

とまあ、リリースされたばかりと言うことでちょこちょこ問題はあるが、早くもRubyMotion 1.1が出たりと動きは速いので、こちらも早々の修正を期待したい。

ちなみにいきなり不具合のエントリーを上げてしまったけど、だいたいの部分ではちゃんと動き過ぎて面白いというか驚いてる。

2012/05/07追記

不具合はRubyMotion 1.2で修正された。

日本語での概要は以下に良くまとまっている。

• Rails Hub情報局: MacRubyがiOSに来た！RubyでiOSのネイティブアプリ開発ができる「RubyMotion」登場
• RubyMotion、はじめの一歩 – Watson’s Blog

一言で言うと今までObjective-Cで我慢して書いていたものをすべてRubyでサクッと書いちゃおうぜ、というノリのものだ。
JavaScriptに対するCoffeeScriptの関係に似ているかもしれない。

個人的には以下の利点だけで値千金。

• 配列や文字列の処理がとてもとても楽ちん
• メソッド定義およびメソッド呼び出しが簡単
• いちいちヘッダーファイルを書かなくていい
• テストが書きやすい（RSpecっぽく書ける）

すべてObjective-Cで悩ましかったところだ。
ほかコマンドラインからビルドや実機転送ができる、好きなエディタで書ける（補完が効かないけど）、メモリ管理が不要等々。とにかくフットワークが軽くなる。インタラクティブシェルも面白そう。

RubyMotionは基本的にiOS SDKのAPIを忠実になぞった出来になっていて、iOS SDKのクラス名やメソッド名がRubyのコードの中でそのまま使える。そのためiOS SDKの持つすべての機能を使うことができ、Objective-Cでの開発経験がある開発者なら今までの知識を生かしつつ、Objective-Cの煩わしさを捨ててRubyでサクサク書いていくことができる。
逆に言うとiOS SDKの知識が必須となるのだが、そのあたりはApple公式のAPIドキュメントがよく整理されているのと、既存のサンプルコードなどが参考になるのでそこまで大きな問題ではないと思う。Objective-CのコードをRubyのコードに置き換える応用性が必要になるので全くの初心者にはちょっと厳しいかもしれないが。

まだリリースされたばかりのプロダクトなので安定度（手元のMBPでは実機転送ができなかった。一方でAirちゃんではできたりとか）やプロジェクトの継続性などは未知数だがこれはちょっと面白くて小気味いいのでしばらく使ってみたい。

その他参考

• RubyMotion で簡単な iOS アプリを作ってみよう – Watson’s Blog
• Why RubyMotion Is Better Than Objective-C – Josh Symonds
• RubyMotion – Ruby for iOS review | Matt Aimonetti

ポピュラーなツールやライブラリを探すにはとりあえずThe Ruby Toolboxだよね、ということでNanocで検索してNanocの属しているStatic Web Generationをポチ。

けっこうたくさん出て来たが勢いのある上の方のやつだけチェックしてみた。

• Jekyll
• Middleman
• High Voltage
• Nanoc
• Stasis

Jekyll

mojombo/jekyll GitHub

GitHubで採用されているだけあってダントツのスコア。単にページを作成するほか、ブログ形式でポストを追加していく機能も持っている。WordPress等の他のCMSからの移行ツールが用意されているのは興味深い。試したらイマイチ期待通りに動かなかったけど。

ところで基本のディレクトリ構成を最初に自分で組み立てないといけないのだが、これのせいでちょっと取っつきにくい。自動で作ってくれるようなものはないのだろうか？と思ったらpull requestがあった。けど取り込まれてないみたい。ポリシー的にこういう機能を取り込む気はなさげ？

簡単に試す意味ではチュートリアルとして紹介されているJekyll Bootstrapはなかなか良かった。テーマの仕組みも作れるとは。ともかくJekyllのスタートにはこれ激しくオススメ。

プラグイン機構も持っていてすでに多くのプラグインがある。このユーザーベースの大きさはメリットかもしれない。

参考

• Big Sky :: Jekyllで始める簡単ブログ
• Jekyll | CSS Radar | Mini Books For Front End Developers

Middleman

Middleman: Hand-crafted frontend development

Sinatraベースの静的サイトジェネレーター。
プログラマブルで柔軟性はありそうだが、これにブログを移行するとしたら逆に自分で書くことが多くなりすぎるぽい。

Dynamic Pagesという仕組みはデータを元に静的ページをたくさん作るには便利そうだ。同じようなことはNanocではDataSource、JekyllならプラグインでGeneratorsを作ればできそうだが。
それと出力の加工にRack Middlewareも使えるのは面白い。要はSinatraということなのかな。

参考

• あーありがち – 最新のfrontend技術を使いまくれる静的サイトジェネレータMiddleman

High Voltage

thoughtbot/high_voltage GitHub

Rails engineということでRailsとの組み合わせで使うようだ。
Railsのバージョンアップに引きずられて面倒なことになりそうなのでパス。

Nanoc

nanoc: a Ruby site compiler that generates static HTML » home

昨年から使っている静的サイトジェネレーター。
ヘルパーとフィルターをごりごり書けば割と何でもできてしまうので実は不足を感じていない。

Statis

Stasis – Static Sites Made Powerful

基本的な静的ファイル生成に加えて何かフィルター的な処理をしたければプロジェクト直下のcontroller.rbの中でまとめてやるようだ。ある意味シンプル。しかしブログっぽい物を作ろうとしたら相当頑張る必要がありそう。

さて、どれがいいだろう

JekyllかNanocかな。
NanocのバックグラウンドがなければJekyllを選択しただろう。しかしNanocを使い慣れているので積極的に移行する必要性を感じない。

要はMarkdownで書けてちょっとプログラムで出力をいじれたらそれでいいってことなんです。
それがNanocより楽できるものがひょっとしてあったりしないかなと思って調べてみたけれど、思い通りのレイアウトやページ構成にするには結局自分で色々書かないといけないようだ。

既存のものがないか探してみるとhugeurlというgemがあった。

• shokai/hugeurl · GitHub
• rubyで短縮URLの展開 | tjun memo

しかし中身をちょっとのぞいてみるとTwitterのhugeurlを使っているところがなんだか微妙だ。
しかもhugeurl自体が使えなくなってるくさい？APIドキュメントにも載ってないしアクセスするとNot Foundだし。

Locationヘッダから取得する

• RubyでURL短縮展開のコードがきもいです… – sorah.blog
• Schwarze SQ: 短縮URLを展開するRubyスクリプトを作ってみた

短縮URLに問い合わせてリダイレクト先をLocationから取るというのは分かりやすい。
エラー処理を軽く追加すれば汎用的に使えて良さそうだ。

更に汎用的なもの

moski/url_expanderというgemは以下のような短縮URLにも対応している。

• ネストされた短縮URL
• HTMLのメタタグでリダイレクトする短縮URL

ネストされた短縮URLはbit.lyのURLが更にt.coで短縮されている、みたいなもの。これを追いかけて展開するかしないかをオプションで指定できるようになっている。

「HTMLのメタタグでリダイレクトする短縮URL」とは、短縮URLを踏むとリダイレクトサービスのページが表示されて、そこからHTMLのメタタグで本来のURLにリダイレクトする形式のもの。そんなものもあるのだね。

といったかんじで、よりきめ細かく対応してくれるわけだが、該当するクラスのないURL短縮サービスに対してはエラーを返すので新しいサービスが出て来たら都度クラスを追加していかなくてはいけない。

しかし短縮URLサービスも多いね。

• アドビの新ツール「Shadow」は、モバイル用Webアプリ開発者必須のツール － Publickey
• Adobe Shadow の設定方法と注意点 – akihiro kamijo

スマホ用のサイトを作ってる時の確認作業というのはURL入力がけっこうダルいものだったけど、これでそのダルさから開放される。テクノロジーの進歩は素晴らしい。
ちなみにShadowを脳内で思わずスバドウと読んでしまうくらい某MMOの後遺症はまだ残っています＞＜ノ

それにしてもThinkPad TabletのUIの挙動はスムーズで一昔前のAndroid端末にありがちだった動作のひっかかりやフリックしたつもりでアイコンをタップしてしまうといった不愉快さがなくなっている。
iPadに比べるとシンプルさが足りず操作に戸惑うこともあるが、UIレスポンスの快適さに関してはけっこう差を詰めてきた感がある。日頃からAndroid端末をウォッチしているわけではないのでThinkPad Tabletが特別にいいのか最近のAndroidタブレットはみんなこうなのかはわからないが。

で、今は手書きメモアプリを探している。
プリインストールされているものは妙に重かったので削除。それから「そういやEvernoteに手書きメモなかったっけ」と思い当たってとりあえずはEvernote+Skitchに落ち着いた。思わぬところでEvernoteに再入門ですよ。
しかしSkitchの書き味がイマイチ（入力がベクターに変換されて細部がはしょられることがある）なのでまだ探し中。iPadのPenutimateくらいの書き味を持ったものがあればいいんだけど。とは言え現状でも十分に快適です。

ちなみにThinkPad Tabletは5月にAndroid4.0へのアップデートに対応する。Android4.0では筆圧にも対応するということで、もっと快適になるのか？と楽しみなんだけど動作が重くなったら嫌なのでしばらく様子見の予定。

iPadと比べると

• 750gは片手で持ち続けるにはちょっと重い
• バッテリーの持ちがiPadの半分以下（実際使った感じで）
• いらないものが最初から入りすぎている（消せるのでまあいいけど）

といった不満もあるけど快適動作するので許容範囲だ。ストレスなく動くAndroid端末は初めてだったので感動した。

そこでまず自作しようとディレクトリを切ったところで、いやいや誰か作ってるのではないかと思い当たり、検索してみると案の定見つかった。

• magic_commenter
• magic_encoding

両方ともコマンドラインツールとして使用する。コマンドを打つとそのディレクトリ以下のRubyファイルを検索してマジックコメントを付加してくれる。
まず最初にmagic_commenterを試してみたが、こちらはマルチバイト文字列が含まれているファイルにしかマジックコメントを付加してくれなかった。うーん、どっちかと言うとこれから日本語が含まれるかもしれないファイルにも付加して欲しいのに。
対して次に試したmagic_encodingは問答無用ですべてのファイルにマジックコメントを付加するようになっていた。個人的にこちらの動作の方が望ましかったのでmagic_encodingを採用。

こうして車輪の再開発は免れた。

Railsに限って言うとカスタムのジェネレータを作成する手もあるのだろうけど、他にもファイルをジェネレートするフレームワークやツールがあることを考えると都度magic_encodingを利用するのが妥当な落としどころかと思う。