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!
Thursday 10 December 2009
Thursday 3 December 2009
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?
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?
Wednesday 2 December 2009
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.
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.
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.
Friday 27 November 2009
That Was The Workshop That Was
At the start of this week I ran my second DataEase/Ffenics training workshop.
The first one was eight years ago, and I do kick myself for not having thought to run more since. Still, I've started again, and will absolutely maybe do it again in the new year.
Last time I ran the event in conjunction with Richard Laidler, who's now retired from the DE world. So it was (mostly) all my own work. I'm not the greatest of organisers, but it wasn't that complicated to arrange. Choosing my birth town of Bristol eliminated a few practical issues, and a bit of time putting together a website, and promoting it largely through the Ffenics forum gained enough interest to make it worthwhile.
The great thing about workshops and conference gatherings and the like is you get to spend a day or two, immersing yourself in the subject. I imagine for most of us, our development time is a solitary one, with little opportunity to explore with a single colleague, let alone several people, the things we are trying to solve, and find the other person enthused in the process.
The benefit is not simply that you learn new techniques and solve or confirm old problems. I think we are addressing one of those higher levels in Maslow's hierarchy of needs -- esteem. No doubt we all may from time to time feel buffeted by the gales of change that forever blow through the world of IT, and wonder whether our trusty boat The Good Ship Ffenics is up to the job of navigating these windy seas. I'd like to think that our two days this week gave a good confidence boost to attendees, not just because of my incredible words of wisdom and demo apps, but to engage with the others there, and see their apps rocking in action. Hey, even my brother, whose a C++/PhP type of developer, was impressed with Ffenics!
Anyway, enough of this for the moment. I hope to get to grips with extracting some usable video footage from the small pile of DVDs in front of me, if I can ever get over the embarrassment of watching myself gesticulating like a windmill on acid!
Thanks to Graham Smith at PLM Consulting in the USA, who gave a Webex/Skype presentation to the group on styling and code reuse, and to delegate John Baldwin, who agreed to kick off a debate about some of the difficulties he's had in moving from DOS to Ffenics. To the other delegates for making the journey over to Bristol ... and to my brother Neill, who videoed and gopher’ed for me.
The first one was eight years ago, and I do kick myself for not having thought to run more since. Still, I've started again, and will absolutely maybe do it again in the new year.
Last time I ran the event in conjunction with Richard Laidler, who's now retired from the DE world. So it was (mostly) all my own work. I'm not the greatest of organisers, but it wasn't that complicated to arrange. Choosing my birth town of Bristol eliminated a few practical issues, and a bit of time putting together a website, and promoting it largely through the Ffenics forum gained enough interest to make it worthwhile.
The great thing about workshops and conference gatherings and the like is you get to spend a day or two, immersing yourself in the subject. I imagine for most of us, our development time is a solitary one, with little opportunity to explore with a single colleague, let alone several people, the things we are trying to solve, and find the other person enthused in the process.
The benefit is not simply that you learn new techniques and solve or confirm old problems. I think we are addressing one of those higher levels in Maslow's hierarchy of needs -- esteem. No doubt we all may from time to time feel buffeted by the gales of change that forever blow through the world of IT, and wonder whether our trusty boat The Good Ship Ffenics is up to the job of navigating these windy seas. I'd like to think that our two days this week gave a good confidence boost to attendees, not just because of my incredible words of wisdom and demo apps, but to engage with the others there, and see their apps rocking in action. Hey, even my brother, whose a C++/PhP type of developer, was impressed with Ffenics!
Anyway, enough of this for the moment. I hope to get to grips with extracting some usable video footage from the small pile of DVDs in front of me, if I can ever get over the embarrassment of watching myself gesticulating like a windmill on acid!
Thanks to Graham Smith at PLM Consulting in the USA, who gave a Webex/Skype presentation to the group on styling and code reuse, and to delegate John Baldwin, who agreed to kick off a debate about some of the difficulties he's had in moving from DOS to Ffenics. To the other delegates for making the journey over to Bristol ... and to my brother Neill, who videoed and gopher’ed for me.
Friday 13 November 2009
Naming Conventions
Ffenics consultants will nag on about not using reserved words, adopting single word naming conventions and so on, but the truth is that DataEase and Ffenics are so resillient to these mistakes that 95% of the time you can probably get away with them.
We'll still laugh at you, of course, unless it's your round.
But I did just come across an instance where idiosyncratic nomenclature aims its teeth at your derriere: punctuation such as brackets (or parenthesis) confuse attempts to write object scripts.
Every book on computing you'll ever read will tell you to stick to single word names, but if you managed to skip those pages, or are looking after an app created by AN Other, then there is a workaround: use the 'object name' option on the field definition dialog, and change the object name at least to a single word.
Ff uses the field name from the form/table to be the default name for the object on a form or aspect that displays the data. It also uses the same name for summary field objects. You cannot have objects with the same name in the same container, but the corresponding summary object for a regular field object will be created in the form container, not in the record container, so there is no immediate confusion. Still, not a bad idea, if you are likely to do a lot of scripting on a document that has summary variables, to rename them to something easier to spot in the script object list.
We'll still laugh at you, of course, unless it's your round.
But I did just come across an instance where idiosyncratic nomenclature aims its teeth at your derriere: punctuation such as brackets (or parenthesis) confuse attempts to write object scripts.
Every book on computing you'll ever read will tell you to stick to single word names, but if you managed to skip those pages, or are looking after an app created by AN Other, then there is a workaround: use the 'object name' option on the field definition dialog, and change the object name at least to a single word.
Ff uses the field name from the form/table to be the default name for the object on a form or aspect that displays the data. It also uses the same name for summary field objects. You cannot have objects with the same name in the same container, but the corresponding summary object for a regular field object will be created in the form container, not in the record container, so there is no immediate confusion. Still, not a bad idea, if you are likely to do a lot of scripting on a document that has summary variables, to rename them to something easier to spot in the script object list.
Subscribe to:
Posts (Atom)
