Practicing JavaScript with Dilbert

I discovered that there was a flash widget displaying Dilbert archives in color, back to the start of 2007.

Naturally I thought to myself “aha, there must be an XML data feed somewhere in that!” Some light flash-decompilation later, I discovered that I was right.

I then seized on this as a learning opportunity, and wrote a much better viewer, in boring old JavaScript. Why is it better? Because it doesn’t require Flash, and is not limited to one panel at a time, that’s why.

My Dilbert viewer, can you view it?

1. It’s perfect in Firefox3 and Safari. Sundays aren’t quite right in IE7; the first and last buttons are missing in Opera. All else is untested.
2. For some reason, the widget seems to get different feeds for the last week or two, which means this viewer is a week behind. I suspect user-agent sniffing, but have not yet been motivated to work out what a flash-player’s user-agent is.

Things learned:
1. Cross-domain xmlhttprequest requiring a proxy is a pain, and has no obvious benefit.
2. jQuery is still awesome.
3. Forgetting to take out debug statements that rely on FireBug when uploading is dumb of me.
4. Decompiling these things is complex – the embed code provided loads a .swf, which loads a .swf, which finally loads the actual widget that displays the comics.

Update: I worked out the cause of the weird out-of-sync-ness I observed between the data files I received and the content seen in the official widget. The lesson is not to trust the data feed when it tries to tell you which domain to look at; it includes a tag, which seems like a perfect complement to the domain-less URLs given in the strip descriptions. However, that domain contains files that are several weeks out of date. So I just hardcoded the “real” URL.

They finally released this stuff to the main Dilbert site, so I just went through and fixed up the viewer to use the appropriate new feed format. Darn changes.

Three gigabytes free…ish announced yesterday that all users get three gigabytes of upload space for free. This is a teensy upgrade from 50MB.

This seems to be primarily for psychological reasons, because there’s a big fat * after the upgrade.

The footnote is that Mr. Mullenweg mentions in this post that “[y]ou still need a space upgrade to upload certain file types, like movies”, and later in the comments that “[y]ou still need a space upgrade to be able to upload MP3s”. So you still have to pay them if you plan to do anything significant with their bandwidth. (Not sure where they stand on humongous zip files, or similar.)

Not that this is wrong of them. It rings a bit of being an arbitrarily large number chosen for PR reasons, but that’s understandable.

The 3 gig limit is very reassuring to an important segment of the blogoratispheroidalmass. Specifically, the people without their own hosting, who want to be able to post their photos on their blog and not worry about having to trim out old ones after a few months.

50MB = 300-500 decent quality JPEGs of photos. It’s easy to imagine that being a problem after a short while. 3 gigs… not so much.

Why I can’t play Dungeon Runners

Last night I thought to myself “hey, I know, I’ll try out Dungeon Runners!” It’s a pseudo-free pseudo-MMO, which could be described as a Diablo parody – that’s the sort of game that sounds appealing to me.

Sadly, I discovered that Dungeon Runners is not a game I can play.

You see, it requires that inbound port 80 be open for your initial connection to a world server. This is a mind-bogglingly weird decision.

Port 80 is an entrenched-by-standards ports – it’s what webservers listen on.

Thus Dungeon Runners is off-limits to two classes of people:

  1. People whose ISP block port 80 inbound, because they really don’t want people running servers. (Verizon did this for a while on my connection.)
  2. People who run a server. (That’s me.)

Okay, I could shuffle ports around, temporarily assigning 80 to my games computer whenever I wanted to log in. But that’s more effort than I want to put into this. Thus I effectively cannot play Dungeon Runners.

How to generate PDFs from XML using Apache FOP in Ruby on Rails

The title is a bit of a mouthful. Sorry.

Before we begin, I present the caveat that this code should not be used on a production system. It launches a java runtime for every single request, which would cripple you. This would need (a) output caching, and (b) some sort of persistent FOP server process before it could be considered usable.

