«前の日(02-17) 最新 次の日(02-19)» 追記

Matzにっき


2004-02-18

_ [OSS]オープンソースの日

武藤さんふと思っておられるが、 実現できたら面白いかもしれない。

「オープンソースの日」とか「フリーソフトウェアの日」とか「FLOSSの日」とか「シュッシュッの日」とかを定義するとマーケティングの向上が図れるだろうかとふと思ったり。

しかし、バレンタインデーというのは人間の根源的欲求の3つのうちふたつ(食欲と性欲)を刺激するのが 良いのであって、オープンソースでは難しいかも。

あなたの好きな人にオープンソースソフトウェアの入ったCD-ROMを贈ると願いがかないます。

...だめそう。よっぽど頑張ってもサンジョルディの日の二の舞だな。

贈るならCD-ROMより(ホンモノの)Rubyが良いかも。 ちょっと値が張る*1のが難点だが。

追記:

PerlやPythonを贈ってみる」とのことだが、 Perl(Pearl/真珠)はともかく、Pythonはワシントン条約やら銃刀法やらに違反しそうだ。 おまけに女の子にもウケそうにないし。

法律違反ではない 『Monty Python & Holy Grail』でも、女の子ウケはしないと思うよ。 喜ぶ女の子がいたら、それはそれで貴重な気がする。

*1  ルビーはダイヤモンドの次くらいに高い

本日のツッコミ(全5件) [ツッコミを入れる]

_ とおりすがり [じゃあ本物のPerlとかPythonを送ってみるとか。]

_ Sla [Javaは…お風呂ジャバを?(爆)そもそもオープンソースじゃないや…]

_ なかだ [せめてコーヒーかお茶を。]

_ OliB [ペンギンやデーモンやRubyちゃんのぬいぐるみを愛する人(彼氏彼女子供)にプレゼントする日というのはどうでしょう。別..]

_ Python使いさん [贈り物をするなら「Spam」ではないでしょうか? 女の子ウケしそうにないですが。]

[]

2005-02-18

_ [Ruby] 関数呼出し

しばらく原稿に追われてRubyをいじる暇がなかったので、 反動としてRubyについて考えてみる。こういう時間が一番充実しているような気がする。

関数とレコードをベースにオブジェクト指向プログラミングをエミュレートするPythonと違い、 オブジェクト指向プログラミングによって関数をエミュレートするRubyでは、 lambdaはあっても、呼び出しが格好悪い

f = lambda{|x| p x}
f.call(12)

と「.call」が必要だからだ。気持ちとしては

f = lambda{|x| p x}
f(12)

と書きたいものだ。そこで

  • 関数的呼出しの関数名部分がローカル変数のときには、そのローカル変数の値に「call」メソッドを適用する

というルールを導入するのはどうだろうか。以前にも同じようなことを考えたのだが、

  • 「call」ではなく「()」という特殊メソッドを適用していた
  • 「foo.bar(12)」なども「foo.bar().call(12)」に適用できることを考えた

こともあり、あまりうまくいかなかった。 今回の条件であるローカル変数があるかないかならコンパイル時に判断できるので、 実害は少ないような気がする。

欠点はローカル変数名と同じ名前の手続きが呼べなくなることだ。 通常あまり問題になることはなさそうだが「p」のような重複しやすいものもあるしなあ。

なにか回避策を用意すべきだろうか。

_ [Ruby] Look at me, I’m a Signal!

Ruby流DIコンテナNeedleの開発者であるJamis Buckが5年間プログラマーとして働いたBYUを辞めて、 Ruby on Railsを開発したDHHの 37signalsに転職するという話。

在宅で仕事をするらしいのだが、 アメリカのプログラマの流動性を感じさせる一件。 また、Rubyが人の人生を変えるのを見るとなんとも言えない気持ちになる。

彼の成功を祈る。

本日のツッコミ(全8件) [ツッコミを入れる]

_ ささだ [@p = lambda{...}; @p() は救いませんか。]

_ まつもと [現時点では救わなくてもいいんじゃないかなあって思ってます。救いたいという積極的な理由があれば考えます。]

_ 野分 [結局 f = lambda(:p){|x| p x} f.p(12) は無しでしょうか?]

_ なかだ [インスタンス変数は、define_methodがあるので必要性は低いんじゃないでしょうか。 野分案は、今まで特異メソ..]

