2005 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
2014 1 2 3 4 5 6 7 8 9 10 11 12
2015 1 2 3 4 5 6 7 8 9 10 11 12
2016 1 2 3 4 5 6 7 8 9 10 11 12
2017 1 2 3 4 5 6 7 8 9 10

ホーム

2007年08月30日

なんなの、Elispのdate-to-timeって。解析できるパターンが
少ないし、21と22とで違ってるし。

一番確実っぽいパターンは"2007-08-30 06:43:33"みたく、
曜日もなくて、秒数まで含む文字列。"06:43"みたく秒数が
ないとエラーになるて、ワケワカラン。Infoには何も
書かれてないしな。つか、22のInfoにはdate-to-timeの
説明すらない。

;; date-and-time: 2007-08-30 Thu 17:22
(defun date-and-time-to-seconds (date-and-time)
  (let* ((strs (split-string date-and-time))
         (normalized (concat (first strs) " " (nth 2 strs) ":00")))
    (float-time (date-to-time normalized))))

(defun difftime (old-date-and-time new-date-and-time)
  (let ((oldsec (date-and-time-to-seconds old-date-and-time))
        (newsec (date-and-time-to-seconds new-date-and-time)))
    (truncate (- newsec oldsec))))

(defun difftime-string (old-date-and-time new-date-and-time)
  (let ((diff (difftime old-date-and-time new-date-and-time)))
    (let ((s (% diff 60))
          (m (% (/ diff 60) 60))
          (h (/ (/ diff 60) 60)))
      (format "%02d:%02d:%02d" h m s))))

本家Permlink


2007年08月29日

http://c2.com/cgi/wiki?OnceAndOnlyOnce

深い。深すぎる。

やっぱりRalphJohnsonの:

  OnceAndOnlyOnce is a profound concept, but difficult to apply. I've
  spent my entire professional life (25 years) learning how to apply
  it to programs.

ということなんだろうなぁ。

--

どうでもよくなったから消す。

本家Permlink


2007年08月28日

『大規模ソフトウェア開発』という問題については、
自分は常に『人の問題』だという態度です。

単純に『コード行数が多い』という事象については、
どちらかというと、言語なりフレームワークなりの個々の
テクノロジーの『生産性』という問題で扱われるべき
でしょう。

『利用者が多い』といった事象については、最近よく
話題にのぼる『スケーラビリティ』という問題で扱われる
べきでしょう。これもまた個々のテクノロジーを議論
することになります。

生産性、スケーラビリティとも、『人』という変数が
存在しなければ、テクノロジーで解決できる部分が大きく
なります。けれども、大規模を人の問題として捉えたとき、
テクノロジーで解決できる部分は小さくなります。
自分はそういう考えですから、大規模という人の問題を
テクノロジーで解決しようとすることに反対しているわけ
です。

ただし、プロジェクトの参加人数が多くても、コード量が
少なければ、問題になることは少ないでしょう。いや、
問題は生まれるでしょうけど、それを解決するのは、
いくらなんでも開発者の仕事ではないでしょう。開発
以前の話です。

--

何度か書いた覚えがありますけど、静的型の目的は主に
2つ。1つは最適化、もう1つは正当性です。そして今
重要視されているのは正当性のほうですよね。じゃあ、
その正当性をより活かすためにはどうすればいいか。
型を増やすしかない。それが静的型言語の宿命なんです。

静的型を『縛り』と見なしてしまうと、型が増えません。
わざわざ窮屈な思いをしてまで型を増やす人はいないで
しょう。そうすると正当性が損なわれます。

だから、型を『表現の手段』、書き手の意図をはっきり
させるためのものと見なさないといけません。プログラムの
表現を豊かにすると思えば、型が増えます。

型を『表現の手段』と見なすのは、Rubyのような言語でも
同じです。単純なArrayやHashよりも型を起こすほうが
意図が伝わりやすい。ただ、型を増やす方向への圧力と
いうのは、静的型言語よりは弱いです。

--

静的型言語の生産性について。あれは半分『煽り』の
ようなもんだったんですけど (笑)。

でも、ほんとに静的型言語の生産性を上げるんなら、
言語仕様だけじゃなくって、開発環境といったものも
仕様に含めるべきでしょう。素のコンパイラだけじゃ
生産性が上がらないんですから。『言語仕様は考えた
から開発環境はよろしく〜』じゃ、もうダメでしょう。

そういう意味では、Javaは正しい方向に向いてると思い
ますよ。NetBeansがあるし。

自分が静的型言語、というかコンパイラ言語が嫌いに
なったのは、コンパイラが信用できないから。何かの
拍子にコンパイルされないファイルがあって。これは
悪夢にも程がある。

まぁ、世の趨勢はインタプリタに傾いてるみたいだし、
自分としてはうれしいんですけど。

--

ああ、Rubyでいえばデバッガのサポートが弱いのが
気がかり。

本家Permlink


2007年08月27日

ハァ? 制約を作れないから大規模はムリ?

なんだそれ? そんなこといったらPHPなんてどうすんだよ?
PHPで大規模やってるってよく聞くだろ? Yahooとか。
こないだ、Erlangの大規模システムの話、ここか獲物で
取り上げたろ?

ほんっと、大規模に幻想抱くヤツが多いな。

--

いいすぎた。ごめん。

でも、静的型って「縛り」なのか? 静的型を縛りと思ってる
ようじゃ、いつまでたっても動的言語の生産性には追い
つけないんじゃないの?

本家Permlink


2007年08月26日

http://www.joc.or.jp/event/essay/2005/index.html

『思いやり』は``respect for others''でいいらしい。

他にも、``caring''という表現を使うこともあるようだ。

『相手の立場になって考える、してあげる』という、
人にとって欠かせないことを、『思いやり』の一言で
表現できることは素晴らしいことだと思う。

--

進捗の報告が必要なら、何が残ってて、それを達成する
ためには何日くらいかかりますって答えればいい。最悪で
何日延びますっていうのがあればベター。

パーセンテージはどこにも必要ない。

そもそも機能っていうのは、均等の複雑さを持つものじゃ
ない。Aという機能とBという機能とじゃ複雑さが違う。
つまり、その機能を実現するのにかかる日数が違うって
こと。

だから、機能を分解して複雑さをならす。Aという機能は
A1とA2というサブ機能から成るといった具合に。あるいは、
その実現を手順化する。Aという機能を実現するには、
これをやってあれをやってといった具合に。そうやって
機能を日数に変換するわけだ。

でも、この変換には必ず誤差がつきまとう。機能が複雑
であればあるほど誤差が大きくなる。パーセンテージが
出てくるとしたらここだろう。プロジェクトの平均速度
(1つのストーリーにかかった時間といったもの) は、
こうで、もっとも遅いのは何%くらい遅かったといった
数字なら、誤差を推測するのに役立つ。

--

あるいは、上とおんなじ理屈で、『完成度』についても
パーセンテージを用いるのはウソになる。

Aという機能のビジネス的価値と、Bという機能のビジネス
的価値は同じではない。機能Aより機能Bのほうがビジネス
的価値が極めて高ければ、機能Bの完成度が決定的に重要に
なる。

だから、XPでは、ビジネス的価値の高いものから手を
つけろといわれる。

本家Permlink


2007年08月25日1

