When I first started it, my online photo gallery started out simply as a set of interlinked HTML pages. Over time, I discovered frames (yes, them!) and started to make use of JavaScript to make the slideshows slicker. In those days, I was working off free webspace provided by my ISP and client-side scripting was the only tool that I had for enhancing functionality. Having tired of the vagaries of client-side scripting - the browser wars were in full swing and incompatibilities reigned supreme, I went with paid hosting in order to get access to tools like Perl and PHP for server-side processing; their flexibility compared to JavaScript was a breath of fresh air to me and I am still a fan of the server-side approach.

The journey that I have just described is one that I now know was followed by a lot of website builders around the same time. Nevertheless, I have still held onto JavaScript for some things, particularly for updating the DOM as part of making the pages more responsive to user interaction. In the last few years, a hybrid approach has been gaining currency: AJAX. This offers the ability to modify parts of a page without needing to reload the whole thing and that has generated a considerable amount of interest among web application developers.

The world of AJAX is evidently a complex one though the underlying principle can be explained in simple terms. The essential idea is that you use JavaScript to call a server-side script, PHP is as good an example as any, that returns either text or XML that can be used to update part of a web page in situ without the need to reload it as per the traditional way of working. It has opened up so many possibilities from the interface design point of view that AJAX became a hot topic that still receives much attention today. One bugbear is efficiency because I have seem an AJAX application lock up a PC with a little help from IE6. There will always remain times where server-side processing is the best route and that needs to balanced against the client-side and vice versa.

Like its forbear DHTML, AJAX is really a development approach using a number of different technologies in combination. The DHTML elements such as (X)HTML, CSS, DOM and JavaScript are very much part of the AJAX world but server-side elements such as HTTP, PHP, MySQL and XML are also very much part of the fabric of the landscape. In fact, while AJAX can use plain text as the transfer format, XML is the one implied by the AJAX acronym and XSLT is used to transform XML in HTML. However, AJAX is not limited to the aforementioned technologies; for instance, I cannot see why Perl cannot play a role in place of PHP and ASP can be used for the same things.

Even in these standards-compliant days, browser support for AJAX remains diverse, to say the least, and it is akin to having MSIE in one corner and the rest in the other. Mind you, Microsoft did introduce the tools in the first place but they used ActiveX and Mozilla created a new object type rather than continue this method of operation. Given that ActiveX is a Windows-only technology, I can see why Mozilla did what they did and it is a sensible decision. In fact, IE7 appears to have picked up the Mozilla way of doing things.

Even with the apparent convergence, there will continue to be a need for the AJAX JavaScript libraries that are currently out there. Incidentally, Adobe has included one called Spry with Dreamweaver CS3. Nevertheless, I still like to find out how things work at the basic level and feel somewhat obstructed when I cannot do this. I remember perusing Wrox’s Professional AJAX and found the constant references to the associated function library rather grating; the writing style didn’t help either.

My taking a more granular approach has got me reading SAMS Teach Yourself AJAX in 10 Minutes as a means for getting my foot in the door. As with their Teach Yourself … in 24 Hours series, the title is a little misleading since there are 22 lessons of 10 minutes in duration (the 24 Hours moniker refers to there being 24 lessons, each of one hour in length). Anything composed of 10 minute lessons, even 22 of them, is never going to be comprehensive but, as a means for getting started, I have to say that the approach seems effective on the basis of this volume. It has certainly whet my appetite for giving AJAX a go and it’ll be interesting to see how things progress from here.

My work in the last week has put me on something of a learning about Oracle. This is down my needing to add file metadata to database as part of an application that I am developing. The application is written in SAS but I am using SAS/Access for Oracle to update the database using SQL pass-through statements written in Oracle SQL. I am used to SAS SQL and there is commonality between it and Oracle’s implementation, which is a big help. Nevertheless, there of course are things specific to the Oracle world about which I have needed to learn. My experiences have introduced me to concepts like triggers, sequences, constraints, primary keys, foreign keys and the like. In addition, I have also seen the results of database normalisation at first hand.

Using Oracle’s SQL Developer has been a great help in my endeavours thanks to its online help and the way that you can view database objects in an easy to use manner. It also runs SQL scripts, giving you a feel for how Oracle works, and anyone can download it for free upon registration on the Oracle website. Also useful is the Express edition of the Oracle 10g database that I now have at home for personal learning purposes. That is another free download from Oracle’s website.

