中里一日記: 日本語に足りない言葉
一応、「ポンジ・スキーム」という言葉はある。 数ある投資詐欺のうち、一番シンプルなのが、このポンジ・スキームだ。どういうものか。詐欺師は高利回りを約束して金を集める。詐欺師は最初のうちは、分配金や払戻金を約束どおりに払うが、それは集めた金の一部を当てているだけで、金儲けのたぐいは一切しない。金が約束どおりに支払われるというので、詐欺師の信用と知名度は高まり、高利回りに引き寄せられて、どんどん金が集まる。金の集まるスピードが、約束した利率よりも高いうちは、分配金や払戻金を払うことで、詐欺師の儲けは増えていく。 つまり、安愚楽牧場やMRIインターナショナルだ。 安愚楽牧場事件やMRIインターナショナル事件の報道の際に、ポンジ・スキームという言葉を使えれば、どんなに話が簡単になったことか。欧米ではポンジ・スキームという言葉は、日本での「ネズミ講」という言葉なみに通じる言葉らしいが、日本では
中里一日記: 僕はSQLができない
僕はSQLができない C.J.Date『データベース実践講義』を読んだ。 私はSQLが死ぬほど苦手で、少しでも複雑なクエリを書くたびに参考になるものを探す。さっぱり理解できない要素も山ほどある。たとえばIN。主にぐぐれないせいだが。 なぜ私はこうもSQLが苦手なのか、この本を読んでよくわかった。SQLが糞だからだ。 どう糞なのか。 ・値と変数を分けて扱うことができない。たとえばSQLの「テーブル」とは値なのか変数なのか ・テーブルの値は行の集合、つまり（Javaでいうところの）Setであるべきなのに、Listになっている。シンプルなSetのかわりに、妙なものがゴチャゴチャついたListを使わされるのがSQL ・SQLの型サポートは貧弱で、意味的にありえないクエリがエラーにならない。品物の個数とID番号がどちらも整数型というだけで比較できてしまう 上記の問題点をご覧になって、なにかお気づきに
「数式エディタを知らない？」彼女はあきれたようにつぶやいた。
「数式エディタを知らない？」彼女は鋭く指摘した。 Illustratorで数式を書きたいんだけど、と尋ねた私は――うっかりしていた。 私はこれでもWord使いということになっている。フィールドコードが読めるとか、Wordの吐くHTMLをMS HTML FilterとHTML Tidyのあれこれの組み合わせであれこれの程度にまともにしてしまうとか、そのくらいのWord使いだった。となると、数式エディタのことは当然知っているべきだし、実際知っているし、彼女が「数式エディタ」と言った瞬間に全部わかってしまった。私が間抜けだったのだ。 私はあわてて言った。数式エディタからコピーして貼る？ 「ほかに方法がなければね。ただし、なにしろ出来が出来だから、ズレてることもある」 彼女は実演してみせた。数式エディタを単体で起動し、定積分の数式を作って、Illustratorに貼った。積分区間の数字が、イン
中里一日記: 正規表現マッチングはMap-Reduceできる
正規表現マッチングはMap-Reduceできる グレゴリオ暦で新年を祝われる皆様、あけましておめでとうございます。 今日のお題は正規表現。ただしチューリング完全なPCREではなく、有限オートマトンにもとづく本来の正規表現である。 一個の巨大な文字列に対する正規表現マッチングをMap-Reduceで分散計算することはできないと思い込んでいるマヌケな子はいねーがー？ できそうな気はするけれどアルゴリズムがわからないアホな子はいねーがー？ 大丈夫、このエッセイを読むまで私にもわからなかった。アホはあなただけではない。といってもなんの慰めにもならないが。 （このエッセイは正規表現のインクリメンタルマッチングの計算量について論じているが、分散計算のほうが例として自然と思ったのでそうした） 英語とHaskellができてモノイドとfingertreeが常識な人なら元のエッセイを読めばすべて一目瞭然だと思
中里一日記: プロにはできない・教えられない掃除法
プロにはできない・教えられない掃除法 石鹸カスは灯油で拭くと簡単に落ちる。ちなみに私自身は灯油は臭いので使わず、かわりに5-56を使った。 あれこれネットを調べていると、清掃業者や洗剤業者はめったに非極性の溶媒を使わない・売り込まないように見える。労災関係かと思ったが、フッ化水素酸は使うらしいので、おそらく色落ちによるクレームのリスクを最小化するためだろう。 クレームのリスクがないという条件のもとでは猛烈に便利な手法でありながら、プロがそれを教えるとクレームのリスクを負うので世に知られない、という手法がこの世にはたくさんあるのだろう。
中里一日記: 難しいプログラミング入門
難しいプログラミング入門 『やさしいプログラミング入門』といったタイトルの本を見るたびに、『鈍才の数学』のことを思い出す。 これは中学か高校のとき教師から聞いた話だ。 かつて、『鈍才の数学』という学習参考書を書いた人がいた。著者がいうには、「天才にとって数学は簡単なので、鈍才が数学に苦しむ理由がわからない。しかし自分は鈍才なので、それがわかる。だから天才よりも私のほうが、鈍才の読者諸君をうまく教えることができる」。納得できる話だ。本の内容も大変優れていた。しかし『鈍才の数学』はまったく売れなかった。そこでタイトルを『英才の数学』に変えたところ、ただちにベストセラーになり、数学の学習参考書の定番になった。どうやら、学習参考書を選ぶときに、自分を鈍才と認めることのできる人は少ないらしい。 『やさしいプログラミング入門』には、『英才の数学』的なごまかしを感じる。数学もプログラミングも、ほとんどの
中里一日記: 護身：XQuery
護身：XQuery 真の護身が完成すると、危険に気づくまでもなく、危険に近づくことができなくなる、という（『グラップラー刃牙』）。 プログラマも護身する。 護身ができているプログラマは、危険なツールや規格やフレームワークを、その存在に気づくまでもなく回避する。 過去の例を挙げよう。RDBMSにMySQLを採用して、4.1の文字化け問題を踏んでしまったプログラマは、護身ができていなかった。護身ができていれば当然PostgreSQLを使っていただろう。 また、現在の例を挙げれば、PHPを使うプログラマは護身ができていない。護身ができていれば当然PythonかRubyを使うだろう。 これらの護身は、なにも超能力ではなく、事実にもとづく総合的な判断だ。 たとえば、日本人の開発者はMySQLには少なく（おそらく存在しなかった）、PostgreSQLには多い。となるとMySQLがいずれ日本語関係で問題
中里一日記: 分散ファイルシステムとHDDのあいだに
分散ファイルシステムとHDDのあいだに ファイルシステムやRDBMSは、なんらかの形でロック機構を持っている。ロック機構がなくてはデータの一貫性が保てない。 分散環境ではロック機構が性能の鍵になる。ノードの数を増やせば記憶容量が増える（スケールアウトする）のは自明だが、ロック機構はそうではない。 また、各ノードに備わるキャッシュ（ローカルキャッシュ）も問題になる。無効になったローカルキャッシュを適切に無効化しなければならない。 これらの要求は、ファイルシステムやRDBMSなどの永続化システムに共通している。また、分散環境では、素朴な方法（環境全体が一定数の同期オブジェクトを共有するなど）ではこれらの要求を効率よく満たすことはできない。 というわけで私は、分散ファイルシステムや分散RDBMSとHDDのあいだに、もう一つのレイヤを設けることを考えた。このレイヤのことを仮に「分散永続化システム」
中里一日記: 本物
本物 Windows専用の言語処理系のひとつに、HSPというものがある。 HSPの機能のいくつかは、月の裏側から集めてきたらしい。不要とわかって捨てられたものを、わざわざ復活させている。たとえばC言語風のマクロだ。私見では、#defineと#ifdefは手動メモリ管理に次ぐ害悪だ。Stroustrup『C++の設計と進化』540ページより引用する： マクロの定義は、環境の中や、コンパイラのディレクティブ、ヘッダファイルなど、いろんなところに潜んでいる。マクロによる置換はスコープという境界ルールを無視し、それどころか、勝手にブレースや引用符を挿入してプログラムのスコープ構造を変えてしまうこともある。（中略）その機能はあまりにも構造性を欠き侵略的なので、プログラマやメンテナ、コードを移植する人、ツールの作者などにとってつねに頭痛の種だった。 しかしHSPは当たった。同種のWindows専用の言
中里一日記: 妄想型プログラミング言語
妄想型プログラミング言語 経営者がビッグなビジネスを妄想するように、プログラマは自分の設計した言語を妄想する。どちらも、なんの役にも立たないが、やめられない。 この無益な行為のなかで、面白い言語機能を思いついた。ここにメモしておく。 public string Func() { using (FileStream fs = new FileStream("test.txt", FileMode.Open)) { using (StreamReader sr = new StreamReader(fs)) { return sr.ReadToEnd(); } } } よくあるC#のコード片だ。 このコード片には、意味的な無駄が多い。 まず、もしC#に型推論があれば、こう書ける。 public string Func() { using (var fs = new FileStream("te
中里一日記: DELETEと参照
DELETEと参照 Houndを通じてかれこれ１年以上、RDB（PostgreSQL）とORM（Cayenne）につきあってきた。そろそろ、この世界の味がわかってきたので、書きとめておく。 結論：DELETEは深遠な哲学的問題だ。 本題に入る前に、RDBの濫用について片付けておこう。 RDBは、あらゆるコンピュータ技術のなかで、もっとも濫用されている。積もりに積もった装飾をはぎとってみれば、RDBというシロモノは、ある面で比類なく優れているかわりに、それ以外の面では恐ろしく融通がきかない。オブジェクト指向がミニバンだとしたら、RDBはF1マシンだ。装飾に隠されてはいるが、本質は変えられない。このことを忘れて設計した人々は、あとで莫大な額のツケを請求される（こうしてOracleが儲かるわけだ）。 手始めに、行ロックを退けよう。トランザクションを開始するときには、トランザクションを終了するまで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
