Chef cookbook for Drush

2013-10-20T00:00:00-04:00

I attended Opscode Chef training a couple weeks ago and got super-psyched about it. I’m working on a project for Jackson River, and utilizing Chef is a big component. While writing the cookbook for this project, I found that I needed more access to Drush.

At first, I used the execute resource, but I couldn’t reliably make the commands idempotent. Furthermore, using execute felt like a hack, and it made my recipes look less elegant. I decided to write custom LWRPs to extend the existing Drush cookbook.

Here’s the result of that effort, my fork of the Drush cookbook: https://github.com/benclark/chef-drush

I’m openly soliciting feedback here. I’m a PHP developer, and this is the first Ruby code I’ve ever written. I cribbed from other cookbooks that attempt to do the same thing (borrowing quite a bit from the Jenkins cookbook providers), and I did my best to be consistent and logical.

drush Lightweight Resources

The drush cookbook is used to interact with Drupal via Drush. It contains the following lightweight resources:

drush_cmd
drush_variable
drush_php_eval
drush_make
drush_site_install

There is also a helper library.

drush_cmd

The drush_cmd lightweight resource provides direct access to Drush. This is the backbone upon which the other resources interact with Drush.

Actions

This lightweight resource provider has the following actions:

Action	Description
`:execute`	Default. Indicates that the Drush command should be executed.

Attributes

This lightweight resource provider has the following attributes:

Attribute	Kind	Description
`command`	String	Required. The command sent to Drush. Examples: `pm-enable`, `pm-disable`, `site-install`.
`arguments`	String, Array	The arguments to go with the command. Examples: for `pm-enable` command, `devel` as argument.
`options`	String, Array	The options to go with the command. Examples: for `vset` command, `--exact` option.
`drupal_root`	String	Required. Equivalent to `drush -r <path>`, `--root=<path>`.
`drupal_uri`	String	Equivalent to `drush -l <http://example.com:8888>`, `--uri=<http://example.com:8888>`.
`assume_yes`	Boolean	Equivalent to `drush -y`, `--yes`. Defaults to `true` because `chef-client` can’t accept user input.
`assume_no`	Boolean	Equivalent to `drush -n`, `--no`. Defaults to `false`.
`backend`	Boolean	Equivalent to `drush --backend`. Defaults to `false`.
`shell_input`	String	Optionally pipe a string into the Drush command.
`shell_timeout`	Integer	Set a timeout for the shell operation. Defaults to 900 (15 minutes).
`shell_user`	User	Run the Drush command as a specific user.
`shell_group`	Group	Run the Drush command as a member of a specific group.
`block`	Proc	Ruby block to act on the `stdout` from the Drush command.

Examples

To run drush site-install for example.com:

drush_cmd "site-install" do
  arguments "standard"
  options [ "--account-mail=example@example.com", "--account-name=admin" ]
  drupal_root "/var/www/html"
  drupal_uri "http://www.example.com"
  shell_user "www-data"
  shell_group "www-data"
end

drush_variable

The drush_variable lightweight resource provides the ability to set and delete variables in a given Drupal install.

Actions

This lightweight resource provider has the following actions:

Action	Description
`:set`	Default. Set a value for a given variable.
`:delete`	Delete a variable. (@todo)

Attributes

This lightweight resource provider has the following attributes:

Attribute	Kind	Description
`name`	String	Required. The name of the variable. Examples: `preprocess_css`, `site_offline`.
`value`	String, Integer, Hash, TrueClass, FalseClass	Required. The variable’s value.
`drupal_root`	String	Required. Equivalent to `drush -r <path>`, `--root=<path>`.
`drupal_uri`	String	Equivalent to `drush -l <http://example.com:8888>`, `--uri=<http://example.com:8888>`.
`shell_timeout`	Integer	Set a timeout for the shell operation. Defaults to 900 (15 minutes).
`shell_user`	User	Run the Drush command as a specific user.
`shell_group`	Group	Run the Drush command as a member of a specific group.

Examples

Enable CSS preprocessing:

drush_variable "preprocess_css" do
  value 1
  drupal_root "/var/www/html"
  drupal_uri "http://www.example.com"
  shell_user "www-data"
  shell_group "www-data"
end

drush_php_eval

The drush_php_eval lightweight resource executes a block of PHP code.

Actions

This lightweight resource provider has the following actions:

Action	Description
`:execute`	Default. Execute the PHP code.

Attributes

This lightweight resource provider has the following attributes:

Attribute	Kind	Description
`php`	String	Required. The PHP code. Examples: `variable_set('site_offline', 0)`.
`drupal_root`	String	Required. Equivalent to `drush -r <path>`, `--root=<path>`.
`drupal_uri`	String	Equivalent to `drush -l <http://example.com:8888>`, `--uri=<http://example.com:8888>`.
`format`	String	One of the following output formats: `var_export`, `csv`, `json`, `list`, `string`, `table`, `yaml`. Defaults to `var_export`.
`shell_timeout`	Integer	Set a timeout for the shell operation. Defaults to 900 (15 minutes).
`shell_user`	User	Run the Drush command as a specific user.
`shell_group`	Group	Run the Drush command as a member of a specific group.
`block`	Proc	Ruby block to act on the `stdout` from the Drush command.

Examples

Generate the $drupal_hash_salt value, and save it into a file:

drupal_hash_salt_path = "/var/www/private/drupal_hash_salt.txt"
drush_php_eval "generate_drupal_hash_salt" do
  php "echo drupal_hash_base64(drupal_random_bytes(55))"
  drupal_root "/var/www/html"
  block do |stdout|
    ::File.open(drupal_hash_salt_path, 'w') { |f| f.write stdout }
  end
  not_if { ::File.exists?(drupal_hash_salt_path) }
end

drush_make

The drush_make lightweight resource turns a given makefile into a Drupal codebase.

Actions

This lightweight resource provider has the following actions:

Action	Description
`:install`	Default. Build the makefile.

Attributes

This lightweight resource provider has the following attributes:

Attribute	Kind	Description
`build_path`	String	Required. The path at which to build the makefile.
`makefile`	String	Required. Filename or URI of the makefile to use for this build.
`shell_timeout`	Integer	Set a timeout for the shell operation. Defaults to 900 (15 minutes).
`shell_user`	User	Run the Drush command as a specific user.
`shell_group`	Group	Run the Drush command as a member of a specific group.

Examples

Build the example.make makefile:

drush_make "/var/www/html" do
  makefile "http://example.com/examples/example.make"
  shell_user "www-data"
  shell_group "www-data"
end

drush_site_install

The drush_site_install lightweight resource installs Drupal along with modules/themes/configuration using the specified install profile.

Note: this provider assumes that settings.php already has the database credentials provided for the given drupal_uri. You can use a template resource to define settings.php.

Actions

