Přejít k navigační liště

Zdroják » Různé » Od PHP až k Ruby on Rails

Od PHP až k Ruby on Rails

Články Různé

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.

Dlouhá léta s PHP

Jako většina online agentur, zabývající se vývojem webových aplikací, jsme stavěli naše řešení na PHPku. Povětšinou jsme vytvářeli standardní aplikace typu web s CMS, e-shop apod., ale dostalo se i na aplikace na míru.

Jelikož už ale fungujeme nějaký ten pátek, tak jsme si prošli barvitou evolucí, od garážových začátků na živnostňácích až po naši současnou značku eBallance. Po technologické stránce, z pohledu vývoje, jsme se rozvíjeli také. Začínali jsme ale v době, kdy dnešní webové frameworky buď vůbec neexistovaly, nebo byly teprve ve velmi raném, dosti neohrabaném stádiu vývoje.

Tu dobu si jistě všichni dobře pamatujete: většina webových vývojářů stavěla na PHPku, zpravidla podle knihy Jirky Koska, absence kvalitních frameworků ale měla dva efekty – kdo neměl smysl pro kulturu kódu, tak vytvářel po technické stránce dosti tristní aplikace, a kdo chtěl být poctivý, tak si začal psát vlastní framework, resp. často spíše pseudo-framework.

My jsme se snažili zařadit mezi druhou skupinu a stejně jako velká část ostatních jsme si vystavěli vlastní řešení, které jsme pojmenovali Defactory. Samosebou s ambicemi vytvořit univerzální platformu pro tvorbu webových aplikací, se kterou dobudeme svět.

V minulosti jsme se snažili využít i rozšířené open-source balíky jako Joomla, Drupal či WordPress, ale odradily nás jak „kulturou“  svého kódu, tak i problematickou účelovostí – udělat v nich něco čistě na míru nám připadalo prostě jako zápas.

Postupem času se začaly objevovat open-source frameworky, kterým se podařilo vybočit z řady a získat na svou stranu početnou skupinku uživatelů – vývojářů. V tomto bodě jsme už ale měli Defactory ve stavu, kdy dostatečně plnila naše aktuální potřeby, a hlavně: byl to framework, který jsme si sami vytvořili, a tudíž jsme přesně věděli, jak do detailu funguje a jak pomocí něj vytvořit aplikace, které naši klienti poptávali. Přechod na jiný framework tudíž v tu chvíli pro nás nedával smysl.

PHP frameworky jako Zend a Symphony ale záhy nasadily rapidní tempo a poměrně rychle nabídly takovou architekturu a možnosti, kterým jsme sami nebyli schopni konkurovat. Začínali jsme tak cítit, že se něco musí změnit, že je naše tempo vývoje naším aktuálním frameworkem limitované a budeme s tím muset něco provést.

K Railsům jsme se dostali vlastně náhodou

Začalo to nevinně – na podzim minulého roku jsme se rozhodli, že veškeré naše a klientské projekty, které jsme doposud hostovali na managed serveru, přesuneme do Cloudu – konkrétně na Linode, který nám, na doporučení Lukáše Konarovského, vycházel nákladově cca na desetinu ceny našeho stávajícího serveru.

Když jsme začali s Lukášem plánovat přípravu virtuálního serveru a migraci projektů, tak jsme se do hloubky bavili i o zlepšení našich vývojových procesů (jako automatizaci deploymentu apod.). V rámci toho jsme dospěli k zajímavému závěru – náš systém na to nebyl dostatečně připraven, a tak nás Lukáš začal nenápadně lanařit na svůj nejoblíbenější webový framework – Ruby on Rails – kde jsou veškeré zmíněné věci už elegantně vyřešeny.

Jelikož jsem otevřený novým technologiím a naše aktuální situace nebyla dlouhodobě udržitelná, tak jsem se rozhodl dát Railsům šanci, a vydali jsme se při rozvoji novým směrem.

Skočili jsme do toho po hlavě…

