Developer - Post archive

Getting started with Bootstrap customization and responsive design

Published by | Friday, November 16th, 2012

Recently I’ve been using a really awesome framework called Bootstrap to put small websites together. In this article, I’m going to guide you through the basics of the Bootstrap installation process, and how the Bootstrap framework can be customized for a responsive web design.

The end result of this tutorial will be a custom Bootstrap website (you can see the final website here). If you prefer to skip the basics and get right to the Bootstrap code, you can download the code directly from GitHub.

Why Bootstrap?

Bootstrap is a framework that provides an easy-to-use 12-column grid system for a 940 pixel wide container as well as a fluid layout grid that adjusts to the size of a browser. Included in the framework are customizable, well documented features—such as dropdown menus, buttons, tabs, breadcrumbs, modals, tooltips, and carousels—that can be implemented without any handwritten JavaScript.

Our finished website

What is Windows 8 going to change?

Published by | Friday, October 26th, 2012

The user interface for Windows 8 blurs the line between tablet, desktop, and smartphone. That’s a good thing.

The Microsoft Build conference starts October 30. For a week developers will be exposed to the latest Windows technologies, analysts will write megabytes of blogs, pundits will tweet reactions both pro and con, and the way we experience computers will change in dramatic and obvious ways.

The new Windows 8 interface

For developers and users alike, the Windows 8 interface is an in-your-face change. No longer based around overlapping windows and desktops, information and applications are now presented as colored tiles. It is possible to slip back into the traditional Windows interface where each running application is visually separated with windows that can be dragged on top of each other, hidden, and closed; but most of the time the new Windows looks, and functions, very much like a well-designed webpage.

Opinions are harsh. Windows traditionalists miss familiar icons such as the Start menu, Control Panel, File Explorer, and Close button, and are finding the years they spent deciphering the nuances of utilities to now be irrelevant and useless. Worse, users stumble into the traditional Windows interface, but have no idea how to return to the new tiled interface, and developers find creating applications now requires new ways of programming, use of new interfaces, and new ways of thinking about interacting with users. What was Microsoft thinking?

DOS to Windows, windows to tiles, desktop to phone
In 2011, computer vendors shipped more smartphones than desktop computers further supporting the idea that handheld devices—such as smartphones and tablets—are pushing desktop and laptop computers into obsolescence. Apple and Android are battling for first place, with Microsoft scrambling for a piece of the action. Dell, the king of laptop manufacturers, has lost almost half of its value in eight months. The future is painfully clear, and it looks like a handheld device, or smaller.

Microsoft correctly reasons that making improvements to an interface that depends on a keyboard and mouse is corporate suicide, but what about our former Windows Vista user futilely searching for the Windows Start button? Is there nothing to be done for them?

Short answer: The pain is only temporary.

Long answer: We’ve done this before. New interfaces, like apps or tiles, are simply normal innovation. They’re disruptive, sometimes annoying, and the first iteration is often clumsy, but the process is normal, expected, and necessary. is working on a collection of classes for developers and users of Windows 8. In the early part of 2013, you can expect to see courses that show how to get started with the Windows 8 developer tools, as well as more in-depth training intended to assist with advanced developer questions.

Nobody on Star Trek uses a mouse
Science fiction explores a possible future, and most science fiction computers don’t use keyboards or mice; they use gestures and voice recognition. Our grandchildren will think our computers are quaint.

Personally, I have enough years under my belt to remember the jump from CPM, to DOS, to Windows 3, and the jump from my beloved Apple IIe to Macintosh OS X. Each was a move away from a known paradigm to something better. Everything changed for the traditionalists invested in the existing technology, and boy, did they complain.

But the number of people using the new tools soon outweighed the traditionalists. New users with curiosity about how the system does work, rather than assumptions about how the system should work took over.

Here’s to a lifetime of learning!


Interested in more?
• The full Windows 8 Preview First Look course on
• All operating systems courses on

Suggested courses to watch next:
 Windows 8 Metro App First Look

• Windows 7 Essential Training
 Migrating from Windows XP to Windows 7

Exploring browser animation options: Part three, Canvas

Published by | Saturday, October 6th, 2012

Over the past few weeks my blog posts have been exploring different animation options available in modern browsers. First, I looked at using CSS, and then jQuery. In this article I want to take a look at a third option, Canvas, and talk about some of the advantages and limitations of working with this part of the HTML5 specification.

Green computing starts with your code

Published by | Wednesday, September 26th, 2012

Is a paperless society really an energy savior?

Manufacturing office paper consumes more energy than producing food, and at nearly 8 percent of US energy going to paper, even more than steel. With these statistics in mind, it’s easy to believe a paperless society would conserve massive amounts of energy. Consider: An electronic memo doesn’t consume paper, doesn’t use ink, doesn’t require a printer spinning motors, and doesn’t require a delivery truck. Some bright folks calculated the savings for sending an electronic memo over paper is about .36 kilowatt-hours (kWh), or an energy-spend equivalent to microwaving three potatoes.

The Internet has a carbon footprint

But hold on a minute—that savings assumes an electronic memo uses no electricity, which is false. According to one estimate, moving one megabyte across the Internet costs .006 kWh, or the energy contained in one very small bite of a chocolate chip cookie.

We move a lot of kilowatts across the Internet. Different groups will provide different estimates, but Cisco estimates [CA3] traffic will pass the zettabyte threshold by 2017. No matter how you run the numbers, all those .006 kWh chocolate chip cookie–sized bytes of data have an impact. Google alone used 2,259,998 megawatt-hours (mWh) in 2010. When you’re consuming this statistic, keep in mind 1 mWh can sustain 1,000 homes for one hour. Another interesting tidbit: Google estimates an Internet search consumes one-third of a watt-hour or .0003 kWh (if you’re keeping track in cookie similes, this is about a cookie crumb).

Moving data isn’t the only thing computers do; they also store data. As an example, services such as Amazon EC2 charge by demand based on processor time, and a majority of that payment goes for electricity. According to the Northwest Power and Conservation Council, at this rate these server farms will account for about 10 percent of northwestern electricity by 2030. Code costs money to run. Inefficient code costs more money to run.

Your code is the solution

So why is the content manager for the Developer segment at bringing this up? What does this have to do with programmers? Other than turning off lights and computers, what can we do?

Plenty. Our code drives the microprocessors that use all this power. Our code makes calls to APIs that spin up central processing units (CPUs) that create thermal load that require cooling that devour electricity.

Mobile devices bring this issue into sharp focus. Unnecessary code chews up precious battery life, reducing the time between recharges. Apple banned Adobe Flash from the iPhone because of excessive battery usage. Interestingly, this battery drain seems to be related to code, not hardware. Imagine the difference if Adobe had been able to reduce the power consumed by Flash with more efficient programming.

Tips for writing efficient code

Your office has power-saving features: lights controlled by timers, setback thermostats, and paper recycling. Why not write code with the same intent? Cache data from the server and reduce the number of queries. Optimize SQL calls to produce only the results you need. Once we start looking for ways to reduce load on the Internet, we’ll see many more options.

• Profile your code to reduce unnecessary cycles. In Drew Falkman‘s PHP 5.4 New Features course, profiling is discussed and examples are provided on how to write more efficient code. Take a look at the third movie in chapter one titled Using the High Precision Timer.

• Write closer to the CPU. Instead of writing a mobile web app, consider creating a native app using Objective-C, C#, or Java. Your application will run faster, and require fewer conversations across the Internet. For more guidance, consider checking out Objective-C Essential Training, C# Essential Training, and Java Essential Training.

• Write efficient HTML. Optimizing HTML pages not only improves the performance of your website, but will also reduce the number of hits on the server and the associated load. Look at Google Webmaster Tools, or check out Bill Weinman’s HTML5: Local Storage and Offline Applications in Depth to learn more about ways to store data locally, instead of on servers.

