Honoの最新メジャーバージョン「v4」をリリースします！

ソフトウェアは進化する一方で、全てのバージョンをサポートし保守し続けるのはリソースを効果的に割り当てる観点から現実的ではありません。
セキュリティリスクや管理コストを考慮し、サポート終了期間を設けるEOLを用いた運用が一般的に採用されています。
サービスを運営する中で、EOLに対して時間に余裕を持って対応できればよいですが機能開発が優先されることでリソース不足となってしまうなどでソフトウェアのEOL対応に対して後手に回ってしまうという課題がありました。
このセッションでは、GMOペパボのSREがソフトウェアのEOL対応をベースとした、ソフトウェアをただアップデートするだけじゃない工夫した事例等についてお話します。

話すこと
EOL対応の意義とメリット、対応プロセスのステップ
EOL対応をモチベーション高くやる方法
(時間があったら)過去にEOLで辛かった事例と乗り越えた話(Perlネタ)

アクセシビリティ（障害を持つ人や高齢者など多様なユーザーにとっての「利用しやすさ」）に関するオープンソースプロジェクト、NVDA（Windows用のスクリーンリーダー）の開発と日本のコミュニティ運営に、私は2010年頃から関与しています。特にWebアクセシビリティにおいて、NVDAは視覚障害者だけでなく検証者にも広く採用されています。オルタナティブな視点や興味がなければ、この分野には足を踏み入れることもなく、継続もしなかったでしょう。そんな自分自身の経験を振り返りつつ、情報アクセシビリティの世界をご紹介します。

クレジットカードの明細反映が遅い…!いくら使ったか分からないうちに請求額がすごいことになっている…!と困った経験はありませんか？なぜクレジットカードの明細はリアルタイムに反映されないのでしょうか？それには数十年以上前に考案され、今なお使われ続けているカード決済システムの仕様が大きく関係しています。

私はSmartBankというFintech企業で、B/43というプリペイドカードを開発しています。決済システムは半年ほどで開発しましたが、リリース後に色々な決済電文パターンに悩まされ、何度かの微修正を加えてようやく安定稼働するに至りました。

この発表では、決済ネットワークの仕組みと、皆さんが普段何気なく使っているカードの裏側で苦悩するエンジニアの姿についてご紹介します。

対象者

• VISAカードの決済の仕組みに興味がある人
• 複雑なデータのパターンに翻弄されるエンジニアに興味がある人

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

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

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

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

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

awkは、Perlとは異なり、Webアプリケーションを作ることには向かず、昨今この用途で使われることはほとんどありません。

しかし、私はawkが好きです。諦めません。gawkはTCP/IP通信と拡張ライブラリをサポートしており、すなわちWebアプリケーションをつくれます。

そこで筆者は、以下を実装したブログシステム (https://github.com/yammerjp/awkblog) をつくりました。これはawkで実装されている点を除けば、MVCパターンのよくあるWebアプリケーションです。

HTTPサーバ
HTMLテンプレートエンジン
PostgreSQLとの通信
Cookieとセッション管理
ユニットテスト
OAuthとログイン

このセッションは、awkでの実装の紹介を通して、フレームワークやライブラリに隠蔽されたWebアプリケーションのあらゆるトピックを俯瞰します。

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

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

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

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

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

あなたは新卒N年目、リードエンジニアのポジションが板についてきた中堅エンジニアです。ある日の朝、あなたが仕事を始めるとおもむろにCTOがやってきて、にこやかにこう言いました。「君、来月からEMね！」……さてどうする！？

ソフトウェアを開発し、ユーザーに価値を届ける活動の中での肝心要、それが「チームでの協働」。
ここでは私が経験したメンバー・テックリード・マネージャー・CTOの4つのロールを切り口として、メンバーレイヤだからこそ発揮できるリーダーシップ・フォロワーシップとは？から、マネージャーロール1日目から使えるヒント、CTOへのジャンプアップに必要な準備まで、ぎゅっと濃縮してお届けします！
「チームでの協働をいい感じにしたい」「プロダクトの価値を最大最速でデリバリーしたい」と思う開発者の皆さんにとってのぼうけんのしょ＝セーブポイントとなるようなトークを目指します。おたのしみに！

所属するLaunchable, inc.では日本とUSの双方にメンバーがおり時差や言語から同期的に開発を進める事が難しいため、非同期な開発体制をドキュメンテーションによって支えています。
本発表では、Launchableでどのようなドキュメントが書かれ、運用されているのかを紹介します。 私が書くときに考えている事/気をつけている事も併せて紹介できればと思います。

話すこと

• なぜドキュメンテーションを大事にしているのか
• 書かれているドキュメントの種類と運用方法の紹介
• ドキュメント運用の難しさ
• 30/60/90 フィードバック
• etc

深く話さないこと

• いい文章を書けるようになるための方法
• 特定のツール/サービスの詳細な使い方

技術選択と聞いてみなさんはどんな印象を受けますか?
かっこよくてキラキラしている? 難しくて泥臭い?

プロダクトに採用する技術の正解とは何でしょうか? そもそも正解ってあるのでしょうか?

職業ソフトウェアエンジニアとして、人生の大半を費す仕事で触れる技術はなるべくなら楽しく好きなものにしたいです。
しかし同時にプロダクト・事業を成功させることも大切です。

職業人としての「正解」と趣味人としての「正解」は相容れないものなのでしょうか?

このトークでは仕事・趣味を通じてさまざまなプロダクトを立ち上げ・運用してきた体験を通じて「好き」を「正解」に近付けるためのエッセンスについてお話しします。

より詳細には以下のような内容をお話しする予定です:

• 業務で合理的な技術選択を果たすための観点
• 教育や採用・コミュニティ貢献について
• 趣味開発の選択にどのような軸を持つか

Perlに対する最大の誤解の一つに「型がない」というものがあります。実はPerlは単に型があるに留まらず、C言語などと異なり「型安全」ですらあるってご存知でしょうか?Perlの型の扱いは実にユニークで、Perlを主言語としない方もPerlの型を通して型(type)という概念を一段と深く学べるでしょう。

• What is type?
• Static vs Dynamic
• Textual vs Contextual
• Why typed that way?
  • Scalar (≒ Union?)
  • Array, Hash and beyond
  • bless it with the class

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

内容

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

対象

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

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

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

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

主なトピック

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