Orban Botond's Blog

RSpec before hooks

2017-05-08T18:58:00.001+01:00

I assume that everybody is familiar with the famous ruby testing framework rspec.

Let's say that we have this spec structure:

require 'rails_helper'

describe 'search_index' do
context 'entity A' do
let(!setup_a){ create :a}
...
before do
SearchIndex.delete! rescue nil
SearchIndex.create
SearchIndex.import
end
...
end
...

context 'entity B' do
let(!setup_b){ create :b}
...
before do
SearchIndex.delete! rescue nil
SearchIndex.create
SearchIndex.import
end
...
end

end

As we see the before blocks are the same. Some might be tempted to move to a common place.

Let's do this:

require 'rails_helper'

describe 'search_index' do
before do
SearchIndex.delete! rescue nil
SearchIndex.create
SearchIndex.import
end

context 'entity A' do
...
...
end
...

context 'entity B' do
...
...
end

end

At this moment we experience a surprise the the tests are not passing...
If we take a closer look we can easily identify the spot.
The import in the before blocks was run before the setup_b and setup_a was called. So there was nothing to import therefore our expectations run on an empty index.

In this particular case it was much more beneficial to leave the common code where it is.
But wait... Aren't we dealing with a ruby code? Yes of corse. This means that the content of the before can be extracted into a function then called before any context.

require 'rails_helper'

def reinitialise_the_index
SearchIndex.delete! rescue nil
SearchIndex.create
SearchIndex.import
end

describe 'search_index' do
context 'entity A' do
let(!setup_a){ create :a}
...
before do
reinitialise_the_index
end
...
end
...

context 'entity B' do
let(!setup_b){ create :b}
...
before do
reinitialise_the_index
end
...
end

end

Much simpler isn't it?
Happy coding :)

Available at Toptal

2015-06-05T14:55:00.001+01:00

Hi,

I would like to announce that I joined total.

I am available for hire at:
http://www.toptal.com/ruby-on-rails#efficient-professional-web-development

The benefit of the squeel gem over standard active record

2015-05-06T17:32:00.001+01:00

The benefit of the squeel gem over the standard active record

Let's try this query:
Field.where(id: 10).unscope(where: :id)

It results in the below SQL:

"SELECT \"fields\".* FROM \"fields\"

Let try to unscope something a bit more difficult:
Field.where('id > 10').unscope(where: :id)
In this case the unscoping didn't work as we intended:

SELECT \"fields\".* FROM \"fields\" WHERE (id > 10)

Let's try now by using squeel gem:
Field.where{id > 10}.unscope(where: :id).to_sql
Now the unstopping works just as we intended:

"SELECT \"fields\".* FROM \"fields\""

Enjoy :)

2015-01-16T09:41:00.002+00:00

Testing the ActiveRecord models using Rspec

Usually the skeleton of my models spec looks like this:

require 'spec_helper'

describe Car do

context 'class hierarchy' do
#Here comes the class hierarchy specification
end

context 'fields' do

#test the enumeration of used fields

end

context 'assotiations' do
#Here comes the enumeration of associations
end

context 'validations' do
#Here comes the validation of models
end

context 'callbacks' do
#Specs for callbacks
end

context 'methods' do

#specs for methods

end

end

Testing the class hierarchy:
Since the model could include modules which affect the functionality I consider it necessary to assert on them.

describe Car do
context 'class hierarchy' do
specify {expect(subject.class).to be < ActiveRecord::Base}
specify{expect(subject).to be_kind_of(Elasticsearch::Model)}
specify{expect(subject).to be_kind_of(Elasticsearch::Model::Callbacks)}
end

end

Testing the fields:
I often encountered errors when the model was expected to have a field and that field was missing. So I always assert on the used fields:

describe Car do
context 'fields' do
specify {expect(subject).to respond_to(:name)}

specify {expect(subject).to respond_to(:filter)}

end
end

Testing the associations:
I test the presence of the correct associations using the 'shoulda-matchers' gem.

describe Car do
context 'assotiations' do

specify { expect(subject).to belong_to(:user) }
specify { expect(subject).to belong_to(:manufacturer) }
end
end

Testing the validations:
I usually test the validations of the fields using the 'shoulda-matchers' gem.

describe Car do

context 'validations' do

specify { expect(subject).to validate_uniqueness_of(:filter).scoped_to(:manufacturer_id)}

end
end

Testing the callbacks:
My callback test usually are like this:

describe Car do
context 'validations' do
context 'before_destroy' do

specify 'call destroy like callback'do
expect(equipment).to receive(:destroy_likes)
equipment.destroy
end
end

