読者です 読者をやめる 読者になる 読者になる

The Beatles EIGHT DAYS A WEEK THE TOURING YEARSを見てきた

音楽 映画・テレビ The Beatles

thebeatles-eightdaysaweek.jp

いくらThe Beatles好きだからといって*1、ぶっちゃけアンソロジーシリーズでいろいろライブ音源は出てるし、Live at the bbcシリーズで質のよいライブ音源もあるし……とそれほど期待せずにいきましたが全体的にはなかなか面白い内容でありました。

基本的にはライブ活動を通したビートルズという切り口で進んでいくので、ライブ活動を停止した後期ビートルズあたりはLet it be時期まですっ飛んでいくし、ライブ活動を停止するまでのメンバーの気持ちのうつりかわりなんかはアンソロジーシリーズを言及するまでもなく、様々な媒体で描かれてきたことなので基本的には知ってる話である。

ただあの時代の空気感をいかに伝えるかというところは結構頑張っていたと思う。観衆がShe loves youを合唱しているシーンが白黒の映像で映し出されたが、あのシーンは結構胸にきた。今の時代にああいう風に歌うことあるのかなぁという思いとともに、あの時代の空気感を感じた。またあの頃世界的(というかアメリカに絞ってか……)にどういう事件があったかも関連づけられ、公民権運動の激しいアメリカ南部の公演では契約で白人黒人分けることはまかりならんと突っぱねる新事実もあったり、結構世界史を勉強した記憶を掘り起こされたりしました。

後はリアルタイムで体験してきた人にインタビュー取るのはうまいなぁと。あのときどうだったのかを語るにはよいもっていきかたですな。

それにしても拡大していくライブ会場で、まともなPAもない状況なのにあれだけ残っている音源などでレベルの高い演奏をしているのが、ハンブルグ時代などでもまれまくったためなのかなんなのか。映画のあとにシェアスタジアムでのライブ映像が30分流れていましたが、5万人という大観衆の中で演奏がよれることもなくきっちり仕事していったのがすさまじい。自分の身に置き換えたときにまともなモニターもなく自分も音も聞こえない状態で、なぜあの演奏ができるのか、そのへんこともしっかり掘り下げてほしかったなぁとは思う。

なので個人的な感想としてはThe Beatlesのライブ活動を俯瞰するにはよい映画、でももっと細かなところを掘り下げるのもしてほしかったというところでしょうか。2時間半という長丁場なのでちとおすすめしにくいけど、それなりに満足感はあるのでひまなときに見てみるのもよいのではないでしょうか。

そういやちょっと前にハリウッド・ボウルでのライブ音源がCDとして出ていて、自分もちょくちょく聴いているのだけどこれのレビューはまた別にあげようかな。

*1:しかもめんどくさい勢である

飛び飛びですまん、な出町桝形商店街の黒板

写真 iPhone

2期!

お、更新前

今週は休み多いのと台風きちゃったから家で仕事してたのよね。出ないからしかたないね。うん。

たまたま買ってきたにごり酒がおいしい。この記事は酔いながら書いています。

ISUCON6の感想書くまでがISUCONと聞いた #isucon

開発 Ruby ISUCON

isucon.net

予選がすべて終了して感想も解禁ということなので、ざっくりと感想をば。

会社の同僚と参加しましたが、結果的には予選敗退ということで残念な結果に終わりました。自分は初参加でしたがこの結果はとても悔しいですねぇ……ボトルネックの部分の洗い出しはちゃんと行われていただけに、そこを徹底的につぶしていけなかったのが敗因ですね。

開始直後の1時間ぐらいの情報集めやあれこれ設定などはインフラ担当のかたが素早くやられて、特に問題なく進んでいった感じでした。自分ともう一人はruby実装の作りを見たりMySQLのデータをのぞいたりと情報集め。作りとしてはisudaがブラウザからのアクセスやキーワードの登録、ログインなどを担当していて、isutarがスターまわりの管理をしていて相互にデータ通信している、それとは別に中身のわからないspamチェック用サーバが動いているということが判明。とりあえず方針を決めて、余計な通信や処理しているところは削除したり処理を置き換えたりしていく。

この段階でrack-lineprofつかって計測とかしていて、ボトルネックになるのはisuda.rbのhtmlifyメソッドということはわかっていたんですが、ここ手をつけるの大変じゃね?と後回しに……ここでもうちょっと強くおしておけばよかったかなと思ったり。

github.com

このあとベンチマーカーを通してメッセージ等出てきたら原因になりそうなところを探してつぶすみたいなことをしていたが、あまり点数も上がらず時間は過ぎていくばかり。結局、終了2時間程前になってhtmlifyメソッドを改善していくことになりDBにテーブル追加したり、キャッシュしたりして5万台まで持って行ったがタイムアウト

