人はどのように“記号の乱用”をしているのか - 檜山正幸のキマイラ飼育記 (はてなBlog)
「“記号の乱用”を実装すべきかもしれない」と「Catyに出現する名前達」において、名前が増えすぎて困る問題について述べました。困った状況は相変わらずです。 オーバーロードとか多相（総称、多態）は、名前を集約して減らす技術だとも言えるでしょう。実際、そのような技術を使わないと、名前はどんどん増えて、しかも長い名前となり、さらに悪いことには密接に関係する名前がまったく別な綴りを持ってしまうことがあります。 とりあえず、名前を減らす技術の使い方を云々する前に、ソフトウェアとは関係ない状況では「記号／名前の増加で困らない」のはなぜか？ を考えてみます。 「記号／名前の増加で困らない」理由は、“記号の乱用”をするからです。僕は「“記号の乱用”を実装すべき」と思っているので、人間が行なっている典型的な乱用の仕方を調べてみよう、ということです。 内容： 人間のコミュニケーションの実際 名前の意味をもっと
衝撃的なデータベース理論・関手的データモデル 入門 - 檜山正幸のキマイラ飼育記 (はてなBlog)
デイヴィッド・スピヴァックによる衝撃的なデータベース理論である関手的データモデル。どうしたらうまく説明できるか？ と色々と悩んでしまいますが、まー、書けるところから書き始めてしまいましょう。 さー、いらっしゃい、いらっしゃい。関手的データモデルの世界へようこそ。圏論の言葉は出てきますが、圏論の予備知識はほぼゼロでOKですよ。 [追記 date="翌日"]取り急ぎ勢いで書きましたので、不注意と早とちりが混じっていました。追記と取り消し線の形で訂正と注記を足しました。字句レベルの表現の変更は直接編集しています。 あとそれと、圏論の基本用語を知りたいときはコチラ、… って、……、ゴメン！[/追記] 内容： はじめに 本の購入のサンプル スキーマのグラフ表現 キーとか計算カラムとか 圏としてのスキーマ 関手としてのデータベース状態 テーブルの変化 自然変換としてのデータ操作 データベースに圏論が使
インターネットはテレビに負けた - 檜山正幸のキマイラ飼育記 (はてなBlog)
Twitterがいつの間にか変わっていた 「Twitterも昔は良かった」か。 僕は、昔も今もTwitterをほとんど使わないので、良かったもナニもないのですが、インターネット全体に関して「昔は良かった」感を抱くことはたまにあります。今のインターネットって、ようするにテレビですよね。「インターネットも昔は良かった」という思いは、僕の場合「昔のインターネットはテレビじゃなかったのに」ということです。 インターネットが普及したらテレビは駆逐されるだろう、みたいなことが言われたこともありましたが、そんなことはなかったみたいです。テレビを視聴する時間が減った、その原因のひとつがインターネットの普及ということは実際あるかもしれません。しかし、「インターネットがテレビを駆逐する」には別の意味が込められていた気がします。テレビとは違った媒体としてのインターネットが勝つ、というような。 でも、今のインター
未来のために過去が必要だ - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕らは未来を創らなくてはならない。 一般論ではなく、技術的なことに話を限ろう。未来は、未来の技術は、今と同じではなくより良いものであるべきだ。だから、未来のためにイノベーションが必要だ。イノベーションにはアイディアが必要だ。アイディアには知識が必要だ。知識は過去に蓄積された歴史的な産物。つまり、未来のために蓄積された過去が必要になるのだ。 「アイディアが閃く」と言ったりする。確かに、突然にイイコトを思いつくことはあるだろう。でも、それは真空中から生まれるものじゃない。無意識のうちに行われた知識の組み合わせの結果が、あるとき顕在化するのだろう。閃いたアイディアを形にするにも知識が必要だ。スキルも必要だ。 知識は過去から学び、スキルはトレーニングで得られる。天から降ってこない。一定の期間なら、何もしないでアイディアが天から降ってくるのを待ってみるのもいいと思う。これは意義がある。なぜなら、天か
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)
内容 レイフィケーション 形式化された証明と算術プログラミング メタプログラミングと妖精さん達 レイフィケーション 2006年の正月に、「ゲーデルの不完全性定理」に関する記事を何本か続けて書きました。 最初の記事： プログラマのための「ゲーデルの不完全性定理」(1) 3本目の記事である「プログラマのための「ゲーデルの不完全性定理」(3)：自己適用からゲーデル化へ」の「メタレベルも取り込むこと：レイフィケーション」という節に次のような絵を入れています。 この絵は、「記述される対象物」と「その対象物に関する記述」の構造が何段階かのメタ階層を作っている状況において、符号化により「対象と記述」が領域の内部へと埋め込まれる様子です。 この記事で既にレイフィケーションという言葉を使っています。 それから2年後、2008年の正月には、「いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ」と
ソフトウェアにとって大事なこと： 正しさが判断できること - 檜山正幸のキマイラ飼育記 (はてなBlog)
良いソフトウェアとは何か？ という基準は人によって違うでしょう。機能が豊富、使いやすい、値段が安い、などの条件がありますよね。僕の関心と価値観から言うと、「正しさが判断できる」ことを重視します。良いソフトウェアの基準というよりは、むしろ、「これを満たさないとダメだよ」という基準なのですが、クリアするのは容易ではありません。 内容： 正しさが判断できるとは 挙動の予測可能性 事前状況の制御可能性 事後状況の観測可能性 まとめ 正しさが判断できるとは 正しいソフトウェアを作りたいと切望するのですが、そうはいってもソフトウェアは人間が作るもの、人間は間違うのでなかなか正しいソフトウェアは作れません。それは致し方ないことだと思っています。つまり、ソフトウェアはたいてい正しくないのです。できるだけ正しくしようという努力が続くだけです。しかし、もし正しさが判断できないなら、「より正しくしよう」という目
型宣言、ホーアトリプル、関数定義は同じもの - 檜山正幸のキマイラ飼育記 (はてなBlog)
内容： 型宣言とホーアトリプル 関数定義とホーアトリプル ホーア論理とホーアセオリー 伴意順序 いろいろな概念を統合できるかな 型宣言とホーアトリプル fが関数だとして、f:X→Y という形はfの型宣言だとみなせます。話を簡単にするために、「型とは集合だ」と考えましょう。これから考える集合 A, B, C などは十分にに大きな集合Uの部分集合だとします。コンピュータで計算する関数に関しては、そんなUが存在します。 p, q などが論理式だとして、ホーアトリプルを p{f}q の形で書きます。pが事前条件、fが実行文（を表す関数）、qが事後条件です。ホーアトリプル p{f}q の意味は次のとおりです。 p(x) が成り立つ状況で f をすると、q(f(x)) が成り立つ。 論理記号で書けば、∀x.[p(x)⊃q(f(x))] です。ここで、「⊃」は「ならば」を意味する含意記号です。 ホーアト
悟りやヒラメキがほんとに大キライだ - 檜山正幸のキマイラ飼育記 (はてなBlog)
ソフトウェアの設計は僕の仕事の一部なんだけど、モデリングとか高水準の設計手法とかに興味がない。いや、正確に言うと、そのテの手法とか流儀とかには、僕を苛立たせるものがあって、精神衛生のために避けている傾向があるってことです。 参照の必要があって、モデリングや設計手法の情報をWebや書籍で調べると、たいていはイライラしてきて最後まで読みきれず、腹を立てて放り投げてしまいますね。 なんでか？と言うと、僕が嫌いな「悟り」や「ヒラメキ」の要素が含まれることがあるからです。「最初は意味不明でも、我慢しているとある日わかってしまう」ような体験 -- それを想定しているような説明がほんとに嫌いなんです。「ある日わかってしまう」経験は僕にもあります。でも、それは僕の能力が足りないからです。つまり、本来なら分かるはずのものが「理解力の不足ゆえに分かってなかった」という事実があるだけ、「遅れて理解した」という事
WebアプリケーションフレームワークCatyの現状と今後 - 檜山正幸のキマイラ飼育記 (はてなBlog)
最近どんな感じで、何を目指してやっているのかを簡単に紹介します。目指していることはイッパイあるのですが、特に「インスタントモックアップ」と我々（僕とKuwataさん）が呼んでいる機能にフォーカスします。インスタントモックアップは、最近着手したばかりで何も出来てないのが実状ですが、できたらけっこう便利そう。すごく便利かもしれません。 インスタントモックアップの目標は「Webサイト／Webアプリケーションのプロトタイプ作成の労力を、百分の一にする」ことです。効率を二桁上げたいわけね。なんかホラ話みたいでしょ。実際、誇張表現なんですが、まったく根拠がないわけでもないんですよ。 内容： 例題「ユーザー管理業務」 Catyの用語を少しだけ モジュールの構造 定義が書いてないモジュール 何をすべきかはナントナク予想できる どんなに中途半端・不完全な設計でも動かす 例題「ユーザー管理業務」 「1年たって
XPathの要点を少し抽象的にまとめておく - 檜山正幸のキマイラ飼育記 (はてなBlog)
ものすごく久しぶりにXPathを使おうと思ったのですが、「XPathってなんだっけ？」という程度に忘れています。 細部はリファレンスマニュアルを調べれば分かることなので、概念的にどんなものかを思い出すのが先。概念や構造を手っ取り早く理解するには、抽象化したほうが都合がいいです。抽象化すると本質がコンパクトにまとまるので忘れにくいし、忘れても思い出す手間も少ないですからね。 内容： ツリー、有向グラフ、ノードセット 全順序付きノードセット 軸 コンテキスト ステップ ロケーションパスの評価 続きの記事：XPathの構文を割と具体的にまとめておく ツリー、有向グラフ、ノードセット XPathが相手にするデータ構造はツリーです。XMLのツリーには属性ノード、名前空間ノードとかもあるので、ノードにも辺にもいろいろな値（ラベル）が付着している有向グラフと考えましょう。ルートが特定されていてサイクルが
リビジョン（バージョン）管理システムに関して近ごろ思うこと - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕は、twitterできわめて少数の人しかフォローしてません。そんな僕のtwitterタイムラインでも、何度も言及されていたのが次のブログエントリー： いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ 本文は「なるほどね」という感想なんですが、コメント欄に驚くべき発言があります。 まずは本文から紹介すると、「いっしょに仕事をしたいプログラマ 5つの特徴」が挙げられていて、それらの特徴で「欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう」と。 5つの特徴のひとつに「人のコードにパッチを送る」（適切なパッチを書ける能力）があるのですが、それに対するコメントが： ミッションクリティカルなシステムでは自分が再利用しようとする既存コードにバグがあった場合は、まるっとコピーしたうえで修正したものを使うことが多いです。 「まるっとコピー」って、い
この機会にマスターしようぜ、正規表現、構文図、オートマトン - 檜山正幸のキマイラ飼育記 (はてなBlog)
正規表現と構文図について解説します。オートマトンについても詳しく述べます。オートマトン・スゴロクで遊びましょう！ 世間でよく知られている／使われている概念・方法にはこだわらず、僕（檜山）の感覚で一番わかりやすいと思われる筋書きと用語法／図式法を使って説明します。この記事に目を通して“感じ”が掴めたら、形式言語理論の教科書を読み始めることが出来るでしょう。 [追記]この記事の内容に対する具体例は、「正規表現とオートマトン：なんだ簡単じゃん、JavaScriptによる実装」にあります。[/追記] 内容： 正規表現 正規表現の例 構文図 基本記号 連接 選択 省略可能 繰り返し ストレートワイヤーによるレイアウト調整 有限状態オートマトン 有限状態オートマトンの実行 バックトラックと先読み スゴロクとオートマトン コマをたくさん使うスゴロクと並列処理 非決定性オートマトンと決定性オートマトン 正
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
こんなとき、詩人も芸人も必要なんだと思う - 檜山正幸のキマイラ飼育記 (はてなBlog)
まったくひどい状況ですが； 昨日（日曜）書いた事と似たような話をもう一度します。 現状では、テレビ放送は情報を提供するための報道番組が圧倒的です。しかし、報道が「必要なことの全て」ではない、と思うのです。と言うと不謹慎に聞こえるでしょうが、報道を否定するものではなくて、必要な報道を圧迫しないことを前提としての話です。 子供向けアニメやヒーローものは子供たちに必要です。1回なら「ガマンしなさい」で済むでしょうが、できるかぎり早く平常に戻して欲しいです。ウチの子たちは子供番組を必要としない年齢になりました。ですが、あの津波の映像は怖すぎます。次男などは、やはり恐怖を感じて萎縮しているようです。今のウチの子たちはサッカー中継とお笑い番組を欲しています。 サッカー選手は多くの子供たちの夢です。お笑い芸人も、ウチの子たちにはヒーローでありあこがれの存在です。スポーツ選手や芸人さんたちは、彼・彼女たち
論理的であるかのごとくに装って、根拠のないイチャモンをつける 13+2 の方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
ちょっと挑発（コレの最後）してみたけど、どうせ反応はないだろな。しらけてしまわないうちに自分でテンション上げて解説を書いてみました。 内容： 前がき 本編 定義の違いを真偽の議論にすり替える 言ってもない事を否定して印象操作をする 傾向や量に関する主張に、勝手に全称限量子を付けてしまう とある階層でなされた主張を、別な階層で否定する 権威や前例に訴える 権威や前例に訴える 別バージョン 論点ズラシ、意図・論点の曲解 論点ズラシ、意図・論点の曲解 感情バージョン 意味もなく自分の経験や知識を強調 問題点を他の事情により帳消しにする 意味不明でもいいから難しそうなことを言ってみる 普通とは異なる解釈を持ち出す 反論されたときは最小コストでごまかす 余計なお世話な悪口も辞さない 言い張る 後がき 前がき すぐあとに続く「本編」では、ホントに「根拠のないイチャモンをつける方法」、もう少し正確に言う
論理的言明を装った感情論は嫌い、という感情論 - 檜山正幸のキマイラ飼育記 (はてなBlog)
ちょっと時間がたってしまったネタですが： プログラミングの出来る人と出来ない人の決定的な違い。 「プログラミングの出来る人と出来ない人の決定的な違い」？ ワンヤグさんの「プログラミングの出来る人と出来ない人の決定的な違い。」は、たくさんのブックマークを集めた記事。それに対して、id:JavaBlackさんが随分と否定的な記事を書き、さらにワンヤグさんが当該記事への追記として反論（らしきこと）を書いています。内容的に、ドチラかが全面的に正しいとは思えないし、ドチラかに味方する気もありません。 ですが、僕のセンサー（どんなセンサーかは最後に述べます）が反応したので、思うところを書いておきます。 時間順が前後しますが、まずはJavaBlackさんの記事のほうから。僕は、元記事「プログラミングの出来る人と出来ない人の決定的な違い。」を読む前に、JavaBlackさんの記事のほうを先に読んだのです。
Wiki処理系を作る前に知るべきこと／考えるべきこと - 檜山正幸のキマイラ飼育記 (はてなBlog)
Wiki構文（Wiki記法のルール）は山にようにイッパイあります。 「新たにもう1つ構文を付け加えても別にいいだろう」と考えるか、「これ以上新しい構文を増やしてはいけない」と考えるかは人によるでしょう。僕は、「集約・統合してWiki構文を減らすべきだ」と考えています。それで、標準的なWiki構文としてWikiCreole 1.0を採用し、KuwataさんがCreoleパーザーを実装しています。 ところが、WikiCreoleの構文記述が曖昧過ぎてサッパリわからんのです。Kuwataさんもイライラしている様子。このような状況はWikiCreoleに限りません。たいていのWiki構文の記述はイイカゲンです -- いやっ、仕様書があるだけでマシなのです。イイカゲンな仕様に適合した（conformantな）処理系を作れと言われてもそりゃ困りますわな。 WikiCreole仕様の曖昧さは以前にも話題
Webサービスを設計するための単純明快な方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Webサイト」、「Webアプリケーション」、「Webサービス」、「Web API」などの用語の区別はそれほど明確でもないし、きっちり区別して使うのもめんどくさいので、ここでは、これらを総称してWebサービスと呼んでしまうことにします。 山本陽平さんは、その著書『Webを支える技術』のなかで、人間がブラウザを使って利用するWebサイトとプログラム向けのWeb APIを区別すべきではないと述べています。この点は僕もまったく同感・同意です。 人間が相手となると、視覚的な効果や装飾、JavaScriptを使った操作性などにフォーカスが向けられ、Web APIとはまったく別物のような印象を与えます。しかし、各ページが持つべき情報やページ遷移の有向グラフ構造などは、相手が人間でもプログラムでも同じだと思うのです。そんな事情で、Webページの機能的／情報的なエッセンスを表現したHTML文書をクリーンH
テンソル：定義とか周辺の話とかナニやら - 檜山正幸のキマイラ飼育記 (はてなBlog)
奇遇ですね。 「テンソルってなんかよくわかんね」 僕も比較的最近、「テンソルってなんなんだよ」と考える機会がありました。 「テンソルってなんなんだよ」と最初に考えたのはもう二十数年も前になるのではないでしょうか。それ以来、たまに思い起こすことがあります。 昔（二十から三十年ほど前です）は、微分幾何や物理工学系の本も含めて勘定すれば、テンソルの本はけっこうたくさんあったように思います。が、最近は何故かあんまり見かけませんね（僕の気のせいでしょうか？）。まーとにかく、当時はテンソルの教科書は複数あって見比べることも出来たのですが、どれを読んでもサッパリまったく理解できませんでした。 これは黒魔術か？ それらの本におけるテンソルの定義は次のようなものでした。 i1, ..., in、j1, ..., jmを適当な範囲を動く添字（番号）だとして、添字付けられた数（スカラー）の組 ai1, ...,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
