Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

The full Java life: Interview with Carlus Henry, independent consultant

On old and new approaches to Java programming

By Matthew Heusser, JavaWorld.com, 09/26/12

  • Print
  • Feedback
.

Page 4 of 6

Finally, I happened upon git-svn, which is the native support that Git has in order to interact with Subversion. I took the plunge and started using Git locally to interact with Subversion. I have written a series of blog posts on this topic, so I won't go into it in too much detail. However, using Git has allowed me to branch and merge multiple feature branches on my machine. I have even purposely checked-in code that doesn't compile locally on my branch, just in order to remember where I left off. It has been a lot of fun using Git, and when asked by my friends what I use for a Subversion client, I always say git-svn.

Matt Heusser: What technology changes have most impacted your approach to writing software since you started coding in 2000?

Carlus Henry: I was first introduced to Spring in 2006, and have pretty much used it on every single project that I have been on since then. Since I had started my professional career in Enterprise Java, I really did not notice how complex the applications that I was developing prior to adopting Spring were. In order to adhere to the J2EE specification, and provide something as simple as remoting capabilities, where external applications could call functions on my application, I would have to create three separate Java interfaces for the business component that I wanted to expose. Spring brought a lot of great ideas, including dependency injection, declarative transactions, and a host of other tools that just made developing Java applications more simple.

Recently, I have been challenged to reexamine the Java EE specification. Much to my surprise, it has really come a long way. It now includes dependency injection, minimal-to-no XML configuration, and it's a cinch to create Java EE applications that support remoting, especially through web services. Before, Java EE 6, I would have chosen Spring to build an enterprise application, every time. Now, when considering which platform to use to build applications, I would seriously consider using Java EE 6.

A developer's toolbox: Carlus Henry

 

  1. Clean code
  2. Roll-your-own code generators
  3. A local database
  4. Distributed version control

Matt Heusser: We talked earlier about testing; has your approach to unit testing changed?

Carlus Henry: Over the past couple of years, I have changed my testing style a lot. After being introduced to test-driven development, I became a unit testing fanatic. This is a great skill to have. Testing your individual classes at the method level for a number of years have given me a lot more confidence in the code that I write, as well as taught me a lot about object-oriented programming. Many a times I have used object inheritance and dependency injection in order to test corner cases.

Today I am still a fan of unit tests but recently I have found them lacking in an important area -- requirements. Sure, you probably have heard the claim that unit tests are really "executable requirements." While this is true, they really only benefit the developer. There is not going to be an end-user who is going to read your source code in order to discover your "executable requirements." I believe that this attitude toward software development puts up a barrier between the developer and the customer. These days I prefer behavior-driven development to fill this gap between tests and requirements.

  • Print
  • Feedback

Resources