Battle of the Traffic Apps

Today I listened to the latest podcast from All Tech Considered, found on NPR. Robert Siegel led his team through a real life test of some of the latest traffic apps to see just how useful they are. The goal was to get from Robert's home to his office at NPR as quickly as possible. The apps used were INRIX, WAZE (which is Google owned), Apple Maps, and Robert's own Volkswagen navigation system. They did the test during rush hour traffic to see if the apps could correctly navigate them through heavy traffic. The apps estimated the total time in a range from 23-30 minutes and then Robert and his colleagues were off.

Testing multiple traffic apps at once proves to be an interesting decision right off the bat, as they could not even agree with how he should leave the driveway. The apps pointed them to turn left at a light where they ended up sitting in traffic through two full signal changes. Additionally Google warned them of a serious accident that turned out to not exist. While Robert admits in the podcast that this is not the most scientific test, he says it is also not the most convincing test either. In the end it takes them a little over 30 minutes to arrive at their office.


The second half of the podcast Robert speaks to Ray Resendes from the Virginia Tech Transportation Institute. They make the same trek Robert made previously with his team and discuss the technology used in tracking commute date. Sensors from the road and from service trucks driving the road provide the information for the apps themselves. They discuss the accuracy of the technology, given that sensors are not accurate enough to differentiate between multiple lanes, and how the tracking will get better when cars are the ones providing data as well.


While traffic apps sound like they could be very useful, it's not something I have ever used myself, or even considered using before listening to this podcast. Based off of the available information it seems like traffic apps have some hills to climb before they will be as accurate as people would want. Will people have a problem with their car constantly broadcasting GPS data? For my view, I don't think I would really mind if it meant I could not have to deal with traffic. But then I live in Milwaukee now, where traffic feels like a breeze even at its worst compared to the Seattle freeways I had to deal with for so long. I wouldn't go out of my way to use a constantly updating traffic map, but if it came with my car I would certainly appreciate it, assuming it can do the job well.

More Fun with File I/O

For our last OOP project of the semester we got to play with File I/O again. This time our goal was to make an address book. Instead of working with a console application we were to work with forms to give it a GUI. The picture below is how mine turned out: 

You're missing out on the welcome screen but trust me it is amazing (if you like console font text, of which there is plenty). The program reads a list of contacts and their various information from a text file as soon as you load it up and uses StreamReader again to store the information so that the program can actually use it. Similar try and catch logic is in play as it was in my Mario Trivia Game from last week, just in case something goes wrong with the text file (for example, if it was not there or named the wrong thing). After clicking the start button the user is shown the window above (minus the code underneath it). The Contacts ComboBox (the drop down menu) is empty at first, but clicking on the arrow gives the user the last names of all the contacts in alphabetical order. Selecting the last name of the contact then brings up all the information, such as what you see for Susie Susanson of San Francisco (I'm mostly sure she is not real, and if she is I hope she goes elsewhere for her email soon).


Mostly all of the GUI stuff was pretty easy, we have done it before when we made a Farmer Game a few weeks ago (blog posting of that as a "Blast from the past": forthcoming!) and while I was fumbling around at first the knowledge of how to set things up came back fast. It's especially handy to have your old programs to look at whenever something stumps you a bit. The other thing that is super handy to have is the MSDN library:

The code above was found by my tutor and myself as I wanted to be able to sort by last name alphabetically without screwing up the index. It turned out there was a method already built to do this, aptly named Sort. It is there to sort Lists for you and was a really great find. There have been many times in both semesters where I have gone to the MSDN library to see how things work, either on my own or with a helpful reminder from my friend. I did run into one bug this project where I accidentally had a couple blank lines in my text file, and StreamReader found them and the whole program got very angry. But some breakpoint debugging led me to the answer, though I had help on this one too, I could see that there was extra incomplete information, but could not fathom the source on my own. It is something I will be very aware of in the future, and it worked out well enough in the present as I got a really good grade on the program. All that is left for the semester is compiling everything I have made in to my existing portfolio from last semester and the final. After that, it's Advanced OOP and I'm sure it will be a blast!

File I/O Fun with Mario

For my latest project in Intermediate Object-Oriented Programming, we got to make a trivia game. The project taught me a few new things, including how to make the game fun for my kids:

I learned how to read a text file line by line, and how to setup error checking via try and catch. The following code is used to try and load the trivia questions when launching the game:

The majority of this is example code from my teacher that she lets us use to understand new concepts, but it's directly from my program. Streamreader is the first new thing to me, you give it a path and it reads through the text file line by line. When it starts the try if the path is set correctly and the file exists, it begins storing everything into questions, answers, etc. This particular program is limited to first reading a question, then a list of answers, a letter representing the correct answer choice, and an explanation if the user got the question wrong. If for some reason there's an error, that's when catch comes into play. In this case it's looking for exception errors, and if it finds one it will give you the error message plus the custom message in red pointing you to where in the code an error popped up. It's really handy for things where you know an error could occur, such as if someone got a hold of this program but without the text file holding all the data.

But easily the most fun part of this program was sharing it with my sons. Sure, it's only a quick 5 question quiz but having them next to me yelling out answers was really fun. However, as the quiz questions increase in difficulty and this one really stumped them:

Do you know the answer? My boys haven't been exposed to Super Mario 3 and they're missing out on one of my favorite Mario items ever.