Thursday, 4 November 2010

Cloud Computing with Scala and Gridgain

This was my first London Java Community event. I've heard of cloud computing and was looking for a bit more. The evening started off with a lightning talk about the Lift web framework. This was really very interesting, but after so long with the Java of GWT I look at web frameworks that involve HTML and big round trips to the server to display pages and page updates with quite a lot of caution.

Nikita Ivanov seemed to have a lot of very interesting things to say. I just couldn't understand 90% of what he said. I don't know if this was caused by where I was sitting of the PA. Anyway, he demonstrated very well how simply distributed programs could be written in Scala. The most impressive thing he demonstrated was the lack of a deployment stage and how the runtime adjusted effortlessly to the realtime addition and removal of processing nodes.

Unfortunately not the best presented presentation, but enough to impress me and for me to buy a Scala book.

Sunday, 17 October 2010

Agile Cambridge 2010

Mark Dalgarno, with the support of Redgate Software, is using Software East to do great things for the software community in Cambridge. Software East has been running frequent evening events on topics including Agile and iPhone development and attracted a number of ACCU speakers including Allan Kelly, Pete Goodliffe and everyone's favourite Mac pusher, Phil Nash. Not content with rivalling ACCU London's events Software East has gone further and put on their own Agile conference over two days in the heart of Cambridge. I was pleased to be asked to speak and enjoyed both thoroughly exhausting days. What follows are some of the highlights for me.

Agile Cambridge was the first conference I have attended as a Twitter user. It's an amazing tool for not only communicating with the the attendees and passing on words of wisdom from one session to another, but also for keeping those who could not attend up-to-date and wetting their appetites for next time.

I do not know what it is about the last day of a conference, and it does not seem to matter how long or short the conference is, but I always leave completely spent on that last day. Maybe it is the activities of the night before the last day? Agile Cambridge was no different and I cannot wait to go again next year!

Test Engineering at Google by James A. Whittaker

James Whittaker is the second incredibly enthusiastic and charismatic tester I have had the pleasure of seeing speak this year, following James Bach at ACCU 2010. He took us through the technology of the last twenty years, including a picture of Michael Douglass on a phone about the size of a small loaf of bread and demonstrated how things have changed. He seemed very surprised that a lot of people in the audience still used a paper phone book and this became the subject of a number of jokes throughout the presentation. One of the main points James made was that with a lot of software now being web based, it is no longer cheaper to fix bugs in a product before it ships. He went on to describe the role of a tester as a consultant in a hospital and told us that all software is broken and on life support until the testers can get in and diagnose the diseases.

What Does It Take to be an Agile Company by Allan Kelly

I have seen Allan Kelly speak a few times and have always enjoyed his direct style. He passionately believes in what he is doing and I enjoyed this presentation as well. I think Allan has a very complete view on what agile is, where it came from and where it is going. He explained that he believes that Agile has arrived and is here to stay and that it will only get better. I am very much inclined to believe him. Another of the stand out points for me was that companies should use experimenting over planning and make sure that if and when failure comes, they fail fast and fail cheap. This became a much repeated line throughout not only the presentation, but the whole conference.

Building Effective Habits Through Peer Group Learning & Assessment by Jason Gorman

Jason Gorman has been doing some very interesting work. I think it is best summed up when described as: coaching Test Driven Development (TDD) at the BBC. I still find it amazing that some developers still do not see the clear benefits of TDD and have to be encouraged with incentives. Jason Gorman has been at the BBC teaching and assessing those who have been incentivised and it sounded like very interesting work! He described some of the exercises that the developers went through, their assessment and certification and some of the problems he faced. One of the techniques used was pair programming, where developers would mark off on a sheet which TDD rules their partner had broken, in order to help them learn and improve. At the end of the session he wrote some code and unit tests while the audience marked off the rules he had broken on a similar sheet to demonstrate how it worked. Of course he broke (almost) every rule. This was another very enjoyable session.

Five Years of Change, no Outages by Steve Freeman and Andrew Jackman

Again, I have seen Steve Freeman talk a couple of times before and he has a lot of very interesting things to say. In this presentation Steve and Andrew Jackman described a very successful project that they both worked on at different times. It solved a particular problem that had been attempted by different teams in the past who had failed. The main secret to the project's success was the use of Agile methods, including regular and automated deployments. They described a lot of the methods I am using every day and I am again amazed that more teams do not see the obvious benefits of regular automated deployments. Maybe this is why this sort of conference is needed so much.

Cyberdojo by Jon Jagger

I attended Jon Jagger's Cyberdojo as a participant at ACCU 2010. On this occasion I was delighted to be asked to help out alongside Jon. The setup had changed significantly as Jon has been developing his Cyberdojo since the last time. There was a greater choice of languages and problems to solve; and the teams were not given an objective until part way through. What was most interesting to me was the teams being told that their only objective was to get every team's build to green and the number of them that then proceeded to break their build after having reached green, before the others had caught up. These Cyberdojo's get more and more interesting and I'm looking forward to the next one.

Building Trust in Agile Teams by Rachel Davies

This was one of most enjoyable presentations, not least because I got to take part. Rachel spoke about how important it was for members of Agile teams to trust each other and the ways in which trust could be gained and lost. Rachel has spent many years coaching Agile teams and had a lot of very useful things to say. They certainly made me think about my team in new ways. Unlike ACCU conferences, the Agile Cambridge bunch took a while to start interacting with the speakers. There was plenty of interaction throughout Rachel's presentation and a whole lot of laughter. I am very much looking forward to seeing Rachel speak again soon.

Creating a Development Process for Your Team: What, How and Why chaired by Giovanni Asproni

The final session at the conference was a panel. I really enjoy panels, both as a member of the panel and a member of the audience. You never know quite where it is going to go and by their very nature there is lots of interaction between the audience and the speakers. Those who joined Giovanni on the panel included Allen Kelly, Steve Freeman, Rachel Davies and Nat Pryce. It was a chance for the audience to ask about some of the recent Scrum bashing and get to the bottom of the concerns some of the industry experts have with it. There was a long and very interesting discussion on pair programming and another on how to convince an organisation that Agile was the way to go.

Saturday, 16 October 2010

Agile Cambridge: Agile is a journey, not a destination

Although I have done it (tongue in cheek) before, I don't like reviewing my own presentations. So I was delighted when Giovanni Asproni, (ACCU conference chair) reviewed my participation at Agile Cambridge 2010 and was kind enough to allow me to publish his comments:

Rachel (Davies) spoke about building trust in agile teams. Setting aside lots of interesting material about the importance of trust in teams and on various techniques to use or avoid in order to earn trust, the highlight of her keynote was an exercise where Paul Grenyer was volunteered by Rachel to do a stage diving (interestingly enough, Rachel, Allan, Paul and I had talked about it the night before at the pub, but we didn’t think Rachel was going to take the conversation seriously ;-)). He accepted and was caught by a group of six or eight people (which included Jon Jagger and Allan Kelly who joined them to make sure the ACCU didn’t loose one of its most valued members). I’m happy to report that Paul was not hurt during the exercise (neither were Jon and Allan).

Paul (Grenyer) presented a session entitled "Agile is a journey not a destination" where he described his experience in introducing agile development practices at his company. The session was aimed at people trying to introduce agile in their own companies for the first time. Paul presented the material in a clear and compelling way, and, judging from the number of questions at the end, the audience really enjoyed it. Personally, I found the content quite interesting, and I was truly impressed by the way he delivered the presentation.


Agile is a journey not a destination presentation slides available on request.

Sunday, 3 October 2010

Zima Blue

By Alistair Reynolds
ISBN-13: 978-0575084551

I loved Zima Blue even more than House of Suns. The standout stories in this collection are those based around the Merlin character. Superb space opera from the master. Not every story is a winner and a couple of them are conduits for explaining science. In some places modified humans are back and there's space travel and extension of the human life span. All the classic Reynolds winners. I only have Terminal World left to read now, so Alistair needs to get on and write something else!

Thursday, 23 September 2010

Cerberus Trial

Plenty of you will have heard me banging on about Cerberus recently and some will be wondering what it is, other than the multi-headed hound that guards Hades of course. Cerberus is an application I have been working on that monitors websites. Features so far include:

  • URL checking at configurable intervals up to once a minute
  • Measurement and recording of response times
  • Email notification on URL failure
  • Email notification on URL recovery

I'm currently running a free trial for a handful of websites and it's going very well. If you would like me to monitor your site, please contact me and I will be happy to add you to the trial.

Up and coming features include:

  • Dashboard for user monitoring
  • User configurable URLs
  • URL statistics
  • Automated reporting

Saturday, 18 September 2010

ACCU Conference 2011 Proposal 2

Session title: Web Application Development with Spring, GWT and MVP

Session type: Case Study / Experience Report

Session duration: 90

Speaker: Paul Grenyer

Biography: Paul has been programming in one form or another for over 20 years. After several years using C++ and a brief period using C#, Paul is now happy somewhere he hoped he'd never be, programming in Java.

After time in industries such as marking machinery, direct mail, mobile phones, investment banking and Internet TV, Paul is currently working for a company based in Norwich where he heads up an ever growing team of senior and highly skilled people.

When he's not programming and family life allows, Paul thoroughly enjoys science fiction, heavy metal and cycling.

Session description: In Enterprise Web Application Development in Java with AJAX and ORMs (ACCU London March 2010 and ACCU2010) I spoke about how to develop and test a Data Access Layer and integrate it with a very simple Google Web Toolkit (GWT) based front end.

In Web Application Development with Spring, GWT and MVP I will demonstrate how to take advantage of Spring's Model View Controller implementation to add Spring Security to a GWT application and show how an adapter can be used to map it onto almost any user domain model. I will then go on to demonstrate the power of the Google Web Toolkit when developing web applications.

Traditionally web based applications, and even some that make use of AJAX, require large numbers of round trips to a server followed by the rendering of entire web pages each time something is submitted. Coupling GWT with the powerful and aesthetically pleasing GXT widget library (which is based on the EXT JS JavaScript library used by web applications such as Nexus) and the Model View Presenter pattern I will show how to create a powerful web application that runs almost entirely within a browser, with much of the same power as a desktop application, only calling to the server to send or retrieve the bare minimum of data.

Throughout the session I will build an application and demonstrate each new feature by running and operating the application.

No knowledge of the previous session is required.

ACCU Conference 2011 Proposal 1

Session title: Agile is a journey not a destination.

Session type: Case Study / Experience Report

Session duration: 45

Speaker: Paul Grenyer

Biography: Paul has been programming in one form or another for over 20 years. After several years using C++ and a brief period using C#, Paul is now happy somewhere he hoped he'd never be, programming in Java.

After time in industries such as marking machinery, direct mail, mobile phones, investment banking and Internet TV, Paul is currently working for a company based in Norwich where he heads up an ever growing team of senior and highly skilled people.

When he's not programming and family life allows, Paul thoroughly enjoys science fiction, heavy metal and cycling.

Session description: I work for a young company that has made a big impact in its market and has quickly established a strong foothold and a growing reputation for product innovation and time-to-market delivery.

A company that at times needed to be “more agile than agile”, as was a frequent refrain of the CTO. In the early days, like many start-ups, requirements were changing on a daily basis and the software needed to keep up with it. Right from the beginning, Agile was the intended methodology, but it was impossible to get the requirements to stand still even for a five day iteration (as is often the way with an owner occupied start-up and the race is on to ‘deliver’). Company growth was phenomenal. However, the requirements did eventually start to stabilise enough for Agile to become a real proposition.

‘Agile is a journey not a destination’ describes a' software team's two and a half year journey from inception to really becoming agile, the evolving process that was adopted and the key lessons learnt in the first iterations.

In the first part of the presentation I will look at how the' software team grew into one of the most technically proficient and successful teams in the area, examining some of the triumphs and pitfalls along the way. I will describe the period from the heady early days to the a time when the requirements finally began to stabilise enough to enable the team to stand back (for a moment) and consider how Agile could be effectively implemented.

I will look briefly at the agile practices, such as unit testing and continuous integration, that should not be taken for granted in any software development, not just Agile software development. I will then go on to describe some of the obstacles that were encountered and how they were overcome, including how buy-in from more traditional project managers was achieved. Also, I’ll provide some key lessons on how you can effectively manage the transition from a waterfall mindset to an agile one; e.g. how to dovetail a business process map with an Agile story and winning the hearts-and-minds of all concerned.

Finally I will describe the development process followed and the lessons learned in the early iterations; like the need for visibility and continuous and free flowing team communication. No agile process is perfect first time and like software, the process must evolve.

Sunday, 22 August 2010

The Java Programming Language

By Ken Arnold, James Gosling, David Holmes
ISBN: 978-0321349804

