昨日 に引き続き、今日は Perl 神社 に来ていますので、自分用にメモを残しておきます。
オープニング
- YAPC Kyoto 成功祈願の様子の動画
- 開発成就、成果達成！
- YAPC Kyoto 2020 年から３年ぶりに焼き直し
- Reboot
- 蓋付きペットボトル、会場配布のもの、以外は飲食禁止
- 禁煙
- 疫病対策はマスク、アルコール消毒、ソーシャルディスタンス
- no photo のタグを付けてる人は写真を撮らないよう
- CoC 守りましょう
- #yapcjapan 、 #yapc_sp #yapc_gy 、 #yapc_do
- Perl神社の参拝回数、金額に上限はありません（ TPF に寄付）
Helpfeel さんのスポンサーセッション
【企画】春のエンジニア ぶつかり稽古 2023
秋のエンジニア ぶつかり稽古 に登壇した者として、見届けに参りました。
- 10 年前のイベントのリバイバル
- YAPC::ASIA の参加者スペシャル特典だった
- 「あんちぽ」さんと「ぶつかり稽古」したい
- きっかけとなった YAPC でリバイバル
- ライブコーディング形式で進める
- お題「ソート」
- 一人がテストを書き、もう一人が実装を書く
- 順番はじゃんけんで「相撲取れと言われなくてよかった」
- 入力を手動で並び替えてテストを PASS → リファレンスと配列の違い、シジル
- 要素数を増やして別のテスト
- 素朴なバブルソートを実装
- 文字列のソート機能も含める
- ChatGPT さん「
looks_like_number」 looks_like_numberで>=gtで分ける
- ChatGPT さん「
- 文字列と数字が混ざったソート
- 第一オペラントだけでなく、第二オペラントも数字だったときのみ
>=を利用
- 第一オペラントだけでなく、第二オペラントも数字だったときのみ
- 攻守を入れ替え（ここから 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 は実行できます
- 二十世紀と二十一世紀で文字列の定義が異なる
- Node.js では、
uフラグを使わないとサロゲートペアが 2 文字扱いになる- Python2 では死にたくなるので捨てて（コンパイルフラグで挙動が変わる）
- 国旗の絵文字の例
- 合成文字。
\x{1f1ef}\x{1f1f5} - Perl では
\Xを使うと良い - JS ではサポートされてない
- 一部のブラウザでwork around はある
- 合成文字。
Regexp::Common$RE{net}{IPv6}
Regexp::Assemble- 正規表現の Unicode については Perl が一番サポートしている
\Xは 5.8 の頃からサポートしている- ChatGPT は意外ときちっと返ってくるが
- 質疑応答
あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで / あらたまさん
- cake.jp の CTO
- YAPC 2011 で衝撃を受けた
- ハッカーに憧れて入社したが、ギャップ
- 振る舞い、実力
- 誰にも言われていないのに
- ゴールも「ハッカー」の定義が不明
- 憧れてから 2 年経っていた
- 2 年経つと組織も変わる
- そこは「ハッカー集団」だったのだろうか
- ハッカーとは
- みんなで成果を出す。事業を出すのが大事
- 成長していた。評価されていた。周りが強過ぎ
- 「ベクトルが自分に向いているうちは何してもだめ」 DeNA 南場さん
- 自分のゴールも不明確だった
- エンジニアの評価軸
- 「正しく」設計し、「正しく」コーディングする
- 「正しさ」は簡単に変わる
- 市場、業務フローは変わる→技術的確からしさだけで技術選択はできない
- 突き抜けた技術、だけではなんとかならない
- 「システムは現実の写像たれ」くふうカンパニーCPO 前田さん
- 業務フロー、カスタマージャーニーを、忠実にコードへと落とし込む
- 能動的に情報を取りに行かなければならない。外側を知りに行く
- エンジニアは how に責任を持つ
- why と what は正しく理解しなければならない
- ドメインに明るくないと、寿命の長いコードを書けない
- 事業、技術のどちらの軸もそれなりに育った人が求められた人
- サービスインから高トラフィックに晒されたりする場合は例外（技術に尖っている人が必要）
- 事業、技術のバランス。自分がどう動けば、プロダクトが成長するのか
- 第 3 の軸: 組織
- 会社に人が集まるのは、 1 + 1 >> 2 としたいから（安定したお給料はいいものだけど）
- マネージャーじゃなくても、「うまくマネージされる」「チームの生産性を上げる」
- 3 軸の評価指標は、絶対的ではなく相対的
- 環境によって大きく変わる
- 2015, 2020, 2023 年で、組織からの期待と自分の希望は異なる
- すり合わせが必要
- 苦しんでる人は、自分に期待されていると思っている役割と、実際に期待された役割がずれている可能性も
- テックリード、スペシャリスト、エンジニアリングマネージャー
- CTOのフェーズ別→初期は技術力、成長期はバランス、円熟期はPDM, CTO, VPoP と分担
- ハッカー
- HRT ( 怠惰、短気、傲慢 ) が実装されている
- 目的の達成に労力を惜しまない、技術を正しく使う
- 技術を好きな方がいい（バフがかかる）
- ハッカーじゃない
- 朝が遅く夜も遅い
- コミュニケーション・コラボレーションを拒否する
- 視点の狭い正論を振りかざす
- 我々の中にハッカーの性質があり、それをどう表に出して育てていくか
- 「あのとき憧れたハッカーは、実は自分の中にあった」
- 自分の希望を、自分の言葉で口に出せるように具体化するのが大事
- 乗っている船に、自分の will を重ねる→納得の行くキャリアが歩める
- 「型にはまると安心する」→「やりたいことをやっていると名前が後からついてくる」
- マネージャー→エンジニアリングマネージャー
- 質疑応答
- いつ呪縛から解かれたのか
- 色んな人にあって、いろんな経験をしたため。突然プロジェクトに放り込まれて、足元が変わったことはある
今出川 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 が公開されたことについて
- 会場から: Q). シンギュラリティはいつ来る？
- 来たと思って働いているといいのでは
- AI が AI を改善始めると来る。もう少し？
- 自然言語はすでに作れているようだ
- 会場から: Q). チャットとしての制約は
- 長く喋らなければならない。タスクによってはマシなやり方があるのでは
- ・・・を・・・してください、は実はタスクを処理している
- OpenAI 社が使いやすいようにチャットにしてくれただけ。限界は感じない
- 会場から: Q). プロンプトの管理
- ChatGPT さんも連れてくればよかった
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す / @moznion さん
dokilldieが好き- 廃墟とは
- 「ソフトウェアは壊れない」→神話
- 自然劣化しない
- 作った瞬間から壊れている
- 機能改善への要求に答えられなくなると、壊れる、劣化する
- 「技術的負債」は誤用。それは廃墟だ
- danさん「借りてないでしょ」
- 良くないソフトウェアが正当化されている
- 廃墟の問題
- 誰もメンテできない
- 「再起動したら奇跡的にリカバリできましたね！」その先はない
- 新機能を安全に入れられない。無理矢理に入れていく。違法建築
- 「廃墟は伝搬する」隣も隣も全部廃墟になる
- 「枯れ」と「廃墟」は違う
- 「継続的に整備、機能追加可能、デプロイ自動化」枯れているだけ。新機能追加はできる
- どちらも、長期間安定に運転されているように見えてしまう
- 大爆発する前に、どう見極める？
- 判断が自動化できる？ last update が 2 年前でも、動くことはあるわけ
- 廃墟を直す
- むずかしい。コストとのトレードオフ。直せるなら直したほうがいい
- 人的リソースを割くのがとても大事。
- できれば複数人、チームでやらないと、逆戻りするリスク
- 「個人技の限界」と「個人技による圧倒」
- CD を整えるのがまず最初
- 足回りを固める。デプロイが難しいと誰もやらない
- やることで、廃墟の構造がわかってくる
- 開発環境が必要。口伝ではダメ
- テストで固める
- シナリオやユースケースをベースとした E2E テストで固める
- ステージング環境を作る
- 難しいが、不確定要素が多過ぎる。本番と同じ状況が必要
- 祈りベースのデプロイでは駄目
- 各種バージョンを上げていく
- Java 1.5 がまさか動いているとは・・・！
- 古いものを使い続けると足枷に
- 少しずつ上げていく
- 普通のプロジェクトと同様の開発フローへ
- 廃墟を出る
- 廃墟を壊す
- 廃墟に住む
- 廃墟に死す
- システムの倒壊が先か、サービスが終わるのが先か
- 倒壊はエンジニアにしかわからない
- エンドユーザへのリスペクトは必要
- システムの倒壊が先か、サービスが終わるのが先か
- 廃墟になるのはなぜか→カネがない
- 古い技術スタック、システムが複雑
- 廃墟ではなく、枯れを目指す
- 運用の自動化
- 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
GET /sample/objectの例- Bayt用メタデータ Content-Type, Content-Length, Etag
- tracker に問い合わせ
- MogeleFS が在り処をリバースプロキシに教える
- リバースプロキシが取りに行く
- Bayt から S3 へ
- 30daysAlbum はそのまま使う
- 質疑応答
- 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 で対応
- Web Standard は使えるが、
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 で対応した（使ってみてください）
- 質疑応答
My New Error... - It is my new era. / @sadnessOjisan さん
- 3 ヶ月間、アラートの監視の仕事だけをした
- 30 個近いレポジトリからのエラーログ
- オオカミ少年問題への対処
- 監視をしやすいエラーハンドリングについて
- スクラッチから書く前提
- 理想論から現実の問題へ
- 何が起きていた？
- 様々な問題があるが、実装の問題から取り組んでいく
trycatchでの例外の管理- 例外を知らないと
tryを書けない Result型を使うResultで包むのは正常系は無駄- 言語機能でないので、トレースが大変
- 例外を知らないと
- デメリットがあっても導入
- パフォーマンスへの問題は、後から対応する
- 関数型プログラミングをしたい訳では無い
新幹線の時間があり、ここで帰宅。
