今まで Rails でブログシステムを作り VPS で運用していたのですが、ブログ運用のためだけにライブラリや OS の更新等が面倒になったのでどうにかしたいなと思ってから早数年。記事も更新していない間に結婚したり子供が出来たり等色々とイベントが盛りだくさんで時間が取れなかったこともあったのですが、AI によってかなり開発にかかる時間が短縮出来たことによりなんとか再開に辿り着きました。

技術的なことを書くなら今なら Qiita や Zenn で書けば良いという話でもあるのですが、ブログが生まれる前の個人ホームページの時代にジオシティーズやら Tripod やらに置かせてもらって HTML 書くのが楽しくてエンジニアになった経緯があるので、記事の中身だけじゃなく何か自分で構築していたいという思いがあるんですよね。それにそんなに技術的なことばかり書いてるわけでもないですし笑

といっても自分で全て賄うのも大変だし WordPress を使うのも中途半端だし、と思っていたところ GitHub Pages の Jekyll を使えば無料でホストしてもらえるし独自ドメイン使えるし、多少 Jekyll について学ぶ必要があるけど大体やりたいことは出来そうということで、AI の助けも借りつつ実装してみました。

自動で再起動する設定にしてたんですが、気づいたら繋がらなくなっていたという（苦笑） 一体どれぐらいの期間死んでしまってたんでしょうかね、アクセスログを見ると昨日までは普通だったかもなので幸いすぐに気付けた方かもですが。

監視サーバとか置けば良いんですが、バックエンドエンジニアなのでインフラに疎かったり、全然運用に力を入れてないので（）後手後手になってます。

まぁトラブルのおかげで久しぶりにブログを更新したのでまた近い内に更新したいところです。ちょっと書けるネタは出来たので書こうと思えば書けるはず。とか言ってるとまた数ヶ月放置とかしそうですが…。

どうでも良い話ですが去年は PS のゲームを頑張って遊んで、1 年でプラチナトロフィー12 個獲得しました。月 1 ペース達成٩( ‘ω’ )و 今年はちょっとスローペースになりましたが、既に 3 つ増えました。

Web 開発界隈は私の観測範囲では結構 Mac 派の方が多いですが、最近 Windows を使い始めたという記事を続けて見かけたので、ずっと Windows 環境で開発を続けてきた Windows 派の私の環境についてもちょっと書いてみたいと思います。ちなみに今の職場は周りは全員 Mac です。

以前win-sshfs の記事を書いたりしましたが、最近は使わなくなっています。最近は Docker を使うことが多いですが、この方法は Docker でも単純な仮想環境でもどちらでも対応可能です。加えて言うと、別に Windows じゃなくて Mac でも可能です（笑） ただし IntelliJ IDEA かあるいは RubyMine 等の JetBrains 製の IDE にある deployment 機能ありきのものです。類似の機能があれば他の IDE でも対応可能かと思いますが、ご了承ください m(_ _)m

ちなみに私の現在の開発環境はホストは Windows 10 Pro で、ゲストとして仮想環境(VirtualBox)に Ubuntu18.04 を使っています。更にその上に Docker を動かしていて、そこで Rails を走らせています。

何故マウントしないのか

上でも触れましたが、私は過去に sshfs や、更に前は samba や仮想環境独自のマウント機能を使ってマウントしたりしてきました。ただそれぞれ問題がありました。共通しているのはディスクアクセスが遅くなることです。それがホスト側で問題になること、ゲスト側で問題になること、両方ありました。

色々悩んだ結果、ソースコードはそれぞれの環境で別々に持った方が速度的に問題なくなるということになったのですが、それはそれで今度はソースコードの不整合が発生することになります。

それを対処するために rsync みたいな sync 機能があればいいなと考えていたのですが、IntelliJ IDEA が便利な deployment 機能を搭載していてくれたおかげで簡単に実現できました。今回紹介する方法はその機能を使った方法ですが、これも上で書いたとおり類似した機能があれば何でも実現可能です。

現在の大まかな構成

ホスト上とゲスト上両方にソースコードを置くことになるのがこの構成の特徴です。Docker を使う場合は仮想環境上で動かし、仮想環境上のソースコードを置いたディレクトリを Docker にマウントすることで対応します。Docker が仮想環境上のファイルを見る分には特にディスクアクセスの速度に問題は起こっていません。コマンドラインから立ち上げる時は-v オプション、docker-compose.yml で設定する場合は volumes で設定する感じですね。

