More on Well-Grounded Rubyist

I hit another one of those confusing passages that I think I get, but not quite. Moreover, this is a good time to remember class methods—which are, essentially, singleton methods attached to class objects.

Objects are classes, classes are objects, war is peace. Sometimes this sounds like “1984” for developers.

And we will always be at war with Javascript.


More Notes on “Well Grounded Rubyist”

Modules in Ruby are sort of like interfaces in Java. They sort of allow multiple inheritance, and you can mix-in mulitple modules, just as a class in Java can implement multiple interfaces. But the methods in a Ruby module actually do stuff, whereas methods in Java interfaces are just the signatures. In Ruby, class names are nouns, and module names are adjectives. You can also contain classes within modules, which allows namespacing in Ruby.

Constants in Ruby begin with a capital letter, and are usually written in all caps. They are like class-level variables. Even though they are called “constants”, he showed that they can be changed. If you need to change class-level data, it might be better to have a constant point to an object, and change the object the constant points to.

Ruby Pipelines

A few weeks ago I attended a Geekfest talk by Myles Byrne about shell scripting.

He talked a lot about using Unix pipelines to string together programs to manage data. The advantages of doing this include thread-safety, and that you can essentially do more than one step at a time. If you are using Ruby to perform multiple operations on a file, you cannot start a step until the first one goes through the entire file. If you are dealing with a large file, that could take a long time to get any results.

Nobody in the room could think of any Ruby gem that could act as a pipeline. I may have found one by Atomic Objects in Michigan. It’s called Piece Pipe. I have not looked at it too closely yet (I am writing about this here so I can find it easily later). They say that they want to do “pipeline-style programming”. I don’t know if it gives all the benefits of stringing together apps in a shell script with pipelines, but it is something to look at.


Well-Grounded Rubyist

On the advice of Code Academy founder Neal Sales-Griffin, I am going through The Well-Grounded Rubyist. So far, I am liking it more than the Pickaxe book.

I did have a bit of a hard time with part of chapter three understanding singleton methods and class methods. Partially because terms and concepts can get swapped between languages. In Ruby, a class method is the same thing as a static method in Java. In Java, a “singleton” refers to a class that is only instantiated one time, like a logger class. In Ruby, a “singleton” is a method that is created for an instance object that is not in the class definition, and that other instances of that class will not have.

Part of the chapter dealing with this stuff was a bit confusing for me. Partially because of the terminology swap between languages, and the terminology swap in the book. In Ruby, everything is an object. Even classes. A class is an object is a class is an object is a class etc etc etc. So he was talking about singletons for class methods of objects connected to the thigh bone. This can get pretty confusing in general. Justin Love has given a presentation on it, and he compares it to the movie Inception, where you can have dreams within dreams.

I like Ruby, but changing existing class definitions (instead of just extending) seems like voodoo. I know Rails does it, but right now it just sounds like something to avoid.

After I get through this, I will go through Eloquent Ruby. A few people on Twitter have said that is a good combination.



Notes On Making a Gem

I decided to make a gem for a bit of practice. I did some googling, and I found a good RailsCast on it.

He uses bundler, which takes care of a lot of the heavy lifting. All I did was run

This will create a directory with the same name as whatever you called the gem. Then to add RSpec, cd to the directory that was created. Then run

I wanted to make a gem with a few layers in the directory tree. Java package names tend to have multiple levels, while most Ruby gems seem to only go one level deep. Perhaps I will never write a gem that has too many levels, but I wanted to make one with a few levels anyway.

I decided to start with a state in the first level. I added

to lib/states.rb
Then add a file: lib/states/hawaii.rb

Then I added a test file. Then in spec/spec_helper.rb, add

I added the  file spec/states/hawaii_spec.rb

There is another way to recognize the module levels in the RSpec file:

I put

in each spec file.

I also added a class lib/states/illinois.rb, and a test file in spec/states/illinois_spec.rb.

I then tried to add a few classes for Champaign County and Urbana. I tried to put them in a directory lib/states/illinois and in spec/states/illinois.

I got this error:

But I changed the directory name to illini, and I updated the files accordingly, and it worked. I changed it all back to “Illinois”, and it stopped working again. So now the module is back to “Illini”. I do not know if Ruby or RSpec will not allow a directory and a class to have the same name, or if I just needed to put illinois.rb in a higher directory. There is a states.rb and a states directory. Perhaps the gem name is an exception to the uniqueness rule. But in the future I will stick with using different names.

So, to summarize, I ran

Then to add RSpec, I ran

For every class that I made, I put a file in lib, a corresponding file in spec, and I put a require statement in the states.rb file.
And the class file names must not be the same as the directory names.

I am sure that for a lot of Ruby people, this post will be review. I tried making a gem using some of the code from the RSpec book as a basis, and I could not get it to work. I did the guy thing by trying something without reading the directions. I am thinking of proposing a talk for Lone Star Ruby Conf, and I need to be able to get a gem to work.

Update On RSpec Group 2012-05-20

There has been a smidge of progress for the RSpec Study Group. Part of the issue is I am not clear how to go about it. I talked with The Fonso and Ginny Hendry about it, and they gave me a few ideas. Even though I am calling it the “RSpec Study Group”, we will cover other frameworks as well. The RSpec book covers Cucumber for a couple of chapters before it gets to RSpec.

Perhaps we will have a meeting a week.

One week will be going through a chapter in the RSpec book.

Another week could be a hack night where we write tests for someone’s project.

Another week could be a lecture from someone in the community. Ginny pointed out that people have pretty set opinions on testing, and it would be good to expose people to multiple viewpoints. I talked to one of the developers of if they would be willing to share their ideas about testing. One of the reasons they made was to get experience with Cucumber and Capybara.


More Notes On RailsConf

DHH  gave one of the keynotes at Railsconf . He talked about the idea of change, and changes in Rails. He said that the Rails committers will make changes to Rails if they feel it is best even if it causes some grief for people. The basic message was to stay agile. A lot of people come to Rails and they are only comfortable with the version Rails was at when they get to it. They do not change with the framework. DHH said we should change with the framework.

He seems pretty committed to Rails, which is good.

At my last job, we used a web framework called Seam. It is the worst framework I have ever had to deal with. At first I was enthusiastic about learning it, and enthusiastic about the job. But after several months, I found Seam to be awkward to work with, and hard to write tests for. I started to hate Seam, hate my job, hate my life.

One of the co-founders said that he was disappointed in my performance. He had hoped that I would give more input into the design of the product/application. The only advice I could give was to stop using Seam. He wasn’t going to go with that advice, so why give it?

(I remember one day one of the co-founders and I spent several minutes trying to get the other co-founder to grasp the concept of the sunk-cost fallacy. But looking back I cannot remember which one got it and which one did not.)

I was on the Seam mailing list, and I do not remember ever seeing a post by Gavin King, the creator of the framework. He is not even working on Java anymore. He is making a new JVM language called Ceylon. In all seriousness, does the world really need another JVM language? The point being that if Gavin King does not want to play with his toys, don’t ask me to.

From what I have heard, Gavin King is as much of a jerk as DHH. I wonder if they have ever met. Perhaps that would solve our energy crisis.

Thoughts On Rails Generators

A few people I know tweeted to a Rails commit on Github that “Added a generator option to remove the public/index.html file when generating a new Rails application.” The people that tweeted about it said it was about time that this was included.

I think a good option for the scaffold generator would be to explicitly list the routes for each of the created actions in the controller instead of just adding

to the config/routes.rb  file.

It would generate this in the config/routes.rb file:

I ran rake routes with each, and they matched.

Image from Corpus Agrimensorum Romanorum, a 6th century manuscript on land surveying housed at the Herzog August Library in  Wolfenbüttel. According to Wikipedia, “It is one of the few surviving non-literary and non-religious illuminated manuscripts from late antiquity.” This image is assumed to be allowed under Fair Use.


Update From RailsConf In Austin

I will probably post more about RailsConf when I get back. So far I like the presentations that I have been to. Here are thoughts on a few presentations.

One of the best was “Use the Source, Luke: High fidelity data with event sourcing”, by Keith Gaddis (Twitter account here). Here is the synopsis:

Ever run into a really gnarly data problem and wished you had a do-over? Tired of wrestling with ActiveRecord to model a really complex domain? Looking for a good way to echo state changes to external systems? Then grab a cup of joe and settle in for a look at event-sourcing your data.

Event-sourced data uses Plain Old Ruby Objects (POROs) to model your data and exclusively uses events to mutate state on those objects. By serializing the events, the state of your data can be recreated for any point in time, and outside listeners can create specialized purposeful datastores of the data, enabling complex business requirements with fewer hassles. We’ll also touch on other architectural patterns like DCI and CQRS that play well with this idea

Someone afterward said that it was the best presentation they saw at the conference. People were still asking him questions and discussing the topic 30 minutes later. I will certainly look for the slides and video for this one.

Another good one was “Presenters and Decorators: A Code Tour” by Mike Moore (look at his Twitter account). The idea is that you use presenters and decorators when you have a lot of if statements in your views and templates.

I also liked “Ten Things You Didn’t Know Rails Could Do With Rails” (with 32 bonus stuff) by the always-entertaining James Edward Gray (Twitter account here).

I just spent an hour doing one of the apps at RailsApps (Twitter account here).

Image from Wikimedia, assumed allowed under Fair Use. Image from the St Augustine Gospels, a 6th century manuscript made in Italy in the 6th century, brought to Britain by the Other Saint Ausgustine.