http://www.atmarkit.co.jp/im/cpm/serial/standard05/standard05html.html

  当然のことながら、「開発標準とはかくあるべし」というような決まりはど
  こにもありません。ですので、その組織にとって事情がさまざまに異なるよ
  うに、どのような形・内容が良いのかはまちまちであり、さらにプロジェク
  トごとにも変わってくるのが当然と思います。それは、会社ごとに目指すも
  のや業務の進め方や文化が異なるということ、そのものでもあります。

それって矛盾してんじゃん? 『標準』ってのは『かく
あるべし』ってもんでしょ? 組織ごとに違うとかいい
だしたら、そんなもん標準でもなんでもねぇじゃん?

これは言葉尻をつかまえてるだけじゃなくってね。そう
いう『標準願望』っていうのは『銀の弾丸願望』と大して
変わんないでしょ。だから、そういう『銀の弾丸』が
あたかも存在するような、みんなを誤った方向に導く
ような言論はどうなの?って話だよな。

--

http://itpro.nikkeibp.co.jp/prembk/NBY/techsquare/20041105/152190/?ST=ittrend

羽生田さんもボケたか?

  プロセスをしっかり定義することの最大のメリットは,トレーサビリティの
  確保です。トレーサビリティを確保すると,説明責任(アカウンタビリティ)
  を果たせるようになります*2。手順をさかのぼることで,現在の製品の状
  態をきちんと説明できるのです。例えば顧客に対しては「このような要求か
  らこうしたユースケースが導き出され,このコンポーネントが必要となりま
  す。さらにこのインタフェースを実装するうえで,このコンポーネントが必
  要です」と説明できます。

ここまではいい。でもその直後に続く:

  プロジェクト・リーダーには,コンポーネントの完成度について「40%のメ
  ソッドは7本のユースケースから使われており,検証ができています。残り
  のユースケース3本で必要な特別なインタフェースを含む60%のメソッドは
  未実装です」と報告できます。

こういうふうに報告できることに一体何のメリットが
あるの? そのパーセンテージの粒度はみんな同じなの?
つまり、残り60%はこれまで実現した40%と同じ割合の
複雑さで、同じ割合の期間で実現できるの? だとしたら、
それって『前払い』だし、『占い』やっちゃったって
ことでしょ? もう何を実現すればいいかぜ〜んぶわかってて、
あとはガイチュー任せで自分らは何もやんなくっていい
んですよってか?

そういうミョーな数字でいつまでもゴマカシは利かない
でしょ? バブルなんてもうどこにもない。

--

豆蔵も、もっとがんばんないとダメなんじゃないの?

http://quote.yahoo.co.jp/q?s=3756.t&d=c&k=c3&a=v&p=m65,m130,s&t=2y&l=off&z=m&q=c&h=on

プロセスっていうのはビジネスなわけでしょ? だったら
ビジネスにその結果が反映できてなきゃおかしいじゃん。

株価が上がってないっていうのは、市場は豆蔵の将来性を
高くは買ってないってことだろ? 株式市場はここ数年上げ
基調だったんだぜ?

株式公開なんかしなきゃよかったものを。

本家Permlink


2007年08月25日

諸事情により復活。というか、もう一度書き起こす (笑)。

--

このページは「Googleバカ百選」の1つなわけですが
(真ん中よりちょっと下くらいだから「君臨」というのは
大げさ (笑))。

でも、何でも「バカ」をつけないと上位に来ないのは
どういうわけか。

Ruby

Ruby バカ

agile

agile バカ

XP

XP バカ

でも、さすがにこれは自分でもあきれた:

プログラミング

プログラミング バカ

本家Permlink


2007年08月23日1

趣味で困るのが、どうしても時間が途切れがちなこと。
時間が経っちゃうと、どこまでやったか、何をやるべきかを
忘れちゃう。

だから、『どこまでやったか』を記録するためにテストを
残す。『何をやるべきか』をTODOリストに残す。

とはいえ、趣味で一番困るのは、やる気の維持なんだなぁ。
まぁ、趣味なんだから飽きたら止めちゃえばいいっていう
意見もある。でも、やっぱり未完成よりは完成させるほうが
楽しい。

完成させることを優先させるんなら、小さいもの、
あるいは、すぐに自分で使うものがいい。大きいものを
作りたいときでも、できるだけ小さくて完成した状態から
徐々にふくらませるように作っていったほうがいい。

って、こうやって書くと、いつもここで書いてることと
大して変わんないんだけど (笑)。

--

でも、自分は、プログラミングに関しては、それほど
純粋ってわけじゃない。プログラミングすること自体も
楽しいけど、それだけじゃなくって、やっぱり他の人から
誉められたいっていう欲がある。

でも、誉められるためには、人前に出せる程度には形に
なってないといけないわけで。そうなると、やっぱり
完成させることを優先させないといけないんだなぁ。

--

そういう意味で、自分にとって囲碁は純粋に趣味といえる。
強くなりたいといっても、それは大会に出て勝つとか、
そういう強さじゃなくって、強くなることで囲碁をより
深く楽しみたいっていう。

本家Permlink


2007年08月23日

あるいは、『大並列化時代にOOPは耐えられるのか?』と
いう疑問が突きつけられているともいえる。

--

やはり、「私はXPを実践しています」というのであれば、
白本は読むべきだ。XPには、1.0のころから価値は5つある:

* communication
* simplicity
* feedback
* courage
* respect

このうち、最後のrespectは、XP 1.0のころは『ゼロ番目の
価値』といわれていた。しかし、XP 2.0になって5番目の
価値になった。

respectについては、度々ここでもその重要性について
触れてきた。個人的には『ゼロ番目の価値』から『5番目の
価値』に『格下げ』されたのは残念に思う。

というか、そこまでバカが多いのかと思うと悲しくなる。
なぜrespectが『ゼロ番目の価値』と呼ばれたか。それが
開発に限らず、人間として当たり前の道徳だからだ。
それをわざわざ明文化しなければならなかったことが、
XPを上辺だけなぞる連中の多いことを暗示している。

--

必ずしも実装の検討に時間をかけてはいけないという
ものでもない。ここでいう『実装の検討』とは、他の
方法論でいうところの『設計フェーズ』というものを
指す。

ただし、前にも書いたように、XPでは、設計は計画ゲームの
段階から始まっている。なぜならば、ある程度設計の
目鼻が立っていなければ、見積もりを出すことはできない
からだ。いくら『大数の法則』があるからといって、当て
ずっぽうでいいものではない。

XPが嫌うのは、開発に不必要なドキュメントを作ることだ。
そして、他の方法論でいうところの『設計フェーズ』の
主な目的は、この開発に不必要なドキュメントを作ることに
ある。

XPでも予め実装を検討する必要はあるし、それに時間が
かかることもある。しかし、それをドキュメントの形に
残す必要はないということだ。

(資料を残したほうがいいと判断すれば残せばいい。
ただし、それはフォーマルなものでなくても構わない。
たとえばWikiに残すだけでも十分だ。)

『実装の検討には10〜20分しかからない』などというのは
『たまたま』であって、それが1時間だろうが、数日だろうが
構わない。『実装の検討には10〜20分』などというルールは
どこにもない。

納得の行くまで検討、議論することは非常に大切だ。

先に『計画ゲームの段階から設計は始まっている』と
書いたが、実際にコーディングしている最中にも実装の
検討は行われる。『今の設計でいいのか、もっといい
設計はないのか』と常に考える。そしてシステムにフィード
バックをかける。

