北海道苫小牧市出身の初老PGが書くブログ

永遠のプログラマを夢見る、苫小牧市出身のおじさんのちらしの裏

今日は YAPC::Kyoto 2023 の日です

昨日 に引き続き、今日は Perl 神社 に来ていますので、自分用にメモを残しておきます。

オープニング

  • YAPC Kyoto 成功祈願の様子の動画
    • 開発成就、成果達成！
  • YAPC Kyoto 2020 年から３年ぶりに焼き直し
    • Reboot
  • 蓋付きペットボトル、会場配布のもの、以外は飲食禁止
  • 禁煙
  • 疫病対策はマスク、アルコール消毒、ソーシャルディスタンス
  • no photo のタグを付けてる人は写真を撮らないよう
  • CoC 守りましょう
  • #yapcjapan 、 #yapc_sp #yapc_gy 、 #yapc_do
  • Perl神社の参拝回数、金額に上限はありません（ TPF に寄付）

Helpfeel さんのスポンサーセッション

  • 会場名をつけた
  • Gyazo, Scrapbox, Helpfeel なんだけど、 2 つしかつけられなかった

【企画】春のエンジニア ぶつかり稽古 2023

秋のエンジニア ぶつかり稽古 に登壇した者として、見届けに参りました。

  • 10 年前のイベントのリバイバル
  • YAPC::ASIA の参加者スペシャル特典だった
    • 「あんちぽ」さんと「ぶつかり稽古」したい
  • きっかけとなった YAPC でリバイバル
  • ライブコーディング形式で進める
  • お題「ソート」
    • 一人がテストを書き、もう一人が実装を書く
  • 順番はじゃんけんで「相撲取れと言われなくてよかった」
  • 入力を手動で並び替えてテストを PASS → リファレンスと配列の違い、シジル
  • 要素数を増やして別のテスト
  • 文字列のソート機能も含める
    • ChatGPT さん「 looks_like_number 」
    • looks_like_number で >= gt で分ける
  • 文字列と数字が混ざったソート
    • 第一オペラントだけでなく、第二オペラントも数字だったときのみ >= を利用
  • 攻守を入れ替え（ここから ruby ）
    • sort をすでに実装したものがあることがバレる「バブルソートと選択ソートは使えなくなりましたねえ」
    • 急遽 sort_by にお題を変更
  • 予め作ってあったバブルソートからコピペ「コソ練が生きてきた」「伝家の宝刀」
  • 文字列の sort も可能
  • 文字列と数値を混ぜると失敗
    • 文字列と数値を比較した結果は nil
  • nil を入れてみる「起こられが発生」
  • nil.to_s <=> ""
  • そもそも渡しているブロックで <=> を使っているが、コピペ元は >= だったので、きちんと直す必要があるのでは
  • ChatGPT による総評「Perl は初心者に読みにくい」「Ruby は読みやすい」

地方のエンジニアが作る日本のITコミュニティの未来 / @tooka_91 さん

  • エンジニア採用をやっている
  • 関西ではB2B向けの SaaS を開発している
  • 福岡、ベトナム、京都、大阪、名古屋
  • エンジニアのコミュニケーションを英語化
  • 居住地に関係なく、全国のエンジニアがキャリアに挑戦できる環境
    • 自分も、居住地に関係なくキャリアを築く
  • 1 つのテックイベントから、 IT 業界に入れた
  • 地方は、メーカー企業に入社することが美徳→エンジニアというキャリアを見逃す
  • エンジニアのあらゆる活動が、誰かの未来の可能性を作っている
  • 自分の可能性に気づいている人が少ない
    • IT コミュニティの 1 つの役割
  • コロナによる変化
    • リモート→居住地によるキャリアパスの制約が減った
    • 地方の報酬が、全国の採用競争で上がった
    • プライベート、キャリアの両立がし易い
    • オンラインコミュニティへの参加しやすさ
    • 一方で、地域は衰退する（リモートで全国区へ）
  • 全国各地にCTO, VPoE
  • 地方のエンジニア採用は必須条件（エンジニア不足）
  • エンジニアの人生を支えるコミュニティ
  • 地方エンジニアのロールモデル
  • 質疑応答
    • Q). コミュニティの貸し出しスペースがなくなってきている
    • A). Money Forward は場所を貸し出している。コミュニティ活動を辞める人は実際多い
    • Q). 地域感のコミュニケーションはどう盛り上げる？
    • A). 名古屋と関西でテックイベント。地域関係なしでやろうとしている。地域で決めてから、別の地域に声をかける
    • Q). 若手を引き込むいい方法は
    • A). モクモク会はハードルを下げられる。大学とコミュニケーションを取る

my$talk=qr{\b((?:ir)?reg(?:ular )?exp(?:ressions?)?)\b}ig; / dankogai さん

  • タイトルは読めません
  • いろんな言語、 unicode 、正規表現の正規ではない部分
  • この正規表現はなんですか？ ChatGPT に聞く
    • 「正しい UTF-8 のバイト列にマッチする」
  • 浮動小数点数 (C99) にマッチする正規表現
  • 素数判定する irregular な正規表現 /^(11+?)\1+$/
    • \1 のせいで regular
  • カッコの判定も irregular
    • cat | perl でも Perl は実行できます
  • 二十世紀と二十一世紀で文字列の定義が異なる
    • 昔はバイト列
    • Perl は 5.8 から Unicode サポートするようになっている
    • Java, JSS, Python2 は絵文字などをサポートしていない
  • Node.js では、 u フラグを使わないとサロゲートペアが 2 文字扱いになる
    • Python2 では死にたくなるので捨てて（コンパイルフラグで挙動が変わる）
  • 国旗の絵文字の例
    • 合成文字。 \x{1f1ef}\x{1f1f5}
    • Perl では \X を使うと良い
    • JS ではサポートされてない
      • 一部のブラウザでwork around はある
  • Regexp::Common
    • $RE{net}{IPv6}
  • Regexp::Assemble
    • 5 文字の辞書内の英単語にマッチする正規表現
    • 「 wordle に登場する単語にマッチする正規表現」
  • 正規表現の Unicode については Perl が一番サポートしている
    • \X は 5.8 の頃からサポートしている
    • ChatGPT は意外ときちっと返ってくるが
  • 質疑応答
    • Q). Regexp::Common はジョークモジュールでは？
    • A). optimize されていて、使って大丈夫なはずである。正規表現はいろんな言語で使われているので、 Perl で regexp を生成してもいいだろう
    • Q). \X を絵文字が流行る前に追加したのか
    • A). unicode consorsium でGrapheme clusterは定義されていた。 Perl ではそれを素直に実装した

あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで / あらたまさん

  • cake.jp の CTO
  • YAPC 2011 で衝撃を受けた
  • ハッカーに憧れて入社したが、ギャップ
    • 振る舞い、実力
    • 誰にも言われていないのに
    • ゴールも「ハッカー」の定義が不明
  • 憧れてから 2 年経っていた
    • 2 年経つと組織も変わる
    • そこは「ハッカー集団」だったのだろうか
  • ハッカーとは
    • 「遅く来て遅く返る」違う
    • 「CPAN Author」主従が逆。モジュールはほとんどstable。実力不足
    • 「 YAPC で登壇」なんかこれじゃない。ハッカーとは言えない
  • みんなで成果を出す。事業を出すのが大事
    • すべての人が尖っている必要はない
    • 抽象度のコントロールが得意
    • 連携のほころびを見つけ、修復
    • PM のロールがきっかけ
    • 「技術力で突き抜ける」という正規ルートではないという疑問。正しい成長？
  • 成長していた。評価されていた。周りが強過ぎ
  • 「ベクトルが自分に向いているうちは何してもだめ」 DeNA 南場さん
    • 自分のゴールも不明確だった
  • エンジニアの評価軸
    • 「正しく」設計し、「正しく」コーディングする
    • 「正しさ」は簡単に変わる
    • 市場、業務フローは変わる→技術的確からしさだけで技術選択はできない
    • 突き抜けた技術、だけではなんとかならない
  • 「システムは現実の写像たれ」くふうカンパニーCPO 前田さん
    • 業務フロー、カスタマージャーニーを、忠実にコードへと落とし込む
    • 能動的に情報を取りに行かなければならない。外側を知りに行く
  • エンジニアは how に責任を持つ
    • why と what は正しく理解しなければならない
    • ドメインに明るくないと、寿命の長いコードを書けない
  • 事業、技術のどちらの軸もそれなりに育った人が求められた人
    • サービスインから高トラフィックに晒されたりする場合は例外（技術に尖っている人が必要）
    • 事業、技術のバランス。自分がどう動けば、プロダクトが成長するのか
  • 第 3 の軸: 組織
    • 会社に人が集まるのは、 1 + 1 >> 2 としたいから（安定したお給料はいいものだけど）
    • マネージャーじゃなくても、「うまくマネージされる」「チームの生産性を上げる」
  • 3 軸の評価指標は、絶対的ではなく相対的
    • 環境によって大きく変わる
  • 2015, 2020, 2023 年で、組織からの期待と自分の希望は異なる
    • すり合わせが必要
    • 苦しんでる人は、自分に期待されていると思っている役割と、実際に期待された役割がずれている可能性も
  • テックリード、スペシャリスト、エンジニアリングマネージャー
  • CTOのフェーズ別→初期は技術力、成長期はバランス、円熟期はPDM, CTO, VPoP と分担
  • ハッカー
    • HRT ( 怠惰、短気、傲慢 ) が実装されている
    • 目的の達成に労力を惜しまない、技術を正しく使う
    • 技術を好きな方がいい（バフがかかる）
  • ハッカーじゃない
    • 朝が遅く夜も遅い
    • コミュニケーション・コラボレーションを拒否する
    • 視点の狭い正論を振りかざす
  • 我々の中にハッカーの性質があり、それをどう表に出して育てていくか
    • 「あのとき憧れたハッカーは、実は自分の中にあった」
  • 自分の希望を、自分の言葉で口に出せるように具体化するのが大事
    • 乗っている船に、自分の will を重ねる→納得の行くキャリアが歩める
    • 「型にはまると安心する」→「やりたいことをやっていると名前が後からついてくる」
      • マネージャー→エンジニアリングマネージャー
  • 質疑応答
      1. いつ呪縛から解かれたのか
      1. 色んな人にあって、いろんな経験をしたため。突然プロジェクトに放り込まれて、足元が変わったことはある

