腐れ縁と１０代目は永遠に

歌舞伎とウィンドウズOSの意外な共通点とは？
http://diamond.jp/articles/-/95552

歌舞伎役者の襲名についてWindowsで例える、元マイクロソフト日本法人社長。

おくだ では、こう考えたらいいと思います。「五代目中村勘九郎は、十八代目中村勘三郎に“バージョンアップ”した」と。
成毛 つまり、Windows 98がWindows 98SEになるようなものだということですか。
おくだ その役者個人の歴史で言えば、キャリアや年齢に応じて演技の幅やスケールが大きくなり、それに見合った芸名に変わっていくのは、バージョンアップと言えますよね。

10でナンバリングが止まる予定のWindowsで例えられると、すごくそわそわしますの。

OSと歌舞伎をくっつけるならMacがいいですの。

次世代OSを目指してCoplandを作っていたのが頓挫して、OS7の次どうしよう…となり、買収したNeXTSTEPをベースにOSXを作ることに決定。Coplandから使えそうなところを集めてOS8を作り、OSXとの橋渡しとしてOS9を作ったところで、ついにMacOS直系の時代は終わり、OSXへとバトンタッチ…という流れに継承・襲名感をものすごく感じますの。

Windowsも、95の直系がMeで終わって、NT系列から伸びてきた2000にバトンタッチするとか、セキュリティ的に弱いWinAPIを置き換えるべく作っていたWinFXが、置き換えまでは行けずに.NET Frameworkとして未だ共存しているとか、血脈感ではむしろ負けてないのですけど、、

やっぱりMacのほう、Appleを追放されたジョブズがヨソで作ったのがNeXTSTEP、というのがポイント高いですの。実力はあるけど、素行に問題がありすぎて追い出された家元が、一家の危機に見知らぬ青年（息子）を連れて帰って来たみたいな、古き良きお家騒動感がたまらないですの。

あれ？
そういえばWindowsがというか、むしろMacこそOSXでナンバリング止まってるきがしますの。もしかして、Windowsが9を飛ばして10にして、それを最終バージョンにしたのって…

ジョブズが亡くなる少し前にビル・ゲイツが訪ねてきたらしいけど、そこで、まあ昔は色々あったよね、なんて雑談の中でぽろっと出た「ナンバリングのジョーク」を、律儀にビル・ゲイツが実行した…なんて真相だったら素敵だなぁって思いましたの。

さりげなくクライアントサーバモデルでスキンシップ

男子「頭ポンポンでさりげなくスキンシップ」→女子からしたら一番アウトだったりする事は義務教育でちゃんと教えてほしかった
http://togetter.com/li/979728

ものすごく長いけど、個人的には問題はクライアントサーバモデルのせいだと思いますの。

男性から女性に何かアプローチして返事や反応をもらうことは出来るけれど、その逆は出来ないとしたとき、それは男性がクライアント、女性をサーバとしたクライアントサーバモデルであると考えることが出来ますの。

クライアント・サーバ間で通信を行うときの特徴は、いま書いたとおり、サーバからクライアントに情報のリクエストが出来ない、ということですの。

では、その制限の下でサーバからクライアントに情報を送るにはどうしたら良いかというと、わらわが知っているのは次の３つくらいですの。（基本的にWebの話）

　１．定期的にリクエスト（ポーリング）
　２．Comet（ロングポーリング）
　３．WebSocket（軽量プロトコルでの常時接続）

１は、ある種の「御用聞き」のようなもので、クライアントがサーバに対して「なにかありませんか？」とちょくちょく聞きにいくというものですの。
クライアントは何度も聞きに行かなければいけない上に、サーバ側もいざ用事があった場合も次に来てくれるまで待つ必要があり、リアルタイムには情報が送れない欠点がありますの。

２は、御用聞きの変形で、「なにかあったら言ってくださいねー」と、相手の前で待つというものですの。
用事があったときにすぐに伝わるのはいいけれど、ずっと目の前にいられるのはお互いに負担が大きいという欠点がありますの。

３は、直接いくのは大変なので、SNSで連絡取れるようにして帰ってくるというものですの。
リアルタイムで負担も少なくていい方法だけれど、古いクライアントだと対応してない欠点がありますの。

