ローファイ日記

出てくるコード片、ぼくが書いたものは断りがない場合 MIT License としています http://udzura.mit-license.org/

See you, RubyKaigi

Hey Rubyists, did you enjoy RubyKaigi 2019 in Fukuoka? I am @udzura.

RubyKaigiがまずは終わった(残件はある)といいつつ本業も慌ただしく、すぐに 次のプロジェクト に入ってしまった感じでなかなかふりかえりモードになれない(なんならまだふりかえっていないのであった)。いったん今の感想、エモなどをダンプしておこうという記事。

はじめに

どうしてもしなければならない宣伝(©️ id:uzulla さん)があるんですが、Fukuoka.rb で久しぶりにLT大会をするので、RubyKaigiで高まった人、そうでもない人、どなたでも是非 ご登壇ください 。RubyKaigi Teamより、 参加賞 もご提供いただいております。

fukuokarb.connpass.com

もちろん普通のご参加も歓迎です!飛び入りも!

Speaker として

さて。

今回、様々な立場としてRubyKaigiに参加した。もらったパーカもオーガナイザーの青とスピーカーの白の2色を制覇した(一般参加者のオレンジは辞退した)。

まずスピーカーとしては、3回目となるおしゃべりをした。今回はRailsを早く起動する話と見せかけた、実はコンテナの話...。

speakerdeck.com

去年は正直反省点の多いおしゃべりだったけど、今回は書いたコードとやったことの話をベースにできたのは個人的には、良かった。

トークの作り方も新手法を導入していた:

  • 最初に英語でスクリプトを書く
  • それを邦訳する
  • 日本語にしたら明らかに言葉が足りないところがわかるので英語を足す
  • 一通り喋る
  • 時間などもみて言葉を足す
  • 繰り返し
  • 最後にスクリプトをスライドに起こす

この手順を実施したらそれなりに文章も整理され、かつ英語を作るコストを最小限に抑えられたので、今後も(全部日本語の場合含め)採用していきたいやり方であるところ。ただ、今年は結局ネイティブチェックができなかったなあ...。

Grenadine、手すき(いつ?)にドキュメント整理してパッケージ作っときますので試してみてください。今まであまりしたことがないような体験ができます。

github.com

昔日本語で書いた記事です。

udzura.hatenablog.jp

Local Organizer として

今年は実は発表しながらオーガナイザー業もしていた。と言っても、RubyKaigiはトークが一番大事ということで id:jinroq さんをはじめFukuoka.rbメンバーにどんどん投げて行く形にはなった(むしろ、もっと自分から剥がせないといけなかったね...)。

いろいろなことがあり様々で、裏方話でもあるので、詳細はオーガナイザー志望者などにどん蔵、檳榔の夜などのいい感じの店で話す形を取ろうと思う :)

ただ、良かったこととしてはなにより、説明するまでもないFukuoka.rbを代表するRubyist、CRubyのコミットを毎日読んでいることでおなじみ id:nagachika さんをキーノートに迎えることができたことだと思う。世界のRubyistに、nagachikaさんの凄さを伝えられたので、Local Organizerとして一番重要なことはきっとできたのではないか。と。

www.youtube.com

そのほか一つだけ挙げるなら、やはりあのカオス、川端商店街での公式懇親会の話をさせてほしい。

「商店街で懇親会ってどうやるの?」という内容をすでに10名ぐらいに聞かれていてFAQなので、手順をここに残しておくが、商店街のような普通の道路で懇親会をするにはまず、その地域が「国家戦略特別区域」というものに指定されていないといけない。いわゆる川端商店街こと上川端322号線・326号線・327号線もその区域の一つ。

申請を出し、MICE(いわゆる国際会議)を盛り上げるという目的に合致していると当局が判断したら許可が下り、懇親会ができる。MICEなので、規模(700人程度以上とか)、海外のお客様の比率などが判断の材料になるとのこと。RubyKaigiはただの国際会議なのでぴったりではあった。

実際の様子は会場デザイナーさんのFacebookの記事や当日のツイートなどをご覧いただきたい。

www.facebook.com

参加された皆様からも「真っ当な人間には思いつけない」「マジでカオス。クレイジーという言葉がぴったり」などの大好評をいただいていた。

個人的にも、このカオスは福岡でコミュニティをやっていてたまに生じるカオスにとても性質が近く、参加者の皆さんに「えも言われぬ、あの感じin福岡」を少しでも体験していただけたと思うので、良かった。

Attendee として

正直当日は色々気を回すことがあるのと、つい人間の皆さんと会話するのを優先してしまい、なかなか身を入れてトークを聞くことができなかった気もしている。逆に空いた時間に細かくハックスペースに行ってもぞもぞ何かを書いていた記憶もあるけど... 何書いてたっけ... (お茶、最高でしたね。豊橋出身ですが静岡茶より八女茶が好きです)

Pattern matchingOvto の話とか、資料を後から眺めるとちゃんとリアルタイムで聞ければよかったのかな、などと思うけど...。録画を楽しみにするのもまた一興なのかも。

