blog.risouf.net

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

ボドゲプレイヤーたちへの「のびのびTRPG」の紹介

はじめに

この記事はボドゲ紹介02 Advent Calendar 2016の18日目の記事です。投稿日がおそらく19日になっているかと思いますが、プライベートでゴタゴタしたためであり、閲覧者の端末に何かしらの異常があるわけではありません(遅れてごめんなさい)。

気軽にTRPGを楽しめるカードゲーム「のびのびTRPG」

最初にとってもイカす公式サイトへのリンクを貼っておく。

のびのびTRPG

現代においてはマイナなジャンルと言えなくもない TRPG について簡単に説明をしておく。 TPRG というのは紙と鉛筆、サイコロなど(それに準ずるもの)を使って、ルールブックに書かれたルール(制約)の中で対話しながら進めていく RPG だ。多くの TRPG はルールとともに世界観がある程度描かれており、その世界観の中で「ゲームマスター」が用意したシナリオを進めていく形式をとっている。ゲームマスターはストーリーを用意したり、プレイヤーの動きを(ルールにあわせて)判定する役割のプレイヤーである。他のプレイヤーはゲームマスターの用意したシナリオを進めていくためのキャラクタを用意して、そのキャラクタを動かすことでロールプレイングする。

読んでいて「複雑そうだな」とか「面倒そうだな」という感想を持たれる方も少なくないだろう。 TRPG は楽しいけれど、準備がそれなりに大変だったりするのだ。今回紹介する「のびのびTRPG」は先に説明したような TRPG と違い、初心者でも簡単に楽しむことができる、まさに入門の入門という言葉が似合うゲームとなっている。

やることは簡単、カードを引いて隣のプレイヤーが解決するだけ

「のびのびTRPG」には固定のゲームマスターは存在しない。プレイヤーが順番にゲームマスターの役を交代して行うのだ。ゲームマスターといっても、このゲームにおいては難しい知識などは求められない。山札のカードを1枚引いて、カードの内容によっては成否を判定するだけだ(この判定はゲームマスターの独断と偏見でかまわない)。

ゲームマスターの隣(次)のプレイヤーは、ゲームマスターが山札から引いたカードに書かれている内容を解決する。解決方法には2種類あり、カードに達成すべき数値が書かれていれば、サイコロを転がすだけで良い。そのプレイヤーが担当している(プレイしている)キャラクタのステータスとサイコロを転がして得た数値によって、目標数値に到達したかどうかが決まる。結果は誰が見ても一目瞭然だ。

達成すべき数値が書かれていないカードであれば、プレイヤーは即興でロールプレイをすることになる。たとえば「仲間たちを奮い立たせる」といったことが要求されるので、自分なりにそれを演じてみれば良いのだ。その演技が一般的に良かったかどうかはなんの意味ももたない。ただゲームマスターが OK を出せば成功なのだ(そして NG を出されれば、どんなに良い演技でも失敗となる)。

道中で詰むことはない

実はプレイヤーが成功するか失敗するかは、ゲームクリアにはあまり大きく影響しない。というのは、成功しても失敗しても得るものがあるからだ。成功したら光カードを引き、失敗したら闇カードを引く。どちらが良いということはなく、どちらにも自分たちを強化してくれるカードはあるし、「なんだこれは……」と思うようなカードもある。

ちなみにオンラインマニュアルには、光カードの説明に「いいかんじの特徴がつき、強くなる」と書かれており、闇カードの説明には「おかしな特徴がつき、おもしろくなる」と書かれており、必ずしもプレイヤーたちにマイナスの効果ではないこと(あと作者の説明のふわっとした感じ)が読みとれる。

のびのびTRPGオンラインマニュアル

ロープレは助け合いだ

ゲームマスターと問題を解決しようとしているプレイヤー以外の参加者たちが暇になるということはあまりない。プレイヤーが問題を解決しようとするとき、他のプレイヤーたちは各々のキャラクタのスキルや、それまでの冒険で得た光カード/闇カードを使ってプレイヤーを助けることができる。

それぞれのキャラクタには得手不得手があるし、物語を構築していく上でもキャラクタ同士の絡みは必須といえる。「のびのびTRPG」は非常に簡単化されたゲームシステムながら、 TRPG の楽しみに必要な機能をしっかり持っているのだ。

わかりやすいオチがある

プレイしていくと、最後にはクライマックスと呼ばれるボス戦のようなものがある。クライマックスカードという、最後に起きるイベントが書かれたカードが何枚かあり、その中の1つを引いて、その問題を全員で解決するのだ。クライマックスは皆でサイコロを振って合計を一定の数値以上にすればクリアできる。クリアできるかどうかはダイス運に左右されるが、クリアできなかったとしても物語はちゃんと終わるし特に問題はない。

カードに書かれていないことを妄想しよう

各種カードには様々なイベント、現象が描かれている。とはいえ、それだけでは骨でしかなく、肉付けはプレイヤーたちによって行わなければならない(必須ではないがその方が絶対に面白い)。何かを探す旅をしていたと思ったら、気がついたら借金取りに追われる生活をしていたりする。その間を面白く埋められると、爆笑必至のストーリーができあがったりする。

「のびのびTRPG」は、プレイの結果面白い物語が構築できればその話を肴に旨い酒が飲めるという、プレイ後の飲み会のことまで考えられた素晴らしいゲームなのだ。

2016-12-19 02:15:55.866418 JST

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