I decided to read this book about 18 months after having to learn Java in a hurry after discovering what I had been lead to believe was a C# role turned out to be a Java role. Despite several years of programming in C++ and C# I figured there must be lots of stuff that was different in Java and that this book would be a good way to find out. The first chapter is a 40 page general introduction to Java and I found it such a dry read that I gave up. Then, twelve months later, I decided I really should read it cover to cover to find out what I was missing and it took me five months to do it!

Although solid and reasonable well written the book is a dry read most of the way through. The chapter on streams is especially hard going. Although in many cases each method of a class being discussed is described in detail, this book represents a medium level (as opposed to high or low level) introduction to the language. As you would expect it covers classes, interfaces, inheritance, polymorphism, enums, control flow, generics, threading, reflection, etc. so you do get a good overview of the language. However it does not go into any detail about how to compile or run Java programs, neither does it mention ANT or describe how to create JARs. If you want a practical tutorial, this is not the book for you.

I didn't agree with a lot of the “good coding style” suggestions such as using a fall through comment in switch blocks to tell the reader of the code what he should already know the language does or using continue in a bodiless for loop as a semi-colon may get deleted or forgotten. Many people, including myself and the creators of the spring library, believe that checked exceptions are a bad thing in most cases and should not have been added to the lanuguage, so I find bad advice like “Nearly all exceptions you create should extend Exception, making them checked exceptions” appalling. There are a number of examples of poor practice throughout the exceptions chapter.

Overall I think most Java developers would benefit from reading this book just to plug a few of the inevitable gaps in their knowledge. It is hard going, but worth it. As it covers Java 1.5 and Java 1.7 is nearly upon is, it would certain benefit from an update and a review of good programming practice.

Thursday, 5 August 2010

Agile Cambridge 2010: Agile is a journey not a destination.

I have just had confirmation that I will be speaking at Agile Cambridge at 2.15pm on Thursday 14th October 2010. Please come and see me!

Session title: Agile is a journey not a destination.

Session type: Case Study / Experience Report

Session duration: 45

Session abstract: Agile is a journey not a destination describes a software team's two and a half year journey from inception to really becoming agile, the evolving process that was adopted and the lessons learnt in the first iterations.

Session description: This is a success story. A young company that has made a big impact in its market and has quickly established a strong foothold and a growing reputation for product innovation and time-to-market delivery. A stretching but credible business strategy will see the company broaden and deepen its market proposition; a future that is critically enabled through a fully distributable software platform.

A company that at times needed to be “more agile than agile”, as was a frequent refrain of the CTO. In the early days, like many start-ups, requirements were changing on a daily basis and the software needed to keep up with it. Right from the beginning, Agile was the intended methodology, but it was impossible to get the requirements to stand still even for a five day iteration (as is often the way with an owner occupied start-up and the race is on to ‘deliver’). Company growth was phenomenal (11 to 100+ people in a little over two years). However, the requirements did eventually start to stabilise enough for Agile to become a real proposition.

‘Agile is a journey not a destination’ describes a software team's two and a half year journey from inception to really becoming agile, the evolving process that was adopted and the key lessons learnt in the first iterations.

In the first part of the presentation I will look at how the software team grew into one of the most technically proficient and successful teams in the area, examining some of the triumphs and pitfalls along the way. I will describe the market opportunity that the company spotted and how the business responded rapidly to meet and exceed the expectations of its new customer base; and how the urgency to deliver a proposition affected the software development team. I will then describe the period from the heady early days to the a time when the requirements finally began to stabilise enough to enable the team to stand back (for a moment) and consider how Agile could be effectively implemented.

I will look briefly at the agile practices, such as unit testing and continuous integration, that should not be taken for granted in any software development, not just Agile software development. I will then go on to describe some of the obstacles that were encountered and how they were overcome, including how buy-in from more traditional project managers was achieved. Also, I’ll provide some key lessons on how you can effectively manage the transition from a waterfall mindset to an agile one; e.g. how to dovetail a business process map with an Agile story and winning the hearts-and-minds of all concerned.

Finally I will describe the development process followed and the lessons learned in the early iterations; like the need for visibility and continuous and free flowing team communication. No agile process is perfect first time and like software, the process must evolve.

This presentation has been written especially for Agile Cambridge, but will probably be given a warm up at ACCU London.

Intended audience: Software developers and project managers.

Session outputs: None

Biography:
Paul has been programming in one form or another for over 20 years. After several years using C++ and a brief period using C#, Paul is now happy somewhere he hoped he'd never be, programming in Java.

After time in industries such as marking machinery, direct mail, mobile phones, investment banking and Internet TV, Paul is currently working for a company based in Norwich where he heads up an ever growing team of senior and highly skilled people.

When he's not programming and family life allows, Paul thoroughly enjoys science fiction, heavy metal and cycling.

Nathaniel Grenyer

It's been a while since I have had chance to blog and this time it's with good reason! I am very happy to say that Charlotte and I had a baby on Monday (2nd August 2010) at 8.53am. After going to the hospital on Saturday at 4pm and following a long painful labour, Nathaniel was finally born in a speedy 90 seconds. I almost missed it! He was born at the very healthy weight of 7lb2. Mother and baby are continuing to do very well! I need sleep.....

Sunday, 23 May 2010

Falling Off A Log

This was this first Software East presentation I have attended. It was hosted at the Redgate offices just off the A14. They were very nice, if not as technologically advanced as Morgan Stanley. It just so happened that Allen Kelly, the speaker, was arriving as I phoned him from the car park, so we wondered in together to find no receptionist and a sign directing us to the Seagull Suite on the first floor. From the first floor there was no indication of where the Seagull Suite was, so Allan gave Mark Dalgarno, the event organiser a call and he showed us to the suite via the “SQL Servery”, Red Gate's appropriately named cafeteria.

The presentation was scheduled to take place between 6.30pm and 8.30pm. Two hours is a long time for these events, even though I can imagine Allan speaking for two hours without a problem. I found out that the first half hour is for networking and buffet eating, so I tucked in and chatted to Allan and Pete Goodliffe.

Allan spoke about setting up your own business. He believes that it's as easy as falling of a log and it is! He pointed out that all you need to do is pay an accountant and they set it up and do all the legal and financial stuff for you. I know this to be true as I have done it.

Allan's main thrust though was that there needs to be at least two of you, a techie and a salesman. That way you may just make it to through your first year. Again, the same thing had occurred to me. Whenever I have thought of setting up my business and going it alone I've always had two problems, I'm no good at selling and I don't have an idea for a product. A salesman wouldn't necessarily have an idea for a product, but they should be able to sell!

