When rebuilding the HackerYou site during our two-month break between cohorts, we had a few goals in mind. We wanted to build a site that was functional, easy to navigate, but also beautiful and full of information. The moment we said congratulations to the fall 2014 grads, we kicked off development on the new site. It was fun to switch from teaching to production and tackle a full (and ambitious!) web project again, from beginning to end. Major thanks are due to studio function, our ongoing design partner. They also teach our part-time design class. Vivian and Frank always seem to know how to push the limits of design and development exactly the right amount, resulting in a project that responds to our needs and desires but is also leading edge. We think it's important for our students and the community to see us pushing the limits design-wise and technically, just like we do every day in the classroom. Let's dive in and talk about how we built the brand-new hackeryou.com!
CMS
We used WordPress. Why? Because it rules. I love Rails. Brenna is a JS person. We considered creating a CMS from scratch in either Rails or Node, but why not use what's existing? The previous HackerYou site was built on WordPress and contained all of our content. Plus, our team was trained and the system was already there. All we had to do was focus on the presentational experience and a couple Post Types while the Admin experience was taken care of. Brilliant. 
In order to ease the creation of the post types that we needed, we utilized Custom Post Type UI so we weren't muddled in the creation and logic of these post types. To create the data fields needed for each post type, we leveraged Advanced Custom Fields to design an admin experience that allows anyone to jump in and maintain the site. One custom field helped us greatly - the relationship field. This tool allowed us to associate models together easily through Wordpress. We could pull in content from another data model and write logic based on it. So for those who still aren't convinced about Wordpress as a production CMS, you're just not using it to its full potential. 
JS
When we first received the mockups, we were stumped as to how best to approach the calendars on the home and full-time bootcamp pages, an important feature of our site for prospective students. We considered a few existing graphing tools, but none offered us the flexibility that D3 did. Using a Wordpress plugin that outputted JSON, Brenna created a beautiful experience with data. 
Now, I know I keep saying "Why reinvent the wheel?", but I totally indulged in writing my own JS for features. This was mainly due to the custom nature of many UI elements, but also because JS is so much fun to write. Examples include the accordions on the bootcamp page, and the syllabus content. Instead of modifying an existing plugin, in this case it was simply easier to create a native experience from scratch. We did use plugins, though. Why complicate things? The alumni page (hire them, by the way) uses Isotope for the layout and sorting, the sliders use bxSlider and the nice page scrolling is achieved through trusty Smooth Scroll.
Automation
For automation, we went with Grunt. The system we needed was already in place in a Gruntfile so we went with it instead of losing a full day working on automating our needs within another tool. Some of the tasks we utilized were Sass, uglify, autoprefixer and imagemin tools for optimization. Having two people working on a Wordpress build at once is tricky when you both have your own local versions to work from, so we used Grunt and Deployments to pull from the remote dev Wordpress MySQL database. Our process was to update content on the remote dev site and update our local databases via Deployments. No conflicts, and incredibly handy. If we're pulling a database, though, we need all the files we uploaded in Wordpress and the plugins as well. Hello rsync. We created one task that combined Deployments and rysnc, to keep our local copies in sync.
CSS
Ok, this is the biggie. Some of the coolest things I've ever done in my career were done on this site simply with CSS. Our wonderful designers, studio function, gave us the most amazing dev package I've ever seen complete with AI files, jpg scroll demos and basic typographic styles in CSS. Honestly, get in touch with them. I've never had such an awesome dev package from a designer. If you already have a design team or are one wondering how best to prepare design mockups for development, download their pdf guide. At HackerYou, we teach Sass because we believe it's accessible to anyone coming from the basics of CSS. For the HackerYou site, we used the scss format because it's clear, concise and powerful. The scss was my baby, there is a world of mixins and functions built in to help us achieve styles quickly and reduce repetition.
Images
One of the trickier parts with any build is the amount of work that needs to go into maintenance on an ongoing basis. Training is often needed for those maintaining the site content and PSD templates need to be provided to ensure certain stylistic components are included. For example, for this site, certain feature and header images were designed to have a gradient on them. This gradient changes on each photo. It would require multiple templates per section of the site, so it was out of the question. We thought, "maybe we could have a transparent PNG with the gradient included..." but that would be ridiculous on load. Image and transparent PNG, no way. 
The option we settled on was a before element and position: absolute. For each element that contained an image with a gradient, we used a before element that had its background element set to multiple linear-gradients. With some positioning, we could make it so that no matter what image was uploaded, the gradient would be there, and not take forever to load.
// HTML
// SCSS
.element {
position: relative;
background: url(image.jpg);
&:before {
content: '';
position: absolute;
z-index: 1;
top: 0;
left: 0;
width: 100%;
height: 100%;
background: -webkit-linear-gradient(258deg, rgba(71,189,182,0.3), rgba(71,189,182,0) 25%), linear-gradient(-122deg, rgba(71,189,182,0.24), rgba(71,189,182,0) 90%), linear-gradient(-69deg, rgba(0,0,0,0.7), rgba(71,189,182,0) 70%);
}
}
Where this worked out great was the sliders. An image gets uploaded through the CMS and the gradient is applied dynamically through CSS. 
Typography
To help with loading in fonts, a mixin was created to quickly access the font and its many formats.
// mixins.scss
@mixin importfont($font-family, $font-filename, $font-weight : normal, $font-style :normal, $font-stretch : normal) {
@font-face {
font-family: '#{$font-family}';
src: url('#{$font-filename}.eot');
src: url('#{$font-filename}.eot?#iefix') format('embedded-opentype'),
url('#{$font-filename}.woff') format('woff'),
url('#{$font-filename}.ttf') format('truetype'),
url('#{$font-filename}.svg#{$font-family}') format('svg');
font-weight: $font-weight;
font-style: $font-style;
font-stretch: $font-stretch;
}
}
// variables.scss
@include importfont('NimbusSans-Regular', 'assets/styles/fonts/nimbussansnovusdot-reg-webfont', 300);
$nimbus: 'NimbusSans-Regular', sans-serif;
Media Queries
To help with responsive, we leveraged the fantastic breakpoints mixin from Juice which helped us define screen sizes quickly and easily within our selectors as nested rules.
// breakpoints mixin
.element {
width: 50%;
float: left;
display: inline-block;
@include bp(medium) {
width: 100%;
}
}
Grid Systems
When it comes to layout, we are big believers in grid systems. But we also hate presentational classes. No one wants `col-md-6 col-xs-12` scattered throughout their page. This becomes unmaintainable as the site grows, so we went with a non-presentational system called Semantic GS. This system simply requires us to set up some basic variables for the grid layout: number of columns, the gutter and column width, and the total width of the grid. To define how wide an element is, we simply call the include in our scss and give it a number that relates to the number of columns.
// semantic.gs
.element {
@include column(6);
}
// with the breakpoints mixin
.element {
@include column(8);
@include bp(medium) {
@include column(12);
}
}
Organization
To reduce conflicts and keep our code modular and organized, we split up our styles into separate files. All individual page templates had a separate scss created and only shared common styles. Our mixins, variables, typography and icons all lived within their own files. Upon compilation, they were created into one minified file through imports and the main.scss file.
- styles
- fonts // held web and icon fonts
- plugins // generic vendor css
- regions
- _about.scss
- _blog.scss
- _bootcamp.scss
- _directory.scss
- _employers.scss
- _home.scss
- _parttime.scss
- _animations.scss
- _base.css // shared layout styles
- _breakpoints.scss // held mixins for breakpoints
- _calendar.scss // D3 Styles
- _grid.scss // Semantic GS mixins
- _icons.scss // Icon font
- _mixins.scss
- _normalize.scss
- _typography.scss
- _variables.scss
- main.scss
That's it.
Everything we did for this site is within reach for our students. Having moved to teaching full-time, we do not get to build products at this scale all the time anymore, so this was a pleasure to build. This was a team effort and the site would not have been possible without my partner in crime, Brenna O'Brien, who upon launching this site is making the move to the development team of TED Talks. Truly going to miss teaching with her, but she's blowing up minds on a global scale now. A huge thank you to Heather Payne for first of all, creating HackerYou, but for her help in getting the site out the door. Not only is Heather the CEO of a coding school, but she can also code, and worked with us to make changes right up to launch. As well, thanks to Eunice Bae for helping keep our heads on straight and maintaining content for us. We hope that the site inspires people to follow their dreams and maybe even take one of our programs. Anyways, I gotta get back to teaching. I hope see to see you at the lab soon. - Drew