日々吾は

どうもJudaです。
読んでいるのだけど、この本はとてもためになる。
『Exception C++』を読むための門前本として紹介されていてEffective C++を読んだらExceptional C++の良さがわかったCommentsAdd Star、「なるほどなるほど」と思って、読み出しました。
C++という言語などのプログラミング言語を使って生活をしているのですが、ちゃんと理解していないでいたこと、どういうプログラミングをすることが流儀に従うのかということについてのちゃんとした知識を得られるのが実にいいです。
もっとも自分のプログラマとしてのレベルが足りないので、この本ですら、読むのが少し大変ですw

どうもJudaです。
最近思うのですけど、世の中にはすぐにできないと言ってしまう人が多いのですね。
例えばそれがハンダ付けであったり、電子工作のためのパーツ選定であったり、数学的な理論の読解であったり、英語の読解であったり、経済の勉強であったり、法律の問題であったり、権利関係の書籍の読み込みなど。
飛び込んでしまってから考えようとか、命が残るからやってみようとか、そういう感じは一般的ではないのですね。
私はなんだかんだと口ではそれが如何に難しいのを留保してから、結局いろんなものに手を出しますね。そうしないでいることによって選択肢が狭くなるのが嫌なのです。
でもなかなか人間関係には飛び込めない。唯一これだけは無理ですね。
失敗した場合に、多少なりともこの問題は死を呼びこむので個人的に苦手です。一番怖いのは人間です。

どうもJudaです。
今日はXMLシリアライズな話


using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Serialization;
using System.IO;
using System.Xml.Serialization;

namespace SerializeDaemon
{
 class Program
 {
  static void Main(string[] args)
  {
   XmlSerializer xmlSel = new XmlSerializer(typeof(Deamon));
   StringWriter wStrm = new StringWriter();
   Deamon hoge = new Deamon();
   xmlSel.Serialize(wStrm, hoge);
   Console.WriteLine(wStrm.ToString());
  }
 }
 public class TestA : ISerializable
 {
  protected int m_id = 0;
  public TestA() { }
  public int Id
  {
   get { return m_id; }
   set { m_id = value; }
  }

  #region ISerializable
  protected TestA(SerializationInfo info, StreamingContext context)
  {
   m_id = info.GetInt32("Id");
  }
  public void GetObjectData(SerializationInfo info, StreamingContext context)
  {
   info.AddValue("ID", m_id);
  }

  #endregion
 }
 public class TestB : TestA
 {
  public TestB() : base() { }
  protected TestB(SerializationInfo info, StreamingContext context) : base(info, context) { }
 }
 public class TestC : TestA
 {
  public TestC() : base() { }
  protected TestC(SerializationInfo info, StreamingContext context) : base(info, context) { }
 }
 public class Deamon : ISerializable
 {
  TestA m_id0;
  public TestA Id0
  {
   get { return m_id0; }
   set { m_id0 = value; }
  }
  
  TestA m_id1;
  public TestA Id1
  {
   get { return m_id1; }
   set { m_id1 = value; }
  }

  TestA m_id2;
  public TestA Id2
  {
   get { return m_id2; }
   set { m_id2 = value; }
  }

  public Deamon()
  {
   m_id0 = new TestA();
   m_id0.Id = 100;
   m_id1 = new TestB();
   m_id1.Id = 4000;
   m_id2 = new TestC();
   m_id2.Id = 6000;
  }
  protected Deamon(SerializationInfo info, StreamingContext context)
  {
   m_id0 = (TestA)info.GetValue("ID0", typeof(TestA));
   m_id1 = (TestA)info.GetValue("ID1", typeof(TestA));
   m_id2 = (TestA)info.GetValue("ID2", typeof(TestA));
  }

  #region ISerializable

  public void GetObjectData(SerializationInfo info, StreamingContext context)
  {
   info.AddValue("ID0", m_id0);
   info.AddValue("ID1", m_id1);
   info.AddValue("ID2", m_id2);
  }

  #endregion
 }
}

コンパイルは通るけれども、実行はできないソースコード。
問題点は、シリアライズ対象のクラスがもっている要素に継承クラスが代入されていること。これはシリアライズにおいて、とても大変な問題をはらんでいる。
サブクラスをシリアライズする方法なんてわからないのだから。
シリアライズという行為が現状を復元可能な形で保存することにあるときに、継承クラスかどうかの判定なんて誰がどうやってするんだろーって事で原理的に今は無理です。柔軟に対応しないといけないならば、むしろ別の方法でそれを実現する方法を探す方が賢いと思います。あるいはできるなら、それを教えてください。
とりあえずは素直にすべての要素が構造体で定義されているものをシリアライズするコンテナクラスとして使用しましょう。というお話です。

細かな点ですが、インターフェイスはコンストラクタを規定できないので、実はISerializableの実装はちゃんとコンストラクタを特別に作っておかないとダメです。
ややこしいですねー。

どうもJudaです。
とりあえず掲題の内容を行う。
なぜ作るのか？それは必要だから。
Random関数を範囲で分散する方法に切り替えようと思うと、どうしてもIntervalって感じの区間計算クラスが欲しくなった。それ以外の用途でも、特定の定義域に値が存在しているか、いないのかを簡単なインターフェイスで取得できることをとても便利であり、よくある処理なので、これをつくる。
BoostのIntervalのAPIを参考して、なんとか作るつもり。本当に数学的な意味でのIntervalの実装は面倒なので、使い易い部分のみをサックリと。
昔似た機能のLimitというGenericClassをつくったけど、それはSerializeのためのSyntaxSuger的な糖衣クラスだったので、ちょっと今回はかっちり作ってみつつ、Serializableも目指す。
細かなクラスや機能ばかりを作っている気もするが、気にしない。大きな建築物を作るには細かな道具の手入れや資材の準備に時間を惜しまない。すべて我が血肉になるのだから。

どうもJudaです。
画像処理ライブラリは汎用性が高くて、使用頻度も高く、なおかつ逐一スクラッチで作るにはめんどうで、それでいて速度が求められて、細かな仕様に左右されることの多いライブラリだと最近思います。
例えばOpenCVのRGBコンポーネントの内部的な配置はRGBではなくBGRであるなど（一応内部的にRGBへ変換する関数が存在するようですが）コンポーネントの問題があり、その画像がRGB24なのかRGBA32なのか、それともGrayScale１６なのかGrayScale32なのかYUIなのかHSVなのかなど色空間の問題もあります。
それらすべてに汎用的なものを用意するのは、非常に困難であり、通常画像処理ライブラリはRGBでの画像処理をもとに考えられています。もっともこれ自体は特にプログラマにとって問題なく読替を効かせることのできるものです。問題はそのライブラリは高速にすることや、面倒を回避するために汎用化することです。
一部細かな話しですが、.netでのImageの操作は通常はメソッド経由なので、オーバーヘッドが尋常ではないので、特定の一点から取得するなどのアクセス頻度の低い作業以外は、なるべく低レベルな操作で構築する必要性があり、BitmapのLock/Unlockは.net系の画像処理では必須であり、これはコンポーネントの構成に大きく左右されるので、通常のマネージドな感覚で行っていると速度の低下が発狂せんばかりになります。Lock/Unlock以外にもUnsafeでガリガリ行う方法もありますが、移植性が下がるので、なるべくそれはやめた方がよいです。それに性能もそれほど向上しないので、最終手段として覚えて置く程度でいいと思います。
話は戻りますが、画像処理は速度と精度と汎用性、多種多様性、移植性、利便性など多くの点が求められるので、なかなか構築が面倒なのですが、作ることは非常に有益だと考えます。
またコンセプト的な嗜好も混ぜ込めるので、個人的にはある程度以上のレベルからは自己のライブラリとして蓄積することを考えてしまいます。
そうするとオープンソースがとても魅力的ですが、仮にこれを業務で特定のアプリケーションに組み込もうと思うと商用ある程度のライセンス料が必要です。そもそも煩雑で有用な知識の集積は、その労力によって企業による上澄みの簒奪を唾棄し、その行為への怒りをこめて、オープン化する場合もあるので、有用なものを安く使いたいという心とライブラリの制作にかかるコストを最低限でも回収したいというジレンマがよくわかります。個人で開発しだすとよくわかります。
だから個人で開発しだしても、やはり企業に差し出すなどということは許容できないなぁと思います。

企業はもっとライブラリライセンスに金を払えやこらー！っていうのがある意味本音です。安くあがる分けねぇだろ、知識の集積を利用しようとしているのに。

どうもJudaです。

読書と筋トレを私はほとんど同列の行為だと時々認識します。
どちらも自己を研鑽する目的があります。読書も本によって内容に強度がありますし、難しい本はやはりベンチプレス200kgのような困難さがあります。しかし読書や筋トレを好む人は、その困難さを楽しみに変えますし、それが嫌いな人は、その困難さが嫌いなのです。運動を頑張る人が勉強を頑張れないというのは、結局はこの困難さがあるということを知らずにいた人なのだろうなぁと思います。私は、個人的にその感覚を養うことができないことはもったいないと思います。ただなにかに頑張るにしても、良き指導者がほしいのは変わりませんが。

さらに読書と筋トレから同様の枠組みを取り出すならば、それは「不自然な行為を自然な行為に変えていくこと」ということでしょうか？読書は通常の人間の営みからすると不自然です。この場合の不自然は意図をもって行動を行わなければならない。ということです。同様に通常の人間の営みからすると筋トレは不自然です。明確な意志や意図をもって行わなければ、それを行うことはないでしょう。

私はこの意図や意志というものを高く評価しています。それは哲学科という日本では非常に特異な分野を専攻していたことに起因するのですが、国外ではこの意図や意志というものはごくごく一般的な教養ある人の中では当たり前であり、意思決定においてこれがないとまっとうではないです。

日本で、ある決定について、「それはどうしてですか？」という根拠を訊くことは野暮ということになっています。それはほぼ均質な文化的な基盤があるという前提が確立しているからですが、現在の日本において個々人の文化的な基盤がほぼ確定的に共通であると信じる根拠に乏しいと思います。ゆとりと称される存在は明らかに文化的な基盤が共通であるとは考えられない人への別称です。このカテゴリにはいる存在に対して、ただ闇雲に「若いヤツは」的な話をするのは、愚かしさの上塗りです。彼らも確かに生きてこの社会に存在しているのですから、その「貧弱」にみえる文化基盤でも問題はないのです。

話は戻りますが、意志や意図をもって何かを行うことは悪いことではないですし、それは非常に強い決定であると考えます。意志や意図はしばしば「悪いこと」をしたときには訊かれます。「どうしてそんなことをしたんだ！」など、見に覚えがあると思いますが、私からすればその理由が答えられるならば、その人は明確な意図をもって行っているので、容易く答えられますが、ただなんとなく行ってしまったというときに失敗する事は多いと思います。

つまり通常時は意志や意図を求められることがないのに、失敗した時だけ理由を訊かれることは、個人的に気分最悪です。意思決定をして、行動を起こす前でなく、その結果のみに対して詰問を行う姿勢は、非常に合理的でシステム的にも無駄がないのですが、それが常態化したときに十分な結果に対する責任をもつという姿勢が養えるのかは分かりません。それに失敗は失敗として既にマイナスでしかなくて、詰問の回答によってはさらにマイナスが膨らむとすれば、誰がまっとうに答えることができるようになりましょうか？

行動の意図や目的を問うことも必要ですし、成功、失敗にかかわらず、結果に対しても常に意見を求めることがこれからの在り方として必要ではないでしょうかねぇ。

どうもJudaです。
.net Frameworkをつかって、フォームをデザインするときにでるあの特別なコントローラーが気になります。
あれがとってもほしいのです。
考えられる方法は幾つかありますが、C#,VBがOOPと言えども、言語的にクラスの継承の間に割り込みはできないので、委譲のほうで問題を回避していくことが重要かもー。
コントロールを入れられるコントロール制御用のコンテナを用意して、そのコンテナに対して制御を加えるようにすれば、汎用的にコントロールを扱えますね。うん、というか、それ以外に思いつきません。
調べたところ、既にこのコントローラを開発した人もいるのですが、2003で作られているし、またこれに限っては車輪の再発明も幾分か自己のOOPへの理解や修練に役立つので少し試行してみる。

取り替えずコンテナをクラスで宣言します。描画の関係もあるので、Controlを継承した方が無難なので、継承する。ただここで考えるのは、
・これにコントロールを入れて、
・Mouse系のイベントを使うこと、
・Key系のイベントでの制御も許容すること。
・同時に周りのコントロールとの数値の関係性によって拘束がかかること。
・選択時には特別な描画処理を行うので、Paintイベントも書くこと。
意外と使い易いコンテナをつくるには問題がありそうだ。
コントロールをコンテナに格納したときに、格納したクラスの個別のマウスやキーのイベントをハックしないといけないので、これが若干気になりますねー。コンテナ格納後に個別のコントロールのイベントが生きていると困るので、殺しておきたいのですが、よくわからないのであとで調べておきますね。
たぶん内側を透明にしてZバッファの順序を入れ替える。もしくはフォーカスイベントが発生するとフォーカスを移すとかですけど、フォーカスのイベント内でフォーカスを移動させると予想外の動きをするので、あまりおすすめできません。以前、実験した際に、呼び出しが規則的に発生しないことを確認したので、フォーカスを制御するのは、確実性に疑問があるので、別の方法を模索するほうがいいです。
あとはコントロールが登録されているものを入れ替えてしまうかですが、これはデータの構造を勝手に書き換えることになるので、おすすめできません。汎用性にかけることは間違いないので、なるべく同一の階層性でイベントの登録のみで解決したいですね。
…別にコンテナを開発しなくても、イベントの登録、削除をうまく制御すれば、データ構造的な面では出来そうですが、すでに存在しているイベントとぶつかったり、そもそももとのイベントが駆動してしまう問題があるので、これはうまくいきそうにないです。
ここまでの問題点で一番大きいのは、コントロールに発生するイベントを一時的に殺して、それをバイパスして別のコントールに移すことができるのかどうかです。そのあとは、ここの機能を分割しながら実装していけば問題はなし。
初回ではなく、選択後つまりコンテナに入れられた後に、そのあとは独占的にコントロールを支配できなければいけません。なにか方法はないものでしょうか？

どうもJudaです。
今回はコンテンツとコンテナの話を。
コンテンツをオリジナルでユニークなそれ自体では複製できないモノとします。それが「なにか」ということについては議論しません。
コンテンツをコンテナに格納すれば、複製可能になるとします。またコンテナに格納されたコンテンツを、別のコンテナに移し替えるこが出来るかどうかは、コンテナの性質になります。
想定している対象物はDVDやMP3です。
コンテナからデータを取り出せないのでは意味がありませんが、このコンテナがコンテンツを完全に取り出せることは保証しません。ただコンテナの存在意義としてそれがあまりにはコンテンツを損傷させるのでは意味がありません。完全に復元可能なものを特別にロスレスという形容をする場合があります。この場合にロスはコンテンツが本来持つ性質を損失しないという意味です。
問題を局所化します。
DVDはコンテナであり、それが内包しているコンテンツが映像やデータになります。通常の販売者はコンテンツをコンテナにいれて、販売します。ただし、このときにコンテンツを売る気はさらさらないです。このコンテンツをコンテナにいれて複写して販売しているので、コンテンツを売ってしまうと困ります。
しかし購入者はコンテンツを購入したと思います。このコンテンツを取り出し、別のコンテナに入れること、複写という行為を含めて権利だと考えます。この時点で既に販売者と購入者の間で意見の相違があります。売買契約から考えると販売者が優位です。このことは既に周知だと思われます。
コンテンツを鑑賞させるけれども、別のコンテナの中にいれることを認めないということは、映画でも同じです。またラジオでも同じです。別のコンテナに入れるときに、コンテンツの作成者は対価を求めます。
さてさてややこしいのは、コンテナとコンテンツは、その構造が入れ子になりうることにあります。この性質のために本来のコンテンツの製作者と利用者の間に介在する存在があることが想定されます。これがもっともややこしい。
すべてのコンテンツの製作者に権利を認めると、その入れ子構造のせいで最終的な利用者以外はすべて権利を持つことになります。オリジナルのコンテンツとしての権利を持つ人ほどそれが無断でコンテナに入れられることに対して、対価請求の機会を損失します。
では本来のオリジナルのコンテンツの制作者からそのコンテンツの権利を手にいれるということは可能か？
これは今までの議論をすっ飛ばしているが、コンテンツの売買というコンテンツの本質に対する問いかけなのだが、これが著作権の本質に直結する。またオリジナルを誰が所有するのかということにもつながる。
オリジナルの所有の問題はもっともややこしい。同一性の問題にもつながり、そこには正統性の話も関わる。正統性の話は歴史の問題であり、そこまで来るならば、それが根ざした背景や環境、文化すらも範囲に入ってしまう。仮に問題を簡素にするなら、何を売っているのかぐらいだろう。
結論から言えば、売っているのはコンテンツをコンテナに詰めることの独占的な販売権だけだろう。
権利というものは、あとから生まれた人為的なものであることを心に止めて置くことが必要だし、それを踏みにじることの代償についてはもっと配慮すべきだ。

