「コンピュータは0と1しか処理できない」とよく言われています。
ビット演算があったり、浮動小数点演算があったり、文字コードが16進数だったりと、PHPerのみなさんもなんとなく実感としてはあると思いますが、なぜ「0と1しか処理できない」のでしょうか。

このトークではアナログの世界・電気回路でデジタルの世界・コンピュータ処理がどの様に表現されるのか、私たちがC言語やPHPで書いたプログラムの実行結果がディスプレイやスピーカーで認識できるところまでがどの様にできているかをお話します。

ふだんの活動ではあまり気にすることのないコンピュータの基本的な仕組みの話になりますが、このトークを聞いたみなさんが今までより少し解像度の上がった目でコンピュータを楽しめることを願っています。

ソフトウェア開発において、品質と生産性の向上は常に追求される目標です。
しかし、これらの目標を達成するための手段として、コードレビューの重要性がしばしば見落とされます。

本セッションでは、
・効果的なPRテンプレートの作成方法
・レビューイが良いコードレビューを受けるためのポイント・テクニック
・レビュアーがコードレビューをする上で気をつけるべきポイント・テクニック
などの我々が実際に取り組んできた効果的なコードレビューの実施方法とその重要性について解説します。

「コードレビューをどのように行えばよいかわからない」「他のチームはどのようにコードレビューを行っているのか知りたい」という方々にとって、
本セッションは有益な情報を提供します。

WEBアプリケーションを開発するうえでセキュリティは切っても切り離せない重要な事柄です。

WEBセキュリティの情報や教科書はたくさんありますが、全てを勉強するのは大変です。
実際に現場であった事故やコードの例を紹介し、最近のフレームワークを活用したWEB開発で起こりがちなセキュリティ事例をお話しします。

◆対象者
・ある程度PHPでWEBアプリケーション開発をしているジュニアorミドルエンジニア
・チームが書くコードをセキュアにしたいリードエンジニア

◆書くこと
・コードレビューしてたらこんな危ない書き方があった！
・こんな脆弱性があった！
・こんな攻撃を受けた！

オブジェクト指向プログラミングにおいて重要な概念となる「SOLID原則」 。
本セッションでは、自分が違反して書いてしまったコードを例に、SOLID原則を紹介していきます。

どのSOLID原則に違反しているか

• 違反がもたらす具体的な問題
• 正しい実装
• 多くの書籍でSOLID原則に関する具体例が示されていますが、このセッションでは「実際の失敗例」を通じてSOLID原則を理解していただこうと考えています。

自分がミスってしまった実装例を、時間の許す限り赤裸々に公開します！！

「良いプロダクトを作るためにもっとエンジニアとビジネスサイドで協力していきたい！」
その想いを胸に半年前からスクラムを使ってプロダクトを作っています。

それまではエンジニアとビジネスサイドが同じチームで深く関わって仕事をすることがあまりありませんでした。
スクラムを入れる上でコミュニケーションの取り方をガラっと変えたかったのですが、ちょっとハードルが高いかもな、、と感じました。

そのため最初は敢えて「不完全」な形式でスクラムを始めました。
スクラムの良さをチームで実感するにつれて、徐々に「完全」なスクラムになっていきました。
そして今は「チーム全員で良いプロダクトを作っている」という感覚があります。

本トークでは、どのようにスクラムの体制を改善していったのか実体験をベースにして紹介します。

このトークの対象

• スクラムに興味がある人
• 組織的な課題でスクラム導入に悩んでいる人

みなさん、サーバレスで動かすPHPはお好きですか？ 私は大好きです。
よくサーバレスなマネージドコンテナサービスでWEBアプリを実行しますが、定期実行するジョブもマネージドなサーバレス環境で実行したくありませんか？

そんなあなたのために、3大クラウドそれぞれで定期ジョブ実行するためのポイントやそれぞれのサービスの比較を行い、実際にPHPを動かす際のポイントなどをお話します！