Allan went on to explain how he missed out on making a billion dollars by not developing an idea for a product he had early in his career that someone else later did. I did have some sympathy, but mostly envy.

Allan over ran and after questions at the end he finished about 8.30pm. The most significant question asked from my point of view was where do us techies find a salesman and, unfortunately, no one really had an answer.

The rest of the group stayed to polish off the buffet and do some more networking while I sloped off for the drive back to Norwich.

Allan's slides are available here: http://allankelly.blogspot.com/2010/05/falling-off-log-slides-online.html.

Tuesday, 18 May 2010

User Stories Applied – For Agile Software Development


by Mike Cohn
ISBN: 978-0321205681

After reading Agile Estimating and Planning, also by Mike Cohn, I was rather disappointed with User Stories Applied. Then I saw that Agile Estimating and Planning was published in November 2005 and User Stories Applied was published twenty months earlier in march 2004. A lot of the material in User Stories Applied forms the basis for and is expanded in Agile Estimating and Planning. Therefore I have come to the conclusion that Mike Cohn spent the twenty months between the two books improving as a writer! However, I think there is great scope for merging the two books and coming up with a better title. There is not enough user story based material here for a single book.

Only about half the book is actually about writing user stories. The other sections cover things like planning and testing. There is also some discussion about identifying roles within a system which, on the first read, felt a bit thin. Then when the case study came at the end and I had had chance to think about user roles in my own context I started see how useful defining them could be.

As you would expect, user stories are talked about in a reasonable amount of depth and most of the advice seems good to me. One of the main points I liked was the clear explanation of how user stories differ from tradition requirements capture and upfront design.

Mike Cohn asks questions at the end of each chapter. At the end of the book there are two appendices. One giving an introduction to XP and the other the answers to the questions.

Overall User Stories Applied is a little bit killer, but mostly filler.

Sunday, 18 April 2010

ACCU Conference 2010

The Roots of Scrum: How the Japanese Lean Experience Changed Global Software Development


Jeff Sutherland

Dr. Jeff Sutherland covers the history of Scrum from its inception thru his participation with Ken Schwaber in rolling out Scrum to industry, to its impact on Google, Microsoft, Yahoo, Oracle, Siemans, Philips, GE, and thousands of other companies. He describes the relationship of Scrum to experience at Bell Labs, MIT, iRobot, and the Grameen Bank, his communications with Kent Beck who used Scrum experience to help create XP, and how the Agile Manifesto accelerated Scrum adoption. Most important, he concludes by describing how team spirit is at the root of product innovation and hyperproductive teams and how that spirit can transform organizations.

Just as last year with Robert Martin's key note, the 2010 ACCU conference got off to a storming start with this key note from Jeff Sutherland, that I wish I could have got my entire team, the managers and to some extent the board to see. It contained good explanations about so many things about Scrum that I have been trying to explain for some weeks now.

Jeff Sutherland, one of the fathers of Scrum, described how Scrum is based on leadership, honesty and transparency and how, in comparison, fraud, greed and corruption fuelled the current global financial crisis. He went on to explain how Toyota's lean Scrum methodologies helped it to put its main competition, General Motors out of business and how, when it let leadership, honesty and transparency slip, it got into trouble that resulted in car recalls. He also described how lean allowed Toyota to develop the Prius in half the normal time by removing waste and impediments form the project. This case study also helped to demonstrate how lean agile methodologies helped define Scrum.

In talking about Scrum itself, Dr Sutherland went on to describe how Scrum:

  • Removes management practices in favour of leadership
  • Empowers employees
  • Uses rules and procedures as enabling tools
  • Uses hierarchy to support organisational learning

With the use of a diagram, Jeff Sutherland, showed how simple a framework Scrum really is. He went on to explain how Gantt charts are always 100% wrong, as things change quickly and they become out of date and how teams must be able to self-organise in order to be truly agile.

Introduction to Scrum: Shock Therapy -- How new teams in California and Sweden systematically achieve hyperproductivity in a few sprints


Jeff Sutherland

New teams need to learn how to do Scrum well starting the first day. This talk will describe how expert coaches at MySpace in California and Jayway in Sweden bootstrap new teams in a few short sprints into a hyperproductive state. This requires new teams to do eight things well in a systematic way. Good ScrumMasters with make sure their teams understand these basics for high performance and great ScrumMasters will make sure the teams execute all of them well. This session will review the critical success factors for new Scrum team formation.

Hoping to learn some more about Scrum I want into Dr Sutherland's follow-up presentation and I wasn't disappointed as there was more of the same! It was good to have the idea that Sprints could be one, two, three or four weeks as I had previously believed that Sprints had to be 30 days to be Scrum.

Jeff Sutherland described how he encourages Scrum to be implemented and understood from board level down and two of the main things that get enforced, by the board, are Test Driven Development (TDD) and Continuous Integration (CI). I see these as two of the bare minimum requirements for software development.

I especially like the definition of “done” given:

  • Feature complete
  • Code complete
  • No known defects
  • Approved by product owner
  • Production ready

Dr Sutherland reiterated his previous point that Scrum should be lean and reminded me that although the right way to estimate stories is with relative story points, in a Sprint planning meeting those stories should be broken into tasks and real time estimates given to each one.

Real QA - the argument for smarter quality assurance than mere testing


Tom Gilb

Traditional testing, as a means towards quality assurance, is far too costly and far too ineffective. There are much smarter ways to approach software quality. This session will argue with facts for a half dozen more-cost-effective ways to get reliability and all other qualities, like usability, security, adaptability, into your systems, than conventional testing.

It seems that Scrum themed sessions are the order of the day for me as Tom Glib works closely with Jeff Sutherland and both attend each others presentations. I went into this presentation unsure what to expect and hoping to learn something. Although I enjoyed it and may just possibly have missed something subtle, it appeared the whole point was that quality should be specified quantitatively in requirements, and those requirements should also be high quality and bug free, rather than trying to ensure it with only testing at the end.


Jon Jagger's DOJO


I was invited, well it was more like press ganged, to a late collaborative programming session. I was a member of one of five pairs who were developing a simple unsplice function and accompanying tests. We ran several iterations and were informed we should be working as group, rather than compete. At the end of each iteration the people in each pair were changed, and each pair would work on another pairs code. It was an interesting look at the way teams collaborate together in an agile environment. In retrospect I wish we'd planned and shared a bit better, but with the information we were given I think we did quite well.

Hello, I'll Be Your Tester Today


James Bach