_ まつもと [野分案は秀逸なアイディアだと思うんですが、「lambdaが返すもの」(要するに「関数」)の性質としては違和感があるん..]

_ なかだ [Delegate?(笑) は使ってるから… AdaptorとかThunkとか。]

_ なかだ [というか、Procのサブクラスじゃなきゃいけないってことはないかも。 module Kernel def att..]

_ 野分 [あとはClosureとかBlockとかですかね……微妙に違和感ありますけど。 Mimic、Emulator、Imit..]

[]

2006-02-18

_ [教会] 掃除

教会の掃除当番。片付けて、掃除機かけて、ゴミ捨てて、イスを並べる。きれいになった。家族総出でやればそんなに時間はかからない。

世間的には大家族らしいので。

_ [Ruby] 多重継承言語としてのRuby

Rubyはフル機能の多重継承を持たずMix-inしかないので、世間的には単純継承言語(+α)と認知されていると思う。

が、世間での認知はともかく、Mix-inが多重継承の一形態である以上、実質的に多重継承的な使い方が出来ることは厳然たる事実だ。

多重継承のある言語としてRubyを見ると

  • インスタンス変数が全クラス階層で共有される
  • privateメソッドとpublicメソッドの名前空間が同じ

という二点はかなり痛い。

前者は継承に参加する全クラス(モジュール)間で名称に衝突があってはいけないことを意味する。単純継承言語ではこの条件はあまり厳しくない。スーパークラスへのラインは一本しかないので調整が難しくないからだ(にも関らずSmalltalkではインスタンス変数はクラスごとに独立だったはず)。しかし、多重継承言語では継承してくるクラス(群)が独立で調整が効かない場合があるので、この制限は厳しい。この点ではクラス名を明示する必要があるC++や名称変更機能があるEiffelの方がはるかに優れている。

っていうか、クラスをモジュールとして考える(OOSC的)立場からは C++ってかなり良い言語なんじゃないかなあ。MeyerはC++大嫌いみたいだけど。

意外なことにCLOSでは(少なくとも標準のMOPでは)スロットの名称重複は継承優先順位の高いものだけが優先になり、解消の余地がない。

後者は局所的なサブルーチンとして使おうと思ったprivateメソッドがよそのクラスのpublicメソッドと名称が重複していた場合、現状では上手な解決策がないことが問題だ。 Rubyには原始的なaliasとundefがあるが、この問題はこれらでは解決できない。

で、だ。

どちらの問題にも解決のアイディアはあるのだが、効率と互換性の両方に懸念があるのだな。

詳細は後日。

_ [Ruby] Rails' Ridiculous Restrictions, a Rant

Joel on Softwareサイトの掲示板への投稿。 Railsの気に入らない点について。

書いた人は「a Hack」さんで、あちこちで誤解されているようだがJoelではない。

気に入らない点は以下の通り。

  1. RDBのメタデータ(外部キーなど)を見ないので、テーブル間の関連は別の場所(Rubyコード)で記述する必要がある。
  2. 修正するたびにリスタートしなければならない
  3. マニュアルがひどい
  4. varchar(40)に80文字データを入れても知らんぷり
  5. 知られざるルールが多い
  6. 設定コードがあちこちに分散している

ただし、「気に入らない」と文句を言いながらも、その実は「I only say all this because Rails is the first framework worth criticizing.」であるとも述べている。

