2010 is going to be busy for conference and use group speaking.
I'm excited the following conferences and user groups have invited me to speak in 2010.

Conferences:

	USville (Several US locations)	Click on image for dates near you	NFJS is 10 years old now! I started on the NFJS tour fairly early and it's been absolute fun. The attendees on this tour are smart and the speakers have become close friends. Love the show and glad to be on it again in 2010. My topics include Java, Scala, Groovy, and agile practices.
	Atlanta	March 8-9	Quite a variety of topics and speakers at this event. I will be giving a keynote and will talk about effective Java.
	Bangalore	March 18-19	Covers quite a variety of topics across language and framework boundaries. My topics include Java, Groovy, .NET, and Javascript.
	Philadelphia	April 8-9	I am really looking forward to this conference so I can meet some of the people I've been wanting to meet for a while. My topic is related to DSL in Groovy.
	Minneapolis	April 16	Centered around technologies, tools, and frameworks related to Groovy, this one day conference will bring some of the key people in the Groovy community together. I will be giving the kick-off talk at this event and a few Groovy related sessions.
	Bangalore	April 20-23	This would be my third year at this conference. It is organized really well and one of the best polyglot conferences in India. I will be giving a keynote and speaking on F#, Java, Scala, Groovy, Functional Programming, and agile practices.
	Denver	May 6	This is a conference focused on Architecture. This is the first time I will be at this conference and looking forward to learning from others at the event. My talk most likely will be "Tell me about your Architecture, I will tell you about your Organization."
	Denver	June 14-17	Summer in Denver this year is going to be hotter than usual with Über Conf coming to town. This conference will offer an eclectic mixture of languages on the JVM and practical agility. The speaker round up looks awesome and the conference price includes a number of interesting workshops. Can't wait for this one.
	Houston	October 9	I could not make it to this event in the past few years, but I have promised to speak there this year. This is another good polyglot event with several great speakers and good participation from the attendees.

User Groups:

Java Metroplex User Group	Testing with Groovy	Jan. 13
Memphis Java User Group	How to approach refactoring	Feb. 18
Boston Area Scala Enthusiasts	Scala Idioms and Design Patterns	March 4

As more programmers are getting excited about test driven development (TDD), one concern I am
hearing more these days is "my tests and mocks make it hard to refactor code."

Remember we took a while to learn how to write better code. Similarly we will take a while to learn
how to write better unit tests.

