An interesting analysis from the New York Times of the progressive replacement of traditional fixed-line phones by mobiles.
The Count – Users Are Tossing Their Landlines Overboard – NYTimes.com
Frank Carver's musings about software and life
An interesting analysis from the New York Times of the progressive replacement of traditional fixed-line phones by mobiles.
The Count – Users Are Tossing Their Landlines Overboard – NYTimes.com
A fascinating counterpoint to Gojko Adzic‘s writings on acceptance testing in an agile process.
thekua.com@work » Automated story-based acceptance tests lead to unmaintainable systems
Update: here’s some more discussion on this topic, and how it is affected by the nature of user stories
User Stories are Just Schedulable Change
pair programming is often one of the hardest things to “sell” when implementing XP or an XP style approach to development. Mark Needham has written a nice summary of some reasons for choosing pair programming.
An article with some good tips on avoiding a clash of cultures between developers and testers on an agile project. (note, there may be a click-through ad on this link)
I’m going to have to read these articles. Jason Yip recommends Geeking with Greg: Early Amazon as a fascinating insight into the inception and growth of Amazon.
Steve Freeman has put together one of the most thought-provoking software development articles I have read in a long time – based on application of ideas from a New Scientist article.
An example of poor usability on what should be a transparently simple device.
We use ant, a lot, but I’m getting progressively fed up with it so I’m looking for alternatives.
Ant has several well-known problems, including:
I have recently investigated three alternatives:
gant, gradle and pjmake. Gant and gradle both aim to replace ant with a build system scripted in interpreted Groovy. Pjmake aims to replace ant with a build system scripted in compiled java.
I’m always interested in how other parts of the industry view the key issues in mobile and digital music publishing. It seems like a few people got together for a conference on this topic on 23 September in London. Here’s a few links about the event
EconMusic – the economics of digital music : Blogs : BCS
EconMusic Video: Billy Bragg In Reuters’ Conference Wrap-Up
EconMusic: Direct-To-Fan: Radiohead, Marillion And The End Of Labels
From time to time I toy with the idea of writing a book. One of the things which has put me off is the whole “big project” nature of the task. I am so used to test-driven, small-iteration, early-value working that slogging away for six months or a year on a single task seems particularly daunting.
An interesting possible solution to this is the idea of writing in an agile manner.
This is just cool, in a “don’t know what I’d actually do with it” way. A port of the Squeak Smalltalk environment to the IPhone and iPod touch.
If you see this, it means I have not written a blog post on this site for 24 hours. There’s no need to report me missing, though. It’s just a test of a new plugin I have installed on my WordPress blog.
The Post Queue plugin monitors post history, and if nothing is posted for a configurable interval, selects one from a pool of pre-written articles and posts it. This post is one such canned article. I originally wrote it on 12 September 2008.
There’s a certain amount of “duh” in this article, but what fascinates me is not that reading and writing text messages while driving is a distraction (there’s that “duh” again), but the statistics of how many people do it.
Several software companies make and sell systems which provide a way to buy and download mobile content, including games and applications. Over recent years I have occasionally been involved in the web and mobile front-end of such systems and I am always on the look out for information about what works and what doesn’t. Here’s a critique of T-Mobile’s App Store:
Wendong’s Smart Phone Weblog » T-Mobile’s new App Store: huge disappointment
The industry in which I work involves a fair amount of content delivery over HTTP. or at least it does when the rest of the system is in place to allow people to buy stuff. As such, we have a fair amount of operation and deployment issues around keeping this working. For each new customer in a new part of the world there is a decision about how to serve content and, most importantly, where to serve it from. Making the wrong choice can lead to latency, errors, increased cost, and inflexibility.
So the announcement that Amazon are setting up a service to cater for just this situation is an interesting one. The premise is that Amazon will use their increasing global network of “cloud” servers to shuffle and cache content around the world, and use that adaptability to provide downloadable content from the most appropriate server for the end user.
Every time I read one of these “cloud” announcements, I get a small feeling that I should make some time to prototype something like our current product using these technologies. The potential pay-off of outsourcing the infrastructure could be enormous.
Technology News: Web Apps: Amazon’s New Service to Rain Content From the Cloud
Ever wanted to make a “screencast” (a recording of some on-screen activity, with or without a commentary, typically used for software tutorials)?
I have done a few, but found choosing and configuring screen-recording software to be trickier than it should be. If you also find it a bit cumbersome, then this might be of use – an on-line screencaster which both records and plays using Java.
As we continue to slog onward trying to ease our overall product process into something more agile, adaptable and effective, we continually run into roadblocks. Typically these are legacy process issues, such as an existing “finger in the air” customer commitment suddenly appearing to bypass all the carefully structured estimation and prioritisation. Although irritating, this kind of problem is at least visible. Stakeholders can get into a shouting match with each other and come to some sort of decision.
Sometimes, however, the problems are out of our control. These are the tough ones. The following InfoQ article describe just such a situation, and serves as a cautionary tale for everyone involved in this kind of effort.
InfoQ: Presentation: When Working Software Is Not Enough: A Story of Project Failure
I’m cross. Very cross. Cross with Sun for releasing a new version of Java which shatters both backward- and forward- compatibility. Cross enough that I cannot see any sensible way of moving my software to Java 6 in the near future.
It all started with an innocuous question in a comment on my Punchbarrel blog. I had posted asking for opinions on a move to Java 5, potentially abandoning Java 1.4, for the core Stringtree codebase. The question in the comment was about skipping Java 5 and moving directly to Java 6. This would normally be too big a leap, but I replied that I would endeavour to continue my policy of ensuring my code works with as wide a range of Java versions as possible.
Then I actually tried to do it, and that’s what made me cross. The more I attempted to produce code which would compile and run on Java 1.4, Java 5 and Java 6, the more impossible it began to seem.
I was already aware of the first hurdle. Sun have added new methods to a lot of key JDBC interfaces by tagging them with the new javax.sql.Wrapper interface. This is actually relatively easy to fix in a compatible way. Just add two new methods to each class which implements one of the affected JDBC interfaces:
public boolean isWrapperFor(Class clz) { return false; } public Object unwrap(Class clz) throws SQLException { throw new SQLException("Not a Wrapper for " + clz); } |
The actual method signatures in the Java 6 Wrapper interface are phrased in terms of Generics, but the above stripped version compiles fine using Java 1.4, Java 5 and Java 6 compiler and libraries.
However, even after adding these arguably pointless methods to all my concrete implementations of affected JDBC interfaces, I still had a bunch of compilation errors when using Java 6 libraries. And this is where Sun have really screwed up.
Several other key JDBC interfaces have also been extended. But this time it has not been done by anything as simple as tagging with a new interface. These interfaces have all gained extra method themselves. This should not be a deal-breaker. It should be feasible to just add implementations of these methods to the existing Java 1.4-compatible code. After all, any class is free to define any methods it likes, not just those from an interface.
Nope.
It is simply impossible to add these new methods to a class and have that class still compile in a Java 1.4 or Java 5 environment.
The reason is that these methods are themselves defined in terms of classes and interfaces which do not exist in earlier Java versions. For example, the java.sql.Connection interface gains methods referring to new interfaces NClob and SQLXML
There is no answer to this. Sun have broken backward and forward compatibility of JDBC in Java 6. It is no longer possible to write an implementation of several key JDBC interfaces in a way which compiles under all the most popular Java versions.
Once again, Sun completely misunderstands the real world. Not everyone is free to upgrade every deployment to the very latest Java version immediately it is released. Even within those who do manage to update all their machines in one go, not everyone can immediately drop real work to spend time messing with old code which should still work to bring it into line with a new fashion.
As I wrote at the start of this rant. I’m cross.
Grrr.
From time to time I get involved in a bout of recruiting, and part of that process is inevitable trying to sort the wheat from the chaff to decide which ones to bring in for a detailed interview. Naturally one of the first things I do when presented with details of a new candidate is to look them up on the web. Obvious things such as a google search for the candidate’s name, looking them up on LinkedIn, facebook etc.
What usually surprises me is how little use most candidates make of this. When applying for work, your name is your brand, and making sure that the best information is easily available to potential employers seems an obvious thing to do, yet so few candidates bother. Instead, the overwhelming impression for most candidates is either that they have practically no internet presence at all, or that their web footprint consists of holiday snaps and mildly embarrassing facebook/twitter chat.
My top tips if you are thinking of looking for a new job.
Above all, remember that potential employers will be looking, so make sure you have a say in what they find
One in Five Employers Uses Social Network Sites When Hiring People