JavaScriptで説明するオーバーロード解決 - 檜山正幸のキマイラ飼育記 (はてなBlog)
型クラスの話をしました。 入門的ではない型クラスの話：Haskellの型クラスがぁ (´^｀;) オーバーロードは何故にかくも難しいのか：Haskellの成功と失敗 Haskellの型クラスに関わるワークアラウンド Haskellの型クラスは元祖・型クラス*1なんですが、なんか残念な仕様です。整合性が歪んでいる理由は、オーバーロード機能を優先しているからです。その分、構造としての型を記述する機能は犠牲になっています。トレードオフだから仕方ないけど。 ところで、オーバーロードの解決（多義性の解決）って、どうやるんでしょうか？ そのメカニズムをJavaScriptのサンプルコードを使って説明します。 なお、「多相とオーバーロードはどう違うか」とかの話は、どうでもいい割に議論すると消耗してバカバカしいので一切触れません。（ちなみに、「並列と並行の違い」なんて議論も時間の無駄。暇つぶし以上の意味は
衝撃的なデータベース理論・関手的データモデル 入門 - 檜山正幸のキマイラ飼育記 (はてなBlog)
デイヴィッド・スピヴァックによる衝撃的なデータベース理論である関手的データモデル。どうしたらうまく説明できるか？ と色々と悩んでしまいますが、まー、書けるところから書き始めてしまいましょう。 さー、いらっしゃい、いらっしゃい。関手的データモデルの世界へようこそ。圏論の言葉は出てきますが、圏論の予備知識はほぼゼロでOKですよ。 [追記 date="翌日"]取り急ぎ勢いで書きましたので、不注意と早とちりが混じっていました。追記と取り消し線の形で訂正と注記を足しました。字句レベルの表現の変更は直接編集しています。 あとそれと、圏論の基本用語を知りたいときはコチラ、… って、……、ゴメン！[/追記] 内容： はじめに 本の購入のサンプル スキーマのグラフ表現 キーとか計算カラムとか 圏としてのスキーマ 関手としてのデータベース状態 テーブルの変化 自然変換としてのデータ操作 データベースに圏論が使
デイヴィッド・スピヴァックはデータベース界の革命児か -- 関手的データモデル - 檜山正幸のキマイラ飼育記 (はてなBlog)
最近、「おおおー、これは凄い、すんばらしい！」と思ったことがあるので、それについて書きます。 最初に言葉についてのお断り； "categorical"の訳語をどうしようか？ と。片仮名で「カテゴリカル」が無難ですが、漢字で書きたい。「圏論的」が落ち着きがいいようですが、必ずしも「論」の意味を含まないときもあります。そこで、以下、「圏的」を使います。 [追記 date="2013-02-12"]入門的解説を書きました。→「衝撃的なデータベース理論・関手的データモデル 入門」[/追記] スピヴァックと関手的データモデル デイヴィッド・スピヴァック（David I. Spivak, http://math.mit.edu/~dspivak/）は、MITの研究者です。 彼は圏的情報学（categorical informatics）を提唱しています*1。圏的情報学の中心的な概念が関手的データモデル
URLに関する議論 -- なぜ僕はクエリパラメータを擁護、ときに推奨するのか - 檜山正幸のキマイラ飼育記 (はてなBlog)
一時期（2010年の1月頃）、URLの議論をしていて、僕は拡張子を含むURLやクエリパラメータを擁護していました。 そろそろ決着、HTTPメソッド、URL、そして標準化された動詞 RESTfulなWebサイトと拡張子を含むURLについて 最近、またURLの問題を考えてみたのですが、僕が拘っているのは次の2点なのだと気付きました。 すべてのURLを列挙したい。 すべてのURLを分類したい。 すべてのURLを列挙したい あるWebサイトやWebアプリケーション（以下、総称してWebシステム）を考えたとき、有効なURLを完全に列挙したいのです。ここでの「URL」は、正確に言えばクエリパラメータを含まないパス部分のことです。もちろん、有効なURLは時々刻々と変化します。でも、ある一時点を取れば、その時点におけるURLは確定するはずです。各時点ごとのURLの集合を100%把握したいのです。 列挙する
そろそろ決着、HTTPメソッド、URL、そして標準化された動詞 - 檜山正幸のキマイラ飼育記 (はてなBlog)
（[追記 date="翌日"]文言を少し改善し、注意を付け足したりしました。[/追記]） HTTPメソッド、URL、動詞（verb）に関して次の記事を書きました。 HTTPメソッドの正統的使い方と現実的対処法 HTTPメソッド、URL、そして標準化された動詞 訂正補足：HTTPメソッド、URL、そして標準化された動詞 問題点がほぼ明らかになり、全体の状況も見えてきたので、総括したいと思います。これで決定版にしたいのですが、実のところ、まだ考えが変わる可能性は否定できません。現時点では、以下に記述する案が最善だと思っていますがね。 内容： 用語の注意 事の発端，事の成り行き URLの意味と用途を分類する リソース種別ごとに動詞を考える さらにリソース種別ごとに動詞を考える GETに乗せるか、POSTに乗せるか インターフェースとしてのリソース種別と動詞 リソースとクラス 用語の注意 HTTP
フローチャートをめぐる迷信と妄言と愚昧 - 檜山正幸のキマイラ飼育記 (はてなBlog)
2011年12月20日の記事で： [フローチャートについて書くのは] 僕にとっては定期ポストみたいなものです。年に一,二度はこのことを言っておきたい、みたいな。 と書きました。それから半年たってないのですが、なんかまたフローチャート・ネタをやりたくなりましたね。 そう思い立ったのは； 「フローチャートを復権させよう -- 2020年代のプログラミングへ」のブックマークに、羽生章洋(id:habuakihiro)さんが次のコメントを残しておりまして、 昔フローチャートについて講演したりポジティブなことを書いたりしたら偉い叩かれたなあ。似たケースにJavaScriptの記事書いたときも叩かれてその後gmail+ajaxブームが来たら一転したり。みんな原理原則より流行が好き。 いまさらながら当時の情報を探して読んでみたのですよ。2006年夏、羽生さんの講演について大森敏行記者が書いた記事が残って
node.js： モジュールの使い方 - 檜山正幸のキマイラ飼育記 (はてなBlog)
LinuxとWindowsにnode.jsをインストールしてみたので、少し使ってみました。 JavaScriptにおいて、機能が欠けていて困る事って何でしょう。クラスがないとかはさしたる問題じゃないと思うのですが、モジュール機構がないのはホントに辛いです。node.jsには、待望のモジュール機構が導入されています。どうやら、CommonJS（http://www.commonjs.org/）という仕様に従っているようですが、僕は仕様を読んだわけではなくて、実際のnode.jsを触って見当を付けただけです。それを以下に書きます。 環境は、Windows＋MinGW/MSYS です。 $ echo $HOME /c/Users/hiyama/Work $ which node /c/Users/hiyama/Work/bin/node.exe $ node --version v0.5.0-p
nginx(エンジンエックス)をWindows上で動かして、SSLとリバースプロキシーの実験をした - 檜山正幸のキマイラ飼育記 (はてなBlog)
我々のWebフレームワークCatyでは、Pythonで実装したサーバーによりWebサイト／Webアプリケーションを動かしています。このCatyサーバーは、次のような点で十分とは言えません。 仮想ホストの実現 HTTPS（SSL）通信 キャッシュによるWebアクセラレーション 詳細かつ柔軟なロギング 複数プロセスを使ったパフォーマンス向上 とはいえ、Webサーバーとしての機能を充実させることはCatyの目的ではないので、不足な部分は既存のサーバーソフトウェアの力を借りることにします。Apache + (mod_python or mod_wsgi)、lighttpd + FastCGI といったところが候補でしょうが、結局、nginx（エンジンエックス）を使うことにしました。現状のCatyサーバー（caty-server.py）には特に手を加えないで、nginxを手前に置くという構成です。
JSONの可能性がグンと拡がるぞ！ JSONスキーマ - 檜山正幸のキマイラ飼育記 (はてなBlog)
JSON（http://www.json.org/）データはけっこうよく使うので、何度か話題にしたことがあります（例えば「もう一度、ちゃんとJSON入門」）。でも、JSONには型情報／メタ情報が付けられないのがとても不満で、JSON改なんてもんを考えたこともありました。（後でXIONに改名） JSONデータに対するスキーマ定義の仕様がかたまりつつあることを、ごく最近になって知りました。 http://json-schema.org/ JSON本体はRFC 4627になっていますが、JSONスキーマの標準化のステータスは、あまりハッキリとは分かりません（僕には）。http://groups.google.com/group/json-schema?pli=1 を覗き見した感じでは、現状ワーキングドラフトという位置付けらしいです。 なかなか面白いし役に立ちそうなので紹介します。ただし、僕にとっ
イベントモデルの概念と用語法が混乱しているので、イライライするんですが - 檜山正幸のキマイラ飼育記 (はてなBlog)
[追記 dateTime="2007-12-07 夕刻"]あーっ、今ごろ気付いた。イライライって「イ」がひとつ多いや。タイトルを編集すると、なんか悪いことが起こったりしませんかね？ うーん、いいや。typoしたままにしとこう。ちなみに、「イライライ」は回文になっているぞ。[/追記][追記 date = "2007-12-11"]http://d.hatena.ne.jp/keyword/%a5%a4%a5%e9%a5%a4%a5%e9%a5%a4 [/追記] いつか文句言ってやろうと思っていた件ですよ。長いぞ。 内容： 似てるけど少しずつ違うイベントモデル達 イベントターゲット イベントフロー EventTargetインターフェース イベントハンドラーとイベントリスナー リスナーとハンドラーについてもう少し イベント伝搬とハンドラー実行 イベントの通過または出現 イベントタイプ 「イベント
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
