Goodbye Groovy – Hello Ruby

I guess the wheels are coming off the Groovy bandwagon and I am jumping off before it’s too late. I’ve blogged about Groovy before and how I had drunk the Kool-Aid. I loved Groovy and that love was based on Java and the fact that I could use my existing Java classes in my Groovy apps and vica versa. But the JSR hasn’t brought the excitement to the Groovy cause that I had hoped and so I am now officially jumping off the bandwagon.

I’ve tinkered with Ruby before – Dave Thomas makes a great case to explore Ruby or any other programming language to expand your horizons and learn to think differently. I guess I finally get a chance to take a serious look at Ruby and see if it can fill the gap I currently have for simple tasks that don’t need all the features of Java. I’m sure most developers write simple ‘one-off’ applications that read the database, send emails, parse a file and stuff it in the database, etc. Ruby seems like a nice solution to fill that role at face value.

The only apprehension I have with Groovy and Ruby and many of the other technologies out there is the introduction of these technologies in the enterprise. Like most developers, I have a full-time job where I work with a team of developers with varied skills. As the technical lead, I am always looking for ‘things’ that make our development team deliver a better solution, faster and cheaper. But the introduction of anything new comes with consequences – Developers need to get comfortable with the new technology and feel confident writing code using that technology. Support people need to understand the new ‘thing’ and how to debug, explore issues, etc. All these factors have to be taken into consideration before exposing the developers to something new. I need to spend more time reading the Ruby Insurgency presentation from Dave Thomas, which is a nice presentation on how to successfully introduce Ruby into your organization.

Groovy, Ruby


BEA to join Eclipse – RIP Workshop?

Wow – this is huge. I just saw Dion’s posting on TSS about BEA’s decision to join the Eclipse foundation and commit to shipping something built on top of Eclipse. I wonder what this means to the Workshop effort? I went to dev2dev and BEA’s press-release site but couldn’t find any more information. I wonder if this is BEA giving up and falling in line with the Eclipse effort – Eclipse does have a commanding lead in the IDE/Tools market in the Java/J2EE space.

If BEA is indeed capitulating, Sun is the only holdout as Oracle was dumping JDeveloper (I think) and using Eclipse as the base framework. I’m keeping hope alive that IntelliJ keeps on making kickass products like IDEA and can keep on competing with Eclipse. Nothing against Eclipse, I just happen to be completely, totally, madly in love with IDEA – I know, I need help.

I love The Dumbster :)

Cobbie just turned me onto Dumbster, a really awesome tool for unit-testing applications or classes that send out email.

Dumbster is a very simple fake SMTP server designed specifically for unit and system testing applications that send email messages. It responds to all standard SMTP commands but does not actually deliver the email messages to the user. The messages are stored within Dumbster for later extraction and verification, further enhancing your unit tests, as you are able to validate sender, recipient, subject, and message content.

The Dumbster is written in Java and is open source and a must have in your testing toolbox. Thanks Cobbie and thanks Jason Kitchen for creating The Dumbster.

public void testTextEmail() {

String smtpHost = “localhost”;
String to = “”;
String from = “”;
String subject = “Testing EMailUtil”;
String message = “Writing Unit tests is fun – don�t you agree ?”;
String replyTo = null;
boolean debug = true;
try {
SimpleSmtpServer server = SimpleSmtpServer.start();
EmailUtil.sendTextMail(smtpHost, to, from, subject, message, replyTo, debug);
assertTrue(server.getReceivedEmailSize() == 1);
Iterator emailIter = server.getReceivedEmail();
SmtpMessage email = (SmtpMessage);

} catch (EmailUtilException e) {
fail(“Shouldn’t get an exception”);