それぞれの活動を無関係なものと捉えるのではなく、
フィードとフィードバックによって強く結ばれたものと
認識することが大切だ。

--

もっとも身近なフィードバックは『ありがとう』の一言だ。

本家Permlink


2007年08月22日

絶望した! 「絶望日記」などという、いかにもありがちな
名前をつけるセンスに絶望した!

--

XPにおける「価値」とは何なのか。価値とは判断基準で
あり、それを高めるために行動するもの。言い換えるなら、
XPのすべての実践、原則は価値から生まれたものであり、
価値を高めるために存在する。

--

理解できるとかできないとか、そういう低いレベルの話では
なく、抽象化の手段としてOOPが適当かどうかという議論が
重要。最近FPが盛り上がってるが、連中はそこをいってる
わけだ。端的にいえば、OOPはFPの焼き直しに過ぎないと
いうこと。

もちろん、自分はOOPの有効性を主張する。OOPのほうが
少なくとも自分には考えやすいから。また、まつもとさんは、
今のところオブジェクト以外に状態をうまく飼い馴らす
手段はないのではないかと意見を述べている (要出典)。

OOP、FP、いずれが今後の主流になるかはわからない。
でも、この2つ以外の、たとえば古典的な手続き指向が
復活するなどということは絶対にない。

本家Permlink


2007年08月21日

たとえば今週の『東洋経済』を見ても、記事はバラエティに
富んでいる。『グッドウィルにも違法派遣の疑惑』と
いうスクープ。経済評論家・田中直毅氏へのスペシャル・
インタビューは『保守、リベラルともに衆参分裂は僥倖で
ある』、およびそれに続く『安倍弱体化で揺れる日米
同盟』という政治色の極めて強い記事。そして特集の
『ファンド全解明』。この特集では本誌記者が名を連ねて
いる。ビクターを買収したケンウッドの会長へのインタビューも
旬だろう。前のほうには、1ページながら、グーグルの副社長に
著作権問題でインタビューを行っている。さらには、
FIFAのブラッター会長の記事もある。

自分は『東洋経済』を経済誌として読んでるわけじゃない。
どちらかというとゴシップ誌的な、オジサン週刊誌的な
ノリで読んでいる。そういうノリで読んでも、上のように
バラエティ豊かな記事のおかげで、現代やポストあたり
よりは全然面白い。そういうオジサン雑誌とは倍くらい
値段が違う(今週号は570円) が、それでも自分は『東洋
経済』を買う。

『東洋経済』は、自分の嫌いな『ナンバー』と同じ意味で、
アザトイ。第2特集は『盟主ニッセイが始めた現場改革の
本気』だが、こういうのはパブ記事だろうし、もちろん、
巻頭のバイオガソリンの記事もそうだろう。ただ、そう
いうのは分かりやすい提灯ではある。それと、そういう
ものも含めた泥臭さが『東洋経済』の魅力の1つだと思う。
『ナンバー』からは汗の匂いは感じられないが、『東洋
経済』からはゼニの匂いが感じられる。

そして、このレベルで週刊ということ。前にも書いたが、
コンピュータ関係の雑誌関係者は、不振を嘆く暇あったら、
ない知恵必死に絞ってみろよといいたい。

『サイゾー』読むんだったら、『東洋経済』、それに
『BUBKA』読んだほうがいい。それが結論。

--

つーか、最近のIT系はWebもつまんない。ZDNetもCNNも
(少なくとも日本のは) ダメ。腐ってる。だったら、
英語わかんなくってもO'Reilly Raderのほうが面白い。

本家Permlink


2007年08月20日

ああ、やっぱ『偽りの輪舞曲』、難易度高めなのか。
システムが目新しいっていうのもあるけど、それを抜きに
しても、ちょっと歯ごたえあるなぁ。挫折しちゃうかも。

攻略ページとか見ないでおこうと思ってたんだけど。
おかしいと思ったら案の定、アンセムは仲間にできるし。

http://www38.atwiki.jp/ituwari/pages/25.html

アイテムはともかく、アンセムの存在は後々、というか
直後のパシリとかの面でも響きそうだし。でも、仲間に
するにはトサカをどうにかしないといけない。むぅ。

本家Permlink


2007年08月19日

Data_Get_Structの結果をチェックする必要はなさそう
なんだな。

--

DuckTypingっていうのは、Cで書かれるRubyの世界でも
効くんですね。それもすっごく効く。

本家Permlink


2007年08月18日

FXで大穴開けた主婦が風俗に落ちてるらしいぞ。
東スポ情報な。

本家Permlink


2007年08月17日1

http://www.01club.org/softdev.html

では改めて。まず最初に、先にも書きましたが、この文章が1994〜1996年に書
かれているという点を強調しておきます。まだXPも知られてなく (白本は2000 
年だったはず)、ネットすらもままならなかった時代に、これだけの内容を示
せたのは素晴らしいことです。これから自分は批判めいたことを書きますが、
それはまったくフェアな態度とはいえません。すでにXPの知識もあり、実際に
agileな開発も体験した上での批判ですから『後出しジャンケン』みたいなも
のです。著者の加賀氏も、おそらく今では違う考えをお持ちではないかと思い
ます。それでもここで議論の対象にするのは、埋もれてしまうには惜しい文章
であることと、これを議論することで、agileというものを再確認できるので
はないかと期待するからです。

結論を先に書きます。まず良いと思ったことから。当時の問題点 (そして現在
でも変わらない問題点) の把握については異論はほとんどありません。要件定
義の難しさ、ドキュメント駆動の煩わしさ、品質向上の難しさといった問題で
す。特筆すべきはテストを重視していることです。意味付けとしてはユニット・
テストに近いものも登場します。さらに、ソフトウェア開発を組織のあり方か
ら論じている点も評価できます。

では、次に良くないと思ったことを。ソフトウェア開発を非常に完全なものと
捉えようとしています。それがゆえに、古典的な開発プロセス、開発組織を批
判しながらも、同じように古典的な結論に着地してしまっています。また、大
規模開発への幻想も感じられます。自分は『大規模開発こそがニッチだ』と何
度も書いてきました。

では、各論に入ります。

『1. 改革の必要性』で注目してほしいのは、『1.3 改革の目標』です。次の
ように書かれています:

  * 顧客満足度の向上
  * 開発リスクの低下
  * 開発効率の向上による、開発費の削減と利益の増加
  * 開発期間の短縮
  * 開発技術者の士気の向上
  * 開発可能なソフトウェアの規模の拡大
  * ソフトウェアの品質の向上と価格の低下による、ソフトウェアの需要の拡大 

これを見るとManifesto for Agile Software Developmentを思い浮かべてしま
います。単純なプロセスの話ではなく、ソフトウェア開発をビジネスとして成
功させようという気概が見られます。

『2. 開発プロセス』では、前半が旧来の開発プロセスへの問題提起であり、
後半が著者が提案する新しい開発プロセスの紹介です。問題提起のほうは自分
も認識に大差ありませんし、やはりここは著者の開発プロセスに注目します。

最初に『2.5.1.要件定義』と『2.5.2.設計』からはじまります。そして、この
2つで、先に自分が指摘した『ソフトウェア開発を完全なものと捉える』こと
がはっきりと示されています。要件定義のところでは:

  このフェーズは顧客との合意で始まり、顧客との合意によって終わる。
  (中略)

  また、この顧客との合意を行なう前に、要件定義書をにたいして、ブラック
  ボックス・テストを行ない要件の記述に誤りがないかをチェックする。この
  フェーズで正確な要件の定義ができなければ、これ以後のフェーズは全て無
  意味である。

