「アイソモーフィックJavaScript」を読みました

はじめに

タイトルのインパクトで本を選んでしまうことが時々あります。
「バンディットアルゴリズムによる最適化手法」とか。
そんな感じでオライリーの書籍一覧の中に「アイソモーフィック」という耳慣れない言葉を見つけて以来ずっと気になっていた本を読みました。

「アイソモーフィックJavaScript」

アイソモーフィックJavaScriptとは

アイソモーフィックJavaScriptとは、サーバ側とクライアント側で同一のJavaScriptコードでウェブアプリケーションを動かそうという考え方のことです。
本書では、今どきのウェブアプリケーションに求められる以下の3つの条件を同時に満たす手法としてアイソモーフィックJavaScriptが有効であると説きます。

  • SEO対応(検索エンジンによるインデックス化が可能)
  • 最適化され高速に読み込まれる初期ページ
  • ユーザーの操作に対する迅速なレスポンス

ウェブアプリケーションの発展に見るアイソモーフィックJavaScriptの利点

古典的ウェブアプリケーション

  • リクエスト毎にページ全体を読み込む
  • 検索エンジンによるインデックス化: ○
  • 初期ページ読み込みの最適化: ○
  • ユーザー操作への応答性: ☓
    新しいページが前のものとほとんど同じでもページ全体の再読込みが必要

古典的ウェブアプリケーション+Ajax

  • ユーザー操作への応答性向上
    書き換えが必要な部分だけをサーバから取得してクライアント側で再描画
  • コードの保守性、開発の効率性に問題
    サーバ側とクライアント側で同じ処理内容を異なる言語で記述
    処理フローの見通しの悪さ
    など

SPA(Single Page Application)

  • サーバ側とクライアント側との責任分担を明確にして保守性・効率性を向上
  • サーバからクライアントに送信されるのはテンプレート(初回)とデータ
  • 描画はクライアント側
  • 検索エンジンによるインデックス化: △
    同じURLのままページが書き換えられる
  • 初期ページ読み込みの最適化: △
    テンプレートを読み込んだ後、データの読み込みが完了するまで描画できない
  • ユーザー操作への応答性: ○

アイソモーフィックJavaScript

  • 検索エンジンによるインデックス化: ○
    HTML5のHistory APIを活用して状態毎にURLを変化させる
  • 初期ページ読み込みの最適化: ○
    初回だけサーバ側で完全なページ描画、それ以降はクライアント側で書き換え。コードがサーバ・クライアントで同一なので保守の問題が生じない
  • ユーザー操作への応答性: ○
    書き換えが必要な部分だけクライアント側で再描画。場合によってはサーバ側との通信さえも発生させずに済むことも

どうやって実現するか

良いことだらけに見えるアイソモーフィックJavaScriptですが、現時点ではデファクトスタンダートと呼べるフレームワークが存在している訳ではなく、自前でフレームワークにあたる部分を実装する必要があります。(あるいは人柱覚悟でオープンソースのフレームワークを導入する)
本書はフレームワークの実装例を示す第II部がメインになっています。

サーバとクライアントと同じコードを動かすためにはかなり泥臭い仕掛けが必要になります。たとえば以下のような課題を解決しなければなりません。

  • サーバ側とクライアント側とでアプリケーションの内部状態を同期する
  • サーバ側とクライアント側とで統一されたアプリケーションルーティング
  • サーバ側とクライアント側とで異なるファイルパスの隠蔽
  • Cookie の読み書きの抽象化
  • リダイレクトの抽象化
  • JavaScriptが無いクライアント(たとえば検索エンジンのボット)のためのサーバ側での描画

これらをどのように解決しているのかについては是非本書を読んでみて下さい。

実例

第III部は Walmart, GetHuman, Bloomberg, Colony といったサイトでのアイソモーフィックJavaScriptへの取り組みの実例です。同じような問題意識を持った各社の人たちがより良い実装とベストプラクティスを求めて工夫している様子がよく分かります。