I want to talk about unit testing and mocking here with an example that was brought up yesterday at
the (#sdtconf). A fine gentleman Zachary Shaw lead an open space discussion on the Hollywood Principle
and mocking. A number of very bright programmers who're very passionate about TDD were in the session.

When talking about the principles, etc. Zack demanded a concrete example. We tossed around a few examples
and I mentioned my friend David Bock's Paper Boy example. Taking that example and tweaking it to our
discussion and desires (as we programmers often do), we ended up with something like this:

public class PaperBoy {

public void collectPayments(List
   customers) {

   for(Customer customer : customers) {

   customer.getPayment(this, 200);

   }

   }

   //...

David, in his example, does not suggest that getPayment() accept an instance of PaperBoy, the example in our
discussion deviated from his example rather quickly.

Now, how would the getPayment() method of the Customer look like?

public class Customer {

public void getPayment(PaperBoy paperBoy, int amount) {

if (hasNoMoney || doesNotCareToPay)

paperBoy.stiff(this);

else {

deductMoney(amount);

paperBoy.acceptPayment(this, amount);

}

}

//...

It was suggested in the discussion that, in getPayment() method, the customer may decide to pay or based on some
condition may decide to stiff the paperboy.

So, how do we unit test this getPayment() method? Most of us readily agreed that we should mock-out (or stub out
or spy out, it does not matter for our discussion here) the PaperBoy. That will help us run the unit test on the
getPayment() method by isolating the PaperBoy.

Not so fast. Yes, if the getPayment() method has to be written like above, then mocking out PaperBoy may be one
way to unit test it. However, there are at least three problem (that I can think of at the moment) with the above code.

Problem 1. The above code has some unnecessary coupling and bi-directional relationship. The Customer depends
on PaperBoy. That is a coupling that I would seriously question.

Problem 2. The unit test is now made to do more. It has to create a mock of the PaperBoy. Even if you tell me it is not
much code, a single line of code that is not absolutely needed is a lot of code IMHO. You don't have to maintain code
that you do not write.

Problem 3. Are you really stiffing the PaperBoy? Who decides that? Can a paperboy decide that under very hard economic
conditions, a loyal customer may be deserves a break? I have no problem the customer deciding to pay or not, but if that is
stiffing or not is for the paperboy to decide IMO.

So, yes, you can certainly consider writing mocks for the PaperBoy, but I would not. Mocking is a tool I would use as the
last resort when unit testing.

How would I approach the above getPayment() method? Let's take a look:

public class Customer

{

public int getPayment(int amount) {

if (hasNoMoney || doesNotCareToPay)

return 0;

else {

deductMoney(amount);

return amount;

}

}

//...

Here the payment method does not depend on the PaperBoy. (If necessary you can pass information on what the payment is
for—paper, magazine, lawn moving, ...). The customer focuses on his/her own logic, whether to pay or not.

Now, how would the PaperBoy's collectPayment look like?

public class PaperBoy {

public void collectPayments(List
   customers) {

   for(Customer customer : customers) {

   int payment = customer.getPayment(200);

   if (payment == 0)
   


if (payment > 0)


    acceptPayment(customer, payment);

   else

   stiff(customer);

   }

   }

   //...

Our paperboy thinks that if payment has not been received, he's been stiffed. He could change his view at anytime without
affecting the customer class. The paperboy is a bit more complex now, but that decision as to whether he's been stiffed or not
belongs to him, not the customer.

Now, how would we unit test the getPayment() method of the Customer. That's not a big deal. No mocking is needed. Simply
run your test on your customer instance.

If you think returning 0 for payment amount is not clear enough, you can return a Payment object with more details contained
in it like Cash, CreditCard, BrokeCantPay, DontFeelLikePaying, etc. as the type of payment. It can then include additional details
like credit card number, etc. or you can even extend the payment information object. That can be used for any payment, not just
payment for paper. The decoupling also makes the code more extensible.

So, when would I use a mock or a stub? I would first try to remove or reduce dependency as much as I can. After a serious effort
to do that, then for those dependencies that are still left I would do one of the following:

A. Separate the business logic in my code from the object it collaborates with. That way, I can run unit test on the logic. Depending
on the situation, I am quite content with integration testing the code that collaborate and unit test the code that does the important
logic. I do not think 100% of the code needs to be unit tested. I do think that 100% of the code should be exercised. So, if I can get
coverage of the code that does business logic through unit test and coverage of the code that collaborates, with the object it depends
on, through integration tests, I'm quite happy assuming it gives me a reasonable (not necessarily instantaneous) feedback loop.

B. If that separation is hard or if I think I need to really get a quick feedback on the code while testing the collaboration not just logic,
then and only then will I consider writing a mock. In short, I use mock as the last option when I do TDD. I will first try to knock it out.
Only if I really can't I will try to mock it out. First try to knockout before you consider to mock-out.

I often get asked "Which web development framework should I use?" The answer generally depends on when I'm asked that question. Over the years I have played with, offered courses in, and written production code using various frameworks in the .NET space, the Java/Groovy space, and on Rails. My answer varies over time as, thankfully, different frameworks emerge and current frameworks evolve.

The tools and techniques for developing web applications on the .NET platform has come a long way. There was a time it was leading, then there was a time when it had to catch up. If you are developing web application on the .NET platform using Microsoft tools (as many developers do), I can't imagine today not relying on the MVC pattern and the capabilities of ASP.NET MVC Web Application Development framework.

The recently released "ASP.NET MVC In Action" from Manning by Jeffrey Palermo, Ben Scheirman, and Jimmy Bogard is a great way to deep dive into it.

The book is written for developers with practical knowledge of web development with ASP.NET. The authors get right into showing us how we will benefit from ASP.NET MVC and without wasting our time.

One of my favorites in the book is the emphasis on automated testing from the get-go.

The book does a good job of not only showing you what to do, but also provides cautionary words to avoid poor practices that may lead to maintenance issues on non-trivial applications. You'll learn how to organize and manage large applications, and also to what extent you can use your current ASP.NET skills and knowledge in ASP.NET MVC.

I feel that the discussion of MonoRail and Rails, taking one chapter, was a bit too much than I cared for. However, the authors do provide an objective comparison to ASP.NET MVC in the end of this chapter.

Overall, the book is a good read and well written. It certainly assumes you are familiar with web development and ASP.NET. If you have that background, it should be a breeze to get through the concept that will help you take good advantage of ASP.NET MVC.

Disclaimer: As I was reading the book, I was quite surprised to find that Ben had mentioned my name. Please do not hold it against him. :) It had no influence on my comments above.

I'm excited about the 2GX conference coming up in New Orleans October 19th to 22nd.
If you're interested in attending, the early bird registration ends Friday September 18th.
There is a $75 discount if you use promotion code SPRINGONE2GX75.

The conference is all about Next Generation Java (http://www.springone2gx.com).
It is two great events in one—SpringOne and 2GX—running concurrently with eight
tracks and over 100 sessions.

I am looking forward to speak there and, more so, to meet and listen to some of the leaders
and practitioners in the industry.

I recently had the pleasure of chatting with Scott Davis during an NFJS stop
in Phoenix. At the start of the interview, Scott surprised me with the question
"Does Groovy know that you are seeing other languages?" You can listen to
the full interview at http://blip.tv/file/2484840.