In closing, consider this: Programmers used to fret about available memory when 16 kilobytes of ram was a big deal, and they learned to be efficient. Over time, memory has become cheap and programs have become larger, but now we face an energy shortage. Why not start considering energy conservation to be the next big programming challenge?

Your thoughts?


Exploring browser animation options: Part two, jQuery

Published by | Friday, September 21st, 2012

Animation can be accomplished in many ways with modern browsers. I’m currently working on a series of blog articles that explore some of the browser animation options available. In my last article, I looked at creating animations with CSS3 using keyframes and transitions. In this article, I’ll look at how to use jQuery to animate objects.

jQuery is a JavaScript library for building interactivity into web applications. One feature of jQuery is its ability to animate elements in HTML. This is quite powerful and useful because another feature of jQuery is its focus on remaining as backward compatible with older browsers as possible. This is significant because these two elements together make jQuery one of the most compatible of the animation options.

A good example of how to use jQuery animations can be found on my MexSantos MexSantos project, which is part of a creating Adaptive Website for Multiple Screens course I prepared for

The MexSantos website

If you click on one of the small thumbnails on the MexSantos website, you’ll see an overlay appear into view and then a copy of the photo in a larger view. The overlay animates subtly, but this is typical of the type of animation that jQuery is ideal for. Interface animations are its specialty and it handles them better than many other methods. jQuery uses JavaScript but one of its goals is to write JavaScript that is compatible with older browsers, so compatibility isn’t the problem with jQuery animations. The main issue is that jQuery animations require JavaScript, so unlike CSS they’re useless if the user has turned JavaScript off. This caveat can sometimes create usability concerns.

jQuery performs animations by modifying aspects of items on the page. For example, it can change the opacity of an image over time to make it look like it’s animated. Let’s take a look at the line of JavaScript code that adds the overlay in the MexSantos website:

#overlay {
    background: #000;
    position: fixed;
    width: 100%;
    height: 100%;
    top: 0;
    left: 0;

One of the great things about jQuery is how commands can be chained together to create a sequence of events. In the JavaScript code above, we’ve managed to quickly create a div then assign it an ID of ‘overlay’ and append it to our body tag. To write the code that actually performs the animation, first we hide the element (otherwise animations show up immediately), and then we add a fadein() command. The fadein() method takes whatever the object is normally supposed to look like (based on CSS style sheets) and performs an opacity fade-in.

The CSS for the overlay ID is pretty simple: A black background with a fixed position that takes on the width and height of the entire window.

#overlay { background: #000; position: fixed; width: 100%; height: 100%; top: 0; left: 0; } 

To really understand what jQuery is doing, you need to look at the code as it animates. If you’re using a browser like Google Chrome with a dynamic code view, you should be able to right click on the background of the page and choose inspect element. Once you have inspect element open, make sure you’re in the elements tab and click on one of the thumbnails. Quickly look at the line before the closing tag. It should show the div being added dynamically and an opacity attribute with rapidly changing values.

jQuery rapidly animates the opacity value of our overflow element

The animate() method

There are a lot of other animation methods that can be used in addition to fadeIn(). Of course, where there is a fadeIn(), there logically is a fadeOut() method, but there are also others like slideDown(), and slideToggle(). Once you learn how to use one, the rest are pretty easy to pick up. There is also a generic method called animate() that allows more granular control over how animations are performed. These animation methods usually take parameters and callbacks as well. I’ve created an example that extracts the overlay functionality of the MexSantos website and shows how the generic animate() method can be used to control the CSS in objects.

jQuery Overlay

Here, we start off with an image that has a click event bound to it:


When someone clicks on the image, the fun starts. First, animate this element out of view with the animate() method, which allows you to change any CSS properties you want. For example, rather than just changing the fade, you can change the opacity as well as the position of the object.

//default animation for element
opacity: 0,
top: '+=200'
}, 500);

As part of the process, the animate() method takes in a JSON object that lets you modify CSS settings like the opacity and position of the element. You can also set the amount of time (for example, 500) you’d like the animation to take. jQuery has some predefined constants for animations such as fast and slow. Just like with the MexSantos example, we can add the overlay:

$('<div></div>').attr('id', 'overlay').appendTo('body').delay(300).hide().fadeIn(500);

We’re adding some delays because we want the animation of the image moving out of view to play before our overlay starts showing up. Now we can load the large version of the image:

$('<img>').attr('src',largeimage).attr('id', 'overlayimg').appendTo('#overlay').load();

With the large version of the image added, we need to know what to do once someone has finished looking at the overlay and clicks to return to the menu. We need to bind a click event to the overlay just like we did with the image, use the fadeOut() method to hide the overlay, and remove it from the page:

    $('#overlay').fadeOut('slow', function() {
    }); //fadeOut
}); //overlayclick

Finally, we’ll animate the image back into its original position.

    opacity: 1,
    top: '0'
}, 500);


Animating with jQuery is like buying a car that is a “mechanic’s dream.” You really need to know your way around JavaScript, but there’s a real benefit in the backward compatibility with older browsers you gain. Using jQuery for browser animations is a strong route to take when working with complex interface interaction. Once you learn a few key concepts like binding methods and chaining commands, this type of animation actually becomes quite fun.

If you’re interested in writing code with jQuery, make sure you check out some of our offerings on jQuery animation in the training library.

CSS pre-processors part two: Mixins and nesting

Published by | Monday, August 27th, 2012

In my last article, An Introduction to LESS and Sass pre-processed CSS languages, I wrote about using variables with CSS pre-processors. Having the ability to use variables will save you enough time to justify learning pre-processors, but there are two other features in Sass and LESS that will save you even more time: nesting and mixins.

Sass versus LESS

Pre-processors allow you to code in a language that’s similar to CSS, but with additional features. Most people are on the fence about adding them to their repertoire because there are two competing high-profile standards: LESS and Sass.

I remember having a similar problem a few years ago trying to decide between jQuery mobile and other JavaScript libraries. Sass and LESS are so similar that it almost doesn’t really matter which one you learn. Switching in between them is pretty easy, so ultimately it’s learning about the concepts that matters. Yes, there are some features specific to each language like guarded mixins in LESS and conditionals in Sass, but I imagine that as the languages develop further, they will each keep up with the other.

Pick one

The important thing is what you plan to do with the languages. If you’re planning to use a framework like BootStrap, from Twitter, then it’s a good idea to go with LESS because Boostrap was written with LESS. If you want a nearly identical framework that uses Sass, check out Foundation. Although Sass requires you to install Ruby, you’ll want to use something like CodeKit to manage your pre-processors.

My advice: Pick one framework and get good with it.

Before we start coding, keep in mind that when I’m talking about Sass, I’m speaking of the newer version with an .scss extension. It’s easier to learn for CSS users because it lets you use CSS syntax and style you may already know.


Besides variables, another awesome thing you can do with pre-processors is nesting. Let’s say you’ve developed a simple horizontal nav bar for your site.

<li><a href="#">Home</a></li>
<li><a href="#">About us</a></li>
<li><a href="#">Info</a></li>

Here’s a typical way to write CSS to make this into a nav bar:

