SKYNETs_EYE

お外でのメモ取りには後でブログなどに使えるように紙ではなくデジタルデバイスに書いている。
ただし、キーボード搭載のポケットPC等ではなくてPalmというPDAを使用している。
このPalmはキーボード非搭載ながらもGraffiti(R)(グラフィティ)という独自の入力方法により、ペンでアルファベットや数字記号を認識できる。

Graffiti(R)(グラフィティ)

PDAの一種であるPalmで用いられる文字入力方法の一つ。例えば「A」を入力するのに「∧」のような形を、「B」を入力するのに「β」のような形を入力する。
これらは一筆で書けるようにアルファベットを簡略化したもので、これを用いることによってすばやく文字を入力することができる。一般的な文字認識に比べて処理が軽く、入力もしやすい。
グラフィティを入力するためのスタイラス画面は左右に分割されており、左側にアルファベットを、右側に数字を入力する。また「/」(左から右上への斜線)に続けて何らかのアルファベットを入力することでコマンド入力となる。
(英語版Wikipediaより)

独自とは言っても習得には30分もかからない。
購入して、30分ほど意識しながら文章を書いていれば違和感なく身に付いてしまう、それくらい自然に即した優れた方法だと思っている。

こういう事を書くと私が新しい物好きで色んなガジェットを弄りまくっているから、苦痛なく覚えられるのだろうという突っ込みを入れる人もいるがそれは間違いである。
私はたいていこう言った物に対しては保守的で気軽にチャレンジもしないし、使ってみて少しでも苦痛を感じる物はすぐに投げで出してしまう。
携帯電話のキーで文字を入力することですら未だに苦手である。
またGraffiti(R)はその後、特許の関係からGraffiti2というやや入力方法が変わった物に変化してしまった。
これですらとても我慢ならず、元のGraffitiの書き方に戻すように細工をしている。
こういう利権絡みで最も優れた方式を無理矢理ねじ曲げられて一番とまどい迷惑を被るのはエンドユーザなのである。

話が長くなってしまったが、これほどまでにGraffiti1が気に入ってもはや手放せない物だった。

だから現在使用のPalm機 PEG-TJ25 を購入したときにそこに付いてきていたDecumaにはまったく意にも介さなかった。
ちょっと起ち上げて認識率や入力スピードの遅さなどで早々に使うことを諦めてその機能を切ってしまったのである。
Palmの日本語入力にはATOK for Palmを使用している。
このパッケージ版にも手書き入力機能もあったのだが、使わない物と頭から決めつけて少ないメモリを節約するためにその機能部分の本体への転送すらしていなかった。

先日、仕事ではじめてお会いした人がPalmを使用しているのを見て、あまりの珍しさについつい話し込んでしまった。
その方曰く「Decumaって使いやすいですよねぇ」って同意を求められて、ちょっととまどってしまった。

さっそく帰宅して、ATOKの手書き機能をインストールして、PalmのDecuma機能を復活させてみる。
相変わらず入力は遅いのだが、使い込んでみて誤認識から選択肢を選べることや、そもそも誤認識は自分の書き順の間違いが元だったなど色々と気付かされた。

デジタル機器を使って文章を入力すると極端に漢字を忘れてしまう。
かといって、紙の手帳にペンで書いたのではそのコンテンツの使い道が限定されてしまう。

文章内容が後々で自分にも理解しやすくするために、他人に認識してもらえるようブログで公開の形を取っているが、
文字では綺麗な文字と正確な書き順で機械に認識してもらうという意識が働く。

文字の書き順とは筆をスムーズに運ぶために考え抜かれた物なので正確な方が効率的なことは言うまでもない。
たとえば「と」というひらがなについても、私の癖で下の「く」の字を書いて上の「、」を付けてしまうが、これだとDecumaには認識してくれない。
「出」の文字でも縦線をまず書いて、それから横横と書かないと認識してくれない。
つまり文章の内容を閲覧者の目を意識し、文字の書き順や正確さを機械の目を意識しながら書くので、まるで常に先生に見られながらみたいでなかなか頭を使ってよろしい。
長年間違えていた文字の書き順や悪筆も矯正される。
漢字が思い浮かばなくても、ひらがなでまず書いて変換して、漢字が解ったら再度漢字で記述することもやる。
漢字を忘れないためのアナログとコンテンツの使い回しのためのデジタルが上手く合わさってなかなか合理的で気に入ってしまった。

もっとも、急いでいるときには今まで通りGraffitiを使用する。

私の中での入力スピード順で並べると
キーボード入力>>>>>>Graffiti>手帳に手書き>>>Decuma なのである。

このように入力のスピードだけ追求するならばキーボード入力に敵うものはない。
ところがこれを漢字を忘却を防ぎ書き順を覚える訓練と合わせてブログのコンテンツの作成と考えるとだいぶ意味合いが変わって来る。
訓練と併用なので入力スピードの効率だけにとらわれる必要がないのである。

Graffitiはあくまでもメモ取りであるが、Decumaはというとこれが俳句を考えながら記述するのに似ている。
頭の体操のつもりで機械の目を気にしながら文字を書き、閲覧者の目を気にしながら文章を考える今日この頃なのである。

先日の新書で簡単な会計を扱った物を読んだ影響で、それから意識して会計的に他の数値に置き換えてみることがある。

消耗品を買うにも価格からグラム単位に割ってみてどちらが徳か比較することは良くやるが、もうひとつ使う頻度も考慮に入れることもしている。
もちろん、消費期限のある物はそれも考慮に入れて無駄にすればそれだけのロスが生じるのでこの期間で使い切れるかどうか?
長期間保存できる物でも使用頻度からの量を考えて、たとえ少量で割高であっても選んだりと色々悩んだ末に決める。

最近、旅行会社のCMで新圧が出て来て「3人目半額」を連呼するものがあるが、これなんかも会計的に見ると6人に1人の割合で全額負担ということで実際はー率15%引きというだけの話で値引率としては決して良い物ではない。
ところがこの「3人目半額」と聞くととても安く感じられてしまうからまさに言葉のマジックである。

