今日は Rust.Tokyo 2023 の日です

Rust.Tokyo 2023 のために、かなり久々にメルカリさんに来ています。以下は自分のためのメモです。

オープニング

• 会場紹介
  • 入館証は退館時も必要
  • 18F から出ると戻れないので、出ない
  • 自販機無料
• ハッシュタグは #RustTokyo2023
• 2019 年から開催、 2 回目のオフライン開催
• オフラインで登壇者、参加者の相互交流を目指す
• オンラインのメリットも活かしたい

IoTプラットフォーム開発におけるRustの活用 / @garasubo さん

• Actcast
  • エッジ AI デバイス ( ラズパイ ) を管理
  • 指定されたAI アプリを動かす
  • WEB UI 経由
  • クライアント、 Device API 、 WEB UI が Rust
• 2017 年に導入
  • 高速、軽量、型システム、マルチスレッド
  • ファームウェアのバグは避けたい
• 使い始めてから今までで、 Rust のエコシステムが大きく変わった
  • async/await 、 anyhow/thiserror 、 サードパーティー
• 初期リリースはスレッド
  • その後、徐々に async/await 化
  • blocking クレートの利用
  • async/await は伝搬する → 変更料が多く、難しい
  • tokio/futures/blocking 非同期ランタイムの混在
  • tokio ランタイム前提の関数は tokio ランタイム内で呼び出す必要がある
• エラー型は failure を実装していた
  • メンテナンス中止になり anyhow/thiserror へ変更
  • std の Error トレイとも改善され、使い勝手が良くなった
  • sentry エラー報告ツール、ボイラープレートの現象
  • failure のエラー型のバリアントが 50 以上あった（！）
  • failure を前提としたエラー処理
  • 部分的な置き換え → 新たな小さいエラー型を、旧エラー型に変換
• ライブラリの変化
  • rusoto から aws-sdk （非公式から公式へ）
  • メンテナンス中止、破壊的変更が入ってくる
  • actix のメンテナがレポジトリ全消去した、など
• Rust の型システムはメモリーリークは容認する
  • std::mem::forget 、std::rc::Rc 、 join しない thread
• tokio::select! で終了しない thread があると、どんどんリークしていく
  • ユニットテスト、結合テスト、テスト環境で長期間のテスト
  • CPU使用率、メモリ使用率、ログの分析
  • リファクタリング
• CI/CD の時間が長くなる
  • ビルドキャッシュ (sccache, Swatinem/rust-cache) 、 cargo build-timings、 cargo nextest でテストケースの実行時間を計測
• ビルトインの名前の乱用
  • 例: std::sync::Mutex と tokio::sync::Mutex
  • フルパスの利用、 rename
• Q). async/await は導入する価値がある？
  • A). 書きやすい。 async/await 前提のライブラリも多い
• Q). メモリリークの原因を見つけるには？
  • A). 問題が起きた→変更の差分から
  • Q). プロファイラなどでうまく行った例は？
  • A). 今回の例はエッジデバイスでプロファイラは利用不可だった。 AWS 環境であれば、監視で見つかることはある
  • A). Rust ではなく IoT ならではの問題。ブラウザで動く JS とかも同じでしょう
• Q). no_std ？
  • A). std 。 AI アプリのほうが大きいので、 std を削っても微妙
  • A). そもそもラズパイなので強力
• Q). mem::forget は使う？
  • A). 使ったことがない。いつ使うのでしょう
• Q). ラズパイ環境の難しさは？ライブラリに制限が入る？
  • A). 特にない。強いて言えばデバイスドライバ周り？

かにさんタワーバトル / @sadnessOjisan さん

• 日経電子版
  • fastly → Vessel
  • リポジトリが全て別れており、 CDN でアグリゲート
  • 24 の micro service が Node.js v12 で動いていた
  • 11 ヶ月で v20 まで上げた
• Node.js はリリースサイクルが早い
  • npm のビルドが通らなくなる
  • アップデートの度に時間がかかる
• 比較的、安定しているものの技術スタックを変更
  • Node.js VS Golang VS Rust
  • Rust が要件をすべて満たしていそう
• 社内に Rust 採用事例があった
  • Fastly の Computing@Edge
  • Wave BFF サーバー
• Rust は batteries-included ではない
  • 依存が多い。 3rd party ecosystem の心配
  • デファクトであれば、採用してもいいのでは
• Axum
  • HTTP server フレームワーク
  • Hyper と Tower ベース
  • Hyper はプリミティブすぎる HTTP Server
  • Tower は Request を受けて Response を返す関数
  • Services をレイヤによって重ねる
  • Axum は Hyper/Tower のごく薄いラッパ
• Axum は 3rd party のアプリだが、採用して大丈夫か
  • 密結合を防ぐ
  • 依存を限定する
  • 横断的関心事は Tower のレイヤに押し込む
  • 例えば、 Axum が使えなくなったら Hyper を直接使える
