Wednesday, July 29, 2015

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... 

Friday, August 03, 2012

Bulk rename in Linux


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

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



Tuesday, December 20, 2011

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

Friday, September 18, 2009

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?"

Tuesday, June 24, 2008

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

Tuesday, June 17, 2008

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.

Tuesday, July 18, 2006

Darmsden

Just found this picture while trying to sort out photos on my hard drive.

You've got to love Darmsden...
Posted by Picasa

Thoughts on Service Oriented Architecture (SOA)

The concept of services within a business context are not new. We are all used to the following being thought of as a “service” provided to the business:

  • Shipping
  • Storage
  • Marketing
  • Payroll
  • Catering
  • Product technical support (Call centres)

And the list goes on. Interestingly, these services have lots in common:

  • They are managed and used in direct support of the business. They have a function to perform with a clear path showing how the service contributes to the success (or otherwise) of the business.
  • They can be “easily” swapped or replaced for an equivalent service from an alternative provider
  • They can be delivered by an internal group/division or by an external service provider
  • The product of the service and any input from the business that the service consumes is clearly defined and clearly understood by both the service provider and the consumer
  • They are often governed by well defined service level agreements
  • They support the ability for consumers (and providers) to measure (using service metrics or KPIs) the use of the service and the ability for it to deliver
  • They often support a fine-grained and open cost structure (audit trail, pay-per-use)
  • Without them a business would grind to a halt – but they are only normally a part of the business, not the whole!
  • They form part of the processes that define how the business works (sometimes a small part, sometimes a large part).

So service’s are not new: what is new is the view of software systems as another kind of service to the business. Before we look at what that means lets take a look back at how software (and to some extent IT in general) has been viewed in the past:

  • software as technology” – In “the beginning” (60s/70s) software was really just a technology, a science if you like. New developments were occurring at a rapid pace, and problems were being solved for the first time. In this era software was centrally deployed and managed (think thin-clients) – as hardware was still expensive. But software too was expensive : it was complex and expensive to build for vendors, but equally expensive to administer and support for consumers. Software and hardware were often bound together tightly.
  • software as product” – The view of software in the 1980s changed. With the advent of cheaper hardware the PC was born. And with it came shrink wrapped products aimed at the “owners” (users) of those PCs. Software was created by development houses, packaged and shipped to customers who installed it on their hardware. Support was provided as long as the customer had a licensed copy of the software.
  • software as project” – As software and IT became integral components to how a business operated, there was a shift in the 1990s towards custom software. Large projects were commissioned to create central software systems for use by the business. These projects were performed by internal IT groups or external software vendors. Sometimes the systems were customised (pick & mix) instances of large complex products (e.g. SAP, Axapta), others were technology-led and developed from the ground up. In recent times these projects have been categorised by late delivery or complete failure to deliver.

SOA is about the next step in this evolution towards “software as a service”, just like any other business service - with the same attributes discussed above.

This view of software really applies to software that makes up some key part of a business process. It does not apply to a calculator type application (personal tool). It applies to software that is central to the operation of the business and used by multiple people in order to communicate some kind of information between them. Typical examples are:

  • CRM and contact management tools
  • Electronic calendars
  • Travel booking systems
  • Time tracking
  • Etc.

But it is not just software within the business that can be modelled as a service, the interface between companies can be modelled as software services. This allows the service provider and it’s customers to conduct more business electronically: ”e-Business”. For example the primary interface to an external travel agent could be a set services for booking travel and managing preferences etc. This is not to say that other human interfaces are not required, just that the more business that can be conducted electronically the better since it is significantly cheaper. The ultimate vision of SOA is that every business function (internal and external) can be called as a service.

Most firewalls help no-one

TCP/IP supports the notion of ports in order that a server can run multiple “services” and clients can connect to that service at a particular port. In this world we are really talking about application service such as FTP, HTTP, RPC etc. Most services have “standard” ports.

90% of firewalls on corporate networks automatically block traffic on all but outbound port 80 – this is left open to allow users (web-browsers) to browse websites. This is with the na├»ve assumption that this will allow the IT group to control traffic and prevent use of unauthorised or unsecure services (such as chat applications or external, or external email that may not be virus scanned).

So software application developers can now only rely on outbound port 80: anything more than this is likely to require users to seek “permission” from IT groups to open ports in the firewall. This will normally be a very slow process and most likely the request will be denied. I believe this is because there is a perception of each open port as a “hole in the wall” – i.e. it weakens the defences.

Since the developers can only rely on port 80 there is now a tendency to squeeze all kinds of traffic through it:

  • HTTP file uploads as an alternative to FTP
  • Various custom HTTP based protocols for modern IRC apps like Windows messenger
  • HTTP based mail protocols like hotmail; and in other cases basic webmail
  • Web services – RPC (and hence any computing you like) via HTTP

So IT groups (through poor policy and process) have not plugged any security “holes” in the network, they have just moved the problem on. Now it requires more “advanced” firewalls to attempt to control the traffic going through port 80. Which will cause developers to find some other way to “wrap” different forms of traffic and make it look like the “widely accepted” one.

This cycle will never stop. We all suffer because each iteration causes more processing power to be required in the software (to unpack all the layers), and more processing is required in the firewall to detect “naughty” traffic masquerading as “normal” traffic.