Monday, February 26, 2007

Roll up the Rim

Do you know what this is:



That’s right, it’s a blank slate.

Roll up the Rim season is back! Which means it’s time for me to start keeping track of the coffees I drink, and the rims that are winners. Will I do as well as last year? Or will I get hardly any winners, like usual? Will I end up with a new Toyota hybrid?

Only time will tell…

Thursday, February 22, 2007

Articles

Some random links I found, this morning.

And that’s all, for now. You can go back to whatever you were do— no, wait, one more:There. Now I’m done. You can go back to whatever you were doing.

Blogs

I have a morning routine, when I come into work:

  1. I log onto my email, and take care of anything important
  2. I log onto my personal email web client, and take care of any spam that’s built up in the last day
  3. I look for any news that looks interesting, on my homepage
  4. I fire up Firefox, and see if anything interesting has been posted on any of the blogs that I follow
Unfortunately, I realized yesterday that I’m not interested in most of the blogs I follow, anymore—I just read them out of habit. So I cleaned out my Live Bookmarks, and I now have a lot less to read every morning.

Oh, sure, I’ll miss them, for a while. But soon I’ll have a whole new set of boring blogs that I’m reading, that I’ll have to eventually clean out, so I’m not expecting to gain too much free time, by this.

Tuesday, February 20, 2007

Tired, and maybe sick

It’s been a rough couple of days. A deployment Saturday night—which really means Sunday morning—which wasn’t as smooth as usual. Then a couple of hours of sleep, followed by church. Followed by a call on my cell phone, that there were production issues, and could I please join the bridge? Followed by an hour or two of listening to people troubleshoot a problem that was over my head.

Followed by possibly the best night of sleep I’ve had in years.

Followed by more troubleshooting the problem that’s over my head, but this time, with an active role in the process. Security is really not my forté. I bet I sounded like an ignorant fool the whole time.

Followed by a day of bureaucratic nonsense.

Followed by an entirely normal night of sleep.

Followed by this blog post.

Oh, and as the title implies, I may be coming down with a cold.

P.S. I haven’t been able to post anything to the serna Bible Blog, and, if this keeps up, may not get to for a while more.

Friday, February 16, 2007

Blogging with Eclipse

I have mentioned—probably ad nauseum—that I haven’t yet settled on a good HTML editor for Ubuntu/Linux. I’ve now begun work on writing a plugin for Eclipse, for blog editing. I even found some tools from Google, that will let me post to my Blogger account(s) automatically, by code. I’m using Java, of course, so I downloaded a handy-dandy JAR file from Google, that simplifies the whole thing. In fact, submitting a post—once you have all of the text for it, of course—is just 9 lines of code.

If all goes according to plan, I’ll be creating the following for Eclipse:

  • An HTML editor—based on existing HTML editors, I’m not writing anything from scratch—with edit and preview views
  • A plugin for working with quotation marks, similar to what I did for HTML-Kit
  • A generic plugin architecture, so that others can add their own blog-specific plugins
  • Preferences, where you can set up Eclipse with all of the blogs you post to, and HTML templates for those blogs.
  • The ability to automatically submit, with the click of a button. This would include things like:
    • Fixing up quotes, using the smart quotes plugin
    • Fixing up any newline issues, and—if necessary—removing <BR> tags
I’m fairly excited about this. But there’s a bit of a learning curve, in writing an Eclipse plugin, so it probably won’t be ready any time soon. (You can actually generate an Eclipse plugin with a few clicks of the mouse, and get it to generate a lot of the functionality for you; but then, when the skeleton code is there, I need to figure out how to sub-class an HTML Editor class, etc.)

Tuesday, February 13, 2007

Why Service Oriented Architecture Won’t Work in the Corporate Environment

Warning: Geek post.

First off, please note that I purposely chose a contentious title for this post. (I was tempted to call this SOA Considered Harmful but figured that most people probably wouldn’t get the joke. Especially since I don’t consider SOA harmful; I just don’t think it will fly. But I’m getting ahead of myself…)

To begin with, from Wikipedia, a definition of SOA:

Service-oriented architecture (SOA) describes a software architecture that defines the use of loosely coupled software services to support the requirements of business processes and software users. Resources on a network in an SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation.

A service-oriented architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including REST, RPC, DCOM, CORBA or Web Services. SOA can be implemented using one of these protocols and, for example, might use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.

SOA can also be regarded as a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services. These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service. SOA-based systems can therefore be independent of development technologies and platforms (such as Java, .NET etc). Services written in C# running on .Net platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application. Applications running on either platform can also consume services running on the other as Web services, which facilitates reuse.

SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not specify or provide a methodology or framework for documenting capabilities or services.

High-level languages such as BPEL and specifications such as WS-CDL and WS-Coordination extend the service concept by providing a method of defining and supporting orchestration of fine grained services into more coarse-grained business services, which in turn can be incorporated into workflows and business processes implemented in composite applications or portals.

Now, as stated, I’m very much in favour of SOA. I think it’s the Right Thing; ever since I started seeing people talk about it, it clicked with me. (As mentioned quite a while ago, I even took a course on it, which is rare for me, because I never go on training.) An organization that can create this type of software architecture will be much more agile, and able to quickly meet business needs, than an organization that doesn’t.

But let’s face reality here: In order for an organization to implement Service-Oriented Architecture, it needs to be supported organization-wide. That means both bottom-up and top-down support. (And middle-out support, for that matter—there are a lot of middle-management bean counters out there.) The developers who are building software need to support it, of course, and start thinking in terms of “services” instead of just “applications”. But the people at the top, who control the dollars, also need to support it. And this is where it all falls apart.

Organizations simply don’t work this way. When an organization is beginning a new software project, it’s treated as just that: a project. The person running the project is given a specific task or set of tasks to perform—“create a new billing system” or “modify the call centre portal to support new ‘daylight savings time’ issues” or that type of thing—and given a budget to do it. The person running the project is going to be measured on how well the project meets the stated goals, and whether or not the project goes over or under budget.

Suppose you’re a Project Manager (PM), and you’re tasked with building a new web-based portal for the organization’s call centre. You’re given a specific budget, and a set of requirements that the system has to meet; it must be able to display customer profile information, perform billing transactions, etc. In fact, there will probably be a lot of requirements, for such a system, which will be ranked: Some requirements are “mandatory”, some are “optional”, depending on time/budget, and some are “nice-to-haves”. Because the new application will be for the call centre, the money is coming from the call centre’s budget.

When the PM goes to build this application, if s/he is familiar with SOA concepts, it will become evident that it would make a lot of sense to build a service, for retrieving customer profile data, so that it could be used by other applications in the organization, not just the one in question. Similarly, it would probably make sense to build services for performing billing transactions. But that would cost more; the services would have to be made more generic, to meet the needs of the application being built, but also to try and meet the needs of any future applications, which might want to use them. (e.g. the service which returns customer profile data would probably have to be built to return any and all available data for a customer, regardless of whether the original application needs it.) Which means that, instead, the PM could simply build something to be used only by the application in question, and use the extra money to implement extra features in the application, for the call centre client. Why build services for performing billing transactions—which may or may not ever get used by other applications—when the money could instead be used to implement some of the “optional” requirements for the application?

As far as the project’s budget is concerned, ignoring SOA, and implementing extra features, would mean that the project would meet, and possibly exceed, the client’s expectations. But the next time an application is built that needs to retrieve a customer’s profile, the PM for that project will now need to re-build the functionality; the organization as a whole is spending money twice, that it could have spent once, but there was no incentive whatsoever for the first PM to spend the extra money, since it would have harmed the original project.

As you read this, please don’t misconstrue what I’m saying as “blaming” the original PM, for being selfish. S/He is trying to make the project as successful as possible, and this is the only way PMs are typically gauged. If the original project had been built such that the customer profile retrieval was built in a service-oriented manner, it would save the organization money, overall, but it would make the project less successful. My inner geek would rejoice, but the PM would not be rewarded—quite the opposite! There would probably even be blame laid, for wasting the project’s money on what is, strictly speaking, an IT-related problem, not a problem that had anything to do with the project.

The best way, the only way, for organizations to overcome this problem is to do away with the project-oriented way of creating budgets, and allocating money. I’ve seen a lot of organizations talking about wanting their people to think as if they’re part of the larger organization, instead of just a member of a particular project or projects, but the reality is that they can’t, because they are forced to charge all time against projects. Time and time again, I’ve been on projects where we lent developers to other projects, to help them achieve some goals, but it always came back to bite us, because the developers needed to charge their time somewhere; if the other project didn’t budget for the extra people, then they couldn’t charge there, but if they charged to my project, then they were eating up my project’s budget.

But if there was only one budget, one big “budget for all IT-related activities”, that people could charge their time to, it would be much easier to do the Right Thing. The bean-counters would all develop ulcers, because they wouldn’t be able to track where their money was going the way they can now, but overall, my hypothesis is that the organization would get much better value for its money.

I think we all realize that the “one budget” solution is not going to happen. Organizations feel that they need to track their money as minutely as possible, to enable more detailed reporting, and track inefficiencies. But many of the people who advocate for SOA talk as if the “one budget” way of doing things is the the way things work. Any person I’ve seen talking about SOA talks about the need for organization-wide buy-in—especially the top-down type of buy-in—which is correct, but to make the leap from “buy-in” to “merged budgets” is simply too large of a leap to make. You may be able to convince the upper-management types that they need to support SOA, but you won’t be able to convince them to change the way they budget.

Instead, any organizations that are serious about SOA are putting together piecemeal solutions. They still allocate funds for projects, which have specific, project-related goals, but they also earmark some money for SOA-related initiatives. For example, they may dedicate money for SOA-related infrastructure, like a registry and maybe an Enterprise Service Bus (ESB), and maybe some hardware where the services can be housed, and centrally supported. Or maybe the organization might have some type of SOA “SWAT Team”, for implementing services; e.g. if the project realizes that it will need a “customer lookup” service, they might farm that work out to the SOA SWAT Team. (Of course, this would tie the project’s timelines to the timelines of the SWAT Team; if they’re not able to deliver, the project fails.)

These ideas are steps in the right direction, but they don’t solve the core problem: Any given project is still only funded for work related to that specific project. Any work on top of the project work would need to be justified, and funded, and, as things stand today, that’s not likely to happen. Even if money weren’t a concern, time still would be; you don’t want developers wasting time on the SOA-related development, when they could be building features instead.

I guess, fundamentally, the problem is that Service-Oriented Architectures benefit an organization, at the high level, but do not normally benefit projects, at the low level. If I build this functionality as a service, with the extra complexity that entails, it may benefit another project, down the road, but it’ll cost me more, and, therefore, cost my project more.

Oh, but I know what you’re probably thinking: “Sure, serna, it doesn’t benefit the initial project, but doesn’t it benefit future projects? Suppose you want to build a customer-facing application, where customers can do self-service over the web; wouldn’t it be quicker to develop, because you could re-use the customer profile and billing services?” In theory, yes; it would take less development time to get the next application up and running, and reusing the existing services. But there are two problems that still need to be surmounted:
  1. Support: If you’re going to reuse the original services, it means that there will be an extra load on those services. The hardware, network, and other resources would need to be able to support the additional requests. Exactly what SOA is supposed to be about, right? Except that, as things stand now, the people supporting the original project would see this as a risk to the application they’re supporting, not a benefit to the organization. What if the new application puts so much load on the system that it takes down the original application? (If an organization has invested in core service-related infrastructure—and if the services in question are housed there—then this shouldn’t be an issue.)
  2. Changes: What if the original services almost, but don’t quite, meet the needs of the new application? An extra parameter needs to be added somewhere, or an extra piece of data needs to be returned? They would need to be modified in such a way that the new application could use them, but the old application would not be broken.

    The original application may or may not still be actively developed; either way, there will be problems:
    • If the original application is no longer actively developed, it would be difficult to properly regression test it, once changes are made to the services. Most people would probably give up, and simply create a new version of the services—perhaps even using good ol’ copy ’n paste, to create an entire new version of the code base. The old service would be left as-is, so as not to break the existing application.
    • If the original application is still being actively developed, then changes to the services would need to be worked into its roadmap. The new project would also have to fund the changes. This brings us into all of the problems discussed above, about project benefits vs. organization benefits.
So, all of this being said, do I support SOA in concept? I sure do. As I said, developing applications in this manner, especially in large organizations, is the Right Thing. If all of the issues I’ve raised in this post were removed, developing services, instead of monolithic applications, would make future development much quicker, as services started to get reused. If technologies like BPEL were used, for implementing business logic in coarse-grained services, it would even make the business more agile, because they could change business processes much more easily.

The problem is not with SOA, it’s with the SOA advocates who don’t take the full picture of how an organization works into account, when espousing SOA’s potential benefits. (People do often mention “politics”, but this goes deeper than politics. This is about how organizations fund projects, and allocate work to developers.) We need to stop having a Star Trek mentality, when it comes to discussions about SOA, and start taking into account reality.

I’m sure there are solutions to the problems I’m raising. I haven’t mentioned any, because that will have to be an exercise for readers who are smarter than I am. But we need to solve these problems, so that SOA will become viable.

Monday, February 12, 2007

Marshmallow

Wikked Lil' Grrrl says:
>>

Is that not the sexiest shoe you've ever seen???


sernaferna says:
Meh. It's not really a style that I like.

Wikked Lil' Grrrl says:
*blink* How... how are we friends, serna? It's like I don't even know you.

sernaferna says:
Yeah, I'm an enigma wrapped in a riddle wrapped in fat.

Wikked Lil' Grrrl says:
in fat? you're not fat.

sernaferna says:
Only around the belly.

sernaferna says:
And the sides.

Wikked Lil' Grrrl says:
Like a mini marshmallow in the middle of a toothpick?

sernaferna says:
There was some on my back, but I think that's gone. Healthy eating is working...

sernaferna says:
Well... if the toothpick isn't right in the centre of the marshmallow. If you stick it in closer to the edge, so that most of the marshmallow is on one side of the toothpick...

Wikked Lil' Grrrl says:

Well, just as long as you stay in the mini marshmallow range, and don't balloon into a Jumbo Mallow. Or an entire tub of Fluffernutter.


sernaferna says:
lol

sernaferna says:
Unfortunately, I have no clever response to that, before I blog this.

Wikked Lil' Grrrl says:
Awww You'll just have to leave a "to be continued..." disclaimer on the blog.

Wednesday, February 07, 2007

The Weekend

I haven’t blogged in a while, have I? Oh well. What can I say, I’ve been busy. So let’s make up for it with a long-ish post.

A friend of ours moved on the weekend. (Actually, she moved again; she first moved out of her old place, and into a temporary place, a couple of weeks ago, and then was moving into her new place this weekend.) She moved into a really nice place, downtown. So, as usual, when we where there I was missing living downtown. Happens every time.

Afterword, when we were sitting around and basking in the beauty of her new living room, the conversation somehow got around to cooking, and I mentioned that Andrea and I hadn’t bought take-out, nor cooked any frozen pizzas, since the year began. Just like I wrote in a previous blog entry. And then, just as I’d been anticipating the response would be, someone came back with “But it’s only been a month!” I’m practically clairvoyant!

Speaking of cooking, last week we tried our most ambitious recipe to date: Sole Florentine. Most of our recipes have been along the lines of “take all of the ingredients, mix them together in a pot, bring it to a boil, and then simmer for a while”. Some are slightly more complex, and require us to put in some of the ingredients, bring to a boil, and then add the rest of the ingredients. The most complex would require us to sauté some onions, before adding them to the mix. But Sole Florentine was a big process; “cook this, then cook that separately, then cook the other, then mix numbers one and two, then throw it in the oven for a while”. If we keep this up, our cooking skills will soar!

(We also made Cajun Chicken this week, with a fancy turnip side-dish. It was great; if I ever do start my recipe blog, I’ll be posting both recipes there.)

On an unrelated note, the Youth Group went to mini-golf on Friday. I was driving my pastor’s van, with a group of kids, and the one thing that I always fear might happen actually happened: we got into an accident. Any time I go out with the kids, I’m always worried that we might get in an accident. Luckily, it was very minor; we were stopped at a red light, and the guy behind us accidentally let his foot slip off the break at the wrong moment, and he nudged into us. It was extremely minor, with no injuries, and no damage to either vehicle. (Not even a scratch, from what I could see.) The strange thing is that I found out on Monday that another colleague also got rear-ended on Friday!

And, even less related than that, my Bible blog is right in the middle of the book of Leviticus right now, and I’d been thinking that, to get a clear picture of God, you really need to read the books of Leviticus and Hebrews back to back; Leviticus to get a picture of how Holy God really is, and then Hebrews to get the Old Testament laws put into a New Testament context. And, in fact, I did read the book of Hebrews on Saturday night. And then, in a weird coincidence, I was leading the service on Sunday morning, and the scripture reading was from Hebrews.

Lily Allen: Smile

