前作「仕事は楽しいかね？」が素晴らしい一冊で、本作の存在を知ってしまった私は手にすることに躊躇はありませんでした。 悩み多き管理職である私にとって本作のテーマ「部下と上司の理想の関係とは？」はまさに教科書。 本作で登場する「私」を私自身に置き換え、読みながら大切な気付きを与えてくれました。 〝ほんもの〟の上司に出会ったことはあるかね？ こんな一言から始まる本作。 以下、大切な気付きを備忘録として。 いいかい、きみは自分の部署の神になろうとしているんだよ。 そりゃあ大変だろうさ、神様になるなんて。 〝他社に負けない給料というのは、〝ふつう〟で、平均的で、ほかのみんなと同じくらい〟ということだ。 最高の人が働くにふさわしい最高の場所 指図ではなく信頼するんだ。 信頼に書類は必要ない。 優れた上司は、常にお役所的な体制と戦っている。 優秀な管理職の基本的な仕事は、管理することじゃない。 革新を宣

サーバ状態収束ツールChefの概要が分かる本。 ChefやPuppetが出てきてから結構経っているが、遅まきながら追いつこうと買った。入門本のほとんどはインストールの仕方とサンプルコードの山で構成されていて、ツールの概要やメリット、デメリット、運用例はほとんど書いてないゴミが多いが、本書はそうではなかった。すばらしい。 本書で得た有用な情報は以下の通り。 【Chefの特徴】 ・Chefは、サーバの状態を収束させるためのツールである。 ・Chefは、冪等性を保証する。 ・Chefを使うなら、サーバの状態管理には必ずChefを使用すべき。 ・サーバ内にアプリケーションをデプロイする場合は、ChefではなくCinnamonなどを使用しよう。 Chefが海外サイトで話題になった頃、「Rubyで書いたAnt」だと思って、特に情報収集していなかったが、RubyのDSLを有効活用しまくった普及の早さと、

訳書ベースで2年前、原書ベースでは5年前という、技術書としては多少古めな本書ですが、近年読んだ技術書の中では出色の一冊です。 DBの論理設計・物理設計に関しては、割と一家言ある方なのですが、いきなり2章でRDBの弱点（階層構造の探索）を突いてきたところでやられました。 その後も、NULLの演算に関する章なんかは「なるほど。勉強になるなぁ」と思いながら読みましたし、物理ファイル格納や全文検索、EAV(KVS)の章などは、現在開発中のシステムの設計に大いに役立ちました。 RDBはプログラミングにくらべるとクセがあって、敬遠しているエンジニアも多いようですが、私は「RDBを制する者はシステム開発を制する」と思っていますし、本書を読むことでその意味が理解してもらえるのではないかと思います。

いつも本書のタイトルを本棚で見かけるたびに「はい、楽しいです！」と笑顔で答えられるような仕事をしたいものだ、と思いつつ、未読だったので読んでみました。 大雪で閉鎖されたシカゴ空港で主人公が出会った老人。 この老人によるたった一晩の講義は、その後の主人公を大きく変えるきっかけになったのでした。 自分の働き方はこれでいいんだろうか…と思っていた矢先に、背中を押してくれる言葉にたくさん出会えました。 「明日は今日と違う自分になる」 「完璧とは、ダメになる過程の第一段階」 老人の言葉を聞きながら、だんだん明るい気持ちになってきました。 特に、遊び感覚でいろいろ試してみることの大切さを再確認。 せっかく仕事をするのだから、いつも不機嫌な顔でしていたらつまらない。 自分が楽しみながら、そしてその楽しさを周りにも波及させていくように仕事をするのが私の理想です。 そんな女性に近づけるよう、日々トライを重ね

javaScriptで使われるデザインパターンがいくつか紹介してある。 その他に2013年前後に使われていたAMDやrequire.js、common.jsなどのモジュールもパターンとして紹介している。 jqueryで使うデザインパターンも数種類説明があった。 パターンについての説明文は訳書なので分かりづらい表現が多い。 図版が少なく基本はサンプルのコードとコメントによる説明となっている。大規模サイトのプロジェクトに関わりjavaScriptを書いている中級以上の人が読むには苦労がないのだと思う。 初学者が読んでも理解できない用語が頻繁に出てくるので用語を調べながら読むことになる。 基礎と応用の間を繋ぐ知識が不足していて、一読してほぼ理解ができなかった。 次回精読しながら部分的に拾い読みする予定。

JavaScriptで分かりにくかったプロトタイプベースの考え方について、しっかり書いてあり理解の助けとなった。 また、JavaScriptで class構造（実際はオブジェクト）がどのように生成されるのか、についても解説があり、より理解できた。 JavaScriptのclass構文は、実際はclass構造を模したオブジェクトを生成するためのシンタックスシュガーであることは元々知っていたが、本書により実際はどのような処理が行われるかを知ることができた。 JavaScriptを扱う際にわざわざ本書を読み込む必要はないが、読み物として読むのであれば良い解説本だと思う。 ただし読んでいてつまらない章もあるため、そこはスキップしてもかまわないと思う。

作品紹介・あらすじ 言語解説部分とリファレンス部分に分け、その言語解説部分をまとめたもの。第5版では、全章の内容を更新し、XMLHTTPRequestオブジェクトでスクリプトからHTTPリクエストに送信する方法、JavaScriptを使ってXMLデータの制御、またJavaScriptによるグラフィックの制御機能についてなど、新しい話題を追加した。

複数の執筆者による原稿を編集した本 この本の出版年は2011年、10年遅れです。 1章 美しさについて 「美しさ」だけでは曖昧であるのでこの本での美しさの指標が示してある 新規性　新鮮な着眼点や表現形式 伝達力　伝達する側の意図が伝わる力 効率　伝達する必要のないものは排除すること 芸術性　伝えるためのテクニック 2章 積み上げ時系列の物語 ビジュアライゼーションのチュートリアル 3章 Wordle 文字の出現頻度によって文書の特徴を表現したビジュアライゼーション 4章 色彩 省略 5章 地図情報 ニューヨークの地下鉄の路線図をデザインする 6章 Flight Patternプロジェクト アメリカとカナダでの民間の航空機の航路を可視化し渋滞状態をビジュアライゼーション したプロジェクト 7章 あなたの行動があなた自身を明らかに Amazonの書籍購入データによりソーシャルグラフの研究 8章

作品紹介・あらすじ 本書は、さまざまな手法や規模、異なった立場でソフトウェアテストに携ってきたプロフェッショナルたちが編み出したテストの極意、「美しいテスト」について語るものです。豊富な経験やユニークな見解を持つ人物に焦点を当てた「テスター」、試行錯誤の末に到達した「プロセス」、すばやく効率的に行うための「ツール」という3部構成で、書き手自らが確立したテストの極意を実例を挙げて分かりやすく解説します。日本語版では、山浦恒夫氏による組み込み系ソフトウェアについてのエッセイを収録。

作品紹介・あらすじ ビューティフルコードに続く、一流のアーキテクトたちによるエッセイ集。今回は「美しいアーキテクチャ」をテーマに、オブジェクト指向提唱者のバートランド・メイヤーをはじめ、19人の開発者が、堅固で、エレガントで、柔軟性が高く、かつ管理しやすいソフトウェアアーキテクチャとは?をテーマにその哲学と思い入れを語ります。

トータルの印象としては、「買い」である。 本書は、JavaScriptを見よう見まねでプログラミングしてきた人が もう一歩先に進むために読んで欲しい、中級者以上向けの本である。 著者は、JSONを発掘した人物だけあって、 本書中には非常に深い経験と洞察に基づいた興味深い内容に あふれている。 読者の前提として、JavaScriptの基本的な知識に加えて、 Java、C#などの強く型付けされたオブジェクト指向言語を習得していると、 本書の主張している内容が理解しやすいだろう。 これは、文書中にクラスの概念や他のプログラミング言語との対比が 述べられているからである。 本書は、JavaScriptが標準API、言語仕様のレベルで、 「良い部品」と「悪い部品」とに分けて、できる限り「良い部品」を利用して、 読みやすく、修正しやすく、バグの少ないコードを書くことを説いている。 あくまで言語Java

