PHPStan は コードを静的解析してバグとなりうる箇所を検出するツール です。
PHPStan ではコードを解析する際の厳密性をレベルで指定することができます。
そのため、レガシーなプロダクトに対してリファクタリングをする際に、段階的にエラーを検出できます。

私自身、 PHPStan の存在自体は知っていたものの、触る機会がなかったので、個人開発のプロジェクトに対して使ってみることにしました。

本トークでは、 PHPStan の基本的な使い方を、 PHPStan を初めて使った入門者の目線 から紹介します。
PHPStan に触れたことのないみなさんも、一緒に PHPStan に入門してみませんか?

仕事で使ってはないけど試しにLaravelをさわってみたい。
異なるPHPのバージョンでLaravelを簡単に動かしたい。

0から色々環境作って試すのは面倒だけど軽く試してみたいという方にLaravel Herdをオススメします！

Laravel Herdは今年のLaraconUSでLaravelの環境構築ツールとして紹介されました。
環境構築ツールとしては既にLaravelValetが既に存在しますが、
Valetよりも簡単にすぐ導入できるところにメリットがあり、
瞬時にLravel環境を作ることができる上、動かすPHPのバージョンもツールから
簡単に切り替えられ、様々なバージョンで試すことも容易です！

このLTではLaravel Herdの紹介とValetとの比較、実際に使ってみての感想をお話しします！

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

本トークで話す内容

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

不具合や障害発生時にSlackなどでエラー通知を受け取ることはありますよね。
そのとき、即座に何をすべきか具体的な対応方法をイメージ出来ますか？
エラー発生時の対応は、迅速かつ効率的でなければ、小さな問題が大きな障害に発展することも……！！

そこで、私がエラー通知を受け取ったときの初動〜対応完了までに「何を考えて」「どのように対応しているのか」をお伝えします！
このLTを聞けば、「エラー通知来ないでほしい」と願っている皆さんも、通知が来ても慌てることなく、冷静に対応できるようになっているはずです！

対象者

• 「エラー通知が来たら何をしますか？」に即回答出来ない人
• エラー通知は先輩がなんとかしてくれると思っている人
• 新卒PHPer、新卒PHPerがチームに加わった先輩エンジニア

どさんこ: 小学生の頃、週末は馬に人参スティックをあげたり乗馬して遊んでました

AWS Lambdaはうまくアーキテクチャに組み込む事で大きなメリットをもたらします。
今回はAWS Lambdaを利用した動的サイトをLaravelを使って構築する手法についてお話します。

皆さんに馴染み深いLaravelを利用して、サーバーレスの世界へ第一歩を踏み出しましょう！

• お話すること

  • LaravelとAWSの親和性
  • AWS Lambda PHPの構築方法
  • 選択できるデータストアの選択肢

• 想定する聴講者

  • AWSを利用している方
  • AWS Lambdaを利用したPHPに興味がある方
  • サーバーレスアーキテクチャに興味がある方

「愚者は経験に学び、賢者は歴史に学ぶ」
オットー・フォン・ビスマルクの格言です

私はPHP4から少しづつ進んできたPHPの変化を感覚として捉えていますが、
言語化出来るレベルでの理解が出来ていないと気付きました

今回はオンラインリソースを駆使することでPHPの歴史を振り返ることで、
PHP、ひいてはPHPコミュニティの選択を振り返ってみようと思います

私と一緒にPHPの歴史を振り返りながら、この日本でPHPのカンファレンスが生まれるまで成長してきたのかを学べればと思います

• お話すること
  • PHPとその周辺技術の歴史
  • PHPの機能追加とその選択の考察
• お話しないこと
  • 何かを解決するようなトーク

OSS活動は自分のためにも他の人のためにも非常に尊い行為です。
このトークでは、PHPを使用して初めてのComposerパッケージを公開する手順を解説します。

PHPerとしてOSSに貢献することはスキルアップとコミュニティへの貢献の両方を果たします。
パッケージの作成からテスト、文書化、そしてPackagistに登録するまでのステップを詳しく説明します。
またOSSプロジェクトでのコラボレーションの重要性と、オープンソースコミュニティへの貢献がいかにして個人の成長に繋がるかについてもお話します。

このトークを通じて、参加者は自身のPHPプロジェクトを公開し、OSSコミュニティに貢献を後押し出来れば幸いです。

• お話すること
  • Packagistに公開するまでの手順
  • 考慮すべきこと
  • OSS活動の意義
  • OSSへのコントリビュートについて

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

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

お話すること

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

想定する聴講者

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

