Názory k článku
Jan Minárik: S Rails vyvíjíme efektivněji

ten koniec zabil :)

Vazeny pane Stastny,

timto Vas zadam, abyste sel s rail _do prdele_ Vy chaby buzerante, aby Vam mraz prdel natrh ! Nikdo tady neni zvedavy na Vasi PR.

Hezky den preje Radovan

Nejseš ten z Banánu? :)

zajímalo by mne srovnání v rychlosti oproti webovým aplikacím v PHP, jelikož zastávám názor že cokoliv co je v RRails musí být pomalejší než když je to jen v PHP (hlavně mne zajímá serverová zátěž)

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.

No tak interpreter Ruby asi nebude z nejrychlejších. Ale to vůbec nevadí, protože největší brzdou webových aplikací je databáze. Poskládat výslednou stránku je sranda, ale SELECT nad jedenácti tabulkami, z nichž některá má třeba mega záznamů, to není žádná sranda.

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.

No... Já bych nepřeháněl. Na Smalltalk se to rozhodně nehrabe. Nebo neznáte Smalltalk.

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.

> Proto doporucuji u velkych projektu pouzivat FastCGI technologii.
A ja odporucam pre velke projekty Javu.

Nebo ještě lépe Common Lisp.

Nic proti FCGI, ale ten pool databazovych spojeni lze snad na normalni platforme resit i jinak, ne?

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.

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?

Znate nejaky xslt procesor ktery nema memory leaky? Treba o libxml2 jeji autor napsal neco v tom smyslu ze: "Nepouzivame staticky promenny, takze doufame ze nase knihovna je TS.
Nemame ale cas to testovat".

Možná bych to upřesnil - mpm_worker v Apache je stable už dost dlouho. S mod_php to asi opravdu nikdy nebude, to by to vývojářům PHP muselo přestat být jedno. Nějakou dobu používáme Apache 2.2 jako mpm_worker v kombinaci s FastCGI PHP a Mongrelem a funguje to výborně.

Dekuji a opravu. Muj predchozi prispevek berte prosim s nadsazkou. Ton jakym je to napsane je castecne zpusoben frustraci zpusobenou hledanim race a leaku v knihovnach napsanych v Cecku.

Pani z iQuest jsou asi dobri analytici, projektanti, programatori, DB specialiste a administratori serveru a siti, ale grafik jim asi jeste schazi. Jimi vytvareny design je dosti podprumerny. Nema to zadny napad, zadny smrnc. Ale to neni nic nenapravitelneho a je docela mozne, ze casem se to zmeni.

Pokud jde o www.iquest.cz, tak to snad brzy bude predelane do noveho designu. ;-)
A ostatni weby mi prijdou pekne, treba www.hairgods.cz je hodne zajimave a netradicni.

Me se design na www.hairgods.cz nelibi. Mozn aje netradicni, ale bez vyrazneho napadu. A kvalita provedeni designu je podprumerna (spatne orezane obrazku, nepruhledne pozadi obrazku - proste des a hruza!).

To je tak, kdyz design, ktery byl delan prave pro zeny hodnotu muz 8-)

To neni o tom jestli to hodnoti muz nebo zena. Je to o tom, ze kdyz se na to podiva clovek, ktery se designem zabyva, tak musi usoudit, ze kvalita je dosti mizerna.

Vy jste jim to tedy podal dost drsne :-/

Nicmene i takovato kritika je pro podnikatele uzitecna. Preji hodne uspechu.

Chtel jsem jen upozornit na to, ze nejen dobry program, ale i dobry design dela uspech. A tato firma proste zatim design nezvlada.

To asi jo, mi muzi nedovedem takovej peknej web. Jen skoda ze sem si v tom ani moc nezaklikal, submenu mi nak mizi kdyz na nej najizdim (teda dvakrat nezmizlo) asi mam pomalou mys:)

Mohol by niekto upresniť aký je tam problém s mod_ruby? Použivať Litespeed by som asi nechcel.

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.

tak toto je jeden z nejlepsich clanku, co jsem na rootu v posledni dobe cetl. A myslim, ze by se mi libil, i kdybych Ruby a Rails nemel v oblibe...

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 :-)

Nazov clanku asi mal byt: "S Rails vyMýjíme efektivněji"

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 :-)

Opodstatneny hype? A cim je ten Rails taky zaujimavy?

Kdyžtak ty Rails, ne ten Rails :-) Pro mě jsou zajímavé, že díky nim dokážu pracovat mnohem efektivněji a rychleji.

A jinak zajímavost/nezajímavost je subjektivní - podívej se na ně, třeba tě zaujmou, třeba ne. Pokud ne, tak ti snad nebude dělat vůbec žádný problém onen hype ignorovat :-)

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.

Uplne to same je skoro v kazdem komponentovem web frameworku.

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.

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.

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.

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

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.

nekdo tady tezce nechape (:

a je to hunki punki:-) Naprosto souhlasim s predchozim komentarem. Ruby a RoR je moderni, marketingova tlacenka, ale jinak to prinasi pramalo noveho.

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

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...

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ě.

Být vámi, tak se nesnažím, ztrácíte čas, zkuste raději spolehlivější téma jako třeba nejlepší Linuxová distribuce. Uvědomte si, že uživatelé Rails jsou líní i na to psát ručně SQL dotazy, takže rozhodně nebudou plýtvat časem na flame :-)

Kokot jednoznacne najlepsi flow ma The Game(uz sa tesim na festival TJHH), a zo Slovenskych raperov asi Supa s Delikom.

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?

Jenže to, jaké použijete vývojové prostředky, jestli vhodné či nevhodné, na tu slibovanou funkcionalitu, stabilitu a výkon má poměrně velký vliv. Univerzální nástroj neexistuje.

Nejdulezitejsi je citelnost zdrojaku a na to ma volba vyvojoveho nastroje silny vliv.

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

Restart počítače 400x za den? Cože? Když den má 24 hodin, start počítače dejme tomu 40sec, reset dejme tomu nulový čas, tak to mohlo běžet necelou minutu. Skvělý způsob jak šetřit disky :)

Server myšleno program, ne počítač.

Markantní nevýhodou #1 je instalace. Snad už konečně někdo nepřijde s použitelnou free instalací typu XAMPP.

Jasnačka, na gem install rails člověk potřebuje titul z jaderného inženýrství. Měli by to sakra zjednodušit, že jo.

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/

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?

Proc apache? I D.Hansson doporucuje lighttpd+FCGI ...

Přesně tak, proč Apache, když můžete použít o dost lehčí řešení? Navíc mi z Vaší stížnosti přijde, že si stěžujete spíš na Apache než na Rails - tím lépe. ;-)