end

Testing the methods:
Usually I test the methods by calling it the asserting that all the necessary changes are made. I do this for all the execution paths.

2015-01-15T15:06:00.000+00:00

Api Development in Ruby On Rails

Recently I wrote a series of blog posts about the best practices of API development in RoR and how to develop API in general.

Let me summarize those posts:

Happy API development :)

2015-01-15T14:55:00.001+00:00

API development in Rails error path

In my series of of API development I haven't covered the error handling.

Let me share my experience with you about what I have learned about proper error handling.
I call error path the case when the user can't achieve what he wants.

This case can happen by the following reasons:

The user calls an invalid url
The user addresses a missing resource
The user misses a mandatory parameter
The uses passes a wrong parameter
Some other internal error occurs
...

Since thousands of calls can be made daily or hourly against the API there is no way to stop the server and debug it. So all the information related to the erroneous call must be recorded. Basically all the information to reproduce the error must be recorded. I call this ApiCallAudit.

Such an ApiCallAudit must contain:

All the incoming parameters
The type of call (GET, POST, DELETE, ...)
cookies
backtrace
created_at

I added some additional fields to it for filtering purposes:

level. It serves to quickly determine the possible source of errors. It could be parameter_error, unexpected_error, parameter_missing_error, entity_missing_error

status. It is a default error message.
code. An error code which uniquely identifies the error.

In the beginning the error code was missing from my design and the mobile clients were using the default error message. This has some disadvantages:

The mobile UI is usually developed in a different codebase. And the server side error message modification is not possible. Specially if the same chunk of server side code is serving many applications.
-The language used on the mobile UI can vary. For example the UX developer can decide to use:

"You haven't provided the group" - First person complaining style.
"The group is missing" - Passive objective style
"Please provide a group" - Proactive gentle style
"Select a group!" - Imperative style
...

In order to formulate the sentences which reflects the application mood the mobile developer needs to interpret the returned error based on its error_code and formulate its own corresponding message.

Happy coding :)

2015-01-15T13:42:00.001+00:00

API Development Restfull vs Facebook style

In the last months I developed mainly API's using grape gem and their related gems.

In this blog post I will express my opinion how to organise the API which manages the entities.

Generally speaking I like the REST concept and I organize my API to conform that way. For cases when there are no association among the entities this philosophy is good enough and clear.

However I like the API to reflect the associations when we are dealing with has_many or has_and_belongs_to_many associations. Just like in case of Facebook Graph API. In these cases I find that style more intuitive and I am following that style whenever I deal with associations.

Examples:

Lets suppose that cars and manufacturers can be reviewed.

class Car < ActiveRecord::Base
has_many :reviews, as: :reviewable

class Manufacturer < ActiveRecord::Base
has_many :reviews, as: :reviewable

class Review < ActiveRecord::Base

belongs_to :user

belongs_to :reviewable, polymorphic: true

In this case the review API would be:

creation of reviews:

POST /api/cars/{id}/reviews

POST /api/manufacturers/{id}/reviews

retrieval of reviews:

GET /api/cars/{id}/reviews

GET /api/manufacturers/{id}/reviews

deletion of reviews:

DELETE /api/reviews/{id}

In the classic restful style the review creation would be:

params do

requires :comment, type: String, desc: "The comment"

requires :reviewable_id, type: Integer, desc: "The id of a reviewable entity"

requires :reviewable_type, type: String, desc: "The type of a reviewable entity"

end

POST /api/reviews

Both solutions have pros and cons. The restful style is more DRY. The Facebook Graph Api style relieves more information about the associations ergo it is more intuitive and easier to use.

Happy coding :)

2015-01-02T16:36:00.000+00:00

Specing the API

When you cover your API with specs the first rule is to cover everything.
Since the API can be called by third parties you need to be sure what is happening in every case. You must be able to reproduce every scenario any time and you must have the same results. :) Does it seems scientific? Well... Indeed it is.

Let me show you some examples:

-You might need to check that only the calls with developer key can access the API. In the opposite case the response is 401, it is still a JSON and maybe an audit log is created.

-You might need to check that the user is authenticated. If not then the response is 401, it is still a JSON and again an audit log is created.

-If some of the parameters are missing or wrong then the response is 400, it is still a JSON and an audit log is created by logging all the incoming parameters.

-If everything is alright then the response is 200/201, the response is a JSON and the entities are massaged as needed by that specific case.

You also need to keep your specs DRY
This will reduce maintenance effort of the test code and it will keep your specs more readable and you will have easy time to add new features and you will feel more happy and in control.

