• 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!

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.

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. :)

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!

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.

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.

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.

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+.

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

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.

Check out the Ember.js on Github and read the announcement here.

Ember.js had the code name Amber while in development. It was announced under the name Amber.js, but renamed to Ember.js after there was some confusion with another project

You have probably encountered bookmarklets in some way, whether it’s in a bookmarking service like Instapaper, or maybe a cool web design tool that manipulates your page in some way. What you may not realize is that it’s very easy to create bookmarklets. So easy that you can use them not only in your large projects, but you can build quick bookmarklets to help you automate tedious online tasks.

Bookmarklet Basics

A bookmarklet is simply a snippet of JavaScript code saved as a link.
When you click the link, or click the bookmark you created from the
link, it runs the JavaScript code on the page that you are currently
looking at.

So what can you do with that? Almost anything! Let’s start, however,
with a very simple example.

So let’s take a very simple piece of JavaScript, and create a
bookmarklet.

alert('This is a rather simple example...');

This typical snippet of JavaScript simply pops up a box that says “This
is a rather simple example…”

So let’s now create a link that executes this snippet.

<a href="javascript:alert('This is a rather simple example...');"> Show Alert </a>

So it looks kind of like a typical <a> tag. The href however is a
little different. Instead of a typical page url, it is our JavaScript
code, preceded by javascript:. This is what allows us to run our code.

If you click the link, you will get the popup. But if you drag the link
to your bookmarks toolbar, you will then be able to click that bookmark,
and execute the code on any page.

Interacting with the Page.

The previous example isn’t very useful, it just pops up the same old
message each time. The beauty of a bookmarklet is that it runs the code
within the page you are viewing. This means your bookmarklet’s
code has access to all of the page elements, variables, and functions on
that page. This is also the reason to be careful using 3rd party
bookmarklets, they can also do malicious things like retrieve your
cookie from the page you are on and transmit it elsewhere.

Let’s jazz up our example to popup the title of the current page.

<a href="javascript:alert('This page is : ' + document.title);"> Show Title </a>

Now this link and bookmarklet will tell us the title of the current
page. This is because the document will be the page document of the
current page.

We can do much more than just get information and pop it up in an alert,
we can apply styles to a page, add or remove elements, or even
manipulate forms to automate data entry.

If you have some long form that is tedious to fill out, but the
actions you want to take can be automated, bookmarklets can save you a lot
of time. Better yet, you can create a bookmarklet for a coworker and be a
hero who saved him or her hours of work by simply spending a few minutes
creating a bookmarklet to help.

If you are making a bookmarklet to work on a particular site, there is a
good chance that the site uses jQuery (it’s that popular). If it’s another
framework you could utilize that too. If you know jQuery is on the page
you are using your bookmarklet for, it makes building bookmarklets that
much easier.

Here is a simple example. Sometimes when confronted with dozens of checkboxes on a page, I want to
just check them all, and maybe uncheck the few that don’t apply to me.
If there is no “Check All” button, I have to do it myself.
The code for that is simple, assuming you have jQuery on the target
page.

$(':checkbox').attr('checked', true);

This selects all checkboxes, and checks them all. Just throw code in a
link, drag the link to you bookmarks bar, and you’re ready to go
checkbox crazy at a moment’s notice.

Workflow

Often when creating bookmarklets, the code requires some
experimentation, and several JavaScript statements.

Here is the workflow I use.

Step 1: Experiment in the Dev Tools or Firebug

Since your code will run on a page, pick out a target page, and open
the JavaScript console of your Dev Tools, or Firebug. This allows you to
experiment with the JavaScript code and what CSS selectors can be used to select elements (if
you are using a framework like jQuery, as shown above).

You may want to write the code snippet in a text editor, then copy and
paste it into the console, rather than try to form you statement(s) in
the console itself.

Once your code does what you want, move to step 2.

Step 2: Prepare Your Code

Since you will have to place your code in the href attribute of an
<a> tag, there are some formatting restrictions. First take note of
any quotes in your code. I like to use only single quotes in my
bookmarklet code, so when I wrap the code in double quotes to embed it
in the HTML, I don’t break out of the href value.

Your code should also be compact. You can do this fairly easily by
removing line breaks. Make sure you are using semicolons properly, but
you already do that, right? You could also try using a JavaScript
minifier to reduce the code, but if there is that much code, you may
want to try a different technique, I will explain shortly.

