Well, we’ve already pivoted on our app idea, but now I’m really beginning to be excited about it. We talked for a bit about the direction we expected the app to go, but realized that the market is flooded with every type of weather app already. What did we want to create that would bring a unique touch?

After some spitballing, brainstorming, paradigm shifting, and all those other buzzwords, we settled on the idea of weather comparisons. You can look at temperatures in one city and compare them to another, but it’s difficult to find a place that does that comparison for you based on historical data. With that, FeelsLike was born.

The premise for FeelsLike is this: you’re thinking of visiting or moving to a new city, but you’ve never been there. Wikipedia talks about the temperature, you can look at charts and graphs, but all you get are numbers on a line. How does that city compare directly to your own? Do you need a jacket in April, or sunscreen? We set out to create this app that will compare two cities based on historical data and give you a plain English answer.

The first thing we needed to do was get the data. Well, the REAL first thing to do was to FIND the data. We tried several weather APIs, but decided Weather Underground and Forecast.io would be the best options, since they provide lots of historical data and the specific values that we need. We agreed that five years of data from five different cities would be enough to get off the ground and provide a decent demo. This turned out to be a serious undertaking, however.

Each API request only provides one day of historical data, so we will need to make 9,125 requests to fully seed our database (5 cities x 5 years x 365 days). The trouble is, Weather Underground only allows 500 API requests per API key per day, so each of the four members of our team created a Dev account at Weather Underground so we could cycle through each team member’s API key. After we got everything set up, it was just a matter of babysitting the database to make sure all of the weather objects were being created properly. This will end up taking a few days, but should give us everything we need with plenty of time to spare.

While watching the database, I started building routes to the back-end data. We’re still planning on a fully decoupled app, so I volunteered to provide all of the data in easy-to-find JSON chunks.

On the front-end, the team quickly realized that React.js will be very difficult to learn in such a short time, so there will be a solid decision made over the weekend about either buckling down with React, checking out Node/Ember, or going back to Rails. We also have to figure out D3 during all of this, so there are a lot of hurdles to get over.

Until Monday, I’m Edwin Unger and I’m a junior developer.