Ruby on Rails support

Waarom en wanneer gebruiken we Ruby on Rails bij Sping?

De keuze voor een technologie, programmeertaal of framework is van vitaal belang voor de klanten van een technologiebedrijf als Sping.

Voor onze klanten

Bij Sping ontwikkelen we online diensten en platformen waar nog geen standaardoplossing voor voorhanden is, òf omdat maatwerk een alternatief is.

Software productontwikkeling doen we bij voorkeur niet op basis van waterval maar Agile. Dit zorgt voor een een korte ‘time-2-market’ en behoud van flexibiliteit tijdens de ontwikkeling. Dit vraagt ook flexibiliteit in de code waarbij we niet in willen leveren op kwaliteit. Naast dat we maatwerk applicaties bouwen, doen wij ook veel support, onderhoud, updating en monitoring voor Ruby on Rails applicaties.

DigiD, Groupon en Twitter zijn geheel of grotendeels geschreven zijn in Ruby on Rails.

Voor ons als Leverancier

Projectbudget en planningen staan altijd onder druk. Daarom zijn voordelen van Ruby onder andere dat de Ruby-community in de loop der jaren al veel ‘bouwstenen’ en ‘halffabrikaten’ heeft opgeleverd die wij kunnen en mogen inzetten voor onze eigen projecten. We hoeven dus niet alles van ‘scratch’ te ontwikkelen, daarmee zijn wij in staat om een snellere implementatietijd te bereiken en kosten te reduceren.
Een mooi gevolg daarvan is dat we de hoeveelheid maatwerk beperkt houden met behoud van snelheid en kwaliteit. Met RoR zetten we in ‘no-time’ een minimum viable product online en blijven we continu updates releasen met behoud van kwaliteit door automated testing (test driven development). Dat komt onder andere door de laagdrempeligheid en goede leesbaarheid met functionaliteiten die eenvoudig uit te breiden zijn binnen RoR.

Omdat Ruby OpenSource is en er voldoende webbureau’s zijn die ondersteuning en ontwikkeling bieden voor Ruby on Rails is de kans zeer klein op een “vendor-lockin”. Dat betekent dat je overal aan kennis kan komen, en er niet één partij is die je kan “gijzelen” met de code.

Korte development tijd door gebruik van “halffabrikaten” en “bouwstenen”

Hoge kwaliteit door Test driven development en makkelijke functies.

Geen “vendor-lockin” omdat het OpenSource.

Voor Developers en Engineers

Onze Wizards zijn helemaal weg van RoR, en dat is niet zonder reden natuurlijk. Dit komt door een aantal dingen zoals dat de Ruby-programmeertaal de mogelijkheid geeft tot meta-programmeren waarvan Rails veel gebruikmaakt. Dit resulteert in programmeercode die vaak goed leesbaar is en eenvoudig te begrijpen, te onderhouden en uit te breiden valt

Convention over configuration” (COC), ofwel “conventies boven configuratie.

“Don’t repeat yourself” (DRY), ofwel “Herhaal jezelf niet”;

Daarmee zijn belangrijke voordelen ten opzichte van andere ontwikkel frameworks zoals Java (spring/struts/faces) en PHP/memcached onder andere:

• Goed leesbare code door “Don’t repeat yourself” (DRY), ofwel “Herhaal jezelf niet” gebruiken. Het framework zorgt ervoor dat elk stukje code wat je moet herhalen, je kan hergebruiken in nieuwe onderdelen. Denk aan knippen en plakken.
• “Convention over configuration” (COC), ofwel “conventies boven configuratie”, wat betekent dat als iets gebruikelijk is het niet beschreven hoeft te worden. Alleen afwijkingen moeten beschreven worden.
• Het is een relatief makkelijk te programmeren taal en framework waardoor er een lagere instapdrempel is. Hierdoor zijn er aardig wat ontwikkelaars die RoR kunnen maken en onderhouden.
• “Easy tools for automated testing” Ruby on Rails biedt eigen geïntegreerde testmogelijkheden. Dit sluit goed aan bij een Agile/SCRUM ontwikkeltraject met continues integration.
• Het Framework heeft een zeer actieve wereldwijde gebruikerscommunity die bestaat uit softwareontwikkelaars die de passie voor effectief webdevelopment delen. Hierdoor is er veel support vanuit de community en worden er altijd nieuwe bouwstenen bij ontwikkeld.

wij kiezen altijd de beste technologie voor de oplossing van onze klanten.

