長らく (本当に長らく) 欲しかった食洗機をついに購入した。今迄購入に踏み切れなかったのは、置く場所がとにかく問題だったからだ。しかし、いろいろ検索した結果、開きなおって、無理矢理スペースを造りだすことにしたらなんとか解決した。

食洗機の設置

うちはカウンターキッチンみたいな形でシンクが設置してある。その横に、普通の棚 (IKEA で前に買ったもの、キャスターがついていたが安定性のためはずした) を置き、純正の食洗機用置き台 (かなりしっかりしてる) と、それにつける足で、シンクと高さをあわせ、シンクを拡張する形で置き場を無理矢理つくった。シンク横すぐにも壁があるため人間が多少出入りしにくくなったけど気にしない。

食洗機の蓋をあけたときに、蛇口とかにあたらないようにするとかを考えると、いろいろギリギリな感じになってしまった。けどとりあえず設置できたのでよかった。

Panasonic 食器洗い機用置台 N-SP3 シルバー - パナソニック(Panasonic)

パナソニック(Panasonic)

3.0 / 5.0

ナショナル/パナソニック 食器洗い乾燥機用・高さ調整脚(高さ120~190mm)Panasonic N-SL19 - パナソニック(Panasonic)

パナソニック(Panasonic)

3.0 / 5.0

購入と分岐水栓

食洗機自体はパナソニックの NP-TR6 を買った。ビルトインではなく、このような後付けの食洗機は各社あまり作っていないようで、実質パナソニック一択だった。基本、賃貸向けの製品はメーカーの眼中にないらしい。パナソニックは分岐水栓の開発とかも含め、プチ食洗とかも頑張っていて印象が良い。

本体とは別に分岐水栓 (1万ぐらいする) が必要なので、棚なども含め、そこそこ金がかかる。

パナソニック 食器洗い乾燥機 NP-TR6-W ホワイト - パナソニック(Panasonic)

パナソニック(Panasonic)

5.0 / 5.0

分岐水栓の取り付けば自分でやったんだけど、結構大変だった。

もともとついている蛇口が相当固く締められていて、体重をかけて回さざるを得なくて疲れるし壊してしまわないか心配だった。モンキーレンチ(可変幅のレンチ)でやったのも難しくした原因の一つであると思う。

蛇口本体をまわさずに締めているカバーだけを回す、みたいなことをしないといけないんだけど、どうしても蛇口本体もまわってしまってだいぶ困った。その蛇口専用の工具 (本体をつかむための) があれば良かったんだけど、生憎それが必要なことを知らなかったので、別の工具で代用してしのいだ。

ただ、単に疲れただけで、手順的にはそんなに難しいものではなかった。

スーパーツール(Supertool) モーターレンチ MF230 - スーパーツール(Supertool)

スーパーツール(Supertool)

3.0 / 5.0

洗剤

実際に洗ってみたけど、汚れは本当に綺麗に落ちてびっくりするぐらいだった。ただ、水のミネラル分らしき白い斑点が思いのほかつく。黒いプラスチックの弁当箱だとこれはかなり目立って、結構気になる。洗剤によるのかもしれないし、汚れ自体は落ちているので、神経質に気にしないことにする。

今回買った食洗機には、試供品として「クリスタジェル」と「フィニッシュ」というやつがついてきた。

チャーミークリスタ クリアジェル 食洗機用洗剤 本体 480g - チャーミー クリスタジェル

チャーミー クリスタジェル

3.0 / 5.0

フィニッシュ 食洗機 洗剤 パウダー 本体 700g (約155回分) - フィニッシュ

フィニッシュ

3.0 / 5.0

あと、これらとは別に、ネットで評判の良い「ハイウォッシュ ジョイ」を買って試している。

食洗機用ジョイ 食洗機用洗剤 除菌 本体 700g - ジョイ

ジョイ

3.0 / 5.0

それぞれ1回は使ってみたけど、「フィニッシュ」は洗剤の匂いみたいなのがちょっと残るのが気になった。「クリスタジェル」と「ハイウォッシュ ジョイ」はどちらも特に気になることはなかった。ただ、今のところあまりひどい汚れでは試していない。

食器の入れかた

これが結構難しくて、鍋とかボウルとか、調理器具も入れようと思うと案外入らない。そんなに汚れてない調理器具は普通に洗うか、調理が終わり次第入れて、スピーディモードで洗ってしまうのがいいかもしれない。スピーディなら食べおわって一息つくごろには終わるので、取り出して食器を入れられそう。

とはいえ、工夫すれば結構入るので、パズルっぽくて面白い。鍋とかだと、そんなに汚れていないなら、内側に小さい食器を重ねて入れてもまぁ大丈夫っぽい。

