<p>この投稿は <a href="http://qiita.com/advent-calendar/2013/rubymotion">RubyMotion Advent Calendar 2013</a> の23日目の記事です。</p>
<p>最近 iPhone に買い換えて、初めて iPhone をメイン端末にしてみたので iOS アプリを何か作ってみよう、と思い最初は無難に Xcode + Objective-C で書いていたんだけど、そういえば RubyMotion でも iOS アプリ作れるんだっけ、どんな感じなんだろうと思って Rubyist がみんな大好き<a href="#f1" title="個人の見解です">*1</a> <a href="http://rubyistokei.herokuapp.com/">Rubyistokei</a> の iOS 版を作ってみた。</p>
<p><img src="http://cdn-ak.f.st-hatena.com/images/fotolife/s/secondlife/20131223/20131223171509.jpg" alt="Rubyistokei for iOS"></p>
<p>Rubyistokei は</p>
<ul>
<li>画像の表示</li>
<li>ネットワークでのデータ取得<ul>
<li>github 上に表示元のメタデータが上がってるため、それを取得し利用する</li>
</ul></li>
<li>レイアウトの構築</li>
<li>タイマーの利用<ul>
<li>時計なんで</li>
</ul></li>
</ul>
<p>あたりの実装が必要で、最初の題材としては簡単すぎずも無く、難しすぎずも無くちょうど良い感じでした。</p>
<ul>
<li><a href="https://github.com/hotchpotch/rubyistokei-ios-motion">https://github.com/hotchpotch/rubyistokei-ios-motion</a></li>
</ul>
<p>というわけで作ってみたんだけど、コードはほぼ app_delegate.rb に。ネットワークやりとりして Rubyist オブジェクトを返す実装のみ rubyist.rb へ。本当はもっときれいな抽象化と、適切なファイル分離を行うんだろうけど、RubyMotion 自体はもちろん、Cocoa フレームワークや UIKit も理解してないため、1ファイルで試行錯誤できた方が楽だったので、ほぼ1ファイルで実装。きれいな実装では無いので、参考にはあんまりならないと思います。</p>
<ul>
<li><a href="https://github.com/hotchpotch/rubyistokei-ios-motion/blob/master/app/app_delegate.rb">https://github.com/hotchpotch/rubyistokei-ios-motion/blob/master/app/app_delegate.rb</a></li>
<li><a href="https://github.com/hotchpotch/rubyistokei-ios-motion/blob/master/app/rubyist.rb">https://github.com/hotchpotch/rubyistokei-ios-motion/blob/master/app/rubyist.rb</a></li>
</ul>
<p>また SugarCube 等の RubyMotion で Ruby らしく書けるライブラリは、理解が薄い時から高レベルのラッパーを使ってしまうと、挙動の理解ができなくなってしまうので、意図的に使わずに。使ったのは BubbleWrap の HTTP と String#to_color ぐらいかな。</p>
<h2>AppStore に申請してリリース</h2>
<p>作ったからには AppStore に申請してリリースする気満々だったんだけど、レビューで落とされたﾖ…。理由は、シンプルすぎる時計アプリだから、もっとユーザ価値を考えて！とのことでした。まわりの iOS 開発者に聞いてみたところ、これぐらいのアプリでも落とされたりすることもあるんだね、とのことだったので、運が良ければ通るし、運が悪ければ落とされる感でした。</p>
<h2>RubyMotion で開発してみて</h2>
<p>開発してみて、意外とつまずくところが少なかったなぁ、という印象。RubyMotion だからハマった、というところはほぼ無くて、だいたい自分が理解してない iOS フレームワークの部分だった。</p>
<p><a href="http://rubymotion.jp/">RubyMotion JP</a> など日本語のチュートリアルドキュメントも充実してて、日本語化してくださった皆さんには感謝です。</p>
<p>特に Objective-C の表現をどう Ruby で現してるか、などランタイムのことが書いてある <a href="http://rubymotion.jp/RubyMotionDocumentation/guides/runtime/index.html">RubyMotion Runtime Guide(日本語訳)</a> が興味深かったですね。</p>
<p><a href="#fn1">*1</a>:個人の見解です</p>


