risou's Lithograph

2019年の記録

2020-01-03

もう2020年になってしまっているけど、主に備忘目的で2019年の身の回りの出来事を列挙しておく。

といいつつ、実は多くのことが思い出せないので、いろんな資料を漁りつつ……。

健康診断

たいていの場合、健康診断は会社の都合で日程が決まる(と思う)。 2019年は年始休み明け初日に2018年度分の健康診断を行った。 2019年度分は12月だったので、1年間に2回健康診断を受けたことになる。 1月に受けた方ではバリウムを飲んだが、12月に受けた方は胃カメラだった。 意識がある状態での胃カメラは初めてだったが、まあなんとかなった。 食道、胃、十二指腸は特に大きな問題がなかったので良かった。

とはいえ、トータルではB判定で、要経過観察の項目があった(例年通り)。

YAPC::Japan Tokyo

1月に都内で開催されたので行ってきた。 なんか Perl 6 の話をした記憶がある。

そういえば今年も3月に京都で開催されますね。

冬〜春

実は年始最初の3ヶ月くらいの記憶があまりない。 気がついたら4月が終わろうとしていた、という感じ。 ちょうど仕事が忙しく、若干終わりが見えない雰囲気を醸し出していた頃なので、つまりそういうことなのだと思う。

RubyKaigi 2019

最近仕事で Ruby を使っていることもあり、数年ぶり(たぶん6年ぶり)に参加した。 結構内容が高度で、話についていくだけで疲れてしまったりもしたけれど、知り合いがいなかったわけではないので楽しめてよかった。 2020 も参加を画策しているけれど、大事な先約と日程が被りそうなので頼むーという感じ。

GW

このあたりは少し記憶があって、水族館に行ったり VR で遊んだり肉食べたりした。

ボドゲ会

何回かやった(主催した)。何回だっけ……2回、かな。回数としてはかなり少ないので、2020年は10回くらいを目標にやっていきたい。

立ち位置に関する変化

詳細はここには書きづらいのだけど、前年からどっちつかずになっていた現象が解消した。

この件については本人に直接聞いてください。

ながら聴きイヤホンを買った

買ったのは以下のもの。

SBH82D

仕事中、声をかけられることがあればいつでも反応できるように、と買ってその用途で頻繁に利用している。 これはこれで良いものだけど、今度は周囲の音を阻害させてくれる集中したい時用のイヤホンも欲しくなっている。 今だと AirPods Pro が有力(だけど経済的な余裕が足りないのでそのうち……?)。

目の手術

目の手術をした話

光凝固術ってのを受けた。 きっかけは飛蚊症が気になって、だったのでそれは解決していない。 とりあえずその後は定期的に眼科に行くことにした。

builderscon

8月の末、チケットを購入して行ってきた。

builderscon 2019 の記録

これは毎回思っていることなんだけど、めちゃくちゃ楽しい経験だったので次回も参加したい、と思って終わりを迎えた。

ハイジインターフェイスさんは最高!

Lithograph 作った

自分用のブログシステムを作り直したいという動機と Raku でアプリケーションを作りたいという動機がマージされて完成した。 このブログは Lithograph 製です。

isucon9 惨敗

0点ではなかった!(はい)

会社の同僚と一緒に参戦できたのは圧倒的に嬉しい体験だったので、次回は同じメンバーで良い結果を残せると良いなあ(次回あるよね?)。

りんご狩りにいった

お誘いをいただいて行ってきた。住んでいるところからは結構遠かったので、大移動という感じでりんご狩り以外も楽しめた。

その他もろもろ

まあ、書けないことの方が多いし思い出せないことも多いので、ツイートとかをみていただくのが良いです。

僕がこの記事を書く際に参照したのは、

  • Twilog
  • このブログ
  • Facebook
  • scrapbox

あたりです。

流行りのリングフィットアドベンチャーをやっている

2019-12-30

縁あって今月の始めくらいに入手したので、それから週6日くらいのペースでプレイしている。

運動負荷

最初はゲーム内の勧めにしたがって運動負荷21からスタートし、3日目か4日目くらいに30になった。 その後は運動負荷30で続けている。運動負荷は30が最大のようだ。

運動負荷で何が変わるかというと、プレイ中に行うトレーニングごとの回数が変わる。 回数が増えれば当然身体にかかる負荷が増すので、トレーニングしたい身としてはそれは良いことなのだが、同時にプレイ時間が増えてしまうのが難点。

アドバイス

プレイ中に色々なアドバイスをくれる。 そのトレーニングがどの部位や症状に聞くか、定期的に水を飲め、今日はこの辺にしておかないか、など。 ありがたい話だし、水を飲めは言われるまで忘れてしまうので言われる度に飲むようにしているのだが、今日はこの辺にしておかないか、についてはかなり早い段階から聞かれるように感じる。 最初の頃はアドバイスにしたがっていたが、全然負荷が足りない気がして最近は無視している。

運動量

リングフィットアドベンチャーではプレイ時間ではなく実際に身体を動かした時間を計測してくれる。 最近は1プレイにつき30分以上、100kCal消化するようにしている。 それでしんどいかというとそうでもない。個人的には物足りないことが多い。

