気づけば僕の手元のVMはdocker-machineだけになっていた…

会社の手元マシンにも自宅の手元マシンにもVirtualBoxを入れているんですが、気づけばVirtualBoxの中にいるVMはいずれも一つだけになっていた。

その正体はdocker-machineのboot2docker。結局dockerだけで済むから他にVMなんて作る必要はなかったんだ。

確かに、時にはdockerではどうにもならないこともあって、vagrant使うこともあるんだけどね。でも大抵はdockerでどうにかなる範囲なんだわ。boot2dockerは割と良くできていると思う。他にもRancherOSとかその他いろいろと競合はあると思いますが、まあ簡単だし、そこはあんまり重要じゃないところ。VirtualBoxである必然性もなくなっている。

dockerイメージはalpine無双の時代が長かったですが、そろそろ過ぎつつあるのかな。自分は今でもdebian:jessieとかubuntuとかcentos:centos7とかopensuseとか使うことが多いですけど、今のメインストリームは、成果物のバイナリのみを/に置いてentrypointにする、というもの。あと必要であればroot CAの証明書も配置する。busyboxもshもない。scratchからCOPYで置く。確かにそれが最強だよな…

今だと別の場所でビルドしてgithubあたりにリリースファイルを置いて、ADDでダウンロードすることになるのかな。ただ、今度からはDockerfileの中でビルドして、結果だけを別イメージに置く、みたいな書き方をしやすいDockerfileになるらしいです。

Golangはその点、そういう感じでビルドしやすいようにできている。前段のビルドで1個のバイナリを作って、後段でそのバイナリを配置する、という。javaやrubyやnodejsとかだとそうは行かない。処理系もそうだし、依存するライブラリのファイルも配置していく必要があって、なかなか大変だ。Rubyのbundlerやnodejsのpackage.jsonも良くできていると思ったけど、不完全だったんだなぁ。Rubyやnodejsでも、処理系や依存パッケージまでまとめて一つの実行ファイルを作る感じのビルドができるように、いずれはなるのかもしれない。

androidのアプリ履歴

一括削除がないので消すのが大変だったが、暇な時間でひたすら消して消して消しまくり、、、

ついにきれいになりました! 達成感!!

今季最悪のUI大賞はこれで決まりかな…

いやまだ上がいるという確信が…

多摩川の土手の改善

多摩川土手の川崎側の進化が止まらない。とりあえず二子のあたりと、等々力のファミマのあたりでの改善がスゴい。何より道が広いし、舗装もしっかりしている。いずれは全体的にああした仕様になるのだろう。待ち遠しいぜ。

二子〜丸子橋の東京側、丸子橋〜ガス橋の川崎側がひどいので、あのへんを最優先かな。東京側はかなりの大工事になるかも。あと多摩川大橋(国道1号)の上流川崎側はすごい改善したよね。立派な休憩所まである。

丸子橋から下流は東京側の方がだいぶ良いんだよな。丸子橋の近くの東京側は工事をしていたけど、もう終わっているのかも。今度見に行ってみようと思った。

giteaがLFSに対応してた

乗り換えるか否か…

giteaのlfs対応を見てみた。まあ、ひととおりのところは使えるみたい。droneから見るときはgogsと同じだと思えばいいのかな?

とりあえず、lfsを使うケースとしては、リポジトリサーバとしてバイナリをそのまま放り込んでraw urlでアクセスさせるとか、そういう使い方が考えられる。

raw url対応はどうか。

  • サイズ0のファイル(非LFS)が1024バイト読める
    • なぜ? 
    • gogsもそれは同じだった
      • 簡単なバグで原因は分かった気がする。gogsのほうにissueを書いてあげたけど、直すかなあの人…
    • それ以外のサイズにするとちゃんとしたデータが読める
  • LFSのraw urlは普通のやつとは別形式
    • メタデータっぽいものが読める

というわけで、あんまりraw urlは信用できないっぽい。まー、しばらくはgogsかな。gogsはraspi向けビルドも分かりやすい置き方だから助かる。むかしgogsでarm用のをraspiで使おうとしたらNGだったことがあるんだよね。それでraspi向けビルドを使うようにしている。

droneの遊び方

