I have been struggling with writing blog posts of late for a variety of reasons.  Firstly, I am working from home far more often.  This deprives me of most of my “train time”.  The half-hour commute (each way) is a golden time for me to catch up on things (such as writing blog entries and professional development AKA “coding for fun”)  It seems strange to gain an hour a day at home, but lose this time, but that is the natural evolution of my day. – When I am at home and finish work, I do things that I can do at home…  When I am on the train, I do things that I can do there.  With less options available to me on the train, my time tended to be more focused.

The second reason the blog posts are irregular, is that the restoration project on the RGV is taking up a lot of time and effort.  I have some admissions to make: I am not much of a mechanic, so mechanical tasks take me longer than they really should.  Also, the garage is a place where I “potter”.  It is a form of relaxation and as such, inordinate periods of time are required to achieve any real progress.  I have also been trying to stick to a monthly budget.  – This restricts the rate of progress I make on the bike.
Most of my work is guided by the experience of others.  The earliest model RGVs are now over twenty years old and there are plenty of enthusiasts (a large proportion being in the UK) who frequent an RGV forum.  I have yet to really come a problem with my bike, that someone hasn’t experienced before and written about on this web site.  It really is a fabulous wealth of information.

So, what have I been up to?

The swing-arm bearings for the bike felt fine, so I did not disturb them.  The dog-bone (linkage) bearings for the swing arm were not.  After losing several hours and inventing several swear words, I took the part to a local mechanic to press the blind bearings out.  I lack the specialised tool to remove them, and the “drift and hammer” technique to bash them out proved fruitless. I felt somewhat justified when I went back to collect the part, as the mechanic had found them far harder to remove than he was expecting!

Based on discussions found on the site, I purchased a GSXR 600 rear shock absorber for the bike.  There is some question as to whether the spring will be too “heavy” to allow the correct range of motion, but track bikes do tend to be sprung more heavily than road bikes.  One forum member posted the measurements he took after fitting the same part. Weighing approximately the same as I do, he was able to set the suspension correctly, so I figure I have a sporting chance too.

At the moment, I am in the middle of performing a top-end rebuild for the bike.  The bike still felt like it had good compression, but I wanted to check the condition of the cylinder barrels and it had been a long time since it had a “freshen up”.  Nothing comes un-done easily on a bike engine last touched ten years ago.  I have learnt that the hammer drill setting can be used as a substitute for an impact driver… sometimes…  At other times, it has led me to my other discovery, that a Dremmel is a good tool, for cutting new screw heads in a screw with a butchered head…
There is no end of “bling” that you can purchase for an RGV.  This also means, there is no end to the amount of money you can spend.  I am still managing to avoid the trap of spending money on good looking parts that do not help finish the project – but I do have my eyes on a couple of items.
I am however reaching a point where I have a tough decision to make.   My budget is currently “in the red”.  I allocated myself a monthly spend, and I am about six weeks ahead of that, at this point in time.  Even using mental arithmetic and not trying to be precise about the budget, I can see that finishing the bike on time and on budget will be a story that belongs in the “fiction” section of the local library.  Going back to my New Year’s Resolution, that means I should be planning on taking the VFR out on the track.  But, to be honest, I’d rather spend the money that would cost, on “finishing” the RGV this year.
I use the term “finishing” loosely, as I said, there is no end of “bling”…

Previously, we looked at the role that springs play in motorcycle suspension.  Suspension is comprised of a spring and a shock absorber.   The shock absorber’s role is to limit the rate at which the spring compresses and expands.
Ideally, a motorcycle wheel should not lose traction with the road surface.  On a perfectly smooth surface, this is not hard to achieve!  For the wheel to grip properly, it must be pressed to the surface with some degree of force.  Luckily for us, the weight of the motorcycle provides us with this downward pressure.
Suppose for a moment we have a motorcycle without any form of suspension:  Not only is there a lack of springs and shock absorbers, but the tyres themselves provide no flex.   Once we are moving forward, the motorcycle has inertia in this forward direction.

When this motorcycle hits a bump, there is no way of “absorbing” the bump.  As a result, some of the horizontal forward inertia changes to vertical inertia.

