On the Spaces After a Period

Two spaces after periods? Shouldn’t Google Plus fix that bad habit automatically?

Saw this over at Daring Fireball. Disappointing, because I love John Gruber’s writing. I’m a two-spacer, probably because I was taught that in school, but also because one-space can be confusing or ambiguous with abbreviations.

“They sell candy in the U.S. Mint.”

I will not repeat the arguments for either side here, but the one-spacers have yet to convince me that two-spaces is not a useful and clear standard. They lecture the Internet at large about history and misinformation and authority and foolishness (and stubbornness! as if they themselves are not also stubborn!), but the mint-candy phrase above is inarguably ambiguous.

(And, of course, whatever I write here, it gets turned into HTML, which has to be tricked into displaying two-space formatting. It’s out of my control, but I can live with it either way. When I am in control, I prefer to make the reader’s job easier.)

On Overzealous Email Validation

Email address – Wikipedia:

Some mail services allow a user to append a tag to their email address (e.g., where joeuser@example.com is the main address, which would also accept mail for joeuser+work@example.com or joeuser-family@example.com). The text of tag may be used to apply filtering and to create single-use addresses.

I see developers get this one wrong all the time. And, actually, they don’t get it wrong: they copy someone else’s regex or validation method, and never bother to test it. If I’m filling out a form online, I’m probably going to give you my Gmail address, and I’m probably going to inject “+yoursite” before the “@” symbol. That helps me track who’s abusing my trust.

But: you have a requirement to “reject” invalid email addresses. What’s a valid email address? Well, to get completely pedantic, lots of things are technically valid email addresses that you’ll never run into. This is one of those cases where I’d actually rather see a set of tests — good emails and bad emails — rather than a “requirement” (“email should be valid”) or the specification itself. (Are you doing anything useful with that email address? Are you confirming that it belongs to the user? Because if you can’t answer those questions, a vague requirement about “valid” emails is just a distraction.)

Truly, the requirement should be based on the audience and expected input. Are you creating a site where people might be typing in their username rather than their email address? (Do your users confuse their mailing address with their email address?) Protect yourself against the scenarios you’re likely to run into, and then pour your energy into other ways to make your form better. (Not writing the fix for the edge case that means an.”unusual\ example”@clownpenis.fart doesn’t pass, because I guess it’s a valid email address.)

10 Questions I Always Ask

A friend wrote to ask “what are ten questions you ask at the start of a project?”

My jobs, over the course of the past few years, have let me work more directly with people at the start of the process, so this is a question that I’ve thought about a lot. (Over the course of the years, I’ve started and refined a document that eventually numbered 48 questions, so I’ll have to make my questions here count.)

What Do You Know?

First off, no set of ten questions is going to work for everybody, all the time. I’ll focus here on custom software development on the web, but even that’s different than it was five years ago. Today, you’ll want to ask questions about how the development effort integrates with mobile strategy and any social media presence. (Both of these things would have been intriguing and futuristic until somewhat recently.)

The Questions, Already

  1. Where are you at in your process? It might be that the client has the website totally mapped out, wire-frames wire-framed and servers procured. It might be that the customer just has an idea, and needs help with strategy, design, content, and analytics. If you ask, you’ll get an answer, even if the response is “huh?”
  2. What decisions have you made about technology? Sometimes a project is really complicated because of a technical decision or legacy system that was made before you got there. Maybe it’s gotta be done in Plone (you know, Plone, the CMS that’s built on Zope).
  3. What’s going to happen after the site launches? What is the customer going to do with their new / relaunched site? Are they expecting to see orders roll in? Are they going to want to change content? Are they planning on a phase 2 after phase 1 is done? That changes not just the complexity of the development scope, but the planning, too.
  4. Roughly, how many pages and templates are we talking about? This is the start of nuts-and-bolts web stuff. (Swap this out if you’re building something else.) This is really just for a sense of scale. Sometimes you’ll hear “I can’t tell you right now, I don’t know” and what they mean is “it’s either 7 or 8, depending on what Gary decides”.
  5. How should this behave on mobile browsers? The answer to this might really surprise you. They may have decided that they can forget about old phones, or it might be that the CEO has a BlackBerry, or it might be that they’ve never really thought of that. On the other hand, they might say “yes, pixel-perfect, across every browser”, and at least you know what you’re dealing with.
  6. Are there internationalization, accessibility, or regulatory challenges we should be aware of? You want to expose multi-lingual stuff immediately. Otherwise, you just want to know if you’ll be working in a space with a special-needs audience or government oversight. This can triple an estimate of effort.
  7. What kinds of interactions, customization, or membership do we need to think about? If you’re talking websites, it’s pretty clear that there should be N pages, utilizing M templates, and some kind of navigation that ties them together. But does the site support search? Contact Us? Some kind of calculator where you determine what your mortgage insurance is going to cost? A marketplace where people shop for insurance? You’ll want to know.
  8. What other systems does this site connect to? Maybe the most important question. Generally, I hear “none, no other system” and then I ask about Google Analytics. That’s a system, and the clients will be interacting with it (unbeknownst to them). And email — does this system kick off emails at any time for any reason? That’s another system.
  9. Who’s going to do what, now and after the development? Maybe this isn’t relevant everywhere, but sometimes you’re selling development. Sometimes you’re selling a team, and sometimes you’re selling an entire project. So, do they have PM and QA representation they’re bringing? Will you be working with an onsite IT team to deploy, or will there be a fierce rivalry between your team and theirs?
  10. When are we starting, finishing, and getting paid? I sometimes leave this for other people to ask and sort out, but these details have to be asked at some point. A word of warning, here: they’ll always say “we don’t know what this should cost, you tell us”. No real project doesn’t have a timeline / budget. (Or: if you have to ask, you can’t afford it. In my experience, this is unfortunately always true.)

