Maven dependency updates for the team

While refactoring a legacy build at work recently, I ran into an issue with the maven xdoclet plugin. It appeared to be confusing the modules I was trying to use when I would use it more than once. It would work fine and then crash and burn throwing an ambiguous subtask error. Oh well.

Anyways, I fixed the problem by downloading the version 1.2.3 src code, applying a patch, and then rebuilding the xdoclet dependencies. I then applied those changed jars to my local repo cache located in the %user_home_dir%/.m2 directory and test it.

Here’s the reason why I wrote this post. To quickly test your change you can simply apply those fixed jars as described above. If the changes appear to work you can then apply them to the company repository, like Nexus or something. Notify others to clear the dependency cache (it can just be for that specific dependency). This will allow the updated version to be pulled down from the company repository. This is the important part.

Another approach is to create a new version number to force download but you are then updating pom files and trying to override what the plugin uses by default. Whichever approach suites your taste.

I’m sure there’s other ways… If you have any please feel free to share a comment!

Agile 2009 – Refactoring Legacy Code

I will be leading a hands-on refactoring session at Agile 2009 in August! Here’s the session information:

Room: New Orleans
Date/Time: Thursday 2:00-3:30PM
http://agile2009.agilealliance.org/node/630

I look forward to seeing all of you there!

GROOVYMAG May Edition!

I wrote part 2 of “Get Rich Quick with Flex and Grails” for Groovymag. Check it out!

Stumbling towards agility

I’ve been developing software now for several years. Most of those years have been as a consultant among various clients, cultures, architectures, methodologies, and technologies. Now I’m an author, speaker, and currently working for a product company that builds medical management software for the insurance industry.

Through it all I’ve seen one common element among folks that I’ve had the privilege of working with. Nearly every team I’ve worked with desired more agility in what they were doing. Most would agree that the affects of agility for the perceived value or inherent benefit is a good thing. For those that take that challenge on good for you. Some strive to arrive at some form of agility and get there while others well….don’t.

As for me, I’m always stumbling towards agility. It’s never perfect, sometimes ugly, not always easy, but always worth it.

Flex On Java – Note for the readers

We would like to take a minute to personally update you on the progress of our book. Although we are running behind the originally estimated release date, the end product will be a much better learning experience. From the beginning we have been continually refining the book and have taken the great feedback we’ve received to align the book more closely to your thoughts and insights. If you are receiving this letter and were part of the reviews, THANK YOU! Much of the feedback received, all helpful, really matched with how we (the authors) were feeling and helped us to really home in on what we felt would be important to include. Here are just some of the things that can be expected out of the new and improved Flex on Java.

Developer accessibility
When we started the Flex on Java journey we wanted to write a book that would assist Java developers in refactoring Java applications with the richness of Flex. Unfortunately, the sample application wasn’t a good fit for everything we wanted to teach and was absorbing too much of our time trying to make it work properly for the readers. The sample application was an open source product that was not easy to download, build and go. This issue caused us to rethink our approach and we turned to Matt Raible’s AppFuse framework that is aimed at helping developers build applications quickly and efficiently. AppFuse makes deployment and creation of the sample application a breeze and also opens the door to developers who are new to Java. It allowed us to focus more on the topic of integrating Flex with Java while broadening its audience to those who are not Java or Flex gurus.

Hit the ground running (faster pace)
The free chapter available will become an introduction to the book and chapter 1 will now get readers rolling with development on the first page. Chapter 1 will begin with developing the server-side application with the AppFuse framework and then quickly begin integrating Flex in chapter 2.

Deepening focus on Flex integration with Java
The faster tempo and more narrow focus on the topic of Flex and Java integration allows us to quickly go deeper in that topic. We will discuss how to use BlazeDS to connect to the Java server-side including POJO services, Spring services and Spring security in more detail. We will also include working with real-time JMS applications utilizing the Flex and Java APIs.

More focus on scalable frameworks
Good developers move from technology to technology and look for frameworks that allow them to avoid the common problems when designing an application. Frameworks for doing both dependency injection for creating loosely coupled applications and Model-View-Controller (MVC) will be explored in more detail. Frameworks such as Spring ActionScript, Cairngorm, and Pure MVC (and possibly others) will be demonstrated.

House cleaning
There are other topics like building the application with Ant and setting up continuous integration that are important but not part of the main gist of the book, so we moved those topics into the Appendices of the book. There are other housecleaning items that are being performed to make this the best book possible on integrating Flex with Java.

We hope that you will be delighted with the upcoming changes to the book. Please feel free to provide us with any feedback you may have for us. Thanks again!

Sincerely,
BJ Allmon and Jeremy Anderson
Authors of Flex on Java

GROOVYMAG April & May Issues – Get Rich Quick with Flex and Grails

