Obscure Bug or Dumb Developer? Mmmm, Probably the Latter

Let me hope I'm not blogging too early, but I may have just solved something that has been driving me nuts!

I could not work out why Google refused to find my website, save for the PDF files.

I had everything in place I should, I thought -- robot.txt, sitemap, etc, etc. The site views fine with every browser I have on my PC.

But check it out with google webmaster and it says, on every page, "network unreachable".

And now I think I know why.

Like every good website, I'm tracking visitors, and since this was my first bit of development in ASP.NET, I added my own visit-recording routine. It picks off from the visitor's broswer a number of variables, including the UserLanguages collection. These are the default languages that you like to browse in, and was giving me a rough and ready guide to country of origin.

Except the googlebot browser is different. Either it or the object that .NET uses to represent it lacks this collection ... and in .NET, if you try to access something that isn't there, you get an error instead of your page.

Of course, I should have asked the question on the google forum ages ago, but you know, there are just some things you don't get around to! Well, I did today, and a kind respondent pointed me in the direction of a site (http://www.rexswain.com/httpview.html) that shows precisely what was going on from a web-botty perspective.

Dumb developer, I think, is really to blame. Hopefully, problem fixed. Fingers x-ed as I wait for google to moozy over to n10net for a new look. What a patient botty to keep putting up with my incompetence!

Doctor's Handwriting

Today's Radio 4 Today programme has a story where "Nearly one in 10 hospital prescriptions contain a mistake, ranging from the minor to the potentially lethal." (http://news.bbc.co.uk/1/hi/health/8391667.stm)

Reasons given include the inevitable issues of handwriting, but also prescribing drugs without regard to the patient's allergies, and getting the dosage wrong.

Why, I have to ask, are prescriptions being hand-written at all? Why not crossed referenced with a list of allergies to at least alert the doctor to possible conflicts? Checked to ensure no obvious mistakes in dosage?

Why not generated from a computer system to do all the above, and more?

Is there an opportunity for Ffenics here, for a PrescriptionEase, for a simple-to-generate and low-cost app?

Out of Sight, Not Out Of Mind: Thoughts on Ffenics Object Scripting

If you want to pass, say, the ID for a record to the setglobal function using Ffenics or DataEase scripting, you need to include some field object on screen.

So a typical scenario might be to create a virtual in your Ffenics form derived from the ID value (or to add a 'layout only field' to an aspect), place this field on the screen, and refer to its 'value' property in the script.

You don't necessarily want the actual data to appear to the user, so somehow you have to style it so that it is not visible, and scrunch it up in a corner somewhere to keep it out of range of the things you actually want the user to see. If it overlaps with visible objects, it may partially obscure them. And because you have set it to look like it is not there, it's hard to spot it when in designer view.

The new 'Hide' option on the Ffenics display dialog for an object does away with this, and can both simplifiy and help with development. By placing a field on screen and then checking this property, you can still reference the value it contains, but the object, as you'd imagine, simply does not appear. In addition, it can overlap with other visible objects without causing runtime oddities in appearance.

And you can give such objects a 'hidden field' style that, in designer view, makes them totally obvious (give them a nice bright red background, why don't you) so you can spot them when you're building your wonderful aspect, safe in the knowledge that they will be forever invisible to the user.