トーク

皆さん、自分の大切なデバイスが壊れたときどうしますか？

2023年初頭、私が約10年間愛用していたキーボードが壊れてしまいました。私はそれまで電子工作には明るくなく、自作キーボードのキットを一度組んだことがある程度でした。しかし、愛着のあるキーボードをなんとかして直して使い続けたいという強い思いがありました。どうにか直せないかと、自作・カスタムキーボードのコミュニティの情報を集めていく中で、PicoRubyという組み込み向けのRuby処理系と、それを利用したprk_firmwareというキーボードファームウェアのことを知り、これを使ってキーボードを直してみることにしました。

本トークでは、実際に私が行ったステップや必要な部品・工具を紹介しながら、みなさんが愛着のあるデバイスを修理したくなったときに参考になるであろう情報を網羅的にお話します。

Webアプリケーションを開発・運用していく中で、1つのテーブルに日時カラムが増えていったり、巨大なテーブルが爆誕した、という経験はありませんか。また、これがプログラムの複雑さに繋がることもあると思います。このような事態を避けるために、私は、モデリングが重要なのではないかと考えています。

モデリングについては、DDD、sudo モデリング、イベントストーミング、UML図、アンチパターンなど、様々な概念や手法、ツール、書籍などを参考にすることができます。
しかし、モデルやテーブルの単位まで落とし込む際には、メンバーの経験や価値観によって解釈が異なり、意見が合わないこともあるのではないでしょうか。

Theory of Models(TM)は、前身となるＴ字形ER法を数学基礎論の観点から見直し、再体系化された技術体系です。誰が作成しても同じモデル構造になるように、規則に従ってモデリングするのが特徴です。

銀の弾丸、とまではいかないかもしれませんが、モデリングの指針となり得るものだと、私は考えています。

本セッションでは、2022年に発売された書籍「事業分析・データ設計のためのモデル作成技術入門」の内容をもとに、個人開発で試してみた経験も踏まえて、なるべく噛み砕いてお話ししたいと思います。

対象者

• モデリングしたが、これで良いか不安になったことがある人
• モデリングの合意形成で苦労したことがある人
• モデリングの社内規約をつくりたい人

話す内容

• Theory of Models(TM) のモデル作成技術
  • 個体指定子（番号やコード、ID など）を使ってモノの集まりをつくる
  • モノをイベントとそれ以外に分けて、並べる
  • ルールに従って、モノとモノとの関係を構成する
  • ...etc
• 個人開発で実践したフィードバック

みなさん、アプリで本人確認をしたことがありますか？最近では不正対策の一つとして本人確認がいろいろなサービスに組み込まれています。例えばライブのチケットを購入する際に写真のアップロードを求められたり、フリマアプリのようなC2Cサービスで本人確認が必要だったりと、一度は経験したことがあるのではないでしょうか？

私は2020年から、SmartBankというFintechスタートアップでB/43というプリペイドカードを開発しています。実は日本でプリペイドカードのようなユーザーからお金を預かるサービスを提供する場合、”資金決済法”という法律に準拠する必要があり、その要件の一つとして本人確認が必須となっています。B/43ではアプリを使ってのオンライン本人確認（eKYC）を実装しています。

本人確認には外部サービスも存在する中、我々は0から内製する決断をしました。そしてユーザー向けのアプリ機能の開発から、本人確認業務を行うCS向けの管理画面の開発までを全て内製し、今も運用しています。

本人確認システムでは、身分証の内容や顔写真との一致度チェックをする仕組みを作ったり、数百以上の申請をできるだけ短い日数で確認するなどのオペレーションの生産性が求められます。なぜ内製したのか？本人確認のシステムはどうやったら作れるのか？どのように運用しているのか？などなど、あまり知られてない（と思っている）本人確認システムについてディープな話をしたいと思います。特に自分が実装担当したCS向けの管理画面の開発における工夫点やCSとの協力話などをお伝えしたいです。

• 対象者

  • 普段使っているシステムの裏側がどうなっているのか知りたい人
  • 業務の効率化に向けてCSとエンジニアが頑張った話を聞きたい人

• 話すこと

  • 本人確認システムを内製化した理由
  • 本人確認システムの要件とシステム構成
  • 本人確認業務の内容と運用

React Server Component は、サーバーサイド上でレンダリングされる React コンポーネントです。React Server Component を用いると、コンポーネントの中から DB にアクセスしたり、ファイルシステムにアクセスしたりできます。

一方で、今までにも erb や pug といったテンプレートエンジンのように、サーバーサイド上でテンプレートをレンダリングする技術というのは存在しました。また、React でも SSR を用いれば、(Client) Component をサーバー上でレンダリングできました。そのためこれらの技術とどう違うのか、疑問を抱いている方も多いでしょう。

