クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

RubyKaigi 2014 1日目 参加レポート by @mumoshu

9/18(木)に開催された RubyKaigi 2014 1日目の参加レポートです。 弊社クラウドワークスも、多くの有名企業に並んでスポンサーをさせていただいているので、全力で宣伝させていただきます！

聴講しながら勢いてまとめているので読みづらい点もあると思いますが、全力で更新していきます！！

f:id:koichiroo:20160112045830p:plain

各種情報

スケジュール

RubyKaigiの公式サイトにスケジュールが掲載されています。

RubyKaigi 2014 | Schedule

Ustream

当日参加できない方向けには、USTが用意されていました。素晴らしいですね!

9:30~ 入場

9:40頃に入場しましたが、受付がスムーズで運営力の高さを感じました！入り口にスポンサーのロゴが貼られていました。

10:15~ オープニング

角谷さんによるオープニングセッション。挨拶や、Rubyが世界中で使われていて、日本はその誕生の地であること、スポンサーの紹介と謝辞など。面白いのはWifiスポンサーで、SIDを自由に付けられる。今回はDeNAさんが「dena_use_ruby」というSIDで宣伝されてましたw

RubyKaigiはセミインターナショナルカンファレンス。通訳あり。通訳ありのカンファレンスって運営が大変なのに、やりきるRubyKaigiすごい。

10:30~ CRuby Committers Who's Who in 2014

次は近永さんにバトンタッチ。 日本やRubyKaigiにはCRubyコミッタが多く集まるので、今回はその人達に質問できるセッションがあります。セッションは所定のはっしゅた　

CRubyにはbotも含めると84ものアカウントがある。個人的な印象としては多い。人間だけでも50人。それぞれ紹介する時間がないので、特に面白そうな人を紹介。今年のRubyKaigiでスピーカーになっているコミッタは、15人。うち三人はキーノートスピーカー。それぞれ発表順で紹介。

Tomoyuki Chikanaga, @nagachika さん at Groovenauts, Inc.

  • Rubyの2.1 branch maintainer
  • ruby-trunk-chanegs日々のRubyへの変更を日本語ブログに書く、という活動
  • RubyPrize 2013受賞

Koichi Sasada @ko1 さん at Heroku, Inc.

Ruby VMの開発がお仕事。Speed Freak, 昨年はRGenGC開発、今年はIncremental GC開発。Incremental GCはもうtrunkに入っているので、次のRubyバージョンでは使えるようになるはず。それぞれsweepを細切れ、mark&sweepを細切れにする。

ko1さん、ご結婚おめでとうございます！ちなみに、お相手の鳥居さんもスピーカー。スーパーカップルですね。

Narihiro Nakamura, @nariさん

Mr. GC, Lazy Sweep/Bitmap Marking, ko1さんに対抗して、今年はSymbol GC開発。次のRailsバージョンはSymbol GCが欲しいがために、Ruby 2.2以降のみをサポートするらしい。つまり、Ruby 2.1がオワコンになるので、メンテがんばりましょう！

matz

Yukihiro "Matz" Matsumoto

The Creator of Ruby

現在は言語デザイナ(Language Designer)、NaCLのフェロー、Rakutenフェロー、名誉市民、など一枚のスライドに書ききれないくらいの 技術顧問とか行ってあ行った、親長さんもしならい

matzのコミット。

去年のRubyKaigi以降、matzのコミットはこれだけだったw このようにRuby自体の開発はしないものの、Rubyの新機能に関わるジャッジ(新機能を入れるべきかどうか)はmatz。

Kazuhiro NISHIYAMA, @kazuさん

  • 'fiz typo' ratio 97 / 143 = 68%。Mr, fox typo

Hiroshi SHIBATA, @hsbtさん at GMO Pepabo, Inc.

Administrator of *.ruby-lang.org (www, bugs, ML)

  • Test edge ruby (trunk) on raiils

