I want to tell you a story of a couple of problems that we’ve tried to solve several times with technology, when all we needed was a couple dollars worth of office supplies.

The Lunch Party

I’ve been working with Nick Pettit since 2007, before we came to Carsonified and Treehouse. In our last job we had a group of friends we would regularly go out to lunch with from the office. After a while, the decision of where to go became too difficult. “We went there yesterday!”, “I don’t really like X!”, and “I don’t know, where do you want to go?” became the common choices.

Then, I was writing in Rails, so I thought, “This is an easy problem to solve. Create a Restaurant and Person model, set up a voting system, input local eateries, Bam! Problem solved.” I had spare time in the office and this could easily be classified as learning, or experience building. I ended up making two or three prototypes over the 3 years I worked there.

The problem is, nobody really used it. Maybe it was a usability problem, but I think the process of using a web app to plan lunch just is not natural. Going out to lunch was a very social activity, and voting on a computer screen doesn’t really mesh well with that.

The “Lunch App” became a running joke between me and Nick. It was a more sarcastic version of “There’s an app for that.” An idea that seems easy, but just doesn’t really work. Fortunately, before I spent the rest of my life trying to plan lunch in the office, the problem was solved for me. Nick and I quit. Then we joined Carsonified to built Treehouse (then Think Vitamin Membership).

There were now just 3 people in the company, and one of them was on another continent. Lunch was just agreeing between 2 people what to do, a web app is overkill. Then we hired Michael. Then Jon. And Amit, now there are 19 people working in the Orlando office. We scaled for a while, we just had to get 3 or 4 or 5 people to agree on lunch. It became stressful around 7. Suddenly the whole office can’t eat at the same place. Organizing lunch became a problem again.

For a few weeks we handled it in our campfire chat room. Someone would suggest a lunch destination, some people would be in, some not so much, an alternative choice would surface. It became hard to track who goes where. I began to think about the “Lunch App” again. Then I came to my senses.

I grabbed a sharpie and a pack of sticky notes, wrote everybody’s name and all of the restaurants, each on their own note. I stuck them on the wall and this happened.

It was amazing. Everybody could see the options, see who wanted to go where and make a good decision. We split into 3 reasonable groups and had excellent lunches, all the way around. This took 2 minutes to make.

There were bugs. The sticky notes were cheap. It was a bit boring, but that was fixed by going to the store and buying some extra-sticky sticky notes. I also picked up some stickers and other decorations so people could customize their stickies.

Version 2 was deployed in a few minutes, now with MySpace levels of “tasteful” customization.

Video Workflow

Lunch planning was not the end of our sticky note problem solving. Managing a video production studio is tough. We spent a lot of time at 2 video pros and 3 teachers. It was pretty manageable, but now there are 9 people on the video team, and 7 teachers. Now planning is critical. We have one screencasting room, and one video studio. With so many people figuring out who is using what resource when, and who is working with who when became our biggest headache.

At Treehouse, we use a lot of web apps. We have switched project management apps more times thatn I can count. Codebase, Basecamp, Github, Remember the Milk, Trello, Team Gannt, Asana, and probably a few others that escape my memory. It felt like we were switching project management apps every week. None of these apps were bad, but they all left something to be desired for our needs.

Then one day the sticky notes began to spread. Michael began utilizing other walls for organizing project workflow and scheduling

So, Sticky Notes Solve All Problems?

No, my point is not that we should all use sticky notes for everything. Obviously this has disadvantages vs a technical solution, but for lunch, we don’t need to have our remote employees involved, for obvious reasons.

The moral of the story is that it’s very easy to get lost in our tools. As web designers and developers, we love the web, we love our tools. It’s easy to get into the mindset of solving every problem with what you know, when the obvious solution just isn’t obvious to you anymore.

Next time you set out to solve a problem with software, step back and think, can I solve this problem without it?

• Faster development mode – Rails now only reloads the classes you’ve actually changed between requests in development mode.
• Explain queries – In development mode, you can automatically show the explain of certain queries by calling .explain at the end of your query. The results will go in your log.
• Active Record Store – Active Record now has a built in way to do key/value storage right from your models. No plug-ins or external gems required!

You can also check out the change log of all of the fixes and changes, both big and small. Enjoy!

We’ve added a simple Groups Dashboard that allows you to see …

1. Group Activity: Who’s watching videos and unlocking Badges
2. Ranking in your Group, based on Badge unlocks

More info …

1. Group pricing is 25% off normal prices, which allows people with large groups to save a bit of money.
2. You only need 2+ people to sign up.
3. If you’re already a Member, you can’t be brought into a Group. We’ll address this in v2 of Groups. However, please contact Support if you need help: help@teamtreehouse.com
4. Sign up here

We have big plans for adding more features to Groups, so stay tuned. This is just an MVP (minimum viable product) release, so we could get it out to you all and see what you think :)

General Design Refresh

Tyson, our new Designer has also done a site-wide refresh on the app. It’s even easier to use now and super fast. Tyson lead the Digg Design Team for awhile so he knows all about optimizing for speed :)

This video is from Treehouse, a high-quality video training site with hundreds of short videos on topics like …

• Accessibility
• CSS3
• Aesthetic Foundations
• Django
• HTML
• CSS
• HTML5
• iOS Development
• JavaScript
• jQuery
• NoSQL
• PHP
• Responsive Web Design
• Ruby
• Ruby on Rails
• UX
• Version Control
• WordPress Theme Design

New videos are added regularly, so it’s a great way to stay up-to-date on all the latest technology and methods. Browse the entire library of videos.

We had so much fun celebrating with our previous giveaway, that we thought we would do another one.If you tweet to @treehouse the name of your favorite web app, we’ll randomly pick 10 winners to receive a "Mike the Frog" Nerd Merit Badge! Here’s a picture of what they look like:

This is super helpful to collect, test and experiment with your collection of semantic HTML & CSS patterns. For beginners it can be a great way to begin to understand the relationship between markup and style. No matter which audience you fall into, it is a handy tool for improving speed and productivity.

Also make sure to take notice of the Pears website itself, which is beautifully designed and responsive.

Thanks Dan, for making our lives more enjoyable with Dribbble and easier with Pears. :)

If you caught Ryan’s article last week, he told you about our brand new, not to be missed Vegas event – Future Insights Live! We’ve combined the Future of Web Apps, Design and Mobile into one massive five day event all geared toward you! Whether you’re a Web Designer, Developer or Entrepreneur there will be something for everyone.

We are launching a brand new scheduling app within the next couple of weeks which will list full details of the huge conference schedule and give you an overall feel for the event. So with that in mind, we have decided to extend our Early Birds (saving you $200) until 24th Feb! That way you can see EXACTLY what you’re paying for.

We’ll be launching the full schedule by the end of the week, so please check it out and join us for our biggest event yet!

It’s difficult to test aesthetics, but with tools like Spur App you can make sure that your design looks good for people with color blindness and other mild vision impairments. You can also make sure that your design has enough contrast and feels "balanced" on both sides.

Check My Colours is another web-based tool that can help out. Simply type in your live URL, and you’ll get a listing of all the areas where your color contrast can be improved. It’s a bit more technical than simply looking at a black and white image, but it’s good for more detailed analysis, especially on a complex web application that might have lots of dynamic views.

At Carsonified Towers, we’re all getting super excited for May, when The Future of Web Design hits London for another three days of learning and inspiration. As ever, we kick off the show with four full-day workshops – each lead by a totally inspirational industry leader. From 9am am to 5pm, we’ll be rolling up our sleeves and knuckling down for a serious hit of web savvy. Numbers are capped at 40 for each workshop, ensuring a great learning environment.

This year’s chosen workshop topics are already proving popular. First up, we’ve got the unstoppable force of web awesomeness that is Paul Boag. Director of Headscape, Paul will be leading a crash course in Running A Successful Web Design Business: ”We like to think that being a successful independent web designer is about creating great websites. Its not. Running your own business is about a lot more than having the right professional skills. ”

After wowing the crowds as a Rising Star back in 2011, Steve Fisher has rapidly become one of our most popular speakers. He’ll be joining us again in London to lead his Rock Solid UX Deliverables workshop: “No longer something that has to always be hugely complex and costly, we’ll cover the back-to-basics approach to UX design in this workshop and how to practically dispatch a rock solid responsive web design UX deliverables package.” 

Next up, creator of the uber popular Coach to 5K app, Josh Clark will be crossing the Atlantic to deliver his Teaching Touch workshop – a sell out success at FOWD NYC last year: “The workshop presents nitty-gritty ‘rule of thumb’ design techniques that together form a framework for crafting finger-friendly interface metaphors, affordances, and gestures for a new generation of mobile apps that inform and delight.”

Last but not least, longtime Carsonified favourites, the Web Standardistas will be joining the fun, to teach their Good Ideas Grow On Paper workshop: “Armed with some fundamental design principles and an abundance of tools – which naturally includes the Standardistas’ ‘Bag of Awesome™’ (containing a veritable cornucopia of material) – we show the aspiring analogue designer a range of methods for breaking out of the stranglehold of the often clichéd digital world.”

This video is from Treehouse, a high-quality video training site with hundreds of short videos on topics like …

• Accessibility
• CSS3
• Aesthetic Foundations
• Django
• HTML
• CSS
• HTML5
• iOS Development
• JavaScript
• jQuery
• NoSQL
• PHP
• Responsive Web Design
• Ruby
• Ruby on Rails
• UX
• Version Control
• WordPress Theme Design

New videos are added regularly, so it’s a great way to stay up-to-date on all the latest technology and methods. Browse the entire library of videos.

Why Use Version Control?

You might be wondering why you should use version control, even for a site you’ll never collaborate with anyone on. This is a valid question. I can best illustrate the answer with a scenario you may have encountered in the past. Let’s say you’re in the middle of making a site and want to try something crazy with the css. Maybe you want to do a bit of an experiment and make everything strange shades of yellow and red. You don’t know if you’re going to keep the work when you finish it. Since it’s an experiment, it would probably be a good idea to not mess up your working version of the site.

At this point, you might be thinking of creating a copy of the site and making your changes on the copy. Maybe you’re sure that you’re going to use this work and you’re going to crank through. Maybe it doesn’t work out, though. Wouldn’t it be nice if you could take a snapshot of your site now, do your experiment, and not have to worry about whether you mess things up? That’s exactly what version control is for!

Step 1: Install and Configure Git

In order to start working with git, though, we need to install it. Git is fairly easy to install. If you’re using Windows, GitHub has an excellent set up guide to get git installed on Windows. They also have great guides for Mac OS X and linux. If you don’t already have git installed, follow those guides and come on back here.

Once you have git installed, you have to tell it who you are. This is done using the config command. Open Terminal and type in the following:

$ git config --global user.name "Jason Seifer"
$ git config --global user.email "jason@teamtreehouse.com"

Step 2: Initialize a repository

We’re going to initialize a git repository now. A repository is just a directory with one or more files we want to track the changes of, in this case our web site. Open up terminal (or command prompt on Windows) and change to the directory containing the site you want to put in to git. You do that with the cd command. I’m going to put my web site in the Sites/think_vitamin directory.

[~] $ cd Sites/think_vitamin
[~/Sites/think_vitamin] $

Once you’re in there, type the following:

[~/Sites/think_vitamin] $ git init

Assuming you have correctly installed git, you should see the following:

  Initialized empty Git repository in /Users/jason/Sites/think_vitamin/.git/

This is git telling you that thinks are working and that the path it gave you is now a repository. If you don’t see that output, go back to step 1 and verify that everything was correctly installed.

Step 3: Add Your Files

Now that we have initialized our git repository, we have to tell git what files we want to add to the repository. In order to do this, we use the add command. The add command takes either a single file or a path. The add command takes the changes you’ve made and adds them to something in git called the staging area. The staging area is kind of like a waiting room for git. It lets you tell git what changes you’re going to add to the main index.

Since we are already in the directory with our web site, we’ll tell it to add the path of the current directory:

[~/Sites/think_vitamin] $ git add .

At this point, you won’t see any output. My example is just an index.html file. In order to see what git is about to stage, you can use the status command:

[~/Sites/think_vitamin master]$ git status
 
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#	new file:   index.html
#

The first line of the output says “On branch master“. In git, a branch is just a pointer to something called a commit (explained in the next section). Since this is our first commit, git lets us know that on the second line of output where it says Initial commit. Next, git says there are changes to be committed. My index.html file is there since it’s the only thing I have in the directory right now. This is good!

Step 4: Commit Your Changes

A commit in git is a pointer to a series of changes that you have told git you want to track with the add command. When you commit your changes, git writes them to the index. This is git’s way of saying “this is what the repository looked like at this point in time.” So let’s commit our changes:

[~/Sites/think_vitamin]$ git commit -m "Initial commit"
[master (root-commit) 542d5fa] Initial commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 index.html

Here we use the commit command to tell git to commit our changes to the repository. The -m argument told git that we want to give the commit a message. My message here was “Initial commit” because this was the first commit to the repository. As you make changes, you can be much more descriptive. This is helpful when working on larger teams. Time Pope has a great article on writing good commit messages if you’d like any pointers.

The important thing about commits is that, once you have committed changes, you can always go back to how your repository was at the point in time of that commit. How cool is that? That means that you’re now free to make horrible changes to your site. Wnat to see how Comic Sans looks for all the headers? Go for it! You can always go back.

Step 5: Make some changes

Now that things are committed, you can feel free to make some changes to your code. In my example web page, I made changes to the header of the page. Now we can run git status again to see what happened:

[~/Sites/think_vitamin]$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#	modified:   index.html
#
no changes added to commit (use "git add" and/or "git commit -a")

Now we’ll add the file we just changed:

[~/Sites/think_vitamin]$ git add index.html
1.9.3 [~/Sites/think_vitamin]$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#	modified:   index.html
#

Finally, we’ll commit the change:

[~/Sites/think_vitamin]$ git commit -m "Modify home page header"
[master bc8251b] Modify home page header
 1 files changed, 1 insertions(+), 1 deletions(-)

Great! We just made our first two commits. Our co-workers will love us for writing a descriptive message along with the second commit, too, although they might also still be mad for taking the last cup of coffee.

Step 6: Make a branch

Remember earlier when we were talking about making experimental changes that you may want to keep? That’ what branches are for! Branches let you easily separate your work. You can have two branches going at the same time with different work. Branches are great for experimentation with something that you’re not sure you’re going to keep.

Let’s say we wanted to change the font on all headers to Comic Sans. You’re not sure how this is going to look (bad) but your client really wants you to give it a try anyway. Let’s create a branch to do that just in case we want to switch back. In git terms, we call this process creating a branch. We do that by checking out the branch and passing a flag to git saying that we want to create it:

[~/Sites/think_vitamin]$ git checkout -b comic_sans
Switched to a new branch 'comic_sans'

Now that we’re on our comic_sans branch, we are free to make changes and commit them. This won’t affect anything on our master branch until later. Let’s make our changes:

[~/Sites/think_vitamin]$ git status
# On branch comic_sans
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#	modified:   index.html
#
no changes added to commit (use "git add" and/or "git commit -a")

Git also let’s us see what changed in between what we’re about to stage with the diff command:

[~/Sites/think_vitamin]$ git diff
diff --git a/index.html b/index.html
index 159202e..266d025 100644
--- a/index.html
+++ b/index.html
@@ -1 +1 @@
-

Hello world

+

Hello world

We can also add and commit the change with one command by using the -a flag when committing:

[~/Sites/think_vitamin]$ git commit -am "Make header font comic sans"
[comic_sans 94af8b2] Make header font comic sans
 1 files changed, 1 insertions(+), 1 deletions(-)

Now we’ve committed to the comic_sans branch. Sweet!

Step 7: Merge your changes

Our client is now happy with the header changes. Our experimental branch we created now needs the changes to make their way back in to our main branch. We do this through a process called merging. What we want to do is merge or changes from the comic_sans branch back in to the master branch. First, we have to go to the branch we want to merge to. We do that by checking out. This time, we won’t use the -b parameter since we’re not creating the branch:

[~/Sites/think_vitamin]$ git checkout master
Switched to branch 'master'

Now we use the merge command to get our changes from the comic_sans branch in to master:

[~/Sites/think_vitamin]$ git merge comic_sans
Updating bc8251b..94af8b2
Fast-forward
 index.html |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Boom! Now we have all of our changes in to git. If we want to see what these changes were, we can use th log command to get a nice display of times, dates, and authors:

[~/Sites/think_vitamin]$ git log
commit 94af8b2e976ba11755f7483bc761ea2b9a747e0a
Author: Jason Seifer 
Date:   Wed Feb 1 15:07:45 2012 -0500
 
    Make header font comic sans
 
commit bc8251b338b8ac4451888e1da482708df6264529
Author: Jason Seifer 
Date:   Wed Feb 1 10:16:41 2012 -0500
 
    Modify home page header
 
commit 542d5fab4c86d29a125a78b8a89366f70bdfaa9d
Author: Jason Seifer 
Date:   Wed Feb 1 10:10:01 2012 -0500
 
    Initial commit

Well Done!

In this article we learned how to install git, create a repository, change branches, and commit changes to our code. In the next article in this series, we’ll learn about removing files, going back to different commits, and pushing up to GitHub and working with other people. Stay tuned!

The ongoing drawback to Google Fonts has been the smaller selection compared to other font services, but that’s rapidly changing. Even better, an editorialized web page called “Beautiful Web Type” has popped up that showcases the best fonts that Google has to offer. Loving this!

View the Tutorial
Demo Page

You can read all about Elliot’s ideas on his website. He explain everything is great detail. If you read his post you will find it hard to disagree. Fixed designs are becoming harder and harder to justify.

We’ve just confirmed that industry leaders Kevin Rose and Jason Calacanis will be speaking at Future Insights Live in Vegas on April 30 – May 4th!

Future Insights Live is our new show that combines Future of Web Apps, Future of Web Design and Future of Mobile into one huge 5-day, 5-track, 1,500 person conference. It’s going to be epic and you won’t want to miss it.

Early bird pricing (save $200) is almost over, so grab your ticket today.

This video is from Treehouse, a high-quality video training site with hundreds of short videos on topics like …

• Accessibility
• CSS3
• Aesthetic Foundations
• Django
• HTML
• CSS
• HTML5
• iOS Development
• JavaScript
• jQuery
• NoSQL
• PHP
• Responsive Web Design
• Ruby
• Ruby on Rails
• UX
• Version Control
• WordPress Theme Design

New videos are added regularly, so it’s a great way to stay up-to-date on all the latest technology and methods. Browse the entire library of videos.

You can also follow @twbootstrap on Twitter.

Here’s some of what’s new in this release:

• Responsive layout (!) with media queries.
• New 12 column grid (the old one was 16 columns).
• Stacked forms are the default.
• Split button dropdowns.
• New Pills.
• Navigation lists.
• New Dropdowns.
• Tabbles in any direction.
• New JavaScript plugins.

What better way to start off the new year than a fresh new Dribbble portfolio?  If you are a designer with minimal coding experience and want to display your Dribbble work in all browser sizes, you have come to the right place.  We will be creating a HTML5 one page portfolio which pulls your Dribbble information and is responsive in all browsers.  This little project will be presented in two parts.

Part 1 (this post):

HTML/CSS/jQuery set up.

Part 2 (coming soon):

Convert HTML to PHP and use the Dribbble API to pull your data. Plus IE fixes.

The File Structure

Let’s dig right in and start off with our file structure.  On your desktop create a folder labeled: ‘Dribble-Portfolio’.  In that folder create the following files:

• folder labeled ‘css’
• style.css
• folder labeled ‘images’
• logo.png
• connet.jpg
• me.png
• sample.jpg
• index.html
• folder labeled ‘scripts’
• jquery.js
• fitText.js

It should look a little something like this:

*to download the .js and image files simply select the links above and save them to the appropriate file structure.

The HTML

Now that we have all of our assets and files lets begin with the HTML. Below is the proper code for your ‘index.html’ file.

<!DOCTYPE html>
 
<html>
 
<head>
 
	<!--Viewport-->
	<meta name="viewport" content="width=device-width; initial-scale=1; maximum-scale=1">
 
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
 
	<title>Dribbble Portfolio</title>
 
  <!--Google fonts-->
  <link href='http://fonts.googleapis.com/css?family=Open+Sans' rel='stylesheet' type='text/css'>
  <link href='http://fonts.googleapis.com/css?family=Raleway:100' rel='stylesheet' type='text/css'>
 
  <!--Main Stylesheet-->
  <link rel="stylesheet" type="text/css" href="css/style.css" />
 
</head>
 
<body>
 
	<header>
 
  	<h1 id="logo"><a href="#"><img src="images/logo.png" alt="My Logo" /></a></h1>
 
    <nav>
 
    	<ul class="menu">
 
        <li><a href="#" class="email"></a></li>
        <li><a href="#" class="dribbble"></a></li>
        <li><a href="#" class="twitter"></a></li>
        <li><a href="#" class="facebook"></a></li>
        <li><a href="#" class="linkd"></a></li>
 
      </ul>
 
    </nav>
 
  </header>
  <!--end header-->
 
  <section class="half">
 
      <img src="images/me.jpg" class="main-image" alt="This is Me" />
 
  </section>
  <!--end main image-->
 
  <section class="half">
 
  	<h2 class="tagline">Check Out My Super Radical One Page Responsive Portfolio Which Pulls My Dribble 'Shots'. Get Gnarly!</h2>
 
  </section>
  <!--end tagline-->
 
  <div class="clear"></div>
 
  <section>
 
			<h1>Latest Work</h1>
 
 
			<div id="container">
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
			</div>
 
	</section>
  <!--end dribble content-->
 
  <div class="clear"></div>
 
  <footer>All RIghts Reserved <a href="#">www.website.com</a></footer>
  <!--end footer-->
 
 
 
</body>
 
</html>

As you can see the code is fairly simple. We have a basic HTML5 markup with some ‘viewport’ settings at the top. The ‘viewport’ settings tell devices such as iPhones to display at the devices width and scale.

 
<!DOCTYPE html>
 
<html>
 
<head>
 
	<!--Viewport-->
	<meta name="viewport" content="width=device-width; initial-scale=1; maximum-scale=1">
 
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
 
	<title>Dribbble Portfolio</title>

Also the ‘head’ is reaching out and grabbing some Google font stylesheets as well as our ‘style.css’ file in our ‘css’ folder. We will get to this file in our next step.

 
  <!--Google fonts-->
  <link href='http://fonts.googleapis.com/css?family=Open+Sans' rel='stylesheet' type='text/css'>
  <link href='http://fonts.googleapis.com/css?family=Raleway:100' rel='stylesheet' type='text/css'>
 
  <!--Main Stylesheet-->
  <link rel="stylesheet" type="text/css" href="css/style.css" />
 
</head>

As we get into the body of the file we have four main sections(header, section(half), section(dribbble) and footer).

The header contains two elements. Element one is the logo, feel free to change it. It’s located in the images folder, labeled ‘logo.png’(200x80px). Element two is our social network icons which we won’t see until we add the css styles. For now we are going to link to hash tags. In part two of this tutorial we will be pulling in the correct data via Dribbble.

<header>
 
  	<h1 id="logo"><a href="#"><img src="images/logo.png" alt="My Logo" /></a></h1>
 
    <nav>
 
    	<ul class="menu">
 
        <li><a href="#" class="email"></a></li>
        <li><a href="#" class="dribbble"></a></li>
        <li><a href="#" class="twitter"></a></li>
        <li><a href="#" class="facebook"></a></li>
        <li><a href="#" class="linkd"></a></li>
 
      </ul>
 
    </nav>
 
  </header>
  <!--end header-->

The next section, section(half) contains our ‘me.jpg’ image and our tagline which are located directly below the header. Feel free to swap out the image(me.jpg) and tagline copy to better personalize your portfolio. The image currently being pulled in is 800x600px as it is scalable to the screen size.

 
<section class="half">
 
      <img src="images/me.jpg" class="main-image" alt="This is Me" />
 
  </section>
  <!--end main image-->
 
  <section class="half">
 
  	<h2 class="tagline">Check Out My Super Radical One Page Responsive Portfolio Which Pulls My Dribble 'Shots'. Get Gnarly!</h2>
 
  </section>
  <!--end tagline-->
 
  <div class="clear"></div>

Our next section is section(dribble) which is going to pull our most recent Dribbble ‘shot’ titles and ‘shot’ images. For now we are going to use dummy content. In part two we will be running a loop to pull the latest projects with the all mighty power of php. You will also be able to choose how many projects you would like to display. For now we are going show twelve ‘shot’ examples.

<section>
 
			<h1>Latest Work</h1>
 
 
			<div id="container">
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
          <a class="box" href="#">
            	<h3>Title of the Work</h3>
            	<img src="images/sample.jpg" alt="Work Title" class="pic"/>
          </a>
 
 
			</div>
 
	</section>
  <!--end dribble content-->

The last section is the footer area. This is for any links or Copy Right text you wish to display or link out to.

<footer>All RIghts Reserved <a href="#">www.website.com</a></footer>
  <!--end footer-->

The CSS

Now that we have inserted all of our HTML data, let’s add our styles to the page. Simply copy the CSS code below and input it into the style.css file. Here is the CSS code:

/* DRIBBBLE PORTFOLIO SITE - 2012 */
 
/*RESET*/
html,body,div,span,applet,object,iframe,#logo,h2,h3,h4,h5,h6,p,blockquote,pre,a,abbr,acronym,address,big,cite,code,del,dfn,em,img,ins,kbd,q,s,samp,small,strike,strong,sub,sup,tt,var,b,u,i,center,dl,dt,dd,ol,ul,li,fieldset,form,label,legend,table,caption,tbody,tfoot,thead,tr,th,td,article,aside,canvas,details,embed,figure,figcaption,footer,header,hgroup,menu,nav,output,ruby,section,summary,time,mark,audio,video{outline:none;border:0;font-family:inherit;font-size:100%;margin:0;padding:0;vertical-align:baseline}article,aside,details,figcaption,figure,footer,header,hgroup,menu,nav,section{display:block}body{line-height:1}ol,ul{list-style:none}blockquote,q{quotes:none}blockquote:before,blockquote:after,q:before,q:after{content:none}table{border-collapse:collapse;border-spacing:0}
 
