2007年2月アーカイブ

『デザインパターンとともに学ぶオブジェクト指向のこころ』を読み終えたので、改めて『増補改訂版 Java言語で学ぶデザインパターン入門』を読み返しています。

Builderパターンにおいて、ConcreteBuilderをクライアント側で用意するのはなぜでしょうか？Director内で用意してはいけないのでしょうか？

『Directorは特定のBuilderのみを扱う』という理解でいるのですが、間違いでしょうか。特定のBuilderのみを扱うのであれば、Directorの中でConcreteBuilderを用意する事も難しくない気がします。

例えば、BuilderFactory::factory(type)などとして、DirectorがConcreteBuilderを知らないままConcreteBuilderを用意する事が出来るように思います。『Builderファミリから特定のConcreteBuilderを作るための指示』は出しますが、それが具体的に何であるのかを知るわけではなく、Builderが定義しているインターフェースを実装しているオブジェクトである事だけを知っているという前提に従ったままです。

Directorの責任が増えてしまう様な気がしますが、それでもクライアント側がBuilderの存在を知る必要があるのか疑問です。クライアントは『使いたいモノを使う事が出来る』という目的をかなえられれば良い気がします。それであれば、『モノを組み立てる実際の誰か』を知る必要があるのでしょうか？また、クライアント側がそのモノを組み立てる誰かを保持するのもどことなく気持ちが悪いのです。

1. コンフィギュレーションを使いたいモノを作成する(Builderを扱う)Directorに与えて、DirectorがBuilderを用意する
   (実際には何かしらのファクトリがBuilder作成の責任を負う)
2. クライアントで使いたいモノを作成するためのBuilderをクライアントが用意して、それを扱うためのDirectorに渡す
   (実際には何かしらのファクトリがBuilder作成の責任を負うかもしれない)

Builder作成の責任を誰が負うのか？Directorが(間接的にしろ)その責任を負うのは誤りなのか？

Directorはモノを作る行程について責任を負います。ConcreteBuilderの生成をDirector内部で行うようにした場合、クライアント側でモノを受け取るためにはDirectorがそのインターフェースを用意しなければなりません。モノを受け取るためのインターフェースはConcreteBuilderが用意しているはずです(これはBuilderがインターフェースを定義しているかもしれません; 静的型付け言語であればConcreteBuilder)。

さて、Directorに新たな責任が発生しそうです。モノを受け取るためのインターフェースをDirectorに用意すべきでしょうか。モノを作るインターフェースがDirector::construct()だったとして、このconstructメソッドが値を返すようにするか、専用のインターフェースを定義／実装する事になります。

Builder パターンを読んで少し理解出来た事があります。『どうやら静的型付け言語による実装のための制限がありそうだ』という事です。型の制限があるために、どこでどのような責任を持たせるかが決まる事があるようです。

さて、『Directorが作られたモノを返す責任を負う』事は誤り(適切でない)でしょうか？作られたモノを返す大本はConcreteBuilderなわけですから、ConcreteBuilderから受け取るべきでしょうか？

昨日ようやく『オブジェクト指向における再利用のためのデザインパターン』(いわゆるGoF本(の訳書))を注文したので、火曜か水曜辺りからこの辺の疑問も解消出来るかなと期待しております。

デザインパターンとしてまとめられたものが絶対の答えではないわけで、この疑問は『センスで』として片付けられてしまう事かもしれません。が、GoF本を読んでいない『デザインパターンのまた聞き状態』ではお恥ずかしながら判断出来ません。そもそも、ろくな設計が出来ない身でもあるので、経験から判断する事も出来ません。

この本いいですね。
デザインパターンとともに学ぶオブジェクト指向のこころ

おいていかれました。おいてけぼりです。

会社の開発チームの面々でオデカケしていく様を、泣く泣く見送りました。

まあ、ノートPCないし、買おうにもLeopard出るまで購入に踏み切れないしで、お断りしたわけですが。そもそも、ネタがありません。が、同行だけして、ひたすら本を読みあさるというのも新鮮だったかも。。。

ひとまず、今回の合宿で何が生み出されるのかに期待します。

『１台でN台』

OSX+BSD+Win+Linux+...(by ParallelDesktop)

python-mode.elを見て、使いながら解釈しつつメモしておきました。
KOSHIGOE学習帳 - [python]python-mode.elのキーバインド

いまいち理解出来ない関数がありますが、インデントと実行、ヘルプ表示くらいは覚えておきたいと思います。PHPではリージョンのeval(実行)を自作したりしましたが、python-mode.elでは普通に"C-c |"として用意されてますね。php-mode.elにもあったのかな？

HTMLドキュメントを用意していないせいで、"C-c C-h"でヘルプが表示出来なかったので"/opt/local/share/doc/python-2.5/html"に置いておきました。併せて、環境変数PYTHONDOCSもセット。

というところで、今日はおしまい。

PHPであれば、"dirname(__FILE__)"としてファイル自身が置かれているディレクトリのパスを取得しますが、Pythonではどうするのか。

import os
print os.path.dirname(os.path.abspath(__file__))

Python2.4.3ではこれで大丈夫な様子ですが、もっと簡単(簡潔)な方法がある気がします。。。

Pythonの__file__は、いわゆる$0(コマンドライン引数の0番目=実行ファイルまでのパス)が格納される様子。

ちなみに、PHPではファイル自身のフルパスが__FILE__に格納されています。

Djangoのキャッシュに関するドキュメントを読んでいて、(Python2.4から)デコレータ構文というものが使えるらしいと知りました。

関数・メソッドのデコレータ :: Python 2.4 クイックリファレンス
関数にデコレータを適用する『構文』については、上記リンク先の説明を読むだけで理解出来ます。デコレート対象の関数を作成する直前の行に@を頭につけたデコレータ関数名を記述するだけ、と。デコレータ構文の効果は、関数を関数でラップ出来るよ、という事でしょう。

そこで、実際に適当なコードを書いてみようと思ったのですが、デコレータが(内部的に)どういう動作をするのかがいまいち掴めませんでした。特に、引数をとる関数に対するデコレータを書く場合、実行時に渡された引数をどう引き継ぐのかに困りました。

ITmedia エンタープライズ：2.4への機能強化で広がるPythonの世界 (3/4)
上記リンク先のリスト３のコードを参考にコードを書いてみて、ようやく(それっぽい)解釈が出来ました。

# -*- coding: utf-8 -*-
def decorator(*deco_args):
    # デコレート対象とラッパー関数とを結びつける
    # ここでの引数fはデコレート対象の関数が実行されたときの暗黙的な第１引数
    def director(f):
        # デコレート対象の関数の実体を置き換える関数
        def wrapper(*args, **kwargs):
            print "in wrapper", deco_args
            return f(*args, **kwargs)
        # デコレート対象の関数と置き換えの関数とが同じ実体となるように結びつける
        # ここでデコレート対象の関数が実行されたときの引数を引き継ぐようになる
        wrapper.func_name = f.func_name
        return wrapper
    return director
 
@decorator(1, 2, 3)
def func(x, y):
    return x * y
 
print func(3, 5)
print func(4, 5)
 

$ python sample_decorator.py
in wrapper (1, 2, 3)
15
in wrapper (1, 2, 3)
20

まず、デコレータ関数は関数を返します。これは、同等の記述として説明されている"f = D(f, ...)"を読めば分かります。問題は、デコレータ関数に与える引数と、デコレート対象の関数に与える引数の扱いに関してです。

デコレータ関数自身は、デコレータ関数とデコレート対象の関数とが結びつけられる際に１度だけ実行されるようです。さらに、デコレータ関数自身が実行される際の引数は、デコレート構文による記述の際に渡された引数になります。上記のコードでは"1, 2, 3 => *deco_args"となります。

