Permalink
Commits on Dec 7, 2011
  1. Beefing up README.

    Okay, now that we're done, let's make sure we have some good documentation.
    committed Dec 6, 2011
  2. small style changes

    I like to use ' instead of " wherever possible, and not use () unless
    it's required.
    committed Dec 6, 2011
  3. reworking requires.

    There's no reason to require everything up front. With this, each file
    requires the things it needs. If we were *cough* writing tests, this
    would make each file testable on its own.
    committed Dec 6, 2011
  4. Various renaming and extractions.

    This is just a bunch of little extract methods, renamings, etc.
    Nothing complicated.
    committed Dec 6, 2011
  5. rename total_steps

    We refer to it as total_steps outside of the class, and steps inside.
    Let's make that more consistent.
    committed Dec 6, 2011
  6. Move Solver into its own file, simplify loop.

    Two things: I moved the solver out into its own file. Self-explanatory.
    Secondly, a loop with only one statemnt is better written in one line.
    committed Dec 6, 2011
  7. Extract Solver object.

    The contents come from about 90% of the loop. Which makes sense, our
    solver should decide what to do with the maze.
    committed Dec 6, 2011
  8. README -> Markdown

    Before, it was just some text. Now we introduce a tiny bit of
    Markdown so it shows up nicer on GitHub.
    committed Dec 6, 2011
  9. Breaking up into files.

    This is almost a real project or something. Lots of little files to go
    with lots of little classes.
    committed Dec 6, 2011
  10. Cleanup and rename various things.

    Okay! These classes are pretty solid. Basically, this commit renames
    some methods, classes, whatever. No major changes. The most complicated
    bit is using Forwardable to make the Request class a bit nicer.
    committed Dec 6, 2011
  11. Simple instance variable caching.

    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.
    committed Dec 6, 2011
  12. Extracting XML from xml_*

    This is pretty straightforward, after looking at the last commit. We
    just move all of the methods that started with xml into a class.
    
    After all, xml_foo(xml) is really just xml.foo in disguise...
    committed Dec 6, 2011
  13. Normalizing names of xml_* methods

    One of the things I like to do before extracting a class is make the
    names all the same. This makes it easier to extract.
    committed Dec 6, 2011
  14. Extract Request class.

    Really, requesting stuff from net::http has nothing else to do with
    anything else, so we'll sequester it off into its own deal-e-o.
    committed Dec 6, 2011
  15. 'curry' the xml

    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.
    committed Dec 6, 2011
  16. making current_xml lazily loaded

    We really only change current_xml when we change URI. We just want the
    xml to match the current URI anyway, so why not just lazily load it?
    committed Dec 6, 2011
  17. Hiding current_xml.

    There's no reason to expose this, and we weren't even using it outside
    of the Room.
    committed Dec 6, 2011
  18. Moving top-level methods inside of Room.

    Top level methods are icky. Besides, they should really be helping the
    Room do its job, anyway. Notice how the main logic is a bit more clear
    now, with the can_go? and finished? methods.
    committed Dec 6, 2011
  19. Extract a simple maze class.

    This doesn't do a whole lot yet. But it does give me an object to
    handle the current state, as well as actually performing the transition
    between states.
    committed Dec 6, 2011
  20. Implement automated solver.

    We go from an 'choose your own adventure' style to an automatic
    solver.
    
    And let's make some comments, show them an example of what we're
    doing and why. Always like to link to the definition of the type I'm
    working with, makes it a lot easier.
    committed Dec 6, 2011
  21. Adding winning message.

    What kind of game doesn't congratulate you when you win?
    committed Dec 7, 2011
  22. Leaving!

    This time, since it really goes inside that loop, I built it as a
    method from the beginning. Most of the implementation is the same as
    extract_href_from_xml. Sweet.
    committed Dec 7, 2011
  23. Accepting input for the game.

    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...
    committed Dec 7, 2011
  24. Extracting directions.

    Since these are the exact same, I did them all at the same time too.
    
    Now we print out which directions we can go in in the current room. You
    gotta hit control-c to break out, and you don't go anywhere. Whatever.
    committed Dec 7, 2011
  25. Wrap up that href extraction.

    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.
    committed Dec 7, 2011
  26. Fetch start of maze.

    First thing we need to do is grab the @start link. We'll use nokogiri
    to parse that out. Pretty simple.
    committed Dec 7, 2011
  27. Wrapping up Net::HTTP.

    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.
    committed Dec 7, 2011
  28. Requesting XML with Net::HTTP.

    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.
    committed Dec 7, 2011
  29. Adding dotfiles.

    I often like to start out a project with a .gitignore and a .rvmrc.
    Documenting which Ruby you're using is a good start, and I hate
    accidentally adding vim's swapfiles into my repos.
    committed Dec 7, 2011
  30. initial commit

    committed Dec 7, 2011