• Retris screen cast (large version)
• Github repo: http://github.com/angryrabbit/retris/tree/master
• gosu library

There are quite a few missing features, but it’s playable. There are probably a small handful of bugs. I’m only aware of one or two. Both are documented in the readme.

I want to thank Julian Raschke and the other gosu contributors. I love Ruby and it’s awesome to be able to concentrate on my game rather than dick around with low-level details.

As happy as I am that I’ve “finally made a game”, I have to confess, I don’t care for Tetris. I suck at it, too. I wrote it because I read in an old game programming book that Tetris is a good first game.

So what’s next? Well, I have a few things I want to finish up. As Diana Gruber says, “the last 10% of the game takes as long as the first 90%”. Or something like that.

At the very least I need to instate loss conditions. Currently, overflowing the grid simply causes the game to go on a freak rampage, creating shape after shape in the grid’s origin. It doesn’t crash, but you can’t do anything but exit when you reach that point.

I’d also like to put in a menu, pause feature, difficulty levels and a menu.

When those things are done I’ll start to think about another game.

I’d like to point out that I ditched the idea of using a matrix (nested arrays, actually) to model either the grid or shape objects. I made this move for several reasons:

• Nested arrays require some math
• I can’t ask a nested array meaningful questions
• Previous attempts at using nested arrays fell short for me
• It doesn’t feel very object oriented

There’s no doubt in my mind nested arrays are a viable implementation to Tetris, but personally, I prefer objects.

True, I could have wrapped the nested arrays into an object and queried that, but it’s just not decomposed enough for my tastes. My landscape (objectscape?) includes Grid, GridLocation, Cursor, Shape, Location and Block objects to orchestrate the interactions required of Tetris. (There are a few more objects, but the ones I listed are my solution to NOT using nested arrays.)

Similar to my object-oriented solution to the Tower of Hanoi, (portions of) my code read like a story. Stories are easier to grasp than mathematics. At least for now they are. I’ve decided to go back to school primarily for math.

I imagine though, that even as I become more proficient with math, the “stage” my code lives in, and the messages passed back and forth, will remain largely true to my current style.

In fact, if object-oriented programming is really all it’s cracked up to be, my style will only get tighter and more nuanced; only the implementations will change.

Five years from now I just might use an (actual!) matrix object to handle the implementation for Tetris interactions. But, my guess (indeed, my hope) is that the act of sending messages to create a story will remain in force.

Here’s to the human mind.

One of the chief detriments of the so-called “information revolution” is the nature of information delivery: we get “factoids” — dismembered fragments of data delivered in such great numbers at so great a speed that developing the context and critical thinking necessary for real comprehension is, in most peoples’ cases, obviated. This easily places media like television and the internet almost by default at the service of prevailing establishment power. All that needs be done is to keep bombarding the populace with byte-sized disconnected chunks of emotionally resonant information which, given this dislocation from any corresponding or conflicting data and from any grounded theory of historic process, debases the very essential question of “how are we to live” to the point that such a question is little more than hollow entertainment. Fewer and fewer of us, struggling to keep body and soul together, have the time, energy, or inclination to develop the patience and epistemological grounding requisite to taking a well-reasoned, humane and ethical orientation to the constantly streaming flood of factoids which create in our minds “the world.”

It is essential that any well-intentioned vision of alternative futures not replace or sap a persistent effort to perceive, oppose and deconstruct the immoral, inhumane establishment structure of power and ideology. Until we are agreed on a clear and well-detailed picture of what we hope to change, to “envision alternate futures” is all too often just time and energy stolen from the liberation and transformation we pay lip service to and, through that distraction, perpetuation of the cruelties and injustices we all hope to remedy.

Here two opposing viewpoints:

Viewpoint 1:

Actually I can… we live on finite planet with finite resources. We
now have over 6.6 billion people here. The more people on the earth,
the smaller the resource pie becomes, especially when non- renewable
resources are starting to decline.

What an interesting time to be alive.

Viewpoint 2:

So you say we live on a finite planet with finite resources? Billions
of watts of power fall on our planet from an outside source every day.

If anything, it’s the zero-sum, finite-resource type of thinking tht’s
going to get us into trouble. Don’t fight over the pie, bake new
ones…

Given the dichotomy between viewpoint 1 and 2, I say the root problem is, as I’ve said before, fear.

Fear that if you don’t, someone else will; and the person that does will not be kind towards you.

I’m glad I was given the opportunity to see it firsthand, but I’m disheartened that it was there to see in the first place.

An entity claiming responsibility for all happenings that lacks the resources, expertise or motivation to actually act responsibly is not an entity that should exist. Doing otherwise sounds like a narcissistic god delusion to me. Proponents of god, like those of big government, claim their benevolent dictator can do more that it can.

The government (state-level government, I’m assuming here) dipped its creeping fingers into something it didn’t understand, or, more likely, didn’t care to understand. The result is a free iPhone, some nice code, decent designs and another nail in the coffin of the “land of the free and the home of the brave”.

Free indeed.

After a few minutes he stands up. I know to turn down the music. He whispers into my ear. I nod in agreement and mouth back a response.

Flow understands my frustration with testing individual methods outside any greater context or usage scenario.

RSpec is a beautiful tool. Leaps and bounds ahead of the standard testing framework built into Rails. It does this, I believe, by allowing you to use more natural language. But it can be be misused. Which is actually closer to abuse, because unless you’re paying respect to flow, you’re fucking yourself.

Don’t test methods outside of the context in which they should be used. It doesn’t mean shit to the person reading your code — even if that person is you.