この投稿は RubyMotion Advent Calendar 2013 の23日目の記事です。 最近 iPhone に買い換えて、初めて iPhone をメイン端末にしてみたので iOS アプリを何か作ってみよう、と思い最初は無難に Xcode + Objective-C で書いていたんだけど、そういえば RubyMotion でも iOS アプリ作れるんだっけ、どんな感じなんだろうと思って Rubyist がみんな大好き *1 Rubyistokei の iOS 版を作ってみた。 Rubyistokei は 画像の表示 ネットワークでのデータ取得 github 上に表示元のメタデータが上がってるため、それを取得し利用する レイアウトの構築 タイマーの利用 時計なんで あたりの実装が必要で、最初の題材としては簡単すぎずも無く、難しすぎずも無くちょうど良い感じでした。 https://

Rubyistokei for iOS を RubyMotion で作った話

<ul>
<li><a href="https://github.com/hotchpotch/GlitchKit">https://github.com/hotchpotch/GlitchKit</a></li>
</ul>
<p>本日、社内外の iOS/Android 向け Tips 共有会、<a href="https://github.com/potatotips/potatotips/wiki/potatotips-2">#potatotips 第二回</a> で、「XXXKit -それははしかのような物-」という内容を発表した。</p>
<p>最近 iOS (Objective-C) を今更ながらに学び始めたんだけど、新しい事を学んで今まで知らなかった/興味深いパラダイムがあると、それにどっぷりつかりがちで、それを <a href="http://d.hatena.ne.jp/Yoshiori/20090706/1246849833">プログラマにおけるはしか</a> 、と言ったりする。</p>
<p>その中でかじってすぐに興味深いと感じたのは Objective-C の"カテゴリ"で。これはヘッダを import するだけ(実際は import するしない関わらずリンクされた時)で、様々なオブジェクトのクラスの挙動を拡張できる。Ruby における mixin + refinements のような物だし、Perl でも use して特定のオブジェクトの挙動を変えることが出来るが、Objective-C を学ぶまで、このようなことができることを知らなかった。</p>
<p>またこの "カテゴリ" と組み合わせて、標準のオブジェクトや UIKit といったフレームワークを拡張することができる XXXKit という語尾に Kit をつけたライブラリがある。たとえば <a href="https://github.com/sharplet/EnumeratorKit">EnumeratorKit</a> なんかは、NSArray や NSDictionary で、Ruby の Enumerator 的なコードを書くことができるようになる。もちろんこれらは意図しない動作を引き起こす可能性もあるため、多用すると危険なのだが、そこは便利さとトレードオフなので、どうしてもオレオレ XXXKit を作りたくなる衝動がでてくる。</p>
<p>そのため、"カテゴリ" と "XXXKit" は Objective-C におけるはしかのようなものだなぁ、と感じた。と言うわけでカテゴリ使って Glitch する XXXKit を作ってみた。</p>
<h3>Podfile に追加する</h3>
<pre><code>pod 'GlitchKit'
</code></pre>
<p><img src="https://dl.dropboxusercontent.com/u/980764/images/glitch_before.png" alt="before glitch"></p>
<h3>UIImageView -glitch でグリッチ</h3>
<pre><code>#import "GlitchKit.h"

