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

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

話すこと

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

話さないこと

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

セッション概要

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

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

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

話す予定の内容

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

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

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

弊社（株式会社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年経ち、もともとあったレガシーなアプリケーションから大半の機能が、マイクロサービスで新たに実装され直した部分へと移されました。この結果、サービスとしての安定性を保ちつつ、機能実装のスピードの向上などの効果が目に見えて出てきていると実感します。
そこで、生き残ったマイクロサービスで、どうして生き残ったのかをマイクロサービス導入の当初から携わるアーキテクトである私が考察し紹介します。

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

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

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

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

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

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

話すこと

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

話さないこと

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

対象者

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

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

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

対象

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

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

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

皆さんはUIの実装を楽しんでますか？マークアップ、Webフロントエンド、GUI、ネイティブアプリ等、ドメインや技術は様々ですが、アプリケーションには必ずUIがあり、それを実装する作業があります。このUI実装の技術についてはよく語られる一方、UI実装者のモチベーションについてはあまり語られていません。本セッションでは発表者の15年ほどUIに関わってきた経験を通して、UI実装の魅力やどのように楽しめばいいのかをご紹介します。

話すこと

• UI実装のモチベーション
• UI実装技術の歴史
• UI実装とUIデザインの関係

対象者

• UI実装が楽しい人
• UI実装が楽しくない人
• UI実装者のモチベーションを知りたい人