つれづれ
その337
マジコン対策法は、プラットフォームの提供者が独自にキマリ（法律みたいなの）を好きにつくれる権利を、法律が保証しちゃうというモノなんだなー、と、ふと思ったり。「企業が条例作れる権利をあげちゃいますよ法（自治区はプラットホーム）」みたいな。
フラットフォームホルダの胸先三寸でどんな理不尽なキマリも作れてしまって、それはいいのですが、それに対し「こんな勝手なキマリ、あんまりだ！」と思っても、破れば今度は国に捕まっちゃう。なにが酷いって、法律には民意が反映するけれどこの「キマリ」は反映しないところかな。なのに「キマリ」に強制力を法律が保証しちゃうというのはさすがにマズくない？と思えます。
だから、マジコンが悪いのではなくって、マジコンで動くようになるソフトの中に著作権法とかを破っているもの（違法コピー）があるからまずい という風にしなくては。でも既に「違法コピー」と読んでいるくらいだから、新しい法律を造るまでもなく今でも違法。うーん、なら、単純に、今、違法コピーしているひとを逮捕すればいいんじゃないかなって思います。
「焼け石に水」といわれるかもですが、たとえば、今小学校にいけばマジコンで違法コピーを遊んでいるお子さんなんて、いっぱい見つかる。それを片っ端から「警察が」補導しちゃうなんてどうかな？とおもう。保護者呼び出して一緒に警察が厳重注意とか（場合によっては保護者を逮捕できるのかしら）。今の違法コピーonマジコン三昧なのは「赤信号みんなでわたれば怖くない」心理なので、それだけで見せしめ効果バツグンだと思うのだけれど。
子供に「悪いこと」という認識を持って貰わないと。そのためには親にその認識をもたせないと。だとしたらこんな方法がいいんじゃないかな、と思います。
素人考えなので、浅はかな意見なのかも。
その338
このレンズは約等倍（1:1.1)までの拡大撮影が可能だが、撮像素子の小さなマイクロフォーサーズ規格のカメラに装着すると、ライカ判換算約2倍相当までの撮影ができる。
切り貼りデジカメ実験室：DMC-GF1で世界初のマクロレンズ「マクロキラー40mm」を試す - デジカメ Watch Watch
撮影倍率とは、実物とフィルム（イメージャ）上の像のサイズの比だから、マイクロフォーサーズだろうとAPS-Cだろうと、1:1.1 は 1:1.1 のまま。35mm換算倍率ってのは絶対おかしくって、フィルムだってユーザの過半数はプリントして楽しんでいたのだから。（プリント上では等倍以上あったのに、あのころから「等倍」っていってた）
と、我ながらマニアにありがちなツッコミをしてしまったあとで思ったのですけれど、像面の倍率なんてもういよいよわけわからなくなってきたな、というのはありますよね。
フィルムカメラの裏蓋をカパッと開けて、そこにトレーシングペーパーを置けば像の大きさがわかります（うわっ、ちっちゃーい、と実感できて感動なので一度やっておくことをオススメ）。そこまで凝らなくても、普通にネガをみれば像の大きさは実感できるのですけれど、デジタルカメラで像の大きさを実感する手段って、そういえばちょっと思いつきません。
人は抽象度があがるほど、無理矢理にも仮想的な基準に換算して具象化したがるのかな？ だから 「35mm換算病」が蔓延してるのかな？などなど、そんなことを思ってしまったり。
（うーん、抽象化云々に繋げるあたりは、ちょっと無理筋かな？）
その340
apt-get moo は知っていたけれど
$ apt-get moo
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...これはしらなかったです。
$ aptitude moo
このプログラムにはイースターエッグ (隠し機能) はありません。
$ aptitude -v moo
このプログラムには本当にイースター・エッグはありませんよ。
$ aptitude -vv moo
このプログラムにイースターエッグはないって言わなかったかい?
$ aptitude -vvv moo
やめてくれ!
$ aptitude -vvvv moo
わかった、わかった。あんたにイースターエッグをあげればどっか行ってくれるかい?
$ aptitude -vvvvv moo
わかったよ。あんたの勝ちだ。
/----\
-------/ \
/ \
/ |
-----------------/ --------\
----------------------------------------------
$ aptitude -vvvvvv moo
これが何なのか? もちろんウワバミに食べられた象だよ。・・ネタがわからない。なんでしょう？ウワバミって。
その341
わたしがトレイトを初めて知ったのが、Matzにっきとそこで紹介された論文なのだけれど、ぶっちゃけ、トレイトに感じる疑問は
ただ、traitは「a first-class collection of named methods」であり、 そのinclude(論文中ではuses:)は、そのtraitが(現時点で)持つメソッド集合を使うイメージのようだ。 Rubyのincludeはinheritと同様、 シンボリックな関係*2を維持している。
Matzにっき(2004-01-26)
で、しばらく考えるにRubyのようなOpenなクラス/モジュールを持つ動的言語では、 TraitsよりもMix-inの方が適しているという結論に達した。
しかし、Traitsの演算は魅力だ。Moduleへ演算を追加することで、 Mix-inのまま、Traitsの利点を導入することは理論的には可能のような気がするが、 普通に実装すると実行効率が下がりそうな気がする。
Matzにっき(2004-12-07)
でみたいな感じ。加えるなら Smalltalk だとその生命感を損なってしまいそうという不安も感じます。どちらにせよ、6年遅れを今追体験しているわたし。
責務を担う振る舞いのひとかたまりに抽象を与えることも、それを再利用の単位として継承木から独立することも、Traits の演算も素晴らしいとおもうのだけれど、実行時チェーンではなく、静的に事前にメソッドをクラス内に展開することのメリットがイマイチ、いや全然解っていません。デメリットはいっぱい浮かんじゃう*1。
実装上の都合と言われれば「そうなんだー」でスッキリだったのですが（というか、そう思ってた）、トレイトの原典になる論文（イントロ訳を載せた奴）を読んでたら「フラッティングは解りやすさのため」みたいなふうにも書かれてい（るようにみえ）て、しかもしつこくMix-in と比較している（ふうに読める）。で、だんだん、うにゃ？なんだかよくわからなくなってきたぞ？？みたいな。
日記をみると もやってきたのは 7月末 くらい みたい。
具体的にクラスが提供する機能はこんなんかな？
- メソッドのホルダー（コレクション）
- インスタンス→クラスへのメソッド委譲
- これらメソッドからのシームレスなインスタンスフィールドへのアクセス
- メソッドコールのさらなるチェーン。instance→class→superclass
- インスタンス生成インターフェイス（クラスメソッド or 特別な言語構文)
Traits は 1,2 あるいは 1 しかフォローしない。というかTrait は メソッドのコレクションそのもの。
で、よくわかんないのが Traits が、なんで reuse の為の最良の仕組みになるか。
Mix-in モジュールが クラスと同じレベルのちょっと違う仲間だとしたら、Trait はクラスの腑のように感じます。
いまのところわたしはTraitsに、クラスの腑をカパッと開いて、取り出したり、継ぎ合わせたりする外科手術を可能にしたような印象を受けてます。それって美味しいのかな？
いろいろ - みねこあ
こっちのモヤモヤレポートの方がまだスッキリまとまってるなぁ。てことは刻と共にどんどんメダパニが進行してってるということですか...orz
その342
ネガキャンばかりではアレなので妄想を大風呂敷。以下与太話です。
トレイトは、責務、あるいは役割(Role) に対する デフォルトの実装。振る舞いの組。今のところ メソッドのセットで表現されるけれど、将来もそう表現するかは不透明・・・というか「ステイトレスは不便」という方向になってきてるので、違ってくると思います。
トレイトを導入した場合、
- クラス→メソッド
から、
- クラス→トレイト→メソッド
という構造で表現するようになります。
これは OOP (というかOOAD)的には自然な構造だと思います。メソッドではなく、責務やロールという粒度の荒いものをクラスに与えて設計をこねこねするのは OOADで よくやる方法だからです。またこの単位は再利用を促進します。おなじみの生物比喩でいえば、体制（内部構造） が性質を決めるのではなく、環境（外界）が求めるものが性質を決めるからです（i.e, 収斂進化）。生物に喩えるのはよくないですけどね。しばしば Interface が細いことになってくるのはこのおかげ。
で、ここからがトレイトの怖いところですが、「再利用」とか「多重継承の問題」という文脈で扱うと、なんとなく Mix-in とか (Javaの) Interface と同列のモノのように語ってしまうけれど、違うよ、ぜんぜん違うよ！なのですよね。トレイトは、多重継承とかMix-in とかそんなチャチなもんじゃ断じてねえ。もっと恐ろしい物の片鱗を味わった気がするぜっ！
* * *
Simula がブロック（≒サブルーチン）の改良の過程で オブジェクトとクラスを発見したとき、それを「階層的プログラミング構造」と紐付けました。クラス/オブジェクトは「概念」を表現するのに適していますし、人は「概念」を抽象度に応じた階層で、系統だてして理解するクセがあるからです（分類病とでも呼ぼうかしらん）。
後に「実装の再利用」も「型の特殊化」も「概念の階層構造」も一緒くたというのは あんまりイクナイということが判ってきて、「実装継承」は委譲に外出しされ、インターフェースは「○○able」みたいに細やかに分解されて合成される対象になったりして、OOは「モノ」の階層構造とは若干違う方向を作るようになってきて。けれどそれでも尚、概念の階層構造はモデリングのよりどころであることは代わりがないという。いまのOOは多分そんな状態に感じます。
そこでトレイトですが、その皮（カプセル）は 実質 Interface (Java)的で、その実（実装）は再利用に適した単位の便利モジュールです。加えて、継承に全く頼りません*2。トレイトのある世界では、再利用（実装継承や委譲が担っていたもの）はトレイトに、型継承はダッグタイピングでまかなうので*3、ぶっちゃけクラス継承は不要です。
でも、「トレイトがあれば、クラス継承はいらない」とならないのは、たとえ型の派生も実装の継承もしなかったとしても、階層構造で抽象化することは、解りやすいことだから（たとえば、クラス継承がなく、トレイトだけが無秩序に散りばめられた世界で、目的のなにかをさがすのが如何に大変そうか）。開放閉鎖原則とかモジュール分解の観点から「良くないない」点がポロポロでてても、やっぱりわたしたちはは抽象化手法として概念の階層化が大好きみたい。
ならば、トレイトを導入することにより、クラス継承木を、再利用のためでも、型継承のためでもなく、純粋に理解のためだけの構造化に使うことが出来るんだよ！！！！（Ω ΩΩ< な、なんだってー！！）
と、突然脳内キバヤシが宣告をしたあたりで、Mix-in や多重継承と同列に語られがちな トレイトだけれど、その OOP に与えるインパクトは むしろ クラスベースとプロトタイプベースの違い並にガツンとくるのかもしれないのかも！、って思い始めた今日この頃。
* * *
なんて、大風呂敷を広げてみたり。
いきおい Mix-in や Intarface を貶めるような書き方でしたが、冷静になれば、どちらも何を継承木に残してなにを継承木の外に置くか、というアプローチだから、トレイトと同列に語るのが的外れなんてことは全然ないな、と書き終わってから思ったり。でも、そうは言いつつトレイトの異質さ加減は相当だとおもうのだけれど。
ちなみに 現状の Squeak の Traits の使われ方は ここまで劇的ではないです。これは既存のクラスライブラリが存在しているシステムだからでしょうか、それともトレイトは「共有したいけれど単一継承じゃ上手くいかなかった痒いところに手が届く孫の手」的用法がよいものだからなのでしょうか？よくわかりません。けれど、一度は Sather の インターフェイス至上主義的ライブラリのようなものを、トレイトでも見たみたいと思ったり。
うだうだ。
その343
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1349825903
やば、わたし頭がおかしいらしい。
でも、個人的にはいまどきパッケージ管理システムのない OS を使ってられないと思うのだけれど。
その344
最近、趣味の Android プログラミングを始めたのですが、Java が すらすら書けないよー...orz あまりに使わなすぎたみたい、しくしく。
ところで別の話ですが、お仕事で半年くらいまえに自分で書いた ちっちゃな ruby スクリプトを 拡張することになったのですが、ヤバ、全然わかんない。リファレンスをみつつなんとか修正。・・・おかしいな、自分で書いたはずなのに（しかもたった半年前ですよ...）。
そんなわけで、どうも頭がところてんのように詰め込んだ分反対側からだだもれのようす。年かなー、と思うのです。
その345
PS3 + torne を発売日そこそこに買って、ずいぶん録画がたまってきました（アニメばかりだけれど）。これだけたまってくると、ちょこっと見たいと思ったものが中にあるようになってきて、すぐみれるのがとても楽なビデオサーバーのメリットを享受し始めた頃合いです。
で、強く思うのが DVD とか Blu-ray をインストールできないものかな？ということ。2TB増設 + 3倍録画可能アップデートで 容量に不安もなくなったし。
できるようになりませんでしょうか。
ﾑﾘﾀﾞﾅ(;x;
その346
賛同するトコ、突っ込みたいトコ まぜまぜなのですが、
プログラミング言語は、構造化やオブジェクト指向プログラミングなどさまざまな進化を遂げてきたが、次の大きな技術革新は「可読性の向上」に焦点を当てたものではないかと、わたしは推測している。ScalaやRubyなど最近の言語は、非常に簡潔なコードが書けるものが多い。言語仕様が徐々に可読性という方向に向かって進歩しつつある兆候なのかもしれない、という考えはいささか勇み足だろうか。
さすがにこれは、ダイクストラ先生が草葉の陰で泣いちゃうかも、と思ったり。だって、ダイクストラ先生の構造化プログラミングは、プログラムが正しく動くことを、コードをみて容易に理解できるようにプログラミングするための 方法論です。（参考:http://www2.cc.niigata-u.ac.jp/~takeuchi/tbasic/Intro2Basic/Structure.html）
これを「『可読性の向上』に焦点を当てたもの」 と呼ばずになんと呼ぶべきかと、小一時間くらい..(略
* * *
世間的には、まだまだ「構造化プログラミング」 = 「if-else や while で書かれた goto を使ってないプログラムを書くこと」でしょうし、「テストでプログラムが正しく動くことを証明する」が無茶振りとは なかなか思われません。それどころか 可読性=品質という意識すら無いカモなのが「普通」だったり。そのなか「可読性大事！」と叫ぶこのエントリは大変素晴らしいと思います。
けれど「構造化プログラミング論」は本当は「実行モジュールが正しく動くことを証明するには、そのソースコードが読みやすくなくてはいけない」「そのためにどうするか」というものです。にもかかわらす、
アウトプットの評価はもはやソースコードから離れ、テスト項目の網羅性やテスト結果に基づく品質分析によって行われることとなる。
残念ながら、プログラマを除くほとんどの人は、コードが正しいことよりも実行モジュールが正しく動くことの方を優先する。
「コードの質の向上」とは一体なんだろうか。
と、振っておいての
構造化やオブジェクト指向プログラミングなどさまざまな進化を遂げてきたが、次の大きな技術革新は「可読性の向上」
は、狙って釣り針を下げてるようにしか 思えないクマーーーッ！、と釣られたクマー
その347
カルネージハート エクサにハマり中です。カルネージハートはアーマードコアやバーチャロンのような3Dロボゲーですが、一つ違うのは操縦するのではなくって AI をプログラミングするというところ。
いままでカルネージハートシリーズは守備範囲外だったのですが、今作の新要素「操縦」に引かれて初体験。というのも「操縦」もパッド入力を読み込んでそれに応じた制御を書くというプログラミングを行わなくてはいけないのですが、それがロボゲーマーが妄想する「わたしの考えた最強操作法」をお手軽に実現できるのでワクテカだったということで。ええ、ロボ大好きです。
で、やってみると、「あなどってたわ」と実感させられること仕切りで、
- プログラミング環境として良くできている。いろんなバランスに腐心した様が手に取るよう
- チュートリアル（シナリオモード）のできが秀逸。正直子供達には「プログラミン」よりはこっちをやって欲しいし、子供でも扱える容易さと、大人プログラマも のめり込んでしまう懐の深さが素敵
- AI ってシンプルなプログラムでも強い！ AIバトルなんておバカな挙動でエキサイトしないものだと思っていましたが、正直すみませんでした。
みたいな。
もっとちゃんとしたレビュー記事を書きたいのだけれど、シナリオがクリアできなくって（敵に勝てるAIがなかなかくめない。本職プログラマなのに...orz）、お預け中。
ていうか、トイレでもお風呂でも寝転がってもプログラミングできるって、大変 睡眠時間がピンチです。
その348
今日チロルチョコを食べていて、ふと こんな文言に気がつきました。
28度という温度にネタ感を感じてしまいました（前からありましたっけ？）
でも、今年の夏はずっと30度を超えていたし、事実チョコは部屋に置いておくだけでドロドロになっちゃってましたし、日本ではもうチョコは冷蔵庫に保存するものなのかもしれないです、とかおもったり。
「お口で溶けて手で溶けない」にピンと来ない時代がくるのかな？
