tonextone.com/type/ tag:tonextone.com,2008:/type//1 2008-12-04T08:40:53Z Movable Type 3.32-ja 店舗情報の版管理 (skypefind の場合) tag:tonextone.com,2008:/type//1.26 2008-11-29T04:11:54Z 2008-12-04T08:40:53Z ...







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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

関連: オブジェクト指向に対する抵抗感]]> オブジェクト指向に対する抵抗感 tag:tonextone.com,2007:/type//1.16 2007-09-14T15:20:20Z 2007-09-14T16:24:01Z ある問題を解決するために必要な工程は、突き詰めていけば、数パターンしかないと思う...
どうも、私は「その工程を突き詰めることによって本質を明らかにする」過程を楽しんでいるらしく、
その工程を必要以上に抽象化することを、むしろ避ける場合がある。
自明な工程が上から下に流れているように感じられるコードを好む。

その理由を考えてみた。

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

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

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

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

オブジェクト指向に対する抵抗感の心理的背景を自己分析できた気がするので、
今日は寝ます。]]> XMLHttpRequest で JSONP . tag:tonextone.com,2007:/type//1.15 2007-08-22T16:42:29Z 2007-08-22T17:17:47Z ふと RJS の仕組みが気になり、 http://jp.rubyist.net/... http://jp.rubyist.net/magazine/?0014-RubyOnRails を読みつつ、
適当な動作サンプルを探してみたけど、なかなか見つからないので、
「きっとこうなんじゃないか？」という推測を書いてみるメモ。

  1. リクエストは XMLHttpRequest
    Rails なんだから prototype.js の Ajax 使ってるはず。
  2. レスポンスは HTML(＜script＞...＜/script＞)
    Ajax.Updater で＜script＞...＜/script＞を描いてるはず。
  3. ＜script＞ /* prototype, scriptaculous で(ﾟДﾟ )ｳﾏｰ */ ＜/script＞
    返って来た ＜script＞ の内容は、
    動的なデータ(JSON)を、
    prototype.js / scriptaculous.js の便利機能で処理するように記述されているばず。
    この ＜script＞ の内容を書くヘルパーが、RJS !

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

これなら、↓こんなおバカな特許問題も華麗にすり抜けられる。
http://ajaxian.com/archives/remote-scripting-transport-patent]]> 情報に関する考察。その1。 tag:tonextone.com,2006:/type//1.12 2006-12-18T08:00:00Z 2006-12-18T11:15:27Z 年上の知人との会話の中で、 「中国には日本とは比べ物にならない混沌があり、ちょう... 「中国には日本とは比べ物にならない混沌があり、ちょうど高度成長期の日本を彷彿とさせる。
　大変な脅威だ。」
という旨があった。
「混沌を秩序に変える」という人の業が求められている。
つまり、混沌がモチベーション。必要は発明の母。
その混沌(～ モチベーション)が、図らずも数の力で維持されていくのではなかろうか、
と、感じた。(旨い肴で日本酒を酌み交わしながら。いつもご馳走様です。)

般若心経に、
色不異空、空不異色、色即是空、空即是色。
受・想・行・識、亦復如是。
とある。
私はこれを以下のような図式で理解している。

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

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

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

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

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

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

色即是空構造の模式図を念頭に、
実社会にある、様々な世界の設計を眺めながら、
こんなふうに回るようにするには、どんな実装があり得るのかと、
考えてみようと、改めて思う。来年のテーマかな。]]> Panoramic Panel Perspective tag:tonextone.com,2006:/type//1.11 2006-12-11T06:42:34Z 2006-12-11T07:20:53Z 私は怠惰なので、作業する時でも何でも、手の届く範囲に全てそろえておきたい。 コッ... コックピットが理想。
cockpit.jpg

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

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

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

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

それならば…と、ちょっと考えてみた。
Panoramic Panel Perspective
要するに横スクロールなんですが、ちゃんと分類した上であれば、積極的に使うのもアリなのではないかと思う。
]]> MT をもう少しちゃんと使ってみる。 tag:tonextone.com,2006:/type//1.9 2006-12-02T16:06:47Z 2006-12-02T23:22:46Z MT を使って何本かエントリを書いてみて: 本文中の改行の br タグへの変換が...
  1. 本文中の改行の br タグへの変換が直感に反する。
    でも、そういうものとして定着してしまったのでしょう。
    郷に従います。
  2. サイドバーとかに表示させる、
    汎用性のある HTML のブロックを 'module' と呼び、
    その 'module' をまとめたものを 'widget' と呼ぶらしい。
    'widget' 単位で管理することにした。

