.NET Frameworkにおける列挙型の中身の列挙

たとえば、列挙型の中身をComboBoxに列挙してみたいとする。
ではどうするか、全ての列挙子を並べて追加するのか？
それが賢いと思えるのは、中身が3つぐらいまでだ。
ではどうするのか。
コレに関しては名前と値とどちらがUniqueなのかが重要である。
ユニークなほうをキーとして使う。
System.Enumのクラスメソッドを使用すれば、綺麗に作れる。
enumはEnumを継承しているように扱われるので、これが最善である。
あとはそこにあるメソッドをつかって好きなように。
ただし、復元するときにはParseを使う。ただ、こいつにはTryParseがないので、例外処理に関しては失敗しにくいとはいえ、可能性は0ではないので、気をつかうべし。

ライブラリの育てる

最近気がついたのですが、ライブラリって育てないといけないですよね。
売られているライブラリや、フリーのライブラリも優れたものがたくさんあります。高い完成度をもったライブラリはそれ以上育てなくても使えます。でもそれ以上に自分のためにライブラリを書き換え、成長させる必要があると思います。
本当はライブラリはカスタムしないほうが互換性や相手の共有の問題をかんがみるとそのほうが便利です。でも、開発の便利さという観点から言うとライブラリを固有のものに変えるほうがいいです。確かに基本の考え方やインターフェイスを保つということを行えば、一貫性を保てます。
ライブラリが互換性を保ちながら、Ver分岐を繰り返していくならば、それはとても巨大な差分をもったツリーの構造を持ちます。多くのブランチをもつ大樹に。
いつかはこれらの枝葉を落としてすっきりとさせないと、当初の開発のための使いやすさが阻害されます。

ということで、ライブラリを育てています。

楽観的な人工知能論

本当に意味での人間の知能と同じ仕組みを持ち、同じように駆動する人工知能は限りなく不可能である。

前提として統一体としての人間は脳のみではない。身体を持っている。これを無視しては意味がない。
だが、これも切り詰めていくと、人間の身体を機械で置き換えていったときにどうなのか。脳のみが生体でそれ以外が機械で構築された人間は、本当に人間になるのか。仮にそうであるなら、器官としての脳の動作を再現する機械が出来れば、確かに身体の面はそろう。
では、次に問うのは、生死だ。機関としての人間が終結するのはなぜだ。脳という機関のどこに致命的なダメージが起きると再生不可能なのか。人間をそのスイッチをON/OFFすれば、駆動を制御できるとする。このときにまだ残るのは、結局私たちに思考と呼ばれるものは何であるのかということである。
それは発火現象なのか？電気信号の錯綜なのか？はたまた思考というこの世界とは別の原理で成り立つなにかがあるのか？もっとこれは言える。物理現象とそれに付随して人間に知覚現象との間には明白な関係性はない。ただ経験的に励起の関係性があるだけである。そうでなければ、いかにして意識の書き換えが可能になるのか？
人工知能論は同時に哲学的な問いかけに対する実証の側面を含んでいる。だから限りなく解決不可能なように見える。哲学がいまだに学問として成立していることから考えて、なかなかに大変であるとしかいえない。

それでも世界はいまだにこの問題に関して楽観的である。それは、すでにいくつかの進展のように思われることをなしていると認識されているからである。だが、それは誤謬だ。振る舞いとしてはだいぶ人間を思わせる駆動が出来ている。それは認められる。ただそれはあくまで人間のような振る舞いを機械が実装しているからだ。実装はその振る舞いとは分離している。
OOPの考え方やCOMの考え方を思い出してほしい。これらのスタイルはインターフェイスとその実装を分離している。ただの結合の関係しかない。実装が隠蔽されていることによって、共通の振る舞いで一連の動作を考案できる。ただ入力に対しての最終的な結果が希望に合致していることが重要なのである。
この点をよくよく考えてほしい。部分的であるならば、犬も人間と同じである。食って、寝て、排泄をする。まったく同じだ。人のように見える。ここでは視点の持ち方が、インターフェイスの捉え方が上記のようなものであるからだ。期待するインターフェイスへの応答性こそが振る舞いができる、できないの判定基準でしかない。なにも知能はいらない。すべてプログラム可能だ。
だが、全てプログラム可能であるが、それが人間と同じ実装をしているのかは謎である。人間もアーキテクチャとしては、すべてに分解して解析済みであるが、その実装系は隠蔽されているが故に脳科学なるものや、哲学があるんだ。
すべての応答関係を洗い出して、それをプログラムしたとしても、それでもやはり同一かどうかは、インターフェイスへの合致の度合いでしか測れない。

・アーキテクチャの相違
・応答関係のテーブルの不十分さ
・アーキテクチャの相違を隠して、仮想的にするだけの知識がない。

一般的な意味での、人工知能は可能だろう。可能だ。ただどれだけ時間がかかるのかは不明だ。特に認識に関するものは人間の認識機構を全て洗い出すことと、またアーキテクチャの違いを乗り越えられるだけのブレイクスルーが必要である。
いうなれば、有限であるが限りない数字を数えきるという作業の感覚しか沸かない。

