✖
トラックバックを実装しました
トラックバックを実装しました
といってもサイト内のエントリ間の言及を表示するだけです。いわゆる古代のオープンなトラックバックではありません。
古いエントリに新しいエントリへのリンクがないのは不便だなと思い、とりあえずさくっと LIKE 検索で機能を足してみていたのですが、良さそうなので、ちゃんとリレーションテーブルをこしらえたりしました。
しかし、全体的にページキャッシュ機能を入れているので、単に機能を足すだけでも考えることが増えてしまいます。イメージではトラックバックが送られたページに更新がかかるというだけですが…
キャッシュ処理も見直して、全体的にテストも書いたりしました。キャッシュが入ると複雑性が増す分、独り人力QAには限界があるので、みっちりテストを書くほうがかえって省力化します。
このエントリを参照するエントリ
子供用の椅子の買いかえ
Stokke ストッケ ベビーチェア ハイチェア 本体 トリップトラップ 食卓 赤ちゃん 椅子 ウォールナットブラウン cho45
2歳になって自分でできることが増えてきたり、「みいつけた」で椅子を見ているせいか、椅子が好きになってきたみたいなので、本人だけで座れる椅子を買いました。
ちょっと高いけど、10年ぐらい使えそうなので、そう考えればそこまで高くないかなと思ったのと、こういう大物は買ったり捨てたりするのが面倒なので、ストッケ・トリップトラップというのを買ってみました。色はウォールナットブラウン。
届いて組み立ててる最中から子供はだいぶテンションが高くて、六角レンチでボルトを締めようとしたり(むしろ緩めてたけど)していて面白かった。
ちゃんと独りで座ることもできるし、安定しているので良さそう。ただ子供は「新しいものは様子を見ながら使う」というのがわかってないので、ドンドコドンドコやっててハラハラする。
ところで最初組み立て図を見ても、座面とかにはボルトがなくて、どうやって固定されるかがよくわからなかった。組み立ててる途中でようやくわかったが、これの座面は左右の支えの窪みに入れた状態で、他の部分のボルトを締めていくことで挟みこんで固定されるようになっている。面で固定されるから直接ボルトで固定するよりもいいのかな。増し締め忘れないようにしないといけなそう。
1週間ぐらい既に使っているけど、表面塗装のせいか汚れても思いのほか拭き取りやすい。あと、倒れないように足の底部に滑る部品(滑り止めではない)がついていて、面白かった。子供がテーブルを蹴って後ろに倒れないように、椅子自体を滑らせるという形のセーフティになっている。ただ、性質上、床面がフローリングでないと機能しない。うちはフローリングにマットを敷いているので残念ながら意味ない。
今まで使っていたもの
これを今まで使っていた。まだ使えそうだけど、自分で座ることができなくてちょっと可哀そうになってきた。それに毎回大人が持ちあげる必要があるが、子供も既にそこそこ重い(12kgぐらい)ので結構つらい。
汚れたら風呂場でザーーーと洗って干すという雑な運用をしていたけど、半日ぐらいですぐ乾いてくれるので良かった。値段も安かったし、十分に使えたと思う。
子供用の本棚
RiZKiZ 子供用絵本ラック 木目調 キッズブックシェルフ マガヒンラック 収納に便利な仕切り棚付き (3段タイプ/ダークブラウン) cho45
今までの本棚に不満があったのでこれを買ってみました。本体がかなり重くてしっかりしてます。
子供は特に何の反応もなく本棚と認識して使っていて、あっけない感じだった。絵本渡して「ないないして」というとちゃんと入れてくれる。よかった。
今まで使っていたもの
森井紙器 すまいるキッズ 絵本ラック レッド cho45
買ったときはあんまり本もないからいいかと思ったけど、急激に増えてしまって納まりきらなくなった。
この商品はダンボールでできていて軽いんだけど、おかげで子供が中の本を全部出して、本棚を振り回して遊んでることが多々あった。さすがに最近はそんなことしないけど、軽くて小さいというのも考えものだなあと思った。あとダンボールなので、乱暴に扱うとかなりヨレてしまう。
結果的にはこれを買ったのは失敗だった。最初からそこそこのものを買ったほうが良かった (どうせ必要だから)。
ブログのキャッシュバックエンドの変更
今までは Cache::FileCache によるファイルシステムキャッシュにしていたけど、いくつか問題があって SQLite にかえた
ファイルシステムキャッシュで困っていたこと
- なんか遅い
- キャッシュ無効化の処理のためにキャッシュを生成元とキャッシュのキーをキャッシュ内に格納したいが、アトミックにやるうまい方法がなかった
SQLite 選択
Redis とかを立てるのが機能的には便利そうだけど、リソース的にあんまりサーバプロセスを増やしたくはないので、SQLite とした。
CREATE TABLE cache (
`cache_key` TEXT NOT NULL PRIMARY KEY,
`content` BLOB NOT NULL
);
CREATE TABLE cache_relation (
`id` INTEGER PRIMARY KEY,
`cache_key` TEXT NOT NULL,
`source_id` TEXT NOT NULL
);
CREATE INDEX cache_relation_index_cache_key ON cache_relation (`cache_key`);
CREATE INDEX cache_relation_index_source_id ON cache_relation (`source_id`);
CREATE TRIGGER on_cache_deleted AFTER DELETE ON cache BEGIN
DELETE FROM cache_relation WHERE cache_key = old.cache_key;
END;
CREATE TRIGGER on_cache_related_deleted AFTER DELETE ON cache_relation BEGIN
DELETE FROM cache WHERE cache_key = old.cache_key;
END;
こんな感じでキャッシュ本体 (cacheテーブル)と、そのキャッシュを生成するのに使ったもののid(文字列)のリスト(cache_relationテーブル)を持って、お互いにトリガーで消しあうようにしておく。
こうしておくと、通常のキャッシュキーによる追加・削除だけではなくて、生成元が更新された時に関連するキャッシュをまとめて消せる。
なお、キャッシュ用のDBファイルは元データと分けた。というのも、元データのDBは毎日バックアップとしてGmailに送りつけているので、キャッシュを含めたくなかったから。