It's a thing.

I’m working on a new local multiplayer game where players fly ships around a battlefield and use gravitational munitions to push and pull asteroids in an attempt to smash the other players. 

If this sounds like something you’re interested in play testing and you have gamepads you can play with signup here!

I’ll send out occasional builds, ask for your feedback, and let you know when the game is done!

Sometime last week it occurred to me that it was odd that while writing ActiveRecord queries I would occasionally have to write SQL. And then, from a few code reviews I've sat in on at work I got to thinking about how you might write database constraints but also validations for models in Rails. So you're ending up kind of duplicating work across these two spaces. 

Then a few days later I came across an article with a sensational title talking about something called Meteor. So I watched the screencast. Then I downloaded the framework and started an example project. Then I deployed it to their servers. 

It was pretty amazing how quick and easy it was to do all this. The example project consists of three files: an html file, a css file and a javascript file. The html file has some handlebars templates. The javascript file initializes a mongo database and contains both client and server code. 

There’s the point.

Both the client and server code are written in the same language. This idea contains two of Meteor’s seven principles: 

One Language. Write both the client and the server parts of your interface in JavaScript.

Database Everywhere. Use the same transparent API to access your database from the client or the server.

This is good and interesting because it allows you to work in one syntactical context for most of the work you need to do. Which is really cool because it helps you get an application doing something quickly (the main point of this framework).

Recently I've had to work on some older PHP code at work. The most recent issue required finding certain users based on access through a group to a record created by another user. ActiveRecord let me figure out a solution quickly in a Rails console, but when I went to try an implement that solution in PHP I ran into multiple roadblocks. Since there were no magic finders to work with I had to write helper methods to find lists of IDs which I then had to loop through to get lists of users which I then tried appending to an array that I would eventually return.

You may be wondering what I was thinking at the time. The fact is I was being lame and feeling bad about having to work on PHP code (I have very little experience with PHP), and so I was coming up with lame ideas about how to solve the problem. Instead of using the tools available to me I tried to translate 3 lines of ActiveRecord magic into PHP queries and loops. It didn't work.

The real solution to the problem was just one query. Granted, there were a bunch of joins, but after asking this awesome guy and the DBA for assistance it came out pretty nicely.

Use the tools you have. Choose the right approach.

Ever since I learned about Gunpoint I've been interested in what Tom Francis has to say. Today I watched a talk he gave at the 2013 Game Developer's Conference in Europe about how review games helped him design Gunpoint. His first point was explaining why you like something helps you understand it. So I'm going to try to explain why I like a game, maybe this will be an ongoing thing to help me get my thoughts straight on games.

Pac-Man Championship Edition DX+

I've been playing this quite a bit recently and I really enjoy it. Here's why:

It's fast, and as you play it gets faster. But unlike a game like Tetris-where the speed continues increasing until it's unmanageable-it slows down when you make a mistake, which keeps you in the game longer.

Despite its speed it gives you a chance when you really need it. When you get close to a ghost the game slows down and maybe zooms in on Pac-Man, which allows you to analyze the situation and intelligently pick a direction to go instead of randomly hitting a direction and hoping you don't die.

When you find yourself in a situation where there is no escape, the game gives you one last way out. There are bombs you can use which send every ghost on the board back to the room in the center, allowing you to continue on. Bombs are limited, but they can be earned back.

These three things add up to a game that actively wants you to succeed and do better. It might be a little hand-holdy, but that allows you get into the game easily without having to play a dumbed down mode of the game or a tutorial to understand what's going on.

My current project involves groups, users, and granting groups access to a user's requests. I've got a service object that lets me do this, and today I realized I shouldn't let this service object be instantiated with a particular user and group unless a user has a membership to that group. Well it turns out it's super easy to add active model style validations to plain ruby class.

class Foo include ActiveModel::Validations attr_accessor :bar validates_presence_of :bar end

And that's all it takes.

Today I learned about the pretzel colon, or the symbol-to-proc (which may or may not be more descriptive). Pretzel colon is an easy way to take a collection of things and run some method on all of them.

For instance say I have a collection of Pretzel objects. If I want to know if they're all salty I might write:

Pretzel.all? { |p| p.salty? }

But instead I can write:

Pretzel.all?(&:salty?)

Or if I want to eat every Pretzel I have I can write:

Pretzel.each(&:nom!)

When Ruby sees each(&:nom!) it attempts to pass :nom! as a proc object to each as a block. But :nom! is a symbol. Fortunately Ruby has a nice little to_proc method for symbols that–when called on an object–sends the symbol as a message to the object. In this case that means that each Pretzel will get have nom! called on it.

There's a great writeup by Dave Thomas here:

http://pragdave.pragprog.com/pragdave/2005/11/symbolto_proc.html

And there's a great Railscast on this as well: 

Today i worked on a project that was functionally complete, but was not necessarily done. There were even tests passing and everything. But it was like when you see the brain splatter on a wall from a shot to the head in a movie. There was code everywhere, across four models: group, access, membership, and user.

The answer was a service object. By extracting this complicated matter out into its own class, I was able to remove complexity from four other models. This object is instantiated with a couple IDs in a controller action and then one of two methods is called on it, create or destroy. It keeps my controller simple and my models clean.

it can be super long

it can be super long

it can be super long

v

v

<iframe width="420" height="315" src="http://www.youtube.com/embed/IytNBm8WA1c" frameborder="0" allowfullscreen></iframe>

it can be super long

it can be super longit can be super long

it can be super long

it can be super long

it can be super long

it can be super long

it can be super long