DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ
Railsは、最初に素早く動くもの(scaffoldなど)を作って、そこからフィードバックをもらい、少しずつ動く状態を保ちながら、改良していくスタイルです。 スモールスタートを切るには最も向いているスタイルです。しかし、最初はそれで良かったものの、プロジェクトへの要求が増えるにしたがって、コードは複雑になっていき、だんだんメンテするのが大変になってきます。 これはRailsの問題ではなく、システムのアーキテクチャの問題です。 システムでやらなければならないことがたくさん増えたときでも、急にコードが複雑になることなく、きちんとメンテナンスし続ける方法があるなら、誰でも学んでみたいと思うでしょう。 その方法を教えてくれるのが、エンタープライズRailsなのです。 エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術 作者: Dan Chak,高井直人,笹井崇司出版社/
Rails 2.2すげぇ - ひがやすを技術ブログ
Rails 2.2RCがリリースされました。 国際化(i18n)、スレッドセーフ化など、 うれしい機能が多数追加されているようです。 リリースノートが公開されていたので簡単に日本語訳してみました。 誤り等あればご指摘ください。 変わりすぎだろうと思うRails 2.2ですが、自分の中でもっとも大きいと思うのは、スレッドセーフのサポート。Ruby自体がスレッドセーフじゃない(スレッドセーフじゃないCのライブラリを使っているので)と思っていたけど、勘違いだったのかな。それともRailsが独自にがんばっているのか。 スレッドセーフ化の細かい内容はこちらをどうぞ。 http://blog.headius.com/2008/08/qa-what-thread-safe-rails-means.html ひとつのインスタンスで、複数のリクエストを同時に処理できるとのことです。でも、グリーンスレッドだと
Railsバブルは終わった - ひがやすを技術ブログ
Railsバブルは終わったと思う。良い意味で。 Railsは世の中の技術者に大きな影響を与えたフレームワーク、そして偉大なフレームワークですが、バブルを起こそうと変に煽っている人たちが前から気になっていました。 最近、Railsについて何度も取り上げているのは、手放しに近い状況で「Rails良い」と煽りまくっている人が目に付くから。こういうのは、バブルにつながるし、バブルは最終的に、はじけてしまうものです。Railsバブルは、もうとめられない気もしますが、Rubyはバブルになってほしくない。 だってバブルがはじけて生き残るのはほんの一握りですよ。自分たちが原因で、失敗するならあきらめもつきますが、バブルを起こして運がよければもうけられるみたいに思っている人に散々利用されて失敗するのは、納得がいかないですね。過剰に評価されれば、それだけ失敗する案件も増えてくる。 煽られてそのプロダクトを採用
コミッタには気楽になっていいんだよ - ひがやすを技術ブログ
コミッタは自分で名乗り出てなるものではない と思う。もちろん、自分自身で新しい何かを作った時は、自動的にそのプロダクトのコミッタに就任しても良い。しかし、他人のプロダクトに対して、 「コミッタにならせてください」 っていきなり名乗り出るのは、OSSの世界を知らないにも程がある。 「コミッタにならせてください」っていきなり名乗り出てもいいと思うよ。 基本的にOSSのプロジェクトの方針は、そのプロジェクトのリーダーが決めるもの。よういちろうがリーダーをやっているプロジェクトなら「コミッタにならせてくださいといきなり名乗り出るのはありえない」という方針でもいいでしょう。でも、その考えをOSS一般の考えのように言うのは違和感あるよ。 OSSを知らない人が、よういちろうのblogをみたら、間違いなく「コミッタにならせてくださいといきなり名乗り出るのは間違ったことだ」と思うでしょう。 OSSはそんな窮
優秀なプログラマの給料が低いわけ - ひがやすを blog
昨日の開発生産性が低い方が収入が多いって変だよねのエントリでは、企業レベルの話だと、生産性が低いほうが売上が上がるという話をしたんですが、実は同じようなことが、個人レベルでも言えます。 生産性の高い超優秀なプログラマより、社交性の高いそこそこ優秀なプログラマのほうが、評価が高く給料も多くもらえるようになるのです。さすがに、個人レベルだと生産性の低い人が評価が高いということはあまりないけどね。一時的には残業が多くて給料が増えるときもあるかもしれないけど、それはあくまでも一時的なこと。 評価が高いということは、上司にそれだけ認めてもらっているということですが、それではなぜ、優秀なプログラマは、上司に高く評価されないのでしょうか。 「上司に技術をきちんと評価する力がないから」それも多少はあります。でも、主な原因ではありません。会社によって違うと思いますが、評価における技術力の部分は2,3割りに過
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
Strutsをなめんな - ひがやすを blog
リリースノートはこちら Bug [SASTRUTS-18] - ArrayWrapperでListを実装するようにしました [SASTRUTS-20] - ActionからActionへ遷移できない問題を修正しました Improvement [SASTRUTS-19] - ActionのプロパティがMapの場合も扱えるようにしました ダウンロードはこちら http://sastruts.seasar.org/download.html このバージョンから、チュートリアルに、ResourceSynchronizerプラグインを使ったリッチなエラーページをつけました。ResourceSynchronizerを超ざっくり説明すると、ブラウザからEclipseを操作するプラグインです。 チュートリアルのリッチなエラーページをクリックすると、Ext.jsで作ったリッチなエラーページが表示されます。ス
そろろろRailsについて本音を書いてみるか - ひがやすを blog
最近の大田さん@mixiのところで、Rubyについて考察する機会があったのと、よういちろうの考えと同じことを思っていたので、たまには本音で書いてみる。 Railsで、最も良いところは、テストの雛形も自動的に作ってくれて、テストの敷居を下げてくれてるところだと思う。なのに、それについて触れる人があまりにも少ないような気がする。一応、私は、1年半以上、はてなのキーワード検索で毎日Railsについては調べているので、はてなでRailsについて書いている人の記事はたいてい見ています。 理由は、いくつか考えられますが、私の読みだと、テストが当たり前の人にとっては、当たり前すぎてわざわざ書く意味がないし、そうではない多くの人にとっては、ほとんどテストは書いていないんじゃないかな。 実は、テストを書くのは結構工数かかるんですよ。スクリプト言語は、コンパイラがミスを教えてくれることはないので、Javaと比
2007-11-20 - ひがやすを blog - [etc]サイボウズ・ラボ見学
ヨシオリがサイボウズ・ラボに面接に行くからついてきて欲しいというので、今日はサイボウズ・ラボにいってきます。半分は冗談だけど。 TAKESAKOさん(http://labs.cybozu.co.jp/blog/takesako/)、 西尾さん(http://labs.cybozu.co.jp/blog/nishio/)、 amachang(http://d.hatena.ne.jp/amachang/)たちと、その後、飲みに行こうという話しになっているので、ほんと楽しみです。みんな言語が見事にばらばらだ(笑)。 追記: TAKESAKOさんに写真を公開していただきました。 http://www.flickr.com/photos/takesako/sets/72157603249097619/
![2007-11-20 - ひがやすを blog - [etc]サイボウズ・ラボ見学](https://cdn-ak-scissors.b.st-hatena.com/image/square/3b82fa3919b0fe42c1f5af79e2337c544f1297fd/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126970898857%2F17680117126970925514%2F1550549857)
2007-10-12 - ひがやすを blog - Seasarはなぜ日本から巣立たない?
正直な話、Seasarはほとんど触ったことがない。 ただ、せっかくいいものを作っているのに、 日本からなかなか巣立つことがないのは もったいないと思う。 これには、明確な理由があります。日本人の特にソフトウェアにおける「舶来信仰」をぶちこわすためです。 自分たちであまり考えることなく、海外ではやっていたらそれをそのまま受け入れる傾向が、日本人には強いように思えます。それっていいことだとはあまり思えません。 例えば、Rubyも海外からのRails効果でブレイクしたわけです。ちょっと悔しくないですか。せっかく日本で作られたすばらしいソフトウェアなのに、海外で認められるまでは、日本人は、一部の人を除いては評価できなかったわけです。 後、ソフトウェアをやるならアメリカ行けとかシリコンバレーに行けとか。場所なんか関係ないんじゃないの、もちろん、海外にも優秀な人は多いと思いますが、日本にも優秀な人はい
ひがやすを blog - Javaを古くしたやつとRubyを煽っているやつ
その正体はわかったよ。正体わかった瞬間からだが震えたよ。まじで。 まずは、羽生さんのこのエントリを見て欲しい。 http://d.hatena.ne.jp/habuakihiro/20070922#1190464426 その後によしおりのこの有名なエントリも復習して欲しい。 http://d.hatena.ne.jp/jYoshiori/20070826/1188150596 もうさぁ、変わってないよねぇ。昔からのこの構図。歴史は繰り返すっていうの。 あからさまにいうとさぁ。賢いスーツな奴らと、頭の固くてあわれで保守的なおやじの歴史だよ。 最初は、EJBだよ。EJB。これからは、ビジネスコンポーネントが流通して、もうプログラミングはいらなくなる。コンポーネントの組み合わせを考えるだけでOKみたいな。最初にね、キャッチーな言葉とともに、あらたなテクノロジーを広めようとするのは、賢いスーツな奴
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
