def loot(character_sheet_file)
  @xml ||= Hpricot::XML(character_sheet_file.read)
  @loot ||= @xml.search("//LootTally/loot[@count!='0']").map do |item|
    res = item.search("//RulesElement")
    case res.size
      when 0: nil
      when 1: coder.decode(res.first.attributes["name"])
      when 2: coder.decode(res.last.attributes["name"].sub(res.first.attributes["type"], res.first.attributes["name"]))
      else    res.map { |re| coder.decode(re.attributes["name"]) }.join(" ")
    end
  end.compact
end

Character files from D&DI Character Builder store loot as a list, but the names of magic items are concatenated with names of their connected mundane items, so you have to mix them based on the magic item’s @type.

Also, the Character Builder stores every item you’ve ever added, even if you deleted it immediately, so you have to filter out items with a count of zero. You have no way to tell if this was an intentional item purchase, an item accidentally clicked on or a found item from a module, so items with @count=0 are useless.

What could I possibly be building‽‽‽

package {
  public class ScopeFu {

    private static var var0:String = 'var 0';
    public static var var1:String  = 'var 1';

    private var var2:string = 'var 2';
    public var var3:String = 'var 3';

    public function ScopeFu(var4:String = 'var 4') {
      var var5  = 'var 5';

      trace(var0);
      trace(var1);
      trace(var2);
      trace(var3);
      trace(var4);
      trace(var5);
    }
  }
}

And yet it works.

Compared to JavaScript:

var ScopeFu;
(function() {
  var var0 = 'var 0';

  ScopeFu = function(var4) {
    this.var2  = 'var 2';
    this.var3  = 'var3';
    var4       = var4 || 'var 4';
    var var5   = 'var 5';

    console.log(var0);
    console.log(ScopeFu.var1);
    console.log(this.var2);
    console.log(this.var3);
    console.log(var4);
    console.log(var5);
  }
  ScopeFu.var1 = 'var 1';
})();

Still a mess. The JavaScript syntax is a little more cryptic and var2 isn’t private, yet there are half as many scope collisions. The ones that do exist are only because JavaScript doesn’t really support private members; I’m using closures to fake it.

In either case, scope can become a nightmare in large applications when you’re trying to figure out where something is defined, especially when you’re jumping back and forth between the otherwise-similar languages. Underscores and access methods can help, so long as you are disciplined enough to be consistent:

Adopting these kinds of conventions may help keep scope sorted amongst a group of developers.

Browsers are fickle beasts, and have some wildly different implementations of the same operations. At the same time, JavaScript applications are becoming more complex and the Internet is rapidly spreading to gaming consoles, mobile phones and linux-powered toasters. Performance optimization is an important tool to keep our applications running sprightly.

Prototype’s document.viewport.getDimensions is a great example of some easy optimization. The method, in the master:

document.viewport = {
  getDimensions: function() {
    var dimensions = { }, B = Prototype.Browser;
    $w('width height').each(function(d) {
      var D = d.capitalize();
      if (B.WebKit && !document.evaluate) {
        // Safari <3.0 needs self.innerWidth/Height
        dimensions[d] = self['inner' + D];
      } else if (B.Opera && parseFloat(window.opera.version()) < 9.5) {
        // Opera <9.5 needs document.body.clientWidth/Height
        dimensions[d] = document.body['client' + D]
      } else {
        dimensions[d] = document.documentElement['client' + D];
      }
    });
    return dimensions;
  }
  /* other methods */
};

The function operation is quite simple:

1. Create an object to hold your results
2. Create an array of possible properties
3. Loop through those properties, each time:
4. Figure out which method to use, based on which browser you have
5. Get the viewport width using that method
6. Figure out which method to use, based on which browser you have
7. Get the viewport width using that method
8. Return the object

However, it’s very wasteful. Steps 2, 4 and 7 execute every time you run the method, even though their results will always be the same. This may not be a big deal, but if you’re using this method a lot—for example, along with the window.onresize event handler which can fire many times per second—every little bit can help.

The above method uses some Ruby paradigms—$w() and self—leveraging a style unique to JavaScript will help us save some complexity without changing underlying logic.

