リリースは政治パフォーマンス? | スラド
ストーリー by mhatta 2006年09月08日 21時00分 昔々あるところにリリース延期を繰り返していたディストロがありました 部門より Anonymous Coward曰く、"オープンソースだと特にそうだが、ソフトウェア開発の現場の近いところ にいるとリリース作業を行うことが面倒くさく感じられてしまうもの。 CVS(SVN)から拾え、と言いたくなる時もあることだろうが、 Matz氏がふとRuby 1.8.5でのリリースエンジニアリングに関して 遅れても困る人はいないという言葉も含めたことからちょっとした 議論になっている。 これに反応したのは、mputの日記の リリースは政治パフォーマンスなんだよという項目だが、 ここではリリースを 「技術革新だけではどうにも解決できない儀式的・政治的要件から 行われているのである」とし、現代では 「儀式的な傾向はより先鋭化していると感じるし、
IT戦記 - ベンチマークツール公開
最近 またしても、JavaScript のベンチマークを取らなければならない仕事が来たので、 ツールをキレイにしました。 それを公開します。(ダウンロードは一番下にあります。) 使い方 script タグで benchmark.js を読み込んで、以下のように連想配列の関数群を渡すだけです。 benchmark({ 'ほげほげの計測': function() { ...... }, 'ふがふがの処理の計測': function() { ...... } }); 結果は以下のように表示されます。 *** ほげほげの計測 *** result : 0.0011[ms] *** ふがふがの処理の計測 *** result : 0.111[ms] 表示された秒数は 関数の中身を一回だけ実行する時間です。 関数呼び出しのコストは差し引かれています。 また、FireBug を使っている場合は benc
Enjoy×Study - JavaScriptを書き始めるとき
JavaScriptを書き始めるとき、いきなり*.jsやHTMLに書いたりするのではなく、大抵下記に試しに書いて実行してみます。 JavaScript Development Environment JavaScript Shell Web Development Bookmarklets 上記2つのブックマークレット版 JavaScript Shell は、補完機能なんかもあって高機能ですが、IE、Operaだとどうもうまく動きません。 JavaScript Development Environment は、ブックマークレット版じゃないほうはIE、Operaでも動くので、どちらかというとこっち使うときの方が多いです。(Operaでのエラー表示が出来てないみたいだけども…) ブラウザ上で簡単に試せるってのはすばらしいですね。 で、その後に*.jsやHTMLに書いて、後はFireBug使い
滑らかなアーキテクチャ
今回は（アレグザンダーのパターン）シリーズ最終巻「まちづくりの新しい理論」に目を通してみよう。われわれの（アレグザンダーの、ではなく）キーワードは「滑らか」、あるいは滑らかなアーキテクチャ」だ。 「まちづくりの新しい理論」は、「成長する全体」をいかにして作り出すかという理論とその実験の書である。「成長する全体」を作り出すための「最優先のルール」と「7つの中間的ルール」を定め、それをサンフランシスコの5年間、約90のプロジェクトからなるウォータフロント開発計画でシミュレートした過程が述べられている。 われわれは、この最優先のルールと、7つの中間的ルールをわれわれソフトウェアの言葉に翻訳しながら、具体的なソフトウェア開発プロジェクトに対してシミュレートする。 まず、「成長する全体」とは何か。もちろんアレグザンダーはあるべき「まち」を念頭に置いている（それに対して近代的な都市計画にはこれらの性質
仙石浩明の日記 「ソフトウェア開発」は「モノ作り」ではない
いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。 日経ビジネス online の記事に次のようなくだりがあった: 「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」 IT業界
patch/diff Tips
Copyright (c) 2001 Koichi OKADA まず「取扱説明書」をお読みください。 はじめに diff/patch とは diff というのはファイルの差分を作成するツール、 patch というのはファイルの差分からファイルの変更を再現するツールです。 通常 diff で作った差分ファイルをパッチ(ばんそうこう)と呼びます。 ライセンス 多分、気にしなくて良いです。 準備 UNIX の場合 通常 UNIX には diff と patch は標準で入っています。 特に準備はいらないはずです。 Windows の場合 一番手っ取り早いのはcygwinを入れることです。 cygwin はでか過ぎるとか cygwin はちょっとって言う人は vector辺りで win32 native な rcs/diff と patch を 取って来る
自然言語としてのパターン
建築家クリストファー・アレグザンダーが考えていたパターンと、われわれソフトウェア業界で通常パターンと呼ぶものとの間には大きな隔たりがある。われわれが本当に必要としているのはどちらのパターンだろうか？ 実は僕はソフトウェアのデザイン・パターンそのものにはほとんど興味がない。嫌いでも好きでもない。ソフトウェアを書くときに自然に使っているけれど、いまどきのパターンの名前をいっぱい知っているわけではない。4人組（Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides）の本（「オブジェクト指向における再利用のためのデザインパターン」）が出る前から、つまり、それぞれのパターンが自分の名前を持つようになる前から、SmalltalkやC++のいくつかのライブラリやNeXTStepで、多くのパターンを学び、使い、作ってきたけれど、その程度だ。 ソフトウェア
ITmedia エンタープライズ：「地方自治体に金はない、残されているのは時間だけ」――長崎県 (1/4)
自治体にとって地場産業の活性化は重要なポイントであるはずだが、実際にそれを実践できている自治体は少ない。IT調達の現状を見ても、地場企業が受注しているケースは非常にまれである。 それは行政側の努力が足りない部分があると話すのは、長崎県総務部参事監の島村秀世氏。長崎県は業務システムにオープンソースを導入し、地場企業が参加する機会を積極的に創出していることでも知られている。同氏に自治体は電子自治体化をどう考えるべきか、また、オープンソースはそこにどう寄与するのかを聞いた。 自治体のシステムはなぜ高いのか？ ITmedia 業務システムにオープンソースを導入したことによるここ数年の成果を振り返っていただけますか。 島村 わたしが民間から入庁した際、知事から「電子自治体の構築には数百億必要だとも言われているが、この金額は長崎県の現状とあまりにかけ離れている。これを安価に構築できるようにしてほしい。
Irb/TipsAndTricks - 2nd life (移転しました)
http://www.rubygarden.org/ruby?Irb/TipsAndTricks Ruby使いなら誰もが愛用している(と思われる)irbのtipsなどが書かれているrubygardenの1ページなんですが、ここのriを使ってリファレンス引く方法が超便利！refeに変えたら鼻血が出るほど便利だったので紹介。refeとは、 クラス名とメソッド名から Ruby のリファレンスマニュアルのエントリを引く、コマンドライン用のツールです。読みは「りふぇ」。 ri をパクって日本語・RD に対応させたものです。 http://i.loveruby.net/ja/prog/refe.html という青木さん作のツールで、最近はgem化もされてるのでgem install refeでも一発インストールができます。で、先ほどのサイトで書かれてるriの箇所をちょっと変更して、~/.irbrcに
ニーズ指向とシーズ指向(黒須教授のUser Engineering Lecture)
人間中心設計の立場からは、ニーズ指向を重視し、シーズ指向に否定的な言い方をすることが多い。シーズ指向、すなわち技術の種が開発されてからその使い道を考える、というアプローチは多くの場合に、無理矢理使い道を考えるようなケースや一見おもしろそうでありながら実際には普及することのないケースが多くなり、商業的な成功がなかなか得られない。特に、研究所で技術を開発した研究者が考え出した実用アイデアというものは、学会発表や企業の技術展示などにもしばしば見受けられるが、商品化の「センス」が今ひとつ、というものが多い。商品化のセンス、という表現をしたが、これは単に直感が優れているかどうかという問題ではない。ユーザのニーズや必要性に基礎をおいたアプローチをとれば、その機器やシステムの存在理由が了解性の高いものになるし、そのアプローチをとらなければ、何のために必要なのかがわかりにくいものになってしまう、ということ
kuranukiの日記 改善型開発について
現在のシステム開発という開発モデルを考えてみると、そのシステムを必要としており開発の依頼を発注する発注側と、実際の開発作業を請け負う開発側の間で、プロジェクトに対し契約を結んだ段階からシステム開発は始まる、というのが当たり前の話。そして、この当たり前と思われている関係でビジネスを続けると問題があるのでは、と考察したのが以前のエントリ、「ディフェンシブな開発*1」だった。 今回は、その当たり前だと思われているところについて、発想の転換を取り入れて考えてみようと思う。社会における通念や物事を大きく変えるためには、コペルニクス的転回が必要だからだ。 ノウハウを集約できないSI企業 まずこの「プロジェクト開始してからシステム開発を始める」という点について、ディフェンシブであるということ以外にも、SI企業として重大な問題点が隠されている。それは、IT技術に対するノウハウの蓄積に関する問題である。今の
- データベースの進化的設計
データベースの進化的設計 Martin Fowler Pramod Sadalage 原文(Evolutionaly Database Design) ここ何年かで私たちはアプリケーションの開発に即してデータベースの設計を進化させることを可能にする技法を編み出した。このことはアジャイルメソッドにとって非常に重要である。この技法は継続的インテグレーション及び自動化されたリファクタリングをデータベースの開発に適用し、かつDBAとアプリケーション開発者が密接に協力することによって成り立つ。この技法は開発中のシステムや既に開発されたシステムに対しても機能する。 変化に対応する 制限事項 プラクティス集 DBAは開発者と密接に協力し合う 全員が自分のデータベースインスタンスを保有する 開発者は共有マスターに頻繁に結合する スキーマとテストデータから成るデータベース すべての変更でデータベースのリファ
小野和俊のブログ:アプレッソのジョエルテスト判定結果
今週末は熱海の温泉に行ってきた。 行き帰りの新幹線で読んだJoel on Softwareは衝撃的に良かった。 この本はソフトウェア開発に携わるすべての人が読むべき本だと真剣に思う。 中でも第三章に書かれているジョエルテストが面白かったので、 これをアプレッソに当てはめて判定してみることにした。 現在のアプレッソでは、12のテストのうち、10項目が当てはまっている。 該当する項目が2から3の会社が圧倒的に多いということなので、 判定結果としてはかなり良い方だと思う。 しかし、今は導入した後でその効果を知っているから全面的に賛成できるのだが、導入する前は、 「今のままで特に大きな問題があるわけでもないし、 新しい方法を導入することにはリスクも伴う。 このままでも良いのではないか。」 という理由で導入を躊躇したものも多かった。 これらはどの項目についても、マネージャーがどんなに反対したとしても
＠IT：特集 「テスト駆動開発」はプログラマのストレスを軽減するか？
新しいソフトウェア開発技法へチャレンジできるか？ ソフトウェア開発の世界にも日々の進歩がある。そしてその中には、使えばさまざまな恩恵を受けられる技法もある。しかし、それらを現場ですぐに活用できるとは限らない。例えば、1990年代末に生まれ、1つのブームを形成したエクストリーム・プログラミング（XP）という開発技法がある。これは、とても優れた開発技法だと思うのだが、開発プロジェクト単位で、顧客まで巻き込んだ形で使われることが前提となっている。しかし、顧客ぐるみでまったく新しい方法にチャレンジできるかといえば、できないことの方が圧倒的に多いだろう。では、エクストリーム・プログラミングの技法を全部使おうとせず、使うことができる部分だけを取り出して試みることができるかというと、そういうわけにもいかない。エクストリーム・プログラミングは、いくつかのプラクティスと呼ばれる項目から成り立っているのだが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2003年04月21日・エディタ「PeggyでHSPとRCSを使おう」・100点
http://www.yasuhisa.com/could/entries/001015.php
)) DEVLISTING
Apple Developer Documentation
リレーショナル・データベースの世界
Amazon.co.jp: Java・J2EE・オープンソース Spring入門 ~より良いWebアプリケーションの設計と実装: 長谷川裕一, 伊藤清人, 岩永寿来, 大野渉, (株)豆蔵: 本