また、上記のコードでは、デコレータ関数が呼び出されると、内部で２つの関数を作成し、最終的にその関数を返しています。外側の関数directorは、デコレート対象の関数が実行された際に、暗黙的に渡される(と思っています)デコレート対象の関数を受け取ります。directorの中で作成しているwrapper関数が、デコレート対象の関数の実体となります。wrapper関数はデコレート対象の関数が実行された時に渡された引数を受け取る必要がありますが、これは何もしないと受け取る事が出来ないようです(受け取り方が分かりません)。そこで、"func_name"という、関数の名前を表す変数をデコレート対象の関数から受け継ぎます。こうする事で、デコレート対象の関数の実体が、wrapper関数になり、実行時に渡された引数も受け取る事が出来るようになりました。

というところまではなんとか(勝手ながらも)解釈できましたが、どうでしょうか。そもそも、『デコレータ構文』という呼び方は正しいのでしょうか？関数修飾子？

余談ですが、IPython使い始めてみました。

右も左も分からないまま、とにかく必要になりそうなモジュール類を探り続けます。
Beautiful Soup: We called him Tortoise because he taught us.

HTMLドキュメントから情報を抽出するために、"Beautiful Soup"というモジュールを利用してみました。
KOSHIGOE学習帳 - [python]HTML関連

findAllメソッドにパラメータを渡して要素を取得する操作が基本でしょうか。パラメータには、取得したい要素名だけでなく、属性名やその値を指定出来るし、正規表現にマッチする要素といった指定も出来るようです。

Python Cheese Shop : Index of Packages Matching 'scraping'
"Python Cheese Shop"でキーワード"scraping"として検索して見つかったのdが、"Beautiful Soup"なわけですが、Scoreが2と高評価ではないようです(Scoreの見方が分かりませんが)。Pythonでのスクレイピングツールとして、一般的には何が利用されているのでしょうか？

Pythonのモジュールについて、『こういう場面ではこれを使え』といった情報が(日本語で)公開されたり交換されている場はあるのかな。

Python Cheese ShopがPerlで言うCPANっぽい気がしたので、ここで探してみました。

検索結果の中から、"toursst"が気になりつつパーサなら"universal feedparser"かなと思い、Universal Feed ParserからDLしてインストール。

easy_installで検索からインストールまで出来るのかと思いましたが、"Universal Feed Parser"は出来ない模様。Source Forgeで独自に管理してるからでしょうか。よく分かりません。そういえば、CPANシェル(?)のようなものはあるんですかね。

ひとまず、setup.pyを使ってインストールまで出来たので、ドキュメントのサンプルを見つつコードを書いてみました。
KOSHIGOE学習帳 - [python]RSS/Atom関連

Conditional GETのための設定やUAなど、色々とオプションを指定出来るようですが、それは後回し。RSS1.0/RSS2.0/Atom1.0について、適当な要素を表示してみました。

(当然ながら)インターフェースが統一されているので、対象を考えずにコードを書けます。フィードの種類やエンコーディングを類推(?)するメソッド、HTTPヘッダを取得するメソッドなども使えるようです。

データを取得する際、ディクショナリとして普通に['...']を使ってもよし、属性風にアクセスしてもよし。名前に付いても、Atom的でもいいしRSS的でもよし。

キャッシュの仕組みは別途必要になりそうですが、大体の事はこのモジュールで解決出来そうな印象です。

高機能なだけに、単体テスト(のテストケース?)を3000程書いているようです。トップページにサンプルコードがあるのも好印象ですが、テスト具合を主張するのもいいです。

さて、"Universal Feed Parser"で宜しい気がしますが、実際のところRSS/Atom関連でPythonのデファクト的なモジュールはあるのでしょうか？

はじめての Django アプリ作成，その 1以降、その 4まで。

クイックリファレンス(PDF)を眺めて、環境を整えつつ探りつつ休憩しつつと、ごにょごにょして気が済んだので、チュートリアルに挑んでみました。

凄いですね、あの管理画面。畳み込み表示とかカレンダーとか、モデルの一覧画面にフィルタやら検索やらが付けられたり。フレームワーク自体を詳しく見てはいませんが、チュートリアルで触ってみた感じでは楽しいです。開発用のウェブサーバもあるのでらくちん。