This talk is how I introduce myself to programmers. It is especially aimed at programmers who may wonder why any intelligent person would willingly be a tester, and why projects needs testers, and how to work with testers. I will talk about what makes skilled testers different and special and about the commitments I make to the programmers I work with. I will help you set a high, but reasonable standard for the testers you work with.

If I am successful, then by the end of my talk, at least a few programmers in the audience will have become testers.


The ACCU conference has always been about quality, but this year is very special, especially with the keynote speakers. James back is a highly charged and very amusing individual. In fact he;s the sort of tester I'd like to be working with.

He explained that he started his testing career as a test manager for Apple about 20 years ago. Throughout his key note, James highlighted the many differences between testers and developers. Including the fact that, apparently, testers have more social interaction. Another subtlety he pointed out was that testers don't break code, developers do and testers do not steer projects, they make suggestions and hold the light so developers can create great code.

One of the best parts of the keynote were the testing related subtitles James added to a clip from The Towering Inferno where Steve McQueen is gathering the requirements he needs to fight the fire. I can't describe its brilliance in a way that will do it justice here.

The point that resonated the most for me is that testers need to be able to think their way around a system with or without a specification or requirements. They need to think outside the box as, after all, requirements are often rumours, right? This is the oppostie end of the scale from what Tom Gilb was saying yesterday. From an understanding of what the system should do and bags full of common sense testers should be able start testing and test effectively.

Genemodulabstraxibilicity


Steve Love

The title says it all! If it's hard to write unit tests, or they take too long to run, if your plugins need the whole application for their distribution, if you can't (re)use a bit of your colleague's code without importing the entire team's work, if your multi-threaded code performs better when you run it sequentially, or you've got 5 versions of the same 3rd party library littering your source repository, then you're suffering from this. Or perhaps just part of it...

Modern languages provide us with many tools for creating beautiful, modular, general, flexible and simple abstractions, yet it seems they give us even /more/ tools for writing ugly, monolithic, specific, rigid and complicated, er, /concretions/.

With examples of both kinds in C#, Python, C++ and maybe even C++0x (if it stays still long enough to get the syntax right :-)), this is a talk about our (code's) propensity for wearing too many hats.


Steve is one of my oldest friends from the ACCU, going back to the first conference I attended in the early naughties. The lessons and observations he discussed in the session are what the ACCU is all about for me. He described lots of the common pitfalls of the code that a lot of people write and how to avoid them sensibly.

There was of course just the right amount of singleton bashing and plenty of humour, not to mention of course, the subliminal elephant that no one was meant to be thinking about. Other important points made were that too many comments is a sign of poorly written code and public inheritance is the strongest form of coupling.

What surprised me the most was Steve's description of a painful code review where he was pulled up for using single entry, single exit. The company Steve was working for actually explicitly stated that they tried to enforce multiple exit points. Just when I thought I'd heard it all....

Data warehouse, OLAP, Data Cubes, Business Intelligence - Buzzwords explained


Sven Rosvall

In the database world there are many buzzwords that most software engineers only hear about but never get experience with. This talk aims to clarify what lies behind some of these buzzwords and describe key differences from the more common transactional database. The talk will also provide enough insight for engineers to decide if any of these technologies are useful in their current or future projects.

The presenter has work for many years on the periphery of the databases, wondering about these buzzwords. He eventually got involved with data warehouses and now wants to share his experiences with fellow engineers.


Sven is another ACCU member I've known for many years. His presentation did exactly what it says on the tin. I came away understanding the difference OLTP and OLAP and that we really need to try and break our own databases up onto separate servers to improve performance.

Although I'm still a little hazy on data cubes, I now understand dimensions and how data is reorganised when it is transferred from OLTP to OLAP to make it easier query. This was certainly one of the most useful sessions of the conference so far.

Database Testing Demystified


Sven Rosvall

Testing databases is not as easy as unit testing of classes and functions. Databases are full of state and internal logics which must be set up before testing can start. There are also lots of dependencies that are difficult to isolate or stub out.

This presentation will look at some techniques to create automated tests for databases and how to debug SQL code including single stepping stored procedures. We will automate database testing with the use of popular unit testing frameworks. We will test simple CRUD statements, calls to stored procedures and verify triggers. Test suites in Java and .Net will be demonstrated.

We will also see how a database can be developed with agile methods. Databases are traditionally developed up front as the database schema is difficult to change later.


Another great session from Sven (immediately following the previous one) even if the material from the second half does overlap what I'm speaking about a fair bit. The highlight here for me was seeing the SQL Unit Testing Framework SPUnit in action and the ability to step through stored procedures in SQL Server Management Console.

TDD at the System Scale


Steve Freeman, Nat Pryce

We present our experience applying "system-test first" test-driven development (TDD) in the development of large systems and systems-of-systems. We try to address integration and system testing as early as possible. The sooner the system is in a deployable state, the easier it is to react to changing business needs because we can deliver new features to users as soon as is deemed necessary. We therefore start by writing tests that build and deploy the system and interact with it from the outside and, to make those tests pass, add code to the system in the classic "unit-test first" TDD style.

Many teams applying TDD start writing unit-tests and leave integration and system testing until late in the project because they find it difficult to write tests that cope with the distributed architecture and concurrent behaviour of their system. We will describe how we address common pitfalls, including unreliable tests, tests that give false positives, slow-running tests and test code that becomes difficult to maintain as the system grows.

We will also describe how writing system tests guides our architectural decisions. Writing unit tests first guides design of the code to be flexibile and maintainable. In a similar way, we have found that writing system tests first guides the architecture to be easier to monitor, manage and support.


A couple of colleagues and myself saw Steve and Nat speak at JP Morgan in February and it was a little bit like disorganised chaos with Steve doing most of the talking and Nat chipping in. There was a marked improvement this time, with Nat doing the majority of the speaking.

I was a little bit concerned to see that they were advocating starting with system level tests before unit tests, but I can see how it might work in some circumstances. The same old system level problems, such as driving the GUI, faking external systems, etc, are still there, but Nat and Steve came up with some interesting ideas to overcome theses.

The main points that stood out for me where:

  • Making the system scheduler external so that it can be faked during test.
  • Use an audit interface instead of direct logging so the system can decide what it wants to report as a whole.
  • Add hooks so that you can easily ask the system if it is happy.

Another point I realised is that I really need to read their book!

The Multicore Revolution: We've Only Just Begun


Russel Winder

I will and have travelled a long way to hear Russel speak, even for a short period of time, on many occasions. He is very entertaining and today was no different. Before talking about the architecture of multi-core processors, Russel spoke about the different forces occurring in atoms. Unfortunately it's so long for me since A-level physics, I was rather lost!

The two important points that Russel made were that we need to stop thinking in a single processor, single memory model and consider a mulit-core, multiple memory model and that although the hardware is mostly there, there is a lot of catching up to do on the software side.

Fortunately no kittens were harmed during the production of Russel's slides as he is using open office instead of power point.

Understanding User Stories


Rachel Davies

On traditional projects, software developers are often presented with volumes of requirements that seem to be definitive and yet are full of holes. On agile projects, the whole team gets involved in establishing user stories on index cards. Come along to this session to understand the life-cycle of a user story from inception to implementation. You'll get a chance to practice working through some real user stories. We'll also investigate ways that agile teams handle requirements that don't seem to be user stories.

I didn't read the description of the session sufficiently! So I was a little shocked when the layout of the room indicated it would clearly be interactive. I don't really enjoy that sort of thing, but this was superb and the 90mins just flew by!

This session was, for me, really about confirming what I have read recently about writing user stories. It was nice to know I was generally right and to find ways to smooth some of the rough edges.

We played a game where one person wrote down a story, e.g. “A man opens a door.”. Then the next person draws it and the following person then writes down what they think has been drawn and this goes right around the group. Each person only sees what the previous person has written or drawn. The idea of the exercise is to show how if one person describes something and another person documents it, things get lost and other things get added. The final description was “A man with a hat, closes a door.”

We also did a brief exercise where one member of a three or four person team is the product owner and the other members of the team ask them questions to determine what is needed for a system and write stories. This also worked very well.

Based on what I saw I'd be very happy to have Rachel come and coach my team.

FindBugs: Testing (Java-) Code Against Bugs And Defects


Bernhard Merkle

This session should be really fun. We will make a deep dive into findbugs, a very useful tool which every programmer should use to test Java code against potential bugs, defects and antipatterns.

After a first overview of the problem domain (static analysis), we will take some of Joshua Bloch's "Effective Java" Rules from his book (a ACCU mentored developer mailing lists currently runs...) and see how / if they can be implemented in a tool like findbugs. I will show how findbugs works internally and we will implement a new bug detector (findbugs rule) to find specific defects we are interested in.

Additionally we cover different levels of static analysis like code-, design- and architecture-level. Interestingly findbugs checks code and design level, but fails itself (!) on the architecture level; which means the tool itself suffered major architecture erosion from version 0.7 to the current 1.3.8.

I am participating now in the findbugs project and contributed several architectural refactorings on the findbugs 2.0 branch (see the sourceforge/googlecode SVN repository) which is currently under development and should hopefully be finished during the time of the ACCU 2010 conference. We will see, how far an automated and tool supported approach can lead to better results and how tools like findbugs can discover areas of code- and design-erosion and suggest improvements. Additionally we will look at the next generation of analysis which is architecture analysis.


Bernhard took us through a very interesting look at what findbugs provides and showed us many examples of bugs in established code bases, such as Eclispse and the Java SDK itself, that could have been found simply by running findbugs. He included some great photos of non-programming bugs and lots of excellent humour.

Findbugs can also highlight architectural problems and Bernhard showed us how the architecute of findbugs itself has got steadily worse over the years.

Bernhard convinced me that we should add findbugs to or static analysis arsenal, which current consists of just PMD.

Saturday Keynote


Due to the volcano eruption in Iceland, Dan North didn't make it to the conference for the Friday keynote, so Russel Winder (as described above) moved his keynote forward. So the Saturday keynote was replaced with four fifteen minute “Lightning talks”. Lightning talks are just very brief talks, usually only five minutes and usually for people who aren't already speakers to give them a chance to try it out. On this occasion the talks were given by four conference speakers:

  • Bob "Unclude Bob" Martin – The birthday problem.
  • Walter Bright – The biggest problem with C.
  • James Bach – Testing models.
  • Jim Hague – Are you getting enough?

All were humorous in one way or another and all very good.

Coupling as resistance to change, understanding and fixing it


Tony Barrett-Powell

Coupling, the number of things a unit of code depends on, is an important consideration when designing and maintaining software. Without due care a slow increase in coupling between units over a few releases of a software product, or even over a number of iterations within a release, can lead to software that is difficult to change, or worse results in a ripple effect throughout seemingly unrelated units. We cannot write software without some coupling, how else would the code achieve anything? Thus, coupling is not a bad thing in itself, it is the degree to which a unit is coupled to other units that can be undesirable, yet is not an absolute measure. Understanding of what coupling is, its many forms and how to recognise them is useful if we want to avoid unnecessary coupling in the software we create. It is important to control coupling in software if it is to be improved over a number of releases, as high coupling slows development, increases time to market and inevitably lost revenue.

This session attempts to explore coupling in all its manifestations, examine the difference between good and bad coupling and to consider its bedfellow cohesion. The session will also explore the techniques used before, during and after the act of design which can be used to reduce unnecessary coupling and as an aside looks at those which can lead to increased coupling. The intent of the session is to arm those designing and writing software with the understanding and techniques to create loosely coupled and maintainable software.


I have known Tony a good few years, but this is the first time I have seen him speak. He is very good and this subject is close to my heart.

Tony explained how lots of coupled code is very difficult to change and even harder to understand. He took us through inheritance coupling and temporal coupling and explained cohesion as a measure of the strength of functional relatedness of elements within a module. If it's all together it's cohesive, if it's split up it's coupled.

Tony continued by explaining Afferent and Efferent coupling. Afferent coupling occurs at the package level and efferent coupling is the number of classes inside a package that reference classes outside of a package.

A Simple Matter of Configuration - how can we tame the complex world of configuration?


Roger Orr

Configuration is a vital element of many programs. However it is often hard to get configuration right, leading to people wasting time and programs that do not work correctly.

In my experience explicit discussion of design options for the configuration of a program is rare and, all too often, the choice is made arbitrarily. I believe that looking at the usage patterns of the program early on helps to pick the best method(s) for configuring it and hence reduce the cost of problems caused by configuration issues.

Configuration is a complex subject and there doesn't seem to be an obvious single solution that works in every case, but we can try to fight against the common 'anti-pattern' of using multiple, unrelated, configuration techniques at the same time.

I will look at some of the issues surrounding configuration; firstly by trying to answer the "six key questions" (who, why, what, where, when and how) for this subject to help understand the size of the problem and the forces at work.

I'll then sketch out some possible design patterns and look at their trade-offs and interaction with the intention that I (and you) can reduce the pain of getting programs working in different environments by making more informed and deliberate decisions.