Once the bump “ends”, the ground “falls away”.  The motorcycle being subject to gravity loses its vertical inertia and returns to the ground.  The vertical velocity is not overcome instantaneously. Rather, it is subject to the laws of gravity.  Depending on the speed of the motorcycle and the size of the bump, the wheel(s) will remain in the air for some period of time.
With the benefit of suspension, not all of the motorcycle needs to be subjected to the vertical inertia caused by the bump.  If the bump is small, the springs may absorb the bump.  As we saw previously, the spring will “want” to return to its state of rest.  The spring will expand in whatever direction cannot suppress the force that the compressed spring now has.  If the bump has ended, the spring will likely expand downward, otherwise the spring will expand upward.  The spring extending upwards is effectively transferring the vertical inertia to the rest of the motorcycle.
As noted previously, the spring continues to oscillate shorter and longer of its “at-rest” state, until all its kinetic energy is expended.  The suspension unit helps regulate the extending and compressing of the spring, by forcing oil to pass from one area of the suspension unit to another.  The oil can only pass through small valve holes.  Because a liquid cannot be compressed, the oil passes through the valves at a set rate.
Adjustable suspension allows the size of these holes to be altered, allowing a faster or slower rate of oil transfer.  Different systems handle the transference of oil in different directions.  That is, when the shock absorber is being compressed, oil is transferred by one set of valving, and when the suspension expands (or rebounds) a different set of valving operates.  The first set of adjustable valving gives you the “compression” setting, and the return valves gives you the “rebound” setting.
In recent years, suspension has been further refined by having two lots of compression valves.  These are known as “high speed” and “low speed” compression valves.  This “speed” refers to the speed that the suspension compresses.  Fast compression is needed to handle surface irregularities (i.e. bumps) whereas “handling issues” arise from slow compression motion.  Unfortunately, I have not had the chance to study suspension with this feature, so how the shock absorption works and which valving is used is as much a mystery to me as the next person.  (Unless they happen to work for Ohlins).
As you may well be aware, oil viscosity affects its flow rates.  A more viscous oil will therefore be slower to transfer through the valves than a “light” oil.  Oil has a tendency to become less viscous as it heats up.  Forcing oil through small valves tends to lead to the oil heating up.  (The kinetic energy of the oil movement is exchanged as heat, due to the friction caused by the fact that the oil cannot move freely.   This of course affects the compression and rebound rates of the suspension.  The bumpier the surface, the more this becomes an issue.  This is an unavoidable fact, but that does not make it desirable!

To combat this, suspension units have been designed to carry as much oil as possible.  More oil, means more oil to heat, meaning more energy required to do so.  A bigger oil reservoir also means a larger surface area in contact with the oil, drawing excess heat out of the oil.

That is about it for how the parts of suspension fit together.  How to make the most of the suspension you have, is a story for another day.

Photo attribution:

http://www.flickr.com/photos/nathanwells/1084352488/in/set-72157601369471448/ courtesy of Nathan Wells.

One of my favourite blog writers is Eric Sink.  I find his writing style entertaining and informative.  I do not find Revision Control Systems the most interesting subject matter. I use one, it works, I am happy.  But for Eric, they are his speciality.  After all, he owns a company that writes them.  In a recent article, he discussed speed vs. storage space trade off.  He used a source code file containing a single class, which was 400KB in size for the latest revision as his “guinea-pig” and braced himself for a barrage of comments regarding whether such a file constitutes an example of poor coding.

Certainly, when you take into accounts things such as the single-responsibility principle, it seems unlikely that a single class could grow to such a size.  It would seem that such a class could be a target for a future refactoring exercise.  Refactoring is a worthy cause.  There is no shortage of reading material that carefully constructs solid arguments for why it should be done.  But a more worthy cause is making software sell.  Pet projects and home-hobbies aside, software is of no benefit, if no one is using it. 

Commercial reality dictates that if a new feature will help sell more copies of the software, then adding the feature is what is important.  It is true that the more obfuscated code becomes, the harder it is to expand to incorporate new features.  I have heard of software projects grinding to a halt because adding new features simply became too difficult to accommodate. 

Using commercial pressures as an excuse to write sloppy code is not acceptable.  I have seen examples of code that looks like “the first thing that popped into the developer’s head” has been committed to the Revision Control System.  Often, with very little extra thought (read “time”) a neater, better solution could have been found.  This is where task estimation is important.  In my experience, programmers will use the amount of time allocated, to perform any task.  In all likelihood, they will get to the end of that time-frame and realise they overlooked at least one aspect and then take longer, but that is not the point I am trying to make here! 

If you have allocated “a day” to add a feature, then most often, that is how long it will take to add.  If you had allocated “half a day” for the same feature, then I would wager that the feature would have been added in about that half-day timeframe.  Granted, this is not always the case, but experience has shown me how often this is a surprisingly accurate revelation. 

This stems from the fact that if a programmer knows how long they are expected to take, they will get it working first, then tinker with the code until the time has elapsed.  Some “tinker time” assists in overall code readability.  If you are not prepared to add “code refactoring tasks” to your project plan (regardless of the project methodology you use) then allowing a certain “slackness” in task estimation allows your code a fighting chance of staying relatively neat.

When time pressures arise, neatness and accuracy of code are amongst the early casualties.  Unfortunately, this seems unavoidable and is just the price that is paid to remain profitable.  Whilst I strive to write and maintain neat, manageable, accurate code, I live in the real world and know that regularly revised source code over two years old (Eric’s example was seven years old) will likely be of the “too long / overly complex” variety.  I will not be one to criticise him for that.

Due to the “Global Financial Crisis”, my work-place has asked all its employees to participate in a “Furlough Program” to reduce revenue spent on wages.  For whatever reason, I had never heard of the term before.  For us, the Furlough program consists of each employee taking five days off (of the employee’s choice) as “unpaid leave”.  This does not affect our various “leave days” or share options programs, just our take home pay.

Monday was my first Furlough day, which I put to good use by going for a ride.  Not only was this good mental therapy for me, but I did my little bit for the economy by spending the money I wasn’t earning in other small communities.

There is something to be said for pleasure-riding on a week day.  The roads are less full of tourists, but more full of road-works and heavy transport. As I chose less popular roads to begin with, I managed to have the true sense of freedom that makes motorcycling such an appealing past time for many riders.

After an extended period of perfect motorcycle riding weather, it was fairly predictable that this day would be the day the weather turned.  Somehow I managed to avoid the rain, although I could not say the same for some of the roads on which I travelled.  The roads varied in quality and motorcycling appeal.  Some I had travelled before, some were “new” to me.  Some were so bumpy, I’m not planning on using them again!

I rode over 400 km (250 miles) on Monday, stopping to take photos along the way.  Unfortunately a couple of the best photo opportunities were lost, due to the look-outs being in the clouds.  Several incidents happened to me along the way, from which I learnt (or at least was reminded) of some important lessons:

1. Any ride for me will likely consist of at least some motorway/freeway riding.  At one stage I noticed a lounge chair in the emergency stopping lane to the side of the freeway.  A little over 500 metres further down the road, was a ute, also in the stopping lane.  In the back of the ute, was a matching chair…  I am guessing it was more luck than anything else that had seen the first chair end up on the side of the road, not in the middle of a lane.  From my perspective, this had not been a “close call”, but I have been in similar situations that were much closer.  It was a timely reminder to pay attention even in the boring bits of a ride.
2. I saw several kangaroos in a paddock.  Contrary to popular belief, if you live in an Australian city, you won’t see them hopping down the street.  I didn’t stop to take a photo of them, figuring if I saw another lot I would photograph them.  Of course, I didn’t. The lesson here is, never let a photo opportunity pass!
3. I rode through the village of Woodenbong.  It doesn’t mean what you might think!

For anyone around the Brisbane region of Queensland, this trip is roughly the one I took (albeit in the opposite direction).  I have put some of the photos of the day on my Flickr page.

What stops a bank teller from stealing money from a bank?  These people literally handle lots of cash.  It would seem that handling large amounts of cash can make them blasé about its value.  I am also sure that most bank tellers are ethical people too.  But I doubt that any bank would be happy with just these assurances that money was not going to be stolen by the tellers.  Instead, the processes used by the bank would generate an audit trail, sufficiently detailed that theft by tellers would quickly be discovered. If tellers stealing money is seen as a risk, then the risk is minimised by the processes used.

Not all careers are able to be adequately scrutinised by processes to avoid unethical dealings.  Doctors make the “Declaration of Geneva” - which is the modern version of the “Hippocratic oath”  . This is a statement regarding their ethical treatment of their patients.  Not being a doctor, I am not sure how seriously they take the oath, but, as a patient, I would like to believe that this is a binding principle for them. 

Computer programming strikes me as a career that could do with an “oath”.  Some programs have the ability to harm people, harm their finances or otherwise adversely affect human life.  How seriously do the programmers of such systems take their jobs?  Again, I would like to think that they take that responsibility very seriously.  Would taking an oath make a difference here?  Computer programming requires no formal education, and quite often the “rich and famous” leaders of the industry are mavericks without one.  Without formal qualifications, do you know whether or not the programmer has produced good quality work?  Unfortunately, these two aspects (“education” and “quality work”) are only tenuously linked in the computing field.  I use this point as a defence for my claim that we are still very much in the infancy of the computer industry.  In years to come, I hope the two are more closely aligned.

I believe that taking an appropriate oath could be an important aspect of computer programming in years to come.  Such an oath would require several parts to it:

Part 1: To be honest and ethical in code that is written.
This includes things such as not writing Trojan horses, illicit collection of users’ private data and ensuring that computational output given is truthful and accurate to the best of your ability.

Part 2: To follow industry best practises with respect to producing high-quality code.
Whatever I write here will date the article, but things such as writing unit-tests for code and following an appropriate development methodology are along the lines of what I am referring to.

Part 3: To reduce the severity or likelihood of errors when they are discovered in software.
The whole notion of “Bug prioritisation” is based upon fixing the most serious ones first, and leaving more obscure bugs with less impact until later.  This point in an oath is to ensure that bugs are not left behind for the wrong reasons.  (e.g. Because there were “more fun” bits to write)

Part 4: To periodically update technical skills through on-going education.
The intent here is to ensure that code written is done on the strongest and most relevant platform.  There is a balance required here.  On one side the aim is not to produce code that “rots” because it is old and unmaintainable and on the other side, trying to avoid re-writing everything in the latest trendy language.

I suspect that such an oath needs to be complied with “in the spirit that it is written”.  Programmers, by their very nature are constrained by binary logic.  As such, I could imagine an extreme-nerdy glee some programmers would have in deconstructing such an oath.  In this sense, “deconstructing” is exactly the right term to use:  Applying a warped perspective on a literal interpretation of an oath would not be constructive for our industry.  You have two choices when constructing something like an oath.  You can write it in straightforward simple terms and use the phrase “in the spirit that it is written”, or you can write it so precisely that there is no room for interpretation.  Precise wording undermines the effectiveness of a document by writing it in “legal-ese”.  No-one likes reading such a document and people often hide behind the excuse that they didn’t understand such a document.

I have never made the “Declaration of Geneva”, but I do understand what it means, and I expect any doctor that treats me to have made it, or a similar oath.  It could have been written with legal precision, but for the benefit of doctors and patients alike, it was not.  Similarly, if the software industry was bound by an oath or affirmation, then it would need to be one that could be understood by both the programmers and the end-users.

Do end-users care about ethical programmers?  I somehow doubt that it is as important to them as an ethical medical practitioner is, but they probably do expect that the software they use has been written by diligent programmers.  If you were to point out that private information on their computer may be accessible by a rogue program, then I expect they would care about the programmers being ethical as well!  Due to the all-pervasive nature of software in western society, you could wonder why the general-public has not started to care more, about such matters. With “public education”, you could probably raise the level of concern, but such an approach does seem to be way over the top.  It is probably just as effective for those of us in the industry to care about such matters.

I am currently serving on a jury.  If I was a well prepared blogger, I would have pre-written articles finished and ready to post during this time.

I am not, and I don’t. 

Sorry ’bout that!   

Motor vehicle suspension is comprised of two systems.  One deals with absorbing bumps in a controlled manner and the other deals with returning the wheel to its correct location relative to the vehicle.  It is the job of the spring to perform this latter task. 

A spring has a state at which it is described as being “at rest”.  In the case of springs used in motorcycle suspension, the spring can be compressed or expanded from this position.  This only occurs through the application of force.  For the most part, simple metal springs conform to Hooke’s law.  The more force (which can be measured in Newtons) applied to the spring, the more it compresses.  Hooke’s law is a linear equation.  So, if you apply twice as much force to a spring, you will compress it twice as far.
When a spring is released, it will return to its state of rest.  But, because the end of the spring is moving and has a mass, it has inertia.  This inertia is a force, which causes the spring to extend beyond its length at rest.  The spring continues to extend until the inertia can no longer overcome the force required to continue extending the spring.  At that point, the spring then starts to compress again to reach its state of rest.  If the spring were not losing energy in other ways, this expansion and compression would continue forever.  Here is a neat-o demo of springs doing what springs do.

Because the gradual dissipation of energy through air resistance and heat loss takes too long to keep motorcyclists happy, the shock absorber is used to overcome the spring’s inertia.  It dampens the rate at which a spring is compressed and expanded.

The more mass you attach to the end of a spring, the more momentum / inertia the spring end gains as it moves.  Because of this, the pogo effect of the spring is increased and stopping it requires more damping.  This in turn, reduces the efficiency of the shock absorber to do other things, such as absorb shocks from bumps!  On any vehicle, the mass attached to the end of the spring (such as the wheel, brake components, etcetera) is referred to as “un-sprung mass”.  As already indicated, unsprung mass compromises the effectiveness of shock absorbers and as a result, motorcycle designers and after-market specialists place an emphasis on reducing this mass as much as possible.

When replacing springs for a motorcycle, there is a measurement referred to as the “spring weight”.  The larger this number, the more force is required to compress the spring, meaning the spring feels “stiffer”.

The other factor in motorcycle springs is the preload adjuster.  Preload, is as it sounds.  It is the amount of extra load placed on the spring before the motorcycle hits a bump.  When you increase the preload, you are compressing the spring and taking it away from its state of rest.  Because of this, increasing the preload, increases the upward force the spring provides when the motorcycle suspension is at rest.  As you may have guessed, the mass of the motorcycle and rider (excluding the unsprung mass) also loads the motorcycle suspension, compressing the springs.  If the springs are compressed too much when the bike is at rest, it will not be able to adequately deal with any bumps you come across when riding.  Motorcycle designers can pick a spring weight suitable for the mass of the bike, but as they do not know the mass of the rider, they cannot be 100% accurate in their choice of springs.  Therefore, preload adjustment is used to fine-tune the suspension.

As per usual, this article is based upon my observations and my understanding of the laws of physics.  If I have made an error, please feel free to leave a comment.

I recently read an article on whether it was necessary to have a computer science degree to program computers professionally.  This is hardly a new topic, but it is one that will not go away. Well, I suspect unless it becomes mandatory to have a CS degree, this topic will periodically be raised.

Most times I read an argument from one side or the other, what becomes clear is whether the author has a CS degree.  If the author has one, then they tend to be in favour of a degree being mandatory.  Not surprisingly, those without one, are on the opposite side.  The university faculty that I went through was having an identity crisis at that time.   So, I started doing a science degree in computing and ended up with a Bachelor of Information Technology.  (That actually makes it sound quite dated!) The way I remember it, the course content hardly changed, so I think it is fair to say I have the equivalent of a CS degree.  This, of course, entitles me to take the high-and-mighty road and tut-tut anyone who doesn’t.  But, I’m not about to do so. “Why?”, I hear you ask…

Well, here is a list of the computer languages that I Iearnt in university:  Assembler, C, Cobol, Fortran, MicroSQL, Pascal, Prolog and SimScript  .  There may have been others, but these are the languages that spring to mind. (and not always for a good reason!)  Obviously, there were other subjects that weren’t computer languages in my studies.  There were four different strains of mathematics and various other topics based on what you would need to learn for the “real world”.  But, most of those units would now be as dated as the languages I mentioned above.  Bits and pieces of what I studied still help me today, but I struggle to believe that my almost twenty-year old university degree is a great asset to my current employer.  Fortunately for them, I try to keep learning!  

I believe that the computer industry is still very much in its infancy.  These days are the technological equivalent of living in the wild-west.  There are certainly plenty of cowboys around!  Another popular blogging theme amongst programmers is whether our jobs should be described as a “craft”, “engineering”, “discipline” and so on.  People use the term “software engineer”, but this is an injustice to the more formalised strains of engineering.  The real question should be “What do we want our profession to be thought of?” 

I am lucky enough to have a job I love doing.  I enjoy coding.  I can empathise with people who do not have a CS degree, but have a similar passion for programming.  I have no doubt that there are better programmers than myself, nor do I doubt that some of them will not have a formal qualification.  Given that they provide good work, would it be wrong to exclude these people from programming careers?

If we want to be taken as a serious profession, then we need to start being serious about it.  When you go to a doctor, you do not want an unqualified person treating you, no matter how much they like helping people. 

Is a comparison between the medical profession and computing justifiable?  Computers are so pervasive in western society, that bad software can and does kill people.  Granted not all software is as critical - maybe bad software in your area merely leads to people having “a bad day at the office”.  But, if you are serious about professional levels of service, then you will probably want to start emulating more formalised professions.  What I think this means is:

1.      A formal qualification in the field of computing.

2.      Compulsory membership in an accredited professional body – which includes a “Professional code of conduct” by which you must abide.

3.      Periodic examination to ensure skills remain up to date.

Point 1 could be seen as me condoning the requirement for a Computer Science degree.  But I wouldn’t want to rule out some other level of qualification counting.  At this point, I am just suggesting something that indicates a level of competence.

I could for-see that Points 2 and 3 are related.  A professional body would be able to provide training and examinations etc.  What I think should form a professional code of conduct is probably large enough to fill its own blog post, so I will leave that as a story for another time.

Am I daunted/scared by what I outlined above?  If I am honest, yes!  I never was the best student.  Exams have always daunted me somewhat, even in the rare instances where I knew the subject material very well! 

Do I see I.T. requiring this level of professional conduct?  Not at this stage.  Apparently, there is still a skills shortage, so employers will be unlikely to impose restrictions that see them unable to fill vacancies.  I do see one possible fundamental shift that will swing the industry towards formalisation, but that too, is a story for another time.

Motorcycle suspension has a variety of roles to play.  While rider comfort is one of the roles, the most important role is actually keeping the tyres in contact with the ground surface.  As the ground surface is rarely perfectly smooth, this means wheels need to travel “up and down” relative to the rest of the motorcycle to stay in contact with the surface.  This comes back to the laws of inertia.  The bike with its mass and velocity will not “track” to the bumps and so the suspension alters the distance between the road and the bike’s sprung mass.

After my own spectacularly underwhelming career as a motorcycle racer, my interest in motor-sport (and in particular motorcycle road-racing) has remained.  Club level racing is a great way of witnessing the enormous difference in talent from the A-graders down to the “also rans”.    I have attended club-days as a spectator and they provide an insight that watching top-level competition does not provide. 

One such revelation was the difference between suspension that has been set up well, and suspension that has not.  The event that stands out in my mind was at Victoria’s Broadford circuit.  At the end of the front straight was a particularly bumpy entry into turn one.  The riders would be braking heavily for Turn one, across a series of “ripples” that had formed in the track.  Watching the bikes at either end of the field (i.e. the fastest riders and the slowest riders) revealed vastly different “behaviour” from the bikes:  The fastest bikes were smooth and composed across the bumps.  The slowest, jumped and skipped across the bumps.  If you watched the two and were asked which ones looked faster, you would have probably guessed the wrong way around.  Put simply, the slowest riders were trying far harder to control their bikes, whilst the fastest riders didn’t look to be expending hardly any effort at all! 

There is obviously more to being good at motorcycle racing than having decent suspension, but the difference was striking.  Bad suspension fails to keep in contact with the road surface.  A wheel in the air, has no grip.   Good suspension also relays the “feel” of the road surface through to the rider.  The feedback given allows a rider the ability to judge the grip levels available.

Motorcycle suspension has an extra limitation applied to it, that cars do not have:  Motorcycles lean.  If you hit a 25mm high bump (approximately one inch) when travelling in a straight line, the suspension needs to compress 25mm to avoid the bump being transferred through to the rest of the motorcycle.  Once the motorcycle leans over, compressing the suspension changes both the vertical distance between bike and ground, as well as the horizontal distance. 

By recalling year nine trigonometry, we see that if you hit a 25mm bump at a 45 degree lean angle, the suspension now has to travel 29.4 mm.  Increase the lean angle to 50 degrees (from vertical), and the distance the suspension needs to travel increases to 33.6 mm.  (And you used to complain that you’d never use the stuff you learnt in maths in real life!)

On a lot of roads, the notion of a bump only being 25mm high is laughable.  In the real world, motorcycle suspension does not prevent some of the bump being transferred to the rest of the motorcycle.   Some transference is necessary or else the rider cannot feel what the bike is doing.  Bump (or “shock”) absorption occurs not only through the motorcycle suspension, but through the flexing of the tyres and indeed the motorcycle chassis.  If I recall correctly, in the early 90s, a lot of race bike manufacturers would make their frames with as little “flex” as possible in an attempt to improve the handling of their machines.  They reasoned that such an approach worked for car racing.  However, they found that some chassis flex (in certain directions) actually improved the handling of their bikes. 

In terms of components used for motorcycle suspension there are some fairly common approaches and a few that are less common.  Most modern sports-bikes consist of two front telescopic forks with internal springs controlling the front wheel and a single rear shock absorber with an external spring, controlling the rear wheel.  This is a fairly-standard evolutionary design, but by no means the only one.  Like most aspects of motorcycle design, this system is a compromise and alternative systems offer alternative advantages and disadvantages.  But that is a story for another time.

As I alluded to previously, if you are blogging to reach an audience that do not read blogs, then you’re doing it wrong!  I am sure there is a small percentage of programmers who want to be better at their profession but who do not know where to look, but these days this number must surely be approaching zero.  Those that will be inclined to search for good programming blogs have already done so.

Some programmers learn their craft in the approximate equivalent of a traditional trade-apprenticeship.  There is a risk though: the programmers may not be taking advice from the right channels.  In other words, the mentors in their programming journey are themselves, misled.  I do believe that as long as “students” still ask questions, they will continue to learn, despite the competence of their “mentors”. 

Despite this risk, verbal communication, feedback on progress and “learning by doing” appear to me to be the most powerful ways of learning technical skills.  At the other end of the effective learning scale, is “learning through cartoons”.  This approach may well work for young children, but I find the approach patronising!  I am wondering if there has been a sudden influx of cell-shading artists in the ranks of some of the bigger tech companies.  To be truthful, the cartoons are thinly veiled advertising for up-coming products or services, rather than an attempt at educating developers, but there is still an “undercurrent of teaching” and they are pitching to the technical end of the market. 

So far, I have only been exposed to two such cartoons.  I am fearful that they are the first of many…  The first was an introduction to the Google Chrome Web browser.  It was vaguely tolerable and not too condescending.

The second cartoon was from Microsoft.  Now I should point out that I am not a Microsoft basher.  No M$ abbreviations from me! :-) Despite a general interest in other technologies, it is programming on Microsoft Windows, that puts food on my table at the end of the day.   As a company, an IT leader and pretty much any other respect, Microsoft is not perfect, but nor is it clueless.  Which makes it harder for me to comprehend what were they thinking when they dreamed up “The Amazing Adventures of Kevlarr and the SDL.”   It really is head-shaking-ly terrible.

If you know of any other appallingly condescending cartoons for technical topics, please leave a comment.