RailsがエッジなRubyで動くかどうか、率先して地雷を踏んでいる。みんな知らないうちに恩恵を受けているはずなので、あったらお礼を言ってあげてください！

Shota Fukumori, @sorah at Cookpad Inc.

  • test/unit maintainer -> dropped from stdlib
  • parallel test

Cookpadで発生したRubyの問題などをRubyにフィードバックする。 最年少コミッタ、Cookpadでは非常に頼りにされるアニキ。 今回のセッション内容はデプロイの高速化、という骨太な内容。

Kouji takao, @kouji

  • Readline extension maintainer
  • MacRuby Commiter
  • Ruby Programming Shounendan

Kazuki Tsujimoto, @ktsj at Nomura Research Institute, Ltd.

  • VM Bug Hunter, ややこしいバグの修正パッチを投げてくださる方
  • Pattern Maching (pattern-match)
  • Power Assert (test-unit-power_assert)

今回のセッションでも、Power Assertについて聞けるらしい。

Aaron Patterson, @tenderlove at AT&T -> RedHat, Inc.

  • psynch/dl/fiddle maintainer
  • Rails Commiter
  • NokogiriというXMLパーサの開発者。かつてのリリースメールTakoyaki Kamenという小話がついていて、楽しみにされていたらしい.w

最近RedHatに転職されたそうですが、RedHatはJRubyコミッタを擁しているので、今後の活動にも注目。

Keiju Ishitsuka, @keiju

  • Rubyという名前を提案した方、Ruby's godfather
  • irb author & maintainer
  • 最近はirbのバグ修正などでご活躍

Masatoshi SEKI, @seki

  • dRuby/rinda/erb author & maintainer
  • 今回紹介している15人の中で、唯一RubyKaigi以降一回もコミットがない。これらプロダクトがいかに枯れているかわかる！
  • 今回のセッションは分散処理について

@zzak

  • Documentation maintainer
  • rubygems, rake, rdoc contributor
  • Conference freak
    • England, Singapore, Maxico, Scotland, Taiwan, Japan, Phillippines, India, Australia, South Africa Belgium, ...去年のRubyKaigi以降20カ国のカンファレンスに参加し、17カ国はスピーカーとして登壇。すごい。
  • 今回のセッション内容は「Rubyのエコシステムに対してどうやって貢献していくか」

Kouhei Sutou, @kou at ClearCode, Inc.

  • rexml/rss/xmlrpc maintainer, XMLにかかわるところ
  • テストがちゃんとかかれていたり、リファクタリングと変更のコミットがちゃんと分かれていたり、今どきのきれいなコミットをされる方で、毎日コミットを読む側としては大変ありがたいそうです
  • Groonga

Aaron at GitHub, Inc.

  • 最終日のKeynoteスピーカー
  • Rubyのコアに精通している
  • Memory Optimizations
  • Inspection/Profiler/Debugger
  • Hash#[] optimization
  • ObjectSpace.dump_all
  • ko1さんとコミット領域が似ていて、ko1さんの愉快な最適化仲間の一人。
  • 今回のセッション内容はたぶん「実行中Rubyプログラムの状態を見る方法」

Rubyの開発にはたくさんの方が関わっている、ということが伝わると嬉しい、とのこと。

11:00~ スポンサーアピール

Cookpad株式会社技術部長のたかいさん。

Cookpadは国内最大のレシピサイト。178万レシピが投稿されているサービス。Cookpadは3つのチャレンジをしている。

  1. 食のプラットフォームとしてレシピ以外のサービスを開発すること
  2. プロのレシピ、料理動画、おでかけ情報共有
  3. Mobile First
  4. アプリはiOS 10.1M, Android 9.9M ダウンロード
  5. ＞突然のモバイルファースト＜
  6. 海外展開
  7. インドネシアのサービスを買収して、CTOが駐在している。

  8. 生ハムがバナナのように売られている写真。

  9. RubyKaigi 2010~2014まですべてスポンサーをしている（拍手）

  10. Rubyのコアデベロッパ三人とRubinius開発者も一人。技術ブログもあり。Rubyの良き市民を目指している。
  11. 今日、garageというライブラリがオープンソース化。

