技術書展5で、Sinatraのコードリーディング本を頒布します
技術書展5に当選しました
当選してしまったので、技術系の同人誌を書こうと思います。
最近の個人的な活動の成果として、SinatraのDSLっぽくBotが書けるMobbというプロダクトを作っています。そしてその過程で得たSinatraのコードリーディングの知見を広く共有するのが良いだろうと思っているので、同人誌にしようと思います。
たまたま、今日の夕方に会社のイベントでこういう発表をしたのですが、これを更に詳細に掘り下げた本になると思います。
kinoppydさんの「Sinatra trick」 / kinoppyd さん - ニコナレ
スペースはどこ
◎貴サークル「トレイリア学園」は、 い22 に配置されました。
どういう本にするの
Sinatraの全コードの解説を目指します。一冊読めば、自分でSinatraライクのDSLを書けるようになるくらいの本にしたいと思っています。対象読者層は、メタプログラミングRubyを読んだことがあるRubyエンジニアを想定していますが、それではあまりにもリーチが狭い（気がする）ので、メタプログラミングRubyの本を読んでいなくても簡単なエッセンスくらいは理解できる感じに解説を入れようと思っています。
また、現在コミットをしているMobbというBotフレームワークのプロジェクトに関しても、簡単な解説本を書こうと思っています。
追伸：Rubyのサンドボックスを作って、evalするBotを作った
注意：安全じゃないです
あらすじ
-
入力されたRubyのコード文字列を安全にEvalするBotを作ったと主張する
-
次々と安全ではないことがわかる
-
ちょっとずつ安全に向けて改良したが、まだまだ安全じゃない
詳細はここ↓
http://tolarian-academy.net/ruby-sandbox-eval-bot/
たくさん届いた指摘
前回の最後の追伸から一夜明けて、またいくつかの指摘を頂いた。それぞれに関して対策を講じていく。
Rubyのサンドボックスを作って、evalするBotを作った
注意：安全じゃありません
RubyのSnadbox環境
Sansbox環境とは、外部から入力されたプログラムを安全に実行する環境のことです。任意のコードを入力可能な場所で、いきなり system(“rm -rf ~/) とか入力されて、それが本当に実行されたら困りますよね？ 自分は困ります。ですが、外部から入力されたコードを安全に実行する環境というのはそれなりに需要があり、最もわかりやすいところではJavaScriptを実行するブラウザ、わかりにくいところでは今回作ろうとしているeval用のbotです。
ブラウザに関しては、インターネットという非常に治安の悪い場所から送られてくるコードを自分の環境で実行するので、サンドボックスが必要です。同じように、会社のSlackで公開するRubyの任意のコードを実行してくれるBotでも、社内の邪悪な人から投げ込まれたコマンドで自分の環境を破壊されると困るわけです。競技プログラミングの採点サーバーなどで、送られてきたコードを実行するときに邪悪な奴だったら困りますよね？ そういう邪悪なコードから身を守るために、サンドボックスは必要です。
その一方で、Rubyは結構自由すぎる言語で、任意の入力に対する安全なコードの実行というのはなかなか難しいです。Rubyには、汚染マークとセキュリティレベルという、外部からの入力を安全に扱う機構があり、これはメタプログラミングRubyでも紹介されています。詳細はリンク先のページを見てもらえると解りますが、しかしこの機構には一つ大きな問題があり、それは汚染された文字列をevalすることができないということです。そのため、汚染された文字列を自分の手で安全だとマークしない限り、evalの引数に渡して実行することができないのです。それはつまり、セキュリティレベルで保護されている内容と同じレベルの安全性であることを自分で保証しなくてはならないということです。それって、セキュリティレベルを自分でもう一度チェックしなくちゃいけないということなので、ハッキリ言って意味が無いです。
なので、セキュリティレベルに頼ることなく、危険なコードを事前に実行できないように、サンドボックス環境を用意する必要があります。
Ruby製の軽量Botフレームワーク Mobb をリリースしました
TL;DR
Sinatra-isiに記述できるBotフレームワークMobbと、Botとサービスの間を取り持つRackに相当するReppを作って公開しました。
require 'mobb'
on "Hello" do
"Hi!"
end
作ろうと思った理由
RubyでBotを作ろうと思うと、大体の人はRubotyを選択すると思います。GoogleでRubyを使ってSlack Botを作る方法なんかをいくつか探していると、そのうち自然とRubotyに行き着くと思います。ドキュメントやサンプルも日本語で多数用意されており、日本のRuby界隈におけるBotの選択肢としてはデファクトスタンダードではないかと思っています。
Rubotyはとてもよく作られたBotフレームワークですが、個人的にはプラグインのロードにBundlerを使って$LOADPATHから順次プラグインをロードしている点がやや使いづらいと感じていました。公にできない自作プラグインや業務レベルのロジックを乗せるには、それを回避する手順が煩雑になってしまい、Rubotyのロードの仕組みを調べることで本来やりたかったことに使うべき時間を奪われてしまうのが悩ましいところでした。
また、RubotyはHandlerとActionというクラスをきちんと定義しており、その流れに乗っていれば特に迷うことは無いのですが、本当にどうしようもないほどにくだらない機能（例えば、渡された言葉をシャッフルしてechoするだけのしょうもない単機能のbot）しか持っていないbotを作るには、あまりにもリッチ過ぎる制約を持っていました。また、プラグインのロードの都合上、Handlerは自分たちのロジックとは違うモジュール名空間に置かなくてはいけないことも気になる点でした。
この煩雑さを回避したい、毎秒クソボットを作りたいと思うようになると、まるでRailsのようなRubotyの壮大な世界観が少し扱いづらくなってきました。そこで、この悩みを解決するためにSinatraのような手軽さで書けるRuby製Botフレームワークが必要だと感じたために、Mobb プロジェクトを開始しました。
また、世の中には数多のBotフレームワークがありますが、その殆どが自らのコードに特化したサービス接続用のプラグインを持っており、他の世界観で使い回すことができないことも大きな問題だと思いました。これはちょうど、Web ApplicationとWeb Serverの接続部分を解決したRackのようなものがBotの世界にも必要だということであり、Rack（のような）インターフェイスにしたがってBotエンジンを記述すれば、サービスとの接続部分を使いまわせると考えたことが、ReppというBot用の共通のサービス接続インターフェイスを作ろうと思った動機です。
RubyKaigi2018のCFP落ちたので後学のために置いておきます
タイトルの通り、RubyKaigi2018のCFPに送ったプロポーザルがリジェクトされたので、内容を公開して後学のためになればと思い、自らの反省点込で残しておきます。
送った内容
Title
Reading Sinatra to build Sinatra-ish application
Abstract
Reading Sinatra code is the best way to learn how to write minimal daemon program by Ruby. Sinatra was made only of about 2000 lines Ruby code. However, the codes consist of skilled Ruby codes, fundamental metaprogramming techniques, and server programming techniques. In this session, first I will introduce how I made a Sinatra-ish Bot daemon program. After that, I will explain the whole Sinatra code in 40 minutes.
Details
Rubyのライブラリを作成/OSSに貢献するにあたって、Rubyの初心者が次の一歩を踏み出すためのトークをしたいと思います。そのためにまず、有名なライブラリのコードを読むことで、最初の一歩の手助けをしたいと思います。 このトークでは、まず最初に私が作成しているSinatraライクなDSLでBotを作るライブラリを紹介します。 その後、そのライブラリを作成するためにSinatraをどう参考にしたかを解説するため、Sinatraの約2000行のすべてのコードリーディングを40分のセッションの中で目指します。 このトークによって、聴講者はSinatraのコードを読んだという実績と、Ruby製のライブラリへの構造への理解を得て、Rubyによる開発によりいっそう親しめるようになることを期待しています。
Pitch
多くの人がRubyのコードを書くことに親しみ、OSSへの貢献を目指します。 また、Sinatraのコードをまるまる読んだことがある人は意外と少ないと認識しているので、中級者にも新鮮な体験になるのではないかと思っています。
反省点
いくつか思いつくので、箇条書きにします
自分が作ったもののアピールポイントが少ない
Ruby25thイベントで、「RubyKaigiは自分が作ったものを自慢できるような場であればいい」の旨の発言を、どなたがなさっていたのかは失念しましたがされていたように記憶しています。
その中において、私がプロポーザルに書いたメインは「Sinatraのコードリーディング」の部分で、私が書いたBotのフレームワークに関する話はサラッと流れています。この次の反省点とも関連するのですが、Sinatraをメインに置くのではなく、自分のプロダクトをメインに（例えば、私のコードがどのようにSinatraから影響を受けたのかなど）して送るべきでした。
特定のアプリケーションの話をしようとしている
私がRubyKaigiに参加したのは2016年からですが、2回参加しただけでも、RubyKaigiにおける「特定のアプリに関する話はせず、Rubyの話をするべき」という空気は強く感じ取っていました。
その中に置いて、Sinatraという単一のプロダクトに関するコードリーディングをしたいというプロポーザルは、かなり無理筋だったような気がします。
まだ作っている途中のプロダクトに頼ってプロポーザルを送ってしまった
プロポーザルの中に書かれたBotフレームワークは、まだ開発中です。アイディアレベルから、一応動くかな？ くらいの実装までしかまだ完成していないため、コードはGithubのパブリックリポジトリにはプッシュしていません。
そのため、まだどこにもコードが無いプロダクトに対して、レビュアーも評価の下しようがなかったように思います。自分が作ったプロダクトの話をしたいなら、せめてそのプロダクトのコードなりLPなりDocなりをもってこいと言われて然るべきだと思います。
実際、プロポーザルを送ってからも開発を続けていたところ、「これはプロポーザルに書くべきだったな」と思うようなコードやアピールポイントがどんどん見つかっています。まだアルファ版も完成していないプロダクトでのプロポーザルは、無謀でした。
DetailとPitchが日本語
これはそんなに気にしていなかったのですが、過去にCFPを送って通った方のブログを見ると、RubyKaigiは国際カンファレンスなので、すべて英語で送ることが望ましいという旨のことを記している方が多いように思われます。なので、これは手抜きせずにきちんと英語で送るべきだったと思いました。
今後
反省点をだいたいまとめると、「まだ完成も公開もされていないプロダクトの話を、特定のアプリケーションのコードリーディングでごまかすようなプロポーザルを送ったのが失敗」だったと思います。そのため、来年はきちんと完成したものを元にしてプロポーザルを送るべきでしょう。
めげずに来年もCFPに出せるようにがんばるので、がんばります
Gitをバックエンドにしたタスク管理bot
この記事は、ドワンゴ Advent Calendar 2017 の4日目の記事です。
TL; DR
すごい簡単なゆるいタスク管理のバックエンドに、内容アドレスファイルシステムとしてのGit使うのもまあいいんじゃないの？ とおもってGemを作った。
ゆるいタスク管理システムが必要だった
通常、仕事のタスク管理はJIRAとかRedmineとかGithubとかTorelloとかなんかそういう専用のやつを使うと思います。とはいえ、「もう今日は帰ってるけど、明日こののプルリク見てください」とかSlackで伝えたり、「このプルリクレビュー通ってるんで、明日マージしといて」とかSlackで伝えたり、その程度のことをチケットにするのも妙な感じです。デイリーミーティングや口頭やSlackで伝えれば良い気もしますが、まあそういうのって大抵忘れます。そもそも言っても忘れ去られるし。Slackのリマインダも使いづらい。そういう、なんか忘れるけど伝えときたいことを忘れないようにしたいなと思ったら、とりあえずbotを作ります。
botを作ることの理由を問われても、まあなんとなくとしか言いようが無いですが、Slack上のbotだったらまあ大体みんな見てるだろうという程度の理由です。
apt-get upgrade したら、Chromeが物故割れたのでなおした
Chromeがぶっ壊れる
UbuntuのChromeをどういうふうに管理していたのか自分でも忘れていたが、今までは普通にChrome自身のアップデートで、Chromeを再起動するたびに勝手に最新になっていた。しかし、ちょっと必要なパッケージがあり、何も考えず Ubuntu 15.04 vivid 上で apt-get update && apt-get upgrade したら、Chromeが起動しなくなった。
何度起動してもクラッシュするので、シェルから起動してみたところ、次のようなエラーが出て起動しないことが分かった。
[16939:16975:1015/174831.367368:FATAL:nss_util.cc(632)] NSS_VersionCheck("3.26") failed. NSS >= 3.26 is required.
libnss3のバージョンの問題だったので、アップデートをすれば治るかと思ったが、 15.04 ではChromeが必要とするバージョンを入れることができないことが分かった。
https://launchpad.net/ubuntu/vivid/i386/libnss3/
そのため、わけあって 15.04 を使い続けていたが、最新のLTSである 16.04 xenial に入れ替えることにした。
Ubuntuのメジャーバージョンアップは今までやったことがなかったが、 do-release-upgrade というコマンドを使えば、特に難しいこと無くできるらしい。ただし、それは当然ながらサポート期間内のバージョンの話に限る。今回困った15.04は、はるか昔にサポート期限切れになっており、一筋縄では行かなかったので、ブログに書いて忘れないようにしておく。
会社で闇LT大会を開催しました
数週間前の話ですが、勤めている会社で闇LT大会を主催し、なかなかの好評を得たのでみんなもやってみてくださいという情報共有です。
TL;DR 普段とちょっと違うLT大会をやることで、社内の交流の促進に繋がりますよ、という話です。
闇LT大会
闇LT大会の開催要項は、次のとおりです。
ルール1：エンジニアリングの話題を話してはならない ルール2：エンジニアリングの話題を話してはならない ルール3：発表は1人10分/質問時間なし
ガールズ&パンツァー シネマティックコンサートを観てきた
ガルパンのシネマティックコンサート、パシフィコ横浜の回を観て（聴いて？）きました。
とても素晴らしかったので、ブログに書いて忘れないようにしておきます。
劇伴がすべて東京フィルハーモニー交響楽団
ガルパンの映画はもう大体全部覚えるくらい観ていますが、劇伴がすべてオーケストラの生演奏で、今まで観てきたどのガルパンとも違った新しい体験でした。素晴らしい。完璧なテイクを録音したパッケージ版の音もそれはそれで良いけど、ライブで楽器の息遣いが感じられる生演奏による劇伴は、爆音上映やBDとは違った迫力があって、興奮しました。オーケストラの方々の真剣に演奏する緊張感と、指揮の栗田さんのバッキバキな動きが小気味良くて、わくわくです。
シネマティックコンサートではオーケストラの演奏が最重点なので、戦車の駆動音や爆発の音はだいぶ弱めに調整されているのが少し物足りないといえば物足りないけど、メインはオーケストラの演奏を楽しむことだからそれでいいのです。
上映の構成は、大学選抜との試合の直前に各校が参戦してくるまでが前半、20分の休憩を挟んで作戦会議から後半。休憩に入る前のオーケストラ演奏もあって、すごい。
カンテレまで生演奏
劇中でミカがなんかしゃべるたびにポロロンするカンテレも、大洗でよくカンテレを演奏しているあらひろこさんによる生演奏。ミカがなにか言うたびに、舞台上でカンテレを弾いていました。当然、継続高校が大活躍するカール自走砲のシーンでも、ずっと生演奏。最高。
当然エンディングも生歌
EDのPieces of youthも、オーケストラアレンジでchochoさんによる生歌。最高すぎる。大宮公演のときは緊急入院で参加できなかったそうですが、いまは無事退院されて横浜公演では力強い歌を披露してくれました。
アンコールも最高
アンコールでは、ゲストとしてあんこう音頭の女こと佐咲紗花さんが登場して、最終章の前半3作の主題歌を担当することを発表し、オーケストラアレンジしたその主題歌を披露してくれました。
最終章の主題歌は、今までのガルパン主題歌のテイストとは少し違って早い曲調のロックテイストに感じました（今までの主題歌と歌っている人がそもそも違うから違う曲になるのは当たり前だし、そもそもオーケストラアレンジだから、なんとも言いようが無いけれど）。最高に楽しみです。
あと、なぜか最後にオーケストラ伴奏のEnter Enter MISSSONを会場のみんなでカラオケするという謎のイベントがあり、めっちゃ楽しかった。
最後はスタンディングオベーションの割れんばかりの拍手と共にオーケストラを見送り、おしまいでした。
最高
最高のライブイベントでした。最高なくらい最高なイベントでした。
サンキュー、ガルパンおじいさん。
Elixirのパターンマッチ、不変性、型、演算子とwith式
教本は「プログラミングElixir」です
Elixirのパターンマッチ
Elixirでは、変数代入ではなく変数名にパターンマッチを使って値を束縛します。同じ関数型言語のHaskellや、Scalaのvalと同じような感じ。
iex(1)> a = 1
1
iex(2)> [x, y, z] = [7, 8, 9]
'\a\b\t'
iex(3)> x
7
iex(4)> y
8
iex(5)> z
9
iex(6)> z + y + z
26