Speaking of large money pits…  I kept a spreadsheet to allow me to stick to my monthly budget.  This in itself seemed like a wise idea.  It does however put sharply into focus how much money I have poured into the project.  (Should that be “poor-ed”?)  Given the prices that RGVs demand these days, it is suffice to say that I would be making a loss if I sold the project at this point in time.

In terms of where the bike is “currently at”:

• It is still two packing shelves full of pieces.
• I have recently had the front forks and rear suspension rebuilt.  This was only the second time I have used a commercial business to do any serious work.
• I have sourced all the parts and I am in the middle of rebuilding the brakes.  That process will hopefully be a story for another time.
• About the only outstanding parts left to purchase are new chain and sprockets and new tyres.  (For some reason I just don’t trust twelve year old tyres…)

Things I have learnt along the way:

• I should not have attempted to restore this bike.  Despite starting with a “free” motorcycle, this project has cost a fortune!  It would have been cheaper to buy a running and almost road-worthy RGV and start from there.
• By doing the boring things first (such as frame straightening) rather than the fun things (such as painting fairings and buying bling parts) the restoration project didn’t start with a bang and run out of momentum.
• Some planning would have avoided the need to do things multiple times.  – I had to completely strip the bike to get part of the frame repaired.  I subsequently put the swing-arm rear suspension back on, only to remove the rear-shock to get it serviced later.
• Buy good tools.  They really do make the job easier.  On the other hand…  Some once-off style jobs are not worth spending a fortune on.  Sometimes it makes sense to take the part to a workshop where the job can be done for you.  Removing the bearings from the rear-suspension linkage was a good example.
• I have become quite good at watching where things (such as nuts / bolts / washers etc) go when I drop them on the ground.  This is an under-rated skill in my opinion.

One thing which I don’t need to learn is that this isn’t the end of spending money on the bike.  A track-bike is never finished and rarely cost free. Until I get the chance to properly put the bike through its paces, I don’t know if the gearbox is mechanically fine, whether the clutch plates slip and whether the engine will perform properly under load.  All these things will reveal themselves in the fullness of time!

Apple advertising pitches the iPad as a revolution. The revolutionary part is not the form-factor, nor the hardware, but rather the care-factor that went in to developing the device. Prior to this device, using a computer was akin to travelling to a foreign country where the residents spoke a foreign language. Sure, you could get around but it was a slightly difficult experience. If you went to the trouble of learning the environment/language, you got more out of the experience. The iPad was more like travelling to a neighbouring country that speaks the same language. The learning curve is almost non-existent.

This salt-pan-like learning curve enables people to feel an immediate mastery of their environment. It is empowering, which in turn leads to favourable experiences. One of the aspects I admire about the iPad is the quality of the default applications on it. Too often in the computing industry, the term “quality” is approximated to “lack of defects”. Quality should extend to usability and fitness of purpose.

The derogatory term “gold-plating” is levelled at some developers. For those unfamiliar with the concept, it basically suggests that a developer spends too much time perfecting some piece of code. After all “The perfect is the enemy of the good”.  The longer your software takes to develop, the more funds it requires. Prior to the software generating income, this is a financial burden. Therefore, it is important to avoid “gold-plating” – especially for “version 1” programs, but avoiding gold-plating is not an excuse to turn in poor work.
Apple have shown that going to the extra effort to produce good quality software can be financially rewarding. If people like your product enough to pay for it, then making software that more people like has an obvious incentive. If you work in a large corporate environment, turning out systems for internal use, the benefit is not as immediately obvious. If you think about the cost to your business in terms of lost productivity and training programs, you can start to appreciate that easier user interfaces save money, even if they do not generate it.
Making better software is hard work. A lot of effort has been expended in terms of producing systems that lead to less defective software. Revision Control Systems / Unit testing frameworks / Continuous Build tools / Static Code Analysis tools and more all aim to reduce software bugs. Can you name one automated tool that provides any support for developing better User Interfaces? I suspect a lack of these tools is due to the required level of intelligence needed to produce meaningful analysis of a user interface. Writing software that analyses UI suggests that the software understands what the UI is. I am no expert in the field of artificial intelligence, but I would suggest we are not quite at that level yet!
Having decided that human intelligence is needed to design User Interfaces does not mean that automated tools cannot assist. The “usability” of clickable targets are affected by things such as their size and location. The usefulness of text is reduced by overall length (Oh the irony in this blog post!) Modal dialogues provide “speed-bumps” to the user’s “work-flow”. Such aspects are quantifiable. Maybe such tools that measure such things already exist, but they certainly do not attract the attention of the programming masses.

Apple is leading the way in terms of “user-focused” software and there is nothing wrong with having a market leader that is doing a “good job”. Here is hoping that others will help raise the overall standard further by continuing to compete with Apple’s products!

1. I do not like iTunes.  There has always been something about iTunes that has not sat well with me.  For reasons I cannot put my finger on, I just don’t like the way it does things!  If it were not for the consumer lock in of iPods and iPhones and iWhatevers, I am convinced it would not be as prevalent as it is.
2. I  have an objection to DRM in music.  I consider myself to be pretty honest.  I buy music I want to listen to, but I will not pick a format that restricts how I want to listen to it.  I also could not be bothered trying to work out how to circumvent DRM.  Music is just something I want to listen to.  I do not want to fight it / worry about it / manipulate the format it appears in / lose it because I upgrade computers too often etc.  I can appreciate that some people will pirate music and that DRM probably prevents some people from doing so, but that does not change my opinion on the matter.
3. I wanted the potential to develop applications for a smart phone.  I know – I could jail-break the iPhone, but that falls into the same category of circumventing DRM.  I can’t be bothered!  There is a learning curve to starting development of smart-phone applications, and I do not need to introduce extra hurdles.

While these reasons are all true and valid for me, if I am completely honest…  There is something deep in my personality that makes me despise following the crowd.  As such, an iPhone was never going to cut it.  From what I read, iPhone market penetration in the US is not all pervasive.  In Australia, consumer gadget of choice, is an iPhone.  I am not sure what will happen when the oversized-novelty-iPhone (the iPad) is released here next week.  I am sure it will sell well, but not convinced it will be quite as ubiquitous.   Everytime I  catch public transport, I swear iPhones outnumber passengers.    Everywhere you look, iPhones abound.  I am writing this post on a plane, next to some guy listening to songs on his iPhone…  That this happened was not a surprise to me…

So, if “second place” is the first of the losers, I have fallen into that category.  My recent purchase was that of the HTC Desire.  From the little I have “played” with friend’s iPhones, the user experience is different.  With more buttons to press, I would not expect for Android devices to win converts from the Apple buyers out there.  Simply, there is a mental adjustment to make if you go from one system to the other.
Initial impressions are that it takes  a few days until you are comfortable with using the “menu” button to get to features in Applications.  The screen on the Desire absolutely beats the iPhone hands down.  I have no doubt that iPhone v4 will probably reverse this trend, but as it stands now, there is no contest.  Even though it has extra hardware buttons and I appreciate minimalism in design, I think the Desire is a better looking device.  I haven’t bothered putting a DRM free music library on the device as of yet, so won’t pass comment on the media player.  If I am to believe what I have read, this issue divides opinions like few others.

Regardless of brand loyalty etc, last night I had my first “I ♥ my smart-phone moment”.  I will not claim that this sequence could not be replicated on other types of smart-phones, but the whole technology came together in an almost magical way for me.

I have been in Melbourne travelling for work. I lived in Melbourne for years and know it reasonably well, but still enjoy exploring when I go back there.  I picked a suburb I could get to on the nearest tram and decided to go there for dinner…

• I used “Google Voice” and spoke: “Places to eat, South Melbourne”
• From the search results, I found a restaurant review website and picked a place I liked the sound of.
• I cut-n-paste the address into Google maps, so I knew how to get there.
• While I waited for the tram, I spotted a “star” close to the moon and pointed my phone running “Google Sky Map” at it to determine that it was actually Mars.
• On board the tram, I used the GPS to show me when I was close to the restaurant so I didn’t have to walk far.
• While waiting for my meal, (eating alone is a hazard of traveling for work) I caught up on some Geek news via the Engadget RSS feed.

It was simply brilliant!  I now know why people love these gadgets!