強いユニットの作り方

強いユニットはいかにして作られるのか。それは強化の条件を満たすために何度も使うことである。これは一般的な強化の方法であるし、また正の循環である。多くのゲームでも再現可能であり、そのためにユニットを育てる楽しみがある。

それでは話を現実世界に戻そう。いかにして、有用であり、また優良な人材になるのか。答えはたやすい。ユニットを育ててくれるマスターにめぐり合うことだ。またはめぐり合うために自己を強化するしかない。それ以外の方法があるのだろうか？攻略本や育成読本のないこの世界において、いかにして強いユニットになるのか。それは、ゲームですら採用されている方法を使うしかない。多くの戦線に赴き、多くの戦火を潜り抜け、多くの知識を蓄え、それを存分に発揮して、より多くのものを手に入れるしかない。嘆くよりも先にすることがある。仇敵を倒すためには、嘆くのではなく、立ち向かうのである。
それでは、残酷だというあなたは本当にそういった人たちを救えるのか？立ち向かうのではなく、ただ嘆くだけの人を前にして、その人とともにあることを望むのか？負の循環は非常にたやすく発生する。停滞は静止するのではなく、負の循環の形態である。本当の意味の停止は変化とともに自らも変えることである。それが正の循環を発生させうるかどうかでのみ異なる。
では、問う。何があなたを強化するのか？
それは、何もかもである。何もかもを利用して糧にしようと思うならば、全てが見方になる。あるいはその逆も。苦難は福音である。ただそれがどこを見ているのかによって価値判断は変化する。人間の評価はすべからく現在からさかのぼって過去を評価する。つまり現在がよければ、過去の不幸は書き換えられる。では、拡張して未来がよければ、現在が肯定されるか？否、それは詭弁である。到来していない未来を善にするのは、現在から進展していく我である。未来と現在と過去は同軸において論じられるがその性質は異なる。それは離散集合にも似て、大きな隔たりを持つ。
強いユニットをみた人は何を思うのか。それをほしがるのか、それに匹敵するものをつくりだすのか？ほしがるものは他人にたやすく奪われる。他人がほしがらぬものは、我もほしがらぬ。
では、何をおこなうのか。人は物ではない。故に人がほしがるようなユニットを自らにひきつけるのである。自らとともに生きることを選ばせるのである。彼にないものを我は持ち、我にないものを彼はもち、二人が分かちがたくあることがもっともこのゲームを攻略する上で重要なことだ。この観点はゲームにはあまりない。あっても限定的で、ゲームの成立を阻害するほどではない。しかし現実はゲームではない。ゲームクリアというのは奇跡に近い。
人は機微優れれば優れるほど、腐臭に鼻が利く。腐臭はふたをしてもくさく、どんなに優れた処理者でも、その腐敗を止められない。一度負の連鎖が確定すれば、その運命を変えることは難しい。だから最後には力なきユニットともにマスターは世界の崩落を迎える。
ゲームというのはもっとも簡略化された現実の模式図だと私は考える。このようなものを否定する奴にろくな奴はいない。まったくなにも考えていないとしか言いようがない。私はそのようなユニットはほしくない。そして私がほしがるユニットは、多くの局面において、切り札あるいは別の切り札を強化するユニットである。このユニットは絶対的に必要である。捨て駒にするなどありえない。ほかのユニットを乱費するユニットは、いくらその効果が優れていても長期では使えない。また限られた局面のみでしか運用できない。
裏切りをおこなうユニットは、短絡的に考えればいらない。しかし裏切りをして悔しい思いをするユニットは大抵優秀である。むしろそうでなければ、裏切りとして認識できない。裏切り者というのはそういう意味で、非常に魅力的であり、そのマスターの力量を表すと思う。荒くれを有効に使い、裏切られる前に使い捨てる、その判断力こそがマスターに求められる資質である。
自らがユニットでありながら、マスターに求められる資質を意識することは、とても強力なユニットへと自らを変えることを可能にする。そしてそういうユニットこそが真に恐ろしく、魅力的である。たしかにそれぞれのユニットに役割があるが、すべてがこのようなユニットで構成されているとき、中途半端な隊は駆逐される。ただこの隊の弱点は、劣勢においては、もっとも簡単に分裂を起こすのである。すべてが賢しいということは、崩落しやすい。またすべてが愚かしいと一蓮托生に崩落する。
なにごとも過度ではならない。ちょうどよく分配し、あるいはバランスが取れる程度の余力のある組織は安定し、また崩れない。組織とは自己を保存しながら、拡大していくものである。組織としての持続を考えない組織は、ある価値がない。ただ捕食され排泄されるだけの供物である。
私はとりあえず、正の循環を起こし、ユニットとしての価値を高め、裏切りという交渉手段を秘めるユニットになろうと思う。だから金銭が問題ではないのだ。ただ私にひざをつかせるだけのなにかをマスターには求める。ただ、それだけだ。ただ私にともに生きていこうと思わせればいいのだ。

