Suspension Setup for 2006 Triumph Daytona 675

[caption id="" align="alignright" width="520"] Two 'old bikes' - one new to me...[/caption]

For those who don't know I love riding motorbikes and in the last couple of years have done a couple of track days but want to do a lot more.

The new bike is a 2006 Triumph Daytona 675 and so far I have been really impressed with it - even from my limited chances to push it. One thing that has been bugging me is the suspension set up. The bike was set up for a different rider so that is no surprise.

Target Sag Setup

Based on the 'ball park' suggestions from Dave Moss the target sag setup should be around 30mm on the rear and 45mm on the front. I have taken the bottom of both estimates as I am primarily riding on the road and need the travel.

Rebound is the Key

The rebound is more of a mystery to me though as only one bike I have previously owned has any options for rebound adjustment. Since I did the California superbike school course I have tried to maintain the break / turn / throttle separation rather than trailing the break. The advice from Dave is that with that style of riding faster rebound is good because you are set up to turn so I am going to dial the rebound to the suggested soft settings 7/7 front and back.

Compression Damping

Compression damping advice is a bit more tricky in a sense because even using a tie wrap to monitor the compression, the public roads are simply really rough. The most common sense advice I have heard so far is that you want to make it as soft as you can so that you use most but not all of the travel on a typical ride. This gives the suspension the best chance of soaking up the bumps in the road. Dave's advice is to go for between 2/3 and 3/4 of the way 'out' - meaning mostly soft to me. The manual suggests 8/12 respectively. Hopefully this falls into our expected range.

Now it's time to put on a tie wrap on one fork to see just how much of the travel I am using. Happy riding.


The Three P's of a Good Business Partner

There has been much written about how many co-founders are best and what the ideal number of co founders is. The bottom line is that there are lots of good reasons to do your next startup with a co-founder.

For me having a business focused co-founder is key. Don't get me wrong - I love business problems, financial modelling and have also been known to do my fair share of cold calling customers. The bottom line is that when you aren't focusing you aren't being efficient. I am definitely a subscriber to the idea that in a startup you have to spend as much time as you can doing what you are really good at as that is how you will differentiate. On the sales front it has definitely been my experience also, that in the B2B sales focusing on sales rather than marketing initially gives the best chance of success. Given that, having one founder focus on sales while the other focuses on delivering the 'stuff' seems like the perfect combination.

As well as sales performance the ideal business related co-founder to a technical co-founder can also take ownership of three other areas:

1. Product Management

Product management is a very broad role in large companies. In startups this role is even more essential and can often be lost in the other tasks spread among the founders. The benefit of having the business co-founder focus on this is that it shortens the feedback cycle from customers to product requirements.

2. Pricing and Placement

Pricing your product can be done a number of ways and it is often tempting to under-price your product. By having the business founder use market research and other factors, combined with more perspective on what the product is 'worth' to customers you get a better result. You are more likely to maximise the potential pricing of your product as well as reach the best pricing level faster.

3. Perception

One thing that I had definitely traditionally not paid enough attention to was the perception of the brand I was working on from clients. There are a few key things to consider but the old rules still apply you never get a second chance to make a first impresison. Give the business founder the resources they need to make sure that your brand is ready to sell. Invest in your website, branding, logo, social and PR. The business founder can lead on these initiative and this will give you the best chance of getting through the first six months to a year.


Schema Org Naming Frustration

Standards are a great thing but some times they lead to having to make some silly compromises. Take the schema.org event. It has a startDate field which is supposed to be a Date [note the lack of Time in the type]. It has the description The start date and time of the event, role or item (in ISO 8601 date format). - are you kidding me? Combine this with the doorTimeattribute on the same thing, Event, which is a.... you guessed it DateTime with the description The time admission will commence..

All of this would be hilarious if it wasn't that this is the 'gold standard' of resource naming. It is a pity that so many naming convention mistakes could be made in such a small space. Note that our new APIs don't have the data type in the name generally - they are called things like 'start' and always use a 'date time'. Let's see how long this convention can survive the onslaught of progressive feature expansion...


OpenHack #3

As part of trying to learn some new technology and approaches I am going to OpenHack #3 with the objective of discussing and hacking on either:

  1. Time series monitoring bucket technology for tracking readings similar to VarZ

  2. Pair with someone to learn some Ruby.

  3. Automation of Rachel builds on Raspberry Pi.

  4. Comparison of different geo-distance functions.

If you are also attending OpenHack #3 and want to pair on either of these things then come and say Hi!

-- Update

  1. Created a model for bucketz time oriented data. Added paths as well as bucket names.

  2. Registered on CoderWall

  3. Signed up for 24 Pull Requests for some inspiration on open source projects to contribute to...

Thanks for organising the event #OpenHack guys!

Travel Needs an Upgrade

