Friday, July 20, 2012

Old stuff dug up.

This is old, I just found it sitting in my drafts from a couple years back. I believe I was writing a tutorial on how to do this in ActionScript 3, but I'm to old to remember that far back now... :(

Anyhow, it was a world of warcraft inspired character inventory/backpack system in flash.



And the pieces:





Ruby/RSpec Callback Argument Capture

Yesterday I had been poking around trying to get a parameter passed into something I was stubbing out in Ruby & RSpec. Like I had mentioned before in .net with rhinomocks, moq or similar mocking frameworks I would do something of the sort:

var repository = Mocks.Get();
repository
  .Stub(r => r.Save(null))
  .Callback((Player entity) =>
  {
    _player = entity;
    return true;
  });

Due to terminology differences, unfamiliarity with Ruby and my shifting understanding of testing; I was having trouble figuring out how to do that. After a bit of searching and experimenting I pieced together what I needed to do as so:

board = nil
@game_runner.stub(:draw) do |arg|
  board = arg
end

And then as the design changed as I continued testing, it was no longer needed. It was good to poke around it and figure it out, funny that it didn't survive more than an hour or so in my code.

Monday, July 16, 2012

My game asset share

I was digging through some of my files the other day and I ran across my 2d game/site assets. I generally end up offering my artwork to co-workers and friends when they show an interest in it. Now that I have a good place to actually share my work, I figured it wouldn't hurt to throw the work up there also.

Keep it clean, and have fun. :)

Game Assets Share

Game Assets Share

Monday, July 9, 2012

Extreme Programming Explained: Embrace Change, by Kent Beck with Cynthia Andres

The second book in the stack 8th Light has given me, Extreme Programming Explained: Embrace Change, wasn't what I was expecting it to be. Normally when I hear about XP, it's some eccentric way those new-age developers do things. Not something a real business can afford the luxury of. So going into the book, I was expecting some crazy, wacked out things like; the Batman programming technique is practiced by spends exactly 13 minutes everyday coding... while hanging upside down.

Turns out, nothing of the sort. The book just lists a bunch of really good ideas; test-first, automated tests, continuos integration, quick feedback, caring about quality, sitting with your teammates, communication focus, and so on. You know, the stuff that is really good for a development team and the business.

One of my previous employers practiced much of what the book covers, and oddly enough hadn't told me it was XP. My last employer ran from the word, cursing it to die. However they loved the idea of the individual concepts that I tried to push on them. It's odd how so many use good terms for their buzz and never really understand them.

So, what is XP?

Besides being a refresher for me, the book really took care to explain and relate amongst itself the various aspects of XP. I've seen most of the ideas in practice here and there, utilizing many myself. They really aren't anything that would be considered out of the norm for most teams that aren't afraid to keep up with the times. But the bigger picture that I was missing is how they feed into each other, making each more effective.

Sitting together in an open room wasn't just about creating a more friendly environment, it was also about building better communication. Communication wasn't just about better understanding, it was also about building the clients trust. Planning for and working short development cycles wasn't just about getting quick feedback, it was also about getting the entire company to shift their way of thinking. Testing wasn't just about confirming bug fixes and elevating fear, it was also the stepping stone towards building what the client needs in this cycle. Automated tests weren't just for one button test runs, continuos integration wasn't just to keep us from having to clicking publish; they were to reduce our stress levels, so we could code more clearly. Which I do decree; I will take to heart any practice that purpose it is, to reduce stress.

XP: Extreme Process

Another aspect of the book that jumped out at me was the care it took to reinforce that you don't have to be a programmer to be able to utilize XP. Quickly the book begins to tie in the practices of XP to the other aspects of a company. The practices build trust with the clients, the team, the employers. While improving the process and elevate pain for the other departments, the development team and all of the individuals involved. By tying the practices so closely to the other groups of people involved, you begin to affect how they work. All of a sudden clients, managers, executives, all have their role to play to make XP really work.

Embrace Change

In the end, utilizing one of these practices, a few, or all; doesn't become the focus of what XP is about. Its the change in the mind set. The breaking apart inefficient or down right bad development practices. Its about moving yourself, your team and your environment in a better direction.