Verkkokaupan koeajo: Gastronautin saitti

Tänään ei huvita käydä kaupassa tai laittaa ruokaa. Voisin tilata jotain. Pizza Pasila olisi hyvä valinta, mutta tänään en halua currykanaa.

Valinta osuu siis Gastronauttiin, ja taidan samalla koeajaa heidän verkkokauppansa.

Gastron saitin suunnittelu ja teknologia on pitkään jo tuntunut jonkun veljenpojan etelänmatkaa vastaan suunnittelemalta ja toteuttamalta. Verkkokauppa ei ole poikkeus.

Rekisteröityminen ja sisäänkirjautuminen ollaan onnistuttu sössimään tekemällä kentistä joihin pitää kirjoittaa aivan samannäköisiä kuin kentistä joissa mainostetaan uusia ravintoloita, ja kentästä jolla valitaan kaupunki. Kenttien päällä on kyllä perinteisen syöttökentän näköinen otsikko, josta klikkaaminen ei tee mitään. Rekisteröityminen onnistuu, jos löytää tekstin alle piiloitetun nuolen.

On aivan turha kuvitella voivansa edes yhtään katsella tai kerätä tilaustaan ennen rekisteröintilomakkeen täyttämistä. Joku amatööri erotti nuo kaksi prosessia toisistaan totaalisesti.

Valitsen ravintolan nimen vasemmasta menusta, ja pääsen ravintolasivulle. Tällä sivulla näen tukun otsikoita, mutta en ensimmäistäkään ruoan nimeä. Jos tajuan klikata erittäin himmeää nuolta otsikkorivin oikeassa päädyssä, otsikon alakohta ruoka-annoksineen aukeaa näkyville.

Oho! Kun valitsin Spizy Co:sta New York purilaisen, sivun ylälaitaan avautui uudestaan samat sisäänkirjautumiskentät joita käyttämällä hetki sitten kirjauduin mielestäni. Ostoskorissa näkyy kuitenkin valintani.

Yritän lisätä lohkoperunoita side orderina, mutta saitti valittaa "sinun pitää olla kirjautunut".

Kirjaudun sisään uudestaan, ja Gastro on kadottanut tilaukseni.

Valitsen suunnilleen samat tuotteet, kiireellä klikkaan tilauksen vahvistukseen, ja teen tilauksen. Saitti lupasi tilauksen menneen perille.

Nyt odotetaan...

The restful hypothesis

I'm taking every fourth week off, starting now. Nine days of uninterrupted rest.

Why? I've been working fairly actively for the last 15 years. I've learned some things about myself and my field.

Projects tend to become hectic. Workplaces become demanding. There would always be so much more to do but so little time.

The pressure to enact big, meaningful changes gives one tunnel vision and encourages one to create and manipulate dangerously oversimplified models of reality in order to create the self-deceptive illusion of reaching organizational goals. (Heimo recently wrote about a similar subject.)

It's hard to critically evaluate efforts one is personally invested in. Most people simply don't go there. I've only been able to step back after the fact.

Postmortems are useful, but not as useful as saving the patient in the first place.

That's why I'm taking every third week off from now on.

To routinely step back and ask myself whether I'm really invested in accomplishing the right tactical goals.

Agile that!

Zend_Cache_Backend_File doesn't work on NFS

We had a bit of a time discovering why our project's Zend Framework-using PHP application wasn't working at all well in our production environment. The first few page loads were working fine, but concurrent page loads were presenting a problem. Neither PHP nor Zend Framework were at all helpful in trying to track down the problem.

It turns out that the application was misconfigured to store its Zend Cache files on a NFS mounted remote file system, and that Zend_Cache_Backend_File tries to flock() its files. On RHEL5, the NFSv3 implementation doesn't react at all well to POSIX locks.

We cracked the problem by figuring out that the locks seemed to timeout at the NFS timeout period, while the rest of our timeouts were at one-minute range, using pstack to dump the stack trace of hanging Apache processes, finding flock() to be the culprit, and grepping through our app's source code for flock, finding only the Zend Cache classes.

Don't accidentally put your Zend Cache files on NFS when using Zend_Cache_Backend_File, or your application will hang.

Cool service of the day: Web Sequence Diagrams

Enforcing strict database DDL upgrade version requirements in Postgresql

When delivering a upgrade version of a web-based product, you often wish to provide your clients with database upgrade scripts.

As the data in the database is the most critical part of the installation, both the upgrader and the developer want to be absolutely certain that upgrades are pushed into the database in the correct order.

This is an example of how to achieve this objective using Postgresql.

BEGIN;

CREATE FUNCTION require_database_version(IN p_version INT) RETURNS boolean AS $$
DECLARE
  dv INT;
BEGIN
  IF p_version IS NULL THEN
    RAISE EXCEPTION 'require_database_version called with NULL input';
  END IF;
  SELECT version INTO STRICT dv FROM database_version;
  IF dv <> p_version THEN
    RAISE EXCEPTION 'Database version required: %. Found %.', p_version, dv;
  END IF;
  RETURN true;
END;
$$ LANGUAGE plpgsql VOLATILE;

CREATE FUNCTION set_database_version(IN p_version INT) RETURNS boolean AS $$
BEGIN
  IF p_version IS NULL THEN
    RAISE EXCEPTION 'set_database_version called with NULL input';
  END IF;
  EXECUTE 'CREATE OR REPLACE VIEW database_version AS SELECT ' || p_version || ' AS version';
  RETURN true;
END;
$$ LANGUAGE plpgsql VOLATILE;

SAVEPOINT s1;
SELECT require_database_version(4);
ROLLBACK TO s1;
SAVEPOINT s2;
SELECT set_database_version(6);
SAVEPOINT s3;
SELECT require_database_version(4);
ROLLBACK TO s3;
SELECT require_database_version(6);
ROLLBACK TO s3;
SELECT require_database_version(NULL);
ROLLBACK;

Setting up a Flash testing environment with several versions of the Flash 9 and 10 plugins

When you're developing a Flash application, you usually want to be reasonably certain that it'll work with the various versions of the Flash plugin which your users might have. The best way to be certain is to see for yourself.

Alas, the Flash plugin was designed to be installed only once per PC, and Adobe wants you as a consumer to always have only the newest version of the plugin installed.

Adobe, however, have provided us with all the tools we need to build a Firefox installation which contains all of the Flash 9 and Flash 10 plugins in separate profiles, so that we can even run the various versions simultaneously.

IE, as usual, is a different kettle of fish altogether, and generates extra customer costs even here.

Let's start by visiting Adobe's page "Archived Flash Players available for testing purposes" at http://www.adobe.com/go/tn_14266.

From there, download the files http://fpdownload.macromedia.com/get/flashplayer/installers/archive/fp10_archive.zip and http://fpdownload.macromedia.com/get/flashplayer/installers/archive/fp9_archive.zip. If the filenames have changed since writing this blog post, you'll probably be able to find the correct files from the Adobe KB page referenced earlier.

These .ZIP files contain all of the .EXE installation files needed to get to the actual plugin files we'll be needing. Create a working directory, and unzip the fp*_archive.zip-files there.

Here's a small shell script you can run under Linux to extract the plugin files from the installation executables, using Wine:

export WINEPREFIX=$PWD/wine
mkdir $WINEPREFIX
mkdir flash_plugins

for file in fp*archive/*/flashplayer*_win.exe
do
  version=`echo $file | awk -F/ '{print $2}'`
  echo $file $version
  wineconsole $file /S /D=C:\\flash\\$version
  cp -r wine/drive_c/flash/$version flash_plugins/
done

... to be continued!

Software projects are such fun