↓↓↓ 現場レポートはこちら ↓↓↓

北村涼の感想まとめ

①（再演）関数型プログラミングと型システムのメンタルモデル

「関数は〈値の集合Sを別の値の集合に移すもの〉と捉える」という話です。関数型パラダイムを生かし、型を別の状態に変更するのではなく、別の型へ移行させるコードを記述します。
これを意識して組んでいけば、コンパイラでのコードチェックを最大限活かすごとができます。インスタンスの状態がどう変わったのかチェックする必要がありません。つまり、人間が行うべき品質チェックの工数が減るということです。

Webアプリケーションに限らず、スマートフォンのアプリケーションでもオニオンアーキテクチャが採用される場面はよくありますが、それも関数型パラダイムのように IO -> ロジック -> IO という考え方なのだ、と言えます。
この本質は祖結合によってテストしやすい、あるいはロジックを簡単に入れ替えることができる、と言うものではなく、ロジック部分が外界のパラダイムの影響を受けずに、さまざまな振る舞いができるのだ、ということが大きいと言えます。

発表者である naoya さんは、今後のアプリケーションのトレンドとしてはこちらの考えがトレンドになるかもな、という話をされていました。
もちろん全てをこのパラダイムでやろう、というものではなくて、関数型の機能が十分に用意されていない言語の場合は無理にやる必要はなく、そこは言語の特性を元に指針を決めていく必要がある、という話です。

【感想】
「型は集合」というとパッとイメージしづらかったのですが、Typescript の Union 型の話が出た時に腑に落ちました。
名著として知られる『達人プログラマー』では「１年に1つプログラミング言語を学ぼう」という提案がされていることは有名な話ですが、こうやって別パラダイムの言語を学ぶことで、たとえ現在はオブジェクト指向なプログラミングをしていたとしても、美しいコードを書く上で得るものが大きいと改めて感じました。

オニオンアーキテクチャについても、疎結合でテスタブル、ロジックの入れ替えが容易という認識でしたが、IO 部分のパラダイムから切り出された存在とするというのは意識していなかったところでした。

総じて勉強になったセッションでした。

②好きな技術《コト》で、生きていく技術

 技術選択をする上で、面白さという指標を考えてみるセッションでした。
以下、登壇者のaerealさんがお話されていたことの抜粋です。

• 面白さとは無駄に感じられるかもしれないが、採用や士気を考えた時に全くバカにできないモノです。

• この面白さにはさまざまなものがあり、型のパズルであるとか、Perl だとコンテキストクイズなどもあります。

• 注意しなければならないことは、技術選択の正解は存在せず、ケースバイケースです。

• また、技術を使えば問題が解決すると言う幻想も捨てて選択しましょう。

• もし、技術選択をした人がいるのであれば、その人に寄り添い、共に考えていく環境が必要です。

【感想】
技術選択に面白さと言うワードを持ち出したのが興味深いところです。ふだん、エンジニアは無意識のうちに面白さを追い求めていると思うのですが、感情的な部分であるため指標として意識することは少ない気がしています。というのも技術選択はどうしてもメリットデメリットを賢く考えがちだからです。面白さという部分を指標として明確に意識できたのが良かったです。

また「技術選択には何かしらの“大変さ”が伴うものだ」とおっしゃっていたのもその通りで、責任が担当者になりがちなのもまさにそうだなと感じていたところなので、みんなで解決するカルチャーを大事にしてチームを作っていきたいな、と思いました。

③平成のエンジニアから令和のエンジニアへの遺言〜技術情報を伝達する手段の変遷〜

 いくつかのテーマに分かれて、著名な方々がトークをするという内容でした。各テーマで話されていた要旨については以下の通りです。

 # 35年定年説
手を動かさなくなって、エンジニアにとってアンチな立ち位置になる、という問題についてです。
ロールがマネージメントになるにつれて、コードを書かなくて良いと言う誘惑がいっぱい出てくる。言い訳ビリティが上がってく。そのような状況下でも、コードを書き続けられるのでしょうか。