今出川 FM 特別編 in YAPC::Kyoto 2023

  • テーマ: LLMs や Chat GPT の活用について
  • お昼の校内放送的な
  • カウントダウン～番組名～拍手
  • ChatGPTの衝撃から LLMs をずっと触っている
  • slido.com #3950 470 です
  • マシンラーニングしましょうといった記憶が無いのになぜ？
  • 機械学習をちょっと知っているエンジニアで、こそこそデモを作ってやってた
  • 去年の秋。ポジティブではないが、あるタスクでなら使えるかもと思っていた
  • ある言葉をマスクして当ててもらう用途であれば。ヘルプとして使うのはむずい
  • T5 ファインチューニングしていた。アイデア次第では使えそうだった
  • 学習に一晩かかり、イテレータ大変だった
  • ChatGPTは使うの簡単。何に使うの？がむずい
  • GPT3 では、文章の続きを作ってくれた「いたこAPI」
    • 使えるイメージが沸かなかった
  • 未完成プロダクトが、 ChatGPT で一気に完成した
  • プロンプトの作り方が Twitter で出回った
    • 中間問題を挟むとか
  • 英語でプロンプトを書いて、最後に日本語にしてもらう
    • 日本語の入力は少ないのに、なぜかうまく応えられる
    • 何が起きているか、研究者の間でも不思議
  • 言語処理学会で ChatGPT は禁句？
    • ChatGPT との比較研究をしている学生さんもいる
  • google docs に gpt 関数を作って実験した
    • プロンプトのアイデアをまとめた
    • 自分のツール
  • ChatGPT の興奮ポイントは？
    • プログラマとしては、少ない労力で圧倒的な成果がでる
    • 楽しい
  • 会場から: Q). ChatGPT で試してよかったプロンプトは？
    • 箇条書きにしろ、など、シンプルな回答を手にする
    • プロンプトが長くなればなるほど、指示が無視される
    • システムプロンプトを分けると、慌てないで言うことを聞いてくれる率がある
  • 自分がいいプロンプトを書けた、とは思わない方がいい
    • 1 つのサンプルケースだけ改善しても、マグレ
  • 会場から: Q). ChatGPT がコードを書くなら、僕のお仕事は？
    • Python を書けないけど、 ChatGPT が教えてくれる
    • 自分ができないことを、拡張してくれる
    • プロンプトの質は入力者の能力に依存する。エンジニアのキャリアがあれば、いい回答が得られる
  • 会場から: Q). よいプロンプトと悪いプロンプトの違いは？
    • やりたいことを直球で伝えて、任せたほうがいい
    • プロンプトの書き方は陳腐化する。モデルが向上すれば不要になる
    • いい、悪い、という指標はどんどん変わる
    • 対話を続けながら、間違えを指摘していく
  • 会場から: Q). プロンプトの作成はエンジニアリング？
    • はい。ランダム要素が少ない。ブラックボックスに見えるが、入出力にルールがある。エンジニアリング可能
    • 適材適所に使う、というのもエンジニアリングの要素。 99.9% の例で正しい回答が出せるのか
  • 会場から: Q). とんでも回答への対応は
    • 99.9% 回答できる問題に分解して適用する
    • ヒューマンインザループ。エンドユーザに見せるまでに、人の工程を挟む。社内ツールに使うなど。サジェストに留めるなど。
    • 逆に創作活動に使えるのでは。自分の殻に閉じこもっては得られない回答が得られる
  • 会場から: Q). NLP 学会で GPT4 が公開されたことについて
    • スポンサーは湧いていたが、参加者は誰も触れてない
    • シャトルバスで GPT4 のニュースが流れてたり
    • NLP から web 側への歩み寄りがあるのでは。リーチが圧倒的
  • 会場から: Q). シンギュラリティはいつ来る？
    • 来たと思って働いているといいのでは
    • AI が AI を改善始めると来る。もう少し？
    • 自然言語はすでに作れているようだ
  • 会場から: Q). チャットとしての制約は
    • 長く喋らなければならない。タスクによってはマシなやり方があるのでは
    • ・・・を・・・してください、は実はタスクを処理している
    • OpenAI 社が使いやすいようにチャットにしてくれただけ。限界は感じない
  • 会場から: Q). プロンプトの管理
    • git 管理してます
    • プロンプトを考えるのは、エンジニアではなく、日本語が得意な人がいい？
    • git は commit を積み上げるツール。流動性高く、どんどん試せるものがいい
    • OpenAI に eval というリポジトリがある。解けない問題を集めるリポジトリ
      • CLI ツールで accuracy を計測でき、 CI/CD で回すことはできる
      • コストが問題
  • ChatGPT さんも連れてくればよかった

ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す / @moznion さん

  • do kill die が好き
  • 廃墟とは
    • 動いているけどメンテできない。なぜ動くの
    • 実装だけでなく、 API 、設計思想、アーキテクチャ
    • ネットワークの設計も気を抜くと廃墟になる
  • 「ソフトウェアは壊れない」→神話
    • 自然劣化しない
    • 作った瞬間から壊れている
    • 機能改善への要求に答えられなくなると、壊れる、劣化する
  • 「技術的負債」は誤用。それは廃墟だ
    • danさん「借りてないでしょ」
    • 良くないソフトウェアが正当化されている
  • 廃墟の問題
    • 誰もメンテできない
    • 「再起動したら奇跡的にリカバリできましたね！」その先はない
    • 新機能を安全に入れられない。無理矢理に入れていく。違法建築
    • 「廃墟は伝搬する」隣も隣も全部廃墟になる
  • 「枯れ」と「廃墟」は違う
    • 「継続的に整備、機能追加可能、デプロイ自動化」枯れているだけ。新機能追加はできる
    • どちらも、長期間安定に運転されているように見えてしまう
      • 大爆発する前に、どう見極める？
      • 判断が自動化できる？ last update が 2 年前でも、動くことはあるわけ
  • 廃墟を直す
    • むずかしい。コストとのトレードオフ。直せるなら直したほうがいい
    • 人的リソースを割くのがとても大事。
      • できれば複数人、チームでやらないと、逆戻りするリスク
      • 「個人技の限界」と「個人技による圧倒」
    • CD を整えるのがまず最初
      • 足回りを固める。デプロイが難しいと誰もやらない
      • やることで、廃墟の構造がわかってくる
    • 開発環境が必要。口伝ではダメ
    • テストで固める
    • ステージング環境を作る
      • 難しいが、不確定要素が多過ぎる。本番と同じ状況が必要
      • 祈りベースのデプロイでは駄目
    • 各種バージョンを上げていく
      • Java 1.5 がまさか動いているとは・・・！
      • 古いものを使い続けると足枷に
      • 少しずつ上げていく
    • 普通のプロジェクトと同様の開発フローへ
  • 廃墟を出る
    • 作り直す、別のコンポーネントに機能を移譲
    • リーズナブル。採用に有利になることも
    • セカンドシステム症候群ではないか、常に疑うこと
    • フルリプレースはだいたい失敗する
      • 成功するときは圧倒的な個人技だが・・・
      • 個人技なので、また廃墟になる
    • 入力と出力だけを満たす
      • 廃墟を廃墟のまま移してはいけない
    • 突飛な言語、フレームワーク、アーキテクチャは廃墟への道
    • 作り直すかは熟考: 失敗すると、思い出しか残らない
    • 健康なコンポーネントに廃墟を移設すると、伝搬する
    • 廃墟の集合体をまとめて、まるっと移すこともできる
    • 責務レベルでコンポーネントを
  • 廃墟を壊す
    • 商売を辞める「やめましょう」
    • 売上、顧客影響
    • お客さんに影響を出すのは「ダサい」
    • 廃墟の伝搬
      • おかしなインタフェース
      • 劣悪なパフォーマンス
      • やる気 ( 廃墟の周辺は人が寄らない。妥協が許される )
    • 必要なものは、別のコンポーネントに移せば良い
    • Twitter の blackout test: サービス終了前に事前予告的にサービスを落とす
    • 瓦礫の片付けは大事
  • 廃墟に住む
    • なぜ住むの
      • 人がいない、金はない
      • 気がついていない
    • 動くまで動かす、違法増改築、テストさえなければ壊れたことに気が付かない: 不愉快
    • 合法増改築: 小コンポーネントを切り出し、そちらを直す。
    • ライブラリのみバージョンあげる
    • 時間が経過するほど、直せなくなる（違法建築。人は減る。キャリアパス）
  • 廃墟に死す
    • システムの倒壊が先か、サービスが終わるのが先か
      • 倒壊はエンジニアにしかわからない
    • エンドユーザへのリスペクトは必要
  • 廃墟になるのはなぜか→カネがない
    • 古い技術スタック、システムが複雑
  • 廃墟ではなく、枯れを目指す
    • 運用の自動化
    • Renovete, Dependabot 依存の自動更新
    • 自律的な状態復元
    • ドキュメント（ ドキュメントがない OSS で成功しているものはない）
    • チームでやる。個人が去ってもサービスは続く。モチベの維持（特に、個人が兼業しているとき）
  • 廃墟へのリスペクト
    • 利益を生んでいる、生んでいた
    • 廃墟をリスペクトしないと、廃墟化が進む
    • 考古学: 当時の技術トレンド、ビジネスロジック
    • 今の技術のほうが優れているはず。現代技術で武装して立ち向かえ
  • 質疑応答
    • Q). コメントに廃墟の理由が書かれている
    • A). 廃墟である可能性が高いが、真の廃墟には何も書かれていない。 TODO を直していくのがいい
    • Q). 古墳は何かを乗せると壊れる。人はもう滅亡している。どうする
    • A). そこまで行ったら作り直しましょう
    • Q). 経営で気をつけることは？
    • A). 経営の立場がないと、物を直す動機づけができない
    • Q). 廃墟を偉い人に認識させるには
    • A). 変更したときに壊れるはず。発生率を数値化して可視か

