Introducing AuroraAlarm

I just finished up work on my latest side project, AuroraAlarm.

AuroraAlarm is a FREE service that will notify you via SMS when conditions are optimal for viewing the Aurora Borealis in your area.

I have always enjoyed watching the weather and the stars. However, I’m not much of a night owl, and every attempt I’ve made to stay up late enough to see an Aurora after a solar event has failed, miserably. Time and time again I would fall asleep, and wake up to find that the conditions were great for viewing an Aurora the night before.

I wanted something that would wake me up if there was a possibility of seeing an Aurora. So, I created AuroraAlarm to do just that.

How it works

Every evening, AuroraAlarm checks to see if any solar events have occurred that could trigger a geomagnetic storm, which can produce an Aurora. If a solar event has occurred, it will send a text message notifying all users of the event, asking if they would like to receive a text message during the next few nights if conditions are optimal for viewing the Aurora.

If they indicate that they would like to be notified, AuroraAlarm will send them a text message at night if conditions are optimal for viewing the Aurora in their area.

What are optimal conditions?

  • Dark. Likely in the hours past midnight.
  • A Kp index strong enough to push the Aurora down to their geomagnetic latitude.
  • Clear skies.
  • A dark moon.

The goal

I have no idea if the aurora will be visible from where I live. Honestly, I think there may be a bit too much ambient light for me to see it. But, with the help of AuroraAlarm, at least I’ll be able to find out. And, I’m really not too far (about a 15 minute drive) from some REALLY dark areas. I certainly wouldn’t rule out making this short trip if it allowed me to see one of nature’s most fantastic displays.

An Adjustment in Priorities

I think it is very common this time of year for people to reflect, especially on their accomplishments during the past year, and what they would like to accomplish next year. Personally, I’ve been doing quite a bit of thinking about my development as a software engineer.

It feels as though, over the past couple of years, the pace at which I have been learning has slowed. This troubles me. One of the reasons I love the software industry is that there is always something new to learn. I love learning about new ways to solve problems with technology. And, learning is what you must continue to do if you are to stay relevant as a software engineer.

Now, this doesn’t mean that I haven’t learned anything over the past couple of years. Quite the contrary actually. I’ve really been enjoying the boom our industry is seeing in non relational data storage systems. We’ve been utilizing many of these newer technologies at Signal with great success. I’ve been an active member of the ChicagoDB users group, attended a few conferences on this topic, and even gave a few talks…a first for me. I’ve also been learning first hand how to scale a system as we’ve taken the Signal application from one capable of sending thousands of messages per “blast” to one that regularly sends millions of messages per “blast”.

However, something is missing. I used to read more. I used to blog more. I used make a sincere effort to learn a new programming language every year. I used to constantly download and tinker with new tools. These things have fallen to the wayside. And, I really miss them.

Instead, over the past couple of years, I have been spending the majority of my time creating. When creating a new project, there is usually something new to learn. That’s what drives me to create the project in the first place. But as time goes on, the cost of the time I spend working on the project starts to outweigh the benefit. I reach a point where I am no longer learning anything while working on the project. If I’m not benefiting from working on the project in any way (now that the learning part has mostly dried up), there is little motivation for me to keep working on it.

Part of me feels obligated to keep these projects going, and to get them to a point that I would consider “done”. I’ve never been a quitter, and stopping work on these projects sounds like quitting to me. However, it makes little sense to continue working on something that gives me nothing in return. I will still fix bugs that are reported, but any new development on most of my active projects is likely going to cease. Time is precious, and I need to make the most of it.

So as of right now, I’m making an adjustment in priorities. I’m using my free time to invest in myself. To read more. To blog more. To get back to learning a new programming language a year (Clojure is on tap for 2012…I’ve been wanting to learn it for 3 years now). To resume downloading and tinkering with tools that spark my curiosity. I want to start practicing how to write code, like I learned at the code retreat I attended over the summer.

I’ll still be creating, as I’m someone who learns by doing, but I have a feeling from now on my projects will be much, much smaller.

It is impossible to “find” time to do something. You have to make time.

Introducing Proby – Task monitoring made simple!

Note: This entry has been cross-posted from the Signal company blog.



One Monday morning about a month ago, I was browsing through open issues in our bug tracker looking for something to work on. It was my week on “technical support”. At Signal, the engineer on technical support spends a week working on non customer facing issues with our infrastructure, process, etc, that are too large to simply knock out as you encounter them.

An issue entitled “Add monitoring to detect jobs that do not start” caught my attention. We already had monitoring in place to alert us when a job fails. However, we had nothing to alert us if that job never starts in the first place. We have many scheduled jobs that run in the background, some pretty important, and have been bitten on more than one occasion by reoccurring jobs that had not run for quite some time.

I bounced some ideas off the team, and we all agreed that that it made sense to create a new application to monitor our scheduled tasks. The app would know what is supposed to run, and when. We would change all of our jobs to “ping” the app when they start and finish. If the app detects that something did not run when it was supposed to, or did not finish when it was supposed to, it could alert the team.

And just like that, Proby was born.

“What’s with the name?”, you ask? I likened the application to a probation officer, keeping an eye on wayward tasks.

Since going live, Proby has caught several issues with our scheduled jobs that would have gone unnoticed…many more than I would have anticipated. It has also evolved into a fairly complete application. It is easy to setup new tasks. It holds onto the execution history of each task, allowing you to see a trend of the run time for each task, and which runs resulted in an alarm. It supports alarms via email or SMS, using Signal’s SMS messaging API. It has several settings that allow you to tweak exactly when an alarm is sent, cutting down on the number of false alarms. And, thanks to designer extraordinaire Drew Myler, it looks amazing!

Shortly after creating Proby, we realized that there is no way we are the only ones who have had scheduled tasks go days without running, unnoticed. So today, we are making Proby available to the general public. It is currently in closed beta, and we are letting people in slowly to flush out any bugs or other issues. Use of Proby is also FREE while it is in beta.

Interested? Head on over to http://probyapp.com/signup and signup to participate in the closed beta! And, don’t forget to follow @probyapp on Twitter for updates!

Build Your Own Sandbox Application

Sandboxes are fun. A simple box full of sand, a bucket, and a shovel somehow opens the imagination like nothing else. You can build anything you want, keep it around for a while if you like it, add to it, subtract from it, or crush it in Godzilla like fashion if you so choose. You can experiment with your creation in any way imaginable, without consequence. Creating things in such a carefree environment can be refreshing, and rewarding.

I think that it is a great idea for developers to have such an environment for themselves where they can try out new technologies, techniques, or processes. Setting up a sandbox now-a-days is pretty easy. Machines are cheap, or free if you’re not picky and keep your eyes and ears open. That 4 year old PC that your cousin is throwing away because he got a brand new Dell for Christmas will fit the bill just fine. Linux is free, runs great on older computers, and has the power and flexibility to host virtually any application. Sign up for a free DNS service such as DynDNS and poof, you’ve got yourself a little server that you can reach over the Internet. My sandbox is a dusty old dual Pentium III with 512 MB of RAM, which is running Ubuntu Linux. It fits the bill quite nicely if you ask me.

But a sandbox is only half the equation. For developers, we need an application that we can play with in the sandbox. Something we can poke and prod. A sandbox application so to speak. There are several reasons why you many want to create a sandbox application.

Platform for playing with new technologies

Perhaps the biggest reason for creating and maintaining your own sandbox application is that it can serve as a platform for trying out new technologies. Doing this at work can be tough. Your boss or client may not be thrilled to hear that you completely re-wrote part of the application to use the bleeding edge release of some hot new framework because you “thought it was cool”. But, there’s nothing stopping you from doing it with your own application. Even if you rely heavily on your application, there’s no reason why you can’t fork your code, and give the new technology a try on a separate branch. If it works out you can merge the code into the main branch, and if not you can always abandon the changes. Now, this approach will only work if you have your application under source control (which you should). If you don’t mind giving the world access to your code, GitHub will host your code for free. Otherwise, it’s very easy to setup your own source control system in your sandbox.

Material to blog about

Trying out new technologies, techniques, or processes can also give you plenty of material to blog about. If the technology/technique/process you are tinkering with is hot, it is very likely that many people will be interested in reading about your experience. If you blog frequently about topics that people are interested in, you’ll steadily increase readership. This could be very good for your career, as well known programmers generally don’t have a hard time finding work. Work usually finds them.