先日こういう話があったばかりだが、、、

CIツールのdroneは仕事でよく使っている。非常に便利なものであって、広まって欲しいなと思っているんです。

そこで、自分でローカルで遊ぶのはどうやるんだろう、と思った。昔はdroneにCLIがついていて、MacでそのCLIをコンパイルしておいて、docker-machineで立てたdockerを相手にローカルディレクトリの.drone.ymlを実行するみたいなことができたんだけど、今はもうできなくなっているようだ。

そこで、docker-composeでコンテナを立てることを考える。drone自身はアカウントを持たないので、ログインするアカウントとして連携できるリポジトリサーバが必要。リポジトリサーバは色々対応しているが、こちらもローカルで立てるんなら、gogsが最も手軽だろう。

そこで、適当にディレクトリを掘って、こういうdocker-compose.ymlを作る

そして、実行する。

# DRONE_SECRET=$(uuidgen) docker-compose up -d
Creating network "drone_default" with the default driver
Creating gogs
Creating drone
Creating agent
# open http://$(docker-machine ip):3000
# open http://$(docker-machine ip):8000

3000の方がgogsで、8000の方がdrone。gogsはsqliteでセットアップする。他のDBMSにしたい時は適宜docker-compose.ymlをいじってDBのコンテナを立てればいいと思います。URLやドメイン名はdocker-machine ipのIPアドレスを使うといいだろう。リポジトリを作ってpushしてみよう。

gogsでひとしきり遊んだら、次はdrone。droneにはgogsで作ったアカウントでログインする。droneにログインするとgogsで作ったリポジトリが表示されるので、それをスイッチオンするとサクサク連携されてwebhookが設定される。リポジトリのREADME.mdにバッヂをつけたり、色々やって遊んでみるといいと思います。

普通のgithub.comとかとも連携できるので、必要であればどっかでVMを借りてgithub.comと連携させるということも考えられるが、その時はDRONE_OPEN=falseにしてアカウントを手動登録にしたり、organizationで限定したり、証明書や秘密鍵を設定してhttpsにしたり、工夫しようね。

で、.drone.ymlを作ってcommit / pushすると書いたものが実行されます。droneのイメージはlatest(現在0.6系)なので、pipelineを書いていく.drone.ymlを作る必要がある。普段よく使うのは0.4系のやつで、いきなりimageと書き始めているんだけど、その形式だと0.6系のdroneではタスクが始まらない。いつも古いのを使っている自分にはpipelineを書くのはちょっと違和感があるけど、ちょっと使ってみるとpipelineとserviceを書いて複数のコンテナを直感的に扱えるようになったのは便利になっていると感じる。DBや色々な関連サービスをちゃんと書いてテストできる。これはいろいろと捗る。間違いなく。

デプロイや通知のプラグインもこのpipelineに乗せて実行していく感じになるみたい。サーバ側で設定しなくても、そのまま行けるのかな? droneのdockerイメージは非常に潔くて、/bin/shすらない。/droneのバイナリとSSLのルートCAの証明書がぽつっとあるだけのイメージ。alpineやbusyboxですらない。/droneは管理コマンドにもなっているので、ひととおりの管理はできる。なるほどこういう作り方もあるんだなぁ。

DOCKER_HOSTとかを工夫すれば/var/run/docker.sockではなくTCP接続にできるんだろう、たぶん。たくさんCIを回すようになったら、swarmクラスタで回したいだろうからな…

川崎0-0広州恒大 (悪条件)

明るいうちはかなり穏やかだったんですけどね。会社を強引に抜け出して向かってみると雨がぱらつき、何か嫌な予感が…そして雨や風はぐんぐん強まっていく。アジア最強の呼び声高い広州をホーム等々力に迎えたACLグループリーグ。川崎はここまで3引き分けと勝ちがない中にも、相手に勝ち点3を与えずにローポイントグループを作り出すことに成功してきた。3試合終わって3ポイントの3位、1位と2位は1勝2分で5ポイントだから、残り3試合もあるし、逆転の可能性は十分すぎるほど残っている。

この気候条件にいつもと違うボール。こりゃ技術の差が出やすい条件だなぁと。川崎は憲剛を後半に温存する作戦。時間限定なら後半の方が効くだろうな、というのは全くその通り。