4PB(ペタバイト)を超えるオブジェクトストレージをハードウェアからアプリケーションにかけて運用するノウハウ / 三上 烈史さん

  • オブジェクトストレージを運用する経験は少ないはず
  • 30days, bayt でオブジェクトストレージを利用
  • オブジェクトストレージといえば、 S3/GCS
  • 30days は 2008 年のサービス。 MogileFS
    • 2015 年に Bayt という社内向けオブジェクトストレージを開発
    • MogileFS の運用経験、 S3 よりも安い
  • Bayt はコスト重視、機能重視であれば S3
    • S3 互換 API だが、一部しかサポートしていない
  • MogileFS: モガイル？モジャイル？
    • client, tracker, database, storage node
    • C 実装である、 cmogstored を利用
  • Bayt: MogileFS に Bayt API とリバースプロキシを重ねたもの
  • クラウドを活用するので、ハードウェアを意識することは減っている
  • ハードウェア構成
    • 15 台
    • HDD 386本
    • 6TB ～18 TB の容量でばらばら
    • 計 4.58 ペタバイト
    • 増え続ける。常に大容量が必要
  • サーバと HDD を増設するだけでは駄目
    • ラック代が高い / ラック 20 ～30 万
    • サーバも HDD も壊れる → 壊れる前に廃棄
  • サーバの性能の劣化
    • 高性能なサーバより、相対的に遅い
    • ライフサイクルを意識する
    • 古いものを廃棄、空いたラックに性能が上のサーバを導入
  • 筐体サイズと HDD 収容能力
    • 2U で 16 Bay、 4U で 36Bay
    • CPU / メモリはいらない
  • データセンタ向け HDD
    • 24 時間稼働が可能。 SSD は高い。 Bayt の要件は HDD で十分
  • HDD の記録密度は増えている
    • 今は 22TB だが、 25 年以降には 30TB 以上を目指している
  • 半導体不足→納期 2 ヶ月だったのが、半年～ 1 年に
    • 先行した発注が必要
  • 為替の影響。海外製サーバを利用するため
  • smartmontools を利用して HDD を監視
    • issue が自動で立つ
  • MogileFS の機能による切り離し
    • alive, drain, readonly, down, dead
    • 切り離されると、自動的にコピーされ、冗長性が担保される
  • Bayt API
    • S3 REST API 互換
    • GetBucket, GetObject, HeadObject, PutObject, CopyObject, DeleteObject, GetObjectACL, PutObjectACL
    • RoR で実装
  • GET /sample/object の例
    • Bayt用メタデータ Content-Type, Content-Length, Etag
    • tracker に問い合わせ
    • MogeleFS が在り処をリバースプロキシに教える
    • リバースプロキシが取りに行く
  • Bayt から S3 へ
  • 30daysAlbum はそのまま使う
    • ハードウェア、 MogileFS 運用の属人化
    • そもそもアプリも属人化、レガシー化
    • 属人化対策、ドキュメントを書く、障害対応トレーニング
    • オンプレ構成から、クラウド込のハイブリッドに
  • 質疑応答
    • Q). MogileFS に暗号化の機能はあるか？
    • A). ない
    • Q). 読み込み書き込み速度の差は問題にならないか。ハズレロット問題
    • A). 意外ときれいに分散してくれるので今のところ大丈夫。発注時に多めに出すような対策をしている
    • Q). 写真の解像度が大きくなっているはず。取ってくるのは遅くなってくるのでは
    • A). metrics を見る限りは顕在化していない

どこでも動くWebフレームワークをつくる / Yusuke Wada さん

  • Perl の話を絡めると複雑なので JS
  • github star で 3,869
    • cdnjs, Polyfill.io, Ultra, Driv.ly, reeat.dev, Convex などなど
  • Cloudflare Workers, Fastly Compute@Edge, Deno, Bun, Lagon, Vercel, Node.js などで動く ( すごい )
  • Cloudflare Workers 向けに作った 2021 年 12 月
  • Express ライクなシンタックス
  • なぜどこでも動くのか→ Web Standard のみ使う
    • Cloudflare と Node.js が推奨
    • WinterCG
    • Request, Response, URL
  • Wrangler 2 の ( 元 ) メインメンテナに取り上げられた
  • Fastly Compute@Edge
    • WASM にコンパイルして使う → Rust JS Go にも対応
    • WinterCG に絡んでないが、使える
  • そのまま動く == ミドルウェアの資産をそのまま使える
  • Deno / JS ランタイム
    • Web Standard は使えるが、 import の方法が違う
    • やめようと思ったが、楽しそうだったので v2 で対応
  • denoify → .ts にしてくれる
    • Deno で使っている人がおもったより多かった
    • マルチランタイム化へ
  • Bun
    • 2022年 1 月からクローズド開発、 7 月に公開
    • Node.js Deno よりも速い
    • Cloudflare Workers と同じコード
  • Bun では Express が動かなかった
    • 「 Hono を使うことはできます」→利用数が一気に増えた
    • 実は、作者には初期の頃から知られていた
  • 「すごくないですか」 → 拍手
  • Bun は本当に速い
  • Lagon これもサーバレスランタイム
    • ステージは Dev
    • 作者から PR
  • Vercel / Next.js に特化したホスティング
    • エッジは Cloudflare で動いているので OK
  • Node.js
    • Adapter を使うことで対応
  • CI では全てのランタイムのテスト
  • c.runtime でランタイムを取れる
  • Web Standard の Standard web framework
  • 次は AWS Lambda で対応した（使ってみてください）
  • 質疑応答
    • Q). the edges のほうがいいのでは
    • A). あ、はい
    • Q). なぜ Hono に？
    • A). Cloud "flare" から
    • Q). マルチランタイムのテストで気をつけること、頑張ってることは？
    • A). メインのテストを通す。環境に依存したテスト（暗号系、環境変数を重点的。ファイルシステムとか）
    • Q). Bun の Express と Hono の速度の違いはなぜ？
    • A). WebStandard の API が Bun が速い。それ以外を使うとオーバーヘッド

My New Error... - It is my new era. / @sadnessOjisan さん

  • 3 ヶ月間、アラートの監視の仕事だけをした
    • 30 個近いレポジトリからのエラーログ
  • オオカミ少年問題への対処
    • 監視をしやすいエラーハンドリングについて
    • スクラッチから書く前提
  • 理想論から現実の問題へ
  • 何が起きていた？
    • 障害に気が付きたい、潜在的な問題に気が付きたい
    • PagerDuty, StatusCake, Sentry, GCP / AWS, Datadog, Kibana
    • 入門監視「目的が決まっているのであれば、様々なツールを導入するのはいい」
    • 何を見るのか、決まっていないと困る
    • 大量のアラート、出るべきアラートが出ていない
  • 様々な問題があるが、実装の問題から取り組んでいく
  • try catch での例外の管理
    • 例外を知らないと try を書けない
    • Result 型を使う
    • Result で包むのは正常系は無駄
    • 言語機能でないので、トレースが大変
  • デメリットがあっても導入
    • SSR が必須だが、部分的な失敗を表現しやすい
    • 例外が飛んでくる予測がむずかしい
    • Rust になれたい、 Scala チームがある
  • パフォーマンスへの問題は、後から対応する
  • 関数型プログラミングをしたい訳では無い

新幹線の時間があり、ここで帰宅。

今日は YAPC::Kyoto 2023 前日祭の日です

土俵に来た ので、自分用のメモを残しておきます。

