karldmoore development

A development oriented blog, containing anything I've been working on, reading or thinking about.

Archive for February, 2009

Hiring Staff: Level 70s Need Not Apply?

Posted by karldmoore on February 26, 2009

After working in the technology industry for many years, I’ve had the pleasure of working with many avid gamers. Some of these are occasion players, but I’ve also worked with those that spent endless evenings and early mornings playing MMOs. The water cooler gaming banter is a regular occurrence; with discussions of last nights raid and the weekend guild meeting. It was therefore quite interesting when I started to read January’s edition of the gaming magazine edge which talked about hiring these same gamers.

“He replied that employers instruct him not to send them World of Warcraft players. He said there’s a belief that WOW player can’t give 100 per cent as their focus is elsewhere, their sleeping patterns aren’t great, etc. I mentioned that some people have written about MMOG leadership as a career positive, and he shook his head.”

After a little searching I found the original source of this quote and the proper context in which it was delivered. Although the opinion was that of a single recruiter and was merely a brief comment in a conversation, it seems to have generated a surprising amount of publicity (nearly 90k hits on the forum alone). Much of this was no doubt due to the telephone game nature of how this story was reported; in some reports it was a job interview, in others a huge employeer. The story had a life of it’s own and was reported in various incarnations, some widely inaccurate from the original. It did however touch a nerve and I was forwarded the same link several times from both gamers and none gamers.

It wasn’t so many months ago that I was reading about “the striking similarities between the skills required for online gaming and those required for real world leadership”. Jim Spohrer, Director of Services Research IBM said, “What we’ve found is that success as a business leader may depend on skills as a gamer”. Some people even went as far as to say that these games should be thought of as “a potential educational medium for complex social skills”. Others even contemplated resumes that include a line reading “level 60 tauren shaman in World of Warcraft.”

I have come across many hardcore MMO gamers who poses in-game qualities that any employer would jump at, but do these really translate into real world qualities? Are guild masters really project managers or lead developers in another guise? I’ve seen guild masters that organize every part of their weekend raid but I really wouldn’t be confident of letting them run the project schedule. Virtual world skills may help improve real world skills but I personally haven’t seen a correlation between the two. Guild masters may make great project managers but I wouldn’t personally use this status as an indication of potential ability.

Since reading the quote in the edge magazine, I’ve read more negative opinions about the impact these games have on individuals. Some anecdotal observations claim that playing these games is causing college drop-outs and led to people neglecting their studies. The results from a small poll even showed that 55% of people thought that MMO gaming affected their own school or work performance. The sample is small, but it’s still quite interesting that the very people playing the game claim it affects their own performance. Many follow up comments from the original story come to a similar conclusion; playing games makes you a less effective employee. But is that really true?

Balance and separation seem to be the dominating factors. Those gamers that I’ve really enjoyed working with were able to leave their gaming lifestyle at home, it’s something they do in an evening but it doesn’t take over their life. Those that really cause headaches think nothing of discussing group tactics and tech tree analysis during work, with the lunchtime forum reading quite easily turning into an afternoons reading. Morning naps are a common occurrence to make up for lost sleep when they were too busy the night before slaying the latest boss. But is this really any different to any other evening activity?

Everyone spends their spare time in different ways, but if that spare time activity starts affecting work on a regular basis, an employeer is completely justified to be unhappy about this. It doesn’t have to be a late night playing games, it could quite easily be a late night at the local pub or 4am coding on your own pet project. It doesn’t matter if last night you were a Death Knight, a Shaman a Warlock or just out partying, if you come to work an absolute wreck and the rest of the team have to make up for it, that’s just not on. When hiring staff, level 70s need not apply?

Posted in Development, Opinion | Tagged: , , , , , , | 1 Comment »

Spring Recipes: A Problem-Solution Approach

Posted by karldmoore on February 17, 2009

springrecipesI recently had the pleasure of reading Spring Recipes: A Problem-Solution Approach. I first began reading the sample chapters released on the authors website, so when the book was finally finished I was really looking forward to getting hold of a copy. When it arrived I was amazed to see that it weighed in at a hefty 752 pages, but that really shouldn’t put you off.

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.

Posted in Books, Development, Spring | Tagged: , , , , , , | 2 Comments »

Documentation: Update It Or Lose It

Posted by karldmoore on February 17, 2009

Over time I’m frequently restructuring and refactoring the code I work on to improve the design and simplify many of the balls of mud I find along the way. If I break some of that code my unit tests shout at me and if they don’t my continuous integration environment shouts at me when I’ve broken one of the integration tests. One area of the code that doesn’t receive the same attention however is the documentation.

I love a well documented API as much as the next developer. I also am fighting a constant battle to improve my JavaDoc skills, trying to write to the same quality that I see in many other projects. But is excellent documentation really enough? It can’t just be excellent when it’s written it needs to be constantly maintained to this same level over time.

It’s a pretty common occurrence that I can look at a section of code and find documentation that has nothing to do with the method it belongs to. The intention revealing name sounds nothing like the documentation which describes what it’s supposed to be doing. Somewhere in the mists of time, the intention of the method and the documentation parted company; it is documentation no more it is ex-documentation. The problem here however is that there’s nothing to catch this issue. If an extra argument is added, Eclipse might display a warning telling me it’s missing from the documentation, but the actual context of the documentation can be completely wrong and I am none the wiser.

Although this incorrect documentation may seem fairly harmless to some, the reason it was supposed to be there in the first place is to the give the user of the API information on the method contract and the expected outcomes. If this information is completely wrong however it introduces confusion and also potential misuse of the API. After much wasted time and several grey hairs later I recently filed a couple of JIRA reports about popular open source frameworks which did exactly this. After my code just didn’t work and the unit tests failed, it took me a number of minutes to realise that the JavaDoc description of expected events just didn’t reflect what was actually going on in the code.

One approach to solving this problem is to include the documentation in the frequent code reviews. Code that doesn’t have documentation or has incorrect documentation can’t be considered complete, thus doesn’t pass the review. Developers need to make sure however, that they treat the documentation with the same respect that they give to their code and their tests. When dealing with documentation I’d much sooner see a method with no documentation than something that is completely wrong. I do want a good level of documentation in the code I work on but there is a very simple rule; update it or lose it.

Posted in Development, Opinion, Refactoring | Tagged: , , , , , , , , , , | 1 Comment »

Embedded Database Performance: Handle With Care

Posted by karldmoore on February 10, 2009

Embedded databases are proving pretty popular with many teams finding their usage extremely appealing. Many embedded databases have impressive features; easy to integrate into the software, low administration requirements, very low footprint and generally extremely fast. It is for this last reason that some people look to these databases, but it is also for this reason that they need to be handled with care.

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.

Posted in Development, Opinion, Refactoring, SQL | Tagged: , , , , , , , , , | 2 Comments »

Playing The Blame Game: A Better Way?

Posted by karldmoore on February 10, 2009

family-gameSuccess! We’ve just released a new version of our software, this calls for a celebration. All the team march down to the local bar for a well earned beer or an orange juice for the designated driver. But what’s that annoying noise in my jacket pocket, my mobile phone’s ringing and it’s the boss. Some customers have just upgraded and now they are reporting serious problems with their systems, looks like we better get ready to play the blame game.

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?

Posted in Development, Opinion | Tagged: , , , , , , , , | Leave a Comment »