Internal & External DSLs in Java

I attended Venkat's talks at NFJS and I was really excited about what Groovy brings to the table for helping you be a more productive Java programmer. He started a series for DSLs in Java and I found this article to be very interesting.

joel on ruby

Kent Beck keynote at Rails Conf 2008

KB's keynote is a retrospective of his experiences as a leader in the industry.

I don't like reading

Beck on Test Driven Design

http://www.threeriversinstitute.org/AbstractVsConcreteParameters.html
This is an interesting blog post. After reading it, I did asked myself, which of these approaches leads to a better design?
Take the example that Beck mentions on the JUnit mailing list, he suggests to "objectify" the integers into a SocketConnection:
class Client { Client(int address, int port) { this(new SocketConnection(address, port)); } }
He then goes on to say that it will be easy to inject an impostor and then you will have more control over the interaction between a socket connection and the client. The problem however is the "cost of modifying the client" because of the lack of flexibility one has when working with a language like Java.
This is not a problem when working with a dynamically typed language like Groovy or Ruby because clients are free to open classes, which makes it easier to remove dependencies. This eliminates the need to make any changes to the client code in order to make it more "testable". This leads me to the conclusion that "good design" changes depending on the language you are using. It seems to me that the more flexibility you have the less it matters how concrete things are in the system... NOT!
Using a flexible language does not excuse you from authoring tightly coupled code. This is something I often observe in CRUD applications because they are generally not designed using a tell don't ask, demeter abiding, publish-subscribe style. If you are lucky the team may use life-cycle hooks like before_save or @PrePersist but chances are your controllers are acting as mediators instead of view components.

RubyConf 2008

I am going back to MCO... MCO... MCO...
... Did I mention I am back working on RoR? :-)

I really should twitter...

Am I an idiot?

The thing about the internet is that your comments are immortalized.
http://www.theserverside.com/news/thread.tss?thread_id=36509#184443
I have come a long way from BUFD...

XP without TDD?

I've been reading a lot of articles and presentations about the state of "agile" adoption. One that caught my attention was "Just Ship, Baby". In it Kent Beck writes:

I had an idea for another little tool yesterday. I wrote it without any tests, just to remind myself that I could still program without a net if I had to. I really didn’t like the feeling of not having any tests, especially when the algorithm got hairy. I’m not sure my code works in all cases. But you know what? I shipped. Turns out it isn’t that cool of an idea, and I’ll drop it. Total cost for that answer—3 hours.

What no TDD? At first, I was appalled but after reflecting on it, it seemed all he did was spike a solution in three hours, which I believe that is a perfectly healthy agile practice. However, this article like many other presentations is a sign that the "agile" community is undergoing a transformation.
No less than ever are we willing to dive in head first to make an impact. I once thought that we were a small band of engineers trying to save ourselves from the waterfall only to find that in the end we are producing waterwheels. How did this happen?