This lightweight resource provider has the following actions:

Action	Description
`:install`	Default. Install Drupal from the specified install profile.

Attributes

This lightweight resource provider has the following attributes:

Attribute	Kind	Description
`profile`	String	Required. The install profile to use.
`force`	Boolean	Force the installation. Defaults to `false`.
`site_name`	String	Optionally provide the site name.
`drupal_root`	String	Required. Equivalent to `drush -r <path>`, `--root=<path>`.
`drupal_uri`	String	Equivalent to `drush -l <http://example.com:8888>`, `--uri=<http://example.com:8888>`.
`shell_timeout`	Integer	Set a timeout for the shell operation. Defaults to 900 (15 minutes).
`shell_user`	User	Run the Drush command as a specific user.
`shell_group`	Group	Run the Drush command as a member of a specific group.

Examples

Install Drupal using the standard profile:

drush_site_install "standard" do
  drupal_root "/var/www/html"
  drupal_uri "http://www.example.com"
  site_name "Example"
end

Helper library

There is a helper library to assist with some of the idempotence.

drupal_present?(path)

This verifies that Drupal core is present at path, but isn’t necessarily bootstrapped via drush status.

drupal_installed?(path, uri = ‘http://default’)

This verifies that Drupal successfully bootstraps at path and uri (via drush status).

drush_vget_json(path, name, uri = ‘http://default’, exact_match = true)

This returns a JSON Object with the results of drush variable-get.

drush_vget_match?(path, name, value, uri = ‘http://default’)

This verifies that a Drupal variable name matches the given value.

10 performance tweaks to make before applying Varnish on your Drupal site

2013-05-30T00:00:00-04:00

Step 11: Enable Varnish. But steps 1 through 10 matter more. Varnish isn’t a magical solution to all your performance woes. In truth, it’s one of the more aptly-named software packages: you should only apply it only after you’ve finished sanding down the rough edges of your site’s performance. If you apply it too soon, you won’t have the smooth surface you were hoping for, and at best you’ll be covering over your site’s imperfections.

Here are some topics I run through before enabling Varnish on a Drupal site. Your mileage may vary, and your methods may vary as well. This list is designed for you to do a deep dive into finding out why your site is “slow,” and I like to perform some version of this list for every site launch I participate in.

1) Have you tried the built-in page cache?

Have you tried turning on the built-in page cache?
Do the pages cache as expected, or are you still getting uncached content delivered?
Are there any portions of your site that no longer work as expected with the built-in page cache enabled?

If turning on the built-in page cache causes headaches, then you likely have some architectural decisions to make.

For example: Drupal core comments are a fun way to “engage” with your visitors, but they’re going to be a real pain to work around if you want effective Varnish caching. But more importantly, do they really get any use on your site, aside from spammers? Could you get the same level of engagement from a third-party commenting system like Disqus, something that exists only on the client side, and thus doesn’t require anything from Drupal?

2) Have you done any PHP profiling?

Have you done any PHP profiling (using xhprof, others)?
Do you know which of your pages take the most time to load, and do you know why they take as long as they do?

Anytime you introduce custom code, you’re introducing something that has not been fully tested at scale.

Be mindful of trying to optimize too much — saving a few dozen milliseconds off of a page request will be nearly imperceptible and barely worth the effort. On the flip side, if you can shave half a second or more off, that’s worth even a significant refactor of your code.

3) Are there any views that take a long time to load?

Are there any views that take a long time to load?
Are they cacheable using a Views cache plugin, or would caching the view break it somehow?
And if so, why?

Writing your own Views cache plugin is easy, so if the built-in time-based cache is insufficient for your needs, feel free to implement your own. For example, if you have view output that is identical for logged-in and anonymous visitors, then your custom Views cache plugin can set a results and output key that does not include the logged-in user’s roles as part of the hash.

4) Are there any Panels panes that take a while to load?

Similar to the previous Views question, are there any Panels panes that take a while to load?
Are they cacheable? (I’m going to strongly urge you to answer yes to that question, even if it requires some extra thought.)

The built-in simple cache may be too simple for your needs, but there are some excellent Panels caching modules already available, and a Panels cache plugin is relatively simple to implement if you need a custom solution.

5) How about SSL?

Are there any SSL pages?
Are you using a module like Securepages to redirect certain paths to SSL?
What percentage of your traffic will be SSL?

Bottom line, unless you’re doing SSL termination, traffic coming in over port 443 is never going to be cached by Varnish. A page that renders slowly before you enable Varnish is going to be just as slow for your SSL traffic. Instead of allowing any page to be encrypted, use a module like Securepages to redirect your traffic back to port 80 (and back to Varnish) unless they’re on a specific set of pages.

6) Can users log in?

Do your users have the ability to log in, to create profiles, etc.?
Is there any value added to the UX if they’re logged in?
Is there any content that changes based on whether your visitors are authenticated or not?

Users are the enemy of a performant Drupal site. Having a user session automatically bypasses Varnish, and thus as long as your visitor is logged in — regardless of whether they’re viewing a members-only forum or the About Us page — they are not going to be served by Varnish. If you don’t absolutely need users, consider blocking them altogether.

If, however, having logged-in users is part of your build plan, take a minute to review alternative caching options. Views and Panels can cache content differently for logged-in and anonymous traffic. And if you have a custom menu callback, consider writing your own cache_get() and cache_set() logic to spare any expensive node_load() or database calls.

7) Are you running Pressflow?

Are you running Drupal 6?
Are you running the Pressflow fork of Drupal 6?

(Drupal 7 developers can skip this section altogether.)

Bottom line, if you’re looking to have Varnish cache your Drupal 6 site, using Pressflow is an absolute requirement. It simply will not work without it. Pressflow is a drop-in replacement for Drupal 6 core, and 99% of sites will function exactly the same — if not better — with Pressflow. Still, it doesn’t hurt to run some of your test coverage again, or, in lieu of test coverage, to test some of your custom functionality by hand.

Pressflow also includes some fun extras like path alias caching, which caches frequent path lookup database requests, as well as some core tweaks that help Drupal 6 in enterprise environments. A simple blog site wouldn’t see those benefits, but a large corporate site could.

8) Are you making any API calls?

Are you making any third-party API calls, like to a payment gateway, or to Twitter?
Are you running modules that periodically call out to get authentication tokens, like Mollom?

If you are, you’re completely at the mercy of the third-party’s API performance and how frequently you request data from it.

In load testing one of our client sites recently, I was getting terrible performance on a site that was sitting on some heavy-duty hardware, and it just didn’t seem right. I broke out the PHP profiler (xhprof), and discovered that the culprit was Mollom. A little known quirk of the Mollom module for Drupal is that when Mollom is in testing/development mode, it issues an API request on every page request as long as there’s at least one form on that page. That form doesn’t even have to be Mollom-enabled, it could just be the search form in the header.

