今年買って良かった入力デバイス


このエントリーは、「ドワンゴ Advent Calendar 2016」の19日目です

今年買って良かった入力デバイス

といってもまあ、2つしか無いですが。

今年買ってよかったなぁ、と思った入力デバイスは、バーコードリーダーとErgodoxです。バーコードリーダーはとっても便利で、Ergodoxは生活の質が変わるくらい良いものです。

バーコードリーダー

自宅には、漫画と技術書を始めとする様々な本が2000冊くらいあります。小学生の頃から、基本的に買った本は売ったり捨てたりせずに本棚を増やし続けたので、蔵書の管理とか全然出来てなくて困ってました。それだけでなく、大人になって下手に可処分所得が増えると、本屋の新刊コーナーに行って「あれ、この本買ったっけ」とか思いながら、特に気にせず同じ本を二冊とか三冊買ってしまうこともあります。

加えて、ついに本棚で家が崩壊し始めたので、あまり読み返さない本などはもう売ってしまおうと思ったのですが、売りたい本の量が数百冊に及ぶとネット申し込みで荷物発送しか現実な選択肢が無く、大抵そういう買い取りサービスは売る本の目録を要求してくるので、手でリストを作るのは現実的ではありません。

なので、いい加減何の管理もできていない状態を解消したいと思い、とりあえず全部の蔵書のISBNを集めて、データベース化しようと思いました。少ない量であれば、スマホのバーコードリーダーでもいいのですが、スマホのリーダーアプリはカメラで読み取る性質上連続読み取りにあまり向いてないため、専用のリーダーを買いました

http://amzn.to/2gP78M6

やすかったのでコレにしましたが、読み取りの敏感さはまあ値段相応という感じです。

USB接続できるバーコードリーダーは、基本的にどれもキーボードとして認識されて、読み込んだバーコードの文字列と改行コードを打ち込んでくれます。なので、単純に使う場合はExcelやLibreOfficeのセルにフォーカスを合わせた状態でリーダーでピッピッと読み込んでいきます。

が、家の本棚は色んな所に分散していて(クロゼットの中だったり)、PCから届かない場所にあったりしますし、だからといってノートPCをいちいち持ち歩くのも面倒です。なので、今回は全蔵書のISBNを読み出すために、バーコードリーダーにRaspberryPiを繋げて、Wi-Fi経由で別のマシンに飛ばす方法をとってみます。実は、いま手元にC.H.I.P.という小型Linuxボードがあり、RapberryPiよりも遥かに小さい上にデフォルトでWi-Fiが乗っているので、そっちを使おうかと思いました。が、どうやらこいつよく見ると技適マークがついていないのです。下手に電源入れましたとか公の場所で言うとアレなことになるため、今回は使っていません。

RaspberryPiにWi-Fiドングルの接続をし、設定が終わっている前提で進めていきます。また、たぶんUSBからの給電不足何だと思いますが、リーダーから出る音が凄い変です。変ですが、一応動くので無視して進めます。

img_2022

RaspberryPiにバーコードリーダーを取り付けて読み取れるようにはなりましたが、なんか不便なので、適当なスクリプト書いてWi-FiでSIBNを飛ばすようにします。

標準入力から受け取ったISBNを、ひたすらCURLでローカルのどっかに飛ばすスクリプトです。流石にこのサンプルは簡略化しすぎているので、実際はもうちょっと真面目にClientクラスを実装したり、画面になんか表示したりするわけですが、そこは適宜読み替えてください。

あとはRaspberryPi上でコレを起動しておけば、接続されたバーコードリーダーが読み取ったISBNを、ひたすらローカルのマシンに送りつけます。サーバー側は、超テキトウにこんな感じでしょうか。

これをどっかのマシンで起動しておけば、RaspberryPiからISBNが送られるたびに、お好みの do_something_to_register_isbn メソッドを使って、ActiveRecordなりなんなりでISBNをどこかに保存できます。実際はもうちょっと真面目にエラー処理とか書いてますが、ややこしいのでこんな感じで。

こうして、家中のISBNを集めたので、さて蔵書のISBNのDBは完成しました。ひとまず、いまは全部のISBNから、Amazon Product Advertising APIをいつかって、本のタイトルや著者を取得しています。

ゆくゆくは、これらのデータを読書メーターなどに一括でインポートしようと思いますが、今はなんの蔵書管理サービスを使うか検討中です。場合によっては、自分専用の蔵書管理システムをさくっと作ったほうが自由にできて良いかもしれないと思っているので、これは来年の目標です。

こんな感じに、さくっと簡単にいろんなバーコードを読み込めて、さくっと飛ばせるシステムがあるといろいろ楽です。バーコードリーダーは、本当に買ってよかった入力デバイスです。

Ergodox

Ergodox(リンクはErgodox ex)は、今年特に各地で話題にのぼったキーボードで、パッと検索しただけでもこれだけのエントリが出てきます(検索結果の先頭を拾ってきただけで、実際にはわんさか出てきます)

ErgoDoxを購入して人生がバラ色になった

Ergodox EZ を使ってみよう

はじめてのErgoDox EZ購入ガイド

ErgoDoxはイイぞ

キーボードを新しくした話(ErgoDox)

いずれも今年の初めから夏頃までに書かれたエントリで、どれか一つは目にしたことがあるのではないでしょうか。

また自分でも、あまりの値段の高さ(約三万ちょっと)に購入をためらっていた頃、 ErgoDox users meet up という割と頭のおかしいイベントに出てきて、Ergodoxの魅力を握力王に熱く語ってもらいながら(実際は筋肉の話ばっかりだったけど)購入熱を高めていき、9月に会社の同僚と一緒に共同購入しました。その時の様子がこちらです。

img_1909

Ergodoxを買って使った感想は、これはもう最高です。素晴らしい部分を箇条書きにしてみました。

  • セパレートキーボード。肩に変な力がかからない自然な姿勢でタイピング可能。
  • 小さい
    • ノートの場合、キーボードの間にPCを置けたりするので、普通のキーボードよりフットプリントが小さい
    • キネシスのような他のエルゴノミクスキーボードと違い、本当に持ちあるける
  • カスタム性が高い
    • キー配列の自由な置き換え
    • レイヤーを複数定義して、入力作業中にダイナミックにキーマッピングを入れ替えられる
  • 打ち心地が良いCherry軸
  • 置くときに自由に角度が付けられる(これはErgodox EZの話だけど)
  • 寝ながら使える
    • 普通のキーボードは、寝ながら使うとお腹の上に置くから手が疲れる
    • その点Ergodoxは、横になった時ちょうど腕を置く場所に置けるので自然
    • HMDや座椅子などを使うと、本当に寝ながら作業できる

いろいろと良い点はありますが、やはり最も大きいのは、キーのカスタマイズでしょう。

キーのカスタムに関しては、 ErgoDox EZ カスタマイズ情報のまとめ のエントリがかなり詳細にまとまっていて、参考になります。先述の ErgoDox users meet  up でも、かなりイカれたLTをやっていて印象的だった方です。

私のErgodoxのキーバインドは、今のところこんな感じです

https://github.com/kinoppyd/qmk_firmware/blob/e259498d95b1eaf675e2bbb90c26f20eb535ba21/keyboards/ergodox/keymaps/kinoppyd/keymap.c

キーマップのポイントとしては、次のような感じです

  • よく使うF7F8F10は、レイヤー1に配置
  • Cmdを右下に2つ配置し、違うキーボードを使った時の指の違和感に対応
    • 組み合わせによって、小指で押したり親指で押したりするので
  • 左親指にはSpaceのみを割り当て、BSを誤爆する危険性を排除
  • レイヤー3に、Vimバインドのカーソルキーを割り当て、Hyperを押しながらHJKLすることでカーソル入力
    • Hyperは押してる間だけ有効になる設定
  • レイヤー3にリセットボタンを設置し、細いピンでリセットボタンを押さずともファームの更新が可能に

それ以外は、割と普通の配置です。レイヤー2もデフォのままです。そもそもレイヤー2はめったに使いませんが。

他に、今現在の課題としてこういうものがあるので、順次いい感じにキー配列を変更していこうと思います。

  • 家で使用しているFILCO MINILAは、レイヤー3に移動するHyper的なキーが親指のところにあるので、混乱する
  • [キーと]キーの場所が直感的ではない

