Honza Malý9.1.2012Zpět

Čtvrt roku s Ruby on Rails

Když jsme před půl rokem dostali do ruky zadání na realizaci webového systému pro management energetických dat, bylo nutné sáhnout po seriózním a kvalitním frameworku. Pro práci v PHP nejvíce vyhovoval Zend framework, ovšem jeho odstrašující dokumentace (kterou nemohl psát člověk, co má lidi rád) a pozvolná křivka učení (nějaké zkušenosti s ním jsme v té době již sbírali a stále sbíráme, každopádně je to proces pomalý a zaminovaný spoustou překážek) mě přiměla hledat další možnosti. Vlastní zvědavost mě však tlačila pro řešení mimo PHP. Na aplikaci takového rázu by jistě sedělo robustní řešení jako Java nebo .NET – ale to už samo o sobě klade vyšší nároky na čas, obsahuje netriviální setup a tedy vyžadovalo zapojení zkušených programátorů, kteří nejsou levní. Zbývali dva významní favorité - Rails a Django.

Rozhodovat se u těch dvou jen na základě programovacího jazyka (Rails běží na Ruby, Django na Pythonu) nelze – oba jsou vyspělé moderní jazyky s velkou podobností řadě detailů. Rails si mě nakonec získalo svojí webovou propagandou, kvalitní dokumentací a spoustou dobrých výukových zdrojů (knihu Agile Web Development with Rails jsem již recenzoval a stále ji považuji za jeden z nejkvalitnějších výukových materiálů pro vývojáře, s jakým jsem měl tu čest). V neposlední řadě mě k Rails přikláněl i velmi pozitivní článek na Zdrojáku. Rád bych zdůraznil hlavní účel celé zakázky, totiž vytvořit uživatelsky jednoduchou, ale kvalitní a hodnotnou webovou aplikaci. Django považuji za kvalitní framework, ale při srovnávání dostupných zdrojů mi přece jen Rails dává větší smysl při vývoji „webové aplikace“, a Django se blíží spíše ke slovíčku „web“. Toto rozhodnutí i dnes vnímám jako čistě subjektivní, proběhnout zkrátka muselo – není cílem tohoto článku srovnávat Django s Rails (a dokud nebudu mít dostatečnou znalost Djanga, tak to ani dělat nebudu).

Disclaimer
Autor článku je si vědom toho, že s Ruby on Rails pracuje teprve krátce a jeho závěry mohou být tedy mylné nebo vyvratitelné. Není v žádném případě namířen proti konkrétním lidem, komunitám nebo programovacím nástrojům. Vznikl hlavně proto, že podobných článků o zkušenostech s RoR je v českých luzích jako šafránu. Pokud máte k článku nějaké postřehy, kontaktujte mne a hodnotné příspěvky v budoucnu zveřejním.

Počátek

Start od nuly je v Ruby on Rails (dále RoR) těžký, a to i když máte po ruce celkem dobrou dokumentaci, výbornou knihu a po 6 letech i spoustu materiálů v diskuzních fórech. Ono je to totiž něco úplně jiného než PHP – familierní jste pouze na úrovni pojmů jako HTTP požadavek, MVC model a podobné. V době, kdy se začínalo psát jádro systému, jsem měl vlastně zkušenost s vytvořením eshopu dle výše zmíněné knihy – a dalo se k ní v každém rysu vznikající aplikace vracet. Samozřejmě, že v této době vznikalo nejvíce omylů a špatných rozhodnutí, která bylo nutno měnit nebo za zvýšené námahy udržovat do budoucna.

Postupem času zjišťujete, že Rails je agresivní framework, který zpravidla velmi tvrdě vyžaduje správné fungování věcí. Ne že by to zejména začínajícím programátorům vadilo – ale ono je někdy složité zjistit, jak to tedy má být správně. Doporučuji, hned jak podchytíte naprosté základy jazyka a frameworku, okamžitě nastudovat a pochopit všechny návody na Rails Guides. Zejména základní věci, jako je Active Record, relace mezi modely a chování kontrolerů vám ušetří hodiny zoufalého tápání ve vzduchoprázdnu. Framework RoR je až neskutečně elegantní a dodnes zírám na to, jak dokáže zkušený vývojář pomocí MVC popsat chování jakékoliv aplikace. Méně zkušený vývojář od počátku všechny souvislosti nedokáže vidět a má problémy.

