Core of the Core: Reflection Talk
May 17th, 2010 by Ben Wagaman.Categorized as Ruby on Rails, programming.
Tonight at the Columbus Ruby Brigade meeting, I gave part two of my “Core of the Core” speaking series.
Part two was on Reflection in Ruby.
Tonight at the Columbus Ruby Brigade meeting, I gave part two of my “Core of the Core” speaking series.
Part two was on Reflection in Ruby.
I’m electronifying my notes from conferences and such. Here’s my notes from Jim Weirich’s SOLID design principles in Ruby talk from eRubyCon 2009.
1.) Single Responsibility Principle
a class should have 1 reason to exist
describe the purpose of your class in a single sentence (you shouldn’t need and/or)
2.) Open/Closed Principle
you should be able to extend a class’ behavior without modifying it
3.) Liskov Substitution Priniciple
require no more, promise no less
4.) Interface Segregation Principle
5.) Dependency Inversion Principle
depend on abstractions, not concrete-tions
** Note that my notes are a little bit shotty, because the days prior to the conference I was totally totally strapped at work and thus rest-deprived.
It’s been a long time since I posted anything in my blog, so I thought I ought to break the silence. Lately, I’ve been trying to get myself caught up on the test-driven/behavior-driven development philosophy. If you are a programmer, maybe you can relate to my struggles of learning how to get it right.
Test-Driven Development is a programming philosophy that encourages the developer to specify test test conditions before writing the code to meet the specification. To me, this is counter-intuitive. I guess I am naturally a brute and think the best way to figure something out is to play with it, and than after a while it should just work.
Ironically, the chapter on Testing in the Agile Web Development with Rails book comes well after the first attempts at hammering out Rails code for a shopping cart application. I understand why the book is written the way that it is, and am greatly appreciative of the book, but there ought to be a Test-Driven version of the same tutorial, so that people can see first-hand how to test-first in development.
It also hasn’t helped that my first attempt at writing tests have been less than perfect too. I’ll end up writing 6 or 7 lines of test code to test one case for a method. The verboseness of tests has negatively reinforced me in to thinking that testing is hard.
What’s more frustrating is that I’ve heard expert developers talk about only having a line or two of test code to test a method. This has seemed to me to be an unatainable ideal. How are you supposed to test code that is ten lines long (or more) with one or two lines of test code? That’s unpossible.
But, recently I came to the realization that if the methods I am writing are smaller and do more specific things, then they are a whole lot easier to test. This is mostly because the tests can move towards the ideal of the expert: short, meaningful, specifications. This in turn helps me to actually write the test first, because I know I can specify the behavior of code that is less complex.
Some of the recent developments in RSpec have helped this ideal even further. For instance, see David Chelimsky’s post on RSpec 1.1.12 He notes that what you could have done
In order to test this:
class Person
validates_presence_of :email
end
You would have in previous versions of RSpec written:
describe Person do
it "should validate presence of email" do
person = Person.new(:email => nil)
person.should_not be_valid
person.should have(1).error_on(:email)
end
end
In RSpec 1.1.12, you can reduce this down to the following:
describe Person do
it { should validate_presence_of(:email) }
end
This is due to:
Three lines of code. Three lines of test. That’s pretty darn cool. Perhaps, it’s not possible to have a line by line spec for everything, but this is a lot better than before.
I’ve still got a fair bit of inertia to overcome before I’ve got TDD under my belt. The more I tell myself that test-driven development is less about testing than it is about developing well-written code, the more motivated I am to do it. I hope this is an encouragement to unit testing newbies.
Today I was writing some specs with RSpec, the Ruby BDD Testing Framework. In between tests, classes aren’t reloaded by default, so I went about try to figure out how to reload a class for certain tests.
Active Support defines a method on Class called remove_class. This provides half of the equation. The other half was to reload the class again. So, I wrote a method on the Object class that should handle most cases. Note, this may not work with namespaced classes, but it did the quick and dirty job of helping my specs to reload the class.
# Call this method like
# MyRubyClass.reload!
# or
# MyRubyClass.reload!('/path/to/file/my_ruby_class.rb')
class Object
def reload!(file = nil)
remove_class(self)
load(file || "#{self.to_s.underscore}.rb")
end
end
All I needed to do was then call this method when I needed to reload the class.
MyRubyClass.reload!
Speakers for the main sessions of RailsConf 2008 are available now. A number of Columbus/Cincinnati Rubyists are showing: Jim Weirich, Joe O’Brien, Aaron Bedra, Dan Manges. I wish I could go. Oh well, maybe next year
On another note, Blip TV has a number of the keynotes from RailsConf 2007 online.
With Rails 2.0 out now, it’s time to explore the new source. It’s hard to believe that it’s already been 2 years since I first checked out Rails 1.0 for the first time.
To update your Rails code, you can run
gem update rails
However, when I tried to run this command I was unfortunately greeted with a nasty error, when getting to update ActiveRecord.
Attempting remote update of activerecord
ERROR: While executing gem ... (Zlib::BufError)
buffer error
According to a Ruby Form post, I found a solution to the problem, updating ruby gems.
While you could run this line to update RubyGems to 0.9.5, I don’t recommend it.
gem update --system
Instead download rubygems-0.9.4, unzip it and then run
ruby setup.rb
This will allow you to continue to use Mongrel, because there are some incompatibilities with Mongrel running on Win32 with RubyGems 0.9.5. See the following:
and then update rails as you would expect.
gem update rails
Voila!
After many months of hard labor, I am emerging victorious with my first large-scale web application called Rankaroo. Rankaroo helps you organize your interests, share them with others, and connect with like-minded people. Everyone is a guru at something. Whether it’s that you know about ski lodges in the Alps or Greek Mythology or Hip Hop, whatever it is you have something to keep organized and share with the world. As we each share our interests we all benefit from mutual discovery.
In the traditional browser way of storing your favorites, you would put your favorites in a hierarchical set of folders and hope that you can remember where you put them later. A few years ago, some sites like del.icio.us introduced the idea of eliminating the hierarchy and using tags instead (basically words). But while this makes it easier to find things later, it’s relatively difficult to find a cross section of these tags, plus you basically throw out your normal grammar in favor of an alphabet soup of words.
Rankaroo is based strongly on the Connect-by-Clicks technology. Connect-by-Clicks is a system that turns simple language into connective tissue. It works as following.
You want to categorize the following web site. http://espn.go.com
Just type a simple phrase. For instance. espn sports news and scores
What Connect-by-Clicks does is creates interconnections between these words. So, later you could find this favorite by going to sports -> scores or espn -> news or espn -> sports -> scores.
While this is cool in itself, it’s not nearly as cool as when hundred of people are all doing the same. If my friend, Joe, enters a favorite on his basketball team and categorizes it by the phrase knicks basketball team scores, if I was searching for scores, I would find out about his basketball team.
You’ll have to experience the power of Connect-by-Clicks yourself to see what I mean.