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

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

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

商品の注文や口座間送金など、二重に行われてほしくない処理をネットワーク越しにリクエストし、通信に失敗したとき────クライアントはリトライするかもしれません。
しかし、直前のリクエストでサーバ側の処理が正常に完了していたら、1回でよい処理が複数回行われてしまいます。

この課題を解く鍵は"冪等性"。
「同一リクエストに対して結果が変わらない」仕組みをサーバが備えれば、クライアントは安全にリトライできるようになります。
そして、その実現手段として注目したいのが、POST/PATCHリクエストを冪等にするためのプロトコル、Idempotency-Key Headerです。

本セッションでは、IETF draftとして提出されているIdempotency-Key Headerの背景・コンセプト・現在の動向を解説し、HTTPリクエストにおける"安全なリトライ"について掘り下げます────

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

対象

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

アウトライン

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

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

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

話すこと

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

対象者

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

好きか嫌いかと問われれば好きに入るぐらい長らくSMTPに携わっていまして、1982年にRFC821となってから43年も経つ伝統産業みたいなSMTPは少しずつ現代の要求を満たす周辺技術が実装されRFC化されています。
本講では現代のSMTPを支える重要な技術について概説的にお話をします。

内容

• メールアドレスの役割・エンベロープ・ヘッダー
• 認証技術(SPF, DKIM, DMARC, ARC, BIMI)
• 暗号化(STARTTLS, MTA-STS, DANE)
• 大量配信での注意
  • レピュテーション(IPアドレス,ドメイン)
  • List-Unsubscribeヘッダー(Gmail等)
  • 商用配信サービスか自前サーバーか

対象

• 現代的なメール技術を知りたい人
• メール沼に入ろうとしている人
• インフラ担当で近所にメール沼がある人

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

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

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

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

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

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

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

NOT A HOTEL で運用されていた、一部 Go で書かれた API と Python で書かれた LLM の API を Cloudflare Workers のスタックへ完全移行し、半年以上運用してみて、何が最高になったか、大変だったことをアプリケーションコードを一部公開しながらお話ししたいと思っています。

• なぜ移行を決断したか

• アプリケーションで提供している機能

  • Workers Queue
  • KV
  • D1
  • AI Gateway

• LLM のための管理画面

  • htmx + Alpine.js (変更の可能性あり)

• ログ周り

  • GCP Cloud Logging

• Cloudflare のメトリクス

  • Cron Triggers

• 移行すると運用にかかる費用が安くなる話はいろんなところで出ているので話しません。

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

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「で」作りましょう！（利用規約は遵守してね！）

複数のパッケージが同じリソースに依存している場合、どのようにしてコンフリクトを解決するのでしょうか？
また、依存関係が循環している場合、それはどのようにブレイクされるのでしょうか？

このトークでは、cpanmの依存関係解決の仕組み、そして現代の若者がPerlを学ぶ様子についてお話ししたいと思います。

私は以前からパッケージマネージャの依存関係解決に興味を持っていました。その美しくも複雑な仕組みが、どのようにスムーズなパッケージ管理を実現しているのか気になりますよね？ そして今回、探求の一環として「cpanm」の世界に足を踏み入れることにしました。依存関係解決の流れを具体例を用いてわかりやすく説明します。

主なトピック

• cpanmのソースコードを読み解く私の冒険と発見
• 依存関係解決の複雑で魅力的な仕組みの探求
• 現代の若者がPerlと向き合うリアルな様子

ソフトウェア開発の学問的な深掘りといわれると、いわゆる「理系」学問を想像しがちですが、今回は深掘りをする方向を変えて、人文学や社会科学方面に深掘りしてみたいと思います。
本発表はソフトウェア開発の深掘りにしたときに現れる人文学や社会科学の学問、いわゆる「文系」の学問についての発表です。これらの学問とソフトウェア開発と一見無関係に見えて密接に関わっています。我々は普段から何気なく経営学や社会学の組織論の考え方を参照し、心理学からリーダーシップや人間の振る舞いを学び、哲学思想から思考の枠組みを提供されています。そんなソフトウェア開発に影響を与えた文系の学問の考え方や成果を紹介しようと思います。
おそらく明日役に立たない知識ですが、"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年目のエンジニアが創業当初から運用されているサービスの整理を行うことで、サービスへの理解を深めた経験についてお話しします。

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

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

ブログが好きです。20年近くのブログ歴で900以上の記事を書き、エンジニア界隈ではそこそこ知られたブロガーとなりました。

ブログきっかけで多くの縁がありました。本発表ではまずエンジニアの発信手段としてのブログについて改めて取り上げ、メリットや活用方法、長く続けるコツについてお話しします。

また、ブログには書く楽しみの他、ハックする技術的な楽しみもあります。私は、個人開発のブログエンジン(Riji)とはてなブログとで2つのブログを運営しており、それぞれ自作のOSSを活用してもいます。

本発表の後半では、ブログ運営上でのノウハウやTips、ブログ技術遍歴、関連技術についても取り上げます。余裕があれば、現代のPerlを用いてRijiを更新した姿もお見せしたい。

自分のブログを作り、メンテナンスし、運用し、そこで執筆する。本発表全体を通して、そういう私の人生の営みについてお話します。

職場で Getopt::Kingpin というコマンドライン引数解析モジュールを 2016 年から使っています
これは Go 言語の kingpin というコマンドライン引数解析パッケージの移植版で、 キッカソンという Perl のハッカソンイベントから開発がスタートしました
当時のモチベーションは

• Go と同じ書き味、低学習コストでスクリプトを作れるようにする
• 書き捨てスクリプトにもヘルプを

というものでした。

Getopt::Kingpin は 2023 年の現在でも職場で使われ続けています。
長く使われることで、当初想定していた以上に職場に好影響がありました。

このトークでは、 Getopt::Kingpin と職場という観点での 7 年間を振り返ります。
https://metacpan.org/pod/Getopt::Kingpin