AppEngine filter command – fail

I’ve been using AppEngine, almost entirely using the GQL language to return my objects.  This is a bit of a curse, and now I’m playing with gaegene’s pagination lib, I’m having to look at why I did this.

I did things this way because I couldn’t get filter() to work.  I didn’t want to waste time finding out why, so I simply avoided it.  If you had to do the why on every command in GAE, you’d never complete anything.

Anyway, I’ve now found out why:

“The name and the operator must be separated by a space, as in: age >
GAE Docs

So my filter command:

messages.all.filter(‘board=’, board)

did not work, and I should have done this:

messages.all.filter(‘board =’, board)


Campaign to Legalize Thankyous

Thankyou isn’t a word.

I was taught this in English class, and it’s official.  It’s not in dictionaries, and Google doesn’t recognise it.

Correctly, it should be two words.  “Thank” and “you”.

But hold your horses there.  As I understand it, one of the key benefits of the English language is its flexibility.  The first Dictionary was, I believe, German, and it laid down exactly how all the words of the language should be.  The English huffed and puffed about this, and openly mocked the idea.  They then sat down in a library and formed the English language by reviewing every English word ever written.  They set out to be descriptive rather than prescriptive.

And our dictionary evolved.  The scholars in Oxford smugly release a new set of words every year, which they promise we’ll all be using a year from now.  Now they didn’t invent these words.  They acknowledged their use somewhere, and described them.

Ok, so I accept that another idea of a dictionary is to provide a single spelling for each word.  In a language with few rules, none of which are not broken, a defining way of spelling helps us all be understood.

But thankyou is a word.  It has become a word through common usage.  It has a specific meaning and use.
It has 12,500,000 matches on Google.

Let us not reject it.  Let us accept it.

Please sign my petition here:


Falling into a Black Hole

You could fall into a black hole, but I’d never see you get there.

Odd, eh?

Reason being, Einstein’s Equivalence Principle – which forms part of his General Theory of Relativity.  This states that an accelerating frame of reference is indistinguishable from a frame under the influence of gravity.

What does that mean?  It means that the force holding you in your seat right now would feel exactly the same as you’d feel if you were sitting in a rocket in space, but accelerating at 1g.

Pretty obvious, pretty boring so far.  However, we also know that Moving Clocks Run Slowly.  If you’re moving through space, you move through less time than someone outside of your frame of reference.

And that gets interesting.  One of the consequences is that a photon (a “ray” of light) does not pass through time at all.  It moves so fast that it never ages.

If you wave your arm, then your hand is fractionally younger than your elbow.  And yet they’re still attached.

Equally astonishing is that a clock on a high tower will run faster than a clock at the bottom of a tower.  I would have thought this is because it is simply moving faster (since it’s on a further radius from the earth).  But actually, it’s because the bottom of the clock is under the influence of gravity, and due to the Equivalence Principle, that clock is accelerating.

Ok, so this is exciting.  Because that means us earth-dwellers are moving through time faster than those in space. (Spacemen actually age less quickly, but this is because they orbit at 17,000mph). (If our clocks are running slowly, then we’re passing through time faster – think about it over a beer).

So if gravity is cumulative enough to hold the galaxy together, then what on earth is the time curve like for the disc?  The galaxy must spin in a very funny way, if the centre of the galaxy is passing through time at a faster rate than the outside.  Actually, galactic discs really do have very odd spin ratios, attributed to dark matter.  How fast is time passing out in Extra-Galactic Space?  Does it pass at all?

Or, let’s face it, at the time of the Big Bang?  Everything was much closer together back then, gravity must’ve been a massive force, and though other short-range forces would dominate, they wouldn’t have gravity’s influence over time.  Perhaps that question isn’t relevant, because everything was uniformly dense.  But you can imagine this might drive “inflation”, where the early universe did some things in strange amounts of time.

Now, back to the Black Holes.

A Black Hole is sufficiently dense that nothing (except imaginary particles like gravitons) can escape.  Not even light.  Something that dense does really weird things to time.

According to my physics books here, if you fell into a black hole, you wouldn’t notice anything particular peculiar.  Except for the whole crushing-to-death thing.

To me watching, it would take an infinite amount of time for you to fall in.

So actually, you would watch the Universe end around you, probably in a very Douglas Adams style.

Now that’s a funny concept.

And here’s the question:  assuming this is so, how did Black Holes ever grow?  Presumably all the holes we can see are primordial, because it would have taken longer than our mere 13.7 billion years to see anything fall in?

Physics: gotta love it.

Agile will not save your project

Agile does not mean faster

If Agile meant faster, we would’ve called it Rapid.

The aim is to get a better result.

