Something about TDD I never expected.

There is one thing I have always thought about programming, is that to do it, you need a couple of hours and to sit down and get in the zone. You really have to settle in and let it absorb you.

This is a bit of a problem when you have just an hour or less to spare because you know just as you actually get what the piece of code does, you need to give up and set off.

However, with test driven development, I can sit down, run bundle exec guard (A gem that runs all my specs for me when a file changes) and if I finished last while writing spec, I will put a spoof method like ENDED_HERE in the code, and it will flash up, or if tests fail, then I can jump straight to the piece of code that breaks.
I can sit down for just 10 mins at a time and make it pass a couple lines of spec and push up the code and go to work/lunch/friends/pub as needed.

Stumbling blocks

I've been bumbling through a few self-made hurdles the last few days and they all unraveled when I sat an unknowledgeable friend next to me and spoke at him as I worked through my problem. This is what I call the rubber duck method.

New knowledge 1)
@thing.user_id = User.find_by_email(params[:legitimate_user_email])
The flaw here is that I this caused me a really hidden error.
I thought assigning it to a user would use the ID since that is how the models for each of these is linked together, but instead it kept returning ID1 instead of throwing an error.
@thing.user_id = User.find_by_email(params[:legitimate_user_email]).id
WOW that was a simple flaw but it didn't show up because it threw no error.
I was almost defeated by 3 letters and I have never been so embarrassed.

New knowledge 2)
Redirect_to :back
the :back parameter is really cool. I was passing a param back to the controller to know where to redirect my users back to, which was causing me to use POST and GET params at the same time, when I could have used :back all along. Code is now prettified and users now cannot redirect themselves to nasty places using an obvious param in the url.

New knowledge 3)
rake db:drop db:create db:migrate db:seed db:test:prepare
I should have a macro for this or something. Saves me time and attention knowing I can chain rake tasks now. Minutes are saved every day.

New knowledge 4)
before_filter do |c|
    c.send(:authorize, "admin")
end
Passing params to the before_filter method is really quite awesome and very helpful if you are writing your own permissions from scratch. I had no idea what I was going to do to get round this as there was no way I was going to explicitly name every method. I would miss my deadline by months even attempting it.

New knowledge 5)

require 'rubygems'
require 'factory_girl_rails'
Loading a gem for local use in a file is not only useful when you want to use a gem outside its intended scope, but apparently there are optimization benefits in loading the gem only when needed too! (according to someone on stack overflow, but I haven't tested it and he also said it was a maintenance nightmare!)

New knowledge 6)
Rails.root.join('folder','file_in_folder.rb')
The cross platform version of  "%Rails_root%/folder/file_in_folder.rb"
Both allow you to rummage around anywhere inside of your own rails directory but the first works on operating systems that do not use '/' as a separator.

Altogether, I'd say this has been a massively successful week. I've been using I18n.translate aka t ("some.location.in.config.locale_name.yml") which is extremely cool, and I'm expanding my use of capybara and TDD.
Now I write it down, I am learning quite a lot in a short amount of time.

Edit:
New 7)
I didn't think it was from this week as it seems so long ago, but commit logs say otherwise.
<%= collection_select("group", "permission_id", @permission, "id", "name") %>
Selecting from a collection is fun, I'm not sure if it is badly documented or I was looking for all the wrong keywords.

Seeding the Test Database

Edit: this post was edited with new information as it was found. As such it is a mess. There are two solutions to loading the same seed data in test as the other environments: Loading your seeds.rb from factories in the spec, or loading your seeds into the testing environment. I prefer the first option as you get to make your seeds with FactoryGirl and it gets validated and if you are loading your seeds in spec, you need to call the method to load it before(:all) every time.

I was wondering why some of my tests were not passing after a Rake db:test:prepare
Turns out it clears the database, and the only way I have to get it back using the seeds.rb file is with RAILS_ENV="test" Rake db:seed which seems cumbersome and not really railsy at all.

As a bonus, after I run RAILS_ENV="test" Rake db:seed, I then fail a lot of tests. It seems that seeding the test database breaks FactoryGirl's creates.

Is there a way for me to have my seeds and test them?

At the moment I am looking into ways to get seeds.rb to load a FactoryGirl method that I can use to also populate the test database separately. That seems like an easier approach to loading my seeds.rb into FactoryGirl as it causes already passing tests to fail and behave differently in test to development which is obviously bad.

