>
>http://www.tangoriki.com/
>、 via.
>ヒビルテ
>。昨日と今日にやって、テスト回数59、現在スコアは461。最高は665。
>
>問題はすべて3択なのだが、選択肢はほかの解答からランダムに取ってこられるようで、毎回選択肢が変わる方式なのは面白い。しかしそのため「いくらなんでもこれはない」という選択肢も多くて、逆に常識に照らしあわせればそれなりに解けちゃうこともある。そういうわけで「これは単語力なのか」という気もするけど、まあでも、何度も何度もやっていればそのうち覚えてくるから良いのでしょう。
>
>なかなか楽しいのでちょくちょくやるかも。
>
>スコアは、単語の難しさ(正答率？)と解答時間が関わってくるようだ。ランダムテストをやっていたら440近辺を前後していたが、専ら上級テストをやるようにしたら若干スコアが上昇した。これはたぶん、個別の単語の難しさの問題だろう。
>
>しかし、999点とかはどうやって取るんだろうな。
>
>さいきん、 GNU screen のエスケープキーを、永年愛用してきた ^t から ^l に変更した。 2ch の screen スレを見た影響。
>
>まだ変更して数日だが、なかなか良い感じで腕に馴染みやすい。まだ一部の操作は ^t から始まる一連の動作にチャンク化されたままなので困惑することがあるが、だんだん慣れてきた感じ。
>
>難点がひとつだけあって、コロン : が打ちづらい。キーが近い上に(おれは英語配列使いなので) Ctrl キーから Shift キーに左小指を素早く移動させなければならないからね。けど、まあ、それくらいだなー。適切に設定されている screen で colon を使うことはまずないし。
>
>ちなみに乗り換えの直接のきっかけとなったのは→
>http://d.akinori.org/?date=20040124#p01
>
>
>ほんと今更だけど、適当にネットを見てたら、 Google 電卓で「
>冥王星と月の大きさの比率
>
を計算してる人がいて素直に感動した。そういえば、『神鯨』のあの式も
>こんな感じ
>だ。
>
>OCaml の lazy は、循環参照が存在しないか調べることをやっていて、存在したら Lazy.undefined 例外が発生するようになっている。一方、 Scheme には promise (約束)という遅延評価が存在していて、こちらは循環参照が許されているのみならず、循環参照があったときにどのような処理が行なわれるかということの解説も書かれている。
>
>では、 scheme において (define a (delay (force a))) して、 (force a) するとどうなるか？
>
>手元にそんないっぱいの scheme 実装を入れているわけではないのだが、 Gauche では停止せず、 Bigloo では segmentation fault になってしまった。挙動としてはやはり、停止しないのが正解だと思うが、なにゆえ segmentation fault するのだろうか。
>
>ところで、 Bigloo では promise 以外を force しようとすると型エラーになるようにしているのか。
>
>D言語スレの最近の流れはぜんぜん読んでなくて眺めているだけなのだが、昨今だと「遅延評価」というとメモ化も含むようなことが多いような気がする。しかし、そうであってもそれを「遅延評価」と読んでいけないということはぜんぜんない。
>
>lazy が delegate を実現する糖衣構文だとして、うまいことやってメモ化するようなクラスを定義したりとか、できたりしないのだろうか。可能なのであればそれはそれで良いという気はする。
>
>トラックバックに greylisting を持ち込むアプローチってあるんだろうか。あーつまり、デフォルトは許可制にしておき、トラックバックを受けても、書き手がチェックしないと結果に反映させないようにしておく。しかし、書き手がいったん許可すると、相手のブログの URL を覚えておき、次からは許可なしでもスパムとみなさずに自動的に表示する、といった具合。なんかメールの greylisting よりずっと有効な気がしてきた。
>
>ただ問題点がひとつあって、「どこまでがブログの名前」で「どこからが可変領域(エントリによって変更される場所)」なのか、っていうのは、システムやサービス提供者によってマチマチなので、「覚える」ために URL を切り出すところがアドホックな処理にならざるをえず、面倒くさいということですかね。
>
>概ね、
>
>
>クエリ文字列を削り、
>
>
>
>パスの最後の区分が〜.htmlなどになっていればそれを省き、
>
>
>
>数値のみで構成されるディレクトリを排除する
>
>
>
>
>ことで「そのブログのURL」が取り出せそうな気がします、直感ですが。
>
>なんか書いてたら、既出な気がしてきましたけど、まあいいや。この日記にはトラックバックをあれこれする機能はないんで、アイディアだけでした。
>
>
>http://d.hatena.ne.jp/izumino/20060912/p1
>。こんな感じ？
>
>
>時間以外全部衝突
>
>
>
>美亜以外全部に贈る真珠
>
>
>
>時空以外全部ドーナツ
>
>
>
>タフ以外全部の方舟
>
>
>
>
>大元のネタはともかく、こういうのがあると便乗していろんな人がいろんなネタを提出するうちにスタージョンの法則が働いて全体としてはつまんないものになってしまうと思っていて、このことをおれは「ダメマッシュアップ現象」と勝手に呼んでいるのだが、まあそれはさておきおれもちょっと書いてみました。
>
>昨日のつづき。昨日は darcs の心地良さについて「すべてがパッチベースであること」を挙げたけど、よくよく考えるともうひとつある。それは「すべてのワーキングコピーがレポジトリであること」。
>
>正確に言うと、ワーキングコピーがレポジトリなのではなく、「すべてのワーキングコピーにはレポジトリ」が付随していて、それぞれ独立にバージョン管理可能な状態になっている。分散バージョン管理といっても、 GNU arch とかは(マニュアルを読むかぎり)まずユーザは自分のレポジトリを作るようだから、そのような構成にはなっていないようだ。一方、 monotone は db ファイルを指定するから、ワーキングコピーごとにレポジトリが存在するという構成になっているのだろう。
>
>で、この構成の何が良いかというと、細かいことをいろいろ考えなくて良いのである。
>
>たとえば「ブランチを切る」という行為。これは「新しいワーキングコピーを1コつくる」ということに相当する。ブランチ間で変更を移すのは、レポジトリ間で変更を伝達するのと同じこと。 darcs には、いわゆる「チェックアウト」という考え方すら(そういう意味では)存在しない。チェックアウト相当の動作は、ただ単に、
>
>
>手元に空のレポジトリを作成し、
>
>
>
>リモートのレポジトリからパッチをコピーして、
>
>
>
>そのパッチを前から順番に実行する
>
>
>
>
>ことしかしなくて、これはようするにレポジトリの複製を作っているのと同じなのだ。そして、こういう考え方はパッチベースととても相性が良い……と、思う。もっとも、 monotone はパッチベースではないようだから、そうでもないのかもしれない。
>
>ところで、この「心地良さ」は実はパフォーマンスと表裏一体になっていると言える。上のような手順を踏まないとレポジトリをコピーできないため、チェックアウトには常に、 svk でいうところの mirror の手間がかかる……といってもネットワーク越しでなければ大したコストは必要ないのだけど。
>
>darcs は、「パッチの理論」なるモノがあってなんだかややこしそうなのと、実装言語が Haskell である点に特殊性がありそうだが、そういうことはぜんぜんない。私はパッチの理論についてはよく知らないし、 Haskell であるかどうかはあんまり関係ないように思える。遅いといっても、処理系に由来する遅さは特にないし。
>
>というのを書いてから「あるのかな」と検索してみたらあった→
>http://www.equational.org/darcs-server/
>
>
>名前こそ「darcs-server」だが実体は cgi で、 http 経由でコミットしたりいろいろできるようになる。認証には gpg のキーリングを利用したり、 ssh アカウントを使えたりするらしい。
>
>「CVS は小学生まで」発言とかを見て、「subversionは中学生まで」といったアジを考えた。ちゃんとした人は、ちゃんと分散バージョン管理を使うものだ。 darcs とか。
>
>まあそれはアジなんで本心はさておき、いや、 darcs はほんとに良いのですよ。何が良いかといってスジが良い。以前は subversion を使っていたけど、自分個人としてはもう完全に darcs に移行してしまったですよ。
>
>分散バージョン管理システムは darcs 以外に触ったことがないので、ほかのがどれくらい良いのか、というのはよくわからない。では darcs のスジの良さは何かというと「バージョン管理とはパッチの管理である」という視点を一貫して持っていることにある。
>
>べつにファイルのバージョンを管理しようがパッチの管理をしようが、ふつうに管理する際にはどうでも良い。ところがこれが分散するとどうでも良くなくなる。レポジトリ間のやりとりというのは、バージョン間の差分であって、それはつまりパッチのやりとりだからだ。 darcs では、ファイルのブランチであるとか、同一起源を持つかどうかといったような問題は一切考慮しない。単にパッチと、パッチ間の依存関係を持っているだけだ。やろうと思えば、全然別の起源を持つ2つのレポジトリをマージしてひとつのレポジトリとして提供することもできてしまう。これはお手軽お気楽極楽でたいへん心地良い。サブコマンドはいっぱいあるが、 cvs や subversion にイマイチ使ったことのないサブコマンドがあるように、覚えなければならないものはほとんどない。
>
>darcs の主な弱点は2つ。
>
>第一に、遅いこと。個人レベルの、あるいは小規模のものであれば大した問題はないのだが、 darcs の「パッチのやりとり」では、パッチひとつひとつがファイルになっていて(gzip圧縮しているが)それを受け渡しするので、膨大なパッチを有するレポジトリを持ってこようとすると、ファイルのやりとりに時間がかかるようになる。これの対処として –partial とか、複数のパッチをまとめて一つのパッチにする機能とかがあるみたいなんだが、いまいち有効に機能しているとは言いがたい感じ。
>
>第二に、認証系が弱い。個人レベルだと、 ssh 経由でコミットする方式が用意されているので楽勝だが、それ以外の仕組みがいささかメンドくさくて、たとえば、 subversion みたいなサーバは用意されていない。ただこれは、余計な認証機能を組込まなくて済むっていう意味ではシステム管理者にとってある意味で楽な面もあるだろう(だいたい個人レベルの subversion ユーザはほとんど svn+ssh を使ってると思うし)。また、マニュアルにはいろんな技術との組合せレシピが載っていて、パッチがメールで送られたときに(パッチをメールで送る機能 – darcs send – がある)うまく処理する procmail のレシピとか、そういうのもある。でも、まあ、弱いなぁとは思う。アドホックで個別対応的になっちゃうから。
>
>ほかにもフックスクリプトの機能がないとか、多言語対応が弱いといった小さな問題もある。フックスクリプトについては、自動でテストを実行して失敗したらコミットを拒絶する(make test に通らないパッチは受け付けない)という機能があったりはするので、そんな問題にはならないんじゃないかと思う。ちなみに、テストスクリプトの機能は下手を打つと危険なのでデフォルトは何もしません。多言語対応については、デフォルトの動作だと 8bit 文字はエスケープしてしまうので、 darcs whatsnew とかやると凄いことになってしまうことがあるという問題で、これは環境変数を設定すれば直る。
>
>というわけで弱点はあるけれども、個人レベルのユーザにとって大した問題はぜんぜんないです。 darcs、オススメですよ。
>