Since I was just posting about Saturday Night Live, it reminded me that Lily Allen was on, as the musical guest. (I was going to link to Lily’s official website, but it’s pretty awful—lots of different pieces of music playing at once, and pop-ups, and colours…) She performed her song Smile, and I’m not quite sure if I like it or not—but I’m pretty sure I do.

Here’s the video, in case you want to see it for yourself:

Saturday Night Live

I know it’s a perennial favourite to talk about how crappy Saturday Night Live is getting “lately”—where “lately” can mean anything from the last year to the last ten years to the last twenty years, depending on the age of the person speaking—but this year it’s gotten really bad, again. Ever since Tina Fey left, the writing has gotten terrible. (Which is not surprising, since she was the head writer on the show.) It’s getting to the point where I don’t know if I’m going to bother taping it every week.

Take last Saturday’s show, for instance. They had a great “Digital Short”, Body Fusion, but then again, Digital Shorts are usually pretty good. (I think Andy Samberg is one of the few saving graces for the show, these days.) But most of the show was pretty bad; sketches that went on way longer than they had to, and other sketches that were, oddly enough, too short.

It just goes to show how much work the head writer on SNL really does. I’m sure that, when Tina Fey was there, she was doing a lot of work, behind the scenes, to rewrite the sketches until they were nice and tight. Until a new head writer of her calibre can be found—or until the current head writer catches his/her stride—I don’t foresee a lot of great shows in SNL’s future.

It’s too bad, because a show of SNL’s format has a lot of potential to be great. They just don’t always attain that greatness. Some time around high school, or maybe a bit after, I stopped watching, because it had gotten so crappy, and then started watching again a few years ago. I might end up stopping, again, if it keeps being this bad.

Note: I’ve just realized that this post was written pretty badly. (I was doing multiple things at once, as usual.) It’s somewhat ironic that I would write a post about how bad SNL’s writing has gotten, lately, and use bad writing to do so…

Monday, February 05, 2007

Book Review: It’s Not Easy Bein’ Me

Author: Rodney Dangerfield

For some reason, I decided to read Rodney Dangerfield’s autobiography. It was actually quite a fascinating read; I don’t know what I was expecting, but I wouldn’t have been overly surprised if it had been bad.

Overall, the book made me pretty sad. At the beginning, it made me sad because he was writing about his terrible, horrible childhood. No love from his parents, sexual abuse from a stranger; it was an awful way to have to grow up. The whole time, he’s writing it in a light-hearted manner—it’s like I could hear Rodney in my mind, dictating it to me in his voice—but for the beginning, you could tell that it hurt him to go back and relive some of that stuff. The jokes sounded forced.

But then he switches gears, and starts talking about when he got into show business—in the 40s, believe it or not—and starts going on about all of the women he slept with, and all of the drugs he took. And for the rest of the book, he really is light-hearted, and it made me sad for a different reason. I’ve always liked Dangerfield’s humour, and he always seemed very likable, but the book made it more personal. I really cared for the guy. And so that made me sad, because now he’s dead, and he’s… well, let’s just say that he’s not in heaven. And it feels like such a waste.

After reading the book, I feel the same way about Rodney Dangerfield as I do about any of my other non-Christian friends/family members/coworkers/etc.

Anyway, I called this a “book review”, and my review of the book is this: I loved it. If you were a big fan of Rodney Dangerfield, the book is a must-read; if you were only sort of a fan, then the book will make you a big fan.

Friday, February 02, 2007

Recipes

This whole year Andrea and I have been cooking properly; making food, instead of just taking a box out of the freezer and throwing it in the microwave. (Or, in the case of a pizza, throwing it in the oven.)

Oh, I know what you’re thinking. “This whole year?!? serna, it’s only February! It’s not quite time to start celebrating yet…” Which is true. It’s not exactly record-breaking material. However, we’re not in the habit of cooking; since we’ve been married, we have a small set of standard meals that we prepare:

  • take-out (of course)
  • perogies
  • roast chicken
  • roast beef
  • frozen pizza
  • curry chicken (Andrea’s aunts taught me to make this, but I still haven’t quite mastered it)
  • beef stew (from a recipe my parents gave me)
There are probably some others, too, but they’re not springing to mind. And I probably shouldn’t say “we” either—since I’m the one who’s been doing all of the cooking, it’s my fault that my repertoire is so small.

