Aplicatie Pentru Strangerea Fondurilor Necesare Unui Proiect, Prin Intermediul Multifinantarii

PROIECT DE DIPLOMĂ

Aplicație pentru strângerea fondurilor necesare unui proiect, prin intermediul multifinanțării

Cuprins

1 Introducere și lucrări conexe

2 Tehnologiile folosite

2.1 Baza de date

2.2 Aplicatie

2.3 Plugin-uri si framework-uri

3 Arhitectura soluției

3.1 Caracteristici generale

3.2 Tipuri de arhitecturi

3.3 Arhitectura curenta

3.4 Arhitectura bazei de date

4 Implementarea soluției

4.1 Caracteristici generale

4.2 Securitatea sistemului

4.3 Regionalizarea

4.4 Auditarea si salvarea erorilor

5 Dezvoltări ulterioare

5.1 Dezvoltări ulterioare pentru baza de date

5.2 Dezvoltări ulterioare pentru aplicație

6 Concluzii

Bibliografie

Anexe și diagrame UML

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Martin Fowler

1 Introducere și lucrări conexe

În primul rând, deoarece proiectul reprezintă o platformă destinată multifinanțării, o să definesc scopul acestei aplicații, precum și încadrarea sa pe piața dezvoltărilor de software românești.

Termenul de multifinanțare provine de la denumirea în engleză “crowdfunding”, un cuvânt extrem de cunoscut pe piața străină. El reprezintă, de fapt, transpunerea unei situații întâlnite în viața reală, pe internet și anume, inițiativa unei persoane sau a unui grup de persoane de a realiza o idee sau un proiect cu ajutorul unor finanțări din partea unui grup de investitori. În cazul unei platforme online, acest grup de investitori este alcătuit din toate persoanele care doresc să investească sau sa doneze o anumită sumă de bani, într-un proiect, prezentat pe platforma respectivă. Inițiatorul proiectului poate fi o singură persoană, un grup de persoane, o organizație nonprofit, o asociație nonguvernamentală, caritabilă sau politică, dar și o companie deja existentă pe piață, ce are nevoie de finanțare.

De obicei, multifinanțarea este o metodă utilizată de companiile de curând înființate și poate reprezenta o modalitate prin care îți poți dezvolta capacitățile manageriale. Totodată, acest concept te poate ajuta fie la dezvoltarea unui nou produs sau serviciu, fie la extinderea bazei de clienți, însă, reclama fără a avea un scop în privința dezvoltării materiale, este descurajată în platformele de “crowdfunding”.

S-a demonstrat faptul că, o idee este mult mai bine finanțată, daca are o poveste bună în spate. Acest lucru determină o strategie extraordinară de marketing, imbatabilă în procesul de câștigare a încrederii asupra unui proiect. Nimeni nu poate finanța, fără a acorda încredere inițiatorului sau ideii. De asemenea, e bine ca inițiatorul să păstreze un ton personal, astfel încât celelalte persoane să se simtă apropiate de respectivul.

Întrebările la care ar trebui să răspundă o persoană pentru descrierea principală a proiectului, ar fi: Ce obstacole ai întâlnit în dezvoltarea ideii și ce obstacole crezi că vei întâlni după ce ideea este finanțată ? Proiectul a fost determinat de un eveniment major din viața reală ? De ce sumă de bani ai nevoie pentru a realiza ceea ce ți-ai propus și până când ai nevoie de suma respectivă ? Câte persoane sunt implicate în proiect ? Ce vei oferi finanțatorilor ?

În privința recompenselor oferite donatorilor, acestea trebuie alese cu mare grijă, și de obicei, ca și fondator, este bine să te pui în situația clienților înainte de a face o alegere finală. Este bine să întrebi persoanele apropiate, familia și susținătorii ce anume și-ar dori. O lecție de bază a economiei ne spune că stocurile limitate generează o cerere și mai mare. Astfel, se poate crea o cerere uriașă pentru serviciul pe care îl oferi prin limitarea ofertei ( limitarea numărului de recompense oferite pentru o anumită sumă de bani donată ). Oamenii vor finanța mai generos ideea, în scopul dobândirii recompenselor, dacă acestea sunt alese corespunzător.

În al 2-lea rând, o platformă de multifinanțare devine o comunitate online în adevăratul sens al cuvântului, atunci când persoanele ce introduc proiecte în aplicație, construiesc odată cu ideea oferită și credibilitate si legitimitate. Cu alte cuvinte, finanțatorii vor dovezi pentru faptul că proiectul, pe care dorești să îl realizezi este legitim, astfel încât investiția să merite o șansă. Arată-le în ce anume vor investi, cum funcționează, încarcă cu fotografii, videoclipuri și chiar un prototip. Ideea principală pe care, oricine trebuie să o aibă în minte, este că nu se vor întâlni, poate niciodată, cu finanțatorii în viața reală, astfel că, aceștia din urmă trebuie să fie atrași de idee încă de la primele rânduri.

O comunitate de care vorbeam mai sus s-a dezvoltat în jurul platformei de multifinanțare, numita Kickstarter, ce activează în acest domeniu din anul 2009. În momentul de față, platforma a fost utilizată de peste 6.3 milioane de oameni, aceștia donând 1 miliard de dolari către 62 000 de proiecte.

Observând proiectele propuse pe Kickstarter, am fost motivat să realizez și eu același lucru pentru România, deoarece, Kickstarter nu este disponibil și în țara noastră. Deși, conceptul de multifinanțare nu este prea răspândit la noi și poate, la prima vedere, nu o să aibă succes, acest lucru nu m-a oprit să încep realizarea proiectului. Știu foarte bine ca, după prezentarea acestuia cu scopul absolvirii facultății voi mai avea mult de muncă, înainte de a fi un produs utilizat de sute, mii sau poate milioane de oameni. Consider ca, românii pot fi reticenți în privința acestui concept, si anume, multifinanțarea, datorită lipsei de încredere pe care o acordă persoanei inițiatoare, dar și datorită invidiei sau egoismului.

Deoarece, în ziua de azi, mulți folosesc tableta sau telefonul ca înlocuitor al unui calculator sau al unui laptop, am realizat aplicația astfel încât să fie disponibilă ( fără pierderea detaliilor ) și pe rezoluții mai mici. Astfel, elementele din fiecare pagină se vor re-organiza în funcție de dispozitivul utilizat pentru vizualizarea platformei. Acest lucru nu este disponibil în momentul de față pe platforma Kickstarter, astfel că, folosirea unui smartphone pentru utilizarea aplicației, este destul de greoaie. Acest lucru ar fi un plus pe lista lucrurilor suplimentare față de o altă platformă de multifinanțare, însă ar fi absurd să spun că, datorită acestui aspect, aplicația mea este mai bună decât Kickstarter, ce are peste 5 ani de la lansare, timp în care a fost perfecționată și îmbunătățită. Despre aceasta tehnologie, precum si de avantajele sau dezavantajele ei, voi vorbi mai târziu, în capitolul destinat prezentării tehnologiilor folosite.

Fig. 1 – Website adaptabil ( sursa : www.corephp.com )

În rândurile de mai sus am vorbit puțin despre ideea de multifinanțare și ce presupune ea, însă nu am spus foarte mult despre cum este implementată în aplicația mea.

Doar persoanele înregistrate pot propune proiecte spre finanțare. După înregistrare, proiectele se pot introduce foarte ușor în aplicație folosind wizard-ul de înregistrare. Pașii pe care un utilizator trebuie să îi urmeze, precum și ce trebuie să completeze sunt foarte bine descrise la fiecare pagină a wizard-ului.

Fig. 2 – Pas înregistrare proiect

Orice proiect înregistrat pe site trebuie aprobat de către un administrator. Acest lucru este posibil accesând linkul primit pe mail ( doar administratorii primesc mail-ul de aprobare al unui proiect ), prin intermediul sistemului de mail implementat de către mine în aplicație sau din panoul de administrare, pe care îl pot accesa doar persoanele cu rol de administrator.

După ce acțiunile povestite mai sus au fost realizate, proiectul poate fi vizualizat de către oricine, fără a fi nevoie de cont în aplicație și modificat ( doar anumite câmpuri ) de către inițiator. Un administrator poate oricând să facă evaluarea proiectului, iar dacă acesta nu respectă normele impuse, să fie șters sau dezactivat, lucru ce va determina ascunderea lui din interfața publică. Proiectul poate fi oricând re-aprobat, însă nu se va mări termenul disponibil finanțării, iar în cazul în care proiectul este re-activat după ce perioada de finanțare aferentă lui s-a terminat, atunci proiectul va fi încadrat în categoria nefinanțate și nu va mai fi disponibil în interfața publică.

Finanțatorii pot dona bani, fără a primi nimic în schimb, însă, majoritatea vor dori anumite recompense pe care le oferă inițiatorul. Schema generală a acestui principiu este evidențiată în ilustrația amuzantă, de mai jos.

Fig. 3 – Prezentare proces de multifinanțare ( sursa : www.projecteve.com )

Ca și model principal de dezvoltare am ales, așa cum am menționat și în rândurile de mai sus, site-ul Kickstarter, fiind pe locul 2 în topul internațional. Faptul că nu dă posibilitatea adăugării unui proiect pentru România reprezintă un dezavantaj – pentru noi. Am aflat de Kickstarter de la un prieten, pe la începutul anului 4 de studiu. La momentul respectiv credeam că în România nu există o platformă de multifinanțare implementată, așa că m-am gândit să dezvolt eu această idee. Pe parcurs, tot căutând informații, am descoperit și câteva site-uri românești, însă care nu erau utilizate foarte mult la momentul respectiv sau chiar deloc. De exemplu, pe site-ul crestemidei.ro ultimul proiect finanțat a fost în anul 2013.

În străinătate, conceptul de cowdfunding are mare succes. “La sfarsitul lunii octombrie, Kickstarter a anuntat ca a atins o performanta remarcabila in evolutia companiei, finantand nu mai putin de 50.000 de proiecte, cu angajamente ale peste 5 milioane de sustinatori individuali. De la fondarea companiei, in 2009, si pana astăzi, Kickstarter a ajutat si finanțat proiecte in valoare de aproape 1 miliard de dolari, obținuți cu sprijinul colectivității, prin donații.” [ sursa : www.imparte.ro ].

Alte platform de crowdfunding, aflate în topul primelor 10 clasate sunt : gofundme – peste 320 milioane de dolari donați, indiegogo, youcaring, causes, giveforward, crowdrise, fundly, firstgiving și fundrazr.

Un alt site, puțin diferit este cyberbeg.com . Oricine, în schimbul a unei mici taxe de 15$ poate posta orice dorește cu scopul de a primi donații. Majoritatea postărilor sunt din partea unor fundații de caritate sau din partea unor oameni fără loc de muncă ce au nevoie de bani. Prin această aplicației s-au donat aproximativ 70 000 de dolari.

2 Tehnologiile folosite

Vreau să menționez că am ales ca și tehnologii de dezvoltare, unele moderne, utilizate de marile companii pentru realizarea unor astfel de aplicații. Acestea au fost utilizate sub licență plătită, oferită de universitatea “Politehnica” București, facultatea “Automatica si Calculatoare”.

Așa cum se poate observa și în cuprins, prezentarea tehnologiilor va fi împărțită în funcție de rolul lor din aplicație.

2. 1 Baza de date

Pentru baza de date am utilizat , ce reprezintă un sistem de gestiune pentru bazele de date relaționale ( RDBMS ), produs, așa cum reiese și din numele său, de către Microsoft.

