Today I released Market Bot.  Features include a simple API and high performance thanks to the Nokogiri and Typhoeus gems.  It also has relatively good test coverage using rspec.  More information including examples, benchmarks, and source code can be found on my github account.

Permalink | Leave a comment  »

Pop Dat is our latest mobile game for Apple iOS and Google Android.  We're very proud of it considering it was our first hobby project.

It had some unique goals:

• Low cost: We had a very small budget for art and sound.  All programming was done for free in our spare time.
• Cross platform:  We used Corona SDK in order program once and deploy on multiple platforms.
• Realistic scope: As an evenings & weekends project, we had to be realistic about what we could launch in a reasonable amount of time.

The team did a great job at driving this project to completion.  Please check it out and let us know what you think.  You can also read the official Blue Frog Gaming announcement on our blog.

Permalink | Leave a comment  »

What is it?
Officer is an easy to use distributed lock server and client written in Ruby.  Wikipedia calls it a Distributed Lock Manager (DLM).

Why would I use it?
You use it to prevent race conditions in your distributed applications.  It can be used with any Ruby app including Rails.  Officer helps you coordinate access to shared resources in a predictable way since a lock can be held by only one client at a time.  Other clients will queue in an orderly fashion and wait their turn.

How did it come about?
Back in 2009, my company wrote a Facebook game named Starfleet Commander.  It's a highly competitive, massively multiplayer, real time strategy game.  In other words, it's a Ruby on Rails application that encourages customers to find and exploit race conditions.  I wrote Officer so that I could fix this problem with minimal changes to the game code.

Is it only useful for games?
Although it was originally designed for a game, it can be used with any application that needs distributed exclusive locks.  Most typical web apps don't benefit from Officer since there is little purpose in exploiting their race conditions.

What are the alternatives?
Officer was originally inspired by Elock.  Unfortunately for me, I encountered a serious memory leak in Elock and thus Officer was created.  In many cases, messaging infrastructure is a better choice than a lock server.  One such product is RabbitMQ.  This wasn't an option for Starfleet Commander since it would have required significant re-architecting of the code base.

What about languages other than Ruby?
Officer's network protocol is a very simple JSON syntax so it should be relatively straightforward to port the client to other languages.  Please contribute them if you have the time.

How do I find out more?
Check out Officer on Github for installation and usage instructions.  Feel free to contact me if you have questions or find problems with it.  My email is under my picture.

Permalink | Leave a comment  »

Determining if you should use SQL or one of the many NoSQL solutions can be a difficult decision to make.  Hopefully this guide will help you in your decision making process...

Do you need a lot of flexibility in your read queries?
YES: SQL is the best choice for query flexibility since it has a well understood language for both simple and complex queries. MongoDB is also a good choice since it has some of the features of the SQL query syntax and you can add indexes on both regular and embedded documents.
NO: base your decision on other question(s).

Is it acceptable to take your application down in order to change the schema?
YES: base your decision on other question(s).  Note that if you are using MySQL and have a busy server, you will have to take your application down in order to change your schema.
NO: You really need to consider your NoSQL options or commercial SQL databases.  MongoDB is great in the sense that it doesn't enforce a schema on your documents.  Key/value databases also give a lot of flexibility in this area since they force the schema to be in the application and not the database.  With MySQL, schema changes typically are blocking operations that will cause your application to hang.  This can take from seconds to hours depending on many factors (database size, server performance, etc).

Do you need transactions?
YES: Stick with MySQL or some other SQL database.  SQL is the king of transactions.  Some NoSQL solutions support limited forms of them (MongoDB, Redis).
NO: base your decision on other question(s).

Do your developers have experience modeling data for different kinds of databases (SQL, document, key/value, etc)?
YES: base your decision on other question(s).
NO: Then they should start off by writing some experimental apps using different databases in order to learn their quirks.  Every database has "gotchas" that you really want to learn about before you start writing your application.  This is especially true of NoSQL solutions if you background is in SQL.

Is your IT staff or hosting provider willing and able to support your database?
YES: base your decision on other question(s).
NO: Development costs are only one part of the picture.  Once launched, it's going to need to be supported in production and every database solution requires specific knowledge in the areas of deployment, backups, monitoring, and performance tuning.  You may be able to go with a hosted solution, a contractor, or full time staff if you don't want to support it on your own.

Is your application best served by using multiple types of databases at the same time?
YES: It's becoming more common to combine different types of databases within a single application.  For example, If your application does lots of increment operations (think ad server counting hits or clicks) then you could use the high performance counters in Redis or MongoDB along with using SQL to store everything else.
NO: base your decision on other question(s).

Is scalability a concern?
YES: You're going to need to determine the vertical and horizontal scalability limitations of the various databases.  Some databases like MySQL will scale vertically without much effort (just get a faster server).  Other solutions such as Cassandra and Riak focus on scaling horizontally (add more servers), but then limit you in other ways.  Another area to think about is scaling reads vs writes.  Many database products have different techniques for scaling each (for example, MySQL slaves only scale reads).
NO: base your decision on other question(s).

Are you considering NoSQL for one of your projects?  If so I'd like to hear from you.

Permalink | Leave a comment  »