Jan Minárik: S Rails vyvíjíme efektivněji

Firma iQuest je je jedna z prvních společností u nás zabývajících se technologií Ruby on Rails. Co konkrétně děláte? Používáte i jiné technologie nebo se specializujete výhradně na Rails?

Nejsme rozhodně první, kdo se technologií Ruby on Rails v Česku zabývá, určitě je u nás pár lidí, kteří se k Rails dostali už v první verzi před více než dvěma lety. My jsme začali přibližně před rokem. Je ovšem pravda, že jsme hned od začátku do této technologie hodně investovali a dnes máme určitě jeden z největších týmů Rails vývojářů.

Děláme především zakázkové podnikové informační systémy, webové aplikace, obchody, portály, ale i jednodušší dynamické weby. Na web-based aplikace jsme dříve používali PHP, ale teď už jsme zcela přešli na Rails, PHP používáme pouze pro údržbu stávajících projektů. Klient/server aplikace jsme vyvíjeli a vyvíjíme v Javě, Rails framework se pro ně příliš nehodí.

Nelze přehlédnout, že převážná většina vývojářů v Rails používá Mac OS X a na programování používají skvělý editor TextMate. Co používáte vy?

Naši vývojáři jsou výrazné individuality, což se snažíme podporovat. Každý z nás má za sebou různé zkušenosti a z toho vychází prostředí a OS, který kdo používá. Ne, „jablíčko” u nás zatím nikdo nemá, je to Linux / Windows přibližně půl na půl. Na těchto platformách je to s výběrem editoru složitější, podpora Rails se v nich objevuje postupně a co bylo nejlepší včera, je už dnes překonané. Poměrně dlouhou dobu u nás vedl RadRails na platformě Eclipse, ale právě teď téměř všichni děláme v Netbeans verzi 6, kterou v Rails opravdu máloco předčí.

Jak vypadají vaše servery? Pro velkou část webových adminů je synonymem serveru LAMP, někteří používají LightHTTP, jinou databázi nebo třeba Python místo PHP, jakou kombinaci preferujete vy?

Na tuto otázku nechám raději odpovědět našeho odborníka na deployment, Tomáše Holase, cituji:

„Ze začátku se nabízelo řešení s použitím Apache a také jsme ho vyzkoušeli. Mod_ruby jsme zavrhli hned po přečtení dokumentace, protože vůbec neumožňuje provoz ve sdíleném prostředí. Další v pořadí bylo FastCGI a Ruby interpreter (s Apache i s Lighthttpd). Tuto kombinaci jsme museli zavrhnout kvůli problémům se stabilitou, a nejsme jediní, kdo s tím měl problém, např. u 37signals, když používali FastCGI, museli někdy restartovat server i 400× za den.

My používáme Litespeed v kombinaci s Ruby LSAPI. Litespeed není opensource projekt, ale ve verzi Standard je s určitým omezením zdarma pro osobní i komerční použití. Co se týká rychlosti, Litespeed je přibližně nastejno s Mongrelem, ale Litespeed má výhodu v jednodušší administraci, hlavně pokud se jedná o sdílené prostředí. Litespeed má stejnou filozofii jako Apache+ModPHP, používá virtuální hosty, které přistupují k ruby interpreteru přes LSAPI. Pokud bych chtěl něčeho podobného dosáhnout s Mongrelem, tak bych musel použít Apache jako reverzní proxy a přesměrovávát požadavky na Mongrely jednotlivých projektů. Navíc při větší zátěži je potřeba použít Mongrel cluster, protože jeden Mongrel může mít problémy s výkonem při větším množství současných přístupů. Tyto důvody nás vedly k nasazení Litespeedu místo Mongrelu, i přesto, že není licencován pod GPL.“

Jaké projekty jste zatím v Rails řešili? A jak byly vlastně velké?

Náš největší projekt v Rails, který je momentálně velmi úspěšně nasazen u klienta, je merchandizingový systém StoreData. Jedná se o systém pro analýzu efektivity využití prodejního prostoru, zejména ve velkých hypermarketech. Součástí systému je dolování informací z velmi rozsáhlé databáze zboží v prodejní síti daného řetězce v celé ČR. Tento projekt trval cca 10 měsíců. Nyní probíhají další etapy vývoje systému.

