めも

そんな HTML5 なんて

2009/11/19 | めも | コメント (3)

先んずれば人をなんとやらということで，というかビーム君に触発されて*1勉強中． 勉強するというほどの内容はない気もするけど．要は慣れるか慣れないかという話であって，慣れてないといざというときにめんどいという話であって．

しかし今まで哲学だったものが規則になっていたりしてニヤリとする部分がある反面，それ 20 世紀の世界じゃないですかな部分もある．……色んな事情があるんだろう．

ひとつ言えることがあるとすれば普及して実用に支障が生じなくなったら XHTML5 で書くだろうということだな．

まあ，体力にものを言わせて新しいものに食いついて噛み砕いていけるうちは全然大丈夫． それができなくなった瞬間から先のことはあまり考えたくない（が，考えないといけない）．

  1. このリンク先エントリの萌えるところは，「HTML5 に移項した」 の部分が強調されつつ誤字っているんだけどまあしょうがないよねこれは，と思えるあたり． [↩]

漢字かな変換のテスト中

2009/09/10 | めも | コメント (0)

といっても自分で実装するわけがなく先人の成果物を弄り回してるだけだけど．

http://dvorak.jp/lab/hconv/

Namazu つながりで知ってた KAKASI と，調べたら出てきた ChaSen と MeCab*1を叩いてみる．

coreserver に自分で入れるかーと思ったら全部デフォで入っていた．妙なところでさすが．

試しもせずに大した精度ないだろうと思っていたんだけど，一番新しくて賢げな MeCab はもちろん，古き良き KAKASI もさすがにこういうことに目的を絞ったソフトウェアなだけはあって頑張ってくれる．綺麗な日本語を突っ込む分には良い精度で機械的に変換できるもんなんだね．

ということがわかった．

もちろんというかあろうことかというか，応用先はタイピングゲームで． 漢字かな交じりの普通の文章突っ込むだけで打鍵対象に出来たら色々面白いかもねという． ブログのエントリがそのまま打鍵対象になるスクリプトだとか，RSS を取りこんでワードセットにするゲームだとか，ニコニコの歌動画のコメントから歌詞っぽい投稿してる人指定するとタイピングゲームになる TypingTube 改とか．

そんなもん書いてる場合じゃないですけどね常識的に考えて．

  1. これらは漢字かな変換っていうかガチに日本語形態素解析する用途で書かれた学術的なもの．言語情報科学に行ってたらお友達になっていたであろう子達である． [↩]

D-JS をもうちょっと実験

2009/09/01 | めも | コメント (0)

引き続き弄ったが気力がなかったので C++ 側ではなく D 側でしこしこ．

先日の D 文字列をばんばん eval して使うという怪しげな使い方をもうちょっと進めて，違和感なく D 関数として js を実行できるようにしてみる．js 関数のインポート，とは微妙に違うけどノリと実現できることは大体そんな感じ．

発想としては js コードを引数にとって D 関数を返すような関数を作ればいい．こういう lambda っぽいことは当の js さんの方が当然得意で，js 書けば 

function hoge(code)
{
    return function(){return eval(code);};
}

とかこういうの．D 言語でも言語レベルでデリゲート使った動的クロージャ利用ができるので似たような書き方でいける． 

typedef string delegate() JS; // 強い型付け
 
JS jsFunction(string code)
{
    return cast(JS){return v8d.eval(code);};
}
 
JS hello = jsFunction("['H', 'e', 'l', 'l', 'o', "!"].join('');");
hello(); // => "Hello!"

関数リテラルで無名デリゲート書けるので本当に同じノリ．

んでさらに，引数を取れるようにしたい．

事前にソースコードを与えて関数（デリゲート）を作成してるので，その呼び出し時に引数を事前に与えた js ソースの適切な場所に埋め込んでから V8 に食わせるという形．

書式付き文字列ですっきり実装できるんじゃない？ とやってみる． js ソースとして 

"%s".substr(%d, %d);

とかを与えておいて， 

JSsubstr("hoge", 1, 2);

と呼ぶとその内部で 

string formatted = std.string.format(`"%s".substr(%d, %d);`, "hoge", 1, 2);