Datele reținute în Sql Server sunt fapte culese din lumea reală. Ele sunt prealuate din măsurători și observații și constituie orice mesaj primit de un receptor sub o anumită formă. Ele nu au nici un fel de semnificație. Mai mult decât atât, nefiind altceva decât o înșiruire de litere și de cifre, ele pot primi diverse interpretări, cele mai multe dintre ele fiind, de obicei, greșite. Poate fi un lucru bun în cazul unui atacator, însă un lucru rău pentru un administrator.

Scopul unui program precum Sql Server este acela de a înmagazina datele în așa fel încât să se poată obține informația dorită în orice moment.

Pentru interogarea datelor existente în baza de date, se folosește un limbaj denumit T-SQL (Transact SQL ), care este transmis si celorlalte tehnologii utilizate în aplicație, precum MVC sau Entity Framework. Un plus important al limbajului T-SQL este acela că toate interogările se pot realiza și dintre ele fiind, de obicei, greșite. Poate fi un lucru bun în cazul unui atacator, însă un lucru rău pentru un administrator.

Scopul unui program precum Sql Server este acela de a înmagazina datele în așa fel încât să se poată obține informația dorită în orice moment.

Pentru interogarea datelor existente în baza de date, se folosește un limbaj denumit T-SQL (Transact SQL ), care este transmis si celorlalte tehnologii utilizate în aplicație, precum MVC sau Entity Framework. Un plus important al limbajului T-SQL este acela că toate interogările se pot realiza și într-o tranzacție, lucru foarte util în cazul operațiunilor importante înșiruite. Tranzacțiile presupun executarea fie întregului bloc de cod asociat, fie deloc. Astfel, în cazul unei operațiuni de transfer bancar, tranzacțiile sunt extrem de importante. Să luam următorul caz : avem o bază de date realizată în Sql Server și un utilizator dorește să transfere bani din contul său altui utilizator; procesul presupune retragerea unei sume din contul curent și depunerea unei sume în celălalt cont; daca procesul nu este încadrat într-o tranzacție ( să se execute complet sau deloc ) și apar erori la jumătatea procesului, atunci contul personal va avea un sold disponibil mai mic, fără ca persoana de la “celălalt capăt al firului” să primească banii.

Orice tranzacție sql este supusă unor 4 condiții : atomicitate, consistență, izolare și durabilitate, iar dacă aceste principii nu sunt respectate, atunci tranzacția nu este una validă.

Odată creată, o bază de date în sql are extensia .sdf și scriptul necesar creării sale poate fi salvat pe disc. Acest luru este util atunci când se dorește păstrarea configurațiilor curente sau pentru cazurile când baza de date trebuie mutată pe alt server. Bineînțeles, executarea scriptului respectiv nu presupune și păstrarea datelor din bază, ci doar a structurii sale și a tabelelor, însă există și mecanismul de backup ce permite salvarea datelor existente în tabelele bazei de date.

Sql server oferă și posibilitatea creării de legături între tabele, pentru eliminarea redundanței și păstrarea integrității referențiale a datelor. Astfel, anumite date pot fi accesate prin relații și nu prin duplicare

În concluzie, un sistem de gestiune a bazelor de date, precum Sql, are anumite avantaje față de sistemele clasice, bazate pe reținearea datelor în fișiere : controlul redundanței datelor, coerența datelor, partajarea datelor – datele pot fi adăugate de mai mulți utilizatori, în același timp, integritatea datelor, securitate bună – se creează utilizatori, cărora li se dau anumite drepturi, creșterea accesibilității datelor și a capacității de răspuns.

Fig. 4 – Statistici utilizare Sql Server ( sursa : www.insideris.com )

2.2 Aplicația

Aplicația a fost scrisă folosind mediul de programare C#, iar ca IDE ( mediu integrat de dezvoltare ) am folosit Visual Studio 2012 Ultimate.

reprezintă o colecție bogată de obiecte, ce permit dezvoltarea aplicațiilor consolă, dar și a aplicațiilor cu interfață grafică, precum și a aplicațiilor de tip serviciu web. În Visual Studio sunt înglobate mai multe tipuri de limbaje de programare – C++, C#, F#, J#, WCF, WPF ș.a.

C#, ca și alte limbaje conținute de Visual Studio, beneficiază de tehnologia .Net Framework ce simplifică dezvoltarea aplicațiilor web și a serviciilor web. .Net este format dintr-un set de librării și permite interoperabilitatea limbajului (de exemplu, un program C# poate apela o librărie C++ ). Acest lucru este posibil datorită existenței unui mecanism numit CLR – common language runtime, de care voi povesti în rândurile de mai jos.

CLR-ul reprezintă un interpretor, un mediu de execuție pentru .Net framework. Toate programele realizate cu tehnologia .net sunt executate sub supervizarea CLR-ului, ce prespune managementul memoriei, securitatea execuției și manipularea excepțiilor. Indiferent de limbajul folosit, codul este transformat într-un limbaj intermediar (MSIL – microsoft intermediat language ) și apoi este transformat în limbaj mașină cu ajutorul clr-ului. Astfel, el poate fi considerat un strat între aplicația scrisă în .net si windows, însă el nu va cunoaște limbajul în care a fost scrisă aplicația inițial, deoarece interpretează doar limbajul intermediar. Transformarea codului în IL intră în atribuțiile compilatorului limbajului în care a fost scris programul.

.Net Framework permite interoperabilitatea datelor, așa cum am amintit și mai sus. Un exemplu concret ar fi reprezentarea tipurilor de date. De exemplu, un integer este reprezentat în C# ca int, in Visual Basic ca integer iar in C++ ca int. Toate acestea fac parte din System.Int32, bibliotecă existentă în framework-ul .Net.

Visual Studio a fost lansat prima dată în anul 1995, iar biblioteca .Net a fost introdusă abia în anul 2002, odată cu lansarea Visual Studio .Net 2002

Proiectul de licență a fost pus pe TFS ( Team foundation server ), o componentă înclusă în Visual Studio, ce îți permite reținerea surselor pe un server microsoft. Orice modificare adusă aplicației permite “urcarea” ei pe acest server, iar modificările pot fi vizualizate de alți utilizatori. Astfel se creează și un log al modificărilor și al persoanelor participante la dezvoltarea proiectului. Serverul pe care este urcat este protejat prin username și parolă și poate fi accesat doar de către echipa de dezvoltare.

2.3 Plugin-uri si framework-uri

Un prim framework folosit este . Acesta reprezintă, de fapt, un șablon, un design al codului, folosit în cadrul dezvoltării software. Este foarte renumit, deoarece separă partea logică a codului de interfață. Bineînțeles, pentru multe persoane această separarea nu a fost îndeajuns și s-au dezvoltat diferite tehnici de izolare a codului după sau lansarea sa. În orice caz, utilizând doar separarea impusă de șablonul MVC, aplicațiile scrise sunt ușor de modificat, întrucât fiecare bloc de cod, responsabil cu o parte specifică se gasește într-un loc bine stabilit. De exemplu, interfața cu utilizatorul ( paginile HTML ) se regăsesc într-un folder numit “Views”. Clasele ce fac legătura între interfață și logica aplicației se găsesc într-un folder numit “Controllers”, iar clasele necesare interfețelor – cele care rețin datele care se trimit între controller si view-uri, se regăsesc, de obicei, într-un folder numit “Models”.

În rândurile de mai sus am amintit de 3 termeni specifici : models, views și controllers. Daca se extrage inițiala fiecărui cuvânt obținem MVC, ceea ce dovedește din nou izolarea diferitelor aspecte ale unei aplicații. Această separare s-a introdus ca fiind o necesitate pentru cei care vor întreține sau modifica aplicația, acest proces efectuându-se mult mai ușor.

Un programator bun este cel care reușește să scrie codul astfel încât și cei care vor urma la dezvoltarea aplicațiilor să îl înțeleagă și sa-l poată modifica ușor.

Fig. 5 – Arhitectura generală MVC ( sursa : en.wikipedia.org )

Un element important de care dispune MVC-ul, îl reprezintă sintaxa Razor, sau cum mai este numit, motorul de vizualizare Razor. Acesta din urmă permite construirea interfețelor utilizând cod similar limbajului C#, cod ce este interpretat și duce la generarea tagurilor Html. A apărut odată cu MVC 1, când se numea Web Form, această denumire fiind valabilă până înainte de apariția versiunii 3. În plus dispune și te autocompletare inteligentă – IntelliSense.

Deși MVC a fost dezvoltat inițial pentru aplicațiile desktop, el a fost adoptat pentru aplicațiile web, iar în momentul de față nu cred că mai este utilizat în alt scop. Ultima versiune, MVC 5 aduce în plus față de a 4-a versiune ( disponibilă în Visual Studio 2012 ca și valoare predefinită ) următoarele: rutarea bazată pe atribute, ASP.NET Identity, generare de cod automat din model, filtre locale și filtre globale – pe întreaga aplicație. Șabloanele pentru proiectele mobile au fost introduse în MVC, încă de la a 4-a versiune. În anul 2015 urmează să apară a 6-a versiune ce va aduce foarte multe îmbunătățiri, precum și o integrare mai ușoară cu serverul Cloud. De asemenea, o să apară o tehnologie numită, Asp.Net vNext ce va permite dezvoltarea programelor hibride mult mai ușor.

Pe langa MVC, am utilizat , plugin ce incorporează CSS și Jquery și permite redimensionarea site-ului în funcție de rezoluția dispozitivului de pe care este vizualizat. În introducere am spus de acest plus al aplicației și acum voi prezenta cum este, de fapt, posibil. Este un plugin open-source și documentația poate fi gasită pe site-ul oficial ( getbootstrap.com ). Deoarece are deja anumite clase CSS implementate, precum si codul javascript aferent modificării poziției și dimensiunii elementelor din pagină, Boostrap ușurează munca dezvoltatorilor web și chiar dacă este destul de nou implementat, se răspândește cu pași mari.

De asemenea, fiind un plugin open-source el poate fi utilizat și în scop comercial.

Dispune de template-uri pentru diferite elemente, precum : dropdown-uri, grupuri de butoane, grupuri de dropdown-uri, input-uri, bară de navigație, paginare, alerte, progress bar-uri ș.a. În plus, aceste elemente se pot stiliza după cum dorește dezvoltatorul.

Un alt element important pe care îl oferă bootstrap îl reprezintă aranjarea și alinierea elementelor în pagină. O pagină HTML se împarte ( utilizând bootstrap ) în 12 coloane virtuale, iar containerele declarate pentru blocurile de tag-uri html pot lua valori cuprinse între 1 și 12 pentru lățime. Valorile respective sunt apoi transpuse în pixeli, conform algoritmului după care este realizat bootstrap. Totodată, aceste valori sunt proporționale cu dispozitivul de pe care este vizualizată aplicația web, lucru foarte util, având în vedere că, în ziua de azi, multe persoane folosesc smartphone-ul sau tableta pentru navigarea pe internet.

Pentru utilizarea framework-ului MVC, impreuna cu Bootstrap am folosit plugin-ul open-source, numit , la dezvoltarea căruia am participat și eu. Acesta permite generarea tutoror elementelor specifice din MVC și din html – texbox-uri, dropdown-uri, radio button-uri ș.a. – cu bootstrap. De asemenea, are implementat și generarea automată a unor grid-uri, ce reprezintă tabele cu date, dar care au și diferite funcționalități, precum : adăugare, ștergere, căutare, ordonare și acțiuni custom, a unor profile – profil de utilizator și a unor team buildere – forma ce permite construirea unor echipe în cadrul unei organizații. Aceste elemente pot fi utilizate doar dacă dezvoltatorul dorește acest lucru. Un exemplu de grid poate fi vizualizat în imaginea de mai jos.