書名から「き97のこ」の部分をとりだして、「97きのこ本」という愛称がついています。 そのルールに基づくなら姉妹本の『ソフトウェアアーキテクトが知るべき97のこと』も「97きのこ本」になるのですが、こちらは特にそのようには呼ばれてはいないようです。 原著の73人のプログラマによる97本のエッセイに加えて、日本人プログラマ8人（小飼弾、関将俊、舘野祐一、まつもとゆきひろ、宮川達彦、森田創、吉岡弘隆、和田卓人）による書き下ろしの10本のエッセイが追加され合計107本のエッセイ集になっています。 エッセイ1本は2ページのものが中心なので電車の中などでも気軽に読むことができます。 テストを話題にしたものも、タイトルだけでも、8本あります（本書中にある分類では14本になっていました）。 テスト担当者はプログラマの友人 偶然の仕様ではなく本物の仕様のためのテストを書く テストは夜間と週末に テストのな

作品紹介・あらすじ 初めて学ぶ方、過去に挫折した経験のある方、知識を確固たるものにしたい方を対象に、イラストや写真を使ってやさしく楽しく解説する人気のHead Firstシリーズのデザインパターン編。刺激的なレイアウト、思わず膝を叩く見事なたとえ、引き込まれる小話、楽しいクイズやパズルで飽きることなく読み進むことができます。複雑難解なデザインパターンの概念が面白いほどよくわかる、目からウロコの画期的な書籍です。

とても優れたコードを書いた人と、そのコードについての門で33章もある。全部は書けないので気になった部分だけ取り上げる。 1章 正規表現マッチヤ 正規表現の短いコードについて。 10章 高速ビットカウントを求めて 単純な方法から分割統治法までのコードを紹介している。 18章 Pythonの辞書実装 ほかの言語同様にハッシュ関数で実装されている。衝突対策としては開アドレス法の１種を採用している。 19章 Numpyの多次元イテレータ Numpyのスライシングは、イテレータによって支えられており多次元配列へのアクセスをcounter配列とスライダ配列を使うことで高速化に成功している。 29章 エッセイのごときプログラム 日本語版の特別章、Ruby言語を開発したまつもと氏によるRubyにおける美しさについて このような本が作られる理由としてコードを作る人が基本的に尊敬されていることなんだろうと思う

作品紹介・あらすじ データベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅。

◆内容 めまぐるしく変化する仕様要求にさらされながらも、迅速にソフトウェア開発を進めていく「アジャイル開発」を実行するためには、 - 「実践法」の理解 (XP とか) - 多くの先人達の失敗と経験から作られた「設計基本原則」の理解 (SRP, OCP, LSP, DIP, ISP とか) - こうした原則をバランス良く利用した「デザインパターン」の理解 が必要だと述べ、それぞれについて詳細に語られている。 ◆印象に残った点 ◎テストファースト - テストファーストにすると、使う側の視点で見ざるを得ないため、早い段階でインタフェースに注意を払える。 - テスト可能な設計にしようとすると、結果的に周辺コードと切り離され、ソフトウェアの分離を促す。結果的に設計の質を高める。 - => いつもは正直、 設計->実装->テスト の順でしかできていなかったので、この考え方は納得した。（本でも、先に実装

アジャイル開発とスクラム　顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント 著：平鍋　健児 著：野中　郁次郎 けっこう分かりやすかった 構成は３部、第１部アジャイルとは何か、第２部ケーススタディ　第３部アジャイル開発と知のモデル　である ■アジャイル開発とは ウォータフォール開発に対して、アジャイル開発 アジャイル開発とは、短い期間を区切ってその中ですべての手順を踏んで動作する完成品の一部を開発する、それを繰り返すこと アジャイル開発では、分析、設計、実装、テストを短い期間で並列で行うこれを繰り返す。動くソフトウエアを一定間隔を作り、それを成長しさせていく アジャイル開発とは総称 ・スクラム ・エクストリーム・プログラミング（ＸＰ） ・ユーザ機能駆動開発（ＦＤＤ） ・ＤＳＤＭ ・適応型ソフトウエア開発（ＡＳＤ） ・Ｃｒｙｓｔａｌ　Ｃｌｅａｒ（クリスタルクリア） ・Ｅｖｏ（イボ）

