tonextone.com/type/

店舗情報の版管理 (skype find の場合)

2008-11-29T04:11:54Z

The Art of SQL「10 章戦力の結集」「11章計略」から読み取ったこと。

2008-10-05T07:16:50Z

スキーマのモデリング技法のうち重要なものは、以下の 2 つ。

第3正規形(3NF)

汎用的な(最適化されていない、中立的な)スキーマ。
マスター/ディテールもこっち。

スタースキーマ

データ・ウェアハウス用スキーマ。
分類のキーとなる「ディメンジョン」表。
各種「ディメンジョン」の組み合わせに対応する集計可能な値「メジャー」だけを含む「ファクト」表。
メタ設計よりも、サブタイプを使おう。
まだ、ピンと来ないので、引き続き、調べ中。

参考URL:: スキーマのモデリング化技法; データウェアハウス関連用語　解説

The Art of SQL「4 章策略」から読み取ったこと。

2008-09-15T14:20:34Z

効果的なフィルターとして働くカラムを見つける。
なるべく早い段階で、そのフィルターを適用する。

例1: 結合する前にフィルター

結合する前にフィルタリングできるならば、そうしたほうが速いに決まっている。

旧来の結合構文でも、同様。

例2: IN か EXISTS か？

サブクエリの内側のフィルターが効果的な場合は IN (非相関サブクエリ)
サブクエリの外側のフィルターが効果的な場合は EXISTS (相関サブクエリ)
ただし、相関サブクエリの結合キーには、インデックスを張るべし。

Re: Emacs の moccur-grep-find で特定のファイルを無視したい

2008-07-17T15:38:01Z

ずっと dmoccur を使ってたんだけど、

( moccur-grep(-find)は、) find-file でファイルを開くことをしないので，dmoccur よりもはやく検索できますし，バッファが氾濫することもありません．

だそうで試してみることにしました。

で、まずは .svn/* とかを検索対象から省いてから速さを比較しようと思ったんだけれど、この「省き方」の情報が無い。

そんな中、 id:higepon さんが moccur を愛用しているようだったので質問させていただいたところ、
elisp を書いていただきました。ありがとうございました!!!

で、結論を言うと、
どうやら、 moccur-grep(-find) でも、 dmoccur の設定(dmoccur-exclusion-mask)を、利用してくれるようです。
color-moccur.el を読めないなりに読んでみると、どうもそのようです。

現在、以下のような設定で、試用中です。

もともと dmoccur の設定があったせい(おかげ)で、
id:higepon さんから教えていただいた設定を追加しても(しなくても)状況が変化せず、ちょっと混乱してしまいましたが、
id:higepon さんの elisp も、期待どおりの動作をしています。

まだ、試用を開始したばかりなので、もしかしたら、この結論も正しくないかもしれません。
間違いなどあれば、ご指摘いただければ幸いです。

セマンティックウェブ設計 5 原則

2008-04-29T08:34:16Z

「セマンティック・ウェブのためのRDF/OWL入門」より抜粋。

すべてのものが URI で識別可能: ネットワーク上のリソースばかりでなく、人間、場所、事象も URI を通してウェブ上で識別されます。 URI という分散型の識別メカニズムを用いることで、誰もがセマンティック・ウェブに参加し、様々な情報を効率的に統合し、意味を明瞭に示すことが可能になります。
部分的な情報 Partial Information: セマンティック・ウェブは完全な情報を前提とした閉じた世界を扱う学問ではなく、部分的な情報しか知りえない実世界を対象にし、そこから有益な結論を引き出すことを目指しています。情報は、いつ誰がどこで記述してもよく、同じリソースに関する矛盾する情報が存在するかも知れません。「すべてを知っている人はいない」のです。誰もがどんなことについて何でもいえる（Anyone can say anything about anything）というキャッチフレーズは、セマンティック・ウェブが自由で拘束がなく、小さな情報を断片的に発信できるということと同時に、不完全な情報を前提とし、それを生かすことの重要性を示しています。
発展性 Evolution: 分散型のウェブでは、さまざまなコミュニティや個人が、独自に情報を発信したり、知識の体系を整えたりします。同じ分野の情報が、異なる方法で記述されることもあるでしょう。これらの情報を統合したり、新しい知識を加える時に、古いものを犠牲にしなくてもうまく融合できること、別々のコミュニティどうしが同一性や矛盾をきちんとチェックできることは、このような分散型の世界が自立的に発展していくために欠かせない要件です。
最小のデザイン Mimimalist Design: セマンティック・ウェブでは、できるだけ制約を課さない、必要以上の標準化を求めない、シンプルなものはシンプルなままに、複雑なものは実現できるように解きほぐして（モジュール化して）、という方針で仕様を設計します。こうすることで、個別仕様の実装が容易になり、またそれに基づいた応用を柔軟に考える事が可能になります。
信頼のウェブ Web of Trust: ウェブにはいろいろな情報があり、そのコンテクストや信頼度はさまざまです。自分が良く知っているところからだけ情報を集めれば安心ですが、それではグローバルなセマンティック・ウェブの力を生かせません。セマンティック・ウェブでは、存在する情報すべてが信頼できると保証するのではなく、アプリケーションがコンテクストから信頼度を評価するために必要な仕組みを考えていきます。

↓この辺の動向も要チェック。
MQL SPAQL

情報に関する考察。その2。

2008-03-10T15:18:54Z

ここ 10 年間ほど、シるという過程に対する私のイメージには、いつも Post-it が登場する。

それは、私の大学時代の学習法に関係がある。

最初は、自分が理解した(と思えた)事柄を紙のノートに書いていた。
新しい事柄が次々に登場するたびに、それらの相互関係を、ノートに反映させていく。
その当時は紙に筆記することに慣れていたので、しばらくはこの方法でやっていた。
しかし、そのうち書き直しが面倒になってきた。

次に、いわゆるルーズリーフを採用した。
前後関係を入れ替えたり、書き直したものに入れ替えたり、というのをページ単位でできるようになった。
しかし、それでも書き直しがあることに変わりなく、不満があった。

ここで、飛躍があり、
「できるだけ書かないようにしよう」と思った。
書かなければ、書き直す必要がない。

まず、良い教科書や、自分の思考に近い文書を見つけ、
その中の要点に、なるべく大きな付箋を貼る。
そして、必要であれば、そこに自分の理解の足跡を残していく。
何章の何節の何処とか何頁の何行目とか、ポインタを記入しておけば、
相互の関係も記述しやすい。
しかし、今度は教科書が膨れ上がっていった。付箋の厚みで。

最終的には、
付箋を貼っていた場所には、ID 番号だけを鉛筆で書いておいて、
その付箋自体は、ルーズリーフにバインドした無地の紙に貼ることにした。
ルーズリーフの返り咲きである。
教科書とルーズリーフとは 1 対 1 にして、章立てなども対応させる。

…と、前置きが長くなったが、
自分自身、相変わらず、上記と同じことをしているなぁ、と思うことが最近あった。

それは、プログラムのコーディング中。

私は、いずれ書き捨てのコードであるという前提で書き始める。

信用できる教科書の、あの部分とこの部分とを補完するストーリーを、
付箋に書くような気持ちで書き始める。

だらだらと手続き志向で書くのでメソッドが長くなるが、それで良いと思っている。

# 付箋と、メソッドとが対応しているイメージ？

理解が進んだら、付箋を張り替えるように、リファクタリングする。

よほど理解が進んだら、教科書の改定にコミットしたくなるかもしれない。

でも、どちらかというと、
教科書を参照しながら、具体的な状況のストーリーを記述するほうが
性に合っているんだろうな。

多分、理解する過程っていうのは、すごく個人差があって、
だから、チームのコードをキレイに保つのが難しいのだと思う。

関連: オブジェクト指向に対する抵抗感

和訳してみた

2008-01-03T11:52:23Z

"Higher-Order JavaScript" by Sean M. Burke を和訳した。 "Higher-Order JavaScript"(ja)

"Higher-Order" という表現に何か高尚なものを感じ、 JavaScript のすごいことが書いてあると期待し del.icio.us したものの、それっきりになっていたので。

最初に斜め読みした段階で、実は、期待していたものではなく、 Perl の人が「JavaScript で Perl を書く」ためのものであることがわかったのだが、
trivial なことでも良いので、何か吸収できるだろうと信じて、区切りの良いところまで訳してしまうことにした。
以下、その過程で脳裏をよぎった物事:

x.func = function() { return this; } ならば、
x.func() の this は x 。
x.func.apply(y) の this は y 。
Function#apply(object, [arg, ..]) は、 prototype.js でいうと、Function#bind(object, arg, ...)
Prototype API Documentation を読もう。要所でソースコードも。
Perl のリストという概念とか、 $arrayref = \@arrayref; $hashref = \%hashref とか、やっぱり変態的。
lisp のリストは俺的にしっくりくるか？ emacs lisp で hello world してみるか。

Google Maps API を SSL で使えるようにしてみる。

2007-10-01T16:12:31Z

2008/03 : /maps?file=api を書き換えるための正規表現のパターンを微調整しました。

2008/05/15 : 通りすがりさんの報告を受けて、正規表現のパターンをさらに微調整しました。

2008/07/25 : また API に変更があったようで、機能しなくなったので、正規表現のパターンを緩めに調整しました。

Google Maps API は HTTPS では提供されていないらしい。
(Google Analytics には HTTPS 版もある。というのは先日知りました。)

しかし、HTTPS なページに、HTTP なリソースを読み込むと IE 曰く、
「このページにはセキュリティで保護されている項目と保護されていない項目が含まれています」と。

この問題を何とかしなければならない機会があったので、
HTTPS な proxy をかまして何とかしてみた。

要するに、Ｇoogle Maps API を使うためには、普通

http://maps.google.com/maps?file=api&v=2&key=...

っていう JavaScript を読み込むけれども、
まずこの JavaScript を https://(自前の proxy )経由でリクエストし、
この JavaScript にハードコードされている http://... を
https://(自前の proxy )経由でリクエストするように書き換えれば良いだけ。
以下は PHP での例。

デモ: https://ssl.tonextone.com/neta/gmap_over_ssl/

# SSL の証明書を買っていないので、その旨の警告は出ます。

./rewrite_gmaps_api.php

require_once 'HTTP/Request.php';

if ($_SERVER["HTTPS"] == 'on') {
  $url_base = 'https://ssl.tonextone.com/neta/gmap_over_ssl/';
} else {
  $url_base = 'http://tonextone.com/neta/gmap_over_ssl/';
}

$url = 'http://maps.google.com/maps';
$url .= ($_SERVER["PATH_INFO"]) ? $_SERVER["PATH_INFO"] : '';
$url .= ($_SERVER["QUERY_STRING"]) ? '?'.$_SERVER["QUERY_STRING"] : '';

$proxy =& new HTTP_Request($url);
$proxy->setMethod(HTTP_REQUEST_METHOD_GET);
$status['proxy'] =& $proxy->sendRequest();

if (PEAR::isError($status['proxy'])) { $response = ''; }
else {
  $response = $proxy->getResponseBody();
  $response_header = $proxy->getResponseHeader();
}

$pattern = array(
                 '<"(http://[^/\.]+\.google\.com)">',
                 // '<"(http://[^/\.]+\.google\.com/intl/en_ALL/mapfiles/[0-9a-z]+/maps2)" *\+ *"(\.api/main\.js)">',
                 '<"(http://[^/\.]+\.google\.com/intl/en_ALL/mapfiles/)>',
                 '<"(http://(kh|mt)[0-9]+\.google)>',
                 );
$replacement = array(
                     '"'.$url_base.'proxy.php/\\1"',
                     // '"'.$url_base.'proxy.php/\\1\\2"',
                     '"'.$url_base.'proxy.php/\\1',
                     '"'.$url_base.'proxy.php/\\1',
                     );

$response = preg_replace($pattern, $replacement, $response);

header("Content-Type: {$response_header['content-type']}");
// header("Content-Length: {$response_header['content-length']}");
echo $response;

./proxy.php

UserPrivateGroup の使いどころ

2007-09-22T16:15:31Z

unix 系のサーバにアカウントを作成する際に、
$ id someone ; uid=1001(someone) gid=1001(someone) groups=1001(someone),500(project),10(wheel)
というように 'someone' のプライマリグループとして 'someone' を設定する事がある。
このようなポリシー、またはこのような 'someone' グループを User Private Group というらしい。

なんか意味無くグループ増えるだけじゃん…と思って、ここ最近では避けるようにしていたんだけど、
本日ようやく使いどころがわかった。

プロジェクトチームでファイルを共有する場合、

同じグループ 'project' に 'someone1', 'someone2' が参加している状態にして、
共有したいファイルの所有グループを 'project' にし、
グループ読み書き権限を付与しておく

…というのは良くあるケースだと思う。
2,3 を実現するためには、それぞれ、 setGID, umask(002) を使ったりする。

このようなケースで、
User Private Group ポリシーを採用していない場合、つまり
$ id someone1 ; uid=1001(someone1) gid=500(project) groups=500(project),10(wheel) $ id someone2 ; uid=1002(someone2) gid=500(project) groups=500(project),10(wheel)
のような場合、共有したくないファイルを作成するのが難しい。
普通にファイルを作成するだけで someone1:project の所有物となり、
umask(002) の効果で、自動的に project グループで共有されてしまう。

一方、User Private Group ポリシーを採用していれば、
普通にファイルを作成した場合は、 someone1:someone1 の所有物となり誰とも共有されず、
project グループで共有されるのは setGID されたディレクトリ内だけになる。

この違いが、重要な場合もあるだろう。
例えば、共有レンタルサーバの管理とかする場合は必須だろうと思う。

# umask のほうをディレクトリ毎に設定するのも一案だが、その方法は、まだ知らない。

オブジェクト指向に対する抵抗感

2007-09-14T15:20:20Z

ある問題を解決するために必要な工程は、突き詰めていけば、数パターンしかないと思う。

どうも、私は「その工程を突き詰めることによって本質を明らかにする」過程を楽しんでいるらしく、
その工程を必要以上に抽象化することを、むしろ避ける場合がある。
自明な工程が上から下に流れているように感じられるコードを好む。

その理由を考えてみた。

まず、
プログラムにオブジェクトを登場させて工程のあちらこちらの具体性を隠蔽する事に、
プロジェクトのメンバーが増えるとワークフローの見通しが悪くなりがちである事と同様のリスクを感じる。

また、
抽象化、模式化には、創作的自由度があり、十人十色の結果になると思っている。
「この色は自分の見ている色と違う」と感じさせたら、それは多少なりとも障壁になると思う。
なので自分の解釈を込め過ぎることにもリスクを感じる。

他にもあるかもしれないが、
とりあえず、上記 2 点に共通しているのは、
頻繁にコミュニケーションして同意を得て、
その同意事項を維持・徹底していく必要がある、という事だろうか？

しかし、
プロジェクトのメンバーが自分一人だけなら難なくクリアできそうに感じる…
…という事は要するに、メンバー間の調整がおっくうだなぁ、というだけか？

オブジェクト指向に対する抵抗感の心理的背景を自己分析できた気がするので、
今日は寝ます。

XMLHttpRequest で JSONP .

2007-08-22T16:42:29Z

ふと RJS の仕組みが気になり、
http://jp.rubyist.net/magazine/?0014-RubyOnRails を読みつつ、
適当な動作サンプルを探してみたけど、なかなか見つからないので、
「きっとこうなんじゃないか？」という推測を書いてみるメモ。

リクエストは XMLHttpRequest

Rails なんだから prototype.js の Ajax 使ってるはず。
レスポンスは HTML(＜script＞...＜/script＞)

Ajax.Updater で＜script＞...＜/script＞を描いてるはず。
＜script＞ /* prototype, scriptaculous で(ﾟДﾟ )ｳﾏｰ */ ＜/script＞