• Q). Rust 採用にあたり CTO をどう説得した？
  • A). CTO はいない。合議制。小さいところからやっているため
• Q). 教育コスト、導入コストは？
  • A). 書ける人、書きたい人が少なかった。書きたい人の熱量で開発している。 E2E テストは充実させている
• Q). DI は？
  • A). コンストラクタインジェクション一択。ライブラリは使っていない

csbindgenによるC# x Rust FFI実践事例 / @neuecc さん

• Cy#
  • C# の会社
  • OSS 開発
  • ゲーム開発、全部 C# でやる。 C# monorepo
• C# を使いたいが、 Android NDK ネイティブ API は C++ しか書けない
  • C++ のクロスプラットフォームビルドの厳しさ
  • Pure C# への移植もコスパが悪い
• Rust エコシステムが充実
  • cargo build 、 cc/cmake との連携、 bindgen
  • 難しいから選択肢に上がっていなかったが、やってみると罠は少ない
• csbindgen
  • Rust → C#
  • C → Rust → C#
  • ブラックボックスのないバインディング（ Rust と 1-1 ）
• Rust は unsafe まみれのコードになるが、そこはケアしない
  • Rust/C# の境界を繋いでいるのは、超危険な C なので、自然
  • 外側の Rust/C# できれいな安全な世界を作る
• 型システムは Rust/C# でほぼ 1-1
• MagicPhysX
  • physx-rs を使ったバインディング
  • C++/Rust の bindgen はなかなかうまく行かない
  • physx-rs は C++ → C API → Rust (Youtube に講演が上がってる)
• YetAnotherHttpHandler
  • hyper と Rustls を使った実装を C# バインディング
  • Pure C# で書くのは大変
• NativeCompressions
  • LZ4 / Zstandard が多い
  • C# binding を書いてもいいが、バージョン追随が厳しい
  • native binding が良い選択
• Q). serde と C# のシリアライザの比較
  • A). 自作のもののほうが良いが、汎用性を持たせると Rust の良さが出ないのでは
  • A). シリアライザ作成者目線として、 serde はもっとパフォーマンス挙げられそう
• Q). テストは？
  • A). ノーテストライブラリ。生成を流しているので
  • Q). binding を使った場合にどこをテストする？
  • A). C# 側でテストをすれば十分でしょう。 E2E
• Q). C# - Rust - C のオーバヘッドは無視できる？
  • A). コンパイラオプションで消し飛ばせそうだが、試していない
  • A). Rust のリンカのオプション
• Q). unsafe 塗れなら Zig のほうがいいのでは
  • A). Rust の開発環境は素晴らしい。安定もしている
• Q). ref out in の対応は？
  • A). しません。
• Q). C++/CLI は選択肢に上がらない？
  • A). 上がりません
• Q). C# er が多いが、 Rust への取り込みは？
  • A). 第二の言語として、キャッチアップしている。使っていく、広めていく

素材メーカーが内製開発でRustを使っている話 / AGC株式会社

• Rust のチームの立ち上げ
• 半分はガラス、半分はケミカル
• データサイエンス → プロダクトの内製開発
  • データサイエンス Python
  • 数理最適化 Rust
  • ソフトウェア・エンジニアリング Rust, OSS 活用
• データサイエンティストはにわかプログラマ
  • 現場で彼らの Python コードが動くのは考えにくい
  • Python の弱点を補う言語
  • データサイエンス組織からソフトウェア組織へ
• データサイエンスを、事業に活かしていくためのエンジニアリング
  • AutoML 、 製造プロセスの改善
  • バックエンドサーバで GraphQL のサーバが Rust 製
  • actix-web + async-graphql, sqlx
  • MLflow とのやり取りは自作（Python はクライアントがある）
• 技術選定
  • SNS、ブログ、実際に使う
  • juniper VS async-graphql, sqlx VS Diesel
• Rust 歴は半～ 1 年ちょっとのチーム
  • Python はみんな書ける
• 環境構築、プロジェクト管理は楽
  • Python は pyenv+Poetry VS Anaconda
• コンパイラが信頼できる、型システム、エラー処理
  • Clippy が優秀
  • Python コードの品質も上がる（型ヒント、イミュータブル）
• 困った点
  • 学習コストは高い
  • ビルドが長い（集中力が切れる）
  • お手本となるソフトウェアエンジニアがいない (We are hiring)
• Cargo ワークスペース
  • Orphan rule でパズルが発生
  • newtype パターンでコード量が増えた → 元の構造に戻った
  • 任意のスキーマを持つテーブルデータ → match 文が複雑に
• The Rust Programming Language の輪読会
  • Rust 経験者が 1 名から 10 名に
