web.xmlのxsi:schemaLocation - wyukawa's diary
[Seasar-user:12909] sa-struts-tutorial の web.xmlについて SAStrutsのチュートリアルとブランクのweb.xmlの記述ミス - しんさんの出張所 はてな編 で指摘されているように、 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" ではなく xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" が正しいみたい。 http://www.atmarkit.co.jp/fjava/javatips/037container004.html http://www.techscore.com/tech/J2EE/Se
Redmineは何？という人へ - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
常識という罠 - 人は知識を蓄積するほどバカになる - cypher256's blog
おそらく何でもあてはまるのだと思っていますが、例えばフレームワークであれば、それを知らない人を主体で、＋知識を有する人をサブとして、作り上げていくべきです。Java であれば、それさえも知らないのが理想的。 知らない人にそれは常識的におかしいとか言ってはだめで、ほとんどの場合、間違っているのは知識（思い込み）と過去のアーキテクチャです。フレームワーク系の ML に聞きにくるのは結構スキルがある人。文句つけてくるのも、それ相応の知識がある人しかいません。経験のある人間が集まって決めた仕様が、経験のない人に使いやすいわけがありません。誤解を恐れずに言えば、民主主義と統率統制された（ように見える）社会主義と言えるかもしれません。崩壊しやすいのは、道を誤るのはどちらでしょうか？ 冒頭で言いましたが、これは技術的なことに限りません。昔、とある営業交渉中に先方（私より明らかに営業経験は上）が「それは商
冗長さが除去されて言語が簡便になれば大規模開発にも役立ちます - 矢野勉のはてな日記
Java t_yanoさんのコメントへのコメント - kwatchの日記を読んで、感想などをコメント欄に書いてたのですがコメント欄を占拠するくらい長くなったのでこっちに移しました。そうですね、「書きやすさ (あるいは読みやすさ)」と「ミスをさせないこと」は両立する、という意見に賛成です。ここで言いたかったのは、書きやすさ（読みやすさ）の利点、というのは現場では即座には理解されにくい、ということなんです。一方、ミスをさせない利点というのは、現場が今まさに求めているものでもあるし、比較的すぐに理解される傾向があるように思います。だから後者ばかりを求める傾向がある。「分かりやすさと簡潔さは大規模開発にこそ必要」という意見について実は私は賛成ですよ。「IDE使えば書きやすさが変わらないからいいや、というのは片手落ちのように思います」という部分についてもね。 今回の話、ちょっと個々の改善例により過
批判を受けながら立ち位置を決める - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
ユースケース駆動開発実践ガイド - プログラマの思索
「ユースケース駆動開発実践ガイド」を読んで、この手法がまさにRUPなんだな、とようやく気づいた。 理解した内容をまとめてみる。 ＃一部はメモなので論理的整合性は無視。 【1】ドメインモデルはプロジェクトの用語集 「ユースケース駆動開発実践ガイド」では、プロジェクトで実際に使われている単語を全て収録した「生きている」辞書だ。 単なるプロジェクトの用語集よりもはるかに優れている。 それぞれの単語間の関係がグラフィカルに表現されているから。 【2】ユースケースは叙述的に書く 「ユースケース駆動開発実践ガイド」では、ユースケースに「～しなければならない」という命令形が混じる時がある。 機能要求は「～しなければならない」のように指示的に書かれた要求。 機能要求を分離してユースケースに割り当てなければならない。 ユースケースに機能要求が混在している時は、ユースケースが良くない兆候。 ユースケースは要求
Javaの冗長な記法って小クラス主義の現れではないかな - 矢野勉のはてな日記
Java以下は無駄に長い駄文です。なんか書いてみたはいいもののうまくまとまらなかった。ごく一部しか表せなかった気がする。これではInputStreamReaderとかがたくさんオブジェクトを連結しないと使えないめんどくささをなぜ許容できるか、しか表せてない... もともとは「 Java における本質的でない記述がどのように大規模開発に役立つのか - kwatchの日記」がらみの話です。文中にいくつか「アクセッサが簡潔に定義できない」「FileReader に文字コードを渡せない」のような例があって、「それらが改善されたら大規模開発になにか不利益があるのかどうか」という具体的な質問があったので私はそこにコメントしときました。私はコメント欄に「不利益なんてないよ」と回答しました。実際のところ、後方互換性が維持され、言語としての統一性が維持されるなら別に不利益なんてあるわけない。あるとしたらマネ
大規模プロジェクトはバージョン管理が重要になってくる - プログラマの思索
ソース管理について良い記事があったのでメモ。 Subversionベストプラクティス 複数のアジャイルチームでのバージョン管理 「複数のアジャイルチームでのバージョン管理」の指摘は非常に重要なので、まとめておく。 【1】バージョン管理の目的 1-1. Fail First コードのコンフリクトや統合の問題を早期に解決する。 1-2. 常にリリース可能 どんなに悪いイテレーションでも、その成果物はリリース可能にならねばならない。 1-3. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が
Flickrでかっこいいデスクトップを探してみた
自分の仕事環境をもっとよくするために、参考になりそうな机は無いかなーとFlickrで検索してみました。 特にデザイン系の会社だと、カッコいいオフィスがありそうなので、もしご存じの方いましたら、できれば写真があるページを教えてもらえませんか？ コメントかはてブでお願いします。 view from my workspace Originally uploaded by cityflickr こんな環境で仕事してみたい。 400年前の城らしいですよ。ここ。 ニセコで仕事したときは気持ち良かったなぁ。 Before-after1 Originally uploaded by m2j2 机のビフォーアフター。 前は何でこんな位置にディスプレイがあったんだ？ Home office 2.0 Originally uploaded by slrw82 シンプルでいいですね。屋根裏っぽいのが憧れる。 Th
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://d.hatena.ne.jp/t_yano/20080502/1209753329