Witam. Mógłby mi ktoś opowiedzieć trochę o Ruby on Rails? Co to takie, jak się to je, jakaś składnia (podstawa) (coś typu <?php echo 'Pierwszy skrypt'; ?>) oraz jakieś warte wiedzy informacje i dlaczego to Ruby (w frameworku RoR) a nie PHP? Z góry dziękuję ;-)

http://letmegooglethatforyou.com/?q=Hello%...by%20on%20Rails

W zeszlym semestrze miałem na studiach przedmiot o RoR i od tej pory wszystkie nowe projekty pisze wlasnie w tym framewowku

1. Co to takie, jak to sie

Ogolnie RoR to framework implementujacy wzorzec mvc. Zawiera w sobie wbudowanego orm-a (active record), system templatow, wiele pomocnikow sluzacych do generowania elementow kodu html (szczegolnie forumalarzy), caaaaaaaale mnostwo pluginow na sieci, dzieki ktorym nie musisz pisac wszystkiego sam a ich instalacja jest banalnie prosta (script/plugin install sciezka_pluginu), rjs czyli cos co generuje kod js za ciebie tzn. nie pieszesz document.getElementById('cos') tylko page['cos']

Do obslugi ajax-a programisci RoR wybrali prototype co wcale nie znaczy ze musisz znac ich skladnie, od tego tez sa pomocniki np.

link_to_remote "nazwa linku", url => {:controller => :main, :action => :add), :update => 'moj_div'

i wiele tego typu uprzyjemniej

2. Pierwszy skrypt (zakladajac ze wszystko masz poustawiane)

rails moj_projekt -d postgresql

i masz gotowy szkielet projektu z przykladowym plikiem konfiguracyjnym dla postgresql-a

3. Dlaczego ruby??

Ruby to jezyk z bardzo fajna skladnia Braki srednika w linijkach wyzej to nie blad, jesli nie piszesz dwoch polecen w jednej linii nie musisz ich uzywac poza tym mozna pisac takie smieszne konstrukcje jak:

300.times do .....

obiekt.nil?

zmienna.empty?

Poza tym z ciekawych rzeczy obsluguje wielodziedziczenie i jak juz sie czlowiek przyzwyczai (bo skladnia jest jednak totalnie rozna od php) to pisze sie bardzo przyjemnie

I tak podsumowujac pisanie w tym sprawia mi autentyczna radosc co przy php-ie powoli przemijali (jedyny problem to hosting do railsow, ktorego w polsce w zasadzie brak :/ )

Jakbym czytał opis Symfony
Z tym wielodziedziczeniem to akurat nie jest jakić postęp, a wręcz przeciwnie.

Nie dziwota, skoro chodzą ploty, że jeden serwis przepisali na RoR po to, aby potem z powrotem przepisać na PHP
Tak poza tym, to no offence, peace itd itp, bo ja nie śmieję się z Ruby czy RoR, tylko z powoli narastających mitów, które przypisują magiczne cechy zarówno językowi, jak i frameworkowi.

Pozdrawiam.

Hosting to nie problem. Jeżeli ktoś chce stworzyć konkretny projekt w dowolnym języku i frameworku to nie będzie tego stawiał na shared hostingu, tylko na virtualu lub dedyku, gdzie dowolnie może sobie skonfigurować serwery i dostępne na nich usługi.

ORM to jest chyba nie wbudowany w same Railsy, tylko dostępny jako Gem. A o systemie szablonów nic nie słyszałem. Chodzi ci o HAML?



Chyba mylisz wielodziedziczenie i mixin-y. Co moim zdaniem nie zmienia faktu, że średnio toto rozwiązuje cokolwiek w tej kwestii. BTW podobny manewr można i w Symfony wykonać.



Eee, nie przesadzałbym, ja znam http://www.cal.pl/.

@qqrq:

Co do wielodziedziczenia to rzeczywiscie nieprecyzyjnie sie wyrazilem mozna osiagnac podobny efekt wykorzystujac wlasnie mixiny

Jeśli chodzi o ActiveRecord to owszem jest dostepny jako gem, ale jeszcze nie widzialem zeby railsy korzystaly z innego wiec w zasadzie nie ma tu wyboru jaki daje np Merb

@cysiaczek:

Ze strony symfony

i tyle w kwestii wrazenia jakbys czytal opis symfony

Generalnie nie mitologizuje railsow ani ruby'ego. Zdecydowalem sie na pojscie w tym kierunku bo na zajeciach naprawde przyjemnie sie i szybko tworzy sie w nim aplikacje oraz ze wzgledu na duza ilosc gem-ow i pluginow a ja jestem leniwym czlowiekiem, nie lubie pisac wszystkiego sam

Poza tym jak dla mnie ludzie od php-a maja dziwaczne pomysly. Chocby z oddzielaniem namespac-ow '\', po prostu troche smiesznie to wyglada:

[PHP] pobierz, plaintext 
<?php
MojaAplikacjaJakasKlasa::JakasMetoda();
?>
[PHP] pobierz, plaintext 

i jeszcze nie mozna napisac '\' tego w edytorze ;P

Co do namespace'ów, to nie ten temat.

Temat: Nowy_namespace_separator_w_PHP

1. Ja wiem. czym się inspirowali developerzy Symfony - nie podejrzewaj mnie o aż taką ignorancję
2. Nie mówię, że akurat Ty mitologizujesz.
3. Jedyne porównania jakie można robić to Ruby vs PHP i RoR vs Symfony. Tymczasem tendencja jest taka:
http://www.railsenvy.com/2007/5/16/hi-i-m-...on-rails-part-3
Tak, mam poczucie humoru, ale społeczność RoR zdaje się pomijać zbyt wiele faktów, a w tych filmikach z premedytacją kłamią. Zniechęcili mnie do siebie - tym jednym filmikiem.

Pozdrawiam.

To chyba nie były ploty. O ile pamiętam, to migracja była spowodowana problemami wydajnościowymi; RoR po prostu nie wyrabiał.


A kto Ci każe wszystko samemu pisać w PHP? Mało masz frameworków? Potem wychodzą fanatyzmy RoRowców (tak, powiem: fanatycy; chociażby CakePHP), którzy przedkładają wygodę nad wydajność aplikacji. Po co się męczyć, skoro można kolejną kostkę RAM-u dołożyć?

Owszem, czas pracy programisty jest cenniejszy niż kilka kości, ale źle zaprojektowane aplikacje w jakimkolwiek języku spowodują dodatkowe koszty i wtedy już nie będzie tak łatwo, jak z RAM-em.

Mnie osobiście denerwuje takie fanatyczne podejście, bo właściwie, to nie ma się czym zachwycać - wszystkie (większość?) możliwości RoR możesz mieć i w PHP; kwestia dopisania odpowiednich modułów/wrapperów.

"Będę" pisał framework w Brainfvcku, też przyjemny język, zbiorę odpowiednią grupę ludzi i będziemy promować. ;P

Hosting na cal.pl i innych z direct adminem - nawet szkoda sie smiac z tego. Testowalem na lap.pl - TYLKO tryb development, bez ssh, mulilo nieziemsko - po prostu ROR ma inne wymagania niz PHP: ssh, wiecej dedykowanej! pamieci na aplikacje.

Railsy sa mocno powiazane ze swoimi bibliotekami: ORM + JS - co dla jednego bedzie zaleta (super je wspieraja), dla drugiego wada (trudniej zmienic je na cos innego)
Nie podoba ci sie to: wybierz Merba

@cysiaczek:

Tja, na pewno przez brak hostingu przepisali cala aplikacje (brak. hmm 2k/rok za dedyka?) po tym jak inwestora zdobyli?



Tak, tak sie powinno porownywac. Tylko ile aplikacji jest pisanych na porzadnych FW w PHP?
Ruby/Railsy zaczely sie od jednego dominujacego FW wiec panuje stereotyp (czesciowo sluszny) ze appy w PHP to wlasnie spagetti

hahaha

Filmik rzeczywiscie jest troche pojechany po bandzie i przerysowany, ale ja nie bralbym go tak bardzo serio i traktowal raczej jak cos w rodzaju kabaretu, a tam wszystok zawsze jest pomnozone razy 100

Pozdrawiam



przegladalem kolejne i jeszcze ta jest fajna tylko sie nie denerwujmy

http://www.railsenvy.com/2007/8/24/rails-vs-php

Bzdura!
Język Ruby powstał ok. 1995 a framework Ruby on Rails 10 [sic!] lat później.
Gdyby nie Railsy to Ruby dawno zdechłby a tak framework wyciągnął go za agonii zapomnienia. Pisanie, że w Ruby od razu pisano ładnie to paranoja To też kiedyś był śmietnik a dodatkowo mało popularny.
Nawet teraz Ruby musi walczyć o popularność z PHP a ponoć jest "lepszy". A że walczą takimi a nie innymi sposobami to już całkiem porażka zwolenników Ruby.

Kto pod kim dołki kopie...

To jest bardzo interesujaca wypowiedz:



Moze potrzebuje czegos takiego wlasnie I za jakis czas wroce z radoscia do php-a

"zaczely sie" w znaczeniu - zaczyly byc popularne.
Ruby by nie zdechl, skoro przy braku popularnosci bylo rozwijany przez 10 lat....
A malo popularny byl bo nie bylo manuali w jez. angielskim, a jedynie w japonskim

Siłą RoR, czy też np. Django i innych frameworków Ruby/Python to znacznie przyjemniejsze/łatwiejsze tworzenie kodu. Szybciej i łatwiej można stworzyć dobry kod implementujący potrzebną funkcjonalność. Nie są to rozwiązania na "proste" stronki, lecz na większe projekty, gdzie liczy się czas i potrzebne są bardziej zaawansowane technologie

No ok, to w czym to się różni pehapowej Symfony?
scaffolding
admin_generator
propel/doctrine jako abstrakcja danych
helpery (włącznie z obsługą Prototype)
predefiniowane tryby pracy
framework testów jednostkowych
rozbudowana baza pluginów (kilkaset)

Może coś pominąłem, ale w PHP istnieją niemal dokładnie takie same rozwiązania jak dla RoR. Grupa docelowa Symfony to też średnie i duże projekty (a do małych nadaje się po prostu wyśmienicie). Nie potrafię właśnie tego zrozumieć, że pomija się narzędzia napisane w PHP. Sformułowanie:

powinno zatem brzmieć przynajmniej tak:


Pozdrawiam

Symfony jak i inne PHP-owe frameworki cierpi bardziej z powodu języka niż technologii. Wystarczy że hosting zapewnia klient... i nie ma PHP5, albo ma, tyle że np. bez jakiegoś normalnego rozszerzenia/starą wersję i X innych przypadków. A w przypadku PHP na myśl przychodzi "zwykły" hosting, a nie virtual/dedyk/specyficzny hosting Py/Rb FastCGI (albo klient ma własny serwer, tyle że "admin" nie wie co to Debian i dlaczego nie ma do tego exe).

Symfony za wiele nie znam, ale w czasie gdy po CI rozglądałem się za czymś lepszym przyglądałem się Symfony, Prado, jak i Pythonowym frameworkom i wybrałem Django - bo okazało się debilnie proste "na starcie", natomiast Symfony wydało mi się trochę zbyt skomplikowane na starcie / a oba miały sporo interesującej mnie funkcjonalności (tu też zaważył fakt że chciałem też nauczyć się nowego języka - lecz ogólnego przeznaczenia).

A jak ktoś chce poczytać jaki ten PHP zły to są newsy na http://blog.zabiello.com/

Taa, już wcześniej czytałem ;D Facet ma dużo racji, ale nie przyjmuję do wiadomości opinii w stylu "PHP jest gówniany, więc frameworki PHP też są gównine".
Swoją drogą, używając Symfony odniosłem wrażenie, że jest bardzo mocno wzorowane na Struts i RoR i chyba nie ma co tu się wypierać, czy zaprzeczać. To różni programowanie od, powiedzmy, grania muzyki, że tutaj oryginalność jest znacznie mniej ważna od np. stosowania schematów ogólnie przyjętych za poprawne. To, że "wszyscy zrzynają od RoR", to nie jest aż takie złe - RoR wprowadził kilka naprawdę fajnych rozwiązań i chwała mu za to, a także chwała twórcom innych frameworków, że to doceniają.
I zgodzę się z przedmówcą - główną wadą PHP-owych frameworków jest sam PHP.

Dlaczego? Może nie rozumiem, ale proszę o odpowiedź.

Bo jego funkcjonalność na serwerach jest ograniczana, a nie rozszerzana

A jesli ktos narzeka na to ze ruby jest wolny, zawsze moze poczekac albo na Ruby 2.0 albo skorzystac juz teraz z JRuby (i przy okazji uzyskac dostep w ruby do bibliotek javy). Chociaz powolnosc ruby to mit nawet w przypadku obencje implementacji (1.8) w ktorej aplikacje bazowane na frameworkach rails(tutaj wiele zalezy od wersji i wlasnego kodu), lub w szczegolnosci merb bijal na glowe wydajnoscial symphony albo inne php'owe frameowrki. http://www.slideshare.net/mattetti/merb-pr...ug-presentation od strony 30. A jesli komus nadal to malo to JRuby potrafi przyspieszyc jeszcze bardziej dzieki wielowatkowosci systemowej.
Ale trzeba zapamietac jedno, 3-4 lata temu nikt nie wybieral ruby ze wzgledu na wydajnosc, bo jesli by tak bylo musial by byc totalnym hipokrytka, bo w tamtyczh czasach cruby bylo jedyna implmentacja, a deployment opieral sie na problematycznym fcgi, lub masakrycznym mod_ruby. Dzis mamy 3 rozne implementacje, posiadajace rozne zalozenia projektowae, ale dzielace wspolnie ta sama specyfikacje http://rubyspec.org/ przez to implementacje zachowaja kompatybilnosc. A rozwiazan deploymentowych jest jeszcze wiecej sa dobre i sa te troche gorsze, ale kazde nastepne pchnie ten jezyk coraz mocniej do przodu.

