Vlákno názorů k článku Ruby on Rails 2.0: Evoluce, nikoliv revoluce od lol - trochu mimo misu, ale vie mi niekto odporucit...

Ze java na webu je kanon, to je fama... Taky jsem si to myslel, dokud jsem se sam neodhodlal se na to alespon zbezne mrknout :) Pak jsem zjistil, ze diky podpore JEE v Eclipse je setup servlet kontejneru a napsani prvni aplikace pro zacatecnika mnohem jednodussi, nez nastavovat Apache a PHP... Stahnete tomcat, zaregistrujete ho jako runtime a jedete.
Nikdo vas prece nenuti pouzivat cely Spring stack nebo Strutsy... JEE samo o sobe prece neni nic jineho, nez specifikace servletu, jsp a dalsich technologii, ktere muzete a nemusite pouzit. Nemusite pouzit vubec zadny framework na to, abyste mohl napsat alespon malou modularni a objektovou aplikaci. To se mi na tom libi. Navic nikde jinde jsem nenasel tak principielne genialni vec jako jsou taglibs u JSP -- do nekonecna rozsiritelny sablonovaci system... A to nemluvim treba o principu servlet filtru... "Pluggability" :) Centralne nastatovane error pages mapovane na druhy vyjimek, etc etc...
Nehlede na obrovske mnozstvi knihoven, ktere pro Javu jsou. A pro mnohe jinde alternativu nenajdete -- XSLT 2.0, XSL-FO a dalsi technologie...
Doporucuju vam se na Stripes mrknout. Mnoho javovskych frameworku me drive ci pozdeji odradilo tim, jak neco delaly zbytecne slozite, Stripes se to zatim nepodarilo :) O Stripes se uz pred rokem mluvilo jako o the new Rails.

Vždycky mě zajímá, proč popularita někoho odrazuje :-) Pokud bych to vzal racionálně, tak popularita je naopak přínos, hlavně u open-source produktů. Větší komunita dodává víc kódu, nachází víc bugů, zveřejňuje víc pluginů a dokumentace, poskytuje lepší rady na IRC kanálech.

Me na RoR take odradila z casti popularita (z casti to, ze se mi proste Ruby nelibilo jako jazyk a uz jsem se aktivne zajimal o Python a snazil se z nej udelat svuj "tool of the trade").

Odradilo me to proto, ze ta popularita je z casti zpusobena Web 2.0 hype a tim, ze Railsy byly proste prvni (vicemene). Kdybych mel jistotu, ze ta popularita pochazi 100% z racionalnich pohnutek a ne ze stylu "Railsy jsou ted IN, tak se to naucim, abych byl jako taky ten webdevelopr", nevadilo by me to, jenze u Railsu tu jistotu nejak nemam...

Popravdě je mi úplně jedno, čím je popularita čehokoliv způsobena. Firefox je populární a je kvalitní, Linux je populární a je kvalitní, virtualizace serverů teď začíná být velkým buzzwordem a taky je to skvělý nápad. Stejně tak je PHP velmi populární, ale to nepoužívám, protože mi nevyhovuje. Nebo Apache je extrémně populární, ale taky ho opouštím, protože maličký a mnohem méně známý Nginx mi pro nasazení Rails aplikací vyhovuje mnohem víc.

Neboli pointa - u kvalitního projektu je popularita plus, za tím si stojím. Ale kvalita je pro mě stejně vždycky prvním měřítkem a Railsy používám, protože jsou kvalitní. Ostatně začal jsem je používat v době, kdy v ČR byly neznámým pojmem.

Ne, tykání mi opravdu nevadí, naopak :-)

Samozřejmě jsem vyjmenoval jenom produkty mezi odbornou veřejností, protože tam se myslím pohybujeme.

Proč není v Ruby hromada použitelných produktů má vcelku jednoduchý důvod - Ruby je sice zhruba stejně staré jako Python nebo PHP, ale dlouho to byla jenom hračka pár Japonců. Teprve když vznikly Rails, tak se o tom vůbec někdo dozvěděl.

No a co se týče toho posledního, na to mám vcelku jednoduchou odpověď. Nevidím důvod, proč bych měl podobné lidi poslouchat, tak je neposlouchám. Railsy používám, protože jsem je vyzkoušel a vyhovují mi. Křiklouni se dají najít v každé skupině a důvod proč jsem se do téhle debaty zapojil byl můj zájem vědět, proč je lidi poslouchají a nebo proč řeší momentální hype :-)

