Following my basic thoughts behind the basic app setup, now I had to build the damn thing. On Thursday I didn’t have my laptop with me, so I did everything from noon to six on a Windows computer, using Notepad++, FileZilla and PuTTY (which I discuss using a bit in this post.)
First, I opened up a file and started writing the models file. I was able to copy a lot of the code from recruits.gatorsports.com and reuse it. I thought of the basic data we would get: Location, Name, Date of Birth, Age, Photo, Cause of Death, Link to a Story and a bio. When thinking of the data I would be able to collect, I thought of a few of the sites that’ve been built to track members of the armed forces who’ve died in war, most notably the project Matt Wynn and Ben Vankat built at the Omaha World-Herald.
Look familiar to our finished app? Yeah. Because it’s a great idea on how to structure the info. Props to them, and thanks for the idea, fellas.
So I wrote out the models in about half an hour and then sketched out a quick wireframe for the pages on a few sheets of paper. I’ll take photos and post them tomorrow, but the basic idea I had my coworker Yinnette Olivo turned into what you see now. The main page would have a simple nav bar and then photos that would brighten and have a name pop up when you rolled over them. Then the individual pages would list the collected data I had in the models.
The designer got out of a meeting, I showed her my wireframes. She laughed at how crappy my drawing is and then she got to work while I dealt with the views. With my projects, I always like them to have a focal point. With a project I built called MyLawmaker, it was the search bar where you entered your address. With this project, it would be the photos.
After handing off my ideas to her, it led to me realizing a problem. We had two websites that would need this — gadsdentimes.com and tuscaloosanews.com. Because I’m not super awesome with Django, I had never used the sites framework that Django has. And because I’m stubborn, I wasn’t about to learn on the fly. So on the strong suggestion from Ryan Pitts, I wrote a bit in each view that looks for the sitename, and then includes the right header or footer based on it. Snazzy, and totally against the Don’t Repeat Yourself principal.
But as Pitts said, this was more important. So repeat myself a lot I did. And it worked, so I don’t care as much.
By about this time, I had the models, views and admin up. I added some fake data and made sure the photos would upload to Amazon S3, which they did. I discuss how to do that in your settings.py file in this post. I had set up everything so far on my live server (yup, no production server, because I’m dumb), including setting up the database (which I discuss in this post, as well), realizing on the fly I had to reconfigure some of the urls.py in my Recruits project, and then change the settings on Varnish.
I was stupid and had originally set up Varnish in a way that wasn’t exactly conducive to adding new projects. So, don’t do that. Always set up Varnish and your production server to be able to add new projects quickly, people.
By this time, my coworker had the basic templates made on her end. She left work and I fixed a few odds and ends.
We normally do a projectname.sitename.com type of structure with our projects, as opposed to sitename.com/projectname. Our DNS stuff for these two papers is controlled by our CMS provider. So before I left work I put in a high priority ticket to get our DNS settings to point stormvictims.gadsdentimes.com and stormvictins.tuscaloosanews.com to the Varnish server. This was finished by the time I got home.
I ate a quick dinner and thought more about the design, setting up the urls.py better and getting the thing ready for implementation, which I will discuss in my next post along with my final thoughts.