La începutul lunii octombrie, Reea a fost reprezentată la prima conferință RomaniaPHP, dedicată 100% PHP-ului din România, de colegii: Alex Sava, Adrian Sorlea, Alin Miron, Andrei Irimie, Bogdan Goia, Sergiu Turus, Mihai Malai și Andrei Bobăilă, din birourile noastre din Tîrgu-Mureș și Alba-Iulia.
Subiectele dezbătute la conferință au fost:
„Event driven apps – event sourcing”, prezentare susținută de Marco Pivetta;
„Funcțional testing”, prezentare susținută de Dorin Avasiloaei;
„PhpStorm tips&tricks”, prezentare susținută de Gary Hockin;
„Getting Started” with PHPUnit”, prezentare susținută de Sebastian Bergmann;
„CouchDB PouchDB and Offline Tolerant Apps”, prezentare susținută de Lorna Mitchell.
Colegii noștri au notat aici principalele aspecte al fiecărei prezentări.
Event driven apps – event sourcing – Marco Pivetta
A fost prezentat un pattern arhitectural, Event sourcing pattern, o abordare ce poate fi folosită pentru gestiunea tranzițiilor stărilor unei aplicații. Aceste tranziții ale stărilor unei aplicații sunt practic evenimente, acțiuni generate de user sau de sistem. Într-o aplicație tradițională, nu se cunosc valorile proprietăților entităților în toate stările intermediare. Patternul event sourcing schimbă acest lucru, prin faptul că oferă mecanisme de salvare a evenimentelor care modifică stările interne ale entităților aplicației. Ca exemplu, atunci când un user cumpără ceva de pe un shop salvăm ce produse cumpără, cantitatea și prețurile (coșul de cumpărături). În acest context, evenimentele reprezintă stările coșului de cumpărături: adăugare în coș, ștergere din coș, plasare comandă etc. În majoritatea sistemelor tradiționale, datele sunt transformate intern, pe când patternul event sourcing presupune salvarea diferențelor (delta) dintre stările aplicației. În orice moment, se pot reconstrui date ale aplicației aflată în diferite stări prin „însumarea” acestor diferențe stocate.
Eventurile se mulează ca layer peste o aplicație existentă și îți permit lansarea de operații în momentul în care anumite acțiuni au loc. Sunt de fapt niște librării care ajută la înlănțuirea de procese (if this, do that). Pe baza event-urilor, se pot construi diagrame cu flowul unui anumit user și putem identifica pașii pe care acesta îi face în cadrul aplicației. Mai mult decât atât, putem să izolăm momentele în care aplicația nu răspunde conform așteptărilor și putem să scriem în loguri momentele respective. Fiind un layer separat, este mult mai ușor de extins și managementul pentru acțiuni este mai ușor de făcut decât în cazul structurilor condiționale implicate direct în aplicație, acestea din urmă ducând la o logică greoaie și greu de menținut de-a lungul timpului. Fiindcă vorbim de eventuri, putem înregistra listeneri care apelează noi acțiuni.
Aceste eventuri pot să fie de tip asincron, așa că userul nu trebuie să aștepte finalizarea proceselor și prin urmare aplicația se mișcă mult mai rapid. Există o librărie care facilitatează munca cu eventurile când vine vorba despre limbajul PHP (Prooph V7). Ce este interesant este că înlănțuirea de procese care are loc poate să fie scrisă în loguri sau într-o baza de date și astfel se face un history al eventurilor apelate.
Printre dezavantaje se numără:
– codul este mai greu de urmărit și necesită un management organizațional mai bun;
– este necesară documentarea proiectului pentru a construi „the big picture of things”.
Smarter, Faster Funcțional Testing – Dorin Avasiloaei
A fost vorba despre prezentarea a unei îmbunătățiri în Testarea Funcțională folosind PHP și Selenium. Practic, pe lângă combinarea fiecărui test cu un runner, s-a pus accent pe utilizarea Chrome cu driverul Mink, versus Chrome și Selenium.
Driverul Mink permite controlul Chrome-ului fără folosirea Selenium-ului. Acesta comunică direct cu Chrome prin HTTP și WebSockets, aspect ce îi permite să ruleze de două ori mai rapid decât Chrome + Selenium 43.
PhpStorm tips&tricks – Gary Hockin
Gary Hockin a venit să prezinte PHP Storm cu ultimele îmbunătățiri pentru creșterea productivității utilizatorului. A expus câteva aspecte importante care practic se găsesc în Help-ul PHPStorm-ului: https://www.jetbrains.com/help/phpstorm/guided-tour-around-phpstorm-user-interface.html
Începând cu versiunea 2017.1, PHPStorm oferă utilizatorilor sugestii despre numele parametrilor folosiți dacă aceștia conțin expresii literale sau sunt nuli. Presupunând că parametrii au fost denumiți într-un mod rezonabil, poți să primești numele variabilei pe care trebuie să o pasezi atunci când apelezi o funcție sau o metodă. De asemenea, puteți dezactiva sugestiile navigând la Editor | General | Appearance și deselectând Show parameter name hints.
În ultima versiune apărută, PHPStorm a implementat o consolă dedicată Composer Log pentru toate acțiunile și notificările din proiect care au legătură cu Composer. Acesta poate fi deschis din panelul editor composer.json sau din Event Log atunci când primești notificare de la Composer.
PhpStorm = WebStorm + PHP + DB/SQL.
Toate caracteristicele editorului WebStorm sunt incluse în PhpStorm plus suport pentru PHP și Baze de Date/SQL.
Getting Started with PHPUnit – Sebastian Bergmann
Creatorul PHPUnit a prezentat avantajele testării automate a codului folosind PHPUnit în Test Driven Development. Ideea de bază e că un developer trebuie să înțeleagă problema, nu doar să scrie cod. Scrierea de teste ajută la înțelegerea problemei pas cu pas. Testele nu conduc dezvoltarea la scopul final. Testele conduc dezvoltarea la declanșarea procesului gândirii, necesar pentru a atinge scopul final.
Unit Testing-ul vine cu câteva concepte:
– verificare prin execuție;
– documentație executabilă;
– specificație executabilă.
Pentru ca o clasă să fie ușor de testat folosind unit-testing, aceasta trebuie să aibă dependențe explicite care pot fi substituite cu ușurință și responsabilități clare care pot fi ușor invocate și verificate. În termeni de inginerie-software, aceasta înseamnă că, codul trebuie să fie slab cuplat și puternic coeziv, adică bine proiectat.
Pentru a scrie unit teste cât mai eficient, trebuie să ne punem câteva întrebări:
– ce vrem să obținem cu testul;
– cât de mult cod avem nevoie pentru a executa testul;
– cum formulăm textul;
– când scriem textul;
– când executăm textul.
Unit testing-ul nu este suficient pentru a asigura test coverage-ul complet. Pe lângă unit testing, trebuie adăugate integration tests, funcțional tests, A-B testing, edge to edge testing și smoke testing. Dozajul între respectivele tipuri de teste diferă de la proiect la proiect, dar se supune întodeauna unei piramide a testării. La baza piramidei se află unit testing-ul, cele mai multe teste fiind unit. Nivelul următor este ocupat de integration testing și A-B testing, apoi functional testing, edge to edge testing și ultimul nivel este smoke testing. Cu cât se urcă mai mult în această piramidă, cu atât cresc complexitatea și mărimea testelor și scade numărul acestora.
Întrebarea mea era cum adăugăm atât de mult overhead pe un proiect și să rămânem în buget, plus competitivi pe piață. Sebastian Bergmann a spus că, în conformitate cu câteva studii făcute pe mai multe echipe de development, în primii doi ani în care o echipă începe să scrie teste se adaugă minimum 30% efort pe respectivul proiect, dar după ce echipa și developerii câștigă experiență, testarea reduce timpul de implementare cu 15%-25%. „More work in less time” cum se spune. Și nu este o afirmație deplasată, diferența o face know how-ul unei echipe, testarea obligându-te să scrii codul corect și structurat. Iar acel cod este mult mai ușor de modificat la un change request, și evident, este mai ușor de întreținut. Referitor la justificarea în față clientului a efortului suplimentar adăugat de testare într-o estimare, Sebastian a recomandat o carte de pe LeanPub intitulată „How to sell testable software”. Recomandăm și articolul: https://enrise.com/2013/06/how-to-sell-software-testing/ care tratează acest subiect.
CouchDB, PouchDBandOffline-Tolerant APPs – Lorna Mitchell
CouchDB este o baza de date NoSQL (adică este bazată pe documente și nu este relațională) similară cu MongoDB, are un mecanism de replicare foarte bun, este RESTful și își tine informatiile în format json. CouchDB este proiectată să fie tolerantă la defecțiuni și are abilități excelente de a sincroniza baze de date care au fost offline una față de alta foarte multă vreme, chiar cu posibile conflicte.
CouchDB folosește MapReduce (scris în javascript) pentru view-uri și oferă, de asemenea, opțiuni puternice în interogarea datelor stocate. O astfel de bază de date consideră că a fi offline nu este o condiție de eroare, ci o caracteristică cheie a Aplicațiilor Web Progresive (http://offlinefirst.org)
PouchDB este o implementare JavaScript a CouchDB, rolul ei fiind de a emula API-ul CouchDB și de a se sincroniza cu CouchDB. Ca exemplu, a fost prezentată o aplicație cu un shopping list care lucra pe partea de client cu PouchDB, cu și fără conexiune la baza de date (pentru a exemplifica utilitatea în aplicații offline). Când sistemul a fost reconectat la baza de date, aplicația se sincroniza automat cu CouchDB.
De ce să folosești o baza de date NoSQL:
– este utilă atunci când înregistrările nu au aceeași structură;
– trebuie să schimbi structura datelor fără o întrerupere a sistemului;
– sincronizarea datelor se face rapid și ușor.
Replicarea bazelor de date:
– poate fi unidirecțională sau bidirecțională;
– poate fi continuă sau se poate face la un anumit timp.
Fauxton este interfață web în care se poate lucra cu CouchDB. Este similar cu PHPMyAdmin pentru MySql.