Step 3: Create the Bookmarklet

There are two main ways to add a bookmarklet to your browser. You can
create an <a> tag on a page, and drag it to your bookmarks, or you can
create a normal bookmark to any page, then edit its title and link. You
would then set the like location to your ‘javascript: …’ code. This
strategy can be a bit cumbersome, but editing an existing bookmark is
the way you have to do it on iOS.

I prefer to create a link on an HTML page. This makes it easier to
share.

We saw the syntax for this at the beginning of this article.

It’s an <a> tag. The href is in the format "javascript: YOUR CODE
HERE" and the content of the tag will be the title of the bookmarklet.

You can either create a new HTML page to create this link, or you can
use something like jsFiddle to quickly create
your link. This has the added benefit of making it easy to share with a
coworker, a friend, or the world.

Bigger Bookmarklets

If you are creating a bookmarklet that goes beyond a simple gimmick or
time saver, you may have a lot more code. While you can cram quite a bit
of code in that link, it’s often better to instead create a JavaScript
file that is hosted on the web, then have the bookmarklet load that
script into the page. Your script will execute in the page just as it
would have with the shorter bookmarklets.

Creating an external file has the added benefit of being able to update
the logic of the bookmarklet by simply updating the target file.

The readable version of the code looks like this.

(function () {
  var script = document.createElement('SCRIPT');
  script.src = 'http://example.com/the_code.js';
  document.body.appendChild(script);
})()

This creates a <script> tag, sets its src, and adds it to the page,
which will fetch and run the file immediately. Of course you would
change the value of src to be the url to your JavaScript file.

The whole thing is wrapped in a function that will execute immediately.
This is because we are creating a variable called script. Since we are
going to be running this on another page, we don’t want to accidentally
mess up a global variable that page may be counting on. By wrapping it
in this self executing function, we keep all our variables to ourselves,
not messing up the target JavaScript environment.

Ultimately the code is compressed to this:

<a href="javascript:(function(){var script=document.createElement('SCRIPT');script.src='http://example.com/the_code.js';document.body.appendChild(script);})()"> Do Something! </a>

Use Your New Superpowers for Good

Now that you can make bookmarklets, you can add all sorts of features to
any site you want. You are now a developer for any site on the web.

Almost anything is possible when you can run JavaScript on a website. If
you want to learn about what is possible with JavaScript, check out the
JavaScript and jQuery lessons on
Treehouse.

Update: A real-life example

I was watching the iOS videos on Treehouse, and coding along when I realized what I would like is for the video to pause when I tab over to Xcode, then resume when I come back to Treehouse. Since I work for Treehouse I could have easily added it to the feature development list, but I wanted it right away. So a bookmarklet was born.

You can check out the bookmarklet here. The code was built for use on a Treehouse video page, but it should work on any page with HTML5 video and jQuery.

Manual Reference Counting

If you have been developing on the earlier versions of iOS 4 then you are probably familiar with reference counting. In a manual reference counting environment you have to keep track of object ownership. If you own an object you must make sure to release it, if you don’t then you will have a memory leak, which eventually leads to app crashes. Aside from crashes or leaks keeping count of the retain, release and autorelease is cumbersome.

Here’s a typical example, you allocate a new object called obj1, then you point obj2 to obj1. At this point you have to make sure that you retain obj2, which increases the reference count. In addition, you have to make sure you send a release to each object to free memory once the retain count goes down to zero. This is a simple example but in a normal sized app this can get very complicated, very quickly.

Automatic Reference Counting (ARC)

The above example is simplified when using ARC.

1
2

MyClass *obj1 = [[MyClass alloc] init];
MyClass *obj2 = obj1;

As you can see, you still allocate obj1 and then point obj2 to obj1. The retains and releases are still occurring, although now it all happens behind the scenes. It is the compiler’s job to maintain the life of an object and to ensure that it is appropriately deallocated when no longer in use. Since this is not garbage collection, you do not sacrifice speed. Your app is just as fast and now with less maintenance. You get to focus on the features of your app and not get distracted by memory management.

Strong vs Weak

With ARC the only thing you have to consider are the qualifiers Strong and Weak.

The strong qualifier is set by default. When using this qualifier you are instructing compiler that you would like to retain an abject for the current event cycle.

You can still use retain, however it is recommended that you use strong instead.

The weak qualifier also known as a zeroing weak reference, instructs the compiler that you do not need to retain the object. And if all the references to this object go down to zero then the object is released and set to nil. This is important because a message send to a nil object does not cause a crash, it simply doesn’t do anything.

You can still use assign, however it is recommended that you use weak instead because it will set a deallocated object to nil.

A weak qualifier is especially used in a parent child object relationship, where the parent has a strong reference to a child object. And the child object a weak reference back to parent otherwise you will end up creating a circular reference.

Upgrading to ARC

Upgrading an existing project to use ARC is very simple. Open up your project in Xcode 4.2 and from the menu select Edit > Refactor > Convert to Objective-C ARC. The conversion process first performs a pre-flight check and then ensures that you are ready to upgrade to ARC. It then gives you a preview of all the changes it will make to your code before finally committing the changes.

Further Reading

This is just a preview of the changes that come with ARC. There are plenty of little nuances that you can read about in the articles below:
Technical specification of ARC
Transition to ARC release notes

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.

Just because your configuration file’s contents are written in a DSL does not mean you should pretend it’s not Ruby anymore.

Personally, I agree with Mr. Susser on every point except the Rakefile, since the original intention of rake is to be Ruby’s version of make. However, rake does support the Rakefile.rb convention as well as a couple of variants. What do you think? Let us know in the comments.

Whenever I see great UI in a native application on a mobile device or a desktop, I always imagine how that might translate to the web. That’s why I was so happy to see the Path menu UI recreated in CSS3! Mad props to Victor for putting this together.

Now not only is there a solution to this problem but there are two solutions to choose from.

CocoaPods

CocoaPods has been around for quite some time and garnered a lot of community support. Basically, you create a Podfile that lists all your project dependencies in one text file. You then run a command line tool to install the dependencies which looks for a Pod, a spec file containing information about each library, based on the Pod it fetches the source code and adds the dependency to your Xcode workspace in a separate project.

VendorKit

VendorKit is fairly new and takes a slightly different approach. Once again you create a text file with all your project dependencies and then run a command line tool. Here’s where the difference becomes obvious: Cocoapods use standardized Podfiles that contain the names of libraries and probably version numbers which, in turn, fetches a Pod detailing information about each library. With VendorKit, you specify the library name, where it’s located, and if it has other dependencies. There is no standardization. There is a vendor spec file, but it’s only required if the library has other third-party dependencies. Other than that, it delivers on its promise, helping you manage your dependencies.

Both approaches have their own merit and and it all depends on your requirements and workflow.

The Basics

RSpec gives you a way to encapsulate what you’re testing via the describe block, and it’s friend context. In a general unit testing sense, we use describe to describe the behavior of a class:

describe Hash do
 
end

Tests are written using the it block. Here’s an example of how you might write a spec for the Hash class:

describe Hash do
  it "should return a blank instance" do
    Hash.new.should == {}
  end
end

Those are the basics of writing some rspec examples. You can run the above by installing rspec via gem install rspec and putting that code in a file called hash_spec.rb and typing:

$ rspec hash_spec.rb

You should see something like the following:

.
 
Finished in 0.11021 seconds
1 example, 0 failures

You can set up test state using the before and after directives. This will apply to anything in your describe block:

describe Hash do
  before do
    @hash = Hash.new({:hello => 'world'})
  end
 
  it "should return a blank instance" do
    Hash.new.should == {}
  end
 
  it "hash the correct information in a key" do
    @hash[:hello].should == 'world'
  end
end

The above code will create the @hash variable before each test is run. There are two arguments for before– all and each. Using the all argument, the setup will be done once before all of the tests in the block, and :each will be done before each individual test. The after directive has the same options and runs the same way, only after tests are completed. This is most useful when tearing down the previous state of the tests.

RSpec Idioms

We usually use the describe keyword to describe methods. Using a “.” will signify that you’re testing a class method, and using “#” will signify that it’s an instance method. Here’s how it might look for a made up class:

describe MyClass do
  describe ".class_method_1" do
  end
 
  describe "#instance_method_1" do
  end
end

The context method does the same thing by letting you contextualize a block of your tests. This is extremely powerful for test states when you add more complicated setup and teardown code to really get in to your objects. I’ll show you a bit more of a real life scenario by building a delicious burger class.

Let’s say that in our Burger class we’re trying to test the #apply_ketchup method. Someone may not want ketchup on their burger. Instead of judging them, we’ll write a test for the class to not apply ketchup if someone doesn’t want it:

describe Burger do
  describe "#apply_ketchup" do
    context "with ketchup" do
      before do
        @burger = Burger.new(:ketchup => true)
        @burger.apply_ketchup
      end
 
      it "sets the ketchup flag to true" do
        @burger.has_ketchup_on_it?.should be_true
      end
    end
 
    context "without ketchup" do
      before do
        @burger = Burger.new(:ketchup => false)
        @burger.apply_ketchup
      end
 
      it "sets the ketchup flag to false" do
        @burger.has_ketchup_on_it?.should be_false
      end
    end
  end
end

Cleaning Up a Bit

The above pattern works but can become a bit tiresome to repeat all the time. RSpec gives us some helper methods to generalize it. We could rewrite the above using the let keyword to make the the variable automatically. The variable would then get created the first time it is accessed:

describe Burger do
  describe "#apply_ketchup" do
    context "with ketchup" do
      let(:burger) { Burger.new(:ketchup => true) }
      before  { burger.apply_ketchup }
 
      it "sets the ketchup flag to true" do
        burger.has_ketchup_on_it?.should be_true
      end
    end
 
    context "without ketchup" do
      let(:burger) { Burger.new(:ketchup => false) }
      before  { burger.apply_ketchup }
 
      it "sets the ketchup flag to false" do
        burger.has_ketchup_on_it?.should be_false
      end
    end
  end
end

This all works but we can clean it up even further using the subject method. The subject method tells rspec what we’re doing the tests on. We’re going to combine that with the specify method in the next example. The specify method is just like the it method except the specify method takes the code block as the description of the test:

describe Burger do
  describe "#apply_ketchup" do
    subject { burger }
    before  { burger.apply_ketchup }
 
    context "with ketchup" do
      let(:burger) { Burger.new(:ketchup => true) }
 
      specify { subject.has_ketchup_on_it?.should be_true }
    end
 
    context "without ketchup" do
      let(:burger) { Burger.new(:ketchup => true) }
 
      specify { subject.has_ketchup_on_it?.should be_false }
    end
  end
end

One neat thing about rspec is that the built in matchers will let you declaratively specify methods in your tests if they conform to a certain naming convention. RSpec will look for methods that are named with has and end in a question mark to let you do write declarative test code. Here’s what our final Burger class will look like using that idiom. Put the following in a file called burger_spec.rb and run it:

class Burger
  attr_reader :options
 
  def initialize(options={})
    @options = options
  end
 
  def apply_ketchup
    @ketchup = @options[:ketchup]
  end
 
  def has_ketchup_on_it?
    @ketchup
  end
end
 
 
describe Burger do
  describe "#apply_ketchup" do
    subject { burger }
    before  { burger.apply_ketchup }
 
    context "with ketchup" do
      let(:burger) { Burger.new(:ketchup => true) }
 
      it { should have_ketchup_on_it }
    end
 
    context "without ketchup" do
      let(:burger) { Burger.new(:ketchup => false) }
 
      it { should_not have_ketchup_on_it }
    end
  end
end

A Burger Needs More Than Just Ketchup

In this brief tutorial we jumped in to rspec and created a burger class. Then we refactored our tests a bit to make them more idiomatic. What we wound up with was easier to read and quick to run. In the next tutorials in this series, we’ll delve deeper in to rspec including more idioms, further testing, and writing our own matchers. For now, I know what I’m having for lunch.

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.

• Jbuilder is a DSL for declaring JSON structures, created by DHH (creator of Rails). It lets you declaratively build your JSON output similarly to how Builder works for xml. It’s currently in the rails user account on GitHub and it may make an appearance in Rails 3.2.
• Rspec 2.8.0 rc1 has been released with some interesting additions to rspec-core and rspec-mocks. Some of the highlights including running examples in random order, the ability to add custom profile options files, and being able to filter example groups from the command line.
• Finally, there’s been talk of converting the Ruby standard library to gems for Ruby 2.0. It’s mostly discussion at this point but that could be an interesting move as it would not require loading the whole standard library for every Ruby program. Additionally, updates to the standard library could come out much quicker than the typical Ruby interpreter release cycle.

What are your thoughts on all this? Have any interesting Ruby news to share? Let us know in the comments.

As the name implies the application is divided into three distinct parts: Model, View and Controller. The main purpose for MVC is reusability where you can reuse the same model for different views.

