「MochiKit」を含む日記

■lispといえば

AutoCADだよなと思う。なんでlispなんかな。

そういえばPhotoshopはpythonだよな。なんでなんかな。

高いソフトって変わってるよな。あんなバカ高いソフト誰が買うんだろうな。

そういえばここってMochikit使ってるよな。はてなのみんなもMochikit大好きなんかな。

AutoCAD、Photoshop、増田、みんな関数型嫌いなのに使ってるのかな。マゾかな？

それとも好きなのに悪態ついてるのかな。ツンデレかな？

それにしても、なんで日本じゃlispもpythonもメジャーにならないのかな。なんでなんかな。

でも、Google先生は「ruby S式」って言ってるけどな。

rubyってS式すきなんかな。変態かな？

http://anond.hatelabo.jp/20080922131514

Permalink | 記事への反応(0) | 19:03

ツイートシェア

■tst

<script type="text/javascript" src="/js/MochiKit/1125/Base.js"></script>

Permalink | 記事への反応(0) | 03:52

ツイートシェア

■怠け者へのmochikitノススメ

javascriptライブラリMochiKitというのをご存知だろうか？

私はこのライブラリを採用して非常に開発が楽になったことから諸君にもおすすめをしたいのでサワリだけ紹介したいと思う。

parial 引数をいちいち指定するのが面倒な人用。

配列を受け取り、それぞれを1加算した配列を返す処理を見てみよう

var arr = [1,2,3,4,5];
var v = map(
  function(x){return x+1},
  arr);

v -> [2,3,4,5,6]

となる。

複数回同じ処理を別の配列に適応する場合は

var arr1 = [1,2,3,4,5];
var arr2 = [2,4,6,8,10];
var fx = function(x){return x+1};
var v1 = map(fx,arr1);
var v2 = map(fx,arr2);

v1 -> [2,3,4,5,6]
v2 -> [3,5,7,9,11]

とできる。しかしこれを書くのが面倒な怠惰な人々のためにpartialが用意されている。

var arr = [1,2,3,4,5];
var fx = partial(map,function(x){return x+1});
var v1 = fx(arr1);
var v2 = fx(arr2);

v1 -> [2,3,4,5,6]
v2 -> [3,5,7,9,11]

とできる。partialは関数の第一引数から順に値を指定した関数を作る関数だ。

この場合はmap関数の一つ目の値をfunction(x){return x+1}に指定した関数がfxに束縛される。

もう少々一般化して配列を受け取り、それぞれをn加算した配列を返す処理を考えてみよう。

var arr = [1,2,3,4,5];
var n = 10;
var add = function(n,x){return x+n};
var fx = partial(map,partial(add,n));
var v1 = fx(arr);
n = 1;
var v2 = fx(arr);

v1 -> [11,12,13,14,15]
v2 -> [11,12,13,14,15]

ここでv1とv2の値が等しい理由はちょっと考えてもらえば解ると思う。

もちろんaddという名前を考えるのが面倒な人は

var n = 10;
var fx = partial(map,partial(function(n,x){return x+n},n));

と書いても問題ない。

compose function(N){return F(A(N))}と書くのが面倒な人へ

では、配列を受け取り、それぞれを値をn加算したあとm倍した配列を返す処理をみてみよう。

既にn加算する処理は一度出てきているからそれを利用する。

var arr = [1,2,3,4,5];
var n = 10;
var m = 2;
var add = function(n,x){return x+n};
var mul = function(n,x){return x*n};
var addMul = compose(partial(mul,m),partial(add,n));
var fx = partial(map,addMul);
var v = fx(arr);

v -> [22, 24, 26, 28, 30]

compose(f1, f2, ..., fN)はf1(f2(arguments))という評価をする関数をかえす。

つまりaddMul(n)の場合はpartial(mul,m)(partial(add,n)(N))と等価なのだ。

もちろん

var arr = [1,2,3,4,5];
var n = 10;
var m = 2;
var fx = partial(map,
            compose(partial(function(n,x){return x*n},m),
                    partial(function(n,x){return x+n},n)));
var v = fx(arr);

とかいてもよい。ただし名前を考えることの労力と、可読性を天秤にかける必要があるかもしれない。

ちなみに私は addMulを別の場所で使わない限り後者で書くことが多い。

以上のことに興味持った怠惰な貴方。

http://mochikit.com/

にいってみてはどうだろうか。

http://anond.hatelabo.jp/20070620200618#tbと同じ増田

Permalink | 記事への反応(1) | 15:36

ツイートシェア

■javascriptが分からない

いや、仕様は大体本読めば分かるんだよ。

全部がオブジェクトで実は中身はハッシュだとか、プロトタイプベースのオブジェクト指向だとかそう言うのは。

