Archive for February, 2009

The happy travels of a postal parcel

Wednesday, February 18th, 2009

Last year, the 21st of December I had to send in my GF’s cellphone for repairs (bought online), incredibly enough the repairs went smoothly and fast, and on the 29th of December it was shipped back to us, using the Norwegian postal system. Little did we know that it wanted to go on a round trip around the southern part of Norway. This is its story.

29.12.08 – Sent from Drammen, Norway
29.12.08 – Arrived at a terminal in Oslo
30.12.08 – Arrived at a terminal in Stavanger
31.12.08 – Arrived at a terminal in Haugesund
02.01.09 – Beep! Still in Haugesund, and the post office realizes that we have moved and that we have bought a service to forward our mail to our new address
02.01.09 – Arrived in Stavanger. Gah! That’s the wrong way!
05.01.09 – Registered at a terminal in Bergen. Yay! It’s getting close!
06.01.09 – Arrived at our local post office in Bergen. Hurray.

…However, they never sent us any packing slip, and we didn’t have the tracking number so we didn’t know.

16.01.09 – Beep! Still in Bergen, and the post office realizes…something and decides to ship it somewhere else.
16.01.09 – Registered at a terminal in Bergen
19.01.09 – Registered at a terminal in Stavanger?!
20.01.09 – Arrived at a post office in Haugesund…again
31.01.09 – Beep! Still in Haugesund, and the post office realizes, once again that we have moved and that we STILL have purchased the service to forward it to our new address.
02.02.09 – Registered at a terminal in Stavanger…yet again
03.02.09 – Registered at a terminal in Bergen
04.02.09 – Arrived at our local post office in Bergen…again. Hurray!

…But they STILL hasn’t sent us any packing slip stating that the package has arrived and that we need to pick it up.
We contact the retailer, which contacts the repair shop, which provides the information that it is here! At our local post office!
So we go to our local post office, I present my ID and that there’s a package for me, aaand… they can’t find it. We go home and yet again mail the retailer, which contacts the repair shop which then gets hold of the tracking number.
Armed with this brand new information, we head to the post office again…

18.02.09 – We get the package.

And no, they still haven’t provided a packing slip.

This is true Norwegian efficiency.

Blogging for LGP

Friday, February 13th, 2009

I’ve just written my first blog post for Linux Game Publishing on the new LGP blog.

The post is about the LGP community. You can head over to the LGP blog to read it.

SWEC future plans

Monday, February 9th, 2009

I’ve got some plans for SWEC in the future. One of its primary limitations at the time is that it can’t really do advanced tests using things like POST or specific pattern matching. So I’m planning a simple command-based file format where you can define advanced checks for sites, to compliment the already existing fully-automated checks.

The basic syntax will be something like this (any input is welcome):

URL http://...
GET
MATCH /regex/ or STRING
RUN_CHECKS

URL http://
POST 'SOME_POSTDATA'
MATCH /regex/ or STRING
[My regex] MATCH /regex/
[String equality] MATCH STRING
RUN_CHECKS

RUN_MAIN

Here any URL statement defines a new check, where all previous data is dropped. Each section can have a POST or GET statement, and then any number of MATCH statements, as well as a RUN_CHECKS statement. If any MATCH statement fails (ie. the regex doesn’t match, or the result isn’t equal to STRING) then it will skip the remaining tests and skip ahead to the next URL or RUN_MAIN statement.

MATCH is obvious, it runs a test on the entire content to see if it matches a regex, or equals a string.
RUN_CHECKS would start the standard (SDF-based) SWEC checks on the returned data.
RUN_MAIN would start the main SWEC mode
[SOMETHING] MATCH would create a named match, so the content within [ ] would be the returned error if it doesn’t match, instead of something generic like “failed to match /regex/”.

Other commands I’ve thought of that I might or might not want to do include one to clean the cookiejar, so that tests can be performed on how a page acts when cookies are missing, and a way to add custom skip filters based upon for instance the URL.

THese are just random ideas and plans that I’ve got at the moment, I haven’t begone coding it yet, but it’s definetely something I’m going to do at some point. I’ll welcome any input if you have any.

Simply checking my web

Monday, February 2nd, 2009

I’ve been doing some web development lately, and the old question of testing has of course come up (and some might say, of course I had to roll my own solution).

I wanted a simple way to sanity check a site, to ensure that my article changes didn’t suddenly break comments on images (lagacy apps are strange beasts). So I ended up writing SWEC, the simple web error checker. It’s a basic app that goes through all links in a site (or “webapp”) as long as those are present in the HTML (ie. it doesn’t run any JS, so its use in JS/AJAX/AJAJ-heavy webapps can be somewhat limited). It parses all pages it downloads, looking for known errors and then reports those. For instance, if you run it on a site based on Catalyst (perl) and catalyst crashes with its standard backtrace, SWEC will return which page it happened on, which page referenced it and a quick line about what happened. Ie. if it’s an exception it’ll say “Exception in Catalyst controller”.

It uses a very simple file format for writing tests (which is well documented in SWEC’s manpage). It has several different types of tests, but the most common one looks something like this:
[SWEC_CATALYST_CONTROLLER_EXCEPTION]
type = regexs
check = Caught exception in.*Controller.*Request.*Catalyst
error = Exception in Catalyst controller
sortindex = 11

What’s between the brackets [ ] is the name of the test. All tests that are shiped with SWEC are prefixed with SWEC_.
The type defines which “type” of test it is. This one is “regexs” which is a ’smart’ regex, a standard perl regex that swec modifies during runtime to easier match HTML. The check is in this case a normal perl regex that is applied to the entire html document. As the type is regexs, swec will modify the regex to this during runtime: Caught(\\s+|&nbsp;|<[^>]+>)+exception(\\s+|&nbsp;|<[^>]+>)+in.*Request.*Catalyst

The error is the string that will be returned, and the sortindex is used for prioritizing tests, the lower the better (bundled tests will always be positive, so one only needs to give tests a negative index to ensure they will be run before bundled ones).

By default the bundled tests (default.sdf) and the user-specific rc file ~/.swecrc will be loaded. The user-specific one can disable bundled ones easily, and you can disable them on the command line on an individual basis.

SWEC supports sessions, where SWEC remembers previously checked URLs, and previous errors and can then either check pages that used to have errors before the others, or only report ‘new’ errors that did not exist before. This will also remember all settings that you set so you don’t have to type it every time (although it’ll allow you to do that as well). It has cookie support so it will run just fine as a logged-in user, though you probably don’t want to run it on a live database, but rather a test one, as it’ll click on any link it sees (with a few exceptions, it tries to avoid ‘logout’ and ‘delete’ links, additions to the exceptions list is welcome).

It’s GPLv3, so feel free to hack your own things into it. I’ll accept patches for the app itself, as well as new tests to be bundled. As long as they are either specific to a language, web server or framework, I’ll happily add more bundled checks (or fixes to existing ones), however I will try to avoid app-specific checks as that might just get a bit too much.

Happy hacking