Update: We’re roughly 72 hours into our latest Bug Battle, which is comparing and evaluating the top TV networks: ABC, CBS, NBC, and FOX.

With just under four days remaining in the week long competition, we’ve already had more than 400 testers participate and 500+ bugs reported. This is shaping up to be the most exciting Bug Battle ever, both in terms of the quantity of bugs submitted and the quality of the reports themselves.

Remember, the Bug Battle ends Friday, February 12th at noon ET, and there is nearly $4,000 in prize money at stake. To join or catch up on Bug Battle discussions, be sure to check out our testers-only forums.

Rating: 5.0/5 (1 vote cast)

Nexus OSS Core has more than 120 REST Resources published. And that number is just increasing with new Nexus Plugins. Not to mention Nexus Pro that comes with even more plugins and more REST resources.    Everything you do in Nexus, whether you use the Maven Nexus plugin or the Nexus UI, is interacting with a REST service that is available to you if you want to write your own customizations and scripts.   It has been this way since we started the project in 2007.  In this post, I’m going to discuss how this came to be, how Nexus was developed with REST in mind from the beginning.

Nexus: A Core of REST Services

When we started the Nexus project, I called it a “blind” application.  A “blind” webapp is one with no UI technology whatsoever built-in.   All it publishes is a few static files, and a REST API.   All of the UI that you see in Nexus is Javascript.   Your browser executes Javascript which, in turn, interacts with a set of services.   The only presentation technology on the server side is a trivial Velocity template used to render the initial “shell” of the page.

The server-side application you call Nexus, doesn’t generate the UI, that is all Javascript.   It is a completely separate and standalone application, that runs in your browser! A self contained JavaScript application (powered by ExtJS), that communicates with Nexus server, using REST calls only.  This has one very important consequence: whatever Nexus functionality you are able to reach using the Nexus User Interface (and I do mean all), you can do with a plain REST client.     If you want to automate a task, you can use a tool like curl, or some Ruby script, or any HTTP capable client.   You can even start to implement your own custom interface if you would like a completely customized UI.

As I said, it was like this since day one. But, we always had one major issue that prevented wider acceptance of Nexus’ REST API: we had no up-to-date documentation for it.    It wasn’t a priority, we spent much of our time trying to integrate the only existing REST framework (restlet.org) with Plexus, and since we were moving so quickly to implement new features, we didn’t think it made sense to stop and document an ever-changing interface.  We did maintain a wiki page which described the REST services from the beginning of the project, it always provided stale information given our aggressive development pace.

REST Documentation: Using Enunciate

I’ve been looking at the Enunciate project for some time, and it appears to be the solution to our REST document issues.  Enunciate is a cool project hosted on Codehaus, with a bold promise:

Enunciate is designed to make your life easier. Enunciate deals with your deployment difficulties, documentation, and client-side code. By using Enunciate to publish your service interfaces, not only will you have all three Web service interfaces (SOAP, REST, and AMF), but you’ll also have full up-to-date documentation generated, strongly typed ActionScript code that you can use to invoke your remote services from your Flex code, and rich client-side libraries that can be used to access your Web services from a variety of platforms (including Mac/iPhone).

Our initial plans are to use Enunciate in a “lite” mode to generate documentation (and potentially client side code) for our current REST API. Later, we plan to integrate it more closely into new Nexus “Remoting API” implementation, and it will be the backbone of our REST services when we will implement version 2.0 of our API.

Here is just a taste of what is to come.  We’ve used Enunciate to generate documentation for our REST services, and the work is proceeding very quickly.   Here is a snapshot of the documentation we will be releasing soon.

Remaining Problems to Solve

When our REST API was concieved in Q4 of 2007 we didn’t have the rich array of options that we have today.   One major REST library was available, and that was Restlet.  JSR311 wasn’t around back then, so we were forced to code directly to the Restlet API.  Back in 2007, it was very cool to create Plexus components that were then automatically published as REST Resources in Nexus. But today, the same thing looks very cumbersome and is not what one would call a “state of the art”. Back then, we had these goals in mind:

• have complete REST API published on Nexus
• have a decoupled UI application
• provide XML/JSON serialized transport to REST Resource without any effort, with proper content negotiation (XML was kept as “Plan B”)
• make our REST Resources as Plexus components (to enjoy all the benefits of IoC, and later pluggability)

