Młot na railsy
Z emocji związanych z wypuszczeniem w świat bezbiura.pl zapomniałem wspomnieć o najważniejszym technologicznym aspekcie tego projektu. Ale już się poprawiam - otóż mam wrażenie, że bezbiura.pl jest jednym z pierwszych (pierwszym?) serwisem w naszej sieci korzystającym z frameworka Merb.
Dlaczego nie Railsy? Moje zniechęcenie do ror postępowało stopniowo, ale swoje apogeum osiągnęło wraz z wypuszczeniem wersji 2.x. Ortodoksyjne zmiany wprowadzone wraz z tą wersją wywołują u mnie wewnętrzny bunt. Praktyka pokazuje, że próba odejścia od świętej ścieżki RESTa powoduje, że urok rora blednie (tak, tak wiem, że niebawem nawet mój kot będzie RESTfullnie komunikował się ze swoją miską - jako zgred powiem - przerabialiśmy to już w czasach XMLa). Aby bazować także na czymś bardziej namacalnym przygotowałem sobie zestaw testów regresyjnych na webankiecie, aby sprawdzić zgodność między różnymi wersjami Railsów i wyniki byly słabiutkie - to co opisane w dokumentacji jako droga migracji to jedno, praktyka okazała się znacznie bardziej magiczna i kłopotliwa. Mniej więcej w tym momencie zaczęło sie robić głośniej o Merbie. Postanowiłem sprawdzić czy może to jest jakaś alternatywa dla Ror i… moim zdaniem Merb to jest przyszły pogromca Railsów, oto kilka subiektywnych dlaczego?
- bardziej modułowa konstrukcja korzystająca z możliwości gemów - co pozwala na precyzyjną kontrolę czego i w jakiej wersji używamy,
- koncepcyjna zgodność z Railsami w tym także podobny szkielet aplikacji - powoduje to, że nie trzeba dokonywać resetu wszystkiego czego się nauczyliśmy, co więcej IDE dostosowane czasem na siłe do Railsów daja rade i z projektem Merbowym,
- otwarcie się na inne ORMy niż Active Record (przy okazji bezbiura testowałem wszystko co ma w nazwie/opisie orm i jest w Rubym - niestety narazie produkcyjnie i czasowo najbardziej opłacalny jeszcze jest AR ale zdecydowanie idzie nowe),
- lepszej jakości architektura i kod samej biblioteki,
- wygodne konstruowanie routingu dla aplikacji - sam kod routera jest znacznie czytelniejszy niż magia w railsach, co pozwala dostosować obsługę urli do nadszczególnych przypadków,
- koncepcja parts - czyli takich prostych komponentów dla aplikacji webowej zrobiona prosto ale wystarczająco do większości zastosowań,
- i chyba niemniej ważne - firma w której pracuje Ezra Zygmuntowicz (autor Merba) dostała w styczniu zastrzyk gotówki więc będzie i dodatkowy motor rozwoju m.in dla Merba.
Co z wadami? Oczywiście są, ale większość z nich to moim zdaniem wady wieku dziecięcego, nic czego nie da się obejść i załatać w kilka minut. Chyba główna wadą jest brak miodu dostarczonego przez railsy - a to nie ma generatora do czegoś, a to brak jakiejś magicznej funkcji operującej na napisach i takie tam. Najsłabszym elementem Merba na dziś jest chyba Mailer, tam natrafiłem na najwięcej błędów i uproszczeń (chodzi głównie o obsługę encodingu) ale to także da sie obejść.
Ogólnie jestem bardzo poztywynie zaskoczony możliwościami i dojrzałością projektu. Merb raczej zastąpi Railsy (przynajmniej w mojej skrzynce z narzędziami). Dla osób lubiących wykresy jeszcze porónanie obu projektów.
[merb ruby]
solnic said,
luty 5, 2008 @ 18:32
Dobrze Cie rozumiem, ja tez jestem na etapie odstawiania RoR’a, 2.0 pokazalo w jak bardzo zlym kierunku idzie ten projekt, nie ma co czekac na cud, tylko trzeba sie brac za alternatywy.
Moglbys cos wiecej napisac na temat Twoich przygod z alternatywami AR? Osobiscie jestem pod duzym wrazeniem DataMappera, mimo, ze jest bardzo mlody.
daniel said,
luty 5, 2008 @ 18:55
@solnic
Postaram się sklecić posta cross ORM szczególnie, ze w miarę na świeżo mam w głowie różne przeboje. Ale właśnie w DM upatruje przyszłego fajnego orma dla rubiego.
Radarek said,
luty 5, 2008 @ 21:14
Jeśli komuś nie pasuje ror 2.x, a 1.2.x za to tak, to nie widzę problemu by używać tej drugiej wersji. AR także nie jest na sztywno spięty z ror, nie ma problemu by użyć co innego (aczkolwiek odpadają wtedy migracje, przynajmniej te railsowe).
Merb już w tej chwili jest świetnym frameworkiem, mi także podoba się inżynierskie podejście Ezry, co owocuje kodem mniej magicznym, a bardziej jasnym i przejrzystym. Moim zdaniem to trochę różne projekty. Merb aspiruje do bycia bardziej komponentowym, railsy od początku narzucają pewną ścieżkę (defaultowy AR, rjs = prototype + scriptaculos itp). Te dwa frameworki jak najbardziej mogą istnieć obok siebie. Najważniejsze jest to, że coś się dzieje w tej kwestii, bo Ruby to nie tylko railsy :). Jest potrzeba by powstało coś innego (w pewnych kwestiach lepszego) i znaleźli się ludzie by to zrobić (podobnie można odnieść to do alternatywnych interpreterów).
solnic said,
luty 6, 2008 @ 11:19
@Radarek
Ja za to widze, po to rozwija sie software, zeby dawac uzytkownikom nowe, stabilniejsze, bezpieczniejsze i bardziej wydajne wersje, a nie po to, zeby mowic “jak Ci sie cos nie podoba, to uzywaj dalej starej wersji”. Takie podejscie jest malo profesjonalne, uzytkownicy RoR nie sa traktowani powaznie, mi to osobiscie bardzo nie odpowiada. RoR byl juz dawno krytykowany za wprowadzanie zbyt radykalnych zmian, ktore bardzo utrudniaja migracje aplikacji do nowych wersji frameworka. Byly problemy z przejsciem z 1.1.x -> 1.2.x, nie wspominajac o przejsciu z 1.2.x -> 2.0 - jak dla mnie paranoja.
W kwestii ORM masz racje, mozna wymienic AR na inny, chociaz nie jest to az tak proste i przyjemne jak w Merb :)
daniel said,
luty 6, 2008 @ 12:38
@Radarek
Moje trzy grosze - podoba mi się REST (żeby nie było, że jestem wojującym anty-) ALE - ale nie zawsze ma sens taka konstrukcja aplikacji. Mówie o realnych aplikacjach, nie o przykładach czy wprawkach. Zbyt silne narzucanie mi jako architektowi *mojej* aplikacji jak mam ją zaprojekotwać to chyba lekka przesada. Dla mnie ror w tej chwili byłby świetnym rozwiazaniem do budowy zewnętrznego API dla aplikacji - do tego nadaje się świetnie - jednocześnie szkoda, że już tylko do tego.
@sonic
podpisuje się oboma rękoma - zwłaszcza, że ‘uzywaj starej wersji’ oznacza no to sam sie wpakowałeś w version lock-in (o którym pisałem czas jakiś temu)