言い訳から始めます。この記事を（途中まででも）読んだ人は、次のように言いたくなるでしょう。 『理論から学ぶデータベース実践入門』は良い本なのか悪い本なのか、いったいどっちなんだよ?! この本は間違いや説明不足があり、誤読されやすい表現も多く、その点では残念な本です。しかし、面白いアイディア、するどい観察も含まれていて、行間を補い深読みすれば、多くの示唆を得られる本でもあります。 よって、「良い／悪い」の二択では答えられません。良い点と悪い点の両方を、できるだけ客観的に記述するしかないのです。それをした結果、長い記事となりました。 内容： ことの発端： zhanponさんの批判 奥野本擁護と奥野本批判 僕の擁護・批判の方針 zhanponさんの指摘の再検討 1. 論理的な矛盾とデータの不整合を混同している 2. 命題論理の限界についての説明がおかしい 3. 古典論理の定義を間違えている 4.

とあるC++コードがコンパイルエラーするんですが、原因がまったく分からなかったんですよ。「そんなバカな?!」という感じ。しばらくハマってしまいましたよ。 結局、C++でもCでも同じことが起きることが分かりました。次は、僕が遭遇したのと同じ現象が起きるC言語のソースコードです。 // -*- coding: sjis -*- // strange.c struct ThreeNums { int x; // 負の数も指定可能 int y; int z; }; int total(struct ThreeNums nums) { return nums.x + nums.y + nums.z; } コンパイルすると： $ type tdm-gcc tdm-gcc is aliased to `/c/Installed/TDM-GCC-64/bin/gcc.exe' $ tdm-gcc --ve

「マイクロフォーマット（microformats）の蹉跌と希望」において、マイクロフォーマット（microformats）のデータモデルもマークアップも曖昧すぎて、どうもダメな感じだと指摘しました。しかしそれでも、次の点はマイクロフォーマットの優位点だと僕は思います： 今ある技術だけですぐさま出来る、新しいナニカを必要としない。 CSSデザインとの相性がよい。 hCard、hCalendarなどのスキーマが既に存在する。 特に最後の「スキーマのレパートリーがある」という点はとても大きな魅力です。もっとも、スキーマ記述言語がない（しいて言えば自然言語）ので、スキーマって概念も曖昧な状態ではありますが。 「マイクロフォーマット（microformats）の蹉跌と希望」のコメント欄にて、神崎正英さんより「microdataはどうか」というヒントをいただきました。Kuwataさんも「microda

TypeScriptでは、コンパイルが必要です。プログラムをブラウザーとNode.jsの両方で使おうとすると、さらに加工が必要です。ミニファイだの文書も作るだのすると、ちょっとしたビルドプロセスとなるので手作業では辛くなります。 今更Makeでもないよなー、と思い、最近のビルドツールを試してみました。 内容： 流行りすたりが激しすぎる gulpを使ってみる：こんなサンプル gulpのビルドスクリプト タスクランナーってのはビルドツールとは違うのか？ ビルドツールは進化したのか 参考資料： 例題のファイルとコマンドの一覧 ソースファイル 追加の話： gulp問題ひきずり：ウォッチがまたおバカ過ぎる 流行りすたりが激しすぎる 「確かGruntってツールがあったよな」と、インストールと使い方を調べていると、やたらにgulpって単語が目立つんですよね。Gruntのライバルの新興勢力らしいです。 「

2009年12月16日「チュートリアルを少し変更、おバカな設定例」 Catyでは、ファイル名拡張子の意味付けや扱い方がデスクトップと同じなんだけど、「クールなURIは、拡張子がねーんだぞ」とか言われそうだから、そのうちラショネールを書かなきゃ。 「ラショネール」なんて奇妙な言葉が出てきてますが、目論見や主張が正当であることを示す根拠、てな意味ですかね＞ラショネール。 僕とKuwataさんが開発しているWebフレームワークCatyは、URLに、.html, .cgi などの拡張子を必ず要求します。クエリパラメータも遠慮なしに使います。「拡張子とかクエリパラメータなんて、RESTfulじゃないなー、クールじゃないなー」とか言う人がいますが、なにゆえに「拡張子やクエリパラメータがダメなのか？」 -- その根拠を示して欲しいもんです。僕らが積極的に拡張子やクエリパラメータを使う事情と根拠は、このエ

