phpカンファレンス福岡に関する2件の投稿 - Qiitaがあるからよかろうもん？

コミュ障は会場の雰囲気がわからないと行きにくいだろうからご参考に。¹

自分語り

2015・2016年にもROM専一般参加してました。
ブリーゼプラザが近場だったので。

PHPおよびプログラムの専門的・実践的知識はあまりないのであしからず。
内容の正確さも保証はしないです。
内容の紹介と感想が入り混じっています。

ツイッターのハッシュタグも追ってません。
画像もないです。

場所

今年からグランフロント大阪へ。
きれいなのはいいですが、迷いました。

案内は

グランフロント大阪北館タワーＣ8階
カンファレンスルーム

ですが、(実質)一般用？とオフィス用に分かれています。
大阪駅からタワーCへ向かって、すっと入りそうな左手のエレベーターでは8階は7階から続くナレッジキャピタル(従業員専用)に続きます。
目的値は右手側のオフィス用のそれらしいエレベーターです。
もっと事前調査しとけばよかったです。

カンファレンスルーム Tower C｜アクセスマップ｜ナレッジキャピタル（グランフロント大阪内）

accessmap_conference_C.pdf

ブリーゼプラザはエスカレーター可で心の準備ができましたが、こちらはエレベーターなので予測不能でドキドキしました。

持ち物

(最低)過去2年であったボールペンの記念品は今年はなかったので、自筆派は筆記用具を持っていきましょう。
全員がノートPCでカタカタしている感じではないです。

受付

例年通り、チケットのQRコードを見せるだけ。配布物を受け取って基調講演ホールへ。
最悪口を聞かなくても大丈夫です。むしろ全体通して口を開かなくても大丈夫。それが大きなカンファレンスのいいところ。

受付後には名前(アカウント名)や属性シールを貼って自分のネームプレートを作る場所が設けられていますが、人と交流する気がなければスルーでも大丈夫なようです。²
ただし、写真を撮られたくない人は最初にもらえる白いひもではなく赤い紐をもらって下さい。³
…でも赤い紐もらうのも自意識過剰っぽいですよね。

会場

大・中？・小？の3ホール。
過去と同じなんですが、大ホールを除き、大抵希望者より部屋のキャパシティが小さい印象です。
あなたが行きたい講演はみんなが聞きたい講演です。最悪一つ前の講演から参加するか、終了前ぐらいから部屋前で待機もありかと。
ただ、ブリーゼプラザよりは小ホールも大きめだっかかもしれないので立ち見でなんとかなるかも。⁴
2016年のLaravel と DIコンテナ、コンポーネントの設計は立ち見も諦めました。

なお、席は1テーブル3席で、普通に両端から埋まるので⁵、友人との参加の場合はより席取りは急いだほうがいいかと。
あるいは大ホール多めで。

基調講演以外に大ホールへは行かなかったのですが、
部屋別ハッシュタグではC7の方がC5より盛り上がっていたそうな。
参加した感じではスタッフさんの飴と鞭の違いもありそうな(無理やりなたとえ)。

真ん中の席に座ることは勇気が要りますが、PHPerは大層優しいので、しれっと座るか一言「ここいいですか」と聞いたらOK。がんばれ。

あ、最後のLTは例年銅鑼が鳴るので、耳が弱い人は後ろの席の方がいいかも。
今年は後方にもプロジェクターとは別にディスプレイが用意されていたので視力が弱くても大丈夫かも。

ブース

企業ブースや書籍販売などが集まるブース。
ここは何か講演を諦めるか、昼休憩を使わないと立ち寄れないので悩ましいところ。
結構企業ブースの人が話しかけてくる(くれる)ので、本当に人見知りな人は避けた方がいいかも。
今年はサムライズムさんの参加がなかった？ので、PhpStormの新機能の話とか聞けませんでした。使いたい…。
レバテックさんも来てて、PHPでも転職できるんだあ(超失礼)と思いました。転職に必要なスキルレベルとか聞いてみたかったんですが、時間がなかった。
なお、クイズに参加するとボールペンがもらえたので、カンファレンスのあてにしていたボールペン代わりになりました。(サポート期限落とした…)