Cookpadさんエンジニア採用中！

11:00~ キーノート: Build-up Ruby interepreter - What is easy and what is difficult? by @ko1

「2014年というのは私にとってとても重要な年でした」

「明後日、結婚記念日」

「Rubyを通じて知り合ったので、このような場でご挨拶させていただいて光栄です」

Ruby 10th Anniversary

  • 10年でここまで来たか、という思いと、10年でまだここまでなのか、という思い
  • 何が簡単で、何が難しかったかという話
  • Ruby developmentのEasy partとDifficult part
  • これからRubyがどこに進んでいくのか、どんな課題があるのか
  • A programmer, CRuby developer since 2007
  • Member of Heroku Matz team
  • Fulltime CRuby developer with Matz and Nobu since 2012
  • One of the directors of Ruby Association since 2013
  • Herokuまでは大学の先生(!)
  • Ruby Associationでは500,000yen/projectで3project公募しているので気軽に応募してほしい
  • Herokuは今年のBentoスポンサー、Herokuの本も出ました

Understanding Computationの日本語版を手に「この本の監訳をしました」

Who am I

  • YARV: Yet Another RubyVM (1.9-)

私にはRubyはこんなふうに見えています。Ruby Intepreterの部分をつくっています

  • 2004/01/01に暇だったから始めたものが10年続いて、やってよかった。

  • Fiber (1.9-)

    • 他の言語ではコルーチンやセミコルーチンと呼ばれるもの。
    • Fast Context Switchを実現
  • New method cache (2.0-)
    • Flonum (on 64bit CPU) (2.0-)
    • Embedded "double" into VALUE like FIxnum: About 2 times faster
  • RGenGC: GEnerational GC for Ruby (2.1-)
    • Introduce RGenGC by inventing "WB-unprotected" objects technique and reduce marking time dramaticaly
    • Incremental GC by same technique (for Ruby 2.2)
      • See Rubyist Magazine vol. 0048 or attend RubyCOnf2014
    • About 15x speed-up!
  • Performance
    • Ruby to C compiler
    • Ruby to C# compiler
    • などなどの開発も研究プロジェクトでされていた
  • http://www.atdot.net/~ko1/activities/ にすべてのアクテビティを書いてある。書いておくと、履歴書つくるときに役に立つ。（いつ転職するかはわからないけど・・）

本題: Ruby developmentの何が難しくて何が易しいのか

  • ミッションは「クオリティを高めること」
  • ちゃんと動くこと(RUn Ruby program correctly, No bugs!!)
  • 速く動いて文句言う人はいないので、なるべく速く動かす
  • 省メモリ・省エネルギー
  • 拡張性
    • Ruby intepreter自体がどれくらい手を入れやすいか。バグ修正やワクワクする新しい機能を実装しやすくするために。
  • トレードオフ
    • Performance <-> Reliability
    • Performance <-> Low resource
    • Performance <-> Compatibility
    • Performance <-> Extensibility (速度のためにコードをぐちゃらせると、手を入れづらくなる)
  • トレードオフを知り、
  • Rubyはlanguage powerと読みやすさ・下記やすさのトレードオフを乗り越えて生産性を向上させてきた

Serial execution Pperformance, Paralle execution performance, GC performanceの話

  • VMをシンプルにつくるだけならそんなに難しくない。それを人間が管理可能な形で置いておくとか、最適化をちゃんとやるのが難しい。Cコードとの相互運用性も難しい。
  • Add bytecode incrementally
    • Increase support ruby features
    • For YARV, ruby has an answer set! (test case)
  • Loop fetch and execute instructionsするだけの、
    • "Implementing block data structure is hell"

ブロックの実装にあたってはこういうことをちゃんと考えないといけない

  • VM記述言語をつくって、それでVMを記述することで保守しやすくした

  • Aggressive optimizations

    • Method/block inlining
    • Constant folding
    • Partial redundancy elimination (PRE)
    • Lambda lifting
    • ... (many well-known traditional optimizations)
  • Key technique is DE-OPTIMIZATION
    • 90年代のJavaやSmalltakは既にやっていたが、これが難しい
    • 最適化されたコードを、必要なタイミングでまた元に戻す
  • Inteoperatility with C codes
    • C code is low-levle, faster than Ruby's code
    • Howevefr, C code doesn''t have internal details which aggressive optimization requires
    • Most of Java class libraries are written in Java program -> Rubiniuys Way

Parallel executionどうするか

  • EASY: 並列スレッドを提供する
    • 博士論文を一部はRuby上で並列スレッドをどう作るか
  • HARD: 単純に並列スレッドを提供すると、スレッドプログラミングが大変なので、Rubyを書くことが辛くなる、プログラマハッピーでなくなる。
    • プログラミングモデルの改善やデバッガの提供が必要
    • あらゆるところで動機が必要
  • "Why Threads Are A Bad Idea (for most purposes)"
    • Quoted from John Ousterhout, 1995

VisualBasicはだれでもできるだろう、C・C++はもっとwizardより、スレッドプログラミングはwizard中のwizardでないとできない

  • 問題は「すべての状態を共有しているので、一つでも同期を間違えるとバグる」
  • よくあるバグ: Data race, Atomicity violation, Order violation
  • Non-deterministic nature
    • Bugs are not reproducible
    • デバッグがすごくつらくなる
  • こういう経験をRubyでしてしまうと、RubyがFun/Happyでなくなってしまう。だからRubyに並列スレッドをそのままは入れたくない
  • 対策
    • Educate programmers: しかし人類がスレッドプログラミングをできるようになるのかという問題がある
    • 他のツールを提供する

工夫すればセーフコードが書ける、セーフコードしか書けない、という2種類ある。 いまは書きやすくて安全なものをみんなが探している状態。

他の言語でのアプローチ

最高性能を出すためにはスレッドプログラミングは確かにはやい。ちゃんとやれば動く。でも人間はミスをするので、デバッグが大変になる。 free() vs GCの話と同じで、わかってる人はfreeすれば速いが、人間はミスをする。RubyはGCの改良で高速になった。

  • IDEA
    • プロセス間通信を良くする
    • MVM: Multiple virtual machines
      • 小さなRubyVMを複数動かす
    • "owner threads" for each object
      • それはそれで、グローバルなアクセスをどうするかが難しい

すごく面白いテーマなので、誰か一緒に考えてくれるとうれしい。

  • Non-deterministic behavior kills programmers
  • Many research on thread debugging tools
    • detecting inter-thread conflicts
    • Change OS scheduler to make programs deterministic
  • GC Performace
    • 世代別GCのアルゴリズムを書くのは簡単。100行くらいでかける。でも、でもそれをちゃんとバグ無く書くのが難しい。
    • Write barrier technique is required for many GC algorithms, but it is difficult to insert WBs correctly because of compatibility issue
    • Non-deterministic behavior: GC bugs appear in unexpected place.
    • Solution: Debugging feature
      • GC.stress: invoke GC many times forcibly
      • CHeck assertions
        • List up all assertions
    • detect write barrier miss
      • "Old objects should not point new objects"
      • バグでwriter barrierの入れ忘れによりこういう状態になる可能性があるのでassert
    • ベンチマークの実行自体は簡単だが、何をはかるか、継続的にどうやるかが難しい。
    • ベンチマークのため、早いマシンがねむってたら、貸してください!
    • 何をはかるか
      • microbenchmark
      • discourseというRailsアプリのベンチマークスイートを使っているが、これしかないのでRubyがこれに最適化されてしまうw 他の使いやすいテストスイートを提供してくれると嬉しい。
    • Ruby 2.1以降「メモリ消費量が増えた」という話を聞くが、それはピークなのか平均なのかメディアンなのか
    • Rubyコミッタになるのは簡単。
    • でも、Ruby開発者になるのは難しい。
      • Ruby開発者とはモチベーションを保って継続的にRubyを開発する人。
      • Ruby開発者を増やすこと。
    • 学習用のリソース
      • ko1さんは「Rubyソースコード完全解説」という本を読んでRuby開発者になれた。
      • Ruby Under a Microscope。現在日本語へも翻訳中。