いろいろErgodoxを褒めちぎりましたが、問題もあります。Erogoxの問題点は、次の通り

  • 高い。EZは特に高い。
  • デフォルトのキーマップが全くダメ。デフォルトのまま使おうとすると、死ぬ
  • ジグザグにキーが配列されたQWERTYではなく、すべてのキーが縦一直線に並んでいるので、タイピングに使う指が変わる
    • 具体的には、Pのキーの押し方がだいぶ変わった
  • 縦一直線のキー配列にした弊害か、キーが縦一列分少ない
    • つまり、4キー分は、通常のQWERTYとは全く違う場所に置かなくてはいけない
    • 自分の例だと、[,],-,があり得ない場所に置かれている
  • 親指にキーが6個も配列されているが、現実的に考えて2個しか押せない
  • たまーにAltが押しっぱなしになる謎現象に遭遇

とまあ、いろいろと問題があります。特にキーが縦一列分足りないのは結構大きな問題だとは思っていますが、それでもセパレートとキーカスタムできる小さなキーボードの魅力には抗えません。

まとめ

今年買ってよかったものを紹介しました。特にErgodoxはとても良いものなので、みなさんぜひ年末年始の消費の熱に浮かれてポチってみてください。いらなくなったら私が回収するので安心してください。回収は無料です。


カテゴリー: 未分類 | コメント / トラックバック: 0個

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のデータセンターには座敷わらしが住んでいることで有名です。

はい、そうです。我らがこのはちゃんです。

実に悪いことしそうな顔清楚かわいい感じですね。

このはちゃんは座敷わらしだそうです。最近知ったのですが、設定によると我々には見えないらしいので、データセンターで何やってても不思議じゃないですね。うっかり足を引っ掛けてサーバーの電源を引っこ抜いたり、余計なおせっかいを働かせて新しいサーバーを追加してくれたり、使ってないと勘違いし気を利かせてサーバーを削除してくれたり。

なんか、しそうじゃないですか?

Chaos ConoHa

まあ、なんかもう大体想像ついてると思いますが、ConoHaのAPIを使ってなんか悪い事するbotを書きます。

一応言っておきますが、これは去年のACで作ったConoHa APIのGemを全くメンテしてないなぁという気持ちから、とりあえずなんか作ってみるかという感じで作っただけで、一切役に立つ機能はありません。マジでプロダクション用のConoHaアカウントで軽々しく実行したりしないでください。ConoHaちゃんのAPIトークンには権限とかないゆるふわ仕様なので、座敷わらしが一回トークンを知ったら最後、何でもやりたい放題です。

こちらが完成したものになります。

https://github.com/kinoppyd/chaos-conoha

こいつを起動するスクリプトを書いて、後はcronにでも登録すれば、一定周期でChaos ConoHaがなんかします。

した結果をSlackにも通知してくれるようにしたので、なんか悪いことしたら喜んで報告に来てくれるでしょう。

今のところ作っておいた悪いことリストは

  • ランダムで勝手にVMを追加する
  • ランダムで勝手にVMを強制停止する
  • ランダムで勝手にVMを削除する
  • ランダムで勝手にVMを再起動する

なんかこれ以上は怖いのでやめました。

VMの追加に関しては、OSのイメージ名とVMのタイプを指定するのですが、両方一覧からランダムに選びます。

っていうか、VM削除する機能はマジでちょっとどうかとと思います。

はい、それでは実行してみます。

Gemの中に実行形式のファイルがあるので、bundlerを使えばそのまま実行できます

はい、これで上の4つのアクションの内、どれか一つをランダムで実行します。マジでランダムで、本気で停止とか削除しに来るので、本当に気をつけてください。

で、なんどか実行してみました。

screenshot-from-2016-12-15-020405

あああああああああああああああああああああああああああああああああちょ

(フィクションです)

(フィクションですが、消えたサーバーの上で動いているサービスはすべてDokkuで動いているので、いつ消えても大丈夫なImmutableな状態です。なので、新しくVPNを追加して、Dokkuをセットアップすれば、20分くらいで復旧出来ましたよ)


カテゴリー: プログラミング, ポエム | コメント / トラックバック: 0個

今そこにあるSlack


この記事は 『Slack Advent Calendar 2016』2日目の記事です。

昨日はru_shalmさんの「Slackで業務チャンネルの平穏を維持するbot、そして人間のトークンをbotに与える話」でした。

今そこにあるSlack

Slackで何が起こっているか、知ってますか?

