『基礎から学ぶ サーバーレス開発』を読んだ

基礎から学ぶ サーバーレス開発

仕事でAWS Lambda(+Serverless Framework)を使う機会があり、AWS LambdaやServerless Frameworkについてほとんど知らなかったので、読んでみた。

『基礎から学ぶサーバーレス開発』は、AWS Lambdaを題材にサーバーレスアーキテクチャでのシステム開発方法を学ぶ書籍。

一番のポイントは出版年月日の新しさ(2020年7月)。クラウドは新機能や新サービスの追加が多いので、書籍に載っている情報もどんどん古くなる。そういう意味で、最新の情報がまとまった書籍にちょうどよく巡り合えたのはラッキーだった。

内容についても、サーバーレスの良さだけでなく、気をつけるべき点についても書いてあったり、実際に動かして試せるコードサンプルもあって良書だと思う。

AWS Lambdaで実稼働させるシステムをどう組めばいいのか分からない、という人にはオススメ。

『雰囲気で使わずきちんと理解する!整理してOAuth2.0を使うためのチュートリアルガイド』を読んだ

雰囲気で使わずきちんと理解する!整理してOAuth2.0を使うためのチュートリアルガイド (技術の泉シリーズ(NextPublishing))

仕事でGoogle APIのOAuthを使う機会があり、そういえばOAuthってちゃんと勉強したことなかったなーということで読んだ。

本書を読む以前のOAuth経験はTwitterクライアントの実装くらい(要するにOAuth 1.0しか触ったことがなかった)。

OAuth 2.0はOAuth 1.0の欠点も踏まえて、よりモダンな仕様になっている。といってもRFC 6749は2012年なので、そこまで新しいわけではなく、OAuth 2.1という仕様も策定が進められている。が、これはRFC 6749の後に出たRFCの機能を盛り込んだり非推奨になってきた機能を外したりといった再構築バージョンという趣で、ベースはOAuth 2.0。OAuth 2.0の知識は今後5〜10年くらいはもちそうな印象がある。

一方でOAuth 2.0は結構複雑で、これだけをテーマに500ページ近い本を書ける分野でもある。

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

本書『雰囲気で使わずきちんと理解する!整理してOAuth2.0を使うためのチュートリアルガイド』は、そんなOAuth 2.0の基本を150ページ程度で押さえることができる書籍になっている。

基本的な用語の解説と主要なアクセストークン発行の流れが網羅されており、本書を読み終わった後にはちゃんとした理解のもとでOAuthクライアントライブラリを利用できるようになる。

OAuth 2.0について書籍で学びたい人が最初に手を出す本としてオススメ。

WP Super Cache をやめて W3 Total Cache をインストールした

WordPressのキャッシュプラグインは色々あるけど、今までこのブログでは WP Super Cache を使っていた。Automattic製ということもあり、信頼がおけると考えていて、実際「静的HTMLをキャッシュして返す」という部分では特に問題なく動作していた。

しかし、WP Super Cacheはサーバサイドでレスポンスを静的HTMLとしてキャッシュするという用途に特化しており、ブラウザキャッシュの設定などは別途行う必要がある。

カスタムテーマにヘッダーをセットする関数を仕込んだりしてもいいのだけど、WordPressなんだからプラグイン + GUIで設定したいということでいくつか試した結果、 W3 Total Cache が良い、という結論になった。

W3 Total Cacheをインストールすると、WordPressの管理画面に「パフォーマンス」というメニューが追加される。

このメニューから各種設定を行えるのだが、レスポンスキャッシュだけでなく、HTML/CSSの圧縮、データベースキャッシュ、PHPレベルのキャッシュ、ブラウザーキャッシュなど多岐にわたるキャッシュ設定を行うことができる。さらに、CDNとのインテグレーションなどもあり、WordPressのパフォーマンス最適化に関する設定全般を引き受けるプラグインになっている。

ブラウザキャッシュも管理画面から細かく設定できる。

W3 Total Cacheを入れていくつか最適化した結果、PageSpeed Insightsの計測結果は95点になった。

さらなる最適化には不使用cssの削除など、出来合いのテーマを使っていては手を出しづらい領域に踏み入れる必要がある。現状のスコアも悪くはないので、これ以上の最適化はしなくても良いかなーと思っている。

『ノンデザイナーズ・デザインブック』を読んだ

ノンデザイナーズ・デザインブック [第4版]

『ノンデザイナーズ・デザインブック』は、デザインの専門的な訓練を受けたことのない「ノンデザイナー」に向けた、ビジュアルデザインの入門書。

本書でいう「ビジュアルデザイン」は文字を中心としたデザインであり、デザイン例は書籍、雑誌、チラシ、ダイレクトメール、名刺など。

「近接」「整列」「反復」「コントラスト」の4原則に基づいて、情報を整理し、それを的確に伝えるよう構造化することで、ビジュアルデザインは見違えるほど良くなる。

本書はデザイン原則を適用したことによる改善例をこれでもかというほど見せてくれるので、頭で理解するだけでなく、審美眼が鍛えられる。

また、書体(フォント)についての基本的な解説もあり、例えば「serif」と「sans-serif」の何がどう違うのか、はっきり指摘できるようになる。

本書の日本語版については、日本語独特の事情(縦書きの存在やフォントの違いなど)の補足もあり、単なる翻訳ではなく、ローカライズになっている点もポイントが高い。

総じて良くできた書籍で、デザイナーがデザインをする際にどういうことを考えているのか理解する助けになる。

なお、本書のテクニックはWordで作る報告書やPowerpointで作るプレゼン資料といったものにも適用できる。資料作成に特化した書籍としては同著者の『シンプルでよく効く資料作成の原則』もあり、こちらも読んでみたい。

『Collection Pipeline』を読んだ

Collection Pipeline – martinfowloer.com

本ではなくWeb記事だけど、面白かったので読書メモ。

コレクションパイプラインとは

コレクション(配列、リスト等)に対する操作をつなげて書くプログラミンスタイル。たとえば、記事のリストから、「JavaScript」をタイトルに含む記事の総語数を取得したい場合、JavaScriptでは以下のように書ける。

articles.filter(a => a.title.includes('JavaScript'))
  .map(a => a.words)
  .reduce((p, c) => p + c, 0);

初めに記事のリストをフィルタリングし、次に語数の配列へ変換してから、語数を合計している。

これをループを使って書くとこうなる。

let result = 0;
for (let a of articles) {
  if (a.title.includes('JavaScript')) {
    result += a.words;
  }
}

ループの方が決定的に劣るということはないが、コレクションパイプラインを使うと配列に対する操作を宣言的に書くことができる。

コレクションパイプラインは、無名関数(言語によってはラムダ式などともいう)を多用することから、関数型のパラダイムや、関数型っぽい機能といわれることも多い(実際、僕もそう思っていた)。

しかし、本記事によると、コレクションパイプラインの発祥はSmalltalkであるらしい。

Smalltalkでは、コレクションに対する操作を以下のように書ける。構文は独特だが、コレクションに対する操作を連結するスタイルは同じ。

 ((someArticles 
      select: [ :each | each tags includes: #nosql])
      sortBy: [:a :b | a words > b words]) 
      copyFrom: 1 to: 3

一方、初期の代表的な関数型言語であるLispでは、こうなる。

(subseq
   (sort
      (remove-if-not
         (lambda (x) (member 'nosql (article-tags x)))
         (some-articles))
      (lambda (a b) (> (article-words a) (article-words b))))
 0 3)

素朴な関数型のスタイルでは、関数呼び出しが実際の処理の流れとは逆順になる点が、Smalltalkとは異なる。この点、モダンな関数型言語(Closureなど)では、関数呼び出しをシーケンシャルに書く機能が用意されていることが多い。

(1) コレクションのシーケンシャルな操作を連鎖させるというプログラミングスタイルは、初期のオブジェクト指向言語であるSmalltalkから生まれた

(2) 無名関数(ラムダ式)は関数型言語の専売特許ではない(C++、Javaといった代表的なオブジェクト指向言語がラムダ式を採用しなかっただけ)

というのが個人的に面白いと思ったポイント。

Collection Pipelineを避けるべき状況

(1) 言語がサポートしていない場合

本記事では、ラムダ式がなかった時代のJavaが例に挙がっている。他にも、Goにはラムダ式はあってもコレクションパイプラインは使えない。このような言語で無理してコレクションパイプラインを使うと、混乱の元になる。

(2) リスト内包表記を使える場合

Pythonなどの言語には [i for i in range(10) if i%2==0] のように、リスト内でコレクション操作を行える機能が備わっている。

リスト内包表記が使える場合は、 コレクションパイプラインではなくリスト内包表記を使った方が、短く読みやすいコードを書けることがある。

(3) コレクションに対する操作が複雑な場合

コレクションパイプラインで実装できる操作であっても、それが10行以上になるような複雑な操作であった場合、単一のコレクションパイプラインとして実装するのではなく、関数を抽出して、細かいステップに分けるべき。

関連書籍:Refactoring, 2nd Edition

Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler))