Working in QA, my fellow co-op students began to see a problem in their day-to-day work. Due to all of the testing that is required, Polar has mass amounts of smartphone and tablet devices of all different manufacturers, models, and operating system versions. The system for developers to check out a device to test with has simply been a binder and a pencil since the company started. Developers are forced to first walk over to the storage area to check if the device they require is there and if not they have to go through the binder to find out who had the device previously. Certainly this is something that could be improved upon.
Enter Bindr - The Brilliant INventory for Device Resources. The QA co-ops showed me sketches of a web-based tool that they wanted to create which would house all devices and would feature the ability to easily check in and out devices and contact others that have the device. It would also have an intuitive search bar allowing users to look for specific operating system versions, manufacturers or device models. Initially there was also talk of checking in and out devices using QR code but this was quickly scrapped for the sake of time.
After taking a look at the sketches, we decided it was certainly do-able and I quickly got to work on the backend. We decided that a Django-based web application would be best given my past experience with the framework. I created several database models to store all the devices and additional information such as the IMEI, serial number etc. I also wrote a quick parsing script to take the current Excel spreadsheet that contained all of the devices and convert it to appropriate fixtures to load into the database.

After presenting our working prototype, the feedback was really quite encouraging. It was something that I was proud to say was accomplished in 24 hours. My manager mentioned to me that with a little work and feature additions it would be something that could be put into production soon. If the application is going to be used, I think I will clean up some of the code first. The main problem with a 24-hour stretch is that you can't always make the best design decisions. Nonetheless, I certainly had an awesome time at this Hack Day and can't wait for the next one!