Nemám rád polovičatá řešení, a když do něčeho jdu, tak naplno – i v tomto případě jsem volil poměrně radikální, i když možná trochu riskantní postup. Promluvil jsem si s týmem, co si o přechodu na Rails myslí, a po pozitivním ohlasu jsme si řekli, že do toho opravdu půjdeme, a naplno. Zhruba za měsíc už jsme nové projekty vyvíjeli výhradně v Rails.

Přestože jsme projekty stavěli původně na vlastním produktu, měli jsme dobrou znalost i standardně využívaných PHP frameworků jako Zend Framework, Kohana či Prado, a tudíž pro nás přechod na Rails nebyl bolestivý. De facto většina současných frameworků využívá podobné architektonické prvky jako MVC, Active Record apod. stejně jako Rails. Vývojář s léty praxe se pak poměrně rychle zorientuje. Jedná se spíš o pochycení odlišné syntaxe, příp. koncepce řešení některých standardních situací, jako je zpracování formulářů, routování nebo třeba komunikace AJAXem. Kvalitních zdrojů a dokumentace je ale dost, nemusíte se tedy bát, že byste se ve frameworku ztratili.

Zároveň nám velmi pomohl právě i Lukáš Konarovský, který nám, jako zarytý Rails evangelista, poskytl celou řadu užitečných zdrojů a rad, nasměroval nás na výuku vývoje v Rails a souvisejících technologiích a postaral se o nastavení celého vývojového a produkčního prostředí. Bez všech těchto věcí by asi naše startovní pozice byla o hodně horší.

Pokud jde o vhodné zdroje, tak výchozí základ Lukáš pěkně shrnul ve svém blogpostu. Nám při výuce asi nejvíce pomohly dva hlavní zdroje, které každému začínajícímu vřele doporučuji – RailsForZombies a původní Rails Guides.

Co se týče vývojového a produkčního prostředí, nachystal nám Lukáš na našem virtuálním serveru vcelku standardní sestavu pro vývoj v Rails. Základem je Debian, webový server Nginx a Ruby 1.8.7. Cílem bylo server co nejvíce odlehčit, tudíž na něm běží pouze minimum potřebných procesů. Verze svých projektů spravujeme skrze instalovaný GIT, deployujeme přes Capistrano a veškeré zálohy se nám automaticky zasílají na Amazon S3, který navíc na první rok využití nabízí 5GB úložného prostoru zdarma.

Je na místě zmínit, že vývojáři, pracující na Windows, mají výchozí pozici ztíženou. Samotné Rails včetně souvisejících technologií si totiž rozumí se systémy na bázi Unixu, ale s Windows nejsou příliš kamarádi. Jste-li tedy uživateli Windows, očekávejte více práce s instalací, konfigurací, aplikace zde běží pomaleji a zároveň práce s příkazovou řádkou, bez které se v Rails neobejdete, není tak přívětivá jako např. na Macu. Vše se ale dá vyřešit bez nutnosti změny platformy. Pro instalaci a následný běh pod Windows doporučuji např. následující zdroje – RubyInstaller for Windows, Vagrant nebo Console.

Open-source balíky ani v Rails světě nestačí

Jak jsem již zmínil, naší hlavní činností z pohledu vývoje byla tvorba vcelku standardních webových aplikací. V PHP světě nás ale volně dostupné open-source CMS, e-shop a podobné balíky nepřesvědčily, proto jsme šli cestou vlastního řešení. Po vstupu do světa Rails jsme si ale řekli, proč vše vyvíjet nanovo, určitě zde bude celá řada kvalitních hotových open-source aplikací.

V porovnání s PHP světem jich však je v Rails podstatně méně. Resp. těch, co něco opravdu umí a mají fungující komunitu, je jak šafránu. V jednoduchosti lze říci, že nejsilnější Rails systém pro správu webového obsahu je Radiant CMS, zatímco nejpokročilejší e-shop platformou je Spree Commerce.

