日々吾は

はじめまして

2020-01-20T23:03:00.000+09:00

はじめまして、HN：Judaと申すものです。
このブログは、日々の思いつきや試行錯誤の後をつづることを旨としています。
ここに決定的な解答がかかれないこともままあると思いますが、そういうブログなのでご容赦を。
内容も情報技術やアニメ、マンガで気になるものをPickUpします。

長く続けられるようにゆるくやっていきます。

幸せな未来は「ゲーム」が創る　備忘録その１

2012-01-15T22:47:00.000+09:00

どうもJudaです。
『REALITY IS BROKEN』の邦訳を読んでいる中で特筆すべき記述があったので、備忘録。

ひとつは、ゲーマーはきわめて貴重な―そしてほとんど活用されていない―参加容量提供源だということです。（12行 p. 329 2011年11月15日幸せな未来は「ゲーム」が創る早川書房）
ふたつ目は、クラウドソーシングプロジェクトはー本当に意欲的な目標を達成できるだけの参加容量を集められる見込みが多少なりともある場合にはー優れたゲームが与える報酬と同じような内発的報酬を与えられるように、意図的にデザインする必要があるということです。（16行 p. 329 2011年11月15日幸せな未来は「ゲーム」が創る早川書房）

如何にしてクラウドソーシングをして、少ない人数では達成できないように思えるプロジェクトを達成するのかということに言及している。第三部はそれまでとは一転して発展的な考察が多いので、面白い。

ウォークスルーまとめ

2011-12-26T14:02:00.001+09:00

どうもJudaです。
レビューに引き続き、ウォークスルーについてまとめます。
第8回　ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り込む
点検対象物としては，システムのDFD（Data Flow Diagram），データの正規化結果，E-R（Entity-Relationship）図，データ・ディクショナリ，画面・帳票仕様や操作仕様などの外部入出力仕様，データベース仕様，モジュール構造や処理機能記述，各種の作業手順書などがある。

「ウォークスルー」を成功させるコツ ――ソフトウェア工学のテクニックがHDL設計を支援 part II
一般にレビューは契約ないしは，標準として定められた正式な認証行為である．これに対して，ウォークスルーはよりインフォーマルな活動を指しており，レビューにはない利点をもっている．

他人の設計ドキュメントやコードを読むのであるから，集中力が必要である．したがってウォークスルー自体は短時間に区切って進めるべきである．集中はするが，時間としては「あっさり」すませるべきだ．前述の『ソフトウェアの構造化ウォークスルー』では，ウォークスルーの時間は30分以内が望ましいとしている．

[1]設計された全体の構造
[2]重要で困難な設計箇所
[3]複雑なロジックを実現しているコード

総括すると、

短時間で済ませる。
長時間やることは不適切。例えば30分ぐらいですべてを確認する。
問題全体の構造を理解できるような資料を可視化することが重要。
困難な部分に焦点を当てる。
問題点を対象としてウォークスルーを行う。

コードレビュー解体

2011-12-26T13:44:00.001+09:00

どうもJudaです。
コードレビューがあるので、しっかりと基礎固めをします。
と言っても、まずは既存の解説記事に当たろうと思います。
効率の良いコードレビュー [software]
Effective Code Reviews Without the Pain
レビューの基礎知識
をあげます。

やはり基本的にはコードレビューは、

コードの品質の保証
知識の共有/開発者同士の成長促進

が念頭にあります。

また議論としてコードを題材にしているだけであり、それを記述した個人の資質、存在に言及することはよくないことであると注記しています。つまりよくあることであると言っているのです。

またToshiya HASEGAWA氏の意見である、ソースコードを頭から眺めていくことの非効率性についての言及はもっともであると思います。
しかしToshiya HASEGAWA氏の意見に私見を加えるならばペアレビューでの、文法チェックやコーディングルールの遵守の確認は、あまりに機械的な作業であるため、コンパイラやチェッカで調べればよく、人間でなければならない理由はあまりないと考えます。私はペアレビューをもし行う場合には、局所的なロジックの妥当性確認やクラス単体での呼び出し整合性の確認を行うほうがより苦痛（退屈）が少なくなると推察します。

チームレビューでのチェックは、微に入り細に入ったレビューを行うがため、
The developer often feels like it's a bashing session designed to beat out their will.
（意訳：開発者はコードレビューは彼らの心を打ちのめすために設計された糾弾の打ち合わせのように思っています。）
すべては雰囲気作り次第であるとは言えますが、たやすくそういう場にしてしまうので、参加者すべてがルールを強く守らないといけません。

宿澤経営情報事務所さまの記事では、さまざまなレビューについて簡単にまとめられており、そのなかで挙げられているインスペクションの有用性と落とし穴についても言及されています。この中でも、レビューが個人の資質を糾弾するための記録として利用されるかもしれないという疑心暗鬼のために、自身の資質をPRするために、レビュー自体が活発なものにならない可能性を指摘しています。組織内での政治的な活動の一部が正常なインスペクションを阻害するのです。組織内での政治的な活動のために、協調的教育的な意味合いの近い活動を利用することは本来のレビューの目的を阻害してしまうため、とても強く注意されていますが、やはりそれだけ多く見られる行動であると推察します。

コードレビューの多様な形態やその基本的なルールを勘案すると、

コードというよりも、そこに記述されているロジックを如何にすれば、特定の目的により合致するようにできるのかを多様な解答の中から提案する場としてレビューがある。
個人の資質について言及することは、それ自体がレビューの趣旨に合わず、場の活動を阻害するため、参加者すべてがつよく守るべきルールである。
微に入り細に入りコードをレビューすることは、全体的な質を均一にするためには必要かもしれないが、あまりに時間がかかりすぎるため、ここでもカプセル化を推進し、事象の粒度を粗から細に臨機応変にすることが望ましい。
なぜという問いかけは、その質問自体がコードを記述した個人のみに帰属する問いになるため、絶対にしてはならない。

というのが大枠である。

The Bug Genie

2011-12-16T00:12:00.001+09:00

どうもJudaです。
Issue Tracking Systemを検討中で、掲題のソフトウェアが最近出た奴でいい感じという記事を見つけたので準備中。
せっかくのLinux系のマシンもあるので、いろいろ調べています。導入するためにDBが必要なのだが、この関連の知識に乏しいためインストール手前でぐるぐるしてます。

AndroidでのAdapterView-Adapter

2011-12-07T00:21:00.001+09:00

どうもJudaです。

今日はAndroidでのAdapterVIewとAdapterの関係についてです。

AdapterViewの継承クラスでは、Adapterを使ってデータと表示を密に連携させることだと思います。
この場合にAdapterViewは大量のデータを高速に表示し、スクロールをよりよくサポートしていることを要求されます。

単純なLinearLayoutの実装では、子要素の数が増えれば増えるほど遅くなります。
これは表示可能領域以外の要素の計測、レイアウト、描画を行ってしまうからです。
また合わせて覚えておきたいことは、Androidでもっとも計算コストの高い処理の一つにLayoutInflaterでのinflateメソッドがあります。XMLからのパース処理はAndroidでもやはり遅いのです。またView要素のコンストラクトも同じく重くなる可能性が高く、あまり多用すると著しい処理コストになります。

上記のような制約がある中で、ListViewなどは高速な表示を可能にしています。
これは、一度生成したViewを再度利用しているからです。
ここからがAdapterViewとAdapterの連携に関わります。
AdpaterViewは、onLayoutでItemを準備します。
この際に、新規にレイアウトする際に、スクロール変位を計算し、それのあと可視領域内に残っているView要素のみを残して、可視領域を外れたものをリサイクルするために格納します。ここでAdapterのTypeIDCount分の格納場所が用意されています。
Viewは排除したあとに、新しく可視領域に出現するView要素を子要素として追加します。このときに使われるのが、addViewInLayoutです。この段階では、単純に子要素として追加したのみであるので、計測処理を行い、のちにLayoutを行います。これはAndroidのLayoutメカニズムの基本です。
addViewInLayoutで追加する際に、利用しているViewは、AdapterのgetViewメソッドによって提供されるものです。このときにconvertViewとしてViewが提供されます。このViewは先ほどの可視領域外にでてしまったViewを格納したところからリサイクル用に提供されたり、また存在しない場合にはnullで提供されます。

大まかな流れはこんな感じです。Adapterには、今回説明していない実装を行うことが求められるメソッドがあります。

静的なIDはデータベースで言うところのIDであり、通常使われるPositionは抽象的な意味でリストの「位置」を表します。またこれを抽象的な意味での「位置」とすることで、内部でソートを行っても、フィルタリングをかけても、とにかく該当するデータを取得する、表現を行うViewを提供することの実装部分をうまく隠蔽できます。

ただ、よくできたInterfaceなのですが、AdapterViewからの実装がめんどくさいです。AbsListViewはそもそもの実装がY-座標系指向が強いので、X-座標系向けではありません。

Android覚書

2011-11-23T23:20:00.002+09:00

どうもJudaです。

Androidについてあれこれ。

