Tag: Software Development

Updates to INN’s Deploy Tools

Posted on by Ryan Nagle

We've made a lot of changes and added a bunch of new commands to our deploy tools since the last time we checked in.

Most notably, we've added commands to help scaffold and run unit tests for your plugins AND your themes. Behind the scenes, our scaffolding and tests works as described by Will Haynes in this post.

Other changes include migration to Fabric's new-style task declaration and updated documentation.

Unit testing tools

To scaffold/set up tests for your theme:

$ fab dev wp.tests.setup:largo-dev

This command:

  • Drops and recreates your testing database (which should always be throw-away, ephemeral)
  • Copies essential test files (e.g. phpunit.xml and a tests directory with test-sample.php and bootstrap.php files) to your theme or plugin directory if they are not already present
  • Installs the WordPress test framework to /tmp/wordpress-tests-lib/includes
  • Configure a wp-tests-config.php file and place it in /tmp/wordpress-tests-lib

With those files in place, you can run tests for your theme or plugin:

$ fab dev wp.tests.run:largo-dev

Example output:

Screen Shot 2014-11-25 at 9.45.54 AM

Namespaces and aliases

The other big change we made was moving all commands to Fabric's new-style task declaration. Using new-style tasks gives us all the benefits described in Fabric's documentation on the subject.

While the deploy tools are not taking advantage of every feature of new-style tasks, they are better organized thanks to namespacing and aliases.

Here's some example output from fab -l:

Screen Shot 2014-11-25 at 10.00.07 AM

Here you can see each module (and submodules) along with defined tasks. Tasks use dot-syntax, which should feel more explicit and intuitive if you're familiar with Python (which is what Fabric is built on).

Also note that the command wp.migrations.s2m is an alias for the much-longer, sometimes-harder-to-remember command wp.migrations.single_to_multisite.

I'm very lazy, so anytime I can save some mental energy and type a bit less, I consider it a win. This is as true for commands I use very frequently as it is for commands I use once in a great while.

Documentation

We also expanded the deploy tools' documentation to include all commands. You can find the documentation on Github.

Notes

Remember, the deploy tools were built with our situation in mind. We deploy to WP Engine, so some stuff is very WP Engine specific.

For example, the wp.fetch_sql_dump command only knows where WP Engine stores recent SQL dumps. The wp.maintenance.start and stop commands assume you are deploying to a host that uses Apache and that you have a .htaccess file in the root of your FTP server.

With that said, much of toolkit will work with any host provided you have (S)FTP access, including the push-button deployment rig I wrote about previously.

If you are using or thinking about using the deploy tools, have questions or suggestions, let us know.

Spaces or tabs: which will YOU choose?

Posted on by Ryan Nagle
Source: 1985 McCall's Magazine

What follows is a Very Important Blog Post. Please, take this seriously.

It’s a question that every tech team inevitably debates and, as with many topics in software development, people can be downright religious about their stance on spaces versus tabs.

I’m here to (officially >_<) declare such debates a waste of time.

Be flexible enough to use either, depending on the project.

What’s more important than an individual's preference for spaces or tabs is that the team agree on a style of writing code and stick with it.

In our case, since we do quite a bit of work with WordPress and WordPress’ best practices indicate the use of hard tabs, we decided to use them for our WordPress work.

For any code that we write outside the context of a specific framework/project (e.g., WordPress), we use four spaces. This includes HTML, JS, CSS, Python and, occasionally, PHP without WordPress.

Soon, you'll be able to see the details of our coding style guide. I'll update this post once that's available.

If you’re interested, my personal preference is spaces.

Here’s why: hard tab length is treated differently by different text editors and may be adjusted to suit an individual’s preference. This can mean varying degrees of readability for the same piece of code on different machines. It can also wreak havoc on code written in languages like Python or Coffeescript, where whitespace is, in fact, significant.

For more information on why you should never ever use hard tabs (except sometimes), check out:

For a less one-sided look, check out Tabs versus Spaces: An Eternal Holy War.

This concludes my Very Important Blog Post.

Editor's Note: ...but don't even get us started about using two spaces after a period.