Ruby on Rails z pohledu odběratele
V návaznosti na minulý článek Rails and the Enterprise a první otázku “jak byste definovali enterprise ?”.
Pokud budeme uvažovat o “enterprise” jako o “podnikovém” software, tak je otázka postavena “jsou vhodné Ruby on Rails pro používání v podnicích”? Pak je třeba definovat kritéria, která rozhodují o vhodnosti používání technologie v podnikovém prostředí. Uvažujme podnik/společnost, která je příjemcem, nikoli dodavatelem software. Podnik chce:
1. Aby software řešil problémovou domému podniku. Pokud podnik potřebuje dostat jakoukoli logiku na web, nepotřebuje specifika jako např. real-time software a tato logika se dá nacpat do klasického request+response+relační db, jsou Ruby on Rails skvělou volbou. Jako programátoři pomocí Ruby skvěle popíšeme problémovou doménu, můžeme vytvořit DSL (domain specific language) a jazyk si v podstatě ohnout podle sebe. Příjemci software je v podstatě jedno, jaký jazyk je v pozadí. Je na schopnostech poskytovatele/dodavatele dokázat, že použitá technologie prostě “bude fungovat”.
2. Aby software fungoval dostatečně dlouho, ideálně aby přežil (časově) potřeby podniku. Tento požadavek je pro příjemce jasný. Pro poskytovatele to znamená přijmout dostatečně agilní model vývoje, který bude rychle reagovat na změny. Podnik se mění společně se světem okolo něj a neexistuje zadání, které by bylo časově neměnné a bez nutných modifikací. Opět je na schopnostech poskytovatele dokázat, že jeho technologie je časově odolná. Ruby on Rails mají za sebou dostatečně dlouhou historii a pokud stále fungují a jsou nasazovány, pak testem odolnosti prošly. Tady je nutno chápat, že 17 let existence Ruby a 6 let existence Rails jsou v IT tak dlouhé etapy, že neschopná technologie by již dávno zanikla. Takže ano, Ruby on Rails jsou časově odolné a nejsou žádný prázdninový hype.
3. Aby měla technologie “zázemí”. Některé podniky se rády šťourají v referencích na použitou technologii a rády slyší, že existuje tzv. “zázemí velké společnosti”. To připomíná známý vtip “Nikdo ještě neudělal chybu tím, že vybral IBM”. Tento pocit bezpečí je falešný, jak jsme nedávno viděli na příkladu Sunu a Javy. Molochy, které poskytují zázemí nefungují. Firmy platí miliony za SLA, konzultanty, metodiky a procesy velkým korporacím, které jako celek degradovaly do bezpohlavních bytostí, jejichž jediným cílem je dosahovat zisku. Mám z 6-leté historie Kyberie bezpočet příkladů, kdy spoléháni na “velkého” dodavatele nefungovalo. Počínaje HW supportem, SW konzultacemi, návrhy na metodiky vývoje, řešení infrastruktury a konče poskytováním SLA… Nejlepší, co lze dle mého názoru udělat je spolehnout se sám na sebe a příjemci/odběrateli poskytnout vlastní zázemí. Ono “velké zázemí” či zvučné jméno může fungovat jen jako pojistka či reference. Ne jako základní stavební kámen.
4. Aby šel software napojit na existující systémy. Možná dostaneme rozhraní, na které se musíme napojit a je možné, že třeba v Javě to půjde jednodušeji. Tady nelze předjímat, vše záleží na konkrétní situaci. Ovšem i s RESTem, který Ruby on Rails používají, případně s web hooks lze dokázat divy.
5. Aby software stál rozumné peníze. Pokud přijmeme klasický platební model “cena za člověkoden”, tak tady jsou Ruby on Rails v obrovské výhodě. Jak jsem uvedl, v Kyberii jsou Ruby on Rails při vývoji asi 10x rychlejší než stack Java+Spring+Hibernate+Wicket+dalších X špaget. Pokud budeme uvažovat jednoduše linárně, tak oproti konkurenci můžeme poskytnout software 10x levněji.
A to už stojí za to vyzkoušet Ruby on Rails, ne?
Railsy jsou o...
Celkom pekny clanok, zaujimalo by ma preco je vyvoj v ROR otolko rychlejsi v porovnani napr. so springom+hibernate … ? Z mojho pohladu velkym problemom moze byt zohnat ludi ktore ovladaju ROR. Taktiez by ma zaujimalo za ako dlho je mozne vyskolit cloveka na ROR(pocul som ze je tam dost strma learning curve),a aka je potom cena takeho developera v porovnani s napr. java developerom?
Comment od peter ferko on 6. 9. 2010 at 19:09
2 peter ferko: vyvoj v ROR je rychlejsi, protoze mas cely stack pohromade a nemusis to spagetovat jako v Jave. Vse ti funguje hned (logovani, testy, deployment pres Capistrano, CI). Lidi si vyskolis. Rychlost je zhruba 1 rok pro cloveka, ktery neumi Javu vs 1-2 mesice pro cloveka, ktery neumi Ruby a Rails, aby byli na stejne urovni pro psani stejne velkych aplikaci. Ja se na to vsak divam ne z pohledu vyvojare (ktery chce hodne penez), ale z pohledu zamestnavatele, ktery chce vyvojare levne, rychle a extremne agilni. IMHO vyskolit interne cloveka pro komplet Java stack je luxus, ktery si mnoho firem dnes nemuze ci nechce dovolit. Drazi vyvojari jsou spatna vec, ktera deformuje trh. Proto potrebujeme jednoduchou a rychlou technologii, kterou ROR nepochybne jsou.
Radeji si to ale zkus. Dej ROR par veceru a napis mi, jake mas pokroky.
Comment od Jiří Hradil on 6. 9. 2010 at 20:35
Ked sa nato pozriem z pohladu developera tak co by malo developera motivovat robit v railsoch, ked by mal prijem nizsi ako java dev. ?
Aj ked nechapem preco by mal mat ROR developer nizsiu hodnotu napr. oproti java dev. ak vedia spravit obaja(RoR dev. aj jav.dev) to iste(pri rovnakej kvalite) len inou cestou (navyse RoR este rychlejsie) ? Pri agilnom vyvoji predpokladam ze developeri niesu hodnoteny podla poctu riadkov kodu.
Chcem sa pustit do jedneho RIA projektu a uvazujem nad 3alternativami: Ruby/Rails, python/django, groovy/grails.
Z tych info co mam tak by som charakterizoval urcite podstatne vyhody/nevyhody:
RoR nevyhoda- smer vyvoja urcuju v podstate dvaja ludia(tvorca ruby, a tvorca rails). Dost nekompatibilne jednotlive verzie. Slabsia performance, skalovatelnost. Vyhodou je vela toolov automatizujucich vyvoj
Django nevyhodou- tiez stoji na dvoch ludoch. Vyhodou kopec modulov.
Grails- Nevyhodou- je to mlady framework, takze nema vela modulov, learning materialov, aplikacii. Vyhodou je ze stoji za tym organizacia, plne moze vyuzivat vyhody javy.
Vseobecne vyhodou dynamickych jazykov su rozne konstrukcie(najsilnejsie ma asi ruby,groovy) DSL atd. -cim prispievaju k rychlosti vyvoja.
Z mojho pohladu na Rich frontend je fajn bud GWT alebo Flex. Preferujem GWT kedze stoji na standardoch, pluginove riesenia casom padnu. Ku GWT vznika dobra integracia so springom,spring roo.
Comment od peter ferko on 7. 9. 2010 at 14:56
2 peter ferko: pokud je jedinou motivaci vyvojare prijem, tak to je dost smutny vyvojar
Railsy jsou o ciste radosti z jednoduchosti, funkcnosti, efektivity. Pokud RoR vyvojar stihne vic prace za kratsi dobu, tak je na tom lepe, protoze usporeny cas muze venovat dalsim projektum, nebo nepracovat a flakat se na plazi 
Body, ktere jsi uvedl - performance, skalovatelnost… Zkousel jsi to osobne, nebo sis to jen nekde precetl? Railsy se diky ’share nothing’ skaluji naprosto skvele, coz jsem nekolikrat zkusil. V porovnani s Javou radove jednoduseji, pokud srovnam narocnost na studium clusteringu JBoss, Glassfish, atd. vs skalovani pomoci jednoducheho balanceru a mongrelu nebo passengeru.
Ona zavislost na 2 lidech - pokud vim, banda commiteru je vetsi. RoR funguji radu let, projektu je hafo, komunita obrovska. O uspechu technologie rozhoduje velikost komunity, nikoli jmeno spolecnosti. Stejne vnikl v Jave Hibernate, Wicket, cela Apache Software Foundation… Na Apache web serveru dnes bezi vetsina netu. Rozhoduje pouzivani a funkcnost, ne znacka.
Zkus si ROR, udelej si v tom mensi projekt, prototyp, cokoli. Uvidis sam.
Comment od Jiří Hradil on 7. 9. 2010 at 23:07