blog.risouf.net

buiderscon tokyo 2018 (の記録)

参加した理由

友人からのお誘い。
「会場、家から近いでしょう?」
なるほどたしかに。

サポーターチケット

なんでサポーターチケットにしたのかちょっと記憶が曖昧だけれど、特に後悔はしていない。
ノベルティについては、電子名札はそんなに期待してなくて、サコッシュ良さそう〜という気持ちだった。
けど、会場で実物に触れてみると電子名札が想像以上に良くてワクワクするアイテムだったので、サポーターチケットで正解でしたね。

聞いてきた話

IoT開発の闇

本当に闇だった。
個人的にはこれがベストトークなんだけれど、投票することもできないし、この感情を当日聞けなかった人と共有することもできない。

Electronによるアプリケーション開発事情2018

個人的に共感しまくった話だった。
今年に入って Electron でアプリを作り始めた、というところがタイミング的にバッチリ自分と重なってて、あちこちで「わかる〜」って気持ちになった。
しかし僕と違って、他の人も使うことをちゃんと考えて開発してて偉い……。

パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと

パスワード早く滅びて、と思いつつもそういう世界の実現って大変だろうなあ、と思っていたことを実際に実現しようとしている人たちの話が聞けた。
認証周りは考えることが多いし、慎重に一歩ずつ進んでいってくれてるだけでもありがたい。

JavaCardの世界

うーん、これはなかなか……。
10年前〜20年前を彷彿とさせる話が大量に出てきて、これが2018年の話です、と言われてもにわかには信じがたい、みたいな内容だった。
(自分は当事者ではないので他人事として楽しめたけれど)

遠いようで身近なサウンドエンジニアリング

普段の自分には関わりのない世界の話。
とはいえ、学術的な部分は当然知っていることで、そこから実際に曲として完成させていくまでにどのようなことをやっているのか、自分の知識と現場での現実の結びついてないところが知れてよかった。
自分の仕事に関係なさそうだから他のを優先するつもりだったけど、行って正解だった。

感想

builderscon 、安定感というか安心感がある。
一番緊張せずに参加できるカンファレンスだと思う。 最近、事情があってあまりカンファレンスに行かないようにしていたけれど、行ってみるとやはり楽しいので今度はもっと早い段階から参加を決めて準備できるようにしたい。

2018-09-11 00:28:33.974911 JST