// glitch!
[uiImageView glitch];
</code></pre>
<p>　　 <img src="https://dl.dropboxusercontent.com/u/980764/images/glitch1.png" alt="after glitch"></p>
<p>簡単便利</p>
<h3>UIImageView -glitchWithBlock: でグリッチ</h3>
<p>好きなようにグリッチさせる</p>
<pre><code>// apply custom glitch
[uiImageView glitchWithBlock:^int(int byte, int index, uint length, Byte *bytes) {
  return (byte == 42 &#x26;&#x26; arc4random() % 3 == 1) ? 0 : byte;
}];
</code></pre>
<p><img src="https://dl.dropboxusercontent.com/u/980764/images/glitch2.png" alt="after glitch3"></p>
<p>簡単便利</p>
<p>他にもUIImage クラスで以下が使えるようになる。</p>
<ul>
<li>(UIImage *)glitch;</li>
<li>(UIImage <em>)glitchWithBlock: (int (^)(int byte, int index, uint length, Byte</em> bytes)) block;</li>
<li>(NSData *)glitchData;</li>
<li>(NSData <em>)glitchDataWithBlock: (int (^)(int byte, int index, uint length, Byte</em> bytes)) block;</li>
</ul>
<p>どうぞカジュアルにごりようください。</p>
<ul>
<li><a href="https://github.com/hotchpotch/GlitchKit">https://github.com/hotchpotch/GlitchKit</a></li>
</ul>


https://github.com/hotchpotch/GlitchKit 本日、社内外の iOS/Android 向け Tips 共有会、 #potatotips 第二回 で、「XXXKit -それははしかのような物-」という内容を発表した。 最近 iOS (Objective-C) を今更ながらに学び始めたんだけど、新しい事を学んで今まで知らなかった/興味深いパラダイムがあると、それにどっぷりつかりがちで、それを プログラマにおけるはしか 、と言ったりする。 その中でかじってすぐに興味深いと感じたのは Objective-C の"カテゴリ"で。これはヘッダを import するだけ(実際は import するしない関わらずリンクされた時)で、様々なオブジェクトのクラスの挙動を拡張できる。Ruby における mixin + refinements のような物だし、Perl でも u

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

<h3>gerry++</h3>
<p>いつでも必ず入れる個室がある安心感って幸福度に直結しそう。</p>
<p>と久しぶりに個室探して冷や汗ダッシュしたので感じたのでした。</p>


gerry++ いつでも必ず入れる個室がある安心感って幸福度に直結しそう。 と久しぶりに個室探して冷や汗ダッシュしたので感じたのでした。

gerry++

<p>元気に育ってます</p>
<div class="photos photos-medium photos-hatena"><span itemscope="" itemtype="http://schema.org/Photograph"><a href="https://cdn-ak.f.st-hatena.com/images/fotolife/s/secondlife/20130401/20130401113638_original.jpg"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/secondlife/20130401/20130401113638.jpg" class="photo" itemprop="image"></a></span></div>


続・続・人参情報

<p><a href="http://r7kamura.hatenablog.com/entry/2013/03/04/120426">http://r7kamura.hatenablog.com/entry/2013/03/04/120426</a></p>
<div class="photos photos-medium photos-hatena"><span itemscope="" itemtype="http://schema.org/Photograph"><a href="https://cdn-ak.f.st-hatena.com/images/fotolife/s/secondlife/20130305/20130305141346_original.jpg"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/secondlife/20130305/20130305141346.jpg" class="photo" itemprop="image"></a></span></div>


http://r7kamura.hatenablog.com/entry/2013/03/04/120426

続・人参情報

<p>miyagawa さんの podcast が毎回面白い、Web っ子ならあーそれそうだよね〜的な相づちを頭の中でうちつつにやにやと聴いてしまう。しかしそれだけだとなんか言い足りない気分、なんか言いたい！と言うわけで、今回の江島さんとの podcast の話題に勝手に乗っかかってみます試み。</p>
<ul>
<li><a href="http://podcast.bulknews.net/post/43535683799/podcast-ep2-2013-02-19-kenn-ejima">http://podcast.bulknews.net/post/43535683799/podcast-ep2-2013-02-19-kenn-ejima</a></li>
</ul>
<h2>マシン環境のセットアップの話し</h2>
<div class="photos photos-medium photos-hatena"><span itemscope="" itemtype="http://schema.org/Photograph"><a href="http://cdn-ak.f.st-hatena.com/images/fotolife/s/secondlife/20120912/20120912182002_original.jpg"><img src="http://cdn-ak.f.st-hatena.com/images/fotolife/s/secondlife/20120912/20120912182002.jpg" class="photo" itemprop="image"></a></span></div>
<p>開発環境をどう整えどう保つか。これはエンジニアそこそこいる会社だと必ず考える話で。マシンセットアップの初期化コストを減らし、その後どう継続するか。</p>
<p>miyagawa さんが言う、うちの会社というのは弊社(クックパッド)のことで、エンジニアの開発環境 OS は Mac。 Mac の上にとりわけ仮想環境の Linux などを構築してるわけでは無く、直接 Mac を使って開発している。</p>
<p>Mac には homebrew というパッケージ管理システムがあり、それを利用してる。しかしながら、自社向けのパッチを当ててたり、特定のバージョン固定が必要なパッケージ、というのがどうしても出てきてしまう。その問題を解決するために、homebrew 0.9 から入った <a href="https://github.com/mxcl/homebrew/wiki/Homebrew-0.9">tap</a> を利用して、自社向けの formula を用意している。まぁなんてかわいい機能なのでしょう。tap かわいいよ tap。べんりです。</p>
<p>それらを調理するために cpad という自社の環境構築ツールがあり、初期のマシンセットアップ時には、homebrew + 自社 tap + 各種必要な formula のインストール + その他細かいこと諸々を行ってくれる。また、必須ライブラリが増えたり、開発環境を変更したりするときも、cpad を通して自動でアップデートされる。たとえば先日は開発者の手元の rvm から rbenv へ切り替えるための設定が反映されたりした。</p>
<p>しかしながら、開発者手元のマシンの条件は使えば使うほど様々な差違がでてくるため(たとえば、Apple Store 経由でアップデートされる Xcode による gcc の差違とかね)完璧では無い。開発者の複数人がハマるような問題は cpad で吸収、一人がおきてるような問題ないならサポートしてカバー、のような方法で対応している。完璧は求めていない。</p>
<h2>Boxen</h2>
<p>便利そうだよねぇ、今 Mac の統一した環境を用意するなら始めに試しすこと間違いなし。こういう Web っ子が欲しがるツールを汎用化して公開しちゃうあたり、GitHubber はいつもクールだなぁ。プロモーションもうまいよね。</p>
<p>そういえば<a href="http://r7kamura.hatenablog.com/">中村君</a>が</p>
<ul>
<li><a href="https://github.com/blog/1345-introducing-boxen">https://github.com/blog/1345-introducing-boxen</a></li>
</ul>
<blockquote>
<p>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</p>
</blockquote>
<p>問題発生時に GitHub Issues に自動で登録・解決するとクローズされるの面白い、って言ってて、たしかに GitHub 的考方。</p>
<h2>コアコンピタンスでない物は、あり物のサービスを利用する</h2>
<p>これは全面的に頷ける話しで。メール送信、パフォーマンスやメトリクスの効果測定、ログ解析等、あり物のサービスで済ませられる部分は徹底的に外部の物を使った方が速くて効率が良いし、クオリティ自体も高いサービスが多い。良い時代になったものだ。</p>
<p>また個人に依存した物を作ってしまうと、その人が会社を辞めたり、仕事の内容が変わったりで、メンテナンスされなくなってしまうリスクもある。よほど必要である物で無い限り、もしくはそれ自体を社内、もしくは OSS としてうまくプロモーションしない限りは廃れてしまう。なのでできる限り、本質的に必要ない部分は外の物を使いたい。もちろん「本当に必要」な物は積極的に作っていきたいよね、フルスクラッチで創造する・コードを書く事は面白いし。</p>
<h2>New Relic</h2>
<p>New Relic は良く出来ていて結構使っているんだけど、Web サービス規模が巨大に・複雑になってくると、 何故重いかを解ってしまっている故、New Relic でのパフォーマンス問題点はすでに既知の事が多く、使いどころが難しくなってしまう。</p>
<p>重いページはしかるべき理由(例えばレガシーコードの仕様によるキャッシュの難しさ、インデクス更新やデータ分割がオンラインでは難しいデータベース、等々)により重く、またパフォーマンスチューニング時もどう改善していくか、を戦略的に考えていく必要があるため、New Relic 自体の重要性が薄れてしまう。</p>
<ul>
<li>New Relic『hey, このクエリー遅いよ』</li>
<li>自分『ごめん、知ってる』</li>
</ul>
<p>もちろんサービスが巨大になる前の、New Relic 見通しの良さはとても素晴らしいのだけどね。</p>
<h2>VPC の話し</h2>
<p>去年、AWS ネットワークを VPC に全面移行したんだけど、開発者視点で一番これは便利！って思えたのはセキュリティグループ(いわゆる iptables のネットワーク・ポート許可設定)をインスタンスの作り直し無しで付け替え可能になったことで。</p>
<p>VPC でない EC2 ではインスタンス作ってたちあげてサーバ設定していざ使おう！という段階でｱｯｰｰｰｯｯｯセキュリティグループ指定ミスってた…作り直し…マジ…となったことが何度あることか…。</p>
<p>そもそもEC2 でできないのがおかしいのでは…という話もあるけど…。</p>
<h2>ま、そんな感じで</h2>
<p>毎回あまりまとめられず、すぱっと podcast 終わるね :)</p>
<p>全然関係ないけど、はてなダイアリーからはてなブログへ移転した。それに伴いですます調を辞め、あこがれのブログぽい記事書きたいと思う。これがブログというやつか！</p>
<p>あとミーハーなので江島さんとごはんたべにいきたいです。</p>


