最近、1993年発売のX68030というパソコンを買って動かして遊んでいます。
大学生当時に憧れだったけど高くてとても買えなかったX68030ですが大人になり財力が付いた今なら…と思ってフリマサイトを監視していたら良さそうな機体が出品されたのを発見してつい…。

X68030はHDDにSCSIを採用しHDD内蔵モデルであるX68030-HDには80MB（GBじゃないですよ）のHDDが内蔵されていました。

翻って現代、2022年。世の中には「Raspberry PiでSCSIデバイスをエミュレートする」とか「Compact Flashに格納したファイルをSCSI HDDとして見せる」とか「Raspberry Pi でFDDをエミュレートする」みたいな同人ハードウェアが生み出され、当時とはまったく異なる快適なX680x0環境を構築することができます。

このトークではX68030の紹介と、2022の今、X68030を楽しむにはどうすると良いかをお伝えします。
今でも十分通用するX680x0の魅力がみなさまに伝わり、X680x0ユーザが増えることを期待しています！（ねえよ）

「傾聴」というキーワードを耳にした事がある人は多いでしょう。
これは何者で、なぜ必要とされるのか。自分なりに納得感を持ていますか？
ノウハウやテクニックとしてではなく、本質的な価値についても深く考えられていますか？

カウンセリングの大家カール・ロジャーズは、対人支援(カウンセリング)の現場において、聽く側に求める態度・資質を原則化しています。
それが「無条件の肯定的関心」「共感的理解」「自己一致」からなる、中核三原則です
これを元に、「人の話を聴く」とはどういう事か、その基礎的なマインドについて紹介します

想定対象: マネージャーやリーダーになりたての人など

・個対個の場面で、話が一方的になりがち / 関係性が深まっている感じがしない
・他者を援助する際に求められる要素を、感覚的にではなく理屈で抑えておきたい
・人の話を聞くのにすごく疲れたり、相手の感情に振り回されがちだと感じる

最近正式版をリリースしたとあるサービスの、開発初期からリリースまでの約1年半の間に発生した様々なシステム構成変更について、変更の原因なども交えてつらつらとお話しします。

私が所属する筑波大学融合知能デザイン研究室では学術向けクラウドソーシングプラットフォームを運用しています。現在の開発チームは主に4名で、システムの運用、保守や新機能開発を続けています。

ところで、今年の3月で前任だった開発者が全員卒業してしまいました。4月から新たな開発チームで開発・運用を始めましたがソフトウェア開発の経験がほとんどない、立て続けに障害が発生する、ドキュメントが無いなど数々のトラブルに見舞われました。

このトークではそういった状況でジョインした私が、チームを立て直し継続的にインクリメントを生み出すために行なった事についてお話します。同じようにチームで開発を行っておりこうした難しさに直面している方に、これらを克服するための気づきやヒントが得られるようなお話をします。さらに学業や進路選びと並行しないといけない大学の研究室という特異な環境でのチーム開発の知見を紹介します。

PHPerの皆さん!OpenBSD使ってますか?

FreeBSDのレンタルサーバーがあった時代はまだしも、世間の開発環境はLinuxのコンテナdocker一強、開発機でもdockerが利用できないと不便な時代となっています。
そのような情勢のなか、OSの選択肢が絞られてしまい他のOSを使った事が無いPHPerの方も多くいると思います。

OpenBSDプロジェクトはOpenSSHをはじめとし、LibreSSLなど普段から御世話になっているソフトウェアの開発も行なっており、殆どの人が利用したことあるプロジェクトでもあります。

セキュリティや利便性を重視するOpenBSDプロジェクトは他のOSには見られない魅力的な機能が多くあり、もちろんPHPから利用できる機能もあります。

このトークでは普段利用していない人も羨むOpenBSDならではの機能をPHPを交えながら紹介していきます

今イチオシの技術スタック、それは IaC(Infrastructure as Code) です。要するにコードでインフラ構成を管理しようというアプローチです。
コードで管理すると何が嬉しいのでしょうか？

• コンソールポチポチ、自前シェルスクリプトポチポチによる手動環境(属人性,手動性)からの解放
• 環境の複製/削除が簡単
• デプロイ後の監視の仕組みまでカバー

など、さまざまな利点がある IaC の中でも、 CDK というツールはとても便利です。
一番の特徴は 「いつも書いているスクリプト言語でコード化できること」 です。
CloudFormation や Terraform のような独自で宣言的に記述するよりも、エンジニア的にわかりやすくなります。
そんな CDK を使って PHP アプリケーションを Fargate 環境にデプロイしてみましょう！

