2008 : The good, bad and ugly

I am so glad 2008 is finally coming to an end. It was indeed a roller coaster ride for me from the beginning. Lots of ups and downs.

The highlights of 2008 were speaking at conferences, giving presentations locally, wrote 68 articles for Javalobby, the three part SoapUI article was #1, #2 and #8 at Architecture Zone and SOA Zone. I also had the opportunity to learn and use many tools.

Now coming to the bad. I always wanted to learn Maven; I even tried to use it a few times. I first tried to use Maven was when I reviewed the book “Java Power Tools”. It was a simple project, and everything seemed to work fine. However, I failed miserably when I tried using Maven for a few other examples. Instead of persevering through my problems I gave up.I started out wanting to become an expert on Maven; I ended up being just another Novice.

Up until my spell of laziness, I read about 2-3 books a month. Starting in about October, I began to lose interest in reading and reviewing books. But I do hope to reverse this trend in the next year.

I never knew that there would be something worse waiting for me in 2008. I used to feel so bad whenever I heard on TV that a company was closing its operations and all the employees were laid off. I felt so bad for them, had no idea that it was going to happen to me also.

When I heard that the company I was working was closing its operations and we were given just 3 days notice, I was devastated, shocked and stunned. I just can't even write how I felt in those few days. My world had turned upside down. I had planned a trip to India to visit my parents and had collected 80 hours of vacation. Lost all of them, the company had no policy of paying for unused vacation. Hah, they tell me at the end. It was just bad.

However, I am sure I had done some good karma, I was able to find another job in just 3 days. Thanks to one of my Friends who referred me.

Now that I have gone through the worst, I am sure I will be able to cope better next time if the same happens.

Anyway, what an incredible year 2008 was. Life is full of surprises; good, bad and ugly, and if and only if we could predict the future........

Stripes Framework - Worth Trying

When I received an email a couple of weeks back from "The Pragmatic Bookshelf" about the book "Stripes ...and Java web development is fun again", I completely ignored the same. I didn't want to learn yet another web framework, and write a detailed review either. I wish I had signed up for reviewing this book.

Just a few days back, I read the article on "TSS" about Stripes called "A Stripes 1.5 Test Drive". The one and only one thing which attracted me to this article was that other than the web.xml file, there wasn't any XML configuration files to be written and to maintain.

I read the article with great interest, and also read the documentation on the Stripes web site. Next, downloaded the libraries and was able to get it working with the many samples I had in minutes. Yes, trust me just minutes.

So, I decided to do something even more interesting which I always do and surprisingly it worked like a charm. I am planning on writing a detailed article about how I was easily able to use Stripes with my existing sample projects.

Have you used Stripes? What do you think about the same? Isn't it a great framework?

Stay tuned about my article as well, I will keep you posted sooon.

If you haven't used Stripes, give it a try. You will be really surprised to see how easy it is to use Stripes.

The Three Pillars of Continuous Integration

Continuous Integration commonly known as CI is a process that consists of continuously compiling, testing, inspecting, and deploying source code. In any typical CI environment, this means running a new build every time code changes within a version control repository. Martin Fowler describes CI as:

A software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build to detect integration errors as quickly as possible.

Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

While CI is actually a process, the term Continuous Integration often is associated with three important tools in particular. As shown in the screen above the three pillars of CI are:

1. A version control repository like Subversion, or CVS.

2. A CI Server such as Hudson, or Cruise Control

3. An automated build process like Ant or Nant

So, let’s look at each of these in detail:

Version Control Repository:

Version control repositories also known as SCM (source code management) play a crucial role in any software development environment. They also play a very important role for a successful CI process. The SCM is a central place for the team to store every needed artifact for the project. It is mandatory for the teams to put everything needed for a successful build into this repository. This includes the build scripts, property files, database scripts, all the libraries required to build the software and so on.

The CI Server:

For CI to function properly, we also need to have an automated process that monitors a version control repository and runs a build when any changes are detected. There are several CI servers available, both open source and commercial. Most of them are similar in their basic configuration and monitor a particular version control repository and run builds when any changes are detected.

Some of the most commonly used open source CI servers are; Cruise Control, Continuum, and Hudson. Hudson is particularly interesting because of its ease of configuration and compelling plug-ins, which makes integration with test and static analysis tools much easier.

Automated Build:

The process of CI is about building software often, which is accomplished through the use of a build. A sturdy build strategy is by far the most important aspect of a successful CI process. In the absence of a solid build that does more than compile your code, CI withers. With automated builds, teams can reliably perform (in an automated fashion) otherwise manual tasks like compilation, testing, and even more interesting things like software inspection and deployment.

Now that we have seen the important tools in our CI process, let’s see how a typical CI scenario looks like for a developer:

* CI server is configured to poll the version control repository continuously for changes.
* Developer commits code to the repository.
* CI server detects this change, and retrieves the latest code from the repository.
* This causes the CI server to invoke the build script with the given targets and options.
* If configured, CI Server will send out an e-mail to the specified recipients when a certain important event occurs.
* The CI server continues to poll for changes.

Why is CI Important?

This is one of the most frequently asked questions, and here are a few points to note about this powerful technique:

* Building software often greatly increases the likelihood that you will spot defects early, when they still are relatively manageable.
* Extends defect visibility.
* CI ensures that you have production ready software at every change.
* CI also ensures that you have reduced the risk of integration issues by building software at every change.
* CI server can also be configured to run continuous inspection which can assist the development team in finding potential bugs, bad programming practice, automatically check coding standards, and also provide valuable feedback on the quality of code being written.

Over the past several months, I have assisted several companies in implementing CI. There was a little bit of resistance from the developers in the early stages when we implemented continuous feedback. But, never heard a single negative comment about this approach. If you already have a version control repository and automated builds, you are very close to the CI process.

Download one of the open source CI servers, configure and setup a simple project. It should take less than an hour if you have automated build scripts. Start adding additional features like code inspections, generating reports, metrics, documentation and so on. Most important, send continuous feedback to your team.

Give this process a try, you sure will be surprised to see how effective it is. And, as always share your thoughts, concerns or questions.

Spring vs EJB War : Will It Ever End?

I can't believe I am even writing this post. My article at Javalobby "EJB 3.1 - EJB New and Improved", became the place for a few people to make it a Spring vs EJB war.

I received several emails asking about my opinion. I did comment saying

As long as it is a healthy discussion on Spring Vs EJB and not a war of words between two individuals, I have no problem at all.

There was one person who went to say that "I was gaining more popularity with this article". I have been writing articles from many years now. Every time I have learnt something new or interesting, I have tried to share those with my community. I don't need such fame.

Of course, it had no effect, and the discussions took a completely different route.

I had seen such war of words and arguments when it came to Java vs .NET, but never had heard or read about two great and very useful framework and specification. I had one former colleague who went to such an extent saying:

I will jump off the bay bridge rather than work on Java.

I didn't understand that statement than, and don't even now. And now with this discussion taking a route which I had never imagined, I am even more confused.

What are your thoughts? Why do developers go to such extreme? Isn't it another language or framework? Don't we learn new languages when we go to different countries however hard it may be? Why we as developers have such hatred towards other technologies?

Interesting books from Apress

I received an email yesterday from the contact I have for Apress about some new and interesting books. Some of these books are going to be available in January 2009, and some in late December.

Here is a sneak peek into the list:

978-1-4302-1877-7 Spring Persistence — A Running Start Fisher, Paul Jan 2009

978-1-4302-1648-3 Pro Spring Persistence with Hibernate Seddighi, Ahmad Jan 2009

978-1-4302-1881-4 Apache Batik: SVG Toolkit Kumar, Ajit Jan 2009

978-1-4302-1926-2 Grails Persistence with GORM and GSQL Fischer, Robert Jan 2009

