Elixirのパターンマッチ、不変性、型、演算子とwith式


教本は「プログラミングElixir」です

Elixirのパターンマッチ

Elixirでは、変数代入ではなく変数名にパターンマッチを使って値を束縛します。同じ関数型言語のHaskellや、Scalaのvalと同じような感じ。

束縛した変数と異なるマッチを行うと、例外が飛ぶ

変数aに1を束縛しているので、2とマッチさせようとして例外が飛んでいる。ただ、Haskellとは違って、変数に再度の束縛は可能

なんかユルくない? とおもうけど、まあこういうもんだと思ってスルー。束縛を維持したままマッチに利用するには、pin演算子(^)を利用する。pin演算子を使うことで、変数に値を再度束縛すること無く、束縛されている値とのパターンマッチを行う。

パターンマッチなので、左辺と値が一致してないマッチは例外が飛ぶ。何にでもマッチして値を利用しない記号は、_を使う。

不変性

Elixirは、immutableな値を扱う言語である。データが不変であるので、元の値から新しい値を作る時にコピーを取るが、Elixirは値が不変であることを知っているので、不必要なコピーを作成しないようにしてオーバーヘッドを抑えている。

例えば、リストはhead(配列の先頭要素)とtail(先頭以降の要素のリスト)に分かれていて、既存のリストに対して新しい要素をheadに加えたリストを作る場合は、このように書く。

この時Elixirは、listの値が不変だと知っているので、new_listには新しいhead要素である0を、tailにはlistへの参照を持つリストを作ることで、不要なデータのコピーを避けている。

Elixirにおけるデータの操作は、データの変換と捉えるとわかりやすい。

オブジェクト指向言語を習得した後に  String.capitalize str という式は微妙に感じるし、特に自分はRubyから来たので、 str.capitalize というメソッド呼び出しで元のstrを変更せずに変更した値を戻り値として受け取ることに違和感が無いが、それでもオブジェクトのメッセージ呼び出しは、オブジェクトに対してどんな影響を及ぼすのかが不確定で、プログラマに余計なことを考えさせる余地が多いので、Elixirや他の関数型言語では String.capitalize str のように明確にデータを変換するという書き方が良しとされる。

Elixirの型は、次のようなものがある

  • 値型
    • 任意の大きさの整数(integer)
    • 浮動小数点数(float)
    • アトム(atom)
    • 範囲(range)
    • 正規表現(regular-expression)
  • システム型
    • PIDとポート(port)
    • リファレンス(reference)
  • コレクション型
    • タプル(tuple)
    • リスト(list)
    • マップ(map)
    • バイナリ(binary)

これに加えて関数も型らしいが、教本ではここの一覧に入っていなかったのでとりあえず置いておく。文字列や構造体は、これらの基本的な型から組み立てられるらしいので、ここでは書かれていない。

IntegerとFloat

この2つに関しては、他の言語のそれらとよく似ているので特筆することは無さそう。整数に関しては、最大値というものは無いらしい。

Atom

アトムは、何かの名前を表現する型。説明をざっと読んだ感じ、Rubyのシンボルに近いのではないかと思う。コロンで始まる単語か、Elixirの演算子がアトムに該当する。コロンで始まり、ダブルクォートに囲まれた文字列も、アトムとして解釈される。

Range

start..end で表現される、範囲

Regular-expression

正規表現のリテラルで、~rで始まり、対になるセパレータで囲まれた文字列と、セパレータのあとに付けるオプションから構成される。セパレータは、正規表現の慣習で/が使われることが多いが、エスケープなどの手間で{}を使った方が読みやすい。が、個人的には//で囲まれていれば正規表現という共通認識がかなり強いので、ケースバイケースな気がする。Elixirの正規表現は、Perl5のPCREに準拠している。強い。

PIDとポート

PIDは別プロセスへの参照であり、ポートはIOリソースへの参照。自身のPIDはselfで取得できる。

