uzullaがブログ

uzullaがブログです。

デブサミ2019で登壇してきました!!

f:id:uzulla:20190220195418p:plain

event.shoeisha.jp

「あの」、Developers summit 2019で登壇してきました!

発表資料はこちらです。

speakerdeck.com

きっかけとしては「城でカンファレンスやりましたよね?今年のデブサミは「SHARE YOUR FUN!」なのでいい感じに発表しませんか?」ということで近藤さんから登壇をさそっていただき、デブサミ初登壇ができました!ありがとうございます!

変わったトークなので?客入りはそこそこでしたが、質問に来てくれた方は片手では足りず。

なかなか皆さん興味をもって聞いていただけたのかなと思います。ありがとうございました!

f:id:uzulla:20190220195851p:plain

実は初デブサミ

デブ(デブではなくて、デブ的な意味で)なのに一度も参加したことがなかった。

感想としては規模がでかいな!という感じですね、そしてスタッフがなんかプロっぽい(実際ホテルの人がサーブとかしているしな)。

様々なカンファレンスに(といっても偏ってる気もするが)参加していますが、商業のカンファレンスにはあんまりいかないのでやはり新鮮に感じますね。

f:id:uzulla:20190220195704p:plain
(控室もシャンデリアバーンですごい)

色々勝手がわからず、同じ枠に登壇した小西さんに色々サポートしていただきました、本当にありがとうございました。

フィリピンから直行だったので

PHPという通貨をさわりたい!」という理由で(?)前日までフィリピンにいました。

1000PHPを崩すのにめちゃめちゃ苦労した渡航が終わり、登壇日の朝4時に羽田に帰国というエクストリーム登壇だったのもあり、他のトークはあんまり聞けなかったのが心残りです。

今度はちゃんと聴講できるスケジュールで参加したいですね。

f:id:uzulla:20190220200042p:plain
(アカツキさんのスペースで開催された非公式懇親会での15秒トークで「今日はフィリピンからきました」という嘘ではない小ネタをいれたら「フィリピンの人なんですか?」といわれてしまって(まあ当然ですね)すいません!となった)

しかし、いつか私がデブサミに登壇することがあればPHPの話をするのだろう…とPHPerとして考えていましたが、まさかこんな形で登壇することになるとはね。まあ自分が楽しいとおもってやっている趣味が評価されるというのはとても嬉しいものです、光栄でした!

こちらからは以上です!ありがとうございました!

f:id:uzulla:20190220195540p:plain
(ビズリーチさんのPHP水の様子です、うれしいですね!)

PHPerKaigi 2019にトーク応募しました!!

phperkaigi.jp

PHPerKaigi、トーク募集が21日の月曜正午までです!(挨拶)

追記: スポンサーもまだ募集中だとのことです (1/31(木)まで)

ということで遅くなりましたが、トークを何本かつっこみました!!

どれもこれも、皆さんの仕事にいますぐ役立つかといわれれば、まあそうでもないな…といういつもの私らしいトークになります。

果たして、どれかは通るだろうか、通ったらがんばります!

皆さんも月曜昼までにトークを応募しよう!!

チケット販売も開始しています、要チェックです、要チェックというか速やかに買おう!!後でっていうと忘れるよ!!

以下は応募(予定)のトーク概要です。どれか通るといいけど、本当に通るか、通ったとしてどれが通るかは不明です、聞きたいものがあれば、ブクマとかコメントとか選択してスターとかで教えてください。

「帰ってきた!平成最後のオレオレフレーワークの作り方」

fortee.jp

フレームワークと聞いて、皆さんは何を思い浮かべますか?Laravel?Symfony?Zend?Slim? 今はいろいろなフレームワークがありますね!

ただ、そうしたフレームワークは古代存在しませんでした(諸説ある)。よって昭和の人間はもれなく皆自分でフレームワークを書いていたと言い伝えられています。

とはいえ、前述の通り平成の今は素晴らしいフレームワークが十分に普及していますよね。平成も終わる今、本トークタイトルのようにオレオレフレームワークを書く意味があるのだろうか。その疑問はたしかに一理あります。むしろ書くなとも言われています。それはタブーだと。

ところで、フレームワークとは枠組みです、枠組みは内面を支えるものです。つまりフレームワークを書く事で自分の内面を知ることに繋がります(?)。そう、自分を知るためにもFWを書くべきです(??)。

※ いきなりスピリチュアルっぽいですが、深読みは不要です!

あと数ヶ月で平成が終わります、平成の終わりにオレオレフレームワークをつくり、自分を知りましょう!

自分を知り、そして…!