Moving Beyond the List

The script above evolved over the course of years. Some questions worked, other questions turned into others, and some questions never got me where I wanted to go (so I don’t include them above). If you don’t write this stuff down, you minimize your chances of evolving and improving your process. (It’ll evolve, I guess: randomly. Wildly. Aimlessly.) Give your list of questions some careful consideration after each interaction, and you’ll be naturally drawn towards making it better.

In Praise of JavaScript

So there’s been, y’know, talk about JavaScript at work.  With JavaScript encroaching on the server-side more and more, I’ve seen chatter about unsuitable it is for server systems.

I was one of those guys.  I didn’t care if I could do it client-side.  Give me a post-back and a code-behind and I’ll get it done.  Or: hey, nice client-side implementation of that.  You know the next Gecko or WebKit or IE will mangle it, right?  Hope they don’t release a new version tonight.

My perspective today is that JavaScript is the language we’ve got.  If you hate it, well, there are lots of jobs working on systems and applications that don’t touch web browsers.  However, if web browsers are where your audience is, then you’d better get comfortable.  I’d bet that most of your beef with JavaScript (if you have beef) is actually with browsers.  They’ve been, well, inconsistent.  But JavaScript is good (as in “flexible” and “expressive”), and getting better.  (And I don’t see a real competitor for it.)

In terms of that encroachment, I think stacks like Node are really intriguing.  I think more traditional stacks will definitely catch up, but I think it says a lot that the first group to patch together something like that (a server that was light, event-driven, and I/O intensive) used JavaScript (and V8) to do it.

I’m reading Douglas Crockford’s JavaScript: The Good Parts right now.  It’s great.  I had the chance to see Mr. Crockford last year — he talked for a day at Front End Masters — but missed out.  I wish I’d been there.

Barry Lapthorn’s WPF/MVVM Quick Start Tutorial

WPF/MVVM Quick Start Tutorial over at CodeProject:

So to address this, I’ve written this based on what I would have liked to have found as the #1 hit on Google after typing ‘WPF Tutorial’. This article may not be 100% correct, or even do things ‘the one true way’, but it will illustrate the main points that I wish I had found in one place 6 months ago.

Fairly good walkthrough of MVVM and why you would use it.  (I had to ramp up yesterday, and spent probably too long trying to sort out the “why”.)

My thoughts:

  • I very much appreciated that the business objects were chosen so that “Name” would not be one of the business properties.  MVVM adds enough new classes, where there are enough opportunities to misunderstand and poorly name things, that having these things completely separate is helpful.
  • The code is very elided.  I missed the bold warning to download the code, and things were much smoother once I did.  (Generally, web articles shouldn’t require that you download code samples, though.)
  • I like the idea of “write something quickly, in a naive way, then patch it up with best practices.”  More articles should be written from this perspective.
  • However, it could be clearer when we’re doing something “quick and dirty” with the intention to clean it up later.
  • I wasn’t famliar with the “xmlns:local” namespace concept, so I spent a half-hour trying to figure that out.
  • I really liked the progression from not working, to working, to using a little more of the .NET framework, to growing our own framework.  It made a lot of sense.
  • I still have a sense that MVVM frameworks replace a lot of brittle syntax (which, to me, is unfamiliar and disorienting) with a more stable, extensible platform (which, being new to me, is also unfamiliar and disorienting).

I think good next steps from this article are to find a framework that I can try out a little more deeply.  Or, I may revisit knockout.js: with a better understanding of the problems it’s trying to solve, I may have better luck with it.