miyagawa さんの podcast が毎回面白い、Web っ子ならあーそれそうだよね〜的な相づちを頭の中でうちつつにやにやと聴いてしまう。しかしそれだけだとなんか言い足りない気分、なんか言いたい！と言うわけで、今回の江島さんとの podcast の話題に勝手に乗っかかってみます試み。 http://podcast.bulknews.net/post/43535683799/podcast-ep2-2013-02-19-kenn-ejima マシン環境のセットアップの話し 開発環境をどう整えどう保つか。これはエンジニアそこそこいる会社だと必ず考える話で。マシンセットアップの初期化コストを減らし、その後どう継続するか。 miyagawa さんが言う、うちの会社というのは弊社(クックパッド)のことで、エンジニアの開発環境 OS は Mac。 Mac の上にとりわけ仮想環境の Linux

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

<h3>Rack のセキュリティフィックスと Timing Attack の話し</h3>
<p>さきほど Rack にセキュリティフィックスバージョンが出たんだけど、セキュリティ的に何故に問題があるのかわからなった(Timing Attack をよく解ってなかった) のでメモ。</p>
<ul>
<li><a href="https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07">https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07</a></li>
<li>このコミットで直った。HMAC で生成するハッシュ値の比較チェックを == から別のメソッドで行うようになった。</li>
<li><a href="https://github.com/rack/rack/blob/master/lib/rack/utils.rb#L399-L408">https://github.com/rack/rack/blob/master/lib/rack/utils.rb#L399-L408</a></li>
<li>え、これ戻り値の bool は Ruby の String#== と同一じゃん、なにが問題なんだろう？</li>
<li>攻撃者が指定した digest により、== の比較速度が異なり、HMAC が推測可能になるのが問題<ul>
<li>これが Timing Attack か！</li>
<li>Response Header で X-Runtime を出してると usec 単位で処理時間がばれる</li>
</ul></li>
<li>secure_compare だとバイト列の比較で最後まで舐めるため、処理速度にばらつきが無くなる</li>
</ul>
<p>ﾅﾙﾎﾃﾞｨｳｽﾃﾞｽｿﾞ~。mrkn / miyagawa さんに教えて貰った。</p>
<p>なお Rails は</p>
<pre><code>use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
</code></pre>
<p>な別の middleware で処理をしてるため、Rack の影響は受けない、と。</p>


Rack のセキュリティフィックスと Timing Attack の話し さきほど Rack にセキュリティフィックスバージョンが出たんだけど、セキュリティ的に何故に問題があるのかわからなった(Timing Attack をよく解ってなかった) のでメモ。 https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07 このコミットで直った。HMAC で生成するハッシュ値の比較チェックを == から別のメソッドで行うようになった。 https://github.com/rack/rack/blob/master/lib/rack/utils.rb#L399-L408 え、これ戻り値の bool は Ruby の String#== と同一じゃん、なにが問題なんだろう？ 攻撃者が指定した digest

Rack のセキュリティフィックスと Timing Attack の話し

<h3>GitHub Enterprise TechTalk に見る、各社の運用法</h3>
<p>弊社もバリバリ GHE を使ってるので落ちると開発が回らなくなる(pull request できないのは、master に merge できないのとほぼ等価)ので、他社どうやってるのかーと大変気になってたのでしれて良かった。</p>
<p>間違ってたら教えてくだしぃ</p>
<ul>
<li>クックパッド<ul>
<li>開発者は GHE へ push, webhook でメインの git サーバに同期</li>
<li>GHE の git レポジトリは本番からは利用しない</li>
<li>GHE が死んだ場合はメインの git サーバを向けることで継続開発・デプロイ可能</li>
</ul></li>
<li>はてな社<ul>
<li>開発者は GHE に push したり場合により別のサーバに push したり</li>
<li>GHE から webhook でミラーリング</li>
<li>GHE / 別 git を開発者がうまく使いこなす必要がある。混乱するので git-hatena コマンドを用意してよしなにラップしてる</li>
<li>GHE のサーバは Active Standby 構成らしいけどどうやってるのか聞きそびれた！</li>
</ul></li>
<li>DeNA 社<ul>
<li>開発者は GHE へ push</li>
<li>GHE から各種 ghe- ツールを使いバックアップ</li>
<li>repos は巨大すぎるので ghe- ツールで無くて rsync<ul>
<li>某権限でｺﾞﾆｮｺﾞﾆｮ…仮想マシン上のｳﾌﾞﾝﾂですし…</li>
</ul></li>
<li>構成は Cold Standby 構成</li>
</ul></li>
<li>- VMWare の仮想冗長化はお値段が…</li>
<li>GREE 社<ul>
<li>大場さんがんばって(´；ω；｀)</li>
</ul></li>
</ul>
<p>というわけで</p>
<ul>
<li>GHE が死んで pull request できなくなると死ぬ<ul>
<li>DeNA でやってる Cold Standby 構成で</li>
</ul></li>
<li>本番に deploy やレポジトリ参照できなくて死ぬ<ul>
<li>参照するのは GHE レポジトリで無く別のメインのレポジトリで</li>
</ul></li>
</ul>
<p>が良さそうだナーと思いました。へーしゃも DeNA 社的なアプローチとりたいなぁ。あと GHE も日々進化してるので、そのうちきっと低コストな手法で SPOF が排除される機能がつく…はず…といいなぁ…</p>
<p>あと感想で GHE 使うの苦行だけじゃ、って話しを何件か見たけど、実際 github.com の運用だけで問題ない会社なら</p>
<ul>
<li>github.com を使ったときのセキュリティリスクをとれる</li>
<li>github.com が死んでてもなかない</li>
</ul>
<p>なら、github.com を使うべきですよ。GHE に github.com で実装された機能が入ってくるのにも時差あるし、github .com を使わない理由は無いです。安易に GHE を使うと運用をしっかりしないと死ぬので。</p>


GitHub Enterprise TechTalk に見る、各社の運用法 弊社もバリバリ GHE を使ってるので落ちると開発が回らなくなる(pull request できないのは、master に merge できないのとほぼ等価)ので、他社どうやってるのかーと大変気になってたのでしれて良かった。 間違ってたら教えてくだしぃ クックパッド 開発者は GHE へ push, webhook でメインの git サーバに同期 GHE の git レポジトリは本番からは利用しない GHE が死んだ場合はメインの git サーバを向けることで継続開発・デプロイ可能 はてな社 開発者は GHE に push したり場合により別のサーバに push したり GHE から webhook でミラーリング GHE / 別 git を開発者がうまく使いこなす必要がある。混乱するので git-hatena

A Day in the Life

2013年の日記・記事