How to proper test scopes (named scopes)

I just read few posts about "how to test named scopes". I'm asking - why should I use FactoryGirl and create tons of unnecessary objects just to test `order(:position).first`?!

How not to do this

We've just created .. let's count .. 5 objects and made 2 unnecessary db queries

How to do this

It's useless to test Rails (it's really proper tested). We need to spec messages that goes between objects and given parameters.

param_protected i Devise

Kilka dni temu pisałem już o gemie param_protected. Jeżeli używamy go razem z Devise, będziemy musieli zrobić zmodyfikować kontrolery i dodać definicję dozwolonych parametrów.

Po pierwsze musimy zmapować URL-e na nasze nowe kontrolery.

param_protected wycina potrzebne parametry

param_protected to świetny gem, który przenosi funkcjonalność attr_accessible oraz attr_protected do kontrolerów. Składnia jest bardzo prosta:

Jedyny problem jest taki, że nie ma defaultowej listy dozwolonych parametrów. Tzn. że wycinane są takie atrybuty jak action, controller, id, utf8 czy (w przypadku używania devise) authenticity_token. Formularze nie będą przez to działać poprawnie, będziemy cały czas wylogowywani itd.

Capybara i Devise - mock logowania

Piszemy request spec-i dla naszej aplikacji.

No i problem! Jak zalogować użytkownika?

Mongoid: polimorficzne embeds_one

Nie da się


Załóżmy, że nasza aplikacja ma model MediaObject, który posiada tytuł, głosy itd. ale specyficzne informacje n/t obiektu (treść/link etc.) są w innym modelu (Media::Text, Media::Image etc.). Relacja oczywiście jeden-do-jeden. Jeżeli zrobimy to na zasadzie referenced assosiation, czyli relacje rodem z baz SQL, będziemy mieli zawsze n+1 zapytań. Mongoid co prawda obsługuje eager loading, ale nie dla relacji polimorficznych. Co więc możemy zrobić?

Tworzymy model MediaObject:

Oraz model Media::Resource - po nim będą dziedziczyć wszystkie modele z modułu Media

Teraz możemy dodać np. model Media::Text

Użycie:


Żeby ułatwić sobie życie, możemy wydelegować #content do MediaObject

Opcja allow_nil pozwala trzymać w #content pustą wartość. W tym przypadku to bardzo ważne, bo nie wiemy czy napewno wszystkie modele Media będą miały taką metodę. Gdyby nie miały, bez tej opcji model zawrze rzucał by wyjątek. Teraz użycie wygląda tak:

Bump to 1.9.3-p0

Dzisiaj (dopiero) zrobiłem update Ruby do wersji 1.9.3-p0. Dużo naczytałem się o poprawie startu appki, wykonywaniu testów itd.

Sprawdźmy jak to wygląda w praktyce :)


Po zainstalowaniu odpaliłem testy powstającej (a więc narazie niedużej) aplikacji Railsowej (Rails 3.1.3)

Ruby 1.9.2

Ruby 1.9.3

Średnie czasy:

Ruby 1.9.2 =~ 16.69

Ruby 1.9.3 =~ 11.12(!)

A więc różnica ponad 5.5s. Całkiem sporo jak na 140 testów.

Update'ować? Opinie są różne, ale wydaje mi się, że jeżeli ma się dobrze otestowaną aplikację można spróbować. Jeśli testy przejdą to po co tracić codziennie te kilka minut (5s * odpalanie_testów_miliard_razy)?

Ruby & Ruby on Rails 101

Ruby & Ruby on Rails 101. Krótka lista od czego zacząć** (będzie uzupełniana)


Ruby
1. TryRuby (Ruby w 15 minut)
2. Eloquent Ruby (moja "mini recenzja")
3. Desing Patterns in Ruby
4. Klasyk, tzw "Książka z Kilofem" - Programming Ruby

Ruby on Rails
1. Rails for Zombies
2. RailsGuides
3. RailsCasts
4. Ruby on Rails Tutorial


Za książki o Rubym trzeba niestety zapłacić (ale pamiętajmy, że to inwestycja!), natomiast źródła o Railsach są w 100% darmowe (no, RailsCasty przynajmniej do niedawna były w 100% darmowe, teraz część treści tam publikowanych jest płatna) i moim zdaniem wystarczające, aby zacząć pisać proste aplikacje. Książek do Railsów jest multum - począwszy od Agile, przez Rails 3 in Action aż po Rails 3 Way (ta ostatnia zdecydowanie dla zaawansowanych), ale moim zdaniem nie są one wymagane (tzn. da radę lepiej lub gorzej nauczyć się bez nich)

** głównie do publikacji na forum Ruby on Rails. Tam takie pytania (a co za tym idzie i odpowiedzi) padają bardzo często. Zamiast pisać to za każdym razem lepiej odesłać do linka ;)

UPDATE Rails 3.1: respond_with i pusty json/xml/yaml przy update

Update postu Rails3: respond_with i pusty json/xml/yaml przy update dla Rails 3.1. Plik application_responder.rb powinien w niej wyglądać tak:


Reszta pozostaje bez zmian.

Template inheritance w Rails 3.1 - DRY niczym Briana Banks

Wielkimi krokami zbliża się wersja 3.1 frameworka Ruby on Rails, a wraz z nią wiele ciekawych ficzerów jak na przykład reversible migrations czy mountable engines. Jako genialny wynalazek zostało również wprowadzone template inheritance:

As the name implies, inherited templates make template lookup follow the controller inheritance heirarchy if it can’t find a template for the current controller.

Najłatwiej będzie to opisać fragmentami kodu.


Fragment kodu, który odpowiada za menu możemy przenieść do katalogu app/views/application, ponieważ każdy kontroler dziedziczy po ApplicationController.


Do tej pory wszystko wygląda wspaniale. Co jednak, jeżeli chcielibyśmy dodać jedną pozycję w menu np. dla NewsController? Nic prostrzego. Tworzymy app/views/news/_menu.html.erb w którym dodajemy link. Wspaniale! Co jednak, jeżeli mamy bardzo rozbudowane menu a dla jednego kontrolera chcemy dodać 1 (JEDNĄ!) pozycję? Tak! Musimy skopiować cały plik i dodać tylko ten 1 link. Don't Repeat Yourself pełną gębą.

System szablonów (nie mówię o języku szablonów, ale bardziej o tym jak działa mechanizm ich ładowania, przekazywania do nich zmiennych itd.) w Rails nigdy mnie nie powalał. Dużo bardziej podoba mi się ten znany z Django. Mamy w nim tzw. bloki. Przenosząc ten mechanizm na nasz przykład mielibyśmy blok menu w głównym szablonie (application.html.erb) i bloki rozszerzające go w poszczególnych szablonach. Wyglądałoby to mniej więcej tak:


Prawda że wygodniej, schludniej i bardziej DRY?




* Briana Banks (ur. 21 maja 1978 w Monachium) - niemiecka aktorka występująca w filmach pornograficznych. [wikipedia.org] [która zdecydowanie nie jest dry (sucha) - autor]

Rails3: respond_with i pusty json/xml/yaml przy update

W Rails3 możemy zamiast (bardzo "nie-DRY") bloku respond_to:


możemy ustawić raz w jaki sposób chcemy odpowiadać na request:

dużo ładniej prawda? :)

Jest jednak jeden problem - przy akcji update (czy każdej innej do której dostajemy się poprzez PUT) Rails zwraca status OK (200) zamiast zmienionego obiektu. Może czasem to dobrze, możliwe, że to nawet bardziej zgodne ze specyfikacją REST, tego nie wiem. Wiem tyle, że potrzebowałem aby update zwracało obiekt. Można zrobić to na 3 sposoby - dobry, okropny, jeszcze gorszy :) Zacznijmy od końca. Możemy w każdej akcji używać:


Skazujemy się jednak na jeden format zwracanych danych. Możemy wrócić znowu do bloku respond_to (to jest opcja nr.2 - okropna), lub nadpisać responder.

Tworzymy plik application_responder.rb w katalogu lib/


Następnie zmieniamy ApplicationController (app/controllers/application_controller.rb):


Dzięki temu możemy w akcji update używać respond_with:

Instalacja Ruby (1.9.2) i Rails (3.0.3) w Ubuntu 10.10

1. Instalacja Ruby 1.9.2

Na początek instalujemy język Ruby wydając w konsoli (Aplikacje -> Akcesoria -> Terminal) polecenie:

sudo aptidude install ruby1.9.1 ruby1.9.1-dev

Proszę nie przejmować się "1.9.1" w nazwach pakietów, w ten sposób instalujemy najnowszą wersję Ruby - 1.9.2

Aby zapobiec konfliktom nazw poleceń z wersją 1.8.7, polecenia dla Ruby 1.9.2 mają nazwę np. rubygems1.9.1. Dla naszej wygody zmieniamy to poleceniem:

sudo ln -s /usr/bin/rubygems1.9.1 /usr/bin/rubygems
sudo ln -s /usr/bin/ruby1.9.1 /usr/bin/ruby 

Dla innych komend (irb, rake itp.) wydajemy podobne polecenia.