I’m working on an application that needs to be supported on a wide variety of browsers, and unfortunately includes some interesting javascript and css. There are three problems we’ve encountered so far.

1. Finding Browser share

When you want to support most users, you have to try to figure out what they’re using. There are at least three or four different sites which give you their browser share, but I think you have to pay if you want really accurate, detailed information; here’s one source, here’s another, and here’s one last site. Update, 11/3: here are stats for the www.bbc.co.uk homepage.

2. Javascript specifications

Perhaps it’s just me, but I’ve had a devil of a time finding a list of javascript events supported by various browsers. I’ll give it to Microsoft, they have some documentation on supported events; I couldn’t find a similar list of events anywhere on the mozilla site. Here’s the Mozilla Javascript page but I don’t see anything resembling an API there. (All I want is a javascript javadoc!) Here is the best comparison of event support on modern browsers that I found. Update 10/31: here is a list of events that Gecko recognizes.

3. Getting ahold of old browsers and older operating systems, so you can test

Luckily, this is fairly easy to solve. VMWare (which I’ve written about previously) takes care of the various operating systems (well, that and a mac mini) that we need to test under. And a simple google search turned up a fantastic archive of old browsers: browsers.evolt.org, which has many different browsers going all the way back to NCSA Mosaic!.

I have a client who wants to put some maps on his commercial website. I’ve done a bit of looking around, and it’s not clear to me what the best way to do it is. There are really two types of mapping services out there. One depends on URL creation, like MapQuest, MapBlast, Yahoo and Google–you don’t register or do much coding at all, you just create a GET string with the address encoded in it. The other is a web service where you register for a key and use an API to generate a map, like Yahoo, Google and MapPoint. You’ll note that Yahoo and Google appear on both of those lists–that’s because they provide both a URL interface and a more formal API.

Now, even though I am not a lawyer, it seems to me, via looking around at the various Terms Of Service (TOS), that commercial use of any of the URL interfaces is not an option. The Yahoo Maps TOS says

The data included in Yahoo! Maps, including but not limited to maps, routes, and/or directions (“Data”), is provided for your personal use only…

while the MapQuest TOS says

…MapQuest grants you a nonexclusive, non-transferable license to view and print the Materials solely for your own personal non-commercial use.

Google Maps, which has been extensively mashed up with other sorts of data, appears to abide by the general Google TOS which say

The Google Services are made available for your personal, non-commercial use only. You may not use the Google Services to sell a product or service, or to increase traffic to your Web site for commercial reasons, such as advertising sales.

To be fair, you may contact Google about commercial services: [i]f you want to make commercial use of the Google Services, you must enter into an agreement with Google to do so in advance. Updated, 10/30: apparently the maps API is governed by a different TOS, which apparently allows commercial use “as long your site is generally accessible to consumers without charge”. My apologies. I didn’t look at MapBlast too carefully, because it’s built on the MapPoint web service, which has a noncommercial provision.

Luckily, at least for those of us in the United States of America, there are two services provided by the Census Bureau (see, those taxes you’re paying are worth something!) which provide mapping data. As far as I could find, these services have no limits on commercial or non commercial use, but they are a bit hokier than the ones I laid out above. (Here are the Tiger TOS and the general Census position of resale.) The Tiger site was the preferable of the two, because it actually gives you a marker for your location. Of course, you have to geocode your address to find your lat/long, but Geocoder.us makes this easy, and even provides instructions on making your own service. The data for Tiger is from 1998, however. If you’re looking for more recent data, FactFinder is worth looking at. It didn’t work for my client because it provided no way to pinpoint a particular address, though it did allow you to recenter on one without geocoding it.

Neither of these provide directions, as far as I could see, so if you’re looking for that, as well as if you want the cooler interfaces of the private sector, you need to look to the web services.

MapPoint, which is a Microsoft service, explicitly denies external commercial use in its TOS:

MapPoint Web Service is for your individual use, solely for internal use by you for your business, or for your own personal use.

Yahoo and Google, however, take a bit more flexible position. For each of these services, according to their TOS, you need to contact them to use the web service they provide in a commercial context. (Yahoo Maps Web Service TOS, and the Google TOS for the web service which is the same as that for the URL interface service.) I have no idea what kind of licensing agreement will emerge from talks with these companies, but, from reading their TOSes, it appears to me that if you want to use their data in a commercial manner, you need to have that conversation.

I’ve covered all the services that provide maps that I know of. Please let me know if there are any that I’ve missed or anything I’ve misinterpreted.

Joel has a new article out, on the topic of setting your priorities for new development. I am mostly in the consultingware business, and love his characterization of it. Most companies I’ve worked for want to get in the shrinkware business, but for various reasons it’s hard to do (mostly because you have to invest time and money up front–I have seen several attempts to build a product on top of work done for a customer, but never a success)–whereas selling your labor is easy. However, I think that his fast and loose prioritization scheme would work well for custom software development too.

If you write web applications, you should peruse the latest release of the Open Web Application Security Project Guide, currently at 2.0.1. Its 293 pages of tips, tricks and techniques, for multiple languages, should be useful to any developer.

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