低スペック環境の定義

厳密な低スペックの定義など無いのですが、今回は仮に以下を低スペックと定義します。

• ストレージがSSDではない。
• メモリが16G以下である。
• モニタが24インチ以下である。
• ネットワークの回線が貧弱である。
• 無線LANがプツプツ途切れる。
• 机にパーティションが無い。

SSDでないことによる弊害

OSの起動やアプリケーションの起動などが非常に遅いので、「ま〜だ起動終わりませんかね〜？」と、「ボーッと画面を眺める時間が増える」ことになります。これが非常に勿体無い。

ボーッと眺めている間に別の作業をしたら？と考えると思いますが、別の作業をすることで更に負荷がかかり、トータルすると個別に処理が完了するのを待つ時間よりも多くの時間がかかってしまう事になりかねません。そうすると、すこしでも生産性を上げようとしたことが逆に生産性を下げる原因になってしまうことさえあります。

SSDの性能ですが、最近のSSDは昔のSSDのようにプチフリしたり寿命が極端に短い事も少ないし、読み込み・書き込み速度も飛躍的に向上しているので、快適になることは間違いありません。

メモリが16G以下であることの弊害

8Gで十分じゃない？という環境もあるかもしれませんが、8Gって結構ギリギリだと感じています。IDEやアプリケーションサーバに少し多くメモリを割り振ったら使い切ってしまうくらいの容量です。最低16Gあれば、プログラマが色々な事にチャレンジする事ができると思います。

例えば、ローカルでDockerやVagrantで仮想環境を構築しようとすると、それだけでドカッとメモリが奪われます。一番最悪なのは、「DockerやVagrantを使いたい。でもメモリが足りなくてそれができない。だから新規案件でもDockerやVagrantを採用しにくい。」という事が起きてしまう事です。

「メモリが少ないという理由で生産性や利便性を向上するための手段が奪われ、可能性が潰されている。」というのは最悪極まりないですね。こういう状況に置かれている人って、結構いるのではないかと想像しています。声を上げないだけで、潜在的には沢山いそうに思えます。

他にも、macを使っている方で、ローカルでVirtualboxやVMWareFusionで、modern.IEの仮想イメージを使ってIEやEdgeで動作確認したい、でもメモリが足りなくてそれができない、という例もあります。
Free Virtual Machines from IE8 to MS Edge - Microsoft Edge Development
modern.IEは割り当てるメモリ容量が仮想環境上のOSのパフォーマンスにダイレクトに影響するので、2G程度の割当ではWin10の起動時間にかなり時間がかかってしまうので、最低4Gのメモリを割り当てたいところです。

モニタが24インチ以下であることの弊害

画面が狭いと表示できる情報が減るので、Control + tab等でのウインドウの切り替えの回数が増えます。一瞬で切り替わるじゃん？と考えると思いますが、問題なのはその回数です。塵も積もれば山となります。1回の動作が数秒だとしても、それが数千・数万回行われれば、それなりの時間の浪費になります。

また、ブラウザ＋開発者ツール、タブ分割したターミナル、slackやhipchat等のチャットアプリ、など、ウインドウの切り替え無しで全ての情報が閲覧可能な状態にあると、生産性が向上しやすくなっています。

ネットワークの回線が貧弱であることの弊害

ファイルのダウンロード速度や、アップロード速度が低いと、やはり待ち時間が増えてしまうので、ボーッと眺める時間が増えます。

それが社内だけでの話で収まるならいいのですが、社外に及ぶと最悪です。例えば「社内にビルドサーバがあって、そこから本番環境やS3等にファイルをアップロードする」という場合は、社内からインターネットへのアップロード速度が遅いと、デプロイする時間に影響します。お客さんから「なんかデプロイ時間長くない？何にそんな時間かかってるの？」と言われてしまった時に、「いや〜、実は転送速度がくっそ遅くて、デプロイ時間の95%は転送時間なんですよね〜 hahaha !!」なんていったら大変なことになってしまうでしょう。

無線LANがプツプツ途切れることの弊害

これはストレス溜まりますね。

気持ちよく開発しているかと思ったら、プツッ。

無線LANがプツッっと途切れると、プログラマの集中もそこでプツッと途切れます。

有線LAN最強説を唱えたいところですが、ケーブルに足を引っ掛けたりする可能性が無いとはいえないし、物理的にモノが減った方が管理するモノが減って皆嬉しくなるように思えます。

机にパーティションが無いことの弊害

よく「パーティションが無い方が周りとコミュニケーションが取りやすい」と言う方がいますが、私の個人的な意見を言うと、「左右にパーティションは無くてもいいけど、正面にはあって欲しい」と思っています。正面の人や斜めの人達と視線があったりする事が非常に嫌だし、想像以上に集中力に影響を与えます。左右はなかなか視線が合うものでもないし、隣の人とは体の向きを変えて直接口頭で話す機会は沢山ありますね。

例えば、↓この環境で1,2の人達が3,4の人達と話そうとするのではなく、

↓3,4の人は5,6の人と話す事になるような座席にすると、視線云々で集中力が途切れる事も減りそうなんですが、どうですかね。

//////////////////　← パーティション

//////////////////　← パーティション

確証は無いのですが、ネット上にはパーティションが無い職場は生産性が落ちる傾向がある、といった情報を沢山見るし、私自身も前の席の人達と視線が合うと嫌ですね。今の環境がパーティションが無くて、どうしてもパーティションが作れない場合は27インチディスプレイ等をパーティションの代用とするしかなさそうです。

なぜNightwatchなのか

沢山あるE2Eテストフレームワークの中で今回Nightwatchを選択したのですが、理由は以下の通りです。

• javascriptでテストを記述できること。
• 使い方が簡単であること。
• 環境構築が楽であること。
• 単独で動くこと。
• assertの仕組みが内蔵されていること。
• 高機能でなくていいので、コード記述量が少なく済むこと。

ざっくり言うと、「簡単に環境構築できて、簡単に動作すること」です。

まず、記述言語はjavascriptに限定しました。以前業務でjava + selenium webdriverでゴリゴリしていましたが、辛いです。あれは辛いです。いちいちコンパイルが必要だったり、環境面も優しくありませんでした。もっとカジュアルに記述できて、コンパイル無しで動くものにしました。

Protractorもいい感じに見えたのですが、Angular.jsのために作られたものだそうで、個人的には特定のFWに依存していたりする事が嫌だったのと、nightwatchと比較するとコード記述料が多いため、見送りました。

nightwatchであれば、nightwatch本体もchromeドライバーもfirefoxドライバーもselenium-standaloneも、全て「npm install」一発で環境を用意する事ができます。テストもjsでさっくり記述でき、コンパイル無しで即実行可能なので、相当楽に動かす事ができます。

docker

docker for mac か docker for windowsをインストールして下さい。

[mac] https://docs.docker.com/docker-for-mac/

[windows] https://docs.docker.com/docker-for-windows/

node.js

macならnodebrew、windowsならnodist等を使い、node.jsをインストールして下さい。

nodebrew install-binary v7.2.0
nodebrew use v7.2.0
nodebrew alias default v7.2.0

nodeist stable v7.2.0
nodeist use v7.2.0
nodeist alias default v7.2.0

dockerコンテナ

最初はmac上でdocker-machineを使わずにdocker-compose upしてみたのですが、以下のように127エラーが起きてしまいました。linux（Amazon linux）上ではdocker-machine無しで上手くいきました。

tree:test tree$ docker-compose ps
                 Name                             Command             State          Ports
------------------------------------------------------------------------------------------------------
seleniumgridnightwatchexample_chrome_1    /opt/bin/entry_point.sh   Exit 127
seleniumgridnightwatchexample_firefox_1   /opt/bin/entry_point.sh   Exit 127
seleniumgridnightwatchexample_hub_1       /opt/bin/entry_point.sh   Up         0.0.0.0:4444->4444/tcp

エラーが出てしまうので、ちょっと嫌ですがdocker-machineで専用ホストを作成します。

$ docker-machine create -d virtualbox selenium
$ eval$(docker-machine env selenium)

vmwarefusionを持っている場合、-dの引数を「vmwarefusion」に変えて下さい。vmwarefusionの方が1.5倍程高速です。

git clone

例によって既にすぐテストできるプロジェクト一式をgithubにアップしています。

git clone https://github.com/treetips/selenium-grid-nightwatch-example.git

github.com

node_moduleの依存

package.jsonを用意してあるので、以下のコマンド一発で依存モジュール類が揃います。今回はnightwatchはglobalにインストールせず、ローカルにインストールする形にしました。

$ npm install

nightwatchの設定

nightwatch.conf.jsを開き、「selenium_host」にdockerのホストを設定して下さい。ホストは以下のコマンド確認することができます。

tree:selenium-grid-nightwatch-example tree$ docker-machine ip selenium
172.16.53.136

docker-hub

docker-hubのイメージを使用するので、アカウントが無い方はアカウントを作成して下さい。
https://hub.docker.com/

続いて、初回docker pull実行時はログインを求められるので、先に以下のようにdocker loginでログインしておきます。

tree:test tree$ docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.Username (treetips): treetipsPassword:Login Succeeded

ログインが成功すると、認証情報が以下の場所に保存され、以降はdocker loginは不要になります。

tree:test tree$ ll ~/.docker/config.json
-rw-------  1 tree  staff   188B 112319:48 /Users/tree/.docker/config.json

ローカルでテストする場合

ローカルの場合はいちいちVNC経由で動作を確認したくないので、selenium-standaloneを使ってローカルにインストールされたchrome,firefoxを直接実行したいですね。

そういう場合は以下のように実行して下さい。

$ npm run local

もしchrome、firefoxを単独で実行したい場合は以下のようにして下さい。

# test for chrome
$ npm run local-chrome

# test for firefox
$ npm run local-firefox

Selenium Gridで並列テストする場合

Selenium Gridを使って並列で一気にテストする場合は以下のようにして下さい。

$ docker-compose up -d

Nighwatchを実行する

$ npm run grid

これで、Docker上のSelenium Gridに対して、chromeとfirefoxのブラウザテストを並列実行する事ができます。

Seleniumの実行状況をVNCで確認する

ローカルの場合はローカルにインストールされたchromeとfirefoxが起動するので、実行している様子を確認する事ができました。しかしSelenium Gridの場合は、linux等のサーバ上のchrome・firefoxが起動されます。サーバ側で実行されているchromeとfirefoxを閲覧するため、VNCを利用します。

幸い今回使用するchromeとfirefoxのdockerイメージは、最初からVNCサーバがインストールされているものを使っているので、VNCクライアントさえあればすぐ確認できます。

