Burningbird's RealTech

Last week, Danny Ayers made a request to the semantic web community at large: that we take turns publishing our own version of This Week's Semantic Web. I volunteered to start, and hope that others follow, though in comments to Danny's post, the suggestion about the Gem of the Week sounded better (and a lot less work).

However, I decided to add a slight twist to my own version of This Week's Semantic Web, focusing not only on the stories, but how I found them. After all, the real purpose of the semantic web technologies is to make information easier to find. How are we, in the semantic web community, doing in this regard?

To start, I subscribe to various feeds including Planet RDF, as a way to keep up with most of the semantic web news. This week, the stories from Planet RDF that caught my eye were the following:

A List Apart has a timely article titled Understanding Progressive Enhancement discussing the perceptual differences between graceful degradation and progressive enhancement. I enjoyed seeing Steve Champeon's idea given new light. Additionally, now is as good a time as any to have a go at these topics, with the many new enhancements being added to today's browsers, while antiques still cutter cyberspace. I could have done without the cloyingly cute M & M analogy in the article, but that's probably my inner Cranky Woman having a go this AM.

I've written about graceful degradation, previously. Graceful degradation means applying modern technology but ensuring the application doesn't negatively effect those viewing a web site with an Antique (remaining nameless). However, contrary to the ALA author's statement of Under this paradigm, older browsers are expected to have a poor, but passable experience, graceful degradation is just that: gracefully degrading, meaning that though the person using the Antique doesn't get all the bells or whistles, their experience at the site is more than "poor but passable".

Progressive enhancement, on the other hand, begins with the content, rather than the technology; ensuring that the markup used to organize the content is semantically correct and valid. Then, and only then, the web site developer progresses to the use of CSS and JavaScript, both to annotate and enhance the content. That's been the primary difference between the two approaches: graceful degradation tends to focus on technology, first, while progressive enhancement focuses on content, first.

This site, like most others built using a content management system rewrites the dynamic URLs into a static format, primarily to make them more readable. More portable, too, as we move our writings from CMS to CMS.

Google has come out with an odd post about static versus dynamic URLs, and it's better for the Google bot to leave your URLs dynamic, because people screw up the rewrite rules. If you leave the URL dynamic, then the Google bot can figure out what it needs from the URL. However, if you rewrite it as a static URL, but leave dynamic pieces in, such as page number or the like, the Google bot may interpret the URL incorrectly.

At least, this is my interpretation of the post, and from the comments, other people's interpretation.

The focus of Google's suggestion is search engine optimization, and so probably only of interest to the SEO types. However, when Google writes posts like this, they ripple out like waves on a pond after a big stone is dropped in. Within a week or two I'm sure we'll be hearing about how "best practice" for URLs now, is to use dynamic, not static URLs, regardless of the reason for the best practice.

No more permalinks to you Wordpress folks. Or smart URLs for the Drupal users. Be brave, and show your parameters.

Or not.

Scott at Lazycoder writes on his recent job interview experiences.

Certification and licensing should be about setting a base level of competency. You shouldn’t have to ask someone what the difference between a div and a span element is during a phone screen if they are a licensed web developer. You shouldn’t ask a C++ developer to find the memory leak in a given piece of code. What you really want to know are the intangibles. Are they a cowboy coder? Are they continuously trying to improve their skills or are they set in their ways? Will they speak up during a meeting if they see a bottleneck or problem coming or will they just ignore the problem? We, as a group of professionals, need to determine a structure and governing body that will allow us to not wonder if an applicant is lying on their resume, but instead focus on whether or not a person will be a good fit with the rest of the team.

Most tech interviewers haven't a clue how to interview. Instead, they set up some code, and allow the code to do the interviewing. Worse, they set up the interview in such a way as to make themselves look good, while making the process as difficult and painful as possible for the interviewee. Rather than a co-worker, the interviewer sees the interviewee as a potential competitor, and acts accordingly.

It's the only field I know of that uses this approach. Most other fields are populated by people who genuinely care about finding the best person for the job.