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でこんなことができます

チームでWebサービスを開発する場合、複数の機能やデータを持つブランチが並行して開発されます。チームのメンバーなら職種を問わず、好きなだけブランチ別の環境を起動できる仕組みがあると、開発と動作確認のサイクルを高速に回すことができます。

そのような仕組みを実現するために、IaCでサーバーリソース一式を丸ごと構築すると、起動までの時間や金銭的なコストが大きくなってしまいます。

mirage-ecs(github.com/acidlemon/mirage-ecs)は、Webサービスの検証環境を誰でも、何個でも、低コストで立ち上げるためのOSSです。 「環境」はAmazon ECSのタスクとして数分で起動し、専用のURLでアクセスできるようになります。

開発者がその原理と実装、数十人の開発チームを持つ複数プロダクトにおける運用で得られた知見についてお話します。

セッション概要

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

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

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

話す予定の内容

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

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

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

話すこと

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

対象者

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

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

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

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

10年以上前に「タワレコ店員からエンジニアになって思ったこと」というスライドを書きました。

そこからさらに10年が経ち、今は OSS のメンテナやプロジェクトリーダー、マネージャなどやれることも少しずつ広がってきました。
気がつけば「プログラマー35歳定年説」を超える年齢となりましたが、今でもコードを書くことを仕事として楽しんでいます。

このトークでは、これまでのキャリア（業務、OSS、転職、同僚）における失敗や成功を通じて学んだことや、大事にするようになった考え方を紹介したいと思います。
また、私自身 Perl や YAPC、コミュニティからも学んだことも多くあるのでそれについても感謝も込めて紹介できればと思います。

エンジニアとしてこれからやっていけるか不安を持っていたりキャリアに悩んでいたりする方に、大丈夫、楽しもうと思ってもらえるようなトークになればと思っています。

皆さんは普段どんなプログラミング言語を使っているでしょうか
golangなどのコンパルする言語もありますが、Perlを始めとするスクリプト言語を使っている方も多いでしょう。
現代のスクリプト言語は実行時にスクリプト言語のソースコードを、言語内独自のVMが実行可能なアセンブラのような命令にコンパイルし、その結果を実行する方式が多いです。つまり、現代においてはスクリプト言語を実装するということはほぼCPUの命令実行シーケンスを実装することと同義です。

特に最近は一部界隈ではRubyの処理系であるRubyVMを実装するのが流行っています。

本トークではRubyVMをPerl...ではなくて、Raku(旧Perl6)で実装し、Rakulangの言語の面白さとRubyVMの実装の面白さについて見ていきます。
なお現時点でコードはほとんど書いてないので当日までに完成するかは......。お楽しみに

弊社（株式会社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%ルールのように、”余白” が非連続な成果を生み出すかもしれません。

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

主なトピック

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

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

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

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

対象者

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

今日、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 高速に全文検索したい人向けの発表です。