RSS
 

Archive for the ‘Google Reader’ Category

How to Bulletproof @font-face Web Fonts

10 Oct

Advertise here with BSA


How to Bulletproof @font-face Web Fonts

You’re interviewing for your dream job, and you’re ready to kick some butt. A small group is gathered around a conference phone and some coding exercises, and they’re pulling up your portfolio on a projector so that everyone can review it.

It looks great, except for one thing: All of your beautiful web fonts are gone and have been replaced with… Arial.

No, this isn’t just a bad dream: It actually happened to me recently when I interviewed at a web design company (352 Media Group). It was painful. I ended up getting the job anyway, but the experience made me realize that even following best practices recommended by industry-leading developers such as Paul Irish’s Bulletproof @font-face syntax and in the current situation where there’s much wider browser support for @font-face, web fonts just aren’t foolproof.

Getting them just right on most platforms and browsers takes work. Below, we will discuss some of the common issues with using web fonts.

Web Fonts Aren’t Displaying

The disappearing web font has to do with HTTP response headers.

Firefox and IE treat web fonts a little like JavaScript documents. For security reasons, a website on a different domain generally cannot display a web font that’s been loaded from another domain. (The Mozilla Developer Network has more information on this policy than you’d ever want to know.)

In cases were you want to allow cross-domain access to such files, the server that hosts the files can include an Access-Control-Allow-Origin header in its HTTP responses. This header can specify specific domains that are allowed to access the files, or it can just list an asterisk to let everyone access the files. The Google Font API does the latter, which makes the service available to all websites.

Workaround for Web Servers that Remove Response Headers

On some networks — including, apparently, that of the office where I interviewed — this header is removed before the response makes it to the web browser. Perhaps an overzealous firewall is to blame. As a result, Firefox and IE refuse to render the web fonts.

Chrome and Safari, on the other hand, happily display the fonts anyway.

Unpredictable networks are a fact of life, but luckily there’s a way to address them. You can use the WebFont Loader, a JavaScript tool that was co-developed by Google and TypeKit to fail over to fonts that are hosted elsewhere where necessary.

The code to fail over to local fonts goes inside your <head> tag and looks something like this:

<script>
WebFontConfig = {
  google: { families: ['FontOne', 'FontTwo'] },
    fontinactive: function (fontFamily, fontDescription) {
   //Something went wrong! Let's load our local fonts.
    WebFontConfig = {
      custom: { families: ['FontOne', 'FontTwo'],
      urls: ['font-one.css', 'font-two.css']
    }
  };
  loadFonts();
  }
};

function loadFonts() {
  var wf = document.createElement('script');
  wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
    '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
  wf.type = 'text/javascript';
  wf.async = 'true';
  var s = document.getElementsByTagName('script')[0];
  s.parentNode.insertBefore(wf, s);
}

(function () {
  //Once document is ready, load the fonts.
  loadFonts();
  })();
</script>

If the client is on a network that deletes the Access-Control-Allow-Origin header, her browser will load the font from Google, fail to display it, and then load your locally-hosted font.

This is slower than just loading fonts from Google. Newer versions of Firefox will take a solid three seconds before they give up trying to display the font from Google, but it’s better than no web fonts at all, and it won’t affect users who aren’t on such networks.

Debugging Response Header Issues with Developer Tools

If you ever have to troubleshoot a problem like this, the developer tools in most browsers have a Net panel where you can inspect file requests and the associated headers. For example, for Firefox you can use Firebug and for Google Chrome, there’s Chrome Developer Tools.

Below is a screenshot of response headers using Firebug. As you can see, the Access-Control-Allow-Origin response header’s value is set to *, which means the document is able to be requested and rendered from other websites.

Troubleshooting with VPN Services

VPN services such as TunnelBear are also helpful in troubleshooting these sorts of problems. Because VPNs encrypt all traffic between you and the VPN provider, your local network won’t be able to mess with your headers.

If the site looks fine through the VPN but breaks when you connect without a VPN, it’s likely that there’s a problem with your local network.

Flash of Unstyled Text (on Slow Internet Connections)

A slow connection can result in a flash of unstyled text — what Paul Irish abbreviates as FOUT — while your web fonts load.

By default, Safari, Chrome, and IE 6-8 won’t display text at all until the text’s associated web font loads.

IE9, on the other hand, will display text in a default font while the web font loads — even in compatibility mode.

Firefox 3.5 will do the same, but versions 4 and later will wait three seconds for a font to load. If the font still hasn’t loaded at that point, only then will the browser display unstyled text. A similar "waiting period" is planned for WebKit.

Browser How It Handles Web Font Loading
Safari Won’t display any text until web font loads
Google Chrome Won’t display any text until web font loads
Internet Explorer 8 and below Won’t display any text until web font loads
Internet Explorer 9 Displays default/fallback font until web font loads
Firefox 3.5 and below Displays default/fallback font until web font loads
Firefox 4.0 and up Waits 3 seconds for a font to load