# 生成AI
使わない派、使う派がいらっしゃいました。
使わない派としては、単純に Copilot で生成されるものが遅い。自分で書いた方が早いというもの。

一方で使う派としては、例えば生活の変化によっていかに時間を有効に使うか。その解決策の一つとして、生成AIを利用しているとのことでした。具体的には、「子どもを迎えにいくまでの15分で何ができるか？」となった時に、コードの総量を上げるために利用されています。

 # コミュニティ
コロナ禍になってコミュニティは大きく変化しました。一時的に対面が難しくなったことで、オンライン開催が増えてDiscord の使い方が上手くなっています。しかしながら、Discord では雑談を生むことは難しいので、その点はリアル開催に分があります。
コミュニティでは、初心者の人でも話しやすい雰囲気を作っていくことが重要です。
また初心者の方や一人で参加した方は登壇するのが大事で、そこで自ら発信することでつながりが生まれていくはずです。これはブログやXでも良いでしょう。

【感想】
自分の場合、生成 AI はCopilot での補完や、ChatGPT に struct を作らせたりと便利に使っています。発表者の一人がおっしゃったように、時間が使えなくなってきた場合に単純作業を任せるのには有用であると感じているところです。

個人的に一番意識させられたのはコミュニティでの振る舞いについてです。これまで技術発表はしてきましたが、コミュニティ活動は不足していました。自分一人で技術力を磨くことも大事ですが、他者とコラボレーションすることでより良い学びに繋げていくことができるはずです。意識していきたいと思いました。

 ③キーノート

 とほほさんの歩みと、「とほほのWWW入門」誕生と変遷を辿るセッションでした。
コモドールVIC-1001 でのコーディングから始まり、PC-8801mkⅡSR、PC-9801 VM2、Apple II と、時代とともにマシンと技術を経験していく。
常に学び続け仕事をするというだけではなく、学びをアウトプットしたり、意見を言い合えるラウンジを作成したりと、インターネットの黎明期から積極的にコラボレーションを意識した活動をされていました。

とほほのWWW入門にはプログラミングだけではなく、陶磁器や投資など、さまざまなカテゴリでの学びが蓄積されています。その根底には「学びが好き」という、とほほさんの姿勢があります。
また、「とほほアイコン」と呼ばれる黄色いキャラクターには「ポップ君」という名前があることが周知されました。

【感想】
とほほさんの変遷はインターネットの変遷といっても過言ではなく、これは、とほほさんの常に新しいものを学び続ける姿勢が関係しているのは言うまでもありません。
この姿勢が「とほほのWWW入門」を生み出し、これによって日本のインターネットに多大なる貢献を果たしました。とほほさんの Web サイトにお世話になった方も多いことでしょう。

アウトプットする力がすさまじく、その姿勢は自分も見習っていきたいと感じました。

赤倉慎太郎の感想まとめ

 ④入門EOL対応 〜SREが鉄板の流れ全部見せます編〜

 GMOペパボの渡部龍一さんによるセッションでした。EOL対応の意義とメリット、対応プロセスのステップ、EOL対応をモチベーション高く行う方法について話されていました。

【感想】
これまでは、EOLに対して単に「期限切れだから対応しないといけない」という漠然とした考えしか持っていませんでしたが、具体的なリスクを認識した上で、対応内容を体系的にまとめることの重要性を学びました。特に、DREADモデルを用いたEOLの危険度評価手法は、今後の業務でも活用できそうです。

⑤Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用

 面白法人カヤックの藤原俊一郎さんによるセッションでした。ブランチ別の検証環境をAmazon ECSに立ち上げるためのOSS(mirage-ecs)について話されていました。

【感想】
ブランチごとの検証環境の動的な構築は、SREエンジニアにとって一度は直面する問題だと考えます。私も例外ではなく、過去何度もこの課題に取り組んだ経験がありますが、その時点でのインフラ構成や運用に沿った形で構築する必要があり、作業コストがかかることに加え、本来、検証環境を利用するべき非エンジニアが扱うにしては難易度が高めな仕様(UI)になりがちです。

