afongen

“I told Owen that Santa’s dead.”

Those were the first words out of Kiara’s mouth when I arrived home one day last year.

If you press her on this now, she’ll insist that she didn’t tell our dear little then-four-year-old that Santa Claus is dead. Just Saint Nicholas. Big difference. :)

We’ve never made a big deal of Santa Claus. Every year people ask if we’ve taken our kids to see him. No, we haven’t. Seeing Santa wasn’t a big deal for us when we were kids, and we don’t want to make a big deal of it with our own children. “What?!” you exclaim, “You have to take them to Santa!” No, not really. Heck, our own mothers look at us strangely when we bring it up.

This is about the time when people assume that we’ve already told our kids the “truth” about Santa, that Santa isn’t real.

No, we tell them that Santa is dead. :-D

Hah. Far from it! We read the stories, “The Night Before Christmas” and the rest. There are so many good ones, it’s not only hard to avoid, it’s pointless. They are an important part of our cultural tradition.

When Owen (now five years old) asks if Santa is a real person, a natural question with a Santa on every corner, we shift the discussion away from talking in those terms. We say that he is very real to a lot of people, that people all around the world tell a lot of different stories about Santa — for example, the Swedish will tell you that Santa lives in Spain. We don’t shy away from the fact that in some parts of the world, he’s just not a significant part of the Christmas tradition at all. We explain that Saint Nicholas was real and did some Very Good Things, and that people started telling stories about him to keep his memory alive, that some of those became stories about Santa Claus. We don’t give him gifts “from Santa,” although others do; we just don’t make a big deal out of it. We stress through our words and actions that the important thing about Christmas is not Santa Claus and presents, but the time we spend with our family, being generous and loving, and infusing the entire year with the Christmas spirit.

At this age, the difference between fantasy and reality is not as distinct as it is for (most) adults. Whether Santa is “real” or not is a non-issue. The magic of the stories, the magic of the season is very real, and that’s what we hope our children carry with them.

No, really. Please, please, pretty please with sugar on top.

I frequently run into problems that developers either can’t figure out or had no idea existed, problems that stem from fundamentally not understanding HTTP.

For example, every few weeks I find myself evangelizing the Post-Redirect-Get pattern. Simplified, it goes like this:

1. User submits form with POST (“buy this stuff!”).
2. Server processes form, sends redirect to the browser to go to the results page.
3. Browser requests results page with GET.
4. Server sends results page.

One trick in doing this is that if you want to display a message about the transaction in step 2 on the page in step 3 (“you bought the stuff!”), you need to temporarily stuff that message into session then remove it when you’re done. Rails makes this easy by introducing the Flash, but it’s becoming more common in other frameworks, too.

Simple enough, and it solves all sorts of problems that I won’t get into now. But I still run into conceptual difficulties:

• Maybe a developer thinks that the browser works directly with Java objects (or PHP, or C#…) and can just manipulate and share these with the server somehow in stateful way. Nope. HTTP is stateless, and your HTML form is just that: HTML.
• It could be that a developer believes that the message can be sent back to the browser in the response in step 2 and be somehow available after the browser gets the HTML page in step 4. Um, no. Not the way you’re thinking.

The nitpicky and clever among you will point out that with trickery and by misunderstanding or misconstruing what I’m saying, it’s possible to do those things. For instance, you could use Ajax and DWR to communicate “directly” with Java objects from browser-based JavaScript. True… but not the point. It’s still not like the browser is a Java client communicating over RMI. Nothing like it. There’s a reason I put “directly” in quotes.

But how about that second example? You could stuff a message in a cookie in the response, and re-use that cookie in the results page. Right? Well, yes. Very good of you to notice.

Dreaming up these workarounds implies that you understand HTTP at least well enough to know its limitations and its mechanics. I’m not talking about you, I’m talking about people who just do not conceptually understand an HTTP transaction. And it’s not just at work, it’s not just among Java programmers, I encounter these issues all over the place and on all sorts of platforms.

I can’t really blame the developers, at least the junior ones. The APIs that we work with nowadays to write web apps remove us from the nitty-gritty of HTTP, just as we are removed from the pain of TCP/IP programming. That might be a good thing, but it leaves us with a leaky abstraction.

So what? So I’ve got a little pet peeve of a pattern. Big deal. What else is HTTP gonna get you?

Unless you have even a basic understanding of HTTP, there will be whole classes of vulnerabilities and design flaws in your web applications. You’ll have insecure session management, for starters, and probably cross-site request forgery bugs. I frequently encounter inadequately restricted URLs because of a misled belief that if a link to a page/resource isn’t exposed, that no one can get there.

Note that I wrote design flaws. These are not just developer problems, code-level vulnerabilities. Poor session management often starts with poor architecture and design. Misunderstanding the basic protocol behind the web can contribute to design problems that manifest in broken code.

How do you learn HTTP? Google around. The third chapter from the out-of-print Web Client Programming with Perl is a good start. If you like paper, I highly recommend Chris Shiflett’s HTTP Developer’s Handbook.

Here’s the trick: it’s not hard! Spend just a few minutes to understand the basics of HTTP. You’ll be a better developer, and your apps will be better for it.

In the five years between graduating from high school and starting college, I spent a great deal of time immersed in literary theory and criticism. How else was I going to spend all those late nights drinking coffee in dark, smoky coffee houses? Once at college and on my way toward a French degree, I continued to read and work deeply in lit crit. But it began to wear on me. A couple years in, by the time I reached a point where coursework had us diving headfirst into literary theory instead of just dipping our toes, by the time when it became the focus of the program, I had had enough. It had all become just so much BS.

Still is.

Sometimes, though, sometimes, it’s fun to read something like this: “Harry Potter and the Unforgivable Curses: Norm-formation, Inconsistency, and the Rule of Law in the Wizarding World.”

When children learn to read and write, they are often taught to memorize spelling rules. In English, you are probably familiar with “I before E except after C.” (I would list more, but I never actually memorized any of them. :) For every rule, there are of course exceptions: eight, height, caffeine… The exceptions may not always make sense, but fluent readers and writers internalize them and understand that the simplified rules that we are taught as children are not sufficient to describe the complexity of a living language.

Visual artists are taught rules of design, the sort of thing that the rest of us find in books like The Non-Designers Design Book. Once they have achieved a level of mastery over these rules, they know when to break them. They understand that the rules are conventions.

Then there are programmers.

I don’t want you to think that I believe this of all programmers — it may even be a minority — but I regularly encounter developers who are made deeply uncomfortable by deviation from rules that they have understood to be set in stone but that in practice can be adapted fluidly. Or those who are just unwilling to accept that there are classes of problems that don’t have a single, clean solution.

I have an unsubstantiated, wild-ass hunch that they’re the same people who work on formal, mathematical proof of the “correctness” of programs. I say this not to impugn their character or ideas, simply to try to understand. I have a liberal arts background, so this is still a foreign way of thinking for me.

(By the way. It may happen that one or two people I’ve talked to recently about these topics will think I’m talking about them. I’m not. Get over yourselves.)

Let’s take web standards as an example. It should be no surprise to long-time readers that I am a web standards advocate. The three-legged stool and all that. I believe that unobtrusive JavaScript is an important and useful way to use standards to best advantage. But I am not a zealot. Sometimes it’s just not practical to take extreme measures to avoid behavioral attributes like “onclick” in your HTML. Maybe you’re using a framework that generates that code, and you can’t get away from it. It’s okay. Take a deep breath. You’ll live. I’ll live.

And then you’ll create something like the UJS Rails plugin to address a shortcoming in your framework of choice. Bravo! I knew you could do it.

Even the standards leave room for plenty of controversy, or at least wiggle-room. Is the kerfuffle over serving XHTML as text/html still going on? I really don’t know. I stopped paying attention years ago but still feel twinges of guilt about recommending XHTML Strict as a standard at work.

Security is an example of a problem that is likely to have less-than-ideal solutions. Consider threat modeling, an important part of a secure software development life cycle. In the threat modeling process, you identify and assess threats and vulnerabilities to your system, identifying those that pose the greatest risk. Security is risk management. It’s a balancing act: if there’s a low likelihood that a vulnerability will be exploited or that it will cause much damage if it is exploited, then you may choose not to devote development resources to creating countermeasures. Sometimes one security solution causes another to pop up elsewhere, and you have to decide which poses the greater risk. It’s ugly. I know.

Accessibility is another of those murky areas. In almost every conversation I have about accessibility, questions arise without satisfactory answers. Are PDFs accessible? They can be. It depends. Is this JavaScript technique accessible? For some people, yes. For others, no.

In all these situations, it comes down to making an informed, professional judgment. Novices do not have the knowledge necessary to make these judgments. That’s what makes them novices. That’s why children learn simplified spelling rules, why budding designers are taught the rules and conventions of their field, why beginning web developers should learn to use web standards and accessible development techniques. Adopting these rules and putting them into practice, over time we bump up against when they fail us. In time we develop a sense for how we can best respond to these failures, to this discord. We learn how best to move past the rules because we understand why they are there in the first place.

I have been shying away from writing about meatier topics here because I think they will take longer than I have to do them justice. And when I start to write something, it seems like I’m just repeating the obvious. Only when I broach a given topic with those who I think are representative of mainstream developers does it sink in that the stuff I spend a lot of time thinking about is all very unknown to a whole lot of people. I suppose that’s nothing new.

I still don’t have enough time to write everything I want to, but here are a few things that have spent a lot of time rolling around in my head, ideas that I think are important and that most normal people think I’m nuts to even spend time on (everyone, that is, except a certain fellow who has recently become enamored with Common Lisp — which exempts him from being called normal).

1. Concurrency.
2. Architecture for scaling. Flexible approach to databases.
3. People’s expectations for software have increased, especially for the type of web apps that I write. The old way of doing things doesn’t cut it.
4. User interface matters. And it’s usually done very, very badly. See #3.
5. RIAs and where HTML & Ajax fall down. See #4.
6. Games, education, Darkstar, and virtual worlds.

Every year I do a presentation or two at the MnSCU IT conference. I’ve been thinking that next year I’ll propose a talk entitled “Your Web Apps Suck (and so do mine)” that brings all those things into a 45-minute rant. But as entertaining as that might sound, I don’t think it fair to submit my colleagues to it. Never mind that “Sam’s Latest Rant” does not a good conference presentation make. So I’m unlikely to. Sorry. Buy me a beer or two and I’ll spill my guts.

In the meantime, I’m going to try to get off my duff and write more. No. Really.

The idea of Mike Huckabee as president makes me more than a little uneasy. But between his entertaining appearance on Wait Wait…Don’t Tell Me! and this “Chuck Norris Approved” ad, he clearly has a certain “wow, he’s a real person” appeal:

(Updated to make my position on Mike Huckabee clear at the outset.)

As part of Marketplace’s series of stories on the American consumer economy, they did a short piece on a family of compacters, people who have sworn off buying anything new for a year.

My family is doing that this year. Nothing new, save a few exceptions like food and hygiene products. We’ve officially been at it since June, though we actually started about a month earlier. From our compact, which borrows from others’:

We plan to follow the principals of the San Francisco group, as follows:

1. To go beyond recycling in trying to counteract our negative impact on the environment.
2. To support local businesses, farms, etc., reducing resources used for transportation.
3. To reduce clutter and waste in our homes.
4. To simplify our lives.

Guidelines:

• Don’t buy new products in stores or online. (Exemptions: children’s pajamas, socks, underwear, swimsuits, and common sense items such as food, hygiene supplies, medicine, cleaning supplies… Use the “fair and reasonable person” standard. You’ll know in your heart when you’re rationalizing a violation.)
• Borrow or buy used items as needed (resale, garage sale, antiques, free internet…)
• Services: barter or support local businesses (plumbers, electricians, auto mechanics, veterinarians, dry cleaners, house cleaners, etc.) and encourage used parts (rebuilt transmission, salvaged headlight unit…)
• Gifts: give used items or “experiences” (museum memberships, massage, classes, charitable contributions…)
• Plants: perennial exchanges, cultivate from free/shared cuttings or seeds. If necessary, purchase from local businesses, farmers markets (not the Home Depot Garden Shop)
• Arts and Crafts: First line of attack: Artscraps! When absolutely necessary (for the professionals and talented amateurs in the group), buy from local businesses and use as you go. DO NOT STOCKPILE!
• Magazines, newspapers, books: no new subscriptions or renewals — read online or from the library, buy used books, share.
• Movie rentals, music downloads: Both OK. Used CDs are OK – or buy directly from artists.

Why are we doing this? Mostly for environmental reasons, to lessen our impact by consuming less. We also have in mind the idea that we can reduce the clutter in our small house. We certainly have clutter aplenty! One of the reasons that we bought a small house in the first place was to limit the amount of stuff that we accumulate. I don’t want a bunch of crap lying around. Buying less new stuff helps, or at least should. We have to be on guard not to buy more old stuff instead, while trying to get rid of things we don’t need.

Buying nothing new might seem extreme. But to tell you the truth, it hasn’t had much impact on our lives. We already bought most things used, including clothing. Yes, other people’s pants. Kiara sews and knits a lot (and does a whole lot of other things), so it’s not like we ever buy mittens. We already used cloth diapers. We used cloth bags at the grocery store when possible. That sort of thing.

The compact has helped clarify a couple decisions, like whether or not to subscribe to a newspaper. We occasionally get tempting offers right around when we realize that we’re not keeping up on the news, but we don’t really need to have a lot of paper dumped on our doorstep every day.

It’s raised interesting and sometimes difficult questions: what about school supplies? Do we send a bunch of used crayons? What if we can’t find used uniforms that fit Owen?

We’ve discovered resources for finding used things. Craigslist is obvious and useful, but there are thrift stores that I never knew about, and the Twin Cities Free Market. Sometimes cities or counties make wood chips available for mulching. Friends and neighbors have tools that we can borrow, and to whom we can loan what we have. There are resources out there in the community if you just look for them.

The biggest sacrifice for me has been books. I buy a lot of technical books, the sort that don’t turn up in local used bookstores or libraries. I’m an early adopter, so they’re often the sort of books that are out of date as soon as they’re published. Sometimes I can get an e-book, but often not. For now, I just make do without. With all the information now available online, many question whether technical books are even necessary, especially on cutting-edge technology. Maybe they’re right. I’ve come to admit that I’ve bought books that weren’t strictly necessary, but the books sure were a hell of a lot easier to read on the bus than a web site.

Overall, though, I feel like the compact isn’t quite the right response to our effort to reduce, simplify, and declutter. I know that we could be doing more. Inspired by the efforts of No Impact Man and, more locally, Riot for Austerity, I wonder if striving to do something else like reduce our energy usage by 50% wouldn’t be more in line with what we’re really trying to do. Reducing consumption is a good step, but it focuses on consumerism rather than a broader range of issues, of things that we do that impact the environment and complicate our lives.

Saint Paul College has been named a Sun Center of Excellence. My favorite part? The URL:

http://www.sun.com/products-n-solutions/edu/programs/coe/

There are so many other things they could have done instead of “products-n-solutions” that would have been more likely.

• productssolutions
• productsandsolutions
• products-solutions
• products
• solutions

Their services and solutions page has “servicessolutions” in the URL. If you try to go to http://www.sun.com/products-n-solutions/ you get redirected to http://www.sun.com/products/index.jsp. (Bravo for that! It could so easily have returned a 404 File Not Found. Pity about the “index.jsp” bit, though.)

And of course, any of that could have been capitalized, but with Sun’s Unix roots, we can hardly expect that, can we?

But no. It reads “products ‘n’ solutions.” How terribly colloquial.

Small things delight me. What can I say.

I’m going to No Fluff Just Stuff for the first time this weekend, Friday through ThursdaySunday. I’ve been looking forward to it awhile, as I hear mostly good things about these conferences. Looking over my planned itinerary, it’s clear that I’m a Neal Ford fanboy. :)

