データベースの寿命はアプリケーションより長い。
そんなサービスのコアにあるデータベースですが、日々進化しています。

NewDBと呼ばれる新しいデータベースソフトウェアの躍進が注目される中、多くの現場ではRDBMSを使っているのではないでしょうか？
そこで今回は、皆さんの身近にあるRDBMSのこれまでの進化と未来の姿を紹介します。

話すこと

• PostgreSQLの進化と便利機能
• ChatGPTに連携するためのベクトルデータ
• PostgreSQLの拡張の世界
• 明日から使えるPostgreSQLのTips

話さないこと

• MySQLをはじめとした別のRDBMSついて
• NoSQL、NewSQLについて
• データベース設計
• アプリケーション設計

皆さんは「無理」に挑戦していますか？

自身のキャリアとしても、自己実現しやすい環境、しづらい環境はあると思います。
例として「権限」が原因で「不可能」である状態です。
「自分で予算を管理してプロダクトやチームを運営したいなど様々な権限がある中で、
「権限がないからしょうがない」と捉えるのではなく、「権限をもらえるためにどう行動するか」や「権限がもらえる環境はどこか」を考えることが重要です。
なぜなら、この環境を受容してしまうと「権限がないので無理」と言う免罪符のもと働くことになり、いつしかこれが当たり前となり成長機会の損失につながる恐れがあるからです。

上記のように自身のキャリアとして、今の環境が本当に自身の自己実現に寄与しているのかを図るための指標として
「無理に挑戦できる環境か」
を提案させていただきたいです。

何らかの技術の理解を深めるのに、最も適した方法はなんでしょうか。
私は、その技術のサブセットを実装することだと信じています。
Perl、ひいてはプログラミング言語というものを理解するために、Perl 言語のサブセットを実装しましょう。
機能が少ない言語の言語処理系は、皆さんの想像よりも簡単に作ることができます。

話すこと

Perl で作る Perl 処理系（のサブセット）の作り方
必要なソースコードはすべて公開され、このトークを聞かれた方が同じものを作成できるように構成します。

話さないこと

以下は実用的な言語処理系を支える重要な要素ですが、このトークでは意図的に省き、より実装が簡易な手法で代替します。

• LR 法のような実用的な構文解析手法
• 仮想機械

Goは2012年に1.0がリリースされる際に後方互換を保つルールが設定され、毎年2回のペースで後方互換を維持したままリリースされています。またそれに加え、近年では互換を保ちやすくするための機能がいくつか導入され、当面は2.0がリリースされることはないとGoチームが明言しています。例えば、1.22ではfor文の仕様が変わりましたが、1.21ですでに導入されていた互換性の強化によって、破壊的変更には繋がらずリリースできました。

Goに限らず、ソフトウェアを開発する上で互換性を保つことは重要で、ちゃんと意識することで、大胆なアップデートやリリースを行え、よりユーザに高い価値を提供できます。

本セッションでは、Goがどのような意図で1つ1つの機能を積み上げて後方互換性を強化したのかを紹介します。Goに親しんでいる人やそうでない人も、一緒に後方互換性からプロダクトの未来を作る方法を学びましょう。

私の所属するNekko Cloud Teamでは、VPNでメンバーの自宅サーバを接続し、プライベートクラウドを構築しています。
ProxmoxでIaaS環境を運用しているのですが、手作業でVMを作成する工程は冗長であり、時間のかかる面倒な作業でした。

そこで、我々は「VMを作成する工程」をトイルとし、VM用プロビジョニングツール「Terrakko」を作成しました。
今回は、Terrakkoプロジェクトを通して、Nekko Cloud TeamにPlatform Engineeringという考え方をもたらす過程を紹介します。

アジェンダ：

• Proxmox VEのVM構築
• Terraformとcloud-initでVM構築を自動化
• IaCツールの導入とFB
• メンバーの認知負荷を下げる工夫
• Terrakkoの仕様設計
• Terrakkoの導入とFB
• おわりに