(勢いで)以下のようなアジェンダを予定しておりますが、予定です。

  • 空のファイルから全部書いたことがない人へ
  • フレームワークとはスタイル・ベストプラクティスである
  • 最大公約数とパラダイム、時代の移り変わり
  • オレオレフレームワーカーの「はしか」
  • 模倣にはじまり、オリジナルを見出し、そして「大人」になっていく
  • まとめ

北海道のトークを進化させたものですが、時間が短いので切り口は変わります。

PHPApache+mod_phpで十分(?)」

PHPはApache+mod_phpで十分(?) by うずら | トーク | PHPerKaigi 2019 #phperkaigi - fortee.jp

みなさんPHPでサービス提供していますか?何をつかって提供していますか?

Nginx+php-fpm?h2o+php-cgiIIS+php-fpm?swoole?builtin server?HHVM?Roadrunner?PHP-pm?いやいや、Apache+mod_phpですよね?あるいは諸般の事情でapache+php-cgiかもしれない。

Apache+mod_phpはいろんな人が「いまどきApacheとかないわ〜」とか「もうそもそも考えてもいなかった」とか言っています。でもどう考えてもapache+mod_phpで8割のケースは十分ですよね???

(勿論、皆さんが2割のケースにいらっしゃるかもしれない、それを否定するわけではありません。勿論そうなら泣く泣く(???)Apacheを使わないのは正しいのでしょう)

これらを比較して、mod_phpを見直しましょう!

「ちょっとまって!そのベンチ直線番長じゃないですか?」

fortee.jp

PHPがまた早くなった!そういう話結構多いですよね。僕もぐんぐんと伸びるグラフやベンチを貼って「PHPははやくなった!他の言語に負けていない!」とか言ってみる事もしばしば(?)あります。

でも、そうなのかな?本当にPHPって速いのかな?本当に十分に速ければ、皆がg○とかに民族移動しなくてもよいのでは…?(諸説あります)

いやいやでも結構PHPも速い(ような気がする)し…。

ということでPHPでよく見る「ベンチの欺瞞」あるいは「現実との乖離」、「先入観」について書いてみます。

「私が気になる最近の謎PHPライブラリ一挙紹介100連発!」

fortee.jp

私には「Packagist監視おじさん」として活動する顔があります(自称です)。@call_user_funcというTwitter botで、Packagistに投稿されるパッケージを日々監視しています。

Packagistに日々大量に登録されるライブラリですが、私が最近気になっているパッケージをたくさん紹介いたします!

※ 100連発とかいてありますが、これは「たくさん」という意味であり、本当に100連発になるか未定です、っていうか多分ならない。

聞いたこともない、みたこともない、日本では知られていない、本当に流行っているとは思っていなかった様々なパッケージに付いてご紹介いたします。

httpdと(mod_php|php-fpm|php-cgi)のカンケイの話」

fortee.jp

PHPにはhttpdがない(諸説あります)

そうすると様々な方法で、Httpd(ApacheやNginx)と付き合っていく必要がありますね、

そのあたりの設定についてコピペで済ませる人が多いですが、それってどうなのっておもいませんか?(えっ、おもわない?)

実は「よく知られている(検索で出てくる)設定はセキュリティ的にまずい」、「あるフレームワークだとなんか動かない」とか、しばしば見かける話だったりします。

様々な設定項目を確認して、それぞれの意味を見直してみませんか?

秘伝のconfからの脱出を図りましょう!

AWS lambda の(準公式)PHPサポートが好きになれない!」

fortee.jp

先日、AWSのLambdaでPHPがサポートされました!

しかし…ネイティブサポートというわけではなかったですね(残念)まあ、色々な都合はわかる所です、PHPのバージョンが固定されないという意味ではよいですよね!

※ 別に5.4に長いことロックされていた某サービスに文句をいっているわけではない

それはそうとして、発表直後こそ大喜びした私ですが、公開されたコードを読んで少々うーん?と思う所もありました。

「これはたしかにPHPだ、PHP-ismになるようにしてある。でも、こうしなくてもよいのでは…?」

他の言語バインディングなどを確認し、PHPならではの設計となっていることに疑問を覚えた私。「こういうふうにしたほうが良いのでは?」というお話をいたします。*1

また、普通のウェブアプリを普段書いている方向けに、これがどういった構造なのか(使い方ではない)、「一見微妙に見えるこの実装」がなぜ良いのか(勝手なエスパーで)、などをお話してみたいと思います。

注意: このトーク自体がLambdaを使う上で直接的に役立つかというと、多分役立ちません!

以上

以上です!

いつも「みんな早くCFPだして!」って急かす側なのに、今回は応募がおそくなってすみませんでした…。