参加した講演

前置きが長い

基調講演 PHPの現場から

基調講演は毎年(といっても2年ですけど)面白かったので期待大でした。

PHP の現場から // Speaker Deck
@shin1x1

PHP カンファレンス関西 2017 にて基調講演をしました - Shin x Blog

PHPを使った開発現場の実態、かと思いきや、PHPの現場Podcast からでした。
「PHPの現場」という Podcast をはじめます - Shin x Blog
上の記事は知っていたんですが、未視聴でした。

なので、現場の話というよりは、PHP(7)の言語としての特徴のお話。
実感としては、PHP7がもう普通に語られているのだなーと。
2年前の@hnwさんの基調講演を思い出しながら感慨にふけりました。
PHPカンファレンス関西2015でPHP7について発表してきました - hnwの日記

開発現場から見た PHP の特徴をあらためて見直すということで、

目覚ましい驚きなどはなかったのですが、2年前および去年の@hirakuさんの
PHPカンファレンス関西2016で基調講演してきました - Mercari Engineering Blog
はとても面白い一方、PHP初心者(あるいは未経験者)でも楽しめるPHPカンファレンスの、基調講演としては経験者向けだなと(逆算的に)思ったので、PHPを見つめ直すような基調講演もありだな、と思いました。

PHPは本当に(初心)人に優しい良い言語だと思ってます。他はあまり知らないんですけど！

ドキュメントが充実していて、
PHP: The Right Wayがあって、
後づけながらもオブジェクト指向に必要な物がそろっていて、
PHP7でぐんぐんよくなって、
RoRほど択一ではないけどwebページを簡単につくれるFWがいくつもあって、
Composerは便利なうえにpearにも対応してるっちゃしてるし、
普段無意識に理解してますけど、ステートレスって(良い悪いはわかりませんが)楽ちんで⁶、
オーバーフローはあってもメモリリークなんてあんまり考慮したことなくて、

そうそうPHPってこういう言語だったと思い出しました。

あと本当にPHPへのネット上での風当たりは感じるので、「胸を張れ」とまでは言わずとも「負けるな」とは個人的に思っていました。代弁された感でよろし。

インターフェースがLL言語では珍しいというのはへー。

あ、OPCashは5.5未満でも手動で入れられます！
PHPはその名称の経緯をたどると面白い！

PHPにおけるDSL

PHPカンファレンス関西2017 PHPにおけるDSL
松藤秀治

DSL=ドメイン固有言語

ある目的のための仕様を擬似言語や疑似コードで話すことが多いけど、それをそのまま動くようにしようぜ！的なものなのかなと漠然と。

実装はYAMLで条件や処理などをタグ付け・パース可能に。
内容は例ではクラス名.メソッド名()と結構普通。実装はちゃんとそのクラスにPHPが普通に持つ。
内容の評価はSymfonyのExpression Language Componentで。

条件評価がtrueなら処理内容を実行という単純な処理を、読み込んだYAMLのforeachで回す感じ？

何が嬉しいか。
条件と処理内容のルールセットがYAMLに抽出されているので、ルールの変更時にPHPの実装コードを変更する必要がない。

変更が必要な場合に、弄る箇所が少ない方が嬉しいとはよく言われるのでこれは飲み込めるところかと。

ハッシュと暗号は違うぞ！

ハッシュと暗号は違うぞ！ PHPカンファレンス関西2017 / Hash or Encryption // Speaker Deck
長谷川智希

口語ではハッシュ化も暗号化ってついついいっちゃうから気をつけようよ。(あとハッシュ値とハッシュ関数も大抵略してるよね)
っといったお話と、そもそも区別ついてるの？
からハッシュの簡単な解説。

パスワードのハッシュ値化のソルトは、ユーザーごとにそれぞれ持ったほうが良いのか、システム共通でもよいのか聞きそびれたけど、流れ的にはそれぞれっぽいかな。そりゃそのほうが良いですよね。(あとストレッチングもほんのちらっとでたけど説明もなかったかな？)