But here’s the thing. This Friday there’s a workshop on bioinformatics and entertainment computing at Metro State that looks like it’ll be great. Chris Melissinos, Sun’s Chief Gaming Officer, will be speaking there, as will Warren Sheaffer, a faculty member at Saint Paul College who’s been doing Good Things with virtual worlds and with teaching Java. Plus, bioinformatics is one of those fields that has just fascinated me since my days as a Perl hacker. Perl was (is?) a big language for data processing in bioinformatics.

Okay, yeah, back up a sec. Chief Gaming Officer at Sun. How damn cool is that? Please don’t be surprised that he has interesting things to say. If you’re confused about why Sun would be doing this, watch Chris’s interview with Scott McNealy.

If my employer hadn’t already sprung for NFJS, I’d go to that workshop. Sigh. It’s still a tough call. Looks like I’ll meet Chris and Warren tomorrow, which will help ease the pain somewhat.

But I’m not done. Oh no.

Gunnar Peterson and Brian Chess will be speaking together at a seminar in early November. Gunnar is known for his writing and presenting about web services and decentralized security, among other things (he introduced me to the idea of misuse cases), and I always enjoy seeing him speak. He’ll be one of the fine lineup at this year’s OWASP AppSec conference giving a two-day seminar on web services and XML security. Brian is founder of Fortify, a leader in the static analysis tools market for software security. Brian recently gave a good interview with the Java Posse. At the event in question, Gunnar will talk about security architecture and governance, and Brian’s topic will be static analysis. This will be a morning well spent, I figure.

However, on the same day, there’s a symposium at St. Cloud State University on Information Assurance, Network, and Software Security. I don’t know anyone who’s speaking or their work — a gap beween academia and industry? — but I am very glad to see this happening. I’d be going if I were not more sorely tempted elsewhere.

What to do, what to do…

This xkcd has left me rolling on the floor laughing:

Update: it hadn’t sunk in that I had a fixed-width design until the image of the comic was borked. It has now been resized, and I’m likely to go looking for another design.