Nexus, Rails 2.2, I18n

Now I’ve finished off EVE Metrics’s indexes (Performance tweaks are nearly done, just waiting on a few external patches for various bits and pieces) I’m cracking on with Nexus. I figured a good thing to do would be to rewrite all my views, partly to tidy them up a bit in places, partly to ensure everything was written to W3C standards, and partly to implement Internationalisation (Otherwise known as I18n).

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.

EVE Metrics gets Location-Aware

Tactical Map - GUI next!
EVE Map -Next step GUI!

I’ve been working on EVE Metrics as well as my out-of-game EVE map (still without a real name) over the past few days. First things first- EVE Metrics now provides indexes. Ever since the Matari Mineral Index closed trading, corps have been limited in choice for indexes on various items. EVE Metrics is now providing two indexes, one derived from reported orders and the other from EVE’s reported past data. The indexes are wide-ranging, the calculation takes a while, and more interestingly, EVE Metrics now supports favourite regions, allowing you to fine-tune your EVE Metrics browsing experience to provide indexes only related to your regions of operaiton. In future I hope to expand this out to the market, too.

This leads me to an interesting issue- performance. The indexes, what with the nature of customisable data, are all computed in realtime. Trouble is, that’s around 10 seconds of work once all the data has been pulled out of the database, had some maths done to it, and so on. Caching is no good because it’s customisable by users in realtime. Thus, my solution (soon to be implemented) is this; when you load an index, if you are the first person to request that specific set of regions for that index, you will be faced with a progress bar showing index generation. This will be AJAX-updated and hooked into BackgroundRB, which will do the actual index generation, cache it as serialised YAML in a database, and tell the AJAX loader to grab the page, which will render using those cached values from the database. Subsequent requests for that day will be cached automatically. While this seems like it wouldn’t help that much with performance, for those not logged in this will be an absolute boon- having the page instantly load with indexes for all of empire rather than having them wait for 10 seconds is a much better situation.

Once this is sorted out I plan to divert my efforts to Nexus, which includes the killboard components that will form the basis of the killboard in EVE Metrics. Hopefully I can get that sorted for the end of the week, and start merging the changes back upstream to EVE Metrics! From that point on it’s API all the way as I spend some time working out a security model and implementing all the API features as data loaders for EVE Metrics.

Live Dev Blog – Fallout

So I sat in on a Live Dev Blog today. Well, what can I say? It was an exercise in futility. Coupled with the fact that t0rfifrans, our designated CCPian for the blog (and a hotly anticipated one at that, given his up-front and no-bullshit remarks surrounding ghost training), had to miss the blog due to his wife becoming hospitalised (thankfully for minor issues); this and Zulupark’s neat dodging of questions and Mindstar’s neat choice of questions lead me simply wanting more.

Maybe it was the way Zulupark touted ‘new gates’ as a major part of the next expansion. Let’s be honest- new gates are hardly shocking. Shiny, sure. Important gameplay change or vitally needed rebalancing? Nope.

Now, don’t get me wrong. Both Zulupark and Mindstar did a fine job in what was rapidly becoming a tricky situation. But CCP is in a rut right now, especially if you ask the playerbase what they think of recent decisions. CCP has been dodging the real questions and, while doing a great job occasionally, tainting the perceptions of players with decisions like disabling ghost training. Continue reading Live Dev Blog – Fallout