たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
とりあえず普通に組み立て中。
前腕は銀色に塗るのが正解なんだけど、めんどくさいのでそのまま。頭の所とかカカトとか、クリアパーツにもなってなくてシールも付いてない所は仕方がないのでガンダムマーカーのアイグリーンで塗ってみてる。あと前腕のスミ入れもアイグリーン。アイグリーンの使い道なんてそんなにないよ!と思ってたけど、こんな所で役に立つとは……
全体的に段差部分とかがとろけ気味なので、ちまちまとモールドを彫り直してる。でも黒いからあんまりわかんないよなあ。
手首はキットには平手(それも思いっきし開いたパー)しか付いてないので、コトブキヤのノーマルハンドAを買ってきて代わりに付けた。1/144スケールのアーマードコア向けらしいんだけど、サイズ的にはちょうどいいくらい(デザイン的には「カスタムハンドA」の方が元のに近いか?)。ただしボールジョイント部分が大径の物を使ってもユルユルだったので、瞬間接着剤でボールを太らせる必要があった。やっぱアルティールにはグーだよね。舞浜シャイニングオーシャンパンチ!
キャラ的にパチ組み前提だからなのか、ゲート跡等があんまり目立たないように配慮されてる感がうかがえてちょっと嬉しかった。
あと、ゼーガペインDVD全巻一気買いしてしまった。虹裏ではDVDの賣れた本數の單位として「1ゼーガ」が使はれてゐる。觀た人の評價は高かつたのに全然賣れなかつた事で有名。
というのを見て「えぇぇぇぇぇー」と思った(検索してみたら確かにそうらしい……DVD売り上げ1900枚=1ゼーガだそうだ)ので、まあ今更も今更だけどチャンスがあったら地道にお布施しとこうと思ってたんだけど、ぐるぐる王国DVD館で22%~30%引きのセール中だったのでこれ幸いと注文した。んで今日届いたんだけど、さすがに何年も前の商品だし初回版(BOX付き)は望めないかなあと思ってたら、全部ばっちり初回版だったので吹いた。どんだけ売れてないんだゼーガ。所有欲的には嬉しいけど、この売れて無さは悲しいよ。
追記。サクッと組み上がった。
スミ入れとかほとんどしなくてよかったから楽チンでした。武装も全部クリアーパーツだし。腰アーマーの後ろと膝頭はアイグリーンで部分塗装、それ以外はなんもしてません。
コクピットを再現したいとかなんとか言ってたけど、なんかこれ見てるともう満足してもーいーやって気になってくる……
前のエントリでも触れてるけど、Firefox 3.1ではタブでない要素がタブバーに入る可能性が出てきたので、安全なタブの取得方法を色々考えてみた。
まず、すべてのタブのリスト。
function getTabs(aTabBrowser) {
return aTabBrowser.ownerDocument.evaluate(
'descendant::*[local-name()="tab"]',
aTabBrowser.mTabContainer,
null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
null
);
}
var tabs = getTabs(gBrowser);
for (var i = 0, maxi = tabs.snapshotLength; i < maxi; i++) {
alert(tabs.snapshotItem(i).label);
}
配列でないと困る時はこう。
function getTabsArray(aTabBrowser) {
var tabs = getTabs(aTabBrowser);
var array = [];
for (var i = 0, maxi = tabs.snapshotLength; i < maxi; i++) {
array.push(tabs.snapshotItem(i).label);
}
return array;
}
特定のタブの「次のタブ」。
function getNextTab(aTab) {
return aTab.ownerDocument.evaluate(
'following-sibling::*[local-name()="tab"][1]',
aTab,
null,
XPathResult.FIRST_ORDERED_NODE_TYPE,
null
).singleNodeValue;
}
特定のタブの「前のタブ」。
function getPreviousTab(aTab) {
var tabs = aTab.ownerDocument.evaluate(
'preceding-sibling::*[local-name()="tab"]',
aTab,
null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
null
);
return tabs.snapshotItem(tabs.snapshotLength-1);
}
preceding-sibling
軸を使った時の返り値のノードの並びは軸方向の出現順ではなく文書順になるので、注意がいる。
function getPreviousTab(aTab) {
return aTab.ownerDocument.evaluate(
'preceding-sibling::*[local-name()="tab"][1]',
aTab,
null,
XPathResult.FIRST_ORDERED_NODE_TYPE,
null
).singleNodeValue;
}
タブの個数、最初のタブ、最後のタブも。
function getTabCount(aTabBowser) {
return aTabBrowser.ownerDocument.evaluate(
'count(descendant::*[local-name()="tab"])',
aTabBrowser.mTabContainer,
null,
XPathResult.NUMBER_TYPE,
null
).numberValue;
}
function getFirstTab(aTabBowser) {
return aTabBrowser.ownerDocument.evaluate(
'descendant::*[local-name()="tab"][1]',
aTabBrowser.mTabContainer,
null,
XPathResult.FIRST_ORDERED_NODE_TYPE,
null
).singleNodeValue;
}
function getLastTab(aTabBowser) {
return aTabBrowser.ownerDocument.evaluate(
'descendant::*[local-name()="tab"][last()]',
aTabBrowser.mTabContainer,
null,
XPathResult.FIRST_ORDERED_NODE_TYPE,
null
).singleNodeValue;
}
こういう時自分はついついXPathを使ってしまうんだけど、速度的にはどうなんだろう。ちゃんと計測してないから分からない。Array.slice(gBrowser.mTabContainer.childNodes).filter(function(aNode) { return aNode.localName == 'tab'; })
とかの方が普通に速かったらごめんなさい。
childNodes
を参照してるコードがヤバイというのはホントに酷い話だなあと思うけど、Google ChromeやIE7以降と同じユーザ体験を実現しようと思ったらどっかの時点でこれには手を出さなきゃいけなかった訳で、もうみんな腹括って粛々と受け入れるしかないんじゃないかと思うんだなあ僕は。
追記。例によってきっとガン無視されるだろうけどバグ立ててみた。
追記。どうやら僕が立てたバグに関しては杞憂だったみたい……そもそもこのエントリに書いた話も今回の修正以前から潜在的にはあった問題のようだし。むしろヤバイのはalice0775氏が着目してる問題で、実際のノードの並び順と表示される順番とが食い違うことがあるようだ。この手の問題は僕も過去にXBLで色々試してた時に遭遇して、諦めて「こういう事はしない」という風に自分ルールで決めた記憶がある。バックアウトするのもいいけど、そもそもこれはXBLの匿名内容のレイアウトに絡む根深い問題に起因してるようなので、ここらで誰かが本気出して低層の所を直してくれないことにはどうにもならん気がする。
26日追記。「実際のノードの並び順と表示される順番とが食い違う」件は、新しいNightlyを試したら再現しなくなった。僕の全面的な勘違いだったのか、それとも別の所で修正されたのか…… あとgetBrowser().mTabContainer.selectedIndex プロパティと getItemAtIndex メソッドじゃあダメなのかな
と言われたので調べてみたけど、現状のgetItemAtIndex()
はchildNodes.item()
のエイリアスに過ぎないようなので、やはり万全を期すなら別の手(このエントリに書いたような)を考えておいた方がいい気はする。
タブのドラッグ&ドロップに関する色んなバグを一挙に解決するパッチと最後のタブの右に「新しいタブ」ボタンを表示するようにするパッチの両方が入って、タブ回りが色々変わった。何はともあれ、タブをクリックしようとしただけなのにうっかりドラッグになってしまって別ウィンドウが開かれてムキー、という事がなくなってよかった。
とりあえず自分が把握してる限りでは、ツリー型タブ等でscrollbox内の方の「新しいタブ」ボタン(今回追加された奴)をdisplay: none;
で消してるせいか、ボタンを再表示させた時や新しいタブを追加した時などにタブやボタンの並び順が盛大にぶっ壊れるようになった。display: -moz-box; visibility: collapse;
にしておくとこの問題は起こらないっぽいので、次版ではそうする予定。(コードはもうコミットしてある)
あと、gBrowser.mTabContainer.childNodes
が返す内容がタブとは限らなくなった(どんな要素でもタブバー内に置けるようになったので)ということで、タブを取得するのにこのプロパティを使ってる人は一応気をつけといた方がいいと思う。てかtabbrowser要素のmTabs
自体がこれを参照してるし、現実的にはタブ以外を置いたら色んな所がぶっ壊れる事が予想されるから「置くなよ! 絶対置くなよ!!」って言ってるのと同じだよなあ。まあ一応対応しとくけどさ……
またさらに気付いたけど、タブのnextSibling
やpreviousSibling
もタブでない値を返す可能性がある状態になってる。XBLのソースに埋め込まれてるコメントノードの位置もタブの間に何故か移動してしまったりする事があるようで、前後のタブをこのプロパティで参照してる場合には被害を受ける事になる。ここも注意が必要だ。
全然話は変わるけど。
アドオンで要素の表示・非表示をCSSのdisplayプロパティで制御するにあたって、display: none;
で非表示にするのはセオリー通りで別にいいんだけど、表示させる時にdisplay: inline;
とかdisplay: block;
とかにしてる人がたまにいてもにょる。Web上のCSSではそれで正解なんだけど、XULでこれをやるとボックスの並び順がぶっ壊れたりレイアウトがおかしくなったりする事があるので、よっぽどの事情(タブバーを多段表示させる時とか)がない限りはあくまでdisplay: -moz-box;
の方を使って欲しい。最近見かけたものではPathtraqがそうだった。
XUL要素の表示・非表示を制御するには大別して3つ、細かく分けると7つの方法がある。
node.hidden = true
と node.hidden = false
node.setAttribute('hidden', true)
と node.removeAttribute('hidden')
node.style.display = 'none'
と node.style.display = '-moz-box'
node.collapsed = true
と node.collapsed = false
node.setAttribute('collapsed', true)
と node.removeAttribute('collapsed')
node.style.visibility = 'collapse'
と node.style.visibility = 'visible'
node.style.visibility = 'hidden'
と node.style.visibility = 'visible'
いくつかのXUL要素では、hidden
プロパティやcollapsed
プロパティに真偽値を代入しても何も起こらないので、setAttribute()
とremoveAttribute()
とした方がより確実ではある。プロパティでの代入にせよDOMの属性値での指定にせよ、最終的にはCSSでの指定と同じ物として扱われる。xul.cssの頭の方を見れば、どういう事かよく分かると思う。
上の例でnode.setAttribute('hidden', false)
ではなくnode.removeAttribute('hidden')
と書いているのにも理由がある。テーマやアドオンの中には「要素のhidden
属性の値がtrue
であるかどうか」ではなく「hidden
属性に何らかの値がセットされているかどうか」しか考えてない場合があって、false
を設定したのに非表示のままになってしまう、というような事がたまにあるから。collapsed
にも同じ注意が必要。
XULの世界的には物凄く基本的な事なんだけど、HTML+CSSの世界から入ってきたばっかりの人はこの辺の事を知らないままでいるかもしれないので、一応書いてみた。
こういう事(why:何故そう書かねばならないか)って、アドオンの実際のコード(how:どう書いたらよいか)をいくら見てても分からないんだよなあ……ほんとXULは地獄だぜ。
browser.urlbar.search.sourcesとbrowser.urlbar.default.behaviorという似たような設定が2つもあってわけわからん!!という話をこの間書いたけれども、新しいパッチが入って、browser.urlbar.search.sourcesは廃止された。
ということで割としっくり来る所に落ち着いたみたい。search.sourcesのために色々調べたり実装を直したりしたのはまるっきり無駄になってしまったけど、しょうがない(異議申立てをした本人だから文句は無い)。
前半のタメと後半の色々の組み合わせが上手いなあ。しかし舞浜に9月1日の朝は来ない……
ああそうそう。アルティールのプラモとビジュアルファンブック買ってしまいました。プラモはコクピットの部分が電飾ユニットになってしまってるらしいので、本の資料を見ながらコクピット再現の工作とか……できるといいなあ。
ウィダーインゼリーの類似品と思われる商品が近所の薬局でおよそ半額で売られている事に今日になって気がついた。
最初からここで買っとけばよかった……
切なかったので粉末ポカリスエットを買って元を取る事にした。
16日夕方。若干体調が悪いかなあと思いつつ会社を出る。秋葉原にて目当ての物を探している間に2回ほど便意に襲われ、下痢。(どうでもいいけどヨドバシ秋葉原店6F男子トイレのウォシュレットのノズル壊れてない?)2度目以降は水しか出ない状態。
16日夜、帰宅。また下痢。水分取らなきゃまずいと思って水を飲んで布団に入る。しばらくしてまた具合が悪くなってきたのでトイレに駆け込み、今度は嘔吐。これも水しか出ない。その後たまたま親から連絡があったので電話で応答し、症状を告げる。
17日0時頃、親→従妹と連絡が回り、近所に住んでいた従妹がポカリスエットやウィダーインゼリー等を買い込んで駆け付けてくれる。土日でもやってる病院を探してくれたり、ハンドタオルで頭を冷やしてくれたり、濡れタオルで湿気の補充をしてくれたりと、大変世話を焼いて貰う。体温37.7℃。
深夜、体の節々の痛みと気分の悪さに耐えかねて従妹に救急車を呼んで貰う。近くの病院に搬送され、そこでまた下痢。インフルエンザの検査結果は陰性。今流行りの(?)ウィルス性の急性胃腸炎ではないかと診断される。一晩がかりで点滴を打って貰う。
17日朝、1日分の薬(胃薬、抗生物質)を受け取って、待合いのソファーで待ってくれていた従妹とタクシーで帰宅。従妹は元からあった用事のためその足で出発。
17日午後、母が大阪から新幹線でやってくる(そこまでしなくても……)。何も無しで帰らすのもアレなので、洗濯して貰ったり冷蔵庫の中の日持ちのしなさそうな物を食べて貰ったりした。でも結局、気がついたら風呂やトイレの頑固な汚れの掃除までしてくれてたり、普段自分では絶対やらん事までやって貰ってしまった。体温37.5℃。
18日午前、母に付き添われて休日診療担当の病院へ行き、診察を受ける。回復に向かっているようだと説明され、5日分の薬(胃薬と解熱剤)を処方される。その後、母帰還。なんだかんだで(主に従妹には頼みづらい掃除やら何やらについて)大変お世話になりました。体温37.0℃。
18日夜、少しくらいは回復したか?と思ってバナナを食べる。(ここまで、ウィダーインゼリーとポカリスエットとすり下ろしたリンゴだけ)
19日午前、下痢。会社に休みの電話を入れる。体温36.8℃。
19日昼、母が置いていってくれたおかゆなどを食べる。また下痢の予感。→最初の水のみの下痢ほどじゃなかったけどゆるゆる。
19日夜、母が置いていってくれたおかゆなどを食べる。またおなかがぐるぐる言いだす。近所にお住まいの友人が連絡をくれたのでポカリスエットとウィダーインゼリーを代わりに買ってきてもらう。
20日朝、ウィダーインゼリー1個の後に出勤。固形の方のカロリーメイトを食べる。コーヒーを飲んだ後に調子が悪くなる。昼過ぎに早退。吐き気がひどいけど吐くとそれはそれで気持ち悪くなってしまうので我慢してしまってる。また連絡をくれた従妹(本人も色々大変な状況やのに、ほんまええ子やで……)曰く、自分がなった時にはおかゆすらも駄目だったとのことで、もうしばらくウィダーインゼリーとドリンクの方のカロリーメイト生活になりそうな感じ。(今ここ)
前のエントリに追記した通り、HTMLメールのデフォルトのフォントに日本語の名前のフォントを使えない問題で書いたパッチが採用されたんだけど、それに続いて設定ダイアログを開いた時に前回選んだフォントが選択されない問題のパッチも採用された。(ただしどっちもShredderの話で、Thunderbird 2.0.0.xに入れてもらうにはまだかかりそう。)
今までずっとアウトローな感じで野良パッチを垂れ流してた状態だったけど、こうしてちゃんとアップストリームに還元できるようになると、嬉しいものだなと思いました。
2006年の作品なんだけど、今頃になってバンダイチャンネルで見た。
うわあああ何でこれリアルタイムで見なかったんだ自分!!! 後悔した。アルティールのプラモ欲しくなってきた。(でもまだVF-25が未着手のまま……)
表題の通りで、ディアスポラや順列都市の世界観や設定にハマってしまった僕には、実にたまりませんでした。という時点でもうネタバレなんだけど、話の筋はこんな感じ。「平和な日常は実は全部仮想空間の出来事だった。本当は人類はもう絶滅してて、記憶や人格なども含めて全部をデータ化できたほんのわずかな人々が、世界中に点在しているサーバの中で、『事実』を知らず(忘れて)に『生活』している。世界の真実に気付いてしまった一部の人間は、ホロニックローダーと呼ばれる人型兵器を駆って、人類を滅ぼした敵と戦い続けている……」まあ、巨大ロボット物としては前例がなかったかもだけど、SFとしてはありふれたストーリーではある。分かりやすい所ではMATRIXとかね。
ゼーガペインが面白いのは、例えばMATRIXでは「現実」と「仮想世界」はキッチリ別れてるし、ディアスポラでも「物理現実」と「観境」はキッチリ別れてる(物理現実の中に出現するにはグレイズナーロボットという入れ物を使わないといけない)、それぞれが混じり合う事は基本的に無いんだけど、本作では「物理現実」の中を「仮想の人間」が普通に歩き回ってるっていう所。「遠くにあって絶対に触れられない」のではなく「すぐ目の前に見えていて、こうして両手の間にすらあるのに、相互に干渉し得ない」ものとして、「現実」が描かれている所。前述の小説での詳細な描写を思い出してついつい、実体のある舟の中を歩いてコツコツと靴音がしてるけど実際には物理的には無人かつ無音なわけで単に彼らの聴覚にそう聞こえるようシミュレーションしてるだけなのだろうか、とか、「ホログラムとして投影されてる位置から見た視点」からの視界をどうやって再現してるんだろう? とか、「人間が操縦してる」ように描かれてるけど現実にはホロニックローダーは無人の自動操縦で動いてるようなもんなんだよなあ、とか、そういう舞台裏?的な所についつい思いを馳せてしまう。
しかしカミナギはいいなあ……衣装をエロいと言われて「ありがとう」とか、いたずらっぽく「(キスしても)べつにいいのにー」と笑うとか、なかなか会えないカップルのように(ように?)別れを惜しむとか、つかず離れずで甘酸っぱすぎて萌えすぎる。なんという青春だ。なんだか泣けてくるよ……
ファンサイト(まとめWiki)とかついつい読みふけってしまいます。
痛いニュース(ノ∀`):【神隠し殺人公判】彼女いた経験ゼロの被告「女性を性の快楽で性奴隷にと…」「勃起せず、強姦は未遂に」「臓器刻み、脳なども水洗トイレに」
産経新聞の公判記事も見た。
「風俗に行けばいいのに」とか色々言ってる人がいるようだけど、裁判での発言によると、経験自体はデリヘル等ですでに何度もあったようだ。
「被告人が過去に作った同人誌」というのが気になる……内容がではなく、この事が今後世間にどういう影響を与えるのかという事に。同人誌だけでなく、「アニメ」「AV」などのフレーズもそう。これらもまた「こういう物の存在を許すとこういう猟奇的な犯罪が増えるのだ」という風な言い方で表現規制を行うための材料に使われるのだろう、と思うと、気が重い。
それ以外は、公判記事は読んでて終始「うげぇ……」という気分だった。食欲なくなるし、気力萎えるし、あまりにお花畑な考え方にウンザリするし、(数少ない)身近な女性の身にこういう事が起こったらと思うととても嫌な気持ちだ。