リファレンス

この教本では扱わないらしい

タプル

順番を持ったコレクション。HaskellとかScalaとかでも出て来る。パターンマッチも利用でき、関数の戻り値として成否とリソースを持ったタプルを返すことがよくあるらしい。

最初の要素が、:okというアトムであるタプルを返す関数の例

リスト

リストは、[]で要素を囲む。Elixirでのリストは配列ではなく、連結データ構造である。不変性の項目で説明したheadとtailという話が関わってくる。先頭から直線的にデータを参照するのに効率的だが、ランダムアクセスに弱い。

リストには、連結演算子++や、差分演算子–、要素が存在するかを確認する演算子inがある。

キーワードリスト

キーと値の対のタプルを持つリスト(マップではない)は多用されるので、シンタックスシュガーが存在する。Rubyとよく似ており、2つの要素を持つタプルの1つ目の要素がアトムである場合は、この2つの式は同じ値を返す。

また、これもRubyと同様に、関数呼び出しの最後の要素がキーワードリストの場合、外側の[]を省略できる

マップ

マップのリテラルは、 %{key => val} で表現される。マップのキーはすべて同じ型であることが推奨されるが、異なっても構わない。ユルい気がするが、まあそういうものなのだろう。

キーがアトムの場合、リストと同じシンタックスシュガーが使える。また、キーには式が使用できる。

マップへのアクセスは[]を使用するが、キーがアトムの場合はドット演算子のシンタックスシュガーが使える。

マップとキーワードリストは非常によく似ているが、マップはキーがユニークであるのに対し、キーワードリストは同じキーを複数持つことが出来る。一般的に、マップは連想配列がほしい時に利用し、キーワードリストは関数やコマンドラインの引数に利用する。

バイナリ

バイナリリテラルは、<<>>で囲む。なんかこのへんはちょっとややこしそうなので、一通り学習してからまた考える。

真偽値

Elixirにおける真偽値は、true, false, nilの3つである。nilは、ブール演算においてはfalseと同じ働きをする。

演算子

演算子はたくさんあるらしいので、教本で取り上げられているものだけを見る

比較演算子

ブール演算子

算術演算子

算術演算子は、+, -, *, /, div, rem がある。
/は浮動小数点数を返し、divは除算の整数値、remは除算のあまりを返す。

連結演算子

in演算子

with式

Elixirのスコープはレキシカルスコープで、幾つかの構造はスコープを生み出す。内包表記で使われるforと、ここで出てくるwithは、それぞれスコープを作る。(forは後ろの章ででてくるらしい)

言語名、公開された年、現在の最新バージョンが書かれた次のようなCSVから、Elixirの項目を取り出す関数は、このように書ける。

実行結果

当たり前だが、外側のスコープのvalueが、withの中のvalueで書き換えられていることはない。with式の中で宣言された変数束縛は、doブロックの中でのみ有効になる。

上のスクリプトの中で、いくつか使われているパターンマッチのどれか一つでも失敗すると、MatchError例外が飛ぶ。例えば、languages.csvのオープンに失敗するとこうなる。

まあこれは良いとして、Elixirのエントリを探すパターンマッチでコケてこの例外が出るのはちょっと違和感があるので、with式の中のパターンマッチでは=の代わりに<-を使うことで、マッチできなかった時にマッチできなかった値を返す。

さっきの関数の、最後のパターンマッチを<-で書き換える。

実行結果は、例外ではなくnilを出力する

これは、Regex.runのマッチが失敗したときの戻り値がnilだかららしい。

また、with式は関数やマクロのような呼び出しらしく、with式と同じ行に式を書くか、もしくは括弧が必要となるらしい。

教本のP34では、doの前ではなくendのあとに閉じ括弧が書いてあったが、多分誤植だと思う。丸写ししたけど動かなかった。withがマクロなので、withの引数としてマッチをとり、それを閉じたあとにdoが続くと考えれば違和感が無い。