You might get a more noticeable FOUT in cases where you have to fail over to a locally-hosted font, but you can hide unstyled text using the WebFont loader, as we’ll discuss shortly.

It’s easy to miss such behavior on a fast connection. Most web designers are probably not on dial-up, after all.

Not everyone will have the same experience, though: According to a 2010 survey, 50% of broadband users in the US are subscribed to their ISP’s basic service. There are still some towns that have limited or no broadband Internet access.

The National Broadband Map can help you figure out whether your users fall into this group. Users outside of the U.S. may have even flakier connections, or they might have great connections but live far from your server. A recent report noted that the average luxury site takes 16.2 seconds to load in China. What will your users see while this happens?

Simulating a Slow Internet Connection

There are a variety of tools that can simulate a slow connection so that you can see how your users might experience your site. I personally like Sloppy, which is free, runs on all platforms, and (unlike some other tools) requires no command-line geekery.

A few caveats: redirections and absolute links will send you out of Sloppy’s slowed-down environment, and browsers often cache these redirections. To be sure that you’re really getting a slowed-down page, make sure your address bar displays an IP address instead of a domain, and clear your browser’s cache if you’re continually getting redirected to a web page other than the one that you specified in Sloppy.

You can make the FOUT less noticeable in the same way that you’d tackle other web performance problems: Compress files using gzip, ask browsers to cache the files far into the future, only request the versions of the fonts that you really need, etc. Some delay is inevitable, though.

The WebFont Loader can help here, too. The script applies a CSS class called wf-loading to text for which web fonts haven’t loaded yet, and you can use this class to force browsers to hide or show unstyled text while web fonts load.

You could even get really granular. Maybe your logo uses a web font, so you don’t want it to display at all until the font has loaded, but want the content area to display in Arial while web fonts load.

What’s best for your site depends on how you use web fonts, how different the fonts are from system fonts, and how fast you expect your users’ connections to be.

Web Fonts Render Inconsistently on Different Operating Systems

In addition to issues with varied connections and browsers, it’s also important to consider how fonts are rendered across operating systems.

Mac OS and Windows have fundamentally different philosophies when it comes to rendering text. Mac OS uses anti-aliasing to smooth text, while Windows Vista and 7 use a technology called ClearType to render more detailed text. (Read more about ClearType here.)

Windows Font Rendering

Windows XP doesn’t do either (at least by default), and Linux might do any number of things depending on how it’s configured.

Windows also has two different rendering modes: the newer DirectWrite and the older GDI. The two modes can produce substantially different results.

IE9 and Firefox use DirectWrite, and they can use hardware acceleration to render pages. If hardware acceleration isn’t available or has been turned off, fonts don’t look quite as smooth in these browsers.

Chrome uses GDI, and Firefox 7 is slated to use GDI for common fonts such as Arial.

Safari actually lets you switch between Windows-style rendering and Mac OS-style smoothing — see the "font smoothing" option in the "Appearance" section of the Safari preferences dialog.

Windows Standard uses GDI, while "Light," "Medium," and "Strong" mimic Mac OS’s font rendering. Try toggling between Windows Standard and Medium, and you’ll see that the font heights switch back and forth. The takeaway here is that the size of text can vary, so it can’t be relied on to exactly position other elements.

Another variable on Windows is ClearType, which takes advantage of the fact that pixels on LCD screens are comprised of red, green, and blue vertical bars. It treats these bars as narrow pixels, allowing Windows to display more detail in text.

At best, ClearType makes text sharper and more readable. At worst, it creates colored "halos" around text — including your lovely web fonts. What you see depends largely on whether you’ve used the "Adjust ClearType Text" tool to configure ClearType for your display. If the software isn’t configured properly, it can actually make text harder to read.

Mac OS Font Rendering

It’s worth noting, of course, that not everyone is wild about Apple’s font rendering either; some Windows users argue that Mac OS sacrifices readability for the sake of making text prettier.

Test in Different Operating Systems

The differences in how operating systems render fonts mean that it’s worth testing your site on two different platforms.

If you’re a Windows user, it’s useful to test your site on Mac OS once in a while (or at least try Safari’s font smoothing on Windows).

If you’re a Mac OS user, you probably already have a copy of Windows somewhere so that you can test on IE. It’s worth trying WebKit or Firefox on Windows so that you can see how different rendering modes affect your site.

It might be tempting to sidestep this whole process and use Cufón to render fonts as vector images, which are then smoothed in much the same way as text on Mac OS is.

It might be equally tempting to use a CSS tweak to disable ClearType in older versions of IE. The problem is that doing so violates users’ expectations and ignores their preferences.

The user may have already configured ClearType or other settings to her liking, and she likely expects text in web pages to look the same as text in a word processor or dialog box. (It’s also worth noting that web fonts are faster than Cufón, particularly when you’re working with large amounts of text.)

Conclusion

It’s difficult to completely account for all situations, when it comes to web fonts. The best we can do is make sure we implement safeguards and fallback mechanisms for the less-than-ideal web browsing scenario.