（[追記 date="翌日"]文言を少し改善し、注意を付け足したりしました。[/追記]） HTTPメソッド、URL、動詞（verb）に関して次の記事を書きました。 HTTPメソッドの正統的使い方と現実的対処法 HTTPメソッド、URL、そして標準化された動詞 訂正補足：HTTPメソッド、URL、そして標準化された動詞 問題点がほぼ明らかになり、全体の状況も見えてきたので、総括したいと思います。これで決定版にしたいのですが、実のところ、まだ考えが変わる可能性は否定できません。現時点では、以下に記述する案が最善だと思っていますがね。 内容： 用語の注意 事の発端，事の成り行き URLの意味と用途を分類する リソース種別ごとに動詞を考える さらにリソース種別ごとに動詞を考える GETに乗せるか、POSTに乗せるか インターフェースとしてのリソース種別と動詞 リソースとクラス 用語の注意 HTTP

昨日書いた「HTTPメソッド、URL、そして標準化された動詞」、どうも詰めが甘い記事だったので、少し訂正と補足をします。以下で、HTTPクライアントとしては、現存するブラウザを想定しています。 （[追記]総括を「そろそろ決着、HTTPメソッド、URL、そして標準化された動詞」に書きました。[/追記]） 動詞としてのpost 動詞（あるいは抽象メソッド）とは、具体的なHTTP通信とは離れて、リクエストの意図・意味を記述する記号です。最初に、この動詞を整理して、それをHTTPを使って表現する方法は後から考える段取りにします。しかし、もともとのHTTPメソッドも、その本来の意図・意味を動詞として定義しておきます。混乱を避けるために、現実のHTTPメソッドは大文字、抽象化された動詞は小文字で書くことにします。 HTTPメソッド 意味／使い方 対応する動詞 GET リソース（の表現）を取得する vi

「最小抽象ファイルシステムの仕様案 その2」 に書いたように、ファイルシステムAPIとHTTPを関係付けようとしてます。そこで、id:yoheiさん監訳の『RESTful Webサービス』を拾い読みしてみました*1。 RESTful Webサービス 作者: Leonard Richardson,Sam Ruby,山本陽平,株式会社クイープ出版社/メーカー: オライリー・ジャパン発売日: 2007/12/21メディア: 単行本購入: 25人 クリック: 842回この商品を含むブログ (168件) を見る それで知ったり考えたりしたことを以下に書きます。 HTTPクライアントとしてブラウザを使うときの問題点 HTTPメソッドの本来の意味／使い方は次のようらしいです。 HTTPメソッド 意味／使い方 GET リソース（の表現）を取得する PUT 新しいリソースを作る／既存リリースを上書き変更する

入力値の集合が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は省略します。 メイヤーは、最後の「

「悟りやヒラメキがほんとに大キライだ 」という記事を書いた背景には、ユースケースの「主／副シナリオ」、「<<extend>>, <<include>>」とかの概念にウンザリしたことがあります。あれから後も、この件がどうも気にかかっていて、『ユースケースの適用：実践ガイド』（asin:4894711869）という本を恵比寿の有隣堂で見つけてすぐ購入しました。 この本には、僕が疑問に思っていた点が説明してあって、理解に役立ちました。ある程度は理解できた事と、その内容に賛同するかどうかは別問題でして、（理解してもなお）納得のいかない点は多々あります。その話は、まーいずれするかも。 ところで、この『ユースケースの適用：実践ガイド』の第5章「ユースケースを図で表現する」の冒頭に次のような文があります。 これまで、長い時間をかけてユースケースのテキストを書いてきました。しかし、ことわざにもあるとおり、

ソフトウェアの設計は僕の仕事の一部なんだけど、モデリングとか高水準の設計手法とかに興味がない。いや、正確に言うと、そのテの手法とか流儀とかには、僕を苛立たせるものがあって、精神衛生のために避けている傾向があるってことです。 参照の必要があって、モデリングや設計手法の情報をWebや書籍で調べると、たいていはイライラしてきて最後まで読みきれず、腹を立てて放り投げてしまいますね。 なんでか？と言うと、僕が嫌いな「悟り」や「ヒラメキ」の要素が含まれることがあるからです。「最初は意味不明でも、我慢しているとある日わかってしまう」ような体験 -- それを想定しているような説明がほんとに嫌いなんです。「ある日わかってしまう」経験は僕にもあります。でも、それは僕の能力が足りないからです。つまり、本来なら分かるはずのものが「理解力の不足ゆえに分かってなかった」という事実があるだけ、「遅れて理解した」という事

Pythonはほとんど使ったことがないのですけど、「いいなぁ」と思う点はインスタンス生成にnewが不要なこと。クラス名を関数呼び出し形式で使えばいいだけ、x = Person('Tonkichi') 。いいなぁ。 リテラルがなかったら不便 newがイヤなのは、まず単純に「書くのがめんどくさい」という理由があります。別な理由もあります、僕はリテラルが大好きなんだけど、newはリテラルにとって邪魔モノなんです。ここで、リテラルってのは、値やオブジェクトを直接に表現する記法です。たいていの言語で、153は整数リテラルだし、"Hello"は文字列リテラルです。 String s = "Hello";のようなリテラルが使えないと大変ですぜ。次のようにしなきゃならないでしょう。 // これはJava風 char[] s0 = {'H', 'e', 'l', 'l', 'o'}; String s =

Kuwataさんとリポジトリ共有のためにBitbucket（http://bitbucket.org）を使っているんですが、そのヘルプのHTMLソースを見たら、表示と関係ない要素がいろいろ入ってました。 JavaScriptを使うことを前提に、JavaScriptプログラムから使うデータをHTML文書内に埋め込んでいるんですね。もちろん、これらのデータは見えてはいけないので、隠すように細工されています。 meta要素を使う head要素内のmeta要素は何も細工しなくても隠れています。ここにプログラム用データを入れられます。「メタ情報である」というセマンティクスに沿ったデータなら、metaに入れるのも理にかなっているでしょう。 <meta name="ajs-build-number" content="2032" /> <meta id="atlassian-token" name="a

最近、JavaScriptとJSONと圏論（モナドとベックの分配法則）に関わる面白い現象を見つけました。圏論のところは置いといて、今日はJavaScript／JSONの具体的な話だけをします。 内容： JavaScriptのルーズな配列 配列とオブジェクトの統合 JavaScriptとJSONの違い ルーズとタイト JavaScriptのルーズな配列 JavaScriptでは、[,1,,3] のような配列を認めます。単に構文的に余分なカンマを許すだけではなくて、このカンマがデータ表現としての意味をちゃんと持つのです。Firebugで試してみましょう。 >>> var x = [,1,,3] >>> x.length 4 >>> x[0] // 何も表示されない >>> x[0] === undefined true >>> x[1] 1 >>> x[2] >>> x[2] === unde

健康関係のアヤシイ製品を紹介・賞賛しているとあるブログエントリーに次のようなコメントが付いていました。 最近多い広告ですが薬事法に触れるのではないかと思います。 それに対して、そのブログの著者の返答： この情報がはっきりとうそだとわかれば、この情報を削除します。 出たっ、無敵の論法。「嘘だと証明されないなら正しいかもしれない、いや正しいんだ」という論法。ウサン臭い製品がタチが悪いのは、はっきりと嘘だと分からないからです。真偽判定不能な命題を出して「この命題が偽であることを証明してみろ。それができないならこの命題は真だ」ってヤツね。これで信じてしまう人がたくさんいるらしい、、、

先週のエントリー「この機会にマスターしようぜ、正規表現、構文図、オートマトン」において、正規表現とオートマトンの理屈は説明しました。んじゃ、適当な正規表現に対応するオートマトンを作ってみましょう。 非決定性オートマトンはめんどくさいので決定性オートマトンにします。正規表現から作ったオートマトンが非決定性になってしまったときは、がんばって決定性オートマトンに変形するかあきらめるかしてください。 例題となる正規表現とオートマトンは、「Erlang実験室：状態遷移を書くのはこんなに簡単」で使ったものをそのまま流用します。 正規表現： (a, a?, b*, c) 図と表のなかで、EOSは End Of String のマーカー、◎は終状態です 遷移表： 0から3までの各状態について、入力ごとの遷移先は次の通り。×はエラーです。 状態 文字a 文字b 文字c EOS その他 0 1 × × × ×