とあり、また設計では:

  このフェーズは顧客とコンピュータとの中間段階である。このフェーズで作
  成した文章や図形は、顧客にもコンピュータにも理解できない。すべての作
  業は紙の上で行なわれる。

  このフェーズで要求される厳密さのレベルは、作成された文章や図形によっ
  てプログラマが、プログラムを作成でき、作成されたプログラムがソフトウェ
  アの一部として完全に動作するレベルである。

  このフェーズで作成するものは、ソフトウェア全体で共通に使用するものに
  ついての設計書であり、次のようなものである。

    ソフトウェア構造図  ファイル設計書  データベース設計書 
    ネットワーク構成図  ユーザーインタフェース設計書
    データフロー図      プロセスフロー図
    共通ルーチン設計書  プログラム設計書

  (中略)

  プログラム設計書に記述された入出力データや機能、制約などに誤りがあっ
  てはならない。誤りはできるだけ取り除くように努力しなければならない。
  設計書として要求されるものは、プログラマがプログラミングを行なうため
  に、必要な情報が正確に記述されたものである。(以下略)

とあります。要件にしても、設計にしても、非常に完全なもの、厳格なものを
要求しています。agileでは、要件も、設計も、emergentなもの、徐々にはっ
きりするものだと捉えます。ゆえにagileでは要件定義から実装までの活動を
短期間で繰り返すことで、要件や設計の真の姿に近づこうとします。

著者があげている開発ドキュメントの多さにも驚かされます。自分からしたら、
これは著者が前半で批判している『不必要な作業』にしか思えません。これは
自分が『古典的なプロセス』から脱しきれていないと感じた点の1つです。

次に『2.5.3.共通ルーチン・サンプルプログラムの作成』が続きます。ここで
は再利用について述べられています。

  プログラミングのフェーズに移行する前に、共通ルーチンの作成、サンプル
  プログラムの作成を行なう。(略)

  共通ルーチンはこのフェーズでのみ作成し、プログラミングのフェーズでは
  行なわない。(略)

これも一種の『前払い』です。agileはリファクタリングを重視する『都度払
い』です。上の文章のすぐ後に:

  このフェーズ (共通ルーチン作成フェーズ (tko注)) でプログラミングの際
  に発生する問題は、できるだけ解決しておかなければならない。

とあります。でも、agileでは、そうした未来を予測することは止めようと諭
されます。サンプル・プログラムはプロトタイプということでしょうが、これ
もまたagileでは否定されます。agileでも実験は推奨されますが、それに時間
をかけることは御法度で、即座に製品に反映させることが求められます。

次に『2.5.4.プログラミング・テスト』です。ここはこの文章のハイライトで
す。

  プログラミングとテストは分けることの出来ない一連のプロセスである。通
  常、プログラムはテストを行ないながらプログラミングを行ない作成される。
  先にプログラミングを行ない、次のフェーズとしてテストを行なうのではな
  い。プログラミングとテストは交互に行なわれるのである。

これは、テスト・ファーストやTDDではありませんが、それでもagileでのユニッ
ト・テストであることに間違いありません。続く『2.5.5.品質保証テスト』に
もあるように、プロセス全体でテストに重点を置いてあるのはこの文章の大き
な特徴 (素晴らしい点) です。

次の『3. 開発組織』から組織論に入っていきます。このあたりは今の開発事
情とズレがあるところかもしれません。目を引いたところをピックアップして
いきます。

『3.2.人間的な要因』で:

  現在、見積りが正確に行なわれない最大の要因は、ソフトウェアの開発規模
  や期間が、そのプロジェクトのメンバーの関係に大きく影響を受けるためで
  ある。(中略) 見積りを正確に行なうためには、この人間的な要因による影
  響をなくす必要がある。

とあります。これははっきりいってムリ。見積もりというのは統計から導き出
されるものでしかないというのが最近の結論。統計というのは、単純に『正し
いか』というのではなく、『どの程度正しいか』ということです。結局のとこ
ろ、似たような経験を積み重ねて (統計の入力となるデータを集めて)、誤差
と上手に付き合っていくしかありません。

『3.2.3.規則による人間関係の安定化』というのも目を引きますが、それは後
回しにして、『3.3.役割・権限・責任』から:

  つまり、プロジェクト内で各メンバーは、各自の得意な専門分野に応じて、
  特定の専門分野の役割をメンバーの個性や能力に応じて割り当てられる。そ
  のプロジェクト内で公式の果たすべき役割を明示され、その役割にともなう
  権限と責任を持つことになるのである。

  そして、役割の明確化によって、次のような効果が期待できる。人には様々
  な得意な分野があるので、その得意分野に合った役割を与えることによって、
  メンバーに心理的な充足感を与えることができる。また、プロジェクトが変
  わっても担当する分野が変わらないため、一貫して特定の分野について専門
  的な知識を増やすことができる。これによって技術者は取得した知識が利用
  される効率を高めることができる。(略)

こうした役割の固定化というのはXPでは否定されています。得意分野があるの
は当然ですが、かといってそればかりではその人のためにも、組織のためにも
ならないからです。1つの分野ばかりでは好奇心が刺激されませんし、また代
替者の確保という点でもできるだけ広い視野を持ったほうがいいのです。

とはいえ、チーム・メンバの士気を考慮している点は特筆すべきです。

『3.3.1.プロジェクト内の情報の利用』に当時まだネットが一般的でなかった
ことがうかがえます。今ならばイントラネットやWikiといったものもからめて
書けたかもしれません。ただ、『情報の正確性』ということであれば、『義務』
や『権威付け』といったように形式張る必要はないでしょう。組織がまともな
ら、そうしたものは自然と生まれているはずです。

『3.4.柔軟な開発組織』あたりから大規模開発の話になります。このあたりは
著者も確信を持って書いているようには見えません。ただ、『3.2.3.規則によ
る人間関係の安定化』にもあったように、『規則』というもので組織を律しよ
うとする点は目を引きます。たとえば、『3.5.2.運営規則』にある規則例を抜
粋すると:

  * 各専門分野の担当者は、その担当する分野における問題の解決や機能の実
    現方法について優先的な権限を持つ。

  * 各分野の担当者はその担当する分野についての支援を、プロジェクトの他
    のメンバーから要請された場合はこれを拒否できない。

  * 他のメンバーにとって有用な情報や知識を持っている場合は、その情報や
    知識をそのメンバーに提供しなければならない。

  * ある機能を実現する方法が何通りもある場合は、最も経費のかからない方
    法でその機能を実現しなければならない。

  * 進捗会議は特別な事情がある場合を除き週一回の割合で必ず行ない、出席
    者は進捗状況及び開発作業上問題になっている事柄を報告する。

  * プロジェクト終了した時点で、そのプロジェクトで良かった点と悪かった
    点について各プロジェクト・メンバーから意見を収集する。

といったものがあります。これらはXPのpracticesを思い出させます。

ザッと飛ばして『4.6.新しい組織の構成』から:

  ソフトウェア開発企業の組織には、さまざまな異なった役割を担う部門が必
  要である。しかし、その中心となるのは、ソフトウェアの開発プロセスの中
  心となる開発組織と、それを管理・支援する周辺組織である。

  新しいソフトウェア開発企業の組織は、原則的にプロジェクトを編成し開発
  の中心となる技術者の集団からなる開発組織と、その開発組織に対して管理
  や情報の交換を行なう複数の周辺組織によって構成される。開発作業そのも
  のは開発組織が行ない、その企業組織外との接触は原則的に周辺組織が行な
  う。(略)