My Safari bookshelf has been another invaluable resource, providing access to O’ Reilly’s Oracle books. Of these, Mastering Oracle SQL has proved particularly useful and I made a journey to Manchester after work this evening (Waterstone’s on Deansgate is open until 21:00 on weekdays) to see if I could acquire a copy. That quest was to prove fruitless but I now have got the doorstop that is Oracle Database 10g: The Complete Reference from The Oracle Press, an imprint of Osborne and McGraw Hill. I needed a broader grounding in all things Oracle so this should help and it also covers SQL but the aforementioned O’ Reilly volume could return to the wish list if that provision is insufficient.

One of the nice things about eBooks is the saving that you can make on buying one instead of the dead tree edition. And if you get one from Apress, it is the full article that you get and they keep it available so that you can download another version if you need it. You can also print the thing off if you want too but a laser printer producing double-sided prints is an asset if you don’t want your space invaded by a hoard of lever arch binders. Having a copious supply of inexpensive toner helps too as does cheap paper. Otherwise, you could spend your savings on printing the thing yourself.

The ever pervasive Safari does things a little differently from the likes of Apress. Mind you, the emphasis there is on the library aspect of the operation and not eBook selling. The result is that you can only ever download chapters, so no index or overall table of contents. You still can buy all of the chapters for a particular book, though some publishers don’t seem to allow this for some reason, but finding anything in there after you have had a read becomes an issue, especially when it’s the hard copy that you are using. Take yesterday, for instance, when trying to relocate the formatting parameters for the UNIX date function. I eventually found them in the chapters of UNIX in a Nutshell that I have downloaded and printed off but I spent rather longer looking in Learning the Korn Shell than I should have done. I know that you can search in the PDF’s themselves but that is more laborious when there is a number of files to search rather than just the one. I suppose that the likes of O’Reilly prefers you to buy paper copies of its books for more extensive use, and they have a point, but having the electronic version all in one file does make life so much easier.

Having been on a web building journey from Geocities to having a website with my own domain hosted by Fasthosts, I should come as no surprise that I have encountered a number of tools and technologies over this time and that my choices and knowledge have evolved too. I’ll muse over the technologies first before going on to the tools that I use.

Technologies

XHTML

When I started building websites, HTML 4 was not long in existence and I devoured most if not all of Elizabeth Castro’s Peachpit Visual Quickstart guide to the language in a weekend. Having previously used fairly primitive WYSIWYG tools like Netscape Composer and Claris Home Page, it was an empowering experience and the first edition (it’s now on its third) of Jennifer Niederst Robbins’ Web Design in a Nutshell took things much further, becoming something of a bible for a number of years.

When it first appeared, XHTML 1.0 wasn’t a major change from HTML 4 but its stricter more XML compliant syntax was meant to point the way to the future and semantic mark up was at its heart at least as much as it was for HTML 4. XHTML 2.0 is on the horizon and after the modular approach of XHTML 1.1 (which I have never used), it will be interesting to see how it develops. Nevertheless, there is a surprising development in that some people are musing over the idea of having an HTML 5. Let’s hope that the (X)HTML apple cart doesn’t get completely overturned after some years of relative stability. I still bear scars from the browser wars raging in the 1990’s and don’t want to see standards wars supplanting the relative peace that we have now. That said, I don’t mind peaceful progression.

CSS

Only seems to be coming into its own in the last few years and is truly an amazing technology in spite of the hobbles that MSIE places on our ambitions. CSS Zen Garden has been a major source of ideas; I wouldn’t have been able to customise this blog as much as I have without them. I was an early adopter of the technology and got burnt by inconsistent browser support; Netscape 4 was the proverbial bête noir back then, fulfilling the role that MSIE plays today. In those days, it was idea of controlling text display and element backgrounds from a single place that appealed. Since then, I have progressed to using CSS to replace table-based layouts and to control element positioning. It can do more…

JavaScript

Having had a JavaScript-powered photo gallery before my current Perl-driven one, I can say that I have definitely sampled this ever pervasive scripting language. Being a client side language rather than a server side one, it does place you rather at the mercy of the browser purveyors and it never ceases to amaze me that there is a buzz around AJAX because of this. In fact, the abundance of AJAX cross-browser function libraries is testimony to need for browser-specific code. Despite my preferences for server-side scripting, I still find a use for JavaScript and its main use for me these days is to dynamically control CSS elements to do such things as control the height of a page element or whether it is shown or not. Apparently, CSS may get some dynamic capabilities in the future and reduce my dependence on JavaScript. In the meantime, Jeremy Keith’s DOM Scripting (Friends of Ed) will prove as much of an asset as it has done.

XML