こちらを先に読んで、アイソモーフィックJavaScriptで解決しようとしている問題の大枠を頭に入れてから第II部を読んだ方が読み進めやすいかもしれません。

ちょっと残念だったところ

本書ではアイソモーフィックJavaScriptの概念をざっくり説明した後はおもむろにフレームワークの実装に掛かります。Hellow Worldだけを表示する簡単なアプリケーションルーターとテンプレートだけからスタートして徐々に機能を追加・更新しつつ説明を加えるというスタイルです。
コードを入力しつつ読むと実装を追体験できるしボトムアップの説明を好む方には良いと思うのですが、私は通勤中に字面だけでコードを追っかけつつ読んだのでなかなか辛いものがありました。

  • 途中段階ではアイソモーフィックJavaScriptになっていないので、「この節で説明しているこの実装をすると何が嬉しいのか」を見失いがち
  • 同じファイルをちょこちょこ変更しつつ説明が進むが、以前のものとの差分が分かりづらくてどこをどのように変更したのか捉えづらい
  • 利用しているライブラリやAPIの位置付けが説明不足なところがある。
    たとえば、Node.jsやBabelやnumjucksなどインストールから説明しているものも有る中で唐突にHistory APIというものが導入されて少々混乱しました。調べてみたらHTML5に含まれるAPIということでなーんだとなりましたが。

個人的には全体像を最初にばーんと示してからブレイクダウンしていく説明の方が分かりやすかったと思いますが、この辺りは人それぞれでしょう。

まとめ

技術的に枯れるまでにはまだしばらくかかりそうですが、アイソモーフィックJavaScriptという考え方の魅力はとてもよく理解できる本でした。
興味のある方は是非。

CSS Grid Layout を使ってみよう!(基本編)


 
webページでレイアウトをするとき、今まではfloat、最近では、Frexboxを使ったりしているかと思いますが、「CSS Grid Layout」も今後導入を考えてもいいかもしれません。
まずは、簡単に3×3のマスを作ってみましょう!
 
.grid-containerにグリッドの要素を内包する要素として
「display: grid;」を記述します。

item1
item2
item3
item4
item5
item6
item7
item8
item9
.grid-container{
  display: grid;
  height: 300px;
}
.grid-item{
  background-color: #efefef;
  border: 1px solid #ddd;
}

このままだと、divタグが並んでるだけなので、.grid-itemにそれぞれ位置を追記します。

.item1 {
  grid-column: 1 / 2;
  grid-row: 1 / 2;
}
.item2 {
  grid-column: 2 / 3;
  grid-row: 1 / 2;
}
.item3 {
  grid-column: 3 / 4;
  grid-row: 1 / 2;
}
.item4 {
  grid-column: 1 / 2;
  grid-row: 2 / 3;
}
.item5 {
  grid-column: 2 / 3;
  grid-row: 2 / 3;
}
.item6 {
  grid-column: 3 / 4;
  grid-row: 2 / 3;
}
.item7 {
  grid-column: 1 / 2;
  grid-row: 3 / 4;
}
.item8 {
  grid-column: 2 / 3;
  grid-row: 3 / 4;
}
.item9 {
  grid-column: 3 / 4;
  grid-row: 3 / 4;
}

これで、要素が3x3に並んだと思います。

CSSが長くなりましたが、内容はほとんど共通でシンプルです。
「.grid-item」に指定してある、
grid-columnは横の開始点と終了点、
grid-rowは縦の開始点と終了点を指定しています。


ちなみに分割する線のことを「グリッドライン(grid line)」と呼んでいます。

アイテム間に余白を入れるgrid-gap

アイテム間に余白を入れたい場合があると思います。
その場合、親要素「.grid-container」に「grid-gap」を追記しましょう。

.grid-container{
  display: grid;
  grid-gap: 5px;
}

アイテム間に5pxの余白が出来たと思います。

共通のアイテムの幅と高さの指定

