GoodRelations Ontology Meetup

The Chicago Semantic Web Meetup will be meeting on Dec 7th. The topic will be the GoodRelations Ontology, which is the second most used ontology next to FOAF. We will be lucky enough to have the ontologys author speak to us.

Here’s the description:

In less than a year since its official release, the GoodRelations vocabulary for e-commerce has received huge interest from practitioners and researchers alike. GoodRelations has already been adopted by Yahoo, BestBuy, OpenLink Software, and may other major players, and it is supported by popular Web shop applications like osCommerce and the Joomla/Virtuemart combo. For the first time in history, we can expect a massive amount of real-world data expressed using a rich vocabulary compliant with the state-of-the art in W3C Semantic Web technology.

In this talk, I will explain the technological foundations and the business implications of GoodRelations for e-business experts, CTOs and CIOs, Web developers, and basically anybody who want to be found on the Web. I will also show details on the massive growth of real-world data, sketch business models for affiliate marketing, and give an overview of available on-line resources and tools for adding GoodRelations support to your business model.

If you’re interested in coming, please RSVP by the 6th. I’ll need to send a list of names to security.

Mac Performance Addicts

Wow, I just came across this site. It’s an extremely exhaustive encyclopedia of all things performance related for Macs. Also, though it’s geared towards Macs, a lot of the details are hardware related and might be useful to non-Mac machines out there too.

Lean, Waste and Bug Trackers

A few years ago I was working at a company that was using Bugzilla for bug tracking. When we moved over to Subversion for source control, we decided to move over to Trac for our issue tracking / wiki needs. As we were preparing for the move, one of the team members spent some time investigating the migration of our data from Bugzilla to Trac. Various issues like field mapping, data scrubbing, etc… made us weary of the switch. It may seem like a strange question, but I had a hunch, so I offered up a simple question:

“Guys, do we even need to migrate this stuff?”

I was meet with scoffs of “Of course!”, but most of the justification was based on the simple fact that we had been tracking these things, so they HAD to be valuable, right? By throwing them away, we were wasting the effort it took to track them.

However, once we started to look back at the past 6-12 releases, we noticed that the features / bugs included in each release tended to be things that have recently popped up. Rarely, if ever, did we go back over a legacy bug and include it in a release. Instead, everything we were doing was either a recent customer requests or a new bug that we just discovered. It seemed as though everything that we weren’t hearing about really didn’t matter.

So what’s this got to do with Lean? Well, I quickly started to realize that bug trackers usually represent a repository for waste. We usually toss anything and everything into them. We do this with the idea that we’ll go back and do something with them at a later date, but that’s never the case. Later Never Comes. In reality, these issues / tickets / bugs just gather dust. They create a big lump of data that we need to wade through every time we interact with the tracking system. They become waste. But why is this the case? Don’t these items represent features that need to be added, bugs that need to be fixed or technologies to be investigated? Aren’t those things valuable?

Not necessarily. Once your software is released and customers are using it, you’ll find yourself inundated with feature requests & bugs from your actual customers. If you listen to your customers, they’ll tell you what’s important and what needs fixing. If they’re not asking for a particular feature, chances are it’s not really important. That kind of direction and feedback is a lot more valuable than some feature you added to your tracker 6 months ago.

Besides, even if you wanted to go back and tackle them, you face several roadblocks. For example, the issue my be incomplete or ambiguous or the original reporter could be gone. It could take you time just to figure out what the bug meant. In that case, you can find yourself chasing something that might not even be useful to anyone. It could have been addressed already without anyone knowing it. It could also have been for an older direction of the product that’s not being pursued anymore.

In my experience, things that are created with the sole intention of circling back and revisiting something are the worst kind of waste a system can product. Not only are you leaving something potentially broken / incomplete, but you now have this millstone that you need to carry with you wherever you go, limiting your agility. Don’t fall into the trap. Later Never Comes!

Removing Google Ads

Updated: Finally removed the last of them.

For the second time in almost 3 years, I’ve decided to remove the Google Ads from 1530 properties. This time, it’s the RSS feeds that serve up this blogs content. I just wasn’t feeling them. Not sure if I’ll ever activate them again.

P.S. It might take a little while to roll out to my feeds.