LANrev OSVersion in Database Export

At my day job I’m working with a database export from a LANrev system. If you don’t already know what LANrev is, you might as well stop reading now. I’m just putting this up on the web because I couldn’t find it there when I looked for it, and hopefully this will save someone the trouble of contacting LANrev support.

Still here? Okay then. Many fields in the database tables LANrev exports are numeric indexes to other tables, which are themselves short lists of values. For example, in the software_info table, there is a field named OSPlatform, but rather than actual platforms (e.g. “Mac OS X”, this field just contains a number, which can be used to lookup the actual platform in the table named enum_osplatform.

And that’s all well and good until you get to the OSVersion field, see it contains numbers (e.g. 4167), and look for the corresponding enum_osversion table. But there is no such table. So then you search through other tables, thinking maybe the table is just poorly named, but again, no dice. So then you search online. Previously, you would have found no explanation of this mystery online, but now hopefully such a search brought you here.

The secret? That number, 4167, is the actual version number; it’s just in an obscure format. Specifically, it’s a decimal representation of a hexadecimal representation of three decimal numbers. It’s all obvious now, right? Hopefully an example will clarify. The hexadecimal value of 4167 is 0×1047. The first two digits of that are the major version number, followed by the minor, and then the really minor or “bug” version. That is, put in some decimal points and 0×1047 becomes 10.4.7, the actual version number in it’s familiar format.

Why does LANrev do this crazy conversion? Apparently because Apple does this. Why does Apple do this? I have no idea. To save 2 bytes? And why doesn’t LANrev document this? Again, no idea. But it’s online now. Hopefully it will help someone.

hAtom Makes rel-nofollow Irrelevant

Of all the microformat specs, rel-nofollow has always been my least favorite. A lot of people don’t like rel-nofollow because it makes publishers even more prone to treat links as an implicit endorsement or agreement. And I share that concern, but my main problem with rel-nofollow is the first open issue on the microformat wiki: nofollow indicates a behavior rather than a relationship from which the behavior should be inferred as appropriate for the useragent. HTML is for describing content. JavaScript or some other programming language should be used for describing behavior.

Philipp Lenssen recently suggested removing rel-nofollow from links after a certain amount of time, in an attempt to solve another problem with rel-nofollow: it’s generally used much too broadly. Because few of us have time to inspect every link submitted via an open comment form to see whether or not we want to apply rel-nofollow to the link, most publishers just apply it to all unverified links. Philipp’s logic is that a link published several days ago can be assumed to be okay (i.e. not spam), so we can go ahead and remove the rel-nofollow.

When I read this, I suddenly realized that rel-nofollow has already been made irrelevant by hAtom. Comments marked up in hAtom already have machine-readable dates attached, so consuming applications (e.g. search engines) could make  date-based decisions about whether or not to follow the links. Those date-based decisions would be better at accurately excluding spam (and only spam) than the current decisions based on overly broad rel-nofollow markup. And as an added bonus, publishers get all the other benefits of hAtom, e.g. free comment feeds.

Playing Here

Playing Here is a website I made based on the MySpace Events Feed Creator. It uses the same process to index MySpace pages for events, but instead of creating feeds by band, it creates feeds by state, city, and venue. It also has a microformatted web interface, email subscriptions, and JavaScript includes for the events. E.g.:

Sortable Tables with Totals and Averages

If you’re publishing any sort of complex statistics, it’s often helpful to be able to sort this data. If the data is coming from a database, you can often do this sorting on the server side rather easily, but sorting on the browser side in JavaScript is generally a better user experience. Contrary to what the “table vs. CSS” rhetoric implies, tabular data still belongs in tables (though layout does not). And HTML tables offer a standard formatting for sortable data, allowing us to apply the same JavaScript behaviors to a wide variety to data.

Enter sorttable, a JavaScript from Stuart Langridge. Sorttable automatically adds sorting behavior to any table explicitly classified as sortable, with the simple semantic HTML: class="sortable". This is a great demonstration of the benefits of separating form from function. Unfortunately, anyone using sorttable with descriptive table markup in HTML will quickly run into a problem: totals and averages get sorted along with everything else.

Let’s say you have a table of people with names, ages, and number of children. Sorttable lets you sort this list by name, age, or number of children. But at the bottom of this table, you have an average age and total children. Sorttable sorts this as well. What to do? One solution is to take advantage of the rarely-used tfoot HTML element. By wrapping totals and averages in a tfoot, our HTML can indicate that this content is distinct from the rest of the table. Problem: solved! Semantic HTML saves the day again.

Well, not exactly. We still need to make sorttable take note of this distinction. To do that, we just need to change this:

for (j=1;j<table.rows.length;j++) { newRows[j-1] = table.rows[j]; }

to this:

for (j=1;j<table.rows.length;j++) {
if ( table.rows[j].parentNode.tagName.toLowerCase() != 'tfoot' )
newRows[j-1] = table.rows[j];
}

This should appear around line 78 in sorttable.js. What this does is exclude any table rows within a tfoot from sorting. Now we can safely apply sorttable to any HTML table we want to sort, even if it has non-sortable information at the bottom.

Update: The original sorttable.js has been updated to include tfoot checking, so there’s no longer any need to edit the script.

Discussion List, Crossdomain.xml for Flash

Many people send questions about this site via private email, which is fine. I’m happy to answer these questions. But often the same question is asked by multiple people working on similar projects. In an effort to connect these people, I set up a Make Data Make Sense discussion list. If you have a question others might have, please sign up.

One of these often-repeated questions is “will you add a crossdomain.xml file for my domain so I can load your feeds in Flash?” And I helpfully say “No, I won’t, because I don’t want to spend my time doing that for every domain that might want to reuse my feeds. Why don’t you just set up a simple proxy script on your own server to bypass the restriction in Flash?” In the most recent exchange on this issue, though, I discovered that I can just set up a generic crossdomain.xml file to allow access from any server. So now that crossdomain.xml file is on the server, and Flash-based feed readers are happy.

Ideally the discussion list will arrive at simple solutions like this faster than I could by answering questions privately. Twenty heads are better than one, right? I hope so.

MySpace Events Feed Creator

What was previously the MySpace Events RSS Creator is now the MySpace Events Feed Creator. As the name change suggests, Atom feeds are now an option. Also, there are now two styles for displaying the event information: “Standard,” or what everything was before, and “Simple,” which removes all redundant information (e.g. MySpace user name is in the feed name, so it doesn’t need to be repeated in every event) as well as the labels. And finally, the MySpace profile pages are now being cached every hour, which should improve the speed all around.

The MySpace Blog and Comment tools will eventually get similar updates. Events was done first because someone graciously paid for these changes. If you have changes you’d like to see to any tools here, the first step to getting them done is to ask for them. The second step, paying for them, is optional.

Comedy Central Feed Creator

The Comedy Central RSS Creator has been updated, and renamed as the Comedy Central Feed Creator. Feeds are now available in both RSS and Atom. Feeds also now point to Comedy Central’s Flash video player rather than the old Windows Media format videos. The new player works much better.

Also, the new feeds include video descriptions (in addition to titles), durations, and download links for the Flash video files in both high- and low-quality versions. If you’re using a podcast viewer that can handle Flash video, you can also subscribe to the feeds as podcasts. Finally, the feed creator is caching now. Rather than checking for new videos every time a feed is requested, it only checks once per hour. As a result, the response time should be much faster, which is good for everyone involved: your feed reader, the Make Data Make Sense server, and Comedy Central’s server.

Please leave a note if you have any problems with the improved version, or anything else you’d like to see.

PHP Source Browser

PHP is a popular open source scripting language, but there’s no convenient way to share the source of a live site. It’s easy to make a publicly viewable copy of PHP scripts, but these copies are inevitably neglected when the live copy is updated. Source Browser is an attempt at solving this problem.

Source Browser should be usable on any PHP server simply by setting the directory that should be open source, and optionally any subdirectories that should be restricted. Point it at your server’s root directory, restrict any confidential files, and you have a live open source website.

By default, only PHP and HTML source files are displayed, but any extensions can be specified. Default PHP syntax highlighting is also replaced by class names, to allow easy reformatting with CSS. Source Browser works as a standalone web application, but it can be easily integrated with any existing site. It’s released under GPL. If you have any questions or suggestions, please leave a comment.

MySpace Events RSS Creator

By request, MySpace Events RSS Creator does exactly what the name suggests, growing (completing?) the family of MySpace RSS creators here on Make Data Make Sense. As an added bonus, the events are marked up in hCalendar format, so they can be easily imported into various calendar applications. Please point out any problems or potential improvements in the comments here.

MySpace Podcasts

Feed2Podcast is a neat service that takes RSS feeds, runs them through a text-to-speech engine, and produces podcasts. This service is now combined with the MySpace RSS Creator here on Make Data Make Sense to produce podcasts of MySpace blogs. Standard data access formats (even RSS) allow for this kind of mixing of services. MySpace should have an API.

Bad Behavior has blocked 878 access attempts in the last 7 days.