While we fulfilled much of these goals above, we did that at a high cost.  For a Nexus core developer (or Nexus plugin developer), it is very cumbersome to create a new REST Resource using our classes, compared to what REST libraries are available today. Current state-of-the-art REST libraries make our initial implementation seem somewhat naive (hence the need to move toward new libraries like Enunciate). Our 1st and biggest mistake was a very deep class hierarchy in our current API.  While all the “defaults” are properly configured, it is often difficult to create a non-trivial Resource in the current API if you are not intimately familiar with the system.

Also, in the initial design, we use XStream with a custom driver to produce JSON. Back then, it was a real pain to produce proper JSON out of Java.   Today, we have libraries like Jackson.   In the next interation of refactoring, you’ll see update the infrastructure used to produce our REST services to bring it up to speed with what is available today.

The Benefits of “enunciating” a REST API

At first, we will use Enunciate with Nexus during build time only, to generate HTML documentation of our REST API. This documentation will be available publicly, but will also be bundled with every Nexus instance!   Our work to modify our own REST infrastructure is going to require some “invasive” work, but I have to emphasize that Enunciate is not invasive if you use it on a modern JSR311 based REST applications. Enunciate is invasive for us only, since we are about to use it on a home grown, non-JSR311 REST application.

Enunciate gathers and builds your services model using your sources and all the metadata it finds (Java5 annotations, Javadoc).  To “enunciate” the Nexus REST API, we had to add JSR311 annotations to our existing REST Resources.  There was one more problem to solve: our method signatures are more “servlet like”, and they didn’t fit the model of a JSR311 REST Application. While a JSR311 application method signature completely describes the method expectations about payload, parameters, and response type, our methods – whether GET, PUT, POST or DELETE – have almost same signature: RestRequest, RestResponse, Variant. Hence, we had to add more metainformation describing what a method does: what it expects as input, if any, and what it sends out as response.

Luckily, it turned out that this was the only piece missing, and Enunciate was happy to generate documentation for us. Ryan added the new annotation that describes the “alternate REST Signature” of the method, and Enunciate got all the information it needed to generate documentation for us.

Another painful step yet to be completed is “freeing” our REST DTOs from Modello. Initially, we knew we wanted to version the DTOs used in REST. Hence, we used Modello to generate the DTOs. Later, problems with Modello and Restlet forced us to always use version 1.0 of our REST DTOs. Since Enunciate requires that DTOs have JAXB2 annotations, we decided to store our DTOs as code and ditch Modello in our builds.

All this looks like a lot of work, but it is actually pretty straightforward.   While this might seem dull to someone not developing Nexus, this work is going to bring real value once it is completed.    In addition to solving our documentation problems, Enunciate is going to open up a world of possibilities once we migrate our REST services over to the framework.

For more information about Enunciate, the Enunciate Wiki contains a nice example of how to use Enunciate in case like ours is, without JAX-RS. Example is shown here.  Examples of Enunciate generated documentation can be seen on it’s site. There is a great walk-through, with static examples.

Expect More Changes in the Next Few Months

As Nexus graduated from alphas, betas and now is at a 1.5.0 version, we realize we have to change gears to keep up. Enunciate is the 1st “newcomer” technology to Nexus stack.  There will be more to come.   Think of this as the Nexus 100,000 mile checkup.  We’re taking a look at the stack and taking this as an opportunity to upgrade where necessary.

One last note, this post is not about any deficiencies in Restlet.  Restlet is a great framework, and it served us well.  We – the Nexus Project team – are very thankful to Restlet.org project with all the help we got from them and for the great library they made.

 

Security testing is always very thankful, many defects, many examples for the trainer of a course. Sir Wilfred Grenfell once said: “Real joy comes not from ease or riches or from the praise of men, but from doing something worthwhile.” He mentioned this quote while he was helping others with medical support. But this quotation is also [...]

http://citconf.com/raleigh-durham2010

I wanted to let everyone know about CITCON North America in Raleigh Durham on April 16 & 17 because I co-chair the conference and the more of you that come, the better the conference becomes. This is the 5th year for the conference. We started the conference back when I was at ThoughtWorks doing CruiseControl work and JTF was at Agitar. It’s great to see new and old faces alike each year. Maceij from Urbancode described it as “an annual reunion of sorts”.

I love the open spaces format, largely because I have no idea what I will learn until I get there. I learn whatever everyone else is interested in. That’s an amazing way to take in new information. It’s humbling. In fact it reminds me of one of the first concepts I had to accept when I studying the philosophy of Socrates in university, “Before we can learn anything, we must first admit we know nothing.”

