Book Review : JBoss in Action

The detailed chapter-wise book review for JBoss in Action has been published on Javalobby yesterday. I am really really surprised by the comments that review has received; 123 comments in less than a day. Of course, DZone has partnered with Manning to give away a free book. Most comments are for the free book giveaway.

I have been getting free books for almost 5 years now. It is not actually free, I do spend a lot of time reading and writing detailed reviews. And, of course I pick and choose which books I want to read.

However, I was surprised to see so many using JBoss AS. So, fellow developers, if you are using JBoss and want a free copy of the book, leave a comment. You might be the lucky one to get the book also.

JBoss in Action : A Sneak Peek

Since this is my first post for 2009, WISH YOU ALL A VERY HAPPY NEW YEAR!.

I started reading the book "JBoss in Action" in October 2007 just before I did the interview with the authors of this book for Javalobby titled "An Interview with JBoss in Action authors Javid Jamae and Peter Johnson. I kept asking the authors and also the publishers every few months if the PDF I was regularly getting the final version. It took almost 1 and 1/2 years from the day I started reading this book. Anyway, the book is finally out.

The book is just amazing. The authors have packed so much detail in this book. JBoss in Action is the first book I have read to focus in detail on how to use the JBoss 5 application server from installation to configuration to production development. The topics on security are also very well covered.

This book is divided into four parts, containing 15 chapters and two appendices. This books covers 5.0.0.GA version of JBoss AS, the chapters on the portal are based on the 2.6.4.GA release running on JBoss AS 4.2.2, and were later verified with JBoss AS 4.2.3 and Portal 2.7.0.

Part 1 covers JBoss AS basics like configuring the server, deploying and undeploying applications and a brief overview of security.

Part 2 shows how to configure, deploy Java EE technologies. There is a complete chapter messaging and web services as well. Very interesting chapters.

I wasn't sure why the authors decided to dedicate Part 3 entirely to JBoss Portal. I did evaluate JBoss Portal long time ago, no real experience here. I would have loved to see this part replaced with two chapters on JBoss Seam. The earlier version of PDF I read had JBoss Seam, I guess the authors had their reasons to remove those chapters.

Part 4 : Going into Production was very interesting. Especially the topics which cover Clustering and tunning the JBoss AS are very well written.

I was a big fan of JBoss until 2007. Once we switched to Java 6, I had big trouble using JBoss and EJB3 with Java 6. So, I haven't used JBoss since than. But, I have seen many of my clients using JBoss.

It is very simple to rate this book: everyone who uses JBoss AS should own and read a copy.

Stay tuned for a detailed chapter wise review and the rating on Javalobby.

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.

Terror in India

The terror attacks in Mumbai(Bombay) have made me so sad and mad from the past 2 days. Having had holiday on both Thursday and Friday, and watching this ongoing fight live on CNN, has troubled me even more. Like they say "Picture says a thousand words", seeing the images brings tears into my eyes.

I just don't understand how these terrorists could just go off and kill all the innocent people. They even went into a Maternity and Childrens hospital, can you believe how cruel these terrorists are? What might be going on in their minds? How do they get such hatred toward people?

Reading all the online stories makes me even more sad. Just unbelievable. With more than 1 billion people, how do we suspect any one person of this motive?

Who is responsible for the bloodshed? Can anyone stop this bloodshed at all?

If there is God, I pray to him sincerely to put some common sense into the brains of all these terrorists.

Why Pair Programming Should be made MANDATORY

Pair Programming is one of the most controversial topics discussed time and again. In the beginning I was a bit hesitant about this practice, but slowly I got used to this and really enjoyed working with another developer. However, when in one of my projects, I was the sole developer for nearly months, I knew how important it is for us to really have another pair of eyes. The few months I worked alone, I was not myself at all. Even though I had the opportunity to learn all the latest and the greatest technologies, I just couldn't take it anymore. I had to resign and so did I.

Now that I am reading the book "Pragmatic Thinking and Learning", I was able to clearly understand why I felt the way I was in that Job working alone. In Chapter 4: Get In Your Right Mind Andy explains about Pair Programming and why it is important. He first explains about the R-Mode and the L-Mode of our brain. So, you may ask what is R-Mode and L-Mode:

If you're looking for global, holistic patterns, you need R-mode. If you need to analyze parts and look into detail, then you need a more L-mode approach. For most of us, this level of specialization is how it is. R-mode sees the forest; L-mode sees the tress.

For pair programming, Andy very well explains that we need to get both R-mode and L-mode working together, and the only way to do this is by having your L-mode work with another person's R-mode or their R-mode work with your L-mode.

Again,to quote from this excellent book:

The navigator is free to see these larger relationships and the larger picture, And most of the time, you cannot see these relationships if you're driving. So if you aren't pair programming, you definitely need to stop every so often and step away from the keyboard.

This doesn't mean that you should pair all the 8 hours you are working. I suggest we should pair when we are working on a critical piece of our module, when we are trying to fix bugs, learn a new language, writing build files. Always better to have another pair of eyes, and another mode of brain.

What do you think? Are you using Pair Programming at all? What are your thoughts?

Clean Code : MUST Read Book

Just yesterday, I posted a brief review of Clean Code: A Handbook of Agile Software Craftsmanship written by Robert C. Martin. at Javalobby.

What an amazing and interesting book it is. Around 4 weeks back, the book was at my front door when I came back from work. The next few weeks were quite hectic and I had no time to even open the book. Finally, two weeks back I decided to just browse the contents. I first read the foreword, which again is amazing. That was the beginning, I just couldn't stop.

This time since I hadn't signed up to review this book, I thought I should try a different format of writing the review. I mentioned 5 reasons why this book was worth reading, simple ones. And, later at the end summarized what I had learnt from this book. I guess it stuck a cord with the readers, and there were some good comments as well.

Take a look at the review, and try to get this book if you read or write code. Trust me it is worth the money and the time.

P.S: I sent an email to the publisher to find out who had shipped this book, and my contact at Pearson had sent the book. I did thank her profusely for sending this book along as well.

Maven: The Definitive Guide--New from O'Reilly

For those of you who are interested in learning and using Maven as your build tool, O'Reilly has just released a book called "Maven: The Definitive Guide".

To quote from the email I received:

For too long, developers have worked on disorganized application projects, where every part seemed to have its own build system, and no common repository existed for information about the state of the project. Now there's help. The long-awaited official documentation to Maven is here.