な形で呼び出されて，formatted すなわちここでは 

"hoge".substr(1, 2);

が評価されて，めでたく “og” が返ってくるという感じ．

引数の型がまちまちなんでテンプレートかなと若干憂鬱になるが，D にはテンプレートを使わない組み込みの可変個引数関数があるよってことで使ってみる． 

typedef string delegate(...) JS; // 強い型付け
 
JS jsFunction(string code)
{
    return cast(JS)(...){
        return v8d.eval(code);
    };
}

ところがこう可変個引数関数へのデリゲートに変更した途端にコンパイルが通らないというか dmd コンパイラが落ちた．v2.014 を使ってて若干古い気もしたので最新の v2.031 にすると通った．

ところがこの可変個引数が割と扱いにくい代物で，各引数にアクセスするにもポインタ経由でお世辞にもエレガントじゃないし，そのままの引数全体をさらに別の可変個引数関数に渡す簡単な方法なんかもない．タプル使えば色々できるのかな，と思うんだけどそうするとテンプレート使っちゃう．

具体的にどう問題になるかというと，スコープのひとつ外にある code を第一引数に，可変個引数デリゲートが受け取った引数全体を第二引数以降の書式指定のパラメータにして std.string.format （sprintf みたいなもん）やらを呼びたいんだけど，うまいこと呼ぶ方法はないもんか，と．

あれこれ試行錯誤して，結局美しい方法が見つからなかったので，気分の悪いローレベルなコードを書いて動かした．

同じような情報を必要としている人が万一いることも考えて詳細を書いておく．

可変個引数関数は，その中で特殊ローカル変数 _arguments と _argptr が使える．前者は型情報を保持するクラス TypeInfo の配列で，後者は引数リストの先頭の void* ポインタ（まあ C の可変個引数関数と似たようなもんではある）．

TypeInfo から型のサイズが取れる (tsize()) ので，ポインタ操作してキャストして，これらから各引数を取り出して使うことはできる．が，可変個引数関数にその全てをつっこみ直す簡単な方法は（わから）ない．

じゃあ std.string.format はどう動いてるのかと dmd/src/phobos/std/string.d を見てみると，std.format.doFormat を呼んでいる．そしてその doFormat の引数には _arguments と _argptr がそのまま使えることがわかる．今は書式化ができればいいので，この doFormat を直接呼べばいい．

自分の望む可変個引数の並びをメモリ上に構成し，_arguments と _argptr をそれぞれ更新し，doFormat に渡せば，任意の可変個引数がうまいこと渡せる．

より具体的には，_arguments を走査して現在の可変個引数のメモリ上のサイズを計算し，前時代的な malloc でそのサイズプラス追加したい引数のサイズのメモリを確保，memcpy なりバイト毎に代入なりで現在の可変個引数を新しいメモリ領域にコピー，空いてる領域に望みの追加したい引数を配置，_arguments にも追加した引数の TypeInfo（ typeid(型) で取れる）を位置を合わせ正しく追加，doFormat を _arguments と malloc した領域の先頭のポインタで呼び出し，malloc したとこ free，という流れ． 

JS jsFunction(string code)
{
    return cast(JS)(...){
        int size = 0;
        foreach (arg; _arguments){
            size += ((arg.tsize() + size_t.sizeof - 1) & ~(size_t.sizeof - 1));
        }
 
        void* argptr = malloc(size + string.sizeof);
        *cast(string*)(argptr) = "{" ~ code ~ "}";
 
        byte* fp = cast(byte*)_argptr;
        byte* tp = cast(byte*)argptr;
        for(int i = 0; i < size; i++){
            tp[i + string.sizeof] = fp[i];
        }
 
        _arguments = typeid(string) ~ _arguments;
 
        string formatted;
        std.format.doFormat((dchar c){formatted ~= cast(char)c;}, _arguments, argptr);
        free(argptr);
        return v8d.eval(formatted);
    };
}

とこれで 

JS init = jsFunction("var ts = new Tsuikyo();");
JS add = jsFunction("var w = ts.add('%s');");
JS stroke = jsFunction("w.stroke('%c');");
JS printTimes = jsFunction("for(var i = 0; i < %d; i++) print(w.get%sString());");
 