But this year, mostly at Andrea’s prompting, we’ve been doing actual cooking. (Well, yes, some of the dishes above are “real cooking” too, but we didn’t make them that often.) Since the year began, we haven’t ordered take-out for dinner at all, nor heated up any frozen pizzas. And in that time we’ve found some really great recipes. For example, Andrea found a great recipe for Moroccan Bean and Potato Soup, and last night we made a really great Tex-Mex Chili. We also made an Avocado Soup which Andrea likes a lot more than I do, and Andrea found a great recipe for Apple and Date Bran Muffins. (And, not only are we cooking better, but Andrea’s getting involved, too.)

So I’ve been tempted to start a new blog, where I simply put up the good recipes we come across. The best part about it would be that we’re still not great cooks, so any of the recipes we put up would be, by definition, easy to make.

However, I haven’t started creating it yet, because it’s still a bit early to know if we’ll stick with our little cooking spree.

Thursday, February 01, 2007

New CD

A while ago—over a year—there was a song that was playing on the radio, that I liked. A friend came across a free copy of the artist’s CD, and promised to give it to me. A year later, they finally remembered, and I got the CD.

I was immediately thrown off, when I saw the cover; it’s a female artist, and it’s really creepy how she tried to make herself look like a little girl in all of the pictures. (According to her Wikipedia article, and some simple math, she was 25 at the time she made the album.) I’m not talking about sexy; I’m talking about a grown woman going for a pre-teen look. That’s bad enough, but it gets even worse when you couple her photos with the lyrics to some of the songs; when you have a cover photo in which the artist tries to look like a little girl, and then listen to a whole album in which she sings about how much she wants to have sex, it’s a little… unnerving.

But I went ahead and popped it into my laptop’s CD-ROM drive, only to find that the CD was copyright protected. It wouldn’t play on my computer unless I installed the software it came with—Windows Media Player didn’t even recognize it as a music CD. I wouldn’t have thought that that would be legal in Canada—our copyright laws are different than America’s—but oh well, what do I know? I went ahead, and let it install the software.

At the bottom of the window, it had a little newsticker; “click here to visit BMG’s website”, that kind of thing. But after a couple of minutes, I noticed these messages:




(It’s the same content in both pictures, but a different title.)

At first glance, I just saw the phrase “Class Action Settlement” and thought the record company had been sued because of the copyright protection. “Good!” I thought. “I’m glad the record company wasn’t allowed to get away with it.”

But then I looked a little closer. If you read those messages (if they were even readable, in the images), you’ll have noticed that they had nothing to do with copyright protection; the software they installed was spyware! So they got sued, in a class action lawsuit.

I’m not lawyer, so I don’t have any expertise, but let me quote some parts of the “Statement of Claim”, which they had on their website, with some pop-ups of the definitions, that came earlier in the document:

This action claims damages for the torts of conspiracy to injure and trespass. the Class has suffered damage, but asserts the right to waive the tort and claim damages measured by the defendants’ enrichment. The action arises fro the defendants’ fraudulent conduct and is not a defective product claim.

Since 2003, the defendants have knowingly included flawed and overreaching computer software programs on hundreds of thousands of CDs sold in Canada. These software programs, referred to as ‘MediaMax’ and ‘XCP’ were designed by Sunn and First, with the collaboration of the defendants and at their request. The defendants knew that the XCP and MediaMax software programs contained features which damaged the operational systems of the Class Members’ computers, occupied memory and bandwidth, and compromised the security and privacy of the information on the computers.

In addition to the stated purpose of copyright protection, the software was intentionally and knowingly designed to install and hide files on the computer’s hard drive. When installed, these files could ‘phone home’ to Sony BMG and report what CD the computer was playing. The software, in an aspect which was neither described nor disclosed to Class Members remained hidden on the user’s computer and made the operating system vulnerable to worms viruses, malware, spyware and to system failure. The software did not contain an ‘uninstall’ command.

According to the website that the newsticker pointed me to, I might be eligible to make a claim:
What you get: you may receive a replacement CD, a free download of the music on the CD, and software fixes for known security vulnerabilities. In addition, you may choose to receive either
(i) a cash payment of $8.40 and one (1) free album download, or
(ii) three (3) free album downloads.
If I’m reading the settlement properly—which I may not be—I might be entitled even though I didn’t buy the CD; the damages are for harm to my computer, for installing the software, not for money I spent on the album.

However, I’m not going to bother.