uzullaがブログ

uzullaがブログです。

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 - 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はいってるとちょっと面倒かな…)

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

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

PDのためにUSB-Cに転向を試みたメモ

HDMIポートがついているMacbookProが最高と考えているuzullaです、こんにちは。

もちろんUSB Type-Cもドングルが必要なので嫌だったのですが、実際にはすでに私はMacbook12(Type-Cしかコネクタがないやつ)を持っており、そろそろType-Cに移行するのもよいのではないか?と思い、表題の通りですが転向を試みました。

目的

  • Macbookを中心として、遠出の際の荷物を軽くしたい。
  • iPhoneXの充電速度を上げたい
  • どうやら近いウチに不可避となるType-Cに慣れておきたい

iPhone Xの充電

充電速度については、純正Type-C<>Lightningケーブルを使うと高速に充電できるのがポイントですね。80%以下だと実際高速。

残量が80%以上ある状態だと、ワットチェッカーでチェックしても5V以上あがらなくて、最初不良品を疑いました。(が、仕様でした)

PD充電できるケーブルは現在純正しかないらしいので純正をつかっていますが(出来るような雰囲気を醸し出しているType-C<>Lightning社外ケーブルは結構あるが、すべてPD非対応っぽい)、正直長い。早く15cmくらいのケーブルが出てきてほしいですね。

PD対応モバイルバッテリー

個人的にはでかいバッテリーは使い切れないし、5000mAhで十分だと思っています。しかしPD対応の有名所のバッテリーは20000mAhとかばかりで良い選択肢がない。Amazonをさまよい、今回は以下を買ってみました。

ロゴはダサいですが質感は良い感じ。実際にちゃんと5Vを超える電圧出力がなされていることも確認しました。

この「10000mAh」が有名メーカー並か?という所については少々疑問はありますが、iPhone 1回はちゃんと充電できるかなーという感じですね。 PD対応なので、このバッテリーへの充電の速度も高速で気に入りました。

