Ostatnio myślałem że fajnie by było mieć:
Web panel do zarządzania migracjami - by nie trzeba było pamiętać jak np cofnąć 2 migracje, lub jedną wybraną
Web panel do edytowania factories/speców - może z tagowanie itp? Czasem ilość linii kodu w tych plikach jest przytłaczająca
A wam czego brakuje?
Sensowniejszego (JAKIEGOKOLWIEK) outputu z rake assets:precompile, nawet jeśli wymagałoby to switcha --trace.
Pewnie coś mi umyka, ale ja to widzę jako chęć edytowania kodu (bo specs i factories to też kod) za pomocą jakiegoś web panelu, a nie edytora… Co jest całkowicie pozbawione sensu.
+2
Ja jestem przeciwinikiem takich paneli, jak coś nie mieści się w zwykły flow edytor + linia poleceń, to znaczy, że coś poszło nie tak. Jak jest za dużo linii kodu, to trzeba rozbijać na mniejsze - z tego co wiem w nowych wersjach factory girl tak jest domyślnie i fabryki siedzą w plikach typu spec/factories/posts.rb
Pewnie coś mi umyka, ale ja to widzę jako chęć edytowania kodu (bo specs i factories to też kod) za pomocą jakiegoś web panelu, a nie edytora… Co jest całkowicie pozbawione sensu.[/quote]
Sławosz chyba jeszcze nie wie że factories można rozbić na kilka plików 
A rozbuchany test pojedynczej klasy oznacza, że testowania klasa też jest rozbuchana, więc czas na refaktoring.
Testy też można rozbić na kilka plików zresztą.
A ja w drugą stronę. Po ostatnich wymysłach w scope, by uczynić je idiotoodpornym, uważam,
że powinno się ten helper całkowicie wyrzucić (podobnie jak kiedyś AS::Memoization), bo czymże się różni
scope :active, -> { where(status: 'active') } # always lambda, srsly?od
def self.active; where(status: 'active') endPomijam coś?
[quote=sevos]A ja w drugą stronę. Po ostatnich wymysłach w scope, by uczynić je idiotoodpornym, uważam,
że powinno się ten helper całkowicie wyrzucić (podobnie jak kiedyś AS::Memoization), bo czymże się różni
scope :active, -> { where(status: 'active') } # always lambda, srsly?od
def self.active; where(status: 'active') endPomijam coś?[/quote]
Dzięki użyciu scope masz listę scope’ów zdefiniowanych na danej klasie, używając metody nie ma jak odróżnić metody zawierającej scope’a od czegoś innego. Nigdy w praktyce tego nie potrzebowałem, ale to jest chyba jedyna różnica, o której mogę pomyśleć.
Co do “always lambda, srsly?”, to implementacja wersji bez lambdy była zagmatwana, miała dużo bugów i łatwo można było się pomylić pisząc bez lambdy coś co z lambdą powinno być ( typu scope :recent, where([‘created_at > ?’, 3.days.ago]) ). Stąd decyzja o ujednoliceniu.
Mam jak sevos, metody statyczne są o wiele sympatyczniejsze składniowo niż podawanie lambdy do scope. Zwłaszcza że w metodzie statycznej rozbicie na kilka linijek, a więc i zapakowanie if-else, jest naturalne, podczas kiedy wielolinijkowa lambda wygląda mało czytelnie.
EDIT: przykład z aplikacji którą jakiś czas temu pisałem, dzięki metodzie statycznej mogę nieskomplikowane wyszukiwanie/filtrowanie emaila po regexpie* zaimplementować prostym scope’em zamiast zaprzęgania pełnego kombajnu typu meta_search:
def self.email_contains(searched_email)
if(searched_email.blank?)
all # scoped
else
regexp = Regexp.new(searched_email.to_s, Regexp::IGNORECASE)
where(:email => regexp)
end
end
[quote=sevos]A ja w drugą stronę. Po ostatnich wymysłach w scope, by uczynić je idiotoodpornym, uważam,
że powinno się ten helper całkowicie wyrzucić (podobnie jak kiedyś AS::Memoization)[/quote]
Może raczej poprawić ten helper, żeby można nim tagować metody klasy?
scope; def self.active; where(status: 'active') end[quote=Bragi][quote=sevos]A ja w drugą stronę. Po ostatnich wymysłach w scope, by uczynić je idiotoodpornym, uważam,
że powinno się ten helper całkowicie wyrzucić (podobnie jak kiedyś AS::Memoization)[/quote]
Może raczej poprawić ten helper, żeby można nim tagować metody klasy?
scope; def self.active; where(status: 'active') end[/quote]
W praktyce to jest raczej rzadko potrzebne, więc nie wiem czy jest sens. Jak ktoś bez tego nie może żyć, to zawsze może zamienić swoje metody na lambdy.
Ja też z reguły używam metod, głównie dlatego, że łatwiej jest napisać “def something”, niż “scope :something, -> {”
Co do różnic, to jeszcze jedna rzecz mi przychodzi do głowy, lambda trzyma kontekst:
[code]class Module
def scope(name, block)
define_method(name, &block)
end
end
class Foo
bar = ‘baz’
scope :one, -> { puts bar }
def two
puts bar
end
end
foo = Foo.new
foo.one # bar
foo.two # undefined local variable or method `bar’ on an instance of Foo. (NameError)[/code]
Ale dalej akademickie rozważania, bo też nie mam pojęcia jak można by to w praktyce wykorzystać