LTはうまいことゆっくり聞けたので楽しめた。VTEPの話がよかった。

github.com

関連イベントのほうは前夜祭からAfter Hackまで色々と参加できた。これは地元開催の便利なところ。地方巡業になってからはAfter Partyは飛行機の関係で行ったことがなかったため、最終日無理を言って参加してしまったが、これも出られてよかった。

そしてAfter Hackは、Fukuoka.rbな感じとRubyKaigiがなんとも言えずに混ざった雰囲気になり、感慨深かった。ちなみにとても豪華メンツによる成果発表は動画に撮っています。

fukuokarb.connpass.com

全体に

今年は今まででぼくが一番RubyKaigiに近づいた年だったのかもしれない。

Rubyistは、それぞれに自分の中のRubyKaigiを持っているような気がしているんだけれど、今年はぼくはローカルなオーガナイザーでもあって、それで結構ワガママというか「udzuraの中でのRubyKaigi」が出て、若干振り回してしまった場面もあったと思うが(すいません...)、それ含め松田さんを始めコアオーガナイザーでうまくまとめていただけたような気がしている。

ローカルなオーガナイザーとしては、RubyKaigi 2019はFukuoka.rbのメンバーのみなさん(論理メンバー含む)がオーガナイザー、ヘルパー、そしてキーノートとトークとLTという感じで色々とコミットメントをしてくださって、とてもエモかった。

何度か言っているけどぼくが2013年に福岡に来た当時は「Rubyって福岡では誰が書いてるんだろう?」と本気で思っていたんだけど、そういうところから、なんやかんやベストフォートでいろいろやって、 福岡Ruby会議02 もやって、RubyKaigi 2019もやれることになった。その間にRubyistの友達がたくさん増えた。

この記事も、今Fukuoka.rbでワイワイした中書いていて、 コミュニティでコードを書いていくって楽しい ということを改めて、強く思うことができた。ぼくは、2011年に初めてRubyコミュニティに行き、 東京Ruby会議05 で「ぼくはRubyを一人で書いてるんじゃない!」 と思ったんだけど、そのことも思い出した。

RubyKaigiに行くと、なんだかたくさん人間がいて、みんなRubyを書いていたり、何かしらRubyのことを考えている。そのことは僕にとってはとても嬉しいことだ。Rubyの話を聞けたし(と言いつつ若干だけど)、Rubyのコードの話をたくさんの人とできた。

とにかく、楽しめたので、よかった(...これは一旦は終わったから言えるのかも)。


来年の松本では、どういう形で参加しているのかはまだわからないけど、きっとRubyistの皆様とお会いできることでしょう... それまでは、 See you!

Grenadine: 「普通のアプリケーション」がチェックポイント/リストアの恩恵を享受する

ここ数日、 Grenadine (グレナデン)と名付けたOSSをやっていっていました。

github.com

Grenadine は、CRIUを用いて、いわゆるコンテナ化をしていないような、VMにデプロイしているようなサーバ型アプリケーション(Webなら、Rails, Django, node.js ...)でもチェックポイント/リストアの恩恵を受けられるようにするためのツールです。

criu.org

今日はこのできたばかりのGrenadineを軽く紹介します。チェックポイント/リストア、と言われてもピンと来ないとは思うので、簡単なデモの手順を示しつつ。

続きを読む

ID Mapping/User Namespace再入門 その(2)

シリーズ2回めです。今回もベースは自分のためのまとめであり、調査不足な点はぜひ突っ込んでください...。

前回:

udzura.hatenablog.jp

今回から、User Namespace の各コンテナでの対応状況を見ていく。

コンテナの非特権に対する対応

前提として、前回のUser Namespaceが解決する課題を再掲する。

主に以下の二つの課題が解決できる。

  • もし特権を付与したコンテナをunjailされた場合等に、ホストのファイルシステムを操作されるなどの被害を最低限にしたい
  • 一般ユーザで、なるべく安全にコンテナを作成したい

前者と後者は、関連してはいるが実現方法が少し異なることは留意すべき。rootless Dockerや一般ユーザでのlxc-startは後者に、LXDによるUser Namespaceの分離は前者に属すると考えられそう。その辺りを踏まえて、各種コンテナランタイムでの対応状況をまとめておく。

Docker (rootless mode)

続きを読む

Rubyでも SO_REUSEPORT 使いたい!

一般に同じアドレスを同じポートではlistenできない。しかし、ソケットのオプションに SO_REUSEPORT というものがあり、Linuxではカーネル3.9以降で利用できる。

ソケットを作成した後に setsockopt(2)SO_REUSEPORT が有効になるように指定すると、同じアドレス・同じポートでのbind/listenが可能になり、リクエストが来た際にはリスンしているソケットそれぞれに回されていく。

ただ、この機能はRubyTCPServerクラス ではすぐには利用できない。 TCPServer#new/open の終了時点でアドレスがリスンされ、setsockoptするタイミングがないため。ではどうするかというと、 Socket クラスでの各メソッド Socket#setsockopt/bind/listen を直接使えば良い。

続きを読む