アドベンチャーモードの難点

トレーニングごとに攻撃力が定められている。 当然、この手のゲームによくあることだが、攻撃力の高いトレーニングはレベルが上がれば解放されるようになっている。 効率厨としては、最短手数(トレーニング回数)で敵を倒したくなってしまうので、つい攻撃力が高いトレーニングを優先してやってしまう。

しかし、このゲームにおいて 攻撃力とトレーニングの負荷は比例しない

つまり、攻撃力基準でトレーニングを選んだ結果、全然しんどくない、ということが起きてしまう。 まあ部位によって現状の筋力も異なる(つまりバランス良く鍛えられている状態ではない)ので、簡単なものとそうでないものがあるのは仕方がない。

個人的にしんどい運動

やはり スクワット系とプランク がしんどい。

ちなみに今(だいたい Lv. 40 ちょい)では攻撃力重視で選んだトレーニングリスト(スキルセット)にはスクワットもプランクもない。つまり今ちょうど全然しんどくないタイミングである。

タイミング的にも年末年始なので、ここはゆっくり負荷の少ないトレーニングを進めて、しんどいトレーニングは年始休みが明けた頃から再開していこうと思う。とりあえずはストーリーを最後まで見ることを目標に進めていく。

ひとつのドメインでプロトコルによって本番環境/テスト環境を切り替える手法はありか

2019-11-27

先日、上記のツイートでアンケートをとった。
実は勤め先の社内でも「これってどうなんですかね」と大半が Web/App エンジニアで構成されている Slack 上のチャネルで質問をした。
ちなみにそのチャネルでは回答率約50%で、全員が「なし」だった。

そもそもなぜこのような問いかけをしたかというと、発端は以下のツイートである。

このツイートを見たとき、「どうしてそんな下手な嘘をつくんだろう」と思った。
嘘だと思ったのは、ひとつのドメインを https と http でそれぞれ本番環境、テスト環境につながるようにしておく、というやり方は明らかに良くない手法だ、と考えたからだ。
そして、このツイートの裏には「本当は隠しておきたい別の事柄があるのではないか」と考えたのだ。

しかし、軽く調べてみると、どうやら本当にそのような設定をしていたタイミングがあったようで、 Google にはテスト環境と思われるページのキャッシュが残っている。
(見た目でテスト環境と容易に判断できるものではなかったが、ページのタイトルが明らかに本番向けではない文字列だった)

となると嘘と判断したのは僕の早計で、これはもしやハンロンの剃刀なのでは、という可能性が思い浮かんだ。
そしてもうひとつ、そもそも「明らかに良くない手法」という僕の判断自体が間違っている可能性も思い浮かんだ。

そこで最初のツイートをした、というわけだ。

僕の周辺にいる人たちの大半はこの手法を良いとは思っていないようだ。

僕自身、改めて自分がなぜ良くないと判断したのかを整理しておく。

想定する状況は以下の通り。

  1. あるドメイン(ここでは example.com とする)を所有している
  2. https://example.com にアクセスしたら、本番環境につながるように設定する
  3. http://example.com にアクセスしたら、 SSL にリダイレクトする
  4. テスト環境で動作を確認したい時のみ、 http://example.com にアクセスしたら、テスト環境につながるように設定する

僕がこのやり方は良くない、と考えるのは以下の点だ。

  • アクセスするタイミングによって http://example.com にアクセスしたときの接続先が異なる
    • 状況を知らない閲覧者に混乱を招く
  • テスト環境に public にアクセスできる
    • テスト環境には社内ネットワークからのみアクセスできるのが望ましい
  • テスト環境が検索エンジンにキャッシュされる
    • noindex なり robots.txt なりでキャッシュされないようにしておく必要がある
      • テスト環境のみ設定が必要になるので noindex などでは本番とコードを同一にできないデメリットがある
      • robots.txt で回避するのが良さそう
      • (ちなみに、これを記載しているのは実際にテスト環境と思われるページのキャッシュが Google に残っているため)
    • そもそもこれも社内ネットワークからしかアクセスできないようにしておけば解決する

ではどうするのが良いか、というと以下のような方法が考えられる。

  • テスト環境用に別ドメインを用意する
  • テスト環境へのアクセスを制限する

当然、これらの方法を取れないケースもある。
たとえば別途ドメインを取得する予算がなかったり、社外の関係者にテスト環境を見てもらうために不特定の IP から接続できる必要があったり。

リスクや回避方法を理解した上で仕方なくこのような手法をとっているのか、何も考えずにやっているのかで内部の状況は大きく異なるように思える。
一方で外からはその違いはわからないし、少々の制約があろうがこれは回避した方が良いリスクだと僕は思う。

とはいえ、僕の考えが正しいという確信を持っているわけでもない。
(やや誇張した表現ではあるが)最初のツイートにあるように、僕はこのあたりの専門家ではない。
個人的には専門家の意見を聞いてみたいが、専門家に問題ないと言われても、僕自身は選択の余地があればリスクを回避と思う。

名前についての考え

2019-11-06

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

前提

僕はもう随分前から、オフラインでもオンラインでも 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 で実装する機会を作っていく必要があるな、と思っているので少しずつチャレンジしていきたい。