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

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

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

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

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

このトークでは

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

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

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

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

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

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

企業向けにサービスを作ったことはありますか？実際に企業へ導入するには様々な障壁がありますよね。
技術的なセキュリティはもちろん、組織的なセキュリティや管理体制など幅広い対策が求められるため、ハードルが高いと感じるのではないでしょうか。
そこで本セッションでは、エンタープライズでも導入できる"本気"のお買い物メモサービスを作りながら要点を解説していきます。
個人、スタートアップで開発をしていく方にとって役立つ情報となるかもしれません。

話すこと

• エンタープライズで求められる、もしくは"求められない"セキュリティとは
• 技術的な対策(マルチテナント、脆弱性管理の自動化や可視化、IaaSの活用)
• 組織的な対策(承認フローの構築、仕組みの文書化)
• 実例を基にした対策(OSS管理、データの越境移転)
• エンタープライズで求められがちな機能(認証と認可、データダウンロード)

全文検索エンジンGroongaは、高速で高機能な全文検索を提供します。

Groongaはライブラリーとしてプログラムに組み込む事もできますし、HTTPサーバーとして起動してHTTP経由で全文検索することもできます。
Perlからは、Groonga-HTTPというCPANモジュールを使ってHTTP経由でGroongaを使えます。

また、PostgreSQLでは、PGroongaという拡張を使って、MySQLやMariaDBでは、Mroongaというストレージエンジンを使って、
Groongaで提供している高速で高機能な全文検索を使えます。

本発表では、Groongaがどのような特徴を持つ全文検索エンジンなのかと、その使い方について紹介します。
Groonga、PGroonga、Mroongaを詳しく知らない、または、高速・高機能な全文検索に興味がある人向けの発表です。

技術的負債はどこの現場でも多かれ少なかれ存在します。技術的負債ゼロな現場はありません。

技術的負債を継続的・定期的に返済できていれば問題はありません。しかし長年放置され「負債度」が高まった技術的負債を返済するのは非常に厄介で骨が折れる作業です。

本発表では、下記のトピックを扱います。

• 技術的負債の生まれ方
• 「技術的負債の倒し方」のはじめ方
  • 「負債」という言葉の限界
  • 共通言語で語る
• 技術的負債の倒し方
  • ソフトウェア開発の三本柱を建てる
  • コードフリーズ宣言
  • ４つの負債解消アプローチ
• 技術的負債の倒したあと
  • 継続的負債返済

技術的負債はなぜ生まれ、それにどう立ち向かい、その後どうすべきなのか。私自身が経験したEOLを迎えたPHPの移植・アップグレード事例を踏まえて発表します。