« June 2005 | Main | December 2005 »

October 28, 2005

Spellcheckers, prosciutto and cross-site scripting

Curious note on Language Log regarding Artifacts of the spellchecker age. I was reminded a bit of bad merges and twitchy refactorings (such as removing seemingly unused methods still referenced through reflection). I thought the final note was worth a chuckle or two:

One very odd type of substitution started popping up a few years ago among users of Yahoo Mail. If an email in HTML format was sent to a Yahoo address and contained the string eval, it would mysteriously get changed to review when the message was received. So medieval became medireview, retrieval became retrireview, primeval became primreview, and so forth. (In French messages, the word for horse, cheval, would become chreview.) It turned out that eval was one of a number of strings that Yahoo's security filter automatically replaced in order to prevent cross-site scripting attacks.

Moon Landing

Moon Landing This is one of the few pictures I happened to come across of my grandparents seated next to each other (most photographs tend to be of large groups taken from quite a long distance, and therefore require a bit of interpretive story telling to get the time/date/context). I like this particular photograph (as scratched up as it is) precisely because it stands in contrast to all those other family pictures full of aunts, uncles and cousins whom I barely remember and have a hard time pointing out from fifty feet away. I also imagine the astronaut waving at the television camera.. which is appropriate enough when you think about it. Here we have a camera on the moon transmitting back to earth, fed through to a television where, at the right moment, my father takes this picture of the astronaut posing with my grandparents for just such an occasion so that, years later, their grandson could scan it in for posterity.

I'm sure this type of picture-taking was a common practice during the moon landings and that other families have such pictures stored in their attics-- after all, how else would millions of television watchers commemorate such an event without so much as a ninety hour Tivo in the house? The mind truly boggles.

In the mean time, suffice it to say that my grandparents only visited the U.S. for brief periods of time until their passing (I have very few memories of my grandmother in particular). The horse figurines on top of the television still exist believe it or not, as does the television-- more furniture than appliance now, but as functional and irradiative as ever.

October 25, 2005

A word on this blog

Since this is a new blog, I figure I should get a few things out of the way.

  1. I don't have any categories set up, but most of what I plan to put here for the next few days will be OOPSLA related (I took some notes last week with doing this in mind, and these should spur me on a bit). Eventually I might make the subject matter more of a general nature (writing and photography), or splinter things into "software" and "non-software". We'll see.

  2. "Why the blog?" A few reasons-- non-work related email was becoming less appealing, and work-related email, while occasionally of a general nature, isn't easily shared with non-work colleagues. I'd rather put my thoughts here, and if people find it interesting, they can pick from it at will.

  3. "What's a 'semper creo'?" I'm not a latin major, but unless the internet lies, it means "always create" or "ever creating". I played around with a few sayings and phrases, but these two words sounded good together, and damn it, even if the conjugation is wrong and it's not perfect-- well, welcome to the site. After all, if you want the news, get a newspaper. :)

  4. I'll try to make things entertaining from time to time without posting code.

  5. As a technical aside, you'll notice that I'm not using Blosxom anymore. I had a thought that I'd blog during OOPSLA (hah! right!), and Blosxom is almost certainly one of the fastest ways to get up and running after you blow away your old website for the umpteenth time.. but now that my initial plans fell through, I took a step back and went with MT. Still using the markdown plugin however, as I'm a big fan of it.

October 24, 2005

"Breakthrough Ideas" - The Acceptability Envelope

Tuesday @ oopsla

Of all the short talks in the Breakthrough Ideas session, Martin Rinard's presentation prompted the greatest number of questions and comment from the audience. He gave a very quick and intense talk on Exploring the Acceptability Envelope. The point of the talk was first to propose that we can consider software "correctness" by using statistical analysis and probability to arrive at a level of acceptability in software, and then to present some examples supporting this idea. In short, he favored probabilistic reasoning over logical certainty. After thinking this over for a while, I admit this idea started to appeal to me.

The way I considered the question was to start with asking why we look for (and expect) certainty in the answers provided to us by our software, while at the same time maintaining a certain tolerance level for non-critical errors that keep us from getting the answers we want.

