afongen

Not long after I failed to explain Second Life to the Small Bytes crew, Educause posted an interview with Sarah Robbins about teaching in SL, which she’s been doing for a while. That should give you a better idea of the opportunities.

Yes, I’m trying Twitter. I’m late to the game, and Kathy Sierra’s probably right, but what the hell. I figure it will help track my time at a different level of granularity than I do on my work blog.

Update: Yes, I’m irritated that Twitter doesn’t support OpenID. Yes, I’m irritated at yet another silo. But still, what the hell.

I almost forgot to mention that a few weeks ago I appeared on Small Bytes, a technology-related podcast out of Saint Cloud State University (direct link to MP3).
We talked about what “afongen” means, what the heck I do for a living, Erlang and concurrency, and then they start asking me questions about things I don’t really know about: the security awareness program that Minnesota State Colleges and Universities is starting up, and Second Life. That went on way too long — Al is really the one to talk to about Second Life — but on the whole the conversation was fun.

They started Small Bytes as a proof of concept, exploring how to do podcasting and ways it could be used at the university. Since then they’ve found a few; the Women on Wednesday series is sometimes amazing. I’ve found it a fun little view onto campus, even though I want to pound my head into a wall whenever they talk about open source. Check it out.

I recently gave a talk about web accessibility to faculty at Century College. I really have to commend the college for starting this discussion, as well as the faculty who attended. Over the years I’ve given these workshops to web designers and developers throughout the Minnesota State Colleges and Universities system and elsewhere, but this is only the second time I’ve spoken with faculty. That’s gotta change.

Not that I necessarily want to start doing a whole lot of accessibility training again. I worked fervently on the issue for years, and frankly got kind of tired of talking about it. If you’re working as a web developer or designer, in this day and age thinking about accessibility should be second nature. It’s just something that you do. But obviously, if you just look around on the web for a few minutes, you’ll find that there is still much work to be done. It is not second nature.

But this isn’t why I agreed to do the workshop. I did so because as important as it is for college “webmasters” (oh, I tire of that word) to understand accessibility, it is far more critical that faculty do. Online courses open doors for students with disabilities, expanding access to education, in some cases making it possible where it never was before. Enrollment by this group of students is on the rise. But if online courses are inaccessible, as I fear they so often are, then this opportunity is lost.

As I prepared for the talk, I began to hope that faculty might take well to the idea of universal design, at least better than other groups I’ve dealt with. It may be that I have an unreasonable expectation that professional educators are more interested in supporting learning than the general population. But I saw more than a few heads nodding. Universal design is at the core of my message about web accessibility: focus less on making accommodations for specific disabilities, and more on making the course accessible to a broad range of students by addressing different learning styles and strategies.

Traditionally, when a student has a disability that interferes with their ability to participate in a class, they work with the college’s student disability office to arrange an accommodation. The accommodation is specifically tailored to that student’s needs, and in some cases the faculty may in fact never know about it. I don’t actually know how common that is. As I talk with faculty about this experience, conversation quickly focuses on disabilities and legal mandates. Not on pedagogy and helping students learn. Don’t get me wrong: these accommodations are necessary and welcome. But activity around them are often focused in the wrong direction.

I prefer to shift the conversation away from compliance and talk more in terms of teaching and learning. It’s my hope that this helps put us on common ground. And it’s not hard at all: things you do to make web sites (including online courses) accessible to students with disabilities help everyone.

• Providing transcripts of audio and/or video is necessary for those who are deaf or hard of hearing, and also helps those of us who are visual rather than aural learners — myself included. I listen to a lot of podcasts, in part to help train myself to be a better aural learner, but I learn and retain a heck of a lot more from those few podcasts that provide transcripts.
• Presenting information in multiple ways — text, images, graphs, charts, audio, video — not only helps students with various cognitive disabilities, but also addresses different learning styles. It also plays into what we know about learning, that using different channels to present information helps trick the brain into thinking that it’s maybe worth paying attention to this stuff.
• Structuring a document with headers, bulleted lists, and so on certainly makes it more accessible to a screen reader user, but done right also has the benefit of breaking up long stretches of text into more easily digestible chunks, which most people find easier to read.

It was a good but too-short workshop. I hope that faculty got something out of it, and I especially hope that it’s just the beginning. I’ve started adding resources specifically targeted to online faculty to a wiki and will be fleshing that out more in the coming weeks.

It’s time I started wrapping my head around identity management again. Of immediate interest are OpenID and OpenSSO. I’ve been watching OpenID develop out of the corner of my eye, but not paying careful attention. It’s time. The buzz level has gotten too high to ignore, and despite concerns about its limitations, it’s clear that OpenID is going to be a player. I’m particularly interested in how OpenID can work as part of a larger strategy, doing its work in scenarios where it fits nicely (e.g. simple authentication), turning to more heavyweight SAML et al where necessary. As if by magic, the Sun Identity Management Buzz podcast started up again in earnest, with an episode on OpenID (with Coté!) and one on OpenSSO. And sure enough, the OpenSSO episode brings up the OpenID/OpenSSO interop question. Looking forward to more.