(普段1〜2本しかださないが、今年は頑張ってたくさん提案してみたから、というのもある)

ちなみにトークが通ろうが通らまいが、PHPerKaigiには参加します!みなさんぜひPHPerKaigi会場でお会いしましょう!

phperkaigi.jp

チケット販売開始してるし、トーク応募は月曜日の12時(正午)までだよ!!

追記: スポンサーもまだ募集中だとのことです (1/31(木)まで)

*1:自作が完成したら、それの話をします

フロントエンドのクラウドロガー・レコーダー、LogRocketの感想

先日「JSが『なんか』うまくうごかない」というクレームが来て調査しており、開発者ツールをみればわかることでも手元のPCで再現せず、その人のPCをみないとわからんな〜〜ということがありました。

こういうのむずかしいですよね、エラーがあらゆる所でランダムに発生する(と主張されている)場合には問題が発生しているユーザーにデベロッパーツールを開きっぱなしにしてもらうのか?という問題もあります。

…と言う気分でTwitterになにか無いかとボヤいたら、JSのプロのmizchiさんにレスをもらいました。

ということで速やかにLogRocket、使ってみました。結果としてはとても役立ちましたね。

logrocket.com

"Stop guessing why bugs happen"というワードが実に良い。

結論からいって、解決に役立ちました。十分な情報が得られます。だれが、どの画面で、いつ、どういうエラーがでていたのかが一目瞭然でした。そして、一部環境以外ではエラーがでていないことも確認できました。最高。

LogRocketとは

  • JSのエラーが発生していないか
  • あるユーザのブラウザにどのように表示されていたか(動画のように表示される)
  • 勿論エラー発生前後の画面の様子も見れる
  • どういったHTTPリクエストがあったのか(所謂Networkパネル、ヘッダーも見れる)
  • ユーザーはどういったブラウザ・OS環境なのか

さらっとかきましたが、これ本当にすごいです。最高では。

JSのエラー確認

まず、何が良いってエラーをまとめてもらえることです。すでにこのサービスのJSエラーはあらかた潰してあったので「エラーが多くてみつからない!」という事はなかったのですが、そういうこともあるでしょう。また、発生頻度が集計済みなのも便利です。

f:id:uzulla:20181205145417p:plain

さらに、このエラーはLogRocketの中で「チケット」的な扱いになっていて、解決!とすると、同じエラーをまとめて非表示に出来ます。対応してないエラーに集中できてよいですね。 (なお、放置すると設定期間で自動的に処分され、空気読んどるな?という感じはありますねw)

詳細を開くと具体的なエラーログなどが確認出来ます。開発者ツールのConsoleくらいの情報量はあるので十分です。

f:id:uzulla:20181205145452p:plain

f:id:uzulla:20181205145436p:plain

(一応、エラーの行情報からソースコードを表示してくれるのですが、無名関数だとおかしい場所が指し示されてしまうなどはあります。(こういうのが多いと、無駄でも無名関数はへらさんといかんなあという気分にもなる))

f:id:uzulla:20181205145724p:plain

やはりユーザーの画面で「どのような時に」エラーになったかを再生することができるのがよいですね。どこをクリックしたとか、どういう遷移できたとか、そういうのが相手の苦痛なくヒアリング無しでわかるので大変に!!助かります。公開できる情報じゃないんで皆さんにみせられないのが残念なんですが、本当にすごいので皆さんためしてみてほしい。

操作している画面がそのまま見れる

そんなことが実現可能なのかとおもっていましたけど、本当にできていましたね、どういう理屈なんだ。Videoみたいなもの以外はアニメーションもちゃんとレンダリングされているようです(Gifアニメ、JSによるフェードアウトなど)、スマホももちろん対応です。

まあ〜〜非常にわかりやすい…クレーム対応でなくてとも、何人もみていると「ああ、ここで迷うんだな」ということがよく分かる。ロードが遅くてマウスをくるくるまわすのもわかる。

(ただ、私の(ここでの)立場はあくまでも実装エンジニアで、仕様策定者に「こうなっているらしいですよ」「へー、きょうみないや」みたいな感じなので活用できていないのだが…)

f:id:uzulla:20181205151107p:plain

このレコード機能はどうやって実装してるんだ?思いましたが、録画とかではないです。プレイヤーのiframeの中に元のサイトが改変ミラーされていて…みたいな感じになっていて、なるほど…?となれます、すごい…。

Liveも見れる

なお、レコーダーの再生は「リアルタイム」にも対応しています。YoutubeのLive再生みたいな感じで録画再生が終わったらLiveに移行できます。