Architektura, technické zpracování i uživatelské rozhraní obou balíků je povedené, avšak obdobně jako v PHP světě velmi jednoúčelové. Každá z platforem sice má rozsáhlou, uživateli vytvářenou knihovnu rozšíření, takže můžete svůj web obohatit např. o diskuze, přehled událostí nebo ho napojit na Facebook, ale stále půjde o správu běžného webu.

Pokud se však, jako naše agentura, živíte zakázkovým vývojem, kdy jednou vytváříte klasický web s CMS, podruhé pak elektronický obchod na míru a jindy třeba kombinaci obojího s komunitními prvky, máte i v Rails světě s open-source balíky najednou problém. Jednotlivé balíky totiž nelze vzájemně propojovat a musíte si vždy vybrat, který z nich na projektu využít. Pokud potřebujete funkce kombinovat, pak se dostanete do situace, že buď budete mít e-shop s rozšířením na CMS, anebo CMS s rozšířením na e-shop. Nějaká obecnější, neúčelově zaměřená platforma s portfoliem standardních komponent typu stránky, produkty, diskuze apod. pro stavbu klasických aplikací zde však, stejně jako v PHP světě, chybí.

Máte tedy následující možnosti: Buď se zaměříte, budete implementovat např. pouze e-shopy, a tudíž se stanete specialisty na jednu vybranou platformu, kterou do hloubky ovládnete a přizpůsobíte si ji dle svých potřeb, anebo se rozhodnete zůstat u širšího portfolia poskytovaných aplikací, a pak je nejvýhodnější si vystavět vlastní řešení, které bude vašemu stylu práce ideálně vyhovovat.

Hlavní síla Rails implicitně není v tvorbě krabicových řešení, ale spíše v rapidním, z pohledu programátora velmi přívětivém, vývoji aplikací na míru. Díky této vlastnosti a díky velkému množství již hotových knihoven, tzv. gemů, však můžete svůj základ pro stavbu „krabicových“ řešení připravit poměrně rychle, což byl nakonec i náš případ – obnovili jsme naši starou platformu Defactory, avšak na zcela novém podvozku. Pokud půjde vše podle plánu, rádi bychom ji následně na GitHubu zveřejnili coby open-source.

Společnost eBallance nabízí agilní vývoj webových aplikací v Rails s úzkou vazbou na online marketingové služby a s ohledem na obchodní cíle svých zákazníků.

Komunita a kultura

Nejsilnějším prvkem na Rails je pravděpodobně komunita a její kultura. Rails vývojářů je, v porovnání např. s vývojáři v PHP, podstatně méně, ale dovolím si tvrdit, že jejich průměrná kvalita je viditelně vyšší. Samozřejmě, i v PHP je celá řada špičkových programátorů, naproti tomu v Rails také nalezneme nejednoho amatéra. Můj pocit a dosavadní osobní zkušenost mě ale prozatím přesvědčila, že najít kvalitního Rails programátora je podstatně snazší než najít obdobu v PHP.

Je otázka, čím je to způsobeno. Dle mého názoru to bude primárně díky kvalitě Rails frameworku, který své uživatele svou prověřenou architekturou a striktními konvencemi nutí psát aplikace velmi podobně – výsledný kód aplikace dvou různých Rails vývojářů bývá často daleko podobnější než např. dvou vývojářů v Zend Frameworku, který má naopak konvence poměrně volné.

Dále se liší situace region od regionu. Např. u nás nejsou Rails mezi vývojáři ještě příliš rozšířeny – podle globálního komunitního serveru Working with Rails se u nás k Rails hlásí 80 lidí (realita bude samozřejmě vyšší). Cestu si k Rails nejčastěji naleznou vývojáři, kteří již mají něco za sebou a hledají něco víc – což byl i náš případ. Z toho důvodu může domácí Rails komunita působit možná trochu elitářsky, přičemž je pravdou, že řadě domácích Rails vývojářů sebevědomí a silný entusiasmus k Rails rozhodně nechybí.