Dále jsme v Rails dělali komplexní informační systém pro pojišťovací makléřskou společnost a právě teď dokončujeme B2B řešení pro distributora náhradních dílů a příslušenství v automobilovém průmyslu. Oba tyto projekty měly složitější především analytickou část, ale i programování bylo řádově v jednotkách měsíců.

Pokud vím, iQuest je v současné době největší tuzemská firma pracující v Rails. Jistě se během vaší práce najdou okamžiky, kdy považujete za vhodné Rails nějak rozšířit, udělat plugin nebo tak něco. Přispíváte svými vylepšeními do Rails?

Když jsme s Rails začínali, samozřejmě jsme řešili, zda je komunita vývojářů pro přechod na tuto technologii dostatečně velká a zda si nebudeme muset vytvářet znovu obecné moduly, které jsou k dispozici pro PHP, jako jsou například různé autentifikace, úpravy obrázků, grafy, XML parsery, apod. Z odstupem času musím dát za pravdu optimistům, cokoliv velmi obecného, co jsme očekávali, že bude k dispozici jako plugin, jsme skutečně i našli a úspěšně použili.

Co se týká rozšiřování Rails – zajímavé je, že když programuješ v Rails, přemýšlíš o všech svých činnostech jako jen o rozšiřování funkcionality základního frameworku. Je to filosofie, na které jsou Rails postaveny a dle mého názoru jeden z důvodů, proč jsou tak efektivní. Takže odpověď je ano, máme množství vylepšení do Rails, které by se daly použít opakovaně, tedy jasné kandidáty na pluginy. Uvažovali jsme, že nějaký plugin zveřejníme, až skutečně ověříme, že je obecný, užitečný a že ho skutečně sami využíváme více než jednou. Samozřejmě jen tehdy, pokud k tomu budeme mít odpovídající práva, protože to je při šíření zdrojových kódů u zakázkových systémů základní problém.

Tak kolik kódu máte například v jádře Rails?

Jak jsem řekl, vzhledem k tranzitivnímu chování jazyka (kdykoliv můžete dodefinovat část třídy později) je těžké rozlišit, co je to kód v jádře. Nikdy totiž do jádra nepotřebujete zasáhnout, pokud potřebujete něco přidat. Objevili jsme asi 3 chyby v jádře, ale dodatečně jsme zjistili, že jsou už reportované.

Mnoha opatrným lidem se stále zdá příliš riskantní sázet na u nás tak málo známou technologii jako jsou Rails. Jaký důvod k nasazení Rails máte?

Nejdůležitějším důvodem je efektivita, v Rails je prostě stejná práce hotová rychleji a spolehlivěji a je tedy možné zákazníkovi za stejnou cenu poskytnout mnohem větší funkcionalitu a stabilitu. Není to žádná magie – Rails důsledně vedou vývojáře ke strukturování kódu, striktně objektovému přístupu a důkladnému testování. Především ale velmi efektivním způsobem programátorovi umožňují soustředit se na řešený problém a nepsat stále znovu obecnou funkcionalitu, protože ta už v Rails je.

Problém opakovaného vytváření téhož kódu samozřejmě každý zkušený programátor časem vyřeší na jakékoliv platformě. Většinou si časem vyvine nějaký vlastní jednoduchý framework, který mu vyhovuje a který potom opakovaně používá v různých projektech tak, aby ty obecné věci nemusel řešit stále dokola. Problém ale je, když se potom několik takových programátorů sejde – jejich kódy nejsou kompatibilní a ani je nechtějí vzájemně používat. Nemluvím ani o tom, že samozřejmě framework tvořený jednotlivcem bude mít vždy velmi omezený rozsah a tím i možnosti použití.

Naopak Rails všichni vnímají jako takový „framework, který by si sami udělali, kdyby měli dost času“. Samotný framework definuje nejen rozhraní funkcí, ale i způsob členění mojí aplikace, což v důsledku znamená, že je težké naprogramovat něco, co bude příliš jiné, nepochopitelné a nekompatibilní s Rails přístupem.

Je požehnáním, že autoři Rails zvolili pro svůj projekt jazyk Ruby – když to nejde jedním způsobem, skoro vždy to jde několika dalšími. Samotný programovací jazyk je jediný výrazový nástroj programátora a jeho flexibilita je strašně důležitá. Sám někdy zjišťuji, že když přemýšlím v Ruby, přemýšlím rychleji.

