RubyWorld Conference 2013 1日目にとったメモです。
個人メモなので誤字などご容赦ください。

全体関連リンク

Aiming the Moving Target

by matz

1990

1990年に社会人
その会社ではプロジェクトは3年単位で動いていた

  • 日本語で設計書書いて
  • それをそのまま実装
  • テスト
  • 納品

スゴく詳細なドキュメント
ドキュメントは厚さ(センチ)ではかってたくらい
ウォーターフォールだった

なにか違うと思ってたが説明できなかった
経験もなかった
20年経った今は説明できるようになった

間違った前提

その1

「なにを作っているか把握してる」
と、思ってること

softwareは物理法則に制限されない
最近は記憶容量大きくなりプログラムサイズは制限されない
いまや、もっとも複雑な被造物といえる

人間の能力を超え、ドキュメントでカバーできない
ソフトウェアは柔らかくない
ソフトウェアはハード(固く、難しい)

更新は大変

その2

「何を作りたいか把握してる」
なにをしたらビジネスが成功するかわかっている人は少ない

ソフトウェアを使った時の状態を想像するのは今も昔も難しい
納品すると大体、「私が思ったのと違う」

上司や顧客がバカ扱いになりがちだが
何を作ったらビジネス価値を最大化できるか分かる人は少ない
実際はみんなバカだった

その3

「状況は変化しない」という前提

対策

無知であることを認めるべきだった
我々ができることは少ない

保守的戦略

過去から学ぶ
状況が変化しないなら、良い戦略
ITでは変化が激しいので成立しない

アリスの赤の女王いわく、
留まるには速く動き、移動するにはもっと速く動かないといけない

ダチョウアルゴリズム

ダチョウは砂嵐きたら砂に頭を埋める
なにもかも投げ出して、ただ待つ
冬眠も似てる

状況が回復するなら良い戦略

これまでの2つの戦略

ここまでの2つは現実に反しており、おとぎの国に向かうような戦略
20年前は上記の戦略をとっちゃってた

コンピュータは高価で持っているだけで差別化できていた
ネットワークも高価
なので失敗しないことを最優先してた
たとえ満足度を犠牲にしても

それが唯一のソフトウェア開発の方法であると信じたかった

いまは持つだけでは差別化できない

いまもすごいソフトウェアの作り方は分からない
無知の知

コンピュータ、クラウド、ネットワーク安くなった
ソフト開発も安くなった
ツールとか言語とかのおかげ

以前は海外にメールすることもできない世界だった

rubyはたくさんの海外の方からサポート
母国語や住んでる場所、性別もしらないこともある

いまや、巨人の方に乗ることができる

試行錯誤(try & errors)

何度でも挑戦できることが必要
コスト最小化が大事
そこをrubyはサポートしてきた
それができるようになって初めて動く標的を狙うことができる
Aiming the Moving Target

動くターゲットとは本当に価値のあるソフトウェア
価値は人間の欲求に基づく

リリースがいまや個人でできる
プリウスは一人でつくれないだろうが、
ソフトウェアでは一人でつくったもので世界を変えられる
当たらなかったらピボットできる

「安く速く何度も」が成功の秘訣

アジャイルもそれを反映している
変化に対応する

成功するかは分からないが成功確率は上がる

自戒を込めて、
熱心にコードを書かない

複雑になり失敗したときのダメージも大きい
コードを書かないために熱心に働く

最初のボールだけ転がして、みんなに頑張ってもらう
rubyもひとりで作っていない

ここも巨人の肩にのる

競争力維持に必要な物以外はOSSにしてしまうのが正しい戦略
コアパートも小さくとどめる

OSSの定義にはないがコミュニティというのは不可欠
OSSでなくてもコミュニティは有効だろう

プロジェクトを最小化し、プロジェクトの組織というものが解体されるだろう
技術ベースでプロジェクトをわたり歩くようになるだろう

OSSコミュニティはサメ
進み続けなければ、死ぬ
大部分は技術的に面白いことで参加してるので、止まると人が離れる
rubyもコミュニティ開いたり、新しい技術応援したり、カンファレンス開いたりしている
OSSでなくても進み続けることは必要だろう

アリスの世界と同様、なるべく速く、何度もためして、何度も撤退すべき
そして大局的構造を変えられるだろう

「失敗したら終わりだ」から「失敗してもいい」へ
まずは失敗をナイストライに言い換えるところから

コードかかず、
いいソフトウェアをつくり、
世界を変えよう

QA

これからrubyで挑戦したいことある?

webでは流行ってきてるがもっと広い世界で使えるようになるといいと思う
たとえば大学の科学技術計算など助成してる

あとはmrubyで組み込み目指してる

公開するもの公開しないものの判断は?

競争力に関わる物であるか
最小になるか

たとえばビジネスロジックだけ出さない

クックパッドをすべてOSSにしても問題ないと思ってる
レシピ・ユーザデータが大事


Speeding up Rails internals using unique Ruby techniques.

by Aaron Patterson (AT & T)

Yak Shaving

バグを見つけたらわかるまで調べてる
なのでYak Shavingになる
よくコンピュータ壊す

とあるバグ報告の調査を開始

シンボルはGCされない
Dos攻撃になるのが心配なので文字列にしたが遅くなったとの報告
rubyソースを追った

とあるソースでruby安全性と速度を担保するには?
=> 定数を使う

2.1のフローズン文字列を使うと、安全で速い

しかし、define_methodはmodue_evalより遅いとのコメントがつく
そこでベンチマークで確認した
たしかに遅かったが
しかしdefine_methodは異なるインタフェースも用意されており、そちらで呼んだら速度改善した

メモリ使用量についてもコメントあったのでベンチマークをして調査した
module_evalのほうが消費する

速くて、メモリ使用量も少ない方法はないか?
を考え改善に至る

数値列(?)からselectすると文字列で返るというバグから始まり、
rubyのVMを学び、
DoS攻撃の対策になり、
railsの高速化に寄与でき、
railsのメモリ効率がよくなった

ただしバグはまだ直ってないがw

大事なことは
「知りたがりましょう」

QA

どれくらいそのバグ修正時間かかった?

1monthくらい
まだ直ってないがw

どれくらい日本語勉強してる?

日本語は7年勉強してて
プレゼンは3週間くらい練習した


クックパッドの継続的デリバリー

by 高井直人 (クックパッド株式会社)

20M UU/month
1.5Mrecipes

14432 testsが
10minutesで終わる

デプロイ頻度
11+ deploys/days

継続的デリバリーの方法

デプロイメントパイプラインで行う
今日はこれに追って解説

DBは本番のものをレプリケーションしてdevで使ってる
少ないデータでは遅い処理検知できない

github enterprise使ってる

テストは分散実行してるので10分で終わる

ブランチ戦略

GitHub Flow
feature toggle
ターゲットユーザに新しい機能出してる
それをするのがchanko

ハロウィンデザイン

chankoで時期になったらフラグたって表示される
デザイナがpull requestだしたり
それがレビューされてデプロイされる

月間 800 くらいのpull request

github enterpiseがEC2で動かないのでサーバわけてる

clone pusherをsinatraで作成
omkinsというjenkinsで管理してる
hipchat連携してる
プラグインは公開してる

CIサーバは8くらいいる
テスト増加にあわせて増えている
目標時間を10分にしてる
その時間もhipchatに出してる

テストは本番と同じ環境のSTGで実施

最新のCI通過分が
平日の9:30am - 5:00pmでデプロイされる
金曜は3:00pmまで

bundle exec cap production deployでデプロイ

デプロイ後はhipchat, wikiに自動で投稿される
infraµモニターおかしかったら、インフラ担当がログ見る
音も出せるが使われてない

デプロイしてほしくないときは
deploy:lockも用意してる
たとえばバグでロールバック中、サーバスケール中とか

QA

DB migrationはどうやってる?

devは変えたいタイミングでやってる
変更時にdumpしてgithubにpushしてる
本番はインフラと相談しながら

CI のメンテナンスに割いてるコスト割合は?

むらたさん、ふくもりさんの2名

ソース全部公開する予定とかは?

依存してない部分は抽象化して出してる

  • chanko
  • 分散テスト環境(予定)

JRubyを用いたRailsアプリ開発の実情

by 三好秀徳 (株式会社日立ソリューションズ)

自己紹介

  • OSSフォーラム推進
  • yokohama.rb
  • ruby world conf 2012のまとめしてる
  • るびま編集者になった

Jrubyの紹介

  • Java API使える
  • 処理速度はCRubyと遜色無し JVMの起動がボトルネックになることはある

Jruby使う理由: Javaの資産を活用したい