Jednotlivé aspekty RoR si zaslouží samostatné články a rád se k nim někdy v budoucnu vrátím. Následují zajímavosti, shrnutí a závěry, které mi z toho plynou.

Active Record

Active Record
Na vysvětlenou - Active Record je návrhový vzor, který převádí relační databázové úložiště do formy objektové, kterou k němu přistupujete z aplikace - více např. wikipedie.

Active Record dnes stále více lidem dělá vrásky zejména s ohledem na výkon a v RoR to někdy bývá tristní. Ušetřený čas vývojáře při využití této objektové vrstvy může mít problematické dopady (rychlostní, paměťové) a některé úlohy je stále lepší řešit ručně psaním SQL dotazů – například mě zarazilo, že Active Record nijak nepodporuje hromadný insert.

Systém sice nabízí cachování, ale to funguje velmi primitivně a při minimální změně vašeho zaměření v dotazu (např. další omezení nebo řazení) se cache invaliduje – dokážu se ale smířit s faktem, že by opačné chování, aby bylo korektní, stálo někde na hranici umělé inteligence. Zvyknete si na to a časem kladete chainované Active Record příkazy co nejefektivněji (zkoušet si je můžete prakticky vedle v konzoli, což je skvělé). Těším se na dobu, až bude mít libovolný PHP framework konzoli :-).

Při práci s JOINy zpočátku nelze než nadávat, než pochopíte, jak to vlastně celé funguje a proč se vám jako výsledek dotazu nevrací i joinovaná data (tedy než objevíte metodu select a zejména si uvědomíte, kdy se vrací jako výsledek model se všemi jeho položkami a kdy data odpovědi). Malým tipem je nastudovat si práci s includes() – obeznámené vývojáře potěší, že jde o dotazy formou velmi podobnou, na které stojí knihovna NotORM známého PHP vývojáře Jakuba Vrány – zkrátka kladení malého množství dotazů s kompletujícím se seznamem ID jednotlivých položek, o které máte zájem. Oba přístupy (join a includes) jsou vůči sobě trochu na nože a celkově vyžadují trochu lepší znalost SQL, než by pro vnějšího uživatele Active Recordu mělo být zdrávo. Velmi zde pomůže konzole.

V RoR ovšem není databázová vrstva despotická a zcela volně můžete pokládat a sbírat výsledky z vlastních dotazů. Filozofický rozpor mezi Active Record a relačním SQL tak pokaždé řešit nemusíte – stačí si vybrat jeden z přístupů (byť je ten „syrový“ nesrovnatelně méně pohodlný).

Nested forms

Nested forms řeší práci s nested models, tedy stav, kdy váš model má na sebe navázány další modely. Koncept je od Rails 2.3 přímo podporován a nabízí sice trochu těžkopádná, ale funkční řešení, jak vykreslit formulář, který pokrývá více na sobě závislých modelů, což je situace, která se vám při vývoji webových aplikací stává typicky neustále. Ani jsem si nemyslel, že to nějaký webový framework vůbec dokáže sám o sobě podporovat nebo nějak rovnou řešit. Dosud máme noční můry z „subforms“ v Zendu. Tady mě Rails překvapilo, zpočátku velmi příjemně.

Existuje totiž přímo „akceptační“ direktiva zadaná v modelu, kterou explicitně naznačíte možnost předání vnořených modelů z formuláře, a pomocné metody při tvorbě šablony stránky s formulářem, které název všech použitých inputů poskládají správně dohromady. Zde je dokumentace pro začátečníka ošidná a např. způsob, jak to rozpohybovat dynamicky pomocí Javascriptu (dokumentovaný od samotného tvůrce Rails), mi přijde až vtipný, to ale stále nemění nic na faktu, že to funguje. Nakonec pochopíte, že je to o jediné věci – „ohýbat“ názvy prvků ve formuláři tak dlouho, až vše do sebe zapadne a na straně frameworku se po odeslání formuláře vyřeší vše za vás. Několik bezesných večerů to ale bude :-) Kdo nevěří, už tam běží: odkaz na patřičný RailsCast (a další související dohledáte přímo z něj).

