Technology Tales

Tidying dynamic URL’s

15^th June 2007

A few years back, I came across a very nice article discussing how you would make a dynamic URL more palatable to a search engine, and I made good use of its content for my online photo gallery. The premise was that URL's that look like that below are no help to search engines indexing a website. Though this is received wisdom in some quarters, it doesn't seem to have done much to stall the rise of WordPress as a blogging platform.

http://www.mywebsite.com/serversidescript.php?id=394

That said, WordPress does offer a friendlier URL display option too, which you can see in use on this blog; they look a little like the example URL that you see below, and the approach is equally valid for both Perl and PHP. Since I have been using the same approach for the Perl scripts powering my online phone gallery, now want to apply the same thinking to a gallery written in PHP:

http://www.mywebsite.com/serversidescript.pl/id/394

The way that both expressions work is that a web server will chop pieces from a URL until it reaches a physical file. For a query URL, the extra information after the question mark is retained in its QUERY_STRING variable, while extraneous directory path information is passed in the variable PATH_INFO. For both Perl and PHP, these are extracted from the entries in an array; for Perl, this array is called is $ENV and $_SERVER is the PHP equivalent. Thus, $ENV{QUERY_STRING} and $_SERVER{'QUERY_STRING'} traps what comes after the ? while $ENV{PATH_INFO} and $_SERVER{'PATH_INFO'} picks up the extra information following the file name (/id/394/ in the example). From there on, the usual rules apply regarding cleaning of any input but changing from one to another should be too arduous.

A penchant for strange decisions?

14^th June 2007

WordPress.com has retired its Feed Stats feature. While there might have been problems with it for some, I do find it a strange decision not to spend some time on it. After all, given the existence of Google Reader and its kind, I wouldn't be surprised to learn that more people read blogs with RSS readers than by going to the sites themselves. In fact, I peruse blogs more often with Google Reader than by visiting the websites themselves. It's enough to make me wonder if I could use Feedburner with this blog.

To follow on from this, I am beginning to wonder if that Automattic, the people behind WordPress.com, seems to be a quirky company that makes decisions that are questioned by its customers. After all, they did remove the post preview functionality from blog post editing screens, and that has generated numerous comments. On self-hosted WordPress, you can add a plug-in to correct this, but that option is not open to WordPress.com users. The answer that I got to a theme change request earlier this year adds to the impression, as does seeing a company having staff apparently work from home all over the world.

Automattic seems an unconventional beast alright; could that lead to their undoing? Though it is king of the hill with blogging world for now, there is nothing to say that will last forever.

Ricoh Caplio GX100?

14^th June 2007

Ricoh Caplio GX100

Because my digital SLR has needed to be sent away for cleaning for a while now (meanwhile, I have got good at using Photoshop Elements to clean up pictures...), I have been on the lookout for a backup camera so that I can add photos to any trip reports on my hillwalking blog without having to wait for film to be processed. Previously, my eye was on Ricoh's GR Digital, but they have now introduced the award-winning Caplio GX100. The zoom range is a very useful 24-72 mm in 35 mm film terms, and that removable electronic viewfinder looks very neat. Having a 10 megapixel sensor adds to the appeal and advanced exposure modes like manual and aperture priority. The feature list has almost ensured its ousting of the GR Digital from any wish list that I might have; the only thing outstanding is seeing how it performs in a photography magazine's full test review. A thumbs up from there might even get me onto the acquisition trail...

The return of the Navigator

13^th June 2007

Netscape Navigator

With the launch of the ill-fated Communicator, Netscape dispensed with the Navigator brand that had served it so well up to that point. And it continued the practice when it turned to re-branding the output from the Mozilla project. The new Navigator is, in essence, a tweaked variant of Firefox's latest incarnation and has the spelling checking capability that I have been missing when giving Safari a spin. You have to ask why, and I am not certain that I have the answer. That said, it does feel slick and works well, a definite change from some of it predecessors then.

Safari on Windows?

12^th June 2007

