afongen

Believe it or not, I generally try not to feed the FUD too much, but Steven J. Vaughan-Nichols’s recent measured rant about why to stop using IE is too good to pass up.

Why? Because Internet Explorer, like Outlook, has finally become, to my mind, a permanent security hole that masquerades as a useful application.

The recent IE/IIS exploit really is a bit over the top.

Via Tim Bray, Peter Korn’s comments on CSUN 2004. Apparently there’s quite a bit of accessibility activity in the free/open software and UNIX worlds: the GNOME Accessibility Project, for instance, and the Gnopernicus screen reader & magnifier. And Eclipse. I had no idea. Pity I didn’t know this a few weeks ago.

I recently took part in two panel discussions about technology and disabilities. Panelists included Earle Harrison from the Minnesota STAR Program, Deb Proctor from Minnesota Online (whose doctoral dissertation is on technology and accessibility issues for students with disabilities), student disability coordinators from several local colleges, and myself.

In retrospect, I probably should not have agreed to participate: although it’s still critical to my work, I’m a little tired of talking about web accessibility, especially in the general terms necessitated by our decidedly non-technical audience. I was far more interested in hearing my co-panelists describe how technology has helped and hindered our students and employees with disabilities. Regrettably, in both sessions, web accessibility dominated discussion. Attendees were clearly interested and walked away with solid messages, so it’s not all bad. I was just a bit personally disappointed to see the conversation settle there.

We didn’t just talk about the web, though. Earle, who’s blind, demonstrated some of the technology that he uses every day, including a PAC Mate, essentially a Bluetooth-enabled “Pocket” PC as big as a full-size keyboard. All told, it runs over $5000; assistive technology ain’t cheap. The disability coordinators had some very valuable things to say about the need for textbooks in alternative formats, as well as cautioning us against setting the technical bar too high when moving courses online.

We also talked about the need to consider accessibility in technology procurement. I think that by now it’s standard fare in contracts, but I fear that too often purchasers rely on vendor assurances rather than doing their own assessment. What I didn’t say but wish I had was that it’s important to actually check the vendors’ claims. Consider it due diligence to google around a bit, if nothing else. I’m thinking of one large software vendor in particular whose materials repeatedly claim Section 508 compliance, with no more demonstration or explanation than “programmed to meet standards.” From what I’ve seen (and no, I haven’t done a formal review), I wouldn’t agree with that assertion. So it’s important to push for more information.

Earle brought up Apple’s upcoming spoken interface and accessibility APIs and suggested something that I hadn’t considered: this is a threat to companies like Freedom Scientific, as it moves the capabilities of software like JAWS to the operating system. I’m not sure why, but I have a hunch that Mac OS X apps are more likely to comply with Apple’s user interface guidelines than Windows apps take advantage of Microsoft’s accessibility APIs. Don’t get me wrong, Microsoft has done a lot to enable accessibility. I just think it a shame that developers don’t leverage that work and am excited about Apple’s approach and hope that I understand it correctly.

One final note: the Minnesota STAR Program produces a monthly webcast “radio” program called “Where’s it AT” that discusses assistive technology issues. Good stuff.

• Dale Dougherty handily dispenses with Eolas’s attempts to rewrite history to suit their patent claims.
• Dave Hyatt: “Testing Page Load Speed”.
• Rephlux, a continuous integration tool for PHP.
• Federal Programmers Get Agile.
• Getting ready for Perl 6: Periodic Table of the Operators.
• Passogva, “a collection of FIPS-181 Automated Password Generator implementations” to generate pronounceable passwords. Not my favorite thing in the world, but a password that people can remember is more secure than one that they need to write on a post-it on their monitor.
• Another password generator that I like a bit better but whose passwords are harder for most people to remember, even with the “show phonetics” option.
• How Tomcat Works. 45% discount if you order from the author’s company’s site.

I’ve got to start writing here again.

MACCAWS has released a white paper, “The Way Forward with Web Standards” and a companion non-technical primer. It’s so strange that we’re still fighting this battle. Why is it that we can be in a rush to meet standards like J2EE — which is difficult to understand & implement and is often overkill — but meet such formidable resistance to the suggestion that we meet basic web standards, which are easy to understand & implement and have such clear benefits? Marketing, I suppose. I face this all the time:

• “Of course we should strive for accessibility, but we shouldn’t spend extra time on it.” Never mind that if we do it right in the first place (i.e. employ web standards), accessibility pretty much falls into place with no extra effort.
• “What does it matter that this CMS doesn’t generate valid HTML? It still looks fine to me.” Sigh.

Hopefully the MACCAWS project will help.

Kathy Sierra is right: Pair Programming is NOT always a choice. Some people are work best alone. This reminds me of something that really got on my nerves during a keynote speech at the Minnesota Government IT Symposium. The speaker’s message was that if pessimists only tried a little harder and improved their attitude, they could be optimists, too. What a load of crock. His assumption that pessimists even want to be optimists is not only seriously flawedflat-out wrong, it’s insulting.

Here’s a tip: no matter how great a product is, no matter how well it seems to meet your organization’s needs, if the people who are going to work with it hate it, it will fail.

