両面テープ式のフック(100均)でワイヤーラティス(100均)を固定して、それにいろいろくくりつけるようにした。

最初、突っ張り棒でワイヤーラティスを固定しようと考えていたけど、フックでも十分な耐荷重を得られそうなのでこっちにした。ただ、経年劣化が心配。

天板裏に貼り付けると殆ど視界に入ることがなくなるので良い。

買ったワイヤーラティスでは案外狭くてごちゃごちゃしてるけど、とりあえず見えない部分については考えないことにした。

固定にマジックテープのやつを使ってみたけど、結構便利。ただ、値段の割にあんまり長くないので、ケーブルタイと併用せざるを得ない…

1. トップ
2. tech
3. 100均グッズを使ってデスクの天板裏でケーブルの整理

届いてから、一通り使いはじめることができたので、感想を記録しておく。やはりケーブルの処理が難しい。ケーブル自体になにか工夫がいりそう。

DELL U2713H は SD カードリーダーがついているのが地味に便利で、既に結構使っている。USB 3.0 のハブがついている点も嬉しいと思う。

ColorMunki Photo と付属のソフトウェアでキャリブレーションしたら以下のようになった。(ディスプレイ側の設定は Preset Color Space -> AdobeRGB) 灰色は AdobeRGB の色域。

ディスプレイアームはエルゴトロンのやつで、買う前は本当に必要だろうか？と思ったけど、結果的に買って良かった。というのも、普通にデスクに座ってディスプレイを見る、という用途と、完全に反転させて位置を下げて、床 (ホットカーペットをしいてる) に横になったままディスプレイをダラ見する、というのが両立できて捗るのです。

最初ディスプレイの重さでアームが下がってくる現象があったけど、説明書に従って調整したらいい感じになった。スムーズに動くし、よくできてるなあと思った。

ディスプレイフードもだいたいできたけど、内側のフェルト貼る作業が微妙に残ってる。

前書いた通りだけど、コストパフォーマンスは十分に良いと思う。

1. トップ
2. tech
3. DELL U2713H 使用感とディスプレイアーム

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

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

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

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

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

ほかに

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

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

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

1. トップ
2. tech
3. 急速充電用の USB ACアダプタでいいのがない。

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

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

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

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

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

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

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

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

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

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

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

1. トップ
2. tech
3. プログラムが書けない人に「仕様変更」について説明するには

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

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

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

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

最終的に、

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

の順になる感じに。

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

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

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

1. トップ
2. tech
3. デスク裏の整理

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

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

1. トップ
2. tech
3. Twitter Card が承認された

ウェブアプリケーションを書くとき、最近はだいたい 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() を直接使うのはできるだけ避けるべきだと思う。

1. トップ
2. tech
3. リクエストオブジェクトへ、型を明示するメソッドの追加