Posts tagged with 'web'

Clarifying Javascript-PHP communication using JSON-RPC

I think of myself first and foremost as a PHP developer but serious sites are getting more and more JS-heavy as time goes on so it gets harder (and less pragmatic) to try and avoid dealing with JSPHP communication of some sort.

I'm a big advocate of RESTful design so tend to end up attempting to write scripts that do lots of GETs and POSTs (as appropriate) and parsing out whatever custom response format I've decided JSON requests will return. It feels good - like I'm sticking to my principles and 'doing it right' but it's a long painful slog that can feel like self-flagellation at times.

It's also slow and hard to prototype - it's hard to argue in favour of some abstract design idea when it's making you take forever to generate simple tasks . Sometimes when I feel lazy what I really want is a way of calling my PHP objects directly from the JS and not worrying about what's happening in the underlying HTTP, and that's what JSON-RPC provides.

In this blog I'll be showing some simple examples of JSON-RPC in action but first let's look at the pros and cons.

Wag.gd - short URLs with a point

Short URLs are a bit of a hot-button topic amongst devs - some think they're useful (like Russell), some are wary of them (like me) and some, like my friend Simon, rail against them as a waste of time and resource.

Simon, however, is a sensible sort so rather than just making lots of noise about how they suck, he's gone away and tried to think of a sensible use case, then implemented it.

So take a look over at Wag.gd if you're interested in mobile development. Simon's written about it far better than I could and it's certainly an interesting idea.

FoWA London 2009 Round-up

FoWA London

I was lucky enough to go along to FoWA this week with a couple of my colleagues, so I thought I'd do a quick round-up of the two days.

I really enjoyed the conference overall - Kensington Town Hall was pretty adequate for the size of conference, the afterparty at Orchid on the Thursday was fairly epic, and the talks left me really energised about the state of web applications in general. The only slight blot on the whole thing was the terrible state of the WiFi, which was unusable on the first day and pretty flakey the second.

Rather than going through it in strict chronological order I've grouped the talks into broad themes. When the videos turn up online I'll try and link them through.

XHTML not dead, despite reports

With the W3C's recent announcement that work on XHTML 2.0 is not being continued, it would be tempting to think that the HTML vs XHTML war has been 'won', and not by the side a lot of people wanted.

However, that's a misconception. XHTML is alive and well as part of HTML5, on more or less equal terms with 'plain' HTML. It's just not going to be replacing 'tag soup' any time soon unless people start using it!

I'll be taking a look at the options authors have for producing XHTML markup, but lets first look at why someone might want to use XML.

Pros and cons of XHTML

Using Twitter as a voting platform

Cast of Star Trek

Like a lot of other people, I've had a love/hate relationship with Twitter. At first I didn't see the point - it was just Facebook without the features, then I drank the kool-aid, and fell in love with its simplicity and openness. Nowadays I've backed off a bit and see it as an interesting social phenomenon that I enjoy being a part of. I'd been meaning to check out the Zend_Service_Twitter PHP library for a while, but hadn't really thought of an excuse.

A few weeks back I was unlucky enough to watch Star Trek V and tweeted about how crap it was, despite my friend Nick thinking it's the best of the lot. There was a bit of back and forth, so I posted an order for the films, from best to worst. A few of my friends then did the same, with the hashtag of #startrekrank as a way of identifying the posts.

It struck me that I could somehow aggregate these results using the Twitter API, so I present to you, StarTrekRank.com!

Webmasters: opt out of Phorm now!

I just got the following email:

"Thank you for your submission to the Phorm website exclusion list. If there are no obvious grounds to doubt the legitimacy of the request the URL will be blocked as soon as possible, usually within 48 hours."

You can get one too by writing an email to the Phorm opt-out address () asking them to remove their service from any and all domains you have control over. I could explain why, but it's best if you just do it first. What you'll be doing is placing a vote against a fairly insidious new marketing system that most of your users won't know how to opt out of, or even know is happening. Go on, do it before you read the next paragraph.