ul {
margin: 0;
padding: 0;
font: bold 1em/1.2em Helvetica, Arial;
ul li {
list-style: none;
ul li a {
float: left;
background: #BA0436;
text-decoration: none;
color: white;
display: block;
padding: 10px;
ul li a:hover {
background: #EEC25C;
color: black;

A simple nav bar written with CSS

As your CSS file gets bigger, the number of styles that are children of other styles increases. In either Sass or LESS, you can do the same thing, like this:

ul {
margin: 0;
padding: 0;
font: bold 1em/1.2em Helvetica, Arial;
li {
list-style: none;
a {
float: left;
background: #BA0436;
text-decoration: none;
color: white;
display: block;
padding: 10px;
&:hover {
background: #EEC25C;
color: black;

This way, the li selector is written inside the ul selector and the a selector is inside the li selector as if they were another rule. Notice that because we are using a pseudo-class, I have to add the ampersand (&) before the :hover selector.

Nesting doesn’t necessarily save you a ton of time, but it makes your code cleaner. When coding CSS, designers can sometimes add new rules where they don’t belong: nesting helps you keep everything tidy.

Both Sass and LESS implement mixins the same way, so there’s no need to show you the difference between the two.


If you liked variables, you’re going to love mixins. They are snippets of code you can reuse over and over in your CSS. You can use them with variables to make coding in CSS easier. Let’s take a look at how you would code a simple top-to-bottom gradient using regular CSS.

.mybox {
  background-color: #333745;
  background-image: -webkit-gradient(linear, left top, left bottom, from(#DAEDE2),
  background-image: -webkit-linear-gradient(top, #DAEDE2, #77C4D3);
  background-image: -moz-linear-gradient(top, #DAEDE2, #77C4D3);
  background-image: -o-linear-gradient(top, #DAEDE2, #77C4D3);
  background-image: linear-gradient(to bottom, #DAEDE2, #77C4D3);

To make sure the gradient displays in as many older browsers as possible, we have to include code for different versions of Safari, Google Chrome, Firefox and Opera. It almost makes you want to stop doing gradients in your CSS. We can use variables to simplify this. Let’s try that with a Sass example.

First, we’ll create two variables for the colors somewhere in our .scss file:

$from: #333745;
$to: #77C4D3;

Once we have that, we can modify our gradient to use the variables:

$from: #333745;
$to: #77C4D3;
.mybox {
  background-color: $from;
  background-image: -webkit-gradient(linear, left top, left bottom, from($from), to($to));
  background-image: -webkit-linear-gradient(top, $from, $to);
  background-image: -moz-linear-gradient(top, $from, $to);
  background-image: -o-linear-gradient(top, $from, $to);
  background-image: linear-gradient(to bottom, $from, $to);

Modifying the gradients to use variables works great and it will save you a lot of time. But what if you wanted to reuse this for other declarations? That’s where mixins come in. You can create snippets of code and reuse them. Let’s create a mixin for linear gradients using the code above as a base.

$from: #333745;
$to: #77C4D3;
@mixin lgradient {
  background-color: $from;
  background-image: -webkit-gradient(linear, left top, left bottom, from($from), to($to));
  background-image: -webkit-linear-gradient(top, $from, $to);
  background-image: -moz-linear-gradient(top, $from, $to);
  background-image: -o-linear-gradient(top, $from, $to);
  background-image: linear-gradient(to bottom, $from, $to);

This makes working with gradients more manageable, but it will only work with one set of from/to colors. We can easily improve on this by putting these variables within our mixin. If you know JavaScript, this is like writing a function. Here’s the syntax in Sass.

@mixin lgradient($from: #333745, $to: #77C4D3) {
background-color: $from;
background-image: -webkit-gradient(linear, left top, left bottom, from($from), to($to));
background-image: -webkit-linear-gradient(top, $from, $to);
background-image: -moz-linear-gradient(top, $from, $to);
background-image: -o-linear-gradient(top, $from, $to);
background-image:  linear-gradient(to bottom, $from, $to);

Now, when we want to use our gradient in our box, we can just type the following:

.mybox {
@include lgradient;

Adding this line of code will create the gradient with the default colors, but since they’re variables, you can create any top-to-bottom linear gradient and specify the colors in your .scss file.

.mybox {
@include lgradient(#FCC,#FEE);

Now you have an easier way to create gradients. Let’s check out the code in LESS:

.lgradient(@from, @to) {
background-color: @from;
background-image: -webkit-gradient(linear, left top, left bottom, from(@from),
background-image: -webkit-linear-gradient(top, @from, @to);
background-image: -moz-linear-gradient(top, @from, @to);
background-image: -o-linear-gradient(top, @from, @to);
background-image: linear-gradient(to bottom, @from, @to);
.mybox {

Pretty similar, except that the dollar signs ($) are replaced by @ symbols and there is no mixin keyword. You can see how pre-processors will help you write CSS more efficiently. If you haven’t already taken the plunge, what are you waiting for?

Interested in more?
• All web + interactive courses on
• All courses from Ray Villalobos on

Suggested courses to watch next:
• CSS: Core Concepts
 CSS Fundamentals
 CSS3 First Look
 Managing CSS in Dreamweaver

Tips for getting your kids interested in programming

Published by | Wednesday, July 25th, 2012

It’s summer! It’s July! Your son or daughter has been decompressing from school for nearly a month, and now they’re bored, feisty, and looking for something new. Resourceful parents dig deep into their bag of tricks for something—anything—to keep the son/daughter from bugging their brother/sister. I, personally, like to think of this boredom as a window of opportunity to convert non-productive screen time into a learning experience, or, more specifically, a window of opportunity to spark an interest that may lead young minds toward wanting to know more about the skill of programming.

Young boy typing on keyboard with red computer.

Sure, in the big picture, summer is all about getting outside, playing ball at the park, swimming in the pool, and, more or less, finding new and inventive ways of getting into trouble. Don’t get me wrong—I’m not advocating taking up residence on the couch. What I am suggesting is that along with that physical activity, summer is also a great time to stretch minds.

Programming is a real-world tool that provides context for structured problem-solving, math concepts, and improved study habits. That being said, of course no red-blooded kid is going to willingly dive into something as “boring” as programming. Seriously—video games are a much more amusing way to consume screen time than staring at a bunch of cryptic incantations written in some useless programming language. Are you kidding? Learn programming? Learn ANYTHING? I know kids that would rather cut the lawn than get stuck behind a textbook.

If your kid is the “I’d rather mow the lawn” type, here’s a thought—tell your kid they could amuse and amaze their friends by building their own video game. It’s entirely possible that they may end up creating something like Angry Birds or Farmville.

Image of Angry Birds App in Facebook, used as an example of Facebook gamification.

While your son or daughter's first programming initiative may not be as exciting as Angry Birds, practice makes perfect and the creation of basic Facebook games is a great gateway into the world of programming.

Facebook is a great platform to introduce  programmingahem—writing games. Facebook programming can be done with JavaScript—an extremely useful language to know— and Facebook games can be created for free. Plus, Facebook is something “the kid” will already know about. You’ll just need to supply server access (something Ray Villalobos walks you through in Building Facebook Applications with HTML and JavaScript.)

How to get your kids started

Getting your kids started may end up being the hardest part of this initiative. You’ll need to use your parenting super-powers of persuasion to introduce the idea and fire up their enthusiasm. This should be far easier than convincing them to floss their teeth, but there may still be some resistance. Back in my parenting days, I found it easiest to have this sort of conversation over an ice-cream cone.

“Hey,” I would say, using my nonchalant voice. “I was just reading about Facebook games. Have you heard anything about them?”

My kids would respond positively. Possibly launch off into an enthusiastic dissertation about their latest engagement with cows, birds, or jewels.

“I heard it’s not too difficult to create them yourself,” I would say. “If you’re interested, I think I could dig up some instructions and you could build one. What kind of game would you build?”

…and we’re off to the races.

Of course, this means that you—the parent—also need to follow up and help them get un-stuck at times. I recommend sitting down with them to watch the introduction to Ray’s Building Facebook Applications with HTML and JavaScript course together. Maybe start by building your own game with them so that you develop some empathy. I’d also recommend that you let them build a game on their own, as it can be entirely too easy for a parent to take over the project, leaving the kid on the sidelines. There’s great benefit in letting them control their own destiny, and make their own mistakes. Besides, you’ll be amazed at how fast they pick this stuff up and learn things you probably overlooked.

What to expect, and why it’s ok if their first initiative isn’t epic

To be honest, the first game is going to be pretty simplistic and much less sophisticated than what a wild imagination might hope for. Remember to reassure your kids and remind them that it’s just their first game, and it doesn’t mean they won’t ever write the epic game they envision. To assist your son or daughter’s first attempt, you might want to use some of the sample JavaScript source code for games you’ll find by googling “simple javascript games.” If you use one of those programs, be sure to remember to credit the original author.

Once your son or daughter makes it over the hurdle of the first game, you’ll find their desire to learn more about JavaScript will naturally feed itself. To aid you in your next steps, the training library has a slew of programming courses, ranging from fundamentals of programming all the way to five hours of in-depth JavaScript training.

Don’t be fooled, though—the training videos in the library are only tools to help you encourage your kids to be life-long learners. In the end, you’re the parent with secret ninja skills of persuasion and encouragement. We’re only here to be your trusty sidekick.

If you have kid programming stories, or tips to share with other parents, we’d love to hear your thoughts! Please leave a comment and let us know your story, and keep us updated as you and your son or daughter progress.


Interested in more?
• All developer courses on
• All courses from Ray Villalobos on

Suggested courses to watch next:
• Building Facebook Applications with HTML and JavaScript
• JavaScript Essential Training (2011)
 Practical and Effective JavaScript
• Foundations of Programming: Fundamentals

Building your web development core skills, and adapting a cross-language approach

Published by | Saturday, May 19th, 2012

Mac Keyboard image.

One question I encounter a lot is whether it’s best for a developer to dabble in a lot of new technologies like SASS, Node, and Rails, or if it’s a better route to specialize in a smaller number of technologies to the point of perfection. Sometimes it feels like the vast number of front- and back-end technologies make it impossible to keep up. This feeling can be especially daunting when you’re looking for a job and it seems like potential employers only want to hire Web Sifus who, on top of having mastered both front-end and back-end technologies, also come with design, video editing, and page layout skills. (If you know that person, or if you’ve encountered a job description like this that only wants to hire Superman—comment below.)

Like all extremes, trying to learn too much, and focusing on too little, are both wrong approaches. Plain and simple, trying to keep up with every language and library is impossible. The goal is not to be miserable trying to learn everything, but to focus on your core and then cross train on skills rather than languages.

Building your Core

For a web developer, a good foundational group of skills to start with are:
1. Setting up and managing a server
2. Building a semantic page structure
3. Mastering page styles
4. Building interaction with the front end
5. Using databases to customize a visitor’s experience

It doesn’t matter whether you’re learning PHP, Python, Ruby, or any other  language you prefer. Learning that some problems are better solved by languages on the server and some on the client is essential. In the end, it’s more important to be proficient at solving problems than slightly more fluent in a specific development language.

After building on your core, it’s essential to make sure you approach projects with a cross-language attitude that stays focused on using the languages you’re comfortable with, and also learning to use different technologies when they make the most sense—not because you feel like you “have to.”

Cross-Language Cross-Training

Cross training in web development means that no one language is an island. You almost never use PHP by itself, or try to solve every problem on a page with JavaScript. Sometimes, the best solution is figuring out how you can combine languages together, and how to decide which language is right for the task at hand.

Recently while working on a Facebook application, I noticed that although there is an SDK (Software Development Kit) for PHP and JavaScript, trying to use just one SDK is silly. It’s better to use both since every language has strengths and weaknesses. For me, web development cross training means taking advantage of that balance and using the best tool for the job.

In the latest episode of View Source, I show you how to use HTML, PHP, and jQuery to upload images to a server and display them on a page as they are loaded. This is a good example of cross training, or, using a combination of skills to accomplish a task. In the video, I use HTML to allow people to upload files, then I use PHP to read the files uploaded to a directory, and jQuery to update the page as soon as a new photo is uploaded so the image uploader can see whether the upload was successful.

Remember, balance is critical to any job. Don’t spread yourself too thin, but also don’t limit your learning so you find yourself struggling with cross-language development. Build your core, then work on your cross-training. While this exercise routine won’t bring you any closer to having six-pack abs, it will make you a better problem solver, and a stronger developer, which will bring you two steps closer to landing your dream job.


Interested in more?
• The full View Source weekly series on
• All web + interactive courses on
• All courses from Ray Villalobos on

Suggested courses to watch next:
• Create an HTML5 Video Gallery with jQuery
PHP with MySQL Essential Training
Dreamweaver CS5 with PHP and MySQL