Over the last year I have been working as a contract CTO and one of the clients was in the travel sector, a London based hotel chain. The client wanted to ensure that the technology was rock solid from a transactional stability point of view. Even one false payment or booking wasn't an option. (You may assume these things only happen rarely but as complexity increases so do failures.) To try and ensure that we could achieve the desired stability in light of total data centre outage applying banking style transaction management seemed a sensible place to start. This left me with a challenge; in order to deliver the project in the time scales that we needed a more 'agile' approach.

Lean / Agile Works for Start-ups but...

If you have visited many of the London start-up co-working spaces you will be familiar with the usual stack of 'Agile' and 'Lean' books that seem to litter these spaces. The challenge is how to build systems that are as stable as what you would expect after an exhaustive build and test [a'la waterfall] process. This was a particular challenge for us as we had a tiny team and needed to outsource the majority of the work. For me personally the ethos of don't out-source anything you care about was also ringing in my ears. The different back end vendors we evaluated seemed to come in two varieties:

  1. White labelling solutions who primarily offered the same solution to most clients with some re-branding.

  2. Niche agencies that offered a (sometimes) slick and customised product.

When it came to it we thought that we could do better. We wanted to apply start-up style rapid development to the back-end and out-source the front-end build to companies better placed to deliver on an industry leading solution.

Brittleness of Agile

When talking to clients they always seem to like the idea of Agile because they like to see results. From that point of view the user story generation approach to requirements capture was also something I enjoyed. User stories are a great way of capturing specific behavioural expectations.

The challenge with all of this 'speed' is, what do you put into the things that you build. There are a lot of great design patterns, like reversibility [be able to undo - encapsulating replicable components when there is a high risk of changing solution in the future] to help you out of a pinch but the hard part is still choosing where to invest your time / code. For me this is the most challenging and fascinating problem; let's assume that you only have time to write 10K lines of code - what do you want to spend them doing? Features? Tests? Integration testing?

By definition - if you are using an Agile / Lean approach then it is likely that you have to choose some things to leave out! The goal is to get your system live as soon as possible so it is up to you to pick the right things to write. For me system tests are a must as they provide the contract that guarantees that our back-end does what we say it does. After that we need some unit testing of complex logic but 100% coverage is rarely a practical goal.

To compound things further the principles of code quality and readability are exaggerated by Agile. You expect to go back to your code and modify far more frequently than you would for say a legacy system that is expected to run for years without modification. To put this into context - I wanted to engineer our platform so that we could do multiple orchestrated releases per day with system tests running in continuous integration. There are a few things you need to make sure you get right if you want to run this way:

  • Tests need to run in seconds not minutes.

  • You need to be able to run your tests on all of the different versions of your application at the same time.

  • You will probably need to be able to build multiple clusters of homogeneous servers.

  • You will probably want to run local, staged, live staged and live release clusters.

Remember: all software has bugs (feature and functional) so it is important that you set yourself up for success with the tools you need to do a 'good job' of dealing with so much uncertainty.

Detecting Issues

The big value impact for us came from the simplest things to do but all too easy to get wrong. Traceability - being able to perform detailed investigation into the root cause of an issue. This let us quickly respond to issues by being able to see a lot of detail of what was going wrong. This then drove new bugs, which had failing tests written first, which we fixed then we would release. This process became fairly fluid after a while but logging wasn't quite enough.

Again, thinking back to companies I have worked at before - one of the most useful features to build on day one is support for live site monitoring - and I don't mean TCP monitoring. Every application has a different set of indicators of health and happiness. This is often something like healthz or varz which can then be monitored by your friendly monitoring technology. For Upgrade we actually created a servlet library that made exporting stats a cinch.

Today Upgrade represents a major code base of approaching 500KLOC and can still run on a model A pi. I am proud to say that we have had only a very small number of bugs found in production. Bottom line is if you have an API write some full stack tests. You will thank yourself later.

Could Using Bleeding Edge Tech be the Best Way to Attract Talent?

It seems that the ruby language was the tool of choice if you wanted to work on the new and shiny. It may be that Ruby isn't the new shiny thing though. Like many people it has been top of my list of languages to learn for a while. The London startup scene is still heavily bought into Ruby even now. The last time I checked the 'services wanted' at Google Campus, there are a lot of calls for Ruby development. On a separate note, it is really interesting that there were no calls for 'technical co founders'; these days all you need is an app and that can be outsourced ;-)

Taking to a number of startup founders lately they have advocated using shiny new tech as a crucial part of their hiring strategy. VisualDna a previous employer also made a lot of using technology like Cassandra. But these systems too are starting to come of age. The problem with wanting to use the newest thing is that it doesn't stay new for long.

The logic seems to go that by concentrating on newer technology you are more likely to find self starter employees who makes learning new skills part of his regular work. This strategy makes a lot of sense. There are a few potential issues:

  • Pre-qualify your recruits on a smaller market of real zealot.

  • You have to try and figure out who is 'learning' and who is 'earning'.

  • Admiration is the furthest from understanding: it can be very hard to know when a recruit is simply following others ideas or practice.

If you want to work with startups today it seems like the main languages are Ruby for web, Java for android and Objective C for iphone. The exception is the data science scene where the challenges of handling the ever increasing challenges of automating large data set processing in real time is still resulting in some language innovation.


Developer Goal #1 Dry-ness

DRYness may be a design pattern you have heard of. If not; we are talking about Don't Repeat Yourself (DRY).

Disclaimer: no one is perfect and therefore neither is their work. We are talking ideals here not rules. Otherwise you would be reading developer rule #1....

Anyway, the idea is to do work only once. Every time you find yourself thinking : "if I just copy .... and change .... Code then ...".


There are lots of good reasons to only write your code once, unless you take the time to refactor your code at the end of a project then when some new developer comes along he will likely miss the X multiple versions. Think about it like this: you write some code with a bug, let's say an off bye one that only happens on the 29th of February. Someone tries to fix your code but doesn't realise that you have pasted the same loop in four places. Even if they fix it they may not run a search to find all of the other cases.

Once you want to start thinking this sort of approach is a good idea other goodness comes for free. If you want to start writing code that is reusable then you have to start thinking about higher levels of encapsulation. You might also think about refactoring your new method or helper class so that all configuration is parameterised. This is great news from a testability point of view too. You can write one set of tests for your new function and the scope of your test plan is limited to your parameter list.

The bottom line is if you are going to write [crap] code at least make it DRY. That way when your agile approach makes you realise you need to fix the problem you deferred you only need to do it once, you may even thank yourself in the future for your own fore sight.


Adding UUID column to a Statement MySQL Replicated Database

UUIDs can be a very nice alternative to Auto IDs for keys in database tables but there is one problem with them when using statement based mysql replication.

Lets consider the scenario where you want to add a new UUID column to an existing table which you want to use as a key. To be able to use the key you need to initialise it and the obvious way is to do a:

Given the context of a table like:

someField VARCHAR(255));