ハッシュ値の衝突を起こし、かつ悪意のあるデータを仕込んだファイルを配布なとか通信の改ざんをされるとハッシュ値だけでは検知が無理なのでつらみ…。

ログインパスワードのハッシュ値は衝突しても良い方のハッシュ値というのが意外だった。ユーザーが複数のパスワードを持っていることと同義(≒パスワードは唯一ユニークでなくてもよい？)ということは記事URLのIDの衝突と比べれば頷くことができるけれど、別物のパスワードでログインできちゃうことが許容範囲というのがそういうものなのかと思いました。

ハッシュ
暗号化
エンコード/デコード
難読化/minify

の使い分けは大事にしよう。特に顧客と話すときには。

オマケで
よくある例で連想配列はハッシュテーブルを使って計算量をO(1)にしている。
ハッシュ値が衝突した場合は、同じハッシュ値を持つものを線形探索で探す(O(N))。

GET・POST・Cookieなどはクライアント側ユーザーが好きな値を設定できる→PHPでは連想配列として処理する。
つまり…
ハッシュ値が衝突する値ばかりを設定したものを投げてやると…
hashdos!
面白かった。
PHPではパラメーター数の上限を設けて(1000)被害を抑える感じだそうです。
最近の PHP の hashdos を検証する - Qiita
PHP7の情報は軽く調べて出なかった。

(質問)なぜそんな危険性を抱えたままなのか？→リスクとベネフィットだと思われる。

ここらへんで時間切れ。残りは懇親会らしい。非参加者は公開スライドで落穂拾いしてもいいんじゃない？

明日から使える！「関心事」と「責務」のお話

「関心事」と「責務」のお話
 @shinichi-takahashi

まあ今年のQiitaにはカノジョできたエンジニア Advent Calendar 2017もできないもできないでしょうが。

「関心事」は「かんしんじ」が正しいそうで。

お話は難しかったので矮小化すると、層で考えて2つ以上先のことを考えるとダメ。関心事オーバー。
マイクロサービスで考えると、自分が直接触らないマイクロサービスのことまで考えない。
どめいんくどう？なら UI―アプリ―ドメイン―インフラの各層の隣意外を考慮しない。
レガシーに下手な例え休むに似たりで考えると、ウォーターフォールモデルの様に(線形じゃないけど)上が完了して下にいける。戻るのは常に一個上。みたいな関係性の単純化が大切なのかな。

関心事 is 機能や振る舞い・目的
責務 is (クラスが)なすべきこと

うーん、関心の分離 - Wikipediaと単一責任原則 | プログラマが知るべき97のことの範疇のお話なのかそれ以上のお話なのか、これらをしかと意識して実践できていない身としては雑念が漂っていました。
どうなんでしょ？

とにかく、関心事と責務を意識して、関心事の分離をして、責務を小さくしましょう(まとめ)

また、大切なことは、原則は原則として、どうしても関心事が増える場合、全体として、「このラインまでは許容できる」という線引を明確にすること。
これは設計思想を明確に、の話にもつながるのではと思いました。

続いて、MVCを例に挙げ、M(という言葉の)責務の多さの再発見についてと、Cの実装が人それぞれになりがちということ。
(だからどうするというところは落としたかな…
リクエストを処理するモデルをリクエスト層と命名した…だったような)

表題の明日から使える、として

設計思想を明確に。説明できるぐらいの言語化。できればドキュメント化まで
思想をもとにインターフェースのみで作成・思想の実証

インターフェースをガンガンつくったことがないので、それがどう設計思想の通用性を測ることになるのか気になります。
なーんとなくスピード感がすごく出て、楽しそうに思えました。やってみたい。

最後にバッドケースをコードで挙げて指摘。こういうのは助かりますね。

RDBの種類に依存
コントローラーにドメインロジックが入っている？
DIコンテナは最初期にすべて初期化(格納)され、ロジック中では読み込まれることが重要(責務)なので、途中で新規にDIコンテナにインスタンスを追加してはダメ⁷

難しかったですが、だいたいそんな感じに理解してみました。IF大事。

