たいていのことは社会のせい

個人の行動を社会のせいにしてはならない。
社会がどうであれ、個人個人が正しいことをすればそれでいいのだ。

と言う主張は、

奴隷制は必要悪だと主張することと、おなじですの。


社会の中で個人が出来ることは限られていますの。
ポケモンを求めて移動する群衆の中に一度入ってしまえば、交通違反だからと道路から出ようとしても、簡単には抜けられないし、一人で人の波に逆らえば怪我をしますの。

社会の流れに反して立ち向かう個人には、大きな負荷がかかりますの。その負荷は本来、みんなが少しづつ負担しなければならない負荷だったものですの。

立ち向かう個人が増えれば、犠牲を出しながらも流れを変えることは出来るかもしれない。けれどそれは、社会のためには尊い犠牲者が必要なのだという発想にほかならないですの。じぶんが進んでその犠牲となると言うのなら止めはしないですの。ただ、他人に対してその役をやれと言うのは、偽善を超えて悪だと思うのですの。

個人は、社会に抗えない。

だから個人がひどい行動をとったとしても、社会がそういう流れなのであれば、責めることは出来ないですの。
たとえ、罰することは出来たとしても。

例えば、いじめを傍観していた人にも罪がある、という主張は無理がありますの。止めに入った結果、いじめの被害者になる可能性があるとすれば、それはもはや、個人に負わせていい負担ではありませんの。警備員を入れるなり、監視カメラをつけるなり、もっと上位の仕組みによって解決すべき問題ですの。

善意の個人は尊いけれど、それを常に犠牲にして社会を成り立たせていたら、当然のこととして、善意の人はいなくなってしまいますの。
そんな世界は生きづらいと思いますの。

そうならないためには、社会がどうであれ、ではなく、まず社会に問題が無いかを徹底的に考えることが先ですの。

個人は、社会に抗えない。しかし、ゆっくりと変えていくことは出来ますの。

あなたが本当にやりたい仕事はなんですか？

A：「まさに今の仕事がそうです！」
B：「実はちょっと、やりたいことがあって！」

あなたはどっち派？


あるいは、こう？
C：「仕事なんてやりたくない！」


A・B・C、どれを選んだ人もいると思いますの。
でも、どれを選んだかは問題ではなくて、大事なのは、いま選ぶために何を考えたかですの。

おそらく、
「いまやっている仕事は、自分にふさわしいものなのかどうか…？」
ということを考えたのでは無いですの？

やりたい仕事は？と聞かれているのに、いまの仕事のことを考えてしまう。
いまの仕事に不満があればあるほど。
「やりたい仕事」なんて素敵なものと対比されて、どんどん今の仕事のアラがみえてくる。

それはすべて自然なことで、
なぜなら、そういうふうに仕向けたいじわるな質問だからですの。

そう、いじわるな質問。
問題は、これとおんなじような質問を、企業。いまの仕事を振ってる張本人が、社員にぽいぽいするということですの。キャリア支援のための参考情報、なんて言って。

なんで社員にいじわるするのか逆に聞きたいですの。

社員の希望を叶えてあげるというのは、企業にとってはとても非合理的でハードルが高いこと。企業が自分の都合で辞令を出すときに、たまたま社員の希望が一致していたらドヤ顔ができる、という程度の話ですの。
なぜなら、お金をもらって苦痛を我慢しにいく、という労働世界観なのだから。

それなら質問を変えて、
「あなたが一番やりたくない仕事はなんですか？」
と聞いて、それを任せることになった場合には申し訳無さそうに頼む、というほうが健全ですの。企業としても、希望を叶えてあげるのは無理でも、地雷を避けてあげるくらいならまだ実現できる可能性がありますの。

そして、この逆パターンの質問こそ、
深く考えれば考えるほど、いまの仕事がマシに思えてくる質問。
日々が幸せになる可能性を秘めた、やさしい質問なのですの。



実は、趣旨自体は前にどこかの記事で書いてあったことですの。
その記事では「期待をもたせて裏切るのはひどい」という感じだったけれど、実際、もっとひどいことのような気がして。なんとなくずっと気になっていてたので、吐き出してみましたの。

どの記事か忘れて見つからなくなってしまったので、もしかしてぜんぜん違ったり、まったく同じだったりすると恥ずかしいですのって思いつつ。。

ヨドバシ.com の実質価格はどのくらい？

じわじわ殿様商売になりはじめてきたAmazonにかわって、応援しておきたいヨドバシ.com。