Can’t make it to CITCON RD? Then make it to one of the other ones – Wellington, NZ – Prague, CZ – Singapore.

CITCON, the Continuous Integration and Testing Conference, is an open spaces conference in its 5th year. The topics aren’t decided until the first night of the conference, but past events have proven extraordinarily useful to anyone interested in Continuous Integration and the type of testing that goes with it. Developer-testers, tester-developers, tool creators, and Agile advocates have all gained a lot from attending.

The conference is free to attend! You have to pay $20 to register, but you get that back when you attend the conference. (We are using long time conference supporter Obtiva’s EventWax for registrations. Just follow the registration link below.)

This year, the North American event will be in Raleigh-Durham at the Sheraton Chapel Hill Hotel. Registration is open, but limited to the first 150 registrants. Sign up now to reserve your spot at this innovative, exciting, education, fun event.
http://citconf.com/raleigh-durham2010/register.php

The conference operates as a non-profit, so our advertising budget is basically zero. We can use your help to get the word out. If you know someone that might be interested, please pass this announcement along to them.

Also, if your company or a company you know would be interested in sponsoring CITCON, there are a wide range of sponsorship options.
http://citconf.com/raleigh-durham2010/sponsor.php

If you have any questions, please don’t hesitate to contact me.

Alex of TestLab² just published their review of our test management software TestRail. As TestLab² is a provider of software testing services, we were especially curious to find out how TestRail performed in an environment with regularly changing clients, requirements and test projects:

The system proved to be almost perfect for us, both for its’ features and everyday usability. We’re involved in outsourced testing and run lots of small projects, and because of that the vendors’ license policy really fits us: the limit is applied to active system users only, so we deactivate client accounts at the end of the project.

Not bad for our initial release, thanks Alex! You can read the full review on TestLab’s website or you can check out the original review in Russian on habrahabr.ru (a popular Russian IT site, I was told).

TestRail review by TestLab² »

Here’s the video from my talk on Behaviour Driven Development and Acceptance Testing with Cucumber last week. In this talk, I go over the basics of Cucumber scenario structure and integration and show examples of using it with Ruby, .NET and Java applications. (scroll down to see the slides and links from the presentation) If you’re interested Cucumber or Behaviour-Driven development, also check out my new Introduction to BDD and Hands-on BDD with Cucumber workshops.

Finally, here are the links I mentioned during the talk.

• Main Cucumber web site
• Richard Lawrence’s blog (.NET Cuke4Nuke integration)
• Cuke4Duke (Java integration)
• Visual Studio plugin for Cuke4Nuke
• My BDD in .NET with Cucumber article series: part 1, part 2, part 3
• Introduction to BDD and BDD with Cucumber workshops

I met Piotr while working together on the portal project. We finished the same university, though I do not recall meeting on this occasion. Piotr is now Adobe platform evangelist, leads riaspace.net blog. I lead this blog in which I broach topics related to RIA quality assurance and testing, that are very good circumstances to [...] Related posts:

1. FlexMonkey 1.0 – Complete Testing Solution ?
2. Three fresh links – Free Flex Automation Tools
3. FlexMonkey – Flex Test Automation Tool Review

Gojko Adzic held a super introduction to the Cucumber testing tool the other night at SkillsMatter. Below are some notes from the session. We’re considering taking up Cucumber in a couple of ways, including using it as part of our evaluation of new folks who want to join us as testing experts. (We want to know how good a candidate is likely to be at writing automated tests, and even if you have never done test automation, you should be able to write a Cucumber test as it’s just plain English. Or Welsh.)

The Gherkin building in London - thanks to Rudolf Schuba

When it first appeared, it seemed the main advantage of Cucumber was that you could use tables in addition to RSpec given/when/then, which didn’t seem that cool at first. But as Gojko’s worked on it, he’s found that it’s great for staying out of your way as you build your tests:

• Generates code for you
• Supports lists and tabular data
• Tagging for types of tests
• JUnit XML output, so easy to integrate with CI tools and friendly to non-Ruby languages

In fact it integrates with almost anything! Gojko showed a slide with over twenty different tools including Watir, Selenium, and many more.

The basic structure of a Cucumber test is plain text, like this:

Feature: Hello World
In order to ensure that my installation works
As a developer
I want to run a quick Cucumber test