メッセージ

12:00~ ランチブレーク

午前の部は終わりです！Have a nice bento！

ランチ画像など

13:30~ Controller Testing: You’re Doing It Wrong @ Hall B

By Jonathan Mukai-Heidt, @johnnymukai at Groundwork

TDD・Testingなどの慣習がRubyにはある。その目的は:

  • Catching regression
  • Developing code in isolation

よくあるコントローラテストのアンチパターンを紹介してから、どう解決するかを紹介。

  • Controller Testing Hall of Shame

    • Stub all the things
      • 意味のないテストになってしまう
    • Everything is integration
      • すべてがCucumberのfeatureになっているとか
    • render_views
      • 聞き取れなかった・・・
    • No tests at all

  • Controllers often have a big action and small details

  • Authentication, Loeading
  • Small converns are actually very important
  • I was also confused
  • Rails controllers + responders are awesomely declarative
  • What do we really mean when we say declarative
  • Imperative/Declarative
  • Imperative
    • When deleting a user, if the current iuser is an admin user, then allow the deletion; if the current user is not an admin, do not allow ...
  • Imperative
    • When a request fora resource comes in , if the rquesit is for JSON ....
  • Declarative this conroller restusn a resource erepstened as jONS or HTML Look at how declarative Rails controlelrs can be

before_filter

before_filer :authenticate_user!, except: :show
before_filter ::load_some_model, ...

Authorization

authorize_actions_for SomeResource
load_and_authorize_resource :foo

Rails4 + Responedrs

respond_to

respond_to :html, :json
def new
  respond_with @foo
end

Little to no logic in controllers

  • Skinny controllerを目指す。
  • "It's not what 90% of the controllers I come across look like."
  • What do we really care about in controllers?
    • Authentication
    • Authorization
    • Presence of resource
      • What resource are we working with
    • Response
  • Tests should help us write better code
  • Shared examples cover the small details
  • Big actions can be simple
it { should assign(:some_resource) }
it { should change(Pizza, :count).by(+1) }

Authentication

各controllerのspecで個別にやるのではなく、shared_examplesを使う

shared_examples_for "an action that requires a login" do
  # ...
  before { sign_out :user }
    it should { ... }
  end

以下のように使う。

before { sign_in(:user, current_user) }

...
it should_behave_like "an action that requires a login"

Response

Authenticationをshared_examplesを使ってテストする方法と同様に、HTMLなどに応答するということをshould_behaves_like...で表現。

Ever since I began Rails work people

What about

ActiveModel is awesome. ActiveModelを使ってSkinny Controllerを実現。

DBとやりとりしないModelはCheap。

Password Resetの例

  • Client wanted to overhaul a legacy password reset workflow
  • Email間違った時にエラーにどうしたい
  • 既に退会していたらどうしたい

  • 突然のFat Controller<

"Think nouns, not verbs"

Footwork

  • No gem!
  • This will vary from project to project
  • Figure out how your project will handle these situations

Habbits

Controller Checklist

  • Rewards
    • Easier to test
    • Drives good design
    • Uniform controllers == Less dev time

14:00~ Continuous Delivery at GitHub