Wanneer zetten we Ruby on Rails niet in bij een project?

Tot nu toe alleen maar voordelen? Nee, Ruby on Rails heeft – net als alle andere frameworks en talen- ook zo zijn nadelen. Daarom zijn en blijven wij kritisch over de keuze van onze technologie. Sterker nog: wij kiezen altijd de beste technologie voor de oplossing van onze klanten.

Er is sprake van een taalbarrière

Wij kiezen niet voor Ruby als er bijvoorbeeld een ‘taalbarrière’ is of bij ‘multi-thread’ toepassingen met veel parallelle/simultane taken. Maar ook wanneer de klant specifieke wensen heeft over het ontwikkelframework, bijvoorbeeld wanneer er een bedrijfspolicy is om JAVA te gebruiken of als de applicatie nadien in beheer moet worden genomen door een afdeling waar PHP of Windows de ‘standaard’ is.

Performance

De applicaties die in Ruby on Rails zijn ontwikkeld vergen meer resources dan een vergelijkbare applicatie in Java of NodeJS

Een van de oorzaken hiervan is dat Rails een ‘threaded’ server heeft. Een threaded server wil zeggen dat elke aanvraag richting de server, zijn eigen proces en dus ‘thread’ heeft. Elke server heeft maar een maximaal aantal threads, en kan dus maar zoveel aanvragen behandelen.
Stel nou dat het proces van de aanvraag moet wachten en dus een thread bezet houd, dan kan het zijn dat als alle processen moeten wachten ook alle threads bezet zijn de server niks meer behandeld totdat er een thread vrij komt.
Om het even makkelijker te maken: zie het als een parkeerplaats. Als alle plekken bezet zijn, dan kunnen er geen nieuwe auto’s bij. De aanvragen kunnen dan dus niet behandeld worden.
Wat je zou kunnen doen bij threaded servers, is het bijplaatsen van servers. Maar dit kan flinke kosten met zich meebrengen.

Alternatieven

Als alternatief voor threaded servers zijn er event based servers. Het voordeel van dit type server is dat een wachtend proces geen thread gebruikt – als er calls moeten wachten op bijvoorbeeld een API call, dan kan de webserver nog steeds nieuwe requests aannemen. Als die geen API call nodig hebben, kunnen deze direct afgehandeld worden.
Zie het dit keer als een McDrive, als je moet wachten op je grote bestelling dan wacht je op een parkeerplek, maar als je iets kleins hebt kan je het direct ophalen en meenemen. Zo is het dus ook met Event based servers, de hoofdlijn is nooit bezet zodat hij altijd aanvragen kan behandelen, en wachtende processen die krijgen een aparte “wachtplek” op de server.

NodeJS

Er zijn een hoop programmeertalen die event-based web-frameworks hebben; zoals bij voorbeeld scala(play2), elixr(phoenix) en NodeJS (express/sails). Binnen het Sping team gaat de voorkeur uit naar het implementeren van systemen op basis van NodeJS; in de onderliggende taal (Javascript) is het Sping team zeer bedreven. Ook kent NodeJS in de rest van de wereld een grotere aanhang. Hierdoor heeft de taal net zoals bij RoR veel voordelen vanuit de community. Een actieve community betekent vaak dat er goed onderhoud word gepleegd aan de taal en framework.

Sails

Soms is een combinatie de beste oplossing. Bijvoorbeeld door de high performance ‘multi-thread’ toepassingen te bouwen op basis van NodeJS, het webframework Sails en de overige ‘webdelen’ implementeren op basis van RoR. Hierbij kunnen we dan alsnog gebruik maken vele features die Rails biedt, zoals snel een compleet product af te leveren (denk aan login, database management etc). Door de backend in NodeJS/Sails te bouwen (high volume/high speed) en de frontend in Ruby on Rails te bouwen (full featured) gebruiken we de best-of-both-worlds om tot een goed platform te komen.

De voor- en nadelen van Ruby on Rails op een rijtje

Pro’s

• Sluit goed aan op Agile software ontwikkeling: snelheid, flexibiliteit en kwaliteit;
• Actieve community: levert veel halffabrikaten op;
• Fijne taal voor developers, korte leercurve;
• Als Ruby on Rails niet (volledig) volstaat, zijn hybride-oplossingen mogelijk.

Con’s

• Minder goed geschikt voor ‘multi-thread’ toepassingen met veel parallelle/simultane taken;
• Moet goed passen bij de toepassingen en organisatie;

Wil je meer weten over Ruby?

No employee selected.