• 問題解決力を鍛える！アルゴリズムとデータ構造
  • 複数チームでの交流
• Rust という本を大量購入
  • Rust が流行っていると思わせる、印象操作
• 今後はイベント参加、 OSS 公開など
• Q). マイグレーションはどうしていますか？
  • A). sqlx CLI を使っている。 gitlab の CI/CD から本番へ
• Q). PyO3 は使っていますか
  • A). やったことはある。運用はしていない
• Q). 高級言語からシステム寄りの言語へどうアプローチ？
  • A). 勉強会。覚えのある人を中心に教わる
• Q). Bazel でビルド時間を削減できる？
  • A). 高性能 PC 。リンカで mold 。分散ビルドはまだしていない
• Q). データサイエンスは Python だろうが、 Rust へ移行して困ったことは？
  • A). Apache arrow 。全言語でのデータフレーム。困らないだろう
• Q). mojo を使う可能性は
  • A). 試す可能性はある

Rustがユニークビジョンにもたらした恩恵と苦労 / ユニークビジョン株式会社

• 2016 年。Twitter の帳票出力で利用（ほかは Ruby）
• 2018 年、 LINE 系で Rust
• その後、他のプロダクトでも Rust を利用
• 2023 年には、 Rust のコードが増えている
• 14 万件の CSV のダウンロードが Ruby では厳しかったため
  • Rust でうまく行った。 15 分程度
• 大量データ登録、高頻度のバッチなどで Rust の利用
• LINE は Twitter の 3 倍の負荷に耐えられるように
  • Rust 、 actix-web を利用
• SNS の情報クロールなどで、 Rust
• 1 秒以内にレスポンスを返す必要がある WEB hook
• コンパイラ、 cargo 、 clippy が優秀
  • 言語としても、面白そう
• Rust によって採用も増える
• Rust での苦労
  • clone() まつり
  • デプロイ後に動的に調整したい
  • crate 不足
• Rust の取り組み
  • Slack のチャネル、社外勉強会、スポンサー、 crate の作成
• twapi
  • 既存のものは API 不足
  • URL エンコードのバグ
  • Twitter API を長く使ってきた経験を生かした
  • twapi-reqwest
  • twapi-v2 ( serde の flatten によって、 API が勝手にフィールドを返してくることに対応)
• actix-daemon-utils
  • actor をループでやり取り、グレースフルに再起動
• csv-zip-maker, dynamodb-mutex, redis-batches, era-jp
• Q). 他の経営陣を説得した？
  • A). 最初は Rust じゃないと動かなかったので。一度入れば使っていける。新しいから採用でもいいなど
• Q). Ruby に比べて実行時エラーが減ったりした？
  • A). typo はなくなった。
• Q). clone を解消したら速くなる？
  • A). そんなに変わらない。そもそも速い
• Q). OSS 公開に工数がかかるのでは？
  • A). そんなにない。ドキュメントくらい
• Q). 買収後の Twitter API の苦労は？
  • A). どんどん API が変わるようになったのはつらい
• Q). Ruby から Rust への学習コストは？
  • A). 個人で書いているうちは大丈夫。他のメンバーには難しい。ドキュメントを読んだり、 Slack を使ったり
• Q). 既存のライブラリを改善せずに書き直したのは？
  • A). スピード感がなかった。自分たちのほうが詳しいという自負があった

並行キャッシュライブラリの開発で得られた知見 / @tatsuya6502 さん

• キャッシュ : 低速のメディアから取得したデータを高速のメディアに保存
  • インメモリキャッシュ : 容量制限付きの hash map
• Moka
  • Java の Caffeine キャッシュを参考（作者公認）
  • crates.io Sentry.io のバックエンドサービスで使用
• future 版と sync 版がある
• max_capacity time_to_live
• or_try_insert_with : 無ければ async ブロックを実行する
• キャッシュの評価指標は、ヒット率
  • ポリシーで決まる。使われなさそうなものを削除
  • Caffeine simulator で測定できる
  • 本番の検索エンジンのディスクアクセスパターンを記録した、公開データを利用
  • Moka は Tiny LFU / LRU よりヒット率が高い
• LRU の前に LFU Filter が入っている
  • 使用頻度の低いデータの入場を拒否
• ロック競合
  • Moka は並行キャッシュ
  • スレッドをたくさん用意しても、動かない
  • チャネルによってキャッシュアクセスをまとめて、ロックは誰かが代表して行う
• Lock free : compare and Swap 命令などを使う。ロックしない
  • Moka では、自前で実装した並行ハッシュテーブル cht で利用
  • LFU フィルタなどの他のデータ構造は、 mutex と一括適用を利用
• ロック実装に future 対応と未対応があるので注意
  • 最悪、デッドロックする