Nested forms ovšem funguje dobře jen pro ten vyzkoušený a tradiční případ, že máte pro vnořené modely přímo do formuláře zadané jejich inputy. Chcete-li podporu formou prvku jako je multiselect, nefunguje to. Přitom Javascriptových pluginů, které z ošklivého HTML multiselectu udělají použitelný widget, je celá řada. Nevadí to ale příliš – Rails a jeho relační vrstva má přímo metodu, do které když vložíte seznam ID daných vnořených modelů, provede úpravu „relace“ (přidání nebo smazání) dle jejího typu na určený stav. Je to tedy jeden řádek navíc v controlleru (nebo v modelu, jste-li příznivcem „fat model, thin controller“). Právě tyto věci dělají framework silným a jakmile vám přejdou do krve, zvýší vaši produktivitu.

DRY, kódování v Ruby, čitelnost kódu

Nejvíce zranění budete v RoR inkasovat v počátku bitvy zejména kvůli čitelnosti kódu. Ve vojenské terminologii bychom použili termín „nebojové ztráty“. Pro člověka přecházejícího z PHP bude překvapením, jak moc se v Ruby a zejména v Rails protěžuje koncept lambda funkcí, resp. předání bloků kódu jako dalšího parametru metody. Zatímco v PHP jde stále spíše o anomálii, zde je využívání bloků kódu jako parametru podobně přirozené, jako v Javascriptu.  Složené závorky v Ruby, resp. bloky do ... end, je třeba nastudovat ze všeho nejdříve. Jen tak se otevře cesta k porozumnění naprosto půvabných one-linerů, které často kombinují  velké množství netriviálních operací. Ve většině případů jde o transformace dat z jednoho formátu na druhý, sám jsem si jich napsal už tolik, že z nich asi vydám slovníček.

Zde je opět velkým pomocníkem konzole. Jakmile se naučíte používat všechny zákonitosti Hash a Array, pochopíte parsování YAML formátu a dokážete si tak vytvářet sofistikované konfigurační soubory, vaši aplikaci to posune zase o kus dál.

CoffeeScript
Jazyk ne nepodobný Ruby, který se kompiluje do Javascriptu. Jde o fenomén, který výrazně zpřehledňuje práci v Javascriptu a velmi fandí funkcionálnímu programování. Dostatečně popsán a popularizován např. na Zdrojáku.

Čitelnost proti primitivním jazykům také ztěžují nepovinné závorky při volání funkce a nepovinné označení hashe (asociativního pole), když je na konci funkce – prostě jen píšete jeho jednotlivé prvky oddělené čárkou. Když k tomu přidáte, že většina metod v Rails API má několik podob dle parametrů... plyne z toho zajímavý efekt – některé věci v Rails se naučíte používat i poslepu z tutoriálů a až později pochopíte, jak jsou vlastně řešené – že jde o volání metod tříd s parametry, ne o jakési „direktivy“, jak by se na první pohled mohlo zdát. Nejvíce jsou takto „zdeformovány“ úvodní části definice tříd modelů. Teď mě napadá, že kdo pracuje delší dobu s CoffeeScriptem, nebude překvapen – dílčí věci zápisu syntaxe se na detaily shodují.

Z hlediska dodržování konceptu DRY (Don’t Repeat Yourself) musím říct následující: Tím, že RoR škatulkuje řešení aplikace do jednotlivých částí komplexu MVC, dochází paradoxně k potencionální hrozbě opakování stejných funkčních částí. Typickým příkladem je opětovná inicializace ne-POST dat (ne všechna data vždy nutně souvisí s odeslaným formulářem) ve view, které bylo vráceno při chybě validace, neboť volaná akce controlleru je vlastně odlišná (akce „edit“ vs. „update“). PHP trampové, které žádný framework nikdy zcela nezkrotí, obvykle řeší obsluhu obou dotazů stejnou metodou, jen na jejím počátku bývá zpracovávatelská část (přiznejte se, kolik takových jste už napsali?). Je a vždy asi bude zodpovědností  programátora, jak se ke DRY postaví. Já to vyřešil psaním dalších (privátních) metod kontroleru, které se sdílejí, lepší by asi bylo dělat to přímo přes model, který ale nemůže nést odpovědnost úplně za vše.