The new class has a “control” engine supplied by Honda and ”control” tyres, supplied by Dunlop.  I suspect the rules for the category were finalised at around the time of the Global Financial Crisis and have been heavily influenced by the desire to keep the costs of this class down.  As with the earlier change from 500cc two strokes, to the 990cc four stroke in the premier MotoGP class, this change in formula has generated a renewed enthusiasm amongst the racing fraternity.  As a result, around forty-three riders are partaking in the formula. 

The rules, plus the sheer number of bikes on the track have made for some quite interesting racing in the opening two events this year.  The knockers are quick to point out that the lap times are slower than the 250cc two strokes they replaced, but racing where plenty of overtaking takes place overrides this concern. 

When a new and significantly different category of racing starts, it ‘levels the playing fields” between the different teams.  Data gathered from previous years is no longer relevant and so, most teams feel they have a fighting chance of being “up at the pointy end of the field”.  Unfortunately, this only really lasts for one season.   The introduction of 990cc four strokes in MotoGP  saw renewed enthusiasm from manufacturers with Aprilia and Kawasaki fielding entries, and Ducati following the next year. 

Several years later, Aprilia and Kawasaki are gone.  Without good results, sponsorship is hard to come by.  Somehow, Suzuki still field bikes despite their lack of decent results.  Will the same fate of shrinking numbers on the grid befall Moto2?  Given the current huge number of bikes in the competition, you would expect some reduction in numbers over the next couple of years.  Hopefully the measures put in place to restrict costs will stop the wholesale decimation of the grid numbers.

As for me: personally, I am just hoping to see a good season of close racing and maybe witness the rise of a new champion in the sport.  Bring it on!

Example 1:  Get the class name

The IMetaDataImport interface provides functions called GetSomethingProps, which provide “properties” of the various tokens.  In the case of an mdTypeDef token, this method is called GetTypeDefProps.  Sticking with its strictly functional style, the Get*Props methods use heaps of out parameters to convey the information they need to.  One of the parameters passed in to GetTypeDefProps, is a buffer into which the function places the UTF8 encoded class name.  You get to specify the size of the buffer in one of the other parameters. (Can everyone say “potential buffer overrun”?)  The actual length of the class name, is returned by yet another parameter.  Here’s some pseudo-code:

if metaDataImport.GetTypeDefProps(typeDefToken, typeDefName, SizeOf(typeDefName), actualNameLength, modifierFlags, parentClassToken) == S_OK
  Print( “Class Name: %s”, typeDefName );

Aside from the name of the class, one of the other returned parameters that may be of interest is the ptdExtends parameter (parentClassToken in the pseudo-code example).  This token is either another type definition (mdTypeDef) or a type reference (mdTypeRef) token.  As you may have guessed, this is the token that belongs to the parent class.   Using this, you could walk the object hierarchy to see what classes this class descends from.  Remember my warning from the previous blog entry!  Make sure you check to see what sort of token you have got!  To get information from an mdTypeDef token use GetTypeDefProps. To get information from an mdTypeRef token, use GetTypeRefProps.

Example 2: Find the Attributes applied to the class

Using the mdTypeDef token we are able to enumerate all attributes applied to the current class.  Like the EnumTypeDefs function, EnumCustomAttributes fills a packed array with tokens for you to process.

enumerationHandle = 0
do
  if metaDataInfo.EnumCustomAttributes(enumerationHandle, typeDefToken, 0, attributeTokens, 5, numTokensReturned) == S_OK
    // Process the attribute tokens in any way you see fit.
  else
    numTokensReturned = 0;
while numTokensReturned > 0;
metaDataInfo.CloseEnum(enumerationHandle);

While the pseudo-code suggests you are free to do what you will with the returned tokens, in practice you will most likely be passing them through to the GetCustomAttributeProps  method. There are two likely out parameters of interest from this method.

The first interesting parameter, is a blob pointer.  This is a pointer to data representing the value of the custom attribute.  Deciphering the blob isn’t too tricky, especially if you have access to the source code for the custom attribute class.  Essentially, the blob is an encoding of the parameters the attribute was constructed with.  Actual blob interpretation is a story for another time.  If you are too impatient to wait, you can download the ECMA-335 Common Language Infrastructure (CLI) Partitions I to VI PDF and read about it yourself!  That should cure your over-eagerness… or your insomnia…

