Moving a Rails app from MySQL 5 to Postgres 9

At Bloomfire we recently decided to do a full migration over from MySQL 5 to Postgresql 9. There are a number of reasons for this, including scalability, better feature sets (such as Psql’s full text search engine) and getting away from Oracle before we are forced to move. For the sake of this post, detailed reasons aren’t important.

What I’ve put together here are the few issues we ran into and changes we had to make to get the application working under Postgres. Overall the code changes are minimal as we mostly use ActiveRecord code for communication, and in the places we write SQL directly it was mostly standards compliant. That said here’s what we did have to change.

Read the rest of this entry »

Component / Entity Systems

Note: I’ve put this work on hold and am going another direction with this project. The C++ code is found in the ogre branch. I’ll have a new post about what I’m putting together soon!

If you’ve done any sort of game development in the past 5 years you’ve most likely heard of “Component Systems” or “Entity Systems” for doing object and scene management over an OOP hierarchy. Object Hierarchies may start out clean, but over the course of the development of a game, become a very difficult to work with. Components — very succinctly built self-contained clusters of data and logic that can be added to, or taken away from, anything — are the answer.

There is a ton written about these kinds of systems. A quick Google search of either of the terms in the title will get you to many of the most popular posts describing the why of Component systems, so I’m not going to dive into that myself. Instead, this post will be explaining how I’m implementing Components in Project Slartibartfast, why I’ve made the decisions I’ve made, and how I plan on continuing development with this system.

As an avid supporter of Open Source software, it’s been annoying reading so much about this radically different methodology and find very little code, or code examples that don’t solve the issue I’m trying to solve, concerning Components. Now that I’ve sat down and actually turned an idea in a working system, I realize that these systems really do end up being very specific in their implementation to the product at hand, be it a game, an engine, or something not game related at all. So this isn’t per-say a “this is how you implement Components and Entities” but an exposé of how I’ve decided to implement this in my game.

As an aside, because these arguments come up so often, my personal view of software development and design is that pragmatism beats idealism every single time. As long as you have a good reason for your decisions, build something that works, don’t fret that it’s not a “best practice.”

That said, lets dive into the Component system of Project Slartibartfast.

Read the rest of this entry »

How Rice Works

Rice is one impressive piece of software. I highly doubt I could have written this from scratch (and for that I give Paul Brannan huge accolades for his work) but after working with and on this library for at least a year I probably could. Now that lead maintainership has been passed on to me, I’d like to take some time to explain exactly how Rice works, how one can dive in and help develop this library, and what my plans are for the near future as I work to make Rice and the rb++ suite; a full and proper replacement for SWIG when wrapping C++ libraries into Ruby (if you’re wrapping a pure C library, I highly recommend Ruby-FFI, though Rice will work).

So with that, I’m putting together this post to help clarify exactly how the various parts of Rice work together, how the entire process flows and more importantly helping anyone who’s wanting to learn and work on Rice with a solid starting point (or at least officially crooked). After reading this, anyone should be able to understand the various classes in Rice, and have an idea on where certain functionality lives when looking to add features, or address any bugs. So with that, we’ll start at the top.

Read the rest of this entry »

Adobe Flash 9 & 10 Security Requirements

For those of us messing and working in Flash, the transition from Flash 8 through to Flash 10 have been rife with some major changes in the security model that allows a local Flash application to communicate with the outside world. Adobe, knowing that these are big changes, had its developers write pages, pages, and pages of documentation describing the where what how and why of these updates.

Problem is, it’s very hard to find the simple How-Tos for common situations in all this text. I spent many days scouring and tinkering to figure out the security solution to my application: a flash-based video viewer that would connect into a server and display Motion-JPEG frames that get streamed in.

Hopefully I’ll help save someone else the same hours of research and playing with this problem. My solution is such:

You first need up a simple service on the server you want to connect into that serves the crossdomain.xml content that defines your security policies.

I use a modified version of the service found here: http://www.lightsphere.com/dev/articles/flash_socket_policy.html. It’s updated to be a full Daemon process, so you need Proc::Daemon and Proc::PID::File installed.

Please note:

<site-control permitted-cross-domain-policies=”all”/>

is the required addition to make this script work with Flash 10. Also, if you are worried about corporate firewalls blocking ports < 1000, simply change $port to something bigger, and add the following to your Flash client:

And you're good to go!

Embedding IRB into your Ruby application

A feature I realized would be very helpful to have in rb++ is a debugging console. Basically, I wanted the ability to drop into an irb session and have available to me the internals of rb++ and rbgccxml, all set up for the sources I’ve specified for the given extension.

Turns out, this is a lot harder to figure out than it would initially seem. The irb code is quite complex and nothing there is documented in any way shape or form. Also, searches around the Internet came back with results that were some six years old, and while helpful, did not pertain to my particular case.

Then I remembered that ruby-debug does exactly what I’m looking for. A quick glance in that code got me the code snippet I needed.

require 'irb'
 
module IRB # :nodoc:
  def self.start_session(binding)
    unless @__initialized
      args = ARGV
      ARGV.replace(ARGV.dup)
      IRB.setup(nil)
      ARGV.replace(args)
      @__initialized = true
    end
 
    workspace = WorkSpace.new(binding)
 
    irb = Irb.new(workspace)
 
    @CONF[:IRB_RC].call(irb.context) if @CONF[:IRB_RC]
    @CONF[:MAIN_CONTEXT] = irb.context
 
    catch(:IRB_EXIT) do
      irb.eval_input
    end
  end
end

And it’s use is quite simple. When you want to drop into an irb session, you simply do

IRB.start_session(binding)

and you will have a code prompt with all data available at your finger-tips.

See the related rb++ commit

You use this feature in rb++ as follows:


ruby your_extension_file.rb console


From there, start playing around with the parsed source tree using either @parser or self.namespace to get started.

There are two hard problems in Computer Science…

Cache invalidation and naming things, and the latter is most definitely not a Computer Science-only problem. I have no idea what to name this blog, so for now, it’s going to remain un-named until either a good suggestion comes along, or inspiration hits me.