PHPでWebSocketを実装してみてわかったこと

PHPカンファレンス関西2017でしゃべってきました - 鈴木商店ブログ
下地功一

WebSocketについてはSocket.ioを触ったときになんとなく理解して、当時とてもわかり易い資料があった気がするも見つからず。

(個人的に)ws(s)プロトコルを使うけれど、そのためのハンドシェイクにはhttpを使う。
一度接続が確立すると、httpなどとは異なりつながりっぱなしになるので、リアルタイムチャットやinputのchangeイベントがトリガー(入力中表示)になっても、接続のオーバーヘッドが存在しないから軽快に動作するよ、と思っている。

といって既存のアプリに組み込むにはNode環境の構築などなどが必要なので、なんとかPHPでライブラリ追加程度で出来ないかなと思っていて参加。

細かいところで、WebSocket通信はブラウザの開発者ツールの、接続確立通信の「フレーム」タブに累積的にデータが溜まっていくのでそこで監視できるそう。
プログラム側にデバッグコード入れなくていい。

PHPで使うなら、Ratchet - PHP WebSocketsがある。
ただし、PHPは(基調講演でもあったように)ステートレスなので、
メインのプロセスの他に、ZeroMQなどのMQ(メッセージキュー - Wikipedia？)と、ブラウザと繋ぎっぱなしになるwsプロセスが必要そうな。
MQは先の講演にも出て、自分は初耳だったのですが、なんとなくふいんきでわかったふりをしていた。

(難しいことを抜きにして)Socket.ioが非常に抽象度が高く簡単に使いやすくできているように、Ratchet.meも同じぐらい抽象度が高く簡単に使えるよ。

でもしっかりすると大変なので、あんまりおすすめしないよ。

サーバー分散させたらどうするよ？→RoRならRedisを使ってよしなにしてくれる。→PHPでは…？

他にも接続切れたらどうするよ？

などなど、本当にWebSocketが必要か考えた方がいい。

WebSocketを(PHPで頑張って使うなら)リアルタイム通信などで。
サーバープッシュならFirebaseに乗っかるか、
(ショート)ポーリング・ロングポーリングで対応しよう。
(無理にWebSocketじゃなくていいんじゃない？)

個人の感想としては、ポーリングの仕組みやコードの準備があんまり好きじゃないのでWebSocketで簡単にできれば嬉しいよなーというスタンスだったので、
ポーリングの(効率的(と思っている)な)代案→WebSocket
が
WebSocketの代案→ポーリング
と言われてうーん、残念。
まあここは最近Hype Driven Development(新技術)に陥っているかなと自省できたので、ポーリングも決して悪くはないよと気取ってみます。

ポーリングで通知などサーバー側で貯めるの面倒だなと思っていたんですけど、そこらへんZMQとかができるんでしょうか？

PHPerさんに伝えたい最近のフロント事情と開発フロー今風のフロントエンド開発をする最短で最小限の装備

今風のフロントエンド開発をする最短で最小限の装備 // Speaker Deck
二神暢彦

タイトル詐欺枠。PHPでませんでした。

(Node.js)
yarn
Webpack (grunt, gulp全部のせみたいな)
babel
TypeScript⁸
axios
Vue.js

の紹介。

私がyarnをQiita上で観測してから浸透までがあっちゅうまで、もう最短かつ最小がnpmではなくyarnになっています。早い早い。⁹

個人的にはWebpack(babel)はwebpack.config.jsを書いてからの動作がさっぱりですね。全部まとめて1ファイルにしちゃうの？みたいな。

自分はaxiosはまだ使ったことなくて(当時はPromise形式がよくわからなかった)、jQueryとSuperAgent使っている間にFetch API,(これもPromiseですよね？)に移行しそうなんで、Fetchに触れたりFetchじゃ何がダメなのかがあればごくごく個人的に嬉しかったです。(共通設定・mockingあたりかな？)

フレームワークはGoogleTrendではVue.jsはまだまだ下火。

