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
Elixirのインストール
今年買って良かった入力デバイス
このエントリーは、「ドワンゴ Advent Calendar 2016」の19日目です
今年買って良かった入力デバイス
といってもまあ、2つしか無いですが。
今年買ってよかったなぁ、と思った入力デバイスは、バーコードリーダーとErgodoxです。バーコードリーダーはとっても便利で、Ergodoxは生活の質が変わるくらい良いものです。
バーコードリーダー
自宅には、漫画と技術書を始めとする様々な本が2000冊くらいあります。小学生の頃から、基本的に買った本は売ったり捨てたりせずに本棚を増やし続けたので、蔵書の管理とか全然出来てなくて困ってました。それだけでなく、大人になって下手に可処分所得が増えると、本屋の新刊コーナーに行って「あれ、この本買ったっけ」とか思いながら、特に気にせず同じ本を二冊とか三冊買ってしまうこともあります。
加えて、ついに本棚で家が崩壊し始めたので、あまり読み返さない本などはもう売ってしまおうと思ったのですが、売りたい本の量が数百冊に及ぶとネット申し込みで荷物発送しか現実な選択肢が無く、大抵そういう買い取りサービスは売る本の目録を要求してくるので、手でリストを作るのは現実的ではありません。
なので、いい加減何の管理もできていない状態を解消したいと思い、とりあえず全部の蔵書のISBNを集めて、データベース化しようと思いました。少ない量であれば、スマホのバーコードリーダーでもいいのですが、スマホのリーダーアプリはカメラで読み取る性質上連続読み取りにあまり向いてないため、専用のリーダーを買いました
Chaos ConoHa
この記事は、「ConoHa Advent Calendar 2016」の15日目です。
Chaos Monkey
クラウド時代の耐障害性という話題の中で、必ず話題に上がる非常に有名なNetflix製のOSS、Chaos Monkeyというものがあります。いまは、いろいろなツールを詰めあわせてSimian Armyという名前になっているらしいですが、非常に有名でユニークなプロジェクトです。
Chaos Monkey でググるとだいたいどのようなものかはおわかりいただけると思いますが、かいつまんで説明すると、AWS上に構成されているプロダクション環境のEC2インスタンスを、定期的にランダムに落とすというものです。混沌の猿が、AWSのデータセンターの電源でも抜いてるイメージなのでしょう。とにかく、日常的に意図的にマジな障害を発生させることで、普段から耐障害性のあるサービスやインフラストラクチャを構築でき、いざ実際に大規模な障害が発生した時に、何も焦ること無くサービスを復旧させることが出来るという、とても素晴らしい考え方に基づいたものです。
ConoHaのデータセンターでは、おそらく混沌の猿は飼っていないと思いますが（ConoHaのサービスがOpenStackで出来ており、かつSimian ArmyもOpenStackに対応しているので、もしかしたら本当に飼っているかもしれませんが、それは知りません）、ConoHaのデータセンターには座敷わらしが住んでいることで有名です。
はい、そうです。我らがこのはちゃんです。
今そこにあるSlack
この記事は 『Slack Advent Calendar 2016』２日目の記事です。
昨日はru_shalmさんの「Slackで業務チャンネルの平穏を維持するbot、そして人間のトークンをbotに与える話」でした。
Slackで何が起こっているか、知ってますか？
Slackはいつでもそこにいるわけですが、実際に自分が観測しているSlackの世界は意外と限定的です。自分がjoinしているチャネルで何の発言がされて、自分がどんなリアクションを付けられ、またあるいはアットマークを付けて呼び出される、くらいの情報しか通常は知る方法がありません。
しかし、Slackにはあなたの知らないたくさんのチャネルがあり、そのたくさんのチャネルでは沢山の人達が会話を楽しみリアクションを付けたり、また新しいチャネルを作ったりチャネルをアーカイブしたりしています。もしかしたら、新しい絵文字を追加しているかもしれないし、登録した絵文字を消しているかもしれません。自分が所属している組織では、2016年12月2日2時14分現在、2478個のチャネルがあり、4496個の絵文字が登録されています。それに対して、自分が参加しているチャネルは100程度と、知っているSlackの世界はごく限られた一部だけです。