The problem with the last commit is that we ended up making a LOT MORE requests than we should have, due to making excessive XML objects. Then inside of the XML object, we referred to the virtual attribute that makes a Request multiple times. Ack! Now we don't do that any more. Note that HTTP caching would be the 'right' thing to do here. I don't want to get into that yet, so we're just using instance variables.
Now that we only ever use it as a parameter, we can actually remove it as a parameter and put it directly into our xml methods. This is a reference to curried functions in Haskell: add :: Integer -> Integer -> Integer add x y = x + y add_five = add 5 add_five is a 'curried' version of foo. You can do this in Ruby too, but it's so much more elegant in Haskell.
Doing this kind of dispatch feels ugly, but since the end goal is automated maze solving, I'm doing it anyway. Also, exit revealed something quite interesting. Can't name a variable 'exit', or else it quits Ruby. hahahaha! Oh, and you can't actually exit yet. Guess what I'm doing next...
My Ruby style tends to be of the 'zillions of tiny methods' variety. So I wrap up _everything_ as methods, even if I'll only use them once, for clarity. This time I did two at once, because I'm impatient and one of them is only two lines. I got lucky... Developing software is all about discipline. You don't _have_ to follow best practices, but it's always those times that come back to bite you in the end.
Now that I have that working, I want to make a method that I can use. I take these steps really slow, _especially_ since I'm being bad and doing this without tests. It's just exploratory programming... Everyone says that in their first few commits, anyway.
First off, I wanted to figure out how the hell to use Net::HTTP. It never fails, I always forget. I did a google search for 'request headers net::http ruby' and came up with the documentation, which had an example I modified to get this. If you run it, you can see the initial maze XML come back. Awesome.