The simple answer is: yes, learn to program.

I believe that everyone should at least learn basic programming skills. Programming is a language like any other, and as the world becomes more and more technical, I’d go as far as to say that in the years to come programming will replace Spanish, French and other languages as a second language in schools. It’ll be more useful, as technology becomes the world’s language.

In Program or Be Programmed: Ten Commands for a Digital Age, Douglass Rushkoff argues that now more than ever it’s time to learn to program: “Understanding programming — either as a real programmer or even, as I’m suggesting, as more of a critical thinker — is the only way to truly know what’s going on in a digital environment, and to make willful choices about the roles we play.”

For those of you who aspire to understand technology — and if you’re reading this then that’s most of you — there’s no better way to do that then to build things. As a builder of software, you see first-hand what goes into making something work. Even those of you who do not aspire to make things for a living will come away with a more critical understanding of the way the world works.

Not only can I build whatever ideas pop into my head, but also, since learning to program, I look at the world in a different light. How so? Well, as a programmer you learn to think about problems both objectively and by taking into account all outcomes. There are only positive outcomes that can come from learning a new skill, and programming is the skill of our future.

The post Should You Learn to Program? appeared first on Treehouse Blog.

The Tools

I have used just about every digital wireframing application on every device known and nothing compares to tangible tools. Applications are entirely too time consuming and I have become infatuated with detail, thus diverting me away from the purpose of being there. Here are my top five tools for wireframing in order.

1. Sharpie + Printer Paper
2. Jumbo Marker + Oversized Craft Paper
3. Dry Erase Marker + Dry Erase Board
4. Chalk + Chalkboard
5. Paint Marker + Wall

You’ll notice a similarity with all of these grouped objects. The utensils are blunt and the surfaces are blank. There is no need for grids, dots or lines. Save that paper for your logo or icons sketches.

The Process

Whether I’m working alone or working in a group, I use the same process. Here is my ten-step process for wireframing success.

Step 1: Write Down Your End Goal

In one or two sentences state your goal with the app. Be as specific and short-winded as possible. This is the most important step as it will determine the app’s direction. If this changes, everything changes. Make sure to nail this down before moving forward. Here are a couple of examples.

Bob’s Bakery Website:
This application will portrait Bob’s Bakery as a fun, connected, brand for everyone to enjoy. The viewer will feel connected and in need of their products.

Mobile Weather App:
This application will provide the weather in the simplest way possible.

From these two examples you can see the applications are completely different. The first is a bakery website and the second is a mobile weather app. However they both have three things in common. They both use emotion to describe the application. Also they don’t use functionality to describe the product. This is really important when creating your app goal. Don’t get hung up on the details and functionality, we’ll be here all day. Use emotion to explain your application. Lastly, they both start off with “This application will…”, this ensures guarantee that your application will exist and acquire these characteristics. By starting this way, you’ve just brought your application to life.

Step 2: List Your Content

I like to refer to this step as puking on the page. I like to take three to ten minutes depending on the project and just write anything and everything you think needs to be in the app. I use sticky notes for this step. This is where features, graphics, copy, video, products, etc… go. Simply make a long list and understand that nothing is wrong, just write it down.

Then once you have a massive list together start organizing it. Categorize everything into sections. They don’t need to have specific titles but certain things will feel better together than others. Simply rearrange your sticky notes.

Step 3: Prioritize Your Content

After you feel you have your notes arranged accordingly, prioritize them by importance. Whatever feels most important goes on top and what feel least important goes on the bottom. Always refer to your main app goal when questioning importance.

Step 4: Turn Your Content into Shapes

We are now ready for our Wireframe tools. Grab your blunt object and approach the blank surface. From your list of prioritized content, start making shapes or blob of where you think this should go on the page. So each group turns into a page. Remember we read left to right, top to bottom. If you’d like, you could place your sticky notes in the areas. If not, it doesn’t matter, just make sure to label it.

Start with your most important categories and then move down the list. If we are dealing with a web application like Bob’s Bakery, never start with a home page layout. That should be the last thing you complete. The home page should be a synopsis of the application, especially if it’s content heavy.

Step 5: Make More Options

Don’t be afraid to make multiple layouts per category section. Maybe it all doesn’t go in the layout, maybe it tiers down. Give yourself options. If it helps to give yourself a time limit, then do it that way. Create a small deadline, say 10 minutes, and just puke wireframes. Pay no attention to detail, simply communicate and document your idea.

Step 6: Narrow Down Your Options

This step works great when doing this in groups. Everyone could make their own layouts and then meet up after 10-15 minutes depending on the project and discuss their options. You will find more often than not, individuals will come up with the same layouts. This immediately flushes out bad UI hence a better UX. By then end of this step you should decide on the direction you want to go in.

Step 7: Document Your Process

