The crash

Rollercoaster - broken wrist! | Ride | Strava

(209) Finale Ligure - Rollercoaster - Full Run - YouTube - video

 W3W: ///skylark.winemaking.doddle

Apps, apps, apps...

There is a lot in the press currently about Telematics and everyone seems to be getting hung up about "Apps" - especially in the context of the car...

I wanted to get down some thoughts on apps. In essence :- it's not really about the app... let me explain.

All "apps" cater to some basic (and usually pretty old) need/desire - let's take "listening to music"; I (like many people) now use music streaming services like Spotify, Google Play Music and Apple iTunes and many more.

Why do I pick one "app" vs. another?

1. Content first 

I like classic rock, when Spotify did not have Pink FLoyd or Led Zep - I looked around for an alternative. Now they have those artists, I use their service. The right content is the "mandatory" part of the app. So what makes me "loyal" to one app/service.

2. Ease of Access

The next thing that differentiates one "app" from another is how easy is it to use. Sure App UX is important. But again, I see this as a mandatory/basic thing... what really matters is that I can get access to the content wherever I happen to be. In the living room, in the kitchen, in a car, on a train in a plane or a hotel room. That means the "app" (really "the service") is largely platform agnostic.

This is where Spotify comes up trumps again: it works on my Android phone, my PC, my iPad, Sonos, the family MacBook our TV etc. And better yet all those devices "know about each other" so I can control the TV from the iPad etc.

It also lets me listen to music offline (e.g. when travelling). Again, it's the content where I want it, when I want it.

3. Personalisation

The last and most crucial aspect of differentiation is the degree to which the app/service recognises me and adapts itself to me. Let's stick with music streaming: over time I have built up a library of playlists and "saved" a bunch of albums I like. This represents some personal equity in the service - I created these, it would take time and effort to create them somewhere else.

That's where music streaming stop short of how far they could go. They have my listening history. With that they could offer (maybe they already do) big data powered personalised recommendations. You seem to like The Stone Roses and Led Zep in the morning; maybe you would like this... that listening history is much more difficult (impossible?) to move from service to service.

In essence personalisation offers me (the user) value/features - but in turn raises the switching costs associated with an app/service.

If you get all three of these right - then you have a good "app"; loyal customers and a potentially lucrative business. But did you notice how little of it is really about "the app"...

Much maligned diagnostic connector and protocols (e.g. CAN)

There has been a lot in the press recently about "car hacking" (there always seems to be a spike just before the black hat conferences).

I read a lot of car security articles and there are some basic premises put forward in many that are not fully accurate, and that annoy me. So I thought I would write down a rebuttal:

Diagnostic protocols (e.g. CAN messages) can be used to attack your car...

Yes they can (sic.). That is really the whole point of the controllers and the network of them. They control stuff!... mainly stuff in your car. If you send them messages they will control stuff differently. The more electronic controls you have (and the trend is more and more on each new vehicle) - the more aspects of the car you can control with these messages.

These networks are also designed to allow a technician in a garage, using a tester connected to this network, to control aspects of the vehicle - to test everything works as expected. 

So if you plug a computer into the diagnostic connector (and make it part of the car control network) you can do all sorts of crazy stuff.

There are fairly limited security measures in place on the network to ensure the tester is "genuine" (seed/key challenges to enable certain, more dangerous features). But these are almost trivial to crack, and the easiest way to compromise them is to compromise some software that contains the algorithm, such as:

• Application layer code on a trusted controller on the network
• Diagnostic software installed on a tester (typically a PC)

But the key security measure here is the physical security of the diagnostic connector (and the controller network). To hack a car this way - you need to be "plugged in". The diagnostic connector is normally inside the dashboard area. So if a would-be attacker, can gain physical access to your dashboard - hacking CAN messages is the least of your problems... they may as well just disconnect the brakes?

The thing that has changed here is that controllers on the network are now connected to other networks (e.g. WiFi, Bluetooth, or cellular) and/or certain controllers can be exposed to malicious content via physical media (USB, Flash sticks etc). The chain is only as strong as the weakest link...

It is the security of those other connections that needs to be "bullet proof"; or at least as secure as the physical security of the car. (Why not trigger the car alarm/immobiliser if attacks are detected on these connections?)

Those "other networks" are the problem, they let you get inside the car, without being inside the car... the weakness has nothing to do with CAN network or diagnostics. We can and we should improve the security of diagnostic protocols (see earlier), but they are not really the main problem and neither is the diagnostic connector. 

The problem is the lack of security around this new way to get inside your car... 

Bulk rename in Linux

A way to rename all files in a directory...

rename s/'([0-9]+)\.(.+)'/'$2'/ *

Gross Margin Calculations

