Slack で簡単かつ公平にくじびきをする
前に書いた「Ruboty でくじびきをする」というエントリの続編です。
何をつくったのか
Slack の slash command を使うことによって、簡単かつ公平にくじびきをできるものをつくりました。
なぜつくったのか
日常にくじびきをしたいシーンは結構あります。
たとえば、issue の assignee を決めるとか、飲み会の予約をする人を決めるとか。弊社でよくあるのだと、ランチのためにご飯を炊く人を選ぶなんていうのもあります。
そういったケースで公平にくじびきできるようにするために、2年ほど前に ruboty-kujibiki という gem を書きました。
この gem は社内の Slack で今も便利に使われていますが、当然ながら「Ruboty がいるところでしか使えない」という問題があり、別の Slack workspace で「くじびきしたい！」となったときに「ここ Ruboty いないじゃん……」となることが結構ありました。
とはいえ、いろんな Slack に Ruboty を入れて回るのは面倒すぎるので絶対にやりたくない。
そこで、Slack App にしてサクッと入れられるようにしました。
使い方
/kujibiki {number} from {comma-separated-elements} でくじびきを行なうことができるようになります。
その他の使い方は /kujibiki help で見ることができます。
インストール
下のボタンをポチッとするとインストールすることができます。
なお、現時点では Slack の審査を通せていないので Slack の App Directory には表示されないですし、認可画面にも「This app hasn’t been reviewed or approved by Slack.」と表示されてしまっています。
どうやって動いているか
全然大したことはしてないんですが、簡単に。
Slack command が実行されると、事前に登録してあるエンドポイントに対して POST リクエストが飛んできます。
このリクエストに対してレスポンスを返すと Slack command の結果として表示されるんですが、今回はこの API を AWS の API Gateway と Lambda (Node.js) で実装しています。
API Gateway と Lambda を選んだ理由は以下のようなものです。
- 複雑なことをしていない
- いかなる状態も持たなくて良い
- サーバー代を払いたくない 💰
今後の課題
自分が使えればいいやという感じでつくっていて細かい処理を全然実装してないので、そのあたりをちゃんとしないといけないのと同時に、せっかくなのでちゃんと Slack の App Directory に登録したいと思っています。
ただ、App Directory 登録のためには審査があり、
- アイコン
- インストール説明用ランディングページ
- プライバシーポリシー
- サポートページ
- サポート用メールアドレス
あたりを用意する必要があります。
いい感じのアイコンとか LP を用意するの厳しいなという気持ちがあり、さらにテキストはすべて英語で用意する必要があって「英語のプライバシーポリシーなんてどうすればいいんや……」と途方に暮れています。
おわりに
Slack でくじびきをするためにつくった slash command について紹介しました。
「使ってみたよ」とか「なんか壊れてる」とかあれば @s_osa_ まで連絡していただければと思います。
もし、「アイコンつくるよ」とか「LP デザインするよ」とか「英語のプライバシーポリシー書けるよ」という神がいたらそちらもよろしくお願いします 🙏
報われてほしい人たちと万人のための Web
ちょっと前からぼんやり考えてることがあるので、そのモヤモヤを整理しようと思ったものの、まだ整理できてないのでモヤモヤしたまま一度書き出してみる。
TL; DR
チラ裏
気になっているもの
最近、note というサービスが気になっている。
description によると、
note（ノート）は、文章、写真、イラスト、音楽、映像などを手軽に投稿できるクリエイターと読者をつなぐサービスです。ブログのように使うことも、SNSのように使うことも、コンテンツを販売することも自在に活用いただけます。
とのことらしい。
自分がよく目にするのは主にブログとしての使われ方なんだけど、作者に対して投げ銭的な支援をできたり有料記事を販売したりという使い方ができる。
そして、有料記事というものに対して少し前からモヤりを感じている。 つまり、誤解を恐れずに言ってしまうと、記事が有料であるというところにひっかかりを感じているのだと思う。
「お金を払いたくない」わけではないはず
なお、自分はコンテンツだったり情報にお金を払うことには比較的抵抗がない人間だと思っている。
物理書籍には昔から課金しまくっているし、Kindle も1600冊以上買っている。 App Store でソフトウェアに課金するのに抵抗はないし、某デジタル配信商品を扱っているサイトでもそこそこお金を使っている。
何かをつくっている人や価値を提供している人は尊重されるべきだと思っているし然るべき対価が支払われてほしいとも思っている。
なのに、note の有料記事に対してはなぜかひっかかりを感じていて、その感覚と上記のスタンスの間に矛盾を感じていた。
「無料の Web」という呪い
そこでいろいろと考えてみると、なんだかんだ言いつつも「Web は無料」という呪縛から逃れられていないのではないかという気がしてくる。
Web を日常的に使うようになったのは中学生のころだったが、その頃 Web に転がっていたものはだいたい無料だった気がする。 Web には楽しい無料コンテンツがいっぱいあったし、無料でいろいろなことを学ぶことができた。
一方、電子書籍は生まれたときから有料だった物理書籍の延長線上にあるし、ソフトウェアはパッケージの、映像はディスクメディアあるいはビデオテープの延長線上にある。 だから、心理的に課金への抵抗感が少ないのではないか。
課金は対価にすぎないのか
じゃあ、課金するいう行為が単に何かを得るためだけの行為かというと、そういうわけでもないのがコトを複雑にする。
たとえば、自分は Mozilla Foundation や Wikimedia Foundation などいくつかの団体に課金してるんだけど、これらの団体に課金したところで自分が得る直接的な利益はたぶんほとんどない。
「無料の Web」という願い
とまあ、いろいろ考えてみると、自分は「誰でもアクセスできる Web」が欲しいだけなんじゃないかという説が浮上してくる。
幸い、今は労働者として日々を過ごしているため収入があり、note にある大半の有料記事くらいならまあ払える。
でも、みんながそうかというとそうじゃないと思っていて、自分も数年前までは学生でそんなに余裕がなかったし、もしかすると数カ月後には失職するなどしてまた余裕がなくなっているかもしれない。
自分が学生だった頃には Web にめちゃくちゃ楽しませてもらったし、いろいろなことを学ばせてもらった。 Web に無料で転がっていた情報のおかげで、今の職業に就けているという自信がある。
だから、情報は可能な限り誰でもアクセスできるようになっていてほしい。
そんな気持ちが note へのモヤモヤの原因なんじゃないかなーというのを、現時点での暫定的な答えとしている。
まあ、こんなエラソーなことを言っておきながら、「やっぱり無料がいい」みたいな気持ちもたぶん存在している気はしていて、それも否定しない。
さいごに
最後になったが、note の有料記事が悪いとか嫌いとかいうつもりは一切ない。
ニッチな領域だったり分量がそれほどでもなかったりして、書籍にするのは難しい知見などが有料記事という仕組みで吸い上げられてくると良いなとも思っている。 それに、note に上がってるのも大半は無料記事だし、他のサービスでは今も無料で情報が提供され続けている。
今回、「何かを生み出している人たちが報われてほしい」という気持ちと「誰でも情報に到達できてほしい」という気持ちがあることに気づいたが、それらのバランスの取り方についてはほとんど何も考えられていないし特にスタンスも持てていない、というのが現在の状況。
むずかしいなー。
URLs are (not) alone
少し前にこんなエントリを書いた。
要約するとこんな感じ。
- URL はリソースを一意に特定するのがプライマリな役割だが、可読性が高くて指し示すリソースの内容がわかると嬉しい
/articles/2018/03/16より/articles/great-articleのほうが良いよねという話
- 一方で、リソースの内容がわかるようにするとキーが意味を持つことになり、変更される可能性がある
/articles/great-articleが/articles/awesome-articleに変更される可能性
リソースの管理が運営主体によって為されている場合はキーの変更リスクもある程度抑えられると思うが、UGC になると表記ゆれなどもあって変更頻度が結構高くなることが考える。
Cool URIs don't change なので URL は変わってほしくない。Web ってのはリンクなんだ。
このあたり、Wikipedia, Weblio, ニコニコ大百科, ピクシブ百科事典なんかは UGC だけど（マルチバイト文字の）タイトルを path に含めていてそれがベストプラクティス感がある。
ただ、やっぱり表記ゆれとかが怖いなーと思っていたら可読性について別の考え方が浮かんだ。
OGP に頼るという選択肢はどうだろう？
現代において、URL が貼られる場所（Twitter, Slack, Facebook, LINE, etc...）ではだいたい OGP を読み込んでタイトルや画像を展開してくれる。
URL が不変性を持ったままリソースの内容を表現できればそれに越したことはないが、内容を表現するために不変性が失われるのであれば URL に意味を乗せることはスパッと諦めて、OGP に意味を乗せれば良いのではないか。
一度この考え方でアプリケーションを作ってみようと思っている。
