Burningbird

A post by Karl Martino reminded me of Jeff Atwood's We are typists first, programmers second. Atwood was responding, in hearty agreement, to a post by Steve Yegge, who wrote

I was trying to figure out which is the most important computer science course a CS student could ever take, and eventually realized it's Typing 101.

The really great engineers I know, the ones who build great things, they can type.

As I wrote in Karl's comments, saying that fast typing is what makes a great programmer is little different than saying what makes a good carpenter is how fast they swing their hammers.

Fast typing is a by-product of extensive creation, whether that creation is web page markup, a stylesheet, or code. The more we create code, web pages, and designs, the more efficient we get with all of the tools used, including but not limited to, typing.

In addition, times have changed. I have no doubts that today's generation of kids are speed demons on the keyboard—whether it's on their cellphone or attached to their computers. A typing class would most likely slow them down.

If anything, what we should be encouraging is more practice with problem solving—the ability to figure something out on one's own, without having to Google an answer or ask friends on Twitter—not typing.

Not long ago, Tim O'Reilly posted a discussion thread about the importance of practice, and one of the participants in the thread, my long-time editor, Simon St. Laurent, reiterated his interest in practicing this year—both on the trumpet, and in his coding.

I never left programming the way I left trumpet. I simply stopped playing trumpet after eighth grade. I've gone back and forth with programming since sixth grade, getting totally into it for a year or two at a time and then departing out of frustration, distraction, or the need to do something else. At O'Reilly, I'm exposed to programming constantly - I edit and write computer books after all! - but editorial is a long ways from actually programming. Even writing books about programming is a seriously meta- activity, one that requires more attention on the communications than on the code. (The code has to be right, but - though this may depend on the audience - the explanations have to do a lot more than the code.) My work isn't programming practice.

One place I practice is with this site. I still have hopes that I can transform my work with this site into some paying work. At a minimum, I enjoy the tweaking and it keeps me occupied.

In addition, I also frequently re-design this site. Doing so allows me to explore new uses of technology, such as the use of SVG for site design, and JavaScript and RDFa in support of semantics. The practice also helps me improve my use of XHTML and CSS, including how to deal with IE without necessarily having to incorporate massive amounts of workaround code. Luckily, the "in" design concepts today are based on a minimalist design, so if my site is legible and clean in IE, it doesn't matter if it's plain.

I'm not practicing with every hot technology; I've made choices with how I spend my time. Yes for PHP, Python, JavaScript, CSS, SVG, RDFa, various web services, and XHTML. No on .Net, Ruby, Java, and cloud computing. A maybe on HTML5 and C++. Not necessarily the best decisions, perhaps, as Java and .Net are where the money is made, and the folks in Silicon Valley drool when you mention "cloud", but I really don't like the technologies or the environments.

Practice is essential for keeping our skills sharp, but that's not the only reason it's important. It's also a way to constructively deal with the constant barrage of unhappy news we're subjected to. We may not have any control over warring nations, global warming, or the state of economy, but we do have some control over how we live our lives. And that includes finding pieces of ourselves that can be improved with practice.

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.