どうもJudaです。

最近ようやくAndroidとiPhoneの開発のエントランスのやってきました。

とりあえずそれぞれの環境設営について。

iPhoneではXCodeとiPhone SDKをつかって開発します。というか、Mac以外での開発は出来ないと思います。権利的な問題だと思うのですが、MacOSはApple以外の機器へのインストールを許諾していませんし、そのMacに付随するものとしてXCodeが提供されています。まぁ、最近は徐々に状況が変化してきていますが、それはおいておきましょう。（個人的にはVisualStudioもしくはEclipseでWindows上で開発できるといいなぁと）

まぁ、XCodeのインストールはApple Developer ConnectionでDownloadできるのでまぁ、それにしたがってもらえば大丈夫です。最新は XCode 3.2.1？でSnow Leopardが最低Verになるので、Leopardは3.1.4になると思います。

次にAndroid。こいつは結構厄介です。というか、厄介でした。JavaのVMが複数インストールされている場合には、それがいろいろと面倒なことを引き起こしてくれちゃうのでそれはおいおい。

とりあえず標準的な開発環境としてEclipseを選択します。この場合にさきほどのVMの設定が悪さをする場合があるので、うまく動かないときには、-vm　オプションでVMを指定すれば、Eclipseがうまく起動する、はず。とりあえず、こういうサイトのほうが詳しいので、こちらをどうぞ。EclipseならAndroid Plug-inが使えるので、導入を検討する価値アリです。

Eclipseが動くのを確認してからAndroidSDKを入れるほうが無難だと思います。

そしてAndroid SDKは本家からDownloadします。

その後はAndroid SDK.exeを起動するのですが、まず注意があります。起動させた場所にSDKの中身を持ってくるので、はじめから入れたい場所で起動することをオススメします。これはあとでEclipseでAndroid SDKへのパスを設定する部分があるので、そこを注意しないといけません。

それでまぁたぶんうまくSDKの実行ファイルからはうまく動かないので、Settingの「Force http://..」な項目をチェックしてRefreshするとたぶん該当するデータを手に入れることが出来るようになると思います。そしてこのインストール作業なのですが、結構失敗していたりするので、ログを確認して、何度かトライしてみて下さい。

インストールできたら、Eclipseと関連付けるためにWindowのPreferenceのAndroidの項目でSDKへのパスをさきほどインストールしたパスで指定すれば、文句は言われなくなります。

これで環境はほとんどできました。最後にAndroidはiPhoneと違いターゲットが多様なので、それにあわせたVirtualDeviceの作成が必要になります。本家のサンプル「Hello,Android」でAVDと表記されている項目はConsoleでの設定ですが、Eclipseで設定している場合、もしくはSDKの起動ファイルから起動できる「Android SDK and AVD Manager」を使用すればGUIで構築が出来ます。Virtual Devicesという項目がAVDの構築と管理を行ってくれます。AVDはAndroid Virtual Deviceの略称ですね。

本家のサンプルはAPI2で作るように書いてありますが、これは使うAPIで整合性が取れていればいいと思っていいと思います。あとサンプルをつくった後にRunすると思うのですが、ここにも注意があります。それは、「とにかく実行されるまで時間がかかる」ということです。Eclipseなどは実行をスムーズに行えるのですが、よくみるとステータスバーのシーケンスパーセンテージの上がりが遅いことが分かると思います。ここが特に不便ですが、分かっていれば、動かないと不安にならなくてすみます。

とりあえず環境設営はこんな感じです。

あとは各種サンプルを探すほうがよいと思います。

どうもJudaです。
2chまとめスレで「黄金の３日間」という単語が出て来た。マネージメントの基礎的な知識であるらしいがちょっと分かりにくいので調べてみた。
Googleの検索ででてくるのは、『黄金の三日間』であり、熊本の先生がまとめたサイトが見つかる。学校での学級運営のための教師へのマネジメントの心構えと実践方法が書かれている。
またAmazonで書籍を検索しても、学級運営のための書籍が出てくる。
文脈からすると「黄金の三日間」なるものは、学級運営のためのノウハウとして生まれ、それは始業式から始まる三日間においてルール作りを行うことが重要である。ということであろう。
これを実際のマネジメントまで一般化したものが、「黄金の三日間」を指すのだろう。
このことがおもしろいのは、学級運営という運営としての捉え方、またこの学級運営のノウハウが企業の小集団、プロジェクトに適応できるという洞察にある。
学級崩壊などが過去に世間をにぎわせたが、これは経営者である教師の失策ということになる。そして教師はただ学問を教えるだけの人材ではなく、同時に経営者としての手腕も問われる多義的な職業ということになる。このことは、注目に値すると思う。年の若い、担当クラスをもつ先生というのは、同世代のサラリーマンとは異なり管理者としてのスキルが問われる。この点は注目に値する。一般企業における管理者は、ある程度の年の者がやるのが、日本では一般的である。これは特定の業務に対しての理解無くしてマネジメントができないという発想に基づく話である。しかし昨今の高度に専門化していく業務においては、ここの管理者が配下の被管理者の業務について完全に理解することはまれであり、またそのために管理者は管理に特化すべきという認識が生まれている。
ここで話を教師に戻した場合、教師には割り振られている仕事は２種類あることになる。しかもそれぞれに専門的な知識が必要になる。このことを鑑みれば、教師という職業がいかに困難であるか分かる。一般企業でも４０人近い被管理者を完全に管理することのできる管理者がどれほどいるだろうか。またその管理者を育てられるだろうか。別の問題として、外部との交渉、つまりは保護者からのクレーム、学校組織内での管理者／被管理者関係など、多岐にわたる業務がある。このことだけでも教師という職業がいかに大変か分かる。
そして、「黄金の三日間」という現場での実践で確かに適応できる知識の創出やその知識の共有化を推進するあり方などは一般企業も取り入れることを検討してもいいと思う。この点を私はIT勉強会として行うと面白いと思う。それが含む企業的な問題については憂慮すべきものもある。

学校組織という特殊なマネジメント環境においてさまざまな管理方法が実験され、共有されていることはとても実験的に面白いと思う。被対象者においての、教育の一回性についてであるが、これは発展が線形で表現できないことからある程度は許容されるべきである。仮に線形である場合にも、人はさかのぼって評価を下しがちであるので、私はこの点からも許容すべきであると考える。それでも認められないのであれば、保護者が教育機関を選別することが必要である。公教育の現場に対してクレームを付けることは、その教育者の管理的なあり方からある程度までは認めるが、彼がプロであることを監視することにとどめるべきであると思う。未熟な管理者を教育するのは、学校組織の側であるので、外部からの強度の干渉は、教育の効率性追求を阻害すると考える。

公教育の現場において、一般企業からの参入を認めてもいるが、私は逆に教師を一般企業に管理者として導入する可能性も多いに期待したい。この人材の交流によって、より効率的な管理体制が探求されることを望む。

どうもJudaです。
いい。やっぱりHHKのLite2はコンセプトが明確でとても素敵だ。
すっきりしたキー配置にはいつも感心する。
またLite2では、十字キーにHome,End,PageUp,PageDownのFnが設定してあることが憎い。
僕はとにかくこのHHKが好きなのだ。これ以上理屈をいくら並べても、それは好きであるということをとらえ損なう。閉じ込めようとしても完全に捕まえきれない。ただ多く語ることで、それが囲んでいる領域をぼんやりととらえるだけ。HHKが好き。これがもっともよく表している。
HHKは最高だぜー、わー。

どうもJudaです。
今日は、「言語」という話を備忘録。
数学と音楽は、日常言語とは違う「言語」を持っていると思う。この場合の「言語」は一定の規約に準じる他者との相互理解のための意味コンテナ。数学の証明は、その作法を知らない者にとって、理解不能だ。音楽もたしなむ人にとっては、特定の旋律や進行がどういう意味合いを持つのかということを理解することもできるだろう。もっと一般化してしまえば、日常の会話でも使われている「言語」は特定の規約を知らなくては理解できないものになるだろう。
このときに、もっとも基礎となる「言語」というものは、もっともその「言語」を理解できる者が最大となるときの「言語」。使用効率がもっともよい者が基礎となるのだろう。これが標準となる。
標準をもとにいくつかの派生言語や、派生先での相互の翻訳がある。このときに、共通の根となるもっとも標準な「言語」を知れば、全てを知ることになると単純に考えることもできる。しかし派生が発生するという現象を鑑みれば、特定の事象を細分化し、他者と共有するために派生が行われていることが分かる。このときに、共通の根というのは非常に素朴なものだけを扱い、あまりにも漠然とし細分化されていないものとなる。この場合の派生関係は差異を進めることによって、もはや共通の根から派生したものとの関係性は薄くなる。これに対して、翻訳を行って、共通の変換規約を作り出しても、その変換は部分的にはうまくいくだろうが、一定以上の細分化が進んでいる場合には、翻訳不可能な局面が現れるはずである。それは、そもそもの派生が発生する契機に、コンセプトの相違に近いものである。
この変換によるロスは、「言語」固有の特質だ。またこのロスを語ることは、それが変換できないという変換可能であることを否定することによってしか、一方の「言語」では、表現できないのではない。
このときに、真に変換された無かった「言語」を理解するには、まったく別のものとして、新規に「言語」を習得する必要性がある。このことを自覚できずに、ロスの存在に気づくと、もどかしさを感じる。
この「言語」を意識、精神に置き換えたときにいかにしてこのロスを克服していくのだろうか。考えられる解は、共通の根まで戻り、再度双方の言語に双方の語を交換して登録を行うことだろう。ただ習得は非常に非連続的なものになる。ある意味ではコンセプトを破壊する。

仮に、これをクラスに置き換えた場合には、特にC++において、継承関係が完成されてるものに対して、新規に継承関係を動的にあるいはソースコードに直接記述することなしに追加していくことはできない。この流れでみたときに、Objective-Cの考え方はとても拡張性に富んでいて、洗練されたObjectOrientiedな言語設計である。もっともC++はオブジェクト指向でのプログラミングを許容する設計であり、複数のコンセプトが混在してる。だからオブジェクト指向への適応度の違いは、なぜC++とObjective-Cが存在しているのかということを再認識させる。このような違いに無自覚でいることは、その「言語」の本質を見失うことである。またその「言語」を使いこなしているのかという観点から言うと否と言わざるをえない。

ただし、この論法を人間に拡大してほしくはない。理由があって派生しているというのは、人工的なラベリングでの話だ。個々人の個別な身体の所有に関しては、その理由を提供するものではない。人間とクローンでは話は別だが、あくまでラベリングされた場合のみだ。

どうもJudaです。
事実として不幸自慢が日本で多いかどうかは知りませんが、自分はついつい根底にそういう含意のあることを話してしまう。私はこれを理性的には恥ずかしいことだと思っています。
なぜ恥ずかしいのか。それは、自分が愚かであることを周りに言い回っているからです。他の人が簡単にこなせるかもしれないことに自分は「これこれの苦労をしてやった」という。それは単純に効率が悪かったのです。そうではないとあなたは言うかもしれません。しかし「それはこのようにすれば実に簡単にできる」と言われたときに、胸がもやもやしてしまうだろう。苦労した自分を認めてほしいのに、その自分はのろまであったと指摘されるのである。このことにもやもやを抱いてしまう。自慢であるのにその本質が不幸に根を下ろしているので、その指摘に素直に従えなくなる。それはさらなる恥である。善意に対して、悪意をもって応えるのは、決して善きことではない。
しかしそれを知っていても、不幸自慢をする。それは不幸自慢が周りに許容される自慢であると言う側面もある。だが、許されるかもしれないが、その本質もネガティブだ。
できることなら、効率よく楽しくさまざまなことに取り組みたい。苦しいことが嫌いだということではなく、互いが互いを高めて引き上げるような環境が望ましいということだ。そのなかに、苦しいこともあるが、それは別にネガティブなことではない。方向転換のための抵抗と同じである。

どうもJudaです。

ドキュメンテーションコメントの重要性について語ろうと思います。

コメントをつけるといっても、どれぐらいの詳細を書き込むのか、あるいはもっと根本的に、何を書くのか、ということは突き詰めると意外と決まっていないことが多い。もっともちゃんとした規約があるところもあるのでしょうが、それらを新規に制定していこうと思うと、Try&Errorではドキュメントを書く人、主に開発者が死にますのでここは重要ですよ。
その勉強のために、一冊本を調達しました。
エンジニアのためのJavadoc再入門講座
この本はまだ途中までしか読んでいないのですが、なかなかためになります。Javadocについて書かれていますが、ここからメタ＜ドキュメンテーションコメント付け＞を引き出していこうと思っています。

なにがドキュメンテーションコメントを深くつきつめる動機になったのか。

それは、レガシー化しているコードを保守、拡張、利用するということが通例であるのに、それらについての一家言をもっている人が周りにいなくて、個人的に困ったことになっているからです。またコメントと同時的にテストやテスト手法、ソフトウェアのもつ責任範囲など、主にソースコードを利用し、改変、配布する場合におこる問題への対処を根とした調査ですね。まわりもリファクタという行為に関してはまだ認知度が高いみたいだが、これに付随するテストに関してはあまり重要視していない。そしてリファクタを行う前にテストを用意しないと行けないという罠。どう考えても、テストは重要だなぁ。と、それを改変するときには、同時にドキュメントを正確にしていかないといけませんなぁという流れです。

そして、一番の関心事は、すべての問題の責任を押し付けられる可能性があることに対して、なるべく強固な方法で防御をしないと、何をされるかわからない危険です。危険は回避したいです。

ドキュメンテーションコメントは、それを利用する人に向けてという意味合いが強いので、ほとんどはPublic 向けな規則ですが、クラスの再利用の問題もあるので、個人的にはProtected、Virtualなメソッドに対しては原則的に必要ですし、例外を投げる可能性のある関数にも必要だと思います。さらに話を広げますと、例外の基準。こちらも実装をしている段階で、いろいろとも問題になります。通常の処理ではありえないものが例外ですが、実装段階でそれらをトラップできるとなると、それは例外なのか？という疑問もあります。そこのところも含めて、上記の書籍には幾分かの指針が書かれていたので、それをもとに考えを深めていく。

どうもJudaです。
Growlというアプリケーションのユティリティキット？みたいなものを夜フクロウを経由して知りました。「確かにこういうのがほしいんだよー」といった感じの機能でして、Focusのないアプリケーションにくる新着情報などを小さな”控えめな”Windowで表示してくれる憎い機能なのです。とりあえず主張がうるさくないし、Desktop上の滞在時間も文字列を全部確認できるぐらいの時間なのでいい感じ。
また自分でアプリケーションから呼び出しができるみたいで（当たり前）、なんらかの状態変化を通知する必要のあるアプリケーションではこの機能の利用はSmartかなぁ。まだなにも触ってないから苦労とか分からないけど、ちょっと気に入った。

どうもJudaです。

問題はこれらは設計段階でうまく考えておかないといくらリファクタリングしても、ほしい機能を実装するめどを立てられなくなりそうなので、いろいろ書いておく。

PlugInの機能をどうやって管理するのか。
たぶんこれは大別して2種類。

内部に管理クラスをもつ実行ファイルがあり、それが内部で呼び出すPlugIn機能を利用する
外部に管理クラスをもった実行ファイルがあり、それが生成するDBを元にPlugIn機能を利用する

中間の形式が違うだけだ。入力:並べられたPlugIn、出力：呼び出し可能なPlugInの列挙。
マクロの問題を考えるなら、PlugInをインスタンス化できて、外部に公開されたメソッド名を使えば、そのPlugInをマクロで制御できるようにする構想も必要だ。

マクロ化するならば、内部的な関数の呼び出しも名前で呼べないといけないなぁ。
マクロを認めるなら、結局はスクリプトを認めることで、それならば内部にはParserが必要になる。この部分をPlugIn側にも認めるのか否かは。。。認めないといけないなぁ。

実際はそこまで考える必要性はないけれど、でもそこまで考えておかないと、未来の僕や僕の後を継ぐ人はかわいそうなコードをかわいそうなスケジュールでかわいそうな顔で変更したり、機能追加しないといけない。コメントをいくら書いても、できないものはできない。なので、イケテル設計(笑)をしないと。開発が嫌いになると困るので、十分調査していこう。

とりあえず、PlugInの管理は別の実行ファイルにしたい。それは、この機能は統合的には必要だけど、単体的には必要ない。だからDBもしくはCSV（Debug用）でPlugIn情報を表現する。

さて、ついでに必要になるのは、PlugInを単体でテストすることができる機能。これは開発者向けの必須ツールだ。最低限呼び出し可能かどうかのテストと、読み込んだデータに対して、期待したデータ処理ができるかが重要だ。できれば、テストデータをDefaultで用意できたり、ファイルの読み込みができたり、内部データを動的に表示したり、ログを取れたり、そういうのが絶対にその後の開発者の助けになるし、、、なにより自分がイライラしないだろう。うん、これは必要。

ほしい機能はとりあえず広げてみたけど、ざっくりまとめると

PlugInの呼び出し、実行（ｄｌｌ）
マクロ機能の呼び出し、実行、（変換機能：動的＋コンパイル済み）
PlugInのテストツール
マクロのテストツール
PlugInのマネージ機能
Debug用のお助けツールキット(オプション式)

