ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 126
Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 56
Abonament PDF

Rapid prototyping cu RubyOnRails

Sagar Ranglani
Software Architect @ Crossover



PROGRAMARE


Î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.

Ce este Rapid Prototyping? Și de ce este el important?

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:

  1. 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.

  2. 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.

  3. 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.

  4. Aspectul execuției: deși în anumite cazuri, machetele și cadrele cu grad mai redus de fidelitate, ar putea fi suficiente pentru a avea un ciclu de feedback mai rapid și mai strâns, un prototip funcțional ne poate duce mai departe în termeni de feedback calitativ ca realitate și valoare. Să ne imaginăm că încercăm să construim un prototip care probabil evoluează într-o aplicație pregătită pentru producție fără prea multe modificări. Sună bine, nu-i așa? Aceasta dorim să evidențiem în acest articol.

De ce este Ruby on Rails suficient de apt pentru prototipare?

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ă.

Paradigma Rails

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.

Convention over configuration

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.

Șablonul MVC (Model-View-Controller)

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.

Resourceful Routing

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"
end

Aici 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.

Implementarea proiectului

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ă.

Extragerea Modelelor de Business și a relațiilor dintre ele

Î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:

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:

Generarea unei aplicații Rails

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.

Scaffolding

Î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:references

Definirea bazei de date

La î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=development

Este 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!

Includem puțin styling

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 Comments

Testarea aplicației

După 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.

Concluzii

Î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.

Bibliografie

În aceeaşi ediţie ... (56)

▼ TOATE ARTICOLELE ▼

VIDEO: NUMĂRULUI 126

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Telenav
  • .msg systems
  • Colors in projects