MT は、使い勝手よりも、カスタマイズの自由度が優先された、玄人向けの設計だと思う。
それが、結局は、受け入れられたんだろうなぁ…と、いまさら思う。

で、Vox は、そうじゃない市場向け、と。
]]> 転職活動中。 tag:tonextone.com,2006:/type//1.6 2006-10-19T10:09:53Z 2006-12-02T23:22:14Z 青森に生まれ、それなりの自然に囲まれて成長し、 以来ずっと、想像したり、モノを... 青森に生まれ、それなりの自然に囲まれて成長し、 以来ずっと、想像したり、モノを創るのが趣味。 「社会とは、人間とは何か」というテーマは、 当時の僕にとっては全体くだらないことだった (今でも面倒に感じるし、オクテだ)。 当時は、社会を知らなかったから、閉塞感すら感じなかった。 想像好きが高じて、偉大な理論物理学者になろうと思い立ち、 仙台の大学に進学し、思考力を鍛えた。思考力だけを。 当時もまだ社会を知らなかったが、知らない世界が多すぎる事には気づいていた。 そのまま仙台の大学院に進み、 自分が社会から隔絶しつつある状況を目の当たりにする。 そうかと言って、その恐怖を呑み込んでまで、 研究に邁進するほどの覚悟が自分には無い、という事に気づく。 「本当にやりたいこと」を自問自答する。 「モノを創りたい。アイディアをカタチにしたい。」 いろいろ考えて、仙台の企業の小規模な IT チームでバイトを始める。 修士課程修了、博士課程中退。 そのまま、その仙台の企業に就職し、 その後5年間、同じチームで WEB エンジニアとして受託業務をこなす。 技術は全て独学で習得したが、 チームの規模が小さかったので幅広いチャンスがあったし、 つまづいた時や、何でもない時に、メンバーから得られる 「ちょっとした何か」の積み重ねが、有り難かったと、今では思う。 この間に、--まだ人並み未満であるが-- 社会を知り、 自分の「本当にやりたいこと」を、本気で模索する覚悟を決める。 上京。結婚。 1年間は、それまでの業務を(一部)請負いながら、個人事業でやってみた。 それなりの自由があったが、 オクテな僕は、個人で続けていく手ごたえを感じられなかった。 将来の事も考えると、学ぶべき事も、まだまだ多い。 現在。30才。 共に、刺激し合い、切磋琢磨し合えるチームを探している。 というわけで、現在、人生初の転職活動中です。 ]]> movabletype に乗り換えました。 tag:tonextone.com,2006:/type//1.1 2006-08-24T15:39:49Z 2006-12-02T23:21:19Z Perl の勉強を始めるぞ!! という事で、いきなり movabletype を... という事で、いきなり movabletype をイジろうと思い、乗り換えました。

旧blog http://tonextone.com/note/ は、とりあえず、そのまま残します。
]]> 4年前くらいにちょっと書いてた時点では、
「Perlプログラミング救命病棟」でいうところのレベル 4, 5 くらいだったんだけど、
今やそれも怪しい。

まずは、配列やら、連想配列やら、それらのリファレンスやらに登場する
記号のニュアンスを思い出したい。

…だっけ?

今みると JavaScript にソックリ。JavaScript がんばっといて良かった。

やっぱり、拠り所となるドキュメントを知らないと不安だな。
調べようと思っても、どこを見たら良いのか分らず手が止まる。
結局 Google してるけど。

perldoc perldoc するしかないのか?
…険しいな。

とりあえず、これ↓を読みました。
オブジェクト指向Perlマスターコース―オブジェクト指向の概念とPerlによる実装方法
オブジェクト指向Perlマスターコース―オブジェクト指向の概念とPerlによる実装方法ダミアン コンウェイ Damian Conway 山根ドキュメンテーション

ピアソンエデュケーション 2001-02
売り上げランキング : 86406

おすすめ平均 star
starオブジェクト化するには良い本でした
starPerl5 流オブジェクト指向プログラミングのバイブル！
star真のPerl使いへ

Amazonで詳しく見る by G-Tools
]]>