The other interesting out parameter is a token representing the type of the custom attribute.  If you wanted to use the token that represents the type of the custom attribute, you will need to pay attention to what sort of token this is!  It will not be anything as straight-forward as an mdTypeDef token!  Instead it will be an mdMethodDef or an mdMemberRef token!  For an mdMethodDef token, call GetMethodProps to get an mdTypeDef token for the attribute class.  If it’s an mdMemberRef, call GetMemberRefProps to determine the class’s token.  According to the documentation, the class’s token can be an mdTypeDef, mdTypeRef, mdTypeSpec, mdModuleRef or an mdMethodDef! So, you may well have some more processing to do with the returned token.  In my (somewhat limited) experience, the token has either been an mdTypeDef or mdTypeRef token.

Unfortunately, my requirements for using the unmanaged meta-data interfaces did not extend much beyond what I have already discussed.  From my trials and tribulations with the meta-data API, I found the documentation to be adequate, without being friendly.  It has been my attempt to help you string together a sequence of API calls to achieve an ends to your means.  If you have any questions on the subject matter, or corrections to my blogs, feel free to leave a comment.  Good luck!

The point of entry for using this API, is the IMetaDataDispenser / IMetaDataDispenserEx interface.  Using the standard technique of CoCreateInstance with the appropriate Class ID will give you a reference to it.  Unlike a lot of COM objects, IMetaDataDispenser is not exposed through a type library.  As such, you will need to find a declaration for it (and its Class ID).  If you’re programming in C++ , this declaration is found in cor.h.  I’m not.   Turning to the Internet, I found cor.h on the koders web site.

As an aside:  Of course, this meant I had to translate the relevant parts of cor.h into Delphi/Pascal code.  I did try one free / open source conversion tool.  Comically, it translated the braces into begin and end statements and nothing else.   I have not written C programs in ten years!  Still, I managed a more convincing translation than the software I tried!

The IMetaDataDispenser interface “dispenses” the other interfaces required to interrogate and manipulate the meta-data.  Think of it as using an abstract factory pattern.  The “easiest” way to access the meta-data is through the IMetaDataImport interface.  IMetaDataDispenser provides an OpenScope method, which takes an assembly file-name parameter and can “return” a reference to an IMetaDataImport.   Here is some pseudo code showing this:

if metadataDispenser.OpenScope(“assemblyFileName.dll”, 0, IID_IMetaDataImport, ppIUnk) == S_OK
  metadataImport = (IMetaDataImport)ppIUnk;

Although Meta-data can quite elegantly be described in terms of objects, the interface access to it is distinctly functional.  The meta-data provides information about an assembly’s make up.  This includes classes, methods of classes, interfaces, properties, custom-attributes and so on.  Each element that is described has a token.  When using the IMetaDataImport interface, you will refer to the element, by using this token.
One thing that eluded me for a while is the importance of the token’s value.  A token is an unsigned 32 bit value.  The most significant byte of the token determines the sort of token that it is.  That is, if the MSB’s value is 0×02 then the token describes a “type definition” (or “mdTypeDef”), or when the value is 0×0C the token describes a custom-attribute.  The full list of token types is described on the MSDN web-site.  The reason this is critical, is that some functions return related token values.  Furthermore, the one function may return tokens of different types!  You need to determine the type of token returned before you attempt to use the returned token in further operations.  Pass the wrong sort of token to a function, and the function will fail.
If you are reading the meta-data, most likely, you will want to run through all the available somethings.  To do this, you will need to use the appropriate “Enum” function.  The ones that I have used all work in pretty much the same manner:  They take a packed array in which to return the appropriate tokens and you also specify how many elements your array has (to prevent over-runs).  One of the “out” parameters tells you how many elements the function returned.  You can keep calling the function until the out parameters tell you there are no elements left. Time for another pseudo code example.  This one enumerates the type definitions in the assembly.  With this basic loop, you would be able to perform further interrogation on all the classes defined in the assembly:

enumerationHandle = 0
do
  if metaDataInfo.EnumTypeDefs(enumerationHandle, tokens, 5, numTokensReturned) == S_OK
    // Process the tokens in any way you see fit.
while numTokensReturned > 0;
metaDataInfo.CloseEnum(enumerationHandle);

