Internetul. Limbajele de Programare Folosite

INTRODUCERE

Odată cu începutul erei WEB, anii 1990, Internetul a crescut și s-a dezvoltat cu o viteză amețitoare. Distribuirea informației, a cunoștințelor și a opinilor cu alți ultilizatori ai Internetului, precum și multe oportunități, au apărut în acest context. Apariția comerțului electronic a revoluționat multe domenii precum: lumea muzicii, lumea filmelor și a artei, lumea afacerilor. Scopul WEB-ului este totodată distribuția de documente, inițial în cadrul său apărând protocolul HTTP și formatul HTML.

Internet-ul este o lume care nu cunoaște limite, acest fapt constituind un avantaj major, dar și un dezavantaj. Dezavantajul este faptul că a crescut exponențial cantitatea de informație și acest fapt a generat problema supra-încărcării de informație.

Internet-ul oferă și o multitudine de aplicații WEB. O aplicație WEB este un program care rulează pe baza unei arhitecturi client-server. Aplicațiile folosesc tehnologii deschise de World Wide Web. World Wide Web este definit ca „a common information space in which we communicate by sharing information” (Tim Berners-Lee-2013). Browserele web se folosesc drept client, iar acest fapt ușurează folosirea lor. În trecut, atât serverul cât și clientul rulau tehnologii proprietar și, din această cauză, mentenanța aplicațiilor de tip client era foarte complexă.

Prin introducere CGI s-a putut realiza rularea unor script-uri pe server, iar acestea generau un răspuns dinamic în format HTML.

Un CGI este un standard de comunicare între documentele Web și scripturile CGI. Acesta este un program care comunică cu documentele Web. Acest concept pemite dezvoltarea unor pagini Web mai dinamice și folosirea oricărui limbaj ce poate fi executat de calculatorul care este server Web.

Dezvoltarea a constat în transformarea acestor documente HTML în interfețe dinamice. S-a realizat cu ajutorul limbajelor precum Java-Script.

La scurt timp, limbajul Java-Script s-a dezvoltat foarte tare prin introducerea API-ului XmlHttpRequest, care putea programa și efectua răspunsuri la mici cereri care erau transferate de la client la server în format XML. Acest lucru se numește AJAX. Mai târziu, s-a preferat standardul JSON (obiecte JavaScript serializate).

Aplicațiile web sunt programe web-based care se execută într-un browser web, iar implementarea lor se face în limbaje de programare precum: PHP, ASP, PEARL, PYTON, HTML, CSS, JAVASCRIPT etc. Tot mai mulți utililzatori se îndreaptă spre acest tip de aplicații datorită avantajelor pe care le oferă, comparativ cu programele clasice existente. Programele clasice necesită instalarea și rularea lor.

Unul dintre cele mai mari avantaje ale aplicațiilor Web este faptul că ele sunt independente de sistemul de operare și pot fi rulate pe aproape orice sistem de operare prin intermediul unui browser web.

Un alt avantaj este faptul că nu necesită instalare. Pentru utilizarea unei aplicații web este necesară doar folosirea unui browser web. Totodată, actualizările sunt foarte ușor de făcut. Modificările se fac întru-un singur loc, pe server, și se propagă automat către utilizatori. În cazul unui program clasic de tip client-server este necesară instalarea sau reinstalarea aplicației pe computer, deoarece interfața cu utililzatorul este asigurată prin intermediul unui program client instalat pe calculatorul fiecărui utilizator.

În cazul aplicațiilor web, backup-ul se realizează foarte simplu, deoarece datele se stochează automat.

Aplicațiile web pot fi rulate pe orice calculator care dispune de un browser web, deoarece prelucrarea datelor se face pe server și, din această cauză, necesarul de resurse ale dispozitivului pe care rulează sunt minime.

Datorită faptului că aplicațiile web rulează în browser este posibilă folosirea lor și pe alte dispozitive precum: tabletă și smartphone, deoarece acestea au încorporat un browser.

Dezavantajul îl reprezintă dificultatea sau chiar imposibilitatea de a realiza conexiunea cu hardware-ul local al clientului. Prin hardware se înțelege imprimantă, scanner etc.

Aspecte generale

Aplicațiile web sunt aplicații care rulează pe un server și care pot fi accesate cu ajutorul unui browser web de un număr nelimitat de clienți. Acestea pot fi folosite cu ușurință de către orice persoană fără pregătire tehnică de specialitate în domeniul tehnologiilor web.

O aplicație web constituie o colecție interconectată de pagini web care au conținut dinamic și care oferă utilizatorilor o funcționalitate specifică.

Interacțiunea dintre aplicație și utilizatorul acesteia are loc cu ajutorul unei interfețe Web.

Browserul utilizatorului trimite către server o cerere HTTP/HTTPS, iar acesta răspunde clientului prin cod HTML, CSS, JavaScript etc.

Caracterizare

Arhitectura unei aplicații web se bazează pe relația dintre client și server.

Importanța aplicațiilor web

O aplicație online poate fi accesată cu ajutorul unui browser web sau printr-o rețea locală, adică un Intranet. Cel mai mare avantaj este că poate fi utilizată de un număr infinit de persoane (utilizatori), fară a fi nevoie ca aplicația să fie instalată și configurată pe fiecare device.

Cu ajutorul unei asemenea aplicații se pot stoca, gestiona, modifica, primi, trimite și procesa informații, folosind conexiunea la Internet, folosind mai mulți ultilizatori, mai multe stații de lucru și mai multe procese în același timp. Datorită faptului că aplicația este bazată pe Internet nu există problema incompatibilității hardware, nu există viruși, aplicația și informațiile fiind stocate pe un server securizat.

Abordări. Etape în realizare

Consultanța

În cadrul etapei de consultanță se urmăresc următorii pași:

Se discută scopul pe care trebuie să îl indeplinească aplicația web

Se analizează resursele necesare aplicației

Se estimează durata necesară realizării și termenul limită de predare

Se face estimarea costului (în cazul în care aplicația urmează a fi vândută).

Stabilirea aspectelor generale

Se plătește o parte din valoarea proiectului

Se dezvoltă aplicația web.

Testarea

Se testează funcționalitatea produsului

Se validează codul sursă (HTML, CSS, JavaScript)

Se verifică funcționalitatea și aspectul aplicației în toate browserele majore.

Se verifică funcționalitatea și aspectul aplicației pe diferite dispozitive și diferite sisteme de operare pentru a testa comportamentul pe diverse rezoluții.

Optimizarea și promovarea

Se optimizează codul sursă, conținutul paginilor, imagini, GIF-uri etc.

Se creează o hartă a site-ului

Se optimizează structura internă a link-urilor.

Mentenanță și suport

Se asigură suport, mentenanță, se fac modificări în funcționalitatea aplicației, se actualizează date si conținuturi.

OBIECTIVE ȘI SPECIFICAȚII

Obiectivul principal al acestui proiect este crearea unei aplicații web pentru detecția discromatiei, bazându-se pe o serie de imagini divers colorate, cu numere, care trebuie citite și completate în căsuța corespunzătoare. Pentru realizarea aplicației web s-au avut în vedere următoarele:

Am implementat o pagină introductivă de unde se poate alege testul Ishihara, având în gând extensibilitatea aplicației prin introducerea altor teste pe viitor

Pentru testul propriu-zis am implementat un player de imagini cu capabillitatea de a introduce un răspuns și vizualiza imaginea anterioară și următoare

La sfârșitul testului se calculează un punctaj în funcție de raportul de răspunsuri corecte și greșite

Am implementat posibilitatea de a vizualiza unde au fost răspunsurile eronate

Usurința de accesare a site-ului printr-un server puternic și mereu în funcțiune

Abilitatea utilizatorilor de a se înregistra și astfel de a vizualiza rezultate anterioare la teste.

Pagina introductivă

Pagina introductivă a aplicației este pagina care trebuie să capteze atenția utilizatorului încă în prima secundă din care acesta ajunge pe ea. A fost construită cu conceptul de „responsive” în minte, astfel încât orice adăugiri ulterioare se vor putea integra cu usurință în acesta. Prin asta mă refer la teste care pot fi scrise în același fel în care este prezentat testul Ishihara pentru discromatie.

De asemenea, pagina introductivă prezintă un sumar al testului pentru ca utilizatorul să poata percepe toate înformațiile necesare acestuia încă de la prima vizualizare a paginii.

Se poate observa astfel că designul paginii introductive este unul foarte ușor de digerat și foarte minimalist, conform standardelor actuale de design al paginilor web și, nu în ultimul rând, cu multe componente ușor de identificat și utilizat. Acestea conferă paginii o credibilitate aparte și userilor un mediu curat și ușor de unde pot continua.

Player-ul de imagini

Player-ul de imagini este o metodă de a afișa toate imaginile din testul Ishihara într-o ordine anume. Utilizatorul poate apoi să spună ce număr vede în imaginea afișată și să treacă la întrebarea următoare. Astfel, player-ul se poate spune că este ca un „carusel” de imagini manevrat doar de utilizator.

Player-ul de imagini a trebuit să fie construit în așa fel, încât să respecte mai multe cerințe de bun simț. În primul rând, utilizatorul nu trebuie să aibă acces la următoarea întrebare până nu a răspuns la întrebarea curentă. În al doilea rând, utilizatorul nu trebuie să vadă dacă un răspuns de-al său a fost corect sau eronat, astfel neinfluențând rezultatul testului și adăugând un nou use-case, care se poate dovedi a fi de mare valoare aplicației și anume: abilitatea unui utilizator de a se întoarce la o întrebare anterioară și a-și vizualiza propriul răspuns la aceasta. Mai mult decât atât, fiind un test, care în mod normal merge destul de rapid, paginile trebuie să se încarce foarte repede, aproape instantaneu, pentru a putea conferi utilizatorului abilitatea de a completa testul într-un timp foate scurt. Acesta este și motivul pentru care am optat pentru o arhitectură tip SPA pentru a reduce timpul de încărcare a paginilor, ele fiind preîncărcate la începutul aplicației și doar imaginile propriu-zise fiind descărcate la schimbarea paginii (care apoi sunt puse în cache în caz că utilizatorul revine la o imagine).

Calcularea punctajului

La finalul testului, odată ce au fost introduse toate răspunsurile, se calculează un punctaj ca raport între răspunsurile greșite și cele corecte introduse de utilizator. Fiind un test static, răspunsurile sunt stocate într-un simplu vector uni-dimensional ca serii de caractere de unde pot fi aduse cu usurință la finalul testului pentru acest scop.

Utilizatorului îi este acordat un calificativ tip trecut/picat în funcție de rezultatul obținut în urma calculării punctajului. Algoritmul pentru calculare a punctajului este unul rudimentar. Se analizează toate răspunsurile utilizatorului, acestea fiind păstrate în memorie și se compară unul câte unul cu răspunsurile corecte din vectorul uni-dimensional care este alocat la rularea aplicației. Rezultatul este calculat pe măsură ce bucla își continuă executarea. Deși este un algoritm foarte simplu, acesta este scris în așa fel încât să poată fi extins dacă se vor adăuga alte teste sau metode pentru indentificarea problemelor vizuale.

Vizualizarea răspunsurilor eronate

Odată ce utilizatorului i-a fost afișat rezultatul testului, acesta poate vedea individual fiecare imagine împreună cu răspunsul pe care l-a dat acesta și răspunsul corect, acestea fiind indicate prin niște culori standard (verde pentru corect și rosu pentru eronat). Răspunsurile sunt stocate în memoria browser-ului pe timpul rulării aplicației, permițând astfel să avem această metodă de vizualizare a răspunsurilor, așa încât utilizatorii pot înțelege mai detaliat de unde ar putea apărea probleme de vizualizare a culorilor. Acest ultim pas, în care utilizatorului îi sunt prezentate răspunsurile corecte, împreună cu răspunsurile sale și imaginile, este din nou scris cu extensibilitatea în gând, astel încât se poate da câte un feedback individual pentru fiecare imagine în funcție de culorile pe care aceasta le-a avut. Totodată, o implementare de felul acesta, în care totul este stocat în memorie în niște structuri rudimentare, este concepută pentru a se putea cu usurință adăuga ulterior alte teste, nemaifiind necesară implementarea lor de la zero de fiecare dată, ci vor avea o bază solidă pe care să se poată construi.

Serverul

Cu o astfel de aplicație este foarte greu de estimat numărul de utilizatori care urmează să o acceseze și, pentru o experiență plăcută a utilizatorilor, ar trebui să reducem cât mai mult timpul de încărcare a paginilor, a aplicației propriu-zise, a scripturilor, a imaginilor și așa mai departe.

Astfel, am optat pentru Cloud9, care ne oferă un server foarte puternic cu 1GB RAM și memorie fizică SSD gratuită. De asemenea, avem un sistem de deployment foarte ușor și stabil, astfel încât putem oricând să adăugăm sau să modificăm ceva la aplicație fără prea mult chin și fără ca utilizatorii să fie afectați în vreun fel. Mai mult decât atât, toate resursele third-party folosite la realizarea aplicației sunt oferite direct de pe serverul nostru, astfel neavând mai multe origini pe care browser-ul trebuie să le acceseze, asta încă odată adăugând multă viteză aplicației per total.