By @rsanheim

  • どうやって一日に50回ダウンタイムなしでデプロイするか
  • https://github.com/blog/1110-rob-sanheim-is-a-githubber
  • What is Continuous Delivery?
  • Key Point is: "Software ready to be deployed at any time"
  • Ship more frequently
  • Why should we care?
  • All the things are changing quickly
  • Besides... Shipping is fun
  • CI is way more fun
  • サイクルが長いと、使われないもの開発に時間をかけてしまうことになる可能性が高まる。サイクルが短い方が、Changingな世界では有効。

ポイント

  • Automation
  • Tests
  • PRs
  • Feature Flags
  • Chat Ops

Automation

プラクティス：同じことを2回やったら、自動化すべき

Tests

  • test/models
  • test/integration
  • test/controllers
  • test/lib
  • test/view_models
  • test/jobs
  • test/mailers

PRs

フィードバックは早く受けられれば受けられるほどいい。 例えば、6行しか変更がない状態でPRを開く。そしてディスカッションしながらPRを育てる。

Feature Flags

def live_update_enabed?
  logged_in? && current_user.staff?
end

全公開するときは、Feature Flagのメソッドで必ずtrueを返すようにする。

Chat Ops

Hubotでつくりこむ。

Rails 3アップグレードの話

  • Long lived branches are a smell
  • timeboxを区切ってリリースしてみる。必要ないものだとわかったらkillする。
  • rails3-reduxブランチをつくって長々と育てるのではなく、早めにmasterにマージ。
  • RAILS_VERSION環境変数によってrails 2、3どちらでもbootstrapできるようした。
  • Gemfile内でもif rails3?でロードするgemを切り替え。

リリース後

  • github/dat-scienceでPDCAをまわす
  • リリース後はtwitterでユーザの声に耳を傾ける
  • "Collect Feedback …and act on it" 正しいフィードバックを受けて、それに対応することが重要。

締めのメッセージ

"Getting started today"

"More flexible, more adaptable, more money, more fun"

14:30~ What is your app's problem? @ Hall B

By Keiko Odeira, @keiko713 at Heroku, Inc.

  • サポートチームのメンバー紹介
    • matz、ko1、nobu、HerokuのRuby、Japanに強いメンバー紹介
  • HerokuはZendeskを使っているが、"my app is down"で検索してみたら263 resultsもヒットした。今回はアプリが"down"した理由のトップを紹介
  • 先にネタばらしをしてしまうと、大抵の場合、アプリが何か間違ったことをしていることが原因

H12エラー

= "request timeout error"

  • 原因は遅いリクエスト
    • NeRelicやログをみる。コード、外部サービス、DBの問題がないか調べる。
  • 突発的なトラフィック
    • "Sudden traffic spike can cause downtime"
    • dynoを増やす。裏側のDBが増えたdynoに対応できるだけのキャパシティをもってることを確認しておく。

Memory quota exceed

  • アプリが制限以上のメモリを使うと超遅くなる
  • 短期的にはアプリを再起動する。
  • Ruby 2.1からメモリ消費が増えた。
  • メモリリークの可能性もあるので、ツールで見る。

いますぐ初めて欲しいこと

Loggingしましょう

  • Herokuは1500行しかログを保存しないので、logging add-onsを使いましょう。

モニタリングしましょう

  • まずNewRelicから始めることをお勧めします。

15:30~ Non-Linear Pattern Matching against Unfree Data Types in Ruby (Egison Pattern Matching in Ruby) @ Hall A

バッテリー切れでメモできず(´・ω・｀) InfoWorldで"Top 10 programming languages on the rise"にも選出されたプログラミング言語Egisonと、そのパターンマッチ部分をRubyに移植したegison-rubyの紹介。

質問では、

  • 速度はどうなのか? → 大丈夫ではないか
  • 実際どれくらい読みやすいのか? → 知り合いのプログラマは3時間で読めるようになった

というやりとりがされてました。

16:00~ Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails @ Hall B

APIは変化に適用しなければならない

  • APIには2種類ある
    • Public
    • Private
  • 変化は避けられない。Web APIは変化に適応しなければならない
  • Changeには2種類ある
    • バージョンのあり・なし
    • 後方互換性のあり・なし
    • クライアントを壊す・壊さない
  • 後方互換性のない変更はNG
    • クライアントに変更を強要してしまう
  • 密結合
    • 本当はAPIの変更がクライアントに自動的に反映されてほしい
  • API Callの考え方は危険。

APIをよくするため、密結合を避ける

  • Hypermediaの考え方を取り入れて、最初にリクエストしたURLが返したレスポンスに含まれるlinkをfollowするだけにする。
  • HTMLの例。HTMLではリンクとフォームでワークフローが表現されている。Hypermediaがワークフローを表している。例えば、各画面にはブラウザが次に何をできるかがメニューのようにすべて書かれている。
  • クローラの例。クローラはリンクをfollowしたり、フォームをsubmitしたりできる。クローラはHTMLドキュメントの意味を理解している。どうやっているのか?
  • Microdataの例。itemtype・itemprop属性でHTMLドキュメント内に構造化されたデータを埋め込むことができる。これにより、データを変えること無くドキュメントの構造を変えることができる。
  • schema.org。Bing, Google, Yahoo!, Yandexなどが進めているプロジェクト。
  • MicrodataのJSクライアントもあるが、たぶんJSON Web APIにしたいはず。どうすればいいか?
  • 一般的なJSON Web APIにはlinkとformの概念が足りない。
  • JSON + Link header, HAL, JSON+LDなどのJSONの拡張を使う?

Hypermicrodata gem

  • Hypermicrodata gemを使う。
    • HypermicrodataはHTMLをサーバサイドでJSONに変換する。
  • Hypermicrodata gemを使ってRailsでAPIを実装する例
    • Design resources: 普通にrails g model Note text:text published_at:datetime
    • Draw a state diagram: クライアントの視点から状態遷移図を書く。
    • 状態遷移図ではunsafe(安全でない)、non-idempotent(べき等でない)な遷移を区別する
  • rel属性がpublish、next、prevのようなlinkやbutton要素を場合によってドキュメントに含める。これにより、クライアントは次に何ができるかがわかる。
  • この手法の利点
    • DRY: HTMLとJSONを同時に提供できる
    • リンクとフォームがある
    • Constraints
  • この方法を使わず、JSONを直接書きたいときでも、まだやれることはある
    • link/formパターンを意識するため、状態遷移図を書く
    • APIを疎結合にする。そのために、model.to_jsonの代わりにViewテンプレートやJbuilderやRABLを使う。
    • "Webを支える技術"

まとめ

  • Web APIは特別なものではない
  • JSONにはデファクトスタンダードなフォーマットはない。
  • RESTの原理原則と制約を意識することで、少し良くできる
  • HypermediaはRESTの重要な要素の一つ
  • "Build a Better & Adaptable Web API!"

16:30~ JRuby 9000 Project Update @ Hall A

By Thomas E. Enebo (@tom_enebo)

  • JRuby 9000はJRuby 1.7系とは別で、CRuby 2.2と互換。
  • JRuby 9000
    • Ruby 2.2
    • New runtime (IR)
    • Major IO and Encodings overhaul
    • Code removal/deprecations

