Do you ever think about programming? Rather, do you ever think about how you think about programming?

You have to start somewhere
Indeed, the whole reason I got into computer programming in the first place was because I wanted to program games. It was circa 1991-1992 when I got heavily interested in programming computers. 286 CPUs running MS-DOS represented the platform I had access to. I was trying to transcend GW-BASIC and learn Turbo Pascal and Turbo Assembler. A little game called Test Drive III was one of the most remarkable titles I had seen running on this type of hardware at the time. Not only did the game do polygonal 3D graphics but it had sound support through various sound cards or the PC speaker.

At the time I was trying to understand how to do decent 2D graphics programming as well as audio programming (background music, sound effects). I had access to a friend’s Sound Blaster and after lots of research (solid, useful programming data was notoriously scarce) and plenty of trial and error hacking assembly language, I finally got the Sound Blaster to make a few blips. I probably still have the code in my archive somewhere.

I didn’t write this post just for my own sentimental programming nostalgia; there’s a punchline here: Read the rest of this entry »

About that “true” offline RSS reader that I pitched in my last post, I’ll have you know that I made a minimally functioning system based on that outline.

These are the primary challenges/unknowns that I assessed from the outset:

1. Manipulating relative URLs of supporting files
2. Parsing HTML in Python
3. Searching and replacing within the HTML file
4. Downloaded .js files that include other .js files

For #1, Python’s urlparse library works wonders. For #2 and #3, look no farther than Python’s HTMLParser module. This blog post helped me greatly. I have chosen not to address #4 at this time. I’m not downloading any JavaScript files right now; the CSS and supporting images are mostly adequate.

Further, it turned out not to be necessary to manually build an XML parser. Whenever I encountered a task that felt like it was going to be too much work — like manually parsing the XML feeds using Python’s low-level XML systems — a little searching revealed that all the hard work was already done. In the case of parsing the RSS files, the task was rendered trivial thanks to FeedParser.

Brief TODO list, for my own reference:

• Index the database tables in a sane manner
• Deal with exceptions thrown by malformed HTML
• Update the post table to indicate that a post has been “read” when it is accessed
• Implement HTTP redirection (since some RSS feeds apparently do that)
• Implement cache control so that the browser will properly refresh feed lists
• Add a stylesheet that will allow the server to control the appearance on links depending on whether or not the posts have been read
• Take into account non-ASCII encoding (really need to train myself to do this from the get-go)
• Forge user agent and referrer strings in HTTP requests, for good measure
• Slap some kind of UI prettiness on top of the whole affair; I’m thinking an accordian widget containing tables might work well and I think there are a number of JavaScript libraries that could make that happen

Once I get that far, I’ll probably put some code out there. Based on what I have read, I’m not the only person who is looking for a solution like this.

My current living situation saddles me with a rather lengthy commute. More time to work on my old Asus Eee PC 701 (still can’t think of a reason to get a better netbook). It would be neat if I could read RSS feeds offline using Ubuntu-based Linux on this thing. But with all the Linux software I can find, that’s just not to be. I think the best hope I had was Google Reader in offline mode using Google Gears. But I couldn’t get it installed in Firefox and the Linux version of Gears doesn’t support the Linux version of Chrome. I did a bunch of searching beside and all I could find were forum posts with similar laments: Offline RSS readers don’t allow you to read things offline. Actually, to be fair, I think these offline RSS readers operate exactly as advertised: They allow you to read the RSS feeds offline. The problem is that an RSS feed doesn’t usually contain much meat, just a title, a synopsis, and a link to the main content. What I (and, I suspect, most people) want in an “offline reader” is a program that follows those links, downloads the HTML pages, and downloads any supporting images and stylesheets, all for later browsing.

I didn’t want to have to reinvent this particular wheel, but here goes.

Here’s the pitch: Create a text file with a list of RSS feeds. Create a Python script that retrieves each. Use Python’s XML capabilities (which I have already had success with) to iterate through each item in an RSS feed. For each item, parse the corresponding link. Fetch the link and parse through the HTML. For each CSS, JS, or IMG reference, download that data as well. Compute a hash of that supporting data and replace the link with that hash. Dump that data in a local SQLite database (you knew that was coming). Dump the modified HTML page into that database as well.

Part 2 is to create a Python-based webserver that serves up this data from a localhost address.

One nifty aspect of this idea is that my Eee PC does not have to do the actual RSS updating. If the relevant scripts and the SQLite database are stored on a Flash drive, the updating process can be run on any system with standard Python.

See Also:

• Part 2, where I get this idea to a minimally functioning state

Once upon a time, I made a valiant effort to create a compatibility page for FFmpeg. The goal was simple– document how to use FFmpeg to generate media files that would play back in the most common media players of the day. At the time, this included Windows Media Player and Apple QuickTime Player. The exercise was naturally obsolete quite quickly due to the fact that I used some random SVN revision (actually, this is so old that I think we were still using CVS at the time).

I still think this is a worthwhile idea. I now realize that the idea can be improved by FATE. Create a series of test specs that map to a certain encoding combination known to work on a popular media player (or even a popular media device– this could be used for testing, e.g., iPod profiles) and document the command lines on the website. When one of the command lines breaks for all configurations, it will be worth investigating to learn why and whether the website example needs to be updated, or whether FFmpeg needs to be fixed.

Testing process:

• Develop command line that should produce content playable for popular software player or device
• Transcode sample media with command line
• Test media on target player to make sure it plays
• Enter FATE test spec
• Document command line on compatibility page

Such a FATE test will be contingent upon a built-in file checksumming feature as I have outlined for a future revision.

Suppose FATE had the infrastructure to test arbitrary branches of FFmpeg. I just realized that it wouldn’t necessarily help because the FATE test specs keep changing as the code is adjusted. This implies that there needs to be more sophisticated test management.

This occurred to me due to the chatter surrounding the recent FFmpeg 0.51 security release. Running the FATE suite against 0.51 doesn’t work since the current state of the various FATE tests are contingent upon the current mainline FFmpeg source. Possible solutions going forward? Perhaps upgrade the FATE database to support some kind of versioning? However, this would also limit my ability to monkey with the existing FATE suite of samples.

A little while ago, an article made the rounds which detailed a visit to The Weird Stuff Warehouse in Silicon Valley. Since I have a thing for weird, obscure stuff, I knew I had to pay a visit.

I didn’t find much interesting material there, though that’s probably more an indication of my own changing interests (there was a time when I would have enjoyed buying up vintage hardware for cheap). They did have an old MPEG-1 ISA bus video decoder board. There wasn’t much in the way of old entertainment software, which is my current interest. However, I did find an old SGI IRIX OS CD-ROM. Since SGI was more or less synonymous with multimedia back in the 1990s, I thought this disc might have some classic multimedia examples.

The manual that comes in the jewel case seems to focus exclusively on using FlexLM.

When ripped, ‘file’ identifies the disc image as “SGI disk label (volume header)”. Is that the same as SGI’s XFS? I installed Linux’s XFS module but was unable to mount the filesystem. Scanning through the image, I didn’t fnd any strings that would indicate more common multimedia types from the era.

Weird Stuff Warehouse also had an SGI Octane machine for running the OS. You have no idea how hard it was to resist the urge to buy it and run the FATE client on it.

I’m strangely fascinated by inappropriate, colloquial error messages. Some software teams insist on smuggling them in despite what the user interface guidelines say about clear, useful error messages. Such is the case with the Google Chrome web browser and it’s “Aw, Snap” error message when a page crashes.

I had been seeing this message with inordinate frequency (3 guesses why) when I started to wonder how this translates into some of the other 50 languages that Chrome supports. I switched my environment’s language to ‘fr’ and saw what appeared to be Francophonic squealing:

My goodness, did they really task their translation team with finding a culturally accurate yet wince-inducing exclamation phrase for this screen in every supported language? Probably not, considering the en_US and en_GB phrases are the same (I’m assuming the phrase in question is an American expression but it could very well have crossed the pond by now). If it seems like I’m putting a lot of thought into this, imagine how much consideration various Google committees had to exert; Google is famous for not making moves unless the data says it’s okay (e.g., testing 41 shades of blue). I guess from that perspective, the translation team is lucky they didn’t get stuck with translating “Oh no this web page di’n't just crash on you!”

While I’m fairly certain that “Aie aie aie” is not a literal translation for “aw, snap”, the following languages do feature literal translations (at least according to Google Translate): Czech, Danish, Estonian, Finnish, Korean, Slovenian, and Portuguese (Brazilian, while pt_PT translates to “Ah, balls!”). A number of other languages (like German, Spanish, and Croatian) feature translations that quite clearly seem to be “Oh no!”. Turkish’s exclamation is simply “Error” which might be the most appropriate of the bunch. Vietnamese’s phrase translates to “Sorry”, which is also reasonable.

In yet another in a long series of useless exercises, I have assembled a gallery of all the Google Chrome translations for “Aw, snap”. See what your favorite language uses for the message and whether in makes any sense (alphabetical by language code): Read the rest of this entry »

As with every summer since 2006, FFmpeg has been accepted as a mentor organization in Google’s Summer of Code. With the GSoC program, college students are able to earn up to $4500 for successfully completing a task for an open source project.

Visit this year’s FFmpeg GSoC page at the MultimediaWiki for more details. According to the program timeline, the student application process begins on March 29.

Apologies for not properly crediting ideas here: Someone once suggested that it would be useful to have a MultimediaWiki page that collected information about all of the various FATE machines, rather than keeping it in the central FATE database to be displayed in a very inept fashion through the main website. Further, someone (possibly the same person) thought it would be neat to have pictures of all the machines performing FATE duty. I have done both on the new FATE Machines page. Eventually, FATE will simply link over to that wiki page rather than its own internal page.

The machine shown above is pretty much the hardest working computer on the FATE farm. It sits on the floor of my living room and constantly churns away, rebuilding and testing FFmpeg for 22 different compiler configurations.

Other FATE machine administrators are welcome to edit their machine’s descriptions and upload pictures (provided they have physical access to their machines; I’m really not sure about the arrangements that some of you have).