macの場合は、Finder ->メニューバーの「移動」 ->「サーバに接続」をクリックすると、以下のように表示されます。

テキストボックスに以下の2つをそれぞれ入力し、接続先を追加します。
vnc://${dockerホスト}:4501 (firefox用)
vnc://${dockerホスト}:4502 (chrome用)
（4501, 4502は、docker-compose.ymlのports要素で指定しています）

接続ボタンをクリックするとパスワードが聞かれます。パスワードは「secret」です。

起動すると、以下のように表示されます。この状態でnightwatchでテストを実行すると、ここにブラウザが表示され、画面遷移する様子が視覚的に確認できます。

実際にnightwatchを実行し、VNCでそれを確認した様子は↓こんな感じです。

コンソールには、以下のようにカラフルに結果が表示されます。

VNCクライアントを2つ（firefox用とchrome用）起動しておけば、両方同時に確認する事ができます。

もしnightwatchの実行時にエラーが発生した場合は、「selenium-grid-nightwatch-example/screenshots/test/Display-yahoo-->-search-->-assert_FAILED_Nov-24-2016-004001-GMT+0900.png」のようにスクリーンショットが保存されます。

修正対象ファイル

$APPENGINE_HOME/google/appengine/tools/devappserver2/mtime_file_watcher.py

修正前

for dirname, dirnames, filenames in os.walk(self._directory,
                                                followlinks=True):

      if self._quit_event.is_set():

修正後

for dirname, dirnames, filenames in os.walk(self._directory,
                                                followlinks=True):

      if'/node_modules/'in dirname: continueif self._quit_event.is_set():

これでnode_modulesフォルダの監視がスキップされ、次回goapp serveした際に警告が表示されなくなります。

もしnode_modules以外で同様の現象が起きてしまう場合、or句で複数条件を記述して下さい。

FF13の場合

本体4000000台 ÷ ソフト1516532本 = 2.63
本体所有者のうち、2.63人に1人はFF13を購入しています。

FF15の場合

本体3500000台 ÷ ソフト690471本 = 5.06
本体所有者のうち、5.06人に1人しかFF15を購入していません。

単純計算すると、FF15はFF13と比較して、2倍買われなくなった事になってしまいますね。これは結構厳しい結果です。本体を持っているにも関わらず、購入に至らないケースが増加してしまっています。

キャラクター面

• 黒尽くめのホスト集団に感情移入できなかった。
• ホスト達がチャラ過ぎた。
• ホスト達の会話が寒すぎた。
• キャラクターが喋ることに違和感を感じた。
• キャラクターと声優のミスマッチを感じた。
• リアル過ぎて違和感を感じた。
• 腐女子向け？と嫌悪感を感じた。

ストーリー・システム面

• ストーリーが良くなかった。
• ゲームシステムが良くなかった。
• オープンワールドを活かせてなかった。
• やりこみ要素が少なすぎ・多すぎた。
• バグが多すぎた。
• FF13のせいでFFブランドのイメージが損なわれた。

ハード・ソフト面

• 発売されるのが遅すぎて興味が薄れた。
• ソフトの価格が高かった。
• PS4を持っていなかった。
• もう据置型ゲームの時代ではないと思ったから。

ユーザ層

• 小中高大学生がPS4を購入していないから。
• デカイ据え置き機を所有する事が恥ずかしいから。
• スマホゲーに夢中だから。
• 映画のような映像クオリティは求めてないから。

間違っているものも多々あると思いますが、ざっとこんな感じの事が想像できます。

本体販売数はFF13とFF15で大きな違いはないのに69万本しか売れなかった、さて、本当の原因は一体何なのでしょうね。FFシリーズはPlaystationの代名詞とも言えるタイトルで、売上も1、2を争うものなので、FF15が69万本となると、PS4は頑張っても初週69万本しか売れません、という事に繋がりかねませんね。

PS4の限界はここまで、という事にならないように、原因の究明などを頑張って欲しいですね。（なんだかバグの調査みたい・・・・）

FF1

社会人になってからPS VITAでプレイ。普通に1回クリアして、目茶苦茶簡単だなあと思いました。

FF2

小学生のころにプレイ。パンデモニウムが突破できませんでした。デスライダー＋ミスリルゴーレムの悪夢が蘇る・・

その後社会人になってPS VITAで再度プレイ。簡単でした。HPも敵の攻撃力も100倍くらいあってもいいと思いました。最終的にアルテマ16にするくらいまではやりました。

FF3

小学生の頃にプレイ。その時点で結構簡単にクリアできました。

その後社会人になってPS VITAで3D版のものをプレー。やはり簡単でした。その時の感想とか雑感は以下に書きました。鉄巨人は撃破しています。
www.bunkei-programmer.net

FF4

小学生の頃にプレイ。音質がやたら良かったのを覚えています。最終ダンジョン以外は簡単でした。

その後社会人になってDS版をプレイ。今までとは異次元な難しさに驚愕しつつ、難しくて逆に非常に楽しめました。個人的にはあれくらい難しいのが標準でもいいですね。フレイムドッグのほのおで壊滅寸前に追い込まれたり、透過レーザーで全滅するなんて、もう最高ですね。

さらにその後、ff4 complete collectionを購入し、隠しダンジョンを全て攻略するくらいはやりました。

ちなみにサウンド面がやたら良かったのは、裏話があるのです。
www.famitsu.com

FF4 the after years

社会人になってPS VITAでプレイ。忍者編がちょっときつかったくらいで、特に印象に残っていません。しっぽは数種類集めて満足して終了しました。

FF5

中学生くらいの時にプレイ。全ジョブマスターするくらいはやりました。まあまあ面白かったです。ゲームシステムが良かったためか、今でもやり込む人は多いですね。

FF6

中学生くらいの時にプレイ。この頃から私のFFに対する印象がちょっと変わりました。恐らく今までのFFと画風がちょっと変わったから？なのかもしれません。

FF7

高校生の時に友達に借りてプレイ。この頃から以下が進行していきました。