978-1-59059-995-2 The Definitive Guide to Grails, Second Edition Rocher, Graeme Jan 2009

978-1-4302-1600-1 Groovy and Grails Recipes Jawad, Bashar Dec 2008

978-1-4302-1055-9 Practical RichFaces Katz, Max Dec 2008

978-1-4302-1883-8 Eclipse Rich Ajax Platform: Bringing Rich Client into the Web Lange, Fabian Dec 2008

And here is a list of books which have already been published and is available for you to purchase.

1. 978-1-4302-1061-0 Beginning Java™ ME Platform Rischpater, Ray Oct 2008

2. 978-1-4302-1624-7 The Definitive Guide to Spring Web Flow Vervaet, Erwin Oct 2008

3. 978-1-4302-0963-8 Beginning Database-Driven Application Development in Java™ EE: Using GlassFish™ Vasiliev, Yuli Sep 2008

4. 978-1-59059-737-8 The Definitive Guide to Apache MyFaces and Facelets Wadia, Zubin Sep 2008

5. 978-1-4302-1057-3 The Definitive Guide to SOA: Oracle® Service Bus, Second Edition Davies, Jeff Sep 2008

6. 978-1-4302-1031-3 Beginning Google Web Toolkit: From Novice to Professional Smeets, Bram Sep 2008

7. 978-1-4302-1009-2 Pro Java™ EE Spring Patterns: Best Practices and Design Strategies Implementing Java EE Patterns with the Spring Framework Kayal, Dhrubojyoti Aug 2008

8. 978-1-59059-921-1 Pro Spring 2.5 Machacek, Jan Aug 2008

9. 978-1-4302-0973-7 Practical API Design: Confessions of a Java™ Framework Architect Tulach, Jaroslav Jul 2008

10.978-1-59059-986-0 The Definitive Guide to Terracotta: Cluster the JVM for Spring, Hibernate and POJO Scalability , Terracotta, Inc. Jun 2008

11.978-1-59059-979-2 Spring Recipes: A Problem-Solution Approach Mak, Gary Jun 2008

12.978-1-4302-1045-0 Beginning Groovy and Grails: From Novice to Professional Judd, Christopher M. Jun 2008

Article Recursion

Sometime in late October, I wrote an article on code coverage for Javalobby called "Is Code Coverage Important?". This article had some very interesting comments. This article was quoted in many blogs.

And, just yesterday my friend Andrew Glover wrote an article in his The Disco Blog called Code coverage coterie confab.

The article was also quoted by another blog as well. The article is "Code Coverage, what is it good for?".

What are your thoughts about code coverage? Do you use it? Share your thoughts?

EJB 3.1 - A Brief Look

Just yesterday, the article I wrote on EJB 3.1 - EJB New and Improved! went live on Javalobby. In this article, I examine a few interesting topics being considered in the new and improved version of EJB such as optional Session Bean Business Interfaces, Global JNDI Names, Singleton Session Beans, and the EJB 3.1 Embeddable Container.

The article has generated very interesting discussion from many readers, and there are very good comments as well. Javalobby also posted it as a Spotlight Feature.

I used the latest version of OpenEJB which has support for quite a few features of EJB 3.1 to work out all the samples. I was able to unit test all the samples as well with just a click of the button in Eclipse IDE. Just amazing for how EJB's have come.

Any Code Analysis Tools for Groovy & Grails?

I had an interesting comment from one of the readers at Javalobby. To quote him:

Hello Meera,

I was just wondering if we have a code analysis tool in the market that integrates and works well with Grails & Groovy? Your response is very much appreciated and valued.

Many Thanks,

Navatha

I have used code analysis tools for both Java & .NET, but none for Groovy until now. I am pretty sure FindBugs which analyzes the byte code might work for Groovy and Grails. All other tools inspect the source code, so we might not be able to use any of them.

Have you used any such tool with Groovy & Grails? Any ideas? If so, please share your thoughts.