Macユーザーの皆様、Docker環境は何を使われておりますか？Docker Desktop, Rancher Desktop, Colimaなどあるかと思います。
今、MacのDocker環境で一番注目されいるツールは、OrbStack(https://orbstack.dev/)といっても過言ではありません。「OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative.」と公式サイトにあるように、早くて、軽くて、簡単に扱えるツールです。

このLTではOrbStackは何ができるのかを説明します。そしてOrbStackならではの便利機能を使いながらLaravelアプリケーションのローカル開発環境の方法もご紹介します。

対象者としては以下の方を想定しています。

• Macユーザーでローカル環境でDockerを使われている人

対象としていない人は以下となります。

• Macユーザーでない方

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

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

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

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

私は今までマネジメントに携わらず、メンバーレベルのエンジニアとして開発業務に携わっていました。
しかし最近小規模(4人)チームのリーダーを任され、どちらかというとマネジメントよりの業務の役割が増えています。

その際に気づいたこと、失敗したこと、意識したこと、戸惑ったことを赤裸々にお話します。

業界歴３~４年目のマネジメント系業務に挑戦するエンジニアにおすすめのトークです。

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

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

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

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

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

私はおよそ10年ほどエンジニアとしてお仕事をしてきたなかで、いろんなインシデント対応をしてきました。
その中で得てきた経験をもとに、「どんなことに意識して対応を行っているのか？」をまとめてお話します。

この話を聞いた方がインシデント対応することになった時、１つでもいいので実務で活かしてもらいたいという想いでお話します。

お話すること

私がインシデント対応において大切にしている点
インシデント対応時に活躍するツールや使い方
原因分析と再発防止の考え方

想定する聴講者

インシデント対応をちょっとやったことある、けどもどんなことに意識していけば良いかまだ掴めてない方

『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』（Boswell & Foucher）
エンジニアのみなさんなら、一度は読んだことがあるのではないでしょうか。

私はブライダル専門メディアを自社開発・運営している会社で保守開発を担当しており、
現在はサイトの一部機能を削除する案件にジョインし、開発を行っています。

Laravelで構築された弊社のサービスは、約20年続く結婚式場のクチコミサイトです。
改修に改修を重ね長年運用されてきたサイトの機能を削除することは、簡単ではありません。
例えば、以下のような問題に苦戦しました。

・表記揺れをしている、または意味を汲み取れない関数名・変数名である
・あちこちでクラスが継承され、メソッドやViewファイルの依存関係が複雑である
・おそらくもう二度と使われないプログラムをきれいさっぱり削除できているか、不安になる

この経験から、普段からシンプルで美しいコードで運用・保守していくことの大切さを痛感しました。

本トークでは、歴史ある大規模サービスの機能を削除する上で直面した問題と、そこから得た学びを共有します。
“機能削除”という観点から、『リーダブルコード』をどのように意識して実践していくべきか、一緒に考えませんか？

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

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

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

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

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

Laravelのバージョンアップを行う予定が、プログラムをすべて書き換える「リプレイス」をすることになったお話です。リプレイスをすることになった背景や進め方、よかったこと、大変だったことを、技術的、組織的な観点でお伝えします！

PHPerの皆さん、cssを書いていますか？
このLTではCSSでPHP(elePHPant)を描く方法を教えます。

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

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

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

対象

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

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

私はポモドーロ・テクニックをこよなく愛する者です。会社ではポモニキと呼ばれており、日々ポモドーロ・テクニックを使っています。
しかし、このテクニックには抑えておきたい大事なポイントがいくつかあります。そうしないと集中もできず、作業も進まず、無駄に終わってしまいます。

本トークでは、ポモドーロ・テクニックの要点とやり方、さらにはおすすめのタイマー紹介など、ポモドーロ・テクニックを始めるための知見を紹介します。

Architecture Decision Record (ADR)はご存知でしょうか？
設計に関する議論や決定をまとめておく文書として、近年注目を集めています。

本トークでは、実際に会社でADRを導入して一年以上運用した結果、開発現場で継続的に使われているのかどうかなど、 実情を赤裸々にお話します。

本トークで話す内容

• ADRとはなにか？
• なぜ、導入する必要があるのか？
• 実際に導入してみて苦労したこと
• 良かったこと、悪かったこと

アプリケーションがヒットするとソフトウェアはどんどん肥大化します。そして、既存のウェブアプリケーションウェブフレームワークはPackage By Layer(PBL)の形式で作られているため、レイヤー内のファイル数が多くなりすぎてメンテナンスが困難になっていきます。

そこで、解決策の一つとしてよく取り上げられるのが Package By Feature(PBF)です。本トークでは実際にPBLのモノリスにPBFを取り入れて一年たった結果、どうなったのかをご報告します。

熟練のエンジニアたちがプロジェクト参加時に何を考えているのか、知りたくありませんか？

もしかして、設計のことを考えている？利益？事業ドメインの理解？
いやいや違うんです、兎にも角にも真っ先に確認しておかないといけないことがたくさんあるんです。

このトークでは、シニアエンジニアがプロジェクトを成功させるために何を考えているのかをぶっちゃけてみます。

2018年に「Laravel Collection の計算量を調べてみた」というタイトルで PHP勉強会で発表を行いました。
https://speakerdeck.com/hanhan1978/laravel-collectionfalseji-suan-liang-wodiao-betemita

あれから、5年。月日が流れて、Collection にはメソッドが追加され、ロジックにも変更が入りました。
というわけで、今、計算量がどうなっているのか測り直してみました。

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

本トークで話す内容

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

本トークでは、Laravelで作られた基本的なウェブアプリケーションを例に上げて、ウェブアプリケーションのチューニングとはどのようなことをすればよいのか？どのような原因でウェブアプリケーションが遅くなるのかを説明し、その対処法について紹介します。

本トークで話す内容

• ウェブアプリケーションが遅いとはどういうことか？
• パフォーマンスの計測方法と評価
• 実際のチューニング方法

PHP は、気軽にウェブアプリケーションを作れる言語として、初心者から熟達者まで、人気のプログラミング言語です。
しかし、せっかく作ったウェブアプリケーションも、保守・運用で扱いにくいとレガシーアプリケーションとか、技術負債などと呼ばれます。また、PHP を忌避するエンジニア達も存在していて、レガシー化しやすいから PHP で新しいアプリケーションは作りたくないと評されたりもします。

しかし、保守性の高いウェブアプリケーションとなると、難しい設計論とかアーキテクチャーとかの話が出てきて、どうやっていいかよくわからなくなります。
なんとか、PHP の気軽さを保ちつつ、保守・運用がしやすいウェブアプリケーションを作ることはできないだろうか？
本トークでは、なるべく難しい設計論を避けつつ、どうやったら無難で、レガシーになりにくく、レガシーになったとしても何とかなるウェブアプリケーションが作れるかをまとめます。

本トークでお話すること

• レガシー化しにくくなる PHP ウェブアプリケーションの基本方針
• 明快で分かりやすい開発時の約束事
• 負債を生み出しにくい開発フロー・開発組織の仕組み作り