These days, a lot of the raw data underlying my personal website is stored in XML. I did try to dynamically transform the display of the XML into something meaningful with CSS and XSLT when I first scaled its dizzy heights but I soon resorted to other techniques. Browser support and the complexity of what I required were the major contributors to this. The new strategy involved two different approaches. The first was to create PHP/XHTML pages from the precursor XML off-line and this is how I generate the website’s directory pages. The other one is to process the XML as text to dynamically supply an XHTML page as the user visits it; this is the way that the photo gallery works.

Perl

This still powers all of my photo gallery. While thoughts of changing it all to PHP linger, there is a certain something about the Perl language that keeps it there. I suppose it is that PHP is entangled in the HTML while Perl encases the whole business and I am reasonably familiar with its syntax these days which is why it still does a lot of the data processing grunt work that I need.

PHP

PHP is everywhere these days, though it doesn’t attract quite the level of hype that used to be the case. It still appears with its sidekick MySQL in many website applications. Blogging software such as WordPress and content management systems like Drupal, Mambo and Joomla! wouldn’t exist without the pair. It appears on my website as the glue that holds my visitor directories together and is the processing engine of my Wordpress blog. And if I ever get to a Drupal element to the site, by no means a foregone conclusion though I am spending a lot of time with it at the moment, PHP will continue its presence in my web site scripting as it powers that too.

Applications

Macromedia HomeSite

I have a liking for hand coding so this does most of what I need. When Macromedia (itself since taken over by Adobe, of course) took over Allaire, HomeSite sadly lost its WYSIWYG capability but the application still soldiers on even though Dreamweaver offers a lot to code cutters these days. Nevertheless, it does have certain advantages over Dreamweaver: it is a fleeter beast to start up and colour codes Perl syntax.

Macromedia Dreamweaver

There was a time when Dreamweaver was solely a tool for visual web page development but the advent of Dreamweaver UltraDev added server side development capabilities to the Dreamweaver family. These days, there is only one Dreamweaver version but UltraDev’s capabilities still live on in the latest version and I would not be surprised if they were taken further in these database-driven times.

Nowadays, Dreamweaver isn’t an application where I spend a great deal of time. In former times, when my site was made up of static HTML pages, I used Dreamweaver a lot even if its rendering capabilities were a step behind the then current browser versions. I suppose that it didn’t fit the way in which I worked but its template driven work flow would have been a boon back then.

However, my move from a static site to a dynamic one, starting with my photo gallery, has meant that I haven’t used it as much since then. However, with my use of PHP/MySQL components on my site. its server side abilities could get a the level of investigation that its PHP/MySQL capabilities allow.

Altova XMLSpy Professional

Adding MySQL databases to my web hosting costs money, not a lot but it could be spent on other (more important?) things. Hence, I use XML as the data store for my photo gallery and XML files are pre-processed into XHTML/PHP pages for my visitor directories prior to uploading onto the server.

I use XMLSpy to edit and manage the XML files that I use: its ability to view XML in grid format is killer feature as far as I am concerned and XML validation also proves very useful; particularly with regarding to ensuring that DTD’s and XML files are in step and for the correct coding of XSLT files. There are other features that I need to explore and that would also take my knowledge of the XML further to boot, not at all a bad thing.

Saxon

For processing XML into another file format such as XHTML, you need a parser and I use the free version of Saxon to do the needful, Saxonica offer commercial versions of it. There is, I believe, a parser in XMLSpy but I don’t use it because Saxon’s command line interface fits better into my work flow. This is a Perl-driven process where XML files are read in and XSLT files, one per XML file, built before both are fed to Saxon for transforming into XHTML/PHP files. It all works smoothly and updating the XML inputs is all that is required.

AceFTP

If I were looking for an FTP client now, it would be FileZilla but AceFTP has served me well over the last few years and it looks as if that will continue. It does have some extra features over FileZilla: transfers between remote sites, and scheduling, for example. I have yet to use either but they look valuable.

Hutmil

In bygone days when I had loads of static HTML files, making changes was a bit of a chore if they affected every single file. An example is changing the year on the copyright message on the page footers. Hutmil, which I found on a magazine cover-mounted disc, was a great time saver in those days. Today, I achieve this by putting this information into a single file and get Perl of PHP to import that when building the page. The same “define once, use anywhere” approach underlies CSS as well and scripting very usefully allows you to take that into the XHTML domain.

Apache

Apache is ubiquitous these days and both the online and offline versions of my site are powered by it. It does require some configuration but it is a very powerful piece of kit. The introduction of 2.2.x meant a big change in the way that configuration files were modularised and while most things were contained in a single file for 2.0.x, the setting are broken up into different files in 2.2.x and it can take a while to find things again. Without having it on my home PC, I would not be able to use Perl, PHP or MySQL. Apart from this, I especially like its virtual site capability; very useful for offline development.