新型コロナウイルス感染症が5類に移行したことで世の中的には3年ぶりの平穏を取り戻しつつある今日この頃、これまで開催が難しかったオフライン勉強会も少しずつ増えてきています。
言い換えると、これまでオフラインイベントに参加してこなかった人でも2023~24年はコミュニティに簡単に溶け込める年であるということです。
古参も新参も大歓迎のこのチャンス、逃す手はないと思いませんか？

このトークでは実体験をもとに、新卒2年目の新米PHPerがオフラインイベントに実際に参加して感じたことについてお話ししようと思います。

具体的な内容

• オフイベは怖くないよ！
  • 「とはいえ実は怖いんでしょ？」が実は怖くないという話
• 各種phpcon(東京・沖縄・北海道・関西)にそれぞれRT・LT登壇した際に新米の視点で感じたこと・魅力などについて

コードで扱われる関数の分け方の基準として凝集度と結合度というものがあります。
これらは構造化プログラミングの文脈において提唱されている概念であり、オブジェクト指向プログラミングにおける様々なデザインパターンやSOLID原則を理解する上でも重要なものです。

このトークではPHPで書かれた具体例をもとに、凝集度と結合度についてお話します。

具体的な内容

• 品質の良いコードって何？
• 凝集度と結合度について
• SOLIDのSである単一責任の原則(SRP)について

対象者

• 時と場合による良いコードの具体的な根拠について知りたい人
  • 少しでも多くの判断基準を持ちたいと思ってる人
• 凝集度と結合度っていうワードを初めて聞いた人
• SOLIDの原則という言葉はなんとなく聞いたことがある人

現場で働くうえでよく分からん&ほぼ必須な要素としてGitが存在します。
とはいえ、gitについて調べても「 commit や push みたいな基本操作は分かるけど、深いところが何も分からん……」となりがちではないでしょうか？

このトークでは、ベテランエンジニアはなぜか知っている git 知識についてお話ししようと思います。

具体的な内容

• git init した際に構成される.gitディレクトリの中身について
• 実際にgit addとgit commitをPHPで実装してみる

対象者

• 簡単なgitコマンドは扱える初心者(add, commitなど)
• 複雑な操作になると不安になってしまう初心者
• あの日破壊したブランチのことをまだ忘れられない人

弊社の「エキサイト電話占い」は、弊社通話システムを通すことで安心安全に占い師と通話できます。
(電話越しに占いができるんです！)

「エキサイト電話占い」には、
・ユーザと占い師お互いの電話番号は非表示
・電波状況などユーザと占い師の環境に合わせた通話手段(通常の電話 or 通話アプリ)を用意
などの要件があります。

私はTwilioを用いて上記の要件をみたした通話システムを構築しました。

この通話システムを構築するという経験はとても新鮮だったため、
皆さんに共有させてください。

このLTでは、
・Twilioを用いた通話システムの作成方法
・上記課題の解決方法
について話します。

●●●LTを聞くメリット●●●
・Twilioの基礎を知ることができる
・電話占いの裏側を知ることができる

●●●対象者●●●
・通話を用いたサービス提供を検討中の方
・占いが好きな方

「良いサービス」とはなんでしょうか。
たくさんの要素があると思います。

このLTでは「接客態度」に焦点をあて、
自称クレーマーな私の実体験
・オンライン/オフライン それぞれにおける接客で 嬉しかった/嫌な気持ちになった話
・自社サービスは接客力が上がれば友達に自信を持って紹介できるのに！と感じた話
・自社サービスの接客力が上がった結果、仕事へのモチベーションが上がった話
を通じて、

「良いサービスを作る」という重要な課題に向き合う5分間を提供します。

LTを聞くメリット

開発をする際に、利便性や速度、正確さだけでなく「ユーザがどう感じるか」という視点を、新しく、もしくは当たり前に持つことができるようになります。

対象者

・自社サービスのユーザとご自身との関わりが少ない方
・自社サービスをユーザとして使ったことがない方
・システムやコーディング以外についての話も聞きたい方

テストの目的は、迅速に進めるための十分な自信を得ることであり、より多くのコードをテストすればするほどチームはより自信を持つことができます。

しかし意味のない努力をしていないでしょうか？

• カバレッジ100%を目指すことにこだわるあまり、肝心な業務要件のテストが漏れている
• カバレッジレポートを見ていないせいで、重要な処理が集まるパッケージへのテストが漏れている
• そもそもテストコードがきちんと書けていないため、カバレッジレポートの数値が正確ではない

これらのアンチパターンに陥った場合、品質を高めるどころかむしろ下げてしまう方向へ努力していくことになります。

このトークでは、上記のようなアンチパターンに触れながら、努力に見合ったテスト品質の向上を目指すためのノウハウをお話しします。