テスト環境やらデプロイ環境は別途必要なのでしょうか？それとも、Pythonにはデファクトが存在していて、Python圏の人たちはそれが当然？他言語で言うMakefileがsetup.py？

さて、Djangoを触っていた時間は楽しかったのですが、その環境を整えるまでにイライラする事がちらほらありました。Tracを入れた頃にMacPortsでPythonを入れて、最近のPython入門に伴ってMacPython(pkg)を入れて、としていたせいか、py-sqlite2を(依存解決やら何やらで)なかなかインストール出来ませんでした。

MacPortsでpy-sqlite2をインストールする際、Python2.4を要求され、依存解決としてPython24を(自動的に)インストールしてしまったわけですが、これがファイルの重複だかで失敗。なんだかんだとしばらくPythonの入れ直しをしてました。MacPortsは相変わらず使いこなせていません。。。

あと、実はDjangoを(tarball落として来てsetup.pyで)入れた後で気づいたのですが、MacPortsにもpy-django-develとしてあるんですね。

ymasuda.jpに豊富な邦訳ドキュメントがあるので、安心してDjangoを触れます。感謝。

Terminal.appからのコピペで、突然改行がコピー出来なくなる事があるのはなぜでしょう？

さっきまでは問題が無かったのに、突然一部で改行文字が無くなっていたり、全ての改行文字が無くなったりします。仕方が無いのでiTerm.appに変えてみて事なきを得ていますが、理由がよく分かりません。

標準出力によっては、改行文字でなく復帰文字が出力されているとかそういう事でしょうか？Terminal.appの設定では「改行を復帰としてペーストする」のチェックを外しているのですが。

不思議。

『第11章スレッドとプロセス』で力つきました。

ひとまずはRubyのさわりとして、構文や特徴を掴みたいとおもいながら読み進めていたので、この辺りで一区切り付けたいと思います。スレッド云々という話は、言語というよりもアーキテクチャとかの話ですよね？Rubyという言語でマルチスレッド処理を書けますよ、という事を知っていればいい気がするので、よしとします。

と、ここで気づいたのですが、第３部が言語リファレンス(よりのドキュメント)なんですね。。。本を途中から読んだり飛ばして読むのが苦手なので、頭から読んでいたのですが間違えたでしょうか。

先に『初めてのPython 第２版』を読んでいたので、「Pythonとの違いをRuby本を読みながら知りたいな」と思いつつ読もうと思ったわけですが、その欲求を満たすためにはおそらく第３部を読むべきだったのでしょう。しかし、残念ながら僕は上級者でも他言語に習熟しているわけでもありません。が、やはり目的ははっきりしていたわけなので、内容を把握した上で読み進めるべきでした。反省。

そんなわけで、目的を(そこそこ果たしつつも)果たす事無く力つきたので、ここからはPythonをもう少し触ってみたいと思います。

以前、レンダリングに耐えきれずに断念して以来、Terminal.appを利用し続けてきましたが、最新版(0.9.5)は耐えきれないほどではないようです。

xterm-256colorに対応しているようで、emacsのcolor-themeをCarbonEmacsと同じように表現してくれます。

言語設定をすれば日本語も入出力可能です(UTF-8でしか試してませんが; zsh)。コマンドラインでの日本語入力には失敗しましたが。。。

問題は、zshかscreenの設定がまずいのか、いくら設定しても起動後の桁数が80に変更されてします事です。どうしてでしょう？シネマディスプレイを活かすために(?)、画面半分から全体を使っているのですが、「80x24にすべし」という事でしょうか？

通常のアプリケーション同様に、Preferenceから設定が出来るのかと思いましたが、どうやら違うようで、[View]->[Show Session Info...]か、[Bookmarks]->[Manage Profiles...]から設定を行うようです。

桁数の問題が解決出来れば、乗り換えても問題なさそうなので、もう少し粘ってみます。

追記[1]

