そういや転職して3年たちましたので、そのへんと最近の面接担当になったりしてる話

qiita.com

これは転職(その2)Advent Calendar 2016 13日目の記事です。

raydive.hatenablog.jp

そういえば自分が現職に転職してからもうすでに3年たっていることに気がつき、ちょいちょいと過去を振り返っておこうかなと思いまして。

raydive.hatenablog.jp

raydive.hatenablog.jp

なんで転職したか、ということについては過去に書いた記事とか読んでいただければまあわかると思います。基本的に停滞感を感じていたところにいろいろ考えさせられる出来事があり、がらっと環境を変えよう!という気持ちで転職を決意しました。

自分は最終的に自身で見つけた会社に決めましたけど、普通は転職エージェント経由のほうがいろいろ楽ではありますね。いくつかエージェント経由で内定をいただきましたが、後々の内定いただいた会社の動きを見ていると結構よいところに受かっていたのだなぁと思います。*1

現状どうよ?

というわけで3年もたっているのですが、基本的に好きなようにやらせてもらっている気がします。新規も保守もやっているし、なにかしら改善していくことに対して抵抗があるような雰囲気もなく、現状にマッチしていないところは遠慮なく意見を出して解決していく気風があります。あと休みやすい。たびたび土日にライブにいっている自分としては月曜を休みにしてゆっくりできるのは非常にありがたいですね。Tri Castle Storyよかったですし、5th Anniversary Partyも現地いけてよかったなぁ。

閑話休題

さて、最近になってエンジニアの中途採用の面接担当を少しずつ始めました。まだ数名なので数をこなしたわけではないですが。

今のところ自分はこういうところをみているつもりです。

  • 転職回数はあまり気にしていない
  • わりと出身大学の学部とかはみている
    • 前職のとき、数学科出身の先輩がちょー優秀だったので
  • 話が論理だっているか?
    • 基本的に話題をふったときに適切なレスポンスが返ってくるかみてます、たまにこれができない人がいる……
  • githubとかにアカウント持っていれば、コードの規模とか他人が読むことを考えていそうなコードかを見る
    • 規模がでかければ、構成とか頭に描けていそうとか
    • 使っている言語は気にしていない、自分もRubyはここに入るまで使ったことなかったので必要ならできるんじゃないかなと思ってます
  • というかコードさらしてる人は根掘り葉掘り聞いても面白い話が出てくる

書き出してみるとわりとあっさりな感じですね。まーぶっちゃけ仕事するうえで「馬が合いそうか」というのが大前提にあると思っているので、そこらへんをきっちりかぎつけられるかどうかかなーとも思います。はい。

ということで、転職でこの3年間ありがたいことに健やかに暮らせているので、転職してよかったなと思っています。

*1:ちょっともったいなかったか……

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

isucon.net

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

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

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

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

github.com

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

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

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

RubyKaigi 2016 3日目メモ #rubykaigi

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

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

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からしかアクセスしないのでいらないかな?と判断

おまけ

お弁当

開けた

おいしかったです。

Xpath書くなんざ久々である

夜フクロウMac App Store版に入れ替える必要が出てきたため、これまでの設定内容引き継げないかなと調べていたところサンドボックス化にともなってか、若干設定ファイルの内容が違うように見えた。基本的に引き継ぎたいのはタブの抽出情報、しかもアカウント単位の抽出情報のみ欲しかったのでnokogiriでxpathを書いた。

xpath書くとか前職以来なので、書き方忘れてたよ。ぐぐったよ……

夜フクロウのタブ情報をさくっと出力できるようにした

ただこのコードだと、アカウント以外に検索語句なども拾ってきちゃうので改善の余地はあるし、半分寝てる頭で書いたので無駄が多そう。もう寝る。

パーフェクトRuby (PERFECT SERIES 6)

パーフェクトRuby (PERFECT SERIES 6)

パーフェクトRuby

パーフェクトRuby

パーフェクトRubyはいい本なので、初学者などは読むといいよ。

響け!ユーフォニアムサントラのハイレゾがそのままじゃiTunesで扱うのに不便だったのでいろいろしたメモ

追記

flacで買えばメタデータもちゃんとついていたという話を聞いたので、みんなそっちで買いましょう^^

出たねぇ

響け!ユーフォニアムのサントラ、e-onkyoやmoraでハイレゾで配信しているというので、e-onkyoちゃちゃっと買ってみたんですがなかなかですね。TVのOPEDショートバージョンで音圧ががっつり上がっていていつものランティス音源なのにはちょっとふいてしまいましたが、吹奏楽部分や劇中使用BGMはいい感じです。

ただ、iTunesを普段使ってるとハイレゾファイルそのままでは扱いに不便だったので、iTunesで扱いやすいようにいろいろやってみた。いい音で聴きたいときは元ファイル使えばいいしね。

wav => m4a

なにはなくともファイルを変換。ここはAAC 256 kbpsに変換してやります。変換はX Lossless Decoder: Lossless audio decoder for Mac OS Xにおまかせ。

メタデータが何もついてないのでmp4v2で変更する

そのまま登録してみると、メタデータが何もついてないのでアルバム名やトラック番号まで手動でいれなきゃいけないことが判明。そんなの面倒くさいので mp4v2 - MP4v2 Library: This library provides functions to read, create, and modify mp4 files - Google Project HostingCLIからある程度の情報は一括でいれておきます。シェルスクリプトがするっと出てくるほど慣れてないのでとりあえずRubyで書いたのがこちら。

mp4tagsを使って、m4aファイルにタグ付け

とりあえず書いた感が満載ですが、まあこれで目的は達成できたのでOK。あとになってmoraかe-onkyoからArtistデータなりひろってきて突っ込めばよかったと思うなど。*1

あとはアルバムジャケットをiTunesで設定して完了。これで仕事中も別マシンで聴けるようになったので、ユーフォニアム三昧であります。

*1:ところでmoraとe-onkyoでクレジット表記違うんですけど、どっちが正しいんですかね?