Steve Jobs recently surprised an audience at Apple's Worldwide Developer's Conference with the announcement that the Safari web browser is being made available for Windows. While everyone else is awaiting Apple's forthcoming iPhone, the Safari announcement is a more important one to me; not being big on phones, I will let the iPhone excitement pass me by. Without either buying a Mac or running OS X in a virtual machine, there was no other way for me to test my web pages in Safari bar looking for a rendering site on the web. Now, that has all changed, and I have downloaded the beta to have a look; it should iron out any rough edges that Mac users have been seeing.

Update: Safari seems to have got a mixed reaction from Windows users; some have tried it with Vista and cited issues. Another gripe has been its memory footprint, but I have seen Firefox take up 100 MB.

Perl vs. PHP: A Personal Experience

11^th June 2007

Ever since I converted it from a client-side JavaScript-powered affair, my online photo gallery has been written in Perl. There have been some challenges along the way, figuring out how to use hash tables has been one, but everything has worked as expected. However, I am now wondering if it is better to write things in PHP for the sake of consistency with the rest of the website. I had a go a rewriting the random photo page and, unless I have been missing something in the Perl world, things do seem more succinct with PHP. For instance, actions that formerly involved several lines of code can now be achieved in one. Reading the contents of a file into an array and stripping HTML/XML tags from a string fall into this category, and seeing the number of lines of code halving is a striking observation. I am not going to completely abandon Perl, it's a very nice language, but I do rather suspect that there is now an increased chance of my having a website whose server-side processing needs are served entirely by PHP.

A peculiarity with PROC EXPORT

10^th June 2007

I have just encountered an issue with PROC EXPORT that I did not expect to see: it needs to run in a windowing environment. The way that I found this was that I was running a SAS macro as part of a batch job in a headless UNIX session and my program stopped dead with the job needing to be killed; that returned a message containing something about SAS/FSP and SAS/AF which does explain things. Still, this was not something that I would have expected with an export to a CSV file; the behaviour sounds more what you see with the likes of PROC GPLOT or PROC REPORT. As it happened, adding the -noterminal option to the batch command line sorted things out.

Getting one’s HTTP headers in a twist

9^th June 2007

I am in the process of further linking the content of hillwalking blog into the fabric of other parts of my website. To date, this has included adding a list of all the posts to the site map and a dossier of the latest entries to the site's welcome page. One thing that started to crop up were a series of warnings of the form:

Cannot modify header information - headers already sent by...

The cause of this was my calling a PHP script that was part of my hillwalking blog installation, and this caused Bad Behaviour to be invoked. The result was that an HTTP header was being sent to create a cookie after one already had been sent to display a web page. A spot of conditional coding and the use of an extra flag resolved the problem.

Apparently, there is another surefire way of getting the same result: whitespace before or after the <?php ... ?> tag in an included script. The cookie issue is one that I can understand, but it does seem strange that an attempt is made to send HTTP header information when the latter arises. It causes loads of questions, though...

Restrictions on SAS libraries when macro catalogs are used

8^th June 2007

When you open up a SAS macro catalogue so that its entries for use by other programs, it has a major impact on the ability to change the library reference used to access the catalogue after it has apparently been unlocked.

options mstored sasmstore=bld_v001;

Using the line above will open the catalogue for reading, but there is no way to close it to change the library reference or unassign it until the SAS session is shut down. Even this line will not do the trick:

options nomstored sasmstore='';

What it means in practice is that if you have a standard macro setting up access to a number of standard macro libraries, then that setup macro needs to check for any library references used and not try to reassign them, causing errors in the process.

Exploring AJAX

7^th June 2007

When I 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 while the browser wars were in full swing and incompatibilities reigned supreme, I went with paid hosting to get access to tools like Perl and PHP for server-side processing. Because their flexibility compared to JavaScript was a breath of fresh air to me, 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 many website builders around the same time. Nevertheless, I have still held on to 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, generating 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 seen an AJAX application lock up a PC with a little help from IE6. There will always remain times when server-side processing is the best route, even if that needs to be balanced against the client-side approach.

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 into 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, both of which 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 only for them to use ActiveX, while 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 based on this volume. It has certainly whetted my appetite for giving AJAX a go, and it’ll be interesting to see how things progress from here.

« Older Entries « » Newer Entries »