返って来た＜script＞の内容は、
動的なデータ(JSON)を、
prototype.js / scriptaculous.js の便利機能で処理するように記述されているばず。
この＜script＞の内容を書くヘルパーが、RJS !

つまり、XMLHttpRequest で JSONP するようなもの。という推測。

これなら、↓こんなおバカな特許問題も華麗にすり抜けられる。
http://ajaxian.com/archives/remote-scripting-transport-patent

Apollo 雑感

2007-03-22T15:29:16Z

Adobe Labs - Apollo 面白そうなので、HTML + JavaScript + CSS なウィジェットを作ってみた。

まずは普通に、HTML + JavaScript + CSS で、
GoogleBase のデータを JSONP で展開して入力を補完するっていう単純なものを作った。
http://tonextone.com/neta/GDataCompletions/

で、これをウィジェットにする。
全く変更なしで、さくっとウィジェット化できた！
http://tonextone.com/neta/GDataCompletions/GDataCompletions.air

↑この .air ファイルの実体は zip 書庫で、
展開すると、HTML, JavaScript, CSS がそっくり入っている。
確か Konfabulator(現 Y! widget) も、こういう設計だったと思う。
(今は違うみたいですね)

端的に言えば、Apollo は、
これまでもいろいろあった Flash 系、HTML 系ウィジェット実行環境を統合する、
Yet Another なウィジェット実行環境、という印象。

scripture

2006-12-29T13:00:00Z

絵本を手軽に作りたいなぁと思い、作ってみた。

できたものは「お話」(イラストレーションと文章の混ざったもの)
を、そこそこ簡単に作れるシステム。
このシステムを、scripture (スクリプチャー)と呼んでおく。
FireFox と IE6以上で期待通りに動作した。
Opera, Safari では使えない(FCKeditor が動作しないので)。

子供や大人に「お話」を聞かせる時に使えるかもしれない。

「お話」サンプル:
http://scripture.tonextone.com/?generation=greeting2007

使い方:

「お話を作る」でゴニョゴニョする
「お話」が完成
「このお話を読む」で閲覧用の URL へ移動
「お話」のページの HTML ソースを保存

使い捨てのシステム。
ネットにつながっていれば、保存した HTML ソースだけで動作するし、
つながってない状況で使いたかったら、HTML ソース読んで、
js とか css とか画像とか、必要な部品をダウンロードして、調整すればいい。
ちょっとガンバればできる。

とりあえず、COOKIE でセッション貼っているので、
自分が作った「お話」(1つだけ)を、後から編集することは、
辛うじて、できるようにしてあるが、
認証などつけていない。
セッションが切れたら編集できない。これはひどい。

情報に関する考察。その1。

