Next month: June 1996
Shifted the second mail request on Saturday evening to 8.05pm (I will keeping moving that back a minute a week until it comes back with a different e-mail compared to the 8.00pm request). I asked Camelot for the Lucky Dip figures and they told me that they have stopped giving out such figures !! I was stunned by this and couldn't understand why they quite happily gave out exact Lucky Dip figures for some 2 months and now refuse to do so. I think it's time to turn up the heat on Camelot w.r.t. this issue - surely the Lucky Dip figures aren't "sensitive" in any way ?
Managed to get all the usual post-draw sales figures (including some older unclaimed prize figures) except for the Lucky Dip figure for this week, which will hopefully be available tomorrow. I might try to suggest that Camelot fax me weekly at work with these mid-week figures from now on to stop me hassling people on the phone line ! Now if only they had Internet e-mail, sigh...
I still allow people to download the entire lot in one file though because it does contain summary stats at the bottom and also bolds the most frequent numbers. I don't bold numbers for individual yearly pages because a) it would mean a lot of extra code just for these pages and b) it might be confusing as to whether the bolding refers to that year's numbers or to all the sets since draw #1. Naturally enough, InterLotto's equivalent section was also revamped in a similar manner.
To save me having to scan down the frequency ordered version manually for the longest gap between number appearances, I've added 3 new pages to the numerical analysis section, each of which lists number appearances in gap order (for 6 balls, 7 balls and the bonus ball). In a similar move towards less manual hacking, I can now automatically generate the newsflash with the count of how many of each major type of page (UK, links and InterLotto) are available. I usually only bring that newsflash forward to the home page when there's been a lull in newsflash updates.
I spent some time re-organising the C source code files to optimise compilation speeds and also binary sizes. For example, the code to generate the Lucky Dip front-end page had ended up in the lottery CGI binary as well as the page generator binary until I fixed this inefficiency. Also, I split one of the source files into two separate ones, but there's still 3 other source files in excess of 30K that need splitting to speed up compilation.
It's been proving difficult to track down an intermittent problem with the "bhs" system that's been plaguing me for months. It keeps chowning files to the wrong user, although I can't see any obvious reason why (the fact it's intermittent is even more frustrating). As a temporary measure, any files owned by the wrong user in the lottery WWW tree are now deleted and re-generated by bhs. This should stop the problem from appearing to the outside world (it manifests itself by replacing the HTML files with the .bhs versions, so you get macroised pages that don't render properly).
Checking out my rival 6 sites, none of them had the results on their pages by 8.34pm, although Might BU ("the only real-time live lottery result") had last week's in the body of the page with a "-" in the ALT tag for the ball graphics, so I can't tell what graphics were actually displayed. Chris Prickett's site unceremoniously displayed "PAGE BUSY...This page is currently being updated on Server ourworld.compuserve.com" (I do 5 minute checks and there were no results between 8.05pm and 8.30pm). So, it looks like I beat everyone to page updates without even being there !
Over recent months, I've noticed that the lottery links section ends up with zero-length index pages all too frequently (pops up "Document contains no data" dialogue in Netscape), so I've added extra file size checks to the code and also flagged any failed external lottery link as an "error". If a complete pass through the generation code flags one or more errors, I pass through the entire generation code again (and for a final third time if the second pass fails as well). This should also conveniently fix any one-time failures to connect to a site when verifying links on a Sunday evening.
Wednesday is a "fun" day to phone Camelot and pester them for "delayed" figures (scratchcards, Lucky Dip, unclaimed prizes and Good Causes). I only succeeded in getting sensible answers for the first two because I was told the grand total for the unclaimed prizes to date and asked to manually subtract last week's grand total to get the latest weekly figure - ugh ! Good Causes had a different problem - both the weekly figure and the grand total were quoted to the nearest pound to me, which is wrong of course because they are the only figures Camelot has to the nearest penny.
I was mightily impressed by the fairly new official US state lottery sites for Florida and particularly Minnesota. OK, I admit I'm biased about the latter because I visited a couple of Twin Cities e-mail contacts there in person for a holiday several years back. It was funny at US Customs because was I asked how I knew the people I was visiting and I said "by electronic mail". The US Customs woman didn't bat an eyelid, which impressed me no end back in 1991. If I'd have said that to a UK Customs person 5 years ago, they'd have locked me up as a spy or looked at me strangely and asked me what e-mail was. Ah, those were the days when you truly had to know what you were doing to be on the Internet - I've had an e-mail address for some 12 years now !
One of my rival UK lottery sites, Might BU, displays confusing info just after the draw on Saturday if you visit it with lynx (a text-only WWW browser). The ALT tag for the ball graphics seems to have the previous week's results, just above the text version of the newest result. I've changed the config file for the WWW grabber to compensate for this, although Might BU are far too inconsistent from week to week w.r.t. their post-draw home page updates.
An old problem with the redundant displaying of "Next Lottery (#whatever)" on the home page when there's a link to that draw higher up the page (this happens between Saturday and Monday morning) re-surfaced and I've now dealt with it. Adjusted second mail request to 8.04pm, since the first two requests are still returning the same info (i.e. sweet F.A. a lot of the time because they are too "quick").
Changed the white lie about the "Last connected" info in the lottery links section - it now says "This week" on most days, except on Sunday evening and Monday when it does a full check and can legitimately say "Today". Added a new "commercial lottery clubs/syndicates" category to the lottery links section. Upgraded the "bhs' system to include spell checking (using "ispell -l", because "spell -b" is pretty awful) with an additional global spelling dictionary. It picked up a couple of errors in the lottery pages that I'd missed with my usual manual spell check.
I decided to type in the expired prize figures using the assumption of a 26-week lag and these are now on the appropriate individual lottery pages. It also spurred me on to create two new summary pages - one for Good Causes figures and the other for the aforementioned unclaimed prizes. Just before I went home, Camelot rang and filled in the remaining few unclaimed prizes and Good Causes figures, so I now have a full set of both for the first time.
I also added a %age column to all such analysis tables (with the exception of the combined sales page because that isn't a percentage of anything of course) detailing the percentage of ticket or combined sales that the weekly figures comprise of. Each analysis table is subtly different from the next (different widths, percentage accuracy etc.), which took me quite a long time to perfect to my liking.
I reduced the frequency point at which I expand the pairs and triples lists to stop the page from growing too large, but I got an e-mail complaint about this, so I may move the expansion point back again for some pages. I ran these pages through the usual battery of tests, including spell checking, weblint, gcc, lint and internal link checking. Only one spelling mistake, a minor lint warning and a missing </UL> to deal with, so the pages are in a pretty good state at the moment.
Anyway, the upshot is that I don't want to go wholly live with these figures since they are in a bit of a mess. I've put the Good causes figure on the individual lottery pages, but that's all I intend to do until I've got the figures for draws #1 to #20 as well.
I already had a #define for the day of the week when the results would be uploaded (Monday normally, Tuesday if the Monday's a holiday), so it didn't take much to add a boolean holiday definition and then use this to not only set the aforementioned day, but also to support conditional cron job files.
To achieve this, I simply changed the crontab file to be more like a C source file (i.e. using C-style comments and #if...#else...#endif), #include'd my usual bhs macros (including that holiday definition) and, yes, sent the crontab file through bhs (a wrapper around cpp in case you'd forgotten) before passing it onto the crontab command. All of this now means I have a conditional crontab file, which is not normally possible in UNIX !
Personally, I think the standard UNIX crontab file should follow cpp conventions, allowing the crontab command to pass it through cpp before installing the file. Anyway, the benefit of all this is that I now only have to change one line in a header file and both the HTML pages and the cron jobs adjust appropriately to avoid mentioning or running next Monday.
Previous month: April 1996