My Notes - thinksimple.pl

Naming things

Sat, 23 Jul 2011 06:28:30 GMT

Am I obsessing over naming things? Is it really that much of a difference if I say loc instead of location? For a local variable? In a ~10LOC method? Yes, it occupies a part of my brain, and it’s slightly annoying once you get used to having everything pretty, but is it worth nitpicking and deny someone a few saved keystrokes?

As I’m typing this, I have already realised what the answer is. Yes. Yes it is worth it. Because the writer only writes it once, but the reader reads it multiple times. Maybe hundreds of times. And every single time this small part of the reader’s brain is occupied with decoding the variables, what the cryptic name stands for and what the variable contains. Overtime, it adds to productivity loss. Greater than saving those keystrokes. Long term, it’s not worth it. Short term… If you’re coding for short term only, then you’re either lucky, or mistaken. Probably the latter.

Capybara, Selenium and SSL

Mon, 14 Mar 2011 21:22:40 GMT

I’ve been looking for a way to get Selenium set up with Capybara. We have a fairly standard dev config, nginx with passenger running the site, Rspec for unit tests, Capybara for integration tests. One bit that was missing was Javascript tests, so I decided to give it a go with Selenium.

First of all, Selenium did not like me trying to log in with SSL. To be honest, it wasn’t really Selenium as much as Webrick which Capybara starts for Selenium. I kept getting ssl_error_rx_record_too_long. Solution: let nginx deal with the SSL bit of the communication and send through a simple HTTP request to Webrick. Bonus points for setting a header which tells Rails that initially it was an SSL request.

Next up: database issues. Our tests rely on two things: seed data and transactions. The idea is to get the seed data in the db and then run each test within a transaction so that it’s quicker to reset. Unfortunately Selenium opens a new database connection, and a new transaction to go with it. Solution: database_cleaner. Strategy – truncation, as mentioned on numerous websites… Oh wait, leave the seed data in! You can pass an :except option to DatabaseCleaner, except that you then can’t create models which are seeded as they will just stay in the db. Oh well, Truncation and loading seeds before each test it is. After painful waiting for the test suite to finish (28min instead of the usual 10) it was clear that this is not a sensible solution. So I tried switching strategies in between tests, from transaction for most tests to truncation for Selenium tests. Worked like a charm.

Lastly, a minor thing compared to everything else – did you know that fixtures are cached? Well they are. So if you try loading them again while running the tests it won’t work. Need a special fix for that.

All in all, it was a painful experience. Below is the code I used, some of it will be deprecated once new Capybara is out, and I might have omitted something accidentally. If so, let me know in the comments. Other than that, enjoy!

nginx.conf:

http {
  # your usual server config goes here

  upstream testing {
    server 127.0.0.1:9000; # Capybara will start Webrick on this port
  }

  server {
    listen 80;
    server_name myapp.testing;
    location / {
      proxy_pass http://testing;
      proxy_set_header Host $host;
    }
  }

  server {
    listen 443;
    server_name myapp.testing;
    location / {
      proxy_pass http://testing;
      proxy_set_header Host $host; # forward the host so that urls use this
      proxy_set_header X_FORWARDED_PROTO 'https'; # this is how Rails finds out if it's an https request
    }
    ssl on;
    ssl_certificate /etc/ssl/certs/myssl.crt;
    ssl_certificate_key /etc/ssl/private/myssl.key;
  }
}

Gemfile

  gem "capybara"
  gem "database_cleaner"

spec_helper.rb

  config.use_transactional_fixtures = false

  config.before(:suite) do
    DatabaseCleaner.strategy = :transaction
  end

  config.before(:each) do
    DatabaseCleaner.start
  end

  config.after(:each) do
    DatabaseCleaner.clean
  end

  Capybara.server_port = 9000
  Capybara.app_host = 'http://myapp.testing'