Vue.js VS React
- ReactはReact色強い。(RoRみたいな印象なのかな？)
- JSXよりVueのテンプレートが好き
- Redux量多い。双方向バインディングしたい。

両方ほんの少ししか触ったことないですけど完全同意だと思う。

Vue.js VS Angular
- ファイル多すぎ

そーなのかー(ノータッチ)

Vue.js環境の構築がcdn読み込みor vuex,vue-router含めた環境
だったので、もうこれら2つはあって当然な雰囲気なのでしょうか。

コンポーネントのデバッグしにくい問題はChromeならエクステンションあるよ。Vue.js devtools - Chrome ウェブストア

Webpackのサーバー使えばオートリロードもできて便利。(webpack-devserver)

(Webpackで)開発・デプロイ環境の切り替えは環境変数で。

(質問)TypeScriptの流れキテル？→Googleとかも使っている。使う人は使う。
TypeScriptを採用しない人の理由は？→型のメリットがわからないのでは？静的型付けは好きな人は好き。

私としてはJavaScriptは変数のゆるい型の扱いがPHPと似ていてとっつきやすいんじゃないかなーと思っているので、(PHP7で型付けが強化されつつあるけれども)PHPerにとってTypeScriptがどう見えるのか・魅力的に見えるのか気になったけれど、時間切れ。

感想としては、JSの流れは気になる点もありますけれど、「常識」や「今時」ではなく「今風」と銘打たれてたので、まあそうだよね。って落とし所みまみた。
あと自分がもう気分はPHPよりJSに軸足移していることを実感。
業務に使わないので流れが早いぶんには楽しいです。(陸目線)

触れられていたかは忘れましたが、Vue.jsはLaravelにデフォルトでバンドルされるようになりました。なったはず。(LTで触れたかな？)
結構最初からそろってた気がするので、Vue.jsキテルよ。流行れ！

LT

タイトルとかは適当です…
なお時間オーバーはたぶん1人だけでした。レギュ違反多いですね。

PHP to JS

PHPがあーだこーだで話題になったようなやつ…。
PHP って JavaScript に変換できるの？できるわけないだろ！ babel-preset-php ってのが今日リリースされた？これまさか・・・。ファーーーーーーーーーーーwwwwwwwwwwww - Qiita

EC-CUBE変換できるけど動かないよ。
作成動機が実用かジョークかは知りませんが、(ネット上の反応で)PHPが腐されてると受け取っちゃうと自分、疲れてるのかなと気になる。LTの感想ではない。

staticおじさんになろう

staticおじさんになろう公開版 #phpkansai / 黒點さん - ニコナレ
 @tadsan

リファクタリングしたいからメソッドの呼び出し箇所を全検出しよう
→grep? 同名メソッド・call_user_func・DIコンテナなどによる作成と呼び出しの分離などなどに対応できるか？

staticにすると解決？よーわからん。リファクタリングのためじゃなくて最初っからstaticで実装しとけば困らないという話。だよね？

マジックプロパティのPHPDoc打ちはしんどくて嫌です…

PHPStormならDIコンテナをmetadataで補完できるそうな？
PhpStorm Advanced Metadata - PhpStorm - Confluence
ちょっとよくわからないので解説待ち。
PHPDocって(IDEの補助がある)手作業だと思うんですけど、そこに不安はないのか。ちゃんと静的解析とかで自動付加・検出できる仕組みがすでにあるのかな。

さて…
どうしてstaticおじさんは発生するんだろう?

(疲れたので)ざっくり言うと設計が悪い。
最初から明るい未来へ行ける設計が大切。(明日から使える！「関心事」と「責務」のお話とも通ずるんじゃないですか)

それでも発生したら。
全てのstaticおじさんを、生まれる前に消し去ることは難しい。
じゃあそれはカオスの収束を目的とした、正しいリファクタリング(ができるようにするまでの)の過程と捉えると肯定できる。

リファクタリングの過程は多少歪になることがある。奇しくも外科施術が切り開き縫い合わせるように。的なことをレガシーコード改善ガイドで見かけた気がします。

まあLTでは設計大事しかわかってませんでした。

テスト高速化

(スライド未発見)
77web

