DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ
Railsは、最初に素早く動くもの(scaffoldなど)を作って、そこからフィードバックをもらい、少しずつ動く状態を保ちながら、改良していくスタイルです。 スモールスタートを切るには最も向いているスタイルです。しかし、最初はそれで良かったものの、プロジェクトへの要求が増えるにしたがって、コードは複雑になっていき、だんだんメンテするのが大変になってきます。 これはRailsの問題ではなく、システムのアーキテクチャの問題です。 システムでやらなければならないことがたくさん増えたときでも、急にコードが複雑になることなく、きちんとメンテナンスし続ける方法があるなら、誰でも学んでみたいと思うでしょう。 その方法を教えてくれるのが、エンタープライズRailsなのです。 エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術 作者: Dan Chak,高井直人,笹井崇司出版社/
SIerの解体と再生 - ひがやすを技術ブログ
ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの
そろそろSeasar2のガラパゴス戦略について語っておくか - ひがやすを技術ブログ
Slim3のファーストリリース(今月中)の前に、Seasar2の開発で、どのような戦略をとったのか話しておきます。 2005/11/8、Seasar2.3のバージョンをリリースしました。このバージョンから搭載されたのが、コンポーネントの自動登録機能です。設定ファイル無しで開発できるようにする機能ですね。Springだと2.5から搭載されたcomponent-scan。 Spring2.5のリリースは、2007/11/19なので、実に2年以上差があります。オープンソースの世界では、みんなが手の内を見せ合っているので、誰かが新しい機能を実装した場合、それが良いものであれば、ライバルも直ぐにそれを取り入れ、それほど機能差がつくことはありません。 なぜ、従来のXML地獄を解消する「コンポーネントの自動登録機能」を実装するまでの期間にこれほど差が出たのか、それはガラパゴス戦略のせいなのです。 Sea
プログラミングをやるのは大手では難しい？ - ひがやすを技術ブログ
私は，現在就職活動をしているものです．仕事は，プログラミングなど（最終的には一連の作業をやりたい）をやりたいと思っているのですがプログラミングをやるには大手では難しいのでしょうか？ ここ最近，大手を中心に何ヶ所か就職のセミナーに行きました．ある会社では開発を行っているらしいのですよくよく質問するとプログラミングは行わないらしいです． 難しいでしょうね。今の大手SIerは、単価の高い上流にほとんどシフトしています。それだけなら、別に問題はないのですが、新人にプログラミングなどを経験させずに、いきなり設計をさせることが多い。例えばこんな感じ。 どうも会社では、僕に上流工程を任せようとしているようです。しかしながら僕は、上流工程にはまったく興味がありません。上流工程のほうが付加価値が高いし儲かるということは一応知っているつもりですが、設計をしたり人の調整をしたり、なんていうことは好きでもないし、
自分の書きたいコードを書け - 脱職業プログラマのすすめ - ひがやすを技術ブログ
良く仕事以外のプログラムをしたことない人っているじゃないですか。ここでいう職業プログラマとは、仕事以外では、プログラムをしない人のことを指しています。 仕事以外でもプログラミングをしている・勉強している人、は、職業Onlyプログラマではなく、職業でもプログラムをしているけど、それ以外にも努力をしている人です。 それは、もちろん何の問題もないんだけど、それだけでは実力はつきません。たぶん、コードを書きながら自分が成長している気がしてないでしょう。あなたの直感は正しい。 何らかのフレームワークを使えば、それなりにできることが増える、それももちろん成長です。ただし、知識のね。プログラミングの力はそれほど変わっていないはず。 自分の経験で言えば、多くの人に読んでもらえないコードは、いくら書いても、実力につながりにくい。人に見せようとするコードは、書いているだけで、いろんなことを考えるし、それが、力
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
