These notes are very closely based on the Spring Reference Document (2.5.6). I have tried to summarize the “important parts” of the reference documentation, while excluding the parts that I do not think will be in the exam. This is just my “best guess” based on comments in forums, mock exams and official Spring resources.
I have linked each section back to the Spring Reference Document (so you can easily refer back to the original documentation)
I have also included links back to the Certification Objectives and tried to highlight key concepts and likely exam questions.
As my studies progress and my Spring knowledge increases, I will update these notes.
One of the main benefits of the Agile methodologies (XP, Scrum, etc) is the growing popularity of unit testing. This used to be a dark art practiced by the most geeky of geeks. Only a very brave developer would spend time implementing a unit test instead of rushing a shiny new feature out the door. However, software developers (and their managers) have seen the light (or are, at least, a little more open to trying out this practice on real projects).
I have been “unit testing” for the last 8 years. Recently I decided to give my unit testing toolkit an update and check out what new shiny toys are available. Here is a summary of what I found / experimented with…
Jmockit. This is the best mocking framework I can find. It is magical. With JDK 1.6, you add the jar to the class-path and you can instatnly mock anything. Yes, anything. I tried mocking static methods, final methods, private methods, objects created with the new operator. There is nothing this baby can not do!! Check out the comparison matrix.
Jmockit code coverage. Not only can this tool mock with the best of them, it can do code coverage as well. Seeing the tested paths really helps you in building efficient and comprehensive tests. It even tracks how many of the possible execution paths are covered. Put that in your pipe and smoke it!!
DBunit. This old tool has been brought back to life by a new team of developer. It is the best way to set-up a database before running your test. Mocks can get you a long way, but sometimes you just need to test with a real (big) database!!
Fest assert. OK, so I am a sucker for cool open source jars. This library makes your asserts much more readable.
TestNG. While JUnit 3.8 stagnated the Java unit testing world, TestNG rocketed ahead with features like annotations, parametrized tests, threaded tests, etc. JUnit 4 closed the gap a little, but TestNG is still ahead. Take it out for a spin and ditch that JUnit clunker.
Selenium. I am just getting my head around this tool. So far it seems the best way to test web sites. I have tried many other “web testing tools” and they all suck eggs big time. This one seems to have legs, but make sure you ditch the x-path locators (use css ones instead) and html format (use TestNG instead)
With so many great tools, there is no excuse for not developing (and maintaining) a comprehensive set of unit tests for your project!!
However, IMHO, I do not think Pair Programming works very well.
I have been using the Extreme Programming methodology (or Agile methodology for the conservative or Politically Correct managers out there) for about 8 years. I have seen many advantages with some of the tenants … but Pair Programming has always been a disaster.
I tried it several times with different pairs and it always resulted in:
Significantly longer development times
No real increase in code quality
Keyboard / mouse hogging (the most assertive developer ends up driving)
See here for scientific findings on Pair Programming.
While working on some code the other day, I had an idea of how to improve pair programming. I like to call this approach Ping Pong Development (P2D).
The basic idea is that each feature is developed by 2 or more people. Note… DEVELOPED … not PROGRAMMED.
Two developers work on a new feature.
The first developer starts the work and completes a basic implementation
The second developer reworks implementation (and tightens things up).
The first developer then extends the feature to cover new use-cases.
The second developer writes additional unit tests.
The first developer presents the implementation to the team.
The second developer fixes issues raised during the testing phase.
The first developer carries out the performance tuning.
Each developer works independently (so there is no keyboard hogging and no increase in effort). However, each developer knows that his work needs to be understood and extended in the very near future to complete the feature. The work is sent back and forth between the developers (just like a ping pong ball) until the feature is complete.
The advantages are:
It puts positive pressure on each developer to produce high quality code (easy to understand, conforming to code standards, well documented, hack free).
Knowledge of every feature is spread amongst at least 2 people. There are always multiple sets of eyes to pick up problems.
Issues would tend to be bigger and of higher value than the small programming ones picked up by Pair Programming.
Issues would be picked up very early. For big systems, code can sit around for years before someone needs to understand it / change it / extend it. Using P2D, the code is looked at and improved hours after it was written.
Both developers need to have an excellent understanding of the feature. For many code reviews, the reviewer does not really understand the code. They end up finding superficial issues. With P2D, both developers need to have an excellent understand the code and the requirements to complete the feature. No extra code reviews are needed!!
It is not revolutionary, so it is easier to sell / implement. There is no reorganization of desks, doubling of estimates, added resource planning complexity, etc. From the management point of view, it is business as usual … except they get a higher quality, better understood code base implemented by a more cohesive team.
First there was Programming (P), then Pair Programming (P2), then Ping Pong Programming (P3) and now Ping Pong Development (P2D)…
Hopefully, I will get a chance to try this idea out. Let me know what you think of it.
The other day I was trawling the Java web sites (Javalobby, The Server Side, etc) and I found “Sonar”.
It takes well established tools (like checkstyle and PDM) and meshes them into a “quality platform” (aka web site) that would blow the socks and shoes off any manager or CTO wanting to take the next step in quality control. You can analyse, dissect, bisect your code, monitor the team check-ins for infringements and watch quality metrics change over time (probably as existing as watching grass grow).
I had a quick look at Sonar and bookmarked it (in the hope that I would find time between work, kids, EJB certification, bike riding, etc to have a look at it).
However, it got me thinking…
“Do all these metrics, style checkers and bug finders really make a difference?”
On reflection, I think that code analysis tools are bit like vitamins (see here) and standard practices (like code documentation, issue management, technology selection & investment, scope management, estimating, etc) are like a good diet.
are easy to take
get plenty of media attention
may make a small difference (but this is not conclusive)
may harm (especially in large, enforced doses)
are often sold (by managers to their managers) as the solution to every ailment
A good diet ..
is boring and hard to sell!!
is know by almost everyone, but followed by very few people
needs to be in place from the start and not added as a last minute “band-aid”
If you still think you need a vitamin boost … check out the Solar in a nut shell and start popping those “FindBugs” tablets and “CheckStyle” supplements.
Over the last few years I have been quite heavily involved in recruiting new graduate developers. One of the issues that came up over and over was the value of certifications.
Some people say that they are not worth the paper they are printed on. Other say that they turn you in to a human compiler. However, I believe that they are extremely valuable for the following reasons:
Certification ensures that you have a minimum level of knowledge. This is a level that an employer can have confidence in. It is not a few “ad-hoc” technical interviews questions … it is a well thought out, comprehensive technical assessment provided by the experts. For example, when you interview someone who is Java certified, you can imagine that the Java experts from Sun had carefully interviewed them and given them their tick of approval (at least in the basic technical area).
Certification gives you a broad and deep understanding of the technology. I have seen senior developers who through circumstance, never mastered some of the most fundamental Java concepts. Real world experience is not always the best teacher. It is often “hit and miss”. You may learn one area well and totally miss another important area. Certification ensures that there are no significant gaps.
Certification can be a stepping stone. They help you move on to new areas and challenges. It is always a vicious circle. Without experience in technology x, you can not get a job working with technology x … but you can not get experience in technology x without a job in technology x…. Certification gives you a way out of this endless loop. You can get certification in an area you want (day-dream) to work in … and then it is much easier to get the job in that area.
Certification proves that you are enthusiastic. Many people say they read IT books, visit sites, keep up to date with new developments, etc … but it is impossible to judge the true level of their interest. However, someone who has taken the initiative to get certified and has invested 3 to 6 months studying, clearly demonstrates their level of commitment. After all “IT development” is not just a job … it is a passion.