Slackはいつでもそこにいるわけですが、実際に自分が観測しているSlackの世界は意外と限定的です。自分がjoinしているチャネルで何の発言がされて、自分がどんなリアクションを付けられ、またあるいはアットマークを付けて呼び出される、くらいの情報しか通常は知る方法がありません。

しかし、Slackにはあなたの知らないたくさんのチャネルがあり、そのたくさんのチャネルでは沢山の人達が会話を楽しみリアクションを付けたり、また新しいチャネルを作ったりチャネルをアーカイブしたりしています。もしかしたら、新しい絵文字を追加しているかもしれないし、登録した絵文字を消しているかもしれません。自分が所属している組織では、2016年12月2日2時14分現在、2478個のチャネルがあり、4496個の絵文字が登録されています。それに対して、自分が参加しているチャネルは100程度と、知っているSlackの世界はごく限られた一部だけです。

数人しか参加していない、規模の小さな Slack team であれば、もしかしたらあなたはSlackの世界で起こっているすべてのことを知っているかもしれません。すべてのチャネルに参加し、すべての発言やリアクションを見ることができます。ですが、誰かが発言し、すぐに削除した発言は見ることが出来るでしょうか? 誰かがこっそり作った(プライベートではない)チャネルの存在を、知ることは出来るでしょうか?

Slackには、クライアントを作成するために用意されている、Slackの世界を知るための方法が用意されています。というよりも、種々の便利なbotを作ろうと思うと、このAPIを避けて通れません。それが、Real Time Messaging APIです。

Real Time Messaging APIから飛んでくる通知を、逐一どこかのチャネルに(どこのチームにもbotの練習をするためのチャネルが必ずいくつかあると思いますが、その中で最も活発なチャネルがオススメです)逐一流すことで、今そこにあるSlackで何が起こっているのかを知ることが出来ます。

わりと簡単に作れると思いますが、一応私が作ったテキトーな実装をご紹介しておきます。

一年以上前からゆるく運用し続けているコードで、使ってるGemが古かったり微妙な実装が多いので、リポジトリにしないでGistにしました。時間があったらちゃんとGemにしますが、今回はちょっとこのコードでお茶を濁させてください。大した規模のコードでもないので、このコードは参考程度にして、ご自分で実装することをオススメします。

slack_watcher.rb

ある日のリアルタイム通知botの様子

screenshot-from-2016-12-02-020908

Caution

このbotをSlackに放つ前に、よく考える必要があります。というのも、このbotは基本的に嫌われます。そしてそのbotをSlackに放ったあなたも嫌われることでしょう。

このbotは、Slackで起こっているありとあらゆることを可視化します。その結果、様々な人から「本当は知られたくなかった」ことを暴かれたとして、厄介者を蔑む目で見られることでしょう。

例えば、仲間内でこっそりと楽しむために作ったチャネルに、どこからやってきたのかわからない人が突然たくさんjoinしてきます。当然このbotの通知を見て興味を持った人が参加したのですが、チャネルを作った本人は、Real Time Messaging API の存在など知らず、一体どうやって新しく作ったばかりのチャネルを補足されたのか、気味悪がることでしょう。個人的にはprivateチャネルでやればいいと思うのですが、どうもIRCのように、クローズではないけど名前を知らないと入れないチャネルを求めている人は想像以上に多いのです。

「どうしてSlackで起こったことをいちいち監視して、あまつさえそれをチャネルに流すのか」と罵られることもあります。とはいえ、このbotで知り得ることは当然公開情報であり、privateチャネルなどで起こっていることは捕捉できません。公開されている情報を可視化したからといって何故責められるいわれがあるのでしょう。とはいえ、そのような正論ぶったことを面と向かって相手に言うと、当然ながらさらなる怒りをかうだけなので、私はよく「公開されている情報をここであえて公開することによって、こっそりと監視するというストーカーみたいなモチベーションを削ぐ効果がある」と、言い訳になっていない言い訳をします。

心の底から本音を言うと、このbotの本当の目的は、圧倒的な権力を持ったアドミニストレーターという特権階級に対して、その力を不用意に乱用することが無いかどうかを監視する、いわば民主主義のような観点のつもりで作ったのですが、実際のところ私が所属している組織のSlackを管理しているアドミニストレーターたちは特に権力を乱用している様子もなく、運用も平和そのものなので、ただ単に私が憎まれるだけの結果になっています。

