&lt;p&gt;W3C today published the &lt;a href="http://www.w3.org/2011/10/integration-workshop/report.html"&gt;report&lt;/a&gt; of the &lt;a href="http://www.w3.org/2011/10/integration-workshop"&gt;Workshop on Data and Services Integration&lt;/a&gt;, hosted on 20-21 October 2011 by MITRE in Bedford, Massachusetts, USA. This workshop provided a way for the community to meet and discuss some of the challenges of integration of heterogeneous data and services. With the emergence of the Web, the need for reusing data and services has become even stronger as the number of available services has grown. Different services stacks now exist from Web Services to Cloud-based services. One goal of this workshop was to figure out the needs in the domain of integration that would benefit from standardization, or where discussion via Community or Business Groups could gather a critical mass.&lt;/p&gt; &lt;p&gt;The participants came to the conclusion that solutions to the data integration issues can be the result of better integration of tools helping going cross-stacks. They also discussed how to architect RESTful services in the enterprise, with a plan to create a group to work on Linked Data Patterns, specifically REST-based patterns on RDF and other formats.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/2005/Incubator/mami/"&gt;Media Analysis Management Interface Incubator Group&lt;/a&gt; published its final report, &lt;a href="http://www.w3.org/2005/Incubator/mami/XGR-mami-20120125/"&gt;Media Analysis Management Interface XG Final Report&lt;/a&gt;. The Media Analysis Management Interface (MAMI) enables the understanding of the real world at a low cost by using analysis engines such as video image processing engines, sensor data analysis engines, and so on. It also enables various services to be easily provided, such as physical security, environmental load reduction, and intelligent accessibility services. The MAMI Incubator Group described the requirements of the MAMI and six use cases in three fields: energy saving, video surveillance, and operational improvement. The Incubator Group expects to collaborate with other W3C working groups, in particular the Multimodal Interaction Working Group.&lt;/p&gt; &lt;p&gt;This publication is part of the &lt;a href="/2005/Incubator/"&gt;Incubator Activity&lt;/a&gt;. This work is not on the W3C standards track.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="/2002/mmi/"&gt;Multimodal Interaction Working Group&lt;/a&gt; has published a Group Note: &lt;a href="/TR/2012/NOTE-mmi-interop-20120124/"&gt;MMI interoperability test report&lt;/a&gt;. This document describes an interoperability test, executed by various members of the Multimodal Interaction Working Group, to demonstrate interoperability of multimodal components which are implementing the "Multimodal Architecture and Interfaces" specification. Learn more about the &lt;a href="/2002/mmi/Activity.html"&gt;Multimodal Interaction Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/XML/Processing/"&gt;XML Processing Model Working Group&lt;/a&gt; has published a Last Call Working Draft of &lt;a href="http://www.w3.org/TR/2012/WD-xml-proc-profiles-20120124/"&gt;XML processor profiles&lt;/a&gt;. This specification defines several XML processor profiles, each of which defines how any given XML document should be processed, both operationally and in terms of what information must be made available to applications. It is intended as a resource for other specifications, which can by a single normative reference establish precisely what input processing they require as well as what information they require. Comments are welcome through 29 February. Learn more about the &lt;a href="http://www.w3.org/XML/"&gt;Extensible Markup Language (XML) Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/2008/xmlsec/"&gt;XML Security Working Group&lt;/a&gt; invites implementation of three Candidate Recommendations: &lt;a href="/TR/2012/CR-xmldsig-core2-20120124/"&gt;XML Signature Syntax and Processing Version 2.0&lt;/a&gt;, &lt;a href="/TR/2012/CR-xml-c14n2-20120124/"&gt;Canonical XML Version 2.0&lt;/a&gt;, and &lt;a href="/TR/2012/CR-xmldsig-xpath-20120124/"&gt;XML Signature Streaming Profile of XPath 1.0&lt;/a&gt;. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. The XML Security 2.0 specifications are designed to update the XML Signature and Canonical XML specifications to improve performance, streaming support, robustness, and reduced attack surface. &lt;/p&gt; &lt;p&gt;The Working Group has also published a W3C Note: &lt;a href="/TR/2011/WD-xmlsec-rngschema-20110303/"&gt;XML Security RELAX NG Schemas&lt;/a&gt;, a document that provides RELAX NG schemas corresponding to the normative XSD schemas for XML Signature 1.1, XML Encryption 1.1, and related specifications. &lt;/p&gt; &lt;p&gt;To address patent disclosures related to the XML Signature 1.1 and XML Encryption 1.1 specifications, W3C has chartered a &lt;a href="/2011/xmlsec-pag/"&gt;Patent Advisory Group&lt;/a&gt;. Concerns related to XML Signature 1.1 may also apply to XML Signature 2.0. &lt;/p&gt; &lt;p&gt;Learn more about the &lt;a href="http://www.w3.org/Security/"&gt;Security Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/XML/Schema"&gt;XML Schema Working Group&lt;/a&gt; has published Proposed Recommendations of two specifications: &lt;a href="http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/"&gt;W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures&lt;/a&gt;, &lt;a href="http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/"&gt;W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes&lt;/a&gt;. The former specifies the XML Schema Definition Language, which offers facilities for describing the structure and constraining the contents of XML documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in an XML vocabulary and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML document type definitions (DTDs). This specification depends on XML Schema Definition Language 1.1 Part 2: Datatypes, which defines facilities for defining datatypes to be used in XML Schemas as well as other XML specifications. The datatype language, which is itself represented in XML, provides a superset of the capabilities found in XML document type definitions (DTDs) for specifying datatypes on elements and attributes. Comments are welcome through 20 February. Learn more about the &lt;a href="http://www.w3.org/XML/"&gt;Extensible Markup Language (XML) Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/XML/XPPL/"&gt;XML Print and Page Layout Working Group&lt;/a&gt; has published a Working Draft of &lt;a href="http://www.w3.org/TR/2012/WD-xslfo20-20120117/"&gt;Extensible Stylesheet Language (XSL) Version 2.0&lt;/a&gt;. XSL-FO is an XML vocabulary that uses CSS and additional properties for formatting documents to paged media. Learn more about the &lt;a href="http://www.w3.org/XML/"&gt;Extensible Markup Language (XML) Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/Style/CSS/members"&gt;Cascading Style Sheets (CSS) Working Group&lt;/a&gt; has published a Working Draft of &lt;a href="http://www.w3.org/TR/2012/WD-css3-text-20120119/"&gt;CSS Text Level 3&lt;/a&gt;. This CSS3 module defines properties for text manipulation and specifies their processing model. It covers line breaking, justification and alignment, white space handling, text decoration and text transformation. Learn more about the &lt;a href="http://www.w3.org/Style/"&gt;Style Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/2008/webapps/"&gt;Web Applications Working Group&lt;/a&gt; has published a Working Draft of &lt;a href="http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/"&gt;XMLHttpRequest Level 2&lt;/a&gt;. The XMLHttpRequest specification defines an API that provides scripted client functionality for transferring data between a client and a server. Learn more about the &lt;a href="http://www.w3.org/2006/rwc/"&gt;Rich Web Client Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;W3C today published the &lt;a href="http://www.w3.org/2011/09/LinkedData/Report"&gt;final report&lt;/a&gt; of the &lt;a href="http://www.w3.org/2011/09/LinkedData/"&gt;Linked Enterprise Data Workshop&lt;/a&gt;, hosted by W3C on the 6-7 December in Cambridge, MA, USA. This workshop provided a way for the community to meet and discuss some of the challenges when deploying application relying on the &lt;a href="http://www.w3.org/DesignIssues/LinkedData"&gt;principles of Linked Data&lt;/a&gt;. The presentations covered many different topics, ranging from the benefits a set of additional conventions would bring to specific technical issues such as the challenges of dealing with the reality that URLs do change sometimes, as well as the need for a more robust security model, and specific gaps in the current set of standards.&lt;/p&gt; &lt;p&gt;Participants of the Workshop agreed that W3C should create a Working Group to define a "Linked Data Platform"�. This is expected to be an enumeration of specifications which constitute Linked Data, with some small additional specifications to cover specific functionality such as pagination. We anticipate a draft charter will be available in the coming weeks.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/2010/webperf/"&gt;Web Performance Working Group&lt;/a&gt; invites implementation of the Candidate Recommendation of &lt;a href="http://www.w3.org/TR/2012/CR-navigation-timing-20120117/"&gt;Navigation Timing&lt;/a&gt;. User latency is an important quality benchmark for Web Applications. While JavaScript-based mechanisms can provide comprehensive instrumentation for user latency measurements within an application, in many cases, they are unable to provide a complete end-to-end latency picture. To address the need for complete information on user experience, this document introduces the PerformanceTiming interfaces. This interface allows JavaScript mechanisms to provide complete client-side latency measurements within applications. Learn more about the &lt;a href="http://www.w3.org/2006/rwc/"&gt;Rich Web Client Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/Style/CSS/members"&gt;Cascading Style Sheets (CSS) Working Group&lt;/a&gt; has published a Last Call Working Draft of &lt;a href="http://www.w3.org/TR/2012/WD-css3-ui-20120117"&gt;CSS Basic User Interface Module Level 3 (CSS3 UI)&lt;/a&gt;. The Cascading Style Sheets (CSS) is a language for describing the rendering of HTML and XML documents on screen, on paper, in speech, etc. It uses various selectors, properties and values to style basic user interface elements in a document. This specification describes those user interface related selectors, properties and values that are proposed for CSS level 3 to style HTML and XML (including XHTML and XForms). It includes and extends user interface related features from the selectors, properties and values of CSS level 2 revision 1 and Selectors specifications. Comments are welcome through 14 February. Learn more about the &lt;a href="http://www.w3.org/Style/"&gt;Style Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;&lt;a class="imageLink" href="http://www.w3.org/2011/socialbusiness-jam/"&gt; &lt;img src="http://www.w3.org/2011/socialbusiness-jam/images/W3CJamHeroImage.jpg" alt="W3C Jam image"/&gt; &lt;/a&gt; W3C today published the &lt;a href="http://www.w3.org/2011/socialbusiness-jam/report.html"&gt;final report&lt;/a&gt; of the &lt;a href="http://www.w3.org/2011/socialbusiness-jam/"&gt;Social Business Jam&lt;/a&gt;. The report authors recommended starting a W3C &lt;a href="http://www.w3.org/community/socbizcg/"&gt;Social Business Community Group&lt;/a&gt; to evolve social standards around customer-driven use-cases. Participants in the the event, which took place last November using IBM's Collaboration Jam platform, explored how standards around social networking, such as those developed by the &lt;a href="http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/Main_Page"&gt;Federated Social Web XG&lt;/a&gt;, could lead to increased innovation throughout the business cycle. Over 1000 participants discussed topics such as identity management, mobile, attention, business processes, integration, and metrics. W3C invites people to &lt;a href="http://www.w3.org/community/socbizcg/join"&gt;join the Social Business Community Group&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/2002/mmi/"&gt;Multimodal Interaction Working Group&lt;/a&gt; invites implementation of the Candidate Recommendation of &lt;a href="http://www.w3.org/TR/2012/CR-mmi-arch-20120112/"&gt;Multimodal Architecture and Interfaces&lt;/a&gt;. The specification describes a loosely coupled architecture for multimodal user interfaces, which allows for co-resident and distributed implementations, and focuses on the role of markup and scripting, and the use of well defined interfaces between its constituents. Learn more about the &lt;a href="http://www.w3.org/2002/mmi/Activity.html"&gt;Multimodal Interaction Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

