トーク

TBD

厳選したPHP8ネタを、カンファレンスでも引っ張りだこの人気プログラミング講師・なるせ先生に出題。
PHPのみならず、さまざまな知識の引き出しを持つなるせ先生でさえ知らなかったものを「PHP学」に認定する。
なるせ先生が「知らなかった！」と申告したら出題側の勝利。
知っていたネタはなるせ先生が”生授業”で自ら解説する。
まさになるせ先生が貯蔵する知識量との大勝負！はたしてどんな驚きの情報が飛び出すか！？

PHP製オープンソースCMS「Drupal」をご存知でしょうか。
OSSとして公開されて今年で20年目を迎える老舗ソフトウェアですが、オブジェクト指向やSymfonyの採用、Composerの導入、ヘッドレスCMSへの対応など、多くの技術トレンドを取り入れながら進化し続けています。
日本ではあまり知られていないですが、世界に目を向けるとあんな企業やこんな組織が、色んなところでDrupalが活用されています。
Drupalを触ったことがない、聞いたことがないPHPerの方々に向けて、Drupalで何ができるのか、Drupalの魅力についてご紹介します。

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

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

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

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

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

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

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

2 年にわたり、ソフトウェア開発の古典＝デザインパターン/アンチパターンをマンガで紹介してきました。このトークではいよいよ古典中の古典「人月の神話」に言及します。こうした古文書が、モダンな設計開発を模索して現在を生きる私たちに何を物語っているのか、時代を超えた私たちが何を学ぶべきなのかを紐解いていきたいと思います。

6年続くWebサービスをリプレイスすることになりました。
あなたならまず最初に何から手を付けますか？

このトークでは、弊社（コネヒト）が運営するママ向けNo.1アプリである「ママリ」のシステムの一部（CakePHP2.x / PHP7）をリプレイスしている状況を共有したいと思います。
長年に渡って機能改修が繰り返され、複雑なドメインを有するサービスは単純にフレームワークを新しくしたり、あるいはLaravelなど別のフレームワークに載せ替えるだけでは解決できない問題がたくさんあります。

様々な工夫を凝らし、今回の基本戦略である「無駄な物をなるべく作らない」という方針でどうやってリプレイスを進めているのか、具体的なプラクティスを交えながらご紹介します。

PHPで画像に縦書きテキストを描画する話です。
横書きテキストしか描画できないImageMagickと、ICU (Intl) を使って実現します。
発表では以下の内容を踏まえて縦書きテキストを画像に描画する方法とその要素技術についてお話しします。

• 縦書きテキストとは何か
• テキストを構成する文字について
• 文字を描画するためのフォントファイルについて
• フォントファイルを扱う時に便利なttxというツールについて
• PHPから使えるImageMagickについて
• PHPから使えるICUについて
• 文字列を折り返すということについて

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

トラブルの耐えない決済システムをPHP×Laravelフレームワークでリプレイスするにあたって、どのような課題に対して、どうやって改善したかをお話します。

前半20分は、リプレイス後の決済システムのしくみについて、後半20分は、20万レコード更新を同期処理で実現したことについて、弊社DBAのyoku0825さんと感想戦をします。

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

「より良くPhpStormを使うために、コーディング規約やテスト実行の設定をプロジェクトやチームで共通化しよう」

.idea/ ディレクトリを.gitignoreで無視するように設定しているレポジトリをよく見かけます。
もし”慣習的に”そうしているのであれば、勿体ないかも知れません！

普段の開発にPhpStormやInteliJ IDEAファミリーを利用している方も多いのではないかと思います。
高機能でありながら、「少しだけ」使う分にも充分に威力を発揮することには、ユーザーの皆さんも同意されるのではないかと思います。
他方で、「設定しなければいけない項目」も少なくないのも事実です。

Inspectionの設定、Interpreterの設定、テスト実行の設定・・・
これらを「PJメンバー全員で同期する」ことができれば、一気に効率が良くなります。
「生産効率」の水準が揃う、という手段となります。

そのための手段が「.ideaを共有する」なのです！！

どのように使えば良いのでしょうか？
また、それによってどこまで実現できるのでしょうか？

本トークを通じて紹介します！

phpinfoは、インストールする時によく使いますね。
それがどのように動いているのか知りたくなったので、phpinfoを写経してみて、わかったことを共有したいです。

最近の PHP コードは意外と型の恩恵が得られます。
PHP 7.0 でのスカラ型宣言、7.1 での nullable、7.4 でのプロパティ型宣言、 8.0 での Union や明示的 mixed の導入といった言語自体の機能追加もあるのですが、psalm や phpstan といった静的解析ツールを利用することで、静的型検査や mixed の排除、Type Erasure な Generics の利用といったことさえできます。
このトークではそんな最近の PHP の型事情、ツールについてのお話や、実際に静的解析ツールを最高レベルで利用し型をガチガチにしながら PHP コードを書く際の注意点についてお話します。

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

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

主な内容

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

「プロダクト開発が、メンバーの技術力を高めるのか」「メンバーの技術力向上が、プロダクトの品質や可能性を高めるのか」
皆さんは、この「鶏が先かと卵が先か」に似た構造を持つ問題についてどのような考えをお持ちでしょうか？

本セッションは、自分自身の取り組んでいることを紹介した上で、
オーディエンスの皆さんからの視点や経験を織り交ぜたフィードバックと議論を集め、『共有知』を生み出す試みとしたいと考えています。
(折角のオンライン＆録画発表なので！)

この課題を選んだ背景

プロダクト開発や(Web)サービスの提供を行う会社において、
Webエンジニアに求められる主要な成果は「プロダクトを良くする」ことだと思います。
プロダクトをよく出来るエンジニアとは、どういう存在でしょうか？
実は、「プロダクトをよく出来るエンジニア」になるには「プロダクトを開発する以上の技量」が要求されるのではないでしょうか。

ここには大きな矛盾があると考えています。
「プロダクトを良くし続けるには、プロダクトに必要なレベルの技量では足りない」という矛盾です。
これについて、自分自身が、所属先の企業でのロールが変化したのをきっかけに取り組むようになりました。
組織の姿が「プロダクトを作れる」を超えた「プロダクトの未来を作れる」ようになるにはどうすればよいか・・？と現在進行系で考えています。

紹介するお話

例えば、以下のような取り組みが「自分なりに考えたこと」でした。

• 「技術力」を定義する
• プロダクトと技術力の関係
• 自分自身が「技術的な成長」を感じた瞬間を構造化して捉える
• その「良いフィードバックの獲得の仕方」を組織的に再現できないか？

こうした話を「議論のネタ」として提供したいと考えています。

※ 以前にタガヤスという技術勉強会でお話した内容の改訂版です。

普段我々が使っているコンピュータシステムというのは、階層的なシステムです。

物理法則から電気回路が作られ、ハードウェアが作られ、ハードウェアの上で動くファームウェアや OS があって、更にその上で動くアプリケーションがあって、アプリケーションの中でも C 言語で書かれた PHP 処理系、更にその上で動く PHP で書かれたスクリプト、というように、何重もの階層化がされています。
土台になるものから高く階層を積み上げていく、というイメージで、階層の上のほうにある技術を高レイヤー、下のほうにある技術を低レイヤーと呼んだりします。

PHP のスクリプトというのは比較的高レイヤーに属するプログラムなわけですが、PHP コードがコンピュータ上で実際にはどう振る舞っているのか、どういう仕組みでできているのか、というのは、当然より低レイヤーの技術で成り立っています。

今回のセッションでは、そんな PHP より低レイヤーの世界へ FFI を通じて PHP スクリプトからアクセスし、PHP 自身から階層をぶち抜いてスクリプトの動作を下の方から覗き見てみるという、少しひねくれたことをやる自作のツール、php-profiler についてお話します。

雑に言うと PHP で ELF と procfs と ZendEngine の内部構造体をパースしつつ FFI で外部プロセスのメモリを読み取り、スクリプトの動作を盗み見るお話です。

私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。
私はこれを「Documentation as Code」と呼んでいます。そして、そのような概念はすでに世の中にあり、時として「Documentation as Code」と呼ばれているようです。
例えばPHPDocなどはソースコード自体の構造とアノテーションをトレースしてドキュメントの自動生成を実現しています。
OpenAPIのように構造化されたデータとして情報を記述することでドキュメントと同時にAPIクライアントやの自動生成が実現できている例もあります。
テストケースに振る舞いを自然言語で併記しながらテストコードを書くことで結果としてテスト仕様や要求仕様のドキュメントで実現するようなアプローチもあります。
私もシステムやコードからドキュメントを生成するようなツールを少なからず作ってきました。
そういった経験から、本発表では、上記のような「Documentation as Code」を実現するツールを独自にモデル化してそれぞれの特性について考えていきます。
そして本発表を通じて皆さんが「Documentation as Code」に興味を持ってもらえればと嬉しいです。

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

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

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