Tuesday January 08, 2008

OT: Can't beat the local news

I tend to stay focused on Spring, Java, Groovy, and other development related topics on this blog, but I couldn't resist posting this link to the local FOX affiliate's web site: Click here.

In case they remove the story, here's a screen-shot of the headline story that caught my eye...

The good news is that his passengers, Robert Gene Dumbass, 21 and William Harold Halfwit, 20, were unharmed and released after questioning.

Priceless.

Monday August 20, 2007

Busting the myth of agile development

One of my favorite TV shows lately has been MythBusters. For those of you who haven't heard of the show, the title pretty much explains it all. A team of individuals attempt to debunk some well-known myth, wives tale, movie element, or folk legend. Many times they're successful...sometimes they conclude that the myth is plausible. In any event, it's always fun to watch and usually they end up blowing up something, which always makes for good TV.

For several years, I've been convinced that Agile Development is the right way to develop software and I've made every attempt to let agile methods impact my work and my projects. But now, almost 7 years after first hearing about eXtreme Programming, I've started to believe that a truly agile project is a myth. It's something I read about and know about anecdotally, but like Elvis sightings and on-time air travel, it's something that has never happened to me.

Don't get me wrong...I've witnessed many valiant attempts at agility in software development. But in every case I've been a part of so far, it has either been squashed by upper management or the entire team simply wasn't on-board. At my current job, I've been encouraged that many steps have been made in recent weeks to be more agile. But it's been a slow-go and not a day goes by that the old habits aren't resurrected at least a little bit.

So is all lost? Has the agile myth been busted?

A couple of weeks ago, I had the great privilege to sit in for a few hours with the development team at Semantra. In that very short visit, I witnessed what I believe to be the most agile practice of software development I've ever seen. Unlike anything I've ever seen before, their development process screamed agility. They worked from a prioritized list, in short time-boxed/fixed-scope iterations, pairing up, writing unit-tests, doing just-enough just-in-time design, had a product owner sitting with the development team, and are moving quickly to address business needs. It was truly a beautiful thing. It was spot-on with something I've read recently about how software should be developed. It felt good...it felt right...it's how I want to develop software.

What makes the difference for Semantra? I think agility is working for them because everyone is committed to it. Everyone from the development team all the way up to the CEO are on-board with developing their product using agile techniques. I think that's the key. If anyone is skeptical or doesn't fully understand agile development, they're a liability to its success. But if everyone has bought into it, agile development can work.

Thanks to Semantra, I'm heartened to report that agile development is very plausible. Given this encouraging news, I'd like to continue observing Semantra's agile endeavors. To that end, I've agreed to take a position as an "agile developer" with Semantra, starting on August 27th. I'm very hopeful that in this position I'll finally be able to declare agile development as a reality and not a myth.

If not, then in true MythBusters fashion, maybe we'll get to blow something up.

Thursday July 19, 2007

Spring in Action 2: The release party

Last night I presented some tips on how to reduce/eliminate XML from your Spring configuration at the Spring Dallas User Group. At that meeting, we also announced a special event for next month's meeting.

If all goes to plan, Spring in Action, 2E will be going to the printers tomorrow (July 20). I've already seen the final version of the cover and we've just been making some small tweaks this week. Knowing how long it takes to get from the printer to a bookstore near you, I would expect to see SiA2 on the shelves and on Amazon sometime around the first week of August.

That timing coincides nicely with the August 15th meeting of the Spring Dallas User Group. So, at the August 15th SDUG meeting we're going to do something a bit special and have a SiA2 release party. I, for one, will be celebrating the fact that I'm finally finished with the book and you're welcome to join in. Manning and No-Fluff/Just-Stuff will be pitching in with food and special giveaways. As always, Nerdbooks will be providing the venue. And I'll be presenting a topic of some Spring-ish interest.

So put August 15th on your calendar to attend the Dallas Spring User Group. More details as we get closer to the date.

Tuesday June 26, 2007

Spring in Action: A Status Report

It's been quite awhile since I've written anything here, so I thought I'd break the silence by giving everyone a status on Spring in Action, 2E.