この３つの方法をクライアントが取り、それをサーバが迷惑に感じた場合、それぞれ次のように言い換えることが出来ますの。

１．セクハラ
２．ストーカー
３．パワハラ

ただ本来、クライアントサーバモデルを採用している以上、サーバがクライアントにアクセスしたいと思っている可能性が０でないかぎりは、構造的に、クライアントはサーバにリクエストを送り続けざるを得ないのですの。

これを防ぐためには、ファイアウォールでリクエストそのものを弾いてしまうか、クライアントサーバからP2Pに移行する必要がありますの。

P2Pであれば、旧クライアントは「相手のリクエストのためのリクエスト」を送る必要がなくなって省力化できるし、旧サーバにとっても、迷惑なクライアントからのリクエストを激減させられることになりますの。


一方で、「そうではなく、頭ポンポンは通信プロトコルの選択が不適切であるという問題だ」というのも当然ある話だと思いますの。

ただこれも、サーバ側の希望プロトコルをクライアントが知りようが無いのであれば、クライアントとしては「とりあえず知ってるプロトコルで投げる」とか、それでダメなら「ポートスキャンして、とりあえず反応が返ってきたポートに投げる」という以上のことは出来ないはずですの。

これはサーバ側の不備であり、その原因の一つとして、正解のプロコトルが公開されていない場合のアクセスの困難さを、その周知責任を持っている側が知ることが難しいということがあると思いますの。

P2Pであれば、お互いがサーバでありクライアントとなるので、アクセスする苦労も、される苦労も互いに共有することが出来て、結果として誤った通信プロトコルが使われることも自然と減っていくと思うのですの。

次長すてき

「だまってトイレをつまらせろ」？――朝日新聞政治部次長の奇妙なコラム
http://blogos.com/article/165015/

また朝日新聞がやってしまったのかとおもったら。
これは、BLOGOSの人の反論のほうが勉強不足かなと思いますの。


まず、元のトイレの話についていえば、
トイレを維持管理する責任は会社にあるので、トイレが壊れて困るのは会社ですの。

その上で、  
ちり紙の用意について、経営者が取れる合理的な選択肢は２つ。

【ちり紙と修理費のどちらを取るかのトレードオフ】
　A：ちり紙をきちんと完備して、使ってもらうことで、トイレの修理費を減らす
　B：想定外の紙を使われてトイレの修理費が増えることを覚悟で、ちり紙を用意しない

普通はAを選ぶと思いますの。
でも、特殊な状況で、ちり紙のコストがトイレの修理費より高くつくのなら、Bだってまあ、ありですの。(*1)

でも、頭の悪い経営者がよく選んでしまう非合理的な選択肢が、Cですの。
たぶん、例題の会社が選んだのもこれ。

【ちり紙と修理費を両方取ろうとする（善意からの搾取）】
　C：ちり紙は用意しないが、使う人がまともな紙を使ってくれるのでトイレの修理費は増えない


要するに、虫がよすぎるというか。
トレードオフの関係にあるものを両方取ろうとするのは、無理と言うものですの。

新聞紙を代わりに使ってトイレを詰まらせるのを悪だと言う人は、いつかこういう選択をしてしまわないように気をつけて欲しいですの。
そもそもの原因は、経営者がちり紙コストを従業員に押し付けたことにあって、従業員が「紙が無かったから適当なものを使った」というのは、十分に合理的な行動だからですの。


また、この話を会社と従業員の世界だけでなく、一般の話に広げるとどうなるかと言えば、

秩序によって多くの恩恵を受けている人が…言い換えれば、秩序が崩れるととても困る人たちが、そうでない人に向かって善意による無償の秩序維持を期待するのは馬鹿げている。

という話ですの。

富や権力を握っている人と、そうでない人の関係はもちろん、
もっと細かいところでも、

ものすごく重要な仕事をしてるのに冷遇されてる人とか、家のこと何も出来ない旦那に威張り散らされる奥さんとか、そういうのは一度、ぽーんと長い有給をとったり、実家に帰ってしまえばいいと。