The enumerationHandle parameter should be initialised to 0 before the first call to EnumTypeDefs and once you’re done with the enumerator pass it to the CloseEnum method to dispose of it.
The tokens parameter is the packed array which in the above example, would have room for five mdTypeDef tokens.
Tokens are all well and good, but they are hardly descriptive to anyone other than your IMetaDataImport reference.  Other functions in the IMetaDataImport interface will allow you to fetch the name of the class, or find its ancestor class.  But that is a story for another time.

	The first downward stroke is referred to as the Intake stroke.  At the top of the cylinder head, there are valves that open and close at different points in time.  The inlet valve (or valves) open during the intake stoke, allowing a fuel and air mixture to enter the cylinder.  Because the piston seals the cylinder when it travels downwards, it creates an area of low pressure above it.  This helps draw the fuel-air mixture in.
	At around the time the piston reaches bottom dead centre (BDC) the inlet valve closes, sealing the gasses in the cylinder. The piston then starts its second stroke: the compression stroke.  The piston travels back up, compressing the fuel-air mixture at the top of the cylinder.  The difference in volume between when the piston is at the bottom of its stroke and the top of its stroke, is commonly referred to as the engine’s compression ratio.
	Compressing a flammable gas in the presence of oxygen is somewhat fraught with problems.  Compressed gas gets hot.  Hot flammable gas can combust!  The octane rating of a fuel denotes how stable it is.  Engines with high compression ratios need high-octane fuel to prevent uncontrolled detonation during the compression stroke.
	Once the piston reaches top dead centre (TDC) the compressed fuel-air mixture is ignited by the spark plug. This causes the gas to ignite and expand rapidly.
	The valves in the cylinder head remain closed at this stage, so the only way the gas can expand is by forcing the piston back down the cylinder. This is referred to as the Power stroke.
	All things going well, by the time the cylinder reaches BDC again, all the gasses have been burnt.
	No further kinetic energy is to be gained from them and they need to be removed from the cylinder, ready for the next cycle. The outlet valve (or valves) open and the now rising piston forces the exhaust gasses out through them. This is known as the exhaust stroke. At the completion of the exhaust stroke, the exhaust valve has closed and we are ready to repeat the entire process.

Two stroke engines work in a similar manner, but combine the intake /power strokes together and the compression / exhaust strokes.  How this is done, is a story for another time.

Anyway, this is an article akin to playing devil’s advocate.  I am not particularly comfortable with what I suggest below. I have written it purely to get people thinking about the time and effort expended writing software.  As always, I encourage your comments – positive or negative.

One of the odd things about the software industry, is that code “rots”.  This is somewhat strange.  Source code, written in text files does not “degrade”.  Unlike organic reproduction, copying a file leads to a perfect reproduction.  If you kept a copy of code written say twenty years ago, it would still be the same today as it was then.  Things change rapidly in the computing industry.  As a result, it is extremely unlikely that you could use that twenty-year old code on a modern computer.  A different form of “rotting code” exists precisely because the code does change.  Over time, countless little hacks or quirks can be added to an active code base that leads to obfuscation and “unhealthy” code.

The common technique to reducing code-rot is refactoring.  By having comprehensive unit tests, refactoring exercises help keep a code base current and ensure that changes made do not lead to regression bugs.  Working on a well-maintained code-base is a more pleasant experience for a developer.  Well-maintained code is easier to extend and developers have less fear of making mistakes.
“Technical debt” is a term coined by Ward Cunningham and refers to the “price paid” for releasing code for the first time.  He argued that a small debt was useful to incur, as it helped speed up the development process.  It was okay to incur some debt as long as it was “paid back quickly” by refactoring the code.

“The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation…”

Productivity graphs show how progress drops away on poorly maintained projects.  The longer the project runs, the harder it becomes to add features or fix bugs without causing other regressions.  The solution to the problem is to avoid as much technical debt as possible. Following best practices will help achieve this goal.  But is this done at too high a cost?  Following best practices adds extra work and thus does slow down development early in the life-cycle of the project.

Not repaying technical debt will grind a software project to a halt.  If you use an analogy of credtit card debt equating to technical debt, having the software project grind to a halt is the equivalent of declaring bankruptcy.   Obviously, this is not a great outcome, but it is not the end of the world either.