As you can see the above steps like checking the response code, checking if the response format is JSON, checking that the audit log is created are repetitive tasks and can be DRY-ed with rspecs shared examples. The only specific thing which changes from one api endpoint to another is "the entities are massaged as needed by that specific case".

RSpec.shared_examples "returning 401" do
specify "returns 401" do
api_call params, developer_header
expect(response.status).to eq(401)
end
end
RSpec.shared_examples "being JSON" do
specify 'returns JSON' do
api_call params, developer_header
expect { JSON.parse(response.body) }.not_to raise_error
end
end
...

Then in your specs you can use these shared examples in particular cases:

context '/API/learn_by_playing/' do
def api_call *params
get "/api/learn_by_playing", *params
end
let(:api_key) { create :apikey }
let(:developer_header) { {'Authorization' => api_key.token} }
context 'GET' do
let(:required_params) do
{
:first_name => 'Botond',
:last_name => "Orban"
}
end
let(:params) { required_params }

  it_behaves_like 'restricted for developers'

context 'wrong parameters' do
required_params.keys.each do |s|
context 'when the #{s} parameter is blank' do
let(:params) { required_params.merge({s => ''}) }
    it_behaves_like 'returning 400'
it_behaves_like 'being JSON'
it_behaves_like 'creating an audit log'
end
context 'when the #{s} parameter is missing' do
let(:params) { required_params.except(s) }
    it_behaves_like 'returning 400'
it_behaves_like 'being JSON'
it_behaves_like 'creating an audit log'
end

end
end
context 'valid params' do
specify '...whatever you need to really assert for in this particular case...' do
api_call params, developer_header
expect ...
end
end

end

As you can see from the above example using Rspec.shared examples a lot of repetitive lines from your Rspec can be thrown out.

On one of my projects I managed to reduce the specs size by 20% and raise the visibility a lot :) I can't measure and therefore I can't express in numbers what "a lot" means but everybody was satisfied and pleased with the result.

Professional DRY hacking ;)

2014-12-29T12:17:00.004+00:00

Use logger.debug rather than puts!

It is often tempting to use puts in the ruby code to debug the informations.

I like logging instead because:
-allows the filtering capability
-allows formatting abilities
-with a little tweak it takes the same amount of effort than puts
-it is an already invented and well tested system

It is much better in short. So whenever is a logger system available I use that.

logger.debug 'doing this and that'

It seem to me too much to type at first, therefore I created a sublime logger snippet which accelerated typing. I created another one for those cases where I need to implicitly reference the Rails.logger.

;)

2014-12-28T23:38:00.000+00:00

API Development in Ruby On Rails, Nested Entities

There are times when there is one-to-many association amongst the entities. And the mobile developer needs to show all of them in one screen. In these cases it is very easy to fell into the bad habit to execute n+1 queries from mobile side toward the server or from the server to the sql-server.

Here are the entities:

class DetailedGameEntity < Grape::Entity
...
expose :reviews, using: ReviewEntity do |game, options|
game.reviews
end
end

class ReviewPresenter < Grape::Entity
expose :user_id, as: :owner_id
expose :comment
expose :rating

expose :image_urls do |review, options|
review.images.map{|image| image.image}
end
end

They are designed to return everything the mobile screen needs. The games contains their reviews. And the reviews contain their images. So in one query the whole mobile screen can be populated.

Let's see how a programmer in a hurry develops all this API:

games = Game.actual.limit(500)
present games, with: DetailedGameEntity

By developing the API this way the call will result in these queries:

...

Review Load (0.5ms) SELECT "reviews".* FROM "reviews" WHERE "reviews"."reviewable_id" = $1 AND "reviews"."reviewable_type" = $2 [["reviewable_id", 2359], ["reviewable_type", "Game"]]

Review Load (0.4ms) SELECT "reviews".* FROM "reviews" WHERE "reviews"."reviewable_id" = $1 AND "reviews"."reviewable_type" = $2 [["reviewable_id", 2358], ["reviewable_type", "Game"]]

...

As you can see for each returned game game another select is executed to fetch the belonging reviews. The same is done to fetch the belonging user and to fetch the images belonging to the review. This is a very ineffective way because as the review count grows more and more queries need to be executed. This problem is called n+1 query problem.

I do this in my code in these cases:

games = Game.actual.limit(500)

games = games.includes(reviews: [:images, :user] )

present games, with: DetailedGameEntity

The above code will do this sql query:

Review Load (1.0ms) SELECT "reviews".* FROM "reviews" WHERE "reviews"."reviewable_type" = 'Schedule' AND "reviews"."reviewable_id" IN (2195, 2198, 2197, 9567, 9572, 9573, 9574, 9575, 9576, 9571, 9570, 9569, 9568, 2196, 2204, 2210, 2211, ...

So, the underlying Rails code will execute only one query per entity.

It is nice, isn't it?

Please use it ;)

2014-12-27T16:22:00.002+00:00

API Development in Ruby On Rails, Entities

In my last blog post I presented in general the features I like the most about the grape gem. Now I will present the grape entities which are related to the presentation of the returned data. I like these entities a lot because they are an OO way to present data and they help a lot to keep my presentation layer DRY.

The last statement of every grape call is returned to the caller as JSON.
Despite this simple efficiency I like to have more control over the returned data and I use the grape entities to format the returned data wherever I can. I can also rspec them and I am doing it extensively because I am a Test Driven Guy ;)

Let me present some examples of entities their usage and how do I spec them:

Here is the spec for the entity:

describe GameEntity do
describe 'fields' do
subject(:subject) { GameEntity }
it { is_expected.to represent(:id) }
it { is_expected.to represent(:user_id).as(:owner_id) }

...

Here is the entity itself:

class GameEntity < Grape::Entity
expose :id
expose :user_id, as: :owner_id

...

The part of the grape API:

namespace :games do

desc "Retrieve all the games"

params do

optional :include_reviews, type: Boolean, default: true, desc: 'Accepts: true/false.'

end

get do

games = Game.actual.limit(500)

present games, with: GameEntity

This was simple so far. But I can use a more sophisticated GameEntity in case I want to present the included reviews. In all other cases I will use my old simple GameEntity to present the Game.

Let's see that case too:

I modify the grape API to this:

...

if params[:include_reviews]

games = games.includes(:reviews)

present games, with: DetailedGameEntity
else
present games, with: GameEntity

end

I also spec the new entity:

describe DetailedGameEntity do
describe 'special fields' do
subject(:detailed_game) { DetailedGameEntity(game).as_json }
specify { expect(detailed_game[:reviews]).to be_an(Array) }
end

Of course the above was a very simple example.

In real world scenarios we can find ourselves that we are reusing the entities like this:

class DetailedGameEntity < Grape::Entity

expose :game, using: GameEntity do |game, options|

game

end

expose :venue, using: VenueEntity do |game, options|

game.the_venue

end

expose :visitor_team, using: TeamEntity do |game, options|

game.visitor_team

end

expose :host_team, using: TeamEntity do |game, options|

game.host_team

end

As you can see we are keeping our entity codebase DRY by calling the TeamEntity twice in the DetailedGameEntity. This is a typical use of delegation of the Entities.

Let me show a more complex example of our entities:

The usage of the entities:

desc "Retrieve all the reviews belonging to a team"

get do

...

present reviews, :with => ReviewPresenter, user: current_user

end

The entity itself:

class ReviewPresenter < Grape::Entity

expose :current_user_likes do |review, options|

review.likes.pluck(:user_id).include? options[:user].id if options[:user].present?

end

And finally the spec for the entity:

describe ReviewPresenter do

describe 'special fields' do

context 'without passing a user' do

subject(:presented_review) { ReviewPresenter.new(image.review).as_json }

specify { expect(presented_review[:current_user_likes]).to be_nil }

end

subject(:presented_review) { ReviewPresenter.new(image.review, user: current_user).as_json }

...

context 'user is the current_user' do

specify { expect(presented_review[:current_user_likes]).to eq(true) }

end

...

end

What I was doing here is to populate the field 'current_user_likes'

to true or false depending if the current_user likes or not the presented review.

As you can see the presentation layer of any grape API could became more DRY and versatile by using the grape entities.

Enjoy using them ;)

2014-12-26T14:34:00.001+00:00

API Development in Ruby On Rails

I met a technology and a set of gems which were designed to develop any API in Ruby On Rails about half years ago.

The set of gems were:

At first glance it seemed that it adds complexity to the Rails application compared to standard Rails JSON returns. After I played a bit with it I suddenly realized that its API formulating DSL is much more superior. So I started to like it :)

Let me list the elements of DSL I like most:

ability to mount API endpoints. This can be very handy if I want to unmount certain unused parts of the API.

mount Caesars::Ping

mount Caesars::PingProtected

ability to describe the API endpoint. This description will appear in the Swagger documentation. It is a help for the API user.

ability to specify the parameters (type, mandatory or required).

params do

optional :user_ids, desc: "JSON array of the user ids to be deleted."

requires :group_id, type: Integer, desc: "The id of the group"

end

By specifying the type our parameters will be converted automagically to the specified type. It is easier this way for us developers to write our core logic.

a complex DSL to organize the API hierarchy and use route params. I consider this the most powerful feature. I can easily organize the API to look more like Facebook graph API or Philips Hue API than standard Rails restfull API.

namespace :teams do

route_param :id do

desc 'Retrieve all games belonging to teams'

get 'scores' do

#DO logic here

end

The grape features are many more including versioning. Take a look for a complete description at grape site ;)

2014-12-25T23:35:00.000+00:00

Hi,

I have news for you. My daughter had been born in august :) With Her time passed very fast.
I even missed the new macbook release date which was in July. But I don't feel disappointed because according to the rumors the newer MacBook will have a much better CPU. So I will wait for the next generation of MacBook pro :)

Here is a picture about us:

Editing the code with the speed of thought

2013-04-01T19:53:00.001+01:00

Hi

I changed my code editor from Textmate2 to Sublime. A friend of mine told me about it and I was so curious that I needed to try it. I started to love it right in the first moment mainly because of the existence of the command palette and its modular feature approach and the multiple editing feature.

The command palette was for me like some sort of help combined with a quicksearch-autosuggest menu. When I thought to something I would do I typed in and if I had luck then the feature was already there. If not then I needed to search for a suitable package which did the desired functionality.
I saw a huge potential in this approach because I always wanted to edit my code like the code editor would be a extension of my body. In other words I wanted to edit code with the speed of my thought.
By default the desired functions were not there. I needed to search for some packages and even edit those packages to achieve my desires. I wanted to toggle between quote types 'a', "a". I wanted to convert a string to a symbol and vice versa "a", :a. I wanted to toggle the do end blocks with the braces blocks. I wanted to convert amongst sneak_case, pascalCase, dash-case, dot.case, slash/separated

So by using it continouosly for more than half year I installed these packages:

Case Conversion

For converting each other from any of them:

"sneak_case"
"pascalCase"
"dash-case"
"dot.case"
"slash/separated"

Clipboard History - for using multiple history feature
CoffeeScript - syntax for coffee script
Cucumber - syntax for cucumber
Eco - syntax for eco template
ERB Insert And Toggle Command

For toggling amongs these

<%= %>
<%- -%>
<% %>
<%= -%>
<%# %>

Gist - I like to store my snippets on gist and access them from sublime
Missing Palette Commands
Plain Tasks - For storing my tasks in plain text format but nicely formated, like the below list

✔ task 1 @done (13-04-01 21:28)
☐ implement sorting

RSpec - syntax for my specs. I am a TDD advocate. It saves me a lot of time.
Ruby Block Converter - for toggling amongst {} block and do end blocks.
SFTP - for editing remote files.
Toggle Symbol To String for toggling between "symbol"and :symbol
Toggle Quotes for toggling between 'string' and "string"
Advanced New File for creating deeple nested directories when I place a file into them.
Nettuts + Fetch for fetching the latest jquery.js or jquery-ui.js or backbone.js libraries.

Often the commands were missing from some of these packages. So when I searched for 'toggle block' then no result was shown however I wanted to convert a block from "{}" style to "do end" style. This was a bottleneck in my speedy coding... In these cases I needed to open the package add the command to the Default.sublime-commands file and then make a pull request. This way if I eventually forgot the key combination of a feature I could search for it in a command palette.

May I ask any developer who makes a sublime package to add this file to the package and enlist the commands there.
There is the multiple editing feature I like the most... :)
And it is a very fast editor.
I also like the snippet feature of it.

Overall all I can say s that it is a very handy code editor and it worth the money for buying it and spending time to learn it ;)

Leting your vital javascript functions to do their job when the content changes

2012-06-16T22:29:00.000+01:00

Hi Fellow Programmers

In this post I will show you one way to let your pages work as intended even if they are manipulated dynamically.

The problem: When the content of the page changes dynamically, those items are not listened by those javascript functions which were initialized at the time when the page loaded.

At the very first steps every programmer reinitializes only those handlers which are needed by the dynamically reloaded partial. This has some disadvantages. One of them is that if the initialization changes then it is very painful to track back the partials where the initialization need to be changed. Plus, the whole thing need a babysitting process...

I don't want that...

What I want is a structured way, in which is agile and robust enough to handle these issues... :)

Let me show you by code:

window.problemOrNot = { 
  vital_functions: [
    ->
      $(".cancel").click ->
        $('.cancelable_remove').remove()
        $('.cancelable_show').show()

  ]
  run_vital_functions: ->
    $.each problemOrNot.vital_functions, ->
      @()
}

jQuery ->
  problemOrNot.run_vital_functions()

And then in your partial, which obviously modifies your dom:

$('.comments').append("<%=j render :partial => 'form' %>");
...
...
...
$('#comment_operations').hide();

problemOrNot.run_vital_functions();

That's it... The first code was in cofee script, and the partial was a rails .js.erb partial. :) Enjoy

Full Text Search Feature Of Postgresql

2012-06-07T14:15:00.000+01:00

Hi,

I was using mysql for my development for a long-long time. But I decided to try postgresql as I watched Ryan Bates screencast which showed the fullt text search capabilities of postgresql.

I was motivated to try postgresql since heroku added a new addon which enables any application to use the lastest(9.1.13) postgresql. And as a bonus the capacity of that DB is unlimited... However I can hardly believe that it will remain free forever...

So...
I created a new DB on my heroku account for my application and I followed the migration manual and voila. It took me about no more than 15 minutes to transition to a new DB.

It was a nice experience. :)

Navigating from controllers to .haml type views in Textmate

2012-06-05T11:52:00.001+01:00

Hi, I made a fix which enables your Textmate to navigate from your controller to your haml type views, using the ruby on rails bundle. Enjoy

Advanced git features

2012-06-04T09:55:00.000+01:00

Hi everybody,

I am using git as source control for a long time ago, and I am happy with what it offers. I presume that the basic git commands are clear for everyone. So in this post I will write about some more advanced git commands which aren't used so frequently but they are invaluable when they are needed.

-Nice Git log which contains a lot of usefull info:
git log --graph --all --decorate=full --abbrev-commit --pretty=short

-Delete the branch 'staging' on remote 'staging':
git push staging :staging

-push the branch "newfeature" to the remote "origin":
git push origin newfeature

-create a remote branch:
git push  :refs/heads/new_feature_name

-list remote branches:
git branch -r

-diff between two branches:
git diff <branchone>..<another branch>

-create a branch wich tracks a remote branch:
git checkout --track -b <new_feature_name> <origin>/<new_feature_name>

-track a remote branch:
git branch --set-upstream <local_branch> <remote>/<remote_branch>

-push to a remote:
git push <remote> <local branch name>:<remote branch to push into>

-configuring to push automatically to a certain remote branch, without specifying the local branch and the remote branch:
git config remote.<remoteName>.push <localBranchName>:<remoteBranchName>

Enjoy and easy your life :)

Installing Ruby On Rails in windows machines

2012-05-23T11:37:00.000+01:00

I dedicate this post to my friends who can't afford to buy a mac or not experienced enough to work on Linux machines

In my virtual box I tried to reproduce the installation of Ruby on Rails on Windows XP.
Because the framework evolved from my last windows installation I realized that some things have become simpler to install and additional things needed to be installed.

Here are the steps which are needed to get a ready to enjoy Ruby On Rails environment on Windows machines:

Download ruby:
http://rubyinstaller.org/
Install it. (The default instalation directory will be C:\Ruby193)

Download devkit for ruby form this location:
https://github.com/downloads/oneclick/rubyinstaller/DevKit-tdm-32-4.5.2-20111229-1559-sfx.exe
Install it to c:/Webkit (important that the directory can't contain spaces)
Put C:\Ruby193\bin and c:\Devkit\bin in your path. (My computer -> properties -> 'environmental variables')

Run these commands from a newly opened command prompt:
cd c:\Devkit
ruby dk.rb init
ruby dk.rb review
ruby dk.rb install

Now you can install rails by doing "gem install rails". (If you previously tried to install anything without having the devkit installed then please empty your ruby gems directories. Usually they are here: C:\Ruby193\lib\ruby\gems\1.9.1)

gem update --system
gem install rubygems-update

rails new hello_world

Normalize you DB

2011-10-06T17:04:00.007+01:00

Hi everyone,

In the last couple of days I had the opportunity to normalize a DB. :)

Let me show you a screenshot about a single table:

As you see a lot of data is repeated across the rows. Therefore, I had some bad thoughts about those who let the DB become like this in the beginning. I didn't wanted to do it. As the moments were passing away I let the challenge to excite me. At the end I did it.

Before doing anything the total number of rows in the db was above 100000 and the size of the table was 10,5 MBytes.

My first step was to extract the name of the components into another table and reference them.

This way the size of the table decreased to 8.5 MBytes. And the new table size was 1.5 Mbyte. I earned 0.5 Mbyte, not too much, but the database was much more cleaner.

My second step was to transform the check/change data represented by a string into their numerical representations, this way enabling the database to be internationalized. By doing this the table size decrease to 6.2 MBytes. That means 72% of its original size and the data can be internationalized and we have all the benefits of a normalized DB schema (that means no update problems and a joy to work with).

I also measured the speed of joins operations. Because of the normalization the same data retrieval was increased by 3 times. I put an index onto foreign keys. And the speed was just like before. :)

Design your User Interface

2011-10-06T10:52:00.006+01:00

Hello everybody,

I have just finished the book "The Design Of Everyday Things".
It's a great book written by Donald Norman. The guy who wrote "The invisible computer", who worked for the Apple Computer's Advanced Technology Group.

In this book he talks about many-many interesting things:
-The constraints and strength of our short term & long term memory.
-The slips and mistakes our brain makes, while we do things.
-How can we make use of our cultural knowledge and knowledge in the world while design.
-The importance of natural mapping between controls and our actions.
-Interpretation of a system state, and our mental model about the system.
-The (missing) evolution of product line. The evaluation of the already selled products and the importance of debriefing then evolving the product to a better one.

He also describes how primitive were the computers at time of writing.

And he gives us some hints how he imagines the mobile phones should easy our everyday tasks. I had the impression the he was envisioning the nowadays iPhones. He also describes how a graphical user interface would help us to be more effective with the computer interaction. I often had the feeling that he was describing a vision which is very similar about nowadays iPads, iPhones or Microsoft Surface.

I was also symphatizing with him because I remember times when I needed to setup my Mouse and CD driver in the config.sys in order to use those devices. Nowadays everything is much more easier. Especially that, I am a Macintosh user I can spend my time focusing on relevant tasks, without even realizing that I am working.

I finished the book yesterday. After I put the book back onto my shelf I started to browse the new Apple products... They are just amazing. I was especially amazed by the new Siri feature in the iPhone. It remembers me to the "Computer" from Startreak. It is a good example that if we can imagine something then we can sooner or later achieve it. Another feature I imagined even myself and waited a lot is the iCloud. I tried the beta version by downloading Ethics from Aristotle on my Macbook and the book instantly appeared on my iphone too. :) Definetely it enhances our usability experience.

The next day, other news were expecting me. Sad news. The founder and main dreamer, envisioner and technology pioneer Steve Jobs died. So good journey Steve and rest in peace.

sqlite log filtering

2011-07-18T21:14:00.007+01:00

Hi,

Presumably a lot of you are developing rails applications using sqlite.
In this case the log is spamed by some pesky sql statements every time our app accesses the db.


 SQL (0.6ms)   SELECT name
 FROM sqlite_master
 WHERE type = 'table' AND NOT name = 'sqlite_sequence'
  SQL (0.6ms)   SELECT name
 FROM sqlite_master
 WHERE type = 'table' AND NOT name = 'sqlite_sequence'
... 
 SQL (0.6ms)   SELECT name
 FROM sqlite_master
 WHERE type = 'table' AND NOT name = 'sqlite_sequence'
  SQL (0.6ms)   SELECT name
 FROM sqlite_master
 WHERE type = 'table' AND NOT name = 'sqlite_sequence'
...

These messages bother me because they have nothing to do with my application logic, they are only needed by the sqlite driver to access the db structure.

Therefore I developed a small ruby gem called sqlite_log_filter which filters these messages out. The source can be found on github

All you need to do is to put it in your gemfile


gem 'sqlite_log_filter'

Then bundle it


bundle install

Hopefully it helps :)

Test (Behaviour) Driven Development

2011-06-21T21:53:00.007+01:00

Recently I saw a pretty nice post:

"If you see anyone pushing code to Rails without tests, ping me and I will gladly revert. In 2011, this should be unacceptable."

I remember times when I had a project which was developed test driven at my former place of work. Of course the Test Driven initiator was me, and by time the teammates embraced the methodology and it managed to be a very successful project.

The most exciting thing was that I never had to debug; the tests always showed me the exact the location of the problem -if there was any.
Another almost unbelievable fact was that days before releases we didn't have any unfinished tasks. We were down on the streets having a Budweiser or limonade and we were chatting. What I mean here is that the test batteries saved us so much time that we never had to work overtime. We were just shipping the product confidently days before the planned release. I also remember some sales meetings where this project was showed to the customers as a success story. I also remember one of the questions one customer asked: "Then why don't you write software this way every time?" and the answer was "Because some customers simply dictate to not write any test at all..." Well everyone in the meeting laughed. But we all knew that this decision would cause any customer to throw out hundreds of thousand of dollars and hundreds of hours of overtime for the developers without mentioning the moral downgrade for every involved party. Maybe we were laughing at that unintelligent stereotype.
I also remember one important fact while writing this. In the initial project schedule the testing time wasn't calculated. We simply adopted the test first and then the benefits showed themself over and over again. We couldn't run out of the schedule... :) Almost unbelievable but it was true.

After the project has been finished I have tried to introduce this methodology in as many projects as I could. Unfortunately there were some projects where the mass was so frozen that my attempts were totally ignored. Sometimes the reason for ignorance was simply the lack of infrastructure. Fortunately the infrastructure is not a problem in Ruby on Rails. The community is also mostly test-centered.

I cannot emphasize enough for every developer in any domain to embrace this Test First thinking. There are so many benefits of it that many books have been written about it. And who knows, maybe you who will embrace this approach, will have some similar success story to tell the world

autotest, zentest, autotest-rails, autotest-rails-pure: which gems to choose?

2011-06-20T13:18:00.012+01:00

It was a little bit confusing for me which "autotest like" gems to choose when I want to autotest my rails application.
Well... There are some alternatives depending which testing framework I choose rspec or Test::Unit, also there are alternatives if I want to generate the tests for my controller actions automatically with zentest or I just want to write them in some other way.

Zentest was the first tool in this domain with a lot of features. Then autotest-standalone was factored out from it. There is also an empty gem called Autotest which is dependent on Zentest.

Because the main idea is to simply map the lib and test directories, in order to test rails application we need to tell the rails specific mappings. This is done by the autotest-rails and rspec-rails and autotest-rails-pure gems. So let's walk through each of the alternatives

Test::Unit

In this case the rails specific mappings are done by the autotest-rails-pure or autotest-rails gems.
The code excerpt which makes the mapping for the controllers is:


    add_mapping %r%^app/controllers/application_controller\.rb$% do |_, m|
      files_matching %r%^test/(controllers|views|functional)/.*_test\.rb$%
    end

For the core autotest we can use the autotest-standalone or the feature rich old Zentest.

Rspec

The rails specific mapping is done by the rspec-rails in case we opt for using rspec

Here is an excerpt wich does the mapping for the controllers:

    add_mapping(%r%^app/controllers/(.*)\.rb$%) { |_, m|
      if m[1] == "application"
        files_matching %r%^spec/controllers/.*_spec\.rb$%
      else
        ["spec/controllers/#{m[1]}_spec.rb"]
      end
    }

So there are a plenty of alternatives we can choose from and it is good to know which opportunities are available. We have all we need :)

Making the Factory Girl to support Paperclip

2011-06-11T12:49:00.019+01:00

Hi Rubysts,

Paperclip and Factory Girl Rails both of them are my loved gems.
Unfortunately Factory Girl Rails can't create the model if the model had been Papercliped. Well at least not in Rails 3.0.7. But the good news is that it can be solved by adding a few lines of Ruby code to our factory.

This is my model:


class Club < ActiveRecord::Base
  has_many :dancers
  has_attached_file :photo, :styles => { :medium => "300x300>", :thumb => "100x100>" }
  validates_attachment_presence :photo
  validates_attachment_size :photo, :less_than => 1.megabytes
end

So in order to use the factory with ease we need to tell our factory to upload some pictures into our model.
Therefore let me show you an example how to write the factory which makes the two gems to co-work:


include ActionDispatch::TestProcess

class Club
  attr_accessor :photo_file_name
  attr_accessor :photo_file_size
  has_attached_file :photo, :styles => { :medium => "300x300>", :thumb => "100x100>" },
                    :url  => "/test_can_be_deleted/:attachment/:id/:style/:filename",
                    :path => ":rails_root/public/test_can_be_deleted/:attachment/:id/:style/:filename"
end

Factory.define :club do |c|
  c.title 'Limpex'
  c.sefurl 'Limpasm'
  c.name  'Limpasm'
  c.metadescription 'good etc'
  c.content '<p> a good place</p><p>the icecream is prety damn good</p>'
  c.state 0
  c.city 'Gheorgheni'
  c.email 'some@somplexx.com'
  c.photo   { fixture_file_upload( 'spec/factories/test.png', 'image/png') }
end

As you can observe I have just reopened my model and have redefined the paperclip attachment to point to a different path in order to store the dev and test mode attachments in different places.

That's it. :)