職場で 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というみなさんに馴染みのある要素で、私の「お好み」を共有できればと思います。

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

話すこと

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

話さないこと

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

1993年にまつもとゆきひろ氏によって開発されたプログラミング言語Rubyは、Perl, Smalltalk, LISPなどの影響を受けながらも独自の魅力を持ち、日本をはじめ世界で利用されています。
私はこの10年Rubyを使い続けてきましたし、今後も使い続けるつもりでいます。このように「Rubyに対してお客様以上の気持ちを持っているプログラマーのこと」をRubyistといいますが、その意味で私はRubyistです。RubyにRubyの何が私を惹き付けるのか。このトークは以下の内容で構成されています。

1. Rubyとはどのような言語か、Rubyの現在位置
2. Rubyの魅力を考察する
3. Rubyでこんなことができます

セッション概要

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

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

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

話す予定の内容

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

経済産業省作成のレポートによると、パブリッククラウドの利用料を中心とする「デジタル赤字」は2030年には8兆円を超えるともいわれています。
円安も続くいま、クラウドコストの「最適化」に留まらず、より強気な「削減」を行わざるを得なくなることも予想されます。

今回は、私たちがコスト削減代行を100社以上行ってきたノウハウをもとに、
きれいごとではなく、何が何でも1ドルでも減らすための活きた「ケモノ道」的テクニックを紹介します。

話すこと

• 具体的な削減手法の実例
  • アプリケーションのチューニング
  • リアーキテクチャ
  • インスタンス最新化
  • 通信経路最適化 and more...

対象者

• パブリッククラウドでサービスを展開している方

※あらゆるパブリッククラウドに通ずることについて発表したいとは思っていますが、事例はAWSに関するものになります。

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

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

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

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

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

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

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

概要

カンファレンスや勉強会に参加して感動したり、あなたの人生を変えるような何かに出会ったことありますか？
あなたが好きだと感じたその場所が、いつか衰退して永久に失われてしまったら悲しいですよね。
しかしあなたは自身の"LIKE"を守るためいつでも行動をおこすことができます。
このセッションでは、コミュニティ運営を事例にして、自身が成し遂げたいと思った"LIKE"を実現に導くための道のりを紐解きます。
私が複数コミュニティを運営するなかでどんな困難を感じてどう乗り越えてきたかなどの経験を踏まえながら、何かを始めたり継続するために必要なマインドや行動のエッセンシャルをお伝えします。

アジェンダ

• "LIKE"を言語化し伝えよう
• "LIKE"を実現するために行動しよう
• もしも挫折したときは

“余白”のない開発を経験したことはありますか？
破綻と隣り合わせの綱渡りスケジュール、山盛りの要件と機能仕様、いつまでも解消されない負債、そこに発生する割り込みのインシデント対応…ぐわあああああ！
”余白” を作っておいたはずなのに、気付いたら空っぽになっていることも少なくありません。

“余白” がなければ、リファクタやテストコードのメンテナンスなどが滞って、生産性が落ちていくかもしれません。
“余白” があれば、インシデントで1日潰れても、スケジュールを引き直す必要はないかもしれません。

20%ルールのように、”余白” が非連続な成果を生み出すかもしれません。

“余白” を愛する全ての人へ
”余白” を手に入れるための戦いをはじめましょう

主なトピック

• なぜ “余白” が失われるのか
• 事業価値から考える “余白”
• “余白” の楽しみ方

今日、OSSでも社内のインターナルなプロジェクトでも、重要なソフトウェアは歴史が長く大きく複雑で、いわゆる "レガシー" なソフトウェアが増えてきています。これらのソフトウェアは、重要であるにも関わらず、ドキュメントが不足していたり、当時は良いとされていた設計が時代遅れになっていたりするなど、様々な理由により理解するのが難しい。

すばやくソースコードを理解し分析することは、レガシーなソフトウェアにおける複雑な問題を解決したり、オーナーシップをとったり、はたまたオープンソースに貢献したり、モノリスを分解したり、あるいは未知のドメインでのコードレビューを行うときに重要なスキルとなります。

この発表では、プログラム理解に関する質的研究と、私がOSSやレガシーソフトウェアの開発に貢献してきた経験をもとに、どのように巨大なソフトウェアに対して取り組んでいけばよいのかについて紹介します。

弊社では30days Albumという写真をアルバム形式で共有できるサービスを運用しています。
これまで本サービスは独自にハウジング契約したデータセンターで運用してきましたが、GMOインターネットグループのシナジーを活かすために、グループで契約されたデータセンターへ全てのサーバを移設することにしました。しかし、本プロジェクトは期限とコストが非常に限られた中で完遂する必要がありました。また、このサービスでは4ペタバイトを超える巨大なストレージをオンプレミスで保有しており、この移設も大きな課題として立ちはだかりました。様々な手法を検討した結果、搬送業者に依頼してトラックに全サーバを載せて物理的に一斉搬送するというめったに聞かない（と思われる）手法をとりました。
本トークでは移設に踏み切った経緯、破損事故などのリスクを踏まえてどのように一斉搬送したのかお話しします。

好きなものは何かと問われても、そんなの一つに決められない。
ソフトウェアエンジニアならOSもプログラミング言語も開発環境だって好きな人は多いはず。

そんな中、マイブームを上げるならNixです。NixはOSでもあり、パッケージマネージャでもあり、プログラミング言語でもあります。
1つで3つ美味しいじゃないですか。

