Make your life easier with Firefox bookmark keywords

I think this is one of those things that people either know about and use actively, or have never heard of. If you’re the latter: read on!

I often need to view bugs in Bugzilla by bug number, and typically resort to going through my history and hacking the URL. It works, but it’s kind of a pain. But you can make it as easy as typing “bz 123456” to look up bug #123456.

Pull up the Bookmarks menu (“Bookmarks” / “Show All Bookmarks”), and then select the “Bookmarks Menu.” Then, “Organize” / “New Bookmark.” There’s probably an easier way, but it eludes me. Here’s an example of what I filled in:

 

The “keyword” is what you can type into the URL bar to trigger the bookmark. %s is the rest of what you type, analogous to ARGV for you shell scripters. What’s magical is that you can plug %s into the Location in the bookmark.

So now “rm 1234” will look up task 1234 in Redmine. Setting one up for Bugzilla (I named mine “bz”) is just as easy.

A Tale of Two Servers

While you might think that working with cloud computing means I don’t deal with hardware, really the opposite is true. True, there’s the public cloud like Amazon EC2 or Rackspace. But then there are private, on-premise “clouds” — VMware vSphere, Red Hat’s RHEV-M, OpenStack, etc. And you can’t exactly run a virtualization environment inside of a virtual machine, so suddenly there’s a whole bunch of hardware needed.

While I have access to setups for my “real” work, it’s a lot harder to say, “I’d like to tinker with setting up RHEV” or “I want to play around with Gluster” and grab a couple of machines to do it on when they’re shared work resources. Used server hardware can be absurdly cheap on eBay, so I decided to pick up a few machines. The other thing I like about buying things on eBay and not needing them in any particular hurry is that you can only buy things when they are legitimately great deals. So today the second of two servers arrived. Here they are:

(Obviously, I need to get a rack/cabinet in which to mount these next.)

What’s interesting to me is how insanely different the two boxes are.

The top server is a Cobalt RaQ 2, sporting a 250 MHz MIPS processor and 128 MB RAM. It takes a single ATA drive, though none came with the unit I bought.

The bottom server, which doesn’t look nearly as cool, is a Supermicro machine. I picked it up for $230, shipped, on eBay. It’s got dual sockets, each a quad-core Xeon, and 16GB RAM. The four hot-swap SATA bays are empty, but not for long.

The Cobalt was more of a collector’s item. I’m having a hard time pinning down the actual history/timeline, but based on the owner’s manual’s copyright date, it was released towards the end of the 90’s, possibly 1999. And back then, I thought the RaQ was the coolest thing ever. It looked incredibly awesome, but it was also this amazing appliance — a total web-hosting setup in one little pizza-box enclosure. It got me intrigued. But being a kid, there was no way I could have bought a cutting-edge server appliance, much less paid to host it somewhere.

But today, it’s something else about it that intrigues me — the advertised power draw is 35 Watts. The 250 MHz MIPS CPU and 128 MB memory don’t exactly qualify this thing as a powerhouse, but I’d like to throw one of a handful of the Linux distros with MIPS support on it and use it as a random always-on Linux box, for things like a DNS cache, ssh bastion host into my home network, NTP server, etc.

I’ll let you know how it goes.

Musing: Conversational Guides

For Aeolus, we’ve been talking a lot lately about how to improve the user interface and make things generally more intuitive.

One thing I noticed the other day was more of a general difference between desktop apps and many web apps — the presence of explanatory text on each page, often with a sort of conversational tone. In a desktop app, you might be presented with a form with various controls that you’re expected to understand. In a web app, you might get asked, “Hey bro, now that you’ve X’ed the Y, it’s time to choose your Z!”

We probably don’t want to address anyone as “bro,” but I’ve been thinking a bit about the concept of what this might look like in Conductor. We have a variety of forms users are asked to fill out to complete certain actions, and it’s not always immediately obvious. And for someone new to Conductor, our teminology isn’t always intuitive, either. (And for intermediate users, it’s still easy to get a little bit confused from time to time.)

Here’s an example of what I’m thinking. When you go to create a deployable, here’s what you see (click for full-size):


That’s great for power users, but what if you’re not one? Wouldn’t it be nice if there was a little bit of a description? (And if you are a power user, be honest: you’re not going to read the instructions anyway, so they won’t do you any harm.) What about something like this:


The text there is really just a quick example, so please don’t worry too much about the exact tone or what we should do for styling of the text. For now I just threw a %p tag at the top of the page and took a quick stab at telling the user what they’re meant to do here. We should probably do better than I did, and actually explain what a “Deployable XML file” is, and how they could create one.

What do you think about this? Are there best practices for this sort of thing?