My co-author Jeremy Anderson and I had the recent pleasure of writing for GroovyMAG (http://groovymag.com) and working with Michael Kismal who is a cool dude. It just so happen to make the cover in April where we plug Flex into Java in part 1 of the series. Part 2 will make the application real-time with JMS. This is fun stuff so check it out!!

Learning through a Brown Bag

Since joining up with Click4Care I’ve continued down the path of leading brown bag lunch time meetings with a variety of topics including Continuous Integration (CI), Maven, and sooner than later Flex, Grails, Java, Clean Code clinics, Agile practices, ect.

There are so many opportunities to learn from one another and I’ve taken that approach as I’ve gone from customer to customer realizing that it’s making everyone better in the end. I don’t really care if an organization has never done them in the past. There’s never a better time to start then now!

Recently, Click4Care hosted a more formal brown bag training session around the topic of Groovy and Grails. The authors of “Beginning Groovy and Grails“, Chris Judd and Jim Shingler came to lead it for me and it was fantastic.

Since doing more traditional brown bags we’ve had about 15 on average showing up which is a great number. However, in my opinion if there are 2 or more you have a real opportunity to learn.

If you haven’t already, try out brown bag lunches in your organization. You will not be sorry you tried.

Here are some brownbag guidelines that I follow:

1. Do them at lunch. People had their coffee and they are not already brain dead.
2. Keep it cheap. Brown bags usually imply that you are packing a PBJ or bologna sandwich.
3. Keep it simple. (KISS) You don’t need an expert, just a topic to discuss. Everyone can join in the conversation.
4. Avoid heavy presenter format that hinders non-presenter types in leading a session. Teach them to lead by your example of facilitating a conversation around a topic.
5. Keep it consistent. Try to hit the same day and place during the week to avoid confusion.
6. Mix it up with a clinic style every now and then to keep it real.
7. Let the group decide the direction. If there’s no one leading the way keep driving. Just hold loosely to the steering wheel.
8. Encourage others to participate in leading them and help them find topics that you think they could be successful in. This means that you are being observant of your team strengths and weaknesses.

I’m sure there’s more. Enjoy!

Meta-enhanced Development

Okay.. So maybe the term OWN-DD is a little ridiculous. How about Meta-enhanced Development? Yup.. That’s pretty much it and yes the acronym is MED. (which usually means a medication..) Hey, that’s not bad at all.

OWN-DD : A fitting acronym by today’s standards

There has been no doubt that with the rise of Ruby and Ruby on Rails (RoR), Maven, Appfuse, Groovy on Grails and other convention over configuration based frameworks and development tools we are in a new era of software development. The days of verbose architecture and massaging architecture every time new features are required is coming to a close. Thank goodness.

With that in mind I thought it would be fitting to exploit a new pattern in development that I’ve noticed myself adhering too for quite a while with others. It’s nothing new but deserves an acronym of it’s own. This is why I came up with “Only When Needed – Driven Development” or “OWN-DD”. I like this acronym. The first two letters alone “OW” is a term that means “interjection” (used esp. as an expression of intense or sudden pain.) This describes how many of us feel when we have to rummage through the ugly details of boilerplate mumbo-jumbo and configuration.

On the other hand, I feel the term “own” however eludes to a slightly different experience where we have the decision to work with frameworks that are tedious and need lots of care of every little detail or not.

I just put DD in there because I guess that’s popular.

In  summary.. It’s a really exciting time right now in the world of software development. Up till now most developers have had to focus on how to build applications instead of what to build. Choose wisely when it comes to frameworks for your next project so that you can focus on value, not plumbing. Only pick frameworks that require more attention when it’s absolutely the only way. (only when needed!)

Refactoring Legacy Code 101 (Dev Jam / Clinic)

Here’s a 90 minute workshop I’d like to lead at Agile 2009 on the developer jam stage.

http://agile2009.agilealliance.org/node/630

Level: Introductory

You’ve started your new project and “surprise” (not really) you’re dealing with legacy code. This unique workshop will focus on a few specific techniques that help make up the majority of what to do in improving legacy code design. Our forefathers gave us “Extract Method” and “Rename”. Cleaning up code is fun and challenging at times! When you achieve some level of code cleanliness or success you begin to feel the reward soon after, even during. A few agile-minded friends will be helping to walk attendees through a pairing adventure with plenty of typical legacy examples to work with together.

Process/Mechanics

• Short introductions (around the room)
• Determine pair teams (Ideally pairs of two but we’re flexible. People should feel comfortable.)
• Choose some classic legacy examples
• Identify code smells identified by Martin Fowler and others such as
  • Comments
  • Long method
  • Long parameter list
  • Large class
  • Dead or Future enhancement code
• Refactor away with techniques like
  • Extract method
  • Pull up/down method
  • Rename and make code expressive
  • Test Driven Development (TDD)
  • Fix code at the wrong level of abstraction
• Refactor with patterns like
  • The First Refactoring Step
  • Refactoring In Very Small Steps
  • Test Every Refactoring
• Refactor with principles like
  • Single Responsibility Principle (identified by Uncle Bob Martin)

Learning outcomes

• How to start refactoring
• Learn how to improve code readability
• Work more effectively with legacy code
• Leave the code cleaner and better
• Learn how to build more cohesive code

Primary target persona

Peter, Programmer

Other target personas

Chandra, Consultant

Ellie, Agile Explorer

Peter, Programmer

Rubin, Reluctant Agilist