Fig. 6 – Formular administrare de tip grid

Pentru legătura bazei de date cu aplicația am folosit Entity Framework. El permite transpunerea bazei în aplicație prin prezența unui fișier cu extensia .edmx, în care se reține schema tabelelelor și a relațiilor, precum și tipul coloanelor. De asemenea, tabelele sunt transformate în clase și în general, unui tabel îi corespunde o singură clasă. Programatorul se poate folosi de aceste clase pentru a le folosi drept Models, însă, depinde de fiecare dezvoltator cum dorește să contruiască programul. În opinia mea, folosirea acestor clase nu este optimă, fiindcă au ca proprietăți toate coloanele dintr-un anumit tabel și de obicei, într-o interfață nu avem nevoie fiecare în parte. Este mai bine dacă ne construim un model separat, care să conțină doar coloane de care avem nevoie în contextul respectiv. Un plus al programului Entity Framework îl constituie existența unor funții ce permit accesarea și modificarea datelor cu ușurință : Linq to Entities, Entity Sql. Deși au un nume total diferit, ele sunt o abstractizare a limbajului T-SQL folosit în Sql server, astfel încât să existe implementare în concordanță cu mediul de dezvoltare – C#. Aceste funcții au fost extinse mai târziu și către alte arii, cum ar fi XML, deoarece există Linq to Xml. În poza de mai jos se poate observa asemănarea dintre Linq to Sql ( în dreapta ) și T-SQL ( în stânga ).

Același lucru se poate scrie, în C# și astfel – fiind într-o formă mult mai apropiată de limbajul T-SQL, însă, majoritatea dezvoltatorilor folosesc sintaxa prezentă în imaginea anterioară:

Tehnologiile prezentate mai sus, în afară de Bootstrap fac parte din partea de backend. Pe partea de frontend tehnologiile folosite sunt ( html 5, css 3, respectiv javascript ). Pe partea de javascript am utilizat, de fapt, un plugin numit jQuery, ce face posibilă optimizarea codului, după cum și moto-ul “write less, do more”.

este o platformă de dezvoltare javascript, concepută pentru ușurarea și îmbunătățirea proceselor și evenimentelor specifice javascript. Reprezintă o bibliotecă de funcții, lansată în anul 2006 de către John Resig și a avut foarte mare succes de-a lungul timpului. De asemenea, biblioteca se poate extinde folosind diferite plugin-uri.

este un limbaj html clasic, folosit pentru a structura și pentru a prezenta un conținut pe internet, ce vine cu noi elemente. Cu alte cuvinte, reprezintă a 5-a versiune a standardului html, lansat în anul 1990. El introduce în html elemente precum : <nav> – utilizat pentru meniu, <footer> – în subsolul paginii, <audio>, <video>. Elementele <font> și <center> de la html 4 au fost scoase, deoarece există echivalentul lor în CSS.

Așa cum html 5 este o nouă versiune pentru html, așa și reprezintă o nouă versiune pentru CSS, care presupune un standard de formatare a elementelor unui document html. Astfel, el vine cu noi elemente precum : selectori, modelul box, efecte pentru text, animații, transformări 2D/3D ș.a.

3 Arhitectura soluției

3.1 Caracteristici generale

Un model de arhitectura sau un șablon de proiectare, cum mai este cunoscut, bine ales poate rezolva multe probleme. Alegerea sa este foarte importantă, deoarece, un astfel de model structurează aplicația și o face mai ușor de modificat pentru ceilalți dezvoltatori ( cel care a realizat aplicație se presupune ca deja cunoaște arhitectura, indiferent de cum a fost construită ).

Există foarte puține software-uri de dimensiune mică, majoritatea având câteva sute de linii de cod, fiind foarte complexe și de aceea, cu ajutorul unei structuri bune a soluției, un programator se poate descurca mai bine, reducând astfel timpul redundant. Modelul de arhitectură este ales, de obicei, după realizarea bazei de date și acesta prezintă comunicația și modul de interacțiune dintre clase. Cu ajutorul unei arhitecturi bune, orice programator, care nu cunoaște neapărat limbajul, iși poate da seama, după numele folderelor, fișierelor sau proiectelor aflate în soluție, unde se găsește logica aplicației, interfața, baza de date sau legaturile între interfața și entitățile bazei de date. În plus, există grupuri de clase sau de obiecte care se repetă în mai multe locuri, fapt ce dovedește necesitatea unor astfel de șabloane de proiectare. În cazul unui nou proiect, o persoană ce cunoaște diferite arhitecturi existente în vechile proiecte, le poate folosi și în noua aplicație, reducând din timpul necesar dezvoltării proiectului.

Arhitecturile pot fi general valabile ( n-tier application, sigleton ș.a. ) sau specifice unui anumit sector de lucru, de exemplu pentru sistemele distribuite , programele în timp real, probleme de concurență ș.a.

Fig. 7 – ( sursa : www.dreamstime.com )

3.2 Tipuri de arhitecturi

Există 3 mari categorii de arhitecturi: arhitectura orientata pe servicii ( SOA – service oriented arhitecture ) – foarte bună în cazul comunicației dintre mediul intern aplicației și mediul extern, aplicația împărțită în straturi ( n-tier application ) – foarte bună pentru implementarea aplicației la sfârșitul perioadei de dezvoltare și aplicația specfică unui mediu de afaceri ( DDD – domain driven design ).

De obicei, aceste arhitecturi nu se folosesc separat, ci se pot combina. De exemplu, în cazul în care se dezvoltă o aplicație ce comunică foarte mult cu mediul exterior ( prin apelul unor servicii externe oferite de marile companii – Google, Facebook ș.a. ) se poate folosi arhitectura SOA, dar aceasta din urmă poate fi combinată cu o arhitectura împărțită în straturi. Astfel, la implementarea aplicației pe mediul de lucru final, arhitectura va fi împărțită pe roluri : o parte se va ocupa de comunicație, parte care va avea implementată o arhitectura SOA, iar celelalte părți se vor ocupa de alte funcții – logică, interfață ș.a.

Aplicațiile web folosesc în majoritatea cazurilor o arhitectură împărțită pe straturi – MVC , dar se poate utiliza și SOA, folosind o comunicație între aplicație și un serviciu web, ce se va ocupa și cu logica aplicației ( salvarea entităților, ștergerea lor ș.a. )

Arhitectura n-tier se folosește pentru aplicațiile foarte mari și este asemănătoare cu arhitectura împărțită pe straturi, însă cu deosebirea că, fiecare segment din aplicație poate fi ținut pe un calculator fizic, separat. Cu alte cuvinte, arhitectura n-tier este folosită pentru aplicațiile distribuite. Fiecare segment este absolut independent de celelalte segmente, iar segmentul n cunoaște doar cum să managerieze o cerere primită de la segmentul n+1 și cum să o trimită, după prelucrare, către segmentul n-1. Un exemplu de arhitectura n-tier se poate folosi în aplicațiile bancare, unde logica aplicației trebuie ținută în spatele unui firewall, pe un calculator separat. În cazul aplicațiilor foarte complexe, logica aplicației poate fi împărțită pe mai multe calculatoare, în funcție de capacitățile hardware are dispozitivului respectiv, precum și de funcția pe care segmentul o realizeaza în cadrul aplicației.

Pentru aplicarea unei arhitecturi de tip DDD, programatorul trebuie să cunoască atât limbajul de programare în care realizează aplicația, cât și sectorul de afaceri căruia îi este destinat proiectul.

3.3 Arhitectura curentă

Ca și arhitectură principală a aplicației am ales MVC, fiind și framework-ul sub care am dezvoltat aplicația. Am combinat MVC-ul cu o arhitectură împărțită pe straturi: modele, view-uri, controller, repositories și helpere. Repositories reprinztă clase asociate fiecărui controller, care se ocupă de logică. Astfel, view-urile realizează o comunicație cu controllerele folosind modelele, fie că utilizează și anumite helpere sau nu, iar controllerele comunică cu baza de date prin intermediul repositoarelor.

