2003-05-13
_ URI は変わるもの？
なんですかねぇ
http://www.zdnet.co.jp/news/0211/01/njbt_07.html
URI ベースのフィルタリングなぞ何の役にも立たない、と。PICS 勉強せんなんですかね。
2004-05-13
_ GIMP 2 に CMYK モードがないような？
1 もそうだった？ うーん、DTP 的にはプロ仕様じゃないんですな。基本的には VGA 出力で済んでいる層向けってことやわ。まぁ RGB の方が広いんだから、CMYK は必要になったらなんとかしろってことやな。
Photoshop キラーってのはこら完全にホラですな。あくまで「一般ユーザーにとって Photoshop は無用の長物」ってだけで。
_ 今日はよく切れる
IP アドレス変わりまくりだ。困るよ。
_ table の border-collapse と DOCTYPE スイッチ
の挙動をちょっとまとめておきたいな。
2006-05-13
_ 思いっきり反対向いてるなorz
※ まぁ世の中のメジャーな方向は向いていない自覚あるけど:-P
CHM ファイルとそのビュワーが使いにくいって話を書いた途端に
textfile.org では逆に HTML Help の情報が…。
そりゃー検索もできるしファイルがバラつかないって意味ではいいと思うよ。でもさぁ、タブ開けないとなぁ。みんな調べものでこそ思いっきりタブ使うでしょ？ 使わないの？
おれだけなんか変な勘違いしてんの？
_ ports の PHP がまた変わった
今度は CLI, CGI, mod_php が同居できるようになった。便利便利。
2008-05-13
_ dom0 と domU の時計が意図せず食い違うケース
以前書いた内容は間違ってたっぽいんですが、あまり見ないケースだと思うのでとりあえず現象をそのまま書いておきます。
えー結論から言うと
dom0 が正しく ntp サーバと同期できていない domU の時計は dom0 とも食い違う可能性がある
ということです。自分はそんなケースを考えていなかったので、あちこち調べた結果
- domU では ntpd を立てない
- dom0 で ntpd を立てる
状態にして、まさか ntp サーバが調子悪くなってると思わず放置してたのですが、しばらくして domU の時間がずれているなぁという話になりました。いやー dom0 に合ってるはずなんですけど？って返したら dom0 とも違うなぁということで色々調べた結果ホスティング先の用意している ntp がおかしなことになっている。(Stratum 16 とか言う。)
前回はこの現象を早合点して RH 系 Linux の domU は自分で時計合わせなきゃダメなんだ！と思い込んでしまったのですが、実際にはそうではなく、単に dom0 が時計をちゃんと合わせてくれないと domU は domU で dom0 とは独立して勝手にずれていく、ということだったようです。
で、今はデフォルトの状態のまま*1 dom0 でも domU でも ntpd を動かしているのですが、これはこれで変というか。
時計はずれてないけど syslog に ntpd が時計を合わせた旨もエラーメッセージも記録されないのです。10日ほど。ntp の設定を見直したまさにその日にしか記録がない。これはおかしいなぁ。でも時計は正確なのです。
ntpd のエラーってなんか conf に書かないと記録されないんだっけか。LAN 内のものは特に設定しなくてもコマゴマ記録されてるんだよな。この状況はまずいんだろうかまずくないんだろうか。もう一回 domU の ntpd を止めて様子見ようかなぁ。RH 系 Linux はそういうもんなのかな。Debian 鯖と記録のされ方がなんか違うな。
*1 domU で独自に ntp を動かすための設定をしていないという意味です
2010-05-13
_ Thunderbirdの受信メールのヘッダを書き換えてImportし直す
結論
受信したメールを書き換えたい場合、いったんメールを .eml で保存して必要な書き換えを行ったあと、
を使って .eml を Import することで可能。
書き換えを Thunderbird 上で行うツールがあるのかどうかは分からない。
背景
- Subject なしで割と重要なファイルを添付したメールを受け取った
- このままでは検索できないので受信メールの Subject を書き換えたい
- そんなことできるの？ 拡張にある？
書き換えの拡張を探し始めたけど見つからず、Thunderbird の外で書き換えればいいんじゃないかというアイディアを確か他の人にもらって探したら見つかった。
直接編集なので MIME encode は自力でどうぞ
Subject などヘッダは MIME encode されているのでエディタでそのまま編集するのはつらい。自分の場合は手元の irb で
NKF.nkf( '-M', 'あいう' )
とかやるとすぐに得られるので苦労はないんだけど。
※ Un*x 版の nkf はデフォルトで iso-2022-jp への変換を行うので、-M で MIME encode してやるだけでよい。でも最近の nkf のマニュアルにはこの辺が明示されていないっぽいので、もしかしたらそのうち挙動が変わるかもなぁ。
2018-05-13
_ 改めてVue.jsのデータの監視方法と回避方法とコンポーネント設計
まとめ
- Vue で監視していたのは data ではなく setter を通ったかどうかだった
- そこは Backbone.js 時代から変わってなかった
- Array や Object の一部を書き換える処理は setter を通らないので Vue は検知できない
- 逆に丸ごと壊せば setter を通すことはできる
- しかし恐らくその場合は書き換える DOM の範囲が広がり、VirtualDOM の速さのメリットがスポイルされる
- コンポーネントを小さくしろというのはそういう意味でもあった
参考
Arrayの変更、Objectの変更はsetterを通らないので検知できない
まぁ、分かってしまえば当たり前の話なんですけど、こういう感じのコードがあると思いねぇ。
data() {
return {
model: {}
}
},
methods: {
action() {
this.model['foo'] = 'bar'
}
}
これ、data だからとか computed だからとか watch じゃないからとかじゃなくて、Vue では検知できないです。
これはごく簡単な理由で
this.model = {foo: 'bar'}
じゃないと setter を通らないから。つまり、
Vueは値は監視していない。setter が通知してるだけ。
そうと分かれば話は簡単。つまり Bachbone.Model の時代から本質は変わっていないわけです。あの頃は Model 側も event を通知する処理を自前で書いていましたが、その部分の記述が setter を通すことで省略できているだけ。
じゃあ検知させたければsetterを通せばよい
その通り。setter を通せばよいのです。
上のコードを本当に動くようにすると以下のようになります。
methods: {
action() {
let model = JSON.parse(JSON.stringify(this.model))
model['foo'] = 'bar'
this.model = model
}
}
こうすれば setter を通るので複雑なデータ構造でも reactive system を動作させることができます。
でも関係するVirtualDOMは全書き換えになっちゃうし、影響も把握しにくい
当たり前ですね。そうなるとせっかく変更のある部分だけ書き換えることを容易に実現できる VirtualDOM の特長が犠牲になるわけです。例えば Array の変更を setter で通知してしまうと、v-for で回している部分は全書き換えになります。
さらに複雑で深い構造のデータを data として保持していて、もしそれがそのまま表示に関係している場合、その component と子の component など、多くの場所でこの data の書き換えの影響を受けます。言い換えると component が大きすぎるわけです。これは実行速度でもマイナスですが、変更もテストもやりにくくなります。*1
素直にsetterで渡せる範囲がVue componentの適切な大きさの一つの指針なのかも
今回 setter の存在に改めて行き着いて、複雑な構造のデータの変更を無理矢理検知させることをやりましたが、本当はこれは Vue 的にはオススメできない方法のような気がします。
今回気づいた setter の動作が理想的なものなのか技術的な制約に基づく妥協なのかは分かりませんが、少なくともフレームワークにとって自然な動作を満たすようにしておくというのは、他の人とコードや知見を共有する際に有効です。逆にイレギュラーな使い方はこの共有を難しくします。
「component は小さく」とはよく言われますが、もしかしたらこの setter を意識せずに使える範囲こそが、component の適切な大きさなのかもしれないという、改めて考えるとごくごく当たり前のことに気づいたという話でした。
落穂拾い
以下、うまくハマらなかったものを殴り書きして終わります。
「component は小さく」とは言いますが、不必要に作りすぎても管理が大変です。小さく保つのは大事ですが、すべてを component に分ける必要はないと思います。
props バケツリレーは確かに面倒ですが、2, 3 階層程度なら割と慣れます。
props で渡すデータの数が増えてもあんまり気にしない方がいいかも。function の引数とは意味が異なると捉え、何も考えずに で展開できる単純さを優先してもよいと思います。「責務が一つであればデータは一つでなくてもよい」という考え方。
*1 例えば自動テストをするにしても初期化、stub out が面倒です。