Week 6 Day 2: Stack Too Deep

Major Activities of the Day: Today we started by creating a virtual Tower of Hanoi solver.  (It's too complicated for me to explain here, but you can click the link to see Wikipedia's description.)  I wasn't really sure how to begin, and then Daniel Kronovet explained to me the algorithm (which is on Wikipedia): essentially, if I have a large stack on Peg A, move all but one over to Peg B, move the bottom one to Peg C, and then move everything from B to C.  This can further be broken down one level up, where you're moving all but the bottom two to Peg C, moving the second-to-bottom to Peg B, and then move the rest from Peg C to Peg B.  You keep breaking this down further and further until there's only one peg.  So here's my recursive solution (from, to, and via are Pegs A, C, and B, respectively):

def move_disk(num_disks, from, to, via)

  return [] if num_disks == 0

  move_disk(num_disks - 1, from, via, to)

  to.unshift(from.shift)

  move_disk(num_disks - 1, via, to, from)

  to

end

I handle the edge case first - if there are no disks to move, return an empty array.  (It shouldn't need to return any value at all, just returning should be enough, but this handles a case where the original method call sent in an empty "from" array.  Afterwards, the method does exactly what we said: move any disks above it to the "via" array, then move the bottom disk to the "to" array, and finally move the remaining disks to the "to" array above the bottom disk.  Finally, the method returns "to" so the original method call will ultimately receive the "to" stack.

I really like this computer science-y stuff.  It's just a matter of understanding the logic, whereas frameworks that depend on just knowing a lot of stuff are much more of a challenge for me.  That's probably why I've focused more on programming than on web stuff in these blog posts.

After our ToH experience, we moved on to a lecture about forms in Rails... well, actually we were supposed to, but didn't, because there were some really interesting student blog posts, and Avi decided to go deep into the topics they covered.  So instead, we did that until lunch, and then had some time to work on things, study, catch up on homework, etc., until 2.  At 2:00, we heard a lecture from Dinshaw Gobhai about DevOps and the idea of breaking down the wall between Dev and Ops, so everyone is a little bit of both.

After the lecture, we had a brief break, and then, finally, the long-awaited Rails forms lecture!  Essentially, there are three ways to make a form in Rails:
1) Write all the HTML yourself, with maybe a little bit of ERB inserted to add CSRF tokens and an action or method.
2) Use form_tag helpers, which generate forms bit by bit, writing the HTML for you and still keeping things a bit DRYer (e.g., no need to write both an ID and a name), and dynamically inserting some information for you instead of having to stick ERB in the middle of a name attribute.
3) Use form_for helpers, which basically write the whole form for you, as long as you pass in an object you are writing the form for.  (If updating, it will be an object that already exists; if creating, it will be a new object with blank attributes.)  You still have to write a line for every attribute you are prompting the user to add, but it's pretty concise, when compared with option 1, and even option 2.

There are lots of ways to write forms, because sometimes you want something more standard, but other times you want a more customized form.  When you want to customize, you can often do it by adding lots of customization in the form of hashes at the level you're on, but it can be easier (to write, and to read your code later) if you just drop down a level, doing more work, but in a way that naturally gives you more options.

Homework was putting together a todo list in Rails.  Honestly, I worked at it for quite a while, but it was too difficult for me, so I'm waiting until I learn more to give it another try.

Skills developed: Recursion, Rails forms