タグ

ブックマーク / capsctrl.que.jp (5)

  • Martin Fowler's Bliki in Japanese - ThoughtWorksでのRuby

    以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日語訳である。 ThoughtWorksは、2006年から格的なプロジェクトRubyを使い始めた。2008年の終わりまでには、Rubyプロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。

  • Martin Fowler's Bliki in Japanese - CollectionClosureMethod

    http://martinfowler.com/bliki/CollectionClosureMethod.html (detectとinject部分を明確にするよう更新) Smalltalkでプログラミングを始めたときから、コレクションクラスが好きでした。 よく使う強力なオペレーションを簡単に使うことができました。 Javaが登場したとき、このようなメソッドがなくなって物足りないと感じました――Java(およびC#)のコレクションは、Smalltalkのそれと比べて非常に限定されたものでした。 というのも、JavaにはClosureが実装されていなかったからです。 Smalltalkの強力なコレクションのメソッドは、すべてクロージャに依存しています。 近年、私はRubyで頻繁にプログラミングをするようになりました。 Rubyに引き付けられたのは、Rubyには強力なコレクションメソッドがあ

  • Martin Fowler's Bliki in Japanese - ひとつの言語

    http://martinfowler.com/bliki/OneLanguage.html 開発努力において言語は1つだけにすべきか? エンタープライズ・ソフトウェア界の流行はここ10年の間ずっと、ソフトウェア開発努力のための1つの標準言語に集中することだった。 多くの開発組織が、すべての作業をJava(とかC#/VB)でこなそうとしている。 これの理論的根拠は、開発者が1つより多くの言語に熟練するのは困難だということだ。単一の言語にこだわり続ければ学習の負荷は下がる。とりわけ新人を採用するときに効果がある。 まあ真実もちょっとはあるけど、大抵は大外しだ。プログラミング環境ってのは一部は言語だけれど、でも複数の言語やフレームワークについてでもある。大規模フレームワーク、HibernateやStrutsやADOなんかは、単一のホスト言語でプログラミングしていたとしたって、今や1つの言語を学

  • Martin Fowler's Bliki in Japanese - RailsConf2007

    http://www.martinfowler.com/bliki/RailsConf2007.html 2007/5/22 以前ほどカンファレンスに参加することはなくなったが、 その分、好きなカンファレンスに参加する時間ができた。 ずっと前からRubyコミュニティには特別な愛情を捧げている。 というわけで、RailsConf?に一般参加者として参加してきたよ。 Chad FowlerとRich Kilmerによってカンファレンスの紹介が行われた。 Chadとは苗字が一緒だが、彼ほどのウクレレのスキルは私にはない。 若いテクノロジーには新しくて重要な特筆すべき点がいくつもある。 だが、私にとって最も重要なのは、JRubyだ。 現在、JRubyは最終的なRCの段階だ。 Java VM上で動くスクリプティング言語を提供するだけでなく、 Rubyプラットフォームの完全な実装をJVM上で行おうとし

  • Martin Fowler's Bliki in Japanese - 朝会のパターン:立ってるだけじゃないよ

    朝会(デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく

  • 1