NP-TR6 はファミリー向けとなっていて、そこそこ巨大なんだけど、それでもこういう感じなので、食洗機は場所が許す限り大きければ大きいほど良さそう。

まとめ

生活家電は確実に生活を向上させるので、多少高くても買って損はしないと思う。無駄に毎年パソコン新調するよりも圧倒的にコストパフォーマンスは良い。

食洗機の場合、食器洗いの鬱陶しさをパズルを解くような楽しさに変換しつつ、精神的な余裕を作れるのが嬉しい。節水がどうとか言ってるけど、水道料金の、特に食器洗いでの家計支配率はそもそも高くないのでどうでもいいと思う。

もっと効率的に運用できる方法を考えて活用したい。

パナソニックの NR-F436T という冷蔵庫を買った。

今回はじめてケーズデンキで購入をしてみた。本当は NR-F437T という後継機のほうを買おうと思ったが、NR-F437T がフル値引きして15万 (ネット最安だと13万円台)、NR-F436T が11万ほど (ネット最安だと9万円台) で、消費電力や容量もろもろは一切変わらず、内容量センサーがついてるかどうかの違いだったので、型落ち品を買った。値段は既存冷蔵庫の処分費 (約4000円ぐらい) や送料込み。

最安で買えた、というわけではないけど、ケーズデンキは今回結構印象が良かった。接客してくれた店員さんが嫌な感じがしなかった。あんまり信用してないけど10年保証もついているので多少安心できそう。ただ店頭の値札の金額は参考程度にしかならず、ケーズデンキのネットショップよりもかなり高いことが多いので注意がいるなあと思った。

実質の消費電力がどのぐらいになるのか心配。省エネを意識して、壁にぴったりつけない感じで設置してみた。意味があるのかは不明。

Google Keep に日記の下書きみたいなものを書くと、それで満足してしまって公開しないまま埋もれていってしまうような気がする。「もう今はこれは言いたいことじゃない」となってしまう。

書きながら考える感じだと、直接日記のフォームに書いていって、すぐに公開しないと、書き出した衝動みたいなものが失われてしまう。

自分が作るウェブアプリケーションでは基本的に以下のような規則を守るようにしている

  • GET だけで副作用 (DB書きこみなど) を伴う処理をしないこと
  • POST 時には自動的に CSRF 防止用トークンをチェックすること

これだけで単純な CSRF はまず防げくことができるからだ (実際は CSRF 防止用トークンの生成方法が多少問題になるが、作るウェブアプリケーションによって、どれほど厳密にすべきかが違うため、そのたび考えてやりかたを変えてる)

このような設計をした場合、全ての POST するフォームに input type="hidden" とかで CSRF 防止用トークンを埋めこむ必要がある。ウェブアプリケーションフレームワークによっては、防止用トークンを埋めこむところも自動的にやってしまうものもあるが、外部サーバへ POST するフォームなんかを作ったとき (ASP型の外部サービスとか)、意図せずトークンが漏れるのがちょっと不安なので自分は手動で全部入れることにしている。たとえ入れ忘れても、普通にチェックしていれば必ず気付くし、一行コピペするだけなのでこれで問題はまず起きない。

しかし一方、外部のアプリケーションから直接 POST されるような場合 (なんらかのコールバックとか)、当然ながら CSRF 防止用トークンは送られてこないため、自動チェックにはねられてしまう。なので、こういう場合は明示的に自動チェックをオフにする必要がでてくる。これが地味にややこしい。

Perl で Router::Simple などを使って適当に本体をディスパッチし、その前 (before_dispatch 的なもの) で自動チェックをかけるアプリケーションがあったとする (シンプルに作るとそうなるだろうというもの)。そんなときなんとなく以下のように書ければいいなと一瞬思ってしまうが、これはうまく行かない。

sub dispatch_foo {
    my ($class, $c) = @_;
    $c->check_csrf(0);
    # do something...
}

自動チェックはこのメソッドの前に実行されており、この段階、すなわち呼ばれたあとに「チェックしない」ことを宣言しても遅い。自動チェックをやめて、CSRF チェックするところにだけ $c->check_csrf(1) とか書いてチェックを明示的にするようにする、という解決方法もあるだろうけど、危ういので避けたい。

とにかく、自動的にチェックを行っている以上、そのチェックが行われる前に「この URI (やサブルーチン) に対しては CSRF チェックをしない」宣言をしておいて、自動チェック時にそのフラグを見る必要がある。理想としてはコードのコンパイル時に行われるのが望ましい。例えば以下のように

sub dispatch_foo {
    my ($class, $c) = @_;
    # do something...
}
__PACKAGE__->check_csrf(dispatch_foo => 0);

