RubyKaigi2014に参加してきた(1日目)
▲3日目 おはよう Railsの様子
9月18-20日にタワーホール船堀にて開催されたRubyKaigi2014に参加してきました。 簡単ですが気になった発表について、感想を交えてレポートを書いておきます。
1日目
CRuby Commiters(Tomoyuki Chikanaga)
- CRubyのコミッタは80アカウント、実質50人ぐらいのアクティブなコミッタがいる
- RubyKaigiでスピーカーになっているのは15人
感想: ネット上やRubyKaigi会場で時々お見かけする方々が、どんな分野を担当してるか分かってよかった。
Building the Ruby interpreter -- What is easy and what is difficult?(Koichi Sasada)
- 10周年
- Rubyの開発は何が簡単で何が難しいかという話
- 何をやってきたか
- 本題
感想: 「なんとなく思いついたアイデアを実装するのは簡単。でも、まともに使えるようにするためには苦労が必要」という部分は、レイヤーは違えどどんなエンジニアにも共通なんだなと思った。私の仕事だとRubyで大量のデータを集計するバッチ処理を書くことが多くて、GCの遅さには悩まされてる。これが新バージョンのRubyで少しでも軽減されると助かる。
Controller Testing: You’re Doing It Wrong( Jonathan Mukai-Heidt)
- controllers
- bing action
- small details
- controllerはno logicであるべき
- テストが必要なロジックはコントローラに書くな
- before_filterを使う
- Little to no logic in controllers.
- shared examples cover the small details.
- 認証テストをまとめる
- 使いすぎるとどこでコケてるかわからなくなる
- テストはチェックリストのように
- 命令文ではなく平叙文的にテストをかけ
感想:「うーん。まぁそうだよね」と思う内容だった。shared examplesを使ってテストをまとめるとしても、やり過ぎるとテストが追いづらくなるし、可読性を求めて一箇所に書いてしまうとDRYじゃなくなりメンテしづらいしバランスが大切ということかな。「テストはバランスが大切」という話は3年ほど前からよく聞いてるし自分でも感じてるんだけど、これといって決定打が無いなとも思ってる。
Introduce Oracle enhanced adapter for ActiveRecord, another choice for your Rails database.(Yasuo Honda)
- Oracle enhanced adapter maintainer
- Oracle enhanced adapter
- 3rd party Activerecord adapter
- 標準にない機能
- Rubyの型とのマッチング
- 既存のテーブル設計をRailsに合わせるユースケースが多い
- 7つほど専用の命令が用意されている
- Oracleを使うことで何が良いか?
- オプティマイザが賢い
- プリペアードステートメントが賢い
- SQLインジェクションの対応に強い
- Oracle11g
- 1つのプリペアードステートメントで複数の実行計画を持つことができる
- User.where(:database => ‘oracle’).last.id
- ActiveRecord
- そのまま
- Oracle modified SQL
- 素のSQLではなく最適化されてる
- where文が書き換えられてる
- 実行計画を動的に変えてくれる
- where文で指定された列に該当する値が多ければフルスキャン
- そうでなければindexを使ってくれる
- 実行計画がメモリに蓄えられてシェアされる
- 素のSQLではなく最適化されてる
- ActiveRecord
- User.where(:database => ‘oracle’).last.id
- 問題点
- いくつかテストがコケる
- Empty string as NULL
- 長さ0の文字がNULLとして扱われる
- Identifier length <= 30 byte
- オブジェクト名は最大30文字
- “id” needs to set explicitly
- Oracleは明示的にidに入る値を書かなくてはならない
- No limit in sub queries
- limit句がサブクエリ内で書けない
- Empty string as NULL
- いくつかテストがコケる
- Rails4.2
- Adequate Record
- パフォーマンス改善
- Adequate Record
- Oracleとしての新しい機能
- 12cが最新機能
- 徐々に標準に近づけようとしている
- JSON Datatypeのサポート
- Better Top-N query support
- これのおかげでページネーションがまともに動くようになった。
- order_hacksというダーティーな処理を削除
- これのおかげでページネーションがまともに動くようになった。
- 12cが最新機能
- 環境作るのが大変だよね
- 1つのプリペアードステートメントで複数の実行計画を持つことができる
感想:発表前の会場挙手で意外とRailsでMySQLを使っている人が多かった。Oracleは普段使ってないけど、MySQLやPostgreSQLと比較して独特の仕様が多いように思う。その反面「Oracle modified SQL」で適切なSQLに書き換えれば高速に動作するところが素晴らしい。単に「ActiveRecordをOracleに対応させましたよ」というだけでなくOracleの旨味を引き出していた。メインで利用するDBとしての選択ではなく、外部システムとのやりとりで接続することを想定してActiveRecordに追加命令があるのもありがたい。複雑になりがちなRailsでの複数DB接続に希望が持てた。
Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails(Toru Kawamura)
- Sendagaya.rb
- Web APIの話
- 蜘蛛の巣のようなAPI
- public
- どう使われるか分からない
- 蜘蛛の糸のようなAPI
- private
- どう使われるか分かってる
- APIをRestfulにするかどうかは要件次第
- 要件にあったAPIを
- 今回は蜘蛛の巣のようなAPIをどう作るかという話
- Breaking Changes are Harmful
- 壊す変更は有害
- クライアントがiOSアプリだと変更に時間が掛かる
- 人間が読めるドキュメントから作られるサービスがたくさんある
- 機械が読める説明書から作られるクライアントもある
- JSONで仕様を提供してコードを自動生成する
- APIの変更がクライアントに反映されるべき
- APIの説明を分割して各レスポンスに埋め込むのが良い
- 疎結合が良い
- APIコールのメタファーが危険
- クライアントが次に何をするかはAPIから返ってくるリンクをたどる。=HYPERMEDIA
- 普通のWebと一緒
- ワークフローがあるから破綻しない
- 人間は画面に表示される内容を目で見て判断して処理を行っている
- HTMLクローラー
- hypermicrodata gem
- HTMLをサーバーサイドでJSONに変換
- 状態遷移図を作って設定
- ブラウザと同じイメージで作ること
- HTMLじゃなくてJSONを書くときの注意
- まとめ
- Web APIはHTML Webアプリと同じように設計しよう
- RESTの制約・原則を意識するともっとうまくできる
感想:API設計で問題となる仕様変更についてのスマートな解決方法を学ぶことができた。クライアントが「次に読むべきURI」をアドレスではなくHTML内の文字で示すという考え方は面白い。「え?それってスクレイピングじゃ...?」という疑問に対しても「hypermicrodata.gem」という解決方法を準備してくれているのも素晴らしい。期限を設けてv1,v2...とバージョン番号で区切るしか無いと思っていたAPI仕様変更に対する問題に光明が差した気がした。
RubyistはWindowsに帰っておいで -Vagrantを使ったWindows開発環境-
Windowsマシンを組み立てたった!
自作PCなんて何年ぶりだ!? pic.twitter.com/AB3FStmPFR
— Yamamoto Kazuhisa (@kazuhisa1976) 2014, 6月 21
ASP.NETに興味が出てきたので久々にWindowsPCをアップグレードした。CPUはCore2QuadからCorei5(4590)に、OSはVistaからWindows8.1に変わった。特に大きなハマリも無くすんなりアップグレード完了。最近のマシンの起動は本当に速い。昔はBIOSでいろいろチェックしたのち立ち上がってたのに時代は変わったなぁ。
なぜRailsプログラマはMac OSを使うのか?
多くのRailsプログラマがなぜMacを使うか?それは「Unixのような環境」を使いたいためだと思う。HerokuやAWS Elastic BeanstalkのようなPaaSサービスが人気なのは確かだがデプロイされる先はUnix系OSであることに変わりはない。開発環境をデプロイ環境と揃えておくことは開発者としてごく自然の考えだし、デプロイ時のトラブルも少ない。もちろん私も4年以上MacでRails開発を行っている。
時代は変わった
本番環境と親和性の高いMacOSだが、最近は開発環境の複雑さによって環境を仮想化し、場合によって切り分ける動きが出てきた。
-
- PostgreSQL
- sidekiq.gem
- redis
プロジェクトB
- Mongoid.gem
- MongoDB
- Mongoid.gem
プロジェクトC
こんな状況で一台のMacに色々なアプリケーションをインストールして、プロジェクトに応じて起動したり停止したりするのはうんざりだ。今であれば普通にVagrantによる仮想環境で解決しようと思うはずだ。
ならWindowsでいいんじゃない?
はい。Windowsでいけちゃいます。
ポイントは次の通り。
Vagrantの共有ディレクトリは使わない
WindowsのファイルシステムをLinuxで使うのと、LinuxのファイルシステムをWindowsで使うのでは後者の方がオススメ。理由としては速度が速い事と、Rubyの組み込みライブラリであるFileクラスの動作不良*1が発生したため。
Sshfs Managerを使ってディレクトリを共有する
シェルはGit BashとConEmuを使う
https://code.google.com/p/conemu-maximus5/
多機能なコンソール。いい感じのフォントや色を設定しよう。
RubyMineはVagrant用の設定を使う
Ruby用IDEであるRubyMineを使うとGemの中のソースまでジャンプしてくれる。Railsのソースを読むのにとても便利だ。RubyMineはVagrantにも対応しておりVagrantfileを読み込ませることで、コードジャンプやIDEによるデバッグ実行が可能となる。
http://www.jetbrains.com/ruby/webhelp/configuring-remote-interpreters-via-virtual-boxes.html
Windows環境はできることが多い
私の場合、Windowsだと幸せが多い
DMMでダウンロードした動画(察して)
なんと、WindowsMediaPlayerとゆー、標準プレイヤーで観ることができる!先行き不安なSilverLightプレイヤーを使わなくていいのはありがたい。
RAW現像ソフトSilkypix Developer Studioの動作が爆速
「爆速」というか単純にMac版が遅すぎるって話なんだけどね...
ゲームができる
バナー広告でよく見かけるWorld of Tanksとかで遊べてしまう。
Visual Studioで.NETができる
あたりまえ。
IEで動作確認できる
まとめ
MacでVagrantを使って開発環境を切り替えつつRailsやってる人は、Windowsに戻ってきてもいいかもしれない。Windows8.1は表示もシンプルで動作も恐ろしく速く、OS自体のデキはMacOSと比較してとても良いと思う。この夏はぜひWindowsで視野を広げてみよう。
*1:File.exists("config/locales.")のような存在しないファイル/ディレクトリが存在することとして判断されてしまう
Railsのバッチ処理のコツ
はじめに
Railsでギョーミーな仕事を行う上で欠かせないのがバッチ処理です。 日々上位システムから送られてくる膨大なデータを迅速に取り込み、集計処理を行いDBに格納する。上位システムは何層も構成されており、我々が集計処理に使える時間はエンドユーザーが出社してくるまでの数時間... みたいなシチュエーション無いですか?
今回はバッチ処理を行うコツについて書いてみようと思います。
想定される処理
- CSVファイルの取り込み
- 集計処理
- 集計結果をDBに格納
普通にrake taskを書いて処理できてれば今回の記事は必要ありません。そっとブラウザを閉じて下さい。そうでない場合、多くの人が直面する問題は次のようなものが考えられます。
- IDのオーバーフロー
- メモリが食いつぶされてバッチ処理が停止
それでは順番に説明します。
IDのオーバーフロー
大量のデータを日々のバッチで取り込んでいる場合、IDがオーバーフローしてしまう可能性があります。IDの最大値はINT型で2147483647もあるので通常利用している範囲ではオーバーフローすることは考えなくても(※1)大丈夫です。しかし、データの取り込みは追記だけとは限りません。何かの条件でDELETE & INSERTする場合、ID列の寿命は思っていたより早く尽きてしまうでしょう。
※1 毎日10万件のデータを取り込んだとして58年持つ計算。
そんな場合は思い切ってID列を削除してしまいましょう。
# migrationの定義 create_table :sales, :id => false do |t| t.references :customer t.date :sales_date t.decimal :total_sales end add_index :sales, [:customer_id, :sales_date], unique: true
IDを削除することの弊害
IDを削除することで、IDのオーバーフローに怯える必要は無くなりました。ActiveRecord::Baseのwhereメソッドによる検索も普通に使えます。findメソッドによるID検索が使えないだけだと思っていると、大きな落とし穴が待ち構えています。それはUpdateができないことです。
この問題を解決するためにはcomposite_primary_keys
というgemを利用しましょう。
Modelに次のようにキーを定義することでUpdateが可能になります。
class Sales < ActiveRecord::Base self.primary_keys = :customer_id, :sales_date end
メモリが食いつぶされてバッチ処理が停止
初めは快調に処理が進んでいたのに、だんだん遅くなって停止してしまう。こんな経験はないでしょうか?
▲こうなるともうお手上げ
メモリの消費をチェック
Linuxであればfreeコマンドでメモリの消費をチェックしてみましょう。
$ watch free -m total used free shared buffers cached Mem: 8000 6998 1001 0 340 2346 -/+ buffers/cache: 4311 3688 Swap: 10063 414 9649
バッチ実行中にbuffers/cache
のfreeの値がどんどん減っていくようであれば、あなたのバッチ処理は何かがおかしいです。
大きなselectを行わない
Sale.all.each do |sale| # 略 end
全てのデータを一気に取得して処理するのではなく、可能であれば小さい単位に分割しましょう。
Shop.all.each do |shop| Sale.where(shop_id: shop.id).each do |sale| #略 end end
適切な粒度でバルクインサートを行う
このような処理はメモリを食いつぶす原因となります。
Sale.all.each do |sale| OtherSale.create!(total_sales: sale.total_sales, ...) end
ActiveRecord.importを利用してバルクインサートを行いましょう。その際に、全てのレコードをインサートするのではなく適切な粒度になるよう気をつけましょう。
Sale.find_in_batches do |sales| # 1,000件ずつ取り出す list = [] sales.each do |sale| list << OtherSale.new(total_sales: sale.total_sales, ...) end OtherSale.import list end
最後に
バッチ実行中にだんだん遅くなっていく現象は、テスト段階では気づきにくいものです。本番運用が始まる前にかならずダミーデータを作成して検証を行うようにしましょう。
Jenkinsでmaster-slave間の通信が不安定なときはslave.jarの起動オプションを疑え
現在、awsのspot instanceを利用してRailsプロジェクトのテストを並列実行しようと試行錯誤しています。
なぜだかmaster-slave間の通信が不安定で困っていたのですが、ようやく打開策を見つけました。
症状
- slave側のテストの状況がモニタリングできなくなる
- slaveの処理が止まっているわけではないみたい
- nodeの接続がすぐに切れるわけではないが、しばらくすると切れてしまう
ログの状況
- 不安定なときのnodeのログは次のようになっていました。
[04/24/14 20:29:44] [SSH] ip-172-16-2-101.ec2.internal:22とのSSHコネクションをオープン [04/24/14 20:29:44] [SSH] 認証成功 [04/24/14 20:29:45] [SSH] リモートユーザーの環境: AWS_AUTO_SCALING_HOME=/opt/aws/apitools/as AWS_CLOUDWATCH_HOME=/opt/aws/apitools/mon AWS_ELB_HOME=/opt/aws/apitools/elb AWS_IAM_HOME=/opt/aws/apitools/iam (略) [04/24/14 20:29:45] [SSH] javaのJavaバージョンをチェック [04/24/14 20:29:45] [SSH] java -version returned 1.7.0_55. [04/24/14 20:29:45] [SSH] sftpクライアントの開始 [04/24/14 20:29:45] [SSH] 最新のslave.jarをコピー中... [04/24/14 20:29:45] [SSH] 404,201 バイトコピー. Expanded the channel window size to 4MB [04/24/14 20:29:45] [SSH] スレーブのプロセスを開始: cd "/media/ephemeral0/jenkins" && java -jar slave.jar <===[JENKINS REMOTING CAPACITY]===>channel started Slave.jar version: 2.39 これはUnixのスレーブです。 Effective SlaveRestarter on ip-172-16-2-101.ec2.internal: null Slave successfully connected and online Apr 24, 2014 9:28:47 PM hudson.slaves.ChannelPinger$1 onDead INFO: Ping failed. Terminating the channel. java.util.concurrent.TimeoutException: Ping started on 1398342287626 hasn't completed at 1398342527626 at hudson.remoting.PingThread.ping(PingThread.java:120) at hudson.remoting.PingThread.run(PingThread.java:81)
Ping failed.
だそうです。
- 解決方法
- slave.jarの起動オプションに
-text
をつける。具体的には[Jenkinsの管理] - [ノードの管理] - (ノードを選択) - [設定] でSuffix Start Slave Command
に-text
をつける。頭にスペースを入れること!
- slave.jarの起動オプションに
- Distributed builds - 日本語 - Jenkins Wiki によると
スレーブ起動のために、telnetのような (バイナリデータを直接扱えない) binary-unsafe なリモート操作用のメカニズムを使っているなら、 slave.jar の実行時に -text オプションを追加して下さい。
とあります。うーん。Macでmaster-slave構成を組んでいた時は何も問題が無かったんだけどな。ともあれ、slaveとの通信が不安定なときはtextモードを試してみましょう。
xip.ioの便利さに気づく
docker - Vagrantでdokkuを動かす - Qiita この記事の中に出てくるxipってのがよく分からなかった。 ググってもこんな人達がたくさん出てきて意味不明。
しかし、しばらくいじってみると使い方がだんだん分かってきた。IPアドレスをサブドメインとして指定すると、IPアドレスを返してくれるサービスらしい。
$ ifconfig (略) inet 192.168.68.9 netmask 0xffffff00 broadcast 192.168.68.255 (略) $ ping 192.168.68.9.xip.io PING 2kkse8.xip.io (192.168.68.9): 56 data bytes 64 bytes from 192.168.68.9: icmp_seq=0 ttl=64 time=0.054 ms 64 bytes from 192.168.68.9: icmp_seq=1 ttl=64 time=0.034 ms 64 bytes from 192.168.68.9: icmp_seq=2 ttl=64 time=0.100 ms $ ping konami.192.168.68.9.xip.io #頭に文字を付けてもよし PING konami.2kkse8.xip.io (192.168.68.9): 56 data bytes 64 bytes from 192.168.68.9: icmp_seq=0 ttl=64 time=0.059 ms 64 bytes from 192.168.68.9: icmp_seq=1 ttl=64 time=0.079 ms 64 bytes from 192.168.68.9: icmp_seq=2 ttl=64 time=0.079 ms
手元でVirtualHostによるアプリ切り替えが便利そう。 って、ここまで書いて思い出したけど昔Powを使ってた時にちらっと見たような気もするな〜。
1ヶ月間ソーシャルデトックスしてみて思ったこと
2014年1月はTwitterをほぼ利用しなかった。MacOS XのDockからTwitterを削除し、Android端末のホーム画面からもTwitterアイコンを削除し「見ない」「つぶやかない」を実践した。
きっかけは「キラキラッター」
「アイカツ!」という女児向けアニメはご存知だと思う。念のため説明しておくと、主人公「いちご」、その幼馴染「あおい」がアイドル養成学校「スターライト学園」でカードを集めながら仲間とともにトップアイドルを目指すという熱いスポ根アニメだ。 2013年の年末、ふとしたきっかけでこのアニメをまとめてDVDで1話から観てたのだが、第7話「つぶやきにご用心」という話で私の中に稲妻が走った。 7話のあらすじはこうだ。
いちごとあおいはそれぞれ別々のオーディションを受ける。ライバルへの対策として「キラキラッター」での情報集めに夢中になるあおい。だが夢中になりすぎるあまり、親友いちごの言葉は届かなくなる。 オーディション当日「オーディションがんばって!」と笑顔で声をかけるいちごに対して、あおいは何の言葉もかけることができなかった……
TL追うのってそんなに重要なことなんスかね?
例えばある人と一緒にご飯を食べに行くとする。その人はろくに話もせずにTwitterのリロードを繰り返している。その行為に違和感を感じていた。(ま、私もその間リロードしてたりするわけですが) 一緒の時間を共有している時くらいリアルで話そうぜと。Twitterを眺める時間は楽しい。楽しいが、リアルで共有している時間を削ってまでTwitterの情報を漁ることにそれだけの価値があるのだろうか。
改めて見返してみた
自分のTLを冷静に読んでみた。
- 診断メーカー
- 社畜ネタのグチ
- 意味がわからない内輪ネタ
もちろん有益な情報も存在するが、私にとってどうでも良いような話題に埋もれてしまっている。
自分のつぶやきは?
……やっぱりどうでもいいような、くっだらないことばかりつぶやいてた。 これシェアする意味あるの?
Twitterを断ってみてどうだったか
実は2013年秋ぐらいから徐々にTwitterを見る回数を意識して減らしていたので、完全に見ないでいることもそれほど苦痛ではなかった。 普段のリアルの会話のネタはTLから直に拾い上げなくても、翌日になれば、はてブのホットエントリーに入ったり、Gunosyで配信される。 ちなみにTwitterから定期的に配信される「◯◯他n人からのツイートがありました」というメールは、ほとんどがはてブの記事なので大して役に立たなかった。 一方、気になる人の動向を追うことができないのは、非常に不便に感じた。
自分が欲しかったもの
はてブやGunosyで話題になるネタはTwitterで見る必要はない。何度もRTされ、話題になり洗練されたものだけが翌日届けば良い。 そうではなくて「離れた場所にいる人が何をしているか」っていうことが本当に知りたかったんだ。あー、なんて当たり前のことなんだろう。
これからどうするか
近場にいる「リアルな知り合い」のフォローは外していいと思っている。近いんだからリアルに話したいし、たまに出会うから「最近どうよ?」って話もできる。何の情報でもシェアするのは好みじゃない。 むしろ、よく「読む」必要があるのは遠隔地にいる人だと思った。
自分のツイートに関しては「シェアする必要性」を考えて行うようにしたい。考えたことを口にする前に、頭のなかで一旦保留にするのと同じだ。頭に浮かんだことをそのままツイートするのは愚かなことだと思う。
私は「アイカツ!」の蘭ちゃんのように「ネットでだれかと繋がってたいとは思わない」とピシャリと言えるほど、ネットと無関係な生活を送っていない。SNSが当たり前にあるからこそ、一旦デトックスして付き合い方を考える期間をとってみて良かった。
久々にcapybara-webkitをLinuxで使ったら高速になってた
capybara-webkitをLinuxで使うと、なぜだか実行速度が遅いという問題があったんだけど最近になって改善されたみたい。めでたい!!
capybara-webkitを使うためにはQtをインストールする必要があります。OSはScientific Linux6.4の例です。
$ wget http://releases.qt-project.org/qt4/source/qt-everywhere-opensource-src-4.8.5.tar.gz $ tar zxvf qt-everywhere-opensource-src-4.8.5.tar.gz $ cd qt-everywhere-opensource-src-4.8.5 $ ./configure $ make (時間がかかる。一晩覚悟しろ) $ sudo make install
インストールが完了したら.bashrcにでもPATHを追加しておきましょう。
$ vi ~/.bashrc PATH=/usr/local/Trolltech/Qt-4.8.5/bin:$PATH:$HOME/.rvm/bin
何回かMacOS XとScientific Linux6.4でCucumberを実行してみたのですが、実行時間の誤差はほとんどありませんでした。これで高価なMacを購入しなくてもインテグレーションテストをガンガン実行できるぜ!
追記(2014.01.27)
やっぱり勘違いでした。仮想環境含め様々なマシンで検証したんですが、高速なビデオカードを搭載したマシンだと動作が高速な気がします。