vieweditattachhistoryswikistopchangessearchhelp

戯

自称(つまり似非)OOPオタク。

このサイトのページの新規作成って、JavaScriptに依存してるんですね。
w3mから新規ページを興せなくて、びっくりしました(T_T)


独壇場に書かれてるようなWikiの字下げ文化(?)は、俺は好きです。推進派(笑)です。
それよりマシな(今の普通(?)のWikiにおける)表現手段が思いつかないっていう理由もありますが、
そもそも自分の思考形態…どんどんTree状に展開していくらしい…しばしばNetwork化するが…と似てるせいもあります。

字下げの件は慣れとか好みの問題が多々ありますね。私自身、前は好きだったのですが、第三者になるくらい時間がたって（歳のせいか、さほど時間はかかりませんが(笑)）、書かれたものを見ると読みにくいったらありゃしない…で、まだ時系列のストリーム＆引用のほうがいいかなぁって今のところは落ち着いています。まあ、これ（ストリーム＆引用）も慣れで、そのうちいやになるかも。--sumim

Wiki の書き込みの書式はどんなのがいい？ ←　あんましいいのが思い浮かばない(笑)。--sumim


＞w3mから新規ページを興せなくて、びっくり
ああ、すみません。よく指摘されるんですがまだ直していません。ごめんなさい。--sumim

最近、いいなぁ、と思うのは新規ページもそのままハイパーテキストにしておいて、書き込み保存するまで新規ページはつくらないってやつ。Tiki もそうでしたっけ？　Wikipedia がそれなんですよね。問題は慣れていない人が新規キーワードをクリックしていきなり編集画面にきたら、あわてて保存ボタンをおしちゃうんじゃないかなぁ…ということ（まあ、慣れていてもいきなり編集画面が現われるのもどうかと）。なんか差分付けないといけませんね。--sumim

この機構の仕様がうまく落ち着いたらってことになりますが、次に考えているのは自動リンク化モード。保存時にチェックを入れておくと、Swiki ブック内のキーワードを探して自動的にリンクしてくれる。負荷かかりそうですが(^_^;)。Swiki にはオリジナルのキャピタルワードによる WikiName 機構がないし、日本語との相性の問題があるから（英語すら問題ありだから Swiki では採用されなかったわけで）なにか代わるものが欲しいとはつねづね思っています。--sumim

直列＆引用方式も嫌いじゃないですが、それならもっと便利な古典的掲示板でいいじゃん？というWiki側の対抗意識に基づく口惜しさ(笑)が有るんで、ちょっと迷う所です。-戯

Tikiは、新規へのLinkは最初は"?"になってて、そこをClickされて新規入力されると、リンク元は"?"じゃなく普通のリンクに変化する、というものでしたっけね。(たしか元祖Wikiと同じですよね)
あるいはRWikiあたりは"?"すら無くていきなり普通のリンクから編集画面に送られるらしい。
まあそれでも良いかという気がしています。
初心者は"ナニをするか判ったもんじゃない(笑)"わけで、押すボタンが保存ボタンとは限らない。
むしろまっさらな編集画面を見て「何か大事なものを消しちゃったか？」とビビって「あの頃(ぉ)に戻りたい」と発心して、あわてて「戻る」ボタンを押してくれることを、俺は期待しています(笑)＃無理な願望かも知れませんが。
それに空の新規ページを作られてしまっても実害が有るわけじゃない(しかも後からRename?できるSWikiなら特に、ですよね)ですから、俺の大好きな言葉を適用しやすいと思います。つまり「放置プレイ」(笑) -戯


さぁどうぞ。


Object短冊とか言ってみるテスト

CRCカードってものが有るそうですね


子供のころ動物飼いや虫取りをしたことが無い奴は、オブジェクトを扱うのも下手だ、と妄想してみるテスト。 -戯

死んだ動物の背中に乾電池突っ込むなんてのは、つまりプロトコルを間違えてるんだ。
死なさないように工夫するってのも、その生き物用のプロトコルにあわせてあげるっていう話。
生き物を(大事に)扱うのと同じように、オブジェクトも扱えばいいんだ。

…それには、逆説的だが、「間違えた」ら「死ぬ」シーンが如実(?)に「見える」ようなシステムが、
少なくとも学習用には欲しいところなのではなかろうか？

で、死なさないために、人はハッチャキこいてクラスを読むわけ。
クラスは、さしづめ、その動物の飼い方を書いてる事典(の該当ページ)、かな。

たとえばドリトルを、上っ面なタートル(つまりView)とかじゃなく、
もっとオブジェクトそのものが見える方向に持っていくといいんじゃないかな。
画面上でオブジェクトそのものが生きたり死んだりするような。

