The cnb experience

I've finally gotten around to setting up a gallery for my photos again.

There are several reasons why it's taken me such a long time. One reason has of course been the fact that I've had a bit of a dry spell in my photography interest during 2008. But mostly it's been more technical. I'm not too fond of having all my photos in the hands of a third party service, so that's never been an option. And for some reason all the off the shelf galleries have gotten such bloated and intrusive designs lately. Or have seriously dated designs instead. Or are bloatware under the hood. Then there are the ones which are just far too basic.

When it all comes down to it, I ended up reinventing the wheel and hacked up a quick little gallery which you can find at http://gallery.cnb.se/. It relies heavily on javascript and isn't well-tested, so use at your own risk.

As you can see from the latest shoots, I've been much more active recently, and I'm hoping it will stay that way (though perhaps with a few more days between shoots than the past week) in the future. I've recently invested in a Canon Speedlite 580EX II flash, so I'm exploring a whole new area in photography for me as I've previously always avoided using flash. Now I'm considering buying one or two more instead with a wireless flash setup. Could make for some nice lighting.

Also, keep an eye out for more additions to the gallery from shoots in the past couple of years. I will add old photos as I come across them.

A couple of weeks ago, we launched the new ULUG website based on FöreningsCMS which uses my TemporalData class. Check it out! And don't forget to stop by Café Linné tonight after 18:00 if you're in the area

Working on my TemporalData class, i realized that it should be an abstract class. It's the way I intended to use it all along, but I somehow forgot that PHP now supports abstract classes and didn't define it as such.

The TemporalData class has a couple of static methods used for selecting objects from the database, and I use late static bindings (a php 5.3 feature) to figure out which class the call came through and in turn which table to query. If you were to call one of those methods directly on TemporalData it wouldn't have any way of knowing which table to query, so I used this code to block such calls:



I thought I could get rid of this check now that I defined the class to be abstract. Turns out this isn't the case:



Output:



Tested with php 5.2.6 and 5.3.0beta1.

I was talking to Johan some time ago and he mentioned working on Temporal Databases. At the time it sounded interesting, but I didn't give it much more thought. Lately I've started thinking more about it, and it's such a simple yet ingenious concept. Instead of deleting or modifying data you'll mark the old data as invalid and insert the new valid data. Of course, in a true temporal database, this is largely transparent to the application. It's useful in pretty much any context. Of course there are exceptions, where it's just unneeded overhead, but usually there's no reason to not keep historic data around. Especially these days when disk space is so cheap. (BTW, did you see the new 2 TB 3.5" disk from Western Digital?)

Many applications (though far from all or even most) keep logs over when things change, so if there is some problem you can backtrack through the logs and if you ware lucky see what changed, and if you are even more lucky you might even be able to see what or who caused the change, and why. The data most likely isn't machine readable any more though, and it takes a lot of manual labour to figure out the history of any given object.

Temporal Database solve this at the database layer, and can be implemented in an existing SQL database using a couple of views, triggers, rules and PLSQL functions. What you need is a couple of extra columns. A start column that marks the first moment in time when the record became valid, and an end column that marks when the record became invalid.

The start column is always set and defaults to current_time. The end column can be null though, as would be the case when you first insert a new record in the database. When you do an UPDATE a trigger catches your query and changes it into two queries: The existing row only gets one row changed, the end column, which is set to current_time - then a new row is inserted with all the data from the existing row, after your changes have been applied, and start set to current_time and end set to null. The procedure for a DELETE is a bit more simple. A rule is created that traps the DELETE statement and replaces it with an UPDATE that sets end to current_time.

Another thing you'll need to keep this logic completely contained in the database is a view for the currently valid data in the table, which simply selects all the rows where end is null. To make things even more transparent you could probably add some rules and triggers to this view which acts on the real table, and then only use this view for everything in the application, though I have yet to try this out.

The above setup is pretty sweet since everything happens automatically. It does have a couple of drawbacks though.

• You have to manually set up all the views, triggers, rules and functions for each and every table.


• When you make changes to your tables, you will need to make the corresponding changes in the views etc.


• If you ever need to purge historic data things get complicated.

The last point is something I personally like. I wouldn't want it to be easy to permanently delete data from a database set up this way. It's however a very important point here in Sweden when dealing with information about living persons since "Personuppgiftslagen" ("The Personal Data Act") applies. One paragraph of the law states that personal information may not be stored longer than necessary. This is obviously an issue if the database system intercepts any DELETE statements and blocks them. One way of working around this would be to disable the delete rule while removing the old data, which could probably be implemented as a PLSQL function. However, there are probably other parts of the law that applies too, e.g. keeping historic records of a persons addresses as they move around may be storing too much information. It'd be interesting to have a lawyer look at that.

While the advantages in keeping all the temporal logic inside the database are numerous I'm considering the alternative of implementing it all in the application layer. Since I started looking at temporal databases I've experimented with both versions, and I'm torn between them, and I think that will always be the case.

I'm currently working on a new member database for ULUG (speaking of which, our last meeting was a great success, with twice as many attending as the meeting before!) which will employ the temporal database concepts, and I've decided to go with the application layer approach, and I'll be extending the concept a bit. I've added two columns for editor and logmessage. The editor column will contain the user id of the person who performed the last record update, and the logmessage will allow the editor to comment on his changes for future reference. It can also be used to specify things automatically, such as "User changed their password". I've also added a column named revision. With every record update it will be incremented by one. This will make it easier to refer to a specific update of an object, for example "User ID 1, revision 5" instead of "User ID 1, as it looked at 2007-04-06 15:45:32". I also decided to use this in combination with the record ID as the primary key, instead of a more complex key using the start and end timestamp columns.

