Merb - it is a bug if...
13 komentarzy | Kategorie: Merb, Ruby, Techblog | trackbackTagi: merb rails ruby
Witam po dłuższym okresie bezczynności. Okres wakacji to chyba taki sezon ogórkowy bo niewiele się działo zarówno w polskiej blogosferze Rubiego a także i na techblogu. Mam nadzieję, że ten okres mamy już za sobą i zarówno na tym blogu jak i na wcześniej wymienionych stronach zacznie się coś dziać;-).
Tym razem chciałbym skomentować podejście developerów frameworka webowego Merb do pewnych zagadnień. Za wiki Merba:
Bugiem w Merbie (merb-core, merb-more) jest:
-kod używający konstrukcje returning() oraz Symbol#to_proc
-plugin, którzy chce rozszerzyć Merb, używając alias_method_chain
-plugin, którzy chce rozszerzyć Merb, korzystając z jego prywatnego API
-gdy wydanie wypada gorzej w benchmarkach niż poprzednie
-gdy sygnatura lub zwracana wartość publicznej metody jest zmieniona bez uprzedniego uprzedzenia (mechanizm deprecation) i odnotowania w changelogu publicznego API
Dodatkowo dla merb-core bugiem jest:
-gdy brakuje specyfikacji dla niskopoziomowej funkcjonalności jak na przykład request dispatching
Muszę przyznać, że bardzo mi się podoba to podejście. Staram się obserwować postępy prac nad tym frameworkiem i coraz bardziej podoba mi się. Śmiem twierdzić, że DHH pisząc pierwszą wersję Ruby on Rails dopiero poznawała Ruby. Zaowocowało to dosyć częstym sięganiem po dosyć magiczne, często niezrozumiałe konstrukcje językowe dla początkującego. I nie jest to zarzut, bo sam po sobie wiem, że każdy musi przez to przejść. Po prostu nie da się od razu mieć wyrobionego zdania na temat czegoś bez uprzedniego spróbowania gdzie może się to coś sprawdzić.
Ezra Zygmuntowicz, główny koder projektu, rozpoczynając pracę nad Merbem takie doświadczenie z Rubym już miał. Z doświadczenia wiedział co niekoniecznie sprawdziło się w railsach. Weźmy dla przykładu to jak zbudowane są przeróżne pluginy do RoR. Przesłanianie metod prywatnych, aliasowanie, zmiana wartości zwracanych to bardzo częsta praktyka, która prowadzi do bałaganu. Jak często chcięliśmy zrobić update wersji RoR do nowszej i okazywało się, że połowa pluginów nie działa albo pojawiają się bardzo dziwne błędy? Oczywiście można tu mieć pretensje do samego języka, który umożliwia takie konstrukcje, ale to błędne rozumowanie. Raczej trzeba mieć pretensje do pseudo railsowej architektury dla pluginów, w której tak na prawdę chodzi o to by załadować plik init.rb pluginu, a on niech sobie już "róbta co chceta".
Liczę na szybko rozwój merba i wypuszczenie stabilnej wersji 1.0 w najbliższym czasie. Jestem pewien, że będzie to doskonała alternatywa dla RoR.
ps. Gdyby ktoś nie bardzo wiedział o co chodzi z konstrukcjami returning, Symbol#to_proc, alias_method_chain to mogę spróbować na blogu je opisać.
MerbCamp juz za pare godzin ;]
czesc Radek
Z mila checia poczytam o returning, Symbol#to_proc, alias_method_chain na Twoim blogu.
pozdrawiam
Sławek
Ja chętnie poczytam czemu returning jest złe :)
A deifnicja ,,buga’‘ bardzo fajna i konkretna
„Śmiem twierdzić, że DHH pisząc pierwszą wersję Ruby on Rails dopiero poznawała Ruby”
Masz 100% racji, poza tym, ze DHH nie jest kobieta ;)
Hmm… Generalnie zgadzam się, że nie należy przesadzać z hakowaniem railsów przez pluginy, bo to się może źle skończyć (co nie znaczy: nie robić tego w ogóle…); ale co jest złego w returning i w Symbol#to_proc??
Co lepiej wygląda:
users.map { |u| u.group }.map { |g| g.name}czy:
users.map(&:group).map(&:name)?Bo według mnie to drugie… Ewentualnie jeszcze w takim frameworku Hobo którego ostatnio używam jest jeszcze taka opcja, też niezła:
users.*.group.*.nameA co do DHH, no właśnie też się zastanawiałem kiedy on(a) płeć zmienił(a) :)
Akurat :symbol to_proc czasem może wydawać się magiczne dla mniej doświadczonych (chociaż sam używam).
Wychodząc z tego założenia można równie dobrze stwierdzić: piszmy w Javie, bo całe Ruby jest magiczne :) Ja pamiętam jakie miałem odczucia jak pierwszy raz widziałem kod w Rubym… że totalna egzotyka, wszystko takie jakieś nienormalne, itd. :)
Psi: magiczne w tym sensie, że już 2 lub 3 razy tłumaczyłem komuś jak to działa, ale jest fajne i typowe Rails Way, dostępne z ActiveSupport.
Za to returning będzie już w Ruby 1.9 jako metoda tap i wtedy Ezra powie, nie używajcie metody tap?
Podpisuje się pod opinią Sławka :)
Dzięki za komentarze.
@solnic: oczywiście, że DHH jest kobietą. Kopernik też była kobietą! (oczywiście literówka, zaraz poprawię :))
Do pozostałych komentarzy postaram się odnieść w najbliższym wpisie. Ale nie spodziewajcie się flame’a;).
Kopernik byla kobieta i to w dodatku niemiecka! :)
„Jak często chcięliśmy zrobić update wersji RoR do nowszej i okazywało się, że połowa pluginów nie działa albo pojawiają się bardzo dziwne błędy?”
Znasz jakies oprogramowanie
które z miejsca gwarantuje ci kompatybilnosc wsteczną w 100 % ?
„Przesłanianie metod prywatnych, aliasowanie, zmiana wartości zwracanych to bardzo częsta praktyka, która prowadzi do bałaganu”
Hmm, balagan to balagan, nie da sie ukryc ze stosowania zbyt wielu sztuczek© ruby prowadzi czesto to nieoczekiwanych efektow, tylko czy niekorzystanie z nich moze zagwarantowac kompatybilnosc poszczegolnych wersji frameworka oraz jego pluginow ? watpie.„-kod używający konstrukcje returning() oraz Symbol#to_proc
-plugin, którzy chce rozszerzyć Merb, używając alias_method_chain
-plugin, którzy chce rozszerzyć Merb, korzystając z jego prywatnego API”
Wszystkie te punkty sa zdroworozsadkowa kalkulacja.
AD 1. returning() nie jest natywne? tak samo jak Symbol#to_proc. Symbol#to_proc bedzie natywne dopieor w 1.9, merb jest chyba pisany nadal dla 1.8. Symbol#to_proc gwarantuje owiele wieksza wydajnosc, ale zmniejsza przejszystosc kodu.
AD 2. plugin nalezacy do merb-more nie powinen korzystac z alias_method_chain poniewaz jest to faktycznie czesc projektu. Twoje pluginy moga korzystac alias_method_chain czemu nie, to najlatiwejszy sposob aby efektywnie cos rozszerzyc. Ale Ezra moze dokonywac odpowiednich zmian i w merb-core i w mer-more a wiec nie potrzebuje tutaj zadnych bajerow.
AD 3. plugin, którzy chce rozszerzyć Merb, korzystając z jego prywatnego API, lamanie takiej zasady we wlasnym projekcie to strzal w stope.
Ogolnie bardzo dbra taktyka. Tylko chcialbym zauwazyc ze to sa bugi w Merbie. Nie powinno sie ich traktowac jako bugi w pluginach ktore samemu sie pisze do merb. Ale jesli widzisz taki kod w Merb-core i Merb-more to znaczy ze ktos spieprzyl sprawe.
Nie poprawiaj, bo jeszcze nie wszyscy z biura to widzieli