チームが大きく、成長してくると属人化の問題は付きものです。
この問題を放置しておくと知識の溝はどんどん深まっていくばかりです。

そこで弊社は１つの取り組みとして「会議の内容を視覚化する」ようにしてます。
アーキテクチャやドメインに詳しい人の知識を可視化してキャッチアップしやすくしたり、これからキャッチアップするメンバーは具体的にどの領域の知識が不足しているのか客観的に把握しやすくすることができます。

この登壇では具体的に弊社はどのような工夫をしてMTGしているか紹介します

・議事録でMTGのリアルタイム可視化
・インフラ構成図をベースに監視ログの可視化
etc

Webシステム開発においてデファクトスタンダートとなってきた、GitHubが提供するCI/CDサービス GitHub Actions。
本発表ではGitHub Actionsで動くCI/CDジョブを20個以上作成してきた私 @pinkumohikan が、GitHub Actionsとはなんぞやという入口からハマりどころとその解決方法、ジョブ実行時間を縮めるためのテクニックなどをお話します。

話すこと

• GitHub Actionsとはなんぞや
• 自分はどういう使い方をしているか
• ハマりどころと解決方法
• ジョブ実行時間を縮めるためのテクニック

Symfonyが誇る素晴らしい公式入門書『The Fast Track - 基礎から最速で学ぶ Symfony 入門』
日本語化されていて誰でも読んで、試し、学ぶことができます。

この入門書は、単なるCRUD操作だけでなく、デプロイ、テスト、非同期、ワークフロー、API、SPA、ローカライズ、Redisセッション、RabbitMQメッセージブローカーなど入門書としては盛りだくさんのボリュームです。

とても素晴らしい入門書ですが、初心者には環境構築という厚い壁が立ちはだかります。

Dev Containers を使って簡単に環境を構築するための方法を紹介します。

「エンジニア＝自分でサービス作る」

いつからだろう。こんなレッテルを貼られるようになったのは。

現実はそれどころではない。仕事をする人。趣味に走る人。一族郎党と過ごす人。

その中に、「自分でサービスを作っちゃう人」がいる。

そんな人は新規プロダクトのために、ナウでヤングなPHPのフレームワークやサービスのSDKをPHPで書くことができるだろう。

「羨ましい」の一点に尽きる。

業務として触るPHPのバージョンアップは、血と汗と涙がどれだけあっても足りないくらい大変である。

じゃあ、 hoge.php で触ればいいじゃん！

そんな声が聞こえる。

違う。違うのよ。

ディレクトリ構成も新しいフレームワークも新しい開発環境で触りたい。

そのワガママを叶えられる、数ある一つの方法を体験談を混ぜて話したい。

皆さん振り返りしてますか？改善のために振り返りは欠かせないですよね。
そんな振り返りの質をあげる考え方、やり方について話します。

トーク内容

振り返りの効能について
振り返りの目的
おすすめの振り返り術
適切な振り返りサイクルと振り返りの仕方
大事な振り返りのその後
振り返りの黄金サイクル

想定視聴者

振り返りの習慣がまだない
何となく振り返りしてるだけの人

Cloud RunとはGoogle Cloudが提供するマネージドサービスです。
1つのコンテナイメージでサービスが立ち上がり、最小は 128MBのメモリ・1vCPU・1インスタンス（0にもなる）から始まり、サービスの拡大とともに最大1000インスタンスまでスケールアウトすることもできます。
そんな始めやすさと拡張性を兼ね備えたサービスです。

そんなCloud Runに夢中になった私が
「Cloud Runのここが良い」
「Cloud Runのここを気をつけよう」
など、実務などで得た経験なども交えながらお話したいと思います。

想定する対象者
・Cloud Runって聞いたことあるけど、あまり知らない方
・コンテナ一つでサクッとサービス立ち上げてみたい方

お話すること
・Cloud Runの推しポイント
・本番運用していくなかでの気付き

お話しないこと
・他のCaaSとの比較

業務開発において、複数人でチーム開発を行うことはほぼ当たり前となっています。その中では、どれくらい PHP が書けるか、設計ができるか、といったスキルレベルにばらつきが出ることでしょう。
アプリケーションの開発を効率的に行うということは、各メンバーの開発が効率的に実装できるということになります。

このトークで話すこと

このトークでは、スキルレベルの差を吸収し、全員が効率よく実装できる二つの『決め事』を紹介します。

• スキルを成長させ、発揮させることができる『自由』
• スキルレベルを底上げし、品質を保証することができる『約束』

ターゲット

チーム開発において、どのような方向でメンバーに開発してもらえばいいか考えているリードエンジニアの方々

概要

弊社はQAエンジニアもいますが、品質の保証はQAに任せっきりにするのではなく、チーム全体で保証しようといった取り組みを始めました。
そのために行なっている取り組みを新卒一年目のエンジニアがお話しします。

話すこと

• エンジニアが書いているテストをQA、PdMへ展開するための取り組み
• テストを充実させるための取り組み
• テストコードを書くときのルール

話さないこと

• テストデータの整備
• CI/CD

ある日思い立ってぼくは https://tyotto-rurou.tips/ というメディアを立ち上げました。
これまで正直WordPressを侮っていました（ごめんなさい）が、メディアを構築・運用し始めると
なんと学ぶことの多いことか、と本気で驚きました。

WordPress自体の機能の多さ・拡張性の幅広さ、そして、 Cloudflare や Google Cloud といった
クラウドの利活用に非常に向いている素材であると感動すらしました。セキュリティ面の補強もいろいろな
工夫の仕方があることにも気がつきました。

本LTでは、自身のこうした体験記から得た、Webサイト運営の勘所をお話しできればと思います。

AWS Lambda PHP！って言い続けている僕ですが、スループットは出る！とも言い続けています

実際スループットには満足してますし、運用には支障が出ていません

でもEC2と比べるとどうなんだろう…？と思ったので比べてみることにしました

EC2にはPHPを運用出来るレベルのインスタンスサイズを選んで、無理しない範囲で公平性を保ちスループットの比較を行ってみます

• お話すること

  • 比較のレギュレーション
  • パフォーマンス比較結果

• お話しないこと

  • パフォーマンス結果の考察

• お約束できないこと

  • 厳密な公平性

私が株式会社ウィルゲートで開発･運用を担当しているサービスのある機能で、設計をやり直して一からリファクタリングを行いました。
その機能は新卒1年目の私が開発を担当した機能でした。
アカウントが無いユーザ向けの機能のため、通常のログイン認証とは別の方法で認証する必要がある機能です。

2年目でその機能の不具合を修正した後に、実装当初想定されていなかった別の要件を満たす必要があることが分かりました。
その要件を満たすために設計を一から見直して作り直した中で分かったこと･体験談をお話をします。

話すこと

• 1年目で実装したときはどういう設計だったのか
• なぜその設計がイケてなかったのか
• 当初の要件で漏れていた要件はなにか
• 既存の設計と新しい設計の両方をmiroを使って図で整理したこと

話さないこと

• ソースコードを用いた詳しい実装方法

2022年夏。とあるベンチャー企業で3年間PHPerをやっていた男が、データ基盤を新規に構築するプロジェクトにアサインされた──

「データ基盤とは一体……？」
「BigQuery, Redshift, Sknowflake 一体どれを選んだらいいのか」
「データソース層、データウェアハウス層、データマート層の3層。ふむ、なるほど」
「え！？この3層をDWHの中に配置するのが流行ってるって？」
「 SQLでデータ加工。話題のツールdbtとは…」
データエンジニアリングの世界に異世界転生したPHPerが、ベンチャー企業におけるデータ基盤構築についてお話します。

とある案件で「Google Cloud で、Laravelアプリを」というオーダーに巡り会いました。
「AWS Fargate 上に Laravel プロダクトを載せる」ことをやりきっていた自分は、
Compute Engine ではなく Cloud Run 上に、Terraform module を利用して構築することにしました。

やると決めてから、Google Cloud のインフラを、初めて IaC で構築していきました。

このLTでは、その過程で感じてきた

• それまでに慣れていたAWSとの様々な違い
• Terraform module を利用することで手軽にクラウドインフラを組み上げることができる素晴らしさ

といったあたりの、新サービス構築事例をご紹介したいと思います。

OAuth 2.0は柔軟な認可フレームワークです
Facebook、Twitter、Googleなどのエンタープライズ企業も利用しており、実装頻度も必然的に多くなって来ます
またHTTPでの利用を想定して設計されており、PHPerにとっても抑えておくべき技術になります

一方で「柔軟で拡張可能なフレームワーク」で有ることから実装者が考慮すべき点は多いです
実装を見誤るとセキュリティ事故が起こってしまいかねません

今回はOAuth2.0の仕様について振り返りながら、考慮すべき事項をLaravelでの利用実装例と併せてご紹介します
OAuth2.0を適切に扱い、柔軟で堅牢なシステムを構築しましょう

• お話すること
  • OAuth2.0の仕様
  • OAuth2.0のアンチパターン
  • LaravelでのOAuth2.0利用実装例
  • OAuth2.1の状況