ソフトウェア開発者のための推薦図書
Code Complete 2 [ Code Complete第2版―完全なプログラミングを目指して (上・下) ] スティーブ・マコネルのCode Completeはソフトウェア開発者のための｢楽しい料理｣本だ。この本を読むということは、自分の仕事を楽しんでいるということであり、自分のすることに真剣であるということであり、もっと向上したいと思っているということなのだ。Code Completeの中で、スティーブは平均的なプログラマが読む 技術書は年に1冊に満たないと指摘している。この本を読んでいるという時点で、あなたはおそらく周りにいる開発者たちの90%と違う行動を取っていることになる。それもいい方向にだ。 私はこの本がすごく好きで、ここから自分のWebサイトの名前(Coding Horror)を取ったくらいだ。この本ではやるべきでない悪い例には"coding horror"アイコンで印
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
Getting Real by 37signals
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> �c\�\U �dt�\U Getting Real The smarter, faster, easier way to build a successful web application Start reading →
スケーラブルWebサイト
ユーザー数の増加に伴って、その規模を容易に拡大できるスケーラブルなWebサイト構築について解説した総合ガイド。何百万人ものユーザーに対応するWebアプリケーション用のインフラを構築するための立証された手順を、実践的な例と最先端テクニックを使ってソフトウェア/ハードウェアの両面から解説します。限られた予算で今日のWebアプリケーションに耐えうる性能を実現したいすべての開発者にとって有用な1冊です。 翻訳者によるサポートページ。 訳者まえがき まえがき 1章 はじめに 1.1 ウェブアプリケーションとは？ 1.2 ウェブアプリケーションの構築法 1.3 アーキテクチャとは？ 1.4 どう始めるか 2章 ウェブアプリケーションのアーキテクチャ 2.1 階層化されたソフトウェアアーキテクチャ 2.2 階層化技術 2.3 ソフトウェアインタフェースの設計 2.4 A地点からB地点へ 2.5 ソフトウ
コンペに勝つ！ (arclamp.jp アークランプ)
コンペに勝つ!はセントラル硝子国際建築設計競技の40回を記念して、審査員である建築家陣（山本理顕さん、伊藤豊雄さん、隈研吾さんなど）が行なった講演を記録したものです。 セントラル硝子国際建築設計競技はアイデア・コンペと呼ばれているもので、実現できるかは関係ありません。それよりも与えられたテーマ、例えば第40回であれば「まちのランドマーク」に対して、どのような解釈を与え、どのような解を導いたかが純粋に評価されます。 第40回の最優秀作品はチェコからの応募で、ユダヤ人の虐殺があった村々に死者を弔う小さなモニュメントを作るというものだそうです。地面に掘られた円形の穴が死者の数や年齢の総数をあらわしています。ランドマークといえば象徴として巨大な建造物になりがちです。しかし、それをあえてささやかなモニュメントにすることで強いメッセージ性を持つことができています。 サイトより直接リンクで引用 では、本
「技術トレンドのおさえ方」を開発の現場に寄稿 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 開発の現場 vol.006（2006年10月発売）の特集「はじめての開発リーダーToDoリスト」において、「技術トレンドのおさえ方」を寄稿しました。 つけていただいた副題は、 3つの力「見極める」「説明する」「活用する」で"使えるもの"を的確に把握しよう 少しだけイントロを。 優れた新しい技術をたくさん知っていれば技術を「おさえる」ことができるようになるのでしょうか。それは残念ながら違います。それに、それだけの技術情報をすべてチェックすることは難しいでしょう。 自動車業界を例に考えてみましょう。優れた最新の技術を結集したものの代表といえばF1カーが思い浮かびます。F1カーで使用する優れた技術を知っているというのは良いことです。膨大な労力をかけて得たその知識は大変貴重な
「ソフトウェア開発の名著を読む」を読む
「めいちょ」と銘打たれるとなかなか手が出せないもの。大著であることも多いし、何より難しそうなイメージが先行してしまう。さらに、たいていは「古典」…なので、書店で平積みになってる賞味期限 1 年のハウツー本みたく目に入ってこない（←こちらからアプローチをかけないと手に入らない）。 というわけで敬遠していた方へ朗報。「ソフトウェア開発の名著を読む」で手軽に「めいちょ」の品定めができる。この手のカタログ本だと、「コンピュータの名著100冊」が有名だが、これはたったの8冊の紹介、しかも新書なので30分で読める。 しかも、言語は問わない。もちろん FORTRAN や Pascal といった「古語」のコードが出てくるが無問題。伝えたい何か、例えば「プログラミング作法」や「よいコードを書くための習慣」を表現するための、レトリックとしてのコードなのだから。 とどめは、昔から、誰からでも、何度でも指摘されて
要求仕様戦争（その3）
■仕様書をどうこうする――「要求」の見える化 「要求を仕様化する技術・表現する技術」がオススメ。「要求とは」「仕様とは」からはじめて、仕様戦争までの経緯、回避するための具体的施策までが分かる。「Excel を用いた仕様書」はなかなか興味深い。 著者は「要求」と「仕様」の関係をロジックツリーに見立てる。こんなカンジ。仕様1～n を実装すれば要求Ａが実現する、という仕掛けだ。 ┌───┐ │要求Ａ │ └┬──┘ ├─仕様1（スペック1-1,1-2,1-3...） ├─仕様2（スペック2-1,2-2,2-3...） ├─ … └─仕様n（スペックn-1,n-2,n-3...） まぁ、こんなにキレイにならないだろうが、「このスペック（群）で"やりたいこと"は実現していると言えるのだろうか?」という視線が、どのフェーズでも配れるという点は素晴らしいと思う（実際に目配りするかどうかは別として）。 本
開発の現場vol4に寄稿しました (arclamp.jp アークランプ)
開発の現場 vol4（2006/4/12発売）の『「上流脳」をつくろう！』において、パート3の「フレームワークの基礎知識」を寄稿しました。 主な内容は枠組みのワクグミを見抜こうで紹介したものですが、より詳細に読みやすくなっておりますので是非。 他にも要件定義、設計と一通りの作業について俯瞰することができます。 要件定義は永和さんで、お得意のコミュニケーション重視のお話。そしてアーキテクチャは豆蔵の長谷川さん、岩永君の師弟コンビが大活躍です。長谷川さんの語り口はやさしくていいですね。っていうか、僕の章がトンガリ過ぎな気がしてきました（ｗ。 プロジェクト全体と通じて必要なことは、常識をもって当たり前のことを積み重ねるという以外にはありません。そういう意味で教科書的な知識は不可欠です。で、教科書のままじゃだめなんだと気付くところから、次のステージが始まるように思います。この本に書かれていることは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