What if your software has run the term of its natural life?  Your software will have been written to meet a specific need.  Maybe that need is no longer there.  Maybe that need is now perfectly met, or the market has been saturated and sales have evaporated.  Maybe every feature that could be added, has been added (including reading mail).    If the project gets “sun-setted” does it really matter how much technical debt is left in the code base?

Not “doing things the best I can” is something I struggle with.  “Doing the best I can” and “doing things well” do not necessarily mean the same thing.  Obviously, the process of software development happens on a linear scale.  Software tends not to be written “the best way” or “the worst way” but rather somewhere in the middle.  If the process your team uses is close enough to “the best way” end of the scale to not be crippled by technical debt, then maybe that is good enough.

Rotary engines are dissimilar enough to require their own discussion, so if these are of interest to you, then I recommend you look elsewhere.  The other types of engines mentioned, all feature a piston attached to the crankshaft via a conrod travelling up and down inside a cylinder.

When the fuel-air mixture is ignited the piston is at the top of its stroke and the gasses expand, forcing the piston down.  This is the “power stroke”.   The distance the piston travels from the top of its stroke to the bottom, is measured and referred to (rather unimaginatively)  as the engine’s “stroke”.  The diameter of the cylinder in which the piston travels is measured and called the “bore” size.

Together, the bore and stroke of an engine are used to define the engine capacity.  The volume of the cylinder , which has the diameter of the bore, and the height of the stroke, gives you the capacity of a single cylinder.  Multiply this figure by the number of cylinders in the engine and you have the total engine capacity.

EXAMPLE:
If a four cylinder engine has a bore of 74mm and a stroke of 58mm…
For those of you who do not remember:
V = π * r ² * height.
The radius is 3.7cm (half the bore) and the height is 5.8cm.
Using the formula, a single cylinder, has a capacity of 249.45 cubic centimetres (cc).
Multiply this by the number of cylinders and you end up with a 997.8cc engine.

As a piston travels up and down inside a cylinder, it must come to a complete stop and change direction.  Arresting and reversing the piston’s momentum takes energy.  The faster the piston is travelling, and the heavier the piston is, the more energy is required.  This energy is supplied by the momentum of the crankshaft.  This means that some of the engine’s output is spent  in changing the velocity of the piston.  For this reason, there tends to be an optimum speed at which the piston travels.  The longer the stroke of an engine, the further the piston travels.  So, in an engine with a long stroke, the piston travels faster at a given crankshaft speed than in an engine with a short stroke.  As a rule of thumb:  the longer the stroke of an engine, the slower the maximum revolutions per minute (RPM).

There is no ideal size for an engine bore or stroke.  A lot depends on what the engine is powering.   Engines that need to move a lot of weight, require more torque.

Torque is a twisting force applied to an object, like a wheel or a crankshaft.   For our purposes, we will consider that torque is measured in pounds-force feet (lbf-ft) meaning the equivalent of a given force, in pounds, acting on the end of a lever of length in feet. … For example, standing with 180 pounds body weight on a lug wrench one foot long yields 180 lbf-ft of torque.

Work is the application of force over a distance. Unfortunately, the units used are the same (pounds times feet) but we write this as ft-lb just to distinguish it. The real difference is that in this case, the “feet” part means feet of movement.

Power is the application of work within a finite time. 550 ft-lb of work in one second is one horsepower.

From this, we can see that torque and power are related.  In fact:

hp = (torque * RPM) / 5250
(Where torque is measured in lbf-ft)

Another rule of thumb is that: engines with a longer stroke produce more torque.  There are other factors that influence power and torque outputs of an engine.  Cubic capacity never goes astray when you need more power and torque…

A motorcycle does not need to shift a vast amount of mass – but tends to be size constrained.  (unless of course, you are prepared to just jam in a big car engine)

More weight conscious sports bikes tend to concentrate on obtaining a high power figure, over obtaining a high torque figure.  Given the formula above, we can see that to produce more power, we either need more torque or more engine revs.  So, sports bikes tend to concentrate on producing power by spinning quickly, which means they end up having a short stroke.

Getting the fuel-air mixture into the combustion chamber also affects power and torque figures of an engine, but that is a story for another time.