Posibilitatea utilizatorilor de a se înregistra și de a vizualiza rezultate anterioare la teste

Pentru a putea accesa și completa testul de discromatie oferit de aplicație, utilizatorii trebuie să se înregistreze cu o adresă de e-mail și o parolă pentru a avea un cont propriu. Aceasta oferă utilizatorilor o experiență mai plăcută pe platformă, deoarece aceștia au posibilitatea de a-și înregistra rezultatele anterioare la teste pe care le pot apoi vizualiza ulterior. Toate acestea se fac fără a distrage utilizatorul de la activitatea sa principală în aplicația web, astfel fiind noninvazive.

Utilizatorii pot apoi compara rezultatele la teste cu rezultatele la teste similare sau rezultatele altor persoane pentru a putea deduce anumite caracteristici în legătură cu capabilitatea lor de a distinge culorile.

STUDIUL BIBLIOGRAFIC

HTML – HyperText Markup Language

HTML, adică HyperText Markup Language, este limbaj de tip markup, standard utilizat pentru a crea pagini web. Browserele web pot citi fișiere de tip HTML pe care le transformă în pagini web vizibile sau sonore.

HTML este un limbaj de tip markup mai degrabă decât un limbaj de programare, deoarece HTML descrie structura unui site web semantic, împreună cu indicii de prezentare.

HTML permite folosirea imaginillor și obiectelor care pot fi încorporate pentru a crea formulare interactive. Acest lucru oferă un mijloc de a crea documente structurate pentru text, titluri, paragrafe, liste, link-uri și alte elemente.

Limbajul este scris sub formă de elemente HTML constituite din tag-uri închise în paranteze unghiulare (ex. <html>). Browserele nu afișează tag-urile HTML, dar le folosesc pentru interpretarea conținutului paginii.

HTML poate încorpora scripturi scrise în limbaje precum JavaScript, cu ajutorul cărora se poate schimba aspectul paginii HTML. Browserele web pot avea totodată referire la cod de tip CSS (Cascading Style Sheets) pentru a defini aspectul și dispunerea textului și a altor elemente. World Wide Web Consortium (W3C), care sunt o organizație care impune standardele în web, încurajează folosirea CSS-ului cu precădere față de standardele HTML.

Fizicianul Tim-Berners-Lee, în 1980, care era antreprenor la CERN, a propus un prototip ENQUIRE, un sistem pentru cercetările CERN, care să fie folosit pentru a partaja documente. În 1989, Berners-Lee a scris o notă prin care propune un sistem hypertext bazat pe Internet. Berners-Lee a scris software-ul serverului și browser-ul în ultima perioadă a anilor 1990. În acel an, Berners-Lee și Robert Cailliau de la CERN au colaborat pentru o cerere de fonduri, dar proiectul lor a fost respins.

Primul document HTML a fost numit „HTML Tags„ și a fost menționat pe Internet de către Berners-Lee la sfârșitul anului 1991. Documentul descrie 18 elemente care cuprind proiectarea inițială, relativ simplă de HTML.

HTML este un limbaj de tip markup pe care browserele web îl interpretează pentru a arăta pagini web vizuale sau auditive. Caracteristicele implicite ale fiecărui element de tip HTML sunt definite în browser și aceste caracteristici pot fi modificate sau îmbunătățite prin utilizarea suplimentară a codului de tip CSS.

HTML a devenit un standard internațional (ISO/IEC 15445:2000). HTML 4.01 a fost publicat la finalul anului 1999 cu o erată publicată în 2001. În 2004 a început dezvoltarea la HTML5 care a devenit o acțiune comună împreună cu W3C în 2008, urmând să se standardizeze în 28 Octombrie 2014.

CSS – Cascading Style Sheet

Limbajul CSS este un limbaj de stilizare standard pentru formatarea elementelor unui document HTML. CSS-ul este folosit în Web Design-ul modern și este responsabil pentru stilizarea paginilor web. Este responsabil pentru culoarea literelor și a fundalului. De asemenea, poate stiliza și poziționarea elementelor de pe o pagină web.

CSS împreună cu HTML și JavaScript sunt o tehnologie de bază pe care majoritatea site-urilor o folosesc pentru a crea pagini dinamice și interfețe vizuale pentru multe aplicații web și aplicații mobile.

CSS este destinat, în primul rând, pentru a delimita conținutul documentului de modul de formatare al lui, cum ar fi aspectul, culorile și fonturile. Această separare poate îmbunătății accesabilitatea la conținut și oferă o flexibilitate mai mare și control în specificarea caracteristicilor de prezentare. Permite mai multor pagini HTML să partajeze specificațiile din documentul .css și reduce complexitatea sau repetiția unor bucăți de cod. CSS face posibilă separarea codului pentru stilizare de conținutul paginilor HTML. Pentru fiecare element de tip HTML, codul CSS poate impune o serie de specificații. De exemplu, o regulă CSS ar putea preciza faptul ca toate elementele din heading1 să fie îngroșate. Definirea stilurilor pentru o pagină se poate face, fie în partea de Head a documentului HTML, fie printr-un fișier extern .css care trebuie menționat tot în partea de head a paginii. Putem, de asemenea, să aplicăm un stil diferit în partea de Body a fișierului HTML, cu ajutorul unui fișier .css, la fiecare tag html în parte.

JavaScript

Conform [8], „Javascript este un limbaj de programare dinamic și interpretat la un înalt nivel. A fost standardizat în limbajul ECMAScript, alături de HTML și CSS și este una din cele 3 tehnologii esențiale ale World Wide Web pentru producerea de conținut. Majoritatea site-urilor web o aplică și este de asemenea suportată de toate browserele moderne fără nevoia de plugin-uri. JavaScript este bazat pe funcții de primă clasă, ceea ce îl face un limbaj cu paradigme multiple, care suportă un stil funcțional și imperativ de programare. Are un API pentru a lucra cu texte, vectori, date și expresii obișnuite, însă nu incude nicio operație I/O (Input/Output), cum ar fi: networking-ul, stocarea ori facilitatea grafică, bazându-se pe mediul gazdă în care este încapsulat.

În ciuda unor denumiri și a unor similitudini standard de bibliotecă, JavaScript și Java sunt în alte aspecte nerelaționate și au semantici foarte diferite. Sintaxa JavaScript este, de altfel, derivată din C, pe când semantica și design-ul sunt influențate de sine și de către schema limbajului de programare.

Javascript este, de asemenea, utilizat în medii care nu sunt bazate pe web, cum ar fi: documentele PDF, browsere specifice pe un site sau widget-uri. Pentru desktop, mașinile virtuale JavaScript mai noi și mai rapide (VMS) și platformele construite pe ele au crescut. De asemenea, a crescut popularitatea pentru JavaScript pentru aplicațiile web server-side. Pe partea de client, JavaScript a fost tradițional implementat ca și un limbaj interpretat, dar pe browserele mai noi performează “just in time”. Este, de asemenea, folosit în dezvoltarea jocurilor, crearea de aplicații pentru mobile și desktop și programare de rețea server-side cu medii de rulare, cum ar fi Node.js.

Javascript a fost inițial dezvoltat de Brendan Eich, în timp ce lucra pentru Netscape Communications Corporation. Într-adevăr, în timp ce concura cu Microsoft pentru adoptarea de către utilizatori a platformelor și tehnologiilor web, Netscape a considerat să ofere între client și server un sistem de operare cu o versiune portabilă a Sun Microsystems în care Java să ofere un mediu pe care se pot rula programe mici, deoarece Java era un competitor al C++ și țintea către programatori profesioniști. Netscape voia, de asemenea, un limbaj ușor de interpretat care să complementeze Java prin atragerea programatorilor neprofesioniști precum Microsoft Visual Basic.

Deși a fost dezvoltat sub numele Mocha, limbajul a fost oficial numit LiveScript atunci când a fost distribuit pentru prima dată în lansarea beta a Netscape Navigator 2.0 în Septembrie 1995, dar a fost rapid redenumit în JavaScript atunci când a fost lansat pe varianta 2.0B3 a browser-ului Netscape.

Schimbarea denumirii de la LiveScript la JavaScript coincide cu adăugarea suportului pentru tehnologie Java în browser-ul Netscape. Alegerea finală a denumirii a provocat confuzie, dând impresia că limbajul era o succesiune a limbajului de programare Java, și că alegerea a fost doar o stratagemă de marketing din partea Netscape pentru a da JavaScript-ului impresia a ceea ce se considera atunci un limbaj modern și atractiv de programare.

Este o concepție greșită, conform căreia limbajul JavaScript a fost influențat de către un limbaj de codare web mai timpuriu dezvoltat de către Nombas sub denumirea C–, a nu fi confundat cu C– de mai târziu, care o fost creat în 1997. Brendan Eich nu auzit niciodată de C– înainte să creeze LiveScript. Nombas a adus în discuție codarea paginilor web către Netscape, însă codarea de pagini web nu era un concept nou, așa cum arăta ViolaWWW. Nombas a trecut mai târziu în ofertă JavaScript în loc de C–. În produsul lor, ScriptEase, fiind parte a grupului TC39 care standardiza ECMAscript-ul.

Netscape a introdus implementarea limbajului pentru codarea paralelă cu Netscape Enterprise Server în Decembrie 1995, curând după lansarea browser-elor JavaScript. De la mijlocul anilor 2000 a apărut o reiterare ale implementării de JavaScript, precum Node.js.”

ES5 – ECMAScript

Conform [9], „ECMAScript este un limbaj de scripting marcă standardizată de ECMA International în ECMA-262 și ISO/IEC 16262. Implementările bine cunoscute ale limbii, cum ar fi JavaScript, JScript și ActionScript sunt utilizate pe scară largă pentru client-side scripting de pe web .

ECMAScript este o specificație standard al unui limbaj de scripting dezvoltat de Brendan Eich la Netscape. Inițial a fost numit Mocha, mai târziu LiveScript și, în final, JavaScript. În Decembrie 1995, Sun Microsystems și Netscape au anunțat lansarea JavaScript într-un comunicat de presă. În Martie 1996, Netscape Navigator 2.0 a fost lansat, oferind suport pentru JavaScript.

Datorită succesului pe scară largă a JavaScript-ului ca un limbaj de scripting client-side pentru pagini web, Microsoft a dezvoltat un dialect al limbii, numind-o JScript pentru a evita problemele de marcă. Jscript a adăugat noi metode pentru a atenua problema din anul 2000 provocată de metodele JavaScript, care au fost bazate pe clase de date Java. JScript a fost inclus în Internet Explorer 3.0, lansat în August 1996.

Netscape a livrat JavaScript pentru ECMA – Internațional pentru standardizare. A început în Noiembrie 1996 prima ediție a ECMA-262 și a fost adoptată de Adunarea Generală a ECMA din Iunie 1997. Mai multe ediții ale limbajului standard au fost publicate de atunci. Numele „ECMAScript” a fost un compromis între organizațiile implicate în standardizarea de limbaje, mai ales Netscape și Microsoft, a căror dispute au dominat sesiunile timpurii de standardizare. Eich a comentat că ECMAScript a fost întotdeauna un nume comercial nedorit care sună ca o boală de piele.

În timp ce, atât JavaScript și JScript țintesc să fie compatibile cu ECMAScript, ele oferă, de asemenea, caracteristici suplimentare care nu sunt descrise în caietul de sarcini ECMA.

Yahoo, Microsoft, Google și alți afiliați ai ediției a 4-a au format propriul lor subcomitet pentru a proiecta o actualizare pentru puțin ambițioasa ECMAScript 3, numită provizoriu ECMAScript 3.1. Această ediție se concentra pe actualizări de securitate și îmbunătățiri ale bibliotecii cu un accent mare pe compatibilitate. După luptele publice menționate anterior, echipele ECMAScript 3.1 și ECMAScript 4 au convenit asupra unui compromis: La cele 2 ediții se va lucra în paralel, cu coordonare între echipe pentru a se asigura că ECMAScript 3.1 rămâne un subset strict al ECMAScript 4, atât în semantică, cât și în sintaxă.

Cu toate acestea, filosofiile diferite din fiecare echipă au dus la rupturi repetate ale regulii de subset și a rămas îndoielnic faptul că echipa ECMAScript 3.1 va sprijini punerea în aplicare a ECMAScript 4. După mai mult de un an de la dezacordul asupra viitorului ECMAScript în cadrul Comitetului ECMA tehnic 39, cele două echipe au ajuns la un nou compromis în Iulie 2008: Brendan Eich a anunțat că ECMA TC39 se va concentra pe ECMAScript 3.1 (mai târziu redenumit ECMAScript, a 5-a ediție) cu colaborarea deplină a tuturor părților, iar vânzătorii ar trebui să vizeze cel puțin două implementări interoperabile până la începutul anului 2009. În Aprilie 2009, ECMA TC39 a publicat proiectul "final" a 5-a ediție și a anunțat că testarea implementării interoperabilității se aștepta să fie finalizată până la mijlocul lunii Iulie. La 3 Decembrie 2009, ECMA-262 5th Edition fost publicat.”

