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

> この駄日記はこのところしばらく現実世界とは別の人格が書いてる。 現実世界の方はいろいろアレんなってんのに、ここではなにも事件が起きてない感じ。 いや別人格じゃなくてパラレルワールドだな。 人格はむしろ現実世界の方でズレを生じてるくさい…。

> しばらく食事量少なめが続いたせいか、 いつの間にか体重が 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 の端末から、 久々に awk を使ってみたがだいぶ文法を忘れてた…。
一番多かったのが 2009年 6月。 NOAH の三沢選手が試合中の事故で亡くなった月だなァ。 翌 7月とあわせて 700件以上取り込んでる (全部が三沢選手関係のデータではないが)。 次に多かったのが 2011年 3月。 東北地方太平洋沖地震の起きた月だな。 こちらは翌 4月とあわせて 600件くらい。 大量の写真を掲載しているサイトが多いので、件数の割に容量は食ってる。

> 友人が、交通事故に遭ってしまった模様…。
自転車で走行中に、脇道から右折してきた新聞配達のバイクと出会い頭に接触とか。あ～。 右腕が手首から先以外動かなくなってしまい、原因はまだ特定できてないようだけど、 検査によると事故のショックで脊椎にヘルニアができて神経を圧迫している、らしい…。 利き腕かつ商売道具だから大変だよな…。 四十肩で可動範囲が狭まるだけでも結構厄介なくらいだし (最近右側もまたぶり返し気味。つーかこれひょっとして死ぬまで治らんのかしら。閑話休題)。 なんにせよ無事に治りますように。

> こんなしょーぉぉもない駄日記でも毎回推敲している。 ためつすがめつ書いて、書き終わって通して読んでみて、しっくりこないところを直す。 気が済むまでいじって、しばらく置いとく (最近は月一ペースだから置き時間たっぷり)。 しばらく置いた後で読むとまた直したい箇所が増えてて、直す。 エディタ上で読んで特に問題ないと思ってもブラウザで表示させて読み直すと、 大抵は引っかかる箇所があるので直す。 と、後の文章とつながりが悪くなるので後の文章も芋づる式に直す。 記述内容にムラがあるようなんで足したり削ったりしてみる。 記述の順番を変えてみる。 どうしてもくどくなっちゃう部分をばっさり削ってみる。 削ったら全体的に「だからどうしたの」みたいな内容になっちゃって結局まるごと削るとかも。 そういう推敲の真似事のようなことを、 いつま～で続けても一向に「これでよし」状態にならん。 基本的に文章書くのがヘタクソなんだろうな～。 と思いつつもなんとなくやめる気にもなれず、こうやって延々書き続けている訳だが。 書ける環境と状態が続く限りはたぶんこうやって駄文をどこかに書き続けるんだろうな～。