ぶろゲ

自分にはプログラムは書けないと遠い昔に思っていたが、稚拙ながらなんとか書けるようになった。そう思わせてくれたのはJavaだったが、今ではRuby言語やAS3言語たちと遊んだりしている。

MVCとの出会い

そうしたアプリケーションの楽な作り方があったら知りたい、という気持ちがあった。基本的に、これらの言語で何を作ろうとしても、作法はあるのではないか。そうして出会ったのはMVCという概念だった。MVCについて学ぶ必然性を与えてくれたのがRuby on Railsで、より積極的に学んだのはPureMVCやrobotlegsというMVCフレームワークだった。

MVCというのは、GUI（グラフィカルアプリケーション）の制作において、有用な形だ。これを使うことで、複雑なアプリケーションのスパゲッティが、少しは食べられるものになる。

だけれども、MVCのことを知らないで、ほかの人が作ったMVCアプリケーションのソースコードを見たときは、スパゲッティ以上に意味の分からない何かに見えた。経験的には、MVC適用を厳格にしなかったプログラムをMVCに書き換えた際には意味が分からなくなった、という意見をもらったことがある（大方、書き方が悪いのだろうけれども）。概念を知っていないとMVCフレームワークの読み込みは非常につらいものになるのかもしれない。

MVCの概念

MVCは、ものすごく単純には、プログラムのソースコードの中のディレクトリを3つに分けましょう、ということだ。その3つとは、View(見えるもの)、Model（データ）、Controller（操作するもの）のこと。WPFで言うところのXAMLやJAVAのswing、FlexのMXMLにあたる部分はViewに入る。それ以外のロジックはそれぞれModel,Controllerに入る、という感じだ。

まず始めにMVC的にプログラムを書くぞー、というときにはこんな風に適当に分けた。こうして分けようとすると、ModelとViewはなんとなく分かるけれどControllerとは何ぞ？ロジック書けばいいの？という気分になっていく。

MとVとCの関係

ユーザの操作の流れからすると、MVC内ではこんな風な流れ作業になる。

ユーザからの操作をControllerが受信する。ControllerはModelを叩いて値を変更する。Modelの値の変化をViewは監視していて、変化したことを察知したのでViewの値を変更する。

この図を見ていると、「ユーザーの操作が直接Controllerに入るのはおかしいじゃないか。だって、ユーザーの操作はビュー上の部品から行われるだろ？」という気分に襲われなかっただろうか。「いや、ジョイパッドのときはビュー関係ないだろ？」という意見もあるかもしれない。

View上の部品に対してユーザーが何かをした場合は、その部品からControllerにこっそりユーザーが何かした、ということを教える。その方がコードが分かりやすい。また、モデルの値が変化したときにも、Viewに対して”変化した”ということを教えなければなるまい。

つまり、このようなこっそり教える関係性がある。実はこれがイベント駆動とかイベントドリブンだとか、GUIアプリケーションの一番初めにぶつかる概念のイベントの伝播だったりする。

Modelの値の変化は必ずしもControllerが始点ではなくてもよくて、例えばTimerだったり、他のサービスへのPollingだったりが、そうしたものだ。そのために、Modelの変更をViewが見守るという関係であったりする。

MとVとCの関係度

で、コードを書くときに気になるのは、コードの使いまわし（GUIをCUIにしろ）だとか、コードの保守性（簡単に見通せて変更ができるか）だったりするのだが、一般にMVCは以下のような依存を持つとされている。

Controllerを変更してもViewとModelは大丈夫。Viewを変更したら、Controllerを変更しなければならないかもしれない。Modelを変更したらControllerとViewの両方を変更しなければならないかもしれない。そんな感じ。

特に大変なのは、Modelを交換したときで、ControllerとViewの2つの面倒を見なければならない。だから、Modelは最初にがっちりさせておく。まさに太らせる。Fat Model。Controllerを太らせてはいけない。Controllerは基本、使い捨てだから。

で、どんなViewを作ろうとしても、Modelの値の引き方というものはModel固有のものになってしまうので、ModelごとにViewを作り込むという結果になってしまう。依存度高し。