Let me start by saying that it has taken me a lot longer to get this done than I (or my wife) ever expected. Part of that is because this is the first book I've written solo (Ryan decided to sit this one out, but was still very helpful in reviewing some of the text and some of my ideas) and I didn't realize how big of a difference having a co-author makes. But also, there's just so much Spring goodness to write about, it was hard to decide what should go in and what shouldn't. As you'll soon find out, there was so much to be written that the printed book overflowed and some material will end up being available as a free download at the book's web site (it's not there yet...but it will be by the time that the printed material is available).

Starting last week, SiA2E is in proofreading mode. As some of you know, that was the mode we should've spent more time on in the first edition. But this time we're giving it a deep look and there are more eyes on it, so hopefully there'll be far fewer errors. Inevitably, there'll be some snafus that slip through the cracks, but it won't be for lack of us trying to stop them.

I'm also taking the next few weeks to check and double-check the code examples to make sure that they work and make sure that they're consistent with what will be in the printed book. I made the mistake of letting the code examples from the first edition evolve independent from the printed examples and it caused a lot of confusion (and some anger) among the readers. This time, I'm trying really hard to keep the downloadable code examples in sync with the book. In addition to being available for download from Manning's web site, I also intend to host them in a Subversion repository--that way I can still evolve them independent from the printed book, while keeping the history of the changes intact. (More on that when it becomes available.)

As I said, we're proofreading everything right now. If we stay on schedule, the first pass at proofreading will be complete by July 4 (or maybe July 6--there was some debate on that, as July 4 is a holiday). After that, a second set of typeset pages will be produced and we'll take another pass or two over them to make sure we didn't miss anything. If everything goes to plan, the book should go to the printers around July 15th.

That means I'll likely have printed copies on my doorstep by the end of July and they'll be available from Amazon and on a bookshelf near you within a week or two thereafter.

Which brings me to my next point: I'm scheduled to speak at the Spring Dallas User Group on July 18th and again on August 15th (the topics will be announced soon). To celebrate the release of SiA2E, we're planning something special for the August 15th meeting. If you're in the area at that time, you'll want to mark your calendar to attend. Keep your eye on this blog, Manning's web site, and The Spring Dallas UG site for more details when they become available.

Finally, I've been chatting with Jay Zimmerman lately about rejoining the No-Fluff/Just-Stuff tour. Nothing's been nailed down yet, but I anticipate visiting a handful of cities later this year with NFJS talking about things like Spring configuration tricks and tips, Spring in general, Spring-WS, Maven 2, and maybe Spring-OSGi. Keep an eye on the NFJS site for more details.

Monday March 19, 2007

Writing a book

As I go around talking to people and speaking at user groups and conferences, I've had several people ask me about my endeavors in book-writing and ask me "how do you get started"?

I often mention the standard requirements:

After that, the best advice that I can give anyone is to read Dave Thomas' series of articles on writing. I wish I had read this before I had written 3 books...might've made a world of difference (eg., I may not have written them!).

Friday March 16, 2007

It's 2004 all over again

Why is JRoller producing fresh RSS feeds for this blog with stuff I wrote in 2004? [grumble grumble grumble]

Tuesday December 26, 2006

Emily Madison

Most of this blog's readers already know that my wife and I have had a certain project in the works for the last 9 months. I'm proud to announce that Emily Madison Walls was delivered today.

Maisy kissing Madison on the cheek

She was born at 2:47pm (central). She weighed in at 6lbs 10oz and is 20 inches long. Aside from a little more hair and slightly chubbier cheeks, she's a perfect copy of what her sister looked like when she was born.

Saturday December 16, 2006

Give them the gift of programming

With just over a week left before Christmas, do you still not know what to get for that programmer geek on your list? If so, then let me point you to the newest feature of this blog: The Spring-Loaded Bookstore.

Almost as long as I've had this blog, I've been sprinkling links to various books in my blog entries. These links go back to Amazon.com where, as an Amazon Associates member, I get a very small credit for purchases made through the links. I'm hardly getting rich off of it, but it helps a little toward paying for my addiction to programming books.

With so many exciting new books coming out in the near future, I decided that I wanted to rev up my click-thru and conversion rates by adding an Amazon aStore to my blog. I frequently get e-mails from Amazon encouraging me to setup a store, but I've never bothered until now. As it turns out, setting up an aStore couldn't be any easier. Just pick a color scheme, create some categories, and choose some products. In no time at all I've got my own bookstore.

Of course, as the old adage says, "You can lead a horse to water, but you can't make him drink." You're always welcome to buy your books from whatever vendor you choose. But I'd certainly appreciate it if you'd consider funding my tech book habit by purchasing books through the Spring-Loaded Bookstore. After all...you gotta buy 'em from somewhere...why not here?

Wednesday August 02, 2006

I would've gotten away with it if it weren't for those meddling unit tests

Saw this today in a commit comment:

It brought both a chuckle and a tear to my eye.

Wednesday May 24, 2006

Put a pitchfork in it...it's done!

By now, you've probably heard the announcement made by BEA and Interface 21 regarding a joint open-source effort to add some EJB 3 support to Spring. And now to give substance to that announcement...

I quite accidentally discovered that Pitchfork is now available for download. I picked it up and tinkered with it over lunch today and it seems to do what it advertises. That is, I can use JSR-250 annotations for dependency injection and interception with beans that are managed in Spring.

I had some trouble running it against the nighly build of Spring 2.0 RC1, but it worked like a champ with Spring 2.0-m4. You'll also need to have commons-logging.jar, AspectJ, and ejb.jar in your classpath.

I'm still not sure that I buy into DI being an appropriate use for annotations, but it's still interesting to see Spring playing along nicely with the EJB 3 specification. More on pitchfork as I have more time to tinker with it.

Tuesday January 24, 2006

Moving on...

You may have noticed that I've not posted much on my blog lately (until tonight). And the astute reader may notice that my list of employers (on the right side) has changed to reflect a new employer...which, in part, explains why I've been too busy to update my blog.

For quite awhile, I've been growing increasingly frustrated and disheartened with my job at Michaels Stores. In short, despite my team's successes there was a move afoot to stifle our agile ways in favor of more rigid software development. I fought it for a long time, but I finally became jaded and decided it wasn't worth the frustration. I began looking for new work.

In my search, I talked to several great companies, including (no names mentioned)...

I also considered going into independent consulting and at The Spring Experience, several people handed me their business cards asking if I'd be interested in joining their company. All of these appealed to me but...

In the end, it was my No-Fluff/Just-Stuff colleague and friend Glenn Vanderburg who got me in the door at Countrywide Financial. The drive to work is a bit long, but the team I'm on is great. The ironic thing is that I'm on a team at Countrywide that is revolutionizing software development within the company--I'm on a team that has management backing to do what I failed to pull off at Michaels.

I'm excited to be there. I am met with new challenges in this job, but they're the good kind of challenges...the kind I can learn and grow from.

"Books" will appreciate it...

Last week I had the opportunity to visit Nerdbooks in Richardson, TX. I was there to present at the Spring Dallas User Group, but I got there early enough to browse their selection and had the pleasure of meeting Dave (the owner) and "Books" (the store dog).

Actually, Books took me by surprise. I'm no stranger to dogs (I have 4 of them myself), but it was a bit peculiar to see a dog in a bookstore. Nonetheless, Books is a very friendly dog and it was pretty cool that he gets to hang out at Nerdbooks.

You may have noticed that I've swapped out my "The Spring Experience" banner in the header of this blog with a banner for Nerdbooks. I don't often promote specific businesses or products, but I make an exception for a business that I really like. Since TSE was over awhile back, I decided to offer the space to Nerdbooks...just because they have such a cool bookstore. They have an AWESOME selection and fantastic prices on virtually every computer-related book in print.

I invite you to check out Nerdbooks.com. Or if you're in the Dallas area, make a visit to the store in Richardson.

Thursday November 03, 2005

No NFJS for me...

I was supposed to be speaking at NFJS this weekend in Dallas, but...

Unfortunately, my wife has been in the hospital for a few days. It's nothing too serious and she's doing a lot better, but she'll be off of her feet for a few days and she's going to need some help wrangling our 10.5 month old daughter. So, I had to tell Jay that I had to bow out.

Jay tells me that he's arranged for Keith Donald to fly in and fill in for me. I've never heard Keith speak, but I know that he knows his stuff. I'm actually a bit bummed that I can't be there because I'd love to hear Keith's presentations. (But if I was there then there'd be no reason for Keith to be there.)

I guess that I'll just have to wait until next month when both Keith and I are speaking at The Spring Experience.

Friday August 05, 2005

POROs and the future of space exploration

The latest shuttle flight hasn't been without its hiccups. But as I write this it looks as if everything is clear for Discovery and her crew to return home on Monday.

Like many, I've been in awe of the shuttle program since the very first Columbia launch. The shuttle is a magnificent space vehicle and much great work has been accomplished as a result of the program. But it has turned out to be more costly than originally expected, costing $1.3 billion (average) per flight--2 orders of magnitude over its original estimates. Furthermore, as evidenced by the Challenger and Columbia accidents, as well as the problems with Discovery's latest flight, the safety of the shuttle has been called into question.

With everyone eyeing Discovery and the future of the space shuttle program, I've found this fascinating article that indicates that future exploration may hinge on a simpler and more traditional design.

In this new program, traditional rockets (Plain-old Rocket Objects or POROs, as I'm referring to them) will be outfitted with some of the best aspects of the shuttle program. Furthermore, the jobs of hauling people and hauling cargo will be decoupled from each other. Thus humans will only need to be involved in flights of exploration and scientific value, while routine transfer of supplies to and waste from the international space station can be done without risking human life. The result is supposed to be a safer and more cost-effective way of exploring space...without the overhead and difficulties encountered by the shuttle program.

This reminds me of something, but I'm not sure what it is... ;-)

Spring, ESBs, and File Suckers

In the enterprise, it's unusual that any application stands alone. Quite often, two or more applications must collaborate, sharing data between each other. A workforce scheduling application may need to share data with the payroll system. Likewise, the payroll system may need to share information with the financials system. And they all may need to interact with the HR application.

There are several tricks, schemes, and hacks to share data between systems. Most of these tricks are one-off integration solutions that are only useful to tie two specific systems together. When you need to throw another system into the mix, you'll probably need to start over and come up with another integration scheme.

A primitive, yet very common integration solution is file-sharing (known as the File Transfer pattern as described in Enterprise Integration Patterns). Using file-sharing a payroll system may write information to a file to be picked up and processed later by the financials system. Often, file-sharing involves some form of scheduling (e.g., cron) to trigger the receiving application to pick up the data file.

The problem with scheduled file-sharing is that the sending application has a finite window of opportunity to write the file before the receiving application comes along and picks it up. In the best case, the sending application finishes writing the file well in advance of the schedule (resulting in wasted time that the receiving application could use to process the data). In the worst case, the receiving application wakes up before the sending application has completed its work (resulting in missing or incomplete data).

In a perfect world, the financials system would pick up the file at precisely the moment that the payroll system has finished writing it. No sooner...no later. The file will always be complete and never have to sit idle waiting for financials to pick it up.

This sounds like a job for a File Sucker.

ESBs as File Suckers

"File sucker" is the name that I use to describe any mechanism that watches a directory for new files. Upon seeing a new file, it immediately sucks the file in and passes it on to any other applications that need it.

File sucking is hardly a new idea. In fact, it is a common feature in most Enterprise Service Bus (ESB) implementations. Although ESBs provide a rich array of integration options that are more robust than file sucking, most ESBs still provide support for monitoring directories and reading files into the bus. Support for file sucking in ESBs enable incremental adoption of the ESB into environments where file-sharing is already a common integration mechanism.

One such ESB that supports file sucking is Mule ESB. In Mule, creating a file sucker involves configuring a component whose inbound endpoint is a file directory. When a file appears in the watched directory it triggers an event in Mule, prompting Mule to read the file into the bus.

There are several ways to setup a file sucker in Mule. But since I'm a Spring fanatic and this is a Spring-centric blog, let me show you a very easy way to use Mule and Spring together to create a file sucker.

What you'll need

Here are the JAR files that I'm using to write the file-sucker example:

Most of these files (or their equivalents) come with the Mule download. But you'll need to provide your own spring.jar file. For your convenience, I've collected all of the required JAR files and have uploaded them along with my example code for you to download here.

Configuring a multicaster

Mule comes with (in Mule extras) MuleEventMulticaster. This clever class subscribes to one or more service endpoints and, when an event arrives on that endpoint, it multicasts it out to any bean who is interested.

For the purposes of our file sucker example, we'll configure the MuleEventMulticaster as follows:

<beans>
  <bean id="applicationEventMulticaster"
      class="org.mule.extras.spring.events.MuleEventMulticaster">
    <property name="subscriptions">
      <list>
        <value>file:///inbox</value>
      </list> 
    </property>
  </bean>
</beans>

As you may have guessed, this particular MuleEventMulticaster keeps an eye on the "/inbox" directory, pulling in any files it finds there. But what does it do with the files that it finds?

To try this out, let's write a simple class with a main() method to load this bean into a Spring container. Perhaps something like this:

public class FileSucker {
  public static void main(String[] args) {
    new FileSystemXmlApplicationContext("sucker.xml");
  }
}

After running this code, copy some files into the inbox directory. If you take a look at the directory, you'll notice the files mysteriously disappearing almost as soon as they arrive. This proves that Mule is pulling them in. But where do they go?

At this point, the MuleEventMulticaster is sucking in the files, but since there aren't any event listeners, there's nobody to receive them. They're all sucked up with nowhere to go. Let's give them some place to go by adding an event listener.

Building an event listener

Mule's documentation implies that any implementation of Spring's ApplicationListener interface will receive Mule events. But as I've found in my own experiments (and as evidenced in the source code for MuleEventMulticaster) your listener classes must implement MuleEventListener. The good news is that MuleEventListener extends Spring's ApplicationListener and has no additional methods beyond onApplicationEvent()...so creating a Mule listener is not much different than creating any other Spring ApplicationListener implementation.

Here's a simple implementation of MuleEventListener:

package com.habuma.sucker.mule;

import org.mule.extras.spring.events.MuleEventListener;
import org.springframework.context.ApplicationEvent;

public class EventListener implements MuleEventListener {
  public void onApplicationEvent(ApplicationEvent event) {
      System.out.println("GOT AN EVENT: ");
      System.out.println(event.getSource());
  }
}

In the "real world", this event listener would probably be more exciting, reacting to the event by performing some sort of business logic. For simplicity's sake, this event listener simply sends the contents of its event to stdout.

Aside from implementing MuleEventListener, this class is no different than any other Spring ApplicationListener. But by implementing MuleEventListener you're indicating that you want this class to receive Mule events.

Now let's configure EventListener as a bean in the Spring context...

<beans>
...
  <bean id="myListener"
      class="com.habuma.sucker.mule.EventListener" />
...
</beans>

To see the event listener in action, startup the application and copy some files into inbox. You should see the EventListener react to every file that is copied into inbox.

There's only one gotcha: MuleEventMulticaster will send the file events to all MuleEventListeners. What if your application has several event listeners and you want each to list for specific events. For example, what if you have two instances of EventListener, one to receive files from "inbox" and another to receive files from "otherbox"? As configured above, both instances of EventListener will receive all events from MuleEventMulticaster regardless of where they came from. This means that both EventListener instances would receive files from both directories.

To remedy that situation, you'll need to implement MuleSubscriptionEventListener instead of MuleEventListener:

package com.habuma.sucker.mule;

import org.mule.extras.spring.events.MuleSubscriptionEventListener;
import org.springframework.context.ApplicationEvent;

public class SubscriptionListener implements MuleSubscriptionEventListener {
 
  public void onApplicationEvent(ApplicationEvent event) {
      System.out.println("GOT AN EVENT ("+this.hashCode()+") : ");
      System.out.println(event.getSource());
  }
  
  private String[] subs;
  
  public void setSubscriptions(String[] arg0) {
    this.subs = arg0;
    
  }

  public String[] getSubscriptions() {
    return subs;
  }
}

MuleSubscriptionEventListener requires that you implement a getSubscriptions() method in addition to onApplicationEvent(). getSubscriptions() should return an array of String that contains all of the endpoints that the listener is interested in. Although it's not required by MuleSubscriptionEventListener, I've also added a setSubscriptions() method so that I can use Spring's IoC to wire in my endpoint definitions.

One more thing you'll need to do is reconfigure your application context such that each SubscriptionListener specifies their own list of endpoints:

<beans>
  <bean id="applicationEventMulticaster"
      class="org.mule.extras.spring.events.MuleEventMulticaster"/>

  <bean id="myListener"
      class="com.habuma.sucker.mule.SubscriptionListener">
    <property name="subscriptions">
      <list>
        <value>file:///inbox</value>
      </list> 
    </property>
  </bean>

  <bean id="myOtherListener"
      class="com.habuma.sucker.mule.SubscriptionListener">
    <property name="subscriptions">
      <list>
        <value>file:///otherbox</value>
      </list> 
    </property>
  </bean>
</beans>

Here we have two instances of SubscriptionListener, each with their own selection of endpoint subscriptions. Also, notice that MuleEventMulticaster no longer keeps its own list of subscriptions.

Now if you fire up the application, you'll be able to copy files into either "inbox" or "otherbox"...each instance of SubscriptionListener receiving its own set of files.

So what?

As I've said, a real world application would likely do something more interesting than simply print out the contents of the files that are sucked in. It may simply write it to a database or process it and then fire the results out as another event in the ESB. As an exercise for the reader, try to imagine the possibilities of how MuleEventMulticaster can be used in your real world applications.

Before you get too carried away, you should know that there's really more here than meets the eye. Although I've been talking about creating a file sucker, the only thing that makes this a file sucker is that the listeners are subscribed to a "file://" endpoint. The event listener classes themselves have no idea that their content is coming from a file. What if instead of reacting to files being written to a directory, you'd like to respond to an e-mail, a JMS message, or perhaps a message sent via TCP?

No problem...just swap out the "file://" endpoint with any one of Mule's other endpoints. For example, to listen on TCP, port 9999:

  <bean id="myListener"
      class="com.habuma.sucker.mule.SubscriptionListener">
    <property name="subscriptions">
      <list>
        <value>tcp://localhost:9999</value>
      </list> 
    </property>
  </bean>

Or maybe you want to receive messages from a JMS topic or queue...

  <bean id="myListener"
      class="com.habuma.sucker.mule.SubscriptionListener">
    <property name="subscriptions">
      <list>
        <value>jms://my.queue</value>
      </list> 
    </property>
  </bean>

  <!--
     To use JMS you need some additional setup
  -->
  <bean id="jmsConnector" class="org.mule.providers.jms.JmsConnector">
    <property name="specification">
        <value>1.1</value>
    </property>
    <property name="connectionFactory" ref="connectionFactory" />
  </bean>

  <bean id="connectionFactory"
      class="org.activemq.ActiveMQConnectionFactory">
    <property name="brokerURL" value="tcp://localhost:61616" />
  </bean>    

But why choose? Notice that the "subscriptions" property is an array. If you want, you can use listen on several endpoints at the same time:

  <bean id="myListener"
      class="com.habuma.sucker.mule.SubscriptionListener">
    <property name="subscriptions">
      <list>
        <value>file:///inbox</value>
        <value>tcp://localhost:9999</value>
        <value>jms://my.queue</value>
      </list> 
    </property>
  </bean>

Files, TCP, and JMS are just the beginning. Mule has several providers for a variety of different endpoints, including:

Use your imagination...Instead of a file sucker, you can use this same technique to have a bean listen for e-mails to arrive at a certain POP3 address. Or maybe you'd like a bean that processes XML messages that arrive via HTTP.

This article has been very Mule-specific. ServiceMix is another up-and-coming ESB in CodeHaus that I've been tinkering with. In some future installment, I'll show you how to do have some similar fun using Spring and ServiceMix. Stay tuned.

There's much more to ESBs and Mule than simply sucking in files and multicasting them to interested listeners. But that's another discussion for another day. In the meantime, if you want to learn more about ESBs, take a look at both Mule and ServiceMix and start tinkering. I also recommend that you check out David Chappell's Enterprise Service Bus book. This book cleared up a lot of ESB concepts for me.

Another book I've enjoyed on application integration in general is Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf. Mule's architecture is based heavily on the patterns described in this book.

I'll be talking more about using Spring with Mule and ServiceMix next weekend at the LoneStar Software Symposium in Austin (and again later this year in Dallas) and at The Spring Experience in December. Hope to see you there!