Co mě na oficiálních materiálech štve, je absence rad pro rozšíření vlastním kódem (mimo adresář app/ struktury MVC). Někdy je kód využitelný ve více částech, většinou k tomu budete ale sahat z důvodu lepší čitelnosti, např. když je business logika vašeho modelu netriviální. K tomu si můžete tvořit vlastní Ruby moduly a přidávat je do aplikace jako knihovny. Vyžaduje to sice ruční include toho daného modulu, což by pro pravověrné RoR fanatiky mohlo být původcem břišních stahů, ale na druhou stranu vám to dá absolutní volnost v rozvržení a dedičnosti tříd. Většinou to zvládnete i pěkně DRY-compliant. Náročnost? Lehce pokročilá. Vyžaduje zásah v hlavním konfiguračním nastavení RoR (pro správné include cesty). Pro složitější aplikaci bych znalost a orientaci v tomto typu programování považoval za nezbytnou. Narozdíl od prostého používání metod frameworku (kterým nemusíte z hlediska implementace vůbec rozumnět) odemkne a naučí krásy jazyka Ruby a velmi pomůže s dodržením DRY (jednotlivé části MVC pak mohou volat naše funkce jako jakési „vnitřní“ API).

Pravověrníci by mě určitě zastavili a poukázali na možnost balíčkování kódu pomocí Gems a jejich „bundlování“ k hotové aplikaci – abych napsal více, musel bych to nejprve umět a používat (a ani nechci z důvodu velké provázanosti mého kódu a zbytku aplikace, nevidím to prostě moc znovu-použitelně).

Osobně mám s gems problém jiný – zatímco v PHP bylo zvykem rozšiřující knihovnu připoutat do adresáře „lib“ a zde ji libovolně přepsat přímo na úrovni zdrojáku (ano, je to odpornost, ale někdy potřebujete jen „malinkatou“ změnu), nyní jste izolováni od samotného kódu (resp. spočívá jinde ve filesystému a s aplikací se nepřenese např. při deploy  – ale stahuje se odděleně podle verze) a máte prakticky dvě možnosti:

1.    monkey-patching – protože Ruby je prototypové, můžete klidně jakoukoliv metodu jakékoliv třídy dosažitelné v systému přepsat, což je ale podle RoR-komunity zavrženíhodné (a z toho důvodu asi také velmi používané :-)). Mimochodem, to je také jeden z důvodů, proč skuteční programátoři nemají rádi Rails,
2.    najet na repozitář, udělat si vlastní větev (nejč. na githubu) a přepsat, co je třeba (což se mi nelíbí, protože moje úprava bude veřejná a nechápu proč, když jde o úpravu na míru mojí aplikace).

Abych téma DRY a způsobu kódování v RoR nějak uzavřel: říká se, jiný kraj, jiný mrav. Respektování zvyklostí je zcela jistě základní premisou úspěšného vývoje v RoR. Pokud nechcete ohýbat neohnutelné a bojovat s implementací funkcí, které se vám nehodí do krámu, svoji zkušenost s Ruby on Rails si značně zkomplikujete.

REST

REST (Representational state transfer) je obecně platný způsob tvorby HTTP požadavků k obsluze nějaké vaší entity (např. projektů v intranetu, článků na blogu). Tím, že je předepsán, zjednodušuje tvorbu jednotlivých dotazů a unifikuje podobu jednotlivých controllerů. Teoretické čtení opět nabízí wikipedia.

