Hello, Goodbye

This post marks the end of this blog on Blogger. After publishing I will be finishing the migration of all my content to distributelife.com. Distributed Life is my own blog and the direction I want to take with my content. If I get the automagic confibulated correctly, your RSS feeds will be automatically routed.

All the posts will be left here (for people who have linked externally) but I will be redirecting all links over to distributedlife.com.

My time at Blogger has not been entirely bad. While I do complain, Blogger did and has served a purpose that I found useful at the time of me starting. That is no longer the case and as such I am moving that fits my requirements.

I hope to see you there.


Regards,
Ryan Boucher (aka Chad Aubergine Stone)

Blogger Defects

This week's defect is one that has been building up for a while. So much so that I really should have reported these sooner and they may have been resolved by now. In any case I found a better solution for me, but you will have to wait for my next post.

These have not been directly reported to blogger. Their defect reporting mechanism is for the user to post on Google Groups. This is hardly a formal support mechanism in my eyes. I prefer to raise my defect through formal channels. The owner will get back to me if need be. Having a public knowledge base is fine, but it should be updated and maintained after each report. This allows similar defects to be collated together. It also means that I am not searching through a forum to see if someone else has raised the defect. There are 17,000 posts under Blogger Support on Google Groups. End Rant.

Defect: Future dates

The 'post options' section of a post by default sets the current date and time of when you created the post. The problem is that this information is used for future dating (or in my case past-dating posts). I can take up to two weeks to write a post. Some of my longer, more involved, posts do take that long as I primarily write my posts in between compiles. Little snippets here and there. When I finally do post the date of the post is published from when I started my draft. This is not common usage. Specific post dates should only be applied if the user specifies the date. Otherwise the date/time of the post should be when I click "publish post". This defect has only existed since they implemented future dating functionality.

To replicate:

1. Create blogger post before midnight


2. Wait until after midnight


3. Publish post


4. The post will be published with yesterday's date rather than today's.

Workaround:

Manually update the post date/time to a few minutes ago before you post.

Reliability Issue: Connection with blogger.com

Just recently the number of times the autosave process fails because it cannot connect to blogger is increasing. this never used to occur but it is at the current point in time occurring approximately once every two days.

This forces me to cut and paste my post into a notepad document and then re-edit my post. After this I must re-create my links. Not a pleasurable process.

I am unsure how to replicate this but it may be related to the number of times the autosave process is fired off. It may be worth reducing that amount to a timer or similar. Or implementing a mechanism by which the connection is reestablished.

Potential Defect: XML Support

Blogger posts do not like XML markup. This makes it difficult to write about xml. In my post here I struggled because of this issue. Cutting and pasting xml into my edit box at one point caused me to lose my entire post due to some on-save process.

If blogger.com is steadfast in its lack of support for xml content presentation, a solution is to sanitise message text on save to avoid such issues.

Usability: Poor script performance on low-end machines

The "Save Now" / "Autosave" function is too eager. It fires off on every keystroke. This impacts performance on low end machines where it can almost impossible to write properly. I shudder to consider performance on a mobile device.

Part of the problem is the lack of flexibility in the autosave mechanism. Low end users should be provided with a session based option to disable autosave or at least push it out to a configurable time limit.

Finally, the autosave option fires on nonvisible characters. For instance, using the arrow keys to navigate around a post will cause the autosave feature to fire. This not required and a performance penalty on low end machines.

Suggested usability enhancements

• Images when added are always inserted at the top of the post. This is a pain, especially for someone who is writing a long post.

• A mechanism should be provide (outside of HTML crafting) to allow users to specify wider posts. The current post width is akin to writing on the side of a milk carton. While there is some justification for maximising the post width to a fixed line length to improve readability it, ideally should be left to the users.
  

Why I am making defects public

I am liking the concept of making "charity" defect reports. Rather than ranting and raving about the ineptitude of developer X because of problem Y, I will raise a defect, make a post and hope that it gets fixed. I call it a charity because I won't charge for this service; it's more about making software better. Every second post won't be a defect report either. More likely no more than one a week depending on how many bugs are inhibiting my current work. I won't go looking for defects; I get paid to do that already and have much better things to do with my spare time.

My justification and reasoning for making them public and not just silently reporting the defect are as follows:

Firstly, one can never be sure that a defect will be fixed once it has been reported. The vendor may just ignore the defect thinking it only effects a minority. Making it public can allows other users to become aware of the defect and can therefore add their weight to the "urgency factor".

Secondly, inexperienced users often suffer from a lack of self-confidence with computers. When something doesn't work they blame themselves. If they read about a defect that I or someone else raises they realise it wasn't their fault. This may strengthen their resolve towards continuing the use of the application.

Next, some bugs present an inability to achieve a workflow. Making the issues apparent may not provide the workaround, but may enable someone else to uncover a workaround. This can be appended to the initial defect which is now the common source for knowledge on the defect. This can maximise the dissipation of knowledge to users and provides a problem and solution in a single place. This leads me to my next point.