これらの置き換えを意図的に使えれば仕事の営業でも効果が期待できそうだ。

24 TWENTY FOUR Season5がやっと最終話が終わった。
今回は何とも痛々しいとしか表現しようもないが、ここに描かれている、ソレがそのまま国民の今の政府に対する感情の表れとも言えなくはない。
話題のある人気のドラマだけに政府からの圧力がないか心配になる。

そういう意味では、華氏911を超えているかもしれない。

Season4のラストはもう続かない印象で終わったのだが、 Season5のラストはもう、 Season6を作る気満々な気概が感じられて頼もしい。
次回はいよいよ中国か...。
これも、現在の対中関係に遠慮することなくいつもの通りアグレッシブに描いて欲しいと思う。

主演のジャック役、キーファー・サザーランドも、もうこの役でイメージを固定される危惧なんて諦めて、このまま突き進んで行った方が良いんだろうね。
「上様」役のイメージが既に固定されたマツケンだって、それを打ち破るくらいの強烈な個性を持つ「サンバ」で新たな活躍の場を開拓できた。
今ではバラエティで「上様」のイメージを上手く利用すらしている。
なんにせよ、話題になって需要があるうちはやり切った方が良いだろう。

役のイメージ固定と言えば、ジャックの昔の上司、ヘンダーソン役のピーター・ウェラーさん。
このひともかつてロボコップの役がはまりすぎて、そのイメージの固定を恐れてシリーズ2で降板。
その後、別の当たり役があったわけでもなく、それほどメジャーになり切れなかった。
もともと演技は上手な人なので今回の役でまた新しい仕事のオファがあると良いなと思う。

ダ・ヴィンチ・コード
全世界4900万部、空前の大ベストセラーは始まりにすぎなかった──
2006年5月、ついに史上最大の暗号が解き明かされる!
2003年の刊行以来、44ヵ国語に翻訳され、全世界で4900万部を超える驚異の大ベストセラーとなったダン・ブラウンの「ダ・ヴィンチ・コード」。今も世紀の天才と讃えられるレオナルド・ダ・ヴィンチの「モナ・リザ」「岩窟の聖母」「最後の晩餐」に、驚くべき秘密が仕組まれていた。名画に隠された暗号を解き明かせば、歴史を揺るがす恐るべき真実にたどり着く……。
事実に基づきながら、独自の解釈と大胆な想像力を加え、超一級のエンタテインメントに仕立てられたこの小説は、日本でも400万部を突破、現在も売り上げは伸び続けている。この空前の大ヒットを受けて、ダ・ヴィンチにまつわる数々の謎について語られた関連本が続々と刊行、TVでも特集番組が組まれるなど、もはや「ダ・ヴィンチ・コード」は小説を超えた社会現象と化したのだ。


ダ・ヴィンチが名画に隠した暗号とは?
歴史の真実を託された2人は、謎の扉を開けることができるのか──
始まりは、実に奇妙な殺人事件だった。パリのルーヴル美術館で発見された、館長のジャック・ソニエールの他殺体は、レオナルド・ダ・ヴィンチが描いた「ウィトルウィウス的人体図」を模した形で横たわっていた。しかもそれは、瀕死の傷を負った身で、自ら作り上げたものだった。さらに死体の周りには不可解な暗号が残されていたのだ。
講演会のためパリを訪れていた、ハーヴァード大学の教授ロバート・ラングドンが、深夜にもかかわらず現場に呼ばれる。フランス司法警察のベズ・ファーシュ警部は、表向きはラングドンの専門知識を駆使して捜査に協力してほしいと求めてきたが、実は彼は第一容疑者なのだ。ラングドンはその夜、ソニエールと面会の約束をしていた上に、暗号の中に彼の名前が記されていたのだ。
ファーシュ警部が巧みな誘導尋問で、ラングドンから証拠となる発言を引き出そうとしていた時、暗号解読官のソフィー・ヌヴーが現れる。ソニエールの孫娘であるソフィーは、現場の写真を見て、ひと目で祖父が自分だけにわかる暗号を残したことに気付いた。さらにラングドンが無実であることにも。ソフィーはファーシュ警部を巧みに欺き、ラングドンを連れてルーヴルから逃走する。ソニエールが暗号で隠し場所を示した、ある秘密結社の紋章が刻まれた鍵を持って……。
警察の厳しい追跡をかわしながら、暗号の謎を解き始める2人。しかし、それは新たな謎の始まりに過ぎなかった。ソニエールが深く関わっていたらしい、秘密結社の目的とは? ダ・ヴィンチが絵画に残した、歴史を揺るがす暗号とは? そして、ソニエールから2人に託された、重大な真実とは? 今、警察とは別の追っ手が、2人に迫ろうとしていた……。

遅ればせながら、話題の映画と閲覧した。
原作の方はだいぶ前から論議を醸し出していたので関連する書籍も含めてざっと目を通していた。
なのでストーリーそのものには目新しさを感じなかったが、トムハンクスなどベテランの俳優の登用でいかがわしくなりがちな物語に重みを与えているように思えた。

最近、久しぶりにファイルメーカーをいじくり回している。
Ver4の頃までは仕事の依頼で結構ディープに使っていて、たとえ、無い機能でも工夫すれば、ほとんどのことが出来るようになった。
それが、いつの間にやらVerUpをして、インストールはするものの起動することが希なソフトになってしまった。
ひとつはデータベース自体が非常に地味なものなので、他に覚えたり、使いたいソフトが多く出てきてHDDの肥やしになってしまったようだ。
それを最近の仕事の依頼で久しぶりに起ち上げてみたわけである。
Ver7から完全なリレーショナルになり、根本的な仕様が変わってしまい、以前との違いに正直とまどった。
しかし、実際試行錯誤して頭を悩ませて動く物を作り上げたら、なんとなく感覚として理解できた。
こういうものはマニュアルと睨めっこしていてもなかなか理解できないものである。
やはり、実作業で実践的に制作する中で試行錯誤の上で身体に覚え込ませることが学習の一番の近道だろう。
いじくり回しているうちに、「やっぱり、俺はデータベースが好きなんだよなぁ」忘れかけていた昔の感覚が蘇ってきた。

