タグ

ブックマーク / www.arclamp.jp (6)

  • スクラムは現実解 (arclamp.jp アークランプ)

    アジャイル開発というとXPに代表されるようなエンジニアリング的な要素が強いように感じられる。しかし、プロジェクトマネージメントをアジャイルにすることの方が重要だと思っている。僕が気に入っているのはスクラムだ。既に書籍が出ており、かなり明確に体系化されている。スクラムのプラクティスがなにかというのはWebやで探ってもらうとして、なぜスクラムが良いのか・なにが難しいのか、というあたりを書いてみたい。 スクラムの良さ スクラムの良さはタイムボックスによるコントロールだ。ソフトウェア開発は、要件も技術要素も非常にあいまいで、ようはやってみなくては分からないことが多い。とはいえ何も基準がないのでは混乱をきたす。そこで、ある時間枠(土日を含む30日間)を基準とする。 チームは少人数(7人前後)で構成されており、自分達で期間内の作業にコミットする。作業ゴールは必ずテスト済みの動くアプリケーションで

    essa
    essa 2006/02/17
  • ApacheにAJAX Toolkit Frameworkが提案 (arclamp.jp アークランプ)

    TuscanyはエントリしないくせにAJAX Toolkit Frameworkはエントリします(だってSCAが理解できなかったんだもん)。 日時間20日深夜にApache Incubatorあてに"AJAX Toolkit Framework"が提案されました(提案書のメール)。 これZimbraとIBMのエンジニアが中心というから驚きました。ZimbraといえばBEA Systemsの元CTOスコット・ディッゼン氏を引き抜き、カレンダー、メールなどを含むZimbra Collaboration Suiteをリリースしたことで知られるベンチャー。 しかも、そこらのAJAXフレームワークとは考えていることのでかさが違います。EclipseプラグインとしてAJAX/DHTMLのIDEを提供がメインになるようです。 a JavaScript editor with edit-time syn

    essa
    essa 2005/12/21
  • なぜWeb2.0は楽しいのか (arclamp.jp アークランプ)

    セス・ゴードウィン氏によればWeb2.0は技術ではなく態度です(Seth's Blog : Tim O. on Web 2.0)。では、なぜWeb2.0的であることは楽しいのか? 僕が思うに、それはWeb2.0がアートだから。 Web2.0を示す"Mush-up"という言葉は、元々ヒップホップのアーティスト達が、いろんな曲をコラージュして新しい曲を作り出すことをさします。 AJAXの楽しさはHTMLに従うのではなくHTMLをコントロールし、データを出力するのではなくデータを表現することです。 とくにハックは最高のアートです。僕がはてなマップをハックしてブックマークレットを作った時、いけないことをしているという感覚とともに、不思議な快感を得ることが出来ました。元々表示されていたHTMLをinnerHTML = ''でぶち壊し、同じデータを使って全く違う表現をする。そこには新しい表現があるわ

    essa
    essa 2005/12/19
  • 自分の言葉で表現する (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ アート・リテラシー入門という(冊子)を読みました。アート・リテラシーとは、アートを読み書きする力、主に鑑賞する力ということです。リテラシーとは、元々は読み書き能力のことですが、最近では情報リテラシーが有名でしょう。狭義にはコンピューターの操作技術であり、広義には現代にあふれる情報そのものを整理し理解する力のことです。 さて、ことアートという分野において、堂々と「アートを語る」のは気恥ずかしさを覚えざるを得ません。きっとそれは、日教育が皆と同じ答を得られることを是としているからでしょう。自分の解釈が他人と違っていたら、あるいは学者先生の正解と違っていたら、、、。 しかし、このを読んで感じたことは、アートの鑑賞とは正解があるものでもなく「行動し、発見し、感じ、自分

  • なぜオープンソースを採用するか リスクと責任と価格 (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ とある記事のお仕事でオープンソース・プロダクトを現場に導入するためにはどうしたらよいか(そもそもはDIコンテナを採用してもらうには)という内容を書こうとしたのですが筆が止まってしまいました。 友人とも議論したのですが、この話を突き詰めると「責任の所在」という根論になってしまい、なかなか書きにくいからです。 責任論でオープンソースを語るのは間違い オープンソースには様々な利点があります。 メリット1 コモディティ化の原理で、共有されているからこそ品質が良い メリット2 コードが見れるので、問題が生じてもなんとかできる可能性がある それでもなおオープンソースを採用しないのは「責任が取れない」という理由からではないでしょうか。自分で責任を取らない(責任は誰かに取って

  • ITアーキテクト:実行性のあるプロジェクト・ビジョン (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 前エントリではITアーキテクトについて書いたのですが、僕が考えるITアーキテクトの作業として重要なものが「プロジェクト・ビジョン」です。 建築のビジョンは完成物が主 建築業界の建築家というと、クライアントの示したビジネス・ビジョンに対して、それを実現する建物のビジョンやコンセプトを定義するというものです。もちろん、それが建設できなくてはいけませんから建築学や物理学に基づいたチェックは行われています。 とはいえクライアントが重視するのは建築過程ではなく完成物です。それは「言うからにはちゃんと建つだろう」という最低限の約束が成立しているからです。もちろん建築業界も遅延や不良品と無縁ではありませんが、歴史的に見てびっくりするほど問題ではないでしょう。 システム開発のビジョ

  • 1