This is all indexed by Google. When I have a problem with an application I search for a solution, then a workaround and finally, if I can't find either, a different application. By making a defect report public I can help others in their defect resolution quests.

Defect resolution

With the Nokia defect, someone posted a comment saying "thanks". I don't expect that. What I do expect, as I'll raise a defect directly with the vendor/developer, is that when the defect is resolved, they will notify me. If such an event occurs. I will edit and top-post my original message with the updated information saying something like: "Defect has been fixed in version X.Y. Upgrade to solve this problem".

This now provides the ideal scenario. Anyone who hasn't upgraded yet, and searches for the problem, will find the defect and solution posted together.

note: I don't expect every defect I raise to be solved post-haste. Some may never be. But I've done what I can to help the situation outside of forking my own branch of the code and fixing it myself.

Fifty!

50 Posts! w00t!

As a cricket fan I think it is appropriate that I raise my keyboard in recognition of this milestone. For those that don't know anything about cricket when a batting player reaches a significant milestone they raise their bat in recognition of the milestone. Batters are also raising their bat to recognise the support they get from the team and from the crowd.

I consider writing fifty posts an achievement. Whilst by no stretch would I call it an impossible task and nor am I the first to achieve this goal. But much like a cricket player the first fifty you make on the big stage is memorable, your first century even more so. The first milestones are always important because they confirm the belief that you hold inside that you can achieve your goals. Anyone can write a blog post (and anyone does) much in the same way that anyone can hold a cricket bat (and anyone should). I also wouldn't say that my fifty posts are elegantly crafted prose but when I first picked up a cricket bat I couldn't use it either. As a matter of fact it took me five years to reach double figures and another three seasons after that to score my first and only fifty. Each time I went out to bat I took what I learnt from my previous efforts and slowly became the player I am today.

Before you think that I am a total cricketing inebriate I have always been a bowler and you may think that a cricketing analogy involving five wicket innings and ten wicket matches would be more appropriate. But if I only did what I was already good at I would never have scored that fifty and I would never have written these fifty posts.

With my analogy of cricket well and truly overdone, my raising of the keyboard is a sign of thanks to those that have supported my efforts (proofreading, editing, commenting or just reading) and I hope that this milestone will become the foundation of a much greater innings. I'm sure it will as long as I can keep learning from each post.

note: Yes, this what I look like.

Advertising @ the French Open

I was watching some tennis on the weekend and noticed that advertisers are required to change their brand colours to suite the basic French Open colour scheme. At first I thought this was just a "European" angle on advertising as I remembered being told a story about a town in Germany that managed to force McDonald's to change its logos and general colour combinations to suite the style of the town.

After doing a bit of searching on the tubes I couldn't find any pictures of that town, so you will have to believe me. What I did see is that the Australian Open didn't go to the same extents as the French Open. Here is a image from the Australian Open and here is one from the French Open. While the difference isn't significant, the French Open setup was a lot easier on my eyes with the advertising blending in and creating a much nicer visual experience.

If only we could start getting some websites to care about how much advertising affects their overall visual experience.

Hark, where are thou keys?

I was talking to my mothra (mum) last night and she had recently found an email I had sent back in August 2005. If I remember correctly I sent this to my boss because I was late and I couldn't find my car keys.

I’ve been looking for half an hour, to the point I’ve looked into the shower.
I’ve searched high and low, left and right. In a bank of snow, with and without light.
I’ve looked far and wide, deep and shallow. Under my feet and, under my pillow.
So if you see my keys then let me know. A reward you will see, to work I will go.
To ease my thoughts and waste my time. I had a coffee and wrote this rhyme.

I think it took a few days to find my keys. They had fallen down the back of one our La-Z Boy chairs and had gotten caught in the internal framework. This meant that they couldn't be found by putting your hand down the side of the chair, nor could they be seen by lifting the chair off the ground. Fun!

Have a good weekend!

Attachments and Requirements in QualityCenter with C#

Previously I covered creating new requirements and how to handle requirement post failure. Today I'll cover attachments which are fairly trivial but have a gotcha that might not be immediately obvious.

To add an attachment to a requirement, the requirement must already have been posted. Otherwise you will get an exception. The following code is how to add the attachment. It is very simple.

code - adding attachments to requirements

Debugging
When you set the path of the image it will be adjusted from something similar to: "D:\\Path\\to\\my\\image.jpg"
to:
"C:\\DOCUME~1\\user\\LOCALS~1\\Temp\\TD_80\\504857af\\Attach\\ REQ1722\\D:\\path\\to\\my\\image.jpg"

Whether this is an artifact of the Quality Center API or the .NET development environment is beyond my knowledge of either.

The gotcha?
You have to add your attachments after creating any child objects. Otherwise every single child requirement (and their children will get a flag added on them saying that a parent requirement has changed and that you should review the potential impacts of such a change). Sometimes you want this, sometimes you don't. If you do it accidentally it can take a long time to remove all those flags.