INSERT INTO MyTable(someField) VALUES ('My Data');

When you run your alter table command:


SET urn = uuid();

(Ignoring the implications around storage cost of putting a UUID in a varchar field) The problem is that when the statement executes on the replica it will have a different value. E.G.

On the master you could end up with:

1My Data37ef6bac-d85b-11e3-a227-bc764e08452a

But on the slave you might have:

1My Data3216702f-d85b-11e3-a9c8-bc764e082848

The answer is to use a UUID initialisation that will assign the same values on the master and the slave, your id field can also be part of the answer to help you get going...

UPDATE BasketLineItem
SET urn = concat('00000000-d411-0000-0000-', lpad(hex(id), 12, '0'));

As long as you have less than 16 ^ 12 (2.8147498e+14) records then you you just migrated to UUID. If you don't have an auto incremented ID already you can also rely on database storage ordering which results in records being evaluated in the same order on the master and the slave (note that this was tested on MySql 5.5.37 with InnoDB storage - but it may not for you so make sure you check):

SET @counter = 0;
UPDATE BasketLineItem
SET id = concat('00000000-d411-0000-0000-', lpad(hex(@counter := @counter + 1), 12, '0'));

Enjoy your UUID keys!

ProtoStore UUID Storage Under MySQL

Over the last year or so using ProtoStore to handle object serialisation has saved me a huge amount of time and countless SQL related bugs. Obviously this is why technologies like EJB exist!

One thing that I have been thinking about for a while is the performance of the UUID based keying due to wasteful storage of the UUID as a string. I have finally found some good data on this UUID storage benchmark.

The headline seems to be that on insert you can get a 4X insert speed-up and a 10X select speed-up by using binary storage of the UUID when using InnoDB engine.

The question is can this be achieved without breaking anything in the way that the current system works? The short answer seems to be YES! By detecting the column type it should be OK to just add this as a 'feature'...

As an aside the protobuf jar is still only 39K but I am going to see if I can further reduce it's size, obviously it doesn't have the features of hibernate core but it does still solve my CRUD storage needs for a fraction of the 5MB cost....


A sad sad day indeed! Bye Bye BMX

Unfortunately I am going to have to sell my BMX. Since I moved I have found it harder to find somewhere like the awesome dirt jump track in Hackney.
To add insult to injury people have been messing with it as it is parked outside at the moment. Given that and the current economic client it's time to grab the cash and run for the hills as I don't have me' bike any more :-(United KL40 Expert 21" BMX

If you are interested in an Adult BMX then this could be the thing for you United KL40 on eBay

If you know anyone that might be interested please do forward a link on to them.

P.S. I still have a number of model bikes. It seems that they are all that is within my budget these days. My favourite is still the model Daytona 675 that J.H. gave me a while back which was supposed to inspire me to 'make some money' so that I could afford better toys, oh well /