Ben Godfrey

Archive for May, 2004

Fabric boss!

Went to Fabric on Friday. It was wicked! Definitely the best club I’ve been to. The club building itself is sweet, set in a big old cellar complex beneath Farringdon. It bears great similarity to a Quake level, especially being lit in primary colours. The rooms are big, but not ridiculous. The sound system was very good as well, actual treble! Did hurt my ears quite badly, but they’re back to working order now.

Woke up very broken yesterday and even more today. Lots of muscles strained in my arms and back. I did really enjoy the dancing, but next time I think I’ll have to limber up!

I even took some pictures and put them on my Moblg.

SQL Queries Considered Sportier Than Expected

Did some optimising of Hype this weekend. When I wrote the new version I didn’t think at all about query efficiency, I used DB_DataObject to handle all the SQL and just got on with implementing the functionality required. When I came to do some optimisation the first thing I looked at was the number of queries that were actually being run. Turns out it’s about 100 for the home page. Those portlets are data hungry!

The obvious candidate for optimisation was the high scores portlet. The query behind that did a count on the messages for a group (>36,000 for Class of 2001) and grouped them by user. It was taking at least 2.5 seconds for the big group. Once I eliminated that, the other queries take no time at all. Less than a hundredth of a second for a select.

So the actual mechanism of querying MySQL from PHP itself is pretty efficient. The queries themselves can be slow however. I’m going to be timing queries on the MySQL command line from now on, but I won’t be thinking of perfomance too much when I next need to trawl something from the DB.

If you’re interested at looking at some profiling info for Hype, add ?debug=true to any page URL and check out the tail of the HTML source.

Note: My MySQL server and web server aren’t even on the same box, but they are in the same rack.

London blog meet

I enjoyed it. Not the Budweiser mind. I drank about a thousand and still came out only mildly happy. They were £3.50 each as well. Three fucking fifty.

End of rant.

Otherwise it was an interesting evening. I met some people with quite well known blogs, including Simon of Minor 9th, a Guardian blog contest winner and a very nice young man. There were lots of nice people there. We talked about the nature of blogs of quite a lot and the differing views were interesting, blogs as journalism, blogs as publishing, blogs as diaries. Most interestingly, blogs as enterprise tools.

I kind of expecting more people talking about software and sociology and the possibilities for business and large scale projects. There wasn’t much of that at all. Which I guess isn’t so surprising, the people there were more into personal expression on a techie media than software engineers per se. It’s made me really excited about NotCon though!

Incidentally, I didn’t talk to Cory. Ladislav did though…

Conversation volume

Little Cocoa app that monitors the room volume via a computers microphone and reduces the system sound when the room volume goes up. The net effect is that if you start talking to somebody, the music goes down in volume. When you stop, the music goes up again.

This is almost certainly too simple and just wouldn’t work because of pollution by the music that’s playing. But you can tap into the audio output on Mac OS X, so you could filter everything coming from the computer out by comparing the input to the output, accounting for a certain amount of distortion.

V&A

Went to the V&A yesterday with Louise. I’ve been doing so much stuff on Hype we haven’t really been spending so much time together and it was our three year anniversary! We’ve also been talking about going to the V&A for ages, having lived about ten minutes down the road from it for a year and a half.

We didn’t stay for very long as we did the usual Saturday thing of rolling up at about half three. We then went into the Bill Brandt exhibition that they’re showing pretty much straight away. We quickly detoured around some exhibits from China and Japan though. They had some lovely traditional Chinese furniture and a whole load of Japanese armour and weaponry. They had an unsheathed, dehandled katana blade. It was amazing. I’ve never seen anything like that. It was so flawless and singular and obviously very dangerous indeed. They had a range of other daisho, katana and wakizashi and some cool suits of armour.

The Brandt exhibition was quite interesting, but quite small. It was chronological as well, so by the time we got to the interesting portraiture and the surrealist nudes our attention spans were waning a bit. Although it was nice to see a side of him that I didn’t know.

Brandt started out as a documentary photographer and I found his images of 30s London and the North of the depression very interesting. The pictures of the North on the way out of the industrial revolution were particularly moving. The difference in scale between the people and the world they lived in was crazy, like the people were just crawling between the teeth of cogs in a giant machine. Or as if the technology wasn’t capable of building things small enough for humans. It was all really very crude and slightly monstrous.

In the evening we went to dinner with Louise’s family at the Bluebird for Louise’s Mum’s birthday. We had a nice meal with a free glass of champagne, which went straight to my head. Afterwards Louise and I watched Girl With A Pearl Earring which was a nice period movie, but not particularly engaging, the plot was a bit light. Boy is it great to able to plug my laptop into the TV though, much better than watching stuff on a monitor. And the sofa is definitely a far better place to sit still for that amount of time.

Hello Pixelsurgeons!

Thanks to Alfie Dennen for an extremely flattering review and a link on Pixelsurgeon. Cheers!

And yes I know the content page looks shit in IE on the PC. If I’d known I was having guests… :-)

London blog meet

May 12th — The International

Loads of people will be going from the looks of the page (curiously hosted by Joi Ito who is, AFAIK, in Japan). It’s just a little bar restaurant.

I will use the event to expose Hype a bit and network and possibly put my feelers out to find out more about NotCon. And I’ll be in the same room as Cory Doctorow, who is like a blog superstar, even though he doesn’t really have a blog. AFAIK.

Permanent logins with PHP sessions