このViewのModelへの依存度を減らそうという考え方がある。

いつか書けるといいなリスト

・依存度を減らそうという考え方の話
・カチコチなMVCって何なのさ的な話
・規約なMVCってどんな感じな話

iPadやKindleなどの電子書籍端末が話題になっている。特にiPadでは様々な雑誌の体験版のような切れ端が配信されている。しかし、書籍まるごとが販売されていることは少ない。日本向けのiBooksで書籍は微妙で、書籍アプリを買って楽しむことになるが数が少ない。日本における様々な本の電子化は未だ、不十分だ。

そのため、自前で電子書籍化する必要がある。だが持っている本のスキャンをするには、費用がかかる。スキャナーの購入、裁断機の購入、そしてスキャンするための人件費（or 時間）。これを解決するのが スキャン代行サービス だ。

BOOK SCAN がすごい

中でもBOOKSCANというスキャン代行サービスが注目を集めている。1冊100円の安価さ、Amazonから本を直送できる手軽さ、Paypalを支払いに利用出来る、そしてPDF化して届けてくれる。スキャン代行サービスとして、これ以上ない充実した内容を持っている。

しかしながら、問題も抱えている。少し前に、「日本雑誌協会が雑誌スキャン販売会社に著作権違反の警告」をした事実は記憶に新しい。また「著作権の間接侵害の判例マップの例」で例示した録画ネットから選撮見録に到るまでの一連の裁判も、著作権の私的な複製に当たるかどうかの、そして複製の主体は誰であるかの戦いである。

著作権法的にはアウトではないのか

過去の例から鑑みるに、スキャン代行サービスによる一般書籍のスキャン代行は、「使用する者が複製することができる」とあるものではないため、私的な複製には当たらないと考えられる。サービスも価格も非常に良いため残念だが、現行の法律ではしようがない。

ただし、サービスのWebページの「著作権について」ページには、

BOOKSCANのPDF書籍変換システムへご依頼頂いたものは、著作権法に基づき、権利者の許可が必要です。許可がないものは、ご遠慮頂くか、ご自身でスキャンしてください。

と、注意書きがなされている。これは殊勝な心がけだ、どう見ても一般の書籍で権利者の許可が確認できなければスキャンしないに違いないだろう、と思い、ブログ検索を試みたところ、100冊超の書籍のPDF化に成功したとの戦果報告を見つけてしまい、萎えた。受け取った動画は全て権利者の許可を得ているとみなすYoutube方式を採用しているのだろう。ということは、権利者は自身の管理する著作物の無断複製の差し止め請求することは可能だ。

本のストリーミングという考え

そこで、著作権的に問題のないサービスはどのようなものだろうか、と思考してみた。ヒントは複製しないこと、つまり、PDFのダウンロードではなく、書籍のリアルタイムストリーミングであれば、複製には当たらない、という考え方だ。

かつて、動画のダウンロードとストリーミングにおいて、ダウンロード違法化（著作権法の改正）が2010年1月から言われているが、Youtubeなどのストリーミングは複製を行っていないとみなしている。それにより、情を知った（それが合法なコンテンツではない）としても問題はない、という形になっている。

今回のスキャン代行サービスの場合、PDF化という複製を行っていることが問題であって、かつてのテレビ配信サービスが通った道のように、リアルタイム配信という逃げ道を用意することは可能ではないか。裁断した本を用意して、CDディスクチェンジャーならぬ、BOOKチェンジャーが存在して、読みたい本を引き出し、自分だけに配信してくれる。

見た瞬間にデータが消えていけば複製ではない。自動公衆送信権と送信可能化権を侵害しなければ、問題はない。自分の本を自分だけが見られるような状態であれば、自動公衆送信権の侵害ではないだろうと考える。だが、この仕組ではインターネットに接続していなければ、自分の本を見ることができない。

しかしどう考えてみても、BOOKチェンジャーの仕組みが無理。考えるだけムダではなかろうか。むしろ、CDチェンジャーの方がずいぶんと楽そうだ。結局のところ、BOOKSCANのサービスで裁断してもらった書籍を送ってもらって自分でスキャンする方が早いのでは？という結論に至る。引き続き本のストリーミングでうまい方法はないか、考えていきたい。

他人の体重の話ほど面白くないものはない。ましてや自分の体重の話ほど気色悪いものはない。それでもGoogleDocsを使ったダイエット方法の話をまとめることに少し意義を感じたので、体重計を買ってからの１ヶ月あまりの体験を書いてみようと思う。

「疲れやすいのは体重が増えたせいではないのか？」

常々体重を減らしてみたいと思っていた。それはまったく運動というものをしない、散歩すらしない運動嫌いという性格があり叶わなかった。減らしたいという願望は、疲れ易いという経験からきていた。数km歩いただけで足がだるくなるのは異常だと感じていた。疲れない足が欲しかった。

ついカッとなって体重計を買ってしまった。50g単位で測定できる体重計だ。50g単位で測定できる体重計はNHKの番組「ためしてガッテン」の「計るだけダイエット」の回で推奨されていた。覚えているのは計るだけでダイエットができる、という点だった。ふとした話題でAmazonで体重計を検索してみたところ、手頃な値段で購入できることが分かり踏み切った。

体重計で計ってから、疲れやすくなったように感じるのは体重が増えたせいではないのか、という仮説が自分のなかで生まれた。というのも測定された数値が自分が想像していた値よりも+8kgだったからだ。信じられなかった。いや、過去に+4kg増で驚いた記憶があるような。そういえば最近は菓子をバリボリ食うことが習慣化されている。

そのような感じで体重に敵意を持つようになった。だけれども、この時点で減量を行う気持ちは強くなかった。上手くいかなかったらどうしようか、という自分を守る気持ちが強かった。というのも昨年にスローステップ運動という数十分の運動を行っていたが途中で辞めてしまったからだ。

GoogleDocsが思ったよりも使えることに気がついた

体重測定環境の準備を粛々と進める。減量そのものには強い希望はなかったが、測定・分析の環境の構築は大好物という勢いで色々考えてみたり、使ってみたりを初めていた。思考実践の結果、３つのポイントを上手く抑えることで測定美を実現できるという結論に至った。

• 測定を忘れないための準備として、よく通る場所に体重計を置くこと
• 分析を忘れないための準備として、GoogleDocsスプレッドシートのフォームとグラフ化を用いること
• 測定を楽しむための準備として、インターネットの検索でよく調べること

その気はないのに、なぜか準備は着々と進んでいた。

測定を忘れないための準備として、よく通る場所に体重計を置くこと

部屋のすぐ近くの廊下に置くことにした。

自分は習慣付けできない性格であることはよく分かっている。そして忘れっぽい。忘れないためには通り道、じゃまになるように体重計が設置されているレベルじゃないとまず無理だ。それに、普段座っていてもよく見える位置でなければ、夜に測定することを忘れる。部屋の中にあっては、いけない。ふと寝ようと歩いていると、そこに体重計があるのが、驚きがあって良い。

分析を忘れないための準備として、GoogleDocsスプレッドシートのフォームとグラフ化を用いること

OpenOfficeCalc(Excel)と比べてGoogleDocsスプレッドシートを利用することに決めた。

測定したデータは加工しやすいデジタルデータで管理したい気持ちがあった。紙では数カ月を通しての測定結果を出すことが難しいからだ。どうしても数カ月の測定のグラフが見たかった。また紙のグラフの場合には見やすい場所に貼る方が良いのだが、デジタルデータでもどの端末からでも見やすいことを条件とした。

１つの検討としてOpenOfficeCalcはどうなのか考えた。強力なグラフ描画、豊富な関数機能は魅力的に思えたが、OpenOffice全体に特有の起動するまでに時間がかかる点が気に入らなかった。この時間だけで、測定しようという心が折れる可能性が高い。また全てのPCにインストールが必要で、Calcドキュメントをネットワークを使って共有するなんてことは上手い手法とは思えなかった。

そこでWeb上で記入できるGoogleDocsスプレッドシートはどうなのか、と検討を始めた。懸念だった起動時間はブラウザのみだから、Calｃほど酷くはない。しかもブラウザだけあれば閲覧できるので、他のPCにインストールする手間もない。管理の厳しいPCでも見ることができるし、データの送受信も簡単だ。これに加えてフォーム機能がとても素晴らしいということに気づけたことは予想外だった。

フォーム機能が予想外に使えた

GoogleDocsスプレッドシートへの記入でさえ”最終行セルへの移動と記入”という厄介な作業で気が滅入りそうだった。が、フォーム機能では”あなたの体重いくつですか？”の簡単な問いに答えるだけのアンケートを作ることが出来た。ときにはそのアンケートにiPadのブラウザから記入している。

というのも、Calcの起動以前にPCの起動そのものがストレスとなっていた。自分の持っているPCはどれも夜間はスリープ（メモリ内容をハードディスクに退避して電源が切れる）機能を使っている。この仕組を使っていても、(1)30秒程度の待ち時間(2)ログインパスワードの入力時間(3)ブラウザ起動…とかったるい作業が必要だった。

ところがiPadを使ったフォーム入力に必要な時間は、PCがスリープから復帰する時間の間に終わらせることができるほど短時間だった。この出来事が測定のその後に時間がかかるという意識を消した。このGoogleDocsスプレッドシートのフォーム機能は簡単なHTMLで構成されており、携帯電話やポータブルゲーム機であるPSPでも入力できることを確認した。

測定を楽しむための準備として、インターネットの検索でよく調べること

測定を楽しむためにGoogleDocsスプレッドシートで様々なグラフ作成を楽しんだ。例えば、測定ごとの差分をグラフ化したり、朝・夜のみグラフを作成したりだ。グラフが動かないのは楽しくないので、無理のない範囲で1日に3回の測定を行うことにした。

忘れていた計るだけダイエットの基礎について調べなおした。おさらいとしては以下の通りだ。

• 一気に体重を減らすと食欲を抑えるホルモン「レプチン」が急激に減って食欲が抑えられなくなる
• 1日50〜100g減らして1週間で500g減を目指す（急激には体重を減らさないように気をつける）
• 1日50g減ったかどうかを知るためには50g単位の体重計が必要
• グラム単位の変化を見逃さないためには同じ服を来て測定する
• グラフを描き、グラフを分析すると出る快楽物質で食べることによって出る快楽物質を代替する
• 腹が減ったら運動

また暑い時に出る汗と運動したときに出る汗とは違う、という話も面白い。

測り続けていたら減ったのでその気になった

ここまで準備をやってきてもその気にならなかった。単に測定を続けていた。1週間ほどたった頃、何もしなくても体重が減っていくという誘惑に惹かれていった。

「整いました！」という声が聞こえたかどうかは分からないが、”道具が整った”、”理由が整った”、そして”時期が整った”というイメージを持った。いつ減量を始めた、という明確な気持ちがないまま、なし崩し的に減量が始まっていた。それに呼応するように運動も始めていった。

食事は減らさず、運動はちゃんと行う

個人的に減量の理念として、

• 食事は減らさない
• 減量を始めたら運動はきちんとする

という２点を守りたいという気持ちがあった。

食事は減らさない

通常の量の食事を減らすと、もうそれだけでストレスなので減らさないことにした。食事の減量を意識せずに測り続けていただけで減ったのだから、問題はないはずだ、という解答を持っていたからだ。ただし、ときどき調子にのって食べる過ぎることがあるので、これはやめるようにした。

菓子も食べたいときは今まで通り食べるようにしてみた。そうして初めて、お腹が減っていないのに惰性で買ってあった菓子を食っていた、という事実に気づいた。その後、食べないように気をつけてみると、ハングリー精神が戻ってきたようだった。

炭酸飲料・スポーツ飲料は飲み過ぎに注意をする。飲むならお茶、とくにカフェインの入っていない麦茶の量産体制を構築することで対処した。

減量を始めたら運動はきちんとする

食べない減量の場合、運動をしなければ筋力が衰えてますます疲れそうだ。逆に食べる減量の場合、落とすためには運動が必要だ。筋力低下は避けたいので後者の方がいい。

