lindsaar.net - Home

Tip #28 - Separate the things that change from the things that stay the same

2008-07-13T11:21:00Z

When you are coding, you should try to separate out the things that change from the things that stay the same. This isn’t my idea, but it is worth tip’n here as I just saw a really good, simple example of this…

I first read about this concept in learning about Design Patterns. Then I also read it in Design Patterns in Ruby by Russ Olsen (good book by the way).

The basic concept is that if you can spot the few lines of code in your design that could change and move these out to a separate part of your code base, when a change comes along, you just have to change one small part of your app and you are done. You don’t have to dive through lots of classes fixing and correcting code everywhere to implement the change.

I recently ran into a good example of this, it is the Active Record Extensions by Zach Dennis

I use PostgreSQL, Zach’s Active Record extensions worked out of the box with PostgreSQL, but in the inefficient fail-safe manner, that is, it did bulk inserts by making one complete insert statement per row, which is per the SQL standard.

For MySQL, he had implemented the multiple insert method in SQL, which allows you to write on “INSERT INTO…” and give it an insert array of (in my case) 1000 rows. This cuts down on data transfer between the client and server. Especially when you are inserting a few hundred thousand rows.

I knew PostgreSQL also supported this, so I dove into the code base to find a way to implement.

Happily, I found that Zach had followed the above rule to the letter. To implement this, I had to modify one line in one file (to include a module) and copy about 20 lines into another file (the MySQL versions) and modify a few of those lines to suit PostgreSQL and I was done!

This was a good piece of code, a good example of the above and worth looking at for a Ruby on Rails intermediate type who wants to find out more about plugins and extending ActiveRecord.

Mikel

Fortune...

2008-07-08T02:57:00Z

I got his when I logged into one of my OpenBSD boxes today. Interestingly true…

An architect’s first work is apt to be spare and clean. He knows he doesn’t know what he’s doing, so he does it carefully and with great restraint.

As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used “next time”. Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a “big pile”.

-- Frederick Brooks, "The Mythical Man Month"

Examples of Behaviour Spec'n

2008-06-30T00:05:00Z

In my previous post (Spec Behaviour not Implementation) I went on a froth roll about why you should treat controller actions as black boxes. Here I give an all to common example of why this is good and how you can write specs that won’t break at the most trivial change.

class AddressesControler < ApplicationController
  def index
    @person = Person.find(params[:person_id])
    @addresses = Address.find_by_person_id(params[:person_id])
  end
end

Now obviously this should be refactored (we’ll get to that in a sec) but what are we doing here? We are assigning person to the view and the person’s addresses to the view.

Using a mocks and stubs, I might do something like this:

describe AddressesController do
  describe 'GET index' do

    it "should ask the Person model for a person" do
      @person = mock_model(Person)
      Person.should_receive(:find).with("1").and_return(@person)
      get :index, :person_id => 1
    end

    it "should assign a person to the view" do
      @person = mock_model(Person)
      Person.stub!(:find).and_return(@person)
      get :index, :person_id => 1
      assigns[:person].should == @person
    end
    
    it "should ask the Address model for the addresses" do
      Person.stub!(:find)
      @addrs = [mock_model(Address), mock_model(Address)]
      Address.should_receive(:find_by_person_id).with("1").and_return(@addrs)
      get :index, :person_id => 1
    end

    it "should assign the person's addresses to the view" do
      Person.stub!(:find)
      @addrs = [mock_model(Address), mock_model(Address)]
      Address.should_receive(:find_by_person_id).with("1").and_return(@addrs)
      get :index, :person_id => 1
      assigns[:addresses].should == @addrs
    end

  end
end

Now, no one would complain about that (except that it is not very dry), pretty straight forward. But I say, my fellow RSpecers, what are we doing poking around the internals of that controller? Why do we give two hoots from a behavioral viewpoint on HOW the controller goes about it’s business? Can’t we just assign the controller responsibility here?

Well, no, you say, I need to know it is getting the addresses properly!. Well, ok, let’s make one trivial change to one line of that controller and see how many specs break:

class AddressesControler < ApplicationController
  def index
    @person = Person.find(params[:id])
    @addresses = @person.addresses
  end
end

Now, you would agree with me that the external behaviour of that controller action has not changed, we are assigning the requested person to the view and we are assigning the person’s addresses to the view, but guess what, every one of our specs now fail Why!? Because we spec’d implementation details. We setup our stubs and mocks to provide data in only certain ways.

