To display the most relevant entries to you in priority,
vote for the stories you are interested in
()
and reject those that you are not interested in
()
This being the year of the "credit crunch" Karen and I have decided to take our finances a little
more seriously and break the habit of just spending whatever we have. We've needed to do this for
a while, really, but the "economic downturn" has made the need all the more prescient.
Phase 1 was to go on "spending lockdown" which we did in the last quarter of 2008. It's working
well - not spending money. It's actually quite nice. Soul-cleansing in fact. We now think about
purchases and only buy what we really need rather than just getting whatever we
want.
Phase 2 is to analyse where the money we do spend is actually going. For a while now
we've felt a bit like the amount coming in to the house does not equal the conceived amount going
added to the feeling of remaining "wealth", negative or otherwise. We literally can't work out
where it all goes.
Not that I am that naive. I know all too well that lots of seemingly small amounts soon
add up to a big total. A hundred pounds here, a hundred pound there. It soon adds up to a
thousand. Likewise, the thousands soon add up.
Anyway, what I want to show you is the tool we're going to use to analyse outgoings. You'll be
pleased to hear I chose to record everything in a Notes database! I've set it up so that Karen
has a bookmark on her browser to a webpage where she can easily input her expenditure each night.
Surprisingly, she's "on board" and as keen as I am to make a go of it.
Here's the database we're using to
record where every penny goes. That's just a dummy copy though. You can mess about with it as
much as you like.
For now it's just a simple app that lets us enter the data. To come is the analysis - with pie
charts, monthly drilldowns, etc etc.
Most of you will probably know what I used to build the app as soon as you see it. For the rest
of you it's called Flex and I'll talk more about
it in my next post. if anybody wants a copy of the DB to start recording their own outgoings let
me know (all you need is to plonk it on your own secure server somewhere).
This weekend we stayed in an "aparthotel" for the second time in as many months. Until we booked
the first stay I'd never heard of them. They're city-based apartments for rent by the night, much
like a hotel, with a reception etc. The difference is you get two bedrooms and a
separate living room/kitchen. The kitchen has a cooker, microwave and dishwasher.
If you have to take a family of five away with you (we were at a wedding in Newcastle) then
having separate rooms makes it bearable, whereas doing the same in a conventional hotel is
nothing short of a nightmare. From now on I don't think I'll stay anywhere else with the kids. We
got the double room apartment on Friday for £120, so not that much more than a basic room
in a city centre hotel.
Anyway, I mention it for two reasons. First to hopefully enlighten you guys. I guess you all knew
about them, but if not, they're worth looking in to next time you're away with family or friends.
The other reason is that I just had to pass on an example of terrible UI design from the website
of the one we stayed in on Friday night, Kensington House.
Looking for a map I looked at their contact page and saw this. See if you can see anything odd:
It took me a while to work out that the weird "garbage" in the contact form was in fact a
CAPTCHA. Can you see it? If you pull your head back and squint you can just about make out that
it says 8+9=. The white box to the right of it must be an input field.
It sticks out like a saw thumb. No less so because the site itself and the place it represents is
going for the "swanky" look. This is what happens when you let a geek design part of the UI. I
can imagine he feels fairly smug at having written such a clever spam blocker, but what about the
poor user?!
I've said before and I'll say again - in my opinion spam is not the user's problem and so they
should not be the one made to pay. That's why all spam blocking measures on this site are
back-end. Not making the user pay is all the more important if the contact form is on a company
website. If you run a company surely you want to make it as easy as possible for potential
customers to make contact. Why make them jump through hoops!?
The other reason for this post is because it's Monday morning after the break and I need to ease
myself back in to office work nice and slow.
The amount of blogging and the amount of feedback is pretty much the same as 2007, which is
reassuring. I'd be worried if the yearly decrease in activity continued. It's hard to keep it
flowing what with work commitments and two kids under the age of two.
The obvious difference this year is that I haven't written an "article". I know most of you refer
to anything on here as an article, but, to me, they're the full-length posts that don't appear as
a part of the blog. What I've found is that a) I don't have time to write the full-length posts
any more and b) I can get most of what I want to say across via the blog posts. This site has
always evolved to my situation and I can see articles being used less and less.
Noteworthy Happenings / Content
Having just looked through all 115 blog entries from the year, here's what stands out for me:
I won an award! Best
Lotus Blogger 2007. Apparently.
Embedded login forms. I
thought this was obvious but a few of you seemed thankful.
DEXT made available for
download. This one download contains all the usefulness mentioned above.
Each year I always think what on earth am I going to write about in the next year. I often think
I'll run out of tips/tricks at some point. Things always come up though, as this year has shown.
As for next year, who knows what will come up!?
Chances are that 2009 will see me talk about XPages, as I need to get up to speed on that and I'm
sure you're dying to know my impressions. For the immediate future though you should expect a lot
of talk about RIAs and, in particular, Adobe Flex!
Visitors
Never mind content. How popular was the site over the last year. Well, according to Google
Analytics, 309,247 Absolute Unique Visitors amounted to 1,134,843 Page Views. I can't compare
this to the previous year as I didn't start recording until March 2007. More than a million page
views sounds alright to me though. Anybody know how much advertising revenue I'm missing out on?
Onwards...
So, here's to another year of techy geekness and to your continued input. Just remember, this
site wouldn't continue if you weren't reading.
Next year will see this site's 10th birthday! Never thought that would happen.
It's Monday morning and I've come to sit in the office as normal. It doesn't feel normal
though. What is it about the weeks that contain Christmas and New Year which make all the days in
them feel like the weekend!?
Because of this weekend-factor I'm finding it hard to concentrate. It feels a bit like I'm the
only one here. Am I? Hello!?
Sorry, I'm waffling. All I wanted to do is wish a Merry Christmas to all (of you that
celebrate/have time off).
I'll probably be back here with something to say (codestore's year in review perhaps) before, but
if not, I'll see you all in 2009...
By coincidence, the day after I spoke about the confusion relative URLs can cause
I was asked to help out on a project where relative URLs of a different kind were causing yet
more confusion. This time it was URLs inside a CSS file.
Note that the file is inside a "subfolder" of the database called "css". Inside this stylesheet
we add a rule to place a background image in the header DIV like so:
Assuming the CSS file is located at /db.nsf/css/default.css you'd probably expect the image to
load if it were located at /database.nsf/images/header_background.gif. But wait. It won't! Why?
Because URLs inside CSS files are relative to the CSS file itself -- not the database and
definitely not any BASE href in the web page, which has no effect on the relativeness of the URLs
in the CSS files.
Come again!? Well, the stylesheet above lives inside a folder called "css". So, any URL it tries
to load is relative to that folder. If you used a HTTP sniffer you'd see the browser try and load
the background image from /db.nsf/css/images/header_background.gif.
The browser then knows to step back out of the CSS folder and then in to the images folder, both
of which are at the same level in the database's faux-folder structure.
Similarly, if the stylesheet were two subfolders deep and in /db.nsf/css/screen/default.css then
the rule would become:
It seems like I've explained a solution to what must be a common problem enough times over the
past couple of months to warrant answering it here (much easier to point to a link than to
explain it over and over).
The Problem
Imagine you place an image on a Form using Passthru HTML. Something like this:
<img src="logo.jpg">
The problem is that when you create a new document using the form the image appears, but when you
open the saved document in read mode it doesn't. It doesn't have to be an image. It can be any
resource you load by URL, such as a CSS or JavaScript file, in which case the consequence would
be much more obvious.
The Cause
This behaviour is down to the fact that the resource is being referenced as a relative
URL. When the document is first being created the actual URL would be something like:
http://server.com/apps/help.nsf/ticket?OpenForm
So the browser will try and fetch the image from
http://server.com/apps/help.nsf/logo.jpg
This is the correct location and so the image loads. When the document is saved and re-opened the
actual URL becomes something like:
However, if you're loading lots of images and/or resources it can become a drain on resources to
compute the database path each time. Instead I'd recommend using the technique I use in all
databases I create -- BASE href.
I know this must seem a bit nooby to most of you, but you'd be surprised how often I see it come
up as a problem.
Friday gone was Felix's 2nd birthday. In keeping with last year's post here's
an updated montage of photos taken exactly a year apart. I'm starting to wish we'd found a better
position for the shot, as it's proves harder each year to keep him still long enough. It's going
to be interesting to see whether I can get him to agree to the photo each year throughout his
adolesensce.
Although the difference between 1 and 2 isn't as obvious as between 0 and 1 I think the obvious
change is from baby in to boy. Oh, and he's got teeth now too. Having a boy makes you realise
it's no coincidence it's boisterous and not girlstrous.
For his birthday I took the day off work and we all (Granny and Granddad included) caught the
choo choo to (Old) York.
Felix is obsessed with anything choo choo. Sitting on the table in one and watching everything
rush by seemed to make him as happy as Larry. Little did he know that when we got there we'd be
going to the National Railway Museum.
In the shot above he's on the class of (if not the) train that his Great Great (Great?)
Grandad, Solomon Howlett, was the fireman on at the turn of the last century.
Needless to say he loved it.
It's always amazed me that he's so in to trains. How can he have any concept of what they are?
Apart from a trip on the Eurostar to Paris, which I don't think he'll remember, he had never
actually been on one before Friday or seen that many in real life. Somehow the Thomas franchise must have a real grip over young boys.
So, a day without Notes. In
fact I spent close to a week working on a PHP site, but launched Notes for various reasons on the
other days.
Although I said I didn't miss Notes, there were certain aspects of it that I did. For one there
was the concept of a Scheduled Agent.
The accepted method of having a PHP-based task run on a schedule seems to be that you use a
"cron" job. You can read all about how
you do this here. Basically you add a line like this to your cron file:
What this does is tell the server that, at 2:30am each day it should load the "curl" program and
tells it to load the webpage found at the URL specified. The user name/password are passed as
it's a good idea, I thought, to lock access to this file.
Immediately it seems odd. Rather than PHP being able to manage scheduled tasks you have to rely
on the OS to run a program for you. What struck me about this was that it relies on internet
access. I guess it's ok to assume a web server is always on and has access to the internet 24/7,
but what if, for some reason, at 2:30am one night it can't see site.com? The "agent" fails to
run!
You could of course just have curl load http://localhost/nightly.php, assuming Apache is set to
respond to that host name. However, any reference in your script to the "SERVER_NAME" CGI
variable is then lost and generated emails have broken links unless you're willing to "hard code"
the domain name.
Another aspect to this is the lack of self-containment of the code. Whereas I can deliver a
customer one single NSF (in most cases) and trust them to get it up and running, with PHP they'd
have to pass it on to an internal techy with a little more know-how and access to the shell or
knowledge of SSH.
In the case of the system I developer for my friend new client I am hosting the system for them
and so have the rights to set up cron jobs etc. If this weren't the case I think I'd miss the
arrangement I have currently with my Notes-based clients whereby my /ROCKALL id is
cross-certified on their systems and I can pretty much make instant updates to most sites I've
developed.
There were other aspects of Notes that would have made life simpler for me, but not having simple
way to run code each night seemed the most obvious case in which Notes comes out on top.
The other week, like usual, I spent a whole day working in my office. Nothing unusual in that, I
know. What made it different was that, for the first time in my career in IT, I didn't launch the
Notes client once!
Why? Because I used Aptana Studio instead. Not because I was working with Domino via the Aptana plugin, which
in theory I could do, but because I was building a LAMP-based site. Shock, horror.
Me messing with PHP is nothing new, although it's been a while since I did. What was different
this time was that I was being paid to do so. A good friend of mine (one of the two best
men at my wedding) who works for a large international company needed a web-based system building
and didn't care what technology it was based on. He needed it doing quickly and wanted to avoid
dealing with any of the larger IT outfits he's used to dealing with.
Learning something new is almost impossible when you have small kids and a full-time job. That's
why I relished the chance of using a SQL-based approach and a more "traditional" web language
like PHP. Although I must point out that PHP was a good fit for the requirements. I
didn't just make it fit because I wanted it to. I'd never do that. Notes could have done
the job but there was nothing that made it the right tool though.
Using PHP and SQL was fun and a breath of fresh air. Having a relational database to interrogate
made giving the customer what they wanted soooooo much easier.
Sign of things to come? I doubt it. Notes is where the money is for me at the moment and so
that's where I'll be staying. If Notes does (as so many people believe it will) start to die out
at some point I hope to carve myself a career in either support of legacy Notes apps and/or
migration to Sharepoint or whatever is the flavour of the day at the time.
For now it's back to having Notes running all day every day. Did I miss it for the day it didn't
launch? What do you think!?
For once I can deliver a promise to you. The Sandbox now has a new version
of DEXT for downloading.
As a recap and for those who have no idea what I'm talking about, here's what DEXT is. It's all
the (useful) demos I've made available as individual NSFs for download over the years. There were
so many it was getting a mess. From now on I will add new demos to DEXT and release a new copy
each time I do or as and when I make any improvements to the existing app.
And it does need improvements. So far it is just most of the demos quickly ported over from their
own DBs. The whole thing need tying together a little better and I don't doubt there are bugs
that you'll uncover.
Hopefully, having all the tips, tricks and working demos in one place will be of benefit for all
us. Myself included. I often find myself in the middle of a new project and needing to solve a
problem. Thinking "I did this somewhere before", I go off to find out where and trying to track
down the demo NSF in question. It can take ages and sometimes I even give up looking.
Now that it's all in one place I don't have to look far for the code I know I've written
before. Nor do you.
Another plus to the all-in-one solution is that I can add little tricks and techniques to it
which wouldn't normally warrant their own demo database. DEXT is already much more than just the
demos you'll see linked to from the homepage. It's also littered with other useful concepts -
such as the WebSession class and
library-based daily agents that update date-based views etc etc.
Anyway, let me know what you think about it. Good or bad. I'll be adding a "forum" to it at some
point. In the mean time post any comments, bug reports etc here. Remember, the level of feedback
I receive is my only indication of how much interest there is in it. I don't want to waste my
precious spare time on something you don't want!
One of the things holding me back from making DEXT available (apart form lack of time) was knowing
the best way to deploy it. Because of the mix of JavaScript libraries in use (Prototype, DOJO,
Mootools and jQuery) I had put all the files in a DB called toolkits.nsf which I bundled in to the download.
The trouble is that it made the additional database ~120MB and the Zipped download 25MB. Not that
that's much by today's standards, but it made uploading new releases a bit of a pain for me.
To get round this I've opted to load all the various JavaScript libraries from Google's Ajax API "CDN". If you look again at the
source code for a demo form on the app you'll see the libraries loaded like so:
Note the lack of "http:" from the URL. This allows you to switch to and from using SSL without
worrying about "mixed content".
You can read mode about the benefits of using a third-party CDN in this
write-up.
While I have my reservations about doing it this way I just think it makes the most sense. It's
just a shame there's no hosted version of Ext. Apparently there
never will be as Google don't want to host anything with less than a completely open licence.
My "codestore time" for today has been spent moving to this new way of doing things, so you'll
have to wait another day for the download. I still need to work out how to provide it without the
1,000s of demo documents currently in it but with enough to make the demos work.
If you look at the DEXT homepage (there's a perma-link to it on the
tabs above!) and scroll to about half way down you should see something like the image to the
right.
This is the LotusScript alternative to the view-based method of
colour-coding document, based on their age, which I talked about last week.
The view-based method has numerous shortcomings, which this LotusScript version avoids. Not only
that but the LS version is accurate to the second, whereas the view version is only accurate to
the day!
The demo I cooked up for this version works the other way round to last week's demo. Now we're
making new (hence "hot") documents red and older ones white.
The trouble with the whole approach is that there's no one-size-fits-all solution I can code. How
you use the concept depends entirely on the scenario you'll use it in.
For now I'll leave you with the demo as I don't have time to discuss the ported code. You'll see
the code if you download the DEXT app after I've made a new version available tomorrow.
One thing I will say about the code is that it produces CSS values such as rgb(255,977,977) which
is of course wrong, but I can't see an equivalent of @Min() in LotusScript, so I've left it as
is. The browsers don't seem to mind accepting the value of white. It's Daz white in fact (a joke
for the Brits there!).
I'll always be indebted to you guys for your help last year in getting my data back from an old
laptop when it failed.
Knowing how it feels to think you've lost cherished digital memories of your children I'm
currently trying to recover files from a friend's hard drive. It's an external USB-type disk.
When I said I'd try for them I kind of promised it would be recoverable. I assumed it would be a
data problem such as a bad sector and I'd easily recover the data using BartPE, which saved my
bacon last year.
As soon as I turned the drive on I realised it was worse than a data problem. Things just didn't
sound right at all.
In trying to get to the bottom of things I removed the disk form its housing and plugged it in to
an old server I've got knocking about. Here's what it sounds like during boot-up:
Notice the screen at the end of the video. Looking at the screen it appears that the Secondary
Master disk is recognised and named in the list of drives but then comes the message:
"Secondary master hard disk fail"
So far I've not managed to get past this point or tried booting from BartPE. For now I wanted
your opinion on the outlook for this drive. Is it good? I really want to help my friend regain
"most of the videos" of his 3 year old son.
I've never known Value Added Tax (VAT) here in the UK to be anything other than 17.5%. I always
thought it was set in stone, never to change. Having just Googled it I see it changed from 15% to
17.5% in 1991, but has remained the same for the last 17 years.
Next month it is going to change back to 15% in an attempt to stimulate the economy (yeah right,
like "Oooh, now that iPod is ?ú2 cheaper I think I will buy it after all").
When I saw this on the news last
night the first thing that came to mind is how many places I've hard-coded the VAT rate as 17.5%
and how I'm going to have to go about soft-coding it before the cut takes place.
I guess it just goes to show it is never ok to hard code something that is so obviously a
variable. No matter how often it might change, chances are some day it will.
Prompted by Andy at Notes411.com I decided to revisit the
colour-coded view trick and
simplify it a little by using a column with a Programmatic Name. The formula for the column which
sets the row's background-colour is now:
$1? This is the "programmatic name" of the first column in the view. This column is hidden,
sorted descending and has a programmatic name of "$1". It's formula is:
The logic for working out the document's age is now in it's own column. So what we've done is
taken the presentational code out of the nightly agent and put it back in a column of its own.
This has the added benefit of simplifying the nightly agent, which is now:
Still not as simple as it could be though. What I'd have liked to have done is have a hidden
column which is simply today's date. All the nightly code would need to do is update the date.
All the "logic" would stay in the view itself.
The trouble is that, unless I'm sorely mistaken (and I hope I am), referring to columns by their
programmatic name is a little buggy. If what you put in the column is anything like a date then
you just won't be able to refer to it programmatically from another column. All very odd
behaviour, so I gave up trying in the end.
The one big flaw in all this (apart from the need for a nightly agent!) is that it's only ever
going to be accurate to the day. If you have a view where you want to differentiate between a
document that is 12 hours old one that is 12 minutes old then it won't work.
When you want to get more accurate that days then you'll need to use LotusScript in the form of a
WebQueryOpen agent. More on this next time...
Let's say you have a view of support tickets that are awaiting processing. The older the ticket
gets the more important it is that somebody does something about it.
How do we convey this to the user though? Well, there's
various methods, but yesterday I came up with a new way, which I think you'll like. Imagine each
row of the view is a varying shade of red, based on the document's age. The older the document
the redder the row.
You can see an example of this in the screen-grab to the right and in this DEXT demo page. On the demo page you'll need to
scroll down to see it in effect.
How Does It Work?
In terms of CSS this works by virtue of the fact you specify a colour as three numeric values
representing the mix of red, green and blue. You might be used to seeing something like this:
<tr style="background-color:#ff0000;"><td>I should be bathed in
red</td></tr>
But did you know you can also do it like this (in all browsers!):
<tr style="background-color:rgb(255,0,0);"><td>I should be bathed in red
too</td></tr>
An RGB value of 255,0,0 is red, whereas 255,255,255 is white. You can specify any shade of pink
by passing 255 for the Red value and any number for
Green and Blue, as long as they're both the same. See this
table as an example:
rgb(255,0,0) Red rgb(255,60,60) ↑ rgb(255,127,127) Pink rgb(255,200,200) ↓
rgb(255,255,255) White
The smaller the number you specify for Green and Blue the redder the colour. Can you see where
this is going?
How This Works In Domino
What we need to do in our view is have each row calculate a number between 0 and 255. Brand new
documents need to come out of the formula with a value of 255, whereas really old documents need
to compute to 0.
The view itself needs to be treated as HTML and one of the columns would have a formula like
this:
As you can see (hopefully) the G and B values of the row colour are worked out as a "percentage"
value of 255, based on how many days have passed since it was created.
The number you multiply 255 by should be somewhere between 0 and 1. If it's 0 then you get red.
if it's 1 then you get white. So it might seem the opposite way round to what you'd expect.
Note that I've introduced a "factor" in to the formula above. What I found was that you need to
spread the shading of your rows out over the range of dates you expect to encounter. The factor
needs to be about the same order of magnitude as the top end date expected. The best way to work
this out is to play with it in your real world scenario.
Using Dates In View Columns
By now you might have noticed the view uses today's date in a column formula. Although the way
I've done doesn't invoke the problems with indexing that using @Today does you might be wondering
how it gets updated, as the date appears hard-coded.
Remember I've talked before about how you can use scheduled agents to
update view selection formula. Well, you can do the same thing with column formulas too!
Imagine this code running every night at shortly past midnight:
Set TodayDT = New NotesDateTime(Now) tmp =
|days_passed:=1+([+TodayDT.DateOnly+|]-@Date(@Created))/(3600*24); factor:=20;
val:=@Min(@Round((1/(days_passed/factor))*255); 255); "<tr
style="background-color:rgb(255,"+@Text(val)+","+@Text(val)+");">"| Set folder =
database.GetView("TicketsByDate") folder.Columns(1).Formula = tmp Call folder.Refresh
It's as easy as that. There's little wonder I'm so fond of Notes.
Summary
Used in the right place this technique can add much usefulness to the user and help them
immediately recognise documents in need of attention. How you use it is down to you (it doesn't
have to be a support ticket system!). It doesn't have to be shades of red either. You can use
shades of any colour, as long as one of the RGB values always stays the same. Brilliant.
Next blog entry will discuss the use of this technique with LotusScript.
As developers it's easy to email users of our systems. How do we know if the email ever reached
the user though? And (more importantly in some cases) can you ever prove it got there?!
Most systems I've worked on have sent email notifications out. Until recently I've never really
thought much about what happens after the .send() method has been invoked. Hey, I've sent the
email. Now it's in the hands of the internet gods. Whether the user ever actually reads it or
not, I just don't know.
One recent scenario involved sending a Booking Confirmation email to users of an online booking
application. The first line of the email is in big bold letters and reads:
Please print this email out and bring it with you on the day as proof of
booking.
The trouble is that some users didn't print it and didn't bring it. In fact they claim they never
even received it.
This is the point where email fails as an effective form of communication. It just can't be
relied on. This is especially true nowadays thanks to our friends the spammers. Spam filters are
having to get more and more aggressive in order to be effective. In doing so there are bound to
be false positives. As I understand it system-generated emails themselves are more likely to fall
prey of spam filters, especially when faking from headers. It's a wonder any of the emails we
send get there at all.
So, my question to you is, if you have an important message that your user must
see, how do you make sure it gets to them?
Alternatives to the booking confirmation email which I've discussed with my customer are:
Display the content of the email to the user on the last page of the booking. It's at this
point they should print the page. The email is still sent, just not relied on as the
sole means of communication.
Have the last page of the booking warn the user to expect the email. It could tell them to
make sure they can receive emails from bookings@acme.com and to check their spam filters if it's
not there in the next ten minutes.
I even suggested including a "tracking image" in the HTML email which loaded from
www.site.com/bookings.nsf/getImage?OpenAgent&foruser=user@company.com. When the user opened
the email the site logged it as read. The trouble is the spammers invented this trick and so most
email applications now won't load images in emails and, although this might prove a user did see
the email, it doesn't prove they didn't.
It all leaves me feeling sad that the spammers have all but destroyed a wonderfully simple means
of world-wide communication. Maybe that's the problem. SMTP is too simple a protocol.
Do you rely on email? If not, what do you do to get round its shortcomings?
Last week I finished a blog about learning JavaScript by saying "more
on that next week". I don't know why I make promises like that. I should just say nothing and
surprise you with the "more" when I get round to it.
What happened as a result of my (empty) promise was that I felt pressure (especially after a
couple of you said you were looking forward to it) to write something concise and meaningful at
some point last week. What actually happened was I never felt the inspiration needed in order to
do so. Hence the solitary blog entry last week.
The real reason is that I just haven't had the time to write such an in-depth blog. A typical
blog entry can take an hour or so to write. Something along the lines of what I was planning
would take at least twice as long as that, if not longer still. I just don't have that much time
spare right now.
You'll have to make do with more seemingly-random entries until I get more time.
In the mean time here's a copy of the
file I have on my desktop at the moment. It's a HTML file with some JavaScript in it (see
source). What I'm doing is going back to basics. Instead of reading I'm just doing. I've started
by creating objects in JavaScript and seeing what happens when I mess around with them and add
prototype functions etc. In testing what I think is true I'll hopefully learn what actually is.
Back to normal from now on though. Hope I haven't disappointed any of you. I'll try and talk
about JavaScript at some point. Just don't expect anything amazing!
Last month I talked about how being Mr Computers can sometimes pay
dividends. This weekend was another example of that. Friends of ours own a group of holiday
cottages in the Peak District called Hurdlow Grange. For
the design, hosting and upkeep of that site I get to stay there free of charge. Since designing
that site they've bought the local pub, The Royal Oak,
for which I also host the site (a modified copy of the other). In return I have been given every
man's dream - a free tab in the pub.
This weekend a group of us had a get together, based around the pub. We (the Howletts) stayed in
the cottages and ate/drank in the pub. All free of charge. Although I'm paying the price in other
ways this morning. I'm getting too old for a whole weekend in the pub and probabl
)
and reject those that you are not interested in
(
)
If you look at the 
How do we convey this to the user though? Well, there's
various methods, but yesterday I came up with a new way, which I think you'll like. Imagine each
row of the view is a varying shade of red, based on the document's age. The older the document
the redder the row.