トーク

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

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

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

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

TBD

みなさんサーバーレスってますか？PHPerでもサーバーレスってますか？
どうやら世の中サーバーレスだったりマイクロサービスだったりがモダンなようです
AWSは使っていても、構成は結局LAMPどまり…というぼくが、次の新規案件にサーバーレスを採用しようと決めました
一足遅くなりましたが、このビッグウェーブに乗ろうとしたぼくの過程をお話ししたいです

ためしに、このトーク用に #サーバーレス で動くモノを作ってみたいと思います

最近ではフロントエンドをJavaScript(typescript)を使用して開発するケースが増えていると思います。
また、最近ではnodejsを使ってのSSRなSPAアプリだけでなく、GatsbyやNext.jsのようなReactベースの静的サイトジェネレータも注目されています。

このセッションでは、2年ほど前にSlim3で作った簡単なPodCast配信用WebアプリのReact/Next.jsでの作り直し作業を通して、React+Next.js+SSGで静的なサイトとして構築する際の構成やメリットなどを解説したいと思います。

いわゆる「大規模」と言われるウェブサービスで、SEOを考えるときに直面するのが、「クロールバジェット」と呼ばれている、クロール割り当ての最適化です。
婚活パーティーのポータルサイトであるオミカレでは、最大で4万件以上の婚活パーティーの情報と、それを検索するための都道府県・市区町村・ジャンルといった多種多様なリストが存在し、「ページ」数は膨大なものとなっています。
その膨大な中から「Googlebotに見てほしいページ」にどうやって効率よく誘導するか？はとても大きな課題です。
そこで、2019年6月に行ったオミカレのフルリニューアル以降、直面したクロールバジェットにおける問題や対処法について紹介します。

主な内容

• 立ちはだかるリニューアル前のURL
• 想定通りにならないcanonical
• 第一回リダイレクト祭り
• 居座るはるか昔の日付
• 一筋縄では行かないrobots.txt
• 検索とパラメーターとインデックスとランディング
• 終わらない内部リンクの検証
• 第二回リダイレクト祭り
• これまでの教訓

PHP界隈でもドメイン駆動設計の話題が盛んな昨今ですが、正しい設計のためには前工程としての要件分析が不可欠です。詳細な設計に入る前にプロダクトオーナーが読み解ける形式の文書で合意を取っておけば、最小のコストで「本当に必要なもの」を作るための足場となります。また、ドメインエキスパートを設計の深いところまで連れて行くための道標も手に入るでしょう。

このセッションでは、システムとユーザーの相互作用をユースケースシナリオとして表現し、そこからオブジェクト指向らしいクラス設計を導く手順を紹介します。設計スコープと目的レベルについて理解し、簡単なフォーマットさえ覚えれば、誰でも明日からユースケースシナリオを活用できるようになります。

一昨年、昨年とWebアクセシビリティの前提や概念についてたくさんお話してきました。
そろそろじゃあどうやって実装するんだという意見を聞いたり聞かなかったり。

PHPerでも一度は言われたことがある（？）「簡単でいいのでお問い合わせフォームを作って欲しいのですが。」「ここマウスカーソルがあたったときに説明が出したいんですが。」「ここにタブを用意して切り替えられるようにしたいです。」
ときにはJavaScriptか…と思いながら実装をしているかと思いますが、きちんと伝えるべきユーザーに伝えられていますか？
これまでのトークから一歩踏み出して具体的なWebアクセシビリティを意識した実装についてお話したいと思います。

本トークでは下記についてお話をします。
・今からでも遅くない！Webアクセシビリティ入門
・Webアクセシビリティを意識した実装とは
・WAI-ARIAについて
・WAI-ARIAを用いた実装事例紹介

エンジニア向けイベントのスポンサー担当をここ数年やっています。
会社としてはもともとそんなに積極的にスポンサー活動をしていたわけではないので、どういったことをきっかけにするようになったかの背景を始め
・スポンサーするにあたって予算とかどうしている？
・効果測定は？
・実務面では何している？
について話します。
このトークをきっかけに、より多くの会社様がエンジニア向けイベントのスポンサーになってもらえればと思います。
もっともそれ以前に、スポンサー担当していると、自社のロゴがイベントサイトに掲載されたり、会場でロゴがあったりするだけでイベント参加が一段と楽しくなるので、そういう楽しさを是非共有したいです。