Scenario: Hello World
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World.

Cucumber forces you to use the good Given/When/Then structure that keeps a clear distinction among components:

1. Your scenario is readable by humans (see above) and is scripted by…
2. …the step definitions, which are in Ruby (or your favourite alternative language) and can be reused to test many…
3. …domain classes, which do the actual work.

Your step definitions can be refactored along with the domain classes to help insulate the tests against code changes. Another way to say this is that you get to separate your high-level activities (the scenario) from your implementation of those activities (the step definitions).

You can write your scenario first with no step definitions and run Cucumber with no errors! Instead it will tell you that your tests are undefined and suggest how to start creating the appropriate step definitions. This makes real behaviour-driven development possible - write the scenario, then the step definitions, then finally get to your domain objects.

Cucumber will give you various output formats so you can see the red/green loveliness in PDF, XML, HTML, and more. It lets you use your favourite language including Java, Ruby, C#, and even LOLCODE!

You can avoid wordy repetition of the same scenario again and again in some clever ways, including scenario outlines (which let you use a compact set of rows to show a group of scenarios using a common format), lists of objects (which specify multiple values per Given/When/Then steps), and common setup (using a “Background” keyword).

Some limitations:

• Console only. But there are plenty of ways to run it in a GUI.
• No IDE support (yet). Apparently there is a VisualStudio plugin. Can Eclipse be far behind?
• No way to add images or other documentation to your test, as you can in Fit and Fitnesse.

You can get long-term maintenance problems if you don’t keep the semantics straight - your scenarios tell you *what* is being tested, not *how* it is done. Antony Marcano points out that you have to watch out for step definitions that drift from their titles - don’t let your “send message” step get defined to log or write to the database.

Business management should adopt Agile developmentPublic and private sector organisations should adopt many of the newer techniques that are used to implement software today to manage the business in general, according to a new report by IT services company, Sogeti Ireland.
Read the report:
http://www.sogeti.ie/en/News--Events/Press-Release/Sogeti-Report-Urges-Change-in-Management-Practice/

There’s a new book in Martin Fowler’s Signature Series: “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation” [you heard that here first]. It couldn’t be written by a nicer couple of guys: Jez Humble and David Farley. Both authors have been scribing away on this book for years.

The book covers the full spectrum of topics – I’ve had access to the sources for a long time, and every time I look at it I’m amazed at the range. There’s a Safari Rough Cut preview available via the book’s web site (see below).

Here’s the low-down:

The primary aim of the book is to improve collaboration among the practitioners who are responsible for delivering software. By following the principles and practices we describe, developers, testers, team leads, and operations personnel can deliver software through a reliable, predictable, visible, largely automated process – known as the deployment pipeline – with well-understood, quantifiable risk. Better yet, the quality of the software being delivered will be improved while reducing the time to get changes live. Traditional topics such as configuration management, version control, release planning, compliance, and continuous integration are covered in depth. The authors also describe proven techniques for less traditional topics such as automated acceptance testing, dependency management, and the creation and management of testing and production environments. The book will help you deliver valuable, working software to users — rapidly and iteratively.

Continuous Delivery

image via DaveFeyram

Share with the group:

Related posts:

1. the industries first and only open-source continuous integration solution from http://www.coveros.com/research/research_stack.php: SecureCI™ is the industries first and only...
2. Continuous Interviews: Jez Humble, Part II This is part two of the interview with Jez Humble...
3. Continuous Integration and Release wisdom Can’t recommend these enough. Item one: this book. Release...

Related posts brought to you by Yet Another Related Posts Plugin.

This video was used as a demonstration reel at January’s Jfokus 2010 in Stockholm, Sweden. It provides a useful walk through of the major features of Nexus Security, including user roles, groups, and privileges. If you are new to Nexus, or if you are evaluating the tool, this five minute video gives you an overview of the UI used to manage Nexus Open Source security.

Highlights of this demonstration of Nexus Security:

Time (M:SS) Note 0:20 Logging into Nexus. 0:29 Listing and managing Nexus Users 0:38 Adding a Nexus User 1:00 Assigning User Roles 1:18 Browsing a User’s Role Tree 1:40 Tracing a Privilege to a Role 2:04 Listing Different Classes of Users 2:26 Managing Nexus Roles 2:54 Creating a Custom Nexus Role 3:52 Managing Nexus Privileges 4:26 Creating a Custom Privilege Set  

