My real name

“If you have a garden and a library, you have everything you need.” -Marcus Tullius Cicero

“It’s no coincidence that in no known language does the phrase ‘As pretty as an airport’ appear.” -Douglas Adams

“The way you overcome shyness is to become so wrapped up in something that you forget to be afraid.” -Claudia Lady Bird Johnson

Quality is not an optional extra in any part of what you do.

If a customer/client experiences a lack of quality in one area they are likely to jump to the conclusion that issues they are experiencing in another area are due to your lack of quality rather than their own mistakes.

The result of these assumptions is increased calls to technical support, more time spent in technical support investigations and escalations, delays to projects and general loss of confidence in your software.

Far more cost effective to ensure quality is good enough in all areas of what you are delivering.

Generics are a powerful mechanism in Java but with power comes responsibility. The indiscriminate use of generics, especially generic methods, increases the complexity of a piece of code making harder to understand, and therefore harder to debug, reuse, extend, etc.

If a collection is designed to be heterogeneous (contain objects of different indeterminate types) employing generic methods to try and force some more type-safety is likely to be counter-productive.

Just because a programming language has a powerful feature or capability, you are not required to use it all the time.

Recently posted an update to my iPhone/iPod Touch app, Brain Ache in Color on iTunes.

Adds GameCenter support to the free version with scores for partial puzzles solved, and achievements that range from easy to ‘too hard for me’. Also, significantly improved user interface (IMO at least).

The professional version removes adverts, has undo, rotates to four different orientations, and adds ‘fun’ tile styles.

The app does not look too bad on the iPad and plays reasonably well but have added specific support for it to the list of enhancements, along with localization.

“Speech is conveniently located midway between thought and action, where it often substitutes for both.” -John Andrew Holmes

“It usually takes more than three weeks to prepare a good impromptu speech.” -Mark Twain

The circles in Google+ are a good step in the right direction. Maintaining multiple accounts in Facebook so that I can separate technical posts from ‘I do have a life away from computers’ posts is annoying. Circles give me the separation but the focus is wrong.

Social circles form around roles that I play in life, as a father to my children, a colleague to people at work, as an ex-class mate to those I used to go to school with, a Manchester United supporter to English Premier League fanatics, and so on.

Each of theses roles presents me partially and slightly differently. I naturally reveal different items of data to different groups and some roles that I play have additional items of data that are specific to those roles.  For example, work colleagues know and use my work e-mail address and are unaware of any other e-mail addresses. Others use my personal e-mail address and do not use my work e-mail address. As an avid Facebook Scrabble player, my wife has stats about wins and word scores that are specific to her in that role. To those that know me informally, I am Steve. To my children I am Dad. To readers of my book, I am Stephen R. Palmer, so even my name changes according to the role I play. 

So rather than explicitly forming circles of people I know as in Google+, I want to create roles that I play, make visible the data I want to make visible for each of those roles, and associate people to those roles accordingly. 

From a software analysis and design perspective, the modelling in colour technique points to all this nicely.

‘Home is where your heart is’ + ‘My heart was in my mouth’ = ?

‘Home is where your heart is’ + ‘The way to a man’s heart is through his stomach’ = ?

Unit testing in the dim and distant past of the last century meant testing the code I was writing before it was integrated with others’ code. It was testing a chunk of software in isolation from the rest of the application, system or component code.

Unit testing in the JUnit era has slowly come to mean the testing of the smallest practical chunk of software. For mainstream object-oriented languages such as Java and C# this has come to mean testing the individual methods within a particular class. Everything else is considered too wide in scope to be a unit test and should be called functional or integration testing instead.

In turn, this idea of unit testing being the testing of the smallest chunk of software has led to rules appearing about what unit tests may not do:

• talk to the database
• communicate across the network
• touch the file system
• run at the same time as any of your other unit tests
• require special tweaks to your environment (such as editing config files)

All this sort of behaviour must be mocked or stubbed out.

One claim for writing unit tests this way, is that these tests precisely identify where a problem is when they fail, and indicate precisely which code is working when they pass. This reduces the time that would be spent diagnosing problems should a wider-scoped test failed. Of course, this assumes the unit tests will actually help diagnose the problem. 

In fact, the overriding aim of these rules is to keep the tests fast so that they do not impede a developers productivity when run every few minutes or just before committing code to a source-control environment, or as part of a continual/continuous integration environment.

Tests must add value to a project: the benefit of being able to run a test must exceed the cost of writing and maintaining that test otherwise it is a form of waste that according to lean development principles should be eliminated from the process. There is a danger that developers produce a large number of trivial unit tests that comply with these rules but do not earn their keep.

Unfortunately, unit tests complying with these sorts of rules, by definition, are not useful as part of a frequent, regular or continual (‘continuous’) integration build. By definition, tests with wider scope are required here that test that components integrate with each other, that they work correctly together. Developers need to write different automated tests in addition to unit tests for their builds. 

If the current popular definition of unit test is to remain:

• developers need to think about what unit tests to write 
• or find a way of generating this kind of very basic unit tests
• developers need to think about what functional/integration tests are required for the frequent/regular/continual integration builds
• developers need to separate tests intended to be run frequently within an individual developer’s development environment, from those run as part of a continual  integration build, and from those run as part of a regular (nightly or weekly) build.