Model

The model contains the data. For example, a Book object contains information regarding the book such as: title and author. In addition, the Book object could be related to other objects establishing a one-to-one or one-to-many relationship. For example, the Book object could relate to a Category object, wherein one Category can contain multiple Book objects. The model objects obtain data either from a database or files, which could be located locally or externally. The model does not talk directly to a view, instead is made available to a controller which accesses it when needed. In iOS, a model is usually a subclass of NSObject or in the case of Core Data (an iOS framework that helps save data to a database locally on the device) NSManagedObject. As with any model object it contains instance variables and getter / setter methods. Most object-oriented languages have a mechanism to provide encapsulation, in iOS a property provides encapsulation and the keyword synthesize automatically generates the getter and setter methods. In the case of Book you would have methods such as getTitle and setTitle or getAuthor and setAuthor.

View

The view displays information contained in the model. For example, the view could display a list of Books as mentioned in the above example. Although the view does not obtain the information directly from the model, it uses the controller as a mediator which instructs it when and what to display. In iOS, most views subclass from UIView which provides the capability for handling touch events and drawing. The UIKit framework contains classes to draw typical interface elements such as tables (lists), buttons, textfields, sliders and more. Below is a list of books displayed using the class UITableView.

Controller

Finally, the controller is responsible for accessing data from the model and displaying it on the view. The same controller can be used to intermediate between several views and models. The controller monitors user interaction with the view and communicates any changes to the model. On the other hand, changes to the model are observed by the controller and subsequently reflected in the view. The controller is also where most of the application lies. In iOS, the controller is generally a subclass of UIViewController that manages a view, it is also responsible for responding to delegation messages and target-action messages. Below you have a UITableViewController which is a subclass of UIViewController that manages a UITableView.

Related posts

Check out the other posts in this series:
iOS Design Patterns: Target-action (Part 1)
iOS Design Patterns: Delegation (Part 2)

If you are interested in learning more do check out the iOS development course.

We’re going to be using homebrew and rvm to get this all up and running. This is a bit of an opinionated method of getting everything installed. There are several ways of installing a modern Ruby and Rails environment and in the end, they all get you to the same place. Another popular option for getting ruby up and running is ruby-build and rbenv.

For the purposes of getting everything up and running quickly, I find rvm to be a bit easier to use and explain so I’m going to use that. Another quick note: while these instructions are written for Lion, they should also work on Snow Leopard, particularly the osx-gcc-installer instructions.

Install Developer Tools

Before we install either Homebrew or rvm, we need to have a compiler installed. Xcode happens to come with one. Open up the App Store and type “Xcode” in to the search box. Click install. This is a large download so go ahead and get some coffee or catch up on the latest meme on Reddit.

Another option is to use the osx-gcc-installer. This doesn’t install the Developer Tools from Apple, only the compiler. The instructions that follow should work with only that installed but I haven’t tested it. Besides, you’ll probably want to have the full developer tools installed so you can unlock the iOS foundations badge on Treehouse.

Install Homebrew

Homebrew is “The missing package manager for OS X.” The other big package manager available on OS X is called MacPorts. It’s also very good but we’re going to use Homebrew for the purposes of this article.

A Word of Warning

The instructions that follow run a shell script directly from a web site that you are not in control of. This is generally considered a Bad Thing™ and in general, you should at least review what the script is doing before you run it. We’re going to have to trust each other and the homebrew team that the script does what it’s supposed to do. Always think twice when you see something like this, though.

Nevertheless, we’re going to trust the homebrew team and run this script. I’ve run this several times before and it’s not like it’s a comment thread on YouTube.

Moving On

Open up the Terminal application that comes with OS X. This should be inside the “Utilities” folder in your main “Applications” folder. Type the following:

/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

You should see a bunch of text going by at this point and having it seem like something is installing. If you see any error messages, double check to make sure that you’ve installed the Developer Tools correctly.

Install Git

This part should go by pretty quickly. Open up a terminal and type the following:

brew install git

You should now have git installed. You can verify by typing the following:

git --version

You should see:

git version 1.7.7.2

That’s the latest version of git as of this writing. If you don’t see something similar, double check that you’ve correctly installed the Developer Tools and Homebrew above.

Install MySQL

Now that you’ve got Homebrew installed, installing MySQL is pretty easy. In the same terminal, type the following:

brew install mysql

Again, you should see a bunch of text going by saying things like “Downloading,” “Patching,” “make” and the like. After it finishes, you should see a bunch of instructions. Let’s follow them, still in terminal:

mysql_install_db --verbose --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp
mkdir -p ~/Library/LaunchAgents
cp /usr/local/Cellar/mysql/5.5.15/com.mysql.mysqld.plist ~/Library/LaunchAgents/
launchctl load -w ~/Library/LaunchAgents/com.mysql.mysqld.plist

That should install mysql to run on startup of your system. Test it with the following at the command prompt:

Note: The dollar sign in front of the mysql command denotes that we are at a shell inside of the terminal. It is not necessary to type it.

$ mysql -uroot

You should see the following:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 75
Server version: 5.5.15 Source distribution
 
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
 
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
mysql>

If you don’t see that, something went wrong in the install. Double check the instructions above and try again. Type “quit;” to exit the prompt.

Congratulations! You’ve installed msyql.

Install RVM

RVM is the Ruby Version Manager. It lets you easily switch between different versions of Ruby on the command line. Remember what I told you a few paragraphs above about not running untrusted shell scripts? We’re going to do it again. Open up terminal again and type the following to install rvm:

$ bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

That install install rvm. We’re not done yet, though! Create a new file in your home folder called “.bash_profile” and open it using a text editor:

$ touch ~/.bash_profile
$ open -e ~/.bash_profile

This will open the file in TextEdit. Place the following inside:

export PATH="./bin:$PATH" 
[[ -s "/Users/jason/.rvm/scripts/rvm" ]] && source "/Users/jason/.rvm/scripts/rvm"

Make sure to change jason above with the “Account name” on your mac. You can find that by typing the following in to your terminal:

$ echo $USER

In my case it returns jason.

If you already have a .bash_profile, you can add those lines to it at the bottom.

With those things done, you can now close terminal.

Install Ruby

In terminal, we need to tell RVM to load the environment we just set up. With terminal open, type the following:

$ source ~/.bash_profile

Now we can install a ruby interpreter:

$ rvm install 1.9.3-p0

This will install the latest Ruby. At the time of this writing, that is version 1.9.3, patch level 0. This should take a few minutes. Feel free to get back to Reddit as you have already loaded up on coffee by this point.

Once it’s done, you have installed Ruby! Congratulations!

Now, let’s tell rvm to use the Ruby we’ve just installed:

$ rvm use 1.9.3-p0

And we’ll make sure we’re using the right version:

$ ruby -v

You should now see:

ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.2.0]

Update: As Ryan Townsend points out in the comments, if you’d like to use this version of Ruby every time you’re in a shell, type the following:

$ rvm use 1.9.3-p0 --default

Thanks, Ryan!

Install Rails

Now that we have Ruby installed, let’s install some gems. First up, we’re going to want to install bundler which Rails depends on. Let’s install some gems:

$ gem install bundler
$ gem install mysql2
$ gem install rails

Now that we have rails and bundler installed, we can create our own rails app. Type the following:

$ rails new testapp

This will create a rails application called “testapp” and then run “bundle install” inside of it. Congratulations, you are now on the rails!

Summary

We’ve gone and installed the latest versions of the Developer Tools, a package manager, git, mysql, ruby, and rails. At this point, we’re all set to create our own Rails applications. If you’d like to learn Ruby, keep an eye on Treehouse. We’ll have the Ruby Foundations badge ready to be unlocked real soon now. If you have any questions, let me know in the comments. Cheers!

I got to choose the tools for the Code Challenges, and now I get to share with you what tools I used, why I chose them, and how they worked out. The code challenge is built as two small, independent applications using NodeJS, Dojo, CoffeeScript, RequireJS, CouchDB, and the Ace Editor.

Modularity

There are two major components involved in the Code Challenge tool. One component is the editor interface that you interact with. This is the only component you really see and touch. The other is the component that actually evaluates the code you write to see if it is correct.

I decided to make these two components completely separate applications. The only coupling between them is the editor component calls the test evaluator via a web service. This turned out to be a very good decision, because the two applications have very different resource needs.

The editor application pretty much entirely runs in the web browser. The server for the editor does a very small amount of work. It was able run on a single Heroku dyno and survive the spike of traffic generated when Treehouse launched.