広州は風向きを見たためか、コイントスでサイドを変更。やってきますね。

試合が始まってみると気候条件をモロに受けて川崎はいつものようなパス回しはできない。浮き球を多用するも、なかなかつながらない。広州の選手のポジションも良くて、川崎のパスやドリブルを要所でザクザクカットしていく。ただ川崎も最後のラインは割らせない。ロースコアゲームの予感を漂わせて前半は終了した。基本、雨風が強くて、雨が弱まると代わりに桜が舞う。とにかく何かしら舞う感じでね。中国から来た人もこんな天候で、災難でしたね。先週だったら暖かかったのに。

前半の終わり頃のアップ風景を見て、後半は頭から憲剛を入れてくるなというのは感じられた。一人だけベンチコートを脱いでアップをしていた。そしてハーフタイムも出てこないのでまあ確定だなと。誰と替えるかは問題だけど、板倉だった。なるほど。憲剛ならこの条件にも負けないだけの技術があるし、なんとかしてくれそうな感じはあった。実際に後半が始まって少し経つとグッと川崎のサッカーになってきて、憲剛のゲームといった様相になってくる。

しかし相手も最後のラインは割らせないし、こっちのシュートもコースが甘くてGKに防がれ、いい展開を作ってもクロスが精度を欠いたりで、ついにゴールには至らず、4引き分け目をマークして寒い一日は終了した。

帰りは雨がひどければ自転車を置いて帰ろう(そして明日の朝の出勤時に拾っていこう)と思ったけど、弱まったのでそのまま乗って帰ってきた。

川崎1-1甲府 (川崎72-63三遠)

桜がちょうど満開となったこの日。天気は悪くて花見日和とは言い難かったが、陸前高田ランドもあって誰もがご機嫌なこの日。ホームに甲府を迎えて久々のリーグ戦。怪我人が多いのは誰しも気になるが、とにかく期待は高まって試合はキックオフした。ドローンが飛んでましたね。

ゴール裏にいたので試合はあんまりよく見えなかったけど、そんなにうまく回ってる感じはしなかったなぁ。大島不在の影響かな。ネットと憲剛、森谷…まずまず行けそうなメンツではあったが。前線は森本を使った方が小林悠がやりやすいんではないかと思った。それでも相手GKが活躍するくらいのところまでは攻めることができていた。ハイネルも噛み合ってきている。ロスタイムの打ち合いはお互いの甘さが出たかな。まあすぐにACLの広州戦があるから、しっかりアジャストしてもらいたいところ。私はというと…ACLのチケット買い忘れた…アジャストできてないじゃん。ACLは席割りが変わるとかいう話。これは異常だったACLの席割りが普通になるってことと理解しているが、どうなるだろうか?

そして今日は子供が行きたいと言ってくれたので、帰りにとどろきアリーナでバスケを観戦。子供は非常に楽しんでくれたみたいですが、習い事はサボらせてしまいました。そして帰り道に先輩に見つかるという。

こちらのブレイブサンダースは強すぎて、優勝&プレーオフ進出をとっくに決めて、残り消化試合が何試合あるんだという有様。ていうか消化試合多すぎ…強すぎるのも考えものです。

こないだの小杉の花見市でもらったパンフレットを持っていけば良かったんですが、持ってこなかったのでフロンターレの会員証割引で入りました。試合は十分に楽しめて、このくらいなら安いもんです。観客数は割と寂しかった。消化試合という事情はある。ただ、東芝も来季あるか分かりませんし、みんな見に来た方がいいと思います。ブレイブサンダースもその辺は結構焦りもあるみたいで、以前よりも積極的にPR活動をしていますよね。近所割引のハガキを配ったり、地域の祭りに出店したり、今日みたいにフロンターレの後援会割引とか。この日は荏原製作所のクジもあってお得感は高かった。当たればかなり良いノートがもらえたし、外れてもよくできてるクリップがもらえた。うちは4人で行って当たり2、外れ2という戦績だった。この日もフレッシュマンデーということで、そういう企画もやりつつある。