その点、mirage-ecsはECS上のコンテナでサービスを立ち上げることによりインフラの環境差分に対応しやすい上、非エンジニア向けにWebUIが用意されていたり、API経由にすることによりSlackから環境を起動することができたりと、かゆいところに手が届いているツールだと思います。弊社でも導入を検討してもいいかもしれません。

⑥古い技術について—SMTP現代事情つまみ食い—

Cubicrootの 東邦之さんによるセッションでした。現代のSMTPを支える重要な技術について話されていました。

【感想】
最近話題のDMARCについて、なんとなくの挙動は知っていましたが、改めて勉強する良い機会となりました。馴染みのない部分では、送信者のドメインにブランドロゴをDNSレコードに登録して、視覚的に分かりやすく識別できるBIMI（Brand Indicators for Message Identification）という技術に興味が湧きました。 BIMI に対応するメールクライアントでは、送信されたメールの横にブランドロゴが表示されるらしいので、弊社で導入しても面白そうです。

また、メルマガ運用を始める前に、各MTAにスパム判定されないように、メール送信を少しずつ始めておく「ウォームアップ」という手法が新しい発見でした。

松永祐生の感想まとめ

⑦Hono v4

yusukebeさんによるHono v4 に関するお話でした。
Honoは js/tsのフレームワークでjsのランタイムならどこでも動き、すごく軽量という特性を持っています。

【感想】
Honoというフレームワークを初めて知りましたが、率直に言ってめちゃくちゃ面白そうだと思いました。まず、jsのランタイムならどこでも動くというのがすごい。さらにJSXが使えるのでReactの感覚でゴリゴリ書けるのがいいですね。
すごく勢いがあるフレームワークなので、今後の動向に注目です。

⑧コミュニティと共に生きる - キャリアの螺旋と人生を変えた瞬間

 soudai1025さんがこれまでコミュニティと共にキャリアを過ごしてきた中で、どのような出来事がきっかけでチャンスや成長が生まれたかという話でした。

【感想】
特に印象的だったのが計画的偶発性理論の話です。人との接触機会を増やすことでチャンスの機会を増やすというのはとても納得できました。
自分も積極的にコミュニティと関わっていきたいし、もっとアウトプットを増やして色んな人に認知されるのが大事だと思いました。

⑨PerlでつくるフルスクラッチWebAuthn/パスキー認証

mackee_wさんがパスキーをperlで実際に実装しながら説明するというセッションでした。
フルスクラッチなのでパスキーがどのようなフローでどういうデータをやり取りするのかというところまで、細かに説明されていました。

【感想】
パスキーは元からかなり興味がありましたが、ちょうど今自分自身が RIZAPの認証/認可基盤を担当しているため、実際に実装しているのを目の当たりにしたことで「裏でこんな複雑なことをやっているんだな」と驚きました。
特にAttestation Objectがめちゃくちゃ複雑だったので、「後日しっかり復習しなければ」と思っています。
あと、おそらくperlのコードを見たのは初めてだったのですが、普通に何をやっているのかがわかりやすかったです。

⑩平成のエンジニアから令和のエンジニアへの遺言〜技術情報を伝達する手段の変遷〜

 941さん、naoya_itoさん、yusukebeさん、t_wadaさんによるトークセッションでした。

【感想】
終始面白かったのですが、特に印象的だったのが「昔はこうだった」と「最近の若い人は」という話題で出た「マサカリ（技術的な指摘）が少ない」というもの。最近の若い人は消極的で、人から色々言われることを好まないという話も出ていました。「逆に自分は、間違っているところはどんどん突っ込んで欲しいな」と思いながら聞いてました。

naoya_itoさんとt_wadaさんが今でもゴリゴリコードを書いているようなことをおっしゃっていて、自分ももっとアウトプットを頑張らないと、と改めて思いました。

（了）