Great Post on the Concurrency Hazards of Stateful Web Applications

When people think about stateful web applications, I believe that most of the concerns usually focus on the scalability of that web application. Stateful web applications are more difficult to scale out, as you need to ensure that all requests from the same session are handled by the same application instance, or you need to setup some mechanism so that instance A can pick up and resume the session that was started by instance B, creating a potential bottle neck.

However, with the new breed of web applications out there that allow a session to be sending multiple, possibly concurrent requests (via practices like AJAX), a new crop of concerns arise. Most (if not all) web containers take care of managing concurrency concerns between sessions. But, most do nothing to manage concurrency concerns within the same session.

Java concurrency master Brian Goetz provides the details at http://www.ibm.com/developerworks/java/library/j-jtp09238.html

Good Post on the Pitfalls of an External DSL

As I have mentioned before, I’ve been working on an (internal) DSL at work to aid with testing. I just finished reading a post by Michael Feathers entitled How to Fail with External DSLs. It’s a good post that brings to light some very real issues regarding the development of external domain specific languages. I laughed to myself when Michael identified one of the pitfalls as being the inability to attract new hires to work on a language that they would not be able use outside of your company, as I turned down a job right out of college for that exact reason.

Proprietary Software Not Necessarily The Best Software

I’m a big fan of open source software. I use it extensively at home and at work. I’ve also contributed to a few projects here and there. I think that on average, it is usually more secure, more stable, and more extensible than proprietary software. Oh, and it’s usually free too.

I got a little reminder today that proprietary software isn’t necessarily the best software. I recently upgraded to Ubuntu 8.10. The first time booting up into the new version of the OS, a little pop-up notified me that some proprietary drivers were available for my graphics adapter. Sweet, I thought. Maybe now I can finally enable Compiz on my work laptop. The driver installed without a problem, and sure enough, most features of Compiz worked without an issue. However, over time I noticed Compiz was slowing things down a bit (it’s an older laptop, with an older graphics adapter), so I disabled it.

Today, I was scheduled to give a presentation to a small group of peers at work. I arrived on time, hooked up my laptop to the projector like I’ve done a hundred times before, and hit the magical key sequence to change the resolution and output to the projector. Nothing. I tried again and again, even rebooting. Nothing. Fifteen minutes after the presentation should have started, I finally bit the bullet and booted into Windows to give the presentation…something I have only done one other time since putting Ubuntu on my work laptop. Man I was pissed, especially since it took Windows forever to boot…reminding me why I switched to Ubuntu in the first place.

This worked fine in version 8.04. What the heck happened?

When I got back to my desk, I did some searching on the web, and found some forum threads indicating that a proprietary video driver could be the cause of such an issue. Remembering I had enabled the proprietary video driver, I quickly disabled it, hooked up to a projector, and tried again. Bingo! Worked like a charm. As a side benefit, I also got the dual-monitor support that had been advertised in the newest version of Ubuntu. Up until now, I couldn’t get that to work either.

So, the moral of the story is, just because it’s proprietary doesn’t always mean it’s better.