În ritmul schimbărilor de azi este aproape imposibil să știi exact ce-și doresc consumatorii de la un produs. Zilnic vedem cum apar firme noi cu produse și servicii noi, dar v-ați întrebat vreodată de ce majoritatea nu reușesc? Cel mai frecvent motiv pentru eșec este că firmele construiesc produse pentru care nu există cerere. Să construiești un produs care să fie exact pe gustul consumatorilor este dificil și din acest motiv doar jumătate dintre ele supraviețuiesc pentru mai mult de cinci ani, potrivit statisticilor pe 2016. Această ambiguitate a nevoilor consumatorilor poate fi rezolvată doar prin identificarea sistematică și timpurie a problemelor din Ciclul de Viață al Dezvoltării Produsului. Aceasta înseamnă că avem nevoie de implicarea mult mai consistentă a consumatorilor cu mult înainte să le oferim orice produs sau serviciu. Rapid Prototyping este una dintre metodele eficiente pentru a realiza aceasta. Construim prototipuri ale produselor și le punem la dispoziția potențialilor consumatori pentru a le estima interesul în legătură cu viziunea noastră, lucru care ne-ar putea ajuta să construim produse cu o rată mai mare de succes.
Prototiparea este o Metodă de Dezvoltare a Sistemelor, prin care o aproximare timpurie a produsului final, numită "Prototip", este construită și testată cu mult înaintea produsului final. Procesul este reiterat de mai multe ori pentru a rafina prototipul în baza feedbackului primit la versiunile anterioare ale prototipului.
În lumea startupurilor, există o noțiune destul de cunoscută prin acronimul MVP, respectiv Minimum Viable Product. Haideți să aruncăm o privire la definiția MVP dată de Eric Reis în cartea sa "Lean Startup" care spune: "produsul minim viabil este acea versiune a unui produs nou care permite unei echipe să colecteze cel mai mare volum de experință cu cel mai mic efort". Deși, în adevăratul sens, un MVP este destul de diferit de un Prototip. MVP este ceva care probabil va fi inclus în produsul final, pe de cealaltă parte, nu există o astfel de legătură în cazul Prototipului. În acest articol vom folosi MVP și Prototip interschimbabil, de dragul simplificării.
Există mai multe aspecte la care să ne gândim în timp ce construim un prototip, iar printre cele mai importante sunt următoarele:
Aspectul financiar: costul construirii unui prototip ar trebui să fie cât de mic se poate, fără a compromite calitatea cerută pentru pentru un feedback bun de către stakeholderi.
Aspectul vitezei: pentru a reduce timpul de lansare, este extrem de important să prototipezi rapid și să livrezi rapid către stakeholderi. Așa cum, pe bună dreptate, a spus Reid Hoffman, fondatorul Linkedin, "dacă nu ți-e rușine de prima versiune lansată a produsului, ai lansat prea târziu". Viteza chiar contează și feedbackul timpuriu este cheia atragerii consumatorilor plătitori.
Aspectul agilității: procesul de prototipare ar trebui să fie agil și să fie capabil să incorporeze mai multe iterații pentru a rafina prototipul. Aceasta este una dintre cheile de răspuns la provocările lumii incerte de azi.
Dacă privești la ecosistemele startupurilor de tehnologie din jur, vei observa că multe startupuri folosesc Ruby on Rails - te-ai întrebat vreodată de ce? Motivul simplu este că face dezvoltarea aplicațiilor web simplă, rapidă și super productivă. Startupurile trebuie să livreze Prototipul în mâinile consumatorilor pentru a obține feedback rapid și să itereze pentru a îmbunătăți. Avem nevoie de o suită de tehnologii care să ne ajute să construim rapid și eficient aplicații funcționale, iar Ruby on Rails este mediu complet care se potrivește acestei ecuații atât de bine, încât nu-ți poți permite să-l ignori.
Ruby este un limbaj open-source tipizat de programare puternic și dinamic, care are un nivel destul de ridicat de lizibilitate și eleganță. Ruby are o curbă de învățare decentă, plată și ușoară la pornire. De asemenea, vine la pachet cu proprietăți puternice cum ar fi Meta Programarea. Limbajul are o comunitate de contributorii open-source vibrantă, activă și în creștere.
Rails, un framework web construit în Ruby, este un framework complet de aplicații web extrem de productiv. Conține aproape tot ce este necesar pentru dezvoltarea unei aplicații web pornind de la baza de date gata pregătită. Aceste proprietăți includ ORM (Object Relational Mapping), Database Schema Management, dezvoltare de servicii API RESTful, scaffolding, environment management, background processing, , asset pipeline, teste și comunicare în timp real folosind web sockets - care fost recent introdus o dată cu Rails 5.
De vreme ce proprietățile de bază ale aplicațiilor CRUD pot fi generate complet fără a scrie prea mult cod, Rails este foarte apt pentru Rapid Prototyping și dezvoltarea MVP. Mai mult, există tone de resurse open-source disponibile pentru cazurile mai puțin convenționale pe care le-am putea avea de construit. De asemenea, Rails este prietenos și cu metodologiile agile de dezvoltare software. Deloc lipsit de importanță este faptul că multe companii de succes (incluzând AirBnb, BaseCamp, Github, CrunchBase, Bloomberg, Scribd și Fiverr) folosesc Ruby on Rails pentru produsele proprii - deci poate fi considerată o opțiune credibilă.
Acum, de vreme ce v-am oferit un sumar despre dezvoltarea prototipurilor cu ajutorul RoR, trebuie să fie foarte tentant să trecem la dezvoltare. Dar înainte să ne murdărim mâinile, haideți să ne uităm la pilonii pe care se sprijină Ruby on Rails.
Rails urmărește o paradigmă de programare numită "convention over configuration", care încearcă să reducă volumul deciziilor pe care trebuie să le ia programatorii, fără a-și pierde flexibilitatea în dezvoltarea software. De exemplu, dacă creăm un model Rails cu numele "Blog", tabela corespondentă din baza de date în care se vor salva blogurile va fi denumită automat "blogs" fără a specifica configurații speciale. Există două mari avantaje pentru această abordare: în primul rând detașează programatorul de uzura decizională - și prin aceasta sporește viteza de dezvoltare. În al doilea rând, codul scris de un programator de Rails devine inteligibil pentru orice alt programator de Rails.
Acesta este un șablon arhitectural extrem de popular, în special pentru aplicațiile web. Așa cum se poate vedea pe diagramă, aplicația noastră va fi structurată sub formă de Modele, Controllere și View-uri, unde fiecare dintre acestea are propriile roluri și responsabilități. Modelele se ocupă doar de date, View-urile se ocupă doar de layerul de prezentare, iar Controllerele construiesc răspunsuri folosind Modele și le randează în View-uri.
Arhitecturile software pot uneori să devină destul de dificil de înțeles și este foarte important să existe o corelație sănătoasă între arhitectura unui sistem software și artefactele de business. Artefactele de business pot fi definite ca sisteme și subsisteme formate din mai multe resurse. Aceste resurse pot fi declarate în Rails în mod direct într-un singur fișier, care poate corela diverse requesturi HTTP cu acțiuni din aceste controllere. Aceasta ne permite să menținem un sistem simplu de routing, care devine explicit pe măsură ce routele reprezintă direct artefactele de business.
Aceasta ne permite de asemenea să creăm servicii web RESTful instant. REST se traduce ca Representational State Transfer. În arhitecturile REST, totul este tratat ca o resursă și serverul REST oferă acces la aceste resurse care sunt cerute de un client REST. Să urmărim un exemplu simplu de resursă "blogs" cu sub-resursa "comments":
resources "blogs" do
resources "comments"
endAici avem două tipuri de resurse "blogs" și "comments" și este foarte evident din cod că resursa "comments" aparține resursei "blogs". Scriind aceste trei linii de cod în routerul Rails, va genera de fapt aproximativ 14 rute care vor facilita toate tipurile de operații CRUD în "blogs" și "comments". Următoarele tabele arată șapte acțiuni în controllerul resursei "blog", care va fi generată prin specificarea resursei în fișierul de rute.
Să discutăm acum exact despre cum puteți folosi Ruby on Rails pentru prototiparea rapidă a unei simple aplicații web în mai puțin de jumătate de oră.
În primul rând, vom analiza scenariul de business și vom încerca să extragem entitățile modelului care vor reprezenta entitățile de business. Să luăm exemplul simplu al unui Sistem de Management al Reclamațiilor Clienților. O privire rapidă asupra sistemului ne poate sugera funcționalitățile de bază ale sistemului. O parte din caracteristicile cheie ale proiectului pot include:
Clienții pot crea reclamații;
Agenții de la suport pot schimba statusul reclamațiilor;
Clienții pot adăuga comentarii la reclamații;
Modelele resursă pe care le putem extrage vor fi "Complaint", "Comment", "User" și "Role" - deoarece vom avea două tipuri de utilizatori - clienții si agenții de la suport. Avem aici o diagramă ER simplă care să ne arate relațiile dintre aceste modele:
Este pe cât de simplu sună: vom genera structura aplicației folosind rails new:$ rails new nitpick-box
Rails va genera întreaga structură a aplicației inclusiv folderul "app" care conține tot codul specific aplicației (modele, controllere, assets, etc.), un folder Config pentru configurări, un folder DB pentru migrări și un folder Test pentru testele unitare si de integrare.
În cazul unei aplicații web convenționale, se obișnuiește să avem mai multe resurse cu operații CRUD, care devine redundant în a facilita definirea API-urilor CRUD. Din fericire, Rails oferă la pachet tooluri de command line pentru generarea modelelor, controllerelor, viewurilor, asseturilor, migrărilor de baze de date, dar și teste pentru resursele specificate, iar acest proces poartă numele de "scaffolding".
$ rails generate scaffold Role name:string
$ rails generate scaffold User name:string email:string role:references
$ rails generate scaffold Compliaint title:string description:string status:string user:references
$ rails generate scaffold Comment body:string user:references complaint:referencesLa început, cele mai multe proiecte comportă incertitudini imense. De obicei, nu suntem siguri ce funcționalități vom dezvolta în viitor și nu putem prezice prea bine cum ar trebui structurată schema bazei de date. Una dintre abordările potrivite pentru a rezolva această problemă este să folosim baze de date No-SQL nestructurate (ex: MongoDB, Cassandra). Aceste baze de date nu au prea multă modelare sau design redundant al structurii. Iar aceasta bagatelizează prototiparea aplicațiilor din perspectiva schemei de baze de date. De notat aici că bazele de date No-SQL nu au relații și asistență la tranzacții și deci, nu sunt potrivite pentru orice caz. Această decizie depinde în principal de cerințele punctuale de business. De dragul simplificării vom folosi aici baza de date implicită, respectiv SQLite.
Rails vine cu un ORM integrat, numit ActiveRecord și de obicei nu suntem nevoiți să lucrăm direct cu scripturi de interogare a bazei de date. Migrările ActiveRecord care sunt parte din ActiveRecord, ne ajută să creștem în timp schema bazei de date într-o formă consistentă. Putem iniția schema bazei de date folosind următoarea comandă, care citește migrările și le aplică pe baza de date:
$ rake db:migrate RAILS_ENV=developmentEste de asemenea interesant de notat că Rails este agnostic din punct de vedere al bazei de date. Aceasta înseamnă, dacă dorim să schimbăm DBMS-ul nostru în viitor, nu vom depinde de rescrierea codului. De exemplu, cu ActiveRecord, dacă înlocuim DBMS al unei aplicații din MySQL în PostGreSQL, nu va trebui să facem nicio schimbare. Atât este de puternic!
Pentru ca aplicația să aibă un minim de styling, vom folosi Bootstrap, un framework popular de CSS si JS creat de Twitter. Pentru a-l adăuga în aplicație, vom adăuga pachetul GEM "twitter-bootstrap-rails" în fișierul Gemfile și apoi executăm "bundle install" în linia de comandă. Următoarele comenzi vor include fișierele bootstrap js și css în proiectul nostru și vor genera layoutul aplicației noastre.
$ rails generate bootstrap:install static
$ rails generate bootstrap:layout application fluid
$ rails generate bootstrap:themed Roles
$ rails generate bootstrap:themed Users
$ rails generate bootstrap:themed Complaints
$ rails generate bootstrap:themed CommentsDupă folosirea comenzilor de mai sus, aplicația noastră va fi deja funcțională. Rulăm serverul implicit care vine la pachet cu Rails, folosind comanda "rails server" și navigăm în browser spre http://localhost:3000. Tocmai am creat o aplicație complet funcțională cu toate operațiile CRUD disponibile pentru toate resursele dorite: Complaints, Comments, Users și Roles.
Într-un cuvânt, înainte de a construi un produs puternic cu tone de funcționalități (și cu eforturi financiare uriașe), este important să construim un prototip sau un MVP pentru a testa reacția pieței, pentru că nimeni nu ar construi un produs care nu este dorit de nimeni.
Construirea prototipurilor implică mai multe provocări, cum ar fi proiecții de cost, viteză, agilitate, cicluri de feedback mai scurte, etc. Această activitate este mai degrabă artă decât o știință exactă.
Ruby este nativ orientat spre simplitate și productivitate. Frameworkul Rails instalat peste el, pur și simplu impulsionează productivitatea din punctul de vedere al dezvoltării unei aplicații. Deci, pentru prototiparea rapidă a aplicațiilor web, Ruby on Rails poate fi denumită pur și simplu o soluție de facto.
Ries, Eric, "The Lean Startup", Crown Publishing Group, New York, 2011;
Hoffman, Reid; Casnocha, Ben; "The Startup of You", Crown Publishing Group, New York, 2012;
de Ovidiu Mățan
de Ovidiu Mățan
de Laura Sima
