Ever wonder what ‘s behind Yahoo!’s YQL? I did until I came across a pretty comprehensive explanation on Yahoo’s Developer Network site. First of all, YQL stands for Yahoo! Query Language, and it’s an expressive SQL-like language that lets IT developers query, filter, and join data across Web services. It promises to make apps run quicker – with fewer lines of code and using fewer network resources. And YQL can be used for commercial and non-commercial purposes.

YQL apparently eliminates the need for developers to locate URLs and documentation to access and query different Web services. It promises to enable developers to access and shape data across the Web via a single, simple language, eliminating the need to learn how to call different APIs.

Yahoo! Says that YQL exposes an SQL-like SELECT syntax that is easily recognizable to developers and expressive enough to nab the right data. This can all be done without opening another Web browser.

Role of Open Data Tables

Yahoo! Says that it uses Open Data Tables so that developers can add tables for any data on the Web to the company’s API-specific tables. Open Data Tables allow users to make their data YQL-accessible.

Something Yahoo! calls Execute element also gives developers control of how the data is fetched into YQL and how it is given back to the user. It means developers can build tables that manipulate, change, and sign URLs to access almost any protected content. Thus, YQL can access and combine data across a variety of different authenticated services, for example, Twitter. This feature greatly streamlines the current labor intensive work of calling up multiple services and data sources to join merge data. The information can be tweaked and manipulated into an optimal format for users’ applications to consume.

YQL’s Execute elements run server-side JavaScript with E4X (native XML) support, giving Web developers a fully functional and familiar language, enabling them to do anything they want with the data.

I suggest a quick read about the specifics of YQL, or you can even join a YQL Developer Community Forum to learn how others are using it and ask questions.

The HTTP response status codes that start with a 5, show the cases in which servers know they’ve found errors or otherwise can’t manage the request. With the exception of responding to HEAD requests, servers ought to have an entity with an explanation of the error and say whether it’s permanent or temporary. Similarly, user agents ought to show all included entities to users. The response codes apply to all request methods.

The server response codes are as follows:

• The server response code 500, or internal server error, means a generic message is sent if no more particular message can be obtained.
• A 501 code, meaning not implemented, indicates that a server can’t recognize a request method or cannot fulfill the request.
• 502 means a bad gateway; the server acted as a proxy or gateway but got an invalid response from a downstream server.
• 503, meaning service unavailable, indicates the server’s lack of availability due to overload or being down for maintenance, which is often just temporary.
• A 504 error, or a Gateway Timeout, occurs when the server acting as a gateway does not receive a quick response from the downstream serve.
• A 505 error means that the server can’t handle the HTTP version used in the request.
• A 506 error is called Variant Also Negotiates, and means that the negotiation for the server’s request results in circular references.
• A 507 error indicated Insufficient WebDAV Storage.
• The common 509 error (Bandwidth Limit Exceeded) isn’t actually specified in any RFC.
• A 510 error means that the request requires further extensions before it can be properly answered.

As a website developer, are you guilty of any of the following sins? If so, it might be time for some self reflection, a good confession and a promise to fix the errors of your ways. These come from a recent article written by a web surfer (hey, aren’t we all?) that every developer should read:

1 – Slow Download Times. OK, so we’ve gotten used to getting what we want RIGHT NOW! But, as a “general rule, the longer it takes your site to download, the fewer visitors will stick it out ’til the bitter end to see it,” says the article. Some suggestions: Try delivering information in a text-only format, check out the available compression tools and strike a good balance between image size and quality.

2 – Poor background and text colors. Don’t frustrate your readers with “psychedelic kittens giving the “peace” sign.” Use black text on white background for a business site. And make sure your links can be distinguished from the background.

3 – Blinking Text. Get rid of it; it’s annoying and not professional on a business page. As for GIFs and other images, certainly use a few to decorate, but, as the author says, “You run into problems when you’ve got 20 or so animated Smurfs doing the Macarena on one page.” LOL. I like that imagery.

4 - Frames. What the heck is the purpose of frames, anyway? Yeah, they could help readers navigate a sight, but do they really most of the time? In terms of layout, they tend to mess things up. Also, some search engines have problems with frames when indexing your site.

5 – The Long Scroll. Don’t write your page to go on forever. Instead, break up your content into short or medium sections of information, or provide links to longer content. After all, you don’t want people getting out their electron microscopes to find the scroll bar at the end of the site. And in these eco-conscious times, you don’t want to cause people using up two trees worth of paper to print out your web page information.

6 – The Hard Hat Syndrome, aka, “This Site is Under Construction.” If it’s not built, they still won’t come. Real easy to remember: don’t put your site up if it isn’t ready. After all, who’s going to bookmark an “under construction” site based on the little hard-hat guy holding up a sign saying “Pardon our appearance but…”

7 – The Sound of Music. No offense, Julie Andrews, but I hate the sound of music on business sites. If you’re building a professional site selling your services or products, why do you need music – especially the kind that loops continually? Most of the time, unless you’re selling some music-related product, it’s just plain cheesy and, again, annoying.

8 – Haphazard Design and Layout. Pick a theme, style, whatever, and stick to it. Using different fonts, colors and switching methods of navigation confuses people and hurts the eyes, mine anyway. Another point, if readers click to a different page and that page looks totally unlike where they just came from, they’ll be tempted to think they’ve lost their way.

9 – Designing for a Specific Browser/Color Setting/Screen Resolution. Don’t make the mistake of designing your site for any specific browser because then you run the risk of a chunk of viewers not being able to access your site. Don’t forget, not everybody updates their browsers before hitting the sack. Why take the chance of missing these folks? Avoid designing for a specific color setting or screen resolution, too. If you design for a higher setting, it creates an annoying horizontal scroll bar for people using lower settings that only moves when you read more.

10 – Spelling and HTML Errors. Proofread everything before putting it up there because there’s nothing more embarrassing on a business site than spelling errors, or, for that matter, mistakes you make in coding that render half your page in bold. Think about this: what do obvious errors – that can be easily avoided – say to potential customers about the quality of your products or services?