tonextone.com/type/

Google Documents List Data API v3.0 を python から利用してみた。

2010-06-19T15:28:09Z

今更ながら、地味に便利なんじゃないかと思って試してみたら...

...すごい。
Google Docs と統合されたアプリを作ったり、単に HTML -> PDF などの変換に使えますね。

OpenLink iSPARQL で DBpedia をみる。

2009-04-18T07:35:50Z

http://wiki.dbpedia.org/About

DBpedia is a community effort to extract structured information from Wikipedia and to make this information available on the Web. DBpedia allows you to ask sophisticated queries against Wikipedia, and to link other data sets on the Web to Wikipedia data.

DBpedia は、みんなでがんばって、Wikipedia から構造化された情報を引き出して、それをウェブ上で使えるようにする、です。 DBpedia があれば Wikipedia に対して、洗練された問い合わせを投げられるようになります。Wikipedia のデータに、外部のデータ集合をリンクすることも。

ってことで、 DBpedia は SPARQL API を公開してくれている。
http://wiki.dbpedia.org/OnlineAccess
ここで紹介されている OpenLink の iSPARQLを使うと、SPARQL を直感的に扱える。
新しい世界が見えるかもしれない。

以下、試したこと:

1. SPARQL で問い合わせ。
Advanced タブにあるフォームから
-- カリフォルニアで設立された組織が開発したソフトウェア。 SELECT * FROM <http://dbpedia.org> WHERE { ?company a <http://dbpedia.org/ontology/Organisation> . ?product a <http://dbpedia.org/ontology/Software> . ?company <http://dbpedia.org/ontology/foundationplace> <http://dbpedia.org/resource/California> . ?product <http://dbpedia.org/ontology/developer> ?company . }
という、 SPARQL を実行してみる。