対象

・Dockerなどコンテナについてなんとなく聞いたことがあり、ちょっと動かしてみたい人
・サーバレスでコンテナを使った定期ジョブをしたい方
・サーバレスという言葉に惹かれる人

お話すること

・各社のサーバレス コンテナサービスの比較（特徴や料金体系など）
・実際にトライしてみての気づき

PHP スクリプトは Web で多く使われ、Web システムの多くは I/O バウンドなため、CPU が遊びがちです。マシンの有効活用には PHP ワーカを増やして並列度を上げたくなります。

しかしたとえ CPU が余っていても、各ワーカプロセスがメモリを食いすぎると並列度を上げづらくなります。実質的に可処分メモリ容量を各ワーカの消費メモリで割った数が並列度の上限となってしまうこともしばしばです。

昨今は Roadrunner、Swoole、FrankenPHP といったリクエストごとに状態をリセットしない AltFPM が成熟してきており、また昔ながらのキューワーカのようなものや Web 以外での PHP 利用も含めて、long running な PHP 実行環境を利用するシーンは増えてきています。これは、メモリがどこでどう使われているかを把握しその改善を行う技術の求められる局面が日に日に増えてきていることをも意味します。

このトークではメモリ使用量の計測のとり方からビットフラグ化、interning、SHM 追い出しといったみみっちいテクニックに PHP のアロケータ実装にまつわる事情の把握まで、12 のメモリ改善技を雑然とご紹介します。

皆さんが所属してるエンジニア組織の課題はなんでしょうか？
どの組織も何かしらの課題があるのではないかと思います。

当社ではPHPで開発された複数メディアを運営し、エンジニアの人数も増加しながら継続的にリリースすることで順調に事業を成長させてきました。

一方で、事業が成長するにつれて「スキル獲得に漠然とした不安がある」や「他エンジニアと交流・切磋琢磨が生まれにくい」と言った声も聞こえるようになりました。

こういった課題に対して、エンジニアリングマネージャーとテックリードを中心に「技術推進委員会」という名の横断組織を作り、メンバーで熱い議論を交わしながら課題解決の施策を考え、実施してきました。(チーフエンジニア制度設計、ハッカソン運営、AWS勉強会開催etc)

このセッションでは、横断組織の立ち上げからこれまでに実施してきた多くの施策や、施策を実施したことでの組織の変化について話します。

みなさん、PHPの事を深く知りたいとき、どうしていますか？
PHPのマニュアルを読む、php-srcを読みにいく、...などがパッと上がるかなと思いますが、
以下を読んでいく事でPHPの仕様を深く知っていくことができます。
https://apiref.phpstan.org

リファレンスを読み、実装されているAST周りから読み解くことでPHPの言語仕様などが”逆引き”のような感覚で面白かったので、例題を出しつつご紹介したいと思います！

息子が大学生になって、子育てが一段落しました。
新卒でエンジニアとして就職してから、結婚して子供が生まれ、今までのキャリアの中で本当にいろいろなことを考えてきました。
自分にとってだけでなく、家族にとって一番よいありかたはどういう形なのか模索し続けた結果、今ここに立っています。
その間、転職をしたり、会社が買収されたり、スタートアップに飛び込んだり、自分で会社を始めたり、いろいろありました。

本トークでは、キャリアの一例として自分がどのように考え、判断を行ってきたか紹介すると同時に、
今まで多くのWebエンジニアを（社外CTOや技術顧問等のアドバイザーとして）見てきた経験もふまえて
Webエンジニアのキャリア戦略についていくつかの考え方を提示します。

皆さんがキャリアについて考える上で、何か参考になることがあればうれしいです。

エンジニアは継続して勉強する必要があると言われています[要出典]。

じゃあなにをどうやって学ぶのかはあまり教えてくれません。コードを書いて公開すればいいよとか、本を読むといいよとアドバイスはしてくれるものの、具体的な行動に移すのが難しいなあと感じます。

