トーク

私はかれこれ10年以上、出社時は、ほぼ毎朝カフェでノートパソコンを開いて、「仕事以外のなにか」をやっています。
例えば、興味のある技術を試したり、OSS の開発をしたり、登壇資料を作ったり。

世の中では「朝型の生活はいい」といった話も見かけますが、「エンジニアの朝型の生活」の一例として、実行してみて良かったこと・悪かったことなど、これまでの私の経験を踏まえてお話してみようと思います。

無料のWordPressプラグインである「FMPress Forms」を使用して、Claris FileMaker Serverと連動したWebフォームを作成する方法とその開発レシピについて解説します。FMPress Formsを利用することで、WordPress用のフォームプラグインであるContact Form 7で作成したWebフォームから送信されたデータをFileMakerデータベースに登録できます。ローコード開発ツールとして注目されているClaris FileMakerの製品構成やライセンスについて紹介しつつ、公開サイトとして運用しているWordPressと、社内システムで使われているFileMaker Server間の連携例を詳しく解説します。

2023 年 11 月、PHP で ISUCON13 にチャレンジしました。したはずです。このトークを応募した時点ではまだ ISUCON13 は開催されていないのですが、チーム登録は済んでいます。

当日実際に出せたスコア、行った取り組みの内容を簡単に振り返りつつ、よりスコアを伸ばすために行った感想戦の結果もご紹介します。

なお、当日に PHP 参考実装が提供されないなどの不幸があった場合も、自前で PHP 実装を用意するなどの形で楽しくトークを成立させられるようなんとかします。

想定する聴講者は以下です。

• PHP のパフォーマンス最適化や計測に興味のある人
• PHP で ISUCON を戦っていきたい人

話者は好んでOSSのBrefを利用したサーバーレスのシステムを構築しています

その中の欲求の一つにAWS Lambda内でSQLを利用したいという欲求があります
Amazon VPC内でAWS Lambdaを利用し、Amazon RDSに接続する方法がよく提案されます
しかしこの構成では利用した分だけ料金を支払う、いわゆるゼロスケールな構成に出来ません

この課題を解決するために、DBaaSであるSupabaseを利用したアプローチを考えました
非常に優れた仕組みと感じており、検証を進めましたがその中で少なからず感じた課題感がありました

今回はその課題感と、解法の提案を行いたいと思います

地方こそサーバーレス、PHPでサーバーレスアプリケーションを構築する一歩を踏み出しましょう

• 想定する聴講者
  • サーバーレスに興味がある方
  • DBaaSに興味がある方

Psalm や PHPStan、あるいは PhpStorm などでの静的型解析の隆盛により、時には動的型の言語であることを忘れそうになってしまうのが現在の PHP という言語です。

しかし一方で PHP は古くからある言語ですから、その現代的なエコシステムの力を借りられない、ソースコード中にほとんど信用できる型情報のないレガシーコードを扱う現場も数多くあります。あるはずです。そうですよね？

このトークでは静的解析や動的解析によって PHP コードへ自動で型アノテーションを付与する方法を 2、3 個ほど紹介し、各手法の良いところ・悪いところを比較検討してみます。

想定する聴講者は以下です。

• 「最近の PHP は型がけっこう使えるだって？寝言は俺の目の前のこのコードを見てから言え！」という気持ちに日々なっている人
• コードの静的解析や動的解析が好きな人
• 暇な人

先日「PHPを動かす技術バトル~PHPer Tea Night~」という非常に興味深いイベントがあったので参加しました

その中でPHPの実行環境は「mod_php」を利用しているのか「PHP-FPM」を利用しているのかの議論がありました
インターネットでみた記事以上の情報のやり取りも行われ、様々な議論が起こり知見が深まった中で、
その違いの解像度を上げたいと考えました
もう一つの選択肢としてOSSであるBrefの話も添えてPHPの実行環境についての比較をします

なんとなくPHPの実行環境を決めるのではなくて、あなたの推しのPHP実行環境を見つけましょう

• 想定する聴講者
  • なんとなく Nginx + PHP-FPMを利用している方
  • mod_php や PHP-FPMの比較について知りたい方
  • Brefってどう動いているかしらない方（これはオマケです）

