PHPカンファレンス福岡 2016 に行ってきた

2016-05-22
イベントに参加した
PHPカンファレンス福岡 2015

概要

項目 内容
日程 2016年05月21日(土) 10:15 – 18:00
会場 FFBホール
公式ページ http://phpcon.fukuoka.jp/
公式Twitter @phpcon_fukuoka
公式ハッシュタグ #phpconfuk

去年に引き続き参加。去年参加分は[2015-06-28-2]を参照。カンファレンスで公開されているスライドをまとめたサイトがあるので参加していないセッションの内容はこれを参考にする。

制約と上手く付き合う ／ 新原 雅司 (@shin1x1)

発表資料が公開されている。

内容メモ

実演した制約は以下

  • アクセス修飾子とタイプヒンティング
  • 不変オブジェクト
  • インタフェース

質疑の中で出た話題

Q：ライブコーディングではPHP7を利用していたが、バージョンが低い場合はどうするのか？
A：戻り値の型宣言以外はPHP5系でも利用可能

Q：PrivateとProtectedの使い分けは？
A：まずはPrivateを考えて、必要に応じてProtectedを指定する。
　　PHP 5.4以降ではtraitがあるので機能のために継承する必要がなくなったためProtectedを使う機会が減ってきたのではないか
　　公開されているスライドの最終ページを参照のこと

感想

ショッピングカートを例に制約を実演していくライブコーディング形式。基本的な内容ではあるが朝一のセッションとしては調度よい感じだった。

ドキュメントを支える技術 ／ 小山健一郎 (@k1LoW)

発表資料が公開されている。

内容メモ

対象は技術ドキュメントではなく、概算見積もりやスケジュールなどのクライアントと共有するための文書。
これらの文書は印刷し体裁を整えるのが前提となる。

ドキュメントづくりを効率化、あわよくば自動化したい。

サーバの利用状況レポート

むかしはEMR＋Excel＋PowerPointでやっていたが辛い
→ Embulk＋PHP、HTML、CSS、JSでレイアウトを作り自動化する

PHP、HTML、CSS、JSでの印刷レイアウトは結構イケる。

インベントリ情報

インベントリ情報とは、サーバにインストールされているパッケージのバージョン一覧のこと。

サーバ1台ごとに調べていくのはつらい
→ Komaを使ってJOSNで出力。結果をPHPで処理し、Excelに出力する

PHPからExcelへの出力にはPHP-ExcelをForkしたものを使っている。

概算スケジュール

ガントチャートや方眼紙Excelはつらい
→ CSVからガントチャートExcelを出力するWebサービス化したti.mefra.me。cURLからも実行できる

まとめ

  • HTML＋PHPで印刷はよい
  • 紙はなくならない
  • PHPにこだわらず使えるものは使って効率を上げていく

質疑

Q：直接PDF等に出力するようにはしないのか？
A：現在作ってる途中です

感想

最近、事務仕事が多くなって提携の書面を作る機会が増えているので、興味があった。PHP＋HTML＋CSSで印刷するのは毎回挑戦して微妙にデザインが崩れてげんなりすることが多かったのだけど、割にいい線いけるらしい。もう少しどうにかしてみるか。

Guzzle Promise を使った非同期処理による API コールの高速化 ／ 鈴木則夫 (@suzuki)

発表資料が公開されている。

内容メモ

1時間毎にAPIを叩く100万件の処理を行う必要があったが、普通にやっていては間に合わない。そこでPHPで実装されたHTTPクライアントライブラリのGuzzleを使った。Guzzleは非同期処理やPSR-7にも対応。スライドではサンプルコードも多数。

単純にGuzzleを使っただけでは処理が追いつかなかったが非同期処理を使うことで対応できた。

  • Guzzleの非同期処理はPromiseというJS由来のモデルを利用している
  • 詳細は「JavaScript Promiseの本」
  • 単純に非同期の並列処理を使うと、メモリ不足などに直面するので必要に応じて対応する
  • Generator(yield)＋poolなど

感想

お仕事の中でAPい叩いたりとかHTTPで一括処理をしたりという機会は割と多くあるのでGuzzleは今度触ってみたい。一回何かしら書けば流用しやすいような気もするんだけどどうなんだろう。