PHP 7.4 で追加された FFI を通じて、 Linux の FUSE を利用することができます。
つまり、今や我々は PHP でファイルシステムを作ることができるのです。
たとえば WordPress ファイルシステムを作ってマウントすることで、grep や sed を通じて DB 内の記事データを編集するような誰得な操作も可能となります。
このセッションではそんな FFI による大道芸、PHP によるシステムプログラミングの実例とそこで使われている技術について簡単にお話します。

AWS,GCPなど様々なクラウドリソースのコード管理を実現するTerraform。
小規模なインフラ構成であれば単一レポジトリにディレクトリを分けずに配置して、シュッとお手軽に利用できます。
しかし、大規模な構成になってくると、途端に管理が面倒になり、ベストプラクティスも存在しない世界になります。。
このトークでは、Terraformのレポジトリ、ディレクトリ構成について、これまでの苦闘した軌跡と、現状のベストだと思う構成、将来的にどうあると良いと考えているか？について話します！
トーク後にはぜひみなさんとディスカッションしていきたいです〜

ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。
PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。

トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。

ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テストの整備につながり、直接的な顧客価値となる外部品質の明確化・維持・向上が期待できます。

このトークでは次の内容について話します。

• ATDDとはなにか、Example-driven Developmentの考え方
• 前提となる「Agile Testing」の考え方
• ATDDを実践する開発プロセス
• テスト自動実行基盤の構築プロセス・構築例
• ATDDを実現するツール選定とツールを用いた「受け入れテスト自動化」
• エンドツーエンドなテスト構築（APIサービスとブラウザベースサービス）
• TDDからATDDへ、自動化テストピラミッドを登っていく

内容は特定技術の実装からインフラ・CI基盤、開発文化・プロセス自体と多岐にわたりますが、ソフトウェアテストという側面で開発を駆動させるあり方として参考にしていただければ幸いです。

2020年の10月に「Fukuoka.php Vol.32」という勉強会で Laravel Livewire のデモを発表する機会をいただきました。

概ね好評だったのですが、一部の方から
「キモい」
「ヤバイ」
「怖い」
「負荷で死にそう」
「次世代jQuery」

という感想もいただきました。これらの危惧を払拭すべく個人プロジェクトではありますがLaravel Livewireを使用したアプリケーションを作成しました。

作成したアプリケーションを例に Laravel Livewire の使い方、内部ではどのように動いているのか、作成時に気をつけたことなど説明します。

Laravel Livewire は決して怖くはありません！！！！

2021年のPHPはPHPStanやPhan、Psalmを用いる事で型検査や不要なコードの検出が可能です。
新規のプロジェクトでは、初期から静的解析ライブラリを導入することにより実行時エラーをデプロイ前に検出することができますが、古くからあるプロジェクトでは、導入しても十分に静的解析の力を発揮することができない場合があります。
古くからあるプロジェクトに静的解析ライブラリを導入するために、何が静的解析の障害となっているか調査しました。
計画的にレガシーコードのリファクタリングを行なうために行なったコードの解析手法についてお話しします。

PHPでは配列の初期化処理がopcode列にコンパイルされて実行されるため、巨大配列の初期化は実行時にコストがかかっていました。ところが、PHP 7からは定数だけで構成された配列リテラル（＝定数配列）をコンパイル時に生成して利用するように変わっています。さらに定数配列はOPcacheのキャッシュ対象になっているため、キャッシュヒットすれば巨大な定数配列を生成コストなしで使えるようになっています。本トークでは技術的背景を簡単に説明した上で、定数配列とKVS（APCu・memcached・Redis）で同じ機能を実現した場合の性能比較を行います。

