私自身、いまだにtransitionalを主流にしているのであまり深くは考えてきていなかったのだが、先日、知人から「どうすれば最もシンプルに解決できるのか?」という質問を受けた。

Javascriptを使って新規ウインドウで開くのは手法として当然のことだが、ここで「シンプルに…」と言われて、catswhocode.comの8 awesome JQuery tips and tricksという記事を思い出し、ちょっと手を加えてみた。

手筈は極めて簡単で、anchorタグにrel属性で特定の名前を与えておいて、jQueryを使ってその名前を持つものだけ新規ウインドウで開くというやり方（一応これがデモページ）。jQueryをロードした後、以下のスクリプトを実行させるだけで済む。

<script type=”text/javascript”>// <![CDATA[
  $(document).ready(function(){
  //-----------
    $("a[rel^='extlink']“).click(function(){
      this.target = “_blank”;
    });
  //———–
  });
// ]]></script>

ソースにあるとおり、ここではanchorタグのrel属性にextlinkで始まる値を持つものだけを対象にしている。

至ってシンプル。もちろんW3CのMarkup Validationもキチンと通る。デモページではcssにも細工を持たせ、外部リンクを明示的に示すアイコンも表示できるようにしてあるので、興味があれば参照してほしい。

• MAMP
• DBI
• DBD-SQLite
• MT

MAMPはイメージをマウントして、アプリケーションフォルダへドラッグでインストール完了。インストール後にMAMP.appをダブルクリックすればサーバが自動起動し、ブラウザの新規ウインドウが開いてテストページが表示される。ポートは8888番。動作を確認後に終了。

DBIはtarボールを展開後そのディレクトリへ下りて「perl Makefile.PL」でmakeファイルを構成。構成後、「make」そしてその後「make test」。test.pl doneとメッセージが出て問題なくテストが完了したら「sudo make install」でインストール。当然管理者パスワードは必要。

DBD-SQLite-1.25もDBIと同様の手順。

続いてMT4のインストール。展開したディレクトリ名をmt4に変え、MAMPのディレクトリ直下のcgi-binディレクトリへ移動（/Application/MAMP/cgi-bin/mt4/）。そのmt4ディレクトリ内にあるmt-staticディレクトリを、MAMPのディレクトリ直下のhtdocsディレクトリへ移動（mt-static）。

これらを移動した後、MAMPを起動し、ウィザードを使ってMT4を構成（http://localhost:8888/cgi-bin/mt4/mt-wizard.cgi）。Static web pathは「http://localhost:8888/mt-static」に、Static file pathは「/Applications/MAMP/htdocs/mt-static」に設定。

DBの設定画面ではパスを「/Applications/MAMP/db/sqlite/mt.db」に設定。

以上で完了。デフォルトのブログ名のまま構成していればhttp://localhost:8888/my_first_blog/でページを確認できる。後は煮るなり、焼くなり。

P.S.
久しくMTを触っていなかったのだが、取り立てて戸惑うところはなかった。個人的な意見を述べさせてもらえば、こうやってローカルへインストールする方がかえって面倒に思える。公開を前提しているサーバであればすでにインストール済みであろうものが一切、もしくは中途半端に入っている分だけ手間だ。今どきのレンタルサーバなら月額500円程で御膳立ての整った環境をほぼ即座に借りられるのだから、そちらの利用をおすすめしたい。

「テンプレートやテーマの開発にどうしてもローカルで…」というニーズであれば理解できなくもないが、安易に入れてもHDDの肥やしを増やしてしまうだけだと思う。

当時、自分にとってのPowerBookは、Vista後を考えた上でメイン環境をOS Xへ移行することを見据えたウオーミングアップ期間であり、配付システムでアップデートを続けても特に気にならないくらいにディスクの空き容量は潤沢にあった。環境がおかしくなってもすべてクリーン・インストールしなおせば良いというお気楽な考えもあたまの中にあった。

しかし、いま使っているMacBook Proはメインマシン。使いもしないソースをわざわざローカルに置いておきたいはずもない。だから今回、PostgreSQLをインストールする際にもMac Portsを使おうといういう考えははなからなかった。クリアにしておきたかったポイントは以下のとおり：

