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.

The potential defect

For those that want to know the defect was a memory problem. The application (Nokia Nseries PC Suite) when you changed from tab to tab, would acquire a several 100k of private bytes. If you keep changing tabs the memory usage continues to climb. This application is designed to start with the computer and remain operational the entire time (its for phone synchronisation). If you didn't turn your computer off at night after a few days of usage its memory usage can get quite high.

Personally I don't really use the application, as a matter fact it bugged me, because it starts when Windows starts and I don't like applications to do that without asking first. I was looking for a way to turn that "feature" off and just happened to have process explorer open on my secondary monitor set to sort by private bytes. After much clicking about, I noticed it work its way up the list... after that, like all good testers, I was deliberately trying to workout what was causing the memory usage to rise.

Reporting Defects in Proprietary Software

I, like just about everyone else on the planet, find bugs in proprietary software. Sometimes I like to report them to the vendor. One thing that really annoys me is how hard it is to report a bug. Often these sites have no Contact Us about Gaping Holes In Our Software, or more frequent Contact Us regarding Potential Software Problems.

This is even more the case for non-software companies that produce software. Often to accompany their hardware. I shall use Nokia in my example. I would still say that they are a non-software company (they make phones) but are heading in the direction of being at least partially a software company (they are trying to buy Trolltech) and invest in other software companies like Symbian.

Nowhere on their site was a place to report a defect in any of their software products. In the end I sent an email with the defect report to the customer service people responsible for my phone and asked them to forward it on. Not an ideal solution and normally if it gets to this point I don't bother. Today I must be feeling extra kind.

At this point I would state my hard-line position and say something like: Seriously, if you produce software in any form provide a mechanism by which users can report bugs in your software. An email address is usually enough for me. A potentially better solution is to make use of Windows Error Reporting. I've never used it, but I can't see how it couldn't be useful. Every little bit of information regarding your applications reliability in the field is useful. Note that WER is only useful for crashing or hanging apps.

The problem is that non-software companies that produce software, traditionally, don't have organisation practices around defect reporting, management and the eventual software evolution that occurs from that. The smaller or less mature the company is, the greater the chance of them not having such practices.

There is not much you can do about that. Supporting software is an expensive process. Even if they wanted to, it may not be possible for them to setup the requisite infrastructure. Some may argue that they should have thought of this before getting in the game. That doesn't change the fact that the software is already written, and if the vendor has gone bankrupt then you have zero chance.

What about the concept of a open defect registry? Where users can report problems with bugs against the software that they use. It would mean that defect is documented somewhere but doesn't solve the following problems:

1. doesn't mean the developer will fix it
2. someone has to manage the defects being report to handle duplicates or non-a-defect
3. the service would effectively be doing the work of software companies for free
4. still doesn't help if the vendor is out of business
   

The first issue applies to defects reported by formal process with the vendor. You can't help that. The second two points could be solved by charge vendors a nominal flat fee to access the defect information regarding their software. This does two things, pays for someone to manage defects and secondly allow for the operational costs to be spread out over many organisations. Reducing the cost of defect management across the board.

The final problem of vendor's going out of business. What we need on top of that is an open source graveyard where applications that are still being used but are no longer supported have the code release to the public. They are kept at a common location allowing open-source developers to revive them to fix bugs or extend per demand.

Eventual advantages of this process allow users to rate the importance of a defect, giving vendors better visibility into the top 20% of defects. An API for automate defect reporting by software and better software all around.

note: This wasn't intended to be a post about a shared service of defect reporting. Train of thought blogging, ftw!

defect in microsoft stl queue documentation

I've just spent the last four or five hours trying to work out why my asynchronous tasking code doesn't work.

After a while it turned out that the last element in my queue was being mangled when I was freeing the memory associated with the current work item. This could be one of two things:

• I'm not popping the element of the back of the queue or,
  
• Somehow I've mixed my pointers up while adding them to the queue and more than one queued task is looking at the same memory. The code that adds elements to the queue is a different thread to the one that handled it.

I looked at the intellisense for the pop command on the std::queue. "erase element at end" is what it says. So I thought, it must be something to do with thread-safety. Spend a bit more time writing down memory addresses to verify my code is logically correct. Nope, nothing wrong with what I'm doing. Just on the off chance I open up the sql queue code and have a look at the pop method and this little gem is what I found:

void push(const value_type& _Val)
{ // insert element at beginning
c.push_back(_Val);
}

void pop()
{ // erase element at end
c.pop_front();
}

A couple of lines of incorrect commenting in a row. Easier enough mistake to make but probably shouldn't have passed peer review. Documentation is an invalable tool but only if it is correct. You can take this as a friendly reminder to make sure you include documentation reviews in your peer review process.

For reference this the stl version v4.05:0009 what ships with Microsoft Visual Studio 2005