/*MAIN*/
body { background:#dce877; margin:0 auto; padding:0 5%; font-family:Open Sans, Arial, Helvetica, sans-serif; width:90%; font-size:13px; line-height:21px; color:#616634; }
header, footer { float:left; width:100%; }
section { float:left; }
ul { list-style:none; margin:0; padding:0; float:left; }
a { color:#616634; text-decoration:none; transition:all linear .5s; -webkit-transition:all linear .5s; -moz-transition:all linear .5s; cursor:pointer; }
a:hover { color:#111; opacity:1; }
h1, h2, h3 { font-weight:normal; float:left; }
h1 { margin:20px 0; }
h2 { font-size:30px; line-height:40px; }
h3 { font-size:14px; line-height:40px; }
p { font-size:12px; }
.full { width:96%; margin:0; padding:2%; float:left; position:relative; }
.half { width:46%; margin:0; padding:2%; float:left; position:relative; }
.clear { clear:both; }
 
/*HEADER*/
header { position:relative; width:100%; border-bottom:5px solid #bcc664; margin:0 0 20px; }
#logo { float:left; margin:20px 0 0; transition:all linear .5s; -webkit-transition:all linear .5s; -moz-transition:all linear .5s; }
 
	/*CONNECT*/
	nav { float:right; transition:all linear .5s; -webkit-transition:all linear .5s; -moz-transition:all linear .5s; }
	.menu { list-style:none; margin:15px 0; }
	.menu li { display:inline; }
	.menu li a { width:32px; height:31px; background:url(../images/connect.png) no-repeat; opacity:.5; float:left; display:block; margin:30px 5px; }
	.menu li a:hover { opacity:1; }
	.dribbble { background-position:0 0; }
	.linkd { background-position:-38px 0 !important; }
	.twitter { background-position:-78px 0 !important; }
	.facebook { background-position:-118px 0 !important; }
	.email { background-position:-158px 0 !important; }
 
/*SECTION(HALF)*/
.main-image { width:100%; }
.tagline { line-height:140%; color:#616634; font-family:Raleway; font-weight:normal; }
 
/*SECTION(DRIBBBLE)*/
#container { -moz-column-count:4; column-count:4; -webkit-column-count:4; -webkit-column-gap:10px; -moz-column-gap:10px; column-gap:10px; float:left; width:100%; }
.box { background:#BCC664; padding:5%; opacity:.75; display:inline-block; margin-bottom:10px; border-bottom:2px solid #616634; border-radius:2px 2px 10px 10px; width:90%; }
.pic { width:100%; float:left; clear:both; }
 
/*FOOTER*/
footer { border-top:5px solid #bcc664; margin-top:20px; padding:20px 0; font-size:12px;}
 
 
/*MEDIA QUERIES*/
@media screen and (max-width:960px ) {
 
	#container { -moz-column-count:3; column-count:3; -webkit-column-count:3; }
 
}
 
@media screen and (max-width: 768px) {
 
	.half { width:95%; }
	.menu li a { margin-right:1px; }
	#container { -moz-column-count:2; -webkit-column-count:2; column-count:2; }	
}
 
@media screen and (max-width: 479px) {
 
	#logo { margin:0 0 0 48px; }
	nav { float:left; margin:0 0 0 50px; }
	.menu { margin:0; }
	#container { -moz-column-count:1; -webkit-column-count:1; column-count:1; }
 
}

After we save our ‘style.css’ file and refresh our browser, we have a very clean portfolio layout that responds well to the browser size.

When you view the stylesheet css code you will see ‘%’ used a lot on the width attributes. The page is styled with a responsive fluid layout in mind. If you have any questions about responsive web sites, please check out ‘Responsive Web Design Foundations’ over at Treehouse.

As of now we have a fully functional static HTML5 page which has been tested in the latest versions of Firefox, Chrome and Safari. Because we are using HTML5 and CSS3 capabilities we will not be testing in IE at the moment. Once we finish up part 2 of the tutorial we will set up separate IE files to compensate for it’s lack of functionality with HTML5 and CSS3.

The JavaScript

Lastly we are going to add a little javascript to our page allowing our ‘tagline’ text to scale with browser size. Insert this snippet of code directly below the footer.

<!--js files-->
	<script src="scripts/jquery.js"></script>
	<script src="scripts/fitText.js"></script>
 
	<!--initiate fit text-->
	<script>
 
  	 $(document).ready(function() {
 
  		 /*FitText*/
  		 $(".tagline").fitText(1.1, { minFontSize: '20px', maxFontSize: '200px' });
 
  	 });
 
	</script>

This snippet simply links up to our ‘jquery’ and ‘fitText’ files we set in our scripts folder earlier. Then it initiates the ‘fitText’ function and gives it some variables. Feel free to change the max-font-size and min-font-size as your ‘tagline’ will be different.

Wrapping Up

Now lets review what we have just done.

• We have set up our HTML
• Added our CSS styles
• Inserted a little javascript

Congratulations you have successfully set up a static responsive one page portfolio.

Source Files
Demo Site

Still to Come(Part 2)

In the final portion of this tutorial we will be using Dribbble API to load in our user data and ‘shots’, as well as IE 8 and up fixes. In the meantime if you would like to know more about HTML5 and CSS3 please check out Treehouse, or contact me at mat@teamtreehouse.com. As always, Get Gnarly and Design your Life!

Role Those Credits:

• Dribbble
• jQuery
• Fit Text
• Treehouse

Just when you thought scrolling your web page was getting boring. Scrollorama has stepped the scroll game up with this remarkable jQuery Plugin. Scrollorama allows you to manipulate text when you scroll the page. You can do everything from Transitions to Zoom to Parallax. Check out the Scrollorama site to view some great examples and the plugin’s documentation.

This Plugin is great for landing pages and highly interactive web applications. Like CSS3 transitions, use your animations sparingly.

We’ve just released our new Treehouse Student plan and it’s only $9 per month! It’s the equivalent to our Gold plan, which is $49 per month, so you’re saving a massive 82%. Anyone who attends a school, college or university is eligible. After you sign up, we’ll ask you to provide proof of your student program.

Benefits include:

1. Unlimited access to our Video Course Library. 450+ videos, more added each week on topics like CSS3, HTML5, JavaScript, iOS, Photoshop and more. All videos downloadable for offline viewing. Unlock Badges to prove your knowledge.
2. Complete Project Videos show you how to create real-world sites and apps, from start to finish. All example files are downloadable.
3. 114 Conference Videos from Future of Web Design and Future of Web Apps ($545 value)
4. Closed Captioning on all videos for non-English speakers and the deaf.

If you’d like to get Treehouse in to your entire school, college or university, please contact Chris and he’ll be happy to help!

There’s a money-back guarantee, and you aren’t tied in to a contract. Sign up today.

I remember the weight of separation vividly. I remember writing custom JavaScript to replace the <a> tag’s target attribute because it added behavior to HTML. I remember dropping the <font> tag from my arsenal of tools, something I don’t regret.

In principle, the rule of separation was good. It helped us explain the best practice and implementation of HTML, CSS and JavaScript. It spun the web toward a brighter future. Separation vanquished the <font> tags, spacer gifs and inline JavaScript that polluted the web for years. In the old web structure, presentation and behavior lived in one layer but the principle of separation divided them.

The Path

The principle of separation lead web standards into victory during the first browser wars. Separation did not do this by eliminating proprietary standards, but by defining the “path” for new standards like CSS and XHTML. Through this victory browser makers work together now, for the most part. Browsers prefix proprietary CSS and push together for new technologies such as HTML5.

However, separation was an old idea that lived hand in hand with XHTML 2. The idea was that structure, presentation and behavior should be at all times pure. Separation like XHTML 2 has seen its day. Just look at the current state of our specifications. The proof is in the pudding.

The Truth

CSS now has behavior with features like :hover and animations. CSS has structure as well with the pseudo elements ::before and ::after. HTML has the same issues. Its new <input> types have behavior and presentation littered throughout. What the web currently looks like vs what separation wants the web to be is not the same.

The specification says separation is dead and the browser makers agree. Last year at SXSW during the browser wars panel I asked the panelists for their thoughts. I asked them what was to keep the <font> tag from coming back and why separation was not being addressed. Brendan Eich answered quickly and simply, “We don’t care about separation.”

He is right to say this. Separation has played its roll. But if he is right and we live in a new age, why do we we still teach separation? Why do we still pretend to follow it? I have a few assumptions.

Why Separation is Still Around

First, it worked at a basic level. It let us know when we were getting into gray areas. Second, the principle was simple and easy to understand. Each technology has its place, HTML, CSS and JavaScript.

So then, what should we do? Ignore all reason and do whatever we like? No, of course not. We need to be honest with ourselves and understand the raising pattern: Divergence.

We have been using Divergence for years. With every site you include :hover in your CSS. With the “email” value you use as your <input> tag’s type. With the many jQuery plug-ins that add new structure and presentation to a site. You use Divergence.

Divergence

What is Divergence? Divergence is the process you take when any of the three layers of separation cross. Let’s think about what we know the web is like today.

As an example let’s examine a scenario where presentation and behavior cross, such as when you need a design change as the cursor moves over a link. You need to pick CSS or JavaScript.

JavaScript has the mouseover event handler and CSS has :hover. However, you want to add a presentational effect, a nice underline maybe.

During the crossover of the two layers we are forced to choose CSS or JavaScript. You could choose CSS because you want to change the link’s style, but you could also choose JavaScript because the change is triggered by a behavior.

Unlike separation where you are trapped, Divergence says this is fine. In Divergence the lines can cross.

Think of Separation and Divergence as totally different logical approaches.

With Separation you live in a true and false world. Everything is black and white. It is on or off. It is Boolean by nature. With Divergence there’s black and white, but there’s also gray.

Truth is Conditional

The first rule of Divergence is that truth is conditional. Presentation can be behavioral and vice versa. We can use CSS a presentational technology with behavior as in the case of :hover.

However, Divergence does one thing that keeps it from creating a world where anything goes. To understand that concept we need to look at the <font> tag and understand how divergence keeps us from using <font> just as the principle of separation does.

Under the “conditional truth” rule of Divergence the <font> tag is fine. It is presentational and structural. However, with the second rule of Divergence there is an issue. This is the rule of “wholeness”.

Wholeness

The <font> tag is in HTML so it is a structure. However, it is not semantic and so while it is a structure it is not structural. The rule of divergence says that an item who falls into conditional truth is fine. It can be both structural and presentational at the same time. The <font> tag is.

However, the <font> tag must now pass the second rule. This rule, wholeness, says that the item must by nature be compliant wholly… to at least one of its parts. This does not negate the first rule. It only approves the item has the properties of the layer in which it lives.

Wholeness works like this:

• An item who is in structure must have the properties structure. In other words HTML must be semantic.
• An item who is in presentation must have the properties presentation. In other words CSS must effect presentation.
• An item who is in behavior must have the properties behavior. In other words JavaScript must effect behavior.

Divergence says that items can have multiple properties but can only operate from a layer if it belongs to it in wholeness. This means that the item itself must have the properties of the layer it lives in and can demonstrate the properties of another layer if it likes.

Where <font> Fails

The <font> tag meets the conditional truth of Divergence but is not fully structural. It demonstrates the properties of presentation in that you can set “font properties” with it. But, it can not belong to structure because its structural property is not structural. This is because the tag name is purely presentational – “font”. This means that it doesn’t belong fully to at least one of its parts.

Therefore it can not diverge to one side or the other. HTML or CSS. So, we can not use the <font> tag under Divergence.

The principle of Divergence is simple and complex. It apples to all layers of web design.

Some Examples

As a quick example we can say that the HTML5 email value of the <input> tag’s type is fine under Divergence. It is semantic and behavioral but complies wholly to at lest one of its parts HTML.

Simply using the pseudo elements ::before and ::after to create content as structure and not presentation is not divergent because it is not fully presentational. Not to mention inaccessible.

It is unfortunate that the world of web design is not black and white and fortunate at the same time because it moves us forward.

To Round it Up

We are standing in a new age. We need to stop saying separation and doing divergence. In the end we can pretend that the principle of separation is still relevant but it doesn’t support the current direction of the web. It doesn’t help standards and browser makers don’t care.

Most importantly we need practical principles to guide us. So we know when to say yes or no to new features in CSS and HTML so that we can keep one eye on the vendors and the other on the web’s future. We need to accept the fact that separation of structure, presentation and behavior is dead.

My favorite feature is the search, which allows you to filter features by compatibility, for instance what is safe to use in IE8+.

If you’re a Web Designer, Developer or Entrepreneur, you can’t miss Future Insights Live in Vegas on April 30 – May 4th. We’ve combined Future of Web Apps, Design and Mobile into one massive five day event, with over 100 sessions. It’s going to be like SXSW, but with valuable content ;) We’re expecting 1500+ attendees, so it’s going to be insane. The tracks include …

1. Development
2. Design
3. Frontend Development
4. Mobile Development
5. Business
6. Cloud

Early bird pricing ends soon (save $200) so move quick and book your ticket today.

This is my recounting of the Idea Week when we created Code Racer. This won’t be a full story as a lot of people worked on this project and I wasn’t in a position to keep track of what everyone was doing. Fortunately our video professionals at Treehouse had cameras rolling, so much of this is documented on video. I can only tell you about what I was involved in, which was the server and client side development.

I had been involved with one Idea Week before, when we created Brickify. This actually wasn’t an official Idea Week, it was a project we decided to build late on a Tuesday, but then became an Idea (half) Week.

We decided to do an Idea Week when Ryan told us he would be gathering the whole team together in Orlando this January. Since we had recently hired several new teachers and video pros, and Idea Week was a great way to get everybody working together as a team.

Treehouse CodeRacer Launch Video from Treehouse on Vimeo.

The idea for what we were going to build wasn’t decided until the Monday morning of our Idea Week. In the time leading up to the project, we figured our product would likely be a Ruby on Rails application with a great UI, design, API, and hopefully an iOS app. This seemed ideal because Alan and Jason work with Rails every day, and I have several years of experience with Rails as well. I was thinking Alan and Jason would lead the server side development, and I would focus on front-end interaction. It didn’t quite end up working out like that.

When Ryan presented his idea of creating a real-time code-challenge game, it became clear that our assumptions of responsibility were pretty far off. Since we needed to use Web Sockets (or their available fallbacks), Node.js became the clear decision for the Code Racer server. This changed the dynamic of the team a bit since I’m the resident Node.js guy, as well as the front-end JavaScript guy. Fortunately Alan, Jason, and Amit have experience with Node.js and JavaScript, so they were able to kick ass on Code Racer.

Besides not knowing the project idea until Idea Week begins, there is another challenge: a hard deadline. One week seems reasonable for a project that has 5 developers and 4 designers. That’s 5 days, right? Well, Treehouse works the four day work week, so it’s really 4. Also, Alan, Ryan, and Tyson had to fly out mid-day Thursday, so we had to launch Thursday morning. So Idea Week is really a little over 3 days. Better get started!

Tech Decisions

The first thing we did was discuss tech. Because the game required near real-time interaction between the players we chose Socket.io, which is a great server and client library for working with web sockets. This is what allows us to communicate quickly between the players and the server.

Socket.io is built on Node.js, which made Node.js the natural choice for our server. The event based architecture allows us to hold many socket connections open concurrently on one server.

As a group we also decided to use CoffeeScript for our server and client code. I found it to be very useful when I worked on Code Challenges for Treehouse, and Alan and Jason were interested in trying it out on a non-trivial project. It ended up working really well.

For the front-end, we chose to use Spine for our application library with jQuery powering our DOM interactions. There is a lot of information shooting around that needs to be reflected in the UI. Events from the user like typing inside the code editor, and events from the server like information about the game state all need to be handled so the models and views can be updated. Spine’s models, views, and controllers handled the interaction extremely well. Information from the server is received via socket.io, which will update our models. The various controllers on our page listen for changes to the model and update the views as needed.

We also utilized Facebook for authentication and MySQL for storing our users and game logs. I can’t talk much about those decisions because Jason lead that effort.

Day One – Planning and Server

On Monday morning, after our first meeting, the whole team swung into action. The designers and developers split up to talk about their plans and responsibilities. This is where we the developers began making the tech decisions that I described above.

While we were doing that, the design team was coming up with UI sketches as quickly as possible, so our whole team was on the same page. These sketches were extremely valuable to the dev team, because we needed to start building the UI almost immediately.

After that, the dev team split up and began working. Fortunately I had some side projects that utilized Node, CoffeeScript, and Less, so we were able to strip out the guts of that project and use it as a starting point. In less than an hour we had a running server and a github repo that everyone could start working on.

Code Racer: Day One from Treehouse on Vimeo.

I spent most of Day 1 setting up the project and then building a game matchmaking system where when you start a game, you join a lobby until that game reaches capacity. When the game reaches capacity it begins, and a new game is created for the next set of players.

Day Two – Interface

The second day for me was all about the front-end. By Tuesday we were able to connect to a lobby and start multiple games on the same server. Next on the list was creating the interface. There are a lot of moving parts in the game that must react to information sent from the server and the player.

When a new player joins, we have to add them to the page, which includes an editor, a tab in the players bar, and an entry in the lobby screen. When a player updates their code, it must be sent to the server, which will notify all the players in the game. Each player must take these notifications and update the code for the other player’s editor. Being able to watch someone else code was one of our top priority features.

Getting all of the information moving around the different client models and controllers, through the sockets to the server and back down to the clients was the most difficult problem to tackle. By Tuesday night we were able to see other players’ code as they typed it. Many of the other game elements like the timer, player list, and scores were also being displayed.

Code Racer: Day Two from Treehouse on Vimeo.

It was about this time I had to step away from the code for a while. Trying to hold all of the server and client interactions in my head was causing me to mentally fatigue, and I could tell I was becoming less effective. Fortunately Alan jumped in and spent Tuesday night working on getting the game logic up and running. I was amazed at how quickly it turned from a small prototype of live-coding into something that really looked like a game.

While I stepped back from the game logic and architecture, I was finally able to go around the office and see what everyone else was up to. It was awesome to see what was getting done. Amit had a working system for creating challenges and verifying answers from the players. Kevin had built a bunch of awesome weapons you can use on other players that will play sounds and manipulate your screen in some way. Jason had Facebook integration up and running. The design team was doing awesome creating amazing designs and interfaces.

Day Three – Integration and Testing

By Wednesday morning we had something that resembled a game. The html layouts the design team had built had not yet been integrated into the game and there was a lot of work to do on the game logic itself. Wednesday was all about getting the game done. We had to be ready to launch by Thursday. We spent the whole day working on the game logic, testing, tweaking, and testing again.

We played our first game on Wednesday after lunch and the competitive taunts and gasps of excitement and defeat from the players were quite loud. For the first time we were able to see that Code Racer is actually fun to play. A huge wave or relief rolled over the whole office. It actually looks like this idea may work.

Day Four – Launch!

Finally it was launch day. We spent the morning squashing bugs, polishing the UI and game play, and deploying the application. It was pretty stressful. We had a lot of things we needed to get done and almost no time to do it.

We sent out links to our friends to test Code Racer before the official launch. Of course this brought us a lot of feedback on improvements we could make and bugs we need to eliminate, which is how we spent Thursday.

As Ryan and Alan were getting ready to leave for their flights, we were able to launch Code Racer officially. We did it!. Articles from TechCrunch and Venture Beat went live, and tweets started flowing in. It was unreal. On Monday morning I wasn’t sure this idea was possible, but now here it was, online, with thousands of people playing it. In the first 3 days after launch over 6,800 players had played a total of over 4,500 games.

In less than 4 days, the team at Treehouse went from idea to product. I’m incredibly proud of all of the people who worked on Code Racer and count myself very lucky to have the opportunity to work with them.

The Libraries and Tools We Used

Finally, I wanted to share the (hopefully) complete list of tools we used to make Code Racer. Thanks to Jason for putting this list together!

• Node.js
• express
• Spine
• hem
• es5-shimify
• json2ify
• eco
• node-uuid
• Sequelize
• facebook-js
• CoffeeScript
• Socket.io
• Amazon EC2
• GitHub
• MacVim

CodeKit automatically compiles Less, Sass, Stylus, CoffeeScript & Haml files. It effortlessly combines, minifies and error-checks Javascript. It supports Compass. It even optimizes jpeg & png images, auto-reloads your browser and lets you use the same files across many projects. And that’s just the first paragraph.

This video is from Treehouse, a high-quality video training site with hundreds of short videos on topics like …

• Accessibility
• CSS3
• Aesthetic Foundations
• Django
• HTML
• CSS
• HTML5
• iOS Development
• JavaScript
• jQuery
• NoSQL
• PHP
• Responsive Web Design
• Ruby
• Ruby on Rails
• UX
• Version Control
• WordPress Theme Design

New videos are added regularly, so it’s a great way to stay up-to-date on all the latest technology and methods. Browse the entire library of videos.

The popover

The UIPopoverController is the class that facilitates the popover view. It takes a custom view controller and then displays it with a neat border and arrow, where the arrow points to its origin. It is ideal for displaying contextual information. The popover user interface is essentially made of three main parts: the border, content, and arrow.

Images

Before we look at the UIPopoverBackgroundView you will need two images to customize your popover. One image for the border and the other for the arrow.

Dissecting the background image

When designing the background image it is important to note that the image will be stretched. UIImage allows you to create a stretchable image by defining cap insets. These caps define portions of the image that will not be rescaled whereas the rest of the image is easily tiled when stretched. As seen in the image below the dark area is what will be tiled and the colored corners will not.

Subclassing UIPopoverBackgroundView

The UIPopoverBackgroundView is an abstract class which has no implementation. We need to subclass it and provide implementations for all its methods and properties. You can read the Apple documentation on all its properties and methods. What is not in the documentation is how to layout the border and arrow using the method layoutSubviews.

First let’s start by creating an Interface and subclassing the UIPopoverBackgroundView.

1
2
3
4
5
6
7
8
9
10

#import <UIKit/UIPopoverBackgroundView.h>
 
@interface CustomPopoverBackgroundView : UIPopoverBackgroundView {
    UIImageView *_borderImageView;
    UIImageView *_arrowView;
    CGFloat _arrowOffset;
    UIPopoverArrowDirection _arrowDirection;
}
 
@end

Make sure to specify your import statement or else the code will not compile. An explanation for each of the instance variables:

• _borderImageView: contains the image for the border
• _arrowView: contains the image for the arrow
• _arrowOffset: used for the property arrowOffset specified in the Interface for UIPopoverBackgroundView. We will see later how this value is used to calculate the position for the arrow.
• _arrowDirection: used for the property arrowDirection specified in the Interface for UIPopoverBackgroundView

Let’s fill out the implementation, starting with the designated initializer

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#import "CustomPopoverBackgroundView.h"
 
#define CONTENT_INSET 10.0
#define CAP_INSET 25.0
#define ARROW_BASE 25.0
#define ARROW_HEIGHT 25.0
 
@implementation CustomPopoverBackgroundView
 
 
-(id)initWithFrame:(CGRect)frame{
    if (self = [super initWithFrame:frame]) {
        _borderImageView = [[UIImageView alloc] initWithImage:[[UIImage imageNamed:@"popover-bg.png"] resizableImageWithCapInsets:UIEdgeInsetsMake(CAP_INSET,CAP_INSET,CAP_INSET,CAP_INSET)]];
 
        _arrowView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"arrow.png"]];
 
        [self addSubview:_borderImageView];
        [self addSubview:_arrowView];
 
    }
    return self;
}

Basically we are allocating and initializing the two views and adding them as subviews. Notice how the background image is defined with cap insets. Next, let’s implement all the required methods including the getters and setters for the properties.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

 
- (CGFloat) arrowOffset {    
    return _arrowOffset;    
}
 
- (void) setArrowOffset:(CGFloat)arrowOffset {    
    _arrowOffset = arrowOffset;
}
 
- (UIPopoverArrowDirection)arrowDirection {    
    return _arrowDirection;    
}
 
- (void)setArrowDirection:(UIPopoverArrowDirection)arrowDirection {    
    _arrowDirection = arrowDirection;
}
 
 
+(UIEdgeInsets)contentViewInsets{
    return UIEdgeInsetsMake(CONTENT_INSET, CONTENT_INSET, CONTENT_INSET, CONTENT_INSET);
}
 
+(CGFloat)arrowHeight{
    return ARROW_HEIGHT;
}
 
+(CGFloat)arrowBase{
    return ARROW_BASE;
}

The above methods are fairly straightforward with the exception of contentViewInsets. This method determines the thickness of your border. The higher the number the thicker your border. Finally, the method that lays out our two subviews in their appropriate sizes and location.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

 
-  (void)layoutSubviews {
    [super layoutSubviews];
 
    CGFloat _height = self.frame.size.height;
    CGFloat _width = self.frame.size.width;
    CGFloat _left = 0.0;
    CGFloat _top = 0.0;
    CGFloat _coordinate = 0.0;
    CGAffineTransform _rotation = CGAffineTransformIdentity;
 
 
    switch (self.arrowDirection) {
        case UIPopoverArrowDirectionUp:
            _top += ARROW_HEIGHT;
            _height -= ARROW_HEIGHT;
            _coordinate = ((self.frame.size.width / 2) + self.arrowOffset) - (ARROW_BASE/2);
            _arrowView.frame = CGRectMake(_coordinate, 0, ARROW_BASE, ARROW_HEIGHT);            
            break;
 
 
        case UIPopoverArrowDirectionDown:
            _height -= ARROW_HEIGHT;
            _coordinate = ((self.frame.size.width / 2) + self.arrowOffset) - (ARROW_BASE/2);
            _arrowView.frame = CGRectMake(_coordinate, _height, ARROW_BASE, ARROW_HEIGHT); 
            _rotation = CGAffineTransformMakeRotation( M_PI );
            break;
 
        case UIPopoverArrowDirectionLeft:
            _left += ARROW_BASE;
            _width -= ARROW_BASE;
            _coordinate = ((self.frame.size.height / 2) + self.arrowOffset) - (ARROW_HEIGHT/2);
            _arrowView.frame = CGRectMake(0, _coordinate, ARROW_BASE, ARROW_HEIGHT); 
            _rotation = CGAffineTransformMakeRotation( -M_PI_2 );
            break;
 
        case UIPopoverArrowDirectionRight:
            _width -= ARROW_BASE;
            _coordinate = ((self.frame.size.height / 2) + self.arrowOffset)- (ARROW_HEIGHT/2);
            _arrowView.frame = CGRectMake(_width, _coordinate, ARROW_BASE, ARROW_HEIGHT); 
            _rotation = CGAffineTransformMakeRotation( M_PI_2 );
 
            break;
 
    }
 
    _borderImageView.frame =  CGRectMake(_left, _top, _width, _height);
 
 
    [_arrowView setTransform:_rotation];
 
}
 
@end

The switch statement determines the direction of the arrow and then calculates the location of the arrow and its rotation. Our default arrow image points upwards so we need to change its rotation using an affine transform which takes in radians. The arrowOffset is calculated and set by the UIPopoverController which essentially tells us the distance of the arrow from the center of content view. We also have to adjust the height and width of our border view to account for the arrow.

Using the CustomPopoverBackgroundView

Now that we have created the CustomPopoverBackgroundView we need to set it when creating an instance of the UIPopoverController

1
2
3

UIPopoverController *popoverController = [[UIPopoverController alloc] initWithContentViewController:contentViewController] ;
 
popoverController.popoverBackgroundViewClass = [CustomPopoverBackgroundView class];

Note: the above code will work only in iOS 5

Now run your app and marvel at your newly designed popover.

This video is from Treehouse, a high-quality video training site with hundreds of short videos on topics like …

• Accessibility
• CSS3
• Aesthetic Foundations
• Django
• HTML
• CSS
• HTML5
• iOS Development
• JavaScript
• jQuery
• NoSQL
• PHP
• Responsive Web Design
• Ruby
• Ruby on Rails
• UX
• Version Control
• WordPress Theme Design

New videos are added regularly, so it’s a great way to stay up-to-date on all the latest technology and methods. Browse the entire library of videos.

Impress.js is a presentation framework that takes its inspiration from Prezi, another popular presentation platform. The difference is, impress.js uses open web standards. Check out the source for impress.js, on GitHub.