Ruby on Rails începe treptat să iasă din aria de influență a hipsterilor. Cu siguranță vei fi numit "unicorn" dacă programezi în Ruby on Rails - toată lumea a auzit de existența acestor developeri, dar nimeni nu a văzut unul în realitate. Dar, înainte de a ne afunda în subiect, hai să vedem de ce ai avea nevoie de acest 'rubin pe șine':
Observăm un început modest în 1995 ca limbaj de programare foarte obscur și putem deduce că popularitatea vine de la framework-ul Rails, care a creat o comunitate efervescentă. Rails a fost conceput și creat de David Heinemeier Hansson în vara lui 2004. Pentru mai multe informații specifice despre Ruby(1) și Rails(2) vă invit să consultați referințele de la finalul articolului.
Analizând diagrama de mai sus remarcăm câteva lucruri interesante: Ruby este mult mai puternic decât PHP și Javascript și este foarte aproape de C#.
Impresionează gradul său ridicat de viabilitate comparativ cu alte opțiuni populare folosite la momentul curent în mediul de dezvoltare.Enumerăm mai jos minicolecția de website-uri, care oferă o mărturie clară a potențialului framework-ului Rails pentru aplicații de tip web:
În continuare vom prezenta particularitățile lui Rails.
Beneficiile lui Ruby on Rails
Această mică funcționalitate face Rails nu numai unic ci și formidabil. Având la dispoziție această unealtă, un programator se poate concentra asupra codului într-o manieră pragmatică, în loc să își irosească energia și atenția asupra fișierelor de configurare. Acest aspect poate fi urmărit cel mai bine în arhitectura de tip Model-View-Controller pe care limbajul o impune. Maniera în care acesta gestionează este suficient de interesantă să stârnească zâmbete pe fața oricărui programator.
Așadar, în loc să fii nevoit să îți configurezi care Model (unitatea atomică de stocare în baza de date) merge în care tabel din baza ta de date, Rails îți oferă o regulă foarte simplă: să presupunem că ai un model numit User, în acest caz vei ști cu siguranță ce va fi asociat cu un tabel numit Users ( pluralul lui user). Mai mult, logica responsabilă pentru codul ce se va ocupa de model va fi regăsit în controller-ul numit UsersController, care va fi mapat la un set de rute predefinite de resursa numita users (endpoint-uri de tip RESTful sunt oferite - index/ show/ new/ create/ edit/ update/ delete) care vor corespunde metodelor cu aceleași nume definite în controller ca puncte de acces. Apoi, desigur, view-urile render-uite de aceste metode se vor afla în folder-ul views, în sub-folder-ul users, având fiecare .html același nume ca și endpoint-ul.
Acum, cum ar fi dacă toate astea s-ar genera cu o singură comandă?
Scaffolding-ul îți conferă această posibilitate, având la dispoziție o aplicație care rulează în doar câteva secunde (având deja Rails instalat). Nu știu ce părere aveți voi, dar mie mi se pare folositor și rapid! De notat este faptul că și convențiile pot fi schimbate dacă este dorită situația, însă Rails întărește ideea de a te folosi de ele așa cum sunt date.
Încă un motiv pentru care vei iubi această practică este ușurința pe care o dă utilizatorilor de a se plimba prin orice proiect. Dacă ai învățat o dată aceste convenții și trebuie să te muți la un alt proiect Rails, există șanse extrem de mari ca să înțelegi logica din spatele acțiunilor doar dintr-un UML. Ba mai mult, vei putea manipula codul fără a mai fi nevoit să primești informații de la developer-ii anteriori. Acum vă întreb din nou, așa-i că e grozav? Și mai există și alte puncte forte!
Din acest punct de vedere, se poate spune că ești de-a dreptul cu picioarele înfipte în pământ. Există o bibliotecă uriașă de tip open source disponibilă pentru Ruby on Rails. În plus, majoritatea surselor sunt foarte bine documentate(4) și exemplificată(5) peste tot.
Oricând ai nevoie de ceva, există un gem (voi adresa acest concept în rândurile ce urmează) special construit, care îți va rezolva problema în 'stilul Rails'.
Cât despre gem-uri - le poți considera librăriile sau plug-in-urile din alte limbaje. Pentru a folosi gem-urile prin aplicație, există un fișier numit gemfile care îți permite să adaugi sau să ștergi după bunul plac orice bibliotecă prin url. Pentru a te asigura că nu îți poluezi mașina sau alte proiecte cu diferite gem-uri fiecare având diferite versiuni, există mai multe abordări. Eu sugerez cu încredere folosirea rvm-ului(6) ( ruby-versioning-manager ).
Iar ultimul bonus al comunității este faptul că este proactivă. În general, comunitățile lâncezesc, îmbătrânesc sau chiar se împiedică în proiectele de tip boom. Dar nu este cazul și aici. Ba chiar mai mult, se poate spune că este mai efervescentă ca atunci când totul a început!
Iar ca ultim aspect - dacă vreodată ai nevoie să rezolvi o anumită problemă și nu știi cum, railscasts(7). te va indruma/ inspira de cele mai multe ori în a găsi o rezolvare.
Nu, nu e un slogan publicitar! Țelul lui Ruby, după cum subliniază creatorul ei, a fost cel de a face programatorii fericiți. Acesta este de fapt aspectul care l-a atras pe David de la început. După ce s-a îndrăgostit literar de sintaxă, el a decis că Ruby este baza pe care își va întemeia framework-ul. Și, pentru a continua tradiția, l-a optimizat chiar mai mult pentru a aduce programatorilor cât mai multă fericire și cât mai puțină bătaie de cap.Pe lângă faptul că poți scrie codul în engleză aproape pură, mai ai și beneficiul de a scăpa de cele mai plicticoase părți ale web development-ului (evitând fișierele de configurare!), toate acestea fiindu-ți accesibile în cea mai rapidă manieră. Din punctul meu de vedere, aceasta ar face și pe cel mai înrăit programator să dea din coadă.
Această filosofie este puternic impregnată în ADN-ul Rails-ului. După metodologia în care codul este împărțit în modele, controller-e și helper-e, niciodată nu vei avea nevoie să îți duplici codul. Ba mai mult, logica este deja extrasă în gem-uri de către comunitate (vedeți cum interacționează?! ) și le poți folosi doar inserându-le în gemfile-ul tău. Prin urmare, dacă ai nevoie de un panou de administrator, poți oricând să imporți iactiveadmin care este atât minimalist cât și stilat. La toate acestea se adaugă faptul că este configurabil. Dacă ai nevoie de soluții de autentificare, devise o va face pentru tine. Apoi, probabil vei avea nevoie de autorizare- ținând cont că ai user-i, vei avea tipuri de user-i, care se autentifică pentru a vedea conținut diferit)- cancan reușește asta pentru tine. Iar lista(8) continuă...
Convenția e folositoare pentru că se bazează pe fișierele de configurare și pe relațiile pe care tu le memorezi. Acesta este beneficiul numărul 1. Apoi există al doilea și anume expresivitatea lui Ruby, care reprezintă principalul motiv pentru care David a ales Ruby în favoarea oricărui alt limbaj. Dacă te întrebi cum e folositor?
Pentru început, când scrii cod te simți bine. Nu numai că nu îți setezi totul la fiecare pas prin aplicație, dar pur și simplu poți să deduci niște funcții care există deja implementate. Ca exemplu, când am început eu să învăț Rails, la un moment dat aveam nevoie să știu dacă într-o listă de string-uri include un string particular pe care l-am calculat eu. Și, desigur, există mereu cele două opțiuni: iterezi prin el, clasic și verific la fiecare pas, sau, îl cauți pe Google. Așa că, uite-mă, căutând pe Google "find string in strings array Rails" - iar acesta e primul link(9) pe care l-am accesat. Vă las pe voi să descoperiți care mi-a fost surpriza când l-am deschis.
Iar acest lucru mi s-a întâmplat de mai multe ori când codam. Ba chiar am ajuns la punctul în care ghiceam ce verb sau combinație de verb și adverb îmi va da răspunsul corect, iar în caz că nu mergea, căutam pe Google (sort_by, .present? .empty?).
Și, poate că încă nu sunteți impresionați. Așa că, am să vă mai prezint un mic secret. Rails seamănă atât de mult cu engleza deoarece folosește un DSL(10) intern. Cum e asta bun pentru noi? Ei bine, permiteți-mi să scriu un code snippet pentru voi, apoi vă rog să-l citiți:
class User < ActiveRecord::Base
devise :confirmable, :registerable
validates_presence_of :name, :day_of_birth, :email
before_save :compute_age
has_many :books
has_attached_file :avatar, :styles => {:small => "240x240>"}
Dacă nu sunteți convinși, încercăm altfel. Arată această bucățică unuia din prietenii tăi și întreabă-l care e cel mai ușor de citit:
Ruby
return Fridge.get_beer_if_availablePHP
$result = $fridge->getBeerIfAvailable($beers);Java
return Fridge.getBeerIfAvailable()Principalul avantaj este că vă puteți exprima cu ușurință gândurile folosind limba engleză, fără a fi nevoie de un nivel de abstractizare suplimentar. În plus, codul este simplu astfel încât îl puteți citi ca limbă engleză.
Așadar, se pare că am ajuns la finalul articolului. Sunt sigur că nu v-am convins să îl întrebați pe șeful vostru dacă nu ar vrea să schimbe profilul firmei spre Rails… Dar….de acum înainte, consider că nu mai există niciun motiv să aveți itemi care stau pe lista de idei bune de implementat. Aveți unealta pentru a face schimbări rapide unei aplicații și să vă alimentați curiozitatea în a vedea cum ar putea funcționa. Așa că, de ce să nu o faceți? Ca încheiere, vreau să vă sublinez că RoR vă va face atât fericiți cât și proprietari ai propriului vostru produs.
de Monica Rațiu
