バリケンのRuby日記 RSSフィード

2009-05-03

[] Lingrが5月いっぱいで終了!  Lingrが5月いっぱいで終了! - バリケンのRuby日記 を含むブックマーク はてなブックマーク -  Lingrが5月いっぱいで終了! - バリケンのRuby日記  Lingrが5月いっぱいで終了! - バリケンのRuby日記 のブックマークコメント

うーん、とっても残念。

http://japan.cnet.com/blog/kenn/2009/05/01/entry_27022150/

せっかくだから、次のルームにしばらく入っているよ。気軽に話しかけてね。

http://www.lingr.com/room/0N4N2Ct6WdT

トラックバック - http://rubyist.g.hatena.ne.jp/muscovyduck/20090503

2009-01-31

[] Google検索がおかしい?  Google検索がおかしい? - バリケンのRuby日記 を含むブックマーク はてなブックマーク -  Google検索がおかしい? - バリケンのRuby日記  Google検索がおかしい? - バリケンのRuby日記 のブックマークコメント

検索結果へのリンクが、すべて「このサイトはコンピュータに損害を与える可能性があります。」ってなっちゃうみたい。

f:id:muscovyduck:20090131235739p:image

こういうこともあるんだねえ。

2008-04-07

[] 美しい設計 vs 手早い実装  美しい設計 vs 手早い実装 - バリケンのRuby日記 を含むブックマーク はてなブックマーク -  美しい設計 vs 手早い実装 - バリケンのRuby日記  美しい設計 vs 手早い実装 - バリケンのRuby日記 のブックマークコメント

artonさんのブログのエントリ経由。

単純さ、理解のしやすさという点でも、テーブルの結合操作というのは、結構嫌われるのですよ。データベースの 正規化 vs 非正規化 というのは、オブジェクト指向でいう、小クラス主義 vs 大クラス主義 に通じるものがあるんじゃないですかね。

ronSpace: データベース正規化・非正規化

うーん、分かるような気がするよ。データベースの設計もクラスの設計も、ちゃんとやったほうが(正規化・小クラス主義のほうが)美しいけど、パパッと何か作りたいときにはちょっと複雑だよね。Railsで最初にデータベースの設計をきっちりやってしまうとScaffoldのスクリプト自動生成の恩恵が受けにくい、とか。

ちょっとこのあいだの「硬いプログラミング言語、柔らかいプログラミング言語」の話にも通じるものがあるけど、どちらが絶対的に正しい、と言うわけではないような気がするよ。

トラックバック - http://rubyist.g.hatena.ne.jp/muscovyduck/20080407

2008-04-02

[] 硬いプログラミング言語、柔らかいプログラミング言語  硬いプログラミング言語、柔らかいプログラミング言語 - バリケンのRuby日記 を含むブックマーク はてなブックマーク -  硬いプログラミング言語、柔らかいプログラミング言語 - バリケンのRuby日記  硬いプログラミング言語、柔らかいプログラミング言語 - バリケンのRuby日記 のブックマークコメント

Yuguiさんのブログのエントリを見て思い出したけど、

Rubyの柔軟性は魅力だけど、でもあとほんの少しだけ硬いRubyが欲しい。

Project Rottenmeier

以前Haskellを勉強してみて、そしていまLispを勉強してみて、Haskellは「硬いプログラミング言語」、Lispは「柔らかいプログラミング言語」だなあとあらためて感じたよ。「関数型言語」とひとくくりにはできないくらい、LispHaskellは似ていないと感じているよ。

そして「硬い」言語は「すでに何を作るかわかっている時に」、「柔らかい」言語は「まだ何を作るか固まっていなくて試行錯誤する時に」、向いているんじゃないかな。

tanabeさんのブログのエントリもちょっと関連で、

What(何を作るかっていうゴール) が決まっているかどうかに依存するってことだよね。つまり、naoya さんが言う「新しい機能を作っているときや、新しいサービスを作っているとき」は設計でも実装でもなく、本質的に企画の状態だから TDD とか関係ないと。たまたまコードで表現できる人だから企画をコードで検証している(プロトタイプ作りながら取捨選択してサービスや機能をデザインしている)だけなんでしょう。

満足せる豚。眠たげなポチ。:TDD は企画には使うなってことでいい?

TDD(テスト駆動開発)やBDD(振る舞い駆動開発)というのは、「柔らかい」言語を「硬く」する、というのも目的のひとつなのかも。

あと、関連して思い出したessaさんのブログのエントリ。