これに対して、DHH本人が反応している。こまめだね、彼も。

  1. 外部キーは関連を表現するのに十分でない。不完全な情報に頼るよりは明示的に記述したほうがよい
  2. 勘違いだと思う。development modeを知らない
  3. 同意する。(http://www.railsmanual.orgというサイトがあるとの情報あり)
  4. バリデーションも明示的に行われるべき
  5. 同意する。まとめるのに協力がほしい
  6. 設定コードは一ヶ所にまとめるべき。誰かが間違っていたら、直せるよう指摘してあげてほしい
本日のツッコミ(全9件) [ツッコミを入れる]

_ とみた [「とう差異と」→「というサイト」?]

_ まつもと [ああっ、直したと思ってたのに。ありがとうございました。]

_ むらやま [「名勝」 -> 「名称」?]

_ まつもと [えーん。直します。ありがとうございました。]

_ shiro [CLOS的には、「スロットの名前の衝突はパッケージで回避してね」ということなのでしょう。]

_ まつもと [でしょうね、たぶん。> パッケージで回避。 CLOS流に慣れてない私には使いこなせません。]

_  [本文と関係無くて申し訳ないのですが、 最近rssにだけ載っている記事をよく見かけます。(クリックすると「日記はありま..]

_ まつもと [「あ」さん、報告ありがとうございます。 きちんと調べてみたいので、今度「日記はありません」と言われた時にそのURL..]

_ アジャ [どれもRailsの本質ではないですよねー(^^; 故意的な野次に見受けられます。 相手にしない勇気も必要か。]

[]

2007-02-18

_ [教会] 評議会

月に一度の評議会。

毎週のことではないので、たまに評議会があることを忘れる人がいるのは ある程度しょうがないと思う(私も忘れたことがある)が、 今日は珍しい人が忘れてた。電話したら「うっかりしてた」んだそうだ。 おうちの事情で忙しいからなあ。

今日は司会。さすがにもう時差ボケはないと思うのだが、でもくたびれた。 さらに集会終了後に半期に一度の監査があったから余計だ。 「できるだけ毎週通帳記帳してください」と言われた。 職場から銀行は近いから全然難しいことではないのだが、 つい、おっくうがっているのがバレちゃうな。

[]

2008-02-18

_ 渡米

6時前に起床。成田でネットアクセスするためにワイヤレスゲート ヨドバシカメラオリジナルプランを購入。

朝、7時すぎに出発。 途中でデジカメを忘れたことに気がついて引き返す。 わりとぎりぎりの時間に米子空港に到着。 米子空港出発組と合流。

米子から羽田へ。羽田からリムジンバスで成田へ。 成田ではワイヤレスゲートのおかげで快適にネット。 夕方からUAでサンフランシスコへ。

サンフランシスコについたらまだ午前中である。

バスで梅田望夫さんのところへ。 祝日(Presitent's Day)なのに親切に対応していただく。 ありがたい。

いろいろなことについてお話したが、 同調圧力や「空気を読む」それから「多様性」について が中心的な話題だったように思う。

kuromomoさんがミーティングの内容を録音していたので、 どこかで(ITPro?)で公開されるのではないかと思う。

_ Matzに聞いてみた:効率の良い開発についてどうお考えでしょう? - builder by ZDNet Japan

以前にインタビューを受けたものが公開された。 なんとなくRubyの宣伝っぽく聞こえるような書き方がしてあるが、 例によって本人にはそんなつもりは毛頭ない。

生産性とスピードがより重視される、というのが基本的な内容なんだけど、 「Web系に限定されるんじゃないか」と読む人も多いんじゃないかと思う。 少なくとも、「今」に限定して考えるとその通りだろう。 基幹系はWebのようには行かない。 また、現時点でRubyを基幹系に適用すべきとは考えない。

「できない」とは思わないし、実際に適用している人もいるんだけど、 Web系よりはずっと難易度が高いので、できる/できないの判断が自ら責任を持って行うべきだろう。 人に聞かないとRubyが適用可能か判断できない人には、まだ早い。

とはいえ、「今後」までを視野に入れると、 分野に関らずソフトウェア開発について同じような圧力は高まるだろう*1。 そうすると、「Web系以外は関係ない」話としておいて良いかどうかはちょっと疑問だ。

今後の業界変化の一方向として頭の片隅にくらいに置いとくのが良いのではないだろうか。

*1  SOX法など別方向の圧力もあるのは認識している

_ レノボX300 封筒に入る超薄型ThinkPad - Engadget 日本語版

Macbook Airと同じくらい薄いThinkpadについて。 かっこいい。魅力的。 タッチパッドは要らないけど。

この間X61を買ったばかりなので、出たらすぐに、というわけにはいかないとは思うけど。 弾さんみたいに年に1台とかいうペースでは買わないし。

_ Hilton San Francisco

今回のサンフランシスコでの宿泊先。

広いのはいいが、ネットアクセスが1日15ドルってのはどうよ。

本日のツッコミ(全1件) [ツッコミを入れる]

_ kuromomo [今回、同行しています。 とてもエキサイティングな旅です。 梅田さんとMatzさんの対談は、ITProでの公開を予定し..]

[]

«前の日(02-17) 最新 次の日(02-19)» 追記

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.