Framework RoR podporuje a jako výchozí nastavení servíruje takové rozvržení požadavků URL a metod (GET, POST, PUT, DELETE), které vychází z modelu REST. Je to klasika, kterou dodržují i scaffoldovací generátory kódu pro nové moduly. Můj dojem z REST je spíše pozitivní – málokterý framework na to klade důraz a mohou skutečně vznikat hloupé chyby, pokud je tvorba cest pochechána na libovůli programátora.

Pro jiné rozložení je možné pracovat přímo s editací nastavení routes.rb. Osobně jsem se k němu dostal zejména, byla-li potřeba mít cesty pro AJAXové responses (které „nepasují“ na existující akce a pro které se hodí separátní pojmenování). Tohle mi přirostlo k srdci v PHP, rozumím ale tomu, že skuteční Rails experti responses napasují přesně na míru REST controlleru. Nedovedu si v tuto chvíli představit, jak bych řešil aplikaci, kde na podobě URL z různých SEO a voodoo-důvodů záleží a je nutné ji přesně specifikovat a ohnout potřebám aplikace. V routes definicích lze nicméně části cesty odezírat „fine-grained“ přístupy s využitím regulárních výrazů.

Validační a „hlídací“ callbacky

Rails obsahuje několik desítek možných callbacků v průběhu života modelu, voláním controllerů atp., které si můžete libovolně definovat a jejich obsluhy specifikovat. Narazil jsem snad jen 2x:

  • pokud before-callbacky modelu vrací false nebo vyvrhnou výjimku, proces na modelu se stopne, transakce se ROLLbackuje (stačilo dodržet pravidlo RTFM :-)),
  • u validací nefungují správně překlady z knihovny I18n pro popisy atributů vnořených modulů – pomohlo mi přepsání dané vykreslovací části error_messages, či spíše hacknutí (kód nebudu zveřejňovat protože nejde zcela jistě o „clever“ nebo „doporučené“ řešení).

Vyloženě pro sport jsem si nadefinoval v aplikaci i dva Observery, které slouží ke sdružení shodných callbacků pro více modelů na jedno místo. Bylo to ale hloupé rozhodnutí – moje observery totiž obsluhují vždy jen ten daný model a tudíž pouze zvyšují nepřehlednost. V dokumentaci je uváděn příklad platebních metod, které jsou použitelné pro více modelů.
Protože někdy není úplně jasné, jaké pořadí callbacků bude vykonáno a jak to model postupně ovlivní, zde více než jinde budete volat po logování. Přímo na třídě modelu se dá jednoduše vyvolat pomocí ModelName.logger.info a nesčetněkrát mi zachránilo kůži.

Velmi užitečná je také vlastnost modelu changed_attributes, která obsahuje hash pouze změněných atributů modelu (key) a jejich předchozí hodnoty (value). Díky této vlastnosti jsem byl schopný rozjet složitější koncepty, jako systém vytváření událostí a historie hodnot.

Přísné chyby

Rails má narozdíl od PHP velmi přísné ošetření chyb. To, co by v PHP znamenalo „notice“, způsobí v Rails většinou fail.

Zpočátku máte tak pocit, že s každým napsaným řádkem uděláte jednu až dvě chyby. Později ale oceníte, že kód, jakmile jednou funguje, korektní, bez minových polí a vrzajících dveří. Ignorování chyb úrovně E_NOTICE v PHP mě už několikrát dovedllo na pokraj zkázy.

S chybami souvisí odlišné srovnávání datových typů a prázdná hodnota nil, se kterou si zpočátku užijete opravdu hodně legrace. Vede to ale k tomu, že na mezní stavy myslíte a ošetřujete je okamžitě, ne až po nějaké pozdější revizi kódu.

Netestuje jenom idiot

Nadpis je naprosto odpovídající současné situaci ve vývoji aplikací. Zejména my odvážní PHP praktikové jsme si zvykli netestovat, a neseme za to bolestné důsledky v podobě nejrůznějších hloupých chyb při provozu aplikace. Rails je, řekl bych, na prvním místě v podpoře a propagaci testování aplikace. Framework k testům naprosto otevřeně vede a nabízí mnoho kvalitních nástrojů na jejich podporu. Implicitně nabízí Test::Unit, výchozí třídu pro testy, a standardním způsobem jde testovat každé zákoutí MVC. Scaffolding (generátor kódu) bez debat vytváří předlohy pro nové testy.