あとは基本的な機能。これは、個々の実装系によるので、無視。
マクロ関係は基本の機能に依存するので、いったんは無視。
PlugInの部分の基本的な考え方は同じなので、これを優先的に作る。
マクロ機能に関しては、既存のスクリプト言語で代替可能であることが望ましい。
個人的にはIroｎPythonもしくはNativeのPython。大穴Scala？
PlugInの呼び出しは基本的にはShowDialog（）のような感じで、Dialogを出して、そこでパラメータを変更する。いくつかのメソッドをPlugIn側に公開する必要性があるので、ここを先に留意する。
後から来る人はかならずInterfaceの概念とCOMの概要は知っている必要性がある。この際にOptionとしてDebugのツールキットインターフェイスを引数に入れられるようにすると、、、、複雑度が上がるか。。。

DeｖKANに行ってきました。
まぁ、楽しい会でした。みんな開発愛にあふれていました。
個人的にはテスト工程の方々の苦悩やテスト工程の方々からの提案がとても身に染みました。やはり開発者の敵対関係にあるのは、特定の問題なのだと、より考えを明確にしました。
個人的には、開発ツールへの愛を語る方がいてもよかったかなぁと（じゃ自分でやれ？
LTも初めてみたのですが、とてもためになりました。
うんうん、ぜひぜひ関西にこの種が芽吹くことが願われます。（他人事？

次はコミュニティー参加は読書会へ行きたいなぁ。
読書会でどれぐらいの知識LVが求められるのか、知りたいなぁ。
#devkan2009

どうもJudaです。
PS3専用ゲーム　「The Last Guy」
いまさらこのゲームなのですが、前から気にはなっていました。ちなみに２０００円でした。

音楽はそれなりにいいのですが、後１分のときの音楽のちょっぴりうるさいことがなぁ。
ゲームの難易度は高めで、大人ゲーマーでも複数回のチャレンジが必要だと思います。ゆとりゲームではないので、小学生ではこのゲームをクリアしていくのは厳しいと思いました。

ゲームをやってみて思ったことは、スタミナへの配慮と列の長さの把握がかなり比重を占めていると思います。あとは敵の巡回経路などもありますが、一貫した法則や索敵範囲がゲーム中で分かりにくいので、これよりもより列とスタミナの把握が重要でと思いました。とりあえず敵がみにくいので、目が疲れます。

どうもJudaです。
最近はTwitterでつぶやきまくって、満足しているのですが、それではここの利用価値が上がらないので、割と重めな内容をPickUp

VB.NETで長時間運用するとメモリを圧迫してメモリリークを起こす問題がある。
http://support.microsoft.com/default.aspx?scid=kb;[ln];q313417
大学時代の製作物の中にこの問題にひっかかるものがあるので、コレに対処するべく調査中。

開発者として給料をいただいている身で思うことがある。
それは、プログラマに求められる以上のことだ。
自己を防衛するための機構の導入だ。
テストしかり、トレースしかり、デバッグプリントしかり、ログ機能しかり。
これらのものは、本来の開発ではオプションである。
しかしこれらを欠くと著しく後期の開発において欠損を生む。
近頃これをよく思う。

詳しくは後日説明を加えたいと思う。

それで後日談。
とりあえず.NETのガベージコレクタはそれほど賢くないので、なるべく明確にゴミを設定してやる必要がある。

それとその前に結果的にだが、プログラマはオブジェクトの所有権にその持ち方についてある程度留意する必要があるということだ。（スマートなポインタが売りだった気がするのだが。

結論としてDisposeのメソッドをもつことが最も確実なメモリ解放への配慮だったりする。
いくつかあるメモリへの配慮として、

変数にNothingをSetする。

配列をEraseする。

ちなみに配列のEraseはすべての要素にNothingを入れるのとほぼ同等らしいです。

ここからが問題ですが、クラスの確保した領域の解放ですが、ここはさりげなくC/C++とそれほど変わらないというのが調べてみた感じです。

循環参照はうまく解決できない。

Nothingを入れる前に入っている変数のサイズ分しか解放されないっぽい。

これは確かC/C++でmallocを行ったときに発生するプログラマのぼんやりから発生するメモリリークとそれほど変わらない。結局C/C++的な考え方を持ち込んでこないと問題を回避できないっぽい。
ここで、明確に破棄するための手段としてIDisposeの適応が考えられる。これによってプログラマは明示的に破棄方法を設定できる。これがもっとも問題の少ない解決法である。

これは憶測だが、Stringの解放が若干怪しい気がするが、基本型で用意されているので問題ないと思うが、C/C++的な考え方からするとこれは基本型ではないので、ちゃんと解放されるのか心配だ。

どうもJudaです。今日はコード管理について。
Mercurialというコードヴァージョン管理ソフトについてです。

まぁ、よく似たのにはGitがあります。
入門Mercurial Linux/Windows対応
Mercurial: The Definitive Guide
オライリーだとこれがありますけど、前述の書籍のほうが日本語だしいいかなぁって思います。
いまどきのソフトウェア会社でコード管理をしていない会社なんてほとんどないと思いますけど、個人ではまだやってないって言う人もいると思います。かくいう私も最近までは管理していませんでした。これは、単純にそういう管理面でのことを教えてくれる記事などがあまりないということが関係あると思います。しかし個人でのいかなるソースコードも資産として価値があると思います。だから管理しておくに越したことはありません。
ほかの管理ツールは
・Subversion
・Git
・Visual Source Safe
とかありますけど、個人で有料のものをつかっていくのはなかなか大変です。そもそも高いですし。その点で言うとオープンソースで開発されているSVNとかGit、Mercurialは有料ではないが、とても有用なプロジェクトの一つだと思います。
Mercurialの基本的な動きなどは、解説書に譲りますが、個人的に使うときに気づくと思うのですが、10Mbyte以上のデータは管理できないらしいです。あとGUI付のTortoise（トータス）系はWindowsのShellと融合して使いやすい反面、間違いを起こしやすいので注意。
あとは、管理といってもやることは簡単。でもちょっと違うことをおこなったときに、どうすればいいのだろうということは結構あります。実際にSubversionで”Working Copyを先にしてね”みたいなエラーは意味が分かりませんでした。もっとも説明書も読まずに使おうというのが間違っています。そして、その説明書が段階を踏んで説明されているわけではないので、解説書を手に入れると結構踏み台としていい感じです。
ちなみに日本語化をするととっても意味不明になります。そもそもの単語が意味分からないで使っているのに、それを日本語化しても分かりやすいわけはないので、なるべく英語のほうがいいです。そして検索の際にも英語で検索するほうが情報が手に入りやすいです。日本語で説明しているサイトや記事が充実していない状態ではなるべく言語パッチを当てないほうがいいです。
あとは大前提としては、英語の情報やプロジェクトのほうが多いので、それを読むことになれること。これは、もはや相対的な開発者の言語分布が英語が圧倒的に多いので、それを受け入れることである。嫌なら、日本語で同等か、それ以上のものを作るしかないです。まぁ、だから日本にはまだ市場があるんだけどね。
多くの事項は、Mercurial入門の日本語の本にあります。ぜひこれを買いましょう！話は戻って、SubversionとMercurial、Gitはなにが違うのか。それは情報の集積のやり方です。SubversionなどのCVSは中央集権的、Mercurialは分散型です。
中央集権的なSubversionは、すべてを管理するRepositoryがあります。個々のRepositoryをもつことは一般的ではありません。分散的なMercurialもRepositoryはあります。しかし個々のRepositoryがあるのです。中央集権的に振舞わせることもできますが、それではよさが活きません。分散型のよさは、中央が死んでいても、個々のレベルで情報を共有して、コード管理できます。これは、結構開発現場ではいいことなのです。たとえば、サーバがなにかの障害で使えなくなっても、個人のソースコードはいつもどおり管理できますし、中央を介せず、個々のレベルでもソースコードの同期を取れます。そのたびにマージがおきますが、このマージの方法も実に合理的です。
Subversionでは、UpdateしてMergeしてCommitします。MercurialはCommitしてPullしてMergeしてCommitしてPushします（たしか
重要なのは、自身の変更結果を自身でも保持しているので、途中で自分の変更がなくなったりしないのです。Subversionは結構マージでてこずると、マージ前に戻したいのに、戻せないことに気づきます。これは、ある意味絶望です。成果がパーなので。
ここらへんで、Mercurialの話は終わりますが、一番重要なのは、SubvesrsionとMercurialは共存できます。だから個人でMercurialを導入しても問題ありません。
そして、これはあくまで手段です、より効率よくソースコードを管理できるのであるならば、別の方法を採用するべきでしょう。というか、ちゃんとそこを理解しないと頭悪い感じになるなぁ。

どうもJudaです。
最近JPEGのDecoderを自前で用意しなくてはいけないので、大変な思いをしています。しかも特許がらみでなんだか情報も閉鎖的です。とりあえず、エントリをつくっておいて、後で情報を足しておきます。
もーめんどくせぇ。

どうもJudaです。
今回は、FinePix REAL 3D W1という商品がいいなぁと言うお話。
なにがいいのか、「ステレオ画像を手軽に取れるところ」。
今の映像業界的な流れは3-Dです、どうかんがえても。(もっとも過去にも3-Dが話題に上がったこともありましたが。)映画もディスプレイも3-Dです。そしてここにきて、3-Dカメラなるものが発売される（た）のです。
既存のシステムでは、シャッタータイミングがどうしてもずれたりするなどお手軽に3-D用のステレオ画像を取れませんでした。この問題などもろもろを制約条件をつけることによって解決したのが、FinePix REAL 3D W1でありまして。
+D media Lisestyle / http://plusd.itmedia.co.jp/lifestyle/articles/0907/22/news061.html
FinePix REAL 3D W1 (ヨドバシカメラ)/ http://www.yodobashi.com/ec/product/100000001001138914/index.html
ただ高画質なだけのカメラになんだかなぁと思っていたJudaは、「これは、おもしろい」と思いました。ただ再生形式や表現環境が著しく制限されているので、広く頒布しようとしている方には問題があるのかもしれませんが、ローカルなサークル内では楽しめるのではないでしょうか？

Emacsのメジャーバージョンアップがきました。
といっても、私はEmacsの信者ではありません。信念的にはViです。(ただでさえCtrlを多用する現状なのに、移動にもCtrlを押し続けなければならないのは苦痛です。といってもEmacsにCtrlでモードを切り替える機能があれば、、、なんて言い出すとViのほうがスマートｗ)ですが、なんにしてもめでたきこと。UNIXを代表する代表的なエディタがWindowsでしかも日本語環境でも起動するなんて夢みたいな話です。多くの互換プログラムがありましたが、本家が対応してくることによって、これまでとっつきづらいと思っていた人にも選択肢が解放されたと私は思いました。

テキストエディタについては人はその重要性に気づいていません。もっとも、日用品となったアプリケーションに普通の人は選択肢が存在する事を理解できません。ブラウザしかり、メモ帳しかり、OSしかり。この現象をあらわせる適切な用語を知らないのですが、習慣づけによって多様性がなくなっていくこと自体は淘汰で言い表せるのですが、この淘汰が発生していることに気づくことをなんと言い表すのでしょうか。淘汰状態を知覚するというのでしょうか。なんとなく哲学的感性の芽生えと類比して考えられるのですが、何度も言うようにこの感覚をあらわす適切な用語が思いつきません。

ともかくも、この気づきに至る人は一般のレールからは逸脱しました。気づいてしまったことで、その前提が脆弱なものであることに気づくのです。趣味の世界への入り口のようなものですが。。。またややこしいことに、この気づきそのものに気づくと、今あるさまざまなものの前提条件が砂上の楼閣になるのです。まぁ、確かにこれは哲学的な感性でしょう。デカルト的な懐疑とでも言えばいいのか。そうか、淘汰状態への気づきはつまりは前提条件によって選択肢が隠蔽されていることに気づくということで類比的に懐疑か。懐疑というメソッドを手に入れると知るものの大半へその懐疑を差し込めるようになります。前提条件を疑うという新たな手法を手に入れます。もっともこれをどこまで適応するのかという問題は再帰的に発生し、この根となるところの話までいくのならば、デカルトを頼ってその著書を読むべきでしょう。私は、これを手段として使うにとどめます。

この懐疑は、つまるところ前提条件を自ら意志的に組みなおすことを求めます。（哲学で言う意志的ということは人間的ということに言い換えられます、割と）気づいているからには、その前提条件を承認するのか、それとも否定するのかという問いかけが発生します。知ってしまうことによって必然的発生する問題です。またこの懐疑という手法は再帰的であるが故に、どこで再帰をやめて戻ってくるのかを規定する必要もあります。無邪気にすべてを無に還して、世を果敢無むをよし、あくまで手法として選択肢に加えるもよし。

趣味や奥義、追求の端緒は、懐疑だろう。そして満足を求める心は修羅の道。されど楽園にはもはや戻れるわけもなく、ただ東へ。

だから選択肢がなくなっていることに気づくのは、人間的。。。なのかなぁ。少なくともシステムの歯車から外れてしまっている

どうもJudaです。
世間的には優れたプログラマは道具を選ばないらしいのですが、私は俗物凡人なので入力インターフェイスもテキストエディタもこりこりで、言語やランチャやクリップボード、仮想Windowなどもつかっています。
入力インターフェイスは長期戦向きのFILCOのマジェスタッチ、職場向けのHHK Professional JP
テキストエディタは通常使いのMIFES8と開発用のVisualStudio、そして修練中のVi、Emacsです。
言語は、なるべくならばC/C++ではなくてC#、Perl、Python
ランチャは穏便にLaunchy、クリップボードはCLCL、仮想WindowはVirtualWindowです。
この導入群の制でALTとCtrlのキーは押しまくりです。

どうもJudaです。

今日は、TDD（Test Driven Design)について気づいたことを。

TDDは結局は終わりから始まりに戻るリバースエンジニアリングであり、それによって開発を行う方法だけど、これって通常は突然の仕様変更に耐えられるように作れるのか？または機能追加に。

事前に機能追加を見越して開発をするということは、テストケースからは推察できないと思うのだが、どうなのだろう。今はまだしっかりと理解していないが、直ぐに思いつく問題になりそうなものはそこかな。

あとはMDD（Model Driven Design)なんかも、仕様を元にデータモデルを考えて云々だと思うけど、仕様変更には、TDDよりは強いと思う。

ただ、一番いえるのは、仕様が変更されることは今までのものでは機能不全であるという烙印を押すのであるから、どんな場合でも厄介である。また冗長性で回避できるにしても限界があるし、想定の範囲内の修正でない場合も多い。

私はソフトウェアをなにかの類推や定型化して考えるには、まだまだ知らないこと、いつか現れる新しいことが多すぎて、いつ何をしゃべっても一定以上の付帯条件がついていて、どれにも銀の弾丸にはならないと考える。ただあるのは、開発者がより多くのツールと手段を知っていることで、それらに対応するのが唯一有効であると言える手法に思える。ただこれは何も示していないのと同じだが。

どうもJudaです。今回は新しいゲームの布教の話をします。

昨今のゲームではオンラインは当たり前になりつつあります。そのなかでPCゲームというカテゴリでの販売にはクローンの生成に問題があります。現在はこれらを海賊行為として取り締まっていく機運がありますが、個人的にはこれではユーザーがわざわざPCゲームを選んでくれているメリットの一つを奪うと考えます。それは、楽しいゲームをみつけて、それを仲間内でやろうとします。そのときには直ぐに仲間とゲームをやりたいのです。そのためにそれが契約違反であってもしてしまう可能性は極めて高いです。そのゲームをレビューするような段階ならなおさら。

そこで既に試みられているかもしれないのですが、この行為が仲間内で行われることを利用して、同一シリアルでのLAN Party利用を前提としたプレイスタイルを認めることを提案します。基本的にはゲームの仮想イメージを故意に流布させる人は、それ以外のものをも流布している可能性が高いので、法的意識云々のレベルで考慮にいれてもどうしようもありません。わかっているけど、一線を越えてしまう人のために限定的に同一ライセンス同士でのローカルマッチを認めるのはどうか、と。これはまだ案でしかないので、より詰めて考えないといけないのですが、新規のゲームほどレビューをしてもらえること、紹介してもらえることにかけるコストが大手に比べて大きくなります。そのためにソフトのロックも保守的になるのですが、あくまでそれらを広めようとする人に対して、より理解を示そうということが主眼です。利用者のいないゲームはただの自己満足でしかないので、可能であるならば、販売者側の立場と購入者側の立場でより妥当な線を提案できればと考えます。

PCでゲームをするという、欧米では普通のスタイルですが、日本国内ではなじみのないスタイルに対して、よい関係を気づいていくことが双方によいフィードバックをもたらすと思います。

このためにオンラインでの対戦のネットワーク構築の基盤となるライブラリの構築と認証システムを考えるのも、販売者よりの利用者の歩み寄りかなぁ、と。まぁ、企業からすれば横柄な利用者にしか見えませんが、それでもゲームは好きですし、よりゲームデザインのよいものをより多くの人と分かち合い、それを生み出してくださった開発者によりダイレクトに評価ならびに評価としての金銭が還元されるモデルがうまくうまれるといいなぁとおもいます。

