Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる
http://b.hatena.ne.jp/entry/bonotake.hatenablog.com/entry/2018/09/06/072800 ここをながめていて思ったことなんですが。
Docker はデプロイにのみ関連するツールであって、ソフトウェア開発の本質には一切関係ないものだ、という考えの人をたまに、いや、よく見る。これは全く間違っていて、 Docker を用いて継続的にソフトウェアをデプロイしているだけでソフトウェアの品質は上がります。ソフトウェアの品質のような問題について考えている人は Docker とそのメンタルモデルに興味をもつべきです。
本来こうした問題について僕がなにかを言う必要はなくて The Twelve-Factor App という文章を読めば十分です。あるいは 大切なことはだいたいHerokuで学んだ というこの文章も非常に有用だと思います。いやこれ Heroku の話じゃんとか思わないでください。 Docker はもともと Heroku クローンである dotCloud の実行エンジンとして開発されたものであり、 Heroku は Docker とそのエコシステムが目指すもの、そして乗り越えるべきものだったのです(部分的には乗り越えていますが、 Heroku は未だに有力なプラットフォームです)。
ところで Docker を使っているだけで何故ソフトウェアの品質が上がるかということを簡潔にまとめたものを改めて書いておくのは悪いことではないと思ったので書いておきます。
ほかにもいろいろあるとは思いますが、すぐに思いつくこととしてはこんな感じですかね。
ここ数年いろんな勉強会でずっとテストの実行に関する話をしてきて 分かったことがあって、やはり多くのソフトウェアエンジニアはテストに興味をもっていない。コストとしか意識していないのだろう。ただし少数のエンジニアが熱烈にこの分野に関心を持っているということもよく分かった。
あんまり健全じゃないよね、これ。
CircleCI あんま好きじゃない
Firebase でバックエンドエンジニアがいらなくなるは正しくない と思っている。
用語定義が曖昧だが、「バックエンドエンジニア」という言葉でなんとなく想像されるものとしては、 Rails とか Laravel とかでデータベースに CRUD する Web アプリケーションを書ける人を指すと思う。違いますかね。そんなに違ってないと思うが。
Firebase でこれらの知識をもつ人が不要か?というとある程度の規模、機能を持つアプリを作ろうと思うとこれは必須になる。 Firebase のデータベースは機能が少なく(とはいえ Firestore はわりと「これで十分じゃん」ではあるが)、なにか複雑なことをしようとすると、すぐに Cloud Functions という機能に頼ることになる。
Cloud Functions はようするに Firebase の Lambda + API Gateway で、 Firestore になにかが保存されたことをトリガーにして「サーバーレス」のコードが起動される。
典型的にこのトリガーを使うのは以下二つの用途であろうと思う
そして Cloud Functions には API Gateway 的な機能が高度に統合されており、 AWS でやるよりも簡単にサーバーレスな API を作成、デプロイすることができる。
典型的にはこれは以下のような用途で使用されると思う
こうした API を作成するのに必要な知識は、
などであって、極普通にバックエンドエンジニアの知識であろうと思う。
Firebase で本当に不要になるのは「インフラエンジニア」だが、これも実際にアプリが大きくなってくるとどうなるか分かない。すなわち
といったタスクが出てくることは明らかで、これを解決できるのは、その人がその会社でどのように呼ばれていようと「インフラエンジニア」であろうと思う。
しかし、 Firebase を使う場合でもこうした人達が必要で、結局 Firebase を使う意味はなく、従来のとおりのアプリ開発が結局優位性を持つのか、というとそうではないと思う。
といった事情で極めて強力、2018 年に 1 からアプリを作る場合最も有力な選択肢の一つだと思う。
ghq で clone したものを peco で検索したあと cd して tmux を開く というようなことをコマンド一発でいけるようにした。
前提となる環境としてはghqを使ったローカルリポジトリの統一的・効率的な管理について - Kentaro Kuribayashi's blogあたり見てほしい。
結論からいうと以下のようにした。
alias opentmux='tmux -2 new-session -s $(pwd | awk -F "/" '"'"'{ print $NF }'"'"') || tmux -2 a -t $(pwd | awk -F "/" '"'"'{ print $NF }'"'"')'
alias gcd='cd "$(ghq list --full-path | peco)" ; opentmux'
を登録しました。ぼくは以前から tmux でとにかくぐちゃぐちゃにセッションを作ってしまい、同じディレクトリを開いているセッションが大量に作られたりして破滅していたのだけど、これでかなり便利になった。
ConoHa 捨てる作業完了した
Lightsail 安くなって ConoHa を捨てる決心がついた
2ノードだと落ちるときは落ちるな
多摩のビル火災が AWS の予定地だったことを報じる必要はないとか言ってる人たちに言いたいことなんですけど
Amazon が普段通販サイト Amazon への納入業者を買いたたく感覚で建設業者を買いたたいた結果無理な工程で安藤ハザマのようなダメ会社に発注することになって、安全管理がずさんになってこの大事故につながったみたいな可能性結構あると思うんですよ。
IT で無理してもせいぜいが精神壊す人がでるぐらいだけど建設で無理すればこういうことになるし、今回はまあ死んだの作業員だけだけど周辺住民にだって被害が出た可能性もある。 Amazon に発注者としてこの事故に責任があるかどうかとか検証し報じる価値のあることだし、第一報でとりあえず「発注者は Amazon らしい」と報じることに意味はある。
自分たちの身の回りの狭い常識だけで話すんなよ、死者出てるんだし。
転送量課金で滅んだ
ここは Heroku に戻した
CDN でごまかしつつバックエンドは GKE のヘボいサーバー みたいな構成に急速に移行している。
バックエンドを Heroku から GKE に切り替えてみた
記事の読み方 みたいな話なんだけど、こちらの記事をご覧頂きたい。サッカーに興味がないという方もとりあえず見てほしい、僕も一切興味はない。
見出しからいろいろと力強い記述が続くのであるが、結局のところこの記事で意味のある部分は以下のところだけである。
１次リーグ敗退でも２勝１敗など健闘した場合には試合内容などを見た上で判断が下される見通し。監督交代の場合はＵ―２１日本代表監督を兼任する森保一コーチの昇格が有力視される。
「2 勝できれば、現監督は続投で、そうでなければ解任。後任第一候補は手倉森ではなく、森保。」それだけが重要な情報なのであって、あとは意気を示しているだけであろうと思う。しかし、はてなブックマークでも Twitterでもなんでもよいのだが、わりと多くの人がそのように読み取れていないように見える。
サッカー協会としては「善戦してもせいぜい 1 勝」「2 勝できれば奇跡のようなものなので緊急登板の監督に続投の褒美」となどとやる前からハードルを可能な限り下げているのは明らかで、まあある意味彼等は現実を見えてはいるのだが、そのように記事を受け止めている人は少ない。「8 強とか夢見るな」とバカにしている人は多いが「最初から 2 勝で十分とか負け犬の精神」とバカにしてる人はあんまり、というかほとんどいない。
ほんとこういうのどうにかしないといけないと思う。
最近 Conoha 不安定
アメリカの安い VPS みたいの探すかー
ようやくムサンナ県の情勢が頭から抜けてきた
風邪ひいたっぽい
localStorage 使ってるコードいい加減なんとかしないとなあ