Tuesday, 27 March 2012

cardsinthepost.com - Nearly there… now what?

The Internet may not have particularly noticed or cared, but I've been inattentive recently. I've been, as they say, not all there. Physically I've continued to exist, but mentally I've been off in the Big Elsewhere.

That's right, I've been to Code Heaven - there and back again. All I've been doing for the last couple of weeks is code code code. HTML5? Yes please. CSS3 and CSS 3D? You betcha! MVC Javascript? Ooooh, yeah! Responsive design? Is there any other way? JQuery? Umm… yes, OK, that too admittedly. Let's keep a fairly low profile about that one though.

Anyhow. We're soooo nearly there. I've built a version of the front end that (so far) runs faultlessly as a browser app, allowing users to make as many personalised postcards as they like before checking out with Paypal so we can print them and pop them in the post. And Adam is tirelessly refining and tweaking his awesome Symfony2 engine for managing all this server side and submitting to the Docmail print engine. We just need to sew the two together and we're basically done.

Dev version of the site... and no, cards will not cost £33.97!

So now what?

Well, the weird thing is that the bit we've neglected so far is how to market this lovely little machine that we've built. Given that Adam and I have pretty heavyweight marketing backgrounds, it's refreshingly odd that we've not given much thought about marketing for Cards… yet.

