Don't forget to bring a jacket!

Ah, springtime in Washington, DC. Where unpredictable weather comes to sow its wild oats.

It's been a distressingly long time since the days my mother was around to remind me to 'bring a jacket', but it got me thinking: The judgments that I make on whether to don a blazer in the morning are based on fairly quantifiable data. I know at what temperature I like to wear a jacket, I know what the temperature for the day is supposed to be, and I know not to wear suede if there's a chance of thunderstorms.

It seems likely that in the age of ultra-accessible information (of which weather seems most ubiquitous), I could build something to do this decision-making for me. Inspired by the geekery at this year's SxSW, I started envisioning a service that would send my phone a text message each day—advising me on whether I should wear jeans or shorts, a jacket or a t-shirt, or bring an umbrella.

WeatherMama had been conceived, and its 2 month gestation is finally almost over.

Read on past the jump for all the geeky details.

Wanting to learn more about Drupal 5, I selected this as a the foundation for my little service. Despite the unfamiliar menus (why??), I quickly learned to love the new forms API and the beauty of hook_form_alter(). A handy weather module from Drupal.org module repository proved to be a great starting point for forecast data.

I had initially intended to use profile module to store my user data, but found myself frustrated with its limited flexibility when it came to rendering form fields I needed to use. So I instead decided to go the custom module route and got my feet wet with the excellent Forms API (which was completely new to me, although the rest of the tech team here has been using it for months).

The weather module I had chosen used METAR data (the same data pilots use) from area airports, which initially appeared sufficient for my needs. Unfortunately, it didn't take long before I realized METAR only indicates the current conditions, not forecasts—something I should have remembered from my flying days. Luckily, TAF data (terminal area forecasts) are in the same format, and do contain forecast data. After tweaking the module bit to support TAF, I started work on the text messaging piece.

Since EchoDitto doesn't have its own aggregator—and I had no budget for this project—I decided to utilize the various carriers' e-mail -> SMS gateways. That first meant determining the different e-mail address conventions that the carriers use (e.g. xxxyyyzzzz@cingularme.com, xxxyyyzzz@vtext.com). Once I compiled that, all it took was a simple SELECT...CASE and PHPMailer to have a functioning text messaging component.

The next challenge was scheduling. Drupal is pretty well-suited for handling multiple timezones, even allowing users to set their own timezone during registration. Since Drupal stores timezones as an offset from GMT, the handy PHP gmdate() function made it relatively easy to account for users in different parts of the country. By using GMT exclusively throughout, I also avoided the complication of our servers being in Seattle, offset from the default EST timezone I wanted to use for the site. A simple cron job, running at 5 minute intervals, completed the picture.

At this point I had a functioning service — but I quickly discovered that the TAF data I was using was unreliable at best. Temperature data was fairly consistent, but the current weather conditions (e.g. mostly sunny, rain showers, etc.) were frequently absent. I also discovered that the TAF data contained a 24 hour forecast, which was not well-suited for my use, since in DC it can be 85 during the day and in the 60s at night.

In looking for alternatives, I was surprised that there weren't a zillion Web services out there eager to hand me on-demand XML weather forecasts. I eventually settled the National Weather Service's National Digital Forecast XML Web service, a which provides weather forecasts via a SOAP interface. (If people find this useful, I'll have to implement a caching server, as the NWS requests developers not query for a single point more frequently than once an hour.)

To handle the SOAP interaction (a protocol Tom insists Microsoft designed to be difficult to use), I used a Web services toolkit for PHP called nuSOAP. To parse the results, I used PEAR's excellent XML Parser and XML_Serializer, which build handy objects and associative arrays from an XML document.

There you have it — a text messaging weather forecaster, from start to finish.

Well, almost finish. Now that I've completed the initial phase of the project, it's time to start working on the weighted survey questions and formulaic logic to replace Mom's infallible recommendations. More on that later...

In the meantime, sign up! I hope you find it as useful as I do.