Skip to content

Dropping the .com from package names

Dion wonders whether you need fully qualified package names on your java packages. For instance, is code that I write with this package declaration: package; that much better than package;?

Given that there are no other mooreds MLDs (from a search at network solutions): is available. is available. is available. is available. is available. is available. is available. is available. is available. is available. is available. is available. is available. is unavailable.

I think the answer is that it doesn’t matter very much right now. And the chances of it mattering in the future are slim. I’d have to write some code with the same classname as another ‘mooreds’ packager, and want to import that code. Improbable, but possible. And if this situation arose, I’d have to rename my class, use a different package name (after all, packages don’t have to be meaningful) or use a different class.

What are the benefits of leaving off the com. declaration? Well, it saves everyone who wants to use it four characters of typing per import (those who don’t use auto importers). Four characters!

So, it’s safe to say that package; and package; probably won’t hurt anything, but given the cost benefit analysis, I can’t see why anyone wouldn’t use the full package declaration: package; .

Now, if someone is using a domain they don’t own, well, that’s just braindead. 15$ and a credit card will get you a domain name. If you can’t afford that, then choose a TLD of your own creation; package; won’t collide with anyone who is following the spec, and has an even smaller chance of colliding with someone who isn’t than just dropping the TLD.

In a different vein, I used to give an unusual name for restaurant waitlists, but oftne when they called out ‘Archibald’ I wasn’t attuned to it like I was to ‘Dan’ and more often than not, I missed my seating. Similarly, if you use a domain that someone else owns as your package name, well, you’re looking for trouble that you don’t really need to. I mean, really, isn’t software hard enough?

Installing eRoom 7 on Windows XP Pro

This is a quick doc explaining how to install eRoom 7 on Windows XP Professional. It assumes that Windows XP Pro is installed, and you have the eRoom 7 setup program downloaded. This is based on the events of last week, but I believe I remembered everything.

1. Install IIS.

2. Make sure the install account has the ‘Act As Part Of The Operating System’ privilege. Do this by opening up your control panel (changing to the classic view if need be), double clicking Adminstrative Tools, then Local Security Policy, then expanding the Local Policies node, then clicking the User Rights Assignment node. Double click on ‘Act as part of the operating system’ (it’s the 2nd entry on my list) and add the user that will be installing eRoom.

3. Restart.

4. Run the eRoom setup program. At the end, you’ll get this message:

Exception number 0x80040707
Description: Dll function call crashed ISRT._DoSprintf

5. Re-register all your eRoom dlls by opening up a cmd window, cding to C:\Program Files\eRoom\eRoom Server\ and running

regsvr32.exe [dllname]

for each dll in that directory.

6. Run the eRoom MMC plugin: Start Menu, Run, “C:\Program Files\eRoom\eRoom Server\ERSAdmin.msc”

You should then be able to create a site via this screen.

Evaluating CMSes:

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.

Using XSLT to grab only certain RSS entries

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:when test="contains($uc_item_title, 'JAVA')">
              <li><a href="{$item_link}" title="{$item_desc}"><xsl:value-of select="title"/></a></li>
           <xsl:when test="contains($uc_item_title, 'BOULDER')">
              <li><a href="{$item_link}" title="{$item_desc}"><xsl:value-of select="title"/></a></li>


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).