(AngularJS) Testing headers with whenGET / expectGET

Jotting this down here in case anyone else stumbles on the same issue(s) in AngularJS.

Suppose you’re mocking out $httpBackend in a unit test and want to test headers, like so:

// Assume $httpBackend and $http have been properly injected above
it("should not send a token if none is set", function() {
 $httpBackend.whenGET("/api-call", function(headers) {
   expect(headers.Authorization).toBeUndefined();
 }).respond(200, {hello: "world"});
 $http.get("/api-call");
 $httpBackend.flush();
});

This won’t work. If a function is passed to whenGET, it expects a true/false return value to signal whether the headers were correct. Instead, try this:

// Assume $httpBackend and $http have been properly injected above
it("should not send a token if none is set", function() {
 $httpBackend.whenGET("/api-call", function(headers) {
   return !headers.Authorization;
 }).respond(200, {hello: "world"});
 $http.get("/api-call");
 $httpBackend.flush();
});

Now, however, when the header test fails, you’ll get the following error:

Error: Unexpected request: GET /api-call

This is a bit misleading, since it implies the $http call somehow never hit $httpbackend. However, the issue isn’t that the GET request was unexpected; it’s that the the GET request with that particular header was incorrect. If you swap whenGET with expectGET, you’ll get a much more sensible failure message:

Error: Expected GET /api-call with different headers

In both cases, returning the correct header should make this failure go away.

The Use and Abuse of Text Messages

I have a new(-ish) pet peeve: receiving a text message when an e-mail (or a Facebook message or whatever) would suffice. As a rule of thumb, if a message does not require my attention within 24 hours, don’t text me. E-mail me.

E-mail’s pretty awesome. I can flag messages I think are important (or star them in Gmail). I can use tools like Boomerang to postpone responding to messages until later. I can search for old e-mails when I need to recall something that someone said. I can set up filters to sort my e-mails based on context. I can forward funny pictures to my friends. I can attach things (like calendar invites!). I can read and write them on my phone or my laptop. I can have more than one e-mail address and separate work e-mails from not-work e-mails. I can CC and BCC and do all the wonderful things that have been part of e-mail since time immemorial (1978-ish?).

More …

Word Wrapper

Many, if not most, programmers leave word wrap off by default when editing code. This is because line-breaks in code can have programmatic implications. Python, for instance, uses line-breaks to indicate the end of a statement. With word wrap enabled, coders may have a difficult time distinguishing between new lines created automatically by word wrap and new lines created intentionally by a carriage return.

That’s all well and fine when you’re working with actual code, but it doesn’t work so well with documentation meant to be written in plain English (or some other traditional language). On one hand, s single long horizontal line of text isn’t very readable — newspapers invented columns for a reason — and horizontal scrolling is a pain. On the other hand, manually inserting line-breaks into text isn’t much better. Adding or removing just one word at the beginning can require deleting and re-typing all of the newlines in a paragraph. And because documentation often lives in the same file as code  (i.e. as comments), most text editors apply the same word-wrapping scheme to both code and documentation.

Some text editors are smart about this and offer ways to automatically re-flow long blocks of text, but it doesn’t seem to be a universal feature in code editors. To help, I’ve put together a simple webpage that uses Javascript to convert long flowing word-wrapped paragraphs to a fixed width text. By default, it uses the industry standard width of 80 characters, but you can change that. You can also use the tool to automatically prepend each line with a characters (e.g. to insert a “#” character to conform to Python’s commenting requirements).

It also doubles as a way to convert fixed width multi-line text back to — e.g. the angle bracket quoted paragraphs in e-mails — back to a traditional word-wrapped single line of text.

You can use the tool here, or check out the source code on Github.

Facebook (Probably) Didn’t Expose Your Private Messages. It Just Made a UI Mistake.

Most folks have probably seen some blog post or story warning them that Facebook has exposed their private messages from 2010 and before on their public timeline, which Facebook denies of course. And Facebook is (probably) right — what you’re really seeing are old wall posts that you thought were private. That’s not much solace to some Facebook users though, who — based on the message content — insist that the messages *must* have been private.

Here’s what I think really happened.

Facebook used to have a wall-to-wall feature, which showed the wall posts between you and your friend in a back-and-forth conversation format. It looked sort of like this. Or this. Because this layout looks very similar to how messages work in Facebook, people treated wall-to-wall the same way they treat private messaging. But as the name suggests, wall-to-wall posts actually go on your (very public) wall. The wall-to-wall feature was removed in late 2010. Coincidentally, people are only reporting private messages on their timeline for 2010 and earlier.

That’s not to say there hasn’t be a privacy snafu. There absolutely is. Regardless of whether they’re wall posts or PMs, old embarrassing messages on your Timeline are still embarrassing. And if that bothers you, you should hide them.

But the cause of this privacy breach isn’t some Facebook engineer inadvertently flipping the privacy bit in the FB database. It’s really a UI / design problem, or more specifically, a divergence between Facebook’s model of users behave and the user’s mental model of how Facebook behaves. Two divergences really.

The first is the aforementioned wall-to-wall issue. From Facebook’s perspective, two users were posting on each other’s public walls. But from the user’s standpoint, based on the visual cues presented to them, they were engaging in a private conversation.

The second is Timeine itself. Timeline exposes old, possibly-private and sensitive information. Again, this is because of a divergence between mental models. For Facebook, the question of whether something is public is a binary decision. When the server receives a request for some particular information, it either provides it or it doesn’t.

But for many Facebook users, public really means accessible. And accessibility isn’t quite so binary. Prior to Timeline, sifting through old messages was time-consuming and difficult (it still is in a way). So by the time an old wall post was buried several months in the past, it may still have been public (as Facebook understood it), but it was relatively inaccessible. Timeline changed the accessibility of old information, and combined with the earlier wall-to-wall issue, we ended up with a huge chunk of Facebook users thinking their private messages were exposed (and in a way, they were).

Some final takeaways / questions:

Don’t trust your memory. When it comes to technology, what matters is what the technology thinks is true, not what you remember as true. As the Wall-to-Wall issue shows, poor UI design can affect how people perceive things are happening on the backend. In this case, if you still think there’s a PM on your timeline, the easiest way to verify this is to cross-reference it against your email archives (if you have your email archived that far back and you had e-mail notifications turned on). Until recently, Facebook would send a separate e-mail for wall posts and private messages. If it’s a private message, the e-mail will say so. And you should notify Facebook, because that’s a huge $#@&-up.

Privacy is often a design problem. Same with security. Or really anything else whether the error exists between keyboard and chair.

How do you resolve old UI mistakes? Facebook was almost certainly aware that many wall posts were intended to be private, despite being marked public. But because of the mis-marking, there’s no easy way to identify what user intent actually was for many of these messages. So what’s the proper response? This actually reminds me of the 2000 election in which many Gore voters likely inadvertently voted for Buchanan. But at least some of those Buchanan voters actually intended to vote for Buchanan, and there’s no easy way to tell who intended what, short of a re-vote. So what’s the fair thing to do here?

How do you roll out new paradigms with old data? Start-ups are all about rapid growth and change. Lots of iterations. The occasional pivot. The problem is this can look a lot like a bait-and-switch. Users may provide a company private information based on implicit assumptions on how that data is being used. And indeed, the company may share those assumptions, at least initially. But start-ups often to change course. Sometimes those changes may seem slight from the start-up’s perspective but strongly conflict with the user’s assumptions about how the data is handled. In such case, what’s the best way for a start-up to handle that?