layoutファイルはlayout*/*に配置される。
layoutファイルでのandroid:*は、xmlnsで定義されているから利用できる。
xmlnsを新しく定義すれば、別の区切りを使えるようになる。しかしEclipseでの入力補助はうまく効かなくなる。
別ファイルに別のlayoutを作成できる。
別ファイルに定義したlayoutは、で呼び出せる。
プログラムから呼び出す場合には、LayoutInflaterを利用する。AndroidのVersionによって呼び出し方が異なるので、要注意。
mergeをrootにもつlayoutは、基本的にはLayoutInfalterからLayoutを呼び出し、親要素に対してアタッチすることが必要になる。
またmergeでアタッチする場合に、親要素はFrameLayoutなどの一部のViewGroupの派生系に限られる。
merge機構を利用して、構築済みのレイアウトを使うカスタムViewコンポーネントを作成できる。
mergeする場合には、親要素とは継承したクラスのことになることが多いので、FrameLayoutなどを継承することで処理を簡略化できる。
inflateしてアタッチした場合はidなどの設定がずれることがあるので、LayoutInflaterのinflateメソッドの戻り値に対して、findViewByIdなどを使うことが必要になる。
onLayoutは、親から呼ばれ、表示可能領域が親要素からの相対的な引数で与えられる。
ViewGroupの系列にあるクラスコンポーネントを開発する場合には、onLayoutやonMeasureを実装することが、必然的に必要になってくる。あとはaddViewの実装を操作するとXMLでのLayoutで子要素を書く数を変えられる。
onLayoutでは、子要素をレイアウトすることが趣旨である。
onLayoutで呼び出す子要素は自身からの相対位置で子要素に対して通知する。その後の配置と描画はここのViewに依存する。MerginやPaddingの取り扱いについては、不定。
onMeasureは自分自身のサイズと子要素をもつ場合には、子要素が確保できるサイズに関して通知をする。はず。。。
onMeasureでは複数のモードを確認する必要性がある。EXACTRY,AT MOST,UNSPECIFIEDがある。
Androidではインスタンスの生成はとてもリソースを必要とする。またLayoutInflaterは更に多くのリソースを必要とする。XMLのパーサが重いらしい。
AndroidではViewの作成が重いため、ListViewとAdapterViewの組み合わせでは、利用したViewを再利用する機構を採用している。
ListViewでは、Scrollによって表示内容が変更された場合に、表示しているViewを減らしたり増やしたりをしている。減らす際に、ViewをRecycleBinに入れておき、なるべく再利用する。またViewの種類が幾つかある場合には、RecycleBinを増やし、種類を識別して対応している。
ListViewやScrollViewはaddChildの利用を制限してる。
独自のクラスを作成し、属性を増やす場合には、value/attrsで記述する。基本的な動作はAndroidのソースコードを参考にすることがよい。またEclipseではattrs.xmlの記述をサポートしてもらえないので、よりソースコードを参考にする必要が出てくる。
ListViewはAbsListViewを継承して作成されているが、あくまでVerticalな動作のみを期待しているので、HorizontalなListViewの実装はAdaperViewなどから実装する必要があり、動作の速度をあげるために、前述のRecycleをする機構を組み込む必要がある。この機構で重要なのは、onLayoutで表示しなくなる要素の確認と、表示しなくなったところを復元するために再度Viewを増やすこと、そしてスクロールオフセットを考慮して、子要素を配置することである。
Scrollerを利用すると、スクローリングやフリックなどの処理を代行させられる。ただし痒いところに手が届かない場合には、再実装が必要になる。
GestureDetector.SimpleOnGestureクラスの実装は痒いところに手がとどかないので、実装内容を確認して、別の実装を組み立てることがより細かな設定を行なっていく上で必要になる。
onDrawを利用することを考えるならば、Drawableの利用を考慮することを推奨する。またsetBackgroundとの兼ね合いが問題にならないように注意したい。
AdapterViewでinflateしてEventを作る場合には、特定のイベントで内容を更新する場合には、そのイベントリスナーに登録する実装はAdapterViewに配置しておかないとうまくnotifyを呼び出せなくなる。
上記のような実装は、階層性を持ったカスタムコンポーネントにそれぞれの処理を実装させてしまうと発生する。（個人の設計ミスであるとは思うが、テストなどをしながら開発しているとよく起こると思う。）
ListViewへのrequestLayoutは子要素のonLayoutの呼び出しを保証しないので、子要素が変化する場合には、子要素自身のrootへrequestLayoutが流れることが必要になる。

読書について

2011-07-18T22:36:00.002+09:00

どうもJudaです。

つらつらと

読書をしながら線を引いたり、

ノートを取ったり、

最近は読むという行為から一歩踏み込んで、

能動的に取り組んでいる。

しかしこの行為をすればするほど、

まとめるという行為が如何に難しいのかが、

明瞭になってくる。

まとめるために能動的に取り組んでいるのではないが、

ノートの分量は増えるし、書き込みも増えてくる。

そうなるとやはり視認性が落ちるし、網羅性も悪くなる。

だんだん頭の中が混線しているような感覚に囚われる。

そういう感覚を契機にして、ふっと、まとめようと思う。

しかし此処に至って、自分が如何に濃度の低い読書をしているのか

突きつけられる。うまくまとめられないのだ。

まとめようにもそれらをまとめていくための柱がうまく決められない。

作者の考えをなぞりながらも、自分の言葉で補足と訂正をおこなうのだが、

事柄をまとめていくための柱と道筋がうまくまとめられない。

なかなかままならぬのだ。

高等教育を受けさせてもらってはいたのだが、

この程度のことも満足できないことに情け無さを感じるが、

しかしやらねばならぬから、じりじり道を登るしかないのである。

Mac OS X+XCode4+Boost

2011-07-18T17:22:00.002+09:00

どうもJudaです。

今日はMacOSXでXCode4を使って、Boostライブラリを利用するときの話。

一般的にはMacPortをつかうみたいですが、i386のアーキテクチャ部分がうまく噛み合わなくて、ライブラリがビルドできなかったりするので、直に使う方法をとります。

基本的にはMacOSXと云えども、Unix系なので、Boostをビルドしたりはできます。

BoostをサイトからDownloadして、展開しておきます。

この段階でstatic libraryを使わないものは利用可能な状態になっています。

XCodeにインクルードパスを追加するときには、VisualStudioとでは考え方がちょっと違って、「ヘッダーを検索するためのパス」を登録しなければいけません。そのため、項目の名前がSearch Header Pathsになってます。User〜というものあるのですが、違いがわかりません。ライブラリに関しても追加ライブラリパスは「ライブラリを検索するためのパス」を登録ということになります。

とりあえずstatic libraryのいらないものはこれでなんとかなります。

次にstatic libraryとかですが、BoostをDarwinでビルドする事になります。なんだかわかんないですけど、BoostのGet Start 〜で書かれているStepにしたがって行います。この時に bootstrap.sh --Prefix=/Path/to/installっていうのがあります。

Unixに慣れている方は普通なのかもしれませんが、WindowsのVisualStudioから来た人にはわかりにくいので、

./b2 というビルドコマンドを発行するだけだと、ビルドをするだけで、./Build installだとさっきの--Prefixで指定したパスへ生成物と必要なものをコピーします。Defaultだと/usr/localになってます。このディレクトリはアクセス制御されていて、読み込みのみの許可になっているので、sudo ./b2 install という風にしてやらないとうまくコピーが出来なくて悩むことになります。

あとはDarwinがGCC4.2のコンパイラを使っているので、XCodeのDefaultのコンパイラ LLVMとは生成物の形式が違うので、dynamic link をさせたときにエラーで落ちる原因になります。要注意です。

んで、実はProgram_Optionsを使ってみようと思っていて、組んで、ビルドはできるけど、うまく実行できず。

CommandLineOptionがうまく機能していないくて大変悲しい目にあってます。

XCodeでCommandLineOptionを指定するときにはXCodeのメニューバーのProductに該当するItemの下の方のEditSchemeで表示されるDialogのRun Argumentみたいな内容の奴にCommnad Line Optionが云々というのがあります。そこを設定すれば一応起動時の引数にはなるようです。

CppCheckの雑感

2011-02-10T18:20:00.004+09:00

どうもJudaです。

CppCheckを利用してみました。

とりあえず日本語の動作がクサイので、setlocale(LC_ALL, "");でビルドをする。

動作的には問題がなさげ。

検出件数とかは、よくわからないけど、未初期化の指摘をしてくれるのが、個人的に嬉しい。

現在わかっている困った点はQtで作成されているGUIで日本語が読めないのか、そもそも日本語パスの扱いがおかしいのか、不明だが、利用できない。

これによって、日本語パス以下にあるファイルの解析がままならない。

手っ取り早く、.NET FrameworkでFork用のGUIだけ準備すればいいのではないかと思う。あとは、Includeディレクトリを常に覚えるのが困るので、とりあえずそこもなんか変えたいと思う。

そんな感じ。

やるきで学ぶTDD

2011-02-09T00:05:00.001+09:00

どうもJudaです。

[ブログ紹介] やる夫で学ぶ TDD

TDDについてまとまっているので、備忘録。

C++における様々なツールについて

2011-02-08T23:55:00.003+09:00

どうもJudaです。
最近CIについて、かなり興味が湧いてきました。また、それ以上に体系的なテストの重要性を痛感している今日この頃ですが。
CIを調べながら、いくつかのツールによる自動化も調査しています。現状ではまだ列挙段階ですが、いくつかのジャンルで情報をまとめておこうと思います。
インスペクションツール
CheckStyle
Uncrustify
Artistic Style

（追記：02/2011/09）Simian

静的解析ツール
CppCheck
ドキュメント化ツール（＋可視化）
Doxygen+Graphviz
OpenSource で利用可能なものはこんな感じですかねぇ。
とりあえず多くの人々がこれらを公開してくれていることに頭が下がります。
Doxygen+Graphvizは導入済みですが、これを自動化して、
Commit毎にドキュメント化するようにするところから初めてみたいですね。
あとはインスペクションツールでリファクタリングの目標を絞ること。
『パターン指向リファクタリング』、
『デザインパターン』、
『実装パターン』、
『リファクタリング』
と開発に関する良い指針となるような書籍を読み進めています。

Rubyの良い教材

2010-12-08T00:35:00.003+09:00

どうもJudaです。

Rubyの良い教材。それは高品質で低価格であること。

そんな我侭な要望を満たす様なカリキュラムがあるのです。
OSSモデルカリキュラム導入実証
ここで公開されている資料はとてもよくまとまってるので、便利である。さらにPDFなので、iPadなどで閲覧するのにうってつけである。
カリキュラムも段階をおっていて、自学習するのにもよい。
これ以外にも公開されているカリキュラムもあるので、合わせて学習してみたら良いと思う。

ちなみに私も現在Rubyの勉強中であり、ここの資料を拝借させていただいている。
主目的としてはRedmineのカスタマイズを行うためである。

Redmineのガントチャートの制御と、Pluginがなぜ動作しなくなるのかを知りたくて勉強している。呼び出しのメソッドが変わったりすると動かなくなるというのは分かる。では翻ってどうすれば正しく動くように修正できるのか。つまりは有用であるが、保守された無くなってしまったPluginを復活させたり、改修したいのである。

Doxygenによる開発のカンフル

2010-11-23T15:07:00.003+09:00

どうもJudaです。

最近Doxygenをはじめました。

Doxygenはコメント生成ツールでかなりメジャーなものだとおもいます。類似したものにはJavaDocやphpDocsとかあるとおもいます。

Doxygenの導入は基本的にはInstallerをOfficialからもらってきて、終わりだとおもいます。DoxygenのGUIとしてDoxyWizardがついているので、比較的簡単にDocumentの生成まではいけるとおもいます。

GraphVizも簡単に手に入れられるので、いれてみるとよりクラスダイアグラムなどが綺麗に画像データになります。

そして、日本語でDoxygenを動かす際にいくつかの問題が起こると思います。

出力ファイルで文字化けが起こること。
入力ファイルが読み込めないこと。
ファイルの検索がうまくされないこと。

１、は基本的にはExpertの設定でDoxygen_OutputEncodingのような設定のパラメータを「Shift_JIS」など日本語に対応したものにすればよいとおもいます。

２、もInputを「Shift_JIS」ないし、日本語に対応したものにして、なおかつ読み込ませるデータのEncodeを整えることと、Encodeできない文字を使用しないということになります。

３、もファイルパスをコピー＆ペーストしているとよく起こるのですが、Doxygenでは￥のディレクトリの区切りが利用できないので、/に変換してください。

それで本題。

DoxygenではCalledByやCallという関数での関係性を表示し、リンクを張ってくれる機能があります。

これを利用すると、呼び出し先と呼び出し元をしっかりしらべることができます。さらに、ソースコードを合わせて出力するようにしていれば、対象となる関数のソースコードを表示してくれるので、より一層ソースコードを探検するのが楽になります。

Doxygenを導入すること、運用することには、コメント付けなどいくつかの規約がありますが、単純に関数の呼び出し関係を整理して表示してくれるので、これだけでもかなりツールとしてありがたいものがあります。ただ静的な解析でのサポートなので、動的な解析はたぶんサポートしていません。それでも改修やDebugのときの一助になることは間違いないでしょう。

SilverlightのDataBinding

2010-11-15T01:41:00.002+09:00

どうもJudaです。

ちょっと失敗こいたので、注意点を。

DataBindingをするときに、DataContextからデータを取ると思う。そのときに対象となるインスタンスの定義がpublicになっていないとDataBindingは失敗する。どうしてか、それは取得と設定がカプセル化されてしまいアクセスするすべがなくなってしまうからである。

Silverlight Sketchflowの変換

2010-11-13T12:53:00.001+09:00

どうもJudaです。

実稼動プロジェクトに変換

http://msdn.microsoft.com/ja-jp/library/ee371158(Expression.30).aspx

今まで散々探したのに見つからなかったのに、今頃見つかるなんて。

Google C++ Test Framework

2010-11-06T11:06:00.002+09:00

どうもJudaです。
最近Google C++ Test Framework(以下googletest)をいまさら導入してみました。
googletestはxUnitの流れをくむTestのFrameworkで少しでもxUnit系のテストについての知識があれば、すぐに使えるという触れ込みです。とりあえず公式な情報を翻訳したサイトで勉強すれば、何とかわかります。ちょっと面白いのは、OpenCVのドメインでGoogleTestDocsの日本語訳がホストされていることかなぁ。
肝心の使い方は、公式に書かれているので、割愛しますが、ちょっと読み解くときに面倒に感じたことをいくつか。

メジャーなコンパイラのためにはすでに特別なプロジェクトが用意されているので、それを利用すること。MSVCとかG++とかは用意されているので、それを利用すればいいので、Cmakeを利用しなくてもいいこと。ただしCmakeを利用した生成もサポートされているので、そちらを利用してもいい。
MSVCに限らないと思うが、Runtimeの種類で別のSolutionが用意されている。たとえば、マルチスレッドとマルチスレッドDLLで別のRuntime体系になるので、別のSolutionが用意されていて、基本的にはマルチスレッドになっている。なので、MSVCの人でMDｄとかMDのRuntimeを使う人は、gtest_md.slnを利用する。
MSVCはテスト用のプロジェクトにgtest.projもしくはgtest_md.projをプロジェクトに含めて、テスト用のProjectはその追加したgoogletestのProjectへの依存関係を作ることが必要である。
TEST_Fを使う場合には事前に::testing::Testクラスを継承したクラスをつくる必要性がある。TEST_F(test_fixture, test_name)でtest_fixtureの部分には利用したい::testing::Testを継承したクラス名を使う。またTest部分ではクラス内部のように変数を扱ってテストできる、はず。
::testing::Testの仮想メソッドにはSetup(),TearDown()があるが、名前は厳密に継承元にある奴でないと動作しない。(当たり前) またそれぞれのクラスの利用のタイミングであるが、それぞれデフォルトコンストラクタやデストラクタでは利用できない仮想メソッドや例外が発生しやすいメソッドの利用などの場合には、利用する価値が出てくると思う。この質問に対する回答もある。

上記のような部分で疑問がわいてくると思う。それよりもまず入門ガイドを読まないと話にならないし、それぞれの利用シナリオもに記述されているので、こちらも参照したい。翻訳サイトがあるので、そちらで知識を得ることを優先して、効率よくテストをするために、まずは効率よくFrameworkを使いこなさないといけない。

継承関係ということについての試論

2010-10-11T02:46:00.002+09:00

どうもJudaです。
ちゃんとOOPを学習していないのですし、該当する書籍を読み込んでいないのでなんともいえませんが、軽症という事象にはいくつかの要因があるのではないかと推察します。

インターフェイス

実装

データ構造

この3要素があると思う。
よく考えずにこれらをごっちゃにして継承をさせていくとどこかで使いにくさが出てくるように思われる。さらにいうとデータ構造の部分が特に危険だと感じています。
インターフェイスの継承は一般的なOOPでの利用に関して合致しそうです。多態性の文脈に合致します。
実装の部分は、特化したインターフェイスを生かし続ける形で実装しないといけないのでとてもナイーブな感じがします。
データ構造に関しては実に困難さを覚えるのですが、多態のためにサブクラス分化するとあまりにクラスが分割されすぎる気もしますし、それぞれの振る舞いがデータ構造に依存しているときにはやりようがないのですが、うまくまとめないと理解しにくくなりすぎる感があります。
どうすりゃいいんだ。OOPはあまりに強い困難さを覚えます。設計ということに向いていないのかもしれない、、、データ構造と実装があまりに緊密になっている感が。。。でもデータ構造が抽象された実装はアルゴリズムとなっているなぁ。。。
インターフェイスはある意味ではさらにもう一層上のレベルでの継承関係をあらわすのかもしれない。
そう仮定すると、COMやインターフェイス志向の記述は、実装を含めたデータ構造を抽象化したものであり、これは一層抽象度が高いので変更可能性強度が増すと思う。

MacでBoostを使う

2010-10-10T22:22:00.005+09:00

どうもJudaです。
とりあえず、作業をする前に調べてみる。

■[Macプログラミング][Boost]MacにC++の高速ライブラリBoostをインストールしたCommentsAdd Startomisima

Mac でBoostCommentsAdd Star

手始めに調べておいていれてみる。いろんなところで実践実践。

2010/10/11 0:14:45
XCodeの最新版を導入
MacPortの導入
導入後にUpdateをかける
BoostJamの導入
Boostの導入<ここでError発生　ちなみにMacOSX SnowLeopard
DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/boost
DEBUG: OS darwin/10.4.0 (Mac OS X 10.6) arch i386
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: universal variant already exists, so not adding the default one
DEBUG: Starting logging for boost
Error: Cannot install boost for the arch(s) 'x86_64' because
Error: its dependency zlib is only installed for the arch 'i386'
Error: and the configured universal_archs 'i386 ppc' are not sufficient.
DEBUG: architecture mismatch
while executing
"macports::_upgrade_mport_deps $mport $target"
(procedure "mportexec" line 26)
invoked from within
"mportexec $workername $target"
Error: Unable to execute port: architecture mismatch
おいおいどうすればいいんだよ。。。
2010/10/11 1:53
なんとなくだけど、
$port varibants boost
でオプションを調べて、
universalを確認してから
$sudo port install boost +universal
ってやるとなんか依存関係もまとめて調べてくれるから、何とかなりそう。
でもBoostのBuildにかかる時間がすげーなげー。か？

2010/10/11 09:51
放置しておいて、朝見たら、Build終わっていた。
---> Computing dependencies for boost
---> Fetching boost
---> Verifying checksum(s) for boost
---> Extracting boost
---> Configuring boost
---> Building boost
---> Staging boost into destroot
---> Installing boost @1.44.0_0+universal
---> Activating boost @1.44.0_0+universal
---> Cleaning boost
とりあえず導入まではできた。

std::vectorは連続領域なのか？

2010-10-10T03:10:00.002+09:00

どうもJudaです。
http://cranehouse.dojin.com/program/vector.html
http://www.s34.co.jp/cpptechdoc/article/vectorastemp/
ここの二つでなんか問題は解決できそうですな。
それにしても、言語の仕様書を読んだのが初めてというへたれっぷり。C#さんの仕様書でも探し読もうかなぁ。
あと先ほどのリンクにあげたS34って会社が大阪にあるので、ちょっと興味ありかも。

Code Kata的な練習

2010-10-08T01:48:00.001+09:00

どうもJudaです。


// Kata000.cpp : コンソール アプリケーションのエントリ ポイントを定義します。
//

#include "stdafx.h"
#include 
#include 
#include 
#include 
#include 


void foreachMethod(const size_t& size)
{
  boost::progress_timer t;

  using namespace boost::lambda;
  using namespace std;
  vector tmpArray(size);
  tmpArray[50] = 200;

  boost::progress_display show_progress( tmpArray.size());
  for_each(
    tmpArray.begin(),
    tmpArray.end(),
    (_1 + 1) );

}
void forMethod(const size_t& size)
{
  boost::progress_timer t;

  using namespace std;
  vector tmpArray(size);
  tmpArray[50] = 200;
  boost::progress_display show_progress( tmpArray.size());
  for( size_t i = 0; i < tmpArray.size(); i++){
    int itt = tmpArray[i] + 1;
    ++show_progress;
    //cout << tmpArray[i] << endl;
  }
}
void foriterMethod(const size_t& size)
{
  boost::progress_timer t;
  using namespace std;
  vector tmpArray(size);
  tmpArray[50] = 200;
  
  boost::progress_display show_progress( tmpArray.size());
  for( 
    vector::const_iterator i = tmpArray.begin();
    i != tmpArray.end(); i++){
    int itt = *i + 1;
    ++show_progress;
    //cout << *i << endl;
  }
}

int _tmain(int argc, _TCHAR* argv[])
{
  const size_t size(1000000);
  foreachMethod(size);
  forMethod(size);
  foriterMethod(size);
 return 0;
}

とりあえずいえるのは、VS2008のReleaseならforeachがはやい。Debugならforが早い。とりあえずどれでもイテレータは遅い。でもこの場合に重要な点は、こんな単純なケースで通常のイテレータ回しはあまり有用ではない、という点と、イテレータでの制御はもっと凝ったもののほうがいいかもしれない。とりあえずforeachすげー。投げる要素数が増えるとかなり露骨に早くなる。

WinSxSについて

2010-09-18T14:57:00.002+09:00

どうもJudaです。
今日はVC++2005から導入されているManifestについての再配置について。
VC++2005以上でコンパイルされたプログラムは、以前存在していたDLL地獄に対応するために、ManifestによるDLLの選択という機構を取り入れました。
これによって起こっている問題は、VC++2003以前でコンパイルして、配布する際には、プライベートアセンブリや共有DLLは同名のDLLファイルが存在していれば、動作できるのです。しかし、これは正しいDLLかどうかは保障されませんでした。DLL地獄の本当のところは調べれば出てきますので、割愛します。
とりあえず手っ取り早く配布をしたい場合には、以下の手順を踏めばいけます。
・VSコマンドプロンプトでmt.exeを動作させます。
・mt.exe -inputresource: -out:を使って、埋め込まれているManifestを分離します。inputfilepathはEXEやDLLをいれて使います。
・分離されたManifestに記述されているDLLを集めます。
・DLLの場所はVisualStudio/VC/redistのところにある場合とWINDOWS/WinSxSにあります。そこから該当するものを取得します。
・WinSxSの場合には、該当するDLLとそのDLLに合致するManifestが必要になります。ManifestファイルはManifestフォルダにあります。ここから取得します。
･アプリケーションを入れるディレクトリにEXEとDLLと同じフォルダ内に、最初に取得したManifestのName属性に記述されている名前と合致するようにフォルダ名を変更して、そこにDLLとそのDLLのためのManifestを入れます。
これでたいてい動きます。それでもWinSxSのエラーが出るときには、コントロールパネル：コンピュータの管理：イベントビュアーにエラーログがでますので、そこから、問題のDLLを調べることができます。
またmt.exeを利用しなくても、VSのソリューションにExeやDLLを登録して、開くとリソースビューが開き、MT_MANIFESTとかかれている項目があります。そこにEXEなら1、DLLなら2と書かれた項目が格納されていますので、それを開きます。その際に表示された文字列が埋めこまれたManifestになります。これは最初に分離したものと同じになります。
またMSDNで記述されているようなDLLのライブラリをフォルダに入れて云々は、Manifestファイルに記述されていない際には、EXEと同じ階層に置くようになりますので、この方法から除外されます。しかしながらDLLのManifestのほうも問題がありますので、そこも要調整になります。

ベクトル解析

2010-07-27T01:55:00.002+09:00

どうもJudaです。
いまさらベクトル解析に本格的に取り掛かりました。
学部自体に専門ではなかったので、特に勉強もせずにすごしていました。これはなかなか興味深いですね。陰関数の特性やスカラー積が何を現しているのかとか、ベクトル積がどういう意味をもつのか。じっくりと基礎の基礎にあたってみるのは、実に価値がある。
同様にこのような基礎に対して、教師なしで学習することができるだけの地力がまだ自分にあることが喜ばしいと感じました。高等教育を受けさせてもらえたことをとても感謝しています。と同時に、高等教育を受けても、その教育が役に立たない、勉強はもう終わりと思っている方が多く見られるのが悲しいです。

Visual Studio 2008 コメント付けについて

2010-07-27T00:07:00.003+09:00

どうもJudaです。

VisualStudo2008でのコメントづけについて

http://emboss.blog28.fc2.com/tb.php/106-4453e599

http://emboss.blog28.fc2.com/blog-entry-106.html

これはいいのだけど、もう開発はストップしてしまっている。こいつはもったいない。ほかにもいろいろなProjectがあるので、VSの力をもっと発揮するために調べてみるのもいいかもしれない。

Silverlight 覚書

2010-07-22T00:15:00.006+09:00

どうもJudaです。

Expression Blend 3のSketchFlowで作成したScreenを別のApplicationでホストすることはあると思います。参照を追加して、xmlns:の名前空間を適応して、いざコントロールをビルドできるようになって、ひと段落ですが、このあとになんかきなくさい実行時エラーがでます。

pb:NavigateToScreenAction TargetScreenのターゲットがうまく見えないっていう罠が。

SketchFlowの時には見えていたものが見えなくなっているのですが、これがまたよくわからない。

あと意外と参照がずれている可能性があるのが、Resource系の.xamlファイルへの参照パス。

SketchFlow時にAppに書き込まれているもののうち、独自のものは再び必要？だったりするので、それも追加する。もっともこれは大本に追加しておけば回避できるような気がする。

KB958017 Rollup Hotfix

WPF デザイナーの修正プログラムロールアップは。

上記の二つが該当するような気がするが、直るかどうかはわからない。

VS2008＋XPでWPFに関連するプログラムはほとんど鬼門である。でもVS2010で直っている保証もないのでややこしい。

またSilverlightはWizardが悪魔のごとき動きをしてくれるので、魂を売り渡せば、もれなく地獄ゆきという特典つきである。問題の調べ方も難解極めるので、ある一定以上になるとExpressionBlendは敵以外の何者でもなくなる。作るコードも汚いし。

追記：7/22 0：41

とりあえず入れてみても問題は解決しない。AG_E_PARSER_BAD_TYPEのエラーはHOTFIXでは解決しない。

またAG_E_PARSER_BAD_TYPEというエラーコードは古くからあるエラーで、XAMLのパルスエラーであるので、かなりの頻度で出るみたい。というか、これ、汎用過ぎて意味わからん。

Solving AG_E_PARSER_BAD_TYPE In Silverlight

このエントリをみると、別のPOSTをみろってある。

AG_E_PARSER_BAD_TYPE Adding Silverlight Toolkit control to module

。。。なんかDLLを足せばなおるって書いてある気がする。

とりあえず文字列でクラスを指定しているところはかなりの確立でエラー起こす。そんな気がする。

でも直し方わからんし、パルスをステップインで追いかけられないし、しょんぼり

追記：7/22 1：00

とりあえずMicrosoft.Expression.Prototyping.Interactivityを参照に追加したら、エラーは起きなくなった。しかし、しかしだ。Navigationがきかないじゃないか。がびーん

NavigateToScreenAction programmatically

で少し調べてみたが、なんか飛び先を指定する文字列に癖があるみたいなことがかかれている。こいつは厄介だ。ここを変数かするのもいいが、そもそもSketchUpで作ったものを移行するのはどうすんだよ。ってところのツッコミがあると思うが、開発末期の部分の処理について書かれたものがない。

とりあえずSketchUpスゲーはわかったから、終わり方を教えてくれ。このゴミのような開発の終わり方を。

そもそもScreen内に遷移情報をかかないわけがないのに、なんでこんなことになるんよ。

DBの覚書

2010-06-27T11:34:00.001+09:00

どうもJudaです。
ＤＢの開発に関する選択肢として、Access、SQLite、PostgreSQLを挙げてみる。
AccessはMicrosoftの製品であり、比較的容易にデータベースを構築出来る。
SQLiteはPublicLicenseであり、ソースもすべて手に入る。
PostgreSQLも似たようなものだが、最近人気になりつつある？MySQLがライセンスが変更されたことによる代替か？
AccessはRDBMSではあるらしいが、データベーストリガとストアドプロシージャがない。
SQLiteはアプリケーションに組み込んで使うタイプのDBMSである。
PostgreSQLがRDBMSとして手軽に利用できるもののようであるが、よく分からない。
RDBMSはコッドの12の法則に準拠してることが必要らしい。
ACIDとかいろいろ定義はあるんだろうけど、DBをやるなら本気で腰をすえていろいろいじらないとTuneUpできそうにない。
SQLite
MicrosoftAccess
Firebird
関連データベース管理システム

Silverlight　Error Code 2104

2010-06-27T05:13:00.002+09:00

どうもJudaです。

SilverlightがErrorCode　2104でエラーしました。

とりあえず調べるべきはIISの設定と、TestPageのparam name="source"で指定しているファイルパス。

いくらビルドしてもこのテストページは更新されないようなので、Projectの名前を変えたときなどは確認が必要です。

拡張保護を使用した統合 Windows 認証ってなんだ？

2010-06-21T01:09:00.004+09:00

どうもJudaです。

http://msdn.microsoft.com/ja-jp/library/dd639324(v=VS.90).aspx

http://msdn.microsoft.com/ja-jp/library/dd470100(VS.95).aspx
Extended Protection for Client Applications

とりあえずなんかVS2008でWebServiceの追加を行って、更新をかけたら、動作がおかしくなったので、調査。もしかするとVS2010を入れると内部のVerが変わるのかも知れない。

ここは調査の必要がある。

追記　2010　06　21　1：46

http://msdn.microsoft.com/ja-jp/library/system.security.authentication.extendedprotection.extendedprotectionpolicy.aspx

Version情報からするとWindows7と.net Framework4 でサポートされているのだけれども、VS2008では当然サポートしていないにも関わらず、なんかエラーでるし。。。

追記　２０１００６２１１：５２

http://connect.microsoft.com/onecare/feedback/details/567198/could-not-load-type-system-security-authentication-extendedprotection-extendedprotectionpolicy-exception-after-automatic-updates-kb976769v2-and-kb908773-installed

どうもWindowXPの特定のUpdateを行うと壊れてしまうみたいだ。

http://lemtodev.blogspot.com/2010/06/could-not-load-type-systemsecurityauthe.html

ここに解析しているものがある。これを読む。

Windows7でのマルチタッチ開発での問題

2010-06-20T03:47:00.001+09:00

どうもJudaです。

Windows７でのマルチタッチアプリケーションの開発についての問題点ですけど、予想通りデバイスの準備ができないことがあがります。またデバイスを用意しても、それが本当にWindows7でのマルチタッチに準拠しているのかは、慎重に確認しなければなりませんし、意外と情報が記載されていないので、早く業界標準になることを祈ります。

現状確認されているだけでもWACOM Bamboo Touchでは独自のWACOM規格のマルチタッチを採用しているので、エミュレートされたいくつかの動作のみしか効かないです。これはすでにCode Recipeに掲載されている情報と実際に上記のデバイスを使って、Windows7＋VS2010＋WPF4で検証しました。動かねぇ。

そして動くと思われているデバイスもちらほら出てきているのですが、仮に対象をNotePCや一体型Desktopが御手軽なので、選択肢に挙がると思いますが、ここで気になるのは、デバッグのやりやすさです。つまり対象PCで開発も同時に行うことも考えると、AtomやCoreDuoでは若干非力ではないかなぁと。そこまで含めると、マルチタッチに対応したディスプレイだけを買うことになりますが、まぁそれほど開発中は主目的で使わないのに、マルチタッチ付きの高いディスプレイを買うのかと言う貧乏開発者のジレンマがあります。

Webサービスを利用する際の大容量データの受信について

2010-06-12T10:28:00.003+09:00

どうもJudaです。
ちょいと失念してしまうことをいくつか。
http://msdn.microsoft.com/ja-jp/library/aa480521.aspx
大量データに対する戦略 -　MSDN
ここに書かれているのですが、
今回はぶち当たったのは、SOAPで提供されているサービスである特定のリクエストに対して大容量データを返す場合に、エラーが起きて受信出来ない問題があったのですが、これは、VisualStudioを利用している場合には、Webサービス参照の追加でSOAPサービスなりを追加するのですが、ここで記述されるApp.configもしくはWeb.ConfigファイルにXML形式で記述されている部分で、受信サイズなどを決定している属性があるのですが、そこがデフォルトの値だとうまく処理ができなかった。
このデフォルト値には、意味があり、不用意な大容量データを受け取らないようにするためであり、基本的には問題にならない。しかし今回起こったような大容量データを受信しようとすると、そこで初めて属性情報に処理を止められると言う事態になる。
この一件を総括するならば、「ウィザードが作ってくれるものは、便利だが、その構築がむき出しの元になったときには困難が起こる」ということになるだろう。これは「達人プログラマ」でも指摘されていることで、悪い魔法使いの話だ。
よくよくデータを確認してみる必要性があるなぁとつくづく思った。

SilverlightにおけるCustom Template Controlの作り方について

2010-05-30T00:48:00.002+09:00

どうもJudaです。

今回はSilverlightにおけるカスタムテンプレートコントロールの説明です。

コントロールのカスタムテンプレートとユーザーコントロール継承の違いですが、私見では、

カスタムテンプレートは、再利用可能なユーザーコントロールの開発
ユーザーコントロール継承は、再利用を含めないユーザーコントロールの開発

であり、後者のユーザーコントロール継承は、特定の部位に別のコントロールを埋め込んだりと言うことを基本的に考えていない場合だと思います。もちろん様々な方法が考えられますが、構造を変えたりはできないので、基本的には作成した際の構造を逸脱することは出来ず、またユーザーコントロールの構造を残したままの改造なので、DependencyPropertyの数が増えすぎる傾向にあります。

今回はCustomTemplateControlの話なのですが、こちらの開発に関しては、注意することは主には二つ。

TemplatePartAttributeなどのパラメータは今度の実装者がどういうパラメータをUIとして定義しているのかを知るための補助的な情報であること。メタデータとして定義されるので、当たり前ですが。
GetTemplateChildというメソッドを使って、自身で定義したフィールド変数にそのコントロールへの参照を設定します。これをしないと煩雑な呼び出しがいっぱいなMFCみたいなことになるので、注意です。

呼び出しのタイミングですが、MSDNのベストプラクティスによれば、OnApplyTemplateのオーバーライドのタイミングが最速になるようです。またイベントの定義の問題などもありますので、変数を直に触らせるのではなく、いくつかのレイヤーをかませて抽象化して、エラーを発生させない機構を作る必要がありますが、あくまで再利用を考えれば、ベストプラクティスに乗っとる必要性がありますが、自己で管理しているレベルでの開発ならば、そこまで神経質になる必要性はなさそうです。

テンプレートコントロールの呼び出しタイミングですが、コンストラクタ→Load→OnApplyTempleteになるので、カスタムユーザーコントロールからの移植の場合には注意が必要になります。

またGeneric.xamlに記述されるので、Blendではすこぶる開発しにくいと思います。また基本的にクラスの定義部分が大きくなりすぎる感がありますので、可能であれば、Partial Classの利用をおすすめします。

Webサービスのリファレンスの追加に関して。

2010-05-23T01:06:00.002+09:00

どうもJudaです。
Webサービスのリファレンスの追加に関して（VS2008）。
Webサービスの追加を行うと、こっそりReferenceファイルが生成されますが、定義から飛ばないと生成されたものを確認できません。定義を確認するとわかるのですが、クラスがpartialで定義されています。これが何を意味するのかと言うと、自動生成のファイルのバックエンドへ変更点を書き込むと更新時に修正、変更した部分を破棄されてしまうので、別ファイルで定義を明確に書いてねって事みたいです。
例えば、EntityのEntityDataという名前のクラスが取得される場合に、その中の要素はPropertyとして生成されます。これに対して、INotifyPropertyChangedを実装しようとします。しかしそれをReferenceに書いてしまうと、更新時に破棄されますので、別ファイルに名前空間に整合性を持たせつつ、PartialなEntityDataを定義します。あとはPartialのキーワードを利用して、各項目のOnChangedやOnChanging（object value）を定義してやれば、独立してプロパティの変更前と変更後の処理を定義出来ます。これでINotifyPropertyChangedを実装可能になります。

DataGridとの憂鬱

2010-05-22T22:30:00.003+09:00

どうもJudaです。
MainPage.xaml.cs


using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.Reflection;

namespace AgScheduler
{
 public partial class MainPage : UserControl
 {
  public MainPage()
  {
   InitializeComponent();
   this.Loaded += new RoutedEventHandler(MainPage_Loaded);
   var list = DataEntity.Users;
   PropertyInfo[] infos = typeof(UserInfo).GetProperties();
   //var q = (from rec in list
   //         select new { Name = rec.名前, Norma = rec.年計, Result = rec.実績 })
   //         .ToArray();
   this.DataContext = infos.AsQueryable();

  }

  void MainPage_Loaded(object sender, RoutedEventArgs e)
  {
   PropertyInfo[] infos = typeof(UserInfo).GetProperties();
   this.dataGrid1.RowHeight = 30;
   this.Foreground = new SolidColorBrush(Colors.Red);
  }


  private void Button_Click(object sender, RoutedEventArgs e)
  {

  }

  private void dataGrid1_SelectionChanged(object sender, SelectionChangedEventArgs e)
  {

  }
 }
 public class hoge
 {
  public string Name { get; set; }
  public double Norma { get; set; }
  public double Result { get; set; }
 }
}

MainPage.xaml


<UserControl
    x:Class="AgScheduler.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:dataInput="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data.Input"
    xmlns:ctrl="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data"
    mc:Ignorable="d"
    d:DesignHeight="600" d:DesignWidth="800">
    <Grid x:Name="LayoutRoot">
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="180" />
            <ColumnDefinition Width="Auto" />
            <ColumnDefinition Width="620*" />
        </Grid.ColumnDefinitions>
        <ctrl:DataGrid Name="dataGrid1"
                       ItemsSource="{Binding}" Grid.Column="2" Margin="0" AutoGenerateColumns="True"
                       SelectionChanged="dataGrid1_SelectionChanged" />
        <Button Content="Help" Click="Button_Click"/>
    </Grid>
</UserControl>

DataEntity.cs


using System;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Ink;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.Collections.Generic;
using System.Linq;

namespace AgScheduler
{
 public class DataEntity
 {
  public static UserInfo CreateUserInfo()
  {
   return new UserInfo()
   {
    ID = 0,
    実績 = 80,
    年計 = 1200,
    名前 = "テスト太郎"
   };
  }
  public static IQueryable Users {
   get
   {
    var list = new List();
    list.AddRange(new UserInfo[]{
     CreateUserInfo(),
     CreateUserInfo(),
     CreateUserInfo(),
     CreateUserInfo(),
     CreateUserInfo(),
     CreateUserInfo(),
     CreateUserInfo(),
     CreateUserInfo()
    });
    return list.AsQueryable();
   }
   set { }
  }
  public static IQueryable Projects { get; set; }
 }
 public class UserInfo
 {
  public int ID { get; set; }
  public string 名前 { get; set; }
  public double 年計 { get; set; }
  public double 実績 { get; set; }
 }
 public class ProjectInfo
 {
  public int ID { get; set; }
  public string ProjectName { get; set; }
  public double ProjectAmount { get; set; }
 }
}

明示的なデータ構造がわかるものじゃないと中身を表示してくれないし、そもそもPropertyInfoは中身を表示してくれない。意味がわからない。無名構造体でも表示はしてくれない。どういうことだ。適応のさせかたのどこかで間違えたことは確かなのだが、どこかわからない。無名構造体が使えないのでは、DataGridに動的にデータを適応しようと思うと困るのだが。

Codeの表示のテスト

2010-05-19T23:01:00.009+09:00

どうもJudaです。
MainPage.xaml.cs


using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.Reflection;

namespace AgScheduler
{
 public partial class MainPage : UserControl
 {
  public MainPage()
  {
   InitializeComponent();
   var list = DataEntity.Users;
   PropertyInfo[] infos = typeof(UserInfo).GetProperties();
   var q = (from rec in DataEntity.Users
        select new
        {
         Name = rec.名前,
         Product = rec.年計,
         Amount = rec.実績
        }).AsQueryable();
   this.dataGrid1.ItemsSource = q;
   this.dataGrid1.UpdateLayout();
   
  }

  private void Button_Click(object sender, RoutedEventArgs e)
  {

  }

  private void dataGrid1_SelectionChanged(object sender, SelectionChangedEventArgs e)
  {

  }
 }
}

Silverlightにおける各種画像のエンコード、デコード

2010-05-16T02:01:00.002+09:00

どうもJudaです。

Silverlight をつかって画像を処理を行いたいなぁとおもっていたり、ファイルを取得して再度変換したいときに、大変なことに気がつきます。

再変換出来ないじゃん
BMPでしか保存出来ないのに、BMP読めないじゃん

意味がわかりません。Silverlightでは、基本的なポリシーとして不適切な攻撃をされる可能性を最小化し、それぞれの実装者の責任に問題を置き直しています。さまざまな部分でセキュリティに重きを置いています。

でもまぁ、そのおかげでいろいろな部分で変更が効くようになっているので助かります。

とりあえず画像データのEncode,Decodeのためのオープンソースを紹介します。

http://code.google.com/p/fjcore/

とりあえずソースを読んでいますが、なかなか便利ですね。

ADO.NETのあれこれ

2010-05-14T11:01:00.002+09:00

どうもJudaです。

BaseListとBaseEntityの話

http://d.hatena.ne.jp/wave1008/20090324

http://d.hatena.ne.jp/wave1008/20090330/p1

まさにこの通りで、Reference.csに自動生成されているものに対してINotifyPropertyChangedを実装しないといけないので、面倒で面倒で仕方ないです。
そもそもEntityを生で扱うとめんどくさいことになるので、困りますね。

LINQ

2010-05-11T01:25:00.001+09:00

どうもJudaです。
LINQはここがめちゃくわしい。
日向ぼっこデベロッパhandcraftの備忘録
http://handcraft.blogsite.org/ComponentGeek/ShowArticle/66.aspx

ADO.NET Data Service のデータの追加、削除、更新

2010-05-10T14:41:00.001+09:00

どうもJudaです。

ADO.NET Data Service のデータの追加、削除、更新についてのサイト

ADO.NET Data Services Part 7: Data Modification - Client

http://lostintangent.com/2007/12/30/adonet-data-services-part-7-data-modification-client/

こりゃ詳しい。

ADO.NET Data Serviceについて

2010-05-06T00:56:00.002+09:00

どうもJudaです。

ADO.NET Data Servicesについてですが、主キーでNot NullableなAutoIncrimentなカラムの値の設定方法ですが、どうも値を自動で上書きされるようです。

それ以上に注意しないといけないのは、Entity FrameworkのEntity Data Modelで接続部分をになってくれる構造体群に対しては、接続元になっているDBの各列の型、既定値、Null許容かなどの、「SQL Expressでつくったから、Wizardがやってくれている」と幻想をいだいているものは大半がダメです。そげぶされます。

明示的に設定するようにMSDNでも書いてあります。調べないとわからないのですけど、ちょっとはどこかに書いて欲しいものであります。

また失敗した場合のエラーログが欲しい場合は、Wizardが書いてくれているコードに対して、いくつかの属性を設定すればより詳しいエラーメッセージを得られるのですが、前に書いたのを忘れたので、探しています。属性についても本当に調べにくい。そのくせ、属性すごく重要。

それとLINQにはAutoIncrimentに関する操作は特にはないです。だから今度はUpdateで揉めそうです。うわー、嫌だなぁー。

SilverlightとDBの連携

2010-05-05T12:39:00.002+09:00

どうもJudaです。

Silverlight : ADO.NET Data Services (Silverlight)

http://msdn.microsoft.com/ja-jp/library/cc838234(v=VS.95).aspx

まぁ連携についての情報はここが一番詳しそうです。

ちなみに疑問になるのは、Entity Frameworkを利用した際に、Viewに該当するものは、基本的にUpdateやDeleteは出来ないのではないかと言うことであり、Wizardを通じて、AddToで定義されるメソッドにもViewのものが混在しうるけれども、これについてはプログラマが意識的に使わないように心がけないといけないものなのだろうか？

SilverlightでのDataDrivenでの注意

2010-05-04T15:51:00.002+09:00

どうもJudaです。

プロパティの変更を通知するインターフェイスの実装をしているクラス
INotifyPropertyChangeでの注意。

文字列で指定するプロパティ名は、
別の参照されている部分で使われているバインディングパスの名前と
同一でないと機能しない。

だからバインドを統括するようなクラスをDataContextにして
それぞれ同じデータを別のエイリアスでつかっている場合には、
それら全てに適応できるように読み換えや
同時に複数の変更を通知するようにしないといけない。

本当はエイリアスのような使い方をする場合には
もっと気をつかった設計を行う必要性があると思われる。

もっともなるべく同一の名称になるようにクラスを調整する方が推奨されるだろう。
しかし今回のような注意点は、複数の提供元によって作成されたコントロール間で
協調させたい場合には、協調を制御する統括クラスにはそれなりの対応が求められる。

SilverlightでのXMLシリアライズ

2010-05-04T01:05:00.005+09:00

どうもJudaです。

dobon.net

かずきのBlogさん

MSDN　＋ MSDNライブラリ

waりとnaはてな日記

すまないが、XMLの書き出し、読み込みをもうちょっと簡単にしたい。

System.Runtime.Serialization.DataContractSerializer

をつかえば、なんとかなる。というか、なんとかできる。

でも正しい使い方なのかわからない。

とりあえずSilverlightでXMLを読み書きするときには、便利なクラス。

というか、XMLの解析をガチでやらせようと思うと、めんどくさくてくさくて、仕方がないです。

ありがとう、XMLの簡単な読み書き機能を作ってくれた開発者の方。

それにしてもXMLにある潜在的なセキュリティーホールとか怖いなぁ。まぁ、全ての入力はすべからく怖いのか。

Silverlightとインターフェイスの話

2010-04-29T09:52:00.002+09:00

どうもJudaです。
XAMLの技術とInterfaceの親和性についての話。
XAMLで記述して、事前にデータバインディングのターゲットを固定させて、そこへのアクセスを確率できるようなInterfaceを公開することは有益なのだろうかと言う問から端を発しました。
試作段階に置いてXAMLで表示したいものと表示の形式がある程度固まると、そのバックエンドとなる部分で調整になると思います。その時に、もっとも合致する機能はInterfaceではないのかという思いつきですが、そこそこ有益だと思います。
Interfaceなら実装を保証させるので、それによってバインディングエラーを減らすことができます。ここで注意したいのは、XAMLのほうでTwoWayを採用するなら、Interfaceに必ずSetterを書いておく方が混乱が少ないのですが、それ以外のOneTime、OneWayの場合には、それはInterfaceで規約するのではなく、実装側の裁量に任せる方がいいとおもう。また、OneWay、TwoWayの場合にはINotifyPropertyChangedの継承が実装側で最終的に必要になるので、それも検討しておきたい。
別の話にはなるが、INotifyPropertyChangedでプロパティの変更を検知する処理を組み込んで、Setterなりを修正するのだけれども、この場合には、自作でSnippet、もしくはマクロを組むことが有効であると思う。大半のコードが同一になるので、これをおすすめしたい。しかしながら、簡易でPropertyを書いた場合、つまり　get;set;のプロパティへの変更検知機能の追加はめんどくさい。なんとかならないのかと思っている。
話は戻るが、Interfaceの基本的な考え方とXAMLでのバインディングの記述の間にある程度の親和性があり、これを再利用出来る形で提供すると面白いのではないかと思う。しかしこれでは何が問題になるってくるのか、まではまだちゃんと確認出来ていない。Interfaceがそういう具体性を求めているのではないとすれば、この考え方はあまり良くないと思うが、個別の開発でフロントエンドとバックエンドを分離して開発するときには、いちいち名称の確認をとらなくてもよくなって、個人的にはいいと考えた。

DataServiceKeyAttribute("ID")

2010-04-26T18:06:00.002+09:00

どうもJudaです。

Reference.cs

[global::System.Data.Services.Common.DataServiceKeyAttribute("ID")]

こいつか。。。

昔おいらを苦しめたのは。。。。

追記；

あれ、違う。。。

Silverlight Content Controlについて

2010-04-25T21:22:00.003+09:00

どうもJudaです。

いっこ前の話

なんとなくですけど、Contentって名前は既に使われているので、これをそのまましようすることはできないので、DependencyPropertyでObjectで任意のコントロールを生成する。そしてPropertyのSetterで登録を行えば、なんとか認識して使用できますが、明確に登録するプロパティを使用しないイケないので、ちょいと見栄えが悪くなります。ここらへんはどうすればいいのかわからない。

SilverlightにおけるCustom Content Control

2010-04-25T02:21:00.002+09:00

どうもJudaです。

Silverlight Custom Content Control

まさに掲題のとおり、Contentを表示したい時があります。

けれども簡単に行う方法はよくよく調べないとわかりません。Custom Template Bindingもひとつの手ですが、それもそれでなかなか大変なのです。（本当か？

Silverlight 2 のカスタムコントロールを作成する

うん、なんかいろいろめんどくさい。

HgInitの試訳

2010-03-27T23:33:00.003+09:00

どうもJudaです。

JoelがMercurialの入門手引きを書いたので、かっとなって日本語に訳してみた。最初の頁のとちゅうまでだけどね。

--以下訳--

私の会社にいるプログラマたちがSubversionからMercurialへ乗り換えることを決めたとき、ジョエル少年は混乱してしまった。

はじめに、あらゆる乗り換えるべきでないくだらない理由に付き合ってくれた。”私は中央サーバにリポジトリを保持すべきであり、それが安全だと思う。””君はしっているのか？君はあまり詳しくないだろうがMercurialでは全ての開発者が自らのハードディクス上にリポジトリ全体のコピーをもつんだよ。それは実際にはより安全だろう。なにより、大抵のMercurialを採用したチームは中央サーバもつかうし、君がBackupをとらなければならないという強迫観念にかられるようなら、そうしよう。また君は3層にもなるセキュリティー、Cylons、Stromtroopers、またはをささやかな開放的な領域を構築できるよ。"

"煩雑なバージョン管理によるトラブルはブランチすることによってすぐに起きてしまうし、ブランチをつくることは常に問題を起こす。””結局この考えも良くない。いずれ悪い結果がおきる。Subversionでブランチすることは問題を発生するのは、Subversionはマージ処理をおこなうのに十分な情報を持っていないからだ。Mercurialでは、マージは苦痛じゃないし、簡単だ、そしてブランチはありふれたことだし、害もない。

”そいつはいいね、つかってみるよ。でもとても僕には理解できるようには思えないよ”僕はJacobにMercurialでSubversionで行っていた事と同等のことをできるようにCheatSheetをつくってくれるように頼んだ。

いま、私はこのCheatSheetを君にみせれる、でもしない。それは数カ月のものあいだ混乱のもとだったからだ。

結局のところ、Subvesionをつかっていたとしよう、それは君の脳をすこし、えっと礼儀正しく言うにはどうすればいいのかな。その、イカれちまってる。おっとこれはよくない。君には少し再教育が必要になる。私が半年の間MercurialがSubvesionよりも複雑だと考えることによってイカれちまった部分を探してみた。でもそれは私がMercurialがどういう働きをするのか理解していなかったから、一度分かれば、ちんからほい、Mercurialはある意味簡単だ。

だから私は君のために手引書を書いている。この手引書では、慎重にSubvesionの意味で説明しないようにした。それもこれ以上の混乱のもとをなくすためだ。もう混乱のもとはたくさんだ。代わりにSubvesionからきた人たちのためにMercurialを勉強するために可能な限り綺麗な状態に戻そうと一章つかってやってみようと思う。

Subvesionを使ったことがないのなら、次の章にいくといいよ。見逃さないでね！

準備はいい？いくよ。ここで簡単なクイズ！
Q1. 初回で完璧なソースを書けますか？
もし君がはいと答えたら、君はとんでもない嘘つきだし、詐欺師だ。君は失格。また試験を受けてくれ。

新しいコードはバグに満ちている。ちゃんと働かせるには、すこし時間がかかります。その間の時間、チームの他の開発者の苦痛になります。

このとき、Subvesionはどのように働くか、
新しいコードをチェックインするとき、みんなトラウマコードを取得します。
君の書いた全ての新しいコードはバグだらけですので、君は悩みます。
バグのあるコードをチェックインして、他の開発者に苦痛を与える。
バグがなくなるまでの間、チェックインをしないようにする。
Subvesionは常にこの苦しいジレンマを起こします。リポジトリはバグで満ちている。新しいコードを入れてもバグを含むし、また新しいコードを管理しないならそれもバグだ。
Subvesionをつかうひとなら、このジレンマが存在しないことを想像できないでしょう。

Subversionをつかうチームはしばしば何日もあるいは何週間も何もチェックインしないことがある。Subversionチームでは、新入りはあらゆるコードをチェックインすることを恐れる。ビルドを壊してしまうこと、つまり年長の開発者のマイクさんやそういったお歴々を怒らせるを恐れる。マイクはすぐにチェックインによってビルドが壊れたことに腹を立てて、インターンのいるパーティションまでやってきて、彼の机の上のものを全部払いのけて、「てめぇはクビだ！」と叫ぶでしょう。（もっともそうならなくても、哀れなインターンはパンツを濡らしちゃいますけどね。）
あらゆるこの種のチェックインに関するおそれはみんながコードを何週もの間バージョン管理のご利益を得ずにソースを書くことをいみし、そしてこの状況に気づいたある年長の開発者がそれらをチェックインするように助けて回る。
どうしてバージョン管理が使えないのに、バージョン管理を導入したいと考えるだろう。

--ここまで訳--

確かにSubversionのジレンマはそのとおりだと思う。しかもこれでブランチを作りまくれば、まぁ大変になるのも仕方なし。とりあえずはやく全部読む。

ADO.NET Data Serviceにおける注意点

2010-03-27T15:24:00.007+09:00

どうもJudaです。

ADO.NET Data Serviceの暗黙的な制約があるっぽいので、注意を。

このサービスを作るときに.svc.csファイルに記述をしていくと思いますが、この時に注意があります。基礎となるデータ構造へのアクセスを提供するIQueryableのプロパティを持つクラスはすべて一箇所にDataServiceと同じところに書いておかないとサービスが使えない。どうもそうらしい。もう少し厳密に調べてみる。それにしてもややこしいなぁ、このシステム。どうも最近VisualStudioのWizardが生成するコードとの相性が悪い。どうも道から離れているみたい。

追記

どうも原因が一定しないみたい。問題を捉えたと思ったら逃げられた。一箇所にデータを入れておいたのに、サービスが認識されない。要求エラーが表示されて、内部にエラーが潜在してしまう。作り方自体は、各種サンプルを参考にしているがどうしても問題点を捉え損なう。

バイナリ化しているものの参照がうまく行っていない気もするけれど、いかにしてそれを捕まえるのか分からない。最近こんなんばっか。はしごが外されている。

もいっちょ追記。

DataServiceのTが扱っているEntityにNullにならない一意なIDになるものプロパティがないと、駄目だ。これがないだけで、全てがおじゃんになる。あとはEnumの継承型をEntityに含めることはできない。使えないんだよ。だから、大抵はint,stringのオンパレード。ちなみにDateTimeも使えない。これが痛い。使えるのかも知れないけど、とりあえず直接は入れられない。とりあえずこうすれば、コードを分割して記述してもいけるし、DLLで参照もできる。これもEntityをDBから作らないから、エラー出力をする属性も分からないし、調べ方も分からない。

ADO.NET Data ServicesあらためてWCF Data Services

2010-03-26T15:05:00.002+09:00

どうもJudaです。

ここにいい導入発見。いくつかの注意点をあとから洗い出します

Using Microsoft ADO.NET Data Services（http://msdn.microsoft.com/library/cc907912.aspx）

Silverlightのためのいくつかの話

2010-03-25T22:15:00.002+09:00

どうもJudaです。
Silverlightリファレンスブック
ASP.NET MVC実践プログラミング―.NET Frameworkによる標準Web開発技法
Silverlightで開発するデータ駆動アプリケーション
とりあえずこの3冊は現状で手に入る日本語のSilverlightまわりの書籍としてはとってもいい。

リファレンスブックは、「そうなんだよ、この実装をどうやるか知りたかったんだよ」っていうものがちらほら。
ASP.NETは、「そもそもSilverlightのクロスドメイン回避するWebサービスが必要だな」ってときに助かる。
データ駆動は、「Silverlightを使い倒してやる」っていうアプリケーション開発者にはぴったりな一冊。

ADO.NET Data Servicesに関する情報は少ないし、そもそもWebアプリケーションに関するビビッとくる本に未だ出会えていない。誰かご存じないですかねぇ。

Silverlightのイベントについて

2010-03-24T11:28:00.003+09:00

どうもJudaです。

Silverlight のイベントの概要

Silverlight のカスタムクラスのイベントの定義

RoutedEventは既存のSilverlightのコントロール以外には適応されないようです。

2010-03-23T23:34:00.005+09:00

どうもJudaです。
いきなりSilverlightというか、WPFというか、
Bindingで使われるDependencyPropertyの話をMSDNの項目からかなり抜粋するが、
細かな部分だが結構込み入った使い方をする。
依存関係プロパティは、DependencyObjectに存在するPropertyのことで、
DependencyObjectプロパティストアに格納されている。
このプロパティストアを所有するDependencyObjectは、
public static readonlyで修飾されるDependencyProperty識別子を使って、識別される。
この依存関係プロパティを実装しようと思うと、通常のプロパティ(CLRプロパティ)をラップする必要性がある。
この依存関係プロパティがなぜ「依存関係」プロパティというのかという一因は、
あるプロパティが別のプロパティを値としてい持てるからであり、
実行時までその値を評価するのを遅延させることができ、
そのことによってプロパティに依存関係を作ることができるからである。
これはBindingとも関連する。
このプロパティを記法は似ているが、異なる添付プロパティが存在する。
例えば、Canvas.Leftのような個別のオブジェクトが所有していないプロパティである。
この添付プロパティの実装は、依存関係プロパティと似ているが、
設定された値が、自身ではなく、要素に対する付加的な意味合いがある。

カスタムしたイベント群を作っていこうと思うと、後半の添付プロパティをうまく使っていかないと、
XAMLで楽をできない。
ましてや、サポートされていない機能であるDrag&DropやDoubleClickの基本構造を適応していこうと思うと、
添付プロパティを使わなくてはとてもコーディングできると思えない。

ただイベントの登録をどうするのかが若干困りものではある。
大まかにはわかるのだが、
Propertyとして設定しようとして
そのプロパティを呼び出したときのオブジェクトを知らせてくれるならば、
オブジェクトとともにイベントハンドラを持てばいいのだろう。

関連付けさえうまくできればなんとかできそうではあるが、煩雑なことにはかわりない。
あとはListBoxからのDrag&Dropに関しても、内部で取得されるItemsSourceが不定であるので、
Converterを指定し、さらにDrag時の描画や、Dragのイベントなどの処理まで考えるとうんざりしてしまう。
ちょうどいいことにライブラリはあるのだが、Telerikのライブラリいいんだけど、10万も出せません＞＜
でもこの機能で10万は安い買い物だと思います。
ちなみに体験版もあるので、ぜひ！

Vimでのコメントアウトについて

2010-03-22T02:28:00.002+09:00

どうもJudaです。

掲題の件に該当する記事のサルベージ

Vim Tip: Comment out multiple lines

commentout.vim : ソースをコメントアウト ←→ コメントアウト解除

とりあえず一番上の英語をオレオレ訳

Vimのプラグインなしで、一連の行をコメントアウトすることについて

ヴィジュアルブロックでコメントアウトしたい行を選択して、そのときに”I”を入力する。これは、選択した部分の頭に挿入を行うためだ。次にコメントアウト用の文字を入力する。PythonやShellなどなら＃だ。そのあとでESCする。

頻繁には使わないけど、時々使う便利なVimコマンドを忘れてしまう。ブログに書けばいいのに。

君はヴィジュアルラインで選択したものについては別の方法を使える。　”s/^/#”ってやつだ。

こいつなら行頭にコメントアウト用の文字をくっつけることをができるさ。

って感じか？

電子書籍の新しい形をサービスへ

2010-03-21T01:59:00.002+09:00

どうもJudaです。

前回描いた電子書籍の新しい形をやっぱりサービスにしたい。

友人と話をしていてとっても勇気づけられたから、なんとか夏までにサービスに原型を作る。

そのときに新しくあるといい機能が出たので、メモしておく。

本から別の本への参照機能
気に入った部分のリスト機能
リスト公開機能
書籍の情報入力の簡易化

とりあえずメモの共有機能をやるとどうなるのかやってみる。

電子書籍というよりも書籍型アプリについて

2010-03-20T00:08:00.002+09:00

どうもJudaです。
今日は面白そうだと思った。電子書籍のやり方をぽつぽつと。

まずはTweet抜粋

書籍化されたアプリ。。。これは、面白い。　これに追加して、他人のメモが挟まっていたりするとおもしろいのではないだろうか？　 http://bit.ly/abQUHL

書籍化されたアプリというニュアンスはとても心地いい。そしてそれはこれから電子書籍をどうしていくのかについて、とてもいい指針を表している。 VerUpしていく書籍ということを考えていたが、これにMedia機能を盛り込んでいくことによって、これまでの書籍とは価値の違う書籍を提供できる。

実はその手前に電子カルテを見据えている。これの普及が日本での鍵かな。日本の出版業界には期待していないので。

何を考えているのかというと、既存の紙媒体の書籍と電子書籍の棲み分け。既存の紙媒体をただ代替するだけでは、あまりに電子書籍という考え方は面白くないし、そもそも出版業界が邪魔をするのでうまく普及できない。日本ではKindleが対応していないが、一応EPUBという形式はあるが、普及はしていない。既存の紙媒体の特徴というのは

無電力
高い保存性
印刷したものは変化しない
可読性の高さ
自由度が高い
版組がきっちりしている
物理的なコンテナを持っている
紙の感触をもつ
重さがある
手に入れるまでに時間がかかる
索引があるけれど、検索はできない

これらが主な要素として挙げられる。そこで電子書籍はなるべくこれと競合しないように考えてみる。

電気を使う
電源を切ると見えなくなる
買った状態から書かれている内容が変わる
可読性は変化できる
自由度は制限される
版組を変更できる
書籍自体の物理的なコンテナはない
紙の感触はない
書籍自体としての重さはない
オンデマンドに手に入る
索引がなくても、全文検索などができる。

こうして考えてみると、現在のブログに近いところが多い。ここまで来てしまうと、情報という意味が強く押し出されてしまって、書籍らしさというものはない。もっとも書籍らしさというものも物理的なコンテナの制約がなくなる時点でとてもあやふやではあるとおもう。
さて話は戻るがここで一つ、試みを足してみる。それは他のメディアを補強するものとして、文字を使うことである。ちなみにこれはすでにペンギンブックスなどが試みている。しかし私は、この方向も面白いが、情報量的な制約によってできることとできないこともあるし、それ以上にこれでは書籍じゃない。雑誌のグラビアが動画になっているのもいいけれど、もっと猥雑さを足してみたい。
例えば書籍にメモを貼れるようにして、それをTwitterや、ニコニコ動画のようにみんなで共有する。現実の本で考えるならば、たくさんのポストイットが貼られている感じ。これがみんなで共有できるのは、オモシロイと思う。ブログに対してコメントを残していく事に比べて、敷居が下がるかどうかは、分からないが、動画にコメントをする行為が受け入れられているので、それほど悩ましい問題ではないかもしれない。
いままでこれをやろうとすると、どうしても同時性に欠けてしまったり、物理的に賃借しなければ読めないことなどがあるが、その問題は電子書籍ではなくなるし、そもそも本を読んでいる人の輪はネットワーク上で補填されるの、地理的な意味は薄くなる。
これは読者側の一体感や同時性を演出するための仕掛け。おなじコンテキストを共有することに対しての提案としての電子書籍。
もう一つ、書籍自体の改版のあり方について、変えてみたい。つまりはVerUpする書籍。あるいはBeta書籍。
現在の書籍は常に完成された形で生まれてきて、長い時間の間で若干の修正が入る。ServicePackがあたるようなもんだ。では、これをBetaで公開しましょう。Alphaで公開しましょう。もしこれを有償のサービスとしてやるなら、Alphaで参加した人は、Betaで参加した人よりも安く手に入り、作者は早い内から読者のFeedBackをもらえる。仮に完成したなら、それを書籍として物理的に発売してもいいだろう。これは、代謝の激しい技術書の世界で根づいてくれるなら、とても嬉しいサービスだ。
つまり技術書、とくにコンピュータ関係の書籍はVerUpによって変更がよく起きる。しかしそれは基本的なものを全部捨て去るほどのものではないし、次の版で、新しいVerのことが追加されて発売されることもままある。そのために良書の版違いをいくつも集めなければいけないことに忸怩たる思いをしている。その問題を解消することが狙いである。あとは、技術書ならば、サンプルを足してもいいし、わかりにくいところを補稿をしてもいい。つまり完全な書籍を販売できないので、不完全な状態から公開、販売し、それを継続的にケアしていく。
こうすることによって、電子書籍は紙書籍とは異なるプロセスで成長できるとおもう。現状の販売システムとは異なるものであり、販売のタイプはライセンス系の契約事項に似てくると思う。そこまで含めてケアできるサービスと、クライアントを用意できれば、これはとてもオモシロイと思う。文字情報をなるべく紙媒体で読みたいという要望は、いずれ電子ペーパーが近いものを提示してくると思う。でも、あくまで紙の代替ではないやり方を電子書籍が追求すると、とてもいい。
こういうビジネスをやりたいなぁ。

Silverlightとの戦い

2010-03-17T23:58:00.002+09:00

どうもJudaです。
Silverlightと最近は格闘中ですが、面白いです。TemplateやBindingはパワフルで使い出のあるアドバンテージです。これらの機能を使いこなすことでコーディング量を劇的に減らすこともできますし、自分の中のデータとビューの関係性を捉え直す機会もくれます。実に取り組みがいのある技術です。この先には、まだまだ多くの発展技術がいることを考えると、挫けそうですが。
それはそうとSilverlight4RCがきましたが、まだ確認をしていません。それよりなによりVerUpの頻度が多い気がします。それ自体は悪いことではないですが、技術書が出揃わないうちにVerUpされると出版側が手を出しにくくなって、困ります。ただでさえ、少ないのに。
ブログなどもいくつも見ていますが、重要なのは基本的な機能に十分習熟することと、Bindingをコード側からも理解することがかなり重要ですね。特にとっつきづらいのはCanvasとGridの実際的な制約事項。
Canvasは自由配置できるのですが、Grid内に配置しても自由に配置を出来ること。Gridのみの場合には、自由配置が全くできないので、XAML側での構造の構築には気を使わなければなりません。あとはDrag&Drop機能を使おうと思うときには、構造をよくよく見れば明白ですが、ListBotのListBoxItemはListBoxの外ではそのまま使えないので、取り出したあとなんらかのコンテナを必要とする点や、データ自体の受け渡しのみならば、別のItemSoruceをもつものとも融通がきくことなど。
実際にコードを触らないとあまりに些末で考えなければならないことが多いです。

Silverlightのパス指定

2010-03-16T11:11:00.000+09:00

どうもJudaです。

Silverlightのパス指定について、重要なことを一つ。

パスの区切りは\ではなく、/。ましてや￥は使えない。

これすごい重要。

VSでIntelliSenceのセンスがインテリでもセンスでもなくなったとき

2010-03-02T08:22:00.002+09:00

どうもJudaです。

VS2008でIntelliSenceが使い物にならなくなりました。その解決方法は、devenv.exe のコマンドオプション　/resetsettingもしくは/resetskippkgsのいずれかを用いて、設定がうまく更新されない問題を再設定を行なうことによって解消します。

このオプションの存在を知らないと、延々と続く再インストールを行い、なおかつ設定が変更されていないので、結局IntelliSenceがつかいものにならないという事態が発生してもおかしくないので、なにかこまったことがあったときには実行ファイルをコマンドプロンプトで実行してオプションを知るのもいいなぁと感じました。それにしてもVSは知らない機能が多くありすぎて、使いこなせていないのも一つあります。また悲しいことにVSの説明書はどれも初心者のためのものが多くあり、中級で普段の使い方になれて、次の段階へ移行しようとする開発者にとっては使い物になりません。Keyboardの隠しショートカットの存在とか、アドオンの設定とか。

Silverlightの開発環境

2010-02-22T10:20:00.001+09:00

どうもJudaです。

Silverlightの開発環境はここをみれば、一発。だってここが本家だもの。

Silverlightのためのいくつかの話

2010-02-21T23:08:00.003+09:00

どうもJudaです。

Silverlight SDK Sample Browser
SDKのサンプル集であり、実行形式になっているものばかりだから、とてもわかりやすい。。。とは言い難いが、それでも基本的な使用方法はよくわかるので参考にされたし。

基本的な使用方法のなかで、全画面表示を考えている場合には、とても重要な情報があります。
全画面表示サポート
使い方に関しては、書かれているがこれはとてつもなくわかりにくい。
基本的な開発をVisualStudioで行うことを考えていると思いますが、この場合に重要になるのは、基本的にはProjectNameで作られたXAMLやcsファイルに対して変更を加えていきますが、この場合にSampleとして上げられているものはどこに導入すればいいのかさっぱりです。
＠IT - [Silverlight 2]Silverlight アプリケーションをフルスクリーンで表示するには？
この記事を利用すれば比較的簡単にボタンに対して処理を使っていけましょう。
これで導入ができますが、これよりも詳細なものの設定は個別のイベントに対しておこないます。
しかしここで4未満においては入力関係に対しては制限がかかります。4からはOut of Browseモードでのみ全画面時にキーボード系の入力を受け付けるみたいですが、これがIn Browseでつかえるのかは謎です。たぶんできないのだと思います。
ほかにも全画面表示の解除を行うためのキーのバインドを変更することができません。ちょっと調べただけですが。
Pageクラスがこの全画面関連のメソッドをもっているので、このクラスを継承もしくは利用するクラスを作成すれば良さそうですが、それでも連携部分に対して不安が残ります。

簡単に調べただけなので、これらの情報の確度は不定です。

SilverLightについての少々の覚書

2010-02-11T22:33:00.001+09:00

どうもJudaです。

SilverLiｇｈｔの初心者向けにいくつか簡単な説明を

Grid要素の下に、ColumnDefinitions、RowDefinisionsを設定して、その子要素としてColumnDefinition、RowDefinisionを必要な分だけ指定してやらないと、その次にTextBoxやButtonを設定してそのプロパティとしてGrid.Row="０"やGrid.Column="０"をやってもうまく表示指定できません。段の組み方などは従来のTable組みと同じです。ただ定義部分とデータ部分が分離されている点がHTMLの時とは若干異なります。

この点を無視して出来るのはCanvasですが、きっちりとした位置取りを行いたいときには面倒かも知れません。

また最初の状態でGridの名前がLayoutRootのものはたしかひとつしか宣言できませんが、これはGridコントロールが唯一と言う意味ではありません。Grid要素の内部にGrid要素を作って入れ子状態にできます。

また塗潰を行うRectangleですが、Gridのときには基本的には指定したセルにフィットしますが、サイズがちぐはぐになると、角の丸め表示などの部分が切られてしまうことがあるので、幅と高さの指定については要注意です。

SilverLight 簡単サンプル

2010-01-24T22:26:00.005+09:00

どうもJudaです。

MainPage.xaml.cs


using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace SilverBullet
{
 public partial class MainPage : UserControl
 {
  //BookmarkList m_listBookmark = null;
  TextBox m_txtBox_UserId = null;
  TextBox m_txtBox_UserPwd = null;
  TextBlock m_txtBlk_UserId = null;
  TextBlock m_txtBlk_UserPwd = null;
  string m_userId = null;
  string m_userPwd = null;

  public TextBox TxtBox_UserId
  {
   get { return m_txtBox_UserId; }
   set { m_txtBox_UserId = value; }
  }
  public TextBox TxtBox_UserPwd
  {
   get { return m_txtBox_UserPwd; }
   set { m_txtBox_UserPwd = value; }
  }
  public TextBlock TxtBlock_UserId
  {
   get { return m_txtBlk_UserId; }
   set { m_txtBlk_UserId = value; }
  }
  public TextBlock TxtBlock_UserPwd
  {
   get { return m_txtBlk_UserPwd; }
   set { m_txtBlk_UserPwd = value; }
  }
  public string UserId
  {
   get { return m_userId; }
   set 
   {
    m_userId = value;
    TxtBlock_UserId.Text = value;
   }
  }
  public string UserPwd
  {
   get { return m_userPwd; }
   set
   {
    m_userPwd = value;
    TxtBlock_UserPwd.Text = value;
   }
  }

  public MainPage()
  {
   InitializeComponent();
   
   m_txtBox_UserId = txtBox_UserId;
   m_txtBox_UserPwd = txtBox_UserPwd;

   m_txtBlk_UserId = lbl_UserId;
   m_txtBlk_UserPwd = lbl_UserPwd;
  }

  private void btn_Login_Click(object sender, RoutedEventArgs e)
  {
   UserId = m_txtBox_UserId.Text;
   UserPwd = m_txtBox_UserPwd.Text;
   messageTxt.Text = "Hit";
  }

  private void txtBox_UserControl_GotFocus(object sender, RoutedEventArgs e)
  {
   if (sender is TextBox)
   {
    TextBox txtBox = (TextBox)sender;
    txtBox.Text = "";
   }
  }
 }
}

MainPage.xaml

MainPage.xmlを投稿しようとしたが、上手くいかない。XMLの構文を解釈されてしまうので、掲載しにくいです。
今日気がついたことは、位置情報をきっちり決めようとすると、Gridの要素としてCanvasを登録して、さらにその要素としてTextBlockなどを設定。そのプロパティとしてCanvas.Left,Canvas.Topを設定すると明確に位置合わせができます。

Google Japan Blog: Tech Talk in 関西: Google 日本語入力を支える情報処理技術（学生向け）のお知らせ (1 月 30 日)

2010-01-24T13:36:00.000+09:00

Google Japan Blog: Tech Talk in 関西: Google 日本語入力を支える情報処理技術（学生向け）のお知らせ (1 月 30 日)

どうもJudaです。
関西の学生はぜひ参加して方がいいですね。というか、私も行きたかった。

SilverLightの特徴まとめ

2010-01-24T00:37:00.002+09:00

どうもJudaです。

SilverLightのどういう点が特徴的であるのか、ちょっとまとめる。

XAML（XMLの拡張）でUIを記述する。
C#、VBもしくはJavaScript、Iron Python、Iron Rubyでロジックを記述する。
デザインとロジックを分離できる。
動画再生にAdv.がある。
疑似３DやエフェクトをSilverLight3からサポート。
WPFのサブセットという位置づけであるので、Desktop Applicationとしても使える。
DeepZoomやPhotoSynthいう機能が他のRIAとは異なる。

DeepZoomはこちらで確認できる。

Photosynthはこちらで確認できる。

マルチメディア系のアプリケーションをつくるのにはいろいろ楽しい感じになっている。

SilverLightことはじめ

2010-01-23T22:09:00.003+09:00

どうもJudaです。

とりあえずSilverLightのことはじめ。

VisualStudio2008で始めるには、とりあえずSP１が当たっていること、.net Framework3.5がはいっていること。これらはWindowsのDownloadページで手にいれることができるのでこれを用意します。Visual Studio 2008 Service Pack 1 および .NET Framework 3.5 Service Pack 1

つぎにVisualStudio上でSilverLightを快適に開発するために、SilverLight Toolをいれる。Visual Studio 2008 SP1 用 MicrosoftR Silverlight（TM） 3 Tools

ほかにも便利なToolなどが存在するが、それらはCodePlexで探せばよい。

たぶん開始してProject作成をしてすぐに文字列を表示したいと思う。その際に注意がある。XAMLファイルの編集は癖があるので、注意。文字列はTextBlockを使う。ここにしか文字を書き込めない。Buttonにすらだ。つまりLabel的なものの動作はこれが請け負っている。これだけわかればあまりイライラせずに開始できるとおもう。この落とし穴に関しては解説サイトでもなんかスルーされている気がする。

開始して30分で気がつく落とし穴はそれぐらい。

インターフェイスの使い方

2010-01-23T16:10:00.003+09:00

どうもJudaです。
インターフェイスの使い方は疎結合のための考え方だろうとおもう。個人的にはpImplイディオムと似た匂いを感じます。ちなみにpImplイディオムの関連して記事
Pimpl イディオムのお手軽な実装
PImpl イディオム
pimplイディオムを語る
このイディオムの重要性は、その結合が粗であること。それによって得られる副次的な作用は、コンパイル時間の短縮、変更の容易さが得られますが、代償としてこのイディオムを知らない人に対してはなぜこのような実装をしているのかが、わかりにくくなります。
これは、開発者のレベルに差がある時には非常に問題になりますが、それはOOPも一緒だし、他の様々な実装方式も同一の問題を抱えます。
インターフェイスベースと言うとCOMですねー。COMあれもめんどくさい。
インターフェイスを重要視して開発すると実装の詳細はあまり関係はなくなりますが、十分に動作や手続を説明していないと使い物になりません。また実装が隠蔽されていることによって、慣れると手続きを構築するのは簡単になるのですが、それを学習するコストが大抵はソースコードをみることができないことによって増加しますし、関連ドキュメントがないことによってさらに増大っと利用に関しては結構な関門があるのと思います。
ここまで考えが至るプログラムを組むことに対して、思慮深くなる。うむむ。

ちなみに参考
プログラミングメモ - インターフェイスの使い方

WPFって？

2010-01-23T14:52:00.003+09:00

どうもJudaです。

今さらですが、
Windows® Presentation Foundation - Microsoft
Windows Presentation Foundation - Wiki
まぁSliverLightの基礎的なフレームワークなんですけど、
これは既存のWindowsのFrameworkから脱却する目的で開発されているので、MFCとは違いますし、.net Frameworkとも違います。まぁ.netとはとても近いですけどね。
重要なのはこれがまぁ新しいフレームワークで、なおかつDesktopとWebをそれほど区別しない点、UIとLogicの分離をフレームワーク的に強制するところです。

これによってMVCのような粗な結合を作ることが推奨されますし、これによってOOP、テストの導入などがしやすくなると考えられます。しかしこれは、ある程度以上の興味と技術をもっていないと上手くいかないので、学習コストをそれなりに払う必要があると思います。
もっとも悲しい事例をあげるなら、すべてが無理やり結合されている。もしくはそれに近い状態におかれることでしょう。例えるなら果物ナイフで巨木を切り倒すようなことにならないように、適宜道具の吟味とその使用法を確認する必要があります。
WPFはC#とVBから利用できる点も特筆しておきたいです。

NVIDIAのCUDAを利用したSolution

2010-01-23T14:37:00.005+09:00

どうもJudaです。
とりあえずこれを見てほしい。

NVIDIA「OptiX」エンジン発表、GPUでレイトレーシングを高速処理
NVIDIA® OptiX™ ray tracing engine
引用、ただし体裁は変更。
System Requirements

Operating System: 32 or 64-bit versions of Windows XP, Windows Vista, Windows 7, Linux
CPU: x86 compatible
System Memory: matches graphics board recommendations
GPU*: NVIDIA Quadro FX or NVIDIA Tesla (GT200 class required for multi-GPU scaling and technical support)
Frame buffer memory: varies with data complexity
Driver: NVIDIA Unified Driver r190 or later, CUDA toolkit 2.3 or later
C/C++ Compiler: Visual Studio 2005 or 2008, along with CMAKE
NVIDIA GeForce to be supported with NVIDIA's upcoming "Fermi" GPU architecture- see OptiX 2 Beta.

今回のSDKのBeta版から計算用のGPUでなくても、実行可能になりました。
以前は40万からしかOptiXを実行することができなかったのですが、今回は2万円のGPUでも実行可能らしいので、とても楽しみです。
これはCUDAベースのライブラリ群です。開発用にSDKを取得するのは、ちょこっと登録すればダウンロードできるので、オッケーです。
でもGPUをまだ買ってきていないので、実験すらままなりません。どうしましょう、どうしましょう。

TracかRedmineかそれが問題だ

2010-01-16T16:55:00.002+09:00

どうもJudaです。
プロジェクト管理ツールとして、Tracを採用するか、それともRedmineを導入するのか、思案中。
CVSがMercurialとSubverisonを併用しているので、両方扱える方がいい。
また導入しやすくて、当面はローカルなサーバーとして運用できる方がいい。
この二つの条件から考えると上記の二つに絞れるのだけど、まだ別の選択肢もあるのかなぁ。と思う。
ちなみに会社のPCに試験的にTracは導入してみた。Trac Lightingではないので、導入に戸惑ったがSubversionの導入はそれなりに簡単にできた。でもHgとの連携のためのPluginの設定方法が分からなかった。とりあえず管理画面からできるという情報を入手したが、まだよくわからない。
Redmineはとりあえず調べなければ、うむうむ。

xUnit Test Patterns買った

2010-01-12T01:11:00.002+09:00

どうもJudaです。xUnit Test Patterns: Refactoring Test Code, Mobipocket (Kindle Edition)
最近の金遣いが最低な人間レベルになっていることは気づいているけど、Kindleは便利だ。すぐに洋書が手にはいるのが素晴らしい。中古販売の権利はないから、もうちょい安くして欲しいと思うけど、さっさと読んで、できれば日本語訳をこっそり作りたい。
テスト系統の学習を早く業務に役立てて、会社に普及させたい。
周りを変えたいと願うなら、まず自分から。とりあえず情報系の大学卒者でいけ好かないやつを　m9　したい。学習コストを支払い続けないとどうなるのかを教えてやる（メラ

ソフトウェアテストについても並行して学習開始

2010-01-10T13:41:00.003+09:00

どうもJudaです。
『体系的ソフトウェアテスト入門』
『ソフトウェアテスト293の鉄則』
を買ってきた。
これでソフトウェアテストについて勉強を並行して開始。開発サイクルと言う考え方を適応するならば、開発フェーズとテストフェーズは隣接しているので、一緒に勉強するのはとっても重要！って言ってみる。

Effective C++を読んでいる。

2009-12-31T01:23:00.002+09:00

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

理由はわかっているけれど、やってしまう間違い

2009-12-23T19:29:00.004+09:00

どうも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の実装はちゃんとコンストラクタを特別に作っておかないとダメです。
ややこしいですねー。

C#でMathematicaなIntervalの実装

2009-12-22T00:46:00.002+09:00

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

画像処理ライブラリ

2009-12-20T20:29:00.002+09:00

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

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

読書と筋トレ

2009-12-19T17:26:00.002+09:00

どうもJudaです。

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

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

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

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

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

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

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

ControlController

2009-12-10T00:27:00.003+09:00

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

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

コンテンツ、コンテナの話

2009-12-06T02:27:00.002+09:00

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

携帯電話類のアプリケーション開発

2009-11-14T12:16:00.004+09:00

どうも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などは実行をスムーズに行えるのですが、よくみるとステータスバーのシーケンスパーセンテージの上がりが遅いことが分かると思います。ここが特に不便ですが、分かっていれば、動かないと不安にならなくてすみます。

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

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

黄金の３日間とは

2009-10-24T14:19:00.003+09:00

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

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

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

Happy Hacking Keyboard Lite 2 英字配列購入

2009-10-23T01:14:00.004+09:00

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

コンテキスト

2009-10-19T02:01:00.003+09:00

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

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

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

不幸自慢はあまりよくない。

2009-10-14T23:40:00.003+09:00

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

ドキュメントコメントについて

2009-10-04T02:14:00.001+09:00

どうもJudaです。

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

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

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

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

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

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

Growl (for mac)

2009-09-27T08:46:00.000+09:00

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

Pluginとマクロのための開発設計

2009-09-27T02:02:00.004+09:00

どうも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のツールキットインターフェイスを引数に入れられるようにすると、、、、複雑度が上がるか。。。

DevKANに行ってきました

2009-09-27T01:49:00.003+09:00

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

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

The Last Guy

2009-09-23T06:22:00.003+09:00

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

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

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

VB.NET におけるメモリリーク問題

2009-09-13T02:23:00.003+09:00

どうも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++的な考え方からするとこれは基本型ではないので、ちゃんと解放されるのか心配だ。

Mercurialの有用性について

2009-09-06T00:09:00.005+09:00

どうも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を導入しても問題ありません。
そして、これはあくまで手段です、より効率よくソースコードを管理できるのであるならば、別の方法を採用するべきでしょう。というか、ちゃんとそこを理解しないと頭悪い感じになるなぁ。

JPEGって手のかかる子

2009-08-26T00:22:00.003+09:00

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

FinePix REAL 3D W1

2009-08-16T23:54:00.002+09:00

どうも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から始まる、奥義の道

2009-08-02T01:25:00.003+09:00

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

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

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

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

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

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

道具にもこだわりたい

2009-07-28T23:40:00.002+09:00

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

テストファーストでの開発の注意点

2009-07-26T00:30:00.002+09:00

どうもJudaです。

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

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

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

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

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

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

新しいゲーム布教の提案

2009-07-18T13:58:00.002+09:00

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

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

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

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

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

人工知能

2009-07-15T23:04:00.002+09:00

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

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

破をみた

2009-07-12T23:35:00.002+09:00

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

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

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

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

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

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

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

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

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

理想的なキーボード配列

2009-07-12T07:28:00.003+09:00

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

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

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

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

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

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

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

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

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

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

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

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

日々吾は

はじめまして

幸せな未来は「ゲーム」が創る 備忘録その１

ウォークスルーまとめ

コードレビュー解体

The Bug Genie

AndroidでのAdapterView-Adapter

Android覚書

読書について

Mac OS X+XCode4+Boost

CppCheckの雑感

やるきで学ぶTDD

[ブログ紹介] やる夫で学ぶ TDD

C++における様々なツールについて

Rubyの良い教材

Doxygenによる開発のカンフル

SilverlightのDataBinding

Silverlight Sketchflowの変換

実稼動プロジェクトに変換

http://msdn.microsoft.com/ja-jp/library/ee371158(Expression.30).aspx

Google C++ Test Framework

継承関係ということについての試論

MacでBoostを使う

std::vectorは連続領域なのか？

Code Kata的な 練習

WinSxSについて

ベクトル解析

Visual Studio 2008 コメント付けについて

Silverlight 覚書

DBの覚書

Silverlight Error Code 2104

拡張保護を使用した統合 Windows 認証ってなんだ？

Windows7でのマルチタッチ開発での問題

Webサービスを利用する際の大容量データの受信について

SilverlightにおけるCustom Template Controlの作り方について

Webサービスのリファレンスの追加に関して。

DataGridとの憂鬱

Codeの表示のテスト

Silverlightにおける各種画像のエンコード、デコード

ADO.NETのあれこれ

LINQ

ADO.NET Data Service のデータの追加、削除、更新

ADO.NET Data Serviceについて

SilverlightとDBの連携

SilverlightでのDataDrivenでの注意

SilverlightでのXMLシリアライズ

Silverlightとインターフェイスの話

DataServiceKeyAttribute("ID")

Silverlight Content Controlについて

SilverlightにおけるCustom Content Control

HgInitの試訳

ADO.NET Data Serviceにおける注意点

ADO.NET Data ServicesあらためてWCF Data Services

Silverlightのためのいくつかの話

Silverlightのイベントについて

Vimでのコメントアウトについて

電子書籍の新しい形をサービスへ

電子書籍というよりも書籍型アプリについて

Silverlightとの戦い

Silverlightのパス指定

VSでIntelliSenceのセンスがインテリでもセンスでもなくなったとき

Silverlightの開発環境

Silverlightのためのいくつかの話

SilverLightについての少々の覚書

SilverLight 簡単サンプル

Google Japan Blog: Tech Talk in 関西: Google 日本語入力を支える情報処理技術 （学生向け）のお知らせ (1 月 30 日)

SilverLightの特徴まとめ

SilverLightことはじめ

インターフェイスの使い方

WPFって？

NVIDIAのCUDAを利用したSolution

TracかRedmineかそれが問題だ

xUnit Test Patterns買った

ソフトウェアテストについても並行して学習開始

Effective C++を読んでいる。

最近気づくこと

理由はわかっているけれど、やってしまう間違い

C#でMathematicaなIntervalの実装

画像処理ライブラリ

読書と筋トレ

幸せな未来は「ゲーム」が創る　備忘録その１

Code Kata的な練習

Silverlight　Error Code 2104

Google Japan Blog: Tech Talk in 関西: Google 日本語入力を支える情報処理技術（学生向け）のお知らせ (1 月 30 日)

VB.NET におけるメモリリーク問題