これもまたagileでは否定されるやり方です。開発者が顧客と直接やり取りす
ることが多くのトラブルを防ぐ秘訣だと考えられているからです。ちなみに、
『顧客』というのが必ずしも文字通りの意味ではないことはいうまでもありま
せん。XPでいえばストーリーを書いてくれる人物のことで、また違う言い方を
すれば、(製品ではなく) プロジェクトにお金を出してくれる人のことです。

以上です。結論は先に書きましたから繰り返しません。ところで、この文章に
はもう1つ特徴があります。オブジェクト指向のオの字も出てこないのです。
これは当時としては珍しいことだと思いますし、自分が好印象を持った理由の
1つでもあります。

やはり日本にもソフトウェア開発を真剣に自分の力で考えていた人がいたこと
をうれしく思います。当時も、そして今も、自分は加賀氏ほど理論立ててソフ
トウェア開発を説明することはできません。その理論から導き出されたものが
自分の意見とは異なるものだったことは残念ですが。それでも、この文章は読
む価値はありますし、実際に自分は勇気づけられました。感謝します。

--

ゲーム屋行って何気なく『偽りの輪舞曲』ってのを買っ
ちゃったんだけど、どうなの、これ? 何気なく買った
のにイラストの小冊子付いてきたし (笑)。

つか『イヅナ 弍 (仮称)』のほうが気になるんだけど (笑)

つか、サクセス、隙間突くのうまいね (笑)。シレンの
隙間がイヅナだったし、『偽りの〜』はファイアー
エムブレムの隙間だし (笑)。だから任天堂もサッサと
DSでFE出せっつの。

--

そういや書き忘れてたけど、Firefoxのタブ・バーって
コロコロできるじゃん? あれゼッタイ間違ったUIだって。
だって、中クリックでタブ消せるじゃん? だから、中
クリでタブ消すときにコロッてやっちゃうときがあるん
だよなぁ。それと、前のバージョンだとタブ・バーの
右端にクローズ・ボックスあったじゃん? あれなくなった
せいで、余計中クリで消したくなるんだよなぁ。

気ぃ利かしたつもりでダメになるUIの典型だよな。

本家Permlink


2007年08月17日

http://www.01club.org/softdev.html

10年以上前、つまりXPが知られる前の時点で、これだけ
考えられたのは素晴らしいことだと思う。

前提はほぼ自分の認識と同じ。ただ、そこから導き出される
結論や対処は違う。それについては改めて書く。

本家Permlink


2007年08月16日4

ああ、ウソ書いたかもしんない。都合がつくんなら、
お金や時間をいじるほうが手っ取り早いんだよな。
でも、やっぱりレバレッジが利きやすいのは人間
なんじゃないだろうか。

本家Permlink


2007年08月16日3

だからね、ソフトウェア開発を矮小化する、極端に
単純化するような話はマユツバなのね。上流・下流思想
なんて、まさにそうでしょう。

自分がこないだ書いた『ソフトウェア開発を活動から
見た図』にしたって単純化なんだけどね。でも、ある
活動は他の活動と相互に影響し合うという点を強調した
つもりなのね。

上流下流とか、ウォーターフォールとかのシーケンシャルな
考え方では、ある活動は次の活動にしか影響を与えない
わけでしょう。でも、現実にはそうじゃなくって、ある
活動は、その直接的な前後の活動、あるいは他の活動にも
影響を与えるわけで。単純なシーケンシャル・モデルよりは
ずいぶん複雑なんですよ。

もちろん、問題を複雑にしているのは人間だという視点も
必要だし。この視点が抜け落ちると一気にリスクが高く
なる。

--

新山さん、日本に帰ってくるの? 記事読んでると
そんな気がするんだけど。時期的にも大学の期末なんで
しょ、今。

落ち着いたらまた再開してください。おねがいします。

--

以前のここみたく、静的なページを延々書き換えるって
いうのもキャッシュを防ぐ手段になる。

テキストを画像にしちゃうという手もある。キャッシュは
されるけど検索には引っかからない。画像解析されたら
アウトだけど、今の段階ではそれがペイすることはないと
思う。

--

う〜ん、動く人が固定化されるのはある程度しょうがない
でしょうね。だから、動く人を増やす外ないでしょう。
そのためにはスカウティングが一番効果的なんじゃない
ですかね。公募よりは個人的に直接的に誘うほうが効果が
望めますよね。

それと、『何をやればいいか』というのをハッキリさせる
というのも必要かなぁ。『動け』といわれても何をやれば
いいかわからないですから。

スカウティングとからむ話ではあるんですけど、そう
なると、人を育てるのも必要かなぁ。たとえば、会長
とかと行動を共にするヤツを置いて、何をどうやれば
いいかを学ばせるとか。

--

あ、あれがない!

  * どうすれば女性のRubyユーザを増やせるだろうか?

--

何度も書いてることと重複するけど。

わからないことがあったら人に尋ねるっていうのは大切な
こと。この業界、『自分で調べろ』って教えることが
多いんだけど。あえて、それは間違いと断言しよう。

まず、自分で調べるより人に尋ねるほうが時間がかから
ない。時間はもっとも貴重な資源の1つ。

それと、コミュニケーション。チームの仲間ならば、
尋ねることで問題を共有することになる。尋ねるべき
人が外部に属す場合もある。そういうときにも積極的に
接触することで『顔をつなぐ』こと。そういう積み重ねが
人脈というものになる。人もまたもっとも貴重な資源の
1つ。

『自分で調べるほうが早い』と安易に考えないこと。
それは上記のようなメリットを捨てることになる。
まず第一の選択肢として人に尋ねることを考えること。

メールよりも、電話よりも直接会うことを大切にすること。
直接会うときの情報量は他の手段よりもはるかに多い。
また、直接会いに行ったほうが相手もその気になる。

『相手の手間を取らせて悪い』とか思わないこと。
尋ねたとき『自分で調べろ』と答えるような人間は、
役に立たないと思っていい。それなりの人間なら、
資料なりポインタなりを教えてくれる。

ソフトウェア開発は集団での作業。だから助け合うことが
大切。技術は隠すものではなく伝えるもの。だから、教え
合うことが大切。

--

上のを書いてて思ったんだけど、ソフトウェア開発で
重要な資源は:

1. お金
2. 時間
3. 人間

くらいなものしかない (順不同)。他の商売だったら、
場所とか設備とかあるけど、ソフトウェア開発では
それほど重要じゃない。

これを単純な式にしたら:

  ソフトウェア = お金 + 時間 + 人間

みたいな話になる。別に:

  ソフトウェア = f(お金, 時間, 人間)

でもいいけど、基本的には、突っ込んだ資源に応じた
成果が得られると考えられている。

でも、お金と時間は固定されてることが多い。だから、
人間に柔軟性を持たせるしかないんだな。

このあたりはXPのスコープの話と似てる。

じゃあ、人間に柔軟性を持たせるっていうのは、どう
いうことなんだろう。

まず、人間は学習できるっていうことがある。時間が
経てば能力が上がると期待できるわけだ。

それと、士気の問題がある。これは諸刃の剣だけど、
士気が上がればよく働いてくれる。