結局PCのほとんどの技術もデータベースであると言えなくもない。

ネットで普及している大部分のデータベースはSQLというデータベース規格言語を使用している。
XOOPSもMovable Typeもちまたに溢れるブログシステムもこのデータベースの技術無しには考えられない。

残念なことにファイルメーカーはこのSQLには直接には準拠していない。
ただ、Apacheと他のSQLデータベースを使用し、管理用のフロントエンドとしてファイルメーカーを使用できるらしいので、ネットで構築やメンテナンスのしやすいシステムが組めるかどうか調べてみようと思う。

ファイルメーカーProを使用したホームページ制作

以前よりエントリーで取り上げていたグーグルの100ドルPCに進展があったようだ。

今度はヴィヴィッドオレンジ--100ドルPCに新プロトタイプ

開発途上国の子供たちに低価格のPCを提供するという「One Laptop Per Child(OLPC:すべての子どもにラップトップを)」の目標が、また一歩実現に近づこうとしている。
非営利団体のOLPCは今週、いわゆる「100ドルPC」のプロトタイプを披露している。OLPCが、実際のコンピュータ部品を積んだプロトタイプを発表するのは今回初めてだ。

脇にあった充電用のゼンマイクランクは回転時の不可に本体が歪む恐れから外されたそうである。
充電は外付けのアダプター部に付けられるらしい。
オレンジでも、グリーンでも良いのだが、デザインの好みから言えば以前の方が良かったような気がする。

今回初めて実際に稼働する部品を付けて物らしいが、予想外だったのが最近のLunuxの肥大化に伴う動作の遅さが目立ってきたという。

Negroponte氏は先月、「Linuxのサイズが大きくなり過ぎた」ために、このことが「小さくて動作の軽快なシステムを実現する上での障害になっている」と不満を漏らしていた。

日々Linuxも肥大化しているため当初500Mのフラッシュメモリではきつくなってきているのだろうな。
このPC専用に無駄な機能を削ったライト版を作成しているらしい。

たとえば、LinuxベンダーのRed Hatから参加しているチームは、OSのサイズを400Mバイトから250Mバイト程度まで小さくすることに成功した。

それでも、予定のメインメモリの半分くらい持って行かれる。
多分これは英語圏システムでの計算だろうからこれが日本語などの2バイトコード圏で組むとそれなりに増えるんだろうな。

私が今まで使用した中で飛びっきり軽快で実用的なOSといえばPalmOSだった。
今回のような教育という使用目的からすれば、むしろPalmOSの方が合っている気もするが、もやはトレンドでもないし、マイナーなために先細りなので現実的ではないのだろう。

むしろ、軽いLinuxにネット機能を充実させて、ネットの「あちら側」にあるアプリを使用するフロントエンドとして扱った物の方が良いかもしれない。

その昔にこの「ネットのあちら側」を主体とした「NC(ネットワークコンピュータ)構想」が有ったが、当時はまだインフラも普及されておらず、通信速度もそれほど期待できないことから頓挫してしまった。

ところがグーグルがこれから構想しているのは正にこれではないかと思われる。
ネットのあちら側に高機能なアプリを無料で使用させる。

例えば写真画像処理ソフトと言えばPhotoShopが定番あるが、これは高機能でソフトウェア自体の値段も高い。
プロでそれで稼げる人はともかく素人が個人で購入するには少しはばかれる物なのである。
実はPhotoshopと同様の機能を持つオープンソースのGimpというアプリも存在するが、Unix発祥のアプリで導入及び運用には敷居が高い。

しかしPhotoshopと同様の機能を持ち、操作が簡単なアプリををネットの向こう側に公開したらどうだろう?
利用者にとっては使用した結果が欲しいだけなのでネットの向こう側に投げて結果だけを受け取る。
重い処理に必要な強力なCPU等のハード構成はネットの向こう側に存在すればよく、こちら側は結果を受け取るだけでよい。

Photoshopならば私は頻繁に使っているのだが、それに限らず、月に1回もしくは半年に1回くらいしか使用しないアプリがHDDの肥やしになっているケースも多い。
それらを全てネットの向こう側に追いやってローカルには向こう側に預けてある物を取り出す個人認識の鍵程度の位置づけになって行くのでないだろうか?

だれしもアプリそのものが欲しい訳じゃなくて、それによって得られる結果が欲しいだけなのだから。

もっと進めば、ローカルのハードという物はやがて希薄になってゆき、身一つでどこに行ってもその場にあるハードが全てネットに繋がっていて自由に自分のネット環境に繋がり、利用することが出来る、それがユビキタス社会になるのだろうと思う。

今年はワールドカップのある年はとかくあちこちで嫌でも関連物を目にする。
まぁ数多くの人が盛り上がるわけで、商売に聡い人はこの気運に乗るというのが常套なのだろうが、ちょっと騒ぎすぎなんじゃないかと思う。

正直私にとってはどうでも良いことなのだが、こうも「みんな興味があって応援しているはず」と決め打ちで押しつけられると拒否反応すら起きてくる。

サッカーと言うスポーツそのものには嫌悪感がないのだが、どうも選手の態度に印象を悪くしたらしい。
インタビューを受け答えなどがどうも不遜な態度に見えてしまう。
まぁ厳しい勝負の世界だからそんな愛想が良くなくても実力があればいいのだろうけど、同じ勝負の世界でも他のスポーツ選手にはあまり見受けられない不遜さがとかくサッカー選手には見えてしまうのである。
もしかしたらサッカー界全体的に不遜な態度OKなんて空気があるのではないかと思えるほどである。
例外として巻選手などはだいぶ丁寧な受け答えで好感が持てたけど、彼の場合は予想外に選考に入ったことが謙虚さにも繋がっているようにも思える。

