Zeebox, ranked number 6 media application above Facebook

The top ten media apps of 2011

Not a bad result for a product that took 3 months of development before its first release on the iPad and has not even been released outside of the UK yet. 2012 is going to be a big year for us!

Handling Java nulls in Scala

Null handling in Scala can be painful, to ease this pain I like to avoid the problem entirely by not using them at all. However sometimes one has to cross talk between Java and Scala, and then one has to face the problem head on.

The cleanest approach that I have found, that does not result in a deranged mix of generics or implicits is to use an anti corruption layer as close to Java as possible that converts Java's use of null into an Option as soon as possible.

For example:

    Option(o).map(_.asInstanceOf[T])

If o is null, then the above snippet will evaluate to None, else Some(o).

String Option with map and closures is rarely readable, at least not until you have bathed in it for long enough to have Scala'ized your mind. So I like to wrap this up with a function, as follows.

  def asInstanceOfNbl[T]( o:AnyRef ) : Option[T] = Option(o).map(_.asInstanceOf[T])

IntelliJ vs Scala [The Battle Rages On: A productivity tip]

Following a short discussion yesterday at work, about how Intellij keeps changing scala keywords to Java class name while you are typing. Forcing you to break flow, go back and correct it (swear) and then continue. I dug around the IntelliJ settings and found the following very useful setting. In Java it works wonders, in Scala it is just plain irksome.

Settings->Editor->Code Completion->Preselect the first option

When writing Scala, set it to 'Never'. The Scala keywords val and override will never be quite as annoying again ;)

Java 8 wishlist

I have blogged before about my dissatisfaction with the rate of improvement of the Java platform. While the situation is understandable, it still leaves me annoyed. Below is an updated wish list that I would like to see in Java 8.

I am increasingly considering getting my hands dirty in adding some of these features. If only I had more time. So my first wish is for a clock with a big 'stop the world' button on it. Having an infinite amount of time, with high energy levels, no risk of rsi and no risk of interruptions would be great. Please create this for me Mr S. Hawking.


jvm
    support jar level constant pools to reduce class sizes
    enhanced gc
    transactional memory support
    add method parameter names to reflection
    access to javaadoc from api (provide in optional packaging that can be accessed via reflection); include comment following abstract method.

Simple syntax sugar
    .?
    multi line strings
    versioned jar file/module system
    drop the annoying diamond operator (<>) added in Java 7 but keep the functionality
    optional method parameters with default values
    language syntax for reflection
    language support for collections
    pre condition support on method signatures

More involved language features
    mix ins
    closures
    Language support for custom types
    replace try-close with keyword; keyword declares that an object is not to escape the stack
    Inferred type support (eg var s = "abc"; s is strongly typed to String why double declare it)

Slow networks

Interesting points from http://highscalability.com/blog/2011/6/1/why-is-your-network-so-slow-your-switch-should-tell-you.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+HighScalability+%28High+Scalability%29


Network operators get calls from application guys saying the network is slow, but the problem is usually dropped packets due to congestion. It's not usually latency, it's usually packet loss. Packet loss causes TCP to back off and retransmit, which causes applications to appear slow.

Packet loss can be caused by a flakey transceiver, but the problem is usually network congestion. Somewhere on the network there's fan-in, a bottleneck develops, queues build up to a certain point, and when a queue overflows it drops packets. Often the first sign of this happening is application slowness.

Which project metrics do you use?

My favourite software project metrics:

The main two that I use at a high level are end to end cycle time, and benefit hit rate.

Business Benefit Metrics

End to End Cycle Time

the length of time from the conceptualisation of an idea, or feature to the reliable use of that feature by the end customers.

ROI cycle time

The length of time from conceptualisation of a feature to when the feature pays for itself, expressed as a rolling average

Benefit Hit Rate

As a percentage, how many of the features that start being developed go on to return more to the business than they cost.

Overhead

Number of man days not spent producing the product, ie waiting for a build, waiting for a release, merging branches, waiting for broken builds, waiting for test runs to complete, waiting for hardware, attending meetings etc

Developer Productivity Metrics

Commit cycle time

Length of time that it takes a developer from completing a feature to receiving confirmation that it has been accepted.

Defect rate

Number of defects per feature that was accepted as complete, expressed as a rolling average or over a period of time.

Build time

Length of time that it takes to run the build

Commit test execution time

How long it takes to run the commit tests

Acceptance test execution time

How long it takes to run the acceptance tests

Automated test quality

When a test fails, is the fix to the system code or to the test? Represented as a percentage: num fixes to system code/num failed tests

User Experience Metrics

Use case duration

How long does it take an average user to perform a single goal

Use case step count

The number of user actions required to attain their goal

User frustration

Number of user mistakes + number of system errors*10

UI Responsiveness

Length of time from a user click and a system reponse

Live System Metrics

Uptime

The length of that the system has been up without a user visible outage

Call out count

Number of times that a 'fatal' error has occurred requiring immediate support staff to take action, even if in the middle of the night

Error count

The number of errors reported in the log files

Warning count

The number of warning messages reported in the log files

Support overhead

Number of man hours required to keep the lights on

Release duration

How long does it take to perform a release, in man hours

Code Metrics

Unit test coverage

Percentage of lines of code tested by the unit tests

Acceptance test coverage

Percentage of lines of code tested by the acceptance tests

Average class Cyclometric Complexity

Indicator of code complexity, the higher the value the more complex the code base is to understand

Worst method Cyclometric Complexity

Indicator of code complexity, the higher the value the more complex the code base is to understand

Refactoring is not the same as rearchitecting

Refactoring is a small scale technique, a collection of small transformations that when applied with skill to a code base helps to improve the readability of the code without changing its behaviour. Unfortunately it has become all to common to use the term with management to hide a project rearchitecturing exercise or rewrite. Such work may be required, however the purpose of refactoring is as a low cost tool to use daily as part of ones programming practice; which helps avoid entropy in the first place.

For more information see: http://refactoring.com/