GPG鍵の運用メモ
GPG鍵の有効期限が切れるたびに、オペレーションをググっているのでメモしておく。 基本的に Subkeys - Debian Wiki と同じ。
運用方針
- Master private key には有効期限を設定しない
- 万が一この鍵が漏洩した場合、自身の有効期限を書き換えることができるので意味がない
- その代わり、普段使いのPCにはこの鍵は入れない
- 普段使いのPCには有効期限を1年に設定した subkey を入れておく
- 1年おきに master private key を引っ張りだしてきて、subkey の有効期限を延長する
有効期限の延長
gpg2 --edit-keys 21B5525E224268076E2163F992F2E8C12BF4ADD0 gpg> key 3E52C704B1FD2D0C gpg> expire Key is valid for? (0) 1y
延長した鍵のエクスポート
gpg2 --export-secret-subkeys --armor 21B5525E224268076E2163F992F2E8C12BF4ADD0
良いコードを書くために良いコードを読む
仕事の中で「良いコードを書くためには何をするべきか」について考える機会があった。 今日の自分の答えは「まず良いコードをたくさん読む」というものだったが、せっかくなので少々掘り下げて考察してみたい。
「書く」に対して「読む」はものすごく重要だ。1行を書くために1000行を読んでもいい。
プログラミングの学習を外国語の習得に喩えるならば、「良いコードを読む」ことは「語彙を増やす」ことに相当するだろう。 中学1年生の語彙のみをもって、ネイティブスピーカーのように話すことは不可能なように、基礎的な書き方の知識のみをもって プロフェッショナルのようにコードを書くことは難しいだろう。
（ただし、プログラミングの学習の場合、「真の未知語」が登場しない点で自然言語の学習と異なる。 これはつまり、膨大な試行錯誤を重ねることで熟達することが可能であることを意味する。 この性質があるがために「プログラムを読む」ことの必要性が低く見積もられてしまっている部分もあるかもしれない）
……シャワーの中の考察は不思議なもので、身体を拭いているうちにだいたい忘れてしまう。 いろいろ考えていたような気がするが、もはや一片も思い出せない。
そこで、以下に「良いコードを読むと言っても、良いコードとやらはいったいどこにあるか」について書いてみる。
プログラミングの新しいパラダイムを習得するとき、今の自分がたどるであろう過程について考えてみる。 例えば、いま新しくReactについての知識が何もない状態で、SPAを書き始めるとしたらどうするだろうか。
まずは公式ドキュメントを紐解くだろう。Getting Startedのような項目があればそれに従って開発環境を整えつつ、急がば回れ、まだたくさんのコードは書かない。 各種コンセプトについてよく読む。ドキュメントの序説に登場するソースコードをじっくり読む。 多くの場合、このコードがそのライブラリやパラダイムが理想とするコードであり、基礎とすべきコードだからだ。
書くべきコードについての指針が得られたと感じたら、適当にコードを書き始める。 ここは適当で良い。公式ドキュメントを読んだとしても、最初から最高のコードを書けるほど自分の能力は高くない。 サンプルを適当に変形させつつ、関数を切ってみたり、コンパイラやlinterに怒られたりする。 Rules of Hooks、なるほど、そういうのがあるのか。不思議なルールだ。
動かしかたがある程度分かってきたところで、コードの質について信頼できそうなアプリケーションのコードを眺めてみる。 この頃になると、疑問はある程度明確になっており、読むべき部分のアタリはついているはずだ。 なるほど、こういう単位で Context を切ると後から取り回しやすいのだな、という具合。 （ここで難しいのが「信頼できそうなアプリケーション」を探すことだが、自分の場合はGitHubで公開されている 著名なアプリケーション、それもできれば自分がユーザーとして使ったものをいくつか探してみることにしている。 例えば、Goを使ったAPIサーバーを書きたい時は、ユーザーとしてよく使っているPrometheusのコードを見てみる、という雰囲気）
そして、最後にライブラリそのもののコードも読んでみる。例えば、「カスタムフックは use* という名前でなければならないらしいが、
JavaScriptでそのような制約をどのように実装しているのだろう」というような疑問をとっかかりに、Reactの全体の構造を簡単に把握していく。
広く使われているライブラリのコードはこなれていることが多く、その機能の複雑さに対して驚くほどシンプルに記述されていることが多い(9ただしRailsは例外))。
……というような調子で、次から次へと様々なコードを読んでいるように思う。 小さなライブラリであれば、最初からその全部を読んでしまうこともあるし、必ずしもライブラリの中までしっかり読んでいるわけではない。
例によって抽象的な感じになってしまったが、飽きたので今日はここで終わり。次はもっといいことを書きたい。
2020年を振り返る
1月3日ぐらいに半端に書いて1ヶ月以上放置した原稿を出しちゃうことにする（なぜならもう2月19日だから）。
新生活
大学院の修了と同時に、東京の目黒へと引っ越した。 オフィスへの移動はバイト時代と比べて大幅に楽になったし、24時間営業している飲食店も多くて便利な暮らしとなった。
……という程度しか東京の便利さを享受できていないのが実感。 本当はいろいろなイベントに参加しやすくなったりするなどで地の利を得まくるはずだったのが、Covid-19で外出機会はあまりなかった。かなり残念。
せっかく都心に住んでいるのだから、渋谷・新宿といった街のことをもっとよく知りたい気持ちはある。 これは自分がインドアなことであまり成功していないような気もする。どうなんだ。
そして、学群・大学院時代の6年間を過ごした茨城県つくば市とはいよいよお別れとなった。 初めての一人暮らしを大満喫した土地であり、すっかり愛着のある土地であったが、まだしばらくは大都会にいたいかな。
その大都会の新居には駐車場はなく、月極駐車場もかなり高額なため、5年弱乗り回したインテグラは手放した。 初度登録から17年ぐらい・15万km以上走行しているのに、立派に力強く走り続けてくれたいいやつだった。 手放した理由は、新居に駐車場がなかったり、付近の月極駐車場が高額だったり、みたいなものだが、 そろそろ別の車に乗ってみたいかも、という気持ちもある。とはいえまだ気持ちだけで、具体的な計画はない。
卒業
修士課程はストレートで卒業することができた。めでたい。 「計算機科学を究める」という壮大な目標をもって決断した修士への進学だったが（大誇張）、数歩ほどは近づくことができたかもしれない。
研究そのものはさておき、コンピューターを学問の対象として扱うコミュニティを知ることができたのが大きな収穫のひとつかもしれない。 計算機科学の分野のなかだけでも、研究しつくされていたと勝手にも思っていた領域や、自分が想像もしたことのないような研究があること、 そしてそれらへのアクセスの方法を知ることができたことは素晴らしい経験だった。と言うと格好がつくだろうか。
仕事
アルバイトとして2.5年働いたクックパッドにそのまま就職した。 広告関連の部署に配属されて、クックパッドに表示される広告の配信システムを作ったりしている。
フルタイムで働くようになっての最大の変化はやはり収入面だろう。 4月になってから収入が激増し、金銭的に強い不自由を感じることは激減した。毎月のカードの引き落としに怯えることもなくなった。
うーん特筆したいほど面白いことをやれていない気がする……。来年はがんばりたい。
趣味
これ！ と呼べるものは実はない気がしてきた…… が、多分それは思い出せないだけなので思い出したら書く。書くのか？
Covid-19
2020年を語る上で外すことのできないこの事象だが、別ポストとする。
2021年へ
2020年を総合すると…… 転居・就職で外的な変化は大きかったものの、内的な変化は意外にも少なかった一年、と言えそう。 というのも、仕事の技術的要素は自分のコンフォートゾーンに収まってしまっていそうだし、趣味の技術活動にはさほど時間を割けなかったからだ。 ということで、今年はGUI技術に挑戦したい気持ちがあるかもしれない。わからんけど。 あとはアウトプットが少なすぎる自覚があるので、その辺の気持ちを高めていくか。日本語を書くのも得意になりたい。
あとは、もう少し日常の記録をつけたいかもしれない。ここ数年でも様々な変化はあるはずなのに、 記録をつけていないことでそれを思い出せず、思い出が平坦になってしまっているように感じているから。 ということで、自分の人生（というと大げさか）の記録をいい感じに残せていけるといいな。
おわり
恐れ、または『天気の子』
最近、他人の言葉に押し流されないように必死だ。
感想を言語化するという行為は、他者の言葉に押し流される恐れとの戦いだ。 たまたま見た他者の言葉を自分の感情として発信してしまうのが怖い。そのことに気づかないのはもっと怖い。
他者の言葉を自己の感情だと勘違いしてしまうぐらいならば、いっそのこと口を噤んでいたほうがマシだという気持ちすらある。 あるいは「良かった」と言う一言にすべてを凝縮したつもりになって満足し、意味のないこの4文字をTwitterに流して忘れ去るのもそういった恐れに対する防衛機制の一種なのかもしれない。
いつまでもそれを繰り返したくはない。マルコフ連鎖と同等の知性には落ちたくない。 この恐れこそが、他者の言葉に押し流されまいとさせるのだろう。
『天気の子』は、そんな恐怖が大きい作品だった。 公開直後、多くの人が Twitter で「ゼロ年代のセカイ系を彷彿させる」「これこそ新海誠だ」との感想をたびたび見た。 己もこれら言葉に染まってしまうのではないか、そういう恐れである。
恐れは、言語化によって対峙できる。 今回の場合は、"自分が「セカイ系」や「新海誠」に特別な思い入れがなく、むしろそれらをよく知らない" という自覚によるものだと整理できた。 Wikipedia やニコニコ大百科の「セカイ系」のページを見ると、その定義や作品例がずらりと並んでいる。 その中には自分がよく知っているものもいくつかある。 しかし、そのいくつかの作品を同一のジャンルとして捉えたことはなく、「セカイ系」の概念は己の中で内面化されていない。
こんな自分が、うっかり「『天気の子』、完全にゼロ年代のエロゲのトゥルーエンドルートだった」なんて口走ってみようものなら、それは完全に自己を捨て、他者の言葉で飾ってみせようとする姿そのものだ。 それは避けたい。死んでも嫌だ。そうは言いつつも、第二の恐れが顔をのぞかせる。
それは、「知らないことを認める」ことを極端に怖がる気持ちだ。 知らないことについて、知らないことを認めるぐらいならば、その場でインターネットでパッと調べて、あるいは調べなくても少しばかり分かっているふりをする。 そんな欺瞞を繰り返してきた。
この「知らないことを認めたくない」第二の恐れは、第一の恐れとの天秤の関係にある。 『天気の子』の例で言えば、とりあえず知ったかぶって「完全にエロゲーのトゥルーエンドだった、新海誠やってくれたな……」と言うことだってできる。 そうすることによって、「知らないことを認める」恐怖からは逃れることができる。
それではいけない。 知らないことは知らないと認めなくてはならない。
だから、今日は他者の言葉を借りるのではなく、己が素直に感じたことを書いてみようと思う。
『天気の子』を見た時もっとも感じたのは、「東京へのコンプレックス」だ。
横浜生まれ・横浜育ち、実家は横浜の中心部まで10分もかからない、という環境で育った自分は、横浜に誇りを持っている。 心の底から最高の都市だと思っている。「横浜なんて実はだいたい山だよ」なんて、言わせたいやつには言わせとけばいい。 選民思想と揶揄されようとも、自己紹介するときに「横浜の人って絶対神奈川出身って言わないよね」と言われようとも、この気持ちは本物だ。
『天気の子』は、東京を舞台とした作品だ。新海誠の手によって東京の中心部は極めて詳細に描かれる。 ドコモタワーを頂上とした新宿、丁寧に描かれた田端駅。 10代の彼らが見る東京を、見事に描き出している。
いや、本当にそうだろうか？ 俺は「分からない」。この映画の中で描き出されている東京が、現実のそれとどれほど同期しているのか。判断がつかない。 なぜか？ それは俺が中高の時代を東京ではなく、横浜で過ごしたからだ。 東京…… いや、"東京" とはなんだろうか？ 距離にすれば25kmもない場所でで10代を過ごしておきながら、やはりそれでも東京のことは分からない。 渋谷や新宿に通う中高時代だったら違ったかもしれない。俺はそうではなかった。一番詳しいのは横浜西口五番街のことだ。
横浜は大好きだ。横浜は大好きだが、東京も大好きだ。首都高、東京タワー、丸の内。すべてが調和することなく、それぞれの美しさを誇っている。 数え切れないほど夜通し首都高でドライブしているし、夜闇にまばゆく光る東京タワーに何度も見とれている。 それでも、東京のことを知っているという自信はまったくない。
東京でバイトをはじめてもう5年になる。秋葉原、渋谷、恵比寿で働いた。新宿だって多少は分かる。いや、それさえも強がりだろうか？ 大ガードが何度も描き出されるのを見て、親近感を覚えたつもりになったかもしれない。 しかし、物語の重要な舞台である代々木や池袋、田端については、本当に何も分からない。多分下りたこともない。池袋にラブホ街なんてあったんだ。
東京で『天気の子』を見た多くの人も、そうなのかもしれない。 だが…… だが、俺は知りたい。東京について、もっと知りたい。 『天気の子』を、見たことがあるかもしれない風景の集合ではなく、身近なところで起きた物語として見たい。 帆高が東京を駆け抜ける時。夏美のバイクで逃走劇を繰り広げる時。 「東京のことを、俺は結局何も知らない」という気持ちが刺激された映画であった。
来年からはいよいよ東京に引っ越す予定だ。 仮に1年後の俺が『天気の子』を見たとしたら、何を感じるだろうか？ まだ東京のことなんて何も分かっていないだろうか？ あるいは、まるで地元の出来事のように感じるだろうか？ それはまだ、分からない。
ISUCON 9: チーム「ソレイユ」の5年目、はじめての予選通過
ISUCON 9 予選にチーム「ソレイユ」 (@osyoyu, @KOBA789, @s4ichi) で参加し、28位で予選初突破を果たしました。 このメンバーで ISUCON 5 から予選への挑戦を続けていて、参加5回目にしてようやく本選への切符を手にした形です。
4度も予選敗退を繰り返しているうちに、ISUCON の本選に出場したいという気持ちは強くなるばかり。 時間の経過とともにメンバーのそれぞれが日常で取り組んでいる課題や業務の領域が ISUCON で扱われるそれに近づいているのにもかかわらず、思うような成績を残せないことに対する焦りを感じることもありました (ISUCON 7: 42位, ISUCON 8: 45位) 。 我々にとっては予選こそが ISUCON であるという状況は長く、本選は手の届かない夢の舞台、という感じです。 文章にしちゃうとちょっと格好悪いね。
そんなわけで、チームとして初めて予選を突破できたのは、大げさなようですが、悲願の達成そのもの、というわけです（他の2人も似たような思いをもっていると信じています）。 正直、どんな気持ちでいればいいのかまだよく分かっていないですが、とにかく楽しみな気持ちでいっぱいです。
さて、そんなことを書きつつ、5年前の我々はひどいものでした。
N+1 クエリを解消できないどころか SQL もろくに書けない、キャッシュと称してグローバル変数 $cache を導入する、途中で仮眠を開始する、競技終盤で飛び出す「で、Ruby ってどうやってデプロイするんだっけ？」*1。
こんな有様でも面白くて仕方ないんだから、ISUCON っていうのは本当に凄いですね。
転機は2017年、KOBA789 の就職とともにあったように思います。 メンバーの1人が学生でなくなったことで学生枠での出場権利こそ失ったものの、これはマイナスどころか圧倒的なプラスでした。
DWH チームで SQL をバリバリ書くようになった彼が N+1 クエリを手際よく倒していく様は、その前の年の状況を踏まえるとまさに感激もの。 時期を同じくして我々も同じ会社にアルバイトとして入社し、production レベルのコードやインフラを見る機会が一気に増え、それぞれの実力を伸ばしていきました。
しかし、ISUCON の参加者も年々増え、問題の難易度も上がり、逃げ続ける予選突破ラインを成長で追う我々、という構図がありました。 ISUCON 7 や 8 では top tier どころか 2nd tier にも入れないもどかしさを感じるようになり、次こそは……！ という悔しさは強まる一方。
こんな道を歩んできたチームなので、過去最大の規模であった ISUCON 9 において本選に行けるチームにまで育ったことを誇りに思います。 来月の本番では存在感を示せるチームでありたいものです。
さて、悔しさとか言いつつ、我々は昨年度までは事前準備をせず、実力ってやつに任せてとりあえず殴ってみるタイプのチームでした。 業務や研究を通じての成長でとりあえずぶつかってみる、というほうが適切でしょうか。
実力だけで予選を通過できたらそりゃ格好良いけど、そろそろ本選に出てみたいよね、真面目に準備すれば予選ぐらいは余裕で突破できんじゃない？ やってみるか、との空気がチーム内でにわかに高まり、各種ツールを作り込み、過去問を使った素振りを行いました。 無事その成果が発揮されてホッとしている、というのが正直なところです。
本音のところでは、これだけやれば予選もけっこう余裕で通過できるんじゃない？ なんて話もしていたのですが、結局 10,090 点 / 28位 とかなりギリギリでした。 今年の問題は過去最大級によく作り込まれていて、必死になりながら楽しめました。運営の方、ありがとうございます。
というわけで、これが今のところの率直な気持ちです。本稿の残りは事前準備として作り込んだツールのまとめです。
ソレイユとして出場した過去5回の予選は本当に楽しい記憶ばかり。 このチームで本選を戦えることを僕は本当に嬉しく思っています。出るからには勝ちたい、とも。
優勝するぞ！ 対戦よろしくお願いします！
ここからは事前準備の自慢記事。 一部、というか半分以上は @s4ichi の参加記 と @KOBA789 の参加記 (予定) に詳しいので、そちらも参照。
< ここに KOBA789 パイセンの参加記が入る予定 >
作り込んだツールを整理するとだいたいこんな感じ。
isumon
各ホストのリソースからベンチマークに返っている HTTP ステータスコードの割合まで、全てが一目瞭然になっている Grafana ダッシュボード。名前の由来は 社内にある InfraMonitor 略して imon をもじった isu + monitor 。そのまますぎ？
s4ichi パイセンの記事 に様子が詳しく書かれている。
isukekka
ベンチマーカーによるリクエストを検知して、ベンチマーク中の alp や pt-query-digest を自動で取って GitHub Issue にしてくれるかっこいいやつ。
そのうち KOBA789 パイセンによる詳細な解説があがる予定。
isukit
Itamae でまとめあげられたプロビジョニングキット。 ISUCON 8 で OS が CentOS であることが告知されたとき、慣れない OS でハマって事故死するよりは、ということでちょっとしたものを準備した。 これが割と便利だったので、今回は Itamae でいい感じになった。 isumon の各種ダッシュボードを含め、Slack とか Issue で夢を語っていたら @s4ichi パイセンがどんどん実装してくれて最高だった。
dotisu / 通称「実家」
我々のチームはすべてのコードの編集を本番サーバーで行う (ISUCON 7, ISUCON 8) 。 この「サーバーサイドプログラミング」スタイルにおいては、快適なターミナル環境を整えることはチームの生産性、ひいてはスコアに直結する。 しかしながら、1台のサーバーを共有しているがため、張っている alias や $PS1 が衝突して困るという問題もまたあり、昨年までは自分が割を食うという形で解決した。多分。
今年は自分の zshrc に寄せたものを作って素振りに持ち込んだところ、まあまあ強めの反発を食らってしまった。残念。 しかし我々はエンジニアなので、エンジニアリング™で解決することができ、これがその結果当日持ち込まれた ~/.zshrc 。
if [[ -n ${WATASHI} ]]; then
source ${HOME}/dotisu/${WATASHI}.zshrc
fi
SSH 越しに WATASHI 環境変数を送ると自分の zshrc が読み込まれる、という体験は大変好評で、「実家」「これじゃないと作業できない」「これだよこれ」などの喜びの声が聞かれた。 UNIX ユーザーの概念は、まだない。
mamiya.sh （デプロイスクリプト）
ソレイユ的にはおなじみ、デプロイスクリプトであるところの mamiya.sh *2 。 1台目で実行すると、2, 3台目に rsync でいい感じにファイルを撒いてくれて、全台でsystemd restart も行ってくれる便利なやつである。
本番中に書いても別に良いのだけれど、やっぱり事前に作ったやつを持ち込むのが精神的にも時間的にも楽。 ISUCON 8 予選で使ったバージョンの出来がそれなりに良かったため、ほぼそのまま itamae に投入。
MySQL 8 へのアップグレード練習
GA を迎える前から ISUCON でなんとか使おうとして、ビルド失敗、datadir 読めない、アプリからつながらない、と様々な失敗で時間を溶かした苦い思い出しかない MySQL 8 氏。
通算3度目の挑戦では、今回は確実なアップグレードを果たすために my.cnf を整えて準備し、叩くだけで MySQL 8 が入る itamae の cookbook も持ち込んだ。
default-authentication-plugin = mysql_native_password はだいじ！
MySQL 5.x の purge や新しい libmysqlclient を使うように mysql2 gem を再ビルドする必要があるなど、地味なハマりポイントが多いので手順書としてまとめておいた。 結果としては本番中に10分足らずで 5.7 を置き換えることができ、大成功であった。 MySQL 8.0 にしたことがどれほどスコアに直接響いたのかは計測していないのでわからないが、RDBMS に詳しい氏である @KOBA789 が MySQL 8.0 を散々褒めていたので良かったのであろう。
本番中に行ったチューニングについては @s4ichi の参加記 に詳しいので、そちらを見てください。
これは画像。
*1:これだけ2度めの参加のときの出来事
SKK 試しています
随分と長い間使っていた Google 日本語入力*1が信じられないほど厳しい変換（具体的な例としては「こういうかんじかな」→「こういう漢字仮名」だったり、「これがていばんなのか」→「これが定番菜乃花」「これが定番７日」）をするようになってきてしまったので、重い腰を上げて IME の見直しをすることにした。
その前に、自分のパソコンを使った文字入力スキルについて簡単にまとめておく（この文章は SKK の練習のために書かれているので蛇足が多いです）。いわゆるタイピングゲームで測定できる入力速度はだいたい 10keys/s 前後で、入力速度が遅くて困る、と思ったことはあまりない。プログラミングにおいては「実際にキーを叩いている時間よりも考えている時間のほうが長いので、タイピングスキルはそこそこで問題ない」とする言説をよく見るけれども、あれは完全に間違いだと思っている。タイピングで使っている指の本数は両手の人差し指と中指だけなので、これを増やすことができればもう少し上の領域に踏み込むことができるかな、と考えることはある。ぐらい。
で、本題。SKK を昨晩から使いはじめて、そこそこの速度で文章を入力できるようになってきた。今までパソコンで日本語を入力するにあたって、送りがなの位置など考えながら手を動かしていたことなどないので、ちょっとした脳トレ感がある。多少気持ちよくなってきた段階。しかし、まだ IME に意識を寄せないといけないので、長文を書ける域には至っていない。人間は脳トレしながら長文を書くことはできないのだ。
今のところ困っている (慣れで解決できない) 問題としては、Shift+英数字で一時的に半角英数モードに入れないこと (これは MS-IME スタイルの挙動だ) 。例えば「これはGoogleです」ならば koreha[Shift+G]oogle[Enter]desu で入力できていたが、SKK では Shift は漢字の開始にあたっているので、どうにもならない気がしている。困っています。今のところはいちいち英数字モードに切り替えていますが、例えばこの記事のテキストならば一度も日本語モードを出ることなく入力できていたので、地味にストレスだ。
自己紹介むずかしい
最近 DMM 英会話というやつの体験をやって、あまりにも難しく感じたことがある。
それは自己紹介。
講師「私の名前は〜。仕事は○○なんだけど、好きな映画は□□で、趣味は休日にサッカーをすることで、友達とロックバンドをやってるよ。他にも……（30秒ぐらい続く）」
ぼく「どうも osyoyu といいます、えーっと大学院でパソコンの勉強してます、うーんパソコンが好きです」
講師「Oh, sounds good. (おわり)」
という展開がつらい。どうして人の自己紹介は魅力的に聞こえるものなのだろう。
相手の属性が事前にある程度明らかになっていればもう少し話しようはある。例えば、相手がソフトウェアエンジニアであることが事前に分かっている場合は、最近気になっている技術要素などから話を展開していくことができるし、うーんそうですね、他に例はあまりないな。
髪を切りに行くときもなんとなく自己紹介的ななにかをすることがあるけれども、そういうシーンでも言えることがなにもないので、髪を切りに行くとき用の架空の人格に関する設定を話すことで切り抜けている事が多い。自分のことではないので、するする言葉が出てくる（別にそんなにたくさん話すわけじゃないので、そんなにたくさん設定を用意する必要があるわけではないが）。
（ここまで書いて思ったけれども、ただ単に自己紹介の機会が少なくて練習が足りていないだけという気がしてきた。DMM 英会話の講師は30分に一度自己紹介をしているわけだし、その過程でどんどんこなれていくわけで、そりゃ自己紹介で負けるわけだわ）
まあ、いずれにせよ、汎用的に使える自己紹介文を準備して、来たる自己紹介の刻に備えたい。自分でそれをできていればなんの苦労もないので、なんか僕が使えそうな汎用自己紹介パーツがあったらみなさん教えてください、ということを言いたかっただけの記事でした。