Developer Journal #1, Ping Collector Part 1

Preface

Over the 8 months I spent developing Ping Collector on the side, there was definitely a fair amount of missteps, in contrast to the things that I did right. The Developer Journal series I hope to do for each one of my products will give insight to the obstacles I faced and how I worked around them.

To put this in context, I am a relatively junior developer. At 23, I have only been in the software industry for about a year and a half now.

What I did Wrong

Failure to research the Framework/Platform I was using thoroughly enough before programming on it.

Google App Engine (GAE),overall, is a great platform. It's cloud-focused and really takes care of the usual nuisances a developer would have to implement himself. This benefit comes with some disadvantages however.

I ended up using the Spring framework as it was something I was familiar with. The MVC library is nice and easy to use, and the inversion of control was great as well. The issue was is that Ping Collector, with the exception of the future graphing service, is only 5% web-page based (this would be the Forgotten Password page). The other 95% is simply service calls which work with the client. I could of used a lighter framework to work my controllers and would of benefited due to the fact that GAE doesn't work like a normal application server and has to rebuild all beans whenever an instance "wakes".

The above caused more issues once I tried to implement a "gateway" which would block users requests to the server if they contacted it too frequently for certain actions. I had implemented this in Aspects/Advice, but it caused slowness in the initialization of Spring in GAE (at one point it was 60 seconds) , and was also rather hard to debug. I ended up simply calling the gateway method in every controller method after having worked on the Spring Aspect Oriented Programming implementation for weeks. This was one of the biggest slowdowns and frustrations of the development process.

Marketing to potential users.

This non-technical obstacle was another misstep in the journey. My experience with seeing the lack of satisfaction and poor performance with Windstream, the pilot ISP for Ping Collector, from people other than my family was limited to DSLReports.com. The forum for Windstream was full of disgruntled customers that I wanted to help.

I failed to look around their website only to realize that they had a product that did measure internet latency of it's users. One difference was that they were measuring from the outside in, instead of the inside out. This meant that there were less options for location-based latency measurements (Ping Collector, with a client update, can gather data from any ping-able host around the world). The biggest difference was that they were charging for it.

When I tried to post Ping Collector on that forum, it was removed from a moderator rather quickly. They insisted that they were protecting their users' information (ironically, they collect the same amount of information as what Ping Collector would). I assume they didn't want the added competition if they could help it and were just tossing me an excuse, in which case I don't blame them for protecting their business interests.

This lack of foresight left me with a smaller than intended user pool for release.

Developing for an environment that I didn't have direct access to.

This was one of the more minor issues that I ran into. Because Ping Collector's first phase was to only accept users who had Windstream as an Internet Service Provider, I had to block any other attempts of use from other ISPs. I had moved out of my mother's house about 7 months before I started development on Ping Collector. I was on Comcast now, which meant that testing in an "actual user's environment" was hard to do.

I didn't have a remote backend into my mother's PC at home (not to mention she would be using it most of the time). This meant that I would have to send alpha/beta releases to friends and family and monitor the server side to see if things went right, or have them check the logs generated by the client, which was tedious as hell.