(Skip to main content.)

Blogs Quoderat Land and Hold Short

Quoderat

Archive for June, 2007

A Victorian British artilleryman blogs

Friday, June 29th, 2007

William Henry Ranson

Gunner William Henry Ranson (born 1843) has started a blog about his life in the ranks of Royal Artillery and as a civilian in Canada right after Confederation:

http://whranson.blogspot.com/

Gunner Ranson was my great-great-grandfather. After serving in the Royal Artillery during the 1860s, he ended up settling in Canada permanently in the 1870s. While many British officers kept diaries and wrote memoirs, very few men of the ranks did — although a good number could read and write, few had the inclination and the available time (and light) to do so — but my great-great-grandfather was an exception. While we don’t have the original diary, we do have a summary that he wrote later in life as a memoir, based on the lost diary, giving a working man’s view of both the British military and of later civilian life (often more brutal) in Victorian Canada.

My brother Tom has had the memoir for some years and has been trying to decide the best way to edit and publish it. In the end, he has decided to publish sections serially as a blog. I encourage anyone interested in British or Canadian history to read this. The blog format reminds me very strongly of the serial magazine publication common during the Victorian period.

Coding lessons from university

Wednesday, June 27th, 2007

Dare Obasanjo, smart code guy and occasional punching bag for the anti-Microsoft people, is collecting lists of Three Things I Learned About Software In College. I posted mine in a comment on his blog, but decided to reproduce them here. Note that these are not lessons you learned 10 or 20 years later, but what you discovered back then.

I coded a lot in university — some of it for pay — but fortunately, I didn’t study computer science or engineering. Here are my major lessons:

  1. Readable code goes further and survives longer than optimized code, especially once you’re no longer the one maintaining it (or if you have to come back to it two years later).

  2. If you write code that makes you feel like a genius, throw it out — you’ll realize later that it’s crap. If you write code that makes you feel like a competent tradesman, you’re on the right track.

  3. No matter how smart you are, everyone — even the most incompetent loser of a coder — knows at least one thing you don’t. It’s a good idea to listen.

Note: If you want to record your own list of three things, please leave it as a comment to Dare’s original posting, not here.

My biggest problem with Wikipedia

Friday, June 22nd, 2007


Summary: You can’t partition a web site’s users into discrete groups by language.

I don’t worry much about Wikipedia’s objectivity or reliability — no sources (especially not newspapers or Britannica) are objective or reliable, and at least Wikipedia preserves its conflicts and controversies in comments and edit history — but I do have one bit problem with the project: WHY THE *^%*& DON”T THEY HAVE SINGLE-SIGNON?

I usually edit in English, but I can also make at least minor contributions to Wikipedia in French, German, Spanish, Italian, and Latin, and sometimes also contribute to Wikimedia. Every one of those requires me to create a separate account! It is absurd that my username and password for en.wikipedia.org won’t work for fr.wikipedia.org.

Don’t make this mistake with your own webapps, kids. Lots of people in the world are comfortable working in more than one language, even if they’re not fluent in all. It’s good to make a site available in more than one language, but don’t expect language to partition your users into discrete groups. Don’t lock them into a single language with a cookie, or limit their accounts to one language domain — multilingualism is extremely common around the world, even in the U.S. (how many American users would want to be able to use a site in English and Spanish if given the opportunity?)

Maybe the women are right

Thursday, June 21st, 2007

Summary: Perhaps the women who don’t choose computer programming are making a good choice, especially with the deteriorating working conditions, stagnant or falling salaries, and offshoring.

Recently, we’ve had a few postings about women in computing (or the lack thereof) — see Bray, Wood, Tenison, and Bray (again), all ignited by a piece in devChix.

These postings all assume that we need to do something to pull more women into coding. Why? Do we think there are there lots of women would be happy coding, but aren’t smart enough or motivated enough to choose the right careers for themselves, or are too timid to deal with any barriers unless someone comes along and dismantles them first?

Listen to the market

In an age where we’ve come to trust central planning less and the free market more, why not try to learn from the labour market instead of trying to push it ways it doesn’t want to go?

If we assume that the majority of working women are smart, strong, motivated, and brave, then we can also assume that they have good reasons for choosing their careers. And in fact, it turns out that their track record isn’t bad. For example, in the 1970s and 1980s, women were grossly underrepresented in manufacturing and overrepresented in lower-paying service-industry jobs like retail. But when manufacturing starting offshoring in the 1980s and 1990s, it was the women who were still working (often as managers, at this point), while the men were at home, depressed, collecting welfare cheques or trying to retrain for jobs that paid a fraction of what they used to earn.

Now, while there’s lots of work connected with tech, we see pure coding increasingly being offshored, the same way that manufacturing was 20 years ago. There’s no shortage of women working in jobs connected with computers, but instead of coding, many women choose onsite consulting, training, marketing, and other jobs that are not only social but require face time with customers, and as a result, are much more difficult to offshore.

Of course, if you absolutely love coding, like I do (and most of the people reading this do), you’re going to work hard to try to find a way to keep doing it, whether you’re a man or a woman. But if you don’t feel that burning love, why let yourself be dragged kicking and screaming into an industry where salaries are falling, jobs are fleeing, hours are increasing (bye bye weekends!), and workers are increasingly treated as interchangeable cogs on a development assembly line, without even the (questionable) union protection their parents had in their factory jobs 20-30 years ago?

The lawyers …

Tuesday, June 19th, 2007

Lawyers force companies to write page after page of end-user license agreements (”clause xix: The said user hereby indemnifies ACME Widgets against any harm caused to his/her pregnancy by use of this spreadsheet”) and disclaimers (”ACME Widgets does not intend that this flight-planning software be used to plan an actual flight or for any other aviation-related or planning-related activities”). We live in a litigious society, so companies need to protect themselves from spurious lawsuits.

But is that true?

When I read blogs and other stuff written by lawyers, VCs, and other similar professionals, I’m usually struck by the lack of legal disclaimers — they don’t seem to worry so much when it’s their own necks on the line, or are satisfied with one very brief, casual-language disclaimer instead of pages of B.S.

That leads me to two questions:

  1. Do disclaimers and long EULAs actually work? Does the amount of legal text have any correlation (positive or negative) with the likelihood of being successfully sued?
  2. Is legal mumbo-jumbo something that lawyers push on companies, or something that paranoid company execs demand from their lawyers (maybe because everyone else has it)?

I’d be interested in pointers to any studies, etc.

XML 2007 Call for Participation (closes 31 August)

Thursday, June 14th, 2007

XML 2007

The Call for Participation in XML 2007, the world’s largest and longest-running markup conference, is now open until Friday 31 August:

http://2007.xmlconference.org/public/cfp/4

The conference runs from Monday 3 December to Wednesday 5 December 2007, and includes a keynote by Jason Hunter, one of our most popular speakers at past conferences.

Thanks to Edd Dumbill and his startup, Expectnation, we have a much simpler, better-designed web interface for submitting proposals this year, so please drop by and take a look.

Changes for 2007

There are a few changes for the conference this year:

  • There will be no separate tutorial day; instead, the regular program (three tracks) ends at noon on Wednesday, then Wednesday afternoon will be devoted to a special training track for all different skill levels (no separate registration required).

  • This is the only call for participation; there will be no late-breaking call this year.

  • On one of the evenings, we plan to offer lightning sessions for standards groups — each group will have 20 slides and 6 minutes and 40 seconds to let us know what they’re working on. This will be a great way to learn a lot about a lot of specs and standards in a short time.

  • We continue to encourage presentations on open data and document technologies other than XML, such as JSON.

We look forward to seeing you in Boston this December.

REST, the Lost Update Problem, and the Sneakernet Test

Saturday, June 9th, 2007

Dare Obasanjo is giving a bit of pushback on the Atom Publishing Protocol, but the part that caught my attention was the section on the Lost Update Problem. This doesn’t have to do with REST per se as much as with the choice not to use resource locking, but since REST people tend to like their protocols lightweight, the odds are that you won’t see exclusive locks on RESTful resources all that often (it also applies to some kinds of POST updates as well as PUT).

How to lose a REST update

  • I check out a resource about “John Smith” (as a web form or an XML document, for example), and correct the first name field to “Jon”.
  • You check out the same resource, and correct the last name field to “Smyth”.
  • I check in my changes.
  • You check in your changes.

You have corrected the last name to “Smyth”, but have inadvertently overwritten my correction of the first name with the old value “John”, because you never saw my update.

Detection, not avoidance

Without exclusive locks, there’s no way to avoid this problem, but it is possible to detect it. What happens after detection depends on the application — if it’s interactive, for example, you might redisplay the form with both versions side by side. I don’t mean to diminish the difficulty of dealing with check-in conflicts and merges — it’s a brutally hard problem — but it’s one that you’ll have whenever you chose not to use exclusive resource locks (and even with resource locks, the problem still comes if someone’s lock expires or is overridden). Managing multi-user resource locks properly can require a lot of extra infrastructure, and they have all kinds of other problems (ask an enterprise developer about the stale lock problem), so there are often good reasons to avoid them.

State goes in the resource, not the HTTP header

Dare points to an old W3C doc that talks about doing lost-update detection using all kinds of HTTP-header magic, requiring built-in support in the client (such as a web browser). That doesn’t make sense to me. A better alternative is to include version information directly in the resource itself. For example, if I check out the record as XML, why not just send me something like this?

<record version="18">
  <given-name>John</given-name>
  <family-name>Smith</family-name>
</record>

If I check it out as an HTML form, my browser should get something like this:

<form method="post" action="/actions/update">
  <div>
    <input type="hidden" name="version" value="18" />
    Given name: <input name="given-name" value="John" />
    Family name: <input name="family-name" value="Smith" />
    <button>Save changes</button>
  </div>
</form>

When you check out the resource, you’ll also get version 18. However, when I check in my changes (using PUT or POST), the server will bump the resource version to 19. When you try to check in your copy (still at version 18), the server will detect the conflict and reject the check-in. Again, what happens after that depends on your application.

The Sneakernet Test

I think that this is far better than the old W3C solution, because it (1) it’s already compatible with existing browsers, and (2) it passes what I call the Sneakernet Test — I can take a copy of the XML (or JSON, or CSV, or whatever) version of the resource to a machine that’s not connected to the net, edit it (say, on the plane), then check it back in from a different computer — I can copy it onto a USB stick, take it to the beach, edit it on my laptop, then take it back to work and check it back in — all the state is in the resource, not hidden away in cryptic HTTP headers.

By the way, if you don’t trust programmers to be honest when designing their clients, you can use a non-serial, pseudo-random version so that they can’t just guess the next version and avoid the merge problem, but serial version numbers should be fine most of the time.