I am looking at the problem in the general case, using examples from various problem domains, and expert knowledge of a particular language or API is not assumed.


This was the last session I attended as I was speaking in one of the final slots of the day. Again, I have known Roger, through the ACCU a long time and shared many a drink and lunch with him. He took us through a humorous look at how to configure applications. This wasn't a look at build configuration, but the way we actually pass settings to a program.

I have come across many of the same problems in my career, and although there was no specific solution to the problem, one of the proposed solutions, storing settings in a database is one I use regularly. Roger showed me lots of methods and their pitfalls, that I had never even considered!

Enterprise Web Application Development in Java with AJAX and ORMs


Paul Grenyer

Recently Java enterprise web application programming has been leaning towards a more classical J2EE approach. Traditional Java Server Page (JSP) programming, and even libraries such as Struts, are being replaced by new AJAX libraries that make GUI programming more straight forward, robust and easier to unit test.

In this session I will look at what an enterprise web application is.

I will demonstrate how to develop a more robust GUI with an AJAX library and how to create a more object orientated Data Access Layer (DAL) with an Object Relational Mapping (ORM) library.

After defining what an enterprise web application is I will move on to demonstrate how to create a DAL, with real code examples, and explain how to use a registry to abstract away Data Access Objects (DAOs) so that the real DAOs can be used in production and integration testing while seamlessly substituting mock objects for unit testing.

Then I will look at an AJAX library and demonstrate how to create the presentation layer in Java, again with real code examples, and make Remote Procedure Calls to access the DAL. I will then look at how to integrate the AJAX library into traditional Spring MVC in order to tap into the vast library of functionality that the Spring Framework can provide for web based enterprise application. I will explain how the tools provided by Spring make integration testing of DAO objects very simple.

Finally I will look at how to use Spring Security to authenticate users of the application and secure individual Remote Procedure (RPC) calls made from the client application, running in a browser, to the server.


I don't know how good I was, but this presentation flowed for me easier than any other presentation I have done. I have never managed to speak for the full ninety minutes before and I came in on time.

It was one of the final sessions of the conference, I was up against some stiff competition and most people had actually already gone home. Even so I had an audience of about half a dozen.

My slides are available here: http://paulgrenyer.net/dnld/Enterprise_Web_Application_Development_in_Java_with_AJAX_and_ORMs.pdf.

Finally



This was the best ACCU conference I have ever been too, simply because of the amount directly useful information I was able absorb. I'm sure next year will be even better.

Thursday, 8 April 2010

Agile Project Management with Scrum

by Ken Schwaber
ISBN: 978-0735619937

I bought this book when it looked like I was going to be doing the Certified Scrum Master course at the ACCU Conference, as it's required reading. I was hoping for a detailed explanation of the Scrum process, but this book actually contains a number of case studies which describe how Scrum has been implemented in different places, what worked well and what didn't.

Even thought the book didn't contain what I expected, I found it quite interesting and informative and it made me think about how our agile team could improve. It's quite a short book at only 153 pages and very easy to read. Consequently I ploughed through it in about a weeks intensive reading.

Saturday, 27 March 2010

Agile Estimating and Planning

by Mike Cohn
ISBN: 978-0131479418

I bought this book because I'm generally rubbish at estimating (I usually under estimate). Also, although we have the technical elements of agile (source control, unit tests, continuous integration, etc) sorted, my agile project management is not all it could be. Agile Estimating and Planning may be as close as I ever get to a silver bullet.

To be honest I expected to be let down and that the scenarios described in the book would not match the situations I find myself in. I was not let down at all. The book covers both planning when features are important and planning when a deadline is important.

It taught me that it was wrong to break stories into tasks when release planning and to leave that for iteration planning. The book discusses the use of both story points and ideal days in estimating, what they both are, the differences between them and then suggests you should use story points.

It described what release and iteration planning are and when to use them. It also discusses how to predict, where necessary, and how to measure velocity in order to calculate the duration of projects. One of the most important things covered from my point of view was how, when and with what to report to the product owner and stake holders.

The book finishes with a 60 page case study. I was tempted not to bother reading this as it goes over the main points covered in the rest of the book again. I was glad I read it and if you buy this book you should read the case study if you read nothing else. It helps put in context how estimating should be done and describes the processes surrounding it.

All I have to do now is write a distilled version for my team, including the project managers, product owners and stakeholder and put it into practice.

Friday, 19 March 2010

Sunday, 28 February 2010

Sustainable TDD Review - ACCU London February 2010

I always say this and I'll say it again: London is a long way to go from Norwich for the evening. On this occasion it was worth it, as it always is for ACCU London. This dark, cold, late February evening had the added drawback of torrential rain. To make matters worse, while looking for the JP Morgan building at 125 London Wall, we got to the junction of Moorgate to find a sign suggesting we had been walking in the wrong direction. With faith in a printed google map and iPhone GPS we forged on another fifty yards and found 125 London Wall exactly where we expected.

I have been in many offices belonging to a number of financial corporations and JP Morgan is no different to any of them, except for the lifts! Instead of calling the lifts by pressing a button next to them, you have to go to a set of small screens in the middle of the lobby. On one of these screens you select the floor you want and it indicates which lift you have to get in. The assigned lift then opens and takes you to the selected floor. Being a techie I couldn't help thinking how cool this was, but I did find myself wondering what you would do if you changed your mind about which floor you wanted once in the lift. We ascended 17 floors in what didn't feel like not enough time. However the view form the window confirmed just how high we were.

Test Driven Development (TDD) and the benefits it brings are well understood by most software developers and even most companies and managers. Still, every year at the ACCU conference someone does an introductory presentation on TDD. So, I was intrigued when I read about Steve and Nat's presentation on Sustainable TDD as it sounded like the next step.

Steve Freeman and Nat Pryce have a book to sell: Growing Object Orientated Software [1]. Their presentation was based around one section of the book. It was only about 45 minutes long, but there was a fairly long discussion after. During the initial 45 minutes Steve did the majority of the talking and took us through some simple techniques that would improve the readability and maintainability of unit test code.

Steve started off by showing us some lengthy, quite messy unit tests of the sort we have all probably seen or even written at one time or another. Then there were some examples and discussion of how to name test methods effectively. Instead of naming test methods after the method under test we should give them names that describe what is being tested. For example:

holdsItemsInTheOrderTheyWereAdded()
canHoldMultipleReferencesToTheSameItem()
throwsAnExceptionWhenRemovingAnItemItDoesntHold()

