Rails 2.2 comes with I18n built in, so I’ve been using that. It’s a slow process, turning every string into it’s own categorised, indexed line. It’s all in YAML though, so I can easily work on it freehand without needing to worry about complex systems for storage. The one downside is I get to reload my development server to see changes to the pages, but that’s not too big an issue. It’s easy to use and works like a charm, so it fits the bill for my purposes.

Also, Rails 2.2 is thread safe! I’m interested to see what this does performance-wise on Passenger. Load on my server isn’t a problem but memory is my main concern- Passenger with Ruby Enterprise Edition works great by sharing common elements in memory to reduce usage, but thread safe Rails means I should be able to get away with running fewer servers in the first place. I’ll spend some time with JMeter and New Relic RPM at some point to see what the real-world gains are.

My next challenge is going to be creating a decent looking fittings/kill display interface. I’ve learned a lot working on the TacMap, and have some ideas for how I’m going to display fittings. I don’t think I’ll use the ingame fittings screen picture with overlays; it’s overly complex and imo there’s better ways to show fittings. Considering one of the main goals with Nexus is high performance and given the slashdot-effect style killboard spammings that occur whenever a big kill gets scored, I’d like to try and keep the SQL loading down to a minimum.

I’m also trying to work out what the best way of handling caching will be. My whole configuration system thus far is getting looked at sternly- I’m using Configatron, but think I need something a little beefier than that which supports some kind of webinterface for editing configuration values. Still, that’s a problem for another day.

On the EVE front, Shrike lost his titan. Again. In exactly the same way (cloaked off a gate). Yay.