Rails nabízí mnohem víc, je to ale bohužel málo (alespoň zdarma) dokumentováno. Nejlepším zdrojem, se kterým jsem v případě testů pracoval, je tak kniha Rails test prescriptions. Naučí mimo jiné testovací framework RSpec, ve kterém se pracuje lépe a inteligentněji. Naučí operovat s mock objekty, očekáváními. Asi to znáte z PHPUnit, v Rails se dále vše koření vyspělostí jazyka: můžete se těšit na další bonusy v podobě vnoření, dynamických testů a všech praktických dopadů kódu v Ruby. Test v RSpec  vypadá vlastně jako specifikace funkčnosti. Spolu s RSpec doporučuji nastudovat FactoryGirl, gem, který s návrhovým vzorem Factory řeší inteligentně testovací data.

Moje největší chyba byla, že jsem se k testům dostal až v průběhu psaní. Budete-li se učit pracovat v novém jazyku či prostředí, vždy se na začátek věnujte testování, a pak až všemu ostatnímu. RSpec vás rychle dostane do módu TDD (test-driven development) – tedy – na počátku napíšete test pro neexistující kód, který selhává, a dopíšete potřebnou funkčnost tak, aby byl splněn. Důsledkem mého zaváhání v testech byla zbytečná doba zkoumání a dedukování, jak co vlastně zpětně funguje a jak tomu ideálně napsat test.

Samozřejmě, ne všechno funguje tak, jak bych si přál. Některá očekávání mi záhadně přežívají mezi testy, sekvence ve Factories se musí ručně nulovat, pokud na pořadí záleží, validace přes is_valid? občas nepobere asociované prvky (zabere až save), ale věřím, že jsou to jen moje aktuální nářky, které se časem vyřeší. Celkově jsem testy v RoR fascinován a s očekáváním budoucího použití technologií jako Webrat nebo Cucumber nezbývá, než se těšit...

Takže – nebuďte idioti. NIKDY se nepokoušejte vytvořit aplikaci bez fungující sady testů. Ta doba, abyste ručně dohledávali, co se po každé změně rozbilo, již pominula. Potřebu psát testy jsem cítil nejvíce v době, kdy jsem si ověřoval chování svých tříd tak, že jsem je oťukával pomocí konzole. Je to však ruční a náročná práce, zbytečně náchylná k chybování – vyhněte se jí.

Pozor také na „mockovací“ extrém. RSpec v kombinaci s možnostmi jazyka Ruby je tak mocný, že není problémem izolovat kód jakékoliv metody a třídy, a závislosti namockovat. Takový test je ale pak dobrý např. k ověření integrity controlleru, neřeší ale problémy druhotné a terciární, které z těchto závislostí plynou. Snadno tak rozpohybuje a odsouhlasí i metodu, která v normální aplikaci selže.

Rails 3.1 – Coffeescript a Sass

S Rails 3.1 přišla nativní podpora Sprockets, lepší verzování assetů (obrázky, CSS, javascripty k aplikaci), jejich automatické grupování do jednoho souboru. Byl to vlastně jediný upgrade Rails (3.0 → 3.1) co jsem v průběhu aplikace provedl, a při tom se pár věcí doslova rozbilo nebo nefungovalo správně (např. mi stále padá minifikace JS dat).

Jednou ze změn, kterou velmi vítám, je integrace Coffeescriptu a Sass na úrovni „Rails default“. Tyto technologie jsou tak výrazné, že by zasloužily samostatný článek, takže jen krátce:

Sass je lepší, kompilovaný CSS, který pracuje se syntaxí oddělenou správným odsazením, zkracuje definice a zadádí funkce v CSS. Jeho praktickým dopadem je výrazně vyšší čitelnost CSS. Již v PHP jsem pracoval s Less, takže mi přechod nedělal nejmenší problém.