Naštěstí jsem do velké míry svým pánem :-) Lidi, co trousí na fórech a v diskuzích "X sux, používejte Y" taky nesnáším.

Ruby 2.0 je daleko, hlavní novinkou v něm má být nová VM. Jelikož ale v Rails, podobně jako ve všech webových frameworcích, je ve většině případů brzdou databáze, tak zrychlení jazyka velkou výhru nepřinese.

Co se týče syntaxe - nedělalo mi to žádný problém. Někdy je hloupá její přílišná volnost, která při práci více lidí na jednom projektu vyžaduje dát pravidla a dodržovat je. Například při volání funkcí můžou být závorky nebo taky nemusí, bloky se dají uzavírat pomocí end nebo celé mezi složené závorky atd. Pokud bych měl napsat věc, kterou považuju za největší opruz, tak to jsou jednoznačně chybějící operátory ++/-- :-)

Větší problém samozřejmě pro mě byl naučit se typické "jak se dělá to a to". Naštěstí IRC kanál Ruby je plný lidí, kteří zmigrovali z PHP, takže jsem jenom psal "something like xy in PHP".

Nu, naše priority jsou trochu jiné :-) Od webového frameworku očekávám, aby mi co nejvíc usnadnil práci a třeba zmíněné kódování je pro mě úplně nedůležitá vlastnost.

Ani nebudu muset :-)

a) Ve většině případů nejde o projekty, které by byly až tak heavy-loaded, ale o projekty, které musí být naprogramované nejpozději včera.
b) Serverový HW je neuvěřitelně levná záležitost. Vím, že za tenhle názor by mě spousta lidí sežrala, hlavně ti, kteří museli optimalizovat kód na rychlost/paměť, ale je to zkrátka fakt.
c) Rails mají propracované možnosti cachování až na úroveň jednotlivých fragmentů stránek.
d) Opravdu to není tak zlé :-) Na netu jsou srovnání rychlostí jazyků na algoritmech typu Hanojská věž apod. kde dostává Ruby samozřejmě hrozně na zadek, jenže to není typický příklad jeho použití. A navíc - už teď existují způsoby, jak výkonově náročný kód psát třeba v C a volat přímo z Ruby.
e) Pravděpodobně se to bude zlepšovat: http://en.wikipedia.org/wiki/YARV

Omlouvám se, ale debaty o výkonu mě nebaví - každý ví, že Rails nejsou extra rychlé, já vím, že nejsou tak pomalé, jak píšeš a to mi stačí ;-) Navíc neřeším cizí projekty, o kterých nic nevím a stejně tak se nezabývám stránkou, kde by se v cyklech prohazovalo 1000 záznamů, protože existují uložené procedury a dalších x způsobů, jak to vyřešit lépe :-)

Java mi drive take vadila, ale treba prisnou typovou kontrolu jsem si nakonec docela oblibil... kdyz nic jineho, ulehcuje to vyvojovemu prostredi nabidnout vam kvalitnejsi code completion... A i tak mi pripadne, ze se kod lepe chape, kdyz mate ty typy dane.
Bohate zkusenosti, to bych o sobe netvrdil...jen me to posledni dobou dost chytlo :-) No nejdriv je asi dobre pochytit zakladni principy toho, jak fungujou JEE kontejnery a principy servletu a filtru. Sice starsi ale pro zacatek dobry serial je na Intervalu, psal ho dokonce vas krajan, takze pochopitelny by mel byt: http://interval.cz/clanky/java-servlets-predstavenie-technologie/
Dobre je taky se vzdelat v tom, jak aplikaci strukturovat, pokud dojde na nejakou interakci s datovym zdrojem. Tedy ze nebudete psat SQL dotazy v tele servletu :) Ale ze je fajn mit servisni vrstvu, pokud cekate, ze budete menit datove zdroje, tak mit i Data Access Object factories, ktere vam vrati dany DAO (najednou se rozhodnete, ze to nechcete mit v DB, ale v XML, tak zmenite DAO a zbytek aplikace o zmene data storage nebude vedet vubec nic) a ten se dotazuje bud primo pres JDBC do databaze, nebo pres nejakou perzistentni/ORM vrstvu. Ja osobne jsem si ted u jedne aplikace dovolil DAO nepouzit, JEE architekti by me asi radi nemeli, ale ja jsem to risknul a v servisni vrstve pracuju uz primo s kontextem Apache Cayenne, coz je dle meho nazoru skvela ORM/perzistencni knihovna na praci s databazi (dostali se do Google Summer of Code a pouziva to treba NHL.com). Take proto, ze obsahuje ve Swingu napsany GUI modeller, ve kterem si namodelujete vztahy v DB a on vam vygeneruje domenove tridy -- usetri plno prace.
Mimochodem tyhle vzory se daji stejne tak dobre pouzit v PHP, jen technologie se zmeni.
No a pak zkuste prolitnout tutorialy a priklady na Stripes (http://stripes.mc4j.org/confluence/display/stripes/Home) a nebo nejaky jiny framework podle gusta... Ale Stripes jsou podle meho v soucasne dobe to nejjednodussi a nejprehlednejsi ( a pritom mocne!), co ve svete Javy na webu existuje.

mrknete na ten Stripes, v Quick Start Guide je krasne videt, jak jejich databinding za vas resi prevod cisla z formulare na javovsky double.

A, pan Tisnovsky chysta serial, takze me urcite opravi, pokud jsem neco napsal nepresne :-)

