dougv.com « Doug Vanderweide

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 »

The New York Times’ Bits blog has a post today in which chief Facebook lobbyist Elliot Schrage answers reader questions.

For a lawyer — especially a lawyer facing a Bonfire of the Vanities-worthy media frenzy, a meddling Congress, watchdog groups barking at his door and an inchoate Intifada by his longest-standing and most important partner — Schrage was pretty forthcoming; most lobbyist / marketers would equivocate their way out of a similar mess.

Actually, if you read the Times blog post closely enough, Schrage effectively admits it’s that sort of behavior that has put Facebook in hot water:

“Our desire to innovate and create new opportunities for people to share sometimes conflicts with our goal to create an easy and accessible user experience,” he wrote in the introduction. “It takes forums like this to get better ideas and insights about your needs.”

Which is the purpose behind this post. I’d like to put, in layman’s terms, Schrage’s answers to each of the questions posed, and either provide the answer I wish he had given — that is, an answer that is the plain truth about why Facebook does what it does — or expand on what he said.

Q: “Why can’t you leave well enough alone? Why do I have to do a weekly ritual of checking to see what new holes you’ve slashed into the Facebook Security Blanket, so that I have to go and hide or delete yet more stuff? Are Facebook customers really pounding on your door screaming that they want more categories of their personal data to be available to marketers every few months?”

Schrage: We are clearly upsetting people by making changes as often as we do. No personally identifiable information is shared with advertisers.

Me: Social media is young. What works and what is profitable changes quickly; what fit into the way Facebook did things, even just a few months ago, may be cutting off opportunities to make money or head off challenges from other social media providers today. That’s why things change so much: To protect and grow Facebook’s market share.

If you’re going to complain about Web advertising based on browsing habits, you probably should have stopped using the Web back in 1996. And if you’ve ever used a coupon, promo code, frequent buyer card or gift card, I’d like to kick you in the butt as I explain what, exactly, constitutes behavior-based marketing.

Continue reading: The Answers I Wish Facebook Had Given To User Questions »

Remember last month, when all the Internet was crowing about how “no one even attempts hacking Chrome” at Pwn2Own, an annual hacking contest with a primary focus on Web browsers?

The implication was, of course, that the Chrome Web browser cannot be hacked; or, at least, that its architecture is so good, and that hackers know this so well, that Chrome somehow becomes the Sword In The Stone, if not the Holy Grail.

This, of course, is nonsense. Fast-forward to today, where Google announces patches to three major Chrome security holes.

While Google isn’t revealing the specific nature of the three holes — “the referenced bugs may be kept private until a majority of our users are up to date with the fix” — their titles alone are alarming: “cross-origin bypass” suggests it’s pretty easy to spoof / forge where a request comes from; and all “memory corruption” causes concern about at least forced crashing, if not unauthorized access to system privileges.

Is Chrome a bad browser? Hardly. Has it had problems? It sure has. Did the refusal of hackers to go after Chrome during Pwn2Own mean Chrome is invincible? Not at all.

For one, there’s money to be made at this competition, and time is limited, so it only makes sense to go after the browsers you know can be compromised easily: Internet Explorer, Firefox and Safari, which was most easily hacked in previous Pwn2Own contests and leverages the same base technologies — WebKit and Chromium — used to power Google Chrome.

For another, these other browsers have been out longer and are used more widely than Chrome. That means knowledge of how they are built, information about glitches that could prove to be exploitable, etc. is greater.

Or I may be completely wrong. It could be that Chrome is, indeed, completely feared within the black- and white-hat communities alike.

Whatever the case, my point is that Google is not infallible, Chrome can be exploited, and why no one bothered to try to do so during a specific competition is hard to say.

Take with a grain of salt the hype you hear about hacking and security, especially if it’s proclaimed loudly. Anything complex is vulnerable to compromise and collapse, be it the Mayan civilization or even the Oracle DB server. Chrome is no different.

All links in this post on delicious: http://delicious.com/dougvdotcom/googles-web-browser-has-its-problems-too

Crowdsourcing is all the rage these days, and even if you’re not managing a social media Web site, sometimes it’s helpful to accept content from end users.

For example, one of my clients has a community calendar on its Web site. Since the inception of the calendar, staff time had been devoted to retyping e-mailed and snail-mailed items into that calendar’s back end.

That was almost entirely wasted time, which my client rightfully wanted applied to something more profitable. My client wanted to allow staff to approve, edit or delete calendar submissions before they appeared on the site, but asked me to shift the burden of actually adding items directly onto the shoulders of site visitors.

Thanks to ASP.NET’s built-in membership system, we can easily provide a simple system for allowing end users to provide content. Not only that, but thanks to the role-based permissions incorporated into membership, we can even presort content to specific sections of the site, based on who is submitting it; grant specific users or user groups the ability to bypass an approval process; throttle contribution allowances; basically, any permission or restriction you might want to use.

(Aside: We can similarly implement a model like this in PHP, but it does not have a built-in membership provider. I may, at some later date, describe building a PHP membership provider that is similar to the ASP.NET model, at least in terms of practical use, if not mechanically similar.)

I am going to make a simple cancellations notification system as my demo.

After all, everyone wants to know if school is closed, or whether the play is still on in spite of the weather. Because canceling school, play, etc. generally comes down to a single person’s decision — or, at most, a few people — we can easily provide a system to log in, select a few options or enter a bit of text, and save everyone the time and grief such notifications otherwise take.

The specific features I will demo, in this and upcoming blog entries, will be:

• an administrative interface to add, edit and delete memberships;
• another administrative interface to add, edit or delete membership roles (i.e., membership groups), and to assign members to those groups, as well as to assign users to specific schools, organizations, etc.;
• an administrative interface to approve, edit or delete cancellation notices;
• a private form to allow membership to post cancellations for the schools, organizations, etc. with which they have been associated;
• a public view of cancellations that have been approved for viewing.

Continue reading: An ASP.NET System To Allow Site Members To Contribute Content, Part 1: Overview »

It’s no mystery to anyone who’s been on Facebook for more than a week that one of its biggest boons — and, in the finest Zen tradition, one of its most nagging banes — is the plethora of third-party applications that leverage its data.

Virtually all the value in Facebook is crowdsourced — that is, users generate all the content, they create all the connections, they drive interest in whatever direction it may flow, they create scores of memes every hour.

Since Facebook’s primary business model is driven by collecting data about usage, this means that opening its use to the creators of new social media tools makes tremendous success.

Why bother taking Microsoft’s old-school tack — create a standard, then ride it into the grave — when, instead, you can provide users, and let others give them reasons to stick with you? Why bother even taking Google’s approach — create lots and lots of things, in the hope one of them proves popular — when someone else can assume all the risk, presenting you with the opportunity to buy or duplicate his success with your framework?

How many people, do you suppose, would have stopped using Facebook after a few days, had it not been for Mafia Wars, Farmville or Bejeweled? That’s my point.

But every day, there’s also a new crop of the outright obnoxious third-party applications that promise to do the exact opposite: Drive users out for fear of their privacy and security.

Take, for example, the recent spate of “see who’s stalking your profile” applications. As The Register notes, all of them are at best cash-for-clicks scams; at worse, open invitations to load malware onto the computers of tens of thousands of unsophisticated users.

I’d like to expand upon a central tenet of a blog post offered by Rik Furguson of Trend Micro, from which The Register drew its article: That it’s high time Facebook employed some sort of vetting process for third-party applications.

Continue reading: It’s Time For Facebook – Or, At Least, Someone – To Vet Third-Party Applications »