だから、不遜な上に「全国民の期待に応えて...」などと話しているのを見ると「別に私は期待もしていないし、むしろサッサと負けて騒ぎが収まってくれた方が良いとさえ思ってる。」などと、ひねくれた感情すら湧いてしまうのである。
そんなことをサッカー好きな人が聞いたら恐らく「非国民」などと言われそうである。

しかし選手もファンの人も中にはそういう人もいるのだという事を意識の隅っこにでも置いて行動や発言をしてもらえば、そもそもそんな感情も起きずに済むのではないかと思うのである。

何ごとにおいても一元的な価値観を押しつけられることほど嫌なことはない。

前のエントリー「HHK」でも書いたが、キーボードというものは操作のフィーリングに直接関わってくる物で、CPUと比べて永らくつきあえるデバイスなので、多少高くてもこだわった物が欲しいし、もっと製品の幅があっても良いと思っている。
ここ数週間、ネットを注意して閲覧したら以下の物を見つけた。

防水ステンレスキーボード“頑丈打"

かなり無骨なスタイルで飾りっ気もなく、見たところ組み込み用のキーボードを流用したようにも見える。
多分金型の節約のためかキーの大きさがコマンドキーなども同じで普段使いとしてはちょっと辛いところだが
全部がステンレス製で防水なのが魅力だな。
時々使っているキーボードを水でジャブジャブ丸洗いしたい衝動に駆られるので心惹かれる。

“木ーボード~樹魂(じゅこん~)"
こちらは木製でなんとブラックウォールナットとメープルで材質も選べる。
キーもちゃんと彫り込まれていて写真から受ける存在感も圧倒的だ。
これは使い込むほどに味が出てきそうで良い。
好みで言えばチークが香りも良く粘りもあるのでレパートリーの欲しいところ。
ただ、残念なことに「win」キーである。
まぁ、ユーザの数から言って仕方がないのだが、もっと汎用的な配列にして欲しかった。

以上2台とも注文数がある程度集まってから製造に入るらしいので店頭でキータッチなど気軽に調べるわけにもいかない。
その割にはおいそれと購入できる値段でもないので、影ながら応援して、この手の市場がより増えてゆくことを願ってやまない。

最近、IQを扱ったクイズ番組やゲームがヒットしているが、解答には柔らかな頭を要求される。
たぶん火付けは任天堂DSの「脳トレ」だろう。
この系統のゲームは数年前からPalmでしかもフリーソフトで出回っていたのだが、やはり大々的なCMとゲーム機を軸にしないと世間には広まらない物なのだろう。
まぁ今回はそれはさておき
今日のエントリはそういう思考的な譬喩表現の「柔らか頭」ではなくそのものズバリ物理的な「柔らかな頭」である。
先日のエントリ「叩いて揉む」にある通り、肩こりが酷いのでしばしば叩いたりツボ押ししたりしているが、
肩がほぐれてくると普段は意識していない、その上の方の凝りのが気になってくる。
肩がほぐれても首筋から後頭部の方の血の流れが悪いと結局は肩に血が停滞してしまう。
やはりメンテナンスするならば全身に渡ってまんべんなく血の流れがスムーズになるよう心がけたい。
とはいえ後頭部はメンテナンスがなかなかしにくい。
背中ツボ押し器の「ケンシロウ1号」で時々押してみるものの、長時間押し続けるにはちょっとやりにくい場所であったりする。「イモキン」で叩いたのでは脳細胞を壊しそうで怖い。
ツボ押しの解説書のように指で押しても石のように固く凝っているのが解り、ちょっとやそっとではほぐれそうにない。
どういうわけか昔から頭の中の血が滞っている様子を想像すると昔から赤黒いドロドロした固まりが頭蓋骨の裏側にビッシリ張り付いているイメージがどうしても離れない。
これをどうにかサラサラとした新鮮な血流にしたいものだと思うわけである。
ちょっとグロい話だが脳蓋をカパッと外してドロドロの脂まみれになった脳を洗浄液に浸して綺麗にして戻せばだいぶスッキリサッパリするのでは、とそんなことすら想像してしまうのである。

実家にたまたまあった中山式快癒器に頭を乗せてみると後頭部の首の付け根にツボにピッタリはまってものすごく「痛・くすぐったい・気持ちよい」。
4つ玉に頭を乗せてツボにフィッテングして左右にグリグリしばらく動かしてみる。
こういう物は「気持ちよい」から「痛い」になった時点で止める物だが、1時間経ち2時間経っても「痛い」にはならない。
よほど凝っていたのだろう、挙げ句の果てはすっかりリラックスしてそのままスヤスヤと眠ってしまった。
久しぶりに長時間、昼寝をして、久しぶりに多くの夢を見た。
ここのところ、夜は熟睡して夢は見なかったのだが(憶えていないだけかもしれないが)もしかしたら凝った血とともに夢の方も固まっていたのかもしれない。
そんなことを想像してしまうほど実に様々な夢が放出された感じだった。

だいぶツボ押ししたつもりだったが起きてからも後頭部にちょっと熱を帯びているもののまだ凝っている実感はある。
私の場合メンテナンスするときには集中してしつこくやる。
掃除と同じで、今まで手つかずだった散らかった部屋はまず徹底的に綺麗に掃除し上げるのと同様である。
本来の状態に戻してからその上で日頃のメンテナンスは予防程度に行うのである。
おかげで頭の血の巡りが良くなるとだいぶスッキリした感じになる。
集中力も高まった感じである。
4時間くらい続けているのだがまだ完全に凝りがほぐれていない感じである。
じっくりメンテして「柔らかい頭」にしようと思う。

本を読む場合は流行に関係なく、ある程度時間が経過して評価の固まった物を読むことが多かった。
むしろ話題のものは避けているところがある。

ここ数年読書量が圧倒的に減っていたので読むペースが遅くなっていたが、ちょっと慣れれば昔乱読していた頃のスピードぐらいまでには戻った。

ここのところ、昔の乱読していた物の中からよかった物をゆっくり読み直していたのだが、だいたい読み終えてしまった。
加えて古い物ばかりを読んでいると新しい物も読みたくなる。

以前ならば、無駄な情報の氾濫を避けて、熟成期を設けて読んでいたのだが、新書には新書の良さがある。
新書には「今」に即した事柄が描かれているので、より「今」という自分の置かれている環境に対しての理解も進むし、共感も得られやすい。
まぁ、新書は新しい見解の発表した物が多いのでそれが果たして正しいか間違っているかはもう少し時間をかけてみる必要があるだろう。
若い頃には感化を受けやすいから、本を読んでしまうとまるでそれが真理のように勘違いしてしまうところがあったが、この歳になるとある程度流し読んで、参考にするだけのゆとりが出来た。

そこで最近では、むしろ話題の本を読むようにしている。
だいたい新書くらいのボリュームならば3時間くらいで読むことができる。
あまりじ読む必要の無いような物は要点だけを流し読みならばで1時間くらいでだいたいの概略をつかむことが出来る。
ここ1週間で以下の4冊くらい立て続けに読んだ。

超バカの壁 (新書)
養老 孟司 著
最近の社会問題を著者独自の切り口で書いて物だけれどもそれほど目新しさは感じられなかった。
一元的な物の見方を戒めることは前書と同様である。

人は見た目が9割 (新書)
竹内 一郎 著
題名だけを見ると内容より外見で判断が9割のように捉えてちょっと違和感のある物であったが、内容は違った物だった。
要は言葉などの言語情報要理も見た目から入る視覚情報の方が圧倒的に影響力があると言うことが書かれていた。

著者は漫画家でもあるので自分の劇画の表現方法の学習としてまとめた内容が多いように思う。

さおだけ屋はなぜ潰れないのか? 身近な疑問からはじめる会計学 (新書)
山田 真哉
昨年発行なのでもはや新書ではないのだが、題名の掴みのさることながら、内容の冒頭から引き込まれてついつい読んでしまった。
そういえば、うちの近所でも月に1度くらいの割合でこの「た~け~や~。さおだけ~」という呼び声の車が通ることがあって、その度に「よくやってゆけるよなぁ」と常々疑問に思っていたところである。
そのほか、ベットタウン住宅地のど真ん中にある高級フレンチレストランは何故潰れないのかとか、普段ふと疑問に思うことに対して会計学的に解りやすく説明されていて面白い読み物だった。

まぁ新書であってもあまり食わず嫌いになることなく頭を柔らかくするつもりでこれからも気軽に読んでゆこうかと思う。

ブログをメモ用のデータベースとして使いやすいものにするべく
やはりカレンダーも月送りになった方が良いだろうとやり方を調べてみた。
MovableTypeにはその機能を備えているものの、ディフォルトのテンプレートでは使われていないらしい。
まずは、カレンダーの表示箇所を他を参考にしながら以下の通りに書き換えてみた。
併せて、アーカイブのテンプレートも2コラム形式に書き換えてカレンダーを表示させるようにしてみた。
ただしメインページからいらないと思われる項目は削っておく。
(カウント・最近の投稿・google検索)

<h2 class="module-header">カレンダー</h2>
<div class="module-content">
<div id="calendar">
<MTArchiveList archive_type="Monthly" lastn="1">
<table summary="投稿されたエントリーへのリンク付き月間カレンダー">

<caption>
<MTArchivePrevious>
<a href="<$MTArchiveLink$>" title="<$MTArchiveTitle$>">&laquo;&#160;</a>
</MTArchivePrevious>
<$MTArchiveTitle$>
<MTArchiveNext>
<a href="<$MTArchiveLink$>" title="<$MTArchiveTitle$>">&#160;&raquo;</a>
</MTArchiveNext>
</caption>

<tr>
<th abbr="日曜日">sun</th>
<th abbr="月曜日">mon</th>
<th abbr="火曜日">tue</th>
<th abbr="水曜日">wed</th>
<th abbr="木曜日">thu</th>
<th abbr="金曜日">fri</th>
<th abbr="土曜日">sat</th>
</tr>

<MTCalendar month="this">
<MTCalendarWeekHeader><tr></MTCalendarWeekHeader>
<td<MTCalendarIfToday> class="today"</MTCalendarIfToday>><MTCalendarIfEntries><MTEntries lastn="1"><a href="<$MTEntryPermalink$>"><$MTCalendarDay$></a></MTEntries></MTCalendarIfEntries><MTCalendarIfNoEntries><$MTCalendarDay$></MTCalendarIfNoEntries><MTCalendarIfBlank> </MTCalendarIfBlank></td><MTCalendarWeekFooter></tr></MTCalendarWeekFooter>
</MTCalendar>
</table>
</MTArchiveList>
</div>
</div>

う~んこうれだと前月の内容を表示させても今月のカレンダーを表示してしまうのね。
しょうがないので更にいじってみる。
幸い、月送りのカレンダーの設定方法が細かく書かれたサイトがあったのでそのまま引用させていただく。
引用: 小粋空間:月送りカレンダー

1.カレンダー用ディレクトリ設定
Movable Type、管理メニューの「設定」→「公開」の「アーカイブの設定」にチェックをいれ、その下に表示されたフォームに下記の内容を設定する。

アーカイブURL:http://ブログURL/archives/
アーカイブパス:アーカイブURLまでのパス

例えば当サイトであれば

アーカイブURL:
http://y-sky.net/blog/archives/
アーカイブパス:
/home/sites/lolipop.jp/users/lolipop.jp-dp08079804/web/blog/archives

という具合になる。

2.カレンダー用スタイルシート作成
管理メニューの「テンプレート」→「インデックス」→「テンプレートを新規作成」をクリック。
次画面で下記を設定する。
設定が終わったら「保存」をクリック。

テンプレートの名前:style-calendar
出力ファイル名:calendar.css
テンプレートの中身:下記

@charset "utf-8";

body {
margin: 0;
padding: 0;
font-family: Verdana, Arial, sans-serif;
}

.calendar {
color: #444444;
text-align: center;
}

.calendarhead {
font-size: 9px;
letter-spacing: .2em;
}

.calendar table {
padding: 0;
border-collapse: collapse;
}
.calendar th {
padding-top: 5px;
font-size:8px;
width : 20px ;
}

.calendar td {
padding: 2px 0;
font-size:10px;
line-height: 120%;
}

.today {
display: block;
border: 1px solid #444444;
}

.holiday {
color: #e50003;
}

.saturday {
color: #0000ff;
}

3.カレンダー用アーカイブテンプレート作成
管理メニューの「テンプレート」→「アーカイブ」→「テンプレートを新規作成」をクリック。
次画面で下記を設定する。
設定が終わったら「保存」をクリック。

テンプレートの名前:カレンダー
テンプレートの内容:下記(本日の日付部分がboldになるように記述)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0/ Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=<$MTPublishCharset$>" /><title><$MTBlogName$></title>
<link rel="stylesheet" href="<$MTBlogURL$>calendar.css" type="text/css" />
</head>
<body >
<div class="calendar">
<table summary="<$MTArchiveDate format="%Y/%m"$>">
<caption class="calendarhead">
<MTArchivePrevious>
<a href="<MTBlogURL>archives/calendar/<MTArchiveDate format="%Y/%m/index">.html"><</a>
</MTArchivePrevious>
<$MTArchiveDate format="%B %Y"$>
<MTArchiveNext>
<a href="<MTBlogURL>archives/calendar/<MTArchiveDate format="%Y/%m/index">.html">></a>
</MTArchiveNext>
</caption>
<tr>
<th abbr="Sunday" ><span class="holiday">Sun</span></th>
<th abbr="Monday" >Mon</th>
<th abbr="Tuesday" >Tue</th>
<th abbr="Wednesday" >Wed</th>
<th abbr="Thursday" >Thu</th>
<th abbr="Friday" >Fri</th>
<th abbr="Saturday" ><span class="saturday">Sat</span></th>
</tr>

<MTCalendar month="this">
<MTCalendarWeekHeader><tr></MTCalendarWeekHeader>
<td><MTCalendarIfBlank><MTElse><span<MTCalendarIfToday> class="today"</MTCalendarIfToday>></MTElse></MTCalendarIfBlank><MTCalendarIfEntries>
<MTEntries lastn="1">
<a href="<$MTEntryLink archive_type="Daily"$>" target="_top"><$MTCalendarDay$></a>
</MTEntries>
</MTCalendarIfEntries><MTCalendarIfNoEntries><$MTCalendarDay$></MTCalendarIfNoEntries><MTCalendarIfBlank>
<MTElse></span></MTElse></MTCalendarIfBlank></td><MTCalendarWeekFooter></tr></MTCalendarWeekFooter></MTCalendar>
</table>
</div>
</body>
</html>

4.ファイルの関連付け
予め、管理メニューの「設定」→「公開」の「アーカイブ・マッピング」の項目の右側にある「マッピングを新規作成 」をクリックして下記の設定を実施する。

アーカイブの種類:月別(またはMonthly)
テンプレート:カレンダー
設定後、「追加」をクリック。
正常に保存されると下の「月別」の欄にカレンダーテンプレートが追加される。
追加された部分の設定は下記の通り。

ラジオボタン:日付アーカイブ(またはDate-Based Archive)のまま出力フォーマット:下記

calendar/%y/%m/index.html

5.カレンダーの設置
「テンプレートの編集」 で各テンプレートのカレンダー表示用タグを削除し、下のタグと入れ替えてる。

<div align="center" class="side">
<iframe name="cal-iframe" src="<MTBlogURL>archives/calendar/<MTDate format="%Y/%m/index">.html" width="150" height="115" scrolling="NO" frameborder="0" marginwidth="0" marginheight="0">
</iframe>
</div>

6.サイトの再構築

自サーバにおけるMovable Typeの不具合を原因を切り分けたり調査していくうちに、XMLとCSSをだいぶいじくり回したおかげで、感覚として捉えることが出来るようになった。
こういうものは学習書とずっとにらめっこしているよりは、実際にいじって慣れてしまった方が身に付くようだ。

私の場合は習うより慣れろなのだろう。

要はデータベースのフィールドと属性設定なのだろうと割り切ることで理解することが出来た。
耳慣れない新語が沢山出てくるのでそれらに気を取られているとなかなか理解が進まないが、用途と働きから考えれば一気に理解は進む。

十数年前、会社の上司に「ネットとデータベースさえやってれば食うに困らない」という言葉が今更ながら思い出される。

XMLなどは技術的には理解できるのだが、それを制作して編集するツールについてはまだまだ改善の余地があるのだろう。
幸か不幸かデータベースはファイルイメーカーから入ったので、それに慣れてしまうと他のスタンスがやりにくく思えてしまう。
たぶんグラフィック系を主に扱うソフトメーカーがデータを扱うという慣れないオペレーションの仕様を決めているせいもあるだろう。
ファイルメーカー社などが本気でXMLを扱うツールを作ったとしたらもっと違ったものが出来ていたかもしれない。
もっともファイルイメーカーにしてみれば自社のDBエンジンを薦めたいのだろうから、オープンソース系のものに手を出すことは考えにくい。
とはいえ現状ではGUI時代にプロンプトに入力作業を求められるようなものなので、一貫してGUIで構築できるような使いやすいツールの出現が望まれる。

ここ数ヶ月、早寝早起きな生活を送っている。
夜中0:30~1:00には就寝するし、朝の5:30には目が覚めてしまう。
自然に時間が来れば眠くなり、時間とともに目が覚めてしまうといったもので特に意識しているわけではない。
まぁ年寄りになったって事なのだろうか?
意識することと言えば以前のエントリ「髀肉の嘆」で書いたとおり22時過ぎには食事を摂らないと言うことだけだろうか。
現実には19時に夕食を摂ってそれ以降は口にすることはないので20時以降は摂らないと言うことだろう。
反対に朝は起きてすぐにコーヒーを煎れて、1時間以内に朝食をしっかり摂る。