あと、上で書いたように、集団ならば、能力を補い合う
ことができる。

こういした点に留意しながら、人間に柔軟性を持たせる。
お金や時間が固定されていても、人間というパラメータを
動かすことで大きな出力を生むことができる。

上の式の例でいえば、人間という入力からいかに大きな
出力を得るかがカギということ:

  ソフトウェア = f(お金, 時間, g(人間))

--

ああ、3つの資源は、基本的には相互に代替不可能だと
いうのが『人月の神話』以来の定説ということも付け
加えておく。

本家Permlink


2007年08月16日2

https://www.hellowork.go.jp/kensaku/servlet/kensaku?pageid=001

さすがに公共事業にJavaは強いな (笑)。

『正社員』をキーワードにほんのちょっと見てみたんだ
けど。確かに、ないことはないけど、希望が持てるのは
少ないかも。こういう言い方は『ゼイタク』っていわれる
のかもしんないけど、でも、もし今自分が失業して、もし
プログラマ以外の職を探さないといけないとしたら、
ちょっと途方に暮れるっていうか、自殺したほうがいい
かもしんない (笑)。

--

こうやって見ると、やっぱりプログラマ (あるいはSE)
っていうのは、ちょっと変わってるんだよな。正社員の
募集もチラホラあって、おカネもそんなに悪いわけじゃ
なくて、でも資格が必要なわけじゃないし。まぁ、経験
者が優遇されるのは、どこの世界でもおんなじだから。

この仕事、無闇にキツイと思われてるようだけど、そんなの
現場によってマチマチだから。それに、結構求職がある
ってことは、そういうキツイとこは避けられるっていう
ことでもあるし。

あと、個人的には、他の職業と比べても、未来に希望が
持てると思う。もちろん、個人の努力次第だけど。要は
実力の世界っていうこと。

本家Permlink


2007年08月16日1

いや、層を設けること自体をどうこういってるわけじゃ
ないのね。層を設けるっていうのは1つのテクニック
だから。

ただ、テクノロジーっていうのは使われてナンボだから。
だから、抽象層ばかりに目をやるんじゃなしに、具象層
にも目を向けるっていうか、具象にこそニーズはある
わけでね。

いや、抽象 vs 具象っていう見方だけじゃなくって、
機械寄り vs 人間寄りっていう見方でもおんなじで。

だから、テクノロジーを全体的なものとして捉えないと
いけないっていうこと。よく『技術的には優れているが
普及しなかった』みたいな話があるけど。それって、
やっぱりダメでしょう。だから、まずニーズをしっかり
つかんで、それをどう技術に転化するかっていう、そう
いう全体的な話じゃないですか。

本家Permlink


2007年08月16日

Xlibを使ってみて感じるのは、その階層というか抽象化へのこだわりです。
Xlib自体はウィジェットを提供しない。ウィジェットを提供するのはXtだった
り、他のツールキットだったりするわけです。XlibがGUIの下層を担うことで、
様々なツールキットが生まれました。こうした多様性はXがもたらした利点の1 
つだといわれます。でも、自分はちょっとやりすぎちゃったんじゃないかと思
うんですよね。

Xは、確かに、他のウィンドウ・システムを押しのけて標準の地位を獲得しま
した。でも、だからといって、現状のUNIXを見たとき、必ずしも成功したウィ
ンドウ・システムとはいえませんよね。成功したというんなら、今のUNIXのデ
スクトップ環境がこんな悲惨な状態にあるわけがない。デスクトップのことま
でXに責任を負わせるのは酷だっていう意見もあるでしょうけどね。

Xlibのこの階層化、抽象化へのこだわりっていうのは、非常にMITらしく感じ
るんですよね。もっとはっきりいえばLisp臭い。下層をしっかり作れば、あと
はどうにでもなるだろうっていう。

で、話は飛ぶんですけど、この『下層をしっかり作れば、あとはどうにでもな
るだろう』っていうのは、多分、P.Graham氏のいうボトムアップ・プログラミ
ングの根幹を成す精神じゃないかと思うんですよね。で、もしこの推理が正し
いんなら、それってやっぱり間違いなんですよ。

Joel氏がいってた『宇宙飛行士』の話があるじゃないですか。あれと同じなん
ですよね。下層、つまりインフラにこだわりすぎるのは良くないんですよ。
ニーズが見えてないのにインフラもクソもないわけで。プログラマっていうのは、
自分も含めてですけど、往々にして使われないものにこだわっちゃう傾向があ
ります。それってニーズを無視してるんですよね。

で、Xの話なんですけど、さすがにXみたいなインフラともなると、ある程度は
先を見通して作っておかないと後々大変なことになります。実際、自分がいく
ら『Xは成功してない』っていっても、現に生き残ってるわけですし、失敗し
たといい切れるもんでもない。ただ、もうちょっとどうにかなんなかったのか
と思うわけです。

とりあえず今はデスクトップも含めてX.orgが主導しているようで、まだ期待
を持てそうです。

--

まぁ、なぁ。そもそも研究室で生まれたもんだしなぁ。MSみたいに豊富なリソー
スがあったわけじゃないだろうし。層をハッキリ分けて人を集中するっていう
のもアリだったのかなぁ。それに、例のUNIX Warsもあったしなぁ。Xがそこで
生き残れたのも、その抽象化のお陰なんだろうけどなぁ。

本家Permlink


2007年08月15日