終わってみると時間のかかっている箇所をいかに早くするかという、通常のWebアプリでもよくある話だったなぁという印象です。巨大な正規表現と変換処理をどうするかってところに注力していれば予選突破できたかなぁという感触です。

それにしても終わったあとはくたくたになっておりました。おかげで今風邪気味……しっかり養生します。

めずらしく土曜に会社まで行っていたので、出町桝形商店街の黒板

写真 iPhone

ほほう

なんかでかい黒板が

京まふ

いつものがでてなかったあ

明日か

今日はあった

なんで土曜も行ったのかは後日。

そういや昨日はTOKYO MXたまこラブストーリーがあったそうで……思わず帰りに撮っちゃうよね。

しまっちゃいましたね…

帰宅中

映画は名作だし、サウンドトラックも素晴らしいので是非買いましょう聴きましょう見ましょう。

RubyKaigi 2016 3日目メモ #rubykaigi

開発 Ruby

rubykaigi.org

raydive.hatenablog.jp

raydive.hatenablog.jp

引き続き最終日も参加してきました。"Deletion Driven Development: Code to delete code!"でのエッジケース乱舞は本当につらい案件であり、入らないコードはざくざく削除していこうと思いました。ちなみにC#で似たようなことをしたことありますね……あとHTTP/2の話は非常に勉強になった。

Web Clients for Ruby and What they should be in the future

  • Toru Kawamura
  • Rubyで書かれたWeb APIにアクセスする人が操作するクライアントを対象
  • ほしくないクライアント
    • 簡単に変更できない
    • 再利用できない
  • 今のgem
    • ドキュメントからgemを作成
      • API変わると作り直し
    • ドキュメントに変更を書くのではなくAPIのレスポンスに書くと対応できる
  • 疎結合なクライアント
    • URLをハードコードせず、リンクをたどる
  • Web APIは簡単
    • net/httpとかつかってる?
      • 他に使っている
    • Web API gemいっぱいあるよね
      • 一長一短
      • 提供する側からだとどうか?
        • インタフェースの再設計
        • 複数言語の対応は大変
      • なんでいっぱいある?
        • レスポンスのJSONの構造の違い
        • 行いたい処理とAPI一回の動きのギャップ
  • Web APIでの状態管理
    • クライアントが状態管理してしまえばいいと思っている
  • ほしいWeb Clientsは状態管理できるもの
  • サーバ側のrackみたいにクライアント側も決めごとがあればいいかなぁ
    • Faradayがあった
    • Rack Middlewareのような形を採用している
    • gemでつくるのではなくFaraday Middlewareでつくるのが再利用もしやすいのではないだろうか
  • gemを作った
    • faraday-navigatoin
      • back/forward
      • リンクをたどる
        • RFC5988
        • RFC6570
    • faraday-link-extractor
      • リンクを抽出してLink/Link-Template headerに変換する

Deletion Driven Development: Code to delete code!

Deletion Driven Development: Code to delete code! - RubyKaigi 2016

  • Chris Arcand
  • コードを殺す方法w
  • コード書くのも好きだけど、削除するのが好き
  • Dead
    • over engineering
    • poorly written
    • refactoring
  • 誰がめんどうみるの?
    • deleting code 2002
      • コードのノイズは開発者の大敵
  • どうやって削除するコードみつける?
    • その方法
  • .rb => ???
    • 静的なチェック
    • parsing the code
      • CFG
      • BNF
        • 解析してルールにあわないものをはじく
      • Rubyだとどうする?
        • ruby_parcerでパース
    • Processing the s-experession
      • S式からメソッドがどこで定義されてるか洗い出す方法
    • Find deleting method
      • sendでメソッドコールすると見逃す
        • S式で判断
      • attr_accessorが見逃されてる
        • これもエッジケース
  • Rubyは難しい
    • エッジケースある
  • Rails DSL
    • エッジケースおおすぎ……
  • gemあり
  • debride以外もいろいろある
  • メソッドが相互に呼んでる場合は検知できる?
    • できない?
  • Railsのunused actionは検知できる?