札束で殴れないときにどうするかby PHPUnit

重複アサーションの除去。
配列のアサーションは要素ごとではなく、配列全体を一度でチェックしよう。
setUP,tearDownでプロパティを開放して軽くしよう。
～をstaticメソッド化しよう。(逃した)

結果！！！…そんなに速くならなかった。

FWを使っていても確認しておきたいセキュリティポイント

@cake_php (たぶんtwitter)

VAddy使おう。

evalこそパワー

PHPの高速オシャレ危険配列ライブラリspindle/collectionを作っている話 - Qiita
@hiraku

関係ないですけど

温かみのある手書きfor文

が好きなセンテンス。
なんだかevalとかgotoと聞くと使わない決意をしているせいか耳に残らない…

WebAPIを理解しよう

ウェブリオ大島

いらすとやで笑いをとれる時代は過ぎ去った…

WebAPIの用途

API前提の設計
アプリ
第三者へのAPI提供
REST API
- (好き勝手作れる)規約のうちの一つ

[メソッド|操作種別]　(URL:https://～)エンドポイント/操作対象(リソース)

メソッド
- GET 取得
- POST 新規作成
- PUT 更新
- DEL 削除

GET/POST以外はREST APIぐらいでしか大抵聞かない。
PUT = 更新って忘れがち。

捜査対象は目的語の複数形。
(主語は操作する人になるので)

ステータスコードも真面目に
200番代→成功　200:OK 201:created 細かい！
400番代→クライアントに問題の失敗
500番代→サーバーに問題の失敗

総じて真面目な規約です。
うーん、真面目すぎて卑近ではバズワード化しているのかな。提供側に回るとしんどそう…って最近GraphQLのときも同じこと思ってる。

閉会

今年は写真撮影がありませんでした。
あっさりとした終わり。

感想

出た講演にもよりますけど、今年はPHP色が強かった気がする。
気を抜くと関数型プログラミングやJSテスト、CSS管理の方ばかり行っていたので…。

やっぱり参加するならば、PHP7とLaravelは触っておくとより楽しめたり選択肢が広がるんだろうなと思いました。

今年の感想ではないですけど、自分の環境で使わないとわかっていても、やっぱりこうやって参加してみて周囲の普通だとか温度感を味わっておかないと焦りが生まれませんし、一年の内にその熱も冷めちゃったりするんで、全然わからん！でもいいので近場なら出てみるのがいい思います。参加費1000円ってお安いですし。

あと口を開かなくても大丈夫と最初に書きましたが、登壇者orスタッフによってはリアクションしてください！とか盛り上がっていこーぜ！とかありますが、(LT)以外はみんな良いか悪いかおとなしいので、あんまりよくは無いですけど、ノらなくても悪目立ちはしないです。
大阪はおとなしいですねって過去何回か聞いたセリフな気がします。

今年は懇親会で聞いて・懇親会が本番的発言が少なかったです。
観測範囲で3回。うち2回はスタッフだったので。セーフ。
一般参加のみには悲Cお言葉なので。
スライド消化しきってわからないことは懇親会で聞いて下さいとかは気にならないんですけどね。

以上。来年もあればいいな。
ぼっちも行こうぜ。

その他参考

~~ # 未整理メモ　~~

手書きメモのテキスト化
本文で疲れた

なお今年はラブライブ！サンシャイン!!のよしこのようでした。…多分。

自分がこういうの欲しかった。 ↩
書いてスルーされるのも記事ひどいよとか言われるのもこわひ(被害妄想) ↩
赤い紐なくても一部では撮られたくない人は手を上げて下さいと言われますが、補助的なものだと思います。 ↩
座ってから振り返れなかった。 ↩
大学時代を思い出します。 ↩
HTTPと相性が良い(両方ステートレス)と言うのも言われてなるほど ↩
これ考えたことなかったです。 ↩
babelとor紹介だったのでbabel不要なのかな？古いブラウザ対応=トランスパイル機能付き？ ↩
ずっと一人で言ってるだけです。 ↩

PHPカンファレンス関西2017行ってきたよ