正規表現と構文図について解説します。オートマトンについても詳しく述べます。オートマトン・スゴロクで遊びましょう！ 世間でよく知られている／使われている概念・方法にはこだわらず、僕（檜山）の感覚で一番わかりやすいと思われる筋書きと用語法／図式法を使って説明します。この記事に目を通して“感じ”が掴めたら、形式言語理論の教科書を読み始めることが出来るでしょう。 [追記]この記事の内容に対する具体例は、「正規表現とオートマトン：なんだ簡単じゃん、JavaScriptによる実装」にあります。[/追記] 内容： 正規表現 正規表現の例 構文図 基本記号 連接 選択 省略可能 繰り返し ストレートワイヤーによるレイアウト調整 有限状態オートマトン 有限状態オートマトンの実行 バックトラックと先読み スゴロクとオートマトン コマをたくさん使うスゴロクと並列処理 非決定性オートマトンと決定性オートマトン 正

なんらかの分野の初心者、なんらかの技量に習熟してない人、そういう人は全然ワカットランな状態にあるわけです。でも、わかっていないのが問題かというと、それは事実ではあっても、特に問題ではないですよね。だって、まだよくわかってない人を「初心者」とか呼ぶんだから、定義上当然にワカットランわけです。 僕が問題だと感じること、困ったもんだと思うことは、ワカットランの反対、つまり、ワカッテシマウことです。ほんとに分かってしまえば、ベテランやエキスパートの域に達したってことですが、初心者／未習熟なのにワカッテシマウのがちょっと困るのです。 僕自身もよくあることだから、自戒も込めて言うのですが、ワカットラン状態のときって、早とちりや誤解から「ナールホド、ソウカ！」とバカな納得をしてしまうことがあるんですよね。実は全然トンチンカンなんだけど。そういう軽率な了解・納得を後で思い起こすとスッゲー恥ずかしい。 たま

僕自身も僕の周辺もJSONをよく使います。でも、細かい点でけっこうミスをやらかしています(苦笑)。このエントリーで、JSONを使う上で注意すべきこと／間違いやすい点をすべて列挙します。 内容 兼チェックリスト： 仕様原典さえ読めば完璧（のはずだが） 数値の前にゼロを付けてはいけない 16進数表記も禁止だよ 数値の前にプラスを付けてはいけない 小数点からはじまる数値はダメ 用語法が違うよ：プロパティとメンバー メンバー名には常に文字列を使う 空文字列""もメンバー名に使える 配列要素はキッチリと並べよう 文字列を囲むには二重引用符だけ 文字列内のエスケープが微妙に違う 仕様にないエスケープは構文エラー undefinedもNaNもありません ラッパーオブジェクトは使わないのが吉 型システムとtypeofに関する注意 最後に 仕様原典さえ読めば完璧（のはずだが） JSONは、小さくて簡単な仕様

文字列リテラル内に登場する二重引用符そのものやバックスラッシュそのものは、エスケープしないとまずいですよね。 内容： 文字列リテラルを置換しよう 正規表現の復習 シェルコマンドラインのエスケープ シェルコマンドラインをsystem関数に渡す ●文字列リテラルを置換しよう 架空の例を出します。でも、あまりにたわいもない例だとつまらないので、次のストーリーを想定しましょう。 Cプログラムをgettextを使って国際化するときは、国際化／地域化したい文字列リテラルを適当なマクロ（N_とか）で囲みます。例えば、N_("hello") のように。これを機械的にやるとえらいことになります。例えば、 #include N_("myheader.h")がマクロ展開されたら変なことになるでしょう。 ですが、「まーとりあえず全部置換してしまえ」ってことで（いいんかそれで？）、GNU sedを使って“文字列リテ