&lt;p&gt;The &lt;a href="http://www.w3.org/wiki/Html-data-tf"&gt;HTML Data Task Force&lt;/a&gt; of the &lt;a href="http://www.w3.org/2001/sw/interest/"&gt;Semantic Web Interest Group&lt;/a&gt; has published two documents today:&lt;/p&gt; &lt;ul class="show_items"&gt; &lt;li&gt;The &lt;a href="http://www.w3.org/TR/2012/WD-html-data-guide-20120112/"&gt;HTML Data Guide&lt;/a&gt; aims to help publishers and consumers of HTML data. With several syntaxes (microformats, microdata, RDFa) and vocabularies (schema.org, Dublin Core, microformat vocabularies, etc.) to choose from, it provides guidance on deciding what to choose in a way that meets the publisher's or consumer's needs.&lt;/li&gt; &lt;li&gt; The &lt;a href="http://www.w3.org/TR/2012/WD-microdata-rdf-20120112/"&gt;Microdata to RDF&lt;/a&gt; describes processing rules that may be used to extract RDF from an HTML document containing microdata.&lt;/li&gt; &lt;/ul&gt; &lt;p&gt;Both documents are Working Drafts, with the goal of publishing a final version as Interest Group Notes. Comments and feedbacks are welcome; please send them to the &lt;a href="mailto:public-html-data-tf@w3.org"&gt;public-html-data-tf@w3.org&lt;/a&gt; mailing list.&lt;/p&gt; </content>

