Practices of an Agile Developer

On the flights down to FL, I was able to read a book that my team will be reviewing in the upcoming months, Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt.



The authors chose a style that I think captures the bipolar disorder shared by most cognizant software developers. It presents topics both from the perspective of the devil who might encourage us to "just duplicate this code, don't bother keeping the system DRY" and the angel who would give us a gentle reminder that "duplication is just a shortcut, and you will have to maintain both sets of code later on". It's amazing how many times you find yourself listening to that devil on a daily basis.

The book is very easy to read even if you don't have a ton of time to devote to it. Chapters are usually 30 pages or under and each one is broken into a number of atomic topics. 'Fixed Prices are Broken Promises' and 'Architects Must Write Code' were two which immediately struck a chord with me.

Additionally, the book has a ton of good quotes that should be tattooed on the back of our hands or at least put on a whiteboard in plain view. My favorites are "Blame doesn't fix bugs", "Negativity kills innovation", and "Blindly picking a framework is like having kids to save taxes".

All in all, a very good read and immediately applicable to developers both agile and not.

The Spring Experience - Day 4

Day 4 started much like Day 3 with another good presentation from Ben Alex regarding Spring Security. This session focused on the enhancements provided in Spring Security 2:

• Annotation driven security that allows a developer to specify required roles directly above a method declaration


• User management API for creating users and default implementations for JDBC and LDAP backed stores


• Hierarchical roles. UPDATE_ALL implicitly grants you UPDATE_CUSTOMER, UPDATE_ORDER, etc...


• Many other features like NTLM support, Portlet Security integration, and Automatic login page generaton

The second session I hit was RESTful web services in Spring by Arjen Poutsma. This session was a combination introduction to REST (Representational State Transfer) and highlight of facilities coming soon for developing clients and providers of these web services. It was great to see how similar the EndPoints Arjen displayed were to the Controller classes shown by Keith Donald earlier in the week in the RESTful web sites talk. Despite the number of disparate people working on these separate Spring based sub-projects, they are all adhering to a few common designs that make it very easy for a Spring developer to become productive in each of the environments.

OSGi was next up, presented by Adrian Colyer and Costin Leau. OSGi will provide Java application developers with a facility for deploying and managing separate versions of the same subsystems or libraries. The examples shown were somewhat contrived, but the concepts of OSGi are extremely powerful and immediately useful in at least two of the last three Java clients I've worked at. If you've ever found yourself trying to juggle version collision of components in your application, be sure to investigate OSGi.

Final talk of the conference for me was Spring Batch Internals by David Syer and Lucas Ward. They covered a plethora of the common issues facing batch processing systems and the solutions provided to these issues by Spring Batch. Batch processing seems to be the red headed step child of software development. Continually neglected while SOA and AJAX based applications win all of the adoration of the parents. Regardless, it is still a significant portion of the software projects out there and there are a wealth of common patterns that can be pulled up a level into a framework like Spring Batch. I'd go into more detail on it but I am seriously exhausted and my head hurts from the amount of information presented at this conference.

In a nutshell, the content at this conference was great and the majority of the speakers were very good. Only downside was that I didn't win an iPhone.

The Spring Experience - Day 3

Started off day three with Spring Security directly from it's creator, Ben Alex. The session provided a good intro to Spring Security but I felt bad for Ben as he got peppered with 4011 questions during the talk. Even with all of the tangents, Ben did a good job of presenting the core benefits of Spring Security. An example of it's power is to have a configuration that intercepts a method, say getEbayItemListing() and checks to see before execution if the user is authorized to perform this action. This can be a complex check that even validates if the current requester is actually seller of the item (instance level authorization). Then upon method completion, the after advice will mask the minimum sale amount by nulling it out on the object if the requester is not the original seller. With this being performed at the method level, it doesn't matter if the request comes from a website, web service, or other Java program. Very powerful.

Rob Harrop gave a talk on concurrency in Java that was very in depth coverage of the Java 5 concurrency objects. There was a ton of info in that session that I'll not cover here other than to say if you are developing in a multi-threaded environment in Java 5, please review the docs in the java.util.concurrency package.