試合の方は#22は以前より動きも良くなった上に相変わらずの技術の違いを見せつけ、#14も肝心なところで3ポイントを決め、守ってはシュートを打たせずにトラベリングを誘う場面も連発。一時はかなり点差を詰められたがディフェンスで踏ん張り、最後は突き放して危なげなく終了。序盤はお互いにシュートが決まらない場面も多かったが、終わってみればこの安定感。ポストシーズンに向けて整って来ている、強いチームという感じを受けた。プレーオフの短期決戦というのはリーグ戦とは異なる部分もあると思うが、連覇…期待できるんじゃないだろうか。

俺たちがHTTP/2.0対応に四苦八苦している間に奴らは…

Googleは勝手にQUICとか使ってやがるんですよ。ひどい話。UDPだから高速なんだ…っていつの時代の話だよ?

このブログのnginxをHTTP/2に対応させました。nginxなんで最初から対応していると思うでしょ? しかしながら、ブラウザ側がALPN必須になったために、ALPNに対応していないOpenSSLバージョンを使っているCentOS7では普通にnginxを入れただけではHTTP/2を使うことができないんです。

src.rpmから少しいじってコンパイルして入れていたんですけど、アップデートがあるたびにHTTP/2対応が消えていく。しょうがないので、毎晩src.rpmをチェックして更新があれば最新のOpenSSLをダウンロードして組み合わせてビルドして更新をかける…といった設定にしました。無駄に手間かけさせやがって。まーこれは、OpenSSLをALPN非対応のまま放っておくCentOS(RHEL)が悪いよね。クソが。

QUICはどうなんでしょうね。とりあえずリバースプロキシ噛ませれば行けるのかな?

ざっと眺めると、botはまだHTTP/2を喋らないものが多いようですね。Googlebot/2.1もHTTP/1.1です。これはしばらく人間の選別に使えたりして??

DAZN for Chromecast (仙台0-2川崎)

仙台戦は先日晴れて対応となったChromecastで見ましたが、クルクル現象や解像度激落ち君(左上のスコアが全く読み取れないレベル)は頻発しますね。当家のChromecastのネットワーク環境はそれほど良いとは言えないこともあって、あまり安定した視聴とは言えなかった。YouTubeとかは普通に見れているんですけど、YouTubeの動画は2時間もぶっ通しで見るわけじゃないので比較するのはフェアではなかろうと思う。今度比較のためにYouTubeで長そうなゲームや麻雀の動画でもぶっ通しで見てみようかな…

で、奇妙に思った部分。最初はChromecastに出すと電話の画面には動画は出なくなるんだけど、クルクル時に色々操作していたら電話の画面にも動画が出るようになった。そしてChromecastでクルクル現象が起きている間にも電話の画面は快調に出力され続け、数分の違い(電話画面の方が時間の進みが早い)が。うーむ。

Chromecastで動画が出てくるまでにしばらくかかるのも気になったな。これではザッピングできないじゃないか。前日に野球とかやってたんで予行演習とばかりにChromecastで見てたんだけど、その時は割と悪くないと思ったんだけどね。チャンネル切り替えはもうちょっと素早いといいと思いました。

Androidでホーム画面にブックマークを置くときに…

モバイル対応のサイトだと、ブラウザからブックマークしただけなのにアプリみたいに表示されるじゃないですか。Chromeじゃなくて内部ブラウザで表示されるってやつ。apple-mobile-web-app-capableなんですが。

これが若干ウザい。Chromeで表示したいんじゃー、と思うことがあるんです。ただ作ってしまったホーム画面のリンクはWebViewで表示されてしまう。そうした場合に、何らかの操作でChromeで表示されるようなリンクをホーム画面に作れないかな、と思ったわけです。

問題はapple-mobile-web-app-capable。これがあるとアプリっぽいWebViewでの表示になる。

ふと閃いたので、以下の方法を試してみたら、Chromeで開くリンクをホーム画面に作れます。

  • 機内モードにする
  • Chromeで該当サイトを表示する
    • 当然、表示できません
  • この状態でホーム画面にサイトを追加する
  • (機内モードを解除する)

するとこれは…なんということでしょう。Chromeで表示されるリンクができました!!

つまりapple-mobile-web-app-capableと書いてない状態でそのリンクをホーム画面に作ればいいんですね。