OSSのコントリビュートは誰でも可能です。
開発経験を積みたい人や、所属組織外の人からコードレビューを受けたい！という人にとって
OSSコントリビュートは副業に比べて低いリスクで開発経験を積むことができます。

本トークでは貢献の仕方・手法をご説明したうえで、Laravelを使ったOSS/ECパッケージ「Laracom」を動かしながら、コードを一緒に読んでみようと思います。

初心者でもやっていけることをやることでオープンソースに貢献をすることで知見が得られ、
エキスパートへの道を一歩踏み出すきっかけになれば幸いです。

OSSのコントリビュートは誰でも可能です。
開発経験を積みたい人や、所属組織外の人からコードレビューを受けたい！という人にとって
OSSコントリビュートは副業に比べて低いリスクで開発経験を積むことができます。

本トークでは貢献の仕方・手法をご説明したうえで、Laravelを使ったOSS/ECパッケージ「Laracom」を動かしながら、コードを一緒に読んでみようと思います。

初心者でもやっていけることをやることでオープンソースに貢献をすることで知見が得られ、
エキスパートへの道を一歩踏み出すきっかけになれば幸いです。

ふりかえり、やってますかー！
「うまくいかないねぇ」とか、「最初はうまくいっていたんだけどねぇ」といった気持ちになったことがありませんか。
あるいは、ふりかえりのふりかえりをしてみると、人によって「良かった・悪かった」の感じ方に差があったぞ、という経験もするかも知れません。

ふりかえりの「アンチパターン」を知ることで、壁を突破するヒントが得られるかも知れません。
このLTでは、書籍: Retrospectives Antipatterns の内容を踏まえて、アンチパターンについて共有していきます。

1. アンチパターンのカテゴリ
   • 構造に関する問題
   • 実施方法に関する問題
   • 参加者に関する問題
2. 具体のパターン
   • 色々な現場で「あるある！」と言われそうな、アンチパターンをピックアップして紹介

他人様が用意した面白い機会に乗っかって、「3人モブプロでTDDをやってみよう！」の会に参加しました
{私: TDD知っている, 1人: 本で読んだことはある, 1人: 完全未経験} というパーティが出来上がります

「一旦if文で期待値をベタ書きしてテストを通して〜」と、まるで”ピエロ”のようにハリボテコードばかりを指示する、ナビゲータの私
段々とエスカレートしていきます
「手が止まる前に、赤→緑に持っていくことだけを考えて、5秒以内に通します」「新しいテストケースを3秒で追加してみますよ！」

終わってみると、初めてのTDDは「そこまでやるんだ！」に溢れていたようです
そう、TDDは「エクストリーム」なのです。まずは教科書通りにやって欲しい

・・・なぜ？信じられないですよね
TDDは「何を解決するのか」をお話するので、「だから極端にやるんだな！」にアハッと言ってもらいたいLTです！

ある時、「誰かに引き継ぎたいな」というタスクがありました。
実装物自体は、PRを投げてレビューを通せばOK。が、作業の特色上、進め方や効率的なツールの使い方に癖がある感じです。
しかし、「誰かいないかな」の解消は、糸口がつかめず…

そしてふと、「実際の作業を、独り言で脳内を垂れ流しながら、録画で残したらどうだ？」と思い立ちます。
──これが、やってみたら「凄い良さそうでは？？？」と手応えを覚えたのです！

確かにプログラミングのノウハウは、ペアプロやレビューを通じて共有できます。
が、割と「相手ありき」のスタイルとなり、「俺の全霊を喰らわせる」って出来なかったりしますよね。
また、時間の上限や一緒にできる相手も限定されてしまいます。

社内配信なら、そんな我儘が叶う可能性がありますよ！
このLTで、ライブコーディングの(アーカイブ)配信を実際にやってみて感じた可能性を「推し」ます。

Webサービス開発をやっていると、障害はいつかやってきます。
──本当にそうでしょうか？

実は、「障害対応をしている人」は偏っていませんか。
つまり、「いつか来る」は「人による」とも言える状況がある現実がありませんか？

意図して(例えば組織設計上の都合で)そうなっているのでないなら、
「もっと幅広く、対応できる人がいて欲しい」という悩みもあるでしょう。

なぜ増えないのか？
その原因には、「恐ろしい」「恐れ多い」「分からない」なんて背景もあると考えています。
性質上、障害対応の経験値は、組織に広まって行きにくいものです。

壁を乗り越え、皆で対応できる生活を送るための、安全な生活と生命を守る学習・・・「避難訓練」を実施してみませんか！

このトークで話すこと

• 組織の「障害対応偏りがち」の原因と弱点を構造で捉える
• ”避難訓練”が何を解決するか・しないか？
• 実施の例と提案