Real Time Messaging API

Slackで今起こっているたくさんのイベントを、勝手に教え続けてくれるWebSocketのAPIです。Slackのクライアントを作成するには、新しく作られたチャネルや、新しく追加された絵文字、新しくチームに参加したユーザーを常に知っている必要があります。さすがに、すべてのチャネルにポストされた投稿を逐一教えてくれることはありませんが、大抵の情報を教えてくれます。

非常にたくさんのイベントを通知してくれますが、私が特に重宝しているイベントを、アルファベット順に共有します。

bot_added event

https://api.slack.com/events/bot_added

新たにbotが追加された時に通知が来ます。新しいIntegrationが追加された時や、新しいOAuthトークンが発行されたことなども教えてくれます。

誰かが何やらよくわからないOAuthなどを発行した時に真っ先に教えてくれるので、組織内で謎の闇サービスが誕生したことを最初に知ることができます。

channel_archive event / channel_created event / channel_rename event / channel_unarchive event

https://api.slack.com/events/channel_archive

https://api.slack.com/events/channel_created

https://api.slack.com/events/channel_unarchive

https://api.slack.com/events/channel_rename

チャネルに何か変化があった時に通知されます。RTMは、基本的に自分がjoinしていないチャネルに関しても、すべてを教えてくれます。

1日目のru_shalmさんが作っていた蟻地獄botも、このイベントを参照しているはずです。

emoji_changed event

https://api.slack.com/events/emoji_changed

絵文字に何か変化があったときに通知されます。先述のchannel系のイベントと違い、サブタイプがやたらと多く定義されていて、サブタイプによって挙動を変えなくてはいけません。SlackのAPIによくある構造の統一性がちぐはぐなやつで、心がほっこりする気持ちになれます。

reaction_added event / reaction_removed event

https://api.slack.com/events/reaction_added

https://api.slack.com/events/reaction_removed

リアクションが付いたり消えたりした時に来るイベントです。これもチャネルの参加を問わずすべて通知してくれるので、便利です。リアクションが付くということは、何かしら情報量の多いPOSTである可能性が高いので、これを通知するとウケますし、同時に顰蹙をかいます。

ちなみに、starに関するRTMもあるのですが、なんかしらないけどいつの間にか「あ、それあんまり使ってる人居ないから廃止したわ」とか、同僚のSlackBreakers(注:どういうわけか、私の所属している組織では、Slackが好きでたまらない人たちのことを、SlackBreakersと呼ぶ風習があります)はSlack社に言われてたので、現在は使えるかどうかよくわかりません。

team_join event

https://api.slack.com/events/team_join

新たにチームに参加したメンバーが居るときに通知されます。こういのを監視してると、ストーカーと言われます。

ちなみに

RTMは本来Slackクライアントを想定して作られていると思われるので、あまりにたくさんの情報をブロードキャストする上に、その組織に所属する人しか参照することが出来ず、Slack Appを作るには不向きでした。そこで、Events API という、OAuthのスコープで参照を許可させることが出来るAPIも存在します。しかし、自らの所属する組織のイベントを参照するにはやや手順が大げさで面倒なので、Slack Appを真面目に作る以外の用途で利用することは今のところなさそうです。

実装の勘所

勘所というほど大層なものでもないですが、運用していていくつか困る点があったので共有します

Slackは勝手にチャネル名を書き換える

チャネル名が変わった時、フツーに #hogehoge のようにPostすると、変更後にSlackが余計な気を利かせて、過去にさかのぼってすべてのチャネルの表示名を書き換えます。これはチャネルに限ったことではなく、Slackの特殊なMarkdownを使っている場合はたいてい起こるケースです。そのため、チャネル名の変更などを検知するときは、キャッシュに残っていたデータと新たに取得したデータを付きあわせて、Markdownを使わずに記述することで、Slackの余計なお世話を回避することが出来ます。

SlackのWebSocketは突然キレる

どんなサービスでもそうだと思いますが、WebSocketは突然一方的に遮断されるものです。リトライ機構を設けましょう。

APIの結果はできるだけ頑張ってキャッシュする

SlackのAPIは、大きな組織で使っていると正直レスポンスがでかすぎて、色々辛くなる上に重いです。しかし、このbotは基本的に今までSlack上に無かったものが増えたことを教えてくれるので、キャッシュに頼ると死にます。なので、キャッシュコントロールはがんばりましょう。

