After staying at the Sofitel Centara Grant in Bangkok, I actually enjoyed the Chaophya much better, even though it is allegedly rated lower than the Sofitel, the atmosphere is much nicer. I’m sure some useless services I don’t use were offered but quite frankly the ones I do like to use (shower, pool, internet) were in my mind better at the Chaophya than at the Sofitel. The room size was nice, the bathroom was wonderful and I had my own personal ADSL connection that seemed to run fine. My only disappointment was that it was all centrally linked to the power so the network would go off when I left the room which meant that it was hard to download anything when I was absent from my computer and it took a minute or so for the ADSL to get line sync when I first came into the room. The place has some nice features and a nice restaurant and bar.

Web design is a skill I don’t have. I admit this freely that is why I write code. But what I hate more are the Photoshop crowd of web page designers that make my life well and truly hell because whilst it looks pretty at the fixed resolution in Photoshop it looks like absolute crap because they rely on Photoshop to build the HTML for them which produces tables with insane spans in them, I’m looking at one with a rowspan of 12. That means tha one cell is supposed to span 12 rows. There is another with 14 and one with a colspan of 9. What I’m realy complaining about here is the lack of decent web designers who can make a decent web page template, something that will work across browsers properly. I know they exist but they are well and truly not the majority of designers out here or at least not the ones I have to deal with. What is worst still is that I have to deal with situations where they have decided to hire the designer separately and get the design done and then I end up having to clean up the mess of a design to get it to render properly. It just makes my life hell when I could be doing better things. Next on my list are the horrible hosting companies that I end up having to deal with as well.

Over the last two weeks I’ve had lots of experience and fun with Citrix and have managed to learn more about Citrix, Windows, Flex and mandatory profiles. I’ve managed to play with all sorts of interesting toys and problems since I’ve had to play with this, and all of it coming from the guy who has a full time Linux desktop and a Mac (very fond of my Mac). We’re amalgamating and all of the other shires (maybe 200 people) don’t really want to move away from their near and dear Outlook client nor do they seem very co-operative for much else. So we end up having to provide them with Outlook instead of Notes.

What we have been trying to do rather unsuccessfully is get IBM’s Domino Access for Microsoft Outlook to play nicely together with everything, including the Hummingbird DM extensions for Outlook. We’ve tried every combination of settings and a few versions of DAMO to get things to play nicely and it really isn’t.

Initially we had some success with getting DAMO to work nicely with Outlook. It takes us a lot of effort to get a user set up with both DAMO, Outlook and their Domino/Notes ID file. We had to go through manually for each user and set them up, however we didn’t get that far.

We next tested to see if the DM extensions were going to play nicely with everything. We found that the DM extensions worked well but DAMO ended up not working at all. We tried this in both our Citrix test environment and then within a Windows XP machine. Simply put, it didn’t want to fly.

So we went for the next best option, which was setting up Scalix profiles. We had the same MAPI profile set up for each user and configuration but it wasn’t as bad as the process we had to go through with DAMO (that is one nasty piece of work). We were running with a trial of Scalix and put it into our training environment to get an idea of the way it would behave when you threw some real load at it. Then we discovered that we couldn’t only have a limited number of premium clients and ended up swapping users around in training to try and get a realistic picture of things. We also did some numbers on Scalix versus Exchange, because that is what our last options were looking like and it started look like in the long term Scalix was going to cost more over Exchange. Plus we found this really nice looking tool that will make integrating the two possible which could provide us even more features over the Scalix solution (this might solve integrated calendars that Scalix wasn’t going to give us, but DAMO would).

So now, after a few weeks of trying DAMO and Scalix we’ve gone for an Exchange solution that might be able to get us out of the water and those who don’t want to learn anything new (or understand for that matter) with Outlook…and mostly everyone is happy.

So most of my day I write code which is cool. I usually don’t have to redeploy things because I end up testing in the same environment that I work on it isn’t until I start a release cycle that I need to start to package things up that I really utilise build scripts. Initially I used to just export from SVN and tar things up by hand. I had also recently heard a few proponents to suggest Phing, a PHP based build tool that uses XML files similar to ANT, as something to use with my build scripts. The scripting that I had done was all in Bash, a rather flexible shell environment but lacking in a few features that a dedicated build tool gives me.

What triggered a lot of this is a set of rather strange bash scripts that form the build tool for Joomla!. It handles building the packages, exporting the packages and building the patch packages (diff of new files and updated files from the old release). Wilco always says that we should use Phing instead because it has all of these features. So this project called JAuthTools that I work on started becoming big and it was a pain to build things for it by hand so I decided that now was the time to get into Phing.

