It allows us to selectively expose parts of the code to other programs running on our page. This makes our JavaScript code more resilient and easier to maintain.

The post How to Write a Module in JavaScript – Quick Tip appeared first on Treehouse Blog.

He took a minute to talk with expert teacher, Mat Helme, and threw some knowledge bombs at him. Enjoy!

The full interview will be available tomorrow to all Treehouse Gold Members.

The post Tall Tales From A Large Man – Interview with Aaron Draplin appeared first on Treehouse Blog.

In this tutorial I want to demonstrate a really simple HTML/CSS/JS web application building over the YouTube API. This demo will list a number of YouTube channels which you may click and pull out all the latest videos, plus their related metadata such as views and comments. All of this dynamic page content will be handled via jQuery so you do not need to host anything on a web server. Check out my sample demo to get an idea of what we are building.

Live Demo – Download Source Code

Getting Started

I will skip a lot of the boring HTML so that we can focus more deeply on the YouTube response and how we handle this in JavaScript. The most important HTML section you should recognize is the navigation along with the inner videos content div. I have used specific IDs so that we can target each element and check whenever the user clicks a link, then display that content inside #videos.

    <nav id="usersnav">
      <ul>
        <li><a href="#gotreehouse">gotreehouse</a></li>
        <li><a href="#thenextweb">thenextweb</a></li>
        <li><a href="#TEDxTalks">TEDxTalks</a></li>
        <li><a href="#wearechange">wearechange</a></li>
        <li><a href="#RTAmerica">RTAmerica</a></li>
        <li><a href="#G4ZDTechTV2">G4ZDTechTV2</a></li>
        <li><a href="#NovaCrystallisDotCom">NovaCrystallisDotCom</a></li>
      </ul>
    </nav>
    
    <div id="videos">
      <!-- vids go here -->
    </div>

In order for the whole process to work we will need a copy of the latest jQuery library. My demo includes this file from within the ./js/ directory so you won’t need to re-download anything. Also I have kept my custom-written jQuery codes inside the index file instead of moving them to an external JS script. It would obviously be easier to do so when you are running this on a live website, but for my demo it is quicker to study these codes from within the same page.

Pulling Results with jQuery

The first step is to define a set of variables which we need in the script. Then we can handle a click event from the user which is interfacing with any of the navigation links. Each of the anchor elements is using an HREF value containing a hash symbol plus username we need. It is important that we stop this default href from loading by using e.preventDefault() and then pull the value out so we can get the YouTube feed results.

$(function(){
  $('#usersnav ul li a').on('click', function(e){
    e.preventDefault();
    var htmlString  = '<ul id="videoslisting">';
    var channelname = $(this).attr('href').substring(1);
    var ytapiurl    = 'http://gdata.youtube.com/feeds/api/users/'+channelname+'/uploads?alt=json&max-results=10';

The handy JavaScript substring() method will create a new string variable starting from the character marker 1(marker 0 is the first character). This removes our hash symbol so that we can now place the username into a generic API call which looks like this: http://gdata.youtube.com/feeds/api/users/CHANNELNAME/uploads?alt=json&max-results=10

The user’s channel name can be accessed to query YouTube and pull out their latest uploads. I am referencing a max results value of 10 and since we are not using pagination. I have not included any other callback methods, either. JSON is the response type we need so that way it’ll be easier parsing all this content inside jQuery.

Building a Loop

PHP and Rails and other programming languages often use logic loops to iterate through data patterns. While loops, for loops, do loops, and other common ideas are not as strict when you would compare them with JavaScript. However the methods for .parseJSON() and jQuery.each() offer the perfect system for looping through all of these results.

    $.getJSON(ytapiurl, function(data) {
      $.each(data.feed.entry, function(i, item) {                                
        var title    = item['title']['$t'];
        var videoid  = item['id']['$t'];
      
        var pubdate  = item['published']['$t'];
        var fulldate = new Date(pubdate).toLocaleDateString();
      
        var thumbimg = item['media$group']['media$thumbnail'][0]['url'];
        var tinyimg1 = item['media$group']['media$thumbnail'][1]['url'];
        var tinyimg2 = item['media$group']['media$thumbnail'][2]['url'];
        var tinyimg3 = item['media$group']['media$thumbnail'][3]['url'];
      
        var vlink    = item['media$group']['media$content'][0]['url'];
        var ytlink   = item['media$group']['media$player'][0]['url'];
        var numviews = item['yt$statistics']['viewCount'];
        var numcomms = item['gd$comments']['gd$feedLink']['countHint'];
      
        htmlString +='<li class="clearfix"><h2>' + title + '</h2>';
        htmlString +='<div class="videothumb"><a href="' + ytlink + '" target="_blank"><img src="' + thumbimg + '" width="480" height="360"></a></div>';
        htmlString +='<div class="meta"><p>Published on <strong>' + fulldate + '</strong></p><p>Total views: <strong>' + commafy(numviews) + '</strong></p><p>Total comments: <strong>'+ numcomms +'</strong></p><p><a href="'+ ytlink +'" class="external" target="_blank">View on YouTube</a></p><p><a href="'+ vlink +'" class="external" target="_blank">View in Fullscreen</a></p><p><strong>Alternate Thumbnails</strong>:<br><img src="'+ tinyimg1 +'"> <img src="' + tinyimg2 + '"> <img src="'+ tinyimg3 +'"></p></div></li>';
      }); // end each loop
    
      $('#videos').html(htmlString + "</ul>");
    }); // end json parsing

This code block seems very large but the majority of the content is generating variable names. YouTube will return a lot more information than we need so it would be foolish to create an array containing all the keys. Instead we should make new variables strictly for the content which will be used inside the layout, and then we create a final HTML string to return to the browser.

Each variable block will contain an important section of the final display. We will need the video title, original publishing date, the full-size thumbnail along with each of the 3 mini-thumbs, direct video URL, view count, and also the comments count. The HTML is displayed using an unordered list of items which finishes by applying the HTML content into the #videos container. This is easily accomplished by using the jQuery .html() method.

Parsing & Formatting Numbers

One other final point I’d like to bring up is the ability to parse through each view counter. Return data for videos which have over 1000 views will not include the comma between each set of 3 numbers. I found an excellent solution on Stack Overflow written using pure JavaScript. The function name is commafy() which is wrapped around each of the view count numbers. This will check if the digits are higher than 4 and automatically place a comma where it should be.

These codes are wonderful to use in any number of JavaScript solutions. The questions and solutions on Stack Overflow are always helpful with these kinds of matters. I think it is worth noting that you could write a much simpler function using jQuery or handling this method inside the .each() loop. But if everything is kept inside a separate file then you may not worry as much about the syntax or number of lines.

Live Demo – Download Source Code

Final Thoughts

Many developers who are not familiar with JSON should hit Google and read a few articles on the subject. It is basically JavaScript code which is written in a certain way so that the syntax can be read as data-value pairs. YouTube can present JSON data from their server and using jQuery it is possible to organize this data into the page dynamically. I hope this tutorial may prove useful to anybody who has been interested in developing over YouTube’s API, or any API for that matter. Feel free to download a copy of my demo and see if you can implement a similar method elsewhere in your own projects.

The post Developing over the YouTube API with JSON appeared first on Treehouse Blog.

It’s fairly straightforward to make URLs nicer in Rails. I’ll walk you through the process.

Baby Steps

In Rails the models have a method called to_param. This method gets called when you pass a model into a URL helper like:

<%= link_to product.name, product %>

Or:

<%= link_to product.name, product_path(product) %>

By default the to_param returns the id as a String rather than a Fixnum. Under the hood Rails is calling to_s on the id attribute, which allows us to override this with our own string. To do this we define the to_param method.

class Product < ActiveRecord::Base
  attr_accessible :description, :name

  def to_param

  end
end

Within the to_param method, let’s set a string with the id followed by the name separated with a dash.

class Product < ActiveRecord::Base
  attr_accessible :description, :name

  def to_param
    "#{id}-#{name}"
  end
end

This would generate a URL of /products/2015-Hoverboard for a product with the name of “Hoverboard”.

Now what happens in the show action in the ProductsController? The params[:id] is the String of “2015-Hoverboard” and when you do a Product.find(params[:id]) the find method calls to_i. In Ruby when you call to_i on a String it grabs the first part of the String that looks like an integer. So Product.find("2015-Hoverboard") is exactly the same as calling Product.find(2015).

However, there’s an issue with names that contain a space. For example, a product with the name of “Flux Capacitor” would generate /1955-Flux%20Capacitor/, which isn’t very friendly. We should format the names so that we get them all lowercase and replace the spaces with dashes.

We can do that by creating a method called slug. The word slug describes the part of a URL that is made up of human-readable keywords.

class Product < ActiveRecord::Base
  attr_accessible :description, :name

  def slug
    name.downcase.gsub(" ", "-")  
  end

  def to_param
    "#{id}-#{slug}"
  end
end

So as you can see we just downcase the name and then gsub out the spaces with a dash and then swap the name with slug in the to_param.

So now the URLs are /2015-hoverboard and /1955-flux-capacitor.

Much nicer.

Taking it Further

Now we’ve done only a little bit of work and haven’t altered the database or the controller. Let’s say we wanted to ditch the ids completely from the URLs.

We’ll do this by generating a new attribute called slug, and then manually or programmatically update all the existing products to have a slug.

We’ll first need to create and run the migration.

rails g migration AddSlugToProducts slug:string
rake db:migrate

Then update your model to have :slug as an attr_accessible and validate its presence while ditching the slug method from the previous implementation. We can also just return the slug in the to_param method like this:

class Product < ActiveRecord::Base
  attr_accessible :description, :name, :slug

  validates_presence_of :slug

  def to_param
    slug
  end
end

Next fire up your rails console and cycle through each product and update the slug in each existing product.

>> Product.all.each do |product|
?> product.slug = product.name.downcase.gsub(" ", "-")
>> product.save
>> end

Now that we’ve done that, we need to modify the controller. The find method looks up products by the id, so for all instances in your controller where you find(params[:id]) on the @product you’d want to find_by_slug(params[:id]). This is because the :id is defined in the routes.rb, not because it is the :id of the object.

$ rake routes
    ...
    product GET    /products/:id(.:format)      products#show
    ...        

So in the show action in the ProductsController is should look something like this:

def show
  @product = Product.find_by_slug(params[:id])
  respond_to do |format|
    format.html # show.html.erb
    format.json { render json: @product }
  end
end

Depending on how you’re using the model in other actions in your controller, you may need update those too.

You’ll also want to update any forms to include a slug field as this is now required to generate a new model. It’s required because without it you won’t be able to generate a URL or find any existing models.

This implementation of creating clear, human-readable and friendly URLs will yield the urls /products/hoverboard and /products/flux-capacitor, which is exactly what we wanted!

A Small Note on Performance

The id column of databases are normally indexed, if not the first things to be checked and indexed when performance issues occur. Finding by id is a fast method for looking them up. However if you have lots of models it may be worth adding an index on the slug to improve performance.

Here’s what you’d add to a migration:

add_index :products, :slug

Conclusion

Depending on how clean you want your URLs, or how much effort you want to go in to cleaning up existing URLs, either one of these strategies will work for you.

The post Creating Vanity URLs in Rails appeared first on Treehouse Blog.

Here are the links for the week:

Quick ‘n dirty iTunes 11 style scroller – CodePen
http://codepen.io/vaskemaskine/pen/DrdJE

Sly
http://darsa.in/sly/

jQuery.Shapeshift
http://mcpants.github.io/jquery.shapeshift/

Packery
http://packery.metafizzy.co/

Pure CSS Peeling Sticky – CodePen
http://codepen.io/patrickkunka/pen/axEgL

Package Managers: An Introductory Guide For The Uninitiated Front-End Developer – Tech.Pro
http://tech.pro/tutorial/1190/package-managers-an-introductory-guide-for-the-uninitiated-front-end-developer

Niice. A search engine with taste.
http://www.niice.co/

jakiestfu/Snap.js · GitHub
http://github.com/jakiestfu/Snap.js/

The post iTunes Scrolling and Mobile Shelving – Treehouse Show Ep 40 appeared first on Treehouse Blog.

But no matter how much progress I made, I still knew I’d need to find a talented technical co-founder to work with. I’ve been around the block enough times to know that a year of programming wouldn’t make me a CTO. But what I couldn’t have anticipated was that learning to program up to the level I’ve achieved would make finding a technical co-founder ten times easier. Sure, it’s sort of a kick in the face knowing that one day, with any product success, you’ll have to pass the lead to someone more capable than you. But again, the huge consolation is that it’s a lot easier to find someone once you’ve learned to code.

For me, with a prototype in September 2012 and happy customers already in place, that time had come.

Because I’ve asked Mike (my Uncover co-founder) to be candid about it, I can say without a doubt that we’d never have teamed up if I hadn’t spent 2012 learning to code. Mike and I had known each other for five years before we decided to work together. It wasn’t until I was months into learning to code, when he saw my dedication and saw that I’d successfully built a prototype, that he began to entertain the idea.

Even during the first few months of coding, I’d badger Mike about working together over frequent afternoon coffees, but he’d shrug off the idea. He wasn’t looking to be someone’s code monkey. He wanted to work with someone who understood programming, who could contribute, and who had proven that he really wanted to push himself ahead technically. The person Mike would be willing to work with had to build something first.

For Mike it was more than me being able to contribute code to our product. It was about the psychological connection we’d have. There’s a special bond that exists between developers. People who can build product look at what’s built in a different way. “You can code? Welcome to the club.”

Mike welcomed me. He then pushed me. He taught me. He made me a better developer than I could ever have been on my own. And ultimately he agreed to join Uncover as a co-founder because I had proven myself and managed to get into the club.

The post How Learning to Program Got Me A Technical Co-Founder appeared first on Treehouse Blog.

The post Sharing What You Know – Interview with Ben Callahan appeared first on Treehouse Blog.

Creator Kai Brach has clarity of intent and passionate conviction when building each issue and it shows in the final product.

Hey Look, It’s Ryan!

It was really cool to see Ryan in this issue of Offscreen, and to read about how passionate he is about family, life and the mission of Treehouse.

If you’d like to peek inside the life of the man that is leading the future of tech education (we’re not biased or anything), then grabbing a copy of issue #5 would be the perfect way to do it.

Real Interviews You Can Learn From

One of the elements that I appreciate most about Offscreen is that Kai gets to the heart of what makes our internet heroes tick through well-executed and personal interviews.

Anthony Casalena is the Founder and CEO of Squarespace, which he started from his dorm room in 2003. I learned a lot from his interview this issue and I got to see what it was really like in the beginning of such a great product. During the company’s early years, Anthony acted as the sole engineer, designer and support representative for the entire Squarespace platform, allowing for it to be a stable and profitable business without the need for large teams.

Anthony’s interview is just one of the many great interviews that Offscreen consistently delivers issue after issue.

We’re Giving Away 3 Copies

Here’s the deal dear readers of the Treehouse blog. We want to give 3 copies away to the people that will use its information the most.

In the comments, tell us the story of a project that you hope to complete by the end of this year. (It’s important to note that I am “of age” and I can smell B.S. a mile away.) Don’t worry about selling or being overly-clever, just be yourself and let us know what dream you want to build.

I’ll pick the best stories myself and announce the winners via Twitter on next Thursday, May 23rd. I can’t wait to hear about your great ideas!

The post Giveaway: New Offscreen Mag Featuring Ryan Carson appeared first on Treehouse Blog.

It’s really not about us. It’s about you: developers, who are building the most amazing and magical experiences that make those platforms and services come alive.

- Vic Gundotra, Senior Vice President, Engineering

But words, spoken or shown on a giant screen in Moscone Center, are empty unless there are actions to back them up. Fortunately for us, the keynote was a parade of actions taken by Google to make our jobs as developers easier and more enjoyable.

Let’s get the devil’s advocate stuff out of the way first, though. Sure, I understand that the “Don’t Be Evil” corporation has a reputation lately of being a little more, well, evil. Take the reaction to sunsetting Google Reader, for example. Those types of decisions are open for criticism, but as far as developer relations go, Google has a history of taking care of developers and listening to their feedback. That trend continued today with a long list of developer-friendly announcements. (Feel free to continue this discussion in the comments!)

Why Google Loves Web Developers

Though Android was first up in the docket, Google spent plenty of time talking about Chrome and the web. Developers would love to see web technologies become first class citizens for native app development, but that just ain’t happening yet. Google did, however, talk about improvements to Chrome and some new file formats that will help improve the experience of web applications on mobile devices.

First up was support for a few new file formats for compressed images and videos. Google showed side-by-side comparisons of images in JPEG and the more recent WebP format, which is free and supports lossless compression, transparency, and animation. The images looked nearly identical but the WebP file was 31% smaller. (This is currently only supported in the beta version of Chrome for Android.)

Mobile-friendly WebP format will help sites load faster

They also showed two videos simultaneously that compared the standard H.264 versus the VP9 format. The videos were again nearly identical, but the bitrate was much lower for VP9 and the overall file size was nearly a third of the size of the H.264 file.

This is a big deal for web developers because a high speed internet connection on a mobile device is not a given. We need to be aware that users around the world are accessing our content from all sorts of networks, and while speed is certainly an issue, cost is too. Anything that Google or developers can do to reduce file sizes helps to speed things up and keep costs down.

Google has been hard at work improving Chrome on mobile devices, too. Performance increased by 50% in the past year for the mobile version of Chrome, according to their own Octane benchmark.

Why Google Loves Android Developers

It seemed like everyone who took the stage yesterday said “Thank you” to developers. It felt like some real recognition of how developers have contributed to Google’s success by creating such an amazingly rich ecosystem of apps. They announced that over 48 billion apps have been downloaded to date from Google Play, and that more payments have been made to developers in the first four months of this year than all of last year. Revenue per user is 2.5 times what it was last year globally.

The other phrase that was repeated often was “we listened to your feedback”. Many of the new features released have been asked for by the development community, including some really exciting ones like the ability to publish to alpha and beta testers within Google Play, using Google+ circles for authorization. The Google Play Developer Console also offers a new translation service to more easily globalize our apps, and it will analyze apps and give feedback on how they might be improved to make more money from them.

Games! Cross-Platform Games!

Another big change for Android developers is the introduction of Google Play Game Services. This is like Apple’s Game Center that allows easy multiplier gaming in apps, but it is cross-platform, meaning that it will work on Android, iOS, and the web. The Game Services will allow developers to easily hook into multiplayer functionality that includes things like leaderboards and integration with your Google+ circles.

Game Center is pretty slick, but if developers and users adopt this, it could blow Game Center out of the water. There is no technical reason to dictate that you can’t play a multiplier game with any device you choose, and it is very refreshing to see Google provide these types of services.

One IDE to Rule Them All: Android Studio

The biggest announcement in the eyes of many Android developers was the unveiling of a new-ish tool called Android Studio. Since Android’s inception, the officially supported Integrated Development Environment (IDE) has been Eclipse, an open source IDE built in and for Java that frankly has come a long way in the past few years. It has a reputation for being slow, clunky, and buggy, though, and many an experienced Android developer use a more polished and powerful product by JetBrains called IntelliJ IDEA.

Android Studio is a new package based on IntelliJ IDEA. I downloaded the preview and at its core it is the same as using IntelliJ IDEA. It does have some new branded and integrated features that should make developers happy. For example, instead of clunky string resource identifiers, we will now be able to see the actual string values pulled in and displayed in layout files and code, as if we had hard-coded the string. We also will see real-time updates to layout files as we edit them in XML or the Graphical Layout Editor.

Live string resource preview makes code more readable

This early access preview doesn’t have many features that differentiate it from IntelliJ, or Eclipse, for that matter. But as Tor Norbye (an engineer on the Android team) says, “We have big plans for Android Studio.”

Having used both tools, I am excited to see official support move to IntelliJ. I have long defended Eclipse as a robust tool that shows how open source software can be very effective and useful. The support community around Eclipse is large and helpful as any question about an Eclipse bug or oddity on StackOverflow will show. But IntelliJ is the more powerful and feature-rich IDE, and becoming the officially supported tool means that the community of developers using it will grow quite a lot, which means better support for everyone and more voices pushing the envelope for Android development tools.

The Hidden Meaning Behind These Android Updates

In other news for Android developers, there were some exciting new APIs released as well. For location-based apps, there are new APIs regarding a “fused location provider” (which will be better on battery life), geofencing (one of my favorites), and activity recognition, which means you’ll be able to tell if the user is walking, biking, or driving. Google+ sign in was enhanced to allow users to sign in seamlessly across devices, upstream messaging was added to Google Cloud Messaging service, and some new UI features were even snuck in without any fanfare during the keynote.

Dustin Earley from Android and Me wrote a post called “Google updating Android without updating Android is the biggest news out of I/O 2013” that sums the hidden meaning behind all these updates. In it he says, “Google’s answer to fragmentation has been fully realized at Google I/O 2013.” This is good news for developers (and everyone, really). His observation is really astute. The new features today are part of different support libraries like Google Play Services that don’t require a new version of Android for developers to take advantage of them. We can start writing apps right away that make use of the new location APIs, for example, which means we can reach a much wider audience than waiting for the latest version of Android to trickle through the system to end users.

Lightning Round

The rest of these announcements are not necessarily meaningful from a developer perspective, though some are certainly ripe with opportunity for developers, like Google Play for Education:

• Google Play for Education was announced, which looks like a great resource for educators.
• The new Hangouts app is a cross-platform messaging service with apps for the web, Android, and iOS.
• A new Google Play Music: All Access service looks to compete with Spotify.
• Many enhancements were made to how photos are stored and edited in the cloud through Google+.
• Google Now (voice search) was improved with more results, and it’s now available on the desktop version of Chrome.
• Improvements were made to Google Maps to give more real-time, context-aware information.
• There were no hardware announcements except for a special Samsung Galaxy S4 that runs stock Android. It’s cool, but expensive at $649.
• There was no mention at all of Google Glass (though it was in attendance on audience member’s faces).
• Developers still can’t access Google+ through an API. (Don’t you trust us, Google?)

Looking Forward

All in all it was an exciting day for the tech world, and the rest of the world as this technology spreads to developing nations and people who have never used anything like this before. It’s an exciting time to be a developer, and that enthusiasm and excitement showed in everyone who presented, all the way up to one of the top dogs himself, Larry Page:

I think today we’re still just scratching the surface of what’s possible. That’s why I’m so excited … I cannot wait to see what comes next. I got goosebumps while I was watching some of these presentations here.

I cannot wait either. I wonder what will be revealed at WWDC?

The post Why Google Loves Developers appeared first on Treehouse Blog.

Treehouse Illustrator teacher Mat Helme will help you get started saving resolution independent SVG files in this Treehouse Quick Tip.

The post Quick Tip: Saving SVG Files in Adobe Illustrator appeared first on Treehouse Blog.