実例

内製Accesssアプリケーションの移行の話 メンテナンス性と速度が低下していたので移行になった

用件

  • パスワードzipファイル出力
  • excel出力
  • 既存のJavaサーバで動かす

=> rubygemsから使えそうな物をピックアップ => warblerでwarファイル化

gemの選定

xlsを使えるgem

  • spreadsheet
  • axlsx

それぞれバージョン対応しなかったり、開けないことがあった。。
のでApache POIで代替することになった。
それなら動作も問題なかった。

動かないgem

  • pg
  • therubyraer
  • unicorn

などなどあるが、
railsが自動で代替用意してくれる

jrubyのwikiにもまとまってる
ただし、全て網羅しているわけではない

  • zipruby
  • SimpleCov

が実際には動かなかった

  • ziprubyはJavaのライブラリで代替
  • SimpleCovはgithubのissue確認してJRubyのバージョンアップで対応

ここ、ソースだけでなく解決状況を見れるOSSのいいとこ

rails/rake遅い問題

JVMの起動が遅かった

  • CRuby: 0.8sec
  • JRuby: 8.5sec

高速化ライブラリもJRubyだと使えない

  • Zeus
  • Spring

対策

Java VMのオプションを修正

Client VMを利用 8.5 -> 3.62秒になった

個々のPCで処理しないようにした

  • guard gem
  • sextant

JRubyは互換性あがってきてる

  • passenger
  • spork

等は対応済み

新たな高速化gemも出てきた
=> commands gem

まとめ

gemの互換性注意
Java利用環境でJRubyは使いどころがある

QA

文字コード対応できる?

parameter-encodingで指定すれば対応できる

JRubyを選定に加えた理由は?

一部の要件がRubyではできないがJavaでできることはわかっていたから

なぜJavaで開発しなかったのか?

Ruby好きだから!


Ruby開発者を増やすための教育について-8年間のRuby教育で得た知見

by 吉田裕美 (有限会社EY-Office)

Ruby教育の現状

一般データはもっていないのでEY-Officeの教育を紹介
2012年から研修申し込みが入るようになってきた

教育業者を使うことのメリット

  • 講義や教育のノウハウがある

社内で教えることのメリット

  • 企業のノウハウを伝えられる
  • 教える側もスキルが上がる

研修期間設定に関連するパラメータ

  • 経験値
  • 能力
  • etc

EY-Officeの教育コース

  • 1日コース
  • 3日コース
- 5日コース

3日が人気
1日で済む人は本でも済む
5日は期間として取りづらい

コース内容

  • 1日目

    • Rubyの基本
    • ループとか正規表現
  • 2日目

    • web application
    • scaffold使いつつrails
  • 3日目

    • 国際化対応
    • TDD体験
    • 脆弱性対応など
    • ブログアプリ等のソースコードリーディング

教育の場でやるべきこと

英語ドキュメントの読み方も教える

exampleから見るとか

デバッグ方法

エラーメッセージはどう読むのか

良いコードの書き方

  • なぜ必要か
  • 名前重要

webアプリの基本

html, cssとか

webの脆弱性

XSS, SQL injectionとか
実際のデモが良い

ポイント

関係者の顔を見えるように

開発者はmatzだよとか

メタ教育

–helpで大体ヘルプでるとか
manコマンドとか

定着

実際に作って、発表

コミュニケーション

確認しながら進める

場数をふむ

同僚に聞いてもらうとか
練習の場を作る

環境

windowsは入門程度なら問題ないが動かないgemなどある
多いのはwindows+VM+Linux
VMイメージ渡してる

印刷物はJekyllでつくってpdfにしてキンコーズで対応してる

QA

その場でいれると環境ずれて困るのでは?

bundle済みのrubyごと渡してる

IDEは使わないの?

隠蔽されてしまうので基本的には使ってない


Social Translating: Rails TutorialとRuby Hacking Guideの翻訳を支える仕組み

by 安川要平 (YasuLab)、八田昌三 (ビヨンド・パースペクティブ・ソリューションズ株式会社)

(事例1) Rail Tutorialの事例

約600page
Twitter-likeなページをサンプルで作るとかが書かれてる

7/1に日本語版も公開
約10人で1ヶ月で対応
4.0対応は2人で1ヶ月で対応

(事例2) Rubyソースコード完全解説

Ruby Hacking Guideの英語化

