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

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

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

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

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

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

というものでした。

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

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

RubyKaigi 2023 の前日に KeebKaigi 2023 があったりと、盛り上がっている自作キーボードの世界
私は C でも Python でも Ruby でもない選択肢として Go (TinyGo) で自作キーボードを作っています
自作キーボードと言えば、たくさんの人が各々の楽しみ方をしています
ここでは、自分で自作キーボードを作って来た一年を振り返り、ソフトウェア、ハードウェアともに事例共有します

自分で使うツールやライブラリを自分で作る、のはとても楽しいです
それが自作キーボードという物理デバイスだと、いつもとは違う楽しさがあります

以下のキーワードでお話します

• 自作キーボードの仕組み
• 思ったより簡単に自作キーボードは作れる
• 基板を設計してプロトタイプする
• ファームウェアの設計

IDはある要素を一意に特定する、まさに識別子です。
WebアプリケーションにおいてはMySQLのAUTO_INCREMENT属性やPostgreSQLのSERIAL型といったDBによる採番をIDとする方法がよく知られています。しかし、時にはそれでは機能要件を満たせないことがあります。
最近、私は2つのIDを決める場にいました。
1つは分散システム内で使うID、もう1つはOSSのツールの中で使うIDです。
前者はDBのトランザクション内に収まらないフローがある、後者はツール実行環境が1種類に限定されないという特徴があります。
どちらも数値のインクリメントによる採番では要件を満たせないと判断し、改めてIDの生成方法の検討をしました。
本発表ではそれぞれの事例でどのような課題があり、解決したのかを紹介します。

IDというみなさんに馴染みのある要素で、私の「お好み」を共有できればと思います。

我々エンジニアは仕事の多くの時間を人への質問に使っています. その手法はテキストチャットツールや文書ツールなどの非同期的な方法やビデオツールやオフラインでの会議などの同期的な方法など多種多様です.
ですが, 「合理的なツール選択」と「核心をついた質問」によって成果(情報の取得や意思決定)を安定して出せる人は少ないのではないでしょうか.
本セッションでは以下の項目について話すことで, 質問に関わる知識と質問について改めて考える機会を提供します.

話すこと

• 質問をする意義
• 良い質問と良くない質問
• 質問をする前に考えること => 質問の核心を探す方法
• 質問する時に考える手段 => 各ツールの使い分け
• 質問・相談できる環境を作ること => 普段の交流・オフラインの交流の大切さ

話さないこと

• アジャイルやスクラムなど開発手法の話

セッション概要

「ぜんぜんわからない、俺たちは雰囲気でエンジニアをやっている」と思ったことはありませんか？

技術の世界は急速に進化し、新しいツールやトレンドが日々登場しますが、それらを理解し使いこなしていくには基礎力が必要であると痛感することがままあります。
インフラ基盤がどのように機能し、ビジネスやプロジェクトにどのように影響を与えるのかを理解することは、エンジニアとしての成功に欠かせません。

本セッションで、雰囲気ではなく基礎を理解して技術と向き合うエンジニアになるための取っ掛かりを掴んでもらうために、インフラ知識の入門的内容をできるだけ網羅的にお話します。

話す予定の内容

• そもそもインフラって何？
• インフラを構成する要素
• ネットワークとサーバ
• 今後も学び続けるためには

弊社（株式会社DeNA）サービス「Mobage（モバゲー）」はPerlで開発されており、もちろんメンバーもほぼPerlユーザーです。
しかしクラウドアーキテクトである私から見て、2年前にAWSに完全移行したにも関わらず、なかなかチームにクラウドが浸透しないことが疑問でした。

その原因を考えた時に「AWS LambdaでPerlが動かないことが原因では？」と思い、「やっぱり好きなPerlで開発したいよね！」ということで、AWS LambdaでPerlを動かせるような仕組みを作りました。
今回はそんな「AWS LambdaをPerlでコーディングできるようにする方法」について、弊社での私の事例を参考にお話ししたいと思います。

内容としては、AWS Lambdaの「カスタムランタイム」のお話が中心になると思いますが、それ以外の技術も扱う予定ですので、幅広く参考になると思います。

皆様、初めての開発体験を振り返ってみませんか？
私は10年前、新卒エンジニアとして初めてのフルスクラッチ開発プロジェクトに携わりました。
そのプロジェクトはPerlを使用した組み込みシステムの開発で、当時の技術状況や経験を通じて学んだことが多くありました。
このセッションでは、私の初めてのPerl開発体験を振り返り、プロジェクトで得た知見や反省点を共有したいと思います。

話すこと
・10年前の技術界隈
・初めてのPerl開発体験
・プロジェクトから得た学びとその後

話さないこと
・最近のPerlの話はしません。

どうぞ、このセッションにご参加いただき、一緒に初めての開発体験からの成長を振り返りましょう。
皆様のご参加をお待ちしております。