In this specific case, I offered a patch to the module maintainer, and disabled testing/development mode in the module settings. But it was a lesson learned: any API call at all, no matter how benign, could have a measurable impact on your site’s performance, especially at scale.

9) Now we talk about optimizing your stack

Now it’s time to review hardware and server configuration. Note how I haven’t mentioned anything about the server environment until now.

There’s plenty of server jockeys out there who will insist that the first rule of getting Drupal to be performant is installing PHP-FPM, nginx, Memcache, and Varnish. They might even recommend Project Mercury, which is a (wonderful) install script for optimizing your entire stack.

As much as I love those tools, no matter how much stack optimization you do, you can still have a page on your site that issues 11,000 database calls that saturate your database server’s I/O, causing the page render to take over 40 seconds to complete, which ties up a PHP resource on your application server while it waits. Swapping out mod_php for PHP-FPM and tweaking my.cnf might take it from 40 seconds down to 35 seconds, but we’re still talking about a massive liability that, truly, has nothing to do with the stack and everything to do with how your site is built.

Remember that Varnish caches aren’t forever, and there will come a time when one of your visitors will hit that page completely uncached.

Am I suggesting that running Memcache isn’t an awesome way to optimize your cache bins? Absolutely not — and by all means, install it and use it, especially if you’re making use of Views and Panels caches, block caches, custom object caches, etc., or if your database layer isn’t on stellar hardware (or worse, if it’s on the same hardware). And the other optimizations are just as valuable. I’m simply arguing in favor of reviewing your Drupal build configuration first. Bottom line, check your custom code and your design decisions before you blame time-tested code like Apache and mod_php.

10) And now for something completely out of left field…

I’m going to suggest something completely out of the box, and I apologize if it ruffles the feathers of any die-hard Drupal developers out there, but: is Drupal the best solution for your site?

Could your site be rendered into static HTML files and still perform exactly the same?

Before you dismiss this question on spec, consider that you’re seeking to do exactly that, just with Varnish. All Varnish is going to do is render your Drupal pages into static files that it stores either on disk or in memory, and those static files are what get served to your visitors. Yes, with Varnish you do have the option of passing through your dynamic requests — AJAX calls, form submissions, etc. — to Drupal, but a 100%-effective Varnished site is going to be equivalent to a series of static HTML (or XML, JSON, etc.) files.

So, if your site is 99% static content, take a minute to ask yourself if the overhead of running a full-fledged content management system is worth the performance hit (and the administrative hassle). Consider also that rendering it into static files means you can upload them directly to a CDN, and you can skip the overhead of running your own servers. For some clients, the server infrastructure can be a significant budget line item, and it could be largely unnecessary.

If you’re seeking a way to automate the rendering of content into static files, look into projects like Jekyll and its derivatives. They’re not Drupal-based — they’re not even PHP-based — but they accept plain text files, Markdown, or HTML (really, any format you require), and plug the content into templates, and can support any metadata you need.

11) If you’ve made it this far, enable Varnish

If you’ve made it this far, feel free to enable Varnish — and enjoy a wildly-performant Drupal site. After all, you’ve taken the time to optimize top to bottom, and your site is moderately-performant when completely uncached. Adding Varnish on top of that smooth surface is going to mean so much more now.

Some of the better band names from three years of My Band Needs a Name

2013-05-24T00:00:00-04:00

For three years, I ran a little-known site called My Band Needs a Name. When I say “little-known,” I mean that maybe five people knew it existed.

It was meant to be a repository of user-contributed band names, so that if you started a new band and needed a clever name, you could find one. And if you thought of a clever name on your own, you could record it.

It was never more than a proof-of-concept, unfortunately, and last month, I was faced with a decision to renew the domain or not. Do I spend the time to make it right — by bringing it up-to-date with a mobile-friendly design, adding much-needed social sharing widgets, etc. — or do I just let it expire and move on to other projects?

I chose the latter, but as a tribute of sorts, here are some of the better contributed band names with their top-voted descriptions.

–

MR. ROBOTO AND THE SUSHI ROLLS

J-pop band, heavy on the synthesizers, rapid-fire double kick drums, and near-continuous sweeps on the Ibanez.

XOR

This band is either rockin’ or full of suck, but never both.

QUADRATONIC

One better than a tri-toned band. Duh.

GARY SINESE’S PET ROCK

Academy Award winning themed bluegrass. Think Lieutenant Dan with a banjo.

MC PLUS-PLUS AND THE AL GORE RHYTHMS

Old school hip-hop/polisci-nerdcore comprised of grad students.

Honorable mention: Environmentally-friendly “green”-core hip-hop group from Alaska.

A SINGER AND SOME SESSION MUSICIANS

Maybe some sort of tween pop-rock “band” – produced by Disney, for idiots.

PNEUMONOULTRAMICROSCOPICSILICOVOLCANOCONIOSIS

The longest word in the English language is now the longest band in the English language!

THE JERRY DALTON ALL-STAR ORCHESTRA

Jerry Dalton, before becoming the third-best used Saab salesman in Memphis, led his All-Star Orchestra in the style of big band and ska. They played mostly weddings.

Honorable mention: Big band electronica/death-metal with a charismatic bandleader in Jerry Dalton (not his real name, of course). Think baby blue tuxedos with blood stains. And a horn section.

And my all time favorite…

DR. PROFESSOR AND THE SCAN-TRONS

Surf rock with a ska riff or two, with the occasional foray into kid-friendly alt folk rock.

I miss my iPhone (but I can’t switch back, yet)

2013-05-19T00:00:00-04:00

I switched to a Nexus 4 back in February, partly out of tech curiosity and partly out of frustration with stagnant iOS innovation. While I still believe that iOS is stagnant and behind the times, with WWDC a few short weeks away, I have renewed hope that Apple can turn it around.

I’ll be honest: I miss my iPhone. I miss the little things that “just worked” and I miss the quality of the apps. I don’t like stressing about app permissions, and I don’t find myself wanting to customize it as much as Android would allow me.

But at the same time, I know I can’t switch back yet, not until iOS (and the iPhone itself) catches up in some of the areas where Android has really taken a strong lead. I still love the way accounts are handled, and how services within the OS (like the web browser, text messaging, and email) can be replaced or augmented — at the OS level — by third-party apps. Oh, and the iPhone screen looks comically tiny now compared to my Nexus 4.

I miss my iPhone

It just worked

My iPhone “just worked.” That isn’t to say that my Nexus 4 has been exceptionally buggy. All software is buggy, and hardware isn’t perfect either. It’s more of a perception thing, I guess, a general vibe that I get from using it.

Actually, I blame the apps far more than I blame the Android OS or the Nexus 4 hardware. The quality of the apps are just not very consistent, and often feel like afterthoughts to their iOS counterparts. My first experiences with most of these apps were on iOS, where the UX is tightly controlled through APIs and HIGs that established early on exactly what an iOS app should look and feel like. So, when I started using the apps on Android, they just felt inferior in their inconsistency — inconsistencies not only with their iOS counterparts, but within the Android OS, and amongst other apps.

I’m not going to offer up a laundry list of apps that are terrible, but instead I’ll name some that are an exception to what I just said, where their iOS and Android versions are, for the most part, comparable in UX and functionality:

Facebook — this takes the prize for being just the worst on both platforms. I absolutely hate using it on any mobile device.
Twitter — actually quite decent on both platforms, and bonus points for having a superior web experience to match the apps.
Harvest — this is my time tracking software that I use for work. It’s a solid, reliable app on iOS, and the Android version is a clean port.

Android apps can do too much

Something that stresses me out probably shouldn’t stress me out as much as it does: app permissions. Anytime I download or update an app, I’m prompted with a reminder that this app can do way too much on my phone. Oh, I can’t do anything about it, it’s just a notification.

Say what you will about iOS, but it has a pretty tight API. There have been a few notable exceptions — at one point, the LinkedIn iOS app did something quasi-malicious with your contacts — but they’ve invariably been turned around on the app authors as violations of the API and TOS. It doesn’t usually end well: the app gets pulled from the App Store, or the company behind the app suffers some bad PR and fixes the problem on their own.

Conversely, in the Android space, it does seem as though apps are given free reign to seemingly low-level endpoints in the OS. I can download an app that shows me intimate detail about the other apps that are running: memory usage, shared library utilization, etc. Without much hands-on knowledge of the iOS API, I’m pretty confident that level of access is either a no-go in iOS or far more limited in scope.

There was a story that went around a few weeks ago that upgrading to the newest version of the Facebook app added some new code that allows the app to update itself in the future, skipping the Google Play Store completely for managing updates. As a software developer, I totally get why Facebook would add that code. As an end user, it scares the crap out of me. I don’t trust Facebook’s intentions 6 months from now when they decide that everyone should have Facebook Home.

I like that I can trust iOS to prevent an app from doing anything predatory or out-of-scope. And when Apple has allowed its apps more access to system services like Location and Contacts, it has done so in a way that I can turn completely off. (Sorry, LinkedIn, I don’t trust you with access to my contacts. Sorry, Facebook, you don’t need to know where I am right now.)

I don’t customize as much as I thought I would

I’ll admit flexibility is a strength of Android. Conceptually, I like that I can change almost anything about the OS. I can download an app to fix something I don’t like about the OS, and the OS doesn’t mind. And if I really hate something about the OS, there’s always the option to root and go completely nuts.

But three months into owning my Nexus 4, do you want to know the truth? I don’t customize: I set it and forget it.

It’s been pointed out to me that every complaint I have for the OS can be rectified with either an app or a new ROM. I wouldn’t argue against that, but I think the fact that I haven’t done those things yet — and that I’m still running the stock version of the OS that came with my phone, with no app-level modifications — says a lot about how I want to use my phone and how I view it as a utility device and not as a general-purpose computing device that I can hack away at until my heart’s content.

But I can’t switch back… yet

I still love the way accounts are handled

iOS is slowly getting there with the integration of Twitter and Facebook as additional “accounts,” but they’re one-off exceptions to the general rule that an app stands alone on iOS. That bothers me a little, because that assumes Apple’s pre-installed apps are always superior. Oh, except in the areas of social sharing (Twitter) and social networking (Facebook). Oh, and once upon a time, in mapping (Google Maps, pre-iOS 6) and streaming videos (pre-installed YouTube).

Before I switched, I was using Google’s Gmail app on iOS for all my mail, and it was working beautifully except for when I wanted to email myself a link from Safari. I would have to copy the URL to the clipboard and paste it into an email myself. There wasn’t a way for the Gmail app to announce itself as a fully-functioning alternative to the built-in Mail app.

Similarly, the Instapaper iOS app requires extra steps to save a link to read later. I can either use the bookmarklet in Safari — which pings instapaper.com with my URL, which is then later downloaded into the Instapaper app — or I can copy/paste the URL from Safari into Instapaper. On Android, this is a lot simpler: there’s a sharing menu, under which Instapaper is an option. The app context switches briefly, and then returns to Chrome.

The Nexus 4 screen

I never thought I’d say this, but I’ve really grown to like the form factor of the Nexus 4 screen. It’s still a bit wide for my comfort, but it’s larger in the right proportions compared to my iPhone 4.

Also, the size of the screen isn’t preventing a switch back to an iPhone in general. It’s not so much of an issue that the iPhone screen remains smaller if the available space can be used more effectively. The trend of skeuomorphic design is over and done, and a switch to cleaner and leaner design will free up a lot of wasted space in apps like Contacts and Calendar. And with the advent of better email clients like Gmail or Mailbox, I hope that we can at least see an UX improvement in the stock Mail app, if not to also gain the ability to completely replace it.

I have hope that iOS can bounce back

I have hope I’ll be an iPhone owner yet again. I still have my iPhone 4 sitting in my desk drawer, waiting for the moment that I can download the new version and start using it full-time again. Still… the realist in me says that any improvements in iOS and in the iPhone are going to be incremental. I enjoy my Nexus 4 and the freedoms it affords me, but… I do miss my iPhone, and I want to come back into the fold.

I bought a Google Nexus 4 to replace my iPhone 4. There, I said it.

2013-03-03T00:00:00-05:00

I bought a Google Nexus 4 to replace my iPhone 4. There, I said it. I feel like I have to justify myself a bit on this one.

A few weeks back, my iPhone started acting strangely. It would freeze up for a few seconds, the Home button wasn’t working consistently, and the battery wasn’t really working great. The battery thing was expected — I mean, batteries don’t last forever — but the other things were just getting annoying. I knew it soon would be time to replace the phone, but getting an unlocked iPhone 5 was going to cost me around $800.

Meanwhile, friends, co-workers, and family had been on me to take a look at the Nexus 4. “It’s vanilla ice cream whatever,” they would say. It was really starting to wear me down, and I have to admit my curiosity was getting the better of me. But the reason I pulled the trigger came down to money: the phone — which is unlocked — costs less than half what I’d spend to get a new iPhone. I figured, what’s the worst that could happen?

OK, so let’s rip this Band-Aid off: I actually like the Nexus 4. I like it a lot. Sure, there are a couple things that bug me about it — but I’m definitely eating crow over my iOS fanaticism.

Things I like about my Nexus 4 (in order of appreciation)

The way accounts are handled

Rather than handling logins in every app, Android centralizes (most?) accounts at the OS level. I added my three Google accounts, which meant that I automatically had my mail in the Gmail app, Maps had my recent search history, Chrome had my bookmarks, Google Reader had all my feeds — and I only had to log in once (per account). Facebook is there, too. Dropbox. Skype. Twitter. It’s all in one place, and apps can share the usage of those accounts without me having to type in my password over and over. Genius.

Links open in Chrome, always

I know iOS means well to embed the browser in each app, but it just makes more sense to me that tapping on links will open the web browser app. By doing that, I get to reuse cookies and sessions. I can leave things open in tabs and switch back to the app I was in. It’s closer to how multitasking works on your desktop OS.

I can customize anything

I’m loving that I can add widgets to the home screen. I can download apps that customize the LED for different notifications. I’ve read that I can replace nearly every aspect of the UI with something else, and then there’s the whole ‘rooting’ rabbit hole I can travel down, too. I like knowing that if something about the OS bugs me I can fix it.

Apps can do more throughout the OS

Apps can do so much more in Android. Example: any app can add itself to the sharing options. I downloaded the Instapaper app, and now I can share links from Chrome or Google Reader directly into Instapaper — without resorting to a bookmarklet (which I always found a little hacky). Another example: Google Voice can take over text messages completely. That’s awesome. It can do phone calls via Google Voice, too, although I haven’t tried it.

Things I don’t like about my Nexus 4 (in order of annoyance)

No Home button, button on the side is hard to push

To turn my screen on, I have to push a button on the right side of the phone. It’s a small, hard-to-push button, and in order to push it with one hand I have to squeeze the phone in such a way that I often accidentally adjust the volume (which is in the same position on the left side of the phone). I don’t necessarily want a Home button on the front of the phone, but it sure would be nice to have something a little easier to push.

Notifications aren’t quite the same

When my iPhone gets a text message, the screen lights up and I can read that text message. If I’m not near my phone or if it’s in my pocket, and I get a couple more text messages, they pile up on the screen. I can do this for other notifications as well, and it’s all configurable per app. It seems to me like a no brainer on how any phone should handle incoming notifications. Out of the box, my Nexus 4 does not do any of this. The best I get is a LED that lights up (sort of).

I’ve been told that all of this is customizable via apps. Light Flow for the LED. SMS Popup for the iOS text message notification. And that’s fine, really — but it bugs me that these options aren’t built-in.

I need to customize everything

Out of the box, the OS feels unfinished. Not in a half-assed, Windows ME way, but in a “we expect you to tune this to your preferences” way. The first night I got my phone, I was fiddling with it for hours. It’s not just the notifications thing, either, but everything. There’s so much to configure that it was overwhelming. I still feel like there’s an entire settings page somewhere in the phone that I haven’t seen yet, and the OCD side of me is really insecure about that. Sometimes, I just want my phone to be a phone, you know?

The speaker is really quiet, vibration is wussy

They designed the phone with the speaker on the back. When it’s sitting on a flat surface, I can’t hear it even if it’s turned to full volume. That’s just an engineering fail right there. And the vibrate feature is really weak. And because the screen doesn’t light up when I get notifications, it’s like this phone is designed for me to miss everything when it comes in.

Too big for my freakishly-tiny hands

My iPhone 4 fit perfectly in my left hand, allowing me to type and tap with my thumb, without once feeling like it was going to slip out of my palm. This Nexus 4 is too wide for one-handed usage. I can rest the phone against the bottom of my palm and angle it so that my thumb reaches most of the keyboard, but then my fingers are only resting on the back of the phone rather than gripping it. It wouldn’t take much for it to slip out of my hand altogether.

Thing is, I never knew I had tiny hands before I started using this phone. It explains so much. No wonder I was lousy at bass guitar.

How to unlock the power of Drupal’s system_settings_form()

2013-01-21T00:00:00-05:00

When building a module that requires a custom administration settings page, the system_settings_form() is indispensible. It saves the contents of a form into system variables, and this frees developers from having to write their own #submit callback for a form. This turns out to be a huge timesaver when building forms with simple things like checkboxes and select fields that don’t really need to be validated or transformed.

But typically this function isn’t considered for more complex operations or data types beyond integers and strings. What if you want to save an array to a variable? Or what if you need to transform a string value containing a username into an integer user ID?

Normally, these cases would require a custom #submit callback, but I want to propose an alternative. I’m going to outline an approach to this problem that utilizes the system_settings_form() to save transformed variables to the database. I’ll then follow up with two real-world implementations.

The problem

It makes no sense to save a untransformed value to the variable, because that means you’ll just have to write a getter function and call it each time you want to use the variable for anything meaningful. That takes precious nanoseconds of page load time, and is completely pointless. Instead, you should take the time to do the expensive processing only when the variable is changed. Then, when it comes time to use your variable, you’re ready to go as soon as you call variable_get().

(Plus if you’re slightly OCD like me, especially when it comes to the integrity of your data, it’s irritating to know that there’s ugliness living in your database that you’re going to have to clean up anytime you want to use it.)

But why not just write your own #submit callback that does the same thing? That’s a valid question, and I’ll preface my argument by saying that it’s going to boil down to a matter of taste. It’s my opinion that this is a cleaner approach to the problem. As with all things Drupal, there are multiple other ways to do this. There’s never only one right way with Drupal (but usually several absolutely wrong ways).

It means code portability

With all your logic at the form element scope, you can move that form element into an entirely separate form, and it will work exactly the same. Furthermore, you can add the same form element to another form (for whatever reason) and keep it in your settings form, and reference the same value and validate callbacks.

If you did all of this work inside a #submit callback, you’d end up with duplicated logic at best, and at worst you might be stuck refactoring a form later on if you change the format of the variable.

It means code reusability

Consider the use of an autocomplete on a textfield (which I will demonstrate in my examples below). It’s conceivable that you would have this on more than just one form, and multiple times on the same form. By using the #element_validate and #value_callback approach, you only need to write two functions for an unlimited number of fields.

The method

All you need to do is add #value_callback and #element_validate to your form element.

Start with a settings form that looks something like this:

<?php
function D6MODULE_admin_settings_form() {
  $form['D6MODULE_variable1'] = array(
    '#type' => 'textfield',
    '#value_callback' => 'D6MODULE_admin_variable1_value_callback',
    '#element_validate' => array('D6MODULE_admin_variable1_validate'),
  );
  return system_settings_form($form);
}
?>

The value callback is used to convert the #default_value — which will contain the transformed variable’s value (e.g., an array, or a user ID) — into the format expected on the form:

<?php
function D6MODULE_admin_variable1_value_callback($element, $edit = FALSE) {
  if (func_num_args() == 1) {
    // No value yet, so use #default_value if available.
    if (isset($element['#default_value']) && is_numeric($element['#default_value'])) {
      // Convert internal value to user-friendly value.
      $value = _D6MODULE_admin_variable1_transform_from_internal($element['#default_value']);
      // Return the transformed value to the form.
      return $value;
    }
    // If the #default_value is blank, return empty string here.
    return '';
  }
  // For other calls to the value_callback, return the second parameter.
  return $edit;
}
?>

The element validate callback is used to both validate the data (as needed) and in the event validation passes, to actually do the transformation and save it in the form via form_set_value():

<?php
function D6MODULE_admin_variable1_validate($element, &$form_state) {
  if (!empty($element['#value'])) {
    // Check that the user-friendly value is valid (optional).
    if (!_D6MODULE_admin_variable1_do_validation($element['#value'])) {
      // Failed validation, return form error.
      form_error($element, t('Variable was not valid.'));
    }
    else {
      // If passed validation, convert user-friendly value to internal value.
      $value = _D6MODULE_admin_variable1_transform_to_internal($element['#default_value']);
      // Set the value on the form.
      form_set_value($element, $value, $form_state);
    }
  }
}
?>

Example implementations

Here are some example implementations of this method.

Explode textarea contents into an array

User autocomplete on a textfield but save user ID

Farewell, Linode! Or, why I should be learning new things

2013-01-20T00:00:00-05:00

My Linode account was activated November 17, 2009, and I shut it down January 14, 2013. During that time, the longest stretch of uptime was 545 days.

I originally switched to Linode from shared hosting on Dreamhost. I really enjoyed the freedom of being able to run my preferred distro (Debian) and call my own shots regarding what tools I used (Lighttpd, Varnish, memcached). So I set everything up, threw some sites on there, and locked everything down — and then left it mostly alone for 3 years.

Here’s the thing: in those 3 years, a lot changed. At some point when I wasn’t looking, Amazon Web Services matured into something really accessible and affordable, especially for people like me who don’t need much in the way of RAM or CPU for their vanity domains, but who do like to tinker with server-level things. Once I realized I was behind the curve with my VPS, I was kicking myself for being so complacent and loyal to that paradigm.

A new year’s resolution is as good of a reason as any to take on a new project, so shortly after 2013 began, I began to migrate my domains away from my Linode to an EC2 instance. Then, I switched my nameservers away from Linode this past weekend, thus signaling the end of a very satisfied 3-year term.

Loyalty shouldn’t keep you from learning new things

Part of the reason I didn’t pay much attention to alternatives to my VPS was that I was a satisfied customer. Although I recognized that cloud computing services and platforms as service were becoming things people actually used, I didn’t want to spend the time and effort to learn something new if my VPS still met all my needs. Besides, I had plenty of other things going on career-wise to keep my brain occupied.

But for someone who identifies as a sysadmin type, I did a disservice to myself by being loyal to my VPS for so long. Don’t get me wrong, I’m not advocating eschewing loyalty in the pursuit of marginally lower prices or anything like that. Loyalty is generally good. But in this case, loyalty became an excuse I used to avoid learning new skills, and I missed out on emerging industry trends.

This got me thinking: I’m a loyal customer of Drupal, too. I’ve been working with Drupal since 2006. That’s six-going-on-seven years of being a full-time Drupal developer, and my focus on Drupal development has come at the expense of my not learning new frameworks and languages.

We can’t afford to stand still for very long

Here’s the hard truth, folks. Developers — and all corners of the information sector, really — can’t afford to stand still for very long. Every semester, there are kids graduating college who have been brought up in an era of X paradigm and Y framework. They’re going to be kickstarting new projects with incubators and crowdsourcing and whatever other thing that is trending right now.

If you’re not staying on top of things, or if you’re not at least dipping your toes in the shallow end of whatever, then you’re running the risk of becoming out-of-date. These kids coming up will lap shortsighted, loyal developers. The longer it takes for us to notice, the worse it gets.

Sure, you can be the type that complains about it, who says X paradigm is just a buzzword, Y framework is a fad — “just you wait, technology is cyclical” — but you’ll reach the point where what you’re loyal to is no longer relevant. And whenever you eventually realize that you picked loyalty over professional development, are you prepared to invest the time and effort to change course?

What’s next?

I’ll come clean: learning more about AWS was eye-opening. I recognize that I’ve only just discovered the tip of the iceberg, too. There’s the whole PAAS sphere that I need to explore, not to mention all the supplemental tools and products that exist. I’m excited to learn more about all of it.

I’m also nervous that my web development skills, which were state-of-the-art 6 years ago, are now showing their age. I’ve set a goal for myself in 2013 to not be loyal to any one technology merely for loyalty’s sake.

I want to stay relevant (and employable!) for a long time to come, and I think being open to new things is the only way to ensure that. I’m reminded of the sage words of Johnny 5 from Short Circuit: “Need input. Input.” I do feel as though I need to play catch-up, but I’m equal to the task, and in truth, energized by it.

The four stages of the Drupal developer life cycle

2012-11-17T00:00:00-05:00

I’ve been working in the Drupal ecosystem for a while now, and I’ve noticed there’s a predictable life cycle of the Drupal developer. We all know the stages. Drupal developers start out hacking away at the theme layer. Then, they start writing their own modules. Still others start contributing those modules back to the community.

Eventually, those who survive the earlier stages grow to be good Drupal citizens, working as professionals and contributing back to the community in a meaningful, productive way. As critical as this stage is for the well-being of all developers, to achieve it requires self-awareness and discipline.

We were all beginners once

Beginners first approach Drupal like a closed box. It’s not something to be tweaked or hacked. Instead, they scour Drupal.org looking for modules they might need. They enable modules indiscriminately. The complexity of their projects increase exponentially as they install more and more modules, and they begin to complain about Drupal’s “learning curve.” Their attention may turn to aesthetics: “Hey, my site looks pretty ugly with all of these blocks and tabs on the page!” Or their attention turns to a limitation of one module or another: “I hate how limited Views is! Ugh, seriously, how hard is it to create a view of related nodes?”

At this point, the beginner starts to peel away the outer layer of the closed box. They search Drupal.org for example code, and begin making the beginner’s favorite dish: copy pasta. They start editing node.tpl.php and template.php. Their first theme may or may not be named zen_starterkit. They find a thread that says to throw some PHP in a Views argument, maybe a node_load(arg(1)) to get an array of terms. They’re well-intentioned but they lack the understanding of what it is they’re copying and what it is they’re overriding. They’re ignorant of the “Drupal way.”

Thing is, Drupal beginners are great people. We need more of them, especially if we’re to sustain our ecosystem. Yes, we need them to learn more, and learn more faster, but they won’t get to where we need them without our help. We must mentor our beginners as best we can, within Drupal.org issue queues and IRC chat rooms, and when they’re our co-workers and subordinates.

Don’t lie to yourself, either: we were all beginners once.

Intermediate developers are fearless

Assuming the beginner is given a chance to grow in a healthy environment, the natural progression is to become an intermediate Drupal developer.

At this stage, the developer approaches Drupal like a blank piece of paper. “A robust system of hooks!” they say with enthusiasm. “I shall use these to make modules for myself!” They’re a child playing with Legos for the first time. There is an overwhelming temptation to build anything and everything with these new building blocks — as they understand them. They’re fearless.

Unfortunately, this means they’re going to write a module when it’s not strictly necessary. They’re going to write a module that changes the page title for node pages. They’re going to write a module that adds some metatags to the <head />. They’re going to write a module that sends an email to a mailing list every time a node is saved or updated.

This is arguably the stage most dangerous to the rest of us. They could be at this stage here indefinitely, masquerading as professional developers. They could do a lot of damage when left unsupervised on a project. And we’re the ones that are inevitably tasked with reviewing their work and fixing it. (I shudder to think, what if we made the mistake of agreeing to a fixed fee before discovering their code soup?)

But there is hope, because there are some in this group who have raw enthusiasm for Drupal as a platform. They want to learn more, write more code, and build with Drupal more effectively. All they’re lacking is the holistic understanding of the community at large, how it all works together and how to leverage existing work to avoid reengineering the wheel¹.

Advanced developers call it “dee dot oh”

The intermediate developer graduates to the next stage, advanced Drupal developer, when they recognize that Drupal isn’t a blank piece of paper, but a rich tapestry. While the thrill of writing a bespoke module remains, there is now also wisdom and the knowledge that there’s no sense in writing their own auto_nodetitle.

Advanced Drupal developers recognize that there’s a larger community of developers out there, so before starting with a blank .module file, they’re going to first check for pre-existing modules and APIs that they can leverage. They’re going to pay attention to best practices and security concerns — they know better than to output text without running it through check_plain(). They might even know to leverage things like the Cache API and the Batch API to be more effective and efficient. They’ve written Views handlers, Panels plugins, and Context reactions.

At first glance, you might mistake this developer as an expert. In a lot of ways, you’d be right. This developer went to Drupalcon, maybe even sat in on a core conversation, or attended a BoF or two. They call Drupal.org “dee dot oh.” They also participate in local community events, and they’re almost certainly employed as a full-time Drupal developer². This type of developer knows the core API inside and out. They might boast that they’ve been working with Drupal since 4.7, and might claim that they’ve written modules for all major releases.

While all of these observations are correct, don’t put this kind of developer on a pedestal. They are far from perfect.

Let’s say they find a contrib module out in the wild that suits their needs. They enable it and find out that it’s buggy, or it doesn’t match their use case exactly. Or even more arbitrarily, it just doesn’t fit their expectations for how it “should be” implemented. Their next thought is, “oh well, I guess I’ll have to write my own!” They expect perfection — or at least likemindedness — from all contrib module authors, and when faced with the alternative, they choose to eschew the community and write their own solution.

The all-or-nothing position is dangerous for a Drupal developer because that implies that skepticism about the ability for existing modules to meet expectations is their default position. The developer works within a bubble even while participating in the community. Their position boils down to “I trust my implementation choices above all else.” They dismiss the intellectual capital invested by the maintainers as inconsequential.

From a practical standpoint, there’s a laundry list of reasons not to do this. They’re going to re-introduce bugs or security flaws that others have already encountered and fixed in the so-considered inferior solution. They’re going to leave out features that they might want down the road, not out of malice but because they simply didn’t think of them.

From a social standpoint, these developers will never have a chance to discover other developers are in fact likeminded. After all, it’s not unprecedented that a contrib module would have a complete rewrite in the -dev branch for the exact purpose of trying out a new design.

Working in a bubble is a terribly narrow-minded approach to open-source software development in general, but it is a cancer within the Drupal community because you can get away with it. There is no such thing as the “module police.” One developer can easily fork another developer’s module to add support for some feature they need on that one project, and nobody would ever know. Sure, maybe someday another developer will be asked to help out on that project and find the forked module, but even then there’s no guarantee that the changes will be merged back in to the community. It’s selfish, plain and simple — and completely unenforceable.

Good Drupal citizens police themselves

Self-policing is what allows the advanced developer to become a good Drupal citizen. They stop working in a bubble. They begin to contribute their efforts back to the community in such a way that acknowledges existing work rather than dismissing it.

They’re not afraid to submit a patch for a new feature on an existing module. They wait for their idea to be reviewed & tested by the community (RTBC), and they keep an open mind about their approach when it needs work. If the patch is rejected by the module maintainer, they find a constructive workaround.

When the good Drupal citizen writes a new module, it is to compliment existing APIs or fill legitimate gaps. They don’t make assumptions about use cases. They write unitasker modules that don’t make assumptions about the theme layer or menu structure. They recognize that some sites will be built with Context and others Panels, and yet others will use core blocks and node templates.

What they don’t do is work in a bubble. Anything they do is done with the assumption that it will be shared with the community in some way.

The community has a right to know what you’ve done and how you’ve done it. Whether it’s shared by submitting a patch, contributing to a 10-page comment thread in an issue queue, writing a blog post, or adding a new module on Drupal.org, good Drupal citizens contribute back. It’s open, it’s transparent. If you’re a PHP genius, the world deserves to know; if you’re barely competent, the world deserves to know that, too. If you won’t stand by your work, then we don’t want you in our community. Stop believing that you’re the only one who will want that feature you’re developing. Stop yourself from thinking that your implementation choices are without flaw.

We all benefit from participation

The Drupal community is lacking a formal peer review process. Participation does not require certification. There are no classes to take. You can start as a beginner and work your way through that intermediate stage of knowing just enough to get the job done, and you can stay employed and do a decent-enough job to never need to grow beyond that.

The measure of a good Drupal citizen, then, is self-policing. Before you fork that module for your own needs, consider how you can integrate your needs with the existing work and allow your Drupal developer peers to review it. Share your expertise with beginners. Encourage your intermediate co-workers to learn new APIs. Be the mentor that you never had because you started with Drupal back when it was just you and Dries.

Bottom line, recognize that we all benefit from your contribution, however big or small, and that you benefit from our collective expertise. No single developer knows more about Drupal than the community does, and yet, there wouldn’t be a community if people didn’t share their knowledge with others.

I promised myself I wouldn’t use that phrase. Damn. ↩
… unless they’re (a) completely unaware of the demand for developers, or (b) completely un-hireable for some reason unrelated to their knowledge of Drupal. Good grief, they should at least be part-time contractors. There’s gold in them there hills! ↩

4 things I learned about myself by working from home

2012-06-06T00:00:00-04:00

I started working from home when I joined Jackson River, and after a week or two of settling in, I realized four things about myself. As it turns out, it’s not hard at all to get into “work mode.” And overall, I’m a lot more productive. But there are downsides, too: I find that it’s hard to stop working at the end of the day. And after over a year of working from home, I felt cut off from the world.

The good

It’s not hard to switch into work mode

Even though I’m in my home, I’ve found it’s not that hard to switch into work mode as soon as I sit down at my desk in the morning. Although I now have a dedicated room for my home office, I was working from a kitchen table for the first month and a half at Jackson River.

Don’t assume that my ability to switch into work mode is just because I can walk into my office, close the door, and shut out everything that might remind me of being at home. Instead, it’s all about setting ground rules and sticking to them.

I have to sit in a chair—a proper desk chair. If I’m on the couch, it doesn’t feel like I’m “at work,” and if I find myself leaned too far back, my neck starts to ache after only a few minutes. The chair can be comfortable, but not too comfortable, like an office chair you’d get in a real office. I think more than anything else, sitting like I’m “at work” tricks my brain enough to forget that my TV or nap-inducing couch lies just outside my peripheral vision.

Music helps a lot, at least it does for me. I’ll set up iTunes DJ to play from a genre playlist or just randomly from my library, and I’m three hours into a series of tickets before I realize it. But I can’t watch TV. This sets off a chain reaction of laziness. I also struggle with podcasts or talk radio, although I’m sure others can multitask just fine.

I also set ground rules with my family and friends: when I’m at work, I’m at work, and there are rarely exceptions to that. I can’t be relied on to do household chores (except sign for packages, small things that don’t detract too much from my concentration). Sure, I can answer the phone, but I can’t talk socially. I can make my own lunch, sure, but watching over a roast in the oven might be too much. This might make me seem uptight, but I need that level of understanding and respect for my work time. It also helps me simulate the physical distance from home life that an office commute provides. I have been fortunate in that everyone in my life had been very understanding of this rule since day one.

I’m a lot more productive

I’ll be frank, some days at my previous office jobs were spent just making sure that the desk chair didn’t float away. (It never did.) So yes, there was a lazy component to the job to begin with. But I would say the most significant barrier to productivity in my old office job was the open door. People would just come in with their help desk issues and I would stop what I was working on to help them. After the first year of this, I mostly stopped working on web development because I was so discouraged by the interruptions.

I think the secret to productivity when working from home is accountability. I’m accountable for the hours I spend, the tickets that I accept and complete, and the emails I send back and forth with clients. I need to maintain a certain level of output, and this keeps me from remembering that I could easily pick up a guitar and start jamming away.

The bad

There are fewer barriers to productivity when working from home, provided that you’ve set up your environment correctly. So at first, there will be a temptation to take this too far—to find out just how productive you can be, to prove to your friends that, yes, where you work is a real job, and so forth. My first six months at Jackson River were a blur of completed tickets and a real productivity binge.

It’s hard to stop working at the end of the day

“Honey, it’s almost 9 PM, can you please come downstairs and join me for dinner?” “In a minute, I want to finish this one last ticket.”

Congratulations, you’ve created an environment of productivity and intense concentration—in your home. One consequence is that when 6 PM rolls around, there’s always one last task, one last email to write, one last ticket to return to the client. How do you turn off your brain when you’re in a uninterrupted headspace that comes so rarely in every other office job you’ve ever had?

I don’t have an answer for you, unfortunately. I tried setting a “work curfew,” but the first time you break curfew for an urgent “our website is offline” issue, you’ve rendered it meaningless. Working from home brought out a side of myself that, frankly, I don’t find especially charming: I am now a workaholic.

Just be mindful that tomorrow will be yet another full work day, and the tickets you’re working on tonight at 11 PM won’t be seen by the client until 9 AM at the earliest. Any tickets you complete after hours are just going to be replaced by new tickets tomorrow. I’m not suggesting you blow off work, or set a slower than realistic pace for yourself, because that benefits no one. But if this was an office job, you’d be eyeing the people leaving the building at 5:30 (because the boss left at 5) and wondering whether finishing two more tickets is worth coming home so late.

I felt cut off from the world

In the first six months of my job, I found that I wasn’t leaving the house except on the weekends. We would run our errands on Saturdays or Sundays and I would have enough lunch food to last me through Friday, and I just didn’t have a need to leave the house. Not healthy, not one bit.

One perk about a commute is that you’re out in the world, experiencing it with other people. You go to an office full of people, you go out to lunch with other people, you’re participating in society in a physical, tangible way. Yes, the 45 minutes on the train or the 2 hours in traffic are a real drag, but it’s real.

Again, I don’t really have a solution to offer. If you’re going to be working from home, then you need to make time to leave the house. I never really figured this one out for myself, and Jackson River opened a DC office just as I was reaching my breaking point. If you have lunch options that are walkable on a nice day, take advantage of that. Is there a park nearby that you can walk around in the mornings, evenings, or midday? Aside from being an excuse to walk away from the computer (and avoid the workaholic mentality), clearing my head with a good neighborhood walk usually helps me solve a tricky software bug or come up with a new approach to a design problem that has been plaguing the team.

Overall, I give it a B+

Working from home can be a real enjoyable experience if you do it right, and it’s a lot easier to be a productive worker at home if you approach it with the right attitude and preparation. I think it’s a win-win if you go in with eyes wide open. There are pitfalls to watch out for, certainly, but overall it’s a manageable, positive experience.

How to change Mac OS X Terminal setting per SSH host

2012-01-05T00:00:00-05:00

So, call me crazy, but when I’ve got a dozen Terminal windows and tabs open at once, and they’re all ssh’d to different boxes, it gets hard to remember which host is which. I end up checking the prompt or doing something like hostname to remember where I am. So, I found a way to automatically switch the Terminal settings to color-code my SSH hosts.

There are two steps. First, we need to create an AppleScript script¹ that will actually do the switching of the Terminal settings. Save this code somewhere memorable, as we will refer to it later on.

The next step is to update your ssh_config (normally ~/.ssh/config). We’re going to use the LocalCommand directive to trigger our AppleScript script after the host connects. We also need to permit that directive via PermitLocalCommand yes. It’s disabled by default, presumably for security reasons — so only enable it per host, not globally.

Add something like this for each host you want to have color-coded, along with the Terminal setting name to use:

Host example.com
  PermitLocalCommand yes
  LocalCommand osascript %d/scripts/set_term_settings.scpt "Homebrew"

Replace example.com with your host. Refer to the ssh man page for escape character substitutions — I’m using %d here for my local user’s home directory. (Oh, and make sure that the osascript command actually works by running it on the command line first.)

You can add your own Terminal settings, or use the built-in ones. You can also tweak the script to set properties individually rather than using a setting name. I’m using this simply to change the background color and opacity, but you could go nuts and set any other property in the setting. This script could be pretty powerful depending on how you want to use it.

“AppleScript script” looks redundant, but “AppleScript” by itself looks weird, too. Not sure what the standard is, but I’m going with redundant. ↩