We also have a special integration_helper.rb included only in integration tests. The DatabaseCleaner mess is to make sure switching from transaction to truncation and vice versa works without any issues.
integration_helper.rb

  config.before(:each) do
    if example.metadata[:js]
      DatabaseCleaner.clean
      DatabaseCleaner.strategy = :truncation
      Capybara.current_driver = :selenium # this can be removed with new Capybara release
    end
  end

  config.after(:each) do
    if example.metadata[:js]
      DatabaseCleaner.clean
      load "#{Rails.root}/db/seeds.rb"
      DatabaseCleaner.strategy = :transaction
      DatabaseCleaner.start

      Capybara.use_default_driver # this can be removed with new Capybara release
    end
  end

You only need this bit if you’re using YAML fixtures/seed data and somewhere in your code you say something like Fixtures.create_fixtures(seed_dir, table).
db/seeds.rb

Fixtures.reset_cache

Rspec integration test

  it "works with Selenium", :js => true do
    visit root_path
  end

Authlogic gotchas

Tue, 22 Feb 2011 19:28:26 GMT

There are two. First one: Authlogic assumes that you want to log your users in with http basic authentication. If you have a staging server protected by basic auth you will get random SQL queries with “WHERE email LIKE LOWER(your_http_auth_login)”.

Solution:

class UserSession < Authlogic::Session::Base
  allow_http_basic_auth false
  # ...
end

Second one: Authlogic provides its own email validation. If you’re using rails3_acts_as_paranoid the deleted_at field will not be taken into account. Resulting in validation errors for emails that exist, but the account has been deleted.

Solution:

class User < ActiveRecord::Base
  acts_as_authentic do |c|
    c.validate_email_field = false
  end

  validates_uniqueness_of :email, :scope => :deleted_at
end

Fixed.

Git Extras

Wed, 15 Sep 2010 18:42:54 GMT

There’s a fantastic tool on Github – Git Extras. Its readme tells you everything you need to know, but just to give you a taste, here are my favourites:

$ git release 0.1.0

Create a commit and tags it.

$ git delete-branch branch_name

Delete local AND remote branch

$ git undo [number]

Undo one or more commits. Internally does git reset --HARD

$ git commits-since [date]

Lists commits since a specified date, or last week

$ git summary

See who created the most commits in your project

Enjoy!

Vim commands for developers, Part 2

Sat, 18 Sep 2010 07:08:33 GMT

The longer I work with Vim, the more great stuff I discover. Here’s another chunk.

Did you know there are so many ways to go to insert mode?

i, a – insert before/after current character
I, A – insert at the beginning/end of the line
O, o – insert a line before/after current line
gi – go to Insert mode where you last stopped editing

Behold – Folding!

zf – fold selected block
:{range}fo[ld]
zo – open fold
:{range}foldo[pen]

Ever changed your .vimrc and had to close Vim to load it? Well no need for that any more!

:source $MYVIMRC

And our plugin of the day is… NERDTree! NERDTree is a project file browser, very useful!

Commands:

:NERDTree [start-dir|bookmark]  # opens NERDTree
:NERDTreeToggle [start-dir|bookmark]
:NERDTreeClose
:NERDTreeFind  # find current file in tree

o, go # open / open and leave cursor in NERDTree
t, T  # open in new tab / open in tab and keep focus on current tab
i, gi # split window
s, gs # vsplit window

Also – you do know about Pathogen, right?

If you missed out on Vim commands for developers, Part 1, here it is.

Useful Vim commands for developers

Thu, 17 Jun 2010 14:41:00 GMT

UPDATE: There’s now Vim commands for developers, Part 2 available!

I’m always on the look for new Vim tips and tricks, so here’s a new lot. Most of them are from this presentation but these are the ones I want to start using.

Marks

