Operating System Interface Design Between 1981-2009 | Webdesigner Depot
うーむ、八十年代から、あまり変わってないな。相変わらず、マウスカーソルによるポインティングが主流で、矩形のウインドウを基本としたGUIだ。色数や解像度、処理性能は向上したが、基本的な部分は、そう変わっていない。
もっとも、非矩形ウインドウは、一般のGUIとしては使いにくいし、マウスカーソルよりましなポインティングデバイスというのも、なかなか見あたらない。最近はタッチスクリーンが流行だが、これとて精度はともかくも、昔からあったものだ。革新的なUIや入力デバイスなどというものは、とくに発明されていない。
まともな参考書が見あたらないので、R6RSのドラフトを読むことにした。なんて読みやすくて短い規格書なんだ。うらやましい。とりあえずGaucheで、(define (foo) (foo))がクラッシュしそうにないことを確認。
鉄を発明したのはヒッタイトではなかった！
中近東文化センター（東京都三鷹市）が調査を続けているトルコのカマン・カレホユック遺跡で、紀元前２１００～同１９５０年の地層から、小刀の一部と見られる鉄器１点が発見された。鉄滓（てっさい）（鉄を生産・加工する時に出るかす）と、鉄分を含んだ石も確認され、鉄づくりが行われていたことが確実になった。人工の鉄の利用は紀元前１５世紀ごろに同じアナトリア半島のヒッタイト帝国で始まったとされてきた世界史の通説が書きかえられる。
鉄器は２０００年の調査で出土したもの。折れていて、つなぐと長さ５センチほど。さびがひどいが、切断して断面をＸ線で調べると、鋭い元の形が見えた。片側だけに刃がある小刀の一部と見られる。鉄滓は１個で直径２センチほど。原料と考えられる鉄を含んだ石は２個確認された。
同文化センターは中近東の歴史・文化を研究する財団法人として７９年に設立、８５年から現地で調査を続けている。昨年までの調査で紀元前１５世紀よりも古い地層から鋼を発見していた。しかし、上の地層から落ち込んだ可能性も否定できなかった。そこで出土した金属類の調査・分析を、岩手県立博物館の赤沼英男上席専門学芸員（文化財科学）が昨年から進めていた。
赤沼さんは「原料も含め加工段階の違う鉄が同じ地層から発見されたことで、この遺跡で鉄の加工が行われたことに疑いの余地がなくなった」という。
これまでは、人工的に鉄を作り出したのはヒッタイト人とされてきた。中国で鉄器が登場するのは前７世紀ごろ、普及したのは戦国時代の前４世紀ごろで、弥生時代だった日本にもそのころ伝わったらしい。
同文化センターの大村幸弘・アナトリア考古学研究所長は「鉄の生産はアナトリア半島で独自に始まり、後に北方から進入し征服したヒッタイト人が武器として利用し、その技術を秘密として守ることでオリエントに覇を唱える帝国を築き上げたのだろう」と語った。（渡辺延志）
Updated Direct2D in March DirectX SDK
The March DirectX SDK includes an updated build of Direct2D. Note that this build of Direct2D runs on both Windows 7 and Windows Vista.
Javascriptの落とし穴
フリーソフトウェア業界では、非フリー（訳注：この文章中のフリーは無料という意味ではない。ソースコードを自由に閲覧、改変、再配布できる権利とでもいうべきものである）なプログラムというのは、ユーザーをないがしろにしているという見解がある。中でも、商業ソフトウェアの使用を完全に拒否して、非フリーなプログラムに対抗している人もいる。この問題は、ブラウザのプラグインにも言えることだ。というのも、フリーなプラグインと、そうでないものがあるからだ。
ところが、ブラウザは、非フリーなプログラムを、ユーザーの了解を得ないままに実行しているのだ。多くの言語が使われているが、最も多く使われているのは、Javascriptだ。
Javascript（公式には、ECMAscriptと言うが、この名前はあまり使われていない）は、かつてはウェブページのおまけ程度にしか使われていなかった。たとえば、気の利いた、決して必須ではない、ナビゲーションや表示といった機能の実現のためだ。従来、これは、本物のソフトウェアというよりは、HTMLマークアップの拡張であるととらえられ、それほど真剣に考慮されてはこなかった。
多くのサイトは、いまだにこのような形でJavascriptを使っているが、Javascriptを本物のプログラムとして扱っているサイトもある。例えば、Google Docsは、500KB程のJavascriptのプログラムを使っている。しかし、そのソースコードは、Obfuscriptと呼ばれ、容量を節約する目的で圧縮されている。コメントなし、空白ほぼなし、メソッド名は一文字、といった具合だ。プログラムのソースコードというものは、簡単に改変できるべきなのだ。圧縮されたソースコードは、ソースコードと呼ぶべきものではない。つまり、本物のソースコードは、ユーザーには提供されていないのだ。
基本的にブラウザというものは、いつJavascriptがロードされたのか、ユーザーには知らせない。多くのブラウザで、Javascriptを無効にすることはできる。しかし、読み込んだJavascriptプログラムが、意匠を認められ得るもので、かつ非フリーであるかどうかを検証できるブラウザは存在しない。この問題に対処しようとしても、検証、拒否、にかかる手間は膨大だ。そもそも、フリーソフトウエア業界の中でも、ほぼすべてのユーザーは、この問題に気づいていない。ブラウザが何も言わないので、ユーザーは盲目になっているのだ。
Javascriptプログラムをフリーソフトウエアとしてリリースすることは可能である。つまり、ソースコードをフリーソフトウェアのライセンスで提供するのだ。しかしたとえ、プログラムのソースが提供されていたとしても、オリジナルの代わりに、独自の改変したコードを実行するのは難しい。現在のフリーなブラウザは、ネット上のページにおいて、ユーザー独自の改変版を代わりに実行する方法を提供していないからだ。これはTivoization（訳注：かつてTiVo社がGPLライセンスに関連して引き起こした問題、TiVo化 - Wikipediaを参照のこと）の問題によく似ている。ただ、Tivoizationよりは、解決が容易ではあるが。
Webサイトがユーザーに送りつけるプログラムの言語は、Javascriptだけではない。FlashはJavascriptの拡張版とも言うべき機能を提供している。Flashの問題を解決するには、さらなる考察が必要である。Silverlightも、Flashに似た問題がある。むしろもっとひどい。なにしろ、Microsoftは、Silverlightを使って、非フリーなコーデックを広めようとしているのだ。Silverlightに対抗できるフリーな実装は、フリーなコーデックなしでは使い物にならないだろう（訳注：このコーデックは、動画のデコーダーの意。そして、この場合のフリーとは、ソースコードはさることながら、規格がオープンかつフリーであることを意味するのだろう。しかし、FlashもVP6という、無料では使えるものの、非フリーな、ソースコードどころか規格すら提供されてないデコーダーを提供しているが、いいのだろうか。現在のffmpegが実装しているエンコーダー、デコーダーは、リバースエンジニアリングの結果の産物である。また、Flashはすでにそうであるし、Silverlightも近い将来、H.264をサポートする方向に動いている。H.264は今後しばらく動画圧縮形式の主流になると思われるが、H.264も特許の問題から、規格がフリーとはいいがたい。とすれば、MSにしろAdobeにしろ、フリーソフトウェア業界にとっての、「問題のひどさ」は変わらないと思われるのだが）
Javaアプレットもブラウザ上で動くので、似たような問題がある。一概にいって、アプレットという仕組み自体に、問題がある。勝手に実行させる環境は、問題が多すぎる。
Webサイトは、フリー（オープンと呼ぶ人もいるが）な規格とプロトコルのみを使うべきであるという、強い時代の流れがある。つまり、その規格が公開されていて、誰でもフリーに実装できるべきという意味である。しかし、Webサイト上にプログラムが存在するという事態がでてきては、もはやこの定義だけでは不十分である。Javascriptというものは、規格はフリーで、WebサイトでJavascriptを使うこと自体は悪くない。しかしながら、上記で述べたように、常に問題がないというわけでもない。Webサイトがユーザーにプログラムを送信する場合は、わかりやすく記述されていて、難読化されていないというだけでは、プログラムはフリーであるというには、不十分である。「フリーなプログラムしかユーザーに送信しない」と、Webサイト側で示されていなければならない。
暗黙のうちに読み込んで実行される、非フリーなプログラムとは、「Webアプリケーション」なるものが生み出したいくつかの問題のうちのひとつである。「Webアプリケーション」という用語は、ユーザー側に送られるソフトウェアと、サーバー側で実行中のソフトウェアという、従来の基本的な仕組みを覆すという意味で作られた。この用語は、ブラウザ上で実行されるクライアント側のプログラム、サーバー上で実行されるソフトウェア、サーバーとやりとりするクライアント上のソフトウェア、などを意味する。たとえ、クライアントとサーバーが強調して動作するために、ほとんどひとつのプログラムとみなしても良いような場合でさえ、依然、クライアントとサーバーでは、問題が異なる。この文書では、クライアント側のソフトウェアの問題を考察する。サーバー側の問題は、また別の文書で考察することにする。
現実的に、どうやってWebサイトで使われている、非フリーなJavascriptのプログラムの問題に対処すればいいのか？ 以下が提案である。
まず、意匠が認められ得る、Javascriptのプログラムに関する、表示（訳注：この語はcriterion、著作権表示、ライセンス表示などの、フリーかどうかの判断基準としての表示）が必要である。意匠の問題であるので、完璧なひとつの正しい答えよりは、簡単な表示（訳注：criterion）が欲しい。
提案としては、意匠が認められ得るJavascriptというのは、複数のメソッドが定義されていて、外部スクリプトを読み込む、あるいはそれ自体が外部スクリプトとして読み込まれている、AJAXリクエストを使う、である。
この文書の最後で、意匠が認められ得る、Webページ上のJavascriptプログラムの中で、ソースコードが置かれているURLと、そのライセンス表示を、書式化されたコメントで行う方法を提案している。（訳注：その部分、省略、原文を参照のこと）
最後に、フリーなブラウザは、Javascriptをユーザーの自由にできるようにする必要がある。何よりも、ブラウザは、意匠が認められ、かつ非フリーなJavascriptプログラムを実行する前に、ユーザーに知らせるべきである。NoScriptがこれをやってくれるかもしれない。
ブラウザのユーザーには、あるページに対して、独自のJavascriptを指定できる、簡単な手段が必要だ（指定するコードは、完全にページのコードを置き換えるものか、あるいはそのページのフリーなJavascriptプログラムを改変したものである） Greasefireは、もっともこれに近いことができるが、完璧ではない。なぜならば、ページ上のJavascriptのコードが実行される前に、絶対に書き換えてくれるという保証がない。ローカルプロキシを使えば可能だが、とても不便なので、現実的な解決策ではない。信頼でき、かつ簡単な解決方法を実装しなければならないとともに、Webサイト側も、変えていく必要がある。GNU プロジェクトは、フリーに改変できるWebサイトを推奨するものである。
これらの機能によって、Webページ上のJavascriptプログラムを、現実的な方法でフリーにできる。Javascriptは、我々の自由にとって、もはや障害ではなくなるのだ。まさに、CやJavaがそうであるように。非フリーなコードは拒否でき、さらにはフリーなコードに置き換えることもできる。まさに、非フリーなパッケージを置き換えられるように。Webサイトを自由にする、我々の運動は、今まさに始まろうとしているのだ。
いや、そんなこと言われましてもね、ストールマン導師。それは、規格上ソースが読める形で提供してあるだけで、著作権者はGPLのようなオープンソースライセンスでの配布を意図しているわけでもないし、ましてやフリーに改変していいことを意図しているわけでもないと思うんですけどね。そりゃ、オープンソースにしたい人はすればいいけれど、JavaScriptのコードの著作権は、やはり認められるわけで、著作権者がオープンソースを望んでいなければ、強いるべくもないと思うんですよ。
と思って読んでみたが、どうも上の批判は、少し的外れらしい。この導師は大真面目だからだ。というのも、向こうの立場に立って考えれば、フリーではないソフトウェアの実行を拒否したいという原理主義者の言で、GPLにあらずんばコードにあらず、非フリーなコードは一行たりとも動かさない、という思想を実現するための提案なのだから、その立場にたってみれば、当然といえば当然だ。しかし、もしストールマン導師が、非フリーなプログラムを完全に拒絶しているとすれば、いったいどんなサイトを見ているのであろうか。「このサイトの一切のHTML、Javascriptなどのソースコードは、これをGPLライセンスの元に提供す」などと公言しているサイトは、数えるほどしかないだろうし、わざわざ公言するサイトが増えるとも思われない。
実際、Javascriptは、単なるHTML拡張のためのおもちゃではなく、もう言語として万人の認めるレベルになっている。そして、Javascriptは、その仕組み上、ソースコードが明らかにされた状態で提供されるので、ライセンスを明確にしておくのは、合衆国アメリカでは、まあ、間違ってはいないと思う。ただ、日本の法律では、暗黙のうちに著作権が認められるので、何も明示しないと言うことは、たいていの場合、俺が著作権を持っているから勝手に使うな、というような意味であるが。
参考のため、訳して引用してみることにした。ライセンスは、Creative Commons Attribution-No Derivative Works 3.0 United States Licenseだが、正当な引用目的であるので、翻訳しても問題ないだろう。ただ、100%ストールマンの意図通りに訳せたかというと怪しいものだ。この文章の根底には、フリーなソフトウェアしか認めない、非フリーなソフトウェアは、俺の環境では絶対に実行したくない、という思想がある。他人の著作物に対しても、フリーにしろと強要するのは無理だから、せめて、俺の環境では、フリーなソフトウェアだけ走らせたいという思想だ。（なんだかさっきから何度も同じ事を書いているような気がする）
翻訳にかなり時間がかかった上、やはり原文を読んだ方がわかりやすいということには変わりはない。やれやれだ。見ての通り、結構、現実的だ。俺は非フリーなコードを認めない。だから、少なくとも俺の環境では、非フリーなコードを走らせたくない。だから、そのコードがフリーである場合は、一定の書式に従ってライセンス表示をしよう、という提案である。Javascriptの圧縮は、実際必要なのだから、本物のソースコードは、別の場所でもいいから、提供すると。GPLの思想によく似ている。唯一のツッコミどころといえば、SilverlightでMSをより悪いと叩いているところぐらいなものか。H.264も同じじゃないか。
しかし、このフリーなWebページという試みは成功するのだろうか。フリーなOSはある。フリーなコンパイラはある。フリーなソフトウェアもたくさんある。したがって、フリーではないソフトウェアを拒否すると言うことは、現実に可能だ。しかし、もはやほとんどのサイトが、意匠権を主張できるほどに、Javascriptを使っているだろうし、多くは、フリーにしたがらないだろう。フリーなWebページ以外否するということは、現実的に可能だろうか。誰かが、すべてのWebページのフリーなJavascriptの実装を書いてくれるという期待は無謀だと思うのだが。
追記：タイトル変更、翻訳した引用文を上に移動。
追記２：
常日頃思っているのだけれど、もし、全世界の個人で手軽に扱えるネットワークの帯域が、少なくとも現在のHDDの読み書き速度並になり、そのレイテンシも、十分短くなれば（光の速度は超えられないが）、サーバーとクライアントの垣根は、ほとんどなくなってしまうのではないだろうか。そういう新時代においては、GPLコードを利用したサービスをサーバー上で提供して、ユーザーで実行するクライアントのプログラムは、単にデータをサーバーに送り、結果を受け取るだけの、単純なプログラムになる。このようにすれば、たとえGPLコードを利用しているといえども、ソースコードをフリー化を回避できるのではないだろうか。なぜならば、GPLのコードはサーバー側で動いているに過ぎないのだから。ストールマン導師は、あれでいて、自分の思想の枠内では現実的だから、現代の常識でGPLライセンスのデザインをするにきまっているが、もし将来、現在の常識が通用しなくなった場合、どうなるのだろう。
BallDroppings
これは左端から球が落ちてくるものを、線を引いて跳ね返らせ、音楽を奏でるというものだ。実に面白い。
Ball Pool
これは大量のボールが動き回るサイトだ。ボールをドラッグすると動かすことができるし、マウスをドラッグすると、大量のボールが現れる。しかも、ブラウザのウインドウ自体を動かすと、ボールも動く。
Monster
これは、JavaScriptで3Dアニメーションを実現しているらしい。
Visited links from normal browsing are no longer being displayed as visited (i.e. purple) in incognito mode.
シークレットウインドウでは、閲覧済みのリンクは、閲覧済みと表示されないようにした。
なかなか面白い。この問題は、もちろん、現在のブラウザの欠陥でもある。というのも、あるURLを閲覧済みかどうかを、CSSなどを使えば簡単に判断できてしまう。これは個人情報保護の観点からみて好ましくない。たとえば、2ch.netのリンクが閲覧済みであれば、にちゃんねらーであると分かるし、それに合わせた広告を表示できる。ユーザーには、自分の閲覧履歴が盗み見られていることが、そう簡単には分からない。
参考：
行動ターゲティング広告の暴走を止められるか
http://it.nikkei.co.jp/internet/news/index.aspx?n=MMITbe000015102008
ドリコムが作って楽天やライブドアが使ってる行動ターゲティング広告のカラクリ
いま、IE8を使ってこのブログを書いているが、とにかく遅い。めちゃくちゃ遅い。このブログを表示させるのがとても遅い。しかも、このブログを読み込んでいる間は、ウインドウ自体の応答がなくなるという始末。Flashのプラグインを無効にしても応答がなくなるのは変わらない。だめだこりゃ。
そして、display : inline-blockへの対応を確かめようと、このブログを一分ぐらい待って表示させてみたが、うまく動いていない。なぜだと思ったら、すべてのサイトを互換表示していた。しかも、互換表示を切り替えるボタンが表示されない。なんだこりゃと、再起動させてみたら、互換表示のボタンが表示された。
とにかく遅い。ページを読み込んでいる間は応答がなくなり、他のタブも操作できなくなる。とても使いづらい。
なお、ここから、ブラウザをChromeに切り替えた。一挙動がいちいちもたつくIE8を使うのは苦痛でしかない。
ところで、検索エンジンのクエリ用のURLを手動で書き換える方法がブラウザ上から提供されていない。糞だ。
現状の規格を読むに、どう考えてもUser Defined-Literalsは、グローバル名前空間では使えないように読める。しかし、ペーパーでは、予約語に関しては何にも触れられていないような気がする。
たとえば、n2747でも、既存の文法やCとの互換性、今後の言語の発展とどう折り合いをつけるのかしか考えられていない。どうも、誰も、アンダースコアで始まる、名前の予約の問題を考えていないのではないだろうか。実際、グローバル名前空間でオーバーロード関数の定義ができないというの仕様は、どう考えてもおかしい。いったいどうなっているのだろう。さっぱり分からない。
網野善彦の書いた、日本の歴史を読み直すという本を読んだ。さて、今の学校歴史教科書は、全部燃やす必要があるな。
いわゆる歴史教科書は、日本は農民国家だったと教える。なぜならば、当時の人を職業別に分類してみると、実に76.4%が農民であり、円グラフにすると一目瞭然であるなどと言っている。でも、その分類はそもそもどうなんだと、この本の筆者は言う。
というのも、当時、土地を持たない人はすべて、水呑百姓に分類されている。しかし実際には、そういう人たちは、土地を持たなくてもいい人達だった。たとえば、教科書は廻船の挿絵を載せたりしているけれど、いったい誰がその船を持っていたかというと、水呑と呼ばれる人たちであった。そういう人たちが何百両も用立てしたという記録まで残っている。そもそも、百姓という言葉には、農民という意味はない。云々。
なぜ、日本は農民ばっかりであったかというイメージがあるかというと、儒教などの中国からやってきた統治思想によるのだとか。当時の政府は、海民にまで、水田を割り振ろうとしていたらしい。また、小島や山奥の田舎は、水呑ばかりで貧しかったのだという従来のイメージは間違っているという。というのも、彼らは観光、製鉄、塩など多彩な生産をしており、それを銭に変えて、米を買っていたのだという。また、飢饉というのが何故起きたかというと、そもそも農民以外で暮らしている人が多かったからだという。彼らは銭で食料を買っていたので、物価が上がると飢えたわけだ。そもそも、戦中戦後を考えても、農民自体は飢えていないではないか。
なかなか面白い本だ。
Microsoft Announces Availability of Internet Explorer 8
ずいぶん急な発表とリリースだな。まあ、もうIE8はほぼできてたし、最終リリース版のバイナリもビルドされていたとか言われていたから、驚きでもないんだが。
日本時間では、明日あたりになるはず。http://www.microsoft.com/ie8で、二十五カ国語同時リリースされる。
しかし、この手のニュースの取り扱いも、実に小さくなったものだ。まあ、いまさらIEじゃなぁ。どうせthose dumbassは未だにIE6を使い続けるだろうし。
思うに、自分は今まで、ユーザー定義リテラルのネガティブな面しか考えていなかったように思う。そこで、ポジティブな面について、考察してみることにした。まず、ユーザー定義リテラルは、単なるシンタックスシュガーであって、パフォーマンス上の利点はない。では、いったいどのように使えば、文法上の利点を得られるのか。
class gram ;
gram operator "" _g(unsigned long long int) ;
gram operator "" _kg(unsigned long long int) ;
gram operator "" _pond(unsigned long long int) ;
gram operator "" _kan(unsigned long long int) ;
void f()
{
// ユーザー定義リテラルを使うと、とてもすっきり。
auto weight = 643_g + 3_kg + 4451_pond + 320_kan ;
// ユーザー定義リテラルがない場合の、実現可能な文法。なんだか読みづらい。
// auto weight = g(633) + kg(3) + pond(4451) + kan(320) ;
}
オーケー、これはクールだ。このようなコードならば、ユーザー定義リテラルも使ってみたくなると言うものだ。
しかし、アンダースコアから始まらなければならないという制限はどうしたものか。どうやって解決すればいいのだろう。ダブルアンダースコア、あるいは、アンダースコアに大文字で始まる名前は予約されている。アンダースコアで始まる名前は、グローバル名前空間において予約されている。このままでは、グローバル名前空間にユーザー定義リテラルのオーバーロード関数を定義することは出来ない。従って、クラス内か、何らかの名前空間の中で定義しなければならないのだが、クラス内はともかくとして、具体的な名前空間の中でしか定義できないのは苦痛である。第一、どうやって使うのだ。
またもし、グローバル名前空間に定義できたとしても、名前の衝突をどうやって避ければいいのか。上記の例に挙げたような、SI単位などの有名な名前は、みんな使いたがるはずだ。それに、この文法の性質上、みんな数文字程度の短い名前を使うに決まっている。長ったらしい名前など使いたがるわけがない。従って、複数のライブラリで名前が衝突すると言うことが、実際に起こりうる。それに、みんなアンダースコアひとつという一番簡単な名前は、自分が使いたいはずだ。
これを延々と考えていたが、ついに以下のような結論に達した。規格は正しい。つまり、ユーザー定義リテラルは、グローバル名前空間に定義してはいけないのだ、という事だ。規格の定義より明らかに、何らかの名前空間の中に定義しなければならない。では、どうやって実際に使うのか。それは、using directiveを使うのだ。
namespace SI {
class gram ;
gram operator "" _g(unsigned long long int) ;
}
void f()
{
using namespace SI ;
gram weight = 100_g ;
}
うれしいことに、こうすれば、名前の衝突と、名前の予約の問題を、同時に回避できる。名前の衝突は、その関数内だけを考えればよく、名前の予約の問題も、その関数の中だけで、グローバル名前空間には影響を及ぼさないので、問題はない。
規格を読む限り、well-formedにするには、こうするしかないと思われる。このことは一切説明されてはいないのだけれど。
追記：
using namespace hogehogeとやるほうが、using directiveであり、それではない方は、using declarationであった。名称を逆に覚えていたらしい。
なに、ナザレのイエス。ああ、そういや、そないなやつもおったな。昔の話やけどな。何でも自分のことを、油ぶっかけられた者、とか言うてはったわ。ほれ、あん時は世の中がいろいろ狂っとったやろ。そいでああいう手合も出てきたっちゅうわけや。よう分からんけどな。ほれ、よく言うやろ。水の上歩いたはったとか、病気治したはったとか、まあ、いわゆる奇跡っちゅうやつやな。そないな噂聞いたもんやから、ほな、一発、見たったろかあと。まあ、ワシそう思うたわけやな。そいでワシ、ある夜、行ってみたんや。なに、どこかて、イエスさんとこに決まっとるがな。
で、行ったらな。おでっさん、ぎょうさんおんねん。ワシてっきり、何や変な趣味でもあるんやないかと思たわ。いやどう考えたかて変やろ、あんなにぎょうさんおるんは。で、ワシうっかり聞いてしもたんや。なにかて、その趣味をや。そしたらやな、「おまへん、センセはそないな人とちゃいます」、言うて、えらいけんまくで怒りよるねん。しもたわあ、聞かなよかったわあ、思てな。はあ、えろうすんまへん言うて、ともかく会わしてもろうたわけやな。
で、イエスさんに会うたわけやけどな。いやあ、これがまた、えらいやさ男やねん。ワシあんだけいろいろ奇跡起こしてんねやから、そらもうどんだけすごい男や思うてたら、えらいやさ男やねん。やっぱりワシ、変な趣味あるんやないかと思たわ。今度は言わへんかったけどな。いや、さすがに言えへんで、本人の前ではな。そらセンセも気い悪うしよるがな。ワシ言えへんでそんなの。で、ワシその時思うたんやけどな。こないな男でも奇跡起こせるのにな、なんでワシ、なんも起こせへんねん思たんや。何でも聞くところによると、ただの水を酒に変えたそうやないか。ワシもそないな奇跡欲しいわあ、ホンマ。そないな奇跡あったら、一生、カネに困らへんやないけ。水なんてナンボでもあるし、それ酒に変えて売ればいいんやから。そやろ。そら欲しいわそないな奇跡。ナハハハ。なんでそないな奇跡起こせるのに、お布施集めてたんやろな。ワシ、アホやさかい分からへんわ。ナハハハハ。
で、ワシ言うたんや。「いやセンセ、神さんのこと教えてえな。なんせ神さんでもおらんかぎり、センセみたいな奇跡でけへんやないか」、言うたんや。そしたらやな、センセ、よっしゃよっしゃ言うて、こう言いよるねん。ん、いや、ホンマによっしゃよっしゃ言うねん。何なんやろな。よっしゃいう言葉、好きなんやろか。よう分からんけどな。ともかくな、こう言うねん。「よっしゃよっしゃ。言うとくけどな。も一度生まれへん限り、王の宮は見れへんねやで」、言うねん。ワシわけ分からんでな。いや、そりゃ分からへんやろ。何やねん、も一度生まれるて。王の宮っちゅうのは分かるんやけどな。きっとゼニがたくさんあるんやで。そらそうやろ。ゼニもなくて何が王の宮やねん。
で、ワシわけ分からへんかったから言うたんや。「センセ、も一度生まれるて何です。母ちゃんのお腹ん中戻るんか」、て。そしたらセンセ、「よっしゃよっしゃ。言うとくけどな。水と霊によって生まれへん限り、王の宮は見れへんねやで」、ところで霊って何やねん。スピリッツならワシも嫌いやないねんけどな。そいでやな、「肉から生まれたんは肉やで、霊から生まれたんは霊やで。そんなびっくりせんとき。も一度生まれへん限り、王の宮は見れへんねやで」。またや、おんなじ事の繰り返しやないか。ええ加減にせえよ、ええ加減に。で、こうも言うねん。「あんな、風が吹くやろ。風が吹いたんは聞こえるけど、どっから吹いて、どこへ行くかは、分からへんやろ。霊から生まれたんも同じやで」、言うねん。もうわけ分からへんわ。風吹くんのと、霊から生まれるのと、何の関係があんねん。それより桶屋の儲かる方がよっぽどマシやわ。なんせ儲かるんやからな。そらマシやわ。ついでに言うとな。風がどこから吹いてどこに行くかを調べんのは、簡単な話やで。人をやな、こう、ぽつんぽつんと、前後左右、等間隔に並べるんやな。恐ろしい広い範囲でやで。そしたら風がどこから吹いて、どこで消えたかぐらいわかるがな。人をそれだけぎょうさん使うのは、まあ、カネもかかるし難しい話なんやけどな、決して出来ん話やない。そやろ。で、仮にやな、風吹くんが分からへんから、霊から生まれるんも分からへんいうんならな。ほれ、もう風吹くんは分かったやないか。人並べればいいんやから。霊はどないやねん。なんで分からへんねん。おかしいやないけ。土台、間違うとるわ。
で、ワシ言うたったんや。「さっぱり分かりまへんわ」、て。そしたらセンセ、言いよるねん。「あんさんイスラエルのあるじちゃいますん。なんでこないなことも分からへんねや。よっしゃよっしゃ。言うとくけどな。ワシら分かりきったこと、見たこと言うてるんやで。何で信じへんねや」
あとはみんなお決まりのセリフやわ。ワシは神の子やで、ワシを信じたら救われるで、信じなかったら地獄行きやで、ちゅうようなことや。それをなんべんも言うんや。言い回しはちいとばかし違てるんやけどな。それ延々と聞いてたらやな、ワシもそのうち信じたくなってきたわ。危ないところやったな。そら神さんの子ならワシも信じたいけどな。そもそも、あのセンセが神の子っちゅう証拠は、ひとつも言わへんねん。あんたらも、あの手の話に騙されたらあかんでホンマ。まあでもな、面白いセンセやったから、何も殺すことはなかったと思うんやけどな。惜しいわあ、ホンマ。
ヨハンによる福音書、King James Version より、心の内に浮かびしままに書ける。ユダヤ人には関西弁がよく似合うと思うのは余ひとりのみであろうか。それにしても、これほど奇妙な書を、真面目に研究している奴らはいったい何なのだろう。
公明党がアナログテレビを二万円で買い取る「経済対策」を打ち出したんだとか。公明党らしいといってしまえばそれまでだが、あほらしいにもほどがある。お題目でもあげてろ。
ああ、巨大浣腸とウンコサンドイッチのどちらがいいかという問題は難しい。
今現在、最新のFlash Playerのバージョンは、10.0.22.87である。これは先月の24日にアップデートされている。セキュリティホールをふさぐアップデートだ。アップデートされた日から三週間ほどたっているのに、Google Analyticsによれば、このブログを閲覧している人のうち、20%しか最新版のFlash Playerを使っていない。これは憂うべき事態である。なぜFlash Playerのアップデートはこれほどおろそかにされているのか。
これをみている八割方の人は、今すぐFlashのアップデートすることをおすすめする。また、Adobe Readerも、11日にセキュリティ上のアップデートがあった。また、先週は、月の二週目なので、Windowsの月例アップデートがあった。それから、今月の4日には、Firefoxも3.0.7に、セキュリティ上のアップデートがあった。ちゃんとアップデートしていただろうか。
仕事をどうしようかな。いい加減に働かないといけないが。
少なくとも今やっているのは、プログラマのすることではないな。ペーパーとドラフトを読むばかり。
素直に大学にでも行って英語を学んでいるべきだったんだろうか。とはいっても、当時のごたごたな状況じゃ、進学するにしてもどこに行くんだという話だったし、今更言っても始まらない。
やんぬるかな。
現在の心境
ユーザー定義リテラルは以下のように定義、使うことが出来る
KiloMeter operator "" _km ( const char*, std::size_t ) {/*実装*/}
auto TimeMachine = "141.622272"_km ; //OK
auto marathon = 42.195_km ; //OK 文字列にされて渡される。
さて、頭を悩ます不思議な定義がある。ドラフト規格の17.6.4.3 Reserved namesによれば、
17.6.4.3.3 Global names [global.names]
1 Certain sets of names and function signatures are always reserved to the implementation:
— Each name that contains a double underscore _ _ or begins with an underscore followed by an uppercase
letter (2.11) is reserved to the implementation for any use. — Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.175ダブルアンダースコア、もしくは、アンダースコアに続いて大文字で始まる名前は、いかなる目的においても、処理系用に予約されている。
アンダースコアで始まる名前は、グローバル名前空間において、予約されている。
では、上記の例は間違いではないかというと、そうではない。というのも、
17.6.4.3.6 User-defined literal suffixes [usrlit.suffix]
1 Literal suffix identifiers that do not start with an underscore are reserved for future standardization.リテラル後置識別子のうち、アンダースコアで始まらないものは、将来の標準化のために予約されている。
アンダースコア以外を認めてしまうと、たとえば、0L、とか、0xff、などといった「ユーザー定義リテラル」が定義できてしまい、確かに問題だ。しかし、ユーザー定義リテラルのオーバーロードを定義する文法は、13.5.8 User-defined literalsに定義されているが、やはり普通の識別子である。ということは、17.6.4.3.3 Global namesで定義されている予約語の制限を受ける。しかし、同時に、17.6.4.3.6 User-defined literal suffixes で定義されているように、アンダースコアで始まらなければならない。これはいったいどうすればいいのだろう。
まず、ダブルアンダースコアで始まるものは論外である。アンダースコアに大文字で始まってもいけない。これはいいのだが、アンダースコアで始まるすべての名前は、グローバル名前空間で予約されている。では、何らかの名前空間の中でオーバーロードを定義しなければならないのだろうか。しかし、引数は組み込み型なので、ADLなど働くはずがない。名前の示すとおり、引数に依存した名前解決なのだから。ということは、ユーザー定義リテラルを使うのは、その定義された名前空間の中や、あるいはクラス内でなければならないのだろうか。つまり、グローバル名前空間では使えないのだろうか。
あるいは、予約されてるだけで、使うことは出来るんだ。だからGo ahead。気にするな。ということなんだろうか。それはないと思いたいが。
Aaron Greenspan: Why I Sued Google (and Won)
"But it's not fair!" Google's paralegal protested. "What if everyone whose account was canceled sued Google?"
そりゃ、今まで払ってこなかったツケに過ぎないな。規約は法律を超えることは出来ない。そして有人サポートがないというのはひどい話だ。
実際のところ、この訴えた男は、たんに広告満載の糞サイトを運営していただけだとか、単なる一社員の個人の電話にかけるのはいいのかとか、法廷で黙れと言われた後に目の色がどうこう言ってGoogle社員を侮辱している奴だ、とかいう声も上がっているが、まあそれにしてもGoogleには分が悪かった。なにせアカウント停止は人間がやったわけではないだろうし、どうしようもない。
http://www.southparkstudios.com/episodes/220683
Oh my GOD! this is fucking awesome. it's kenny! and whore bitch. and disney's stupid mouse. and of course kenny will be dead again.
You think god is in controll here? haha. I AM in controll I'm ???? in controll since 50s!
It looks like they replace episode with uncensored audio. That means stupid mouse speaks like fucking bad.
あるとき、ヨハン・ファウストは、大勢の客を招待したが、何の準備もしなかった。さて、客が集まってから、悪魔達を呼んで、どのくらい速く料理が出来るかと訊ねた。
一人目の悪魔が答えた。「私は矢のように早く料理を用意できます」と。
負けじと二人目が答える。「私は風のように早く用意できます」と。
しかし、ファウストは三人目の悪魔に料理を言いつけた。その悪魔は次のように答えた。
「思想のように早い」と。
昔のファウスト伝説というのは、思想が一番早いと言うことで満足していたのだが、後に、もっと早い物が出てきた。そのはじめとなったのはレッシングで、その未公開のファウストにおいて、善から悪に変わるように早いという表現を使ったらしい。
Windows 7 Won't Save Hybrid Hard Drives - Lab Notes by ExtremeTech
2007年頃に、ハイブリッドHDDというものが期待されていた。これは、通常のHDDと、数百MBから数GBのフラッシュメモリを組み合わせたもので、両方のいいとこ取りを狙ったものだ。つまり、HDDの大容量性と、フラッシュメモリのランダムアクセスの早さを組み合わせようというアイディアだった。パフォーマンスの他にも、省電力性も期待されていた。なぜならば、常にディスクを物理的に回転させなくてもいいので、電力が節約できるというわけだ。（追記：フラッシュメモリ内のキャッシュにヒットすれば、ディスクを回さなくてもいい）
ところが、現実はそううまくはいかなかった。まず、高価な割には、パフォーマンスもそれほど上がらず、消費電力も、下がるどころか上がってしまった。なぜならば、フラッシュメモリとHDDの両方を動かさなければならなかったからだ。そして、現在、数百GBのSSDが大量に出回っていることも、ハイブリッドHDDの必要性を微塵も感じさせない。もちろん、当時は、こんなにも早く大容量のSSDが普及するとは、思っても見なかったわけだが。
まあ何にせよ、ハイブリッドHDDは死んだ。RIP（安らかに眠れ）
世論調査（せろんちょうさ）とは、主としてマスコミ各社により創作される、数字や割合を扱うことをテーマにした芸術かつ美術の範疇に入る作品群、またはその様式である。
やはりuncyclopediaは実にすばらしい百科事典だ。
神保町で森鴎外全集が捨て値で投げ売られていたので、何冊か買ってきた。今は書簡を読んでいる。
しかし、候文は実に奇妙だ。谷口大勉強之由喜敷奉存候（たにぐちだいべんきょうのよしよろこばしくぞんじたてまつりさうろふ）、とか、旧來之親友ノ如ク思フ人モ有之候得共決シテ不然（きゅうらいのしんゆうのごとくおもふひともこれありさうらえどもけしてしからず）。漢語ではないし、日本語でもないし。
＜ゼロゼロ物件＞ 敷金礼金がゼロの賃貸物件。非正規労働者や外国人が多く入居している。賃貸契約ではなく部屋のカギの利用契約という形をとり、家賃振り込みが遅れると居住者への違約金請求やカギの無断交換、荷物撤去を行う業者があり問題化した。入居時に連帯保証人を立てられない人が契約する家賃債務保証会社が、家賃滞納者を追い出す行為も問題化。国土交通省は保証会社が全国に約１００社あるとみているが実数は不明。
あくまで鍵の使用権であって、部屋の使用権ではないので、賃貸に関わる法律はスルーできるというのが、連中の言い分らしい。鍵の先にある部屋は無断かつ無料で使っていいらしい。つまり、二十年住み続けたら、時効で自分の物にできるのだろう。ひとたび自分の物になったら、自分の部屋についている鍵は、とってもかまわないだろう。何しろ部屋が自分の物なのだから。なんて良心的なところなんだ！
世の中には変なことを考える人がいるものだ。
英語の否定疑問文に対する応答では、質問の内容に関する肯定否定ではなく、その質問の文が、positiveかnegativeかで、yesとnoを使う。これが、日本人の感覚には合わない。
では、ネイティブなら感覚通りなのかというと、どうもそうでもないらしい。そういうものとして決まっているというだけの話で、やはり混乱するらしい。特に、論理的には、質問に対しての肯定否定の方が、理にかなっているはずだ。
どうやら、これは元々そうであったわけではなく、歴史的な理由らしい。かつて、英語には四つの肯定否定の言葉があった。yea, nay, yes, no である。前者二つは、肯定疑問文に対する応答の肯定否定に用いられ、後者二つは、否定疑問文の肯定否定に対して用いられた。自然言語の常として、それが、いつのまにか、二つに減ってしまった。意味が重複していただめだろう。ただし、当時の名残で、肯定文と否定文に対する区別は残った。その結果が、現在の不思議で非論理的な受け答えになっているらしい。
Thousands in scramble for free books after Amazon supplier abandons warehouse | Mail Online
これは天国に違いない。
扱いが雑だとか、図書館やチャリティに寄付すべきだとかいうコメントがついているが、無粋なことだ。本の価値はその内容にあり、読める状態であれば、価値は変わらない。