iste, ale na php najdete milion lacnych hostingov, na j2ee nic.

Groovy na web vypadá opravdu nadějně, Java bohužel "write less, do more" nesplňuje.

Je teď vývoj Stripes aktivní? Zdá se mi, jako bych o něm delší dobu nic nového neslyšel. Nebylo by špatné, kdyby dořešili věci jako možnost používat pěkná URL apod., což tuším mělo být ve verzi 1.5.

Podle deni v mailing listu vyvoj stripes aktivni je a nekteri pouzivaji current vetev i na ostre aplikace. Dnes se v listu objevila zprava, ze 1.5 by mela byt venku behem par mesicu.

Co se tyka "peknych URL", tak ty je mozne pouzivat i v 1.4.x za pomoci rozsireni Clean URLs (http://remi.mongus.com/stripes-clean/), i kdyz je k tomu potreba trosku vice hackovani (musite odvodit novou tridu pro stripes:errors JSP tag, protoze ta stavajici nebere syntax clean URLs v uvahu a validacni chyby se vam tim padem nikdy nezobrazi -- ale jde jen o zmenu na par radkach). V 1.5 by vsechno tohle melo byt vyreseno interne.

Kazdopadne muzete ti pomoci UrlRewrite servlet filtrem, coz je obdoba mod_rewrite pro Apache (a umi vyuzivat i specificke vlastnosti kontejneru, ne jen interni presmerovani)

Na to rozšíření se podívám, díky za tip.

UrlRewriteFilter znám, ale přiznám se, že nejsem moc příznivcem podobných řešení (míněno pro pěkná URL), a to ani u servletů, ani u Apache. Připadá mi to odtržené od zbytku aplikace a hůř spravovatelné. Nepříliš elegantně se pak také řeší takové věci jako například lokalizovatelná URL.

Presouvate teziste nekam jinam. Nehodlam s vami rozebirat rozdily mezi pojetim MVC v ruznych frameworcich

Nerozebiram tu MVC, validace dat nema s MVC nic spolecneho -- ani to kdy a kde se deje.

Podle meho nazoru je naprosto v poradku, ma-li byt vrstva zodpovedna za nakladani s daty zaroven zodpovedna za jejich validaci.

Ale proc? Predstavte si, ze mate prichozi data z formulare, ktera potrebujete zvalidovat a potom nasypat napr. do generatoru faktury nebo je odeslat mailem a ta data ani neodpovidaji strukture zadneho z vasich modelu. Tak kam validaci date? V CI proste natahnu tridu validatoru, priradim ji validacni pravidla napsana pro tuto prilezitost a validator spustim. Jak napisete v Cake modelu validacni pravidlo pro pole, ktere v tom modelu neexistuje?..a i kdyby to slo, nebije vas to do oci, to takhle delat?

skoro to vypada jako by jste nevedel, ze validaci dat muzete v CakePHP provest i bez pokusu o jejich ulozeni.

To, o cem tu celou dobu pisu, neni ZDA to jde udelat, ale JAK a jestli je ten nastroj dobre architektonicky uzpusobeny k tomu, aby to tak slo udelat.

To se rovnou muzeme shodnout na tom, ze udelat lze vsechno vsude a diskusi uzavrit. Ale ja tu mluvim o tom, ze tvurci Cake umistili mechanismus validace tak, ze vas v nezanedbatelnem procentu pripadu donut drbat se levou rukou za pravym uchem.....