まずホストからゲストと繋げるために SSH が繋げるようにしておきます。これは個人的に SSH を導入するのが一番楽だったり、その他開発する上で便利かと思って使っていますが、FTP を使っても対応可能です。

続いてホストとゲストそれぞれの環境で git clone しておきます。その方が改行コードの問題とか起こりづらいです、多分。

その後 IntelliJ IDEA の deployment 機能を使います。「Tools > Deployment > Configuration」から設定します。ホスト環境とゲスト環境のそれぞれのコードの置き場を設定すれば、初期設定は完了です。ついでに Excluded Paths タブでホスト環境の.idea ディレクトリと、ゲスト環境の tmp ディレクトリ、log ディレクトリを指定しておけば大まかに大丈夫かと思います。

ここまで設定すれば実際 deployment ツールを実行することが出来るはずです。実行して問題が無ければ設定成功です。最後に「Tools > Deployment > Automatic Upload (always)」を選択すれば、上書き保存する度に勝手にアップロードされます。多分これだけで設定完了です。便利！簡単！

注意点

上記までで一通り使えるようになったかと思いますが、少し注意点があります。

まず気をつけれなければいけないことは、deployment 機能は万能ではないということです。上書き保存時にアップロードしてくれますが、ゲスト側で新規にファイルを作ってもホスト環境にダウンロードしてくれません。rails g 等でゲスト側でファイルを作成した後には手動で同期を行う必要があります。私は Settings の Keymap で「Sync with Deployed to…」を設定して、すぐに deploy メニューを呼び出せるようにしています。

それからホスト側の文字コードや改行コードにも、特に Windows では気をつける必要があります。Windows 上でテキストファイルを新規作成すると改行コードは CRLF になってしまいます。IDE の設定で LF に設定しておくのが無難で、且つファイル作成は IDE から行うように徹底しておいた方が良いと思います。

あとファイル権限周りは同期に失敗する原因になります。特に Docker を使っていると仮想環境と Docker でユーザが違ったりして、ファイルを新規作成する時に毎回設定する必要があったりします。まぁそこら辺は慣れれば毎回意識して設定出来るかと。ちなみに私は常にホスト側で git commit, push するようにしています。

まとめ

私の Windows と仮想環境を使った開発環境の構成を紹介しましたが、完全に我流の構成です。Windows と仮想環境を使ってどうやって Web(Rails)開発が楽に出来るかとあれこれ試行錯誤した結果ではあるものの、これよりも便利に開発できる方法があるかもしれないので、これがベストだと主張するつもりもありません。

Mac でもまったく同じことが出来るので、個人の趣味嗜好で環境を選択できれば良いんじゃないかなと思います。アプリと違って Web 開発はあまり OS に縛られないのが楽なところかと思います。私は以前 Mac を買って使ってみたものの肌に合わなかったので、今後もしばらくは Windows 環境でやっていけたらと思います。

こんな感じに、ほぼ千切れるぐらいのレベルで破けました。前日まで普通に使えてたはずなのですが、もしかしたらある程度亀裂が合ったのかもしれません。写真にも写っていますが、近くにもいくつか亀裂がありました。

ホースの交換が可能かどうか調べてみましたが、公式ページにはパーツとしては特に紹介されていませんでした。一応公式の商品を扱っていると思われる EC サイトは発見しましたが（HFK-VH770 ホースで検索すると見つかると思います）、本当に使えるのかわからなかったのと、年末だったので届くまで時間がかかりそうだったのでもっと違う方法を考えてみた結果、ジャバラホースを修復するテープが売られているのを知り、試してみました。こちらの商品です（私は地元のお店で売ってたのでそっちで買いました）。

Amazon リンク

正直ホースが太いので本当にどうにか出来るのか不安だったのですが、灰色のテープで何度か挑戦した結果何とかなりました（＾＾；

これがまず下地で、続いて黒いテープで巻きます。これは多分ゴムテープと呼ばれるものだと思います。結構太いのですが長さは短いので、もし足りなかった場合は別に買い足して巻けば良いと思います。自分の場合はギリギリ足りた程度でした、ホースが太いからかなり使ったのとあまり引き伸ばさなかったのが原因かと思います。

一通り黒いテープで巻いたあとは、灰色のテープをその上から改めて巻きます。

これで完成です。見た目はそれなりに上手く行きました（個人的感想です）。使ってみたところ、特に問題なく使うことが出来ました。唯一問題点があったのが、収縮することが出来なくなってしまったので、ホースを本体に収納することが出来なくなってしまったことです…。

これでまた壊れたりしたら、ホースを購入するかもう別の布団乾燥機を買おうかと思います。そもそも 1 年ちょいで壊れるホースって、耐久性に難ありですよね。1 年超えてしまって保証が使えなかったのが痛かったです、これ 1 年中使ってたらもっと早くに駄目になってたんじゃないかと思うんですよね。ひとまずこれで今季は大丈夫だと思うので、しばらく様子見です。

まず使い方としては Surface Book のメインディスプレイとして利用しています。本体のディスプレイとの大きさが違いすぎるので、本体の方では出力していません。それでも十分作業スペースは確保できます。画面表示の倍率は 125%で使っています、100%はちょっと文字が小さすぎましたね。決して読めないぐらい小さいわけではないのですが、使ってて辛くなったので 125%にしました。

良かった点としては、やはりとにかく作業スペースが広い。全て横並びに置くというのはさすがに厳しいですが、一部重ねるぐらいならば IDE とブラウザとコンソールを配置しても余裕があります。そして 1 枚のディスプレイで表示しているわけだから、色味の違いで違和感を覚えたりすることが無いというのも利点でしょうか。

PC と繋げるコネクタも 1 本で済みます、ノート PC の場合は持ち運ぶ度に抜き差しが必要となるのでこういうのも便利と感じます。Surface Book の場合はドックを買えば良いんですけど、あれだけで 2 万円かかりますからね…。

さて、ここから微妙な点を書いていきます（苦笑）。まずディスプレイが大きいことは良いんですが、横だけじゃなくて縦にも大きいというのは考えものでした。視線を上に向けるのって面倒です、目が疲れます。となると必然的に画面の下の方にあれやこれや物が集中することになり、あまりフルに活用できていないように感じます。

それからディスプレイのサイズについてですが、先に書いたとおり 43 インチでも 4K を 100%で表示するのはきついなと感じました。これが 49 インチとか 55 インチとか更に大きなディスプレイなら可能なのかもしれませんが、そうなると更に横にも縦にも大きくなるので、それが PC ディスプレイとして実用的なのかどうかについてはよく分かりません。

余談ですが、32 インチでの 4K ディスプレイとかありますが、あれは 150%や 200%で表示しないと使えないんじゃないですかね？ そうなると、4K である意味というのをどう見い出せば良いのか、使ったことがないのもありますが分かりません。特に Windows の場合、アプリケーションによっては倍率にちゃんと対応できてないものがあったりするので（古くからあるフリーソフトとか）、表示が大変かと思います。

感想としてはこんな感じでしょうかね。個人的には、エンジニアがディスプレイとして使うのに一番適しているのは 27,8 インチぐらいの WQHD じゃないかなと思っています。それを出来れば 2 枚並べて、あるいはノート PC の場合は本体のディスプレイと合わせて使うとか。43 インチ 4K はテレビとしては文句ないんですけどね、ゲームも快適です。

XZP を選んだ理由としては、現時点のハイエンド機であり、また 2 年ぐらい同じ端末を使い続けても不便が無いと良いなという願望からです。当初は Xperia XZs でも十分かと思っていたのですが、ドコモに MNP すると端末購入サポートとして 8 万円弱も割り引いてくれて、XZP と XZs で端末代金に差が無かったので、それじゃハイスペックの XZP が良いなと（笑）

それまで mineo を使ってましたが、おサイフケータイ機能を使いたいがために白ロムの XZP を探してました。ただ白ロムだともしかしたら使えなくなる可能性があったのでそこが怖いところですよね、お店が保証してくれるところで買えば良いのかもしれないですが。そんな時にドコモの端末購入サポートだと本体代金が激安になると知って、計算してみたところ私の使い方（カケホーダイライトプラン＋データ S パック）だと 1 年使った後に解約違約金を払っても、白ロムで買った本体（8 万円程度を想定）＋mineo（デュアルタイプ 3GB）と比べると安いんですよ。

そんな皮算用をして機種変をしましたが、ドコモ回線についてはまず基本的に不満は無し。そりゃこれまで使ってたのが MVNO ですからね、完全に上位互換ですから（笑） 端末についてですが、巷で話題になってる写真の歪みに関してはそもそも写真をあまり撮らないのと、Z1 でも既にあったのでそんなに気になりません。「Z シリーズは大丈夫だったのに」みたいな書き込みを見かけましたが、端末によって差があったんでしょうかね？ 私の Z1 は同じように歪みがありましたが（苦笑）

感動したのはやっぱり CPU スペックが向上したおかげでアプリがサクサク動くことですね。特にポケモン GO とか、リリース直後に Z1 でやってましたが端末が熱くなりすぎてすぐ諦めました。それに比べて XZP はそんなに熱くなりません（多少は熱くなりますが）。電池のもちも大分良くなってるように感じます。ポケモン GO をやってるとさすがに消費が激しいですが、それでも少しの外出時の使用という私の使い方なら 1 日もちます。それと最近はスタンダードなのかもしれないですが、電源ボタンの指紋認証でのロック解除は便利ですね。指紋認証を利用したのは Thinkpad X61 以来です（古い）。

地味に便利だったのはデフォルトでライト機能が付いていたことですね。今までアプリを入れて対応してきたんですけど、最初から入っていると導入の手間が省けたり、広告が出ないで済むので良いですね。

一番不満な点は、通知のランプが気づきにくいというところです。Z1 はバーのような広範囲が光ってくれたのでパッと見ただけで気づけたんですけど、XZP では小さい丸い点のようになっていて本当に気づきにくい。そんなにスマホを確認する癖とか用事が無いので、もうちょっと気づけるように光ってほしいんですけどね…。それから Wi-Fi がたまに切断されて 4G 回線になっちゃってるときがありますが、これは海外サイトによるとファームウェアで改善されたとか？ まだ日本には来てないみたいですね、期待したいです。

全体的には満足して使っています。Android のバージョンも 7.1.1 なので、検証端末としても役立ってくれそうです。今のところ私の仕事は Web がメインなのでアプリほどバージョンには依存しませんが。

自分の長所と短所、今持っているスキルと今後伸ばしたいスキル、現在の年齢と今後の生き方を考えた結果、ここは試しに独立してみようという判断に至りました。最初からネガティブじゃあれですが、失敗しても全然やり直しがきく範囲ですし。

この 1 ヶ月、基本は遊んでばかり（ウィッチャー3 の DLC や Horizon Zero Dawn を遊び終わった）でしたがプログラミングで新しいことにも取り組んでみました。フリーランスとして”NocTech”という屋号を名乗ることにしましたが、これのためにホームページを作成しました。ほぼペライチなホームページで無駄ですが、Rails5.1 で puma で動かしてます。Rails は問題なかったですが、初 puma と nginx の設定はちょっと苦労しましたね…。それとデザインもちょっと悩みました。

こんな感じでまだ働いてないですが、もし何かお仕事のご依頼がありましたらこちらのページからお問い合わせください。

今後はこのブログの更新頻度を上げられるようにもうちょっと頑張りたいところですが、こちらは相変わらず趣味の話も詰め込んでいこうと思うのでより混沌とするかもです（苦笑） もうちょっとタグとか見やすくて使いやすいように改善しなきゃな…。

Windows10 に VirtualBox を入れて使用していたのですが、何かの拍子で VirtualBox 自体が起動できなくなりました。恐らくですが Windows10 Creators Update が怪しいんじゃないかと思っています。アップデート後にすぐに使っていなかったので確信はないのですが。

そこでひとまず VirtualBox を最新のもの(5.1.22)に更新してみました。すると VirtualBox は起動できるようになったのですが、今度は肝心の仮想環境が立ち上がりません。エラーメッセージには「NtCreateFile(\Device\VBoxDrvStub) failed: Unknown Status -626」という表示が。なんのこっちゃって感じです。

検索してみたら 2 年前の QA がヒットしたりしてたので Windows の更新が原因じゃないのか？と悩んだりしましたが、回答としては最新の物で更新したり Windows を以前のバージョンに戻したり、test buildsという beta 版のようなものを使ってみるというものがありました。そこで 5.1.23 を入れてみたところ、ちゃんと動いてくれるようになりましたヽ(´ー｀)ノ

ちなみに何か変な設定が残るとまずいかなと思って VirtualBox は毎回アンインストールしてからインストールし直してました。それと仮想イメージには一切手を触れなかったのでデータとしては何も問題なく使えました。

一時はどうなることかと思いましたが、無事使えたのでホッとしてます。しかしこの症状の原因が Windows10 Creators Update が原因だとしたら、リリースされてから時間が経ってると思うのでもっと色々被害があってもおかしくないと思うのですが、何か別の原因なのかあるいは環境によるんでしょうかね？ 結局問題の原因がわからなかったのが、今後また再発しないかが気になる点です。

2017/07/20 追記
5.1.24 がリリースされていたので導入してみたところ、こちらでも問題なく動作しました。

そんなシステムが今朝クラッシュしていました。なんでだろうと思ったら zone.js が何かコケていると。でも昨日まで動いていて特に手を触れていないのになぜ急に壊れるのか。DB には特に問題はなかったのでこれはもう完全に JS 側の問題だろうと思って調べていたところ、RxJS が原因でした。

CDN から読み込んでくる時にバージョン指定していなくて、昨日次期メジャーバージョンアップの alpha 版が出されたことでコケたみたいです orz

完全にケアレスミスですね。チュートリアルからコピーしてきた部分でしたが、バージョン指定をしているライブラリもあったので、まぁ気づけよと。RxJS の 5 系を指定したらまた問題なく動いてくれました。

やれやれこれで一件落着かと思っていたのですが、引き続き systemjs.config.js を眺めていたらどうも angular core の方にもバージョン指定がされていないように見えました。何か嫌な予感が、胸騒ぎがしました…。

_あ …ありのまま 今 起こった事を話すぜ！

『おれはチュートリアルに従い Angular2 を動かしていると
思ったらいつのまにか Angular4.2.2 になっていた』

な… 何を言ってるのか わからねーと思うが
おれも何をされたのかわからなかった…

頭がどうにかなりそうだった…

見間違いだとか自動アップデートだとか
そんなチャチなもんじゃあ 断じてねえ

もっと恐ろしいものの片鱗を味わったぜ…_

いやぁ、本当に設定がザルでした（汗） 幸いな事に Angular4.2.2 の今でも（確認した範囲では）問題なく動いてくれていたので、このバージョンでロック。今後こういうことが無いように注意します…。

まず最初に参考にしたのは Certbot の公式ドキュメントです。nginx と Ubuntu16.04 の組合せについてはこちらのページに書かれていますが、ここでまず一つ問題が。ここに書かれているコマンドは私が見ている現時点では

$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install certbot

となっていますが、ここのadd-apt-repositoryが Python の環境が入っていないと実行できませんでした。そのため先に

$ sudo apt-get install software-properties-common python-software-properties

を実行しました。余談ですが、私は基本aptitudeを使っています。今回はapt-getで書き換えていますが、aptitudeを使っている方は置き換えて考えてください。

さて、上記を一通り実行したらもう Certbot の導入は完了ですね。次はもう証明書の取得です。

$ sudo certbot certonly --webroot -w [ドキュメントルート] -d [ドメイン] --email [メールアドレス]

これで証明書の取得が可能です。ドキュメントルートは Rails だったらRailsルート/publicですね。一つ気をつけたいのは、パッケージで導入した時のコマンドはcertbotだということです。よく Qiita とかでcertbot-autoで書かれたりしてますが、あれは恐らくソースを DL した場合のコマンドです。今回パッケージで導入したから違うわけですね、私はちょっと戸惑いました。

ここまで来ればあとは nginx の設定と証明書の更新の設定です。nginx の設定については

server {
    listen 443 ssl;
    ssl_certificate     /etc/letsencrypt/live/www.example.com/cert.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
}

ここらへんを気をつければ大丈夫なはずです。さくらのナレッジの記事を参考にすると、80 でアクセスしてきた場合のリダイレクト処理も書いてあげるとなお親切ですね。

server {
    listen       80 default_server;
    listen       [::]:80 default_server;
    server_name  www.example.com;
    return  301 https://www.example.com$request_uri;
}

そして証明書の更新については root ユーザの cron に

0 5 * * 0 certbot renew --post-hook "service nginx restart"

こんな感じで設定しておくと良いかと思います。上記は毎週日曜日の午前 5 時に証明書の更新を試みる内容になっていますが、どうもこれを実行しても証明書の有効期限が一体期間以上残っていたら更新はしないようになっているようです。

以上が私が Let’s Encrypt で SSL を導入するまでの大まかな手順でした。