init();
add("ほげ");
stroke('h');
stroke('o');
printTimes(3, "InputKey"); // => "hohoho"

みたいなことは実際にできるようになった．

引数の数や型の簡単なチェックを入れるとか，細かいことはまだ色々．

D から js を利用する……というよりはメタプロの魔の森に足を踏み入れかけているだけのような気はすごくする．

今さら感漂うが Google V8 JavaScript Engine を使ってみた

2009/08/31 | めも | コメント (0)

D 言語上から JavaScript 使いたいでござると試行錯誤した記録*1．SpiderMonkey もトライしたんだが結局 V8 に．

説明の順序がアレな気もするけど Google V8 JavaScript Engine っていうのは名前にもあるとおり JavaScript エンジンで，Chrome に採用されてるやつ．オープンソースなのでフリーに使うことができて，組み込むことでアプリケーションに JavaScript を解釈する機能を持たせることができる．

この手のモジュールってオプソとは言いつつも自社製品特化のためとかなのかなんなのか，ごにょごにょだったりして使い勝手がいまいちで，自アプリに便利に組み込んで使えるという地点からかけ離れていることが少なからずあるんだけど，さすが Google というべきか，

  • 言語 C++
  • 気の利いたビルド環境
  • 導入ドキュメントばっちり*2
  • 隠蔽度が必要十分
  • 他外部ライブラリに非依存
  • ライセンスは修正 BSD

と十分に使いやすいものになっていた．

参考ページ

できたこと

  • 簡易インタフェースを C++ で書いて共有ライブラリ化． D からそれを呼ぶ．
  • 実行コンテクストの切り替えや js の評価と結果の取得とか基本的なこと．
  • D の関数を js にエクスポート（js から D の関数を呼べる）．
  • tsuikyo.js を実際に D から使ってみるなど．