Asking others seemed a good idea:
http://stackoverflow.com/questions/9861075/how-can-i-load-seeds-rb-into-the-test-database-without-breaking-factorygirl

But in the end I managed to weedle out 2 possible answers myself:

1) Loading Seeds from Spec

In Spec/helpers.rb:

def seed_data
require Rails.root.join('db', 'seeds.rb')
end

2) Loading Spec from Seeds

In Seeds.rb

require Rails.root.join('spec', 'helpers.rb')
require 'rubygems'
require 'factory_girl_rails'
seed_data

In Spec/helpers.rb

def seed_data
  Factory.create(:admin)
  #Create all your objects
end

Rails on Logging Passwords

I was just reading through security issues for my app as it is good to do from time to time, just to keep on my toes when I spot this:
"By default, Rails logs all requests being made to the web application. ... Encrypting secrets and passwords in the database will be quite useless, if the log files list them in clear text."


I immediately jump to my development.log to check out if my passwords are showing and lo and behold on line ~1000
"Parameters: {"utf8"=>"✓", "authenticity_token"=>"8DznfYV1t1Mb+S/3MzMaZ9Clf/FuO894UkYFoBfu0Ug=", "user"=>{"email"=>"a@a.a", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]", "language"=>"en"}, "commit"=>"Created User"}"

Thank you Rails 3.2 !


Note1:
If your passwords are not hidden, the fix should be something like the following line:
config.filter_parameters << :password

Note2: It looks like by default Git does not push up log files in Rails, but you should double check all your public Github log directories just in case

Making Heroku like PG ( whether it likes it or not)

Sometimes my Heroku DB will completely derp on me and go "NOPE" and not even a Heroku Run rake db:migrate will fix it.

Generally what I then proceed to do is use this sledgehammer for the task.
heroku pg:reset DATABASE_URL --confirm theashvale

You should then be able to re-create and re-migrate the database as desired.

This is really taking a sledgehammer to it though as all your data will be lost but it is nice to be able to start from scratch now and again.

A Newfound Love of Testing

So I will say it from the start, I dislike cucumber with a passion. It just feels like another language I need to write, then I end up writing code to "pass" my tests where I actually end up testing my tests using the code I would have originally wrote.

This meant that all that happened was I sat in the back of lectures thinking "Nope Nope Nope", and that it would just double my work load.
On top of that, cucumber-rails has the added bonus of breaking all machines running windows. Not really an appropriate tool to pick to teach us TDD on windows university PCs with.

Then along came capybara.
The great thing is you can basically write all your tests as variations on a few commands.

• Click_on "some_button_id"
• Page.should have_content  "some #{dynamic} content" 
• visit some_path
• current_path.should eq some_path
• fill_in "field name", :with => "some #{dynamic} content"

That is pretty much it. With capybara, it is like sitting behind someone telling them what to do, it is no longer complicated or cumbersome and your testing doesn't need to be complicated buggy code of its own. It is REALLY simple and I like it. I like it a lot. It even encourages you to make your HTML better documented as if there is a page with a hundred DELETE buttons, you don't want to accidentally click on the one for yourself.

Mix it with Factory_Girl and you are flying in seconds!

A small note on gem dependencies.

It is sad that a really cool gem like Twitter-Bootstrap-Rails depends on Less-Rails, it is in turn that Less-Rails depends on Less, and it is a shame that Less depends on Libv8, and again that Libv8 depends on JS gems other than execjs.
This means that it does not autodetect a javascript engine like nodejs which means that they chose a specific gem (therubyracer) that only works on linux.

This chain of dependencies is unavoidable, I know. And less seems quite cool though I prefer the meta-programming like scss way more, but forcing gems built on gems build on therubyracer locks it unavoidably to mac or linux.

Edit:

Turns out there is a version of Twitter-Bootstrap that uses static CSS, which can be used with this in your gemfile: gem 'twitter-bootstrap-rails', :git => "git://github.com/seyhunak/twitter-bootstrap-rails.git", :branch => "static"

I don't really like ANSICON...

... infact, it is so bad, it is the reason I started using Linux.

JSON breaks on bundle install after ever having using Ansicon.

See Ansicon puts an autorun or autoplay value in your registry somewhere around a couple locations making a really obscure "Native Extensions" error which took a long time to track down using even my google-fu.
Just delete any autorun/play thing if they are there.

HKEY_CURRENT_USER\Software\Microsoft\Command Processor 
HKEY_ LOCAL_MACHINE\Software\Microsoft\Command Processor