2014年に飲んだビール

おきゃんさんが 2014年飲んだビール – Oh! Can Not Diary というブログを書いていておもしろかったので便乗することにします。

真澄 Red Horizon

IMG_0769

エチゴビール レッドエール

IMG_1010

オクトーバーフェスト

IMG_1023 IMG_1025 IMG_1041

ブーン・グース

IMG_1067

グラゼントールン・ヤン・ドゥ・リヒトゥ

IMG_1089

BFMアッべヒ・デ・セイント・ボン-チイエン

IMG_1091

新潟のビアバー、Beer Trip Olive。

IMG_1357 IMG_1359 IMG_1362 IMG_1363

アンカー ビッグリーフメープル

IMG_1433

ロンドン・プライド

IMG_1468

ネストビール アンバーエール

IMG_1619

ヤッホー 僕ビール、君ビール

IMG_1624

ネストビール ペールエール

IMG_1683

欧和 桜ランビック、山伏 弐 セゾン・ノワール

IMG_1691

ダーク・アイランド・リザーブ

IMG_1884

BFMアッベヒ・デ・セイント・ボン-シェン2013

IMG_1898

まとめ

今年一番印象に残ったのはやはりBMFのボン-シェン 2013かな。

写真はあるけど何か覚えてないものもあったので来年は細かく記録したいですね。

iremocon wifiを買った

かなり前に発表されていた iremocon wifi 、西日本のフレッツでしか使えなかったのがニフティのサービスで使えるようになっていたのでさっそく申し込んでみた。おへやプラス という見守り系のサービス。申し込んだ少し後に一般販売が始まったけど気にしない!

箱はこんな感じ。

写真 2014-12-09 19 46 30

箱から出してみた。サイズ見てなかったけど思ったより小さい。直径10cmくらい。

写真 2014-12-09 20 05 45

設置。iremocon wifi は温度・湿度・照度の計測ができるので、比較として手持ちの温湿度計を並べておいた。赤外線の出力はかなり強力なようで、設置したのはエアコンと同じ側の壁なんだけどちゃんと操作できる。

写真 2014-12-09 20 45 56

アプリに端末を登録する時にエアコンや照明のリモコンをメーカーから選択して登録できた。

エアコンはこんな感じ。操作はけっこうもたつく。エアコンのリモコンは液晶パネルがついてて設定が見えるけど、アプリの場合は見えない。今エアコンがどういう状態なのかが分からないのは不便。エアコンのAPI叩いたら情報を返してくれるような仕組みがほしい。

写真 2014-12-09 21 15 04

照明。いろいろボタンがあるけど自宅の照明はボタンが1つしかなくて4段階位をトグルするだけなので、1個だけでよかったりする……が、UIデザイナーというものでオリジナルレイアウトのリモコンが作れるので、それを使えば解決するはず。

写真 2014-12-09 21 15 20

iPhoneアプリからセンサ情報を見た所。温湿度計と比べて、湿度にかなり差がある。

写真 2014-12-09 21 15 32

音声操作やタイマー機能もついているので、朝に照明を点ける設定をしてみた。そういう用途だとhueがよさそうだけど……

APIの仕様書が公開されたらセンサの情報を記録して遊ぼうかな。

 

デジタルネガを使った暗室プリント体験

通常、暗室におけるプリントではフィルムを現像したネガを用いる。しかし、デジタルデータからネガを作成してプリントする技法があることを知り、東京都写真美術館が開催している「モノクロ銀塩プリントワークショップ(ハイブリッド方式)」で体験してきた。

以前からデジタルネガに興味はあったのだが、自分で試すには敷居が高い(プリンタ、専用の紙(ピクトリコ)が必要)ため、写真美術館のワークショップへの参加を狙っていたのだ。

今回は2枚プリントすることができた。ボランティアスタッフの手で印刷されたデジタルネガは4×5のサイズだった。このサイズのネガを見るのは初めてだっため、なかなか新鮮だ。そのままでも結構見られるため、ポジフィルムだともっとすごいのだろう。

IMG_1135

印刷されたネガは、片面にインクが乗っているため、乗っていない側から見るとボンヤリとしている。上の写真はインクが乗っている面を下にしている。

ネガのサイズが大きいが、プリントでやる事は35mmと変わらない。暗室でのプリントは4〜5年ぶりだったが、結構体が覚えているもので、すぐにサクサクとプリントできるようになった。

IMG_1137

RCペーパーにプリントされた写真。1カットにつき5〜6枚プリントした。ボランティアスタッフの方にアドバイスを頂きつつ完成に追い込んでいく作業は楽しいもので、あっというまに時間が過ぎてしまった。

プリントの質だが、ネガからプリントした写真を最後に見たのがかなり前なので比較するのは難しい。が、やはり黒色は綺麗に出ていると思う。同じ画像をネットプリント等で出力して、見比べてみたい。

久しぶりの暗室作業だったが、PCでやるのに比べ、やはり作業自体が楽しい。紙に絵が浮び上がる瞬間や、暗室から出て光を当てる時間を検討したりするのは、PCでは味わえない。年に一度位、レンタル暗室で作品を作るのもいいなと思った。

そうそう、今回は引伸機を使って印画紙に焼いたのだが、実際にはデジタルネガを印画紙に密着させて焼き付ける方が主流らしい。この方法だと引伸機が必要ないので、自宅でプリントする敷居が下がる……うっかり機材を揃えたくなるので注意しないといけない。

Go言語の構造体でタグを使う時のメモ