フリーで仕事をしていたので時間の割り振りが自己管理なのだが今まではどうも楽な方へと流れていたようだ。
せっかくフリーになったからと、渋滞の時間を避けるようにあえて一般とずらしていたところがあるが効率からいうと早寝早起きがよい。

フリーで仕事をしているから、夜に作業して生活リズムを崩してしまうのではなく、フリーだからこそ早朝に作業をして午前中に仕事を終わらせて、後は余裕を持って新しいことを学習に当てたりもできるというパラダイムの変換が必要だろう。
また、フリーだからこそ、余計な付き合いにも振り回されることがないのも有り難い。
勤め人時代でもそれほど付き合いの良かったわけではないのだけど、時々、夜遅くに飲みや食事に付き合ってリズムを崩すこともあった。
睡眠時間も以前より短くなったり、早朝から集中して仕事をしているので、さぞかし時間が余るだろうと思っていたが、実は以前よりも時間はない。
一日24時間という限られた時間から行うべきことに時間を割り振ってゆくとほとんど残らないのである。
なので優先順位の低いものを犠牲にするより仕方がない。

生活リズムを崩してダラダラ暮らしていた頃は実際にはプライオリティの高い事柄について、おざなりにしていたり、またはそもそもの存在そのものを忘れていたところがある。
それが年間を通してみてイマイチ進歩がないという事に繋がっているのだろう。
規則正しい生活を送るようになると、色々と現実的に行うべきことに気づかされる。
それにしても一日で達成できる進捗のなんと遅いことだろう。
だが、以前に一日に集中して詰め込んで行うことに比べて、日々着実に血肉になっているという実感がある。

早寝早起きは熱効率にも良い。
日光は有り難いことに無料である。
日の出とともに起きて働いて日が暮れたら休むというリズムは経済的にも喜ばしいだろう。

以前、渋谷に通勤していた頃、残業帰りの山手線の窓からに23時のスクランブル交差点のまるで昼間のような明るさと人の多さを実際に目にして改めて驚いた記憶がある。
「いったい、こんな夜中にあんなに多くの人たちが何をしているのだろう?」その時ながら疑問に思っていた。

便利な世の中になったものの、正月でも店が開いていたり、四季に関係なく色んな食べ物が手に入ったり、昼夜の違いがほとんどなくなったり、人間の自然なリズムを崩してはいまいか?

1977年のニューヨークでの29時間に及ぶ大停電で次の年の出生率が上がったという。
たいがいの娯楽は電力がないと出来ない。そんな中でやることと言えばだいたい決まってくるのだろう。
むしろ日本でも燈火規制でも行えば少子化対策と温暖化対策の問題が解決するのではなどとも考えてしまう。
それも現実味のない事なので要は一人一人の意識が大事なのだろう。

久しぶりのエントリーなのに、いきなりいかがわしいタイトルで申し訳ないがこれは私の日々の身体のメンテナンスの順序である。

この逆はあり得ない。
デスクワークが多いので肩の凝りはひどい。
そもそも何でこんなに石のように凝ってしまうかと原因を考えてみると一つは仕事で集中して同じ姿勢のまま長時間いることと、あともう一つは私の寝相の良さもあるだろう。

私の寝相はとても良い。
夜仰向けで胸の上で両手を組んで目を閉じた状態のまま次の朝に起きたときもまったく同じ姿勢のままである。
寸分も動いていないのでたぶん寝返りはまったく打たないのだろう。
もっとも誰もが寝てる間の自分のことは解らないのでなので、もしかしたら夜中にやおら起きてコサックダンスを踊りまくったあげく"無意識に"同じ姿勢で床に入っているかもしれない。
しかし過去に横に眠っていた人の多くの証言では、本当に動かないらしい。
疲れて熟睡しているときなどは呼吸していることすら疑われてしまって口に耳を近づけてようやく生存が確認されたというエピソードがあるくらいである。
つまりそれくらい深く文字通り「死んだように眠る」のである。
それだけならばまぁよいのだが、どちらかというと私は固い床に薄いマットを敷いてその上で眠ることを好むのでこれが背中や肩の凝りの一つの要因になっているのではないかと想像している。

以前知り合いのマッサージ技師に背中を見てもらったが肩胛骨が筋肉にくっついてこれじゃあ凝るだろうと言われたことがある。
なのでもっぱら肩胛骨を引き剥がしてスムーズに動くようにすることを薦められた。

我が家には「ケンシロウ1号」と名付けた10年来愛用している、?(クエッション)型の背中ツボ押し器具がある。
今だと100円ショップでプラスチック製の安価な物も出回っているのでそれでも十分だろう。
私の物は柄の部分が金属で絶妙なしなり具合があったり、ツボ押しの部分が鋭利な形と堅さで、値段に見合ったより好ましいツボ押し効果があると思っている。
強力なツボ押し効果はあるものの、凝りが酷いときには肩から背中にかけて石のように固くなるので「ケンシロウ」の突きが秘孔にまでは届かず、ハート様のように「効かんなぁ」という感じになってしまう。
そこで石のように固くなった筋肉に「ケンシロウ」の突きが秘孔に到達するように木槌で丹念に叩いて柔らかくするのである。
木槌は100円ショップで売っている堅い木で出来たT字型の(普通のハンマーが1型程度だがこれはまさしくT字型)もので、これは「イモキン」という愛称で呼んでる。
「イモキン」で秒速2フレで軽く叩いて血の巡りを良くして固くなった筋肉をほぐしてゆく。
まるで料理で固いすじ肉を叩いて柔らかくするような感覚である。
柔らかくほぐれたところで「ケンシロウ1号」で意識して肩胛骨と肉のツボを押して短時間で効率的なメンテナンスが可能になった。
なので順序は「叩いて、揉む」なのである。
眠っている間にメンテナンスされることが理想的なので、やはり理想の寝具マットを探す必要もありそうだ。

