Rails 3

Dyskusje
21

Dla mnie jedną z największych zalet będzie to, że wszystko co do tej pory napisałem i jest w użyciu to railsy - nie ma żadnych szans, żeby klienci nagle zdecydowali się na rewrite na merba (co byłoby swoją drogą w większości przypadków kretyńską decyzją) i jeżeli chodzi o moje aplikacje, to też raczej nie miałbym na to czasu. Dlatego będę mógł powoli dostosowywać aplikacje do Rails 3 i korzystać z dobrodziejstw obu frameworków.

Dodatkowo wspomniani wyżej klienci - cały czas jest dużo klientów, którzy przychodzą i mówią “chcę to w PHP”, teraz trochę z nich pewnie będzie mówić “chcę to w RoR” (ze względu na rosnącą popularność" - długo trzeba by czekać na promocję merba. Wystarczy spojrzeć ile potrzebowały railsy na to, żeby ktokolwiek oprócz programistów kojarzył co to jest.

Kilka słów a propo wad (tymi komentarzami nie chcę pokazać, że się z tym nie zgadzam, bo na pewno to co napisałeś to są wady, ale chciałem tylko napisać dlaczego są one jeszcze mniejsze niż się wydaje :wink: )

[quote=apohllo]Wady:

  1. Problemy decyzyjne - im większy zespół, tym proces podejmowania decyzji jest trudniejszy.[/quote]
    Nie sądzę, żeby to był jakikolwiek problem. Ostatnia decyzja pokazuje, że to są dojrzali programiści, którzy stawiają dobry kod ponad jakieś osobiste wycieczki. DHH z kolei pokazał, że to już nie jest “jego framework” i że jest w stanie dać go do poprawienia ludziom od merba - to jest radykalna zmiana.

Nie wiem co dokładnie masz na myśli pisząc zależności, ale railsy 3 mają być modularne, w stopniu mniej więcej takim jak merb teraz (merb-core i merb-more, czyli tak naprawdę zestaw pluginów rozszerzających core). Tak jak powiedział Matt Aimonetti w swojej prezentacji o pluginach: “… czyli tak naprawdę dodając nowe rzeczy do merba przez większość czasu pisaliśmy pluginy”. Przy takim podejściu bardzo łatwo jest wymienić specyficzne części frameworka na swoje własne rozwiązania (głównie dzięki uporządkowanemu i udokumentowanemu API i zasadzie “it is a bug if you can’t do something without using alias_method_chain”).

Na pewno nie będzie to kwestia 15 minut, ale tak jak pisałem powyżej, obecnie na rails3 będą pracowali ludzie od merba i od railsów. Wszyscy oni (+ community) mają jakieś projekty w obu frameworkach, więc obie grupy będą chciały zrobić przejście możliwie jak najłatwiejsze (jeżeli nawet nie z chęci pomocy programistom, to z czystego egoizmu).

Myślę, że dzięki RACKowi i passengerowi niedługo nie będzie już problemu z hostowaniem żadnego frameworka, który opiera się na racku.

Ja jestem dobrej myśli - jeżeli podjęli tak trudną decyzję, to nie sądzę, żeby nagle zaczęli się kłócić o to jak zaimplementować daną rzecz. Zauważ, że większość zmian z ostatnich tygodni (miesięcy?) w edge railsach było tak naprawdę doganianiem merba pod niektórymi względami: pluginy jako gemy, widoki i kontrolery w pluginach, railsy działające na racku, metal middleware, przepisany action view, wcześniej ogromna praca włożona w to, żeby railsy były thread safe.

Nie chcę być nadmiernym optymistą, ale nie ma opcji, żeby się nie udało :stuck_out_tongue:

22

Jak powiedział PaK, nie zapominajmy o polityce i kasie (już widzę ten tony papieru poświęcone migracji i co jest grane w rails3 plus festiwale szkoleń itp. uff, ale będzie machina). Mówienie teraz plus/minus jest na wyrost, bo wszystko to na razie sfera pomysłu, niż realnego kodu, oto dwa światy chcą być jednym i każdy zapewnia, że to będzie ich świat, co jest grane? Ktoś na merbowym blogu zasugerował, aby to nazwać merbrails1.0, na co dostał odpowiedź, że z wiadomych względów tylko szaleniec by zrezygnował z brandu ‘rails’, ‘merba’ było łatwiej poświęcić. W domyśle tej odpowiedzi brzmiał nowy framework jak nic, do migracji wypuści się kilka biblii na rynek i niech ludzie się cieszą.

23

Wygraja psychologicznie - nie bedzie przymusu zmiany marki, tak jak drogus wsponial, nie ma szansy na przestawienie klientow obecnych z rails, na merb, to kosztowalo zbyt duzo energi. Programisci natomaist nie bede musieli zmieniac nic w swojej swiadomosci. Oczywiscie rozumiem to ze nie mozna trzymac sie jakiegos konkretnego framework’a, z drugiej jednak strony, rails jest tworzone do webdevelopmentu, wiec jesli ktos jest webdeveloperem i uzywa jednej dobrej technologii, to co w tym zlego ?
Wygraja ekonomicznie - nie trzeba bedzie promowac od nowa merb’a, nie bedzie trzeba porownywac go z rails i zjadac sie nazwajem slowami “rails jest lepsze od merb tu, a tu jest gorsze” to nie jest produktywne. Koszt tworzenia dokumentacji, tez bedzie owiele mniejszy, teoretycznie to OS i wszystko jest zadarmo. Ale to tylko zludzenie :slight_smile: Mysle ze moze powstac oddzielny Railsconf … ukierunkowany bardziej technicznie a mniej biznesowo.
Wygraja technicznie - rails stanie sie lepszym frameworkiem
Wygraja strategicznie - jesli teraz okazalo by sie ze rails… cos co mialo przerwocic swiat webdevelopmentu do gory nogami odeszlo w zapomnienie bo ktos zrobil technicznie lepszy framework, to za 2 lata moglo by sie okazac ze ktos znow zrobil cos lepszego i znow zrobilibysmy 1 krok naprzod i 2 kroki w tyl. Teraz, idac w kierunku 1 marki, 1 frameworka, 1 dokumentacji i 1 teamu jest znacznie trudniej zrobic cos lepszego od tego co potencjalnie juz jest lepsze :slight_smile: moze troche zamotalem ale chodzi ogolnie o to ze samemu nie jest sie w stanie byc madrzejszym od 10 osob z core team’u. Nawet jesli masz jakies genialne pomysly, to i tak beda one tylko malal czescial calosci pracy ktora docelowo musialaby zostac powielona i wykonana poraz n’ty. Teraz jesli jesli ktos znow bedzie mial jakis lepszy pomysl a rails bedzie z zalozenia modularne, bedzie mogl go latwiej prowadzic, latwiej oddac do uzytku… i wygramy wszyscy.

24

Jest w tym coś złego? Nic dziwnego, że ludzi chcą zarobić na tym kasę, czemu robić z tego jakikolwiek problem? Wiadomo, że w związku z kryzysem wszyscy chcą ciąć koszty - EY zwolnił programistów, którzy pracowali nad Rubiniusem, połączenie z railsami też w dużym stopniu może być dla EY efektywne finansowo.

Dla mnie to jest całkowicie normalne i dopóki w rezultacie dostaję coś fajnego, to nie wnikam głębiej - szczególnie, że dla mnie to jest bardzo dobra decyzja z technicznego punktu widzenia, abstrahując od korzyści finansowych i polityki.

Zgadzam się całkowicie. Też nie chciałbym, żeby to było coś innego niż rails - nie rozumiem czemu niektórzy mają z tym problem?

25

Święte słowa. Wczoraj na #rubyonrails.pl kilku miłośników merba bardzo się nie zgadzało z tą decyzją i pytali wiele razy Katza na #merb dlaczego railsy wchłoną merba, a nie na odwrót i dlaczego chcą iść pod górkę.

Ja nie jestem na tyle doświadczony, żeby stwierdzić co jest łatwiejsze i wydajniejsze i czy to może się technicznie udać.

Yehuda Katz napisał, że przed tą decyzją przejrzał kod railsów i stwierdził, że od momentu kiedy poprzednio tam zaglądał zmieniło się bardzo dużo, dużo części było zrefaktoryzowanych i przepisanych. Jeżeli on twierdzi, że to jest dobra decyzja i że jest to do zrobienia, to ja mu wierzę.

26

[quote]1. Problemy decyzyjne - im większy zespół, tym proces podejmowania decyzji jest trudniejszy.
…
Nie sądzę, żeby to był jakikolwiek problem.[/quote]
Hmm? Doprawdy? To dlaczego w ogóle pojawił się Merb?
M.in. dlatego, że choć Railsowcy twierdzili, że wydajność nie ma znaczenia, Merbowcy doszli do wniosku, że jednak ma i poszli w tym kierunku.

To, że teraz połączyli swoje siły, to wspaniała decyzja, ale jest mnóstwo przykładów z OS, gdzie sytuacja jest dokładnie inna. Przypomina mi się np. kwestia rozwoju schedulera dla linuksowego kernela. Jeden z deweloperów spoza Core team stworzył bardziej wydajną wersję (w szczególności lepiej sprawdzała się na desktopach), ale decydenci nie chcieli jej włączyć do głównej dystrybucji i skończyło się tak, że gość rzucił wszystko w cholerę. Wielu użytkowników bardzo tego żałowało, a wszystko rozbiło się o to, że kilku gości nie mogło się po prostu dogadać.

Zależności pomiędzy modułami wchodzącymi “w skład Rails 3”. Chociażby fakt obsługi trzech ORM-ów. O ile nie ma specyfikacji API agnostycznej względem implementacji, zawsze któreś rozwiązanie będzie bardziej dostosowane, a inne mniej, nawet jeśli to drugie jest lepsze, bo trzeba się zdecydować na pewien “wspólny mianownik”, a jego wypracowanie nie jest banalne. A zasada jest prosta - im system jest większy, tym wprowadzanie zmian jest trudniejsze, czytaj kosztowne. Na szczęście Railsy są już dosyć dojrzałym frameworkiem i pewne wypracowane rozwiązania można po prostu uznać z “wystarczająco dobre”.

A ogólnie też się z Tobą zgadzam - “wady” nie są takie istotne. Mam nadzieję, że projekt wypali. Ja też jestem optymistą :slight_smile:

27

Chodzi Ci o sprawę Cona Kolivasa i jego schedulera? Oj, to bardzo tendencyjnie i upraszczająco przedstawiłeś zagadnienie, które było o wiele bardziej skomplikowane. Nie potrafię powiedzieć czy rację miał Con czy Linus, ale tam naprawdę było sporo zmiennych i wątpliwości, a owa lepsza “wydajność” była tak naprawdę niezmierzona (i prawdopodobnie niezmierzalna) - a wrażenia subiektywne już nikogo nie przekonają od czasu teorii placebo :wink:

Plusem historii jest to, że niedługo później pojawił się w kernelu - mainline’owym - scheduler bazujący na podobnych założeniach (i też zorientowany na desktopy) co wersja Cona, ale napisany w sposób niebudzący u Linusa zastrzeżeń.

28

Dalej nie rozumiem jaki w tym problem :slight_smile:

Oczywiście zawsze będzie tak, że jedne rozwiązania mają większe wsparcie niż inne, ale jeżeli Rails 3 będą miały modularność merba, to tak naprawdę nie obchodzi Cię czy coś wejdzie do projektu, czy nie, bo możesz podmienić ten “moduł” swoim własnym.

Mówiąc o wspomianych przez Ciebie ORMach - Merba przy dość małym community z powodzeniem można było używać z 3 ORMami i nie było pewnie żadnego problemu z dopisaniem pluginu do obsługi innego ORMa. Nawet widziałem sporo pluginów, które były pisane tak, żeby działały z 3 ORMami. Dlatego nie rozumiem co rozumiesz przez “wejście do projektu”.

29

Oczywiście że można, nawet javowcy (mając 20x gorszy język :wink: - to wyrazy współczucia, a nie pogardy!) już dawno sobie z tym poradzili poprzez Java Persistence API. Może nie do końca jest to wspólna warstwa abstrakcji dla ORMów, ale kaman - chcecie zmieniać ORM w połowie rozwoju aplikacji? Bez sensu.

A pozostałe składniki railsów są już teraz bardzo słabo zależne od AR, więc nie rozumiem gdzie problem. Większym wyzwaniem będą helpery AJAXowe (pomijam już to że są biedne okrutnie i niepraktyczne do zastosowań ponadpodstawowych :stuck_out_tongue: ) niezależne od frameworku JS.

30

Looknij na wspaniałe prezentacje o jQuery i Merbie. Efekt, jaki daje helper railsowy można równie łatwo uzyskac i to unobtrusive w jQuery. A każde niestandartowe ozszerzenie funkcjonalności helpera w railsach to ból, a w jQuery jest proste lub wręcz banalne, jeśli autor pluginu jest pragmatyczny :slight_smile:

A jeśli chodzi o szczegóły implementacyjne, to mam nadzieje, że Drogomir znajdzie czas na opisanie tego :slight_smile:

31

Prawdę mówiąc zbiera mi się w okolicach gardła i idzie do góry za każdym razem, kiedy słyszę o unobtrusive javascript. Mamy 2008 rok, goddamit! Nawet moja komórka obsługuje JS. :wink:

32

Nie jestem tego do końca pewien, ale termin unobtrusive javascript zaczął być promowany jakoś tak rok temu. Mimo, że coraz to więcej urządzeń, klientów itp. obsługuje javascript coraz więcej mówi się o UJ, więc chyba jest w tym jakaś logika :slight_smile:

Moim zdaniem w UJ bardziej chyba chodzi o separację javascripta od html-a niż o zapewnienie działania strony na czymś co nie obsługuje javascripta.

33

Dokładnie.

Większość aplikacji łebwazeło nie działa w pełni bez włączonego javascripta. Tak jak kiedyś pisałem na blogu - większości helperów railsowych da się używać tak, żeby to działało i bez javascripta - to nie o to chodzi. Jest dużo innych wad.

Dla mnie helpery javascriptowe mogliby całkowicie usunąć z railsów, więc szczerze mówiąc mało mnie ta kwestia obchodzi, jak mają coś schrzanić to mogą właśnie tą część :wink: