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

全体関連リンク

The Internet Axiom: Escaping the Tyranny of Time and Space』

by Tom Preston-Werner (GitHub Inc. CEO)

self introduction

  • ruby developer
  • php developer

githubで変えたいことがあれば言ってくれ

(~ video上映 ~)

video作ったのは私が変わり者だからというのもあるが
この歌が未来をとらえているから

このインターネットを使える時代素晴しく思う
電気がうまれた時代に似てる

インターネットは多くの情報をはこべ、電力以上に素晴しい

これはキャンプしたときの写真
電気が近くにあったわけではない
あったのはケータイだけ
これがインターネットの力

あなたのお気に入りのレストランのページはどうなってる？
メニューとかのってるだろう
それだけでいいのでしょうか

政府も考えるべき
申請書をアップロードするだけでいいと思ってる人がいる

ほぼ全ての人がスマートフォン持っている
10年後はいつでもどこでも使えることになってるだろう

“WEIGHTLESS DATA”

これからデータの重さがなくなる

例えば鍵

みなさん持ってますね

数KBのデータがあれば鍵はデータで表せるだろう
なぜ金属で持ち歩いているのか？
何万もケータイで持てるのになぜ？
インターネットの力使えてないといえる

実際にLockitronというサービスがある

お金

お札を持ち運んでいるがこれも意味が無い

squareがあります
ただ、リーダーがあるとデバイスが増えてる
そこでsquare cachというものも出してる
しかしemailなど管理は必要

iphoneだけでできないだろうか？
master cardはそれを解決しようとしてる
pay passというサービス

なんでこんな大変なのか
不正起きないよう、さまざまな制約があるから

bitcoinがある
これは問題もあるかもしれないが完全にオンラインで成り立っている

病院

なんども同じ問診票に同じ情報を書き続けなければならない
そして医者はまたそれをコンピュータにいれてる

drchronoはこれに対応している

みなさん仕事している中でいらつきを感じる場面あると思う
それをメモしてください
インターネットアクションをとってないことを

WEIGHTLESS DATA MOVES FAST

サンフランシスコからサクラメントにいって事務所に出さないと資料があった
1.5時間かけていった
データでいうと400Byteくらいの内容を書いた
そしてまた取りに戻った

つまりトータルで8時間もかかった
なんと50Byte/h
急いでもこれ
なんでこんなかかるのか

これと真逆の状態とはどんな状態でしょう

snapchat

革新的なのは数十秒でデータが消える
たとえば人の顔に落書きしておくったり

これのなにが特別なのか？
私たちは手紙をemailで代替している
パラダイムにのって変わったもの
しかし十分に適応していない部分がある

snapchatを使うと、送った馬鹿げた写真が広まることを気にしなくて良いのです

COMMUNIATION BECOMES EASY

UBER

サンフランシスコのtaxi状況はひどい
UBERを使えばどこにいるか見えるし自分の場所に来てくれる
待つ必要もないし、お金もその場で払わなくて良い
インターネットの力が発揮されている

簡単だから毎日使っている

SPOON ROCKET

これの対象はタクシーではなくご飯
6$で連れて行ってくれるて食べられる
車の送迎サービスもある
そして温かいご飯食べられる
大学生の助けになる

GitHub

世界中で働いている

先月のmain GitHubのレポジトリを見ると

  • 931 pull requests
  • 815 merged
  • 113 authors
  • 5273 commits
  • 443 issues
  • 248 closed

pull requestすると見える化できるし、レビューできる
ディスカッションができる

なぜこのような活動ができるのか？

ASYNCHRONUS

それは非同期にできるから
実際、いま私は日本にいて時差あるわけだが
リアルタイムではないがメッセージを送りあうことができる

これにより分散して仕事できる

非同期をサポートするのが

  • pull request
  • issue

という機能

Linusとも話した
彼以外の人は多くの人が一緒に働くということについて考えていなかった
大企業だけがそのような仕事していた
linuxはまさにそういうパターンの仕事だった
githubは分散された仕事を便利にしたもの

bear 13

githubではbear13という取り組みをやっている
集まって、新しいプロジェクトや新しいビジョンの話をする

サンフランシスコでやるが遠隔地のひとはどうするか？
‘remote by the fault’という考えでやっている
videoを見えるようにしている

URLS

URLも大事にしている
githubのURLは見れば何を指しているか分かるようにしている

みなさんのサイトでも考えてほしい
URLどれだけ読みやすいか

@mentions

これはtwitterにもある機能
issueなどで使う
これがあることで「いいね」というようなメッセージを引き出せる

CHAT

(chatopsのことぽい)
同期でも非同期でもできる
cookpad Takaiさんの取り組みは似ている
うちは28回なのでgithubの勝ちですw

1secでデプロイできるので何度も本番にデプロイできる

graph meで見るとかなりのメッセージが飛んでること確認できる

pagerやpuppetもchatで操作できる

QA

pull requestなどの機能はユーザにはどう使ってほしいと思っている?˙あとこれから予定してる機能ある？

ソフトウェアエンジニアが使えやすい機能を考えている

遠隔地でのコミュニケーションどうしてる

基本的には非同期でコミュニケーションだが、
face to faceするのは戦略的な話をするようなとき
そういう時にはgoogle hangout使う

翻訳に使った時gitを分からない人がいてpull request分からない人いた。なにか良い解決策ある？

non engineerにgit教えるのは大変。
githubはweb上だけでファイル編集とpull requestできるのでそれが使えるのでは

rubyやrailsに期待する機能ある？

いまそんなコーディングに時間使ってない 
rubyはプロトタイプにとても適していて好きだ

問診票は手の震えや記憶も見ている。それをインターネットで解決できるアイデアある？

オンラインでビデオ問診とかある

さいきん開発してる？

そんなしてない
奥さんと子供がいないときだけしてる

CLIでpull requestみるオススメのツールある？

hubとか
やっぱりwebが便利