前回断念したスローステップ運動を再開することにした。足の運動で、足が疲れなくなることに期待しているからだ。また減量のためには無酸素運動よりも有酸素運動に持ち込みたい。有酸素運動は数十分続けなければ意味が無いので、目標設定を30分に設定した。ただし厳密ではなく20分を超えたらよいくらいのゆるい感じで行っている。この運動は漫画や本を読みながら・テレビを見ながら・ゲームをやりながら行える点もよい。

約5週間続けた結果は3kg減

1週間で600gずつ減っていった計算になる。これは少し減りすぎだが、問題はなくいい感じだ。ただ個人的には夏の典型的な食細りによる夏痩せの可能性が高いとして観測を続けている。

それ以上に測定を１ヶ月続けられたことが嬉しい。記録・日記を毎日つけるような習慣付けは失敗が多かったが、測定は上手く行っているようだ。これはGoogleDocsで上手く環境を作れているからかもしれない。

足が疲れにくくなった実感は感じられない。というよりも、足がプルプルしている。貧乏揺すりではなく、筋肉痛だ。筋肉痛は超回復の作用で筋肉を作っている状態なので、ある程度の許容と快感がある。

測定を続けていくと、体重の推移が理解出来ない時があるが、焦らない方がよい。急に1kg増えたり1kg減ったりするときがある。原因は水を沢山飲んだとき、その水が抜けていったときのような気がしているが、未だに確信はしていない。仮説の状態なので、水をたくさん飲んだ日は言い訳欄に、水を飲んだ旨を書くようにしている。

参考になる人がいれば幸い

と、始めてまだ１ヶ月しか経過していないが、体験記としてまとめた。自慢にはなるレベルではないが、参考になる人がいるかもしれないと考えたからだ。

この画期的なダイエット手法を現代のデジタルを上手く活用して行うにはどうしたらよいのか、という思案が出発点だった。「ためしてガッテン」での「計るだけダイエット」の初出は2003年だそうで、この間、いかにexcelやその他を使ってどうにかしようと思っていたらしいが、結局はGoogleDocsに落ちついた。いかに測定後の入力を短時間で出来るのか、そして閲覧時のグラフ作成を簡単に行えるのかが鍵だった。

ある本のAmazonレビューに薦められていて、ロジカルシンキングにも興味があったので、買った本。「考える技術・書く技術」。
中身を見ないで、初めてレビュー買いをしてみた。また、Amazonの1-Click(TM)を初めて使ってみた。悪くはないが、金銭感覚が狂うので精神的にはあまりよくない。

肝心の本については、まだ読んでいない。買ったときには気づかなかったがAmazonのビジネス文書の分野の1位の本だそうな。そう悪くはない本なのだろう。

心配なのは、当方に、この本を読むための十分な「読む技術」「理解する技術」があるかどうかだ。どうも最近、文章を読む力が弱いのではないか、と思い始めている。もう一度、読む聞く、理解する考える、話す書く、あたりの所作について考え直したい。

LED電球が点灯しなくなった。SHARP DL-L601N。二口ソケットで2つのLED電球を半年ほど利用していたところ、片方の電球が時々点滅するようになった。室内灯で点滅されると勝手が悪いので、その電球を廊下で利用するようにしていたが昨夜ついには点灯しなくなった。

LED電球の画像を見ると分かるが電球上部には放熱板がついている。既存の照明器具ではLED電球は廃熱に無理があるという意見も見る。推奨環境温度についても5度〜35度とされている。この点から”二口ソケット”で2つのLED電球を利用したときの廃熱が問題だったのではないか、と考えている。

LED電球を室内灯として利用するには物足りなさを感じた。ラピッドスタート蛍光灯40w2本の代わりに設置したからかもしれない。LED電球は直下がより明るくなる特性を持つからだ。しかし廊下の電灯用としては良いものだった。電球形蛍光灯はゆっくり明るくなるのだが、LED電球はすぐに明るくなる。

先日購入した体重計を廊下に置いてあるのだが、デジタル表示部に照明機能がなく夜間の数字読み取りが困難だった。そこで廊下灯としてLED電球を利用してみたところ、すぐに明るくなる・直下が明るくなる性質によって数字が読み取り易く、使いやすさを感じた。今も点灯する方のLED電球を廊下灯として使っている。

二口ソケットが悪いのかどうか確証はないのだが、場合によっては点灯しなくなるケースがあるということが分かった。特に廃熱には注意する必要がありそうだ。普通の電球に比べて高価な製品で高寿命という呼び声が高かったから、今回の件はショックだった。いい体験になった。

とはいえ、普通の使い方では高寿命だろうし、省電力・すぐ明るくなる・直下が明るいという特性は玄関灯・廊下灯・トイレ・風呂・洗面所あたりの利用であれば十分使えるものだろうと現時点では考えている。

VMware Playerによって仮想化ツールが無償化したあたりから、仮想化ツールを使い始めた。それまではcygwinやcolinuxによる仮想化による作業を行うことが多かったが、cygwinはカーネル仮想化ではない点、colinuxではLinuxカーネルに独自のモジュールを組み込んだ状態でビルドしなければならない点において不便をこうむることが多かった。その点、VMware Playerは、当時は既存の仮想環境しか利用できず仮想環境の作成（ディスクイメージの作成）は行えなかったが、その点は様々なツールの組み合わせで解決でき、非常に便利に使わせてもらった。

続けてVMware Serverが無償公開したので、Ubuntu Linuxに移行して楽しんでいたが、設定は難しく、またVMware Server 2になってからはWebインターフェース（Tomcat）が固まるなど、不便さを感じることが多かった。またVMware製品を利用するためにはユーザーアカウントの登録が必要だが、そのあたりも面倒で、簡単に人に薦められるものではなかった。

ふとしたことで、VirtualBoxがかなり使えるという情報を得たので利用してみたが、非常に良い。良いのは、VMwareのようにユーザー登録しなくて良い点、WMwareと共通のディスクイメージを利用できる点、VMwareと同様に設定項目が豊富な点、VMwareのように面倒なカスタマイズが必要ない点、などだ。これなら仮想化環境の初心者にも進められる。また昨今の仮想化環境の利用に必須なVT-xにも対応している。途中のディスクイメージに戻すことができるスナップショット機能も含まれている。

早速、Chrome OSとAndroid-x86のディスクイメージをダウンロードしてみた。Chrome OSは起動・動作ともに問題なかった。Android-x86は起動することはできたが、イーサネットドライバが見つからず、ブラウザを利用することはできなかった。Windows環境については、WMwareのようにクライアント側にインストールする補助ソフトがありシームレスに画面を移動できる、また利用していないので分からないが、クライアント側でDirect2DやDirect3Dの利用もできる。公式サイトの情報によると、Mac OS Xの仮想化も可能らしい。

VMware ServerのようにWebインターフェースは提供されていないが、コンソールから操作する分には問題ないだろう。

名前にOracleがついている時点で今後も無償で提供されるのか、オープンソース版も継続して提供されていくのかが少し不安だが、現時点において非常に優れた製品だと感じている。

ふと、放置していたノートPCを触ると、熱を持っていた。開きっぱなしのブラウザで処理を食っていたのだろうか。ブラウザを閉じると落ち着いていった。

今回はバッテリーではなくACアダプタを接続していたので問題は無かったが、バッテリー駆動で知らない間に電力を多く使うような場面があったら困るな、と思った。

この問題で思い出すのは、iOS製品におけるFlashの電力食い問題であり、ノートPCにおけるブラウジングにおいてもFlashをOFFにすることで、多少の駆動時間を稼げるのだろうという発想が出る。おそらくは、Flash以外の他のプログラムにおいても、電力を無駄に食うようなものがあるのだろう。

そういったものを明らかにしていくには、どのプログラムがどれほどの処理を行ったのかのロギングが必要になる。そうして調べることで、そのプログラムがバッテリー駆動時には動作しないようにする、などの対策を行うことができるはずだ。

という妄想。