無限ループに気をつける

これもbotあるあるだと思いますが、自分の発したメッセージに反応して、核分裂でも起こしたかのような急激な無限ループが発生することがあります。今回のGistには入れていませんが、特定のキーワードに反応するときは気をつけましょう。

余談

RTMを使えば、特定の誰かがオンラインになったとかオフラインになったとかもわかります。つまり、誰もが気になるあの人がSlackでオンラインになったりすると、それを教えてくれるbotとかも作れたりします。需要があるかどうかは知りませんが、組織の誰もが知りたい人物のオンライン情報とかがあれば使ってください。

まとめ

まあだいたい、これくらいのイベントを見ていれば、立派にストーカー扱いされますな情報通です。

先に強調したとおり、RTMが教えてくれることは、botのトークンを使う限りはprivate groupなどの秘匿情報を一切含んでおらず、あくまでSlackのチーム全員に公開されている情報なので、非常に有益です。

みなさんもぜひ、今そこにあるSlackをリアルタイムで可視化し、世界を知りましょう。


カテゴリー: Ruby, Slack | コメント / トラックバック: 0個

RubyKaigi 2016 に行ってきました


RubyKaigi 2016

2016 09/08 〜 09/10 の三日間で、RubyKaigiが開催されたので、Ruby大好きなひとりとして参加してきました。

自分がRubyを触り始めたのはここ一年半くらいの話で、前回のRubyKaigiが開催された頃はまだRubyに本格的に染まる前だったので、自分がRubyistとして目覚めて初めてのRubyKaigiでした。

同じく大きなカンファレンスであるYAPCのお祭り感とは違って、ストイックにRubyの話題を中心にしたセッションが大半を占め、更にはCRubyやJRubyの実装にも深く立ち入った話が多く、単純にRubyを書く人だけではなくRubyを作っている人たちの目線を感じることも出来て、普段Rubyのコードを書いている自分から見て新鮮な刺激を感じました。(たまに全然Ruby関係ないよくわからないセッションもあって、それはそれで面白かったです)

今回のRubyKaigiのセッションの中で、ひときわ特徴的だったのは、コンカレンシーに関するセッションの数の多さと、CRubyに関するセッションの数の多さです。全40セッション中、6セッションがメインでコンカレンシーを、5セッションがCRuby(とそのエッセンス)を扱っていました。これは、ここ数年の関数型言語の考え方の流行だったり、マルチコアを活かしきるプログラミングをRuby3に期待している人が多いのだろうといった理由が感じられます。CRubyの話題の多さに関しては、Ruby3に向けてもっとコミッターに興味を持って欲しいという現コミッターたちの意識の表れではないかと思います。

半分は英語のセッションで、同時通訳も無かったので、必死に英語をリスニングして結構頭に効きました。面白いことに、日本語のセッションは英語の同時通訳があり、実に国際的なセッションなのだなということを感じました。

聴いたセッション

一日目

http://rubykaigi.org/2016/schedule/#sep08

  • Ruby3 Typing (Keynote)
  • dRuby in the last century
  • Who reordered my cord?!
  • A proposal of new concurrency model for Ruby 3
  • Isomorphic web programming in Ruby
  • Unifying Fixnum and Bignum into Integer
  • Scalable job queue system build with Docker

二日目

http://rubykaigi.org/2016/schedule/#sep09

  • Fearlessly Refactor Legacy Ruby (Keynote)
  • Writing a Gameboy Emulator in Ruby
  • How DSL work on Ruby
  • Learn Programming Essence from Ruby patches
  • Web Server Concurrency Architecture
  • Pwrake: Distributed Workflow Engine based on Rake
  • Modern Black Mages Fighting in the Real World
  • SciRuby Machine Learning Current Status and Future

三日目

http://rubykaigi.org/2016/schedule/#sep10

  • Ruby committer vs the World
  • Ruby3x3: How are we going to measure 3x?
  • High Tech Seat in mruby
  • It’s More Fun to Compute
  • Optimizing Ruby
  • Game Development + Ruby = Happiness
  • Dive into CRuby (Keynote)

特に凄かったやつ

3日かけて22ものセッションを聴きました。どのセッションも基本的に素晴らしいものでしたが、その中でも特にこれはヤバイなと思ったものを、いくつか感想として残しておきます。

