Hack Western: "Weather or Not"
A web application that prompts users to take money-saving actions based on real-time weather updates.
Links
Tools
HTML5, CSS3, JavaScript, JQuery/Zepto, Node.js, Zerver, Git, Heroku, Yahoo Weather API, Twitter Bootstrap, Arduino
Context
This was a project worked on for Hack Western 2015. It was created over a time period of 36 hours, of which I slept <5 hours. It was great fun. All of us were hackathon newbies. For most of us, myself included, this was our first ever hackathon.
Role
On this team, I mainly focused on working with both the frontend and backend of the web-side of our project. Being the most experienced at web development on our team, it was my time to push myself to develop my skills even further, while also acting as a mentor for the rest of my team to the best of my ability. Fortunately, I did get a chance work on the Arduino side of things at various points throughout the event as well.
Inspiration
Leading up to the hackathon, we brainstormed a couple of ideas. We had just about settled on building a better alarm clock prior to coming to the event, but as soon as we got there, we were filled with newfound adrenaline. We decided that we wanted to be more ambitious for a rookie team and so made plans to make an elaborate self-driving robot that would bring things to various locations in a room. I'm being fully serious.
This again changed after the opening ceremony.
Of the themes presented, we decided that we were going to work towards the one based around saving people the most money. We brainstormed again. This process took up a good chunk of time, but it was time well spent. After going through idea after idea and mocking up some very low-fidelity prototypes, we decided that we would build something that would monitor the weather conditions around a user’s home and alert them when the conditions changed so that they could take action to save money. These actions included turning on or off heating and the air conditioning, as well as closing windows and doors.
I would like to give an honourable mention to the idea that we almost went with: a smart cash register that would automatically sort and dispense optimal amounts of change (i.e. minimize the number of coins returned). It would have been cool to build this one out, especially the sorting mechanism.
Process
Planning Revisited
Having chosen our idea, we now had to decide what tools we were going to use, and how we were going to split up the work to maximize efficiency. We broke the team up into two halves; two of us would work on the web part of our project, while the other two would focus on the Arduino component. In theory, this made sense to us. However, as soon as we started working, we immediately realized that we did not know how to start working. To the mentors!
Node.js
Our first challenge came in the form of selecting the tools to use for our backend. After discussing it with a few very helpful and friendly mentors, it was decided that we would use Node.js. Although I do feel relatively confident in Javascript, Node.js was something that I could never really wrap my head around in the past when I tried to learn it on my own. But I thought to myself, “What better environment to learn Node than at a hackathon with endless support available?”
Coincidentally, we also happened to stumble across a Node.js framework that would communicate with an Arduino. Node seemed to be the perfect solution for us.
Branching Off
We decided that we would collectively learn Node so that our solution would be as integrated as possible from the start. However, after a couple hours of limited success, the Arduino team decided that it would be a more optimal use of time for them to start programming the native Arduino language. Although we were able to successfully control the Arduino with Node, we were not sure how to move forward and integrate it with our web components.
With this decision made, our team split back off into its two branches once more. With my partner and I focused on Node, we quickly realized that we had no idea what we were doing.
After a some consultations with the mentors, we realized that we should be using Express for Node. However, after working with it for a bit, we talked to the mentors once more, at which point we made the decision to switch over to Zerver. Zerver for Node met exactly the requirements that we needed, and it also felt a lot more approachable from a new learner’s perspective.
API Access
When I think about how many things we were trying to do with this project, it really amazes me that we were able to put together anything working at all. Not only was this our first time using Node, but it was also our first time trying to call APIs. But the challenge was great fun.
Our first goal with Node was to find a way to call a weather API, parse it, and spit it out into an HTML table.
Halfway through the night, after hacking together a way to call a particular API, the data being sent back started to inexplicably return default values. Panicked, we started asking other teams if they were experiencing the same thing. Sure enough, the API was down.
Without thought, we decided to switch to the Yahoo Weather API. All of our code had to be reworked to accommodate the API switch. This was a major slowdown for us, as it took us what seemed like forever to properly get the API calls working again.
The Website
Being comfortable with web development, I took a short 3 hours sprint and just worked through everything front end. I decided to use Twitter Bootstrap as my base (mainly for the grid and buttons), and strip out all of the unnecessary classes to make the website as lightweight as possible.
We were using Zepto at first by recommendation of a mentor, but I decided to switch back to JQuery to avoid any potential quirks that would not be worth the time to investigate.
Node.js was used to make the API calls and JQuery was used to format the data and output it into a nice, responsive table (although we did not use HTML tables, but rather grid blocks). Notification alerts based on weather updates were implemented using a modified version of the built in Bootstrap buttons and alerts (HTML + JS). Beyond that, the rest of the website was created using the standard set of HTML5, CSS3, and JQuery.
Arduino Woes
Our website was up and running and the Arduino was responding to commands via serial. Switch cases were set in place to control the different sensors and system intensities (ex. heating and cooling levels) and appliances, but we could not figure out how to send the processed data from the weather API from our server to the Arduino.
Both sides of our project were working independently of each other and were set up to communicate with each other, but unfortunately the communication aspect was the missing link to our success.
Outcome
You can visit the website that I worked on via the link above. Unfortunately, I did not record any footage of the Arduino side of our project, but I can assure you that it was indeed working and responded to the inputs that were sent to it via the computer. Again, we were unable to successfully get the Arduino to communicate with our server, but our proof of concept was otherwise functional. All of the necessary switch cases set up to process the data that would have been sent over from our server had we been able to establish the connection.
How it Works
The goal of our project was to save people money by providing an effortless way for them to control their home from through the web. The Yahoo Weather API would be called periodically to pull the latest weather information for a specific location. This data would then be interpreted and displayed on the screen. Along with displaying raw data, we would process the data and provide the user with contextually appropriate options that they could act on should they choose. For example, if the weather was above 15°C, a button would show up and ask the user if they wished to turn on their air conditioning to a certain intensity. Had we been able to get the server to communicate with our Arduino, the Arduino would then have turned on a PWM LED to a specific intensity to represent this change of state. Since communication was not established, we had to manually set the flag for the Arduino to run the program that would control the LED’s intensity. Of course, there were also manual overrides set in place to let the user have full control over all of their systems.
Reflection
The hackathon experience is definitely something that I would encourage everyone to try out at some point in their life. Granted, it was super exhausting and my sleep schedule was an absolute wreck for the following week, but beyond that, it was so worth it! Not only did I get to meet and work with some awesome people, but I also learned so much in such a short span of time.
Although I think that I could have benefitted from using tools that I was already familiar with rather than try to chart unfamiliar territory and learn an entirely new set of skills, the challenge was great fun. While we definitely could have built something more polished if we used languages we had previous experience with, the fact that we were still able to throw something together that worked (for the most part), despite having essentially zero experience with our tools, was a great feeling. It just goes to show how far dedication and determination can go. It also helped that we had some amazing mentors as well.
The more I work with different languages and tools, the less scary programming becomes to me. While I would still consider myself still relatively new to the coding space, I picking up new languages and practices continues to feel easier and easier. It might be because I have been fortunate enough to have have had some pretty awesome resources and mentors to help me along the way, but nevertheless I am glad that I am always learning new things.
Getting to watch other teams compete and build, what were in my mind, much more extravagant and elegant things in the same space of time that our team had was not only extremely motivating, but also a reality check for me. No matter how far I think that I have gotten in coding, no matter the amount of experience I have, there will always be room for me to grow. But by no means am I discouraged by this; part of the reason why I love programming so much is that there will always be new things to learn.
For me, I learn best by doing. I can only learn so much from reading documentation. The hackathon atmosphere was definitely conducive to learning by doing; the environment was fast-paced, energetic, and inspiring. Being surrounded by so many motivated people who share similar interests and ideas with me was very encouraging, and working with both them, and the extremely knowledgeable mentors was definitely an experience that I will never forget.