Update 2007-10-05: voting for the rumble is closed. We didn’t win, but we had a lot of fun participating. Thanks very much to those of you who took the time to vote for us, and for throwing us some feedback, we really appreciated it!

Whew, what a weekend! We signed up for the Rails Rumble a couple of weeks ago and competed this past weekend with quite a few other folks to put together an entire Rails web application from start to finish in 48 hours. We made our final adjustments just minutes before the SVN repository was closed to any new changes; it was a bit hairy just before midnight as everyone was checking in their code and the SVN server sloooooowed down.

We’ve been really busy with PingMe over the last few weeks, so we saw the Rumble as our chance to crank out most of the code for our next big project, TagTime (and we really want that belt!). Like PingMe, TagTime solves a particular need for us as a consultancy — a time entry system that gives us extremely flexible reporting for billing, streamlining how we bill our customers and helping us to quickly get metrics we can use to make informed decisions and estimate future growth. At the end of the month we don’t want to be hacking Excel spreadsheets exported from Product X to massage them into the views we actually want. We’ve tried a lot of other apps out there that came close but none of them have quite got it right. With TagTime it’s very easy to look up, for instance, how many hours two folks on a team billed for a particular group of tags, like ‘Company X’, ‘oracle’, ‘support’ for a range of dates, or maybe last month.

From there we can do RSS feeds of the data, Excel exports, invoice printing, etc. The version of TagTime up on the Rumble site doesn’t have the export functionalities in it yet, but we did manage to get the RSS feeds in there before the Rumble closed.

Cranking out so much code in such a short amount of time could have been quite a mess, but we had a lot of success following an iterative battle plan we had drawn up before hand. Our basic approach was for one of us to handle server setup while the other began coding the models, unit tests, and building fixture data that we could work with immediately. Once we were really hammering away at the app, the creation of the fixture data early on helped us immensely (although I’d be lying if I said we stuck with testing every bit of code until the end, there just wasn’t enough time!) Careful planning and solid execution is the Zetetic method, and it served us well.

One key feature that we didn’t get to implement during the Rumble was graphing — TagTime will provide illustrative graphs for date ranges, and we’ll use some means and averages to generates graphs to help predict what our billing might be in the upcoming cycle.

All in all, we’re very happy with how it came out and we’re ready to start using it for our own billing. Everyone else will have to wait a bit while we do just a little more work to get it ready for a proper launch. In the meantime you can check out TagTime yourself over here on the Rumble site, where you can vote for us if you are so inclined. Voting for the Rails Rumble is open to anybody, so if you have a spare minute and you like our products we could really use your vote. The winners will be announced at the end of this month at the Ruby East conference, and we’ll be there, too, if you want to say hello.

Many PingMe users are really excited to be using Jott with PingMe. But it seems a few users that have recently joined the service are getting stuck on how to correctly specify when the Ping should be sent.

Human beings tend to be a lot better at learning how to write than computers are at learning to read. Therefore, when we were first designing a short-hand for creating Pings remotely we had two priorities for the “time” language:

1. Make it very quick and terse so that users would have to do as little typing as possible from their mobile phone
2. Make it easy for PingMe’s computers to reliably parse

PingMe’s time codes do exactly that – they allow you to specify the minimum amount of information necessary to convey a date and time. ‘h12 m30 call mom t:m’ is a lot less typing, than say, ‘remind me to call mom at twelve thirty on my cell phone’, and it’s 100 times easier for our computers to process.

When we introduced the ability to create Pings by speaking via the Jott service (with which are totally unaffiliated), we found that the time codes fit well there too. Numbers and and interval codes (days, weeks, hours, minutes) were reliably transcribed by the system in our testing with a very low failure rate. Our primary concern is always reliability, so we didn’t focus as much on a natural language translation: you basically speak the exact same time codes that you would type into an email or SMS interface to PingMe.

Sure, it would be really great to be able to say “remind me to call mom at twelve thirty on my cell phone,” or something similar. That will take more work on our part, and we need to evaluate how critical a feature that is for our users. To put it in perspective, we’ve processed thousands of time-coded messages, and many users are already comfortable with this interface.

In the meantime, lets review how to specify a Ping remotely and go over what you need to say to get the job done when you create a Ping by voice using Jott (or via SMS for that matter).

Messages to create a Ping must begin with some information telling PingMe when to send the reminder. The time codes we use for this information are documented in our help here, but here’s a basic example:

h12 m30 Call mom

The full set of intervals and their synonyms follows:

  'min'    => [ 'm', 'min', 'mins', 'minute', 'minutes' ],
  'hour'   => [ 'h', 'hr', 'hrs', 'hour', 'hours' ],
  'day'    => [ 'd', 'ds', 'day', 'days' ],
  'week'   => [ 'w', 'ws', 'wk', 'wks', 'week', 'weeks' ],
  'month'  => [ 'mo', 'mos', 'mon', 'mons', 'month', 'months' ],
  'year'   => [ 'y', 'yr', 'yrs', 'year', 'years' ]

When PingMe receives a message, it evaluates it left to right. It sees the h12pm and sets the ping to go off at 12pm today. Note that if 12pm today has already passed, this Ping will not be sent! Then PingMe sees the ‘m30’ and updates the Ping to be sent at 12:30pm. Another form of time code is to specify a number and then the interval name, like this:

1mon 1d h6p Call mom

In this case PingMe sees the ‘1mon’ and recognizes it to mean ‘1 month from now.’ Then ‘1d’ pushes the time ahead one more day. Notice that we’ve switched back to the other format to set the time to 6pm! PingMe long-hand for this message would be:

1 month 1 day hour 6pm Call mom

So this statement means ‘call mom in one month and one day at six o’clock PM’ The example is perhaps a little contrived but gives you an idea of how flexible the time codes are.

Also notice that you can abbreviate the interval names, but you don’t have to. When speaking into Jott you should use their full names, which seems to help ensure accuracy, like this:

one month day fourteen call mom

If you have feedback on the time codes or Jott interfaces please let us know.

Last night we saw a really big surge in Japanese users on PingMe. Irashaimasen! We wondered what was up and saw that this article on a Japanese website might have been the cause.

We were really curious to find out what the article says so we popped it into Google Translate, but their Japanese support is still a little wonky. Can anyone help us out? Is it a decent review?

Timezones are a difficult thing, whether you’re traveling or communicating across them. While the jet-lag will always catch up with you, PingMe won’t let you down when you’re crossing timezones and borders.

In the Profile screen you can select your Timezone from a drop-down list. It provides many different timezones to account for the small adjustments to time that are made by various local governments around the world.

Let’s suppose that you are traveling from the East coast of the United States to the West coast. Changing your Timezone to ‘US – Pacific’ will change the display time of your current pings by three hours. They will still be sent at the same time, which is to say that a Ping set for 5pm Eastern time will be sent at 2pm Pacific time. This is great if you don’t want to miss that conference call with your boss at 1pm Eastern time.

But what if you’re not just making a short stay, what if you’re moving? Or maybe you have daily Pings (like “wake up,” which seems to be very popular) that you want to go off at the same time of day in the new time zone? We’ve got you covered.

When you select a new Timezone on the profile screen, a check box appears labeled “Move all pings to this timezone?” If you select this option and save your profile, you’ll find a Ping that was scheduled to be sent at 5pm Eastern time will now be sent at 5pm Pacific time.

We’ve been hard at work on PingMe over
the past few weeks. Here are a few improvements to the way you can create Pings remotely from your mobile devices.

Create Pings with Email Subject

Hardcore Blackberry and Email wizards everywhere often type quick notes directly in the subject line of a message. It saves keystrokes and lets you easily find messages by subject in your message list view. Now you can use this messaging style to create Pings by placing the entire create message in the subject and leaving the body part empty.

New Flags for Remote Pings

We’ve added some new flags that let you specify confirmation mode and set tags when creating a Ping by e-mail or from your Phone:

1. Specifying c:y or c:yes after your message will require confirmation on a Ping
2. Tag your mobile Pings using the z: flag, followed by a list of tags, separated by spaces, commas, or both

Here’s an example that would create a tagged ping that requires confirmation:

1d h5p Call Dunder-Miflin, close paper deal c:y z: followup calls sales