I think I was reading about CommonMark when I saw this mentioned.

Sad because true?

Honestly, I think CommonMark is probably a pretty good idea, all things considered. There are people that are going to get concerned with a "spec" that's, as CommonMark puts it, "ambiguous". You don't want strange edge cases that seem to conflict with reasonably hard and fast rules. I think the best complaint I've seen (and I can't dig the source back up in 10 mins of googling) is the "underline for headers" issue.

What do you do here?

This is a header. Or is it the last thing in a section before a horizontal line?
--------------------------------------------------------------------------------
I'm not sure. You tell me.

Apparently the original spec didn't address many edge cases like this, and you'd have to go to the code. I can't recall why that code wasn't good enough, other than folks occasionally disagreeing with it. And different users do have different needs, so I think that's a fair complaint.

And most importantly for coders, CommonMark gives you a test suite. We like to have explicit pass/fail conditions. You're only as good as your metrics and QA.

But yeah, any time somebody's providing something called Babelmark to help you see what's going on in different flavors of a markup format with unresolved edge cases, you've got a fragmentation problem.

Also worth mentioning: Is HTML a Humane Markup Language? from Atwood. Probably as good a visualization of why we might prefer Markdown to some other markup language that's got some traction right now as I've seen, though Atwood here (contra Atwood now, afaict) strangely decides that HTML is easier to eyeball than Markdown.

In other news, I had this choice definition of POJO open from Martin Fowler's site. I was pretty confident when I read "Anemic Domain Model" that he'd meant Plain Old Java Object, but the backstory is both hilarious and tragic.

POJO An acronym for: Plain Old Java Object.

The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000. In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.

(ー_ー﹡)

Labels: coding, fowler, markdown, standards

While reading up on how to properly respond to Accept-Encoding:gzip requests with a quick node server I'm hacking up, I ran into this support article about IE6:

In Internet Explorer, the Urlmon.dll file uses an internal buffer to read compressed data. Urlmon.dll fills this buffer when more data arrives and empties the buffer when Urlmon's client, Mshtml, reads data. The bytes that remain to be decoded in the buffer may be small (8 bytes or less) and the data contained in the buffer decompresses to 0 bytes. Frequently, this data is gzip frame data. When Mshtml receives 0 bytes, it thinks that all the data is read and closes the data stream. As a result, the HTML page sometimes appears truncated.

No, I'm not saying you necessarily need to code around the foibles of a now [thankfully] fairly rare version of IE.

What I am saying is that this is a rookie mistake that made it out of QA at one of the best software engineering companies (particularly in 2002-2003) there is, and in one of its marquee products. Anyone who has used streams has run into issues with buffers similar to this one. This is, at worst, a slight variation on theme.

Though I'm not suggesting you forgive bad code either, it is slightly comforting to know that, at least 12 years ago, Microsoft let something so [okay, potentially anachronistically] glaring slip.

Labels: coding, html, ie, standards, testing

We at Webmonkey hope it’s obvious that building WebKit-only sites is a waste of time. If you’re only interested in iOS users then take a tip from Instagram and build a native app.

Labels: browsers, firefox, standards, webkit

In this sample paragraph, 70% of the letters are on the home row in Dvorak, with 15% top and 15% bottom. In QWERTY 30% are on the home row. Beware, it takes a little getting used to, especially if you're transitioning from a standard QWERTY keyboard.
...
The standard QWERTY keyboard layout was designed to prevent typewriter jams (which is no longer necessary with computers), whereas the Dvorak layout was designed specifically to be easy on the hands.

Many Dvorak users have no problem learning the normal Vim commands with a Dvorak layout. The movement keys may not look it at first but are in fact pretty intuitive -- J and K are on the middle and index fingers of the left hand, right next to each other in the same order as on the qwerty layout, while H and L are the index and pinky fingers of the right hand, so the one for left is on the left -- again perfectly accessible.

I have been using Dvorak (as X keyboard map) and Vim for about two years now, without *any* adjustments (concerning Dvorak) to Vim at all, and it works great. The solution imho is to simply remember Vim commands by their name, rather than their keyboard position (e.g. I think I want to d(elete) 2 w(ords), and hit d2w without thinking about the key positions (my fingers know the position themselves).

Effectively my brain was trying to wire three kinds of cursor movement modes:

1) Dvorak Vim with remappings (when I'm on my own machine)

2) Dvorak Vim with no remappings (when I'm on someone else's machine and have the keyboard remapped)

3) Qwerty Vim (when I'm on someone else's machine and don't have the keyboard remapped)

This is, simply, too much. Your life as a programmer is hard enough without you having to learn three different spatial layouts for text editing commands.

Labels: keyboard, pain, standards