- 公式サイト: http://www.rubyworld-conf.org/
- 公式UST: http://www.ustream.tv/channel/rubyw-conf-13
- togetter day1: http://togetter.com/li/592855
- togetter day2: http://togetter.com/li/593359
- my memo day1: https://gist.github.com/Matsue/7585061
- my memo day2: https://gist.github.com/Matsue/7600639
- Social Translatingの資料: https://speakerdeck.com/yasulab/social-translating-the-way-of-translating-rails-tutorial-and-ruby-hacking-guide
by matz
- english memo https://www.evernote.com/shard/s54/sh/9cd05cf6-6119-4baa-a1ae-31bd2f23ae34/16638f82bd08ac21c5ad4206d81630de
1990年に社会人
その会社ではプロジェクトは3年単位で動いていた
- 日本語で設計書書いて
- それをそのまま実装
- テスト
- 納品
スゴく詳細なドキュメント
ドキュメントは厚さ(センチ)ではかってたくらい
ウォーターフォールだった
なにか違うと思ってたが説明できなかった
経験もなかった
20年経った今は説明できるようになった
「なにを作っているか把握してる」
と、思ってること
softwareは物理法則に制限されない
最近は記憶容量大きくなりプログラムサイズは制限されない
いまや、もっとも複雑な被造物といえる
人間の能力を超え、ドキュメントでカバーできない
ソフトウェアは柔らかくない
ソフトウェアはハード(固く、難しい)
更新は大変
「何を作りたいか把握してる」
なにをしたらビジネスが成功するかわかっている人は少ない
ソフトウェアを使った時の状態を想像するのは今も昔も難しい
納品すると大体、「私が思ったのと違う」
上司や顧客がバカ扱いになりがちだが
何を作ったらビジネス価値を最大化できるか分かる人は少ない
実際はみんなバカだった
「状況は変化しない」という前提
無知であることを認めるべきだった
我々ができることは少ない
過去から学ぶ
状況が変化しないなら、良い戦略
ITでは変化が激しいので成立しない
アリスの赤の女王いわく、
留まるには速く動き、移動するにはもっと速く動かないといけない
ダチョウは砂嵐きたら砂に頭を埋める
なにもかも投げ出して、ただ待つ
冬眠も似てる
状況が回復するなら良い戦略
ここまでの２つは現実に反しており、おとぎの国に向かうような戦略
20年前は上記の戦略をとっちゃってた
コンピュータは高価で持っているだけで差別化できていた
ネットワークも高価
なので失敗しないことを最優先してた
たとえ満足度を犠牲にしても
それが唯一のソフトウェア開発の方法であると信じたかった
いまは持つだけでは差別化できない
いまもすごいソフトウェアの作り方は分からない
無知の知
コンピュータ、クラウド、ネットワーク安くなった
ソフト開発も安くなった
ツールとか言語とかのおかげ
以前は海外にメールすることもできない世界だった
rubyはたくさんの海外の方からサポート
母国語や住んでる場所、性別もしらないこともある
いまや、巨人の方に乗ることができる
何度でも挑戦できることが必要
コスト最小化が大事
そこをrubyはサポートしてきた
それができるようになって初めて動く標的を狙うことができる
Aiming the Moving Target
動くターゲットとは本当に価値のあるソフトウェア
価値は人間の欲求に基づく
リリースがいまや個人でできる
プリウスは一人でつくれないだろうが、
ソフトウェアでは一人でつくったもので世界を変えられる
当たらなかったらピボットできる
「安く速く何度も」が成功の秘訣
アジャイルもそれを反映している
変化に対応する
成功するかは分からないが成功確率は上がる
自戒を込めて、
熱心にコードを書かない
複雑になり失敗したときのダメージも大きい
コードを書かないために熱心に働く
最初のボールだけ転がして、みんなに頑張ってもらう
rubyもひとりで作っていない
ここも巨人の肩にのる
競争力維持に必要な物以外はOSSにしてしまうのが正しい戦略
コアパートも小さくとどめる
OSSの定義にはないがコミュニティというのは不可欠
OSSでなくてもコミュニティは有効だろう
プロジェクトを最小化し、プロジェクトの組織というものが解体されるだろう
技術ベースでプロジェクトをわたり歩くようになるだろう
OSSコミュニティはサメ
進み続けなければ、死ぬ
大部分は技術的に面白いことで参加してるので、止まると人が離れる
rubyもコミュニティ開いたり、新しい技術応援したり、カンファレンス開いたりしている
OSSでなくても進み続けることは必要だろう
アリスの世界と同様、なるべく速く、何度もためして、何度も撤退すべき
そして大局的構造を変えられるだろう
「失敗したら終わりだ」から「失敗してもいい」へ
まずは失敗をナイストライに言い換えるところから
コードかかず、
いいソフトウェアをつくり、
世界を変えよう
webでは流行ってきてるがもっと広い世界で使えるようになるといいと思う
たとえば大学の科学技術計算など助成してる
あとはmrubyで組み込み目指してる
競争力に関わる物であるか
最小になるか
たとえばビジネスロジックだけ出さない
クックパッドをすべてOSSにしても問題ないと思ってる
レシピ・ユーザデータが大事
by Aaron Patterson (AT & T)
バグを見つけたらわかるまで調べてる
なのでYak Shavingになる
よくコンピュータ壊す
シンボルはGCされない
Dos攻撃になるのが心配なので文字列にしたが遅くなったとの報告
rubyソースを追った
とあるソースでruby安全性と速度を担保するには？
=> 定数を使う
2.1のフローズン文字列を使うと、安全で速い
しかし、define_methodはmodue_evalより遅いとのコメントがつく
そこでベンチマークで確認した
たしかに遅かったが
しかしdefine_methodは異なるインタフェースも用意されており、そちらで呼んだら速度改善した
メモリ使用量についてもコメントあったのでベンチマークをして調査した
module_evalのほうが消費する
速くて、メモリ使用量も少ない方法はないか？
を考え改善に至る
数値列(?)からselectすると文字列で返るというバグから始まり、
rubyのVMを学び、
DoS攻撃の対策になり、
railsの高速化に寄与でき、
railsのメモリ効率がよくなった
ただしバグはまだ直ってないがw
大事なことは
「知りたがりましょう」
1monthくらい
まだ直ってないがw
日本語は7年勉強してて
プレゼンは３週間くらい練習した
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も用意してる
たとえばバグでロールバック中、サーバスケール中とか
devは変えたいタイミングでやってる
変更時にdumpしてgithubにpushしてる
本番はインフラと相談しながら
むらたさん、ふくもりさんの２名
依存してない部分は抽象化して出してる
- chanko
- 分散テスト環境(予定)
by 三好秀徳 (株式会社日立ソリューションズ)
- OSSフォーラム推進
- yokohama.rb
- ruby world conf 2012のまとめしてる
- るびま編集者になった
- Java API使える
- 処理速度はCRubyと遜色無し JVMの起動がボトルネックになることはある
Jruby使う理由: Javaの資産を活用したい
内製Accesssアプリケーションの移行の話 メンテナンス性と速度が低下していたので移行になった
- パスワードzipファイル出力
- excel出力
- 既存のJavaサーバで動かす
=> rubygemsから使えそうな物をピックアップ => warblerでwarファイル化
xlsを使えるgem
- spreadsheet
- axlsx
それぞれバージョン対応しなかったり、開けないことがあった。。
のでApache POIで代替することになった。
それなら動作も問題なかった。
- pg
- therubyraer
- unicorn
などなどあるが、
railsが自動で代替用意してくれる
jrubyのwikiにもまとまってる
ただし、全て網羅しているわけではない
- zipruby
- SimpleCov
が実際には動かなかった
- ziprubyはJavaのライブラリで代替
- SimpleCovはgithubのissue確認してJRubyのバージョンアップで対応
ここ、ソースだけでなく解決状況を見れるOSSのいいとこ
JVMの起動が遅かった
- CRuby: 0.8sec
- JRuby: 8.5sec
高速化ライブラリもJRubyだと使えない
- Zeus
- Spring
Client VMを利用 8.5 -> 3.62秒になった
- guard gem
- sextant
- passenger
- spork
等は対応済み
新たな高速化gemも出てきた
=> commands gem
gemの互換性注意
Java利用環境でJRubyは使いどころがある
parameter-encodingで指定すれば対応できる
一部の要件がRubyではできないがJavaでできることはわかっていたから
Ruby好きだから!
by 吉田裕美 (有限会社EY-Office)
一般データはもっていないのでEY-Officeの教育を紹介
2012年から研修申し込みが入るようになってきた
- 講義や教育のノウハウがある
- 企業のノウハウを伝えられる
- 教える側もスキルが上がる
- 経験値
- 能力
- etc
- 1日コース
- 3日コース - 5日コース
3日が人気
1日で済む人は本でも済む
5日は期間として取りづらい
-
1日目
- Rubyの基本
- ループとか正規表現
-
2日目
- web application
- scaffold使いつつrails
-
3日目
- 国際化対応
- TDD体験
- 脆弱性対応など
- ブログアプリ等のソースコードリーディング
exampleから見るとか
エラーメッセージはどう読むのか
- なぜ必要か
- 名前重要
html, cssとか
XSS, SQL injectionとか
実際のデモが良い
開発者はmatzだよとか
--helpで大体ヘルプでるとか
manコマンドとか
実際に作って、発表
確認しながら進める
同僚に聞いてもらうとか
練習の場を作る
windowsは入門程度なら問題ないが動かないgemなどある
多いのはwindows+VM+Linux
VMイメージ渡してる
印刷物はJekyllでつくってpdfにしてキンコーズで対応してる
bundle済みのrubyごと渡してる
隠蔽されてしまうので基本的には使ってない
by 安川要平 (YasuLab)、八田昌三 (ビヨンド・パースペクティブ・ソリューションズ株式会社)
約600page
Twitter-likeなページをサンプルで作るとかが書かれてる
7/1に日本語版も公開
約10人で1ヶ月で対応
4.0対応は2人で1ヶ月で対応
Ruby Hacking Guideの英語化
githubを使って実施した
RHGはJekyllで実施
7.5 yearsかかった
GitHub移行後は1.3年
これを踏まえてRails Tutorialは工夫した
word使いたい人とか
プロの翻訳者に相談して仕組みを変えた
social coding のような social translating
なるべくみんなが使いやすいwebツールで対処
pin機能を使ってREADMEのような投稿を常に表示
- 概要
- 役割分担
- 参加方法
- 翻訳サポートツール
- URL指定で翻訳できる
- 翻訳メモリ、用語集を使える
原文と訳文のペアが蓄積したもの
次の翻訳開始時にメモリから一気に翻訳できる
原文の更新の追尾が楽になる
メモリの記述形式はテキストやXML
翻訳のボリュームが大きい時は非常に効果的
web記事などは効果薄い
続きはtechrachoの技術ブログにhachi8833で掲載予定
エンジニアが自動化
toolkit上のタグ単位でzipダウンロードしてheroku push
- pull requestが使えない
- diffがとりづらい
達人出版ででてる
Creative Commonsなので配布などOK!
学生さん、割り勘購入とかもできるよ
例も示してスタイルガイドを定義していた
適宜きづいた点も指摘していた
updateとか名詞なのか動詞なのかとか変わる
明確な対処方法はない
表が特に危ないので気をつけるべき
READMEを翻訳メモリのようにしてGitHub上でtoolkitにすることを考えたことはある
toolkitにpull requestを追加することも考えたことがある
by 五十嵐邦明 (株式会社spice life・一橋大学)
- https://github.com/igaiga/hitotsubashi-ruby-2013
- http://c4sa.nifty.com/
- https://github.com/ruby-no-kai/official/wiki
- ニフティの寄附講義
- 島根Ruby合宿でも単位がもらえる
などなど
- ruby, shellの基本的な解説
- wikipediaのアクセス数解析
- twitterの解析
- ニフティのC4SAでデプロイしたり
- ブラウザ上で編集もできるクラウド
- http://c4sa.nifty.com/
- そもそもshellとirbの違いとか分からないもの
- 文法よりもアルゴリズムが難しい
- eachで中間データを持たしておくとか
- hash理解されづらい
- プログラマー向け入門書はあるが、初心者向け無い
- エンジニアが教えることでで最新rubyなどに追従できる
参加者の動機
- 同僚のやっている内容知りたい
- 旦那さんの仕事知りたい などなど
万葉では卒業生むけの勉強会も開催中
学生向けrailsワークショップ
いまは高専卒業生多い
- 講義
- pull request道場
- コード大喜利
開発の流れに慣れるためのpull request練習
ミサワ画像でコミュニケーションw
課題を解く形式
うまく動けば○でる仕組みになってる
動いてても師範が脆弱性ついたりする
VMはあまり使ってもらえなかったのでネイティブで
社会人も含めた未来に設定することが大事
なので、たのしい雰囲気や仲間作りを大切にしてる
興味があっても始めるきっかけがなかったり方法がわからないことがある
何が出来るのか、どうやってトラブル解決方法、勉強方法まなべる
先輩がtdiary使ってた
そこから学ぶことが楽しかった
- linuxに慣れてない方が多い
- ネイティブでないのでもっさりしてる
ので敬遠されている模様
- ライブラリが豊富であること
- webですぐ動かせること
が条件だと考えていてそれをruby満たしてる
あとはくせがなく読みやすいという声も生徒からあった
基本的に多数の方にあわせる
演習の時間多いので、その時にサポートする
初めてだと翌週でも忘れるし、新規の方もいるので、聞かれたらもう一度説明をするようにしている