Tuesday, July 26, 2005

Hardware Tokens

In our office, we all sit around a couple of sets of desks. You may say that we're definitely not 'geographically challenged'. Each pair can pretty clearly see every other pair.

We don't store any source code on our local machines. Since we're developing a PHP application we need to deliver it though a web server and it access a nice big Oracle database, and guess what... we've got a whole department geared up to supporting web servers and databases. So we don't have local installs of databases and webservers, we don't administrate them, and none of us want to.

So our workspaces live on a network drive. Yep, Win CVS is a bit of a pain over a network, but for now we're living with it. Our PHP files live on a web server so we can access them without running any uploads or anything.

We've given our workspaces numbers, prefixed with the name of the project. The source code lives in a folder with the name of the workspace and the database lives in a schema with the name of the workspace. Your pair is working in workspace 'Laurel1', you get set of source code 'Laurel1' and database schema 'Laurel1'. Nice and simple.

The only problem is, if no one individual owns a particular workspace, then how do we know which pair is allowed to work in which workspace?

We have mutually exclusive hardware tokens. Or, to put it another way... we have paper flags that we put into holsters taped onto the back of our flat screen monitors.
If you've got the Laurel1 flag then you've got the Laurel1 workspace, and only your pair is allowed to change the workspace.
If you 've not got the Laurel1 flag then you can't change the Laurel1 workspace.

Since everyone's living so close, it's easy to see the flags. In the very rare situation where a pair is working remotely, they phone up a proxy to get their flag, a humorous effigy is made of one of the pair, and the flag is given to the effigy.

We have a spare workspace too...

We call it integrate*. It's the workspace where the integration takes place. In order to do a large scale commit you must have the integrate workspace token. If you don't then you don't commit. The pair with the token is the pair that's currently doing an integration. It has the advantage of a separate build machine since you're forced to check in from your dev space and check out to the integrate space and everyone can see you're doing it.

Our hardware tokens make it easy to see who's working where.

And they were fun to make.

Technorati Tags: , , , ,


* actually, we call it autotest, but if we got a new one we'd call it integrate... honest.

Monday, July 25, 2005

The saddest post ever

One of the things that I had to come to terms with about 18 months ago was the fact that I needed to understand regular expressions.
The Oracle world has yet to really embrace these strange beasts, and so I was completely hidden from their glory.

Now, I've reached the point where I'm going to do possibly the saddest thing in the whole world. I'm going to post a recent regular expression onto this blog... here... now.

For a soon to arrive firefox extension, I needed to extract a number of complete sentences from a piece of text that numbered at least 100 characters in length. Here's how I did it:

(.|\n){200,}?[\.!\?\)"\n\r]+


OK, if you use apostrophes as quotation marks it falls down a little, but then you deserve a slap anyway ;-)

For being so sad, I must now go and whip myself with a birch branch.

Updated: OK, so I'm hoping that it now deals with newlines properly as well ;-) Serves me right!

Tuesday, July 19, 2005

Extending in batch

Inspired by Andrew Beacock, with thanks to Brian Duff's post here and the cracking resource at XUL Planet, I've started to look at doing some Firefox extension development.

It all looks pretty straightforward. Produce a bit of XML in the guise of XUL and slap in some Javascript event handlers and you've got the idea. Early testing is easy since Firefox just lets you open XUL files as if they're HTML. It's all very easy to get going with.

The only issue I had at the start was the structuring of the source code tree and the packaging up of the .XPI file.
An .XPI file is a packages extension that Firefox can install. It's easy to run one, you can simply double click on it and firefox kicks of its extension manager. Packaging one up though, it a little trickier. Without wanting to get into the details of the how any why (again, Brian Duff's got the intro covered), I've found it's easist to develop within the directory structure that's ultimately required by the XPI package...


+YourExtentionName
|
|-- install.rdf
|
|-+ chrome
|
|---+ content
|-- contents.rdf + other .rdf files
|-- .xul files
|-- .js files
|-- .css files


Brian suggests dropping the chrome directory and having the content in the extension directory, but that's much of a muchness if you ask me. He also supplies an ANT task to package up the XPI file for you. I don't have ANT installed. I don't use it, because I've got no need for it at home (it's overkill for this, really). So in true Windows skript kiddi traditions, I've put together a batch file that'll do the same job.

It assumes the directory structure is the same as stated above, and it should be ran from the YourExtensionName directory.

Forgive me if it's not perfect, feel free to use and amend. It'd be nice if you posted a comment back here if you improve it.

Update:Just had my attention drawn here/ Shame I didn't spot that before I wrote my own Batch file based packager! Eerily similar they are too...



BUILD_XPI.BAT


@ECHO OFF

SETLOCAL

IF ""=="%1" GOTO :noparams

SET current_directory=%cd%
SET extension_name=%1

MKDIR build\chrome
DEL %extension_name%.xpi

CD chrome
CALL :createZipFile "%current_directory%\build\chrome\%extension_name%" *.*
MOVE "%current_directory%\build\chrome\%extension_name%.zip" "%current_directory%\build\chrome\%extension_name%.jar"

CD ..\build
COPY ..\install.rdf .
CALL :createZipFile "%current_directory%\%extension_name%" *.*
MOVE "%current_directory%\%extension_name%.zip" "%current_directory%\%extension_name%.xpi"

cd ..
RD build /q /s

GOTO:EOF


:createZipFile
SET zip_file=%~1
SET files=%~2

REM Change the following line to one that runs your particular CMD Zip executable
REM
REM It should create a ZIP file, adding files recursively, keeping
REM their directory structure

pkzipc -add -rec -dir=specify %zip_file% %files%

GOTO :EOF

:noparams
Must specify a name for the extension



Technorati Tags: , , , , , ,

Thursday, July 14, 2005

Trackback a go go

Thanks to a mail from my good mate Andrew Beacock (why research things when you've got a mate like him to do it for you!), I've think I've got this trackback thing sorted.

For all those people looking for a service out there, I've started using Haloscan. It's pretty easy to setup, Andy's got some help here if you need it, but to be honest it's straight forward.

The difficulty I always had was what to actually do with the trackback once you've got it!

Here's the deal:

When you want to link a blog entry with a trackback facility you start off by writing your blog entry.
Then get hold of the permalink for YOUR entry.
Go to THEIR entry, and click on the trackback link.
With Haloscan you'll then get a trackback URL.
Copy this URL so you now have two links... YOUR entry link and THEIR trackback link
Log into Haloscan and 'Send a Trackback ping'
Paste in YOUR permalink into the (der) 'Your Permalink URL' field, and put THEIR trackback url into the URLs to Ping.

And that should be it.

Check out Andy's post here and it should have a trackback to here...

Technorati Tags: , , , ,

Wednesday, July 13, 2005

Sharing

Andrew Beacock has once again found a little beauty... del.icio.us have added the concept of forwarding bookmarks to other users. I can't wait to see my inbox fill up with useful links from mates, and masses of spam bookmarks from god knows who!

Experimentation is needed me thinks...

Technorati Tags: , , ,