Názory k článku Jan Minárik: S Rails vyvíjíme efektivněji
-
Zkousel jsem testovat rychlost ruby proti PHP a v ramci mych testu bylo asi sestkrat rychlejsi. Ale pozor, to neni vubec smerodatne, jednalo se jen o velmi omezeny okruh testu, takze to o nicem nevypovida a o tom, jak rychle to bezi na serveru teprve ne. Ale nicmene nemyslim si, ze by problem Ruby byla rychost, to ani ne, spise pamet. Klasicke reseni, tj. mongrelovy cluster si vyzere skutecne hodne. Ale na druhou stranu to se kompenzuje vetsimy zisky za aplikace, ktere vyvijite vyrazne rychlejsi. -
anonymníKrome toho, ze interpret ruby je jeden z nejpomalejsich (orientacne viz. napr. http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all), tak RoR rychlosti zrovna dvakrat neprida. Jako hlavni problem vidim jejich ActiveRecord, ktery si s optimalizaci zrovna hlavu nedela (ovsem neznam nejnovejsi verzi), do databaze posila obrovske mnozstvi dotazu, kde nejsou potreba. Takze v kritickych castich jsem byl nucen se vykaslat na pekne, ciste a kratke zapisy v Ruby a nahradit je stejne osklivymi a slozitymi lec rychlymi SQL prikazy.. :( Pokud je potreba neco pocitat mimo databazi, tedy v pripadech, kdy jde o hruby vypocetni vykon Ruby, tak je rychlost interpretu take znatelna.. Jinak s vetsinou "PR reci", ktere se tykaji efektivity programovani (koneckoncu i zabavy pri psani;), vicemene souhlasim a verim, ze se RoR bude dal s postupem jeho vyvoje zefektivnovat a prichodem Ruby 2.0 se situace dal zlepsi..
-
kb (neregistrovaný)Ja ale nechapu to neustale srovnavani s PHP. I na tech videich co byly v tom nejakem blogu hned po konferenci. Srovnavate framework a jazyk, coz je tak trochu blbost. Pokud zacnete psat aplikace from scratch v ruby i v php bude s tim spousta prace. Srovnavejte spise Symfony a RoR. To uz by bylo porovnatelne. Trochu symfony znam a myslim, ze s nim by se dali taky rychle a efektivne vyvyjet aplikace stejne jako v RoR (ale nechci zakladat flame, jen nazor). Navic kdyz se dva hadaji treti se smeje :) (Python?).
P.S. po te konferenci se zacinaji objevovat nehorazne tendecni clanky opevujici RoR. Tim nerikam, ze jsou spatne, samotneho me laka je vyzkouset. Jen dojem. -
Hmm, já mám zase z PHP pocit, že bude pomalejší, protože je "one-shot", při každém požadavku musí zpracovat skoro všechno znovu. Oproti tomu dlouhoběžící proces (nějaký aplikační server) může výrazně těžit z toho, že si bude data uchovávat v paměti. "Tvrdá čísla" samozřejmě nemám.
Problém je v tom, že aby člověk získal "tvrdá čísla" musí mít nějakou složitější úlohu a většinou nemá čas ji napsat ve dvou jazycích. Syntetické testy je možné nastavit tak, aby vyhrával libovolný z jazyků.
PS: V Ruby nepíšu, srovnávám PHP a Python. -
PHP se da spustit jako FastCGI. Proto se pak vsechno nemusi zpracovavat znovu ale zavola se jen program v pameti. Dalsi vyhodou FastCGI je i to, ze kdyz si program navaze spojeni na DB, tak si ho ten program uchova tak dlouho, jak je to nastavene v DB serveru. Ono navazovani spojeni s DB je take dosti casove narocne a zatezuje to navic jak aplikacni tak DB server. Proto doporucuji u velkych projektu pouzivat FastCGI technologii. FastCGI ma podporu nejen v PHP, ale i v Perlu, Pythonu a dalsich jazycich.
-
Ivan (neregistrovaný)Ono moc reseni neexistuje. PHP, Perl i Python maji problem v tom, ze jsou postavene na
knihovnach napsanych C(C++), takze i kdyby nakrasne byly jejich interpretry multivlaknove,
tak alesom jedna knihovna na kterou maji binding nebude thread-safe. I kdyby i bylo vsechno thread-safe tak budou knihovny obsahovat memory leaky. Multivlaknovost PHP je jen chimera. Threaded worker Apache2 je uz hodne dlouho unstable a v kombinaci s PHP asi nikdy fungovat nebude. Akoliv jsem byl hodne dlouho odpurce JAVY, tak jsem musel uznat, ze v kombinaci s DB Oracle jsou aplikacni servery postavene na JAVE mnohem vykonejsi nez cokoliv postavene na Apache. Pokud totiz otevirate a zavirate 200 DB session za sekundu tak je uplne jedno
jestli mate aplikaci napsanou v JAVE nebo z assembleru. -
Rejpal (neregistrovaný)Hmm, ale nakonec je všechno napsané v Cčku, ve kterém mohou být memory leaky. V JITu můžou být chyby. Když mohou být leaky nebo chyby v PHP nebo Apachi, proč by nemohly být v Javě? Nebo v těch mamutích aplikařních kontejnerech? Nebude fígl v tom, že když je něco hodně používané (Java, Apache, PHP), budou v tom ty chyby vychytané? ;-)
Věta "i kdyby nakrasne byly jejich interpretry multivlaknove, tak alesom jedna knihovna na kterou maji binding nebude thread-safe" je mírný úlet, protože to zcela jistě nutné není - nebo snad překročíte stín vlastní mlčenlivosti a prozradíte nám, kterážeto knihovna je naprosto nevyhnutelná a přitom thread-unsafe? -
Láďa (neregistrovaný)Nepamatuju si to přesně, ale na webu je to hodně dobře popsané. Litespeed není zdaleka jediná možnost a popravdě je to dost neobvyklý řešení. Co se oblíbenosti týče, tak zdaleka vyhrává Mongrel a liší se jenom co se použije jako proxy/loadbalancer. Zatím vyhrával Apache, poslední dobou je ale čím dál tím víc slyšet o Nginxu, právě protože postrádá komplexnost Apache.
-
erg (neregistrovaný)Jsem jediny, komu prijde, ze se z Rails posledni dobou dela strasny hype? Nerikam rozhodne, ze to je spatny framework, to rozhodne ne, ale dela se z nej posledni dobou strasny hype. Takovych frameworku jako Rails tu uz bylo a je pro ruzne jazyky - namatkou co mne napada Symphony, Java Server Faces, ASP.NET, Seam, etc.
Spis mam pocit, ze se s temi frameworky roztrhl posledni dobou pytel :-) -
Láďa (neregistrovaný)Samozřejmě, ale podle mě jde o hype opodstatněný. Srování s ostatními frameworky dost pokulhává, ASP.NET nebo JSF jsou někde úplně jinde a Symfony je prakticky kopie Rails pro PHP.
A že se s frameworky roztrhnul pytel znamená, že čím dál tím víc webových programátorů dostává rozum :-) -
kb (neregistrovaný)Dokazte ze je Symfony kopie Rails. MVC je dostatecne zname. Jako model pouyiva Propel, ten vychazi s nejakeho Apache projektu, helpery jsou inspirovane v Rails. Existuje preci vice frameworku. Mam pocit ye posledni dobou vsichni jen probiraji RoR vs. zbytek sveta, pricemz RoR je slovo bozi.
-
To není moc složité, namátkou jsem kliknul na jednu kapitolu v dokumentaci Symfony http://www.symfony-project.com/book/trunk/09-Links-and-the-Routing-System a ta podobnost opravdu nebude náhodná ;-) Jinak já to nemyslel ve zlém, je mi jedno úplně jedno když se vykrádají dobré nápady, ostatně proč znovu vynalézat kolo.
-
Možná byla chyba, že jsem v rozhovoru více nerozvedl důvody, proč jsme nevybrali jiný MVC framework. Nebylo místo a myslel jsem, že by to ne každého zajímalo. Jen krátce: zajímali jsme se o frameworky TurboGears, Django, Symphony a Zend Framework a vycházeli jsme rovněž ze zkušeností s Java Spring.
Proč zrovna Rails:
1. Convention over configuration, viz Google. Diskutabilní, ale u mě je to jednoznačně výhoda.
2. Velmi dotažený objektový přístup - velmi pozdní vazba, zprávy, reflexivita, moduly a mixiny, closures a iterátory, striktně private atributy.
3. Efektivní a přehledná syntaxe.
4. Velká komunita. Komunity okolo PHP či Pythonu jsou příliš rozdrobené do mnoha různých frameworků.
Co se týká srovnání absolutního výkonu, někde jsem viděl benchmark, z kterého vyplynulo, že Django je o něco rychlejší než Rails, zatímco ty jsou o něco rychlejší než Symphony. Nicméně důležitější je samozřejmě škálovatelnost výkonu. Na toto téma jsem žádné seriózní měření nenašel. My jsme ověřili, že Rails škálovatelné jsou, a to dostatečně pro naši potřebu, což samozřejmě není žádná obecně použitelná informace. -
chomsky (neregistrovaný)No s tim kopirovanim Symfony od Rails bych to asi az tak cerne nevidel, samozrejme myslenka generovani CRUDU je prevzata, ale jinak ma symfony ponekud jine pouziti a uprimne pro programatora zvykleho pracovat s php je 10x jedodussi se naucit pracovat s frameworkem nad PHP nez se ucit syntax ruby.
-
hisaak (neregistrovaný)A kde jinde najit pro takovou vec podporu nez u opensource (resp. linuxove) komunity. Ta prece miluje, kdyz nekdo znovuobjevuje kolo (x office baliku, x desktopovych prostredi, x prohlizecu ...).
Jeste cekam na nejakeho dobraka, ktery do tohodle vlakna napise, ze to je dobre, protoze si clovek muze vybrat. To by byla pravda, kdyby naprosta vetsina nebyla nepouzitelna. Napriklad framework, ktery musim doprogramovat (!), abych mohl zakaznikovi dodat prostou webovou aplikaci. -
hisaak (neregistrovaný)A kde jinde najit pro takovou vec podporu nez u opensource (resp. linuxove) komunity? Ta prece miluje, kdyz nekdo znovuobjevuje kolo. Kolikrat uz to tu bylo? Kolik jen existuje office baliku, desktopovych prostredi, prohlizecu kdeceho, linuxovych distribuci, ...
Jeste cekam na nejakeho dobraka, ktery do tohodle vlakna napise, ze to je vlastne dobre, protoze si clovek muze vybrat. To by byla pravda, kdyby naprosta vetsina nebyla nepouzitelna. Napriklad framework, ktery musim doprogramovat (!), abych mohl zakaznikovi dodat prostou webovou aplikaci.
Az bu -
hisaak (neregistrovaný)Jeste jsem chtel dodat, ze az budu velky a budu mit opravdu hodne penez, ze zalozim firmu, ktera dela bezne webove aplikace a budu je delat na platforme s nasledujicimi parametry:
- bude ji znat pokud mozno co nejmene lidi,
- budu ji muset nejprve dodelat, abych ji mohl pouzit,
- vsechny lidi budu muset sam zaskolit,
- vsechny nove prichozi budu muset znova skolit do toho, co jsem vymyslel noveho, protoze i kdyz treba budou znat dany framework, tezko budou znat ma rozsireni,
- jediny dustupny a rozumne pouzitelny server bude za penize, ale pujde to nejak odrbat,
- jeho alterativou pak bude pasak, ktery se musi 400x denne restartovat.
Pak to cele budu opevovat a budu mluvit o "mnohem vetsi funkcionalite a stabilite". Taky nezapomenu psat rafinovane maskovane PR clanky, kde budu vtipne pouzivat terminy jako "velmi uspesne nasazeny projekt". A kdyz se najde clovek, ktery se bude umet dobre zeptat ("Mnoha opatrným lidem se stále zdá příliš riskantní ..." - jakoby to ti zpatecnici stale nechteli pochopit, co?!), bude to extaze. -
wtf (neregistrovaný)napriklad? kopie RoR nad php ci python a podobne frameworky pro (jazyky jako :-)) Java (coz si myslel ze :-)) si muzes rovnout odpustit. Psat webovou aplikaci v ruby nebo v Jave je dost rozdil. Ale popravde tyhle java-based frameworky pro web apps neznam, pokud je nektery z nich tak snadny na pouzivani jako rails rad se poucim
-
michal (neregistrovaný)No hype to je desny, ale nespojoval bych zrovna RoR a JSF nebo Seam... To je jak spojovat JSF a Struts... Jinak clanek je fajn, vyznelo z nej to spravne - neni to na cem rozumne provozovat v clusteru. A muj nazor je takovy, ze Ruby a RoR je jedna, velikanska bublina, ktera driv nebo pozdeji praskne...
-
Josef Liška (neregistrovaný)Ahoj,
kromě Litespeed používáme i apache2 s fcgid. Výhoda litespeed je hlavně v tom, že to funguje out of the box a navíc je tam předpřipraven běh jednotlivých aplikací v suexecu.
Kombinaci apache2 - fcgid používáme pro některé samostatné aplikace.
Konzumace paměti v ruby není tak kritická, model je ala java - tzn. alokace a garbage collector.
V porovnání s javou u malých věcí vítězí ruby, u velkých rozdíl nevím, asi se to bude strovnávat.
Hnidopichové by měli poznamenat, že www.iquest.cz je v php a ne v ror.
Viděl jsem některé z posledních aplikací od kolegů z iQuestu a jeden grafický návrh na úplně novou aplikaci a musím říct, že jsem z toho uchcával. Bylo to pěkné jak graficky, tak funkčně. -
Karlos (neregistrovaný)Ale takovej mejnstrím s výplachem mozku via PR frikulíno-speak, jsem opravdu, ale opravdu dlouho nezažil.
Tato univerzalita, rozuměj v kontextu článku, je na škodu věci a se samotným Rails to má společného asi tak jako ježek s flaškou rumu.
Je to škoda, takový mixing frikulíno speaku nemá smysl a odvádí či spíše dezorientuje čtenáře od podstaty věci o které by chtěl něco uznati.
Obecně vzato
- je celkem jedno v čem to napíšu a pod čím a na čem to pojede
- Java, Basic, C++ a tak dál není rozhodující
- Důležitá je slibovaná funkcionalita, stabilita a výkon
- vše je ovlivněno velikostí peněženky zákazníka a jeho chápáním "věci"
Já sám preferuji Domino server + koexistenci s ostatními systémy.
Tak, mějte se a kdo že to bude házet kamenem? -
Karlos (neregistrovaný)Ahoj progmani.
Odpovím oběma.
Zatím jsem se setkal s takovým chápáním zákazníka - že to co chce se musí realizovat.
Kupuje přeci službu, produkt, servis a tak podobně.
Hlavně však vždy chtěl funkcionalitu a s tím spojené záležitosti.
A proto ho nezajímalo ani v čem to bude a nakonec ani ta čitelnost kódů.
Jinak programujme každý v čem chceme. Hlavně aby nám to šlo a klienti byli spokojeni,
Ahoj -
zalezi na tom, co clovek potrebuje - pro server asi opravdu neni nic hotoveho, ale pro vyvoj na lokale uz fungujici reseni existuje: Instant Rails is a one-stop Rails runtime solution containing Ruby, Rails, Apache, and MySQL, all pre-configured and ready to run. viz http://instantrails.rubyforge.org/ -
Wejn (neregistrovaný)Tak bezte hostovat k engineyard (dot com), kdyz vam dela takovou starost ostry provoz.
A pokud na takovy luxus nemate, porad je tu textdrive nebo railsmachine ... ze. ;)
Nebo je to nakonec tak, ze budete radeji brecet jak je to slozite, protoze musite sockovat kvuli usetreni tech par $/mo? -
anonymníZaver vase prispevku je ubohy (jako sam autor?). Dale vase reseni fat velmi "systemove". Kdy jste sezral moudrost sveta, muzete ukazat funkcni a hlavne stabilni reseni pod Apache? Jedine funkcni a stabilni reseni jsme nalezli pod IIS s FastCGI na Windows Server 2003, ktere kupodivu nepada a ani procesy nezatuhnou. Radi by jsme videli i funkcni a stabilni reseni na Apachi na Linuxu/*BSD.
