Railsバブルは終わった - ひがやすを技術ブログ
Railsバブルは終わったと思う。良い意味で。 Railsは世の中の技術者に大きな影響を与えたフレームワーク、そして偉大なフレームワークですが、バブルを起こそうと変に煽っている人たちが前から気になっていました。 最近、Railsについて何度も取り上げているのは、手放しに近い状況で「Rails良い」と煽りまくっている人が目に付くから。こういうのは、バブルにつながるし、バブルは最終的に、はじけてしまうものです。Railsバブルは、もうとめられない気もしますが、Rubyはバブルになってほしくない。 だってバブルがはじけて生き残るのはほんの一握りですよ。自分たちが原因で、失敗するならあきらめもつきますが、バブルを起こして運がよければもうけられるみたいに思っている人に散々利用されて失敗するのは、納得がいかないですね。過剰に評価されれば、それだけ失敗する案件も増えてくる。 煽られてそのプロダクトを採用
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
SIをやるのは正社員の終身雇用を守るため? - ひがやすを技術ブログ
ある大手SIerの偉い人がこういっていたという。 SIをやるのは終身雇用を守るためこれだけでは、何を言っているのか良くわからなからないけど、真意は次のことのようだ。 アメリカではSIerは存在せず、ユーザ企業が自らシステム部門を持ち、 自社内でシステム開発を行う。 しかし、それができるのは、アメリカが終身雇用でないからだ。 アメリカでは巨大なシステム開発が完了したときに、 プログラマを解雇することができる。 日本ではそれができないため、ユーザ企業の雇用調整の機能をSIerが担っている。 ユーザ企業の雇用調整の機能をSIerが担っているのはいいんだけど、その雇用調整の仕方が、下請け構造なんだと思う。 この国の労働構造においては、正社員というのは、派遣社員無しには維持できないんです。企業が正社員に福利厚生をして、給料払って、失業から守ってあげれるのは、派遣とか期間工とか、フリーターがいるからな
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
僕がRubyをやめたわけ - ひがやすを blog
私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこすことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふくれあがってしまいました。その上、Rails では動的なコードの変更が可能なため、開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバレッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も安定していません。それなのに開発コミュニティはそのことに見向きもしません。 liftを開発した人へのインタビューなんだけど、ちょっとひ
メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ
その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