1. 最新のソースからのインストール
2. 「postgres」ユーザを利用せず、現在自分が利用しているユーザでPostgreSQLを動かす
3. 上記も踏まえdsclコマンドでの操作も行わない

上述のポイントはオーバーラップする部分がある。バイナリで配付されているPostgreSQLでは「postgres」ユーザが作成されてしまう。またユーザが作成されてしまうのでdsclコマンドでユーザ環境の初期操作も必要になる。しかもユーザが増えると、起動時にGUIログインでの画面が現れるという悪循環が生まれる。

そもそも今回PostgreSQLをローカルへ放り込むことになった理由はデータベースで遊ぶためではなく、Djangoでの開発を行うためなので、このような渾沌がメインマシンに持ち込まれることは精神的にもよくない。

これらの理由も踏まえて、いろいろと調べることから始めた。この3年ばかりは翻訳仕事がメインになっていたこともあり、正直いって状況把握をかなり怠っていたからだ。

まずは把握すべくは初期の共有メモリの値。これへの対応はPostgreSQL 8.2.13 Documentationの16.4. Managing Kernel ResourcesとAndre Lewis氏のブログエントリを参考にした。

In OS X 10.3.9 and later, instead of editing /etc/rc you may create a file named /etc/sysctl.conf, containing variable assignments such as

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024
This method is better than editing /etc/rc because your changes will be preserved across system updates. Note that all five shared-memory parameters must be set in /etc/sysctl.conf, else the values will be ignored.

Beware that recent releases of OS X ignore attempts to set SHMMAX to a value that isn’t an exact multiple of 4096.

SHMALL is measured in 4 kB pages on this platform.

実際に割当てた値は以下のとおり：

% cat /etc/sysctl.conf
kern.sysv.shmmax=167772160
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=65536

sysctl.confを作成した後、マシンを再起動し割当てを有効にして、PostgreSQLをインストール。インストールの方法はなんら悩むようなものではなく、ダウンロードしてきたソースを展開後、素直に./configure、make 、make installの順番で進めていくだけだ。

「postgres」ユーザの問題はPostgreSQLインストール後のdata/ディレクトリの所有権を自分に変更することで対応している。

# chown -R egg /usr/local/pgsql/data

環境変数に実行パスとaliasを追加（私はtcshを使っているので、必要に合わせて読み替ええてほしい）。

% cat ./.cshrc
set path=($path /usr/local/bin /opt/local/bin /opt/local/sbin ~/bin /usr/local/pgsql/bin)
…中略…
alias pgrun ‘/usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l /usr/local/pgsql/data/logfile start’
alias pgstop ‘/usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data stop’

サーバ機ではないので、起動時にPostgreSQLが立ち上がる必要はないためaliasを使ってパラメータ込みで任意に起動／停止できるようにしてある。

続いてデータベースのイニシャライズ。

% initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user “****”.
This user must also own the server process.

The database cluster will be initialized with locales
COLLATE: ja_JP
CTYPE: ja_JP.UTF-8
MESSAGES: ja_JP
MONETARY: ja_JP
NUMERIC: ja_JP
TIME: ja_JP
The default database encoding has accordingly been set to UTF8.
initdb: could not find suitable text search configuration for locale ja_JP.UTF-8
The default text search configuration will be set to “simple”.

fixing permissions on existing directory /usr/local/pgsql/data … ok
creating subdirectories … ok
selecting default max_connections … 100
selecting default shared_buffers/max_fsm_pages … 32MB/204800
creating configuration files … ok
creating template1 database in /usr/local/pgsql/data/base/1 … ok
initializing pg_authid … ok
initializing dependencies … ok
creating system views … ok
loading system objects’ descriptions … ok
creating conversions … ok
creating dictionaries … ok
setting privileges on built-in objects … ok
creating information schema … ok
vacuuming database template1 … ok
copying template1 to template0 … ok
copying template1 to postgres … ok

WARNING: enabling “trust” authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.

Success. You can now start the database server using:

postgres -D /usr/local/pgsql/data
or
pg_ctl -D /usr/local/pgsql/data -l logfile start

====================================================
% postmaster -D /usr/local/pgsql/data
LOG: database system was shut down at 2009-04-12 00:15:49 JST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
====================================================

% pg_ctl -D /usr/local/pgsql/data stop
waiting for server to shut down…. done
server stopped

さて、これでお膳立ては全部そろった。後はpsycopg2を放り込んで、Djangoと連携させるだけだ。

]]> http://ebisuisland.com/labmemo/?feed=rss2&p=48 0 http://ebisuisland.com/labmemo/?p=11 http://ebisuisland.com/labmemo/?p=11#comments Fri, 10 Apr 2009 13:45:21 +0000 Ethan Goodspeed http://ebisuisland.com/labmemo/?p=11 CSVやRSSなど、どこかのデータソースを上手に利用してマッシュアップをしたいと考えているなら、YQLとgetJSON()の組みあわせが、なんとも素敵すぎるくらいにシンプルに物事を解決してくれる。

XMLをそのまま力技でparseしても良いのだろうけど。しかし実際には必要ないデータをクライアント側へ送って帯域を無駄にしてしまうのはやはりエレガントではない。どこかでJSONに畳み込んで非同期でクライアント側へ投げるのが、最低限の今どきのお作法なのだろうと思う。ならば自らのサーバサイドでLLを使ってXMLからJSONへポロリと吐き出そう、と、短絡的に考えてしまうのも悪くないが、なんだか3年前に戻ったようなDéjà vuを覚えなくもないし、せっかくだからもうひとひねりしてみたいと思うのが人情というものだろう。

すこし前に、IBMのdeveloperWorks JapanにJSONP、jQuery、Yahoo! Query Language を使ってREST クエリを使ってマッシュアップを作成すると言うエントリが掲載されていた。それを思い出し、参考にしてYQL（Yahoo! Query Language）を使ってJSONP(JSON with Padding)を生成し、クロスドメインなgetJSON()で遊んでみた。

このブログのトップページの中間カラムにある「Top news@sfgate.com」の内容は、ページがロードされた時点での最新のsfgate.comのトップニュース内容のRSSをYQL側で取り込み、ヘッドラインと記事へのURLという必要な情報だけをもったJSONPへ畳み込んでjQueryのgetJSON()で読み込んでエレメントの追加したもの。

コードは以下のとおり：

var yqlUrl4="http://query.yahooapis.com/v1/public/yql?q=select%20title%2C%20link%20from%20rss%20where%20url%3D%22http%3A%2F%2Fwww.sfgate.com%2Frss%2Ffeeds%2Fnews.xml%22&format=json&callback=?";

jQuery.getJSON(yqlUrl4, function(data){
jQuery.each(data.query.results.item, function(index, item){
$("＜a href='" + item.link + "' target=\"_blank\"/＞")
.html(item.title) .appendTo($('#sfgate'))
.wrap('＜li/＞');
});
});


コード中にもあるように、getJSONで得た値を各々「sfgate」という識別子を持つエレメント（ここではul）に追加している。文字列へのタグの修飾（ここではliとa）も見てのとおり。YQLが生成するRESTクエリはけっして美しいとは言えないが、YQLの書きやすさと柔軟さを考えれば、差し引きしてもじゅうぶんにおつりがくる。このRESTクエリの生成に必要なYQLは以下のとおり。

select title, link from rss where url=”http://www.sfgate.com/rss/feeds/news.xml”

YQLとgetJSON()の組みあわせれは、マッシュアップのアイデアを形にするために必要な時間を大幅に短縮できる。ちょと素敵すぎるくらいに自分好みだ。

P.S.
ちなみにjQueryのドキュメントの例にあるとおり、Flickrのようにデータフォーマット変換用APIオプションが用意されている場合はYQLを通す必要はない。便利になった反面、このあたりのチェックを怠ると「気が利いて、間が抜けてる」状態に陥りかねない。

]]> http://ebisuisland.com/labmemo/?feed=rss2&p=11 0