便利さと習熟曲線

便利であるけれども、習熟曲線で実際の利の部分が出てくるまでの機関が長いものは、得てして不恰好なものといわれる。たしかに線形的に利がでてくるものならば、すばらしいが、大抵そういったものは上限が低い。
InterfaceやOOP、COMなどのプログラミングテクノロジー？っていう奴は一度その型にはまらないと利を得られない。

Interfaceの統一は非常に魅力的だ。これによって一意にロジックを組むことが出来ることはすばらしい。だが、このやり方に慣れていない人からすれば、これは非常に不恰好に見える。なにより手順しか記述されていないので、豊富なドキュメントで補わないと、そのロジックを理解することが難しくなる。だが共通の基盤に立つものにとっては豊富なドキュメントはごみに等しい。
教育でいうと、共通の基盤を知っていることを「教養のある」という形容をする。「教養のある」プログラマというのは、言葉にするのはたやすいがこの言葉に真に該当するのは難しい。プログラマが相手にしている領野はとても広く、とても更新が激しい。その中で「教養がある」という形容に足る存在は、ほとんどいないだろう。
これを踏まえた上で今日の社員教育や、大学での情報系の授業を考えてほしい。多くは語らないが、賽の河原にいる気分だろう。何をしたいのか？何を基盤としたいのか？そもそも大学でやることなど、すでに知っているか、それはプログラミング雑学だ。2000円の本に書かれていることをなぜ日給ウン万円の人がわざわざ講釈たれなければならない？そもそも規格文書あるいは仕様書以上の規則を教えてくれないならば、それは2000円以下の価値しかない。なにより2000円の本の内容を覚えたところで、すぐに使えるわけがない。それを使う術を教えないから、教えられないから。ついでに言うと教えられるなら仕事しているわ、ヴォケ。
でも時々そういうことを越えて、すごい人もいる。だけど学生には理解できない。「教養がない」から。
教養課程がどうのこうのじゃなくて、この専門化された社会で一般教養は語学と勉強方法論以外にない。真に一般足りえないから。もっとも社会的な制約下では、国史は一般教養足りえるが、あくまで制約下でしかない。

あたりまえの予言

時間がたてば、その先進的で先見性の高い予言も陳腐化して見える。

これをさかのぼって評価して喜んだりするのもいいが、その予言が当たり前のこととして認識されていることにちゃんと気づくことが大事だ。
ドラッガーの著書（たぶん原著の正確な翻訳ではない）を読んでいる。この人が予言したことを私は当然のことであると思った。またこのことにきちんと留意しようと思った。つまりこの予言の時代は到来しているし、これから先がある。と私は考えた。しかし、必ずしもこの予言どおりの世界になるとは思わない。たぶんこれを読んで留意している層とそうでない層で分離し、その中庸が取られると思う。でも支配的な原理を知っているのと知らないのでは振る舞いの「滑らかさ」が違う。

予言の当たり前のことに照らし合わせて考えると、現在の教育の機能は非常に稚拙である、いや的外れである。ただろくでもない「教授」という非生産者を生かしていくだけのポンコツ機関になりさがっている。詰まった便器みたいなものが今の大学だ。

大学生のもつジレンマもよく分かる。つまり「この学習が社会に出ても役に立たない」というジレンマだ。今の私からすれば、視点を間違えたジレンマにしか見えない。もう高校生の自分でも気づいていたが、重要なのは
・「学ぶという行為それ自体とその構造」
・「学習した知識によって何が変わるのか」
・「大勢とはなるべく競争しない」
ということへの感覚を養うことが、現状の教育制度の中で学生たちが効率よく振舞うために出来ることである。学習した知識など、それこそ君と肩を並べて学習している人々全てが知っているのだ。そんなものがいまどき何の役に立つのか？語られて広く広まったものには、もはやそれ自体では力がない。秘匿されているもののみがポテンシャルをもっている。
まぁこの原則みたいなものは、別に一度身につけば、それをやめる必要性もない。これこそが優れた企業家やビジネスマンに求められることだ。コミュニケーション云々は、大前提であるし、これがなくても上記の原則を生かせばいくらでもカバーできる。声高に叫んでいることの中に有益な情報なんて一つもない。それには何の特別な点もないから。

まぁ本来の大人に要求されるべきものである、「その先の社会でどのように生きていき、どのように社会に関わっていくのか」を考えるということを「大人」は教えない。また教えられない。彼らは結局なにも学べていない。手段と目的、金銭を稼ぐことと物を売ることの関係性が逆転している状態を是としているからだ。これに気づかないから教えられない。知っている人は教えない。当たり前だから。
そしてもしも教えるときにはその人を利用するときだ。傀儡にするにはちょうどいいから。だが悲観することはない、君は求められている！