Rubyというプログラミング言語は、楽しいことを仕事にすること、あるいは仕事を楽しむことを要求する。それができないとうまくプログラムができないようになっている。開発者のまつもと氏は、何事にもすごく柔軟な発想をしバランス感覚に優れている人だが、「Rubyはプログラミングを楽しくする言語」ということだけには、かなり頑固であり意固地である。 Rubyは過去の言語の「いいとこどり」をした寄せ集めの言語だが、この点だけはユニークであり一貫している。

楽しさを最大化するには、自由が必要である。 Rubyは他の言語に比べて、プログラマに大きな自由を許している。「オブジェクト指向」という思想をそのために使っている。そして、自由が混沌にならないように、「自治」のための仕組を用意している。自分で自分を律していけば、どれだけ仕事が大きくなっても仕事は崩壊しない。たくさんの人がネットを通して共同作業しても問題ない。ただし、自治でなく他律的なコントロールを求めた瞬間に、全ての自由度が反逆してコードは滅茶苦茶になってしまう。

Java はこのようの観点で見ると、Rubyの対極にある言語だ。 Javaはプログラマ性悪説を取っている。誰かの仕事を監視するために、これほど洗練されたシステムはない。「監視」するということは期待すべき仕事の「成果」について、何かを知っていなくてはいけない。ソフトの世界で「成果」を全部予見できたら、仕事が終わっているということだ。最終的な「成果」の本質をうまく取り出さないと「監視」はできない。 Javaは「オブジェクト指向」をこのような「監視」のシステムとして活用している。

同じ「クラス」という言語の概念を、 Javaはひとを縛るために使い、 Rubyはひとのいましめを解くために使っている。どちらも過去の伝統を正統的に引きついでいる言語だが、 Javaではプログラマーが迷子にならないように伝統を活用し、 Rubyではプログラマーが冒険に出るために過去の知恵を集積している。

アンカテ (Uncategorizable Blog) - Java はプログラマ性悪説

硬いプログラミング言語と柔らかいプログラミング言語、やっぱりどちらも必要なのかも。

トラックバック - http://rubyist.g.hatena.ne.jp/muscovyduck/20080402

2008-04-01

[] nil  nil - バリケンのRuby日記 を含むブックマーク はてなブックマーク -  nil - バリケンのRuby日記  nil - バリケンのRuby日記 のブックマークコメント

Rubyist Magazine 0023 号が出たよ!

今回のRubyist Hotlinksは原信一郎さんだったけど、ちょっと興味深いやりとりがあったよ。

原 何でだったかな。特別扱いすべきものは、きちんと特別扱いしようみたいな方式です。Ruby でいうと、nil を普通のオブジェクト扱いするのに、僕は反対なんですよ。

all おおー。

原 ハッシュで、値として nil を与えると要素を delete するっていう機能が昔はあったんですけど。それは AWK 譲りかな。

ささだ JavaScript でいう undefined みたいなものですよね。

原 そうそう。nil は特別だから、そういうことが起こっても良いと。nil を代入するんじゃなくて、nil が来たから、全然違う動作になってしまう。そういうことがあるべきだと言うのが、僕の主張です。何か特別なものがあっても良いという。すべては Object だから平等に扱うべし、みたいな考え方は、良くない。なぜ良くないかと言うと、特別なものを内部に取り込んでしまうと、新たにまた別に特別なものがどうしても必要とされてしまうのではないかと。

ささだ 今、無いは無いでやってるけど、それは無理をしているはずだ?

原 そうです。

ささだ ま、deletedelete というメソッドがあるしという。

arton でも特別なものを取り込むと、もっと特別なものが新たに出てくるから、発展するよって話じゃないんですか?

原 いや、発展しないので、結局元に戻ってしまう。

ささだ 発散しちゃうとかそういう。

arton じゃ、特別なものは取り込まないほうが良いと言うわけですか。

原 そうです。特別なものは特別なままにしておく。

arton ああ、そうかそうか。

原 特別扱いすべきものを……。

arton 無理に取り込むって言うのは、意味が無いと。

ささだ nil を変数に代入したら、それは変数の消滅だ、とか?

原 そうそう。そういうことの方が良い。

Rubyist Magazine - Rubyist Hotlinks 【第 21 回】 原信一郎さん

Rubyに限らず各プログラム言語でnilの扱いがまちまちなのは、やっぱりどこか根源的な問題があるのかも。

トラックバック - http://rubyist.g.hatena.ne.jp/muscovyduck/20080401