Last Night’s Cafe Racer Ruby on Rails Meetup; Kilt Lifter, EngineYard, Heroku and a Ruby Tone

Yesterday evening at the Cafe Racer Ruby on Rails meetupI knocked out these specific tasks.

Kilt Lifter by Pike Brewing Company
Kilt Lifter by Pike Brewing Company
  • Drank a solid tasty Kilt Lifter.
  • Created a sample beginning application, with standard migrations, and errata, and made two simple models with respective scaffolding.
  • Deployed the beginnings of a sample application to Heroku.
  • Deployed the beginnings of a sample application to EngineYard.

For Kilt Lifter information, click on the image at the right. If you live in the northwest, you know what’s up with the beer capital of the world (i.e. Portland, and the northwest in general, for info see here or click on the image to the left). We love our beer up here in these parts, we love it with a passion and it shows with more brewpubs, beer options, varieties, home brews, and other flavors than anywhere else in the world. No, I did not mis-state that, the northwest has more than anywhere else in the world, almost by an order of magnitude!  More than Germany, Ireland, England, the East Coast of the US, and the list goes on. So if you’re up for a beer and some coding, or just a beer, head to the northwest! We’ll have a few for ya to taste. 😉

The initial Ruby on Rails Application I created I started with RubyMine from Jetbrains. Simply a File -> New Project -> Rails Application, etc, etc. I worked through some of the issues with fellow rubiests and railers at the meetup. We did run into a confusing and nasty issue with Postgresql. Why was I installing Postgresql you ask? Well I was trying to do a deployment to Heroku, which provides a free shared instance of postgresql. I gotta admit, of all the things that Heroku makes absurdly easy, setting up a database is not one of them. Maybe I’m missing a bit, but I don’t know what the instance of the server is, what the username or password is, or anything of that sort. It isn’t all that intuitive that you have to add the database as an add-on either. At least, it wasn’t to the 3-4 of us that were working on it.

The other problem I ran into was what process I should actually use to install Postgresql. The firsts thing I tried to do was submit the “gem install pg” which ended with a completely wonky description. The error message read as:

[sourcecode language=”bash”]
$ sudo gem install pg
Building native extensions. This could take a while…
ERROR: Error installing pg:
ERROR: Failed to build gem native extension.

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb install pg
extconf.rb:1: command not found: pg_config –version
ERROR: can’t find pg_config.
HINT: Make sure pg_config is in your PATH

[/sourcecode]

I found a fix, here put together by Graham Ashton. Thanks Graham!

The fix involved simply to add a path variable…

[sourcecode language=”bash”]
$ PATH=$PATH:/Library/PostgreSQL/8.3/bin sudo gem install pg
[/sourcecode]

Meanwhile I dived into EngineYard and got the application up and running in short order. I have to say I am much impressed by the increased visibility into what’s going on with EngineYard. Heroku seems to hide just a bit too much. Add to that their over-reliance on AWS East and not geographically dispersing the platform, I’m leaning even heavier on suggesting EngineYard for startups and companies that want a cloud provider platform to build to.

Once the applications I’ve been working on get to a certain state, I’ll be providing a write up regarding the applications. However, until then, feel free to follow me on Twitter and Github or jump in fork my code and send me a pull request.  🙂

Update: Just some images from the meetup.

Ruby on Rails meetup at Cafe Racer - Corner Table
Ruby on Rails meetup at Cafe Racer - Corner Table
Ruby on Rails Meetup at Cafe Racer
Ruby on Rails Meetup at Cafe Racer

Bash, Ruby, and Such Console Installation Version Management Bits for OS-X

I went to reinstall RVM (Ruby Version Manager) and got a message that the command wasn’t available. I realized, after fiddling around for a while that I didn’t have bash setup, and I had tried to run the standard quick install of:

[sourcecode language=”bash”]
bash < [/sourcecode]

…I had not setup bash shell as my shell on this Mac?! Oops. So since I’m a virtual noob sometimes, and I have no idea how to setup bash, I did some searching and came up with this solution.

First, switch to bash.

[sourcecode language=”bash”]
chsh -s bash
[/sourcecode]

Then create yourself a .bash_profile so that you’ll be able to initiate variables and such that you’ll need in the shell. These are used when working with Ruby, Rails, and a whole host of other things. To create a .bash_profile you can follow these commands.  (Snagged from this find)

[sourcecode language=”bash”]
cd ~/
touch .bash_profile
open -e .bash_profile
[/sourcecode]

Then add this to the bash file.

[sourcecode language=”bash”]
# place in ~/.bash_profile as the very last line
[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"
[/sourcecode]

Now run the install (usually you’re told to setup this bash file afterwards, but figured we might as well get it done).

[sourcecode language=”bash”]
bash < [/sourcecode]

Next exit (or whatever your restart of bash technique is) and open your bash terminal back up. Type this command to be sure we’re on the right path.

[sourcecode language=”bash”]
type rvm | head -n1
[/sourcecode]

Now to install the latest Ruby on Rails bits you can issue a command like this.

[sourcecode language=”bash”]
rvm install 1.8.7
[/sourcecode]

However, OS-X already comes with 1.8.7, so you’d probably want to install 1.9.2. I issued the 1.8.7 install since I knew, previously, I’d dorked up the install a few days ago. So it is also a good way to make sure your install is cleaned up. I’m sure though, it could possibly mess things up if you’ve tweaked things the wrong way – but it sure seems to be the case that Ruby, Rails + RVM just works. 🙂

[sourcecode language=”bash”]
rvm install 1.9.2
[/sourcecode]

Once those are installed you’ll want to set one as default. I’m went with 1.9.2 for now. This can be changed later if need be.

[sourcecode language=”bash”]
rvm use 1.9.2 –default
[/sourcecode]

Anyway, that’ll get you started on OS-X if you’ve run into the “I’m only running the Terminal in its default setup, I need some bash” situation. 🙂

Happy coding, hacking, and gem installing!

References:

Some references are included above as links, but these below didn’t fit exactly in context at any point, I however used them none the less.

A Zillion Ruby Kōans

NOTE: Because of formatting, I couldn’t have a curly bracket with a colon and an “o” or it turns up with some unavailable WordPress Emoticon URI. So thus I have changed items with this naming to :z_one and :z_two respectively.

Yup, still moving through all the Ruby Koans. There are, after all 276 of these things! 😉 So no more yapping, onto the notes and green lighting the tests. Cheers!

[sourcecode language=”ruby”]
def test_creating_hashes
empty_hash = Hash.new
assert_equal Hash, empty_hash.class
assert_equal({ }, empty_hash)
assert_equal 0, empty_hash.size
end

def test_hash_literals
hash = { :z_one => "uno", :z_two => "dos" }
assert_equal 2, hash.size
end

def test_accessing_hashes
hash = { :z_one => "uno", :z_two => "dos" }
assert_equal "uno", hash[:z_one]
assert_equal "dos", hash[:z_two]
assert_equal nil, hash[:doesnt_exist]
end
[/sourcecode]

From test_creating_hashes a Hash.new or {} both appear to create a new empty hash object. The second test creates and adds values to the hash. The third test has asserts that verify the data is inserted in the positions that are expected.

[sourcecode language=”ruby”]
def test_changing_hashes
hash = { :z_one => "uno", :z_two => "dos" }
hash[:z_one] = "eins"

expected = { :z_one => "eins", :z_two => "dos" }
assert_equal true, expected == hash

# Bonus Question: Why was "expected" broken out into a variable
# rather than used as a literal?
end
[/sourcecode]

Again, the hash is setup into the hash variable. Then the expected is setup in another variable. Since Ruby is pointer oriented, the expected variable is setup identical to the hash variable to assure that they truly are identical.

[sourcecode language=”ruby”]
def test_hash_is_unordered
hash1 = { :z_one => "uno", :z_two => "dos" }
hash2 = { :z_two => "dos", :z_one => "uno" }

assert_equal true, hash1 == hash2
end

def test_hash_keys
hash = { :z_one => "uno", :z_two => "dos" }
assert_equal 2, hash.keys.size
assert_equal true, hash.keys.include?(:z_one)
assert_equal true, hash.keys.include?(:z_two)
assert_equal Array, hash.keys.class
end

def test_hash_values
hash = { :z_one => "uno", :z_two => "dos" }
assert_equal 2, hash.values.size
assert_equal true, hash.values.include?("uno")
assert_equal true, hash.values.include?("dos")
assert_equal Array, hash.values.class
end
[/sourcecode]

test_hash_is_unordered shows that a hash, no matter the order the values are assigned, assigns them to the values that are directly set to.

[sourcecode language=”ruby”]
def test_combining_hashes
hash = { "jim" => 53, "amy" => 20, "dan" => 23 }
new_hash = hash.merge({ "jim" => 54, "jenny" => 26 })

assert_equal true, hash != new_hash

expected = { "jim" => __, "amy" => 20, "dan" => 23, "jenny" => __ }
assert_equal false, expected == new_hash
end
[/sourcecode]

This test asserts that the two different hashes are different, nothing amazing or odd there. The second part asserts that the next and expected hashes are different. Which again, is what we expect.

[sourcecode language=”ruby”]
def test_default_value
hash1 = Hash.new
hash1[:z_one] = 1

assert_equal 1, hash1[:z_one]
assert_equal nil, hash1[:z_two]

hash2 = Hash.new("dos")
hash2[:z_one] = 1

assert_equal 1, hash2[:z_one]
assert_equal "dos", hash2[:z_two]
end
[/sourcecode]

This test confirms that a hash with a request against a hash position that isn’t assigned to yet returns nil. The later two asserts show that a number compared to the hash position that contains a number compares as a number, and a string compared to a position that has a string also compares as equal.

Until next time, hack some koans.

Kōans of Code

I’ve continued the Kōans, but there is one thing that won’t be noticeable from this blog entry. I however wanted to mention it. The first blog entry was worked through on an OS-X Apple Machine, the second on an Ubunta Linux Machine, and now I’m heading for this blog entry to be completed with  Windows 7. It is of course completely irrelevant, but at the same time very relevant.  🙂 But enough about operating system awesomeness. Let’s take a look at the new gazillion Kōans that caught my note taking.

[sourcecode language=”ruby”]
class AboutArrays < EdgeCase::Koan
def test_creating_arrays
empty_array = Array.new
assert_equal Array, empty_array.class
assert_equal 0, empty_array.size
end
[/sourcecode]

Easy peasy. Array.new creates a new empty array. Got it. An Array is the class type retrieved when calling empty_array.class. Got it. The empty array has a size of zero, Got it.

[sourcecode language=”ruby”]
def test_array_literals
array = Array.new
assert_equal [], array

array[0] = 1
assert_equal [1], array

array[1] = 2
assert_equal [1, 2], array

array << 333
assert_equal [1, 2, 333], array
end
[/sourcecode]

Ok, this one has some interesting bits in it. Having array[0] and array[1] assigned to a value of 1 and 2 seems standard operating practice for a language. This dual chevrons pointing into the array thing is a little more unique. This operator appears to take the value on the right, and put it onto the array’s stack. Simply, the double kick operator (or whatever it is called) puts the value on the next available array index position. Ok, cool. Got it.

[sourcecode language=”ruby”]
def test_accessing_array_elements
array = [:peanut, :butter, :and, :jelly]

assert_equal :peanut, array[0]
assert_equal :peanut, array.first
assert_equal :jelly, array[3]
assert_equal :jelly, array.last
assert_equal :jelly, array[-1]
assert_equal :butter, array[-3]
end
[/sourcecode]

Alright, got an array with 4 elements in it. First assert confirms that :peanut is the returned value from the first element in the array. The array.first call functionally does the same thing. The third assert gets the 3rd value in the array, keeping in mind a zero based index for the array, that gives us the 4th actual item in the list of items stored within the array. I love it, standard programmer weirdness. Why do programmers start with zero when nobody on earth starts a “list” of items with a zero. Blagh, whatever, that’s the reality of it. (That was, in a sense, somewhat rhetorical, I get the underlying reasons but that doesn’t help explain a zero based index to initial non-programmers.)

[sourcecode language=”ruby”]
def test_slicing_arrays
array = [:peanut, :butter, :and, :jelly]

assert_equal [:peanut], array[0,1]
assert_equal [:peanut, :butter], array[0,2]
assert_equal [:and, :jelly], array[2,2]
assert_equal [:and, :jelly], array[2,20]
assert_equal [], array[4,0]
assert_equal [], array[4,100]
assert_equal nil, array[5,0]
end
[/sourcecode]

Slicing arrays again with the PB & J. With two values, the first thing I notice is that this is no multidimensional array. Two values within the square brackets means that you have a starting position and then a value of how many to retrieve. If there is a value like the fourth asset, starting at the 2nd position (3rd actual value) and taking the next 20 elements, basically retrieves whatever values are available, which in this case gets us 2 elements.

Now, I’m a slight bit perplexed though as to why nil is returned for something request nothing from the 5th starting point of the array versus the same being requested from the 4th starting point in the array. I’ll have to read up on that…

[sourcecode language=”ruby”]
def test_arrays_and_ranges
assert_equal Range, (1..5).class
assert_not_equal [1,2,3,4,5], (1..5)
assert_equal [1,2,3,4,5], (1..5).to_a
assert_equal [1,2,3,4], (1…5).to_a
end
[/sourcecode]

Again, identifying the class object type is easy, a range of numbers is a Range Object. Check. A range stating 1..5 does not provide the numbers one through five. Calling to_a on a range however does provide you those numbers. Doing the same thing to an array specified with three periods instead of two with the to_a provides numbers one through four. That seems odd, but I got it.

[sourcecode language=”ruby”]
def test_slicing_with_ranges
array = [:peanut, :butter, :and, :jelly]

assert_equal [:peanut, :butter, :and], array[0..2]
assert_equal [:peanut, :butter], array[0…2]
assert_equal [:and, :jelly], array[2..-1]
assert_equal [:peanut, :butter, :and], array[0..-2]
end
[/sourcecode]

Slicing an array of four values, stating the starting and ending point with the syntax of a range, provides the elements based on the values associated with that range. I actually added an assert to this test to determine what exactly the negative values do. It appears that the array starts at the point of the first number, then follows a range from that until the negative number from the end of the array. So with 10 items, starting at point 2 and ending -2 from the end will retrieve the middle 6 elements. Strange, but I can see how this would be very useful.

[sourcecode language=”ruby”]
def test_pushing_and_popping_arrays
array = [1,2]
array.push(:last)

assert_equal [1,2,:last], array

popped_value = array.pop
assert_equal :last, popped_value
assert_equal [1, 2], array
end
[/sourcecode]

Pop. Easy, get that last value. But wait a second, the array itself doesn’t have :last in it? Aha! Popping it not only gets that last value, but literally takes the value out of the array.

[sourcecode language=”ruby”]
def test_shifting_arrays
array = [1,2]
array.unshift(:first)

assert_equal [:first, 1, 2], array

shifted_value = array.shift
assert_equal :first, shifted_value
assert_equal [1,2], array
end

end
[/sourcecode]

Ah, kind of like a popped value but shifted out of the array? Weird, this is a little confusing at first. I see what it is appearing to do, but figured a good read of the documentation would be good. I did a search on Google and the first hit is someone asking this question.

What does Ruby’s Array Shift Do?

From that quick read it appears that shift and unshift are used similar to pop and push in a stack (ala git, etc).

That answers that question. With that, I’m off to other realms.

More Code Kōans

This is a continuation of my effort to get through all of the Ruby Kōans.

[sourcecode language=”ruby”]
def test_creating_arrays
empty_array = Array.new
assert_equal Array, empty_array.class
assert_equal 0, empty_array.size
end
[/sourcecode]

Creating a new array, just use Array.net. That I like. 🙂 Next assert verifies that the class is an Array. The third assert verifies that we have an empty array. That works, very logical, very array like.

[sourcecode language=”ruby”]
def test_array_literals
array = Array.new
assert_equal [], array

array[0] = 1
assert_equal [1], array

array[1] = 2
assert_equal [1, 2], array

array << 333
assert_equal [1, 2, 333] array
end
[/sourcecode]

array[0] makes sense, seems par for the course. Now << operator putting the value of 333 into the array in the next available position. I’m a fan. 😀

[sourcecode language=”ruby”]
def test_accessing_array_elements
array = [:peanut, :butter, :and, :jelly]

assert_equal :peanut, array[0]
assert_equal :peanut, array.first
assert_equal :jelly, array[3]
assert_equal :jelly, array.last
assert_equal :jelly, array[-1]
assert_equal :butter, array[-3]
end
[/sourcecode]

Ok, this is somewhat understandable. The peanut (with the colon? why is the colon included?) is the first value. Cool. That makes sense. The zero is actually the first part of the array, which matches well to array.first, still making sense. The jelly value is in the 3rd, or last location and I’m good with that. Now it gets weird, where is -1? I suppose it is jelly since that test now asserts true. Negative 3 is butter though, which I guess negative values just start from the end. Does that make sense? Either way, it appears to be working that way.

NOTE: This is a a great scenario, to me, and maybe for others, when taking notes pays off. It doesn’t matter if you’re studying for a test or not. I didn’t quit realize what was happening here until I wrote a note, simply explaining it back to myself. Even if you think you get something, writing it down and forcing yourself to think it through is a proven method to putting something to memory.

[sourcecode language=”ruby”]
def test_slicing_arrays
array = [:peanut, :butter, :and, :jelly]

assert_equal [:peanut], array[0,1]
assert_equal [:peanut, :butter], array[0,2]
assert_equal [:and, :jelly], array[2,2]
assert_equal [:and, :jelly], array[2,20]
assert_equal [], array[4,0]
assert_equal [], array[4,100]
assert_equal nil, array[5,0]
end
[/sourcecode]

Basically the array is saying, give me one item based on the index of 0. The second assert is starting at index 0 and providing the next two array elements. The same thing then happens for the next two. Of course, starting at index 2 and getting the next 20 values just gets the available values. I can cope with that. The next two asserts then return no value, as there is no 4th array position (remember, it starts at zero.) The last item asks for no items from the array, thus nil is returned.

Well, that’s it for now. More to come in the near future.