xterm-colorにしたら桁数は指定通りになりました(勿論256色表示はできません)。

追記[2]

xterm-256colorでもscreenを起動しないようにしたら指定通りになりました

追記[3]

どうせクリップボードの問題で(256色出来ようがなんだろうが)CarbonEmacsは使い続けるので、ギブアップ。

追記[4]

コメントをいただきまして、無事指定通りでscreenが起動出来ました。しばらく併用して様子を見ます。

『くらすめそっど』を変換すると『暮らすメソッド』。

プログラムを書く仕事でご飯を食べている中、君との付き合いもかれこれ２年以上。

そろそろ君くらいは認めてくれても宜しくないですか？

どこのプログラマやら技術者がそんなメソッドを駆使するんでしょう。

あれですか、軽いヒキコモリなオレに対するイヤミですか。そうですか。

いっそ、『暮らすメソッド』を確立してやろうかしら。

と、久しぶりにネタエントリな訳ですが、Googleの検索結果でヒットする『暮らすメソッド』もやっぱ"ことえり"なのかな？

１週間ほどかけて、ようやく読了。

新規に立ち上げたHikiにメモを取りつつ読み進めていたので、結構時間がかかりましたが、さくさく読めて楽しい１週間でした。

読書感想文には嫌な思い出しか無いので書評などはしませんが、表題通りのよい入門書かと思います。Amazonのレビューでも好評でした。

結構前に、Rubyに触れてみようとRuby本を買い込んだのですが、そちらはタイミングが悪い事もあって置き去りになっています。『初めてのPython』で書かれている点に注目して、『Rubyではどうなのか』を考えながらRuby本を読んでみたら面白いのかも(違いが分かりません)。これを機会に、Perlを改めて覚えてみるのもいいかも。

さて、Pythonで遊んでみるか、Ruby本を読むか、これからが問題です。

v0.6です。scplugin.tigris.org

メニューがToirtoiseSVNに近くなった気がします。ただ、ToirtoiseSVNでは設定メニューがありますが、SCPluginでは見当たりません。言語リソースの変更は自分でビルドする事になるのでしょうか？

さて、SCPluginのv0.6を使ってみて、SSL証明書と認証でエラーが出てしまったのでその解決策をメモしておきます。

Server certificate verification failed

リポジトリのSSL証明書が、信頼の置ける機関から発行されたものでないため、ユーザによる承認プロセスが必要です。SCPluginでは、この承認プロセスを実行出来ないようなので、最初はCLIのsvn(v1.4以上)を実行し、pで常に承認するようにしてください。

authorization failed

ユーザ認証に失敗しています。SCPluginでは、OSXのキーチェーンを利用してユーザー認証を行います。~/.subversion/configで、store-auth-credsをnoにしている場合はyesに変更する必要があります(デフォルトでコメントアウト)。初回の認証はCLIのsvn(v1.4以上)で済ませておいてください。

try&errorの結果ですのでご注意下さい

Nabble - Re: Authorization issues with SCPlugin 0.6?
上記エントリーを参考に、try&errorで問題を解決した際のメモです。細かいところで不要であったり誤りであったりするかと思います。認証情報が関係しますので、ご利用の環境によっては好ましくない方法であるかもしれません。

機能的にはまだまだでしょうか

さしあたって、ひな形が出来上がったかなという印象です。メニューはあるけど、結果が出てこない場面がちらほらと。もうしばらく、OSXではTerminalからsvnを叩く方がよさそうです。

これまで、Desktop Managerを利用していましたが、VirtueDesktopsに乗り換えてみました。

Desktop Managerではアプリケーションとデスクトップのバインティングの方法が分からず放置してましたが、VirtueDesktopsでは"アプリケーションの配置"というメニューから色々と設定出来るようです(日本語なのが嬉しい)。

アプリケーションをデスクトップにバインドさせる事で、Cmd+Tabでのスイッチ時にアプリケーションがバインドされたデスクトップに切り替わるようになります。