I met Garrick yesterday at Coffee & Tea, Ltd. in Linden Hills to have a cup of Kopi Luwak. It’s really worth following that link to Wikipedia if you haven’t heard of Kopi Luwak, because it’s the sort of story that you’re not going to believe, so you might as well read it from a source you’re not quite going to believe, either. :)

When I worked at the Roastery, we sold Kopi Luwak, and I had my chance to roast and taste more than my share of this unique coffee. Talk about pressure: green (unroasted) coffee was running us about $2 or $4 a pound at the time, but this stuff was $100 a pound. A mistake would be expensive. And it still makes me laugh: we’re drinking coffee made from beans that have passed through the digestive tract of a palm civet? How is that not hilarious?

It really does taste different: musty, heavy, rich, strangely complex. Hints of chocolate, old wood, hazelnut. Fresh out of the roaster, it smelled a bit like a newborn baby’s urine. This sounds compelling, I know, but it’s the only hint of its scatological origins. In the hours following roasting, the flavor changed dramatically. A day later, it was like a completely different coffee. Still had that mustiness, still deeply rich, but its few higher notes had faded. I’ve never had another coffee that changed so much so fast.

Jim Cone, proprietor and local coffee legend, said that they roast only a pound at a time, usually enough for about a week. I suspect that what Garrick and I were tasting was more than a couple days old, enough so that much of its delightful or even interesting characteristics had faded. It was good, but not great. Not what I remember. But a good excuse to reconnect with Garrick.

Jim roasts his coffee darker than I prefer, tending more to what you’ll find on the West Coast. If you’ve had Peets, you know what I mean. When something is that dark, it’s hard to taste the subtleties that I’m looking for. No discredit to Jim — as I say, he’s a legend, with good reason: he’s been roasting small batches of speciality coffee for ages, on a roaster that looks like it’s had its share of trips to the local blacksmith. I just don’t usually care for that particular roasting style.

Still, I came home with a half-pound of beans from Nepal. I didn’t even know they grew coffee in Nepal. Nice.

“The deinonychus is coordinated. That means it’s attached to a cord.”

Our boy does like the dinosaurs. And puns, apparently.

(another scene from my life with Kiara)

We use unscented laundry detergent. We have a baby, after all, and perfumes and dyes aren’t good for his delicate skin. They’re not very good for our skin, either, so we favor unscented detergent. But the stuff we’re using now smells bad. I don’t mean “my jeans don’t have that fresh aroma of spring clouds that makes me dream of diving into a mountain stream.” No, I mean “something died.”

Fed up with this, Kiara grabbed a bottle of essential oil and ran downstairs to mix some into our laundry soap. Only after she started a new load did she look to see which bottle she had chosen.

Fennel.

Yes, we have a bottle of essential oil of fennel. And yes, now most of my clothes smell vaguely like something drowned in a tub of black licorice.

In a conversation on the Agile Toolkit Podcast, Dave Thomas mentioned that the Pragmatic Programmers are publishing a book on Erlang. I’m fairly certain he said it was due this summer but I can’t be bothered to check, sorry.

This is good news! The next month or so are really busy for me, working on a couple presentations and a side project or two, and after that I’ll be digging into Scala in a big way, but then I do want to look into Erlang. Why? Concurrency. It just plain fascinates me. I also happen to believe that it will be increasingly important in the coming years, especially with multi-core systems turning up on everyone’s desk or lap. But mostly I’m just interested. Java Concurrency in Practice is staring at me from the bookshelf, I should probably crack that open.

Ah, so little time…

Update: the book has been released in beta.

In his Web Framework Manifesto, David Pollak identifies a number of features that he believes web frameworks should have, and I think he’s right on the money. He starts out with what you’d expect to find from one of the newer frameworks.

• A quick and easy way to map between a relational database and the target application.
• Easy, “right by default,” HTTP request mapping.
• Automatic “view” selection and composition.

So far, so good. In Rails, Django, and other similar frameworks that emerged about the same time with the same values, this is largely accomplished by staying DRY, by favoring convention over configuration, and by being focused and limited in scope. DHH makes much of his having no interest in Rails as a one-size-fits-all framework, and this is a Good Thing. Yes, it means that Rails isn’t a good fit for every app. Get over it. It also means that although Rails et al changed a lot in their emphasis on radical simplicity, they didn’t change enough. I don’t see Rails as the future of web development so much as I see it as representative of a final stage of MVC web frameworks, wrapping up up a lot of good ideas and giving us something to work with as we get over the hump into the next stage. Whatever that will be.

I’ll put my money on a few ideas: component-based architectures, addressing how Ajax shifts how and where state is managed, and better state/scope/workflow management with continuations.

Pollak gets into some of that in his next criteria, which is quite a list. He starts with a discussion of components. (I won’t quote everything here. I really suggest you go read the full piece.)