The third session I attended was from one of my favorite tech speakers Venkat Subramaniam. Venkat covered Spring's facilities for integrating dynamic language objects like Ruby and Groovy classes into your Java framework as plain beans. I had no idea that this facility existed and as with most things Spring, it is accomplished very painlessly with a little configuration. A great use case for this is on the fly loading of dynamic processing logic (like rules) without stopping your application or server. Want some small dynamic rules processing without dealing with a full blown rules engine like JRules or JBoss rules? Here's your answer (and you don't need to wait for your company to deploy Java6). The second half of his talk covered using the GroovyObjectCustomizer object from Spring to implement a DSL. This also seemed relatively simple, but it was surprising how much more complex it was to implement in straight Java versus Groovy. I still prefer Ruby though.

The final talk before 500 pasty, flabby geeks descended upon the Hollywood, FL beach was Spring Web Services by Arjen Poutsma. I didn't gather a ton of info out of this session but a couple of nuggets were useful. The speaker advocated the opposite approach of XFire. Basically that you should start with the contract and work back towards mapping to your domain which I think makes sense in all but some of the more trivial cases. Additionally it seems that once you get the gist of Spring and the annotations provided in 2.5, moving from Spring MVC and WebFlow to something like Spring WebServices is rather trivial.

Time to hammock up!

The Spring Experience - Day 2

I focused on web framework related sessions today and came away with a wealth of knowledge and a long list of technologies to investigate further. Keith Donald gave a presentation on full stack web frameworks that was very interesting. He gave a very unbiased perspective on how frameworks like Grails, Rails, Django and others excel and lag with respect to about 10 criteria that comprise a "full stack" web framework (AJAX, REST, data binding, security, testability, etc...). He offered that Spring really doesn't have a full stack web framework, but instead acts as a foundation for them (Grails being built on top of it for instance). That is changing however as Spring MVC and WebFlow are adapting and integrating with some other technologies to really provide a complete offering.

I attended a few other sessions that focused on REST with Spring, AJAX offerings, JSF and WebFlow based apps, and Reasonable Server Faces. They all provided ton of information outside of my traditional area of expertise (middleware and persistence).

I think the most striking thing that I realized in these sessions though was how much of a huge step up in productivity there is in Spring 2.5. Annotations seem like a much better fit for metadata and being able to tell the container to only autowire a few certain dependencies right at their declaration point is immensely useful. Spring Security (formerly ACEGI) has gone from around a minimum of 150 lines of configuration to about 15 for the simplest cases by making use of these constructs. Spring 2.5 maintains backwards compatibility as well, so run, don't walk to the download if you haven't already.

The Spring Experience - Day 1

Day one of TSE was just registration, dinner, and a keynote by Rod Johnson but it was a great evening for a couple reasons.

Rod's keynote focused on the changing of the guard and disruption for the Java EE landscape. Most notably, his contention was that the committee driven process that we have now is largely failing. EJB 3.0 being just the latest example. OpenSource is a much more dynamic and user driven process that nearly immediately produces software and frameworks that a lot of users need. The committees by contrast are steered by people who try to sell application servers and move at the pace of a Columbus driver in a 1/2 inch of snow (aka very s l o w l y). I think his point here was right on and I think it might signal a very polar divide between users and committee.

Additionally, the conference passed out Rod Johnson bobblehead dolls complete with the pose from this book cover:



Classic!

Christmas Comes Early for Spring Fanboy

Wednesday I leave balmy Ohio (currently 38 degrees with showers) for Hollywood, FL (currently 82 degrees). Weather aside, I am extremely excited as I'm going there for the Spring Experience conference. As big a fanboy as I am with Spring, I'm somewhat daunted by the sheer volume of information that will be coming at me this week. There are 70 1.5 hour sessions crammed into 3 full days and I've got more than a passing interest in attending about 50 of them.

TSE is organized by Jay Zimmerman of NoFluffJustStuff fame, so I've got high expectations. I've been to NFJS conferences the last four years and every time I come back to work re-energized and armed with a bevy of new tools and techniques that are immediately applicable to my daily work. NFJS typically brings only noted authors and thought leaders in as speakers for these conferences and this one is no different with Rod Johnson, Juergen Hoeller, Rob Harrop, Ben Alex, Ramnivas Laddad, and a slew of other Spring contributors and experts speaking at the conference.

I'm going to have the laptop with me and battery willing, I'll be able to share my impressions throughout the conference.

Time to get packing. Now where did I put the old banana hammock...

The Long and Winding Road

I've started back up on a new phase of a project and it's rekindling my hatred for extensive documentation. I'm beginning to feel that most developers are just not inherently good at writing documentation, myself especially. We're just not wired that way and I think people generally despise doing tasks that they are not good at.

In this instance maybe it's just more painful because there is no challenge involved. It's a straight migration of an existing system so there is none of the excitement involved in finding out what the business domain entails and trying to mate technologies to the problems facing the users of the system.

Luckily we're always running an Agile project at QSI, and this particular client is open to documenting only what is needed and not wasting money on anything more. Unfortunately this brings up the question, what are the bare essentials when it comes to documenting a system? In this instance specifically, what is the minimum amount of documentation needed to capture the state of an existing code base? How valuable is any documentation? It's always the first thing thrown out the door when timelines get compressed and it's typically the last thing updated after maintenance or enhancements are performed on a system.

The first of many Spring kicks arse posts

In my opinion, nothing has brought life into Java development like the Spring Framework. Enterprise development in Java 4 years ago had me scratching my head. Why do I need to implement methods in this interface when I don't declare I implement it? Why do I need Entity Beans? Which of the 8 web frameworks should I be using? Why does it take so long to go from fixing a bug to actually testing that it worked? Spring has in some way, shape, or form answered all of these questions. Well except for the 8 web frameworks one.

Spring started with a couple of developers who were as frustrated as I was with the complexity inherent in Java enterprise development. Fortunately for our community, they were and are much smarter and driven than I am and they wound up with a set of tools that simplify almost every aspect of development in a Java enterprise. I think one of the keys of Spring's success has been focusing on simplifying advanced concepts and providing extremely useful tools out of the box. This example shows how Spring has simplified Aspect Oriented Programming which was a rather radical shift for Java developers in the early days of AspectJ. Additionally it provides something that 90% of all Java projects would want out of the box. Simple entered/exited logging and performance monitoring.



This code in it's current state will provide good trace logging for any bean named *DAO or *Service. Change or add the interceptor name to PerformanceTraceInterceptor and it will provide performance metrics using the JAMon performance monitoring utility. All of this provided out of the box with Spring. Stay tuned for more Spring fanboy-ism in the future.

Hibernate Hijinks

I've been tasked with optimizing some slowly performing transactions in a system that has been built upon Hibernate. Yesterday I ran across an interesting situation where a single transaction was resulting in 6 separate queries to the database. This may not necessarily be bad, but when the transaction was performing as slowly as it was, we needed to take whatever means we could to speed it up. What was unique to me was that we eliminated all but 2 queries, and we eliminated each one in very different ways.

1. Use the second level cache for largely read only data. There was a table that had slipped through the cracks of our investigation that will rarely be updated. A couple of configuration entries later and it will be stored in a second level cache and refreshed on a weekly basis instead of causing an extra query hundreds or thousands of times per day.
2. Eagerly fetch associations that are needed every time the transaction is called. The Criteria API in Hibernate allows the user to specify the fetch mode for every association, effectively overriding the default behavior provided by the mapping file. Setting the fetch mode to Eager for this association resulted in an extra left outer join, but it eliminated an extra query per result row.
3. Don't haphazardly access collections that are not needed by all of your clients. The transaction in it's previous state would call off to a dependent collection and call the size() method on it to determine how many child records were linked to the parent. This caused every child record in that collection to be loaded by Hibernate, even though very few of the clients actually needed to know the size of this collection. Adding a property to the incoming request to determine if the transaction actually needed to fetch that count and then doing it by simply executing a separate projection based query resulted in much speedier performance for all clients.

This scenario illustrates the flexibility of Hibernate and also the ease with which you can misuse this powerful framework. Always output the SQL generated by Hibernate in development, and make it a regular part of your design, develop, test cycle to inspect that SQL to ensure that it is doing what you think it is.

Hello World

I've finally been coerced into starting a blog. Thanks BHP!

Stay tuned for my thoughts on Beer, Software Development, Family, and Friends. Mostly beer though.