Ruby3 Typing (Keynote)

Matzの基調講演で、Ruby3において型をどのようにして扱うかを、今現在のMatzの頭のなかにあるアイディアレベルで話してました。

Rubyには型がないから、最近新しく力を伸ばし始めた静的型付けの言語に比べて遅れているとよく言われる。しかし、技術というのはトレンドの間を振り子のように行ったり来たりするもので、いまは静的型付けの方に振り子が傾いているが、今後はどうなるかわからないので、Rubyは安易にその波に乗ることはできないと言っていました。これは、Matzのここ最近の講演で常に共通している意見で、YAPCの時N高特別授業の時も同じことを言っていました。

特に印象的だったのは、「絶対に型は書きたくない!」と「絶対にインターフェイスは書きたくない!」という2つの力強い宣言でした。

Rubyのダイナミックな言語仕様が尊重しているのはダックタイピングの概念で、静的型付けやインターフェイスではダックタイピングを壊してしまうため、安易に採用することはできないと、繰り返していました。継承の概念を大事にすると、たとえばIOやStringBufferの関係の様に、同じ挙動をするのに継承関係が無いオブジェクト同士のダックタイピングを阻害するということです。しかしその一方で、Goのように振る舞いを定義するインターフェイスに対してはかなり好意的な立場で、Goのインターフェイスは良くできていると強調していました。また、型推論というアイディアは素晴らしいが、それでも柔軟性を犠牲にするところが多く、何か新しい型の解決方法を考えつかないと、Ruby3に型の概念を入れることは難しく、現状はそのアイディアの実装がないので、Matz自身がプロトタイプを作ってコミュニティに問うていくしかないとのことでした。

dRuby in the last century

いきなりoso-matzとjushi-matzが出てきて、受けとか攻めとか言っててヤバイなこれって感じでした。

そしてdRubyの存在を初めて知りましたが、これは結構実用的で面白いのでは? と感じたので、家に帰っていろいろ触ってみようと思います。

A proposal of new concurrency model for Ruby 3

Guild、というRuby2との互換性を保ちつつ、Ruby3でコンカレンシーを実現するライブラリの提案でした。

アイディアはかなり面白く、Guildという1つのグループの中では今までどおりGVLが働くが、Guildグループは複数持つことができ、他のGuildとの間ではオブジェクトのやり取りに制限がつくという、ForkとThreadの中間(あるいは混ぜあわせ)のあるようなアイディアです。

1つのプロセスは必ず1つのGuildグループをもち、この最低1つは存在しているGuildが、今までのRuby2との互換のために使用される、すなわちRuby2は1つしかGuildグループが作れないGuildと同等ということです。

これがRuby3に採用されるとかなり面白いな、と思いました。

Isomorphic web programming in Ruby

Rubyでバックとフロントの両方のコードを書いてしまおうというアイソモーフィックライブラリ Menilite の紹介&ライブコーディング。

そもそもRubyでIsomorphicしようというスタイルが既にヤバくて面白いだけではなく、非常に完成度の高いライブコーディングのテクニックが披露され、発表そのものがショーのようで素晴らしかったです。

ライブコーディングはだいたいミスって、ミスるところまで含めてライブコーディングの楽しさというところがあるのですが、ゆうちゃんさんは

  • あらかじめ完成したコードをgitで管理しておいて、ライブコーディングの進みに合わせてコミットしておき、いざというときにリカバーする
    • Diffを見せながら解説を加えるので、実際にどういう変更が入ったのかがコミット単位でわかりやすい
  • TODOアプリを作りながら、実際にライブコーディングする内容をTODOする

といった、技術面でも演出面でも舌を巻く完成度で、絶対に真似しようと思いました。

Modern Black Mages Fighting in the Real World

Fluentd 0.14 を支える、黒魔術の話です。

トークが軽妙で面白いのに、扱っている内容が深刻すぎて引きつった笑いが出てしまう。みんな大好き黒魔術! という感じです。

同じ日の2つ前のセッションにHow DSL work on Ruby というセッションがありましたが、それと合わせてRubyの黒魔術の深い部分がよく伝わってくる、この2つのセッションを聞くだけで黒魔術師になれる最高のセッションでした。

Ruby3x3: How are we going to measure 3x?