• ダメージの強烈なインフレ
• 召喚獣の演出の長期化
• ディスク枚数の増加(FF7は4枚組）
• サブクエスト（進行に直接関連の無い寄り道イベント）の増加

ナイツオブラウンドとか超究武神覇斬とか、もうなんだこれ、という感じですね。しかもナイツオブラウンドなんて1分40秒くらいじっと見ていないといけないほど長いです。

今見ると酷いグラフィックですが、当時は革新的に見えました。FF6からいきなりあのグラフィックでしたからね。ストーリーも以外とちゃんとしていたし、敵・味方共にキャラクターも魅力的でした。旧作のFFとはいい意味で一線を画するものだと思えました。FF6 -> FF7は恐らくFF史上最大の革新があったのではないでしょうか。

FF8

未プレイです。個人的にリアル路線のキャラクターに魅力を感じなかったのと、戦闘システムが激変してしまった事が原因で、やる気がおきませんでした。今もやりたいとは思いません。

FF9

FF8の印象が悪かったので、未プレイです。しかし後から見返すと、キャラクターがFF8のリアル路線からデフォルメ路線に戻ったので、ニコニコ動画でプレー動画を全てみました。が、ボスキャラがあまりにも魔道士だらけで「あれ・・？」と違和感を覚えたのと、シリーズ屈指のロード時間の長さに閉口しました。

FF10

ここからPS2です。一気にグラフィック・サウンド共に向上しました。

大学生の頃に友達に借りてプレイしました。プレイ当初はキャラが喋りまくる事に違和感を感じましたが、ティーダがアホキャラだったせいか、あの見た目でも違和感なく楽しめたと思います。

オーケストラ調のBGMなど格好いいBGMが増え、ビジュアル面も演出が格好よくなりました。キャラチェンジ等、戦闘システム面でも色々なキャラを使う（使わざるを得ない場面もあり）機会がありました。

最終的には限界突破という、ダメージが9999以上になる新しい概念の登場により、FF7とは比較にならないダメージの爆発的なインフレを生み、HPが1千万もある隠しボスが登場したりもしましたが、やりこみ要素も多く、中々楽しめました。

以降のFF

全くやっていません。

FF4 DS版

FF4のDS版はあの難易度が非常によかったです。FFシリーズはほとんどが低難易度で、町から次の町へ行くのに対して装備を整えなくても楽勝、ボスも弱い、というのが通例なのですが、FF4 DS版だけは別格です。

突如現れた雑魚敵フレイムドッグにほのおで全員7割以上削られ、キマイラのブレイズで焼かれ、フリーズビーストに凍らされ、レッドドラゴンの熱線で焼かれ、ルゲイエのリバースガスで初見殺しされ、防衛システムの透過レーザーでオーバーキルされ、超強化されたミジンコのビッグバーンで壊滅し、散々な目にあいます。

だがそれが面白い。そこを攻略するのが楽しいのです。変態マントの紳士に盗むで火炎竜を阻止したり、対策して完封したりする過程が楽しいのです。（ぶっちゃけデカントという新システムのおかげで結構簡単に攻略できます）最近のユーザは難しい事を好まず、ほぼ何も考えずにボタンをポンポン押すだけでストーリーが進んでしまうような低難易度化が進行していて、とても受け入れられないでしょうね。（ダークソウル等の難しいゲームがヒットする事例もありますが）

私は基本的に難しいゲームが好きなのです！

FF10

キャラもストーリーも中々総合的に楽しめます。

FF2

完全に思い出補正ですが、FF2ってなんか何回もやりたくなってしまうのですよね。ストーリーも長くないし、攻略法も解りきっているので、魔法縛りとか、ついついやってしまいたくなります。

目標

• GAEを使う。
• 独自ドメインを適用する。
• 独自ドメインに対してLet's encryptでSSL証明書を発行し、適用する。

前知識

現在のGCPでは、リージョン変更は簡単に行えません。

新たに東京リージョンで新規プロジェクトを作成し、そちらにリクエストが向くよう変更しないといけません。

しかし、その手間をかけてでもリージョン変更する価値はあります。

リージョンが選択できない場合は新規にgoogleアカウントを作成する

早速ですが、注意点があります。

私がGAEのアカウントを作成した際は、今のGoogle Cloud Platformの管理画面ではなく、以下のような古い管理画面でした。

この時期に作った古いアカウントのせいか、Google Cloud Platformの管理画面で新しいプロジェクトを作成しようとしても、以下のようにリージョンが選択できませんでした。

Googleのサービスは往々にしてこういったこと（アカウント作成時期により機能が限定される）があるので、ここは素直に新規にGoogleアカウントを作成する事で、以下のようにリージョンの変更が可能な状態になりました。

新規GCPプロジェクトを作成する

GCP管理画面を開き、メニューの左上の部分を選択し、プロジェクトを作成します。

作成するプロジェクト名は、移行前のus-centralで作ったプロジェクト名と同一で問題ありません。ここで旧アカウントのユーザは馴染みが無い事が起こります。

昔のプロジェクト作成時はプロジェクト名＝プロジェクトIDだったのですが、今は異なります。プロジェクト名を入力すると、ユニークなプロジェクトIDが自動で振られます。デプロイする際のプロジェクトIDは、これを入力する必要があります。

GCPプロジェクトを作成後、GCP管理画面の左上のハンバーガーメニューからGAEを選択し、GAEプロジェクトを作成します。ここで何やら見慣れないチュートリアルを強制されますが、頑張って下さい。。。チュートリアルでは、Google Cloud Shell上でgitでサンプルをcloneしてデプロイするデモを体験できます。最終的に何らかのプロジェクトをデプロイし、ブラウザで確認できる状態にして下さい。

チュートリアル完了後、めでたく見慣れたGAEのダッシュボードを拝む事ができます。ここまでできれば後はこの新アカウント・新プロジェクトIDに向けてデプロイしていきます。

EclipseのGoogleログインのユーザを変更する

Quick Start  |  Google Plugin for Eclipse  |  Google Developers
上記のpluginを使っている場合のお話ですが、今回Googleアカウントを新規に作成したので、以前まで使っていたアカウントでログインしている状態になっているかと思います。従って、まずデプロイの向き先（Googleアカウント）を変える必要があります。向き先の変え方ですが、ちょっと解りにくいのですが、Eclipseの右下から変更可能です。

デプロイ先のプロジェクトIDの切り替え

デプロイの向き先のgoogleアカウントは変更できました。次はどのプロジェクトにデプロイするかの指定、プロジェクトIDを変更します。前項で確認したプロジェクトIDを、以下に入力して保存します。

これでデプロイ準備完了です！

デプロイする

eclipseプロジェクトを右クリック -> Google -> Deploy to App Engine でいつものようにデプロイしましょう。これで新アカウント・新プロジェクトに向けてデプロイできます。

デプロイは完了してブラウザからも画面表示を確認できますが、独自ドメインからのアクセスは以下のようになっているので、まだユーザは旧サイトを閲覧している状態です。

リクエスト -> www.tree-maps.com(独自ドメイン) -> GAEの旧プロジェクト

旧アカウントのGAEプロジェクトのカスタムドメインを削除する

www.tree-maps.comからのリクエストを、このGoogleアカウントのこのGAEプロジェクトにプロキシするぞ〜、という設定が残ったままなので、これを削除します。

新アカウントで再びカスタムドメインを登録する

新アカウントにはまだ独自ドメインが登録されていない状態なので、ざっくり以下のような感じで登録していきます。旧アカウント作成時に行った作業と全く同じですね。

tree-maps.comでドメイン追加し、tree-maps.comに対するエイリアスとしてwww.tree-maps.comを設定します。途中でドメインの所有権の確認が入るので、レジストラ側のTXTレコードに、指定された値を入力して保存し、TXTレコードの反映を待った後、ドメイン所有権の確認を通過させます。所有権が確認できた後、そのままウィザード通りに選択し、カスタムドメイン定義が完了します。

ここで「Aレコード、AAAAレコード、CNAMEレコードをこう設定しろ」という指示が表示されますが、これは旧アカウントで既にレジストラに入力したものと全く同じなので、レジストラ側の変更は不要です。レジストラ側の変更は、所有権確認のTXTレコードの追加のみです。

SSL証明書の反映

私の場合は旧アカウントで作成してあったLet's encryptのSSL証明書定義が既にあったのでそれを新プロジェクトに反映するだけでした。もし証明書が無ければ、以下の記事を参考にSSL証明を作成して反映して下さい。

www.bunkei-programmer.net

トラフィック割当の変更

GAEのチュートリアルでデプロイしたプロジェクトがデフォルトとして登録されてしまっています。

GCP管理画面 -> GAE ->バージョン と選択し、トラフィックを移行し、チュートリアルプロジェクトに向いているのを、新サイトの方に向き先を変えます。向き先変更後、チュートリアルのバージョンを削除してしまいましょう。

移行完了

おめでとうございます！これで移行完了です！

今回は個人サイトだったのでサイト停止時間はあまり気にしませんでしたが、事前にSSL証明書だけ新アカウントに登録しておいたりし、停止時間を減らす事は可能だと思います。

chrome上で計測

東京リージョン＋GAE/GOの驚異的な潜在能力

上記環境でjsonpをシンプルに返却するURLを用意し、計測した結果は以下の通りです。

・・・・んん？？見間違いかな？

なんか 19msとかいうトチ狂った数値が見えますね。これは驚異的な速度ですね！これがGAEの真の力なのだ・・・！！

ページ数を減らす施策

タイトルがどうとか、キーワードがどうとか、まあ確かにSEOの施策として存在します。

しかし業務で開発するサイトでは、コンテンツ量を調整する類の施策の方が重要度が高い気がしています。それは何故か。答えは「ページ数が多過ぎるから」です。業務サイトはほとんどが動的なサイトなので、検索条件を組み合わせると、簡単に数千万URLできてしまいます。多言語化すると、更に数倍になります。

検索エンジンも馬鹿ではないので、「このページとあのページは恐らく同じ」という事を察知して、本当にユニークになるコンテンツを検索結果として表示しようと努力します。しかしそれにも限界があるので、canonicalタグでページをまとめたり、alternateタグで多言語を調整・誘導したり、コンテンツ量の少ないページをnoindexしたり、GETだったページをPOSTにしてURLパラメータを除去したり、明示的に検索エンジンにそういった命令をし、ページ量を調整します。

ページ量を調整する施策をしないと、検索エンジン側で頑張ってページ内容を把握しようと頑張っても、その量が多すぎるが故、コンテンツが正しく認識される時間が遅くなってしまいます。なので、できるだけ不用意なインデックス化は避け、必要なページを必要なだけインデックスさせるような事を行います。

勿論某キュレーションサイトみたいなものはNGで、真実に基いた記事で検閲されたものが公開されないといけません。

ページ数を増やす施策

S3やFTPやSSIを使い、開発会社以外が自由にサイトにコンテンツを追加可能にできる仕組みを構築し、更にそれらコンテンツのURLを自由に設定できる施策なんかもよくあります。（格安の）ページ制作会社にページの制作を発注し、大量に追加コンテンツを作って貰う感じです。その際にページのヘッダー・フッターの共通化等でSSIを使ったり、何らかのテンプレート化をする事もあったりします。

他にも、開発会社が異なる複数のサイトを統合する事になり、ドメイン統合作業が発生する事もあります。各社でURLが被らないようにうまくディレクトリを調節し、且つドメイン統合の影響を最小限に抑えるため、リバースプロキシで頑張って統合するケースも多々あります。

最近ではスマホに力を入れだしているので、ドメインを統合しつつUAでスマホサイトにリダイレクト、しかもPCサイトとSPサイトでURLが異なるのに頑張ってURL変換してSPサイトにリダイレクトするなんて力技もあります。（これは地獄なのでできればやりたくない施策です・・・）

圧倒的物量で押す

大体業務で行うSEO施策はこんな感じのものが多いです。確かにタイトルタグやdescriptionの精度を上げるような、よくはてなブログに上がる経験に基づいたSEO施策TIPS記事みたいな事もやるのですが、そんなに沢山やりません。本当は凄く大事な事なのですけどね。

実際はそういった細かな調整よりも、重複しないページ・コンテンツをドカーンと増やす施策の方が結果が出る場合が多いようです。これが良い事なのか悪い事なのか、正直どっちも当たっていると思うので何とも言えません。

各社のブログは最初からある程度SEOが考えられている

もちろんフルスクラッチで開発する業務サイト程の自由度はブログには無いので、「ある程度の施策」です。私ははてなブログを使っているのではてなブログの事しか言えませんが、各種SNS連携も設定一つで簡単にできるし、自動的にはてなコミュニティに記事が拡散します。

たかがSNS連携だって、OGPに関するタグをツラツラと、しかもfacebookやtwitterで内容が異なるようなタグも自動で設定してくれているのです。普通にこれをスクラッチしようとすると結構面倒です。各社の対応OGPを調べて実装する必要があるし、テストするのも大変です。

ユーザビリティとか

サイトのテンプレートも用意され、しかもレスポンシブ対応やモバイル特化のテンプレートも存在し、それもテーマを選ぶだけで簡単に行えます。最初からユーザビリティを考慮したサイト設計がなされたテーマもあるので、単にテーマを適用するだけで、ある程度のユーザビリティを獲得する事ができます。

勿論ユーザビリティと言っても、色々な種類のユーザビリティが存在するので、抜けはあるとは思います。

ブログのページ数はどうだろう

大半のブログが1〜2000ページ程度じゃないでしょうか。重複を除外すると500〜1000ページくらいですかね。個人ブログだとそのくらいのページ数しか作れない場合がほとんどです。人間一人が作る記事数には限界があります。

ページ数を考えると、私を含む恐らく素人の経験則に基づいたSEO施策を1000ページに施しても、正直たかが知れています。タイトル調整やキーワード選定やページ更新を頑張る事で、確かに効果は出るとは思いますが、その効果が現れるであろう影響範囲が圧倒的に不足しているように思えます。

繰り返しになりますが、それら施策に意味は絶対に、必ず、100%有ると思っています。が、その影響範囲は小さい、と私は考えています。労力に見合う結果は正直出にくいのではないでしょうか。

最初からブログがある程度のSEO施策を行ってくれているのに加え、SEO業者が組織的に調査したものでもなく個人で調査したレベルの施策になるので、益々その効果は薄くなるように思えます。

SEO施策でライバルに勝てるかもしれないじゃないか

確かに可能性はありますね。キーワード頻出率を計算し、タイトルの左から何文字目までに云々、等をした方がいいかもしれません。が、その程度で他ブロガーに勝てるんですかね。検索エンジンってそんな馬鹿じゃないので、もしライバルに勝っているとしたら、単に内容で勝っているのであって、SEO施策で勝っているわけではないのではないでしょうか。

ちょっとググった程度の施策で勝ってしまう闇の時代は大分前に終了しています。「SEO施策で勝った気になっているだけ」です。本当は内容で勝っているんです。

検索エンジンの目指すところ

検索エンジンは、最終的に自分たちの利益を生み出す事が目的です。利益を多く生み出すには、規模を大きくする必要があります。規模が大きくなると、各種ルールを設定しないと、混沌とし、コントロール不能に陥り、利益予測ができなくなってしまいます。

グーグル等の検索エンジンは、自分たちが最大限力を発揮できるルールを利用者である私達に強います。そうする事で検索エンジンは力を発揮しやすくなり、利益を生み出す事ができ、更に機能追加・改善もしやすくなり、お互いにメリットが生まれます。どんなルールを設定すればいいのかを考える必要がありますが、その時代のトレンドによって姿を変え続け、ルールは日々変わります。

日々細かいルールが変わったり増えたり廃止されたりしていくのですが、それは検索エンジンが主導で行われ、ユーザへの通知無しに変わる事も多々あります。それに頑張って個人が追従しようとするのは、中々厳しいものがあります。

検索エンジン側としては、文字コードが今時SJISだしSEOについて全く何も解っていないけど、非常に良い事を言っている記事を埋もれさせたくありません。そういう記事を拾うことができれば、検索エンジン側の利益にも繋がるし、ユーザ側も検索エンジンに現れやすくなり、お互いにメリットがあります。

検索エンジンはルールを設定してはいますが、ITリテラシーが低いユーザにそれは伝わりません。ユーザ側が自分達の都合の良いルールに従う事を口を開けて待つよりも、自分達でSEO下手な人達が何を伝えようとしているのかを解釈しようと日々努力しています。

その常軌を逸した努力は日々精度を上げていき、徐々に昔流行ったSEO技は駆逐されていき、残ったTIPSは、「良い文章を書きましょう」「インチキしないようにね」「セキュリティ高めようね」等、割りと普通？のTIPSだけになりました。結局健全なWEBが最も自然で扱い易く、検索エンジンにもユーザにもメリットが増えるという事なのでしょうかね。

SEOに明確な答えは無い

SEOの話をすると、必ず根拠の無い、自分の経験則だけのオレオレ持論を持ち出してくる人がいます。そうなってしまうのは、そもそもSEOには答えが無いためです。googleのサイトを見ても、本当に具体的な事は書いてくれず、ちょっと曖昧にかかれています。

これは推測ですが、明確な答えを書いてしまうと、悪用されやすいからだと私は考えています。世の中には検索エンジンを容易に欺く頭脳を持ち、それを悪用しようとする人達が沢山、それはもう沢山います。ほんの少しでも手の内を見せてしまうと、googleでさえ付け込まれます。実際にブラックハットSEOという形で、悪意の歴史は続いていますね。

他にも、敢えて明確に書かない事で、少しだけユーザに自分の頭で物事を考えて欲しい、という側面もあるのかもしれません。ユーザが自立してくれれば、ルールに従わせるのも容易になって検索エンジンの機能・精度の向上がしやすくなり、ユーザ側としても検索エンジンが使いやすくなります。

曖昧な世界で正解を求めて彷徨う

結局検索エンジンを作っている人達しか正解（実装）を知らないので、実はSEO業者がやっている事にも根拠はありません。彼らは検索エンジンの敷いたレール（ルール）に脱線しないように乗り、仮定を作り、実践し、KAIZENしていっているだけです。正解が解らないので、恐らくこれで合っているだろうと仮定して施策しています。

そんな曖昧なSEOの世界で、組織でもなく個人で一人で書いているブログで、明確な根拠もないTIPSに右往左往して振り回されるよりも、適切な言葉で、伝えたい事を伝える事ができる文章を書くよう努力する方が、絶対に精神衛生上良いと思います。

文章力

タイトルの文字数が云々よりも、文章の構成能力を鍛る事を検討すべきです。私は文章の専門家ではないので、どうやったら鍛えられるのかは他サイトを参考にして下さい。起承転結とか、正しい言葉・正しい表現方法・段落などなど、学校で勉強したような事です。

キーワードの選定云々、カテゴリ云々も確かに効果はあるとは思いますが、まずは土台となる文章、伝えたい事を伝えたい人に簡潔に伝える、といった事に纏わる勉強をするべきだと考えています。

現実世界の例を挙げると、パワポのプレゼンを思い浮かべて下さい。あれです。結論が書かれていなかったり、スライドの順番と文章の脈絡がちぐはぐだったり、スライドが長すぎて読む気が起きなかったり、あれですあれ。あれが上手くできる人は、限られた表示領域で、限られた時間で、伝えたい事を伝えたい人に伝える事ができる人です。それと同じ力があれば、ブログは成功し易いと思っています。

レイアウトとかUXとか視線移動とか

ヘッダの位置だとか、ここにこの要素があるとUX的にどうとか、人間の視線移動的に云々とか、スクロール量と視認領域とか、小難しい事はSEO要素として存在します。

完全ではありませんが、これらもある程度テーマが解決してくれます。ユーザは文章だけ書けば、カテゴリリンクの位置はヘッダー・フッター等は自動的に、人間工学に基いて（希望的観測）設計してくれているので、テーマだけ変えればまあまあ対応できたりします。

別にレスポンシブに対応したテーマを選ばなくても、モバイルのサイトはデフォルトで用意されているので、どちらでも構いません。SEOだのUXだのを考えず、自分の好みのテーマを選んじゃって下さい。微妙に気に入らなければ、独自cssで拡張するのもアリです。

画像サイズとか

画像の縦横の大きさは、最近のブログはレスポンシブ対応される場合が多いので、縦横が大きい画像でもまあ大丈夫です。というか、高解像度スマホを考えると、ある程度大きめの方がいいかもしれません。

画像のファイルサイズについては、数メガバイトにもなる画像を作る方が逆に難しいので、そんな心配いらないかあと思います。はてなブログの場合は画像はCDN通っているのでキャッシュされますし。（あまり巨大な画像はそもそもアップロードする時点で弾かれた気がします）

1点気をつけないといけないのは、最近問題になっていますが、著作権ですね。ネットでフリー画像を探す際は、画像の使用許諾・ライセンスを読みましょう。出典を明記してリンクする必要があったり、画像を改変する場合は権利者の許可が必須だったり、何もかも自由だったり、色々ありますので。

揉めるのが怖かったり自信が無ければ、素直にPIXTA等で購入するか、画像ソフトで自分で0から作りましょう。

何故テーマを変更したのか

• 新年になったので、丁度区切りがついた感がある。
• 既存のテーマに飽きた。
• テーマにカスタムcssを適用しすぎて訳が解らないレベルで改造してしまった。
• レスポンシブテーマにしたかった。

最大の理由は「レスポンシブ対応」です。

皆さんご存知の通り、検索エンジンも完全にスマホに舵を取っているので、そろそろレスポンシブ対応しないとな〜、と思い変更しました。レスポンシブにする事で、PC・スマホの両者でhtmlの内容が一致するので、より安全で検索エンジンにも優しくなります。

あと、変更前のテーマをcssであまりにも魔改造してしまっており、もう元のテーマの原型を留めない程にカスタマイズしてしまいました。あまりにもやり過ぎてしまったので、描画が少し重く、カスタマイズcssもあまりもの行数が増えてしまい、cssの修正が大変になっていました。

そこで今回は以下のテーマを適用し、マテリアルデザイン風に少しcssをいじりました。

CONTENTS - テーマ ストア

テーマのカスタマイズで意識したこと

• マテリアルデザイン風にすること。
• ドロップシャドウを画像に適用する。
• 狭すぎるマージンは避ける。
• adsenseは全部レスポンシブにする。
• ごちゃごちゃしすぎないようにする。

こんなところです。このテーマは元々フラットデザインなのですが、やはり個人的にマテリアルデザインのドロップシャドウが好きなので、主に画像に適用してみました。いい感じに立体的になり、おもわずクリックしてみたくなるようにしました。

レスポンシブなので、マージンを多めに取り、スマホからでもリンクやボタンがタップしやすいように、マージンが狭すぎないように、文字が小さすぎないようにしてみました。

キャッチコピー画像

キャッチコピー画像ですが、ドロップシャドウを適用した時に綺麗に見えるように、ちゃんとキャッチコピー画像を作っています。昔の記事はキャッチコピー画像を作っていないので、順次作成していっています。頑張ってPhotoshop Elementsで作成していますが、プログラミングより時間かかりますね。。。

ソースコード

こんなクソコードでいい筈ありませんが、何となくの速度計測はできます。碁盤のように縦横整列した状態でピンが綺麗に生成されます。

縦200個、横300個、合計6万マーカーの生成を行います。

<!doctype html><html><head><metacharset="UTF-8"><style>html{height: 100%;}body{height: 100%;}#map{height: 97%; border: 1pxsolidgray;}</style></head><body><inputtype="button"value="マーカーを追加"id="add-marker"/><inputtype="button"value="マーカーを削除"id="delete-marker"/>　マーカー数=<spanid="marker-num"></span>件　処理時間=<spanid="result">0</span>秒

<divid="map"></div><scriptsrc="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script><scripttype="text/javascript"src="https://maps.google.com/maps/api/js?key=${APIキー}"></script><scripttype="text/javascript">var map = null;var markers = newArray();var ROW_COUNT = 200;var COL_COUNT = 300;$('#marker-num').text(ROW_COUNT * COL_COUNT);google.maps.event.addDomListener(window, 'load', function(){var mapOptions = {        zoom: 8,        center: new google.maps.LatLng(36.72085546100, 141.8274727702),        mapTypeId: google.maps.MapTypeId.ROADMAP,        scaleControl: true};    map = new google.maps.Map(document.getElementById('map'), mapOptions);});$('#add-marker').on('click', function(){var startTime = newDate();for(var row = 0; row < ROW_COUNT; row++){for(var col = 0; col < COL_COUNT; col++){var lat = 35.72085546100 + (row / 100);var lng = 139.0274727702 + (col / 55);var latlng = new google.maps.LatLng(lat, lng);            markers.push(new google.maps.Marker({position: latlng, map: map}));}}    $('#result').text((newDate() - startTime) / 1000);});$('#delete-marker').on('click', function(){    jQuery.each(markers, function(){this.setMap(null);});});</script></body></html>

実行結果

処理時間の計測完了からマーカー表示が遅いですが、これはGoogleMapApiの処理は完了済みだが、マシンが頑張って大量のマーカーをレンダリング（表示）する処理に時間がかかっています。つまり処理自体は高速ですが、マーカーの描画の時間がかかっているわけです。

ソースコード

例によって、こんなクソコードでいいのかは棚上げし、こんな感じで準備しました。

<!DOCTYPE html><html><head><metacharset="UTF-8"><metaname="viewport"content="initial-scale=1.0, user-scalable=no"><style>html,body,#map-canvas{height: 100%;margin: 0px;padding: 0px}</style></head><body><inputtype="button"value="マーカーを追加"id="add-marker" /><inputtype="button"value="マーカーを削除"id="delete-marker" />　処理時間=<spanid="result">0</span>秒

<divid="map-canvas"></div><scriptsrc="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script><scripttype="text/javascript"src="https://maps.googleapis.com/maps/api/js?v=3.exp&key=${APIキー}"></script><scriptsrc="https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.3/d3.min.js"></script><script>var map;google.maps.event.addDomListener(window, 'load', function(){    map = new google.maps.Map(document.getElementById('map-canvas'), {        center: {lat: 36.72085546100, lng: 141.8274727702}, zoom: 8
});});$('#add-marker').on('click', function(){var startTime = newDate();    map.data.loadGeoJson('/assets/html/coordinates.geojson', null, function(features){        $('#result').text((newDate() - startTime) / 1000);});})
</script></body></html>

