読者です 読者をやめる 読者になる 読者になる

Rubyistokei for iOS を RubyMotion で作った話

この投稿は RubyMotion Advent Calendar 2013 の23日目の記事です。

最近 iPhone に買い換えて、初めて iPhone をメイン端末にしてみたので iOS アプリを何か作ってみよう、と思い最初は無難に Xcode + Objective-C で書いていたんだけど、そういえば RubyMotion でも iOS アプリ作れるんだっけ、どんな感じなんだろうと思って Rubyist がみんな大好き*1 Rubyistokei の iOS 版を作ってみた。

Rubyistokei for iOS

Rubyistokei は

  • 画像の表示
  • ネットワークでのデータ取得
    • github 上に表示元のメタデータが上がってるため、それを取得し利用する
  • レイアウトの構築
  • タイマーの利用
    • 時計なんで

あたりの実装が必要で、最初の題材としては簡単すぎずも無く、難しすぎずも無くちょうど良い感じでした。

というわけで作ってみたんだけど、コードはほぼ app_delegate.rb に。ネットワークやりとりして Rubyist オブジェクトを返す実装のみ rubyist.rb へ。本当はもっときれいな抽象化と、適切なファイル分離を行うんだろうけど、RubyMotion 自体はもちろん、Cocoa フレームワークや UIKit も理解してないため、1ファイルで試行錯誤できた方が楽だったので、ほぼ1ファイルで実装。きれいな実装では無いので、参考にはあんまりならないと思います。

また SugarCube 等の RubyMotion で Ruby らしく書けるライブラリは、理解が薄い時から高レベルのラッパーを使ってしまうと、挙動の理解ができなくなってしまうので、意図的に使わずに。使ったのは BubbleWrap の HTTP と String#to_color ぐらいかな。

AppStore に申請してリリース

作ったからには AppStore に申請してリリースする気満々だったんだけど、レビューで落とされたヨ…。理由は、シンプルすぎる時計アプリだから、もっとユーザ価値を考えて!とのことでした。まわりの iOS 開発者に聞いてみたところ、これぐらいのアプリでも落とされたりすることもあるんだね、とのことだったので、運が良ければ通るし、運が悪ければ落とされる感でした。

RubyMotion で開発してみて

開発してみて、意外とつまずくところが少なかったなぁ、という印象。RubyMotion だからハマった、というところはほぼ無くて、だいたい自分が理解してない iOS フレームワークの部分だった。

RubyMotion JP など日本語のチュートリアルドキュメントも充実してて、日本語化してくださった皆さんには感謝です。

特に Objective-C の表現をどう Ruby で現してるか、などランタイムのことが書いてある RubyMotion Runtime Guide(日本語訳) が興味深かったですね。

*1:個人の見解です

GlitchKit - iOS でカジュアルにグリッチできるライブラリ

本日、社内外の iOS/Android 向け Tips 共有会、#potatotips 第二回 で、「XXXKit -それははしかのような物-」という内容を発表した。

最近 iOS (Objective-C) を今更ながらに学び始めたんだけど、新しい事を学んで今まで知らなかった/興味深いパラダイムがあると、それにどっぷりつかりがちで、それを プログラマにおけるはしか 、と言ったりする。

その中でかじってすぐに興味深いと感じたのは Objective-C の"カテゴリ"で。これはヘッダを import するだけ(実際は import するしない関わらずリンクされた時)で、様々なオブジェクトのクラスの挙動を拡張できる。Ruby における mixin + refinements のような物だし、Perl でも use して特定のオブジェクトの挙動を変えることが出来るが、Objective-C を学ぶまで、このようなことができることを知らなかった。

またこの "カテゴリ" と組み合わせて、標準のオブジェクトや UIKit といったフレームワークを拡張することができる XXXKit という語尾に Kit をつけたライブラリがある。たとえば EnumeratorKit なんかは、NSArray や NSDictionary で、Ruby の Enumerator 的なコードを書くことができるようになる。もちろんこれらは意図しない動作を引き起こす可能性もあるため、多用すると危険なのだが、そこは便利さとトレードオフなので、どうしてもオレオレ XXXKit を作りたくなる衝動がでてくる。

そのため、"カテゴリ" と "XXXKit" は Objective-C におけるはしかのようなものだなぁ、と感じた。と言うわけでカテゴリ使って Glitch する XXXKit を作ってみた。

Podfile に追加する

pod 'GlitchKit'

 

before glitch

UIImageView -glitch でグリッチ

#import "GlitchKit.h"

// glitch!
[uiImageView glitch];

   after glitch

簡単便利

UIImageView -glitchWithBlock: でグリッチ

好きなようにグリッチさせる

// apply custom glitch
[uiImageView glitchWithBlock:^int(int byte, int index, uint length, Byte *bytes) {
  return (byte == 42 && arc4random() % 3 == 1) ? 0 : byte;
}];

 

after glitch3

簡単便利

他にもUIImage クラスで以下が使えるようになる。

  • (UIImage *)glitch;
  • (UIImage )glitchWithBlock: (int (^)(int byte, int index, uint length, Byte bytes)) block;
  • (NSData *)glitchData;
  • (NSData )glitchDataWithBlock: (int (^)(int byte, int index, uint length, Byte bytes)) block;

どうぞカジュアルにごりようください。

Re: Podcast ep2: 2013/02/19 ゲスト: Kenn Ejima

miyagawa さんの podcast が毎回面白い、Web っ子ならあーそれそうだよね〜的な相づちを頭の中でうちつつにやにやと聴いてしまう。しかしそれだけだとなんか言い足りない気分、なんか言いたい!と言うわけで、今回の江島さんとの podcast の話題に勝手に乗っかかってみます試み。

マシン環境のセットアップの話し

f:id:secondlife:20120912182002j:plain

開発環境をどう整えどう保つか。これはエンジニアそこそこいる会社だと必ず考える話で。マシンセットアップの初期化コストを減らし、その後どう継続するか。

miyagawa さんが言う、うちの会社というのは弊社(クックパッド)のことで、エンジニアの開発環境 OS は Mac。 Mac の上にとりわけ仮想環境の Linux などを構築してるわけでは無く、直接 Mac を使って開発している。

Mac には homebrew というパッケージ管理システムがあり、それを利用してる。しかしながら、自社向けのパッチを当ててたり、特定のバージョン固定が必要なパッケージ、というのがどうしても出てきてしまう。その問題を解決するために、homebrew 0.9 から入った tap を利用して、自社向けの formula を用意している。まぁなんてかわいい機能なのでしょう。tap かわいいよ tap。べんりです。

それらを調理するために cpad という自社の環境構築ツールがあり、初期のマシンセットアップ時には、homebrew + 自社 tap + 各種必要な formula のインストール + その他細かいこと諸々を行ってくれる。また、必須ライブラリが増えたり、開発環境を変更したりするときも、cpad を通して自動でアップデートされる。たとえば先日は開発者の手元の rvm から rbenv へ切り替えるための設定が反映されたりした。

しかしながら、開発者手元のマシンの条件は使えば使うほど様々な差違がでてくるため(たとえば、Apple Store 経由でアップデートされる Xcode による gcc の差違とかね)完璧では無い。開発者の複数人がハマるような問題は cpad で吸収、一人がおきてるような問題ないならサポートしてカバー、のような方法で対応している。完璧は求めていない。

Boxen

便利そうだよねぇ、今 Mac の統一した環境を用意するなら始めに試しすこと間違いなし。こういう Web っ子が欲しがるツールを汎用化して公開しちゃうあたり、GitHubber はいつもクールだなぁ。プロモーションもうまいよね。

そういえば中村君

We designed Boxen with teams that work like GitHub in mind. Boxen automatically updates itself every run and opens and closes GitHub Issues as problems arise and get fixed. With Boxen

問題発生時に GitHub Issues に自動で登録・解決するとクローズされるの面白い、って言ってて、たしかに GitHub 的考方。

コアコンピタンスでない物は、あり物のサービスを利用する

これは全面的に頷ける話しで。メール送信、パフォーマンスやメトリクスの効果測定、ログ解析等、あり物のサービスで済ませられる部分は徹底的に外部の物を使った方が速くて効率が良いし、クオリティ自体も高いサービスが多い。良い時代になったものだ。

また個人に依存した物を作ってしまうと、その人が会社を辞めたり、仕事の内容が変わったりで、メンテナンスされなくなってしまうリスクもある。よほど必要である物で無い限り、もしくはそれ自体を社内、もしくは OSS としてうまくプロモーションしない限りは廃れてしまう。なのでできる限り、本質的に必要ない部分は外の物を使いたい。もちろん「本当に必要」な物は積極的に作っていきたいよね、フルスクラッチで創造する・コードを書く事は面白いし。

New Relic

New Relic は良く出来ていて結構使っているんだけど、Web サービス規模が巨大に・複雑になってくると、 何故重いかを解ってしまっている故、New Relic でのパフォーマンス問題点はすでに既知の事が多く、使いどころが難しくなってしまう。

重いページはしかるべき理由(例えばレガシーコードの仕様によるキャッシュの難しさ、インデクス更新やデータ分割がオンラインでは難しいデータベース、等々)により重く、またパフォーマンスチューニング時もどう改善していくか、を戦略的に考えていく必要があるため、New Relic 自体の重要性が薄れてしまう。

  • New Relic『hey, このクエリー遅いよ』
  • 自分『ごめん、知ってる』

もちろんサービスが巨大になる前の、New Relic 見通しの良さはとても素晴らしいのだけどね。

VPC の話し

去年、AWS ネットワークを VPC に全面移行したんだけど、開発者視点で一番これは便利!って思えたのはセキュリティグループ(いわゆる iptables のネットワーク・ポート許可設定)をインスタンスの作り直し無しで付け替え可能になったことで。

VPC でない EC2 ではインスタンス作ってたちあげてサーバ設定していざ使おう!という段階でアッーーーッッッセキュリティグループ指定ミスってた…作り直し…マジ…となったことが何度あることか…。

そもそもEC2 でできないのがおかしいのでは…という話もあるけど…。

ま、そんな感じで

毎回あまりまとめられず、すぱっと podcast 終わるね :)

全然関係ないけど、はてなダイアリーからはてなブログへ移転した。それに伴いですます調を辞め、あこがれのブログぽい記事書きたいと思う。これがブログというやつか!

あとミーハーなので江島さんとごはんたべにいきたいです。