(I keep having to phone a friend on this - so by writing it down; I can come here in future...)

If we have:

• cost (C) = £50
• We want to achieve a Gross Margin (M) of 30% (that is 0.3)
• Then what will have as a sell price (P)

The answer is:

   P = C / (1 - M)
     = 50 / (1 - 0.3)
     = 50 / 0.7
     = 71.43

This can be verified by calculating the margin as:

   M = (P - C) / P
     = (50 - 71.43) / 71.43
     = 0.3

Or lastly:

   C = P * (1 - M)
     = 71.43 * (1 - 0.3)
     = 71.443 * 0.7

     = 50

Instanceof and isAssignableFrom

Java includes the rather handy instanceof keyword that can be used to test if an object is an instance of a particular class. Other methods exist such as Class.isAssignableFrom(Class) and Class.isInstance(Object).

(new Double(100.0) instanceof Double)=true
(new Double(100.0) instanceof Number)=true
(new Double(100.0) instanceof Object)=true
(((Object)new Double(100.0)) instanceof Integer)=false

An alternative (when working with instances of Class)  is to use Class.isAssignableFrom(Class):

Double.class.isAssignableFrom(Double.class)=true
Double.class.isAssignableFrom(Number.class)=false
Number.class.isAssignableFrom(Double.class)=true

i.e. X.isAssignableFrom(Y) is like saying "is Y a kind of X?"

Another alternative (when working with instances of Object) is to use Class.isInstance(Object):

Double.class.isInstance(new Double(100.0))=true
Number.class.isInstance(new Double(100.0))=true
Object.class.isInstance(new Double(100.0))=true
Integer.class.isInstance(new Double(100.0))=false

i.e. X.isInstance(Y) is like saying "is Y a kind of X?"

Useful SQL

Crafty way to create a temporary table (view) with some rows in it:

CREATE VIEW Xyz AS
    SELECT 'A' AS id
UNION ALL
    SELECT 'B' AS id
UNION ALL
    SELECT 'C' AS id
UNION ALL
    SELECT 'D' AS id;

Creates a table:

Xyz

id

A

B

C

D

Maven

With some recent projects I have been instructed to use Maven to fetch and build software. I was struck by how hard it was to do anything and how much time I spent faffing with the build environment rather than doing anything productive!

I felt like I was back in the 70's building some mainframe UNIX OS - not trying to build some trivial open source library for Java!

Is it just me or does Maven represent a massive step backwards? Here are my pet gripes (in no particular order)

1. Centralised software "catalogue" - I don't think this is a good idea for the same reason library catalogues suck. One man's "popular fiction" is another man's "crime novel" etc. How can you find stuff?
2. It is full of very deep voodoo parameters (so are most builds) and settings files spread liberally around the filesystem
3. It fails in some spectacularly unhelpful ways
4. When you read the documentation and support forums - most of the focus is on nursing the beast into just working. Surely it working should be a "no brainer"... only when I want to fiddle with stuff do I need to read the detail?

Maybe I am just looking at a bad example project that does not use the tool correclty? But I can't help but think: what does this tool do for my build environment that a decent build document and a set of human friendly tools (an IDE?) don't.

Can I more easily set up new team members with a productive build environment? Is it faster than copying a Virtual PC image and clicking "start"?

Layering Abstractions

Just a braindump/moan...

In my work I often see people writing library code (A) that "wraps" and "simplifies" use of another library (B). When I see this it immediately makes me think:

1. The person who wrote the (A) automatically assumed (B) was going to be too hard to use.
2. They Google'd some feature they were looking for and found (A) supported it. But (A) supported lots more besides, so (A) did not look exactly like what they had imagined.
3. They did not bother to learn how to use (A) properly, before then creating an application using (A).
4. Instead they learned to use (A) by creating a wrapper (B).
5. Does (B) add any value - simplifying is not value.
6. There is this idea that if you keep abstracting the final application that "joins them together" will somehow write itself.
7. Creating re-useable libraries is what good programmers do. I am a good programmer -> I must create some libraries.
8. If I had written (A) I would have done it more like (B).
9. (B) Provides a "layer of indirection" allowing me to choose to swap (A) for an alternative library (C) one day in the future.
10. Writing (B) makes you look busy while you deliver the work of (A) wrapped up with your name on it. It's basically plagiarism!

But (B) just introduces more maintenance? Worse still it makes maintenance harder while developers pick through unnecessary "proxy" and "interface classes".

Why not simply write an app that uses a subset of (A) directly?

To me it smacks of a work avoidance technique. Rather than think about how to address a customers problems, or stick your neck out and make a bet on a library... it's easier to write an abstraction layer, which will allegedly "make it easier" to write the business app one day in the future.