http://www.rubyist.net/~matz/20070412.html#p01 http://alohakun.blog7.fc2.com/blog-entry-731.html http://www.lingr.com/room/gauche/archives/2007/04/21 http://www.lingr.com/room/gauche/archives/2007/04/22 このへんの界隈の、プログラム実行中に変化していく状態の、オブジェクト指向言語と純粋関数型での書き方の違いの話。 いろいろコメントつけたり返事をもらったりしてたわけだけど、それでもやっぱり僕は「書きやすさ」が最重要な点だと思っている。どういう書きかた、考え方を好むかは「それまで自分が触れていじってきた言語や環境への慣れの影響が大きい」という話もわかるんだけど、それだけでは片付かないものがあるの
タイトルはおおげさすぎ。きっかけは 新しいwhyプロダクト、ShoesはGUIツールキット。 サンプルはこんな感じ。 Shoes.app do button "Press Me" do alert "You pressed me" end end こういうAPIは好みだ。 http://www.rubyist.net/~matz/20070801.html#p02 を見たこと。 「あーinstance_evalはやっぱり便利ですよね」と思ってみてたんだけど*1、この構造って再帰的に使えるよなぁ、と思ったのでコードでメモ。 ポイントは、上のソース中のbuttonというメソッド。buttonメソッドはソースの字面をみると定義なしに突然使われているんだけど、instance_evalの黒魔術を使うとこういうことができる。obj.instance_eval do .. end という構文を使うとブ
加藤さんのきょこコーリングのエントリー「アメリカ人に通じるプレゼンを作るために」で書かれていた 「アメリカにいる上司を説得しなければならないときに、「英語力を上げよう」として英会話に通ったり、ビジネス英文の書き方の本を読むのではなく、MBA関連の本を読むとのこと。」 という箇所を読み、非常に納得できましたので、ちょっと考えてみました。 日本人が作るプレゼン資料が、なかなか海外の人に伝わらないということは、海外とコミュニケーションをなさっている方であれば、経験なさっていることと思います。 欧米社会だけでなく、アジア社会でも結構起こっているように思います。 欧米型のプレゼン資料（又は製品資料やお客様事例等)というと、こんな感じではないでしょうか？ 文章をズラズラ書く。絵はない 我々からすると、当たり障りのない文章。当たり前の結論 でも、何故かこれでちゃんと意思が伝わるし、相手も動く 一方で、日
MacOSXを再インストールする時のメモ。 これさえあればLeopardのインストールも1時間で終わるはず。 Xcode Tools + 10.4 Universal SDK: とりあえず入れとけ。 QuickSilver: http://quicksilver.blacktree.com/ ランチャ これがないと何も起動できない。 iTerm: http://iterm.sourceforge.net/ タブターミナル これがないと、とにかく何もできない。 zsh: http://www.zsh.org/ shell これがないと、イヤ。 - ftp://ftp.demon.nl/pub/mirrors/zsh/zsh.tar.bz2 - ftp://ftp.demon.nl/pub/mirrors/zsh/zsh-4.3.4.tar.bz2 Mac OSX UTF-8関連 $ curl
自分でももやもやしてるのでツッコミ希望。 考えだした元記事 : http://techon.nikkeibp.co.jp/article/TOPCOL/20070806/137518/ TDDを紹介するときに、「TDDではプロダクトコードの前にテストを書く」という紹介のされかたが多いんですが、これはちょっと誤解を招く表現だなぁ、と思います。TDDを達成するための1つの(とても有効な)技法としてテストファーストがあるわけですが、その関係は"=="じゃなくて包含だよなぁ、と思うのです。 TDDは字義通りに解釈してもしなくても、テストが開発を駆動することが重要なわけです。駆動するというのはもちろん先にテストを書けば駆動してるんですけど、それは必要条件じゃない。 別にあとから作っても*1、 自分が作ってるモジュールを使ってみたら、APIが「ねーよwww」くらい使いづらいものであると気づいたり、とか
Java と DI (Dependency Injection) の世界から C++ に戻ってくると気が滅入る. すべてがくっついている. ああ... "Working Effectively With Legacy Code" に従ってバリバリと依存を引き剥がすことになるんだけれど, もうウンザリ. せめて新たに書くコードはレガシー風味とさよならしたい. DI したい. C++ にも少しは DI コンテナの実装がある. Autumn Framework とか. ただリフレクションのない C++ では DI コンテナを使う有難味が薄い. Autumn Framework のチュートリアルを見ると無力感に襲われる. 閉じた型システムの再発明. C++ の限界もあるだろうから, あまり責める気は起きない. COM のような既存のオブジェクトシステムに DI を載せることはできるかもしれない.
Posted by nanki Wed, 15 Aug 2007 09:05:00 GMT XSLで関数型プログラミング <?xml version='1.0' encoding='utf-8'?> <xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xmlns:common='http://exslt.org/common'> <xsl:template match="array"> <xsl:call-template name="sum"> <xsl:with-param name="array" select="."/> </xsl:call-template> </xsl:template> <xsl:template name="sum"> <xsl:param name=
まつもとゆきひろ氏が理事長を務めるRubyの普及推進組織「Rubyアソシエーション」は技術者認定試験を開始する。2007年10月から東京と松江で筆記試験を行う。2008年2月にはインターネットで日本語版と英語版で，世界の技術者を対象にした試験を開始する。認定試験によりRubyの普及拡大などを図る。 試験は伊藤忠テクノソリューションズ「CTC」に委託して行う。CTCは技術者向けにRubyの教育事業などを行っている。 Rubyアソシエーションは「Rubyをエンタープライズ分野で安心して利用できる環境を整備する」ことを目的として2007年7月に設立された。具体的にはRuby公式サイトや日本Rubyの会のWebサイト，メーリング・リストのサーバー運用などのコミュニティ支援，イベント開催および支援，Rubyを用いたシステムインテグレーション事業の支援，Rubyグッズの販売，広報などを行う(関連記事）
http://d.hatena.ne.jp/Rinta/20070814#p1 長いので引用はしないよ。質問は4点あるようで Agileはプロジェクト管理の失敗をケアできるものなの？ 少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？ テストベンチはAgileだけの特徴ではないよね？ 設計書なしで保守をどうするの？ Agileはプロジェクト管理の失敗をケアできるものなの？ 次の質問への答が参考になるはず。失敗とはなにか？も参照のこと。 少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？ ウォーターフォールと同じものをAgile開発に期待するのなら、その通り。少人数でまわせば時間がかかるようになるだけ。 ここでいう「同じもの」というのは 全く使われない要件（フィーチャ） ほとんど使われない要件（フィーチャ） 使わ
大規模Agileの生産性の話を見つけた。QSM社のデータなので間もなく客観的数値が上がってくるであろうが 7チーム100名の並列SCRUM QSM社の生産性データベースの上位5%以内に入るのは確実 この領域に到達するのに２年しかかかってない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
