私が歌川です

@utgwkk が書いている

ログ

ログ*1、油断すると絶妙に情報量が足りなかったり、欲しいものがdebugレベルでしか出ていなくて本番環境で見れなかったりしがち。ここでこういうログが欲しくなるだろう、という感覚を鍛えるには、実際にログが足りなくて困る経験をするしかないのか、もうちょっと高速道路が整備されているものなのか。

外部APIにリクエストを送る部分はとりあえずリクエスト・レスポンスの内容を (ユーザー個人情報などには気をつけながら) ログ出力しておくと調査に役に立つ、というのはありそう。GoのgRPCクライアントのミドルウェアにはまさにそういうのがあるし、HTTPクライアントにログ出力の仕組みを差し込むのもすぐできる。自分のシステムに閉じていない部分はこういう仕組みが整っていそう。

ほかにはアプリケーションごとに固有の事情に合わせることにもなるだろう。何が重要で、調査をしたくなるか、そしてアプリケーションログではなくもっと永続的なデータとして残したくなるか? ログとログデータの区別はどこに生じるのか?

*1:ここではWebアプリケーションやサブシステムなどのアプリケーションから出力するログを指す

週末

金曜日

定時ダッシュで新幹線に乗り、渋谷へ。

5時までクラブにいるのは初めてなもので、4時ぐらいからだんだん睡魔が勝ってくる。なんとか最後までいることができた (帰る家がないから)。

土曜日

11時ぐらいに目覚めた。意外と元気ですごい。

萩の湯で風呂をキメたあと、川崎に名取さなさんを見にいく。名取さなさん、背が低くて手がちっちゃいな。

lacittadella.co.jp

そして、12時間ぶりに渋谷に向かうのであった……。チケット代として1万円払いました。

終電の新幹線で京都に帰って、気絶。

日曜日

レンタカーでドライブ。免許がないので座ってるだけ。

www.youtube.com

大量の新情報を浴びながら京都に戻ってきたのであった。なんか京都ブームが来ているらしい。

中央・総武線沿いを歩くコーナー

歩くタイプの暇潰しは、融通の効く街ならいくらでもすぐに切り上げられるし、風景をちょっと気にするぐらいでコンテンツを生み出せる。

秋葉原

東京に来てとくに用事がないとき、だいたい秋葉原にいる。今回は御茶ノ水に用事があった。せっかくなので歩いていくことにする。

アーケードゲーム基板ショップみたいなのが気になったけど行かずじまいだった。

御茶ノ水

湯島聖堂で孔子像を見る。Swarmに孔子廟というジャンルがあることを知った。

まだまだ暇なので、いけるところまで歩いてみることにする。

水道橋

東京ドームってこのあたりなのか。なんか人が多かったように思う。

飯田橋

だんだん神田川と外濠の区別がつかなくなる。東京は起伏がすごいので歩くと疲れる。しかし大きな荷物を持っていなければ普通に歩ける距離ではあろう。

市ヶ谷

NFTを捨ててはいけない。わかりましたか?

四ツ谷

外濠が終わったので、このあたりで切り上げて電車に乗ることにする。外堀について高速に学習した。


東京に引っ越すならどこがいいか、というのを考えなくもない。すぐに人を募って飲みに行けるところかな……。

個人の技量だけではスケールしないのは確かだが、それは技量を伸ばさずに別のところだけ伸ばしていればカバーできる、ということを意味しているのではないだろう。いわゆる「魚の釣り方」を超えた技量の伝授ができるようになって初めて、高い生産性に対する脱属人性・再現性ができるのではないか。ドキュメンテーションだけで属人性が解消するほど簡単ではない。

ソフトウェアに対する考古学は技術的好奇心を満たすのにとどまらず、当時の考え・設計思想を理解することでコードベースに対する深い理解を得て、今後の糧となる。いちばんコードベースへの理解が深い状態とは、自分が設計・実装したことがあるコンポーネントが大半の状態、ということになるんじゃないか。

再現性のある知とは?

GraphQL Cursor Connectionにおけるedgeのnodeフィールドの型は必ずしもNode interfaceを実装していなくてもよい

タイトルが全てです。

GraphQL Cursor Connectionの仕様の3.1.1節には以下のような注意書きがあります。

The naming echoes that of the “Node” interface and “node” root field as described in a later section of this spec. Spec-compliant clients can perform certain optimizations if this field returns an object that implements Node, however, this is not a strict requirement for conforming.

https://relay.dev/graphql/connections.htm#note-e0232

注意書きをざっくり訳すと以下のようになります。

  • この node という名前は、GraphQL Object IdenrificationにおけるNode interfaceや node クエリを想起させる
  • が、connectionのEdgeの node フィールドの型は、必ずしも Node interfaceを実装していなくてもよい
    • もちろん、Node interfaceになっているほうが最適化が効きやすいだろう

多くの場合はEdgeのnodeがそのまま Node interfaceを実装するようになっていても支障はないだろうけど、必ずしも Node interfaceである必要はないよ、というのが伝えたいことでした。

アイコンのステッカーを支える技術

以下のツイートが全てです。

この記事では、ツイートで触れていないトピックについてメモします。

大きさ

技術イベントの名札に貼れるぐらいのサイズにすると取り回しがよいです。40mm x 40mmはラクスルで発注できるバラ四角カットシールの最小サイズです。

貼った様子は以下のツイートにある写真を見てください。これぐらいのサイズだと、小さな名札に貼った上で名前も書けるぐらいに収まります。

配置

アイコン画像に余白がない場合は、印刷保障線を少しはみ出るぐらいにサイズを調整して入稿するほうが見栄えがよいです。アイコンの端が途切れるのを恐れずに入稿しましょう。先述したツイートの画像にあるシールを発注したときは日和ってしまったので余白があります。

納品形態

他の納品形態を試したことがないけど、バラ四角カットにするとかさばらず持ち運びやすいし、1枚ずつ配りやすいです。アイコンの形をアピールしたいときはバラ台紙カットするのがいいのかな。

部数

多ければ多いほど単価が安くなると思うけど、量が増えるし値段も上がるのでいいバランスを見極めましょう。

自分はとりあえず50部で注文しています。単価は 2,805円 / 50 = 56.1円で、まあこんなもんなのか?

同人イベントとかで配りまくるならもっと部数があってもよさそう。

納期

納品までの日数が多ければ多いほど安くなるので、余裕を持って発注しましょう。7営業日は1週間よりも長いので注意してください。

画像形式

1200 x 1200ピクセルのPNG画像で入稿したけど、印刷の粗とかはとくに気になっていないです。自分が気にしていないだけかも。


ほかにも話題がありそうだけどいったんこれで。インターネットにいると人をアイコンでしか認識できないことがよくあるので、オフラインカンファレンスなどで名札にアイコンのステッカーを貼ると認識してもらいやすくて便利だと思います。