-
31
DEC
2014Game Programming Patterns
I meet a lot of programmers that tell me they got started because they wanted to build games. However, when I ask most of them which games they have built, the list rarely includes anything more than mostly unplayable toy projects.
I can only guess at the reasons for this oddity, but I suspect it might be due to the fact that games are fairly complex. Even if you want to rebuild a fairly simple classic like Space Invaders or Snake you need to know at least a little about event loops, keyboard handling, animation, and collision detection. If your day job involves a different kind of programming, like Web application development, odds are good that you don't get a lot of practice with these concepts.
That may not be your story, but it was definitely mine. This year I decided that it was finally time to learn how to build games. I used several sources to gain this knowledge and some helped more than others, but the biggest win by far was a book called Game Programming Patterns by Bob Nystrom.
-
21
AUG
2014Guard Clauses, Rust Style
When I'm programming in Ruby, I will often use guard clauses to prevent undesirable scenarios. For example, let's say I'm building a simple
Stack:class Stack def initialize @numbers = [ ] end def push(number) @numbers.push(number) end def peek fail "Stack underflow" if @numbers.empty? @numbers.last end end stack = Stack.new ARGV.each do |number| stack.push(number.to_f) end p stack.peek
If I only want to work with numbers everywhere, I add a line like the call to
fail()above. This prevents anilfrom being returned frompeek(), ruining my expectation that I will have numbers everywhere.When I first started playing with Rust, I wanted to write code the same way:
use std::os; struct Stack { numbers: Vec<f64> } impl Stack { fn new() -> Stack { Stack{numbers: vec![]} } fn push(&mut self, number: f64) { self.numbers.push(number); } fn peek(&self) -> f64 { if self.numbers.is_empty() { fail!("Stack underflow"); } self.numbers.last() } } fn main() { let mut stack = Stack::new(); for number in os::args().tail().iter() { stack.push(from_str(number.as_slice()).expect("Not a number")); } println!("{}", stack.peek()); }
-
21
MAY
2012Decorators Verses the Mix-in
It is a neat time to be involved in the Ruby community, if you ask me. A large portion of us are currently studying the techniques for doing good object oriented development. We are looking at the ideas that have come before and trying to decide the best ways to apply those ideas to our favorite language. This leads to blog posts, forum threads, and conference talks about what we are learning. No matter what, we all gain from explorations like this. Everybody wins as our collective knowledge grows. We all deserve gold stars.
So far, there's one point pretty much everyone agrees on: composition should typically be preferred to inheritance. The trickier part of that discussion though is deciding what composition looks like in Ruby. Generally you see Rubyists comparing the merits of decorators and mix-ins. [Note: the comments correctly pointed out that this was a bad use of the word "composition" on my part, to describe mix-ins.] There's a very representative thread on the excellent Objects on Rails mailing list.
-
21
JAN
2012Iteration Patterns
I love studying how the human brain works. It's an amazing biological machine capable of impressive feats. Of course, it also has its quirks.
For example, the brain is a terrific pattern matcher. That's probably one of its favorite activities. It wants to do this so much that it will often even find patterns that aren't there.
While this "feature" of your brain can get you into trouble, you can also make it work for you. Some parts of programming really are about patterns. If you prime your brain with the right data, it will just take over and do one of the things it does best.
How I Teach Iterators
One evening, at a post Ruby conference dinner, Glenn Vanderburg and I had a lengthy discussion about iterators and patterns. During this discussion we nailed down a plan for how the iterators could be taught.
I know that we've both used the strategy we came up with in multiple Ruby trainings and we have both seen it work wonders. This is hands down the best way to learn the iterators, in my opinion.
-
1
MAR
2008Design Patterns in Ruby
I've been lucky enough to read a string of good Ruby books lately and the latest in that line is Design Patterns in Ruby. This book attempts to modernize the software design patterns by showing how these patterns can be applied in a language as dynamic as Ruby. Despite a couple of minor missteps along the way, the book definitely delivers on this goal.
Design Patterns in Ruby begins with a couple of introductory chapters introducing both the concepts behind reusable software patterns and the Ruby programming language. After that, the main section of the book has 13 chapters that walk through 14 of the patterns first introduced in the famous "Gang of Four" book that began the design patterns movement. The author then introduces three new patterns he feels have grown out of day to day Ruby usage. Finally the book closes with a short conclusion and two appendices on installing Ruby and other sources of information.
Most of that content is exactly what I wanted to find in this book, but you're going to have to tolerate a diversion about a pet peeve of mine that is strangely common in Ruby books. This is really, really important, so listen up: you can't teach Ruby in 30 pages. Period. I can hear all on the "But…" replies forming out there now… No buts. You can't. Trust me. Not even if the person is already an experienced programmer. It just can't be done. Authors and publishers need to come to terms with that and move on. Its just fine to say, "This is not a beginning Ruby book." We even prefer that, because we know when we are ready to read it and we don't have to skip that useless 30 page chapter when we do. Please, stop including introductory Ruby chapters in every book.
