Here is a 4 minute non technical film explaining software patents.

Via the EFFector mail list.

One of the hardest decisions every developer faces is build vs buy. In general, build takes more money and time, but can deliver a program closer to the users’ needs with greater flexibility. Buy, on the other hand, limits extension of the software–only in ways that the creators have intended can you typically extend bought software–but delivers it quickly and for a known cost (unless you’re buying Oracle in which case, I hear, the price is negotiable :).

One of the harder components of deciding to buy is comparing features. This usually involves rummaging around websites, downloading evaluation copies and installing them. I’ve done a few of these (for open source portals, open source CMSes and bug tracking tools) and it’s interesting as well as daunting. There’s just a lot out there, and with limited time, I end up making decisions based on less than full fledged implementation. You can’t afford to entirely implement the solution using the proposed software, and every solution will cause you pain (including, for that matter, custom built solutions).

Regardless, a friend sent me a website that takes some of the tediousness out of evaluating CMSes. Sure, it’s not a replacement for downloading the software and trying it out, but it does give you a central starting point and makes it easier to quickly rule out possible solutions. I was also impressed by their inclusion of blogging tools and ease of use as well as the breadth of features compared.

So, as I’ve mentioned before, RSS can help you find a job. However, many jobs in my area are posted to a yahoo group (rmiug-jobs). I’m usually interested in seeing new contracts, even if it’s just to see how the market is doing. However, subscribing to this email list presents you with four choices:

1. Have your inbox flooded with job postings, most of which don’t apply to you. The benefit of this method is that when you do see one that applies, you can respond. Every single response I’ve received off of this list was in reply to a mail I sent minutes after seeing the job post; I’m guessing that almost 8000 members means that any job posters are flooded with resumes.

2. Create a filter so that all the mail messages (or even the ones with interesting subject lines) are pushed to one folder in your email client. This means that your inbox isn’t flooded, but that you have to read that folder regularly. I didn’t do that often enough to be worthwhile. In fact, as the messages piled up in that folder, I felt less and less able to read it. In addition, you may have issues if your filtering rules are complex (I want A and B but not C), though not if you use procmail.

3. Get the daily digest and miss out on timely job postings. I did this for a few months and found that I almost never read the large digest. I just felt guilty at the bandwidth wastage.

4. Use the search functionality to periodically check for postings of relevance to you. This helps with research, but doesn’t deal with the time issue. And, you have to remember to check periodically.

However, now there’s a fifth solution. Yahoo provides an RSS feed for that group. (Not all groups seem to have rss provided for them, and I couldn’t figure out how to turn it on for a group that I moderate.)

With the magic of XSLT, I was able to write a stylesheet which only grabs entries with interesting keywords in the title, thus avoiding the flooding problem. RSS is not real time, but it’s can be close (as close as I want/am allowed to poll the feed). Additionally, I’m a lot more likely to scan it than I would any of the email solutions.

Here’s the relevant XSLT:

<xsl:template match="item">
        <xsl:variable name="item_link" select="link"/>
        <xsl:variable name="item_desc" select="description"/>
        <xsl:variable name="item_title" select="title"/>
        <xsl:variable name="uc_item_title" select="translate($item_title,'boulderjava','BOULDERJAVA')"/>
        <xsl:choose>
           <xsl:when test="contains($uc_item_title, 'JAVA')">
              <li><a href="{$item_link}" title="{$item_desc}"><xsl:value-of select="title"/></a></li>
           </xsl:when>
           <xsl:when test="contains($uc_item_title, 'BOULDER')">
              <li><a href="{$item_link}" title="{$item_desc}"><xsl:value-of select="title"/></a></li>
           </xsl:when>
           <xsl:otherwise>
           </xsl:otherwise>
        </xsl:choose>

</xsl:template>

The reason for the translate cheesiness is that the version of the perl RSS module I’m using does not support the upper-case function (here’s a useful list of XSLT functions).