A Ghost is Born

Ghost opened to the public yesterday—on Canadian Thanksgiving Monday, no less!— so I naturally downloaded it and gave it a spin.

It’s been available to Kickstarter backers for a few weeks now (or months?) so there’s lots of press out there already. Almost all of the stuff I’ve read has been overwhelmingly positive, and for good reason. Ghost is already a well packaged product: the branding, the marketing, the single-minded vision (to be a blog), to say nothing of the software itself (it looks great).

I read a great piece from Michael Bastos yesterday talking about the intersection of WordPress and Ghost. He does a great job of outlining where both are in the market and where they’re likely to collide and/or benefit from each other. I agree with almost all of what he says. But while using Ghost yesterday for the first time, I wasn’t struck by how full-featured it was, or how it could develop into a “WordPress killer” as some are saying. What I was struck by was something unexpected.

I was struck by the speed and responsiveness. Having Javascript at its core, I was certainly expecting Ghost to feel somehow different, I just wasn’t sure how. But after a few clicks around the admin area, it felt wildly different than anything else I’ve used. Pages loaded instantly when you clicked. No waiting, no progress bar, nothing. Just click and then there’s the page — instantly.

Going back to a WordPress project after playing with Ghost for a half-hour or so, felt like I was taking a real step backwards. I could feel the WordPress pages loading. I’d click a menu item and wait a noticeable amount of time before the page loaded. It wasn’t unbearable or sluggish by any means, but it really was different. Of course I understand that a page load in WordPress involves much more than one in Ghost, and that their underlying technologies are very, very different, but still.

The whole time I was playing with Ghost yesterday, it felt that this was where WordPress could stand to benefit most. As more and more of WordPress slowly morphs into Javascript, we’ll eventually get to a stage where WordPress behaves this quickly and responsively. This is what makes working with WordPress that much more exciting.



It means I am an idiot

As a hobby, I build a content management system. I build it at night. I am aware of what it means to write a content management system in my spare time. If you are not aware of what that means, it means I am an idiot.

Paul Ford, my favourite writer of things online

Passing PHP variables to Javascript with wp_localize_script()

I’ve been using jQuery Backstretch in projects for a long time now. I love it. It’s so simple to use, and works perfectly. To use it on your site, you just:

1. Download the file—regular version or minified version, doesn’t matter which—and put it in your theme files’ /assets folder or /js folder, or wherever you put your scripts

2. Enqueue the Backstretch file in functions.php, like so:

function waterstreet_scripts() {
 wp_enqueue_script( 'backstretch', get_template_directory_uri() . '/js/jquery.backstretch.min.js', array( 'jquery' ), '', true );
add_action( 'wp_enqueue_scripts', 'waterstreet_scripts' );

Have a look at the Codex if those parameters don’t make sense to you.

3. Now that Backstretch is properly included in our theme, we can write our own scripts.js file and set a background image for stretchin’. That file might look something like this:

jQuery(function($) {

Ok, so all that’s cool. We’ve added Backstretch and called it with our own scripts file and told it about the background image we want to use. But have you noticed the problem? I’ve hardcoded the path to the file. I develop locally, so that line in my local file will look lit this:


It’s happened to me about 10,000 times now that I will send a client a first draft of a site and they’ll say — Hey! I though we were going to put an image in the background? So then, I’d need to go in and remove the link to my localhost site and add the the live site url—again, by hardcoding it. It should be easier than this. Good news is that it doesn’t need to be this way!

wp_localize_script() to the rescue!

To make a long story short, I just want to be able to use something like site_url(); in my Javascript file so I don’t have to hardcode the url every time—but, of course, I can’t. What I can do, however, is set site_url as a parameter in PHP that I can use in my Javascript via wp_localize_script().

Now, that enqueue file will look something like this:

function waterstreet_scripts() {
	wp_enqueue_script( 'backstretch', get_template_directory_uri() . '/js/jquery.backstretch.min.js', array( 'jquery' ), '', true );

/* Make site url available to JS scripts */

$site_parameters = array(
	'site_url' => get_site_url(),
	'theme_directory' => get_template_directory_uri()
wp_localize_script( 'scripts', 'SiteParameters', $site_parameters );

add_action( 'wp_enqueue_scripts', 'waterstreet_scripts' );

And hence, instead of hardcoding the path to the file in the Backstretch file, I can now simply use the parameter I just setup:


wp_localize_script() is extremely handy for this. Any time you need to reference a PHP variable in a Javascript, you can just go back and add it to the $site_parameters array. You will hardcode no more!

How much am I worth?

I was listening to episode #82 of the ShopTalk show today when an answer to a question about salary vs creativity caught me completely by surprise. The guy was basically asking: should he stay at his current job with lots of creative freedom and less money or move to a more “corporate” job for more money and less creative latitude.

Now to the part that caught me by surprise — Chris answered the question by suggesting that this guy could probably have both if he lived somewhere like San Francisco:

Just in my experience in living in the San Francisco area for a while. […] I feel like that’s the base level out there [$100, 000]

That’s a terrible quote, but it captures what Chris was saying. You can listen to the whole answer for better context. Still, Chris was suggesting that $100,000 was pretty-well a base salary for a normal (“non-rockstar”) developer. Does this sound absurd to anyone else? Can a front-end developer make $100,000 doing front-endy things in SF? I recognize that $100k doesn’t get you all that far in a city with enormous living costs, but still.

So it raised the question for me.

How much am I worth?

I’ve developed lots of client sites over the years. I try and stay current, I’m at probably an intermediate-level with PHP/WordPress and Javascript, I’m a reasonably good designer, I do the whole responsive thing. I use Git. Etc. I’m no “full-stack engineer” by any stretch, but I can certainly take a fairly complex project and turn it into a fully-functioning WordPress site.

Is there some upside-down universe out there (SF maybe?) that would pay me $100,000 dollars a year to do this? In less crazy cities, this figure would obviously be reduced, but what are they paying? What does this person make in Chicago? Toronto? Vancouver? Dallas?

Is San Francisco upside-down, or are people actually making similar money out there in normal cities? Just curious. Send me a note on Twitter if you have any thoughts.


Rethinking Mail with SmartMail

Photo:William Selman

We’ve lived in our house for five years now. In that time, we’ve had all sorts of things come in the mail: boots, jeans, coffee makers, cameras, computers, watches, Christmas gifts from mom and dad, etc. Lots of stuff.

I suspect that we’ve had at least 40-50 packages delivered to our door in the last five years — that’s roughly ten per year or one per month or so. Of course, when I say “delivered” I don’t actually mean delivered. Only maybe 5 of the 50 packages were actually delivered. For all the rest, I’d receive a notification on the door that someone came by and tried and failed to deliver the package because we weren’t home, and we’d eventually go to the depot across town and pick it up.

This happens to you too. I don’t even know you, but I’m certain this happens to you. You’re at work all day, and the delivery people are out delivering your packages all day—of course you’re not home to receive them! You couldn’t think of a more absurd way of delivering mail than the system we have now. Trucks full of packages go around to homes with no one in them, dropping off stickers to tell the homeowner that their package was here earlier, but is now available at an inconvenient location across town. Just completely absurd!

A Better Mail System

Let’s rethink the mail system for a second. Not cable bills and birthday cards from you mom—that’s separate. Let’s just think about packages for a moment:

Imagine you order a new alarm clock online from Amazon. When you go through the checkout process, Amazon collects your email address. When they hand off the package to SmartMail, they hand off that email address as well. When your package arrives in your city, it gets delivered to a central depot where you can pick it up, and you get an email telling you it’s there. No more silly trucks driving around knocking on the doors of empty houses.

SmartMail, of course, has a few pros and cons:

Mail should be cheaper. SmartMail should be able to cut out door-to-door delivery trucks completely. This will save money on the trucks, the salaries of the people driving them, auto insurance, maintenance, etc.

It would just make sense. Email me when my package arrives, and I’ll pick it up. If I wanted the package delivered to the door, I could still select UPS or Canada Post or similar in the checkout options, but if I’m 100% sure I won’t be home when they try and deliver, it would be great to be able to choose the cheaper SmartMail.

Urban centres only. To avoid getting into the issue of having to deal with local carriers, SmartMail would probably have to be urban centre only. But not everyone lives in a big city!  I know. That’s why I’ve clearly listed this in the “Con” category.


Please note: I know nothing about the mail system. Literally nothing. The only thing I know is that I find the current system a bit silly and inefficient. That said, I think this could actually work. Just imagine a much, much smaller version of Canada Post that only sent packages, and only served urban centres. Each city would need a few depots, a few delivery trucks and a few staff in each depot. Compare that with the army of people required to run the current mail systems that exist, and I think you’ll agree that a new system could work.

Given the trouble that traditional mail companies are in right now, I think SmartMail could really work.

Update: Minutes after posting this, I was told about BufferBox. Oh well. Just when you think you’ve had an original idea.