概要：アマゾンが発表した新しいKindleは79ドルという価格攻勢により電子書籍端末の決定版となった。アマゾンが電子書籍市場を支配することで、読者、出版社、書き手のあり方はまったく異なるものとなっていく。 79ドルのインパクト： ここ数年続いた電子書籍をめぐる狂想曲は、完全に終わった。終わりを告げたのは、始まりを告げたのと同じ、アマゾンだった。9月28日に開催されたアマゾンのKindle発表会は、そう確信するに十分な内容であった。 アマゾンが最初に電子書籍端末Kindleを発表したのは2007年11月のことだ。初代Kindleは白黒のE Inkディスプレイ、やぼったいデザイン、電子書籍に対応するだけの単機能性、399ドルといった価格で、売れるはずもないという批判も多かった。しかし実際は発売当初から売り切れの続く人気製品だった。もっとも、ハードカバーならば何十ドルもする書籍が電子書籍なら9.

タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し

メモ。 アジャイルとウォーターフォールを対比させるのは違和感があった。ので、少し考えてみた。 アジャイルソフトウェア開発宣言にある「包括的なドキュメント」とか「契約交渉」とか「計画に従う」とかと、「対話」「顧客との協調」「変化への対応」とかは、わりとばらばらなお題目が並んでいるように見える。少なくともこれがMECEだと思う人はいないと思う。 ばらばら並んでいる項目の共通点、類似点は何か。それはたぶん、「顧客」と「開発者」という2つのロールを仮定して、そのロールの人同士の間でのコミュニケーションコストを最大化する（という言い方が悪ければ「最大限許容する」と言い換えてもいい）というものだろう。文書や契約や計画は、あらかじめ（多少はコストをかけて）まとめておけば、それ以降のコミュニケーションは省略できる（ような気になる）、というものだろう。ツール・プロセスも同様だ。一方で、個人や対話、顧客との協

パラダイムを学ぶことと、実際にデリバリーすることとのバランスについて。あるいは転職報告。 導入 8月1日にグロースエクスパートナーズ株式会社に入社しました。人生で2回目の転職となります。入社してまもなく一ヶ月が経とうとしていますので、本日はその報告を。ブログ、翻訳、プレゼンに続く舞台裏記事の第4段ですね。私とは違う物事のとらえ方をする方々も多くいらっしゃることは重々承知しておりますし、それを批判するものではないこともあらかじめご了承ください。 転職をした理由 私が7月まで勤めていたのは、いわゆる「ITゼネコン」と呼ばれる元請けSIerでした。開発の実務は協力会社さんにお任せしつつ、自分はメールと打ち合わせに埋もれる日々を送っていたわけです。要件定義から保守まで一通り経験できたという意味で学ぶこともありましたし、アーキテクチャ策定やデータモデル設計のようなことも隙を見てやっていたことは事実で

ロンドンその他都市のあの「愚者の祭り」から1週間が過ぎて、あの月曜日の事情が少しずつ分かってきた。5年以上ロンドンに住んでいる者としてあれこれ考えることも多かったし、諸事情で「暴徒」のおかれた環境について少し知る機会もあったので、少し書いておきたい。 あの日起こったことは何だったのかこれについては、無軌道な若者の暴走と言うことで概ねコンセンサスは取れているように思う。以下のtogetterは現状ロンドンで理解されていることに近い。 http://togetter.com/li/172491 警察が、最初の暴動の抑制に失敗したことで、「今なら何をやっても大丈夫」という無礼講的なお祭り騒ぎが一挙に拡大したと言うことなのだろう。周囲の興奮と燃えさかる炎に当てられて、「乗るしかない、このビックウェーブに！」とばかりに舞い上がってしまった子供が相当数いたであろう事は間違いない。（ロンドンで逮捕された

著者：ケヴィン・ケリー ( Kevin Kelly ) 訳　：堺屋七左衛門 この文章は　Kevin Kelly による "When Hard Books Disappear" の日本語訳である。 紙の本が消滅するとき　　When Hard Books Disappear 紙の本は絶滅の途上にある。 生物学には「タイプ標本」という概念がある。あらゆる生物の種には、顕著な差を持った多数の個体がある。たとえば、米国には何百万羽ものコマツグミがいる。それはすべて、学名turdus migratoriusという種類の鳥に見られるコマツグミらしさを備えている。しかし、他の鳥を「コマツグミに似ている」とか、あるいは「まさしくコマツグミだ」と科学的に表現する必要があるとき、その何百万のコマツグミのどれと比較すればよいのだろうか？ 生物学者は、一つの個体を任意に取り上げて、それが種全体を代表する原型であるこ

僕は、twitterできわめて少数の人しかフォローしてません。そんな僕のtwitterタイムラインでも、何度も言及されていたのが次のブログエントリー： いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ 本文は「なるほどね」という感想なんですが、コメント欄に驚くべき発言があります。 まずは本文から紹介すると、「いっしょに仕事をしたいプログラマ 5つの特徴」が挙げられていて、それらの特徴で「欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう」と。 5つの特徴のひとつに「人のコードにパッチを送る」（適切なパッチを書ける能力）があるのですが、それに対するコメントが： ミッションクリティカルなシステムでは自分が再利用しようとする既存コードにバグがあった場合は、まるっとコピーしたうえで修正したものを使うことが多いです。 「まるっとコピー」って、い

FizzBuzzをサービスにする「CodeEval」が面白い、というエントリーは、プログラマ採用に必要なスキル判定とリクルーターのマッチングをサービスとして提供するベンチャーの紹介でした。 しかし「良いプログラマ」というのがいるとして、それを見るのに、アルゴリズムのコーディングなんか必要なのか、そんなもので測れるのかという根本的な問題があるように思えます。 最近、RubyInsideで見かけた「Practical Tips for Hiring Ruby Web Developers」（RubyのWeb開発者を雇うための実践的なティップス）と題されたエントリは、まさにこれに答える内容で興味深いです。オーストラリア人開発者のTim Gohさんは、CのatoiだのQuickSortだのを書かなきゃいけなかったことなんて最近ないでしょ、Fizzなんてプロダクション環境で出力したことねぇよとして、

ちょっと興味深いエントリが目に留まりました。「プログラミングへのこだわり」を方向づける: 設計者の発言基本的に、この方自身もプログラマーや開発者をされているようですし、他のエントリを読んでも「プログラマーの地位向上をすべき」ということで、私にとっても非常に共感することをおっしゃっているのです。それでも、ちょっとこのエントリの内容については疑問に思うところがあったので、勝手ながら私の意見を書かせていただきたいと思います。 業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 これは、まさにおっしゃる通りですね。もちろん、可読性ということもあるため、厳密には最少のコードが最良とい

もうすぐ4月になると言う事で、時事ネタ。コの業界、特にエンタープライズなSIerやその協力会社なんかに就職される方向けに、夢や希望をなるべく潰さないつもりで書いてみる。 PGになってはいけない SIer用語でPGって言葉があります。あとSE、PL、PMとかありますけど、序盤は関係ありません。これらは契約形態は違うのですが、作業内容よりも主に単価で分けられます。で、PGは「末端作業員」と言う意味です。 PGはプログラマではありません。プログラマに失礼です。PGにプログラムは作れません。また、PGはコーダーでもありません。PGにコードは書けません。PGはSEの指示の元、似た事をしている既存システムのコードを切り貼りして、それっぽく動くものを作る下請け作業員でしかありません。そこに創造的な仕事は一切ありません。多くのPGは自らの意思か外部からの圧力によって、思考を放棄もしくは停止しています。PG