この流れで行くと、学生の各個人の信念の持ち方は不十分に見える。
だが少し救いがある。人という総体はそれほど高尚には出来ていない。止むに止まれずうまく立ち回るという方向性を持ちうるかもしれないが基本的には意志的に行動などしない。ただ環境が許すことによって、高度な教育を受けられた人のうちの、さらに何割かの人々が、ただ自分たちがうまく生きていけるようにその考えを利用し、そうでない人を使用する。

だけど忘れてはいけない。いい組織にはちゃんと上と下がある。みんな下ではうまく行かないし、みんな上ではそもそも立ち行かない。過度に人を利用する人は結局は身を滅ぼす。だから唯一この上下の関係性の健全性が社会での持続的な発展を促して、そのために自浄作用をもつ。だからどちらがえらいということはない。ただ命令系統に優先順位があるだけだ。

こういうものが途方もなく好き

http://wiredvision.jp/blog/gadgetlab/200905/20090521100034.html
折りたたみ自転車。
最高にクールだとおもいませんか？
折りたためることを知ったときの驚きは、久しぶりでした。
久しぶりに驚きました。久しぶりにかっこいいと思いました。
デザインってこういうのですよね。

Perlも学習

どうもJudaです。
最近、ちょっとしたことでPerlの勉強をまた始めました。以前にも何度かPerlに挑戦しているのですが、その度に長続きしませんでした。理由はこの言語を常用するコミュニティに属していなかったことがあげられると思います。まぁ現在も属してはいませんが。

MacでのPerlの開発はネイティブで使えるので少し導入が楽ですが、実はWindowsのActivePerlがもっと強力です。CPANというPerlのModuleを集めたデータセンタがあるのですが、そことの連携の強いModule Managerがついているので、最新版の入手やそのパッケージが改変されていないかのCheckまで簡単にできます。
MacのコンソールはWindowsのコンソールとは大きく違います。Macはbashで動いていますが、WindowsはWSH?で動いているので、コマンドが異なります。
特にそのことを感じるのは、 ディレクトリの検索するときのコマンドが
Windows: dir
Mac(bash):ls
とこんな基本的なコマンドすら異なるので、別の環境から移行してきた人には少し慣れを必要とします。

まぁ、それもありPerlの勉強の前にコンソールの動かし方の勉強になるのですが、環境変数の設定に関してはさらに一癖あるのですが、これに成功していないので、何とも言えません（ぇ
ただGUIで変更できるWindowsは開発者ライクだなぁと思いました。

Perlの話に戻りますが、いまさらながらにリャマ本を読んでいます。初学者だし。ラクダ本も近いうちに買うかもしれませんが、趣味みたいなものでPerlを使うので、優先順位は低いです。
リャマ本はまだ二章の途中ですが、面白いですね。読んでいて、ところどころのジョークが私は好きです。固くなりすぎないので、ちょっといいです。ただPerlはまだまだ呪文のように見えるので、とりあえずはソースを読めるようにがんばりたいと思います。

デフォルトコンストラクタ

なんだか、VBにも慣れてきましたが、私はC#スキーです。

VisualStudioでWindowsFormApplicationをつくっている人で、困ったことにならないように事前に注意。Formから派生したものでDesignerをつかってレイアウトなどをいじる人は、絶対にデフォルトコンストラクタ以外のコンストラクタを作らないこと。
引数なしの単純なコンストラクタ以外を作ると一発で駄目ですっていわれます。
コマンドライン引数がほしいときは、Application名前空間のものを使えばいいと思います。
それ以外にもLoadイベントの中でエラーが起きると、Designerが死にます。UserControlもオブジェクトファイルなりDLLなりがないと不安定になります。

VBは基本的には型指定なしでガンガンコードを組むための言語なのですが、なぜかデリゲートに関してはナイーブです。匿名メソッドへの対応がなかったり、NULL参照がしにくかったり、意外とFrameworkとは相性が悪かったりします。クラスメソッドをインスタンスから使えたりするので、これは非常にややこしいです。暗黙的に引数に指定してくれると楽なのですが、そうもいかないのでなんだかなぁです。

話は変わりますが、UserControlはただ作るのでは、まったく使えません。かといって、全てのコントロールをAccess可能にして使うのも下策だと思います。確かに扱いやすいのですが、それでは結局はただ配置しただけで、むしろ複雑な操作を要求するようになるだけでいまいちです。カプセル化やインターフェイス、イベントドリブンの組み方を少しは理解しておいてからおこなうと、すっきりとしたものが作れます。またこれに付随して属性の勉強を始めるとできることが目に見えて増えるので、この経路での属性の学習はありだと思います。
ただ、このUserControlはVSとの親和性が異常に低いので、いろいろなところでエラーやミステイクの温床になるので、気合を入れて使ってください。ただ、これは慣れると、構造がすっきりして見易く、カプセル化や抽象度の変化についての考えが深まるので、使えなくなると逆に不満が爆発するでしょう。
でもマジUserControlでよく使うコントロールや巨大なコントロールをクラスにすると扱いが簡単になって幸せです。オブジェクトのネストが5とかになると管理がしにくいので、一考の余地アリです。

XULのための思考実験とその効率的なあり方？

XULなるものがある。
http://ja.wikipedia.org/wiki/XUL
XULとはUI（ユーザーインタフェイス）を記述するためのXML文書のことらしい。

V→UI→COM→C→M

今日はそんな話

Microsoftの.NET Framework 3.5 でのWPFアプリケーションを作る際のXSTLなんかとよく似ていると思う。どちらもUIを記述し、イベントを関連付けするためのものである。WPFは一度取り組んでみようとしたのだが、あまり便利だとは思わなかった。確かにUIの記述方法がマークアップ言語化されているのでWebでのデザインに慣れている人にはわかりやすいかもしれないが、これが要求するプログラミングスタイルはMC-Vである。ViewであるVがModelとしてのM、ControlとしてのCとは完全に分離していないといけない。Appleでのプログラミングを主とする人にはどうということはないが、一般的なWindwosApplicationProgramを行う人はMVCには慣れていない。CygwinでLinux環境向けに開発している場合も例外的である。
確かにVがMCと分離することには非常にメリットがある。それは見た目を変えても、関連付けさえしっかりされていれば、同等の機能を発揮できることである。これは再利用という面から見ても有益だ。
またMC-Vを推奨するならばCOM（Component Object Model)プログラミングの重要性も考えるべきだ。これは、Interfaceという考え方に基づいた汎用的あるいは抽象的なプログラムの駆動を制御するプログラミングモデルである。COMに基づくとその実装は知る必要はない（むしろ秘匿されている）。ただその制御の流れについては熟知していないとまったく使えないのである。
XULによるUI記述ならびにそれと特にCとの結びつけ。またこのCがCOMを採用し、一層、抽象層を継承して記述するならば、｛XUL（UI｝：V）→｛Interface→Control：C｝という流れを持たせられる。このときには特定の機能を実現するためのInterfaceを実装したものに付随するUIとしてSetに使えるようになる。ただここまで抽象化して、実装と分離すると、ブラックボックス的に動く部分が増えすぎて、破綻をきたしたときに対処することが容易ではない気もする。逆に分離されているから問題ないのかもしれない。
話はもどるが、XULでUI+Interface形式の記述を行うなら、Interfaceとその使い方が変わらない限り、UIの変更も、Control側のロジックの書き換えも自由だ。Interfaceという中間層で違いを吸収するようにすれば、デザイナとプログラマの仕事を分離できる。これがすばらしいのかどうかは分からないが、分業や専門性による分離が明確になる。まぁ、両方できるに越したことはないが。
追記
XUL ファイルは、どの要素が UI を構成しているか、どこに要素が現れているかを記述します。XUL 言語は制御に反応してどういう働きがあるかをプログラマが定義することを許す属性を定義します。動的なアプリケーションのふるまいを定義するために、ある場合には特定のユーザインタフェースイベントが発生したときに呼ばれる JavaScript 関数を定義することが出来ます。それらの JavaScript 関数の中では、直接アプリケーションのふるまいを記述するか C++ で定義されたロジックを含む COM オブジェクトの利用可能な他のアプリケーションロジックを呼び出すかすることが出来ます。
引用元：https://developer.mozilla.org/ja/Mozilla_Hacker's_Getting_Started_Guide
やっぱりCOMの考え方は使われているというオチ。まぁスクリプトに関してJavaScript　Onlyなのは、多言語対応がややこしさを持ち込むのからだろう

女性に便利なサービス

ネット時代の婚活
「男性を家畜扱い」「個人情報どうなる」　婚活サイト「男の子牧場」に批判殺到
まぁ、ローカルなレベルで、これをやっていると思うので、もういまさら何を言っても遣り様がないと思います。たしかにこのサービスをするにあたって、男性が閲覧できないシステムになっているかもしれませんが、ネット上での人格に性別、年齢は存在していないので、リンクさえされていれば進入可能なので、愚かとしか…

男性が作ると小動物でかわいい・きれい/壁・山って分類ですかねぇ…そういう風なサービスがされていると女性はどう思うのでしょうね…お互い愚かですよねー…うふふ

便利だけどシニカルなサービスだとは思います。なんとなく「こういうふうに人をみているのかー」って思っちゃいますね。そして、その次はその悪感情が「そのようなサービスを利用するような女性はご遠慮願いたい」ってことですかねぇ。上品なサービスか？と問われれば、そうではないとしか答えようがないですな。結婚相手が自分のことを馬やヤギなんかだと思っていると知った日には…草食動物のような気性っていってもそれはあくまで基本的な気質で、明らかに侮蔑的な扱いだと思いますよね。。。サラブレットですら、若干嫌ですし。。。馬面かよ！って（ぇ？
そもそも婚活なるものをするぐらいなら、親に見合いを頼めばいいのでは？恋愛と見合いの中間という意味で婚活があると思うのですが、機会を増やしたところでその市場に自分のほしいものがないことに気づくのではないのでしょうか…

あー、でも婚活ってのもしなきゃいかんのかー？もうめんどくせぇよ、そこまでして結婚したくねぇよ。ぶら下がる気しかない相手なんぞ要らんわ。

Crinkler/GFXとは？

語句説明

SystemKのkioku氏のブログ
Double Slashのgfxプロシージャの特集に出てくる。
Crinklerとはなんぞや

Crinkler is an executable file compressor (or rather, a compressing linker) for Windows specifically targeted towards compressing 4k intros.

適当意訳
Crinkelerは実行可能なファイル圧縮機で（いや、正しくは圧縮リンカだわ）Windowsの、それも4K Introを対象とした特別な奴ね。
簡単に言って4k Introのための特別な圧縮屋
わかったような分からないような。

まぁこれはおいておく。

そもそもGFXってなんだ？
デジタルアートのことなんだと思うけど、まさか…
Graphics=グラフィックス=じーえっふぃっくす=GFX
ということなのか…

だとすれば、gfxプロシージャであるところのProcessingと近いだろう…

BOXING

決して格闘技ではありません。ボックス化です。

いまだにC#でボックス化を意識的に使わないとうまく使えないです。
クラスが参照のコピーでしかなくて、クラスでの実体のコピーはそのためにコンストラクタ（C++でいうとことのコピコン）が必要になります。またC#では構造体は値型なのです。
C++はクラスも構造体もどちらも同じように定義ができますし、アクセスメンバの初期状態の違いだけで、本質的にどちらもC#で言うところの値型です。でもそのくせ、コピコンが必要です。
ボックス化を意識的にやりだすと、もうこれはほとんどC/C++のポインタとかと同じです。むしろそちらのほうが表記が明確なだけ気が楽になります。
まぁ、これが言語の特性なので、これを理解できるような段階に上ってきていることが喜ばしいです。（的外れかどうかはおいておいて

SystemKのkioku氏がSpecialなページを作ってくださいました。
http://kioku.sys-k.net/4kgfxmon/
先に言うと、私の勉強不足で、gfxが何を指しているのかよく分かっていません。Graphics Flexible eXtention？（知らんが）画像可変的な外部拡張？
ただ機能的によく似ているのがProcessingかなぁ、と。

でもこの特集の中で重要なのは、モデルデータではなくて、ピクセルデータの当たり判定という観点かなぁ。そこは詳しく説明されていた、と思った。。。
すばらしい特集なので、いろいろなところで吹聴していきたいなぁと思いました。
（今日は思ってばっかりだな）

P.S. 　とりあえずプログラミング多言語マニアになりそうです。
P.S.2　はやくゲームをやれるだけの余力がほしいです。ヴァルキュリアやりてー

ネオリベらしい

どうやら私の経済の考え方はネオリベに近いようだ。
といってもその思想の始祖の本を読んだわけではない。
たださまざま言説を少しなぞってみた感じでは、その考え方が割りと好きである。

でもこの考え方の怖さはたぶん無自覚でいられないことだと思う。この考えは多くの大前提（現在の前提とは異なる）があるので、前提が共有されていない状況では理解しにくいという問題もある。これは議論のときに問題なるけど、それはどれも同じ。議論中には誰もそれぞれの土俵を捨てることができないことが実は哀れ。
日々に忙殺、あるいは無気力ゆえに考えることをやめて生きることをよしとするならば、ネオリベで満たされた社会では欲望を抱くことは難しい。自らを売り込むことが出来ない人は、生きてはいけるが、それ相応の状況で生きていくことを理解しなくてはならない。自らと向き合い、他者と向き合うことから逃れられない社会にネオリベっぽい雰囲気がある。

このあり方はとても理性的である。哲学的といってもいいかもしれない。自らの行為に責任を持つが故に、失敗したときの負債は大きい。故にセーフティネットを用意したほうがよい。また再挑戦を可能にしなくてはならない。でも現実にはないから、ネオリベの人は自らセーフネットを確保しておかなくてはならない。人生を難しくしている原因は、セーフティネットのなさと再挑戦の困難さである。要求を満たしているものはゲームだ。

社会をゲームのように動かしていくことがネオリベだろう。

ロボット開発

楽しそうに尽きる。
開発を試すにも費用の面でいくらか安くなってきているので、
楽しみが増えてきた。
またCAD,CAMの統合開発環境についてもずいぶん状況が変わってきているので、
ローコストで行えます。
とてもすばらしいことです。
近いうちにこの方面へも参戦予定です。

ロボカップに行ってきた

どうもJudaです。
今日は京セラドームで開催されているロボカップの観戦に行ってきました。
一言でいって、ワンダーランドです。