まあ、生きたり死んだりといっても、
ライフゲームみたいに自動(?)的に勝手に先へ先へと進んでくれる必要は無い
(オブジェクト指向はやっぱり外部イベントが来てやっと動くというモデルがだよね)が。
オブジェクトの受動性

Smalltalk(Squeak)だと、既にその境地にいってるのかな？
ん？早い話が、永続オブジェクト環境(Smalltalkも一種のソレだが、他にも色々有る)で
仮想たまごっち(古い)を作ればいい、のかな。

ところで、学習用だけじゃなく本番(仕事?)でも正にそういうのが欲しいけどな(藁
メモリの中でオブジェクトたちがどう悶え苦しんでいるのか？が正に見えれば、
今は「このオブジェクトを」救ってやる(べきな)んだ！と判れば、
こんなに苦労はしない筈なんだ。

＃スレッドやコンテキストは、さしづめ空調や浄化機やサーモスタットかな？

事典(クラス)を読むのは2番目にすべき作業だ。1番目はまずオブジェクトに当たれ。
そうでないと、マニュアル人間の謗りを免れないぞ(藁


めも。
http://kwatch.at.infoseek.co.jp/diary/diary.htmlの2003-08-09の
「あるデータがオブジェクトかどうか？というのは、「is-aポインタをもつかどうか」に帰着される」
は嘘だと思う。
「オブジェクトは自分自身がどのクラスに属するのか（つまり自分が何者なのか）がわかり、」
とあるが、そんなものが判ることはオブジェクトの必須事項ではないし、
「(上の文に続いて)ダイナミックバインディングが実現できる」
とあるが、そんなものが無くてもダイナミックバインディングは実現できる。

だって、プロトタイプベース・オブジェクト指向を考えてみれば一目瞭然。
proto=nilになった瞬間にオブジェクトがオブジェクトでなくなる、なんて事有る訳がないじゃん。

「何者なのか」は種類の問題。アイデンティティと種類は別な概念だし、
「種類」はその他のどのオブジェクトの定義の諸説にも出て来はするまい。
＃オブジェクト指向の第一要素としてクラスを挙げるようなDQNな議論は別ね。 -戯

is-aポインタは、それこそ上記記事から参照されてるオブジェクト指向の神髄
でいうところの「あると便利なもの」でしかない。

ダイナミックバインディングのエンジン(?)を、クラス(やプロト親など?)にしか原理的に置けない、というわけではないでしょ。
オブジェクト自体に置く事だって出来る。それを地でやってるのがプロトタイプ方式な言語なわけで。


(論理)改行なしに長く書かれた文(文字列)は、「更新履歴」の表示がイヤンなことになりますなあ。
文全体のうちどこが更新されたのか、凝視しないと判らない。 -戯

＞文全体のうちどこが更新されたのか、凝視しないと判らない。
確かに把握しづらいですね。
私自身、Squeak にコピペして比較スクリプトを書いたりするのもしばしばです(^_^;)。
仕事柄、DNA 塩基配列の改変部分をそのコンテキストから推測する機会も多いので、それとからめて、
そのうちなんかそれっぽいのを仕込んでみたいとは思ってはいるのですが、なかなか手と頭が動きません。
（↑こんなんでどうでしょう？）--sumim
（↑グーっす） --self

ところで、「行依存じゃない比較スクリプト」をしばしば書いてるってことですよね？
それってどういう仕組(アルゴリズムってゆーかぁ…)っすか？
やっぱり文字単位のエディットグラフをマヂに考えることになるんかな… --self

感想：

newを毎度毎度明示する言語は面倒か？
→んなこたぁない。 --self
→→それよりむしろ、new(に相当するもの)を書くときに、一緒に他の沢山の文字をウダウダ書かないとならない言語なら、それゆえに面倒だ。newのせいじゃないだろ。
→ただ、特定のクラスに特定の近道な書き方が用意されてるのは、美味しい。
→→もちろんその「特定」がナイスな選択ならばの話だが。
→→rubyの「[]」「{}」は秀逸。まあそれ言ったらLispの「()」も同じことだが。
→→→ただしrubyの「{}」は、時としてコードBlockと紛らわしくなるのが、イマイチ。


ふと妄想。＃書く場所を考えるのがアレなんでとりあえずここに。クタリングかんげー

お題。
最近流行の自動テストも、ユーザインタフェースの一種なんじゃないか？
MVCでいえばVCね。

最近流行の自動テストは、UIのテストは苦手だそうだ。UIじゃないものをテストするのに向いてる。
＃克服手段は有るようだが、それはさておき。

テストプログラムは、テストされるプログラムを「使う」「呼び出す」かたちで、記述される。

テストプログラムは、ユーザが(間接的かも知れないが)呼び出して使う(つまりテストを開始する)。

テスト対象プログラムは、ユーザの命令を、テストプログラムを通して受け取り、
またテストプログラムを通してユーザに返答を返す。＃その形態は「テスト結果」という独特なものだが。

それって、UIとソックリだよな？
UIがUI自体を呼ぶという事態をあんまり想定してなかった、という点も含めて、さ(笑)

でだ。もしかして、ボタンやText入力といった奴らと同様に、
「テスト」Widgetというものもまた、作れるのではないか？という気がしたんだ。

勿論、テスト対象次第で、テストWidgetもまた、千差万別のかたちにならないとなるまい。
結構大変そうだ。
ただ、千差万別なかたちのWidgetを作る手間がもし簡単だったら、
これは現実的な選択肢になるんじゃなかろうか？と。 --戯

＃言い換えればこれは、「Widget作るの、もっと楽になってくれよ」っていう話でもあるんだけど(^^;

＞それって、UIとソックリ
それが何を指すのかちょっとこの文からでは分かりませんが、
もともと UI として考えられ作られたのに、長らくそうした切り口が忘れ去られていただけってことはありませんか？
平たく言うと、Lisp や Smalltalk 的には「何を今更」的なよくある話というタイプの。--sumim

「俺が」知らないことが世の中に有ることは、幾ら有ってもおかしくとはいえ、
最近言われ始めたものであるUnitTestに対して、「もともと UI として考えられ」てたってことは、
考えにくいと思うんですが、そういうものではなく？

ちなみにこの「テスト=UI」説に基づいて考えるならば、
あの一連のUnitTestフレームワークは、伝統的な意味でのUIは
お仕着せの(開始ボタンとか進行状況メータとかの組み合わせ)が用意されてて、
そのUIとModelとの「間」を自作のTestメソッドで埋める(もしかして配線する？)
というものだ、と解釈できるかも。
もちろんこれは後付けの解釈なのですが、逆にいえばそのぶん解釈自体は新しいのかなーと。

なお、UIといっても、テストという名のUIは、Modelの全(?)機能を普通のアクセスする普通のUIとは
ずいぶん毛色が違うものだ、ということになると思います。ちょっと変わった切り口からModelを攻めるUI。 --戯



webアプリって、今というオブジェクト指向時代(笑)に対する癌だと思う。
増殖が酷いという意味でも、またその増殖が世を蝕むという意味でも、癌だ。

オブジェクト指向どころかそれ以前(それ未満)の方法論から見ても、
web(HTMLとHTTP)の世界って、プログラム(動的なもの)との相性が悪いんだもん。

少なくとも、静的ページを見る際に合理的だと思えるブラウザの「戻る」ボタンの存在は、
動的ページになった途端に強烈な破綻をきたす。
V(ブラウザの表示ね：MVC2とやらの嘘んこ(笑)の話じゃなく)とMの状態の同期を真っ向から否定するんだもん。
絶望的じゃん。

流用するのが間違ってんだよ。
もともとCGIというアイデアだけでも微妙に無理が有ったのに、更にその上に色々積み重ねていくんだもんな。

＃Wikiも結局、その限界(の低さ)に振り回された結果として、こういう仕様で存在してるわけだし。

あと、それより上(笑)のソリューションってのが、
JavaAppletやFlash(最近はOpenSourceの制御系も存在するそうなので)みたいな
随分リッチな奴しか無い、ってのも寂しい。

＃Webって、見た目がどんどん毒々しくなっていく一方で、UIひとつ組むのにも一苦労しまくるのだから、
＃往年のローカルGUIアプリの、作って地獄な世界より、更に酷いのでは？
＃＃てゆーかお前ら、なんであんなに画面を毒々しく飾り立てたいか？＞巷の「Webシステム」作者＆注文顧客
＃＃UI機能も無い(従来UIを越えるものじゃない)くせに見た目だけ飾って、アホらしく感じないか？

htmlくらい簡素で、かつ動的なアプリな画面を司る仕組みって、なんで立ち上がらないんだろ？

あ。企業の利権にとってメリットが無いから、か(藁
簡素すぎる仕組みを各企業が勝手に拡張するか、
複雑すぎて他人がHackできない(あるいはHackすればCrackだと某法律によって見なせてしまう(笑))ようなものか、
どっちかならば囲い込みで利益を独占しやすいが、
中庸なシステムだと独占できないもんなあ。

ん？Tek端末(とかいうんだっけ)やSVGの方面には、見込みは有るのかな？事情知らないけど。
ん？JavaScript？なんか違うぞと本能が告げているのだが… -戯



このページを編集 (11730 bytes)

Congratulations! 以下の 47 ページから参照されています。

This page has been visited 8153 times.