Create something that you will use

What’s the point in going through all of this trouble to create something if you never use it? I’ve created a few applications that I use on a regular basis. Not only did these applications address some need that I was currently facing, but having a sandbox application that you actually use means that you will be more likely to maintain and enhance it.

Looks great on a resume

Employers love to hire people who show an interest in their field outside of work. I’ve found that people passionate about their field are usually better at their jobs than those who show up at 9, work on the same ol’ stuff for 8 hours, and go home. Having a sandbox application shows people that you love what you do so much that you have dedicated time outside of work to create something that you care about. This especially holds true if you’ve put serious thought into your application, and are excited to show it off to anybody who asks to see it.

Release it, and potentially help others

One of my colleagues once said,

Your parents lied to you. You are not special. There’s millions of people out there just like you.

He wasn’t trying to be mean, this time :) He was simply pointing out that you are not alone. If you are facing a problem, odds are there are hundreds or thousands (or more) of people out there who are facing that same problem. Releasing your application could be helping all of these people. Perhaps it would help them so much that they would be willing to pay for it. Wouldn’t that be nice?

Open source your application

Open sourcing your application can be great for several reasons. Perhaps you’ve just finished migrating your application to the latest version some framework. Not only can you blog about your experience, but you can share the code with others so that they can see exactly how you did it. This could potentially help others looking to migrate their applications to the same framework. You could get feedback from the community about something you could be doing better, and learn something new. People looking at your code could spot a bug, giving you the opportunity to fix it before it affects you (especially if you use your application). Some employers ask to see source code samples as part of the interview process. What sort of reaction do you think you would get if you immediately spit out several repositories that you owned on GitHub for the prospective employer to browse at their leisure? I’m not sure about you, but I’d be pretty impressed.

However, there is a potential drawback in releasing your code to the world. Ironically, it’s the same as one of the benefits. The world can see your code. This can be a bad thing if your code is full of bugs, or sloppy. So if you plan on releasing your code, take the extra care necessary to ensure that the code reflects your best effort. Your code, and you as a developer, will benefit from the extra TLC.

The next big thing

You never know which crazy, off the wall idea will turn into the next big thing. Who would of thought that there was a real need for an application that lets you tell the world what you’re doing right now. If your idea for a sandbox application turns into something with real business value, then you never know where it will end up. Large companies will often spend big bucks to buy great ideas. I’d imagine it would be pretty cool to be on the receiving end of one of those deals.

Summary

Creating a sandbox, and a sandbox application is something that every serious developer should do. If nothing more, it will give you a place to tinker with new technologies and grow as a developer. There is little to no cost to set it up, and your imagination is the only limit.

Moved Rails Apps to GitHub

I’ve spent some time over the past couple of months cleaning up the Rails apps I’ve written with the goal of making them available for download on this site. I wrapped that up last week with the release of Addressbook. However, I soon realized that making the code available on this site was not ideal, and it would be much better if I made the code available via some code hosting site, like Sourceforge or GitHub. This gives the projects a little more visibility, allows for easier contributions to the projects, and simply provides a better home for the code. So, I spent the past few days making Diners Club, Addressbook, and Karate Journal available on GitHub. Please check the project pages on this site for links to the GitHub repositories.

Choosing GitHub was fairly easy. I’ve been wanting to learn Git for a while now, GitHub has all of the features I needed (plus some nice-to-haves), and it seemed pretty straight forward to use. So far so good!

I did however have to do some additional cleanup before the move to GitHub. Previously, I had a bash script that I ran that would export the code from my local Subversion repository, and wipe out any user names, passwords, or other configuration that I didn’t want to publish with the code. The script would then tar and zip up the code, and push it to the site. This wouldn’t fly with GitHub, since everybody would be able to see the code in the repository. So, some work was needed to provide template config files (database.yml.template for example) for people to specify their own configuration, and I removed the original files from source control.

All things considered, I’m very happy with the move, and wish I’d done it sooner. I think from now on, I’ll be using GitHub from the start with new projects.

Merry Christmas everybody!