実行結果

あれ、遅い。。。

GeoJSONファイルのパース処理の時間は追加される筈ですが、パース後は何か特別なマーカー生成をしてくれると期待して、Marker APIより高速になるかも！？なんて思ったらこれです。

件数が少ないのが悪いのかと思って、試しに縦400、横500の計20万件で試したのですが、結果はやはりGeoJSONの方が遅いというか、Marker APIはちゃんとプロットできましたが、GeoJSON APIは500エラーで取り込めず。

GeoJSONはポリゴンとか、マーカー以外の方が強そうなので、マーカー生成は素直にMarker APIでゴリゴリした方がいいのかもしれませんね。

ソースコード

leaflet.jsを使っています。

<!doctype html><html><head><metacharset="UTF-8"><linkrel="stylesheet"href="https://unpkg.com/leaflet@1.0.2/dist/leaflet.css"/><style>html{height: 95%;}body{height: 100%;}#map{height: 97%;border: 1pxsolidgray;}</style></head><body><inputtype="button"value="マーカーを追加"id="add-marker"/><inputtype="button"value="マーカーを削除"id="delete-marker"/>マーカー数=<spanid="marker-num"></span>件　処理時間=<spanid="result">0</span>秒

<divid="map"></div><scriptsrc="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script><scriptsrc="https://unpkg.com/leaflet@1.0.2/dist/leaflet.js"></script><scripttype="text/javascript">var ROW_COUNT = 50;var COL_COUNT = 50;var ZOOM = 10;    $('#marker-num').text(ROW_COUNT * COL_COUNT);var map = L.map('map').setView([36.02085546100, 140.5274727702], ZOOM);    L.tileLayer('http://tile.openstreetmap.jp/{z}/{x}/{y}.png', {            id: 'osmmap',            attribution: '&copy; <a href="http://osm.org/copyright">OpenStreetMap</a> contributors'}).addTo(map);var markers = newArray();    $('#add-marker').on('click', function(){var startTime = newDate();for(var row = 0; row < ROW_COUNT; row++){for(var col = 0; col < COL_COUNT; col++){var lat = 35.72085546100 + (row / 95);var lng = 139.9274727702 + (col / 45);var marker = L.marker([lat, lng]).addTo(map);                markers.push(marker);}}        $('#result').text((newDate() - startTime) / 1000);});    $('#delete-marker').on('click', function(){        jQuery.each(marker, function(){map.removeLayer(marker)});});</script></body></html>

