Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Branch: master
Commits on Dec 7, 2011
  1. Beefing up README.

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

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

    authored
    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.
  4. Various renaming and extractions.

    authored
    This is just a bunch of little extract methods, renamings, etc.
    Nothing complicated.
  5. rename total_steps

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

    authored
    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.
  7. Extract Solver object.

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

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

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

    authored
    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.
  11. Simple instance variable caching.

    authored
    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.
  12. Extracting XML from xml_*

    authored
    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...
  13. Normalizing names of xml_* methods

    authored
    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.
  14. Extract Request class.

    authored
    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.
  15. 'curry' the xml

    authored
    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.
  16. making current_xml lazily loaded

    authored
    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?
  17. Hiding current_xml.

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

    authored
    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.
  19. Extract a simple maze class.

    authored
    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.
  20. Implement automated solver.

    authored
    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.
  21. Adding winning message.

    authored
    What kind of game doesn't congratulate you when you win?
  22. Leaving!

    authored
    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.
  23. Accepting input for the game.

    authored
    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...
  24. Extracting directions.

    authored
    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.
  25. Wrap up that href extraction.

    authored
    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.
  26. Fetch start of maze.

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

    authored
    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.
  28. Requesting XML with Net::HTTP.

    authored
    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.
  29. Adding dotfiles.

    authored
    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.
  30. initial commit

    authored
Something went wrong with that request. Please try again.