Go言語で実装するLinuxNameServer ／ 山下 和彦 (@pyama86)

発表資料が公開されている。

内容メモ

Go 1.5から共有ライブラリを作成することができるようになった。その御蔭で、Goがワンバイナリで動くプログラムを書けるというメリットに加えてLinuxのミドルウェアを作ることが可能になった。

ただし、幾つかの制限はあるし、Linuxを含めたテストも必要になるためC言語の知識や覚悟が必要になる。

Goの特徴

  • バイナリ
  • 共通ライブラリ
  • サーバ
  • クロスコンパイル
  • 圧倒的生産性

感想

Go言語は前から気になっていて手を付け始めている。とは言っても仕事ではあまり使いではないのでどうしたもんか。流石にLinuxのミドルウェアは書かないけど、前のセッションの非同期処理の辺りとかも含めて仕事っぽく試せればいいんだけど。

PHPerに知ってほしいRDBの事 バージョン 2 ／ 曽根 壮大 (@soudai1025)

発表資料が公開されている。

内容メモ

データベースの寿命はアプリケーションよりも長い。サービスの寿命＝データベースの寿命と言っても過言ではない。

検索Index

まずは実行計画(EXPLAIN)が大切。以前行った実行計画の話も参照のこと。

  • MySQLでは、1つのクエリでINDEXは1つしか使われない
  • INDEXでは重複が少ない(結果が少ない)ほうが良い。全体のレコードの10%～30%程度が目安
  • MysqlではJOINが遅い。対象を少なくしてJOINする。不要なJOINは避ける。INDEXを利用したJOINをする
  • 難しいことをしないで済むような設計をするのが大事

MySQL WorkbenchやpgAdmin3ではEXPLAINの結果をグラフィカルに確認することができるのでわかりやすい。

削除フラグの話

一般的に使われることが多い削除フラグ(論理削除)という闇。WHERE句が積み重なる、UNIQUE制約が効かなくなる、条件式が複雑になるというデメリットがある。

  • Viewを作っても高速化にはつながらない
  • INDEXが効かなくなる(大部分のレコードがdeleted = 0に該当してしまうため。全INDEXにdeletedを追加する必要がある)
  • UNIQUE制約が効かなくなるのでデータの外部キー制約が使えなくなる。整合性を担保できずバグの温床になる

対策としては
– 削除済みデータ用のテーブルを作る
– そもそもデータベースにステータスを持たせない

感想

PostgreSQLの方はあまり興味がなかったので端折っている。INDEX周りは毎回色々難儀しているので参考になった。MySQL WordbenchでEXPLAINの結果をグラフィカルに見ることができるのは知らなかったので、さっそく明日からでも使ってみる。

削除フラグの話はほんとに耳が痛い話で。要望の問題もあり、どうしても作ってしまう。ただ作り方の問題だと思うので、例えば削除データ用に汎用的なテーブルを作っておいて、削除されたデータをJSONで放り込むなんてのは比較的ラクに作れるかもしれない。

どうせ何かあって戻すときは人手で戻す必要があるんだから、そのくらいラフでもバチは当たらない気がしてきた。

日本で一番PHPのシステムをテストしている手動テスターが思うところ ／ フクダリナ (@rina)

発表資料が公開されている。

内容メモ

Fusicでは唯一のテスター。エンジニア25人に対して一人。年間 約35案件をテスト。手動でのテスト。

素早く効率的にテストをするために
– 進捗のエビデンスなどは作らない
– パターンを全網羅するようなテストは行わない
– バグを見つける
– おかしな仕様を見つける
– デザインの違和感を教える
– 仕様書がなくてもテストする
– テスト手順書は作らない
– 動かしながらテストする

テストでは品質は上げられない。品質を上げられるのはコード。

感想

Fusicのテスターが一人とは思わなかった。言いたいことは実感としてわかるんだけど、職人の技が光っていて中々横展開ができなさそう。あとテスターにエンジニアの経験があるだけでテストする側もされる側もだいぶ変わるんだろうなぁっと思う。そういう意味では羨ましい限り。

HTTPメッセージ – PHPで扱う場合の再入門 ／ させざき (@sasezaki)

発表資料が公開されている。

感想

正直良くわからなかった。