New Runtime Internal Representation (IR)

  • IR導入の理由
    • AST to semantic representation
    • Traditional Compiler Design
    • Wanted Architectual longevity
  • 意味解析がCFGからIR Instructionsを生成、最適化はCFGをみる、Byte code生成(JVM、Dalkvik向けそれぞれなど)はこれらと別
  • それまでのJRubyでは密結合だった
  • 意味解析が例えば何をやるか
    • superの簡単化。
  • set_trace_func
    • On-demand instrumentation possible
    • Trivial to JIT
    • Very easy to understand in source
  • 最適化
    • Dead Code Elimination
    • Constant Propagation
    • Method+Block Inlining
    • Unboxing wrapped types
    • それぞれプラガブルなコンパイラーパス（プラグインのようなもの?）で対応
  • IRとJVMのミスマッチ。IRよりJVMのほうが制約が強い。
    • Javaの場合、tryブロックのローカル変数はfinallyブロック内から見えない。Rubyの場合、beginとrescueは同じスコープ。

IOまわりの改善について

  • JRubyの問題
    • JRuby 1.7xはRuby 1.8.xと1.9.xの両対応。M17n対応の違い、それぞれのコードが混在してしまう。
    • byte -> char -> byte[]というJDKのtranscodingが非効率的
  • 解決方法
    • Port: MRI IOサブシステムをポートする
      • MRIのIOと同じバッファリング戦略等
    • 結果: JRuby 1.7.xと比べて高速なTranscoding・IOも高速化
  • 9000のTODO
    • 起動高速化。現状は1.7.xと比べて最大30%起動が遅い。
    • Parser高速化(10~20%)
  • MRIとの互換性
    • Refinements
    • freezeされた文字列
    • coreにある85個くらいのメソッドがまだない
  • Java Heap != Ruby Heap
    • Java Heap (hprof) -> Ruby Heap (JSON)に変換するalienistというgem
    • そのビュワーalienist_viewer(Railsアプリ)
      • Rubyのヒープの内容（オブジェクト）をWebアプリ上で見ることができる

Ruby Committers versus the World

Twitterや会場で集めた質問にRubyコミッタの皆さんが答えるコーナー。

  • 明日のキーノートで公開?!

会場から質問

  • Perlのローカル変数/ダイナミックスコープがRubyに入ることはありませんか?
  • matz「人類には早すぎた。諦めてください」
  • @nagachikaさん「理由を書いて欲しい。あと、ついでにインデント修正とかはやめていただきたい！」
  • 「一人天才がいるので、その人がメンテしてます」(!)
  • matzはぼんやりとActorを考えているが、いつ入るかとかは決まってない
  • matz「macroは入りません。neverっていうな、って書いてるから、絶対」
  • matz「macro書くくらいなら、Rubyの場合はコードジェネレータ書いてください」
  • matz「とりかかってもいないプロジェクトの完成予定はわかりません！」
  • そういえばMac版Rubyのメンテナがいない
  • ARM版まじめにメンテしたほうがいいよね
  • Ruby Associationでやってます
  • さっきRuby 2.2のPreview 1がでました（会場拍手）
  • 今のうちに各自の環境で2.2 Preview1を動かしてみてください。このままリリースされるとお正月くらいに大変なことになりますよ！
  • 警告は出る?
  • エラーにするようなモードがRubyにあってもいいかも。さっき話題にでたstrictモードとか?
  • 既に.!メソッドがある (もう何年も前からあったようです)
  • "Write lots of tests"
  • 他の人にコードを見られる環境に身をおくこと。ちゃんとしたものを書くモチベーション
  • 拡張しようとするとハマるので、最初からプラグイン機構をつけておくこと
  • Rubyで上手に書く方法と、他の言語で上手に書く方法にあまり違いはない
  • 開発者のレベルではmrubyにもアテンションがある

この記事で利用している素材について

この記事でも利用しているRubyKaigiのロゴ・バッジ・バナー画像は、RubyKaigiの公式サイトで配布されています。

RubyKaigi 2014 | Goodies

様々なサイズが揃っていて嬉しいですね！ 記事を書く際にライセンス的に利用して問題ない画像を探すのに時間をかけなくて済むのは大変ありがたいです。

© 2016 CrowdWorks, Inc., All rights reserved.