m<letter> – bookmark named letter
`<letter> – jumps to that bookmark
'<letter> – jumps to line with the bookmark
:marks – show current marks

Handy example:

ma #=> set a mark
c`a #=> change text from cursor to mark a
d`a #=> delete text from cursor to mark a
y`a #=> yank text from cursor to mark a
=`a #=> reformat lines from current to the one with mark a

`` – moves you between the last two locations

Text objects

They are complicated things which I probably thought I will never need, so here’s a Vim help link: :help text-objects. One useful tip:

ci{ – change text inside {} block
Or, obviously, di{, yi{, ci( – you get the idea.

Undo – simple version

u – undo
CTRL + R – redo

Complex version: If you undo something and make a change, a new branch is created, so then you can do this:

g-, g+ – go to newer/older text state (through branches)
:earlier Ns,m,h – go to text state as it was N seconds/minutes/hours ago
:later Ns,m,h
:undolist – lists changes

Tabs

gt, gT – move around tabs

Completion

There are many types of completion and you can read about them under :help completion, but this is probably most useful:

CTRL + N – complete with keywords in the current file

You can also use omnicompletion, triggered by CTRL + X CTRL + O, but it doesn’t seem to be working for me.

Open file under cursor

gf, that’s easy. However, you can also do this: CTRL + W, CTRL + F and bang! split window open. This alone is the best tip in this post.

Ruby static code analysis

Sat, 08 May 2010 09:04:00 GMT

Today I’d like to show you four tools for Ruby code analysis. I’ll look at my Rails app written over two years ago, when I was just starting to learn Ruby and Rails – there is a lot to fix there.

Flog

sudo gem install flog

Shows the most complicated code you have written. The more complex the code, the higher the score, and the harder the code is to test. Here’s my result:

$ flog app/controllers/*.rb
  1045.2: flog total
    12.6: flog/method average

    68.5: EntriesController#search         app/controllers/entries_controller.rb:80
    39.6: CommentsController#destroy       app/controllers/comments_controller.rb:91
    38.6: EntriesController#search2        app/controllers/entries_controller.rb:64
    37.0: CommentsController#create        app/controllers/comments_controller.rb:49
    35.1: EntriesController#json           app/controllers/entries_controller.rb:176
    34.3: EntriesController#update         app/controllers/entries_controller.rb:47
    33.2: SessionsController#create        app/controllers/sessions_controller.rb:8
    33.2: EntriesController#advanced_search app/controllers/entries_controller.rb:115
    31.4: EntriesController#create         app/controllers/entries_controller.rb:13
    29.0: ProjectsController#update        app/controllers/projects_controller.rb:60
    27.5: EntriesController#archive        app/controllers/entries_controller.rb:137
    27.3: TagsController#update            app/controllers/tags_controller.rb:48
    26.0: ProjectsController#create        app/controllers/projects_controller.rb:43
    21.9: TagsController#show              app/controllers/tags_controller.rb:21
    21.6: TagsController#index             app/controllers/tags_controller.rb:9

EntriesController#search method is 27 lines long and includes looping over all entries and doing a regex comparison on every single one. Definitely a candidate for refactoring.

Flay

sudo gem install flay

Flay looks for structural similarities in the code, ignoring whitespace, variable names and some other changes. A sample result looks like this:

$ flay app/controllers/*.rb
Total score (lower is better) = 907                    


1) Similar code found in :defn (mass = 108)
  app/controllers/projects_controller.rb:77
  app/controllers/tags_controller.rb:66

2) IDENTICAL code found in :iter (mass*2 = 96)
  app/controllers/entries_controller.rb:16
  app/controllers/entries_controller.rb:51

3) Similar code found in :defn (mass = 90)
  app/controllers/comments_controller.rb:22
  app/controllers/projects_controller.rb:16

4) Similar code found in :iasgn (mass = 81)
  app/controllers/comments_controller.rb:9
  app/controllers/tags_controller.rb:10
  app/controllers/users_controller.rb:25

5) Similar code found in :if (mass = 56)
  app/controllers/entries_controller.rb:88
  app/controllers/entries_controller.rb:92

Flay marked a similarity in ProjectsController and EntriesController, and the similarity is the automatically generated destroy method. Not very helpful.

However, the identical code listed is assigning tags to an entry in create and update methods, and it is indeed identical. Well spotted.

Heckle

sudo gem install heckle

Heckle is a piece of really mean software. It takes your code, takes your tests, and then changes your code to see if the tests really fail. It works with Test::Unit or RSpec tests.

Unfortunately, I wasn’t able to run heckle on my current codebase, for one thing, because it doesn’t have any sensible tests (I was learning, OK?), and also because I broke my gems and now it doesn’t recognize ActiveRecord class.

Reek

sudo gem install reek

Finally, a tool for detecting code smells. Reek tells you exactly what is wrong with your code, and you better fix it. This is a sample output:

$ reek app/controllers/entries_controller.rb
app/controllers/entries_controller.rb -- 33 warnings:
  EntriesController has no descriptive comment (IrresponsibleModule)
  EntriesController#advanced_search calls entry[:content] twice (Duplication)
  EntriesController#advanced_search calls entry[:tags] twice (Duplication)
  EntriesController#advanced_search calls entry[:title] twice (Duplication)
  EntriesController#advanced_search has approx 10 statements (LongMethod)
  EntriesController#advanced_search refers to entry more than self (LowCohesion)
  EntriesController#archive calls month.nil? twice (Duplication)
  EntriesController#archive calls params 3 times (Duplication)
  EntriesController#archive has approx 11 statements (LongMethod)
  EntriesController#create calls params 4 times (Duplication)
  EntriesController#create calls params[:entry] 4 times (Duplication)
  EntriesController#create has approx 9 statements (LongMethod)
  EntriesController#create has the variable name 't' (UncommunicativeName)
  EntriesController#json calls params 6 times (Duplication)
  EntriesController#json calls params[:count] twice (Duplication)
  EntriesController#json calls params[:tag] twice (Duplication)
  EntriesController#search calls params 5 times (Duplication)
  EntriesController#search calls params[:search] 5 times (Duplication)
  EntriesController#search calls params[:search].downcase 3 times (Duplication)
  EntriesController#search contains iterators nested 2 deep (NestedIterators)
  EntriesController#search has approx 13 statements (LongMethod)
  EntriesController#search2 calls Entry.published 3 times (Duplication)
  EntriesController#search2 calls params 8 times (Duplication)
  EntriesController#search2 calls params[:search] 4 times (Duplication)
  EntriesController#search2 calls params[:tags] twice (Duplication)
  EntriesController#search2 calls params[:title] twice (Duplication)

I get it, I get it, tons of duplication and horribly long methods. Let me do some refactoring now…

(Thanks to Tomash for his presentation)

Multiline step arguments with Cucumber

Fri, 25 Sep 2009 07:37:55 GMT

I’ve been doing lots of Cucumber testing lately and I must say, it’s a great tool. I have stumbled upon one problem though, which are multiline step arguments. The Cucumber wiki covers most cases, but what happens when the HTML list or table you want to check is not a proper table, but just some divs, mixed with tables and/or uls?

There is a pretty easy way to do this. Cucumber History.txt file says that table_at method is deprecated, and we should use element_at instead. Also, element_at takes a CSS selector as an argument. So we can just choose any container element from the HTML, pass it to Nokogiri, and get an array of text.

Example: if we had this HTML code

<div id="search_results">
  <% @people.each do |person| %>
    <div class="result">
      <div class="image"><img src="/img/default.png" /></div>
      <div class="information">
        <ul>
          <li class="name"><%=h person.name %></li>
          <li class="email"><%=link_to h(person.email), "mailto:#{person.email}" %></li>
          <li class=""></li>
        </ul>
      </div>
    </div>
  <% end %>
</div>

and we wanted to check if the search results are what we expect, we could write a Cucumber step that looks like this:

Then /^I should see the following search results$/ do |searches|
  search_results = element_at('div#search_results')
  node = Nokogiri::HTML("<html>#{search_results.element}</html>").css('.information ul li.name')
  actual_table = node.map { |name| name.inner_html.strip }
  searches.diff!(actual_table)
end

and call it like this:

Then I should see the following search results
  | John  |
  | Mike  |
  | Susan |

Done!

AJAX pagination with Javascript

Fri, 14 Aug 2009 07:48:56 GMT

Ryan Bates did an excellent Railscast about pagination with AJAX. I’d like to take it one step further and explain what to do when you want some Javascript functionality in the pagination partial.

Let’s just go with something easy: say you want to highlight clicked products instead of continuing to the show product page. We’ll create a file called highlights.js:

// highlight.js
$(function() {
  function on() { 
    $(this).css('background-color', 'yellow'); 
    return false;
  }

  function off() { 
    $(this).css('background-color', 'transparent'); 
    return false;
  }

  $('.product h3 a').live('click', function() {
    $(this).toggle(on, off);
    return false;
  });
});

Remember to include the file, we can do this in index.html.erb, right below including pagination.js

<% # index.html.erb %>
<% title "Products" %>
<% javascript "pagination" %>
<% javascript 'highlights' %>

<% # more code here... %>

Okay, let’s try it out. First click… Oops, nothing happens. Second click – background turns yellow. Third click – background turns back white. Maybe second page will be better. First click – nothing happens. Second click – there it is, yellow. Third click – white again.

Everything works except for that nasty first click, where did this come from?

Remember when we did this:

$('.product h3 a').live('click', function() {
  $(this).toggle(on, off);
  return false;
});

What this live thing does is bind a click event to all selected elements. The problem is that toggle does exactly the same thing. So when we click for the first time, the toggle method is run for the first time, and therefore it doesn’t toggle anything, it just binds another click event. From then on everything works like it should. The simplest solution would be to call toggle right after live:

$('.product h3 a').live('click', function() {
  $(this).toggle(on, off);
  return false;
});

$('.product h3 a').toggle(on, off);

First page – great, works! Second page – oh crap! Apparently everything that’s in the highlight.js file has been done just once on the initial page load, and that includes the toggle line we have just added. It should be done every time you change the page, because there are new links that need to have the click bound. If so, how about adding the toggle line into index.js.erb?

$("#products").html("<%= escape_javascript(render("products")) %>");
$('.product h3 a').toggle(on, off);

Trying the second page – my Firebug says “on” is not defined. That gives me an idea. Let’s change our highlights.js file to this:

function on() { 
  $(this).css('background-color', 'yellow'); 
  return false;
}

function off() { 
  $(this).css('background-color', 'transparent'); 
  return false;
}
  
$(function() 
{
  $('.product h3 a').live('click', function() {
    $(this).toggle(on, off);
    return false;
  });

  $('.product h3 a').toggle(on, off);
});

The on and off functions are now defined regardless of whether the page is ready or not. Check it again – tadaa!

Ok so just to sum up what we need to do from Ryan’s final code:

create highlights.js with this content
link to highlights.js in index.html.erb
call toggle in index.js.erb

And actually, while we’re at it, we might remove the live call altogether. We need to bind the click event on our own each time anyway, so this is not needed anymore. So the final highlights.js looks like this:

function on() { 
  $(this).css('background-color', 'yellow'); 
  return false;
}

function off() { 
  $(this).css('background-color', 'transparent'); 
  return false;
}
  
$(function() 
{
  $('.product h3 a').toggle(on, off);
});

And you know what, I’m just going to say it. AJAX pagination sucks.

Bye bye Prototype!

Mon, 27 Jul 2009 07:03:46 GMT

I’ve been struggling for a couple of days to make a javascript carousel. Or, to find a library that does that. There are a ton of scripts out there, just grab one of ‘em and let’s get started!

Ughhh. Little or no documentation. Incomplete examples. Lots of HTML and CSS just to have the same thing as in the example and it still doesn’t work. Seriously, is it really that big? In the meantime I saw this page, Top 10 JS Carousels and Sliders. Out of those 10, 5 (namely: five!) were written in jQuery and only two in Prototype.

So today I gave up. I installed jrails. And tried out jCarouselLite as jCarousel seemed too big for my needs. And guess what? I got it up and running in about 10 minutes, including downloading, skimming documentation and updating my HTML (actually, removing all unnecessary markup needed by previous libraries). Worked like a charm. Also, now I’m really really angry that Rails makes you use Prototype by default.

You can see the result on my projects page.