• async を値渡ししたときの振る舞い
  • 容量が 7 倍になって返ってくる（！）
  • コンパイラ側の最適化で、複数コピーされるため
  • 値渡しではなく Box<Pin> を利用するというワークアラウンド
• 非同期キャンセルは大変
  • .await の途中で poll を辞めて future 毎 drop できる → キャンセル
  • WEB app などでは、接続が切られたらキャンセルすれば便利
  • アプリ側が対応しないと、不整合な状態が起きる
  • Drop trait を利用するのがいい
  • spawn すると、キャンセルの影響を受けない
• Moka には特定のランタイムがないので、 spawn ができない
  • Shared トレイトで共有しておいて、リトライ
  • リトライ自体がキャンセルされることもある
• 今後の展望
  • wasm 対応（シングルスレッド）
  • snapshot から復元
• Q). atomic 命令はインラインアセンブラ？ CPU 毎に記述？
  • A). llvm が CPU の命令を抽象化している。標準ライブラリがそれをラップしている。 crossbeam クレート
• Q). stale while revalidate 機能は？
  • A). ない。アプリ側でロジックを書く
• Q). read が多いのに RwLock ではなく mutex なのは？
  • A). 内部のデータ構造は get されたときに write が必要。内部的にはほとんどの操作が write を伴う

Rust 業務経験がない開発者で集まって汎用ツールを開発した話 / kajiwara さん

• Roggol
  • イベントソーシング。 RMU (Read Model Updater)
  • 専用の RMU を実装していたが、すべて同じようなことをしている
  • 取得、加工、格納、オフセットの保存
  • 同じイベントデータストアから、重複なしで各プロセスがデータを取る
  • 設定ファイルによる実行 → 再コンパイル不要
  • OSS 公開を目指す
• チーム
  • Rust 経験者なし、 Rust 愛は高め
  • 2022/02 から現在も
  • Rust VS Golang VS Scala → 横に並べて実行したいので必要なリソース量の少ない Rust
• 想定通り
  • コンパイラ、 clippy に怒られる
  • 実行が速い、サイズが小さい
  • 社内の Rust 採用の後押し
  • ポジティブなことは巷で言われている通り
• 想定外
  • Rust への抵抗は少ない
  • コンパイルはそんなに遅くない（個人の感想）
  • 学習環境の充実 the book, Rust By Example, Rust API Guidelines
  • 外部 crate の充実（乱立には戸惑う）
  • 他の言語を書いたときにソワソワ（ clone しなくてもコンパイルエラーがないとか）
• unwrap はよくない
  • エラーメッセージが開発者にしかわからず、他のチームに聞かれてしまう
  • 自分たちにもわかりにくい
  • unwrap をやめて Result で返す
  • Option は anyhow context で
  • 本当にエラーでも、 expect
  • assert が直ぐ側にあるなら unwarp でも
• 並列処理は型だけでは不十分
  • Arc<Mutex> を clone しても、状態は共有される（知識不足）
  • コンパイラは何も言わない
• Tonic で protobuf ファイルを扱う
  • protobuf ファイルが先に無ければいけない
  • prost-reflect を使う必要がある
  • 動的な仕組みと Rust を組み合わせるときは注意
• 報われたこと
  • Scala と比べてイメージファイルが 1/10 程度に
  • CPU、メモリ使用率が安定 → 安心して運用
  • Scala だと、 JVM の GC 対策などの運用経験が必要。 Rust では不要だろう
• Q). crate の選択肢が複数あるときにどうする
  • A). ダウンロード数と更新間隔
• Q). チーム内でのノウハウの共有は？
  • A). チーム内では同じコードベースを触っているので。チーム外は課題
• Q). ビルド時に protobuf の形式が不明とは？
  • A). ビルド時は利用者が不明。誰がどの protobuf を使うか不明。利用者はどんな protobuf か知っているので、使える
• Q). なれない言語での初回リリースのステークホルダとの調整は？
  • A). ステークホルダの声は小さかったので大丈夫。調整は特にしていない

Ferrocene - Rust in Critical Environments / @argorak さん

• ferrous systems
  • rust-analyzer, Knurling, Bindgen, sudo-rs
  • Training
• ferrocene
  • language specification, Long Term support
• qualified tool
  • compiler, specification, test (mapped to specification), Evidence (test output)
• goal
  • evidence
  • always pass all tests
• 69,000 additions for codes
• Paranoid mode for Rust
  • Slow but safety
• OSS stack
  • Reuse ,Sphinx, Sigstore, bores-NG, cargo-dist, Python/Bash
• Safety Manual
• Constant testing, merging of upstream
  • automationed

クロージングセッション

• スピーカーとメルカリさんに感謝
• Rust.Tokyo
  • プロポーザル募集（今年は多かった）
    • 良いプロポーザルも、トピックの偏りを考慮して落選することがある
    • 数が多いと、会場を大きくしたり採用も増やせる
  • スタッフ募集
  • 大きくすることは目的ではないが、大きくなるとできることが増える