Tweet $B$3$N%(%s%H%j!<$r$O$F$J%V%C%/%^!<%/$KDI2C(B

HHKB を漂白した

3ヶ月ほど前のこと。

諸事情で、押入れにしまっていた HHKB Type-S 白を約2年ぶりに出すことになった。
出してみると、(暗所に保存していたのに)かなり日焼けしており、そのまま使うには抵抗のある状況だった。
これは叙述的な問題で、実際には日焼けしたのではなく黄ばんでいる、といった方が正しいのかもしれない。
(今回、原因とか回避方法とかは調べていない)

漂白前

漂白前

白さを取り戻す方法についてはググるといろいろ出てくるのでここでは手順を詳細に記したりはしない。
簡単に言うと、バラして漂白剤につけて1週間くらい日光(紫外線)に当てると白くなる、という感じ。

漂白後

漂白後

無刻印だったので、バラしてキートップを洗浄したあと、戻すのに若干手間取った。
外側のキーは横幅が違ったり同じだったりするので微妙にややこしいし、内側のキーは列ごとに角度(傾斜)が異なるので、どの列かは容易に判断できるが、そこから先の判断材料がない。
バラす前と全く同じではないけれど、同じ形のものがちゃんと入るように試行錯誤して、動作を確認したところ、問題なく動いたので、これでいいか、という感じになった。

2018-06-24 22:27:34.381084 JST

Tweet $B$3$N%(%s%H%j!<$r$O$F$J%V%C%/%^!<%/$KDI2C(B

Qiita Team Viewer というアプリを作った

インターネットで生きていると、様々なサービスのアカウントが増えて管理が大変になったりすると思います。あるいはアカウント自体は1つだけど紐づくグループが増えるパターンもあります。

たとえば Google アカウント(G Suite アカウント)とか GitHub の organization とか Slack の team とか Qiita:Team とか、仕事してたり OSS 活動してたりするとうっかり増えちゃいますよね。

本題とは一切関係ないけど、僕はこの現象をアカウント・マルティプライズ(account multiplies)と呼んでいます。

複数の所属している Qiita:Team の記事を一覧で見たい

今回は Qiita:Team の話です。紆余曲折あって所属するチームが複数に増えてしまった僕は、わざわざチームごとにブラウザのタブを開いて個別に閲覧することにつらさを感じました。

この手の同一サービス複数アカウントについては、サービスの主旨によって対応が変わるところですが、個人的には Qiita:Team の記事自体は複数のチームのものが混ざって一覧表示されても困らないなと思ったので、そういう使い方ができるアプリを作ることにしました。

Qiita Team Viewer

作ったものはここから落とせます。

Releases · risou/qiita-team-viewer

使い方は簡単で、起動して(Gatekeeper 周りで警告でるかもしれません) Qiita のアカウントでログインしてアプリの連携を許可してもらえば、アカウントに紐づく Qiita:Team の記事の一覧が画面左側に出てきます。記事を選ぶと画面右側に記事の内容およびコメントが表示されます(その他は README をご覧ください)。

Qiita Team Viewer v0.1.0 では以下のことができます。

Qiita Team Viewer v0.1.0 ではできないけど、今後のバージョンで以下のことができるようになる予定です(実装の難易度やアプリの方向性によって変更される可能性があります)。

一方で以下のことは今後もできるようにならない予定です。

これは主に、複数ある Qiita:Team で投稿先のチームを間違える危険を避けるためです。

Qiita Team Viewer の技術選定

ここからは素人がアプリを開発する上で考えたことを記録として残しておこうと思います。

今回アプリを作るにあたって最初に考えたのは、 兼ねてより興味のあった Electron を使ってみよう ということです。
ネイティブアプリがよかったのと、後々 Windows, Linux にも対応したかったということでちょうど良さそうに思いました。 NW.js などの類似の選択肢もありましたが、初めて触るジャンルということもあり現状で一番情報が多そうな Electron にしました。

最初は Electron の簡単なアプリをチュートリアルなどを参考に作り、そのアプリ上で Qiita の API を実行して結果を得るだけのプログラムを書きました。そこから、実際にアプリを作っていく上で必要なことを考えました。

あとは「node module に electron-vue ってのがあるのかー」みたいな雑な感じで使ってみたり。

専門職の人たちからすれば最適には程遠い選択だと思いますが、素人の手遊びとしては思ったより順調に試行錯誤しつつ実装が進み、なんとか現状まで持ってこれました。

新しく触れた技術要素

Electron を使うことを決めた時点で避けられない道だったのですが、ひとつひとつのことを実現するのに新しい技術要素に触れていくことになって新鮮な経験でした。実際に触れた新しいものは以下のとおり。

どれもこれも全然知らないところからはじめて v0.1.0 をリリースするまで約1ヶ月。バッドプラクティスと言われるような使い方をしている箇所もあるかもしれないけど、なんとか使えるレベルまで持ってこれました。わからないこと多すぎてかなり勉強になった気がする(それをいちいち書き留めておく余裕は残念ながらなかったけれど)。

その他感想とか

できればテストも書きたかったけれど、特に仕事を休んだりもせず空いた時間で進めるには、試行錯誤しながら動くものを作るので精一杯でした。まあ、テスト自体は後からでも追加できるのでモチベーションが続けば。

今後はドッグフーディングしつつ、検索機能とか追加していければなあと思ってます。けど、他にもやるべきことがあるので、ここから先はゆっくり進めていこうかと。  あと、今回の開発で(僕みたいな人間にとっての) CSS フレームワークの強力さを思い知ったので、ブログのデザインとかアップデートしていきたいですね。

Qiita Team Viewer を作るにあたって参考にしたサイト

2018-04-16 22:43:19.346896 JST

Tweet $B$3$N%(%s%H%j!<$r$O$F$J%V%C%/%^!<%/$KDI2C(B

GitHub で assign されている Issue の件数を Slack の custom_status に表示する

元ネタというか、インスパイアされたのは以下の記事。

「おまえは今までレビューしたプルリクの数をおぼえているのか?」 - pixiv inside

@kana1 さんの上記の記事では、依頼されているレビューの件数を表示することで、同僚にどれくらい忙しいか(レビュータスクが溜まっているか)を知ってもらって、レビュー依頼が集中しないようにしている。

Slack の custom_status は前々から有効活用できそうだなーと思っていたけど、このアイデアはとても良いものだと思ったので自分に合う形にカスタマイズしてみた。

僕の今の働き方だと、

という感じなので、レビューの数ではなく Issue の数を可視化することにした。

どこでどうやって動かすか

@kana1 さんの用途では、 Slack のチャンネルを監視して custom_status に対して get/set を行っている。
僕の用途ではチャンネルの監視は必要なくて、リアルタイムじゃなくて良いので定期的に Issue の件数を数えてもらえればそれで良い。

さらに、これだけのためにサーバを用意するのとかはとても面倒だったので Google Apps Script で全部やることにした。
GAS では一定時間ごとに実行するトリガーを設定できるため、定期実行は GAS に任せることができる。

GitHub から assigned Issue の件数を取得する

僕は複数の organization に所属していて、それぞれに対応する Slack Team に所属しているので、「ある organization のリポジトリに紐づく assigned Issues の件数を、対応する Slack Team の custom_status に設定」することが目標になる。

GitHub の API では以下の URL で目的の情報が取得できる。

https://api.github.com/orgs/{:org}/issues

特にクエリパラメータを設定しなくても、初期状態で self-assigned かつ open な Issue のリストが取れるためこれで良い。

当然 API を叩くために token が必要。 scope はそんなに広くなくてよくて、 repo だけチェックしておけばよい。

GAS で API を叩く際には UrlFetchApp.fetch を使えば良いらしい(このあたり node.js のモジュールとかそのまま使えないのかな?)。

Slack の custom_status を設定する

assigned Issues の件数がとれたら、件数に合わせて custom_status を設定したい。

基本方針は @kana1 さんのものと同じく10件までは件数を表示して、10件を超えたら溢れている感のある絵文字を表示すれば良さそう。

Slack の API はチームごとに token が取れるので、 GitHub organization に対応するチームの token を用意しておく。
Slack の API はクエリパラメータに token とセットしたい内容を与えてリクエストを送れば良い。
今回のケースでは以下のような URL を叩くことになる。

https://slack.com/api/users.profile.set?token={:token}&profile={:data}

data の部分にはセットしたい値を URL エンコードされた JSON を与える。以下のような形になる。

{
    status_emoji: emoji,
    status_text: text
}

定期的に実行する

GAS はトリガーを設定できる。僕の場合は15分ごとに実行するように設定している。

これだけで15分毎に assigned Issues の件数を Slack の custom_status に設定できる。

2018-04-07 00:13:53.002221 JST

Tweet $B$3$N%(%s%H%j!<$r$O$F$J%V%C%/%^!<%/$KDI2C(B

YAPC::Kansai 2017 Osaka の記録、あるいは最近の YAPC について考えていること

行ってきた。

YAPC::Kansai 2017 Osaka

感想

箇条書きで。

自分のトーク

高速化の初歩 というタイトルで20分枠をいただいて話をしてきた。

トークすることになった経緯

そもそも、話すネタもないしプロポーザルを出すつもりなんて一切なかったのだけど、締め切りが数日後に迫ったある日、 moznion 君に「YAPC 行くんですよね? 僕、キャッシュの話で応募したんですよ。 risou さん何か話さないんすか? Perl 6 とか」みたいなことを言われたのがキッカケ。
(結局 Perl 6 とは全然関係のない内容になったのだけど、今でも Perl 6 ネタを振ってくれる人がいて、嬉し恥ずかし)

まあ枠が埋まらないことはないだろうけど、「応募したけど採択されなかったわー」ってつまらない自尊心を満たしとくかーと思って、ネタを考えて応募した。そしたら、何を間違えたか採択されてしまった。きっと採択されなかったトークの中には、僕が聞きたいトークもあったと思う。

トークの狙い

とはいえ、トークの内容はちゃんと考えていて、今回のトークは「初心者向け」のものとして用意をした(セッションの最初にも念押しした)。僕が初心者向けのトークをするのにはいくつか理由があって、

というのが主な理由。特に重視しているのが1つ目。

YAPC は例年レベルの高いトーク、その時々のトレンドを扱ったトークが多くあり、毎回満足度が高いのだけど、一方で「これからプログラマ/エンジニアになりたい」「最近、技術に興味を持った」人向けのトークってそんなに多くないイメージがある。しかし、おそらくどんな専門技術についても言えることだと思うが、新規参入者への間口は広い方が良い。 YAPC で初心者向けのトークをやるというのは、そういった層にたいして「あなた方もこのカンファレンスのターゲットなんですよ」という意思表示になると思っている。

端的に言えば、学生や現在別業界で仕事をしている人たちをターゲットにしたトークをしたかった。

これにはもう一つ理由があって、あわよくば技術に興味がある将来有望な人を採用したいという気持ちがある。優秀なエンジニアの採用はなかなか難しくて、その一番の理由は母数の少なさにあると思っている。将来の優秀なエンジニアを大切にしていくことは、業界にとっても会社にとってもメリットのあることだと思うので積極的にやっていきたい、という思惑もある。
(そういう意味で Perl 入学式は圧倒的に成果を出している素晴らしい勉強会だ)

そういう狙いでトークを構成したので、同僚や現役のエンジニア、CPAN Author が聞きにくることを一切想定していなかった。

トークの結果

当日、小さい部屋ながらも立ち見がでる程度には聞きにきてくれた方がいて、とても嬉しかった。あのトークで得るものがあったという人が少しでもいれば幸い。

ただ、中には先程書いたように完全に想定対象外の CPAN Author たちがいて、有名な @dankogai さんまで何故か聞きにきてくださっていた。その結果、以下のようなツイートが為されるような展開になってしまった。
(言い換えれば dan さんにトーク中にツッコまれるという実績を解除したとも言える。めでたい?)

risou さん、Dan the interruptionにめげずに頑張っててすごい #yapcjapan #yapcjapanB

— songmu (@songmu) 2017年3月4日

risouさんのDanさん捌きが凄すぎる #yapcjapan

— songmu (@songmu) 2017年3月4日

発表後から懇親会にかけて、僕のトークについて話しかけてくれる人のほとんどが dan さんの話に言及していたので、結局僕のトーク自体に関する感想はほとんど得られず、良かったのか悪かったのか全然わからなかった。

もし誰かの役に立っていたのなら、次回以降も初級レベルのトークを応募していきたい。

最近の YAPC

昨年の北海道から国内で開催されている YAPC については、一昨年までの YAPC とは運営のメンバーが全然違う。そのせいか、結構運営方針の違いみたいなのを感じている。以下に僕が今の YAPC について思っていることを列挙する。

ただの不満みたいになってしまったが、批判する意図もないし改善を要求するつもりもない。たぶん僕みたいに思ってる人はほとんどいなくて(そういう発言をしてる人に会ったことがないので)、僕だけが気にしてることだと思うので、こういうマイノリティがいるっていうことを表明しておきたいだけ。

2017-03-07 01:54:10.132764 JST

Tweet $B$3$N%(%s%H%j!<$r$O$F$J%V%C%/%^!<%/$KDI2C(B