PHPをローカル開発するにはXAMPPとかMAMPを入れたらいいんでしょ？ と言われて早数十年。

いやいやXAMPPで困ってないよと思いながらも、いつの間にか世の中ではみんなコンテナとかDockerとか言うようになりました。

本トークでは難しいことは置いといて、なぜみんなコンテナを使うようになったのか、Dockerの良いところ悪いところについて簡潔にお話しします。

話者はPHPカンファレンス2022にて「RFC911*から振り返るHTTPの仕様」という話をさせて頂きました。

その中で特に新しい仕様である「RFC 9114 - HTTP/3」を読んでインターネットの未来を感じました。

今回はHTTP/3に焦点を絞ってRFC 9114からの仕様を理解した後に検証を行い、これまでのHTTPとの違いを体験します。

PHPerとは切っても切り離せないHTTPの次世代プロトコルを体験することでその価値に触れ、
HTTP/3採用のモチベーションになれば幸いです。

• 想定する聴講者
  • HTTP/3に興味がある方
  • HTTPの仕様は知っているけど、HTTP/3について知らない方
  • HTTP/3に関する検証をしたことがない方

PHPerの皆さまは今日もPHPを何処かの環境で動かしている事だと思います。

様々なクラウドベンダーの上にはPHPを動かす選択肢がいくつもあるのですが、
実際にどの環境で動かすのが良いのか迷ってしまいます。

今回はクラウドベンダーをAWSに絞り、
現在稼働させることのできるPHP実行環境の比較を行います。

より良いPHP環境を選択して、コスト効率よくPHPを運用しましょう。

• 想定する聴講者
  • PHPのAWSにおける実行環境に興味がある方
  • PHPのAWSにおける実行環境に興味がないのだけど選択を迫られている方
  • AWS初心者〜中級者の方

2018年から約5年、計15人の1on1をする中でよく話すことをまとめた教育における考え方や理論をまとめた私の秘蔵のボードを大公開します！
しかも、どんなときに使うかの実践例付きで紹介します！

「わたしたちのコード（＝ドメインロジック）」は安定していますか？？

フレームワークを利用している場合にコードの境界がハッキリしていないと、強くフレームワークに依存することにもなりかねません。

フレームワークには便利な機能がたくさんあります。
たとえばLaravelには、Eloquent、Facede、サービスコンテナ、認証、ミドルウェア、Blade、artisanコマンドなどがあり、それらの機能を活用することで、スピード感のある開発ができるでしょう。

しかし依存のしすぎはビジネスの変化への対応による作り直しや機能のバージョンアップの際に思わぬ量のコード修正になってしまうことがあります。

わたしのチームでは主にInterfaceを利用して「わたしたちのコード（＝ドメインロジック）」をフレームワークから独立させ、安定させることを心がけており、その方法をご紹介できればと思っています。

みなさんPHPをビルドしていますか？

つまりはaptやhomebrewやコンテナでPHPをビルドせず、バイナリインストールばかりしていませんか？

昨今、PHPのソースコードについて様々な話題がふえてきているものの、「あれ？ビルドする人がすくなくない？？？」と思っており、PHPをソースからコンパイルして使う方法が失伝している気がします

なので、今回PHPをビルドし、それをつかうという「ちょっと前だったら当たり前だった行為」についてトークしてみたいと思います

ちょっとトリッキーな技も説明できるかも？

このトークは初心者、中級者向けです。

概要

ジェネレータは、特に大量のデータを効率的に処理する際に有効な手法です。
例えば、LaravelのCollectionは便利な機能ですが、多用するあまり気づかずに大量のデータを扱ってしまい、意図せずパフォーマンスに影響を与えることがあります。
本セッションでは、PHPとLaravelにおいてジェネレータを活用し大量データ処理のパフォーマンスを改善する方法について説明します。

トーク内容

1. PHPのジェネレータの概要と基本的な使い方について
2. Laravelにおけるジェネレータを使ったLazyCollectionの使い方について

想定聴講者

普段PHPで開発しており、運用上のデータ量増加問題についてまだ考えてない方、あるいは現在悩んでいる方

ある程度事業が成長している会社であれば、技術的負債と向き合う必要があります。
私も沢山の会社で今まで向き合ってきました。

