5つの世界 - The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/5/6 ある重要なことがプログラミングやソフトウェア開発についての文献でほとんど語られず、そのため私たちは互いに誤解する結果となっている。 あなたはソフトウェア開発者だ。私もそうだ。しかし私たちの目的や要求は異なっているかもしれない。実際、ソフトウェア開発にはいくつかの異なる世界があり、異なった世界ではルールも異なっている。 あなたがUMLモデリングの本を読んでも、それがデバイスドライバのプログラムを作るのには役立たないということはどこにも書かれていない。あるいは「(.NETに必要な)20MBのランタイムは問題ではない」というアーティクルを読んでも、それは当たり前のことに触れていない：あなたがROMが32KBの携帯電話のためのコードを書いているなら、それは十分に問題だ！ ソフトウェア開発には
鉄板焼きのお店から学ぶ、バッチ処理“超”入門
鉄板焼きのお店から学ぶ、バッチ処理“超”入門：Javaバッチ処理は本当に業務で“使える”の？（1）（1/2 ページ） バッチ処理を知っている人も知らない人でも 多くの業務システムでは、ユーザーと直接対話処理を行う「オンライン処理」とは別に、バッチ処理が裏方としてシステムを支えています。しかし、裏方としての活躍であるせいか、Webアプリケーションなどのオンライン処理と比較して、表立って取り上げられることが少なく、公開されているノウハウも少ないのが現状です。 本連載では4回にわたって、バッチ処理についてその特徴をまとめ、最近話題になっているJava言語で開発するバッチアプリケーションについて解説します。連載の中では、Javaバッチアプリケーションを実際に体験するために、オープンソースのJavaバッチアプリケーションフレームワークの1つである「TERASOLUNA Batch Framework
ＣＭＭは非人間的か
最近、「ＸＰ（eXtreme Progrmming）」が話題になっています．日経コンピュータ（2001/6/4）にも、大々的に特集が組まれていますので、多くの人は、その存在に気付いていたことと思われます． ＣＭＭの時は、日本で広く知られるようになるのに、アメリカで発表されてから５〜７年もかかったが、ＸＰの場合は、３年弱で日本中に知れ渡ることとなった．これはインターネットの普及が背景にあるのと、ケント・ベック氏の戦略の上手さもあるのではないかと思っています．日本人と違って、彼らは自分をアピールするのが上手い．どうすれば、自分をアピールできるかを、良く心得ています． 私自身、先のオージス総研の「Object Day 2001」でこの問題に関わったこともあって、このあとしばらく、ＣＭＭとの関係について触れていくことにします．また、ＸＰを信奉する人たちが、果たして、本当にＸＰを理解しているのだろ
システム開発のボトルネックはメインフレームに有り - プログラマの思索
システム開発のボトルネックは、メインフレーム（ホスト）の存在そのものにあるのではなかろうか？ JavaでWebシステムを開発していると、いつもそんなことを感じてしまう。 どこの大企業に行っても、必ず10年以上稼動し続けているメインフレームが既に存在している。メインフレームなしでは企業活動そのものが存続できないようだ。最近の流行であるそのメインフレームをオープンシステムへリプレースすることは、どこの大企業でも殆どありえないように見受けられる。 そもそも何故メインフレームが存在するのか、本当の理由を僕は知らないが、とあるBlogでは、「企業の基幹システムは最終的に財務諸表を作るために存在する」と書かれていた。 しかし、財務諸表や損益売上決算書などは、オープン系システムでできないのだろうか？ 普通、どこの大企業でも、メインフレームは顧客データや請求・契約などの会計に関するデータを管理している。つ
道具箱の整理
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ１ヶ月ほど、私的Ｗｅｂサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね～」と話していたのが、非常～に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数（アクティブな人）が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
【再考】XPプラクティスの相関関係 - プログラマの思索
SEA関西プロセス分科会「エンピリカルソフトウェア工学の実践 」を聞いてきた。 さかばさんの講演でした。 最も興味があったのは「効果的なXPの導入を目的としたプラクティス間の相互作用の分析」。 内容は、XPのプラクティスの相関関係を調査したもの。 2004年当時、2個のプロジェクトでヒヤリング形式で調査したとのことだが、下記の結果が得られている。 【1】生産性や向上に役立つプラクティス ペアプロ リファクタリング テスト駆動 シンプルデザイン 更に、保守性に役立つプロセスは、上記＋アルファとして、 コードの共同所有 コーディング規約 【2】要求品質に役立つプラクティス 短期リリース 常時結合 ユーザテスト 計画ゲーム 【3】コミュニケーションに役立つプラクティス 全員同席 計画ゲーム ユーザテスト XPは第2版になって複雑化してきているが、現在のシステム開発をパワーアップさせるプラクティス
Martin Fowler's Bliki in Japanese - 設計力
http://martinfowler.com/bliki/PreferDesignSkills.html 2008/1/18 雇用について考えてみよう。 応募者が2人。どちらも経験が数年間。 青コーナーの人には、あなたが好きな設計スタイルの広範な設計力が備わっている（私の場合だと、DRY、分別のあるパターンの使用、TDD、伝わるようなコード、なんかが挙げられるけど、自分の好きなやつでいいよ）。ただし、彼女には、あなたが使っているプラットフォーム技術についての知識がない。 赤コーナーの人には、そういった設計の知識は（それに興味も）ないが、プラットフォーム技術についての知識はめちゃくちゃある。言語には詳しいし、どのライブラリが使えるかはよく知ってるし、ツールも流暢に使いこなす。 これ以外のことについては（こうした思考実験以外については）、2人ともまったく一緒だとしよう。 また、あなたのチーム
分散プロジェクトの誤謬 - steps to phantasien t(2008-02-26)
タネン本を始めとする分散システムの教科書で必ずとりあげられる話題に "分散コンピューティングの誤謬" がある. 以下 Wikipedia から引用. ネットワークは信頼できる. レイテンシはゼロである. 帯域幅は無限である. ネットワークはセキュアである. ネットワーク構成は変化せず一定である. 管理者は一人である. トランスポートコストはゼロである. ネットワークは均質である. ネットワークプログラミングをしたことがあれば, いずれも該当のバグに思いあたる節があると思う. これらはみな複数台の計算機が関わる際の問題であり, いわばコミュニケーションの問題. 同じ問題は計算機同士に限らず, 人と人の間, 組織の間でもおこる. 順番に例を並べてみる. <伝言や連絡は信頼できる> : できない(よね?) ミーティングには欠席者がいる. 後輩は話を聞いてない. メモもとらない. メールはスパムに
キンタマをつかむ - masayang's diary
どっこいSIerは簡単になくならないが面白い。著者id:mkusunokさんの意見に同意。 実のところ丸投げ自体が悪いとは思わない。経営にとって重要じゃない機能であれば、丸投げで型通りのものを使った方が安上がりだ。 もう一歩進んで、「経営にとって重要じゃない業務であれば、丸投げで型通りのものを使った方が安上がりだ。」とも言える。米国だとADPなんかが有名。ここは人事給与管理の業務を丸受けする会社。[*1] 開発だけを投げちゃうのは、「開発という業務は経営にとって重要じゃない」から。そして、そう判断できるのは「システムの企画から要件定義」と「設計開発」を分離できると経営陣が信じているから。[*2] これまで重要かどうか腑分けせず、さらに丸投げなのに手組みするものだから、おかしなことになっていた訳だが。 お客さんにとって重要な業務のシステムを丸受け（設計、開発から日々の運用まで）することを、自
雑種路線でいこう - どっこいSIerは簡単になくならない
SIerが変わらなきゃってことには同意。けど日本でSIerは当分なくならない。少なくとも解雇規制がなくならないとね。米国で何故ユーザー企業が専門家を雇えるかというと、要らなくなったらクビにできるからだ。例えば汎用機とCobolのシステムをLinuxとJavaに移行する場合は、汎用機オペレータとCobolプログラマを切って、LinuxオペレータｔJavaプログラマを雇い入れる。そういう世界だ。 日本じゃ簡単にクビを切れないから、潰しのきかない技術者はできるだけ雇いたくない。そこのところはSIerに押しつける訳だ。重層的な下請け構造が何故あるかというと、SIerも簡単にはクビを切れないんでバッファを必要とするからで、6次とか7次になれば会社そのものが吹けば飛ぶ世界で、労働基準法なんか形骸化しているしね。 今後はユーザー企業がどんどん内製で出来るようなシステム作りを支援する方向に向かわねばならな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
au W42CA とW42Hに恥ずかしいバグ - Engadget Japanese
DBはグローバル変数 - プログラマの思索
如何にしてソフト会社は崩壊したか