ざっくりPHPカンファレンスメモ
PHPカンファレンスに参加してきた。 ざっくりしたメモ。
OPCacheの最適化器の最適化
OPCacheの機能
バイトコードの最適化のお話
定数の最適化の挙動がすごいなーと。
もうコンパイラじゃん!ってなった
Lancersバージョンアップ
お姉さんが動いた!という喜びのコミット
目をつぶっていたNOTICEエラーを消して行った
別ブランチを作成してバージョンアップを行なって行った。
masterブランチの更新も走っていたので差分を取り込むのが大変であると。
Upgrads Shellだけでは動かなかった
自動で新しいメソッド、関数に変換するシェルを作成した(App::importをApp::usesに変換とか)
CakePHP1.3でできることを先にしておく
paramをdataにするとか
CircleCIでチェックし変更をする
CakePHP1.3と2.8を同居させることに成功した
Codeceptionで動作を担保する
phpのバージョンアップ -> カナリアテスト
CakePHPおんバージョンアップ -> 2バージョンを用意して書き換えて行く、UnitTestも2バージョン用意、Codeceptionがあるから安心
Realtime Messaging with Firebase
2ヶ月でのリリース
なるべく作らない方針
microserviceとして切り出さない
クラウドサービスを使い倒す
スコープを削りきる
Firebase
Googleの提供するBaaS
モバイルに非常に特化して多機能
Firebase Realtime Database
Firebaseの機能の一つ
サンプル
{ "messages" : { "1": { "text": "hello, firebase", "user": "sota1235" } }
認証機能を追加したりできる
Rule
ノードに対して数字のみとか書き込み禁止とかできる
rulesには.writeにfalse、その中のroomsには.writeと.readにtrueでroomsだけに制限することができる
Ruleの適用
GUI or REST APIで設定
ハマりどころがあるらしくREST APIがおすすめ
スキーマ設計
Subscribe側を意識する
非正規化した方がいい場面もある
後方互換性を意識
配列がない
addすると自動でキーが振られて配列みたいに作成される
放送後はデータを読み込ませない
特定のライブIDが放送中かどうかのフラグを管理し、読み込みを許可する
root.child('alive_lives').child($live_id).val === trueとすることで他のノードの値を引っこ抜いて書きこみ、読み込みを制御できる
admin権限でルールを無視して放送中フラグを変更する
Write戦略
スマホからFirebaseへの書き込みは行わせない(APIを通す)
攻撃、認可など工数を考えたため
APIからEnqueue Job(Q4M)、Worker Process(PHP)がDequeue Job、Firebaseに投げる
FirebaseをSPOFににしない
野良SDKでkreait/firebase-phpをおすすめ
Read戦略
クライアントは受け取ったデータを表示するだけ(バリデーションはかけない)
スケーリング
Realtime Databaseはスケールアップできない
常用インスタンスと高負荷用インスタンスを分ける
料金は従量課金
何台インスタンスを立てていても通信しなければタダ
Firebase ProjectsとGCP Projectは1対1
Cloud Firestoreで変わった点
自動スケールアウトするようになった
SDKのI/Fがよくなった(Where的なことができるようになった)
RDよりLatencyが伸びる可能性がある
VS
新規プロダクトは基本Cloud Firestoreでよい
ReadWriteオペレーションが大量に発生する場合はCloud Firestoreの方がお金がかかる
何がよかったか
ユーザー体験
シンプルなアーキテクチャ
待機開発リリースを実現
運用、追加開発しづらいPHPアプリケーションに未来を与える方法
しやすい
やりやすいとは
- テストコードがある
- アプリケーションモニタリングがある
- デプロイが容易(CIサーバー・1コマンド)
モニタリングを追加
New Relicで見える化 各コントローラー、エンドポイントのレスポンスの記録を確認できる
新規機能追加
既存のアプリケーションを触らず、別のアプリケーションを立てて修正して行く Slim 3.xとALBを使用して追加していく
セッション
session管理はデータベースに書き込むようにした
PHPカンファレンス 2017に参加してきた
参加してきました。
その時の雑な自分用メモを公開します。
OPCacheの最適化器の最適化
OPCacheの機能
バイトコードの最適化
Lancersバージョンアップ
お姉さんが動いた!
目をつぶっていたNOTICEエラーを消して行った
別ブランチを作成してバージョンアップを行なって行った
masterブランチの更新も走っていたので差分を取り込むのが大変
オレオレUpgrads Shellを作成
自動で新しいメソッド、関数に変換するシェルを作成した
CakePHP1.3でできることをする
paramをdataにするとか
CircleCIでチェックし変更をする
CakePHP1.3と2.8を同居させることに成功した
Codeceptionで動作を担保する
phpのバージョンアップ -> カナリアテスト
CakePHPのバージョンアップ -> 2バージョンを用意して書き換えて行く、UnitTestも2バージョン用意、Codeceptionがあるから安心
Realtime Database Messaging with Firebase
2ヶ月でのリリース
なるべく作らない方針
microserviceとして切り出さない
クラウドサービスを使い倒す
スコープを削りきる
Firebase
Googleの提供するBaaS モバイルに非常に特化して多機能
Firebase Realtime Database
Firebaseの機能の一つ
{ "messages" : { "1": { "text": "hello, firebase", "user": "sota1235" }, }, }
認証機能を追加したりできる
Rule
ノードに対して数字のみとか書き込み禁止とかできる
rulesには.writeにfalse、その中のroomsには.writeと.readにtrueでroomsだけに制限することができる
Ruleの適用
GUI or REST APIで設定
REST APIがおすすめ
スキーマ設計
Subscribe側を意識する
非正規化した方がいい場面もある
後方互換性を意識
配列がない
addすると自動でキーが振られて配列みたいに作成される
放送後はデータを読み込ませない
特定のライブIDが放送中かどうかのフラグを管理し、読み込みを許可する
root.child('alive_lives').child($live_id).val === trueとすることで他のノードの値を引っこ抜いて書きこみ、読み込みを制御できる
admin権限でルールを無視して放送中フラグを変更する
Write戦略
スマホからFirebaseへの書き込みは行わせない(APIを通す)
攻撃、認可など工数を考えたため
APIからEnqueue Job(Q4M)、Worker Process(PHP)がDequeue Job、Firebaseに投げる
FirebaseをSPOFににしない
野良SDKでkreait/firebase-phpをおすすめ
Read戦略
クライアントは受け取ったデータを表示するだけ(バリデーションはかけない)
スケーリング
Realtime Databaseはスケールアップできない
常用インスタンスと高負荷用インスタンスを分ける
料金は従量課金
何台インスタンスを立てていても通信しなければタダ
Firebase ProjectsとGCP Projectは1対1
Cloud Firestoreで変わった点
自動スケールアウトするようになった
SDKのI/Fがよくなった(Where的なことができるようになった)
RDよりLatencyが伸びる可能性がある
VS
新規プロダクトは基本Cloud Firestoreでよい
ReadWriteオペレーションが大量にハッセうする場合はCloud Firestoreの方がお金がかかる
何がよかったか
ユーザー体験
シンプルなアーキテクチャ
待機開発リリースを実現
運用、追加開発しづらいPHPアプリケーションに未来を与える方法
運用、追加開発しづらいPHPアプリケーションに未来を与える方法 // Speaker Deck
しやすいとは
- テストコードがある
- アプリケーションモニタリングがある
- デプロイが容易(CIサーバー・1コマンド)
モニタリングを追加
New Relic
新規機能
各コントローラー、エンドポイントのレスポンスの記録を確認できる
既存のアプリケーションを触らず、別のアプリケーションを立てて修正して行く
Slim 3.xとALBを使用して追加していく
セッション
session管理はデータベースに書き込むようにした
※この度過去に参加したイベントのメモなどを公開することにしたので、投稿日時をイベント当日に変更してあります。
ゼロから始めるデータベース操作を読み始めた
SQL 第2版 ゼロからはじめるデータベース操作 (プログラミング学習シリーズ)
Amazon CAPTCHA (amazonのサムネイルがちゃんと表示されない?)
前職(まだ退職してないけど)ではCMSを使っていたので、SQLを書く機会がとても少なかった。
書くときも結構その都度調べて書くってことをしていて、大学で学んだときからしっかりSQLを勉強していなかったのでこの機会に基礎をやりなおそうと思った次第。
この本はDB2、Oracle、SQL Server、MySQL、PostgreSQL対応と謳っている。
実際中身はPostgreSQLを使用して学習をしていくのだけど、各データベースで差異がある場合はそれぞれのクエリの書き方の差異を示してくれるのでありがたい。
PostgreSQL
そもそもPostgreSQLを触るのが初めて。
前職ではMySQLとSQL Serverを触っていたので。
サラッと備忘録として基本操作を書いておく。
# ログイン psql -d [データベース] # データベース一覧 \l # データベース選択 \c [データベース] # テーブル一覧 \dt # テーブル情報 \d [テーブル] # 終了(Ctrl + d も可能) \q
MySQLとかだとそのまま句を書いていたので違和感。
PostgreSQLだと show xxxみたいのってないんですかね。
知らなかったこととかそんなんあったなーとか
Distinct
重複行除外、最近めっきり使ってなかったので忘れていた。
DISTINCT A, Bと複数カラム選択すると、すべてが重複しているもののみ除外する。
AND、ORの優先順位
ANDが優先で評価される
A AND B OR C -- 等価 (A AND B) OR C
CHAR型は固定長文字列
CHAR(8)でabcと入れればabcのあとに半角スペースが5つ入る。
NULLを含んだ計算は問答無用でNULL
COUNT(*)以外の集約関数はNULLを計算前に除外
こんな感じで
勉強したことをなるべく振り返られるように要点をブログに出来る限り書いていこう。
UbuntuにDockerとDocker Composeをインストールする
下記公式サイトを参考にインストール。 ほぼ公式サイトのままなのでメモ程度に。
# 既存のバージョンを削除 sudo apt-get remove docker docker-engine docker.io sudo apt-get install linux-image-extra-$(uname -r) linux-image-extra-virtual sudo apt-get install apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo apt-key fingerprint 0EBFCD88 sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" sudo apt-get update sudo apt-get install docker-ce # サービス開始 sudo service docker start # テスト実行 sudo docker run hello-world sudo docker run -it ubuntu bash sudo usermod -aG docker $USER # 自動起動の有効化 sudo systemctl enable docker
docker composeのインストール
sudo curl -L https://github.com/docker/compose/releases/download/1.16.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose # ビルド sudo docker-compose build
Windows PCの中身をUbuntuに変えた
WIndows PCの中身をUbuntu 16.04.3 LTSに変更した。
入れた手順は公式からisoファイルを取得してUnetbootinでUSBメモリに書き込んで、BIOSの起動順序変えて前のWIndowsが入っていたSSDにクリーンインストール。
Windowsの不調
元々Windowsが不調で悩んでいて、つい最近BIOS画面から進めなくなったことから試しにUbuntuにしてみた。
Windowsのシステムファイルが破損したのか、結局原因は分からずじまいではある。
起動できなくなる前は、何度更新しても延々と外国人の眩しい笑顔のWindows Update催促の表示が出まくったりしていて、これやばいなと思っていた。
Windowsの開発者ビルドのアップデートも受け取っていたのでそこらへんも関係していたりするのかもしれない。
開発OSとして
そんなこんなで、元々Windows以外のOS,というかサーバー開発に優れたOSをメインにしてみることは考えていた。
やはりWindowsでもMacでもVagrantやDocker for XXを使っていくとバグを踏んだり環境特有の問題があったりして辛かった。
Ubuntuにすればそこらへんの障壁がなくなるのではないかという淡い期待。
使ってみて
賞味3時間も使っていないが現時点での感想。
- 日本語入力が不安定(最初だけで途中からは問題なくなった)
- オーディオインターフェースなどデバイス周りは特に問題なかった
- ブラウザ系アプリも問題なし
- Kindle使えないの辛い
- キーボードショートカットよくわからん
- 情報がGUIとCUI混在していて探しにくい
ざっとこんなところか
ぼちぼち使ってみて引き続き使うか、他のOSに戻るか検討しよう
最終出社終えました。
2日前の金曜日に最終出社を終えました。
昨日は交流会でLTもしていてそれも終わったのでひと段落といったところです。
まだ退職しているわけではないので後々現職はこんなんやってましたーみたいな退職エントリも書こうかと思います。
とりあえずひと段落、ここから休息と勉強です。
HTML5 Conference 2017に参加してきた
参加してきました。
その時の雑な自分用メモを公開します。
公式サイトは今は見れないっぽい。 http://events.html5j.org/conference/2017/9/
以下に発表スライドをまとめてくれている人がいます。
qiita.com
任天堂
2011年入社 津田 宗孝 2013年入社 堀川 雄司
任天堂とWeb?
公式サイトだけじゃない!
世界中の人と繋げるためにスマートフォンとWEB
Webkitをベースのブラウザコンポーネント
ニンテンドーアカウントの作成はウェブ画面
メールアドレスだけ入力すれば、スマートフォンから他の情報の登録ができるようになる
Nitendo SwitchとWeb
Switchのスクリーンショットで、投稿する画面はウェブアプリケーション スプラトゥーンの武器の説明はHTML、試し打ちのスーパーの説明やバトルのルール説明など 文字が多いところはWEB、WEBだと多言語対応がしやすいため アームズのキャラクターのところも?
みまもりSwitchは普通のネイティブ
Nintendo eShopができるまで
2015年末
eShopのプロジェクト発足
すぐに
- すぐに出会える
- すぐに買える
- すぐに改善
出会える
eShopを見なければ目につかないのであれば意味がない
商品のプロモーションはゲームニュースに切り出した
スリープ復帰時に必ず目につくようになっている
買える
書いたいと思ったらすぐに買えるための導線を増やす
買いたいと思う熱を冷まさない
ソフトとサーバーサイドが連携してeShopの色も自動で変わるように対応
すぐに改善
ライブラリ選定
SPAを前提
コンポーネント指向
シンプルな状態管理、決済や言語などに対応するため
React + Redux
react redux react-router axios
文脈に沿って追加/習性が可能
コンポーネント化の誤解
ここは価格を目立たせたい
価格、同じコンポーネントだけどどうするの?
デザイナーはWhat、エンジニアはHow
全体を俯瞰できるモックアップの開発に立ち返った
検索は非同期で一部描画
描画コストの高い画像に関しては商品のキーカラーを表示
描画領域以外の箇所を後からレンダリング
React-storybookを活用して認識を共有、コンポーネントカタログを作成
開発と検証の溝
国、言語、法律、通過、決済
ユーザーストーリの作成
エピック
ニュース→eShop→ゲームの購入
品質目標
- Never
- Must
- Want
開発序盤からのテスターとの協業
長期的な安定稼働
すぐに改善
終盤、ローンチまで半年を切ったところ
eShopが不安定、起動が遅い
フロントエンドエンジニアからのヘルプ
サーバー、ブラザ、アプリ、SDK/OSプログラマ、デザイナ、一つの会社、一つの建物にいるのでできる
Yahooのプロキシとプロトコル
新部 長則
2010年 HDDからSSDへの変更
2011年 帯域不足 NW増強、データセンター追加
2013年 pushスパイク問題、Proxy、origin共に増設
2015年 SSL、CPU性能不足 システム入れ替え
AOSSL対応
2015年10月 全社の代表者が集まり発足
サービスが100以上、ドメイン1000以上なのでなるべく収まるよう減らして言った
またワイルドカード証明書を活用
共有Proxy Hardware 500以上のサーバー
リクエスト200万rps
Traffic 300Gbps
EV SSLだとワイルドカード証明書が使えない
SNIによる証明書の出し分けで対応
HTTP/2の現実
大津 繁樹
ATM
HTTPリクエストを仮想的に多重化
待ちが他のリクエストに引きずられない
サーバー側から見る速度
大きめのファイルのダウンロードは確かに早くなった
アクセスしているOSやクライアント環境によるものかもしれないのでHTTP2のおかげで早いのかは分からない
小さいファイルはほぼ変わらなかった
クライアント側から見る速度
DOMContentLoaded
HTTP 1.1 1.15s
HTTP 2 1.14s
ほとんど変わらなかった
画像の読み込みは早いがそれ以外の要因で変わらなくなっている??
新規接続:再接続
http/2 11:89
1.1 42:58
サーバーのSSLの暗号化処理の分が軽くなるのでサーバー側に影響が以外にもあった
TLSの現実
TLS1.0はオワコンだがWin7 IE9、IE10、IE11やAndroid4.x 標準ブラウザ
今はTLS1.2
TLS1.3
HTTPというものはブラウザからも信用されない時代がくる
中間経路がTLS1.3に対応していないとそこでブロックしてしまう可能性があるので調査が必要
QUIC
クイック
UDP
モダンウェブアプリケーション5カ年計画
Rendering on Googl Search
V41のクロームでSPAもSEO解釈されるようになっている
Isomofic JavaScript = Universal JavaScript
全アプリに向かない(参照系に向く)
管理画面などは複雑性が高いから難しいかも
Code-Splicting
SSRは意外にも表での処理がとても長くなる(操作開始まで)
WebpackのDynamic Importsで解決
React Fiberでバックエンドの処理もさらに細かく
※この度過去に参加したイベントのメモなどを公開することにしたので、投稿日時をイベント当日に変更してあります。