Maven: The Definitive Guide (O'Reilly, US $34.99) serves as both an introduction and a comprehensive reference for Apache Maven, the tool that will transform the way an organization builds and manages application development. Written by members of Sonatype's engineering team—including Jason van Zyl, the creator of the Maven central repository—the book explains why Maven is replacing Ant as the tool of choice, not just for open source Java projects, but for applications in many other languages, including Scala, Ruby, and Groovy. The book also provides the first in-depth overview of Maven 2.

The first half of this book introduces Maven by example, with a series of real-world, multi-module applications that can be used as templates. The second half serves as a reference to a wide range of topics, teaching readers how to:

* Get started with Maven
* Understand the Project Object Model (POM)
* Integrate Maven with Eclipse
* Master advanced dependency management
* Use the Nexus repository manager
* Integrate Maven with Spring and Hibernate
* Write and use Maven plugins
* Generate a project website
* Customize a build with properties
* Use build profiles and profile activation
* Create and use Maven assemblies
* Develop with Maven archetypes

I did try learning Maven several times, and each time got lost in the POM. It sounds like this book is for people like me, but I already have quite a few books in my list. And with this one for me to review, I sure will have to try all the examples, and there isn't just enough time right now.

What's FuseMetrics?

FuseMetrics is an open source tool written in Groovy, which can parse the reports of many of the most common analysis tools:

* Junit
* TestNG
* JDepend
* Checkstyle
* PMD
* JavaNCSS
* FindBugs
* Simian
* Clover
* Cobertura

It produces summary metrics and graphs - sparkline and histograms.

No matter what build tool you are using, Ant, Maven, Gant or Gradle you can use FuseMetrics.

It’s completely open source and we have used it for many of our clients. To read more about FuseMetrics, take a look at the article I wrote at Javalobby here.

Try it out and give us your feedback.

What's Gradle?

My article a few days ago in Javalobby "Ant or Gant" had some very interesting comments. One reader posted about a new build tool which I had never heard of called "Gradle". To quote his comment here:

gradle is another java+groovy based build-tool
IMO gradle is clearly superior to gant.
it implements support for dependency-management
and some other really smart concepts.
check it out: http://www.gradle.org

As always, I didn't waste anytime once I saw this comment, and read the Getting Started and also Users Guide. It sure looks interesting. I will download Gradle and give it a try and share my experience. In the mean time:

Have you used Gradle? Share your thoughts?

Ant or Gant?

If you have complicated build files and have no clue what and how to refactor these files, check out the article I wrote at Javalobby called "Ant or Gant?".

This article explains the following in detail:

1. When to choose Gant?
2. What's Gant?
3. Getting Started with Gant.

Of course, you should know Groovy before you decide to runaway from Ant.

Are Software Developers in America Lucky?

This isn't a controversial post. Trust me. Let me give you a small background before you start freaking out.

I have been in the software industry for a long time now. Every time someone moves back to India, and at the same time I chat with someone in India or UAE, I have this dreadful conversation. Read on:

Question 1: Meera, when are you coming back to India?

Meera: I have some family responsibilities, I am not sure I will be coming back soon.

Question 2: You should, the salary they pay here is amazing, do you know?

Meera: Yes, I do. But, I am really happy and content with my salary here as well.

Question 3: How is the working hours there?

Meera: I work 5 days a week if I am within the DC area, and if I am travelling I work 4 days.

Question 4: We work almost 10-14 hours everyday, do you know that?
Meera: Yes, I do. I have also worked when the project was due, and we had tight deadlines.

Question 5: See, that could be one reason why you will not fit in here?
Meera: I don't know, I really know how to manage my schedule and manage work which is assigned to me. So, I don't see any reason whatsoever to work 10-14 hours everyday. I sure wouldn't work at a place where my Manager would expect me to work like that.

Question 6: You guys working in America are really Lucky.
Meera: I don't know, when it comes to work, I can speak for myself and the team with whom I have worked and most worked hard. So, I am not sure why we are lucky?

At this point, I knew the conversation was taking a wrong path, and decided to logout of IM, and later saying that I got interrupted. This has not happened to me once or twice, but many times over the past 2 years. I should admit, I just can't argue at all.

But, I am still shell shocked. Why do developers in India have to work 10-14 hours? Is it really needed? And can you stay focused working 10-14 hours a day? Do you still have the ability to concentrate after 8-9 hours of work? I don't know? I should try working for a month or so in India just to see how things are now, don't you think so?

What are your thoughts? Are we developers working in America really lucky? What do you think?

I remembered the quote from Thomas Jefferson, which says

I'm a great believer in luck, and I find the harder I work the more I have of it.

I guess that sums up why American Developers are Lucky, right?


P.S: If you haven't yet noticed, I am an Indian and proud to be one as well. But, I just don't understand the logic behind working more than 40 hours every single week; and hence this post.

Update: The only reason I posted this article was to know why our fellow developers were working long hours, and to know their state of mind. And it was posted in good faith. I am seeing that the comments are taking a completely different direction, and I just don't want to start a war of words. I am not going to respond/approve any anonymous comments.

Is easyb Easy?

Yes, that's exactly what you will find out by reading the article I posted a few days back at Javalobby. easyb is a BDD framework for the Java platform written by Andrew Glover. And, I learnt quite a few things from Andy as well about easyb. This artcile goes in detail about how to write a

1. Scenarios within Stories
2. Run these Stories from Ant
3. Generate a report.

Check out the article to find out what my verdict was. Also, give it a try and let me know your verdict as well.

Javadoc or Doxygen?

If you have been thinking about how to improve your technical documentation, than you have to take a look at the article I wrote last week at both Javalobby and also Test Early.

Here are a few reasons why you should consider using the Doxygen:

1. With Javadoc you have to remember all the HTML tags, you need to embed within your code comments. However, with Doxygen code comments are much more concise and polished, without the need for any HTML.

2. Doxygen can also generate a variety of diagrams, we will take a look at some of them later.

3. Doxygen also provides a structured view on the source code. As I mentioned in 2 above in the form of various diagrams, cross-referenced and syntax highlighted code.

4. You get all the above benefits even if the code does not have any comments at all.

5. Last but not the least, Doxygen is a documentation system not for just Java but also for various other languages like C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#.

The article shows in detailed steps the following:

Step 1. Download, Install Doxygen.

Step 2: Configure Doxygen.

Step 3. Doxygen and Ant.

Step 4. Integrate with Hudson.