RSpec のすごいところ - kなんとかの日記
(注: 以下の内容は、RSpec ユーザの間で広まっていることでもなく、もちろん RSpec 開発チームの公式な見解でもなく、あくまでワシの個人的な見解です。) RSpec のすごいところは、コードに対してではなく仕様に対してテストを書くことを明確にしたことだと思う。何を今さらと言われそうだけど、今さらになってようやく気づいたニワトリ頭ですまんかった。 ワシも最初は、「assert_equal(expected, actual)」のかわりに「actual.should == expected」と書くかっこよさに目を奪われて、テストコードを自然言語に近い形で記述するのが RSpec のすごいところだと勘違いしてたし、それが「TDD (Test Driven Development)」から「BDD (Behaviour Driven Development)」へという新しい潮流だと勘違いしてた
@ITの炎上していたブログ主がクビになってた - kなんとかの日記
昨日紹介した、SQLとオブジェクト指向の話題で炎上していた『ベンチャー社長で技術者で』というブログの主が、なんとクビになってた。 【お知らせ】 ＠IT自分戦略研究所 編集部です。 2010年5月28日、『ベンチャー社長で技術者で』を執筆する生島勘富氏を、エンジニアライフ コラムニストより除名いたしました。 今回の件について、多くの読者から問い合わせをいただきました。今回の処置について、生島氏には了承いただきましたが、「これまで行ってきた議論のまとめはしっかり行いたい」と、最終原稿掲載の依頼を受けました。 編集部で協議した結果、掲載すべきであると判断し、下記に生島氏より受領した最終原稿を掲載します。なお、この内容は＠IT自分戦略研究所の見解・意向を示すものではありません。 生島勘富氏の最終コラム：エンジニアライフ運営日誌：エンジニアライフ アンチのせいでクビか。アンチ大喜びだろうな。 思うに
SQLが苦手なオブジェクト指向屋さん - kなんとかの日記
炎上したのでまとめ (ベンチャー社長で技術者で) なんか炎上してるらしんだけど、なぜ炎上するのかわからない。ごく当たり前のことを言っているようにしか見えないのに、なぜあんなにアンチが湧くのか理解に苦しむ。ちっぽけなプライドの問題？ 2．SQLはオブジェクト指向言語の数十倍の効率 オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十％も変わらない。 SQLとオブジェクト指向言語を比べたら、数百〜数千％の差が付く。 炎上したのでまとめ：ベンチャー社長で技術者で：エンジニアライフ まあ、そうだよね。SQLでできることはSQLでやったほうが高速 (例外もあるだろうけど少数)。 スクリプト言語とJavaとの速度差なんて、下手なSQLひとつで吹っ飛んでしまう。そういうのを経験すると、SQLがいかに重要かが身に染みてわかるし、ほかにも「言語の速度 !=
高速なプログラミング言語が生み出す本当の価値 - kなんとかの日記
なんか、はてなブックマークとか見てると残念なコメントが多いよなー。『こんな比較は意味ない』とか『できることがまったく異なるテンプレートを並べて比較されても』とかいうやつ、何なの？「言語の速度 != アプリの速度」という主張を示したベンチマークなんだから別におかしくないじゃん。主旨がまるで分かってもらえてない。ネットワークやデータベースの処理まで含めて計測したら、「言語の速度 != アプリの速度」という主張がより鮮明になるだけじゃね？ 反論する人があまりに残念な反論しかできないようなので、かわりに自分で「高速な言語を使う理由」を説明する (一人マッチポンプ状態じゃねーか)。 ・ ・ ・ ・ 言語が速いことによる本当の利点は、採用可能なアーキテクチャが広がることだと思う。新しいアーキテクチャを思いついたので採用したいが、スクリプト言語ではどうやっても満足な速度が出せなかったのが、Java
Rails の routes.rb がわかりにくい - kなんとかの日記
Rails の routes.rb と格闘中なんだけど、なんで Rails の routing はこんなにわかりにくいのだろうか。 ## named route は省略 map.with_options(:controller=>'books') do |x| x.connect '/books', :action=>'index', :conditions=>{:method=>:get} x.connect '/books', :action=>'create', :conditions=>{:method=>:post} x.connect '/books/new', :action=>'new', :conditions=>{:method=>:get} x.connect '/books/:title', :action=>'show', :conditions=>{:metho
Enumerable#select と #collect を同時に行いたい - kなんとかの日記
せっかくなので小ネタを。 Python でのリスト内包表記は、for と if を同時に書ける。これはループを1回まわるだけで、選択 (select) と写像 (collect) を一度に行えることを意味する。 >>> L = ['foo', 'bar', 'baz'] >>> [ x.upper() for x in L if x.startswith('ba') ] ['BAR', 'BAZ'] これと同じことを Ruby でやると、Enumerable#collect と #select を使うわけだが、そうするとループを2回まわることになり、アルゴリズム的には動作効率はよくない。 irb> arr = ['foo', 'bar', 'baz'] => ["foo", "bar", "baz"] irb> arr.select {|x| x =~ /\Aba/ }.collect {
YAML 1.2 仕様書リリース - kなんとかの日記
YAML 1.2 の仕様書が正式公開されました。 YAMLメーリングリストに流れたClark C. Evansのメールに、今回の変更点が紹介されてました。それによると、今回の目玉はずばり「JSONの仕様を取り込む」ことです。つまり、YAML1.2からはYAMLはJSONの完全なスーパーセットということになります。 今までもYAMLパーサをJSONパーサのかわりに使うことはできたのですが、実はYAMLとJSONとで細かい差異があったため(特に「:」と「,」の直後の空白の有無)、YAMLパーサがすべてのJSONファイルをパースできたわけではありません。しかし今回の仕様変更で、YAMLパーサはすべてのJSONファイルを正しくパースできるようになりました。 The primary objective of the 1.2 revision of this specification is to b
Re: 大量のハッシュデータを簡潔に作成する - kなんとかの日記
これもどこまでマジなのかよくわからんのだけど…… つ injectとだけ言わせていただく。 jijixi's diary - Re: Python での組み込み型をより自然な名前にする - kwatchの日記 , Re: 大量のハッシュデータを簡潔に作成する - kwatchの日記 inject()があればHash.create_with()はいらないというご指摘をいただきました。 検証してみましょう。 ## Hash.create_with()を使う方法 data = Hash.create_with(:name, :gender, :role) {[ ["Haruhi", 1, "Leader of SOS Brigade"], ["Mikuru", 1, "Time Traveler"], ["Yuki", 1, "Humanoid Interface"], ["Itsuki", 0
大量のハッシュデータを簡潔に作成する - kなんとかの日記
スクリプト言語では Hash や dict のリテラルが用意されているので、書きやすい。しかしテストデータなどで大量の記述が必要になると、さすがにちょっと面倒である。 data = [ {:name=>"Haruhi", :gender=>1, :role=>"Leader of SOS Brigade"}, {:name=>"Mikuru", :gender=>1, :role=>"Time Traveler"}, {:name=>"Yuki", :gender=>1, :role=>"Humanoid Interface"}, {:name=>"Itsuki", :gender=>0, :role=>"ESPer Boy"}, {:name=>"Kyon", :gender=>0, :role=>"Story Teller"}, ] 同じキーが繰り返し出てくるのがいやだよね。これなら
Web アプリのボトルネックはテンプレートシステムにあり - kなんとかの日記
Ruby のネタがないので Python でお茶をにごす。 Python の速度を 5 倍速くするという目標を掲げている unladen-swallow というプロジェクトがあるんだけど (日本語はこちら)、その中に次のような一節があった。 Unladen Swallow's benchmark suite is focused on the hot spots in major Python applications, in particular web applications. The major web applications we have surveyed have indicated that they bottleneck primarily on template systems, and hence our initial benchmark suite focuse
GitHub で gem を自動作成させるときの注意 - kなんとかの日記
GitHub では、gem パッケージを作成してくれる機能がある。 やり方: GitHub のプロジェクト管理ページから「edit」をクリックし、「RubyGem」のチェックボックスにチェックを入れる。 自分のプロジェクト用の *.gemspec ファイルを commit & push する。このとき、バージョン番号をあえて 0.0.0 にしておくことをお勧めする。 *.gemspec ファイルでバージョン番号を更新して commit & push する。← 重要! 成功すると、しばらくしたあとに http://gems.github.com/list.html に Gem 名が現れる。失敗した場合は自分宛にメッセージが届いているはずなので、それを読む。 それ以外にも GitHub での gem 作成はけっこうハマるポイントがある。ローカルでの gem 作成はまったく問題がなくても、Git
本気を出すそうです - kなんとかの日記
NOV1975 あとで本気で書く。 2009/02/09 はてなブックマーク - Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記 今までのは本気じゃなかったそうです。これは期待するしか! IwamotoTakashi 誤読されるって厄介だよなー。いくら説明しても理解してもらえなかったり。この件もどうなることやら。 2009/02/09 はてなブックマーク - Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記 どうなるんでしょうね。ひとまず彼の本気を見せてもらってからにしましょう。 誤読したうえで自説を展開してきた彼ですが、それも本気でなかったのなら仕方ありません。 本気になった彼がどんなことを書いてくれるのか、楽しみですね。 ＃まさかこれだけ宣言しておいて逃げ出すようなまねはしないと思いますが。
Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記
まーた「スーパープログラマー」に反応しちゃってるよこの人。 ようはあなたが望む体制はスーパープログラマーに選ばれないってことじゃないの？ スーパープログラマーは生産性がスーパーなわけではない - novtan別館 文章の意味がわかりません。ワシの頭でもわかるように書いてください。 そもそもの前提として、業界は今現存する(あるいは将来生まれる)スーパープログラマーで全ての需要が満たされるというものが成立しないと、属人性を排除して均質化および全体の質の向上を図るという戦略が間違っているとはいえないから。 なんでそんな前提が必要なの? 単に生産性の高い人の能力を引き出す、というだけの話になんでこんな前提が必要となるわけ? 僕はともかくdankogaiにそれいっちゃいかんだろｗｗｗ Dan氏じゃねーよ、キミのことだよ。「スーパー」とか「天才」とかに過敏に反応しているキミのこと。 それは捉え方が間違
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