document.viewport = {
  getDimensions: function() {
    var B, vpsizer;

    B = Prototype.Browser;

              // Safari <3.0 needs self.innerWidth/Height
    vpsizer = (B.WebKit && !document.evaluate) ?
      function (D) {
        return self['inner' + D];
      } :

      // Opera <9.5 needs document.body.clientWidth/Height
      (B.Opera && parseFloat(window.opera.version()) < 9.5) ?
        function(D) {
          return document.body['client' + D];
        } :
        function(D) {
          return document.documentElement['client' + D];
        };

    function it(acc, value) {
      acc[value] = vpsizer(value.capitalize());
      return acc;
    }

    function f() {
      var r = {};
      it(r, 'height');
      it(r, 'width');
      return r;
    }

    return (document.viewport.getDimensions = f)();
  }
  /* other methods */
};

This might look a little alien at first, so let me walk through it.

1. Remove the array of properties. It’s a waste to invoke all of Prototype’s Array mechanics for a two-member array that never changes. We still set the browser name because we’re doing the same checks as the previous function.
2. We set vpsizer to a different function based on the browser’s needs. While using the ternary operators and function literals together looks a little awkward, it’s the most concise way to so set a variable based on shifting conditions where you can’t use a switch statement. In my opinion it’s always best to minimize the amount of assignment operators you use, as it becomes easier to track down exactly where variables are set.
3. The two functions it (short for iterator) and f are our workhorses. Now that we’ve stored vpsizer in memory, we call it for 'width' and 'height'.
4. In the last line we’re doing three things in concert:
   1. Assigning document.viewport.getDimensions (the current method) to our workhorse function f. This means that all of the logic we’ve done so far remains in memory and we never have to do it again.
   2. The assignment operator also returns the assigned value. By wrapping the assignment in parenthesis, we can then use the () operator to immediately call f.
   3. We exit the function, returning the value of f().

What have we done? After all, the function looks more complex now than before. However, running the following script will show the performance difference:

alert(document.viewport.getDimensions);
document.viewport.getDimensions();
alert(document.viewport.getDimensions);

Note that second alert: document.viewport.getDimensions is now only four lines of code. We have, however, removed quite a bit of syntactical sugar. Much like putting a slinky on top of your stairs converts kinetic energy into potential energy, we’ve converted computational complexity into conceptual complexity.

I’m not a pro at testing performance, but a rudimentary test is showing performance gains of averaging around 40% or more over time. Re-setting document.viewport gave me gains of 15% or so, and removing the Array madness added 25%. Now a cynic might say that we’re only really shaving a handful of milliseconds off of execution, but remember: checking the viewport size is not an intensive operation. Using these techniques in your own code can come to surprising benefits.

All that’s left, of course, is to commit the code. Problem. Prototype Rake to do unit tests, and I can’t for the life of me get Opera to pass any of the viewport tests. In fact, I can’t get window.resizeTo() to work in Opera at all unless the window I’m resizing is a pop-up I’ve created. I’ve tried setting and unsetting Opera’s JavaScript preferences in 9.5 and 9.2 multiple times. Any help would be appreciated.

Notes

1. One note, however: do not use this technique to cache DOM Objects, lest you invoke the feebleness of Internet Explorer. ↩

JavaScript and Ruby are dynamic or duck-typed languages, meaning that variable values are converted between types when your code requires, allowing you to do things like:

"2" * 2 == 4 // true

Instead of having to manually convert between types. This allows some shortcuts for otherwise annoying code. For example, you never have to do

if (typeof foo == 'undefined' ||
    foo === null ||
    foo === false ||
    foo === "0" ||
    foo === '') { doSomething();}

You can just do

if (foo) { doSomething();}

In JavaScript you can also do some nifty type conversion:

"4" * 1 // 4
4 + ""  // "4"
!! 4    // true

This can lead, however, to some odd bugs if you’re not careful. I was receiving a boolean flag via JSON, which came across the wire as zero or one. In my application I had something that was essentially

if (flag) { makeTheMagicHappen();}

Unfortunately, flag was coming in as a string, not an integer. I want flag as a Boolean, but "0" evaluates to true, so my flag was coming up incorrectly. Worse, this was a pretty tough bug to spot. The solution, of course, is:

if (Boolean(Number(flag))) { makeTheMagicHappen();}

or

if (!! (flag * 1)) { makeTheMagicHappen();}

Worse, type coercion varies between languages. Ruby converts all values except nil to true.

Notes

1. Actually, the solution is to change the bad data, but for complicated reasons outside of this post’s scope, that’s not possible. ↩

You can share your private video by following the steps below:

1. Sign into your account.
2. Enter the “My Videos” section. There are three ways to do this:
   • Click the “My Videos” link in the “Account” dropdown at the top of the page.
   • Click the “Account” link at the top of the page, then click the “Uploaded Videos” link in the “My Videos” section.
   • Click the “Account” link at the top of the page, then click the “Videos, Favorites & Playlists” link in the “My Account” dropdown.
3. Click the edit button next to the video you would like to share.
4. In the address bar of your Web browser, change the the text my_videos_edit2 in the URL to my_videos_edit.
5. Under “Broadcast Options”, click “choose options”
6. Click the “Private” radio button “+” next to the label that contains the user you want to share with. If you do not have a Label set up, do the following:
   1. Click the “edit contacts” link.
   2. Click “New Label” either under the “Label” drop down or the “New” drop down.
   3. Enter a name for the list, then click “Create”
   4. Click on “All Contacts”
   5. Click the name of your contact.
   6. Click “Edit”
   7. Check the check box next to the label to which you want to add the friend.
   8. Click the “Save Changes”
7. Click the “Update Video Info” button.

And there it is: eight (or fifteen) simple steps to sharing a private video on YouTube.

My Web app works in IE Mobile 5 and 6, Opera Mobile 8.65, Opera Mini 4 and the iPhone Simulator. A proper iPhone version would require a slightly different UI and leverage the absurdly better layout engine of MobileSafari, but this will work while I wait for lines to thin this weekend.

Opera Mobile is very good and will handle almost anything you throw at it; Opera Mini is a mysterious beast, but seems to “just work”. IE Mobile, however, is a bizarre member of the device browser family, and like its desktop-sized predecessors, has some quirks:

• Both support more selectors, but far fewer CSS properties than IE 6. Luckily the IE Mobile 6 and IE Mobile 5 documentation is well done, if hard to find.
• Unobtrusive scripting is explicitly not supported. At all. If an element needs to listen for an event, it must use the onevent="" attribute in the HTML.
• Transparent PNGs and GIFs cause visual static when used as background images.
• HTMLElement#nodeName is not supported; you have to use HTMLElement#tagName.
• The getElementsByTagName method is supported only on the document object in IE Mobile 6 and not at all in IE Mobile 5. If you want to support that browser, element references must be done via IDs.

In addition, feature detection and document.getElementById are new features in IE Mobile 6. Luckily, IE Mobile 5 populates the window Object with variables named identically to element IDs, as if it could do:

var el, c = -1;
while (el = document.getElementsByTagName('*')[++c]) {
  if (el.id) {
    window[el.id] = el;
  }
}

Because IE Mobile 5 lacks feature detection, testing for this case requires some special work as well. Porting the dollar function to device JavaScript looks like the following:

var $ = (function() {
  try {
    (! document.getElementById);
      return function(id) {
        return document.getElementById(id);
      };
  }
  catch(e) {
    return function(id) {
      return window[id];
    }
  }
})();

This simplified version accepts only a string argument. It’d be a good coding exercise to rework it into accepting a string, HTMLElement or Array. Good luck!

UPDATE: The application is a very simple means to track life in a game of Magic: The Gathering. Check out the Magic Game Tracker.

We went through a ton of candidates. It amazed me the range of skills and knowledge people applying for a Web Developer position had. But in general, I ran a few common issues that soured me on many candidates.

Know what you don’t know

One of the first questions I ask candidates is how they rate themselves on a one-to-ten scale with HTML, CSS, JavaScript and Flash. Amazingly, most of the candidates rate themselves a nine or ten in HTML. Now I’m pretty sure only Ian Hickson, and maybe Anne Van Kesteren grok HTML in it’s fullness, but if you rate yourself a ten in HTML and cannot describe the differences between HTML and SGML, or the parsing irregularities between the four major browsers, it reflects poorly. Many candidates rated themselves a seven or higher, but could not describe the purpose of a <label> element.

JavaScript is not just frameworks

I wasn’t prepared for the number of people with little or no idea how to program professionally in JavaScript. While I don’t require an intimate knowledge of the various native objects or having the ECMA standard memorized, good Web Applications require understanding why framework makers have to work around quirks like the event model—not just that they do.

In addition, most self-taught programmers have little grasp of good programming patterns that save time and make self-documenting code. The best Web application in the world is useless to me if I have to re-write it form scratch a month later because it would take less time than learning how it works.

I had a number of candidates ask me how I came about my JavaScript knowledge, and I didn’t have much to offer them. I’ve never taken a JavaScript class, although my unsuccessful interview at Google could be considered one. I do, however, recommend two books: PPK on JavaScript by Peter-Paul Koch and Pro JavaScript Design Patterns by Dustin Diaz were invaluable resources. The first is a very low-level examination of the history of JavaScript, while the second is a high-level translation of classic programming methods to JavaScript.

Play

The people who stand out to me are the people who play with the discipline. If your resume is a Word Doc or PDF, you’re starting with a strike against you. Have interesting side projects and who show a curiosity in the medium. Own yourname.com or yourlameinternethandle.com and show me what interesting things you’re doing with the Web 2.0 API of the week. Even if it’s a horrible hack or you code is just plain bad, I’d rather have that than a code wizard on autopilot.

Visionaries of HTML, CSS and JavaScript have been promoting this change—which they knew about before the rest of the world—with an odd sort of fanfare. Says Zeldman:

What’s really new is that by opting out of Microsoft’s version targeting … you get to skip testing in future versions of IE. If your site works in IE7 today, it will work in IE47, or so Microsoft has promised.

It’s the Microsoft has promised line that raises my hackles. Microsoft is somehow going to port every rendering mode since IE 5.5 into future versions of IE. How long will the cost of backporting IE7′s bugs and quirks to the latest Windows version will be seen as benefiting Microsoft’s shareholders? Methinks it won’t be 40 versions. My guess is two. Tops.

By taking the onus of maintaining sites off of Web developers and onto a fairly untrustworthy party—especially one with a business case for stagnating standards-based development and a means to force it into broad acceptance—we are making a deal with the devil. Version targeting is bad for the Internet.

Who are the unenlightened?

Worse, however, than betting on Microsoft to save us is that Zeldman blames the situation on some theoretical group of unwashed masses that are making bad Web sites:

Zillions of people who don’t know any better do tailor sites to the quirks of IE6. That’s why an improved IE7 “broke” old sites. And it’s why, in crafting a new switch, Microsoft must build its default to protect unenlightened developers.

PPK walks lock-step with Zeldman, using the same rationale as colonial Europe when pillaging Africa.

Noblesse oblige. Since we know more and can do more and better things with web sites, more is expected of us. If our ways are so much better, we should shoulder more responsibilities than those whose ways are wrong. Our shoulders are fit to bear these burdens; [standards-unaware web developers] aren’t.

Both of these articles assume that these unenlightened people are going to magically become enlightened, and not abuse this new property as they do the rest of HTML currently. What seems realistic to me is that these people will start new projects. They’ll want to use new IE features. They’ll use—because they’re not “enlightened”—IE=edge. And Microsoft will have to dream up some other scheme to prevent the Web from breaking, and this hubub will start all over.

We need to stop being elitist. The “problem sites” aren’t just being created by these “unenlightened” developers; they were created by developers—enlightened or not—and have been left fallow. Our industry is flush with hit-and-run agencies and freelancers that throw up a site and then dump it on understaffed, underpaid and under-experienced teams to manage. It’s easy to see that three agency guys might focus on sites created by novice Web developers or existing since the 20th century as the main problems, but I have a hard time believing every Happy Cog site would survive IE8 without some kinds of tweaks. Sites which are not actively maintained, but still have value to Internet users—these are the sites Microsoft is afraid of breaking. A fix is never simple if there is no one to do it.

My guess is that the IE7 update is not the one that fueled the version targeting decision: it was the rancor over Vista. A vast number of applications and device drivers would not function with Windows Vista’s new API’s, and as a result the operating system has had a fairly frosty reception. IE7′s release was a party in comparison. Apparently there exists a hearty core of people that desired to use applications and hardware years after they’ve stopped being maintained. The scripting and CSS updates alluded to with IE8 may bring similar Web sites down, and that’s ill will Microsoft can’t afford to engender.

In other words, updating IE without setting up version targeting to a current browser will break an unknowable number of Web sites which may still contain valuable content but have no means to upgrade and stay current. We need it.

Opting to opt out

Somehow, I’ve got to reconcile this conflict. I’m glad that Microsoft created a way to improve the state of their browser without throwing away the old Internet. That said, I don’t have a very high opinion of that company and am loathe to contribute a spare byte of mindshare to their products by inserting IE crutches in my code. I’m going to let it break. Refusing to use IE’s meta tag will lock their browser to a predictable set of features and bugs—or as predictable as such things will ever be, and for the foreseeable future, IE7′s Web standards support is passable enough for most work, and we’re going to have to support IE7 (the browser, not just the rendering mode) anyway.

I’ve long believed that Web Developers have been, as a group, too milquetoast about dealing with IE’s problems. We tediously work around a cranky browser and then, hypocritically, use buttons that read “this site requires flash,” and “download the PDF viewer.” For me no longer. Any site in beta, any site I develop for fun, and any site without a demonstrable need for IE8 features is going to stay in IE7 mode. At least, that is, until HTML5 is usable.

Notes

1. Mr. Meyer does cite some Web research, but both studies do not prove anything about the current state of Web development. Google’s statistics surveys the entire Internet with no regard to when a page was developed, while Marko Karppinen’s study assumes that validity has anything to do with standards-based design, which it clearly does not. ↩
2. If the IE team truly wanted to preserve the Internet, they’d make version targeting default to IE6 rendering, and not IE7, as IE6 has been actively targeted by Web developers for almost ten years, IE7 a fraction of that. Admitting this, however, makes me die a little on the inside. ↩

I mentioned previously how to set up an EVE Online-focused rails site. After reading through old Riding Rails posts, I noticed this excellent post on iPhone-optimising your rails project. This process is almost exactly the same for sharing views between EVE and a normal browser. In Rails 2.0 all you have to do is register the MIME Type.

config/initializers/mime_types.rb:

Mime::Type.register_alias "text/html", :eve

Then, in your application controller, use a before_filter to adjust the format as necessary.

app/controllers/application_controller.rb:

before_filter :isolate_eve_browser

private
  # EVE-specific data
  def isolate_eve_browser
    if eve?
      request.format = :eve
      request_trust unless trusted?
      end
    end
  end

Now everywhere you want to separate your EVE views from your standard browser views, simply use respond_to.

app/controllers/home_controller.rb:

class HomeController < ApplicationController
  def index
    respond_to do |format|
      format.html
      format.eve
    end
  end  
end

You can then use app/views/home/index.html.erb and app/views/home/index.eve.erb respectively. This means you can also request trust on the appliaction level instead of on the action level as I mentioned previously. Notice that request_trust method above? It should look something like:

app/controllers/application_controller.rb:

private
  def request_trust
    response.headers["eve.trustme"] = (
      "http://#{request.env['HTTP_HOST']}/" +
      "::Your custom message begging for trust."
    )
    render :template => 'trust_me'
  end

The action is rounded out by creating app/views/trustme.eve.erb, which is the template rendered above when the user declines to trust you. Happy coding!

I’ve already got a few ideas on fun things to do with all of this data. The trick is trying to make opinionated Rails play nice with the browser, the API and the Data. To that end, here are the strategies I’m invoking. Comments are, of course, welcome.

Dealing with Data

I can’t even begin to wrap my brain around the cool things you can do with EVE data. A number of desktop applications exist for character tracking and skill planning, but that’s only a very shallow bit of what’s possible. Getting the data into manageable form, however, is a bit tricky.

I wanted to keep my EVE data separate from my game data. Presumably EVE’s data will change over time. Ideally a new dump will come out and I can just swap it with my current one–no fuss, no muss. I downloaded the Trinity 1.0 SQLite3 dump. And dropped it into db/ of my Rails application. Then I had to make sure to point all EVE data to the correct database.

config/datbase.yml:

eve_development:
  adapter: sqlite3
  database: db/trinity_1.0_sqlite3.db
  timeout: 5000
eve_test:
  adapter: sqlite3
  database: db/trinity_1.0_sqlite3.db
  timeout: 5000
eve_production
  adapter: mysql
  database: *******
  username: ********
  password: ********
  host: *******

and

app/models/eve_data.rb:

class EveData < ActiveRecord::Base
  establish_connection "eve_#{RAILS_ENV}"
end

Now any model that subclasses EveData will point to the correct database and key:

app/models/race.rb:

class Race < EveData
  set_table_name :chrRaces
  set_primary_key :raceID
  has_many :careers, :foreign_key => :raceID
end

The tedious part of this is setting up all of the associations, as EVE data does not conform to rails column naming conventions (although it’s not unimaginable that one could fix this with an elegant script).

One last note: if you generate any sub-classes of EveData using the built-in generators, be sure to remove test/fixtures/<subclass>.yml as it will cause you tests to die horrible deaths.

API Wrangling

Rails has a lot of built-in API magic, all of which is absolutely worthless with EVE. Consuming the EVE API requires a lot of anonymous XML parsing. Boooooring! Luckily, Lisa Seelye has an excellent wrapper module for the EVE API. So long as you’re okay with her clear-as-mud license, Lisa’s work will be a great benefit.

Managing the EVE Browser

Update: I’ve written up a slightly better way to target the EVE Browser in Rails 2.0.

The EVE Online browser stinks. I got only halfway through the HTML 4.01 test suite before quitting out of frustration. I’m pretty sure it can’t even render GIF images. I’d love to see them bundle WebKit instead. One thing the browser does, however, is provide custom HTTP headers (without the required X- in front, of course) for in-game EVE data. Custom headers are available to the controller in the request.env collection. I made them available to all controllers and views with the following:

app/controllers/application.rb:

class ApplicationController < ActionController::Base
  ...
  # Provides access to views
  helper_method :eve?
  helper_method :trusted?
  helper_method :eve_data

  private
    def eve?
      !! request.env['HTTP_EVE.TRUSTED']
    end
    def trusted?
      request.env['HTTP_EVE.TRUSTED'] == "yes"
    end
    def eve_data
      if trusted?
        {
          "name" => request.env['HTTP_EVE.CHARNAME'],
          "id" =>  request.env['HTTP_EVE.CHARID'],
          "alliance" => request.env['HTTP_EVE.ALLIANCENAME'],
          "region" => request.env['HTTP_EVE.REGIONNAME'],
          "constellation" => request.env['HTTP_EVE.CONSTELLATIONNAME'],
          "solar system" => request.env['HTTP_EVE.SOLARSYSTEMNAME'],
          "station" => request.env['HTTP_EVE.STATIONNAME'],
          "corporation" => request.env['HTTP_EVE.CORPNAME'],
          "role" => request.env['HTTP_EVE.CORPROLE']
        }
      end
    end
end

The eve? and trusted? methods return booleans and eve_data a hash of the character’s current location in-game. They allow me to write helpers such as

app/helpers/application_helper.rb:

def character_image_tag(id, size, options = nil)
  if eve?
    o = { :src => "#{src}:#{id}", :size => "#{size}" }
    o.merge!(options) if options.is_a(Hash)
    tag(:img, o)
  else
    o = { :width => "#{size}", :height => "#{size}" }
    o.merge!(options) if options.is_a(Hash)
    image_tag("http://img.eve.is/serv.asp?s=#{size}&c=#{id}", o)
  end
end

Guessing by the speed of the browser, using in-game resources instead of external will save the user a lot of time.

As players fly around EVE, the application has the ability to detect a location change and refresh the page, updating the location information. Applications could work in EVE from only one URL, even without JavaScript. In order to do so, however, the application must do some header-gymnastics as well. My take on this is something akin to:

app/controllers/foo_controller.rb:

class FooController < ApplicationController
  def index
    # Tell the client your content will change
    # Not necessary, but correct and future-proof
    response.headers["Vary"] = "eve.trustme"
    if ! eve?
      # Do something to the regular browser
      render :action => "external"
    elsif ! trusted?
      trust_me
      render :action => "trust_me"
    else
      lookup
      render :action => "lookup"
    end
  end

  def external
    ...
  end

  def trust_me
    # Send the trust header
    response.headers["eve.trustme"] = "http://#{request.env['HTTP_HOST']}/::Trust me."
    ...
  end

  def play
    # Send the auto-refresh header
    response.headers["refresh"] = "sessionchange;URL=#{url_for(:controller => 'foo')}"
    ...
  end

end

Each action will then have its own view file and its own logic, but the same URL. Be careful where you send the auto-refresh header: create, update and delete actions should not get them. Note too that the trust_me action should end with render => :nothing or similar. This does not work. The EVE browser requires a text/html file to trigger the trust prompt.

And that’s it! You’re on your way to a Rails-powered EVE application. Please send me any questions, critiques or issues. I’ll post more often with other quirks I pick up.

UPDATE: Modified the database set-up to use my database.yml for EVE data and connect EVE data to my environments. Also moved establish_connection into the model where it should be. I also added a note on fixtures that took me a silly amount of time to work around.

Notes

1. I haven’t been able to find a license for this data. Although I’m guessing it’s Creative Commons Attribution-DontDoAnythingStupid. ↩