トーク

PHP 7.4 から FFI がサポートされるようになりました。これまで、Cのライブラリを経由して何がしかの処理を行う場合は、PHP拡張を作るしかありませんでしたが、FFIを使うことで、直接PHPからCのライブラリをコールすることが出来るようになりました。

このLTでは、Webカメラの操作を題材にしてPHP-FFIが開くPHPの新しい可能性について紹介します。

PHPといえば、Web開発。
Web開発と切っては切り離せないのが「データベース」と「SQL」です。

このトークは、オライリー・ジャパン出版の名著「SQLアンチパターン」で紹介されている25のアンチパターンを駆け足で学ぶものです。
「SQLアンチパターン」では、データベース設計やSQL記述の際に避けるべき事柄をアンチパターンとして紹介しています。
「アンチパターンを知っていれば問題を防げたな・・・」という場面は、きっとあなたの今までの開発経験の中にもあるはずです。

あなたは、すべてアンチパターンを全て覚えていますか？

このトークを聞くことで、「へー、そんなアンチパターンがあるんだ」「あ、そういえばそんなのあったな！」という気づきを得られるはずです。

また、このトークでは実際の開発で直面した問題や、プロダクト開発に生かした例も交えてご紹介いたします。
明日からすぐ使える知識としてお届けできたら幸いです。

めざせ、SQLアンチパターン・マスター！

Have you wondered how Laravel and Symfony started? This talk will cover the history of both frameworks. We will also cover documentation and examples on how these frameworks work. Let's dive into the details of the design patterns and features both have to offer.

Do you need to develop a backend API quickly with PHP? Then this is the talk for you. We will cover all the major PHP frameworks out there such as API Platform, Laravel and more. We will cover how to develop APIs quickly and how to support frontend teams to interact with your API easliy.

Are you still using Apache/Nginx and a bunch of virtual hosts to create your own shared hosting server? Stop tinkering with configs on your server because this talk is just for you. In this talk I’ll share how I manage my sites with EasyEngine. EE is a docker setup that uses Nginx, php-fpm, and Redis to spin up sites in a blazing fast and repeatable way. I’ll go over how I use EasyEngine with Google Cloud Compute, Terraform, and Namecheap to create a server, point a domain, and create a site in just a handful of steps. This has allowed me to be able to migrate sites in a super fast way to new operating systems and keeping security patches in tip top shape. I’ll go over how to use LetsEncrypt which is built right into EasyEngine for free SSL certificates and how you can backup/migrate sites quickly. After this talk, you will be ready for lift off with EasyEngine!

PHPを始めたばかりの初心者の方は1つのファイルにすべての処理を書き込むところからスタートすると思います（フラットなPHP）
一方で、プロダクトは一度作って終わりではなく必ず改修が必要になります。フラットなPHPで開発するとぶち当たる改修の難しさを軽減し、より良いプロダクトを作るためにオブジェクト指向という考え方があります。
「オブジェクト指向」という言葉を聞いたことはあっても「なんとなく難しそう…」と二の足を踏んでいる人も多いでしょう。この機会に入門してみませんか？
概念の説明だけでなく、実際にフラットなPHPに書かれている処理をオブジェクト指向を使ってクラスに分けて書くやり方を、実際にコードを書きながら解説します。

※私自身オブジェクト指向について学問的に学んだことがあるわけではありません。日々PHPで開発するのに必要な概念のみ話す予定ですが、学問的には間違った内容が含まれる可能性が少しあります。

グループとチームは違う、と言われます。
その違いは「ただ人が集まっている状態の集合体」と「共通の目的を持ち、取り組む集合体」のように説明されます。

仕事の文脈では、色々な場面で「チーム」が組成されると思います。
しかし、実態は「与えられたタスクをバラバラにこなす、個人ワークがメインで・・」というのも、よくある話ではないでしょうか。
目的やメンバーのレベルによってはそれでも問題なく、むしろ最適な場合もあると思います。でも「チームとして動いた方が良いのにできていない」のであれば勿体ないことです。

このあたりの話は、世の中に多くのノウハウやパターンが出回っています。インセプションデッキもそうだし、スクラムのフレームワークも透明性・検査・適応の実現の過程で「チームで動く」ためのコミュニケーション設計が成されているように感じます。

「じゃあ明日からチームになっていこう！」と思った際に、何から手を付けましょうか？
このセッションでは、私自身がこれまでに参加した「チーム」や、リーダーの立場で実際に行い・フィードバックを得た経験も交えながら、「 そもそも、なぜチームになる事が求められるのか」「グループではなくチームになるために大事にしたこと、やってみてよかったこと」をお伝えしたいと思います。

