「オープンソースが成し遂げたものづくりやコミュニティのような，小さくても確実な幸福感が得られるような場所が，よりよく生きたいと思っている人たちの数だけ，ネットの上にできたらいいな」（梅田氏）。「僕が追求するのはオープンソースであるかどうかよりも，個々の技術者が幸せかどうかなんです」（まつもと氏）――梅田望夫氏とまつもとゆきひろ氏の対談，後編は新しい時代の新しい幸福とそれを実現する生き方へと話が及ぶ。 ＜＜前編へ＜＜ ネットの上の「小さくとも確実な幸福感が得られる場所」 梅田　まつもとさんにとっての「幸せ」って何ですか。 まつもと　ご飯が食べられる範囲で，好きなことを日がな一日やっていられれば幸せですね(笑)。 梅田　「ご飯が食べられる」の定義もいろいろありますよね。今日飯を食えればいいとか，蓄えがないといけないとか。 まつもと　蓄えはあったほうがいいですね。生活に不安がない程度に。 梅田　

ここ数日、私はずっとペアプログラミングをしている。 ペアプログラミング自体は、これまでに何度も経験したことがある。 しかし今回の試みが今までと違うのは、 一日中、ペアプログラミングしかしないという点である。 １セット1時間半、15分の休憩を入れて、 ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。 このところ、これを何日も続けている。 こうやって、ある程度ストイックに続けてみることで、 わかってきたことがある。 それは、ペアプログラミングにはメガトン級の破壊力があるということだ。 プログラマーは絶えず誘惑にさらされている。 調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、 考えたことをメモするついでに2時間かけてブログを書いてしまったり、 仕事の用事で知人に IM したついでにしばらくだべってしまったり、 Twitter に書き込んだついでに Friends

