皆さんテスト書いてますか？モックしてますか？
テストを書くときにDBや外部サービスをモックしていると思いますが、順番にデータベースへの書き込みを行っていくような手続き的な処理をテストするとなると、テストコードがモックの差し込みだらけになってしまい、とても見づらくなってしまいます。
また、モックの差し込みを書けば書くほど、これって本当にテストになっているのかと疑問になってきませんか？これを解決するために弊社では、あえてDBにつないでテストするということをしているので紹介します。

あなたはDIというワードを耳にしたことがあるでしょうか？
直訳すると「依存性の注入」という言葉で言い表されるDIですが、この概念自体は新しいものではありません。

Javaにおける開発では一般的であり、PHPのフレームワークであるLaravelではサービスコンテナと呼称される仕組みが提供されていたりもします。
しかし、DIを雰囲気で使っている人もいるかもしれませんし、そもそも使った経験がない人もいるかもしれません。

・「知らないなんて、今更言えない。」
・「触ってみたけど、よく分からなかった。」
・「そもそも、依存を言葉で説明できないかも。」

このセッションでは、不安を抱えながらDIのことを見つめている方に向けた掘り下げをしていきたいと思います。
資料の構成はこれからですが、実際のコードを交えつつの解説をしていくつもりです。特定のフレームワークに限定した内容にはしません。

AWS ElasticBeanstalkで運用しているサービスでAWS SQSとLaravel Jobを用いたWorkerサーバーで不具合が発生した。

Jobの実行が必ず失敗するわけではなく、なにか特定の条件があった。
それはスペースが2個以上ある場合のメッセージQueueだと特定した。

この不具合に対してどのように改善したか説明します。

プログラマの三大美徳とは次の通り（Wikipedia より引用）。

怠惰（Laziness）
短気（Impatence）
傲慢（Hubis）

デプロイ作業は単純作業が入り込みやすいです。もし「怠惰」なプログラマだったら単純な繰り返し作業なんて嫌なはずです。
デプロイ作業は時間がかかります。もし「短気」なプログラマだったら長い待ち時間に我慢できないはずです。
デプロイ作業はミスが許されません。もし「傲慢」なプログラマだったら自動化してミスなどしないはずです。

私の所属する会社でもかつては、かつてはほぼ手動でgitコマンドを順番に打って、タイミングを見計らい migrate し、長い待ち時間に甘んじたこともありました。
しかし徐々にフローは自動化され、完璧とは言えないまでも三大美徳を徐々に実現してきました。
PHPerであろうと他の言語のプログラマであろうと避けられないデプロイフローの話をお届けします。

皆さんの開発現場はAPIドキュメントの自動生成化がお済みでしょうか？
このLTではCakePHP4にSwaggerを導入して、コードのアノテーションからドキュメントを自動生成するまでの流れをご紹介いたします。

▼こんな方におすすめ
・これからWeb API開発を始める方
・ドキュメント書くの面倒な方
・実装とドキュメントの乖離に苦労したことがある方

昨年、社内で実施した勉強会のテーマの中で一番メンバーの反応が良かったのが「アノテーションからのドキュメント自動生成」でした。ドキュメント作成の手間を少しでも減らして、開発体験を向上させていきましょう！
（LTではCakePHPをサンプルコードとして紹介いたしますが、Laravelに導入する手順も別途資料をご用意させていただく予定です。）

はじめてのアクセス制御の導入でCasbinというライブラリを使ってみたらすごくよかったので紹介します。

Casbinを用いたロールベースのアクセス制御の導入を例に挙げて、
権限モデルの種類やCasbin、CasbinのLaravel向けパッケージであるlaravel-authzなどについて話します。

元々パッケージとして開発していたソフトウェアですが、リライトせずSaaS化をしたという話です。

qiitaで途中まで書いた話です。
https://qiita.com/Rei_okawara/private/ec0dfe9bf552f7d78101

何も難しい知識は必要ありません。コンパイルされたクラスファイルはオラクルによってドキュメントが公開されており、ただ単純にそれになぞって実装するだけです。それでも、ウェブアプリケーションとはまた違った味を感じていただいた上で、 PHP で JVM を作る楽しさを伝えられたらと思います。

セミコロン、書いてますか？

PHPの構文要素には式と文の厳密な区別があり、一般的なプログラミングのベストプラクティスでは、適度な単位で文を区切ることでリーダブルなコードになるとされています。しかしながら式指向の言語機能や関数を利用することでコードを圧倒的に短縮することもできます。この記事においてはセミコロンの数を最小にしながら偏執的なPHPプログラミングを行う非実用的コーディングテクニックを紹介します。

