Hatena::ブログ(Diary)

あどけない話

2009-09-27

クライミングジム・マップ

重い腰を上げて、クライミングジム・マップを更新しています。

クライマーの方へ

ずいぶんさぼっていましたが、ジムをいくつか追加しました。手元の未登録リストには、まだ30弱ぐらいのジムあります。暇を見つけては追加していきます。

Googlemaps プログラミングに興味がある人へ

今まで Googlemaps API v2 を利用していましたが、今回は Googlemaps API v3 を使用しました。v3 の特徴は以下の取りです。

  • 登録キーが不要になった!
  • 複数の吹き出しを同時に表示できるようになった
  • 地図のロードが速いらしい
  • ようやく、名前空間を慎ましく使う、まともな API になった

これでまで、ジムのデータは XML で保持し、XSLT をつかって吹き出しを作っていました。XSLT を利用したのは v1 に XSLTAPI があったからです。v2 ではなくなりましたが、GoogleXSLT ライブラリを利用していました。

しかし、静的なデータなので XSLT を利用する必要もないし、XSLT ライブラリを読む込むのは嫌だし、XML は人間が書く書式ではないし、という理由から、XSLT の利用はやめました。ジムのデータは YML で保持し、Haskell で書いたパーサーで、JSON へ変換しています。プログラム自体も、気分も、かなりすっきりしました。

あと、緯度経度を調べるのはもう嫌なので、Geocoder を使って住所から位置を特定できるようにしました。

2009-06-30

高階関数と無名関数

Ruby ではブロックが自慢らしい。制御構造を自由に作れる感じがするのだと言う。

obj.foo do |x,y|
    x を使う
    y を使う
end

これは、高階関数の最後の引数として無名関数を渡していることに他ならない。他の言語でどうなるか考えてみる。

JavaScript ではこうなる。

foo(arg,function(x,y) {
    x を使う;
    y を使う;
});

たしかに、function とか閉じ括弧が冗長な印象を受ける。

Haskell で書くとこうなる。

foo xs $ \x y -> do
    x を使う
    y を使う

end がない分、Ruby よりもすっきりした感じ。

Python でも同種のレイアウト規則を採用しているので、すっきり書けるかと期待したのだが、無名関数は一行に納めないといけないそうだ。

ここで関数の名前について考えよう。ruby では、ブロックに名前をつけられないけれど、Haskell ではできる。

bar x y = do
    x を使う
    y を使う

foo xs bar

名前が付いた関数であれば、高階関数の第一引数として渡したい気になるけど、Haskell では引数の順番はいかようにでも変更できる。

実際の例を挙げるなら、forM は mapM を flip したものだ。

mapM :: (a -> m b) -> [a] -> m [b]
forM :: [a] -> (a -> m b) -> m [b]
forM = flip mapM

という訳で、Ruby のブロックは、Haskell では当たり前の機能っぽい。

間違いや誤解があれば、指摘して下さい。

2008-08-27

動的型付言語とデザインパターン

具体例で説明するデザインパターン」は、よく使われている JavaScript のデザインパターンについて分りやすく説明しています。

そもそも、僕がこのブログを始めた理由は、JavaScript のデザインパターンを議論したいからでした。(今では、全然違う内容になっていますが。^^;) そして、その議論を止めたのは、動的型付言語では、デザインパターンはそんなに重要でないと気付いたからです。

きっかけは、「ハッカーと画家」です。この本の 201ページには、以下のような脚注があります。

ピーター・ノーヴィッグは『デザインパターン』に挙げられた23のパターンのうち16はLispでは「全く見えないか、あるいはより簡潔である」ことを見出した。

これは、「Design Patterns in Dynamic Programming」というスライドのことです。

Java でデザインパターンがもてはやされるのは、静的型付言語だからだと思います。2つのクラスがやりとりする場合、拡張性を考えて、それぞれに上位の型を定義します。たとえば、三角形や四角形を汎化するために、図形という抽象クラスを定義する訳です。

こうなると、登場するクラスは 4 つになって複雑になるため、デザインパターンというカタログが必要になるのでしょう。

Douglas Crockford 先生は、「JavaScriptにおける古典的継承」で、Java のような複雑さは、JavaScript には無縁だと雄弁に語っています。

そもそも、私たちはなぜ継承を気にするのでしょうか?それには主に2つの理由があります。一つ目の理由は、型に関する利便性のためです。私達は言語システムに対して、類似するクラスの参照へ自動的にキャストしてもらうことを望みます。オブジェクト参照のキャストに、定型的で明示的な記述が必要な型システムからは型の安全性をほとんど得ることができないためです。これは強い型付け言語ではとても重要なのですが、JavaScriptのような弱い型付け言語ではオブジェクト参照はキャストの必要がないため大した意味を持ちません。

結局、「デザインパターン」に書いてあるように、言語によって何をデザインパターンだと思うかは違う訳です。

プログラミング言語の選択は重要である。なぜなら、どの言語を使うかによってどのような観点でデザインパターンをまとめるかが違ってくるからである。

もちろん共通理解として、23 個のデザインパターンを覚えておくのはよいことだと思います。

2008-03-20

Firemacs 3.1

Firemacs 3.1が受理され、正式にリリースされました。Firefox 3 を使っている人は、ぜひ活用して下さい。

2008-03-14

Firemacs 3.1

Firemacs 3.1を提出しておきました。承認されれば、公開されます。

Firemacs 3.1 のバグ

あー、提出した途端にバグを発見。はぁ。wiki のアクセスキーが自動的に解除できなくなっていました。Google のお告げで、一瞬で直せました。Firefox 3 で XPath を使うには、適切な `document' を使わないといけないんですね。