For years marketing companies have been offering consumers the following deal: "Give us a completely history of every website you visit, and in exchange we'll give you slightly more targeted adverts". Most people on hearing this proposition don't really see what's in it for them, and decline. Basically, the price in privacy is worth far less to most people than some idea of amazingly personalised advertising.

Make all your sites work in IE8 with one fell swoop

At work we have around 100 sites hosted for clients, some of which might not have been updated in a few years (I should point out these are sites we develop, so there's no chance a client's going to edit the site themselves). IE8 is going to be rolled out to Windows users with Automatic Updates enabled as of next week, so there's a small worry about auditing these sites in time.

When IE7 came out we had to spend the time going through each of them manually and checking everything was fine. This time around, although IE8 has a new rendering model, it's possible for the browser to render pages as if it was IE7. In general this has been hugely controversial, but for people in our situation it's pretty handy.

The easiest solution to having sites that may not work in the IE8 renderer is 'do nothing'. IE8 has a compatibility button that a user can press that renders the page as if it's IE7. If enough users press this button, a scary centralised Microsoft database marks you as a naughty site and from then on, IE8 users get to see you in 'compatibility mode' until some time in the future when you fix your site and manage to persuade Microsoft that you should be let back in to the halls of the worthy.

However that sounds like a mess, relies on users jumping through some hoops, and might be a bit tricky to get off the list at a later date. The strategy we've decided to go for is to explicitly mark all our sites as needing to be rendered in compatibility view, then turn this off for each site in turn as they're audited, at our leisure.

Rev-canonical should be handled with care

A short while back, Google and a bunch of other search engines launched @rel="canonical", a standard for specifying that the current page is a copy of another, more canonical, version hosted elsewhere. I blogged about it at the time , and generally approved of the idea but warned against overuse when an HTTP redirect might be more sensible.

Recently there's been a large amount of discussion about @rev="canonical" , a proposal that seems to have been floated with the intention of providing URL shortening services. The idea is that my page can 'advertise' some other URLs that it can be found at so that clients can pick a different one to use when referring to it.

In this particular use case I could publish a page at http://ciaranmcnulty.com/blog/2009-04-14/a-long-blog-post-with-a-complex-url that had a @rel="canonical" link to http://ciaran.ws/complex (I don't really have that domain, don't bother trying it). Applications that wanted a shorter URL for the content (e.g. Twitter clients, SMS gateways) could then use my shorter URL rather than having to get a more obfuscated one from TinyURL or somewhere similar.

The number of sites that have already included the markup is staggering in such a short time, and a testament to how a simple markup idea like this can really take off (if only Microformats could gain this kind of uptake!). I've been reading a lot of the commentary that's bouncing around the HTML blogosphere, and thought I'd put my £0.02 in. Frankly, I fail to see the point of all the hooh-hah, for the following reasons:

Converting HTML to PDF using wkhtmltopdf

I blogged a while back about delivering pages as PDF using PHP, and at the time DOMPDF seemed to be the best-of-breed package for converting HTML into PDF for the purposes of delivering PDF versions of web content.

However, I noted at the time that DOMPDF's last release was in July 2007, and it still doesn't look like being updated any time soon. The fundamental problem with packages like DOMPDF is that they tend to implement their own rendering engine. The thing is, HTML and CSS are both pretty huge now - writing a rendering engine that can cope with all the different combinations is a huge task, so projects like DOMPDF end up missing out important bits of functionality.

A better approach would be to use an existing rendering engine from a browser, and then build a binary around it that can take a website as input and produce a PDF as output. That way you can get results consistent with how browsers would print a page and if you pick the right engine you'll not have to keep up with any changes to HTML standards, the engine developers will do that for you.

This is essentially the approach wkhtmltopdf takes: it extracts the open-sourced Webkit renderer used inside browsers like Safari and Chrome and bundles it up into a Linux CLI application which produces some pretty impressive results.

Simplifying file operations using PHP stream wrappers