ここまでで、「item1」〜「item9」まで個々にアイテムの幅と高さを指定していましたが、共通の幅と高さである場合「grid-template-columns」「grid-template-rows」で省略できます。
grid-template-columnsで横幅の指定、grid-template-rowsで縦幅の指定ができます。

次のように書くと、「横幅が150px 100px 50px」「縦幅は150px 100px 50px」の縦横共通のアイテムができます。

.grid-container{
  display: grid;
  height: 300px;
  grid-gap: 5px;
  grid-template-columns: 150px 100px 50px;
  grid-template-rows: 150px 100px 50px;
}

「fr」という値について

さらに「1fr」「2fr」などの様に指定すると残りの長さを分割出来ます。

.grid-container{
  display: grid;
  height: 300px;
  grid-gap: 5px;

/*幅150px 残りの1/3 残りの2/3 のグリッド*/
  grid-template-columns: 150px 1fr 2fr;

/*高さ150px 残りの1/3 残りの2/3 のグリッド*/
  grid-template-rows: 150px 1fr 2fr;
}

個別のアイテムの大きさの変更

これらを応用すれば下記のようなレイアウトが出来ます。
(item4,item5の大きさを変更しています。)

item1
item2
item3
item4
item5
item6
item7
.grid-container{
  display: grid;
  height: 300px;
  grid-gap: 5px;

/*幅150px 残りの1/3 残りの2/3 のグリッド*/
  grid-template-columns: 150px 1fr 2fr;

/*高さ150px 残りの1/3 残りの2/3 のグリッド*/
  grid-template-rows: 150px 1fr 2fr;
}
.grid-item{
  background-color: #efefef;
  border: 1px solid #ddd;
}

/*「grid-template-columns」「grid-template-rows」で指定した以外の大きさのレイアウト*/
.item4 {
  grid-column: 1 / 3;
  grid-row: 2 / 3;
}
.item5 {
  grid-column: 3 / 4;
  grid-row: 2 / 4;
}

グリッドラインに名前

ちなみにグリッドラインに名前をつけることができます。
最初や最後、キーポイントとなるグリッドに名前を付けることで管理がしやすくなるかと思います。

.grid-container{
  display: grid;
  grid-gap: 5px;
  grid-template-columns: [c1] 150px [c2] 1fr [c3] 2fr [c4];
  grid-template-rows: [r1] 150px [r2] 1fr [r3] 2fr [r4];
}
.item1 {
  grid-column: c1 / c2;
  grid-row: r1 / r2;
}

spanキーワードを使う

グリッドラインの代わりにいくつ先のラインに伸ばすか記述する方法もあります。
下記の「grid-row」だとグリッドライン2から2つ目までという意味です。

.item5 {
  grid-column: 3 / 4;
  grid-row: 2 / span 2;
}

ここまでのサンプルです。

簡単にですが、CSS Grid Layoutの基本的な使い方をお伝えすることができたでしょうか??

グリッドの指定が独特ですので、「GRID GARDEN」というゲームを触りつつ、慣れてみるものありかもしれません。

対応ブラウザについて

https://caniuse.com/#feat=css-grid
Edgeも対応され、これから徐々にグリッドレイアウトのサイトが増えてくるかもしれませんね。

次回は、具体的レイアウトを元に使い方をお伝えしようと思います。

今年も大阪の街を駆け抜けました

こんにちわ。
リエです。
 
11月26日は第7回大阪マラソンマラソンでした。
昨年大阪マラソンのチャレンジランを走ったというブログを書きましたが、

大阪マラソンエントリー~出場までの道のり


 
なんと今年もエントリーしたら運よく当選しました。
たくさんの方がエントリーする中で、2年連続当選するとはとてもラッキーなことだと思います。
神様ありがとう。
 
ただ、わたくし日常的に運動しない人間でして、走るのもそんなに得意ではないという。。
前回のチャレンジランからお恥ずかしいことに全く走っていませんでした。
 
練習しなきゃ〜と思っているうちに、月日は流れ、あれ?今日マラソン当日じゃない?となりました。
冗談抜きで全く練習していない(-_-;)
※ケガの元となるので、練習無しでのマラソン参加は大変危険です。
絶対にマネしないでください。(誰もマネしないか。。)
 
不安しかない中でマラソンはスタートしました。
 
さて、結論をいうと完走できました!
途中歩くこともなく1時間ぐらいで完走できたので、上出来じゃないかな〜と思ったり。
順位はちょうど真ん中ぐらいでした。(995位/1982人中)
 
昨年は1時間以内で走るというのが目標でしたが、今年は制限時間内に走りきるということが目標で、途中歩いても完走することが大事かなと思っていたので、本当によかったと思います。
楽しんで走りきれましたし(*´∀`)♪
 
たくさんの方が応援に来られていて、あたたかい声援をたくさんいただいたおかげで走りきれたと思います。
応援してくださった方、本当にありがとうございました。

感動のゴールの瞬間(下向いてる)
なんかモザイクが不自然ですいません\(^o^)/
 
現在は絶賛筋肉痛中です。
自分の足じゃないみたいです。
 
 
早くこの筋肉痛から開放されないかなと切に願っています。

Laravel 5.1でQueueを使って困ったこと

 

技術系のメモ書き程度のことですが、メール送信処理や時間のかかる処理等をLaravelのQueueを初めて使って困ったところを書いておきます。

結論を先に書くと
1. listenよりworkを使う
2. ドライバーにdatabaseを使う場合は複数立ち上げない

1. listenよりworkを使う

処理の優先順や別々の機能等があり何個かQueue処理を作ってそれぞれlistenで立ち上げていたのですが、複数立ち上げていくとCPU使用率がどんどん上昇してしまい最終的にはちょっと実用に耐えられないぐらい上がってしまいました。

もともとlistenで立ち上げるとCPUを食うことは知っていましたが、listen1つでここまでCPUを使うとは・・・

こちらはlistenからworkに変更することで問題は解決しました。
全然CPUにかかる負担が違う。

2. ドライバーにdatabaseを使う場合は複数立ち上げない

基本的にはSQS等を使えば問題ないとは思いますが、当面は処理量も少なくまたローカル開発環境で手軽に使える為、ドライバーにdatabaseを使用していました。

特に処理も滞りなさそうに動いていたのですが、複数のqueueを立ち上げているとログに不穏なものが・・・

 

Deadlock found when trying to get lock; try restarting transaction

 

調べてみると、どうやらドライバーにdatabaseを使用して複数立ち上げると発生するっぽい。
とりあえず基本的に量が少ないうちだけdatabaseを使用して、処理量が多くなったらSQS等にドライバーを切り替える予定なので、当面は同じQueueについては1つのみ立ち上げる形で運用しています。

 

以上、LaravelでQueueを使って困ったことでした!

 

あとがき
次のLTS出たのでそろそろバージョンを上げたい。
・・・でもそんな時間がまだ取れないorz
いつになるかわかりませんが、5.1から5.5に上げた時に困ったことを記事に書く予定です。

 

読みやすい文章を書く、ちょっとしたコツ

 

こんにちは。
デザイナーのヒロシです。

 

メールやプレゼン資料・オウンドメディア記事の作成など、文章作成は日々の業務に付いてまわるもの。少しでも分かりやすい文章を書きたいものですが、苦手意識を感じる方も多いのではないでしょうか。

 

日本語ってムズカシイ。
かくいう私もそのひとり。

苦手意識をなくすために、今回、このような本を手に取ってみました。

 

新装版 日本語の作文技術
新装版 日本語の作文技術 本多勝一(著)

 

文章作成やライティングなどのキーワードで本を探したりしていると「読まれるため」の方法はよく見受けられます。以下のような感じ。

 

・読み手を意識した主題や構成を考える
・語彙力を豊富にして表現方法を高める
・ブログ記事ならばキーワード選別(SEO対策)etc…

 

それはわかってるんですよね!
私が知りたいのは文をどう書くのか?
どう言葉を回したらいいのかが知りたいんです!

 

なんて時にこちらの本が参考になります。
厳密に言うと、文章の作り方ではなく分かりやすい文の作り方、いわゆる作文の技術になるみたいです。
本記事では、こちらの本から、すぐに使えて効果がありそうなトピックスをひとつご紹介しています。

 

多くの人に読まれる文章を書きたい!記事のPVを上げたい!という方は、他の記事をお探しくださいw

 

かかる言葉と受ける言葉をなるべく近づける

 

当たり前のことなんですけどね。でも、普段から意識してますか?

たったこれだけを意識するだけで見違えるように文章が分かりやすくなります!

例えばこちらの一文。

 

【1. 入れ子のケース】

 

私は小林が中村が鈴木が死んだ現場にいたと証言したのかと思った。(P.42)

 

極端な例です。一読しただけでは分かりませんね。はい。でも文法的には間違っていません。

「私は…思った」の間に、修飾語・被修飾関係にある言葉が何重もの入れ子になっています。

この文を、一切の言葉に変更を加えず、機械的に位置を変えるだけで分かりやすくすることができます。

 

 

このようにかかる言葉(修飾語)と受ける言葉(被修飾語)を近づけることでぐっとわかりやすくなります。

 

【2. かかる言葉があいまいのケース】

 

とても美人だとは言えない(P.40)

 

第一感としては特に問題のなさそうな文ですが。。。

 

これは「到底、美人であるとは言えたものではない」の意味と「非常に美人だ、とは言えない」の二つの意味に捉えることができてしまい、文法的にあいまいさが見受けられます。
もし文を直すなら、「非常に」の意味であると捉えて(普通に考えると、「到底」の意味であればこのような文にはなりにくい)…

 

美人だとはとても言えない(P.40)

 

「とても」を「言えない」と近づければ明瞭な文になります。

 

このように、文章を読んでいて一読しても分かりにくい、なんだか引っかかるという場合の多くは修飾語と被修飾語のいち関係が問題だったりします。

 

【3. 複合の場合】

 

二日未明、東京都三鷹市のマンションで、部屋に充満していたプロパンガスが爆発して四人が重傷、三十二人が飛び散ったガラスの破片などで一〜二週間のけがをした。(『朝日新聞』1974年10月2日 夕刊9ページ)| (P.45)

 

特別わかりにくい文ではありませんが、それでも「三十二人が飛び散った…」のところは一瞬引っかかりがあります。まるで人間が飛び散ったかのように捉えることもできる。「三十二人」が実は「一〜二週間のけがをした」にかかっていることを理解するのには、瞬間にせよ途中で読みかえす必要があります。

 

これを抵抗なく読めるようにするために修飾語の位置関係を調整してみます。

 

…四人が重傷、飛び散ったガラスの破片などで三十二人が一〜二週間のけがをした。 (P.45)

 

としてみました。しかし、「一〜二週間のけが」をした人はガラスの破片によるものですが、重傷の四人は何によるものかは明確になっていません。爆風とも考えられますが、「ガラスの破片など」というのだから、「ガラスの破片などで」は重傷者も修飾すべきと考えます。

 

…プロパンガスが爆発して、飛び散ったガラスの破片などで四人が重傷、三十二人が一〜二週間のけがをした。 (P.46)

 

いかがでしょうか?かかる言葉と受ける言葉の位置で読みやすさや受け取る意味の明瞭さが変わることが理解いただけたかと思います。

 

 

 

新聞の社会面トップ記事でもこのようなことがあります(文字制限の関係もあるかと思いますが。。)。ちょっとしたことで随分と分かりやすさが変わってくるので、文章を作成する際、読む際にも十分気をつけていきたいですね。

 

今回、紹介しました「日本語の作文技術」では、修飾語の位置以外にも「テニヲハ」の使い方など、明確な作文技法やルールが述べられていますので、文章作成に苦手意識のある方はご一読してみてはどうでしょうか。

 

また機会があれば、修飾する順番や句読点の打ち方など紹介したいと思います。