WordPress

My hosting supplier offers blogs on Blogware but that didn’t offer the level of configuration that I would have liked. It is true that this is probably true of any host of blogs. I can’t speak for Blogger but Wordpress.com does have its restrictions too. In order to make my hillwalking blog fit in with the appearance of my photo gallery, I went popped over to WordPress.org to download Wordpress so that I could host a blog myself and have maximum control over its appearance. WordPress supports themes so I created my own and got my blog pages looking as if they are part of my website, rather than looking like something that was bolted on. Now that I think of it, what about WordPress supporting user created themes? I support that there is the worry of insecure PHP code but what about it?

MySQL

I am between minds on whether this is a technology or a tool. The SQL language certainly would be a technology but I am not so clear on what MySQL would be. In any case, I have classed it as a tool and a very useful one at that. It is the linchpin for my WordPress blogs and, if I go for a content management system like Drupal, its role would surely grow. While I do have a lot of experience with using SAS SQL and these helps me to deal with other varieties, there is still a learning curve with MySQL that gets me heading for a good book and Kofler’s The Definitive Guide to MySQL5 (Apress) seems to perform more than adequately in this endeavour.

Paint Shop Pro

As someone who hosts an online photo gallery, it won’t come as a surprise that I have had exposure to image editors. Despite various other flirtations, Paint Shop Pro has been my tool of choice over the years but it is now set to be usurped by a member of Adobe’s Photoshop family. Paint Shop Pro does have books devoted to it but it seems that Photoshop gets better coverage and I feel that my image processing needs to be taken up a gear, hence the potential move to Photoshop

If you ever go into a bricks and mortar newsagent and peruse its shelves with an eye out for references to data imaging software, you might find Adobe’s Photoshop as predominant there as it is in the digital imaging world. And the same trend seems to continue in to the bricks and mortar bookshops as well. Online, especially within the vaults of Amazon, it is not as much a matter of what gets stocked as what gets published and my impression is that the bias, if that’s the right word, continues there. That said, I didn’t realise until recently that Elsevier’s Focal Press has been covering Paint Shop Pro, once branded the poor man’s Photoshop, from at least version 7. That discovery, if it had come earlier, may have made a big difference to how I have been using PSP. That said, I have seen some opinions that PSP is easy to use and that may explain the lack of attention from publishers. Future Publishing did put out a monthly guide to PSP but that seems to have disappeared from the shelves and it does lend weight to that argument. Or it could have been Corel’s purchase of JASC that changed things…

Of course, without books and magazines, it is not as easy to see the possibilities and it is here where Photoshop really scores. The digital photography revolution has ensured the software’s escape from the world of computing and the digital arts into photography magazines and beyond. These days, even conventional photography titles feature Photoshop how-to articles. In fact, such is the level of digital content in titles such as Photography Monthly, Practical Photography and Outdoor Photography that you hardly need to pursue the specialist digital photography titles at all.

Speaking of photography, this is and has been my main use of digital imaging technology, be it the scanner that I use for digitising the output of my efforts in film photography or processing RAW files from my digital SLR. I have been using scanners since 1998 and am on my second, a CanoScan 5000F. The colour rendition in the output from its predecessor, a UMAX 1212U, deteriorated to the point where a replacement needed to be sought. As it happened, the Canon proved to be light years ahead of the UMAX, even with the latter operating properly. Incidentally, my first scanning outing was in the then current version of Photoshop (I booked some time on a scanner at the graphics centre of the university I was attending at the time and sneaked in the scanning of a photo with the journal graphic that I needed to do) - a limited affair, it has to be said - but I then reverted to things like Corel PhotoPaint and Paint Shop Pro. And PSP was what I was using in the main even after encountering the copy of Photoshop Elements 2 bundled with my EOS 10D. Elements’ cloning capabilities did tempt me though and I did acquire a Focal Press volume on the application but I somehow never took it further.

At the end of last year, Corel and Adobe launch new versions of PSP and Elements, respectively. That got me tempted by the idea of giving the whole business another look, this time in detail. My look at PSP XI regrettably suffered from the lack of time that I could devote to it and seeing what a book on it might have to say. I had more of a chance with Photoshop Elements and came away impressed with the way that it worked. Since then, I have been making my way through Scott Kelby’s latest Elements book and the ideas are building up. At the same time, I have been making good use of a Photoshop CS2 try-out and I am on the horns of a dilemma: do I splash out on CS2, do I get Elements 5 or do I await the now imminent CS3? You’ll notice that PSP doesn’t feature here; the amount of literature pertaining to Photoshop simply is too much to ignore and I have loads more to learn.