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

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

クランプ部分は机の厚さによって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() を直接使うのはできるだけ避けるべきだと思う。