テスト駆動開発を組み込みという環境に合わせて１から優しく教えてくれる本。 良い点は3つ。 まずテスト駆動開発とは何か？ということをふんわり教えてくれる。ケント・ベックの『テスト駆動開発』を読めばいいのかもしれないが、それよりもおそらく柔らかく書いているだろうし、組み込みという環境に合わせて書かれているので、気を付けるべき箇所などに目が行きやすい。 第２に、細かいノウハウに実例をもって説明を加えていることが非常に好ましいと感じる。依存関係（のあるオブジェクト）の注入、いわゆるＤＩにも触れているし、それを読者が体験できるようにコードも用意されている。また、ダブルとこの本では呼んでいる、モックやスタブなどの効果的な使い方も記されていてためになる。ダブルで置き換えるための３つの方法は特にそう感じた。 最後に、テスト駆動開発のことだけでなく関連する重要な要素として、設計方法やリファクタリングについて

とても良い本でした。 ソフトウェア開発にたずさわる読者に、「アジャイルであること」とは何なのかを理解させ、アジャイルプラクティスの試行を大いに助けてくれる本です。 アジャイル(Agile)とは、直訳すると「機敏である」ということ。 ソフトウェア開発において、最終的な製品の仕様が開発段階であらかじめ完璧に決まっているなんてことはあり得ないんだから、当然完璧な要求仕様やスケジュールなんか最初から組めるわけない。エクセルで開発スケジュールを作り、スケジュールが変化するたびに(スケジュールは当然変化する)エクセルのスケジュールをちまちま編集する、そんな馬鹿げたことに無駄な時間と労力を費やすよりも、とにかく作ろうとするソフトウェアをモジュール単位に分割して、何かしら設計してみて、コーディングして、コンパイルして、テストして・・・のサイクルを機敏に繰り返して素敵な製品を作って進化させていこうよ、という

Java開発していてEclipse上の各種プラグインで行なっていた作業が鬱陶しくなったので、自動化してみようかと読んだ。手作業だと作業漏れも怖いし。 初めはシェルやcronの発展型みたいな感覚で、これまでやっていたことを自動化で楽する目的だったのだが、実際使ってみると、結果レポート（グラフ化、差分表示）が有用と思った。プロジェクトの見える化。 例がJavaによるWebアプリ開発だったので自分にはぴったりの内容。 Subversionから取得 JUnitによるテスト WARファイル作成 Coberturaによるカバレッジ Checkstyle、FindBugs、JavaNCSSによる静的解析 ビルドにAntを多用しているのでAntの知識は前提と思う。 私は既にWARファイル作成をAntでしていたベースがあったのでスムーズに移行できた。 これまでの自分はテスト自動化止まりだったけど、さらに範囲

UNIXプログラミングは業務で触らない環境なので、まずはその雰囲気に触れてみようかぐらいの感覚だった。また、Webサーバがらみで非常に勉強になったブログの中で紹介されていたことも理由のひとつ。 正直、Rubyもそんなに触っていないのでなんとなーくの理解で止まっている。が、一時プロセスとスレッドの違いってなんだよっていうようなレベルで？？だったこともあり、その辺の知識を整理できて良かった。Windowsとは意味が違うってなったらもうお終いだが…

連載目次 Team Foundation Server（以下、TFS）および、Team Foundation Service（以下、TF Service）では自動ビルドを実現するビルド・サーバ機能が統合されている。前回はTFS Expressにビルド・サービスを構成して自動ビルド環境を完了させた。 今回はVisual StudioからTFSに接続し、このビルド・サービスを活用して、実際にプロジェクトのビルドを行ってみることにしよう。 【コラム】Visual Studio 2012 Update 3とVisual Studio 2013 Preview マイクロソフトの開発者向けカンファレンス「BUILD 2013」開催初日の6月26日（米国時間）にVisual Studio 2012 Update 3、Visual Studio 2013 PreviewおよびTFS 2012 Update