CoffeeScript je dokonalejší způsob zápisu Javascriptu (či spíše úplně nový jazyk), který se do JS kompiluje. Jeho sytax se blíží Ruby, ale přitom využívá velmi specifického způsobu práce JS (funkcionální programování) a posouvá ho k dokonalosti. Zpočátku vyžadoval nějakou dobu na naučení, dnes už úpím a trpím, když mám něco psát v čistém JS. Právě mám o Coffeescriptu rozečtenou pěknou knížku.

Nelze si nepovšimnout, jak brutální změny se v Rails objevují i na úrovni minor verzí. Mottem hlavního developera je, aby Rails vždy byly obrazem toho nejlepšího, co je aktuálně ve světě vývojářům k dispozici. Velmi často je to ale za cenu nevratných a zpětně nekompatibilních změn, což je k vzteku zejména hostérům – viz tato polemika. Kdyby to takto fungovalo v PHP, asi to způsobí konec světa (vzpomeňte co dopadů, zbytečné kritiky a pomalého přecházení přinesl přechod 5.2 → 5.3).

Deploy

Kupodivu nejméně složitá záležitost celého vývoje byl deploy na „staging“ server, kde si k aplikaci přistupuje klient. Částečně je to způsobeno tím, že si server spravujeme sami, a není tedy složité pomocí SSH povolit cokoliv, co jen Capistrano (deploy mechanismus) potřebuje k životu.

Samotný deploy trvá poněkud déle – na vině je proces „zpracování“ assetů (CSS, JS, obrázky) – vše ale probíhá precizně a bezchybně (setkal jsem se vlastně jen s jednou podivnou chybou, kdy se mi nepřejmenovaný soubor - obrázek s rozdílným obsahem na serveru nenahradil).

K deployované verzi je pak možné přistupovat pomocí konzole, SSH na serveru použijete také pro přístup k logům.

Co se týče rychlosti provozu, tak náš vlastní server už je starší a bude předmětem brzkého upgrade, nicméně nic slavného to není. Zda je navině kombinace Apache + Passenger + MySQL, to je otázka, kterou budu ještě řešit. Rails aplikace každopádně obecně (zde opět přebírám z toho, co jsem na internetu dohledal) nevedou co do rychlosti (což dohánějí ve spoustě jiných aspektů). I rychlost vývojové verze s asset engine z verze 3.1 je kritická a pokud provádíte vývoj z virtuálního stroje, doporučuji mít opravdu rychlý disk nebo pracovat na linuxu nativním (tam už mi rychlost tolik problémů nedělala).

Plánujeme také rozjetí na známém českém hostingu, který Rails podporuje (schválně, tipněte si :-)).

Hledání vývojáře

Problémem strategickým rozhodně je, jak a kde najít programátora, který po mě kód převezme. Zatímco PHP programátor je na českém trhu bezproblémovou akvizicí (pravdou je ale velmi různorodá kvalita), pak RoR přitahuje lidí podstatně méně – jde spíše o „niche“ – a jsou tedy dražší. Na druhou stranu, podle všech předpokladů může jít o lidi podstatně kvalitnější, než jsou průměrní PHP vývojáři, zejména, mají-li jednu nebo dvě aplikace úspěšně za sebou.

Pokud jste v RoR zdatní, tento článek vás zcela neotrávil a máte zájem o spolupráci, kontaktujte nás.

Budoucnost

Je velmi světlá!

Jít do RoR vnímám jako rozhodnutí velmi dobré. Ten čvrtrok nebyl jednoduchý, hodně jsem se učil, termíny doslova úpěly a problémy se množily. Celkově jsem z toho ale vyšel bohatší o zkušenosti, poprvé v praxi vyzkoušel zcela nový model vývoje založený na testech, a vyladil první verzi systému, který za pár měsíců již odmaturuje a bude uvolněn. A to s benefity i pro klienta – provádět na aplikaci změny a ladit ji podle připomínek není bolestivé, ono to se všemi výše zmíněnými technologiemi může být i docela zábavná práce. A proto to přece děláme všichni, ne?

Honza Malý
maly@kurzor.net
+420 722 211 443
Honza se specializuje na návrh webů a UI, věnuje se také vývoji.