The first and second specs fail because @person is a mock model and gets an unexpected message :addresses, the second and third specs fail because we don’t return anything from the Person.find and so you then get nil.addresses which fails. Even if that didn’t fail, we then have a failing spec because the Address model is never called.

Evil. Madness. Insanity, but most importantly, lost time. Now you need to go and dig in, remember what that spec did, what you were trying to do and re-write the spec, hoping that you aren’t changing the required behaviour.

And what is worse, our behaviour driven development specs are failing when the behaviour didn’t change!

Now there is a lot to be said for mock objects and stub methods. They are useful and have their place, they definitely speed up spec execution time, but I think this whole thing of mock everything in the controllers to make the specs go faster is over rated.

I work in a development team. We user factory objects and real objects when we can get away with it. And our specs run slower. On an app that is about 50% done we have 1500 specs passing, and it takes about 70 seconds to run them. Not too bad. About half of them use real objects (from the database). Sure, if I went through and mocked and stubbed everything out and spent the time doing that, it might get down to 50 seconds, or maybe 40. But it is pretty rare that waiting for the test suite to pass is blocking my development time.

So, if we re-wrote the above spec using factories, we would get something like this:

describe AddressesController do
  describe 'GET index' do

    it "should assign the requested person to the view" do
      @person = Person.build_valid!(:id => 1)
      get :index, :person_id => 1
      assigns[:person].should == @person
    end

    it "should assign the person's addresses to the view" do
      @person = Person.build_valid!(:id => 1)
      @address = Address.build_valid(:person_id => @person.id)
      @person.addresses << @address
      get :index, :person_id => 1
      assigns[:addresses].should == [@address]
    end

  end
end

Now, even though we have reduced this down to two specs, in reality, that is all the behaviour our controller is showing. It has no error handling etc.

If there were decision path’s in the behaviour of the controller, I would stub these out to do what I wanted for the spec, like @person.stub!(:save).and_return(false) and the like.

One other thing that I often read is that you don’t want to do a spec like this because some other developer could go and change the underlying API on how person and address talk to each other or what constitutes a valid object.

Well, I work in a team and I humbly submit that:

(a) this doesn’t happen too often, especially if you are using factories, because if you change the valid requirements of a person, then you should also be updating the factory.

(b) I want to know if my controller broke because of an API change.

Anyway, that’s just how I do it, your mileage may vary.

blogLater

Mikel

US iTunes Gift Vouchers Up for Sale

2008-06-28T04:35:00Z

Bit off topic, but over the past two weeks I have received $75 in US iTunes gift cards.. per apple, I can’t use them from Australia… anyone want to buy them? I’ll sell the lot for $70 US.

Turns out that Shane showed me if it is a voucher, you can redeem it at the US iTunes store… cool :)

blogLater

Mikel

Tip #27 - Spec a Behaviour, Not an Implementation

2008-06-28T03:42:00Z

This has been said a lot, and doesn’t really need repeating by someone like me, but, as this is a tips page, I should put it here.

What does this mean? Behaviour, not Implementation?

Well, it means, what is it you are expecting your code to achieve? What is the end product that your code is meant to do? What are the valid states your code can be in after it has finished executing?

The way I draw the line on this is, except for RARE cases, I only spec the public interface of a component. That is, the bits that the class is presenting out to the bad wide world as valid ways to communicate to it. If you do this, it means that later you can change your implementation of HOW you got something done without a bunch of specs failing.

The applies to controller specs.

You should really treat the insides of a controller as sacrosanct, you don’t really have any business hunting and poking around in there, each controller has a right to privacy, THEY HAVE RIGHTS TOO!...

Ok, maybe a bit carried away, but you might see what I mean in a sec:

def create
  @person = Person.new(params[:person])
  
  respond_to do |format|
    if @person.save
      flash[:notice] = 'Person was successfully created.'
      format.html { redirect_to(@person) }
      format.js
    else
      format.html { render :action => "new" }
      format.js
    end
  end
end

With this simple example, what is it we are actually trying to spec?

Well, what is the behaviour?

1. If it succeeds, then we should get a flash sent to the view telling us we were a good little user.

2. If it succeeds, then we’ll get sent to the person show page