ぱっと見、Amazonよりちょっと割高に見えるのですけど、
10%のポイント還元がほぼ全商品に付いていて、ポイントまで入れるとAmazonよりわずかに安くなってることが多いようですの。

ただ、少し悩むのが、ポイントを使って支払った分にはポイントは付かないという点ですの。

ポイント含めてAmazonとトントンということは、付かないなら割高ということですの。つまり、ポイントを使うときには必ず割高なお買い物になってしまう、、ということは、１ポイントに、１円の価値が実は無いのですの？　そして、１ポイントに１円の価値が無いのなら、ポイント含めてAmazonとトントンというのもあやしくなってきますの。どういうことですのー！

これじゃおちおちお買い物も出来ないので、大雑把な計算をしますの。

それぞれ次のような関係だったとして、、
　（１）Amazon価格×1.1＝ヨドバシ価格 (*1)
　（２）ヨドバシ商品は必ず10%ポイントがつく
　（３）ポイントで支払った分にはポイントはつかない

これで架空のお買い物をしてみると、、

NIVEAツナ缶
　Amazonで1000円　：　ヨドバシでは1100円（110ポイント還元）

ポッキー(生姜味)
　Amazonで100円　：　ヨドバシでは110円（11ポイント還元）

この２つをAmazonで買うと、、
　1000＋100＝1100円が必要ですの

そしてヨドバシで買うと、、
　1100円でツナ缶と110ポイントを受け取ったあと、
　110ポイントを使いきって生姜ポッキーを受け取るので
　1100円が必要ですの

つまり、びっくり！基本的には価格の差はなかったみたいですの。
なにか差がでると思って計算してたので、ほんとうにびっくり。

また、ポイントの還元率が10%で揃ってる限りは、どの商品で貯めて、どの商品で使っても差はないはずなので、いつ貯めて使うかのタイミングを図る必要も特になさそうですの。

まあ、Amazonの価格と必ずしも綺麗に連動してる保証は無いので、一応、はっきりわかるほど高値になってないかは確認したほうがいいかもしれないけれど、それはAmazonにも言えることですの。
１品から送料無料で、届くのがやたら早くて、90日保証までついてるので、基本はヨドバシで、なかったらAmazonっていう流れだと幸せになれそうですの。

Amazonで送料無料にするために、あれこれカートに追加していてそう思いましたの。


(*1)
「10%ポイント還元でAmazonとトントン」と考えると、ヨドバシ価格はAmazon価格×1.1ではなくて、×1.111111…かも？と思ったのですけど、実際にいくつかの商品で価格を比べてみたら、×1.1付近になってたのですの。ポイント込みで微妙に安くなるのは、たぶんそのせいですの。

ダンボールにしてはいい橋ですね

変数に値を再代入する方法をしらない人が書いたコードの中では、変数とは定数のことである。

ゆるい言語、きびしい言語、いろいろあるけれど、使う人が常にすべての機能を正しく知っているとは限らないですの。むしろ、大小の違いこそあれ、全ての人は自分なりのサブセットだけを使ってコードを書いている、と言っても過言ではありませんの。(*)

さて、一見して無駄が多く、構造的に弱そうなコードであっても、良かれと思って書きなおしてしまうと問題が起こることがありますの。

それは直接的には、既存部分と書き換えた部分の不整合のせいだったり、書き換え方がそもそもまずかったせいだったりするわけですけど、、根っこには、書いた人と書き直した人の、お互いのサブセットの衝突があると思いますの。

よく勉強して、フルセットに近いサブセットを持っているほうが常に正しいか、というとそうでもなく、不完全な学習によって作られたサブセットが、ある種のドメイン固有言語となっている可能性もありますの。

オール天然素材でつくった、ロハスでおしゃれで、だけど頑丈で安全！と噂の橋をトラックで渡るのなら、その前に、それが歩行者と自転車しか知らない人が作った橋じゃないことを確認してからのほうがロハスですの。

郷に入れば郷に従え、という通り、
既存のコードを分析するときは、言語のフルセットの機能から考えるだけでなく、書いた人のサブセットの姿も考えないと、本当の意味は見えてこないのかもしれないと思ったのですの。


*) アセンブラや、Brainf*ckみたいな小さな言語もあるので実は過言ですの。

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

歌舞伎とウィンドウズ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で半額なら十分魅力的。(*)
技術系の本は高い上に、中古でもなかなか値段が下がらないし、下手するとプレミアついたりするので、値段が下がるっていうだけで貴重ですの。

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



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

バーニング・ラブ・SQL

SQLについて調べていたら、すごく詳しい記事を書いてる方がいたのですの。
生島勘富さん、という方ですの。

「艦これ」についてのまとめ #艦これ
http://d.hatena.ne.jp/Sikushima/20131230/1388375483

初級シスアドはユーザ向けの試験で、プロはできて当然！
http://el.jibun.atmarkit.co.jp/g1sys/2009/07/csql-bbbb.html

どうも、キワな方が多いことで個人的に有名な@ITのエンジニアライフで、コメント欄を炎上させて執筆陣から除名になった方だそうですの。
あそこのコメント欄、過疎か炎上の二択しかないきがしますの。

さておき、SQLと、それを中心とした開発についての愛と知識は本物だと思うのですの。

いくつか記事を読んだ限り、この方が一番よく主張しているのは、
「SQLは、APサーバ側の言語（Java、C#など）からDBアクセスのために呼び出される添え物、ではない」ということのようですの。

DBMSを使う以上は、なるべくSQLで処理をするのが（ほとんどの場合）良い、と。

なぜかというと、そもそもDBMSを使う以上は、そこにデータを集めていくことになるので、データを扱う処理はすべてDBを通すことになるわけですの。
そういう状態で、処理の主体をAPサーバに置こうとすると、DB・APサーバの間で処理がぐるぐる行ったり来たりする非効率な構造が生まれやすいということですの。たぶん。

また、SQLは、それさえちゃんと書ければ、設計から開発までぜんぶ出来ると言ってもいいくらいの言語なのに、その割に教育がすごく手薄で残念、もっとみんなSQLを勉強するべき、、ということもよく書かれていますの。

わらわもSQL苦手なのですけど、そうやって丁寧に「むしろSQLこそがメイン」と言われると、そうかも、と思ってしまいましたの。


ほかにも、C#とか使ってて、DBとやり取りする部分のコードが綺麗に書けなくて、、っていうのは、けっこうみんな悩みどころだと思うのですけど、この方いわく「ストアドでDB側に置いてしまえば、そういう汚い混合コードを書かなくても済む」といわれていて、これもなんだか納得ですの。

ストアドを多用すると、処理の在り処が散らばってわかりにくくなる…と思っていたのですけど、主体がAP側っていう先入観を捨てれば、かえって全てDB側にまとまって見やすいかもですの。

それに上でも少し書いたように、構造上、AP側はDBを無視して完結することは出来ないけれど、DB側はそれ自体で完結することが出来るはずですの。それなら、処理をどちらかにまとめたい場合、DB側にまとめるのは悪くない筋だと思うのですの。たぶん。

C#のvarとtry～catchが糞すぎる らしい

５年以上前の話に今さら感はあるのですけど、
C#の型推論について調べていて、へぇーと思ったのでメモですの。

2010-09-29 C#のvarとtry～catchが糞すぎる
http://d.hatena.ne.jp/yaneurao/20100929 

ものすごく大雑把に言うと、↓のようなコードをvarを使って書くとコンパイル通らない、という問題ですの。

HogeClass hoge = null;
try {
    hoge = new HogeClass();
    hoge.XXX();
} catch {
    if (hoge!=null)
        hoge.YYY();
}

直接的な問題は、ここで、
var hoge = null;
とすると、コンパイルが通らないことですの。
var hoge;　
でも同じく。

そこでC#の型推論が甘い、という話になるのですけど、

ただ、この書き方を許すということは、
コンパイル時に↓のようなコードを弾かなければいけなくなるということで、

var hoge = null;
if(てきとうな式){
　hoge = 1;
}else{
　hoge = "文字";
}

それって、すごく大変じゃない？　と思ってこれを書き始めたわけなのですけど、元の記事からリンク貼ってあったページを見ると、

[C#][Nemerle]C#の型推論は怠けすぎ
http://d.hatena.ne.jp/akiramei/20100929/1285759272

関数型、あるいは関数型寄りの言語なんかでは、普通に実現できていることのようで、なんか型推論ってすごいんだなぁって、５年以上前の記事を読んで思ったのですの。

この辺りは、よくも悪くも、「よその言語のおいしいところを、つまみ食い」してるに過ぎないC#の限界なのかもしれないですの（ドヤ顔）


ちなみに、一行でこう書いても↓ダメでしたの。当たり前だけど。
var hoge = (true == false) ? 1 : "文字";

あけてまして

おめでとうございましたの