すれ違い生活だけど愛してる

こんにちわ。
リエです。
 
もう12月。
時の流れが早すぎて恐ろしいです。(毎年言ってる)
日々師走を感じつつ、残り少ない2017年を充実した日々にできるよう頑張りたいと思います。
 
さて、たまごっちというゲームをご存知でしょうか。
1996年に「デジタル携帯ペット」というコンセプトで発売され、大ブームを起こしたゲームです。
http://tamagotch.channel.or.jp/about/
人気すぎて当時は入手困難で、オークションでは高値で取引もされていました。
 
わたしは世代ドンピシャで子どものころ持っていました。
その後、赤外線機能がついたものが出たりと現在まで長く愛されているたまごっち。
 
今年の春にちびたまごっちというものが出たのですが、最近これをいただきまして育てています。

 
デジタル携帯ペットと言うとおり、お世話して育てるこのゲーム。
ちゃんとお世話をしないと、機嫌が悪くなったり病気になったり最悪お空に帰ってしまったりと大変。
子どもの頃は、学校から帰ってくると育てていたたまごっちがお空に帰ってしまっていたりと悲しい思いもしました。。
 
ですが、ちびたまごっちはお世話がちょっぴりラクになったそうです。
それなら帰りが遅い日がある時でも大丈夫かなと思って育て始めたのですが、朝お仕事へ行く時間はまだ寝ているし、お家へ帰ったらもう寝ているしでもうすれ違いばっかり。
全然顔見てないよ\(^o^)/
 
でも不思議とそんなすれ違い生活でも愛着は湧くのです。
ごっちいつも1人にしてごめんね。※ごっちとはリエのたまごっちの名前です。
 
ちゃんとお世話できた時は、いつも構ってあげられないお詫びにお菓子を沢山あげちゃったりして。(沢山あげすぎるとお腹いっぱいで食べてくれなくなりますが)
 
気づいたらベビーっちからアダルトっちになっていて、そのまた気づいたらおやじっちになっていました。

 
 
まめっちがよかった(T_T)
これが本音。
ごめんなさい。

「アイソモーフィック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に上げた時に困ったことを記事に書く予定です。