カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09Mikiya Okuno
この記事はTDD Advent Calendar jp: 2012 : ATND の6日目です。 前日(5日目)は @a_suenami さんの 受託開発でTDDを導入するということ でした。 デシジョンテーブルを使ってテストしたい! 仙台で行われている、仙台ソフトウェアテスト勉強会とデシジョンテーブルとSpockで試すTDD(ネタ) - pocketberserkerの爆走にインスパイアされ、テスト技法としてデシジョンテーブルを書いた後に、具体的にどのようにテストの自動化を行うか考えてみました。 今回は(も?)FizzBuzzをお題としたいと思います。 デシジョンテーブルとは? デシジョン・テーブルを活用するを参照してください。以下引用します。 デシジョン・テーブル(ディシジョン・テーブル)は decision table、 つまりそのまま訳せば「決定表」です。 様々な事情・条件を考慮し
このエントリは、TDD Advent Calendar jp: 2012の5日目の参加エントリです。 前日は、@irofさんの「思い通りに動くコードを書きたい」でした。 このエントリでは、受託開発においてTDDを導入することについて考察していきたいと思います。 自社サービスとして継続的に機能改修をしていくのに対して、明確な納期がある受託開発ではシステムの品質を求められるタイミングも、その内容も異なるため、TDDを実践するにしても気をつけないといけないことがあります。 そんな、僕が最近考えていること、気をつけてること・今後気をつけようと思っていることについて書いていこうと思います。 一般的なTDDのメリット まずは受託開発の話に入る前に、一般的なTDDのメリットについておさらいしたいと思います。 TDDとは分析・設計手法であり、プロダクトコードを書く前にレッドになるテストコードを書こうとする
2012年のTDD Advent Calendar、4日目でございます。 TDD Advent Calendar jp: 2012 : ATND 3日目 @grimroseさん open build/reports/life/index.html: スタッフになってみませんか? #TddAdventJp 5日目 @a_suenamiさん 受託開発でTDDを導入するということ #TddAdventJp - assertInstanceOf('Engineer', $a_suenami) 自分にとってのTDDを考える 「TDDとは?」なんて掲げたところで、万人に通じる明確な答えを私は持っていません。原典はありますが、相応に進化も派生もしておりますので、固執する必要はないと思います。その上であえて「私にとってのTDD」を挙げるなら、以下の二点になります。 思い通りに動くコードを書く コードの成長
現在、アジャイルサムライ横浜道場の門下生として、勉強している会社員です。 横浜道場での参加レポートはこちらです。 今回は、TDDBC横浜 2nd seasonのスタッフとして参加したことをもとに、 スタッフになってみてはいかがですかというお誘いの内容です。 なぜ、ただの門下生がTDDBC横浜のスタッフとして参加したのかは、 その回のレポート(->こちら)を見ていただくとして。 レポートにはスタッフとして参加するメリットを書いたので、 ここでは体験から思いつきそうな不安や疑問について書いてみます。 スタッフと聞いて、「言語を使いこなしていないし…」と尻込みするかもしれませんが、 そんなことはありません。 確かに、ある程度言語を使える必要はありますが、TDDBCの場合予めお題が提供されていることがほとんどです。 ということは、前もって実践できます。 また、課題も過去の課題を利用する場合も多いの
2012年12月02日00:00 カテゴリAdventCalendar TDDで思考を整理してみる #TddAdventJp この記事はTDD Advent Calendar jp 2012( http://atnd.org/events/33846 )の記事です。 TDDでテストを書くときテストファーストで書きますよね。 テストファーストで書くとしたらテストに何を書くのでしょう。 私は「プログラムにさせたいこと、期待すること」を書きます。 プログラムを書くときに、手元にある紙にタスクを書くように、テストコードに「プログラムにさせたいこと、期待すること」を書きます。 そうすると、何をテストに書くか、このプログラムの挙動はなにか、ということを考えます。 すると私はこのプログラム、このクラス、このメソッドに何をさせたかったのか、というのが整理されます。 また、「あれ、このプログラム、振舞が似て
TDD Advent Calendar jp: 2012 の1日目です。 初日ということで、TDDをとりまく環境について浅く狭く紹介したいと思います。 TDD(Test Driven Development=テスト駆動開発)とは何か? 普通の開発だと 実装して 全部終わったらユニットテスト TDDだと ユニットテスト 実装 リファクタリング(実装の粒度によってはあったりなかったり) 1に戻る 普通は一通り実装が終わってからテストを書くと思いますが*1、先にテストを書くこと(テストファースト)で全体的にメンテしやすいコードにできます。 詳しくは wikipedia:テスト駆動開発 参照。 TDDをすることにより何が嬉しいか 最初からテスト有りきで実装をするため、テストが網羅されている 後からテストを書く場合テストすることを前提とされていないことが多いため、実はこっちの方が難しいと思います あ
去る8月にアメリカ・テキサス州ダラスで開催された Agile 2012 にて James Grenning さんにインタビューを実施させていただきました。James さんは、組み込みソフトウェア開発におけるアジャイル開発のコーチ・トレーナー・コンサルタント、『Test Driven Development for Embedded C』[1] の著者、アジャイルソフトウェア開発宣言の著者17名の1人、そしてアジャイルな見積り手法「プランニングポーカー」[2] の考案者でもあります。 インタビューでは、日本の「 Test Driven Development for Embedded C読書会 」参加メンバーから挙がった質問について順次尋ねる形で進めました。 2012 年 10 月号の前編に続く後編の本記事では以下の話題についてお伝えします。 ・ モデリングやアーキテクチャ設計とTDDの関係
去る8月にアメリカ・テキサス州ダラスで開催された Agile 2012 にて James Grenning さんにインタビューを実施させていただきました。James さんは、組み込みソフトウェア開発におけるアジャイル開発のコーチ・トレーナー・コンサルタント、『Test Driven Development for Embedded C』[1] の著者、アジャイルソフトウェア開発宣言の著者17名の1人、そしてアジャイルな見積り手法「プランニングポーカー」[2] の考案者でもあります。 インタビューでは、日本の「 Test Driven Development for Embedded C読書会 」参加メンバーから挙がった以下の話題についての質問を順次尋ねる形で進めました。 ・ 組み込みソフトウェアに対するアジャイル開発やTDDの導入 ・ モデリングやアーキテクチャ設計と TDD の関係 ・
What is Better Specs Better Specs is a collection of best practices developers learned while testing apps that you can use to improve your coding skills, or simply for inspiration. Better Specs came to life at Lelylan (open source IoT cloud platform) and checking out its test suite may be of inspiration. Better Specs focus on Rails testing, but our goal is to create testing guidelines covering mos
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
デブサミ関西2012での講演内容まとめ はじめに 今月、GOOS日本語版が発売されました。 実践テスト駆動開発 (Object Oriented SELECTION) 作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘出版社/メーカー: 翔泳社発売日: 2012/09/14メディア: 大型本購入: 4人 クリック: 262回この商品を含むブログ (31件) を見る継続的デリバリーに続き、高木さんと一緒にお仕事をするのはこれで二冊目です。今回も多くの人に助けられて、目標としていたデブサミ関西での出版にこぎつけることができました。関係者の皆さま、どうもありがとうございました。 講演では触れませんでしたが、ここで「実践テスト駆動開発」というタイトルの由来について少し書いておきます。原書のタイトルはご存じの通り、"Growing Object-Oriented Softwa
4. 自己紹介 Facebook : Atsushi Mizoue Twitter : asion_m ・Vimが大好きで社内で 布教&プラグイン作成なんかやってます ・JavaScriptも大好きで最近仕事では ほとんどJSしか書いてません。 ・麦酒が血液です。
でもそんなのどうでもいいから最終的には皆自分のTDDを持てばいいのではと思っている 2012-08-30 12:27:33 via web あなたがTDDだとおもうものがTDDです。 ただしたにんのどういをえられるとはかぎりません。 2012-08-30 12:30:20 via Twitter for iPhone ということで、TDDを定義します。 はじめに TDDを定義し、それの基礎を明らかにし、リファレンスモデルを明にする。 そして、他の例も紹介してみます。 TDDとは何であるか TDDとはソフトウェア開発者向けフレームワークです。 RED -> GREEN -> REFACTOR のスパイラルモデルが根幹にあります。 RED, GREEN, REFACTOR は開発者のアクティビティになります。 僕の理解ではプロセスの部分集合がフレームワークであるから、プロセスと呼ぶ事もできるけ
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい!どの口がアジャイル出来るって言ってるねん!」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを10年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか?」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く