It’s inevitable: Fonts will look different across browsers and operating systems, and they will perform differently across various connections. This is okay (even good)!

With a little testing and tweaking, you can accommodate users on broadband and dial-up, Macs and PCs, corporate networks and coffee shop Wi-Fi.

Related Content

About the Author

Ryan DeBeasi is an interactive designer at the web design company 352 Media Group, which offers custom web design and development for large corporations and small business web design. He’s passionate about front-end development, user experience and writing. His portfolio no longer breaks on corporate networks. Follow him on Twitter: @RyanDeBeasi.

 
 

What I Learned From Steve Jobs

08 Oct

Many people have explained what one can learn from Steve Jobs. But few, if any, of these people have been inside the tent and experienced first hand what it was like to work with him. I don’t want any lessons to be lost or forgotten, so here is my list of the top twelve lessons that I learned from Steve Jobs.

  1. Experts are clueless.

    Experts—journalists, analysts, consultants, bankers, and gurus can’t “do” so they “advise.” They can tell you what is wrong with your product, but they cannot make a great one. They can tell you how to sell something, but they cannot sell it themselves. They can tell you how to create great teams, but they only manage a secretary. For example, the experts told us that the two biggest shortcomings of Macintosh in the mid 1980s was the lack of a daisy-wheel printer driver and Lotus 1-2-3; another advice gem from the experts was to buy Compaq. Hear what experts say, but don’t always listen to them.

  2. Customers cannot tell you what they need.

    “Apple market research” is an oxymoron. The Apple focus group was the right hemisphere of Steve’s brain talking to the left one. If you ask customers what they want, they will tell you, “Better, faster, and cheaper”—that is, better sameness, not revolutionary change. They can only describe their desires in terms of what they are already using—around the time of the introduction of Macintosh, all people said they wanted was better, faster, and cheaper MS-DOS machines. The richest vein for tech startups is creating the product that you want to use—that’s what Steve and Woz did.

  3. Jump to the next curve.

    Big wins happen when you go beyond better sameness. The best daisy-wheel printer companies were introducing new fonts in more sizes. Apple introduced the next curve: laser printing. Think of ice harvesters, ice factories, and refrigerator companies. Ice 1.0, 2.0, and 3.0. Are you still harvesting ice during the winter from a frozen pond?
  4. The biggest challenges beget best work.

    I lived in fear that Steve would tell me that I, or my work, was crap. In public. This fear was a big challenge. Competing with IBM and then Microsoft was a big challenge. Changing the world was a big challenge. I, and Apple employees before me and after me, did their best work because we had to do our best work to meet the big challenges.

  5. Design counts.

    Steve drove people nuts with his design demands—some shades of black weren’t black enough. Mere mortals think that black is black, and that a trash can is a trash can. Steve was such a perfectionist—a perfectionist Beyond: Thunderdome—and lo and behold he was right: some people care about design and many people at least sense it. Maybe not everyone, but the important ones.

  6. You can’t go wrong with big graphics and big fonts.

    Take a look at Steve’s slides. The font is sixty points. There’s usually one big screenshot or graphic. Look at other tech speaker’s slides—even the ones who have seen Steve in action. The font is eight points, and there are no graphics. So many people say that Steve was the world’s greatest product introduction guy..don’t you wonder why more people don’t copy his style?

  7. Changing your mind is a sign of intelligence.

    When Apple first shipped the iPhone there was no such thing as apps. Apps, Steve decreed, were a bad thing because you never know what they could be doing to your phone. Safari web apps were the way to go until six months later when Steve decided, or someone convinced Steve, that apps were the way to go—but of course. Duh! Apple came a long way in a short time from Safari web apps to “there’s an app for that.”

  8. “Value” is different from “price.”

    Woe unto you if you decide everything based on price. Even more woe unto you if you compete solely on price. Price is not all that matters—what is important, at least to some people, is value. And value takes into account training, support, and the intrinsic joy of using the best tool that’s made. It’s pretty safe to say that no one buys Apple products because of their low price.

  9. A players hire A+ players.

    Actually, Steve believed that A players hire A players—that is people who are as good as they are. I refined this slightly—my theory is that A players hire people even better than themselves. It’s clear, though, that B players hire C players so they can feel superior to them, and C players hire D players. If you start hiring B players, expect what Steve called “the bozo explosion” to happen in your organization.

  10. Real CEOs demo.

    Steve Jobs could demo a pod, pad, phone, and Mac two to three times a year with millions of people watching, why is it that many CEOs call upon their vice-president of engineering to do a product demo? Maybe it’s to show that there’s a team effort in play. Maybe. It’s more likely that the CEO doesn’t understand what his/her company is making well enough to explain it. How pathetic is that?

  11. Real CEOs ship.

    For all his perfectionism, Steve could ship. Maybe the product wasn’t perfect every time, but it was almost always great enough to go. The lesson is that Steve wasn’t tinkering for the sake of tinkering—he had a goal: shipping and achieving worldwide domination of existing markets or creation of new markets. Apple is an engineering-centric company, not a research-centric one. Which would you rather be: Apple or Xerox PARC?

  12. Marketing boils down to providing unique value. Think of a 2 x 2 matrix. The vertical axis measures how your product differs from the competition. The horizontal axis measures the value of your product. Bottom right: valuable but not unique—you’ll have to compete on price. Top left: unique but not valuable—you’ll own a market that doesn’t exist. Bottom left: not unique and not value—you’re a bozo. Top right: unique and valuable—this is where you make margin, money, and history. For example, the iPod was unique and valuable because it was the only way to legally, inexpensively, and easily download music from the six biggest record labels.

Bonus: Some things need to be believed to be seen. When you are jumping curves, defying/ignoring the experts, facing off against big challenges, obsessing about design, and focusing on unique value, you will need to convince people to believe in what you are doing in order to see your efforts come to fruition. People needed to believe in Macintosh to see it become real. Ditto for iPod, iPhone, and iPad. Not everyone will believe—that’s okay. But the starting point of changing the world is changing a few minds. This is the greatest lesson of all that I learned from Steve.

 
 

Chrome Remote Desktop – Access Any Computer Remotely Using Google Chrome

08 Oct

Chrome Remote Desktop BETA is fully cross-platform, extension to connect any two computers that have a Chrome browser, including Windows, Linux, Mac and Chromebooks.

Sounds awesome, right?

“Chrome Remote Desktop BETA is the first installment on a capability allowing users to remotely access another computer through the Chrome browser or a Chromebook.

The goal of this beta release is to demonstrate the core Chrome Remoting technology and get feedback from users. This version enables users to share with or get access to another computer by providing a one-time authentication code. Access is given only to the specific person the user identifies for one time only, and the sharing session is fully secured. One potential use of this version is the remote IT helpdesk case. The helpdesk can use the Chrome Remote Desktop BETA to help another user, while conversely a user can receive help by setting up a sharing session without leaving their desk. Additional use cases such as being able to access your own computer remotely are coming soon.”

That’s how the team explains the new beta release of this remote desktop feature. Oh, btw, this extension is from the Chromium team, the people behind the browser and OS.

They have been developing this feature for a long time. That explains a lot, especially when most other features make it to stable release in short span of time, comparing to other browsers.

This feature will give a tough competition to those free remote access services available in the market now. Watch out teamviwer! Talking of that,  do you think Corporate IT will block Chrome or this feature because of data security concerns?

Works on Chromebooks Too!

During the future stages of development, this extension or this feature will be a hi-light on Chromebook, answering the criticism of not being able to do anything that a traditional PC does. This may not be a full blown solution, and Chromebooks are not aiming to be a 100% replacement for your traditional PC as of now. However, this tool will be handy for anyone who owns a Chromebook.

Agree, Chromies?

Install this Extension From Here.

DOWNLOAD YOUR FREE EBOOK - 100 Tips for Chrome, Chrome OS and ChromeBook users ! Click Here.
Chrome Remote Desktop – Access Any Computer Remotely Using Google Chrome is a post from: Chrome Story - Google Chrome OS Tips Blog

Related posts:

  1. Remoting = “Allow Remote Connections To This Computer”
  2. Chrome Gets “Remote Debugging” On It’s Developer Tools
  3. Google Will Partner With RealVNC To Remote Access in Chrome And Chrome OS

 
 

Quick Tip – jQuery Newbs: Stop Jumping in the Pool

07 Oct

As editor of Nettuts+, I get to review a lot of code from tutorial submissions. Despite the fact that jQuery has been available for years now, there is still one frequent mistake that I see more than anything else.


Example #1

Consider the following bit of code:

$('.nav a').click(function() {
  $(this).hide();
  $(this).css('color', 'red');
  $(this).show();

  alert('something else');

  $(this).hide();

  return false;
});

The code above is overly complicated for a variety of reasons. Don’t worry over what the code actually does (it’s gibberish). Instead, I want you to look at all of those references to $(this).

Think of the DOM as a pool.

Think of the DOM as a pool. Remember when you were a kid, and would dive into the pool for coins, while your parents acted like they were watching? That will be our real-world comparision.

Every time you use $('.someClass'), jQuery jumps into the pool (DOM), and searches for that coin (or nodes). So, when you reference it multiple times within a function, that’s a lot of diving. Or, to cut the real-world comparison, it’s wasteful and unncessary. Why call upon jQuery if you don’t require it? You should perform what we call “caching.”

$('.nav a').click(function(e) {
   var anchor = $(this);

   anchor
      .hide()
     .css('color', 'red')
     .show();

   alert('something else');

   anchor.hide();

   e.preventDefault();

});

This is much cleaner. While modern browser engines are incredibly fast these days, and will make up for your poor coding as best as possible, you should still strive to write efficient code, and keep from wasting all that energy jumping in the pool. Now, technically, if you pass jQuery a DOM node, like this, it doesn’t re-query the DOM. It simply returns a jQuery object.

Just because the performance difference between the two will honestly be negligible, we write clean code for ourselves.

Example 2

Let’s consider a slightly more complicated example: tabs.

$('.tabs li').css('position', 'relative');

$('.tabs li').click(function() {
   $('.tabs li').removeClass('active');
   $(this).addClass('active');
   $(this).load('someHref', function() {} ); // example
   $(this).css('top', '1px');
});

This code is all over the place. It’s ugly, and inefficient. Fix number one is to get rid of all that CSS. You’d only place styling in your JavaScript if the values were created dynamically. For example, if you need to calculate the precise location an element should be on the screen, you could use .css('left', calculatedValue). In this case, it can all be exported to an external stylesheet. That leaves us with:

$('.tabs li').click(function() {
   $('.tabs li').removeClass('active');
   $(this).load('someHref', function() {} ); // example
   $(this).addClass('active');
});

Next, again, why do we keep querying the DOM for .tabs li and $(this)? Stop jumping in the pool. Let’s “cache” the location of .tabs li.

var tabs = $('.tabs li');

tabs.click(function() {
   tabs.removeClass('active');
   $(this).load('someHref', function() {} ); // example
   $(this).addClass('active');
});

Better, but we’re still calling $(this) twice, which isn’t a huge deal. But, from my experiences, if you don’t nip it in the bud early, this number quickly increases.

var tabs = $('.tabs li');

tabs.click(function() {
   var tab = $(this);
   tabs.removeClass('active');
   tab.addClass('active')
     .load('someHref', function() {} ); // example
});

Filtering

Another (slightly less optimized) option would be to use filtering.

var tabs = $('.tabs li');

tabs.click(function() {
   tabs.removeClass('active')
       .filter(this)
       .addClass('active')
       .load('someHref', function() {} ); // example
});

The difference in this case, is that, rather than referencing $(this), we’re using the filter() method to reduce the collection of list items down to only the one that was clicked.


What You Should Take Away

Yes, the world will not end if you reference $('.tabs) several times within a function. JavaScript engines are super fast these days. If you were to test the performance of doing so thousands of times, the difference in execution might be a couple hundred milliseconds. But still, the question remains: why would you?

Sometimes, when we use massive abstractions like jQuery, it’s easy forget that $('.tabs') is an actual function that runs a good bit of code. It should also be noted that these concepts apply to JavaScript in general – not just jQuery.

Use the caching techniques described above to write cleaner code…for yourself.

 
 

Quick Tip – jQuery Newbs: Stop Jumping in the Pool

07 Oct

As editor of Nettuts+, I get to review a lot of code from tutorial submissions. Despite the fact that jQuery has been available for years now, there is still one frequent mistake that I see more than anything else.


Example #1

Consider the following bit of code:

$('.nav a').click(function() {
  $(this).hide();
  $(this).css('color', 'red');
  $(this).show();

  alert('something else');

  $(this).hide();

  return false;
});

The code above is overly complicated for a variety of reasons. Don’t worry over what the code actually does (it’s gibberish). Instead, I want you to look at all of those references to $(this).

Think of the DOM as a pool.

Think of the DOM as a pool. Remember when you were a kid, and would dive into the pool for coins, while your parents acted like they were watching? That will be our real-world comparision.

Every time you use $('.someClass'), jQuery jumps into the pool (DOM), and searches for that coin (or nodes). So, when you reference it multiple times within a function, that’s a lot of diving. Or, to cut the real-world comparison, it’s wasteful and unncessary. Why call upon jQuery if you don’t require it? You should perform what we call “caching.”

$('.nav a').click(function(e) {
   var anchor = $(this);

   anchor
      .hide()
     .css('color', 'red')
     .show();

   alert('something else');

   anchor.hide();

   e.preventDefault();

});

This is much cleaner. While modern browser engines are incredibly fast these days, and will make up for your poor coding as best as possible, you should still strive to write efficient code, and keep from wasting all that energy jumping in the pool. Now, technically, if you pass jQuery a DOM node, like this, it doesn’t re-query the DOM. It simply returns a jQuery object.

Just because the performance difference between the two will honestly be negligible, we write clean code for ourselves.

Example 2

Let’s consider a slightly more complicated example: tabs.

$('.tabs li').css('position', 'relative');

$('.tabs li').click(function() {
   $('.tabs li').removeClass('active');
   $(this).addClass('active');
   $(this).load('someHref', function() {} ); // example
   $(this).css('top', '1px');
});

This code is all over the place. It’s ugly, and inefficient. Fix number one is to get rid of all that CSS. You’d only place styling in your JavaScript if the values were created dynamically. For example, if you need to calculate the precise location an element should be on the screen, you could use .css('left', calculatedValue). In this case, it can all be exported to an external stylesheet. That leaves us with:

$('.tabs li').click(function() {
   $('.tabs li').removeClass('active');
   $(this).load('someHref', function() {} ); // example
   $(this).addClass('active');
});

Next, again, why do we keep querying the DOM for .tabs li and $(this)? Stop jumping in the pool. Let’s “cache” the location of .tabs li.

var tabs = $('.tabs li');

tabs.click(function() {
   tabs.removeClass('active');
   $(this).load('someHref', function() {} ); // example
   $(this).addClass('active');
});

Better, but we’re still calling $(this) twice, which isn’t a huge deal. But, from my experiences, if you don’t nip it in the bud early, this number quickly increases.

var tabs = $('.tabs li');

tabs.click(function() {
   var tab = $(this);
   tabs.removeClass('active');
   tab.addClass('active')
     .load('someHref', function() {} ); // example
});

Filtering

Another (slightly less optimized) option would be to use filtering.

var tabs = $('.tabs li');

tabs.click(function() {
   tabs.removeClass('active')
       .filter(this)
       .addClass('active')
       .load('someHref', function() {} ); // example
});

The difference in this case, is that, rather than referencing $(this), we’re using the filter() method to reduce the collection of list items down to only the one that was clicked.


What You Should Take Away

Yes, the world will not end if you reference $('.tabs) several times within a function. JavaScript engines are super fast these days. If you were to test the performance of doing so thousands of times, the difference in execution might be a couple hundred milliseconds. But still, the question remains: why would you?

Sometimes, when we use massive abstractions like jQuery, it’s easy forget that $('.tabs') is an actual function that runs a good bit of code. It should also be noted that these concepts apply to JavaScript in general – not just jQuery.

Use the caching techniques described above to write cleaner code…for yourself.

 
 

The U.S. Now Uses More Corn For Fuel Than For Feed

07 Oct

For every 10 ears of corn that are grown in the United States today, only 2 are consumed directly by humans as food. The remaining 8 are used in almost equal shares for animal feed and for ethanol . And, for the 12 months from August 2011 to 2012, the U.S. biofuels industry used more corn for fuel than domestic farmers did for livestock feed - a first for the industry. This significant milestone in the shifting balance between crops for food versus fuel shows the impact of government subsidies for the biofuels industry . And, it could represent a tipping point in the conflict between food and fuel demand in the future.

Over the past year, U.S. farmers used 5 billion bushels of corn for animal feed and residual demand.  During the time timeframe, the nation used more than 5.05 billion bushels of corn to fill its gas tanks. And, while some of the corn used to produce these biofuels will be returned to the food supply (as animal feed and corn oil), a large proportion of this corn will be solely dedicated to our gas tanks.

[More]
 
 

10 Web-based Sandbox Tools for Testing Your Code Snippets

07 Oct

Advertise here with BSA


10 Web-based Sandbox Tools for Testing Your Code Snippets

One of the greatest benefits the Internet provides web developers is the ability to share and collaborate with other professionals. When you’ve hit a coding roadblock, you can reach out on your social networks to see if your friends can give you a hand.

When you need to debug, experiment with, and share short code snippets, sandboxing tools are immensely useful.

Why use a web-based sandbox tool instead of a testing server or a local web server stack like XAMMP or WAMP? Not having to set up and save HTML, CSS and JavaScript documents simply to test and debug small code snippets, being able to back up your code snippets remotely, and the capability of quickly linking to and showing off your work (which many of these tools can do) are the major reasons you’d want to use them.

In this article, you’ll find some of the best free code sandboxing tools for testing, debugging and/or sharing your code.

Common Features

Though each tool in the list has its own unique features that might make one of them more appealing than another, you’ll find these general features in most of them:

  • Simple and optimized for snippets: these tools aren’t meant to be full web-based IDEs/source code editors (like the Amy Editor and Kodingen)
  • Web-based: Can run in the browser without having to install any software
  • Free: You can use these tools without paying a cent, and many are even open source
  • Preview pane: Allows you to see how your code will render
  • Runs front-end/client-side code: Can, at the very least, run HTML, CSS and/or JavaScript
  • Saving capabilities: Most tools included allow you to download your code and/or save it on-site
  • Sharing capabilities: Most tools below are designed with sharing and collaboration in mind

Let’s look at some top-notch, free sandboxing tools and, for each of them, we’ll discuss some notably unique features they have, to help you make an informed decision on which one is right for you.

1. Tinkerbin

Tinkerbin sandbox tool

Created by web development agency Sinefunc, Tinkerbin is a relatively new code playground that can run HTML, CSS and JavaScript, as well as CSS and JavaScript abstraction languages/metalanguages like SASS and CoffeeScript. It has keyboard shortcuts that conveniently allow you to navigate efficiently between tabs and code panes. The auto-updating preview pane is a nice feature that displays your work as you’re coding.

2. JS Bin

JS Bin sandbox tool

This open source sandbox tool by developer Remy Sharp is an excellent JavaScript/HTML code-testing tool. It has the option for live/real-time preview and the ability to reference (include) popular open source libraries like jQuery, MooTools, YUI and Modernizr. You can grab JS Bin’s source on GitHub if you’d like to use the tool locally. View documentation, tips and tutorials for this tool on JS Bin’s very own Tumblr blog.

3. JS Fiddle

JS Fiddle sandbox tool

JS Fiddle is a free sandbox tool for HTML, CSS and JS that has a wonderful set of features, like the ability to reference popular JS libraries/frameworks like jQuery, YUI and MooTools and an Ajax-request-testing functionality for simulating asynchronous calls for your code. There’s a command for running JSLint that can check your JavaScript for code quality and the "Tidy Up" code-formatting command for re-indenting your code. The source code of this open source web tool is available on GitHub.

4. CSSDesk

CSSDesk sandbox tool

This online CSS/HTML sandbox tool is a slick way of testing snippets of your style sheet and markup. You have the option of changing the background of the preview pane, which is useful when you have a hard time scoping out the outcome of your CSS/HTML work due to low foreground/background contrast or for seeing how your work looks on different types of backgrounds. You can also maximize the screen viewing size of the preview pane by hiding the HTML and CSS code panes.

5. Pastebin.me

Pastebin.me sandbox tool

A tool created by developer and entrepreneur Dale Harvey, Pastebin.me is a simple and clutter-free HTML/JS open source sandbox tool. The code pane flexibly resizes depending on your browser’s viewport, which is especially awesome when you’re using a widescreen monitor. It has three useful templates ("HTML", "JavaScript" and "jQuery") for instantly auto-populating the code pane with default HTML tags.

6. jsdo.it

jsdo.it sandbox tool

This sandboxing tool emphasizes on community engagement and collaboration, with features that easily give you the opportunity to share your code on your social networks as well as within the site. It has a slick interface, an auto-updating preview pane and the ability to include open source JS libraries. One unique feature is the "Smart phone preview" command that opens a new browser window with the viewport sized equivalently to mobile phones. This tool requires you to sign up and be logged-in.

7. Tryit Editor Instant

Tryit Editor Instant sandbox tool

This free and no-frills tool allows you to rapidly test your HTML markup. If you don’t need all the features that the above tools offer and simply want one for quickly testing HTML, check this one out. It auto-updates the preview pane whenever you change something in the coding pane. It doesn’t have any saving and collaboration features, so this one is more of a personal tool.

8. PractiCode

PractiCode sandbox tool

The PractiCode online code editor is a supplementary tool for Landofcode.com’s educational web design materials. Though it’s meant to be used alongside their guides and tutorials for practicing and testing code snippets while you’re reading their material, it can be used as a sandboxing tool as well. This online tool can render HTML, CSS and VBScript.

9. JavaScript Sandbox

JavaScript Sandbox sandbox

Are you looking for a dead-simple tool for testing your JavaScript code snippets? Look no further than the JavaScript Sandbox, which is a very austere tool when pitted against the other web-based tools already mentioned (such as Tinkerbin and JS Bin). However, to some, its uncomplicated nature may just be the thing that’s most attractive about this tool.

10. Google Code Playground

Google Code Playground sandbox tool

Google offers web developers plenty of free APIs and services for things such as web fonts, Google Analytics and a content distribution network (CDN) for popular, open source JavaScript libraries (such as jQuery). Google Code Playground is a sandbox tool that gives you the ability to test and experiment with Google’s awesome APIs.

Also, see the top Google products and services for people who build webites.

Other Tools to Check Out

  • Pastebin: A simple text-pasting tool that has syntax highlighting. (No live preview though)
  • codepad: A web-based compiler/interpreter for server-side and software programming languages like PHP and C++
  • Real-time HTML Editor: A very simple HTML previewing tool
  • Ideone: An online interpreter/debugging tool that can run over 40 programming languages

Do you have a favorite web-based sandboxing tool not mentioned above? Please share it with us in the comments.

Related Content

About the Author

Jacob Gube is the Founder and Chief Editor of Six Revisions. He’s also a web developer/designer who specializes in front-end development (JavaScript, HTML, CSS) and also a book author. If you’d like to connect with him, head on over to the contact page and follow him on Twitter: @sixrevisions.

 
 

#thankyousteve

07 Oct

thank you steve

Twitter engineer Miguel Rios pays tribute to the man, the legend. Zoomed out you see the portrait of Steve Jobs. Zoom in, and you see public tweets tagged with #thankyousteve sent out over a four and a half hour period on the evening of October 5. Tweets are ordered by number of retweets, left to right and top to bottom.

See the full-sized version here.

 
 

Google Cloud SQL: your database in the cloud

06 Oct
Author Photo
By Navneet Joneja, Product Manager for Google Cloud SQL

Cross-posted from the Google App Engine Blog

One of App Engine’s most requested features has been a simple way to develop traditional database-driven applications. In response to your feedback, we’re happy to announce the limited preview of Google Cloud SQL.

You can now choose to power your App Engine applications with a familiar relational database in a fully-managed cloud environment. This allows you to focus on developing your applications and services, free from the chores of managing, maintaining and administering relational databases.

Google Cloud SQL brings many benefits to the App Engine community:
  • No maintenance or administration - we manage the database for you.
  • High reliability and availability - your data is replicated synchronously to multiple data centers. Machine, rack and data center failures are handled automatically to minimize end-user impact.
  • Familiar MySQL database environment with JDBC support (for Java-based App Engine applications) and DB-API support (for Python-based App Engine applications).
  • Comprehensive user interface for administering databases.
  • Simple and powerful integration with Google App Engine.
The service includes database import and export functionality, so you can move your existing MySQL databases to the cloud and use them with App Engine.

Cloud SQL is available free of charge for now, and we will publish pricing at least 30 days before charging for it. The service will continue to evolve as we work out the kinks during the preview, but let us know if you’d like to take it for a spin.


Navneet Joneja loves being at the forefront of the next generation of simple and reliable software infrastructure, the foundation on which next-generation technology is being built. When not working, he can usually be found dreaming up new ways to entertain his intensely curious one-year-old.

Posted by Scott Knaster, Editor
 
 

Steve Jobs

05 Oct

My iPhone slid out of my shirt pocket a few months ago and fell straight onto concrete. I was luckier than some: the only damage was a shattered back panel. I slapped a strip of black gaffers tape over it to keep it intact. I knew that I could take it to any Apple Store and have the back replaced for just $29, but I carried it around like that anyway.

I figured it was my punishment for not taking care of my toys.

I finally went into a Store today to get it fixed.

I went to Apple.com and was able to reserve a time for my visit. When I arrived, I was greeted at the entrance. The place was packed, even though it was the middle of a random Wednesday afternoon. People were playing with every demo unit on display.

For all of the crowding, this mall Apple Store was still a pleasant place to be. It was clean and well-lit, and the staff were all clean, kind, and patient.

I made my way to the Genius Bar at the back. I was greeted a second time by an employee whose job it was simply to act as a welcomer and a concierge and a facilitator. He invited me to take a seat while I waited for my appointment. I was early.

I sat in a large area reserved for one-on-one training. A dozen or more people were learning how to use their Apple hardware. Some, I reckoned, were doing things with computers that they’ve never done before.

Me, I took out my iPad and was on the store’s open WiFi in an instant.

Five minutes before my scheduled time, a Genius walked up to where I was sitting. It was a simple problem and he explained that they could fix it up in just ten or fifteen minutes. He tapped away at an iPhone that had been equipped as a logging system for work orders and then walked away with my phone.

I looked around. I saw a man carrying in an iMac wrapped in a towel, the way you’d carry a sick and beloved dog into the vet.

I saw a child who couldn’t have been more than four years old playing with an iMac that had been set up at a table low enough for four-year-old children to set at. She was playing a word game of some sort. Presently, a parent came by and handed the girl what I presumed to be the child’s own white iPad 2. I sure didn’t think that this 30-ish woman had put Dora stickers on her own iPad.

The child stopped just short of hugging the iPad like a beloved doll, but she was clearly very pleased to have it back again. She held it and woke it up and tapped through to her favorite apps. Satisfied — and at the urging of her mother — she then tucked it under her arm in a maternal way and held her mother’s hand as they walked out.

I spied another store employee with a full-sleeve tattoo in progress. Her forearm was complete but a koi that splashed down from her elbow had only been outlined. The traditional staff uniform is a tee shirt (in the color du jour). Staffers are welcome to throw something on underneath it. She obviously felt comfortable enough in this environment to show off her tattoos.

Another Apple employee approached me, with my repaired phone. I hadn’t budged from that table since I walked in and sat down. $29 plus tax for the repair. His iPhone card scanner didn’t work for some reason but he didn’t let his annoyance show. After two swipes, he apologized sheepishly and led me to the store’s POS terminal. Zip, tap, a few pleasantries, and it was all taken care of.

Let me extract elements from that story:

1) Staff acknowledging people as human beings, and with courtesy.

2) A pleasant, beautiful space to be in, even if the store wasn’t a “landmark” property.

3) People learning things.

4) People who don’t simply own and tolerate their computers, but who feel a real emotional connection to them.

5) People who live lives that are a bit out of the mainstream, in a space where they feel comfortable being who they are.

6) Kids who see the most advanced technology in the world as just another window through which they perceive the world.

7) The worst thing that can happen in a relationship between a manufacturer and a customer — a broken product — being handled quickly, courteously, efficiently…and affordably.

Steve Jobs was correctly known as the most productively hands-on CEO in technology or maybe even any other industry. The Apple Stores were a particular obsession. If you walked in and discovered that the table of hard drives had become a table of headphones and the hard drives were now on the third shelf of the first bank of product shelves, it was probably because of something Steve decided earlier in the week.

Steve is dead. But you walk into an Apple Store and you see all the reasons why he was such a phenomenal CEO, and why so many people feel the way I do tonight.