ちょうぜつ Advent Calendar 2020 からの抜粋で、知っておきたいアンチパターンを紹介します。
https://qiita.com/advent-calendar/2020/memory-chan

みなさん N+1 問題ってご存知ですか？DB への接続をループ分で N 回実行し、+1 はカウントで全件数を取ってきたりすることを総称して N+1 問題というかと思います。他にもループ分で N 回実行しているコードだけのものも総称して N+1 問題と言ったりしますね。言葉の真意は神のみぞ知るですが、概ねこういった理解の方が多いのではないでしょうか。もちろん N+1 は DB に限らず外部リソースへの接続も同様と理解すべきです。外部リソースといえばキャッシュ用の Redis もそうですし、全文検索エンジンの Elasticsearch も同様です。1 回の接続であれば目を瞑ることもできますが、ウェブアプリケーションとして稼働している場合、そういうわけにもいきません。そして、N+1 問題はパフォーマンスチューニングにおいて重要なファクターの一つにあげられることも多いかと思いますが、具体的な改善方法は中々調べても出てきません。そこで、本トークでは N+1 問題をそもそも生み出さない方法はどうするのか、既存のアプリケーションから N+1 問題を改善するためにはどうしたらいいのか、といった今後あなたが開発をしていく上での一つの引き出しになれるようなトークを私の今までの経験を交えてできればと思います。

LTしたことある人、挙手。
カンファレンスで登壇したことある人、挙手。
本書いたことある人、挙手。
何かアウトプットしていますか？Twiterやブログだって十分です。

登壇や執筆なんて、つよつよエンジニアだけができるものだと思ってませんか？違いますよ？もっとカジュアルに登壇・執筆・アウトプットしてみましょう。

トークに自信がない？ネタがない？自分なんて初心者だから？そんな幻想・呪縛はポイです。あなたの「今」を切り取ったアウトプットをしてみましょう。必ず誰かが聞いてくれます。必ず誰かの役に立ちます。そして自分も得るものがあります。必ず次につながります。

アウトプットの始め方、育て方、広げ方、トークネタの作り方、そのあとの広がり、やってうれしかったこと、などなど。

やってみようかなと思った時がはじめ時。アウトプットをはじめることで開ける優しい世界の一端を紹介し、あなたをアウトプットの世界にお誘いします。

PHPerの皆さんは、日々Webアプリケーションを開発している中で、フレームワークのコードと自分たちのコードを区別できていますか？
自分たちのアプリケーションにとって重要な、業務知識をモデリングして書いたコードは、「いまのフレームワーク」と切り離して動かすことができるでしょうか？

フレームワークのバージョンアップ、あるいはフレームワークの開発終了によって自分たちのアプリケーションの命運が左右されることがないように、フレームワークへの依存を取り除き、大事なコードの可搬性を高めましょう。
ごく一般的な小さなWebアプリケーションを題材に大事なコードを守りつつLaravelからSymfonyにフレームワーク変更する様子を実演しながら、考え方とテクニックについてご紹介します。

Advent Calendar（アドベントカレンダー）、以降アドカレと呼称します。
エンジニア界隈の人なら聞いたことがある人が多いでしょう。
エンジニア界隈でいうと12/1~25に記事を投稿していくイベントです。

僕が所属している組織では6年連続でアドカレを実施しています。
私は実施1年目からの発起人です。
はじめは人が集まらず1人でいくつも記事を書いてなんとか25個埋めていました。
運営として代表としてこれではいけないと思い
・地道な声掛け
・せっかく参加して投稿してもらった記事はしっかり読んで感想をFB
などコツコツ続けた結果6年も続けることができています。

・どんなキッカケで開始されたのか
・アドカレを行なうメリット、デメリット
・6年やって見えてきたもの
・これからやってみようと思う人と団体にアドバイス

このあたりを中心にお話できればと思います。
みんなアドカレやろうぜ！

「ママリ」を運営するコネヒトは2020年12月にConnehito Tech Visionとして「Beyond a Tech Company」というビジョンを公開しました。本セッションでは、なぜテックビジョンをつくったのか？そもそも、テックビジョンとは何か？といった話から、技術のコモディティ化が進み、アフターデジタルな世界の実装が進む中で、今後開発組織はどうあるべきか？どういった技術戦略が求められてくるのか？といったお話を出来ればと思います。本セッションとこのテックビジョンの紹介を通じて、一つの開発組織の在り方を提示したいと考えています。

自分はこれまで、いくつかのバージョンアップを実行してきました。