Desktop Managerよりもデスクトップの切り替えが重いように感じられますが、実際はどうなのでしょうか。

試している最中に突然落ちたりもしましたが、これからの発展が楽しみなアプリケーションです。

2007/02/09修正

typo: VirtualDesktops => VirtueDesktops

思いつきで使い始めたOperaですが、１日目にしてギブアップします。

Firefox2でスマートキーワードを利用してdel.icio.usへのポストを行っているのですが、これをOperaのキーボード設定を利用して行う方法が分かりません。

キーボード設定でキーとアクションを設定すれば良いという事は分かるのですが、開いているページのタイトルをどう渡せばいいのかが分かりません。"Go to page"を使うと新規タブでjavascriptが実行されてしまい、document.titleではタイトルが取得出来ません。

ページを２回開けばいいのでしょうか？ブックマークしたいページを開いて、開いた後にdel.icio.usへのポストを実行する。。。違う気がします。

会社のWindowsマシンにインストールして、メイリオフォントまで入れて体制を整えつつあったのですが、残念です。

これまで通り、Firefoxの２枚看板(v1.5とv2.0)で頑張ります。

λ式でプログラムを表現出来る→式で(数学的に)プログラムを表現出来る、という事ですか？

プログラム(コンピュータによる計算)は『チューリングマシン』と『λ計算』という処理系(?)でシミュレート(?)する事が出来る。チューリングマシンでは、手続き。λ計算ではλ式。

プログラムを数学的に解決する場合、その思考や表現がよりダイレクトに表現出来るのがλ計算という事でしょうか。一方で、プログラムを命令書として解決するなら、手続きで考えると素直に書けるという事ですかね。

Common Lispなどの関数型言語について学ぶ事で、手続き型言語で解決する際の『幅』が広がるだろうと期待して本を購入したのですが、いまいちよく分かりません。

『プログラムは計算なのだから、数学思考を表現するに適した(λ計算; λ式という)モデルを利用したらいいよ。』という単純な事ではないですよね？

自身のこれまでのプログラミングを振り返ると、ユーザーの手続き(行動)を元に設計や実装を行って来たように思います。『手続き』という言葉に触れて安直にこのような振り返りをした気もしますが、まあ、そんな感じです。

結局、『何がなんだかさっぱり』『なんだかモヤモヤする』まま読み終わってしまいました。本の批評ではありません。今の自分では、１回読んだだけでは期待していた『関数型(言語)から得る恩恵が何か知りたい』という欲求を満たす事が出来ないのだと思います。

経験が足りないのか、思考が足りないのか。愚直に『これっぽい！』ものに手を出していきます。

IDからアイコン画像を生成して、ブログコメントの名前脇を飾るアイデア(勿論、ブログでの利用に限らず)。

• Don Park's Daily Habit - Visual Security: 9-block IP Identification
• Radium Software(紹介記事)

元記事のコメントに、Identiconを取得出来るAPIらしきURIが掲載されていたので、試してみました。

http://www.docuverse.com/blog/9block?code={32-bit integer}&size={16...64}
Don Park's Daily Habit - Visual Security: 9-block IP Identification

画像生成情報として、32bit整数とピクセルサイズ16-64を指定出来るようです。

32bit整数をどのようにして画像にしているかは、以下のページで解説されています。また、JAVAのソースも配布されているようです。
Don Park's Daily Habit - Identicon: Updated and Source Released

はじめ、"32-bit"を"32-digits(桁はdigitsでしたかね？)"と勘違いして真っ黒な画像が表示されましたが、適当なIPを32bit整数にして画像を生成したらカラフルなアイコンが手に入りました。

記事を読んでもよく理解出来ていないのですが、おそらく、頭14bitで模様、残り18bitで色を生成しているのだと思います。14bitx18bitの数だけユニークなアイコンを作る事が出来る、と考えていいのでしょうか？

コメント欄での利用方法を見ていませんが、MTプラグインなどで簡単に使えるようになれば楽しそうです(挨拶程度でもコメントを残してアイコンを見てみたくなりそうです)。