僕らが大好きだったWebはなくなるのかもしれない - 檜山正幸のキマイラ飼育記 (はてなBlog)
Webはなくなるのかもな、と思います。 この記事の続きは「ブラウザが消滅して： APIベースのWeb」 あの頃のWeb 「Webとは何か」を定義しなければ、なくなるか／存続するかなんて議論は意味をなしません -- それは承知ですが、ここでは曖昧な、あるいは感傷的なWebのイメージに基いて話します。 Webはブラウザで閲覧するものでした。ブラウザはHTML文書の表示装置です。ハイパーリンクをたどってインターネットを“サーフィング”できます。あるいは、検索エンジンを利用して目的のWebサイトを探します。たまにフォームを使ってWebに“書き込み”をします。それが、今までの（「かつての」かもしれない）Web体験です。 このようなスタイルのWebの盛り上がりのピークは2005年からのWeb 2.0ブームだったと思います。Web 2.0の提唱者だったティム・オライリーの真意はどうであれ、Web 2.0
この機会にマスターしようぜ、正規表現、構文図、オートマトン - 檜山正幸のキマイラ飼育記 (はてなBlog)
正規表現と構文図について解説します。オートマトンについても詳しく述べます。オートマトン・スゴロクで遊びましょう！ 世間でよく知られている／使われている概念・方法にはこだわらず、僕（檜山）の感覚で一番わかりやすいと思われる筋書きと用語法／図式法を使って説明します。この記事に目を通して“感じ”が掴めたら、形式言語理論の教科書を読み始めることが出来るでしょう。 [追記]この記事の内容に対する具体例は、「正規表現とオートマトン：なんだ簡単じゃん、JavaScriptによる実装」にあります。[/追記] 内容： 正規表現 正規表現の例 構文図 基本記号 連接 選択 省略可能 繰り返し ストレートワイヤーによるレイアウト調整 有限状態オートマトン 有限状態オートマトンの実行 バックトラックと先読み スゴロクとオートマトン コマをたくさん使うスゴロクと並列処理 非決定性オートマトンと決定性オートマトン 正
コンピュータ系実務者のための双対性（概略） - 檜山正幸のキマイラ飼育記 (はてなBlog)
直積スタンピング関手（掛け算関手）は簡単な関手ですが、驚くほど役に立ちます。コモノイド／モノイドをスタンピングする関手は、それぞれコモナド／モナドを定義します。コモナド／モナドは互いに双対です。その実例として「参照と更新の双対性」があります。さらに具体化して、データベース操作に関して述べるなら、次のような双対性があります。 参照 更新 DBを参照する DBを更新する クエリ 更新リクエスト クエリの実行 更新のコミット クエリ結果の使い回し 更新リクエストのキューイング イミュータブルなスコープ トランザクション 更新操作がモナドを構成するのですが、ストレージ更新（書き込み）モナドとストレージ状態空間へのコミットは、線形代数（線型代数）と次の類似性を持ちます。 ストレージ更新 線形代数 更新モナド スカラー体 ストレージ ベクトル空間 更新リクエスト スカラー リクエストの連接 スカラーど
Webサービスの設計： ハイパーオブジェクトはワークフローやインターフェースも運ぶ - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Webサービスの設計： ハイパーオブジェクトとトリガー」において： 僕は「Webとはハイパーリンクなり」と考えているので、Web APIでもなんでもハイパーリンクを使ってないなら「Webっぽい」とは思いません。RPC（遠隔手続き呼び出し）的な要素を取り入れても、ハイパーリンクを活用しているならWebっぽいでしょう。「っぽい」とか「らしい」は単なる趣味嗜好の問題ではなくて、ハイパーリンクの活用は大きなメリットがあります（そのメリットの説明は今日[注：2010年8月11日]はしませんが）。 「ハイパーリンク活用の大きなメリット」について、今日（2010年8月25日）は説明します。 内容： 遠隔呼び出しとHTTP インターフェースと手順の合意 あなたに任せるわ、私は言われるまま 理想のケースは人間がクライアントのとき 状態遷移モジュール インターネット／Webの驚嘆すべき頑健性 遠隔呼び出しと
Webサービスを設計するための単純明快な方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Webサイト」、「Webアプリケーション」、「Webサービス」、「Web API」などの用語の区別はそれほど明確でもないし、きっちり区別して使うのもめんどくさいので、ここでは、これらを総称してWebサービスと呼んでしまうことにします。 山本陽平さんは、その著書『Webを支える技術』のなかで、人間がブラウザを使って利用するWebサイトとプログラム向けのWeb APIを区別すべきではないと述べています。この点は僕もまったく同感・同意です。 人間が相手となると、視覚的な効果や装飾、JavaScriptを使った操作性などにフォーカスが向けられ、Web APIとはまったく別物のような印象を与えます。しかし、各ページが持つべき情報やページ遷移の有向グラフ構造などは、相手が人間でもプログラムでも同じだと思うのです。そんな事情で、Webページの機能的／情報的なエッセンスを表現したHTML文書をクリーンH
Webサービスの設計： ハイパーオブジェクトとトリガー - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Webサービスを設計するための単純明快な方法」の続き、あるいは補足です。 内容： Web APIもWebサイトも同じ トリガーとは トリガーの構造 トリガーについてもっと ハイパーオブジェクトを返すRPC Web APIもWebサイトも同じ 僕の方針は、プログラムが利用するWeb APIであっても、次の原則で設計することです。 API体系は、人がブラウザで閲覧するためのサイトとまったく同じ構造にする。 人間用のサイトを一切作らないときでも同じ原則を適用します。転送オブジェクト（レスポンスのエンティティボディに入るデータ）の形式が(X)HTMLでないときでも同じ原則に従います。 「人間＋ブラウザ」用の転送オブジェクトの形式（フォーマット）といえば、もちろんHTMLです。HTMLの最も重要な特徴はハイパーリンクです。ハイパーリンクがWebを形作っているのです。ですから、HTML以外のフォーマ
山本陽平さんの『Webを支える技術』はWeb技術者に必携だな - 檜山正幸のキマイラ飼育記 (はてなBlog)
山本陽平（id:yohei）さんから『Webを支える技術』を送っていただきました。 Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) 作者: 山本陽平出版社/メーカー: 技術評論社発売日: 2010/04/08メディア: 単行本（ソフトカバー）購入: 143人 クリック: 4,320回この商品を含むブログ (183件) を見る これは力作です。サブタイトルである「HTTP、URI、HTML、そしてREST」について、とてもよくまとまっています。通常必要とされるWeb技術の要点は網羅されていると言っていいでしょう。 この本の内容は、ある意味では「Web技術者の常識」なんでしょうが、その常識を要領よくまとまてある書籍って全くなかったと思います。HTTPやRESTなど個々の技術に関してさえ、読みやすい書籍は意外に少ない状況。『Webを支える
Webベースの分散アプリケーション - 檜山正幸のキマイラ飼育記 (はてなBlog)
今現にポピュラーに使われているWeb技術、つまりHTTPとHTMLだけで分散アプリケーションは作れます。もっとも、「分散アプリケーション」（あるいは「分散コンピューティング」）という言葉の定義によりけりですが； ここでは、「インターネット上に散らばったデータリソースや計算リソースを協調させて何かをするアプリケーション」くらいの意味。いたって雑駁でライトウェイトな定義です。 「Webアプリケーションの入出力と状態遷移」において、Webアプリケーションの基本動作は代入文と同じだと言いました。随分とひどい単純化をしたものです。が、単純化しておけばその後の説明が楽だと思ったのです。単純化した定式化＝代入文に基づいてライトウェイトな分散アプリケーションの説明をします。 内容： リモート実行とローカル代入 長い距離を表す矢印 Catyにロングパイプを ロングパイプを隠蔽せよ Web空間上にグローバルな
Webアプリケーションの入出力と状態遷移 - 檜山正幸のキマイラ飼育記 (はてなBlog)
入力値の集合がA、出力値の集合がBである関数fを、f:A→B と書きます。ｆは純関数です。関数が状態に影響を受けるときは、f:S×A→B となります。Sは状態空間です。単に直積の記号「×」では、状態と入力の区別が付かないので、セミコロンで区切ることにします。f:S;A→B 。セミコロンの左が状態ね。fが副作用を持つとき、つまり状態空間Sに作用するときは、f:S;A→S;B と書きます。S→S は状態遷移を表すことになります。 副作用があるかもしれない関数を、次のように分類すると便利です。1は単元集合（シングルトンセット、ユニットセット）です。 f:A→B 純関数 f:S;A→B バートランド・メイヤーの言葉で「問い合わせ」 f:S;A→S;1 バートランド・メイヤーの言葉で「コマンド」 f:S;A→S;B 一度にいろいろするメソッド 以下では、単元集合1は省略します。 メイヤーは、最後の「
プログラマ／デザイナの境界としてのクリーンHTML - 檜山正幸のキマイラ飼育記 (はてなBlog)
Catyプロジェクトを始めたとき、プログラマとデザイナの「干渉が少ない分業」が大きなテーマでした。僕らが採用した基本的な方針は次のものです。 プログラマはJSONデータの生成に専念する。 デザイナは生成されたJSONデータを展開コンテキストとするテンプレートを作る。 このとき、テンプレート言語にプログラミング言語の能力を持たせてしまうと分業にならないので、テレンス・パー（Terence Par）の理論と提案に従い、戦略的低機能テンプレート言語を提供します。 この方法がマズイとはまったく思ってませんが、別な分業形態も準備した方がよいと最近思っています。「マイクロフォーマットとクリーンHTML」で説明したクリーンHTMLは、その「別な分業形態」におけるプログラマ／デザイナ境界となるものです。境界とは、2つの作業を分離するための手段であり、2つの作業のあいだで受け渡すデータのことです。 クリーン
マイクロフォーマットとクリーンHTML - 檜山正幸のキマイラ飼育記 (はてなBlog)
ここ何日かマイクロフォーマット（microformats）の話題を続けています。僕がマイクロフォーマットを思い出したキッカケは、WebAPIのデータ形式について考えていたときです。マイクロフォーマット方式でマークアップされたHTML断片をWebAPIで使えないかな？と思ったのです。 多くのWebAPIでは、特定のURLにHTTPリクエストを送ると、XMLやJSONのデータが応答として返ってきます。仮に、とあるAPIがJSON形式の人物情報を返してくるとします。独自に人物情報のデータ形式を考えるよりは、何か標準を採用すれば、考える手間も省けるし、相互運用性からも好ましいでしょう。 そこで、hCardのサブセットを使うことにします。スキーマ（型定義）を示すことはしませんが、例えば次のJSONオブジェクトは人物情報のインスタンスだと考えられます。 { "vcard" : { "fn" : "檜山
マイクロフォーマット（microformats）の蹉跌と希望 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「カジュアル過ぎるmicroformatsを少しだけ厳密に」の続きです。 マイクロフォーマット（microformats）の仕様は、自然言語と事例により記述されています*1。これは、親しみやすく読みやすく、教育的な読み物としては良い手法だと思います。が、仕様書としては問題と困難をかかえています。それを具体的に指摘したいと思います。例として、hCard仕様とhReview仕様（のごく一部）を取り上げます。 内容： プロパティの値って何？ 複数のクラス名 CSSセレクタでデータを抽出できるか それだけでは済まない こんな事していいのか？ マイクロフォーマットのアプローチはなぜ間違いなのか それでも使いたい プロパティの値って何？ マイクロフォーマットのデータでは、プロパティと呼ばれる名前・値ペア（name-value pair）が基本になります。単一のプロパティ、またはプロパティの（階層的な）
100% JavaScriptによる、簡易なDOM/SAXの実装 - 檜山正幸のキマイラ飼育記 (はてなBlog)
ああー、疲れた。いったん、ほうりなげよう。 気がむいたら手直しするけど…… って何の話かというと： これをはじめた動機 「ブラウザ上でXMLプログラミングしようぜ」って話をする予定です（一昨日のエントリーを参照）。 しかし、ブラウザ＋テキストエディタだけではさすがにシンドイ。SpiderMonky, WSH, Rhinoなどの対話的環境を併用すれば随分と楽になります。だがしかし、（少なくともRhinoでは）DOMが備わってないのですよ。 そこで、JavaScripでDOMを実装してしまえばいいと思って、やってみました。とりあえず最小限の機能ということで、MiniDOM/JS、ついでにDOMツリーをたどってSAX風イベントを発生させるMiniSAX/JS。 だけど見直す気がしないゾ まだチャントできてません。テストもしてないし、test firstじゃなくて、test after first
サーバーサイドJavaScript - 檜山正幸のキマイラ飼育記 (はてなBlog)
amachangの「IT戦記」からトラックバックをいただいていたので、「なんだろな？」と思ったら minidom.js のこと。一瞬「それなんだ？」と思ったが、僕の放置ウェアだった。 amachangの同記事に曰く： まあ、ともあれ JavaScript がサーバーサイドで動くってーのはめっちゃ楽しいですね！ サーバーサイドでJavaScriptをやりたいなら、Helmaがありますよ*1。僕がやっている某社内勉強会で取り上げたことがあって、簡単な解説が次のページにあります。 http://symple.jp/85.html http://symple.jp/100.html 上記ページから引用すると： Helmaは「多年にわたり数多くのサイトで採用された、安定したソフトウェア」だそうです。それでも日本ではいまいち普及していないらしい（Helmaの詳しい日本語ページが見つからない、 Helm
コンビネータとは - 檜山正幸のキマイラ飼育記 (はてなBlog)
明日(19日）セミナーをやるので、今日になって話す内容を考え出した（毎度コレだよ、反省はしてない）。朝食の後、見出しをいくつかノートに書き並べていたら： 長男：「コンビネータってなに？」 次男：「おにいちゃん、コンビネータ知らないの」 長男：「知らない」 次男：「映画だよね、おとうさん」 父親：「えっ、映画？」 次男：「ロボットが出てくるやつ」 父親：「はっ？？」 次男：「このあいだ、おとうさん言ってたでしょ」 父親：「あれはターミネーター」 ここからは兄弟で悪のり。 長男：「俺、コンビネータわかった」 次男：「なに、なに？」 長男：「石油の工場があるところ」 父親：「それはコンビナート」 次男：「おとうさん、あのさ、道路とか橋とか作るさ、」 父親：「コンクリートじゃない！」 長男：「じゃあさ、あのさ、」 父親：「もういいから。学校行くしたくしろよ」
Back to XML (2) - 檜山正幸のキマイラ飼育記 (はてなBlog)
過去に蓄積されたXML技術のどのあたりを檜山が面白いと感じ、再評価・再発見してみたいと望んでいるのか？ それは、また次ね。 前回、こんな文面で終わってしまったので、「それはどこ？」の話をせざるを得ないでしょうね。だから実際しますけれども、論理的な順序から言うと、その前に話しておくべきことがあるのだった。まー、いきがかりだから論理的順序は無視します。したがって、解説としては若干不親切で、幾分錯綜した感じになりそう。致し方ない。 話は前世紀まで遡＜さかのぼ＞るのだが 「過去に蓄積されたXML技術」という言葉は、なにか特定単一の仕様を意味してるわけではありません。いまだ脈ありと僕が思っているものがいくつかあるわけです。そのなかで第一の候補を挙げれば、… … XLinkです。 XLinkは、XML 1.0仕様とほぼ同じ時期から構想されているものです。XMLの初期のドラフトでは、XLink仕様がXM
Back to XML - 檜山正幸のキマイラ飼育記 (はてなBlog)
一時期、ある狭い範囲内では「XMLの檜山さん」だったわけですが、ここんところ、XMLにはご無沙汰で、事実上何もしてない。個人的な事情もあるけれど、期待したほどには XML everywhere、everything in XML という状況にはならないし、XML技術が変に矮小化されたり、トンチンカンな使い方をされたり、不毛な議論があったりと、デスパレートな気分にもなりますわな。 じゃ、XMLにまったく興味を失ったかというと、それはないです。不本意に別れた昔の彼女に未練があるくらいの感情は残っています。あわよくば復縁したい、とね。そうは思っていても、行き違いや誤解や不運とかが重なってなかなか復縁できなかった、とそんな感じでしたね。 最近になって、XMLに戻れるかな、もう一度なんらかの形でコミットしようか、と思いはじめました。その事情を話す前に、XML技術がどう使えるか、どう使うべきかを述べて
コンピュータのメカニズムをお手軽に知る方法はないものか - 檜山正幸のキマイラ飼育記 (はてなBlog)
なんか定期的に蒸し返している話題なのですが、「『プログラマの常識』ってなによ？」に書いたようなこと。つまり、コンピュータの基本的なメカニズムに関する知識の話なんですが； レジスタ、アドレス、メモリとかに関する説明があって、機械語／アセンブリ言語のさわりを紹介していて、高級言語の説明もある、と。しかも読むのが負担にならないように手短に書いてある、と。そういう参考書（自習書）を探しています。 組み込み系のプログラミング本だと、8ビットCPUとかを例に、けっこう丁寧な説明があっていいなと思うのですが、PCを使っているだけの人間だと一生触りそうにないCPUや機器が素材だと現実性に欠けるのが気になります。やっぱり、題材はインテルのCPUとPC/ATアーキテクチャでしょう。 たまたま有隣堂で、ASCIIの「Linuxのブートプロセスをみる」を見つけました。 Linuxのブートプロセスをみる (UNIX
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
関東でも新型インフルエンザ？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
