iA


Coolness I’ve Learned At The Chicago Tribune, Part Two

by Andy Boyle.

Chicago Tribune Weather

During my first week on the Chicago Tribune News Apps team the first project I started was to build a Chicago Tribune’s Weather page. This involved using the styles of a project that already lived on our touch site, which was designed by a different team. I had to take their look and feel, use the same API they were using and figure out a way to allow for users to search for different locations.

But before I did all of this, I had to get my machine set up. My boss pointed to my desk and a new Apple MacBook Pro, still in its box, so I would be setting everything up clean. Thankfully, Brian Boyer wrote up a great gist to get you started on a new machine that’s Python heavy. I walked through this, asking dumb questions of my coworkers — “What’s bash and zshrc?” — and got my machine set up.

Divvy was one of the cooler apps I learned about going through his walk-through. Get it. If you’re a fan of bending windows to your will, you’ll want it.

Prior to starting at on the TribApps team, I was primarily using Coda and the basic Terminal with bash. I’ve since moved on to using vim and iTerm2 with ohmyzsh. I use my boss’s janus settings. The learning curve was worth it, although I still use my mouse too much.

Now, back to the weather project. Had I stated on this project now, I would’ve built everything in Backbone.js. Instead, I was dumb (I was new!) and wrote what are basically templates and views that do a lot of jQuery appends after hitting the weather API. I had help from my coworkers when I got stuck (big ups to Ryan Nagle), which was often.

What was also nifty about this project is we’ve got the ability to write to “blurbs” in our content management system via its API, so I could program everything as HTML files in a git repo, thereby tracking my changes. If your content management system doesn’t have something like this, you should strongly push for it. Being able to push static content (JS/CSS/Images) to Amazon S3 and then pushing/updating the HTML straight into the CMS was great. We use Fabric for our automated deployment, and that’s what we use to push blurbs into our CMS.

Previously, I’ve worked in shops where you’d have to copy and paste your code into whatever proprietary CMS code-editing program, with no version control available other than Ctrl+Z in the text-editor you copied your code from. This new way was awesome.

Since launching the weather page, we’ve had to refactor the weather bad boy a few times to work in different browsers because of weird JavaScript issues. We also refactored it to do less API hits, to help out our pals on the team that built the weather API. This site is linked to from the homepage of ChicagoTribune.com, and as you may imagine, it gets some okay traffic. I’m pretty proud of this app, although I still wish I had built it using Backbone.js. Oh well, you live and you learn.

Biggest Takeaways

I now just want to build projects using an MVC JavaScript framework. Hitting an API and doing most of the work on the frontend instead of server-side is definitely the way things are going in web development. In my opinion, making a change to JavaScript or HTML is certainly much easier than having to change server side code that spits out HTML.

Previously, most of my high-traffic projects were written as bigger, more-complicated Django apps, hitting databases and spitting information out into templates (all backed up by Varnish, of course). This was the first time I built something dynamic that relied solely on front-end code. It was a bit scary, as that’s not a world I had previously traipsed around in much.

This project was also the most complicated JavaScript I’ve had to write in my career, and other than the occasional tweaks and one big fix to how we hit the API, it’s been humming along nicely. I also had my first real interaction with Underscore.js, which really helped me do for loops and parsing data. I also used the Underscore templating system a lot, which, again, would suggest I should’ve just used Backbone.js.

Thankfully, on my next big project, I got more Backbone exposure. I’ll be talking about that tomorrow.