tonextone.com/type/

]]> http://tonextone.com/type/2008/11/29-1311.html http://tonextone.com/type/2008/11/29-1311.html おもうやりくりする Sat, 29 Nov 2008 13:11:54 +0900 セマンティックウェブ設計 5 原則セマンティック・ウェブのためのRDF/OWL入門」より抜粋。

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

↓この辺の動向も要チェック。
MQL SPAQL]]> http://tonextone.com/type/2008/04/29-1734.html http://tonextone.com/type/2008/04/29-1734.html おもう architecture social userinterface Tue, 29 Apr 2008 17:34:16 +0900 情報に関する考察。その2。
それは、私の大学時代の学習法に関係がある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連: オブジェクト指向に対する抵抗感]]> http://tonextone.com/type/2008/03/11-0018.html http://tonextone.com/type/2008/03/11-0018.html おもう architecture Tue, 11 Mar 2008 00:18:54 +0900 オブジェクト指向に対する抵抗感
どうも、私は「その工程を突き詰めることによって本質を明らかにする」過程を楽しんでいるらしく、
その工程を必要以上に抽象化することを、むしろ避ける場合がある。
自明な工程が上から下に流れているように感じられるコードを好む。

その理由を考えてみた。

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

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

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

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

オブジェクト指向に対する抵抗感の心理的背景を自己分析できた気がするので、
今日は寝ます。]]> http://tonextone.com/type/2007/09/15-0020.html http://tonextone.com/type/2007/09/15-0020.html おもう Sat, 15 Sep 2007 00:20:20 +0900 XMLHttpRequest で JSONP . 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]]> http://tonextone.com/type/2007/08/23-0142.html http://tonextone.com/type/2007/08/23-0142.html おもう ajax javascript Thu, 23 Aug 2007 01:42:29 +0900 情報に関する考察。その1。「中国には日本とは比べ物にならない混沌があり、ちょうど高度成長期の日本を彷彿とさせる。
　大変な脅威だ。」
という旨があった。
「混沌を秩序に変える」という人の業が求められている。
つまり、混沌がモチベーション。必要は発明の母。
その混沌(～モチベーション)が、図らずも数の力で維持されていくのではなかろうか、
と、感じた。(旨い肴で日本酒を酌み交わしながら。いつもご馳走様です。)

般若心経に、

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

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

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

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

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

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

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

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

色即是空構造の模式図を念頭に、
実社会にある、様々な世界の設計を眺めながら、
こんなふうに回るようにするには、どんな実装があり得るのかと、
考えてみようと、改めて思う。来年のテーマかな。]]> http://tonextone.com/type/2006/12/18-1700.html http://tonextone.com/type/2006/12/18-1700.html おもう architecture Mon, 18 Dec 2006 17:00:00 +0900 Panoramic Panel Perspective コックピットが理想。

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

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

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

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

それならば…と、ちょっと考えてみた。
Panoramic Panel Perspective
要するに横スクロールなんですが、ちゃんと分類した上であれば、積極的に使うのもアリなのではないかと思う。
]]> http://tonextone.com/type/2006/12/11-1542.html http://tonextone.com/type/2006/12/11-1542.html おもうつくる Mon, 11 Dec 2006 15:42:34 +0900 MT をもう少しちゃんと使ってみる。

本文中の改行の br タグへの変換が直感に反する。
でも、そういうものとして定着してしまったのでしょう。
郷に従います。
サイドバーとかに表示させる、
汎用性のある HTML のブロックを 'module' と呼び、
その 'module' をまとめたものを 'widget' と呼ぶらしい。
'widget' 単位で管理することにした。

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

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

旧blog http://tonextone.com/note/ は、とりあえず、そのまま残します。
]]> http://tonextone.com/type/2006/08/25-0039.html http://tonextone.com/type/2006/08/25-0039.html おもう Perl movabletype Fri, 25 Aug 2006 00:39:49 +0900