行政業務システムのRuby化(開発事例紹介

by 木島浩暁 (株式会社日立ソリューションズ)

Ruby化の経緯

システム改修の短期化したかったから
そこでruby+railsを提案

スケジュール

  • ruby化
  • 変更分の取り込み

をウォーターフォールで計画

構成

  • web: java
  • バッチ: C

これがrubyとrailsになった

課題

1.開発体制の構築

多数のruby技術者が必要だった
=> 島根県企業と共同で行った

PROBIZMOと協力 VPNや会議システムを構築して対応した

2.Rails規約に沿わない機能の実装

  • URLの難読化
  • 外部ファイルの取り込み

rails拡張コンポーネントを挟んで対応した

2-1.URLの難読化

URLを予測されて直接入力されるのを避けたかった
開発者は通常通り開発し、難読化はコンポーネントが対応

2-2.外部ファイルの取り込み

申請書をweb画面から入力するのは難しいので
外注パンチで作成したファイルを取り込み機能が必要だった
ファイル解析用のDSLを定義した

3.バッチ処理の性能確保

C言語で書かれていたバッチと同等の速度確保を目標としていた

47万社のデータをCだと1h22minで処理してた
そのままrubyにすると70hかかった・・

  • Active RecordからSQL直接入力へ変更
  • GCタイミング修正
  • parralel gemでの並列実行

このような取り組みで1h10minにできた

Railsプロセスの起動時間も問題になっていた

  • プロセス常駐化し、
  • そこにプロセス間通信でキック、
  • 処理プロセスをforkする

という流れにすることで改善した

4.品質の維持

  • rspec
  • C0は100%
  • テストコードが2.5倍以上を目標

テストに9hourかかる
クックパッドのテスト並列実行のOSSに期待してます

最後に

rubyにしたことで次期以降での改修時間の短縮に期待している

QA

ruby関連の質問は開発担当のmakiさんが回答

rails起動の時間かかるというのはバッチ処理用のgem使ったのか、作ったのか？

delayed jobも検討していたが自作した
200行程度のもの
作ってからzeusでできるよとも言われた

機関系でのruby使用は増えそう？

全国のデータではなく行政単位の処理だったので並列処理できたが、
もしこれが並列実行できないようなものだったらと考えると検討が必要だろう

処理が分割ができれば使えそうということ？

その認識で間違っていないと思う

RDMSがネックになるのでは

それはある。
他のプロジェクトで限界を感じている

Active Record使うのやめたときエスケープ処理などはどうしたのか

ORマッパーだけ使わず、サニタイジング機能などはrailsのものを使った

『日本最大級のクラウドソーシング「クラウドワークス」の超速事業起ち上げにおいてRubyの果たした役割』

by 野村真一 (株式会社クラウドワークス)

自己紹介

モバイルCP -> クーポンサイト -> クラウドソーシング
Ruby使い始めたのはクラウドワークスが初

クラウドワークスとは

依頼できる仕事はオンラインで完結するものなら何でも

  • ウェブアプリとか
  • ランディングページとか
  • サーバ構築とか
  • デザインとか

ミッション

「21世紀の新しいワークスタイルを提案する」

背景は

  • 正社員比率の減少
  • 超高齢化社会
  • 女性の終業ギャップ

大切にしていること

ユーザエクスペリエンス

機能で語る時代ではなくなってきた
車のCMでも「モノより思い出」といっちゃうくらい

仕事の受発注において、
お金だけでなくやりがいなどを期待しているはず
そういった社会の満足度等を提供していきたい

「働くを通して人々に笑顔を」

クックパッドさん参考にしてる
仕事を通じた満足やつながりを生みたい

「ありがとう」ボタン
facebookのlikeのように感謝を可視化した
リリース後スゴい押されてる
採用しなかった受注者の方に押されること多い

「1クリックで世界の仕事とスキルにアクセスを」

これまでのクラウドソーシングサービスは
予算や仕様が明確でないといけなかったりして複雑だった
ちょっと電話かけて相談するくらいの感じを想定

「ショートメッセージ」機能もあり、気軽な相談できるようにしてる
「お仕事相談所」というところで依頼方法や相場も教えてくれる

開発事例

rails多い
ポケットコンシェルジュも発注してる
ポケットコンシェルジュは時給制を採用してる

ロゴコンペ

新しい事業のロゴを依頼してたくさんのデザインが応募してくれる
経産省Jump start Nipponでも使われた

選択と集中

受注と発注は鶏と卵
発注者にフォーカスしてる
目標設定も発注者の数
受注者はあとからついてくるとしてる

スピード!スピード!スピード!

楽天を参考にしてる
F1より自転車のほうがイメージあう
守るものなく、エンジンは自身なので、スタートアップぽい

たちあげの話

CTOと非常勤の2人でつくった
rais使ってる
サービス開発に集中できる

主に使ってるgem

  • capistrano

  • em-websocket railsモデルそのままチャット機能つくれるので選択

  • OAtuth-plugin

メタプログラミングも活用

今は4名くらいで開発
PHPに飽きた方がjoinしてる
rubyスキルはrubyぽく、railsぽく書けてるかで判断できる

審査

ソースコード出してもらってやってもらっている

スキルの登録具合

受注者のスキル層的にはPHPが多い

内部で使っている技術

大半がRubyがらみ
rails, fluentd, etc

QA

今後の機能等あれば

3Dプリンタの仕事追加したら発注されてる
マッチングにふっていきたい
スケジュール管理、ファイル共有とかを使いたいという要望がきてる
現状だとdropboxつかってくださいと言ってるが強化したいところ

『クラウド時代のRubyアプリケーション設計』

by 相澤歩 (株式会社セールスフォース･ドットコム)

自己紹介

rubyコミッタになったのが２年前のrwcだったので感慨深い

herokuは買収され２年ほど経ち、
herokuでありセールスフォース・ドットコムの社員

エバンジェリストとしてエンジニアむけのマーケティング活動してる
大規模なキャンペーンのさい等にテクニカルアカウントマネージャーとしてサポートもしてる

製品開発以外やってる

エンタープライズレベルの契約をすると日本語でサポート受けられる

Heroku

2007年に3人で創設
最初はrubyだけホスティングしていた

2011に買収されてからはjavaやpythonなどなどサポート開始

しかしユーザの使用言語、システムの言語はRubyが多い

課金

使った分だけ

ユーザ分布

ランキングは上から

  • アメリカ
  • UK
  • カナダ
  • 日本

UKインスタンスできてからUKも増えた
カナダと日本は僅差

‘the twelve-factor app’

heroku創業者が書いた論文のようなもの
アプリ構築に必要な12の要素にまとめたもの

  • セットアップは宣言的に行う
  • 依存を明確に定義する
  • クラウド環境を仕様
  • 環境と本番の差異をなくす
  • アーキテクチャを変更せずに用意にスケールするように

というようなこと書かれてる

12のプラクティスのタイトル紹介

今日は3つだけとりあげる

1.Codebase

  • ひとつのアプリは１つのコードもつ
  • ひとつのアプリは複数の環境にデプロイされる
  • 複数のコードベースは複数のアプリとして取り扱う

環境ごとに持つべきではない

gem化

共通コンポーネントはgemにして複数アプリで使う
jeweler使うとgem化は楽

rails_12_factor

herokuではrails12_factorを入れるようにしてもらってる
aasetsなどのサポートがはいる

gitのsubmodule

これでgitレポジトリの入れ子できる

2.Config

これはデプロイに特化したものなのでコードベースと分離すべき
環境変数にわける

3.Build, release, run

依存解決、リリース(実行準備)、実行

バージョン管理

コードベースのバージョンとリリースのバージョンは違う
rollbackはリリースのバージョン単位で行う
heroku内ではbuildpackで依存解決し、最終的にDyno managerでリリースされる

日本語訳

ここ: http://twelve-factor-ja.herokuapp.com/

QA

アーロンさん「ダジャレ賞さしあげます」

これはダジャレクラブというハッシュタグがあり、その中でいいだじゃれ(たくさん?)つぶやいたのでもらえた

司会「最高のダジャレおねがいします」

「イベントで良い弁当」

なぜjewelerにした？

bundlerと悩んだが初心者にはjewelerのが良いと思った

slug compilerの中ではbundlerしてる
rubyのバージョン管理もherokuではbundlerで管理してる

『Rubyからアジャイル開発･ビッグデータ対応のデータベース(4D DAM)を利用するためのAPIの研究開発』

by 山本哲男 (株式会社八雲ソフトウェア)、高木丈智 (株式会社テクノプロジェクト)

山本さんの舞台裏

  • 5000人にrwc招待メールおくった
  • 300人から返信
  • 34名カンファレンス参加
  • 20名ツアー参加

八雲ソフトウェアについて

松江駅前にて開業

八雲は出雲のかかりことば
8は無限も意味している

Uターン人材を募集して、これまで4名採用した

首都圏の状況

  • 人材不足
  • オフショア開発のリスク
    • 文化も違うし
    • 賃金あがってきた

なので東京で営業、地方で開発がよいと考える
首都圏の技術者60%は仕事があれば地元に帰りたいと思ってるという背景もある

4D DAM

  • アジャイル
  • ビッグデータ(高速処理)
  • シンプルなテーブル構造
  • メンテナンスが簡単
    • DB内でプログラム実行可能

データベースだが上記に対応

実際、東証ではSQLは1行しかかかれていない

東証での実例

2010年に東証に採用された
不正検知などに貢献

契機は富士通のアローヘッドを使い始めたこと
7ヶ月しかなかったがアジェイルで4ヶ月で仮稼働まで辿り着いた
他社は数年予定だった

オリンピック殿でも実績ある

機能解説

  • ダイナミックアレイ構造
  • ディクショナリードリブン

変更が用意であるため、アジャイルに適用できる

テクノプロジェクト

創立29年
2007年からrubyに取り組んでいる

4D DAM APIの紹介

4D DAM向けのAPIの提供の話
Ruby版ドライバを作成したのでこれからはRubyから使える
ドライバは年内完成予定
来年２月にAPIは提供予定

4D DAMの応用の可能性について

  • ECサイト
  • 医療情報DB
  • 通信監視
  • 部品管理
  • フィールドクラウド

フィールドクラウド

クラウドと統合したフィールド監視

example: 笹子トンネルの崩落
情報は紙では管理はされていた

交通規制といった水害対策もセンサーと連動することでできるだろう

QA

機関システムではRDBMSだが、4D DAMに移行したらACID性は担保される？されないなら対策は？

joinが問題だと思うが常にjoinしたような状態で動くので問題が起きない

API実装上、データの整合性に気をつけていると思うが、どのへん工夫している？

4D DAMの開発者にCで記述してもらっている
主にrubyらしい命名の要望だけ開発者に伝えている

使用する上での懸念点を本音で言ってほしい

八雲ソフトウェアが大きい会社ではないので体力的に懸念はされることはあるだろう

『Rubyistによるアジャイル開発事例紹介と進め方』

by 川端光義 (株式会社アジャイルウェア)

アジャイルウェア

Rails4のシルバー試験の問題を作成中、来年４月から受けれるようになる

総メンバ数: 15名

Rubyの受託で12件ほど

XPS & XCSの実現を理念としている
=> 究極のプログラマー満足と顧客満足

Redmineのプラグイン開発事例

2ヶ月で12個のプラグインを作成した
4つはOSSとしてgithubに還元した
ちょうどredmineのissueに上がっておりパッチを送った

発注先として選ばれたのは短期間の12個開発にOKと言えたから

次の開発フェーズ

redmineのガントチャートが使いにくい
=> MS Projectのように使えるガントチャートを作成することに

そして Lychee Gantt Chart が生まれた
Web上でマウス操作で各種期間などを操作できる

Orange project

THIN REPORTSにお世話になってます

開発効率

社内ではPivotal Trackerでチケット管理しているが、
それを見ると日に(?)2,3時間だけ使われている状態で進んでいる

Ruby, Rubyistの生産性が高いと言える
映画でリラックスするように彼らはプログラミングでリラックスしている

変わったこと

要件定義 == プログラミング
要件も細かく伝えなくていい
テストはあるがユニットレベルで仕様が柔らかいまま進む
受け入れテストの前に顧客のacceptが出ながら進む
スケジュールが前倒しになって管理がいらなくなってくる

これはRubyistのおかげ
エンジニア合わせて組織も変えてきた

学歴ではなく、githubをみる
プログラミング以外の物を引き取る
マネジメントも厳しくしない

最後に

あるカンファレンスでのKent Beckのやりとり
質問者「周囲を変えないと、アジャイルやXPができない」
Kent Beck 「変えられるのは自分自身だけ、それにつられて周りは変わる」

QA

テスト駆動開発できないというのは？

受け入れのテストから始められないということ
ユニットテストは最初から書いてる
仕様が固まった後半からCIも自動化してる

顧客との仕様固めは開発者が直接行ってる？

間に担当が立つこともあります
状況によります

なぜフルーツの中でもアケビをプロダクト名に選んだのか?ruby色関係ある？

英語のpawpawが可愛いと思ったから
ruby色だからではない

クロージングセレモニー

by 井上 浩 (Rubyアソシエーション　副理事長, しまねOSS協議会　会長)

来場者数

  • day1: 491人
  • day2: 410人
  • 合計: 901人

開催趣意書

趣意書どおり未来イメージできたと思ってる

開催テーマ

様々なテーマ交換できましたね

各種紹介

  • 構成団体
  • 実行委員会
  • 事務局
  • ワーキンググループ
  • スポンサー

最大の危機

直前でmatz尿管結石に。。

各種おもてなしありましたね

  • 聖地 やぁ
  • 夜も更けたり
  • 今年も鉄板の石原さん

発表者の紹介、振り返り

keynoteでは

  • あまりコーディングしない
  • ナイストライを重ねてchange the world

が印象的でしたね

  • 三好さんからはなぜJavaを選ばなかったのかという話もありました
  • 受賞者の書いた紙を温めていたのは舞姫隊のあやめ様でした
  • matzのTokyoはナイストライでした
  • 笹田さんご結婚おめでとうございます
  • Tomからはインターネットとプロジェクタの新しい使い方を学びました
  • 相澤さんダジャレ賞おめでとうございます
  • アジャイルウェアさんのウォータフォール万歳

アーロンさん壇上へ

今日は素晴しい通訳(matz)がいますので英語で
いつもひとりで作業して疲れてる
アメリカにはおつかれさまという言葉ない
なので週末にハグをするというのを考えた
(ここでみんなでhappy friday)

最後に

尿管結石にはご注意を
石原さん「来年も待ってるんだからね！」