3. If it succeeds and we did an XHR request, then we’ll get the create.js template

4. If it succeeds we should get a person instance assigned to the view that has been saved.

5. If it fails on a HTTP request, then we get the new template rendered

6. If it fails on an XHR request, then we’ll still get the create.js template

7. If it fails then we should get a person instance assigned to the view that has not been saved.

And that’s it.

You don’t want to get into what params are being assinged to the person model on the new action, you don’t want to get into if the person model receives the wrong number of values for the new action, or anything like that.

Why? Because what the model does with the params is really no business of the controller. It is not the controller’s responsibility. All the controller wants to know is “Did it save or not?”

In fact, I would argue that no where in your spec for the controller would you have ”@person.should_receive(:save).with(some_params).and_return(true)”, no, it is implementation detail, evil.

Ideally (though this is hard to achieve in practice) you want to try and treat each executable code block as a black box in terms of describing behaviour.

You want to know “If I feed it XYZ, then the result will be ABC”. You don’t want to get into ‘If I feed it XYZ, then I need to make sure it will do A through Z so that I can then test to see if it actually did ABC’

See the difference? The first viewpoint allows you to refactor away inside the discrete code block (the create action in this case), but the second requires your behaviour specification code know every minute detail about your code execution, and that my friends is about as brittle as a 10,000 line PHP page.

Use ‘shoulds’ for specifying behaviour and use ‘stubs’ for dictating code execution paths.

if you did that, your specs would look something like this:

describe "create action" do

  def doing_a_successful_save
    @person = mock_model(Person, :save => true, :new_record? => false)
    Person.stub!(:new).and_return(@person)
  end

  def doing_a_failed_save
    @person = mock_model(Person, :save => false, :new_record? => true)
    Person.stub!(:new).and_return(@person)
  end

  describe "successful request" do
    it "should flash a notice to the user that the create succeeded" do
      doing_a_successful_save
      post :create
      flash[:notice].should == "Person was successfully created."
    end
    
    it "should assign a person instance to the view" do
      doing_a_successful_save
      post :create
      assigns[:person].should == @person
    end
    
    it "should render the show template for HTTP Request" do
      doing_a_successful_save
      post :create
      response.should render_template('show')
    end
    
    it "should render the create template for XH Request" do
      doing_a_successful_save
      xhr :post, :create
      response.should render_template('create')
    end
    
    it "should assign a saved person instance to the view" do
      doing_a_successful_save
      post :create
      assigns[:person].should_not be_new_record
    end
  end

  describe "failed request" do
    it "should return the new template for HTTP Request" do
      doing_a_failed_save
      post :create
      response.should render_template('new')
    end
    
    it "should return the create template for Ajax Request" do
      doing_a_failed_save
      xhr :post, :create
      response.should render_template('create')
    end
    
    it "should not save the object" do
      doing_a_failed_save
      post :create
      assigns[:person].should be_new_record
    end
  end
  
end

BDD is a discipline. Getting your head around it really starts with understanding the basic underlying principles of WHY you are doing it.

BDD stands for Behaviour Driven Development. So stick with that and nothing more and you will find BDD a lot easier to get done.

blogLater,

Mikel

Tip #26 - Start Small

2008-06-27T10:18:00Z

If you are getting frustrated with RSpec, then you have probably skipped a gradient. Start smaller!

When I was trying to teach a co-worker how to write specs, I ran into a gradient problem. He was trying to write specs for an existing app and controller setup that had the usual create action in the controller, it also had a before filter checking logins and timezones, the controller action was simple enough, something like this:

def create
  @person = Person.new(params[:person])

  respond_to do |format|
    if @person.save
      flash[:notice] = 'Person was successfully created.'
      format.html { redirect_to(@person) }
      format.js
    else
      format.html { render :action => "new" }
      format.js
    end
  end
end

Now, if you are really starting out, don’t start with this. Start with something MUCH simpler… maybe like this:

12	def newend

That would be a good gradient :)

No, seriously, if you just “don’t get RSpec”, then you skipped a gradient or went past something you don’t understand. Go back to an earlier gradient and come forward again.

I can say without a doubt that the #1 problem that new RSpec users have is code that tries to do too much.

Let the code evolve step by step from NOTHING and then come forward, the RSpec webpage has it right when it says “take very small steps”.