オープニング

  • 3 年ぶりのオフライン開催
  • 今日は他の部屋で別のイベント ( 新卒説明会、学会 ) をやっているので、お静かに
  • CoC 遵守
  • 困ったら yapc-kyoto-2020-core@googlegroups.com へ

PHP8によるデザインパターン入門 / 遠藤太徳さん

  • GoF
  • 歴史
    • 起源 A Pattern Language 建築の本
    • Using Pattern Languages for Object-Oriented Programs 論文
    • Gang of For / Erich Gamma, Richard Helm, Ralph Johnson, John Vlissile
    • Design Pattern 書籍
    • 完全なプログラムが生成できるとは主張していない ( 建築の方は完全な建物ができるらしい )
    • 生成、構造、振舞のパターン
  • PHP5, PHP7, PHP8
    • Personal Home Page Tools が起源
    • PHP5 オブジェクト指向
    • PHP7 型の指定
    • PHP8 ユニオン型、名前付き引数、列挙型など
    • jetbrains の PHP 25 周年記念サイトによくまとまっている
  • Singleton
    • 生成に関するパターン
    • 一つのインスタンスのみ。他のコードからの変更を防ぐ
    • 変数を private にする
    • getInstance で生成されていないときだけ、生成する
    • PHP7 だと nullable ? 型を使える
    • PHP8 だと null合体代入演算子 ??=
  • まとめ
  • なぜデザインパターンを学ぶのか
    • 手段は本質よりも早く廃れる

インシデントレスポンスを自動化で支援する - Slack Bot で人機一体なセキュリティ対策を実現する - SEASON2 / 伊藤洋也 さん

  • インシデント: 機密性、完全性、可用性
  • インシデントあるある
    • ログが流れる
    • Slack のスレッドでやると、みんなが気が付かない
    • 人を適切に呼び出せない（気が引ける、誰を？）
    • 発生と完了を伝えられない
    • フローが不明確、マニュアルが無視される
    • いつ、どこのチャネルで対応されたか不明
    • 再発防止ができない（サマリがなくてようわからん）
    • ポストモーテムやりたい
  • インシデントのアウトプット
    • 企業のテックブログ（障害や訓練）
      • CloudNative Inc, mercari, モノタロウ, STORES, RAKUS, Ubie, Sreake など
    • 情報誌、カンファレンス
      • システム障害対応の教科書
      • Incident Response Conference, LEARNING FROM INCIDENTS Conference
    • SaaS
      • BLAMELESS, rootly, jeli, incident.io, Waroom, Datadog, PagerDuty, Graphana Incident
  • @sssbot GMOペパボさんの内製
    • 準備 -初動-> 対応 -普及-> 事後分析 -解決->
    • 発生、検知アラート、対応、復旧、解決
    • ユーザ、組織の両方に影響がある。
    • インシデントマネジメントの時間を短縮 Time is Money
  • 初動
    • sssbot を呼び出すと、チャンネルを作る
    • 通知を複数のチャネルにブロードキャスト
    • 1 インシデント 1 チンャネル
    • 初動対応チームを自動で invlite (心理的ハードルがあるので、人ではなく bot がやる)
  • 対応中
    • タイムキーパーが 15 分毎に現れる
    • 復旧の通知まで担当する
  • 事後分析
    • postmortem のドキュメントを作ってくれる
    • pin したメッセージからタイムラインを自動生成
    • ダッシュボードから一覧可能
    • /archive し、通知
  • 準備
    • 年一回以上訓練・演習している
  • 実装、設計
  • Brent Chapman さんのプラクティスを参考に
  • 参考書:
    • SRE 本
    • システム障害対応の教科書
    • INCIDENT MANAGEMENT FOR OPERATIONS (消防士の経験から)
  • CSIRT*, 経営層への情報共有
  • 課題
    • 事後分析のプロセスが重く、後回しに
    • 再発防止策まで至らない
    • ChatGPT にサマリを作らせる
  • AI + インシデントマネジメントの相性は良さそう
    • 解決方法の提案までやってくれれば・・・

チーム開発における様々なボトルネックの整理 / id:stefafafan さん

  • 改善サイクルが回っていない ( 効率の悪い仕事の仕方が続いている )
    • アジャイルを取り入れる
    • Incremental, Iterative: 少しずつ着実に進める
    • Scrum ソフトウェア開発以外にも使える
  • 開発速度が遅い
    • Four Keys: デプロイ頻度、変更のリードタイム、変更障害率、サービス復元時間
    • すべての指標を満たす必要がある
    • Extreme Programming: 小さい単位（レビューも楽）、ペアプロ、テスト
    • DevOps: インフラ要件をプロジェクトで管理, CI/CD, Infrastructure as Code, オーナーシップ
  • チーム内の連携
    • HRT ( 謙虚、尊敬、信頼 ) の欠如: コードレビューが辛い、発言できない
    • チームの自己組織化:
      • エラスティックリーダーシップ: サバイバル、学習、自己組織化
  • チーム外との連携
    • Team Topologies: 他のチームとの関わりを図に
      • リリースなどで他のチームの許可が必要など
  • ボトルネックの整理
    • スコープによる整理
      • エンジニア、デザイナー。企画～リリース。同部署、会社。
    • カテゴリ別の整理
      • テクニカル、プロセス、人間関係
    • マトリクス化する
      • エンジニア+デジアナー✕テクニカル
      • App エンジニア + SRE ✕プロセス
      • 会社のエンジニア組織✕メンバーの成長
  • まとめ
    • チーム開発のボトルネック
    • スコープ✕カテゴリで分類し、どこから手を付けるか考える

NOT A HOTEL - AI コンシェルジュ 「Kevin」 の開発秘話 / codehex さん

  • zendesk の話から急遽変更して chat GPT の話
  • HOT A HOTEL: 別荘兼ホテル。家を相互利用できる世界に
  • Kevin: chat bot。 お客様に 24 時間対応する
    • 「テスラを使いたい」
    • CS 対応の勤務時間の制限
  • AI ができること
    • 情報の提案
    • 料理や清掃のオペレーション
  • Sunshine Conversation
    • メッセージングプラットフォーム
    • Switchboard: 人と bot の切替
    • Pass control: bot と人、どちらなのかの判断
  • Dialogflow CX
    • CS (Zendesk) と GPT を切り分ける
    • 雑談などは GPT
    • GCP 上の AI 開発プラットフォーム
    • 会話のコンテキストを保持できる。構造化されたデータに変更
      • 後続の処理は、会話のコンテキストを引き継げる
  • GPT-3.5, GPT-4, LangChain
    • OpenAI の API (Chat Completion)
      • 安い、速い
    • Dialogflow CX で拾えない部分（雑談、観光地の情報提供）
  • LangChain
    • LLM (Large Language Model) との組み合わせ
    • ReAct: 推論 + 行動。 Thought, Act, Obs
  • zero-shot-react-description
    • ほとんど成功しない、遅い。 2.5 分
    • サポートに問い合わせてもまともに返ってこない
  • Document Question Answering
    • google の検索結果は使えなかったからはずした
    • DB の類似検索に絞る
    • ドキュメントの内容を OpenAI に要約させる
    • エラーはなくなった。レスポンスは 50s 。 DB に登録された内容なら回答可能
  • Map Reduce アルゴリズム
    • 並列のはずが直列で・・・
    • 件数を減らせばいいという結論（直列なので）
    • 30sec くらいで返せるように
  • 今後の展望
    • Dialogflow CX: フローが複雑なので整理
    • GPT: データを増やす（現状 4000 件 ）
    • OpenAI が遅い問題→キャッシュ
  • このために Python を勉強した
  • スライドの構成は ChatGPT にお願いした