この場合、サブルーチンに対して CSRF チェックを自動チェックするかどうかを check_csrf() クラスメソッドで宣言しておくイメージになる。

これでとりあえずいいとは思うけれど __PACKAGE__ とか書きにくいし、dispatch_foo は2度出てくるしで、なんとかしくなる。

結論を言うと、この場合、以下のように CODE Attribute を使うのが一番スッキリいくように思った。

sub dispatch_foo : check_csrf(0) {
    my ($class, $c) = @_;
    # do something...
}

Catalyst 以来、最近は CODE Attribute を使っているものを殆ど見ておらず忘れていたのだけれど、こういうときはやはり便利だな、と思った。

これに従って、自分でウェブアプリケーションを作るときのスケルトンにも同じような仕組みを入れた。

  1. トップ
  2. tech
  3. CSRF 防止用トークンの自動チェックの問題と解決
  1. トップ
  2. perl
  3. CSRF 防止用トークンの自動チェックの問題と解決

全部のファイルをキャッシュさせても、一瞬で表示される感じではなく、ローディングバーが表示され、あくまでロードが走っているようにみえる。この時点でネイティブアプリを超えられない。

殆どペライチなページであっても 0.5 秒ぐらいはローディングバーが出る。ウェブフォントやら外部CSSやらを多く使うと、やはり、それなりに遅くなる (Boostrap を特に気にせず使ってアプリケーションキャッシュに入れると 1 秒ぐらい)。低スペックマシンだと不安がある。


ウェブフォントは、そもそもアプリケーションキャッシュさせるにしても、ブラウザごとに読んでいるファイルが違うので悩ましい。全部書くがいいのかなあ。

  1. トップ
  2. tech
  3. Chrome for Android での HTML5 アプリケーションキャッシュ

血潜り林檎と金魚鉢男(1) (電撃ジャパンコミックス) - 阿部 洋一

阿部 洋一

3.0 / 5.0


血潜り林檎と金魚鉢男(2) (電撃ジャパンコミックス) - 阿部 洋一

阿部 洋一

3.0 / 5.0


血潜り林檎と金魚鉢男(3) (電撃ジャパンコミックス) (電撃ジャパンコミックス ア 1-7) - 阿部洋一

阿部洋一

3.0 / 5.0

なんか 2巻か3巻 (忘れた) に洗濯機から女の子的なのがでてきた

節電モニター - はやわかり

はやわかり

3.0 / 5.0

微妙に高いんだけど、おもしろそうなのでこれを買ってみた。

計ってみるとわかることが多々あっておもしろい。特に、常時使っている電力が結構多い (100W〜200W) ことがわかった。

けど、どの機器が使っているか、というちゃんとした支配率まではわからない。そのせい、もんもんとするので別途ワットチェッカーも買おうと思っている…… ブレーカーの一部を落としたりしてみた感じだと、待機電力で一番支配率高いのは冷蔵庫っぽいなあという感じ……


なんか某ネトゲの公式サイトにどうしてもログインできなくて、変だなあと思っていた。よくよく考えてみると WiMAX でテザリングしていたときにも同じことがおきていたような気がするので、たぶん透過プロキシが悪さをしているのかな、と考えた。

WiMAX テザリングだったときは SSH でトンネル掘ってダイナミックポートフォワードしつつ IE に SOCKS を設定してなんとかしていたけど、滅多に問題になることはないのでそれで十分だった。

今回もその手でいくかなあと思っていたけど、透過プロキシを無効にできるというリプライをもらった。全く知らなかったというか、個別に無効にできるとは思ってもいなかったけど、確認したら確かにそんなことが書いてあった。

LTE NETのパケット通信において、以下のファイルを対象に、画面の表示速度や動画の再生開始時間を早くするための通信の最適化を行う場合があります。

※HTTPS通信、Eメール添付ファイルの最適化は行ないません。
※通信の最適化を必要とされないお客さまは、お客さまセンター (157) にて非適用のお手続きをさせていただきます。

http://www.au.kddi.com/mobile/charge/list/lte-flat/

本当にこれで解決するのか興味が沸いたので、157 に電話(!)をして無効にしてもらった。暗証番号を口頭で言わされる (頭おかしい) ので注意が必要そう……

最適化は無効になっても透過プロキシ自体はそのままかもしれないし、他の原因があるかもしれないのでなんともいえない。そもそもログインフォームは HTTPS のはずで、透過プロキシの影響はうけないはずなんだけど、回線を変えたら大丈夫だし、原理がよくわからない。そのうちどうなったか書く。

結論を書くと、透過プロキシは無効化されない。最適化がオフになっているかどうかはよくわからないので検証できなかった。

  1. トップ
  2. tech
  3. au テザリングでの透過プロキシを無効にする