risou's Lithograph

名前についての考え

2019-10-16

最近、名前について考える機会があったので、現状での僕自身の名前についての考えを整理しておく。

前提

僕はもう随分前から、オフラインでもオンラインでも risou という名前を使っている。
ここでいう「名前」というのは「戸籍上の名前」やそれに類するものではなく、オフライン(やそれに近しい環境)でのニックネームやオンラインにおける個人を識別するための ID だったりする。

一部の親族を除けばほとんどの人が僕のことを呼ぶときには「りそう」という音を使っている。

表記について

口頭での発音についていえば前述の通り「りそう」なのだが、厳密には「りそー」という音の方が近い人もいれば、さん付けに省略が加わり「りそさん」と呼ぶ人もいる。
いずれにせよ、音はそれで構わないのだけど、テキストでの表記になると少し話が変わってくる。
結構いろんな表記がされていて、どの表記にするのが良いか、と悩んでくださる方も世の中にはいたりする。
表記は主に以下のいずれかになる。

  • risou
  • りそう
    • カタカナのバージョン
    • 末尾が促音のバージョン

僕としては当然どれでもよくて、問題は気づけるかどうかだけなのだけど、一応上記のいずれで表記されても気づけるように可能な限りフィルタしている。
(余談だが、このフィルタは漏れを極力減らしたいために甘く設定されていて、誤検出がとても多い)

ID について

仕事柄、といってよいかどうかはわからないけど、いわゆる “ID” を持つことが少なくない。
たとえば、 GitHub のアカウント、情報共有サービスのアカウント、会社のメールのローカル部、など数えればたくさんのシステムが個人を識別する “ID” を人に付与している。

僕は、自分に付与される ID は可能な限り risou になるように統一している。
統一する理由は簡単で、「あの人はあのサービスでは ◯◯という ID 」というのをいちいち覚えたり思い出したりしなければならないのは非常にコストが高いからだ。

とはいえ、この考えを強制することはできないし、再現するのも難しい。
なぜなら ID は重複を許さないため、先にその ID を使う人がいれば後からそれを奪うことは基本的に不可能だからだ。

それでも、先の理由から ID はなるべく統一されていてほしい。
ついでにいうとアイコンも統一されていることが望ましい。
インターネット上のサービスを活用した仕事をしていると、それらの統一感がない人とのコミュニケーションは一段階難易度があがってしまうからだ。

名前 = ID ?

たとえば会社組織などで働くにあたっての ID は名前、つまり本名ではいけないのか、という話はあるが、これはダメだ。
過去にいくつか破綻した例を見ている。
少なくとも日本語名は意図もたやすく重複する。
いわゆる同姓同名というやつだ。

一方で名前と ID の関連性が全くないと、それはそれで一緒に働く人たちの頭の中でちゃんと紐づくまでに時間がかかる。
とはいえ、名前と関連性のある ID を強制するのは良くない手段で、それは本名とそう変わらない頻度で(あるいはそれ以上に)重複する。

使いやすい ID

「整理する」といいながら、頭の中にあるものをつらつらと書いていたら発散してしまった。
最後に、こういう ID だと取り回しが楽だな、と思う条件を列挙して締めようと思う。

  • 一意性が高い
    • 重複しづらい
  • 発音しやすい
    • オンラインコミュニティでの知り合いと会話する際に混乱が生じづらい
  • 本名、あるいはそれに近しい個人を識別しやすい記号と関連性がある
    • これは必須ではない
    • オフラインで関わりがある人にニックネームとして認識してもらいやすい

ちなみにこの条件に対して僕の ID がどれくらい対応できているかというと、実はそんなにちゃんと対応できていない。
日本語圏では risou は比較的珍しいが、異なる言語圏では珍しくなかったり、一般名詞と音が同じであるために同じ日本語圏内でも重複する可能性がある。


以上が2019年時点での僕の ID や名前(本名ではなくコミュニケーションの場において広く使われるそれ)に対する考え方。
で、おそらくこれは2000年代前半くらいから変わっていない気がしている(当時の記録があるわけではないので定かではないが)。
僕は世代的にちょうどこういう考え方になりやすい変化期を通ってきている気がしているので、僕より若い世代、それこそ平成の後半や令和に生まれた人たちにとってはスタンダードではない可能性が高いと思っている。
これについては、今後も定期的に周囲の意見を聞いて変化をウォッチしたい気持ち。

Qiita:Team の記事を検索するための Alfred Workflow を実装した

2019-10-16

結構前から Alfred というアプリを使っていて、 Spotlight と使い分けたり、それぞれがバージョンを上げるごとに行ったり来たりを繰り返していたのだけれど、最近は Alfred Workflow がやっぱり強いな、ということで Alfred をメインに使っている(ファイルサーチだけなら現時点では Spotlight の方が強い気がしているので、サブで Spotlight も使っている)。

Alfred Workflow とはなんぞや、というと Alfred が備えているアクションを組み合わせて複雑なオペレーションを Alfred の UI で操作できるようにするもので、特に強力なのがアクションとして コードを実行したりプログラムを呼んだり できること。