For the last couple of months the SoftwareTestingClub has been working on its magazine and now it’s out!!!
You can download it here:

What we like most about the magazine is that it’s fresh, cool and different.  Starting from the large number of new names who published their articles and all the way to the fun stuff such as the tester cartoons by Andy Glover, the blogs and even the conversations that are included inside inside.

A lot of people worked hard to make it happen, from the authors who submitted the articles and the rest of the pieces, and all the way to Rosie and Rob who literally spent days and nights to get it published.

THANKS, YOU DID A GREAT JOB!

Now I can’t wait to see what will come out in the next edition…

• Tweet This!
• Share this on del.icio.us
• Digg this!
• Share this on Reddit
• Blog this on Blogger
• Stumble upon something good? Share it on StumbleUpon
• Post this to MySpace
• Subscribe to the comments for this post?
• Share this on Technorati
• Add this to Google Bookmarks
• Share this on Linkedin
• Add to a lense on Squidoo
• Share this on Tumblr
• Submit tip to N4G
• Submit this to Script & Style
• Share this on Blinklist
• Post this on Diigo
• Buzz up!
• Share this on Mixx
• Submit this to DesignFloat
• Share this on Facebook
• Email this to a friend?
• Suggest this article to ToMuse
• Seed this on Newsvine
• Share this on Devmarks
• Add this to Mister Wong
• Add this to Izeby
• Share this on Tipd
• Share this on PFBuzz
• Share this on FriendFeed
• Mark this on BlogMarks
• Submit this to Twittley
• Share this on Fwisp
• Moo this on DesignMoo!
• Share this on BobrDobr
• Add this to Yandex.Bookmarks
• Add this to Memory.ru
• Add this to 100 bookmarks
• Add this to MyPlace
• Submit this to Hacker News
• Send this page to Print Friendly
• Bump this on DesignBump
• Add this to Ning
• Post this to Identica
• Save this to Xerpi
• Share this on Wikio
• Tip this to TechMeme
• Sphinn this on Sphinn
• Post this to Posterous
• Grind this! on Global Grind
• Ping this on Ping.fm
• Submit this to NUjij
• Submit this to eKudos
• Submit this to Netvouz
• Submit this to Netvibes
• Share this on Fleck
• Share this on Blogosphere News
• Blend this!
• Add this to Wykop!
• Engage with this article!
• Share this on Hyves
• Push this on Pusha
• Bookmarks this on Hatena Bookmarks
• Store this link on MyLinkVault
• Submit this to SlashDot
• Submit this story to Propeller
• Submit this to FAQpal
• Clip this to Evernote
• Submit this to Meneame
• Submit this to Bitacoras
• Submit this link to JumpTags
• Share this on Bebo
• Submit this to Strands
• Promote this on Orkut
• Add this to Stumpedia
• Post this to Current
• Share this on Plurk

On Tuesday, February 9th, I will be leading the jam session for Come Jam With Us, the software developer study group in Ann Arbor. The session will be on ASP.NET MVC, and aims to give attendees enough of an introduction to the product to empower developers to be able to start coding their own ASP.NET MVC 2 projects. Like all of the Come Jam With Us sessions for the winter/spring of 2010, it will be held at the offices of SRT Solutions in Ann Arbor at 5:30p.

Prerequisites

You will need few things for ASP.NET MVC 2 application development and to complete this exercise. Please complete the following prerequisites prior to the session, otherwise you likely will spend the hour downloading and installing rather than coding.

• Install Microsoft Visual Studio 2008 SP1 or Visual Web Developer 2008 Express with SP1
• Install Microsoft SQL Server or SQL Server Express
• Download and install ASP.NET MVC 2 from CodePlex
• Download MvcContrib from CodePlex

Technorati Tags: Ann Arbor,Software,Code Jam,Study Group,ASP.NET MVC,ASP.NET MVC2

Conflict is a natural part of your every day life, whether it is at work or home. A certain amount of conflict is healthy as long as you work out how to resolve it.

Liv Wild and I will look at a number of conversation models we’ve found healthy teams use, in agreeing to agree. We’re holding it at the Thoughtworks UK office from 7pm this Tuesday (9 Feb). More details can be found here.

Coverity recently published an insider's view to building a static analysis tool. It does a great job of explaining the practical issues in building a world-class tool that is depended upon by so many software development organizations in so many different industries.

