The first thing I did was compare the Magic Quadrant chart with the same chart from 2007. A quick comparison shows little that separates the two. The larger enterprise solutions remain where they always have, in the upper echelon of the square, while the remainders continue to jostle for position around the centre.

There was minor movement amongst the larger organizations; one moved up a little on one axis while another tiptoed along the other. But despite that nothing much visibly has happened.

Personally it’s no surprise as the larger organizations make the biggest footprint. With a larger reservoir of capital they can afford to make things happen much quicker, marketing, sales and even innovation.

Its Just One Opinion Right ?
I think we should be grateful that this market even has a Magic Quadrant report for people to chew over. As is states at end of the report, “Gartner does not endorse any vendor, product or service depicted in the Magic Quadrant, and does not advise technology users to select only those vendors placed in the “Leaders” quadrant.”

It’s a bit naive though to think the report is just another opinion, as James Governor analyst with RedMonk says, being in Gartner’s Magic Quadrant can move mountains for a company.

Organizations use these reports as a means for garnering further sales, why else participate?

Quotes and positioning details are peeled off and reprinted on marketing material. In fact it’s not uncommon to find the entire Magic Quadrant report available on company websites which have benefited from the report.

Ratings by research firms matter, their opinions are taken very seriously by IT procurement departments evaluating products and services.

Moving Mountains
The Gartner Magic Quadrant evaluation process looks at several areas, not only regarding the product, its limitations and direction but also the supporting business infrastructure, marketing execution, pricing, sales execution. For a lesser-sized business, being compared to the likes of Oracle in these departments is hardly going to work in your favor.

As Dave Kearns mentions in his article, Thor Technologies’ provisioning product was ranked third or fourth (depending on how you read the chart) a few years ago. Once it was acquired by Oracle however, it was repositioned at the top of the leader quadrant with little change except for the acquisition. Despite the improved sales force the product remained the same yet it had gravitated to Leader status.

So it’s not hard to see why some businesses find these annual reports demoralizing and even attribute them to potential lost earnings as was the case with ZL Technologies

It can not be underestimated; the Magic Quadrant is incredibly powerful. “It’s the difference between trying to sell something and trying to fulfill. The business of IT purchasing is predicated on requests for proposals. Everybody in the leaders [quadrant] is always going to be invited to bed,” James Governor RedMonk analyst.

Not All Lost
If there are any positives that can be taken from these reports (for those that have not favored highly) is that they can be a catalyst for change. These detailed reports highlight areas that can be improved, providing opportunities where alternative strategies need to be sought; whether that is improving marketing execution, customer experience or something else.

Whether Gartner stops producing these reports or alters them makes no odds, there will always be opinions that some people give greater importance to over all others.

Bone-idle IT procurement departments will continue to start and end their product evaluation with these reports and opinions; grading product viability on how high and furthest to the right something is on a chart. But for many, especially with IT security budgets shrinking, purchasing decisions are being done with a lot more care. Businesses are using these opinions and reports along with many others to find something that is right for them rather than relying on where a product is positioned against bespoke criteria.

I’ve since recommended it several times to other people who were interested in building applications new applications. Most of the this feedback has been extremely positive so I’ve managed to get around to having another look at it recently. After @snaglepus suggested I check out Build twitter in Grails in 40 minutes (registration is required) I have to say I was very impressed. Since watching that I’ve gone from knowing absolutely nothing about Grails (three years it too long to keep information in memory) to building a sample application very quickly. After finding plugins for many of the tasks I wanted, I’ve implemented the logic I need and let the tool do the rest of the heavy lifting work which led to a very productive evening of coding.

I really love it when you find technology which just seems to work and does exactly what you expect it to do. There is still much I want to learn about Grails and I’m sure there are many other tips and tricks I can pick up along the way. At the minute I’m just looking through the many Grails books to find a winner and I think I have in The Definitive Guide to Grails, Second Edition. If you haven’t looked at Grails before, I really recommend you check it out and see what it can do for you. And if you aren’t following me on Twitter, I’m @pramatrdev and I’m sure there will be a few more tweets about Grails before the month is over .

Spring Recipes covers Spring 2.5 (and earlier versions) taking it from the simplest concepts right through to the most advanced level. The book is divided into nineteen chapters organised into three parts; Core, Fundamentals and Advanced. Each part builds on the previous ones to grow your understanding of all aspects of the Spring framework, for this reason the book is best read cover to cover.

This book is in no way filler and is packed full of content covering not only the Spring framework and but also several common Spring projects including; Spring Security, Spring Web Flow and Spring Web Services. For anyone that knows Spring (and it’s associated projects), this is a huge amount of information to cover in just one book, but this book really does deliver!

As the author puts it; “Reading Spring Recipes will help you master the most important 80 percent of Spring’s features with just 20 percent of the effort you would need to learn them all.” If you are already using Spring, this book will serve as an invaluable reference and companion guide for future development. If you are a newcomer to Spring, this book will serve as an excellent launch pad to get you up, running and productive with Spring very quickly.

Structure

Each of the recipes covered in the book follows; a problem, solution and then how it works approach. This approach lays out many of the common FAQ style questions that come up on Spring Forum in an accessible way; clearly outlining the problem and mapping the path to the solution. This book also acts an excellent companion to the Spring Reference manual, which is sometimes difficult to read in places and lacks the array of examples this book provides.

Audience

The intended audience for Spring Recipes, is any Java programmer hoping to learn more about Spring. No prior knowledge of Spring is required as this book covers it all right from core concepts such as inversion of control (or Ioc). This book is accessible to anyone who has heard the hype about Spring and simply wants to learn more about it and how they can leverage it’s power. This book gives Java developers hands-on experience using the Spring framework with real-world examples, this experience can be transferred straight into your Spring project.

Chapters

Part 1: Core

This part focuses on the core concepts and mechanisms of the Spring framework. The chapters in this part aim to familiarize you with Spring’s core. As a newcomer to Spring Chapter 1 introduces the concept of inversion of control the core foundation of Spring. It explains how and IoC container works, but also why it is useful and beneficial to use one. This chapter serves as an excellent introduction to IoC and is invaluable to anyone who isn’t quite sure why they should use a container based approach. This chapter is a must for anyone new to Spring or anyone trying to deliver it to a new audience.

Chapters 2-4 build on the IoC introduction, explaining how to setup and configure a new Spring project and apply the basics of Spring configuration. These first four chapters are the foundation for the rest of the book and are a must read for anyone who has never used Spring before and even advanced users may find useful hints and tips within. Chapters 5-6 cover the extremely powerful approach of AOP, introducing crosscutting concerns and how these can be configured with Spring. This technique can be extremely useful to provide trace logging, caching and other crosscutting concerns such as security. This is a must read for anyone using Spring, even if you are not directly leveraging Spring AOP or AspectJ. Spring AOP lays the foundation for introducing how Spring provides features such as transparent transaction support and method level authorization checking.

Part 2 : Fundamentals

This part has a split focus, it introduces Spring’s Data Access support, Web integration and also Testing support. Chapter 7 introduces one of the most important aspects of Spring’s data access support in the form of JdbcTemplate. This shows the reader how they can use JdbcTemplate to prevent the use of direct JDBC and instead let Spring handle all of the boiler plate code. As JdbcTemplate removes the need for the common try/catch/finally/try/catch code seen with JDBC, the code is much cleaner and much more readable. Along with this support, the Spring DataAccessException hierarchy is introduced which provides a rich set of common exceptions to provide a more granular handling approach.

Chapter 8 introduces Spring’s excellent transaction management support and explains in great detail all of the various propagation behaviours and isolation levels. This chapter is one of my favourites as it not only introduces the concept of Spring transaction support but transactions in general. It’s accessible to everyone and extremely useful when mentoring new developers.

Chapter 9 discusses how to integrate Spring with existing ORM frameworks, making their usage within the application seamless. This provides multiple approaches to integration allowing you to build on existing Spring classes, or completely decouple your classes from Spring removing the need for any Spring imports within your code. Chapters 10-11 discuss Spring’s popular MVC framework and also discuss how many other leading web frameworks can be integrated with a Spring application. As many of the projects I have worked on in the past have used Struts, Chapter 11 was particularly useful to outline all of the options available to use Spring and Struts together.

This part finishes with the introduction of Spring Testing Support, teaching you not only what features Spring has to offer but also how it integrates with popular testing frameworks such as JUnit and TestNG. As the Spring Testing support has been overhauled, it was great that this book covered the TestContextframework, but also legacy test classes to cover older versions of JUnit and TestNG. This chapter helps you leverage not only IoC for your tests but also transaction support, mock testing and also MVC integration testing. This approach enables you to easily decouple your code from your tests, providing first class support for all your testing needs.

Part 3 : Advanced

For anyone that has mastered the first twelve chapters, Chapter 13 is where things start to get really interesting. This chapter is dedicated to one of the most scary Spring projects, namely Spring Security (formerly known as Acegi). Spring Security provides a full range of authentication, authorization and access control options which allow it to secure a standalone Java application or a web-based application. This book focuses on version 2.x onwards which dramatically reduced the size of the required configuration and also its complexity. Spring Security can be a difficult subject to tackle as it’s often hard for developers to understand it’s concepts, but this chapter builds security into the example application in piecemeal steps. This demystifies many of the problematic areas of Spring Security whilst addressing the common problems a new developer might face.

Chapter 14 covers the portlet application development using the Spring Portlet MVC framework, highlighting the portlet-specific features which differ from the standard Spring MVC framework. If you don’t require the portlet features currently within your application, this chapter can safely be skipped as the next one is another gem. Chapter 15 covers the Spring Web Flow framework which addresses the three major pain–points facing web application developers: user interface navigation control, state management, and modularity. Spring Web Flow offers a flow definition language which encapsulates a reusable sequence of steps that can execute in different contexts. This framework is extremely flexible and powerful, but this chapter provides a great introduction into what is a very large subject.

Chapter 16 introduces the remoting integration that Spring provides for various technologies such as RMI, Hessian, Burlap, HTTP Invoker, and Web Services. Having already been familiar with many of these technologies, this chapter provides an excellent insight into how these can be integrated with Spring and how quickly this can be achieved. This chapter concludes with a look at Spring Web Services including how to develop contract-first web services. Chapter 17 discusses how to develop EJB 2.x and 3.0 components with Spring’s EJB support, and how to use Spring’s JMS support to simplify sending, receiving, and listening to JMS messages. This introduces a powerful concept of message-driven POJOsfor those who like the concept of message-driven beans (MDBs) but don’t want the restrictions of an EJB container.

Chapter 18 demonstrates how easily Spring beans can be exported as JMX MBeans with relative ease in comparison to the typical approach. It continues to extend this by providing remote access, auto-detection and notification. This chapter continues by introducing Spring’s email support which removes the reliance on JavaMail specific mail sessions and exceptions. This provides an abstraction which is independent making it easy to switch to another e-mail API. This chapter finishes with a look at the options available for scheduling tasks within the Spring framework, this integrates with the JDK Timer and also Quartz scheduler.

Chapter 19, this part and the book concludes with a look at the various scripting languages that can used with Spring applications including; JRuby, Groovy and BeanShell. One of the most powerful features of using scripts is that any changes made to these can be detected by Spring and thus the beans can be refreshed automatically. This is of great benefit when you wish to avoid the long compile, deploy and test cycles or the application cannot be taken down regularly for maintenance. This chapter demonstrates how scripted beans can be added to your application quickly and simply using Spring.

Summary

This book has undertaken a mammoth task, trying to squeeze Spring and associated projects all into one book. This book is very clearly written, with well-structured, concise examples that get to the heart of the problem without complicating it with unnecessary detail. The examples provide solutions to real world problems instead of taking the form of the simplistic examples found in many other technology books. My only real minor criticism of this book is it’s scope and size. Given the huge undertaking, there are obviously going to be some areas which only provide a minimal amount of information. This should be expected given the vast array of information covered, but there are a range of Apress books which can build on this foundation. I would still give this book five out of five and rate it as one of the best framework specific books I’ve read.

