トップはてなー達が読んでるベスト「科学・学問」系書籍 20冊 まとめ

TopHatenarで購読者数またはブクマ数のいずれかでトップ100にランク入りしてる人達のエントリで、より多くのTopHatenarの人に取り上げられてるアイテムを集計しました。ただし、都合上、はてなダイアリーだけを対象にしてます。正確には、はてブでカテゴリが「科学・学問」に分類されているページを対象として、amazonへのリンクがはてブに抽出されている数をカウントしています。人数が同じ場合は、紹介回数で順序を付けています。


そのアイテムを取り上げているエントリへのリンクも付けました。


ほかのはてブカテゴリもデータを取ってあるので、それらも後でエントリにしたいと思っています。


★作成済みエントリ

第2位 ビッグバン宇宙論 (下) (3 tophatenars)

ビッグバン宇宙論 (下)
サイモン・シン
新潮社
売り上げランキング: 89516
2006/6/22


トップはてな−達の紹介/言及エントリ

第3位 ビッグバン宇宙論 (上) (3 tophatenars)

ビッグバン宇宙論 (上)
サイモン・シン
新潮社
売り上げランキング: 93592
2006/6/22


トップはてな−達の紹介/言及エントリ

第4位 生物と無生物のあいだ (講談社現代新書) (3 tophatenars)

生物と無生物のあいだ (講談社現代新書)
福岡 伸一
講談社
売り上げランキング: 529
2007/5/18


トップはてな−達の紹介/言及エントリ

第10位 Mind Hacks ―実験で知る脳と心のシステム (2 tophatenars)

Mind Hacks―実験で知る脳と心のシステム
トム スタッフォード マット ウェッブ
オライリージャパン
売り上げランキング: 7799
2005/12


トップはてな−達の紹介/言及エントリ

トップはてなー達が読んでる 社会派書籍ベスト15冊+次点41冊

TopHatenarで購読者数またはブクマ数のいずれかでトップ100にランク入りしてる人達のエントリで、より多くのTopHatenarの人に取り上げられてる書籍を集計しました。ただし、都合上、はてなダイアリーだけを対象にしてます。正確には、はてブでカテゴリが「社会」に分類されているページを対象として、amazonへのリンクがはてブに抽出されている数をカウントしています。人数が同じ場合は、紹介回数で順序を付けています。


その書籍を取り上げているエントリへのリンクも付けました。


ほかのはてブカテゴリもデータを取ってあるので、それらもエントリにしています。

第6位 「ニート」って言うな! (光文社新書) (5 tophatenars)

「ニート」って言うな! (光文社新書)
本田 由紀 内藤 朝雄 後藤 和智
光文社
売り上げランキング: 29943


トップはてな−達の紹介/言及エントリ

次点(第16位タイ)

トップはてなー達が読んでるベスト15「コンピュータ・IT」関連書籍 +23冊

先日、TopHatenarが新しくなりあっちこっちで盛り上がってました。昨日は、プログラミングの本の紹介がホッテントリ入りしてるのを見て、ボクも賢くなりたいので、彼らが読んでいる本を調べてみました。


調査方法は、TopHatenarで購読者数またはブクマ数のいずれかでトップ100にランク入りしてる人達のエントリで、より多くのTopHatenarの人に取り上げられてる書籍を集計しました。ただし、都合上、はてなダイアリーだけを対象にしてます*1。正確には、はてブでカテゴリが「コンピュータ・IT」に分類されているページを対象として、amazonへのリンクがはてブに抽出されている数をカウントしています。人数が同じ場合は、紹介回数で順序を付けています。


その書籍を取り上げているエントリへのリンクも付けました*2


ほかのはてブカテゴリもデータを取ったので、それらもエントリにしました。


★作成済みエントリ

第7位 計算機プログラムの構造と解釈 (6 tophatenars)

計算機プログラムの構造と解釈
ジェラルド・ジェイ サスマン ジュリー サスマン ハロルド エイブルソン
ピアソンエデュケーション
売り上げランキング: 8824

トップはてな−達の紹介/言及エントリ

次々点 (第19位タイ)

*1:TopHatenarが新しくなったのに意味ねーな><

*2:ダイアリー記法でタイトルの出し方知らないので、ベタリンク・ベタパスにしてタイトルが出せてません…。

PHPはそのニセ科学的な文化が問題なのでは?

もうおまえらPHPerは正規表現をブログにうpするんじゃねえ!
と言われても無理もなくなってしまうのではないか。

http://blog.livedoor.jp/dankogai/archives/51189905.html

弾さんの咆哮に対して、「PHP関係ねぇ!十把一絡げにすんな」的な反論がブコメでもチラホラ見られる。それは正論だし、当然ちゃんとしたPHPerも少なからず居るはずだと思う。だけど、あえてそれを無視して暴論を。


PHP周辺が、ハッカー達から蔑ずまれ叩かれやすいのは、単に正規表現が間違っていたかという単体の事象達が問題なんじゃなくて、そういう事象を生み続けるPHPの文化圏、そこに属する人達の態度が誠実でない傾向が原因じゃないだろうか。


彼らは、プログラミングに関わる諸問題を科学的に研究してきているコンピューターサイエンスに対して、リスペクトも関心も払わず、対象の問題内容もろくに理解しせず自ら正しいかどうか確認する事もなく、表面的にとりあえず目的さえ果たせる(と思えれば)いいという発想で、適当にコピペでコーディングして、『あ、動いた。おk、出来た』と言うノリ。


自ら思考することなく、それっぽければ問題を掘下げることなくむしろ出来るだけ浅い理解のまま、ただご利益だけを安直に求める姿勢は、ニセ科学を蔓延させる人達とどこか通じる物すらある。


もちろん、上記は偏見である。しかし、PHPはそう言うイメージを持たれている事は事実だと思うし、実際今回も、対象を適切に扱わずに適当に処理するコードを、これまた正しいかどうか確認もせずにコピペしてご利益を得ようとする事を狙った記事が問題となっている。


PHP擁護の人は、弾さんの論法なんか突付いているよりも、データで偏見自体が誤りである事を示す事が本当の反論になるだろうし、偏見に当てはまる人はおのおの自らそうではないように努めれば発展的だし、あるいは、その偏見通りである事が実は良いことである事を示せば話が面白くなるかも知れない。

おまけ:

偏見を書いただけだと気持ちが悪いので、安直いかんと自分で言ったそばから、安直にGoogle先生に聞いてみた。もちろんこれはまったく不十分で証明にはならない、ネタと言う事で。


まず各言語のプログラミング記事ヒット数。プログラミングに関わる記事の可能性が高い範囲にするために、キーワードにprogramも付けている。PHP>>Java>Perl>Ruby

    • Ruby program の検索結果 約 590,000 件中 1 - 10 件目
    • Java program の検索結果 約 21,400,000 件中 1 - 10 件目
    • Perl program の検索結果 約 1,020,000 件中 1 - 10 件目
    • PHP program の検索結果 約 58,200,000 件中 1 - 10 件目


コンピューターサイエンス系出身ではなくても、まじめにプログラミングするなら、SICP※には突き当たるはず、というわけで、

    • SICP Ruby の検索結果 約 276,000 件中 1 - 10 件目
    • SICP Java の検索結果 約 338,000 件中 1 - 10 件目
    • SICP Perl の検索結果 約 219,000 件中 1 - 10 件目
    • SICP PHP の検索結果 約 260,000 件中 1 - 10 件目

(※↓SICP

計算機プログラムの構造と解釈
ジェラルド・ジェイ サスマン ジュリー サスマン ハロルド エイブルソン
ピアソンエデュケーション
売り上げランキング: 38790


チューニングtipsより計算量が解ってないでプログラミングは出来ないはず、というわけで、

    • ソート 計算量 Ruby の検索結果 約 8,480 件中 1 - 10 件目
    • ソート 計算量 Java の検索結果 約 13,600 件中 1 - 10 件目
    • ソート 計算量 Perl の検索結果 約 11,000 件中 1 - 10 件目
    • ソート 計算量 PHP の検索結果 約 14,900 件中 1 - 10 件目

テスト、するよね?、というわけで、

    • TDD Test Ruby の検索結果 約 55,500 件中 1 - 10 件目
    • TDD Test Java の検索結果 約 790,000 件中 1 - 10 件目
    • TDD Test Perl の検索結果 約 35,000 件中 1 - 10 件目
    • TDD Test PHP の検索結果 約 57,300 件中 1 - 10 件目

コピペ?

    • コピペ Ruby の検索結果 約 395,000 件中 1 - 10 件目
    • コピペ Java の検索結果 約 704,000 件中 1 - 10 件目
    • コピペ Perl の検索結果 約 427,000 件中 1 - 10 件目
    • コピペ PHP の検索結果 約 7,780,000 件中 1 - 10 件目


それぞれの項目でのヒット数は、もともとの記事量の大小をならしてやらないと不公平。というわけで、各言語のプログラミング記事ヒット数で割ってみた。まず、SICP
SICPのグラフ
やっぱPHP低いよ…。


計算量。
ソート 計算量 のグラフ
やっぱPHP低いよ…。


TDD+テスト。
TDD Test のグラフ
やっぱPHP低いよ…。


そして、コピペ。
コピペ のグラフ
…。おお!PHP少ない!最多はナントRuby

結論

PHPerは、Rubyistにコピペコーダーと馬鹿にされたら、鼻で笑ってやりましょう。

失敗の公開は重要だけど、それをどうしよう。

git移行のきっかけが、SVNリポジトリの崩壊、瓦解、というのがほほえましくもあり、ツッコミどころでもあり。

はてぶのコメントで http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/rx7/20090212/p1 なんかで、エラソーに言っている人がいるけど、あんたはエライよ。

http://d.hatena.ne.jp/hyoshiok/20090215#p1

吉岡御大にダメ出し喰らった!/(^o^)\
自分のブコメ

r-west RAID1ひとつ程度でバックアップ取らないとか、度胸も根性もさすがパネェっす!/つか、備えるべき厄災はHDDハード障害だけじゃないぜ?リポ管理作業で手が滑ったりsvnがバグで発狂したり誰かがキレてrm -rf /repoしたり… 2009/02/13

http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/rx7/20090212/p1

うああぁ、醜悪っ!!/(^o^)\

自分の失敗をつつみかくさづ言うということの価値をなんでわからないんだろうね。失敗によって、何を学んだか、何を学ばなかったかということが失敗したことより遥かに重要なのに

http://d.hatena.ne.jp/hyoshiok/20090215

うああぁ、まったくその通り!!


ただ、このブコメを書くとき何にも考えなかったわけでもない。というか、言われているような事もそのときの脳内では掠ってはいる。

  • うちだったら、(迷惑を掛けたお客様以外に)こんな身内の恥を晒す事はあり得ないなぁ。
  • これを公開するなんて、さすがオープンなはてなだなぁ。(←この辺、掠ってると思う)
  • しかし、事業の生命線であるSubversionなりなんなりソースコードリポジトリをバックアップしないなんて、ありえないよなぁ。
  • (ネタ化のためなんだろうけど)「\(^o^)/オワタ」とか言ってるレベルの話じゃないよなぁ。
  • 結果オーライで、反省も注意喚起もないなぁ。こんな軽いノリで済ましてたらみんな大変だぞ、それ。(←この辺も掠ってると思う)
  • これはちゃんと突っ込むべきだろう。

てな感じ。せっかくオープンにしたのに非難すると言う事に、逡巡が微塵もなかったわけでもない。でも叩いた。


開発プロセスアジャイルとかウォーターフォールとかなんとか、Web系かプロダクト系かSI系かそんなこと関係なく、ソースコードリポジトリのバックアップを取らないというのは、無責任過ぎる。これはいわば自分の良心でもある。これを突っ込まずに、わっはっは、と笑ってスルーしたとしたら、それはそれで失敗情報の公開には与するかも知れないけど、それはそれで、自分の良心に従っている気はしない。では、どうすれば良かったんだろう?


いきなり掲げたのは、1世紀近くにわたって読み継がれている定番本だ(タイトルが仰々しいが自分のような小市民にも普通に役立つ)。自分も参考に読んだが、内容は、議論をさけ、誤りを指摘しないとか、穏やかに信頼関係を結ぶ事の重要さが説かれていて一般の評価は高い。吉岡御大は、記事を読んでいてもまさにこの方向にぴったりのイメージだ*1。しかし、相手の主張が有害であり看過できない場合に、誤りを指摘せずにどうすればいいのだろう。大局的には信頼関係を結べればその方が重要なのだろうけど、あっちはスターPG、こっちは泡沫ブックマーカーだし、なにより今を置いてその問題を扱う事は出来ない。
ハッカーとして尊敬の対象であり人生の先輩でもある御大は、そう言うときにどうしているのか、非常に知りたい気持ちでいっぱいになった。

追記 返事貰った\(^o^)/

hyoshiok コミュニケーション 1 正解はないと思う。一緒に考えよう。 2009/02/15

http://d.hatena.ne.jp/katzchang/20090216/p1

テケトーな1エントリを書いた位で答えを貰える安い問題ではなかった\(^o^)/

おまけ 吉岡さんとのotsuneさんのやりとり

id:otsuneがこの件で吉岡さんに精力的な反論をしていたのを、漠然と共感と違和感の両方を持って眺めてたけど、

otsune 2009/02/16 18:23
正しいことを言われたから凹むだの上から目線だのやる気を失うだってのが吉岡さんのコメントで書いた「昭和の風習」だってこと。
パワハラによって上下関係と命令系統を叩き込む風習だよ。
んで「バカなことしましたが、バカと言わないでください」ってのは、そのパワハラがあって当然だという風習を前提にしてるの。
わかるかな?

http://d.hatena.ne.jp/katzchang/20090216/p1

このコメントを読んで、得心した。


完全フラットな言論空間。そこには上も下もなにもなく、批評はただ批評として存在する。自分の共感はそこにあった。


だけど、上で掲げたような「ヌルい」本が1世紀近くにも渡って売れ続け、今日現在でもAmazonランキング二桁という事実からして、その理想郷は遙か遠く、現状は言論マッチョ圏のローカル文化であって、これからも大半の人はモヒカンの投げる手斧から「ひぃぃぃぃ!」つって逃げ惑う村人であり続けるんじゃないか。とすれば、批評の対象となる村人の事例そのものが、妥当な批評を受ける事自体を負のインセンティブとして現れてこなくなる、という吉岡さんのというのは現在の現実に対してな有効な心配だと思った。一方、批評できない事例に存在意義を認めなければ、その心配には意味がない訳だけど。このやりとりは、それについての共通認識がないために、片方は理想郷を前提とし、他方は現状の現実だけを前提として話しているため、噛み合わなかったんだと思う。


で、今回の件は、はてな自体が言論マッチョ圏の中か外かってのがよくわからないけど。

*1:今回の記事は人に駄目出ししてるが例外中の例外だと思う

うごメモの規約違反通報1件=5円。任天堂に期待されたはてながやっている事は…。

うごメモ規約違反投稿通報に、ポイントが支払われるようになった。

本日より、掲載ガイドラインに違反している不適切な作品を通報いただいたユーザーさんへ、はてなポイントの付与を開始します。

うごメモはてなで通報を受けた作品を、はてなの管理者が確認して不適切であると判断、非公開とした際に、その作品について最初に通報いただいた方にはてなポイントを 5ポイントを付与します。

http://d.hatena.ne.jp/ugomemohatena/20090123/1232690426

なんなんだ、これは。金銭や即物的報酬は自発的動機を低下させるのは常識と思う*1。第一、それ無しで人を集めて有用な行為を起こさせるのが、Webのコミュニティ運営のキモではないのか?実際、人力検索ではポイント目当ての糞の様な回答が跋扈しているではないか。


しかも、5円。報酬は、その行為の価値を定義する機能も持つ。例えば、

ヤバい経済学 [増補改訂版]
ティーヴン・D・レヴィット/スティーヴン・J・ダブナー
東洋経済新報社
売り上げランキング: 952

asin:4492313788 にこんな話があった。子供を迎えに来るのが遅い親達に困っていた幼稚園が、遅れる毎に数ドル程度の罰金的な制度を設けた。その結果は、期待とは逆に遅れる親が増える結果になった。「時間通りに迎えに行く」事の価値を数ドルと規定され、それれなら多少遅れても他の用件に時間を使ってた方がマシだと思われてしまった訳だ。しかも、親の遅れは、制度を廃止した後も、元には戻らなかったそうだ。


5円というのは、いちいちまじめにやるにはバカらしい額だが、adsenceやスパムのアガリ平均単価に比べれば、十分に高い。はてなが金で釣るという考えならば、ユーザの適応的行動は自動でそれを行う事である。

例えばこんなモノを作ってみた。

このグリモンを両方インストールして、http://ugomemo.hatena.ne.jp/movies?page=20 辺りを開いて放置しておけば、若干の小遣い稼ぎ位にはなるかも知れない。


なお、はてなは、こういう脅しを掛けているが、

なお、ポイントの獲得を目的とした、無差別な通報や自分の作品への通報などがあった場合には、利用停止などの措置を取らせて頂きますのでご注意ください。

http://d.hatena.ne.jp/ugomemohatena/20090123/1232690426

一応、上記のスクリプトの通報は、無差別ではない。はてなお得意の「集合知」を利用した判断(笑)をしている。ただし、ヘタレの自分は脅しが怖いので試してない=未テストで本当に動くかどうかは不明。ご利用は自己責任で。

追記

スクリプト、やっぱだめだった。よく読んだら「最初に」通報した人だけ、とのこと*2。未通報をフィルタしてる所を外して、誰か旨くやってください。それが出来たらはてなも文句ないハズ。

*1:ちょっとググればいくらでも資料がある

*2:っつーか、自分が引用した部分にはっきり書いてあった…。orz

逃げる位なら「正しいプログラミングテクニック」を盲信しとけ!

いや、本当は盲信じゃなくてちゃんと理解すべき。でも理解不十分のまま、ふろむだ氏も言ってるなんて理由でそれに反する事を実行するよりは、盲信してる方が現実的にはよっぽど有益。というのは、彼が言っている事は、

  • 例外的な条件でのコードのあるべき姿の話
  • そのコードを取り巻く悪い状況に対する妥協の話

がごっちゃになっているから。これらを分ければ、前者の条件に該当することなんて本当に例外中の例外。プログラマは、悪い状況を招かない事にまず注力しなければ、いつまで経って低いレベルの妥協から抜け出せない。妥協の塊のせいで保守コストが上がり、そのせいで開発パワー不足が悪い状況を生み、また妥協…、のスパイラル。

「変数のスコープは狭いほど良い」

変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある。

http://d.hatena.ne.jp/fromdusktildawn/20081026/p1

「けっこう」とか曖昧に言われても、それでは有益な情報ではない。コードのあるべき姿の話なのか、そのコードを取り巻く悪い状況に対する妥協の話なのか。

いろいろな箇所から比較的頻繁にアクセスする必要があるようなオブジェクトや機能がバインド(格納)された変数やメソッドのスコープをクラスやメソッド内のローカルにして、それを使うときは、いちいち各クラスやメソッドにパラメータ渡しのチェーンを繰り返して使うようにコーディングする人がいる。

http://d.hatena.ne.jp/fromdusktildawn/20081026/p1

ふろむだ氏は、これが駄目だと言っているが、これはコードを取り巻く悪い状況に対する妥協の話かと。状況自体をそんな事にならないように設計をするのがプログラマの本来の仕事。


どこからでも見るられる変数は、そのコードにとっての環境だったり対象だったり。それを適切に纏めてコードが無駄なく書ける状況にするのが設計のはず。まるで引数渡しが悪いかのような書き方だけど、まず対象を引数に渡すのは当然の事。関数の機能も明確で分かりやすくなるし、テスタビリティも上がるし、再利用性も上がる。環境も、どういうスコープ(コード上の話ではなく意味の話)のどういう環境なのかを見極めて、適切な形のコンテキストとして適切な範囲で持ち回る。


それが出来ておらずコードが汚くなっているのは、プログラマが仕事に失敗した状況であって、本当は再設計・リファクタリングすべき状況。とはいっても、そういう時はもうそんな事をしている時間がないのが現実だろう。ふろむだ氏が言っているのは、そういう状況への妥協策だと認識すべき。なってしまったものはともかく、プログラマの仕事はそうならないようにする事。ふろむだ氏が言っていたからなんて言って、これに甘んじていてはいつまでも状況が改善しない。

広いスコープからアクセスできるようにした方が正しいケースの代表的な例は、標準入出力ストリーム(stdinやstdout)がバインドされたグローバル変数の形で実装されているシステム変数や、Rubyのprintやpメソッドだろう。

http://d.hatena.ne.jp/fromdusktildawn/20081026/p1

それは、スコープがプロセス全体である環境の例*1。もともとOSが規定している意味としてそういうスコープのものなんだからそういうもの。普通のユーザ変数でそういうものは例外的。それでもスコープが広いものは、変数でなく定数にするなど、利用者の喧嘩が起きないようにする事で害はかなり小さくはなる。


なお「変数のスコープは狭いほど良い」のは、単一責務の原則とも密接な関わりがある(単一責務の原則は、なにもオブジェクト指向限定の話ではない。コードとして現れるすべての名を持つモノは、すべからく単一責務の原則に沿う事でそのメリットを享受する事が出来る)。プログラムにおいて、「それ(クラス、オブジェクト、メソッド・関数、…)」の責務を明確にして、「それは何?どういうもの?」をブレさせずに一貫させる事は、もっとも重要な事のひとつ。つまらないバグの相当部分が、これをブレさせた為に起きる*2。スコープが狭くて利用者が凝縮していれば、そんな取り違えのリスクも小さくて済むし、多数の利用者の多様なニーズに合わせて責務がゆがむリスクも小さくなる。

「同じロジックのコードを2度以上書くな」

5つ理由が挙げられているが、やはりほとんどが、

  • そのコードを取り巻く悪い状況に対する妥協の話

の話。もちろんKISS原則・YAGNI原則もちゃんと考えるべきではあるが、抽象化を分かりやすい形に出来ていないという問題を、抽象化を悪者にして対処とするのは如何なものか*3

プログラミング言語を極めるのが大切」

この節は元々別エントリだったのをホッテントリ入りのために後からマージしたものらしく、話のレイヤがいきなり飛んでる。しかし、これがふろむだ氏の話を理解する上で重要と思った。

結局のところ、ほとんどのコンピュータプログラムは、人間や社会のニーズや欲望を満たすために存在し、人間や社会の利害や感情の構造の組み立て(これも一種のプログラミングだ)と無縁ではいられない。

http://d.hatena.ne.jp/fromdusktildawn/20081026/p1

ようするに、ふろむだ氏は「意味があることにしか意味がないと思ってる((c)岩明均@風子のいる店)」んだと思った。社会的な意味において、

しつこいほどくりかえす。ユーザー視点において、 What to Code に比べたら、 How to Code などブロックをendで閉じるか}で閉じるかほどの意味しかないことを。

http://blog.livedoor.jp/dankogai/archives/51130751.html

というのは、弾さんの言う通り。極論すれば、そういう意味ではプログラムなんて「動けばいい」のだ。ふろむだ氏の発想の根本はこれなんだと思った。彼は有り余る知力で、プログラミングも高いレベルでこなすかもしれないが、プログラマではなく、結局、経営者なんだと。もちろん、経営者が悪いわけはない。それどころか絶対的に正しい。私だって、チームや部門の経営的観点で、プログラミングを妥協する。そうしなければ社会的に、意味を得ることが出来ないからだ。しかし私は、意味があることにしか意味がないとは、いい歳こいた今でも思っていない。


弾さんは、先に引用した言葉のあとには、以下のように続けてエントリを結んでいる。

しかし、その差が気にならない人が良いプログラマーになるということもまずないのだけれども。

http://blog.livedoor.jp/dankogai/archives/51130751.html

*1:ちなみに、元記事にスレッドの話がまったく出てこないのが気になった。スレッドはひとつの重要なスコープだと思うんだけど

*2:変数の意味するものを微妙に取り違えたり、関数の意味を勘違いしたり、いじってるうちに変えちゃってたり

*3:Monadとかそういうレベルの抽象概念をプロジェクト毎に発明というなら、むべなるかなという所だが、少なくともSI業界ではそういうチームの存在自体が例外中の例外だろう