But if you just need to generate PDFs on an intranet app, say, then this could be handy.

Step 1: Put FOP somewhere it can be found. Specifically, its “build” and “lib” folders. I created a “fop” directory in my project, and stuck everything in there. (I don’t promise that this is ideologically sound — I’m new to the whole Rails thing.)

Step 2: Add Mime::Type.register "application/pdf", :pdf to config/initializers/mime_types.rb (this gleaned from Dynamic Graphics with Rails 1.2).

Step 3: Use a controller action something like this:

Then whenever someone asks for “documents/17.pdf” it’ll make a PDF and serve it right on up. In the event that something goes wrong it’ll just display the command it ran, for some rough-and-ready debugging.

For a proof-of-concept you could try this with the example XML and XSLT that comes with FOP. Look for “projectteam2fo.xsl” in the examples directory.

As I said above, this works, but should not be put anywhere near a publicly accessible site.

Thoughts on Ruby on Rails after one day of work

I started looking at Rails (leading to my talking about scaffolding) because I wanted to try writing my next work-project in it.

I don’t know about others… but I hate learning a language/framework in isolation from a project. Writing an insipid tutorial project that I don’t care about doesn’t involve me, and so I don’t learn as well. Also, the applications written alongside tutorials tend to be very carefully chosen to hit all the good parts of a framework, while ignoring the rough spots. Thus I’ve historically viewed “prototyping my next project” as a great time to pick up something new.

So. I started Rails tutorials on Friday, didn’t touch it at all over the weekend, and by mid-morning on Monday I had my proof-of-concept app. I’m storing legal documents described in XML, allowing people to fill in some defined fields on them, then generating custom PDFs/RTFs/PNGs/whatevers using Apache FOP. (That sounds more complex than it is. I’ll post an example later.)

Rails itself is being reasonably unobtrusive, which I approve of. I had to do minor research into how to set up custom mime types for response formats, but it turned out to be quite simple.

Rails 2.0 Scaffolding

I’m learning Ruby on Rails starting with 2.0. This is occasionally problematic, as it was only released a few days ago, and the tutorials are still all for 1.2.

So, to help others, something not mentioned in the release notes, which causes errors if you’re following the official tutorial.

Scaffolding has changed.

The 1.2 way was to stick scaffold :modelname into a controller.

The 2.0 way is to run ./script/generate scaffold ModelName field1:type field2:type field3:type on the command line.

The new way is more useful, I think, as it reduces the initial hurdle of moving from a scaffolded controller to a slightly custom one. It gives you controllers filled with code ready to be tweaked, and sets up a migration to create your model. You’re left with a working site filled with examples of how to do things in rails, instead of a magical “scaffold :foo”.

It’s just that it’s a wee bit undocumented.

An aside: I felt that I needed to post this because googling for “rails 2.0 scaffolding” didn’t actually produce anything helpful on the first page or so. Lots of talk about whether it’s ideologically pure, but not so much on the “this is how to do it” front.

[Update: I get the impression, from seeing others talk about this, that it’s not so much that scaffolding has changed as that one scaffolding option has been removed. It looks like the scaffold generator was there pre-2.0, and the only change is that scaffold :Foo is no longer available. Still breaks every “getting started with Rails” article I’ve ever seen, though. 😛 ]

Niche WoW news

* NEW – freeSlots, bagType = GetContainerNumFreeSlots(bagIndex) — Returns the number of free slots in a bag, and the type of items that can go in the bag. For bagType, 0 means any item can go in the bag.
* NEW – bagType = GetItemFamily(itemID | “name” | “itemLink”) — When used with a container, this returns the type of container. When used with an item, it returns the type of container the item can go in. However, bagType is a bitflag, so GetItemFamily for something that could go in a quiver (bagType 1) and an ammo pouch (bagType 2) would return 3. A bag that can hold both arrows and bullets would also return 3.

This does mark the first time I’ve asked for API functionality and had it implemented. 😀