To paraphrase one way of putting forth the point here (my words only-- hopefully I'm not butchering the intent of the presentation too badly), given a series of "x" tasks needed to complete a process, and "x-n" failures at any given time, it is possible to reason about the outcome of the process in certain circumstances where "n" is either low, or "x-n" failures represent non-critical parts of the entire process.

For example, if 100 tasks are required to complete in order to determine a given outcome, but any one of those tasks is susceptible to failure, rather than returning an error (or no result) to the user, a given system should be able to determine the likelihood of the outcome based on probability. I take it to mean that the term "outcome" here is contextual. In mission-critical systems for example, we may need to know that all required tasks completed successfully in order for us to proceed.

On the other hand, when booking a trip to Memphis for the weekend and requesting an aisle seat, I could see probabilistic reasoning being pretty helpful. If the steps involved include writing to the database and interacting with two third-party systems in order to make the request, failure to receive a response from one of those systems would probably generate either an error message back to the user, or long wait times. As it is, errors are propagated back, and long wait times are often mitigated by putting the user's request in a "wait" state, setting a placeholder and resorting to asynchronous communication with the third-party systems. This solves the technical problem, but not the user's problem-- they often don't want to know that certain parts of their request are in a "wait" state. And as software designers, we shouldn't presume anything about the user's workflow apart from the software! Maybe they need an answer right away in order to complete another request-- if so, the development effort put into implementing the asynchronous communication doesn't help the user at all. That said, why not avoid the complexity of dealing with the asynchronous messages in the first place, give up on the third-party response and present the user with an semi-intelligent conclusion based on the probabilistic outcome? If the probability of success is high even with a given failure rate, better to inform the user of success, and reduce the overall complexity of the system at the same time in this case, than to either leave the user in limbo, or (worse) show them some meaningless error message like "Unable to communicate with third-party system".

This all may sound weird, I know. I thought so at first as well. But then I started thinking about it in human terms-- were I a person standing in the room giving you directions around an unfamiliar part of town, I might be wrong about certain landmarks, the distance between two streets, the number of stoplights between here and there, etc.. yet somehow, while I reason about directions and guide you through them, I don't avoid giving you any help at all just because I completely forgot one step in the process (like how to get out of the parking lot, for example). Likewise, (person-to-person), you're more likely to to find my directions useful in some way, shape or form, even if I am unsure about a few steps. Why couldn't we approach software like that? Take the worst case scenario in each instance: in the person-to-person example, if my directions are completely off, you can probably stop and ask for directions. In the software example, you will probably call a help desk anyway.

Software is just going to keep gaining in complexity, and systems will need more and more work integrating with each other. It's not a bad idea to ask ourselves, where do we want to invest our time developing these systems? Hire a staff of thirty to chase bugs everywhere and sanitize a limited number of "happy paths" through the system? Or use the same size or smaller team to focus on critical elements of the system, using probabilistic reasoning for other parts, in order to get the user some sort of feedback so they can get back to more important things?

In any case, I found Rinard's fairly engaging as a speaker. Doing a search on MIT's site, I found some interesting material he's published you might want to check out as well.

October 19, 2005

Aspects from afar

Tuesday @ oopsla

This has been the first year I've really taken a close look at aspects due to my work at G2, particularly in reference to Spring, so I decided to sit in on this lecture in order to get a bit more perspective on aspects "in the large". I can't say I changed my mind very much about aspects (I still think it holds some promise, but I'm also still skeptical), but I think I've been able to think a bit better about what I do and don't like about aspects.

After remarking that everyone seems to talk exclusively about aspects with respect to extending legacy systems or extending a 3rd party codebase, someone asked the panel why nobody spends much time talking about using aspects in new development (i.e. designing with aspects in mind). Dave Thomas responded that [paraphrase], you probably won't be able to see these cross-cutting concerns early enough starting out, unless the problem domain is very well understood. I find that statement rather curious, since it could be argued that it either reflects an inability to wrap our heads around aspects as a tool to help us reason about the world, or else limits the real impact aspect programming can have on a system.

From my point of view, I like aspects for what they do, not for what they are. They are a code-centric tool, not a reasoning tool. When you start designing a system, so much time is spent reasoning around the code, I can't really see that aspects would be as helpful as other tools. I remember first learning about OO and the first OO program that made me think different about programming in general. OO may not reflect "real world" things, but they always helped me reason about the world. I never talk about cross-cutting concerns in the "real world". That's not to say they don't exist, just that they are artifcats of a world that has been thought through-- not constructs that helped build that world. What people like about cross-cutting concerns almost always relates back to code, never about the formulation and categorization of ideas.

Everybody likes good looking code, but as a general rule, I like things that help me reason about the world better. Or maybe I just haven't seen anyone talk about aspects in a way that has made me go "Wow!".

In response to the question of whether or not all features could be treated as aspects (which probably speaks more to the previous point), I believe it was Gregor Kiczales who mused somewhat sarcastically that anyone who could define exactly what "cross-cutting concern" means should try to provide a good definition of the word "object". He later went on to talk about about people thinking (incorrectly) that aspects == optional, but back-stepped a bit on that point when it was challenged by Jack Greenfield. To be honest, I didn't quite follow the subtext of what was going on there-- if nothing else, I felt the exchange was a bit distracting. I really don't care if aspects are considered of as "optional" components of the application (I'm guessing things like logging were being addressed). Chances are (again, we experienced this at G2) that you'll make mistakes along the way, and to the extent that dealing with mistakes is not optional, aspects are probably not an "optional" part of a given application.

The final comment I'll leave is Dave Thomas wondering if promoting aspects as a tool isn't like supplying needles to addicts-- so we don't really know what they'll do. I share his view that we may have a long way to go in understanding this all.

Miscellaneous points:

  • How to properly version pointcuts along with code?
  • Learning how to read pointcuts (string matching is one of the weakest parts of AOP).
  • Naming conventions are the answer? Need to stress naming conventions.

October 18, 2005

What is this?

Finally some down time.. I decided (rather late) to start writing down some of my reactions to what I see and here at OOPSLA. And, as usually happens when I decide to write on some new topic, I end up blowing away whatever I had up at my web site and starting from scratch rather than append to it, and be distracted by unrelated thoughts from months ago.

I suppose it's an attempt to get into the spirit of things, to be here and nowhere else, at least between breakfast and dinner. I apologize in advance for mistakes of all kinds.. give me a month or two and I'll go back to make corrections (or shoot me an email). Then again, I'll probably end up archiving all of these notes the next time something needs my immediate attention.

Contrary to my usual style, in which I edit and re-edit my remarks in order to polish them up, I'm trying this will hopefully become less a place to summarize points other people have made, than to provide a few questions and/or comments.

The sad truth (for me at least) is that I usually react to keynotes and panel discussion comments an hour or two after they've been made. I feel I need a bit of time to digest all of it.