そんなふうに思っていた自分は今では、本をたくさん読み、ポッドキャストをたくさん聞き、いろいろな勉強会に参加していました。私が実践している楽しく勉強ができる方法を紹介します。

対象

• 勉強の仕方がわからない人
• いろいろな情報のインプット方法を知りたい人

レポジトリパターンを使っていますか？
EloquentでModelをinjectして使っているつもりになっていませんか？
DoctrineORMのEntityRepositoryはいい線行ってますが、モデリングを極めると不足を感じます。
"本当のレポジトリパターン"についてお話しします。

プログラムを書くときに計算量を意識していますか？計算量の基本を理解することで、サービスが成長したときに問題を起こしにくいプログラムを作成することができます。簡単なプログラムを例にして、まず計算量という概念に慣れてみましょう。

本トークで話す内容

• 計算量とはなにか？
• 時間計算量、空間計算量
• 実装時に意識しておくこと

皆様はペアプログラミングをしたことはあるでしょうか？では、ペアテストはどうでしょうか？
なぜかあまり有名な方法ではないようで、やったことがなければ聞いた事もない人も多いことでしょう。

自分自身では完璧に作ったと思っていたのに、リリースやQAに回したら、気が付かなかったバグや、想定外の操作による不具合が発生することはめずらしくありません。
後でバグがみつかり、QAからもどされたり(ちなみに私はQAです)、リリースを取り消すことになったりしてとてもつらい気分になったことはありませんか？

「僕のPCでは動いたのに…」と。

そこで、ペアテストです！

ペアテストとは複数人で一つのブラウザなどを囲みながら行うテストです。BDDやAgileの開発手法でも取り上げられることがあります。
自分が気付かないエッジケースや、気が付かなかった仕様漏れの発見に効果的で、品質の向上は勿論、手戻りを防ぐことができ、結果として開発速度も向上します。

私はエンジニアではなくQAですが、皆さんに体感してみて頂きたいとおもっています！

内容

• ペアテストの基本
• ペアテストの実例
• 私のお勧めするペアテストの工夫
• エンジニアの感想

あなたも是非ペアテストで見落としを減らし、品質を向上させ、開発速度を上げていきましょう！

Everything will be Serverless

サーバーレスは正しくアプローチ出来れば、開発コストとしても運用コストとしても非常に高いコスト効率を出すことが出来ます。

今回は私が実際に構築してきたの具体的な事例を通じてサーバーレスがどのようなメリットを与えて来たのかを、
開発、運用、コストの面からお話します。

なぜサーバーレスに価値があるのかを感じてもらい、どのような場合に適用を行うべきなのかを議論、検討する材料になれば幸いです。

• お話すること
  • 構築事例とその狙った効果
  • その中で得たメリット、価値
  • 構築、運用でのデメリット

2023年6月にGoogleが運営するドメイン登録サービス「Google Domains」の売却が発表されました。 また同年の9月にはNTTドコモが2021年に終了した金融サービス「ドコモ口座」のドメインがオークションで落札されたことが話題となるなど、インターネットドメインに関わるニュースは時折世間で話題となっています。

一般的にインターネットドメイン(以下ドメイン)とはインターネット上のURLのことであるくらいの認識で、普段Webサービスを開発・運営していたとしてもドメインに直接関わる機会は意外と少ないと思います。

しかしドメインは2024年においてもインターネットにおいてとても重要な要素の1つです。
そこで今回、普段ドメイン登録サービスの開発・運用を主な業務として行っている私がドメインについての入門的な基礎知識や、普段あまり知ることがないドメインの管理構造や管理ポリシーなどについて紹介し、みなさんにドメインについてより関心・興味をもっていただきたいと思っています。

本トークでは以下についての発表を行います

1. ドメインの基礎知識
   • ドメインの仕組み
   • ドメインに関わる管理団体
   • WHOISとは？