皆さんは、Composerをご存知ですか？利用していますか？では、その中身を読んで遊んでいるでしょうか？

Composerの世界においての中核的な概念は、「Repository」と「Package」です。
これらを組み合わせると、「何がインストール済みなのか」「composer.lockに指定されているもの、composer.jsonに指定されているものは何か」「このシステムの環境は要件を満たしているだろうか」「packagist.orgだけではなく、GitHubレポジトリやローカルファイル(path)も見に行くぞ！」という複合的な課題にそれぞれ応えることが可能になります。

システム開発は、PHPのソフトウェアも多分にもれず「どういう問題を、どのように抽象化し、組み合わせ、解決するか」という活動です。一見複雑そうに見える・・・という問題を、エレガントに解けるのも「モデリング」の力です。

本セッションでは、Comopserを例にしながら「どういう風に問題を切り取って、どういう風に抽象を定義し、それを具体的な世界に落とし込むか！！」という思考を味わってみようと思います。
世界中で利用されているソフトウェアの「シンプルさ」を感じ取ってもらえたら幸いです。

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

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

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

おしながき

• Rectorってなに？
• どういう仕組で動いてるの？
• 独自ルールを作ってみる

vimeo/php-mysql-engine は、「MySQLを使わないでMySQLの処理を動くようにしちゃおう！」という野心的な何かです。
コンセプトや利用イメージなどの概要については、日本語であればピクシブ株式会社様のブログエントリーを参考にすることが出来ます。

ピクシブ百科事典のテストにphp-mysql-engineを導入しました - pixiv inside

しかし、とても不思議ですね・・・？
一体どうしたら、こんな処理を実現できるのでしょうか。
気になったので、調べてみました！

本セッションでは実装面からphp-mysql-engineの挙動を読み解いていきたいと思います。

Xdebugを活用していますか？ステップ実行の機能については、利用経験者も多いかと思います。
公式サイトを開き、トップページを見ると「Step Debugging」「Improvements to PHP's error reporting」「Tracing」「Profiling」「Code Coverage Analysis」と主要機能が列挙されています！

本LTでは、「知っているといざという時に便利！！」なTracing・Profilingの機能を紹介します。
Tracingを使いこなせば「この処理どう動いているんだ？？？」を効率的に理解するのに役立ちますし、Profilingを使いこなせば「どこの処理がボトルネックになっているんだ？？？」をパパパっと理解できるようになっちゃいます。

ぜひ、プログラマーの道具箱に入れておきたいですよね！

静的解析、利用していますか！
PHPStanやPhan、あるいはPhpStormのコードインスペクション機能によって、普段から色々な恩恵を受けている人、「もうコレなしではダメなの！！！」なんて人もいるかも知れません。

では、チームで活用できていますか？既存プロダクトに”後から”静的解析を導入したいんだが・・・と、悩んだことはありませんか？
個人的に、静的解析は「入れたら当たり前になるもの」「でも導入までは面倒くさいもの」に思われがち、という印象を持っています。
最初の導入にはいくつか無視できない壁があると思いますが、その1つは「チームメンバーで合意を得る(場合によっては説得を伴う)」ことではないでしょうか？

しっかりと「静的解析、こんな場面で便利！」と説明する必要があります。
それも、抽象的な原則や一般論的な「○○べき」で押し付けるだけでは、モヤモヤが残るだけかも知れません。
欲しいのは「ほら、お前もコレ観たことあるよな？・・・それ静的解析で出来るよ！！！」という魅力です(多分)。
また、その後のフォローとして「こうやったらちっちゃく入れられ始めるよ」というポイントも押さえておきたいものです。

あなたは既に「静的解析を知っている」し、「使ってみたいと思っている」とします。
その上で、「チームメンバーにどうやって良さを伝えたものか・・・」で悩んでいるのです。
私は、そんな人達を応援したい！！！と思いました。

本セッションでは、「静的解析を入れたいけど説明や説得が面倒だぁ・・」という人に向けて、「どうやったら良い感じに巻き込めそうかな？」を考えてみます！

CakePHPというフレームワークがあります。現在のstableは、4.2です。
Packagistのstats を見ると、まだまだ3.xの方が利用数が多いようです。