どうもJudaです。
今日は、人工知能の話。

人々が本当に望んでいるのは、人工知能ではない。とても優秀な私だけの奴隷だ。
仮に人工知能が可能であるとすると、自身の意図していない行動を起こすようになることだ。自律的に活動するということだ。でも、人々が人工知能に期待するのは、人道的な奴隷だ。
空間を跳躍して、同時に離れた場所に点在する。遍くこの世界に存在することが究極の願いだろう。いわば、神である。
この目標を達成することに、知能はいらない。精密なフィードバック機構と規格化された外骨格だけが必要なのだ。機械はどこまでも末端神経の拡張でしかないので、この方面での拡張はもっとも人間的である。
自らの身体という鎖から放たれていることが目的であるので、この方向はとても利に適う。しかし別の欲求も認める。自分でない、自分と同等の存在の渇望。人は一人でできることなど限られる。議論やゲームなどの闘争に関するものは必然的に一人ではできない。
人は遊び相手、奴隷、代替品として人工知能を求めている。しかも自分と同等の知能でという制約付だ。その中で社会制度というものを考えるとなかなか面白いのではないだろうか。自己の制限付の代替品としての他者とか。
人工知能の究極のジレンマは、離散集合でしかどうしても処理ができないことだろう。

というわけで以下ネタばれ

単純にみて、泣けました。

シンジの葛藤や、アスカの苦悩、レイの心境の変化がふんだんに盛り込まれていて、今までのエヴァとは違うものとなっていました。まぁ、悪く言うとガイナック的な演出が多くなりました。それは特に後半に凝縮されているのですが、いささかやりすぎな演出があったと思います。宣伝も大々的に行ったサブカルチャとしてのエヴァから大衆向けのエヴァへの変化という点では正解なのだと思うのですが、後半の戦闘シーンに関してはもっとトーンを落としてもよかったのかもなぁと思います。

本当はべた褒めしたいです。アスカの心理描写がとても現代的なものに変わっていること。アスカがとってもキュートな演出できつさがぼかされていること。まぁとにかくアスカがかわいいんだ。（ぇ
まぁ、アスカとレイの描写がことごと古い時代とは変わっていること。それがいいことか悪いことかは瑣末な問題で、本当に受け取るべきは今回提示されたエヴァであり、これは古い時代の誰もを悩ませた混沌に満ちていたエヴァとは違う。あの行き場のなさとそれでも抗うしかない自己との拮抗のような詩的な世界観から、人から神へと昇華する神話的な世界観になってきています。エヴァというアニメ界の金字塔に求められている期待に対する回答としては、上等だと思います。

ただ着目したいのは、
なぜ物語はシフトしたのか？
なぜ大筋から変革を加えられたのか？
時間が流れて、要求されるものが変わったから？
それとも、これが本来の結末なのか？

エヴァの世界観を現代風にアレンジしなおしても、どうしても変えられなかったのは、"インターネットの導入"だと思う。携帯電話やノートPCがでてくるが、インターネットの存在は明らかにならない。彼らの世界にはそれがないと考えるのが自然だ。あの世界にはGoogleは生まれていない。mixiもブログもない。知識は本や口承で伝わるのだ。世界はつながっていないのだ。

なぜエヴァの結末は変わったのか？私の答えは、インターネットが生まれたからだ。この発明のせいで人類補完計画の結末は塗り替えられざるを得ないのだと思う。今すでに人々はつながっている。知識は共有されている。一つのネットワークを作り出している。ネットがない世界を、ネットがある世界の人が見ていながら、人類補完計画の結末を納得させるにはどうするのか？これに立ち向かうのか、それともこの問題を回避するのかは、これからの話だ。たぶんエヴァの新しい世界では人類補完計画は発動しない。あの結末はネットのない時代の孤立と取れる。ならば、結末はどうするのか。ハッピーエンドにしてしまうのか？

あと気になるのは、今回のエヴァはよく精神汚染されていると思う。なにかのメタファー？

と、難しいことも書いたけど、普通に見れば楽しめます。熱いです！

どうもJudaです。
今回の記事はインターフェイスについて考えます。

結論から言うともっとも汎用的なものがもっとも便利です。しかし、そのキーボードには潜在的な健康リスクや打鍵速度の限界が存在しているとします。そのときに、自分のキーボードだけでもそれを回避しようという考えが生まれるかもしれません。インターフェイスの重要性への気付きです。

インターフェイスの基礎はそれを通じての他者間の交通があることです。その交通が円滑に行えることは、交通量の増大をもたらします。古いタイプライタがQWERTYを採用した背景には交通量による制限がありました。あまり早く打鍵すると、交通量が増えすぎて入力が渋滞するのです。現在のキーボード入力のために用意されているパスではこのような交通渋滞は発生しません。つまりはQWERTYに固執しなければならないハード的な制約はないのです。

キーボードに求められるインターフェイスの要求は、手元を見ずに話すような自然さで入力を行えることでしょう。日本の携帯電話は固定電話のインターフェイスを踏襲しています。これに対してiPhoneは、キーボードのインターフェイスを踏襲しています。一部は固定電話のインターフェイスですが。ここでも結局は既存のインターフェイスを変革させることはできませんでした。インターフェイスは習得することに抵抗が大きいのです。

しかし習慣化されたインターフェイス利用への前に存在した学習期間がどのインターフェイスにも必要なことに留意してもらえば、対等にそれぞれのインターフェイスを考えることができます。またそのあとの利点については、なるべく伏せておきます。この点に関しては、趣味の話なので、個人の信条が至上です。ただここで考えるのは、優れたインターフェイスを追求するという試みです。

携帯電話に話を特殊化します。このときに入力インターフェイスが固定電話と同じであることは至極もっともです。iPhoneのPCキーボード踏襲は完全にMailやBrowseでの使用が前提です。この基盤の違いがインターフェイスを決定しています。日本の携帯はi-modeなどのネット利用のBrowseを普及させる戦略をとりましたが、結局インターフェイスは電話のままでした。私はこれは使いにくいと思います。もともと意図されていないインターフェイスを使わされているので、不便であるはずなのです。しかし現在この入力系は基本です。これを強制する理由は電話利用におけるキープッシュです。あとは携帯のための小型化のためにインターフェイスに課せられる制約は大きいものであったと思います。

そしてiPhoneでBrowseにはなじみのQWERTYを持ってきましたが、今度はそれを使うBrowserが携帯での利用を本気で考えてはいなかったことですかね。あんな小さい画面でPC並みの情報を得ることには無理があります。すべての機能が統合されていません。ちぐはぐな感じがします。このことにもきっとDesignerは気付いていると思います。

携帯自体が個人間のインターフェイスとして機能しています。電話、メール、ブラウズの機能を凝縮したインターフェイス端末です。電話とメール・ブラウズには使う感覚に違いがあります。電話は音声、メールなどは文字です。携帯の役割が次第にメールなどの文字系統に変わっていくのならば、インターフェイスがキーボード配列になっていくのは、自然であると思います。しかし携帯端末にPCのキーボードのような役割をもたせつつ、PCとは異なるインターフェイスの開発が求められます。今度は空間的な制約がインターフェイスに制限を課すのです。

そのなかで私はiPhoneのタッチしているとスライドする入力方式はとてもスマートであると思います。ただし入力精度にまだ問題が残っているのですが、あの考え方は素敵です。ですが、完全なブレイクスルーにはいたらないと思います。あれでもまだ入力しにくいのです。ただタッチスクリーンによる入力インターフェイスは、レイアウトが自由ですし、開発の制約が少ないので、さまざまインターフェイスがうまれてくることを期待します。

このときに、私が重要だと考えるのは、２つです。

片手で入力が完結すること。（基本的に携帯は片手で使用）
1.７５ステップで入力できること。（めんどくさいのいまいち）
できればさらにコンパクトにおさまること（画面的な制約）

習得のしやすさは根本的な問題ではなくて、とっつきやすさでしかないのです。

どうもJudaです。
最近業務とゲームが忙しくてサボってしまいました。
今日はCVSの話

CVSのレポジトリを終えるにはどうするのがよいのか？
コレに関しては誰も書いてくれていないので、僕もかけない。
今は関連する情報を調査中です。
とりあえず自分のソースコードのバージョンの安全性を保証するためにこれを慣習化するまで使ってみる。
同時にメモリーリークを起こすプログラムの見直しと対策。
またはリファクタリングによる整理を行う予定。
詳しくは、また今度、とにかく今はマシーンが調子悪い

PCの前に座っているプログラマのみが開発をしている。
これは幻想です。PCの前に座っているのは、しようがなくコーディングをしているときだけです。基本的には遊んでいるように見えます。ええ、見えますとも。
別に会社に来なくても開発は出来ます。ただPCの前に座っているほうが効率がいいのは確かです。だからといって、仕事をしているわけではありません。精神的欠席って奴です。場合によっては精神的退社ですよｗ
熟練プログラマはどんな状況下でも開発が出来る。（ただしコークのない世界では無理かもねｗ）それでは非熟練プログラマはどうすれば開発が出来るのか？そりゃ、長くPCの前に座って、しかも集中できる環境でしょうよ。（それがベッドサイドかもしれないし、公園のベンチや喫煙所かもしれないｗ）
開発の経験のない人は、その姿を怠惰だという。まぁ、リラックスして仕事をしていると怠惰だといわれるならそれはそうかもしれない。でも首が絞まる紐を首にぶら下げて、窮屈な白い拘束具をきて腰の痛くなるイスに９時間座っていることが仕事というなら、それも良いだろう。まぁたいていの人は嫌がると思うが。（もちろん私も嫌だｗ）
本来重要なのは、生産物であり、その過程を評価するにしても、それは効率のよいやり方の追求に関してであり、高品質の生産物を生成する過程でリラックスタイムがいくらあってもそれは咎められることではない。それを批判するのは、「苦痛によっているマゾヒスト」が普通の人間に苦痛が快楽だと自分の性癖を押し付けるようなものだ。世の中には「苦痛を与えて苦しめるのが好きなサディスティックな上司」というものもいるが、私はそれも嫌だ。（もっともSとMの相性は抜群なので、そういう組み合わせは幸せになれるだろうがｗ）
もっともそのような苦痛でソースコードが洗練されることなどない。あるのは、みにくく、保守のしにくい奇形コードを納期に間に合わせるために生成することだけだ。プログラミングは知的生産であり、職業小説家のようなものだ。それも頻繁に合作をする作家集団だ。こいつらに早く書けといっても、書ける訳がない。売り物にならないものがほしいならDummyデータを葉注すればいい。みんなよろこんで、凝りに凝ったDummyデータを発明するだろう。

重要なのは、互いに強力や連携を必要としている事実だ。プログラマは生産を担当しているので、納期を極力守る。また守るのがよいことだと思っている。しかし明らかな短納期については、事情が違うが、頑張る。なぜならプログラマは自発的にはどこまでもマゾヒスティックだから。しかし他人から強制されることに対する拒否は強い。特に非開発者の無理解な注文や怒声には。
非開発者があせるのは分かる。彼らはなにも自ら作るすべを持たないからだ。もっとも持っているときには、よりあせるのだがｗ

本音を語る。
そう語っている時点で嘘かもしれない。そのことを明言しなくてはいけないことが悲しい。

間接的利害関係にあるものには本音を決して語ってはいけない。本当に利害関係にあるものに対して、それを語ることは実に狭い中で物事が解決するので、いらない心配がいりません。でもほかの誰かが介入したときには、その発言は訂正や補足ができません。

いまさら気づかされました。

だから私は本音を語ると言って、語るもので「本音」であるものは何もないのです。もはやあるのは、本音を語ると言って、誰かを誘導するための言葉のみです。本当はそういう振る舞いをしたくはないのですが、意図しない局面で秘密を公開されることを防ぐには、公開されている言葉について管理するしかないのです。誰しもが、他人の利益を守るようには振る舞ってはないのです。秘密の共有は仲間を増やすためには必要ですが、それがアキレス腱や弱点になるぐらいならば、いっさいの不利な要素を公開する必要性はありません。

なにもこれが不誠実だとは思いません。もし誰かがそれを言うならば、「私の本音が意図しない形で他人に伝わるかもしれない可能性を考慮せずに他人の発言を引用する貴方の存在が不誠実だ」と言わざるを得ない。むしろこのようなことを考えもせずに生きているくせに不誠実を語るなと「本音」をぶちまけたくなります。そして何も考えていないからこそ、わたしの発言の真意は結局は伝わらず、頭の固いやつということになります。他人に自分の発言が理解してもらえると期待する私のありふれた期待はもろくも崩れ去るのです。
よく考える人は、よくよく自分から発言することを嫌うのだなぁと思います。他人に言質を取られる不測の事態を防ぐには、それが一番です。

もはや酒など飲んで自身の正体を失う価値もなく、他者と「本音」で語り合うなど無意味です。私はそれを語りませんし、相手がそれを語るからと言って、私が自身の本音を語るべき理由になりません。問題は相手が何を語るのかです。それを誰一人、相手ですら保証できないのですから、自身を守るためには誰かに何一つ本音を語る理由がありません。

私が語れる本音とは、まったく業務に関係ないことや、自身の趣味の話、プログラミングの手法、設計や言語特性しかありません。他人はこのような私を「面白みのない人間」と評するでしょうけど、それを説明しても理解されると思えないので、またわかったとしても、本当の意図、「誰にもしゃべらずに墓場までもっていけ」を解してくれるとはまったく思えない。
だから私は他人が心底どうでもいいです。
だから「ファミリー」と自分が認めるものへの協力や援助は、無尽蔵です。
私はXXXxの人を「ファミリー」だとはいっさい思いませんけど。。。

どうもJudaです。
今回はC++の所有権の問題について。この話は開発者にとってはもはや古典的であり、解決策も見つけられた基本的な事象です。
そのことについて、少しだけ反省交じりの後日談を書きます。

C++における所有権の問題というのは、アロケーションに関する問題である。つまりは動的領域確保によってヒープ領域に作られた領域を誰が所有して、それを最終的に開放するのかという問題である。
これに関しては、C++は特に何もしてはくれない。ただnewとdeleteをキーワードとして提供しているにすぎず、管理してはくれない。
大規模プログラムになるとこの問題はソースコードのモジュールごとの凝集性や普遍性の問題のなかで爆弾となる。誰がその領域を開放するのか。
この問題に対する解決策はすでにあり、BoostのSmartPointerなどを参照してみるのが、一番よいだろう。
この問題に対して、どのように考えるのかということを少し提起したい。
領域の開放をしないと、いつまでその領域が使えないという特性をもっているので、そのような領域でないという前提を排して、誰がという点に焦点をあてて考える。

・明示的にプログラマ
・暗黙的にプログラマ
・明示的にアプリケーション
・暗黙的にアプリケーション

軸を明確にすると設計者か実行環境か？あるいは言語特性か、特性ではないか？

C++という言語に話をあわせると、言語特性として、確保された領域を管理はしていないので、特性ではない。また実行環境でもこの開放をサポートしているのか、していないのかは、不明確だ。故に、プログラマに任されている、現状は。
しかし、この明示的にという部分は確かに多くの制御の自由が与えられているので、それはとても助かる。しかしこれは煩雑さの元でもある。抽象度の関連で、この領域の開放はより機械よりのアプローチである。期待される動きは、誰も使わなくなったら解放する、である。
そうであるので、このためには言語特性ではないので、ポインタをクラス化して、一枚層をかませるのである。これがスマートポインタにあたる。これによって、生のポインタと実際の使用している局面をつなぐクラスの必要性が理解される。また、この中間層の発明によって、より柔軟な解放シーケンスを提供できる可能性を提示する。
Boostの優良なライブラリの機能であるSmartPointerを知っておくことは実に重要だ。どこでも好きにつかえるライセンスだけど、中身を知っておく、使い方を知っておくことはとても有意義だ。まぁ、それが意外に大変です。なぜ基本的に与えられていないのだー。

