Po pierwsze nie mozemy tu porownywac RoR i PHP z oczywistych wzgledow. Czy php jest frameworkiem? Czy Ruby zostal stworzony dla aplikacji webowych? Dzieki RoR wszytko sie zmienia dla Ruby.
Zrobcie sobie test goglowania jakosciowych materialow o Ruby, RoR czy innych Rubowych frameworkach i porownajcie z wynikami dot. PHP. No i wlasnie, mimo, ze google daje nam 6 krotnie wiecej wynikow na fraze ‘php programming’, sprobujcie sie przekopac i znajdzie jakosciowy tematy o php. Moim zdaniem najwiecej jakosciowych a na dodatek innowacyjnych materialow jest na temat jezyka RUBY i frameworka RoR.
Jaki wniosek wyciagnalem z 2 lat bycia programista RUBY?
Dzieki wysokiemu i trudno dostepnemu wejsciu w swiat RUBY, glownie zainteresowali sie tym jezykiem dojrzali i kumaci programisci, ktorzy rozwineli sie w jezykach takich jak PYTHON, PERL, JAVA, ERLANG.
Wedlog DHH RoR ma sie dobrze, nie przygotowywali go na dzielone hostingi. Pytanie dlaczego jest ciezki i dla wielu zbyt powolny(??).
Oczywiscie odpowiedzi mozna znalezc na necie, jedna z nich jest, ze optymalizcja jest zbyt kosztowna, kiepski framework zwieksza czas pracy i opoznia projekt, inna poprawna opinia: tania jest pamiec na procesy.
Ciekawy jestem w jakiej sytuacji bylibysmy teraz jesli przed RoR, pojawilaby sie ‘wersja’ RUBY a’la PHP, stricto dla webu. Piszesz byle co wrzucasz i dziala, powiedzmy, HMM rewelacja.
tczubiński: w dużej mierze zgodzę się z Tobą (choćby z tym, że za Ruby biorą się raczej kumaci, bo Ci gorsi po prostu nie dadzą rady). Jednakże nie ma to związku z tym, że fajnie by było stawiać lekkie aplikacje (forum, galerie) tak jak w php, bez bawienia się w stawianie serwerów aplikacyjnych, a co ważniejsze, by to chodziło sprawnie na share hostingu.
Wiesz, mi nie chodzi koniecznie o wrzucenie Railsów na serwer “tak jak aplikacje php”. Rozpocząłem ten temat i zainteresowałem się rozmowami, bo brakuje łatwego podpięcia interpretera rubiego na serwerze. Jeżeli chodzi o Railsy, to nie wiem jak to mogłoby wyglądać, nie wiem czy w ogóle jest możliwe i nie wiem co z tego wyniknie, ale jeżeli ludzie by się nad takimi rzeczami nie zastanawiali, to pewnie dalej trzeba by się bawić w fcgi.
To, że się jednak da napisać mniej żrący framework pokazał Ezra Zygmuntowicz ze swoim merbem. Jest szybszy i zjada około 2 razy mniej pamięci przy pustej aplikacji (nie wiem jak to wygląda na realnych aplikacjach, ale podejrzewam, że podobnie). Teoretycznie mongrel i proxy to bardzo łatwe/fajne rozwiązanie, ostatnio popularny robi się sporo szybszy thin, ale jednak jak ktoś nie dysponuje serwerem z dużą ilością ramu, to czasami może być ciężko. Mam nadzieję, że to co mówi PaK o rubiniusie się sprawdzi. Brzmi ciekawie
I nie mam pojęcia w czym upatrujesz tą wysoką barierę wejścia w Ruby/RoR Może już nie mam obiektywnego spojrzenia na naukę nowych języków programowania/frameworków, ale wydaje mi się, że nie jest dużo trudniej niż w przypadku php
czy w końcu przyjdzie czas na lekkie serwowanie aplikacja a’la php ? Ej, chce Wam sie robic male aplikacje ? (zartuje)
Czy czasem nie zauwazyliscie, ze raczej gonitwa idzie w kierunku wydajnosci VM ?
np. wspomniany Rubinius, lub inne podobne cacka, ale nadal to idzie w kierunku wydajnosci. Nikt sie jakos nie interesuje mod-ruby itp.
Hmm czy to nie dziwne? A moze jakas zmowa?
Podobaja mi sie te polowiczne, ale jak teraz potrzebne zmiany, np wspomniany Thin.
Z przyjemnoscia przyjalbym pod swoje strzechy dosc idealne rozwiazanie dla RoR. A mianowicie mozliwosc odpalenia jednej Railsowej instancji, zamrozenie Class Active* lub cos w tym stylu i wspoldzielenie tychze Class miedzy aplikacjami napisanymi pod Railsy Nazwijmy to po imieniu MOD_RAILS z jednym siedzacym procesem 30-50 megowym.
Jesli wszelkie teraz podobne ‘maszyny’ jak Rubinius dadza taka mozliwosc to czekam z niecierpliwoscia. A i mysle, patrzac na niechec programistow do ruby_mod, że napierw sie doczekamy MOD_RAILS anizeli dobrego mod_ruby.
Tak sobie kiedys dawno temu myslalem, ze Camping jest dla wytrwalych, i dobrze, że wtedy zmienilem zdanie. Warto wiedziec, ze mozna cos malego napisac, nieco mozolniej ale jednak.
Przyszla mi jeszcze jedna mysl:
Konwerter napisanej aplikacji w RoR na Campingową. I juz jest lekkosc pod jednym poleceniem ‘rake ror_convert_to_camping’. To tylko taka tam mysl, nie bierzcie tego serio
Więcej na blogu http://izumi.plan99.net/blog/[/quote]
Ja wiem, czy upgraniony? Jak sobie wyobrazasz zmiane w kodzie? Restart calego apache’a za kazdym razem (i w raz z nim wszystkich innych serwisow i aplikacji)? Przeciez to chore. Takze zagniezdzanie railsos na kazdy fork Apache’a nawet jak ma byc uzyty do odczytu statycznego HTML’a? (dlatego ucieklem od mod_* na rzecz fastcgi i potem proxy do mongrela/thin/ebb) Na stronie pisza, ze atrybuty klas nie dzialaja poprawnie. Nie mozna miec wiecej projektow RoR jak jeden na jeden Apache. Bez sensu. Ktos chyba za bardzo sie podniecil mod_php gdy to tworzyl.
To jest z raczej niemozliwe, bo Rails nie jest wielowatkowy. Musisz uzywac izolowanych procesow co w praktyce w Apache’u sprowadza sie do trybu prefork, a nie worker. I tym samym kazdy fork ma zagniezdzony interpreter Rubiego z tymi Railsami. Ogromne marnotrawstwo zasobow serwera. Nie ma sensu przenosic rozwiazan z php do ruby (ani pythona) bo tam to dziala inaczej. Kazdy request tworzy i niszczy na nowo wszystkie zasoby pehapa. Cos takiego w Ruby byloby samobojstwem. mod_php w Apach’u zajmuje relatywnie malo pamieci bo jest calkowicie napisany w C. tu musisz zmiescic w pamieci caly interpreter i kod Rubiego dla Rails. jednym slowem, mod_rails to kuszaca, ale raczej slepa uliczka.
@jzabiello: Zgadzam sie z Toba w 99%. Ale wiem, że na pewno jest gdzies rozwiazanie.
Osobiście to od lat korzystam tylko z dedykowanych serwerow i vps-ów, a przy tworzeniu większych rzeczy to jest to jedyna droga.
Od początku przypadł mi do gustu Nginx + mongrel, eksperymentowalem też z róznymi “wersjami” mongrela. Aktualnie jestem zadowolony z Thin.
Cytując swoja wypowiedz, ktora była jedna z kontynuacji w tym watku: “Z przyjemnoscia przyjalbym pod swoje strzechy…”, traktuje narazie jako abstrakcyjne wyobrażenie. Mimo, że nigdy nie bede korzystal z MOD_RAILS czy tez MOD_RUBY, zaintrygowal mnie blog na jaki trafilem i ich podejscie do problemu.
Tak jak w styczniu zauwazylem, ze predzej pojawi sie MOD_RAILS, pare miesiecy minelo, zmysly sie jeszcze bardziej wyostrzyly tak wiec bede teraz czekał jak ktos stworzy DEDYKOWANY SERWER WWW przeznaczony tylko i wylacznie pod RAILSY. Mysle ze to realne
RAILSY nie sa wielowatkowe, no to nich bedzie DEDYKOWANY SERWER WWW przeznaczony tylko i wylacznie pod MERBA.
O, i tym to bylbym zainteresowany. Jeszcze lepiej
[quote=tczubinski]DEDYKOWANY SERWER WWW przeznaczony tylko i wylacznie pod RAILSY
…
DEDYKOWANY SERWER WWW przeznaczony tylko i wylacznie pod MERBA.[/quote]
…znaczy coś jak mongrel/thin/ebb/pewnie_jeszcze_milion_innych?
Kolesie od Rubiniusa chcą zrobić sensowny (działający i kompatybilny z Railsami) mod_rubinius dla Apacza.
Co do dzielonych hostingów: czas procka, ram i przestrzeń dyskowa są coraz tańsze. Railsy się średnio nadają na dzielony hosting, głównie dlatego, że nawet niewielka aplikacja wymaga ramu mierzonego w dziesiątkach MB. To samo tyczy się wszystkich chyba aplikacji napisanych w jakimś sensownym frameworku, a tych będzie coraz więcej - kosztem koszmarków w PHP. Dzielony hosting po prostu traci rację bytu, a przyszłość leży raczej w VPSach.
VPS na SliceHost kosztuje dwukrotność ceny dzielonego na DreamHost, a warunki - jeśli chodzi o procek, ram i swobodę - są nieporównywalne.
BTW, mam sklep w RoR postawiony na DreamHost, ale będę niedługo stamtąd uciekał.