ロボカップなので出てくるロボットは基本的に自立型が多いです。一部中型よりも小さいものは、その機体サイズの制約として、視覚に相当するセンサを外部に持っているものがありました。
特に中型の中央の司令塔があるタイプのロボットは楽しそうでした。大型機のほうは、制御が難しいらしいのか、まともに動いているところをみることができませんでした。2.1mの巨大二足歩行ロボットもいたのですが、タイミングの関係で動いているところは見れませんでした。残念。

とりあえずロボットの制御などの問題は、下のレイヤでは画像処理、上のレイヤでは指揮指令の問題があるとおもった。後者は人間の世界でも同じです。ただし前者は人間と同じように考えているだけでは限界があると思います。

その理由は、人間の情報処理方法と機械の情報処理方法との間に大きな違いが見られるからです。まぁ単純に言うと人間は類似→同一、機械は同一→類似の処理が簡単だということです。これが非常に重要。実世界では同一などありえません。類似の制約度が高くなった程度しかありません。1つ、汎用的な属性を挙げるなら、エントロピーぐらいしかないのです。

前述の違いゆえに、機械に高速に処理をさせるためには処理に適した情報を準備してやる必要があります。この準備に関しても、人間が調整して機械のために準備しなくてはいけません。これを簡略化するために遺伝的アルゴリズムなども利用されますが、そのアルゴリズムで考慮するパラメータも事前に人間が用意します。

…こんなことばかり言うと不可能のように見えますが、この問題が解決するならば、可能になります。問題点が特定されているのか、どうかということは試行するときの大きな目安になります。そしてまだ救いがあるのが、これが論理的に、あるいは哲学的に完全に否定されていないことです。ただ人工知能を作り上げることに関しては、もう相当に分が悪いです。処理機構の抜本的な変革がないと無理です。

あとこれに付随してCAN(Car Area Network)通信のようなデバイス間で中枢を経由せずに調整をするような機構の開発が次のブレイクスルーになるのかもしれません。この調整機構は「無意識」に近いので、ちょっと面白いと思います。

仕事好き

どうもJudaです。
私は今の仕事も好きです。
働いて、お金もらえるのが好きです。できれば働かなくてもお金がもらえると楽です。
今はこの仕事が好きだけど、それはそれなりに理由があります。

この職に就くことを決意したときに、勉強をし続ける覚悟をしました。そのために技術書は惜しみなく買い、時間の許す限り本を読み、プログラムを生成しました。割とほかの事は切り捨てました。私には、それが苦にはなりませんでした。遊びに行ったり、女の子とイチャイチャする時間は正直作りませんでした。いえ、作れませんでした。相手の必要なことは思い通りにならないことばかりです。それは嫌ではないのですが、どうも期待しすぎていて、相手には重荷のようです。あとは、イベントとか無関係なので、そういうことを重視する人には嫌われましたｗ。
このことで人生を損していると思う人もいるでしょう。まぁ、それなりに損だと思うことはあります。ムードのあるデートというものもしてみたいです。まぁ、損だ、損だというのは馬鹿らしいですし、それ以上に毎日が楽しいので、損していると思いません。仕事が好きですけど、仕事中毒ではないです。暇があれば、それなりに楽しめるし、リフレッシュもできます。ただ女の子と仲良くすることはハードルが高いです。
まぁ、勉強してたくさん物を知っていると、業務が楽ですし、それなりに成果も挙げやすいので、評価もされやすくなるので、充実していきます。たぶんこういうのを正の循環というのでしょう。私は意図的にこの状態が生み出されるように、力を注いでいます。
何度も恨み節のように出てきますが、こういう循環には女性が入ってきません。なぜか！。たぶん女性への献身がほぼ０なのがいけないのでしょう。いや、でも薄情ではないです。愛情というものはよく分かりませんが。優しいということもわかりませんが、親切はそこそこ親切です。押しは弱いです。でも主張はします。

あー、はやく嫁さんこないかなぁ（マテ

話は変わりますが、言語の特性の部分に近くなれば、なるほどプログラミングの楽しみもぐっと増える気がします。効率化と簡便さを追求しだすと、ワクワクがとまりません。C++のSTLやBoostのライブラリの実装を眺めていると感嘆します。
論理的かつ端的な機能実現には感心します。またかゆいところに手が届くライブラリの設計とか。人間の叡智の結晶を見た気になります。

あー、すばらしい実装をもっとみてー！

C++とC#の大きな違い

それはC++のClassは絶対的に値型、C#なら参照型。これはどこでよく分かるかというと、データの取り扱いで、C++はnewのキーワードは(T*)mallocのSyntax Sugerでしかない感じ。それゆえ、Newを受けるのはT*なので常に扱いが->になるので、若干冗長になる。

