Monthly Archives: June 2010

So I got up on a Saturday, pondering what routes and buses would need to be taken to go from Belltown to Fremont here in the Seattle area. Because I live here and have a transit oriented mind (I do write Transit Sleuth also…) I know which buses come where that would make a trip to Fremont real easy. Fortunately there is a site called onebusaway.org here in Seattle that helps one that likes to effectively use transit. The core Metro, Pierce County, Sound Transit, and other sites are of minimal use in comparison. They can give you basic routing but other than that there isn’t a lot of other information for the hard core transit user.

So this Saturday morning I stumbled into an idea that wouldn’t be too expensive to implement within the cloud (either Azure or AWS). Here’s my initial idea without any research done except to know that somewhere, somehow, Metro, Sound Transit, and the other authorities in the Seattle area offer some type of data and GPS location feeds.

Transit & Logistics Cloud Idea

The connectivity shown in the diagram above is nice and all, but what exactly do I want for a front end? That’s the next point, what is needed is a truly flexible dashboard. One needs to be able to actually query against locations and find multiple options to the various places they’re trying to travel to. For instance, the trip from Belltown to Fremont isn’t just one bus. I could easily get the 17, 30, 26, or 28. But there isn’t an easy way to identify and track all of the nearby bus stop locations that those buses travel by on their route. That’s where a dashboard of statuses and location information would come into play.

The idea would be able to track multiple bus stops in a particular location for various buses going in all directions. This seems like a feasible idea. The extension of that would be to get the stops within X distance from a particular location, possibly derived from an iPhone or some such. I’d like to use this on an RIA for the Windows 7 Series, Blackberry, and iPhone – which I assume would be a boon for anyone that uses the Metro, Sound Transit, or surrounding services.

I have collected the following information for this prospective project.

The onebusaway.org Open Source Project that currently does bus tracking and other transit related information has some great research done already, which may be useful.

King County Metro has a page of Q & A for developers. The GTFS Data for Metro is available too.

A really good discovery I found was the UW Research. This site has all sorts of web services information related to traffic and transit. In addition there is specific .NET examples and such. Always nice to see the examples in the code or tech stack that I intend to use.

Anti-Test Driven Development Arguments and Myths

June 18, 2010

Unknown Code Ramblings

2 Comments

Ok, I have run into the anti-TDD arguments on and off over the years. Generally it comes from two primary sources. The person who doesn’t want to do TDD no matter what, nor test, nor learn anything about the latest and greatest tech, they simply want left in their corner of the universe to code whatever they are coding until they drop dead. Then there is the other individual who is a decent developer, but just has honest hesitations about the style.

The developer who has honest hesitations I can understand, can talk to, and can usually at least get a “Well, that sounds reasonable, but I’m still not sure” response. Which is much better than the alternative of disregarding TDD outright. The hope, is that this individual can at least try out TDD and see if it would work for them.

Even with the more open minded developer it is still difficult to put TDD into practice. Why? That’s simple, TDD is hard and forces a developer to step back into the basics and really think the problem through first. Most developers (at least currently, maybe it’ll change) have a very “just attack the problem with code” type of response. Often the way to break down problems is taught in computer science 101 level classes, but after that is often lost in all the cramming for math, algorithms, and other such material. But the core fundamental idea of thinking the problem through clearly still needs to be broached. TDD puts that idea forefront in the process by making a developer write the test to verify the problem statement first.

With all this stated, there are a few myths that I’d like to bust. These myths are often what cause the first person to cringe away cowardly in their corner of the universe, and causes these hesitations in the second more open minded developer. After busting these myths I’d hope more of the open minded developers can use the power and thinking that TDD encourages. As for the first corner cringing coder, they’re a dying breed and I wouldn’t bet on their recovery.

The Myths

MYTH: But I can’t test every single thing that is written, so TDD just isn’t for me. The reality is, you can’t test every single thing and you shouldn’t. You should stick to the logic, business process, and other parts of the code. Don’t worry about the configuration, individual database nodes, or other arbitrary or configuration based bits. The idea is to make you think through the problem spaces and architecture needed to work through those problem spaces. So TDD is still something you should try, but don’t try to test every single line of code. Focus first just getting through the logical, flowing, business related bits of the code you are writing with tests first. This will get you appropriately experienced with TDD.
MYTH: You can’t test against boundaries, that becomes an integration test, so why even mock/stub/fake if I’m not testing the real framework/parts/features? Again, why worry about testing parts that you know or are not responsible for? Don’t test the integration parts. There is a reason QA exists, and defining and testing boundaries is what QA does great. But you still need to test and confirm that your code works against those. Mocking or stubbing against that gives you the confidence that your code logic will work against these integration points and also provides you a basis in which to work off of. If you write the tests first, you also know you’ve thought through these integration points to a fairly thorough level.

Do you have anymore myths that should be burst? Please feel free to toss a myth or two to burst in the comments, I’d love to hear others input on the matter.

Kata Kickin’ Some Prime Numbers

June 16, 2010

Code Katas, How-to

1 Comment

Lately I have been interviewing people for prospective positions in the company I work for. In the various questions that I and others pose during these interviews one popped up as a prospective Kata. The challenge is really quit simple, “Write a method that would take a int and check if it is a prime number.” The following snippet is what I came up with.

protected bool IsPrime(int theNumber) 
{ 
    bool isPrime = true;

    int theHalf = theNumber / 2;

    for (int i = 2; i < theHalf; i++) 
    { 
        var remainder = theNumber % i; 
        if (remainder == 0) 
        { 
            isPrime = false; 
            break; 
        } 
    }

    return isPrime; 
}

The next idea that popped up was to find X prime number in order. As the answer a question like, “What is the 6th prime number?” I came up with the following method for that.

protected int GetPrimeByPosition(int position) 
{ 
    int counter = 1; 
    int thePosition = 0; 
    while (true) 
    { 
        if(IsPrime(counter)) 
        { 
            if(thePosition == position) 
                return counter; 
            thePosition++; 
        }

        counter++; 
    } 
}

In the end the Kata is a simple 2 step problem.

Write a method that determines if an int is a prime number. i.e. “Is 5 a prime number?”
Write a method that determines the prime number based on X order. i.e. “What is the 3rd prime number?”

So based on these two steps, what would be some other steps to add to this Kata? What are some other good interview questions that are short and simple for prospective employees to code through?

Respectable Behavior

June 11, 2010

Unknown Code Ramblings

2 Comments

I’ve always pondered good interactions from other developers. What makes it easy, or not so easy, to work with another developer? Here’s a few of my thoughts on these engineering types.

The Uber Ego Engineer. Just be curious and interested in the work if you are or aren’t really well versed in something. The last thing any engineer likes is the know it all engineer. Fortunately I’ve not run into too many of these in my career.

The Energy Engineer. I like to work with other engineers, and other people in general, that have an energy and look forward to their day. Sometimes however an engineer can overdo the energy. The excessive bouncing about, ADHD style approaches to software engineering can be very stressful on those around you. So to those energy based coders, just settle into a Prozac just for a bit. Thanks!

The the Doldrums Engineer. This engineer that just can’t find a single thing right in the world. It’s always sunnier somewhere else, the code isn’t right, the build builds but shouldn’t type is one of the most frustrating engineers to work with. I can do it, and usually can find a way or two to snap them out of the doldrums, but it takes a huge effort.

That’s it from me for the moment. What engineers do you know of that are good cohorts (or bad)?