Česká komunita ale rozhodně není uzavřená, ba právě naopak. Domácí Rails evangelisté, jako např. Karel Minařík, mladý Tomáš Jukin nebo třeba již zmíněný Lukáš Konarovský, se snaží komunitu co nejvíc otevřít. Máte-li zájem s Rails začít, rozhodně doporučuji se do práce v komunitě aktivně zapojit. Vstupní branou pro vás může být některý z následujících zdrojů – RubyOnRails.cz, jejich Twitter účet a Google Group, Rails fórum – nebo dorazte na tradiční Ruby sraz, který se koná první středu v měsíci večer, zpravidla v pražském baru Fraktál.

Pro mladé, začínající vývojáře ale jsou i další možnosti, jak s Rails začít. Tomáš Jukin nabízí úvodní Rails školení, Karel Minařík je vám schopen nabídnout školení Rails i GITu na míru vašim potřebám a dokonce i na univerzitě – konkrétně na Unicorn College – naleznete kurz Webové technologie, kde se s Ruby a Rails studenti seznámí od základů pod výukou Tomáše Holase a Jana Minárika.

Jste-li firma, která váhá, podobně jako jsme váhali my, zda na Rails přejít, a obáváte se např. nedostatku personálních kapacit na trhu, pak myslím, že přehnané obavy nejsou na místě. Rails vývojářů u nás sice není tolik, jako např. vývojářů v Nette, ale firem je také podstatně méně – oficiálně něco přes deset – takže volných vývojářů se zájmem o práci je poměrně dost. Např. mně se podařilo pro jeden větší projekt za týden sestavit tým pěti Rails vývojářů, což mě samotného až překvapilo. Zpravidla se vám podaří sehnat kvalitní programátory, musíte ale na druhou stranu počítat s jejich vyšší cenou oproti např. běžným PHP vývojářům.

Pokud jste vývojář, který o přechodu na Rails uvažuje, tak bych vás taky podpořil. Hlad po kvalitních Rails programátorech je nejen na domácím, ale především i na globálním trhu. U Rails vývojářů je velmi časté, že spíše pracují coby freelanceři – kontraktoři, a řada českých vývojářů outsourcuje své služby do zahraničí, zpravidla do západní Evropy či USA. Pro tyto účely může posloužit např. některý z pracovních portálů, ať už je to např. obecný Guru.com nebo třeba Job Board přímo od 37 signals – tvůrců Ruby on Rails.

Shrnutí

Pokud budu mluvit za svou firmu, tak v Rails prostředí se sice pohybujeme ještě poměrně čerstvě, ale s přechodem z původního vývoje pod PHP jsem spokojen a dle mého názoru nám tento krok velmi pomohl ve zkvalitnění našich vývojových procesů a prospěl efektivitě práce. Tudíž čistě za sebe, i za svou firmu, mohu tento krok vřele doporučit.

Rád si nyní poslechnu váš názor. Pokud v Rails vyvíjíte, jak jste s tím spokojeni? Co vám vyhovuje a co naopak chybí či vadí? Pokud o Rails teprve uvažujete, tak jaké jsou vaše vstupní bariéry, čeho se obáváte nebo co vás brzdí? A pokud v Rails nevyvíjíte, ani o tom neuvažujete, tak v čem si myslíte, že je technologie, kterou aktuálně využíváte, pro vás vhodnější? Podělte se v komentářích pod článkem.

Komentáře

Subscribe
Upozornit na
guest
102 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Pepa

základní “getting started” guide je k dispozici i v češtině na http://guides.rubyonrails.cz/

Pepa Chmel

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

johno

Odporucam skusit JetBrains RubyMine. Bezkonkurencne najlepsie IDE na Rails.

Alois.Janicek

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

Pepa Chmel

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.

Pepa

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.

n0

„v budoucnu“ :-D