Protocoale folosite

HTTP – Hypertext Transfer Protocol

Conform [10], „Hypertext Transfer Protocol este un protocol de cerere pentru distribuire, prin sisteme colaborative a informațiilor hypermedia. HTTP este fundamentul de comunicații de date pentru World Wide Web.

Hypertext este text structurat care utilizează legături logice (hyperlink-uri) între noduri care conțin text. HTTP este un protocolul folosit pentru a schimba sau transfera hipertext.

Dezvoltarea standardelor HTTP a fost coordonată de către Internet Engineering Task Force și World Wide Web Consortium, culminând cu publicarea unei serii de solicitări de comentarii. Prima definiție a HTTP 1.1, versiunea de HTTP în uz comun, a avut loc în RFC 2068, în 1997, cu toate că acest lucru a fost subclasat de RFC 2616 în 1999.

HTTP funcționează ca protocol cerere-răspuns în modelul client-server. Un browser web, de exemplu, ar putea fi clientul și o aplicație care rulează pe un computer de găzduire a unui site web poate fi serverul. Clientul depune un mesaj de cerere HTTP la server. Serverul, care oferă resurse, cum ar fi fișiere HTML și alte tipuri de conținut sau exercită alte funcții în numele clientului, returnează un mesaj de răspuns la client. Răspunsul conține informații cu privire la starea cererii și poate conține, de asemenea, conținutul solicitat în corpul mesajului.

Un browser web este, spre exemplu, un agent utilizator. Alte tipuri de agenți utilizatori includ software-ul de indexare utilizat de către furnizori de căutare (web crawlers), browsere vocale, aplicații mobile și alte software-uri care accesează, consumă sau afișează conținut web.

HTTP este conceput pentru a permite elementelor să intermedieze prin rețea pentru a îmbunătăți sau a permite comunicarea între clienți și servere. Site-urile cu trafic mare de multe ori beneficiază de servere Web Cache care livrează conținutul de pe partea de servere din amonte pentru a îmbunătăți timpul de răspuns. Cache-ul Browserelor Web accesate anterior reutilizează resursele web atunci când este posibil, pentru a reduce traficul în rețea. Serverele HTTP proxy aflate la granițele rețelei private pot facilita comunicarea pentru clienți fără o adresă la nivel global rutabil, prin retransmiterea cu servere externe.

HTTP este o aplicare a unui protocol de strat proiectat în cadrul Internet Protocol Suite. Definiția acestuia presupune un protocol de strat de încredere pentru transportul de bază și Transmission Control Protocol este frecvent utilizat. Cu toate acestea, HTTP poate utiliza protocoale nesigure, cum ar fi User Datagram Protocol, folosit în servicii simple precum Discovery Protocol.

Resurse HTTP sunt identificate și situate pe rețea (URL-uri), folosind Uniform Resource Identifier. URI-urile și hyperlink-uri din Hypertext Markup Language formează documentele interconectate hipertext.

HTTP/1.1 este o revizuire a HTTP original (HTTP/1.0). În HTTP/1.0, o conexiune separată la același server se făcea pentru fiecare cerere de resurse. HTTP/1.1 poate reutiliza o conexiune de mai multe ori pentru a descărca imagini, script-uri, fișe de stilizare etc, după ce pagina a fost livrată.

Termenul Hypertext a fost inventat de Ted Nelson în 1965 în cadrul proiectului Xanadu, care a fost la rândul său, inspirat de viziunea lui Vannevar Bush (1930) bazată pe extragerea prin microfilme de informații și de gestionare a sistemului de "memex" descris în eseul său „Cum am putea gândi” (1945). Tim Berners-Lee și echipa sa de la CERN sunt acreditați cu inventarea originală a HTTP, împreună cu HTML și tehnologia asociată pentru un server web și un browser web bazat pe text. Berners-Lee a propus pentru prima dată proiectul WorldWideWeb în 1989 – acum cunoscut sub numele de World Wide Web. Prima versiune a protocolului a avut o singură metodă, și anume GET, care cerea o pagină de pe un server. Răspunsul de la server a fost întotdeauna o pagină HTML.

Prima versiune documentată a HTTP a fost v0.9 HTTP (1991). Dave Raggett a condus Grupul de lucru HTTP (HTTP WG) în 1995 și a vrut să extindă protocolul cu operațiuni extinse, negocieri extinse, mai bogate în meta-informații, legate cu un protocol de securitate care a devenit mai eficient prin adăugarea de metode suplimentare, câmpuri si anteturi. RFC 1945 a introdus oficial și a recunoscut HTTP v1.0 în 1996.

HTTP GL planificase să publice noi standarde în Decembrie 1995, precum și sprijinul pentru HTTP pre-standard de HTTP/1.1, bazat pe RFC 2068 aflat atunci în curs de dezvoltare (denumit HTTP-NG) a fost adoptată rapid de către majoritatea dezvoltatorilor de browser la începutul anului 1996. Prin Martie 1996, HTTP pre-standard de HTTP/1.1 a fost adoptat în Arena, Netscape 2.0, Netscape Navigator gold 2.01, Mosaic 2.7, Lynx 2.5 și în Internet Explorer 2.0. Adoptarea de către utilizatorul final al noilor browsere a fost rapidă. În Martie 1996, o companie de găzduire web a raportat că peste 40% din browserele aflate în uz pe Internet au fost HTTP 1.1 conforme. Aceeași companie de găzduire web a raportat că, până în Iunie 1996, 65% din toate browserele accesate au avut serverele HTTP/1.1 conforme. HTTP/1.1 standard, cum este definit în RFC 2068 a fost lansat oficial în Ianuarie 1997. Îmbunătățirile și actualizările pentru HTTP/1.1 standard s-au lansat sub RFC 2616 în Iunie 1999.

În 2007, a fost format Grupul de lucru HTTPbis, pentru a revizui și a clarifica specificațiile HTTP/1.1. În Iunie 2014, WG a lansat o actualizare a specificațiilor formată din șase părți, eliminând ca atare RFC 2616:

RFC 7230, HTTP/1.1: Sintaxa mesaj și rutare

RFC 7231, HTTP/1.1: Semantica și conținutul

RFC 7232, HTTP/1.1: Cereri Condiționate

RFC 7233, HTTP/1.1: Cereri de distanță

RFC 7234, HTTP/1.1: Caching

RFC 7235, HTTP/1.1: Autentificare

HTTP/2 a fost publicat ca RFC 7540 în Mai 2015.”

HTTPS – HyperText Transfer Protocol/Secure

Conform [11], „HTTPS, numit și HTTP peste TLS, HTTP peste SSL și HTTP Secure este un protocol pentru comunicații securizate pe o rețea de calculatoare, care este utilizat la scară largă pe Internet. HTTPS este format din comunicare peste Hypertext Transfer Protocol în cadrul unei conexiuni criptate, folosind ca mijloace de transport Layer Security sau predecesorul său, Secure Sockets Layer. Principala motivație pentru HTTPS este autentificarea pe site-ul vizitat și pentru a proteja intimitatea și integritatea datelor schimbate.

HTTPS, ca folos general, oferă autentificare pe paginile și serverele web asociate cu care comunică, protejând împotriva atacurilor „man-in-the-middle”. Mai mult decât atât, oferă și criptarea bidirecțională a comunicațiilor între un client și un server, care împiedică și protejează interceptarea, modificarea sau falsificarea conținutului comunicării. Acest lucru asigură o garanție rezonabilă asupra unei căi de comunicare cu site-ul cu care se intenționează să se comunice, impostorii fiind combatați. În plus, se asigură conținutul comunicațiilor între utilizator și site-uri care nu poate fi citit sau falsificat de către un terț.

La început, conexiunile HTTPS au fost utilizate pentru operațiunile de plată pe World Wide Web, e-mail și pentru tranzacțiile sensibile în sistemele de informații corporative. HTTPS a început să vadă utilizarea pe scară largă pentru a proteja autenticitatea pe pagină pentru toate tipurile de site-uri web, la sfârșitul anilor 2000 și începutul anilor 2010, asigurând și menținând conturile de utilizator folosite în comunicații, identitate și pentru navigarea web privată.

HTTPS Uniform Resource Identifier are sintaxă identică cu sistemul standard HTTP, în afară de simbol de sistem. Cu toate acestea, HTTPS semnaleză browser-ul să folosească un strat de criptare alcătuit prin adăugarea de SSL/TLS pentru a proteja traficul. SSL este potrivit în special pentru HTTP, deoarece aceasta poate oferi o anumită protecție chiar dacă numai o parte a comunicării este autentificată. Acesta este cazul cu tranzacțiile HTTP pe Internet, în cazul în care de obicei numai serverul este autentificat (de către clientul care examinează certificatului serverului).

HTTPS creează un canal securizat printr-o rețea nesigură. Acest lucru asigură o protecție rezonabilă față de infiltratori și atacuri ale intermediarilor, cu condiția ca un cifru adecvat să fie utilizat și că certificatul de server este verificat și de încredere.

Deoarece HTTPS transportă HTTP în întregime peste partea TLS, totalitatea protocolului HTTP de bază poate fi criptat. Aceasta include URL-ul cerere (pagina web care a fost solicitată), parametri de interogare, anteturile și cookie-urile (care conțin adesea informații despre identitatea utilizatorului). Cu toate acestea, pentru că gazda (site-ul), adresele și numerele sunt neapărat parte din protocoalele TCP/IP, HTTPS nu poate proteja divulgarea acestora. În practică, acest lucru înseamnă că, chiar pe un server web configurat corect, hackerul poate deduce adresa IP și portul numărului serverului de web (uneori chiar numele de domeniu, de exemplu www.example.org), dar nu și restul de URL.

Browserele web știu cum să aibă încredere în site-urile HTTPS bazate pe certificate autorizate care vin pre-instalate în software-ul lor. Certificatele autorizate, cum ar fi Symantec, Comodo, GeoTrust sunt în acest fel de încredere pentru creatorii browser-ului web, oferind astfel certificate valabile. Prin urmare, un utilizator ar trebui să aibă încredere într-o conexiune HTTPS cu un site web dacă și numai dacă toate caracteristicile următoare sunt adevărate:

Utilizatorul are încredere că software-ul browser-ului pune în aplicare în mod corect HTTPS cu certificatele autorizate corect preinstalate

Utilizatorul are încredere în autoritatea de certificare pentru a garanta doar pentru site-urile legitime

Site-ul oferă un certificat valabil, ceea ce înseamnă că a fost semnat de către o autoritate de încredere

Certificatul identificat în mod corect pe site (de exemplu, în cazul în care browser-ul viziteaza "https://example.com", certificatul primit este corect pentru "example.com" și nu pentru o altă entitate)

Utilizatorul are încredere că stratul de criptare a protocolului (TLS/SSL) este suficient de sigur împotriva hackerilor.

HTTPS este deosebit de important asupra rețelelor nesigure (cum ar fi puncte de acces WiFi publice), precum oricine de pe aceeași rețea locală poate descoperi informații sensibile care nu sunt protejate de HTTPS. În plus, multe retele WiFi gratuite/plătite se angajează în „injecție de pachete” cu scopul de a servi proprile pagini web ca anunțuri. Cu toate acestea, acest lucru poate fi exploatat cu rea intenție în mai multe moduri, cum ar fi injectarea malware pe paginile web și furtul de informații private.

HTTPS este, de asemenea, foarte important pentru conexiuni peste rețeaua anonimă Tor, deoarece noduri malware Tor pot deteriora sau modifica conținutul dacă trec prin ele într-un mod nesigur și pot astfel să injecteze malware în conexiune. Acesta este unul dintre motivele pentru care Electronic Frontier Foundation și proiectul Tor au început dezvoltarea HTTPS Everywhere, care este inclus în Tor Browser Bundle.

Pe măsură ce mai multe informații se descoperă despre supravegherea în masă la nivel mondial și hackerii produc furt de informații cu caracter personal, utilizarea de securitate HTTPS pe toate site-urile este din ce în ce mai importantă, indiferent de tipul de conexiune la Internet.În timp ce metadatele despre paginile vizitate individuale nu sunt sensibile, atunci când sunt combinate, ele pot dezvălui multe despre utilizator și compromite viața privată a acestuia.

Implementarea HTTPS permite, de asemenea, utilizarea SPDY, un protocol de rețea conceput pentru a reduce timpul de încărcare a paginii și scăderea latenței.

Se recomandă să utilizați HTTP Strict Transport Security (HSTS) cu HTTPS pentru a proteja utilizatorii de hackeri, mai ales de către SSL.

HTTPS nu ar trebui să fie confundat cu puțin utilizatul HTTP Secure (S-HTTP), specificat în RFC 2660.”

AJAX

AJAX (Javascript și XML) este un grup de tehnici interdependente de dezvoltare web utilizate pe partea de client pentru a crea aplicații web asincrone. Prin AJAX, aplicațiile web pot trimite și primi date de la server asincron fără a interfera cu interfața grafică sau cu comportamentul paginii active. Datele pot fi obținute utilizând obiecte de tipul XMLHttpRequest. În ciuda numelui, utilzarea XML nu este necesară (JSON este adesea utilizat), iar request-ul nu trebuie să fie neapărat asincron.