自分が初めてPerlに触れたのは、大学での研究室配属に際して出された事前課題でした
確か、類似画像検索システムの構築をするお題で、何らかのスクリプト言語を使用することが条件で、これがPerlとの最初の出会いだったと思います
つまりは、自分のエンジニアとしてのキャリアの起点がPerlといっても過言ではない、ような気がしています

そこで本講演では、エンジニア・リサーチャーとして、大学での3年、企業での7年間のキャリアを積み重ねて、今年でちょうど10年目を迎えるということもあり、これまで携わった研究開発事例を増し増しで、その時に利用した技術スタックベースに振り返りをします
具体的には、生成AIや以下を含む事例について言及します

・ノーコード時系列データ分析ツール：https://nodeai.io/
・ドラレコ映像解析：https://iotnews.jp/maas-case/108219/

今から約50年前、カール・ヒューイットによって提唱されたアクターモデルは、
50年の時を経て再び現代のシステム設計において世界中で脚光を浴びています。

このセッションでは、まずアクターモデルの歴史的背景に触れ、その基本的な考え方を理解しながら、
50年後の現在において、当時の並行計算の限界を克服するための革新的なアイデアが、
どのように現代の複雑なシステムにおいて役立っているのか、どのような影響を及ぼしているのかを探ります。

アクターモデルの歴史的背景から現代への応用までの道のりを、
まるで未知の大陸を再発見する旅のように感じ、
過去の知識を新たな視点で理解し、未来のシステム設計に活かすための冒険に一緒に出かけましょう。
この旅を通じて、アクターモデルの奥深さと、その持つ無限の可能性に触れることができれば幸いです！

Ruby on Railsがリリースされたのは2004年。Perlで馴染みのあるCatalystは2005年です。かたやNext.jsは2016年。では、今、Webフレームワークを作るとしたらどのようなフレームワークをつくるでしょうか？

僕にとってその答えがHonoです。実はHonoはPerlのMojoliciousから強く影響を受けています。一方で強力なTypeScriptサポートやReact互換を入れたりと攻めています。

今回はHonoを題材に、この時代にWebフレームワークを作るとしたら過去から何を学び、未来に何を提案できるのかを考えます。

• Web StandardsとPSGI/Plack
• ORMはいるのかどうか
• バリデータを移譲する
• ミドルウェアとヘルパー
• 型をRPCとして使う
• Rooter::Boomは速い
• テンプレートエンジンの代わりにJSX

「未来」を切り拓くようなプロダクトの開発は、得てして「未知」な状態からスタートします。
例えば、どのような技術が必要か、法的な制約はなにか、どのようなリスクがあるのか、だれも何もわからないといった状況です。
そのような状況下で、未知を既知にしていき、プロダクトを適切に開発するには、どのようなアクションが必要でしょうか。

この発表では、わたしがキャッシュレス決済サービスの立ち上げからエンハンスに関わる中で得た、未知のプロダクト開発に立ち向かうための術をお話します。
話したいこと:
・事業ドメインを深く理解するためのノウハウと活用方法
・仕様書もない中で未知なシステムを作るための戦略
・未知だらけの開発でどうチームとして協調するか
・未知のプロダクト開発に挑む際のマインドセット

ユーザーインターフェイス（UI）は全てのユーザーが製品に触れるための重要な境界であり、これがなければ製品は成立しません。現代においてはUIデザイナーという専門職が確立されていますが、様々な事情により、エンジニアがUIデザインを担当する場面も少なくありません。例えば、創業期にはUIデザイナーを雇う余裕がない場合や、デザイナーがいてもリソースが不足している場合などが挙げられます。この発表では、突然UIデザインを任されたエンジニアの皆さんに向けて、どのように仕事を進めるべきかの指針を示します。

含まれる話題

• 発表者のフロントエンドエンジニアとUIデザイナーの兼業経験
• ユーザーのメンタルモデルを理解し獲得する方法
• 実用的な70点のUIを仕上げる方法
• エンジニアがUIデザインを学ぶことの未来像

