Connecting to my Amazon EC2 image (from which this site is running) from Mac Os X took ages to find out and turned out to be relatively simple with the correct information (isn’t that always the case). At first I didn’t think the builtin Mac OS X ssh could cut it so I started looking into various Mac OS X ssh clients (Fugu, RBrowser, CyberDuck etc ..) but none of those could handle the Amazon public/private key encryption. Then I started looking into using Putty on Mac OS X even though thats not available for Mac OS X (but with a little help from MacPorts). That bombed on problems with GTK1. Dang, what to do?
Archive for the ‘Webtechnology’ Category
Language based redirects using mod_rewrite
For the website of my wife’s company, www.exportmanagement.nu, I needed a simple approach to direct traffic to the proper pages based on the language preference setting of the visiting browser. It’s a very simple approach, any browser with Dutch as its language setting will be directed to the main site and any other language will be directed to a smaller, English language based, website. Luckily the swiss army chainsaw named mod_rewrite came to the rescue and the following little code fragment will do just that (placed in an .htaccess file).
Media files in Django are served through the web server and they can be served with a different url than the Django content itself. By spreading requests across multiple urls you can speed up your site because the browser will execute requests in parallel. The rule of thumb seems to be a maximum of 2-3 hostnames otherwise the added DNS requests negate the speed up effect.
Switching to WordPress
I finally succumbed to ease of use and switched from my bespoke PivotLog installation to WordPress. I thoroughly enjoyed Pivot but when switching from Textdrive to Amazon EC2 I had to change and migrate so many things that I settled for the easier solution; WordPress.
Changes to this site
As explained in one of the first posts on this blog this site is basically just one big Atom feed that gets transformed into this blog by using a bit of Apache content negotiation and client side XSLT. Besides some issues with browsers ignoring client side XSLT in a feed and forcing their own rendition of my feed which was fixed by inserting 512 bytes of crud to throw of the feed sniffing this approach has worked fine for the last four years.
Templates, template engines and PHP
In the process of developing Lilliput CMS I had to think about how to do templating with PHP. There’s a lot of material available regarding PHP and templating and most of it is really weird. Having had a look at the Top 25 PHP template engines I can’t for the life of me understand why I would want to use something like Smarty, Savant or phptal. Obviously a lot of love and attention has been poured into these solutions but I can’t escape the feeling that these template engines are recreating PHP and its innate templating function. This feeling was confirmed when reading the “Templates and template engines” article on the php patterns website.
Lies, damned lies and caching
One of the most excellent aspects of HTTP and the underpinning REST architecture is the aspect of idempotence and non-idempotence. Idempotence roughly means that some operation yields the same result whether it is done only once or several times. This behaviour forms the basis of caching because if the result is the same you can work with a copy of the result for all subsequent requests. This excellent property of the web also has some downsides as the Law of Preservation of Complexity demands that for any goodness in technology there always is a trade off in increased complexity somewhere else. In the case of caching it is determining when to cache and when not to cache.
My work for the Lilliput CMS has lead to some interesting new findings about PHP 5′s new DOM functions, particularly the XPath part of it. Whilst working on the templating structure for Lilliput I couldn’t get the DOM XPath queries to work on the file at hand, a normal XHTML 1.0 Strict document. With an external tool called XPath Explorer (XPE) every query evaluated correctly but as soon as I tried the same XPath expression in PHP it failed. After searching long and hard I came across a code snippet that contained the solution namely to explicitly declare the xhtml namespace for the DOM document you’re working on:
Building the previous blog
This blog uses used a novel approach (I think) in that it is was entirely Atom 1.0 based. There is was no underlying (X)HTML, everything is was Atom (with a hint of XSL). I came to this approach after I figured out that it is silly to serve the same content in multiple formats when one format suffices. Modern browser are perfectly capable of executing XML/XSL that allow for the transformation of the Atom 1.0 feed into XHTML. There’s some nice stuff going, let’s dig into the details (hey I’m a technologist at heart so why not busy myself with the stuff I love).