Myslím že s příchodem RoR3 už uteče i ten zbyteček co se drží naděje ;)

Zkusit můžete např. http://www.sublimetext.com/

Kit

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.

Čelo

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.

Petr

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.

blizz

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

pexxi

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.

Pepa Chmel

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)

Pepa Chmel

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

alancox

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.

martin

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

xx

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.

martin

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

xx

Tomu nerozumím, co to říká o produktivitě?

martin

Že se tím vyprodukuje víc ;-)

xx

Já myslel produktivitu jednoho člověka.

krespo

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

xx

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

martin

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.

v6ak

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

jos

přesnější by bylo říct:

oni PHP programátoři přejdou ledajakou chybu

nyan

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.

v6ak

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.

xylon

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

xx

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

xylon

ano a z tejto vlastnosti vyplyvaju vyhody a nevyhody, o ktorych je dobre vediet.

v6ak

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 .

krespo

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

xx

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

v6ak

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

Čelo

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

Pepa

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

Čelo

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

Alois.Janicek

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

D

http://ruby.railstutorial.org/ruby-on-rails-tutorial-book

Aktualna verzia je k Rails 3.0 (3.0.7), existuje aj 2.3 a kniha je +/- updatovana s novymi verziami Rails.

honza

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?

vidya

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.

Martin Soušek

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.

Mintaka
Droid

To jde. Například to, že v UK a USA se s Djangem asi moc neuživíš.

Honza Kral

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.

Droid

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

Erich

Radiant moc nedoporučuji, daleko lepší projekt je http://refinerycms.com/ (není to klasické CMS, spíš framework nad CMS). Pokud chcete použít klasické CMS tak můžete zkusit http://www.locomotivecms.com/.

BeryCZ

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

Honza Kral

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.

Martin Putniorz

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

David Marko

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

BeryCZ

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…

daevid226

prave zacinam delat ve we2py a docela sa mi to libi

ZiziTheFirst

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

David Marko

Mohu-li ještě z vlastní praxe doporučit tak http://www.playframework.com . Jednoduchost alá ROR, schkvělá podpora IDE.
Já dělal projekt v Grails a vyzkoušel Play! a zůstal. Tedy co se javy týče.

v6ak

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

v6ak
ZiziTheFirst

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

v6ak

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.

martin

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é?)

v6ak

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.

krespo

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 ?

Martin Malý

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ů…

Opravdový odborník :-)

Cena je dána nabídkou i poptávkou.

martin

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

krespo

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.

martin

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.

krespo

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.

karmi

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.

krespo

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)

v6ak

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ů…

Pepa

Když jsme u té Javy, tak ještě existuje JRuby, což je Javová implementace Ruby. Normálně v tom jede většina Ruby / Rails aplikací, a v případě potřeby se z toho dá přímo volat Java, viz. https://github.com/jruby/jruby/wiki/CallingJavaFromJRuby

ZiziTheFirst

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.

Oldřich Vetešník

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

mamlasek

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.

v6ak

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.

mamlasek

„…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…

Pepa

dnes po tom neštěkne ani pes? :-o žijeme na stejné planetě? :-)

Droid

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.

mamlasek

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)

martin

…kdo tohle muze sakra pouzivat.

Nebylo to tohle: http://bit.ly/jm3eZN ?

Třeba twitter na tom vyrostl. Github a řada dalších http://rubyonrails.org/applications

martin

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?

mamlasek

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.

martin

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

Bruce

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

Pepa

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

mamlasek

Zatim se to moc neujalo :( , lidi asi maji jine veci na praci.

martin

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

Bedňa

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

krespo

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.

v6ak

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…

krespo

ano vdaka ze si upresnil myslel som frameworky, nie javu ako jazyk.

krespo

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.

v6ak

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

krespo
v6ak

Tak už asi jo. Díky za odkaz!

karmi

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

v6ak

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

karmi

Protože v Twitteru si rádi hrajou.

Richard Riman

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/

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.