Building Atlanta Code Camp Website

I recently helped the Atlanta Code Camp effort by building them a new website. You can see it here:Atlanta Code Camp.  I am pretty proud of what I was able to accomplish in the scant number of hours I had to build it. It’s not done as we need to improve it when we have the speakers chosen and set up the schedule, but so far I am pretty happy with it.

How I Built It

I had a number of goals for the project:

  1. Create a better (e.g. usable) mobile experience across the whole site
  2. Enable maturation and reuse For every future Code Camp
  3. Enable Old Content to be reachable after future code camps occur
  4. Be able to build it in my spare time and not require a big team to get it working

My first thought was to start with a Mobile-First template and just build the site but as #4 was going to stymie that as PluralSight would really like me to finish my courses ;) So I started with a Bootstrap template (that I got from This provided a good basis for the shell of the website. Before I did real color skinning of the site, I needed to wait for our logo. Dennis Estanislao did an amazing job on the logo. With that I was able to use the color scheme to change the template to match the logo and overall theme. But that was just the HTML part of the story.

To deliver the site, I brought it into a ASP.NET MVC4 project. I did this for two major reasons:

  • I wanted to use Areas to segregate each each year but share common pieces like Layouts and Contact pages
  • I wanted to use WebAPI for my access to the event data

First, I created an Area for “2013” since this is the first year we’re using the new site. This is where I put this year’s pages (but the Layout is shared across the whole site). Currently any request gets forwarded to the /2013 area. In future years this will change to /2014 but the 2013 area will remain available so that links to talks and content will continue to work.

Next, I created pages for the different parts of the site. Each of these pages uses the main Layout for the whole site that is primarily the Bootstrap template and some common code (like menus). Since some of these pages are just markup (e.g. the home page), I didn’t add any code or complexity here. But for some of the pages (e.g. Speakers), we’ll need to be able to get data and show it. I made what might be a controversial decision here. Instead of simply using Razor and creating these pages, I decided to use AngularJS to build the pages on the client side. I did this for two reasons:

  • I wanted to have a good client to validate the API
  • I wanted the mobile experience to show the page as fast as possible, at the expense of bandwidth of retrieving the data.

For this reasons, most of the data-driven pages are asynchronous but I am fine with this. Be clear, I did this on purpose and not because I think moving away from Razor makes any sense. I like Razor but in this case I found using AngularJS was a clearer way of doing this…especially in the time frame. Most of our data is locally stored in a database but is imported from SharePoint which is being used for collaboration between the volunteers.

Next I decided to host this as an Azure Website. We’ve been hosting the site on computers in some of the volunteers’ homes and I wanted to not have to worry about the uptime of power going out at someone’s house. I like Azure Websites as a simple way to just push my code up and it works. The deployment via Visual Studio is simply and easy (I could have done this with Source Control integration but opted for a simpler approach – even though the source is hosted in a GitHub private repo).

Lastly, we needed some features that I thought we could farm out. First, we needed a simple way to accept speaker submissions. We had done this via email then typing into SharePoint but I thought that was tedious. Instead I created a Google Docs form to accept the data from the potential speakers. I tried going the Excel Survey route as they’ve recently added this as a SkyDrive feature but you could share the survey via link but not embed it. Google Docs’ Forms are a little more mature there so I grabbed what worked.  We also needed registration (though we haven’t opened it quite yet). For that we’re using EventBrite to do the actual registration. EventBrite is easy to setup and has a lot of mature options that would have sucked time out of my schedule to build so it’s an easy buy-in.

I think my total commitment so far to the site is about 15 hours of work. With the set of technologies I picked, this streamlined the time I really needed to build the site. I am trying to work easy not hard so schedule was a factor in some of the decisions. For those of you who like lists, here is a list of the technologies I used:

If you are interested in speaking at the Atlanta Code Camp, please visit:

Any questions about this, please leave a comment…