Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

RubyKaigi2014 速報(5) – おはよう Rails

  • Ohayo Rails

    • 高井さん進行
    • あれあれ?大きなお友だちの声が聞こえないよ?
    • 大きな声でおはようございます
    • なんでマリ見てパロってるの?
    • 高井さんはしゃべりすぎないように気をつける
    • ちょっとストレッチしてゆるい感じではじめましょう

    • 挨拶・自己紹介

    • クラウドワークス・クオカさん

      • 笑いが足りない(by 高井さん)
    • ドリコム・オオナカさん

      • もっとおもしろいこと言ってください。でも長い。(by 高井さん)
    • mixi オオツカさん

      • モンストのバックエンドはRuby
      • ユーザーは1300万人
      • あとでモンストの裏ワザを教えてくれます(by 高井さん)
    • Oh My Glasses シラツチさん

      • 7人中6人メガネ。全部Oh My Glassesで買いました(by 高井さん)
    • Pixiv コシバさん

      • うちの息子がいとうのいぢさんのノベルティを見て「可愛い女の子だねー」と言ってました(by 高井さん)
    • 食べログ オオイシさん

      • 最近サイトで予約できるようになりました
      • 1個の大きなRailsアプリで動いてます
      • 今日のポイントはオオイシさんがどれだけしゃべるかです。テンション上げてとこう!(by 高井さん)
    • Railsどうよ?

      • StartUpには楽ですね
      • Railsを採用してなかったら僕は入社してないですね。みんなRailsを使いたくて入社してない。
      • Ruby会議ではアンチハラスメント・ポリシーがあって、Pで始まる言語の悪口は自重してください。
      • Railsはデプロイ方法とか色々揃ってて知見が貯まってるのがいいですね
      • 環境セットアップとか楽で、人の入れ替わりが激しくても手順がわかってるのが素晴らしい。
      • bin/setupに書こうとか。いいね。いいよね。
      • ActiveRecordもいいですよね。どの辺がいいですか?
      • ActiveRecord脳になってる。画面を見たらDBの設計が一意に決まるのがいいですね。
      • 他の言語から見たらRAILSは甘え。SQL書けよとか思う人もいる。
      • ちょっとした小手先のこともRubyでできるのもいいですね
      • Arel賢い。対抗馬もなかなかでない。
      • スカラを使ってた期間長いけど、RAILS楽。 他のフレームワークだとORMをすぐ変えようとか言う話になる。 大概のことはできる。
      • いざとなったら生SQLも書けるし。
      • 新卒とかでSQLを熟知してなくても理解しやすい。
      • あ、オオイシさん喋った(by 高井さん)
    • エコシステムとしての側面。テストとか。

      • テストフレームワークとしてRailsを安心して選択できる。要すればGem追加したりできる。
      • Rakeで完結したり。
    • FactoryGirl or Fixture?

      • 違う会社の人とでも何派?っていう話ができるのって実は素晴らしいですね。
      • Redis, Unicorn, MySQL, 等、大体話しが通じるしコードを見たらすぐわかる安心感。
    • とりあえず褒める流れ?

    • とはいえ、とりあえず作ったらGemは100個くらいになる。知らないといけないこと多い。

    • Deviseの中身読んだことある人いる?

    • Deployのこととか。

    • もっとしゃべっていいよ。

    • Capistranoが使えない場面とか。
    • Padrinoみたいなフレームワークを選択するためにRails以外にも対応するGemがあるといいですね。
    • Gemに対応する手段として、モンキーパッチ or Pull Requestがある。
    • Private Gem ServerでFork。
    • ダメだよ、モンキーパッチ。PullRequestでContributeしようよ。
    • 放置されてる場合、「やらないなら俺がやるよ」くらいのスタンスがほしい。
    • Contributeしたくても華麗にスルーされることがある。
    • acts as paranoidとか。公開したいけどメンテはしたくない。
    • Gemのソースコード呼んでからいれたい。闇雲にいれたら後で大変。
    • fluentdとかver.0.x.xのものを使うのは覚悟がいるよね。
    • ログどうしてる?
      • treasure data
      • 内製の分析器版
      • fluentdはアプリケーションレイアーのフレームワークとしても使ってる
    • Gemを使わないと、世界規模でコピペしてる感がある
    • 気軽にGemをいれられる反面、消し忘れが多い
    • 未使用のGemを検出するGemがほしい
    • 正直ガチャのGemを作りかけました
  • 皆のProduction環境の話
  • Job Schedulerとか、非同期の話。Railsももうちょっと対応してほしい。
  • 高井さん司会してください。
  • ゲームはRailsじゃなくてもいいんじゃないの?

    • Railsから乗り換えようと思っても、「Railsのアレが使えない」っていうことが多い。
    • RailsはHTMLを返すにはいいけど、Jsonを返すAPIサーバでなんでRAILSを使うんだろう?
    • 新しく入ってきたエンジニアが簡単に着手できるのが利点ですね
    • 例えば広告だと、モデルが厚くなるけどリクエストを高速に捌くことが要求されてRailsを使わないほうがよくなる。
  • Railsはバックエンド担当になってきて、JSとかNativeと連携しないといけなくなってきた。

    • Railsでsingle page applicationは辛い。そうなるとFront End専用のエンジニアが必要になる。
    • そういうエンジニアにはRubyいれてとは言いづらい。asset pipelineを外したりする。はじめからnodeでいいじゃんって言われる。
    • 最近の若い子はRailsは業務で使うもの、個人の趣味では他のことやってる。
    • RailsRuby書いてて楽しい?Railsのコードを書くことはそんなに楽しくない。頭使わない。
    • 昔は楽しかったのになー。
    • とはいえ、サービスで価値を提供することがあるべき姿で、フレームワークに振り回されなくなったことがRailsの成果。
    • 何で作るかはどうでもよくて、何を作るかに集中できるのはいいこと。
    • Railsで決まりだね。
    • Railsが書きたいわけじゃない若い人たちとどうやって僕らのサービスを育てていくかが課題だと思ってる。
  • 質問

    • ゲーム業界のActiveRecordインスタンス化のコスト、JsonのRenderingコストについて
      • スケールさせるときはRailsを捨ててpure RubySQLを叩いたりします。
      • JsonはViewという考えは捨てた方がいい。別のシリアライズクラスを作った方が速いです。
    • テストが多くなる問題
      • engine, gemでモジュール化
    • 若い人がN+1とか発生させちゃう問題とか、Railsでどう解決するか
      • Bulletを入れるとか
      • リリース前に検知が難しい場合、どうやったら検知が速くなるかを考える
      • dirty query pointを定量化とか。自動検知の方向。
    • 規模が大きくなるとアプリの切り出しが必要になってくる。そういったときのモデルの共有はどうするか?
      • モデルだけのリポジトリを作ってモデル層を共通化
      • API通信
      • サブアプリを使う
      • Engineで切り出す
      • マイクロサービス化