こういうの:

  ID2SYM(rb_intern("signed")

って、イディオムみたいなもんなんですけど、マクロに
なってないんですか?

/usr/local/src/ruby-1.8.6-p36$ find . -name '*.c' | xargs grep 'ID2SYM(rb_intern("'
./ext/enumerator/enumerator.c:    sym_each		= ID2SYM(rb_intern("each"));
./ext/enumerator/enumerator.c:    sym_each_with_index	= ID2SYM(rb_intern("each_with_index"));
./ext/enumerator/enumerator.c:    sym_each_slice	= ID2SYM(rb_intern("each_slice"));
./ext/enumerator/enumerator.c:    sym_each_cons	= ID2SYM(rb_intern("each_cons"));
./ext/openssl/ossl_pkcs7.c:	return ID2SYM(rb_intern("signed"));
./ext/openssl/ossl_pkcs7.c:	return ID2SYM(rb_intern("encrypted"));
./ext/openssl/ossl_pkcs7.c:	return ID2SYM(rb_intern("enveloped"));
./ext/openssl/ossl_pkcs7.c:	return ID2SYM(rb_intern("signedAndEnveloped"));
./ext/openssl/ossl_pkcs7.c:	return ID2SYM(rb_intern("data"));
./ext/syck/rubyext.c:    sym_model = ID2SYM(rb_intern("Model"));
./ext/syck/rubyext.c:    sym_generic = ID2SYM(rb_intern("Generic"));
./ext/syck/rubyext.c:    sym_bytecode = ID2SYM(rb_intern("bytecode"));
./ext/syck/rubyext.c:    sym_map = ID2SYM(rb_intern("map"));
./ext/syck/rubyext.c:    sym_scalar = ID2SYM(rb_intern("scalar"));
./ext/syck/rubyext.c:    sym_seq = ID2SYM(rb_intern("seq"));
./ext/syck/rubyext.c:    sym_1quote = ID2SYM(rb_intern("quote1"));
./ext/syck/rubyext.c:    sym_2quote = ID2SYM(rb_intern("quote2"));
./ext/syck/rubyext.c:    sym_fold = ID2SYM(rb_intern("fold"));
./ext/syck/rubyext.c:    sym_literal = ID2SYM(rb_intern("literal"));
./ext/syck/rubyext.c:    sym_plain = ID2SYM(rb_intern("plain"));
./ext/syck/rubyext.c:    sym_inline = ID2SYM(rb_intern("inline"));

--

本屋行ったら、たまたまユニマガが置いてあったんだけど。
一体誰があんなクズ雑誌買うの? チンポナエナエだよ。

ほんと、法人の定期購読しか狙ってねーのな。そんな総会屋
みたいなマネは止めろっつの。そんなことするくらいなら、
潔く死ねといいたいね。

--

いやさー、結局、コンピュータ系の雑誌がクズだっていう
のは、記者がいないからでしょ? 編集ばっかで。記事は
アマチュアしか書いてねぇじゃん? どっかで技術者として
働いてる人に記事頼んでるだけじゃん? それってアマ
チュアが記事書いてるってことじゃん?

だから、記者がその気になって取材して記事書けば、
それなりに売れるもんが作れねーの?

自分は最近よく『東洋経済』を買うけど、あれなんか
よくできてると思うよ。話題になる特集も多いし。
でもって、あれってあんましアマチュアが書いてる感じは
しないじゃん? 専門家に意見を聞くこともあっても、
それをまとめてるのは記者だよね。週刊誌で700円近い
もんが売れてるっていうのもすごい話と思わないの?

--

で、ユニマガに戻るけど、『うぇぶあぷりけーしょん
さーばー』なんて、ピントズレズレだろ。しかも、記事
書いてるのはIBMとかBEAとかの連中で、そりゃただの
宣伝記事特集だろ。ネコもまたぐわ、そんなもん。

--

いや、最後の一文は余計だった (笑)。

本家Permlink


2007年08月14日1

で、黄色いのと黒いのと、どっちがwotaさんなの?

--

コーディングをイヤがるモデラーは死ね。

--

ワロス >>940

本家Permlink


2007年08月14日

ん〜、仕事じゃやったことないんですけど、OpenBSDの
コードをマネて、関数呼び出しに``(void)''付けたり
することもあるんですよね。

たとえば:

  (void)printf("%d", 100);

みたいな。

でも、RubyのCコードだと、VALUE返してくる関数が多く
って。rb_define_methodあたりもVALUEを返してきます
よね。そうするともう(void)だらけになっちゃう。

そもそも、なんで(void)を書くのかもよくわかってない
んですけど (笑)。セキュリティより可読性を上げる
ために付けてると思うんですけど。

rubyでもあんまり付けてないですね。数える程度。
やっぱやんなくていいかなぁ。

本家Permlink


2007年08月13日

すみません。2chのスレ読んでおりませんでした。
2chで読むとこといえばbbynews (と市況板のとある
スレ) くらいなもんで。

つか、もうすぐ1000行きそうだったんで焦った (笑)。

ありがとう >>940 (実はまつもとさん)

あと、おっぱいカッコワラタ。

--

うへ、Dolphin Smalltalk、discontinuedですか。

ちなみに、Squeakはライセンスが変わって、今はレッキ
としたオープン・ソースのはず (各自確認のこと)。

Squeakが``production-ready''かどうかは意見が分かれる
ところじゃないですかね。自分は十分production-readyと
思ってます。というのは、あの独特のGUIを別にすれば、
他のGUIを持たない言語、たとえばRubyであるとか、PHP
とかであるとかと『製品レベル』という点では大差
なかろうと思うからです。

それがSmalltalkであるがゆえにGUIばかりに目が行って、
それを見て『製品レベルにない』と騒ぐのはいかがな
ものかと。それに、あのGUIは、Morphという先進的な
フレームワークの成果でもあって、そこを評価しないと
いけない。さらにいえば、サウンドや3DのAPIも整って
いるし、そういう面でいえばJavaに決してヒケを取ら
ない環境なんじゃないですか。

まぁ、唯一の欠点といえばドキュメントかな (笑)。

--

囲碁で『手どころ』っていう言葉があります。『中盤の
難しい局面』、つまり『考えどころ』といった意味です。

でも、この手どころを感じ取るのもまたセンスなんじゃ
ないかと思うんですよね。

最近では持ち時間も短かくなってきてますから、時間を
かけて考えるべき局面かどうかの判断が非常に重要に
なっています。もちろん、『時間をかけていいか』を
判断するために時間をかけるわけにはいかないので、
即断すること、つまりセンスが必要になるわけです。

もちろん、囲碁の話 (だけ) をしてるんじゃないですよ?

日々のコーディングっていうのは、大抵はありふれた
作業です。リファクタリングにしてもメソッドを切り出す
といったことがほとんどです。考えることなく、手が動く
ままに進んでいいことがほとんどなわけです。でも、
どこかで腰を据えて考えなきゃいけない場面が出てくる。

  古典的な方法論では、考えどころっていうのは前もって
  わかっていたわけです。というか、コードを書きはじめる
  前に (囲碁用語でいえば) すべてを読み切ることが要求
  されていたわけです。なんともおかしな話です。

考えなきゃいけない場面では、とことん考えることが
大切です。囲碁では、手どころでの見落とし、読み抜けは
負けに直結します。

だから、自分らも手どころを敏感に察知しないといけません。
とはいえ、まぁ、大抵はすぐわかるんですけどね。
たとえば、手がパッタリ動かなくなったときとか。でも、
そうじゃないときもあります。何かイヤな臭いを感じた
ときとか。そういうときは、それが考えどころに値するか
どうかを即断しないといけません。

ちなみに、即断っていっても、常に数秒、数分で決断しろ
っていうわけじゃなくって。判断にかけられる時間は
状況次第です。

本家Permlink


2007年08月12日1

いや、Data_Wrap_Structで解放関数指定してるん
だから、その中で資源を解放してやらいいんじゃね? 

--

『文学少女と``死にたがりの道化''』。ほんとにアマゾンは、
まとめて注文すると1ヶ月くらい届かないことがあるからな。
しかも受け取りの時間指定もできねぇし。客なめてんのか?

で、卓球少女のほうを先に読んじゃったんだけど、会長が
すすめてくれたのはこっちなのね。卓球少女と比べると
ストーリー展開がうまくなってる気がする。

作者の野村美月は、まだラノベでしか活躍してないみたい
だけど、赤川次郎並みに化ける可能性がありそう。つまり、
本格的な推理で売るんじゃなくって、ストーリーテリングの
うまさで売るっていう意味で。

そういう意味では、文学をギミックにしたのはあんまり
いい戦略じゃなかったように思う。どこまで広い層の
人たちに受け入れられるか疑問が残る。このシリーズ、
もう5冊くらい出てるみたいだけど。

ちなみに、自分も文学作品とは無縁の人間。芥川賞とか、
直木賞とか全然興味がない。

本家Permlink


2007年08月12日

ひょっとして、Cの中だと:

raise RuntimeError.new

の形式は呼び出せない?

rb_raiseって、第一引数をnewしようとするみたい。

なんでこんなことを気にするかっていうと、
コンストラクタでメッセージ以外にもエラー・コードを
渡すような例外を投げたいから。

で、ちょっと調べたら、こんな書き方ができると
わかった:

class FooError < StandardError
  def initialize(*args)
    super(args[0])
    @errno = args[1]
  end
end

begin
  raise FooError, ['failed', 100]
rescue
  p $!
end

でも、これもCではできなさそう。

あとはrb_eval_stringかなぁ。一応動くけど、backtraceが
汚ないのがなぁ。

それだったら文字列解析するほうがマシかな。

たとえば:

rb_raise(cFooError, "failed^L%d", errno);

みたいな感じで。もちろん``^L''は実際には制御文字に
するんだけど。

本家Permlink


2007年08月11日

さすが東スポ。薬物事件でラロッカのコメントを持って
くるとは (笑)。

  昨年、ヤクルトでガトームソンと同僚だったオリックス・
  ラロッカ (34) は今回の問題に敏感に反応し、本紙に
  こう打ち明けた。

  「彼は髪の毛に関して気にしていたようだ。ボクは頭の
  真ん中がハゲてしまっているけど、それを気にしたら
  仕事もできない (以下略)

そいでもって、ラロッカの写真が前からと後ろからの2枚。
しかも、そのキャプションが「ハゲの鑑!? ラロッカ」
だもんな (笑)。

--

今年のG1は久しぶりに興味が持てたんだけど。やっぱり
越中ね。それと真壁。

まぁ、しかし、越中が2敗目、しかもミラノに続いて矢野
だからね。kamiproで予想されたとおりじゃねぇかって。
それで最後は棚橋だろ。なんか見えちゃうよな、先が。

真壁もなぁ。曙はともかく、天山なんかに負けんなよって。
それで最後はチョーノだろ。なんか見えちゃうよな、先が。

本家Permlink


2007年08月08日1

LLナントカとか、ナントカカイギが盛り上がるっていう
のは、仕事抜きのプログラミングの話ができるからじゃ
ないだろうか。より正しくいうと、プログラミングを
仕事として見る人間ではなく、プログラミングが好きな
人間が集まるからじゃないだろうか。同好の士が集るん
だから、そりゃ盛り上がるだろう。

外の人から見ると意外かもしれないけど、自分の仕事場を
見ても、プライベートでもプログラミングをするヤツって
いうのはほとんどいない。CPUがデュアルコアだとか、
マザボがどうたらとか、そういう話は出るけど、LLが
どうしたとか、STLがどうしたとか、そういう話は滅多に
出ない。

それほどプログラミングが好きな人間は希少なんだと。
希少ということは、その手の話に飢えてるということで、
そういうヤツばっかが集まったら、そりゃガツガツ行くし、
パンピーはヒクわな。

本家Permlink


2007年08月08日

やっぱり、単純にソフトウェアを作って売るっていうのが
限界に来てるんでしょうね。製造業のメタファーの中で
最悪なのがこれだったのかもしれない。

それと、『もてなす』っていうのは、hospitality以上に
日本的なものだと思うし、あと日本的なものを加えると
したら『きめこまやかさ』だと思う。だから、きめ
こまやかにもてなすっていうのが日本の商売の根っこに
なると思う。これはものづくりでもそうでなくても。

--

自分はデバッグが大の苦手なんです。そんな自分には
やっぱりバージョン管理システムが欠かせません。

あんまり効率のいいやり方じゃないですけど、バージョンを
さかのぼって、どこでおかしくなったか調べます。おかしく
なったバージョンを特定できたら、その前のバージョンとの
差分を見て、バグを突き止めます。

こういうやり方をする場合、やっぱりバージョンを細かく
上げておくほうがいいです。変更が小さければ、入れて
しまったバグも見つけやすくなります。

自分の場合、バージョン番号は、2日で100くらい上がる
ときもあります。

自分は仕事ではCVSを使っているんですけど、やっぱり
一括でコミットができない点は不満です。リビジョン
番号はファイルごとにバラバラですし、コミットされた
時間もズレます。

それと、コミット・ログですけど、よく『何を変更したか
よりも、なぜ変更したかを書け』といわれます。確かに
一理あるんですけど、でも実践的じゃないんですね。
ログっていうのは一覧するもので (C-x v l)、そのとき:

* extract method.
* extract method.
* extract method.

なんていうログが並んでても何の助けにもなりません。
やっぱり:

* extract doit().
* extract dothat().
* extract dothis().

といったように、ある程度何を変更したかがわるほうが
手がかりになります。

自分は、Meadowでコードを書いて、Visual Studio (VC++
6.0) でコンパイルしています。確かに面倒なんですけど、
Emacs VCだけでも見返りは受けられてると思っています。

本家Permlink


2007年08月07日

へー、未来検索ブラジルはPHP縛りなのか。

本家Permlink


2007年08月06日


本家Permlink


2007年08月05日


本家Permlink


2007年08月04日

やっぱりC言語のfor文思いついた人は天才だな。C言語が
オリジナルじゃないかもしんないけど。

K&Rのシェルソート:

void shellsort(int v[], int n)
{
    int gap, i, j, temp;

    for (gap = n / 2; gap > 0; gap /= 2)
        for (i = gap; i < n; i++)
            for (j = i - gap; j >= 0 && v[j] > v[j + gap]; j -= gap) {
                temp = v[j];
                v[j] = v[j + gap];
                v[j + gap] = temp;
            }
}

--

にも関わらず → にもかかわらず (にも拘わらず)

--

いや、テストのコストは高いからこそ、毎日の作業にしちゃ
おうっていう見方もできるわけで。

でも、gccやemacsにテストがないっていうのは初耳だなぁ。
PostgreSQLなんかはregression testがあったけど。あと、
最近はrubyにもテストがあったはず。

本家Permlink


2007年08月03日1

『東洋経済』でも『若年層における正規雇用と非正規雇用との間の経済格差と
その拡大や固定化』という問題が取り上げてますね。その分析の資料となった
のが:

http://wwwdbtk.mhlw.go.jp/toukei/kouhyo/indexk-roudou.html

にある『賃金構造基本統計調査』というもの。面倒なんで東洋経済の分析を鵜
呑みにすると、非正社員には希望はありませんね。一方で、非正規雇用は拡大
してるし、『いったん非正規雇用になると、正規雇用への転換が難しいという
事情に変化は見られない』といいます。

ん〜、やっぱ自分が気楽すぎるんですかねぇ。

--

たかだか4年か6年で『つまらない』と思えるくらいになるほど極められるもん
なのか、プログラミングは?

この世界、天才と呼ばれる人はたくさんいるけど、自分があげるとしたら、ま
ずGuy Steel氏。Steel氏はSchemeの発明者の一人で、今はFortressっていうプ
ログラミング言語を作ってる。今も自分でコーディングしてるかどうかまでは
知らないけど。

http://en.wikipedia.org/wiki/Guy_L._Steele%2C_Jr.

次にあげるとしたらDan Ingalls氏。Smalltalkの開発者の一人で、今でも
Squeakにcontributeしてる。

http://en.wikipedia.org/wiki/Dan_Ingalls

この2人がどこの大学出身かは知らない。でも、若くして名声を得て、それで
いて今でもプログラミングに情熱を燃やしているのは尊敬に値する。

本家Permlink


2007年08月03日


本家Permlink


2007年08月02日

バカは気紛れ。

--

リスクを取るのは基本的にお客さんなのね。自分らに
できるのは、どんなオプションがあって、どんなリスクが
あるかを示すことくらい。これは当たり前のことなんだ
けど、当たり前のことだけに非常に大切なことでもある。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails