駄日記 (未完結間欠日記)

2012年 10月


2012-10-31 (Wed)

この駄日記はこのところしばらく現実世界とは別の人格が書いてる。 現実世界の方はいろいろアレんなってんのに、ここではなにも事件が起きてない感じ。 いや別人格じゃなくてパラレルワールドだな。 人格はむしろ現実世界の方でズレを生じてるくさい…。
しばらく食事量少なめが続いたせいか、 いつの間にか体重が 50kg 台半ば近くまで落ちていた。 この夏めたくそ暑かったから夏痩せ分もあるのかもしれないけど、それにしてもなんだこの減り方。 身長が低めなので BMI で“標準”とされる範囲 (50~68kg) からは外れていないんだが…。 しかし体脂肪率と日常の運動量を考えると…。 体脂肪率は民生用ヘルスメーター測定値なので数値自体の正確性は若干アレかもしれんが (でも変化はここ数年来ほとんどないことだけは確か)。 内臓脂肪だけは (同ヘルスメーターによれば) ここ数年でかなり減ったっぽいけどね…。 とりあえず、 脂肪以外の体組成成分をある程度は維持しておきたいところだが。 動けなくならん程度には…。
超今更だが、VOB ファイル(*31-1)をマージするには単にくっつければいいだけなのを知った。
cat src1.vob src2.vob src3.vob > dst.vob」 こんな感じでよかったんだな~。 かつて専用ツールいくつも探して試したりマヌケなバグに悩んだりした時間と労力が…。
さらに、DVD の容量 4.7GB ってのが実は HDD と同じ 1000倍単位系 (用語ヘン?) だったことを知る。 つまりファイル容量などの 1024倍単位系に換算すると、 片面1層の DVD メディアに入るファイル量の合計は約 4.377GB (4482.27MB) だったのだ。 ついでに片面2層の容量 8.54GB はファイル容量換算で 7.95GB (8144.3MB) だったのだ。 なるほどそうだったのか…。 大体、今まで書き込みツールが勝手に容量計算してくれてたんで気にしたことなかったわ…。 いや、ひょっとすると昔は認識してて最近すっかり忘れてただけかもしれないが… (かもしれないが思い出せない)。
メモ。 手元のデータでいくつか試してみた限りの範囲では、 lame(*31-2) の可変ビットレートのデフォルト (パラメータ -v。-V 4 相当) のエンコ後サイズは --abr 160kbps とほぼどっこいかちょっと小さめ程度 (元データにもよる)。 エンコ後のサイズのばらつきが気になるので今までずっと --abr を使ってきたんだが、 今後は -v (-V 4) にしようかなあ…。 どのみちワシの耳的には 160kbps 程度あれば、音の劣化とかほとんどわからないんで、 まあどっちでもいいっちゃいいんだが…。 ちなみに -V のパラメータ 0~9 は (この順に高品質→低品質)、 エンコード時のビットレート分布グラフを見る限り、 それぞれ 320~64kbps (320、256、224、192、160、128、112、96、80、64) が主に使われるようエンコードされるっぽい。 で、デフォルト (160kbps) より低品質を指定すると、 音質をなるべく落とさないようにか、 主ビットレートと同等の cbr や abr よりもサイズが大きめになる傾向がありそうな予感がする。 ぜんぜん実験してみてはいないけど。 あと、まあドキュメントとか読んでないんで、探せばちゃんとどっかに解説があると思うけど…。 じゃ探せよって話だけど。
前回散髪後まだ 2ヶ月ちょいだというのにもうぼちぼち鬱陶しくなってきた。襟足とか。 1000円カット店的技術 (もしくは作戦) にまんまとハマってるな。 つーかワシこんなにくせ毛だったっけかなァ…。 まァ特に支障がなければあと半年はこのままほったらかす。
10年ほど前に右耳の後にできた粉瘤 (たぶん) はとっくに枯れているんだが、 そのすぐ上のところに新しく別の粉瘤ができてしまった模様…。 まさか増えるとは思わなかった。 しかもなんか腫れてるし。 うううむ。 一度、病院に行ってちゃんと取ってもらわんとアカンのだろうなァこれは…。 といっても健康保険証も作ってないし (ヒドい)、 保険証がもしあってもたぶん治療費を払える余裕は現時点ではないしな~。 もういろいろ末期的だ。
その後、つぶれて中身が出てしまったらすっかりしぼんだ。 まあ一度できると同じところが繰り返し腫れる可能性が高いんで、油断は禁物か。
リール (ワイヤー) タイプのキーホルダー、 4年ほど前に 2つ買ったうちの 1つ(*31-3)が先日壊れてしまった。
2種類買って部屋の鍵用と自転車の鍵用に使い分けていたのだが、 壊れたのは使用頻度が高かった (ワイヤーを引っぱる機会が数倍多かった) 自転車の鍵用の方。 出先でいつものようにぐいっと引っ張ったら、 そのままワイヤーごとぶちっと抜けた。 細いワイヤーが内部で千切れてしまった模様。 リール機構部分の穴から覗くと中にワイヤーの残りが見える…。 バラして直せないかな…と思ったが、 ヘタにバラすと中のゼンマイが弾けて修復不可能になりそうだし、 そもそもワイヤー自体が千切れていてつなぎ方もわからんし、 ワイヤーの切れた箇所の近くを指で触ると点々と傷んでいるっぽい感触があって、 仮につなげたとしてもじきに別のところが続いて切れそうな予感もするし…。 で自前修理は諦めた。最近諦めが早い。
さて、どうすっかなァ…。 新しく買うにしても微妙に高いし (買った時は末永く使うつもりでちょっとだけ思い切った)。 Amazon で同じようなタイプのキーホルダーを物色してみつつレビューを眺めると、 これに限らずこの手の製品に故障や破損は割とありがちっぽいし… (といってもまあこいつの場合 4年はもったんだけど)。 とりあえず、今まで鍵をそれぞれに 3つずつ計 6つぶら下げていたが、 実質日常的に使っているのはそのうち 2つ、 あと普段ほぼ使う機会はないけど持ち歩くべきなのが 1つ、 だけなので、 他の鍵はまとめてしまっておいて必要な時だけ持ち出すことにして、 キーホルダー 1個で当分間に合わせることにした。 こっちも壊れたら…その時また考えよう。
以前、知人が長い金属製の鎖に鍵束ジャラジャラつけて、 ジーンズからぶら下げて歩いていたけど (鍵束はポケットに突っ込んで鎖だけ垂らして)、 あれなら切れはしないだろうけどさすがに音もうるさいしなァ…。 まァその知人は当時細身で茶髪で革ジャンなんか着て歩いてたからサマになってたけど。
xyzzy の表示フォントを Lucida Console 改 (ASCII) + IPA モナー 明朝 (日本語) の組み合わせから、 気まぐれで Lucida Console 改 + NFモトヤアポロ1等幅 に変えてみたが、どうもしっくりこない…。 今は MacType(*31-4) 入れてるのを思い出し、 以前と同じフォントセットでも表示のされ方が少しは違うかもと思って試してみたんだが。 いや、同じフォントセットじゃなかった。以前使ってたのは NFモトヤシーダの方だったっけ。 しかしモトヤフォント (モトヤアポロ) もデザイン綺麗だし見易くて好きなんだけど、 やっぱしもうちょびっと半濁点と濁点の区別がつけやすければ…とどうしても思ってしまうな。 といっても現在使ってる低解像度なディスプレイで表示させる都合上の話なんで、 印字した際のバランスを考えたら NG だろうけど。 あるいは高解像度なディスプレイを使えばまた違うかもしれないけど (今はムリだけど)。 あと、好きなんだけどとか書いてる割には無料お試し版(*31-5)しか使ってないわワシ…。
あとはゴシック系…は音引き記号と漢数字の一なんかが区別つきにくいしなァ…。 と思ってたんだが、試しに MigU を設定してみたら音引きと漢数字の一にそれぞれちょろっとヒゲが。 なんと。これは盲点だった…。 しばらく MigU 1M (と Lucida Console 改の組み合わせ) を使ってみよう。
ちなみに…。 最初は Ricty の方が xyzzy 上ではバランスがいいと思ったんだが、 ふと「―」記号 (ダッシュ、Shift JIS だと 0x815c、unicode だと 0x2015) が表示されないことに気づいた。 おや? なんでこんなメジャーな文字が…。 Ricty の (ジェネレータの) バグかなァ…。 なんでじゃろ、と思いつつ「ダッシュ」で検索してみたら、 どうもダッシュにもいろいろあるっぽい。 Shift JIS で 0x815c のこの文字は Wikipedia によるとダッシュではなく「ホリゾンタルバー」らしい。 えええ? 今までずっとダッシュ相当の箇所にはこれ使ってきたんだが…。 Wikipedia によると、 短いダッシュ (enダッシュ) がユニコードで 0x2013 (U+2013)、 長いダッシュ (emダッシュ) が 0x2014、らしい。 たぶん使ったことないんじゃないかな…どうやって (skkime で) 変換するかもわからん。 どうも、マッピング (規格) の齟齬のようだが…。 もう何がなんだかさっぱりの世界だな (これだから unicode はキライだ!)。 まあしかし少なくとも他のフォントセットで何も問題なく表示されてる 0x2015 (unicode) の文字が、 Ricty ではカラッポで何も表示されないのは確かなんで。 少なくともウチで生成したフォントデータでは…。 という訳で原因は不明だけど、 この不具合が解消されるまでは残念ながら Ricty は選択肢外ということに。
メモ。自転車の積算走行距離、現在約 2700km。 これ、買ったのがほぼ 5年前だったんだ。もうそんなになるのか…。 しかし 5年間も乗ってる割には積算距離が少ない。 まァ、月に 10回かそこらの買い物の時以外ほとんど使ってないしなァ。 それにしても、安物折り畳みのくせにロクに手入れもしてない割によくもってるぞ。 > DOPPELGANGER 202 (初代)
そういやフロントフォークのベアリングのグリグリ (←説明がなってない)、 メーカーサポートの返事は使っているうちに取れていくとかだったが、 結局取れずじまいなまま未だに正面向きで軽くクリップするんだよなー。 もうあんまし気にしてないっていうかどうでもいいやモードに入っちゃってるんでホッタラカシだけど。 ま~、もし次に自転車を買う機会があったらこのメーカーは避けた方が無難かもしれない…。 自分で整備調整できるようにでもならん限りは… (たぶんならない)。
以下ひとことでまとめると SQLite (+ Perl) を使ってみた話。
現在、3万件 (3万ファイル) 程度の規模のとあるデータをたまにいじくっている。 いじくっている、ってのもヘンだけど。 ファイル名ベースで管理しているので、 検索が必要なのは各々のファイル名と格納フォルダ名だけ (各ファイルの中身は触る必要なし) なのだが、 その都度ファイル名検索してたら時間もかかるし、 なにより HDD 負荷 (の累積) が大変なことになりそうなので、 ファイルを更新したタイミングでファイル名リストをテキストデータに保存し、 そっちから文字列検索する形にしている。 ファイル群自体の更新頻度はそんなでもないので、 リスト更新時の HDD アクセス負荷はまあ許容範囲 (というか必要コスト) ということにして…。 しかし、なにしろフォルダ情報も含め 4万行以上あるテキストデータをシーケンシャルに検索するんで、 Perl でざっくり処理するのに 1回につき 8秒程度かかっている (元々処理能力のあまり高くないロートル機で、 I/O のトロい Cygwin 上で、 さらに多少は高速化の工夫もしているつもりではあるものの処理が Perl で、 といっても Perl の内部コンパイラはなかなか優秀ではあるんだけど、 しかも都合により保存ファイルの文字コードは Shift JIS、 検索文字列の入力や結果の出力は UTF-8 なので、 都度文字コード変換のオーバーヘッドもかかってたりして、 遅いのは当たり前ではあるんだが…)。
で、たま~に頻繁に多量に (数十件以上、五月雨式に) 検索せにゃならんことがあって、 1回ごとに 8秒程度ずつかけているうちにだんだん鬱陶しくなってきて、 せめて検索だけでももうちょっと高速化できんもんかしら、とふと考えた。 検索用インデックス (と専用の検索ツール) を作成したらどうか…。 しかし自前で作るのはベンキョーにはなるかもしれないけどちょっと大変だし…。 作るとしたら全部 Perl で書くから (ぉぃ)、インデックス生成時間もバカにならなさそうだし… (この駄日記をサイトにアップロードする毎に Hyper Estraier のデータも更新してるんだけど、 毎回それなりに時間食ってるし、 といっても処理してるのが 266MHz FPUなしの PowerPC 互換 MPU で動く OpenBlockS 266 だから余計だけど)、 やはりそういう力仕事部分はバイナリでさくさく動作する、 完成度も高い既存のシステムを使った方がよさそうだよな。
で最初に思い付いたのは、このサイトでも検索エンジンとして使っている Hyper Estraier。 しかし試してみたらどうもうまくいかない。 元々 Web サイトの検索などを目的として設計されたものだからか、 “目当ての文字列を複数ファイルのどれ (どのへん) にあるかを探す”のには向いてるが、 “単一のテキストファイルから一致する行を探す”みたいな用途には向いてないっぽい。
次に思いついたのは、今まで自分から触る機会がまるでなかった RDB。 といっても DB サーバ動かすのも大仰なんで 1ファイル = 1データベース、の SQLite (v3)。 SQL とかよくわからんながらも昔買った入門書や Web で検索して参考になりそうなサイトを頼りに、 試しに (くだん) のテキストデータを DB に変換して、 検索かけてみたら 2~3秒で結果が出力された。 あ~なるほど…。 DB ってのはこういうことのためにあるもんなんだ~。 というのを改めて実感…。 ちなみにテキストデータから DB を作成するのもほとんど 2~3秒以内に完了してしまう。 これならなんの問題もないわ。 つーことで、今後の検索は DB ベースでやることにした。 DB の更新や検索も DBI や DBD::SQLite をインストールして Perl から行なえるようにして。 で、テキストデータの方はそれはそれで用途もあるので DB と併用すると。 まァバッチ処理が必要なければ、 テキストファイルをエディタ (xyzzy) で読み込んで、 エディタの検索機能使うのが一番速いっちゃ速いんだが… (ファイルアクセスのオーバーヘッドがかからない分)。
まあ数万件程度のデータだから SQLite で十分以上に間に合ったけど、 もっともっと巨大なデータの場合は、巨大データ向けの高速な DB を使うとかになるんだろうな。 その場合 DB の選択より先に実行環境の高速化を考えるべきだろうけど。
その後、ちょっと調べたら Windows Desktop Search という、 ファイル名 (やファイルの内容) をインデクシングして高速検索できる仕組みも MS から提供されているらしいが…。 Cygwin 上から使えないとワシの場合ちょっと意味がないというか使い勝手的に問題があるからなァ…。
日本でもやっと Kindle が発売される、というニュースで Twitter の TL がプチ賑わってるのを見た…。 考えてみるとここ数年でやたらといろいろ出てきた、スマートフォン (スマホ) とかタブレットとか、 あるいは各種無線通信サービスとかの類に、ほとんど関心がないまま、知識もないままでいる。 あーあと現実に出てきている電子出版系サービスの類とかもだな。 調べようと思えばいつでも情報はまとまって転がってるし…というのもあるのかな。 情報端末機器はキーボードがつながってないとなんかヤ、ってのもあるのかな。 情報端末機器で文字入力は必須、効率的 (実用的) 文字入力にはキーボードは必須、と思ってるからな。 Palm Pilot (への好感) はまァ例外だったけど。 アレは Graffiti (の設計思想) が好きだった…。 あとオンラインのコンテンツ提供サービスに関しては、まあちゃんと調べてはいないんだが、 ユーザの自由度が少ないものの方が多い (というか、今のところほとんどそれ?) という感触で…。 そういうものに関心がわかない、ってだけかも。 あるいはまた、トシとっていろんなモノへの関心自体が薄れているせいも多少はあるのかも。 あとはお金ないからなまじ関心持つとヤバそうということで敢えて回避してる部分も、 少しはあるかもしれない。
メモ。 ISO イメージファイルの展開は 7z コマンドで可能。
以前から、「友人」と「知人」の違い (区別?) がどうもいまひとつよくわからないでいる。 さっきふと思ったんだが、お互いにタメ口で (敬語を使わずに) 話せる間柄は友人、 という切り分けはどうだろうか。 ただし名前に敬称つけるのは許容範囲、ってことで。 でも敬語を使う間柄の友人だっていてもおかしくはなさそうだよなァ…。 うーんいまひとつか。
先日 TANITA の電子キッチンスケールで小麦粉だかスパゲティだかを量ろうとしていたら、 液晶の目盛表示がピクピクと変動するのに気づいた。 1秒未満程度のインターバルで、-数g ~ +数g を行ったり来たり。 もう数年来愛用しているが初めてみた症状。 電池は 1~2度切れて交換しているけど、電池切れでこんな症状になったことはなかったし…。 いよいよ故障かな…? と思ったが、 電子レンジを止めたらピタッと治まった。 なんと電子レンジからのノイズの影響か…!? ちなみに流し上のキッチンスケールは、 流し横の冷蔵庫の上の電子レンジの、側面から斜め下 1メートルくらいの距離。 こんなに離れてても影響されるのかァ…。
表示している Web ページ (の表示状態) をまるごとローカルに保存する、 Firefox のアドオン ScrapBook を愛用中なんだが。 以前も書いたけど溜め込み量がかさんでしまって、 HDD 容量もだいぶ食っちゃって (4GB ほど) 逼迫しているし、 件数も 4000件を超えちゃっていささか重い (気がする) し、 なんとかできないかな…と突然思い立つ。 これで何度めだ。 ちなみにこの程度の件数なら Scrapbook アドオンからのタイトル検索なら一瞬で終わるんで、 まあ主目的は HDD 容量の確保だな…。
とりあえず以前調べた、ZIP ファイルをフォルダとしてマウントできるようにするユーティリティ Pismo File Mount Audit Package (pfmap) と、 それに対応して改造した Scrapbook アドオン本体の組み合わせを試してみた。 ちなみに日本語ファイル名のファイルを Cygwin の zip コマンドでアーカイブすると、 あふW などで中を覗いた時に文字化けして見えてしまうんだが (UTF-8 でアーカイブされるため?)、 試してみたところ pfmap でマウントしたら中のファイル名は化けずに表示された。 pfmap かシステムかがよろしくやってくれるらしい。 あふW あたりから手作業で (DLL 使って) ZIP にすれば文字コード Shift JIS のままアーカイブできるんだけど、 多量のファイル (フォルダ) の ZIP 化は手動ではとてもやってられないんで助かった。
  • Scrapbook アドオン本体を展開し、中の scrapbook.js 内にある
    		else {
    			var modTime = cache.lastModifiedTime;
    			if (modTime && ((new Date()).getTime() - modTime) > 1000 * 60 * 60 * 24 * 5)
    				shouldRebuild = true;
    		}
    
    の「else {」行を
    		else if (! cache.path.match(/\.zip$/i)) {
    
    に書き換える (参照)。 install.rdf の version もちょっと非正規改造版っぽく枝番追加した。
  • 改造版 ScrapBook を Firefox にインストール。
  • Firefox を一旦終了する。
  • scrapbook データを保存してあるフォルダ内の、 data サブフォルダ内の、 数字 14桁のサブフォルダごとに ZIP でアーカイブする。 ({サブフォルダ名}.zip 内に、サブフォルダ内のファイルのみ入っているような形で)
  • 作成した ZIP ファイルを元のサブフォルダと置き換える。
  • scrapbook データを保存してあるフォルダ内の、 cache.rdf と scrapbook.rdf を編集して、 ZIP 化した {サブフォルダ名} 部分を {サブフォルダ名}.zip に書き換える。 バックアップも忘れずに…。
Multi-scrapbook で別の scrapbook にテスト用データをいくつか作って実験したところでは問題なさそうだったので、 まずは全件一気に ZIP 化処理した (一晩かかった…)。 C ドライブには入り切らんので外付の別ドライブ上に。 容量は全体で 3割ちょっとしか減らなかったが、 これは Scrapbook の保存データのうち、 かさばっているのは画像ファイルなどの圧縮があまり利かないファイルが多いためだな。 次にこれらを pfmap でフォルダにマウントしようとしたところ…。 なんとこいつってばマウント 1件につき pfmstat.exe というプロセスが 1つ起動するのであった。 4000ファイルもマウントしたらプロセスが 4000も起動・常駐しっぱなしになるのか…。 気づかなかった…。ううむこれでは使えないではないか…。 ZIP 単位で管理できるようになれば取り込み件数 = ファイル数になるので、 データのハンドリングが多少はマシになるかもという期待 (皮算用) もあったんだけど。
という訳で、素直にデータを外付の別ドライブに引っ越すことにした。 一晩かかった ZIP 化作業がムダになってしまったが仕方ない。 データの単なる移動なら、アドオン自体の改造や rdf ファイルの書き換えや ZIP 化やマウントなど、 今後も手間をかけ続ける必要なく普段どおり使えるのでそれはそれでメリットではある。 Scrapbook データをまるごと外付 HDD に引っ越したので、C ドライブの空きが 4GB ほど増えた。 これでしばらくはもつかな…? 外付 HDD が死んだらそれまでだけど…バックアップもとっておかないとだなァ…。 いやまァ、消えたら致命的というほどのデータでもないかもしれんが…。
あと他の方法としては、 データを Scrapbook からエクスポートして Scrapbook からは削除してしまい、 検索や管理は Scrapbook からではなくエクスポートしたデータの方で独自に行なう (DB に追記式に登録していくとか…?) という手もあるんだな。 こちらはそのうち気が向いたら試してみようかな。 いずれにしても C ドライブの外へ追い出さにゃならんのは一緒だけど。
…まァ本来メインドライブの HDD 容量増やすのが正攻法という気もするが、資金ぜんぜんないし (PC が古いんで上限がせいぜい 80GB 程度の IDE HDD しかつなげないという事情もあるが。 最近の PC を導入すればどれも SATA HDD とか SSD とかで容量問題はまるっとクリアなんだが、 それにはさらに資金が必要だし、っていうとことんお金ないの世界)。 もっと正攻法だと、溜め込みっぱなしで不要なデータを削除する、になるんだろうけど。 しかし試しに古い保存データ (Web ページ) をいくつか開いてみたら、 何で保存したのかさっぱり思い出せないようなページも、読むと面白かったりするんであった…。 溜め込み屋的にはこの方法はちょっとムリかもしれん…。 まァ件数も人力で整理するにはちと多いんでアレだしなァ。
ついでに Multi-scrapbook とエクスポート / インポートの仕様についてメモ。 これは scrapbook データを複数持つための拡張仕様 (?) なんだが、 完全に別々のフォルダに別々のインデックス付で保存されてしまい、 相互のデータの移動やらマージやらの機能は (直接には) サポートされてない。 また横断的な検索もできない。 複数の scrapbook 間のデータの移動やマージには、 一旦別ファイルへエクスポートしてそれをインポートし直す方法しかない模様。 元々、Scrapbook の各スクラップデータは、14桁の日付 (数字) のフォルダ名で分けて格納されていて、 この日付はスクラップを取り込んだ日時なのだが、 これをエクスポートすると、各データのフォルダ名がページタイトルに変わってしまう。 ファイルシステムとしてデータを探すにはこの方が都合がいいかもしれないけど、 マージした際に並び順が取り込んだ日付順ではなくなってしまうのではないか。 と思っていたんだが、試してみたところ、 一旦エクスポートしたデータをインポートした段階で、 それぞれが取り込んだ日付のフォルダ名に戻っていた。 その後調べたら、各フォルダ内の index.dat にちゃんと情報が保存されていたんだった。 という訳で、一旦別ファイルに書き出してまた書き戻す (実ファイルを 2回も複製する) 余計な負荷と手間は必要だが、 とりあえず各 multi-scrapbook 間のデータの移動はこれでなんとかなることは分かった。 なんかちょっとメンドくさいけど…。 でもまァ実験してみてよかった (ひょっとすると実験するまでもなくドキュメントがあったのかもしれないが見てない)。
しかし Multi-scrapbook の用途って割と限定的なんだな。 分散させる、というよりはそれぞれ独立して持つ、的な。 データの移動やマージや (これらはもうちょっと簡便にできるようになって欲しいが) なにより検索が横断的にできないというのはつまりそういうことなんだな。 物理的な保存場所を分散させられれば HDD 容量不足に対処できるな~、 みたいな発想しか浮かばなかったのがそもそも間違いだったか…。
で、上述のように scrapbook の取り込みデータは取り込み日時を元にした 14桁の数字のフォルダ名ごとに分けて保存されているので、 試しにこのフォルダ名を元に、月別の取り込み件数一覧を出してみた。 scrapbook のデータを保存しているディレクトリが c:\_scrapbook だと仮定して、 Cygwin の端末から、
( cd /cygdrive/c/_scrapbook/data/; ls -d * | awk '{print substr($0,0,6)}' | sort | uniq -c | awk '{printf $0 " ";s=int($1/10);for(i=0;i<s;i++){printf "*"}print ""}' )
久々に awk を使ってみたがだいぶ文法を忘れてた…。
一番多かったのが 2009年 6月。 NOAH の三沢選手が試合中の事故で亡くなった月だなァ。 翌 7月とあわせて 700件以上取り込んでる (全部が三沢選手関係のデータではないが)。 次に多かったのが 2011年 3月。 東北地方太平洋沖地震の起きた月だな。 こちらは翌 4月とあわせて 600件くらい。 大量の写真を掲載しているサイトが多いので、件数の割に容量は食ってる。
友人が、交通事故に遭ってしまった模様…。
自転車で走行中に、脇道から右折してきた新聞配達のバイクと出会い頭に接触とか。あ~。 右腕が手首から先以外動かなくなってしまい、原因はまだ特定できてないようだけど、 検査によると事故のショックで脊椎にヘルニアができて神経を圧迫している、らしい…。 利き腕かつ商売道具だから大変だよな…。 四十肩で可動範囲が狭まるだけでも結構厄介なくらいだし (最近右側もまたぶり返し気味。つーかこれひょっとして死ぬまで治らんのかしら。閑話休題)。 なんにせよ無事に治りますように。
こんなしょーぉぉもない駄日記でも毎回推敲している。 ためつすがめつ書いて、書き終わって通して読んでみて、しっくりこないところを直す。 気が済むまでいじって、しばらく置いとく (最近は月一ペースだから置き時間たっぷり)。 しばらく置いた後で読むとまた直したい箇所が増えてて、直す。 エディタ上で読んで特に問題ないと思ってもブラウザで表示させて読み直すと、 大抵は引っかかる箇所があるので直す。 と、後の文章とつながりが悪くなるので後の文章も芋づる式に直す。 記述内容にムラがあるようなんで足したり削ったりしてみる。 記述の順番を変えてみる。 どうしてもくどくなっちゃう部分をばっさり削ってみる。 削ったら全体的に「だからどうしたの」みたいな内容になっちゃって結局まるごと削るとかも。 そういう推敲の真似事のようなことを、 いつま~で続けても一向に「これでよし」状態にならん。 基本的に文章書くのがヘタクソなんだろうな~。 と思いつつもなんとなくやめる気にもなれず、こうやって延々書き続けている訳だが。 書ける環境と状態が続く限りはたぶんこうやって駄文をどこかに書き続けるんだろうな~。
いろいろすごいらしい。 DB は疎いまんまだな~個人用途ではほとんど用がないってのもあって…。 WordPress なんかの試験的インストールの時に手引きどおりに設定するくらい。 あと先日ちょこっと SQLite をいじってみたくらい…。

粘着テープの歴史とかトリビアとか。 日東電工ってニトムズ (NITOMS) かァ。 先日買った梱包用の透明テープ (アクリル系粘着剤のポリプロピレンテープ) がニトムズだったわ。

ジュリー・アンドリュースの 77歳の誕生日を記念して 77枚の写真、とのことで、 77歳のジュリー・アンドリュースの写真が 77枚あるのかと思ったら違った。 というか 77歳らしい写真は 1枚もなかった…。 まあそういうもんか…。

ニセ科学の話からちょろっと“かけ算の順序”問題へ。

うちのマグカップのヒビ模様は…アンティークではないけど…経年貫入というやつかもしれないな。 陶器 (水和膨張する素材) ぽいし。

ふむふむ…なるほど…。

スタパ斎藤氏が Twitter でオススメしてたんで (スチルカメラとしてはかなり使いやすい)、 なんとなくメモ。 なるほど動画は撮れないのか。 …使いやすいとは書いてあるけど画質はどうなんかな。 まあ悪くはないんだろうけど。 …動画撮るなら軽い機材の方がいいよなたぶん…。できれば専用の。

意外と…あんましオシャレでもないな…。 もっとバーンとデザイン決めるのかな~と思ってた。 面積増やしたりすると印刷コストがかかるからかな…?

5型でフル HD (1920×1080ピクセル)、解像度 443 ppi。 なるほど液晶の場合は単位 ppi なのか。 デジタルディスプレイも印刷物にだんだん迫ってきたかな…。

この URL、2年も前に拾ってた。 「きみの絵をうごかそう」。 子供向けの、オンラインのプログラミング教育教材。 LOGO っぽいのかな、と思ったが違った (LOGO は、動かすカメを主体として位置や向きを指定するが、 これは動かすフィールドの座標系が基準で、まあ一般的な画像ソフトなんかと同じ)。 でもまあ絵を動かすってのはプログラミングの導入としては有りな気はする。 ロートルホビープログラマはたぶんほとんど全員、 初心者の時に BASIC の PRINT 文とループの組み合わせで遊んでたりするだろうし…。

大人の (ホビースト向けの) プラモデルカメラ。 だそうな。

アクセス解析嫌い。めんどくさいし、どうせ不正確だし。 というのは昔自前で拙劣にやってたからってのもあるかもだが。 いずれにしても“目安”程度なことを前提に、 まあ役に立つ部分があるなら利用するか、くらいの構えならいいだろうけど…。

タイトルから想像した内容とはかなり違っておった…。う~む。

以下の文章は、TorrentFreakの「Anti-Downloading Law Hits Japan, Up To 2 Years in Prison From Today」という記事を翻訳したものである。


日本でも最近またいろいろ話題になった親学ってのも、はっきりいって、この3歳児神話の蒸し返しで、現代の研究からは完全に否定されているものなんだけど、そいうのを支持する政治家とかがいるのはホント困ったもんだよなあ(´・ω・`)。

3歳児神話は、その後に行われた世界的な色々な調査でも否定されていて、日本の厚生労働省の2004年のレポートでも、一日12時間以上保育を受けた子どもでも、24時間母親に養育された子どもでも、3歳児、6歳児で、IQや体の発達、問題行動、精神疾患の罹患率など全ての指標で差はないと報告されているんだよね。

親学にハマってんのは先日自民党新総裁に選ばれたっつー安倍晋三。

ミステリアス vs. ミステリアス…

映画。ナチスが月から…。なんか面白そう…。


掛け算には順序あるよ派。らしい。 挙げられてる参考文献が「うっひゃあ!」なレベルらしい。 つーかここって「わだいのたけひこのざっき」の人のサイトじゃん。なんだ。 サイト名変わったんで気づかなんだ。
しかし、放射性物質恐怖症、ニセ科学信奉者、新興宗教信者、 掛け算順序派、いわゆるネトウヨ、ニューエイジ、etc. … いたるところにいろんな“ハマっちゃってる”人がいるもんだなァ…。 なんか共通したメカニズム (心理的というか脳機能的な) が、 あるんだろうな…とは思うんだが…。

MS が公開したオープンソースの JavaScript のラッパー (でいいのかな?)。 の解説。丁寧。べたぼめ。 なんかもうナマの TypeScript エンジン開発して JavaScript エンジンとみんな置き換えちゃえばいいのに。

真意というか経緯というか。 なるほど。そういう経緯。 そして他人のネタでもなんでもいいから注目されたい君がここにも一人登場。 結構いるんだなァ…注目されるためには盗作でもウソでもなんでもありってパターンの人。 最近、Twitter の TL やら Web のまとめサイト系やらでやたら捏造オモシロ画像を見かけるんで… (大抵は自分で作ったんじゃない大昔のネタ画像を、 中には捏造を知りつつテキトウなキャプションつけて流してるような奴とかが結構いるっぽい。 まあ上記の注目されたい君は画像そのものに捏造や改変をしていた訳ではないけど)。

PLUS の「フィットカットカーブ」というはさみ。 交差する角度がどの部分でも一定になるように刃がカーブしている、と。 刃先でも巻き込んだりせず、力を入れなくても切れる (逆に根元では一般的なハサミと比べて多少力が必要)。 なるほど。 これは確かに地味だが画期的かも。 チタンコーティングからフッ素樹脂コート、長刃、左利き用、などいろいろバリエーションも。 別メーカーだけど Silky のシリーズもこんな刃先の製品出さないかなァ。 まあ PLUS のを買えばいい話なんだろうけど…。

最近、ページを下の方までスクロールさせると数秒固まるサイトが増えてきて、とてもうっとうしい。 メインブラウザの Firefox に、 ページ読み込み時に (IE みたいな) カチッというシステム音を鳴らすアドオンを半分洒落で入れてみたら、 この Firefox が固まるタイミングで、 一瞬の溜めの後えらい勢いで音がカカカカカカカカッッと連続して鳴ることが判明。 要するに、関連リンクを自動生成するナニかを仕込んだページ (サイト) が増えてるんだな。 で、正体はどうもこの zenback とかいうやつらしい… (まだ未確定。他にもあるのかもしれない)。 ただでさえ非力極まりない PC 環境なので、 zenback とか ninjatool とか閲覧側に大してメリットのない鬱陶しい仕掛けはブロックするに如かず。 て感じで…。 いやホント、ブログパーツとかガジェットとかの類は鬱陶しい…。 ナビゲーション領域でだらだら読み込まれるのも鬱陶しいし…。 他にも最近だとスクロールしてページ終わりに来ると発動する仕掛け (リンクやらメニューやらが横から出てくるとか) も多いが、こいつらも鬱陶しいんであった。 ま~非力環境なので余計に、かも。

ほほう。 守ってくれるかどうかはわかんないけど発想はちょっと面白いと思った。

豚はダメ。ってワシでも知ってた (でも割と最近に近くなってから知ったかもしれない…覚えてないけど)。 そのうち豚肉を“細胞”として低コストで無菌培養できる技術でも開発されたら、 生食用培養豚肉とかいって販売されたりするようになるかもしれないけど…。

大阪地検。腐り切ってるなあ…。自浄能力は残ってないのかな…。

徐々に落ち着いてきてるとはいえ、 震災前と比べると、いまだに地震発生回数はちょっと多めなんだ。

くり と きんとき。喜国・国樹家のわんこ。おおお。

まあ…残念ながら「無能」と言われても仕方ない現状のようだなァ。 身内の犯罪者は (有罪確定でも) 不起訴だったり罰金刑で済ませたりといろいろアレだから余計に。


はっは。

なんか正気の沙汰じゃないなこりゃ。 > NEC
NEC の 1万人リストラっていつの話かと思ったら今年に入ったあたりから延々やってるのか…。 先月には自殺者も出てるようだ。 そりゃこんなことやっとりゃ自殺者も出るだろうが… (亡くなったのはリストラ対象者じゃないような情報もあるけど…)。 それにしても自主退職 (実際には強要なんだが) を「特別転進」て…。 退却を転進と言葉だけ言い換えた旧日本軍の言語感覚そのまんまか。
いくらこのような (特にこんなあからさまに違法な) 勧告をされても辞めねばならん義務はない、のだが、 自主退職した人の気持ちもわからなくもない気はする。 こんなクズな会社にいても先はないんでは…と思って辞めることを選んだ人も、 中にはたぶんいるんじゃないかなァ。

最近ドイツの税関でヘンな事件が続いてるな、くらいのザツな認識だったんだが、 どうもフランクフルト空港に限定の話みたいだな…。
なんかしっちゃかめっちゃか…。

まァ、そうなんだろうな。 「碎啄の機」ででもないと。 人の考えを変えるのは困難なんだ。

消費税はいただいてよろしい。というか逆に消費税分は払わない、というのは法律違反。 これを理解できてないところ (人、会社) が現状非常に多い。 処置なしといっていいレベルで。

ドライブレコーダの映像集。

あははは。 「社員は経営者ほど仕事へのモチベーションや強烈な精神力や体力がない (あったら起業してる)」 これを相互に理解してないところからくる行き違いや悲劇がとても多い、悲しいことである、と。

なるほどナムルかー今度作ってみよ。 もやし安くていいんだけど足が速い (傷むの早い) んで普段あんまし買ってない。

“定説”では、米国はアウトソーシングもしくはパッケージ購入が進んでいるけど、 日本は“旧態依然”の内製もしくはオーダーメイドが多い、 みたいな感じのことを見聞きする機会が多かった気がするが、 実態としては、日本のソフト開発技術者の大半は IT 企業に所属しているが、 米国の場合は一般企業に所属していると。

“努力”しなくても続けられる (自動的に続けてしまう) こと、か…。 あるにはあるがのう…。
コンビニ店長 (突然自分のブログ全消去して消えちゃった人) っぽい、 というコメントを見かけたが確かに。

そしてあの強迫的なライフハック記事の群れだ。

多いよねえ… (まあ、はてなブックマーク (via Twitter) とかからたどって記事読んでると、だけど)。
追記:やっぱりそうだったようだ。 ↑(店長)
まあ、会社員だと自分で方針決める機会は確かにない (必然的に与えられない) わな…。 意思決定に慣れる機会がないまま生きてきてる訳だから、 その点自営とは全然違うか。

nginx のマニュアルページ…らしいんだが (まあドメインも nginx.org だし)、 参考になりそうなのでちょっとメモを。

Imager.pm。 ちょっとした画像加工で、 perl スクリプトから convert (ImageMagick のコマンドラインツール) を呼び出さずに直接処理するには何がいいんじゃろ、と思ってざくっと検索したら引っかかった。 試しに cpan (cpanm) からインストールしてみたらインストールできてしまった。 perldoc (POD) も充実してる。英語だけど。 いろいろできて割と便利そうだが…。
白一色の Jpeg ファイルをファイルサイズ最小目指して生成してみたが、 ImageMagick で作成したのと比べると 3倍くらいでかい。 もっと縮める方法はあるんかのう…。
METHOD_INDEX と CONCEPT_INDEX。

菊池誠氏のブログが復活。

パソコン通信時代の BBS のログを保存公開している。 こういうの、個人でやってる (やらざるを得ない) ところがなんかアレだなァ…。 税金でやれとはいわないが、 金銭的に補助するシステムくらいはあってもバチは当たらない気がするんだが。

どうやら最近の流行りらしい…。 まったくなァ…。

ふむふむ。 確かにすごいとは思うけど (それに異存はない)、しかしこういうのメンドクセーと思う。 もっと省力に合理的に“解決”する道筋がなにかありそうな、そんな気がするんだよなァ…。 …つーかコンテンツ側に仕掛けないでもブラウザ側で勝手にやってくれればいいんじゃないのかしら…。 それだと「(なるべく) 見せる側の見せたいように表示する」のができないから受け入れられないか…?

千鳥学説を根拠に犬用のアヤしいサプリを販売している“専門家”。 with 読売新聞グループのお墨付き。

名前がちょっとなァ…。わかりやすいっちゃわかりやすいけど…。 で、画像提供元は大半 (全部??) が他のサイトで、 リンクたどって利用規約とか使用条件見るとそれぞれ違っていて結局若干メンドくさい。 という感触。 今後に期待か。
次々と…。

蝉ドンて…。

問題は、単に警察の強引な捜査だとかでっちあげにあるだけではなく、そもそも日本の司法自体に、実際に罪を犯していようがいまいが、本人にとって罪を認めるほうが得であるというインセンティブシステムが埋め込まれていることにあります。



なんだかなァ… > システム設計した奴。 blog 主は実装と運用のどちらに問題があるかは一概には言えないという考えのようだけど… まあカンペキな設計は不可能だとしてもちょっと手抜き & ホッタラカシ過ぎだと思うわ。

おお。これは。 4コマ雑誌とかも送れるのかしら…。
なんかすごいな…。

なんか記事にする段階でトンチンカンな内容にされてしまって、 セキュリティ専門家がこれって、みたいにネタにされてしまったという。 メディアの取材も、担当分野の基礎知識・専門知識を持った記者でないとダメ、 なんじゃないかな。ぼちぼち…。 もっとも取材する側の“思い込み”によるストーリーどおりに記事 (だの番組だの) が作られるパターンも、 わりと日常茶飯事みたいだから… (警察検察司法の冤罪濫造ルーチンと同じ構造だな…) まあ専門知識だけ持っててもしゃあないのかもしれんが。

怒るも叱るも結局のところは一緒。自分 (怒る|叱る) 側の都合。まあそうだわな…。

この意表の突き方はすごい。

なんかむつかしそう。
「人を動かす 新装版」D.カーネギー/山口博、創元社 ISBN4-422-10051-3 1575円 (1999.10)
過去に文庫版も出てたようだけど絶版ぽい。中古なら探せばあるかな。

↓これを受けての記事。

ニンテンドー3DS用ソフト「わがままファッション GIRLS MODE よくばり宣言!」。

そうだな~なんかやたらアクロバチックでデモンストレーチブな HTML5 の作例ばっかしあっちこっちで見せられ続けてた気がするな~。 つーか HTML5 といいつつ HTML5 範疇外のモノもひっくるめて総称してるくさい気がする。現状。

メモ。 ウチも遅いけど、まあ Flash に限らず JavaScript からなにから全部遅いんであんまし関係ないかも。

DeNA。 LINE のパクリ + α。いやはや。

なんにでもあてはまりそうじゃな。

基礎。↓以下の記事を受けて。そして、陰謀論にハマる人なんかの心理状態も同じメカニズムではないかと。

Cygwin 上から mp3 ファイルの ID3 タグを編集するのに、 id3v2 を試してみようとインストールを試みた。 まずは id3lib (3.8.3) のインストールが必要なのでソースの tar を拾ってきて、 configure したところ、途中でコケる。 入っているハズと思われるヘッダファイルが見つからんらしい。 検索してみたら、どうも gcc/g++ 4.x 以降 (?) でコンパイルしようとするとこうなるらしい。 で、パッチが公開されていたので当てたら問題なく configure、make、make install完了。
次に id3v2 なんだが、これも難儀した。 Sourceforge から 0.1.12 の tar をダウンロードしてきたが、そもそも configure がない。 コンパイル済実行ファイルも含まれていたがそもそも Cygwin 用じゃない (拡張子がない)。 make したらコケる。 これもいろいろ情報を検索して、Makefile を修正して対処。
  • PREFIX= /opt/localPREFIX= /usr/local に変更
  • id3v2: コンパイル部分のオプション並びを、 … -Wall -g -o $@ $^ -lz -lid3 から … -Wall -g -o $@ $^ -lid3 -lz -liconv に変更
で、あらかじめ make clearn しておいてから make; make install でうまくインストールできたと思う。 インターネットさまさまだなァ…。
で、id3v2 自体はそれほど多機能なツールという訳でもない感じで、 結局は Perl で (適当なモジュールを使って) ツール自作した方が後々ラクかもしれない。


近代科学技術発達の概略。おもしろい。




ほえほえ…。 「フェラーリ娘」にはこんなに姉妹がいたのか。

ほえほえ。 うさドロ。

まあ、たぶんこんな程度は氷山の一角なんだろうな、と思いつつ。 そしてコメント欄にわらわらと湧いてくる石原擁護軍団。

自制心なァ…。
「何かする」意志の力は弱々だけど「何かしない」のには比較的強いかも、 と自分では思っていたが、 実はどっちも弱々だったかもしれないなァ、と最近認識がちょっと変わってきた。 例えばお菓子 (おやつ) を、数日間から 1週間分くらいのつもりで買って、 数時間から 1日以内くらいに買っただけ全部食べちゃうようになってきた。 しかし、自分で作るポップコーンは例えば 200g 買って 1回につき 40g ずつ使うとして、 1日 1回だけ作ると決めると 5日間もったりする。 つまり「しない意志の力」が強いんではなく、 「めんどくさい」ことは避けたい欲求が強いだけなのかもしれない。 そしてありとあらゆることがなにかにつけてメンドクサイ。
という訳で自制心鍛えるのもメンドくさい…。詰んでるな…。
それはそれとしてこのサイトは面白そうかな…購読してみるかな…。

あ~あ。

毎日新聞 2012年10月28日 08時48分(最終更新 10月28日 09時25分)

 東京タワー(333メートル)から東京スカイツリー(634メートル)=今年5月開業=への電波塔移転が、当初予定の来年1月から大きくずれ込む見通しとなったことが27日、NHKなどへの取材で分かった。スカイツリーから電波を出した場合、想定以上の障害が発生する恐れが強く、対策に時間がかかるため。NHKと在京民放5社の放送事業者には、視聴者の多い昼間に東京タワーの電波を止めて、スカイツリーの障害の全容を把握すべきだとの声もあり、視聴者を巻き込んだ大きな混乱も予想される。

 放送事業者は東京タワーから電波を関東広域圏に送出している。東京タワー開業から50年以上たち、周囲に高層ビルが建ち並んだため、ビル陰などによる電波障害の解消や新たな観光名所を目指して、約650億円かけてスカイツリーが建設された。

 スカイツリーのアンテナは東京タワーより200メートル以上高い位置にあり、ビル陰などによる受信障害は大幅に減少すると予想されていた。ところが、今年7月からNHKと民放各局が共同で、スカイツリーから試験電波を出して受信状態のサンプル調査を始めたところ、電波が強すぎることやアンテナの向きが原因で、全く映らない世帯が方角や地域に関係なく見つかった。

 障害の全容把握のための電波試験には、東京タワーの電波を止める必要があり、視聴者の多い昼間の試験となると影響も甚大だ。

 NHKのある幹部は「1月の移転は無理。アナログ放送と並行した地デジ化とは異なり、今回は一夜で行うため、それまでに難視聴世帯対策を完了する必要がある。5月までに解決したいが、莫大(ばくだい)な追加費用がかかる」と戸惑いを隠さない。総務省関東総合通信局は「受信対策をしっかり行って、早く移転日を決めてほしい」と話している。【土屋渓】


AdBlock Plus は Web ページの広告類の表示を消す Firefox の拡張機能 (Add-on) だが、 日本語ページの広告は表示されっぱなしの場合が結構あった。 まァ海外製アドオンだし仕方ないか…とか何も考えずにそのまま使っていたんだが、 ふと日本語ページ用の設定も誰か作ってるよな…? と思いつき (なぜいまごろになって思いついてるのかようわからんが… 以前探したけど目ぼしいものが見つからなかったんだったかな…??)、 ちょっと検索してみたらすぐヒット。 なんだ~あるじゃん。 これで日本語サイトの閲覧も快適さが増すであろう。
…と思っていたら、フィルタ設定がキツすぎるのか表示がヘンになるサイトがぼちぼち…。 しかしこの拡張機能の性質上“表示されるべき箇所が表示されなくなる”ため、 ヘンになっていることに気づきにくい (これは日本語ページ用フィルタに限らず AdBlock 元々の弱点だが)。 まァ見つける都度、例外条件を追加していくしかあるまい…。
追記:予期せぬ不具合がやや多すぎるため使用継続を断念。断念で残念。(駄洒落)

「少ない手間と知識で“それなり”に見せる、ズルいデザインテクニック」 Web デザインの「常備菜」的 (?) な小技。 なかなかおもろい。 まァ、CSS3 とか SASS (SCSS) とかが使えてこその、だな…。

最近、Web や SNS 界隈でやたら宣伝してて (?) それなりに売れてるらしい「PCメガネ」について。 まあありがちなイメージ商品だろうと思うんだが、 「ブルーライト害悪説」とセットで宣伝してるあたりがアレだな。 実用性+αの「+α」部分が気に入って買って使ってる分にはまァいいんだろうけど…。

日本でGIDの非病理化の声が盛り上がらないのは、ひとつには時代を先取りしていた??かもしれない。

つまり、日本で性同一性障害がマスコミなどで紹介されるときは「心と体の性が一致しない状態」としてである。

「性転換願望を持つ精神疾患」などというような理解はされてない。

精神疾患であることも、当事者と専門の医師以外は、あまり認識されていない。

なるほど。

ベンゾピレン。 調理過程でも生成され、食物から完全排除はできない物質。 喫煙者はいつも (自分から) 吸い込んでいる。 普通の生活で摂取する量は推定平均 89~127ng (農林水産省による)。 この程度の摂取量では健康への影響は低い。 この倍程度の高摂取群では、 健康への影響の可能性とリスク管理が必要になる可能性 (回りくどいな) が示されている、と。 今回は原料のかつお節が韓国の基準値を超えていたために回収になったらしい。 まァ、そんな程度の量なら影響はまずないといっていいだろうなァ。 というか、辛い系のラーメンはほとんど食べないし (タイから輸入のアレくらい)、 個人的にはぜんぜん関係ないけど。 韓国の辛ラーメンはけっこう高いのもあって買ったことないし…。
元々、韓国の基準も厳しすぎるみたいだな。 韓国でも議員騒いだのがきっかけで回収したらしい。 で、韓国で回収したんだからと (安全かどうかとは全く関係なく) 日本でも回収を決めた、と。 非合理的な“政治的判断”“行政判断”つーのは国を問わず厄介なモノだな…。

マインドコントロール、の手法そのままだな~。

TV 番組の企画で作ったアニメーションの BGM で使用した曲のメンバーから、 正式な PV として採用された、と。 このつながりは YouTube に上がった (番組のキャプチャの) 動画経由。

Chrome 内で動く。 別途 (環境ごとに) ヘルパーアプリが必要。

床から 20cm の空間は細菌汚染が最も激しい。 床から 20cm というとワシの現在の生活空間だな。ほぼ 24時間腰までずっぽり。

おおぅ。 100% 完全に段ボールという訳ではないようだが。 ちょっと面白そう…。


竹熊健太郎氏その他のつぶやきまとめ。 ふむ。

蛇足的脚注

*31-1 : VOB ファイル
DVD VIDEO に収録されているうちの、映像・音声データ部分のファイル。 実質 Mpeg2 ファイル、なんだが、 コンテナなのか生データなのかとかそのへんちゃんと把握してなくて…。 万一コンテナだとすると単純に append しても正しくデータ結合できないだろうと思って検索したら、 専用の merge ツールがあちこちで紹介されてるんで、ああやっぱりそうかと思い込んでしまった。 根本からの検証をサボったせいでまんまとダマされてしもうたわい。 進歩ないねえ…。
*31-2 : lame
今んところ一番有名で、一番多く使われている (…と思う) MP3 エンコーダ (MP3 ファイル変換ツール)。 無償で高性能。
*31-3 : リールタイプのキーホルダー
リトルリーフというメーカー (たぶん) の、 キーバックワイヤー KC-800C という型番のもの。 ドン・キホーテで約 600円だった。
もうひとつの部屋の鍵用に使っていたのは、メタルリール KMC-23 という型番のもの。 こちらはドン・キホーテで約 1000円だった…高…。 値段こそ違うが、ワイヤーの太さやリール部分の機構などは見たところ共通っぽいんで、 これも壊れるとしたら時間の問題かもしれんな…。
*31-4 : MacType
Windows の画面のフォント表示をアンチエイリアス化する常駐ユーティリティ。 字画の多い文字が綺麗に (判読しやすく) なる、場合がある。 作者は中国の人ぽい。ま~中国も簡体字とはいえ字画多いからな…。
*31-5 : モトヤフォント無料版
モトヤはフォントメーカーだが、 過去何度か、お試し用に一部の書体を無料で公開している。 商用利用は不可だが個人使用ならほぼ無制約。モトヤエラい。 PC (Windows) 用には NFモトヤアポロ、NFモトヤバーチ、NFモトヤシーダ。 あと Android 端末用に Apache ライセンスで何種類か公開している模様。