2. ドメインの登録・管理・移管について
   • ドメインのライフサイクル
   • ドメイン管理に関わるポリシー

最近のプロダクト開発においてSPAやマイクロサービスといったアーキテクチャを採用しているケースが多く、バックエンドのWeb APIの開発を避けて通れないと思います。

登壇者も近年数多くのAPIの開発を行ってきました。その中でスキーマ駆動開発も取り入れた開発プロセスを取り入れるなど、APIのスキーマ定義・管理方法ついて試行錯誤を重ねてきました。

その中でAPIのスキーマのバージョン管理がコラボレーションを行う上で大変重要であると気づきました。

如何に開発コストを増やさず

• バージョン管理を適切に行うのか？
• API仕様書の品質を高める
• API仕様書を活用してアプリ全体の品質を高める
• 仕様書以外でのバージョンの活用

など、実践してきたことと取り組みにおかえるメリットについて紹介します。

みなさま、技術コミュニティは好きですか？私は好きです。
そんな私は福岡という地方都市で暮らしていて、技術コミュニティが大好きです。

東京に比べると地方でのイベントというのは絶対数は少なくなり、参加者の人数も少ないのかもしれません。
実際私はコロナ禍においても、ひたすらコミュニティ活動を続けていましたが、
そこで断絶したコミュニティを見てきました。

地方でコミュニティに求められる属性として、コミュニティの継続性という観点があると思います。
コミュニティの継続性とは何なのでしょうか。

今回は、私が今までコミュニティ活動を10年間行ってきて見えてきた
コミュニティに必要な要素としての「熱」のお話をします。

カンファレンスのみなさまだからこそ、目を向けるべきコミュニティを言語化して振り返ってみましょう。
そこで見えてくるなぜコミュニティが楽しいのか、続くのかを皆さんと一緒に考える機会になれば幸いです。

みなさまは技術広報という役割をご存知でしょうか。
私は所属する株式会社Fusicにてエバンジェリストという役割を担っているのですが、
その中で技術広報という役割も一部担っています

正直私は広報という分野の専門家ではありませんしド素人です。
それ故自らの登壇という以外の広報アクションはかなりの悪戦苦闘をしています。

そこで私はエンジニア以外も巻き込みながら技術広報チームを立ち上げて、
素直に自分以外の力を借りながら技術記事の執筆や自社オンラインイベントの立ち上げなどを実施し、
失敗を繰り返しながら少しづつ少しづつ改善を行ってきました。
そしてほんの少しではありますが、芽が開いてきて繋がったような気がします。

今回は専門ではないながら、その技術広報チームで試行錯誤しながら行ってきた活動を振り返り、その中で得た知見を言語化してお伝えします。

• お話すること
  • Fusicに元々あったものアウトプット文化
  • 技術広報チームの立ち上げ、悪戦苦闘の日々
• お話出来ないこと
  • 技術広報の正しい手法
  • 専門的な広報知識

みなさんLaravelは使っていますでしょうか？
LaravelはPHPの中でも最も広く使用されているフレームワークの一つであり、その中でも「セッション」はWebアプリケーション開発において重要な機能の一つです。
そんなセッションですが、我々はLaravelのセッションの仕組みを理解せず利用し失敗をしてしまいました。

本トークでは、なぜそのようなミスが発生したのかを理解し、Laravelのセッションの仕組みを紐解いていきます。
Laravelのセッション機能は非常に便利である一方で、その仕組みを正しく理解していないと予期せぬ問題が発生することもあります。
具体的な事例を通じて、どのようにして問題が引き起こされたかを明らかにし、それを回避するためにはどのように対処すべきかを解説します。
フレームワークの便利な機能は深く理解せずに利用することもできますが、理解することでより堅牢なコードを書くことが可能になります。
本トークを通じてLaravelのセッション機能を理解することで、同様の失敗を未然に防ぎ、よりLaravelを活用できるようになりましょう！