The code testing application, on the other hand, does a lot of heavy lifting on the server. Because of this, it isn’t able to run on Heroku, so instead we ended up running it on Amazon EC2 instances. Since the testing application is entirely stateless, we are able to fire up multiple instances of the server behind a load balancer. This allowed us to keep challenges up an running as thousands of people began taking challenges.

In this article, I will mainly be talking about what powers the code editor component.

NodeJS

NodeJS powers the application and web servers that run our Treehouse Code Challenges. The servers are actually very thin. Besides serving the static assets, the servers mainly act as a proxy to the database and other services.

Node is particularly suited for the task of proxying data because it can handle a lot concurrent connections, since the server is only busy while actually moving the information through the server. The time the connections are idle and waiting can be used to serve other clients.

Dojo

The user facing application is a single page JavaScript app. All of the interaction is done on one page, with no reloading or linking to other pages. The user interface makes use of a lot of advanced interface elements including tabs, resizable layouts, and stack layouts. My options were to use jQuery and jQuery UI (or a mish-mash of other jQuery plugins), or I could build my own UI elements, or use a more robust library like Yahoo’s YUI or Dojo.

After some prototyping with YUI and Dojo, I decided to use Dojo. It had a larger variety UI Widgets, and seemed like a pretty solid choice. There are a lot of great options I could have chosen, but I chose Dojo because it was new to me, seemed to have a lot of support, and integrated well with the AMD module pattern that I was using via RequireJS.

The main drawback is that Dojo’s documentation can be a bit tricky to navigate, and sometimes I just had to dive into the Dojo source to figure out what was happening. Ultimately I feel confident building with Dojo, but there is definitely a learning curve when you get started.

CoffeeScript

I have been a fan of CoffeeScript for a while, but I had yet to use it for a non-trivial project. I decided that I would use CoffeeScript front-to-back. The front-end code is CoffeeScript. The NodeJS server is CoffeeScript. Even the CouchDB design documents are written in CoffeeScript, then translated to JavaScript and saved to the server.

I chose CoffeeScript because I liked CoffeeScript, and wanted to find out if using it in a large project would make me love it or hate it. Well, now I love it. My code is both readable and maintainable and a significant amount of boilerplate code has been removed. The way CoffeeScript handles classes and inheritance made it super convenient to subclass Dojo widgets for the UI. I hope to delve deeper into this in an upcoming article.

RequireJS

Organizing code in JavaScript can be complicated, but in a larger application, proper organization is crucial. Having all of your code in one or two files just isn’t maintainable. The more you split up your files, the more complicated it gets to include it into your page. You have to make sure all of your files are included in such a way that all dependencies are loaded before they are used.

RequireJS does a phenomenal job at allowing you to split your code in such a way you can have just one class or module per file. RequireJS also includes an optimizer that will combine all your files into a single, minified file for use in production.

RequireJS uses the Asynchronous Module Definition (AMD) pattern for organizing your code. Dojo also uses such AMD to define it’s own modules, so you can require specific Dojo dependencies in your project, just like you require any of your own files. This is a huge win since I could keep my code organized in a consistent way.

You can read more about why RequireJS is awesome in my previous article.

CouchDB

When it came to choosing a datastore for the application, I wanted something that would be easy to work with from the front end. I narrowed it down to MongoDB and CouchDB. I actually built the first prototype with MongoDB, and ended up switching out to Couch.

It turns out all I really needed in a database was something that could store arbitrary documents, and retrieve them by ID. The querying functionality in MongoDB is very cool and useful, but I just didn’t need it in this project. I always had the ID of the document I needed, and only need to have proper queries in the admin tools (to a very small degree). This made CouchDB’s strengths outweigh MongoDB’s for this project, and that is why I made the switch.

CouchDB is queried over HTTP, which is great because I was able to effectively do the querying from the front-end code, and just use the server to proxy the query to CouchDB relatively untouched. The server does have some logic for security, but ultimately the front end code is directly querying the database.

Ace

One of the most important parts of the Code Challenge is code editor, since it’s really all about the code. A simple HTML textarea just won’t do. An editor should have good indentation support, code highlighting, and the keyboard shortcuts you would expect.

The Ace project provided a great code editor with pluggable themes, language support, and a good amount of extensibility. Overall I am pretty happy with Ace, but we might end up swapping it out for a similar component.

Since the application is so modular, it’s very easy to swap out components like Ace if an alternative has better support for a certain feature we may want.

Results

