Lately I’ve been writing a TON of tests using RSpec and Capybara. The syntax keeps slipping my mind so here’s a cheat sheet I keep coming back to…
Lately I’ve been writing a TON of tests using RSpec and Capybara. The syntax keeps slipping my mind so here’s a cheat sheet I keep coming back to…
Today at AppAcademy we have gone through almost all of Michael Hartl’s rails tutorial. I just wanted to quote Hartl explanation of what a database index is and how it works. I love the analogy because it’s probably the most simplistic examples I’ve probably ever seen:
Putting an index on the email column fixes the problem. To understand a database index, it’s helpful to consider the analogy of a book index. In a book, to find all the occurrences of a given string, say “foobar”, you would have to scan each page for “foobar”. With a book index, on the other hand, you can just look up “foobar” in the index to see all the pages containing “foobar”. A database index works essentially the same way.
Bam!
First off, I stole this pic from Greg Pike’s post about Javascript. Now that the confession is out of the way…
Today at App Academy my pair and I were asked to explain the meaning of Ruby’s “double pipe equals” operator to our cohorts. I figured that might be a good topic to post here.
The double pipe equals, which will be referred to as “||=” from now on, is an operator that’s used for conditional assignment.
In a nutshell the||= operator’s usage is something like this:
blah ||= blabbity_blah()
This essentially says: “if blah is false then set it to blabbity_blah(), otherwise leave it set to whatever it was before we started”
Here’s a contrived, but-still-real-code, example lifted (and modified) from Wikibooks:
Here’s a cool chain of info nuggets that starts @ Renè Descartes and ends @ Ruby’s Array.product, lol.
Renè Descartes was a French philosopher and mathematician born in 1596.
He’s known for lots of things but one of the most popular is the following quote from a passage in his publication Discourse on Method (1637):
“I think, therefore I am” (or the corrected version “I am thinking, therefore I exist“)
Renè Descartes developed “analytic geometry”, an algebraic description of geometry. A pair of numbers can represent a specific coordinate on a plane or graph. Sets of coordinates can be represented on a graph as well… and this gets us closer to the end of this nugget chain…
“Analytic geometry” is also known as “Cartesian geometry”… with the name stemming from Descartes’ own name. In the Cartesian view, when given a plane (think … graph), any point on the plane can be represented by coordinates — in a 2 dimensional plane these might be X and Y, in a 3 dimensional space this might be something like X, Y and Z.
A cartesian product is the result of taking two sets and returning all permutations of their combined results. So for example, if you had a set of numbers named X that contained: “1,2,3” and a set of numbers called Y that contained “-5,-6,-7”, their cartesian product would be:
[1, -5], [1, -6], [1, -7], [2, -5], [2, -6], [2, -7], [3, -5], [3, -6], [3, -7]
And finally getting back to Ruby…. this is where Array.product gets it’s name!
Array.product is awesome and will get you the Cartesian product for a given array against a number of other arrays!
/fin
Ruby provides 3 ways of classifying a methods in a Class: Public, Private and Protected. These keywords are used to declare a method’s visibility and essentially what you’re doing is restricting access to the individual methods contained in your class.
Here’s a quick and dirty about the differences:
Public
These methods are accessible by anyone who calls your class. They define your class’s public “interface”.
Protected
Protected methods are accessible by objects of the same class. By this definition, a good use case is when classes extend your class and want to access those methods. The subclass will retain access into the super class’s protected methods.
Private
Private methods can mask the gory details of how the public/protected take input and generate output. One way to look at this is that these methods are essentially for the “author of the object/class”. And by “author” I do mean the guy who wrote the code. Because private methods are not publicly exposed — aka someone who calls your class doesn’t have access to them — private can be considered free for refactoring, changing and deletion without worrying that your outside callers are going to have problems.
Here’s a cool trick for dealing with situations where you want to assign multiple values at the same time.
The technique used is called parallel assignment and it looks something like this:
If you’re working with game boards, this is super useful way to pass around board coordinates!!
If anyone actually reads this, here’s an unusual circumstance to look out for… circular object references that cause Pry to go BSC.
(For those who don’t know, Pry is a Ruby shell that can be used as a replacement for the default Ruby shell, IRB (like IPython for python people).)
Today I witnessed a pretty strange phenomenon where I had a game board that contained a bunch of objects representing items on the board. Each item involved in the game also contacted a reference back to the game board. After building this circular awareness we starting having problems with Pry where it would just flat out lock up and tax the CPU like crazy.
After some investigation we narrowed things down to the inspect method and the fact that whenever a statement in pry is executed (and irb too… I think) the inspect method is called on it. This ultimately gives you the nice visual representation of your objects we all love.
After some investigation and soliciting help from peers it looks like this was probably caused by the fact that the game board object referenced other game objects that in turn referenced the game board…. and so on…
In the past, this has NEVER been a problem for me, and later in the day I wasn’t about to reproduce it with different code… the situation today definitely caused a problem and wasted at least 30 minutes. 🙁
Some notes on thee specifics of merging vs rebasing with Git.
What is a Merge?
When you merge one branch into another branch the branch being merged into receives a single commit that basically brings it up to the current state of the source branch.
This commit is created automatically by git and essentially represents all of the differences between the branches stuffed into one change. If you were to `git log` in the branch that was merged into, you wouldn’t see any of the commits that had been made in the source branch.
What is a Rebase?
With rebase you basically say “use another branch as new base for my work”. Behind the scenes what appears to be happening is that git takes the current branch and rewinds any updates you have made on it. It then moves the starting point to the head of the branch you’re rebasing against. Finally all of the rewound changes are then applied on TOP of the updated/new starting point.
One thing to keep in mind with rebasing is that it will rewrite commits. Senko’s blog post explains it pretty poignantly:
In rebase, you change your branch (that’s being rebased) so it looks like it was branched off a new base, not the original one. This involves rewriting the commits, so you’ll end up with different commit IDs.
AppAcademy had us coding some games today! Specifically, Mastermind and Hangman.
When my pair Brittney and I started this we had both never heard of mastermind; so that was the first challenge. Turns out mastermind is pretty straight forward AND it’s actually a really cool game.
Let me explain the rules of mastermind first…
You basically have a board that allows for 10 turns. There’s a code-maker and a code-breaker. The board has 4 columns and a row for each of the 10 turns. Each row (or turn) also includes a “correctness area” (just baked that term up fresh) for the code-maker to indicate how many of the 4 were wrong, near or correct; I’ll explain those soon. For our purposes the computer was the code-maker.
The code-maker’s role is to make a secret “code” that consists of 4 colors selected from a list of 6 available options. Once the code-maker has selected a code he keeps it a secret and allows the code-breaker to guess it.
As I mentioned above, the code-breaker gets 10 attempts to crack the code. Each time he makes a guess he sets 4 colors from the 6 available on the row corresponding to his turn. At that point, the code-maker takes a look at the code-breaker’s choices and using the “correctness area” indicates if any of his/her choices were exact, near or wrong.
If a choice was exact, meaning the color and column selected were correct, a black marker is placed in the “correctness area”.
If a choice was near, meaning the code-breaker selected a correct color but didn’t place it in the correct spot, a grey dot is placed in the “correctness area”.
If a choice is flat in every sense, meaning it’s a color not used in the code, then we do nothing.
If the code-breaker guesses the code before the 10 turns are over, he wins! woot!
Our implementation basically had 3 classes a Computer (the code-maker), a Player (code breaker) and a Game class that actually “played” the game.
The full source is as follows:
Under construction still…
Today was Awesome. In my past experiences I’ve found that pairs balance out as they work but with Kriti I think we balanced out as a whole. To explain that a bit further… Kriti is incredibly strong with recursion problems … like straight up a bad ass (and I have a line of code to show for it) and I’m stronger with some of the more common Ruby idioms — test first and similar stuff in that vein. Instad of balancing out on a per problem basis it felt like we kind of showed our strengths against problems we were better at and the result was a good balance across entire duration of working together.
We worked on a lot of recursive problems and while working on one in particular ended up making a pretty ridiculous mistake… We used #each instead of #map. After probably an hour of trying to figure out why our ___________ method wouldn’t work we realized that we had been using #each (probably out of habit since it’s so common) and our results were coming out totally unchanged.
We actually ended up writing the same method like 3 different ways trying to resolve the issue and FINALLY zeroed in the fact that nothing was changing -> #each iterates and doesn’t make changes -> #map iterates and DOES make changes -> OMFGWTF
In other news, here’s an awesome, awesome, method that Kriti came up with.
____________________f