Your program is a play. Your objects are actors. You are the writer and director. You say action! You say cut! You know all the lines, but it’s not your job to voice them. You assign those roles to your actors, and they carry it out much better than your sorry ass ever could.

Context. Acknowledge it. If your tests look like this:

describe 'An InterestList' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'upon creation' do
 
    it 'should not be a new record'
    it 'should be empty'
    it 'should report having zero Interest objects'
 
  end
 
  describe 'when adding a ProductInventoryPrototype' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
    end
 
    it 'should answer true'
 
  end
 
  describe 'with one ProductInventoryPrototype in it' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
      @interest_list.add(@cheese)
    end
 
    it 'should not be empty'
    it 'should report having one interest'
 
  end
 
  describe 'removing a ProductInventoryPrototype' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
      @interest_list.add(@cheese)
    end
 
    it 'should answer with the item when that item is removed'
 
  end
 
  describe 'after removing a ProductInventoryPrototype' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
      @interest_list.add(@cheese)
      @interest_list.remove(@cheese)
    end
 
    it 'should be empty when that item is removed'
    it 'should report having zero items'
 
  end
 
end

You’re fucking with the laws of nature, and you will be smitten.

What’s wrong with it? The

#before

code is reinitializing all the steps you’ve just accomplished.

Make it look like this.

describe 'When working with an InterestList,' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'it must first be created.' do
 
    it 'It should not be a new record.'
    it 'It should be empty.'
    it 'It should report having zero Interest objects.'
 
    describe ' After which you can add a product.' do
 
      before(:each) do
        @cheese = inventory_prototypes(:cheese)
      end
 
      it 'To which it should answer true.'
 
      describe 'It now has one product in it.' do
 
        before(:each) do
          @interest_list.add(@cheese)
        end
 
        it 'It should not be empty.'
        it 'It should report having one interest.'
 
        describe 'Now we remove a ProductInventoryPrototype.' do
 
          it 'It should answer with the item when that item is removed.'
 
          describe 'After removing a ProductInventoryPrototype,' do
 
            before(:each) do
              @interest_list.remove(@cheese)
            end
 
            it 'it should be empty when that item is removed.'
            it 'it should report having zero items'
 
          end
 
        end
 
      end
 
    end
 
  end
 
end

Of primary importance is a subtle point. I didn’t illustrate it in the two examples above, but I will now:

Before:

describe 'When working with an InterestList,' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'it must first be created.' do
 
    it 'It should not be a new record.'
    it 'It should be empty.'
    it 'It should report having zero Interest objects.'
 
    describe ' After which you can add a product.' do
 
      before(:each) do
        @cheese = inventory_prototypes(:cheese)
      end
 
      it 'To which it should answer true.'
      it 'It should not be empty.'
      it 'It should report having one interest.'
...

After:

describe 'When working with an InterestList,' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'it must first be created.' do
 
    it 'It should not be a new record.'
    it 'It should be empty.'
    it 'It should report having zero Interest objects.'
 
    describe ' After which you can add a product.' do
 
      before(:each) do
        @cheese = inventory_prototypes(:cheese)
      end
 
      it 'To which it should answer true.'
 
      describe ' At which point' do
 
        it 'it should not be empty.'
        it 'it should report having one interest.'
...

On the surface it’s just another level of nesting. After meditation, you realize you are first testing the object’s answer to your message. Second, you are testing the state of the universe after that action is made. The difference is subtle, but important. If you don’t understand the importance, recall the indifference you felt when you first saw RSpec: it’s Rails’ standard test framework with different words thrown in.

You were wrong then and you’re wrong now.

Words offer the means to meaning, and for those who will listen, the enunciation of truth. - V

If an object’s answer to the message passed violates expectations, flow stops. You know, not that a method is broken, but that flow is broken.

Of secondary importance is that your

#before

methods are no longer redundant.

The result of running your tests now looks like:

When working with an InterestList, it must first be created. It should not be a new record. (Not Yet Implemented)
When working with an InterestList, it must first be created. It should be empty. (Not Yet Implemented)
When working with an InterestList, it must first be created. It should report having zero Interest objects. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. To which it should answer true. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. It should not be empty. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. It should report having one interest. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. Now we remove a ProductInventoryPrototype. It should answer with the item when that item is removed. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. Now we remove a ProductInventoryPrototype. After removing a ProductInventoryPrototype, it should be empty when that item is removed. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. Now we remove a ProductInventoryPrototype. After removing a ProductInventoryPrototype, it should report having zero items (Not Yet Implemented)

This is easier to read and understand than a series of isolated tests. You’re made aware of the context in which each test is being run, which is priceless when you’re attempting to understand the system from a high level.

Congratulations. You are no longer a moron coding outside the realm of the context in which your code lives.

def initialze(attributes)
  @attributes = attributes
  load_xml_request
end

Since you SPELLED IT WRONG! :)

I have a very urgent asp.net project that I need done by Tuesday.

I want it to be designed using 3 tier model

1- Data Access Layer ‘DAL’. I want to use subsonic for that. Also stored procedures. Did you work with subsonic?

2- Business Logic Layer ‘BLL’

3- User interface ‘UI’ (The UI has 5 pages)

I need very high OO code quaity. I am a programmer myself and I will review the code.

Also, the database is MS SQL 2005.

Let me know asap if you can do it and I will forward the specs to you.

Thanks

The kittens are crying.

class Array
 
  def roll
    loop { each { |e| yield(e) } }
  end
 
end

>> a = [ 'a', 'b', 'c' ]
=> ["a", "b", "c"]
>> a.roll { |e| puts e; sleep 1 }
a
b
c
a
b
c
a
...