AJAX nu este o singură tehnologie, ci un grup de tehnologii. HTML și CSS pot fi utilizate în combinație pentru a formata informația. DOM-ul este accesat din Javascript pentru a afișa și pentru a da posibilitatea utilizatorului de a interacționa cu informația prezentată. Javascript și obiectele XMLHttpRequest oferă o metodă de a schimba date asincron între browser și server, evitând reîncărcarea paginii.

La începutul anilor 1990, cele mai multe site-uri Web s-au bazat pe pagini complete de HTML. Fiecare acțiune a utilizatorului necesită ca pagina să fie complet reîncărcată de la server. Acest proces a fost ineficient, așa cum este reflectat de experiența utilizatorului: tot conținutul paginii dispărea, apoi reapărea. De fiecare dată când browser-ul reîncărca o pagină pentru o schimbare parțială, tot conținutul trebuia să fie retrimis, chiar dacă doar o parte din informații s-au schimbat. Acest lucru a încărcat server-ul duplimentar și a utilizat excesiv lățimea de bandă.

În 1996, tag-ul iframe a fost introdus în Internet Explorer pentru a încărca sau descărca asincron conținut.

În 1998, echipa Microsoft Outlook Web App a implementat prima componentă XMLHTTP într-un script pe client.

În 1999, Microsoft a utilizat tehnologia iframe pentru a actualiza dinamic știri și cotații bursiere pe pagina de start a Internet Explorer și a creat controlul XMLHTTP ActiveX în Internet Explorer 5, care a fost adoptat ulterior de Mozilla, Safari, Opera și alte browsere ca obiect XMLHttpRequest JavaScript. Microsoft a adoptat modelul XMLHttpRequest nativ începând cu Internet Explorer 7. Versiunea ActiveX este încă suportată în Internet Explorer, dar nu și în Microsoft Edge. Utilitatea request-urilor HTTP spre server, ce rulează în background, și a tehnologiilor web asincrone a rămas destul de neclară până când a început să apară la scară largă aplicații online, cum ar fi Outlook Web App (2000) și Oddpost (2002).

Google a dezvoltat la scară largă standarde conforme, cross browser AJAX cu Gmail (2004) și Google Maps (2005). În octombrie 2004 lansarea publică Kayak.com beta publică a reprezentat una dintre primele utlizări pe scară largă în cadrul e-commerce a ceea ce dezvoltatorii lor au denumit-o la acel moment “the xml http thing“.

Termenul "Ajax" a fost declarat în mod public la 18 februarie 2005 de Jesse James Garrett într-un articol intitulat "Ajax: A New Approach to Web Applications”, bazat pe tehnicile folosite în cadrul paginilor Google.

La 5 aprilie 2006, Consorțiul World Wide Web (W3C) a lansat prima schiță a obiectului XMLHttpRequest în încercarea de a crea un standard Web oficial.

Termenul Ajax a ajuns să reprezinte un grup larg de tehnologii Web, care pot fi utilizate pentru a implementa o aplicație web ce comunică cu un server în background, fără a interfera cu starea curentă a paginii. În articolul care a adus pentru prima dată termenul Ajax, Jesse James Garrett a explicat că următoarele tehnologii sunt încorporate:

HTML (sau XHTML) și CSS pentru prezentare

Document Object Model (DOM) pentru afișarea dinamică a interacțiunii cu datele

XML pentru schimbul de date și XSLT pentru manipularea lor

Obiectul XMLHttpRequest pentru comunicare asincrone

JavaScript pentru a aduce aceste tehnologii împreună.

Totuși, de atunci au existat o serie de evoluții în tehnologiile utilizate într-o aplicație AJAX și definirea termenului AJAX. XML nu este necesar pentru schimbul de date și, prin urmare, XSLT nu este necesar pentru manipularea datelor. JavaScript Object Notation (JSON) este adesea folosit ca un format alternativ pentru schimbul de date, deși alte formate, cum ar fi HTML preformatat sau text simplu pot fi de asemenea utilizate.

HTML asincron și HTTP (AHAH) implică utilizarea XMLHttpRequest pentru a prelua fragmente (X)HTML, care sunt apoi introduse direct în pagina Web.