そうすると、もちろん仕事は回らなくなるし、旦那も途方に暮れるかもしれないけれど、気にする道理はないですの。それは向こうが自分でなんとかすべきことだから。大事にされているならともかく、喧嘩を売ってきた相手に対して、いつまでも親切・従順なコマでいる必要はないですの。

それが「だまってトイレをつまらせろ。ぼくらはみんな生きている。」ということだと思いますの。


P.S.
BLOGOSのページ、さすがに批判のコメントがいっぱいついてますのー。と思ってコメント欄ひらいたら、賛成意見だらけで吹きましたの。
どちらかというと炎上してるイメージだったので、すごくびっくり。


*1)
ちり紙の価格が異様に高いとか、近所にトイレ修理が趣味のおじさんがいっぱい住んでて、いつでもすぐ無料で直してくれるとか

表紙のおっさんのすべてを知り尽くしたいあなたに

プログラマのためのSQL 第4版 を買ってみましたの。

でも、中身を読む前に解決しないといけない問題があるのですの。
それがタイトルのこれ。

（監修・翻訳の方のページ）
[SQL]新著が出ます：ジョー・セルコ『プログラマのためのSQL 第4版』
http://d.hatena.ne.jp/mickmack/20130519/1368931267

あらかじめ言っておきますが「表紙のおっさん誰？」という質問は私にはしないように。私も答えられないので（笑）。

（査読されたらしい方のページ）
これは英訳したいセルコの最新刊！−−「プログラマのためのSQL第４版」
http://sakaik.hateblo.jp/entry/20130519/celko4ja

「表紙のおっさん」は、ガリレオさんじゃないんですかね。おひげとおでこの感じが特に(笑)。

聞かないで、って言われるとなんだか気になるのですの。
それで探したのですけど、どうやら表紙の絵は、

コロンビア国立博物館：パドヴァ大学で理論を説くガリレオ
https://www.google.com/culturalinstitute/u/0/asset-viewer/galileo-demonstrating-the-new-astronomical-theories-at-the-university-of-padua/HQGamkQZzU7VVg?hl=en

この絵からの切り抜きのようですの。つまりガリレオで正解。

切り抜かれた表紙の状態だと、なんとなく、幼稚園か小学校の授業くらいの距離感を想像してたのですけど、元絵だと相手が近すぎて吹きましたの。

あと表紙の絵にも相手の人の手がちょっと入ってますの。元絵を見てないとこれが手だとはわからないと思うので、ちょっと得した気分ですの。なにそれ。

重そうな本を前に、表紙でこんなに遊んでていいのかしら。

擬人化の出来がよすぎて

それ系で、まさか泣かされるとは思わなかったですの。

Java、C++、Python…プログラミング言語擬人化計画！
http://next.rikunabi.com/tech_souken/entry/ct_s03600p002412
(Web魚拓)

C++お姉さんが多彩とか、C#が成長著しい幼女とか…
と書くと、よくある擬人化みたいだけど、PHPだけ人間じゃないみたいなのをはじめ、言語の雰囲気や歴史、使ってる人のタイプまで鋭く表現されてて凄いですの。

特にRubyは衝撃的で、あの言語の妙な愛でられ方に感じてた違和感が、一気にすーっと消えましたの。もう…パパはRubyに甘いんだから的な優しい世界。こんなにも理解を助けるイラストは偉大だと思ったのですの。


読んでもないのに比較に出すのはひどいけど、
本探しの最中、「擬人化でまなぼ！ネットワークのしくみ」のレビューで、

また、擬人化キャラがMPEGやJPEGとしての特別な特徴があるわけでなく、ネクタイに誰が何を表しているかだけなので、正直擬人化しているメリットがわからない

こういう指摘があったのを見てたので、やっぱり理解を助けるほどの擬人化って簡単じゃ無いんだろうなって思いますの。


で、結局なにに泣かされたのかと言うと、もちろんJavaScriptですの。

言われてみればたしかに、JavaScriptほど戦火に翻弄されてきた言語も無いですの。ほかの言語は競争こそあれ、いちど自分が設置された家は安全地帯でしたの。でも、JavaScriptの実行環境はブラウザ。

