articles tagged with 37signals

One command to rule them all

no comments yet, post one now

LOTR rings DRY isn’t only a good practice in software development. Developers should always be looking for better ways to not repeat themselves. Everything we do more than once could (and probably should) be a candidate for optimisation. From simple repetitive tasks like, connecting to remote servers to setting up a fresh development environment (and everything in between).

At HouseTrip we have amassed a collection of shortcuts, scripts, and rake tasks to make our lives that little bit easier. In an effort share them throughout the team and make some of them more well-known, I decided to create an all new ht command.

37signals Sub

The ht command uses sub, a command line framework from 37signals. It’s a great starting point for building commands like this; with autocompletion, help, bash/zsh support and aliases all built in.

Helpers and configuration

Sub has some great conventions, but to allow us to direct commands at any one of our (many) staging and production servers, I forked it and added some helpers and configuration options of our own. Our staging servers can be temporary things, so its important we can easily change where we want to direct and auto-complete commands to.

Our server connection information lies in a simple yml file for each Rails environment we have. So we can issue a single command like this;

ht console staging100 # or ht c staging100

and have a Rails console (running on the remote staging100 machine) in no time. In the future I’ll try to create a pull-request with these helpers (to sub).

These helpers also include methods for handling and logging command output (even speaking output with the built-in OSXsay’ command). So far the ht command has been a hit, a trusty friend (with a voice) to call on for saving time.

Command Ideas

To give you some idea of what I’ve implemented so far (or plan to soon);

  • `ht-ssh (env)` – connect to any server
  • `ht-console (env)` – ssh and ans start a Rails console on a remote server
  • `ht-dump (db-name)` – grab a fresh (anonymised) database dump and import it to your development env
  • `ht-cache-clear (env)` – clear the Rails.cache on a remote server
  • `ht-be-admin (env) (username)` – convert an existing remote user to an admin
  • `ht-jobs (env)` – get some basic stats on job queues
  • `ht-bump-job (env) (id)` – bump the priority of a remote job
  • `ht-booking (env)` – show stats on the last few live bookings
  • `ht-gif (keyword)` – fetch an animated gif into your paste buffer (with
  • `ht-git-visual (time-ago) (repo)` – visualise git repository activity (with Gource)
  • `ht-add-server (config)` – add new server details to your local ht config file
  • `ht-mugshot (keyword)` – search and grab a photo from our team intranet page
  • `ht-laptop` – kick off a setup script that installs and configures your laptop for HouseTrip development
  • `ht-hammer` – replay a realistic log file of traffic requests to a staging server (with httperf)

Our ht command isn’t open source just yet, but it will be soon!

Opinions matter

no comments yet, post one now

Be opinionated. In software its important. I’d go as far as saying it can completely make or break your app. It’s something that 37signals have been advocating for a long time, and something they practice daily in saying ‘No’. In fact in both Rework and Getting Real it is clearly stated that saying ‘No’ should be the default answer when considering any new feature (including their own!) I couldn’t agree more.

What happens when you don’t say no? It leads directly to feature bloat or in the long-term a big ball of mud. And if your business is beholden to clients who can throw financial weight around, then your’e really in trouble. You can end up second guessing their needs or prospecting new features that will attract them. This can be more true in b2b products where I think it can be much harder for people to say ‘No’ by default.

Apple take sides in a very obvious way. Rather than be all things to all people, they continually make game changing decisions that their competitors probably haven’t even considered. No DVD-drive in the Apple Air, loosing the conventional right-mouse button, more often than not they are constantly removing and simplifying their products. Look at everything thats not built into the iPad, you’ll find a long list of features if you compare against traditional touchpad devices.

All this creates division (and a buzz) amongst fans and critics. But have you ever heard an outcry over the latest updates to Microsoft Office? People just don’t care when an already bloated app tries to be all things to all people (and yes, I’m writing this post in Writeroom)

In building Bugle I have made lots of decisions along the way in code, the interface and even the server stack. Drawing on my own experiences and motivations has helped to keep things simple. Im not doing competitor comparisons or even looking at what people consider normal steps in the processes. I’m just defining the problems a user faces and trying to offer the simplest solution that will meet their needs.

Of course opinions matter in blog posts too, so what do you think, agree or disagree?

April 01, 2010 21:04 by
← (k) prev | next (j) →