Recent Advances in HTTP and Controlling them using ruby

  • Kazuho Oku
  • Current State of http
    • なんでhttp2か?
      • レイテンシがボトルネック
      • http2ではconcurrencyでレイテンシを隠蔽
    • 2015/5 released
      • 全体の3割がhttp2
    • http2 feature
      • header圧縮
        • positiveな結果 中央値で90%データ削減
      • 多重化&優先順位漬け
      • push
        • positive&negative
          • pushしたものの5割が無駄
  • 問題点をどうやってfixするか?
    • 理想 => 優先順位が高いリクエストに早く返す、リソースを正しい順序で返す、ないデータをpushする
    • どれもできてない
  • head of line blocking
    • 優先度の高いデータがあるけど低いデータが滞留しているのでおくれない
    • 技術的に解決できそう
      • 実装して評価
        • 理想的な最適化を得られる
  • 優先順位漬け
    • クライアント側で提示、サーバで参考にして送る
    • CSSJavascriptが帯域のほとんどをしめる
    • SafariやBlinkは優先順位漬けしてくれない
      • 画像が帯域をしめてしまう => HtmlやCSS, Javascriptが後回し => 表示が遅くなる
    • バンド幅の正しいわりふり
      • WFQやDRRを使ってスケジューリング
        • nghttp2とかH2OはWFQを実装
      • 頭の悪そうなクライアントにはCSSJavascriptを先に送信する
  • hidden resource
    • CSSの@importなど
    • リソースみつかるまでに画像が流れるので遅くなる
    • Hidden resourceを使わない
    • preloadタグを使う
  • push
    • 優先順位漬け
    • リクエスト処理中にpush
    • CDNからpush
      • いくつか考えられている
        • RUM(ログとかから学習してpush)
        • DSLベースでやる
    • 複数の中間レスポンスと一つの最終レスポンスを返せる(HTTPの仕様)
      • Unicornはraw socket, Pumaはパッチ当てる必要あり
    • H2Oはmrubyでハンドラかける
    • Push vs Cache
    • 画像はpushしないようにしたほうがいい
      • pushしたデータとpullしたデータの優先順位がむずかしい
      • JSやCSSはpushしたほうがいい
      • head of line lock問題が顕在化しやすい
    • http2はポピュラーに
      • まだ使うモノによって差がある
      • H2Oつかってね

Optimizing Ruby

  • Urabe, Shyouhei
  • deoptimizotion over Ruby2.4
  • Rubyは遅い
    • どちらかというと遅い方
    • 最適化されてないから
      • 1 + 2 => 3?
        • +が再定義おこなわれる可能性があるため3とは限らない
  • Deoptimization
    • 再定義がなかったとして最適化
    • 再定義されていたらフォールバック
    • JRubyやRubinuisにもそれぞれで実装
  • Strategy
    • nativeにはしない
    • sequenceにパッチするかたち
  • 何がいいか
    • Pure C コード
    • program counterをいじらない
      • VMの状態を戻さなくてイイ
  • 再定義の検出
    • 別途カウンタを用意
  • Optimize on it
    • いくつかの最適化をした
    • これまでの最適化は動的におこなわれる
    • ほかにもやることはある
  • benchmarks
    • make benchmark
    • 一応はやくなってる
      • 最適化の結果シーケンスが同じになるものもある
    • vm2_eval
      • 邪悪なやつ
      • overheadで遅くなってるがまあこの程度ならはやくなってるかな
  • はやくなったのはめちゃはやくなった、遅くなったのはちょっと遅くなった
  • methodがpureかどうかの判定はrubyでわかる
    • ある、つくりました
  • 最適化の方法でメモリの使用量はふえてそうだけどどの程度増えてる?
    • 増えてますがまだ評価していない
  • 大きいアプリケーションでの評価は?
    • まだ
  • Folkで影響あるように思えるけどどうか?
    • そこのところ考えてなかったけどありうる
  • 最適化したあとのシーケンスが長くなる場合には?
    • まだそこは考えられてない、対応必要

Hijacking syscalls with (m)ruby

  • Franck Verrot
  • mrubyをいろんなシステムに組み込んできた
    • 今Redisやってる
  • System call
    • osとのinterface
  • Hijacking syscalls what for?
    • Sercuring Ruby apps is kinda tricky
  • なんでmrubyでsyscallsをオーバーライドするか
    • Rubyすきなので
    • Higher level
      • superでもとのが呼び出せる
    • creating an embeddable mruby
      • 組み込みやすい
      • モジュラー構造
      • 複数VMを単一プロセス
  • performance
    • naive implementationだと24倍遅い
    • optimized implementationだとnaiveより10倍速い
  • system callを置き換える理屈というかうれしさがイマイチぴんときてない