Every page in the system displaying data that come from a temporal source will automatically display a small clock that when clicked allows the user to pick a date and time and show the object as it looked at that point in time. When an old revision is being displayed, the background will change and a warning text will appear at the top of the page to make it clear without a doubt that this data is no longer valid. There should also be some kind of way to show a log of all the revisions of an object, though I'm not completely done with the thought process on the specifics of this feature.

My goal is to implement the temporal aspects of this as a special class that holds all the temporal logic. Any other objects, e.g. Member, WikiPage, etc, should be able to inherit from this object and automatically get the benefits of temporal data without having to manually add the extra code as would be the case when it is implemented in the database layer. The only thing needed are the extra columns in their respective table.

If I can get that to work nicely I'm sure I'll end up using the application layer approach much more than the database layer approach. The drawback of course is that an application error could potentially erase data, but that's a problem with regular databases as well and I've managed to avoid any such bugs in my code so far. And if the worst case would happen, that's where my point-in-time-recovery backup system enters the picture!

While working on a project this morning I discovered what appears to be a bug in PHP when dealing with objects and calling functions statically. I was calling a static function of a class from within an object of a different class. However, I had forgotten the name of the function I needed to call and ended up calling the wrong function. And even though the function I called wasn't declared as static I didn't get any error. Instead $this in the function ended up referring to the calling object.

Here's a short example:



And the output:




Update:
I've only tried this in version 5.2.6 so far. I suppose it might be the intended behavior but it seems rather odd to me. Though come to think of it, you don't get any errors when calling a non-static function statically from global scope when the function never use $this. In my opinion, these situations should cause a fatal error.

We finally have some new life and energy in ULUG. Two weeks ago we had another meeting with a rather small turnout. However, this sparked some online activity among other people who didn't make the meeting. And one of the attendees took it upon himself to finally fix our website. For a far too long there's been nothing there except a message apologizing for the lack of a website, but no more!

We're having another meeting on Tuesday (10th of March), and I'm hopeful that we'll see at least one or two new faces as well as some regulars. It's in the same place as usual, upstairs at Café Linné.

Uppsala Linux User Group is having a meeting on Tuesday November 11th at Café Linné. If you're in the neighborhood around 6 pm, feel free to drop by. You'll find us upstairs.

As promised in the previous post, here is a little update on what I've been doing with customized workflows in Trac. I've only recently convinced everybody at work to move over to Trac, so we're still in the process of streamlining everything. It wasn't a hard sell, the last couple of projects have been set up with a shared document in Google docs, where they've had a hard time telling which "tickets" have been started, finished, or are even supposed to be included in the current milestone. However, as they have started using Trac in a more serious manner, and now even letting customers into the system, I've gotten a couple of customization requests.

For example, just because a feature is implemented or a bug is fixed, the ticket is not considered ready to be closed. It's only closed once the code has been deployed to the production server. From the get go we tried to work around this, since in Trac a ticket is either open or closed. By having different resolutions and reopening the ticket and then closing it again with a new resolution, we were able to almost get what we wanted. However this does not look good in many places around Trac, for example in the timeline, and when the customer sees the ticket as closed, they expect it to be live on the production server as well.

Thankfully Trac 0.11 introduces a new feature which solves this completely for us - Customizable Workflows. It's an amazingly powerful yet simple to use feature and I got a sample setup up and running surprisingly quickly. The showworkflow command line tool that ships with Trac now was extremely helpful and made it even easier to see that you set things up the way you planned without requiring extensive testing when you make modifications. It simply takes your configuration file and generates, using graphviz, a flowchart of your workflow:



As you can see when comparing the default and my sample workflows above, we've added a couple of extra steps in between the accepted and closed states. Once you've accepted a ticket it cannot be closed, the only possible actions are to either reassign it or to submit it for review by the project manager. When you submit it for review, it ends up in a new Status called validation. While in this state, the manager can choose whether to let it pass the review or to reopen the ticket and send it back to the developer.

Once it has passed the review it ends up in yet another new Status - ready_for_deployment. From this state the developers can choose to either deploy the new code to the shared development server and demo it to the customer, or directly deploy it to the production server. It's also still possible to reopen the ticket from this point. If they however deploy it to the development server the ticket ends up in yet another new status called deployed_dev. Only when a deployment on the production server is completed the ticket will be closed. This can be performed either from the ready_for_deployment status, or from the deployed_dev status.

While we haven't put this new workflow to the test yet, I'm certain it will work much better than the previous system with different resolutions. Since I find this feature to be well-documented I don't see any need to repeat the steps needed here, however I will post the [ticket-workflow] section from my trac.ini here for your reference:



Things I have planned for the future is customizing the permissions so that indeed only the manager can say a ticket has passed the review (With the configuration above, any developer can do it since they all have the TICKET_MODIFY permission) as well as modifying the milestone status page to account for the new states.

I have finally decided to start up my blog again. I've decided to promote it to cnb.se instead of blog.cnb.se where it used to live. If I ever have any useful non-blog content I'd like to put up here, I'm certain a subdirectory will suffice!

Considering the both interesting and hateful things I stumble across at work these days, I'm hoping this time there will be more frequent updates and certainly more interesting posts. For instance, recently I've been busy setting up a customized workflow in Trac for our developers, and in a personal project we're trying out DAO - Database Access Objects.

Stay tuned for the next and future updates where I'll talk more about those topics and more!