try { Support Engineer } catch($e) { joy, pride, and prospect } / Kensuke Nagae さん

  • 「ソフトウェアエンジニアからサポートエンジニアにジョブチェンジしてみた」
  • サポートエンジニアの情報が少ない、 Perl プログラマの平均年齢が高い

  • サポートエンジニア

    • 自社製品。技術的な問い合わせ
    • 製品について、トラブル対応、開発チームへ
    • ドキュメント、（まれに）機能開発や修正

  • 問い合わせ対応が 8 割。うち、トラブル対応が 7 割

    • 「書く」より「読む」
    • ドキュメント（公開、社内）、過去の事例、ソースコード
  • 面白いところ
    • 問題解決: 具体的で解決する必要がある問題、謎解き
    • 問題のスコープが広い
    • 1～2週間で PDCA を回せる。似たような問題が来る（しかも、すぐに）
      • 開発職ではあまりない
  • しんどさ
    • 顧客対応については自明なので割愛
    • reactive ( 問題が起きてから対応 )。予防できない。マイナスから始まり、 0 で終わる
    • 作れない: 開発の優先順位に手を出せない。お客様の希望に添えない
    • 小さい締切 ( 初期応答時間 ) : 毎日、小さなプレッシャー。難しい問い合わせが複数積まれたとき
  • 向いてる人
    • 問題解決が好き: トラブルシューティングだけでなく、疑問を解決する
    • 意思疎通（社交的である必要はない）: 意思疎通により問題を浮き彫りにし、解決に導く
    • 締切のプレッシャーに強い: 障害対応になると燃える ( 短期集中 )、逆に締め切りを無視する胆力

ネコトーストラボ杯争奪 東西対抗 LTマッチ

「これが３年ぶりのドラですよ」

開幕LT / ネコトーストラボさん

  • 光る棒がノベルティに入ってます
  • バトルからマッチに
    • Try Catch == 東西マッチ
  • NEW: Nekotoastlab East West
  • Try Catch == お題なし
  • if (New lt match) : Perl は LT フレンドリー
  • 綱引きのイメージ
  • Try Catch == 勝敗どっち

GraphQL やるなら DataLoader を使おう / gari8 さん

  • GraphQL サーバサイドへクエリ。型
  • N+1 問題が発生
  • JOIN で解決しようとしたが。必要のないときも JOIN
  • スロークエリとコードの可読性の低下
  • Dataloader バッチ処理
  • 親タイプの処理→子タイプからKeyを集積 (dataloaderのお仕事)→Keyに基づいて処理

Slack からクロネコで送ろう / こたまご a.k.a. ひなたん さん

  • 「 Perl は小さい頃にちょっと」
  • 社員間で宅急便
  • 住所がわからん。営業所止め
  • Slack で宅急便。ヤマトさんと
  • ワークスペース単位で申込み可
  • Slack 3秒ルール→非同期処理 (Django + Celery, Redis, TiDB)
  • 月額費用はただ。ヤマトさんより安い

AstroNvimを使おう！ / _ybrliiu さん

  • vim: キーボードで操作が完結、作業が高速、プラグイン
  • 学習コストは高い、環境構築が大変
  • Neovim: vim 派生。 luaでも書ける
  • AstroNvim: Neovim のもろもろをまとめたパッケージ
  • セットアップが簡単、ヘルプが充実
  • :Lspinstall
  • F7 でターミナル表示
  • 放置するとヘルプが出る
  • ゴーン

Perl初心者が社内Perlエンジニアのレビューを受けてみて / minto さん

  • 社内で利用。移動があると便利
  • 明日のゴミを Slack に通知する bot
  • 鎌倉市のゴミ情報をパース
  • use lib use lib/....pm ではなく -Ilib を
  • 配列のから判定は $#x < 0 ではなく @x == 0 で
  • サブルーチンの返り値はスカラ（ %x ではなく \%x ）
  • サブルーチン引数を @_ を使わない
  • shift ではなく my (undef, $x) =

Masahiro Honma さん

https://docs.google.com/viewer?url=https://github.com/hiratara/YAPCKyoto2023LT/raw/master/slides-export.pdf

スポンサーブース担当レベル1からの足跡 / honchang さん

  • 入社３日目で RubyKaigi
  • 伊勢神宮をイメージして鳥居を
  • 社名をたくさんつけた
  • ノベルティ全部持ってった（統一性がない）
  • ぼっち: ノベルティを取りに、ホテルでミーティング、結婚式（！）
    • 次からはシフトを

自然言語処理とWebアプリ・文字コード / Shunsuke Tsuchiya さん

Railsエンジニアがフロントエンド分離に挑戦してみた / mikikun14 さん

  • フロントエンドをやることになった
  • React, Vue は触ったことがあった
  • 課題を早くこなすことにフォーカス、すぐ助けてもらう、雑でも速く
  • 意思決定の理由を理解するように
  • 理解できないことを放置しない。質問できる雰囲気を。プライドが邪魔にならないよう
  • 自己紹介でハードルを下げておく

Something NEW / myfinder さん

  • yapcramen を忘れずに

  • 会社を作った
    • Eric Sink マイクロISV
    • 4 期目、黒字
  • 数の暴力との戦い
    • 一人
    • オートスケールは無意味
  • クローズドソースプロダクト
  • ChatGPT で解決できそうなお仕事を募集中

Something New / arthur-1 さん

  • 新卒１年目が顔を売るためにやったこと 100 連発
  • 出社エントリ
  • 深夜バスで出社
  • ツッコミどころ
  • 社員に喧嘩を売る
  • 先輩の腕をつかんで二次会へ
  • 二日酔いの直し方　飲めば１日酔いになる
  • Slack 投稿数 40/日 ジョーク、反応、業務連絡は 20%
  • 思っていることを社内エントリに
  • いろいろな会に顔を出す
  • 細かいネタ
  • 他人と会話、柔軟な働き方「忙しそうなので代わりにやりましょか？」
  • 夢を語る
  • ユーザからの問い合わせに反応
    • CREs との協業のチャンス

TypeScript + Express + Prisma + Node.js API開発 / 秋田 尚輝 さん

  • Perl について「飛ばします」
  • TypeScript 静的型付け
  • Prisma: ORM
  • Express「飛ばします」
  • レイヤードアーキテクチャ。個々のコード量を抑えられる。開発しやすい
  • コーディング技術も大事だが、設計者の意図を汲むこと
  • ChatGPT + GItHub Copilot があればコーディング技術は・・・
  • 難しいことを簡単に。開発速度を上げる