ですが、4.0->4.1->4.2と堅実に進化を遂げています！
また、4.2の次期バージョンでも「お、遂にそこにメスを入れるんですね？！」という変化も予定されています。
まだまだロードマップも未策定ですが(※2021年7月現在)、どうやら5.xに向けた開発も動き始めているようです。
(「じゃあ姿が見えてきたってことか？」というと微妙なので、それはカンファレンスまでにどのくらい進捗するのか・・・次第です。楽しみですね！！)

このセッションでは、主にCakePHP利用者向けに「最近＆ちょっと先のCakePHP」の話をします。

PHPを業務や趣味で使っていると、「PSR(PHP Standards Recommendations)」という単語を目にする場面があるかもしれません。
こいつは一体なにものなのでしょうか・・？

PSRは、「PHP-FIGが策定し、運用する 何か」です。 また新しい単語が出てきました。PHP-FIGってなにものでしょうか・・？

PHP-FIGやPSRが誕生した背景、そしてこれまでに辿ってきた歴史、そして今現在のPHP-FIG/PSRを取り巻く状況を理解してみることで、「PSRとは何か」を感じられるようになるかも知れません。

本セッションでは、PHP-FIG/PSRの歴史を振り返ります。

みなさんの開発・運用しているシステムでは、障害・・起きていますか！
障害は恐ろしいものです。その一方で逃げられないものでもあります。
逃げられないのであれば、付き合っていきながら打ち克っていくしかありません。

障害を小さくし・防ぎ・減らしましょう。
そのためには、「透明性」を担保し、「検査」と「適応」を繰り返して進化していきたいものです。

では、どうやって取り組んで、どこから変わっていけるものでしょうか？
「(自分たちの根ざす)マインドセットの獲得」と「(自分たちの作る)システムの見える化」、そして「(自分たちの取り組む)プロセスの改善」から始めていきませんか。
スキルやプロダクトについては積み上げていくしかないものであり、一朝一夕では変えられません。
ですが、組織やチームの持つ「ルール」と「やり方」「仕組み」は、「やるぞ！！」という気持ちを持てた瞬間が、変わるときです。

本セッションでは「障害と向き合って、提供するものの品質を整えていくために、チームでやっていきたいこと」を取り上げていきます。

私事ですが、身をおいている環境の変化により、自分より若手の開発者と接する機会が増えてきました。
そんな中、ある時「どうしたらコードをうまく書けるようになりますか？」と質問をされたのです。
私はふと「コードをたくさん読むと良いよ」なんて答えたような記憶があります。

ソースコードをたくさん読むことはとても良いものです。実に多くの理由があります。
その中でも2つの点を強調するとしたら、

1. 利用(依存)しているソフトウェアについて、「なぜ・どうやって動くのか」を自分の目で確かめられる。しかも、読めば読むほど「読むハードル」が下がる
2. お手本となるコード、多様な書き方を見て自身の引き出しを増やしたり考えを深める材料となる

といったものがあると思います。

例えば、普段の業務の中で「モデルにあるhogeメソッドに処理が来るまでに、意図したデータが渡ってこない」なんていう時に。「フレームワークのコードを読んだら、データの渡り歩く経路が追えたので、”どこでデータが加工されていそうか”の勘所が掴めるようになった」と、納得感のある形で回答を得られることがあります。
あるいは、「この外部通信クライアントのテストをどう書こう？」→「実通信部分を担っているドライバ層のライブラリは、どうやってテストを書いているかをみてみよう」・「クラス名がググラビリティの低い単語になってて、情報が探り出せん・・・」→「実装を見てしまえば一瞬で処理がわかった！」などなど。

「読めること」あるいは「読んでみようと思えること」の恩恵は、様々な部分で感じられるでしょう。
とりわけ、「OSSのコードを読んで見る」ことは、世界中の開発者の目を通して磨き上げられたコードにアクセスできる可能性を意味します。

本セッションでは、「あまりコードリーディングってしていないかもなぁ」という人を対象に、「実際にOSSのコードを読んで見るにはどういう感じで取り組んでいけばいいのかな？」の例を示します。
実例のパートでは、Composerのコードを例に取りながら「気になるあの処理のコードを読んでみよう！」という取り組みも行います。

PHP8.1が近づいてきました！！enumにfiberにreadonlyにnew in initializersに・・楽しみがいっぱいですね！
さて、その前にPHP8へのアップグレードが必要だと思います。
PHP5.xからのアップグレードを・・・は大変そうですが、PHP7.xからのアップグレードであれば、
「いかに低コストに・安全にやれるか？」を考えてみる価値があるかも知れません。

本セッションでは、以下のような点に触れながら「リスクを最小化しながら、どうやってPHP8に上げていこうか？」を考えていきたいと思います。

• 「PHPのアップグレード」は何が大変なのか？
• PHP7->8変更時に(特に)気にしたい箇所
• アップグレードのスコープを決めよう
• 静的解析を利用した「要修正箇所」の洗い出し
• ツールを使った「変更の自動化」でPHP8対応を楽にする
• Composerをうまく使って「今のコードをそのまま動かす」

※ PHP7.x -> 8.0を想定しています

アプリケーション開発者にとって、「エラーが起きた」は恐ろしいことですか？それとも、安心できることでしょうか。
もちろん、「エラーを出さない」という心構えはとても大事です。
では、「出しちゃいけないもの」という信仰から「エラーが出るのは怖いこと」という価値観が発生しているのでしょうか。

最も恐ろしいのは「何が起きているのかわからない」ことのはずです。
裏を返せば、「何が起きているのかがわかる」ことは最重要ともいえる武器です。
最強の武器を普段から磨いて備えて使っていくことは、我々を良い未来へ導いてくれるに違いありません。

エラーと付き合い、使いこなしていきましょう。
アプリケーションで発生したエラーを把握していますか？
「把握している」というのは「何かが起きたことを知っているか」ではありません。
「何が起き、それがどれだけの異常で、どう影響し、原因を追求するのに十分な情報を効率的に取得できるか」です。

もし「ちゃんとエラーに気づける」という世界があったら、いったい何が変わるでしょうか？
ひとつには、「デプロイが怖いもの」ではなくなります。
「もし変更に失敗しても気づけるから」という自信に繋がります。
もうひとつには、「高く付いたかも知れないダメージをグッと軽減できる」ようになります。
エラーないしバグは、「出た瞬間に直す」のがもっとも損失を抑えられるし対応コストも抑制できます。

本セッションでは、アプリケーションエラー管理ツール(Sentryを想定しています)を利用して、「開発現場にどのような”エラーに対する心構え”を構築し、チームでどう運用していくか？」をお伝えします。

世の中から「クソコード」は無くせるものでしょうか？
せめて、地球や宇宙の全部とまではいわなくても、「私の身の回りにある世の中」であれば可能でしょうか？

私は、なるべく「クソコードなんて視界に入ってこないで欲しい」と考えています。
一体どうすれば奴らはいなくなるのか。すごく難しそうです。
ですが、「新しくクソを生まないようにしよう」というのは可能でしょう。

そのための一歩として、「クソコードと呼ばないようにする」ことを本セッションにて提案したいです。

「心理的安全性が高いチーム」「人として、周りに気を配れる」「社会性フィルター！オン！！」
どれも大事ですね。とても大事です。
ですが、私は、もっと利己的な理屈をもって「クソコードと呼ばない」というムーブメントに取り組んでいます。
「温かい空気を作るため」ではなく、「もっと自分が技術者として成長するため」に、「クソコードなんて言葉は使わないぞ！」と決めたのです。

コードや成果物に対する「批判」は大事です。しかし、それは決して「あげつらう」ことではありません。
共有可能な価値観を提示し、それに照らし合わせて、より適正な在り方を目指す・・・そうした「批判」です。

「なんでこんなコードを書くのだろう」。
その根本にあるのは「コードの書き主が知らないことがある」「自分が見落としている事がある」の何れかです。
ここで「それはクソコードだ」と言ってしまえば、思考は停止してしまうと思います。
もっとダイブ出来るはずです。書き手の気持ちを考えよう。「なぜこの書き方を？」「どういう思考プロセスを経てこの書き方をしたのか？」「自分だったら、どこで”こうじゃない”と気付くはずか？」「単に書き手の技量不足だろうか。その足りない知識は、自分がわかりやすく説明できるだろうか？」クソコードから学べることは多いと考えます。
自分で納得できるまで「そのクソコードの生まれた歴史」を突き詰めていますか。

改めて、クソコードを超越した開発者になりたいと強く念じます。
極めて個人的な主張、理屈になってしまうかも知れません。
ですが、このセッションを通じて、こらからの未来に1回でも多くの「クソコード」発言が減らせたら幸いです。

オンライン勉強会やイベントが続くこと1年。
なかなか参加者の盛り上がりを登壇者や参加者間で共有することができずモヤモヤした日が続いてきました。
そこで効果音を共有することで課題を解決するサービス pong swoosh を公開しました。
開発の経緯、実際使ってみてどのような反応があったのかを紹介します。