これもユーザーサポートでは非常に便利ですね。後述のユーザーIDとのひもづけをしておけば探すことも簡単ですし、相手に指示もだせるとおもいます(そこまでやったことはないので、実用的かは不明)

一覧で「現在LIVE中」かわかると助かるな(まあ、小さいサイトでしか実用的ではなかろうが)、1 min ago とかの表示でもいいんだけど。

セッションについて

記録の単位は「セッション」になります、ブラウザの一時 Cookieみたいな感じです。課金単位はこのセッション数です。

重要なのは、SPAでない普通のページ遷移を伴う場合も1セッションとして扱われることでしょうか。いわずもがなこれは非常に重要ですし、よくできてるな〜〜ポイントですよね。

なお、「便利だから!」てサイト全部に影響する所でトラックJSを埋め込むと、1セッションが長すぎて確認のための早送りが大変になります(まあ、サービスによるでしょうが)。なので、ある程度タグを埋め込む箇所は調整したほうが良いと私は思います。

セッション検索は結構豊富なメタデータで検索出来ます。

f:id:uzulla:20181205151224p:plain

これを組み込むことでクレームがくるか?

これ結構心配していましたが(なにかが破滅したり、やばいくらい遅くなるとか)今の所そういった問題はなさそうです(もちろん帯域は無駄に消費しちゃっているのでしょうが)。

まあ、今回はユーザー数が多くないBなサービスなので、サンプル数が足りないかもしれませんけど。

正直サービスが(検閲削除)向けなものなので、ロード速度の悪化具合とかまではちゃんとチェックはしていないです。

どれくらいインストールに手間か?

サインアップはすぐにできて、あとはタグをサイトに貼り付ければ記録出来ます。

さらに、タグにメタデータを追加できるので、UserIDを紐付けることでWeb UIから該当のユーザーを調べることが可能になります。エラーが発生しているユーザーアカウントをCS経由で問い合わせなくて良くなるので最高!!!

最終的には、タグは以下みたいな感じになりました。

<script src="https://cdn.logrocket.io/LogRocket.min.js" crossorigin="anonymous"></script>
<script>
if(window.LogRocket){
  window.LogRocket.init('********');
  if( USER_ID !== 0){
    LogRocket.identify(USER_ID);
  }
}
</script>

調べながらやったんですが、まあ30分〜1時間あれば使い始められますね。

プライバシー(?)等について

画面をログするので、プライバシーみたいなものが気になると思います。正直ここまでログできると、正当な業務であっても難色を示す人はいそうです。(「保存ボタンを押す前の下書き」まで見えるわけですからね)

一応、HTMLのクラスなどに特殊な指定をすることで、録画しないように出来ます。(つまり、かんがえられてはいるということです)

それ以前(?)に、一般向けへのサービスだとプライバシーポリシーやGDPR周りで苦労がありそうですが、まあ、このあたりは色々考えていくしかないかな〜という感じですね。

docs.logrocket.com やっていってはいるようだが、自分のところでユーザーにどうやるか、という話は別問題。

まあ便利なロガーはこのあたりの問題をどうやっても抱えるので、各自(法務と一緒に)なんとかしていきましょう。

まとめ

エラーが発生「した」ことがわかるツールは現状把握には重要だと思いますが、そのエラーを再現させるための情報収集で大量のprintデバッグが必要になりがち。

そのあたり、LogRocketだとどういう操作をしたか(XHRでどういうリクエストを飛ばそうとしたか含む)などがわかるので実に簡便。

LogRocket非常に良いですね。

追伸

アクセス数の多いサイトや、何でもかんでもログする!だとめちゃめちゃ高くなるかも。

https://logrocket.com/pricing/

※ プライス表は、ログインした後にもう少し細かいものがあります。

サーバー側で「このユーザーIDや、環境や、(サービスの保守)契約プランならJSを読み込ませる」とかしないと無理そう。(そうすれば、大抵1万セッションくらいには収まるのでは…?)

例えばですけど、「IEだけタグを出すようにする」と、もはやシェアが減りつつあるIEのJSの互換性チェックできますね…便利!!

ただ、エラーはすべてを確保しておくのが迅速な解決につながるし、状況に応じてかな〜。NewRelicみたいにオープン初期は金を積む!とかもよいかもしれないですね。

あるいは、JSエラーの検知だけは別の安価なツールで検知して、必要に応じてこいつを差し込めるように…、くらいがよいのかもわからん。(CDNはいってるとちょっと面倒かな…)

あ、セッション数が溢れた後の挙動はまだわかってないです、使い切っていない(後で追記するかも)

簡単でしたが、こちらからは以上です。