OpenParking

Now live in the App Store

Posted by Davey Witter on November 27, 2018



Initial Thought


On a Monday I was driving to work. Dependent on the office I have to be in, the parking can be a real pain in the ass.

In the city of Rotterdam parking is just way to expensive. But there are two free parkings which I cross.

Both parkings are next to the subway station. One is 20 minutes by subway to the office and the other one 8 minutes. Driving to the latter one is only 5 more minutes. So as you can guess, I'd rather park at the second parking.

The only downside of the second one is that I am not the only one who wants to park there.
So every day I have to be in Rotterdam, I always ask myself the following question:
Am I gonna risk it or not?

In this case, if there is no space left I either have to drive back, which makes me lose a lot of time, or I have to park in one of the expensive parkings.

One morning I thought to myself, why is there no application which gives a fast indication on the amount of parking spaces left? Why can't I just check real quick if it is worth it to drive on?

So it begins


So when I arrived home in the evening I started looking for open data sets. I did the same thing for OpenBridges, and the idea is almost the same. So I started searching and searching. Until I finally found an open data set which has that specific park and ride. Because I had to be in Rotterdam the next week, I knew I had to create a MVP (Minimal Viable Product) in a really short time.

I found the api which contains the json data with the status of the park and rides. Now I just have to pull the data from there.

Okay so now I had to figure out what to do with this data. How to use it in the application. I started drawing some architectural images.

After some consideration I decided to write a python application which calls the api every x seconds. This means the data will be accurate to the api data. After I pulled the data from the api, the application transforms the data to make it usable and store it in my own database.

Run, run, run, and...... crash


When the python script was finished, the rest api was set up it was time to upload the script to a server to make it run.

Okay don't judge me, but because the server for OpenBridges only used 10% of it's resources I thought it would be a good idea to run OpenParking there to. How many resources could it use? Well wrong. Never do this! Always make sure you either do one of the following three things:
  1. TEST your code
  2. TEST your code
  3. TEST your code

However, I thought, it is just a small MVP for just myself now. I can always fix errors later on. What could go wrong?

Well you can maybe guess it. I uploaded it to the server. Had 90% of the resources left when it started. And the following day it crashed. And not just the OpenParking application. But the whole server including the OpenBridges script. This made OpenBridges unavailable for a whole day. And believe me, this is the worst that can happen.

But this actually was a good lessons learned for me. I knew that I had to test my code before uploading it to any server. What actually went wrong? Well I used the RAM to store a dictionary which contained the parking garages. Instead of updating an existing key-value pair I created a new one and added it to the dictionary. It was just a small stupid mistake which lead to the memory getting full (appending 40 items every 1 second to the dictionary makes the script end up with 144.000 items in the dictionary every hour).

But this was a very good lessons learned for me. I ordered two more droplets on digital ocean. One for testing purposes and one to run only OpenParking after it is finished.

Conclusion


In the end I learned that you should always test your code in every way possible. Besides never test a new application on a production environment but always create a separate environment to test out the code.

I hope you all learn something from my mistake and never make the same mistake. I hope you enjoyed reading this blog and please leave some feedback.
Share on Facebook Share on twitter


0 Comment


No Comments


Comment