どうやって対応したのか?

githubを使って実施した
RHGはJekyllで実施

7.5 yearsかかった
GitHub移行後は1.3年
これを踏まえてRails Tutorialは工夫した

改善点

みんなgitに慣れてる訳ではない

word使いたい人とか
プロの翻訳者に相談して仕組みを変えた
social coding のような social translating
なるべくみんなが使いやすいwebツールで対処

ツール1: facebook group

pin機能を使ってREADMEのような投稿を常に表示

  • 概要
  • 役割分担
  • 参加方法

ツール2: google translator toolkit

  • 翻訳サポートツール
  • URL指定で翻訳できる
  • 翻訳メモリ、用語集を使える

翻訳メモリとは

原文と訳文のペアが蓄積したもの
次の翻訳開始時にメモリから一気に翻訳できる
原文の更新の追尾が楽になる

メモリの記述形式はテキストやXML
翻訳のボリュームが大きい時は非常に効果的
web記事などは効果薄い

続きはtechrachoの技術ブログにhachi8833で掲載予定

deploy部分の工夫

エンジニアが自動化
toolkit上のタグ単位でzipダウンロードしてheroku push

問題点

  • pull requestが使えない
  • diffがとりづらい

HTMLからepub化した!!

達人出版ででてる
Creative Commonsなので配布などOK!
学生さん、割り勘購入とかもできるよ

QA

複数人で翻訳すると言い回しの監修はどうしてる?

例も示してスタイルガイドを定義していた
適宜きづいた点も指摘していた

翻訳メモリ、順番変わって言い回し変わったらどうなる?

updateとか名詞なのか動詞なのかとか変わる
明確な対処方法はない
表が特に危ないので気をつけるべき

もしstackover flowなどを追従翻訳しようとすると大変、なにかアイデアある?

READMEを翻訳メモリのようにしてGitHub上でtoolkitにすることを考えたことはある
toolkitにpull requestを追加することも考えたことがある


ひろがるRubyの学びの場

by 五十嵐邦明 (株式会社spice life・一橋大学)

一橋でのRuby講義

  • ニフティの寄附講義
  • 島根Ruby合宿でも単位がもらえる

講義資料

などなど

講義内容

  • ruby, shellの基本的な解説
  • wikipediaのアクセス数解析
  • twitterの解析
  • ニフティのC4SAでデプロイしたり

やってみて気づいたところ

  • そもそもshellとirbの違いとか分からないもの
  • 文法よりもアルゴリズムが難しい
    • eachで中間データを持たしておくとか
  • hash理解されづらい
  • プログラマー向け入門書はあるが、初心者向け無い
  • エンジニアが教えることでで最新rubyなどに追従できる

rails girls

参加者の動機

  • 同僚のやっている内容知りたい
  • 旦那さんの仕事知りたい などなど

万葉では卒業生むけの勉強会も開催中

rails 寺子屋

学生向けrailsワークショップ
いまは高専卒業生多い

  • 講義
  • pull request道場
  • コード大喜利

pull request道場

開発の流れに慣れるためのpull request練習
ミサワ画像でコミュニケーションw

コード大喜利

課題を解く形式
うまく動けば○でる仕組みになってる
動いてても師範が脆弱性ついたりする

環境

VMはあまり使ってもらえなかったのでネイティブで

ゴール

社会人も含めた未来に設定することが大事
なので、たのしい雰囲気や仲間作りを大切にしてる

場所があるということは重要

興味があっても始めるきっかけがなかったり方法がわからないことがある
何が出来るのか、どうやってトラブル解決方法、勉強方法まなべる

五十嵐さんのrubyはじめたきっかけ

先輩がtdiary使ってた
そこから学ぶことが楽しかった

QA

VMなぜ使ってもらえなかった?

  • linuxに慣れてない方が多い
  • ネイティブでないのでもっさりしてる

ので敬遠されている模様

初めての言語がRubyであることのメリット・デメリットは?

  • ライブラリが豊富であること
  • webですぐ動かせること

が条件だと考えていてそれをruby満たしてる

あとはくせがなく読みやすいという声も生徒からあった

参加者の学習状況に差が出た場合の対処は?

基本的に多数の方にあわせる
演習の時間多いので、その時にサポートする
初めてだと翌週でも忘れるし、新規の方もいるので、聞かれたらもう一度説明をするようにしている