2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと

12月3日 Global Day of Coderetreat in Tokyo(東京都) 2011/12/03 Global Day of Coderetreat in Tokyo #gdcr11 - Togetter (写真：世界中で同時開催されている各地会場の幾つかと、直接映像・音声で交流する一幕。写真右側には東京イベントのファシリ−テータ:原田 騎郎さん。) この日は、『Global Day of Coderetreat in Tokyo』というイベントに参加してきました。 場所はクラスメソッド株式会社＠飯田橋。以前RIA関連の3日連続でセミナーが開催された時に訪れて以来の訪問です。 『CLASSMETHOD 春の集中講座vol.2』に参加してきた - Shinya’s Daily Report 『CLASSMETHOD 春の集中講座vol.3』に参加してきた - Shinya’s

プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほど、

この書籍の元の内容はクリエイティブコモンズのライセンスで公開されている。(*1)(*2) その内容を日本語に翻訳したうえに、有名な日本人プログラマの書き下ろしが10本追加されている。 まさに「プログラマが知るべき107のこと」になっているのだ。 そしてなぜか、通称きのこ本と呼ばれている。 発売前からTwitter上では、この書籍を元ネタにしたパロディが盛り上がっていた。 Togetter – 「プログラマが知るべきじゃない97のこと」 Togetter – 「プログラマの嫁が知るべき97のこと」 Togetter – 「プログラマが体験すべき50の危険なこと」 書籍を読む前からニヤニヤしてしまったわけである。 それぞれの言語には、良い部分も悪い部分もある。 それに加え、特徴となる文化もある。 プログラマにはそれぞれ得意とする言語がある。 一つの言語だけでは視野が狭くなりすぎる。 流行の言語

What's this? Perl基礎文法最速マスター - Perl入門～サンプルコードによるPerl入門～ を発端とした各種プログラミング言語の「基礎文法最速マスター」記事の人気ランキングです． 人気ランキングは，以下の各種 Web サービスの API から得られるカウントの合計を元に作成しています． Twitter Facebook ※API の total_count の値を使用 はてなブックマーク 総記事数は 94，最終更新日は 2013-11-05T00:35:52+09:00 です． ランキング タイトル カウント 合計

UNIXの基本的なコマンドの1つであるdiff。 これに実装されているアルゴリズムは実に興味深い世界が広がっています。 本稿では、筆者が開発した独自ライブラリ「dtl」をもとに「diffのしくみ」を解説します。 はじめに diffは2つのファイルやディレクトリの差分を取るのに使用するプログラムです。 ソフトウェア開発を行っている方であれば、SubversionやGitなどのバージョン管理システムを通して利用していることが多いかと思います。本稿ではそのdiffの動作原理について解説します。 差分の計算の際に重要な3つの要素 差分を計算するというのは次の3つを計算することに帰結します。 編集距離 2つの要素列の違いを数値化したもの LCS（Longest Common Subsequence） 2つの要素列の最長共通部分列 SES（Shortest Edit Script） ある要素列を別の要

どうも、技術部でプログラマをしている鈴木です。シャノンに来てからは主に Shanon Marketing Platform の国際化対応をやっています。 わたくし、いわゆるひとつの vi 使いでして、世の vi 使いの類にもれず、世の中のすべてのアプリケーションの UI が vi ライクになればいいと常日頃思っているクチなのですが、（この記事も、vi で書いてからコピペであります。WYSIWYG なんてクソくらえ！　でありますw）今日は恥ずかしながら、そんなわたくしが普段どんな感じで vi を使っているかをお見せしたいと思います。