結果発表

  • 西MVP: honchangさん
  • 東MVP: 秋田さん
    • 賞品: 和菓子通販品
  • 勝利チームは西チーム
    • 賞品: ネコの足形グラス

明日は 9 時からオープニングです。 (9 時前に来ること！ )

Tokyo Cabinetのデータベースタイプの誤り

Fundamental Specifications of Tokyo Cabinet Version 1 (Japanese)

データベースタイプ ハッシュ表（0x01）かB+木（0x02）か固定長（0x03）かテーブル（0x04）

ドキュメントのこの記述、間違えている。 tcutil.h に、

enum {                                   /* enumeration for database type */
  TCDBTHASH,                             /* hash table */
  TCDBTBTREE,                            /* B+ tree */
  TCDBTFIXED,                            /* fixed-length */
  TCDBTTABLE                             /* table */
};

と定義されているので、正しくは、「ハッシュ表（0x00）かB+木（0x01）か固定長（0x02）かテーブル（0x03）」である。

致命的過ぎる記述ミスな気がするけど、誰もファイルフォーマットなんて気にしていないということかな。

Redis::Fastのコードリーディングのメモ

Redis::Fast のコードをちょろっと読んだので、自分用のメモ。

  • hiredis 側には adapters/poll.h というものが用意されているが、自前実装している
  • wait_all_responses と wait_one_response はまったく同じ実装である
  • wait_*_responses を呼んだときのみ redisAsyncHandleWrite するので、 POD にあるような Redis がコマンドを処理する間に long_computation(); をするような使い方はできない
  • poll.h の redisPollTick に相当するメソッドがあればイベントループを回しながら別のことをできる気もするが、用意されていなさそう

父が亡くなった

1 月 11 日に父が 69 歳で亡くなった。 2020 年 8 月 3 日に動脈瘤が破裂して救急搬送され、 2021 年 10 月 17 日に再度破裂して再手術、そして、三度動脈瘤が大きくなったため年始から手術に臨んでいたのだが、難度の高い手術で予定を大幅に上回る 15 時間もかかってしまい、その後血圧が安定することはなかった。

正直に言うと、自分のショックはそこまで大きくはない。最初に倒れてからは、常に万が一の事を考えて後悔がないように行動していたし、今回の手術に関しても医者の説明などを聞いていると相当な難易度であることは想像できた。かと言って、 2 度破裂していることを考えると 3 度目も破裂すると考えるべきで、どんな難易度でも手術は受けるしかなかったわけだ。恐らく父も同じ考えで、年末年始にかけて色々と LINE が来ていた。自分で取り寄せた魚介を捌いて丼を作り、「包丁を握るのもこれが最後だな」と LINE もくれていた。父はもともと水産加工の会社を経営していたのだが、今でも衰えない見事な包丁裁きだった。

そんなわけで、自分の気持ちの整理はついた状態で帰省して母と葬儀の準備にあたったわけだが、話をしながら母は手術を勧めたことを後悔していること、そのせいで気持ちの整理がついていないことがわかってきた。そもそも離れて暮らしていた自分と違って父とずっと暮らしていたわけで、ショックが大きいのは当たり前ではある。いつも笑顔を絶やさない母で、今回も気丈に振る舞ってはいたが、会話の節々で辛さを感じられた。帰省中は他愛のない会話をたくさんして、少しでも悲しみを忘れられるように努めたつもりだが、それが正しかったのは今となってはわからない。もしかすると、共に悲しむ時間も必要だったかもしれない。

葬儀については、父が生前にばっちりと準備していてくれたお陰で、滞りなく終わらせることができた。ほとんどの作業は葬儀屋がやってくれたが、父が亡くなってから葬儀屋を探したり葬儀の段取りを決めたりするのはほぼ無理ゲーで（それでもやるしかないのだが）、生前にきちんと用意しておくことは大事なことだなあと思った。初めて親族として葬儀に関わって、ちょっと不謹慎かもしれないが、葬儀という儀式は大切なものだと感じた。父の遺体に向き合って線香をあげると、ザワザワする心が少し落ち着いた。故人の今までの温情に感謝するとともに、遺族がこれからを生きるための心の準備をするために、葬儀という儀式は大切だ。

よく言われることだが、葬儀でいろんな親戚と会うことができたのも良かった。どうせなら生前に揃ったほうが・・・と思うのは山々だが、これは誰の葬儀でも言えることなので、仕方がないことだろう。故人についていろんな話をするにつれ、全く知らなかった父や親戚の人生についても多少は知る機会となった。

昔から、両親が死んだらどうなってしまうのだろうという漠然とした不安を持っていたが、葬儀が終わってみると、特にどうにかなるものではなかった。葬儀はあっという間に終わるし、その後の自分の生活は今まで通りに続いていく。ただ、そこに父がいないだけだ。人間はいつか必ず死ぬものなので、死を過度に恐れる必要も忌み嫌う必要もない。ただ、生きている間は、自分の人生と、身の回りで支えてくれる人々の人生を、大切にしたいなあと感じた。

最後に、父について遺しておこう。父は裕福ではなかったし学歴があるわけでもなかったが、賢い人間だったと思う。浜の人間らしい荒々しいところはあったが、しっかりと考えて行動し、自分が決めたルールは絶対に破らないという強い意思も持ち合わせていた。毎日大量の魚を捌きながら、夜は遅くまで六法全書で法律を学んでいる父を見て子供心にすごい人だなと思っていたし、あれだけ毎日何本も吸っていたタバコをきっぱりと辞めた精神力にも感服した。独裁者のような絶対的な厳しさを持つ父だったが、それは家族を心底愛していたからこそできることだろう。その証拠に、父のことは今でもとても尊敬している。良い父だった。心から冥福を祈っている。

2022年に買ってよかったもの

結論から言うと、 brompton である。 今年の 2 月末に買ったもの だが、今でも使い続けている。

以下のグラフを見て欲しい。 2014 年から何をやっても下がらなかった体重が、コロナ禍で最盛期 77Kg まで上昇したが、 brompton を買っただけであっという間に 10Kg 以上下がっている。

bromptonによる体重の推移

brompton の良い点

brompton の良い点などはすでに以下のエントリで書いているので、それから約 10 ヶ月が経ってアップデートがあったことを書いておく。

自転車を買った - 北海道苫小牧市出身の初老PGが書くブログ

使うか使わないかよくわからなくても常に持ち歩こうと思っていた 持ち歩きは買った直後に諦めた

実は、あれから常に持ち歩いている。もう少し正確に言うと、常に自転車で移動をしている。電車に乗ろうとするから持ち歩きが大変なのであって、自転車のまま持ち歩くのであればなんの問題もない。コロナ禍で遠出をすることも減ったため、自転車をメインの移動手段として使うという選択は、今のところとてもうまく機能している。

自分もこの一ヶ月で 400km 近く走って体重も 1kg ほど落ちた

