Komentáře k článku

Od PHP až k Ruby on Rails

Zaujal vás framework Ruby on Rails, ale máte o něm pochyby, resp. nechce se vám plýtvat silami a učit se další webový framework? V článku Lukáše Burkoně z eBallance se dozvíte, jak se k Railsům dostali oni, jaká byla jejich motivace, co jim Railsy přinesly a jakým problémům při přechodu museli čelit.

Zpět na článek

102 komentářů k článku Od PHP až k Ruby on Rails:

  1. Pepa Chmel

    S Rails pod Windows není problém ;)

    Taky jsem přešel z PHP na RoR :). Ale krátce po tom co jsem si pořídil nový počítač s Win 7 64b. Tak jsem se rozhodl že to na těch Windows prostě rozchodím :).

    Nakonec je to možná jednodušší než na Linuxu, kde jsem to již spouštěl taky (demo server (ubuntu) a produkční server(centos)). Ani zásadní rozdíl v rychlosti nevnímám (když porovnám chod v dev. režimu).

    Seřadím dle náročnosti instalace
    centos
    win 7
    ubuntu

    Na Win 7 je třeba najít navíc vývojové prostředí.
    Takže má konfigurace je Ruby 1.9.2 rails 3.0.7:
    Netbeans 7 http://netbeans.org/downloads/
    Netbeans Ruby plugin http://plugins.netbeans.org/plugin/38549/ruby-and-rails


    Ruby installer http://rubyinstaller.org/
    Dev kit http://rubyinstaller.org/add-ons/devkit/ (některé gemy to vyžadují)
    mysql2 0.2.6-x86-mingw32 http://rubygems.org/gems/mysql2/versions/0.2.6-x86-mingw32 (to jediné nešlo pod win funkčně přeložit)

    Na serverech zase Passenger
    http://www.modrails.com/install.html

    Většinu příkazů pouštím z prostředí IDE, je to pohodlnější než je datlovat :) (jedině na bundle install si pouštím příkazovou řádku)

    Tak snad to někomu pomůže při rozjezdu pod Win. :)
    Pepa

    1. johno

      Re: S Rails pod Windows není problém ;)

      Odporucam skusit JetBrains RubyMine. Bezkonkurencne najlepsie IDE na Rails.

    2. Alois.Janicek

      Re: S Rails pod Windows není problém ;)

      Co říkáte na Aptanu Studio 3 v porovnání z Netbeans? Zkoušel jste?

      1. Pepa Chmel

        Re: S Rails pod Windows není problém ;)

        Zkoušel, ale nic navíc jsem oproti Netbeans nezískal. Spíš jde o to, s čím je člověk zvyklý. Já mám v Netbeans i PHP a C++ projekty, proto jsem zůstal u toho.

      2. Pepa

        Re: S Rails pod Windows není problém ;)

        V Rails komunitě většina lidí žádný IDE nepoužívá. Píše se v TextMate nebo Vimu + konzole. Windowsáci tuším používají jEdit, scite, e-text a je fakt že dost i Netbeans.

        1. Lukáš BurkoňAutor příspěvku

          Re: S Rails pod Windows není problém ;)

          Na Windows můžete využít ještě nový česko-slovenský projekt Intype. Sice je to ještě alpha a zatím poměrně neohrabaná, jde ale podobným směrem jako TextMate, takže v budoucnu to může být určitě zajímavé.

  2. Kit

    Skriptovací jazyk na serveru

    Z článku mi není jasné, jaký interpreter musí běžet na serveru. Je to Ruby nebo se aplikace pomocí RoR kompiluje do PHP, které pak běží na serveru?

    Pokud by na serveru musel běžet Ruby, tak je podle mne dost omezený výběr hostingu.

    1. Čelo

      Re: Skriptovací jazyk na serveru

      Samozřejmě výběr hostingů není tak rozsáhlý jako pro PHP, ale omezený není.. u nás je minimálně railshosting.cz a už jsem zahlédl i nějaké další možnosti hostovat aplikace v RoR. A pak je tu hlavně heroku.

    2. Petr

      Re: Skriptovací jazyk na serveru

      Je samozřejmě potřeba mít ruby interpret, možnosti hostingu jsou opravdu omezené.
      To je podle mého názoru jedna z věcí, které brání většímu rozšížení. Další věcí je, že je poměrně komplikovaný proces instalace, takže napsat hello world aplikaci vyžaduje větší úsilí.
      Zkuste třeba 4smart.cz, tam dostanete vlastní virtuál s již předinstalovaným ruby on rails v podstatě za běžnou cenu webhostingu.

    3. blizz

      Re: Skriptovací jazyk na serveru

      Na normálnych vačšine veľkých (unix / linux) hostingov ponúkajú aj RoR. Inak čo je to za hlúpy argument? Snáď nebudem prispôsobovať vývojovú platformu hostingu. Hosting kde admnini nedokážu nainštalovať ruby gems a pár balíčkov treba vymeniť za lepší. Prípadne vlastný server alebo Virtual server, možností je dosť.

      1. pexxi

        Re: Skriptovací jazyk na serveru

        Presne, myslim, ze virtual-server je najlepsia cesta…

        Sam takto riesim PHP/Java webs a ked som experimentoval s Ruby, tiez som to mal takto ovela jednoduchsie… Na bezny shared by som uz nesiel nikdy viac…

        Pri viacerych hostovanych weboch a specifickych poziadavkach sa aj tak ta investicia niekolkonasobne vrati.

    4. Pepa Chmel

      Re: Skriptovací jazyk na serveru

      Když se použije Passenger, tak je způsob vydání aplikace úplně stejný jako s php.
      Passenger je jako modul do Apache a když máte připravenou aplikaci v dev. režimu, tak ji můžete tak jak je zkopírovat na server.
      Nastavení přístupu přes doménu je jako úplně normální virtualhost.

      Jediný rozdíl oproti php je, že se po nahrání nové verze musí v produkčním vyvolat „restart“ passenger modulu (spíš kompilace) (změnou datumu jednoho souboru). Osobě to považuji za obří výhodu, oproti php, kde člověk musí řešit nějaké dočasné obrazovky s upozorněním aktualizuji… tady ne ;).
      Jediné co se musí asi dělat vždy z příkazové řádky je migrace databáze na novou verzi (rails má v sobě migrační mechanizmus).

      Ani co se týče paměťové náročnosti nevidím zásadní rozdíl oproti php aplikaci s frameworkem. (u mě má podobná aplikace v php o 10 MB méně – zato jsem ji dělal 2x déle :D)

      1. Pepa Chmel

        Re: Skriptovací jazyk na serveru

        Ještě k poslední větě: „Ani co se týče paměťové náročnosti …“ jedná se opravdu o množství alokované paměti RAM :) co si alokovaly při běžném chodu obou webů.

    5. alancox

      Re: Skriptovací jazyk na serveru

      To jsou spojené nádoby.

      Vyšší úroveň Rails programátorů je spojena s tím, že jich je málo. Tím, že jich je málo, je také málo hostingů.

      Když se čistě náhodou Rails rozšířil do rozsahu PHP, pak úroveň Rails programátorů bude možná i horší, než PHP programátorů. Zato seženete hosting.

      Ostatně úroveň unix/Linux nadšenců byla mnohem vyšší v době, když jich bylo jen pár. Kvalita lidí kolem nějaké technologie je přímo úměrná nezájmu o danou technologii. Tak to je a tak to vždycky bude.

      Já se spíše u Ryby obávám toho, že jeho autor má hračičkovací tendence podobně jako autor Perlu a autor Pythonu, kdy jeho hračičkování má přednost před zpětnou kompatibilitou a ochranou práce vývojářů, kteří už nějaký kód v jazyce napsali. Perl 6, Python 3 a Ruby verze nevím kolik by měla být mementem. To je hlavní důvod, proč jsem se těmto jazykům nikdy nesvěřil – nekompatibilní změny v syntaxi byly jasně více vedeny stylem „autorovi se to tak líbí“, než skutečnou praktickou potřebou a vylepšením. To rozhodlo, že na poli skriptovacích jazyků dávám přednost PHP, u kterých jsou nekompatibilní změny minimální a účelné. I když bohužel také jsou.

      Ovšem, jsem prostitutka, když bude na všech hostinzích nabízen dobrý jazyk, který nebudou autoři nekompatibilně přetvářet bez důvodu (nejsem proti změnám, ale musí to být benefit, nikoli byrokracie jako u Pythonu, nebo Ruby), tak klidně udělám web v něm. Musí ta změna stát za to.

      Výhodou Railsu je to, že je hotový framework a lidé kolem něho neryjí zcela low level. Na druhé straně moje priority jsou jasné – hodnotový žebříček developerů samotného jazyka je pro mě alfa a omega. Je-li to hračičkování (Perl, Python, Ruby), pak mu nevěřím. Ctění zpětné kompatibility až na kost, s výjimkou opravdové nutnosti či enormního zlepšení vyvažující potíže je to co požaduji a nikdy neslevím.

      1. martin

        Re: Skriptovací jazyk na serveru

        Je pravda, že změny mezi ruby 1.8 a 2 (aka 1.9) jsou bolestivé byť lze důvody přinejmenším částečně obhájit. Ale úzkostlivé lpění na zpětné kompatibilitě moc efektivity také nepřidá.

        Na druhou stranu je produktivita s těmito jazyky (a prostředími) v současné době bezkonkurenční. Tedy pro oblast aplikací, na kterou míří.

        A od té doby co existuje RVM (myslím, že snad někdo udělal i ekvivalent pro Python), tak mě tolik různé verze moc netrápí.

        1. xx

          Re: Skriptovací jazyk na serveru

          Na druhou stranu je produktivita s těmito jazyky (a prostředími) v současné době bezkonkurenční.

          Tohle je diskutabilní. Řekl bych, že se kód v dynamicky typovaných jazycích udržuje mnohem obtížněji než v jazycích staticky typovaných.

          1. martin

            Re: Skriptovací jazyk na serveru

            Myslím, že to diskutabilní není. Řekl bych, že je to dost evidentní. Stačí se kouknout na Internet.

          2. krespo

            Re: Skriptovací jazyk na serveru

            Ahoj preco myslis ze s kod v dynamickych jazykoch udrzuje tazsie? z dovodu citatelnosti, alebo ake dovody?

            1. xx

              Re: Skriptovací jazyk na serveru

              Hlavní výhodou staticky typovaných jazyků je, že pomocí typového systému můžete formulovat a vynucovat invarianty, které má kód splňovat. Důsledkem toho je, že mnoho problémů zachytíte už při kompilaci a IDE vám může lépe pomáhat, protože má více informací.

              1. martin

                Re: Skriptovací jazyk na serveru

                Až na to, že tahle pěkná vlastnost také nefunguje za všech okolností jak už bylo (a ne jen tady) 100x napsané. atd. atd. takových diskusí jsou tisíce a nemají konce. A výsledek? Desítky aplikací v PHP na jednu Javovskou. A to jsem častěji viděl backtracy Javy než kiksnutý PHP (kde to většinou byla spadlá DB).

                A to nemluvím o tom, že způsob typování hraje při výběru technologie pro takové projekty snad i téměř nulovou váhu.

                1. v6ak

                  Re: Skriptovací jazyk na serveru

                  Ono PHP taky přejde ledajakou chybu, takže se pokračuje dál. Což ale ne vždy je dobře.

              2. nyan

                Re: Skriptovací jazyk na serveru

                Az na to ze kazdy C program v praxi, ktery je slozitejsi nez hello world, pouziva pretypovani. Akonahle pouzijete pretypovani, obchazite staticke typove overovani. Tudiz to ze jsou staticky typovane jazyky bezpecnejsi je pohadka.

                1. v6ak

                  Re: Skriptovací jazyk na serveru

                  Nemáme tu dva póly typování (statické a dynamické nebo bezpečné a ‚nebezpečné‘). Dynamické typování si lze zhruba představit jako používání metody invoke(String name, Object…args) s troškou syntaktického cukru. To by ostatně šlo i v Javě po výměně třídy java.lang.Object (není až takový problém – bootclasspath), jen by to nevypadalo až tak hezky. (A byl by to, samozřejmě, drastický zásah.)

                  To, že jde o syntaktický cukr, naznačuje i takový experimentální trait Dynamic http://www.scala-lang.org/api/rc/scala/Dynamic.html . V Javě bychom například k JSONu mohli přistupovat (bez mapování na vlastní třídy) ve stylu a.get(„foo“), zatímco trait Dynamic by měl umožnit i přístup a.foo. A to bez omezení typové bezpečnosti. Ta tady je z principu celkem v čudu.

                  Jazyk C není zrovna ukázkou nejlepšího typového systému, který by umožnil odhalit při kompilaci kde co. Nemá například generické typy (v C++ templates), které dovedou nahradit snad drtivou většinu přetypování typově bezpečnou a pohodlnější cestou. Lépe je na tom třeba z těch známějších C++ a Java, z méně známých třeba Scala. Celkově si myslím, že fakt, že typová bezpečnost nebude 100%, ještě neznamená, že se na ni máme úplně vykašlat.

                  Pokud ale nemáte stoprocentní code coverage (mohu vyhrabat článek, který doporučuje se o to nesnažit za každou cenu – podle pravděpodobnosti a závažnosti selhání), statické typování se celkem hodí na místech, kde jste testy nepovažovali za až tak důležité. Chcete smazat třídu a nejste si jisti, jestli někde není používána? Není problém, stačí to pak zkusit zkompilovat.

                  Dále, statické typování se někdy hodí i se stoprocentním poktytím testy. Dozvědět se o všech výskytech, které jsou zasaženy odstraněním něčeho, okamžitě, je tu samozřejmostí. A dozvědět se o chybě ideálně již z IDE znamená méně skákání v myšlenkách a lepší koncentraci na problém. A napovídání v IDE taky není k zahození.

                  Bohužel, v mnohých webových frameworcích typová bezpečnost končí nejpozději na místě, kde se stýká Controller nebo Prresenter se šablonou. Od tohoto bodu je vše typované dynamicky. Nicméně i zde si dovedu představit celkem snadné řešení, které by v některých případech znamenalo (Japid, Scalate) jen minimální změny.

                  Navíc statické typování nemusí být otravné. Stačí se podívat třeba na type inference. Ve Scale mi často stačí určit jen typy parametrů a kompilátor si všechny ostatní typy odvodí. A bez znalosti typů parametrů je někdy velmi těžké se ke kódu vracet. Navíc si myslím, že by to neměl být problém – pokud nevím typy parametrů, těžko něco kloudného vymyslím.

                  1. xylon

                    Re: Skriptovací jazyk na serveru

                    V poslednej dobe sledujem ze programatori maju nazor: „staticke typovanie je minulost a buducnost patri dynamicky typovanym jazykom“. Samozrejme to je nekonecna debata, kazda alternativa ma svoje pro,proti.
                    Ake su hlavne vyhody dynamickych jazykov? z mojho pohladu:
                    1.niesu ukecane 2.v niektorych pripadoch sa v nich efektivnejsie(lo­gickejsie) modeluje.

                    1.je mozne efektivne riesit aj v statickych , vyuzitim type inference a navyse je to kontrola co je dost dolezite.

                    Napr. vezmime tiez znovupouzitelnost kodu-v staticky typ. sa pouzivaju generika, ktore malo kto vie rozumne pouzivat. Pricom v dynamickych logicky s tym nieje problem(kedze sa neurcuju typy)+musime pokryt testami.

                    Inac vyzva na clanok nech niekto znaly napise clanok na temu vyhod/nevyhod staticke vs dynamicke jazyky(myslim ze teraz dost aktualna tematika).

                    1. xx

                      Re: Skriptovací jazyk na serveru

                      Lze říci, že dynamicky typované jazyky jsou vlastně staticky typované jazyky, které mají pouze jeden typ.

                    2. v6ak

                      Re: Skriptovací jazyk na serveru

                      Takovýto článek jsem zvažoval (a možná něco sepíšu), ale asi by při nejlepší vůli nebyl úplně nestranný… Ale přinejmenším jiný pohled se taky může hodit. Problém je asi dost v tom, že pod statickým typováním si mnozí hned představí Cčko a jejich sice funkční, ale ne zrovna nejpříjemnější typový systém.

                      K ukecanosti: přesně tak, type inference to celkem rozumně řeší. IMHO takové 20/80 řešení.

                      Ke znovupoužitelnosti a logičnosti/efek­tivitě modelování:
                      * Generika jsou pěkná věc a s jejich principem se lze setkat i u polí. Základní použití je opravdu jednoduché a nebolí. A pokročilejší použití? Ano, člověk se občas zpočátku může trochu spálit (kompilátor mu jeho kód nevezme), ale stačí umět trochu přemýšlet a dá se přijít na problém. Java s její tzv. invariancí může být nepříjemná (už jsem si to zažil), ale třeba Scala má v tomto celkem příjemný systém genericity. Například List[Employee] mohu přiřadit do List[Person] jen tehdy, jedná-li se o neměnný seznam (scala.collec­tion.immutable­.List). Pokud by se jednalo o upravitelný seznam, bylo by to logicky špatně, protože by nám někdo do seznamu zaměstnanců přidat, řekněme, zákazníka. A typový systém Scaly to nedovolí. Dá se o tom přemýšlet jako o vstupu a výstupu. Nejlépe je to vidět u typů funkcí, kde mohu slíbit konkrétnější návratový typ a obecnější typy parametrů.
                      * Co je v dynamických jazycích logičtější? Mě třeba přijde logičtější řešit implicitní konverze (a jejich případné kolize) při kompilaci než monkeypatching (přidávání metod za běhu), u kterého se v lepším případě dozvím kolizi za běhu. Přitom ty implicitní konverze mohou fungovat i jen lokálně, jak jsem ukázal na https://github.com/v6ak/Scala-implicit-conversions-example .

                      1. krespo

                        Re: Skriptovací jazyk na serveru

                        ohladom tej logicnosti v stat typovanych jazykoch: ak mam interface, a triedu ktora sice splna formalne metody uvedene v interface ale neimplementuje ten interface(pripad externych kniznic) tak v kode nieje mozne volat metody tohto objektu cez referenciu interfejsu. Co je z objektoveho pohladu nelogicke lebo ak mam kontrakt ktory implementuje niejaky objekt, tak by som mu mal vediet zaslat spravu.
                        Mozno sa najdu aj ine pripady, ale zatial ma ziadne nenapadaju.
                        btw urcite by bolo fajn kebny si napisal clanok(ak mas znalost v problematike tak aj nestranny sa da napisat:)

                        1. xx

                          Re: Skriptovací jazyk na serveru

                          Pokud Vám dobře rozumím, tak máte na mysli structural subtyping? To podporuje například OCaml nebo Go.

                        2. v6ak

                          Re: Skriptovací jazyk na serveru

                          Například Scala má možnost určit typ výčtem požadovaných metod (tzv. strukturální typy) a v Go je tuším automaticky implementováno každé vyhovující rozhraní. To by asi ve Scale šlo simulovat pomocí nějaké takovéto deklarace:

                          type Closeable = {def close()}

                          V případě Scaly by se daly pro pohodlné použití využít tzv. package objekty, ve kterých by byla tato definice, ale to už zabíhám příliš do detailů.

                          Nicméně jsem spíše proti tomuto přístupu:
                          * Rozhraní nedefinuje jen seznam metod, které mají být implementovány. Rozhraní definuje i to, jak se mají chovat, ačkoli to už není součástí typu. V takovém případě je tu teoretická možnost, že bude nějaké rozhraní automaticky implementováno navzdory tomu, že implementováno být nemá.
                          * V praxi si nepamatuji na moc případů, kdy třída splňovala požadavky nějakého rozhraní, ale neimplementovala jej.
                          * Když už taková situace nastane, je možné udělat wrapper. Je to sice otrava, ale těžké to není a nevzpomínám si, kdy jsem to dělal naposledy.
                          * Při implementaci uvádění seznamu rozhraní spíše pomáhá, aspoň podle mě: Uvedu seznam implementovaných rozhraní a tím mám vlastně takový „todo list“. IntelliJ IDEA mi nabídne metody k implementaci po stisku Ctrl+I a přinejhorším se to zastaví na kompilátoru.
                          * V dokumentaci seznam implementovaných rozhraní (a taky seznam tříd implementující dané rozhraní) je IMHO spíše vítaný než obtěžující. (V Go by to nebyl problém, ale zmíněné typové definice Scaly by s tím asi měly problém a dynamické jazyky jakbysmet.)

                          Ale nějaké případy, kdy bych to považoval za přípustné tu jsou:
                          * Jde především o jednoduché případy jako ta metoda close(). Ale na druhou stranu, u rozsáhlejších rozhraní těžko stane, že třída vyhoví požadavkům nějakého rozhraní, aníž by si toho byl autor vědom.
                          * Spíše bych to vnímal jako praktický ústupek vycházející ze skutečného (ne úplně ideálního) stavu.
                          * V případě implicitních konverzí (těmi lze ve Scale lokálně „přidat“ metody) se strukturální typy hodí, yle to už odbočuju – týká se to spíše samotných strukturálních typů než původní připomínky. Použil jsem to třeba tady, i když tam není návratový typ funkce toTimes explicitně uveden: https://github.com/v6ak/Scala-implicit-conversions-example/blob/master/times-repl.scala

  3. Čelo

    zdroje

    Jelikož si již nějakou dobu snažím proniknout do světa RoR, tak uvedu zdroje, na které jsem nalezl doporučení, či které se mi samotnému osvědčily. Samozřejmě budu rád za jakékoliv doporučení.
    Sám jsem začal se základním Rails Guides, asi týden před příchodem českého překladu :)
    Neustále jsem slyšel doporučení na Agile Web Development with Rails, nyní již ve čtvrté edici. Zakoupil jsem, také doporučuji.
    Rails For Zombies už v článku padlo a mě se líbil i, ve stejném duchu vedený, ale již placený, Rails Best Practices na codeschool.com
    Jinak dalším zajímavým zdrojem mi je railscasts.com a jeho přepis asciicasts.com (poslední epizoda popisuje třeba změny a novinky v betě 3.1)
    A pak už github a jednotlivé projekty :)

    1. Pepa

      Re: zdroje

      Ještě bych doporučil screencasty a PDF z Peepcode. Například:

      http://peepcode.com/products/rails-3-upgrade-handbook-pdf
      http://peepcode.com/products/meet-rails-3-i
      http://peepcode.com/products/meet-rails-3-ii

      na Peepcode jsou taky podobný zdroje k Ruby samotnýmu, k Sinatra, ke Gitu, atd. Všechno je placený, ale těch pár dolarů jednoznačně stojí za ten ušetřenej čas.

      Pár mírně pokročilých zajímavých screencastů o scaling v rails je tady:

      http://railslab.newrelic.com/scaling-rails

      Pak ještě přímo na webu rails:

      http://rubyonrails.org/screencasts/rails3

      1. Čelo

        Re: zdroje

        Díky, na Peepcode jsem zapomněl… zatím jsem si zakoupil jen to video o Sinatře a o dalších uvažuji.

      2. Alois.Janicek

        Re: zdroje

        Peepcoďáci jsou hustí, díky ním pomalu opuštím Aptanu Studio a migruju na gVim a terminál. Mají perfektní screencasty, srozumitelný i pro průměrný angličtináře ;)

  4. honza

    Srovnání s Djangem

    Jakožto neznalý Railsů bych se rád zeptal znalců, jak si stojí RoR ve srovnání s Python frameworky, například zde často probíraným Djangem?

    1. vidya

      Re: Srovnání s Djangem

      django a rails su si velmi podobne a ked som sa ja medzi nimi rozhodoval tak v konecnom dosledku zavazila len moja osobna preferencia pythonu. aj deployment je velmi podobny (passenger <-> mod_wsgi, unicorn <-> gunicorn, capistrano <-> fabric …). niektore veci ktore vedia railsy v zaklade ako migracie db schem, vyriesis v djangu neoficialnymi aplikaciami(south), alebo naopak ten slavny generovany admin v djangu vs mnozstvo gemov crud v railsoch. jediny zasadnejsi rozdiel okrem jazyka je podla mna vo velkosti komunit, railsy ju maju o nieco vecsiu.

      1. Martin Soušek

        Re: Srovnání s Djangem

        Já jsem se tedy rozhodoval asi před rokem, zkusil si aplikaci v obojím a nevím jak je to teď, ale Django si s sebou v té době táhlo velké pozůstatky toho, že vzniklo kvůli stránkám jakéhosi deníku.

        Takže jsem se rozhodl pro RoR a nelituji. Ten bastl PHP už nikdy.

        1. Honza Kral

          Re: Srovnání s Djangem

          Dovolil bych si pomerne silne nesouhlasit. O Djangisty je veste velky zajem a je jich stale nedostatek. Pro kvalitniho Django programatora neni zadny problem sehnat si praci v CR ci v zahranici, sam bych pro nekolik mel pozici.

          1. Droid

            Re: Srovnání s Djangem

            Ahoj Honzo, z grafů to na mě působilo úplně obráceně, proto děkuji o objasnění :-) Pokud jsi stále v SF, tak posílám pozdravy za oceán :-)

  5. BeryCZ

    web2py

    a co web2py? nikdo žádné zkušenosti? osobně si myslím, že je to pro vývojáře v pythonu nejlepší framework… s RoR ovšem nemůžu srovnávat, nikdy jsem neviděl

    1. Honza Kral

      Re: web2py

      Web2py bych skutecne neradil mezi kvalitni python frameworky. Nerespektuje zakladni konvence pythonu a jeho navrh i samotny kod je pri nejlepsim pochybny. Pokud chcete alternativu k Djangu, vrele doporucim Flask.

      1. sputnikone

        Re: web2py

        Flask bych spíše viděl jako ekvivalent Sinatry. K Djangu podle mě neexistuje nějaká pythoní alternativa.

    2. David Marko

      Re: web2py

      Já mohu doporučit, velmi dobře postaveno a krásně se s tím dělá. Vývoj web2py je dynamický, komunita vlídná …

      Bylo několik diskusí, kde lidé z Django a Flask komunity poukazovali na nedodržování Python zvyklostí … ale jsou to dezinformace. Ano, není to Django nebo Flask, ale je vidět, že to dělají lidi co to i používají :-).

      1. BeryCZ

        Re: web2py

        já právě jednou „lehce“ nakoukl na web2py a django a teda web2py mi přišlo flexibilnější… samozřejmě, pokud práskáte prezentačky o 4 stránkách, django je dobrá volba, ale pokud máte vytvořit nějaký velký projekt, asi bych osobně volil spíš web2py…

  6. ZiziTheFirst

    Groovy (and) Grails

    Dobrá volba je také jazyk Groovy a k němu framework Grails. Vyzkoušel jsem jak RoR, tak tuto kombinaci, a subjektivně se mi lépe pracovalo s Grails. Styl práce bývá, jak zmiňuje Lukáš v článku, téměř totožný napříč všemi MVC frameworky, Grails není výjimkou, pod kapotou Hibernate + Spring a další, a běží na platformě Java – se všemi výhodami a nevýhodami, např. možnost kombinovat statické a dynamické typování nebo využít Java dovednosti i knihovny:)

    RoR je vynikající a přes dost exotickou syntaxi ho dlouho ho u mě nic nepřekonalo, až Grails+Groovy ho myslím předčí.

      1. v6ak

        Re: Play framework

        Teď si taky hraju s Play a vypadá dobře. Prý je celkem podobný RoR (ale rozhodně ne kopie), ale porovnávat nemohu.

        Ale rozdíl je v tom, že nepoužívám Javu, ale Scalu. U Play to možná nemá až takový význam, protože Play portuje některé věci (např pattern matching a lambda) ze Scaly do Javy, byť místy trocchu šíleně, a podpora Scaly v Play místy trochu vázne. Navíc k Javě můžeme přidat Lombok (údajně s Play spolupracuje) a jsme zas o kus blíž Scale. Takže u Play Scala nemá až takový význam jako jinde, zvlášť v případě relativně jednoduchých aplikací.

        Jinak je Scala pěkný jazyk. Na první pohled tam není statické typování až tak vidět (není ukecaná), ale funguje. Funkcionální prvky a DSLka taky umí pěkně, třeba SQueryL je zajímavé DSL.

        Pěkná vlastnost Play je výměna tříd za běhu. Asi díky bezstavovosti jde mnohem dále než takový JRebel. A bourá mýtus, že cokoli spojeného s Javou musí být složité.

      2. ZiziTheFirst

        Re: Play framework

        Díky za tip, neznám, ale vypadá pozoruhodně:) Neznám bohužel ani Scalu, ale na zběžný pohled mi přijde podobná jako Groovy, resp. řešící podobné výhrady vůči Javě, ale trošku jinak. Pro Groovy podle mě mluví ještě to, že za ním stojí SpringSource, tj. potažmo VMWare, a že je tím pádem postaráno o to, že to nebude hračka jednoho autora (viz výhrady k Pythonu nebo Ruby) a že se bude rozvíjet predikovatelně.

        Každopádně ale souhlasím s tím, co zmiňoval Vít Šesták, že složitost čehokoli spojeného s Javou se stala jen mýtem ;)

        1. v6ak

          Re: Play framework

          Ke Groovy vs. Scala: Scala je typovaná staticky, to pro mě bylo velké plus. Je tu teda i experimentální Groovy++, která umožňuje i statické typování.

          Co se týče týmu, který za jazykem je, tak sice Scala na tom není až tak dobře jako Groovy, ale je za tím více lidí – není to one man show. A i některým velkým společnostem (namátkou Twitter) asi ten rozdíl až tak nevadil. Ale zajímavý argument to každopádně je.

          Když jsem se rozhodoval mezi jazyky jako Scala, Mirah, Groovy++ a BooJay, pro Scalu rozhodlo:
          * Je to dospělý jazyk (a používaný v produkci i velkými firmami).
          * Podpora IDE je aspoň trochu použitelná, byť ne ideální. (Možná Groovy++ na tom taky nebude špatně.)
          * Groovy++ zřejmě nahrazuje třídy jako java.lang.Object. Pokoušet se kombinovat dva takové jazyky by mohlo být peklo.
          * Scala generovala celkem pěkný bytecode, narozdíl od Groovy++. Porovnával jsem Hello World a tomu, co lezlo z Groovy++, jsem moc nerozuměl.
          * Groovy++ na mě působí místy dojmem, že mu ještě něco z dynamického typování zbylo. Headius (jeden z autorů JRuby a jazyka Mirah) ostatně ten můj dojem z bytecode komentoval, že příčinou asi bude to, že prvotní návrh se soustředil na dynamické typování. Je to sice jen pocit, ale i to může ovlivnit výběr.

          Navíc, Scala mi přijde místy čistější než Groovy(++). Například persons.map(_.age) je sice delší než persons.age, ale je to mnohem popisnější. Našlo by se i pár dalších drobností. A přijde mi jako větší průkopník.

          Na stranu Groovy(+i) zase musím říct, že do mixovaného projektu s Javou může zapadnout lépe než Scala. Ale i tam to není strašné a pokud se na to myslí, neměl by to být problém. Naopak, u čistě Scalového projektu ale může být možnost využít věci, u kterých nelze snadno držet rozumnou kompatibilitu s Javou (např. traity), výhodou. Tady nevím, jak je na tom Groovy.

        2. martin

          Re: Play framework

          složitost čehokoli spojeného s Javou se stala jen mýtem

          Na konci každého rébusu stojí prohlášení „vždyť je to triviální“. Jenže to neznamená, že dotyčný ten rébus vyřešil nebo že nad tím neztrávil čas(=$/€).

          O jednoduchosti a rychlosti programování čehokoli spojeného s Javou svědčí i ty ceny za vývoj (doufám, že tady nikdo nebude argumentovat kvalitou kódu apod.) A to ani nenačínám kapitolu deploymentu, zdrojů a pod.

          Pokud je cokoli spojeného s Javou efektivnější než něco jiného, tak si to cokoli najde určitě cestu. Zatím to válcují projekty v PHP, Rails příp Perlu. A nebýt úspěchu Rails, tak kdo ví, kdybychom se dočkali Grails a podobných. (mimochodem nevíte někdo proč je Grails tak pomalé?)

          1. v6ak

            Re: Play framework

            Ono je to spíš o overengineeringu, který je tu častý, ale rozhodně ne nutný.

            A pomalost GRails? Někde jsem četl něco ve smyslu, že heslo Groovystů je ‚na rychlosti nezáleží‘. A v Javě 6 má svůj podíl i JVM, která není na dynamické jazyky dělaná. (Dá se to i relativně efektivně, stačí se podívat na JRuby, ale je s tím zbytečně moc práce.) V Javě 7 má být instrukce invokedynamic, která podle zatím kusých informací má v takovýchto jazycích dramaticky zrychlit běh.

          2. krespo

            Re: Play framework

            pocul som ze cena(Eur/hod) RoR developerov je vo vseobecnosti nizsia ako cena javistov pri porovnani rovnako kvalitnych programtorov v tychto jazykoch,frame­workoch. Je to pravda ? ak je to pravda preco je to tak, ked obidvaja vyprodukuju rovnako kvalitny kod ?

            1. Martin Malý

              Re: Play framework

              Protože cena není dána výkonem, kvalitou ani schopnostmi, ale ochotou kupujícího zaplatit. Takže hraje roli spousta dalších subjektivních a individuálních faktorů…

            2. martin

              Re: Play framework

              Cena (čehokoli) je otázka nabídky a poptávky, nikoli kvality (tedy ne přímo).

              Rubystů i Javistů je nedostatek, ale každá ta skupina dělá (pokud hovoříme o rozdílné ceně) jiný typ SW pro typově jiné zákazníky. Zatímco typický Ruby resp. Rails projekt je webová aplikace typu webové CMS (eshopy, redakční systémy, …), web GUI k čemukoli atd. tak typický Java projekt v té vyšší cenové třídě jsou enterprise informační systémy pro střední a větší společnosti. A k tomu si musíte osvojit i API těchto systémů.

              Jinými slovy bych řekl, že hodinovka obou programátorů na stejném typu projektu bude podobná, jen ta celková cena webové aplikace bude (podle mého názoru) u implementace v Javě vyšší a doba dodání delší.

              1. krespo

                Re: Play framework

                myslim ze cena javystu bude vyssia(voci RoR programatorovy) na rovnakom type projektu pretoze programator nastupuje za pevnu sadzbu/hodinu(ktora je u javystov vyssia) a to uz je na managemente aby zohnal co najviac rentabilne zakazky. A kedze ti „najviac rentabilny“ (banky..) preferuju java, .net(z roznych dovodov ako support, integracia so sucastnymi rieseniami..) tak railsi v tomto svete asi velmi nemaju sancu na vysoko ziskove zakazky(ktore suvisia s implementaciou core funkcionalit), teda niejaky maju sancu na niejake kvazi „pomocne“ prace. Z toho vyplyva ze rovnako kvalitny programatori v tychto jazykoch zvecsa nebudu mat rovnaku cenu.

                1. martin

                  Re: Play framework

                  pevnu sadzbu/hodinu(ktora je u javystov vyssia)

                  myslím, že tahle informace pochází ze zkreslené statistiky, kde většina projektu právě nejsou ty webové, kde nachází uplatnění rails.

                  Pokud ale vezmeme nějaký specifický segment trhu, tak nemůže být jedna skupina výrazně cenově jinde, protože by na tom trhu nic neudala. Java, ruby, perl, php nemá pro zadavetele příliš mnoho rozdílů z pohledu obchodu. Když kupuju jako zákazník eshop nebo CMS, tak je mi jedno jestli běží na v ruby nebo php. Všichni budou +- cenově stejně. Pochopitelně tam nějaký rozptyl je, ale ten je i v rámci nabídek jen rails nebo jen php. atd.

                  Jo jiná je pochopitelně situace, kdy zadavatel potřebuje nějakou vlastnost (např. konektor do čehosi nebo cert. atd.), kterou nabídne jen java. Tím automaticky získává konkurenční výhodu a šanci na vyšší cenu.

                  1. krespo

                    Re: Play framework

                    Ano prave v tychto webovych aplikaciach(typicky eshop,cms) kde nezalezi na technologii ma rails sancu, len skoda ze su to tie menej rentabilne projekty. Teda napr. eshop v jave musi byt logicky vzdy drahsi nakolko programatory su nakupeny na sadzbu x eur/hod, a ta sadzba odpoveda nakladom z korporatnych projektov, ktore su viac ziskove ako napr. tvorba eshopu.

                    No korporatni klienti casto nepotrebuju eshop,cms ale praveze potrebuju upravovat existujuci funkcionalitu, pripadne chcu novu funkcionalitu, ktoru ale treba zintegrovat s existujucou(typicky java,.net systemy, a dalsie technolgoie z muzea).

                    A teda ked to zhrniem teda rozdielnost trhov na ktore sa zameravaju je dovodom preco je rails programator lacnejsi ako javista.

              2. karmi

                Re: Play framework

                Většina Rails aplikací v České republice není ani redakční systém ani e-shop. Jedná se zpravidla o složitější weby s napojením na externí API, administrační systémy, rozsáhlé webové aplikace, apod.

                1. krespo

                  Re: Play framework

                  karmi: z toho potom vyplyva ze posobia na rovnako ziskovych segmentoch trhu a teda cena rovnako dobrych rails, java developerov by mala byt rovnaka. A ako je to v praxi je rovnaka ? Umna osobne plat nieje motivacny fakor ale radost z programovania, ale viem ze u mnohych ludi je to motivar cislo 1.(aj u kvalitnych programatorov) preto by bola tato informacia zaujimava. (Este jedna vec ohladom startupov a ASP.net ma napadla ale to dam kvoli logicnosti do noveho threadu)

                  1. v6ak

                    Re: Play framework

                    Když si představím typickou J2EE aplikaci, vybaví se mi těžký overengineering a programátory jásající nad mnoha vrstvami a pěkným použitím návrhových vzorů. Takovýto projekt se prostě musí prodražit… Mojw slova potvrzuje třeba i tento článek: http://javicka.blogspot.com/2011/02/je-java-produktivni-jazyk.html

                    Nicméně, neznamená to, že se to musí týkat všech projektů. Zmíněný Play framework se ostatně od J2EE v mnohém distancuje a asi to nebude úplně náhodou. Ostatně, http://www.playframework.org/documentation/1.2.1/faq#aYouguysdontevenknowhowtoprograminJava…a je takové rýpnutí do klasických Javových frameworků…

      1. ZiziTheFirst

        Re: Groovy (and) Grails

        Jj, to je zajímavé pro lidi, kteří Ruby mají rádi. O Grails jsem psal pro ty, kterým až tak nesedlo (JÁ;) a chtějí se Ruby zbavit, protože mají třeba rádi Javu, ale zároveň se jim líbí Rails a chtěli by něco podobně se používajícího.

  7. vetesnik

    Pěkné

    Já mám hlavně rád Ruby, to je prostě jazyk, ve kterém to většinou nebolí a jde to, a hlavně je to zábava. :) Díky Ruby je Rails Railsem.

    Celá komunita mi připomíná komunitu Eplí – produkty jsou většinou mnohem více vymazlené a user-friendly, a díky tomu je i snaha dělat kvalitnější software větší.

  8. mamlasek

    proc?

    Pridam si trosku flajmi otazku (nedokazal jsem odolat): proc by nekdo prechazel z PHP zrovna na Rails/RoR? Prijde mi to, jakoby nekdo z trabanta presel na trikolku, byt blistivou a pozlacenou, s trasnemi na riditkach.

    Dokonce mam takovy nazor na Ruby, ze bych tento „jazyk“ zakazal i ve skolach – sice je to jazyk jednoduchy a (trosku) „vhodny“ na uceni, ale obcas mam pocit, ze mezi informatickou mladez zanasi prilis prapodivne zpusoby. Python mi k vyuce prijde vhodnejsi, Ruby je vice o magii a voodoo.

    1. v6ak

      Re: proc?

      Na PHP jsou už i celkem slušné frameworky, například Nette. A má celkem slušnou podporu hostingů a je startovním bodem na serverové části webu pro většinu lidí. Takže je celkem pochopitelné, že se do PHP pustí kdekdo. A taky je celkem pochopitelné jít za lepším. Co je na tom vlastně nenormálního? Začnu s davem a pak se rozhodnu lépe.

      1. mamlasek

        Re: proc?

        „…a pak se rozhodnu lépe“

        O tom prave mluvim :D Ruby rozhodne nepovazuji za „lepsi rozhodnuti“, spise tak za vice vyhypovane. 2008/2009 to byl velky Hype, vsude se Ruby tlacilo, dnes po tom nestekne ani pes, a PHP stale bezi – pro male, pro velke, pro ty co to umi i ty co neumi…

    2. Droid

      Re: proc?

      Nevím, já v Ruby žádnou magii nevidím a Python mi příjde nehezký a moc ukecaný ;-) Navíc jsem nenarazil na žádný framework, který by mě zaujal. V Ruby jich mám hned několik.

      1. mamlasek

        Re: proc?

        Byl sem na jedne karmiho prezentaci o RoR… po tom, co byla zminena nejaka super-uzasna featura s poli (neco ve smyslu, ze kdyz pridame k nazvu promenne „s“ na konec, mame z toho pole), jsem se prestal nejak soustredit a jen sem se smal, a rikal si, kdo tohle muze sakra pouzivat.

        (A dalsi vec me zaskocila – normalni smrtelnik musi pouzit skript pro vygenerovani struktury aplikace, protoze vytvorit ji rucne je neskutecny opruz – a to v mych ocich svedci o dost pitome vymyslene architekture)

        1. martin

          Re: proc?

          A dalsi vec me zaskocila – normalni smrtelnik musi pouzit skript pro vygenerovani struktury aplikace, protoze vytvorit ji rucne je neskutecny opruz – a to v mych ocich svedci o dost pitome vymyslene architekture

          Vždyť symfony(PHP) má to samé. Django taktéž. Tak s čím to srovnáváte?

          1. mamlasek

            Re: proc?

            K symfony jsem se nedostal z podobneho duvodu jako k RoR – neverim skriptum, chci si skeleton aplikace vytvorit sam, coz je ale pro RoR i pro Symfony extremne zdlouhave a obtizne. Framework ma programatorovi pomahat a delat praci veselejsi.

            1. martin

              Re: proc?

              :-) To je ale hodně naivní přístup. Nevěříte skriptům? A binárkám věříte? Věříte počítačům? Čemu vlastně věříte? Sobě? Věříte, že manuálně neuděláte chybu? Dělal jste vůbec někdy větší projekt? Dělal jste někdy větší projekt s někým nebo jen one-man-show? Já věřím, že vám váš styl práce vyhovuje, ale upřímně – jste exotika. Takhle to většinou efektivně nefunguje.

            2. Bruce

              Re: proc?

              V tom pripade nepouzivajte frameworky a mozte robit vsetko sam. Pripadne co Vam brani v tom, si skeleton napisat rucne? Ved je neskutocne zabavne robit dookola to iste ;)

    3. Pepa

      Re: proc?

      Myslím, že tvá otázka má solidní flejmovací potenciál. Obsahuje útok a zesměšňování nějakého cíle, aniž by uváděla jakýkoliv argument nebo oporu pro daný názor. :-)

    4. martin

      Re: proc?

      Python mi k vyuce prijde vhodnejsi, Ruby je vice o magii a voodoo.

      Ruby a magie a voodoo? To asi narážíte na metaprogramování, které obecně vytváří efektivní a konzistentní kód, ne? Ale v Ruby můžete programovat i bez takové míry abstrakce a dynamiky. A nebo zaměňujete Ruby a RoR?

      Já mám rád na Ruby, že
      1. kód je samopopisující (10.times do…, [1,2,3].each do….; „slovo“.empty?) a nedělá mi číst po někom kód i velké aplikace a upravovat ji.

      2. konzistentní O přístup (je to sice drobnost, ale v Pythonu mi vadí explicitní self a neobjektové primitivy)

      3. gem aneb jednoduchá instalace, včetně správy verzí balíčků

      4. jednoduché rozšiřování o C knihovny

      5. rake (něco jako make) a řada dalších nástrojů

      6. rvm (správa verzí celých ruby prostředí)

      7. nevynucuje zbytečná pravidla (středníky, odsazování)

      a další.

  9. Bedňa

    Toto je čo za blivajz

    Toto je reklamný článok? Škoda času, takýto blivajz som už dávno nečítal a dal som ho celý a márne hľadal pointu. Kto nevie robiť v PHP nebude vedieť robiť ani v lepších a hľavne rýchlejších frameworkoch ako je je RoR. Tfuj :(

  10. krespo

    startupy rails asp.net

    ake vyhody pre startup poskytne rails v porovnani s asp.net. Vychadzame z reality kde vecsina ludi vychadza zo skol naucenych javu,.net. Java je overkill, asp.net je kompaktny framework.
    learning curve:
    jazyk- asi ruby je strmsiu learning curve
    frameworku- asi narovnako

    Co teda vybrat? vzhladom na znalost zo skol logickejsie mi pride asp.net(proste skor sa da zohnat clovek na .net) a teda aj projekt by sa mal rychlejsie naimplementovat.
    Myslim ze typ patternu(MVC alebo MVP) nema az taky velky na rozhodnutie. Aj ked asp.net ma aj MVC ale to zas nepouziva vela ludi.

    1. v6ak

      Re: startupy rails asp.net

      Co je na Javě overkill? Jazyk samotný mi přijde spíše příliš jednoduchý než příliš složitý. Pravda, některé frameworky mohou být overkill, ale ne všechny…

    2. krespo

      Re: startupy rails asp.net

      este jedno VELMI podstatne kriterium som zabudol dodat do otazky a to: nakolko je dobra skalovatelnost rails rieseni voci .net,java? Vychadzajme z poziadavky na cloud app pre velky pocet uzivatelov. Viem ze twitter s tym mal problem tak potom to prepisali do scaly.

      1. v6ak

        Re: startupy rails asp.net

        Ačkoli jsem zastáncem Scaly, musím poznamenat, že u Twitteru přepisovali do Scaly jen část, asi nějaký vnitřní queuing systém, u kterého potřebovali vyšší výkon (ne škálovatelnost). Někde jsem četl, že zvažovali i JRuby, ale chyběla jim, tuším, podpora volání nativních funkcí. (Ono to i v JRuby jde, ale přes Java Native Interface apod., tedy jinak než v Ruby MRI.) A taky Scala dosahuje obvykle lepších výkonových výsledků než JRuby. Myslím si, ačkoli krk za to nedám, že frontend dodnes jede na RoR.

        Něco o tom je tady: http://www.artima.com/scalazine/articles/twitter_on_scala.html
        Nějaké citace:

        „We find Ruby and Scala are very complementary. We use Ruby, actually specifically Rails, for things that it is very strong at. All the front end stuff that it does very well.“

        Ke zvažování JRuby: „We did. At the time we looked into it, we simply couldn’t boot our Rails app on JRuby. Too many of the Ruby Gems we make use of require C extensions, and haven’t been ported to JVM-friendly versions. The performance of JRuby was also not even on par with MRI (the C implementation of Ruby), much less a language like Scala. We’re open to trying out JRuby again in the future, but we’re also hoping that some Ruby patches will help in the meantime.“

          1. karmi

            Re: startupy rails asp.net

            Ne, jen přepsal vyhledávání z Rails do Javy. Frontend aplikace je v Rails. Chce to číst pečlivěji.

            1. v6ak

              Re: startupy rails asp.net

              To pak jo, já to jen prolétl. Ale nechápu, proč v takovém případě nepoužili Scalu. Rozdíly ve výkonu tu bývají na úrovni odchylky měření.

  11. Richard Riman

    Zdroje

    Pridam take nejake zdroje:

    http://rails-bestpractices.com/
    https://www.ruby-toolbox.com/

    Zde napr. take sikovna knizka o testovani Rails aplikaci: http://everydayrails.com/2012/06/13/rspec-book-complete.html

    a obecne cely portal http://everydayrails.com/

    A jelikoz je potreba vysledne aplikace take nekde hostovat:

    http://engined.net/cs/webhosting/ruby-on-rails-hosting/

    Muzete take sledovat muj blog, kde cas od casu vydam nejaky ten clanek o tom, jak jsem resil urcity problem v Rails:

    http://blog.richardriman.cz/

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3487