順序付き関係の圏 - 檜山正幸のキマイラ飼育記 (はてなBlog)
型の計算をしているうちに、“順序付き関係の圏”とでも呼ぶべきものに出会いました。Ordered Relations でORelと書くことにします。集合の圏Set、順序集合の圏Ord、関係の圏Relと、圏ORelのあいだには次のような関係があります。 Set -- Gr --> Rel | | Disc Disc | | v v Ord - OGr --> ORel 矢印はいずれも関手です。Grはグラフ化、OGrは順序付きのグラフ化（グラフの順序的閉包を取る）、縦方向の矢印は集合に離散順序を入れる関手です。2本の縦矢印は違う関手を表しますが、似ているので同じ名前Discをラベルにしています。これらの圏と関手について説明します。プロ関手との関係とかにも触れますが、とても急ぎ足です。 内容： 関係の圏の素早い復習 順序集合の圏の素早い復習 反対順序と直積 上方閉集合と下方閉集合 順序付き関係の圏
1円クラウド・ホスティングDigitalOceanを、Vagrantから使ってみる - 檜山正幸のキマイラ飼育記 (はてなBlog)
SSDなVPSを提供するDigitalOcean（https://www.digitalocean.com/）については、徳丸さんの記事に分かりやすく紹介されています。徳丸さん記事のタイトル「1時間1円から使える」から、「1円クラウド・ホスティング」と名づけてみたのですが、これはウソではありません。現状の僕の利用明細は次のとおりです。 0.01ドル単位で課金されて、合計で0.05ドルです。 このDigitalOceanを、去年くらいから話題となっている仮想環境マネージャVagrantから使ってみました。これ、便利ですよ。 内容： DigitalOceanに申し込んでドロップレット（仮想マシン）を作る Vagrantを使った操作の準備：DigitalOcean側 Vagrantを使った操作の準備：ローカルマシン側 プロビジョニング その他こまごま DigitalOceanに申し込んでドロップ
カン拡張（Kan extensions）とカン持ち上げ（Kan lifts） - 檜山正幸のキマイラ飼育記 (はてなBlog)
n-Category Cafeにデイビッド・コーフィールド（David Corfield）が、"Kan Lifts"（カン持ち上げ）という記事を書いています。 http://golem.ph.utexas.edu/category/2009/06/kan_lifts.html 冒頭の雰囲気だけテケトーに訳すと： ぼくは、数学における組織化の原理について、ずっと考えている。それで思い出すんだけど； スチーンロッドがどっかで（どこだっけ？）、代数的位相幾何学の分野を、拡張と持ち上げ（extensions and lifts）の概念を使って、すごく分かりやすく見事にスケッチしていた。一方、マックレーンは次のように言ってるよね： カン拡張（Kan extension）の概念は、圏論における基本的な概念をすべて含んでいる。 スチーンロッドとマックレーンの言葉を考え合わせると、カン持ち上げ（Kan l
えっ、僕のエントリーが関係してた？ んじゃ … - 檜山正幸のキマイラ飼育記 (はてなBlog)
hirataraさんのエントリー「"圏論とかモナドなんて簡単だからscalaを使って説明してみた"を検証してみた」は読んでました。そこから辿って、もとのエントリー「圏論とかモナドなんて簡単だからscalaを使って説明してみた」もザッと目は通しました。で、特別に何かを言いたくなるような感じはしませんでしたね。 hirataraさんは、過度に批判的にならないように注意深く書いていて： 先ほど「圏とは言い難い」という表現をしたのだけど、これは「関数1つからなる圏も考えられる」という事実を考慮してのことだ。 mapとflatMapが分かれば実用上問題がないというのはその通りで、それ以上圏や関手、モナドについて踏み込んで厳密に理解する必要はないと言える。「圏論とかモナドなんて不要だからscalaにおける要点だけ説明してみた」ってことあれば全く同意である 僕も、scalaのmapとflatMapに対す
関手的データモデル入門 2：統一的に制約を書く方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
夢のような話も楽しいけど、今日は地道に行きましょう。様々なスキーマ制約を、単純な発想だけを使って、すべて一様に扱う方法を紹介します。 それにしても、「入門 2」なんて番号付けていいんでしょうかね？ 「衝撃的なデータベース理論・関手的データモデル 入門」を「入門 1」とみなすつもりですが、「入門 3」「入門 4」があるかどうか不安。 内容： データたちのいるところ 集合と部分写像 従業員と事業所の例 主キーと外部キー 従属性（冗長性） ビジネスルール スキーマにおける制約記述法のまとめ データたちのいるところ 関手的データモデルは、データベース理論を極限まで単純化します。基本概念は、テーブル、カラム、制約の3つだけです。この3つだけであらゆることを記述しようとします。背後に、対象、射、可換図式だけであらゆることを記述する圏論があるので大丈夫、ってことです。 そうはいっても現実は複雑です。複雑
衝撃的なデータベース理論・関手的データモデル 入門 - 檜山正幸のキマイラ飼育記 (はてなBlog)
デイヴィッド・スピヴァックによる衝撃的なデータベース理論である関手的データモデル。どうしたらうまく説明できるか？ と色々と悩んでしまいますが、まー、書けるところから書き始めてしまいましょう。 さー、いらっしゃい、いらっしゃい。関手的データモデルの世界へようこそ。圏論の言葉は出てきますが、圏論の予備知識はほぼゼロでOKですよ。 [追記 date="翌日"]取り急ぎ勢いで書きましたので、不注意と早とちりが混じっていました。追記と取り消し線の形で訂正と注記を足しました。字句レベルの表現の変更は直接編集しています。 あとそれと、圏論の基本用語を知りたいときはコチラ、… って、……、ゴメン！[/追記] 内容： はじめに 本の購入のサンプル スキーマのグラフ表現 キーとか計算カラムとか 圏としてのスキーマ 関手としてのデータベース状態 テーブルの変化 自然変換としてのデータ操作 データベースに圏論が使
デイヴィッド・スピヴァックはデータベース界の革命児か -- 関手的データモデル - 檜山正幸のキマイラ飼育記 (はてなBlog)
最近、「おおおー、これは凄い、すんばらしい！」と思ったことがあるので、それについて書きます。 最初に言葉についてのお断り； "categorical"の訳語をどうしようか？ と。片仮名で「カテゴリカル」が無難ですが、漢字で書きたい。「圏論的」が落ち着きがいいようですが、必ずしも「論」の意味を含まないときもあります。そこで、以下、「圏的」を使います。 [追記 date="2013-02-12"]入門的解説を書きました。→「衝撃的なデータベース理論・関手的データモデル 入門」[/追記] スピヴァックと関手的データモデル デイヴィッド・スピヴァック（David I. Spivak, http://math.mit.edu/~dspivak/）は、MITの研究者です。 彼は圏的情報学（categorical informatics）を提唱しています*1。圏的情報学の中心的な概念が関手的データモデル
インターネットはテレビに負けた - 檜山正幸のキマイラ飼育記 (はてなBlog)
Twitterがいつの間にか変わっていた 「Twitterも昔は良かった」か。 僕は、昔も今もTwitterをほとんど使わないので、良かったもナニもないのですが、インターネット全体に関して「昔は良かった」感を抱くことはたまにあります。今のインターネットって、ようするにテレビですよね。「インターネットも昔は良かった」という思いは、僕の場合「昔のインターネットはテレビじゃなかったのに」ということです。 インターネットが普及したらテレビは駆逐されるだろう、みたいなことが言われたこともありましたが、そんなことはなかったみたいです。テレビを視聴する時間が減った、その原因のひとつがインターネットの普及ということは実際あるかもしれません。しかし、「インターネットがテレビを駆逐する」には別の意味が込められていた気がします。テレビとは違った媒体としてのインターネットが勝つ、というような。 でも、今のインター
JavaScriptの関数には、やたらに何でも突っ込める - 檜山正幸のキマイラ飼育記 (はてなBlog)
jQueryのドル記号「$」は、理不尽なくらいに大活躍します。あまりにも何でもできるので、「ありゃ何なんだ？」と思いますよね。$(...) という形で呼び出せるので、関数なのは確かです。JavaScriptでは、ひとつの関数名に対して呆れるくらいにオーバーロード（多義的定義）ができます。 内容： コンストラクタあるいはクラスとしての関数 メソッドとしての関数 名前空間あるいはモジュールとしての関数 関数／オブジェクトとしての関数 試してみる コンストラクタあるいはクラスとしての関数 関数は、オブジェクトのコンストラクタとして使用できます。 function Point(x_, y_) { this.x = x_ || 0; this.y = y_ || 0; } お尻にアンダースコアが付いた引数名 x_, y_ は省略可能のつもりです。new Point()、new Point(2)、ne
bitbucketはもう信用する気になれない - 檜山正幸のキマイラ飼育記 (はてなBlog)
bitbucketは、分散バージョン管理システムのリポジトリと関連機能をホスティングしているサービス。Catyの開発にはずっとbitbucketを使ってきた。細かい不満はあるものの、「これはダメだ」というほどの問題点は感じていなかった。だが、最近の変更は酷い。それについては、既にKuwataさんが書いている。 http://return0.info/note/2012-10.html#id2012-10-10 http://return0.info/note/2012-10.html#id2012-10-19 Wikiの記法が、WikiCreoleからMarkdownに変わったのだが、互換性への配慮が一切されてない。ユーザーが今まで貯めこんできたデータが壊れる事態もヤムナシという判断らしいが、ヒド過ぎる。具体的に言うと、過去にWikiCreole記法で書いた（イシュートラッカーの）イシュー
冗長な操作 - 檜山正幸のキマイラ飼育記 (はてなBlog)
インクリメンタルサーチとか入力補完機能ってホントに便利ですね。例えば、ある文脈で先頭が "hiy" に一致する語が "hiyama" しかないなら、"hiy" だけ見て "hiyama" と確定してしまっていいですよね。さらなるユーザー入力を要求するのは道理にあいません、だって候補が1つしかないのですから。 ボタンを押すとメニューが現れ、そのメニューからどれかの項目を選ぶUIがあったとしましょう。メニュー項目がただ1つならどうでしょうか。それだったら、ボタンだけで十分で、メニューを出すのは冗長で不愉快なUIになるだけです。 さて、地上と地下1階を行き来するエレベーターに乗ったんですよ。ドアを閉めるボタンを押しても動かないのです。行き先の階を押さないとダメなんです。選択肢は1つしかないんですけど。これって、冗長で不愉快なUIです。 おそらく、一般的なNを想定して設計されていると、N=2 の特
何も分からないままに望月新一氏のInter-universal理論について語ってみる - 檜山正幸のキマイラ飼育記 (はてなBlog)
とある界隈では、京大数理解析研究所の望月新一教授とABC予想で大騒ぎですね。一般のマスコミも、9月18日くらいから報道をしているようです。ABC予想を解いたとされる論文自体は8月30日から公開されていたそうです。一時、アクセスが困難でしたが、今はサクッとレスポンスが戻ります -- サーバー機能を増強したんでしょうか。 Title: Inter-universal Teichmuller Theory IV: Log-volume Computations and Set-theoretic Foundations URL: http://www.kurims.kyoto-u.ac.jp/~motizuki/Inter-universal%20Teichmuller%20Theory%20IV.pdf タイトルに「IV」とあるように、これはシリーズの4番目の論文で、全体では500ページくらい
分散バージョン管理システムは誤解されやすいイノベーション（ジョエルも言っている） - 檜山正幸のキマイラ飼育記 (はてなBlog)
2009年6月12日に、僕は分散バージョン管理システムMercurialについて短い記事を書いて、そこで次のような言ってます。 実は僕は、分散バージョン管理という発想と仕掛けを最初はまったく理解できず、「エエーッ？なんだそれ」「そんなんでうまくいくのかよ？」とかグダグダ言っていたのですが、いったん使い始めればラクチンラクチン。 要するに、最初は誤解に基づき否定的だったってことね。僕と同じような誤解をする人がいるような気はしたのですが、あまりうまく解説できそうにないので*1： 「四の五の言ってないで、使ってミソ」ってことです。 最近になって、ジョエル・スポルスキ（Joel Spolsky / 青木靖 訳）の「分散バージョン管理で間違いないって、ベイビー」という記事を目にしました。2010年3月17日に書かれた記事です。 なんと、あのジョエル・スポルスキも最初は誤解に基づき否定的だったらしいで
なにかが抜けている -- Webと関わる人間はどこにいる？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
winplusさんが、色々と有意義な考察をなさっています。 http://d.hatena.ne.jp/winplus/20120716/1342407196 ： 「アプリケーション状態エンジンとしてのハイパーメディア」というのは、アプリケーション状態はすべてリソース(≠<リソース>)として存在しているため、リンクをつうじてリソース間を移動することがそのままアプリケーション状態の遷移となる、ということだと理解しています。 ここで、「リソース」と「<リソース>」が区別されていますが、「リソース」に関しては、次の説明で十分だと思います。 リソースにはぜんぶURLをつける。つまりURLでリソースを識別できるようにする。 このような解釈に対して疑問に思うことがあります。この疑問が解決すれば、「<リソース>」から「リソース」に乗り換えてもいいと思っています。 [追記]「人間はどこにいる？」という見出
ハイパーリンク設計をサーバーサイド設計に従属させるべきではない - 檜山正幸のキマイラ飼育記 (はてなBlog)
[追記] この記事内で、既存の用語の意味をズラシたり拡大解釈して記述したところがあります。「既存の解釈に強く拘らない」というのがひとつの（僕が推奨する）方策ですが、「もう少し、ハイパーメディア・アプリケーションについて」も一緒に読んでくださるのがヨイかと。 [/追記] 昨日の記事「ハイパーリンクは何を繋ぐのか」の続きです。今日も落書きみたいな絵で説明します。昨日使った絵も再掲（流用）します。 僕にとっては、ハイパーリンクがリソース間のリンクだというモデルは受け入れがたいものです（それが昨日の記事の主張）。サーバーは利用者の相手はできません。利用者に機能性や利便性を提供する窓口はWebクライアントです。利用者（それが人間だとして*1）は、画面を見て、アンカーをクリックして次の画面に移り ……、とナビゲートされます。このとき、URLの綴りや発行したHTTPメソッドを意識しているでしょうか？ 「
ハイパーリンクは何を繋ぐのか - 檜山正幸のキマイラ飼育記 (はてなBlog)
[追記] この記事内で、既存の用語の意味をズラシたり拡大解釈して記述したところがあります。「既存の解釈に強く拘らない」というのがひとつの（僕が推奨する）方策ですが、「もう少し、ハイパーメディア・アプリケーションについて」も一緒に読んでくださるのがヨイかと。 [/追記] 『RESTful Webサービス』という本はよく参照しましたし、このブログ内でも何度か言及・引用しています。 RESTful Webサービス 作者:Leonard Richardson,Sam Rubyオライリー・ジャパンAmazon この本はたいへん勉強になりました。しかし、多少の違和感が残る、なんか不足を感じる点もあります。この本の著者達、リチャードソン＆ルビーと僕のあいだで、どこかに認識やメンタルモデルの食い違いがあるみたいです。それは（仮にあったとしても）微妙な点なので、なかなか明文化はしにくいものです。 最近また『
いかにして合意と伝達の負担を減らすか： URLを例として - 檜山正幸のキマイラ飼育記 (はてなBlog)
昨日「URLに関する議論 -- なぜ僕はクエリパラメータを擁護、ときに推奨するのか」という記事を書きました。そこで出した簡単な事例は、足し算を要求するのに、/calc/add/2/3 みたいなURLを使うのはやめて /calc/add?x=2&y=3 とか /calc/?op=add&arg1=2&arg2=3 にしようぜ、というものです。 実際には、URLのパス部分が既に存在する実体を指すことを強要すると、PUTメソッドでファイルを作りたいときはどうすんだ？ といった問題もあります。が、個別の問題を議論する前に、クエリーパラメータや拡張子を擁護する背景をもうちょい説明します。 内容： 合意と伝達は大変 XMLを使ってエンコードする方法 URLにエンコードする方法 とにかく手間を減らすには 名前やパスに情報を含ませること まとめ 合意と伝達は大変 僕は「合意と伝達」の問題に強い関心を持って
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%把握したいのです。 列挙する
ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕は、ソフトウェアシステムの構造や処理の流れを絵で描くのが大好きです。 つうと、「UML図か」とか思われそうですが、UML図には気力が湧きません。 理由1：ナントカ図、カントカ図といっぱいありすぎる。 理由2：オブジェクト指向設計の影響が強すぎる。 UMLから派生したSysMLだと、図の種類も少ないし、オブジェクト指向風味も薄まっているようです。それでも僕には面倒な感じです。「フローチャートをめぐる迷信と妄言と愚昧」にも書きましたが、箱と矢印だけくらいの、少数の要素からなる絵がいいのです。 内容： ロバストネス図 手書きにサイコー バウンダリーとインターフェイス まとめ ロバストネス図 絵にするのは好きだがモノグサである僕にピッタリだと思えるのがロバストネス図です。ロバストネス図の要素は3つしかありません。ユースケース図の要素を入れても5つです。「ロバストネス図の概要」（http://ww
フローチャートをめぐる迷信と妄言と愚昧 - 檜山正幸のキマイラ飼育記 (はてなBlog)
2011年12月20日の記事で： [フローチャートについて書くのは] 僕にとっては定期ポストみたいなものです。年に一,二度はこのことを言っておきたい、みたいな。 と書きました。それから半年たってないのですが、なんかまたフローチャート・ネタをやりたくなりましたね。 そう思い立ったのは； 「フローチャートを復権させよう -- 2020年代のプログラミングへ」のブックマークに、羽生章洋(id:habuakihiro)さんが次のコメントを残しておりまして、 昔フローチャートについて講演したりポジティブなことを書いたりしたら偉い叩かれたなあ。似たケースにJavaScriptの記事書いたときも叩かれてその後gmail+ajaxブームが来たら一転したり。みんな原理原則より流行が好き。 いまさらながら当時の情報を探して読んでみたのですよ。2006年夏、羽生さんの講演について大森敏行記者が書いた記事が残って
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