The skipped gradient problem is hard enough for experienced RSpec coders trying to fix an existing broken spec, but for someone who hasn’t understood the basics of how RSpec works, it is simply a killer. You don’t want to be wondering if your use of response.should have_tag(‘div’, 2) is correct when all the specs are not working and you have red failing tests everywhere… “Thar b’ dragn’s thar matey!”

If you run into this problem, then go make a new scratch app and start specing it from the ground up, with minimal code generation.

Something like this:

baci:test mikel$ ./script/generate rspec_controller welcome 
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/welcome
      exists  spec/controllers/
      exists  spec/helpers/
      create  spec/views/welcome
      create  spec/controllers/welcome_controller_spec.rb
      create  spec/helpers/welcome_helper_spec.rb
      create  app/controllers/welcome_controller.rb
      create  app/helpers/welcome_helper.rb

Now go into the spec/controllers/welcome_controller_spec.rb and check it out:

require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')

describe WelcomeController do

  #Delete this example and add some real ones
  it "should use WelcomeController" do
    controller.should be_an_instance_of(WelcomeController)
  end

end

Your standard RSpec template. This is good enough to start. We are going to build a welcome page here, so lets write our first spec:

describe "getting the home page of the site" do
  it "should be a success" do
    get :index
    response.should be_success
  end
end

And stop RIGHT THERE and run your specs, it will fail because no index action or template exists yet. Once it has failed, do the next smallest thing that could possibly pass. Write an empty index action:

1234	class WelcomeController < ApplicationController def index endend

And then run your specs, it will now pass. Good! Now you can start building on that stable datum of ‘it is passing now, if I add this one thing it should fail, then if I code this one thing, then it will pass again.’

While I am at it, ban the script/generate rspec_scaffold command from your development vocabulary until you know how to do every step in the code that the scaffold generates (and even then, the use is questionable). The great thing that the scaffold does is provide examples. If you are new to RSpec, you might be tempted to use the scaffold, I would recommend instead to make a scratch up, and use the scaffold there, and then use the code examples step by step in your own app building up your own specs.

This will give you a much broader understanding of how RSpec works.

Trying to spec some huge pre-existing code block as your introduction to RSpec is not impossible, but it is a pretty steep gradient and will result in more hair loss than passing specs.

blogLater

Mikel

Tip #25 - Logging is your friend...

2008-06-26T10:16:00Z

Sometimes when you need someone to just look over your code and figure out what the heck is going on, you can turn to your best coding friend, this friend sits away in the log directory carefully collecting data waiting for your beck and call…

Watch your log files.

This should sort of be obvious, but I know several people (including yours truly) who have been bitten by this one.

When you are running your specifications, keep a ‘tail -f log/test.log’ running. If you are on Windows and can’t do this, then either install cygwin so that you can, or make your system dual boot with Ubuntu or something so you can.

The logs will tell you a huge amount about what your app is trying to do when. This is especially true if you get a controller spec response along the lines of:

1)
'PeopleController handling GET /people should render index template' FAILED
expected "index", got nil
./spec/controllers/people_controller_spec.rb:54:
script/spec:4:

2)
'PeopleController handling GET /people/new should render new template' FAILED
expected "new", got nil
./spec/controllers/people_controller_spec.rb:60:
script/spec:4:

I expected the new template, but got nil… not very helpful…

But in the logs, the truth appears:

Processing PeopleController#index (for 0.0.0.0 at 2008-06-25 09:15:28) [GET]
  Session ID: 
  Parameters: {"action"=>"index", "controller"=>"people"}