型の後ろに「xml:"hoge"」と書けば,Marshal・Unmarshal時に対応づけてくれる.

[go]
type Foo struct {
Hoge string xml:"hoge"
}
[/go]

jsonもOK.

[go]
type Foo struct {
Hoge string json:"hoge"
}
[/go]

xmlとjson両方設定する場合はスペースで区切る.

[go]
type Foo struct {
Hoge string xml:"hoge" json:"hoge"
}

type Foo struct {
Hoge string xml:"hoge" json:"hoge"
}
[/go]

DockerのストレージバックエンドにBtrfsが使えるようになってたので試した

みなさんこんにちは。 最近Docker Meetup in Tokyo #1の参加を逃したりImmutable Infrastructure Conference #1の参加申し込みに出遅れたりしてがっくりしている@r_takaishiです。

さて、今回はDockerのv0.8でストレージドライバに新しくBtrfsが追加されたので、これを試してみました。

Btrfsをストレージとして使うための準備

まずは、DockerがBtrfsをストレージとして使えるようにします。 なお、環境ですが、Vagrant + Ubuntu13.10 を使用しました。 Dockerのインストールは公式ドキュメントに従っています。 Btrfsを使うための手順は以下の通りです。

  1. Btrfsなパーティションを作成 & マウントする
  2. Dockerデーモンの起動オプションでストレージドライバとデータ保存先のディレクトリを指定する
  3. Dockerデーモンを再起動する

Btrfsなパーティションを作成 & マウントする

適当にストレージを追加して、mkfs.btrfsでファイルシステムを作成、任意のディレクトリにマウントするだけです。 今回は、「/opt/docker」にマウントしておくことにします。

Dockerデーモンの起動オプションでストレージドライバとデータ保存先のディレクトリを指定する

Dockerのデーモンは標準だとストレージドライバにaufsを、データの保存先には「/var/lib/docker」を使用します。 これを、ストレージドライバにbtrfsを、データの保存先には「/opt/docker」を使用するように設定してあげます。 サービスとして起動しているので、その設定ファイルである「/etc/default/docker」内の「DOCKER_OPTS」を以下のように書き換えます。

[bash]
DOCKER_OPTS="-s btrfs -g /opt/docker"
[/bash]

Dockerデーモンを再起動する

再起動しましょう。これで、ストレージドライバにBtrfsを使うようになります。

[bash]
sudo service docker restart
[/bash]

aufsとbtrfsで、コンテナのビルド速度を比較する

Btrfsストレージドライバを触っている時、ビルドに時間がかかるような気がしたので、aufsと比較してみることにしました。 比較する操作は以下の通り。

  1. ubuntu:13.10をベースにイメージを作成(ubuntu:13.10はあらかじめpullしておきます)
  2. 1で作成したイメージをベースにイメージを作成
  3. 2で作成したイメージをベースにイメージを作成
  4. 2〜3を100回繰り返す

これらの操作を行うスクリプトをRubyで書き、1〜4に要する時間を測定しました(測定回数は一応5回)。 その結果、以下のように大きな差がありました。

  • Btrfs:平均256秒
  • aufs: 平均47秒

実に5倍の差があります。現時点で、Btrfsストレージドライバは実験的なものではあるのですが、これ程差があるとは思いませんでした。 仮想マシンを作成する事に比べるとはるかに高速ですが、それでもインフラをCIするような、ビルドを何度も繰り返すことになるケースだと遅く感じる事がありそうです。 今の所aufsの使用で困っている事はないので、Btrfsストレージドライバをメインに使うのはしばらく先にしようと思います。 Btrfsストレージドライバが遅い理由までは今回は調べることはできていません。現状の実装の影響なのか、そもそも仕組みからして遅い、という可能性もあります。 後、これもきちんとは調べていないのですが、aufsで100個近くヒストリを繋いでいると、後半にいくにつれて若干ビルドに時間がかかるようになっていたような気がします。 今後、調べてみたいですね。

備考

測定に使用したスクリプトは以下の通りです。出力が汚いけど気にしない。

 

[ruby]
— coding: utf-8 —

require ‘benchmark’ require ‘systemu’

5.times do |count|
# Btrfs用。作成したイメージ等を全削除する。 #sudo service docker stop #cd /opt/docker && sudo btrfs subvolume list . | awk ‘{print $9}’ | xargs -I{} sudo btrfs subvolume delete {} #sudo rm -rf /opt/docker/*
# aufs用。作成したイメージ等を全削除する。 sudo docker images | awk ‘{print $3}’ | xargs -I{} sudo docker rmi {} sudo service docker stop sleep 2 sudo rm -rf /var/lib/docker
# サービスの起動と初期イメージの取得 sudo service docker start sleep 2 systemu "sudo docker pull ubuntu:13.10"
# ビルドの繰り返し(ここの時間を測定) Benchmark.bm do |x| x.report("#{count}: ") { base_id=” status, stdout, stderr = systemu "echo ‘FROM ubuntu:13.10\nRUN echo init >> /log’ | sudo docker build -t base -" stdout.each_line do |line| if line =~ /Successfully built (.*)\n/ base_id=$1 end end

100.times do |num|
status, stdout, stderr = systemu "echo ‘FROM #{base_id}\nRUN echo #{num} >> /log’ | sudo docker build -t #{num} -"
stdout.each_line do |line|
# puts line
if line =~ /Successfully built (.*)\n/
base_id=$1
end
end
end
end
[/ruby]