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

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

(監修・翻訳の方のページ)
[SQL]新著が出ます:ジョー・セルコ『プログラマのためのSQL 第4版』
http://d.hatena.ne.jp/mickmack/20130519/1368931267
あらかじめ言っておきますが「表紙のおっさん誰?」という質問は私にはしないように。私も答えられないので(笑)。

(査読されたらしい方のページ)
これは英訳したいセルコの最新刊!−−「プログラマのためのSQL第4版」
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は、基本的な命令すらブラウザ同士で互換性が無いような悲惨な状態だったそうですの。

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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



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

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側にまとめるのは悪くない筋だと思うのですの。たぶん。