Posts tagged: Communication

Web Form Verification for Dummies

The standard method for interaction with computer applications has gone from being the command line to being the native GUI, to being the web form. We were awesome at verifying input when it came from the command line — that was simple. Then we were kind of ok verifying input in the native GUI, although quality varied a lot more.

Now we suck at verifying user input from web forms. The current state of code that verifies user input has both managed to take us back to the kindness of the command line when it comes to freedom of input and manages to check all the wrong kinds of things. Why is it so hard to write these checks? I suspect because people don’t really think much about them, and I bet there are more interesting things out there than to write user input verification.

These problems aren’t some beginner coder errors either — they’re rampant on even the biggest sites out there like paypal.

The most common field to get me snared is the phone number field. In 99% of all cases, the site assumes that all phone numbers in the entire world are formatted like US phone numbers. Not, as one could imagine, because I’m claiming to live in America — I clearly just told the site that I live in a European country. So anyway, inputting my actual phone number causes an “invalid phone number” error. Not that there is any mention whatsoever on the site about what the correct format of a phone number is (there are, in fact, even several ways of writing a US phone number).

This sets off a wildly unamusing guessing game of how to “convert” my phone number into a format the site will accept. This practice often costs the sites money as I end up giving up and going somewhere else, frustrated and unable to make a simple online purchase that didn’t really require that phone number anyway, did it?


Another highly amusing game is the one where web sites try to force users to choose “secure” passwords by enforcing the formats of passwords. “You must have at least 6 characters, with at least one letter and one number”. Sounds good, except in general these passwords are restricted to only contain letters and numbers. Hold on, isn’t it common wisdom to include at least one non-alphanumeric character in a secure password?

As such, out of my set of passwords, the only password which tends to pass most password verifications is my least secure one. The idea that you could fix a social problem through technology is somewhat funny anyway — “password1” is not more secure than “password” in any way that really matters.

ErrorThe same thing applies to the old trick of forcing your users to change passwords every month. This can have two potential outcomes — users append a counter to the end of their password, and increment it every time they are forced to switch, or they keep a post-it note taped to their monitor with their current password. Neither outcome is a net gain in terms of security.

Some sites even let the user set a password which is then considered invalid when the user tries to log in (ebay, for instance,  has done this) — causing a prompt for a new password and much annoyance.

Format wars

Parsing stuff is what computers are good at. So forcing me to input something in a strict format is always a loss. Either separate the fields and force me to select the individual parts of a date separately or actually use all that computing power at your disposal to do your user a favor. Telling me you have no idea what I mean by “2009-12-21” because you expected “20091221” is annoying the user for no good reason, even if you told me to not include dashes.

If you find yourself in a situation where you need to verify input  from the web, take an extra minute to consider how you could make things as convenient as possible for the user, which ones of your assumptions only hold true for the region you live in… and when you’re done, whatever you do make sure you tell the user exactly what the expected format is.

Don’t Be an Open Source Douchebag

I love open source software. It provides both a neat training ground for programmers, a good place to go scratch that itch. On the other side of things, it provides awesome software for people, including some software that would never come out of a big development house.

Still, there are some issues with free software that don’t really show up to the same degree with commercial software. One such thing is documentation. It’s painfully obvious that documentation is written by people who:

  1. Already know the software in and out.
  2. Don’t like writing documentation.
  3. Know nothing about how people learn.

For instance, when I started a side project a few months back, I was looking for a build system. After settling on CMake, I set about trying to make sense of it. There’s the ever-present getting started example, of course. And then there’s the full reference of everything you could possibly want (almost).

But in between those, there’s nothing. Well, nothing except a book, which just goes to show you that there’s something missing — a professional writer could obviously make some money out of explaining things in a reasonable way.

The problem with this is that it doesn’t match how people learn. Getting started is a good step, but a relatively small one. Most of the time will be spent incrementally expanding the knowledge, moving from beginner to expert. Most time will thus be spend in some kind of zone in between the “getting started” and “reference of everything” levels.

Worse than that, some open source programmers have a tendency to view their full reference documentation as an appropriate resource for everyone. “It’s all in there,” right? But pointing a beginner at a 40-page document detailing all the options of some application when all they want is to run it properly isn’t very helpful. I’m sure you know what I’m talking about if you’ve ever used an open source command line tool.

That ends us up with the really dark side of free software culture. The true douchebags out there will not only be extremely smartass in their RTFM comments, they’ll also be incredibly sensitive and defensive about the software they’re working on.

I ran into a problem with cygwin’s SSHD implementation last week. In searching for the solution, I found this mail list answer:

  Wrong.  That is uninformed speculation and guesswork.  Stop
spreading misinformation.

  Cygwin SSHD has had the support for fully logging in as any
user since 1.7, as you have already been told and completely
ignored.  Go and read the manual.  The link was in the previous
email I sent in this thread.

  freesshd works exactly as Cygwin *used* to before it got
subauth support: when you log in with a key, rather than a
password, you just end up as an admin user.

Wow. This kind of answer is wrong on so many levels. First of all, while he makes it seem like the functionality has been there forever, cygwin 1.7 is still not even out of beta. The chance that an end user has it is about 0. So, with the current version (1.5),  supposedly cygwin sshd works just like freesshd. This is clearly false, because the original poster reports one working and the other not (which is, by the way, exactly the same results that I had).

So, a user reporting a problem about logging in gets pointed to a long documentation about security settings in a beta version, doesn’t understand a word from that document (no surprise there), and as a result gets told to “stop spreading misinformation”. Truth is, simply installed like any normal user installs applications, one works and the other doesn’t, something made quite clear by an answer from the original poster in a different place in the thread:

> Are you talking about password or public key authentication?
> If the latter, Have you tried the LSA authentication package
> in Cygwin 1.7?
I don't know. I'll try to deciper that. Sounds complicated. In
the meantime, friend is using freesshd.

The essence of what he’s saying (which has been completely missed by the cygwin developers) is that the effort required to get cygwin to work like one would reasonably expect of it is much higher than the effort required to just google for something that just works out of the box. The fact that you could potentially make it work is irrelevant, because he’s not getting any help actually making it work.

He might as well just have said, “I don’t care about making it work for you. It works for me.”

Software companies usually compensate for their complete lack of useful technical support with a good (or at least reasonably decent) amount of help documentation. Free software usually has neither.

I encourage any programmer to practice their technical skills on an open source project. But while you do so, take the opportunity to practice your people skills a bit as well, or why not your writing skills? Don’t be an open source douchebag — someone reporting your software’s flaws is not attacking you personally.

News Flash: Griefing People Makes Them Angry

I read with some surprise about the professor who joined an MMO only to grief people to no end, and observe how they reacted to it. Fine, cruel way to treat people I guess since they had no choice of opting out of his “experiment”, but I’d accept that if he had some kind of point to make… so that’s not the worst of it. The worst of it is the conclusions he comes to from this “work”.

Taste these:

“He believes it proved that, even in a 21st century digital fantasyland, an ugly side of real-world human nature pervades, a side that oppresses strangers whose behavior strays from that of the mainstream.”

“Myers was stunned by the reaction, since he obeyed the game’s rules.”

“It started to not be fun,” said Myers, a video game aficionado. “I became the most hated, most reviled player.”

“He said his experience demonstrated that modern-day social groups making use of modern-day technology can revert to “medieval and crude” methods in trying to manipulate and control others.”


Someone actually grants funds for this nutcase? Hell, I could have told you all of those things at once, without the need to be a total dick to people for two years: There are social systems in any context that go above and beyond that of the rules and laws of the context. Yes, this goes for online communities as well. No, you wouldn’t be stupid enough to do that to someone if you weren’t online and anonymous.

I’d urge Mr. Myers to try it out AFK sometime. A subway train could be a good place, for instance (though I’m certainly open for other suggestions, these things are common). Place yourself in the middle of the doorway. Stand in the way of peolpe trying to enter or exit the train. If they move to sidestep you, follow to block the movement.

This is not illegal or against subway rules, but it will still make people really fucking angry. The social context tells you “don’t do that”, not because it causes people to become “medieval and crude” when they force their way past you violently, but because you’re being a real dick to people if you do.

People started out by asking kindly, but then stepped up their efforts to change his behavior as he ignored them. Like people under threat from abuse AFK, they first tried all the normal, appropriate ways of dealing with normal, reasonably sane people, but then had to go to extremes when this didn’t work.

This has nothing to do with him being a “stranger” (hint: everyone’s a stranger in an MMO), but with the fact that he was making their lives miserable to the best of his abilities.

In any game there will be things that are possible according to game rules, but forbidden due to social context. In Battlefield and other shooters, it’s spawn camping. In golf, it’s crossing another player’s line of putt on the green. In World of Warcraft, it’s ninjaing a target or piece of loot from other players. I could go on for a long time.

In the end, we come down to the simple fact that this guy gets paid for being a twat to people for two years, and tries to interpret it scientifically as some sort of bullying on their behalf.

There are plenty of interesting areas to research when it comes to games… games are still a young medium, and especially the social effects and interactions of MMOs are fascinating. So picking an area with slightly more relevance could be nice. Better teach this guy the basics of human psychology before letting him near another study, though.

Taking a Step Back

I’ve been doing quite some thinking about things, and considering the interpretations my post from the other day has got, and some of the speculations going on I’ve decided to take it and the followup post offline. I’ve tried explaining my viewpoint on it, but it hasn’t seemed to make much of a difference.

I love being able to communicate with fans of the games I make, and I certainly won’t stop communicating on how to make the best games possible for all of you guys.

The Fine Art of Being an Asshole in All the Right Ways


We do code reviews of all code that’s about to be checked in. It’s interesting to see the different approaches to code reviews different coders have. Many (especially junior) programmers tend to lack the self confidence required to go about a code review in an effective manner.

Let me explain that — why would a code review require self confidence? Well, a code review will go over a large amount of code at times, and your job as the reviewer is to find any question marks that might possibly cause any kind of trouble. This is, apparently, a problem for many programmers when they review the code of another (usually more senior) programmer, since pointing out potential errors or problems is seen as somewhat sensitive. I know many coders get very emotionally attached to their code.

You would think this should be something which happens only to junior programmers, but I’ve seen this happen with relatively senior programmers as well. It’s more about character than it is about experience I guess. The reasoning is “I don’t understand this, but this guy’s smart so it’s fine” or something similar, sometimes connected to how much code there is to go through and how long that would take.

However, the quality of a code review is directly proportional to how much you can disconnect your own respect for others. Your task is to understand everything you get shown, and to be the most nitpicking, hard-to-please obsessive-compulsive asshole the earth has ever seen for as long as the code review lasts.

Sound like something you don’t want to do? I hope so. But remember, you’re doing a service here… if there are bugs, someone is going to find them. We have QA people who specialize in finding bugs and piling them up on your desk, producers with a great attention to detail, and if nothing else you can bet someone will find it and it’ll end up on youtube. I don’t know about you, but at least I’d want to see my errors pointed out to me before I check them in.

So here are my tips for doing a code review:

  • Understand everything. If you don’t understand something, make the reviewee explain it again in a different way. Chances are, you aren’t understanding because there’s something strange going on, or because what’s been done is unnecessarily complicated. Either way, if you don’t understand something you can’t guarantee that it’s right. Part of the purpose of a code review is for the reviewee to explain his thinking, and while doing so make for a possibility that he or she discovers errors as well.
  • Be picky. Point out all details, from naming convention errors to coding standard misses to comment spelling errors. Whenever something gets checked in, the cost of changing it is a lot higher. Often the details may be the things that are wrong, and being picky forces you to notice such things.
  • Look at everything. Resist the temptation to skip files where only small things have changed, but like I mentioned above, the details can often be what’s wrong. I can’t begin to count the amount of code reviews I’ve done where we’ve found inverted if conditions and equally dangerous things. The relevant code is simply a missing exclamation mark, but the consequences are far reaching, and if you had skipped the file because it had almost no changes in it, then you would have missed it.
  • Endure. If you feel like you’re being a pain in the ass, think of it as a great favor since the amount of potential bugs you’re stopping is high. It’ll also act as an incentive for the reviewee to focus more on code quality for next time.

Think of yourself as the guardian of quality, personally responsible for the quality of the code you’re reviewing. Imagine that you’ll be the one yelled at if the code is broken, or the one who’ll be put to fix it.

The end result will be much higher quality code.

WordPress Themes