Antares Trader Blog

Your humble and not very consistent author has survived the Christmas Rush and the purchase of our first home with very few social causalities. One of these few has been blogging. SureWest is going to come and hook up my fiber connection on Friday, until then I am at the mercy of places that advertise "Free Wifi" but don't actually have a live connection. (I'm looking at you LaBou Bakery of S.Natomas)

This doesn't mean I haven't been hacking. I have started working with Mongo and MongoMapper both of which are really cool and deserve a post written with out the distraction of a fast food joint. I'm also looking at Redis. These alternatives to SQL databases make the complex data relations found in Antares Trader much easier.

I'm also enjoying learning from the folks at the Sacramento Ruby Meet-up. More will flow from this blog.

Finally, I'm starting on Rails 3 sence I know that it will be the version I will want to which I will port Antares Trader. I thought Merb was great, but it will also be nice to be back in the main stream again.

More will flow from this blog. Hopefully starting Friday

Github has recently posted a wonderful article about their history with job queues. It is a superb read and I recomend looking both at it and the README file for Resque, GitHub's new Redis back job queue. It is replacing the venerable delayed_job. In this post I am going to briefly look at some of the concepts of Worker Queues in an attempt to better explain my hopes for Updater, my delayed_job clone for DataMapper.

The factory_girl Gem is a great tool for creating valid test instances on the fly. There are lots of posts about why this is so much better then fixtures. Unfortunately for us DataMapper fans, the official version is not quite compatible with our favorite ORM. I've done my best to remedy that situation. There is now a fork of factory_girl that I have made mostly compatible with both DataMapper and ActiveRecord. You can also pull the gem from GemCutter as dm-factory_girl.

The game loop is an essential part of what makes a game work. To implement one for Antares Trader, I wrote a class that would repeatedly call the update method on DataMapper resources. It was a quick hack that got my mini-game sketches working. Eventually, I needed to pull the code out from under the web server and give it it's own process. For a while it was just a class in the lib directory. Eventually, updater grew to need it's own table in the database and now there was Updater code in too many different places.

At this point I went looking for a better solution. I picked up delayed_job and liked what I saw. It did a lot of what I needed. It had a cool API, and GitHub used it so I knew that it had been tested in the real world. On the other hand there were a couple of features missing, and more importantly, it depended on ActiveRecord. So it was back to Updater.

The Factory Girl gem from thoughtbot is the way to go if you have to test ORM classes. It has been featured in Ryan Bates Railscast, and by good fortune, it also works with DataMapper, my ORM of choice. When I upgraded to the latest release of DataMapper however, all my user tests broke. in particular the crypted_password and salt fields were not being set when the record was saved. I'm using the salted password mixin from Merb and I assumed that it was to blame having not gotten up to speed with some of the new API changes in DataMapper. It turned out instead to be an incompatibility between Factory Girl and Datamapper that had existed for a long time but was now showing up. I've modified factory girl to maintain compatibility and my changes are at http://github.com/startrader/factory_girl.

Internet Explorer is the bane of every web developer's existence. Google being the one of the largest web content producers finally got fed up and has developed a work around for everything that is wrong with IE. They have developed a browser plug-in that completely guts IE and replaces its rendering engine with Google Chrome. The Google Chrome Frame looks like a great way to reach all the cooperate users and grandmas that cannot or will not upgrade to a new browser.

In my last game related post I wrote about the mechanics of making a game work. Just because a game works does not mean it is enjoyable to play. In this post I am going to talk about the reward cycle and why some games are so addictive and other either get boring, or were never fun to begin with.

The key concept her is the action-reward cycle. A player makes a decision and then gets some feedback on that decision. Good decisions get rewards while poor ones are either ignored or reduce future rewards. The thing that makes a game fun to play is the balance and value of these rewards.

Is Ruby better the Lisp? There are lots of ways and reasons to answer questions like this. Some people rightly find the argument banal sense there are so many different values and reasons at play. I personally enjoy such comparisons. The give me a view of how other people code, and different things that can be done in different ways.

My problem is that so often the examples that are chosen show me nothing. They are so small as that they are almost pointless, and if I haven't ever seen something done before, I have no clue why I'd want to do it. My opinion is that articles like this should have one small, but useful example written in both languages. This example should actually solve a problem someone might care about, and it should not be the key idea of either language.

Cucumber is an acceptance testing framework that lets you and your clients write our requirements as short stories and then test those stories fro compliance. Those familiar with it will know that you can tag a scenario by placing putting labels precede by the @ sign on the line imminently before the scenario starts. There are a number of different uses for these tags. They can sort features by priority or developer, or they can designate in what version the feature is likely to appear.

As a one-man-band, I don't need quite that level of organization. But I do use three tags that help me keep my development clean. I do however label all my scenarios as @pending, @current or @passing. I can then use the -t flag to choose which tags to run.

JZForm is a side project I've been working on. Its aim is to provide a DSL for html forms and input in general. After a week of picking at it I'm setting it aside again because it is sapping my energy without showing much progress. The problem is, I really don't know what I want. I have some general ideas, but the API continues to be overly complex while the output is too amorphous to provide a clear path forward.