GraphQLは2015年にFacebookにより開発されたRESTとは異なる新しいAPIフォーマットです。
​PHPでもLighthouseというGraphQLフレームワークの存在により、簡単に実装することが可能となりました。
​
​しかしいざ中〜大規模なプロダクトで使用するとなった時、十分な性能や応答速度を発揮することはできるのでしょうか？
​今回は実際にPHPでGraphQL APIを構築し、それに対して負荷試験を行った結果からREST APIとは異なるポイントや負荷のかかり具合の違い、コードチューニングの勘所などについてお話ししたいと思います。

サイボウズの大企業向けグループウェアのGaroon（ガルーン）は、PHPで開発されている19年目の製品です。
PHP 4からPHP 7までアップグレードを追従したり、もともとパッケージ製品だったものを、cybozu.comという自社クラウドでも提供を行うようにしたりと、今でも現役で開発されており、サイボウズの主要製品の一つとなっています。

今回は、ガルーンのお客様からいただいた技術的な問い合わせについて回答する、テクニカルサポートチームのお話をします。
10年程前までは、技術的な問い合わせを専門に対応するチームはありませんでした。
お客様の電話やメールの対応をするカスタマーサポートチームとガルーン開発メンバーの間には、想像以上に大きな組織の壁がありました。
多くのお問い合わせに追われ、満足のいく製品開発ができない時期もありました。

しかし、2011年にお問い合わせ対応や不具合改修専門のチームができて、状況は徐々に変わっていきます。
組織の壁を感じることなく、お客様に対して一丸となって対応していきました。
質の高い回答ができるようになり、お問い合わせ1件に対する効率も上がっていきました。

現在では、テクニカルサポートチームが通常のお問い合わせ対応だけでなく、そもそもお問い合わせを減らすべく、安定運用のための開発をおこなえるようになってきています。

そんなテクニカルサポートについて、10年前の問題と、現在の状況、さらに今後の取組について、対談形式で発表します。
エンジニア2名とサポートリーダーとプロダクトマネージャーの4名でお話したいと思います。

同じような苦労を抱えるテクニカルサポートチームにとってのヒントになれば幸いです。

あるシステムを理解して開発を開始するとき、必要なのはInfrastructure as Codeを含むソースコードだけでは大抵の場合は不十分です。では挙動がわかるようなテストコードがあれば十分かというとそうでもありません。
いわゆる「オンボーディングの効果的な運用」「開発開始までのオーバヘッドの削減（PHPerKaigi2020で発表）」は継続的な生産性向上のためには考えなければならない要素です。
そして、上記を補完するためにしばしばドキュメントが書かれます。

私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。
私はこれを「Documentation as Code」と呼んでいます。そして、そのような概念はすでに世の中にあり、時として「Documentation as Code」と呼ばれているようです。
例えばPHPDocなどはソースコード自体の構造とアノテーションをトレースしてドキュメントの自動生成を実現しています。
OpenAPIのように構造化されたデータとして情報を記述することでドキュメントと同時にAPIクライアントやの自動生成が実現できている例もあります。 これらはコードによってドキュメントが管理されており、継続的なドキュメンテーションも実現可能です。
さて、ドキュメントと言っても「何を解決するためのドキュメント」なのかを考える必要があると思います。
本発表では、上記のような「Documentation as Code」を実現するツールを独自にモデル化してそれぞれの特性について考えます。
そして、どのような「Documentation as Code」が「開発開始までのオーバヘッドの削減」に繋がるのか、私が実際に取り組んだ（また取り組んでいる）事例を交えて考えていきたいと思います。

令和の世においても根強く利用されるデータフォーマット『CSV』
他サービスとのデータ連携やバルクデータ入出力などで使い勝手が良いため、未だに大活躍しています。

ですが、PHPでは扱うための癖が強く「微妙にダメなのは判っているけど諦めて使っている」「そもそも絶対におかしくなるので編集してから利用、または入れてから編集している」などのつらくきびしい現実がありました。
また、一般的には「変換不能文字があると行ごと無かったことにするiconvストリームフィルタ」や「メモリが枯渇しやすくなるmb_convert_encodingを用いた対応」など、一見安全に対応できたように見えて運用面で深刻な問題を抱える対策が蔓延っています。

このトークではそんな現実と対決し「ダメだと判っていたそれを解決」「そもそもおかしくならないのでゼロストップでデータ入出力」できる方法をご紹介します。