手元にあったACアダプタが突然死したため、代わりのを探しているけど、いいのが本当にない。不思議

• アダプタ内で D+ D- ショート(急速充電)
• 1ポートで2A出せること

という条件だけなのだけれど、びっくりするほど存在しない。

これは Android ポートとやらが 2A 出せて D+ D- ショートっぽいけど、無駄に高いし、iPhone も iPad も持っていないので、Apple 側のポートは使いようがない。

これは一個既に持っている。充電用ケーブルを介して使っているけど、そもそも充電用ケーブルというのを持ちたくないので、できれば買いたくない。充電用ケーブルって短いのしかないので、とにかく不便。それに買うとしても1ポートしか使わないし、以下のやつでいい……

ほかに

というのもあるけど、D+ D- の処理がわからない。

これらには当て嵌まらけど、そもそも 2A 対応とか表示してあっても実際は2ポートそれぞれで1Aずつ (合計2A) という意味の場合が多くて、商品を探すこと自体困難。

あるいは最悪、充電ケーブルで 2m 程度のやつがあればいいんだけど、無駄に巻取式だったりして、普通のがない。

「仕様変更」という言葉はプログラム書く人じゃないと、そのイメージが掴めないと思う。イメージが掴めない人に対してそれを説明するとしたら何がいいだろう？ と思った。

とりあえず、料理に例えたらいいのではないかと思ったので、それに例えて考えてみる。

仕様とはレシピのことであり、最終的には具体的に「食べることができる美味しい料理」すなわち「うまく動くプログラム」を作ることを目的としている。

仕様というのは、最初は「イタリア料理」「日本料理」「中華料理」程度しか示されない。当然この時点では方針程度しか考えることができない。食材を買うこともできない。せいぜい使う調味料を揃えるぐらいしかできない。

もう少し進むと、料理名まで具体化される。スパゲティを作りましょうとか、ピザを作りましょうとかだ。とりあえずここまできたら小麦粉を買おうとかまではできるかもしれない。でも実際に作りはじめることはできない。

さらに進むと、ペペロンチーノを作りましょうとか決まってくる。ここまできたらさすがに作りはじめることができる。ペペロンチーノ用にパスタを作って、どんな風味のペペロンチーノにするか決めながらソースを作るぐらいできる。もはや完成間近になる。

しかしここで「仕様変更」が入る。やっぱりペペロンチーノは止めましょう。ナポリタンにしましょう、となる。そうなったらソースは捨ててパスタは作りなおしになる。パスタのことをよく知らない人は「パスタは再利用できるでしょ？」と言ったりする。悪夢である。そして「じゃあ再利用しましょうか、時間もないですし」ということで、今度は今あるものにナポリタンソースでどういう味つけにするかを考えて作ることになる。

しかしここでまた仕様変更が入る。しかも今度はやっぱりペンネにしましょうとか言わたりする。そうですか。小麦粉は無駄にはなりませんが、他のものは全て無駄になりますね。でも仕方ないですね、としかプログラマは言いようがない。でもここでも「パスタは再利用できますよね」「スパゲティを使ったペンネですか？ それはペンネではないような…… とにかくわかりませんが、わかりました」

この繰替えしが何度もある。一度止めたけど、やっぱりそっちにしましょうとか、悪いプロジェクトではそれこそ、そもそも日本料理にしましょうとか言いだすこともある。

結果として、下手に再利用することで不味い料理ができたり、そもそもいつまで経ってもできなかったりする。

また、時間は有限で、例えばお昼までに使える時間というのは限られている。でも11時50分になって「やっぱりナポリタンにしましょう」なんてのはよくあることである。いずれにせよ、このプロセスで最終的にできるものはスパゲティである。

こんな感じで壁に背を向けて座る感じでデスクを設置したので、普通に部屋に入ってくるとき、デスクの裏側が見えるようになってる。

ケーブル自体はデスク裏に貼り付けることで殆ど気にならないようになったけど、ディスプレイアームのクランプ部分がちょっとみっともないって感じだったので工夫して隠した。

クランプ部分は机の厚さによって3段階に調整できるようになっている関係で、1段2穴、3段分 (うち1段は本体の固定用に使用) のネジ穴があるので、余っている穴をうまく利用して隠す板を取り付けようと思った。

ディスプレイアーム自体はデスクに対して取り付け位置が可変なので、完全に固定するような取り付けをするとあとで困るかなと思い、大きな一枚板をそのまま貼り付けるわけではなく、小さな板をまず一枚取り付けて、その上に軽い素材の板 (プラスチックダンボール) を机の幅分、両面テープで貼り付けるという形にした。

最終的に、

1. クランプ金具 (デスクに固定済み)
2. ワッシャーx3 (ゲタ)
3. 木製の15cm四方程度の板
4. 同じサイズのプラスチックダンボール (ネジ山埋める用)
5. M6のネジ (クランプ金具のネジ穴まで貫通)
6. 机の幅分の板

の順になる感じに。

クランプ金具にはM6のネジが切ってあった。金具の中央にちょっと盛り上がりがあって、そのまま板をつけると板がしなってしまうので、ワッシャーでオフセットした。あとネジの頭が隠れるように小さめのプラスチックダンボールを挟んで、ネジ頭をそれにめり込ませるようにした (木にあさりをつけるのは大変なので…)。

机の幅分の化粧板についてはプラスチックダンボールを140cm x 15cmぐらいで切り出して、木目シートを貼ってそれっぽくしてある。本物の木を使ったほうが綺麗にいくと思うけど、このサイズの木だとそこそこ重量があって不安だし、加工するのが面倒なのでこうしてある。ただやっぱりプラスチックダンボールだとしなってしまうので、硬い針金を通すとか、もうちょっと工夫がいりそう。

木目シートは以下のをホームセンターで見てから買った。あんまり置いてなかったけど、これは質感がよくてよかった。あんまり安くはないけど、もっと安いやつは変な光沢があって、あからさまに塩ビって感じがしてひどかったので、これぐらいは仕方ないっぽい。突板を貼るっていうのも考えたけど、突板のほうが圧倒的に高いのでやめた。

申請して承認されないと表示されないという仕様なので、大量のユーザーがいるASPサービス向けなんだろうなー と思いつつ、一応申請をしたら、忘れたころに承認メールがきた。

だいたい3週間ぐらいかかったようだ。「Twitter Cards - Your submission has been approved!」というメールがくる。

ウェブアプリケーションを書くとき、最近はだいたい Plack::Request なりなんなりを継承して、そのプロジェクト専用のリクエスト/レスポンスオブジェクトを作ることにしている。

特にリクエストオブジェクトは、リクエストのパラメータを適切に変換して返すようなメソッドを生やすことが多い。例えば以下の例：

sub number_param {
	my ($self, $key, $limit) = @_;
	$limit ||= 'inf';

	my $val = $self->param($key) // "";
	if ($val =~ /^\d+(.\d+)?$/) {
		my $ret = $val + 0;
		if ($ret <= $limit) {
			$ret;
		} else {
			$limit;
		}
	} else {
		undef;
	}
}

この number_param() メソッドは、$key と $limit という引数をとって、$key という名前のパラメータを数値にして返す。もし数値として評価できないもの、あるいは指定されていなければ、undef を返す。$limit が指定されている場合、$limit を上限とした数値を返す。

同じように、

sub string_param {
	my ($self, $key, $limit) = @_;
	$limit ||= 'inf';

	my $val = decode_utf8 $self->param($key) // "";
	length $val > $limit ? substr($val, 0, $limit) : $val;
}

と、string_param というメソッドを定義したりしている。これも $key と $limit を引数にとり、$key という名前のパラメータを文字列にして返す。$limit が指定されている場合、$limit 長で制限される。

このようなメソッドをリクエストオブジェクトに生やす利点は、

• 型を明示することで予期せぬバグを防げる
• パラメータ値のような信頼できない値を事前にチェックできる
• 全体で統一した型変換アルゴリズムを設定できる
• コントローラなどでコードの可読性が向上する

あたりがあると思っている。

文字列化まわりは、フラグまわりでハマったりするので、明確に「これは文字列である」というのをコード上でわかりやすくしたほうがバグが出難いと思う。

数値変換も、ページャを素朴に実装すると、巨大な数字を指定されてほぼテーブルフルスキャンかかっちゃいました、みたいなことが起きたりするので、数値に制限をかけたりするのが簡単にできると捗ると思う。

param() を直接使うのはできるだけ避けるべきだと思う。

それなりに探しても好みのものがないので、作ろうかという気持ちになってきてる。

とりあえず図面を描いてみた。スライドレールをつけたいけど、その分の寸法を入れてない。スライドレールにどういう種類があって、どれを使えばいいかよくわかってない。

この図面の目的は切ってくれるサービスを利用した場合、どのぐらい値段がかかるかを知ることにある。実際、これで考えた板の寸法を入力して見積りしてみたら最安でも2万ぐらいになった。材料費だけでも結構いく。

接合方法を考えたとき、引き出しの中身は普通に木ネジ的なものでいいけど、外側は表にネジが出ないように、ダボ継ぎしたい。

疑問：ディスプレイサイズが大きくなるほど鑑賞距離も長くなっていき、ppi もそれほど必要なくなるはずだが、実際のところどれぐらいの ppi が必要なのか?

var libphoto = require('../lib/libphoto');

function displaySize (diagonal, width, height) {
	var r = Math.sqrt(Math.pow(diagonal, 2) / (Math.pow(width, 2) + Math.pow(height, 2)) ); 
	return { width: width * r, height: height * r };
}

var inch = 15.4;
var size = displaySize(inch * 25.4, 16, 9);
console.log('%dmm x %dmm', ~~size.width, ~~size.height);

// シンボルの認識限界とされる画角 ( http://gc.sfc.keio.ac.jp/class/2005_22267/slides/04/11.html )
var angleOfView = 30 * Math.PI / 180;

// ディスプレイサイズの横幅が上記画角になるときの距離
var distance = libphoto.angleToFocalLength(size.width, angleOfView);
console.log(Math.round(distance), 'mm');

// 視力1.5 の人がぎりぎりピクセルを区別できる程度のディスプレイ解像度
var ppi = libphoto.dpiByDistanceAndVisualAcuity(distance, 1.5);
console.log(Math.round(ppi), 'ppi');

今家にある本をできれば電子書籍化したいのだけれど、するならするでちゃんとしたいと思ったとき、何が制約になるかないし電子化できないものは何かを考えた。

現状だと 10 インチ 300ppi (Nexus 10) がまともな解像度を持っている中で最大のサイズなので、これ以上に大きなの書籍は電子書籍化しても、元の品質レベルで閲覧できるデバイスがない。持ってないので実際のディスプレイサイズは知らないけど、21cm * 13cm ぐらい……？ だとすると、これに収まる範囲の紙のサイズは

• A6 (14.8cm * 10.5cm)
• B6 (18.2cm * 12.8cm)

で、ひだまりスケッチ サイズ (20.8cm * 15cm) はぎりぎり残念ながら縮小されてしまう (普通に考えれば許容範囲だけど)。

with (Math) (function (diagonal, width, height) { var r = sqrt(pow(diagonal, 2) / (pow(width, 2) + pow(height, 2)) ); return [width * r, height * r] })(10, 2560, 1600);
//=> [ 8.47998304005088, 5.2999894000318 ]

実際出力装置が出揃っていないのは、今後の技術革新でどうにかなるかもしれない (とはいえ結構先だろうけど)。一先ずまともなスキャナーで十分な解像度でスキャンできれば、偏執的に保存しつつ保有コストを下げることはできそう。

しかし、カラーマネジメントしてスキャンする環境を整えるのは難しく、閲覧デバイスも今のところ皆無のため、写真集に関してはもしかしたら作家がこだわっている可能性があるので、オリジナルを失う電子書籍化はできないことになると思う。裏をかえすと、色にものすごいこだわりのある作家は電子書籍で出版できないか、しても妥協の産物にしかならない。一方、一番邪魔なのは写真集なのがむずかしい。

これから先電子書籍閲覧端末は

• 大型化
• それに耐えうる高解像度化
• 十分なカラーマネジメント

が必要で、これらがないと、それなりの本が電子書籍化しても残念な感じになる。結構雑誌とかでも大きめのサイズのものが今は多いけど、電子書籍がメインになっていくとどうなるかわからない。写真雑誌とか、電子書籍の環境で読んでも、色がまともか判断つかず悲しいことになりそう。