2006-12-18T08:00:00Z

年上の知人との会話の中で、
「中国には日本とは比べ物にならない混沌があり、ちょうど高度成長期の日本を彷彿とさせる。
　大変な脅威だ。」
という旨があった。
「混沌を秩序に変える」という人の業が求められている。
つまり、混沌がモチベーション。必要は発明の母。
その混沌(～モチベーション)が、図らずも数の力で維持されていくのではなかろうか、
と、感じた。(旨い肴で日本酒を酌み交わしながら。いつもご馳走様です。)

般若心経に、

色不異空、空不異色、色即是空、空即是色。
受・想・行・識、亦復如是。

とある。
私はこれを以下のような図式で理解している。

物事は放っておくと秩序から混沌へと向かう。それが神仏の所業。
物事の仕組みをシって、これを逆行させる。それが人の所業。
あるいは、人は、混沌から秩序へと逆行させる事によって、
物事の仕組みをシるとも言える。

そして、この色即是空構造が、すなわち、人の世界、あるいは生命界である。
その世界は、万物が流転する事で成り立っている。
自分の一生のうちに関われる周期の(小乗な)サイクルと、
それより大きい周期の(大乗な)サイクルがある。

さて、前置きはこのくらいにして。
この色即是空構造を、特定のシステムに導入すれば、そこに一つの「世界」が出来ると思う。

例えば、インターネットのリソースを、
ディレクトリ(カテゴリ)に分類し、
キーワードで検索できるようにする
というシステムがある。

「書籍」という形態における語彙になぞらえると、
カテゴリ = 目次
キーワード = 索引
かなぁと思う。誰かの視点で完成された秩序である。

このシステムに色即是空構造を導入する試みが、
ソーシャルタギング(～フォークソノミー)だと認識している。
つまり、不特定大多数のユーザによって、神仏の業を擬似的に再現し、
混沌(～モチベーション)を導入するものであると。
ただし、当然、破綻しないように設計する必要があるわけで。

色即是空構造の模式図を念頭に、
実社会にある、様々な世界の設計を眺めながら、
こんなふうに回るようにするには、どんな実装があり得るのかと、
考えてみようと、改めて思う。来年のテーマかな。

Panoramic Panel Perspective

2006-12-11T06:42:34Z

私は怠惰なので、作業する時でも何でも、手の届く範囲に全てそろえておきたい。
コックピットが理想。

今、座っているデスクの前と左には、本棚が接している。
前の本棚には、よく使う書類のフォルダが、4種類に分類されていて、
左の本棚には、よく使うリファレンス系の書籍がある。
(各本棚のデスクトップより下の領域は、普段使わないモノが収納されている。)

そのデスクに、ノートPC を置いて、処理しなければならない書類を意識しながら作業し、
ちょっと「首を捻る」ようなことがあったら、首を「左に」捻って、リファレンスを手に取る。

こういうユーザーインターフェイスが体になじむ場面は、多いと思う。

でも、ウェブアプリケーションの場合、
扱っている対象に関連性のある、良く使うツールですら画面に収まりきらないことも多い。
特に web2.0 なマッシュアップなさービスでは、
アレコレ関連性を表現しつつ、それらをその場で編集する、みたいな、
優れた一覧性が重要な気がする。

それならば…と、ちょっと考えてみた。
Panoramic Panel Perspective
要するに横スクロールなんですが、ちゃんと分類した上であれば、積極的に使うのもアリなのではないかと思う。