If you've ever used Coverity, or any other static analysis tool, you will have a more healthy appreciation of how difficult static analysis can be. It just might explain some headscratchers you may be experiencing. Static analysis can never be perfect, but it can be darn good enough to provide significant value in the software development process.

On February 13, 2010 in Microsoft premises in Prague, there will be a series of ongoing short presentations about .NET.

Gil Zilberfeld will lecture online @ 13:30 CET “Designing for testability: The good, the bad and the ugly”

If you design your application for testability, you’ll have a better architecture, components will be decoupled, and the sun will rise every morning. But is testability really the goal? You will want to watch out from taking it too far.
It’s time to talk about what designing for testability really is – the good and the bad. Your architecture and your project can benefit or suffer from the choices you make. In this webinar session, Gil Zilberfeld from Typemock is going to discuss the pros, cons and alternatives.

Gil Zilberfeld has been in software since childhood, starting with Logo turtles. After 15 years in commercial software companies, he has vast experience in development and development practices. Currently Gil is the Technical Evangelist of Typemock, promoting unit testing and some incredibly cool tools.

For the last couple years there has been a growing collection of people rallying around the software craftmanship. From an outside perspective, it appears that they are dipping into the classic apprentice – journeyman – master model for growth (without the inclusion of guilds which is often the point of fear with this model). From its title, Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman would be aimed only a the beginning of the road and only for developers. Both would be wrong. This book is of value to anyone in a knowledge role and at any point in their development.

Dave Hoover and Adewall (Ade) Oshineye have collected together a series of of almost 40 ‘patterns’ that you can use, and likely already are, to assist your growth. Each pattern follows the same structure by defining the context, giving a sample scenario where the pattern might solve a particular type of problem, a solution and action that the reader can take immediately to start implementing the pattern. Because of this structure it is easy to jump at random throughout the book and [start to] digest a pattern in a single (brief) sitting. The real power of the patterns for people starting out is in the Action section I think, though I admit that I have not followed through on most. These are the ‘get off you butt and do something about your growth’ motivators.

Having embarked on my path already I found that I was already implementing a number of these patterns which I think completely validates their inclusion in the book. But it also meant that the Solution section was what got my attention the most with lots of ideas how to refine my implementation of the patterns. Flipping through my copy of Apprenticeship Patterns I can find only 2 or 3 patterns that I did not underline or star or otherwise mark up.

My favourite patterns (both from the book and the real world)?

• Breakable Toys – Experience is built upon failure as much as (if not more than) success
• Find Mentors and Kindred Spirits and Rubbing Elbows – Seek out those who have gone ahead of you and strive to learn from them
• Record What You Learn and Share What You Learn – Start writing. Start writing now!

People who know me likely won’t be that surprised with that list. Your list, almost by definition will be different as you have walked a different (though perhaps similar) road in your journey.

My only knock against the book is likely its price. It is 130 pages and $37.99 CDN. That is steep, though I suppose in-line with current pricing structures since Beautiful Testing is 320 pages for $62.99. To their credit, the patterns could at one point be all found online (minus some polish that comes from the editing process) but I couldn’t find them at time of writing. But a book like this really should be consumed in dead-tree format where you can make notes in the margins. (If someone finds the wiki link again, please post it.) And at the risk of sounding like I’m pimping my book, Amazon has been long running a deal where you can save if you buy Apprenticeship Patterns and Beautiful Testing together. While likely related to release dates and ish similar breadth of content, I’m ridiculously happy to see it.

The Agile community is in the midst of an obsession of Shu Ha Ri, and much to my annoyance I admit that there are different ways that people learn at different stages of their learning. I don’t know if there is going to be ‘Journeyman Patterns’ follow-up, but I hope there is. But even if there is, Apprenticeship Patterns is staying on the bookshelf where it is nice and handy.

Free Isolator 2010 Every Week

 

Welcome to the Easy Unit Testing Family. By now you are probably Following Typemock @ Twitter 

AND only for that you will be included in every Wednesday Drawing from now until the End of February, unless you  already won or will win Before :))).

The rules are very simple:

1. make sure that you are following us on Twitter
2. To finalize your registration please Tweet from your personal twitter account

Just entered to win an Isolator 2010 to enter & keep up with latest unit testing news, follow @typemock & RT

http://bit.ly/7SVQkx

 

That’s it!

You may Email us your contact information to Social@typemock.com

Good Luck!!!!