しかし、React Server Component は従来の技術への単なる回帰ではありません。今まで存在していたいくつもの問題を解決し、優れた開発体験をもたらす技術なのです。

このトークでは、React Server Compomnent とは何か、どんなことができるのか、そして従来の技術とどう違うのか、どう開発スタイルが変わるのかについて話します。このトークが、React Server Component に関する様々な疑問を解消する手助けになるはずです。

内容

• React Server Component とはなにか
• SSR の限界と React Server Component が登場した理由
• React Server Component でできるようになったこと
• 従来の技術との比較
  • 振り子なのか、螺旋なのか
• React Server Component により、どう開発スタイルが変化するのか

サービスの運用がインフラエンジニアだけの仕事になっていませんか？

はてなの各プロダクト開発チームでは、「PWG (Performance Working Group)」という会をチーム全員で月次で開催しています。

この PWG では、Mackerelのダッシュボードを活用して、最近のパフォーマンスの変化を共有し、キャパシティプランニングを行います。インフラエンジニアだけでなくチーム全員 (非エンジニアも含む) でグラフを眺めることにより、以下のような非常に良い効果があります。

• インフラやパフォーマンスに関する問題の早期発見と迅速な対応
• インフラの改善作業が特定の人のものではなく、チームの仕事になる
• チーム全体で、ユーザ影響が出たイベントに対しての感度や理解度が上がっていく
• 毎月育っていく、効果的なダッシュボードを構築できる

本トークでは、PWG の具体的な取り組みとその効果を紹介します。
ぜひご参加いただき、チームでダッシュボードを育てる感覚を手に入れて帰ってください。

-

キーワード

CLI, YAML, コード生成, 静的型付け, Go言語

概要

CLI（Command Line Interface）を備えたコンソールアプリケーションを開発する際には、CLIを定義・解釈する仕組みが必要となります。この仕組みを実現するために、私は「cyamli」という名前のCLIジェネレータを開発しました。「cyamli」は、YAMLファイルに記述されたCLIスキーマに基づき、型付けされたCLIを扱うためのコードを生成します。

本発表では、「cyamli」について詳しく紹介したいと考えています。具体的には、まず以下の「cyamli」の特徴について説明します。

1. コマンドライン引数の定義・解釈：CLIとして、サブコマンド、オプション引数、位置引数で構成されるコマンドライン引数を定義・解釈することができます。
2. 型付けされたCLI：生成されるコードは、型付けされたCLIを適切に扱えるため、静的チェックやコード補完といった機能を活用できます。
3. 情報源の集約：CLIのスキーマの情報源をYAMLファイルに集約して管理できるため、コードの一貫性を維持しやすくなります。
4. 様々な出力形式：現時点で、GoとPython3をサポートしており、テキストおよびMarkdown形式のヘルプメッセージも出力できます。

さらに、以下の内容についてイメージしてもらえるように、実際にデモンストレーションを実施して、例を示しながら解説したいと考えています。

1. CLIスキーマをどのように定義するのか
2. どのようなコードが生成されるのか
3. 生成されたコードをどのように利用するのか

対象者

以下のような方々に興味を持っていただけると思います。

• Go言語を使う方
• コンソールアプリケーションを開発する方
• スキーマ駆動開発に興味のある方

リファレンス

• https://github.com/Jumpaku/cyamli

Linux を Browser 上で動かしてみたい。そう思ったことはないでしょうか。
自分も過去に何度も挑戦したのがその度に挫折していました。
理解すべき項目の多さももちろんのことながら、こういった個人プロジェクトの最大の敵は「飽き」だと考えています。

ですが、最近約 1000 行で飽きる前に達成できる構成を見つけたためその内容を紹介いたします。

本プロジェクトはrv32ima NOMMUをtargetにエミュレータをRustで書きWebAssemblyにてbrowser上で動作させています。
Rustに関してはZero Dependenciesとなっており、各言語の行数は以下のようになっています。

 Language            Files        Lines         Code 
========================================================
 JavaScript              1          210          191    
--------------------------------------------------------
 HTML                    1           18           18    
---------------------------------------------------------
 Rust                   13         1146          971    
=========================================================
 Total                  15         1374         1180    

実現にはどのような機能をどのように実装していくのか。
困ったところ、面白かったところはどのようなところか。
などをお話しする予定です。

話す内容

• rv32imaやMMU、CLINTについて
• deviceTreeやUARTについて
• WebAssemblyやasyncifyについて
• 困ったことや面白かったことについて