We need a brand (not just a logo - we've got one of them). And we need a campaign. And in order to get those things right, we need to understand what people are likely to want to do with cardsinthepost.com

With cardsinthepost.com you can make and send a real postcard in the real post. You can upload a photo (or any jpeg, gif or png), you can write a message and you can add an addressee. And you can repeat until you've got all the cards you could possibly want, and then pay with Paypal. The cards are great quality, and they're posted anywhere in the world first class and Airmail.

That's it. Dead simple.

But what might people want to do with cardsinthepost.com?
  • It's an easy and super quick way to send a postcard back from holiday.
  • It's a great way to send out a party invite, thank you card, or any other personalised announcement.
  • It could be ideal for small businesses to promote themselves to prospective clients.
  • And we love the idea of letting holiday companies create their own skin on our service, providing a kiosk for sending out cards from their resort or hotel.
We reckon we'll have a fully working version in the next few days. And we'd love to get some feedback. So if you'd like to have a go with the site - maybe send a card or two, maybe let us know what you think - then we would love to hear from you.

Any comments welcome... or Tweet us @elecmal, or on our new Cards Twitter @cardsinthepost… or get in touch any other way (maybe send us a postcard?)

Saturday, 24 March 2012

Compressing JSS and CSS: results on our new web app

Our new app cardsinthepost.com (not yet released) relies heavily on modern techniques such as AJAX. Specifically it does a lot of Javascript and requires a lot of libraries. We're in the process of reducing the number and size of those, but today we wanted to see what could be done using automated techniques.

Using separate, uncompressed files

In debug mode, our app brings in each JS and CSS file seperately, uncompressed.

This is not a scientific test because in 'debug' mode the back-end is (much) slower as well as the front-end. But note the grey bars: those are 'blocked requests' i.e. the browser has opened its max sockets to our webserver (usually 6, browser dependent) and until one of those is freed up, it can't get the next file.

Also unscientific because this was also using 'jquery-ui' already minimised, meaning the filesize difference would be more significant otherwise.

Javascript

Before: JS
13 requests, 171kb, taking 13 seconds.

CSS

Before: CSS
4 requests, 10kb, taking 12 seconds (concurrent).

Note how the CSS is being blocked by the Javascript. That's a good reason to move the JS down out of the HTML head to the bottom of <body>.

Using unified, compressed files

When switched to production mode, our app combines all the Javascripts into one file and all the CSS into one file, then runs Google Closure to compress the Javascript and Yahoo's YUI Compressor to compress the CSS. It does this once during deployment and the result is normal files on the file system.

Javascript 

After: JS
3 requests, 115kb, taking 1.2 seconds.

CSS

After: CSS
2 requests, 9kb, taking 0.1 seconds (concurrent).

Results

A reduction from 17 requests to 5, from 181kb to 124kb and from 13 seconds to under 1.5 seconds.

Notes

Results exported with the wonderful NetExport plugin for Firebug.

The technologies doing the magic that haven't been mentioned are Assetic and Symfony2.

Monday, 19 March 2012

Git, Capistrano and Vagrant: a new dev/deploy technique

Here's a post on some of the 'deep geek' technical aspects of our upcoming site cardsinthepost.com.

One of the most interesting parts of this journey for me has been seeing how much things have moved on since I last did serious web dev work 5 - 10 years ago. The first thing we put in place was Git for source code control. That saves our bacon on a near daily basis. By recording every iteration of every file and providing an easy way to move back and forward between versions, it's a refreshing change from copying the entire directory before you make a major change and deleting it once you're done. Much better.

I knew we didn't want to transfer files to the server via FTP because it's insecure, and secure FTP is a bit slow and old. For a good while we pushed to a Git repo on the server (via SSH) then used post-receive hooks on the server to deploy code for testing, but that's not great because:
  • Git doesn't know or care about file ownership or permissions
  • Git, focusing on managing files, doesn't transfer empty directories. We need some ready for things like cache data.
  • Checking out the files from the repo while quick isn't instant, which leaves our application in an unknown state during the deployment process as files are copied over
Enter 'Capistrano', or the Symfony2 port of it 'Capifony'. This Rails app runs on your local machine and scripts your deployments. It plays nicely with Git because it grabs the latest files from the repo then pushes them (via rsync) to the live server. Three things about this are the reasons to bother:
  • It doesn't push direct to the live directory. It pushes to a 'releases' directory then once everything is tested successful, it updates a single symbolic link to the new release. This is instantaneous.
  • It maintains five (or however many you like) previous releases, keeps them on the live server, and can rollback the live site to any of them at a moment's notice.
  • Once it's done, it can execute any combination of scripts to finish the deployment, as if you were SSHd into a terminal on the server.
The final piece in our dream dev/deploy setup was a tip from @Zoltrain: Vagrant. This is another Rails app that uses Oracle VirtualBox to virtualise your dev server, making it portable between developers and between your own machines.

That's a massive step forward since previously I've tried to mirror our live setup on Windows 7 (no native SSH client!), Mac OS X (MAMP and not MAMP) and Ubuntu 11.10 (which isn't quite the same as Ubuntu 10.04). In every case you get it 'almost, but not quite' the same. It's those 'not quite' bits that sap hours away from feature development until you realise 'ah, that's because X is subtly different on this machine'.

Vagrant makes that a thing of the past, and that's brilliant. Whatever machine I'm on, I transfer the 800mb dev server image and can get to work. That frees me from my home webserver, so I can now extend Cardsinthepost.com from your nearest Pret, woohoo! This did need a memory upgrade (to 4GB) for my Macbook - and I'm going to switch to an SSD too.

My new Crucial 128GB SSD.
Awaiting a T-6 screwdriver for installation.
I didn't expect Virtual Reality to look like this

It seems actual files on an actual server are becoming a thing of the past. We now have a series of incremental references to bits of files (the Git repo), inside a virtual machine running a virtual operating system (Vagrant), stored on a hard disk that's really memory, that publishes to a directory that's just a temporary reference (Capifony) on a server that doesn't really exist (Rackspace Cloud).

I'm already impressed with the huge library of AMIs from Amazon that provide server snapshots that you can import and fire up as your own whenever you like, like a giant server supermarket. Maybe one day there'll be an open standard for server images where you can run them locally or spin them up as 'live' via your favourite provider? That would be excellent.

Wednesday, 7 March 2012

First cards arrive!


I know, I know. The Ferrari is mine. Well the picture of it is. Apologies in advance to those that might have imagined our first web app Cards in the Post to send much better photographs. The good news is, you can fix that. Soon*!

* As soon as we resolve a bunch of reasonably serious bugs before providing even private beta.

These were submitted Sunday and arrived Wednesday by 'standard class' mail. Latest decision is to automatically post everything first class. Because you're worth it.

Conception cannot precede execution


Art is a process of discovery through making.

Our ability to discover is generally greater than our ability to invent.

Think of your work process as a form of travel.

Look for the things you don't know, the things that are revealed or inadvertently uncovered.

It is easier to find a world than to make one.

- Conception cannot precede execution. Emphasis mine.

From the most worthwhile '101 Things to Learn in Art School'.

Tuesday, 6 March 2012

No more punctures with airless tyres

Now this isn't the sort of invention we're normally interested in. A bit too real world for our usual tastes.

But when my car got stolen a couple of weeks ago, and the really crappy courtesy car we got from our insurance company got a flat tyre a couple of days after we received it... well, I guess my level of interest in tyres changed.

So here's something clever: airless tyres.

Apparently they've been in development since 2006 or earlier. (They were originally called the "twheel"... hmm, wonder if that'll ever take off? ...OK, now stopped wondering: because, no it won't.) Car conspiracy theorists will love the reason why they've mysteriously lacked investment. Apparently the police and the military in the US have blocked investment because airless tyres can't be shot or burst at roadblocks.