iPhone開発で、メモリ管理の基礎を社員に伝えることが増えてきたので、エントリとして書こう。 Objective-C基礎 メモリ管理の前にObjCの基礎として、メソッド呼び出しの話。 クラスのインスタンスaがmethodAをコールするときは、 [a methodA] と書く。このとき、aがnilだったときは、エラーではなく、コールされない。methodAに戻り値があるときは、それは、0やnilやNOが返る。ObjCでは、 void dealloc { if(a!=nil){ [a release]; } [super dealloc]; } は、気持ち悪いので、nilチェックはやめましょう。 なお、ObjCでは、動的にメソッドを差し替えることができ、コールの度にメソッドが存在しているかも確認しています。そのため、LL言語(ライトウェイト言語、スクリプト）のように柔軟な記述が可能です。そし

開発技法、プロセス、プラクティスが期待通りの効果を出す場合には、何らかの前提があることがほとんどだ。 その前提と技法、プロセス、プラクティスをセットにして考えると、さらなる改善や横展開につながると考えている。私の専門分野の1つであるエンピリカルソフトウェア工学では、前提をコンテキストと呼び、その記述とともに結果や結論を述べるよう推奨されている。 コンテキストは、ある結論（たとえばある技法が非常によい効果をもたらした）に対して、その原因、前提を考えることにより明らかになる。「組込みだから」「社内システムだから」「40代男性だから」等、思いつくままに定義すると的外れになることが多い。 具体的なコンテキストを抽出するシステマチックな方法は存在しないが、たとえば、他プロジェクトへの展開や次に活かそうとしたときに、前提がそろっているかどうかを考えると、いくつかが浮かんでくるだろう。 私はコンテキスト

なんかVelocityもJSPもスクリプト言語より遅いという事実は、Java屋さんはあんまり知らなかったみたいだね。しかも、遅い原因の考察が的外ればかりで笑ってしまう。 「Javaの文字列操作は遅いから」とか「UTF-16の変換に時間がかかるから」とか、そんなのまるで関係ないですから。Javaの文字列操作は十分速いし、UTF-16の変換も主要因ではない。 ＃つうかさ、「Javaの文字列操作は遅い」とか、Javaに対して失礼だろ。 VeocityやJSPが遅いのは、単に動的な独自言語を導入したから。はっきりいって、これはアーキテクチャ上の間違った選択。せっかくJavaが静的であるのにその特性を利用せず、わざわざ動的言語を導入しているのだから、何考えてんだろうと思う。いつもJava屋さんが主張しているような、「コンパイル時にエラーを発見できる」「IDEでの補完が効きやすい」「リファクタリングが

本ブログの記事に対して多くの皆さんからいただいた意見を総合すると、技術力のあるトッププログラマーにとって現状の日本のSI業界での仕事というのは、働き甲斐のない、魅力の少ない仕事として認識されているという残念な事実を思い知らされます。 オブジェクト指向の基本すらいまだにきちんと使いこなせない開発の現場 技術について勉強した知識をほとんど活用できないし評価もされない 無駄なドキュメント作成などに対する膨大な単純作業を強いられる いわゆる3K職場と言われるような過酷な労働と低い賃金 20年以上も前の仕事の進め方からあまり進歩が見られない 多重下請け構造によりユーザーに直接価値を提案するような仕事が難しい 多くの業務アプリケーション開発現場における体験を通して、以上のようなことが語られているということを考えれば、「業務アプリケーションのプログラマーは負け組だ」という意見が出てくることも当然のことか

みなさま、新年明けましておめでとうございます。硬派担当のにゃん太郎です（笑）。今年もわたしの考えを述べつつ、みなさまといろいろ意見交換ができると幸いです。本年もよろしくお願いします。 名前だけ見るとふざけているようで、とても硬派ではないのですが、この「にゃん太郎」という名前はわたしの奥さんが実際にわたしを呼ぶ時に使っています。付き合い始めた頃からなので、すでに10年以上になります。長いこと使っているので、時々外出先でも奥さんに「にゃん太郎」って呼ばれます（ぉぃ）。 さて、今年の最初のテーマは「フレームワーク」です。最近のソフトウェア開発にはなくてならないものを通り越して当たり前になっています。フレームワークと呼ばなくても構造的にフレームワークになっているものもけっこうあります。わたし自身はシステム開発においてフレームワークの必要性というか有用性は理解していますし、先ほども書いたとおり、なく