I just spent three days in meetings in St. Cloud, an opportunity to get away from the office while our cubicles are being torn down and rebuilt (bit of a physical reorg to match the recent organizational reorg) and to outline the direction that our web development will be taking in the next couple years. If we had been at a conference center, we would have called it a retreat, I’m sure, but instead we were in a small conference room in a basement labyrinth in a building that just screams “I was built in 1969! I was built in 1969!” There’s a guy in our regional computer center there who has been working in the same basement office since 1971. Crazy.

The first day was highly energizing, the second day exhausting, the third energetically neutral and quite enlightening. Today we hashed out a process for moving code from development to QA to production. Largely because of concessions that we made for existing processes, it ended up being far more complicated than I ever expected. For one thing, our introducing CVS entails an enormous shift in code management. The way that I would normally think to use CVS, branching off major releases to run through QA, won’t work because of conceptual hurdles and because it doesn’t mesh with the current process. The culture clash between our long-time core systems developers and newer developers working on web-based apps will be a fun one to watch. I understand that we shouldn’t jettison a perfectly functional system, and I want to learn from what we’ve been doing, but at the same time it’s really bizarre to me that CVS should cause such a ruckus, because I don’t think it’s that different.

Then again, I don’t think that the leap from procedural to object oriented programming is a big deal. Seriously, I don’t understand all the fuss.

I can’t wait until we broach the topic of unit testing. Oy.

Regardless, I’m going to have to spend time thinking about how to smooth out the wrinkles in our new code management process. It will work, but it’s inelegant.

And of course, the real fun of the meeting was getting other work done at the same time, as I have a big project that just can’t wait for me to be on pause for several days. Thankfully, I’m surrounded by workaholics who think it perfectly natural to be typing away while everyone’s talking. :)

A few quick links of note:

• Eclipse 3.0 Milestone 8 has been released and has some very worthwhile improvements.
• EPIC, Perl plugins for Eclipse, was updated a few days ago.
• I’ve been thinking about ways to handle continuous integration, and a coworker points me to CruiseControl, Excellent. If I’d been paying more attention, I would have seen that.
• Compiling GD on Mac OS X. If you’ve ever tried to do this, you’ll know why I’m thrilled.
• Lawrence Lessig’s latest: Free Culture. Free Culture as PDF, as a very pleasant HTML version, and Free Culture as audio, recorded by a fast-acting band of volunteers.

Plone 2.0 has been released. Plone is a content management system built using Zope, an open source application server written in Python. It pulls together the Zope Content Management Framework with a number of other pieces to make a pleasant, standards-based, easy-to-use CMS. If I had to install a CMS at work right now, I’d choose Plone in a heartbeat.

• Plone and Zope are easy to use and administer. There is, I grant you, a learning curve to consider: Zope’s conceptual model is a bit … let’s say opaque. You kind of have to wait for a “Eureka!” moment when everything just clicks. Plone inherits some of that initial complexity but also does a good job of disguising the worst of it. As web-based CMS go, Plone has one of the most user-friendly interfaces around.
• It’s cross-platform (runs wherever Python does?). You can run it alongside your existing web server so need not abandon your existing infrastructure or face substantial retraining and retrofitting costs.
• Open standards. Out of the box, Plone generates valid and accessible XHTML and CSS. How many CMS do that? To me, this is essential not only for the usual reasons, but also because I’m thinking five years down the road when Plone might be replaced, and I want to stand a chance of being able to migrate the content without digging through all sorts of lousy, invalid markup. I suppose, come to think of it, that is one of the usual reasons.
• Note how I mentioned accessible? Of course, the valid XHTML & CSS help quite a bit, so if your design is done right, the only additional trouble you need take to improve accessibility is content manager training. I shouldn’t have to say this, but never trust a vendor when they tell you that their software is completely accessible, because it’s probably not true. I’ve had salespeople from certain large software companies tell me that their portal and CMS products meet all government accessibility standards, despite this claim being demonstrably false. From what I’ve seen of Plone, its accessibility claims are not a lie.
• Built-in workflow. This is a good example of Zope’s security model and object inheritance at work. User and group administration is built throughout and is easy to work with. Any object (a folder, a file, whatever) inherits its parent folder’s characteristics and permissions and can be overridden. Couldn’t be simpler. Rollback to an earlier version is a snap, too.
• Clean URL structure. Although sometimes I feel like I’m the only one who cares.
• Plone is open source and Python. As much as I love Python, I’m not just looking for an excuse to use the language (if anything, I should be pushing us to centralize on Java). Python is easy to learn and to ramp up to actual productivity to modify and extend Plone if we need to.

The big down side, of course, is that it doesn’t cost tens of thousands of dollars. Sorry about that.

This raises an advantage of open source that I don’t raise nearly enough: cheap prototyping. Three years ago, we had a chance to install a Zope-based or other open source CMS at work but did not. In retrospect, this was a huge mistake: the process for which we delayed implementation ended up causing complete inaction. We would have done well to set up a low-cost interim solution. Free & open source software offers this opportunity far more easily than high-buck commercial competitors.

Via Glenn Vanderburg, I see that Dave Hunt & Andy Thomas have just released Pragmatic Unit Testing in C# with NUnit, a companion to the wonderful Pragmatic Unit Testing in Java with JUnit. Huzzah! Apparently it’s more than just a rework of the JUnit book, too. If you’re interested in unit testing, either of these books is a good place to start.

Now I’m just waiting on their automation book.