Dive into CRuby

  • NARUSE, Yui
  • CRubyへの貢献
  • 新機能
    • なぜ追加する => いまあるものじゃだめだから
    • 実際にどういうコードの場合にだめなのかということをしっかり固める必要がある
      • 必要は発明の母
    • 例:壊れた文字列
      • webクローラーでOK
      • 壊れたファイル NG
        • そもそも壊れたファイルを無理矢理読み込む必要はない
  • 新環境
    • しばしば動かないこともある
    • clang
      • gccと違う最適化する場合がある
    • Visual C++ 2015
      • C Runtimeがコンパチビリティーを破壊
      • かなり邪悪なコードをいれてうごくようになった
  • 最適化
    • ボトルネックを探す
      • derailed benchmarks
      • new rewlicでスタックトレースとれる
        • めっちゃ深いのでrails側で頑張ってください
      • no bottle neck => とりあえずString#blank?はやくする
    • Regexp#match?
      • $&への保存がない
      • SSE4.2で高速化 => 終わりが結構めんどくさい16byteないとSEGV
      • ARM SVE => 末尾でページをまたぐ場合の処理を考えている
    • Ruby VMの高速化
      • Cのレイヤー
      • perf report
      • vm_exec_core
        • core function of RubyVm
        • ここはbottleneckじゃない
    • こういうのを早くしてほしいなというベンチマークを用意できると、JITをいれるというモチベーションがあがるかも
  • Debugging/ Profiling/Tracing
    • 期待通りに動かない、遅い、クラッシュした
    • メモリを食ってる場合
      • perf-top
      • ps(1)
      • procfs
      • ObjectSpace
      • GC.State
      • sigdump
    • get stuck
    • SEGV
      • バグ報告するときには全部貼り付けておくってください
      • C levelのバックトレースが重要
        • 通常は非公開になっている関数名とかがとれる
      • core file
        • .gdbinit for CRuby
  • まとめ

おまけ

今日の弁当

今日も美味しかったです。はい。

RubyKaigi 2016 2日目メモ #rubykaigi

開発 Ruby

raydive.hatenablog.jp

rubykaigi.org

2日目も参加。国際会館駅についたのがぎりぎりになってしまったので、一番はじめの途中から入ってしまった。ちょっとこれはもったいなかった。あと英語があんまり頭に入らなくて、ちょっとこれはやばいと思うのでなにかせねば。

とりあえずSutureとScrawlsはチェックしておこう。

あと丸善ジュンク堂ブースでみんなのGo言語【現場で使える実践テクニック】を購入。

みんなのGo言語【現場で使える実践テクニック】

みんなのGo言語【現場で使える実践テクニック】

Fearlessly Refactoring Legacy Ruby

How to create bindings 2016

  • Kouhei Sutou
  • Binding?
    • CとRubyをつなぐ、Cの機能が使える
    • Rubyを使えるケースが増える
    • GI(GObject Introspect)がおすすめ
  • Demo
    • Webブラウザを使う
    • Webkitのデモ
    • ロードするのは非常に簡単に見える
    • バインディングで生成したオブジェクトに対してブロックを指定したりできる
      • Rubyっぽくかける
      • Cでenumで指定するところが、Symbolで指定できる
  • 拡張ライブラリ
    • Cで書かれたRubyライブラリ
  • Libffi
  • 手書きや自動生成での拡張ライブラリの説明
    • 自動で生成しても、使いやすくするためには手で書く必要もある
  • 手書きや自動生成のlibffi
    • バインディングRuby側(拡張ライブラリはC側)
    • GIはgobject wrapperの部分が増える
      • でも書くことは少ない!楽!
  • 自動生成の違い
    • swig ビルド時 => 新しいライブラリが出たら再ビルドする必要がある
    • GI 実行時 => 再ビルドは必要なし
  • OSS gateとClearcode boothの宣伝
  • 速度面はどうか?
  • C++のクラスとか構造体とかをマッピングするときはどうするの?
    • GIで面倒見てくれる
  • rubyから数値配列つくるときは自動変換してくれる?
    • それらも自動変換してくれる
  • Macでもつかえる?
    • 使えます 例:rabbit
  • GIだと登場人物増えるけどトラブルシューティング大変じゃない?
    • 私ぐらいになると大丈夫(どっ)
    • CとRubyと元の
  • SWIGも建前上は全言語いけるのでは?
    • 現実的には各言語のCライブラリつかわないとつらいものもある
  • GIの場合は動的に作られる=>でかい場合はロードに時間がかかる?
    • でかいgtk3ですぐ
  • 速度は?
    • Giだと結構オーバーヘッド食う
  • GIを覚えるコストはどのくらい?
    • rdocのフォーマット覚える程度なので軽いと思う

How DSL works on Ruby

  • SHIBATA Hiroshi
  • rake
    • make like
  • DSL
    • 特定のドメインを解決するための言語
    • Rubyの言語を特定のドメインの言語として読むほうがおおいかな
    • 実装におけるいくつかのパターン
  • DSL in gem
    • rakeのコードリーディング
    • capistranoはrakeを継承 => capistranoはrake拡張(capistrano3から)
    • Thorはrake関係なし
      • Thorクラスの中にDSL関連の実装を詰め込んでいる
    • Bundler
  • Rakeの話
    • JRubyだけで落ちるテスト => 修正
    • ToDOで残してたdeprecated codeを削除 => 他のライブラリに波及(ひええ)
    • Rake12
      • Ruby 2.2以降
        • -jでつかってる外部のコマンド呼び出しをEtc.nprocessorに置き換えたい
      • 仕組みを簡素化したい
      • defualt taskの記法を追加
        • 記法変更するとObjectにメソッドが生える => あんまりしたくないので、解決する仕組みをどうするか考えている
  • DSLのつらさを改善するtips的なこととかアドバイスあるか?

Learn Programming Essence from Ruby patches

  • Mitsutaka Mimura
  • プログラミングの知識
    • 言語仕様やライブラリの使い方
    • アルゴリズムとか
      • これらの勉強の仕方は?
        • 本を読む
          • 実プロジェクトと教科書との乖離
          • Programming Technics
  • パッチを読んで勉強!
    • Why patch?
      • コードベースが小さい(対象箇所わかりやすい)
      • コミットメッセージなどの情報がある
      • わかるところが選択できる
    • パッチでライブラリの使い方やアルゴリズムもわかる!
  • Rubyのパッチを読もう => 多少はRubyの中身をしらないと大変
    • Ruby Under a Microscope
    • doc/extention.rdoc
    • slide
  • Example
    • st_tableに対するパッチ
      • Hashを作ったときなど大事な構造体
    • hashのキーが衝突する場合 => Rubyだとチェイン法をつかっている
      • そのためのst_table_entry内のnext
    • パッチではオープンアドレッシングに変更
  • パッチ単体だと動きがみえないときもありそう

Web Server Concurrency Architecture

  • Kirk Haines
  • Web Server
    • Shellでも作れる
  • Scrawls
    • Pluggable IO Engine
    • Pluggable HTTP parsing
  • Single Threadでもベンチの結果はわるくない
    • ネットワークのレイテンシも短いし、この結果だけだと落とし穴がある
  • Concurrency
    • Multiprocessing
      • 実装はシンプル
      • プロセスの管理大変、リソース共有も大変
    • Mutlithreading
      • 管理は楽でライトウェイと
      • ロックの問題とかThreadは難しい
      • そのあたりはいっぱい記事あるのでそっち読んで
    • Event Driven
      • はやいしリソースにもやさしい
      • 不利な点を聞き逃した
        • 多分一般的に言われてるやつ
  • 他のRubyウェブサーバを説明
  • 細かい数値がおおかったので、資料として公開してもらえるといいな
  • 話としては基礎的なところからWebサーバにおけるConcurrencyを説明、Scrawlsでそれの違いを数値として表してみるというところ

Pwrake: Distributed Workflow Engine based on Rake

  • Masahiro TANAKA
  • NArrayの作者
    • 今年になって進捗あり
  • Pwrake
    • rake拡張
    • 並列分散して実行
  • 例:天文での画像
    • 複数の画像を連結して一つの宇宙の画像にする
    • 並列で処理できる
  • ワークフローを記述する言語
    • XMLベースのモノ
    • 新規言語
      • 学習コストが……
    • 既存のものを拡張
      • 例:GXP make
  • Rakeのいいところ
    • Rubyスクリプトとして使える
    • Pathmapが便利
    • 他にも便利なので、rakeはワークフロー記述言語としてぴったり
  • Pwrake
    • Master nodeとWorker node
    • ThreadとFiber
      • ThreadはやはりややこしいのでFiberを使うようにした
      • 非同期IOが必要……
    • File sharing
      • NFSなども検討してGfarmFile Systemを採用
        • 計算ノードのローカルストレージを束ねる
        • Meta Data Serverがスケーラブルでない
          • ここでこけそうな
    • ローカリティを考えたスケジューリング
      • IOで別ノードのファイルを読んだり、書いたりすると遅くなっちゃう
      • DAGを使ってグラフを分割、ローカリティを上げる
        • 提案手法で何もしない場合より性能があがった
    • 耐障害性
      • Master失敗だと再実行
      • Workerは落ちてもワークフロー全体は止めない
        • 別のノードで実行
        • あるノードで実行に失敗しつづければ、障害発生として別ノードで実行
    • 採用例
  • Inputがファイルに特化している?
    • その通り
  • 各ノードの生存はどうやって監視している?
    • 監視はしていない
  • 一つだけ処理失敗したときのとかは?
    • そこまででとまる
  • Gfarm File Systemがなくても動く?
    • 動きます

Modern Black Mages Fighting in the Real World

  • Satoshi "moris" Tagomori
  • メタプログラミングユースケース
  • fluentd
    • OSSのログコレクター
    • ロゴがかわった(目立たせるため)
  • 黒魔術
    • 例の黒魔術師
  • v0.14でネームスペースがかわった
  • 0.12ではクラスによってemitメソッド内の呼び出しがことなる!
    • ややこしい
    • 非常に問題が多い
      • 3rdパーティのプラグインがfluentdのコアを直接呼び出す
        • fluentd側で処理がやりにくい
      • ドキュメントも書きにくい
  • 0.14
    • エントリーポイントを分割する
      • コアのメソッドを上書きさせない
    • コールスタックが一本道になる
  • 0.12でのプラグインはどうするか?
    • そのまま動く必要がある => 死
    • 0.12が動くコンパチビリティーレイヤーを用意
    • コンパチビリティーレイヤーで3rdパーティの呼び出してるメソッドを判定して切り替える
      • 黒魔術!
    • moduleを動的に生成してemitメソッドをはやす
    • あるメソッドの前後ろにフックをつけられるようmoduleをincludeしたりextendしたりする
  • pluginのlifecycle
    • Module::Prepend
  • singleton_classをさらにprependする => 真っ先に呼び出されるメソッドができる
  • 正直よくない!
    • v0.14用のプラグインにバージョンアップを心がけてください
    • ただユーザに不利益を被ることはあってはならないので、黒魔術でもなんでもやる
  • 呼び出しは複雑、あれを設計するときどうした?
    • 図を書き出した、そもそも0.12の動作について理解ができてなかったので書き出した
  • OSSとか後方互換性がんがんこわしていくこともあるけど、プラグイン書き直しと考えることは?
    • あったけど、現状プラグインの数がおおいので単純に書き直しは大変
    • Rubyコミュニティとは別のところで発展していった。互換性を壊すということに敏感なところもあるのでそういう手はとらなかった
  • 0.14の機能を0.12にバックポートすることは?
    • そもそも機能を増やすのが無理だったので、バックポートはできない
  • 性能への影響は無視できる
    • 無視できる

SciRuby Machine Learning Current Status and Future

  • Kenta Murata
  • enumerable-statistics.gem
    • ベンチがめっちゃはやい、すごい
  • Ruby機械学習したい => Rubyでデータサイエンスをしたい
  • SciRuby開発したい人来てください
  • 機械学習、なぜ?
    • データからビジネスの意思決定したい
    • データがでかくなってきたので、機械学習で傾向を知りたい
  • いくつかライブラリはある
    • liblinear
    • rb-libsvm
    • decistiontree
    • 実用にはほど遠い
  • real world Machine Learning
    • データでかい、欠損値ある、どのアルゴリズムがあうのかわからない、比較しないといけない
  • Scikit-learn
  • Future SciRuby
    • Scikit-learnのようにしたい
      • 直接Scikit-learnそのものを使えるようにする
        • Juliaの例
    • Scikit-learnのようなものを作る
      • 難しい
      • Cython-like systemが必要
        • rebex
      • Numerical array
  • いろいろ活動しはじめているので、参加してください

おまけ

今日の弁当

うむ

今日も美味しかったです。

RubyKaigi 2016 1日目メモ #rubykaigi

開発 Ruby

rubykaigi.org

初参加だ

今年は京都で開催、しかも国際会館なので地下鉄一本でいけるアクセスのしやすさということで、Super Early Birdで申し込んで会社も有給休暇とって万全の体勢で行ってきました。今日は未来と過去の話、コンテナに関連する話が多め? 個人的にはhaconiwaとジョブキューシステムが気になる。DockerだとToo Muchになることもあるんじゃないかなといろいろ試してみて思っていたので、haconiwaのわかりやすさというのがよさげ。" Isomorphic web programming in Ruby"の発表は内容の面白さもさることながら、お手本にしたいプレゼンの進め方をしていた。非常にわかりやすくデモもスムーズにいっていてすばらしかった。

Ruby3 Typing

  • Yukihiro "Matz" Matsumoto
  • 大事なことは日本語で
  • Ruby3
    • Performance
    • Concurrency
    • Typing => Matz
  • 2010's
    • Many Static Typed Lang
  • "Ruby is dead" "Rails is dead"
    • Don't have Static Type
  • 技術は行ったり来たりする
  • Futre of (Dynamic) Typing
  • What is Type?
    • Class は型ではない
    • 継承も内部構造も関係ない
    • 振る舞いが大事
      • 動けばいい
    • ここでスライドにトラブル
    • StringIOとIOの例
      • Static Typeだと動かないlog
      • Duck Typingは未来に開かれている
  • Rubyの型とは? Duckという概念
    • Duck is not a (nominal) Type
    • Duckは期待する振る舞い
    • ClassによるTypeは近似でしかない
  • GoのInterfaceはいい
    • Wirteメソッドをもっていることだけが期待されている
  • Duck Typingは素敵
  • DRY
    • 冗長性は削りたい
  • Dynamic Typingの欠点
  • 絶対に型を書きたくないMatz
  • ドキュメンテーションがほしい
  • 一部型指定とかいろいろ提案あるけど、どうもイマイチ
  • いろいろ課題はある => 改善の余地がある
    • エンジニアは技術でなんとかしたい
    • Static Typing with Type Inference(型推論
      • 静的な型は柔軟性が……
    • Rubyとしては別の何かが必要
      • Call soft Typing
      • Soft Typing
        • 振る舞いで決まる
      • 型の名前を決めるのは難しい
      • すべての型チェックできないこともあるが、元々0%なのでまし
    • 実行時の型情報なんかも使えそう(Gemのテスト時に得られたものとか)
      • Type DatabaseをGemと一緒にだしてコード補完に活用したり
  • まだ構想段階なので動いているものはない
  • We Care about YOU
    • 開発体験を改善したい
  • Ruby3いつくる?
    • わかりません
    • ちょっと無理そうな期限を設定してはっぱかけるのがコミュニティリーダーの役割かな?
    • 東京オリンピックのときにあるといいなぁ
    • 前に進み続けないといけない
  • Soft Typingの用語が元々アカデミックな用途と違うけど
    • 新しい言葉が必要

dRuby in the last century.

  • Masatoshi SEKI
  • dRuby => from 1999
  • 2000年にdRubyの話をここ(国際会館)でした
  • dRuby is OOPARTS
  • before dRuby
    • 昔っぽいUNIXを使った組み込みシステム
      • 小さなデーモンの組み合わせ
      • fork, pipeなど
      • selectはなかった
    • CGIの単純な世界
      • 俺マイクロサービス世代
    • ruby & shttpsrvにであう
      • 小さいアプリにwebサーバを組み込む
    • なにか気に入らない
      • RubyとWeb世界を翻訳しないといけない
    • Rubyのように振る舞う分散オブジェクト
      • RPCじゃくてRMI
    • 分散オブジェクトがあるような演出
      • 簡単通信ライブラリではない
  • dRuby
    • 分散オブジェクトシステム
    • プロセス超えてメソッド呼び出せる
  • みんなでデモやる
  • OOPっぽさ
    • 相互に呼び出せる
    • 仕組みは本買ってください
  • Twitterの初期はdRubyとRindaだったらしい
    • いまはつかってない
  • dRubyではじめて最後は使わなくなることがある
  • これから
    • 直したいところ
      • セキュリティっぽいのを消したい
        • アブナイモノは危なく見えるべき
      • UnitTest
    • 啓蒙していきたい
      • まずおもしろがってもらう
      • 並行処理の勘所に気づいてもらう
  • わかる人がわかればいいと思ってたけど、心境の変化とかあった?
    • はい
  • るびまで寄稿お願いします

Welcome to haconiwa - the (m)Ruby on Container

  • Uchio KONDO
  • Before Haconiwa
    • Docker, LXCを経験
  • Dorne.io
    • Dockerを使ったin houce CI
    • 変なバグふんだ
    • operation大変
      • LA, CPU usage, memoryつらい
  • Sqale
    • PaaS by GMO Pepabo
    • LXC usa
      • resource reallocation
      • configから変更したり手で変更したり煩雑
  • ぶつかった問題を解決するコンテナを作りたい => Haconiwa
  • Small tour of Haconiwa
  • Container technology overview
    • mruby, mrib使用
    • Linux namespace => partitions in OS resources
    • cgroups => CPUの使用制限など、デモでcpu4個あるが2つまでしか使ってないところを見せる
  • Container = Isolation + Limitation
  • Haconiwa & mruby
    • はじめはcruby使ってた
    • うごいたけど……
    • system callsで制限
  • mrubyに置き換え
    • c system callつかうので
    • いろいろgemがあった
    • 自分でも書いた
    • mruby-cli
  • Container as Codeに落とし込める(まだ開発中だけど)
  • Containerの数が変わったりしても、同じ数に維持できる
  • mrubyをつかうことで大変だったこと
    • ドキュメントが足りない
    • ドキュメント書く人がほしい
  • 目的を達成はどのくらい?
    • あと一歩
  • Jailとかはどうか?
    • 今は計画なし
    • FreeBSDの経験ないのでやろうとすると時間かかる
    • He said NO!

A proposal of new concurrency model for Ruby 3

  • Koichi Sasada
  • だいありー
  • 平行並列の八票多いのでconcurrent ruby kaigiではないか?
  • マルチスレッドプログラムの難しさ
  • Rubyは安全性、簡単さを想定
  • マルチスレッドプログラムを正しく実装するのは難しい
    • 簡単なものだったわかるかもしれないけど、どでかいプログラムだと? ましてやgemの内部の問題なんかだと?
  • Ruby3でのConcurrency
    • Guildというものを導入する
    • Guildの中にスレッドが存在する
    • mutableなオブジェクトはGuildの中に存在する
      • メンバーシップがある
      • 他のGuildからはアクセスできない
    • Guild::Channelでやりとりをする
  • GoLangのChannelみたいな感じ
  • Array#concatの例からすると、やってることが違うような?
    • ああいうことをやれないようにするという提案

Isomorphic web programming in Ruby

  • Yoh Osaki
  • Opal
  • Hyalite
    • React like viretual DOM library
  • Isomorphic programming
  • Menilite
    • 作ってるところ
    • サーバとクライアントでRuby Codeを共有
    • ActiveRecordも対応
  • デモ
    • スムーズなデモ
    • 簡単に見える
  • Reactive RecordというActiveRecordを使ったものがある
  • サーバサイドとクライアントサイドではモデル求めるモノが違う
    • Meniliteを作った理由

Unifying Fixnum and Bignum into Integer

  • Tanaka Akira
  • Ruby2.4
    • Unify Fixnum And Bignum into Integer
    • Ruby使う人はFixnumやBignumクラスはなくなる
    • C使う人はいくつかのグローバル変数がなくなるので、影響あるかも
  • Ruby2.3までは数値をあらわすのに3つのクラスで表現
    • 整数はFixnumとBignum => 2.4でIntegerになる
  • Rubyの規格では
    • FixnumとBignumという名前は出てこない
    • ↑二つのクラスは実装
      • 規格には出てこない内容と考えた
  • 2.4からはFixnumの範囲に依存した挙動を当てにしてはいけない
  • Rubyを学習するのが簡単になる
    • FixnumとかBignumという言葉はCommon Lispから来てる
    • 教えることが減る
  • ドキュメントも簡便になる
  • 非互換
    • FixnumやBignumがIntegerを参照する
      • コード中にFixnumなどにアクセスすると、挙動が異なる場合がある
      • 2.3 EOLまでは消すことはない
    • Fixnumのrangeが隠れる
    • MetaprogrammingとDSLが壊れる
      • Sequelとか <= 自業自得だけど……
  • Cレベル
    • 利点が特にないかも
    • 内部表現は変わらない
    • ifdefで2.4以降とそれ以前でかき分けてください
    • 対応して、ライブラリをバージョンアップする場合はマイナーバージョンアップをおすすめ
      • gemの依存関係で悲観的なバージョン指定されている場合、使えなくなる可能性がある

Scalable job queue system built with Docker

  • Takashi Kokubun @k0kubun
  • ジョブキュー
    • 遅いタスクを実行する
    • ジョブを記述してデータストアにいれて、あとで実行
      • resque, sidekiq
  • キューに使うデータストア
  • Worker
    • resque
    • delayed_job
    • shoryuken
  • Barbeque
    • 新しく作った
    • Ruby実装
    • なにがはいってる?
      • Worker
        • serverengine
        • Dockerつかってる
      • webconsole
        • Rails engine
        • RubykaigiではRailsの話はしてはいけない(どっと笑いがおこる)
      • Queueing API
      • コマンド実行
        • 他の言語でも使えるように
  • なんでつくるのか?
    • いままでジョブキューをほとんど使ってこなかった
      • resqueはマルチプロセス
      • kuroko2というすばらしいバッチシステムがあった
        • リッチなwebコンソール
        • Dockerでjobを実行
        • Too muchな感じなのに使ってしまう
      • ジョブキューが必要な場面もあるので作ってしまった
    • workerを集中管理したい
      • アプリケーションがたくさんあるので管理が大変
      • Jobが簡単にデプロイできる
        • Dockerでほとんどのアプリケーションをデプロイ
        • ECSを使用しているので、既存の環境にはいるとオートスケールしてくれる => うれしい
  • 内部
    • キューはAmazon SQS
      • スケールするし、信用できる
      • 制限もある
      • QoS
        • at-leaset onceを選択 => これで困るようなことがないため
    • WorkerはRubyで実装
      • jobを実行するのはコマンド
      • jobを実行するのはhakoを使用
        • Dockerを使用する環境がころころ変わるのでコアに含めると管理が大変
    • RDBへの書き込みはworkerのみ
      • メンテでとまることもあるので、簡単にする
    • AutoScaling GroupでECSクラスターを拡張
      • 足りないときはEC2追加で自動的にスケール
      • いらないときも同様に
  • Dockerイメージを
  • ECSのログとるのめんどくさいけどどうやってるの?
    • ECS上で実行されたログはS3に
    • ECSに実行するログはcloudwatchにあるので、それを見られるアプリをつくってる
  • enqueueとdequeueの形がちがうのは?
    • enqueueは実装を隠蔽したい
    • dequeueはBarbeque workerからしかアクセスしないのでいらないかな?と判断

おまけ

お弁当

開けた

おいしかったです。