I am extremely pleased with each of these tools, both how they work in isolation, but also in how they work together. There were several points in development when I couldn’t work on this code for several weeks at a time. Normally I am disoriented when coming back to code after such a break, but in this project it was so well organized that I was able to pick up fairly quickly from where I left off.

I was also able to do a full rewrite of the code about halfway through because I was able to simply write new modules, and switch them out one by one. This allowed me to rewrite some sloppy code with my new knowledge I had gained about my tools. This rewrite only took a few hours, and didn’t introduce any regressions in functionality.

Dojo turned out to be particularly awesome because the widgets are supported and tested thoroughly in most browsers. Everything pretty much “just worked” from one browser to another, and I didn’t spend much time at all on browser bugs.

The launch of Treehouse and Code Challenges was a complete success. The code challenges had only a few minor bugs pop up during launch, and most of these were small style bugs. The servers kept pace with no problems since it was easy to add more servers when traffic picked up.

This combination of tools allowed me to build both prototype and a real application very quickly. It has very few bugs, is easy to maintain, and ultimately is a joy to work with. I hope to share some specific tips and tricks I discovered with these tools, both here on Think Vitamin, and on Treehouse.

Delegation Example

The delegation pattern means exactly what its name implies, in that it delegates control. It is simple yet powerful.

Take the example of a simple app that contains some images within a scrollable view. The images are laid out horizontally and dragging the view horizontally makes it possible to paginate between the images. The images are downloaded from the internet, hence scrolling should automatically trigger the image download.

Therefore, the two main components for this app are the image downloads and the scrollable view. Once the view has been scrolled the application needs acknowledgement of this event and subsequently trigger an image download. In most cases what matters most is where the scrolling has halted, however, in some cases it is also important to know when the scrolling began and the velocity of the scroll. The iOS framework has a class called UIScrollView but this is a generic class without any knowledge of the fact that there are images that need to be downloaded upon scroll. This would be an application specific task and it is impossible for the UIScrollView to perform any such tasks.

So how does the UIScrollView notify the application of scrolling events? It uses a delegate class called UIScrollViewDelegate which defines all the scrolling events available. The application can then implement this delegate and intercept those scrolling events.

Delegate property

In the example above, the application creates and displays an instance of the scroll view which then contains a reference to the delegate. The delegate is a property of the UIScrollView which tells the view that another class will contain an implementation of the methods defined in UIScrollViewDelegate. Therefore, when scrolling occurs it refers to its delegate and accordingly calls the methods. Another way to look at it would be a method callback.

Delegate protocol

The delegating class (such as UIScrollView in the above example) contains a property, usually named delegate and it declares one or more methods that constitute a formal or informal protocol.

A formal protocol (such as UIScrollViewDelegate in the above example) declares all the methods that can be implemented by a class. It can also mark methods as required or optional.

The informal protocol declares methods on a category of NSObject. A category is a feature that enables you to add methods to a class without subclassing it. However, Apple is phasing out this approach.

The mechanism of delegation gives objects a chance to coordinate their appearance and state with changes occurring elsewhere in an application usually brought about by user actions. More importantly, delegation makes it possible for one object to alter the behavior of another object without the need to inherit from it. The delegate is almost always one of your custom objects, and by definition it incorporates application-specific logic that the generic and delegating object cannot possibly know itself.

Naming convention

The delegate methods follow a standard naming convention. Starting with the name of the UIKit object doing the delegating which is followed by an auxiliary verb (such as: will, should, did or has) describing the status of the reported event. Let’s look at some of the methods within the UIScrollViewDelegate:

– scrollViewDidScroll:
– scrollViewWillBeginDragging:
– scrollViewWillEndDragging:withVelocity:targetContentOffset:
– scrollViewDidEndDragging:willDecelerate:
– scrollViewWillBeginDecelerating:
– scrollViewDidEndDecelerating:

Data Sources

The data source is just like the delegate except it has a different purpose. Instead of delegating control of the user interface it delegates control of data. For example, a table view has a data source which provides information on which rows to display with what data. Data sources are responsible for the memory management of their data objects.

Related posts

Check out the other posts in this series:
iOS Design Patterns: Target-action (Part 1)

If you are interested in learning more do check out the iOS development course.

This video is from Think Vitamin Membership, a high-quality video training site, curated by us at Carsonified and Think Vitamin, with hundreds of short videos on topics like …

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

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