また、MacBookSurface Goにも充電することができました(起動しながらの充電だと少々ゆっくり(使いながらだと30分で〜10%くらい?サスペンドしていれば2〜3倍の速度、12Vの1.1Aで13Wくらい。もちろんフルチャージはできない(感覚的に30〜50%分くらいかな…)が)。

余談ですが、このバッテリーはポートがたくさんついてます。microUSBから充電したり、USB A出力の口が2コついてたりするのもポイント高い、何気にQCにも対応してますし、スペック厨にはうれしい。

欠点としては、Type Cのコネクタがちょっとゆるい気がします。外で気づかないウチにケーブルが抜けている事が何度もありました。まあ、しゃーないかなとおもいますが、これ以外はほとんど不満がないので残念です。(個体差かなー、もう一個買ってみるかなー)

小型ACアダプタ

こうなると、当然小さいPDのACアダプタが欲しくなります。Cheeroの18W1ポートにしようかと思ったのですが、出先だとUSB Aが一個あると非常に重宝しますよね(変換も持ち歩きたくないし!)、ということで以下のものを購入。

Type Cケーブルも付属しているし、Macbookにもちゃんと(18Wなりですが)充電できました。

欠点としては、USB Type Aを接続すると、Type-CのPD給電はできない事ですね(両方5Vに落ちる)。寝る前にiPhoneともう一個USB機器を充電する用途なら全然問題ないのですが、Macbookにつなぐなら他のUSB機器は繋げない(つないでも充電されない)のはちょっと残念。

今は軽さが重要なのでためす気にはなっていないのですが、Anker のやつとか、以下のやつがよさそう。(スペック上は、同時接続でもPDがおちないように見える)

Macbook

(今回の本筋とは関係ないんですが)MBPは昔より軽くなったとはいえ、Macbook12との重量差は400gはあります。さらにACアダプタも100gくらいはMacbookの方が軽かったりします。この間の旅行ではMBPをあきらめてmacbookだけで移動したんですけど、本当に軽くて最高です。

さて、しかしながらMacbookはType-Cのコネクタ一個しかついておらず、そこにACアダプタと(たとえば)SDカードリーダーが同時に繋げない。なので、充電しながら外部機器をつなぐのにドングルが必要ですね。

www.apple.com

で、このドングルはシンプルなものですが、もうちょっと多機能な奴があります。以下みたいなUSBの口が3つついてたり、SDカードリーダーがついてたりして便利です。

で、最初この社外ドングルと社外の18WのACアダプタとLightningケーブル(Type-A…Type−Cがささるドングルがない!なんでや!)を持って外で作業してたんですど、Macbookの電池が減るんですよ。

なんだなんだとワットチェッカーを差し込んでいろいろ見てみたら、こういったハブはあんまり電気が通らないんですね…。

※ 2018/12/22 Ravpower と Cheero のPD対応電源を買ったので、それも記載

ACアダプタ ドングル V A W
Omars 18W 直つなぎ 14.4 1.1 15.84
Omars 18W 社外ドングル 14.3 0.44 6.292
Omars 18W 純正ドングル 14.4 0.65 9.36
Cheero 18W 直つなぎ 11.7 1.37 16.03
Cheero 18W 純正ドングル 11.8 0.74 11.8
純正AC 直つなぎ 14.2 1.88 26.696
純正AC 社外ドングル 14.3 1.18 16.874
純正AC 純正ドングル 14.3 1.39 19.877
RavPower RP-PC104 45W 直つなぎ 19.1 1.37 26.167
RavPower RP-PC104 45W 純正ドングル 19.0 1.24 23.56

見ての通りなんですが、18W+直つなぎで(少々低いがw)15W流れるのに、社外ドングル通すと6Wしかながれないんですよ。Vがちゃんと14Vでているので、PD非対応ということもない。

で、純正ドングルだと「もうちょっと」流れる。まあこれも直つなぎよりだいぶ低いな〜って思いますが。

ただ、純正ACはやっぱり強いんですよね。ドングルつけても16W流れる。ふーむ。(逆にこれってどういう相性問題なの?という気もしますけど)

さらにいえば、純正ACを上回るのがRavPower RP-PC104 45Wで、こいつは直つなぎだと同等のワットだが、ドングルを指しても23WがMBにながれる、強い。やはり純正の30Wはもう一息ほしい感じだったのがよくわかります。

なので

  • ドングルを使うなら、この社外18W ACアダプタは微妙
  • 純正の30W ACアダプタはドングルをつなぐとドロップがある。高出力を検討しても良い
  • いずれにせよドングルは充電速度を押し下げる
  • 見てもさっぱりわからんので、ワットチェッカーは重要

という感じですね、

なお、この時純正AC+純正ドングル構成で、ドングルにiPhoneをぶら下げてみると、AC<>ドングル間が 14.3v * 1.7A = 24.8Wに増加してACアダプタの性能を使おうとします。

その時ドングル<>iPhone間は4.85V*0.9A= 4.3Wが計測され、Mac側へ回される電力は(計算上は)かわらず19Wで、1AくらいはiPhoneに流れます。これはまあぼちぼち悪くない気がします、充電もゆっくりですがなされます。

これが社外ドングルだと AC<>ドングル間が14.3v*1.36A = 19.448Wどまりで、 iPhoneには5v*0.47A=2.35W しかながれませんでした。 計算上Macには16Wくらいしか流れない感じです。iPhoneもこの電力だと充電できるか怪しいです。

(もちろんですが、これが社外+社外だと、合計でも10W以下しか流れないので、すごい勢いでMaciPhoneも電気がなくなります)

ということで、

  • 社外のドングルは微妙!(ちょっと古い製品なので、最近のは違うのかな〜?)

という感じですね。

私はできるだけUSBテザリングするので(モバイルホットスポットを避ける習性があるw)、最低でも純正のドングルを持ち運びたいと思います!

まとめ

USB Type-C、PDはちゃんとした組み合わせでないと性能が出ないですね、特にドングルやHUBみたいなものは脈絡なく半分くらいしか流れないとかあるようなので、電力を測ってみないと安心して使えそうにないです。難しい!

すでにType-Cの世界で長く生きていらっしゃる方々のほうが詳しいかなとおもうので、もし良い(軽くて、充電速度が早い)構成をご存知ならぜひ教えてください。

ACチャージャー側にドングルが内蔵されているみたいな製品でてこないかなー。こちらからは以上です。