În cadrul browserelor pre-HTML5, paginile create dinamic utilizând request-uri AJAX succesive nu se salvau automat în istoricul browser-ului, astfel că apăsând butonul “înapoi” nu întorcea browser-ul la o stare anterioară a request-urilor AJAX din cadrul paginii active, ci întorcea spre ultima pagină vizitată și accesată printr-un request normal. Un astfel de comportament de navigare între pagini în schimbul navigării între stări ale paginilor poate fi dorit, dar în cazul în care este necesară o urmărire fină a stărilor, atunci o soluție pre-HTML5 a fost utilizarea iframe-urilor invizibile pentru a declanșa schimbări în istoricul browser-ului. O soluție implementată utilizând tehnici AJAX este de a schimba ancora URL-ului (partea de dupa “#”) atunci când o starea a unei pagini este schimbată printr-un request AJAX, apoi monitorizarea schimbărilor de același tip. HTML5 oferă un standard API extins pentru a lucra cu istoricul browserelor.

Actualizarea dinamică a paginilor web face de asemenea dificilă salvarea și întoarcerea spre o anumită stare a aplicației. Soluții la această problemă există, multe dintre ele utilizând tot ancora URL-ului. Soluția oferită de HTML5 pentru problema de mai sus, se aplică și aici. În funcție de natura aplicației AJAX, actualizările dinamice ale paginii pot întrerupe interacțiunile utilizatorilor, mai ales în cazul în care conexiunea la internet este slabă. De exemplu, editarea unui câmp de căutare poate declanșa o interogare către server pentru auto completare, dar utilizatorul s-ar putea să nu observe acest comportament, în cazul unei conexiuni slabe, din cauză că sugestiile pot apărea cu întârziere, atunci când utilizatorul a inițiat deja o altă acțiune. Excluzând Google, majoritatea crawler-elor web nu execută cod Javascript, astfel că pentru a fi indexată de motoarele de căutare, aplicația web trebuie să ofere o alternativă înspre accesarea conținutului ce este în mod normal adus prin AJAX. S-a sugerat faptul că un browser fără interfață poate fi utilizat pentru a indexa conținutul furnizat de site-urile web ce folosesc AJAX.

Orice utilizator al cărui browser nu suportă Javascript sau XMLHttpRequest, sau are aceste funcționalități dezactivate, nu va putea utiliza în mod corespunzător paginile ce depind de AJAX. Dispozitive cum ar fi smartphone-urile sau PDA-urile s-ar putea să nu suporte tehnologiile necesare, chiar dacă acest lucru devine tot mai puțin o problemă. Singura modalitate prin care se poate oferi funcționalitatea completă utilizatorului este de a folosi tehnicile anterioare non-Javascript. Acest lucru poate fi obținut dacă se asigură că link-urile și form-urile funcționează corect și în lipsa suportului AJAX.

Similar, unele aplicații web ce folosesc AJAX sunt construite într-un mod în care tehnologiile de scanare a ecranului (screen-reading), cum ar fi JAWS, nu pot citi. Standardele WAI-ARIA oferă un mod prin care se furnizează anumite sugestii în cazuri de genul.

Cititoarele de ecrane au posibilitatea de a utiliza AJAX, însă nu pot citi corespunzător conținutul generat dinamic.

Politica aceleiași origini previne unele tehnici AJAX de a fi utilizate între domenii diferite, în ciuda faptului că W3C are în vedere autorizarea acestei funcționalități. Modalități de a ocoli această caracteristică de securitate există prin utilizarea unui canal special (Cross Domain Communications) încorporat într-un iframe din pagină, sau prin utilizarea JSONP.

Stilul de programare asincron ce folosește funcții de tip callback necesar, poate duce înspre cod sursă complex, greu de menținut, depanat și testat.

ANALIZĂ ȘI PROIECTARE

Pentru implementarea aplicației web pentru detecție a discromatiei am luat în calcul următoarele mari puncte după care am structurat proiectul:

Implementarea arhitecturii generale și a modelelor cu extensibilitate în gând

Implementarea testului Ishihara de detecție a discromatiei

Conexiunea client-server

Testul Ishihara constă în prezentarea unei serii de imagini în formă de cerc compuse din cercuri mai mici de diferite culori. În fiecare din aceste imagini se pot distinge una sau mai multe cifre de o culoare, având restul cercurilor mici de o altă culoare. Astfel, o persoană fără probleme de discromatie poate vedea cu usurință cifrele ascunse în imagini, iar persoanele care prezintă unele semne de discromatie vor avea probleme la unele sau chiar toate imaginile prezentate. In principal, se pot observa cu ușurință dificultăți în distingerea culorilor roșu și verde și semne ale daltonismului.

Testul Ishihara la origini consta din 38 sau 24 de imagini, dar semnele discromatiei se pot observa din mai puține imagini cheie ale testului. Testul a fost creat de Dr. Shinobu Ishihara în timpul Primului Război Mondial pentru o detecție mai ușoară a problemelor de vedere a culorilor, decât ce se folosea la timpul acela.

Pentru implementarea unui test de acest tip am luat în calcul faptul că utilizatorul trebuie să primească o serie de imagini într-o ordine anume cu un anume progres și să încerce să spună ce cifră sau numere vede în fiecare dintre imagini.

Astfel, odată intrat în test, utilizatorul are de urmat niște pași liniari pentru completarea acestuia și analiza rezultatului:

Se afișează rând pe rând fiecare imagine într-o dimensiune foarte vizibilă pe centrul ecranului

Sub imagine se prezintă un camp unde se poate introduce una sau mai multe cifre ca răspuns la pasul curent

Odată introdus un răspuns, utilizatorul se mai poate gândi dacă acesta este răspunsul final, confirmându-l

Utilizatorul poate mai apoi să treacă la următoare imagine

A se nota că utilizatorul nu poate sări peste imagini și nu poate trece la imaginea urmatoare până când nu a confirmat un răspuns la imaginea curentă. Mai în detaliu despre asta în capitolul următor unde se vorbește despre implementarea propriu-zisă

La finalul imaginilor, utilizatorul își vede rezultatul la testul de detectare a discromatiei

Utilizatorului îi este prezentată apoi o detaliere a răspunsurilor sale, având la dispoziție uneltele necesare pentru a vizualiza imaginile din nou împreună cu răspunsurile corecte și cele date de el, cu niște culori standard care marchează răspunsuri corecte respectiv greșite.

Din start această aplicație a fost construită cu gândul la extensibilitate. Astfel, arhitectura generală este una rudimentară și modelele folosite sunt unele foarte generice. În felul acesta va fi foarte ușor pe viitor să se adauge alte teste de detectare a problemelor vizuale sau chiar extinderea cu noi funcționalități a testelor curent.

Pe pagina de start a aplicației este afișat testul Ishihara și o mică descriere și un preview al său. Pagina aceasta este construită în așa fel, încât oricâte teste ar fi aici să poată fi afișate într-un mod optim și „responsive”.

Baza de date aferentă aplicației conține două modele care sunt responsabile cu stocarea tuturor datelor necesare. La fel, menționez extensibilitatea și aici și de aceea am ales o bază de date NoSQL, pentru ca modele să poată fi editate sau extinse oricând. Nu mă refer doar la modelul de utilizator, ci mai degrabă la modelul care este responsabil pentru stocarea rezultatelor. Avantajul unei baze de date NoSQL este faptul că mai multe teste ar putea folosi același model, având în vedere că un test ar putea să aibă niște rezultate total diferite decât altul. Astfel modelele folosite sunt următoarele:

User

username: string – numele unic al unui utilizator cu care acesta își creează contul și se poate autentifica

password: base64 – parola unui utilizator

name: string – numele real al unui utilizator

admin: Boolean – identificator prin care știm dacă un utilizator este de tip admin sau nu.

Result

test: string – numele testul aferent rezultatului

passed: Boolean – o valoare de tip adevărat/fals care indică dacă testul a fost trecut sau nu

user: ObjecId – o referință la id-ul unui utilizator, cel de la care este înregistrat rezultatul

created_at: Date – data creării rezultatului

updated_at: Date – data ultimei modificări a rezultatului.

Ambele modele au desigur și un ID unic după care este indexată colecția respectivă de intrări.

Pentru ușurința de implementare, ambele modele au fost extinse cu o funcție care caută în baza de date o intrare cu un id exact. Mai multe despre aceasta în capitolul următor, aferent implementării.

După cum se observă, arhitectura este una foarte rudimentară. Modelul User se referă la fiecare utilizator unic care se înregistrează pentru testul de discromatie, iar modelul Result este folosit pentru a stoca toate rezultatele la teste a tuturor utilizatorilor. În felul acesta, totul este generic construit astfel încât adăugarea de teste sau de atribute este foarte ușoară și cu plăcere acceptată de aplicație. Mai mult decât atât, modelul folosit pentru rezultate este atât de generic gândit încât este foarte ușor să fie extins pentru niște teste total diferite prin simpla adăugare a unor atribute pe model (încă odată avantajul folosirii NoSQL în cazul acestei aplicații).

Conexiunea client-server este una standard. Serverul ascultă constant pe portul 3000 pentru oricine i-ar putea trimite o cerere. Nu este setat un header de „Cross-Origin” pe server, de aceea se vor putea primi doar cereri făcute de pe aceeași origine. Clientul, browserul, trimite cereri la server, iar acesta răspunde într-un standard modern impus de W3C, folosind coduri. De asemenea, toate incodările și decodările făcute pentru comunicarea client-server sunt de tip JSON, ceea ce este benefic și din punct de vedere al vitezei serverului și al încărcăturii, dar și din punct de vedere al limbajului de programare folosit pentru care JSON este o structură nativă. Alte astfel de structuri mai puțin benefice ar fi fost: XML, SOAP sau FormData impus de Mozilla. De asemenea, se mai stabilește o conexiune de același tip între serverul propriu-zis și baza de date.

Baza de date își deschide, la rândul ei, un server care ascultă pe portul 27017 orice cerere de la server ar primi, fie ea de scriere, citire sau ambele. Prin această arhitectură formată din trei componente: baza de date, server și client obținem ceva destul de rudimentar la bază, dar cu o scalabilitate enormă.

De asemenea, a se menționa că și baza de date și server-ul rulează pe același server fizic, astfel făcând orice comunicare cu baza de date foarte rapidă din nou cu gândul la utilizator și făcând experiența sa cât mai fluidă și mai cursivă posibil.

Scalabilitatea este una din cele mai mari probleme în arhitecturile curente ale aplicațiilor web, de aceea construind o aplicație scalabilă din start, chiar dacă la o scară mai mică pentru început este o practică foarte bună și rar adoptată de multe produse actuale pe Internet, ceea ce mai devreme sau mai târziu aduce un avantaj foarte mare aplicației propuse.

IMPLEMENTAREA

Instrumente și prezentarea aplicației

Pentru realizarea aplicației web de detectare a discromatiei s-au folosit mai multe instrumente principale și mai multe biblioteci și framework-uri.

Instrumentul principal de dezvolate folosit care este și mediul de lucru a fost platforma Cloud9 (https://c9.io) care ne dă acces la mai multe beneficii. Prin ea obținem un mediu de lucru integrat care conține un editor de text, un explorer de fișiere, unul sau mai multe ferestre de linie de comandă pentru execuție, un browser unde se poate testa în timp real aplicația și, nu în ultimul rând, un sistem de deployment în timp real care face aplicaîia publică la fiecare modificare a ei. Server-ul oferit în mod gratuit de platforma Cloud9 este un server cu sistem de operare Ubuntu Server cu o memorie de 1GB RAM și un spațiu de stocare de 1GB SSD. Aceste specificații sunt mai mult decât de ajuns pentru o aplicație precum cea prezentată.

În continuare, voi prezenta pe rând fiecare dintre instrumentele oferite de platforma Cloud9 și cum au fost folosite în cadrul proiectului.

Editorul de text este fereastra principală a platformei Cloud9 aflată chiar în mijlocul acesteia. Acesta este locul unde vom edita tot codul aplicației, indiferent de limbajul de programare. Editorul este de tip "Tabbed", ceea ce înseamnă că mai multe fișiere pot fi deschise în același timp după cum se observă în Figura 5.1. Mediul de lucru este foarte asemănător cu unul dintre cele mai cunoscute editoare de text folosite în dezvoltarea de aplicații web: Sublime Text.

Exploratorul de fișiere din dreapta editorului de text este asemănător cu alți exploratori de fișiere, fie ele din editoare de text sau din medii de lucru tip IDE. El poate fi vizualizat în Figura 5.2.

Voi prezenta în continuare structura de fișiere asociată cu aplicația web.

Toată aplicația este moștenită din directorul de bază numit "checkme", care este și numele propriu-zis al aplicației prezentate. În acest director avem câteva fișiere de bază ale proiectului.

Fișierul "README.md" este o mică documentație a proiectului, acesta fiind open-source.

Fișierul "mongod" este un script auto generat care pornește serverul bazei de date, care urmează să asculte pe portul 27017 pentru orice cerere primită.

Fișierele "bower.json" și "package.json" sunt fișierele de dependințe, Bower fiind package manager-ul folosit pentru toate dependințele aplicației client, iar NPM fiind package manager-ul folosit pentru toate dependințele server-ului. În Figura 5.3 și Figura 5.4 se pot observa conținuturile fișierelor "bower.json" și "package.json" respectiv.

În rădăcina proiectului mai putem observa fișierul "server.js" care este punctul de intrare propriu-zis al aplicației server. Mai multe despre acest fișier voi prezenta mai târziu.

Directorul "node_modules" este directorul în care sunt aduse toate dependințele server-ului de către NPM.

Directorul "data" conține baza de date propriu-zisă, care este ținută local pentru o viteză de răspuns mai mare.

Directorul "models" conține modelele propriu-zise ale aplicației server. Acestea vor fi prezentate în detaliu mai târziu.

Directorul "controllers" conține toată logica aplicației server. Fișierele din acest director vor fi prezentate în detaliu mai târziu.

În directorul "client" putem regăsi tot ce ține de aplicația client. Acesta este directorul făcut public utilizatorilor prin browsere. El este structurat după cum urmează:

Fișierul "client/index.html" este pagina de start și principalul punct de intrare a aplicației client. Pe orice pagină se navighează de pe un browser, acesta este primul fișier cerut de la server.

Fișierul "client/app.js" este punctul de intrare a logicii aplicației client. Aici se inițializează framework-ul AngularJS.

Fișierul "client/config.js" este fișierul unde se configurează framework-ul AngularJS. Mai multe detalii despre acest fișier vor fi prezentate mai târziu.

Directorul "client/assets" conține toate fișierele statice necesitate de client. Asta include atât imagini, cât și fișiere de tip CSS.

Directorul "client/templates" conține toate fișierele de tip HTML ale aplicației, mai puțin fișierul de intrare "client/index.html".

Directorul "client/services" conține servicii și microservicii ale aplicației.

Directorul "client/lib" conține toate dependințele de client ale proiectului. Asta include atât framework-ul principal, AngularJS, cât și alte dependințe care sunt folosite în cadrul aplicației.

Directorul "client/filters" conține filtre folosite de AngularJS.

Directorul "client/directives" conține directive folosite de AngularJS.

Directorul "client/controllers" conține controllere folosite de AngularJS. Aici putem regăsi aproape toată logica aplicației client.

În partea de jos a mediului de lucru găsim încă o structură tip "Tabbed", de data aceasta cu linii de comandă. Aici vom rula toate comenzile necesare pentru rularea aplicației, cât și pentru debugging, conform Figurii 5.5. Mai multe detalii despre comenzile necesare aplicației vor fi prezentate ulterior.

Deși Cloud9 ne oferă un browser integrat unde putem vedea aplicația, datorită sistemului de deployment în timp real, care face deploy pe un server public la fiecare modificare, este mult mai ușor să testăm și să observăm aplicația într-un browser nativ, motiv pentru care am folosit Google Chrome. Un alt motiv pentru această alegere sunt, desigur, modalitățile de debugging oferite de browserul Google Chrome, cunoscute sub numele de Chrome Dev Tools. Aceste modalități facilitează atât debugging-ul codului Javascript de pe aplicația client, cât și stilizarea paginilor în timp real sau emularea dispozitivelor mobile.

Diagrama use-case a aplicației este prezentată în Figura 5.6. În continuare voi prezenta pe rând fiecare funcționalitate a aplicației, împreună cu arhitectura din spate și modalități de utilizare.

Aplicația web este împărțită în două mari părți. Partea care rulează pe server sau "back-end" și partea care rulează în browser-ul utilizatorului sau "front-end".

Back-end

Partea de server a aplicației este scrisă, folosind două framework-uri mari. NodeJS care este un framework pentru server, folosind cod JavaScript. Acest framework a prins mare amploare în ultimii 2 ani, realizând performanțe uimitoare comparativ cu alte limbaje de programare. Celălalt framework folosit este ExpressJS, care este folosit pentru rutarea de server și API-ul propriu-zis. Baza de date fiind MongoDB din motive prezentate anterior, am ales să folosesc un ORM peste aceasta, facilitând felul în care sunt făcute toate interogările și comunicările cu baza de date. ORM-ul folosit este Mongoose și este special construit să funcționeze în conjuncție cu NodeJS.

Am optat pentru NodeJS în primul rând datorită performanței, dar și datorită beneficiilor în termeni de scalabilitate și extensibilitate pe care le prezintă framework-ul. În plus de asta, totul este foarte bine documentat și comunitatea este foarte mare, desi se prezintă totuși ca un mediu de dezvoltare foarte nou față de altele care sunt printre noi de zeci de ani.

Așadar, voi începe în primul rând, cu instrucțiunile de rulare ale aplicației într-un mediu local.

Folosind Cloud9, tot ce trebuie să faceți este să folosiți terminalul din partea de jos a ferestrei, prezentat în Figura 5.5, navigând în directorul rădăcină al proiectului, folosind comenzi de UNIX precum "cd". Odată ajunși aici, rulați „./mongod„ pentru a porni serverul bazei de date. Apoi rulați "npm install" și "bower install" pentru a aduce local toate dependințele serverului și ale aplicației client. Odată ce descărcarea s-a finalizat, puteți rula "node server.js" pentru a rula server-ul. Deployment-ul pe un mediu public se face automat, așadar din acest moment putem naviga pe "https://checkme-ioanapaula.c9.io" pentru a vizualiza aplicația.

Așadar, putem observa că punctul de intrare al aplicației este fișierul numit "server.js". Voi prezenta în continuare mai în detaliu conținutul fișierului și arhitectura din spatele său.

Prima parte a fișierului este constituită din importarea dependințelor server-ului pentru a putea fi folosite în continuare. Acest lucru este făcut folosind metoda "require" (conform Figurii 5.6), care este nativă în NodeJS, dar defapt vine din biblioteca RequireJS. Folosind "require", toate metodele și variabilele publice ale bibliotecii respective sunt un lucru foarte convenient pentru noi. Liniile de cod care importă toate dependințele pot fi observate în Figura 5.7.

Următoarea parte, prezentată în Figura 5.7, este configurarea framework-ului ExpressJS să folosească "body-parser" și "method-override" pentru crearea unui API de tip JSON.

Linia de cod din Figura 5.8 îi spune server-ului unde este locația bazei de date pentru a se conecta la ea. Conexiunea aceasta este stabilită prin intermediului ORM-ului "Mongoose". A se observa că URL-ul bazei de date începe cu protocolul "mongodb://". Acesta este protocolul definit de către baza de date MongoDB și practic stabilește o conexiune persistentă cu baza de date din momentul rulării.

Figura 5.9 prezintă următoarele linii din fișierul "server.js". Practic, se aduc doar niște referințe la modelele și controllere definite de către aplicație. Mai în detaliu despre acestea în paragrafele următoare.

Pentru autentificarea și înregistrarea utilizatorilor am folosit "Passport", după cum se vede în Figura 5.10. Passport este un sistem întreg de autentificare integrat cu NodeJS și MongoDB care ne permite tot ce înseamnă autentificare, tokeni și sesiunea unui utilizator doar prin câteva comenzi. Practic, tot ce trebuie să facem odată ce Passport a fost adăugat în "package.json" ca dependința și adus, folosind "npm install", este să obținem, folosind "require" o referință la obiectul exportat de Passport, iar apoi acestuia îi putem da modelul de bază de date al colecției în care stocăm utilizatorii și el se va ocupa de restul. Așadar, eu folosesc modelul "User" pentru utilizatori, iar în aceste trei linii îi spunem lui Passport că dorim să creăm o strategie de autentifiare și că, pentru serializarea și deserializarea unui utilizator, vom folosi niste metode custom din cadrul modelului "User", decât metodele standard care ne sunt prezentate de Passport.

În următoarele linii din fișierul "server.js", și anume cele care sunt prezentate în Figura 5.11, ne definim rutele aplicației, folosind framework-ul ExpressJS de rutare. Rutarea paginilor propriu-zisă o vom face în aplicația rulată de client, așadar avem o singură ruta de pagina și anume ultima din Figura 5.11, care spune că la ruta „/”, adică pe rădăcina aplicației, server-ul trebuie să răspundă cu fișierul "index.html" care este practic fișierul de intrare pentru aplicația client.

Restul rutelor definite aici sunt rutele de API. Așadar, avem următoarele endpoint-uri pe API:

– GET /v1/users

– POST /v1/users

– GET /v1/users/:userId

– PUT /v1/users/:userId

– DELETE /v1/users/:userId

– GET /v1/results

– POST /v1/results

– GET /v1/results/:resultId

– PUT /v1/results/:resultId

– DELETE /v1/results/:resultId

– POST /v1/session

– POST /v1/session/create

Putem observa că unele rute conțin un parametru precedat de simbolul „:”. Acesta denomină o rută dinamică care conține un parametru. Rutele fiind scrise după paradigma REST, parametrul respectiv se referă la un ID unic indexat în baza de date. Parametrii sunt definiți în continuarea rutelor, așadar avem doi parametri în cazul nostru:

– userId

– resultId

La finalul fișierului îi spunem server-ului să asculte pentru cereri pe portul 3000, folosind obiectul și metoda nativă „server.listen()” (Figura 5.12).

Baza de date fiind de tip NoSQL, nu trebuie neapărat să definim o structură a colecțiilor, ci putem să lăsăm totul să fie dinamic. Cu toate acestea, e mult mai benefic să avem niște structuri a colecțiilor definite pentru ca baza de date să fie ușor extinsă și înțeleasă de viitori developeri pe aplicație. Pentru asta, în directorul "models" avem două fișiere "results.js" și "users.js" care corespund celor două modele "Result". respectiv "User". Folosind Mongoose, definirea modelelor este foarte ușoară, făcându-se într-o structură de tip obiect Javascript și este foarte lizibilă. Aici se definesc și anumite constrângeri pe baza de date, precum validări sau tipuri de câmpuri. În figurile 5.13 și 5.14 putem vedea definiția modelelor User, respectiv Result și putem observa că atributele definite sunt ușor lizibile, chiar și de o persoană fără tangențe cu MongoDB sau programare de fel.

Singurul lucru aparte pe care îl putem observa este în modelul de User unde este definită și schema de înregistrare și autentificare pentru user-ul respectiv. A se nota că, deși atributele "username" și "password" nu sunt definite explicit, acestea sunt create ulterior de către Passport care se ocupă de toată autentificarea. Putem observa integrarea modelului User cu Passport în Figura 5.15.

Observăm cu toate acestea că niciuna dintre colecții nu are câmpul id. Asta este din cauza faptului că MongoDB crează automat coloana id pentru orice colecție și indexează după ea, așadar definirea acesteia explicită nu își are rostul. Singurul scop în definirea coloanei ar fi dacă am vrea niște coloane codificate în alt fel decât standardul MongoDB sau dacă am vrea să facem indexarea standard după altă coloană, nu după id. În cazul de față am fi putut face indexarea tabelei de utilizator după "username" care este unic, dar MongoDB ne recomandă să lăsăm indexarea standard să fie făcută după id pentru consistența între diferite colecții din baza de date și pentru o indexare mai performantă și integritate cu versiuni mai noi de MongoDB sau Mongoose.

Am ales să folosesc un model destul de apropiat de standard-ul MVC. În cazul nostru V este toată aplicația client, M sunt modelele de bază de date prezentate anterior. Așadar, urmează C sau controllerele. Am ales să definesc toate rutele în "server.js", dar cu toate acestea, fiecărei rute i-am asignat o metodă individuală care se ocupă de ea. Așadar, toate aceste metode, sau cu alte cuvinte toată logica aplicației server se află practic în controllere, trei la număr, care pot fi găsite în directorul "controllers".

Avem așadar trei controllere:

– session.js

– user.js

– result.js

user.js și result.js se ocupă fiecare de modelul atașat, User respectiv Result comunicând constant cu baza de date printr-o paradigma REST. Controller-ul session este asociat cu partea de care se ocupă Passport sau mai în detaliu, se ocupă de tot ce ține de autentificare, mai exact înregistrarea și logarea utilizatorilor în aplicație. Așadar, în acest controller regăsim două metode publice "register" și "create".

Metoda "register" prezentată în Figura 5.16 se ocupă de înregistrarea unui utilizator nou. Această metodă este invocată, accesând endpoint-ul /v1/session/create cu o cerere de tip POST care trebuie să conțină un username și o parolă. În cazul în care username-ul există deja sau ceva nu merge bine, server-ul va răspunde cu codul status 500 și cu mesajul "Cannot register user".

Figura 5.17 ne prezintă metoda „create”, care este metoda invocată de către endpoint-ul /v1/session cu o cerere de tip POST. Această metodă este puțin mai complicată la bază și se ocupă de autentificarea propriu-zisă a utilizatorilor în aplicația web. Ce se întâmplă practic este că se folosește obiectul User, care este o referință la model, deoarece folosim Mongoose, putem face interogări native MongoDB. Așadar, se apelează funcția "findOne" care aduce prima intrare în baza de date care satisface cerința și se caută primul utilizator cu username-ul oferit de cererea de autentificare. În cazul în care acesta nu a fost găsit se returnează codul status 500 și mesajul "Invalid username or password". Odată găsit utilizatorul, se invocă metoda „authenticate”, care este o metodă expusă de Passport care verifică parola din cerere cu parola din baza de date. A se nota că parola din baza de date nu se decodează niciodată, deoarece Passport foloseste un algoritm de "One-way hashing" prin care parolele, deși au un hash și un salt, ele nu pot fi decodate. În cazul în care parola este incorectă, server-ul returnează codul de status 500 și mesajul "Email or password invalid". Dacă parola este corectă, în răspuns, server-ul va atașa codul 200 implicit și toate datele din bază ale utilizatorului respectiv (cu excepția parolei, evident).

În continuare voi prezenta controllere "result.js" și "user.js" care aparțin de modelele din baza de date Result respectiv User. Deoarece controllerele și rutele sunt construite după paradigma REST, ele două sunt aproape identice, având fiecare câte șase metode, cinci dintre ele aparținând rutelor din AP, iar una aparținând parametrului dinamic al rutelor. De aceea, voi prezenta doar unul dintre controllere, și anume controller-ul "user.js", deoarece codul este aproape la fel pentru controllerul "result.js".

Metoda "user" prezentată în Figura 5.18 se folosește în cadrul rutelor cu parametru dinamic. Ce se întâmplă este că se apelează metoda "load" definită în cadrul modelului User, care caută un utilizator după id. În cazul în care utilizatorul nu este găsit în baza de date, se returnează o eroare pentru a se ști că ruta respectivă nu este validă. În cazul în care utilizatorul este găsit, se atașează obiectul cu datele sale la cererea făcută la server și apoi execția continuă. Astfel, când execuția va ajunge la una dintre metodele apelate printr-o rută cu parametru dinamic, utilizatorul va fi deja atașat cererii și se va putea lucra cu el în continuare.

Metoda "show" din controller-ul "users.js" (prezentată în Figura 5.19) este invocată în cadrul rutei "/v1/users/:userId" printr-o cerere de tip GET. Metoda doar ia utilizatorul atașat de metoda "user" la cerere și îl intoarce client-ului. A se nota că parola (hash și salt) nu sunt întoarse niciodată client-ului. MongoDB se ocupă, știind singur să nu întoarcă aceste atribute în cadrul unor interogări simple. Așadar, dacă facem o cerere tip GET pe "/v1/users/fewoih323g09h" vom primi înapoi datele utilizatorului cu id-ul fewoih323g09h. A se observa că la toate cererile pe API, se trimite un cod status în cazul erorilor, dar nimic în cazul în care totul merge bine. Asta este pentru că ExpressJS se ocupă să trimită 200 de fiecare dată când o metodă este invocată fără eroare.

Metoda „destroy”, prezentată în Figura 5.20, se ocupă de ștergerea unui utilizator. Se ia utilizatorul din cerere, unde a fost pus de către metoda "user" apelată anterior și se încearcă ștergerea sa din baza de date. În cazul în care ștergerea eșuează, se întoarce codul status 500 și mesajul de eroare „Cannot delete user”. În caz contrar, utilizatorul este șters din baza de date și întors client-ului pentru computări ulterioare.

În Figura 5.21 observăm metoda „update” din controllerul „users.js”. Această metodă este invocată odată cu apelarea endpoint-ului "/v1/users/:userId" cu o cerere de tip PUT. Aici putem observa ceva nou față de metodele anterioare și anume variabila „_”. Aceasta este de fapt o referință la o bibliotecă numită "lodash", una dintre cele mai mari biblioteci de helpere de Javascript. Folosim metoda „extent” de la lodash care practic compară utilizatorul pe care îl avem deja în baza de date, cu utilizatorul nou și modifică doar unde trebuie. Astfel, dacă vrem să modificăm username-ul unui utilizator, tot ce trebuie să facem este să trimitem un obiect cu noul username. Acesta se va schimba, iar restul atributelor vor rămâne nemodificate. Odată schimbat utilizatorul, încercăm prin metoda "save" nativă MongoDB să îl salvăm înapoi în baza de date. În cazul în care salvarea eșuează, se trimite codul de status 500 și mesajul de eroare „Cannot update user”, iar în cazul în care totul a mers bine se va trimite înapoi client-ului utilizatorul cu modificările făcute.

Metoda „all”, prezentată în Figura 5.22, este invocată odată cu apelarea endpoint-ului „/v1/users” cu o cerere de tip GET. Metoda apelează la rândul ei metoda „find”, o metodă din Mongoose care dedesubt apelează „find”-ul nativ MongoDB. Metoda „find” aduce toate intrările în baza de date care satisfac una sau mai multe condiții, dar pentru că în acest caz nu dăm nicio condiție, se vor returna pur și simplu toți utilizatorii din baza de date într-o structură de tip vector uni-dimensional de obiecte Javascript (în cazul în care colecția de utilizatori este goală se întoarce un vector gol). Dacă metoda eșuează se va întoarce codul de status 500 împreună cu mesajul de eroare „Cannot list users”, altfel se va întoarce lista de utilizatori în formatul descris anterior.

În Figura 5.23 este prezentată metoda „create” apelată în momentul invocării endpoint-ului „/v1/users” cu o cerere de tip POST. Aceasta ia datele din cerere și creează, folosind metoda nativă MongoDB „save” o intrare nouă în colecția de utilizatori. A se nota faptul că nu ne legăm deloc de codificarea parolei aici, asta este pentru că Passport creează un interceptor pe colecția de utilizatori și, de fiecare dată când încercăm să introducem o intrare nouă, el va lua automat parola și o va codifica, urmând apoi să creeze un hash și un salt pentru ea. În cazul în care metoda eșuează, se întoarce codul de status 500 împreună cu mesajul de eroare dat de MongoDB, altfel se va întoarce codul de status 201 (semnificând că utilizatorul a fost introdus) și un obiect care conține datele utilizatorului nou adăugat.

Controller-ul pentru rezultate „results.js” este o copie fidelă a acestui controller, singura schimbare fiind faptul că acesta operează pe alt model: Result în loc de User.

Front-end

Toată aplicația client sau partea "front-end" a aplicației se regăsește în directorul „client”. Aici sunt toate fișierele care se vor descărca mai devreme sau mai târziu de către un utilizator obișnuit prin intermediul browser-ului. Fiindcă aplicația folosește AngularJS ca și framework principal pentru partea de client, am structurat directoarele conform nevoilor acestui framework și pentru o scalabilitate cât mai mare a aplicației. Mai multe detalii despre structura de directoare se regăsesc într-un paragraf anterior.

În Figura 5.24 regăsim conținutul fișierului app.js. Deși punctul de intrare propriu-zis al aplicației client este fișierul „index.html”, fișierul „app.js” este punctul de intrare al framework-ului AngularJS. Așadar, în acest fișier regăsim inițializarea modului inițial pe care se va baza restul aplicației și o serie de dependințe de care acesta are nevoie. Putem observa, așadar, că modulul principal se va numi „CheckMe” și dependințele sale sunt „ui.router”, „ngSanitize” și „angular-cookies”.

În Figura 5.25 regăsim o bucată din fișierul „config.js” și anume bucata care definește rutele paginilor din aplicația client. După cum observăm, se face referință la „$urlRouterProvider” și „$stateProvider”. Aceste două obiecte sunt parte din „angular-ui-router”, o bibliotecă care extinde rutarea nativă din AngularJS și adaugă multe funcționalități noi de care ne putem folosi, inclusiv niste directive HTML pentru navigare. Putem vedea, așadar, că rutele definite sunt mai degrabă numite „state” sau stări, deoarece o rută este oarecum o stare în care se află o aplicație. Prima linie, cea care declară „otherwise„ este o rută-altfel. Ce înseamnă asta este faptul că, dacă un utilizator încearcă să ajungă pe o rută care nu este definită în acest fișier, va fi automat redirecționat către ruta aceea, în cazul acesta fiind ruta „/” sau pagina principală. În afara de asta, putem observa definirea a 4 rute: ruta „/„ pentru pagina principală, o rută separată pentru pagina de înregistrare numită „register”, ruta „dashboard” care este pagina prezentată unui utilizator logat. Ruta „test” putem vedea că este definită ca o rută abstractă, având atributul „abstract” definit ca true. Ce înseamnă asta este faptul că pe această rută propriu-zisă nu se poate ajunge, dar ruta va avea niște copii care moștenesc din ea. Așadar, următoarea rută numită „test.ishihara” moștenește din ruta „test”. Motivul pentru care am construit arhitectura de rutare în acest fel este scalabilitatea și extensibilitatea aplicației, în felul acesta putând fi adăugate pe viitor alte teste cu ușurință după același model. Mai observăm că, în afară de atributul „url” care este specific URL-ului vizibil în browser-ul fiecăruia, mai există un atribut numit „templateUrl” care specifică calea relativă către fișierul de tip HTML care va fi arătat utilizatorului la ruta aceea. Într-un paragraf ulterior voi vorbi despre directiva „<ui-view>” și cum se injectează fișiere HTML specific în unele locații.

A se nota că unele rute mai au un atribut „resolve”. Asta indică faptul că, înainte ca un utilizator să ajungă pe ruta respectivă, o metodă trebuie să fie invocată, în cazul acesta metoda „loggedIn” definită în Figura 5.26. Metoda respectivă returnează un boolean. Dacă acesta este false atunci utilizatorului nu i se dă voie să ajungă pe ruta respectivă. Facem asta pentru ca pe dashboard și la teste să nu aibă voie să navigheze doar utilizatorii deja autentificați în aplicație.

Pentru stilizarea CSS a paginilor aplicației am folosit framework-ul de CSS „Bootstrap”, așadar majoritatea claselor CSS prezente în fișierele de tip HTML sunt clase de Bootstrap. Fișierul „index.html” este punctul propriu-zis de intrare al aplicației client. În momentul în care un utilizator ajunge pe orice pagină de pe server-ul nostru, server-ul automat îi trimite fișierul „index.html”, urmând apoi ca acesta să dea drumu și aplicației de AngularJS și să facă cereri ulterioare pentru diferite imagini, fișiere etc. AngularJS se folosește de un sistem de directive care practic sunt tag-uri XML care, odată injectate în DOM, au o însemnătate specială pentru AngularJS. De aceea putem vedea că a doua linie a fișierului „index.html”, conform Figurii 5.27, conține directiva „<ng-app="CheckMe>”. În momentul în care AngularJS vede directiva „ng-app„ știe că el trebuie să dea drumul la o aplicație de tip AngularJS cu modulul principal „CheckMe”, modul pe care l-am definit anterior în cadrul fișierului „app.js”.

Putem vedea că fișierul „index.html” conține doar referințe cptre toate fișierele de tip CSS și toate fișierele de tip Javascript din cadrul aplicației și mai conține bara de navigare din partea de sus a ferestrei care este prezentă pe toate paginile. În afară de asta, „index.html” nu conține nimic special, deși este pagina care este prezentă pe toate rutele aplicației. Ce se întâmplă în spatele scenelor este, putem observa că la linia 48 a fișierului conform Figurii 5.28, directiva „ui-view” care este atașată unui element de tip „div”. Folosind „angular-ui-router” acesta știe că în locul acelei directive el trebuie să injecteze în DOM un întreg fișier HTML în funcție de rutele definite în fișierul „config.js”. Așadar, dacă ne aflăm pe pagina principală după autentificare, de exemplu (dashboard) dacă ne uităm la HTML-ul generat de browser observăm tot ce conține fișierul „index.html”, dar în locul directivei „ui-view” putem observa întreg conținutul fișierului „templates/dashboard.html”, ceea ce face ca aplicația noastră să funcționeze ca un SPA.

AngularJS conține foarte multe directive native care la compilarea DOM-ului sunt transformate în alte elemente, dar ne permite și definirea proprie a unor directive care apoi pot fi folosite ca HTML pentru a obține unele efecte altfel greu de obținut. Pentru această aplicație s-au folosit foarte multe directive, dar nu a fost nevoie de nimic customizabil, de aceea a ajuns folosirea directivelor native AngularJS. Cu toate acestea putem observa că directorul „directives” a fost creat și, deși gol, el este acolo pentru a încapsula viitoare directive care vor necesita a fi scrise pentru extinderea aplicației.

Autentificarea utilizatorilor se face pe un sistem de cookies, așadar un utilizator logat care părăsește aplicația va rămâne logat și într-o sesiune viitoare, atâta timp cât nu a trecut o anumită perioada de timp în care cookie-urile expiră pentru a evita unele probleme de securitate. La logare, datele unui utilizator sunt trimise de la server. Pentru a avea acces la ele la un nivel global în aplicația client, fără a face cereri multiple la server, am creat un serviciu numit „Auth” care ține în mod global datele unui user. Acesta are acces la un getter și la un setter pentru a seta și a lua informațiile necesare despre utilizatorul curent. AngularJS folosește un sistem numit „dependency injection” în care un serviciu poate fi injectat în orice metodă sau modul pentru a fi folosit, de aceea oricând avem nevoie de datele unui utilizator logat putem injecta serviciul „Auth” și invoca metoda „getUser” pentru a obține datele sale. Serviciul Auth este definit în fișierul „auth.js” din directorul „services” și definiția sa poate fi vizualizată în Figura 5.29.

AngularJS este un framework de tip MVC, așadar mare parte din logică se află în controllere. Controllerele pentru aplicația CheckMe se află în directorul „client/controllers”. Deși doar două la număr, ele sunt construite cu scalabilitate și extensibilitate în gând în așa fel încât dacă vor fi teste adăugate, se vor putea scrie în același mod câte un controller nou pentru fiecare test care să se ocupe de toată logica. Controller-ul „session.js” se ocupă de logica din spatele metodelor de autentificare ale unui utilizator și management de cookie-uri. Controller-ul expune două metode: „login” și „register”, expuse în Figura 5.30, respectiv 5.31 pentru autentificarea unui utilizator.

Funcția de înregistrare a unui utilizator face o cerere către API împreună cu numele, username-ul și parola unui utilizator, iar apoi redirecționează utilizatorul înapoi spre pagina de pornire în cazul în care înregistrarea s-a sfârșit cu succes, altfel se afișează un mesaj de eroare. Funcția de autentificare „login” încearcă să autentifice un utilizator, folosind username și parolă, iar în cazul în care această acțiune se sfârșește cu succes setează un cookie care spune că utilizatorul curent este autentificat. În caz de eroare se afișează un mesaj de eroare pe ecran.

Controller-ul „ishihara.js” este cel care se ocupă de tot ce înseamnă testul Ishihara de detecție a problemelor de discromatie. Acesta conține metodele „next” și „prev” care migrează între imaginile testului (observate în Figura 5.32).

De asemenea, aici sunt stocate în memorie răspunsurile corecte la testul Ishihara într-un vector uni-dimensional pentru a putea fi comparate cu răspunsurile date de utilizator la finalul testului și a putea da un verdict în legătură cu problemele acestuia de discromatie. După fiecare răspuns introdus, utilizatorul trebuie să apese un buton pentru a „finaliza” un răspuns, care apoi nu mai poate fi modificat, astfel acest răspuns este salvat în memoria browser-ului. Putem vedea metoda care se ocupă de această operațiune, metoda „complete”, în Figura 5.33.

Odată ce utilizatorul a trecut prin toate întrebările, se apelează metoda „submit” care calculează un punctaj și acordă un calificativ de tip trecut/picat. Acesta este și momentul în care utilizatorul își poate vizualiza singur rezultatele, trecând prin întrebările anterioare și vizualizând răspunsul dat de aceștia împreună cu răspunsul corect, imaginea fiind marcată ca fiind greșită sau corectă, în funcție de răspunsul dat de utilizator. Odată ce un punctaj s-a calculat, se trimite automat la server pentru a putea fi salvat și stocat, folosind modelul Result prezentat anterior. Putem vedea metoda „submit” în Figura 5.34

Toate fișierele HTML parțiale folosite în proiect sunt stocate în directorul „templates”. În afara de folosirea directivelor, AngularJS mai folosește o sintaxă de interpolare pentru fișierele HTML, denotată de două acolade „{{}}”. Astfel de sintaxă este destul de cunoscută developerilor de aplicații web, fiind folosită în mai multe framework-uri, cum ar fi: MoustacheJS, BackboneJS, Laravel și altele. Astfel, AngularJS reușește să transforme un limbaj static, HTML, într-un limbaj dinamic și astfel putem aduce interacțiunea dintre aplicație și utilizator la un nivel foarte înalt după cum se observă în cadrul testului Ishihara la care fiecare buton apăsat are un impact puternic instant asupra paginii și toate acestea se întâmplă dinamic, fără să necesite server-ul și fără să reîncărcăm pagina. Totul se întâmplă în memoria browser-ului cu o viteză ridicată.

TESTARE ȘI VALIDARE

Pentru partea de testare a aplicației propriu-zise am făcut mai multe teste la diferite niveluri de abstractizare. Pe măsură ce progresam cu dezvoltarea aplicației testam fiecare modul individual iar apoi, la finalul dezvoltării am testat aplicația cap-coada cu toate use-case-urile posibile.

Testare pe server

Pe server am testat API-ul, folosind Postman, o extensie de Google Chrome care permite testarea de API-uri. Am luat fiecare endpoint individual și am verificat că întoarce datele corecte existente în baza de date, sau dacă a fost o cerere de tip POST, PUT sau DELETE care adăuga, modifica sau ștergea respectiv o intrare din baza de date am verificat dacă intr-adevăr aceste modificări se pot regăsi în baza de date. După fiecare cerere trimisă la server am verificat și integritatea bazei de date și dacă totul este ok.

Tot ce ține de autentificare nu a trebuit testat deoarece Passport este foarte bine întreținut și testele lor demonstrează integritatea și securitatea întregului sistem și a librăriilor folosite de noi pentru autentificarea utilizatorilor.

Odată ce s-a terminat dezvoltarea API-ului am verificat dacă baza de date răspunde cum trebuie la toate interogările, făcând manual interogări direct din linia de comandă. Folosind MongoDB interogările sunt foarte ușoare deoarece MongoDB își expune propriul său shell care poate fi accesat rulând "mongo" din orice linie de comandă.

Astfel ne este expus un shell unde se pot rula interogări pe fiecare colecție, de exemplu pentru a căuta toate rezultatele care au un scor pozitiv putem rula urmatoarea interogare: db.results.find({passed: true}). După cum se poate observa interogările sunt foarte ușor de înteles și aproapiate de limba normala de vorbire. Practic interogarea anterioară poate fi citită în felul următor. Din baza de date (db), din colecția de rezultate (results) caută (find) toate intrările cu rezultat pozitiv (passed:true).

Astfel putem compune și interogări mai complicate cum ar fi următoarea întrebare: "Caută toate interogările de la testul Ishihara și la fiecare vreau și user-ul care le-a completat". Această interogare ar putea fi satisfăcută în felul următor: db.results.find({test: 'ishihara'}).populate('user'). Interogarea anterioară poate fi citită în felul următor: Din baza de date (db), din colecția de rezultate (results) caută (find) toate intrările la testul Ishihara (test: 'ishihara') și atașează user-ul la fiecare ( .populate('user') ).

Observăm așadar că fiecare interogare se face pe o anumită colecție urmată de o acțiune (find, findOne, insert, remove) și apoi un filtru pentru interogarea respectivă. În felul acesta am testat încontinuu integritatea datelor pentru a avea grijă ca totul să fie așa cum ne așteptam în baza de date.

Testare pe partea de client

Odată ce toată partea de testare pentru server a fost completă am început dezvoltarea aplicației client și totodată partea de testare. Întai am creeat doar paginile statice cu HTML și CSS la care testam tot timpul să fie "responsive" adică să arate curat pe orice rezoluție ar fi afișate, fie că este desktop sau un telefon mobil.

După ce paginile statice au fost gata și bine testate am început să scriu logica pentru aplicația client, la care am testat rând pe rând serviciile și controllerele individual prin injectarea lor forțată în DOM folosind Chrome Dev Tools. Folosind aceste ustensile am reușit să iau pe rând fiecare părticică din aplicație și să o testez individual urmând apoi să o integrez cu restul.

La sfârșit după ce toate au fost puse la locul lor am făcut niște teste cap-coadă manuale pentru a verifica că totul s-a integrat bine. Am creat conturi, m-am logat, am așteptat pentru perioada de expirare la cookie-uri să vad dacă funcționează.

Pentru testul Ishihara în special am încercat diferite valori și am încercat rularea inainte și înapoi a testului în diferite cazuri pentru a vedea dacă totul se comportă cum ar trebui.

Majoritatea bug-urilor întâlnite au fost la codul de pe server și în special în controllerele de la API dar folosind metodele de testare prezentate mai sus am reușit totdeauna să le indentific din timp și să le remediez.

Pentru debugging am folosit linia "debugger" și pentru client și pentru server. Rulând linia "debugger" într-o aplicație client face browser-ul să intre într-un mod de debugger unde se pot rula instrucțiunile una câte una și o consola este activă pentru a rula comenzi manual.

Pe partea de server când este întâlnită instrucțiunea de "debugger" server-ul intra în stand-by și linia de comandă care a fost folosită pentru rularea inițială a server-ului intra în modul debugger unde se pot rula orice comenzi de Javascript și de NodeJS și se poate continua execuția linie cu linie sau forța ieșirea din unele bucle. Multe alte ustensile sunt utilizate pentru debugging de cod Javascript dar în principiu acestea de baza sunt și cele mai eficiente. Chrome Dev Tools ne dă acces la un set de ustensile mai avansate pentru Profiling și management de memorie a browser-ului dar acelea sunt în principal folosite la aplicații la scară foarte mare care sunt în producție.

MANUAL DE INSTALARE ȘI UTILIZARE

Manual de instalare

Pentru instalarea și rularea server-ului sunt nevoie de următoarele resurse:

– Calculator cu acces la Internet și interfață grafică

– Un browser de ultimă generație instalat

Pentru rularea aplicației client sunt nevoie de următoarele resurse:

– Calculator cu acces la Internet și interfață grafică

– Un browser de ultimă generație instalat

Pentru instalarea și rularea server-ului se definesc următorii pași:

1. Se deschide browser-ul și se navighează pe https://c9.io

2. Se apasă pe butonul de "Sign In", se introduc credențialele de autentificare de developer

3. Se alege aplicația "Checkme" și se apasă butonul "Open"

4. În linia de comandă din partea de jos a ferestrei ce rulează următoarele comenzi în succesiune:

– npm install

– bower install

– ./mongod

– node server.js

Odată ce pașii anteriori au fost urmați, dacă totul a mers bine, aplicația ar trebui să fie accesibilă în browser-ul integrat în mediul de lucru la adresa "http://localhost:3000" sau public pe Internet la adresa "https://checkme-ioanapaula.c9.io".

A se nota că procesul pornit prin rularea comenzii "node server.js" va trebui oprit si repornit după fiecare modificare făcută la codul server-ului (dar nu și al clientului). Dacă se dorește evitarea acestuia se poate rula "nodemon server.js".

Manual de utilizare

Ca utilizator, odată ajuns pe pagina principală a aplicației “Checkme” se poate observa un form pentru logare, vizibil și în Figura 7.1.

Dacă utilizatorul are deja un cont făcut își poate introduce credențialele și continuă către dashboard. Dacă totuși avem de-a face cu un utilizator nou, acesta poata apăsa butonul de "Register" din colțul stânga sus al aplicației și va fi dus pe pagina de register unde prin completarea câmpurilor din Figura 7.2, utilizatorului i se va crea un cont în cadrul aplicației și va fi redirecționat înapoi la pagina de start unde se va putea autentifica.

Odată autentificat, utilizatorul este automat redirecționat către dashboard-ul aplicației. În partea de sus a aplicației se poate observa o bară de meniu cu logo-ul aplicației în partea din stânga și un numele a utilizatorului în partea din dreaptea. Apăsând pe numele utilizatorului, un meniu va apărea cu opțiunea de a se deloga pentru motive de securitate.

Mai jos în partea principală a aplicației putem observa testele accesibile utilizatorului. În momentul de față este accesibil doar testul Ishihara pentru detecția problemor de discromație dar dashboard-ul este construit în așa manieră încât adăugarea de noi teste poate fi făcută cu ușurință, fără nicio schimbare majoră a arhitecturii curente. În Figura 7.3 putem observa "card"-ul asociat testului Ishihara împreuna cu butonul de start care va duce la începerea testului propriu-zis.

Odată apăsat butonul de start, utilizatorul este dus pentru a completa testul de detecție a problemelor de discomație.

Pe parcursul testului, utilizatorul va vedea imagini conform celeia din Figura 7.4. O imagine mare apare sus, iar jos apare un câmp unde se poate introduce răspunsul și trei butoane, unul de navigare înapoi, unul de confirmare a răspunsului curent și unul de navigare înainte. A se observa că în Figura 7.4 nu s-a dat un răspuns înca, deci butonul de înainte este altfel colorat față de butonul înapoi. Astfel denotă faptul că nu se poate trece la următoarea imagine până nu s-a răspuns la cea curentă. Odată ce utilizatorul introduce un răspuns și apasă pe butonul "Check" butonul "Next" va deveni activ și utilizatorul poate continua la următoare imagine. Acest lucru se poate vedea în Figura 7.5. Totodată butonul de confirmare va dispărea.

La ultima întrebare nu va mai apărea un buton de "Next". În locul acestuia apare un buton verde de "Submit" prin care rezultatul este calculat și trimis la server, apoi utilizatorului ii sunt afișate toate imaginile împreuna cu răspunsul corect și răspunsul dat de acesta. Putem observa vizualizarea rezultatelor in Figura 7.6.

În partea de sus se poate vedea rezultatul, în cazul acesta "Fail" iar mai apoi în succesiune sunt prezentate toate imaginile împreună cu răspunsul corect și cel dat de utilizator.

CONCLUZII

Domeniul web este în foarte mare expansiune. Încă de prin anii '90 tot web-ul a explodat și de atunci nu a avut nici măcar un minut de repaus. De când a izbucnit bula tehnologică și odată cu finanțarea nebunatică a startup-urilor în marile combinatoare din Sillicon Valley și în principal zona San Francisco, majoritatea inovațiilor se aduc ori în domeniul tehnlogiilor web propriu-zise ori în tehnlogii afiliate dar care la bază au tot un API web cum ar fi valul Internet of Things care ia mare amploare de câțiva ani încoace.

În ciuda faptului că unii au zis că web-ul se va domoli în câțiva ani, studiile arată contrariul. Tendința de a muta totul pe o platforma web e atât de mare și nivelul de implicare care se pune în acest domeniu este atât de accentuat încât este posibil peste câțiva ani să vedem o reformă radicală a tehnologiilor prin care se renunța la sistemele de operare cu care suntem obisnuiți, pentru utilizatorii de rând de fel, sau acestea se vor muta în totalitate pe Cloud.

În orice caz trend-ul ne arată categoric că toată lumea vrea cât mai multe din programele soft pe care le folosesc să fie posibil să fie utilizate direct dintr-un browser.

Inclusiv gigantul în industrie, Google, ne arată că tinde foarte tare să aducă totul pe web prin tot ce au scos în ultimii ani. Începând cu suita de aplicații web care aduce foarte tare a vechiul Microsoft Office, vorbim aici de Google Docs, Google Sheets, Google Presentations care din cauză că sunt în totalitate aplicații web aduc noi metode de utilizare care înainte erau greu de imaginat cu o suită office obișnuită.

Prin introducerea laptop-urilor tip Chromebook care au ca sistem de operare de bază Chromium care este practic un Google Chrome emulat ceea ce înseamnă că singurele aplicații care rulează pe aceste sisteme sunt aceleași aplicații care rulează într-un browser obișnuit.

Un studiu recent indică faptul că aproximativ 75% din toate repository-urile de pe cel mai mare host de versionare a codului sunt scrise folosind JavaScript. Asta indică clar încotro merge trend-ul în dezvoltarea software la nivel global.

Fiecare sistem are nativ limbajul și mediul său de programare, JavaScript începe să încalce toate regulile și să pătrundă peste tot. Vedem cod mobile scris în JavaScript care compilează în cod nativ Objective-C pentru iOS și cod nativ Java pentru Android prin framework-uri precum NativeScript sau React-Native, framework-ul de la Facebook.

Pe lângă asta vedem cod JavaScript care compilează în cod nativ pentru aplicații desktop prin platforme precum nw.js sau Electron având acces la toate funcțiile și functionalitățile native ale sistemului de operare și cu toate acestea un singur cod compilează pentru toate trei platformele mari: OS X, Linux și Windows, aducând un mare avantaj atât giganților în industrie cât și startup-urilor printr-o scădere foarte mare a costurilor de producție.

Cele mai mari inovații în cadrul tehnologiilor web la ora actuală sunt aduse de Facebook, Google și Mozilla. Aceste trei mari companii multi-naționale au declarat că e posibil să vedem o reformă atât de radicală în cadrul dezvoltării de software încât e posibil ca JavaSript să fie în sfârșit limbajul unic de programare care va fi folosit într-un procentaj exorbitant pentru orice nevoie software, un lucru care se încearcă înca de acum zeci de ani și anume unificarea software.

Pentru mine proiectul acesta a fost mai mult decât ocazia de a explora toate aceste tehnologii web. Am reușit să învăț de ce web-ul este considerat atât de puternic la ora actuală și de ce se pune așa mare preț pe toate inovațiile aduse în cadrul său și în jurul limbajului de programare JavaScript.

Cu toate acestea, pot să spun la un mod subiectiv că este foarte greu să rămâi la curent cu tot ce e nou în lumea aceasta, asta pe lângă faptul că trebuie învățate din start minim trei limbaje de programare (HTML, CSS, JavaScript) și accesul facil la zeci de framework-uri diferite cu promisiuni diferite.

„CheckMe”, aplicația web pentru detectarea problemelor de discromație a fost într-adevăr o provocare. Nu doar că a trebuit să învăț toate framework-urile și limbajele cu care am lucrat dar a trebuit să învăt și partea server și partea client. A trebuit să mă ocup de comunicarea dintre ele, management bazei de date, sistemul de deployment și altele. Per total observ că un programator trebuie să aibă un "toolset" foarte vast dar are totodată foarte multe ustensile la îndemână.

Cred că unul din principalele motive pentru care Internetul este atât de la modă și se mizează atât de mult pe tehnologiile și ustensilele de construcție a aplicațiilor web e posibil să fie faptul că Internetul este mult mai greu de cenzurat decât alte platforme și astfel dezvoltatorii au acces la nenumărate librării open-source pentru toate nevoile de zi cu zi, ceea ce într-un final scade timpul de dezvoltare, un lucru foarte benefic pentru o companie.

Un mare avantaj în ceea ce am învățat a fost că toată aplicația este construită cu scalabilitate și extensibilitate în minte. Astfel, a trebuit să concep o arhitectură atât de modulară și de robustă încât să poată fi extinsă oricând în nenumărate feluri. Totul a trebuit construit generic și usor de moștenit.

Concret vorbind, am realizat o aplicație pentru detectarea problemelor de discromație. Am realizat un server care comunică în permanență cu aplicația client care poate fi în browserul oricărui utilizator, fiind publică la adresa "http://checkme-ioanapaula.c9.io".

A trebuit să realizez modelele de bază de date și comunicare propriu-zisă cu baza de date cât și toate interogările care trebuie satisfăcute pentru rularea cursivă a aplicației. Mai mult, a trebuit să scriu un API cât mai extensibil urmând paradigmele REST pentru un standard cât mai comun industriei web.

Pe partea de client a trebuit să realizez o interfață cât mai plăcută vizual și cât mai ușor de utilizat chiar și fără un manual de utilizare. Aplicația ar trebui să fie posibil să fie folosită cu minim de cunoștințe atât despre problemele de discromație dar și un utilizator fără prea multă experiență în folosirea calculatorului.

Pe partea aceasta de client sau "front-end" a mai trebuit construită o logica folosind un JavaScript interpretat de browser prin intermediul framework-ului AngularJS astfel încât să poata fi manipulate diferite secțiuni ale paginilor și ale browser-ului cum ar fi cookie-uri, rute, navigare și altele.

Mai mult de atat a trebuit să învăț metode de debugging și de testare pentru a putea obține o consistență a codului și a elimina toate bug-urile din acesta. Pe deasupra a trebuit să învăt și cum se lucreză cu baza de data NoSQL MongoDB și interogările pe aceasta pentru a putea în permanență verifica consistența bazei de date și a datelor propriu-zise.

Per total toată aplicația a fost foarte dificilă și a trebuit să învăț să utilizez și să înțeleg în detaliu multe ustensile pentru a putea să scriu un cod curat și să dezvolt per total o aplicație robustă și bine gândită din start.

Motivul pentru care am pus atat de mult accent pe scalabilitate și extensibilitate este faptul că aplicației îi pot fi adăugate în continuare teste și aplicația va putea fi folosita de suspecți de diferite afecțiuni de vedere pentru a-și diagnostica singuri problemele înainte de a vizita un specialist în domeniu.

Bibliografie

[1] Ari Lerner, „Ng-book”

[2] Colorblind Home Page, „PseudoIsochromatic Plate (PIP) Color Vision Test 24 Plate Edition”, Disponibil: http://colorvisiontesting.com/ishihara.htm

[3] David Flanagan, „JavaScript, The Definitive Guide, 6th Ed.”

[4] Nicholas C. Zakas, „Professional JavaScript for Web Developers, 3rd Edition”

[5] Open Web Design – dezvoltare aplicații web, „Ce este o aplicație web?”, Disponibil: http://www.webdesign-galati.ro/blog/ce-este-aplicatia-web

[6] Sabin Buraga, „Dezvoltarea aplicațiilor web – concepte primare și viziune”

[7] Sean Fioritto, „Sketching with CSS„

[8] Wikipedia, „Javascript”, Disponibil: https://en.wikipedia.org/wiki/JavaScript

[9] Wikipedia, „ECMAScript”, Disponibil: https://en.wikipedia.org/wiki/ECMAScript

[10] Wikipedia, „Hypertext Transfer Protocol”, Disponibil: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

[11] Wikipedia, „HTTPS”, Disponibil: https://en.wikipedia.org/wiki/HTTPS

Acronime

AJAX – Asynchronous Javascript and XML

API – Application Programming Interface

CSS – Cascading Style Sheets

GB – Gigabyte

GIF – Graphics Interchange Format

HTML – Hypertext Markup Language

HTTP – Hypertext Transfer Protocol

HTTPS – Hypertext Transfer Protocol Secure

IEC – International Electrotechnical Commission

ISO – International Organization for Standardization

JSON – Javascript Object Notation

PDF – Portable Document Format

RAM – Random-access memory

SPA – Single Page Application

SSD – Solid-state drive

SSL – Secure Sockets Layer

URI – Uniform Resource Indentifier

URL – Uniform Resource Locator

W3C – The World Wide Web Consortium

XML – Extensible Markup Language