Phing
Phing (http://phing.info/) is as stated before a PHP based build tool. Its web site says it can do anything you can do with a traditional build system, which is really kind of your base expectation when you think about it. Why would you replace your build system with something that provides you less? Phing comes with by default all of the nice things you’d want from a build tool, tasks to do things, output things, make directories, move and copy things, call other tasks and a few other nice things.

Problem is that what I’m after is something to build tarballs, and these are marked as optional tasks for the system. This has some cool things like DbDeploy, which connects to a special DB and builds SQL delta files (version control for your DB), coverage analysis, PDO SQL executor, PHPUnit and my personal favourites, tasks for Zip, Tar and Subversion.

So I went to install Phing on my work box. Its a Linux machine so I decided that I wanted to avoid the PEAR path because that is just as good as installing things all over my system. Phing lived happily in my personal bin directory until I realised that to get SVN working I needed to get this thing from PEAR. I decided that I might as well fight PEAR (and my work proxy for that matter) and install it that way. It only took a few attempts to get PEAR to work through my work proxy, it appears that between the last time I was fighting it they fixed it up which is nice. CPAN is another one that is a pain as well because it wants to pull things left and right and my proxy decides that half of the files it wants are too big and it should ask for them after 5pm instead or use a special download request system. But I digress, Phing ends up being mostly unhappily installed via PEAR with a few complaints (I said, “yes download your dependencies” which bombed out when it figured out that its dependency was still marked unstable and refused to install it (so why err bother? why not ask me! I want to install it, I even said so, that is what “alldpes” means right?)). So now I have a SVN capable Phing! Shiny!

So I go off and build all sorts of things and suddenly the installer rejects the package I just built with Phing complaining its an invalid zip file. So I ended up by working around this with a Bash script that basically rebuilt the ZIP archive after Phing was done with its business. So I progress from Bash to…err…Bash via Phing! This is on a PHP 5.2.5 latest build so I’m not sure where the fault for this lays, but if I end up using the old tool then as far as I’m concerned it isn’t a replacement for my build system.

The next thing that I ended up finding is that the nested dependencies appeared not to be fully supported by the tool, which didn’t particularly bother me however as you’ll read later Make supported this perfectly fine. So I ended up having to alter my build file to handle Subversion check outs better because it would check it out for each sub dependencies. So I would have a top level one and then sub-dependencies so that each individual item wouldn’t have to do it themselves, especially for the targets that matched the same repository. I ended up just moving this into a common parent dependency and going from there.

And then I wanted to do some work on my Mac at home. I have a slightly out of date PHP, 5.2.0, which appears to have caused issues. This time I went straight to using PEAR to install things and again this caused issues, but given I was expecting some hassles I managed to get things working. I also don’t have a nasty proxy or firewall so that makes life easier for me as well when installing these things. I tried out my first build script and it spewed out a horrible amount of errors. For some reason on this combination SVN doesn’t want to work which dies silently which then causes the rest of the script to fail because it expects the SVN task to succeed and given I’m using a build tool to ensure that errors get properly trapped it doesn’t bail out or check that directories exist like I could do with a shell script.

Whilst this all sounds bad I did however like one feature that allowed me to control what the zip task (or selected other tasks) included and excluded which made things easier for building packages and controlling operations that are slightly harder in bash or make.

Make
Today I started off making a few new scripts on my Mac to replace the non functional Phing scripts. It wasn’t too hard to go from Phing to Make but I ended up re-expanding out my SVN scripts now that I have a system where the dependencies work better. Strangely enough my zip files also started building properly which was nice to have. But this got me thinking: why do we reinvent the wheel?

Sure it is nice to have a fancy XML file that takes a lot of control away, but at the end of the day when I compare what I wrote to get SVN to export in Phing and what I have to do with Make or BASH, on sheer number of characters I end up finding that Phing loses again.

But here is the really simple thing: Phing’s SVN support is a wrapper around the regular command line SVN client. The advantage of using Make or BASH is their portability for myself. My primary environments are Mac and Linux, and when I have been on Windows for extended periods of time I ended up installing Cygwin. So at the end of the day my build system is portable between systems. Additionally the “Gotcha’s” page for Phing shows that it isn’t really a walk in the park to get it to work on Windows either. The question is that do you really want to play with your build system each time you want to change platforms or do you want to go and get up and go without too many issues.

Make and BASH are both staples of the Unix environment and have had years of testing. Whilst it is nice to have something with a whole heap of new features, the fact is that some of the basic functionality doesn’t work properly or is a pain to get working across platforms: I ended up replicating these features anyway.

Today I’ve been working on some new stuff for Joomla! to enable SSO between disparate Joomla! instances. I’ve tested it on Joomla! 1.0 and 1.5 in legacy mode. I’ll do some more work later to get it working with Joomla! 1.5 in native mode and to better integrate with JAuthTools for 1.5 (to utilise the SSO system that I’ve written for 1.5). If you’re interested, check out the JAuthTools SVN here: http://joomlacode.org/svn/jauthtools/sso/joomla10x/soapsso. If you check it out you can use the install from directory feature to install it into your test sites. I’ll have packages up in the next few days.

I’m also looking at doing some work on the JAuthTools for 1.5 to improve support. There appears to be some issues so I want to get it back up and running as well as porting/merging some of the features from the LDAP SSI into 1.5 and the LDAP Authentication plugin. I’ll probably also do some update to docs on the wiki as well to reflect the new features.

Things on my todo list after I clean up my released JAuthTools plugins:

• Backlink Manager
• JAuthTools Manager
• JDiagnostics for 1.5