BROMPTON図鑑に出演した

縁あって本日発売の「BROMPTON図鑑」に出演させて頂いた。見開き 2 ページを含む 4 ページを使って、所有しているブロンプトンを紹介して頂いた。

見本誌を頂いたので中身も読んだが、全ページブロンプトンへの愛に溢れた素晴らしい内容になっている。紹介されているオーナーは総勢 25 人で、それぞれ個性的である。どんな人物が、どのようにカスタムをしたブロンプトンを、どういう使い方をしているのか、読んでいるとブロンプトンの懐の深さに感服するとともに、こういうこともできたのかとワクワクしてくる。他、各部名称の紹介から日本初のブロンプトンを追う企画まで、ムックとは思えない贅沢な内容だった。興味がある方には購入をオススメする。

さて、出演したブロンプトンについてだが、実は 去年購入したブロンプトン ではない。今年のゴールデンウィークにもう一台ブロンプトンを購入しており、今回出演したブロンプトンはそちらの方だ。購入したのは BROMPTON X CHPT3 4TH EDITION という限定モデルである。

borompton chpt3v4

去年買ったブロンプトンには満足していたのだが、それでも使っているとこうしておけばよかったなという点がいくつかあった。まず、折り畳み時に転がせるようにとリアラックを付けたのだが、結局ラックについているローラーは使わず、肩にかけて持ち歩くことにした。もちろん、本来の目的通り荷台として使うと便利なのだが、フロントバッグの使い勝手と性能がとてもよく、リアラックに荷物を載せたのは２～３回しかなかった。そもそも、輪行よりも自走で乗ることがメインとなってしまったということもあり、リアラックが役立つ機会はほぼなくなってしまった。

brompton M6R

次に、シートポストやクランクの色は、やっぱりシルバーがよかったなあと思った。フレイムラッカーの色が気に入ったのでブラックエディションを買ったのだが、やはり個人的にはシルバーの方が好きだ。近所でホワイト系のブロンプトンを見かけたときは、すてきな色だなあと心惹かれた。そういう意味では、 barbour model はモロ好みど真ん中の色で、これに関しては本当に買うか迷った。とは言え、同じ仕様の車体を2つ持っても意味がないなあと思ったし、じゃあフレイムラッカーと交換したいかというと、フレイムラッカーの方はこれはこれでいい色なので、そこまでではないなあという結論に達した。

そう思っていたところで発表されたのが、今年購入に至った CHPT3 4TH EDITION である。リアラックがないどころか、泥除けまでついていない。フロントのキャリアブロックすらデフォルトではついていないので、ブロンプトンの象徴とも言えるフロントバッグすら装着ができない。本当に割り切ったミニマムな装備のブロンプトンである。これだ、と思って、ダメ元で予約をしたところ、運良く当選した。

brompton chpt3v4

この車体のベースは P Line であり、リアフレームやフロントフォークにはチタンが使われている。実測で 10Kg 弱の重さであり、 C Line の 13Kg と比べるとだいぶ軽い。ギアが外装４段で M6R の内装含めた６段よりも少なく、その点は不安だったので事前に P Line を試乗させてもらった。感覚としては M6R の一番軽いギアと重いギアがなくなった感じであり、重い側は回せなくてほぼ使わないのでともかく、軽い側については坂道で若干不安だなあとは感じる。とは言え、都市部を走るには全く不自由もないし、大船にある栄光坂は（死にそうになりながら）一応登ることはできたので、峠にでも登らない限り困ることはないと思われる。

ということで２台目のブロンプトンとなった chpt3v4 であるが、こちらも買ってよかったなあと思っている。１台目の M6R とかなり方向性が違うブロンプトンなので、それぞれ違った遊び方ができる。 M6R の良さはなんといっても積載力なので、旅に使うと威力を発揮する。 北海道へ行ったとき に使ったのもこちらの車体である。一方で chpt3v4 は、とにかく身軽なことが魅力である。エキササイズとして川沿いの道をひたすら走るのであれば、 chpt3v4 を使ったほうが楽しい。フロントバッグが使えないので、 chpt3v4 を使うときはバックパックを背負うことになる。重量が軽いことも相まって、カフェに入るのは chpt3v4 の方が遥かに楽だ。スタバの前で止まって、 10 秒で畳んでそのまま片手でひょいとブロンプトンを持ってそのまま入店ということが、 chpt3v4 なら簡単にできる。荷物はバックパックを背負っているので、いちいちフロントバッグを外す必要もない。 M6R だとここまでのスピード感は出ないし、車体が重いので入店するときもヨタヨタとしながら大荷物を担いで入ることになるので、店員や周りの目も気になる。結果として駐輪場に止めたほうが楽だなあということになる。

brompton chpt3v4

Brompton in Palace に chpt3v4 で参加した際、たまたま著者の 山本耕司さん に見つかって声をかけていただき、今回の出演に至った。乗ることはもちろん、こういう人と人とのつながりが生まれるのも、ブロンプトンという自転車の良いところだなあと思う。「BROMPTON図鑑」を読めば、個性的なオーナーと自転車達を通して、その魅力を読者にも十分に理解して頂けることだろう。

北海道へ飛行機輪行

実家の都合で２泊３日で北海道に帰ったのだが、天気を見ると調度うまい具合に晴れの予報だったので、思い切って ブロンプトン を飛行機で輪行して持っていった。

羽田空港

羽田空港の第二ターミナルから飛行機に乗ったのだが、第二ターミナルへ自走で行くのは大変である。 団長が行き方を公開してくれている が、それよりも第三ターミナルから無料巡回バスを使ったほうが圧倒的に便利である。第一、第二ターミナルと違い、第三ターミナルは めちゃくちゃ自転車にフレンドリー なのである。第三ターミナル駐輪場まで自走すれば、そこから 巡回バスの乗り場 までは自転車を（畳まずに）押して歩いて 5 分ほどで着く。

ただし、バスには 10 ～ 15 分ほど乗らなければならないので、時間には余裕を持ったほうがいい。

飛行機輪行

飛行機で輪行するために事前に色々と下調べはしたのだが、結局、通常の電車の輪行とあまり変わらない手間で飛行機に乗せることができた。やったことは以下である。

事前に航空会社へ電話

事前に航空会社に電話をした。結論から言えば、ブロンプトンのサイズであれば、今後は電話連絡は要らないとのこと（ただし、航空会社によって異なるので、注意）。

自転車のパッキング

パッキングはめんどくさいのでしていない。もう一年間相当に使い潰したので、多少傷ついたっていいし、壊れたら プロの兄さん達 に直してもらえばいいやくらいの気持ちで臨んだ。以下は巡回バス内の写真だが、この状態からチャックだけ締めてそのまま預けた。

ただ、以下の２点だけは実施した。

• ブロンプトンのヒンジのパーツがくるくる回らないように、ネジを締めておく
• タイヤの空気をちょっと抜く

前者はやっておいたほうがいい。ヒンジパーツは変な角度で力が入ると折れてしまう。ネジを閉めるのは 10 秒以内にできるので、やって損はない。後者については、空気入れがないと空気が抜けないし到着後に入れることもできないので、若干荷物が増える。航空会社には、抜けと言われた。

もう一点、地味に忘れがちなのがヘルメットである。これがかさばって邪魔なので、行きは輪行袋に入れたのだが、自転車と接触してヘルメットが削れてしまった。帰りは 大容量のバッグ を活かして、バッグにヘルメットを入れて自転車と一緒に預けた。念のため小さなバッグも持っていたので、機内持ち込み品だけそちらにまとめた。

従価料金

飛行機輪行でググるとたくさん出てくるので、申し出て手続きしてもらい 200 円を払った。丁寧には扱われたのではないかなあと思う。

ただし、従価料金も預け入れもかなり時間がかかるので、早くても 30 分は自転車を預けるのにかかると思っておいたほうが良い。平日で 30 分だったので、休日だと 1 時間を超えてくるだろう。そもそも自転車は自動で預け入れられないので、激混みの有人のカウンターに並ぶことになる。従価料金の手続きも、慣れていない担当者の場合かなり手こずる。

そして、北海道へ

遠く離れた地を自転車で回るのは楽しい。

子供の頃見慣れた風景を、大人の視点で、そして自転車で眺めると、色々な発見がある。

目一杯走って、満足した。

新千歳空港

さて、帰りは新千歳空港まで自走したのだが、羽田空港とは違ってなかなかに厳しかった。

苫小牧から新千歳空港へ向かうには、国道 36 号線を延々と千歳に向かって走ればよく、ここまでは楽（と言っても、交通量も多くて車速も速いのでずっと緊張しっぱなしだが）。

問題は 道道 130 号 に入ってから。そもそも片道一車線の追い越し禁止区間でほどほどにアップダウンもカーブもあって走りにくいのだが、この道には熊注意の看板が立っている。お世辞にもサイクリストにやさしい道ではない。

その上、道道 130 号を進んで着くのは国際線ターミナルである。国内線ターミナルに行くには国際線ターミナルを抜けて行く必要がある ¹ のだが、ずんずん進んで行くと写真のような合流地点に出る。

自転車でここの左側の２車線側へ合流するのは、かなりキツイものがある。

まとめ

飛行機輪行を初めてやってみたが、下調べしていたこともあり、何も困ることがなくスムーズに自転車を飛行機に乗せることができた。旅先を自走できるのは楽しく、やっぱりブロンプトンは大人の遊びに最適だなあと思った。今後も天気が許す限り輪行を利用したい。

ただ、北海道の自転車の走行環境は、首都圏ほどは良くない。大型車がかなりのスピードで走っている上、路肩は広い場所も多いが整備されておらず荒れ放題で、かなり神経を尖らせて走る必要がある。路肩の広さ・荒れ具合と、後方の車の状態をよく見ながら、路肩と最左車線（場合によっては歩道も）のどこを走るべきか、かなり頭を悩ませた。自転車ナビマークなんて優しいものは、どこにもない。それでもきちんと走り切れたのは、日々、首都圏の公道を走って色々な経験を積んだ賜物だろうなあと思う。ブロンプトンを買って翌週には飛行機でいざ北海道へ、とかは流石に辞めておいたほうがいい。

羽田に着いてからも自走したのだが、多摩川沿いのサイクリングロードは環境が良過ぎて、マジで天国かと思った。なんだかんだで首都圏の自転車事情はかなり良くなってきていると言っていいだろう。

---

1. 係員に聞いた行き方なので、正式な行き方のはず。↩

traitのaliasを作る ～ associated typeを添えて

Rust には整数の primitive 型が多数あるが、どの型でもよしなに計算してくれる関数を書きたくなる。四則演算子を表す trait はあるのだが、細かく分かれているので指定するのが大変である。

use std::fmt::Display;
use std::ops::{AddAssign, Mul, MulAssign};

fn execute<T>(mut x: T, y: T)
where
    T: Display + Copy + MulAssign + Mul<Output = T> + AddAssign,
{
    println!("x={}, y={}", x, y);

    x *= y;
    println!("x * y = {}", x);

    x += y * y;
    println!("x * y + y ^ 2 = {}", x);
}

fn main() {
    execute(3u32, 5u32);
    execute(4i64, -3i64);
}

せめてこれらの trait をまとめてエリアスにできれば楽になる。しかし、 issue はあるがその機能はまだ使えない。

github.com

work around は紹介されているので、こちらを使うことになる。

まず、 supertrait を指定した新たな trait を作る。

trait LooksLikeNumber: Display + Copy + MulAssign + Mul<Output = Self> + AddAssign {}

この LooksLikeNumber trait を使えば、 where を使うことなくすっきりと書ける。また、同様に「数値」を引数に取る関数や型が増えたときにも、 LooksLikeNumber と書くだけで済む。

fn execute<T: LooksLikeNumber>(mut x: T, y: T) {
    ..snip..
}

人間の気分的にはこれで終わっているのだが、残念ながら u32 も i64 もこの trait を実装してないのでエラーとなる。

   |
17 |     execute(3u32, 5u32);
   |     ^^^^^^^ the trait `LooksLikeNumber` is not implemented for `u32`
   |

もちろん、自分で実装を書けば良いが、こんなことをしていると日が暮れてしまう。

impl LooksLikeNumber for u32 {}
impl LooksLikeNumber for i64 {}

そこで、 supertrait をすべて実装している型は自動的に trait を実装できるように、定義を書く。

impl<T> LooksLikeNumber for T where T: Display + Copy + MulAssign + Mul<Output = T> + AddAssign {}

これで、 u32 i64 だけではなく、必要な四則演算が定義されているすべての型について execute メソッドが利用可能となった。

    execute(1.5f64, 2.2f64);
    execute(Complex::new(2i16, 1), Complex::new(-4, 6));

浮動小数点数の演算で誤差が出ているのはご愛嬌。

x=1.5, y=2.2
x * y = 3.3000000000000003
x * y + y ^ 2 = 8.14
x=2+1i, y=-4+6i
x * y = -14+8i
x * y + y ^ 2 = -34-40i

さて、次は execute にこんな処理を加える。

    println!("y * 4 = {}", y << 2);

<< は Shl<i32> という trait で提供されており、出力される型 Shl<i32>::Output は Display trait を実装していて欲しい。よって、こう書きたくなる。

trait LooksLikeNumber: Display + Copy + MulAssign + Mul<Output = Self> + AddAssign + Shl<i32>
where
    <Self as Shl<i32>>::Output: Display,
{
}

impl<T> LooksLikeNumber for T where
    T: Display + Copy + MulAssign + Mul<Output = T> + AddAssign + Shl<i32>,
    <T as Shl<i32>>::Output: Display,
{
}

しかし、これはエラーとなる。

   |
17 | fn execute<T: LooksLikeNumber>(mut x: T, y: T) {
   |               ^^^^^^^^^^^^^^^ `<T as Shl<i32>>::Output` cannot be formatted with the default formatter
   |

LooksLikeNumber を実装している型が、 where で指定した trait 境界を満たしているとは限らないのである。そうなると、こう書きたくなる。

trait LooksLikeNumber: Display + Copy + MulAssign + Mul<Output = Self> + AddAssign + Shl<i32, Output: Display>
{
}

方向性はあっているのだが、この機能は以下で議論中であり、まだ利用できない。

github.com

error[E0658]: associated type bounds are unstable
  |
5 | trait LooksLikeNumber: Display + Copy + MulAssign + Mul<Output = Self> + AddAssign + Shl<i32, Output: Display>
  |                                                                                               ^^^^^^^^^^^^^^^
  |
  = note: see issue #52662 <https://github.com/rust-lang/rust/issues/52662> for more information

issue 内で、 この問題に関するワークアラウンド も紹介されている。 trait 境界を与えることはできないが、具体的な型を与えることはできるので、そうすればいいのだ。 LooksLikeNumber に関連型 S を定義する。

trait LooksLikeNumber:
    Display + Copy + MulAssign + Mul<Output = Self> + AddAssign + Shl<i32, Output = Self::S>
{
    type S: Display;
}

では、関連型 S はどう実装すればいいのだろうか。都合がいいことに、 Shl<i32>::Output という Display trait を実装する型があるので、それを使うと良い。

impl<T> LooksLikeNumber for T
where
    T: Display + Copy + MulAssign + Mul<Output = T> + AddAssign + Shl<i32>,
    <T as Shl<i32>>::Output: Display,
{
    type S = <T as Shl<i32>>::Output;
}

<< を使うようにしたので、先に追加した浮動小数点数や複素数のコードは動かなくなったが、 u64 i32 のコードは想定通りに動作する。

x=3, y=5
x * y = 15
x * y + y ^ 2 = 40
y * 4 = 20
x=4, y=-3
x * y = -12
x * y + y ^ 2 = -3
y * 4 = -12

ところで、冒頭に、

四則演算子を表す trait はあるのだが、細かく分かれているので指定するのが大変である

とこのエントリを書くためにあえて書いたのだが、以下の PrimInt trait を使えば四則演算をいちいち細かく指定する必要はない。

https://crates.io/crates/num

いやぁ、 trait って本当に素晴らしいもんですね。

今日は 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 を整えるのがまず最初
    • 足回りを固める。デプロイが難しいと誰もやらない
    • やることで、廃墟の構造がわかってくる
  • 開発環境が必要。口伝ではダメ
  • テストで固める
    • シナリオやユースケースをベースとした E2E テストで固める
  • ステージング環境を作る
    • 難しいが、不確定要素が多過ぎる。本番と同じ状況が必要
    • 祈りベースのデプロイでは駄目
  • 各種バージョンを上げていく
    • 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 とリバースプロキシを重ねたもの
  • MogileFS のドメインの仕組みを利用して、論理的に区別
  • 物理的には混在
• クラウドを活用するので、ハードウェアを意識することは減っている
  • クラウドの中身はハードウェア
• ハードウェア構成
  • 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 月
  • trie 木、いいフレームワークがなかった
• 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合体代入演算子 ??=
• まとめ
  • PHP のバージョンが上がってもデザインパターンの本質は一緒
  • プログラミング言語は利便性、堅牢性が上がっている
  • ソフトウェアは建築物と違って、時代に合わせて最適な構造を作る必要がある
• なぜデザインパターンを学ぶのか
  • 手段は本質よりも早く廃れる

インシデントレスポンスを自動化で支援する - 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 し、通知
• 準備
  • 年一回以上訓練・演習している
• 実装、設計
  • RoR + slack-ruby-client
  • プライベートクラウド k8s
  • ChatGPT も Celelry + Fast API
• 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 割

  • 「書く」より「読む」
  • ドキュメント（公開、社内）、過去の事例、ソースコード
• 面白いところ
  • 問題解決: 具体的で解決する必要がある問題、謎解き
  • 問題のスコープが広い
    • 自社製品の深掘り、依存する技術（ミドルウェア）、サードパーティ、ITの基礎
    • 知識、経験、長年のカン
  • 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 さん

• 文字化け: 文字コードを別の文字コードとして読み込んだ結果
• MS 製品は Shift_JIS ・・・
• 旧字体と新字体: 桜と櫻、国と國
  • 検索できない、 unique にできない、機械学習への影響
• 濁点の文字数の判定: Unicode の結合文字
• 文字列が壊れていたら文字コードを確認、文字列の見た目に騙されない

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

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

Something NEW / myfinder さん

• yapcramen を忘れずに

• 会社を作った
  • Eric Sink マイクロISV
  • 4 期目、黒字
• 数の暴力との戦い
  • 一人
  • オートスケールは無意味
• クローズドソースプロダクト
  • ソースコードが開示されてないので、補完が効かない
  • AST 操作
• 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）」である。

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