Slim3とPSR-7 ／ 市丸 朋史

発表資料が公開されている。

内容メモ

[Slim(http://www.slimframework.com/)]はphp the right wayを書いた人が作ったマイクロフレームワーク。基本的には router、 middle、PSR-7、di-containerしか無い軽量なフレームワーク。composerなどのおかげでライブラリが外に出ていく傾向があり、slim2からフレームワークとして提供している機能が減っている。

感想

Slimは前から気になっていたフレームワークなので概要がわかった感じ。とは言っても実戦投入ってレベルの理解まではできていないので、これも今後の課題にしたい。特に複雑じゃないAPIサーバなんてのだったら簡単にかけるんだろうけど、もう少し複雑なものになるとどういう風にするのか辺りが気になるところ。

WordPress REST APIが開くWordPressの未来 ／ 宮内 隆行 (@miya0001)

発表資料が公開されている。

内容メモ

WP REST APIは、WordPress 4.4から追加されたWPをJSON REST APIで操作するための仕組み。現時点のバージョンではWP-APIプラグインが必要(4.7からCoreに取り込まれる予定)。正統派RESTfull API。プラグインで拡張することも可能。

今までのWPの問題点

  • フロントエンドの人がPHPを覚えるコストが高い
  • スケーリングが面倒くさい
  • WP自体が1枚岩過ぎて複雑になりすぎている

WP REST APIで解決できること

  • WPをバックエンドシステムとして扱える
  • 普及しているWPの管理画面を使えることは利用者の学習コストを大幅に下げることができる
  • フロント側では本番環境でもステージングでもライブデータを扱える
  • マイクロサービスの一部としてのWP。他のCMS都の連携も
  • APIの結果にキャッシュを効かせることができるようになる
  • 開発のワークフローの改善（フロントとバックエンド）

実例

  • フロントエンドをnode.js＋React。バックエンドをWordpress
  • フロントのサーバはDocker
  • npmのサイトもバックエンドはWordpress
  • node.js側でキャッシュしているのでWP側が落ちても大丈夫
  • NewYorkTimesやWiredなどでも利用されている

WP-APIはWPのテーマ主体としたエコシステムを変える存在になりうる。

カスタム投稿タイプはWPのボトルネックになる。WP-APIで複数のカスタム投稿タイプを利用するのであれば、WP自体をカスタム投稿タイプごとに分けてしまうのもあり。

感想

タイトルの段階では特に興味はなかったんだけど、今回一番面白い話だった。

確かにWordpressのフロント側ってのは面倒くさいんだけど、Wordpressのバックエンドは使いたいって要望はありそう。というか本編中でもあったように利用者の学習コストを大幅に下げることができる。

それに加えて、バックエンド側を開発するコストも大幅に下げることができるので、案件全体の省力化が見込めるような気がする。カスタム投稿タイプ周りなんかもあるので、テスト的にやってみてその辺りを確認してを見てみたい。

CakePHP3レポート ／ 伊藤 潤樹 (@Junkins_110)

内容メモ

CakePHP 2と一番変わったところは、ModelのEntity。これを有効に使うことでModelの負担を減らし、よりCakePHP3らしいコードを書くことができる。

感想

別の方が補足記事を書いてくれている。

ライトニングトーク

トランスパイルという文化の話 ／ 平尾ゆうてん (@cloud10designs)

セキュリティは2016年も「熱男」で行こう！ ／ Tomohiro Hanada (@decoy_service)

PHP関数他探訪2016 ／ 平田 哲 (@debility)

発表資料が公開されている。

Codeceptionでテストしよう ／ 野島 隆 (@nojimage)

発表資料が公開されている。

Composerを活用した脆弱性ハンドリングツールのご紹介 ／ 諌山鉄平 (@tette)

発表資料が公開されている。

まだ正規表現で消耗してるの？ ／ 岸田 健一郎 (@sizuhiko)

発表資料が公開されている。

Perlに比べてPHPが不便（主観です）ああ…だから僕は… ／ 石田 絢一 (@uzulla)

発表資料が公開されている。

swaggerでかっこいいAPIドキュメントを作ろう ／ 渡辺 一宏 (@kaz_29)

発表資料が公開されている。

タイトルとURLをコピーしました