ただ、具体的にプロダクトにこう言う機能を実現させたい！って時に何をやればいいのかさっぱりイメージが浮かんでこない。

例えば、ちょっとテーブルで表を作ってどこかのカラムをクリックしたら入力フォームになってデータ入力出来る様にしたい、とかでも何から手をつけていいやら。

結局色んなライブラリを探してその説明通りちょこちょこ流用できる時以外は、あうあうあうああーーで全然ナニやれば良いのか頭が働かない。

DOMの操作が分からないってだけなのかなぁ？

phpとかでXML文書をパースして色んな処理、とかは特に躓かなかったんだけど。

AJAXとかprototype.jsとかMochiKitとか色んな技術を使おうとワケワカメになってるのもあるのかも。

昔から地道にwindowオブジェクトをチョコチョコ弄って、とかのjavascriptを書いてきた経験が無いから。

何か良い書籍とか教えてください増田

Permalink | 記事への反応(3) | 18:04

ツイートシェア

■そろそろまたJavascriptオフの時代が来た

Google Maps以前のころ。ヘビーユーザーのあいだではJavascriptオフが常識になっていた。度重なる時計の再発明に業を煮やし、IEのActiveXに警戒心を抱き、不安定なOSをさらに不安定にするため暗躍するのがJavascriptでありJScriptだった。

Google Mapsがあれだけのインパクトを与えたのは、ひとえに、こういった先入観を打ち砕いたからに尽きる。信じられないことに、Javascriptって便利なのだ。実に見事な枯れた技術の水平思考である。

Ajaxという言葉が帰納され、ライブラリがぼこぼこと発表される。ネイティブオブジェクトの拡張と、クロスブラウザのための供物ラッパー集合体たるprototype.jsを筆頭に、様々なものが世に出、様々なアプリケーションがより手軽に実装できるようになった。

script.aculo.usやLightBoxやmoo.fxといった、エフェクト中心のライブラリも出回り始める。IEのせいで煩雑な記述を強要されたグラフィックアーティストが、DOM操作によって問題を解決しようとし始めた。リンクにmouseoverしたらうっとうしいエフェクトを振りまくスクリプトが当たり前のように設けられた。このはてなも、いつの間にか大量のMochikit/*.jsを読み込んでページのレンダリングを遅らせている（たまにad.hatena.ne.jpのレスポンスが遅いときなど目も当てられない）。これらに共通することは、多くの人がそれを望んでいないということだ。

もちろん好ましい方向への進化もあった。OperaがUser Javascriptを発案・実装し、FirefoxもGreasemonkeyでそれに追随。SafariもCreammonkeyを得て、いわゆるモダンブラウザユーザーは、豊かなスクリプトライフを楽しめるようになった（IEにもなんとかいう同様の機構を実現する環境はあるが、IEユーザーには敷居が高いのかほとんど見かけない）。Livedoor ReaderやGoogle Readerはイベントを操作することで、キーボードでの操作を今までにないほど豊穣にした。入力フォームのリアルタイムバリデーション、Google AnalyticsやAdsenseの導入容易さなど、見るべき意匠もいくつかある。

しかし平均的に考えて、何の変哲もない個人ブログにJavascriptは必要ないものだ。素人がつくったタイマーは、いつもユーザーを憂鬱にする。素人がつくったAjaxサイトは、だいたいの場合IEとFirefox以外を排除するもっともらしい理由を得るためにAjaxを使う（Dellが自社サイト上で「Netscape4.6以上で閲覧せよ」と警告することによって、やる気のなさを主張するようなものだ）。

我々が自分のブラウザ上でページを表示するとき、Javascriptによる意外な効果などまったく期待していない。UIにおいては最速こそ正義、というmala氏の言葉を引用するまでもなく、不必要に重いサイトはそれだけで忌避するに足る理由となる。流行を追って常識を忘れるのは愚かとしか言いようがない。

Firefox(のNoScriptアドオン)とOperaは、ページごとサイトごとにきめ細かなJavascriptの挙動を設定できる（不勉強にしてSafariについては知らない。IEはできない）。Javascriptに限らず、広告ブロックや不要ファイルの無視、特定Flashの再生可否など、ユーザーは「何が要らないか」を指定でき、要らないものを気軽に突っぱねられるようになった。不要なものを除去する習慣が、ヘビーユーザーのあいだで間違いなく形成されつつあるのだ。

何かひとつのことをするためのJavascriptは、これからしばらく出現し続けるだろう。ウェブマスターが、重厚長大な飾りで貧弱なコンテンツを隠すためだけに。何かを拒絶するテクノロジーは、今後しばらく発展し続けるだろう。十重二十重のラッピングに疲れた人たちのために。

Permalink | 記事への反応(4) | 21:11

ツイートシェア