一連の読書シリーズはこれで最後。アプリケーションアーキテクチャ設計パターンを読んだ。
本書はアプリケーション全体、システム全体の設計について具体例を添えて書かれている。Javaを中心に様々なパターンについて触れられており、全部に触れていくとキリが無い。気になったワードや解釈を中心に触れていく。
内容が多岐にわたることもあって簡単なワードやらを羅列する形でまとめているが、サーバー側の知識を中心に増やすことができた。これまでWebクライアント一本で進んできたので、繰り返し読み返して身につけたい。もう少し個人でもサーバーサイドのコードを書こうかなー。
僕がプログラムを一番最初に書いたのは17歳の時だったが、これまでに自分が書いたソースコードを全て見直しても、おおよそ設計と呼べるものが無かった。
設計思想、設計とは何かを学ぶためにCleanArchitectureを読んだのでメモを書く。
いつも見る例のアレ。既にネットにある種々の解説を読んでみてもピンとこなかったが、本を読むとそれなりにしっくりきた気がする。自分なりにまとめてみる。
この本では、依存方向のコントロールと適切なコンポーネント粒度の重要性について語り口を変えて幾度も説かれている。アプリケーションやソースコードに依存が発生するのは避けられないが、依存の方向はコントロールすることが出来る。それが出来れば、依存先に重大な変更が加わった場合でも、依存している側への影響は最小限で済む。そのために、例えば必ずインターフェースを定義、用意しておくことでコントロールが容易になるなどの例が繰り返し紹介されている。
また、依存方向をコントロールするためには、適切なコンポーネント粒度である必要がある。コンポーネントが密結合すぎると、アーキテクチャの変更等アプリケーションにとって大きな変更が加わった場合に対応できなくなる。コンポーネントの分割粒度や可変/普遍など詳しくは書籍の中で触れられているが、それぞれのコンポーネントがどういう位置づけで、他のコンポーネントとどのように関わるのかは常に意識したい。
個人的には、こういったことを意識することでテスタブルなコードを書けることも嬉しい。
本書を読むまで、上記の図すら理解出来なかったがまずはそこをクリア出来てよかった。クリアするためにはその前提である依存方向のコントロールやコンポーネント粒度を理解しておかねばならず、その理解が無かった僕にとっては多くの収穫があった。本の中でも触れられているが、あくまで円の図は一例であるので、実際のアーキテクチャを考えるにあたっては完成はなく常に見直し続けることが大事らしい。そういった考えに至れたり、少しずつ自分の書くコードがまともになっている気がするのはほんの少し進歩したと思う。思いたい。
僕がWebフロントエンドの世界に飛び込んでから数年経った。しかし、恥ずかしながらこれまでアプリケーションのパフォーマンスについてあまり深く考えたことがなかった。僕がWebに飛び込む前から、そして飛び込んだ後もWebページの高速化は日に日にその重要性を増してきており、最低限の知識や考え方を持っていないと成果を出すどころか同僚との議論にすら全くついていけなくなる有様だ。
パフォーマンスの世界への入り口として 超速本 を読了したので自分なりにまとめてみることにした。
推測するな、計測せよ は様々な領域で言われていることだが、改めてこの言葉を噛みしめることになった。
考え方としては、
の2つが特に重要そう。
高速化と言っても、ボトルネックの正体やそれに合わせた対応を考えると様々である。
しかし、主に軽量化(取り扱うデータ量を削減する)や最適化(実行の順番やデータ経路などのチューニング)を意識することになる。
具体的には、下記のようなことを考えることになる。
ここまでで、Webのパフォーマンスアップに対する考え方や着目点を知ることが出来たが、重要なのは計測することである。計測手段はいくつかあるので、それぞれ見ていく。
おそらく最も多くのWebフロントエンジニアに馴染み深いツール。DevToolの各タブで出来ることを見ていく。
個人的には、DevToolの中でも使用頻度が高いタブ。ページ内の関連リソースの通信状況を確認できる。
Yahoo!JAPAN でnetworkタブを開いてみるとこんな感じ。
ページ上部にはページ読み込み完了までのリソース読み込み状態が表示されている。
ここで、青と赤の赤線に注目したい。
上記のリソース読み込み状態の下には、Waterfallが表示されている。ここでは、リソースがダウンロードされる順番や、各リソースをダウンロードするのにかかった時間がわかる。それぞれのリソースの詳細も見られる。
Webサイトのパフォーマンスを計測できる。これまであまり使ったことがなかった。
AbemaTVのもの
この値が小さいほど、より速く画面が更新され動くことを示す。
CPU
このグラフが示すのはCPUの負荷の大きさで、色によってそれぞれ意味が異なる。
NET
ネットワーク通信状態を示す。優先度の髙い/低いリソースへのアクセスを表す。
Googleが提供しているツール。URLを入力することで、そのWebページのPC/SPでの表示速度を計測できる。
久しぶりに自分のWebページに対してチェックをかけてみたら一見良さそうな値が出てきた。一見早く見えるが、単純にコンテンツが無いだけ。
複雑なWebページであればあるほどスコアは落ちてくるが、改善項目をサジェストしてくれるのでその項目を精査、改善するだけでも結構違う。
合成モニタリングを行うサービス。実際に特定のリージョンからアクセスを実行し、ChromeDeveloperToolsのNetworkタブに相当するデータを取得できる。
こちらに詳しい。
自分のWebページに対して実行してみた結果。有料の合成モニタリングサービスとしては、 SpeedCurve が有名。
上記のツールを用いてパフォーマンスの改善を図る場合に、どのタイミング/段階の数値を改善するのかを追いかける方がより良い改善ができる。表示速度においては、ナビゲーションからのパフォーマンスを示す複数の指標がある。
こういった指標が挙げられ、それぞれに効果的な改善を模索、実行していくことになる。ここで意識しておきたいのは、 最も重要視するべき指標はプロダクトによって変わってくる ことである。プロダクトでの各指標がどうなっているかを継続的に計測すること、改善するために何が出来るかをチームで議論して実践することが何より大事っぽい。
いろいろ考えることがあって混乱してしまうのが正直なところだが、まずは計測する仕組みする仕組みを整えること、それぞれの指標/フェーズにおいて何が出来るのかを一つずつ明らかにしていくのが良さそう。
計測による可視化がなければ闇雲かつ場当たり的な対策しか出来ず、パフォーマンスを改善したとは言えない。特にWebは多種多様な環境でのアクセスが当然のように起こる世界なので、チーム/プロダクトで協力して様々な環境を用意し、定期的なモニタリングと評価、改善が肝要なのだと知ることが出来た。
プライベートプロジェクトのサーバー実装を一新するべく，セッション認証とパスワードハッシュ化を付けたのでメモ．
本当はユーザー情報をDBに持たないと意味が無いけど，ユーザーは僕しか居ないからまあいいやと妥協した．
const express = require('express')
const oauth = require('oauth')
const http = require('http')
const path = require('path')
const crypto = require('crypto') // 暗号化
const bodyParser = require('body-parser')
const session = require('express-session')
const app = express();
app.use(express.static(__dirname));
app.set('port', process.env.PORT || 3000);
[f:id:heimusu:20180518115114j:plain]
// Cross Originを有効化
app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', '*');
res.header('Access-Control-Allow-Headers', 'Origin, X-Requested-With, Content-Type, Accept');
res.header('Access-Control-Allow-Methods', 'GET, PUT, POST, DELETE, OPTIONS');
next();
});
// Optionsも
app.options('*', (req, res) => {
res.sendStatus(200);
});
// urlencodeとjsonの初期化
app.use(bodyParser.urlencoded({
extended: true
}));
app.use(bodyParser.json());
// セッションの生存時間（分で指定）
const maxage = 1;
// セッション管理設定
app.use(session({ secret: 'keyboard cat', cookie: { maxAge: maxage * 60000 }}))
// セッション管理関数
const sessionCheck = (req, res, next) => {
if (req.session.email) {
next();
} else {
res.status(440).json({message: 'セッション切れです'})
}
}
const email = 'email@email.com'
const password = 'hogehoge'
// sha-512で暗号化
const hashed = password => {
let hash = crypto.createHmac('sha512', password)
hash.update(password)
const value = hash.digest('hex')
return value;
}
// ログイン処理
app.post('/login', (req, res, next) => {
const reqEmail = req.body.email
const reqPass = req.body.password
try {
if(email === reqEmail && hashed(password) === hashed(reqPass)) {
req.session.email = {name: req.body.email};
res.send(200)
}
else {
res.status(401).json({message: 'メールアドレス/パスワードが一致しません'})
}
}
catch (error){
res.status(500).json({message: 'error'})
}
});
app.get('/', (req, res, next) => {
sessionCheck(req, res, next)
res.sendStatus(200)
})
app.listen(3000, function(){
console.log('working');
});
散々言われ続けてきたことだが，自分の備忘録として残しておく．
例えば下記のような場合
constructor(props) {
super(props);
this.state = {
isOpen: false
}
}
componentDidMount() {
this.setState({
isOpen: true
})
}
click(flg) {
alert(flg)
}
render() {
return({
<div onClick={()=>this.click(this.state.isOpen)}>
})
}
DOMをクリックした場合に，1回目のクリックではfalse，2回目以降でtrueが表示される． 本当は1回目のクリックでtrueが表示されてほしいが…
正しい対処法なのかどうかはさておいて，上記のコードを次のように変更すると良い．
constructor(props) {
super(props);
this.state = {
isOpen: false
}
}
componentDidMount() {
this.setState({
isOpen: true
})
}
click(flg) {
alert(flg)
}
render() {
const isOpen = this.state.isOpen
return({
<div onClick={()=>this.click(isOpen)}>
})
}
render()内でthis.state.isOpenを変数に外出しにして，その変数をDOMに渡す． こうすることで一回目のクリックでもtrueが表示されるはずだ．
業務でReact.jsを扱う中でハマったので試行錯誤した結果この形になったが，原因や良い対処法についてはっきりしていない…
stateの変更タイミングが意図的に制御されているのだと思うが， そもそもreduxを使っていれば心配いらないのかもしれない．
原因やよりよい方法についてご存知であれば是非コメントにて．
業務でTinder風UIを作るオーダーが来たので，勉強も兼ねてRx.jsで作ることにした．
下記のコードはRx.js ver5.8.8で動作を確認しています． v6.0.0では動作しないので適宜読み替えてください．
また，モバイルでの動作を想定して記述しています．
const tolerance = 200;
const windowWidth = window.innerWidth
const imageElem = document.querySelector('.characterImage') // dom
// 現在のスワイプ位置を取得
const touchstart$ = Rx.Observable.fromEvent(imageElem, 'touchstart')
.switchMap(startEvent =>
Rx.Observable.fromEvent(imageElem, "touchend")
.map(e => e.changedTouches[0].pageX)
)
touchstart$
.do(val => {
// スワイプ位置を判断して画像を振り分ける
if(val > windowWidth - tolerance) {
imageElem.classList.add('rotate-right')
}
else if(val < windowWidth / 2.0 - tolerance) {
imageElem.classList.add('rotate-left')
}
})
.delay(1000)
.subscribe(val => {
imageElem.classList.remove('rotate-right')
imageElem.classList.remove('rotate-left')
})
対象のDOMをfromEventで監視して，touchend時の座標を基に判定する． torelanceをいじることで動作をもう少し過敏にしたりできる．
subscribeではサンプル用に画像の復帰処理をしているが，画像の追加変更も任意で行える．
まだRx.jsの勉強中なので掴めていないところが多々あるが，一旦は目標のものが出来上がった． Rx.jsは出来ることがたくさんあって使い所が分かっていなかったり，そもそも書き方がまだおぼつかなかったり… 使いながら覚えていくしかなさそう．
上記コードの指摘等あればプルリクを投げてもらえると嬉しいです．
https://github.com/heimusu/rxtinder
CloudFrontに紐付いたS3に静的ファイル一式を置いた構成はテッパンだと思う． この場合，静的ファイルを更新するためには 1. S3にファイルをアップロードする 2. CFをInvalidateする の手順が必要となる． 滅多に更新が発生しないならともかく，絶賛開発中のプロジェクトの場合にこの操作を何度も手動で繰り返したくない．
本来ならばCIを設定したりwebpackでbuildついでに実行するなどありそうだが，オーソドックスにgulpタスクを書いてみた．
$ yarn add gulp gulp-awspublish gulp-cloudfront-invalidate
const gulp = require('gulp');
const awspublish = require('gulp-awspublish');
const cloudfront = require('gulp-cloudfront-invalidate');
// S3にデプロイするタスク
// dev環境にデプロイする
gulp.task('deploy', function() {
const key = {
accessKeyId: '...',
secretAccessKey: '...',
region: "ap-northeast-1",
params: {
"Bucket": "bucket-name",
}
}
const publisher = awspublish.create(key);
// deployするもの
gulp.src(['**/*', '!node_modules/**/*', '!gulpfile.js', '!package.json', '!README.md', '!yarn.lock', '!.babelrc' ])
.pipe(publisher.publish())
.pipe(awspublish.reporter());
});
// CFをInvalidateする
const cfInvalidateSettings = {
distribution: '...',
paths: ['/*'],
accessKeyId: '...',
secretAccessKey: '...',
wait: true
}
gulp.task('invalidate', function() {
return gulp.src('*')
.pipe(cloudfront(cfInvalidateSettings));
})
$ gulp deploy && gulp invalidate
これで，指定したS3に静的ファイルを設置（存在しないファイルは新規に設置，存在するファイルは差分があれば更新）した後に指定したCFをinvalidateしてくれる． あとは個々の案件に併せてタスクをカスタマイズして，package.jsonのscriptsに良い感じで書いておく． 上記の設定だとinvalidateの完了までwaitする設定になっているが，外すことも出来る．個人的にはしっかりinvalidateが完了したかを見届けたいのでwaitすることにしている．