I’ve always enjoyed tinkering with this diminutive site, and lately I’ve continued the quest to improve speed and uptime while staying ruthlessly cheap about it. The result has been a switch from Statamic to a static site generator called Sculpin, along with a hesitant return to CloudFlare. It took about a month of experiments and minor breakthroughts to get there.

I quietly got around to supporting SSL for my site in late February, mostly to be a good citizen of the internet. A recent series of Webfaction outages got me thinking about ways to circumvent downtime, and I was inspired by a client’s deft use of Fastly to solve the problem. I wandered my way into some requirements for this latest endeavor:

1. Generate a static site to eliminate the need for any application caching.
2. Use a CDN for whole-site caching and global mirroring in the name speed and relative immunity from downtime, with an edge node in Seattle because I adore low pings yet will not relocate for them. (With an idealistic global page load time of <1s, and initial connects in <10ms.)
3. Switch entirely to SSL (https) URLs so PRISM has to try a little harder.
4. Keep using a bare domain without any www because it looks nice that way.

Here’s how that went.

Generating the site with Sculpin

I’ve been happily using Statamic since 2012, and it dawned on me that I don’t have any compelling reason for a CMS since I’m the sole author of a tiny, infrequently-updated site. Statamic has a static generator built in, but I figured I’d go all the way and remove the CMS from the equation. Jekyll seemed like the obvious choice, but Sculpin was a bit friendlier thanks to its reliance on Twig templates and native post tag handling.

The only roadblocks were easy to clear: I built a simple PHP form handler (hosted on a subdomain) and went through some dark URL rewriting to convince Apache to do without trailing slashes.

It also turns out that a rather critical aspect of being cacheable is asking to be cached. I’ve not always taken the time to specify cache headers, which can be a crucial mistake if a cache service is handling requests at face value. Like CloudFlare, for example, which tends not to cache HTML responses unless specifically asked to, rendering the Always Online™ feature worthless if it’s got no cached page to serve.

I used my .htaccess Apache directive to set Expires and Cache-Control values for different file types, and whipped up a shell script to publish the Sculpin site, copy .htaccess into the mix (which Sculpin otherwise leaves out), and publish it to Webfaction via rsync.

Choosing a CDN

This long journey had me comparing KeyCDN, Fastly, CloudFront, MaxCDN, CacheFly, section.io, and poking at CloudFlare again.

I could have used KeyCDN for full site caching, and it would have been really fast and really cheap with free custom SSL. Pings and TTFB to KeyCDN’s nodes were easily <10ms for most of my tests, and I would have lived with having to serve the site from a secret domain to have it pulled into a zone and served at workingconcept.com. (Pulling from workingconcept.com while serving from it created an infinite loop. Derp.) KeyCDN even offers origin shielding, which is another impressive offering from one of the least expensive CDNs around. A seemingly impatient support response confirmed what I suspected: there’d be no good way to serve the site from a bare domain. The bare domain is also called an apex domain by those with better vocabularies, and it would turn out to be the greatest challenge among my list of requirements. While I could use DNS Made Easy’s proprietary ANAME, which is kind of a CNAME living on the root A record, doing that robbed KeyCDN of its ability to distribute traffic geographically and instead served every request from its Washington D.C. node. I thought about going www and couldn’t. I contemplated living without global mirrors, and couldn’t.

So on I went to Fastly, which is a shockingly fast service built on Varnish. A client uses it for its web product, which helped me appreciate Varnish (which is like a software memory stick) and Fastly’s platform. My site would be on Fastly now if I wasn’t priced out of it for this humble blog. While I could have skated by for free with my low traffic, full SSL and whole-site caching would have been prohibitively expensive. This was confirmed by an uncommonly personable and hilarious support agent.

I’ve been using Amazon CloudFront for static assets since early 2014, and while it could have been a viable option I didn’t want to switch to Route 53 for DNS since it never seems to appear in the top tier of performance benchmarks. I generally find AWS to be a bit more slow and a bit more expensive than alternatives, even though it’s a vast wonderland of integrated services.

MaxCDN had a nice control panel, impressive speed, and a handful of nice options like the ability to designate an IP address—rather than a domain name—for a pull zone. As I learned with KeyCDN, this can make it easy to pull from the origin you’re also shielding. The lovely admin interface was littered with upsells, and an agonizing cancellation process ultimately confirmed that whole-site caching wasn’t going to be possible with a bottom-tier (cheap!) client.

CacheFly’s control panel was an uncomfortable journey back in time, and I promptly fled once I figured out that whole-site caching—or anything more than hosting static files—wasn’t going to be a good idea there.

section.io was intriguing and confusing enough that I toured it twice. It’s sort of like a scrappy Fastly, made up of various pieces that developers and ops folks would mostly likely appreciate. Where Fastly had a well-unified, seemingly polished control panel, section.io’s often left me uncomfortable and uncertain what I was getting into, even though it was clearly a flexible product aimed at fitting in with developers’ workflows. Like Fastly, it made it possible to combine Varnish with a CDN. Custom SSL would have been free, and I might have easily afforded low apex domain traffic by handing over DNS to section.io. Support was prompt, personal, and friendly, and engineers fixed an innocent DNS issue that I had as I was kicking the tires. Unlike Fastly, inexperience with Varnish may have kept me from being qualified to work with section.io. A confusing inability to cache static pages and lackluster CDN speeds led me reluctantly away.

And that’s how I returned to CloudFlare. I’ve been routinely scared away from free accounts over infuriating 522 errors, with CloudFlare blaming an unresponsive server while the server’s usually perfectly happy and healthy. I’ve had better luck with paid CloudFlare accounts using full DNS setups (as opposed to CNAME only), and Railgun is really nice when it’s an option. My tests with CloudFlare yielded heartening waterfall timings with <100ms total for a simple static page, all over the globe—from that all-important apex domain. While custom SSL wasn’t a cheap/free option, I don’t mind the shared certificate¹. I also don’t like CloudFlare’s messaging during an outage because I’d prefer that a visitor not even know the origin went offline, but at least all this thrilling content can weather a storm.

DNS Made Easy has been consistently fast and issue-free since I started using its DNS service in February 2014. But I bravely and/or foolishly left a good thing and pointed my DNS to CloudFlare.

tl;dr

I’m back on CloudFlare, finally specifying appropriate cache headers, with a completely static site served via https on a bare (apex) domain. The plan has so far succeeded, and I’m curious what my uptime will look like in the coming months.

Many of us have felt the shameful sting of committing a large file to an otherwise pristine repository. “But it’s important too,” you pleaded. “Idiot,” they snarked, begrudgingly fixing your mistake while secretly acknowledging that you had a point. Years later, we have a resolution.

I’ve been working with Git Annex thanks to GitLab’s adoption early this year. GitHub opted to support Git LFS, which I’ve only started poking at now that GitLab decided to support it, too.

But which one to use? Each will help you solve that large-file problem in a slightly different way. Think of Git Annex as an experienced librarian waiting at the information desk. You’ll need to walk up to ask your question or return your book, but the librarian can help you in a variety of ways by getting books moved around, checking up on things, and generally being a pro at cataloging stuff. Git LFS is more like your large file personal assistant, working alongside you to keep track of things you’ve pointed out.

In other words, my experience with Annex is that it’s full-featured and a bit less focused in its approach. It’s easy enough to check in files and sync them among various locations, but there are also testing tools, a web-based GUI, and lots of options you can use in different situations. The git-annex project site reveals a lot: plenty of features, updates, discussions, and enough threads that some sort of trail off.

Git LFS is at the other end of things: a bit nicer-looking, a bit more straightforward, and significantly simpler. Tack it on to your repository, tell it what kind of files to watch, and then pretty much forget about it. If you check in a file (with a normal git add whatever.mp4), the magic happens via a pre-push hook where LFS will check your watch list and spring into action if needed. It otherwise blends in after minimal configuration.

Let’s take an identical set of files and commit them using each.

Our Fake Project

A markdown file and four PNGs that we’re going to treat as large files:

• test.md
• assets/01-north-pole-daylight.png
• assets/02-plus-blue-light.png
• assets/03-night-glow.png
• assets/04-day-glow.png

Git Annex

Once git-annex is installed, we need to configure our repository to use it:

$ git annex init
init ok
(recording state in git...)

Add our one normal file as usual:

$ git add test.md

Add our images to the annex:

$ git annex add assets/*
add assets/01-north-pole-daylight.png ok
add assets/02-plus-blue-light.png ok
add assets/03-night-glow.png ok
add assets/04-day-glow.png ok
(recording state in git...)

The files are turned into symbolic links that point to data in .git/annex/objects. (You can easily undo this if you ever need to, restoring the files and getting rid of the annex.) Push it all:

$ git push origin
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 282 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)

Critically important here is that the PNG files are not yet at the origin, only symbolic links that point to them. Annex knows they’re on the local machine, but that’s the only place they exist so far. We can ask git-annex where a certain file exists:

git annex whereis 04-day-glow.png (1 copy) 
 758aaecf-f502-44be-8854-03819db671d6 -- matt@mattBook-Air.local:~/Documents/git/annex-test [here]

This can be useful while exploring and figuring out what’s going on. Now let’s actually sync the file data:

$ git annex sync --content
commit ok
pull origin 
ok

Each file will be copied with a progress report that looks like this:

copy assets/01-north-pole-daylight.png copy assets/01-north-pole-daylight.png (checking origin...) (to origin...) 
SHA256E- s1093459--12cbb85304bc084cedd0537830a09d55e3cd2224917e9faaec390b27ad7f2d98.png
 1093459 100% 126.44MB/s 0:00:00 (xfer#1, to-check=0/1)

sent 1093758 bytes received 42 bytes 128682.35 bytes/sec
total size is 1093459 speedup is 1.00
ok

Before (as seen above) and after the binary transfer, git-annex will make sure the file metadata is properly synced as well.

pull origin 
ok
(recording state in git...)
push origin 
Counting objects: 14, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (14/14), 1.08 KiB | 0 bytes/s, done.
Total 14 (delta 4), reused 0 (delta 0)
To git@gitlab.com:workingconcept/annex-test.git
 4ef0edb..a8f52cd git-annex -> synced/git-annex
ok

We can use the same trick from above to confirm that a given PNG now lives in more than one place:

git annex whereis 04-day-glow.png (2 copies) 
1d3c732a-ff9a-490e-a0c8-18ee13694c7a -- "GitLab" [origin]
758aaecf-f502-44be-8854-03819db671d6 -- matt@mattBook-Air.local:~/Documents/git/annex-test [here]

Success! It’s easy enough to clone the repository and use git annex sync --content to get everything synced up. A long list of files will go slowly since they’re transferred one at a time, but my experience has been pretty solid¹.

Git LFS

Now let’s do the same thing with LFS. Same first step, which is to invite git-lfs into the repository:

$ git lfs install
Updated pre-push hook.
Git LFS initialized.

Simple, yet hugely different: tell LFS what kind of files we’ll treat separately:

$ git lfs track "assets/*"
Tracking assets/*

In this case, everything in the assets folder. It could just as well be extensions like *.psd or *.mp4, or a handful of paths. Now let’s add everything and commit it:

$ git add .
$ git commit -m "Test commit."
[master (root-commit) 02a1537] Test commit.
 6 files changed, 16 insertions(+)
 create mode 100644 .gitattributes
 create mode 100644 assets/01-north-pole-daylight.png
 create mode 100644 assets/02-plus-blue-light.png
 create mode 100644 assets/03-night-glow.png
 create mode 100644 assets/04-day-glow.png
 create mode 100644 test.md

That’s it, no extra step. Push:

$ git push origin -u
Git LFS: (4 of 4 files) 3.95 MB / 3.95 MB 
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (9/9), 1.02 KiB | 0 bytes/s, done.
Total 9 (delta 0), reused 0 (delta 0)
To git@gitlab.com:workingconcept/lfs-test.git
 * [new branch] master - master
Branch master set up to track remote branch master from origin.

Note that LFS reported back about what it had to transfer, and that after the initialization we just go about our business as we normally would. LFS added .gitattributes to store a reference to its watched file patterns, and it jumps in and does its magic only when it needs to. Complete contents of .gitattributes:

assets/* filter=lfs diff=lfs merge=lfs -text

The second thing that LFS quietly adds to your repository is a pre-push hook. Thanks to these two things, you don’t have to interact with lfs directly like you would with git-annex. Contents of the pre-push hook:

#!/bin/sh
command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/pre-push.\n"; exit 2; }
git lfs pre-push "$@"

Feel Good Ending

So you have options. I don’t know that either one’s better, it’s just a matter of choosing what works for you and is supported by your Git host.

I’ve not gotten myself into any complex situations yet, and I’m working on converting some repositories largely by running uninit to un-annex files and remove every trace of git-annex from the repository so I can turn around and check those files in with LFS.

Let me know if you’ve stumbled upon this post with more insights, corrections, or flagrant objections!

Being concerned with word usage but somewhat lacking in vocabulary, I often find myself making up words. I know what this implies about my intelligence and can live with that part, but recently I decided that a common web development practice must have some word I don’t know.

The situation: I’m taking a flat html file and integrating it into a content management system. It’s no problem describing that task in a conversation, like "we’d like to make that page dynamic." It gets tricky when I need a concise way of listing the task among others:

• “make About page dynamic” (wordy)
• “dynamic-ify About page” (made up word)
• “dynamize About page” (will anybody know what this means?)

I took to the English Language & Usage Stack Exchange, where the question more or less flopped. There were some interesting ideas, but no legitimate English word was uncovered.

That’s why I think we should all use the word interactivate. Sure, it’s not even fully embraced by Urban Dictionary, but I think it has merit. We are, in fact, activating an otherwise static and lifeless file, much like a chemist (or wizard!) might activate inert ingredients and turn them into something more useful. The presence of interact is still important, as it correctly conveys the transition from a static thing to one that’s capable of being acted upon via the content management system.

This is all so that my little bullet can be tidy and instantly understandable:

• “interactivate About page”

Building your mobile app after solely working with wireframes and comps? Interactivate!

Making a prototype of a thing you sketched on a napkin? Why, you may just be interactivating!

Now who’s with me on this?

Using GMVault to back up Google Apps email to my Synology DS214 has been great, when it works. And it seems like it fails pretty often: software update, token expiration, strong gust of wind, etc.

My original article from April 2014 turned into a bit of a mess, but after a few reinstalls and helpful comments (thanks David and Simon) I’ve got a much shorter set of instructions:

1. Install the Python (2.7) package from the Synology package manager.
2. SSH into the Synology box as root.

3. Download and install pip:

   wget https://bootstrap.pypa.io/get-pip.pypython get-pip.py

4. Use pip to install virtualenv:

   <pre><code>pip install virtualenv</code></pre>
5. Log in as your normal user, and cd to wherever you want to install GMVault.

6. Set up a virtual environment for GMVault to run in:

   <pre><code>virtualenv gmvault_env</code></pre>
7. Install GMVault in this little environment: <pre><code>cd gmvault_env/bin./pip install --verbose --pre gmvault --allow-external IMAPClient</code></pre>

Now you can run ./gmvault from this directory, or put together scripts that reference it by full path.

If you’re like me and your backups frequently see IMAP timeouts, don’t forget to cd ~/.gmvault and edit gmvault_defaults.conf so that enable_imap_compression=False.

If you’re used to visiting this site often, and I’m not sure why you would, you probably noticed some minor changes. Over the weekend, I rebuilt my Statamic theme with Bourbon, Neat, and Bitters. This was brought about by a newfound love of thoughtbot after Darin and Scott pointed me to the lovely thoughtbot playbook. That and I was upset at some lackluster home page rendering I noticed with Safari on iOS8.

Features:

• better and more fluid mobile breakpoints
• beautifully organized Sass that you won’t see or notice
• cleaner CSS that’s also about 10KB lighter
• code sample syntax highlighting with Prism

Not yet completed:

• an interesting home page
• a focused blog with regular posts

If you’re reading my blog, you might think I’ve been living in the woods since June. Unfortunately I haven’t, because boy would the facial hair be bizarre, but there has been plenty going on.

The five-year-and-counting experiment is still going strong, now from a new office with some new clients. For somebody like me that enjoys diverse and interesting challenges, saying "no" to things and focusing on great over good is hard. It means deliberately taking on fewer projects, fewer clients, and saying no to good opportunities. It means releasing inactive side projects back out into the ether, where they can’t quietly compete with other thoughts and ideas. It means having the discipline to identify those little things that sap attention and deal with them. It means letting dumb domain names expire and being okay with it.

Raina (my wife and archnemesis) has joined me during the day, and her strict Trello discipline alone has sharpened the view on the ground and at 10,000 feet. My year-old(ish) decision to jump headfirst into Craft has led to fun and interesting work, including the past week I spent with an awesome¹, recently-acquired startup in beautiful Palo Alto. Being there was energizing and made me want to be better, which is how I know I’m on a good path despite making all of this up. Even minor improvements to focus have yielded more fun and more interesting work.

In hopelessly dorky terms, I’m happiest when I’ve reached high I/O in strong relationships. Hopefully I can continue weeding out idle processes and patching memory leaks until I can fly².

Wouldn’t you love to live in a world where Craft questions are asked and answered on Stack Exchange instead of Google+? Of course you would!

So get on over there and support the proposal!

Edit: Committed! It didn’t take long, so the beta period should be pretty fun.

I just read the news and it’s not good: John and Padraig are no longer maintaining and supporting Mountee, the magical Mac app that let me work with EE templates like plain old files in Sublime Text. I could search and replace across templates, add/delete/rename, change PHP and cache settings from finder, and have a lovely time of it.

After a brief panic and some cranky grumbling I’ve saved all my templates as files for the first time. I’m not looking forward to this "synchronize templates" step that’ll be required with every change, and my productivity is bound to take a dip until I figure out how Mountee-less EE humans have been coping all along.

Craft looks that much better now and it didn’t even have to do anything this time!

Update 10/16/14: Nevermind! Hop Studios has taken ownership of Mountee and will apparently keep it going. Now that I’ve got flat, versionable templates I’m not sure I can go back though.

In October 2013, GoDaddy’s scandalous acquisition of Media Temple sent me on a quest to replace my common recommendation of the DV product. I’ve been giving Webfaction (affiliate link) a go and am quite pleased so far.

Contenders

I experimented with RamNode (fast!), VPSCheap (yay resources!, more limited connection speed), and considered DigitalOcean. I can’t believe that hosts like RamNode and VPSCheap even exist; do they even know how much power and speed they’re giving away for so little? While they deserve separate write-ups, they offer unmanaged hosting which I’ll only consider for my own development endeavors. I’m not a server guru so I won’t force my inexperience on clients when it comes to production sites.

DigitalOcean still captured my interest, as it seems (anecdotally) popular with many a web nerd, but a shining account from mega nerd Gabe Weatherhead pulled me into Webfaction’s corner. And I like it there.

The Promise

Supposedly, Webfaction provides speedy hosting with ample resources and good support. It’s geared for developers, whatever that means.

First Impressions

I signed up for my trial account and logged into the control panel, flush with dopamine. At first glance, “geared for developers” simply meant “convoluted setup that requires patience.” You don’t add a domain name and dump your (digital) bags in a corner via SFTP or SSH. Instead you linger in the lobby, bags in hand, trying to figure out how to check out a room.

But it’s not hard, and one might even start thinking of it as smart: you define a new application (sort of a tailored environment for your intended app), a new domain, and a new website which simply links the application and domain. Hey, kind of smart—and that orderly flexibility could be useful later!

I got my Statamic site moved over, which is painless because it’s just PHP, Yaml, and Markdown. One clone of a Git repo and I’m on to the next app.

Worth mentioning here is that I could SSH right in and interact with Git and other friendly command line utilities. I felt right at home. There’s limited root access as well, even though I’ve not done anything interesting enough to test it.

Also nice was that when choosing an environment I could select—among other things—PHP 5.3, 5.4, or 5.5. Modern presets (Ghost, Node, etc.) were available, not endless lists of junk. To be clear, Webfaction’s “application” isn’t the same thing as a cPanel-style one-click installer that gets you up and running with WordPress and a database name you wish you would have chosen yourself. Technically speaking, it’s more thoughtful than that.

Setting up a new MySQL database was child’s play. Nothing to write about there, other than a note that PHPMyAdmin is available should you need a GUI for your MySQLing.

Support

I’ve been spoiled being able to speak on the phone with a human being at Media Temple. Someone I can understand, who can understand me and correct my mistake or fix a problem. The same goes for chat, which is typically quick and productive. Nobody ever asks if I’ve turned it off and on again.

In the event of a necessary Media Temple support ticket, there’s always thorough and expert attention within the course of a day or two.

So Webfaction had a lot to live up to.

Webfaction doesn’t offer phone support to mortals like me, so all the pressure is on its ticketing system.

My full account was established on 10/24, and the seemingly-automated “your account is ready” email allegedly came from a guy named Wayne. I cheerily thanked “Wayne” just for the fun of it, and ten minutes later he extended a personal welcome and reminded me they’re ready to answer questions when I have them¹. Wayne was real!

I submitted my first real ticket with low priority on 10/30, trying to figure out why PHP’s file_get_contents() was mysteriously timing out in one app. Ryan’s response came 8 hours later, and he asked some questions that immediately led me to the issue.

My second low priority ticket got a response in six minutes, and was wrapped up within a 15-minute window.

But let’s get serious with my only normal priority ticket. I got a password wrong and locked myself out of SSH. (Don’t judge, you’ve done it.) I submitted a ticket for this on 12/31 expecting an annoying delay, and was robbed of that annoyance when Björn cleared the IP block two minutes later.

My check goes in the “so far, so good” column on support, but you can interpret for yourself.

Speed

I moved an AngularJS+CodeIgniter app from Pagoda Box² to Webfaction and the performance difference was night and day. Rendering times dropped a half second or more, and the entire app felt significantly more speedy—nearly (but not entirely) instantaneous.

Every site I’ve deployed on Webfaction (CodeIgniter, ExpressionEngine, Statamic, Craft CMS, Bugify) has felt faster, even if I’ve not bothered to benchmark in each case. I guess it’ll be tough for you to take my word for it, but you’ll have to. Or challenge me in the comments and I’ll benchmark upon learning that non-imaginary people read my blog.

In the thirty days prior to my Webfaction migration (from Pagoda Box), Pingdom reports 99.92% uptime with 21 downtimes. The thirty days after the switch have a 99.96% uptime with 2 downtimes³.

Pingdom’s global response time averages (all European and North American nodes) in those same time periods: 954ms before the switch and 392ms after. Exact same URL and app being tested.

This is all … ahem … under very little load.

Mail

I’m always skeptical about email services that come with a hosting package. In my experience, particularly in shared environments, the accounts are like spam sponges and are often slow and intermittently unavailable. Not exactly top-notch. I use Google Apps for mail so I’m immune to these situations, but I still have to consider clients that may rely on included services.

Unfortunately all I know is that server-generated messages go out instantly, and Gabe says the email service is good.

Downsides

The service and support have been great, but Webfaction isn’t perfect.

My most serious complaint is that only one set of credentials has full access to the control panel. Separate contacts can be listed as technical, support, billing, etc., but only one username and password can be used to access the control panel. Webfaction says they’re looking to improve this situation, but it’s definitely an annoyance for smoothly handing off (or sharing) client access.

The control panel generally looks nice and is straightforward to use, but it drives me bonkers that clicking on a parent navigation item simply reveals child options and another selection is required to do something. I’m sure they’re all very nice people, but come on: give me a useful landing page or a flyout menu. I’m used to this now, but I still don’t like it.

Working Conclusion

I like Webfaction. My apps run consistently faster and have good uptime, the support is great, and the quality of services and resources and support all feel like a good value for the price.

I’ll update my review if there are any new developments, but I’m happy to stay and am confidently able to recommend Webfaction to clients.

I’ll share one last affiliate link just because I can, and you should know that I’m just another nerd with no special relationship to Webfaction or any other hosting company. But please, give me free stuff to play with and I’ll write about it!

If you’re one of the three people that reads this, let me know! I’m happy to answer questions and I like learning how others are faring with their hosting.

Other Disclosure

I got an email from Webfaction inviting me to dust off the Twitter account and tweet about my experience, good or bad, and get a free month of service. I was already planning on writing a bit more about it, so I sort of followed through but in more than 140 characters.

Lately I’ve been making an effort to evaluate and improve my writing wherever it happens. I found the book On Writing Well to be an informative, inspiring page-turner, which can be unfairly distilled to one idea: “clear writing is the result of clear thinking.”

You should read it, especially if you don’t think you should read it.

I’m mumbly and occasionally rambling in person, and it normally takes me a few approach runs before I taxi into the airport of understanding. But I love bringing order and clarity to things even if just for myself. Since enjoyment does not equal proficiency, I keep a journal and try to write in it every day. William Zinsser, author of the aforementioned book, is conveniently on board with this:

You learn to write by writing. It’s a truism, but what makes it a truism is that it’s true. The only way to learn to write is to force yourself to produce a certain number of words on a regular basis.

I enjoyed Zinsser’s definition of clutter as “the official language used by corporations to hide their mistakes,” which extends to people like me.

One of my favorite highlights is one that I should be reading every time I bother to write more than a paragraph:

Be grateful for everything you can throw away. Reexamine each sentence you put on paper. Is every word doing new work? Can any thought be expressed with more economy? Is anything pompous or pretentious or faddish? Are you hanging on to something useless just because you think it’s beautiful? Simplify, simplify.

Like anyone, my written persona gets to sound much more focused and eloquent when I make the effort to scrutinize my words. Hopefully when you’ve read my email, Basecamp message, or sporadic blog post you’ll see evidence of careful consideration. If not, please call me on it, because my unclear writing certainly deserves clearer thinking.

Harry Roberts said it much better in his article about ‘crafting’ software. It’s focused and even productive, in stark contrast to my recent attempt to quantify my frustration with the word.

Update: Softaculous updated AMPPS so that the GUI tools will ultimately work with Mavericks, and posted some patching instructions for those already using 2.1. Time to download!

I jumped in with both feet today and upgraded both of my work machines. Surprisingly enough, the only thing that’s broken so far (aside from hiding spotlight again and re-enabling TRIM) is AMPPS – specifically Apache.

I’ll post an update when I get somewhere more intelligent, but for now I’ve found that I can force start the bundled Apache under sudo via command line:

 sudo /Applications/AMPPS/apache/bin/httpd -k start

You can of course stop Apache this way as well…

 sudo /Applications/AMPPS/apache/bin/httpd -k stop

This was mentioned on the AMPPS Wiki and works just fine.

But why does this happen?

The system log leads me to believe that the problem lies squarely with a missing /etc/authorization, a normal and expected change that’s part of Mavericks’ revamped security.

I’ve been working on an ExpressionEngine project, for which we decided years ago to use your add-on. It’s a commercial add-on, meaning that people pay for your work to be able to take advantage of what the product advertises. It’s still being sold as I write this.

After years of evolution, the product sucks. Simple things like broken pagination, a data exporter that only provides 100 records, and a high-profile tool that denies you access even as a Super Admin – bugs that aren’t hard to fix. Bigger things, like sloppy code and questionable implementation – those are harder to fix unless you refactor and get serious about planning well and working cleanly.

But these things could be excused, at least, if you were taking feedback from your users and constantly patching up the junk. I write software, and I’m not at all perfect or always designing things I’m proud of – I understand how that can happen. What I don’t understand, however, is how you can release this software to the public with a certain expectation, take money, and then turn your back to problems by not supporting your software.

This is irresponsible and bad business. I’m not sure if the Pixel & Tonics and Lows and Causing Effects of the world necessarily care deeply about their customers’ wellbeing, but I would be shocked if they didn’t all agree that happy customers are an essential part of the business. In each case there are products that fill specific needs (like yours), and thoughtful, friendly, responsive support – very much unlike yours.

I would love to have a product I could charge for, evolve, and support – but the type of workload I maintain right now would leave support efforts (or current clients) shortchanged and I’m not willing to half-ass something out into the marketplace. I’m not willing to put something out there and charge for it ultimately to hurt the reputation of ExpressionEngine’s talented, thoughtful development community. Or worse, to create new headaches for the customers whose problems my widget attempted to solve.

If your product sucks so bad that you’re completely overwhelmed trying to support it, apologize to the people whose money you’ve stolen and take it off the market. Or open source it so we can all fix it up together. Or just work out the specifics of your business so that you can at least catch up to your promises and get your product back on track.

I’m not asking that you write perfect software, that you test like you should, or that you rethink everything you’ve done. But please: in the interests of professionalism, decency, honesty, and consideration of the community, support your software or make it go away.

For whatever reason, I’ve once again been invited to the AppleSeed program and I’m running Mavericks (10.9) on my MacBook Air. A bazillion other blogs will have thoughts on the subject, I’d just like to point out that TextExpander works as long as you figure out how to enable assistive devices in the rearranged System Preferences…

Visit Security & Privacy, then select the Privacy tab. There you’ll find Accessibility, and to the right will be a list of applications that you can allow to control your computer. Enable TextExpander and all is well again.

I lived without TextExpander for an entire day before figuring this out. Thanks to treichert in the MacRumors forums.

This is an oddly-specific post that I’m leaving here just in case my blog can better focus on the issue than ThemeForest’s flat comments¹.

A rather common problem with the SmartStart Responsive HTML5 WordPress theme is that upon upgrading to WordPress 3.5, the site will suddenly start throwing an error on portfolio pages:

Warning: array_count_values() [function.array-count-values]: Can only count STRING and INTEGER values! in (...)/themes/smartstart/functions/custom-functions.php on line 640

A quick fix that drops the error and seems to leave everything in good order is to wipe out a line that tries to count something that’s not there. You can do this by opening smartstart/functions/custom-functions.php in a text editor (it’s okay if PHP seems scary) and finding line 640. You’re looking for this part:

$slide_types = array_count_values( $project_slider[0][0] );

And you’ll want to change it to look like this…

//$slide_types = array_count_values( $project_slider[0][0] );
$slide_types = 0;

Don’t forget to save your file! By adding two forward slashes in front of the original line you’re just commenting it out and telling WordPress to ignore it, so if you have any problems you can easily undo your change.

Warning: I usually save personal posts for my private journal, but I feel like I should share this reflection at the risk of boring both my readers more than usual.

I got my first pair of glasses this week and I’m amazed at the literal change in perspective. My unaided vision isn’t horrible, but years in front of glowing rectangles have started to bear noticeable effect. On top of this, my eyes apparently have varying astigmatisms – meaning the wacky curvature of my eyeballs results in distortion. I had no idea, of course, because I’ve had my life thus far to adjust. Adding corrective lenses, however, is a headache: my "corrected" field of vision falls off more sharply and artificially to the left, so everything on my monitor is warped by a bizarre, horizontal gravity. Every close, flat surface tapers to follow a new and uncomfortable perspective. My world is suddenly crisp, richly detailed, and disturbingly shifted.

Here’s the cool part though: this is temporary because my brain will adjust. I’m already less distracted by the frames on my face, and after a few days my brain should adapt to signals that are different from those it’s been interpreting my whole life. How cool is that?

By positioning some shaped polycarbonate in front of my eyes, my quality of life improves. The hardware update does not require any software change. Sometimes I’m frustrated with the limitations of my own brain, and I forget that it’s a marvelous and powerful thing whether I appreciate it or not.

I’ve been moved by this article I came across today, which passionately clarifies the vast difference between design and decorating with enviable brevity and resolve. The implications are beyond design or any particular commercial endeavor, though the focus is on web design.

In other words, please read this. Aral Balkan: Design is not veneer.

In March of this year, I left Billings for the more cloud-friendly Harvest time tracking and invoicing service. It was an excellent choice, and the only complaint I’ve had is that recently I’ll have to log in every day to duplicate the previous day’s Timesheet, making my usual billable buckets available and ready to go.

Since this is an annoying and painfully redundant task, I decided to cut it down to a script I can run with Alfred. For this, I’m using some simple PHP to execute commands via the Harvest API. I simply choose my new "Harvest - Duplicate Timesheet" command, a few seconds pass, and then the browser opens to my current Timesheet to confirm that all went well.

What This Does

1. Searches a day at a time into the past (from today) to find the last-used Timesheet. I’ve limited the search to 10 days so we don’t get an infinite loop – you may need to adjust if you rarely work or take long vacations.
2. Duplicates each item from the last sheet onto today’s, with 0 hours.
3. Toggles the last timer. By default, the last timer will start out running. By toggling it, our new Timesheet will be ready to go with no items running.

What This Doesn’t Do

Anything else. I made it for myself, and you’re free to improve it – it won’t be friendly warning you about invalid credentials or telling you that it can’t find a last-used Timesheet within the search period.

On the plus side, it would also have a hard time screwing anything up. It doesn’t modify existing data, it doesn’t delete anything, and it doesn’t change any timers. It’s pretty simple.

I guess I have to remind you that I offer no warranty, and should you ruin everything and blow up the planet while playing with my humble PHP, it’s not my fault.

Making It Go (Three Steps)

1. Grab the Script

Clone or save this PHP, add your account credentials, and put it somewhere that it can be called upon. (I have a Google Drive folder of scripts, for example, which I can conveniently run with the same path on any machine.)

2. Create an Alfred Trigger

You could do this with cron so it’d be totally automated, but for some reason I still prefer Alfred.

1. Open Alfred’s Extensions preference pane.
2. Click the little "+" (bottom left) to create a new Shell Script.
3. Add some basic information, a title, description, and choose a keyword that you like. I run this silently, but this is your choice of course.
4. In the Command box, add…

   php ~/path/to/your/harvest-duplicate-timesheet.php
   open https://shortname.harvestapp.com/time

   Change the path and account shortname to reflect your own details.
5. Save.

3. Run it!

Use your new trigger, and if all goes well you’ll just wait a few seconds and your freshly-copied Timesheet will be staring right back at you from the browser.

You’ve dealt with that person before, the one who gets way too excited over his infinitesimal achievement. Yesterday, dear reader, that person was me! Two goals accomplished:

1. Post something useful, anything, even a simple fieldtype, to Devot:ee.
2. Experience the thrill of having a friendly stranger improve something I made. This was at the hands of Mr. Eli Van Zoeren, who kindly made said fieldtype available for Matrix and shared the result.

Thanks again, Eli! And of course Ryan Masuga, whose hard work makes Devot:ee an essential resource.

EllisLab recently made announcements that mark the beginning of … something. A redesigned site (with significant reorganization, new CEO, and the move to paid official support were among changes publicized on the company blog. The pro network ended abruptly, and thoughtful reactions are making their way to the interweb.

People (myself included) can be resistent to change, and having to pay for something that’s always been free¹ is a bummer if not worse. I also understand that change can be good, even essential, and I’m happy to pay for something that’s valuable to me.

While I truly hope that EllisLab has refocused itself to vigorously evolve and support excellent software, I’m pessimistic about what the changes could mean for its community and how that will shape ExpressionEngine’s future.

When I started using ExpressionEngine in 2007, it was an exciting endeavor. The control panel was one of very few that looked modern and visually considered, the documentation made it easy to start using powerful templating features, and the forums were already bustling with other users and EllisLab staff. I felt like I was just getting into something that did more than I needed, and where everybody was strangely friendly and had my back if I could ask good questions. (And in some cases, patient souls helped me understand how to ask better questions.)

ExpressionEngine became easier to recommend as I got more familiar with it. It worked for small clients and larger clients. I heard someone from the Huffington Post talk about caching and optimization for high-traffic sites, then helped build larger sites in the studio I worked at. It seems like the momentum just kept building, and ExpressionEngine and I kept changing at a steady pace. And it was good.

Now 2012. I rarely build an EE site anymore that doesn’t use Structure. Very often Matrix, Playa, Wygwam, and maybe a dozen addons are part of a project. The ExpressionEngine forums have seemed less active and less frequented by EllisLab staff. Devot-ee is where I go to hunt for an add-on that will save me hours of work. I get occasional contacts through Director-ee. The Stack Exchange initiative seems to be gaining momentum and is now in public beta. More and more of my meaningful time in the ExpressionEngine universe is outside of any official sites or support channels.

It seems like EllisLab knows this, and would like to get out of the business of facilitating community altogether, to get back to improving the quality and support of its software. It knows that it’s great for large sites, and that it can thrive where budgets are big enough to include ongoing support costs. It knows that it doesn’t need to appeal to the little guy anymore, that he’ll look elsewhere and find Blocks Craft, PyroCMS, Laravel, Statamic, and others. It seems smart.

The EE community wouldn’t exist without ExpressionEngine. I’ve benefitted from it, as have clients of mine large and small. What I’ll be interested to see is how ExpressionEngine changes with a less diverse and centralized user base.

I’m still just as confident that ExpressionEngine is an excellent choice for large projects, though I think it’s also a good time to be get to know other products that will fill the growing gap.

“To design something really well you have to get it. You have to really grok what it’s all about. It takes a passionate commitment to thoroughly understand something – chew it up, not just quickly swallow it. Most people don’t take the time to do that. Creativity is just connecting things.

When you ask a creative person how they did something, they may feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after awhile. That’s because they were able to connect experiences they’ve had and synthesize new things. And the reason they were able to do that was that they’ve had more experiences or have thought more about their experiences than other people have. Unfortunately, that’s too rare a commodity. A lot of people in our industry haven’t had very diverse experiences. They don’t have enough dots to connect, and they end up with very linear solutions, without a broad perspective on the problem. The broader one’s understanding of the human experience, the better designs we will have.”

– Steve Jobs

via vanSchneider Blog

It happened again today. Every time I introduce a client to the ExpressionEngine admin panel, the same question comes up: "how do I preview my changes before I make them live?" It’s a natural question for someone who wants to be sure their edits look right before putting them in front of a vast, faceless audience. And I’m still not sure how to answer.

Sure, there are plenty of ways to preview new posts. You can find articles, add-ons, and various methods for showing draft entries to the requisite few. That’s great.

But the elephant in the room is the Structure page, an existing and very live entry to which the client wants to make and preview edits. Our options are as follows:

1. Upgrade to Better Workflow.

It’s a brilliant $65 add-on that, among other things, clones entries and takes over the task of managing their statuses. In other words, those edits take the form of a separate draft entry that can be fine-tuned and previewed without even a whiff of change on the public website. Drafted content can then be published, replacing the current live entry’s content. No copying and pasting, no changing entry IDs, all very smooth.

Better Workflow does not, however, fully support more exotic add-ons. This prevented us from using it, for example, on a large site that benefits from Pixel & Tonic’s Assets. And we were really, really bummed to part with Better Workflow – though hopefully Assets will be supported someday.

2. Tinker with live updates at 4am, making iterations while the audience is hopefully sleeping.

I’m sure lots of us do this, but that doesn’t make it any more attractive to a client who bothers to get decent sleep.

3. Clone the page to a different URL, edit, then copy successful changes back to the original.

MX Cloner can take the pain out of cloning entries. Using that, we can get a reasonable little workflow:

• Clone the page you’d like to edit, changing the URL and "Hide from nav?" to "Yes" if that’s relevant.
• Submit changes to your heart’s content, previewing at your secret, public URL. (You could also change the status and restrict preview privileges to logged-in users if need be.)
• Either scramble to simultaneously retire the old entry and replace it with the new one (URL + status changes), or copy and paste your changes one field at a time to the existing entry. For the latter, you’ll be angry if you used Matrix, Playa, or really anything other than a textarea of some sort.

It’s that last part that makes this method feel a bit silly.

4. Use a staging environment for managing changes, then push to the production environment when it’s time.

This seems like a pretty clean way to do it in theory, but what about those things that pull the two environments out of sync? There could be Freeform submissions, template tracking updates, etc. A straightforward database + filesystem transfer could wipe out important information on the production side.

Conclusion: there’s still no perfect way to preview Structure page edits.

After all this time, Better Workflow seems like the only option that doesn’t require the client to jump through hoops. (Assuming the additional $65 and more limited add-on support isn’t a hoop.)

It’s tough to ask smaller clients to invest in a flexible, modern CMS where a pretty basic (and fair, I think) expectation of previewing content can’t be met.

Am I alone thinking this? Am I missing something? Is this just a sign that I’ve identified the add-on I need to make? Let me know what you think in the comments!

I noticed how poor the internet seemed to look on Apple’s retina iPad, and for whatever reason this new retina MacBook Pro seems to have more people focused on the issue of retina graphics and the internet. I happened upon two nice-looking solutions (Retina Images and retina.js) and implemented Retina Images on this site. I chose it over the latter because it serves the desired image once and works with CSS background images.

Retina Images gets the device pixel ratio and stores it in a cookie. Every image request is routed through a PHP file, which evaluates the cookie and whether a 2x image equivalent exists in the filesystem. The correct image is then returned. If any part of the process breaks (no cookies, for example), the original image is served. Pretty clever! The Retina Images site has instructions for setup, so all I have left are a few tips:

1. Make sure your “@2x” images are exactly double the pixel dimensions (not the dpi).
2. Hope that your source Photoshop files use smart objects liberally. Bonus points for having them already snapped to the nearest pixel.
3. The Retina Images PHP file has a handy (and optional) debug log that you can switch on if things aren’t working out quite right.

It seems likely that future specs will make room for device resolution, but Retina Images can at least take some of the ugly out of the internet today.

I stick with package managers when I can. In this case, yum would do the trick but it isn’t aware of Mercurial by default. (Try yum install mercurial with a fresh DV4 and it won’t know what to do.) To help it out, we’ll add another catalog of sorts, called RPMforge, that it can search through. We just need to get the right catalog, load it up, and tell yum to install Mercurial again.

1. Make sure you’ve got yum installed and your root access is enabled.
2. SSH into your server as the root user.
3. Create a temporary folder mkdir rpm-download.
4. Get all up in that directory cd rpm-download.
5. Download the latest x86_64 RPMforge package for CentOS 5 wget https://www.rpmfind.net/linux/dag/redhat/el5/en/x86_64/dag/RPMS/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm.
6. Add this repository to our search set rpm -ivh rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm
7. Install Mercurial! yum install mercurial
8. Make sure it worked hg

What do I do again?

I love solving problems, I’m fascinated with the web, technology, and putting things together that can make people’s lives better in some way. I’m used to wearing a lot of hats, and I like it that way, but I’m constantly forced to choose between focusing on one or two things to be really good at, or chasing a whole bunch of interests at the expense of never being The Expert at any of them.

A smart person I used to work for told me that the work I take will be the kind of work I keep getting. To my unamazement, this has proved true. I’ve learned that low-budget, ASAP projects where I’d occupy a narrow role are the worst to take on. They offer the most stress for the least pay and tend to be a drain on everyone involved. On the other hand, I work extremely well in situations where I’m the glue; there’s a big, undefined problem that needs to be identified, solved, and executed. It may involve translating between people with different interests and skill sets, or helping a small client solve big problems on a small budget. It may mean researching and building some weirdly-specific thing that nobody else could figure out how to do. I love this stuff, partly because I’m hardwired to take pleasure in organizing things, and partly because the conversations and relationships involved are engaging and interesting.

And Then There Were Answers

Through trial and error, I’ve finally started to figure out where my interests and abilities overlap. This makes it infinitely easier to know how to choose projects and who I’m looking for to collaborate with.

Things I know now…

I’m a good designer and a lousy artist.

You can argue that there’s overlap between the two, and I’ll agree to some extent. But I’m convinced that a designer is a person who solves problems, and an artist is a person who creates (or at least observes and interprets if you’re in the "nothing is new" camp).

Reliability is something I sell.

I want to be the person with the killer Dribbble feed, or the eagle-eyed pro that spots new trends before they’re big. But I’m neither. One of my most useful traits isn’t sexy or even all that interesting: I do what I say I will, when I’ve said I’ll do it. I try and communicate clearly, spell and punctuate like I give a damn, and actively take ownership of any mistakes while doing whatever I can to make them right. I’ve learned that, despite being hopelessly dull, this is a desirable trait.

Work does not happen in a vacuum.

I spend an awful lot of time at a desk by myself, and sometimes fall into the trap of believing that I work on my own. The reality, however, is that every project I work on is the result of a process, often with lots of focused communication. A huge part of what I do is to cultivate relationships that allow for efficient problem solving, be it with clients, collaborators, or both.

My spirit animal is a stodgy old man.

I can’t help it: I think that capitalization, punctuation, spelling, and grammar count for something. I don’t think Facebook, Twitter, or many newfangled ways to communicate make thoughtful communication obsolete. Intentionally crappy drawings don’t impress me, regardless of what the hipster holding the poster looks like. Maybe I’m drawn to things that seem inherently well-considered. Maybe I’m just a jerk.

The Inevitable Redesign

With these realizations, and even before articulating them, I decided it was time to redesign my tiny website. The old site, despite being tiny as well, was wasting time spreading a minimal amount of content over a few pages, and started using silly visual motifs that were more whim than anything else. So I did what felt right: focused, simplified, and made sure that design, responsiveness, and page load times would support the myriad of browsers and devices that could end up at my humble little domain. Caslon feels way more appropriate for me than Museo ever did. And as fun as it is to add excessive textures and faux embossing to type, it’s just not me. I’m also not bold enough to build a site without a stylesheet altogether. I only considered it in the moment while writing, but I suppose I’m not purist enough to take it that far.

End of Post

I’m not sure that this post will be meaningful for anyone but me, but it feels important to leave a note for my future self that says, "remember you’ve been learning things." After all, no matter what I end up doing next, no matter how wonderfully or terribly it goes, I can take pride in having learned things and helped people solve problems.

After getting really excited about CloudFlare, I was setting it up for a client’s WordPress site when it disappeared during a DNS update. The CloudFlare-served error told me that the web host wasn’t serving data to web traffic, which seemed odd.

The web host was HostGator (shared reseller account), and a chat technician confirmed my suspicion: they do not (yet) support IPv6 mapping that CloudFlare provides. So if you’ve enabled the IPv6 feature from CloudFlare’s settings and your site suddenly disappears, make sure your host supports the IPv6 protocol. Disabling the feature (it’s just a feature you can disable!!) restored the blog to its happy former state. That is all.

I host several projects on MediaTemple DV plans for the stability, flexibility, and top-notch support. (I’d rather not be troubleshooting server issues for clients at 3AM.) You can certainly use CloudFlare without MediaTemple hosting, they’ve just made it a one-step add-on service that you’d have to be a drooling idiot to mess up. I warily enabled the service for a static site, which involved signing up for a free account (email address, password) and enabling the service in MediaTemple’s control panel. A CNAME record was automatically created in the DNS settings, and that’s it.

I visited said site and it had an immediately-noticable zing. Excitedly, I added the service to workingconcept.com to see how CloudFlare would cripple the ExpressionEngine setup. I was sure it’d fail and I’d have to revert, but I tried it anyway. I was blown away: CloudFlare seemed to have absolutely no effect but to dramatically speed up page delivery. Below is my non-scientific evaluation…

just-ping.com results, before CloudFlare (MediaTemple DV4.0, Virginia datacenter)

just-ping.com results, with CloudFlare

As you can see, ping times were easily improved across the board. Remember that this is less than an hour after enabling the service.

Pingdom Full Page Test

I use Pingdom to monitor my own website and client web apps, and they’ve got all kinds of great tools. Here I used the Full Page Test to compare page load time. This test loads an entire page and basically gives you an overview of the process: how long it takes, what assets are loaded, the order in which things stack up.

The result: page load from 4.7 seconds to 1.8 seconds.

I did nothing but switch on the service. I’d say that’s a significant plus for a product that’s totally free.

Conclusion

Yesterday I could have cared less about CloudFlare, but today I suddenly can’t live without it. I’m thoroughly impressed and hope this post is helpful to somebody. I don’t work for CloudFlare or get any sort of incentive for writing this post, but I would certainly take incentives if they were offered. I’ve already been experimenting with Amazon S3 as a CDN, and Rackspace CloudFiles – both offered inexpensive performance gains with minimal setup, but CloudFiles is another thing entirely! The pro and enterprise upgrades offer increased protection and fine-tuning along with a variety of genuinely-enticing features. As of this moment I’m still using the free account, which is serving pages much faster and allegedly adding a layer of protection from various types of attacks. Once they fix that placeholder logo of theirs I’ll be proudly recommending it to everybody I can find!

Working Concept is now based in Lake Mary, Florida. I plan on continuing work with my excellent Pacific Northwest and California clients and look forward to meeting folks in the Orlando area!

Every website that I build ends up being better than the last. Something becomes more efficient, or some new little detail becomes standard. One such detail has been automatically-sizing textareas, similar to Facebook’s. It’s a simple idea: the user types more text, the text area gets bigger. It requires no extra UI, it makes perfect sense as it happens, and it degrades without issue. The jQuery plugin I keep coming back to is James Padolsey’s autoResize.

I’ve also made a habit of having textareas size automatically when the page loads, in the even that there’s already text in the field to be edited:

$('textarea.autosize').autoResize().trigger('change');

Update: since my original link died, you may instead want to check out Jack Moore’s similar jQuery plugin.

We’ve all been there with a WordPress install: “Can’t Establish a Database Connection”.

I made sure that my connection info was correct, and unlike every other PHP app install, I continued to get the error.

Assuming I still managed to get something wrong, I was good sport and used a barebones PHP script to test the connection info. To my surprise, it worked. The problem had to be with WordPress.

After a few hours of experimenting, I found the problem. I had created a test working copy on my public development server; the WordPress install I was using locally at “wp.localmachine.com” moved to “wp.devmachine.com”, and I had simply copied over the same database. The WordPress database references the site URL in several places, and you need to update these URLs in MySQL for your alternate site to work. The easiest way to do this is to dump your database to a .sql file, then find and replace the original domain (“localmachine.com”) with the new one (“devmachine.com”). Then import the resulting .sql file on the new server.

If you’d rather update the new database by hand, I believe you’ll need to change domain references in wp_site, wp_options, and wp_blogs. But be careful, wp_posts and several other areas will have references to your old domain.

A List Apart’s first publication, “HTML5 for Web Designers,” is both an easy one-sitting read and a warm introduction to HTML5. I dare you to try reading it and not geek out, even just a little bit, over what’s just around the corner.

I’ve been customizing Mark Huot’s Livesearch extension for ExpressionEngine, which combines the livesearch jQuery plugin with an ExpressionEngine plugin for returning formatted query results.

The livesearch JavaScript has a built-in caching mechanism that didn’t seem to be clearing in Firefox. In Safari, IE, and others, valid search results (weblog entries) were being returned as one would expect. In Firefox, old/deleted entries were being returned as search results. In Firefox 3.6.3 (both for myself and my client), the browser cache couldn’t be completely cleared.

The only way to fix the problem was to view the JavaScript file (jquery.livesearch.js) directly in the browser, then hold shift and click refresh.

I also updated the headers to prevent excessive caching in the first place.

I like SEO (search engine optimization) because there’s always something to tweak or improve. My latest quest has been to improve the overall speed of my sites and my clients’ sites. To do this, I’ve started using two tools:

1. Pingdom This is a web app that monitors your site(s) and gives you reports on uptime and latency, among other things. I use it to see when my site is fastest and slowest, and to get some idea of what the site’s response times are around the world.
2. YSlow An outrageously fun (geeky fun) Firefox plugin that will grade your site in various categories, and its companion website will help explain what you need to do in order to start speeding things up.

Never satisfied with anything, I decided to move my blog—formerly called Spontaneous Noise with good reason—over to the company site and run it with ExpressionEngine.

It finally dawned on me that using one subversion repository for all my projects was silly. If each project has its own repository, there are some benefits:

1. My revision comments make lots of sense and follow a logical path.
2. My revision numbers are more meaningful, and pertain to each project directly.
3. I can easily share access to one project with someone else if I need to, without exposing all of my work or potentially sensitive information.
4. I can join the rest of the world that’s using subversion properly.

So why wasn’t I doing this sooner? I learned to use subversion this way, and it actually helped when I decided to use Beanstalk. Beanstalk is awesome, provides lots of hooks and cool features, and is just lovely. The obstacle in my repository-for-every-project quest was Beanstalk’s limit on repositories. With the $15/month account, I could only have 10 repositories. I could pay more for additional repositories, but I’m cheap and ambitious and there seemed like there had to be a better way. And there was. Here’s how I set up stylish subversion hosting with unlimited repositories for $19.95 a month.

Step 1: Sign up for Linode account.

I loved Slicehost but was always curious about Linode; you get just a little bit more for a teeny bit less, and like Slicehost they seem to have a great reputation. I signed up for a Linode 360 account, which gets me blazing fast access to 16GB of storage, 360GB of memory, and 200GB of transfer per month.

Step 2: Prep Linode account.

Linode’s control panel makes it easy to get set up quickly. I installed Ubuntu 8.04 LTS (free). Done.

Step 3: Set up the server.

Equally brainless was installing VirtualMin GPL (free) using the install script, which is designed to work with Ubuntu 8.04. VirtualMin makes it easy to set up virtual hosts and repositories with a web-based GUI. I love the shell, but I find it easier to administer the web server with a GUI like VirtualMin. My brain only has room for about 10 terminal commands before I have to start looking things up. I then followed PickledOnion’s iptables setup instructions (scroll down to find it) to secure things a bit.

Step 4: Make some test repositories.

Log into VirtualMin, set up a virtual server, and add some repositories. Ridiculously easy. I access my subversion repositories via a URL like https://example.com/svn/repository-name. Tested connecting with Versions, and everything worked just fine and very quickly. I dumped my Beanstalk repository, then imported it to the new server using VirtualMin.

Step 5: Split projects from old setup into their own individual repositories.

I was sailing along feeling clever and upbeat, and then this step was like a punch below the belt. For your benefit, dear reader, I’ll share what worked rather than the grim tale of how I got there.

1. SSH’d into server via Terminal.

2. Dumped my current repository.

   svnadmin dump /home/domain/svn/oldrepo > oldrepo.svndump

3. Split off a single project into its own dump, dropping unrelated revisions and renumbering them. (Note: folder structure is important here, and you should know that a project in my old repository had a path like /projects/projectname/trunk/.

   cat oldrepo.svndump | svndumpfilter --drop-empty-revs --renumber-revs include /projects/projectname > projectname.svndump

4. Keep filtering dumps until your paths work for a new repository. You’ll know if this isn’t working because you’ll get import errors. Long story short: view the dump source with a text editor and make sure that no paths are committed to the new repository that reference non-existing folders. My three steps basically create a tags folder and make sure that trunk gets moved back one level.

   cat projectname.svndump | sed -e 's,^Node-path: projects/projectname,Node-path: tags,' > projectname2.svndump

   cat projectname2.svndump | sed -e 's,^Node-path: tags/trunk,Node-path: trunk,' > projectname3.svndump

   cat projectname3.svndump | sed -e 's,^Node-copyfrom-path: projects/projectname/trunk,Node-copyfrom-path: trunk,' > projectname4.svndump

If you’ve lived through step 4, now all you have to do is create a repository for your project and import your last filtered dump (projectname4.svndump).

Step 6: Add a touch of awesomeness with Warehouse.

Beanstalk is sexy and made it easy for me to share code with others. At this point I was thrilled to have unlimited repositories, but resigned to say goodbye to Beanstalk’s good looks and friendliness. Then Warehouse brought sexy back. I just happened upon Warehouse, a web-based subversion browser that’s built on rails. And it just happened to go open source!

I deployed a few Ruby on Rails apps in the past, and all I remembered was that it wasn’t as easy as plopping PHP and MySQL somewhere. Ultimately the setup was simple, thanks to the last step:

1. Add a subdomain wildcard for the server in the DNS manager.
2. Create a MySQL database for Warehouse, upload everything to the server’s web root, and run the installer.
3. Update Ruby, Rails, and Gems.
4. Install Phusion Passenger alongside Apache so there aren’t any more steps to install this app. (This is awesome, by the way.)

You can figure out the rest on your own. Enjoy your new repositories, your web-based browser, and your awesome new subversion hosting!

References:

• How to Move a Subdirectory From One Repository to Another
• Subversion Manual, Chapter 5 Section 3
• Transferring Repository Data

Update: For the hordes of people who followed these instructions and ended up with frustrating blank pages in Safari after multiple page refreshes, there’s a fix: code.google.com/p/phusion-passenger/issues/detail?id=354

I complained before that my beloved “Edit in TextMate” input manager wandered off into the woods when I upgraded to Snow Leopard and started using 64-bit apps. I work with lots of sites using ExpressionEngine, and “Edit in TextMate” made life quicker/easier when editing templates. (We can have a lively debate about saving templates as files later.)

Ricky at IF/THEN pointed me to QuickCursor, which is like a more grown-up “Edit in TextMate.” QuickCursor stays calm as I change Safari tabs, and never seems to lose the connection between the browser window’s textarea and the TextMate window. It lets me choose the keyboard shortcut, and you’ll never guess what I made it.

Bonus: you can add various “Edit In…” applications with shortcuts. What’s not to like? Get it for yourself!

A week ago, I logged into the Slicehost admin panel, took a deep breath, and looked down at my index finger. I held my breath and clicked, and deleted my beloved Slice. Despite the fact that Slicehost will always have a special place in my nerdy little heart, I’m moving on.

The talented and wonderfully-bearded Scott Thiessen and I have started a new project called BlipBleepBloop. It’s our own tiny hosting company that we’re using for clients and to which we’re inviting a handful of folks.

I’m proud to be running all of my non-development sites off of a Blip account, which will inherently improve our service since both Scott and I are running our own sites there. Everything has been comfortably stable and speedy, and we’re working hard to pretty up cPanel. (Which we’re both thrilled about since we’ve each encountered so many shamelessly ugly themes in our past.)

Since we don’t have the ability to offer subversion hosting, I’ve moved my repositories to Beanstalk, which I couldn’t be happier with.

Want to know more about BlipBleepBloop packages? You won’t find any specs or ordering info on our website, so email us if you’re interested. That’s the idea: small and personal.

If you’ve got a Hostgator account and are interested in using Google’s excellent Postini mail filtering service, the following should get you up and running. Please note that I’m not an IT guy, I’m not speaking on Hostgator’s behalf, and I’m not responsible if mobs come after you with pitchforks or you encounter email issues.

1. Sign up for Postini, and look for a welcome email with MX server settings that you should use.
2. Use cPanel to make sure your desired mailboxes are set up and working. (Obvious but necessary.)
3. Find either your website’s IP address or the hostname of the server you’re on. You can use any basic Whois tool, like cqcounter.com’s.
4. In Postini’s admin tool, tell the delivery manager to send Postini’s messages to your mail server. Click the “Inbound Servers” tab, select an option from the “Choose Org:” dropdown, and click the “Delivery Mgr” nav item.
5. Find the “Edit” button and click it. You’ll now see “Email Servers and Load Balancing.” Make sure that one of your email servers is the hostname or IP address from step #3, and set “% Conn.” to 100% unless you have another mail server to route to.
6. Update your Hostgator MX records to automatically send all mail to Postini for processing. If “Edit MX Entry” is an option in cPanel, you can do it yourself. Otherwise you’ll need to chat with a Hostgator support specialist or file a support ticket. You want to change your MX entries (which tells the server where to send email) with those referred to in step #1. Make sure that you select the checkbox that says “Always accept mail locally even if the primary mx does not point to this server.” Otherwise you won’t get your filtered mail from Postini.
7. Wait a while and see what happens.
8. If anything seems fishy, or even if everything seems to be working well, use Postini’s “System Tests” (again in the admin panel) to make sure that everything is routed properly.

A final note: I learned the hard way that you need to use valid email addresses everywhere. By default, your Hostgator account will reject any incoming emails that aren’t going to a valid address. My daily Quarantine Summaries weren’t showing up in my inbox even though I was getting filtered mail because I told Postini to send me messages from “do-not-reply@spontaneousnoise.com,” which didn’t exist. SMTP message tests failed because Postini tried to send from “test@spontaneousnoise.com,” which also doesn’t exist. Creating an alias for that address allowed the test to work.

Setting up a mail server hasn’t been a simple affair. Fortunately, PickledOnion’s email tutorials gave me a jump start on configuring my Hardy slice as a mail server. After using Postfix and MySQL to get virtual mail delivery working, several offers for replica watches and discount meds reminded me that I needed junk filtering. Here I’ll detail the process that I went through to configure email handling on my slice.

Categorizing Mail with SpamAssassin

At the time, SpamAssassin seemed like the best way to filter out junk. I’d heard of it before and configured SpamAssassin settings on shared hosting accounts at Hostgator and DigitalSpace. I’d used it and knew it worked; I just had to figure out how to set it up. I read a few warnings about SpamAssassin being a bit of a memory hog, but how bad could it be? I’ll come back to that later. It was easy enough to use aptitude install to download and install SpamAssassin, but it was elliot’s tutorial that helped me configure SpamAssassin and get it processing mail on my Ubuntu server.

I populated SpamAssassin’s whitelist and lowered the minimum SPAM score. Immediately SpamAssassin started doing a great job of telling me what was SPAM and what wasn’t. There were very few false positives, which were quickly remedied with more whitelisting.

The next problem was keeping SPAM from my inbox. SpamAssassin was doing a great job of categorizing SPAM, but I needed some way to avoid seeing the SPAM alongside my legitimate messages. Every new SPAM message to my inbox was an urgent reminder of two things:

1. I needed to separate junk from real mail.
2. With my own server, I just have to do everything!

Sorting with Procmail (or at least an attempt)

Webmin, which has at times been extremely helpful and deserves its own post, had a menu item under SpamAssassin for Procmail delivery. It didn’t take much searching and reading to know that Procmail was just the filtering device that I was looking for. I installed Procmail and repeatedly configured /etc/procmailrc and restarted Postfix. Nothing ever happened. I made sure that my log file existed and had proper permissions. I checked my mail logs and found nothing helpful. I was still receiving mail that got filtered by SpamAssassin, but Procmail never did anything or logged anything. It was supposed to use SpamAssassin’s headers to determine whether the message was junk, and then either deliver to the inbox or to the Junk folder. Instead it did nothing.

Filtering with Maildrop

My understanding of virtual delivery was lacking and I couldn’t get Procmail to work. It seemed like most of the example Procmail scripts I found assumed that you were using local delivery with real users (as opposed to virtual users like I was using via MySQL). I convinced myself that Procmail didn’t play nice with virtual delivery (wrong) and looked for alternatives. Despite looking for the wrong reason, I found Maildrop and eventually got that installed and filtering mail.

Here’s how I configured maildrop and got it working:

/etc/maildroprc

DEFAULT="$HOME/Maildir"
logfile "/var/log/maildrop.log"

SHELL="/bin/bash"
PATH=/bin:/usr/bin:/usr/local/bin:/usr/lib/courier/bin/
INBOX="/home/vmail/$DEFAULT"
DEFAULT="$INBOX"
SPAMFLD="$INBOX.Junk/"

# create the trash directory if it does not exist
`test -d "$SPAMFLD"`
if( $RETURNCODE == 1 )
{
`maildirmake "$SPAMFLD"`
}

# filter message through spamassassin's spamc agent
xfilter "/usr/bin/spamc -f"
if ( /^X-Spam-Status: Yes,/)
{
DELETE_THRESHOLD=9.0
/score=(\d+)/
if ($MATCH1 >= $DELETE_THRESHOLD)
{
to /dev/null
}
else
{
to "$SPAMFLD"
}
}

/etc/postfix/master.cf

maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}

/etc/postfix/main.cf

mailbox_command = /usr/bin/maildrop -d ${USER} ${RECIPIENT}
virtual_transport = maildrop

It’s imporant to note here that virtual_transport was critical because I was using virtual users and inboxes. The maildrop config lines in master.cf, combined with virtual_transport in main.cf seemed to be the key elements that allowed maildrop to filter mail.

Maxing Out the Slice

Everything was finally working just like I wanted. The only minor detail was that my memory usage seemed high, and my virtual memory usage was — well — being used on occasion. Typically, I was running at about 230MB out of the available 256MB. In the Slicehost Campfire chatroom, I posted my memory usage statistics and promptly received some concerned feedback. My swap usage was over 100MB, which means that my memory usage was so high the system had to start dumping memory contents to the disk’s swap space. I was maxing out the 256MB of memory on my Slice, and I needed to tune some processes and avoid utilizing virtual memory.

I restricted my Apache limits a bit, knowing that none of my sites would generate heavy traffic. I reduced the number of SpamAssassin children running on the Slice. Both of these adjustments helped a bit, but my memory usage was still high. I restricted SSH, saslauthd, and Courier, but that proved to be pretty stupid. Mail.app would suffer from SSL errors and I’d get occasional authentication problems. I put those back quickly.

Weeks passed and I closely watched my memory usage. I didn’t want to sacrifice functionality, but my memory usage was high and occasionally pushed into swap territory; mostly as little as 80KB but sometimes up to 4-5MB. My top processes were Apache (which I couldn’t cut any further), SpamAssassin, and MySQL. Switching Apache for Lighttpd didn’t seem like a good idea for me. How could I cut down on my memory usage?

Filtering Mail with Google Apps/Postini

I read a helpful post by unicks in Joyent’s forums (now gone from the internet) that explained how Google Apps/Postini offered an excellent mail filtering service that’s fairly easy to implement. I could still have complete control over the physical mail on my server, but with the benefit of up-to-date, state-of-the-art junk and virus filtering. Most importantly, I could drop SpamAssassin and save some memory.

All I had to do to configure this was to edit my DNS settings and point my MX servers to Postini. I then restricted Postfix’s allowed domains to Postini, so any mail that comes through my inbox has first passed through one of the more sophisticated SPAM filtering services on the market. The service will be less than $20/year, which is also a huge plus.

Regaining Memory

Rather than paying to upgrade to a slice with more RAM, I’ve offloaded my SPAM filtering to Postini — which I trust more than myself to stay up-to-date and effective. My average physical memory usage now hovers at around 125MB, which is about 80MB less than my SpamAssassin setup took. My swap usage gets to about 80KB sometimes, but that doesn’t worry me too much.

I was recently finishing up a kiosk project wherein a Flash projector would have to run fullscreen 24/7, and was having a terrible time pinpointing a memory leak that left the projector unresponsive after only a few hours. While I was able to improve memory usage, I couldn’t get the app to stay calm over an extended period. The end result was a workaround that had the projector restart itself after an inactive waiting period.

The Problem

I was working with a proprietary AS3 framework that relied on multiple SWFs and XML for configuration and content. The piece involved lots of lossless images (dynamically loaded) and only needed to run as a projector from a Windows machine. It also communicated with an external series of lights via a MAKE Controller board. Initial testing of the app went smoothly, but letting it run overnight turned it into a sluggish memory hog.

Improving Memory Usage

There were a few tips I followed from various sources to streamline the app’s memory usage. Ultimately they weren’t enough to solve the big problem, but I watched the numbers drop in Apple’s Activity Monitor.

• Remove unused event listeners.
• Clear unused display objects by setting each obj = null.
• Make sure you’ve deleted any child display objects with removeChildAt()—great in a loop.
• Stop all Timers to free up the memory that they use. myTimer.stop();

Final Solution

We came to two options: use a third-party product for compiling a more efficient Flash .exe (such as Screenweaver, Zinc, or MProjector), or create a reliable workaround that would simply restart the kiosk app and avoid the memory leak in the first place. The client needed files delivered quickly and did not have extra budget, so we ended up choosing the latter. We avoided the problem by adding a timer that would restart the Flash piece after 10 minutes of inactivity. (This was done by using FSCommand to call a batch file, since we’re using windows, immediately closing the Flash app, and having the batch file execute the Flash app again.) This ended up working pretty well and allowed us to deliver everything on time.

There are more discussions about memory optimization with Flash projectors (and Flash in general), but I never found any silver bullets. Here are a handful of links that were helpful:

• Similar Issue: Executing Long-Running Tasks
• Grant Skinner on Resource Management
• Detecting Memory Leaks in Flash and Flex
• Self-Restarting Projector
• Monitor and Restart Crashed Windows Programs

I could be late to the party here, but I’ve just discovered IETester, a piece of software that’s been missing from my life for some time now. It’s a single (Windows) application that lets you test a given website in IE5.5, IE6, IE7, and even IE8. It’s in alpha right now, but I’ve tried it and so far I’m thrilled.

Stop reading and just go get it.

I’ve had a chance to check out MacRabbit’s Espresso, and I was really impressed by its autocomplete functionality–specifically with CodeIgniter and ActionScript. Its snippets, project panel, and Safari-like text search are also very attractive, but there are a few yet-to-be-implemented features that make it impossible for me to switch from TextMate.

In order of importance:

1. Project-wide search and replace with support for regular expressions.
2. The ability to duplicate a selection without copy and paste. (⌘ + D in TextMate)
3. Multi-line selection/edit tool (alt + click/drag), and the related ‘Edit Each Line in Selection’ feature.

Espresso has been freshly released at version 1.0, and I realize that it needs time to mature. It’ll take a while to build up the enormous feature set that TextMate offers, and it’ll be amazing if it can stay as simple as TextMate at the same time. I’d make the switch in a heartbeat if I wasn’t so dependent on TextMate’s awesomeness.

You’ve got a web project and you consider yourself somewhat tech-savvy, but you know you need to enlist some professional designers and programming nerds to get your site off the ground. For most clients, this is new territory and it’s hard to know exactly what to ask. Here are a few things you’ll want to consider…

Know what you need, want, and would like to have. (In that order.)

The most common misconception is that the internet is a magical place where things build themselves, and everything is possible. It may be magical, and there are lots of talented people doing amazing things on the web, but every cool thing you see starts with some kind of plan and takes time to build. The clearer you can define your project’s needs, the easier time you’ll have working with some professionals to scope things out and get to work. If you haven’t already, make a list of your must-have features/goals, the ones you want but aren’t necessary, and then things that would just be nice.

A good website has a good plan behind it.

The process from start to finish roughly follows this path: define goals, determine technical requirements, establish information architecture, create and revise design/look-and-feel, build, test, and launch. Each of these phases assumes some amount of revision, and the entire process could range from a few weeks to a number of months. It’s tempting to want to see how your site will look and wait until you can use it to revise the way it works, but that’s a sure way to make a project more expensive. Defining goals that can be measured, having good information architecture that models key aspects of site functionality, and listing technical requirements up front can save lots of time and money later in the project cycle.

The sky is not the limit; it’s time and budget.

If you’re new to web projects, pretend you’re building a house. They come in all shapes and sizes, they often meet the same basic needs, and you’ve been through enough neighborhoods to know that they can be vastly different from one another. Be prepared to share your budget and expected timeline, as they will be critical in determining the scope of the site. Ask to see a few bids where the design firm explores potential options that meet the site’s needs within the budget and timeline that you have to work with.

Hopefully this will demystify some of the process. If you still have a few questions, or if you’d like to start a conversation about your project, drop me a line!

This is one of those awesome bugs that wasted more of my time than I’d like to admit, so hopefully this post can help someone in the future.

The problem: I’m working on a site that uses the jQuery Cycle plugin. The chunk that gets rotated for the slideshow is an HTML list-item that contains another list with nested list items. (li -> ul -> li, li, li). The root li kept getting a background color applied to it, even though I specified that it should be transparent.

The solution: disabling the Cycle plugin’s default behavior of applying a background to the slideshow container element when using IE on a Windows machine with cleartype enabled. Add this little combo to your Cycle options and things should be fine:

cleartypeNoBg: true

The key was mention of this undocumented feature in this thread.

I work on more than one Mac. Working from Subversion and checking my email is a breeze, but pretty much everything else is annoying when it comes to sharing data. I don’t want to fork over the money for MobileMe because I’d only want it for syncing. I finally have a simple solution that I’m using to keep my 1Password keychain, Address Book contacts, and Things data all up to date. I first switched my 1Password data to the Agile Keychain format, chose to store the keychain in my Dropbox, and I was done! It worked so well I thought I’d try and use Dropbox for some other stuff.

I could finally have Address Book share the same data and sync any changes to my iPhone from my primary/home computer! It was as simple as turning the Address Book’s data folder into a symbolic link. The app acts like it normally would, but secretly the data it uses gets stored in the Dropbox and therefore updated each time the Address Book gets an edit. For me, it was two lines via the terminal:

cd /Users/[username]/Library/Application\ Support/
ln -s /Users/[username]/Dropbox/SyncData/AddressBook/ ./AddressBook

Since this worked just fine, I tried the same with Things. It stores its data in a single XML file, but I made the whole directory a symbolic link anyway:

cd /Users/[username]/Library/Application\ Support/Cultured\ Code/
ln -s /Users/[username]/Dropbox/SyncData/Things/ ./Things

The only catch here is that I need to remember to close Things when I’ll be moving to another computer. I ran into a problem once where I opened up my laptop and it wrote to the Things data before it had a chance to pull down updates. This was easily fixed by going to the Dropbox web panel, selecting a previous revision of that file, and restoring it. It immediately pushed the revision to all three machines. Impressive! So even if something gets messed up, Dropbox is quietly keeping revisions of everything. I love it.

I’d like to follow suit with my Safari bookmarks, but I only want to update one file (bookmarks.plist) rather than Safari’s entire support directory. I tried making only this file a symbolic link, but Safari is quick to overwrite it with a real file which destroys the link. I don’t want my browsing history, cookies, cache, etc. to get synced, but I’m not sure what else to do. If anybody out on the internet has an idea, feel free to leave a comment. (Also, if anybody besides me actually reads my posts, I’d be thrilled to find that out.)

Update: I’ve been able to get some other apps syncing data as well, including Billings, MacJournal, and Typinator.

In September, I switched from a Baby shared hosting account at HostGator to my very own slice at Slicehost. It’s been an eye-opening plunge into the world of unmanaged hosting, but the Slicehost support team has played a critical role in supporting me while I get my Slice running smoothly, securely, and efficiently. I’m maxing out a 256MB slice with LAMP, a mail server, DAV, and SVN.

The great relief is that every single problem I’ve had been my own, not the limitations or drawbacks of the hosting company. I was impressed with the responsiveness and offering of my HostGator account, but felt limited by not having DAV or SVN access. Slicehost, at least thus far, has simply followed through with its promise: rock-solid, high-performance service with unbeatable support. They’ve gone out of their way to help me troubleshoot and configure my Slice, understanding full well that I’ve been learning as I go. The risk of course is that your server is yours … to completely screw up. I’ve had a few late-night Postfix/Courier experiments go poorly, but there has always been someone around to help. (Which is amazing — I really mean always.)

I plan on posting some articles with what I’ve learned from my own experience. If you’re starting out with Slicehost, however, PickledOnion’s tutorials are a must.

JAMstack is the Beatles.

At Dot All we clutched our hearts, outstretched our hands, and jumped around screaming and crying as JAMstack filled the air.¹

You probably heard about that already, and if not you might want to start with an excellent summary by Matt Gray or Ben Croker.

I'd like to clarify how headless Craft, serverless architecture, GraphQL and JAMstack relate and how they could play a part in however you build web projects.

Before that, Marion made a point on the devMode podcast that's worth repeating: Craft is not forcing you to change anything. If you build sites happily and productively with Twig, you can keep right on doing that and enjoy the exciting stuff that's coming in Craft 4. This headless, JAMstack-centric business is opt-in only and not something that requires you to change the way you work.

My Interest in JAMstack

I've been building modestly-sized, headful Craft sites for years, and I'd like to build sites statically without any compromise for content authors. My clients shouldn't have to suddenly do without Live Preview or lose control over exactly when they publish updates. My technical interest comes down to hosting and building with components. I'd like to...

• stop provisioning, maintaining and supporting servers
• dramatically reduce hosting costs while improving performance, uptime, and security
• deploy static sites built with Vue, React, or Svelte (using projects like Gridsome, Gatsby or Sapper)
• take advantage of component-centric tools like Storybook and Figma to design and document work with greater clarity

I haven't made that my new normal yet, but as of Craft 3.3 the major pieces are all there to be assembled. I'm pretty sure that's what we're all excited about.

But let's sort out what these things mean. They seem to have arrived all at once, and it's easy to confuse the pieces and how they fit together.

Headless != JAMstack != GraphQL

Andrew's talk compared the LAMP stack we know to the JAMstack we want to. It's not an alien wonder, but a rearrangement of concepts and responsibilities we already know pretty well. Cool new things that have their own tradeoffs.

The LAMP/LEMP initialisms acronyms stand for software you inherently run on a server, while JAMstack's JavaScript, APIs and Markup don't require a server at all.

For this reason, one of the benefits of the JAMstack is how well-suited it is for serverless architecture. The term “serverless” is part lie because there are still servers, but mostly great because you don't have to manage them. Usually you point a slick SaaS offering to a repository, give it some minimal configuration, and it takes care of the rest.

We'll get to Gatsby and Gridsome in a moment, but it's important to know that they still require a server even though they build sites you can host on a CDN. Gatsby and Gridsome require a server at build time, which is before the site gets deployed. This is probably similar to how you're prepping CSS or JavaScript for deployment right now, except the site's pages are all built too. Craft obviously runs on a server, but it was born building pages on the fly at request time. Various forms of caching can make that as fast as a static site, but that's the key difference between Craft and static site generators: both need web servers to generate pages, but one builds before deploy and the other builds live, upon request.

The last Craft 3 install you touched can run headless right now without any changes to its server. In the not-too-distant future, you'll also be able to use headless Craft without needing to install anything on a server—that's Craft Cloud.

Headless Craft just means Craft without Twig.² Craft reduces its role to content manager, with a UI for authors to manage content and APIs (ElementAPI and GraphQL) for developers to extract that content and decide how and where it's presented. Those developers aren't limited to using Twig to build a frontend, but anything at all that can interact with those APIs. This plays perfectly, and at just the right time, into serverless static sites.

Static sites aren't new, but hosts like Netlify and Zeit offer platforms that make them easy to work with. Building those sites can be fun with projects like Gatsby and Gridsome.

There are two reasons Gatsby and Gridsome get so much attention:

1. They'll take whatever content you've got. This can mean local markdown files, MySQL or Postgres, a GraphQL API, and more. It can also be any combination of sources. No matter how much there was or where it came from, it'll then be accessible in one uniform GraphQL collection.³
2. They neatly package frontends using the things we know we should be. Performance and best practices are baked in: preconfigured webpack (!), server side rendering, critical CSS and prefetching to name a few. Plugins make trivial work of adding Tailwind or offline browsing and loads of other fancies. If you've ever tried to wire up just a few of these things yourself, you'll appreciate how they all just work right out of the box.

It's reasonable to assume, based on Gatsby and Gridsome's popularity, that humanity has not been loving the tooling complexity required for a performant, well-rounded modern frontend. Each project takes data from a variety of sources, lets us work with Vue or React and whatever we want for styling, and offers preconfigured and easily-customizable tooling to generate a great static frontend.

Live Preview

Live Preview was a real challenge for static sites until Pixel & Tonic released preview targets with tokens. This says, “sure, let whoever you want into that preview pane, just have them give us this little token so we know it's safe to share your content.” It still takes some extra planning and effort to support Live Preview outside of Craft's comfortable Twig templates, but the preview tokens make it a lot simpler.

Read/Write

If you've contemplated a static Craft site, it probably took you ten seconds to wonder how content gets back into to Craft via Guest Entries, form posts, etc.

The GraphQL API doesn't yet support mutations, which is GraphQL-speak for writing stuff that's currently just read-only. But those are coming. You can still use the Element API, see how plugin developers might support headless interaction, or just send data to third-party services.

The bigger shift to prepare for right now, however, is adding more logic to your presentation layer. If you've ever submitted a contact form via AJAX, you already know exactly what this means: have axios or jQuery post the data, look at the response, and decide how to reflect that on the page. This is the exact same shift you'd make for building a member section or store, though you'll probably need to store persistent data in sessions or local storage. Once you make the shift in how you think of “dynamic” interaction, it'll probably make Vue or React seem more powerful and lead to a more manageable set of problems to solve.

What Now?

One nice thing about JAMstack's patchwork is that its pieces can easily be broken into bite-sized nuggets.

Francesca's talk offered a pragmatic way forward for those of us that are new to a lot of these things: don't feel pressured to build a whole project with Gatsby if that's overly daunting. Instead, sprinkle a little Vue or React into a project as progressive enhancement.

Or whip up a serverless microservice by using a Lambda function to handle your image transforms or send email notifications when forms are submitted.

You might discover a surprise love for Lambda functions and like AWS again, become weirdly passionate about web components, or maybe get comfortable with enough different parts that building a headless Craft site seems more inevitable than daunting.

Whatever you do, make stuff and have fun!

The short version is that I finally went to a conference and thereupon learned that I should go to conferences.

The longer version is that I returned to Florida two weeks ago to attend Peers, a conference I’d sum up as a therapeutic professional gathering of web entreprenerds. Despite the high concentration of likeminded people in my industry, I manufactured poor but sufficient excuses not to go in years past. This year a lack of scheduling conflicts and an abundance of curiosity led me to the far end of the blue baggage claim at the Tampa airport. That’s where I met the first folks in what would turn out to be a dazzling array of people, messenger bags, and earnest conversations about the stuff we all do.

I was not surprised to confirm the presence of fascinating backstory, hilarity, catharsis, experience, insight, and challenge. I was surprised, however, not to encounter douchebaggery or cliquishness of any sort. I braced myself for some of the unsavory stuff I’ve heard about tech conferences where attendees (usually women) get singled out by real life trolls and jerks, and was heartened—though not surprised—when a female presenter stood up at one point to share that she was happy to give a talk in a place where she wasn’t rudely treated like a novelty woman-developer but got to engage in conversations she was passionate about.

The spirit of the thing, the laid-back gathering of approachable web nerds, was the golden nugget at its core. It pervaded the workshops and talks and conversations, and I think much of the credit for that belongs to Jess D’Amico, the tireless champion and organizer of the event. As an over-thinking introvert, I don’t tend to breeze among foreign venues and introduce myself to strangers. Yet that I did, because keeping up was effortless thanks to untold effort from Jess and her crew, along with the attendees who unanimously chose to be amicable and sincere.

Another thing I didn’t expect to find was reassurance. More than one presenter had me deeply appreciating challenges and failures rather than fearing them, and it became obvious after only one evening that many of us were on similar quests experiencing similar joys and problems. As a solo nerd more or less making up his career, this was comforting and refreshing. It’s not often that I can find relief in something while being challenged by it, and my time at Peers very much hit both marks.

Judge not my simple revelations, dear internet, as I conclude with my humble Peers takeaways. These are for me, so don’t be surprised if you’ve already figured them out:

1. Don’t make assumptions about people you’ve only known as an arrangement of pixels. You can avoid being wrong and being a jerk at the same time!
2. Don’t waste time being intimidated by people, but appreciate the work they do and be prepared to ask them questions. It’s way more interesting to hear what motivates them than to stare dumbfounded as you realize they wear pants just like you.
3. Invest real effort in remembering peoples’ names, remembering how it felt when a stranger bothered to remember yours.
4. Don’t complain about long flights. Someone with a fabulous accent will have inevitably journeyed much farther.

I’d like to use this first post of 2017 to summarize the year, a new tradition that’ll ensure at least one post for every lap the earth makes ‘round the sun.

It’s been a busy year with a few big milestones for us, the biggest being a transition from “me” to “us.” Raina’s been working with me for more than three years, and starting this month she’s employee #1, entitled to all the perks and unpaid vacation we enjoy here at the company. We met working together, got married along the way, and continue to work well together, and I’m eager to see how Working Concept can grow and improve.

For those expecting bullets, here are the highlights:

• Helped behind the scenes with Peers 2017, which came to Seattle in April for its fifth incarnation.
• Published four Craft plugins: Cloudflare, Versioneer, KeyCDN, and Bugsnag (for Craft 3). I write a bunch of Craft plugins and publish few, so it’s been good to get something out there.
• Hit a perfect 100 for Google PageSpeed Insights, after finally grappling with CriticalCSS and more intense caching. If you’re an active client reading this, you’ve benefitted from this quest in some way.
• Migrated BlipBleepBloop, our tiny hosting operation, to much faster and more stable infrastructure without pricing changes.
• Boosted overall project efficiency adding Gulp workflows to old and new work.
• Got started with Craft 3, which hit RC2 just before I published this post. (If "RC" only reminds you of soda, just know it’s getting close to its big launch.)
• Helped some exciting young software companies define and refine their visual identities. We’re excited to watch them grow!
• Launched a 17-language site for distinctly different audiences spanning four continents.
• Watched speed and SEO improvements bring an existing client more business.
• Launched our very first pro-bono project for a neighborhood non-profit that helps neighbors in need get clothes, transportation, and help paying bills.
• Ushered projects old and new into the era of https.
• Started using a CRM, which you’ve noticed if you brought up work and I "magically" remembered to follow up methodically. More on this below.
• Spent quality time with Laravel and Vue, leading to a few client projects and a handful of internal tools for monitoring project health, scheduling meetings, signing contracts, and automating Trello tasks.
• Luxuriated in this bountiful age of text editors, occasionally setting aside Sublime Text 3 to work smarter with PhpStorm and sometimes cheerily with VS Code.
• Committed to using Bugsnag and Pingdom to stay vigilant with active projects.
• Managed to be the second-most-useful moderater on the Craft CMS Stack Exchange site. Stop by, ask an inappropriate question, and I may be the one to remove it!
• De-integrated the CMS from some old Craft and ExpressionEngine projects that are better off static for the long haul.

Modest Marketing

How many times have you heard the statement “We like to let our work do the talking.” That’s modesty. And in marketing, there’s no place for modesty.

Alex Goldfayn, The Revenue Growth Habit

Despite my enthusiasm over a helpful project management book, the year’s greatest business development has been the notion of business development. A different book that I didn’t like helped me approach the idea of sales, for my business, without feeling my soul start to wither. I read it following some interesting discussion in a Slack group, and had my most moving annual epiphany.

But first, you should know I’ve been running my own business to accomplish two things:

1. help people solve interesting problems
2. continue eating and sleeping both legally and indoors

For a tiny company like mine, I’ve seen sales as a misguided effort to win money rather than do good work. I’d rather under-promise and over-deliver, I’ve been lucky enough to always have work, and I’ve had little need to sell anything. Since it launched, this site has continually communicated less about what we do. I’ve been getting away with it, not updating testimonials and case studies with glee. My epiphany, courtesy of Alex Goldfayn, is that I’ve been letting existing and unrealized clients down:

• Existing clients aren’t aware of an evolving skill set, sometimes surprised to learn we do a particular thing or that we’d solve a problem differently than we might have a year ago.
• We’re primed to lose work with good, inactive clients when all they see is the site we built many years ago. If they want something fresh, there’s no reason to consider the maker of the old thing with only a few blog posts to indicate they’re alive.
• We have to spend a significant amount of time compiling work samples for potential new clients, who must ask for them given the absence of a portfolio or case studies on the site.

If you’re reading this (hi, and thank you!), you’ve fallen into a carefully-placed trap. I’d like to do a better job of conveying how we might be able to help without wasting your time. I’ll be using a CRM to make sure I follow up on any new work you might want to tackle. I’ll be updating this site to better communicate what we do and show examples. (A secret HAQ page was a recent start.) I have more ideas, and hopefully they’ll help us both do better work together in the year ahead. Happy almost-2018!

We’re pleased and relieved to finally start offering formal maintenance plans and the option of ongoing support. This is part of a commitment to improve the quality and care of all projects by making maintenance a business priority.

A strong launch is one thing, but keeping a site strong months or years later can be a challenge.

Things on the interweb change fast and long gaps between updates can be issues for security, speed and usability. We’re constantly improving how we build and deploy projects, so even getting back into older code can take a significant amount of time. We’re not the first to offer this kind of arrangement, but we hope we’ve found options that’ll work for every client and provide a sustainable way to keep every project happy and up to date.

For clients with older projects that have been with us for a long time, the idea may be uncomfortable. This is our fault, because like many in our industry we’ve learned the hard way that ongoing free support and availability has a cost. This cost either adds up day to day, or reveals itself when an old and untouched project needs work or experiences an emergency. While every project is different, there’s not a single site on the internet that isn’t dependent on hardware, software, and vast networks being maintained to keep it alive.

Why now?

Two key factors have contributed to our push to formalize plans.

The first is a growing body of work. We’ve launched more than a decade’s worth of projects, so we’ve had to figure out how to ensure every project stays up to date especially when it appears to be humming along without any needs.

We’ve always been happy to answer questions and keep supporting work we’ve done. It’s also becoming increasingly important to discern where to spend our finite supply of attention. Maintenance and support plans expose formerly vague or hidden costs and assign value in a way that’s clear, professional and sustainable.

Second is a much stronger proficiency with development tools and hosting infrastructure. A stroll back through some of this blog’s earlier posts will offer evidence of learning and diving deeper into the complexity of how a site exists and performs on the internet. While I wouldn’t dare mistake myself for a professional systems administrator, I’m comfortable with systems that years ago would have had me hesitate to offer support or guidance.

In other words: we aren’t just offering plans, we can actually manage and support them. We’ve put a lot of time into policies, practices, and packages that should ensure service from which everyone can benefit.

Okay great, but I’m a client. You solved problems, updated software and answered questions for free for a long time!

We’d honestly like to keep doing that because we like being helpful, but we’ll all end up disappointed if we keep on that way. Our support won’t be worth anything if our company isn’t around to provide it. We have to prioritize work that pays, which means maintenance isn’t a serious priority until we can include it in a stream of committed work. We don’t want to operate with a wink and a nudge, but with clear parameters and a fair cost.

Is a maintenance plan required?

No.

We don’t own or control any project; every one is in the hands of the client. We’re raising our standards and insisting that projects are kept up to date when we’re asked to work on them. (They should be monitored and kept healthy and we’d love to help with that too.) At the very least, we’ll expose the cost of software and workflow updates in any estimate we provide. That may not be a big deal particularly for newer projects, but there are plenty of options for older sites:

1. We can help train someone from your team to manage updates. There’s nothing secret about what we do, we just insist that somebody cares for every project so it stays strong.
2. We can help you find another developer or agency that can handle maintenance.
3. If your site’s older and doesn’t see frequent updates, we may be able to flatten it by removing the machinery that might otherwise be problematic if left untouched. We’ve done this for a few clients, and while it’s not perfect it can dramatically reduce a site’s ongoing maintenance needs.
4. We can also help move you to a platform that includes hosting, like SquareSpace or Shopify or Wix. You’ll sacrifice some of the flexibility you enjoy having a fully custom project, but maintenance and support are included in the service fee.

What does "up to date" mean?

Up to date means that a site’s code base is clean and checked into version control, that all minor software versions are current, and that any commercial software is properly licensed and entitled to support. Security patches and critical updates are applied throughout the software stack. Backup mechanisms should be utilized and periodically verified.

In non-technical terms, simple diligence should prevent the site from being a liability for the client. Best practices and redundancies can prevent problems and make it easier for others to get involved or help out.

Servers fail, people make mistakes, teams and developers change. None of these things needs to jeopardize a site.

What does "monitored" mean?

The level of monitoring depends on the plan, but at minimum it means perpetual one-minute checks from different geographical locations to make sure your public website is as fast and available as we’d expect. We’ll automatically be notified if there are issues, and clients will authorize us to file support tickets to quickly get them resolved. We’ll also report the site’s overall uptime metrics so we can all know how well (or not) the hosting setup is working out. Lastly, we’ll let you know about any upcoming SSL certificate or domain registration expirations. None of these things count as issues in Maintenance & Support plans. We’ll monitor and be proactive for any site we’re watching, period.

For more involved monitoring and support, we’ll also set up error monitoring in production and respond similarly if problems occur in the wild. If the web host type allows us to also collect server health metrics, we can include those as well.

Why is this a good idea?

“An ounce of prevention is worth a pound of cure.”

Benjamin Franklin

Benjamin Franklin didn’t operate a single website and he was referring to preventing fires in Philadelphia, but contingency planning is always a good idea. In this case, some diligent action can prevent inconvenient or even catastrophic business problems. Lost data and lost business can take a lot of time and resources to replace.

What if I want to handle these things myself?

You can, and we’ll even give you pointers to get started! We don’t offer magic or proprietary wizardry, just expertise at what we think are reasonable prices. We love working with all the bits and pieces that bring web projects to life and enjoy sharing that knowledge. Odds are you hired us because you didn’t have time to become a designer and/or web developer and do everything yourself. That’s the same reason you might consider trusting us to keep an eye on your site and keep it up to date.

What’s it take to get started?

That depends on what the project looks like.

Recently updated projects won’t need much, just a plan selection, initial payment, and onboarding.

Older projects will probably need to be caught up further with workflow and software updates.

Either way, it might help to read more on the Website Maintenance & Support Plans page and chat with us about what it would take to get up and running.

Andrew Welch’s landmark webpack treatise covers just about everything you’d need to get working with an organized, comprehensive webpack-based workflow. I know this because I’d recently made the transition from Gulp to webpack with only a fraction of what’s covered in his post. It took me a long time. If you’re looking for an up-close view of the machinery, Andrew’s article will make the most of your five minutes.

If you’re still not sure that webpack makes any sense, or how it can be okay to have 66 dependencies for a demonstration, join me here for a moment.

I’d started pawing at webpack a few times only to get confused or frustrated at the lack of a Gulp-like simplicity.

In hindsight, simplicity was the wrong thing to look for because webpack is just more complicated.

Making produtive use of it demanded that I rethink my approach to front end assets and how they come together. It took me a while to hammer out my humble workflow, and I’d like to share the critical shift in orientation that finally made all the technical hurdles worth the trouble.

Webpack is for Modern JavaScript

As much as I don’t want to admit it, Peter Jang’s Modern JavaScript Explained for Dinosaurs was the first article that put things into context for me. Webpack doesn’t just do stuff to files. It understands packages and dependencies and web performance. That’s massively important and distinctly different from Gulp.

Imagine a project that relies on jQuery, some plugins and scripts, and a Gulp workflow. For that project, webpack will feel like overkill. It probably is overkill. The retooling and complication may not be worth it for every project.

Another project may use ES6 and Babel, Vue/React, PostCSS, and incorporate Critical CSS and polyfills and asynchronous JavaScript loading. If you’ve built such a project without using webpack, odds are you’ve found yourself in a bit of a kerfuffle. These are great tools, and yet getting everything neatly packaged and cache-broken for production gets increasingly tedious. Once your expanding front end toolset starts to feel like a herd of cats, that’s when webpack’s majesty reveals itself. Whether you’ve experienced that pain or not, the first step is to understand how webpack is designed to solve problems differently than Gulp.

A Conveyor Belt and a Production Manager

Gulp and webpack are different animals.

Using Gulp is like having a conveyor belt where you can tinker with each of the stations. You drop stuff in at different points, it all moves down the line, and it’s dumped out somewhere.

Using webpack is more like hiring a production manager to listen to all your needs and wrangle all the stuff efficiently. Instead of adjusting conveyor belt stations, you tell the production manager where to find things and what you’d like to end up with. You spend most of your time going into great detail clarifying your instructions, and the manager gets it done.

This manager only understands JavaScript so you’ll have help convey what CSS and static files are, but the manager understands packages, dependencies, inputs and outputs. This is a big deal, because it’s not just acting on files but working more knowingly with code. The manager also has a network of friends (plugins) that can add expertise to the production department. If you’re all working well together, stuff will end up where you need it and how you need it, for development or production. It’s very fast, too.

Suggestions

Webpack doesn’t just want to compile your things and dump them out, it wants to help you solve production problems. "Help me help you," it says. Here are my tips for working with webpack:

Don’t skim when you’re reading about entry points.

The webpack magic starts and ends with entry points, so it’s important to understand what they are and how you can use them. The concept shouldn’t be too unfamiliar: entry points are the built assets you’ll reference in your markup so the browser can work with your bundles.

Your current setup might have a global app.js that handles site-wide navigation and search functionality, for example, and then forms.js that you use only on pages with forms. Each could easily be an entry point in your webpack setup.

Where things can get more interesting is that a single entry point can load code asynchronously, dynamically split code, and usher in all kinds of fancy that doesn’t have an equivalent with your current setup.

But they don’t have to be complicated. The entire contents of an entry point might look like this:

import '../css/forms.css';

That’s an imaginary /src/js/forms.js file containing only a CSS import. As I mentioned above, webpack understands JavaScript—but a common practice is to lump in CSS and have webpack split out and process JS and CSS separately. After the webpack magic is complete, it’ll have built /dist/css/forms.bundle.css which I can include on the front end. In this case I’d also have a /dist/js/forms.bundle.js I’d ignore.

I can, however, start including other JS code or writing JavaScript directly in that entry point and drop the resulting /dist/js/forms.bundle.js in my site’s markup.

Know what an entry point is and how you intend to use one or several of them in your project.

Don’t bring files and expect to leave with some other files.

Bring packages and code and expect to leave with bundles.

If you’re used to downloading JavaScript, putting it in a publicly-accessible folder, and adding script tags to your markup before relying on that code, your life is going to get way easier and your projects are going to get much tidier.

You might start whistling while you work.

For example, let’s say you’re using Prism to add syntax highlighting to your code blocks.

Previously, you might have visited the download page to customize and download a build with whatever features you’d want. You’d plop them in your web folder and add the JS and CSS to your markup:

<script src="prism.js"></script>
<link rel="stylesheet" href="prism.css">

You could have put them in a project source folder and had gulp minify and combine them as well, but ultimately you were putting the result in the web root one way or another. You would then have to manually grab new files for changes, whether it’s to Prism’s core code, a change of color theme, or different language support.

Including Prism’s JavaScript alone will have it get to work on your page’s code blocks, but you can also add a data-manual property to your script tag to prevent that and configure it via API.

<script src="prism.js" data-manual></script>

You’d then write some code telling Prism what to do, putting it in <script> tags on your page or in another file (like app.js) that you include as well. This is the same approach as including a jQuery script tag, some jQuery plugin script tags, and then adding your own JavaScript file or script block to use jQuery and its plugins to make stuff happen.

Now let’s look at this Prism example with a webpack setup.

By virtue of using webpack, we’ve probably already included bundle references somewhere in our markup:

<script src="app.bundle.js"></script>
<link rel="stylesheet" href="app.bundle.css">

The app. filename is deliberate, because this bundle is actually a collection of different things and not just our Prism assets; each file is the result of webpack’s bundling process. That process likely includes combining and minifying files (among other things), resulting in app.bundle.js and app.bundle.css. You can choose whatever filenames you’d like, of course.

Webpack knows what to do with npm packages, which you probably already know are a vast expanse of JavaScript repositories you can neatly require with npm or yarn at the command line.

That’s exactly what we’ll in the webpack equivalent of our example:

npm install prismjs

npm now downloads Prism for you into your project’s node_modules directory. Unless you’ve done something horribly wrong, node_modules shouldn’t be web-accessible.

First we’ll want to load Prism into some JavaScript in our project:

import Prism from 'prismjs';

Nothing happens with this alone, so we have to add one line that tells Prism to highlight all the code blocks it finds:

import Prism from 'prismjs';

Prism.highlightAll();

That’s it! As long as this JavaScript is included in a webpack entry point, it’ll get bundled with everything else. No need to move anything else into your web root or update your markup. You also get a few more perks that come with package management:

1. When you npm install, the package and its version are added to your package.json file. This will signal to other developers that your project uses Prism, and the package manager will look out for compatibility issues and make sure any project code can share the same version of Prism to keep things efficient.
2. Your repository is cleaner since dependencies are downloaded separately. (Commit your bundles, don’t commit your node_modules.) This can be helpful for licensing, too.

Webpack will champion your dependencies and performance needs, so try to shift your thinking toward what code you need and where it should have an impact rather than what files you need and how you’ll manage them in your webroot and your markup.

Be patient.

I found many helpful articles on my quest that had totally incompatible approaches to solve similar problems. It’s complicated, there’s a whole lot you can do, and it’ll feel fantastic when all the pieces are working for you and speeding up your development process.

I’m far from an expert on the subject, but my prior confusion was genuine and long-lasting. Despite the significant effort to use webpack in my projects, my code is cleaner and my build process is much smoother and I’d probably have tried to make the move sooner if I’d known how much it would improve my development efforts in general.

I hope this is helpful! Please post a comment or send me an email if you have questions, comments, or corrections.

Just as GitLab announced support for the more popular git-lfs, I’ve figured out how to get Tower working with Git Annex.

If you’ve been using annex in your GitLab repositories, and your Tower commits fail with

git: 'annex' is not a git command.

…you’ve likely resorted to making commits from the command line. Your shell is configured to look in a few different places for other binaries, so git can look around for git-annex, which probably lives in /usr/local/bin. Tower is more limited to where it can look around, so you can fix this problem by installing a git binary to /usr/local/bin and telling Tower to use that one.

I already had Homebrew installed, so it was a matter of brew install git. I could confirm that /usr/local/bin/git existed, then select exactly that from Tower’s Git Binary menu in the Git Config pane.

Commits from tower should now work fine, just in time for you to move on from git-annex and set up for git-lfs.

I often waste time checking to see whether any of my Amazon.com reviews have landed more helpful votes. For that reason, I hacked together a quick OSX Dashboard Widget that lets me watch obsessively without getting a browser involved. Enjoy¹!

Amazon Reviewer Profile.wdgt.zip (23KB)

One discovery this week needn’t be a secret: it’s an app called Page Layers, and it’s already making my life easier.

Often I’ll need to put together mockups of an existing web page, and I’ll start by taking screenshots and breaking them up in Photoshop. This can take a significant chunk of time, and gets excessively annoying should the site’s content change during the Photoshop spree.

Page Layers solves both problems quickly and simply: feed it a URL and it’ll capture a screenshot like Paparazzi and similar programs. The critical difference is that it’ll allow you to save a layered PSD file, whose folder names and hierarchy come directly from the page markup. All text gets flattened, and if a particular element needs to be further separated it’s as simple as adding a span element before running through Page Layers. It’s, simple, smart, and surprisingly fast even on my mid-2009 MacBook Pro.

While there may already be a less primitive way to jump-start Photoshop mockups of existing pages, Page Layers has already been a helpful addition to my workflow. It fits a niche role, but works its reliable magic just as well as I’d hoped.

It’s available on the Mac App Store for $33.99, which I’d call pricey if the time saved didn’t more than justify the price.

Working Concept is now officially back in Seattle! I’m excited to be setting up a studio space in the historic and really cool Inscape Building with Bryan Wilson and Scott Thiessen.

It’s exhilarating to be in good company and back on the west coast.

I’m on a roll with Alfred: this time with a workflow for searching and browsing Bugify issues via the Bugify API. I’ve been increasingly relying on Bugify, so it’s helpful to quickly find an issue and jump straight to it in a browser.

If you’d like to try it out, you’ll need to set the URL of your Bugify install along with your API key. I’m not sure whether there’s a better way to do this, so it’ll require two steps:

1. setbugifyurl http://yourbugifyurl.com/ (with trailing slash)
2. setbugifykey YOUR_BUGIFY_API_KEY

Once your connection details are stored, try any of the following:

• bugify projects to list projects, then select one to view issues for that project
• bugify users to list users, where selecting one will list issues for that user
• bugify filters to list your custom filters and then view issues within them
• bugify search KEYWORD or bugify KEYWORD to search issues

I whipped up some icons for issue statuses, and happily stole others from Bugify and Entypo.

Enjoy, and promise to be gentle if you need to point out anything I’ve done questionably.

Download Bugify.alfredworkflow or check out on GitHub.

More than once, I’ve been stuck having to use images where a logo and/or some type is flattened onto a white background. The goal is to achieve something similar to the “Multiply” layer blending mode, but be able to save a PNG with a completely transparent background and no nasty, pixelated artifacts. About a year ago, I found a perfect Quartz-based app (or plugin, I forget which) that could remove the solid background from an image while preserving reflections, drop shadows, and the subtle parts of an image that have more complicated opacity. Unfortunately, I never bookmarked the author’s site nor did I write a blog post or a Tweet or anything that would have been useful.

After hours of searching for said app, I stumbled upon Mikeal Simburger’s KillWhite, a Photoshop plugin (and 64-bit PixelBender plugin!) that does the same thing. And what a relief. It works just as well as the mysterious app I first used, and even better is that Mikeal is working on a version that will key out a selected color.

In an unprecedented frenzy of blogworthy activity, I’ve just created an Alfred workflow for quickly getting the range between two dates. After hours of contemplation, I decided to call it Date Span.

It uses PHP’s DateInterval to take a variety of datetime formats and output the range in various units. For example, give it a single date and it’ll calculate based on the current date and time:

Give it two dates (separated by to ) and it’ll calculate the difference between them:

And just because it’s friendly, it’ll remind you if the date is in the past:

I’m not thrilled with the icon I whipped up for it, and I’ve not tested my theoretical bash-centric guess at timezone detection. And PHP 5.3+ is required.

Enjoy, and please complain about anything that’s stupid!

Download DateSpan.alfredworkflow.zip or check it out on GitHub.

It’s been almost one year since I embraced VPS hosting for projects and published some provider benchmarks I collected. I thought I’d share an update with a few more benchmarks and how I’m hosting things now.

Briefly

I’ve been using Laravel Forge to provision servers, with Digital Ocean or AWS for client projects and Hyper Expert + Impact VPS + VirMach for my own. I tailored a quick restic + B2 setup for versioned backups when provider snapshots aren’t available.

How I’m Hosting Projects

As much as I liked Centmin Mod for its speed, active updates and ease of use, I was still spending too much time provisioning and updating servers.

I switched to Laravel Forge and haven’t looked back.

Forge provisions quickly, uses solid defaults, and is just configurable enough in ways I like. It has a lovely feature called recipes for running scripts on any number of servers, and provisions with with big name providers as well as the smaller ones I like to use and try out.

I’ve kept with Hyper Expert, Impact VPS, and VirMach for most of my own projects because each has been inexpensive, reliable, and well-supported. I can get more CPU for less money than big-name providers, so I do. And in lieu of snapshot backups, I use my own restic+B2 setup that’s been quick to set up, rock solid and cheap. Backups are incremental and similar to Time Machine on macOS, minus the gratuitous time travel UI.

For client projects, I stick to Digital Ocean or AWS mostly for snapshot backups, built in monitoring, and ease access sharing when needed. SLAs and GDPR compliance are also a must, and the larger companies always have clear policies in place.

Field Notes

It seems like no matter the size of the host, random networking issues are a fact of life. No one host has perfect uptime or performance, so I’ve also given up on that as a realistic goal.

I’ve been mostly put out by SSD Nodes. The performance value is real and their “10x” NVMe offering is eye-wateringly fast, I just can’t stomach the constant marketing hype and lackluster support. I’ve tried a few SSD Nodes servers and none has come with any perceivable catch; low (or zero) CPU steal, admirable uptime and response times, and things behave as I’d expect. It seems like once they sell you a decent VPS, everything else is as barebones as it can be. Tough to get excited about.

IonSwitch deserves honorable mention. After I posted my last article Stan reached out privately and mentioned I might want to give them a try. Stan went out of his way to answer questions, share some of what he looks at as measures of strong performance, even shared some of what goes on behind the scenes. Always prompt and thoughtful responding to tickets, good value for great service. I used an IonSwitch VPS for production for a few months until an unfortunate series of networking incidents forced me to move elsewhere. Stan’s response was unfailingly prompt, understanding and unnecessarily generous.

I learned to watch out for CPU wait and steal which can indicate slowdowns from overcrowded hardware or noisy neighbors. I added Server Hunter and NodeQuery to my toolkit and stopped myself from using NetData because that’s just too much information and I have other things I should be doing.

I learned individual core speed is critical for PHP (which makes sense), and that MySQL can scream with multiple cores.

More Benchmarks

I also benchmarked a few more servers since my roundup. I can’t help it, but I’m getting better at exercising restraint.

Note that I’ve usually benchmarked a VPS after finding a compelling deal, so in about half of these cases I was able to score a cheap VPS on sale and benchmark that. There was some hunting involved, but every deal was publicly available at some point.

The Candidates

Measurable Value per Dollar

Closing Thoughts

Nothing profound, just some random notes:

• My crazy cheap Black Friday VirMach VPS has been surprisingly stable.
• ITLDC offered a stable, well-performing server with a control panel that was strange and uncomfortable.
• UpCloud really did outperform Digital Ocean on an equivalent VPS, but marginally so compared to other not-big-name providers. (RamNode being one I’d gladly rely on.)
• SolvedByData offered really strong CPU, but the outages, 100Mbps uplink and support vibe would keep me from seriously relying on them as a provider. My experience with BigPowerHosting was similar—and apparently they’re gone from the internet now.
• Data Packet is the latest host I’ve tried and I’m convinced there’s something downright scandalous going on there, I just haven’t figured out what it is yet. That’s just too many cores for the price.

Thanks for reading, and consider leaving a comment or sending me a message somewhere if you have questions, suggestions or objections!

Non-Affiliate Links

No trickery:

• Digital Ocean
• Hyper Expert
• Impact VPS
• IonSwitch
• RamNode
• SSD Nodes
• VirMach
• Data Packet
• ITLDC
• SolvedByData

I’m not sure why, but in Windows (only!) Firefox 4.0.1 seems to think it’s cool to put a red box-shadow on any input field of the "email" type. Just leaving a note here in case it’s helpful – it’s easy enough to fix:

I started using Sublime Text 2 in March after getting excited about its speed, easy package control, and good reputation. I spent some time this week going through the entire Tuts+ “Perfect Workflow in Sublime Text 2” course by Jeffrey Way and realized how much I’ve been missing. I would strongly recommend this free course whether you’re interested in Sublime Text 2 or are using it with the nagging feeling that you should level up.

I’ll sum up my favorites (old and new), but it’s seriously worth your time having Jeffrey show you each in more detail.

It’s all text

The preferences are stored and edited in JSON files. The packages are uncompressed folders that simply live neatly in Sublime’s Application Support folder. (Both of these things, by the way, make it very handy to sync everything with Dropbox.) The project-wide search returns results as a flat text file in a new tab. Sublime is all about text and the keyboard, with very little UI that requires or uses anything else. You can rely on the mouse less as you get more comfortable, without the frustration or slowdown of jumping right into the terminal for text editing.

Ditch the sidebar forever with ⌘+P

Never hunt through files and folders again, just type the name of what you’re looking for whether it’s a path, a method, or … well anything. Tack on an @ symbol to a filename and all methods will be listed so you can jump in exactly where you’d like.

Do (almost) anything with the Command Palette ⌘+⇧+P

Anything Sublime can do will be accessible here so you can stay off the mouse even if you don’t have all the shortcuts down. Change syntax on the current file, install or remove a package, access snippets or build options – really just anything. It’s Alfred, but in a text editor.

Multiple Cursors & Incremental Search

I shouldn’t admit to you, dear reader, that I was happily working away in Sublime Text 2 completely oblivious to its multiple cursors. Sure, you can ⌘+click several things manually and get a new cursor for each one. But that’s little beans.

You’ve already noticed that every time you select a word, every instance of that exact same thing is highlighted. Hit ⌘+D and the next occurrence of that word will be selected with its own cursor. Repeat until you’ve got enough of them selected, then just type to change them all at once.

But it gets better: say you want to select every occurrence of that word instead of hitting ⌘+D repeatedly. Let’s do that. Start by placing your cursor inside any given word, then hit ⌘+D once to select the word. Now hit Control+⌘+G and every occurrence will be selected with its own cursor. Simple and extremely useful.

Snippets

We all know that snippets are essential time-savers, and you probably already know that Tools → New Snippet will give you a (simple) template to edit and save as a .sublime-snippet file in your User folder. Jeffrey gets into setting up GitHub Gist integration and a few other helpful pointers.

Package: Package Control

Install Will Bond’s Package Manager first, and install it now if you haven’t already. Most Sublime packages are current and available through this channel, making it an absolute must if you want package discovery/installation/update/removal to take only a few keystrokes and a few seconds.

Package: Zen Coding

Use a simple, logical shorthand to quickly generate HTML structure. It’s more compelling to see this in action, but the idea is that you can write something like div#nav>ul>li*5>a to hit tab and get…

Obviously you can do quite more than this, and it applies to CSS authoring as well.

Package: Fetch Files and Packages

Commissioned by Tuts+, this package lets you define preset file and package shortcuts so you can get a project running quickly. Simply put, it takes a predefined URL and downloads it (extracting, if necessary) to whatever directory you specify from within Sublime. I added shortcuts for jQuery, variations of the Twitter Bootstrap, the HTML5 Boilerplate, and CodeIgniter.

Package: Fast Folder & File Creation

I’m not sure why this wasn’t built into Sublime in the first place, but the AdvancedNewFile package lets you use ⌘+⌥+N to type a folder/file path and hit return to create it. This saves having to use the standard OS GUI to save a newly-created file.

Package: Sidebar Enhancements

I started using this a while ago, but in light of my newer discoveries it’ll certainly become more trivial. Anyway, use Sidebar Enhancements to get more right-click options in your sidebar.

Package: Sublime Linter

A great package that’ll check your syntax as you write, or as you save depending on how you set it up. You may have to do a little bit more work setting up linters depending on what languages you use, but the workflow improvement is surely going to be worth it. Unless you never make typos or mistakes. In that case, please contact me because I would like to talk about hiring you for everything I ever do.

Package: Sublime + Marked

I tend to use Byword for writing posts like this in Markdown, but this part of Jeffrey’s course led me to better appreciate the build system. To me, “build” always meant compile source code into a binary executable of some kind, be it a Cocoa app or a Flash/Air program. Here, Jeffrey demonstrates how you can author your Markdown and then set up a custom build, effectively launching Marked (an inexpensive Markdown viewer) with ⌘+B to view your work in HTML.

Bonus Package: Less Compiler

After seeing Jeffrey’s Markdown+Marked screencast, it dawned on me that I should be compiling Less from Sublime. (Wipe that look off your face, it just never occurred to me okay?) Sure enough, there was a package for that: LESS-build-sublime. Do some work, ⌘+B, and compile that .less into .css. Easy.

Much of this may be review, or overly simplistic for those wizards who have mastered Sublime Text 2. This is one of those posts I’ll probably be referring back to myself, and hopefully you’ve gotten something out of it as well!

Is there something you’ve stumbled on that you can’t live without? Let me know!

Update: I forgot to mention in my original post that it was Ross Hunter’s post that kicked off my latest quest to improve my Sublime workflow, and it’s probably to his credit that I ended up spending a few hours with the Tuts+ series. Thanks Ross!

January 2015 update: I reinstalled GMVault again, and David’s comment below was worth detailing in a new post. Read the updated post.

Update: I kept getting IMAP abort errors to the tune of Gmvault ssl socket error: EOF. Connection lost, reconnect., and a GitHub thread suggested I turn off IMAP compression in gmvault_defaults.conf. That fixed the problem for me, and now I’ve got completely clean, error-free backups.

A Synology DS214 recently made its way into our home, and I’ve been busy devising ways to grow our new private cloud. After pulling and crimping some CAT6, installing some nice drives, and a rather effortless setup thanks to DSM 5.0 (Synology’s own surprisingly nice software), I’ve got a headless server with plenty of RAID-protected disk space and dirt cheap, off-site Glacier backups. It does a bunch of cool things out of the box, and I decided my first challenge would be to automate Google Apps email backups.

Background

I have separate Google Apps accounts for personal and business use, and for business I’ve been using Backupify for almost a year and a half. For $3/month, Backupify required zero setup and faithfully kept all my Google Apps data backed up and available to restore at a moment’s notice. There’s nothing I’d change about the service, I just did the math and decided I’d take matters into my own hands. For “fun.” And with all the savings, I can afford an extra two-thirds of a cup of coffee every month!

Now here’s the best part: I managed to do this without installing ipkg. That’s a well-known and well-documented bootstrap for Synology devices that gives you access to a whole world of updated, third-party Linux packages. I’m still attempting to avoid it, only because I’ve read that firmware updates can require re-integrating ipkg, and I’m wary of jumping in after earlier regrets over iPhone jailbreaking. In other words, I’m a baby.

But avoid I can, because DSM 5.0 comes with cron, shell access, and one-click installers for Python 2.7 and Python 3. This means that all I have to do is get GMVault running and move on to the next challenge!

Jimmy Bonney’s post got me most of the way there, and a comment from David Cumps and some old-fashioned trial and error saw me through the rest of the way.

The Setup

I have shared folders for work and personal use, and my setup in each is identical. There could be a better way to do this, but so far all’s working well. For each shared folder, I have…

• mail-backup/: a directory that GMVault can use for its repository, which is a series of dated year-month folders containing two files per message: JSON meta data and a compressed package with the message body and attachments
• utilities/: the directory I used to install GMVault and where I’ve placed backup scripts for cron
• utilities/log/mail-backup/: a directory that gets dated plain text logs every time the backup scripts run

I’ve cobbled together two shell scripts, one that runs daily and syncs in quick mode, and one that runs monthly to ensure a full sync.

email-backup-full.sh: Mark and timestamp the beginning and end of the sync process, print environment variables at runtime (helpful for debugging permissions issues if you don’t run as root), and log gmvault’s output while it attempts to sync.

email-backup-quick.sh: Ditto the first script, just put gmvault in quick mode instead of full.

Process

1. Install Python 2.7 (labeled “Python”) from the DSM Package Center.
2. Create directories in a shared folder for your backup repository, logs, and a place to set up GMVault. (Mine are mail-backup, utilities/log/mail-backup, and utilities respectively.)
3. SSH as root into your utilities directory, and curl -O https://raw.githubusercontent.com/pypa/virtualenv/master/virtualenv.py -k to install a virtualenv¹.
4. python virtualenv.py gmvault_env to install GMVault in the virtualenv from the previous step.²
5. sh /volume1/yourfolder/utilities/gmvault_env/bin/gmvault should now run GMVault and give you an error for having too few arguments.
6. Place your full and quick backup scripts somewhere—I put mine right in the utilities folder. Remember the full path to each script for step 8.
7. Authenticate with Google Apps once, running some variant of sh /volume1/yourfolder/utilities/gmvault_env/bin/gmvault sync --emails-only -t quick --db-dir /volume1/yourfolder/mail-backup/. Read, hit enter, paste the unique URL into your browser, allow access from the browser, and you can end the gmvault instance prematurely once the authentication’s done. Auth tokens will be stored in /root/.gmvault, along with gmvault defaults that you can edit.
8. Schedule these scripts to run automatically with Task Scheduler, which you’ll find in the Control Panel. Create a new User-defined script and give it a name, run as root, and in the User-defined script textarea add: sh /volume1/yourfolder/utilities/backup-email-full.sh. Schedule it to run when you’d like (or temporarily at short intervals to test), then repeat with the backup-email-quick.sh script.

That’s it! I’ll probably try and figure out how to detect failures and fire off an email, but at the moment I’ve got working daily backups of two Google Apps email accounts. The initial sync for each ~4GB of mail took 3-4 hours, and subsequent quick syncs only take a few minutes. As a bonus, when you allow GMVault to compress messages the total size of the backup will be a fraction of what Google reports for your disk usage.

Check out GMVault’s options for more ideas, and let me know if you improve my humble first attempts to get this working! As usual, my Python and shell scripting is a bit on the infantile side.

This is an update to an earlier post about working with DDEV.

One limitation was that symbolic links didn’t work with local, out-of-project file references—like when you’d have composer use a local Craft CMS plugin that's not part of the project structure:

I solved this the hard way by running a script that used fswatch to detect changes to foo-craft-plugin and rsync them into my local project tree (my-current-project/plugin).

The easy way, it turns out, is to just mount that plugin directory into the container by creating .ddev/docker-compose.mounts.yaml and mapping the local path to one in the container:

After a quick ddev restart the volume will be mounted inside the container.

It's important to remember is that the local (Mac) filesystem doesn't know about this arrangement, so composer updates need to be initiated from inside the container.

This may not be all that new, but I’m glad I finally stumbled onto it!

A post from @typaulhus on ADN was the first I heard of this “Statamic,” and after a brief period of skepticism I’m head-over-heals for it. Statamic has officially replaced ExpressionEngine as CMS of choice for this humble little site. Why is it so exciting?

• No database. Fast, easy to deploy, and I can keep everything in Git without doing anything clever.
• Content is stored in Markdown files. This is a huge plus because I write just about everything longer than a paragraph in Markdown and then I have to figure out how to get it into that other thing. I can skip that step.
• Very clever design. It’s very clear that Jack and Mubashar wanted to get away from EE’s bloat while taking advantage of its templating convenience and … well … Structure. It feels perfectly focused as a CMS for small sites and blogs, while being flexible enough to work for web creators that have ideas beyond a WordPress theme.
• Gorgeous admin panel. Blazing fast and perfect on an iPad? Yes and yes. If you think that’s shallow, log in to EE’s admin panel on your iPad. I’ll wait.

The migration from EE went smoothly and happened more or less in one evening. Here’s how I did it…

Step 1: move comments to Disqus.

I was using native EE comments, and the easiest path here was to create a Disqus account for the site and import my previous comments. Ryan Battles posted a template tutorial for exporting a WXR file for Disqus. It’s as easy as creating two templates with just a little bit of required consideration.

I foolishly waited quite a while and even opened a support ticket before finding import.disqus.com, which barfed on a syntax error in my XML. I waited another 24 hours and got an import error with no message, and then frustratedly hacked my way through two ExpressionEngine addons and two more Disqus test accounts before I got everything straightened out. For the record, I’d recommend going with CX Disqus Comments if you also run into problems.

Step 2: get EE posts into Markdown files.

Once again, somebody else did most of the work for me. This time it was Derek Jones with the Download Content plugin for ExpressionEngine. I created a template that listed all my posts, each with a link that would download that post in a Markdown format I specified¹. I just command-clicked on each item (silly and effective) and ended up with a folder of posts ready for Statamic.

Step 3: make that new theme.

I copied "london-wild" and went to town with it. As you can guess from my site, half my work was just deleting things I didn’t use. Coming from EE, the theming process felt very familiar. Imagine ExpressionEngine with native Structure bits, but mustachey-looking.

The only sacrifices I had to make were dropping an email contact form (for now) and doing without numbered pagination.

Step 4: consider the URLs.

My blog posts went from /blog/entry/title to /blog/title, so I added a line to .htaccess for redirects:

Redirect 301 /blog/entry/ /blog/

Since I had only six pages of blog posts, I added quick-and-dirty redirects for EE’s pagination links too:

Redirect 301 /blog/P6 /blog?page=2
Redirect 301 /blog/P12 /blog?page=3
Redirect 301 /blog/P18 /blog?page=4
Redirect 301 /blog/P24 /blog?page=5
Redirect 301 /blog/P30 /blog?page=6

Step 5: launch.

The easiest part. Moved all the EE stuff into a doomed folder, dropped all my files right into the doc root via Git. And then I … here’s the thing … and then I was done. I hope you have a rocking time with Statamic too!

My Statamic-generated page titles have been a mess because of extra whitespace and line breaks, which I eventually decided was unacceptable. I took inspiration from a Twig extension for killwhite, which removes excessive spaces and trims out tabs and returns.

So this...

...which might have generated...

...just gets wrapped with a {{ killwhite }} tag...

...and the result is beauty we can all appreciate:

I got Storybook working again for my Gatsby JSX components and found a nice, simple way of switching between dark and normal styles.

Background

Storybook is a lovely tool for developing and cataloging UI components. You can add it to your codebase, write brief “stories” for components to document and mock data to feed them, and spin up a nice browser UI. You can also generate static output to host wherever you’d like.

I’ve added Storybook to projects that use Twig, Vue, or React. Two reasons:

1. It’s a nice way to work.
   I can use Storybook like a workbench and focus on one component at a time without concern for the CMS. Hot module reloading (HMR) keeps things fast and fluid. Storybook’s tools make it quick to mess with inputs, modify the viewport, and run accessibility checks. (Among other things.)
2. It’s a useful way to review work in progress.
   Storybook URLs can jump straight to specific components and variations, facilitating discussion about new UI outside the context of the production site. Stories accumulate into an always-current reference, which is particularly useful planning with designers and content authors.

The dark mode bandwagon is a bumpier ride.

If you’ve added dark mode CSS to a project, you might have found it clunky checking your work toggling system or browser settings. Like checking print stylesheets, it’s inefficient enough to add drudgery and pull you out of The Zone.

There’s already an addon for switching the Storybook interface to and from dark mode, but I want to simulate dark mode for the components themselves.

Storybook has an event system you can subscribe and react to, and this dark mode addon fires an event when the UI mode changes. All that’s left is to let the component preview pane know what mode to display.

I had to make two changes to my project: one to my strategy for applying dark mode styles, and another to the Storybook setup.

First, I switched away from using a media query to apply dark classes with @media (prefers-color-scheme: dark). Instead, I decided I’d detect that setting with JavaScript and apply a body class. This makes JavaScript a requirement, but it means I can honor the visitor’s browser setting by default and expose the dark scheme as an option on the site.

Now that I could toggle dark mode with JavaScript, the next step was ... to toggle dark mode with JavaScript. In Storybook, this meant listening for a change to the dark mode UI preference and responding accordingly. This was a matter of adding a few lines to .storybook/config.js, simple enough I nailed it on my very first try. 🎉

The change for the site was nearly the same. Let’s take a look.

The Steps

1. Set up Storybook.

Add Storybook to your project and write a story for your favorite component.

2. Install the dark mode addon.

github.com/hipstersmoothie/storybook-dark-mode

3. Write dark mode styles.

You’ll need styles meant for dark mode, applied when the document’s body class is .dark. I have some PostCSS that looks like this:

Tailwind isn’t important here, but side note if you use Tailwind: there’s a plugin for adding dark mode utility classes. I haven’t tried it yet, but its strategy is similar requiring a mode-dark class applied to the html element.

4. Respond to Storybook UI mode changes.

Add the following import and snippet to .storybook/config.js:

This will toggle a dark class on the body of the component preview pane when the Storybook UI theme changes.

5. Add the dark mode class with your site/app.

Make sure your project handles the body class, too!

This step is optional for the purpose of this post, but if you forget you may wonder why your dark mode styles never work outside Storybook.

I chose to do this in my layout component, passing the desired body class to Helmet:

There’s a similar example, classing the html element, in the tailwindcss-dark-mode project: prefers-dark.js.

This strategy relies on the style cascade, so I’m not sure how useful it will be in a CSS-in-JS world but I’ll deal with that when I get there.

I’m hoping somebody’s as thrilled as I am to toggle back and forth easily!

Background

It’s rare that I have a Markdown-related thought for which Brett Terpstra hasn’t already made some elegant thing, but for once I think I’ve done it!

After buying just about every Markdown writing app there is, I’ve finally circled back to Sublime Text 3 with Terpstra’s Markdown Editing package and Marked 2.

Federico Vittici’s epic review of Editorial, a really impressive iOS text editor, prompted me to give it a try, and one particular workflow has been tickling my fancy ever since: compose your message in Markdown, then in two taps pipe the rendered HTML message to Mail.app. Wonderful!

Naturally, I wanted to be able to do this on the desktop as well. To my complete surprise, Mr. Terpstra had not yet graced us with a solution for this, and neither did the internet at large. Months later, I posed an iffy question on Stack Overflow: can I use Python to get Markdown from Sublime Text 3 rendered to an email client? User fanti swooped in almost immediately with an alarmingly thorough answer. So I had no choice but to pick up the quest.

Disclaimer

I’ve only ever hacked away at Python and AppleScript, and I am no authority on either one. I’m simply sharing my progress with the hope that you’ll learn something from my baby steps or just get your Markdown-to-email workflow started.

As usual, if your computer explodes or the universe collapses on itself because of anything here, that’s your problem. No warranty.

Overview

We’re building a Sublime Text 3 build system so that we can hit ⌘+B and ship our Markdown off to Sparrow¹.

Step 1: Install markdown2 module, set up converter script.

We’re going to have Python convert Markdown into HTML, so we need to install Python’s markdown2 module (thanks again, Stack Overflow!):

Now, save a file called convert.py somewhere handy – I keep mine with other scripts in my Dropbox folder:

This is where all the magic happens, and it took me a few hours to get it working properly with lots of Googling and successive failures learning opportunities.

We’re reading the specified text file, using markdown2 to convert it to HTML, escaping the result, then creating and calling ActionScript that gets piped to Sparrow. Even for uninitiated, this probably makes sense.

If you’ve never used Python before, be careful copying and pasting these examples! Python loves – needs, even – tabs and not spaces, so be sure to keep tabs preserved exactly as they are.

Step 2: Create the new Sublime Text build system.

Go to Tools → Build System → New Build System and add your new build:

Save this file in Sublimes Packages/User folder with a name like MarkdownToEmail.sublime-build. This will make the build system available within Sublime Text, where after a restart you’ll find it under Tools → Build System → MarkdownToEmail.

Note that my Python path is /usr/bin/python – you can check yours by opening Terminal and running…

…and your full python path will be printed for either verification or a new round of confusion.

Step 3: Try it!

Now you’ve got everything in place to compose a message in Sublime Text. Set your new build system and hit ⌘+B to render HTML in a new Sparrow message window. Hopefully it works, and if not you’ll want to do some troubleshooting:

• Are your paths all correct?
• Can you run convert.py from the command line, outside of Sublime Text?
• Did my feeble convert.py choke on a character or encoding that I hadn’t planned for or tested?

Other Ideas

This could clearly be improved. Ideas I’ve had thus far…

• Populate the subject with the name of the file, or even use YAML to set a subject, recipients, etc.
• Add an option to automatically delete the original Markdown once it becomes an email message.
• Figure out how to get this working with Mail.app and clients that other people actually use.

Let me know if you have any more ideas, run into problems, or if you’ve got any tips or objections!

It’s no secret that I’m a fan of Webfaction. For me, the $9.50/month standard service has replaced crappy shared hosts and even some Media Temple DV servers. Webfaction combines the ease of a shared platform—think Media Temple (gs) or your typical $3/month host—with the speed and flexibility of a VPS. The handful of Craft sites I’ve set up on Webfaction fly, with great speed and solid uptime.

If you’re new to Webfaction, there’s a learning curve that can make your first site frustrating to set up. The control panel will undoubtedly be different from what you’re used to, even if it turns out to be really simple. (You may eventually like it, even!) I’ll attempt to help you make sense of things and get your first site up and running in short time.

The key thing to understand is what a Website is in Webfaction’s terms: an Application assigned to one or more Domain Names. This means that to create our Craft site, we’ll set up the pieces and link them together. You can read more about Webfaction’s unique, organized setup in their Applications and Websites guide.

Pros

• Bang for your buck: the fastest, most stable hosting I’ve found for the least amount of money.
• You don’t need to be a sysadmin: you don’t maintain server software, worry about security, or bother with networking issues. Smart, qualified people do that.
• Support tickets are addressed quickly and thoughtfully, no “did you turn it off and on again?” run-around.
• MySQL is particularly fast since it runs in a separate container with its own (free) memory.
• Different geographic locations to choose from: US, Europe, Asia (hint: choose the one closest to your primary audience).
• You can pay to upgrade your resources, so there’s some peace of mind knowing you can scale if/when you need to.
• It’s possible to SSH in and install software on the server, so things are more flexible than you might be used to with a shared platform. More like a VPS in that way.
• The platform is organized and pretty clever, with modern software versions and some thoughtful app install shortcuts. (But no tacky 1-Click garbage!)

Cons

• No phone or live chat support, which could be a shock if you’re coming from Media Temple.
• You’re limited to one set of control panel login credentials, which can make for a funny little shuffle if you’re sharing the account with a client.
• You’ll have to deal with a minor learning curve as you set up your first site.

What You’ll Need

• a Craft site you’ve built, ready to check out from GitHub or Bitbucket
• a MySQL dump of said Craft site
• a spirit of adventure

Getting Down to Business

What we’re going to do is check out our project repository and point a symbolic link to it. The folder structure will end up like this…

1. Create your Webfaction account, using my referral link if you’re a kind soul, or not if you’re sick of those dirtbags that sprinkle referral links everywhere. Use PayPal or a credit card to plunk down $9.50 and get full access. Choose your username wisely, as it’ll be the basename of your account and used as your site preview URL (i.e. username.webfactional.com).

2. Clone a copy of your Craft site by SSHing into your account (ssh username@username.webfactional.com) and creating a project folder. You’ll start at /home/username, so mkdir craft-site to create /home/username/craft-site. Step into this folder with cd craft-site and then git clone your Craft project here. (Something like git clone git@bitbucket.org:acme/acme-craft.git ..)

3. Create a new Application in the Webfaction control panel. You can do this by choosing Domains/Websites → Applications → and Add new application. Pick a sensible name, choose Symbolic link for the App category, and choose the latest PHP option among the Symbolic link to static/cgi/php5x variants. For Extra info, specify the path of the public folder for your Craft project. In this case, it’d be /home/username/craft-site/public.¹

4. Create a new MySQL database under Databases → Databases → Add new database. Pick a name, use MySQL, leave Encoding alone, and create a new user for the database and squirrel away the connection details.

5. Import your MySQL dump by using Webfaction’s phpMyAdmin or connecting a desktop client like Sequel Pro through an SSH tunnel.

6. Add your domains under Domains/Websites → Domains → Add new domain. These won’t do anything yet, we’re just telling Webfaction we’ll want to use them. If your website is acme.com, here you’ll want to add acme.com www.acme.com.

7. Finally, add a Website from Domains/Websites → Websites → Add new website. Pick another name and skip to domains, where you’ll use the type-ahead field to select the domains you just added in step 5. Choose Add an applicaton → Reuse an existing application, and pick the one you created in step 3. This is a good time to also assign your preview domain (username.webfactional.com), if you want to take a look at your site before pointing your domains to Webfaction. Save and you’re done!

Now that the setup is finished, you’ll want to introduce Craft to your new environment details by editingdb.php and general.php in the craft/config/ directory. I’ll assume you’re already using multi-environment configs and you know how to do this.

Did I miss or fail to illuminate anything in this post? Let me know and I’ll get it updated!

If you’re like me, you’ve used MAMP Pro for years because you work on a Mac and it’s easy to get a PHP site running in a few clicks.

You first approached the command line as one would a wounded bear, but you’ve increasingly found it to be inviting and liberating. You’ve poked at Vagrant, been wooed at the idea of Docker, and you’ve soldiered on with MAMP because you haven’t found a way past it that sticks day to day. You may be wary of those who espouse command-line-first tools, because the tingle of excitement is normally followed by hours of stumbling over broken dependencies of which zero were obvious.

Take heart! I’ve finally found my local development champion in DDEV and I’ve been happily using it for more than a month. Let me reiterate: happily. More than a month. Not a single moment of weakness when I had to go back to MAMP just to do that one thing. DDEV isn’t perfect, but it’s been a welcome MAMP replacement and I’m going to try and convince you to try it.

DDEV?

DDEV isn’t a prepackaged Mac app like MAMP, but a command line tool that manages Docker containers for development.

Like MAMP, it’s easy to work with and it comes with the innards you’ll need for working with LAMP/LEMP apps. Unlike MAMP, configuration lives quietly within each project (which you can version if you want!) and the machinery is all powered by Docker containers. That difference is important because those containers are more efficient than individual virtual machines like you might run with VirtualBox and Vagrant. They’re not as efficient as MAMP, but each project container runs its own software stack and can be fully customized—very much unlike MAMP. These containers are also fully isolated, so (like MAMP) they don’t have to care about whatever software you’re running natively on your Mac.

DDEV is free and actively maintained, as are similar systems like Lando, Docksal and Devilbox. The purpose of this post isn’t to compare options, but I’ll at least mention that I stuck with DDEV because almost every problem I encountered had an answer, whether by design or documentation or mention in a support issue. It required the fewest changes to my workflow and could be tailored most easily wherever I was forced to evolve. Each of the above was easy to get started with, and DDEV kept making sense as I went.

Pure Docker containers (or docker-compose directives) would be great, but I haven’t developed enough proficiency to actually ditch MAMP and use Docker that closely day to day. DDEV provided just enough to get me over that wall. If you’ve already considered using Docker for local development, spin up a DDEV project and examine the difference between the yaml you define and the docker-compose.yaml DDEV generates for you. That difference, very precisely, is DDEV’s appeal: it abstracts what might otherwise be a bit too complicated for daily use.

DDEV Pros

• Great for Craft CMS, Statamic, Laravel, and ExpressionEngine projects. Pick Apache or nginx in your config, choose a PHP version (back to 5.6), and ddev start to spin up the project.
• Assumes you’ll want to be working locally (and offline) just like MAMP, and automatically attempts to manage /etc/hosts changes for your *.ddev.local or custom development domain.
• The standard PHP setup happens to come with all Craft requirements, including ImageMagick and GD. Default Apache + nginx setups will play nice with clean URLs, and you can season to taste easily with your own .htaccess, nginx.conf, and/or php.ini.
• Easy database management: quick commands for taking snapshots, importing dumps, and launching PHPMyAdmin or Sequel Pro.
• Crazy ability to customize if you’re willing to experiment a bit with Docker and Linux. Also a nice way to learn about Docker since you can peek behind the DDEV curtain to see how it works, and further customization will mean getting closer to Docker and not some odd contraption a Gandalfish character maintains from a remote mountaintop with spotty satellite internet.
• An alpha GUI if you just can’t break the habit.
• Regularly updated, pretty thoroughly documented, and supported by friendly and responsive folks.
• Working on a project and actually getting stuff done without MAMP will make you feel a keen sense of triumph.

DDEV Cons

• Hyperkit, which is required to run Docker on a Mac, has often taken an absurd amount of CPU on both (Mojave) Macs I use regularly. Your mileage may vary, and I’m counting on this eventually being improved.
• Docker downloads entire images as it needs them, so it can quickly take more disk space than MAMP if you tend to customize your environments. This can be managed, but it could be a deal-killer if you work on a laptop without ample free space.
• If you develop Craft 3 plugins and use symbolic links that reach outside your current project, the complexities of volume mounts mean you’ll want to rsync files into your project. (Or deal with either an incredible performance hit or a solution I’ve not yet found.)
• Though every site gets https support by default, the self-signed certificate means you’ll have to live with browsers being cranky. This is a huge drag when you’re working with an app like PageLayers that doesn’t allow you to ignore self-signed certificates. No longer true since DDEV 1.8.0.

What it Looks Like

Once you’ve installed DDEV and Docker for Mac, you’ll run ddev config from your project root to initialize some .yaml in a project-relative .ddev folder.

Rather than loading MAMP and switching on its server, you’ll just ddev start from a project root. If you forget how to access your site or database, just ddev describe:

You can use ddev stop to shut down that project, or ddev restart to turn it off and on again. While you’re working, it can be handy to run ddev snapshot and ddev restore-snapshot for jumping between database states.

There are a few more utilities that can be useful as well…

If looking at ddev -h output makes you uncomfortable, you can go and download the alpha DDEV UI. It’s not nearly as full-featured as MAMP’s UI, but it’ll let you see all your projects with their status and give you the ability to start, restart, and stop each one.

If you’re still reading I’ll assume this is theoretically interesting. Let’s look a little closer at what’s going on and start up some Craft projects.

Getting Started

You’ll need to install Docker and DDEV. If you’re on a Mac with Homebrew installed, you can run brew cask install docker and then brew tap drud/ddev && brew install ddev.

If that went well, choose an existing project and open a command prompt at its root. In VS Code, this is a quick ^+~. Initialize your project with ddev config, which will ask for three things:

1. The project name, which defaults to the parent folder and is used for a *.ddev.local domain.
2. The web root.
3. The project type, which is php unless you’re using any of the listed options.

This will create a .ddev folder within your project:

The config file is pretty simple, with a commented section afterwards (which I’ve omitted here) explaining some bits and pieces you may want to customize.

Not too scary, right? Run ddev start to get the project running. DDEV will ask for your Mac password if it needs to edit /etc/hosts for a custom local domain.

You’ll probably want to import a database. Drop a .sql or .sql.gz file someplace near your project and use ddev import-db and interactively provide a path. You can also do this in one command with ddev import-db --src=db.sql, or open PHPMyAdmin with the link listed in ddev describe if you’d just rather use a GUI.

If you’re curious about what’s going on behind the scenes, look no further than the docker-compose.yaml file that was quietly created in your .ddev folder. You may already know what this is, and appreciate that DDEV generated it for you. If you’ve never seen any of this docker-compose business before, this is a configuration fed more directly to Docker that tells it what to do. You don’t have to look at or change anything here, and you probably shouldn’t change any part of it, but it’s a fun place to look if you want to get a better feel for how everything works.

Sample Craft 3 Setup

I added a few more things to my standard Craft 3 project setup. It takes a few more seconds to copy in files and make an edit, but it’s still quicker to get a project going than it would be with MAMP. I keep the .ddev folder versioned (without changing its gitignore) so another developer can check out the project, ddev start, and be on her way—so these steps only apply to when I’m first adding DDEV to a codebase.

First, I add a simple setup script hook. Tell config.yaml to run a shell script after everything’s started:

This will run setup-craft-3.sh, which I’ve dropped into .ddev/scripts:

I keep Craft 3 environment settings in a .env file, and this script just checks to see whether one already exists. If so, it doesn’t do anything. If not, it copies one into place and sets Craft’s security key.

Contents of .ddev/.env.ddev.example:

Edit 12/9: Note that there’s no DB_PORT specified here. DDEV chooses a new MySQL port every time your project spins up, so we need to let it expose its own DB_PORT environment variable (as it does by default).

Even more excitingly, I add a file specifically named docker-compose.environment.yaml:

This sets environment variables for the server, which you can of course customize however you’d like. Note the last commented-out line, which just reminds me to enable redis for environments that use it.

There’s redundancy in the .env and environment variables above, but this is all you need to add to have your Craft 3 projects up and running smoothly with DDEV! A modern Laravel or Statamic project would look very similar.

You can go on to specify whether you need apache or nginx, provide a custom nginx config, and more. I’ll just set this right here.

Sample Craft 2 Setup

Older projects may not rely on environment variables for setup, but hopefully you’ve joined me in embracing multi-environment configurations for Craft 2, ExpressionEngine, and that old custom thing you clobbered together.

Craft 2 still works great with PHP7+, so you can add docker-compose.environment.yaml to your .ddev folder to supply database settings:

One more step, however, is to grab those settings using getenv() in craft/config/db.php. Mine look mostly like this:

Ancient Projects

There might be a dusty old project or two that have you eyeing MAMP again, but don’t do it! You can edit your DDEV project configuration to go back in time to PHP 5.6 with php_version: "5.6", and if you’re lucky enough to be using multi-environment configuration you can set up yourproject.ddev.local with DDEV’s database settings. If you haven’t noticed already, the database name, username, and password are all db. Sort of easy to remember, and okay since we’re just working locally.

DDEV So Far

I’ve actually enjoyed working with DDEV. If after all this glowing praise you’re left wondering why you wouldn’t want to use it instead of MAMP, I’ll give you my top two reasons:

1. Hyperkit’s performance can be a dumpster fire. Emphasis on fire, which may actually start if you’re working on a laptop wearing highly flammable pants. CPU usage can be nuts. I’ve had the best luck limiting Docker to 2 CPUs, giving it 10GB of memory, and 1GB of swap. Also limiting mounted directories to ~/.composer, ~/.ddev, and ~/Documents/git (where projects live) and making sure Docker’s storage uses a .raw disk image.
2. You can’t neatly symlink Craft 3 plugins outside your project via composer. This is because of how file mounts work. You can symlink plugins from within the project just fine, but if you’re working in ~/Projects/foo with DDEV your composer symlink to ~/Projects/craft-plugin won’t work. I’ve either temporarily moved the plugin into the project or put rsync on watch.

I’m thinking that each issue will be smoothed out one way or another, and overall I’m still happy I’ve made the switch. Let me know what you think if you end up trying it!

Every few years, GoDaddy acquires my web host of choice and I embark upon a technical pilgrimage to greener pastures. Webfaction has been the latest victim and I’ve decided to run my own VPS and shop around for the right software and provider.

Things have been good with Webfaction, and I’ve defended its shared platform which stands apart from any other I’ve experienced. Every now and then noisy neighbors would be an issue, but sites sped along nearly as if hosted on a VPS with plenty of memory and CPU. (This includes shared service and the first two cloud levels, about a dozen accounts. I would have included it in the benchmarks below, but the sustained CPU usage had the test processes automatically dropped before they could finish.) Some servers were more stable than others, but most were unfailingly fast and rarely down. But if there’s one thing I can’t forgive, it’s being acquired by GoDaddy.

My humble sites don’t see a lot of traffic, so a single server instance behind Cloudflare works great. My goal is to find the fastest VPS I can, as close to me as possible, at <=$20/month with at least 99% uptime. There’s a lot of subjectivity and my approach is hardly scientific, but I enjoy comparing what’s out there and hope my notes might be interesting or useful.

Software

• ServerPilot
• RunCloud
• Laravel Forge
• Moss
• Cloudways
• Centmin Mod 👍

After trying (and retrying) a few provisioning/management services I decided I’m ready for more direct control over the VPS. I’m finally comfortable enough with Linux to ditch a web-based GUI and keep things lean. Centmin Mod lulled me away from Ubuntu into CentOS. It’s an actively-maintained suite of shell scripts and tools that provision and maintain a CentOS box with lots of fine-tuning for speed and common web server usage. Most importantly for me, it provides a reassuring amount of structure, optimization, and community support when I might otherwise feel like I’m in too deep. George’s notes, benchmarks, and comments are all insightful and often reassuring.

Service Provider Goals

I had an experimental 512MB RamNode VPS a few years ago and got used to noticing its 100% uptime as I checked on other “more serious” servers. I’ve since deployed projects on cool platforms like AWS, Digital Ocean and fortrabbit, but thought it’d be fun to look around and see where I could maximize performance per dollar. There are tradeoffs with cheaper hosts: monitoring, backups, instant provisioning and hourly billing are all nice (if not essential) and rarely offered by budget providers. Since I’m experimenting with my own projects and not client sites, I’m comfortable working those things out for the sake of learning. I ended up trying out servers from RamNode, SSD Nodes, HostUS and Hyper Expert, comparing against Digital Ocean, Vultr and AWS to see how things would stack up.

My interests are…

1. Memory, CPU, and fast storage, because I want sites and apps to be as fast as they can.
2. Network bandwidth, in case the usual trickle ever becomes a flood.
3. Cost, as I’m ruthlessly cheap with my own hosting and my low-traffic sites don’t warrant exciting infrastructure spend.
4. Location/latency. I’m in Seattle and short pings make everything feel fast.
5. Support, which should be competent and able to respond to coherently-submitted tickets within at least a few hours.
6. Stability: reasonable load and strong uptime.

Cheap VPS Challengers

I wasn’t trying to find servers that’d closely match each other feature for feature, but compare different things and see what I could learn. Let’s see how various <=$20/month options stack up first, then we can compare on performance later.

I profiled 23 different servers over the course of four weeks. I’ve omitted all kinds of gleeful and superfluous detail so it looks like it wasn’t just some obsessive spree. (It was.)

OpenVZ vs. KVM

The type of virtualization may not be hugely important for hosting a few PHP projects, but I think it could be important particularly for low-resource plans.

In each case, a physical server somewhere is being divided up for multiple customers. The more accounts a hosting company can get onto that hardware, the more money they make. We want them making money because we want them to keep existing, offering support, and having an interest in keeping things fast and stable. At the same time, fewer neighbors means you get more of that hardware to yourself as a customer. Better performance, increased stability, more power. The divvying up happens via virtualization, which often comes in two flavors: OpenVZ and KVM.

I’m not a virtualization expert, but my takeaway is that OpenVZ is a bit leaner and more limiting. A KVM VPS has you running your own kernel, meaning you can do more with it but you also pay the performance overhead of running the entire kernel. OpenVZ containers all share a kernel and will thus be more limited by a host. Your resources, however, are more devoted to applications and the business end of whatever you’re doing there.

Performance-wise, I don’t know that OpenVZ or KVM virtualization made a whole lot of difference. My only practical takeaway is that KVM is better for monitoring and can be tuned more flexibly; my OpenVZ servers didn’t report various I/O metrics to nginx Amplify or StatusCake, and Centmin Mod has more power to tune when it has more direct control over system settings.

RamNode

RamNode is a small company with a seemingly good reputation, and in my experience extremely low latency and unmatched uptime. This is where I first compared OpenVZ and KVM servers with similar specs and got my first hands-on experience with the two virtualization types. I tried the (blazing fast) NVMe service from Los Angeles since all NVMe were out of stock in Seattle, but I’d put that in my top three if the stock replenished. I’m also curious about their VDS, but it’d break the $20 budget.

SSD Nodes

I found SSD Nodes on LowEndBox and assumed it was a scam. After digging around skeptically, it seemed like the company actually delivered on fast, reliable servers at surprisingly low prices. Most reviewers claimed to see strong uptime and performance, and the company responded to overcrowding accusations by publishing a live display of load across all its servers. This and a generous trial period convinced me to give their XL plan a shot.

They apparently used to offer Seattle servers, and if those ever re-appear with similar pricing I’ll jump on one in a heartbeat.

So far, this $9.99/month server (prepaid one year) has vastly outperformed anything in the same price range. Support responses have been helpful and decent, taking maybe a few hours with medium priority. (I try not to abuse "urgent" flags, and I’ve only been testing the VPS I got.) I decided to keep it and am curious whether uptime and benchmarks will be as good a year later.

HostUS

HostUS is another company I encountered on LowEndBox. My initial benchmarks were strong, and after some weird IO issues I ran another set and found read and write performance wheezing at 1-2 MB/s. I filed a ticket that spurred a pleasant support discussion and investigation, only to find that the ticket had been closed after this comment from support staff:

We sometimes end up putting a blanket limit on IO in place per VM due to the level of abuse we see on our OpenVZ plans, this is the quickest and easiest method to mitigate larger issues at scale.

While I did run two benchmarks that used a bunch of CPU, and while I understand resources aren’t dedicated, the limit of 1-2 MB/s observed over several tests is an issue. This is the only server I tested that had an outage and dropped occasional http requests, and I’m not feeling compelled to keep the account. For what it’s worth, I do like the customization HostUS made to the otherwise-standard control panel, which offers convenient bonuses like adding SSH keys and disabling root login from outside the VPS.

Hyper Expert

I found Hyper Expert, once again on LowEndBox, toward the end of my search specifically for Seattle-based providers. I wasn’t sure exactly what I was getting when I signed up, but took advantage of a 10% off code and used it to customize a seemingly impressive VPS. I didn’t expect much, but it’s been my all-around favorite. Excellent performance, lowest load among its competition and friendly, responsive support. Its proximity and low latency make everything about the server feel fast. The company has a Discord server and strong reviews, and my one (low priority) support ticket received a fast and friendly answer in just under three hours on a Saturday.

And then there are the more established providers…

Linode

SliceHost and Linode were the first VPS providers I ever used. SliceHost was acquired by Rackspace, and Linode’s still going strong. The company is apparently one of Digital Ocean’s major competitors, and is the first of four "name brand" providers I decided to include for comparison.

Digital Ocean

Digital Ocean is lovely to work with and has been my choice for several client projects, but I don’t need instant provisioning or hourly billing and for now I’ll manage my own monitoring and backups. But Digital Ocean is a popular provider, so I figure it can’t hurt to compare my budget finds against an established host and much larger company.

Vultr

I’ve only ever poked around at Vultr, which has a reputation for being fast that didn’t disappoint. Seattle is one of their datacenter options, which is a plus for me.

AWS (+Lightsail)

High on the rush of spinning up powerful servers just to benchmark them, I decided to throw in a beefy EC2 instance along with another from Lightsail, which is Amazon’s clever way of simplifying your experience with AWS while drawing you into its vast universe.

Testing Method

For each server, I installed CentOS 7 and Centmin Mod before running tests with ServerScope.io, GeekBench, and Centminbench. The metrics I’m sharing here are the one’s I’ve found most interesting or useful.

Geekbench and UnixBench scores are straightforward, the latter all coming from ServerScope’s tests.

MySQL performance measurements came from mysqlslap via Centminbench:

PHP performance measurements, again from Centminbench, are the average of three Zend/micro_bench.php runs:

I opted to use a very simple bandwidth benchmark, which is Centminbench’s Cachefly download. The file itself should be close because of the CDN:

Disk read/write came from Centminbench’s fio benchmarks:

I’ll be monitoring my finalists with StatusCake and nginx Amplify to see how they behave longer-term.

Cheap VPS Results

Performance Competitors

Thrilled with the Hyper Expert VPS performance, I decided I’d try a few more plans to compete on directly performance instead of price.

Here are the additional higher-performance plans:

Working Conclusion

My current concept of value centers around performance and stability, but despite all the fun here I could see eventually wanting to pay more for service that comes with monitoring, backups, and features that cost very little compared to the time it’d take me to establish and maintain my own solutions. At the moment, I’ve let easily-chartable stats guide me a bit.

SSD Nodes clearly wins for best performance/cost ratio, but I’ve been most thrilled with the Hyper Expert VPS since it’s in my neighborhood. I’m going to keep both of those around for the next year or so and see what else I learn.

I don’t understand why all AWS read/write values seem consistently fixed near 12 MB/s, or how Digital Ocean’s Droplets do so much better in bandwidth tests.

A lot of this testing seems circumstantial and general at best, but it’s clear to me that processors and storage types matter when it comes to these shared resources. RamNode’s NVMe plan comes with good processors and exceptionally fast storage, and it shows. Time will tell whether all this glorious performance wins out over major platforms and all their perks.

I hope you enjoyed this post! I welcome questions and criticisms in the comments.

Non-Affiliate Links

• Hyper Expert
• SSD Nodes
• RamNode
• HostUS
• Digital Ocean
• Linode
• Vultr

One of my goals this year is to stop spending time maintaining my own private code.

I have a pile of apps and scripts and learn a great deal writing them, but I’d rather focus on sharing and improving code instead of being a hoarder. Another goal is to spend more time on code and techniques I’d offer to clients and fewer rabbit-hole learning quests. So this one’s a two-fer.

After a thorough comparison of VPS providers and ways of provisioning I’ve decided to simplify my live and embrace Laravel Forge. I have a few hosting accounts with smaller providers that don’t offer backup service, so I’ve spiffed up my pre-Forge backup scheme for quick setup on a newly-provisioned Forge server.

It stores data offsite with Backblaze B2 using a command line app called restic.

The combination is stable, inexpensive, efficient and encrypted. A nice perk is that the backups are snapshots, meaning you can choose a specific backup point to browse/restore much like Apple’s Time Machine. This and the built-in encryption make it better than just rsyncing data. (Credit goes to The Full Stack Blog for pointing me toward restic!)

Good news, dear reader: if you’re using Forge, you can probably use this too! Grab it from GitHub (workingconcept/forge-backup), and let’s take a quick look at how it works in the wild.

Requirements

1. Server provisioned with Laravel Forge running Ubuntu 18+.
2. Backblaze account.

Quick Version

You can clone the repository to start, but everything’s built into one shell script so you can run a one-liner as root:

Note that you must be root here and not just use sudo.

It’s a good idea to be wary of downloading and running shell scripts as root because some random internet guy said it’s cool on his blog. So let’s examine what happens one step at a time.

Step 0: Ready the Things

Provision a Forge server and keep track of the sudo and database passwords you get. You can safely run this on an existing server as long as it’s Ubuntu 18+, because restic isn’t included in Ubuntu’s default packages for lower versions.

Create a Backblaze B2 bucket under B2 Cloud Storage → Buckets. Pick (and remember) the name and keep it Private.

Now choose Show Account ID and Application Key just above the big Create a Bucket button. Create a key and limit it to your new bucket, and grab the resulting key (large) and keyId (small) you’ll find at the bottom in this screenshot:

We’re ready to continue.

Step 1: Initialize

SSH into your new server and become root.

Copy and paste that one-liner and hit return.

This will download restic-setup.sh from GitHub, make it executable, and then run it. That’ll look something like this:

It’s going to ask for your B2 application key ID, application key and bucket. Then it’ll install restic (apt-get install restic) which will look like this: