In an old post I talked about doing collision detection using a 2d bitmap (or grid). That example was done using Processing (Java). It was a simple example but was very relevant to all the problems I had when building Tatris which did not use a bitmap for player position, instead it used real 2d space of x,y.

I didn’t talk about it in the previous post but I had added an Observer to the Java code that would highlight blocks in green when a collision was detected. Unfortunately, the code is a bit unclean although it works. I have a few global variables (common in Processing sketches) and some unused variables. So I never posted it.

Fast-forward to today and I have been playing around with ruby-processing (rp5) and porting some of my sketches. The code is not much smaller (300ish lines of Java, 265 lines of Ruby) but I didn’t optimize either code for line numbers. Neither code is really easier to read. This might be because I straight-up ported the code with only minor changes. Even if I were to do this from scratch, I’m not sure I could make it more ruby-like. Where I use arrays for x,y, I’m sure I could do something cooler like ruby Hashes, but a lot of the code is bound to JRuby and the Processing API so it ends up reading about the same.
(more…)

Git changed the way I code singularly because of how branching works. Hopefully you have at least tried branching out in Git. Even if you have, you might still be doing the old SVN ways of never merging. If you do merge, chances are you’ve had a conflict. I have had only really bad experience with conflicts when something is majorly wrong with my repo. For the most part, Git does everything automatically and is really smart about it.

But sometimes, Git doesn’t know what’s going on because too many changes have happened. No fault of Git but sometimes it has cost me some time when I’m either doing too many things at once or did something wrong. As far as actually defining what I do and in what order (workflow), it’s not really relevant because I usually work on one feature branch at one time. In a team environment (which I haven’t really done), I’d say this looks pretty good.

Regardless, we’re going to play around with conflicts and show a sample workflow with branching. First, go into some directory you don’t care about and create a project:

cd /tmp
mkdir test_conflict
cd test_conflict

Create some “code”.

echo -e "This code computes PI and is released." > code.txt
 
git init
Initialized empty Git repository in /tmp/test_conflict/.git/
git add code.txt
git commit -a -m "initial commit"
[master (root-commit) e7007ea] initial commit
 1 files changed, 4 insertions(+), 0 deletions(-)

(more…)

Sometimes when I’m fumbling around in irb on an API I don’t know, or with Active Record queries, I get an Enumerator object back when I don’t want to. So if I save this Enumerator as a variable, what the heck do I do with it? And why do I get an Enumerator anyway?

So what we’ll do is play around with a hash of elements. Elements have a name, color and what happens when you touch them attributes. We’ll iterate through them and print out the values as normal but we’ll also store the Enumerator by itself and iterate through it later.

# enumerator test
# ie: why the ---- do i get an enumerable back when I'm cluelessly hacking?
 
elements = [
  { :name => "earth",   :color => "brown",  :touch => "I'm dirty." },
  { :name => "wind",    :color => "white",  :touch => "I'm flying." },
  { :name => "fire",    :color => "red",    :touch => "I'm on fire!" },
  { :name => "water",   :color => "blue",   :touch => "I'm wet." },
  { :name => "ice",     :color => "blue",   :touch => "Brr!"}
]
 
# Here is the wtf moment.  What are we supposed to do with an Enumerator?!
puts "What do you use a Ruby enumerator for?"
puts elements.find
 
# Fix it you dummy, you didn't pass in a block.
puts "\nYou don't get an enumerator if you pass a block in:"
puts elements.find{|e| e[:name] == "wind"}
 
# ok so ruby devs aren't dumb, wtf is enumerable
enum = elements.each
 
color_enum = enum.collect { |e| e[:touch] }
puts "\nDelayed enum search: "
puts color_enum.collect { |c| c }.join(", ")
 
puts "\nStandard collect with no enumerator: "
puts elements.collect{|e| e[:color]}.join(",")
# => ["brown", "white", "red", "blue", "blue"]
 
map = elements.collect {|e| {e[:name].to_sym => e[:color]} }
# [{:earth=>"brown"}, {:wind=>"white"}, {:fire=>"red"}, {:water=>"blue"}, {:ice=>"blue"}]
# No!  This is an array of hashes.  Not what we want.
 
h = {}
elements.each {|e| k=e[:name]; v=e[:color]; h[k]=v}
# {"earth"=>"brown", "wind"=>"white", "fire"=>"red", "water"=>"blue", "ice"=>"blue"}
# YES!  One hash, one deep.  Perfect.
 
puts "\nNice hash associating element to color: "
puts h

(more…)

Background

I’ve always wondered how I’d go about publishing a real REST API on the web to do something. In this example, we’ll create an employee manager app-thing. It’s not particularly interesting but it shows what “API” means. In another bit, we’ll create an “API” meaning a library to interact with this web service.

The rails app

First, create a new rails app.
rails new rest_api

Edit config/database.yml:

  # MySQL
  #   gem install mysql2
  development:
    adapter: mysql2
    host: localhost
    database: rest_api
    username: rest_api
    password: rest_api
    pool: 5
    timeout: 5000

(more…)