When I took the Zend certification exam, one of the areas I really wasn't very clear on was PHP's stream wrappers. Since reading up on them for the exam, I've been kicking myself for not using them before, the amount of simplification they allow for common code is ridiculous.

As an example, a colleague recently showed me some code he'd written that downloaded a .dat.gz file from a remote server, saved it to disk, unzipped it and save the expanded contents into a file. The original code he showed me was similar to the following (with a lot more error checking and comments):

<?php 

$tempfile 
tempnam(sys_get_temp_dir());

// get the file from FTP to local disk
$fh ftp_connect('ftphost.com'21);
ftp_login($fh'username''password');
ftp_get($fh,$tempfile'/path/to/file.dat.gz');
ftp_close($fh);

// read data from local .gz into var
$gh gzopen($tempfile'r');
$data gzread($gh1000000);
gzclose($gh);
unlink($tempfile);

// write data to local .dat
file_put_contents('/local/copy/of/file.dat'$data);

The first thing to note is that the ftp functions have an underscore in, while the gz functions don't. To me at least, this makes it almost impossible to remember without constantly referring to the reference. The second thing to note is that by downloading the file to disk first, then reading it into memory, then writing it to disk, we're doing a three-step process.

Rel-canonical should be handled with care

Something we've been telling clients for years is to not publish the same information in more than one place. There are many reasons for this from the point of view of web semantics, but the one that makes the clients listen is when we say that Google will penalise their site for it.

As of today Google allow duplicate content as long as you indicate clearly which version is the canonical one. This entails adding something like the following to the HEAD element in your duplicated page, pointing back to the original:

<link rel="canonical" href="/the-other-page" />

This approach has been welcomed by many, but I'm fearful that it is duplicating already-existing web semantics as well as encouraging bad habits in web authors.

Embedding third-party content in your site using oEmbed

There's a whole class of 'Web 2.0' technologies that have emerged recently which have some common features: They solve a simple problem, they do so in a decentralised way and they stay simple. As examples I'd quote things like XFN, OpenID, oAuth and even things like RSS and Atom feeds. They start off by solving a particular use case, and stay as simple as possible (or at least should - I'm looking at you OpenID).

The latest such technology to interest me is oEmbed, via a blog post by Ben Ward. The name is a bit cryptic, but the use case it addresses is one of embedding content from one site into another. That may sound like something esoteric, but just looking back over the handful of blog posts I've done on this very site, a large number of them contain images from Flickr. Looking around the web as a whole people are constantly embedding videos and images from sites all around the web into their forums, blog posts and CMSes.

There are a couple of ways this is normally done in the wild, neither of which are that satisfactory.

  1. The site the content is hosted on generates a snippet of HTML - From looking at a page with the content on, a couple of clicks will give the user some HTML that they can copy and paste into their HTML editor. This is ok for people who are happy with HTML and actually have the ability to edit the HTML in their posts rather than using some sort of WYSIWYG, but can be confusing for novice users. This technique also limits the ability of the receiving site to reformat the content to fit into any existing templating.
  2. The site the content is hosted on gets screen-scraped - Some blogging platforms and CMSes know how major sites like Flickr or YouTube structure their HTML so are able to extract images and videos from just a URL. This of course falls down if the HTML changes significantly, and if you're trying to post content from a site your platform doesn't know about, you're out of luck.

Of the two existing solutions, the second has the best user story. The user clicks an button, pastes in a URL to the content on another site, and the patform slurps up the content, reformats it to fit in with any house styles and inserts it into the content area. What's needed is a way to do this in a decentralised way, which is where oEmbed comes in.

How oEmbed works

Keeping your Javascript clean

I've been doing a bit more Javascript recently, specifically using Prototype AJAX stuff with Google Maps ,and I've come up with a few guiding principles that have helped me keep stuff neat and tidy. I thought I'd share them with you, my handful of readers.

SCRIPT tags should live inside HEAD

There are very few reasons for having SCRIPT tags inside the document body. The main one, use of document.write() nearly always leads to ugly code. It's also not actually allowed in XHTML, despite most browsers accepting it as long as the page is delivered as text/html.

Furthermore, SCRIPT in the document body is in my opinion always the result of a perceived problem that's actually the result of poor architectural choices.

How much of your data is available online?

One of the emergent web technologies I'm very interested in is the Microformats project, a set of ways of making data embedded in HTML documents machie-readable.

Two of the most widely adopted Microformats are hCard and XFN.

hCard is a standardised method for marking up contact data. the point of it is that if all sites mark up contact data the same way, it's easier to parse.

XFN is all about the relationships between sites, and one of its key features is that it allows you to identify that a set of online profiles all belong to the same person (if they've voluntarily linked them).

Delivering pages as PDF using PHP

HTML is great. It's the lingua franca of the web, and a fantastic format for exchange of hyperlinked information. However, it has its drawbacks - It typically relies on multiple external files, different browsers interpret it in different ways, and printing it is a bit of a minefield, even with the limited print CSS currently available.

So, sometimes it makes sense to present documents as a PDF as well. I've done so on this very site, with my CV, after finding that most recruitment sites won't except an HTML document, and recruiters just get confused when you attach one to an email (or send them a hyperlink).

The component I use is called dompdf. At its heart it is an HTML->PDF converter written completely in PHP, and is pretty simple to use. The code to convert some HTML to a PDF looks something like this:

<?php

// include in the dompdf library
require_once('dompdf_config.inc.php');
spl_autoload_register('DOMPDF_autoload');

// instance dompdf
$dompdf = new DomPDF();
$dompdf->set_paper('a4');

// tell the user-agent to expect a PDF
header('Content-type: application/pdf');

// load the HTML, convert it to PDF and output
$src file_get_contents('document.html');
$dompdf->load_html($src);
$dompdf->render();
echo 
$dompdf->output();

?>

Optimising a site for iPhone

Screengrab of my site on iPhone

The unmodified site

The first thing I should probably mention is that yes, despite saying I wouldn't, I got an iPhone 3G relatively soon after release. I'll skip the reasons why for now, that's for a future posting. Naturally the first thing I did upon getting my iPhone was to plug in my own site's URL into the browser and see how it did - you can see the result in the screengrab.

You know what - it's not bad. The site looks roughly as it should, and with a bit of zooming and panning around all the content is accessible. However, on first load the text isn't really legible and it's not making the best usage of the limited screen space on the iPhone. Also, the large header graphic makes loading a bit strenuous over an EDGE connection when I'm not in 3G coverage.

Simon has been blogging recently (here and here), about 'mobilising' websites (and has written a good article on the subject for php|architect) so it's something I've been thinking about lately and I decided to see what it would take to improve the way the page was rendered on iPhone.

A new comments system

I've made a little comments system for this blog, and it gave me a chance to look a bit more into Doctrine.

I keep meaning to blog about how I put this site together, but for now I'll just say that it uses Zend Framework for MVC, with Doctrine for the ORM. To implement the comments form I used a great bit of code from CodeUtopia, written by Jani Hartikainen (a.k.a. 'zomg' on IRC) that ties together Doctrine objects and Zend_Form in quite a nice way.

I'm hoping to do a quite simple tutorial about how to implement a small blog, but that's for another time when I'm not busy revising for my ZCE!

Fire Eagle - Yahoo's location service

Yahoo! recently launched a beta of their new Fire Eagle service and thanks to the kindness of Simon I managed to snag an invite code.

Screen grab of the main Fire Eagle page

The main Fire Eagle page

The simple concept behind Fire Eagle is that it's a web service that stores your geographical location. That's it. There are no other fancypants features to get in the way of the central message, everything else is left as an exercise for third parties.

Like Twitter, Fire Eagle straddles a blurry line between a website and an API. The site itself offers very little - a box to write your location in, and a map showing the last known location (see picture).