ディープワークは邪魔されず集中して取り組めて，価値あることを成し遂げるような仕事，シャローワークは，メールに返信したりとか，事務作業みたいな仕事．ディープワークが大事，という本． 邪魔されないようなライフスタイルの組み立て方も載っていて，「インターネットしない日を作る」ではなく，「インターネットする時間を決める」とか，けっこうストイック．SNSを使うべきかどうかという議論も載っていて，目標を直接支援しないならやめましょう，ということだった．クヌース先生はメールを使わないことで，ディープワークに集中できている． クヌースにツイッターのフォロワーをつくることや、もっと自由なメールのやりとりで生まれるかもしれない予想外の好機を売り込んでも無駄だろう。これらは直接、彼の目的の助けとはならないからだ。 ソフトウェア作ってるチームでチーム歴が長くて便利な人になっていくと，Slackで絶えず話し続けて，
みんなのGo言語読み終わりました。 各位、最近レビュー書いている方は著者の方から献本されているが、僕はそんなことはなく普通に購入した。 なんか先行販売してるところが少なからずあるらしい、という情報が上記のツイートから得られた。 このツイート見たときたまたま池袋にいて、「池袋のジュンク堂ならあるのでは？」と考えて行ったら、あった。 ブックファーストにはなかった。僕は本が好きで、しょっちゅうジュンク堂行ってたがやはり素晴らしい店だとわかる。 Go言語、コミュニティに暖かさが見られ、言語としてもとっつきやすいので好きなのだけれど、いまいち実際のプロジェクトに応用されてる際のコード例とかが見れなくて悶々としてたので、「こういうライブラリ使ってますよ」みたいな話が多かったのが好印象だった。入門しつつ、痒いところを一通り掻いてもらった感がある。 もっと欲しい情報としては、「〜〜の言語から来た人にとって
はじめに 数学に対してコンプレックスがあるエンジニアというのは、多少なりともいるかとは思う。かくいう自分も、「数学」に対しては、出来ないというコンプレックスがあった。とはいえ、単なるコンプレックスならば、それを克服すればよく、取っ掛かりになる分野を探したりしていた。 もちろん、数学とはいえ、いろんな分野がある。例えば、論理学であったり、集合論であったり、あるいは解析学や、幾何学、巨大数論といったように、さまざまな分野がある。そして、これらの分野は、少なくともある程度までは、プログラミングの世界にも通じている。 例えば、条件分岐を考えるときに、ドモルガンの法則を使うとすっきりするパターンとかもある。だから、全ての数学の分野がそのまま実務に使えるとは限らないけれども、しかしその分野と密接な部分は少なからずあることは疑い得ない。 とはいえ、例えば微分・積分を現実の業務に使う必要性が出てきたからと
2014/10/14 追記 本書87ページに「母数」という単語が複数回出てきますが、 これは全て「分母」とすべきでした。*1 通常、統計学の文脈では、母数は各確率分布を特徴付ける変数を指す単語であり、 例えば正規分布は平均と分散という二つの母数によって形状が決定されます。 決して母数と分母（あるいは全数）と誤解してはなりません。 しかし母数と分母を混同することは本当によくあることで、 本書はこのような頻出する誤解を訂正し、 皆様が統計を用いる際の失敗を一つでも減らす という目的で執筆に至ったにも拘らず、 まさか本書でこのような重大な失敗をしてしまったことに対し 心からお詫び申し上げ訂正させて頂きます。 なお、問題個所の記述は共著者の森藤氏ではなく 私が記述したものであり、全責任は私にあります。 本を書くに当たり、誤字脱字や言い回しの不備は出来る限り無くすべきですが、 人間であるためミスをす
技術評論社様から献本して頂きました！ありがとうございます！！日本を代表する DataBase Administrator(DBA)である松信さんの新著ということで、あえて僕の様な人間が何をせずともすばらしい本であることは自明ですが、献本頂いたからには何か書かねば！ Open database life: 新著「Web エンジニアのための データベース技術[実践]入門」 「データベースがないと何が困るのか」 これが第 1 章のタイトルです。あぁ、入社前の自分に言い聞かせてやりたい。僕はプログラムを触り始めたころ、データベースを触りたくないという理由だけでウェブアプリを作ることを諦め、plagger を使って自分ではデータを直接保存しないことばっかりやってました。結果、SELECT文すら書けない状態でエンジニア生活をスタートしたわけです。 で、実際ウェブアプリの現場を 3 年やってきて、データ
過去に実際に起きた「インターネットが壊れて復旧した」事件を端緒に、「粘り強いが壊れやすく、壊れやすいが粘り強い」という視点でインターネットの形を探るという本を書きました。 インターネットを構成する基礎技術TCP/IPを解説した書籍は非常に多くありましたが、そのTCP/IPを使ってインターネットがどのように運用構築されているのかに関しては、あまり知られていません。本書は「TCP/IPを知っていてもインターネットはわからない、一方でインターネットを知るにはTCP/IPの細かい話を全て知る必要もない」という思想で、教科書的にならずに、あくまで「読み物」として楽しんで頂けることを目標に書いています。 立ち読み 「インターネットのカタチ もろさが織り成す粘り強い世界」草稿の一部、目次、参考文献(360件)、その他情報を公開しています。 はじめに 目次 1章 壊れやすくて粘り強い 参考文献 (LaTe
デベロッパー向けに情報発信をしている「Dr. Dobb's Journal」が、この1年（昨年7月1日から今年の6月30日まで）に出版されたIT系書籍の中から優れた本を選ぶ「Jolt Awards」が今年も発表されました。 発表記事では選考理由などが紹介されていますが、以下では選ばれた6冊がどんな本なのかを紹介しましょう（当然ながらすべて洋書です）。DSL（ドメイン固有言語）やClojure、Continuous Deliveryなど、新鮮な話題を提供している本が並んでいます。また、マーチン・ファウラー氏の著作が2冊（「Domain-Specific Languages」「Continuous Delivery」）選ばれている点にも目を見張ります。 タイトルに目を通すだけでも、いま何が開発者のあいだで話題になっているのかが伝わってきますが、もし興味を持たれたら実際に中身を読んでみてはいかが
若い頃はなんだか「本を読むのが偉い」と思い込んでいて馬鹿な乱読をしたものでした。そしてそんなことには意味がないと気づいた今となっては時間はあまりに貴重です。一冊、一冊、何を読むかを選ぶことは如何に生きるかという大問題なのです。 ブログ Pick the Brain の「もっと本を読む方法」というそのものずばりの記事のなかで良い点が２つ指摘されていました。それは 本当に読みたいと思っているものをよむこと 特に読みはじめの段階で、本に最適な時間を割り当てる というものです。最初の「本当に読みたい本」というのは、読書人としては当然の話なのですが「読んでいないので恥ずかしいと思っている古典」や「誰もが話題にしていて乗り遅れたくないと思っている本」といったプレッシャーに負けないという点です。 ２番目の点は、たとえば難しい本なら５分刻みで読むのではなく、なるべく読みはじめの段階で大きな時間を割り当てら
2011年01月22日 台北・Eslite 誠品書店に「書店」が進むべき未来を見た。 つくづく思うが、テクノロジーというものは「残酷」なものだ。 新撰組のように、青春を捧げて剣術の修行に励んでみても、銃を手にした素人には敵わない。ロウソクの明かりに、どのような情緒があると言っても、2011年の今、ロウソクに明かりを灯すのは、誕生ケーキを前にして歌うほんの束の間であり、電灯を使わぬ生活など考えられない。 そのようにして消えていったものは多数ある。帆船、馬車、蒸気機関車、電信、タイプライター。たとえば私の記憶が鮮明にある範囲でも、ポケベルもそうだった。現在、30代の女性が「女子高生」と言われていたころには、「５６４３（ゴム持参）」といったように数文字の語呂合わせで、友人同士が公衆電話からプッシュ信号を押して、コミュニケーションしていたなんて、今の高校生にとっては、モールス信号なみの時代錯誤に思
本日から仕事始めという人が多いだろうが、週末になれば三連休とまだいくらか余裕があるので、2010年を総括して2011年の方向性を定めるのに参考になる文章を読む時間はまだ残っている。 新年一発目の更新は、そうしたトレンドを読む文章として O'Reilly Radar に掲載されたオライリー・メディアの創始者、CEO であるティム・オライリーの What lies ahead インタビューシリーズを取り上げたい。 オライリーは5つの分野について今後の展望を語っている。ワタシが読んでおっと思った文章をざっと翻訳しておく。気になったら是非原文をあたっていただきたい。 What lies ahead: Data やはり彼の一番の興味はこの「データ」にあるようで、来月開催されるカンファレンス Strata 2011 は注目である。 データとアルゴリズムこそが非常に多くの企業の活動の中核をなしており、そ
http://blog.usagee.co.jp/2010/11/23/level-up-programmer id:lizy javablackさんが来そうな内容だｗ http://b.hatena.ne.jp/entry/blog.usagee.co.jp/2010/11/23/level-up-programmer いやまったく．毒と分かっていても食らうしかないのは不幸だ． http://d.hatena.ne.jp/JavaBlack/20080401/p1 http://d.hatena.ne.jp/JavaBlack/20070522/p1 悪書 憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection) 作者: Tucker出版社/メーカー: 翔泳社発売日: 1998/05/31メディア: 大型本購入: 10人 クリック: 508回この商品を含むブログ
本を読むと、知識が増える、アタマが良くなる、カネが儲かる、廊下を走らなくなる、などと言う人があまりに多い。 読書家とは本を読むことを恥ずかしいと思っていない者、と書いたことがあるが、もちろん事実とは違う。 本を読むのが好きな人は、自分が「良いこと」をしてるとは思っていない。 むしろ「うしろぐらいこと」をしていると思っている。 本を読むのが好きでない人は、読書が「良いこと」だと思っている。 これでは永久に本を読む楽しさを知ることはないだろう。 そればかりか、読書を「良いこと」だとすすめて、周囲の人間まで本嫌いにしてしまうだろう。 寺山修司は、暗いところで何か読んでいると「目が悪くなるからやめなさい」と叱られる、「本当の理由」を看破している。 問題は、視力低下でも、照明の暗さでもない。 ヨーロッパ中世では、黙読していると「あいつは今、悪魔と喋ってやがる」と後ろ指を指されることがあった。 それと
2010年09月21日18:00 カテゴリ書評/画評/品評Lightweight Languages 言語設計者たちが考えること - 書評 - Masterminds of Programming オライリー社の担当編集者赤池様より献本御礼。 言語設計者たちが考えること Mastermind of Programming Federico Biancuzzi / Shane Warden 伊藤真浩 / 頃末和義 / 佐藤嘉一 / 鈴木幸敏 / 村上雅章訳 [原著:Masterminds of Programming] ソフトウェアに関する人文系書籍としては、間違いなく最重要の一冊。今後これなしでソフトウェアに付いて語ることは慎まれるであろう。 このような重要な一冊に査読者としてお手伝いできたことは、光栄としかいいようがない。 本書「言語設計者たちが考えること」、原著"Masterminds
この記事には参考文献や外部リンクの一覧が含まれていますが、脚注によって参照されておらず、情報源が不明瞭です。 脚注を導入して、記事の信頼性向上にご協力ください。（2021年4月） 『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』（ぎんのたまなどない ソフトウェアエンジニアリングのほんしつとぐうゆうてきじこう、英: No Silver Bullet - essence and accidents of software engineering）とは、フレデリック・ブルックスが1986年に著した、ソフトウェア工学の広く知られた論文である。 原論文は英語である。日本語では『銀の弾丸はない』と、翻訳されることもある。ブルックスは、「銀の弾丸」（Silver Bullet）として、魔法のように、すぐに役に立ちプログラマの生産性を倍増させるような技術や実践 (特効薬) は、今後10
『計算機プログラムの構造と解釈』（Structure and Interpretation of Computer Programs。原題の略称SICPがよく使われる）は、1985年にMIT出版から刊行された、計算機科学分野の古典的な教科書。著者はマサチューセッツ工科大学 (MIT) の教授ハル・アベルソンとジェラルド・ジェイ・サスマン、ジュリー・サスマン。かつてMITコンピュータ科学科の6.001として知られるプログラミングの入門講義で使われていた[1]。第2版（ハードカバー版 ISBN 0-262-01153-0、ペーパーバック版 ISBN 0-262-51087-1）が1996年に刊行された[2]。計算機科学の古典として広く認められている。 表紙に魔術師が描かれているため魔術師本（Wizard Book）としても知られ、まれに表紙の色をとって紫本（Purple Book）とも呼ばれる
太古の昔から、タールの沼に落ちた巨大な獣が死にもの狂いで岸に這い上がろうとしている光景ほど、鮮烈なものはない。恐竜やマンモス、それにサーベル・タイガーが、タールに捕らえられまいとしてもがく様が目に浮かぶ。激しくもがけばもがくほど、タールは一層絡みつき、どんなに力強い獣でも、また賢く器用な獣でも、ついには沈んでいってしまう。 大規模システムプログラム開発は、過去十年以上もの間そうしたタールの沼のようなものだった。そして、多くの強大な獣たちが、その中へ乱暴に突き落とされてきた。たいていは稼働システムを作り、這い上がってきたものの、目標とスケジュール、それに予算にかなったものはほとんどなかった。 規模の大小、また大量動員あるいは少数精鋭であろうとも、開発チームは次から次へとタールでがんじがらめになってしまう。問題を引き起こす原因は、一つだけではないように思われる。原因が一つだけなら、足のどれか一
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く