まだだけどやりたいこと

  • ラッパをなんとかして D のオブジェクトの js エクスポートを楽に．これ的な．
  • 拡張を考えて実装してみる (誰でも考えるであろう include(’hoge.js’); とか）．
  • ゲーム用スクリプトエンジンとして js 使えるようなフレームワーク考える．

ぐだぐだメモ

  1. がっつり何かを作る時間がないから，こうやって外堀を埋めていく毎日． [↩]
  2. ただし一歩進むと一気に情報量は減る． [↩]
  3. すげーな誰のページだろ，と思ったら tossy-2 さんかよっていう（すごく遠いけど知ってるっちゃ知ってる人） [↩]
  4. 試してないので偏見かも． [↩]
  5. 実装が C だからしょうがない部分ではある． [↩]
  6. dm/bin に入ってる．早く気付けよ……． [↩]
  7. @v2.014 [↩]

そして創作妄想

2009/08/10 | めも | コメント (0)

前エントリを書いていて，伏線とかパラドックスとか因果律がどうのこうのとかが錯綜するアレなタイプのストーリー構造の型を機械的に生成したらどうよと思った．

人間がやるからアホな矛盾とか出るのであって初めから決められたルールと公理から機械的に正しいものだけ生成すりゃいいのよという形式・公理主義をこんなところで爆発させるとどうなるのかという．

論理プログラミング的といえばそんな感じで，公理から，複雑怪奇ではあるけれども確かに矛盾無く正しいプロセスを経て，ただ一つの結論を導く論理ツリーのようなものを作る．作ると言っても根，すなわち結論から逆向きに作る．最終的に結論を導くに足る論理構造を展開して作って，適当に情報が散らばったところでやめる．もちろん興味の関心は根や葉そのものではなくて，実際にそれを演繹する過程であって，すなわち過程がストーリー（謎の構造）となる．

適当に数を決めておいた変数だの演繹だのに実際にその特性を満たすような現実の要素をそれぞれ当てはめていって，違和感のない対応関係ではめきることができたら，複雑怪奇でとても人間が考えたとは思えない情報密度でありながら矛盾が出ないという凶悪なミステリーとかが構築できそうな．

それが小説として面白いかどうかはさておき*1，高階論理と文章の織りなすなんとかかんとか，とかいって芸術のひとつとして主張できそうな形にはなるんじゃね？

問題があるとすれば現実の要素との対応関係をつくるところかなぁ．実際の人間だとかものだとかには属性が多すぎて，適当にはめると元々の論理式が意図していないような関係が紛れ込んでしまって，結局矛盾に陥ったり解がひとつに定まらなかったりしそうだ．

さすがに現実世界全体をモデルにするには厳しすぎる気がするので，何かしら限定的な環境を想定して，そこだけの話にするとかすればなんとかなるかなぁ．なんというか，かつての人工知能 on Lisp な流れではあるが．

独房の中にそれぞれ特徴を持った凶人が 5 人いて……とか． ありがち．

教室全体が未来に飛んでしまって，クラスメイトが……とか．あるある．

うん，まずその環境選びからして大変そうだ．

このアイディアについて権利を主張することはしないので芸大の卒論とかとかに使いたい人は好きにどうぞ．

  1. おそらく最強につまらないであろうことは想像できる． [↩]

メールアドレスはいかにして載せるべきか

2009/07/29 | めも | コメント (11)

アドレスをエントリ内に打ってて思ったこと．

メールアドレス表記に細工して蒐集エンジンに拾われないようにすること，例えば

hoge◎example.com

が常識化してる気がするけど，個人的には試してもベタで書いてしまうのとあんまり違いを感じない．スパムフィルタが優秀だから気づかないとかではなくて，一時期ほど平に書いてあるアドレスに鬼の如くスパム送るってことがされなくなった気がする．実地に調査したデータみると面白そうだ．mailto つけとくとどの程度差が出るのか……とか興味ある．

で実際にそういう細工の効果の度合いについて推測してみると， @ を☆とかアットとか [at] とかにしたところで，そういう文化はスパマーさんもご周知な以上，ちょっとパターン調べてちょっと正規表現弄るだけで手間というほど手間かけずに 8 割 9 割対応できちゃうし，さすがにそれくらいの脳味噌はもってる人たちだと思うんだよなぁ*1．ドメイン部分の調査に . を使っていることが多そうだから，それも [dot] なり _ なりにする，くらいすればどうかわからんけど．

そんなことするより， JavaScript が ON だとみなしていいモダンな環境ならメールアドレス部分をスクリプトでなんらか動的に書き出したりすれば問題なくなる話だとは思う．google ですら js で内容ゴリゴリ書き換わるページの扱いは考えあぐねてるくらいだし，ブラウザでスクリプト走らせてからソースの調査とかいう対策は効率の点からいってやらないだろうし*2，まあ 9 割 9 分 9 厘 9 毛安全．

それよりは認知度が高そうな，アドレスを画像にしておくっていう手はより簡単確実そうに見えて，そうでもない．CAPTCHA 破られまくってるし．

やるとすれば全ての画像を解析対象にするのは現実的じゃないので，メールアドレスが描いてありそうな画像ファイルに限定して読ませる……とかやるのかな．その絞り込み条件は画像サイズ*3*4とか，それらしいファイル名*5の辞書作るとかでそれなりの精度が出そう．で，いざ OCR な段になれば対象はきっとメールアドレスであるというバイアスの元に読めばいいので精度高そうだし，明らかに無理そうだこれ違う画像だろという判断も簡単．

……という風に素人でもなんとかできそうな程度には危ない．とはいえ単純に正規表現でガシガシ拾っていくのに比べれば実装がめんどいのと調査効率が落ちることの二点から現実的には問題ないが．

ただ画像ファイルにする方法は，メールアドレス毎に画像を用意するのが若干めんどい上に，コピペ不可能，実際にページの上に表示した際にもああこれ画像だなあという違和感，浮いた感じが拭えない*6等という欠点が目立つ．

JavaScript にやらせる方法なら一度スクリプト用意すれば画像をいちいち作る手間はないし，実際にブラウザで見る時には平にアドレスが書いてあるわけで自然．なんなら mailto でアンカーつけちゃっても問題ない．逆にこちらの欠点は JavaScript 切ってあると残念っていうこと．

総合するとブログのエントリだとか，wiki 内ページだとか，そういうテキストテキストした場所に自然かつ安全に埋めるには スクリプトに頑張ってもらうのがいいんでないかと思ったのが結論．

でもって大事なアドレスでもないしクライアントサイドでフィルタあるから別に拾われても構わんよという開き直りができるなら（俺はできる状況），そのままベタ書きすればいいだけの話．

  1. と思いきやメールアドレス収集ツール今だけ特価 39,800 円！　とかを使っている残念な人ばっかだという話も聞く． [↩]
  2. そんな一部の漏れにこだわってる暇があればより多くのページをクロールする． [↩]
  3. デカすぎる画像はメールアドレスでない可能性が高い．ある程度以上に横長の画像がメールアドレスである可能性が高い． [↩]
  4. 画像ファイルのピクセルサイズ調査は（jpeg gif png あたりの規格詳しく知らないので合ってるか知らんけど）画像ファイルの先頭 1KB くらい読めばヘッダ部から判断できそうなので画像を全てダウンロードするなんて馬鹿なことはしないで済むはず． [↩]
  5. address とか mail とかでもうかなりの割合だろう． [↩]
  6. これはフォント合わせてサイズ合わせてレイアウト頑張ってすれば改善はするだろうけどそんな馬鹿みたいなことは普通しない． [↩]

小手先のそれより仕様や設計

2009/06/07 | めも | コメント (0)

バイトでコード書き始めたのがきっかけで，小規模なプログラムでも紙と鉛筆でかっちりクラス図書いたりして納得してからじゃないと実際のコード書きたくなくなった．というかいろいろ怖くて書けなくなった．良い傾向なのか違うのかは知らない．

我流の限界を感じるので UML を勉強しよう……．こんなもん職業 SE になったりしないと使わないよねとか思っていた時期が俺にもありました．

また暗記か

2009/05/08 | めも | コメント (2)

ブログ等は RSS リーダ辺りに任せておけばいいとして，よく使う web サービスだとかの，更新された情報をチェックするわけではないが能動的に開く機会のあるページの URL の保存・アクセスをどうしたもんかと．

ローカルのブックマーク使うのが苦手で，web サービスのそれはもっと苦手．理由は色々ある気がする．追加するのがめんどいとか，整理されずぐちゃぐちゃになるのが嫌だとか．ほとんど好みの問題だけど．

特筆すべきはアクセスしたいときにキーボードだけで辿ろうとすると不快だという点．この点 IE も Firefox も Chrome も Safari も*1似たようなダメさで*2．ホームポジションから手を離したくない人のこととか考えてらんないからしょうがないが．

そんなにキーボード操作大好きなら拡張入れればいかがっすかと言われると，ゴテゴテした拡張入れてそれに慣れるってことはしたくないんだよね，とかお前あれもだめこれもだめ贅沢言いすぎだ死ねという感じですが，まあ実際そう思っていて*3．

最近は URL のうち特徴的な部分*4を覚えておいて，ショートカットキーでアドレスバーにフォーカスを移して，覚えた文字列入力して，ヒストリから候補出たところで tab で補完確定して enter ，という行動をしている．Firefox でニコニコなら Ctrl + L n i c o Tab Enter，とか．操作としては標準的なシェルの補完っぽいので違和感あんまない．

そこそこ使えるんで多分同じことしてる人がいる所には相当数いると思うんだけど，その基本だけでは機能的に足りない．例えば覚える特徴的な部分は大抵ドメイン部になるわけだけど，同じドメイン内に候補たくさんある場合とか困るし，じゃぁディレクトリ名やファイル名を入力して，と思ったらそちらはそちらで意図しない別のドメインのものまでひっかかってきたり．

実は，というほどのことでもないけど，Firefox ではスペース区切りにすると上記ヒストリ検索で AND 取ってくれる． dvo yae で dvo(rak.jp) 内の yae(t) ディレクトリ内のページとかが候補になって，あとは tab 1 打が 2 打でなんとかなると．

キーボード派としてはブックマーク使うよりは格段に便利．一切の拡張や設定が要らないのもいい．

こうなってくると検索ボックスにスペース区切りで URL 入れてぐぐるのと同じじゃねと思うかもしれないが，そんなことはなくて，対象はローカルヒストリ内だけだから過去にアクセスしたページしか出てこないだとか，検索対象は URL 文字列だけだとかが，十分ブックマーク的だと思う．

URL の部分を覚える分人間の負担は少しあるけど，適当にブックマークしてどこにやったかわからなくなるとか，たまに整理しないととんでもないことになるとか，いちいち整理で自己満足するために時間が潰れるだとか，タイトルが非 ascii 文字で始まってるとキーボードショートカットでアクセスできないことになるとか，そういうことがないのは幸せ．何より，使用頻度が低いものは自動的にブックマーク空間（脳）から削除されていくという仕組みがスマート*5．

問題は，ヒストリに依存してるから PC 間で同じ結果にならない*6あたりか．それが気になってかつ気分的にヒストリ共有して問題なさげならそのためのプラグイン等はある*7し，そういうのでやればいいんじゃないかな．やらんけど．

  1. 多分 Opera もその他も． [↩]
  2. web サービスは言うまでもない． [↩]
  3. mayu は笑顔で使うくせにね．どこか一貫してないとは思う． [↩]
  4. Firefox なら，ドメイン・ホスト・ディレクトリ・ファイル名から先頭一致で調べてくれるから，そのどれか． [↩]
  5. 消えて困るものは別途なんとかするとして． [↩]
  6. 最悪，一度もアクセスされていなくて出てこない． [↩]
  7. Google Browser Sync とか． [↩]

mac も買うかも

2009/02/24 | めも | コメント (2)

正直言って mac とか 21 世紀には滅びてるだろうなと昔は思ったものだけど，全然ピンピンしていて，最近の傾向だとむしろ躍進してる感じなんで，知識無駄にならないならまあ戯れに触ろうかなあとか．

ECCS の環境でもいいんだけど，やっぱよくなくて，所有しないことには文化がわからないし，マルチプラットフォームーとか言おうとするとどうしても mac のこと考えないといけない風潮だし，CUI でなんかする分にはただの unix だし，一台あって使わないってことはないはず．

思うに mac の問題点はみっつくらいあって，無駄に高いことと，ラインナップがミドルレンジモデルくらいまでしかなくてどれも全然高いことと，販売戦略のせいでいつまで経っても高いことだよ．それが mac の品質に……とか寝言は寝て言えっていう感じがするからな．マカーは洗脳されすぎである．嫌いではないけど，金あるんだなーみたいなジェラシーは感じる．

幸いにして mac mini という手頃なのがあることはあるんで，多分そうする．もう mini の新型はでないのではないかと噂されていたかと思えば最近になって mini の新型のリークというか噂情報とかが出回りだしてるようなので，とりあえず様子見．

新型が出たらそれ買うか，出た効果で安くなった旧モデルを買うかを考えよう．

mod_rewrite で query string の扱い

2009/02/11 | めも | コメント (0)

評価対象のパス文字列中に含まれるもんだと思ってたら違って若干嵌ったので俺メモ．

/hoge/dir/file を hoge.cgi?d=dir&f=file に向ける的処理はありがちで問題ないんだけど，例えば hoge?a=b を unko?file=hoge&a=b に向けたいときとかに，? 以降全マッチさせるようなルールを書くと残念なことになる．

調べてみるとクエリー部分は %{QUERY_STRING}*1に入るそうなんでそれを向ける先に使って， 

RewriteRule ^[a-zA-Z0-9_-]+$ unko?file=$0&%{QUERY_STRING}

という感じでやるとできる．

……のだが，それもまだ無知な感じで，[QSA] オプションつけると自動的にクエリーを保存再現してくれるようで． 

RewriteRule ^[a-zA-Z0-9_-]+$ unko?file=$0 [QSA]

より平易．知ったかしてなんとなくで使わないでちゃんとドキュメント読みましょうという話．

  1. ? は含まれない． [↩]
« Previous Entries

サイト内検索

カテゴリ

ログ

最近のコメント

携帯版

http://gohan.wotaku.jp/
PC と共通の URL で OK．