Disclaimer: I think this works, but it’s only endured light testing so far. I may be wrong. Please let me know if you think I am.

PHP sessions are a great addition to the application programming environment. The first time I used cookies I used PHP’s setcookie() function to roll my own system, which can only be described as flaky. Browsers seem to have an overwhelming disdain for cookies in general, each one requiring a complex set of chicken dances to work. PHP sessions may or may not do lots of clever stuff under the hood to address these problems, but they have always worked 100% reliably for me and that confidence has been enough for me to deploy and forget the technology, something which is critical if we are to get on with the business of developing actual software and not constantly writing our own libraries.

But eventually the time came when I wanted to have the option for people to be logged in permanently (or at least for a very long time, let’s say 90 days). Finding a solution to this problem took me a little while, so I thought I’d write it up. I got quite a lot of help from this discussion at the Experts Exchange and obviously the sessions section of the PHP manual.

First piece of knowledge: PHP garbage collects session files when their modified time reaches a predefined timeout, the default being 1440 seconds — about 24 minutes. PHP has a series of INI file settings that govern the sessions system. These allow you, amongst other things, to control this garbage collection, by either raising the timeout, or reducing the probability of collection after that timeout has expired. For my purposes, I wanted the session files to remain intact on disk for up to 90 days (7776000 seconds). The php.ini key for garbage collection is session.gc_maxlifetime. If you have control over your php.ini file, simply locate and alter that value. If you don’t, you can change these options via a .htaccess file (see below). It’s not enough to change these options using the ini_set function as the value needs to be maintained for all instances of PHP that are working in the session dir.

According to one expert at the Experts Exchange, changing your session.gc_maxlifetime will cause problems when PHP instances running other scripts (e.g. belonging to others on a shared server). This can be fixed by moving the session save path to a different location. This can be acheived with session.save_path parameter.

Presumably, if you set your session.gc_maxlifetime and then move your session path with ini_set(), your sessions will be untouched by other PHP instances, meaning you can use just ini_set to do the initial lifetime change. I haven’t tested this however.

I also decided to specify that my sessions should use cookies only. I set both session.use_cookies and session.use_only_cookies to “on” and session.use_trans_sid to “off”.

As I don’t have access to the php.ini on my production server, I put the following block into the .htaccess for my application:

<IfModule mod_php4.c>
    php_value session.gc_maxlifetime "7776000"
    php_value session.save_path "sessions"
    php_value session.use_cookies "on"
    php_value session.use_only_cookies "on"
    php_value session.use_trans_sid "off"
</IfModule>

OK, so now a user’s session will be waiting on the server for them to come back, we have to ensure that the other half of the equation — the browser cookie — will wait just as long.

Second piece of knowledge: session_start() always sends a Set-Cookie header with the default path and no expiry time. No expiry time means that the cookie will be removed when the browser is closed. If session_start() sends a cookie with an expiry we don’t want, don’t we have something of a chicken egg situation? We need to run session_start() before we can access our session data, but to make the cookie optionally permanent you have to store that somebody wants a permanent cookie somewhere: the session. There are other options, but they are less then ideal. For example you could store the option in a database, but what if the user wants to be permanently logged in on their home machine, but not when they visit your site from a net café?

The solution is to stop and then restart the session with the new timeout parameter. The algorithm looks like this:

  1. Call session_start(), this sends a duff cookie, but it does give us access to $_SESSION
  2. Look in the session for the permanent flag, and copy it
  3. If the user wants a permanent login:
    1. Run session_write_close(), this commits the session to file and closes it
    2. Use session_set_cookie_params() with just one argument to set the cookie timeout, 7776000 seconds in our case.
    3. Run session_start again, this time it sends a good cookie

All you need to do when the user logs in is create the permanent flag in the session if they want it.

This solution has been tested and works on Mozilla, IE5/Mac, Safari, IE6/PC and IE5/PC.

Because two Set-Cookie headers are sent with each response, it’s conceivable, even likely, that some browser somewhere will get confused and set the expiry time wrong. In this case it should be possible to do the work of the original session_start() call manually. Get the cookie using the $_COOKIE array, find the session file, parse the file for the perma flag (unserialize() didn’t work as I hoped it might have done) and then resume the original process at step 3. I haven’t implemented such a system myself as yet, so this approach is untested.

Milestone 6

Today I reached M6 for Hype and put the site up so people can play with it! Finally, after all these years, it being almost three years to the day since I first put Hype up.

I got a lot of feedback, lots of positive comments, some bugs and some keen exploration of the potential and operation of some of the new features I’ve put in. Link title grabbing, a recent addition to the feature set, got much attention. At the moment the system tries to grab the titles from everything, 404’s, MP3’s, flash files, you name it. I just hadn’t thought about it thoroughly enough and my test data was wholly inadequete to highlight the problem.

Oh man, so much stuff went on today. The old Hype is kind of already dead, people are posting to the new one instead, even though nothing’s there. I’d better port the data across fairly soon otherwise it will take on a life of it’s own!

So I’ve got a list of about 15 things to go through in response to today alone. That’s on top of all the things I had anyway. But it’s all good stuff. What worries me is that now the system is visible I’m loosing the burn. But I’ve fought on through this for a while. What I wonder is how much work I’ll do in the next six months. Will my list be complete by Christmas? It could be.

As for now, I’m pretty worn out. Do a bit of hacking I think then pass out and get back to it tomorrow in earnest.