Friday, July 25, 2008

Postcard from Ile Sainte-Marguerite

Still on vacation ;)



Thursday, July 24, 2008

Postcard from Monaco

I'm on vacation so I'm just posting some rubbish :)
Enjoy!


Wednesday, July 23, 2008

Are development frameworks worth anything?

After graduating from university every decent software development undergraduate is able to write computer programs in many languages. Most probably the list will include C, C++, Java, Ada, Pascal (Delphi), PHP, Shell scripts, JavaScript. Depending on the university the list could be longer or shorter and programming skills would also differ. And those guys are able to write almost everything in every enumerated language (starting from HTTP servers up to transactional systems and applications computing shortest paths between two or even ten cities in Europe).

How is it possible that even guys who graduated with honors know almost nothing when they start working for companies for their first assignments? Is it because companies and already existing projects use frameworks (transactional, middleware, whaterverware)? Does it make sense to invest in using frameworks? Aren't they only the source of problems and maintenance horror? Isn't it better to write your home-grown tiny little framework that will do good - you don't need full blown framework because your project is too small now?

I'll try to answer some of these questions and other questions regarding development frameworks.

A bit of history


I started working before the end of fourth year (out of five) at my university in a small development company. Although it was a small company it had really fancy products in its portfolio all developed in Borland Delphi. My task as a "fresh" and highly skilled student was to port some of the functionality from those products to the Java technology and expose it as a web application. My only choice was J2EE stack: Apache Tomcat, Java Servlet, JSP, JDBC and maybe something more. I knew MVC design pattern and I knew all mentioned technologies. I started developing the system and it was working well until it reached its critical mass i.e. adding new features meant copying-pasting a lot of code. OK - I was not the Java and object-oriented prodigy at that time but everything I touched simply worked. Yet, it was not very easily extensible.

My first framework
Struggling with such problems I found Struts that solved 99% of my problems, literally. This framework was what I was looking for. I even wanted to write something like that by myself but I found it first. Struts 1.x saved my life and my project at that time. 1:0 for the frameworks.

It's time to learn more
After couple of months I moved to a bigger and more prestigious company for a trainee position. Some time before that happened I started interesting in Aspect Oriented Programming (AOP) - more specifically AspectJ. This AOP-thing seems unimportant in this context but it really isn't. You will see it shortly :)

In my new, bigger, more prestigious job there was a system that we were supposed to develop as a standalone GUI application in SWT and JFace. Middleware components were based on Spring Framework and Hibernate - two big and full-blown frameworks I didn't know at that time. I had to learn them and be an expert in them.

Is it so simple?
As I was extremely fast-learner then (I really think I was better in learning then that I'm now :) I caught Spring and Hibernate in minutes and my colleagues also. It doesn't mean we were good at Spring and Hibernate just like that. I still didn't understand many things but I was able to be a leading developer in this project (after over one year) and deliver requested features.

Although we learned Spring very fast there was a part of it not all of the guys were able to catch - it's name was AOP. It was very important part of this framework we were using extensively - and if I weren't learning AOP before I could have had big problems at work then. This means that even if you know how to use the framework and you're good at it you don't have to know it from the inside - although it can really help you in case of any problems.

Was it worth?
After all those years I see how Spring together with Hibernate made our lives easier. We were able to deliver new features really really quickly. The maintenance of the system was not so bad at all and I know that if we developed this system using pure JDBC and home-grown ORM stuff we would not deliver this system to the customer or would deliver it much later.

What now?


When I start a new Java-based project I almost always assume that we would need Spring Framework, Hibernate, Struts2, JFree Chart, Lucene, iText, Jakarta POI, Velocity, ........................................... And most of the time we need all of these.

The real learning
I hope you see what I mean - you have to know a lot of stuff and you cannot know it all after you leave your school. Learning all those frameworks and libraries took me years and I still know nothing. There is still a lot of things I have to learn but isn't it fun? It is - for me. Our job (software developer) is very difficult, we have to learn enormous amount of things. Not just for the sake of learning - we have to use our knowledge, be creative and produce something from nothing. Smart people are not enough - you need here smart, knowledgeable and skilled people.

The real learning starts after graduation when you know programming languages but you don't know frameworks. Frameworks are like languages themselves - and they make developer's live easier (after they make his/her life much more difficult).

Conclusions


Does it make sense to learn all of this, to spend so much time on learning frameworks? Does such investment pay off? Isn't it better to write something simpler and quicker but on your own? You can multiply such questions and each similar question is an excellent question.

Try it yourself you'll see how difficult it is
If you tried to learn and then apply at least one framework in your professional life you should know how horrible it can be. You go through tutorial (torturorial :)), copy the code, set all properties, start the example and.... java.lang.NullPointerException. Yes - you know this very well :) After at least few days and many WTFs you finally solve the problem but wait! Here is another one...

Until you excel the use of the framework of your choice you can get mad many times. You will lose a lot of time and nerves and you still cannot be sure that the use of your framework will do good to your project.

Invest or not?
As always there is no simple answer. Definitely it's worth investing some time and money into investigation. If the framework you want to use makes the development or maintenance easier the decision should be obvious. If the learning curve in order to excel the framework is bigger than the value of using the framework you should consider not using it.

The big disadvantage of frameworks is the learning curve - you have to learn it and to be smart enough to understand it - not everybody is capable of doing this and doing this for such a long time. Many team leads and project managers don't like that risk and they invest in crappy home-grown solutions - that doesn't pay off in the long run.

Answer?
If your project is to write couple of JSP pages with maybe few Servlets it really doesn't make sense to use Struts or Spring. It may make sense to write your own two- or three-classes tiny little framework that will work after couple of hours - not days or weeks of training.

After all using frameworks pays off and is worth investing time and money - of course if you use appropriate frameworks to your project and your project reaches its critical mass. Your application will be much more maintainable and extensible (maybe also more testable and portable). Your customer will be satisfied and your employees will be smarter and more skilled. These are the reasons you should consider development frameworks very seriously.

Do you have different view on frameworks? What do you think - is it worth investing your time and effort in learning how to use them? I would be glad to know your opinions.

Originally published on AgileSoftwareDevelopment.com

Thursday, July 17, 2008

Code coverage: a tool against unused and untested code

I'm an agile developer because I write my code incrementally i.e. only what I need today. I usually start writing the code by writing Unit Test - it really works and it really helps me understand what should be implemented and how system should behave (I will leave the subject of convincing people, who are new to unit testing, to do "write-test-first" for a separate post). OK - I usually do this but sometimes it's difficult or I'm just too impatient to see the result and start with the implementation and write unit test later. How do I know which packages/classes/methods are tested and which are "not touched" by any single unit test? How do I know that my code is really used somewhere by other parts of the developed system? This is the work for code coverage tool.

What is code coverage
According to Wikipedia article code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing. For me as an agile developer code that is not tested is not used and not needed. I mean it! If the code is not tested and not used it is the code that "will be needed in the future". I don't accept such code - if I need something in the future I will simply add it - if I don't need something at this moment I have to remove it (because not used/tested code may contain bugs).
If some part of my code is not tested it means that I don't need it - that is true in almost 100% of cases. This way code coverage tool shows me not only which parts of the software are tested but also which parts of the system are not used and can be removed.

Example
I use Cobertura code coverage tool that calculates the percentage of code accessed by tests. Let's take a look at this simple project containing 19 classes:

This report does not tell many things - useful information is that line coverage of the whole project is 70% and the branch coverage is 25%. The only conclusion you should get looking at this report is that the project is not well tested (or contain some unnecessary code).

If you navigate deeper and take a look at some classes you could see something like this:

This report tells me as a developer that e.g. getDocs() and setDocs(String) methods are not visited during unit testing. I assume that these methods are not needed thus I remove them (!). You should consider doing the same.
If it occurs that you need those methods write unit test that covers this class and those methods immediately.

Bad example from the past
I have very good example how not to write code and how code coverage tool can help you catching such problems. In the past when I had to write some exception hierarchy I started writing exception class with implementing all constructors from the superclass i.e. java.lang.Exception - just in case ;) Here it is:

This means that I had 4 constructors in each exception class but was using usually only one... Why to write the constructor that nobody wants? There is no need to do it!

Consider following Cobertura report:

This is how I write code now :) I start with the unit test and add the code incrementally only when needed. And Cobertura (code coverage tool) helps me assuring myself I'm using my code.
This way I'm sure at least two things:
1. My code is well tested (maybe not well tested but at least I know to what extent it is tested)
2. I've written only the code that is needed - there is no "dead" code

Conclusion
The best way to write code is to start with unit test and to write it incrementally - implement ONLY what you need today. If you are not feeling good with test-first principle and you prefer write an implementation first (you shouldn't) make sure you use your code. One way to do this is to employ code coverage tool (open-source, or commercial ones like Clover). Such tool will show you which parts of your system need testing or simply which parts of your system are not used and can be removed. After each build I check code coverage report to see how much work I have and I really don't like red color (I love green instead :)

What do you think about usefulness of code coverage tools? How do you write your code - are you really writing your code incrementally? How do you ensure that?

Originally published on AgileSoftwareDevelopment.com

Tuesday, July 08, 2008

How to ensure code quality?

I'm co-developing big Java project that does what it should do but lacks the style and conventions. The code is hard to read, understand and maintain - and it is Java! I'd like to write what I discovered in the code, project configuration and what are my recommendations on ensuring high(er) code quality.

In my previous post I mentioned tool called FindBugs that finds common Java problems that can occur during runtime and will be difficult to find and debug. One of the comments to this post opened my eyes to what I'm doing currently and how I can fix current status quo. And the comment was about PMD tool.

PMD
There is a tool called PMD which scans Java source code and looks for potential problems like: Possible bugs, Dead code, Suboptimal code, Overcomplicated expressions, Duplicate code.
PMD is configured in the project I currently contribute to but I was somewhat shocked that although the code is totally, absolutely crappy PMD doesn't show any problems. Hmmmmmmm. I was shortsighted because I didn't see the fragment invented probably by some kind of "genius":

public class ... extends ... { // NOPMD


Well, the fragment in question is // NOPMD which tells PMD: "Don't check this class". It's not funny!
Fortunately this was not the case for most of the classes. Nevertheless I still didn't know why my PMD plugin is not alarming me about the problems. I checked whether it is enabled for my current project in Eclipse IDE. Voila! It was not! The guy who helped me configuring the project disabled it and when I asked why he said that if I enable it I will be probably unable to compile the project. It's really not funny :) Or.... is it?
Anyway - he was right! When I enabled the PMD for the project I was really unable to compile it...

No comments!

PMD problems
I've never used PMD before and I think that was a good choice. Why? I enabled it for some classes I worked on to see why people disable it - I hoped to find some clues. I didn't wait long - actually I didn't wait at all. Consider this snippet (class' method - context is unimportant):

String value = (String) entry.getValue();


What warning could you get for this piece of code? I got this one: Local variable 'value' could be declared final. WTF?! OK - I added final keyword before value variable declaration to see what will happen. #$%&@! - I got another warning: Avoid using final local variables, turn them into fields. So, should I declare my local variables as final or not?!
Who configured this PMD? Or is it default configuration? I don't care - with such warnings I really understand people who simply disable this tool - it's insane!

Of course, everything is a matter of configuration but I'm already pissed off with PMD as a Eclipse plugin and am not going to use it anymore. On the other hand I'm always using PMD as a Maven2 plugin and it works fine - I used to get quite reasonable comments there (I'm not getting them anymore because they are already fixed ;)

Checkstyle
I've never used PMD before but I used Checkstyle instead (currently I'm using version 4.4.1). I was always very satisfied with this tool and it helped me keep many projects nice and clean (yep - I was the fascist in many projects kicking asses of other developers if they were writing ugly code :). I always used Checkstyle as a Eclipse plugin but recently I've also started generating Checkstyle Maven2 reports for our mavenized projects.
I'm attaching two XML files (see the original post) with Checkstyle configuration. One is for ordinary Java source files and the second one is more "liberal" for test classes. I worked on this configuration with couple of my colleagues from my previous company and we really think it's the best you can get from Checkstyle (however de gustibus non est disputandum).
When you incorporate Checkstyle configuration in question in your projects be sure that your code will be beautiful - it can still do nothing ;) but at least it will be well formatted and structured.

Recommendation
My very private recommendation and advice is to use.... both tools because they are complementary. Checkstyle only ensures the style of your Java code is standardized and "nice". It checks white spaces, new lines, formatting, etc. (i.e. it looks on the code line by line). On the other hand there is PMD which not necessarily checks the style of your code but it checks the structure of the whole code i.e. it looks on the code from the "higher altitude".
I would advise using Checkstyle as an Eclipse IDE as well as Maven2 plugin and PMD only as Maven2 plugin. In addition I would also advise using FindBugs as an Eclipse IDE plugin but I mentioned it already in the previous post.