実行結果

うーん、たった2500件なんですけどね。もしかしてleaflet.jsの処理速度が遅いとかですかね？それとも実装の仕方が間違っているとか。

Golangは何を解決したのか

Golang選択の理由は非常にシンプルで、Javaよりも高速で、Javaよりもコンテナのスピンアップ速度が遥かに高速だからです。

どれくらい高速なのかは以前以下の記事を書きましたので、合わせてどうぞ。
www.bunkei-programmer.net

今回Golangをランタイムとして使ってみて、以下の感想を持ちました。

本当はJavaで書きたかったのですが、Javaのスピンアップの速度の遅さが半端ではなく、他のメリットを全て帳消しにする程のものだったので、Golangを採用しました。JavaはIDE支援が超強力なので、目茶苦茶書きやすいのです（完全に個人の主観ではありますが）。

スピンアップが遅いとコンテナが起動するまでの速度が遅い＝画面が表示されるまでが遅いという事になるので、ユーザの離脱率が跳ね上がるわけです。Golangをランタイムにする事で、それを大幅に軽減する事ができます。単純に動作速度もトップクラスの速度なので、Ajaxでjsonを取得するリクエストをガンガン投げても高速にレスポンスを返すこともできます。

スピンアップ・スピンダウンとは

念のため説明しておくと、GAEのインフラは、一定時間サイトにアクセスが無いと、なんと（仮想）サーバが削除されます。これはリソース（物理的なメモリ消費量
ディスク使用量・電力・通信量）を出来る限り節約するためです。このサーバごと削除される事をスピンダウンと言います。

スピンダウンしている状態からサイトにアクセスされると、Google内部ではサーバの構築・アプリケーションやフレームワークの起動が行われます。このGoogle内部のサーバ構築をスピンアップと呼びます。サーバはフルマネージドで恐らくVMWare的な仮想環境上で管理されており、プログラマブルにサーバのインスタンスの生成・削除が行われます。

この考え方は今AWSで流行っているAWS Lambdaと同等です。GAEがアプリケーション単位なのに対し、AWS Lambdaは関数単位という違いはあります。

フレームワーク

実は3回フレームワークを変更しています。Slim3はすぐやめたので実質カウントする必要はないですけどね。

最初はPlayのv1系で頑張ってGAEを開発していたのですが、途中で開発が全くされなくなり、音沙汰もなくなってしまい、終いにはデプロイコマンドが失敗する状態にまでなってしまいました。GAE上でスピンアップからPlayの初期化速度も非常に遅く嫌気が指していたので、デプロイ失敗を機に素のServlet、しかもv2.6系に回帰しました。

Servletに回帰した事でスピンアップ後のアプリの起動完了までの速度は大分速くなりました。が、フレームワークの利便性が無くなり、開発は厳しくなりました。

そしてリニューアルです。使用言語はGoogleのGolangなので、Golangのフレームワークを選定する事になります。前述のスピンアップ速度調査記事ではGin（ジン）を選択していましたが、今回新tree-mapsではecho（エコー）フレームワークを選択しました。

echo選択の理由は、Ginよりも更にシンプルで高速（多分）で、何よりGithub上のコミット数がGinよりも多く、これは開発が活発に行われているな！と確信したので、echoにしました。まあGinもechoも対して機能の違いは無いので、どちらを選んでもいいと思います。

とまあフレームワークのお話をしましたが、正直バックエンド側はルーティング以外何もしていません。。。今回バックエンドが行っているはなんと以下だけです。

• ルーティング
• リダイレクト（実はプロットをprotとtypoしていたのは内緒）
• htmlテンプレート（divが一個あってgooglemapのjsとadsenseのjsをロードする程度）

.goファイルの数はなんと2ファイルだけです。しかもトータルで300行で収まるくらいです。最近の開発ではサーバ側はjson生成器みたいなものなので、これでよいのです。下手にhtml生成をサーバ側で頑張らない方針なのです。

ビルド

単にgoapp deployのみです。変に頑張ってはいません。

カオスを極めるフロントエンド

さて、問題のフロントエンドです。バックエンド重視からフロントエンド重視にトレンドは推移し、未熟極まるフロントエンドがここ数年で常軌を逸した進化をしており、沢山のフレームワークが現れ、あっという間に廃れていきます。それは今も尚続いています。

新tree-mapsではどうしたか

さて、論争を説明したところでようやく本題に戻ります。（それだけフロントエンド界隈が激しいので技術選定も悩みました）

新tree-mapsでは大まかに以下を選定しました。

reacを選択しました。はい。

Angularと迷ったのですが、私が迷っていたタイミングではまだAngular2が正式リリースされておらず、タイミングが微妙だったのと、リリース当初のAngura2は微妙な空気があったので、Reactとなりました。Vue.jsも迷いましたが、会社の業務の採用例的にも今回はReactに軍配が上がりました。reactなので、今回はSPAにしています。

UIについては、最初はFlexboxベースのbulmaを使っていたのですが、欲しいコンポーネントが足りないので見送り、マテリアルデザイン全開で、採用例も多いmaterial-uiにしました。コンポーネントも多く、これは素晴らしいです。

CSSについては、そもそもmaterial-uiがデザインのほとんどを吸収してくれるので、ちょっとしたCSSが書ければ何でもいい、生cssでも全然問題無いのです。まあPostCSSが流行ってきているので、折角なのでPostCSS+sugarssにしました。残念ながら今回cssはたった1ファイル、しかも140行しか無いのですけどね。。。

苦労した点

<RaisedButton
    label={'ジオコーディングする'}
    secondary={true}
    icon={<FontIcon className="muidocs-icon-custom-github"/>}
    onTouchTap={this.handleSubmit}
    disabled={this.state.buttonDisabled}
    style={{width: '100%'}}
/>

this.handleFunc1 = this.handleFunc1.bind(this);
this.handleFunc2 = this.handleFunc2.bind(this);
this.handleFunc3 = this.handleFunc3.bind(this);
・・・以下thisを使う関数毎に書く・・・

<RaisedButton
    label={'ジオコーディングする'}
    secondary={true}
    icon={<FontIcon className="muidocs-icon-custom-github"/>}
    onTouchTap={this.handleSubmit}
    disabled={this.state.buttonDisabled}
    style={{width: '100%'}}
/>

import RaisedButton from 'material-ui/RaisedButton';

高速になった

高速になるというのは、言うのは簡単ですが、実際にそれを行うのは非常に難しいです。処理速度は技術要素に依存する面も強いので、古い技術を使っているとそもそも高速になりにくい部分もあります。今回は以下を解決する事で、サイトの高速化を図りました。

機能追加のし易さ

reactもある程度使っていると、「あ、これjQueryでは厳しいけど、reactだとできるわ」という部分が出てきます。特に「チェックボックスがこういう状態で、テキストエリアがこういう状態の時、ボタンは非活性になる」等の、複雑な状態が絡む処理はreactは圧倒的に楽です。jQueryと違ってdomの状態を気にする事も無く、単にstateの値だけで判断でき、stateの状態が全てのイベントとリンクしてくれるので、これはバグも起きにくいなと感じました。

モバイルファースト

material-uiを使っていると強制的にモバイルファーストになります。旧tree-mapsではTwitterのbootstrap v3で一応レスポンシブ対応していましたが、モバイルは全然意識していませんでした。今回はmaterial-uiなので、Androidのスマホを使っている方には見慣れたUIだと感じると思います。