というわけで今回、パッケージマネージャについて話したいと思いました。
AptやHomebrewのようなシステムパッケージはもちろん、プログラミング言語のパッケージモジュールを管理するのもパッケージマネージャと言えるでしょう。PerlならCPANです。
そこで、パッケージマネージャの基本からさまざまなパッケージマネージャと、ついでにその終着点の一つともいえるNixの魅力について簡単に紹介したいと思います。

世の中にはたくさんのマイクロサービスの導入例が紹介されていますが、その中のうちどれぐらいのサービスが今も生き残り、また成長を阻害するような痛みが解消され、開発が続けられているかはあまり知られていないように思えます。

面白法人カヤックが運営するeスポーツイベント運営のためのサービス「Tonamel」では3年前からマイクロサービスを導入し、今もまだサービスの成長と機能の拡張を続けています。
導入から3年経ち、もともとあったレガシーなアプリケーションから大半の機能が、マイクロサービスで新たに実装され直した部分へと移されました。この結果、サービスとしての安定性を保ちつつ、機能実装のスピードの向上などの効果が目に見えて出てきていると実感します。
そこで、生き残ったマイクロサービスで、どうして生き残ったのかをマイクロサービス導入の当初から携わるアーキテクトである私が考察し紹介します。

PostgreSQLで素朴に全文検索をする場合、LIKE演算子を使った中間一致になります。
デフォルトのPostgreSQLでは、LIKE演算子を使った中間一致検索にはインデックスを使用できないため、データ量に比例して検索速度は低速になります。

PGroonga(ぴーじーるんが)は、全言語対応の高速な全文検索機能をPostgreSQLで使えるようにする拡張です。
PGroongaでは、英数字も日本語等のマルチバイト文字に対してもインデックスを使った全文検索が可能です。検索速度は非常に高速で、かつ高機能です。
本発表では、PGroongaがどのくらい速いのか、どのような便利機能を持っているのかを紹介します。

本発表は、PGroongaのことをまだ知らない or PGroongaに興味はある（聞いたことはある）が詳しいことはしらない人 or 高速に全文検索したい人向けの発表です。

「自分で管理しているシステムなら、手を加えられるけど、外部のサービスやウェブサイトはどうしても手を出せない…」こんなもどかしい経験、一度や二度はしたことがありませんか？しかし、プログラムを書くことにそれほど抵抗がないのであれば、ブラウザ拡張機能を自ら作成することが、この問題への解決策のひとつになります。

このセッションでは、ブラウザ拡張機能の開発の魅力を、実際の開発エピソードを交えて紹介します。外部サービスも、自分の手でカスタマイズし、使い勝手を向上させたり、効率を良くするアプローチを紹介します。そして、初めての拡張機能開発でも迷わないステップや、作成にあたっての考え方も紹介します。

プログラミングのスキルを活かして、ウェブの世界をもっと自分好みに、もっと効率的にしませんか？外部のサービスに自分の手を加えて、毎日の業務やブラウジング体験を向上させる方法を手に入れましょう。

みなさん、好きな言語や好きな技術はありますか？ その技術を使って開発した経験は？
…働くようになってから、「技術と初めて出会った時のようなトキメキ」はまだ残っていますか？

個人開発をしたい（している）けれど、”作るものが思い浮かばない”という壁にぶつかる人も多いでしょう。
かく言う私もその中の1人です。

このセッションでは、普段ハッカソンの運営をしている私が出会った「好きなものを使って」「好きなように開発する」学生たちの事例をもとに、凝り固まった考えを捨てて開発する”お遊び開発のススメ”についてご紹介します。

話すこと

• 過去に学生や私が開発したプロダクト（一部抜粋）で紹介
• 凝り固まった考えを捨てるには

話さないこと

• 個人開発のやり方
• プロダクトに関する”詳細な”技術話

対象者

• 若者のパワーが欲しい方
• アイデアの刺激を受けたい方

twitter(X)に何かあるたびに話題になるmastodonやmisskeyのような非中央集権型マイクロブログサービスが構成するネットワークは"fediverse"と呼ばれます。これらは主にActivityPubというプロトコルで接続されていますが、ActivityPub仕様は大枠を定めているだけであり、実際に現在のfediverseに参加するには単にプロトコルの仕様書に書かれていること以上のノウハウが必要になります。

このトークでは、Perl版ActivityPubサーバ"Actub"を紹介しながら、fediverseに参加するサーバアプリを作成するために必要なノウハウについて概説します。

内容としては、Builderscon 2019で発表したものをベースとして、Perlでの実装方法と、その後のfediverse界隈の変化に対応した最新の状況についてお話しします。

Site Reliability Engineering (SRE)が近年話題ですね？SRE本が出てから早6年、既に「近年」ではないという説もありますが、ますます盛り上がってきている分野であります。
SREというロールがあるにせよないにせよ、皆さんも似たようなことは日頃やっているはずです。
他の人がどんなSRE的取り組みをしているか気になりませんか？気になりますよね？

LINE スタンプという、多くのユーザーがいるサービスで、実際に日々行っている(比較的小さな)SRE的な取り組みをご紹介します！

対象

• SREというロールで仕事をしている人
• SREというロールではないけどDevOpsとかそういう仕事をしている人
• SREというロールの人がどんな仕事をしているか気になる人