EnvyCasts

Now, I’m not usually one for plugging paid-for services. I’m an open-and-free kind of chap at heart. However, there’s no such thing as a free lunch, and while there is a free option for this particular service- that being Rails videocasts- one must be reminded that a free lunch is going to taste worse than the 5-star buffet in the nice resturant.

Anyway, enough waffle. I had first tripped over EnvyCasts on my RSS feeds through various Ruby blogs, and never got around to actually getting any. Having purchased both the Rails 2.2 and Scaling Ruby videocasts, I’m genuinely impressed. They’re of a very high quality, the explanations are excellent and the content is at a level approachable by even beginners but aimed at a higher level than most videocasts. It’s like Railscasts on steroids.

So, if you have $9 (So around £0.50), I strongly recommend picking some up if you have a spare moment.

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.