Tuesday, 24 June 2008

Vista's UAC outdated design?

My work machine has recently been "upgraded" to Windows Vista. I have an application which works flawlessly under Windows XP. One of the applications features is to generate reports to rtf file. When I attempt to do so Vista warns me that I cannot write to the users\documents folder because it is readonly.

Yes that is correct apparently Vista believes that the users own Documents folder, created by Microsoft for the purpose of writing data, cannot be written to by the user. Now the permissions are such that the user, administrators, system and network service all have full control of this folder.

Now the user is able to save files from this application to a network drive, and can create files from outside of this application to the user's documents folder, but combining the two fails.

However, if I disable UAC then I am able to write to the folder. Amazing UAC makes my personal documents folder readonly for some applications against my will...

UAC appears to offer even more irritation than simply making you click continue all the time when you are trying to use your computer. Now as an MCSE etc. I understand the purpose of security, but as a software developer I also understand UI design. It is well known that your standard OK Cancel buttons are ignored by the less competent users. These are the very users that UAC is attempting to protect. UAC quickly becomes an automatic and meaningless click.

Security needs to be practical. For example if your company implements a strong password policy, 8 digit alpha numeric, with uppercase and lower case required, that must be changes each month and cannot be the same as the last 12 used, well quite simply 2 things will happen, the IT department will have hundreds of "reset my password" calls, and users will write down their passwords on a piece of paper so that they can remember them. If someone just needs to read the password off a piece of paper it completely defeats the point of introducing strong password policy...the same is true of the UAC.

Saturday, 7 June 2008

A simply beautiful story

Well I was sent a video of "Team Hoyt", and in terms of emotional stories this had to be one of the most beautiful. Dick Hoyt competes in Iron Man races with his quadriplegic son. He swims 3.8km followed by cycling 180km and then 42km run all the time towing his son. Completing an Iron Man is hard enough, then to think that Dick Hoyt competed at the age of 54 while carrying his son who has had cerebral palsy from birth.

If you are ever feeling hard done by and need some inspiration, then Dick Hoyt and his Boston University graduate quadriplegic son Rick Hoyt should be more than enough for any one.

When asked what one thing Rick wished he could give his father, his reply was "The thing I'd most like is that my dad would sit in the chair and I would push him once."

Video of team Hoyt

Friday, 6 June 2008

BMW 320i is pointless

I have been looking for a new car for over a year now, and one of those cars high on the list was a 3 series BMW. With my money ever draining out of my pocket I thought I would look into the affordability of a new 320 BMW.


Recent tax law changes and current petrol prices have IMO made the 2001-2003 BMW 320 petrol car a pointless vehicle. The other engines in the range make a lot more sense to buy.


For simplicity I have listed the 2001 model specifications for various 3 series BMWs (sports manual) and given the price per litre of petrol 116p and 129p for diesel, their price per mile of travel. The second hand price of each model is not considered as I have seen examples all at similar prices, in theory also the re-sale price will remain proportional to the initial price and therefore this is not a real factor in the TCO. Also I have not taken into account replacement parts costs of the vehicles. I have assumed that you will drive 10000 miles each year. I have taken 14 as the base insurance rate and +£50 for each increase in group (this is an approximation of my insurance, £50 more for each IG above 14...)


ModelMPG0-60CostRoad taxInsurance Group
320i318 secs17.03 pence/Mile£43015
330i316.3 secs17.03 pence/Mile£43017
320d498.6 secs11.98 pence/Mile£15514
330d427.6 secs13.98 pence/Mile£21016

So if you look at this table you will see that a 330D is £475 per year cheaper than a 320i, and for that saving you get a car with 5% more acceleration 0-60.


The cheapest option is significant with the 320D being £830 cheaper per year than a 320i for a 7% acceleration decrease.


For my mind though it is significant that with a 330i you pay just £100 more per year than a 320i and get a 21% acceleration increase!


Essentially my point stands, why get a 320i, the 320d is dramatically cheaper, the 330i costs only a little more and yet performs dramatically better, and the 330D looks like a good compromise, being faster and a lot cheaper than the 320i!

Tuesday, 3 June 2008

SugarCRM

I feel like I am having a personal battle with SugarCRM at work. We have a professional licence and the most recent upgrade 5.0.0e has a large number of bugs that affect us.

I can see why the bugs exist, they fundamentally changed several important database relations, while retaining the old relationships. I assume they kept the old relationships so that they would not break existing modules, however, doing this has (for me at least) caused a lot more problems than it has solved.

I have logged 8 calls with SugarCRM so far after the upgrade. Each time they come back to me suggesting the problem is server related, or database connectivity, and they "cannot reproduce the problem".

I was most frustrated when I gave a 5 step procedure to replicate a bug using their own http://demo.sugarcrm.com/ website. I received a response with a screen shot at step 4 saying "I cannot reproduce the behaviour you are talking about". After my reply saying that you missed out step 5 in the procedure and here is a screenshot of the bug it was logged against their bugs database.

Another issue that was frustrating me was suggested to be php sessions failing to write to the server. This seemed odd as it was the same single element in a whole page of elements was not populating correctly and that there had not been a problem prior to upgrade. As I was getting no where with the support team I went deeper into debugging and found that a specific javascript file was causing the problem. "quicksearch.js"

It was meant to give an autocomplete and validate on a specific field, but it has 2 issues.

1. It sometimes requests the wrong information if you use the delete key and so the array it comes back with is completely wrong.
2. Even when it gets the correct information it can cache the array incorrect and so fail to autocomplete / valid.

This problem took ages to work out as the quicksearch.js is written without any commenting, or spacing...

Anyway, I hope this time at the 3rd attempt they will log this one as a bug to be fixed.