(http://wiki.dbpedia.org/Datasets の 4.3.2. Querying the Infobox Ontology にあったサンプルです。 )

2. 結果をみる。
なにやら結果リストが表示されたのでみる。

(↑クリックで拡大しないとわからないが) Adobe の製品などが並んでいる。

3. SPARQL のグラフを視覚的にみる。
問い合わせを実行した後に、QBE タブに行くと、問い合わせの叙述が視覚化されている。
Advanced のフォームに SPARQL を書いて、実行しないまま Visualize ボタンを押しても視覚化できる。
逆に、 QBE タブで、視覚的に SPARQL を組み立てて、 Generate ボタンを押すと、Advanced のフォームでの編集モードになる。

問い合わせの叙述が、2 つのトリプルから構成させているのが、よくわかる。
# トリプルというのは { (Subject) −(Predicate)→ (Object) } のこと。

4. 結果リソースの関連情報をたどってみる。
結果リストから AdobeFlash を選択し、Get Data Items をクリックすると、
なにやら別の結果が表示された。

5. SPARQL を確認する。

↑こういうグラフで問い合わせが行われている。
つまり、
(Subject="AdobeFlash") −(Predicate=?)→ (Object=?)
和集合
(Subject=?) −(Predicate=?)→ (Object="AdobeFlash")

↓SPARQL で書くとこう。

-- AdobeFlash を主体か客体にもつ叙述をくれ。 SELECT DISTINCT * FROM <http://dbpedia.org> WHERE { { <http://dbpedia.org/resource/Adobe_Flash> ?p ?o } UNION { ?s ?p <http://dbpedia.org/resource/Adobe_Flash> } }
なるほど。

Metaweb が Freebase 用に開発した MQL のほうでも、MQL Query Editorが公開されているが、
こうやってトリプルのグラフを視覚化して見せられると、SPARQL のほうが RDF / セマンティック風味が強い気がする。
いろいろ Query を投げてみよう。

ウェブサイトのイメージを共有するためのツール

2009-04-04T10:39:44Z

職場で、これから作成するウェブサイトのワイヤーフレーム + サイトマップを作りたくなって、いろいろ調べた際のメモ。

ワイヤーフレーム

pencilは、ワイヤーフレームというには、ちょっと具体的過ぎる感じ。
結局、ER図作成でお世話になっている gliffy を選択した。

gliffy は、矩形選択してコピーとか移動とかすると、
操作対象の中のレイヤーの z-index が維持されなかったりグルーピングがおかしなことになったりするけれど、
そういうクセを許容させるくらい使い勝手が良い。

また、今回の目的はイメージを共有することなので、
オンラインで共有できて、さらにコラボレーション(共同編集)できるのも良い。

サイトマップ

writemapsは、見た目キレイで良いのだが、機能が足りないので、却下。
dot -> graphviz も試したが、コラボレーションに向かないので、却下。
結局、マインドマップツールの、MINDOMOを使ってみた。
SERENA Prototype Composer も気になったが、ちょっと高機能過ぎる気がするのと、Windows アプリなのでコラボレーション的な制限を感じたので、保留。
今から触ってみます。

以上、とりあえずのメモ。

Jester is ActiveResource client lib. for Javascript.

2009-03-08T08:27:09Z

JavaScript で REST API をたたく場合、
XMLHttpRequest, IFRAMEHttpRequest, JSONScriptRequest(JSONP) などを使うわけだが、
Jesterは、これを抽象化して、xx.find(), xx.save() とかいうカッコいい API を提供してくれる。

そもそも、REST を抽象化して ActiveRecord パターン似の API でやりましょう、
という ActiveResource がRails で提唱・実装されている。
その後、この ActiveResource の実装がいくつか公開されている中で、
クライアントライブラリの JavaScript 実装として有名なのが Jester 。

prototype.js, jQuery なんかの Ajax.foobar() を使ってゴリゴリやるのが今の日本の主流だと思うが、
WebOSGoodies で ActiveResource が絶賛されていることもあり、Jester で軽く試してみた。

Firebug <=> Twitter API

とにかく手軽に試したいので、

Firebug のコンソール上で Jester を利用
既存の REST API である Twitter API を操作

というプランで。

prototype.js, jester.js をロードするだけの HTML を書く。

<html> <head> <script src="./lib/prototype-1.6.0.3.js"></script> <script src="./lib/jester.js"></script> </head> <body></body> </html>

おもむろに使ってみる。find('all' {username: 'tonextone'}, console.log);
// define Twitter model. Resource.model('Twitter', { prefix: 'http://twitter.com/statuses', format: 'json', urls: { list: '/user_timeline/:username.json', show: '/show/:id.json' } }); // then use it. Twitter.find('all', { username: 'tonextone' }, console.log );

DONE!

レスポンスの中を見てみる。

find(1274085406, console.log);
Twitter.find(1274085406, console.log);

レスポンスの中を見てみる。

サーバとのやりとりを確認。

要するに JSONP です。

簡単です。お試しあれ。

FreeBSD リモートアップデート 5.4-RELEASE => 6.4-RELEASE

2009-01-31T07:55:07Z

さくらで借りている専用サーバー(このブログも入ってる)の OS を、
リモートアップデートした。

FreeBSD 5.4-RELEASE => 6.4-RELEASE

5.4 用の ports のリポジトリが更新されなくなって来ている気がしたのが理由。

OS のアップデート自体は、ほぼ無問題で、
ただ locale の調整が必要そうなので、それを今から解消する。

ports のアップデートも、無問題。

ports で、不用意に perl をアップデートしたので、少しはまった。

locale 問題を解消したら、
一連の詳細を trac に作業記録を書いて、このエントリからリンクする予定。
# trac も locale の問題でエラーを吐いているので。

ということで、作業記録。

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

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 : Google 側のコードに変更があったようで、機能しなくなったので、正規表現のパターンを緩めに調整しました。

2009/07/19 : kobuchi さんの報告を受けて、修正しました。
Google 側のコードの変更により /maps?file=api だけではなく、そこから先で動的にロードされる JS ファイルの内部も書き換えることが必要になったので、そのように変更しました。

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';

$url = ($_SERVER["PATH_INFO"]) ? preg_replace('<^/>', '', $_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();
}

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

$pattern = array(
  '<([\'"])(http://[^\'"]*\.js[\'"?])>',
  '<(["\'])(http://)>',
);
$replacement = array(
  '\\1'.$url_base.'rewrite_gmaps_api.php/\\2',
  '\\1'.$url_base.'proxy.php/\\2',
);

$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 点に共通しているのは、
頻繁にコミュニケーションして同意を得て、
その同意事項を維持・徹底していく必要がある、という事だろうか？

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

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