Don’t throw anything away just yet. Now we have a bunch of content and wireframes we don’t want to use. Make sure you document them though before getting rid of them. Document each one of your steps and your final layouts before proceeding to the next step. Take photos of the work as they happen.

Step 8: Break & Revisit

At this point we’re ready to stop and take a break. Change your focus for at least 15 minutes before revisiting the project. This could be something like getting a cup of coffee or calling it a day. I personally like to exercise at least once a day to change my thought process. There is something about elevating your heart rate that really alters my focus. It’s almost like a forget about the project. Then when I go back to it, I’m fresh and will immediately know if I or we made the right decision when we narrowed down our options. If something seems off simply look back into your documented process.

Step 9: Create a Final Rough

Again using the same tools recreate your final decided layouts. Spend a little more time on it then your original design. Don’t be bothered with detail just make it more legible. At this point you should have rough final wireframe(s).

Step 10: Get Digital

Now it’s time to crack open an app of your choice and layout your wireframes. This could be Photoshop, Illustrator, Balsamic, Mockingbird, Framer or any other wireframing app. Again, document the process and get ready to start the development process.

Conclusion

By having a clear vision of what you want the app to be, we can easily go through the wireframing process step by step and flush out the unnecessary content and layouts. I strongly encourage completing this ten-step process in a group rather than by yourself. If you are building the app yourself, simply buy your friends lunch and ask them to take part as you value their opinion.

Another valid point I would like to leave with is this. The majority of designers are under the assumption that the constructive process of an app is like that of a painting. You take your time and place every pixel in place, then when you launch the app you think you’re done. This is unfortunately on the contrary, you’ve just begun. Yeah you might you nailed the brand identity, yeah the multi-device functionality is there, but the user experience has just started. Now it’s time to tweak and tweak until it’s this amazing piece of digital nector that truly fulfills your app’s goals.

Great application design happens before the pixels and after launch, everything in between is just a manufactured process.

The post Great Application Design Comes Before the Pixels appeared first on Treehouse Blog.

I have to remind myself that life is short. Anything that isn’t a life experience, time with friends or family, or time spent going for our dreams, should be called into question.

That being said, the little sneaky time-suckers like tweets, texts, emails, notifications, and meetings, always have a way of finding their way back into our routines.

Every few weeks I have to re-assess my time and hit the productivity reset button. Here are a few strategies I use. I hope they can help you in some way.

Identify the Critical 3

It is important to spend the time we do have, accomplishing something of note. It has been my experience that people can rarely do more than three major projects at a time and do them well.

I always stop and make sure that I’m clear on the top three projects or goals that I want to accomplish. This is important because I find that time typically fits into one of three categories:

• core time
• support time
• waste of time

“Core time” means you’re in the zone and you’re actively working, focused on a core task for great work. “Support time” is the necessary emails, tweets, texts, calls and meetings to do your work. “Waste of time” is the unnecessary emails, tweets, texts, calls, articles, Youtube videos and meetings.

In order to have the most “core time” possible, you have to first identify what that time is and what goals that time needs to accomplish. Decide on your three best projects now and set them as the backbone of your productivity.

Know When You Are Your Best

I tend to be my “sharpest” in the early part of the day. This is the time when I need to be writing, coding, and designing (my critical 3). We’re only capable of a few hours of maximum productivity each day and I like to spend that precious time doing the things that are most important to long-term goals.

With carefully planned recovery and downtime throughout the day, I’m still able to be focused and productive, but just not at the levels I am in the morning. The afternoon is good for learning, building relationships, tackling emails and sharing on Twitter.

Knowing when I perform best has been a huge factor for my career. It’s hard to keep the discipline to keep that time sacred, but it’s entirely necessary. Know yourself and identify when you are at your best. I promise it will help you set your best possible routine.

Don’t Be So Accessible

We tend to really care about what people think, and we genuinely want to be someone that can be counted on to be there for our teammates. The problem with this is that there are no boundaries and you’ve left yourself vulnerable to distractions and not getting anything critical done.

In the end, you and your team only truly want one thing: that you get your work done. Educating yourself and the people you work with on how to maximize “core time”, will help you set boundaries and hold your time sacred.

The fact of the matter is that people respect those that command it. Be someone that is disciplined with your time and be sure to let everyone know it. What you do with your time is crucial and we can’t make it up like we tend to try to tell ourselves we can.

Conclusion

I use these points to keep my time in check. It’s a very difficult thing to do because there is so much opportunity out there and so many cool things to watch, read, and discuss.

I hope that these have flipped some light switches in your own mind and that they’ve provided the start of a new productivity strategy for you.

Be smart and disciplined with your time. It will really show by the end of next year.

The post Keeping Your Time in Check appeared first on Treehouse Blog.

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.