Googleもこのモバイルの波を意識し、ついにPCサイトよりモバイルサイトの方に軸を変更してきているので、例えそのサイトがモバイルで使われる類のものでなくてもモバイルファーストでなくてはならないのです。

これってtree-mapsのようなどう考えてもPCでしか使われないサービスにとってはモバイルの存在は邪魔でしかなく、モバイルファーストの強制も何だかなあ、という感じがします。実際GAで見ても、PCが95.6%で、残りがモバイル等です。これでモバイルファーストを強制されるのはねえ・・・

ジオコーディング・逆ジオコーディング

ジオコーディング or 逆ジオコーディング実行後、入力・変換された緯度経度を使って即座にgoogle mapに描画するようにしました。

プロット画面

スクロール位置が持続される

例えばトップページで下の方までスクロールします。その状態で左サイドナビで他のメニューを選択します。するとあら不思議、選択したメニューのスクロール位置がトップページのスクロール位置になっています。スクロール位置まで記憶されているのです。

以下を参考にしみたのですが、効かないのです。。。
github.com

使用しているreact-routerはv3.0.0なのですが、どなたか解決方法をご存知の方がいれば教えて頂きたいです。。。

SNSのタイトルがおかしい

厳密には、URLは正しいがタイトルは一つ前の画面のものになっている、です。

react-document-metaを使って、メニュー切替時にtitleタグ・meta descriptionを差し替えているのですが、差し替え後のtitleタグが取れていません。綺麗な解決方法は思いついていませんが、reduxを導入し、メニュー切替時にstateにtitleタグを保存し、snsボタン描画時はそのstateからtitleタグを取得する、みたいにすれば上手くいきそう？と模索中です。

DMS => DEG変換機能

特定のフォーマットに従っていないと変換できません。

以前はjavaでゴリゴリしていたのですが、golangであのゴリゴリをするのが面倒だったので、ライブラリを使ってごまかしています。。。優先度低めでいずれ直します。

サーバサイドレンダリング(SSR)

多分やりません。少なくともGolangではやりたくありません。。。node.jsだったら、これくらいの規模のアプリならやってもいいかな？と思います。

グループプロット

これはアンケートをした時にも書いていますが、プロットをグループ単位で行えるようにしたいと考えています。

例えば、とあるイベントで、男性グループと女性グループがいるとして、人間全てに緯度経度データを持っているとします。その時、視覚的に「男性の場合はピンを青色に」「女性の場合はピンを赤色に」というグルーピングをしたい場合、現状のtree-mapsではできません。

男女だけでなく、「今日の緯度経度」「昨日の緯度経度」を同じ画面で確認したい場合も、グループを分けて色が異なるピンでプロットする事ができれば、視覚的に確認する事ができます。

これは個人的に非常に有用な機能だと思っているので、開発する予定です。

入力値の保存・復元

例えばtree-mapsのプロット機能を使う際に、必ず中心点を使う、更に色も毎回同じにしている、等という場合、毎回のその選択するのは煩わしいですね。それを解決するため、ローカルストレージに状態を保存し、次回画面表示時に使えるようにしようと考えています。

プッシュ通知

chromeでプッシュ通知ができるので、新機能通知機能ができるかな？等と適当に考えています。

アプリ化

アンケートで「webアプリかネイティブアプリかどっちがいい？」と聞いたのですが、ほぼwebアプリでした。理由は「環境構築が不要」でした。という事で旧tree-mapsと同様に今回もwebアプリとしています。

もしネイティブアプリであればもっと沢山の緯度経度を扱えると思いますが、環境構築（アプリのインストール）が鬼門の場合があります。会社でtree-mapsを使う場合にネイティブアプリだと、「許可されていないアプリのインストールは許可されない」等の壁が立ちはだかります。するとそもそもtree-mapsを使う事すらできない場合があるので、webアプリだと助かる場合が多いようです。

とはいえアプリ化すると嬉しい人もいると思うので、Electronでアプリ化できるかな〜？、等と安易にアプリ化を模索しています。

goランタイム

go_appengineのバージョンによって変更するファイルパスが違うようです。今回は v1.9.48 の修正方法となります。

$ goapp version
go version go1.6.3 (appengine-1.9.48) darwin/amd64

変更するファイル

修正するのは以下のファイルです。
${GO_APPENGINE}/google/appengine/tools/devappserver2/watcher_common.py
ネットで調べてみると、go_appengineのバージョンによって watcher_common.py のパスが違うようなので、見つからない場合はfind等で自分で探してみて下さい。

修正内容

def ignore_dir(dirpath, dirname, skip_files_re):
  """Report whether a directory should not be watched."""
  return (dirname.startswith(_IGNORED_PREFIX) or
          skip_files_re and skip_files_re.match(os.path.join(dirpath, dirname)))

_IGNORED_DIRS = ('node_modules',)

def ignore_dir(dirpath, dirname, skip_files_re):
  """Report whether a directory should not be watched."""
  return (dirname.startswith(_IGNORED_PREFIX) or
          skip_files_re and skip_files_re.match(os.path.join(dirpath, dirname)) or dirname in _IGNORED_DIRS)

node_modues

以下の2つのモジュールをインストールします。yarnを使っていない方はnpm install -Sに置き換えて下さい。

yarn add electron-prebuilt electron-packager --dev

electron実行用js

以下は実際にtree-mapsで使っているものを少し整形したものです。
解りやすいように electron.js としてファイルを保存して下さい。

const{app, BrowserWindow, Menu, session} = require('electron');

let mainWindow = null;
app.on('window-all-closed', function () {
    app.quit();
});

app.on('ready', function () {
    mainWindow = new BrowserWindow({
        width: 1000,
        height: 600,
        webPreferences: {
            defaultFontFamily: {
                standard: 'Noto Sans JP',
                serif: 'Noto Sans JP',
                sansSerif: 'Noto Sans JP',
                monospace: 'Noto Sans JP'}}});
    // WebView的なロードを行う
    mainWindow.loadURL('https://www.tree-maps.com/');
    mainWindow.on('closed', function () {// アプリ終了時にキャッシュをクリアする
        session.defaultSession.clearCache(() => {})
        mainWindow = null;
    });

    var template = [{// ショートカット
        label: "Application",
        submenu: [{label: "About Application", selector: "orderFrontStandardAboutPanel:"},
            {type: "separator"},
            {
                label: "Quit", accelerator: "Command+Q", click: function () {
                app.quit();
            }}]}, {// コピペを有効化
        label: "Edit",
        submenu: [{label: "Undo", accelerator: "CmdOrCtrl+Z", selector: "undo:"},
            {label: "Redo", accelerator: "Shift+CmdOrCtrl+Z", selector: "redo:"},
            {type: "separator"},
            {label: "Cut", accelerator: "CmdOrCtrl+X", selector: "cut:"},
            {label: "Copy", accelerator: "CmdOrCtrl+C", selector: "copy:"},
            {label: "Paste", accelerator: "CmdOrCtrl+V", selector: "paste:"},
            {label: "Select All", accelerator: "CmdOrCtrl+A", selector: "selectAll:"}]}];

    Menu.setApplicationMenu(Menu.buildFromTemplate(template));
});

icnsファイルの生成

electronアプリの実行ファイルに設定するアイコン画像は、icnsという特殊な形式のものを使います。macでicnsを生成するには「iconutil」を使います。

iconutilでiconsを作るわけですが、16px, 32px, 64px, 128px, 256px, 512px, 1024px のpngファイルが必要なので事前に用意しておいて下さい。

それらを以下のような構造にまとめます。

.
└─ ${アプリ名}.iconset
　　　    ├── icon_128x128.png
　　　    ├── icon_128x128@2x.png
　　　    ├── icon_16x16.png
　　　    ├── icon_16x16@2x.png
　　　    ├── icon_256x256.png
　　　    ├── icon_256x256@2x.png
　　　    ├── icon_32x32.png
　　　    ├── icon_32x32@2x.png
　　　    ├── icon_512x512.png
　　　    └── icon_512x512@2x.png

tree-mapsの場合は「tree-maps.iconset」というフォルダを作り、その中に画像を配置しました。
この状態で、以下のように実行すると、icnsファイルが生成されます。

iconutil -c icns tree-maps.iconset

成果物として「tree-maps.icns」というファイルが生成されます。これを次項で使用します。

アプリ実行・ビルド等のタスク設定

package.jsonのmainとscriptsセクションを以下のようにします。この例ではwebpackを使用するので、「yarn add webpack --dev」等でインストールして下さい。

"main": "electron.js",
  "scripts": {"build": "NODE_ENV=product webpack --progress --color",
    "app": "electron .",
    "package": "NODE_ENV=product electron-packager . tree-maps --out=dist --platform=darwin,wind32--arch=x64 --icon=tree-maps.icns --overwrite"
  },

※ この記事ではビルドは64bit版で行うものとします。

appタスクはパッケージングせず、直接electronアプリを実行します。主にデバッグ用途で使用します。

electronアプリを配布する際は、まずbuildタスクを実行して各種成果物を生成し、その成果物をpackageタスクでパッケージングします。

electron-packagerには沢山の引数がありますが、それぞれ以下のようになります。

homebrewのインストール

以下の「インストール」にワンライナーのインストールコマンドがあるので、インストールします。
brew.sh

xquartzのインストール

$ brew cask install xquartz
Uninstalling brew-cask... (5,904 files, 3.2MB)
Warning: The default Caskroom location has moved to /usr/local/Caskroom.

Please migrate your Casks to the new location and delete /opt/homebrew-cask/Caskroom,
or if you would like to keep your Caskroom at /opt/homebrew-cask/Caskroom, add the
following to your HOMEBREW_CASK_OPTS:

  --caskroom=/opt/homebrew-cask/Caskroom

For more details on each of those options, see https://github.com/caskroom/homebrew-cask/issues/21913.
==> Downloading https://dl.bintray.com/xquartz/downloads/XQuartz-2.7.11.dmg
######################################################################## 100.0%==> Verifying checksum for Cask xquartz
==> Running installer for xquartz; your password may be necessary.
==> Package installers may write to any location; options such as --appdir are ignored.
Password:
==> installer: Package name is XQuartz 2.7.11
==> installer: Installing at base path /
==> installer: The install was successful.
🍺  xquartz was successfully installed!

wineのインストール

非常に依存モジュールが多く、インストールが長く、インストールする依存の中には503エラーでタイムアウトするものもあります。503の場合は時間を置いて再度brew installしてみて下さい。

tree:certbot tree$ brew install wine
==> Installing dependencies for wine: libpng, freetype, jpeg, libtool, libusb, libusb-compat, fontconfig, libtiff, webp, gd, libgphoto2, little-cms2, cmake, jasper, libicns, makedepend, openssl, net-snmp, sane-backends, libtasn1, gmp, nettle, libunistring, libffi, p11-kit, gnutls
==> Installing wine dependency: libpng
==> Using the sandbox

・・・snip・・・

By default Wine uses a native Mac driver. To switch to the X11 driver, use
regedit to set the "graphics" key under "HKCUSoftwareWineDrivers" to"x11"(or use winetricks).

For best results with X11, install the latest version of XQuartz:
  https://xquartz.macosforge.org/
==> Summary
🍺  /usr/local/Cellar/wine/2.0: 4,297 files, 461.9MB

パッケージングしてみる

yarn build && yarn package

パッケージングのコマンド自体はmacと同様（というかmacとwinを同時にビルドするよう前項でpackage.jsonを設定しました）です。

が、ビルド中に、ここから更に「mono」「Gecko」のインストールを求められます。monoは、macでwindowsのバイナリを生成するためのものでお馴染みのアレです。

パッケージング中に以下のダイアログが自動で起動するので、全てインストールしちゃって下さい。

3つ目のダイアログの Install をクリックすると、パッケージング処理が続行して、無事exeを生成する事ができます。

macとwindowsの64bit版をパッケージングすると、以下のような成果物が出力されます。

macの方は「アプリ名.app」単体で起動しますが、windowsはフォルダの中のdll等は全て必要なので、exeファイル単体で配布せず、ディレクトリごと配布して下さい。

Make sure that the "wine" executable is in your PATH.

yarn packageする時に、wineがインストールされていない場合に発生します。wineをインストールしましょう。

$ yarn package
yarn package v0.20.3
$ NODE_ENV=product electron-packager . tree-maps --out=dist--platform=win32--arch=x64--icon=tree-maps.icns--overwrite 
Packaging app for platform win32 x64 using electron v1.4.13
Could not find"wine" on your system.

Wine is required to use the app-copyright, app-version, build-version, icon, and 
win32metadata parameters for Windows targets.

Make sure that the "wine" executable is in your PATH.

See https://github.com/electron-userland/electron-packager#building-windows-apps-from-non-windows-platforms for details.
error Command failed with exit code 1.

wine: XQuartz is required to install this formula.X11Requirement unsatisfied!

wineのインストールをするには xquartz のインストールが必須のようです。xquartzをインストールしましょう。

tree:certbot tree$ brew install wine
Updating Homebrew...
wine: XQuartz is required to install this formula.X11Requirement unsatisfied!

You can install with Homebrew-Cask:
  brew cask install xquartz

You can download from:
  https://xquartz.macosforge.org
Error: An unsatisfied requirement failed this build.

curl: (22) The requested URL returned error: 503 first byte timeout

brew install中に以下のように503エラーが発生する場合があります。これはhttpステータスコード通り、サーバが混み合っているだけですので、少し時間が経ったら再びbrew installして下さい。

==> Installing wine dependency: sane-backends
==> Downloading https://fossies.org/linux/misc/sane-backends-1.0.25.tar.gz
######################################################################## 100.0%==> Downloading https://raw.githubusercontent.com/Homebrew/formula-patches/6dd7790c/sane-backends/1.0.25-missing-types.patch

curl: (22) The requested URL returned error: 503 first byte timeout
Error: Failed to download resource "sane-backends--patch"
Download failed: https://raw.githubusercontent.com/Homebrew/formula-patches/6dd7790c/sane-backends/1.0.25-missing-types.patch

mapTypeIdが変わってしまう

通常の地図だと

map.setMapTypeId(google.maps.MapTypeId.ROADMAP)

というように、ロードマップが適用されます。
しかし地理院タイルの指定時は「GsiMaps」とユニーク値を指定しているので、tree-mapsのように地図のスタイルを変えたり元に戻す必要が有る場合、通常の地図に戻す場合は上記のようにロードマップに戻してあげる必要があります。

対応しているズーム値

最初嵌ったのですが、沢山ある地理院タイルは、それぞれ対応しているGoogle Mapのズーム値が決められています。

例えばズームレベルの項目に「9～11」と書かれていたら、zoomMax: 11, zoomMin: 9 のみ対応しています。それ以外のズーム値は画像が用意されていないので、必ず対象の地図にかかれているズームレベルを確認して設定する必要があります。

必ずしも0〜21の値が指定できる訳ではないので注意しましょう。

対応している地域

「提供範囲」という部分が画像を配信している地域です。これが「日本全国」であれば、日本の画像のみが表示でき、海外を表示しようとするとタイル画像が404になったりします。

例えば「西之島付近噴火活動 標高タイル（2013年12月17日）」のタイルがありますが、ここの提供範囲は「西之島付近」とだけ書かれているので、それ以外の地域ではタイル画像は404になります。相当範囲が狭いので、汎用的な地図サービスで使うにはちょっと難しいですね。

ズームレベルが不正確？

例えば「アナグリフ」の「グレー」のタイルですが、ズームレベルを見ると2〜18に対応してそうに見えますが、私が試してみたところ、どうも「2〜16」しか対応していませんでした。

もしかしたらズームレベルの17〜18は特定の地域しか配信されていないのかもしれませんね。

タイル画像にはpngだけでなくjpgもある

これはよく見ていないとタイル画像が404になり、「は？」と思ってしまう点です。

タイルにはpngとjpgの2種類があるので注意する必要があります。

既存のサーバを汚したくない

まあnginxだったらインストールしてもいいかな？とも思いますが、nginx自体のバージョンアップとか考えると面倒だし、そのサーバに既に別のwebサーバがインストールされていたりするとちょっと困ってしまいますね。既存のソフトウェアとのバッティングを避ける際はdockerを使うと楽です。

他のサーバへの引っ越しが楽

他のサーバに仕組みをゴッソリ引っ越したくなった場合、yum等でインストールしてしまうとアンインストールする必要があるし、アンインストールした事で既存環境に影響を及ぼしたり、ゴミが残ってしまったりすると面倒です。dockerであれば、Dockerfileやdocker-compose.yml等の少量のファイルさえあれば、大抵のサーバですぐ動きます。

モチベーション

地味に重要だと思うのですが、私は未だにオンプレ案件を多く担当していますが、オンプレ系プロジェクトはとにかく技術要素が古い場合が多く、モチベーションが上がりにくかったりします。それを少しでも解消するためにdockerを使ってみる、というものアリなんじゃないでしょうか。

軽量

https://hub.docker.com/_/nginx/

公式のAlpine linuxベースのnginxが用意されているので、これを使います。

イメージのサイズも15MByteと非常に小さく、イメージのダウンロードもすぐ終わります。

$ docker images
REPOSITORY                           TAG                 IMAGE ID            CREATED             SIZE
nginx                                1.12.0-alpine       61055e9116d4        11 days ago         15.5 MB

dockerのインストール

手順はオフィシャルサイトに丸投げします。

docs.docker.com

使用するイメージ

https://hub.docker.com/_/nginx/

こちらです。公式のAlpineベースのnginxを使っています。

docker-compose.yml

version: '3'
services:
  webserver:
    build: .
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./default.conf:/etc/nginx/conf.d/default.conf:ro
      - ./htdocs:/var/www/html:ro
      - ./assets/:/etc/nginx/assets/:ro
    image: treetips/simple-static-file-viewer
    container_name: simple-static-file-viewer
    tty: true
    restart: always
    environment:
      - LANG=ja_JP.UTF-8
      - TZ=Asia/Tokyo
    ports:
      - "8081:80"
    command: "nginx -g 'daemon off;'"

これは最新バージョンのインタックスなので、v3に非対応の場合はversionを2に書き換えて下さい。

では、少しづつ解説していきます。

ln -sf  /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