Ruby3 を3倍の速さにする話ではなく、どうやって3倍の速さを計測するかという話でした。

ベンチマークに関する、体系だった知識を一度に頭に入れるには最適なセッションで、ベンチマーキングを正しく行うということの難しさとその原因をわかりやすく解説していました。

惜しむらくは、セッションが英語というだけで難しかったのですが、スライドが進むのが早く、頭の理解が追いつかないという点でした。このセッションのスライドは、ベンチマーキングを理解する上で非常に役にたつものになると思うので、どこかで公開されることを祈ってます。

It’s More Fun to Compute

Rubyで作曲。ヤバすぎ。国際会館のメインホールがダンスフロアと化した。最高。

Dive into CRuby

CRubyの世界への入り口、というにはちょっと専門的すぎて、さすがコミッターという格の違いを見せつけられたセッション。

主に2つの話題で、Rubyコミッタになるためにはと、CRubyにどうやって貢献するかという話。

新しい機能を提案するときには、ユースケースを正しく理解したうえで提案するべきであること、というのが非常に腹にストンと落ちてくる話で、普段の仕事にも活かせそうだと思いました。

心機能の提案時に、その機能をどのように使うか、そしてその機能の名前は本当に適切なのか、新機能という事象を研ぎ澄ますように精査して、本当に必要な使い方を見出していくという考え方はとても重要だと理解できました。

また、CRubyの世界を旅するときに、大事なことは現象を観測することだということも強調していました。様々なツールを使い、CRubyのメモリやコールスタックがどうなっているのか、解析ツールを使ってどこがボトルネックになっているのか、などを観測することで、Rubyの最適化やバグレポートに繋がると教えてくれました。

Drinkup by Misoca

二日目には、MisocaさんのDrinkupに参加させて頂きました。

途中、Misocaエンジニアに質問タイムがあったので、Rails4から5へのアップデートで苦労したところや、デプロイの戦略に関して質問してみたところ、丁寧に答えていただいてとても楽しかったです。

お料理とお酒、ごちそうさまでした。

RubyKaigi 2016 楽しかった

三日間の日程や、朝が早めであることから、体力的には結構辛かったですが、とても楽しめました。RubyKaigi最高です。

そういえばちなみに、Closingの時に「会社がRubyKaigiの費用出してくれた人ー?」っていう質問があって、ちらほら手が上がっているのを見て、「いま手を上げた人は、 #rubykaigi のハッシュと一緒に会社名をつぶやくと、リクルーティングの役に立つよ」と言っていたのがとてもおもしろかったので、来年は弊社の偉い人に「RubyKaigiのチケットと交通費ください! なんでもしますから!」ってお願いして、弊社の宣伝をドヤ顔でやってやりたいと思いました。

RubyKaigiのスタッフの方々、登壇者の方々、最高の三日間をありがとうございました。


カテゴリー: Ruby, プログラミング, ポエム | コメント / トラックバック: 0個

YAP(achimon)C::Asia Hachioji 2016 mid で、 Slack as a Game platform というLTしてきました


タイトルのとおりです

YAPC::Asiaが去年最終回を迎えて、いつかYAPCで登壇したいなと思っていた夢が終わってから1年。やっぱちーが開催されると聞いて、忙しい時期だけど絶対にLTくらいは出来ると思って応募して、無事採択されたので喋ってきました。

本家YAPC::Asiaに比べるととてもこぢんまりしていましたが、それでも集まった人たちは楽しそうにセッションをしたりそれを聞いていたりして、YAPCってこんな感じだよな、って雰囲気を感じられて楽しかったです。

自社のセミナールーム以外でやるカンファレンスで喋るのは初めてだったので緊張したけれど、ニコナレの録音を聞く限りではまあそこそこうまく喋れていたようなので安心した。

あとで自分のトークを見返せる(聞き返せる?)ニコナレ、素晴らしいサービスですね。

SlackGameのgemの0.2.0をリリースしました

YAPCの他のトラックを聞いている間に、0.2.0をパブリッシュしました。

半年くらい前に、お酒を飲みながらノリで書いたコードは酷いなぁと思いながら、とりあえず変なメソッド名や変数名を修正して、あとはReactionに対応して、リリースしました。

とりあえず、まだ問題点はあるので、近いうちに0.3.0にアップデートになると思います。


カテゴリー: ポエム | コメント / トラックバック: 0個