デシリットル問題 - 檜山正幸のキマイラ飼育記 (はてなBlog)
長男：「おとうさん*1、デシリットルって習った？」 父親：「あー、習ったよ」 長男：「俺も習った。けどさ、デシリットルって見たことないんだよね。おとうさんは使う？」 父親：「リットル、ミリリットル、キロリットルは使うけどなー …」 長男：「デシリットル使う？ 見たことある？」 父親：「ウーン、ないな。君よりはるかに長く生きてるけど、小学校の教科書以外で見たことないわ」 長男：「おとうさんも見たことない。じゃ、なんでアレ習うの？」 父親：「アレねぇ、デシリットルねぇー」 長男：「意味ねーじゃん」 父親：「いやまー、すぐに役に立つもんばかりが教育じゃないからね」 長男：「役に立たなくてもいいけどさ、どんな意味があるの？」 父親：「デシリットル教える意味ねぇ、エーと、ウーンと …」 よくわかりません。 *1:オヤジと呼ばれることも最近多い。
JavaScriptの関数には、やたらに何でも突っ込める - 檜山正幸のキマイラ飼育記 (はてなBlog)
jQueryのドル記号「$」は、理不尽なくらいに大活躍します。あまりにも何でもできるので、「ありゃ何なんだ？」と思いますよね。$(...) という形で呼び出せるので、関数なのは確かです。JavaScriptでは、ひとつの関数名に対して呆れるくらいにオーバーロード（多義的定義）ができます。 内容： コンストラクタあるいはクラスとしての関数 メソッドとしての関数 名前空間あるいはモジュールとしての関数 関数／オブジェクトとしての関数 試してみる コンストラクタあるいはクラスとしての関数 関数は、オブジェクトのコンストラクタとして使用できます。 function Point(x_, y_) { this.x = x_ || 0; this.y = y_ || 0; } お尻にアンダースコアが付いた引数名 x_, y_ は省略可能のつもりです。new Point()、new Point(2)、ne
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%把握したいのです。 列挙する
バルセロナ vs サントス 異聞 - 檜山正幸のキマイラ飼育記 (はてなBlog)
長男はサッカーが大好き。僕も長男も行く美容院などでは、長男がサッカーの話ばかりするので、なんか僕もサッカーファンだと勘違いされたりするのだが、そんなことはない。僕はあんまり興味ない。 で、長男は、「TOYOTAプレゼンツ FIFAクラブワールドカップ ジャパン 2011」の決勝（2011-12-18）を見に行って、ナンヤカンヤとその話をしてくれるのだが、僕の興味を引いたのは次の4つ。 試合が行われたスタジアムは、TV放映などで「横浜国際総合競技場」と呼ばれているが、ほんとは「日産スタジアム」。「TOYOTAプレゼンツ」なので、「日産スタジアム」は具合が悪いので旧称を使ったのだろう、と。 長男は、テーマ曲をKyleeが歌っているときにトイレに行ったそうな。皆んな曲を聞いて盛り上がっているあいだに、と。そしたらトイレに長蛇の列。「ええー、みんな、なんでテーマ曲聞かないのー」。お前も聞いてないだ
論理的であるかのごとくに装って、根拠のないイチャモンをつける 13+2 の方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
ちょっと挑発（コレの最後）してみたけど、どうせ反応はないだろな。しらけてしまわないうちに自分でテンション上げて解説を書いてみました。 内容： 前がき 本編 定義の違いを真偽の議論にすり替える 言ってもない事を否定して印象操作をする 傾向や量に関する主張に、勝手に全称限量子を付けてしまう とある階層でなされた主張を、別な階層で否定する 権威や前例に訴える 権威や前例に訴える 別バージョン 論点ズラシ、意図・論点の曲解 論点ズラシ、意図・論点の曲解 感情バージョン 意味もなく自分の経験や知識を強調 問題点を他の事情により帳消しにする 意味不明でもいいから難しそうなことを言ってみる 普通とは異なる解釈を持ち出す 反論されたときは最小コストでごまかす 余計なお世話な悪口も辞さない 言い張る 後がき 前がき すぐあとに続く「本編」では、ホントに「根拠のないイチャモンをつける方法」、もう少し正確に言う
論理的言明を装った感情論は嫌い、という感情論 - 檜山正幸のキマイラ飼育記 (はてなBlog)
ちょっと時間がたってしまったネタですが： プログラミングの出来る人と出来ない人の決定的な違い。 「プログラミングの出来る人と出来ない人の決定的な違い」？ ワンヤグさんの「プログラミングの出来る人と出来ない人の決定的な違い。」は、たくさんのブックマークを集めた記事。それに対して、id:JavaBlackさんが随分と否定的な記事を書き、さらにワンヤグさんが当該記事への追記として反論（らしきこと）を書いています。内容的に、ドチラかが全面的に正しいとは思えないし、ドチラかに味方する気もありません。 ですが、僕のセンサー（どんなセンサーかは最後に述べます）が反応したので、思うところを書いておきます。 時間順が前後しますが、まずはJavaBlackさんの記事のほうから。僕は、元記事「プログラミングの出来る人と出来ない人の決定的な違い。」を読む前に、JavaBlackさんの記事のほうを先に読んだのです。
これだからシェルは… - 檜山正幸のキマイラ飼育記 (はてなBlog)
シェル（主にbash）のスクリプトをたまーに書きます。シェルスクリプトの構文は全然憶えられないし、しょっちゅう間違います。そんなことを何度かこのブログに書いたことがあります。 シェル（bash）のfor文の違いを吸収するMakefile の書き方 シェルスクリプトのセミコロンの打ち所がわからん testコマンドのハイフンナンチャラが憶えられない 今日も間違いました。 if [ "$1" = ""]; then echo "Do Something" fi これはうまく動きません。 空白を1つ足してやる必要があります。 if [ "$1" = "" ]; then echo "Do Something" fi 左ブラケット '[' は、testというコマンドの別名で、[ "$1" = ""] は、次のように分解されます。 第1引数："$1" 第2引数：= 第3引数：""] これはうまくなくて
マイクロフォーマットとクリーンHTML - 檜山正幸のキマイラ飼育記 (はてなBlog)
ここ何日かマイクロフォーマット（microformats）の話題を続けています。僕がマイクロフォーマットを思い出したキッカケは、WebAPIのデータ形式について考えていたときです。マイクロフォーマット方式でマークアップされたHTML断片をWebAPIで使えないかな？と思ったのです。 多くのWebAPIでは、特定のURLにHTTPリクエストを送ると、XMLやJSONのデータが応答として返ってきます。仮に、とあるAPIがJSON形式の人物情報を返してくるとします。独自に人物情報のデータ形式を考えるよりは、何か標準を採用すれば、考える手間も省けるし、相互運用性からも好ましいでしょう。 そこで、hCardのサブセットを使うことにします。スキーマ（型定義）を示すことはしませんが、例えば次のJSONオブジェクトは人物情報のインスタンスだと考えられます。 { "vcard" : { "fn" : "檜山
ファイルパス名の構成部分の、呼び名と定義 - 檜山正幸のキマイラ飼育記 (はてなBlog)
basename, dirnameというコマンドとか関数があります。これにより、ファイル（またはディレクトリ）のフルパスを2つの部分に分けることができます。それぞれの部分を「ベース名」、「ディレクトリ名」と呼ぶのは常識と言ってもいいと思います。また、「+」を文字列連接演算だとして次の関係があります。 fullpath = dirname + '/' + basename ところが、ルートディレクトリに関してはこの関係が成り立たないことがあります。GNUのコマンドでは、「basename /」も「dirname /」も結果が / なので、上の等式はそのままでは成立しません。でも、ルートに対するbasename, dirnameを共に空だと定義し直せばOKです。 ベース名には拡張子が含まれることがあります。ベース名から拡張子を除いた部分は何て呼ぶんでしょう？ ルート名（root name）とい
VOODOOな理論達：南堂久史さん、その強さの秘密 - 檜山正幸のキマイラ飼育記 (はてなBlog)
平成のアリストテレス／博学の王・南堂久史さん（と勝手にキャッチコピー付けてみました）の解説「シュレーディンガーの猫の核心」に対して、nucさんが「シュレディンガーの猫」なるエントリーを書かれました。 昨日のエントリーより引用： しかしながら、これを読んでみて、nucさんも僕も、南堂さんには“かなわない”なー、という気分もしました。それはどういうことかと言うと … ウーン、時間がない、明日とか。 で、続きです。 ●理解した気分になったほうが嬉しい id:mindさんの、「いいセンいってる南堂久史さん」へのブックマーク・コメントが大変に示唆的： 我々は理解するよりも、理解した気分になったほうが嬉しいですから。 さらに面白ければ2倍トク。 この「理解した気分」の取り扱いが非常に厄介でして、僕もホントに悩まされていることなんですよ。 ●比喩の功罪 誰か（ファインマンだったかな？）が、量子力学的現象
RESTfulなWebサイトと拡張子を含むURLについて - 檜山正幸のキマイラ飼育記 (はてなBlog)
2009年12月16日「チュートリアルを少し変更、おバカな設定例」 Catyでは、ファイル名拡張子の意味付けや扱い方がデスクトップと同じなんだけど、「クールなURIは、拡張子がねーんだぞ」とか言われそうだから、そのうちラショネールを書かなきゃ。 「ラショネール」なんて奇妙な言葉が出てきてますが、目論見や主張が正当であることを示す根拠、てな意味ですかね＞ラショネール。 僕とKuwataさんが開発しているWebフレームワークCatyは、URLに、.html, .cgi などの拡張子を必ず要求します。クエリパラメータも遠慮なしに使います。「拡張子とかクエリパラメータなんて、RESTfulじゃないなー、クールじゃないなー」とか言う人がいますが、なにゆえに「拡張子やクエリパラメータがダメなのか？」 -- その根拠を示して欲しいもんです。僕らが積極的に拡張子やクエリパラメータを使う事情と根拠は、このエ
JSONスキーマの功罪を、印象や感情じゃなくて考えてみようか - 檜山正幸のキマイラ飼育記 (はてなBlog)
「JSONの可能性がグンと拡がるぞ！ JSONスキーマ」に対して、がくぞーさんからトラックバックをいただきました。その冒頭を引用すると： この記事のブコメを見てみると XML Schema が在るんだし軽さがウリの JSON にそんなの必要なくね？的なコメントが散見されます。 なるほど、「なんだか複雑になりそうでヤダなー」とか「そんなもん要らねーよ」という印象や感情を持たれた方もいるんでしょうね。僕は、JSONスキーマをプロモートする気はないので、「ヤダ」とか「要らねー」の人を説得する動機はないのですが、「印象や感情だけじゃ主張や議論にはなりませんよ」って趣旨でちょっと書いてみます。 内容： 僕の感情と事情 妥当性の検証はたいてい必要 JSONにスキーマはそぐわない？ JSONスキーマの弊害 バリデータ実装の負担 僕の感情と事情 「印象や感情じゃ、ラチあかんよ」と言いましたが、まずは僕の感
Back to XML (2) - 檜山正幸のキマイラ飼育記 (はてなBlog)
過去に蓄積されたXML技術のどのあたりを檜山が面白いと感じ、再評価・再発見してみたいと望んでいるのか？ それは、また次ね。 前回、こんな文面で終わってしまったので、「それはどこ？」の話をせざるを得ないでしょうね。だから実際しますけれども、論理的な順序から言うと、その前に話しておくべきことがあるのだった。まー、いきがかりだから論理的順序は無視します。したがって、解説としては若干不親切で、幾分錯綜した感じになりそう。致し方ない。 話は前世紀まで遡＜さかのぼ＞るのだが 「過去に蓄積されたXML技術」という言葉は、なにか特定単一の仕様を意味してるわけではありません。いまだ脈ありと僕が思っているものがいくつかあるわけです。そのなかで第一の候補を挙げれば、… … XLinkです。 XLinkは、XML 1.0仕様とほぼ同じ時期から構想されているものです。XMLの初期のドラフトでは、XLink仕様がXM
もう一度、ちゃんとJSON入門 - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕自身も僕の周辺もJSONをよく使います。でも、細かい点でけっこうミスをやらかしています(苦笑)。このエントリーで、JSONを使う上で注意すべきこと／間違いやすい点をすべて列挙します。 内容 兼チェックリスト： 仕様原典さえ読めば完璧（のはずだが） 数値の前にゼロを付けてはいけない 16進数表記も禁止だよ 数値の前にプラスを付けてはいけない 小数点からはじまる数値はダメ 用語法が違うよ：プロパティとメンバー メンバー名には常に文字列を使う 空文字列""もメンバー名に使える 配列要素はキッチリと並べよう 文字列を囲むには二重引用符だけ 文字列内のエスケープが微妙に違う 仕様にないエスケープは構文エラー undefinedもNaNもありません ラッパーオブジェクトは使わないのが吉 型システムとtypeofに関する注意 最後に 仕様原典さえ読めば完璧（のはずだが） JSONは、小さくて簡単な仕様
シェルのリダイレクトを「こわいものなし」というくらい完全に理解しよう - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Java BlockingQueueで遊ぶ：パイプラインごっこ」でパイプラインの話をしたので、本来の、つまりUnixのパイプやリダイレクトを少し調べてみました。 たまに話題となる some-command >file 2>&1 と some-command 2>&1 >fileの挙動の違いについて、「シェルはコマンドラインリダイレクトの指定を右から左に解釈実行する」なんて説明が見つかりました。んなバカな！ パージングは左から右にするものですよ。パーズツリーを逆順にたどることはできるけど、そんなことする必然性はなんにもないよ。 次の記事を読むと、「右から左」なんて事情じゃないことが分かるでしょう。 UNIXの部屋 検索: リダイレクト シェルのリダイレクトにまつわる失敗 さてここでは、複雑なリダイレクト処理も完全に理解できる処方箋を示しましょう。例えば、次のコマンドラインが何をするか分かる
イベントモデルの概念と用語法が混乱しているので、イライライするんですが - 檜山正幸のキマイラ飼育記 (はてな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インターフェース イベントハンドラーとイベントリスナー リスナーとハンドラーについてもう少し イベント伝搬とハンドラー実行 イベントの通過または出現 イベントタイプ 「イベント
Webでダイエット -- 同じこと考える人はいるのね、だけどこれは… - 檜山正幸のキマイラ飼育記 (はてなBlog)
おや、おやおや。 「どんな方法にも向き・不向きがあると思った」で次のように書いたけど： ところで、ダイエットって巨大市場ですから、携帯電話＋Webでレコーディング（詳細な記録）をサポートするサイトとか作るとヒットするかもしれませんね。 実際にやった人がいたのね（僕は言ってみただけ）。それで、 いいめもダイエット サービス停止のお知らせ って、変な結末になっちゃった、と。でも、岡田さんもちょっとスモール・アナルなんじゃないの。脂肪と一緒に寛容さ／鷹揚さも削り落としてしまったのかな（もとが寛容／鷹揚だったかどうか知らんけどさ）。 あっ、念のため： [岡田氏に]事前に承諾を得なかったこと、無断でお名前を記載してしまったことなど、 これはマズかったと思うけどね。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
重箱読み、湯桶読み、いや違う、何読み？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
「ドドーン」ってそう書くの？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
ていねい形・過去 - 檜山正幸のキマイラ飼育記 (はてなBlog)