そこで小さくリファクタリングしようとして失敗したり、フルリニューアルに挑戦して失敗したり、多くの失敗の末、今では成功するアプローチとバランス感覚が身についてきました。

本日は実際に私が経験した失敗談と成功談を交えながら、技術的負債と付き合っていく正しい歩き方についてご紹介します。

※登壇資料はこちらです。
https://speakerdeck.com/soudai/learn-from-predecessors

「推測するな、計測せよ」という言葉は、改善策を探す時だけでなく、新機能をリリースする時も同様で、「計測」することは重要です。
開発環境の少量のデータを扱う場合は問題なく動作するクエリも、本番環境の大量のデータではパフォーマンス低下し、スロークエリになる可能性があります。
このトークでは、本番環境での実行計画の実行時間が約600msかかるクエリを、約0.2msに改善した事例を題材に、計測と具体的な手法について紹介します。

話すこと

• 理論：EXPLAINコマンドを使った実行計画の読み方
• 実践：本番レコード調査、具体的な対応として実行計画の解読、クエリ再設計、INDEXの再検討

注意：このトークではPostgreSQLを使用しています。

フレームワークのドキュメントに従って、あるいはプロジェクトの既存のコードに従ってファイル上部に書いた「namespace」「use」といったキーワード。

この意味、正しく理解していますか？
「ディレクトリ名と対応させて書くやつ」「他の言語でいう import みたいなやつでしょ？」みたいな認識をしていませんか？

実は PHP の機能としては namespace（名前空間）とディレクトリ名、ファイル名には一切の関係はありません！

「じゃあ、なんで require とかを書かずに他のファイルに定義したクラスを使えているの？」と思ったあなたに、その仕組みと、それらを支えている存在をお教えします。

※本トークは「第 146 回 PHP 勉強会@東京」にて発表した LT の増補改訂版です。

コロナ禍をきっかけとして、テレワークを導入した企業は珍しくないでしょう。
テレワークは働きかたに様々な利点をもたらしてくれた一方で、新たな問題をもたらした側面もあります。

私たちのエンジニア組織は従業員どうしの関係性や勉強会等の活発さといった文化を強みのひとつとしていました。
そして、テレワーク導入直後にはその強みがほとんど見えなくなっていたのです。
もともと組織文化醸成の役割を担っていた「開発組織活性チーム」は、この問題に対して活動内容をテレワークに適応させるための試行錯誤に舵を切ります。

本トークではそこからおよそ 2 年にわたる「開発組織活性チーム」の取り組み内容と、それによって実現できたこと、できなかったことおよびそれらの考察をお話します。

アジャイル開発、していますか？チームは成果を出せていますか？
弊社ではクライアントワーク型の案件でスクラムを採用していますが、全てのプラクティスを厳密に採用しているわけではありません。

このトークでは成果を定義し、結果を計測し、改善をするためにやったことと、それによって起きた変化を紹介します。

※プロポーザル時点では改善活動を始めたばかりですが、カンファレンス時点では３ヶ月程度で実際にどの程度の変化が起きたのかを紹介できる予定です。

Google Apps Script（以下、GAS）とはGoogleが提供するローコードプラットフォームです。
単なるJavaScript実行環境にとどまらずGoogleの提供する各種サービス（スプレッドシートやフォーム等）との連携を容易に行えたり、動的なWebページを表示できたりと、まさに「ローコードプラットフォーム」と呼ぶにふさわしい機能を備えています。

何が正解かわからないビジネスの世界において、誤った方向性でプロダクトを作り込んでしまうことを避けたいもの。
そのためにコストをかけずにプロトタイプを作って仮説検証のサイクルを回す必要がありますが、GASの備える特性はその際の強力な助けとなります。

本トークでは、その際に知っておくと役に立つ

• GASでできること
• GASを使うときのコツ、Tips
• GASの限界、使うべきでないところ

についてお話します。

子育てをしながら新しい技術を学ぶことをとても大変なことです。
学ぶことに正解はないけど、模索しながら少しづつ自分の中でカタチができてきたのでそのことについてお話しします。

子育て中じゃなくても、みなさんの学び方に対するヒントになる何かをお伝えできればと思います。