たとえば自分が便利に使っているところとしては、以下のようなものがある。

上記を見てもらうとわかるけど、いわゆる「記事」に相当するものを検索するのに多用しており、 Qiita や Esa といった情報共有サービスや Dropbox Paper のような閉じたコミュニティ内で使うようなドキュメント共有サービスにある記事を探すのに重宝している。

ただ、上記で紹介している Qiita の Workflow は qiita.com には対応しているけれど、 Qiita:Team には対応しておらず、 Qiita:Team 内の記事を検索したいケースでだけいちいちブラウザにスイッチするのが面倒だった。
ので、自分で作った。

Alfred Workflow for Qiita:Team

Qiita:Team の API は何度か触ったことがあるので、サクッとできた。
Alfred Workflow では直接実行できる言語には限りがあるが、 bash とかを実行できるので実行可能なバイナリが生成できる言語であればだいたい使える。
ということで今回は Rust に挑戦してみた。

risou/qiita-team-alfred-workflow: search articles in Qiita:Team by Alfred Workflow

1日の空き時間を少しずつ使って Rust を学びながら作って、だいたい1週間ほどで作ったので、実装自体も Rust 歴1週間の人が書いたものと思ってもらえると助かる。
つまりこのコードの中にはアンチパターンとかバッドプラクティスとかあったりするかもしれない(あれば Issue を立てるなり Twitter 等で直接でも良いので指摘いただけると喜んで直します)。

Rust 自体には以前から興味があったけれど、こういう機会がなければなかなかチャレンジしないので今回は我ながら良い機会を得られたと思う。
とはいってもまだまだわかっていないことも多く、たとえばテストなども書けていないわけで、学ぶべきことはまだまだたくさんある。
このあたりはこのツールをアップデートしていくだけでなく、他にも Rust で実装する機会を作っていく必要があるな、と思っているので少しずつチャレンジしていきたい。

不定期に集まってボードゲームをしている

2019-09-30

2013年くらいから僕が主催しているボードゲームをするためだけの集まりがある。
主催するといっても、僕がやるのは日程調整と会場の確保だけで、あとは僕がいようがいまいが適当に回っている。
(イベントのタイトルが「 risou さんとボードゲームやれるよ」と言わんばかりの内容なのに僕がいない会があるのはアレだけど)
幸いにも僕の周りには とても たくさんボードゲームを持っている方が4, 5人いて、そういう人たちのおかげで楽に開催できている。

先日、3か月ぶりくらいに開催した。
記録が正しければ32回目の開催で、参加人数は実績値で17人(たぶん)。
一応、プライベートイベントという扱いで、僕の知り合い(および彼らが連れてきてくれる人たち)しか参加できないようにしているので、人数としてはこれくらいで安定している。
過去実績では20人を超えたことが何度かあり、そういうときは会場選定に少し困ったりしていた。

このイベントは参加者の善意によって成り立っていて、ルールらしいルールがほとんどない。
勝手に集まって、勝手に適切な人数に分かれて、勝手にゲームが行われる。
当然ボードゲームをしなくてもよく、僕が終了1時間くらい前に顔を出してボードゲームをせずに会計だけして去ったこともある。

サイコロを拡張するのに楊枝を携帯している様子

僕の知り合いがコアな参加メンバーになるので当然かもしれないが、参加者の年齢層は僕を中心に(正確には中心よりやや上に)±10歳くらいにおさまっている。
が、過去実績で最年少参加者は3歳(当時)でその子は現在は小学生になっている。先日開催時にも来てくれた。

また、時折ボードゲームを作っている人が来てくれたりして、その人の作品をプレイしたり、発表前の作品をテストプレイしたりもしている。

そんな会だが、これまでの一番の課題は会場選定だった。
基本的には貸し会議室等を利用することが多く、代金を会場代として参加者から徴収する形になっていた。
しかし、ボードゲームを買って会場代を支払って、となると経済的な負担も馬鹿にできない。
(参加者は気にしていないかもしれないが主催者は気にしている)

今回、紆余曲折あって僕がお世話になっている会社の会議室を借りて開催することができた。
これまでも企業に会議室を借りる案はないことはなかったが、比較的プライベートなイベントでもあるため、企業にペイできるものがないことがネックだったりしたが、今回はそのような問題もなく(おそらくは)平和的に場所を確保できたように思う。
参加者によって使いやすい会場だったかどうかはこれから確認するつもりだが、問題なければ同じ会場で継続して開催できると精神的な負担は少なくすみそうだと思っている。

高速道路を作っている様子

残る課題は、 皆が持ってきてくれたは良いが数が多すぎて遊びきれていないゲームたちを如何にして遊ぶかスケジュールが連続して合わないと1年くらい(以上)参加できない人がいる ことかなと思っており、今後は開催ペースは少し上げられたら、と思っている。

このイベントに参加してボードゲームをプレイしてみたいと思う良識ある僕の知り合いの方は Twitter の DM や Facebook Messenger あるいは LINE, Slack, Discord 等のプライベートな連絡手段で僕に声をかけてください。

目の手術をした話

2019-09-21

もうしばらく前の話だけど、目の手術をした。
網膜光凝固術というもので、網膜剥離等の症状に対して有効な手術らしい。

どういう経緯でこの手術を受けることになったのか、どんな手術だったのかを記録しておく。


実は前々から眼鏡を作り直すために一度眼科に行こうと思いつつ、急ぎでもないしズルズルと先延ばしにしていた。
あるとき、仕事で長時間連続稼働したときに普段以上に「目の疲れ」を感じることがあった。
そのタイミングで「これは近いうちに眼科に行って目に異常がないか診てもらったほうがよいな」と思った。

なんとか予定を調整して、平日の朝早くに近くの眼科に行って検査してもらった。
順番待ちや検査用の目薬の効果を待つ時間もあり、実際に検査ができたのは昼前だったが、目を見てその場で「網膜に穴が開いている」と言われた。
症状としては網膜裂孔というもので、眼球に衝撃が加わると網膜剥離する可能性があるという説明を受けた。 網膜裂孔と診断した医者はとても軽いノリで、「で、この診察終わるの待って手術する? 夕方もう一度来て手術する?」と聞いてきた。
色々と手術にかかる時間や術後のことなどを確認して、「じゃあ夕方で」となって一旦帰宅した。

夕方まで自宅で仕事を進め、急ぎのものはないという状況まで持っていって再度病院に向かった。
麻酔を含め、点眼薬の効果を待ってから、予定通り手術を受けた。

光凝固術はレーザーによって網膜の対象箇所を焼き切って固める手術らしい。
この手術によって症状が回復するわけではないが、その後の悪化を止めることができるそうだ。
光凝固術は数分で終わり、即日(というか術後わりとすぐに)退院できる。
これらの説明は午前中に受けていたが、実際に手術する準備が整って「さあ、レーザーを照射するぞ」というタイミングで、医者が「そういえば料金の説明をしてなかった」などと言い出した。
僕自身は高額になれば高額医療費制度が使えるし、一時的に手持ちのお金が減ってしまう分にはなんとかなるだろうと気にしていなかったが、まあ雑な医者ではある。
(一方で手術を受けるにあたってサインをしたときに料金を聞いていない僕も僕である)
レーザーを照射する台の前に頭を固定した状態で、だいたいの料金について聞き、その場で了承した。

手術自体は5分前後で終わったと思う。
後から聞いた話では 210 発照射されたらしい。
「痛みはない」みたいな話を聞かされていたが、数発目くらいから脳に直接刺激が来るような痛みがあり、それは最後まで続いた(我慢できないほどではなかった)。
終わった直後は、レーザーを照射された方の目は完全にバグっていて、そちらの目では世界が(特にモニタから発される光が)マゼンダに見えた。
(当たり前というか残念というか、この症状は数分後には完全に落ち着いていた)

その後は普通に料金(高額だったので一部)を支払って帰宅した。
頭痛があったのでその日は最低限やるべきことをやってすぐに寝たが、次の日から普通に出社して仕事ができた。
術後は最大3週間ほど安静にしている必要があり激しい運動等が禁止されたが、つらかったのは「階段を駆け降りる」ことが禁止されたことくらいだった(つい癖でやってしまう)。
その後は術後1週間と3週間のタイミングで検査し問題ないことを確認して、ついでに後日視力を検査してもらって通院を完了した。

Lithograph を育てる

2019-09-20

毎日ブログを書くような性格でもないのだが、前回の記事から今日までの間、隙を見つけては Lithograph を育てていた。
育てるといってもたいしたことはしていない。
(実はバージョンを上げてすらいない)

改善内容は以下。

  • Travis CI での build の実行結果を Slack に通知するサンプルを追加
  • Google Analytics のタグを埋め込めるようにした
  • OGP 用のタグを設定できるようにした
  • build 用のシェルに -eu を設定

だいたいこれくらい。
自分で使っているうちに、「あれもできたらな」と思ったものに対応していっている感じだ。

他にも改善したいことはあるが、これはたぶんすぐにはやらないだろうな、というものもある。
例えば、

  • 初期セットアップ時に生成するリソースファイルのみ更新するコマンドの追加
    • Lithograph 本体側で設定ファイル等に更新があった場合に反映したい
  • config.yml に必要な項目が揃っているかをチェックする機能
    • あると良いかもだけど、今は必須項目もほぼないのでなくてもいいかな
  • 既にファイルのあるディレクトリでの初期セットアップを抑制する機能

あたり。これらはあると便利そうな気がするけど、あんまり頻繁に使われるものではないので実装を急いでいない。

時間さえ見つけられれば(他に優先度の高いものがなければ)やりたいのは主に build 周りの改良で、

  • 「次の記事」「前の記事」へのリンクを付けられるようにする
  • 記事にタグを付けられるようにして、タグでフィルタしたリストページを作る
  • 更新のない記事の build をスキップする

などは後々のことを考えるとやっておきたい。

けれど、他にもやるべきことがあったりするので、これらはまたそのうち時間を見つけて、といった感じ。