Filter chain halted as [:must_login] rendered_or_redirected.
Completed in <snip> | 200 OK [http://test.host/people]

Processing PeopleController#index (for 0.0.0.0 at 2008-06-25 09:15:28) [GET]
  Session ID: 
  Parameters: {"action"=>"new", "controller"=>"people"}
Filter chain halted as [:must_login] rendered_or_redirected.
Completed in <snip> | 200 OK [http://test.host/people]

Ahh! Filter chain halted as the must_login method returned false! So we forgot to log in before we went to try and get the controller action.

Simple example, I know… but aren’t all the good tips simple?

Mikel

Tip #24 - Being clever in specs is for dummies

2008-06-24T14:37:00Z

This tip is coming to you from a frustrated developer having to read someone else’s specs….

RSpec is a wonderful tool.

In the right hands, it makes behavior driven development almost natural. It definitely makes producing readable specifications possible and allows you to stop focusing and worrying about writing your specifications, and just get on with life and livingness.

Another wonderful tool is the DRY principle.

The idea of the DRY (Don’t Repeat Yourself) principle is that every datum in your system that you are programming, and every procedure, should be defined and delimited to one location in your code / system structure. This is a wonderful principle that allows you later to make changes to your code with simplicity and aplomb, as you only have to look in location A to find all the code relating to A. You don’t have to look in A, then repeat your change 15 times in different locations in A all to fix one small part of the code.

You know unDRY code, you have all seen it. It’s like someone crossed a big 1980’s BASIC for loop with a code generator and let it loose in your app folder. It isn’t pretty and it is a pain to maintain.

However…

Being crispy DRY is the WRONG tool to apply to writing SPECS.

What do I mean?

Well, consider this (simple) controller example:

1234	it "should redirect if we are not logged in" do get :index response.should redirect_to login_pathend

Simple, this just ensures that the response from the server when we are requesting the index action in the current controller will be a redirect to the login page.

Now, we keep coding and we get:

it "should redirect if we are not logged in" do
  get :index
  response.should redirect_to login_path
end

it "should let us see the index if we are logged in" do
  session[:logged_in] = true
  session[:user_id] = 99
  get :index
  response.should be_success
end

it "should render the index template if we are logged in" do
  session[:logged_in] = true
  session[:user_id] = 99
  get :index
  response.should render_template('people/index')
end

Now, this is where the DRY-o-meter in your head starts going, “Err… Mikel, are you on drugs or what, why not put that logged in thing into a before call?!”

Why? Well, I think it is the wrong place for it, but to humour you, lets try that:

describe "when not logged in" do
  it "should redirect if we are not logged in" do
    get :index
    response.should redirect_to login_path
  end
end

describe "when logged in" do
  before(:each) do
    session[:logged_in] = true
    session[:user_id] = 99
  end

  it "should be a success" do
    get :index
    response.should be_success
  end

  it "should show the index template" do
    get :index
    response.should render_template('people/index')
  end
end

OK, now you DRY-gurus can cast an evaluative eye over that and grant it a stamp of approval.. except (you all say) that get :index is a bit of a give away, can’t we put that in the before call as well?

Well….err… yeah… I guess so… lets try that:

describe "when not logged in" do
  it "should redirect if we are not logged in" do
    get :index
    response.should redirect_to login_path
  end
end

describe "when logged in" do
  before(:each) do
    session[:logged_in] = true
    session[:user_id] = 99
    get :index
  end

  it "should be a success" do
    response.should be_success
  end

  it "should render the index template" do
    response.should render_template('people/index')
  end
end

THERE! you shout, THAT IS DRY!

And you are right, it is DRY, nothing is repeated.

But you know what? It is also unmaintainable and will be a nightmare in a few months when you look back on it.

Right now, it isn’t a problem, after all, it is only 22 lines of code and you can see everything, but sooner or later, that controller spec could get up to a few hundred lines line, and then you, my dry friend, are up the DRY creek without so much as a paddle. Because when you go to fix the line ‘it should redirect if we are not logged in’, you are going to have to go hunting up through the before call chain (which could be several levels deep) keeping track of instance variables, session state and any other cobweb that has been inserted in there, and find what in blazes is going on.

Of course the above example is simplistic. But I am sure you can agree that looking at a spec that tells you NOTHING about the context or scope it is running in is useful for a computer, and saves some hard drive space, but basically useless for you, and really, that is who matters, the programmer.

Here is a tip:

Before calls are to set up and clean up your testing environment, they are not there to setup up your testing expectations

Valid use of a before call? Making sure some directories that you are about to create in a test suite are not there. Valid use of an after call? Ensuring that the directories you made in the test suite are no longer there.

That is, anything that your program is not designed to handle or is not part of the specification, can go into the before or after calls….

N-O-T-H-I-N-G E-L-S-E

Get the drift?

It might seem harsh, but believe me, you will thank me when you are 6 months down the track and come back to it…

So, if you can’t use before and after, what are you to do? Well, the simple solution is to explicitly call inline helper methods… lets refactor our code above:

describe "when not logged in" do
  it "should redirect if we are not logged in" do
    get :index
    response.should redirect_to login_path
  end
end

describe "when logged in" do
  def given_a_logged_in_user
    session[:logged_in] = true
    session[:user_id] = 99
  end

  it "should let be a success" do
    given_a_logged_in_user
    get :index
    response.should be_success
  end

  it "should render the index template" do
    given_a_logged_in_user
    get :index
    response.should render_template('people/index')
  end
end

There.

Now, we have added 3 lines of code and made it much clearer. Why? Because now you don’t have to make the mental note of ‘oh, before this spec runs, I set the session params to log in the user’ instead, it is right there in the spec.

I have taken the given syntax from Story running, I like it. And further, you can just read that code.

When you come back to it in 6 months, you can look at it and instantly see what is going on, with NOTHING left out.

Anyway, end of rant… I’m off to refactor some 4 deep nested before calls….

blogLater

Mikel

Tip #23 - Know your fundamentals

2008-06-21T08:50:00Z

You would expect any professional to know their stuff, for a Ruby on Rails beginner, this is no less important.

One of the things I run into quite a bit is people simply not knowing enough about the underlying model of their database. Getting them to understand a has many through object relationship, is not going to get very far if they don’t know how an SQL database represents this.

Basics are what will make or break you as a programmer. You can know all the syntactic sugary beliefs out there, but without some hard won understanding of basic principles, you will be out in the cold as soon as some part of the program breaks in a new and unusual way.

Each subject has it’s basic fundamentals. For my Ruby programming, the fundamentals are defined in several key books (like the Pickaxe and the Ruby Programming Language and Design Patterns in Ruby). For Rails, you can’t really go past Agile Development and the Rails Way for key points. Each of these become like a ‘Bible’ to you when you are coding. Each programmer has their bible, it is interesting even that it is called a Bible, as in Christianity, the fundamentals of that belief system is contained in a book CALLED the Bible. My religion has a set of books that contain our core beliefs, we call them collectively, ‘The Basics’.

But a lot of Rails folks in their misguided ‘coding SQL is evil’ forget that underneath all that pretty ActiveRecord sugar are real, cold blooded, raw, writing SQL queries, automagically generated by our core team friends to attempt to leach from our databases the data we and our application so desperately need.

It’s all well and good to be able to type ‘person.phones’ and get an array containing all the phone numbers belonging to that person, but if you don’t know that in executing that statement, that an equivalent SQL query approximating “SELECT * phones WHERE person_id = 2;” is occuring, you my friend are in for some nasty surprises.

Just like me when I first discovered the has many through, I promptly made a call like paragraph.chapter.book.genre.words and wondered why my DB came to a screeching, painful halt, and my ruby instance blew straight through the available RAM and started playing friendly with my swap space… I did not understand what all those queries were doing and did not thinking with the size of the resulting dataset. The LEFT OUTER JOINS came to bite me… quite hard.

But SQL is a dry subject, not DRY that is, far from it actually, more like a moist sponge, but it is dry in that most of the materials you have to learn it are bland and quite factually boring.

But I found this book online, it has been around for a bit, I am not the first to discover it, but it is an introduction to SQL that I think almost any Rails developer should read. It covers the basics, where RDBMS’s came from, why you need two apostrophes to get one and how using SQL will get you better dates.

So I thoroughly recommend it. Head over to SQL for Web Nerds and have a good read.

blogLater

Mikel

Convert Visual Basic / Microsoft Long Integer Color Values to CSS RGB Format

2008-06-17T08:42:00Z

Here is how to convert the microsoft way of storing color values (which looks like 16777215 for white) into the familiar RGB CSS style HEX values (which look like #FFFFFF) in Ruby.

def long_to_rgb_hex_string(val)
  r = "%x" % (val % 256)
  g = "%x" % ((val / 256) % 256)
  b = "%x" % ((val / 65536) % 256)
  "#" + [r,g,b].collect { |c| c.to_s.ljust(2, '0')}.to_s
end

long_to_rgb_hex_string(2093422) # => #6ef11f

Or Grant Hutchins gave this as an option from the comments:

123	def long_to_rgb_hex_string(val) sprintf(’#%06x’, val)end

Any other good options? :)

blogLater

Mikel

It's amazing what you find...

2008-06-07T11:11:00Z

When you go looking for a postgres module for puppet…

Check this out…

I think it is a world wide critical problem…

The Smarties Ticket

blogLater

Mikel

RSpec Story xhr problem

2008-06-06T00:16:00Z

If you are using RSpec stories (and if you are not, why not?) you might run into this little problem. doing an xhr :post returns ArgumentError: wrong number of arguments (4 for 3)

This happens on a simple story like this:

When “I submit a search name” do xhr :post, ’/searches’, {:search => {:given_name => “bob”, :family_name => “smith”}} end

You will get in your story output, something like this:

ArgumentError: wrong number of arguments (4 for 3) stories/searching_story_spec.rb:45 in “I submit a search name”

But if you look in the above xhr method, I am only using 3 arguments, (1) a symbol [:post], (2) a string [’/searches’] and a hash [{:search => {:given_name => “bob”, :family_name => “smith”}}]

What gives?!

Looking in the test.log file doesn’t help either, as no exception is raised (which is weird)

Asking on the RSpec mailing list, Zach Dennis was good enough to give me the solution.

Use ‘xml_http_request’ instead.

Apparently, there is some problem with xhr being aliased to the wrong method somewhere internally…

Anyway, hope this helps!

Mikel

Tip #22 - How to ask a question about Rails

2008-06-05T12:20:00Z

This tip actually applies to every open source project out there… it is, how do you ask a question that will get you the maximum chance of a good answer?

The most successful thing I have found, is to make sure you convey that you have looked for the answer intelligently, and also attempted to resolve the problem in question to the best of your ability.

You should also show the code snippet in question, or if it is something you are bugged on, the basic steps you took to debug the problem.

If you do this, and then ask, you will be more likely to get an answer.

Including that you attempted to find the answer on google with what search is also a good idea, as you will be less likely to get “Google ‘Your problem’” as the answer.

Here is an interesting write up by people who have been helping other people for a long time, it is one of those things that I recommend a lot of people to read, and so I’ll link it here as well.

blogLater

Mikel

Tip #21 - Developer Info On Every Page

2008-06-03T15:06:00Z

When you are making a rails site, you sometimes need to get to the session hash or the params hash and see just what got sent back to the browser, but going in, editing the template and reloading is just a PITA, here is a quick tip that can help you have that (and any other) information no more than a click away, at any time, and any view….

What we need to do is be able to show, on any page in our site, some quick Developer Information.

What I wanted is a little link at the bottom right of every page called “Developer Information” and if I click it, I get a screen popping up with all the information I need, that I could then hide away again.

I had a need for this on a site I was making, and in true Ruby style, I thought “What is the simplest thing that could work?” Well, I think this is about it.

First, make a file in your /app/views/common_partials folder called ‘_developer_info.html.erb’

Into this, throw the following:

<a id="DevInShow" href="#" 
   style="font-size:small;position:absolute;bottom:10px;right:10px"
   onclick="$('DevInfo').show(); $('DevInShow').hide();">
 Show Developer Info</a>

<div id="DevInfo" 
     style="background:white;padding: 5px;
            border:10px solid red;position:absolute;
            top:0px;left:0px;display:none">

  <a href="#" 
     onclick="$('DevInfo').hide(); $('DevInShow').show();">
  Hide Developer Info</a>

  <h1>Params</h1>
  <pre>
    <%= params.to_yaml %>
  </pre>
  <h1>Session</h1>
  <pre>
    <%= session.to_yaml %>
  </pre>
  <a href="#" 
        onclick="$('DevInfo').hide();$('DevInShow').show();">
  Hide Developer Info</a>
</div>

The above code sets up a hidden div in your view with a link at the bottom right. When you click the link it makes the hidden div visible (which is absolutely positioned over the top of all your content) and gives you a link to click it away again. Neat.

Now, to make all this Rails-foo goodness work, add the following to the very bottom of your application.html.erb file, just before the </body> tag is good.

123	<%- if RAILS_ENV == "development" -%> <%= render :partial => 'common_partials/developer_info' %><%- end -%>

This renders the developer info link, only in development mode, just to be safe :)

Of course, you will want to remove this from your pages when you go live, but it is really handy when you are debugging session or params movements in your code.

Enjoy!

blogLater

Mikel

And now for something completely different...

2008-06-02T00:11:00Z

Found this video clip while bouncing around the interwebs ™

It is a stop motion clip of the making of a stop motion clip…. spooky…. but very cool!

blogLater

Mikel