Rails jsou v zahraničí velmi populární, u nás je bohužel vidět, že jsme o několik let nazpět. Jak to vidíš s nástupem Rails u nás? Kdy to tak bude a zda jsou zde nějaká specifika oproti zahraničí, která tento nástup ovlivní?

Nejsem prognostik, vůbec bych nerad mluvil do řemesla analytikům IT trhu, to by ses měl raději ptát jinde. Za sebe odhaduji, že jsme pozadu přibližně o rok, tedy velká vlna se rozjíždí právě teď – sám vidíš, jak víc a víc lidí přichází s nadšením pro Rails.

Jaká je motivace pro vývojáře, aby se naučili Rails, přinese jim to nějakou výhodu v zaměstnání? A co platové podmínky, není výhodnější naučit se třeba Javu nebo C#?

Java a .NET jsou univerzální nástroje, ve kterých lze vyvíjet cokoliv. Oproti tomu Rails je vysoce specializovaný framework pro vývoj webových aplikací. Specializace je obrovská výhoda, která Rails dělá efektivnější a umožňuje vývojářům stejnou práci udělat rychleji. To se počítá především jako konkurenční výhoda – nepochybně bude v blízké budoucnosti po Rails programátorech velká sháňka a nelze než doporučit, aby se této technologii věnovali.

Toto se ale týká hlavně vývoje webových aplikací. Velká část IT odvětví nebude boomem Rails nijak ovlivněna a pokud v nich dominuje Java, .NET, C++, apod, určitě to tak bude i nadále.

A v neposlední řadě – z těch méně racionálních argumentů – myslím, že většina vývojářů dělá svou práci proto, že je to baví a za sebe musím říct, že Ruby on Rails jsou zkrátka zábavnější (smích).

Co považuješ za největší nevýhodu Rails u nás? Nesetkali jste se například s nedostatkem vývojářů, kteří Rails znají?

Musíš si uvědomit, že jsme s Rails začali v době, kdy jsme ani nemohli očekávat, že u nás budou k dispozici nějací vývojáři. Nehledali jsme tudíž znalosti Ruby on Rails, ale spíš potenciální schopnosti a znalosti programování web-based aplikací, schopnost organizace, apod. Nakonec se nám to vyplatilo, teď máme tým zkušených Rails vývojářů, díky kterému jsme bez problémů schopni v tomto prostředí realizovat velké projekty. Nicméně stálo to hodně úsilí, a to jak ze strany firmy v podobě značné investice, tak i ze strany vývojářů, kteří se studiu Rails hodně věnovali i ve volném čase.

V tom vidím největší nevýhodu Rails u nás – nemožnost získat komerční školení velmi omezuje použití Rails ve firmách orientovaných na software s vysokou přidanou hodnotou. Takové firmy obvykle udávají hlavní proud, a tím je rozšíření Rails značně omezeno.

Zúčastnil ses s několika kolegy konference Ostrava on Rails. Jak se Ti na konferenci líbilo a co tě zaujalo nejvíce?

Konference byla dost motivující, zejména příspěvky Tobiase Lütkeho o veleúspěšném Shopify a Jamise Bucka, který dal všem nahlédnout do zákulisí vývoje Rails. Zejména jsem ocenil možnost diskuze s přednášejícími.

Poslední dobou je patrná snaha o vytvoření české komunity okolo Rails. Jak se na to díváš ty? Účastnil by ses něčeho takového a čím si myslíš, že by se mělo začít?

Jak už jsem řekl, okolo Rails existuje velmi rozsáhlá a zavedená anglicky mluvící komunita, kde lze velmi snadno získat odpovědi na nejrůznější technické otázky. Od české komunity bych si naopak sliboval spíš společenské působení – jakési „šíření osvěty“, nebo spíš upozornění na Rails, na jeho výhody a zejména navázání osobních kontaktů s konkrétními vývojáři. A jak začít? Myslím, že právě Ostrava on Rails byla tím správným krokem, já sám jsem tam poznal množství velmi inteligentních lidí.

Díky za rozhovor. Chtěl bys za sebe či za iQuest čtenářům něco vzkázat?

I já děkuju. Vzkázat? Snad jen – věděli jste, že Yukihiro Matsumoto byl ve Wikipedii o tři roky dřív než Kaiser Chiefs? Vzpomeňte si na to, až vám bude někdo tvrdit, že nezpívají o Rails (smích).