This book should accompany anyone starting their journey with the Spring framework and even seasoned developers. It can take you from knowing nothing about the Spring framework to knowing pretty much everything you need to create a fully functional web application with all the bells and whistles you’d expect. It provides information and examples on numerous integration points with other popular open source frameworks and languages allowing you to truly become a Spring expert. Read it, read it again and keep it on your bookshelf as a solid reference for the Spring framework.

Just like OpenOffice, a previous project I worked on used an embedded version of HSQLDB. We had started to have several performance problems so engaged in some profiling to find potential areas for improvement. After staring at several screens full of SQL debug, one thing became apparent; our system was producing a huge number of SQL statements. This was accompanied by the realisation that it was also producing a huge number of exactly the same SQL statements.

As the embedded database was extremely fast, there had never been any performance problems before. In fact the database was not the bottleneck in many of the application operations. As the application grew more complex however, performance problems began to arise quite quickly. These problems only got worse when the numbers started to increase. Complexity + Scaling != Success. The extemely fast embedded database was now starting to be a real problem, some serious changes needed to be made.

Many of the database performance problems were resolved quite quickly by simply re-learning the most basic best practices, just because the embedded database was quick these should not have been ignored;

• Connection pooling can improve performance
• Statement caching can improve performance
• Batching statements can improve performance
• Performing SQL n + 1 selects are a bad idea regardless of how quick the database is
• Caching common SQL results can improve performance
• The database needs to be profiled to see exactly what SQL is getting executed against it

It may be possible to ignore these issues early in the project, but as the complexity increases and the application is expected to scale they can begin to be exposed. Embedded databases performance can be impressive, but make sure you handle with care.

For those people who have never played the blame game before, we need to set out the rules. The rules are actually quite simple, if in doubt seek the advice of a seasoned player. The first rule of the blame game is, it’s never your fault. The second rule of the blame game is, it’s never your fault. The third rule of the blame game is, it’s always some one else’s fault. So now we’ve established the rules, we need to work out some tactics to work out whose fault it actually is.

The first candidate for blame always has to be the last person to leave the company. Anything that’s wrong can easily be blamed on them, after all they can’t defend themselves so they make an ideal target. The next candidate can be chosen from any of the temporary staff you currently employ, the shorter the contract the better. If you aren’t going to have to see these people for much longer, this should work out quite nicely. The next candidate is anyone that’s working for the company in another location (if it’s another country this works even better). You might have to work with these people again, but you’re probably not going to see them on a daily basis, it shouldn’t be too awkward. Now this is where your choices start to become a little tricky, you’re down to the people that you work with everyday.

You have to keep this simple and align yourselves with the strongest members of the team, after all this is survival of the fittest. Fit yourself nicely into the crowd and look for anyone that doesn’t quite fit, this is real back to basics school ground behaviour. Pick off the weak and vulnerable first as these shouldn’t put up much of a resistance, then work your way up the power hierarchy until you find your patsy. So there you have it, those are the basic tactics for the blame game you might have to tweak as appropriate within your organisation but the general approach should apply.

The most important decision you face when presented with the blame game is do you really want to play? If you decide that it’s really not for you, the best way to deal with it is to simply throw out all of the rules, rip the board in half, stamp your feet as hard as you can and shout out loud, “I refuse to play”. It is often said that; “we work in a blame free culture, until something goes wrong”. Are you really interested in finding someone to blame when something goes wrong? Will it really help the customer solve their problem any sooner if you’ve found the person to carry the can for the failure? In the time it takes to sit there and rack your brains for potential candidates to take the blame, you could already be investigating the cause of the problems and attempting to fix them. In his recent post Sean Landis said;

Successful Agile development presupposes that team members will all act like adults. That’s a euphemism for being competent and professional. Agile teams are expected to accept a high level of responsibility and accountability. When they don’t, things can fall apart really fast.

Regardless of how bullet proof a process claims to be, there are always going to be issues that weren’t found prior to the release. If issues are always going to occur, should teams really be allowed to turn on each other in response to them, will this really lead to a better working relationship? The most important thing is that problems are dealt with promptly and professionally when they arise. Instead of trying to assign blame, people should be responsible for their own actions, they need to learn from the experience and measures should be put in place (if possible) to prevent this happening again. Next time your team is out celebrating your latest release and your mobile phone starts to ring, do you really want to start playing the blame game?