あとはC#が常にobjectの継承になるので、基本的にGenericが実現可能なのに対して、C++はdefaultでは継承関係にはないので、これは明示的に実装するしかない。ただし、これよりもC++で重要なのは、TemplateClassやTemplateMethodにあるでしょう。これによって継承によるコードの重複を抑えることが出来るようになります。C++はそもそも考案された段階では現在ほどのメモリ量やCPU速度がなかったので、Genericが考えられてない、と思う。それよりも後に考えられたC#はGenericやTemplateなどのメタプログラムへの拡張がよく考えられていると思う。
それゆえに、C++とC#は使うべき分野が違う。高次のプログラミングにはC#、組み込み系などのリソースに限界がある場合にはC/C++が向いているのだろう。
C/C++での組み込み系でひとつ問題がありまして、DOSは16bitの限界があったはず…また32bitでのCUIベースのシングルスレッドC言語環境が調べてもないです。いまどきDOSを使っているところがまだあるのかといわれると、存在しているとしか言えません。ただ重要さの順位から言うとシングルスレッド、32bit、CUIな環境。…環境がないので、たぶんISO Cの仕様を満たすアセンブラかCのコードを生成して、OSを構築していくしかないような気がします。あー、工業用のマイコン出している会社がそういうOSつくらんかなぁー

元学生の反論

livedoor news - 最高学府はバカだらけ

まずこの主張の始めに雑誌と学力の相関関係がでてくる。
雑誌を読む（AERAや週刊朝日）という行為をしていないことと学力の低下にどんな関係がある？
ちなみに学力とは、学校制度の中で問われる試験での得点獲得能力がもっとも的確なパラメータだと思う。それは、これ以外のものの判定は現在の入試制度では問われない。その考えを裏付けるように、この主張は後半で入試制度との関係が出てくる。この人の主張の中で例に挙げられている雑誌を読んでいると成績が上がると思いますか？私は、そのようには思えません。問題意識を持たせることや、意見の多様性について知るという効能はあるかもしれませんが、どういう因果関係を通じて学力の向上などにつながるのでしょうか？私には非常に微弱な関係性しか認められません。

またこの主張の中で社会人とのかかわりがでてきますが、これはむしろ相対的には社会人が増えていると考えられるので不当であると思います。それに以前ほど近所での付き合いの中で大人とかかわり合いになることが少なくなっているとしても、ボランティアなどで結果的なバランスがとられていると思われます。社会での関係性の構築が苦手なのは、もっとも最小の社会である家庭の形態が変わっていることに起因するのではないでしょうか。
私の主張も若干飛躍していますが、社会構造の変化とコミュニケーション能力云々の間には明白ではないですが、それなりの相関があると思います。核家族化の進んだ社会でそこに生まれた子供たちが成長します。そして社会にでてきだした頃にこのコミュニケーションということが問題になってきているように思われます。

また教育というシステムに人々があまりに多くのことを仮託していると思います。なにかあればすぐ学校やシステムのせいにしますが、嫌だと思うなら、国の対応が悪いと思うなら、どうぞ別の手段を講じてください。具体的な改善案と収支計算と財源についてまで計画されているなら、そしてそれが確かに優れているなら、みなさん賛同するでしょう。違いますか？

結局持論を展開して、訳知り顔で「国が悪い」という結論を述べることは、ブロガも記者も大差がありません。記者とブロガの差異は、それが編集されているかいないかですが、この編集という行為もひとつのシステムですから、このシステムが妥当であるのかどうかということは、国というシステムを検閲するというお題目を掲げるものは自らにもその矛先をむけることが道理である私は考えています。

システムへの信頼はとても社会を動かすためには必要な要素であり、このことを指摘している哲学者もいます。ニクラス　ルーマン
この人の考え方をもとにした社会学の理論をつかってわかりやすくしている記事がありました。
社会学の理論で斬る「ネットの不思議」

本当に学力の低下を憂いて記事を書いているのであるなら、当然ルーマンを引き合いに出すと思われるし、この問題を雑誌媒体を読まない＝バカになるというような構図で簡略化して提示してしまうことは不適切だと思う。まぁ、バカがバカを笑っているだけという喜劇ならば、それに本気で怒っている私も道化なのでしょうw

データの分解、再構築

私には、他人のソースコードに手を加えだすと、最短手順で要求を満たすのでなく、リファクタリングをしまくってしまうというとても面倒な癖を持つことが判明しました。関数内での抽象度の統一に主眼をおいたリファクタリングをするという方針が悪いとは思っていないのですが、最大の短所として時間がかかりすぎるという大きな問題があるのです。まぁそれ以外には、元の人からすると変数や関数が自由に参照できなくなるので、不便だと言われます。さもありなん．．．

関数が綺麗になって、変数もグローバルが少ないととても見やすいと思うのですが、それをやっているとほとんど別物になる。リフォームしてほとんど別物の家になるけど、それが使いやすくなっているとは限らないということが。。。

変数がほとんどPublicのプログラムをみるとしんどいです。たくさんのコメントをつけてくれているとまだ楽なのですが、どうせなら参照範囲ごとになるべく関数と変数をセットにして関連性を高めてくれる方がうれしいですね。

何にせよ綺麗で簡潔で、あまり依存関係の強くなく関数、変数をつかうプログラムが能力的にとてもいいです。変数のスコープが短いととっても楽です。全変数グローバルはやめて下さい。(><)