MovaleTypeに変更したものの、ロリポップ鯖のcgi実行力の弱さのためか、エントリ書き込み等のcgiプログラム実行時にエラーが返されることが多い。
最初はectoを疑ったが、ブラウザからのエントリ書き込みでもしばしば同様の現象が起こることから、MTの再インストールも試してみた。
再現性があったり無かったりなので、これはサーバのプログラム実行負荷に対する許容値が低い為だと判断した。
確かにやすいサーバなのだがこういうところに落とし穴があるのかもしれない。

MovaleTypeについては色々とカスタマイズしやすし、カテゴリや日付分けなどメモの整理としてはとても重宝しているのだが、こうも書き込みで頻繁にエラーが出るのでは精神衛生上よろしくない。
iBlogを使用していたときにはアップロードに時間はかかるが、確実に(ローカルでXMLに変換してからアップするので当たり前なのだが)投稿できていたので、不安定な土台にブログを書き込む気になれずとはいっても、原因を深く追求する時間も取れずにズルズル来てしまった。
いっそのことiBlogに戻そうかなどという気弱な考えがよぎったのだが、すでに「賽は投げられた」のである。
これだけ採用実績のあるブログシステムなのだから、あとは自分の環境に合わせた設定と使いこなしが大事なのだろうと機能拡張性も考慮に入れてこのままMovable Typeの問題解決に腰を据えてみた。

色々と問題を切り分けしてどうやらdb内のファイルに不具合が出やすいところまでは突き止めた。
なので、この際データベースエンジンをBerkeley DBでから、思い切ってSQLiteというデータベースに切り替えてみる。

1.MT3.2のdbの作り直し(とりあえず再構築が出来る壊れていない物)

2.「Ogawa::Memoranda」さんのmt-db-convert.cgiをダウンロード。

3.解凍後、編集なしでcgi/mtにアップロード。属性は700。

4.ブラウザで「自分のサイト名/cgi/mt/mt-db-convert.cgi」にアクセス

5.「Source DB Configuration」

DataSource=「サイトパス/cgi/mt/db」ObjectDriver=「Berkeley DB」

6.「Destination DB Configuration」

ObjectDriver=「SQLite」、database「サイトパス/cgi/mt/db/sqlite.db]

7.「convert」ボタンを押せば最後に

Your recommended setting
-------------------------------------
# DataSource サイトパス/cgi/mt/db
ObjectDriver DBI::sqlite
Database サイトパス/cgi/mt/db/sqlite.db
-------------------------------------

と表示される。
8.mt-config.cgi をエディタで開き

DataSource サイトパス/cgi/mt/db を

# DataSource サイトパス/cgi/mt/db
ObjectDriver DBI::sqlite
Database サイトパス/cgi/mt/db/sqlite.db に書き換えて、アップロードし再構築。

9.記事を更新した時にサイトパス/cgi/mt/db/sqlite.dbが更新されていれば成功

さっそく、Movable Type管理画面にログインして複数のエントリを選択して「再構築」をかけてみる。
まえのBerkeley DBではほぼ100%、500エラーが発生していたところである。
20くらいのエントリを再構築しても無事に処理が終わった。
ectoからの投稿・更新もスムーズに行えて、DBエンジンの堅牢性が上がった印象である。
まぁ当たり前と言えば当たり前の状態になっただけのことだけど、今までが酷すぎたために素直に嬉しかった。

まずはめでたしめでたしである。
これで土台に不信感を懐かずに安心して日々のエントリの更新が出来るようになった。
アップしないまでも書き留めていたエントリも少しづつ(公開を意識した文体に書き直す必要があるため)アップしてゆこうと思う。

遅ればせながら話題の新書、『ウェブ進化論』梅田望夫著(ちくま新書)を読んだ。
面白く興味深い内容だったので3時間くらいで一気に読み上げてしまった。

ここ1年くらいウェブに対して何となく動きは判るものの、実情についてうやむやになっていたところが、この本では明快に提示されていておかげでスッキリ氷解した。

Googleに関しては良質の検索エンジンを提供して広告で稼いでいる会社くらいにしか思っていなかったが、
(例の100ドルPCで世界戦略の一部を垣間見た程度だけれども)その凄さについては正直言って知らなかった。
Googleは、目に見える製品、手で触れる製品を作っていない。
ネットの世界を深く経験したことのない人には、その実体を想像することすら難しい会社なのである。
本書ではその難しいさの説明を以下の要点で表していた。

(1) 「世界中の情報を整理し尽くす」というGoogleの構想の大きさと、Googleという会社の個性。


(2) この大きな構想を実現するために、情報発電所とも言うべき巨大システムをネットの「あちら側」に構築してしまったこと。


(3) その巨大システムを、チープ革命の意味を徹底追及した全く新しい作り方で自製し、圧倒的な低コスト構造を実現したこと。


(4) 検索連動広告「アドワーズ」事業に加え、低コスト構造のインフラが存在して初めて可能となる秀逸な「アドセンス」事業を構想・実装し、大変な収益を上げていること。
「知の世界の秩序の再編成」に「富の再配分」のメカニズムまで埋め込んだ凄さについて。


(5) 20世紀までのどんな会社もやったことのないようなやり方で、社内の組織マネジメントに新しい思想を導入し実践していること。


(6) 既に存在する多くのネット企業のどの会社とも全く似ていないこと。

本書で根幹を成すキーワードの一つに「ネットのあちら側とこちら側」があるであろう。
そういう切り分けで言うと、私などはまだまだ「ネットのこちら側」にこだわっているように思う。
Webメールサービスなどをわだかまりなく使用できる友人は「ネットのあちら側」よりにあるといえて、より進歩的な感覚を持っていたと言えるだろう。
私も少し反省したのでブログなどの情報のオープン化、共有化を進めてゆこうかと思う。
ただセキュリティはしっかりと設定して望みたい。
とはいえ、私の今までのネットへのスタンスは危険回避の観点から長らく排他的で鎖国状態であったのですぐにフレンドリーな状態になるとは思えないが、(内向的な人がある日を境に外向的になることが難しいのと同様)この本を読んでパラダイムの変化が認められたのでこれを軸に徐々にシフトしてゆくことになるだろう。