/etc/nginx/conf.d # cat default.conf
server {
    listen       80;
    server_name  localhost;
    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

    location / {
        add_before_body       /assets/nginx-before.txt;
        add_after_body        /assets/nginx-after.txt;
        autoindex             on;
        autoindex_localtime   on;
    }

    location /assets {
        alias                 /etc/nginx/assets;
    }

<html><head><title>Index of /</title></head><bodybgcolor="white"><h1>Index of /</h1><hr><pre><ahref="../">../</a><ahref="%E4%BB%8A%E6%97%A5%E3%81%AF%E3%81%84%E3%81%84%E3%81%8A%E5%A4%A9%E6%B0%97%E3%81%A6%E3%82%99%E3%81%99/">今日はいいお天気です/</a>                                       30-Apr-2017 18:57                   -
<ahref="Dockerfile">Dockerfile</a>                                         29-Apr-2017 14:57                  65
<ahref="README.md">README.md</a>                                          29-Apr-2017 15:36                2624
<ahref="default.conf">default.conf</a>                                       29-Apr-2017 13:55                1236
<ahref="docker-compose.yml">docker-compose.yml</a>                                 29-Apr-2017 14:07                 451
</pre><hr></body></html>

<!DOCTYPE html><htmllang="ja"><head><metacharset="utf-8" /><metaname="viewport"content="width=device-width, initial-scale=1.0"><linkrel="stylesheet"href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css"type="text/css" /></head><body><divclass="container-fluid"><divclass="row-fluid"><divclass="col-md-12"><html><head><title>Index of /</title></head><bodybgcolor="white"><h1>Index of /</h1><hr><pre><ahref="../">../</a><ahref="%E4%BB%8A%E6%97%A5%E3%81%AF%E3%81%84%E3%81%84%E3%81%8A%E5%A4%A9%E6%B0%97%E3%81%A6%E3%82%99%E3%81%99/">今日はいいお天気です/</a>                                       30-Apr-2017 18:57                   -
<ahref="Dockerfile">Dockerfile</a>                                         29-Apr-2017 14:57                  65
<ahref="README.md">README.md</a>                                          29-Apr-2017 15:36                2624
<ahref="default.conf">default.conf</a>                                       29-Apr-2017 13:55                1236
<ahref="docker-compose.yml">docker-compose.yml</a>                                 29-Apr-2017 14:07                 451
</pre><hr></body></html></div></div></div></body></html>

定期的にhtdocs配下にファイルを配置する

私の場合はデザインhtmlのファイル群をjenkinsでpullし、dockerホストのhtdocsを更新しています。デザインファイルがpushされるとホスト側のhtdocs配下に上書かれ、それがnginxのコンテナに伝搬してブラウザでそのファイル・フォルダを確認する事ができるようになります。

autoindexの注意点

autoindexには注意点があり、ngx_http_index_moduleに注意する必要があります。

Module ngx_http_index_module

「index index.html」等と書いてしまうと、http://localhost:8081/等とアクセスした際にindex.htmlが自動的に参照されてしまい、autoindexの一覧表示がされず、index.htmlを表示してしまいます。特にデザインhtmlであれば大抵index.htmlが存在するので、autoindexが全然開けない事態になります。

これを防ぐため、通常有用であるindexモジュールを敢えて効かないような設定にする必要があります。

何故Fancy Indexモジュールを使わないの？

Fancy Indexは残念ながら標準モジュールではなく追加モジュールです。従って、有効にするにはコンパイルオプションを指定してコンパイルしないといけません。そこまで頑張りたくないので、今回は見送りました。

h5aiは使わないの？

larsjung.de

まあ使ってもいいとは思うのですが、ちょっと、仕組みが重すぎるというか、重厚過ぎます。そこまでリッチなものは欲していないというか、カスタマイズが凄く難しそうというか。phpが必要な点も嫌ですね。

v4系に対応していない！？

react-router v4をreduxで管理させようと思ったのですが、2017/05/18現在react-router-reduxのv4系は残念ながらreact-routerのv4系に対応していません。

The next version of react-router-redux will be 5.0.0 and will be compatible with react-router 4.x. It is currently being actively developed over there. Feel free to help out!

https://github.com/reactjs/react-router-redux

なので、5.0.0-alpha.4を使う必要があります。以下のようにインストールします。

yarn add react-router-redux@5.0.0-alpha.4

react-router-reduxとreact-routerを連携

import * as React from 'react'import * as ReactDOM from 'react-dom'import{createBrowserHistory} from 'history'import{Provider} from 'react-redux'import{ConnectedRouter} from 'react-router-redux'import{Switch, Route, Redirect} from 'react-router-dom'import configureStore from './store/configureStore'import App from './container/App'import Hello from './components/Hello'const store = configureStore()
const history = createBrowserHistory()

ReactDOM.render(
  <Provider store={store}>
    <ConnectedRouter history={history}>
      <Switch>
        <Route exact path="/" component={App} />
        <Route exact path="/hello" component={Hello} />
        <Redirect from="*" to="/" />
      </Switch>
    </ConnectedRouter>
  </Provider>,
  document.getElementById('app')
)

ざっくりこんな感じです。

一応以下を見ながら書いてみたのですが、これで合ってるか全く自信ありません・・・
github.com

Routeの行で謎のエラーが！？

こんな感じでエラーとなり、以下のようなエラーメッセージが表示されました。

(28,12): error TS2322: Type '{ exact: true; path: "/"; component: typeof App; }' is not assignable to type'IntrinsicAttributes & IntrinsicClassAttributes<Route> & Readonly<{ children?: ReactNode; }> & Rea...'.
  Type '{ exact: true; path: "/"; component: typeof App; }' is not assignable to type'Readonly<RouteProps>'.
    Types of property 'component' are incompatible.
      Type 'typeof App' is not assignable to type'StatelessComponent<RouteComponentProps<any> | undefined> | ComponentClass<RouteComponentProps<any...'.
        Type 'typeof App' is not assignable to type'ComponentClass<RouteComponentProps<any> | undefined>'.

これは2パターンの解決方法があるようです。
stackoverflow.com

<Route exact path="/hello" component={Hello} />

<Route exact path="/hello" component={Hello as any} />

<Route exact path="/" component={App} />

import{RouteComponentProps} from 'react-router-dom'interface Props extends RouteComponentProps<any> {}exportdefaultclass App extends React.Component<Props, any> {

  constructor(props:Props) {super(props)
  }・・・略・・・

browserHistory.pushはどうやる？

react-router v4からbrowserHistoryが無くなったので、記述方法を変更する必要があるようです。

qiita.com

こちらの記事を読むと、どうやら「browserHistory.push」を「this.props.history.push」と書き換えるそうです。

が、Typescriptでこれを書くにはどうしたらよいのか。。。これが解らない。バカ正直に「this.props.history」と書いても、historyが見つからないと言われるんですよね。Propsのinterfaceを切って、そこにhistoryを追加してやるのですかね。解りません。

docker環境を用意する

docker for mac, docker for windows でさっくり環境構築をして下さい。必須要件はこれだけです。

Docker For Windows | Docker

Docker For Mac | Docker

git cloneする

git clone https://github.com/treetips/schemaspy-mysql.git

schemaspy.propertiesをいじる

schemaspy.propertiesにデータベースの接続情報を書いて下さい。

cd schemaspy-mysql
vi schemaspy.properties

コンテナを起動する

お馴染みの起動です。

docker-compose up -d

schemaspyのコンテナ起動時にDB定義書の自動生成をします。生成が完了すると、schemaspyコンテナはそっと消えます。

nginxコンテナだけデーモン起動します。

ブラウザでDB定義書を見てみよう

http://localhost:8081/

さて、どうでしょうか。見えたでしょうか。

自動生成が成功すれば、以下のような定義書をブラウザから確認できたと思います。

DB定義書を更新する

再度SchemaSpyを実行し、DB定義書を生成します。

停止中のschemaspyを叩き起こすのですが、--rmオプションを付けるので、実行が完了するとまた静かに眠りに付き、リソースを消費し続ける事はありません。

docker-compose run --rm schemaspy

本当はcron用コンテナでも用意してそこからSchemaSpyコンテナを叩こうと思ったのですが、再実行したいタイミングは人によって違うと思ったので、やめておきました。場合によってはCIサーバでDBマイグレーションが実行されたタイミングでピンポイントで実行したいかもしれませんし。

私はまだまだdockerを始めたばかりで全然ベストプラクティスが解ってないのですが、コンテナをバッチ的に起動するって、どうやるのがいいのでしょうね。

一番簡単なのは今回のようにホスト側のcrontabで叩いてしまえばいいのですが、ホスト側のcron設定を汚すのも微妙に嫌ですね。Jenkins等のCIでスケジューリングして叩くのも楽ではありますが、ちょっと格好悪い気もしています。

DBマイグレーション実行後のみ叩きたいケースや、手動で再生成したいケースを考えると、やはりホスト側から叩くのが良い気がしていますが、どうするのがよいのやら。digdagとかairflow的なワークフローコンテナ用意するとか？

AWTFontDefaultChar: symbol not found

java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/libfontmanager.so:
 Error relocating /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/libfontmanager.so: AWTFontDefaultChar: symbol not found

このエラーはバグで、JDKのバージョンによって起きるようです。最新バージョンで試してもエラーが起きたので、openjdk:8u121-jdk-alpine を使いました。

FontConfigurationのNullPointerException

schemaspy_core | java.lang.NullPointerException
schemaspy_core | 	at sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
schemaspy_core | 	at sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:219)
schemaspy_core | 	at sun.awt.FontConfiguration.init(FontConfiguration.java:107)

これはAlpine linuxで起きがちなエラーで、単にシステムフォントがインストールされていないだけです。

ttf-dejavu等を適当にインストールしちゃって下さい。

wget: can't execute 'ssl_helper': No such file or directory

Alpine linuxでwgetをインストールしてhttpsのURLを指定すると、以下のエラーが起きました。

wget: can't execute 'ssl_helper': No such file or directorywget: error getting response: Connection reset by peer

ca-certificatesを使う方法もあるようですが、私は面倒なのでlibresslをインストールして解決しました。（ダウンロード後は不要なのでdelします）

schemaspy.propertiesのschemaspy.portが反映されない

これは単純にschemaspyのバグっぽいです。何指定しても無視されます。コマンドラインパラメータでportを指定しても同様の結果になりました。

なので、現状は残念ながら3306固定だと思って下さい。（MySQL以外だと違うかもしれませんね）

静的リソースビューワー

github.com
これは、gitにpushされたファイルを、git環境無しでブラウザから閲覧できるようにする支援を行うものです。

と言っても単にnginxコンテナを起動してhtdocsのボリュームをホストと同期し、CIで定期的にhtdocsにファイルをpullすると、デザイナや営業がSourceTree等をインストールしなくてもgitのファイル群を確認できるよ、というクソツールです。

SeleniumGrid + nightwatchのE2Eテスト支援

github.com
ほぼサンプルプロジェクトですが、Dockerコンテナ上にSeleniumGridを構築し、ChromeとFirefoxに対してNightwatchでE2Eテストするためのものです。ローカル環境で実行する場合はGrid起動せず、自分のPCにインストールされたブラウザを直接起動するnpmスクリプトも用意しています。

複数のMySQL・MariaDBデータベースを一括起動

github.com
業務で使うデータベースがほとんどMySQLで、案件毎にバージョンが異なるのがウザかったので、いっそMySQLもMariaDBもありったけ起動してやれ！的なノリで作りました。docker-compose up -dすると、MySQL5.5〜5.7、MariaDB 10.0〜10.3を全部一気に起動するという、細かい事は一切気にしない男らしいコンテナです。

ちなみに前述のスクリーンショットは、この男らしいコンテナにテストテーブルを作って自動生成したものをキャプチャしたものなのです。

テスター向けのphpMyAdmin

これはDockerfileが不要なのでgithubにもdocker-hubにもアップしてませんが、以下のようにdocker-compose.ymlを保存して実行するだけで、WEB版のphpMyAdminが起動できます。

version: '3'
services:
  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    container_name: phpmyadmin
    environment:
      - LANG=ja_JP.UTF-8
      - TZ=Asia/Tokyo
      - PMA_HOST=127.0.0.1
    ports:
      - "8080:80"

強い権限を持つユーザでphpMyAdminにログインされると、テーブルの削除やカラム定義の変更等が行えてしまうので、select・insert・update・deleteのみが行える専用ユーザを用意すると、テスターが自分でデータをいじってテストする事ができて便利です。

こんな感じで最近dockerで簡単に用意できる便利ツール的なものを導入していってます。

↑では挙げてませんが、アプリケーション内の画像を、ビルド時に画像変換（圧縮）するものも作ってたりします。parallelコマンドとmogrifyコマンドで並列実行し、高速に一括で画像変換するものです。業務ではそれを使っているのですが、githubで公開するにはクオリティが低すぎるので、公開していません。

ImageMagickコンテナを作っていて思ったのですが、コンテナ内で変換した画像ファイルのowner・groupの権限設定って目茶苦茶面倒臭いですね。ホストとコンテナでユーザIDとグループIDを合わせたユーザで変換しないと駄目なんですよね。何も考えずにコンテナ内で変換してもroot:rootになるし、かといってuid・gidを揃えないとホスト側からは存在しないuid・gidのowner・groupになってしまうし。

こんな感じで今後も簡単に試せて簡単に捨てる事ができるdocker環境を増やして公開していきます！