Navigate

Tuesday, July 24, 2007

Flexible Pipes

Cole Camplese's blog post ‘As a Public Service, Let Me Repeat that RSS Rocks’ has me thinking about Yahoo Pipes again. Cole's experiment is a nice, simple, clean demo of feed aggregation using Google Reader (a great probuct, BTW) that is just the thing for sites with a very sharp focus on specific topics. Especially easy and intuitive is the ability to aggregate feeds using tags to simulate a file system organization. The problem I ran into with Google Reader is too little control of sorting and filtering content, with too much unrelated content.

That led me to think about pipes. Here's the use case: I want to aggregate feeds about Python, Zope, Plone and the WebLion project. Since Pythonistas are somewhat passionate about the elegance of their language, they can get a bit wordy and wide-ranging and off my chosen topics. So, for our readers benefit I wanted to limit posts about Python to subjects related to Zope and Plone. Pipes has the filtering operators I need, and can be combined in very precise ways. The result is the PythonZopePlonePipe. Clone it, mash it, put it in a pipe and smoke it.

Blogged with Flock

Wednesday, July 04, 2007

Building a Testing Culture

When you think about it, there's really not much difference between our university's collective group of IT staff - the set of technology people from academic, business and administrative units, and ITS - compared with, let's say, Google. Sure, everyone talks about how smart they are, but so are we. Yes, they do have THAT DATABASE, but soon we'll be as tightly integrated in our divers operations. OK, so as of July 4, 2007, they have a market cap of 166.47 Billion U.S. dollars, but that's not a fair comparison since our university is a non-profit institution. So what's the big difference that really distinguishes us from a company like Google?


I propose that the big difference, and their real advantage, is their hive mind. Not quite like Borg, mind you. But they walk around with a culture in their head, and they are like-minded in this regard: they talk data. They gather it (with a vengeance), render it, analyze it, hypothesize it, and they talk about it. I know this because I read things that assert this with frightening uniformity, and I have a couple of contacts that have admitted as much. I have also noticed that many IT folks at our university don't have the same obsession for data. I'm starting to think that's a regrettable thing.


Take for example the group I know best and identify with most - our Web development community. Smart people doing lots of very cool stuff. Lots of them are database and scripting wonks, JavaScript and UI geniuses, gadget freaks (raise your hand if you were in line for iPhone D-Day), as well as chefs of tasty mash-ups. But how many of us test our work, gather data, and tweak our user interface based on that data? Hands up, please.


My hand isn't raised, either, mind you. Despite years of reading about best practices, I don't write and distribute code with unit tests; I don't even run the unit tests handed to me in open source code. (Now I'm off to execute runalltests.py - I'm thrilled!). I rarely run usability tests on application interfaces, so when I do it it's a big deal to design the test, find victims, find a quiet place, summarize data and make adjustments and test again... Why, because it's not routine. (I well remember testing an eCommerce application for an annual fund raiser, and it was crucial that I did so; and it's still running without major changes.) Ditto testing that doesn't require much work - standards and Section 508 compliance. And, interestingly, it's rare when I'm asked for results of tests. I say it's not routine and therefor more difficult than need be, but what I'm really saying is that it's not part of the culture we work in.


And if we don't test, or analyze our logs, how can we be sure that we're giving our stakeholders a good experience? I know I sometimes have a hard time finding information in our Web cloud. Developers are too close to their work to be good judges of quality and usability. But we're in a good place to be testers.