by W3C Staff at January 29, 2012 06:00 PM

In this 7 minute video, you will learn the basics of the UITabBarController and how to create one using the Xcode project template.

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.

by Amit Bijlani at January 26, 2012 08:55 PM

Twitter Bootstrap 2.0 will be coming out January 31st. In the mean time, there is a pre-release you can check out and report on any bugs that you find. Twitter Bootstrap is a great HTML and CSS framework that has been gaining a lot of popularity recently. You can check out sites built with bootstrap on the unofficial Built With Bootstrap tumblr.

You can also follow @twbootstrap on Twitter.

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

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

by Jason Seifer at January 26, 2012 02:00 PM

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

by Mat Helme at January 26, 2012 02:00 PM

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.

by Mat Helme at January 25, 2012 08:00 PM

From 31st of March until 17th of April I’ll be once again touring the US. I’ll start and end with conferences, but I’m not quite sure yet what I’m going to do in between and I’m looking for suggestions.

I’ll arrive in Seattle for An Event Apart, on 2 and 3 April, where I’ll pontificate on the touch events and how they’re not the same as mouse events. It’s been a while since I’ve been exposed to so much Apartness, and it’ll be a nice start of my tour.

My tour will end in Orlando on 16 and 17 April, where I’ll speak at the third Breaking Development conference, Mobilism’s American sister conference. The good Breaking Developers have given me the code ORPPK12 for a $100 discount on tickets, and if you register before end of next week you’ll save another $200. Not a bad discount for a top-notch conference.

