by John Turner
Posted on January 28, 2011
I’ve just been reading a survey report from Cisco Internet Business Solutions Group titled The Next Growth Opportunity for Banks. I have to say, the results of the survey are consistent with both my own experience and that of some well regarded banking figures.
The main findings of the survey are that banking institutions will need to meet the growing demand for:
If this is all to be realised, it will mean exciting times for those like me who are involved in IT delivery within the banking sector. The challenge, of course, will be delivering on the promise in today’s constrained financial environment.
by John Turner
Posted on January 13, 2011
I finally got around to watching Jurgen Holler’s presentation Spring and Java EE 6: Synergy or Competition.
It is quite a comprehensive presentation that starts out looking at and overview of JEE 6. New platform services such as JEE Profiles, Servlet 3.0 and Authentication Service Providers are discussed, as well as new and updated user component models such as JSF 2.0, JPA 2.0, JSR-303 (Bean Validation), JAX-RS, EJB 3.1 and JSR-299 (Context and Dependency Injection).
Next Jurgen looks at how Spring continues to incorporate support for these enhancements. I’ll be particularily interested to see how support for JSF is improved in the upcoming releases of Spring.
Jurgan provides a nice comparison of JAX-RS and the Spring support for REST. This probably deserves a presentation in itself. There is also a high level overview of JEE 6 Singleton Beans and a comparison with Spring managed singleton beans.
Finally, JSR-299 (Contexts and Dependency Injection) is discussed at length before a concise summary of his 1 hour 30 minute presentation.
Quite long, but very interesting and well worth watching.
by John Turner
Posted on December 01, 2010
Martin Fowler recently wrote about the value of a reproducible build. I agree absolutely with the points Martin makes and also that fans of continuous integration often assume a build to be reproducible.
In the early phases of an Agile process when there is a significant amount of foundational activity that has yet to be completed, release procedures are often neglected over building the momentum of the development team and feature delivery. Of course, we have our Continuous Integration environment from the word go but there is a bit more than that to creating a reproducible build.
For a start we need to make a specific build identifiable (you can’t reproduce what you can’t identify!). Sometimes it is sufficient to add versioning to the build artefacts but often it is necessary to make the build identifiable to the end user. The easiest way to do this is through adding a version tag to the UI.
Versioning assumes some sort of release procedure that is typically automated. John Ferguson Smart talks in detail about this in his excellent presentation titled Automated Deployment with Maven and Friends.
But at what point does it become important that a build is reproducible?
In the early stages of an Agile project, features are normally developed, tested, deployed and perhaps presented (at a show and tell) by the team and for the team (or extended team). It’s probably safe to assume that only a single branch of development exists and with such a limited audience (who are probably intimately involved in the project) it is possible to get away with limited versioning of releases. I always take a JIT (Just In Time) approach to establishing procedures, practices etc. as establishing all the procedures and practices that a project requires up front often has a negative effect on momentum.
Of course, as the project gains momentum and a couple of iterations have been completed, a layered approach to testing and quality assurance is usually applied and at this point identifying and reproducing specific builds becomes important.
by John Turner
Posted on November 22, 2010
At Devoxx 2010, Max Katz of Exadel presented Mobile Development Choices: Native vs Web. He kindly posted the slides on Slideshare and I have been eager to review the presentation as this is a development choice I have been considering lately.
The presentation is very good (although no doubt better in the flesh) and provides some background before laying out the main areas to be considered when making the choice between native and web. I’m not going to rehash or summarise the content but if your interested or involved in mobile development, I would highly recommend spending a few minutes to look through the presentation.
It’s a pity that the presentation was not available through vimeo.com or similar because it’s such an interesting topic and audio would have added a lot to the presentation.
by John Turner
Posted on November 15, 2010
Over the years, I have been involved in interviewing candidates for lots of different roles and companies. I say involved, as it is normally the case that I am rolled in to help assess the technical competency of the candidate and provide feedback in this regard. Typically this involves quizzing the candidate on roles and technologies outlined on their curriculum vitae and technologies utilized by the hiring company or team. Very rarely does the process go beyond this.
More recently, I have been seeking to hire for a specific role and have been receiving curriculum vitae from a number of different sources.
Having more influence on the process, I decided I would screen candidates via a 30 minute phone call during which I would introduce the role, and ask a number of questions from a predefined list. If the candidate displayed any particular in depth knowledge of a specific area, I would “go off piste” and deviate from the predefined list. The aim of this approach was to reduce the amount, or weight, of subjective opinion when evaluating the candidates familiarity with the technology stack. I felt it was less disruptive for all involved than having a face-to-face screening interview.
For candidates who progressed beyond the screening, I decided that for this particular role, I would take a more novel approach to the interview. I felt that at this stage, I had already established (as much as I could without sitting them in front to of a keyboard) that the candidate was familiar with the technology stack so I wanted to assess their approach to problem solving and design.
My approach was to present the candidate with a popular board game (Monopoly) and ask them to design an online platform for the game. There was a short brief but everything they needed was in the box. So what was I looking from the candidate?
I was looking for the candidate to display a willingness to take on the challenge, be pragmatic in their approach to presenting a design in the short time frame available, and be able to present a coherent explanation of their solution along with the decisions they had to make along the way. I also expected the candidate to have an appreciation of how the solution would further evolve.
I was also looking for other less desirable traits, such as the temptation to dwell too long on the instructions, or an unwillingness to have their design challenged.
Overall, I think the approach worked well and though some within the team were originally skeptical, everyone soon appreciated the benefits of this approach over the more traditional Q&A approaches. I will certainly be more willing to try alternative interviewing techniques in the future.
I’d be very interested to hear feedback on this approach or on other approaches people or companies have taken.