エディタで書いてる間は気付かなかったけど、下のエントリ長すぎ。
Life is beautifulさんの
を読んでの感想。
あと、併せて読んだ話は下の二つ。どこかで話が重なる部分があるかも。
産業としてのSIerについて語りたいのか、プログラミングスタイルについて語りたいのか。それはさておくとしても、少なくとも誰のために何を作る話をしているのかははっきりしないと意味がないんじゃないかと思います。
もちろん、一般論としてのプログラミングスタイルとしてどちらがより優れたものが作れるのかなんていうのは議論するまでもないです。
ただ、その上でスケールしやすいパッケージ系のソフトウェアビジネスについての話なのか、それとも儲けの上限が決まっていて一人一殺形式だからスケールしにくいSIビジネスについての話なのか、というのははっきりしないと抽象論で終わってしまって、「上流下流の分離いくない。以上、おわり」みたいな話になってしまうわけです。(中島さんのエントリがそうだったとは言いません。ただ、このエントリを受けてこのように短絡的に理解する人は大勢出たのではないかと思います。)
例えば、パッケージ系のソフトウェアビジネスであれば、Googleを作ったり、WindowsやOfficeを作れば、天井知らずの儲けが期待できるわけです。それならば、優秀なデザインをできる天才ハッカーを集めて最高のサービスで最大の利益を目指すことも一つの有効な戦略だと思います。
しかし、SI業ではそうはいきません。ある一社の要望を受けて、天才プログラマがGoogleばりのスーパーな製品を作ったとしましょう。それでも、このすばらしいプログラムはビジネスとしてはスケールを生みません。品質や製品としてのデザインの優位性、メンテナンスまでを考えた場合のコストパフォーマンス、すべてがすばらしいかもしれません。それでも、その一つの仕事が何百億の時価総額を生むことは絶対にないのです。なぜなら、それを使うお客さんにとって、それは何百億を生み出すものではないですから。
プログラミングスタイルとしてあるべき姿と、産業としてビジネスとして妥当な姿を混ぜて議論してはいけないです。(妥当は語弊があるかも。必要悪というか、仕方ないというか、少なくとも現在のところは残念ながらベターな選択肢を見出しているところが少ないとでもいうべきか。)
実際、優秀なプログラマと一山いくらのプログラマの生産性の違いは20倍なり100倍なりあるでしょう。開発速度だけでなく、品質、保守でのコストを考慮するともっとあるかもしれません。
それでも、そんな優秀なプログラマの人数がSI業の需要に対して足りているとは思えません。そうなると、ビジネス上の判断として、一つの対応として、上流下流の分離なり、人月30万の人海戦術なりで物事を進める必要があるわけです。たとえ悪手に見えようと。
批判すべきは、それが結果として期待されたレベルで成立していないことです。それはたとえばJoelの言葉を借りれば、マニュアルを整備してSI業をスケールさせようとしたのに、スケールしなかったというような点を批判すべきなのです。
マニュアルが悪い、段取りが悪い。だから、一山いくらのプログラマでもどうにかお客さんが望む成果を出せるだけの「より良い段取り」を作ろうじゃないか。そんな提案が必要なのだと思いますし、実際にSI業を真摯にとらえている人の中ではたとえばGoyaのような動きが出てきたりしているわけです。(Goyaはまさによりよい段取りという方向性だと思います)
一方で、SI業をスケールしやすいパッケージビジネスにしようという動きの急先鋒としてSalesforce.comがあったりします。GoyaやSalesforce.comが成功するかはわかりません。ただ、正しい現状認識に基づいて少しでも前進しようという動きに見えます。
後記。そんな私の最近はCODE COMPLETEとオブジェクト指向入門(OOSC)と格闘中。趣味でモノヅクリをしている人としては、本当は同意したい部分も多々あるのだけど、仕事としてサービスを提供して対価をもらっている身としては安易に同意もできずエントリしました。
※Goyaについて
常々、疑問に思ってたことがある。本屋での本の並びってどうやって決まっているんだろう?
出版社別は、まぁ、わかる。
よくわからないのが、技術書。これは出版社別になっているのはO'Reillyシリーズくらいで、他はカテゴリー別ってケースが多い。
あの、カテゴリーやどのカテゴリーの棚に置くのかっていうことは誰がどうやって決めているんだろう?
本屋の人?それとも出版元や著者のリクエスト?
納品書に「キーワード」とかあって、"Java"とか"Ajax"とかMetaタグでも振っているんだろうか。
教えて、中の人!
とか言ってもいいんだけど、ここのPVと内容じゃ中の人に当たる可能性が低そうなんで、今度書店で質問してみよう。
Rubyでメソッドオーバーロードについて検索してたら、まつもとさんのこんなログを見つけた。
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/1401
まず、
引数の数についてはoptional引数とrest引数で対応して ください. def foo(a, b=23, *c) end 呼び出しは以下のようになります. foo() # error!! 引数の数が足りない foo(1) # a=1, b=23, c=[] foo(2,3) # a=2, b=3, c=[] foo(2,3,4) # a=2, b=3, c=[4] foo(2,3,4,5) # a=2, b=3, c=[4,5]
そして、
メソッドの型については * Kernel#typeを使って分類する case obj.type when "Integer" ... when "Float" ... else ... end * defined?を使ってメソッドが定義されているかどうか調べる if defined? obj.foobar ... end * Object#kind_of?を使ってサブクラスかどうか調べる if obj.king_of? IO ... end
んー、なるほど。追記したいことがあるけど、時間がないのであとで書く!
昨日の記事を書きながらPathnameをいじっていて、Pathname.newだらけなのが気に入らず、下のような拡張を考えてみた。
class Pathname def path=(new_path) initialize(new_path) end end
いちいち
p = Pathname.new('/tmp/hoge')
とかしなくても
p.path = 'tmp/hoge'
とかすればよくなるから、ちょっと見た目にいいと思ったんだけど。
実はもっとスマートな解法があるのかな。ご存じの方はぜひ教えてくださいませ。
川o・-・)<2nd lifeさんで、Pathnameの話題が出てましたね。
ぼくもdaigoさんのRedHandedでの紹介を見てからすっかりPathnameの虜です。一度使うと離れられないです。
Pathnameファンとしては、このあたりもおすすめ。
使い方はこんなかんじ。
Pathname.new('/tmp/foo').exist? # => false Pathname.new('/tmp/foo/bar/hoge').mkpath # => 上位のディレクトリも自動的に生成 Pathname.new('/tmp/foo/bar/hoge').exist? # => true Pathname.new('/tmp/foo').exist? # => true
Pathname.new('/tmp/foo').find do |f| p f.basename.to_s if f.directory? end # => "foo" # => "bar" # => "hoge"
Pathname.new('/tmp/foo/bar/hoge').mkpath p = Pathname.new('/tmp/foo') p.exist? # => true p.rmtree # => 配下のディレクトリも再帰的に削除 p.exist? # => false
Find.findがしっくり来なかったんで、Pathname知った時はうれしかったなぁ。あと、コードも簡潔でめりはりあって好きです。
# そういえば、ちょっと前にWindows環境でPathname.cleanpathを使ってはまったような。。
# なんかぐちゃぐちゃやって解決したような覚えがあるんだけど、どうやって解決したんだっけか。
kind_of?を見て、Rubyでオーバーロードならこの方がそれっぽく見えるかと思いました。
class Integer def exclaim v = 1 self.downto(1) { |n| v *= n } v end end class String def exclaim self+"!" end end i = 10 s = "10" class Sample def Sample::exclaim(o) o.exclaim end end [i, s].each { |o| p Sample::exclaim(o) } # => 3628800 # => "10!"
king_of?関係ないし。StringとかIntegerに直接定義すなってかんじですが。なにより釈迦に説法ですね。失礼しました。
「へー、こんなふうに勉強されるんだなー」ととても興味深く読んでいます。今後も楽しみにしています。