That leaves me with almost two weeks in-between conferences. I’m fairly certain I’ll be in Toronto on the 10th, and I plan to visit San Francisco and the Valley at some time (duh), but other than that my itinerary is still unclear.

If you’d like me to swing past your city, let me know. Unfortunately I’m not super-wealthy, so I do expect you to pick up my hotel bill, as well as help me out a bit with domestic flights.

Last year I ended up going to San José, Austin, New York, and Albany. I have no idea what this year will bring, but that’s what makes this kind of touring so exciting.

Anyway, I’ll post an update when I have more news.

January 25, 2012 04:23 PM

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

Benefits include:

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

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

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

by Ryan Carson at January 25, 2012 09:58 AM

I have retested the support for the new input types (<input type="number"> and such) in the desktop and mobile browsers.

All in all support has increased slightly since the last time I tested them, although Safari desktop, Chrome, and BlackBerry have seen some decline. Safari and Chrome have mainly done away with badly or buggily implemented types — it’s clear they’re rewriting significant parts of this module.

As to BlackBerry, its decline was a nasty shock to me. Previously it vied with Opera for Best Implementation, but the PlayBook 2 default browser has dropped support for quite a few types and attributes, such as required and pattern.

Quiz

To understand how complicated these new features can be, consider the following quiz question:

I add an <input type="number" step="3"> to the page, and the user enters 11. What should the browser do?

You can try it for yourself at the test page. Don’t forget to submit the form. My Twitter followers gave they following replies:

* This total includes the votes for an error message.

So the desired outcome is unclear. The browsers’ behaviours have been documented on the desktop page.

Purpose

A quick repeat of the underlying purpose of the input types seems in order. In the end, the idea is to not send incorrect values to the server. Thus we can see three purposes:

1. The browser could perform a validation and show an error message and refuse to submit the form when an incorrect value is found.
2. The browser could also restrict the accepted input — for instance by not allowing letters in an <input type="number">.
3. Finally, the browser could also give the user a nice interface — for instance the various date pickers in Opera, BlackBerry, and Safari iOS.

The last purpose is a nice extra. If the browser offers an interface but doesn’t support either validation or input restriction, I judge its support Minimal. It misses the actual point, after all.

Findings

With that said, my findings were the following:

• readonly is still the only universally supported attribute or type.
• IE10’s support is decent, though not great.
• Opera and BlackBerry added support for color.
• Firefox on desktop has added datalists, but its interface is an autosuggest, and not a complete list of options, as IE and Opera show.
• Firefox Mobile, however, has a very nice interface (see screenshot) that I hope other mobile browsers will pick up.
• Firefox Mobile does not show any error messages, though, while Firefox desktop does.
• Chrome dropped support for the date types. That’s curious, because Chrome 10 supported them reasonably well. I can only assume a major re-factoring is going on.
• Safari desktop dropped support for dates, datalist, email, and url. Since they were hideously buggy previously, this makes sense. I assume they’ll reappear.
• Safari on iOS added support for dates, numbers, and ranges. The interface for the range slider is a bit confusing, though.
• Android 3.2, MeeGo and UC support autofocus, but they cleverly don’t pop up the software keyboard, which would be very annoying. As far as I’m concerned this should become a mobile standard.
• Still, poor Android can’t do anything right. Android 3.2 tried to add support for number and range, but the range slider is invisible, while the number type restricts user input only to actual numbers. No negative numbers; no exponents.
• And then BlackBerry, which in my previous round of testing was the best browser. The PlayBook 2 default browser dropped support for required, pattern, email, url, step, and month (though not the other date types). The old BlackBerry Torch (OS6) supported them all fine. I’m not sure what’s going on here, and I hope the PB 2 final version will restore these types.

January 24, 2012 02:45 PM

The separation of structure, presentation and behavior is dead. It has been dead for a while. Still, this golden rule of web design sticks around. It lives on like Elvis and we need to address it.

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.

by Kevin Dees at January 24, 2012 02:00 PM

HTML5 Please is a great resource for determining browser support for many HTML5 and CSS3 Features. Each feature offers a recommendation to either use, not use, use with caution, or use with a fallback. It offers great information like the browser share for each feature, as well as the fallbacks you can use to simulate the feature in incompatible browsers.

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

by Jim Hoskins at January 23, 2012 10:06 PM

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

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

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

by Ryan Carson at January 23, 2012 12:05 PM

After the blackout on Wednesday, it seems that the political tides are shifting against SOPA and the PROTECT IP Act"”as of this writing, there are now more members of Congress in opposition to the bills than in favor. That's good news.

I wil reiterate something I said on Twitter, though: the members of tech community, particularly those who are intimately familiar with the basic protocols of the Internet, need to keep working on ways to counteract SOPA/PIPA. What form that would take, I'm not sure. Maybe a truly distributed DNS system, one that can't be selectively filtered by any one government or other entity. I'm not an expert in the area, so I don't actually know if that's feasible. There's probably a much more clever solution, or better still suite of solutions.

The point is, SOPA and PIPA may soon go down to defeat, but they will return in another form. There is too much money in the hands of those who first drafted these bills, and they're willing to give a fair chunk of that money to those who introduced the bills in Congress. Never mistake winning a battle with winning the war. As someone else observed on Twitter (and I wish I could find their tweet now), the Internet community fought hard against the DMCA, and it's been US law for more than a decade.

By all means, take a moment to applaud the widespread and effective community effort to oppose and (hopefully) defeat bad legislation. When that's done, take notes on what worked and what didn't, and then prepare to fight again and harder. Fill the gap between battles with outreach to your elected representatives and with efforts to educate the non-technical in your life to explain why SOPA/PIPA were and are a bad idea.

Days of action feel great. Months of effort are wearying. But it's only the latter that can slowly and painfully bring about long-term change.

by Eric Meyer at January 20, 2012 02:56 PM

If you haven’t seen Code Racer, you should give it a try. Code Racer is the product of Idea Week at Treehouse. Idea Week is a tradition brought over from Carsonified to Treehouse where the entire team drops what they are doing to work on a completely new project for one week.

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

by Jim Hoskins at January 19, 2012 08:35 PM

The web is rapidly evolving and it seems like the editors just can’t keep up. If you are web developer using Sass, Stylus, CoffeeScript or Haml then CodeKit is for you. The only drawback is that CodeKit is only available for MAC OSX Lion.

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

by Amit Bijlani at January 19, 2012 08:01 PM

In this 8 minute video, you will learn how to install Ruby on both Mac OS X and on Windows. This will let you get IRB up and running and is the basis for running Ruby programs on your own computer.

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.

by Jason Seifer at January 19, 2012 02:00 PM

Popovers are very common within the iPad user interface but you were restricted to the design provided by Apple. With iOS 5 came a little known class called UIPopoverBackgroundView which allows you to provide a custom border and arrow for the popover.

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.

by Amit Bijlani at January 18, 2012 07:27 PM