「ITゼネコンをぶっつぶせ」レポート
日本Javaユーザグループ主催で、クロスコミュニティカンファレンス(CCC)が、4/30日に行なわれました。 この稿ではそのうち「ITゼネコンをぶっつぶせ」というBOFについてレポートおよび考察となります。 講演者はSeasarの開発者として著名なひがやすを氏。会場は立ち見が出るほどの盛況ぶりでした(100人以上はいたと思われる)。 ITゼネコンをぶっつぶせ - ひがやすをblog ITゼネコンを倒す方法をみんなで考えよう - ひがやすをblog プログラミングファースト開発 - ひがやすをblog セッション資料はそのうち公開されるのではないかと思います。 本セッションはITゼネコンの問題点をまず挙げ、ひがやすを氏の考える打開案であるところの 「プログラミングファースト開発」についてのプレゼンといった流れ。 残念なのはひがやすを氏が契約の部分に対して解をもっていなかったという点ですね。
6000人が作ったシステムは必ず動く：ITpro
最盛期の開発要員6000人，開発工数11万人月，投資額2500億円，取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ，勘定系システム一本化プロジェクトの成果物である。6000人のシステムズエンジニア（SE）が作り上げた巨大システムは，2008年5月の連休明けに必ず動くはずだ。 23年間にわたって情報システム開発プロジェクトの取材を続けているが，6000人のSEを集めた事例は過去に一度も見聞きしたことがない。世界を見渡してもおそらく例がないはずだ。これから何年間，記者を続けるのか分からないが，今回の三菱東京UFJ銀行を除けば，6000人を動員するプロジェクトを取材する機会は二度とないだろう。 6000人のSEが同時期に集まったのであって，「6000人月」ではない。開発工数は先に書いた通り，11万人月である。この数字も凄い。一体何を作ったのかと思ってしまう。正確にはこのSEパワーは開
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論 Developers [Test] Summit 2008（デブサミTest） 「建前ではなく実際にテストを普及させるにはどうすればいいのか」。2008年4月23日，東京・九段で開催されたテストに特化したソフトウエア開発者向けカンファレンス「Developers [Test] Summit 2008（デブサミTest）」で「【徹底討論】テストなんていらない？！-テストを，どこまでやるべきか？」というパネル・ディスカッションが開催された。 司会を務めたのはタワーズ・クエスト プログラマ兼取締役社長であり，テスト駆動開発（TDD）の日本での第一人者である和田卓人氏。同氏に，オープンソース・プロジェクト「Seasar」のチーフコミッタであるひがやすを氏，テストの
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
角谷HTML化計画(2008-04-12)スはスペックのス〜RSpec(関西弁)の動画
■1 第25回 Ruby/Rails勉強会＠関西 以前にアナウンスした通り、Ruby＠関西の勉強会で発表してきた。予告通りに関西弁で。Ruby＠関西の運営の皆様はもちろん、参加者の皆さまにも非常にあたたかく迎えていただき、楽しい時間を過ごすことができました。okkezさんがつくった「その場で書けるアンケートWebアプリ」を読む限りでは好評だったのでひと安心。 それからそれから特筆すべきは池上さんに会えたこと。ほんとうに光栄でした。感想については、はてブのruby-kansaiタグで目についたものはブクマしてます。当日受けた質問などについての補足は別エントリで書きます。 ikegami: ついに会えましたね。ようこそ、かくたにさん。お察しの通り、私が池上です。 わたし: お会いできて光栄です。 ikegami: いや。光栄なのは私のほうです。こちらへ。お座りください。 以下はスライド。ニコ動
無駄なく確実にテストする---目次
本記事では，ソフトウエア・テストの流れに沿って，その知識と手法を解説する。開発期間が短期化する一方，システムはより複雑化している。このような厳しい状況にもかかわらず，基本を押さえた上で，漏れのない的確なテストを整然と実施することが求められている。テストの手法を学ぶ前提として，テストの流れ，テストの目標，テスト管理という3つの基本知識を整理しておこう。 総論 3つの基本知識 “バグ取り”だけが目的ではない I 単体テスト すべてのシステムで実施される基本的なテスト II 結合テスト プログラムを組み合わせて仕様を満たしているか確認する III システム・テスト 負荷の限界を知る IV 運用テスト 初期稼働のバグを摘出 V テスト管理 データを基に先手を打つ
はてなブックマークの作り直しについて - naoyaのはてなダイアリー
id:naoya:20080320:1206009912 でも少し触れましたが、京都に来てからはてなブックマークの作り直しをしています。どういう意図を持って作り直そうとしているかを述べておきます。 まず大前提として、今のはてなブックマークに追加したい機能、変更したい仕様、本来追加するはずが途中で頓挫したものが結構な数で山積みになっています。それを実現するための基礎作りです。 追加したい機能、変更したい箇所 おそらく新システムの最初のリリース時には、それほど大きく変わった、という印象にはならないかと思います。長く続いているサービスですし、インタフェースや使い方もリリース当初からそれほど大きくは変わっていません。既存システムからの極端な変更は歓迎されないだろうと思っており、まずはオリジナルが持っていた機能をしっかり再現することが重要です。 ただし、既存システムでも問題と思っている箇所は改善して
ソフトウェア開発のメタファ：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発のメタファーはいろいろある。建築、などと対比されることが結構多い。 ここでは、ラグビーで得点する、という活動と対比してみたい。敵の動きはあらかじめ計算できない。監督は試合が始まったら声をかけたりサインを出したりするが、基本的に現場で判断が起こる。つまり、「計画して忠実に実行する」という考え方では得点できない。 野中郁次郎先生が、"The New New Product Development Games"という論文で、製品開発の「知識創造活動」をSCRUMという形で定式化した。これが、アジャイル開発の１つの起源になっている。SECIモデルの知識創造が、現場で起こっており、それを支援するプロセスとして製品開発をモデル化している。 ただ、すべてのソフトウェア開発がこのような「動的な」ものだ、というつもりはない。ものによっては、「計画してその通り実行」というモデルに近いものもある
連載◎開発現場から時代を眺める by arton---目次
ツールは正しく使わなければならない。トラックに荷物を満載して皆でリヤカーのように引っ張って歩いても，それはかえって苦労を増やしているだけだ。見かねてガソリンを入れることや運転免許の取得について教えようとすると，「そんなコストや手間をかける必要はない。これはしょせん最新の荷車だからリヤカーを引っ張る経験さえあれば良いのだ」と胸を張って答える人がいる。だがそれは違う。パラダイム・シフトを甘く見てはいけない。 J2EE（Java2 Platform, Enterprise Edition）はエンタープライズ・コンピューティングに対する最新のツールだが，どうもリヤカー時代の成功体験に引きずられて，冒頭の例え話のような間違いが起きていると感じることがある。プログラミング言語のパラダイム・シフトについては誰もが知っている。Javaはオブジェクト指向プログラミング言語だそうだ。これは今度の荷車は自走式だ
テスト駆動開発のテストは、テストか？―TDD から BDD へ - An Agile Way [ITmedia オルタナティブ・ブログ]
アジャイル開発の中の１つのプラクティスであるTDD(Test Driven Development、テスト駆動開発)に使われるユニット・テスト、というものの役割について、よくテスト界の人との意見の相違がある。テストとしての完全性、や、品質保証についての考え方から見ると、テストとは呼べないのでは？ということ。 最近、アメリカテスト界の有名人であり、アジャイルコミュニティへの貢献も大きい、Brain Marick(www.testing.com/cgi-bin/blog) 氏とメールで話す機会があった。 アメリカでのコンセンサスは、TDDのテストはテストとしては二義的であり、一義的には、「設計ツール」だ これは、以前「テストの役割=進捗管理＋設計戦略」 blogs.itmedia.co.jp/hiranabe/2005/08/sd4__c05e.html で 紹介した、t-wadaさんの「テス
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
2008-02-19
「オープンソースとRIAの融合：Seasar2とBlazeDSでFlex3が加速する」 というテーマで講演します。 フレームワークが、最初登場したときは、必要な機能が足りなかったり、バグがあったりするものです。それが、ユーザに辛抱強く使ってもらうことで、機能が強化され、バグは修正され、安定していきます。 そうすると、ユーザも増えていき、さらに機能も強化されていきます。 機能を強化するというと聞こえはいいのですが、悪い言い方をすると、どんどん肥大化していきます。 肥大化していく中で、あるポイントを過ぎるとユーザは、重い、あるいは、機能過剰と感じ、離れていく。 このことに、フレームワークを作っているほうは気が付かない。自分たちは中身を良く知っているから、覚えることがたくさんあるとは感じないし、自分たちで必要だと思って追加したんだから、不要な機能があるとは感じない。 既存のユーザは、新機能だけを
Geekなぺーじ : オーム社開発部での開発体制
オーム社開発部さんでの本の作り方を取材させて頂きました。 社内で自作ツールをバリバリ作って、出版作業の効率化を行っているのが凄いと思いました。 ただし、今回取材をした内容が行われているのは、オーム社開発部のうちの1グループ(グループは約3名)です。 全体的にこの体制で行われているわけではないそうなので、ご注意下さい。 取材実現の経緯は「オーム社開発部の方とのやり取り」をご覧下さい。 Subversionでバージョン管理 著書の原稿は、XML管理されており、そのXMLはSubversionで全ての著者(監訳者)と共有されているそうです。 Subversionのサーバはインターネット上にあり、各自がリモートで作業を行える環境が整い始めているため、最近では著者と一度も会わずに本が完成するという案件もあるそうです。 フォントなどの問題から、本番環境でのPDF作成はオーム社開発部で毎日行っており、毎
「スはスペックのスRSpecによるテスト駆動開発の実演」 - 角谷HTML化計画 (2008-02-16)
■1 「スはスペックのス〜RSpecによるテスト駆動開発の実演〜」 | View | Upload your own (会場からsshを使えないので、PDFはさしあたってはslideshare.netのダウンロードをご利用ください) なんとか無事に終わりました。この日記で事前に告知できたからか、ustream.tvでの中継を通じて札幌以外の皆さんにもライブで見てもらえたみたい。インターネットすごい。 ちなみに、今回の発表は、デブサミでのid:t-wadaのセッションとテーマはまったく同じなので、デブサミのセッションを偵察していたら、FizzBuzzでも60分ではやりきれていなかった。 だから今回の、Bowling Game Kataは絶対ぜんぶは無理だろうなあ、と思っていたら30分時間を延長してもらえました。感激。札幌 is nice. 発表では質疑応答もできて、ボウリングゲームも完成させ
2008-02-07
以前話していた仙台でのイベントですが、東北デベロッパーズコミュニティの発足会になるようです。 http://www.sendai-cafe.com/modules/piCal/index.php?smode=Daily&action=View&event_id=0000000501&caldate=2008-2-4 http://onbandiary.cocolog-nifty.com/taka/2008/01/post_59ce.html 今まで action service dao って言うレイヤで組んでたので （いつもserviceとdaoは空っぽに近い） actionだけで書く、ってのがちょっぴり違和感。 最初にDaoがいるかって話なんですが、あってもいいと思うけど、今後は使われなくなっていくだろうと思っています。 S2JDBCも当初は、Daoの皮をかぶせるつもりだったんですよ。で
実践ロバストネス分析 第1回 ロバストネス分析の基礎 | オブジェクトの広場
ロバストネス分析は、ユースケースのように文章で記述された要求から分析レベルのオブジェクトを見つけ、適切な単位にまとめることができるものです。また、ソフトウェアシステムが行わなければならないことも適切な単位にまとめることができます。本稿はロバストネス分析の使い方と効果について解説します。 はじめに ロバストネス分析という用語を聞いたことはありますか？ ロバストネス分析を使うことによって、ユースケースのように文章で記述された要求から分析レベル（アーキテクチャが考慮されていないレベル）のオブジェクトを見つけ、適切な単位にまとめることができます。また、ソフトウェアシステムが行わなければならないことも適切な単位にまとめることができます。 これから、3 回に渡ってロバストネス分析について解説します。本稿にあたる第 1 回ではロバストネス分析の使い方と効果について解説し、第 2 回ではサンプルアプリケー
Matzにっき(2008-02-04) - 初心者向けの言語|ソフトウェア開発における初心者
<< 2008/02/ 1 1. [言語] 「ハッカーと画家」の著者が新しいLisp系言語「Arc」を公開 | エンタープライズ | マイコミジャーナル 2. 「セキュリティ、なめんなよ!」 なめねこも一緒に情報セキュリティ強化宣言 | ネット | マイコミジャーナル 3. 「サイオステクノロジーはグルージェントの未来技術に期待し子会社化」：ITpro 2 1. [Ruby] Nimble Method: Garbage Collection is Why Ruby on Rails is Slow: Patches to Improve Performance 5x; Memory Profiling 2. [言語] LuaJIT roadmap 2008 3. [Ruby] What will Matz do? 4. [Ruby] EURUKO 2008 − European Ruby
OTN Japan - 今だからデータ・アクセスを真剣に考える！ 第1回
システムを構築する上で必須となるデータベースアクセスの機能、皆さんはどのように実装しているでしょうか？JDBCで記述/EJB Entity Bean(BMP/CMP)を利用/データアクセスフレームワークを利用、等様々な実装方法を選択されているかと思います。 この連載では、様々な観点からデータアクセスに関わる事項を取り上げ、皆ささんがデータベースアクセスについて、少し考えてみる場になればと思っています。まず今回のデータアクセスことはじめ（前編/後編）では、これから様々なデータベースアクセスに関する事項を扱っていく上でのベースとなる知識を取り上げます。 現在、Javaプログラミング言語を用いてエンタープライズシステムを開発する場合、要件変更への設計・実装の変更の容易性、JDBC、EJB Entity Beanなどのデータアクセス要素技術とのマッピングの容易性、等々の理由により、システム全体を論
構成管理 実践入門 第1章 構成管理入門 はじめに
第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その１ メインライン コードライン編その２ コードラインポリシー コードライン編その３ プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その１ リリース管理 リリース編その２ 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか？ Maven2のインストール まずは試してみよう さらに開発を進めよう 第5章 Maven2ベストプラクティス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://d.hatena.ne.jp/habuakihiro/20080411