そのブラウザっていうのはまさに、代を変え、相手を変えながら、延々と戦争してる紛争地域。そのせいで特に昔のJavaScriptは、基本的な命令すらブラウザ同士で互換性が無いような悲惨な状態だったそうですの。

もちろんプログラマにも恨まれるし、それはちょっと変わった子になるのもしょうがないですの。

なんかこだわりの強いオブジェクト指向だったり、関数型言語みたいだったりするのもしょうがないですの。とか思ったら、泣いていましたの。


実際のところ、そういう仕様は別にブラウザ戦争に巻き込まれたからではなくて、最初からそういう言語だったのですけど、イメージがはまり過ぎてるので、もうそれでいいですの。

それにしても、ブラウザ戦争が凄惨化した８割くらいはマイクロソフトの横暴のせいだと思ってるのですけど、そんなマイクロソフトが「パパがRubyを愛でるように」育てたC#と、JavaScriptの関係に妄想が膨らんでしまいますの。

後発の強みでオブジェクト指向＋関数型言語してるC#と、古いのに昔から近い機能を持ってるJavaScript。なんとなく対照的でもありますの。そういえば、Node.jsの登場で今では仲良くサーバサイドで殴りあってるそうですの。

JavaScript「来ちゃった」
C#「ゆだんした！」
JavaScript「ならキミがブラウザへ来る？　あそこは地獄だよﾌｩﾊﾊﾊ」
C#「こわい！たすけてパパ！」
マイクロソフト「まってて！いまTypeScriptつくってるから！」

きっとこんなかんじですの。

50%OFFセールを半日堪能した結果

全品チェックとまではいかなかったけど、かなり掘り尽くせた気がしますの。

とりあえず、面白そうな本を２９冊見つけましたの。
いくらなんでも全部買ってると出費がすごすぎるので、次は絞り込みタイムですの。

メモしたリストを見返すと、すでに「なんだっけこれ」みたいのもいっぱいあって、物欲の恐ろしさを感じますの。冷静に考えれば、３冊読むだけでも相当めんどくさいはず。


それにしても、こんなこと初めて思ったけど、
Amazonのサイトで、検索結果の後ろのほうを見るのってかなり不便ですの。

ページ送りが、１ページづつしか進められないので、ちょっと検索条件を変える度に１ページ目からやり直しになって、めくり直すのがすごく大変。

たとえば、みかんの本が欲しくて「柑橘類」で検索して１０ページくらいめくって、やっぱり「みかん」で検索し直すような場合ですの。

みかんが柑橘類に入ってる以上、途中までは、さっき見たものが延々出てくるだけですの。適当に８ページ目くらいまでごそっと飛ばせると楽なのですけど、なぜか出来ないいじわる仕様ですの。

たぶん何か処理の都合だとは思うのですけど、よくわからないですの。

翔泳社の電子書籍５０％OFFセール ※ただし（ｒｙ

翔泳社の電子書籍、全タイトルで50％割引セールを実施！
対象は800点以上、2月19日から25日まで
https://codezine.jp/article/detail/9254

翔泳社のキャンペーンページ
http://www.shoeisha.co.jp/campaign/fes/20160219


終わる前に見つけられてちょっとうれしい。。
しかもちょうど欲しかった本があったのですの。

ただセール対象のサイトが、
　Kindle, hont, 楽天Kobo, BookLive!, ヨドバシ
の５つで、ぜんぶDRM付きの電子書籍みたいですの。

翔泳社はじぶんでｐｄｆ販売もしてるようなのに残念。。

DRM付きの電子書籍は、安いの１冊くらいなら気軽に買えるけど、まとめて何冊もってなると金融商品を扱ってるような気分になってくるのが嫌ですの。本が欲しいだけなのに。

とはいえ、Kindleで半額なら十分魅力的。(*)
技術系の本は高い上に、中古でもなかなか値段が下がらないし、下手するとプレミアついたりするので、値段が下がるっていうだけで貴重ですの。

というわけで、全品チェックせざるを得ないのですの。忙しいですの。



*) ほかの４つだけ対象だったら、割高でも紙の中古を探すかも。