dougv.com « Doug Vanderweide

CSS-Tricks, a really great Web site that explains in detail how to replicate cutting-edge Web site designs and effects, tipped a new idea: humans.txt, a metadata file to compliment robots.txt.

“It’s an initiative for knowing the people behind a website,” said the proponents, who hail from Spain. “It’s a TXT file that contains information about the different people who have contributed to building the website.”

Like Chris Coyier, the author of the CSS-Tricks article, I like the idea of having a meta data file, outside the code base of a Web site itself, that credits the people behind the site.

I find those “Web sites created by {insert Web design firm here}” links in the footer of a site to be so 2001 (although admittedly, I only stopped putting them on sites about five years ago). And sure, one can add an author meta tag to the head of a Web page, to give credit where it is due. But I revere the head element of a Web site; authors shouldn’t put any old thing in there, and everything in there should serve a specific purpose to the page itself.

So a humans.txt file makes a lot of sense, and I admire the cleverness behind calling it that, in compliment to the familiar and requisite robots.txt file.

I like the idea of being able to give extended credit to site contributors. I like the idea of being able to reveal base technologies behind a site. (But not too specific, mind you; I can just see the script kiddies out there, putting together exploit bots that scour humans.txt files to find unpatched software to attack.)

I think it makes more sense, however, to use XML. The robots exclusion standard came out in 1994, was the brainchild of one person solving a problem specific to his search engine’s needs, and effectively became a standard by fiat.

While it has a kind of schema — at least, its proper formatting is well-known — the structure of a robots.txt file isn’t efficient or elegant; it’s not easily read or manipulated, and it can be repetitive and difficult to manage multiple rules for multiple engines.

An XML document is far cleaner.

Continue reading: Meta Data For A Web Site's People: humans.txt »

The first New England GiveCamp was this weekend at Microsoft’s Northeast Research and Development building in Cambridge, MA, and it was, by far, one of the most rewarding experiences I’ve had in the 15 years I have been professionally coding.

About 100 technical and non-technical volunteers spent the weekend of June 11-13 writing code for charities. Most projects were Web site upgrades — either installing a content management system, or extending that system to do something it didn’t do before, such as collecting very specific data, integrating with a customer relationship management tool, etc.

Other projects were more complex. For example, my project was data normalization and version control.

I was assigned to the Goshen Land Trust, a charity that protects open and green space in Goshen, CT. My team members were Kriss Aho and Pat Tormey, both from the Boston area; and Chris Craig, the president of GLT.

Prior to last weekend, GLT tracked all its customer relationships in Excel spreadsheets. They do their accounting in Quickbooks.

If someone was a volunteer, his name went into the volunteer spreadsheet. If he owned land, his name was in the landowner spreadsheet. If he was a land or money donor, his name went into another spreadsheet. And so on, and so on; this story has been told a thousand times before, we all know it by heart.

And, of course, there were several versions of each of these spreadsheets out there: They were exchanged back and forth via e-mail, meaning no two copies of the same spreadsheet were alike. Again, stop me if you’ve heard this one before.

Finally, donor payments are managed entirely separate from the spreadsheets, via entries into Quickbooks. So there’s a completely different store of around 800 mostly duplicate names in Quickbooks, too, which isn’t easily compared to a spreadsheet of about 2,000 names.

So we had to figure out a way to impose some version control on these sheets; we had to create a master data store, so we could have an authoritative source of customer relationship information; and we had to sync customer information in Quickbooks to match the master data store.

Sounds like fun, I know. It actually was, after it stopped being awful.

Continue reading: New England GiveCamp 2010: What A Great Experience »

And now, for some levity, courtesy of Andrew Clover at doxdesk.com: An obvious trolling of Stack Overflow (and one which they have removed), but a funny one, nonetheless.

(Click for full-size pic)

So full of win, from start to finish. Even the “Related” links are hilarious. FYI, bobince — the straight man in this joke — is Clover.

All links in this post: http://delicious.com/dougvdotcom/how-to-not-add-numbers-in-javascript-and-how-to-troll

I recently came across a post on elegantcode.com that really struck a nerve. The premise: If you write good code, comments should not only be unnecessary, they could actually be counterproductive. Says author John Sonmez:

“As my experience has increased, I have realized more and more that comments are actually bad. They indicate a failure.”

I know that this runs contrary to what most professors, instructors and textbooks say. They offer what seems a reasonable rule: Comment your code so that the next person who reads it doesn’t need to try to figure out what you’re doing.

And it’s also contrary to most of the code I put out on this Web site. I would certainly agree that I over-comment my code, but that’s a conscious decision, based in large part because I want my readers, who tend to be newer programmers, to completely understand what my code is doing at each step.

But as Sonmez notes, comments aren’t the best way to achieve that goal, especially in object-oriented code.

For example, if you change code, its related comment doesn’t change. Use proper constants — e.g., DEFAULT_LOOP_ITERATIONS — instead of a variable declarations. Name your methods, properties and function so they are self-documenting (do you really need to comment a method named OpenXMLFile?) and write more code so that self-documenting names can replace more abstract procedural code calls.

It’s this third suggestion that interests me. I’ve said, many times, that less code is better. I maintain that view. But I’m inclined to agree more with Sonmez that, if it takes a few extra lines and a couple more dependencies to create self-documenting code, that complexity is probably the right trade-off, versus adding novella-sized comment blocks.

I’m almost certainly going to continue over-commenting code here, especially because I am trying to serve the needs of novice programmers.

But Sonmez’s brilliant post really hits hard, and reminds me that if I am trying to write simple code that’s easy to understand, I should rely more on best programming practices than double-slashes. Expect to see more of that in the future. And please do take the time to read his post in full.

All links in this post on delicious: http://delicious.com/dougvdotcom/good-coding-practices-should-replace-comments-in-code

I spend several hours every day reading / viewing and retransmitting Web content. For the longest time, that meant a lot of visits to a lot of places; it also meant some places got forgotten along the way, or not as fully appreciated as they should be.

That is, until I discovered Google Reader, The New York Times Skimmer and Ping.fm. The three of them make my online life a lot easier to manage. I’d like to explain what each of them is, and how I use them to streamline and crowdsource my daily Internet viewing.

Google Reader is an exceptionally powerful RSS feed reader. (For those who are new to the blog, an “RSS feed” is basically a way to transmit content from one Web site to several others; be it text, pictures, audio or video. Google Reader, and other RSS feed readers, are ways to combine several RSS feeds into one place.)

Reader provides most of the features you’d expect from an RSS reader, plus a lot more:

• Feed aggregation (that is, you can read several feeds at once);
• the ability to group feeds;
• tagging of individual items;
• a “like” feature, which helps Reader suggest other feeds you might like, based on the articles you like;
• a “star” feature, that you can use to easily find items you want to revisit;
• and by far the most valuable feature, a “share” button, that allows you to re-aggregate content — that is, it gives you another feed of the items you share, and presents it as an Atom feed, a static Web page attached to your Google profile, and a JavaScript widget you can easily add to a blog (check the upper left-hand corner for mine).

I currently subscribe to feeds from Slashdot, Lifehacker, The Daily WTF, Wired and a few NPR blogs / podcasts.

Another great thing about Google Reader is Play, which is basically a visual way to find new things on the Internet. Your Facebook friends will think you’re the cleverest person around, just because you repost things you find in Play.

Continue reading: Three Web Sites That Make My Online Life A Lot Easier »