次回

4章までおわったので、次は5章からやっていきます。


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

Elixirのインストール


Elixir

Erlang上に実装された、Ruby likeのシンタックスを持つ言語。強力な並行性を持つ関数型言語。

http://elixir-lang.org/

Install to Ubuntu

Unix likeのシステムは、だいたいのディストリに関してインストールガイドが用意されている。意外と、Ubuntuが一番インストールの手順が多くて、なんか微妙な感じがする。

すべてrootで実行したので、 sudoは省いた。

ユーザー領域にインストール出来ないのかな、とは思ったが、面倒なのでとりあえず入れて試したかったので突っ込んだ。

同じページに、rbenvのようなElixirのバージョン管理システムも載っていたが、何故か4つも選択肢があって比較するのに時間がかかりそうなので、一旦無視した。

http://elixir-lang.org/install.html#compiling-with-version-managers

っていうか、全部の解説が 「install and manage different Elixir and Erlang versions」 で、違いがさっぱりわからん。Erlangの扱いあたりに差があるのだろうか?

REPL

ElixierのREPLは、iexというコマンド

最新のバージョンは、1.3。REPLの抜け方は、Ctrl-Cの二回押しが一番早いっぽい。

REPLで便利なコマンドは、hとiらしいので、試してみる。

hはヘルプコマンドで、iexの使い方や、引数に取ったモジュールや関数などの使い方を教えてくれる。iは値の内容を確認するコマンドで、渡された値の型や説明をしてくれる。

ブログ上では分からないが、実際は出力にいい感じに色がついてて見やすい。

iコマンドは、”hoge”と”ほげ”のそれぞれのバイト数や、実際のバイナリ値などを教えてくれて、便利な予感がある。

Version 1.3

教本にしている「プログラミングElixir」は1.2を基準にしているらしいので、何が変わったのかはリリースノートを読む。

http://elixir-lang.org/blog/2016/06/21/elixir-v1-3-0-released/

Elixir v1.3 brings many improvements to the language, the compiler and its tooling, specially Mix (Elixir’s build tool) and ExUnit (Elixir’s test framework). The most notable additions are the new Calendar types, the new cross-reference checker in Mix, and the assertion diffing in ExUnit. We will explore all of them and a couple more enhancements below.

一応、トピックとなるのはCalendarモジュールの追加と、Mixの相互参照チェッカ、ユニットテストのdiffingアサーションの追加っぽい。全文をさらっと読んでみたが、とりあえずコア機能にそこまで破壊的な変更はなく、あとはMixとかのまだ未学習の自分にはよくわからない機能なので、とりあえず気にせず1.3で勉強を始めることにする。

VimでElixir

各種エディタのサポートが、公式で用意されている。全てはドキュメントの右ペインに載っているが、用意されているのは今のところ下記の通り。

  • emacs
  • vim
  • sublime text
  • atom
  • intellij
  • gedit
  • Visual Studio

あとは、バンドル版とかArchemist対応もあるらしい。

vimの場合はこれ。

https://github.com/elixir-lang/vim-elixir

プラグイン管理にはDeinを使っているので、Deinのプラグイン管理部分に次の行を加えてインストールするだけ。

Hello, World!

Elixirファイルには、2つの拡張子がある。.exと、.exsで、それぞれ.exはコンパイルして実行、.exsはスクリプト言語的に実行するものに付けられることが慣習になっているらしい。Hello worldは別にコンパイルする必要がないので、.exsで記述する。

動いた。やったぜ。iexのなかでも、cコマンドを使ってコンパイル実行できるらしい。

動いた。最後の[]は、多分cコマンドの戻り値で、ソースの中にモジュールが含まれていると、ここにモジュール名のリストが入るらしい。

やっていく気持ち

ここまでで、プログラミングElixirの1章がおわった。今年は、Elixirを頑張っていく気持ちです。


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

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


このエントリーは、「ドワンゴ 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個