PHP jest kiepsko zaprojektowany. Zresztą najlepiej to chyba widać przy braku spójności nazw funkcji. Co tam jeszcze - brak pełnej obiektowości, brak wielowątkowości (jest tam jakieś rozszerzenie, ale podobno to lipa), brak namespaców (wiem, wiem, będą), kiepska wydajność, kaprawa konwersja typów, zbyt mała restrykcyjność dla developera (to jest wada tylko w kontekście tego, że PHP jest bardzo popularny), brak możliwości monitorowania uploadu (bez np. APC), itd, itp...



A kto tu narzeka, że Ruby zbyt wolny. ;) Kurcze, często ostatnio to słyszę od programistów i fanów Ruby-ego, że nieee, Ruby wolny wcale nie jest, ale jeśli byście jednak uważali inaczej, to poczekajcie no jeszcze trochę, to zobaczycie jaki jest szybki. ;) Spoko, jak będę potrzebował języka-rakiety to postawię raczej na Python-a. ;)



Do dużych projektów to jest raczej Java, czy .NET - chyba że wyróżniasz jeszcze kategorię "bardzo dużych projektów".

@qqrq - albo inaczej rozumiem "wielkość " projektu. Tą bowiem można mierzyć na kilka sposobów. Tylko w jednym wypadku warto pisać w javie - gdy pojedyncze requesty wywołują masę akcji w systemie, bo tu faktycznie każdy język wielowątkowy i kompilowany ma przewagę. Jeśli jednak masz projekt, który rośnie wszerz, czyli są dokładane kolejne funkcjonalności, to nie widzę potrzeby użycia Javy - dokłada się sprzęt
Tak ja to widzę okiem amatora w tych kwestiach
Z mitotwórczymi Rubystami postanowiłem nie dyskutować więcej, bo po prostu mnie nie przekonują, zwłaszcza ta prezentacja (odwoedźcie tą stronę - Merb jest wolniejszy od CodeIgnitera o około 30%.. po powtórzonych testach)

Pozdrawiam.

Mitotworczymi, no tak nie chcesz dyskutowac ale jednak zucasz fałszywe argumenty w dyskusji i sam tworzysz mity.

Nie sprawdziłeś, zrób to proszę i zapoznaj się z liczbami, które tak występują.
http://www.avnetlabs.com/php

Nom wydawalo mi sie jednak ze mowiles cos o poprzedniej prezentacji ;] Dzieki za link, wczoraj usiadlem do tego co gosc przygotowal i zaczolem przeprowadzac wlasne testy, mam zamiar dopisac jeszcze implementacje testu dla merb'a i zrobic pelne zestawienie, php, php + accellerator, ruby 1.8.6, ruby 1.8.6 ree, ruby 1.9.1, jruby

Tymczasem, zwroc uwage na to http://merbist.com/2008/11/30/latest-news-...erbland-nov-30/ testy z wczoraj, troche szkoda ze nie uwzledniaja php z accelleratorem dla cakephp i codeignitera, ale jednak bez tego merb i rails i tak jest wydajniejsze?

W wolnej chwili zerknę. Szkoda, że upierają się przy testowaniu codeignitera, który jest napisany w php4. Lepszy byłoby porównanie Symfony

Merb vs CI? CI jest bardzo prostym frameworkiem od strony kodu. Trochę jak porównanie print 'hello world'; z hello world w ezPublish Tego typu testy większego sensu nie mają. Jeżeli narzędzie jest wydajne (nie musi być najszybsze), ale pozwala bardzo szybko tworzyć dobry kod - to wygrywa.

No bardziej myślałem tutaj w kontekście serwerowego monstrum z dużą ilością klientów (nie tylko przeglądarkowych - jakiś desktopowy, czy coś) i olbrzymią bazą danych. Tutaj taki wynalazek jak EJB jest chyba nieodzowny. Ale oczywiście zgoda - projekt może (podobnie jak człowiek ) rosnąć w różne strony.