そして実にC++という言語は、自由だ。（ｗ
自由すぎて、涙でる(ｗ

C++というものが如何なるものであるのかということに対して、最近の私は一つの信念をもっている。それは、C++は荒れた大地を提供するもので、そこで利用するものは神であるプログラマが多くを提供する必要があり、それを用いて構築物を作るしかない。
C#は、森を提供してくれている。だが荒地を使うには、煩雑で一度森を焼かなくてはならない。
この違いの表現は使ったものなら分かってもらえると思う。C++も神としてのプログラマが世界構築になれているなら、多くのものははじめから持ってこれるが、それは本当に万人と共通なのかどうか、という点では無理でしかない。

洗濯という行為すら奥が深い。

クリーニング屋という専門職の存在を人々は軽視している。洗濯という日常の作業の専門家ということで大したことがないと思っているのだろう。でももっとも洗濯に精通しているのはクリーニング屋だ。
洗濯は汚れを落とすことが重要である。汚れを落とす。これは簡単なように見えて難しい。たとえば、ワイシャツの汗じみ。地味な例であるが、これほどクリーニング屋の技術の高さを知ることはない。あの黒い線のシミ。洗い上げの洗濯にあの線が残っているときの敗北感を理解いただけるだろうか。別のものでいうと血液のシミ。このシミもただ洗い流すだけでは黄色のまだらが残ってしまう。洗濯後に汚れが落ちていないときの失望は計り知れない。
日常的な洗濯という行為も満足に出来ないことは非常に不満だ。この問題を解決するために私たちに出来るのは、さまざまな洗剤や方法を試して汚れを落とすことである。もう一つは専門家に頼むことである。
いかな主婦主夫といえどもクリーニング屋に匹敵する洗濯テクをもつものはそうはあるまい。掃除も然り、料理も然り。
だから、これが出来る人が好まれることは本来必定であろう。日常におけるささいな行為のそれぞれを正当にやって見せること。これほど本来は賞賛させるべき行為はない。あるべきものがあるべき姿であるということは、それが日常的であるほど、行為の価値に対して反比例して評価されない。
仕事が出来るということはそれによって社会によりよく貢献しているという程度の意味しかない。本来的に全体的なパイの絶対量は変化しない。人々はそれをただ切り分けているだけだ。金銭はそれに付帯する評価と渾然一体の対価である。だからそれが普遍化すれば、評価は落ち、対価として手に入れられる金銭は目減りする。
だからこそ人は常に目新しいものを探していく。しかしここで忘れてはならないのは、評価の下がったそれが不要にならないことである。誰か何らかの形で代替していくものである。日常に溶け込んでいったものの中にもそれは多い。正しい評価ということをいうのであるならば、日常品の有用性やその価値、その意義を何度も語るべきである。それは不当な評価というものだ。しかし評価の本質は不平等だ。AがBより優れているという形でしか評価は成立しない。絶対の基準など一切役に立たない。そんなことを語っても、一向に「等しく」評価されていることにはならない。
もし仮に誰かが正義や等しさを語るなら、語られなくなったものについても語るべきである。語られているもののみで世界は出来ているのではない。AとBの対立軸では単純すぎるのだ。A、Bと変則的な非ABがあるのだ。A、Bにうまくはまらない物事一般という第三領域が。そしてA,Bよりもそれははるかに大きい。

洗濯という行為は、掃除という行為は、尊いのだ。またここで語られない多くの業も尊いのだ。だが遍く尊いということは、何一つ特別なものがなく、どれも尊くないのだ。でもここで注目すべきは、その尊いのだとおもう傾向性だ。これだけが前者と後者を分断する。なにも定点的な考えが全てではない。時系列的な「厚み」を持った判断というものも重要なのだ。

他人の構築したライブラリを読んでいると、
どうしても
「どうしてこんなに効率の悪いアルゴリズムを採用しているのだろう」
「このアルゴリズムはすげーかっこいい」
とか価値判断が含まれてしまいます。

価値判断というのは、
このコードのほうが正しいという感覚を持たせてしまいます。

しかし他人のコードを読むときにはこの感覚は危険です。
正しくそのライブラリの意図するところを理解できないし
自分のもっている尺度のせいで
正しくアルゴリズムを理解するときの障壁が多くなります。

このときには、進んで自分というものを押し殺す必要が出てきます。
他人の考えを推測するというのも読解を早める効能がありますが、それが間違っていたときの代償が大きすぎます。
だからとりあえず自分を捨てて、没入することが必要だと考えます。

んでもって、学生さんは他人のソースコードを読むことになれていないので、
他人の読みやすいコードを書くという感覚がない。
これに関しては、日本の様々な技術者が言っていると思いました。

んで、一人でもできる他人が書いたように感じるソースコードの用意の仕方。
単純に自分が書いた古いコードを最後まで読んでみる訓練をすればいいと思う。
そのときに、つけたコメント基準が自分の欲しいと思うコメント基準だし、
たぶんそれをくりかえず度にソースコードのまとめ方もわかると思う。
ただしこれには時間がかかるので、学生の学習向きではないのかもしれないけど、
効果的なやり方だと思います。

時間差レビューマジおすすめ！

C++はカプセル化することはまったく考えられていない。としか思えない。
Headerにprivateなものを記述してしまうとそれは内部に持っていることを宣言しているのと変わらない。ただアクセスは出来ませんという意味しかない。
C++のHeaderを渡さないと変数のMapが分からないという性質から、仕方がないけど、privateなものの宣言にははなはだ向かない。
ということは、C++はデータの構造をさらすことを重要と考えるほかない。基本はstructでしかないので、そのことを念頭において考えると、データの凝集性と抽象度が重要に思える。そして何よりもPropertyなどのカプセル化に関して重要なパラメータのためのインターフェイスはおいておかれているので、片道的なアクセス方法以外を宣言する必要性がない。そして、あまりにプロパティの宣言が煩雑なので、関数の内部で、自身が使う変数が妥当であるのかということを調べる共通の関数を作っておくべきであろう。
あとは関数についてはあいまいさがないようにすべきである。内部を全て知ってもらうつもりでないならば、なおさらである。関数の動詞部分と修飾部分で動詞と判断できるものが重複していると混沌を極めるのでこれに留意したい。

また別件だが、TextEditorを買った。
MIFESというMEGASOFT社製の製品である。DOSの時代からの古参である。
従来のポータビリティとライセンシングとの関連上フリーのテキストエディタに比べて使いにくいかなぁと思う。しかし強力な検索機能やカスタマイズ性があるので、トレードオフかなぁ。
ただ表示の美しさは驚きに値する。
正直な話、Editorとしての機能をVSが開放してくれるといいのですけどね。

全ての努力が水泡と化していく感覚が私を苦しめる。ただ、走り続けることでしか、保てない。

たとえば、列挙型の中身を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
折りたたみ自転車。
最高にクールだとおもいませんか？
折りたためることを知ったときの驚きは、久しぶりでした。
久しぶりに驚きました。久しぶりにかっこいいと思いました。
デザインってこういうのですよね。

どうも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なるものがある。
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なのは、多言語対応がややこしさを持ち込むのからだろう

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

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

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

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

語句説明

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と近いだろう…

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

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

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

XCodeを使っての開発環境について少しお話をします。
結論から言ってVisualStudioとはコンセプトが違うと思った。
そしてそれはあくまで定量的なものにはよらない。ただの推論。

基本的にWindowsは洗練とはかけ離れている。しかしそれが悪いという訳でない。
いくつもの選択肢から自らに適した方法を選びとることができる。
一方のMacは非常に洗練されている。しかしそれがいいという訳ではない。
ある特定の推奨される方法にとっては最適なものを提供するが、それに合致しないものには関与しない。
VisualStudioは基本的に何でもありの機能の見本市と化している。
一方のXCodeは非常に整ったあるやり方を提示している。
さてこのときにそのツールについて学習しやすいのはどちらでしょうか？
答えはVS。母体数の違いとさらにいうとその操作の選択肢の多さから多くの人がいろいろなところで情報をあげている。XCodeは母体数が少ないこととその操作の洗練されているが故にオフィシャルのもので十分であり、それ以外の情報があまりない。
XCodeでコードを組むことはそれなりに簡単である。しかしVisual Studioでならされた開発の癖を抜ききるのはなかなか難しい。むしろその違いに戸惑うばかりである。Edit Modeの見やすさはXCodeであるが、開発のしやすさに関しては、現状ではVSだ。クラスの生成の半自動化ができていないので、XCodeに若干不満がある。またライブラリの追加や、名前空間の宣言、開発環境に事前に登録しておきたい項目（Visual Studioで使っていたライブラリ）の登録方法がよくわからない。つまり道具としてXCodeになれていないので、その真価を評価しきれていない。

ただ初心者プログラマがMacで始めるのは正直どうなのかと思う。
かといってUNIX系のEmac？でいいのかは知らない。

買いました。
Exceptional C++―47のクイズ形式によるプログラム問題と解法 (C++ in‐Depth Series)
Accelerated C++―効率的なプログラミングのための新しい定跡 (C++ In Depth Series)
Modern C++ Design―ジェネリック・プログラミングおよびデザイン・パターンを利用するための究極のテンプレート
合計で７０００円超也
ちょいと本気で業務でC++使っていくなら、知っておくべきかと思って買ってみました。

"こんな本を読まなくてもC++ぐらい使えるようになる。"
ごもっともです。８割方もう趣味です。言語マニアですな。何度も言うけど、本当はC++よりもC#を愛しています。でも業務で使えないので、仕方なくC++をやっています、今は。まぁ使っていくと、それほど面倒でもなくなってきました。ですが、どうしてもC#の便利さに慣れているので、Propertyの存在やtry-catch-finallyの便利さが懐かしいです。あとは超強力リファクタリング機能。言語的な特性よりも開発環境からのサポートの強力さがC#Loveを推進しています。
現在はいまひとつ分かっていないC++のTemplate機能とSTL、Boostの使える機能。この二つをおさえれば、もう少し開発が楽になると思うので、前述の本を買いました。Boostの本は中古がなかったので、本屋で買おうと思っています。C#のほうはすでにオライリー本があるので、これ以上は買いませんが、いまだに効率的な例外処理クラスとカスタム属性がつかめていません。あとはラムダとヴァリアント。C#3.0を早いうちに慣れさせたいのですが、C#2.0ですら使わせてもらえないので、遅遅として進まないのが目下の問題です。

先日、同期と一緒に食事に行った帰りに、本屋に寄った。
そのときに、プログラムの棚で楽しそうに本を選んでいたら、
「業務外でプログラムの勉強とかやる気しねーよ」と同期は言った。
まぁ、なんということはないごくごくありきたりの一言だ。業務外で勉強とか、働くとか、俺も嫌だ。なるべく避けたい。

私にはひとつ思うことがある…いや、いっぱいあるけど。
プログラムは経験と知識が物をいう。知らんものは書けないし、使えない技術じゃ意味がない。業務で楽をするために時間外で努力したり勉強をする。すべては楽をするために努力する。意味がちぐはぐかもしれないが、そういうものだ。全ては楽をするためだ。

楽をしているとたぶんもっとおもしろそうなことができるようになるし、くだらないことに関わらなくてもすむ。仕事の抽象度があがってくると余力が生まれてくると思う。

現在の仕事での評価の仕方が時間重視で計算されているので、それはとても大きな意味をもつ。仕事量が決まっていて、それに対して払われる金額が決まっていて、変数は時間しかない。このときに時間が短くなればなるほど、時間当たりの価値は上がる。より効率的労働しているということになる。企業としてはそれは望ましいことだし、時間給で労働力を購入しているので、効率的に労働してくれることによってより大きな儲けになる。ただこのときに、労働者は本当は逆に動きたいのだ。時間給であるが故に働き如何に関わらず給料は固定だ。なるべく労働しないようにするだろう。これは効率的に働くことへの動機付けがなされていないときには当たり前だろう。企業側はこの部分に対してより敏感になるべきだし、そのための動機付けを模索するべきだ。

個人的には基礎研究としての、ライブラリ構築やフレームワークの開発、チュートリアルやサンプルの充実がもっとも大きな効率を生むので、そういうことへの評価をしてもらいたいと思う。また環境的な面からもなるべく労働者が働きやすいように調整を行うべきだろう。あとは一度良質化した労働環境を下げることは、大きなマイナスを生む。通常ならそれは会社が傾いていることをあらわしているので、可能な限りそれはしないほうがいい。それまであったものがなくなることへの不満は予想以上に大きい。

話は戻るがライブラリの構築やまた基礎研究の整理は、長期的な目で見て、それらの情報を部分的にでも公開していくことは価値がある。現在ならHPへの掲載、あるいは書籍の発行である。勉強会を開くこともよいだろう。類似したことに関心のある人が集まるようになれば、それらの研究への価値が上がり、めぐりめぐって会社の価値が向上する。HPでの公開に関して言えば、サイトを利用する人から新たな情報の提供や提案がなされる可能性がある。直接的には金にはならないが、間接的に営業行為に結びつく可能性がある。なによりも名前を知ってもらえることは大きな意味がある。

HPの例でいえば、企業が情報を公開していることは、中小では稀である。しかしそこでしっかりとした情報が公開されていることは、稀であるが故にとても目につく。とても優位な広告活動である。しかも能動的なアクセスさせている点で、さらに情報の伝達率が高い。

事実、業務中もネットを通じて情報を集めることが多い。これらはすべて先人が情報をアクセス可能な状態にしてくれているからであり、この恩恵をただ受けているのでは、ただのROMでしかなく、それは道義的に下位の状態であると思う。

業務的にはライブラリの構築や調査内容を平易な書類にまとめることにも留意されているが、それによる評価の基準があいまいであるし、その情報を利用する範囲がわからない。また現在それらが使用可能な状態であるのか、それがどこにあるのかが不明確である。（なんでも訊けっていうけど、みんな忙しそうにしているから、訊けないですよ？）

さらにいうとどのライブラリの使用が推奨されているのか、またどのレベルでの開発が求められているのかを明確に示すことは、ある程度プログラムを組める人に対する指示としては妥当だと思われる。それは、そのレベルにあると思われう人は、自らライブラリを探してくるだろうし、プログラムを構築する際の選択肢も初心者に比べて多様になっていると思う。また真っ当なプログラマは「車輪の再発明」をしたくないものだ。つまりはなるべく公開されているフリーの外部ライブラリを使うとする。そのため、選択肢を制限するために、それらを指示することは妥当である。またその理由を説明することはプログラマにフラストレーションを溜めないために必要であると思う。「車輪の再発明」はなるべく避けたい。しかしそれが高速化、信頼性の向上である場合には、それは再発明ではなく、改良になる。これが重要である。再発明の強要ほど真っ当なプログラマを苦しめるものはないだろう。

話は戻るが、私は時間外でプログラムの勉強はよくする。それは楽をしたいがためだ。時間をかけて、くどくどしくプログラムをすることには何の意味も抱いていない。
可能なら楽をしたいし、可能ならプログラムを組みたくない。可能なら、１００行以下で求められていることを終わらせたい。

労働時間が長くなるのは、嫌だ。それが雇われであるなら当然。労働力を売っているんだから、供給したくないときだってある。それを選択できるか、できないかは別の問題。買い手がつかないときもあるし、つくときもある。雇用主との間に、持っている情報や資金的な面での不平等はあるが、契約に関して一方的に買い叩かれる謂れなどない。そしてそれを主張するためには非常に効率的に仕事をこなすことが必要だ。相手に「ここしかない」と思わせることは、商業的には下策だ。特にこちらから売り込まなければならないときには。無限に買い叩かれる可能性がある。それは本当に最低な営業活動だ。

それで結局何がいいたかったのか。
要はオレは業務で楽をするってこと。あとは買い叩かれたくないので、若干駆け引きするよ！ってこと。

DICOMというメディア規格について。

規格の書物の１，３，５，６，１４で画像をうまく復元できるようになると思う。
１は概括、３はオブジェクトの説明、５はデータ構造、６は定義集、１４はGrayScaleの色調補正。
浜松医科大学は生家のある都市だが、DICOMの情報が一番整っていた。やるな、浜松
ビットデータをどうしても8bitにしなければいけないので、さまざまなフィルタが必要である。
GrayScaleはどうしても黒に対する人間の目の感応力が低いので、黒よりも白でより多くの諧調を表現すようなトーンカーブをつくる。
ほかの画像に関してもガンマ補正が必要
DICOMはもともとは通信の規格から発展しているので、画像関係のところは散乱している。１、を参考にされたし
１がMin白、２がMin黒、GrayScaleの話

まぁ仕事が回ってくるのは良いが、せめて業務の範囲を明白にしてください。最後までやるならやるでもっと設計と解析に時間をかけたいです。というか、先にDICOMの規格の書物を全部日本語に訳さないとあとあと二度手間、三度手間だけど、それをして良いのかも、訊かないと分からないのもなんだかなぁ…さらに重要な、業務の期日も明白にして。

話は変わるけど、オブジェクト指向プログラム環境下でGetValueというメソッドで個別の変数を返す処理をしたいとする時に、引数と戻り値をどうするのがもっとも効率的か分からない。特にC++にはクラスに型タイプがない…１つ考えたのは、型の列挙型：eType
eType getValue(void *dst , unsigned long *size);

このように関数を作れば、値をつめたものとそのサイズ、自分で設定した識別子が手に入るのだが…仮にこの引数などは結局はポインタで参照しているデータのアドレスとそのデータのサイズが一緒になっていれば、１つの引数で終わるのだ。さらに言えば、識別子も入れるなら、getできるか出来ないかということまで記述できる。

ただこれだとまったくポリモじゃない。たぶんswitch文で大量に分岐するのが目に見えている。それはそれで面倒です。

さらに話は変わって、C/C++でもっとも信頼できるライブラリって何？そしてライブラリの信頼性の評価/テストってどうなってんの？Boost　C++ をいれてみたいけど、導入がよくわからんｗドキュメントを早く読んで使ってみるお。はじめからスタティックライブラリつけてくれてもいいのに…。

Fast Light Tool Kitの初心者のためのチュートリアルを少し見た。
これはWindowsの.NETのFormの作り方によく似た感じを覚える。
クラスをインスタンス化して、Begin()-End()の間でコントロールを設置している。そのあとでShow()、表示させて、Run()でメッセージループの開始をしている。このWindowのクラスの抽象度はとてもいいと思う。惜しむらくはBeginとEndに目的語に当たるものをちゃんと設定してほしかった。あるいはUnlock-Lockといった対になることとその間だけでなにかが許可されていることを表す関数名がよかった。
この抽象度は.NETのFormも同じぐらいだ。これは、C#のFormの動きをみればよく分かる。どちらが先とか言うことではなくて、この設計思想はたとえばボタンをすぐに乗っければいいと思う人にとっては、Begin()-End()のロック機構がまどろっこしいだろうし、呪文にしては、Begin－Endは上記の理由で不適切だと思う。
ぱっと見た感じだけど、よく考えられていると思う。そしてなにより扱いやすそうだ。抽象度が適当だと思う。このライブラリは更新も割りと頻繁に行われているようなので、当分はいけるのかな。日本語の解説サイトがないことがもしかしたら普及が遅い理由なのかもしれない。あるいはFLTKがクロスが不十分か、Macが非対応か？
そしてクロスプラットフォームにそれほどこだわるのはなぜか？実行形式にされないと結局はどの環境でも使えないし、そもそもパフォーマンスをあげるのは、やはりオーダーメイドで、仮想レイヤーが少ない場合だろう。この流れでいうと、Windowsのみで、クロスプラットフォームサポートを捨てた日本製のToolKitの開発というのも意外とアリなのかもしれない。解説サイトが日本語は当たり前だ。でも技術的な知識の蓄積は見込めないし、コードの修正、改造なども頻繁とは行かないだろう。海外のユーザーがつかわないと技術的な情報の蓄積が見込めない（母体数と能動的参加者の明白な差）ので、海外の技術者コミュニティにコミットしたものがいいだろう。それでいうとGLUTとFLTKはいいのだろう・・・
あとは映像製作用に特化した細分化された巨大なライブラリ群かな…
細分化された巨大なライブラリというのは、必要に応じて、使うライブラリを減らせるということでファイルサイズに制約がある場合に対応できて、なおかつ製作中は多くのライブラリでサポートすることによって撮影を簡便にすることだ。・・・え、既存のライブラリを集めればいいって？そりゃそうだ。
さらにさらにいうとライブラリの信頼性については、各々が確認してから使うしかないのがつらい。ライブラリの信頼性はアプリケーションの信頼性だし、もろもろのソースコードにまつわる問題と一蓮托生だ。とりあえず自分でWindowsのFormをC++ベースで抽象化してみる。・・・本当はC#が好きです。

最近、OpenGLの補助ライブラリ、GLUTってどうなのだろう。

現役なのだろうか？僕にはこれは使いづらい。カメラアングルのテストとかのためにマウスを最大限生かそうと思うと、このインタフェイスは不十分だ。それに日本語訳されたAPIリファレンスはLast Update 2001って何？７年も更新がないっていうのは、完成されたのか、破棄されたのか、どちらでしょうか？７年という時間はコンピュータの世界でレガシーになるには十分な気がします。とりあえずクロスプラットフォームのためのGUIサポートの関係上どうしてもMouseWheelを組み込めないのかもしれませんがいまどきWheelのないマウスが逆に少ない。それにWindowsに特化したOpenGLの補助ライブラリっていうのも必要な気がします。でもそれはGLUTの範囲を逸脱するのだとも思う。

とりあえず目に付いたのは、http://ja.wikipedia.org/wiki/FLTK
FLTKがクロスプラットフォームの補助ライブラリなのですが、正直これに関してはまた使用してみていないので、謎です。

それほど大きな仕組みを必要としていないので、カメラのクラス、関数や行列計算関数のライブラリとGUIの制御のライブラリ、画像処理ライブラリの組み合わせがいいなぁ…必要最低限の分をくみ上げるのにはちょいと時間がかかりすぎるので、周辺の情報をかき集めて、回答を探してみる。
とりあえず自前でBITMAPを扱える程度の能力とバイナリファイルの解析をするだけの忍耐が出来たので、画像のほうはいざとなれば、どうにでもできる。

OpenGLをなぜ今やりだすのか、ということ。

単純に大学時代の先輩がなにかやるぞという動きを見せたときに、少しでも助けになるようにという軽い気持ちで。大学時代に先輩がDEMOをつくっているのをみたときから、プログラマの世界はずっと自分には遠い世界だと思っていた。その世界を自分は結局選んだ。だから、その世界の１つの到達点であるDEMO製作をやってみたいとはずっと思っていた。
きっと日本でのはじめての海外勢を呼んでのPatryには間に合わないけど、その領域に近づきたいから、がんばってみよう。会社のほうはまだ残業代もつかないし、定時で帰れるし。。ｗ

今日先輩に「再帰処理」はメモリリークやDEBUGの困難さからどうしても駄目なときの最終手段だよっていわれました。個人的には再帰はとても合理的な選択だと思います。入れ子式のデータ構造を解析するときに深さが不明なのときには再帰処理が最適だと思います。というか、最近は再帰以外で考えるのが、若干難しいです(汗　forで代替する方法がわかりません。

あとクラスを使うことによってコードを簡単にすることを提案されました。これは合理的な判断だと思います。個人的にC++でクラスを書くのが嫌いです。C#と比してです。CベースでやるならUnionをつかってそれを構造体に型を特定する方法を含めて作れば、便利かも。とりあえずC++でクラスを表記するのが面倒。あと継承しているのにOverrideしないとVSのIntellisenceから消えるのが最低。C++もメソッドをマクロで作ってくれたり、クラスのメンバを追加してくれるならとっても楽チンで別にC++でもいいのです。できればクラスを書くのが簡単になったり、VC++でPrivateな変数をそれをHeaderから参照しているときには隠してほしいと思いました。アクセスさせそうになっていかん。

あと今日から電話を取るようになったけど、耳が悪いので、聞き取れないので気分が最低です。さらに「いつかかってくるかわからない感」が開発への集中度を下げます。とってもいかんです。電話は嫌いです。メールでお願いします。聞き逃しと伝達ミスが少ないので、私はメールを推奨します。特急の電話の時にはやりようがないですけれど、そんな状況になる前に問題解決させたいです。

とりあえず電話は文明の利器の中でもっとも嫌いです。次が核兵器です。
電話など消えてしまえ！

GLUTをつかって描画を表示させようとしているのだが、Windowの表示の更新が死んでいる。またMessageLoopがおかしい。

それと気づいたが、GLUTで作られたWindowから正しく脱出する方法がない。

exit(0)で脱出しているときには、生成したWindowのハンドルが開放されていない気がする。

あとはWinAPIとの絡みで全般的にMouseWheelは使えない。これは.netでもいえるので、仕方ないかもしれないが、３Dでチルトホイルが使えないのは最低だ。Zoomがない。

GLUT自体のWindows配布版はいい加減VC6++はやめてほしい。

なんだかしらんが、すげー勢いでCPUを占拠して、活動がままならなくなった。

慣れもあるけど、GLを特にオススメする理由が見当たらない。

GLそのものを使うのがいいと思うが、それでは機械的なレベルすぎて、しんどい。でもGLUTの抽象度でここまで扱いにくいと正直もっとつらい。インターフェイスに関しては、必要じゃないものが省かれているけれど、正直サンプルをみて、リファレンスもみてじゃないとぜんぜん扱えない。というか、サンプルが動かないとか、致命的。

大学時代の先輩がBreakPoint 2009に参加した。

System KのKioku氏、crv氏、sincl氏は先輩である。
http://www.sys-k.net/
チームサイト
http://kioku.sys-k.net/
kioku氏の個人ブログ

kioku氏のブログに「日本でPartyをやらないのか？」ということを聞かれた話が出ていた。
面白いと思う。ほんとうに面白いと思うけれど、
「それに自分は参加できるだけの力量があるのか？」と
考えるなら躊躇せざるを得ない。力量が今はないからだ。
ということで、すこしずつOpenGLを再度確認しようと思った。

ちなみに
http://www.siggraph.org/asia2009/jp/
SIGGRAPH ASIS 2009　は
日本の横浜で行われる。
これにあわせて、もしもPartyができるならさらに面白いと思う。

SystemKの作品を見た感想

ここから先は失礼を承知で書く。コードを作る大変さや映像を作る大変を実際の１厘も分かっていないけど、観客としてみたことを書く。
その作品を見た。
僕は導入部分が好きだ。ありがちな無機的な映像だけど、あの映像とあの映像にかかっているエフェクトが好きだ。奥に引きずりこまれていく感覚と時計の表現から、流転するものを表現するのかと感じた。
しかし後半のモデルが乱立しているあたりでなんとなく映像に停滞を感じた。それも意図している停滞ではない停滞を。なんとなく映像が息切れしていると思った。
葉っぱから落ちる水滴の表現も個人的にはサンプルがそのままのような印象を受けた。実際の水のように落下する水滴の表面に下から上へ波が伝播するを期待していたが、それがなかった。当然くると思っていた波紋の表現がなかった。
全体的に前半のエフェクト部分と後半のモデルの部分でちぐはぐな感じを受けた。前半の表現の感覚を続けていくなら、後半のモデル部分では最低でも人間は必要がないと思った。

期待が大きかっただけになんだかもどかしかった。

DICOMという医療用のTag付Media形式規格がある。

これがめちゃめちゃ巨大な規格である。

基本的にはTag+Value(s)みたいな形式のデータ構造。

Tag部分は、Keyデータに当たる部分があり、それぞれ規格によって決められた意味を持ったものと独自のタグが含まれている。

たとえば

GroupNum(2byte)|ElementNum(2byte)｜Keyword(2byte)｜（reserved）(2byte)｜DataLength（2/4byte）｜DataValue(DataLength)

という形式のデータがずっと並んでいる。

DataValueの中にふたたびTag+Valueみたいな形式のデータが入る、入れ子構造にもなっている。

人間の可読性は限りなく低い。機械に優しいわけでもなさそうです。

ただ汎用性の面では機械にレベルが近いので、優秀そうです。いまならXMLで構築されていそうです。

これが格納できる画像もしくは動画の形式はオーソドックス（JPG,PNG.RLE、MPGE）なものばかりですが、その格納方法もとい圧縮方法がいまいち分かりにくい。というか、最新の規格書は英語もので、PDFファイルもDeadLinkあるいはそもそも配布禁止っぽいもの。

でもこの規格自体の需要はあるので、OpenSourceでいろいろ公開されています。それはぐぐればいろいろ出てきます。

ただ本当に規格の文章を読むのなら、３，５，６でとりあえずはファイルの内容を読むことが出来るようになります。特に６の文章にはタグのデータの定義集がついているので、必須。５は圧縮されたデータについての情報。３は基本的なDICOMの話がある。もし画像をやるなら５，６は本当に必須。

でもこの５，６の文章が英語でもあまり判明ではない。またそれぞれの数値の実際的な使い方についての記述が少なく、規格からそれを実装するまでの溝が結構ある。

また規格自体が超巨大といってもいいので、それら全てを網羅したものを作れば、普通に販売が出来ます。というか、売っているところがあります。もっともタグに独自にデータを割り振れるところがあるので、完全に解析できることはなさそうですが、互換性がそこで完全ではない分、オーダーメイドの部分をもったソフト販売も夢じゃないですね。もっともそんなところとお付き合いのある会社に雇われていなきゃこんな規格みないでしょうけど…

仕様にしたがってファイル読み込みを作る練習にって思っているなら、やめたほうがいいですね。そもそもこの形式のファイルが手に入らない…ｗ一般的に流布しているファイル形式じゃないところが良いのでしょうけど…ちなみにIrfanViewではみられます。

題名は昔どこかのサイトで誰かが言ったすばらしい台詞。

意味としては、すでにあるものを再び発明するために労力を使うなんて馬鹿らしい、という意味だと思う。決して、再発明することによってそれを発明した人の経験を追体験できてすばらしいという意味ではないと思う。

なぜこのことを言うのか。今現在の世界ではあらゆるところで発明が日夜起きている。それの情報にどれだけ多くの人がアクセスすることができるのか、という観点をおいておいて、その発明を新たに知ることはそれを再発明する労力よりは割と軽微だと思う。もっともそれはよく訓練された検索エンジンが動いているからであり、ただその恩恵に対しては十分ありがたいと思うが、それが一般化されてしまうと忘れがちです。

話を元に戻すと、今度はアクセスの問題で、秘匿されている知識、発明はありますが、インターネット網で整備された巨大な図書館の存在は、それが存在していなかった時代に比べて、はるかに知識を手に入れることが容易になりました。またプログラムにおいては肝となる実装部分は本来は秘匿されていて、またあるいは高額な書籍の中に印刷されていました。ここにきて、オープンソースの話をするのですが、彼らは何のためにそれらをアクセス可能な形で残すのか。この動機付けに関して、商業に長く身を置いている人は、アクセス可能であることのありがたさを感じていながら、自身で身に着けた技術を隠すことが多いです。まぁそれで食っているのに、わざわざ手のうちをさらすまでもないのですが。

正直なところ、私もソースコードを公開する動機付けで１つだけいえるとすれば、「前に公開されている情報によって助けられたから」ということしかありません。言うなれば、「情けは人のためならず」ですな。特にプログラミングなんてほとんどどっかの誰かのコピペみたいなソースコードや誰かの提唱した考え方、アルゴリズムをふんだんに使って作っているのに、いまさら自分だけは秘密っていうのも･･･

まぁ、１つだけ大きな公開を躊躇させる懸念事項は、ソースコードの品質。ソースコードにも綺麗と汚いが存在するので、汚いソースコードを出したくないってことです。また誰かに再利用されるときに責任問題があったり、またその利用条件によって使えなかったりいろいろです。ソースコードは基本的に責任取らんから、好きに使って良いけど、「自分のものって言うなよ」って権利がいいのですが、ソースコードの独自性をどこまで認めるのかという問題が出てくると、改変禁止が一番分かりやすくて、でもそれは変えられ場合には誰の権利になるのかということが問題になります。

哲学で言うと、なんたかの舟という問題で、代替可能なもので作られたAを統一体としてのAとして認識させているものは何かって問題です。オリジナルや自己というものの本質を問う題目である。

それで再発明した場合には、発明しているのにすでに誰かのものっていうことで、全ての苦労が水の泡。権利問題もあるけど、なるべくならすでに発明されているものを利用してそれから先に行こうよって言うのが、私の基本スタンス。だってすでにあることを知ったときの脱力感が嫌いなんです。

どうしてもこれだけは許容できない点が私には存在します。
それは、とても主観的な問題で一般化できず、また特定の手順によって確認できるものでもないのです。

浪費ばかりをし続ける人
努力しない人
口だけの人
今だけしかない人

これらはただこのように並べられていると、どれも例外が存在しています。１．に関しても、資産をもってそれを食い潰している人は、まぁ許容できますが、２.該当するならば許容しがたいです。しかし、私は努力をむやみに礼賛する気もさらさらないのです。努力という言葉はその言葉にすでに善性を表す意味合いが含まれていますが、個人的にはこの努力というのは覚悟をもった労働であり、これによって如何なる結果が導かれても自己への内省を生むようなものをさします。そうでないと、努力であれば全てにおいて許されることになってしまいます。３．の口だけの人は結局は覚悟がないという点で２.と複合的に許しがたい行動をとることが多いので、いやです。４．の今のみに生きているというのも、確かに極限状態で事象の大まかな見通しすら立たないのであれば、それについては問えませんが、私が問題にしたい場合は十分予見可能な範囲のことすらも考慮に入れない人です。これを仮に確かめるならば、説明をしてもらえばいいのです。なぜそうするのか。

大抵の許容しがたさの根本には、自己への無理解であると思います。自己への理解、自己の行動原理の確度。内向きの検討であるけれど、それの題目は将来や外の事象に向けられていることをしっかりしている人を私は評価していますし、そのように私自身なるべきであると思っています。これらを多くなしている人のことは私は尊敬しますし、より少ない人でもこの志向性を持っている人へは敬意を払います。これらの志向性が欠如している人こそ、私がもっとも嫌うものであり、度し難いと思います。

もっとも簡単にたとえると、寄生虫はすべからく排除したい。

童話でたとえるなら、「アリとキリギリス」でのキリギリスは厳冬の雪の中で、アリに頼るようなら死すべきであり、その中でもキリギリスとして生き続けようと覚悟を決めるならば、わずかに助けるべきであろう、ということである。

考えて生きていくことをあきらめた人は、積極的に排除したいです。考えた末に死にたいと願う人にはわずかな憐憫を覚えますが、私は８割もったいないと思います。その覚悟をもって、ことにあたれば本当に困難なことなどないはずですから。死は根本的な無へいたった状態と考えるから、死への志向は生の逆であり、落下速度に近いエネルギーだと思うのです。そのエネルギーで問題を突破できるなら生きれば良いし、突破できなくても本来の覚悟へは至れるから、ただ死ぬことを選ぶことは、本当にもったいないと思う。

「必要とされていないから死ぬ」という人は、考え違いを起こしていると思っています。問題の局地は、他人が先に発生するのか、自己が発生するのが先か、です。「社会的に必要とされていないから死ぬ」という意味で死ぬならば、その前提とされている社会を変えることを考えられないことが哀れみを誘う。そして必要とされるようなことをしてこなかった、あるいはしていないのに、それを望むならそれはないものねだりであり、赤子である。してきて、今はなくなってしまったのなら、次の必要とされることをすればいい。「他人に必要とされる自分」でしか自分を保てないなら、それを満たすようにするか、そもそもの「他人に必要とされる自分」は人格的に壊して、別の人格を作り直すしかない。これを「死」とみられるならば、それでいい。なにもせっかく生きようとしている「身体」まで殺してしまうことはない。ハード的な「身体」はまだ使えるのだから、ソフト的な「人格」を再インストールするか、リカバリするしかない。ソフトの複製が確立されていないので、論理的に身体は根本的な自己といえるかもしれない。これは経年劣化や外的衝撃で破壊されてしまうまで使えばいい。

そして、やはりいいたいのは、どう行きたいのかを明確に自分にだけは説明できるようにしておいてほしい。そうでないと見苦しいし、救いようがない。芯になるものがないとざるにもかからない。本当の意味ですくいようがないｗ

アサートとエクセプション

ついさっき、AssertとExceptionの違いを理解した。

端的にいって

AssertはDeveloperのためのもの。
ExceptionはUserとDeveloperのためのもの。

Assertは前からその存在を知っていたのだが、うまく使い方が分からずにずっと放置していた。

とりあえず自分で考えた使い方のルールを備忘録。

Publicなメソッドの中での引数のエラーなどは、Exceptionで処理するか、もしくはそのまま情報を追加してThrowする。
Privateなメソッドの中での引数のエラーなどは、基本的に開発者に責任があるので、それはAssertで警告する。
ProtectedなメソッドでVirtualでないものは基本的にAssert、それ以外はException。
DLLなどの形のときに外部から使われるものは、基本的にはThrowする。それ以外は開発者のみが知ればいい情報なので、それらはAssertで処理する。

例外処理が万能すぎるからついつい多用してしまうので基本的にはこのルールでいいと思う。Trace…に関しては別の話でｗ。

あと問題だと思うのは、Exceptionでしか捕捉できないもので、なおかつAssertしたほうがいいものがあるけど、これはどうするのか…それとそもそも予期できないエラーはすべてExceptionに飛んでいくのはどうなのだろう…。プログラムの設計の仕方が悪いのかもしれない。

安全で、効率的なコーディングを目指してT&Eしかないのか…

1つ、意外と休みが多いこと。
2つ、8時間(9時間)の拘束って意外と苦痛。
3つ、新人だから気を使いすぎて倒れそう。

あとは地味に飲食と音楽聴くのがダメなのがきつい。
普通なのだと思うけれど、きつい。

休みが多いなぁと思った。実家で手伝いをしている感覚だと、拘束時間はゆるく長くて、なおかつ土日はない。休日はむしろ仕事って感じだったから、平日しか仕事がないことが不思議。
普通の会社は拘束時間は割りと長めでみっちりしてる。そしてCRTのモニタの前に8時間はつらいです。目が痛いです。

さらに一応、それなりにプログラミングをしていたので、会社では『期待の新人』らしい。とてもじゃないが、気を使いまくって倒れます。どの面下げて「できる」と言え、と。

･･･あと環境を設定させたいのなら、Officeとかは一番に入れさせて下さい。勤怠表が書けませんｗ

仕事が終わって帰宅して3時間ぐらいは時間が取れるので、意外と勉強とかできそうです。（今はまだｗ

日々、吾ハ習ヒ試シ違ヒ試スナリ: .NET Framework のDictionaryの弱点

この記事の話ですが、
よくよく調べるとDictionaryEntryの配列が存在しました。
こいつは、PropertyがKey,ValueともにGetSetなので、
期待しているSerializeの働きを行うのに適合します。
これによってデータがSerialize、Deserializeされることが
確認できましたので、覚書ですが、ここに記します。

【ニコニコ動画】字幕つき【音声のみ】麻生太郎の健全な日本の話【2008.1.26】
これを聞いてもなお、彼の人が物を知らないという人がいるのなら、ぜひその発言を公にしてほしいなぁとおもいました。
一国の総理になるってすげーことだ。

セブンスドラゴンのレビュー
このゲームは、ひさしぶりに長いことそれほどのストレスを感じずにやることができました。

キャラクターのかわいらしさについては言うことありません。ドラゴンのデザインもいい感じでした。システム的な面では王道といわれるターン制バトルでよかったと思いました。しかしバトルに関して、エグゾースト能力については使いどころに困ることが多くあり、またこれを有効に使える局面が限られすぎていました。またダンジョンではＭＡＮＡやゲージの温存を基本とするので結果的に使わないことが多いです。

ついでにいうと、ヒーラーのクラフトマナというスキルが尋常ではないほどの有用性をもっているのでこれによってダンジョン攻略のしやすさが格段に違います。またローグの小銭集めスキル、メイジのアイテム拾いスキルが有用すぎてアイテムがあふれて仕方がありません。倉庫がほしかったです。

自分は侍姫忍僧でやっていたのですが、姫の補助能力の有用性が半端じゃなかったです。侍の攻撃力の高さが群を抜いていたのも驚きました。ローグの吸血スキルは後半ダメージ合戦になるとほぼ無敵なのがバランスを著しく欠いている気もしました。そしてあまりジョブ間の連携攻撃を行うよりも、単純にバトルでの効率を重視したパーティ設計をしたほうが簡単だと思いました。
ちなみに最初期にはメイジが入っていたのでしたが、途中からヒーラーと交代しました。ヒーラーのクラフトマナとメイジの魔法攻撃力、明らかにヒーラーが有能です。そして後半、侍の攻撃力が強化後で大抵500でるので、正直メイジは空気でした。ローグも吸血で自動回復しながら戦闘をすることが通常化すると回復不要でＭＡＮＡの供給さえあればぜんぜん問題がなかったです。若干姫が空気ですが、補助詠唱と回復スキルで後列で攻撃をしのぎながら前列を補助し続けるという戦闘スタイルがとても効率的でした。

シナリオは、ご都合主義の某大作ＲＰＧに比べると残酷さを含んでいたので、個人的には満足でした。

システム的な面ではいくつかの問題があると思いましたが、全体的には我慢できるレベルでしたので、問題なし。ただキャラごとのスキル性能の差がありすぎるのが気になりました。とりあえずヒーラーのクラフトマナは根本的にずるいと思いました。

ただ2週目やりたくないです。もうすでに50時間超で最終盤です。

日々、吾ハ習ヒ試シ違ヒ試スナリ: 画像の補正
その後、該当するアルゴリズムを探す視点を変更。
すでに適応されている画像編集ソフトのフィルタの作者を探しに回った。
ＧＩＭＰ，Ｐａｉｎｔ．ＮＥＴにはＬｅｎｓＤｉｓｔｏｒｔｉｏｎというまさに探していたフィルタが存在する。
これらの作者を探して待っているとソースコードが出てきた。
今回見つけたのは、Ｐａｉｎｔ．ＮＥＴ用のフィルタです。
http://paintdotnet.forumer.com/viewtopic.php?f=16&t=21624
この掲示板の後半のほうにソースコードとＤＬＬを配っている方がいらっしゃいます。
この人が変数ｋを与えられたパラメータから生成してデータテーブル化して使っています。
これによって前回問題してしていた行列内の変数に対応していました。
今は、このソースを勉強し、自分のアプリケーションに合致するものに読み替えています。

この場合はソースコードをコピーしたことになるのでしょうか？
そもそも数式が存在するものに占有権を主張できるのかなぁ。
そしてぶっちゃけプログラミングは八割は誰かの模倣で成り立っていると思っています。
つまり占有権を認めてもらうと困ります。
ただアプリケーションになっているものについてはこの限りではないと考えます。
ブラックボックスになったものを解析するのはいいけど、
これを複製して自分のもののように主張してはいけないと思います。

歪んでしまったカメラ画像を変換して、歪みねぇ画像にしないといけないのだが、ぜんぜんうまくいかない。カメラモデルによる理想的な変換行列については関連したところを見つけることは簡単だが、ただ画像を補正するものはなかなかない。そもそも歪曲収差のような変換は行列的には逆変換が存在しないっぽい？のでただ変換行列を逆行列に無理やり換えてもうまくいかないという罠。ちなみに理想的な変換行列に関してはそれぞれのパラメータを取得するに際して最大で１６変数だかで、計算して求めるには、大変な計算量になるらしい。またパラメータのいくつかにべき乗数が存在するので、数値が拡大されてしまうので、数値が大変なことになるっぽい。
そもそもこの行列をつくるときに面倒な点は、中心点からの距離によって使用されるパラメータが変化することである。単純に定数を入れるのではうまくいかない。いくつかのパラメータは変数である。カメラモデルでのパラメータとしてみると理想的な撮像モデルと実際のモデルでは、境界を形成する線が曲線になる。どのような曲線かはよく分からない。ただゆがんでいるのだ。
各点に対して変化するこの行列はｎで表現される式になっている必要性がある。というか、そうでないと扱いにくい。

http://jp.techcrunch.com/archives/20090317hypocritical-artists-and-secondary-ticket-sales/trackback/
ここに掲載されている日本語訳の記事はとてもまっとうなことを言っていると思う。
世間でのチケットに関しての奇妙な公正さの主張はとても気分の悪いものだ。違和感を感じる。

時間を割くことのできないファンはファンではないかのような物言いにいつも私は不思議な感覚になる。
もしダフ屋を完全に消し去りたいのなら、すべてのチケットをオークション制で売るがよい。ファンは自らの愛するアーティストへ多額の援助金(笑)を進呈することができる。だが人々は金で愛を測るのか、と問う。逆に問えるのは、時間で愛を測るのか、ということだ。一度市井に流出した商品がどのような経緯をたどろうとも、正直提供者は関心を持たない。ただ同じ商品を手に入れたものが、他人の取得方法に関して関心をもち、論争を行うだけだ。長い時間並んで買ったチケットに愛着をもつのはかまわないが、それと同様の品をあなたが購入したときの値段よりも高く買っただけの人をなじる権利をもつのか？それを斡旋した人をなじれるのか？それは時間をかけないで手に入れた誰かを見ることによって、自らがみじめになっているからではないのか？自らの愛が否定されたようでみじめなのだろう。では、それで減じるようなものを至高のもののようにしたがるのは、それが嘘だと思っているからだろう。

売買の仲介をしているものを不必要に悪く言うこともいい加減にしたほうがいいだろう。仲介人は仲介する際に自分がこうむるリスクの分は最低限確保したいものだ。自らが直接買い付けができたからといって、できなかったものへ分配を行う仲介人を悪くいえるのか？彼らがやりすぎるように見るときもあるが、彼らを破滅させたいのなら買わなければいい。実際それほどのうまみがでるわけではない。水物のような商品を儲けるために大量に購入すれば、潜在的な在庫の山が発生するだけだ。

自分の信条や信心に反するからといって牙をむいて吠え立てるのは、弱者である。むしろ吠え立てるのは、大抵弱者である。しかし本人たちは本来的に勝っていると考えているのに、なぜ牙をむくのか？それが私の違和感なのだと思う。

とりあえずいえるのは、アルミボディは冷たいし、熱い。

またＢｏｏｔＣａｍｐを使用しようと考えているときには、かならず付属のＤＶＤを忘れずに用意しましょう。ＤｒｉｖｅｒのはいっていないWindowsは最低です。ちなみにＥｔｈｅｒ　ｎｅｔもないので、Ｕｐｄａｔｅすらままならないので注意しましょう。

WindowsがＭａｃＢｏｏｋで動く必要性は本当はないのですが、動けば便利です。

あー、ちょっと気がついたのですが、Windowsでリムーバブル設定されているデバイスは任意のタイミングで抜き差しできるのですが、ＭａｃＯＳではそうではなくてまぁかならず所定の動作をするしかないです。

Ｍａｃでの操作は慣れると楽なのですが、机の上で使うことが前提なので、寝転がったり、床に直に置いて使うときには、なかなか使いづらいですねー。とりあえずタッチパッドの使用感はいい感じです。

それでまだiPhoneの開発に入っていません(汗）そうこうしているうちにiPhoneは3.0になってます。コピペや横向きでの入力ができるようになったらしいですね。まだしっかり文書を読んでいないので分からないのですが、頻繁にＯＳがＶｅｒＵｐされるのもちょっと考え物な気がします。

システムの外へ落ちたときには、何も保護してくれるものはない。

そしてシステムの内にいるときにそれを実感することが可能なのは、それを見ようと努めるときだけである。

自らが属するシステムがシステムの外を見ることを可能にする、しないということは国家でいうならば報道規制の有無がそれにあたる。ただし報道規制がなくても、報道を行う側がそれを見せ続けることを努力することが必要になる。これは不自然な働きなのでこれは努力するしかない。意志して行うほかない。これの時の自分は「自由」であるということもある。

さまざまな流れに逆らっているときに自由である。

また従いながらも、従うことを選択することが自由である。

そして自由であることを自らに任じるならばそれは意志して行うことに他ならないので、責任が発生しないことがない。逆に言うとこれを自らに任じていないのならば、その人には責任はないのだろう。

そもそも予見できないものに責任をもつことは無限の責任を負わせることに繋がるだろう。

もっともこれを言い出すと責任からはたやすく逃れることができるだろう。

しかしこれから逃れることはすなわち意思することを放棄することである。

この放棄を躊躇させるのは、システム外へ落とされることの恐怖でしかない。

システムの外へ落ちることをいとわないものはあらゆる責任からも逃げることを選択しうるのでないだろうか？またシステムの外をよく知るものはそれを選択しうるのではないだろうか？また恐怖を感じなければ、何でもできるのはないだろうか？結局恐怖がないときには躊躇させる強制力がないのではないか？これでいくと、身体的な罰則は根源的に強制力がありそうだ。拷問はそう考えると合理的な責任を負わせる方法なのかもしれない。まぁそれを行う時点でシステムの外の存在の扱いになっていて、責任を負うことによってシステムの中に回帰できるのか？

Dictionaryの弱点というか、クラスの設計上の弱点という盲点だと思うけど。

Serializeすることができない。

答えは復元することができないからだ。

KeyValuePairでのKey、ValueのそれぞれはGetしかできないので、その後の復元ができないのだ。しかし辞書クラスは外部にデータを取り出したい、ときもある。

しかもややこしいことに大体この一対一のペアになるようなデータ構造のものは結構あるという罠。

かといって、このために新たに構造体を作るのもなにか負けた気がする。

解決策は...わかりません。

さらに問題なのは、IFormatConverterとかいうSerializeのための変換インタフェイスがあるのですが、実装しなおさなければならないということ。GenericClassなんだから最初から実装してよ、って思いました。

PS.　

http://blogs.wankuma.com/pandora/archive/2007/06/07/79902.aspx

もうどうしようもないので、拡張してしまった先の話

PS.2

http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=42363&forum=7

このようなTopicに関する議論。ところどころ

冗長だと思うけど。

数式の解析はだいたい正しく組めるようになった。

重要なのは、スタックの優先度が低いものから高いものへの再起構成かなぁ･･･

あとはOutOfIndex（ｗ

ただこの数式の解析については基本の演算子のみサポート

代入"="と等号不等号の演算子には非対応。

これらに関しては、数式とは別のレベルでの解析が必要になる。

代入と成否判定はもっと単純に表現すると、

X=AとA==Bなどの形式に変換されて、Xは変数、A、Bはそれぞれが数式である。

このときの記号はVerb（動詞）として振舞う。

そして動詞の振る舞いも自動詞、他動詞がある。

自動詞ならば　X（arg1,arg2,...argN）

他動詞ならば　A？B

だなぁ。

？は予約された記号で対応できそうだな･･･

まぁ、変数の宣言機能はつけなければどうでもいいかもなぁ。

自動詞と他動詞のたとえだと若干混乱するけど、言いたいのは記号の動詞的振る舞いだから、そこに注意。

http://www.fresheye.com/

ここのサービスのコトバノウチュウ

なかなかおもしろい表示法です。

ただの関連語句の表示よりはほかの語が目に付きやすくていいですね。

これに似たサービスを行っているところがほかにもあったと思いますが思い出せません。

確か検索語句との関連性を元に3次元に表示する『情報の海』のような表現方法もありましたなぁ。

どうもJudaです。

数式エンジンをようやく作れました。

計算は逆ポーランド記法にしたがって記述しなおしながら行いました。

変数の取得と代入もIronPythonの方式で行えるようにしました。

ただし新規に登録できる機構がついていないので、使い方は大体Shaderみたいな感じ。

これによって一列の数式なら計算可能になりました。

あとは構文解析を行ってIfStatementによる条件分岐が行えるようになれば、簡易のスクリプトエンジンとしては十分かなぁっと。

そのときには変数の宣言が必要になると思うし、また例外処理の厳密化が問題になると思う。

ちょっと思ったのですが、計算の演算子の優先順位で％と＾の優先順位がどのようになっているのか。

今回のエンジンは　() >　＾ > */% > +- > =　の順番で優先順位がついているのですが、これであっているのでしょうか？

まぁ　＾　が今回特別に必要なので追加しましたが、これでいいのだろうか？

ちょっとした計算を外部に出したいってことがある。
そのために外部変数を取り入れ可能なインタプリタエンジンがほしい。
IronPythonもあるけど、あれは便利だけど、でかすぎる。
もっと機能限定された簡単なものでいいのだ。

ということで、
『ゲームプログラミングエンジン』赤坂玲音著、Softbank Publishing
『プログラミング作法』Brain W.Kernighan,Rob Pike著、福崎　俊博訳、ASCII出版
に出てくるインタプリタの項目を参考にして作成中。

とりあえず考え方は分かるのだけど、いかにして言語化するのかについて思案中。
基本的な算術式を実行できるようにするだけでなかなか大変だなぁ。
でも一度作れば、自分の資産になるので、勉強中。

現在、まさにこの勉強にぴったりな内容の本が出版されているので、
興味のある方はそちらを探してみるのもいいでしょう。

別の話
RIDEBACKがアニメ化されているけど、おもしろい。
10巻で最終巻らしいが、さっさと戦争状態に入ってしまったので、かなしい。もっとレースの話をしてくれても楽しかったかも。

Pythonコードへの外部化に成功した。

今回ネックになったのは、DLLのImport

そもそも名前空間だけ異なる同じプロジェクト内に存在するファイルのクラスをどのようにして認識させるのか分からなかったので、そもそもそれはDLL化した。

まぁそこまでやると普通のDLLの登録と変わらない。

AssemblyNameはｄｌｌのプロパティからデータを取って、妥当性チェックをすることができる。名前空間のImport自体はオブジェクトブラウザにDLLを食べさせることができれば問題なくできる。

ただPythonのコード自体の妥当性チェックに有効な方法があまりないのが現状で、このコンパイルエラーをより厳密に特定できるようになれば、生産性は格段にあがると思う。

あとは、ImportのSyntaxSugerがもっとほしいとは思う。

とりあえず前のエントリの情報に従っていけば、IronPython1.1は十分エンジンとして組み込み可能なことが分かった。ただやはりハードコーディングのほうが実行速度は速い。事前コンパイルのエンジンを駆動させることができればより早くなる可能性はある。要検討だと思う。

IronPythonはC#で実装されているPython。仲間にはCPythonやJyphonがある。しかしIronPythonの特異な点は、それが.NET Frameworkとの橋渡しがされていることだ。DLRというカテゴリーらしい。

ちなみにIronPythonのサイトは、

http://www.codeplex.com/IronPython

であり、ここには全てがある。

MicrosoftのPublic Licenseに登録されているので、ソースコードも公開されています。これをみれば、インタプリタの勉強にもなるかもね。

ちなみにIronPythonについてなら、

http://www.okisoft.co.jp/esc/python/iron-python-intro.html

入門編なら

http://www.atmarkit.co.jp/fdotnet/special/ironpython01/ironpython01_02.html

http://journal.mycom.co.jp/articles/2007/05/08/IronPython11/index.html

IronPythonとC#の連携についてなら

http://codezine.jp/article/detail/2187?p=1

大前提としてこれ以外にも

Pythonについて勉強しなければならないのはご愛嬌ｗ

スクリプト言語が組み込み可能になることによって、

ソースの細かな調整部分が外部に取り出されることになるので、

とっても便利だね！

最近CodeZineの無料の会員に登録したのだが、

http://codezine.jp/

まじCodeZineのソースは便利。

よく考えると不思議なのだけど、
自転車の取扱説明書を僕は読んだことがない。いや、そもそも今乗っているものも「自転車」とは言いがたいのかもしれないが、説明書が付属していなかったなぁ、と思った。自分の足の拡張である自転車のメンテナンスをしようとふと思ったときに、どうすればいいのか分からない。機能として「自転車」の要求を満たしているものが、本当に自転車足りえているのかを調べるすべを私は知らないのだ。もっというと、この「自転車」が妥当なものか分からないのだ。今にして思うと、私はメンテナンスというものを行った覚えがない、さまざまなものに対して。これで機械や論理的なものが好きだというのはお笑い種かもしれない。またなにかを大切にしていると発言することすらおこがましいのかもしれない。
なぜこんな話をしているのかを少し言おう。最近、自転車をこよなく愛する人のブログを読むたびにすこしづつ、信頼という思考停止状態に疑問を感じるようになってきた。まぁ、その人の文言はキツイのだが。その人が主張することの１つである、「自転車が楽しいこと」に関しては、異論はない。これほど単純で明白で便利なものはないのだ。そういう意味で言うとどのようなものも道具としてあるには意義があるんだ。でもその道具はその意義と「生命」を持っていると思う。それゆえその道具を活かしきれる環境が整わないとそれはそれで道具に悪い気がする。
じゃあ翻って、PCについてはどうだ？こいつのメンテも難しいなぁ。オーバーフォールするには経年している歴史が再構築に難ありで、困る。･･･ところでPCの固有なものってなんだ？

自分で考える基礎
共通

開発環境の状態
開発言語の文法
ロジックの考え方（テンプレート的なもの、デザインパターンなど）

C言語

ポインタ制御
標準の関数群の内容
ファイルの分割方法

WinAPI

イベント駆動型の意義

C#

言語のもっている機能（多機能なので、習熟に時間がかかる）

ロジックの考え方に関しては、プログラムの肝であり、また習熟し尽くすことはできないと思われる。そしてロジックに関しては擬似言語でも学習可能である（限界はあるような気もするけど）。しかしこれが豊かであればあるほど、上質なコードを生成できるので、これを強調したい。もっとも言語によらず、ロジックは存在できるので、一つの言語でこれを試行錯誤することが重要である。それゆえに開発言語がなにであるのかということは、言語特性に習熟しているか、開発の見通しを立てやすいかということぐらいにしか関係しない。。。と思う。まぁ、母国語が日本語なのに英語で作文を書くと大変なのと似ているような似ていないような…

信頼でなりたつシステムっていっぱいある。というか、保証つきのシステムだってそうだ。

何が言いたいのかというと、妥当性チェックしろってこと。

下位構造を知ることなく使えるシステムは全て信頼の上に成り立っており、その信頼が揺らぐときシステムは既定の動作を行えなくなる。何らかの権利を集約して持っている存在は信頼性なしにはその動作を安定させられない。しかし逆に下位構造がなくなっていても動作した気になることも可能である。「信頼している」が思考停止の魔法の呪文であると同時に「信頼されている」という言葉もまた思考停止の魔法の呪文でしかない。常にこの関係は妥当であるのか、チェックしなくてはならない。

信頼システムは安定した環境では非常に簡便なシステムであることは認める。しかし安定した動作を求めているのに、日常的に動作不安定な状況ではこれほど非合理なシステムはない。ただこれを厳格化すると初動がどうしても遅くなる。不安定な状況でも安定した動作を求めるのか、それとも不安定な環境でもそれなりに妥当であればいいのか。それは機能の安定性に関連してくる。それがトレードオフの対象だろう。

ところで厳格なシステムでは変革への機運が生まれないような気が･･･まぁ、デジタルな世界ではうまいこと変革ができないので、厳格システム一本かなぁー。アナログな世界ではどうかなぁ？

法の意識というものは、人間の発達段階で思春期を過ぎたあたりから生まれるものらしい。

インターネット上で中学生ぐらいの質問者が違法なレベルに抵触しているテーマを提出するということはこの観点からすれば、一定の留保を認めることができるかもしれない。しかしこれらをたしなめることなく質問に対して回答してしまうことは問題だと思う。そしてそれをたしなめる自身にも同じことが遵守されなければならないはず。

また日本で法といってもそれは守るべきものではなくて、引っかからないようにするものであるという意識がある。そうでなければ、違法か非違法かどうかを気にするわけがない。見つかる、見つからずに関わらず発生すべきである。しかしこれはあくまでキリスト教的な「ユビキタスな神の視線」ということが前提である。日本は一応これではなく「恥」というものを考え方を使っていた。現在これが十分な機能を果たしているとは思えないが。いまどきは恥をかかされた自分を悔いるのでなく、恥をかかせた相手を名誉毀損や侮辱で訴えるのだろう。結局自らのうちから恥をなくし、神の視線はなく、ただ他者の視線から隠匿されるならばそれでいいのだ。

インターネットという現実世界とは違う振る舞いを求められる世界で現実世界と同じように振舞うなら、ただ他者の視線から隠匿されることを望むものたちは、非常に活動しやすいだろう。発言者の身分は自ら明らかにしない限り隠匿され、ほぼ他者から隠匿されている。ネット上では強制力はなく、ただ一個人として自らの倫理観や道徳観をもって振舞うのでなければ、自らの振る舞いを律するものがない。実際は18歳未満禁止のポルノサイトに青少年がいくらでもアクセスできるし、それを行っている行為者を特定する手段が存在しないことからも、これらの違法行為を抑止するのは本人以外にない。

だからといって、ネット上でもこそこそと違法な話をすればいいというわけではない。そこで発言されたことはネットを介して閲覧できる以上は技術をもった人ならば誰でも到達できることを意味している。これは先ほどの隠匿とは逆の公開である。存在は隠匿されていても、そこで行為することを通じて、次第にネット上に存在が確立されていく。このようなあり方を「新たな誕生」のように捉えることもできるだろう。

結論として言いたいのは、ネット上でも人格が形成されていく可能性があるから、あとから後悔したくないのなら、自らの発言には生活世界であるとき以上の厳密さと責任が必要とされることだ。

まぁ後悔などと無縁であるような人はこの限りでないので、何を説いてもそれは無駄というものだ。これの人格の話もただ便宜上これを採用するだけで、これは真実ではない。ただこういう風に組み合わせて考えることもできるというだけだ。VR内で人格を形成することはたぶん可能だろうけど、それはVRのみではなく生活世界にも当然関係するから、まぁVRでの人格はある意味その人の一面という意味合いが伝わればいいなぁ。

まぁ、特殊であることの不利な点は環境が変わると全滅する可能性があるということです。それがリスクであるけれど、逆に強みでしょ。グローバル化という御旗の元に外へと出て行こうとしているけれど、井の中の蛙だったということですね。というか、このガラパゴスという表現を使うなら当然進化論を前提にしているわけで、でもその進化論の現在の研究まで到達していないでただ絶滅の危険だけあおってもしょうがない気が･･･遺伝子の変異の仕組みからすると、業界は変革していくだけの広さを認めないと死に絶えるような気がする。まぁ小手先の変化なんてよくある変異なので、大きく変えないとダメだねー。ってことでガラパゴスがガラパゴスから変化するにはもっと大きくぶれないといけないですよねーって話。

Demon's Souls のゲームレビュー

これは、よく死ぬ『ゼルダの伝説』だな。ゲームのシステムはばっちりだと思う。難易度もなかなかクリアできないぐらいに調整されていていいと思う。

でもステージが少ないのが気になる。。。ダウンロードコンテンツでダンジョンを増やしてくれたりすると末永く楽しめてよかったなぁ。DLCでの課金が常態化されると困るけど、ちょっとした拡張がされるとうれしいなぁと私は思った。あと飛び掛り攻撃とぶら下がりがほしかった。

政治とはなにか？権威とはなにか？責任とはなにか？

なんにせよ、これらにたった一つの回答しか該当しないのではあまりに不自由だ。

でも政治とは罵倒すること、権威とは失墜させるもの、責任とは逃げることではないと思う。

Gin Rummy（ジンラミー）
http://www.owari.ne.jp/~snowbird/rules/ginrummy.htm
というトランプの遊び方があります。
これはあまり日本でははやっていないのでしょうけど、
XBLAでDownしてやっているのですけど、なかなかおもしろいです。かなり戦略的に行動することができるので、ゲームとして面白いです。

http://ps2dev.org/psp/Projects
にPSｘでの開発のための道具が公開されていますし、
Tutorialがあります。
でもコンシューマーゲーム機での開発ならXBox360で
XBLA用にXNAで開発するほうがクリーンかも。
ただポータブルゲーム機の開発環境がないので、
開発環境の公開が願われます。

学ぶためには、それ以前の段階がほとんど意識にのぼらなくても理解できなければならない。そのうえで新たなことを試すことができる。このタイミングは書籍ではページの流れがつくるしかない。ゆえに書籍で勉強するときにはとても積極的な知的な活動を要する。しかしこれをすでに知っている人がやるとそれほど難解ではない。人はとおりいっぺんの発言しかできないのではなく、時に応じて言葉を変えることができる。そしてこれができない人は、結局自分でも理解できていないのだ。

なんてサークルの活動報告を傍できいていて思いました。

最近、ＭＶＣの構造でのアプリケーションを構築することを目標に開発している。
ＭＶＣは、Model-View-Controllerの頭文字であり、
Modelは本質的なデータ構造とそれに付随するメソッド
Viewは表層的なデータ構造とそれに付随するメソッド
Controllerは本質的なデータ構造と表層的なデータ構造を接続するメソッド
と解している。
ただこれも便宜的な分割方法に過ぎないので、無理にこれを準拠しようとすると
当然うまくいかないこともあると思う。

Objective-Cというかリンゴの会社はこれを推奨している。

これを意識するようになって、根本的にデータ構造の研究に注意を向けていなかったことがわかった。
以前は、View-Controllerのやり方に引きづられるかたちでその場その場に都合のいいデータ構造を作っていた。
これだとViewが変化したときにデータ構造が大きく変更されたり、そもそも不要になったりするので、改造に不便なこと、この上ない。
最低限必要なデータを決めておくこと(Modelの措定)によって、その後もデータの要素を変更しても、そのデータ構造に対して、必ず代入して値を満たすことを目指していけば、データをうまく扱えるようになる。
と思う。私の知っている範囲だとこの構造が一番うまく組めると思う。

WindowsProgramingについて何か語ることがおこがましい気がしますが、いくつか大切なのだとおもった概念を備忘録します。Windowsが推奨しているCOM+イベントドリブンの考え方を十分に理解しないと、うまくプログラムするのが、めんどうであると感じました。

VSでの開発を考えていますが、Applicationのサイズが大きくなるにつれて、一つのFormであつかうコントロールの数が多くなるにつれて、それらを扱いづらくなる。そしてDocumentOutlineで表示しづらいと感じるなら、カスタムコントロールやユーザーコントロールを使うことがたぶん選択肢に上がる。しかし上記のCOMとイベントドリブンを理解していないと自分の作ったコントロールがほかのコントロールの振る舞いと合致しなくなり、ちぐはぐな感じで扱いにくくなる。そしてこの書き方はわりと定型的に決まっている。VSを使っているなら定型句の挿入にはコードスニペット機能を使えばよい。この定型句を登録しておくと便利だと感じた。（もうあるのかな？

VSというIDEは非常に巨大なIDEです。そこに搭載されている機能は説明なしで使うには非常に多岐にわたっていてすべてを理解するのは困難であり、そしてそれらの一覧や概観ですら十分にわかりやすくないことがあると思います。コードスニペットやマクロは便利なのですが、いまいち機能のプレゼンがないように感じます。

WindowsApplicationならVSが安上がりですけど、そのVSをフルに使うのはなかなかに骨が折れて、WindowsApplicationを満足に開発するのも骨が折れます。

と感じました。

http://itpro.nikkeibp.co.jp/article/EVENTS/20090107/322349/
ARについてのカンファレンスの開催があるらしい。
とっても気になります。

http://plusd.itmedia.co.jp/games/articles/0901/08/news129.html
覚書。デジタルゲームＡＩについての珍しい日本語の記事。
末尾にリンク集がついているので必見。

どうもJudaです。
今回は.net FrameworkのControlの描画順について投稿します。

Controlの描画の順番は基本的にはヒエラルキーを順次読み上げる形式なのです。
VSなどのOutlineで見たときの順番で描画を行っています。
しかし同じ親に属している兄弟のControl同士の描画には描画の上下が存在しています。
そのため、以前の描画領域がどこまでかということに関して、
覚えているようです。

そのため、ちょっと変わった描画をしようとすると描画の順番に気を使わなければなりません。
しかし描画の順番がわかりにくいです。

12/31/2009

12/26/2009

12/23/2009

12/22/2009

12/20/2009

12/19/2009

12/10/2009

12/06/2009

11/14/2009

10/24/2009

10/23/2009

10/19/2009

10/14/2009

10/04/2009

9/27/2009

9/23/2009

9/13/2009

9/06/2009

8/26/2009

8/16/2009

8/02/2009

7/28/2009

7/26/2009

7/18/2009

7/15/2009

7/12/2009

7/09/2009

6/23/2009

6/21/2009

6/14/2009

6/13/2009

6/07/2009

6/01/2009

5/31/2009

5/30/2009

5/29/2009

5/27/2009

5/26/2009

5/24/2009

5/20/2009

5/16/2009

5/15/2009

5/13/2009

5/12/2009

5/11/2009

5/10/2009

5/09/2009

5/06/2009

5/03/2009

5/01/2009

4/30/2009

4/26/2009

4/25/2009

4/23/2009

4/22/2009

4/21/2009

4/20/2009

4/15/2009

4/12/2009

4/05/2009

4/03/2009

3/31/2009

3/29/2009

3/27/2009

3/23/2009

3/22/2009

3/17/2009

3/04/2009