トーク

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.

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

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

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

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

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

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

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

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

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

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

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

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

静的解析、利用していますか！
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回でも多くの「クソコード」発言が減らせたら幸いです。

これまで社内勉強会活動として、トイレ利用状況を可視化サービス「Toilet Evolution」、常駐先から出退勤するサービス「Dakoku」を開発してきました。
デバイスやセンサーを使った開発はオフラインが主体でしたが、コロナで活動自体が難しくなりました。
そこで実デバイスでなくThingをオンラインに参加する人の感情と見立て、共有することがオンライン時代でのガジェットになる、と考え新サービスの開発を始めました。
これまでのものを含め、勉強会主体でサービスを作ることと、開発中のサービス pong swoosh について紹介します。

初めての登壇チャレンジです。
Webセキュリティ脆弱性に恐怖と興味を抱き「OWASP TOP10」や「安全なWebアプリケーション入門」IPAの「安全なウェブサイトの作り方」とかを見て調べました。
これ結構ちゃんと対策しなきゃな...というものもあれば、これの対策が必要なWebシステムってそんななくない？と感じるものもありました。
どのシステムでも対策が必要そうなメジャーなWebセキュリティから順に素のPHPもしくはLaravelのコードを用いて解説できればと思います。
Webエンジニア歴は浅いのでご容赦ください。

【お話しする内容...】
現在、世界の開発者1800名のユーザーが使用、有志の企業/開発者からの支援を受け「LaravelDB.com」を開発し、運営しています。
前回のPHPカンファレンス2020では「何故作ったのか？、仕様、主な使用方法」を解説しましたが、
今回は「Webサービスを作るまでの始まり、どのように進めて作ったのか？DB選択？」などお話できればと思います。
「言語解説」というより、開発者としてどうやって1ヵ月でプロダクトをリリースするまでやったのかという話をしたいと思います。
【ターゲット層】
PHP初・中級レベルの人がメインのターゲットになると思います。
1人で全てを作り切ったことが無い、個人開発してみたい、新規事業でβ版をリリースを考えてる人 向けになると思います。

技術があればある程度の物は作れると思うのです。会社や周囲を巻き込んで何か実現しようと思った際は企画書が有効です。
そもそも会社は稟議で承認を得てますが、その稟議も企画書なのです。一方で技術はできても企画書を書くのはちょっと苦手という方もいると思い、PHPer向け企画書の書き方と企画力の高め方を実例を用いて解説します。

企画書の本も出した企画者一筋30年の講演者が解説します。（うわっハードルを上げてしまったｗ）

皆さんアプリケーションのセキュリティ対策はしっかりしていますか？
フレームワークを使っていれば大体自動で対策をしてくれているCSRFですが、実際どういう攻撃手法でどういった対策をされているか認識してる人はどれくらいいるでしょうか？
本セッションではまずCSRFとはどういった攻撃手法なのかを解説します。
次にメジャーなフレームワークのソースを読み、どうやってCSRFを対策しているかを読み解いていきます。

大きなカンファレンスでプロポーザル採択による登壇はしたことがありません。
よろしくおねがいします！

途中から入ったLaravelでの開発プロジェクトでFat Controller(3000行以上)がありました。
このControllerをいかに可読性の改善、ファイルの細分化を行ったか話していきます。
例えば、外部サービスを使っているロジックはSrviceクラスに切り離し、ビジネスロジックはModelに切り離しました。
その他にも定数などになり得る箇所はEnumに切り離しました。
このようにいろんなロジックが入りがちなControllerのロジックを役割ごとに分離するやり方を解説していきます。