お陰で走行距離は順調に伸びて、今では月に 800Km 程度は自転車で走っている。単純平均で 1 日 25Km 走っていることになる。ただし、体力的には余裕がある距離ではあるのだが、時間的には毎日 1.5 時間ほどとなかなか負担となる時間がかかっているので、これをずっと続けるのは難しいのかなとも思うのが正直なところである。無理しない程度に、とは言え、時間が取れるのであれば続けていきたい。

それでも週末は輪行を楽しんでいる

輪行はほぼしなくなった。電車に乗ると走行距離が稼げなくて勿体ないと感じてしまう。それでも輪行は brompton のとても良い点であり、長距離を走るときの保険として大変頼りになる。最近も、めんどくさいから何も考えずにとりあえず半日走り続けて、夜になったから輪行で帰るというのをやったばかり。綿密なプランを立てなくても気軽にめちゃくちゃ遠くまで行ってしまえるのは、本当に楽である。

行ったところ

brompton を買ってから色んなところに行った。

駒沢オリンピック公園。

コーエーテクモ新本社（みなとみらい）。

東京タワー。

ズーラシア。

境川。

ヤングボール（柏市）。

ディズニーリゾート。

霞ヶ浦。

久里浜港。

強いて言えば、最近困っているのは、長距離は走りたいし同じ道は飽きるけど、行きたい目的地が特にないということである。

メンテ

自転車のメンテに関しては、毎日の空気入れと、 2 週に 1 回のチェーン清掃だけは覚えて自分でやっている。それ以外は、 3 ヶ月に一度自転車屋に行って、すべて基本的に丸投げである。 7,000Km 以上走ってチェーンも伸び切ってしまったらしく、それも自転車屋に交換してもらった。この後、ブレーキのシューとタイヤの交換ですねと言われている。面倒な整備をプロに診てもらえるのは大変ありがたい。

一応、工具セットは買ったのだが、数回しか開けていない。フレームに傷がついたとき用にタッチアップペイントも買ってあり、こちらはいざという時の心の安泰のために便利である。

夏

夏の自転車は汗との勝負である。普通の服装では着衣水泳の後のようにびしょびしょになってしまうので、ユニクロで発汗性のめちゃくちゃ高い服を下着から含めて買い揃えた。また、目的地で汗を拭くのも普通のハンカチでは完全に役者不足なので、セームタオルを買った。セームの良いところは、汗を大量に取れるだけではなく、それを水道で洗うだけで簡単にもとの吸水力を取り戻せることである。普通のハンカチやスポーツタオルは乾燥した状態で使うものなので、行きで使ってしまうと帰りでは使えないという自体に陥ってしまう。

後、当然だが吸水にはめちゃくちゃ気を使った。保冷用の水筒を持ち歩いた上で、コンビニ・自販機をフル活用して常に水は切らさないようにした。お陰で熱中症には一度もならずに夏を越せた。

もう一点忘れていた。日焼けがえげつない事になるので、基本的には半袖ではなくアームカバーをずっとして走っていた。それでも腕は真っ黒になるレベルで日焼けする。

冬

夏が終われば冬が来る。 11 月後半までは、冬のほうが楽だなあと余裕たっぷりだった。 10 度以上あれば、半袖に薄手のジャケットを羽織るだけでも十分過ごせる。ただ、自転車をどんなに漕いでいても手はめちゃくちゃ冷えるので、手袋は早めに用意したほうがいい。それでも、夏よりも装備は不要で余裕があった。

しかし、 12 月の半ばを過ぎて気温が 5 度以下になってくると、本格的に寒さと戦う必要が出てくる。防風だけの手袋では寒さを防ぎきれず、防寒手袋も買う羽目になった。それでも、手指は冷えて痛くなる。顔、耳に関しては、 モンベルでバラクラバ を買った。こちらはものすごく薄くて、初めは寒さを防げるか半信半疑だったのだが、恐ろしいほどの防寒性を発揮しており、バラクラバ１つだけで全く寒さを感じていない。これはとてもおすすめである。

と、 5 度前後になってくると寒さをきついとは感じるのだが、上半身は薄手のウインドブレーカー一枚着ただけでも汗ばんでしまう。もちろん、自転車を漕いでないときは寒いので、夏と違って服装の選択がとてもむずかしいと感じている。

事故

最後に、自転車で避けられない話題として交通事故がある。今年だけでも、自転車に乗っている人の事故をかなりの件数耳にした。さらに、うちの子も落車して左肘を骨折している。 自転車は危険な乗り物である。

危険だからこそ、事故に遭う確率は下げて置かなければならない。当たり前のことだが、赤信号、一時停止、二段階右折などの交通ルールはしっかり守ることが大切である。日本では交通ルールを守っている自転車はほとんどおらず、赤信号や一時停止、踏切で停車すると後ろを走る自転車に「あぶねーだろ！！」と怒鳴られたり、ひどいときは衝突されたりする。それでも、自分の命には変えられないので、誰も守っていなくても、自分だけは交通ルールは遵守すべきであると感じる。

ヘルメットは常に着用し、また、夜の運転のために ブルベ用の反射ベスト を持ち歩いている。テールライトを装着し、昼間でも車に気がついてもらいやすいように ライトを点滅 させている。高速走行中の手信号は危ないと思うこともあるが、基本的には車に自分の意志を知ってもらえたほうが安全なのでなるべくサインを出すようにしている。特に、駐車されている車を抜くときの右への車線変更時の手信号は、とても重要である。

このように、事故に遭う確率を下げられることは、なんでもするべきである。

まとめ

今年は brompton に乗ったおかげで、何の苦もなく 10Kg 以上痩せられた。とても高かったが、結果的に良い買い物をしたと思う。

古いrustを新しいMacで動かす

全部 https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20How.20can.20I.20fix.20Rust.201.2E53.2E0.20or.20earlier.20to.20run.20on.20macOS.2012.2E6.3F/near/299263887 に書いてあった。

一応 TL;DR のためにまとめておくと、最近の Mac の環境 ( CommandLine Tool for Xcode 14.0 ?) で Rust 1.53 以前を使おうとすると、 ld: in ... .rlib(lib.rmeta), archive member 'lib.rmeta' with length ... is not mach-o or llvm bitcode file というメッセージが出てリンカが動かないという現象。リンク先も 9 月のやりとりなので、おそらく 2022 年の秋頃から起きている。

現状これを回避するには新しい Rust を使えばよいが、どうしても古い Rust を使いたい人のためのワークアラウンドとして別のリンカを使う方法があり、 brew install mold した後に、対象プロジェクトに .cargo/config.toml ファイルを作り、

[target.x86_64-apple-darwin]
linker = "/usr/bin/clang"
rustflags = ["-C", "link-arg=--ld-path=/usr/local/bin/ld64.mold"]

と書くと ld を使わないのでこの問題を回避できる。

なお、 VSCode で rust-analyzer を使うことまでやりたいのであれば、以下のエントリも大いに役立つであろう。

zenn.dev