天然の問題の養殖の問題より奇なり。
現場で見つかった驚きの事実を皆様にお送りします。

※フィクションです

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

WEBセキュリティの情報や教科書はたくさんあります。
皆さんも勉強されていることでしょう。

しかし、セキュリティ事故が起きたら一体どんなことが起きるのでしょうか？
PHPで書かれたWEBアプリケーションが攻撃され、実際にセキュリティ事故が起きた時にとても辛かった思い出を面白おかしく話します。

◆対象者
・ある程度PHPでWEBアプリケーション開発をしている人

◆話すこと
・前提の状況
・実際に起きたこと
・どんな対応が起きたか
・どれだけ寝れなかったか

チームの成長と改善を促進するために、定期的なふりかえりは重要です。
しかし、「単なる会議に終わってしまう」、「カイゼンが継続しない」、「なんか微妙な雰囲気で終わってしまう」...など、ふりかえり自体がなんだかうまくいかないことってありませんか？
実際に私も上記の経験をしてきました。その失敗たちを元にカイゼンを重ねていったわたしの「最強のふりかえりファシリテーター法」をお話します！

私が大事にしていること

• ポジティブな雰囲気作り
• 気になったもののみを深ぼる、選択と集中
• チームの雰囲気に合わせて手法を選択する
• カイゼンを継続させる

開発って実はお金かかるんです！
え、そんなのは知ってる？

じゃあ、新しい機能を作るとき、どのくらいのお金がどこにかかるか、考えたことあります？
私は詳細まで考えたことはないです。なので今から実際のプロダクトを例に考えてみましょう！

たとえば、PHPだけじゃWebサービスは提供できませんよね。
そのWebサービスがAWSなどの従量課金制のプラットフォームで動いているならアクセス量に応じてお金がかかりますよね。
PHPとそのサービスを動かす仕組み自体にも当然運用コストが乗ってきます。

ところでPHPを書いている人は？仕組みを組み立てている人は？そのサービスはエンジニアだけいれば成り立ちます？
つまり、機能の開発にも運用にもお金がかかるのです。

当然時間もかかるので、綺麗事抜きに、これから作る機能は、そのお金を払ってまでも作る価値はありますか？と問いかけて作っていったほうがいいのはないでしょうか。
その機能を作ることでどれだけの人の労力と時間を削減できるのか、それをお金に換算するといくらなのか、を考えることで
あらためて自分たちが生み出すことができる価値の大きさを知ることができるような気がしています。

スクラムでの開発にはレビュー会という、スプリント内で実装した価値をお見せする場がある。
決まっていない部分はダミー実装で後回しにして、Interfaceを切ってIOだけを明確にして、とそこまでは順調だった。

だがしかし、レビュー会までにプロダクトは出来上がらなかった。

不確実なことを抽象のままできるだけ後回しにして実装したのに、詳細の実装が間に合わなくなってしまったのはなぜなのかを実装の進め方とともに振り返ってみようと思う。

勉強会とかカンファレンスに何回か参加しているとそのうち湧き上がってくる感情があると思います。
それは、自分も登壇する側に立ってみたい！

でも、
発表には憧れてるけど、発表することがない。
自分なんかが発表したって誰にも刺さらないでしょ？
発表したいけど発表ネタが浮かばないから、手を挙げられない。

その一方で、いつも登壇してる人がいるし、なんなら勉強会が決まった後にネタなんて考えればいいでしょ？って人もいるんです。
同じようにネタがないのに発表できる人と発表を尻込みしてしまう人、この違いはなんなんでしょうね？

そこで、ネタがなくて発表を尻込みしちゃっていた自分が、発表ネタを見つけるために心がけたことを話します。
同じように発表したいけど話すネタがなくて困ってる方の背中を押せたら嬉しいなと思います。

なんらかの機能の開発者は、機能を作る際になんども同じ動作を繰り返して正しく動くことを検証すると思います。
一方で開発者だけだと見逃してしまう考慮漏れなどに気づくのに有効なのが別な人がその機能を触っての検証です。

開発者も検証者も検証シナリオを考えたり、実行したりする際に、同じような動作を繰り返します。
その機能のユーザーは開発者や検証者よりは長い時間をかけてその機能を利用するはずですが、
同じような操作を何度もするという点ではあまり相違はないと思います。

つまり、開発者や検証者が面倒だな、複雑だなって感じる部分は、その機能を何度も使うユーザーにとっても面倒で複雑なものになる可能性があるのではないかと思っています。
このことを具体的な機能の例で示します。

友達の目に余る行動、恋人に直して欲しいところ・・・
伝えたいことはたくさんあれど、嫌われたくないと思う気持ち。
しかしオブラートに包むとうまく伝わりません。

このようなご経験のある方はCodeReviewer改め、行動Reviewerと呼ぶべきでしょう。
そんな行動Reviewerなみなさまが一体どのように伝えていくと相手に聞き入れてもらえるか、phpを交えながら面白おかしく発表していきます！

public subnet のロードバランサーで受けて、private subnet のアプリケーションで処理して、storage subnet のデータベースに保存する。
これが、自分がこれまで「信仰」していた、クラウドの構成概要でした。

が、最近とある方に、自分にとって Breaking Change な発想を提案されました。"public subnet に全部置いちゃう" というスタイル。
セキュリティグループで通信制御すれば、いいんじゃない？トノコト。

あるコミュニティで話を聞いてみるとわりと既にこのスタイルだったり、実際に NAT Gateway 要らずでコスト効率最高だったり、意外にアリなんだなと思いました。

本トークでは、この角度を実現した２つの事例をご紹介します。

• 3層構成FargateをIaCでコスト最適化構成に"1週末"で作り直した
• 1台のEC2で稼働していた小規模なサービスのネットワークをダウンタイムなしで再編した

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ユーザーでない方

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

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

お話すること

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

想定する聴講者

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

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

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

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

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 にはメソッドが追加され、ロジックにも変更が入りました。
というわけで、今、計算量がどうなっているのか測り直してみました。

コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。

いわゆる、1対1のコミュニケーションがどれだけ発生するか？というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか？という経路としてのパスもあります。

個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか？というのもチームコミュニケーションにとって大切な要素ではないでしょうか。

本トークでは、1対1のコミュニケーションにおける対話（パス交換）に着目して、私が大切にしていることを共有したいと考えています。

突然ですが、あなたはどれぐらい集中してない状態でもPHPコードを書けますか？
たとえば、唐揚げを揚げながら、PHPコードを書けますか？
普通のPHPerのあなたはそんなことできるわけない、と思うでしょう。実はできます。
どうやればできるのか、お話しします。

話したいこと

仕事をしながら勉強を続けるのはとても大変だと思います。
しかし、私のチームでは1年間毎日勉強会を続けてきました。その秘伝の方法を大公開しようと思います！

このトークで得られるもの

• 効果的なチーム学習法：皆で学ぶことの力と方法
• 実践的な成果：1年間の勉強会を通じて得られた具体的な成果と改善点
• スムーズな勉強会運営：日々の勉強会を円滑に、そして楽しく進めるためのコツ