Tools like PMD and Checkstyle will not ensure your code does what it should do (not even 0.1%) but they will help your team produce well structured quality code that will be much more easily understandable than before. Ensuring one code convention in your organization (whatever it will be) is always a good thing to do. And tools like PMD and Checkstyle help you make it agile way i.e. fully automated.
Belive me or not but in other companies I was able even to teach real Java-beginners how Java code should look like without spending with them any single minute. And they were producing pretty good Java code from day one. I was amazed!

PS. I'm using Eclipse 3.3.x IDE and some of the problems I encountered can be dead-issues on other IDEs.

Originally published on AgileSoftwareDevelopment.com

Monday, July 07, 2008

Postcard from Eze and Sainte-Agnès

From the Glamorous Life of the Software Developer



Wednesday, July 02, 2008

When unit testing is not enough

I'd like to share my experiences about unit testing (using JUnit) Java servlets outside of the servlet container. Agile world tells us that we should automate as much tests as we can - it would be good if all aspects of the developed system are completely tested. We should test functional as well as non-functional requirements of our systems. But can all tests be automated? What is the REAL value of such tests? The reality brings us problems and pitfalls even experienced developers fall into. I will present such story regarding automated and manual testing of Java servlets.

The problem
Quite recently I had do develop some "proxy" servlets facilitating Ajax request from web browser to our middleware layer. We couldn't directly send Ajax requests because JavaScript security model doesn't allow to request data from other address than it was originally downloaded (similar restriction to Java Applet).

All right then, our servlets were not doing any amazing job (some input and output transformations were needed, however) but I made some bugs even having 100% test code coverage (used Cobertura 1.9).

What about automated tests?
Well some things can be automated, some not. Let's start with unit testing servlets. The simplest (containerless) solution to unit test servlets is to use EasyMock in order to provide mocks for HttpServletRequest, HttpServletResponse, etc. Yes, I know you can use Jakarta Cactus but I did it quicker using easy mock :)

OK - I unit tested my servlets and was very happy that I saw the green light. I started the sevlet container accessed the web page and it seemed to be working. Unfortunately I didn't see that the servlet set some instance variables after the first invocation and these variables couldn't be changed afterwards. The effect was disastrous - servlet was sending the same request all the times not taking into account passed parameters. We could have checked this problem by invoking my doXXX method multiple times with different parameters - we didn't.

Did we test our servlets manually?
Yes, non-automated tests were performed using JMeter. I used JMeter to check how our servlets behave under heavy load. The performance and load results were OK but I noticed in the logs many entries similar to this one:

Checkout date [2008-10-15] is earlier than or equals checkin date [2008-10-11]

Well the log message lies! And the implementation is well-coded (really). What's wrong?
This is how I discovered problem with SimpleDateFormat - not to mention the help from FindBugs that showed me big red light in the affected lines :)

What was wrong?

  1. I forgot that using instance variables is not thread-safe (there is only one servlet instance created by the container)

  2. I forgot that java.text.SimpleDateFormat has synchronization problems and cannot be used as a static class field

  3. I took UTF-8 for granted - unfortunately default encoding was set to the server's default one (this problem was not described above but it appeared during further manual UI testing)


Lesson learned
When you want to test your servlets:

  1. You should invoke all methods you test multiple times

  2. You should test your servlets using couple of simultaneous threads to see whether there is no shared data clash

  3. Be sure you set required content type and content encoding before you flush any response - DON'T take anything for granted

  4. You should use FindBugs to check any common Java problems (e.g. SimpleDateFormat) - either using Eclipse/NetBeans plugin or Maven report

  5. ALWAYS test your servlets under heavy load - what works for single user can stop working when many users try to use your application


Using load testing tools you can discover quite interesting and unexpected problems - without such test you cannot be sure your application will work under every circumstances.

After implementing all fixes our servlets seem to work very well even under heavy load. We don't have any thread-safety issues and our dates are parsed correctly ;)

Conclusion
To conclude shortly I will say that testing servlets is not easy. You can write unit test, "inject" mock request, response, etc. objects but you still will not be sure how your system behaves inside servlet container under heavy load (you should also try using Jakarta Cactus framework).
Agilists say that you should automate as much tests as you can. I generally agree with it but sometimes it makes more sense to perform some manual testing which simply works. I probably would not discover all the issues I revealed using only automated tests.

If you have other experiences with testing Java servlets, please share them here.

Originally published on AgileSoftwareDevelopment.com