トーク

私はスタートアップやベンチャーの新規事業の中でシステムのリプレイス作業が必要な場面を何度も見てきました。
機能追加を行うたびに不具合が発生してしまったり、簡単そうな修正を行うだけでも何週間やときには何ヶ月かかるという話もよくあります

私がプロダクトを作るときはシステムリプレイスが必要ないように作ろうと決めて開発しています。
結果、今のところリリースから約4年になりますが、システムのリプレイスが必要といった状態にはなっていません。
今後、リプレイスの予定も今のところはありません。

どうすればスタートアップでも技術的負債をためずに開発しつづけることができるかといったことや、速度を優先して技術的負債をためてしまった場合の対処方法などを話せればと考えています。
このトークはプロダクト開発をいった話を軸に技術選定、チーム作りなど話題が多岐に渡る予定です。

最近よく聞かれます。「なぜKubernetesを採用したのですか？」
ネタバレしてしまうと、当時の機能でECSと比較するとKubernetesに分があった、というのが大きな要因です。
ただ、Kubernetes楽しい（楽しそう！）というのも要因としては含まれていて、
Kubernetesのがっつり運用をやってみたい、というモチベーションで入社したメンバも（私含めて）いるのも事実です。
様々な要件があるなか、「好きだから」で技術選定をするのは良い面も悪い面もありますが、
様々なツラミもある中しっかり運用できているという点ではうまくやれていると思っています。

Kubernetesの運用を始めて7年経ったChatworkインフラの今や、改めてその好きなところを振り返りつつ、
たとえば今この時点で再度技術選定できるならどうするか、といったお話もできればいいかなと思っています。

本トークはソフトウェアエンジニアとしてのキャリア設計について演者が考えてきたことを、「育児」と「スキル」というトッピングを交えて話します。

演者はソフトウェアエンジニアで、IC (individual contributor) として働いています。昔は仕事でもプライベートでもコードを書いていればそれで幸せでしたが、40代になって思うところが増えてきました。特に、家事と子育てに大きな時間を使うようになったことで、キャリアについて考えなければならないことが増えました。よって一つ目のトピックは「育児」です。

さて演者のキャリアを振り返ると、まずまずうまく行ったなという部分と、あまりうまく行かなかった部分があります。特にハードスキル・ソフトスキルの研鑽については、もっと別の道があったのではないか、これから何のスキルを伸ばしていくか、日々悩んでいます。そこで二つ目のトピックは「スキル」です。

みなさんはPerlのコードを実行した際の警告やエラーでプログラムの行番号やファイル名が出たのを見たことがありますか？ エラーや警告が出ているのはわかるけど、どのコードが原因で出ているのかさっぱり分からない、と思ったことはありませんか？
このトークではPerlのスタックトレースやその周辺の仕組みについてざっくばらんに語ります。スタックトレースという概念について興味を持ってもらえれば幸いです。

主なトピックとしては以下を予定しています。

• warn,die
• caller
• Test::More,Test2
• __FILE__,__LINE__
• 他言語との比較？

あ、もちろんCarpモジュールの話もします (なぜなら広島だから)。

エンジニアの皆さんは日々効率化を進めていると思います。
ですが、自分のキーボード入力を効率化しようと思ったことはありますでしょうか。
とても小さなことですが、仕事道具ですし、PC操作にはキーボード入力が伴います。

キーボードはQWERTY配列がデフォルトです。この配列は無駄が多く、右手首を痛めやすいものとなっています。
実は、QWERTY配列以外にも配列が存在します。英語入力向け、ローマ字入力向け、日本語入力向けがあります。
英語入力向けのDvorak, Colemanは聞いたことがある方もいるのではないでしょうか。

本発表では、ローマ字入力向け配列であるEucalyn配列を習得した筆者が実体験から以下のことを話します。
・QWERTY配列以外の配列の紹介
・別配列を覚えるうえでの障害
・別配列を使っていてどのような利点があるのか
・別配列を使うための設定

近年JavaScriptによるGUI開発の文脈で台頭しつつある Signal（シグナル）という概念をご存知ですか？実はSignalの歴史は長く、この文脈は数十年前から存在します。それがなぜ最近になって注目されているのかということを、Webフロントエンド開発におけるReactivity（リアクティビティ）をキーワードにしながら紐解いていきます。題材として具体的なライブラリ・フレームワークの内容にも触れますが、予備知識は必要ありません。

対象

• GUIプログラミングの話題が好きな人
• Webフロントエンドの話題が好きな人

アウトライン

• Reactivityとは何か
• ReactivityとSignal
• Signalの歴史
• SignalによるWebフロントエンド開発

近年、データエンジニアリング界隈でモダンデータスタックという言葉をよく聞くようになりました。
企業のデータ基盤を構築する上で必要な、データの収集や処理、カタロギングなどをSaaSやOSSで構成したアーキテクチャのことを指します。

本セッションでは「趣味ではじめる」をテーマに、データ基盤の構成要素を解説しながら、身近なデータを集めて活用する実装例をご紹介します。
オープンセミナー2022@広島で発表した「データ分析基盤のはじめかた」をベースに、具体的な技術スタックの解説や設計の勘所などを織り交ぜてお話します。

話すこと

• データ基盤に必要な構成要素
  • データレイク
  • ETL / ELT
  • データウェアハウス / データレイクハウス
• 身近なデータを使ったデータ基盤の事例

対象者

• データ基盤の構築に興味のある方
• 趣味でデータ基盤を作ってみたい方

近年、Webアプリケーションの高速化の需要が急速に高まっています。
2021年からは、Web Vitalというパフォーマンスの指標が、Google検索のランキング指標としても組み込まれました。
リッチなUIを提供する一方で、継続的なパフォーマンス計測や改善活動がUXを損なわないために不可欠です。また、基礎となるブラウザの挙動を正しく理解することも重要です。

本トークでは、Webフロントエンドのパフォーマンスを最適化するための技術に焦点を当て、以下の要素を掘り下げて考察します。

・ ブラウザのレンダリングの仕組み
・Core Web Vitalsの指標からわかること、目標値の定め方
・バンドルサイズの最適化
・キャッシュの最適化と活用

Webアプリケーションのユーザー体験を向上させるために必要な実践的手法を模索しつつ、ブラウザのフロントエンドを支える技術について深掘りしていきます。

筆者はこれまで携わってきたプロジェクトの中で、「開発効率を上げる」という目標のもとに、いろいろなライブラリを導入したりツールを自作したりしてきました。どのように開発効率を上げてきたか、もっとよくできる点がなかったか振り返りながら、「開発効率を上げる」ということに対して気をつけるべきだと考えているポイントについて説明していきます。

具体的に取り上げる事例としては、以下のものを予定しています (増減の可能性があります)。

• Perlのテストコードを自動で書き換える
• Goのコード生成を使い倒す
• 「なんでも手書きする」から脱却する
• 自分だけの知恵をチームの知識として展開する

そうです、やらかし案件です。

Perlで作られたシステムも長らく運用していると、時に大きなバージョンアップが必要になりますね。
とはいえ、Perlは後方互換に強いので、バージョンを上げても結構問題なく動きます。
でもシステムを構成しているCPANモジュールの方はそうではないですね？
モジュール自体は動いても、APIや挙動が変わってることはよくあるからです。

そう、挙動がね、しれっと、変わってるの……

だからテスト必須です。そしてテストは無い。

というわけで、「CPANモジュールのバージョンあげたらあるある」の傾向と対策をお話します。
ほっこりしますよ。

（このトークはこれからPerlで構築されたシステムのメンテナンスする方、予定の方向けです。あとヤラカシ案件を聞いてニコニコしたい方向け）

「コードの書き方を強制するために lint rule を追加したいが、その rule に違反する既存のコードが多すぎて追加できない...」。こういった経験はありませんか? 折角開発体験を向上させようと思ったのに、既存のコードが足かせになってそれができない。こんなことはあってはならないと思います。

そこで私は eslint の補助ツールである eslint-interactive を開発しました。このツールは、先述のようなコードに対して新しい eslint の rule を追加するのを補助する、様々な機能が実装されています。

このトークでは eslint-interactive ができるまでの経緯、そして eslint-interactive が新しい rule を追加するのを補助するために、どのような工夫が施されているかについてお話します。

7月に経済産業省から「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」が公表されました。
システムの脆弱性が企業経営に与える影響を認識されるようになり、脆弱性管理の一つとしてSBOMが注目されています。
実際に、医療関係のシステムではすでにSBOMの導入が進んでいます。
とはいえ、SBOMという言葉は聞いたことがあっても、いまいちどんなものがよくわからないという方も多いのではないでしょうか。

本トークではSBOMの背景や現状、SBOM生成のデモ、生成したSBOMはどう活用するのか、などを紹介します。

RenovateはDependabotと並ぶライブラリの自動更新ツール・サービスです。OSSとして開発されており、私もコントリビューションしています。

私が所属する株式会社はてなでは2019年からRenovateを導入していますが、当時はPerlのcpanfileには対応していませんでした。そこで2022年の春、私は一念発起してRenovateのcpanfile対応に着手しました。まずはPoCとして、正規表現で任意のファイルを扱えるカスタムマネージャーを活用するところから始め、そこから段階的にversioning、datasource、manager というレイヤーを実装し、2023年5月にcpanfile対応がリリースされました。

本トークでは各ステップでの工夫や苦労を振り返りながら、PerlでのRenovate利用と、Renovate自体の開発についてご紹介します。

私はGitHubが好きです。「運用レス」はもっと好きです。
アプリケーションのインフラの運用が楽であればあるほど最高だと常々思っています。
ところで、GitHubにはリポジトリはもちろんPagesやPackages、GitHub Actionsなどある種のインフラとしての機能があります。
本発表では発表者が開発しているコードメトリクス計測ツール octocov ( https://github.com/k1LoW/octocov ) など、GitHubエコシステムを活用している具体的なOSSを題材に、GitHubをインフラとして仕組みを構築するためのTipsや、それ自体の楽しさを紹介できればと思います。
上手くハマればインフラはGitHubです。
皆さんも是非GitHub「で」作りましょう！（利用規約は遵守してね！）

2023年のYAPC::KyotoではChatGPT（LLM）がホットなトピックとして盛り上がった印象です。
Web API経由で使え、文章生成や要約をさまざまなWebアプリケーションに追加できます。

LLMから望む出力を得るにはプロンプト（例：以下の文章を要約してください）が重要です。
一方、開発を進める中で精度改善を狙ってプロンプトは変更されます。
では、プロンプトの変更前後でLLMが生成する文が同じなのかどうか、どのように評価すればよいでしょうか。

このトークでは文章の定性評価の評価指標を紹介していきます。

• ROUGE
• BLEU
• BERTScore
• LLM as a judge（最近の研究動向）

Pythonにそれぞれのライブラリがあるのですが、ROUGEやBLEUはPerlのスクリプトがベースという点が興味深く、YAPCでの発表のモチベーションとなっています

SonikはJavaScriptの「メタ」フレームワークです。メタというのは以下の3つの技術の上に成り立っているからです。

1. Hono - Web framework
2. Vite - Bundle & Dev tool
3. UIライブラリ - hono/jsx, Preact, React

Sonikを使うことにより2つのことができます。

1. ファイルベースルーティングによる大きなWebアプリの作成
2. フルスタックアプリケーションの作成

特にSonikは、バンドルサイズが小さく、レンダリングが高速で、Cloudflare PagesやVercelなどのエッジ環境に適しています。またDXも優れていて、CloudflareのBindingsに対応した高速な開発サーバーを備えています。

現在「アルファ」ステータスですが、当日は完成度の高いものを見せれると思います。

ソフトウェア開発の学問的な深掘りといわれると、いわゆる「理系」学問を想像しがちですが、今回は深掘りをする方向を変えて、人文学や社会科学方面に深掘りしてみたいと思います。
本発表はソフトウェア開発の深掘りにしたときに現れる人文学や社会科学の学問、いわゆる「文系」の学問についての発表です。これらの学問とソフトウェア開発と一見無関係に見えて密接に関わっています。我々は普段から何気なく経営学や社会学の組織論の考え方を参照し、心理学からリーダーシップや人間の振る舞いを学び、哲学思想から思考の枠組みを提供されています。そんなソフトウェア開発に影響を与えた文系の学問の考え方や成果を紹介しようと思います。
おそらく明日役に立たない知識ですが、"what you like"な深掘りというのは得てして実利とは関係ない活動です。この発表をきっかけに人文社会系の学問に興味を持つ人が出てきてくれたらうれしいです。

このトークでは、発表者が好む"小さい"テスト駆動開発（TDD）を紹介します。
TDDという好きな開発スタイルにおけるこだわり、TDDをいいかんじにする考え方を共有する発表です。

FizzBuzzを例に、小さいステップを積み上げるTDDをライブコーディングを通して共有します。
TDDはRed-Green-Refactorのサイクルからなりますが、これを何度も何度も回していきます。
小さいを貫くことで、Greenの時間（＝コードが動作する時間）が大半を占めるようにできます。
リズムをご覧いただくとともに、「仮実装」「三角測量」「明白な実装」といったテクニックを持ち帰っていただけたら嬉しいです。

このトークの前提は、TDDをやったことがある、または、書籍で読んで知っているとします。
コード例は、XP祭り2023のワークショップ用のPython実装をPerlに書き換えて示します

様々な要因により、Web開発の現場でも静的型付け言語が大きく活躍するようになってきました。
その結果、PerlでWebAppを実装する機会が年々減りつつあることは、Perl Mongerの皆さんとしては多かれ少なかれ歯痒い気持ちがあると思います。

でも、思い出してください。
Perlがその本領を発揮していた場はもともとスクリプトであったはずです。

Web開発において、スクリプトを一切使わないという開発現場は珍しいでしょう。
それをPerl以外の言語で書いたほうが良い場面も少なくはないかもしれませんが、それは逆も然り。
つまり、どんな開発現場にもPerlが活きる場面が隠れていると言い換えることができます。

本セッションでは、Perl以外の開発現場のどのような場面でPerlが活かせたのか、他の言語で記述した場合と比較してどのようなメリットが想定されたか等を、その実例を交えてご紹介します。

サービスの運用について考えると、機能追加やバグ修正などが思い浮かぶかもしれません。
しかし、それだけでは管理するものが増えたり複雑化するため、インフラやコードの整理が必要になってきます。

既存のリソースを統合または削除することは、機能追加やバグ修正よりもリスクがあります。
例えば、使用されていたものを誤って消してしまうと大きな障害に繋がります。

私はこれらを安全に進めるために、インフラやドメインを含めた広範囲なサービスの理解が必要だと感じました。
このセッションでは、新卒2年目のエンジニアが創業当初から運用されているサービスの整理を行うことで、サービスへの理解を深めた経験についてお話しします。

具体的には以下のことをお話しする予定です。

断捨離からシステムを理解する方法
安全に進めるためのプロセス
この活動を通して個人やチームに与えたメリット