The problem with “magic numbers”, literals used directly in code, has been understood for some time, but as Steve explained they still get used in test code, so we should try to use self describing variables instead. For example:

final static Chat UNUSED_CHAT = null;
final static int INVALID_ID = 666;

Often tests require one or more complex objects to be constructed before the test can be carried out. This setup code can often be very verbose:

Order order = new Order(
new Customer("Sherlock Holmes",
new Address("221b Baker Street",
"London",
new PostCode("NW1", "3RX"))));
order.addLine(new OrderLine("Deerstalker Hat", 1));
order.addLine(new OrderLine("Tweed Cape", 1));

The verbosity can be reduced by using a builder, similar to those described in item 2 of Effective Java [2]:

new OrderBuilder()
.fromCustomer(
new CustomerBuilder()
.withAddress(new AddressBuilder().withNoPostcode().build())
.build())
.build();

Steve described quite a few examples of how you might use builders to repeatedly build test objects with different properties. Although this technique could be useful, it would only be where you have a large number of objects to construct or a number of different permeations of a single object that takes a large number of parameters.

Steve then went on to describe a technique that I consider a little controversial. He suggested that the message parameter of JUnit's asserts should be used to help diagnose the problem when a test fails. For example:

assertEquals("balance", 16301, customer.getBalance());

This to me is tantamount to using comments. Here, someone could change the test to test something else and not bother to update the message. However, in simple assertions like this with one word descriptions this is unlikely and the message is is likely to be very useful.

Then Steve explained something that appealed to my colleagues and I as pure genius in its simplicity and potential usefulness:

Date startDate = namedDate(1000, "startDate");
Date endDate = namedDate(2000, "endDate");

Date namedDate(long timeValue, final String name) {
return new Date(timeValue) {
public String toString() { return name; }
};
}

Here if an assertion involving startDate or endDate fails, instead of the actual date being reported:

java.lang.AssertionError: payment date
Expected: [Thu Jan 01 01:00:01 GMT 1970]
got: [Thu Jan 01 01:00:02 GMT 1970]

you get a description of the date:

java.lang.AssertionError: payment date
Expected: [startDate]
got: [endDate]

I think the potential usefulness of this technique speaks for itself.

Discussion continued and Alan Stokes pointed out that only code with unit tests should be refactored and asked how you therefore refactor test code, as it has no tests. The answer was that you first break your production code so that the tests fail, refactor the test code making sure it still fails and then fix the production code and make sure the tests still pass.

Those were the highlights of the presentation for me, although Steve and Nat did cover some other techniques and examples. It was certainly enough for me to buy their book.

References

[1] Growing Object Orientated Software by Steve Freeman and Nat Pryce, ISBN-13: 978-0321503626

[2] Effective Java by Joshua Bloch, ISBN-13: 978-0321356680

Saturday, 27 February 2010

EJB3 In Action

EJB3 In Action
By Debu Panda, Reza Rahman, Derek Lane
ISBN-13: 978-1933988344

I bought and read this book as I wanted to learn about Enterprise Java Beans having only used Spring for Enterprise Java development up to this point. This is an excellent book for just that.

It explains in a reasonable amount of detail what stableful and stateless session beans, message driven beans and entity beans are. After a number of chapters describing how to use session beans and a further chapter on message driven beans a large amount of the book is turned over to entity beans and the Java Persistence API. As a user of Hibernate I found going over a very similar API somewhat tedious in places, but I am sure this would not be the case for a novice ORM user. I also think Hibernate does it better.

I found the general style of the book, although chatty, quite easy to read. Although the authors mention many of the areas where Spring has similar or even better functionality it is clear, as you would expect, that the authors favour EJB in all cases. Even when EJB is still quite heavy weight in comparison.

My biggest criticism of the book is that it's more of a text book that a practical guide. Although the source code for the example application is available to download, it is not possible to put the application together just from reading the book and deploying an application to a container is handled very late in the book. If I was actually wanting to do some EJB development at this stage I would want to try things out and therefore having deployment examples at the start of the book would be paramount.

Saturday, 13 February 2010

Linux Fortinet VPN Client

Ever since the company I work for changed to a Fortinet VPN I have been looking for a Linux client that will work with Ubuntu. Today I found one:

forticlientsslvpn_linux_4.0.2010.tar.gz

Install and use instructions can be found here.

Referencing one Nexus repository from another

If you want to reference one (master) Nexus repository from another (slave) Nexus repository this is what you have to do:

Add 2 proxy repositories to the slave Nexus, one configured for releases and one configured for snapshots. Set the remote url in both to:

http://<master>:<port>/nexus/content/groups/public

Then add the releases proxy to the public group and the snapshots repository to the snapshots group.

Thank you to Damian Bradicich of the nexus-users group for these instructions.

Monday, 18 January 2010

ACCU London March 2010

I will be giving my Enterprise Web Application Development in Java with AJAX and ORMs presentation for ACCU London at 7pm at 7 City (4 Chiswell Street, London, EC1Y 4UP) on Thursday 18 March 2010.

Registration will be required.

Who's the daddy?


My blog has always been personal and professional so I want to share the most important news I have ever had and the best thing that's happened to me since I got married.

Thursday, 14 January 2010

Data Access Layer Design for Java Enterprise Applications

Java Database Connectivity (JDBC) can be used to persist Java objects to databases. However JDBC is verbose and difficult to use cleanly and therefore is not really suitable for enterprise scale applications. In this article I will demonstrate how to replace JDBC persistence code with an Object Resource Mapper to reduce its verbosity and complexity and then, through the use of the appropriate patterns, show how you might design a more complete data access layer for a Java enterprise application.

Read more.

Saturday, 2 January 2010

Installing VMWare 2.0.x on Ubutnu 9.10

There are some known issues with installing VMWare 2.0.x on Ubuntu 9.10 which are described well here:

http://www.ubuntugeek.com/how-to-install-vmware-server-2-0-x-in-ubuntu-9-10-karmic.html

so I am not going to repeat them. However I will add the following:

  1. Make sure you have build-essentials installed so VMWare can build its special kernel modules:

    sudo apt-get install build-essentials

  2. Make sure you have the linux headers installed. To obtain your kernel version execute:

    sudo uname -r

    Then to install the headers:

    sudo apt-get install linux-headers-<kernel version>

  3. In the configuration step, following the install, you will be asked which user you want to be able to log into VMWare as. The default is root and since root is not enabled by default on Ubuntu you should choose another user with root permissions rather than enabling root.