De asemenea, aplicația a fost împărțită în 2 segmente principale : partea de administrare și partea publică a aplicației. Aceste părti sunt puse în arii diferite, iar fiecare arie prezintă arhitectura amintită în paragraful anterior. Astfel, aplicația are o arhitectura împărțită pe straturi, dublată, sau chiar triplată, dacă facem referire și la proiectele aflate în soluție. Cele prezentate mai sus fac parte din proiectul principal, unde este conținută și interfața aplicației, însă celelalte componente, precum entitățile bazei de date și baza de date sunt ținute în proiecte separate, așa cum se poate observa în imaginea de mai jos ( crowder.Database este proiectul asociat bazei de date, iar crowder.Entities reprezintă transpunerea tabelelor în clase C# ).

Fig. 8 – Proiectele soluției

Pe lângă cele 3 proiecte se poate observa în imagine și un folder, numit “nuget”. Acesta este folosit la implementarea și transferarea aplicației de pe serverul local, pe un alt server și face posibilă extragerea de referințe pentru plugin-urile utilizate în proiect, astfel încât acestea să nu fie ținute în soluția curentă, cu scopul optimizării dimensiunii aplicației. Acest aspect ajută la portabilitatea programului.

Deși aplicația este legată la o bază de date SQL, implementare despre care voi vorbi în subcapitolul următor, în Visual Studio am creat și un proiect de tip Database pentru a reține configurația bazei de date. În acest mod, la distrugerea sau alterarea serverului pe care este ținută baza de date ( de obicei se păstrează separat de aplicație ), configurația este încă păstrată în proiect și baza de date se poate regenera. Bineînțeles, acest beneficiu nu aduce și datele ce erau înregistrate, însă acest lucru intră în atribuțiile administratorului bazei de date, care ar trebui să păstreze fișiere de backup. Un proiect database permite compararea configurației curente din aplicație cu cea din Sql server și modificarea automată, în orice direcție.

Proiectul conține clasele asociate tabelelor bazei de date. Aceste clase sunt generate cu ajutorul tehnologiei Entity Framework. Ele sunt asemănătoare modelelor utilizate de view-uri și în unele cazuri pot fi și utilizate. Modelele se creează doar dacă dorim să extragem numai anumite coloane ( proprietăți ) și nu avem nevoie de întreaga clasă generată de entity framework. De asemenea, proiectul păstrează și o diagramă a bazei de date, ce poate fi actualizată cu ușurință atunci când se realizează modificări asupra tabelelor din Sql Server. În imaginea de mai jos, ce reprezintă o porțiune din diagramă, se poate observa că se păstrează și relațiile dintre tabele.

Fig. 9 – Schemă parțială a BD

Această diagramă poartă numele de EDM ( entity data model ), iar relațiile dintre tabele poartă numele de proprietăți de navigare. De exemplu, dacă avem un tabel numit Utilizatori și un alt tabel numit Date_personale putem naviga astfel : Utilizator.date_personale. EDM ne dă posibilitatea să lucrăm cu un model conceptual al bazei de date și nu cu schema ei și este folosit pentru orice interacțiune cu baza de date. Astfel că, atunci când am spus că repositoarele comunică cu baza de date, de fapt, interacționează cu modelul prezent în crowder.Entities și acesta, la rândul său, trimite cererea, mai departe, la baza de date.

Operațiile trimise către baza de date sunt de tip CRUD ( create, read, update și delete ).

Proiectul reprezintă “inima” aplicației. Aici se găsesc toate paginile HTML, toate plugin-urile instalate ( referința către ele ), codul ce face posibilă interacțiunea utilizatorului cu aplicația ( logica ), precum și fișierele javascript sau jquery.

Așa cum am spus mai sus, proiectul principal este împărțit în arii. Acest lucru se poate observa în poza de mai jos, unde sunt vizibile 3 din cele 4 arii, a 4-a fiind partea publică, dar care nu are nevoie de un folder separat.

Fig. 10 Ariile existente în proiect

Un proiect MVC are 3 foldere de bază : Models, Views și Controllers. Fiecare arie, la rândul său, conține aceste foldere, ceea ce presupune că și ea folosește o arhitectura MVC – împărțită în straturi, asemenea aplicației.

Fig. 11 – Arhitectura de tip MVC a unei arii

Se poate observa în poza din stânga existența folderului Repository, ce se ocupă cu logica acelei arii ( logica părții de administrare conform imaginii de mai sus ). În mod normal, în șablonul arhitectural MVC, această logică ar trebui scrisă în Models, însă pentru o mai bună structurare și în scopul separării conceptelor până la cel mai mic nivel, am mutat-o în folderele de care am amintit în rândurile de mai sus.

Pe partea de interfață, orice pagină HTML folosește un template general, numit în arhitectura MVC, Layout, ce reprezintă o pagină de tip recipient – container, fiind termenul englezesc, pentru celelalte pagini, acestea din urmă împrumutând atât elementele HTML, cât și cele CSS. Se pot crea cât de multe template-uri dorește programatorul, însă o pagină se poate folosi doar de unul. De obicei, in template se scrie codul pentru meniul de navigare, pentru partea de subsol și se includ scripturile generale ale aplicației. Aceste fișiere de tip template se găsesc în folderul Shared de sub Views.

Pentru fiecare arie în parte, precum și pentru întreaga aplicație există fișierul _ViewStart.cshtml în folderul Views, ce setează template-ul default pentru toate view-urile ariei/aplicației respective. Acesta conține o singură linie de cod și poate lipsi din aplicație, însă în cazul în care nu există, template-ul folosit de o anumita pagină HTML, trebuie specificat în pagina respectivă. În imaginea de mai jos se poate observa codul din interiorul acestui fișier.

Aceste template-uri se pot folosi și în alt scop. De exemplu pentru stilizarea unui email. Deoarece am implementat în aplicație și un sistem de mailing, am folosit astfel de template-uri pentru stilizarea mesajelor trimise. Inainte ca mesajul să fie trimis la serverul smtp, el incorporează atât elementele de html, cât și “descrierea” css a acestor elemente.

Un plus al limbajului MVC, este acela că permite modificarea interfețelor în funcție de limba vorbită a utilizatorului. Acest lucru este posibil prin prezența unor fișiere de resurse, numite Resources.resx și Resource.ro-RO.resx / Resources.en-GB.resx ( în cazul meu ). Aceste lucruri vor fi explicate pe larg în subcapitolul destinat prezentării regionalizării.

Fișierele de tip javascript sunt încadrate în folderul cu numele Scripts. Structura unui fișier jquery ( sau javascript ) realizat de mine este asemănatoare unei clase din C#, folosind prototipuri, ce presupun modularizarea fișierelor de script.

O imagine generala a folderelor din proiectul principal ( partea publică ) se află mai jos.

Fig. 12 – Folderele din proiectul principal al soluției

Existența folderului Helpers presupune anumite fișiere ajutătoare, care nu se încadrează în celelalte categorii, precum Controllers, Models, Views sau Repositories. Ele conțin diferite funcții care se repetă în aplicație, deci sunt folosite la nivel general. Așa cum, în mod normal, un bloc de cod ce se refolosește într-o clasă, se trece într-o regiune cu numele Helpers, așa și fișierele din folderul respectiv au același rol.

Folderul Enums se folosește pentru definirea fișierelor de enumerație. O enumerație reprezintă o structură de cod ce prezintă anumite valori asociate unor chei, care se folosesc în logica aplicației. De exemplu, în cazul în care avem 2 tipuri de valori, tipul 1 și tipul 2, nu ar fi sugestiv să folosim în logica aplicației doar cifrele 1 și 2. Putem totuși să grupăm aceste valori într-o structură de tip enum și fiecărei valori îi putem asocia o cheie pe care să o folosim în aplicație. Bineînțeles, valorile 1 și 2 pot fi utilizate și într-o altă enumerație, sub alte chei, conform contextului în care sunt utilizate. În imaginea de mai jos este exemplificată structura unei enumerații – General și Financial reprezintă cheile, iar valorile sunt 1 și respectiv 2. Numele enumerației este TaskTypeEnum.

În folderul Content se rețin fișierele de tip stylesheet – fișierele CSS, imaginile folosite în aplicație sau alte elemente prezentate în interfață.

În folderul App_Start se găsesc fișierele de rutare – cele care descriu rutele prin care paginile aplicației comunică între ele, un fișier numit Bundles ce reprezintă grupări de scripturi javascript sau de foi de stil ( CSS ), ce pot fi apelate în paginile HTML astfel încât să nu fie specificat fiecare script în parte, un fișier numit Filters ce permite setarea de filtre asupra aplicației și un alt fișier ce permite autentificarea în program cu ajutorul serviciilor externe, de exemplu Facebook.

În concluzie, am încercat să structurez aplicația cât mai bine posibil, astfel încât, fiecare folder sau fișier să se ocupe de o anumită parte a aplicației, fără să amestec conceptele între ele. Această separare se foloseste și în mediul de afaceri, al marilor companii ce se ocupă cu dezvoltarea aplicațiilor web. Utilizarea arhitecturii MVC a crescut de-a lungul anilor.

3.4 Arhitectura bazei de date

Baza de date, realizată în Sql Server, are 43 de tabele, fiecare având un anumit rol. În rândurile de mai jos o să prezint structura unor tabele, pe care le consider mai importante.

Un tabel foarte simplu, dar care joacă un rol extrem de important în aplicație este . El ajută la securitatea aplicației, parte de care voi vorbi mai pe larg în capitolul destinat securității.

Tabelul conține date despre utilizatori. Are urmatoarele coloane : Id – cheia primară, Biografie, Nume de familie, Prenume, Data nașterii, Nume de utilizator, Parola, IsProtected – pentru administratori, Enabled – daca utilizatorul este activ sau nu, coloană utilă atunci când dorim să banăm o persoană, aceasta ne mai putând să se logheze dacă nu este activă, Marcat ca șters – deoarece entitățile nu se vor șterge niciodată permanent din baza de date, IsVerified – daca utilizatorul și-a verificat mailul după înregistrare, Data înregistrării, Data ultimei autentificări, Descriere, Site web, Id_Address – cheie străină, Id_Role – cheie străină, plus alte coloane ce țin de rețelele de socializare sau de date personale.

Pentru informațiile legate de adresă, am creat mai multe tabele : , , , și un tabel principal ce conține referințe ale tabelelor enumerate anterior ( chei străine ) . Pentru România sunt incluse toate informațiile geografice, urmând ca pentru celelalte țări să se populeze automat, utilizând aplicația.

Tabelul conține setările pentru sistemul de mail construit în aplicație. Se rețin informații precum : serverul de mail, portul, numele de utilizator pentru conectarea la serverul de mail, parola, daca se utilizeaza o comunicație securizată ( SSL ) și mailul emițător.

Informațiile principale despre proiecte se rețin în . Se prezintă informații precum : id-ul categoriei din care face parte proiectul – cheie străină, numele, descrierea, riscuri, o scurtă poveste a proiectului, logo-ul său, data înregistrării, suma necesară, suma strânsă, data de sfârșit, plus alte informații legate de rețelele de socializare și de logica aplicației.

În tabelele , și se rețin date despre fișierele adăugate prin aplicație, precum și transpurea lor în cod hexazecimal. Acest cod este parsat și se construiește imaginea inițială atunci când se dorește vizualizarea ei în interfață.

Un plus față de site-ul Kickstarter, despre care am vorbit în introducere este și existența, tabelului – cutia cu sugestii, așa cum reiese din numele său. Astfel că, în aplicație, utilizatorii înregistrați pot trimite sugestii de îmbunătățire.

Am introdus și un sistem ce se ocupă cu trimiterea newsletterelor, iar abonații, împreună cu mail-ul, numele și un cod pentru dezabonare se rețin în tabelul .

Categoriile prezente în aplicație sunt trecute în tabelul . Coloanele acestuia sunt : nume, descriere, o coloană ce marchează dacă o anumită categorie este ștearsă, o altă coloană ce marchează dacă este activată – doar cele activate fiind vizibile în aplicație, data înregistrării și data ultimei modificări.

În Sql Server se pot face setări pentru ștergerea sau actualizarea în cascadă. Acest lucru presupune transmiterea modificărilor unui tabel primar la tabelele secundare – prin cheile străine. Am încercat, totuși, să folosesc cât mai puțin această facilitate, deoarece logica de ștergere am construit-o doar din aplicație. Doar în cazurile de legatură directă, minoră ( cum ar fi Proiecte – Persoanele care au dat “like” la un proiect ) am setat această funcție.

Sql server îmi oferă și posibilitatea de a seta valori predefinite pentru anumite coloane. Astfel, pentru coloanele de tip data înregistrării am setat ca ca valoare predefinită, data din ziua respectivă. Acest lucru se realizează prin apelul funcției getdate() pe care o găsim definită în Sql Server.

Am ales ca și mediu de dezvoltare pentru baza de date, Sql Server, fiind un program în care am lucrat atât la facultate, prin intermediul cursului de baze de date, precum și la serviciu. Este un mediu de dezvoltare modern, folosit în mediile de afaceri, fiind și un limbaj structurat ( SQL = structured query language ). Conform statisticilor, este cel mai răspândit limbaj pentru bazele de date și este folosit de marile întreprinderi, deoarece suportă informații de mari dimensiuni.

4 Implementarea soluției

4.1 Caracteristici generale

Împărțind aplicația în 2 segmente, partea de administrare și partea publică, în rândurile de mai jos o să vorbesc despre fiecare.

Partea de administrare

În partea de administrare au acces doar utilizatorii cu rol de Administrator. Despre modul de implementare a acestor restricții o să vorbesc la subcapitolul următor. Odată intrat în sistem, un administrator poate naviga către panoul de administrare, folosind calea din meniul principal. Când un administrator ajunge pe pagina principală a panoului de administrare, el poate intra pe secțiunea dorită, folosind unul dintre link-urile existente. În imaginea de mai jos se poate observa o parte din aceste căi.

Fig. 13 – O parte din meniul principal al panoului de administrare

Totul este foarte sugestiv, design-ul simplu și clar, făcând astfel ușoară utilizarea aplicației, mai ales că partea de administrare este văzută doar de cei care s-au ocupat de dezvoltare ( în cazul acesta, de către mine ) sau de persoane angajate special pentru acest lucru.

Pentru partea de administrare am utilizat numai framework-ul BForms, despre care am povestit în capitolul destinat prezentării tehnologiilor folosite. Astfel, toate paginile sunt responsive – se autoaranjează în funcție de rezoluția dispozitivului de pe care sunt vizualizate, conțin griduri sau profile și sunt foarte dinamice și optimizate. De exemplu, elementele se pot edita, fără a se reîncărca pagina – se folosește ajax. În plus, toate mesajele ce apar în interfață sunt vizualizate în limba utilizatorului.

Un grid are ca acțiuni predefinite următoarele : vizualizare detalii despre o anumită înregistrare, ștergere, căutare avansată, căutare simplă, ordonarea elementelor din tabel, paginare, modificarea numărului elementelor afișate în tabel, dezactivarea și activarea elementelor din tabel, reîmprospătarea tabelului și acțiuni rapide ( toate cele prezentate până acum, dar fără a mai expanda detaliile unei înregistrări și fără a folosi butoanele prezente acolo ).

În imaginea alăturată este exemplificată operațiunea de ordonare a coloanelor. Săgeata care apare în dreptul coloanelor indică și tipul ordonării – ascendentă, descendentă sau fără ordonare, atunci când nu apare.

Din bara de unelte a gridului se poate adăuga și căuta înregistrări . La completarea câmpului în care apare mesajul “Caută”, căutarea se face automat, fără click pe un anumit buton. La click pe butonul “Adaugă” apare un formular construit de mine, între tabel și bara de unelte. În imaginea de mai jos este prezentat un formular extrem de simplu, cu un singur câmp ce trebuie completat. În formular sunt prezente și 2 butoane, Adaugă și Resetează. Cel din urmă va reseta câmpurile din formular la valorile predefinite. Același lucru se întâmplă și la apăsarea butonului adaugă, însă numai dacă noua înregistrare a fost salvată în baza de date și a fost inserată în tabelul din interfață.

Fig. 14 – Formular de adăugare din grid

La fel se întâmplă și în cazul căutării avansate. După orice fel de căutare, fie ea simplă sau avansată, în dreptul numelui gridului apare urmatoarea iconiță , ce ne indică faptul că s-a realzat o filtrare a rezultatelor, precum și numărul lor.

Paginarea și numărul elementelor din tabel se pot modifica din partea de jos a gridului, așa cum se poate observa în imaginea următoare.

Fig. 15 – Prezentare opțiuni de paginare ale gridului

Un rând din tabel, expandat, arată în felul următor:

Fig. 16 – Detaliile unui rând din grid

Se poate observa existența unei iconițe, sub formă de creion în partea dreapta a rândului. Apăsând pe ea, forma de prezentare a informațiilor se transforma într-una editabilă.

Fig. 17 – Opțiuni de editare ale unui rând

Forma editabilă permite atât salvarea, caz în care informațiile persistă în baza de date și în locul formei editabile apare cea de vizualizare. Același lucru se întâmplă și pentru butonul Anulează, însă fără persistența datelor în bază.

Acțiunile rapide, de obicei aceleași cu cele prezente în detaliile unui rând pentru a păstra o consistență a paginilor html, se află în dreptul numelui gridului, în partea dreaptă. Ele apar doar după selectarea căsuței ( checkbox-ului ) din dreptul fiecărui rând.

Fig. 18 – Opțiuni suplimentare ce apar la selectarea unui rând

Pentru o mai ușoară selectare a înregistrările se pot folosi filtrele acțiunilor rapide. Dezvoltator poate defini câte filtre dorește

Fig. 19 – Opțiuni de selectare rapidă a rândurilor din grid

Gridurile au fost utilizate pentru prezentarea generală a înregistrărilor din bază, în timp ce profilul este utilizat, așa cum sugerează și numele, pentru detalierea unei singure înregistrări. La fel ca și gridul, acesta dispune de secțiuni de vizualizare, precum și de secțiuni editabile, disponibile prin apăsarea iconiței sub forma de creion. Spre deosebire de grid, toate secțiunile sunt separate una de cealaltă și prezintă un chenar pentru poza de profil. Toate secțiunile se pot colapsa, după cum dorește utilizatorul.

Săgeata din dreptul fiecărui tab indică modul următor de vizualizare, în cazul unui click pe secțiunea respectivă.

În profil toate acțiunile sunt realizate prin Ajax, iar animațiile existente în pagină, precum apariția formelor editabile sau de vizualizare, expandarea sau colapsarea secțiunilor ș.a., sunt realizate cu ajutorul framework-ului jQuery. Încărcarea sau ștergerea pozei de profil se poate face utilizând butoanele + și – din chenarul destinat acesteia. De asemenea, la încărcarea unei poze, aceasta va apărea automat pe pagina de profil. Pentru a face posibil upload-ul ( încărcarea ) pozelor prin Ajax, fiind o acțiune destul de dificilă, s-a utilizat plugin-ul jQuery File Upload, creat special pentru acest lucru. Chenarul pozei de profil este prezentat în imaginea de mai jos – se rearanjează automat în funcție de dimensiunile pozei.

Fig. 20 – Chenar pentru încărcare și ștergere poză de profil

De asemenea, într-o secțiune din profil se poate include și un grid, iar acesta din urmă poate dispune de aceleași funcționalități pe care le poate avea, dacă este inserat într-o pagină separată. Este alegerea dezvoltatorului și de el depinde cum își construiește fișierele necesare.

Fig. 21 – Grid aflat într-un tab din profil

Pe lângă panoul de administrare, în fiecare pagină am inclus și un meniu secundar – similar cu panoul de administrare, pentru o navigare mai ușoară prin paginile de administrare și un sidebar ce permite navigarea către anumite pagini din site-ul public.

Partea de administrare permite editarea, ștergerea sau crearea tuturor elementelor vizibile în partea publică, fapt pentru care o consider unul dintre elementele importante ale unei aplicații web. De aceea am început mai întâi dezvoltarea ei și apoi am continuat cu partea publică. Bineînțeles, pe parcurs s-au mai produs modificări.

Partea publică

Partea publică a site-ului poate fi vizualizată de orice persoană, însă anumite funcții, precum înregistrarea unui proiect, oferirea feedbackului legat de site ș.a. sunt disponibile doar persoanelor înregistrate în aplicație.

Panoul de intrare în aplicație ( login ) este unul simplu, conținând un câmp pentru numele de utilizator și un câmp pentru parolă. Daca unul dintre ele este greșit atunci se va da un mesaj corespunzător. De asemenea, dacă numele de utilizator completat nu există în baza de date, se va specifica acest lucru. Tot în acest panou există și un buton pentru resetarea parolei, care la apăsarea lui ne va schimba formular cu unul în care avem un singur câmp, și anume un email. Dacă emailul există în baza de date, atunci se va trimite un cod de resetare pe acea adresă. Mai jos sunt exemplificate cele 2 panouri, în stânga aflându-se cel de login, iar în dreapta, cel pentru resetarea parolei.

Fig. 22 – Panoul de logare Fig. 23 – Panou pentru resetarea parolei

Toate acțiunile din cele 2 panouri, precum și apariția sau ascunderea lor se realizează prin Ajax, respectiv prin jQuery, astfel că viteza de răspuns este mult mai mare, fără a mai fi nevoie de o reîncărcare a paginii.

Pentru înregistrarea unui nou cont în aplicație există pagina de Register, aceasta din urmă fiind un panou asemănător cu login-ul – folosește același design, însă cu un număr mult mai mare de câmpuri. Parolele sunt salvate în bază criptate, folosind un șir de caractere pe post de salt. Astfel, ele sunt știute doar de către persoana ce și-a făcut cont. Așa arată o parolă criptată.

Fig. 24 – Parolă stocată în baza de date

De asemenea, panoul de înregistrare dispune de validări pentru toate câmpurile completate. Astfel de validări sunt prezente pe tot parcursul aplicației.

În cazul de față, câmpul este validat deoarece prenumele este obligatoriu, însă nu a fost completat. ( Fig. 25 – Validare câmp )

Atât logarea, cât și înregistrarea se regăsesc în meniul principal al aplicației, sub același titlu – Primul pas. Bineînteles, acest câmp Primul pas dispare din meniu după ce persoana folosește, cu succes, formularul de login. De asemenea, toate elemente prezente în meniu apar în funcție de țara și limba pe care o vorbește persoana ce utilizează aplicația.

Se poate observa în poză că, Primul pas are culoarea de fundal verde, fiind elementul activ, curent, din meniu. Celelalte elemente au culoarea de fundal albă.

Pe partea publică mai exista paginile Despre noi, în care sunt prezentate informații despre termenul crowdfunding și Contact, unde putem găsi un formular prin care utilizatorii trimit mesaje. Pe pagina de contact este prezentă și o hartă ce indică locația curentă a “sediului” companiei dezvoltatoare – Splaiul Independenței. Această hartă este prezentă și pe toate paginile, în subsol, dar cu o dimensiune mult mai mică. În pagina despre noi, partea de subsol a paginii nu este activă în mod predefinit, ci doar la trecerea cursorului în zona respectivă.

Pentru trimiterea mail-urilor am folosit serverul SMTP de la google smtp.google.com cu anumite setări.

smtp.Port = 587; //portul specific serverului

smtp.UseDefaultCredentials = false; // fals pentru că vom utiliza date de logare

smtp.Credentials = new System.Net.NetworkCredential

(smtpModel.MailUsername, smtpModel.MailPassword); // datele de logare specifice

smtp.EnableSsl = true; // trimitere prin SSL – sigură

smtp.Send(mail); // trimiterea mail-ului

Variabila mail este construită de către mine și reprezintă ceea ce ajunge la destinație. Eu ii setez un anumit subiect și un conținut, precum și adresa de Reply, dacă este cazul.

În subsolul paginii mai este prezent și un meniu sumar al aplicației, precum și un buton , care la click, printr-o animație, deplasează poziția paginii în partea de sus. Este util atunci când dorim să accesăm un link din meniul principal, link care nu este prezent în meniul din footer.

Fig. 26 – Meniul secundar al aplicației

Butonul de logare din meniul secundar dispare dacă persoana ce utilizează site-ul în momentul respectiv este deja logată în aplicație.

Prima pagină a site-ului, cea de home, poate fi accesată prin click pe sigla și de aceea nu am mai rezervat un loc pentru pagina de start în meniul aplicației.

Multe site-uri dispun de această funcționalitate, astfel că, pentru majoritatea persoanelor este sugestivă.

Din meniul principal, poate fi accesată și lista de proiecte prezente în baza de date. În scopul optimizării, ele nu vor fi afișate în număr complet pe pagină, ci în blocuri de câte 10. Asemănător Facebook-ului, care încarcă mai multe elemente la scroll, am creat un buton care aduce următorul bloc de elemente. Dimensiunea blocului este setată din aplicație.

Fig. 27 – Buton încărcare proiecte

Toate aceste acțiuni sunt realizate prin animații de fade in – fade out pentru a da un aspect plăcut site-ului.

Logica de pagina se poate observa în porțiunea de cod de mai jos. Parametrii forceFirstPage și wasSearched se folosesc pentru a aduce prima pagină în cazul unei noi căutari, iar parametrul ajaxLoaded este utilizat pentru a se cunoaște dacă utilizatorul a intrat pentru prima dată pe pagină sau dacă a apăsat butonul pentru a încărca mai multe înregistrări. De asemenea, am luat în cod și o variabilă disabledButton ce mă ajută să fac butonul neselectabil atunci când am ajuns pe ultima pagină. Atributul [AllowAnonymous] este folosit pentru a permite oricărui tip de utilizator – chiar și cei neînregistrați să poată accesa pagina.

Pagina următoare este reținută pe sesiune Session[“ProjectsPage”], dar dacă sesiunea este nulă – nu are valoarea, acest lucru presupune că utilizatorul a intrat pentru prima dată pe pagină și nu a apăsat încă pe butonul de încărcare. În acest caz se va încărca prima pagină.

Fig. 28 – Câmp de căutare proiecte

Pe pagina amintită mai sus există și un formular de căutare, care se realizează, la fel ca și încărcarea blocurilor de elemente, prin Ajax. Filtrarea, de asemenea, se produce prin efecte de fade in – fade out.

Pe fiecare proiect în parte, prezent în listă, avem un buton ce permite vizualizarea detaliilor acestuia. La click pe el vom naviga în pagina de profil public a proiectului unde sunt ținute toate informațiile necesare, precum poze, descriere, autor, actualizări ale proiectului, data de sfârșit, știri în legătură cu proiectul, finanțatorii, precum și recompensele ce sunt oferite finanțatorilor. Aceste informații sunt organizate în diferite taburi, fiecare cu un anumit rol.

Fig. 29 Secțiuni din zona de profil proiect

În partea dreaptă sunt listate recompensele, iar în partea de jos pozele aferente proiectului respectiv.

Fig. 30 – Chenarul pozelor din zona de profil proiect

În partea dreaptă a fiecărei secțiuni din pagina de detalii apare și un link prin care putem edita. La click pe acest link, blocurile de text destinate vizualizării informațiilor se transformă în formulare editabile, proces asemănător părții de administrare, însă fără utilizarea plugin-ului BForms. Totul este realizat manual.

Am realizat diferite forme de editare în funcție de natura elementului pe care dorim să-l edităm – calendar, număr, adresă sau chiar un mini-word. Elementele de tip adresă prezintă și autocompletare ( dacă scriem în căsuța aferentă Pr se vor prezenta sugestii ale orașelor sau județelor – în funcție de ce încercăm să completăm – care încep cu cele 2 inițiale ). Autocompletarea este realizată folosind tehnologia prezentată la început, numită Ajax – apelez o metodă de pe server ce îmi întoarce elementele care se potrivesc căutării.

În poza din stânga este prezentat editorul de text pentru porțiunile “Descriere” și “Riscuri” din pagina de prezentare a proiectului

Fig. 30 – Zone de editare din pagina de profil proiect

Toate aceste elemente pot fi editate doar de către persoana căreia îi aparține proiectul respectiv. Nimeni altcineva, indiferent de poziția pe care o ocupă în cadrul aplicației nu are acest drept. Administratorii pot edita din partea de administrare.

Pe lângă profilul unui proiect, utilizatorul găsește în aceeași pagină și o secțiune destinată task-urilor și noutăților aduse proiectului respectiv. Toate elementele din aceste secțiuni se pot șterge – nu se editează. De asemenea se pot adăuga și altele noi. Poze cu facilitățile prezentate anterior se găsesc în anexa documentației.

Tot în pagina respectivă există și o secțiune destinată prezentării utilizatorilor ce au finanțat proiectului. Sunt prezentate informații precum : nume, nume de utilizator și email. În plus, este pus la dispoziție si un câmp destinat căutării – pentru cazul în care sunt foarte mulți finanțatori.

Butoanele de editare sunt disponibile doar celui care a adăugat proiectul respectiv.

Proiectele se pot introduce în sistem prin intermediul wizard-ului de înregistrare. Este construit fără utilizarea unui plugin, toate acțiunile și paginile fiind realizate de la 0. Acesta are 6 pași vizibili și încă unul care nu este disponibil utilizatorilor, cel din urmă ocupându-se cu trimiterea mail-urilor către administratori după ce un proiect a fost înregistrat cu succes. Administratorii vor urma linkul primit pe mail pentru aprobarea proiectului respectiv.

Fig. 31 – Pașii wizard-ului de înregistrare proiect

Primul pas presupune acceptarea termenilor și condițiilor. Al 2-lea reprezintă completarea informațiilor de bază ale proiectului – nume, poveste scurtă, data, suma de bani, categoria și informații legate de rețelele de socializare. Al 3-lea pas presupune completarea unei descrieri detaliate ale proiectului și ale riscurilor la care poate fi supus acesta. În pasul 4 se completează datele despre adresa proiectului, iar în pasul 5 se realizează lista cu recompensele oferite, urmând ca în pasul 6, utilizatorul să încarce poze pentru proiectul respectiv.

Informațiile persistă în baza de date prin intermediul butonului Continuă, aflat în josul paginii. Deoarece wizard-ul permite vizualizarea pașilor, fără completarea lor – prin meniu expus în poza de mai sus, am introdus o alertă ce apare în cazul în care utilizatorul dorește salvarea, fără să fi terminat primul pas.

Fig. 32 – Alertă tentativă de salvarea greșită a pasului

De asemenea, dacă utilizatorul dorește să treacă la pasul următor fără a completa câmpurile, iar printre ele se află și câmpuri obligatorii, formularul se va valida și utilizatorului nu i se va permite efectuarea acțiunii dorite. Totodată, validarea presupune și deplasarea poziției paginii către meniu, pentru o mai bună vizualizare a câmpurilor completate greșit sau necompletate.

Trecerea dintr-o pagină în alta se realizează printr-un efect de slide din stânga sau din dreapta, conform butonului apăsat – înapoi sau continuă. La navigarea cu ajutorul meniului se ține cont și de poziția curentă, astfel încât, dacă utilizatorul apasă pe butonul asociat paginii curente fereastra va vibra și nu dispare, iar apoi să reapare ( prin slide ). Astfel îi este indicat că acțiunea pe care a dorit să o realizeze, are rezultatul deja afișat în pagină.

Orice pas din wizard este bine documentat, astfel încât utilizatorul să îl poată completa cu ușurință. De exemplu în poza de mai jos apar o parte din câmpurile aferente primului pas.

Fig. 33 – Zonă din primul pas de înregistrare

În poza din dreapta sus, chenar ce apare la primul pas de înregistrare, se autocompletează câmpurile pe măsură ce utilizatorul umple input-urile, din stânga, cu date – previzualizarea blocului ce apare în lista de proiecte.

În formularul de adresă utilizatorul este ajutat de o precompletare inteligentă, disponibilă pentru România. În baza de date am introdus toate județele din țară, precum și orașele sau comunele. La fiecare tastă apăsată, câmpurile sunt autocompletate cu înregistrările corespunzătoare.

Pentru secțiunea cu numărul 5 utilizatorul are la dispoziție 2 butoane prin care mai poate adăuga sau șterge recompense. Acțiunile se realizează cu ajutorul unor efect de fade și de slide.

Pe partea de adăugare poze, acestea sunt încărcate pe server în blocuri de un anumit număr și nu separat. În acest mod aplicația este mai optimă și mai rapidă. De asemenea se dă posibilitatea ștergerii lor din aceeași pagină. În dreptul fiecărei poze apare o iconiță ce indică statusul curent – dacă poza a fost încărcată sau nu. În imaginea din stânga, de mai jos, poza nu este încarcată.

Fig. 34 – Prezentare status poze din ultimul pas al wizardului

Pe partea publică am pus la dispoziție și o pagină cu profilul utilizatorilor. Dispune și de opțiuni de editare, însă ele pot fi efectuate doar de către cel care deține profilul respectiv. În această pagină sunt prezente și două liste – proiectele adăugate de persoana ce deține profilul respectiv și proiectele pe care le-a finanțat. Listele nu sunt vizibile inițiat, ci apar la apăsarea unor butoane cu nume specifice. Apariția listelor nu este statică, ci este realizată printr-un efect. De asemenea, am adăugat și o opțiune de căutare în fiecare dintre cele 2 liste.

Tot în această pagină sunt ținute și detaliile legate de adresa utilizatorului. La fel ca și celelalte elemente, aceste informații sunt editabile, iar formele de editare sunt asemănătoare cu cele prezentate în pagina unui proiect.

Fig. 35 – Câmp editabil din profilul utilizatorului

Am înglobat în partea publică a site-ului și o secțiune destinată știrilor. Pagina se prezintă asemănător unui “timeline” ( cronologii ). Toate știrile au ca dimensiune maximă de afișare 600 de caractere, însă textul poate depăși această valoare, caz în care, la știrea respectivă apare un buton ce va deschide o fereastră cu textul complet.

Fig. 36 – Buton pentru afișarea detaliilor unei știri

Știrile pot fi vizualizate în două moduri – compact sau extins. În poza de mai jos se poate observa modul compact de vizualizare, precum și așezarea în pagină ( în stânga ) și modul expandat în dreapta. Modurile pot fi combinate în funcție de cum dorește utilizatorul. De asemenea, în modul expandat se păstrează design-ul paginii, cu observația că fiecare știre va ocupa un loc mai mare pe ecran, fiind disponibilă și o parte din conținut sau chiar tot conținutul, spre deosebire de o știre colapsată, unde se pot vedea doar titlul, autorul și data.

Fig. 37 – Moduri de prezentare a știrilor

În modul compact sunt vizibile titlul și autorul știrii respective. Data la care a fost adăugată este vizibilă la trecerea cu mouse-ul prin cercul din dreptul lor. O parte din codul ce permite acest lucru este scris în rândul următor – modificarea modurilor de vizualizare făcându-se la click pe o anumită știre.

$('.js-heading').click(function(e) { // identificator pentru toate știrile.

var target = $(e.currentTarget); // se ia știrea curentă

target.parents('li').find('.js-footer').toggle('slow'); // se colapsează sau expandează

target.parents('li').find('.js-body').toggle('slow'); // se colapsează sau expandează

return; // ieșirea din funcție

});

Pe lângă paginile prezentate mai sus, ultimele 2 secțiuni existente în partea publică a site-ului sunt : întrebări puse frecvent și pagina pentru finanțarea unui proiect. În pagina de finanțare utilizatorul are opțiunea de a alege din recompensele proiectului respectiv ( titlul si autorul proiectului se găsesc în partea de sus a paginii ) sau de a introduce el o anumită valoare. De asemenea, el poate alege o recompensă de 5 euro și să completeze câmpul aferent sumei dorite cu o valoare peste 5 euro, caz în care se presupune că el dorește recompensa, însă a finanțat proiectului cu o valoare mai mare. În această pagină sunt vizibile doar recompensele care nu au atins limita maxima de finanțatori, limită setată de creator în momentul adăugării proiectului. După finanțare, se va trimite mail către acel utilizator.

Mai multe imagini cu partea de administrare, cât și cu partea publică a site-ului puteți găsi în anexa acestei documentații.

4.2 Securitatea soluției

În primul rând, securitatea se caracterizează prin capacitatea unei soluții ( aplicații ) de a rezista atacurilor. Cu alte cuvinte, o securitate bună micșorează nivelul vulnerabilității unui sistem. Important de reținut este faptul că, oricât de mult vom încerca să securizăm o aplicație, aceasta nu va fi niciodată complet sigură și imună atacurilor de orice gen.

O securitate sporită se datorează și experienței administratorilor.

Există mai multe tipuri de atac, pentru care un administrator, precum și o aplicație trebuie să fie pregătită : accesul utilizatorilor – un utilizator normal poate găsi breșe în sistem, de obicei, datorate lipsei unor restricții pentru utilizatorii normali ; o astfel de persoană va încerca salvarea unor informații colectate din aplicație sau mai rău, modificarea unor informații, accesul de la distanță – atac de tip DOS ( denial of service ) care de multe ori duce la încetinirea sistemului până în momentul când acesta din urmă cedează complet.

În privința aplicațiilor web cele mai cunoscute atacuri sunt : SQL Injection sau Cross-Site Scripting ( XSS ). Injectarea SQL se realizează atunci când un utilizator folosește câmpurile editabile din aplicație pentru a introduce cereri către baza de date, fie că ele sunt corecte sau nu – o persoană va încerca până va primi un rezultat, pe parcurs aflând tot mai multe informații folositoare pentru a lansa următorul atac. Printr-un studiu, ce a avut loc în anul 2012, o companie numita, Imperva, a realizat un studiu privind atacurile de tip SQL la care sunt supuse aplicațiile web și s-a observat că site-urile personale primesc în jur de 4 atacuri/încercări pe lună, în timp ce pentru site-urile comerciale, cifra se dublează.

Un exemplu de atac simplu este surprins în imaginea de mai jos.

Fig. 38 – Exemplu de atac simplu asupra bazei de date

Printr-un atac de tip XSS sunt injectate diferite script-uri în codul sursă al unei aplicații, cu intenția de a modifica, distruge sau obține informații. Dacă datele provenite din interfață nu sunt verificate pe server, ele pot avea efect devastator atunci când au fost introduse de o persoană rău intenționată. De exemplu, pe un site ce are o secțiune de comentarii, un utilizator poate strecura, pe lângă comentariul său și un script invizibil pentru interfață, dar care rulează în spate, script ce se transmite utilizatorilor și are ca efect transferul banilor din contul personal de PayPal în alt cont atunci când aceștia intră în sistem. De aceea e bine să criptăm și să verificăm orice informație transmisă de la client la server și invers.

Fig. 39 – Schemă atac XSS ( sursa : www.techgyd.com )

Un atacator poate urmări cookie-urilor unui site prin jQuery și, în plus, există și instrumente ce pot verifica site-ul pentru slăbiciuni – Nessus sau Nikto. Aceste instrumente pot fi folosite atât de dezvoltatori, cât și de persoanele rău intenționate. De reținut este faptul că, acele cookie-uri pot fi urmărite, chiar dacă este dezactivată opțiunea document.cookie de pe dispozitivul clientului ( consumatorului ). Acest proces de urmărire a informațiilor poartă numele de HTTP Trace, informațiile fiind colectate și apoi transmise către alt server. Pe serverul final, un atacator le poate utiliza pentru propriul interes. O metodă clasică de protecție împotriva XSS-ului este dezactivarea trace-ului HTTP. Acest lucru, într-o aplicație MVC se face prin adăugarea următorului cod în web.config.

În cazul aplicației Crowder am încercat să respect cele prezentate mai sus, precum și o criptare a datelor provenite de pe server sau la server. Algoritmul de criptare se găsește în anexa acestei documentații. De asemenea, am realizat o criptare la nivelul acțiunilor de tip GET și POST, astfel încât numărul de identificare al elementelor să nu arate în felul următor

id-ul este vizibil

În poza de mai sus code este criptat și nu se cunoaște valoarea lui reală. Numai cei care dețin șirul de salt și algoritmul de criptare ( de obicei doar dezvoltatorul ) poate obține valoarea lui reală.

Pe lângă criptare și dezactivarea HTTP Trace-ului, în Crowder am introdus și posibilitatea introducerii scripturilor jQuery în câmpurile editabile, însă fără a le executa. Ele sunt interpretate precum un șir de caractere.

Fig. 40 – Exemplu de atac simplu prin script injection

În plus, transmiterea datelor se realizează prin Ajax, fără reîncărcarea paginilor și de aceea majoritatea execuțiilor nu sunt vizibile în interfață. Toate lucrurile de mai sus se aplică indiferent de browser-ul de pe care este vizualizat site-ul.

4.3 Regionalizarea

Aplicațiile moderne sunt internaționalizate. Acest proces reprezintă construirea aplicațiilor în mai mult de o singură limbă. Astfel, dacă un utilizator din Franța și unul din România vor intra pe aplicație, dorind să vizualizeze site-ul, conținutul pentru persoana din România va fi afișat în română, în timp ce, pentru cel din Franța, va fi afișat în franceză, dacă dezvoltatorul a oferit această facilitate, sau în engleză dacă nu este altfel disponibil.

În momentul de față, pentru Crowder conținutul este disponibil în engleză și în română.

Fig. 41 – Prezentare meniului în engleză și în română

Pentru limba engleză se adaugă în bara de adresă ( în url ) șirul de caractere /en. Pe server, orice adresă este interpretată și utilizatorului îi este oferit conținutul în limba dorită.

Un plus al limbajului MVC este acela că permite modificarea interfețelor în funcție de limba vorbită a utilizatorului. Pentru a seta diferite culturi într-o aplicație MVC, trebuie să ne definim șirurile de caractere conform fiecărei culturi pe care dorim să o implementăm. Acest lucru este posibil prin crearea unor fișiere numite Resources.resx, la care se adaugă acronimele culturii respective. De exemplu pentru România avem Resources.ro-RO.resx, iar pentru engleza britanică avem Resources.en-GB.resx. Fiecare fișier are 2 coloane pe care trebuie să le definim : una în care se definește numele resursei – o vom apela în aplicație în locul șirului de caractere și o altă coloană ce conține implementarea resursei respective – șirul de caractere aferent ei. De exemplu, în loc să folosim șirul “Unvisersitatea Politehnica din Bucuresti” pentru română și “Politehnica University from Bucharest” pentru engleză, ne putem define o resursa cu numele UniversityName pe care o vom apela în aplicație. Fișierul Resources.resx conține doar numele resurselor împreuna cu un comentariu, fără implementare. Un exemplu de implementare poate fi observat în imaginile de mai jos.

Fig. 42 – Tabele cu textele regionalizate

4.4 Auditarea și salvarea erorilor

Auditarea se realizează prin înregistrarea anumitor informații în baza de date, precum : ultima dată a autentificării – în cazul utilizatorilor, editat de către, editat la data de, șters de către, șters la data de ș.a. Aceste informații pot fi utile atunci când se dorește investigarea unei acțiunii. În plus ele pot fi puse la dispoziție administratorilor, chiar din interfață.

De asemenea, am realizat și o auditare separată pentru acțiunile administratorilor. Aceste informații se rețin într-un tabel separat, în baza de date – LogAdminActions. Pentru salvarea acțiunilor utilizatorilor am creat tabelul LogUsersActions.

Salvarea erorilor se realizează prin intermediul unor metode construite de către mine pe partea de server, iar datele se rețin în următorul tabel – atât pentru partea de administrare, cât și pentru partea publică:

Id-ul reprezintă cheia primară

Coloana IsAjax reprezintă salvarea tipului de acțiune ce a generat eroarea – daca este realizată prin Ajax sau nu

UrlReferrer reprezintă adresa de la care s-a generat eroarea

Exception presupune mesajul de eroare

Timestamp – data la care s-a înregistrat eroarea

IpAddress – adresa ip de la care a provenit eroarea

Method – metoda apelată de pe server ce a dus la generarea erorii

Browser – ce browser s-a folosit atunci cand eroarea a fost generată

Fig. 43 – Tabelul de salvare a erorilor

În opinia mea, toate aplicațiile moderne trebuie să dețină un sistem de auditare, precum și de logare a erorilor. Totodată, dacă se pune accent pe acest lucru, se poate implementa un sistem de notificări pentru modificările aduse aplicației. Atunci când se creează o modificare pentru o parte importantă din program, toți administratorii sau persoanele ce dețin drepturile necesare vor fi notificați printr-un email. Pe viitor, doresc să implementez acest lucru pentru finanțarea proiectelor, precum și pentru modificările unui proiect ce este deja lansat spre finanțare. Consider acest lucru util, atât pentru o funcționare corespunzătoare a site-ului, cât și pentru partea de securitate. Deși la început ai nevoie de acordul unui administrator înainte ca proiectul să fie lansat spre finanțare, pe parcurs informațiile prezentate, aferente lui, pot fi modificate de către utilizator.

5 Dezvoltări ulterioare

Indiferent de tipul de proiect realizat, fie că este o aplicație web sau una desktop, ea trebuie îmbunătățită constant. Mereu vor apărea lucruri noi de care utilizatorii de internet vor fi încântați și e bine să integrezi acele lucruri cât mai repede și în aplicația ta, dacă este posibil.

Toate dezvoltările pe care doresc să le realizez, vreau să le construiesc înainte ca proiectul să fie lansat în producție.

5.1 Dezvoltări ulterioare pentru baza de date

În primul rând, înainte de a face modificări asupra tabelelor, pe viitor, intenționez să folosesc Sql Server 2014, deoarece aduce foarte multe lucruri în plus, precum și o viteză mai bună de răspuns.

De asemenea, doresc să verific fiecare tabel, să îl compar cu aplicația și să șterg orice coloană nefolosită. În plus, în funcție de modificările pe care le voi aduce în aplicație baza de date va fi actualizată.

În viitor mă voi gândi și la avantajele utilizării unei baze de date NoSql și de asemenea doresc să mă consult cu un designer web și cu persoane ce lucrează deja în domeniul multifinanțării.

5.2 Dezvoltări ulterioare pentru aplicație

Modificările pe care doresc să le aduc pe viitor aplicației sunt :

Integrarea unui blog în aplicație

Abonarea la un serviciu de monetizare a donațiilor făcute pentru proiecte

Adăugarea unei noi categorii de finanțare pe termen lung, astfel încât marile companii ce doresc finanțarea unui proiect să poate face acest lucru printr-un contract => promovare

Posibilitate integrării video-urilor în descrierea proiectului prin intermediul unui player video construit de către mine

Integrarea în aplicație a unui algoritm pentru determinarea locației curente a utilizatorului în funcție de adresa IP a acestuia pentru furnizarea unui conținut care îl poate interesa mai mult

Adăugarea mai multor culturi – pentru regionalizare, cum ar fi franceza sau daneza.

Integrarea site-ului cu rețelele de socializare precum Facebook, Google+, Twitter ș.a.

Adăugarea unei pagini pentru promovarea proiectelor finanțate cu succes

Îmbunătățirea sistemului de taskuri pe care utilizatorul le poate adăuga, astfel încât acestea să fie accesibile tuturor, pentru nimeni sau doar persoanelor pe care acesta le alege – asemănător unei rețele de socializare, precum și implementarea unui sistem de notificări la nivel de taskuri, astfel încât utilizatorul să fie anunțat atunci când se apropie deadline-ul unui task sau cât a realizat din el

Adăugarea unei pagini ce îi permite unui utilizator să își gestioneze finanțele precum și modul în care un proiect i le-ar putea afecta – cu generare de statistici

Adăugarea posibilității de a genera pdf-uri cu descrierea proiectelor

Adăugarea unor noi funcționalități pentru partea de administrare, astfel încât utilizatorii cu drepturi ridicate să poată genera statistici privind utilizarea site-ului pe ore, zi, săptămâni sau luni

Lansarea site-ului în producție

Crearea unor aplicații native pentru Android, iOS și Windows Phone

Implementarea unui sistem de notificări pentru modificările aduse proiectelor lansate deja spre finanțare

6 Concluzii

“Fiecare vis începe cu un visător.” – Harriet Tubman

Deși noi considerăm multifinanțarea ca fiind un concept modern, el a început încă din anul 1700. De exemplu, mai jos am găsit o statistică pe site-ul www.imparte.ro cu proiecte importante, înființate încă din anul 1700.

“1700 – Fondul de Credite Irlandez, infiindat de autorul Jonathan Swift ("Calatoriile lui Gulliver"), acorda imprumuturi familiilor cu venituri reduse din zonele rurale irlandeze.
1976 – Inventatorul microfinantarii, dr. Mohammad Yunus, implicat intr-o multime de acte caritabile, lanseaza un program in Bangladesh prin care ofera oportunitati de finantare locuitorilor cu venituri reduse; la 5 ani de la initiativa, programul a adunat 30.000 de membri.
1983 – Dr. Mohammad Yunus transforma programul de finantare din Bangladesh in institutie bancara; ia astfel nastere Banca Grameen, care astazi are peste 8 milioane de clienti, iar 97% din imprumuturi merg catre afaceri administrate de femei.
2005 – Proiectul non-profit KIVA ofera posibilitatea acordarii microcreditelor catre antreprenori din zone sarace ale lumii; rata totala de returnare depaseste 98%, ceea ce este o reusita remarcabila.
2006 – Michael Sullivan, fondatorul FundaBlog, foloseste prima oara si patenteaza termenul de crowdfunding. In acelasi an, dr. Yunus si Banca Grameen castiga Premiul Nobel Pentru Pace.”

În ceea ce privește implementarea unei platforme de multifinanțare în România, consider că un mare accent trebuie pus pe uzabilitatea aplicației. De obicei, românii se plictisesc foarte repede de o aplicație dacă este greu de folosit sau dacă nu atrage atenția. Astfel, trebuie ținut cont de faptul că relația între aplicație și utilizator este foarte importantă. Un utilizator, trebuie să facă ce dorește într-un context cât mai sugestiv și mai simplu, fără a pierde însă din lucrurile importante ale aplicației.

“În ceea ce privește crearea siturilor sau a aplicațiilor web-based, ideea principală este aceea că, indiferent de modul în care dorește, administratorul aplicației să o folosească, există un singur mod de a o crea, mai exact prin punerea în centru a utilizatorului.” – [sursă: Probleme de uzabilitate – TreeWorks]

O bună implementare a aplicației duce la următoarele:

Creșterea numărului de utilizatori precum și a satisfacției de care aceștia dau dovadă

Creșterea productivității și a succesului

Reducerea costurilor pentru mentenanță

S-au efectuat anumite studii privind așteptările unor clienți în utilizarea site-urilor web, iar opinia exprimată de ei a fost următoarea :

Utilizatorii erau obișnuiți ca link-urile pentru navigarea spre pagina principală, de Home să fie localizate în marginea de sus a paginii, în stânga

Help sau FAQ – întrebări puse frecvent să fie localizate în partea dreaptă, sus, sau în mijlocul paginii în nota de subsol

Reclamele să fie localizate în partea de sus sau pe marginea din dreapta

În cazul aplicațiilor de vânzări online, coșul de cumpărături să fie plasat în partea din dreapta sus – exemplu www.emag.ro

S-a observat astfel necesitatea construirii unei scheme a obiectelor web dintr-o pagină, astfel încât acestea să fie localizate în unele zone ce sunt deja cunoscute utilizatorilor.

În opinia mea, un aspect important pe care orice pagină web trebuie să îl aibă, este design-ul plăcut. Deoarece, eu nu am lucrat niciodată pe partea de design nu pot spune că am făcut un lucru extraordinar, dar, pe viitor, înainte de a lansa aplicația în producție doresc să angajez un designer care să evalueze și să îmbunătățească aplicația din acest punct de vedere.

“În general, designul joacă un rol important în stabilirea unei prime impresii plăcute. Când un website este armonios construit, el prinde utilizatorul, îl atrage și îi creează un sentiment de ordine interioară, un echilibru al experienței vizuale. Când nu este armonios construit, website-ul devine ori plictisitor, ori haotic ” [sursă: Lauer & Pentak, 2002]

Totodată, în cazul design-ului culoarea este importantă și de obicei are efectul unor mesaje subliminale. Am ales culoarea verde pentru a apropia utilizator mai mult de natură, de artă, de lucrurile verzi.

În ziua de azi, informația o poți găsi oriunde și de aceea este foarte importantă atracția pe are site-ul o creează la prima vedere. Dacă nu este una puternică, acea persoană va căuta ceea ce dorește în altă parte, pe un site mai apropiat de stilul său. De aceea, dezvoltatorul trebuie să fie obiectiv și nu adauge în aplicație elemente personale. De obicei, utilizatorii web sunt capricioși și nerăbdători.

Am ales dezvoltarea aplicației folosind Bootstrap deoarece, în ziua de azi majoritatea folosesc smartphoneul pentru utilizarea internetului. Multe persoane sunt grabite, nu au un laptop în apropiere și chiar cunosc persoane care își conduc afacerea de pe telefonul mobil atunci când sunt plecate din birou.

Fig. 45 – Adaptare aplicație la diferite rezoluții

Nu am avut ocazia să testez aplicația și pe un smart tv, însă înainte de a o lansa în producție, sigur voi face acest lucru. Vreau ca toate aspectele să fie verificate înainte de a face acest pas, fiind totuși un punct ce va implica anumite costuri – hosting, mentenanță și dezvoltare ulterioară. De exemplu, în imaginea de mai jos este evidențiată durata de viață a unei aplicații web :

Fig. 46 ( sursa : http://www.sixrevisions.com/web-development/agile )

Se poate observa că procesul de mentenanță este singurul care va ocupa un loc important în viitor, mai ales pentru o platformă de multifinanțare, unde nu e nevoie de îmbunătățiri majore de la lună la lună sau de la an la an. De obicei, conținutul depinde de numărul de proiecte adăugate pe site și dacă aplicația este de succes, conținutul se schimbă mereu. Poate singurul lucru ce trebuie îmbunătățit constant ar fi securitatea aplicației, deoarece pe parcursul vieții ei vor apărea și alte metode de atac, necunoscute în momentul dezvoltării.

Inițial, internetul și navigarea pe internet au fost proiectate în scop informativ, însă s-a dezvoltat foarte mult, astfel încât, în ziua de azi, există câteva surse sigure de informare – precum Wikipedia, iar în rest web-ul a evoluat într-un mediu al aplicațiilor

În opinia mea, dezvoltarea unei platforme de multifinanțare a reprezentat o provocare pentru mine, a trebuit să țin cont de foarte multe lucruri, într-un timp nu foarte îndelungat și am lucrat cu anumite tehnologii pe care nu le mai folosisem până acum. A fost o experiență plăcută și în același timp, mi-a dat posibilitatea de a construi un lucru personal, de care aș putea să mă folosesc în viitor. Deși, în momentul de față aplicația nu reprezintă nici 80% din ceea ce îmi doresc, în timp, o voi îmbunătății și voi adăuga funcționalitățile necesare, pe care mi le doresc. Voi încerca construirea nu numai a unei platforme de multifinanțare, ci a unei comunități și răspândirea conceptului tot mai mult în România.

“Happiness lies in the joy of achievement and the thrill of creative effort.”

Franklin D. Roosevelt

Bibliografie

[ 1 ] “Joseph Albahari și Ben Albahari, C# 5.0 in a Nutshell – Fifth Edition, SUA, O’Reilly, ISBN: 978-1-449-32010-2”

[ 2 ] “Jon Galloway, Phil Haack, Brad Wilson, K. Scott Allen, Professional ASP.NET MVC 4, Indianopolis, Wiley Publishing, ISBN: 978-1-118-34846-8”

[ 3 ] “Robert Vieira, Beginning Microsoft SQL Server ver® 2008 Programming, Indianopolis, Wiley Publishing, ISBN: 978-0-470-25701-2”

[ 4 ] “TreeWorks, Probleme de uzabilitate în crearea siteurilor și aplicațiilor web-based, Romania

[ 5 ] http://en.wikipedia.org/wiki/Crowdfunding

[ 6 ] http://www.asp.net/mvc/tutorials

[ 7 ] http://en.wikipedia.org/wiki/Multitier_architecture

[ 8 ] http://adamyan.blogspot.ro/2010/02/aspnet-mvc-2-localization-complete.html

[ 9 ] https://www.youtube.com/user/dnfvideo/videos

[ 10 ] http://biblioteca.regielive.ro/cursuri/limbaje-de-programare/proiectarea-web-dezvoltarea-sistematica-a-aplicatiilor-web-146194.html

[ 11 ] http://www.securitatea-informatica.ro/audit-securitate/vulnerabilitati/tipuri-de-atacuri-asupra-aplicatiilor-web/

ANEXE

Partea publică

Fig. 1 – Panou de login Fig.2 – Panou pentru resetarea parolei

Fig. 3 – Panou de înregistrare

Fig. 4 – Pagina de start

Fig. 5 – Pagina de start

Fig. 6 – Întrebări frecvente

Fig. 7 – Pagina de proiecte

Fig. 8 – Pas din wizard-ul de înregistrare proiect

Fig. 9 – Pagina de știri

Fig. 10 – Pagina de contact

Fig. 11 – Pagina de profil utilizator

Partea de administrare

Fig. 12 – Panoul de administrare

Fig. 13 – Tabele ( administrarea listelor – dispune de acțiuni de tip adăugare, ștergere, editare, căutare, căutare rapidă și acțiuni specifice fiecărei pagini )

Fig. 14 – Pagină de profil ( administrare obiect )

Bibliografie

[ 1 ] “Joseph Albahari și Ben Albahari, C# 5.0 in a Nutshell – Fifth Edition, SUA, O’Reilly, ISBN: 978-1-449-32010-2”

[ 2 ] “Jon Galloway, Phil Haack, Brad Wilson, K. Scott Allen, Professional ASP.NET MVC 4, Indianopolis, Wiley Publishing, ISBN: 978-1-118-34846-8”

[ 3 ] “Robert Vieira, Beginning Microsoft SQL Server ver® 2008 Programming, Indianopolis, Wiley Publishing, ISBN: 978-0-470-25701-2”

[ 4 ] “TreeWorks, Probleme de uzabilitate în crearea siteurilor și aplicațiilor web-based, Romania

[ 5 ] http://en.wikipedia.org/wiki/Crowdfunding

[ 6 ] http://www.asp.net/mvc/tutorials

[ 7 ] http://en.wikipedia.org/wiki/Multitier_architecture

[ 8 ] http://adamyan.blogspot.ro/2010/02/aspnet-mvc-2-localization-complete.html

[ 9 ] https://www.youtube.com/user/dnfvideo/videos

[ 10 ] http://biblioteca.regielive.ro/cursuri/limbaje-de-programare/proiectarea-web-dezvoltarea-sistematica-a-aplicatiilor-web-146194.html

[ 11 ] http://www.securitatea-informatica.ro/audit-securitate/vulnerabilitati/tipuri-de-atacuri-asupra-aplicatiilor-web/

ANEXE

Partea publică

Fig. 1 – Panou de login Fig.2 – Panou pentru resetarea parolei

Fig. 3 – Panou de înregistrare

Fig. 4 – Pagina de start

Fig. 5 – Pagina de start

Fig. 6 – Întrebări frecvente

Fig. 7 – Pagina de proiecte

Fig. 8 – Pas din wizard-ul de înregistrare proiect

Fig. 9 – Pagina de știri

Fig. 10 – Pagina de contact

Fig. 11 – Pagina de profil utilizator

Partea de administrare

Fig. 12 – Panoul de administrare

Fig. 13 – Tabele ( administrarea listelor – dispune de acțiuni de tip adăugare, ștergere, editare, căutare, căutare rapidă și acțiuni specifice fiecărei pagini )

Fig. 14 – Pagină de profil ( administrare obiect )