Obviously, getting a better result avoids the need for costly revising later.  That will save time.

You can’t switch to Agile because you’re behind

An Agile project needs regular input from key stakeholders on a project.  If you’re not getting that already, something is already wrong.

By going Agile, make sure you’re switching cost models to a time-based approach.  Otherwise you’re simply handing your client infinite inputs and revisions for no cost.

An Agile project is basically the repeated improvement of a prototype.  If you haven’t got a prototype ready, starting Agile might mean you have to step back in your project plan.

If you’ve been through a whole bunch of project definitions and deadlines which you have to stick to, then you have already missed the boat.

A meeting with the client every week is not Agile

I have seen people suggest that we “go Agile”, by having a weekly meeting.  This is not Agile.  This is a weekly meeting.  If you don’t understand a word, don’t use it.

If you can’t say no to your client already (which surely is a blog post in itself), then giving them extra input will increase your workload.

If your client is interfering rather than assisting, then maybe less input is what you need.  Maybe full definitions are needed to avoid scope creep.

Agile is not always better

“How much will it cost?” is the question ever-present in your client’s mind.  Unless you have built up the trust by delivering on projects and timelines already, or have wowed them with case studies on the concept, then your client is right to be suspicious.  What guarantee have they got that your Agile project will complete in budget?

A waterfall process can be slower because you have to continually define what you’re building.  But this definition should not be wasted.  Know the audience for your documents, and make sure they’re read.  Don’t complete documents just for process checklists.  Make them useful.  Make them short.

Then introduce Agile for your next project.  Make sure you know your stuff on this.  Go Agile early.  Make sure you can deliver to cost, and make sure you know who’s paying if you don’t.  A clue:  it’s your client. (extra flexibility costs money)

Agile will not save your life.  But it might just deliver your client a better result.

Use it wisely.

Fixed-height web page layouts are always wrong

I can understand that when you’re designing a magazine page, a poster, an advert, a banner, or hell, even a letter to your granny, then the first thing you need to know is the size of the material you’re working with.

The challenge of the web is that your users’ monitors vary widely.

In the UK, we currently have the following breakdown:

1024×768 25.10%
1280×800 24.60%
1280×1024 13.38%
1440×900 10.23%
1680×1050 6.74%
1366×768 2.76%
1920×1200 2.32%
800×600 1.99%
320×396 1.55%

It’s good to see the 800x600s have dropped to under 2%. This has been a steady decline, and so we can politely ignore the size when building our sites.

We build to ensure that there is no horizontal scrollbar when viewed at 1024pixels across. This gives us a working width of 990px to allow for the scrollbar on the right.

Users on bigger screens simply see more space, but they are also likely to avoid maximizing their windows, so this usually doesn’t look too bad.

The big issue is the height of the screen. We cannot give a fixed working height, because we do not know the size of the titlebar and bookmark bars at the top, nor the height of any windows taskbar at the bottom. There is no “usual” size here, since inexperienced users commonly add bars, but do not know how to remove them.

Generally we work to a height of about 550px. It’s important for this part of the screen to convey the majority of useful information.
Users will need to see the following, before they scroll:

  • Logo
  • Navigation
  • Current location in the navigation (highlighted nav or breadcrumbs)
  • First header
  • A description of what this page is about.

We refer to this area as “above the fold”.  This is a term acquired from newspapers, where only the information shown above the halfway fold is visible to the buyer, and so is the area most likely to influence your purchase.

Poor designers can be readily spotted here:  they see the above, and make designs of a fixed height.  This means that the page is built without any vertical scrolling.  This restricts the usable area for content, and usually means some sort of custom scrollbar needs to be used in little windows in the site.  It’s lazy.  It’s amateur.  It’s pathetic.

What I want to point out here is that scrolling is not bad.  People do know how to scroll.  People like to scroll.  It’s the most usable way to present content on the web.

So, please say NO to:

  • fixed height layouts
  • custom scrollers

Reasons you can give are:

  • custom scrollers do not work on touchscreens (like iPhones)
  • fixed height designs can’t flex to fit smaller screens (like iPhones)
  • scrolling is still fine with high-resolution backgrounds.  Look at twitter, where the background is simply fixed.
  • custom scrollers look ugly when javascript is disabled.

While mobile users and non-JS users are usually dismissed out of hand, there is evidence to show that this should not be so.  See the 1.5% of users above using a 320×396 display?  That’s mobile.  And yet the site I used to gather these stats is not even mobile friendly.  This is rising, and will continue to rise.

In Japan, mobile internet is used more than PC internet.

It’s time to embrace flexible layouts.

And to be fair, most of the Internet has.  But there are still a few designers out there who haven’t.  Wake up!