• PHP 7.2 -> 7.4 、7.3 -> 7.4
• Laravel 5.6 -> 5.7 -> 5.8
• PHPUnit 5 -> 6 (-> 7 -> 8 -> 9)

Docker の利用により以前よりは格段に難易度は下がっているように思うものの、
躓いたポイントや乗り越えた事例をいくつかお話しできればと思います。

「エラーと向き合う」ことは、プログラムの品質を極める上で最重要な要素の一つです。
では、PHPが持つ「エラー」とは、いったい何を意味しているのでしょうか？
面白いのは「時代の流れに応じて変わってきている」点であり、またそれがphperを悩ませるのも点でもあります。
「エラーとは何なのか」、PHP8が登場した今の時代に改めておさらいしてみませんか？

PHPにはたくさんの「異常」を知らせる仕組みがあります。
まず初めに「エラーレベル」があり、PHP5で「例外」が導入されました。次にPHP7で当初"EngineException"と称された「Error」が登場します。
そしてPHP8では、「Error」の適用範囲が増えたり、あるいは(時には処理実行の中断を伴う)エラーレベルの引き上げが実施されました。

最も顕著なのは、組み込み関数でも引数が宣言された型に合致しない場合にTypeErrorを発生させるようになった点でしょうか。
もしくは、未定義変数を利用した場合のエラーレベルがNoticeからWarningに引き上げられた点だ、と言う人もいるかも知れません。
どちらも昨今のPHPが”より真面目に”プログラミングのエラーに向き合うようになりつつある態度を感じます。

本セッションでは、PHP7時代を振り返って「Throwable/Error/Exception」を整理するとともに、エラー関連の挙動に注目しながらPHP8の「堅牢さ」についても考えてみたいと思います。

何らかの理由によって「既存のクラスやAPIの使い方が変更された、それに対応しないといけない！」という場面が、
しばしば開発の現場には発生します。
その時に、なるべく「人間の目と手で作業する」という負担は避けたい・・面倒くさいな・・と思うのが人の心情ではないでしょうか。

https://github.com/rectorphp/rector は、既存のPHPコードのリファクタリングやアップグレードを自動実行するツールです。
こいつを上手く使えれば、あの退屈で機械的な作業を真の意味で「機械の作業」にする夢が叶うかも知れません！！

本セッションでは、Rectorについて紹介し、具体的に活用するための方法を話したいと思います。

おしながき

• Rectorってなに？
• どういう仕組で動いてるの？
• 具体的にどうやって使われてるの？ 〜CakePHP4の アップグレードコマンドを例に〜
• 独自ルールを作ってみる

普段の開発において、OSSのライブラリやフレームワークの利用は欠かせません。
そこで「これはどう動くんだろう」「何でこんな動きをするんだ」と思った時にできること・・・公式のドキュメントを読んで見る、インターネットに公開されているブログ等の情報を探してみる。
そして「ソースコードを読んで見る」、「マージまでの経緯を読んで見る」ことです！
ソースコードを読むためには、多少ボリュームのあるソフトウェアからでも「目的の場所を手早く見つけてみる」のが重要です。
また、OSSならではの利点として、コードだけでなく「そこに至るまでにどんな議論があったか」という情報にもアクセスすることができます。ここでもまた、多少のコツを掴んでおくと便利です。

今まで「フレームワークのコードを読んでみるのは苦手だ」「ググって欲しい情報に近い解説やQ&Aが出てこなかったら諦めちゃう」という日々を過ごしていたあなた！
私の周りにも、「ライブラリのコードを読むのは怖い」「面倒くさそう、億劫だ」という人がチラホラいるものと感じます。
もし「ドキュメント探すよりコード読んだ方が早いわ」という選択肢を手に入れられたら、きっと楽しいことになりますよ・・！

明日からは「もっとライブラリと仲良くなれるぞ♡」な日々を歩んでいきませんか？
本セッションが、そのための勇気をもたらす最初の一歩となれればと思います！

普段みなさんは PHP を動作させるミドルウェアは何を使用していますか。よく一般的に使われるのは Apache の mod_php や PHP に備わっている php-fpm をベースとし nginx からリバースプロキシさせる方法だと思います。
私の所属している株式会社トラーナでは物流をベースとしたシステムが必要になり、どうしても一つあたりのレスポンスが大きいデータを取り扱う必要があります。元々弊社では php-fpm を使用していましたが、パフォーマンスが著しく遅く、そこで swoole と laravel-swoole を導入し、8倍もの高速化を行いました。
そこで、本セッションでは導入する際にハマったポイントや、導入する点でのメリット及びデメリット、そしてどのように導入していくか、最後にどのようにプロダクション環境へと昇華させるかというトークをさせていただければと思います。