私が置き忘れてきたもの
それは……何だろう？
こなせていません。龍騎の映画も見に行こうとしていたのに、結局行けませんでした。(ネタバレが嫌で他の日記を見ていなかったんですが、書いていなかったようなので……意味なかったですね……)(評判はあまりよくなかったようですね。)
弟くんのラグナロク廃人生活はまだ続いています……。
「マリみて」の勢力拡大が著しいのは、弟くんに一年以上放置プレイされている私に対する嫌がらせですか？
おねがい、読ませて〜〜〜な状態……継続中……。
普通。……もっとも、普通という評価を下すような私の方が間違っているのかもしれない。……というか、キャラコレを普通に読んでいた人の感性を信じてはいけません。
萌えは……たのかな？ なかったのかな？ むしろ微笑ましくて、「ふふふっ」と笑って暖かく見守る、そんな感じ。
そんなこと言うと、「あの強い感情移入はどうなったんだ？」って聞かれそうですね。確かに羨ましいですよ、可憐ちゃんが。でも可憐ちゃんに対してはのめりこむというよりも、その想いに触れ、共感しつつも少し距離をおいて見守るって、そんな感じなんです。私の中の可憐ちゃんとはそれで折り合いをつけることができます。(これが亞里亞ちゃんや千影ちゃんだったら、そうはいかないんでしょうけど……)
私は可憐ちゃんのことを電波だというのが分からないんだけど、それは基準が大いに狂っているからかもしれない。……と書き始めると長くなりそうなのでやめ。ただ、恋をしたことがないというのは嘘で、ああいうところまでいかないとしたことにならないと思い込んでたからだろうな、って思わされるんですよね。そういう風に言っている人の言葉を聞くと。
スタッフに知り合いの名前が出てきてびびる。調べた結果、別人で名前は偶然一致していただけでしたが……。……だって、思い当たるふしが色々あったんだもん。
ついに、ML Interpreter for Template Metaprogrammingというものまででてきました。(Boostのファイル置き場に実物があります。なくなりました。残念。)
今のtemplateを駆使したコードはテクニックだから難しいわけで、もっとルール化を進めてプログラミング言語化してしまえば大幅に使いやすくなる……そういった意味で注目すべき進展。(……でも、理解してない人には無視されそうだし、理解している人には「MPLの方が先じゃないの？」って言われそうな、微妙な分野。)
MPLと同じく(ver.1.30)、これもそのうちBoost.Pythonで利用できるようになりそうな予感。……がしたのに……。
弟くん、今期のアニメはビデオにとらないらしい……どうやらラグナロク三昧で時間がない模様。……。
ドイツ語。語彙力が足りな過ぎ……夏休みはじめからずっと勉強ばっかりやってきたのに、未だに宿題終らない……。あぅ〜。
結局間に合いませんでした……。
WideStudio、Macへの対応を開始したみたいです。
まだ、Xサーバー上でしか起動しませんし、できたらα版を公開するといっていたWindowsでのRubyやPythonへのAPI対応の途中で手をだしてしまったようなので、バイナリもソースも公開されていませんが。
他にもいろいろと水面下で動いています。
河童でもいろいろと動いています。(こちらはいつものことか……)
[Cuppa-devel]の内容をみせることができないのが残念ですが、プログラミングをされる方であれば期待していいと思います。
確かに普通に2つあるとなると開けてくる様々な可能性に燃えるっていうのも手ですよね。片方でリトルエンディアン、もう一方でビッグエンディアンを扱うとか、過去への互換性を切り捨てるために、片方で旧環境をエミュレートするとか、擬似P2P環境でテストしてみるとか。
何かSWIGで遊べるアイデアないかな？
今シリーズ、お兄ちゃんに萌えられません。うそっぽくて、かっこよさもなんだか伝わってこなくて……
前半。終りよければ全てよし。萌え。……ただ、全体的にパンチ力が足りない。思わず正視するのに耐えられなくなるくらいはずかしい、甘々な話を期待していたのですが……。
バスの前でこけてしまったあたりで、突然「花穂 お口で」を思い出してしまって、きっとそういうときでもやっぱりしっぱいしてこぼしちゃって、涙を溜めた目で「ごめんなさい……お兄ちゃま……花穂、ドジだからいつも失敗ばっかりで……」って、そういうふうになるんだろうな、と思い浮かべてしまったり。
後半。しのぶさんも言ってますが、「花穂でなく衛を持ってきたのには何か意図があるんだろうか？」、「衛だったら身体検査じゃないの？」などと思いつつも、何か魅せてくれるはず……と淡い期待を抱きながら見る。
……分かってない。衛はもっとこう、コンプレックスを押し出していかないとダメなのに……。
既出うんぬんはさておき、その手のシステムはありふれてますし、またこの手の行動もやっぱり一番最初がすごく思えるわけですから、そうでない以上「以前のものを越えたかどうか」、「それらと比べて明らかに優れているかどうか」、そういうものが問われることになるので、そんなに単純に「衝撃的だ」と反応することはまずないと思います。(これが「君の望む永遠」発売直前あたりであれば違ったでしょうけど……)
ごうさんが強い印象を受けるのはプログラマー肌で、しかもそういったツールをライバル視しているからであって、そうでない人にとってはどんなに凄いことができようとGPLなどでソース公開されていようと関係なくて、むしろ自分がしたい表現をかなえる方が重要で、それさえできれば十分なんです。(まあ、時には、「あれができないと表現できない」という考えに取り憑かれたり、
よってもう少し冷静な見方になってしまうので、どんなに良いもの見えようが、実物が出てこない今の段階では様子見といった感じになってしまうのは否めないと思います。
企画屋、マネージャー、アーティストなどという風に分業化を進めるとなると、もっとメーカーの果たすべき役割をもっと真剣に考えた方が良いような気がしますが……
ちなみにメーカーはお金を出し、場を用意し、窓口となり、回収していくだけのパトロンに徹するとか、Webだけで作業を完結させる(誰もそこまで言ってない……)といったアイデアには反対です。理由は、情報技術は時間的制約を取り去りますが、リアルタイムでの反応とか、共同作業をおこう環境といったものも同時に失わせてしまうからです。(このあたりの話はなぜITは社会を変えないのかに詳しく述べられています。(あいかわらず凄い邦題……。))
また、メーカーがブランドのみに依拠することになるとブランドが崩れたとき脆いので、何らかの他の競争手段をもっておく必要があります。(オープンソースやGame Programming Gemsなどの書籍に現れる知識共有、Generic Programmingによるルーチンの共通化といった昨今の流れが示唆するように、システムで持たせようとするのはナンセンスですが……。)分業化が進んでも、いやそれだからこそなおさら優秀な人材を確保あるいは育成する必要があるでしょう。でもそういった人材を使って別の製作チームを作るだけであれば、当たり外れといった不確定なものに身を任せている現状を肯定しているわけで、企業行動として健全なものとは言えません。ようするに他分野の企業が今直面していると同じ問題、いかにしてヒット商品が生まれる環境を作るか、って問題を注視しなければなりません。ここでできることは、徹底したユーザー調査・把握と、開発者グループだけで完結してしまうと自ずと限界がでてきてしまうので、そこを補うための他のグループとの交流、その企業の持つ雰囲気(企業文化？)などの環境の提供をおこなう、といったことであり、そういったものを保持するための手段として自社スタッフを使うというのも手ではないでしょうか？ (決してかませ犬にするってことではないですよ……念のため。)
あとは……企業は今のようにコミケとか＊＊ショーとかで物を売ったり、イベントを催したりするだけでなく、もっと他の企業や個人に対してコミュニケーションをはかったり、ネットワークを張ったりする場として活用してもいいと思います。(別のイベントが必要かなぁ……)
音楽著作権関連の話は完全に出遅れたようなのでやめておきます。だいたい、私が読んだのってアメリカのやつですし……。
新版がでてるので、いつもの通り、環境変数STLPORT_PATHにSTLportのディレクトリを設定してコンパイル。VC6でのsignalとdatetimeの利用にしくじる。どうして？ (jamからならOKなんですけど……)
日記の中でいくつにも分かれているものを参照するのは面倒なので、boostを扱うページを作りました。基本的に解説はboost infoやLet's boostに任せるとつもりなので、メモ書き程度の扱いです。そのうち気が向いたら色々と書き足すかもしれません。
STLportを使用するけどSTLportのiostreamは使わない場合(STLport/stlport/stl_user_config.hの_STLP_NO_OWN_IOSTREAMSが定義されている場合？)、VC6ではboost_regex_vc6-stlport_mdidd.lib(424)とboost_regex_vc6-stlport_mdsdd.lib(536)のcregex.cppで「ヒープが不足しています」と言われてコンパイルが中止してしまうので、makeファイル内の記述に/Zm200などという風にオプションを足してやる必要があります。
(うちだけでしょうか？ もしかしたら、それ以外の場合でもなるかもしれませんが調べてません。)
また、STLport使用時にはマルチスレッドのみサポートしているようです。(STLportのiostreamはマルチスレッドを対象にしているので、当然といえば当然ですが……。)
一話で魅せれないのは致命的。どうせなら一挙ニ話の方が良かったんじゃ……
Ζ以降を強く意識していたXに対して、これはファーストを語りなおすことを目的にしてるっぽいけど……「ひょっとしてVも意識してる？」ような感じもします。
あらすじを見る限り、友を敵に回さなければならないということを主軸にしているはずなのに、友との交流の描写がおざなりになっているのがどうも……今後に期待して、いいのかな？
「兄くんがかっこいいこと……それは確かな事実。…………だけど、少し……ほんの少しでいい……困った顔をして欲しい。……そうでないと、心をどこかに置き忘れたかのように見えるんだ…………。」
Aパート。
最初はいろいろ雑念が入っていたけど、花穂のお馬鹿なところを見ているうちに思わずのめりこんでしまって、体重計の上でお兄ちゃまに抱きかかえられた瞬間、「きゃぁぁぁぁぁ」と花穂の気持ちになって心の中で叫んでしまいました。
つぼは間違っているんですが、これはこれで楽しめたので良かったかな……。せっかく健康診断という武器を持ってきたんだし、できれば衛との二重奏が見てみたかった、それが心残り。(二人がそれぞれ違った理由でお馬鹿なことをしていて、花穂が衛に向かって「がんばろうね」って言うんだけど、そうやって女の子らしい悩みを持っていることに対して衛はコンプレックスを感じてしまって…………という１コマとか。)
羨ましい。私が亞里亞を見つめる目はいつもそうだ。
亞里亞は私が捨てさせられたもの、捨てざるをえなかったものを持っている。そういうものが受容される環境、その中で育っていった亞里亞に対して私は羨望を抱く。そうしたメッキは時々剥がれるのだが、いつも普通の人として振る舞うだけに、思考速度が非常にゆっくりしていて言葉も考えも中々浮かんで来ないなんて、他の人と同じ言葉で語ることが難しいなんてなかなか理解してもらえない。そうした悩みに囚われていない亞里亞はまさに羨望の対象だ。……それでいて、兄やまでいるなんて！！！！！！！
「……兄や、亞里亞をここから救い出してくれる…………？」
[cuppa-devel]にて、Tcl/tk Unitの話をきっかけにして、渋川さんと検証機能付フレームワークの話など。
「GUIに関してはpolicyとかtraitsベースのtemplate設計でDbCを備えていれば(ユーザビリティテストを除いて)テストするまでもなくプログラミング段階でエラーが検出できると妄想しているんですが……」といったのがきっかけ。さすがに、機能が正しいかどうかだけではなく、ユーザビリティ方面の知識も埋め込みたいというこっちの認識とはずれがありました。
で、そこからユーザビリティの話に移る。
これで秘密情報が長期的にもうけれるようなものであると、それはそれで逆に独占禁止法にひっかかったりします……というか、これは不公正な競争に結びつく危険な見方です。(情報そのものには価値がないことへの自覚はまだまだなのかな？)
また、合理化を避けると、海外の方ではいろいろと共有が広がっているため、日本のゲーム業界ピンチ、ってことにもなりかねなかったり……。
GPLなスクリプトエンジンで実行されるスクリプト自体はGPLの影響を受けないんだったっけ
人によって言っていることが違いますね。
RMSは適用される派ですが、Linusは動的リンクまで認めると言ってます。(ただし、OSを対象に述べているので拡大解釈すると危険。)
というわけで作者の態度次第になりますが、とりあえず、スクリプトに一般的な言語を使ったり、GPL以外のライセンスで他に同じスクリプトを使用できる(互換性のある)ソフトが存在する場合には大丈夫だと思います。
#まあ、所詮は「(プログラムがタダになったところで)どうせ8,800な製品定価は変らんのでしょ」と思ってる……(以下略)
その辺はマーケティングとサプライの力構造が関わってくるはずなんですが、日本の場合流通の合理化が図られていませんので……
複合文書がうまくいかないのは需要がないからではなくて、Microsoftの実装し方が良くないためです。例えば身の回りのものであれば、やることに応じてその都度道具を変えていきますよね、複合文書でそれがうまくできないのは今のMacのようにアプリの機能の一部だけを呼び出したり、同じ種類のものであっても用途に応じて別のアプリを呼び出したりすることがサポートされていない(あったとしても容易にはできない)ためだと思います。もちろん、パフォーマンス上の問題もありますが……。
Intelli SenseもVisual StudioのエディタではなくIMEでサポートして欲しいし、スペリングチェックもOSで実装した方がずっといいのですが、そんな風にはならない……。
それらをきちんとやればOpen OfficeもCannaもMicrosoftなんて目でなくなると思うんですが……無理かな？ (アクティベーションは他者に有利な状況を招いているから大丈夫かも。)とりあえず、Cannaにはここの予測と曖昧検索にもとづく入力手法と関連する研究(PDF)の成果は生かしてもらいたいところ。
……というか、なぜパクろうとしないんでしょうか……Internet Explorer 7でようやくタブブラウザ化されるように危機感を感じてからってことでしょうか？ ……それでは使いやすさは向上しませんよ。
<!--注(ここにあまり来たことがない方へ)：本へのリンクはURN(ISBN)で貼っています。サポート用の拡張を入れていない方は検索してください。-->
一連の話題では、秘密を守ることに焦点がいきがちで、「守らないとすればどうすればいいのかという」ことに触れていなくて残念。せっかく職人という比喩を使っているのに、熟練や名声などという視点を欠いているように思えます。
製品生産の分野でもフォーディズム的な単能工ではなく、一通りのことがこなせる熟練の多能工が求められ、技術力のない人が淘汰されようとしている昨今、どうやって経営者にとって雇うに値する人物になるかが問題ではないかと思います。で、「どうやって熟練すべきか、経営者は熟練者にどう接するべきか」というような話題が、ソフトウェア職人気質という本で語られています。(ソフトウェアの分野ではまだ人がたくさん必要な状態が続くことが分かっているので、ではどうすればいいのか、という話題もありますが、そのへんの本はまだ読んでいないのでパスです。)
安い代替品が高品質の品に取って代わるプロセスについては、イノベーションのジレンマ 増補改訂版が詳しいかと。マーケティングについては……ごめんなさい、単位取った程度の知識しかありません……。
あと、「情報そのものには価値がない」という言葉をそっちの意味でしかとる人がいなくて残念。実は情報を公開しても、ノウハウなどは渡らないっていう話があります。実行できるとは限らないからhowは渡らなくても不思議ではないとして、どうしてknowが渡らないかというと、情報というものは目に見えるもの(形式知)を追いがちで暗黙知にはなかなか目が届きにくい。そうしたものを形式知に置き換えようって試みもおこなわれはするんですが、暗黙知なだけに見当外れのものをプロセス化してしまって失敗することも多い。で、結局のところ何が知なのかというと、そこにある環境とそこで働いている人そのもの。だから、下手に解雇する会社はみすみす知を失っている、という話などが前にも紹介したなぜITは社会を変えないのか(The Social Life of Information)に書かれています。(ただし邦題や翻訳の評判がとても悪いですが……)
(経営の本質はいくらむだをするために、他の部分でのむだを排除するかってことです。いくらコストが抑えられるからといって、人的資源を軽視する経営者なんて……)
いかにシステムを強力かつスクリプトをシンプルに保つかが今後の焦点になることはまず間違いありませんが(C++での昨今の流行やXMLでのシンプルを売り物にしている規格を見てもらえば分かる通り、その両立は十分に可能)、スクリプトのオブジェクト指向化は反対です。下手にオブジェクト指向を持ち込むとスクリプトが複雑になってしまいます……。それよりもRELAX NGのように関数的な参照系のアプローチをとった方がぐっとシンプルになっていいと思います。
まあ、関数言語がそうであるように、結果として楽にオブジェクト指向的に運用できそうですが……。
で、スクリプトが複雑になってはいけない、プログラミング言語化してはいけないということに関しては実はGame Programming Gemsに詳しく述べられています。……というわけで当該部分を引用。
データ主導の振る舞いにスクリプトを使うことはデータ主導方法論の自然な成り行きである。しかし、良い常識を持って実践する必要がある。そのカギはロジックとデータの分離という根本原則を忘れないことである。複雑なロジックはコードに渡し、データを外に置くこと。
ゲームをデータ主導にしようという願いから遠ざかったとき、問題が起きる。ある時点で、複雑なロジックをスクリプト内におくという誘惑にとらわれるだろう。スクリプトが状態情報の保持から始まり、分岐が必要になり、有限状態マシンになっていく。状態の数が増えていくと、罪のないスクリプトライタ(あるいはゲームデザイナ)はプログラミングが仕事となってしまう。スクリプトが非常に複雑になったとき、その仕事は限定された仮想言語でプログラミングするプログラマに戻すべきである。スクリプトは人々の仕事をより簡単にするためにサポートされるべきものであって、複雑にするためのものではない。
(中略)
おそらく読者が想像しているとおり、スクリプト内の少なからぬロジックは非常に入り組んだものになりがちである。スクリプトパーサやコンパイラやデバッガを書くのに数ヵ月は消費するだろう。ところが、プログラマはその目の前にすばらしい完璧なコンパイラを既に持っているのである。
しのぶさんの語りがあれば十分なのではないかと思いつつ、リピュアの感想。
Aパート。
ようやく「ただの完璧な兄」ではなくて、「完璧ではないけれど、それでも妹の視点から見て理想の兄」というのを見れたような気がして、ほっとしました。私的にはAパートで人間らしいところも含めてきちんとした兄を描いて、Bパートで妹の想いで純化するという構成の方がいいと思ってるので……。
「お兄ちゃまの家に」花穂とふたりきりで映っている写真が飾ってあるってことは、花穂が来る前にわざわざ置き換えたってわけで、置き換える前にみんなの写真を飾っておくべきかふたりきりの写真を飾っておくべきか思い悩む兄バカなお兄ちゃまの姿を想像してみて、ふふっと思わず笑みがこぼれたり。
Bパート
これまで重大な勘違いをしていたことに気がつく。ようするに、ここ(Bパート)で語ろうとしているのはあくまで妹の世界であって、萌えを刺激されるような話でも妹の兄に対するひたむきな思い入れを描き出すようなそういうおいしい話でもないのだ。そう考えると、これまでの話のセレクトも納得がいく。
だから、ここで描かれる物語はとても綺麗にうつる。この作品を見ることができて、私は幸せです。真摯な作品作りを心がけてくださったスタッフに感謝。
共有コンポーネントの実装し方で、今私のなかで有力なのはdRubyで分散しSWIGで各言語を糊付けするという方法。あとはRubyがバイトコードをはくようになれば完璧。
EmacsにはSchemeバインド版もあるようですし、APIの抽象化の足りない部分をC/C++で抽象化しておけば事実どこでも動くはず……
ただ、日本語処理とか考えるとguileよりもGaucheの方がいいなど、Schemeには実装によっていろいろと違いがあるのが悩みもの。(例え主要なもの全てにSWIGが対応したとしても、全部インストールするなんてやってられませんよね。)
曲解しているかもしれませんが、Windows上にあるから使いにくくて当然というのに対しては、そうではないと信じたいですね。本来、OSの使いやすさと周辺機能の使いやすさと、そしてアプリの使いやすさは別物としてとらえ、その中でそれぞれを評価するべきだと思います。……現状ではそうでないので一緒にしたがる気持ちは分かりますが。
……もし、そのなかのどれか一つでも使いにくかったり思想的に古かったりする場合には、別の部分でそのあたりを改善してもいい……むしろそうするべきです。(極端な話、Windowsプロンプトの貧弱さからcygwinの皮を被せるように、TRONや他の技術の皮を被せてもいいはず……。)Mac OSXの場合統一感を重視するのはいいのですが、Cocoaなどに見られるようにあくまでOSの側からやっていくことに拘り過ぎていて、そういった視点が欠けているので、(Carbonが残っている今はまだいいのですが)その態度が続く限りさらなる使いやすさへの進歩の牽引役となることは難しいと思います。逆に言うと、Windowsはアプリ開発者に自由度を残しているので、この先下手に標準を押しつけるようなことをしなければ、Microsoftではない別の開発者の手でいくらでも使いやすさを改善する余地があります。
……。ええと、もしかして話がずれてますか？ 私が言いたかったのは、要は「OLEの技術をそのように用意しているからといって、何も馬鹿正直にそのまま使わないでもいいよね？」ってことなんですが。(仮にもMacにアプリを提供しているんだし、そこから改善したっていいはず……。)
ファイルに関しては、そもそもファイルやフォルダという概念に頼りっきりってところが旧時代的なもので、場合によってファイルやフォルダとしても扱えるというぐらいでないとダメだという意見もありますが……。メタデータを使えばうまくやれそうですね。もちろん、Mac的なファイルに埋め込む式のメタデータではなくて、ファイルを総合的に管理するメタデータを作るって話です。そしてインクリメンタル検索も可能にと。バックグラウンドで常にNamazuとMigemo的なテクノロジーを動かすっていうのもありですね。CUIの世界には未だGUIが取りこぼしているテクノロジーが多いので、早く拾ってほしいところ。(強力な履歴機能とか一部のアプリしか実装できていないインクリメンタル検索とか、まともに整ってないフィルタとか…………)
アクティベーションに関しては、それだけで考えるのはよろしくないかと。とりあえず他のOfficeソフトのファイル互換によるネットワーク効果の減少(マイナス要因)などが考えられるわけで、その上にアクティベーションがあるから他者に有利な状況を招いているだろうと判断したわけで……。……と書いてみましたが、ここも何だか違いそうですね。とりあえず、OpenOffice.orgの解説本は既に5冊もでてるってことで……。…………さらに古いWindowsでは使えないって要素まで加わったみたいですね。
賛否両論のある今回のお話。原作を知っているからこそ否定する人と、知っていて肯定する人。多分、知らない真っ新(白)な状態だからこそ素直に見れた人と、知らなくても性格から否定する人、人としてのある一面を秤にかけてもやっぱり否定する人。
一日かけてもどうやら私の結論は出そうにない。私に言えることはただ二つ。あるべきものがそこに足りない、それと、真っ新な状態で素直に見れた人が羨ましい。
どうしても私には媚を売っているように見えてしまいます。妹の世界を描くことを放棄し、多くの視聴者の望むものをただ見せる、そんな姿勢に。でも、もう一方で真っ新な意見になるほどと思わされもする。……こうやって悩まされること自体、失敗なのだろうけど。
もっと、美しさが欲しい。安易なものに逃げずに、もっと丁寧に描いて欲しい。今回のお話はそうすることができたはず。花穂のお話然り、千影のお話も然り。
The planned Everett release goes further with support for partial specialization of class templates and partial ordering of function templates. Visual C++ developers have been using a series of work- arounds to attain these features, but Microsoft believes the time is now right for adoption.
だそうです。で、一時期lokiが使えるって言われてたわけですね。
でも、そういう期待はVC7に対して持っていたので、見捨ててもいいかも。templateとnamespace関係のバグが取れればDigital Marsも使い物になりそうですし……VC7の使えるマシンは占領されてますし……
……色々と悩む……。