• Pages must be composed of arbitrary components that manage their own state.
• The rendering of components must be asynchronous based on user-based and external event-based state change.
• Components should be live (or seamlessly persisted) at all times, ready to respond to events.

Right away we’re getting into an area where older-style MVC frameworks like Struts, which is still alive and kicking thankyouverymuch, completely fall down. I’ve been dancing around this for years without getting into it too deeply here, but I just don’t think that MVC is a perfect match for web applications. It is useful as a separation of concerns, but the action-based controllers that we’ve been used to in MVC web programming are becoming inadequate with the rising use of Ajax. We are hitting a wall and should be able to do so much more.Both the Java and the .NET worlds seem to be moving toward components, albeit with slower adoption than either Sun or Microsoft would like. (I don’t know what I’m basing that on, by the way: I freely admit that it’s just a gut feeling. I also admit that I don’t deeply understand the shift to components and what it entails. I just haven’t taken the time.)

• The browser should be honored and feared. That means the back button should “do the right thing”
• There should exist a simple, unified way to describe modal user behavior (e.g., filling out a multi-page form.)
• Sessions should be tied to a browser window/tab, not to a browser session.

I am interested in Seam and RIFE in part because of how they manage state — especially using continuations in RIFE. Seaside has demonstrated what that can be like, done well. Not only do we have continued usability problems with managing state across multiple HTTP requests, but considering that it’s still in the OWASP Top 10, I’d say it’s fair to say it’s a significant security problem, as well.

• Mapping between object fields and HTML (or whatever the presentation layer is) should be “right by default”

We spend far, far too much time messing around with this at a low level, and it offers far too many opportunities for niggling little bugs to introduce themselves. I won’t trouble you with details about how I just spent two days doing something that should have taken twenty minutes. I’m still too angry about it.

It should come as little surprise that I am delighted by Pollak’s emphasis on security. Web frameworks do not do enough for security, period. I believe that developers can and must understand the range of attacks to which their software is likely to be subjected, even if they don’t become security experts, but frameworks should also make it easier to do the right thing than not to. Input validation should be centralized, simple, and a default. Output encoding should be handled properly by default. Access control should be more transparent and pluggable. And so on. Pollak has good suggestions.

• input from the browser should never be trusted, but should always be tested, validated, and destroyed if it is unexpected
• There should be a single way of describing input validation.
• There should exist an orthogonal security layer such that objects that are not accessible to a user should never be returned in a query for the user and fields on an object that are not accessible should not be visible.
• Code should be impervious to a replay attack. That means that fields in forms should have random names that change for each request.
• The framework and runtime should correctly and gracefully deal with non-ASCII characters.

The last one is not just a security issue, but I lumped it in there because it does fit.

I love the idea of random names for form fields. So simple, yet we’re so caught up in the annoying low-level mapping of field names to back-end objects, that it gets overlooked. And as valuable as the Commons Validator framework can be, calcifying field names in even more config files is tiresome, error-prone, and constricting.

Finally, deployment. I’ve written before how as much as I like Rails, Capistrano, and Mongrel, and as confident as I am that a Rails apps can be deployed so they perform, scale, and can be well managed, I’d still feel sheepish suggesting deployment scenarios that change as often as Rails’s “proven practices” seem to. Maybe I should just get over it. Regardless, it’s clearly something to take into account when considering a development platform.

• Deploying the web application should be as simple as putting a file in a known location (e.g., a WAR file on a J2EE server) or by executing a single command (e.g., Capistrano.)
• Deployments should contain all dependencies.
• The production environment should support modern technology including executing multiple threads in a single process and allowing for many “live” objects to be corresident
• The production environment should support hot code replacement
• The development environment should support hot code replacement such that once a file is saved, it becomes live at the next HTTP request.

The last is so very, very important. Shortening the feedback is vital, one of the much-touted features of Rails and other dynamic language frameworks. It can be done with Java and a decent IDE, but not always. And although I think it’s obvious, this is far from universally understood or believed. Not long ago, because of a really slow database load and a design error, a developer I know had to wait 15 minutes for a Java web app to deploy and load. Unacceptable. I don’t know how she or her supervisor tolerated it, because it meant that she could make and test at most four changes an hour. Or, more likely, make more changes than were really safe, which is what a long feedback cycle encourages.

The benefits of frequent and automated testing should be well known by now, or at least I think they should be, so I won’t write ano more about that now.Where does all this lead? Shortly after he wrote this manifesto, David Pollak responded to it by releasing Scala with Sails, now known as the lift web framework. You can get a feel for some of it in the recent announcement on his blog. Lift is written in Scala, a functional/object-oriented language (yes, both) that compiles to Java bytecode, so it runs on the JVM and has access to the Java API. Scala is my next language, if only so I can work with (and on?) lift. Much as I have high hopes for JRuby on Rails, I think that lift is something to watch, especially if the development team can do half of what they set out to do. As is clear from the Pollak’s essay, we need to push web frameworks more than we have done.