含まれない話題

• ブランドデザイン
• 大規模組織でのデザインシステム

過去作られたコードに最大のリスペクトをしつつも、サービスの成長とともに少しずつ技術的負債が溜まっていくことは多いと思います。
弊社も開発と並行した改善を続けていましたが、一度立ち止まって考え、１ヶ月の間、「品質UP」に全エンジニアのリソースを集中させる意思決定をしました。
本発表では、コアドメインとなる「予約 / 決済」機能を中心に、実施した具体的な取り組みとポイントを共有したいと思います。
品質を諦めず、今後の体制強化に取り組んだこと、そして未来への施策が、「Open the future」のきっかけになりますと幸いです。

＜話すこと＞
・経営陣やビジネスマネージャーの理解を得て意思決定した話
・全ての因子（テストすべきテスト条件）の洗い出し　〜　シナリオテストの作成　〜　Rspec、コンポーネントテスト作成の話
・未来を切り拓く開発プロセス改善の話
・得られた副次的効果

メルカリグループの提供する決済サービス「メルペイ」では「クレジットカード」「プリペイドカード」「コード決済」「ネット決済」など様々な支払い手段を提供しており、メルカリでの売上金で支払ったり、銀行口座と接続したり、与信枠を使って決済することができます。
(他にも変動する還元率や個人間送金の機能なども持っています。)

特にクレジットカードである「メルカード」は提供から約1年4ヶ月で300万枚を超えて発行され、利用されています。
決済サービスでは高い信頼性とデータ整合性が求められますが、我々がどのようなアーキテクチャおよび技術を用いてこれらを達成しているのか、そもそも決済サービスはどのような仕組みで成り立っているのかということを解説し、最終的にはそれらを俯瞰して未来のキャッシュレス決済について思いを馳せることが本発表の目標です。

人は感情の生き物であり、感動は大きな力を生む。
そして、感動は技術によって作ることが可能です。

本トークでは感情を揺さぶるプレゼンテーションの作り方をお伝えします。どうやって話を組み立て、深く伝えるのかを思考と技術の両面から解説します。

概要

• キーメッセージから始める
• 受け取り手に期待する変化を明確に
• 自身が話す意義を考える
• 登壇ノート作成　アイデアの発散と関連付け
• スライド作成の手引き
  • ネームを切る
  • 感情の波の意識と支配
  • 核となるページを最初に作る
  • 目的別スライド構成のすすめ
  • 書くこと書かないこと
• 落語に学ぶ感情を揺さぶる話法
• 細部にこだわる
  • ノイズの削減
  • 環境別スライド構成のすすめ

未来を切り拓く力になるよう、私の持つ知識と技術を贈ります。

Azure が信頼性を向上・維持するためにどのようなサービスや取り組みを提供しているかAzureのエンジニアリングチームとしての視点で紹介します。
どのサービスや機能を使いどのようにサービスの信頼性を上げていけばよいかもお話ししたいと思います。

• Safe Deployment Practiceによるリリース管理
• Project Tardigrade/Project Narya/Project Flashによる基盤の障害検知、回復性向上
• 認証基盤の回復性を上げるための仕組み
• Azure Boostによるハードウェアのオフロード
• CXPチームによるオンボードから運用までの改善
• 実装の実際
  • SLA/RPO/RTOの定義、ワークロードの優先順位付け
  • Azure Advisorによるサービスの可視化
  • その他実装のTips

大規模言語モデル（LLM）は、今や多くの企業や開発者にとって身近なツールとなりました。しかし、その実装には様々な課題や考慮すべき点があります。
本セッションでは、ここ1年半ずっとLLM時代のプロダクトの設計・開発・営業・導入に取り組んできた中で得られたLLMの実装パターンとその実際について、ソフトウェア開発者が活用するという視点から解説します。

コンテンツ：

• LLM活用パターンの概観（Chat、RAG、Agent、Workflow、MLモデルとしての活用)
• 実現できるアウトカムとコストの考え方
• 具体的な実活用と課題と解決策

国内では、思ったほどLLMらしいプロダクトやその活用が増えていない危機感があります。
本セッションを通じて、明日からなにか取り組んでみる、プロダクトに反映させてみる、というきっかけを作れたらと思います。

コンピューターを動かすためにコードを書いてデプロイし運用することはエンジニアの中核業務といえます。
同様に、会社を動かすことも"コード"を書いて"デプロイ"していく同種の業務とみることができます。

このセッションでは、会社を作動させる"コード"を軸に、コンピューターとの類似点・相違点と、コードから価値を得るための開発・テスト・デプロイ・運用・改定の一連のライフサイクルの留意点について解説します。

筆者は長年のシステム開発運用やCTO/VPoE経験を経て、ここ数年、社内IT部門立ち上げ、経営企画責任者の"右腕"スタッフ、Engieering Office設立と幅を広げる中で、会社を動かす"コード"について理解と実績を積んできました。
この分野はエンジニアから遠いと思われがちですが、各種技能を直接活かすことができるブルーオーシャンであるため、今後仕事の選択肢に入れていただければと思います。

このトークでは

• 先達のみなさんが作ってきた 1990 年代，2000 年代の北海道の技術コミュニティの歴史
• 2010 年代の北海道の技術コミュニティをどう過ごしたか
• 2020 年代の北海道の技術コミュニティをどう過ごしていくか
• 2030 年代以降の北海道をどう作り上げていこうとしているのか

についてお話しします．
　
2007 年に地元の旭川で初めて IT エンジニアの集団に出会ってから 17 年が経ちました．
それから今まで数えきれないほどたくさん，道内各地の技術コミュニティや IT エンジニアが集まるイベントに参加してきました．
タイトルに含まれている地名は，自分自身で足を運んだ技術勉強会があったり，イベントの際に共に登壇した学校関係者がいたりする地域です．
みなさんと共に，道内各地の技術コミュニティの関係に想いを馳せながら，北海道と技術コミュニティの未来を考えます．

私はエンジニアとして就職する気がありませんでした。プログラミングは好きだけど、なんかきつそうな世界だから仕事にするのはいいやと。

でもひょんなきっかけからこの世界に飛び込み、これは天職かもしれないと感じるようになり、気づけば15年の月日が流れ、様々な経験をさせてもらいました。フリーランスとして働いたり、スタートアップの立ち上げに携わったり、CTO・VPoEとしてのマネジメントなども。

今でもエンジニアリングのことを考えながら働くのは毎日楽しいです。
なぜずっと楽しいのか？と考えたとき、自分が求める"意思決定の裁量"が与えられている現場が多いことに気づきました。だから納得感を持って働くことができ、それが楽しさに繋がっています。ではその裁量を得るにはどうすればよいのでしょう。

私のキャリアを通じて気づいたことを振り返りながら、明日からの仕事をもっと楽しくする技術をお伝えします！

「推測するな、計測せよ」パフォーマンスの話題でよく耳にするフレーズですが、その実践は意外なほど難しいものです。
ひとくちに「計測」といっても、何を計測するかを判断し、得られた計測値を解釈するとき、開発者の技量は大いに試されます。

数ある「計測」ツールの中でもひときわ強力なのが、perfやpprofに代表される「プロファイラ」。
プログラムの関数単位で呼び出し回数や実行時間を集計し、flamegraphなどのビジュアライズを出力できます。
しかし、使いこなすためには少々の知識が必要です。

• そもそも実行時間とは何か？
• 得られた情報はどれほど「真実」か？
• プロファイラのオーバーヘッドをどう制御するか？

Rubyプロファイラ開発者として、一人のプロファイラおたくとしてこれらの疑問に答え、良き「計測」をする方法、そして理想のプロファイラについてお話しします。合言葉は「全部知る」！

今回は秋口の開催ということで次期バージョンの話はあまりできなさそうですが、現行の Perl 5.40 の機能を中心に最近の Perl 界隈のニュースなどを紹介します。