スラドのペアプログラミング、実践してますか?と、そこへのコメント群を読んで思ったことをいくつか。 そもそもの目的 タレコミさんの文章では 一部研究によれば生産性が1人で作業した場合の2倍以上になるともされていますが などと書かれているけれど、その生産性ってなんなの？　という検討をしておかないとペアプロ導入の意味はなくなる。　単純に単位時間の成果物量(LOCとかFPとか）を測定するのは意味がなくて、品質まで考慮するべきであろう。http://slashdot.jp/askslashdot/comments.pl?sid=381687&cid=1256285 のコメントが的確。 仕事である以上速い遅いはほとんど関係なくて『どうすれば正確に（仕様通り）プログラミングできるか？』『どうすればバグ発生率の軽減できるか？』という課題に対する１つのアプローチがペアプログラミング． 自分のところのささやか

「データベースはブラックボックス。どんなSQL文を投げたらどんな結果が返ってくるかさえ知っていればよい」---そう思っている人も多いかもしれません。 しかし，本物のソフトウエア・エンジニアを目指すのであれば，データベースが動く仕組みを学ぶことは避けて通れません。パフォーマンスなどに問題が生じたときどこから手を付けていいのか皆目見当がつかない，といった事態に陥りかねません。 市販のRDBMSの内部はかなり複雑ですが，基本的な部分を理解するのはそれほど難しくありません。この特集でデータベースの動く仕組みを理解してください。 イントロ ●ブラックボックスのままでいいの？ 基礎から理解するデータベースのしくみ（1） Ｐａｒｔ１ ●SQL文はどのように実行されるのか 基礎から理解するデータベースのしくみ（2） 基礎から理解するデータベースのしくみ（3） 基礎から理解するデータベースのしくみ（4） 基

2006年06月20日18:20 カテゴリWEB+DB PRESSLightweight Languages Haskellは難しくない--こともある。 まだVol.33も正式発売されていないというのに、すでにVol.34の原稿書きにいそしむ今日この頃。実はその記事の一つがHaskellだ。「Powered by Ph.Dな言語の解説を中卒がやるのってどうよ?」と我ながら思うが、自分で言うのもなんだがむしろいい記事に仕上がってきているのを感じる。 Matzにっき(2006-06-13) 私:「Haskell難しいですから」 「ええっ？」 というわけで、予告ついでに、HaskellよりRubyの方がずっと難しいことを一つ上げさせていただく。 それは、なんといってもProcオブジェクトだ。 「Rubyの美しくない部分を一つあげよ」と聞いて、真っ先に思い立つのがこれだ。 例えば、logbXをカリ

2004年27件，2005年24件，2006年28件，そして，2007年86件。 これはITproに掲載されたニュースのうち，タイトルに「中国」という単語が含まれている記事の検索結果である。2007年の86件は，11月13日時点の数字なので，年間では100件を超える勢いだ。平均20数件だった2004年～2006年に比べて，一気に4倍増である（ちなみに，タイトルではなく本文で「中国」に言及している記事も含めると，11月13日時点で313件）。 一口に中国のIT関連ニュースと言っても様々だが，オフショア開発（海外のIT企業にソフトウエア開発を委託すること）をはじめ，日米欧の企業が中国の企業と手を組むというニュースがよく目に付く。例えばこんな具合だ。 ・中国・無錫市、大連に続くオフショア拠点に名乗り（2007/10/19） ・日立情報が中国でアウトソーシング事業、現地法人を通じて開始（2007/

顧客別に営業の基本構想をまとめた「アカウントプラン」は、今やソリューション営業に不可欠なツールと言えます。この連載ではアカウントプランに対する誤解を解いたうえで、顧客の経営課題を把握し、ツボを押えたソリューションを提案するうえで強力な武器となるアカウントプランの作成・活用法を基礎から解説します。 第1回　計画は営業の基本業務，提案に必須のツールを作れ 第2回　「顧客の概要」の日々更新で営業活動の品質アップを実現 第3回　営業プランは顧客本位を貫け，顧客の経営課題からテーマ抽出 第4回　SWOT分析を駆使して解決すべき顧客の課題を抽出 第5回　顧客の課題を体系的にとらえソリューションにつなげよ 最終回　計画は立てるだけでは意味なし，顧客の深堀のために活用せよ

ソフトウエアの改造がトラブルの温床になっている。改造案件が増える一方で，改造ならではの方法論が未熟だからだ。プログラマやSE，プロジェクト・マネージャが一丸となって「改造力」を高めるノウハウを解説する。 第1回　ソフトウエア改造力が足りない：変更ミスがトラブルの温床に 第2回　ソフトウエア改造力が足りない：工数膨らませる影響調査と確認テスト 第3回　対応すべき案件を選ぶ：要望を集め，工数を概算する 第4回　対応すべき案件を選ぶ：費用対効果で優先順位を判断する 第5回　改造の影響を調べる：詳細な工数とソースコードの変更箇所を洗い出す 第6回　改造の影響を調べる：ドキュメントをまとめ作業計画をレビューする 第7回　テスト範囲を最適に決める：過去のテスト項目集めて漏れを減らす 第8回　テスト範囲を最適に決める：シナリオや環境整備でテストを効率化する 第9回　テスト範囲を最適に決める：本番リリース

「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします。（編集部） バッチ処理の変遷 Javaの登場以来、ホストコンピュータ、専用サーバなどで動いていた数多くのレガシー（既存資産）システムが、Java環境へ移行してきました。Web上のオンラインアプリケーションにおいては、特にJavaの活躍の場が増えたといってもよいでしょう。 その中でも移行が遅れており、旧来のマシン環境、旧来の言語での利用が続いてきたものに「バッチ処理」が挙げられます。 ■そもそも「バッチ処理」とは何か？ ここでいうバッチ処理はWindowsのバッチファイル（.bat）を示すのではありません。大量のトランザクションデータを扱い、大量のデータを順次処理することを示します。 また、バッチ

第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21

私は以前SIベンダーに所属し，Web系システムのソフトウエア・アーキテクチャを設計，開発していました。正直に打ち明けると，そのころはシステムの設計や開発と比べ，運用や保守をあまり楽しい仕事だと考えず，そうした仕事を避けていたと思います。こんなことを書くと怒られるかもしれませんが，ITアーキテクトを志す人には，そういう方が少なくないのではないでしょうか。 現在は音楽配信サイトのベンチャー企業を立ち上げ，自分たちで設計・開発したシステムを自分たちで運用・保守する立場になりました。そしてやってみて，私は心底ガックリしました。ほかでもない，自分の設計にです。本エントリではこの経験を基に，「ITアーキテクトと運用・保守」について，考えをまとめたいと思います。 まずは，ちょっとまどろっこしいかもしれませんが，ITアーキテクトと呼ばれる役割の仕事について，レストランのシェフに例えて少し想像しながら考えて

PostgreSQLをクラスタリングするツールの新版「pgpool-II 2.0」が11月16日，リリースした。データベース・ノード間でレプリケーションを行っている際，障害が発生したノードが復活した時に再同期させて復帰させるオンラインリカバリ機能などを実装した。 レプリケーションの高速化や，複数のバックエンドから異なる結果が返ってきた場合に，同じ結果が多数返ってきた結果を信頼する「多数決方式」の実装などを行った。またノードを切り離した際と復帰した際に，ユーザが設定したコマンドを実行する機能なども備えた。 pgpool-II 2.0はSRAOSS日本支社が中心となっているコミュニティ「pgpool Global Development Group」による開発されている。オープンソース・ソフトウエアとして配布されており，以下のURLからダウンロードできる。 http://pgfoundry.o

今日のソフトウエア開発において，Javaは最も重要なプログラミング言語あるいは開発環境といってもいいでしょう。そこで，ITproではJavaの最新技術についての連載を掲載しています。著者はJavaプログラマ向け情報ページ「Java in the Box」で有名な櫻庭祐一氏です。

業務分析に焦点を絞ったパターンは，Process four（P4）と呼ぶ4人の開発者が提唱した「ワークフロー・パターン」（詳細は，http://www.workflowpatterns.comを参照）だ。業務フローを作成する際のひな型として「基本的なパターン」や「先進的な分岐と結合に関するパターン」といった六つのカテゴリに分け，全部で20種類のパターンを定義している（表1）。 表1●ワークフロー・パターン（Workflow Pattern）の概要 業務フローを作成する際に，各アクティビティの配置をどうするかについて示したパターン。六つのカテゴリに分かれ，全部で20種類のパターンがある [画像のクリックで拡大表示] Michael Havey氏が2005年に著した「Essential Business Process Modeling」という本の中で，業務プロセスを設計する際のパターンとして