Numarul 21/martie 2014 - Today Software Magazine by Today Software Magazine

Nr. 21 • Martie 2014 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

T O D A Y S O F T WA R E MAG A Z I NE

Bibliotecă JavaScript de logare HipHop Virtual Machine

AOP folosind .NET stack

Înapoi în viitor: Http 2.0

Dezvoltatorii de aplicații mobile și datele personale

Lupta noastră împotriva Datoriei Tehnice

Au proiectele Agile nevoie de disciplina în livrare? Tick Tock on Beanstalkd Message Queues PM în Agile Interviu cu Csaba Suket Director of Technology @ Betfair România

Agilitate înainte de Agile Autoencoders Faze și procese în structurarea unui proiect Disciplina în cadrul proiectelor Agile

6 Cluj Startup Weekend 2014 Marius Mornea

8 Interviu cu Csaba Suket Director of Technology @ Betfair România Ovidiu Mățan

10 Clusterul ClujIT: Inovare Interdisciplinară și soluții IT avansate

32 Cum să scrii un generator de cod bazat pe template-uri flexibile Dénes Botond

35 Mașina virtuală HipHop Radu Murzea

39 Autoencoders Roland Szabo

Paulina Mitrea

13 Lupta noastră împotriva Datoriei Tehnice Septimiu Mitu și Daniel Ionescu

15 PM în Agile Ciprian Ciplea

19 Agilitate înainte de Agile Alexandru Bolboaca și Adrian Bolboacă

21 Faze și procese în structurarea unui proiect Augustin Onaciu

23 Tick Tock on Beanstalkd Message Queues

41 AOP folosind .NET stack Radu Vunvulea

44 Disciplina în cadrul proiectelor Agile Mihai Buhai

46 Dezvoltatorii de aplicații mobile și datele personale Claudia Jelea

48 Cauza tuturor relelor în dezvoltarea soft… Cluj Business Analysts

52 Training de impact

Tudor Mărghidanu

Monica Soare

26 Înapoi în viitor: Http 2.0

54 MWC 2014: Smartphone-uri, Tablete, Phablete şi Smartwatch-uri

Rareș Rusu

29 Bibliotecă JavaScript de logare pentru dezvoltatori Bogdan Cornianu

Diana Ciorbă

56 Gogu și justificarea acțiunii Simona Bonghez, Ph.D.

editorial

Ovidiu Măţan, PMP

ovidiu.matan@todaysoftmag.com Editor-in-chief Today Software Magazine

umărul 21 al Today Software Magazin are ca temă generală Project management-ul. Această temă nu a fost aleasă întâmplător, ci pentru a se afla în concordanță cu ...even mammoths can be Agile, eveniment dedicat prin excelență domeniului project management-ului, care aflat acum la cea de-a cincea ediție se va desfășura la Cluj.Today Software Magazine și- a manifestat susținerea și implicarea în organizarea acestui eveniment , cunoscându-i eficiența de necontestat în a transmite și promova principiile de bază ale acestui univers complex care este project management-ul. Vastitatea acestui domeniu generează de cele mai multe ori riscul unor interpretări mult prea personalizate care conduc spre direcția nedorită a eșecului. Project management-ul este destul de multe ori înțeles ca o modalitate de promovare a liderilor tehnici care s-au făcut remarcați pentru rezultatele lor. Din păcate, prin acest demers de transformare a PM-ului într-un titlu de promovare se poate cădea în capcana ignorării laturii manageriale.Există riscul ca persoana investită cu noul rol să nu manifeste aceleași abilități și competențe de nivel superior și în domeniul managementului. Dincolo de formula ideală a expertului tehnic dublat de un bun manager la care aspiră project manager-ul, este important să ți se ofere ocazia de a evidenția și dezvolta calitatea de lider tehnic sau pe aceea de manager. Strategia corectă în astfel de cazuri este existența a două direcții de evoluție a carierei. La finalul anului 2013, Project Management Institute publica premiile oferite pentru cele mai bune proiecte.Câștigătorul desemnat a fost: Adelain Desalination Project din Australia. Lansat în 2008, pentru a reduce riscul de a rămâne fără apă din sudul Australiei, proiectul a fost construit pentru a acoperi 25% din necesarul de apă. Ulterior, s-a cerut dublarea cantității de apă furnizată. În aceste condții, echipa de management a proiectului a reușit să finalizeze proiectul cu 19 zile mai repede de data limită și cu o depășire a bugetului cu doar 1%. Un alt premiu a fost acordat construcției celei mai mari autostrăzi din Utah, USA. Valoarea inițială a proiectului a fost de 1 miliard de dolari și s-a reușit finalizarea sa mai ieftin cu 260 milioane dolari, doi ani mai repede și a livrat 10 mile în plus. Prin aceste două proiecte am vrut să evidențiez avantajele unui management de calitate și valoarea reală care pot fi aduse. Din această perspectivă, recomand o certificare PMP sau Prince 2 tuturor managerilor de proiect prin prisma standardizării proceselor și a structurii unui proiect. Bineînțeles, vom vorbi pe larg despre toate acestea în cadrul evenimentului ...even mammoths can be Agile. Vă oferim o scurtă prezentare a articolelor din acest număr. Startup Weekend Cluj este un eveniment încheiat de curând, a cărui caracterizare am ținut să v-o oferim chiar din perspectiva celei care a construit echipa câștigătoare, Antonia Onaca. Păstrându-ne în sfera evenimentelor, menționăm articolul despre Barcelona Mobile World Congress care a punctat principalele lansări de tablete și telefoane ce au avut loc. Continuăm cu interviul acordat de Csaba Sucket revistei. Acesta surprinde principalele provocări ce apar atunci ești cel mai mare dezvoltator de jocuri de noroc online. Articolele următoare, Lupta noastră împotriva Datoriei Tehnice, PM în Agile, Agilitate înainte de Agile, Faze și procese în structurarea unui proiect, se constituie într-o primă serie dedicată temei project management-ului. Dintre articolele cu tematică tehnică, care toate se remarcă prin subiecte interesante, vă oferim câteva titluri precum:Tick Tock on Beanstalkd Message Queues, Înapoi în viitor: Http 2.0, Bibliotecă JavaScript de logare pentru dezvoltatori. Mașina virtuală HipHop prezintă pe larg evoluția mașinii virtuale folosită de către Facebook , iar Autoencoders continuă seria de articole din sfera rețelelor neuronale și inteligență artificială. Vă dorim o lectură plăcută !!!

Ovidiu Măţan

Fondator al Today Software Magazine

nr. 21/Martie | www.todaysoftmag.ro

Redacţia Today Software Magazine Fondator / Editor în chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com Editor (startups și interviuri): Marius Mornea marius.mornea@todaysoftmag.com

Lista autorilor Alexandru Bolboaca

Claudia Jelea

Agile Coach and Trainer, with a focus on technical practices @Mozaic Works

Avocat & Consilier in domeniul marcilor

alex.bolboaca@mozaicworks.com

claudia.jelea@jlaw.ro

@ IP Boutique

Radu Vunvulea

Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com

Radu.Vunvulea@iquestgroup.com Senior Software Engineer @iQuest

Roland Szabo

roland.szabo@3pillarglobal.com Junior Python Developer @ 3 Pillar Global

Diana Ciorba

Monica Soare

Marketing Manager @ Codespring

Manager @ Artwin

Cluj Business Analysts

Bogdan Cornianu

Mădălina Crișan, Business Analyst Monica Petraru, Product Manager Cătălin Anghel, Business Analyst

Java developer @ 3Pillar Global

Marius Mornea

Rareș Rusu

diana.ciorba@codespring.ro

monica.soare@artwinconsulting.ro

Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com Contabil : Delia Coman delia.coman@todaysoftmag.com Produs de

Today Software Solutions SRL str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com

www.meetup.com/ Business-Analysts-Cluj

marius.mornea@todaysoftmag.com Inginer interesat și implicat în diverse activități IT, de la dezvoltare, management, până la educație și jurnalistică în cadrul Epistemio, UTCN și TSM

rares.rusu@betfair.com Inginer Software @ Betfair România

Mihai Buhai Septimiu Mitu

www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag

bogdan.cornianu@3pillarglobal.com

septimiu.mitu@endava.com Development Lead @ Endava

mihai.buhai@tss-yonder.com Delivery Manager @ Yonder

Tudor Mărghidanu

ISSN 2284 – 6352

tudor.marghidanu@yardi.com

Radu Murzea

rmurzea@pentalog.fr Software Architect @ Yardi România

PHP Developer @ Pentalog

Simona Bonghez, Ph.D. Augustin Onaciu

augustin.onaciu@fortech.ro

Copyright Today Software Magazine Reproducerea parțială sau totală a articolelor din revista Today Software Magazine fără acordul redacției este strict interzisă. www.todaysoftmag.ro www.todaysoftmag.com

simona.bonghez@confucius.ro Speaker, trainer şi consultant în managementul proiectelor,

Project Manager @ Fortech

Owner al Colors in Projects

Paulina Mitrea

Dénes Botond

Coordonator al Comisiei Innovation @ ClujIT Cluster

Software engineer @ Accenture Romania

Daniel Ionescu

Ciprian Ciplea

Paulina.Mitrea@cs.utcluj.ro

daniel.ionescu@endava.com Scrum Master @ Endava

denes.botond@accenture.com

ciprian.ciplea@isdc.eu Project manager @ ISDC

www.todaysoftmag.ro | nr. 21/Martie, 2014

interviu

Cluj Startup Weekend 2014

nul acesta ne-am bucurat din nou de prezența la StartupWeekend și vrem să felicităm echipa organizatoare pentru dovezile evidente de maturizare. Pe toată durata evenimentului am avut sentimentul că lucrurile merg conform planului, mai ales datorită atitudinii participanților. Față de anul trecut, când a existat un salt clar cantitativ, numeric, anul acesta aproximativ același număr de participanți, a pitch-uit 49 de idei, aproape la fel de multe ca și cumulul edițiilor precedente (2012 + 2013 - 59 pitchuri). Dovada clară că și publicul s-a maturizat și că majoritatea participanților au venit cu un scop foarte precis. Dincolo de organizarea discretă și eficientă, as vrea să subliniez două merite importante ale organizatorilor. Primul este nivelul de educație al publicului, care a venit pregătit de muncă, fapt ce validează toate eforturile pre-eveniment și evocă succesul edițiilor precedente în a crea startup-uri și a consolida ecosistemul antreprenorial din Cluj. Al doilea este punctualitatea, mai ales luând în calcul cele 49 de prezentări de idei de vineri care, nu știu cum, nu au reușit să dea programul peste cap, semnul cel mai evident al unei echipe cu experiență și maturitate. Pentru a înțelege mai bine experiența trăită în calitate de participant la eveniment, vă invităm la o incursiune în pielea câștigătorilor acestei ediții, echipa Engagement Management, alcătuită din: Dragoș Andronic, Emil Vădana, Ionuț Radu, Călin Vingan, Marius Mocian, Horațiu Dumbrean, Oana Vezentan și nu în ultimul rând, Antonia Onaca, cea care ne răspunde întrebărilor de mai jos. De cât timp ai ideea și când te-ai hotărât să participi cu ea la StartupWeekend? Ideea de engagement a apărut de mai multă vreme în munca pe care o fac în prezent, și cred că e o idee cu care cochetează

cam toată lumea care a lucrat măcar un știu cel mai bine ce pot face ei bine și fain. minut în viață cu o altă persoană. Lucrez • m a n a g e m e n t u l d i r e c t i v n u ca soluționist pentru organizații pe profuncționează atunci când vrei creativivocările legate de oamenii din organizații. tate, inovație, soluții bune, implicare. Am lucrat cu sisteme de managementul În acest caz vrem să explorăm diferite performanței construind variații ale acesdirecții și atunci nu trebuie să ne fie frică tora pe parcursul celor aproape 10 ani în de eșec (Innovator’s dilemma). HR și în leadership development. Principala • oamenii vor fi mai implicați și resproblemă pe care organizațiile o identiponsabili în lucrurile pe care au hotărât fică, mai ales în knowledge economy, este ei că le fac. că metodele de performance management • în knowledge economy nu putem nu funcționează și câteodată fac mai mult defini rezultatul pe care vrem să îl rău decât bine. De foarte multe ori a apăobținem (waterfall) ci mai degrabă îl tot rut problema: cum recompensăm oamenii creăm pe parcurs. faini ca să continue să fie faini (pentru • oamenii se așteaptă de la liderii că perks-urile nu funcționează) și cum lor să recompenseze efortul în primul îi facem pe cei care încă nu sunt acolo să rând și nu doar rezultatele acestuia ajungă acolo. Conform research-ului din (câteodată lucrăm mult doar ca să explopsihologia organizațională (care este un răm posibilități, unele dintre aceste domeniu masiv) răspunsul este „employee posibilități s-ar putea să nu se valideze, engagement”. Acesta are câteva lucruri pe dar acesta nu înseamnă că nu am lucrat) care le propune diferit: • responsabilitatea liderilor devine ast• pornim de la presupunerea că oamefel direcționarea efortului și încurajarea nii vor să facă o treabă bună (își petrec fiecărui om din echipă. jumătate din viața adultă la serviciu și ajung să își extragă măcar jumătate din Ca să răspund la întrebare, ideea a valoarea ca oameni din reușitele în acel cochetat cu mine, ca nevoie, de mulți ani context) și a venit ca soluție de vreo șase luni pen• o altă presupunere este că oamenii tru partea de dezvoltare organizațională

nr. 21/Martie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE (consultanță) concretizându-se ca produs în momentul în care trebuia să mă gândesc ce vreau să fac la SWCluj. Organizatorii au prezentat acest event (cel puțin mie) ca un context unde trebuie să faci o treabă bună și relevantă. Au transmis standarde foarte înalte pentru participare și atunci nu am vrut să nu le întâlnesc. Ce pregătiri ai făcut înainte de eveniment? Înainte de eveniment nu aveam idee despre cum poate să arate în realitate o soluție de genul acesta. Știam că piața are nevoie de o soluție pentru a creste employee engagement și atunci înainte de eveniment, am făcut research pe ce înseamnă acest concept, cum este abordat și care sunt metodele validate de soluții organizaționale care îl pot influența. Mai știam din experiența de consultant că implementarea oricărei soluții în organizații trebuie să aibă niște caracteristici: • să nu fie overhead - ceva foarte simplu. • e greu să îi duci pe oameni în alte medii decât cele în care sunt - așa că cel mai ușor este să stai în clientul lor de mail. • curba de învățare mare omoară multe din inițiativele organizaționale - un produs foarte ergonomic și ușor de învățat. Am încercat să vorbesc cu oameni din organizații pentru a vedea dacă sunt în prezent mulțumiți de soluțiile pe care le folosesc. Am aflat că firmele cu care am vorbit folosesc variații din procesele tradiționale de performance management ,dar nu consideră că îi ajută și simt că sunt foarte greu de implementat. Am mai aflat de la ei că employee engagement e un lucru la care se gândesc mult și pe care deja încearcă să îl influențeze cu diferite soluții organizaționale. Înainte de event aveam milioane de idei, informații și concepte care, acolo la fața locului, s-au ordonat și s-au transformat în cum ar putea arăta ele în realitate. Având în vedere importanța echipei, câți membri ai reușit să atragi și ce strategie ai folosit? Am fost opt oameni faini în echipă. Ne știam toți din alte contexte și cred că relația anterioară a fost un factor determinant. Cred că fiecare dintre cei din echipă au fost la un moment dat supărați pe sistemele actuale de managementul performanței și au văzut valoarea ideii (ca posibili beneficiari). Mai mult de atât, cumva ne respectam și ne plăceam de dinainte, unul câte unul și cred că și asta a fost un factor. Știam că va fi o experiență faină în cele două zile și de fapt cam fiecare urmăream asta de la eveniment. Câți dintre ei vor rămâne alături de proiect? Ne-am plăcut foarte mult și am lucrat

excepțional împreună. După SWCluj, fiecare dintre noi ne-am întors la proiectele noastre, pentru care făcusem deja angajamente și am stabilit că după ce ne liniștim și ne odihnim câteva zile, ne întâlnim să sărbătorim și să vedem cum punem țara la cale. Pentru asta va trebui să facem un alt articol în TSM :). Care sunt cele mai importante trei sfaturi primite la SWCluj? Ce mi-a plăcut mult la SWCluj a fost faptul că mentorii și juriul nu au venit cu sfaturi pe care noi să trebuiască să le respectăm. A fost o experiență foarte faină datorită faptului că fiecare a încercat să înțeleagă ce vrem, ce problemă încercăm să rezolvăm și cum ne-am gândit să facem asta. Mentorii au fost extraordinari că ne-au pus cele mai bune întrebări care să ne facă să gândim, să ducem ideile mai departe, să ne uităm critic și constructiv la ele. Cred că dacă ar fi venit cu sfaturi pur și simplu nu ar fi avut același impact. Ceea ce au făcut ei foarte bine a fost că ne-au învățat prin întrebări cum să gândim. Strategia e foarte bună pentru că un sfat îl ai o singură dată și pe cele mai multe dintre ele le uiți. Dar dacă cineva activează un proces de gândire, acela rămâne cu tine și după eveniment și mai ales atunci când chiar ai nevoie și mentorii nu mai sunt lângă tine. Care sunt cele mai importante trei realizări ale weekendului? În primul rând, cred că am validat relevanța ideii. Fiecare dintre noi, din echipă, a avut experiență în medii antreprenoriale și cred că știm că cel mai important este să validezi ideea. În al doilea rând a fost faptul că am avut acces la experiența reală a altor oameni. Știu că fiecare trebuie să ne facem propriile greșeli, însă este neprețuit când poți să înveți din realitatea experimentată a altora, chiar și numai ca să faci greșeli noi. Din păcate viața e prea scurtă ca să apucam să facem toate greșelile din care să putem învăța. A treia realizare a fost faptul că a fost o experiență foarte plăcută. Chiar ne-am simțit superbine. Aceasta se datorează echipei de organizare care a fost foarte înțeleaptă când a gândit evenimentul raportat la cum îl vom experimenta noi. Din experiența mea, ne-ar fi luat undeva la un an de viață, cel puțin, ca să învățăm lucrurile de acolo. Asta au făcut foarte bine organizatorii, au condensat un an de viață antreprenorială în 54 de ore. Ce premii ați câștigat? Foarte multe premii, foarte relevante pentru un start-up. Ele sunt listate pe site și în principal presupun acces în contexte unde ideea și munca poate fi accelerată semnificativ precum și tool-uri foarte utile și

relevante ca produsul nostru să ajungă realitate. Premiile au fost foarte bine gândite în așa fel încât să ai tot ce ai nevoie sa te apuci de treabă, să transformi în realitate ideea care va face lumea puțin mai bună. Pe lângă cele care sunt pe site, au fost de fapt mult mai multe. De exemplu, contacte personale cu oameni care te pot și vor să te sprijine sincer să faci ideea realitate, multe încurajări care sunt esențiale mai ales în partea de început când funcționezi pe kerosen emoțional și faptul că devii parte dintr-un grup care îți devine automat suport în a face față la provocările inerente oricărui început. Ai un sfat pentru viitorii participanți și eventual o rețetă/ ingredient de succes? E un sfat care vine din experiența antreprenorială, dar care a fost confirmat foarte bine de SWCluj. Nu te baza pe intuiție, asigură-te că există o nevoie reală și documentată. De multe ori ni se pare că soluția pe care o gândim e foarte utilă, pentru că ne identificăm noi cu ea, dar trebuie să vedem a cui problemă o rezolvă sau a cui viață o face mai bună și dacă acel cineva chiar vrea acea problemă să fie rezolvată. Mai mult de atât, citește research-ul pe domeniu să vezi dacă chiar se întâmplă cum crezi că se întâmplă. Este incredibil cât research relevant este făcut și cam tot îl găsești prin scholar.google.com sau sagepub. Chiar dacă industria de IT este inovativă , ea încearcă să rezolve tot probleme omenești, iar în problemele omenești există foarte mult know-how util. Un alt sfat este să se distreze sincer la eveniment. E incredibil ce lucruri faine ies atunci când ești fericit și te simți bine (cei de la zenQ au și construit un produs fain pe conceptul acesta). Când ești fericit, așa cum ziceau și ei în pitch, ești mai productiv, gândești mai bine, ai soluții mai faine, colaborezi mai bine și experiența e o recompensă în sine.

Marius Mornea

marius.mornea@todaysoftmag.com Inginer interesat și implicat în diverse activități IT, de la dezvoltare, management, până la educație și jurnalistică în cadrul Epistemio, UTCN și TSM

www.todaysoftmag.ro | nr. 21/Martie, 2014

interviu

Interviu cu Csaba Suket Director of Technology @ Betfair România

etfair România este cel mai mare centru de dezvoltare software al Grupului britanic Betfair. Sediul din Cluj are în prezent peste 250 de angajați, specializați într-o gamă largă de limbaje de programare, analiză de business, securitatea informației și project management.

La Cluj se dezvoltă patru arii principale: Platform Development, e-Commerce, Gaming, Product și Enterprise Data Services. Tehnologia inovativă din spatele produselor Betfair permite procesarea a peste șapte milioane de tranzacții pe zi, reprezentând mai mult decât volumul tranzacțiilor de pe piața bursieră europeană la un loc; 99,9% dintre aceste tranzacții sunt procesate în mai puțin de o secundă. Cel care ne poate dezvălui o parte din secretul succesului acestei companii este Csaba-Attila Suket, Director of Technology la Betfair România, care și-a arătat amabilitatea și ne-a răspuns la câteva întrebări: Bună ,Csaba, spune-ne câteva cuvinte despre tine. Salut Ovidiu. Pe scurt, am 33 de ani, am studiat la Cluj – Universitatea Babeş-Bolyai, specializarea Informatică. La Betfair am ajuns în 2008 şi am avut diferite roluri începând cu Engineering Manager, evoluând până la rolul de Director of Technology. Fiind developer la origini (baze de date), mă simt apropiat de Oracle şi de spațiul Data, dar în acelaşi timp sunt un fan SOA, Cloud, sisteme distribuite şi limbaje noi gen Go, Agile/Lean (Betfair România fiind printre pionierii Scrum-ului în Cluj). Motto-ul meu personal după care mi-am ghidat cariera şi viața mea este:think simple and positive, believe and achieve. Despre hobby-urile mele aş putea spune că acestea sunt hocheiul și filozofiile orientale.

Csaba Suket

aplicaţii Web care folosesc JavaScript, HTML, CSS, Templating (FreeMarker). Serviciile sunt construite folosind un framework intern bazat pe Jetty şi Spring (Core, DataAccess, AOP, Batch) şi JMS unde este nevoie. Pentru partea de build şi release folosim diferite tool-uri ca Maven, Jenkins, Sonar, Nexus, Chef. Sistemele de caching, load balancing sunt folosite pentru cele mai importante flow-uri. . În plus, punem foarte mult accent pe calitatea aplicațiilor pentru a putea face față unui astfel de load și în acest sens utilizăm Mockito, TestNG, JUnit, Selenium. Nu în ultimul rând, implementarea conÎn scurta prezentare a Betfair România am menționat desprea ceptului de DevOps ne permite o autonomie crescută pe partea de procesarea a peste șapte milioane de tranzacții pe zi. Pe ce tehnologii delivery și ne asigură o reacție promptă la urgențe operaționale. se bazează platforma Betfair, dacă ne referim la partea de server și baze de date? Care este strategia de dezvoltare din punct de vedere tehnologic? În ultimii ani, partea de Technology de la Betfair a trecut În momentul de față urmărim mai multe direcții strategice prin diverse transformări tehnologice și organizaționale până să dintre care câteva ar fi Cloud, tehnologii/limbaje de programare ajungem la un model Delivery Centric. În acest moment echipele noi și evoluție artitecturală bazată pe eficiență și ușurință în a noastre asigură ,,end to end” delivery la cea mai mare parte din opera produsele și componentele noastre. platforma Betfair, de la stadiul de specificaţii, design, implementare, testare, până la release şi partea operațională. Pentru o imagine mai completă, poți să ne spui care a fost prinTehnologiile pe care le folosim sunt Oracle pentru partea cipala realizare din punct de vedere tehnic din ultimul an? de baze de date, pe lângă alte sisteme NoSql și Java pentru A fost un an superb, plin de realizari, în care am rulat la o aplicaţii. Arhitectura noastră este de tip SOA, peste care avem viteză foarte mare și în care echipele noastre au livrat la un ritm

nr. 21/Martie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE de 40 de release-uri de producție în fiecare lună. Aceasta ne-a perDacă ar trebui să scrii un articol tehnic, care ar fi titlul acestuia? mis să ne perfecționăm începând de la nivel architectural, procese Cred că ar fi: Capacity and Scalability on an E-Commerce (operaționale, Scrum, de development și de testare, etc.). Mai mult Platform. decât atât, focusul a fost pe crearea de oportunități de inovație tehnologică pentru angajații noștri; unele idei de business care au Îți mulțumesc pentru amabilitatea de a răspunde la aceste avut un impact au venit din rândul angajaților. Aș spune că valo- întrebări. area adaugată business-ului prin aplicațiile și capabilitățile nou dezvoltate se impune detașat ca principala realizare a anului. Cum vezi evoluția Betfair România în următorul an? În următorul an ne propunem să continuăm investirea în calitatea produselor și proiectelor pe care le livrăm. Betfair România este un business solid din toate punctele de vedere; suntem bine poziționați ca angajator prin tehnologiile, oportunitățile și beneficiile pe care le oferim. Pe termen mediu focusul nostru va fi pe creșterea eficienței continuând în a oferi oportunități de creștere și perfecționare la toate nivelele pentru angajații noștri. Totodată vom păstra focusul pe cultura organizațională a firmei. Am auzit de Betfair University, poți să ne spui câteva cuvinte despre aceasta și cui se adresează? Betfair University este un program intern pentru angajații noștri, desfășurat de Camelia Hanga și Andreea Misaras, care oferă oportunități de dezvoltare profesională și personală. Este practic un concept umbrelă pentru toate activitățile de învățare de la cursuri, workshop-uri la certificări, mentoring, mese rotunde. Toate programele sunt personalizate în funcție de nevoile individuale și ale echipei. Rolurile de trainer – cursant se schimbă frecvent- fiecare angajat poate să contribuie cu expertiza sa. Gama de activități de învățare este foarte largă – de la cursuri tehnice la soft skills, management school, ședințe de coaching, până la competiții de programare și jocuri olimpice. Betfair University este un element central al culturii oganizaționale, angajații fiind cei care–și fac managementul propriei dezvoltări personale și profesionale.

Ovidiu Măţan

ovidiu.matan@todaysoftmag.com Editor-in-chief Today Software Magazine

www.todaysoftmag.ro | nr. 21/Martie, 2014

business

Clusterul ClujIT: Inovare Interdisciplinară și soluții IT avansate, pentru o comunitate urbană de avangardă

robabil că este deja binecunoscută misiunea Clusterului ClujIT în generarea și susținerea unui context de interacțiune a reprezentanților industriei software cu mediul academic și cu instituțiile publice.Consolidarea unui potențial menit a dinamiza evoluția mediului nostru socio-economic și accederea la un nivel de dezvoltare complet armonizat cu poziția Clujului de lider în domeniul IT pe direcția serviciilor de outsourcing se impun ca principale direcții de acțiune ale Clusterului ClujIT. Paulina Mitrea

Paulina.Mitrea@cs.utcluj.ro Coordonator al Comisiei Innovation @ ClujIT Cluster

nr. 21/Martie | www.todaysoftmag.ro

Consolidarea tendințelor de dezvoltare ale firmelor și entităților cu activități în domeniul IT, prin încurajarea paradigmei de diversificare a activităților prin realizarea de produse IT proprietar inclusiv prin start-up-uri inovative, creează premizele necesare garantării perenității industriei IT în arealul clujean, în condiții de augmentare a tuturor efectelor benefice ce-și fac simțită prezența de pe acum, lucru deja perceput în mod clar în comunitate.

Câteva obiective ferme în acest sens, în care se inscriu activități concrete, vizează următoarele: ·crearea premiselor pentru creșterea competitivității întreprinderilor din sectorul IT&C, bazată pe utilizarea intensivă a cunoașterii ·identificarea şi promovarea inițiativelor ce generează produse şi servicii inovatoare ·accelerarea colaborării, în domeniul cercetării, între mediul universitar şi companii ·generarea și atragerea de finanțări pentru proiecte

TODAY SOFTWARE MAGAZINE de cercetare&dezvoltare și inovare, cât și crearea mecanismelor pentru abordarea colaborativă de proiecte inovative de anvergură ·crearea şi promovarea brandului industriei IT&C locale ·consolidarea potențialului inovativ din domeniul IT prin instruiri specifice ·generarea de interacțiuni și contexte care să susțină posibilitatea de dezvoltare, la nivelul firmelor membre ale clusterului, de produse IT inovative, menite a le poziționa la nivel de top pe piețele existente și de a le deschide noi oportunități de piață, inclusiv piețe de nișă. Această „listă” de obiective cu adevărat ambițioase, își confirmă viabilitatea printr-un comportament bazat pe interacțiuni, cu efecte deja concrete pe zona competitivității. Este vorba despre cadrul de instruire pentru conștientizarea și consolidarea de know-how privind avantajul competitiv, oferit în contextul programului „Competitivitate și Inovare” afiliat cu Harvard Business School și derulat prin departamentul DECID al UTCN, cât și de sprijinirea activităților de branding și înregistrare de mărci la OSIM. S-a realizat, de asemenea, pregătirea de proiecte pentru programul „Future Internet”, iar in ceea ce privește identificarea de noi oportunități pentru finanțarea inovării, s-a demarat constituirea de consorții pentru proiecte finanțate din recentul lansat Horizon 2020 – program cadru pentru cercetare și inovare al Comisiei Europene. În virtutea unui crez asumat prin însuși statutul asociației ClujIT Cluster, obiectivul cel mai important este însă oferirea de soluții IT inovative pentru comunitate, bazate pe aport colaborativ de know-how și competențe avansate / chiar de avangardă (!), provenite din toate mediile furnizoare de knowledge și expertiză care sunt atât de bine reprezentate în urbea noastră prin potențialul pe domeniul IT probat cu brio de firmele clujene,în conjuncție cu capabilitatile de inovare oferite de cele patru universități membre ale clusterului. Este vorba deci de un potențial urias, iar anvergura proiectelor care se derulează pe această direcție majoră este pe măsură, căci vorbim aici de proiectul de “Dezvoltarea Inovativă prin Informatizare a Ecosistemului Urban Cluj-Napoca” cunoscut și sub denumirea de „Cluj-Napoca: Next Generation Brained City” - proiect aprobat spre finanțare pe POSCCE/ Op.1.3.3, cât și de proiectul major Cluj Innovation City, consolidat prin intermediul unui parteneriat public-privat puternic ce reunește autoritățile locale, mediul academic, mediul de business reprezentat prin Clusterul ClujIT/, în jurul a ceea ce este deja considerat a fi cel mai mare proiect urban al orașului nostru. Aceste două proiecte de mare anvergură, sunt menite a genera un areal de viețuire bazat pe conceptul inovativ de comunitate de tip urban ecologică și complet informatizată, consacrată sub paradigma de „networked ecological city”. Conform acestui concept, mediul nostru urban are șanse să devină un mediu armonios și eco-eficient, în care componentele și nivelurile specifice sunt armonizate prin intermediul unei informatizări integrative și exhaustive, acest sistem informatic urban jucând rolul de „creier” („brain”) ce utilizează date colectate prin intermediul unor rețele de senzori („smart sensor networks”), dar și prin intermediul operatorilor umani din toate contextele specifice ale comunității (de business, culturale, educationale, sociale, medicale etc.), pentru a gestiona și armoniza într-un mod inteligent resursele și componentele comunității de la fiecare dintre aceste niveluri.

Este absolut clar că și energiile implicate pentru realizarea în practica acestui concept, sunt și vor fi și în continuare deosebit de importante! Iar semnalul dat de faptul că există deja susținerea fermă atât a autorităților locale, cât și a celor de la nivel național, cu puncte de sprijin bine conturate chiar și la nivel european, este, în mod clar, de bun augur!

www.todaysoftmag.ro | nr. 21/Martie, 2014

comunități

Comunităţi IT

n luna martie vom avea evenimente de lansare a numărului 21 TSM în Cluj și în Timișoara. Vă așteptăm să participați, să răsfoim revista împreună și să asistați la prezentări ale articolelor publicate. De asemenea, vă invităm să participați în Cluj la Innovation Days și la ...even mammoths can be Agile.

Calendar Transylvania Java User Group Comunitate dedicată tehnologiilor Java. Website: www.transylvania-jug.org Data înfiinţării: 15.05.2008 / Nr. Membri: 563 / Nr. Evenimente: 43 Comunitatea TSM Comunitate construită în jurul revistei Today Software Magazine. Website: www.facebook.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 1241/Nr. Evenimente: 17 Romanian Testing Community Comunitate dedicata testerilor. Website: www.romaniatesting.ro Data înfiinţării: 10.05.2011 / Nr. Membri: 721 / Nr. Evenimente: 2 GeekMeet România Comunitate dedicată tehnologiilor web. Website: geekmeet.ro Data înfiinţării: 10.06.2006 / Nr. Membri: 573 / Nr. Evenimente: 17 Cluj.rb Comunitate dedicată tehnologiilor Ruby. Website: www.meetup.com/cluj-rb Data înfiinţării: 25.08.2010 / Nr. Membri: 170 / Nr. Evenimente: 40 The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software. Website: www.agileworks.ro Data înfiinţării: 04.10.2010 / Nr. Membri: 396 / Nr. Evenimente: 55 Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice. Website: www.meetup.com/Cluj-Semantic-WEB Data înfiinţării: 08.05.2010 / Nr. Membri: 152/ Nr. Evenimente: 23 Romanian Association for Better Software Comunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare. Website: www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 235/ Nr. Evenimente: 14 Tabăra de testare Un proiect care își dorește să strângă cât mai mulți oameni care lucrează ca și testeri. Website: tabaradetestare.ro Data înfiinţării: 15.01.2012 / Nr. Membri: 285/ Nr. Evenimente: 27

nr. 21/Martie, 2014 | www.todaysoftmag.ro

Martie 10-14 (Cluj), 17-18 (Timișoara), 20-12 (Cluj) Microsoft TechWave microsoft.com/romania/techwave Martie 15 (Cluj) Coderetreat it-events.ro/events/coderetreat-3 Martie 18 (Târgu Mureș) TEDx Târgu Mureș tedxtargumures.com Martie 19 (Cluj) Lansarea numărului 21 al Today Software Magazine www.facebook.com/todaysoftmag Martie 20-21 (Cluj) Cluj Innovation Days - recomandarea TSM www.clujinnovationdays.com Martie 24 (Timișoara) Lansarea numărului 21 al Today Software Magazine www.facebook.com/todaysoftmag Martie 24 (Iași) Open Source Iași it-events.ro/events/open-source-iasi Martie 25 (Cluj) Monthly BA Community Meetup #5 meetup.com/Business-Analysts-Cluj/events/165537042 Martie 29 (Cluj) Windows Azure BootCamp în Cluj-Napoca codecamp-cluj-azurebootcamp.eventbrite.com Martie 31 (Cluj) Mobile Monday Cluj #6 meetup.com/Cluj-Mobile-Developers/events/153087092 Aprilie 4-5 (Cluj) ..even mammoths can be Agile - recomandarea TSM colorsinprojects.ro/eveniment-cluj-4-5-aprilie-2014 Aprilie 4-6 (Timișoara) Timișoara Startup Weekend timisoara.startupweekend.org

management

Lupta noastră împotriva Datoriei Tehnice

ând implementezi o nouă funcționalitate ai două opțiuni: (neagră sau albă) - repede și neglijent sau curat și inteligent. În primul caz se tot adaugă o datorie tehnică pe care vei fi nevoit să o plătești la un moment dat. Dacă alegi opțiunea a doua investești initial mai mult timp și energie - dar devine mai ușor să dezvolți aplicația în viitor.

Septimiu Mitu

septimiu.mitu@endava.com Development Lead @ Endava

Fig 1. grafice adaptate după cursul PSPO de la Scrum.org

Conștientizarea

Daniel Ionescu

daniel.ionescu@endava.com Scrum Master @ Endava

Proiectul la care am lucrat a pornit de la zero. Au fost momente când am fost presați de timp și sprint după sprint am început să acumulăm puțin câte puțin datorie tehnica. De obicei, la sfârșitul sprintului ne dădeam seama că ne-am supraestimat abilitațile de a livra noi funcționalitătți. La acel moment eram mult mai interesați în a livra cât mai mult și cât mai repede, în defavoarea calității tehnice. Feedback-ul din partea clientului pe partea de arhitectură a venit foarte tarziu, iar când a venit am realizat că parte din codul nostru nu respectă îndeaproape recomandările lui. Câteodată am livrat o funcționalitate care mergea corect din punct de vedere al businessului, dar codul din spate era slab structurat. Ne place ideea de arhitectură emergentă în care structura aplicației se dezvoltă pe măsura ce proiectul evoluează. Pe măsură ce sunt implementate cerințele clientului arhitectura aplicației se dezvoltă și se cristalizează. E o modalitate bună de a lupta împotriva incertitudinii - atunci când nu știm de la început în detaliu toate cerințele sistemului, îl construim pe măsură ce aflăm răspunsul la întrebări. Adăugând o componentă aici, alta dincolo, aplicația noastră a început să semene

tot mai mult cu Frankenstein. Din punct de vedere al utilizatorului - aplicația făcea tot ce trebuia - dar codul a devenit pe zi ce trece tot mai greu de întreținut. Un alt punct slab al echipei noastre era faptul că aveam o singură persoană specializată pe o anumită tehnologie - ca de exemplu Alex pe BPM. Când el era plecat în concediu,ceilalți membri ai echipei care au scris cod BPM, neștiind ce era acolo, au scris cod doar ca să meargă fără să înțeleagă în amănunt implementarea BPM. Acest lucru se numește efectul autobuz: de câți oameni e nevoie să fie călcați de autobuz pentru ca echipa să nu-și mai poată continua activitatea în mod normal. În cazul nostru efectul autobuz era egal cu unu. Pentru a înlătura această deficiență, am încercat să avem cel puțin două persoane care să știe codul care ține de o anumită tehnologie (în cazul BPM a fost vorba despre Cosmin și Ștefan).

Nevoia de schimbare

Pe măsura ce încheiam un Sprint și încă unul, codul sursă al aplicației devenea tot mai dificil de întreținut. Tot ce am pus sub preș începea să iasă la suprafață. Dezvoltatorii nu mai erau capabili să scrie cod pentru o nouă componentă până nu puneau la punct codul existent. Soluțiile rapide aplicate în trecut au

www.todaysoftmag.ro | nr. 21/Martie, 2014

management Lupta noastră împotriva Datoriei Tehnice transformat codul în nisipuri mișcătoare. Plata datoriei Auzeam tot mai des la întâlnirile zilnice SCRUM: task-ul meu Sunt trei pași pentru a scapa de datorie (conform cursului de a durat de două ori mai mult decât a fost estimat pentru că a trebuit să sap și să refactorizez sistemul. Oamenii deveneau pe zi ce trece tot mai frustrați. Dezvoltatorii deveneau tot mai nemulțumiți pentru că petreceau mai mult timp să curețe codul existent decât să scrie funcționalități noi. Managementul s-a alarmat pentru că a scăzut velocitatea echipei. În același timp dezvoltatorii au început să stea tot mai mult peste program în încercarea disperată de a livra funcționalitătile promise la timp. Pentru a gestiona User Story-urile și task-urile folosim atât tabla de SCRUM cât și Jira. Tabla de SCRUM e inima echipei noastre unde ne întâlnim și discutăm toate problemele. Folosim Jira pentru a oferi Product Owner-ului posibilitatea de a vedea evoluția proiectului (Product Ownerul se afla în altă locație decât locația echipei de dezvoltare). Pe măsura ce timpul trecea - Jira a PSPO de la Scrum.org): devenit tot mai greu de gestionat datorită task-urilor neînchise, 1. Încetează să te mai împrumuți. task-urilor neplanificate, modificărilor la User Story apărute între 2. Plătește câte puțin din datorie. timp. Din Jira a devenit imposibil să-ți dai seama de starea proi3. Repetă pasul 2. ectului. La un moment dat lucrurile au devenit atât de grave încât nu am mai putut continua să lucrăm așa. După ce am facut vizibilă datoria tehnică pe tabla de agile și în Confluence, am început să rezolvăm din ea puțin câte puțin în fiecare sprint. La un moment dat ne-am dat seama că în ritmul Vizibilitatea Pentru că nu se mai putea continua așa – am scos totul la acesta se termina proiectul și noi nu terminam datoria tehnică. lumină: am pus datoria tehnică pe tabla agile și în Confluence. Așa că ne-am luat un sprint ca să o rezolvam. În același timp am Partea cea mai grea a fost discuția cu clientul, să admitem că avem încetat să ne mai împrumutăm. o problema și să-i cerem susținerea. Am început prin a revizui întreaga arhitectură și întreg codul. Am extins utilizarea Sonar, intrumentul folosit de noi pentru controlul calitătii și Jenkins - care ne ajută la livrarea continuă. Colegul nostru de la Endava Cluj - Mădălin – a mers un pas mai departe. A creat un panou care oferă o imagine de ansamblu asupra celor mai importanți indicatori de calitate. Și aceasta pentru toate echipele care lucrează la un același proiect într-un mod comparativ. După cum puteți vedea în imaginea de mai jos se pot urmări: numărul și tipul bug-urilor și trendul evoluției lor, acoperirea cu teste unitare a sistemului și rezultatul rulării testelor automate.

nr. 21/Martie, 2014 | www.todaysoftmag.ro

management

PM în Agile

ând discutăm despre proiecte, discutăm şi despre managementul de proiect care este o adevărată artă şi ştiintă de a duce la bun sfârşit proiectul. Pornind de la binecunoscuta relaţie Calitate, Timp, Cost, supranumită şi triunghiul de fier, avem încă de la început provocări care ne influenţează munca şi definesc rezultatele ei.

Ciprian Ciplea

ciprian.ciplea@isdc.eu Project manager @ ISDC

Istoric vorbind, managementul de proiect şi-a început evoluţia în proiecte industriale şi construcţii, iar in ultimele decenii a fost aplicat şi în domeniul IT pentru a duce la bun sfârşit viziunea antreprenorilor curajoşi sau a investitorilor care au văzut în sistemele IT un „commodity” la fel cum sunt azi petrolul, energia electrică sau mai recent Internetul. Mergând mai specific spre proiecte agile de dezvoltare a aplicaţiilor web, m-am gândit să punctez în acest articol o serie de aspecte, momente şi activităţi cheie pe care eu le-am întâlnit ca manager de proiect (PM) în ciclul de viaţă al proiectelor, în contextul ISDC - companie IT care oferă servicii şi soluţii software pe piaţa europeană. În cele ce urmează voi parcurge acele aspecte importante ce merită atenția deosebită a PM-ului într-un proiect agile și nu numai: de la un scurt istoric legat de evoluția metodelor de development la pornirea unui proiect agile, identificarea stakeholder-ilor, faza de fundamentare, definirea cerințelor funcționale și non-funcționale, managementul schimbării, planificarea, comunicarea, managementul riscurilor, monitorizarea progresului, QA, managementul vizitelor, demo/UAT la client și concluzionând cu retrospectiva.

Satisfacţia clientului

Din momentul în care eşti implicat ca PM într-un proiect, porţi o mare responsabilitate: satisfacţia clientului, care poate fi o întreagă organizaţie cu o serie de factori decizionali implicaţi sau doar un grup restrâns de persoane. Cred cu tărie că acesta este vectorul esenţial în controlul triunghiului de fier şi în dezvoltarea unei relaţii de continuitate cu acel client. Totul începe încă înainte de pornirea proiectului. Procesul de pre-sales şi sales este deseori lung şi plin de provocări. Odată setaţi parametrii colaborării cu clientul şi parafaţi printr-un contract, PM-ul preia aceşti parametri şi începe rafinarea lor.

“To be or not to be”… Agile

Agile sau non-agile, un proiect trebuie în aşa fel condus încât să-şi atingă ţinta în condiţiile stabilite de comun acord cu clientul şi să livreze produsul dorit de client la momentul dorit şi în buget, respectând o serie complexă de parametri funcţionali şi tehnici ce definesc calitatea produsului. Dar să vedem cum s-a ajuns la agile. De-a lungul timpului informaticieni şi ingineri, specialişti şi oameni de business au încercat

www.todaysoftmag.ro | nr. 21/Martie, 2014

management PM în Agile diferite formule de lucru pentru a finaliza cu succes proiecte informatice şi de a colabora impreună. Foarte cunoscutul waterfall a fost folosit din plin în proiectele IT cu secvenţierea fazelor de descriere de cerinţe funcţionale şi tehnice, cu analiza şi designul, iar în final implementarea, integrarea şi testarea. Au urmat alte formule intermediare, incrementale cu spargerea monoliticului model waterfall în segmente/ iteraţii mai mici, dar tot waterfall. În final modelul de dezvoltare software care s-a impus global a fost cel agile prin flexibilitatea sa, dar şi printr-un time-to-market mult redus.Vorbind de agile, mă voi referi în continuare la Scrum în calitatea sa de cadru de dezvoltare software, dar desigur sunt şi altele (de exemplu: DSDM, Extreme Programming).

de ambele părţi, ce apar încă din etapa de vânzări. PM-ul trebuie să aibă în vedere identificarea şi clarificarea acestor diferenţe şi stabilirea unor acorduri cu clientul. Aici intervin şi aspectele legate de planificare, definirea fazelor de lucrări, numărul de sprinturi ce vor fi folosite, mărimea echipei şi modul de lucru. Practic la pornirea proiectului, trebuie acoperite în discuţiile cu clientul subiecte care pornesc de la cerinţele funcţionale şi non-funcţionale care influenţează arhitectura şi atributele de calitate aşteptate până la felul în care se va face implementarea şi testarea în proiect. În cazul în care totuşi rămân puncte deschise sau neclarificate atunci recomand definirea unei liste de acţiuni pe care PM-ul să o urmărească.

Identificarea stakeholder-ilor

Există cazuri în care trebuie revenit de mai multe ori asupra unor aspecte când proiectul este complex şi de lungă durată. Un caz pe care l-am întâlnit a fost revenirea şi clarificarea Non-Functional Requirements (NFR): printre care se număra performanţa, mentenabilitatea, robusteţea şi securitatea sistemului software dezvoltat. Atenţie însă, acestea pot avea un impact foarte mare asupra sistemului după cum arhitectul vostru vă poate spune. Modificări ale NFR-urilor în timpul dezvoltării sistemului software, vor impacta planificarea şi bugetul proiectului pentru că au un potenţial mare de a genera re-work sau refactoring. În cazul unui proiect cu preţ fix aceasta vă va da şansa să vă exersaţi talentul de a convinge clientul să plătească suplimentar pentru modificările făcute.

În m aj or it at e a proi e c t e l or am lucrat cu clienţi externi în conjuncturi organizaţionale complexe, ceea ce a făcut dificilă, uneori imposibilă, participarea tuturor stakeholder-ilor principali la sedinţele de început de proiect (project kick-off). De aceea, un ţel important pentru un PM este să-şi cunoască toţi partenerii interesaţi direct/indirect de proiectul de care este responsabil şi pe lângă acesta să le cunoască şi interesele legate de proiect sau produsul livrat de proiect. Una dintre cele mai neplăcute situaţii este când un stakeholder este identificat prea târziu, în faza finală a proiectului. Această situație neplăcută vă poate da peste cap planurile şi acceptanţa finală a produsului dezvoltat.

Faza de fundamentare

În proiectele din ISDC am optat în ultimii ani să propunem clienţilor o fază de fundamentare înaintea începerii efective a sprinturilor de dezvoltare. În această fază, putem identifica şi relaţiona cu stakeholderii direct implicaţi. Beneficiile acestui pas preliminar începerii proiectului propriuzis sunt imense, echipele de lucru (client şi furnizor) se vor cunoaşte şi se vor alinia legat de modul de lucru (way of working) şi de alte aspecte importante ale proiectului. Cu siguranţă acest pas trebuie foarte bine organizat cu un plan şi o agendă clară în aşa fel încât timpul să fie folosit eficient şi să acopere aspectele prioritare pentru începerea dezvoltării.

NFR – cerinţe non funcţionale

Roluri şi guvernanţa în proiect

Definirea, clarificarea și atribuirea rolurilor încă de la începutul proiectului sunt de asemenea esenţiale, începând de la guvernanţa la nivel de Project Board până la clarificarea rolurilor în echipa/echipele de Scrum: Product Owner (PO), ProxyProduct Owner (PPO), Scrum Master (SM) sau Team leader (TL), Arhitect, PM etc. Există multe configuraţii de roluri care funcţionează, aspect care depinde şi de felul în care se desfăşoară acel proiect: cu echipe de development mixte (furnizor şi client) sau doar de partea furnizorului sau în colaborare cu sub-contractori sau consultanţi ai clientului. Sunt roluri care se pot cumula, uneori un PM este Diferenţe de aşteptări şi SM/TL, uneori SM este şi PPO etc.. La În momentul alinierii cu clientul pot modul general, cumularea acestor rolieşi la iveală o serie de diferenţe de aşteptări uri implică responsabilități importante

nr. 21/Martie, 2014 | www.todaysoftmag.ro

precum evitarea conflictelor de interese care pot apărea și luarea în considerare a particularității organizării interne a companiei software.

Definirea cerinţelor funcţionale şi Managementul schimbării (Change Management)

O alta lecţie învăţată în timp este că sunt clienţi care ştiu exact ce vor şi foarte mulţi care nu pot indica cu exactitate şi trebuie ghidaţi. În fond, în calitate de furnizor de servicii software, una dintre provocări este să ghidăm clientul spre cea mai bună soluţie care să-l ajute să-şi dezvolte sau îmbunătăţească afacerea. Aici intervine definirea cerinţelor funcţionale, care fie este realizată de oamenii de business ai clientului în colaborare cu consultanţi specializați, fie de furnizorul software în colaborare cu clientul. Odată cu trecerea de la waterfall la agile definirea cerinţelor funcţionale se face în paşi, în care echipa de dezvoltare este implicată înainte de fiecare sprint în acele sesiuni numite (Scrum) de pre-grooming sau grooming. Rareori avem documentaţii complete funcţionale şi chiar şi atunci când ele există la momentul implementării sunt deja învechite. De aceea o prioritizare preliminară cu clientul a cerinţelor funcţionale majore (epics) din product backlog este de dorit, pe sprinturi. PM-ul trebuie să se asigure că acea prioritizare este realistă şi abordabilă în context tehnic şi funcțional după consultarea cu SM/TL-ul şi architectul. În cazul unui contract/proiect cu preţ fix, pentru a realiza o delimitare clară a funcționalităților (project scope) poate fi necesară o detaliere în avans a tuturor acestor cerinţe majore (epics) în unele mai amănunţite (userstories) pentru toate sprinturile.Această delimitare reprezintă una dintre marile provocări ale unui proiect cu preţ/buget fix. Pentru a putea avea evidența schimbărilor funcționale, trebuie pus la punct managementul schimbărilor (change management) care constă în definirea un proces de raportare și aprobare a cererilor de schimbare a specificațiilor funcționale (change management flow) și în identificarea actorilor cu responsabilitățile lor în acest proces (client, echipă, PO, PM, Project Board, etc.). E important ca echipa de dezvoltare să aibă foarte clară definiția unei cereri de modificare (Change Request). Rolul PM-ului aici e esențial, de aceea o bună colaborare cu SM/TL-ul și o aliniere permanentă este necesară. Orice cerință ce vine de la client și care declanșează o potențială schimbare trebuie notificată de

TODAY SOFTWARE MAGAZINE call etc.) fie el un stakeholder intern din cadrul furnizorului, fie un stakeholder de la client; • informarea periodică a echipei de către PM și reciproc, dincolo de standup-urile zilnice; un meeting săptămânal poate fi de ajutor; • alinierea internă în cadrul factorilor decizionali (PM, SM/TL, Arhitect, Management, Sales); De asemenea, sunt și lucruri care ar trebuie evitate: • întreruperea de către PM a daily stand-up-ului cu subiecte ce pot fi discutate ulterior și nu interesează toți membrii echipei; de fapt nu totdeauna este necesară prezența PM-ului în aceste meeting-uri; • atribuirea de task-uri direct de PM către membrii echipei fără informarea SM/TL-ului; • convocarea de ședințe cu participarea întregii echipei când nu este nevoie de toți membrii ei; • neglijarea problemelor și riscurilor comunicate de echipă în daily sau ulterior în discuții cu membrii echipei.

echipă către PM.

Planificare, Ipoteze de lucru, Constrângeri și Riscuri

Bugetul alocat, rolurile necesare în echipă pe sprinturi pe săptămâni, defalcarea în timp a bugetului (în ore și bani) și o secvențiere a activităților și a reperelor (milestones) la finalizarea fazelor de lucrărisunt aspectele de care trebuie să țină cont o planificare de ansamblu a proiectului ( high-level planning). Planificarea trebuie să aibă în vedere ipotezele de lucru (assumptions) de la care echipa de dezvoltare pornește, care pot să fie tehnice, funcționale etc.. Diversitatea lor este surprinzătoare. Ele vin la pachet cu constrângerile (constraints) proiectului: bugetul, data livrării, atributele de calitate, disponibilitatea membrilor echipei furnizor și client. Nu în ultimul rând planificarea este legată de riscurile identificate la începutul proiectului. Această planificare trebuie pusă în acord cu clientul încă de la începutul proiectului, menționând validitatea ei doar în contextul listei de ipoteze, constrângeri, riscuri. În cazul modificărilor ulterioare apărute în cadrul ipotezelor de lucru, PM-ul trebuie să ia în considerare impactul asupra planifică- Identificarea și „dezamorsarea” riscurilor rii deja agreate. Într-adevăr este vorba de managementul riscurilor. Gândiți-vă la riscuri ca Comunicarea și managementul stakela ceva cu capacitate distructivă pentru holderilor proiectul vostru. Nu ați vrea să le tratați Comunicarea este unul din facto- cu atenție? „Dezamorsarea” acestor riscuri rii decisivi în succesul unui proiect. Iar ar trebui să fie printre principalele griji ale PM-ul este un dirijor care orchestrează PM-ului. această comunicare. Deseori comunicarea Noi am făcut acest lucru permanent este neglijată și problemele de comunicare în proiectele în care am fost implicat, cu împiedică bunul mers al proiectului, dar scopul de a reduce probabilitatea și impacexistă câteva lucruri care pot preveni astfel tul lor prin diferite acțiuni. Împreună cu de probleme dacă sunt de la bun început echipa și SM-ul, PM-ul trebuie să identifice stabilite: și să găsească mijloace de a reduce pagubele • cum și la cine se raportează progre- în caz că riscurile se manifestă. E nevoie de sul și cu ce frecvență (zilnic, săptămânal, transparență în echipă pentru ca aceste rislunar) și în ce format/canal (e-mail, pe o curi să fie puse pe masă de echipă. Și apoi platformă de colaborare, meeting, Skype de consecvență din partea PM-ului pentru

SUMMER INTERNSHIP

JULY 1–AUGUST 22, 2014 / APPLY UNTIL APRIL 11! .NET

Big Data/ Analytics/ Business Intelligence

a le documenta, monitoriza și mitiga. Sunt cazuri în care riscurile trebuie puse pe masa Project Board-ului. E important ca aceste riscuri să fie colectate de PM/SM/Arhitect permanent în toate împrejurările. Nu vă rezumați doar a întreba membrii echipei în timpul daily-urilor. Participați din când în când ca observatori la ședințe tehnice, la sprint planning-uri și grooming-uri și veți identifica riscuri. Discutați periodic cu membrii echipei voastre, așa veți colecta pe lângă impedimentele zilnice și riscuri la care este expusă echipa și proiectul.

Monitorizarea progresului

Măsurarea progresului este un factor cheie în a determina succesul unui proiect și a aplica acțiunile corective potrivite. La ora actuală există o multitudine de aplicații care facilitează echipele de dezvoltare în stocarea cerințelor funcționale, criteriilor de acceptanță, statusul activităților desfășurate și estimărilor lor inițiale, timpul petrecut pe activități, legătura cu codul sursă și altele. În proiectele recente la care am lucrat am folosit JIRA (Atlassian) sau TFS (Microsoft). Cu ajutorul burn-down chart-urilor puteți identifica zilnic întrun sprint dacă progresul a fost conform sprint planning-ului inițial. În caz de devieri, împreună cu SM-ul puteți lua măsuri corective. Periodic, de exemplu o dată pe săptămână puteți verifica și starea bugetului (ore/bani). În cazul proiectelor cu preț fix este util să aveți o descriere a produsului, defalcată pe funcționalități, numită și PBS (Product Breakdown Structure), în care să marcați proporția de implementare pe o anumită funcționalitate și să aveți și o estimare în efort și durată a ceea ce a mai rămas de implementat. De cele mai multe ori puteți deriva acest PBS din product backlog.

BECOME AN ISDC PAID INTERN! Experience a company that understands and

IN GOOD COMPANY

rewards talent. If you are an IT student or fresh graduate and have the latest technologies at

BRILLIANT INTERNS WANTED

Testing Java

your fingertips, apply to join a competitive team of professionals! Good knowledge of OOP is a must and team spirit definitely helps. We promise tough development assignments because you can!

www.isdc.eu/careers/summer-internship e-mail to internship@isdc.eu

www.todaysoftmag.ro | nr. 21/Martie, 2014

management PM în Agile QA – Asigurarea Calității

Termenele de livrare, efortul și costurile nu sunt totul, sistemul software dezvoltat în proiect trebuie să aibă atributele de calitate dorite de client. În cadrul ISDC am avut șansa să pot apela la expertiza pe zona funcțională, pe zona architecturală/tehnică și cea de calitate a proceselor de dezvoltare și testare. Aceasta mi-a dat o indicație obiectivă a stării de sănătate a sistemului dezvoltat și a proceselor folosite. Pe lângă mecanismele implicite „built-in” de review a codului sursă și cel de testare funcțională, regăsit în practica echipelor de dezvoltare, care îți oferă siguranța că nu ți-au scăpat erori serioase tehnice sau funcționale, recomandabile în ciclul de viață al unui proiect sunt următoarele acțiuni: • un review arhitectural făcut de un technical lead sau un arhitect software; • un review al procedurilor de release/deployment și management de configurații; • un test de încarcare și performanță (load/performance test) al sistemului; • un test de securitate (white/black box).

Managementul impedimentelor și problemelor

Există impedimente și probleme care nu pot fi înlăturate de SM și atunci acestea vor ajunge pe masa PM-ului. În acest caz ca PM este necesar să identifici mijloace și alternative de a le rezolva: comunică tu direct cu clientul, rezolvă probleme legate de resurse sau dacă nu le poți rezolva singur, ai un instrument puternic și influent: Project Board-ul în fața căruia poți aduce acea problemă cu alternativele propuse de tine. Dar nu-l surprinde, pregătește din timp o agendă și comunică-o board-ului,

fixează o dată când toți membrii se întâl- avantajele. nesc și clarifică ceea ce te astepți de la board. Retrospectiva Cel puțin la finalul fiecărei faze de Disponibilitatea clientului și planificarea execuție (o nouă versiune de exemplu) comună constând dintr-o serie de sprint-uri, Una dintre problemele majore în multe este indicat să aveți un moment de din proiecte este indisponibilitatea per- retrospectivă cu echipa și clientul în care soanelor cheie de la client. Pentru acestă să analizați parametrii proiectului: devieproblemă vă propun o sesiune comună de rea pe estimări, gradul de re-work, calitatea planificare cu persoanele în cauză de la cli- userstory-urilor, calitatea codului, calitatea ent sau cu managerul lor.Practic o astfel de test-scripturilor. Este posibil să doriți să reconciliere a planificării făcute de echipa faceți aceasta în sesiuni separate, dar e bine de dezvoltare împreună cu partenerii cheie să identificați cu echipa lucrurile care au de la client va duce la rezultate mai bune. funcționat și pe care vreți să le păstrați dar și pe acelea care nu vreti să se repete.

Managementul delegațiilor reciproce

O altă cauză comună a impedimentelor și problemelor ne-rezolvate este lipsa sau raritatea contactelor directe dintre echipa de dezvoltare (sau a reprezentanților ei: PM, SM, Architect, PPO) și client (sau a reprezentaților lui: PM omolog la client, PO, Key User, Test Manager). PM-ul este cel în măsură să propună clientului ca parte din planul de comunicare: un plan de vizite reciproce care să elimine barierele de comunicare și să stimuleze comunicarea dintre membrii ambelor echipe.

Concluzii

Din punctul meu de vedere un PM într-un proiect agile trebuie să fie dinamic, flexibil, receptiv la feedback-ul clientului/ echipei și să aibă întotdeauna o privire de ansamblu asupra proiectului. Focusul PM-ului rămâne pe satisfacția clientului și calitatea sistemului dezvoltat în buget și la timp, lucruri care se obțin prin: comunicare susținută și managementul stakeholderilor, prezența la client periodică, evaluare constantă împreună cu clientul a sistemului dezvoltat până în momentul respectiv și Demo la client decizia implementării de CR-uri, identifiOri de câte ori aveți posibilitatea, carea și ameliorarea impactului riscurilor planificați accesul clientului la un demo sau conjugată cu un QA eficient. o perioadă de acceptanță User Acceptance Testing (UAT) on-site la client sau la voi. E vital pentru succesul UAT-ului să fiți aproape de client. Planificați delegații la client în care să faceți demo la ultimele functionalități dezvoltate sau pentru a începe o perioada de UAT. E posibil să întâlniți rezistență din cauza costurilor de deplasare ,dar argumentați-le prezentând

nr. 21/Martie, 2014 | www.todaysoftmag.ro

management

Agilitate înainte de Agile

ată o situație obișnuită în zilele de astăzi: o companie află despre Agile și decide să adopte “procesul agile”. Echipa de conducere a companiei creează un plan al tranziției care include: training, coaching și consultanță. Monitorizarea avansului se face întrebând: câte echipe sunt agile? Pentru că atunci când vom fi peste 80%, am terminat tranziția și vom fi agile. Nu?

Alexandru Bolboaca

alex.bolboaca@mozaicworks.com Agile Coach and Trainer, with a focus on technical practices @Mozaic Works

Greșit. Cât de agile este o companie nu contează cu adevărat. Singurul lucru care contează este agilitatea: cât de repede poate o companie să se adapteze schimbării. Agilitatea este proprietatea organizației, nu a echipelor. Îmbunătățirea agilității presupune de obicei folosirea practicilor agile și lean la nivelul echipelor, dar nu doar atât.

Cine are nevoie de mai multă agilitate?

Adrian Bolboaca

adrian.bolboaca@mozaicworks.com Programmer. Organizational and Technical Trainer and Coach @Mozaic Works

Dacă ne uităm în acest mod, atunci este evident că nu toate companiile au nevoie de agilitate. În special o companie nu are nevoie de agilitate dacă toate criteriile următoare se aplică: • are un model de business puternic care aduce un profit remarcabil, • nu vrea să se extindă pe alte piețe sau să creeze alte modele de business, • clienții au un ciclu de punere în producție foarte lung (1-2 ani). Spitalele sunt un exemplu de client care nu vrea să își schimbe software-ul mai des de două ori pe an. Contabilii sunt de asemenea cunoscuți pentru a fi utilizatori conservatori care preferă mai puține update-uri. Unele practici agile pot să structureze mai bine munca realizată în asemenea contexte, dar valoarea pe care o aduc afacerii va fi limitată. În mod sigur, nu toate spitalele sau nu toți contabilii se potrivesc acestui model, în consecința fiecare afacere trebuie să se decidă în funcție de contextul propriu. Dacă întoarcem acest argument, ajungem să aflăm care sunt motivele pentru a crește agilitatea unei companii: • când piața o forțează să furnizeze calitate îmbunătățită mai repede, • atunci când piața s-a schimbat și afacerea trebuie să se adapteze, • când afacerea trebuie să intre pe o nouă piață, • atunci când afacerea trebuie să crească repede.

Observați că vorbim despre creșterea agilității. Orice afacere are un anumit nivel de agilitate, problema este cum să o creștem pentru a răspunde forțelor externe care o obligă la schimbare.

Măsurarea agilității. O utopie?

Putem să măsurăm agilitatea unei companii? A o măsura direct este evident foarte riscant și foarte scump, pentru că am avea nevoie să aplicăm forțe externe asupra companiei și să observăm cât de repede se adaptează. Putem, totuși, să analizăm evenimentele trecute și să discutăm situații ipotetice. De exemplu “ce ar trebui să facem pentru a reduce ciclul de punere în producție de la un an la șase luni?”. Dacă răspunsul este “acest lucru ar fi imposibil” sau “acest lucru ar fi foarte dificil”, atunci agilitatea în mod clar nu este un punct forte. Un alt exemplu: “cât de repede puteți crea un produs complet nou de la o idee pe care o aveți astăzi?”. Dacă răspunsul este “un an” sau “6 luni”, în mod sigur e loc de mai bine pentru că trei luni este o perioadă uzuală pentru acest gen de activitate. La acest moment nu există nici o listă clară de întrebări pe care le putem adresa pentru a măsura agilitatea. Întrebările interesante sunt foarte dependente de contextul afacerii și obiectivele sale. Aici experiența unui coach agile cu diverse organizații devine foarte utilă.

Principii și practici pentru a sprijini creșterea agilității

Odata ce s-a decis ce trebuie îmbunătățit, este timpul pentru a crea un experiment si pentru a ne concentra pe principii și practici. Principiile sunt fundația oric ărei tranziții, iar practicile definesc cum putem face anumite lucruri. De exemplu, principiul agile, comunicarea față în față definit drept “cea mai eficientă metodă de a transmite informaţii înspre şi în interiorul

www.todaysoftmag.ro | nr. 21/Martie, 2014

management Agilitate înainte de Agile echipei de dezvoltare, conduce la practica de a avea echipe colocate și de a organiza întâlniri cum ar fi Daily Scrum, Planning sau Retrospectiva, unde toată echipa este prezentă fizic oricând posibil. Principiul de a avea feedback rapid și des se traduce în practica prin: • a lua feedback de la clienți pe dezvoltări, • dezvoltatorii să scrie teste unitare astfel încât primesc un feedback rapid în legătură cu corectitudinea schimbărilor făcute de ei, • integrare continuă a modificărilor pentru a permite feedback rapid pe schimbările realizate, • feedback “neînfricat” între membrii echipei pentru a îmbunătăți colaborarea în echipă. Principiile sunt structura de rezistență a tranziției: oricând scopul unei practici nu e înțeles bine, principiile ajuta la luarea unei decizii pentru a opri practica respectivă sau pentru a îmbunătăți modul cum este pusă în aplicare. Unele practici sunt foarte importante pentru agilitate. De exemplu, o echipă cu adevărat auto-organizată care poate lua decizii singură, în niște limite setate de manageri, poate permite schimbări mult mai rapide decât un model decizional centralizat. Deși mecanismul echipelor auto-organizate este adesea neintuitiv și poate părea haotic, este dovedit ca fiind funcțional și este parte a unui nou tip de management care se ocupă de sisteme complexe, numit de obicei Management 3.0. Uneori rațiuni practice împiedică echipele de la aplicarea unui anumit principiu; de aceea practicile ar trebui adaptate pentru a echilibra aceste lipsuri. De exemplu, echipele care sunt forțate să lucreze într-un mod distribuit ar trebui ajutate prin utilizarea unor conexiuni non-stop video și audio pe un ecran mare, care poate părea aproape la fel ca și cum ar lucra în același birou. De asemenea, călătorii ale membrilor echipelor între birouri pentru a se cunoaște mai bine va întări colaborarea. Dacă cei care conduc afacerea au o dorință serioasă de a crește agilitatea ei, nu se vor opri la practici organizaționale precum adoptarea Scrum pentru toate echipele. Schimbări în alte zone sunt adesea necesare. Haideți să ne uităm îndeaproape la câteva dintre ele.

cum consideră cei mai iscusiți practicieni Lean Startup). Odata ce fluxul de valoare din industrie, fără a schimba practicile teh- este clar este vremea să: nice care sunt folosite. Agilitatea la acest • îl vizualizăm; nivel are nevoie de design software flexi• măsurăm cycle time: timpul scurs între bil, teste automate, specificații executabile, momentul în care începe o dezvoltare și integrare continuă și refactoring zilnic. În aceasta este finalizată; articolul precedent “Agilitatea presupune • măsurăm lead time: timpul scurs între Craftsmanship” s-a explicat în detaliu de ce. momentul în care un utilizator a cerut Articolul “Building Changeability in Design” ceva nou și momentul în care dezvoltarea http://www.mozaicworks.com/blog/buileste plătită; ding-changeability-in-design – explorează • îmbunătățirea continuă a fluxului rolul pe care îl are design-ul software atunci de valoare prin eliminarea zonelor unde când schimbarea este la ordinea zilei. valoarea este blocată și prin eliminarea risipei (orice nu ajută la dezvoltarea unor Feedback elemente de valoare). Principiul de a avea un feedback rapid tinde să se răspândească și către alte Îmbunătățirea Continuă departamente, în special către HR. Dacă Îmbunătățirea continuă este partea departamentul de HR obișnuia să facă cea mai dificilă deoarece necesită adesea evaluări bianuale, dezvoltatorii cu com- decizii dificile de business și management. portament agile cer evaluări mai dese ale Coaching-ul ajută foarte mult la menținerea performanțelor proprii. Practici cum ar fi ritmului de îmbunătățire; acestea sunt adeîntâlniri lunare one-on-one cu managerii sea invizibile pentru membrii echipei din direcți, feedback lunar de tipul “360 degrees“ cauza obișnuinței cu procesul curent de sau feedback continuu între membrii echipei lucru. ajută la îndeplinirea acestei nevoi.

Management 3.0

Rolul managementului se schimbă spre mai puțin control direct și mai mult către leadership. Unele dintre deciziile luate în mod uzual de manageri sunt delegate către echipe auto-organizate, iar managerul devine coach și ajută membrii echipelor în luarea deciziilor. La această situație nu se ajunge peste noapte ci necesită o perioadă de tranziție; vizualizarea ariilor de responsabilitate și a nivelurilor de delegare ale echipei este de ajutor atât pentru management cât și pentru echipe pentru a înțelege noul lor rol pe drumul pe care au pornit. Odata ce acest lucru s-a întâmplat, managerii au mai mult timp și energie pentru a se concentra pe gândire strategică.

Business Agility

Probabil cea mai dificilă zonă de schimbat este cea de business. Agilitatea este măsurată la acest nivel în termeni de cât de repede poate compania să intre pe o nouă piață sau să își schimbe modelul de business. Practicile și principiile “lean” joacă un rol important pentru acest tip de schimbare. Primul pas este de a identifica fluxurile de valoare ale noului model de business, adică pentru ce vor plăti clienții și care sunt pașii care trebuie făcuți pentru a crea această valoare. Dacă aceste lucruri sunt necunosCiclul de release cute, este timpul pentru a defini niște ipoteze Reducerea acestui ciclu de la un an la și de a le valida prin experimente în modul o lună sau mai puțin nu este posibilă, după Lean Startup (vezi articolul precedent despre

nr. 21/Martie, 2014 | www.todaysoftmag.ro

Concluzii

Agile și Lean nu contează în sine. Agilitatea contează. Agilitatea este proprietatea unei companii definită ca viteza cu care se schimbă când este nevoită. Companiile au cel mai adesea nevoie să se schimbe atunci când sunt forțate de piață, când decid să intre întro piață nouă sau când o plănuiesc creștere accelerată. Pentru a îmbunătăți agilitatea, trebuie definite în primul rând foarte clar obiectivele de business. Urmează adoptarea setului de principii și practici utile din agile și lean, ținând tot timpul cont de obiectivele de business. Practicile de la nivelul echipei precum cele definite de Scrum sau XP sunt doar o mică parte din îmbunătățirea agilității. Managerii trebuie să își modifice rolul de la cel tradițional la unul de leadership și gândire strategică. Departmentele HR trebuie să își adapteze procesele de evaluare pentru a permite feedback rapid și des, chiar dacă este transmis direct între membrii echipei. Liderii afacerii trebuie să se îndepărteze de viziunea tradițională de departamente compartimentalizate și să perceapă businessul ca flux de valoare, bottlenecks și eliminarea risipei. Agilitatea poate fi îmbunătățită și fără modificarea tuturor nivelelor din organizație. Amintiți-vă totuși că întotdeauna puteți face lucrurile mai bine.

management

Faze și procese în structurarea unui proiect

n majoritatea proiectelor software, exceptând poate cele de mici dimensiuni, managerii de proiecte folosesc metodologii bine cunoscute. Acestea pot fi reprezentate de sisteme consacrate - PMBOK (Project Management Body of Knowledge) sau PRINCE2 - dar pot fi redate și prin metodologii proprii, specifice unei anumite organizații. Deși aceste abordări au o serie de diferențe de orientare și folosesc terminologii specifice, toate ilustrează câteva puncte cheie: proiectele sunt livrate pe etape care implică folosirea anumitor procese comune managementului de proiecte. Augustin Onaciu

augustin.onaciu@fortech.ro Project Manager @ Fortech

În acest context, etapele sau fazele unui proiect sunt de o importanță crucială pentru un manager de proiect. Organizând lucrurile în etape, managerul de proiect se asigură că serviciile sau produsele livrate la finalul fiecărei faze sunt în conformitate cu scopul urmărit și, în același timp, că membrii echipei de proiect sunt pregătiți pentru următoarea fază a proiectului. În continuare voi sintetiza fazele generale ale unui proiect, precum și câteva aspecte practice din experiența proiectelor derulate și a relațiilor cu membrii echipei, clienți și alți factori interesați la nivelul unui proiect.

Stabilirea strategiei proiectului

În această primă fază din ciclul de viață al unui proiect se vor defini cerințele de business și se vor face propuneri în ceea ce privește abordarea și metodologiile care vor fi folosite în cadrul proiectului. În esență, această etapă are ca scop obținerea aprobării privind strategia de business care validează abordarea ce se dorește a fi folosită. Mai mult, e recomandat ca la finalul fiecărei etape a proiectului, echipa de proiect să revizuiască cerințele de business pentru a se asigura că acestea sunt în continuare valide și de actualitate.

Analiză și pregătire

Interacțiunea consistentă cu clientul și/sau acționarii alături de colaborarea cu membrii echipei reprezintă punctele cheie ale acestei etape, iar activitățile care o definesc pot include: • “descompunerea” componentelor proiectului printr-un Work Breakdown Structure (WBS); • recrutarea unei echipe de proiect sau completarea celei existente (dacă este cazul); • stabilirea unui plan de proiect și a unor

etape intermediare. Implicarea membrilor echipei în detalierea planurilor pentru etapele intermediare le oferă acestora un sentiment de responsabilitate și proprietate asupra etapelor, asigurând o implicare mai accentuată din partea acestora; • stabilirea unui program de colaborare cu echipele de suport (IT, operațiuni etc.).

Arhitectură și design

Aspectele implicate în această etapă fac referire la definirea și crearea elementelor ce vor fi livrate având ca punct de pornire strategia proiectului și cerințele de business. În cadrul acestei etape, în funcție de dimensiunea proiectului, este important și aportul unui analist de business care să lucreze cu clientul în vederea stabilirii elementelor de design și a detaliilor ce țin de arhitectură. În cazul în care sunt necesare schimbări la nivel de proces, e indicată folosirea unui Flow Chart sau a unei Swim Lane Diagram pentru a crea o reprezentare grafică a procesului. În acest punct, toate eforturile trebuie concentrate pentru a analiza și considera potențialele riscuri înainte de a începe dezvoltarea propriu zisă. Problemele prevăzute din timp sunt aproape întotdeauna mai ușor de abordat în etapa de design decât după ce este începută dezvoltarea. Realizarea unei etape de design complete și bine documentate oferă într-o anumită măsură o siguranță în ceea ce privește conformitatea serviciilor sau a produselor ce vor fi livrate, la fel cum o fază incompletă de design conduce de cele mai multe ori la omiterea obiectivelor și a așteptărilor clientului. Pentru proiectele în care sunt identificate riscuri de natură tehnică alături de alte elemente generatoare de nesiguranță e bine să fie luată în calcul și o etapă de analiză a fezabilității în care să dovedim validitatea

www.todaysoftmag.ro | nr. 21/Martie, 2014

management Faze și procese în structurarea unui proiect produsului prin dezvoltarea unui concept sau la stabilirea unor puncte de acțiune (demo) de dimensiuni reduse. viitoare pentru a asigura succesul viitoarelor inițiative.

Dezvoltare și testare

Odată ce proiectul dispune de o analiză completă și de un design suficient de detaliat, echipa de proiect poate începe dezvoltarea componentelor proiectului. Detalierea diverselor procese și a potențialelor abordări ale acestor faze nu reprezintă obiectul acestui articol, fiind în sine un subiect amplu de tratat.

Pregătire și validare

Închiderea proiectului

Deși această etapă nu se regăsește printre fazele cele mai așteptate sau dorite ale proiectului, ea trebuie realizată cu maximă responsabilitate pentru a nu interfera cu alte inițiative care s-ar putea răsfrânge întrun mod negativ asupra organizației. În cadrul acestei faze sunt necesare: • finalizarea și stocarea documentației proiectului; • realizarea unei analize post lansare pentru ca echipa de proiect să poată utiliza pe viitor experiența acumulată; • realocarea membrilor echipei în proiecte în care să își poată valorifica și aduce aportul în raport cu experiența și cunoștințele dobândite.

Obiectivul acestei etape este pregătirea pentru lansarea produsului, această fază putând implica: • pre g ăt i re a g h i du r i l or p e nt r u utilizatori; • asigurarea planului pentru suport; • transferarea datelor spre sistemele clientului; • identificarea elementelor care vor Pe parcursul tuturor acestor etape se asigura eficiența proiectului din momen- pot identifica o serie de procese specifice tul lansării; managementului de proiect. Acestea sunt: • validarea obiectivelor proiectului. • Managementul etapelor - în cadrul acestui proces se asigură faptul că se Suport și feedback îndeplinesc condițiile pentru finalizarea Asigurarea suportului în timpul fiecărei faze. Este esențială în acest protranziției proiectului de la echipa de proices înțelegerea elementelor care trebuie ect la echipa clientului reprezintă focusul livrate la finalul fiecărei faze. acestei etape. În multe cazuri, din diverse • Planificarea - inițial este necesară considerente, echipa de proiect este o planificare pentru întreg proiectul, realocată pe noi proiecte mult prea repede pentru ca ulterior să fie necesară o planiodată ce proiectul a fost livrat. În acest fel ficare cât mai detaliată pentru fiecare se diminuează conștientizarea beneficiilor fază în parte. Trebuie asigurat faptul că sau a potențialelor probleme apărute după proiectul dispune de resursele necesare, livrare din motive care nu țin în mod necede metodologii, de tool-urile de suport sar de echipa de proiect. Monitorizarea pentru fiecare fază astfel încât proiectul beneficiilor proiectului livrat este foarte să fie livrat la timp, în bugetul stabilit și importantă pentru moralul echipei și la standarde de calitate. poate ajuta la promovarea proiectului • Control - este esențială ținerea sub

Young spirit Mature organization A shared vision Join our journey! www.fortech.ro

nr. 21/Martie, 2014 | www.todaysoftmag.ro

control a scopului, a costurilor și o gestionare corectă a timpului, a riscurilor și a beneficiilor. Crearea de rapoarte care conțin informații relevante pentru stadiul și progresul unui proiect reprezintă o practică des întâlnită. • Managementul echipei - un manager de proiect este responsabil și pentru gestionarea echipei de proiect. Proiectele necesită de cele mai multe ori formarea unei echipe compuse din persoane care au cunoștințe și abilități diferite, iar managerul de proiect trebuie să fie capabil să determine componența echipei, păstrând un echilibru și acoperind totodată și potențialele nevoi de training. • Comunicare - în fiecare fază a proiectului este esențială stabilirea celui sau a celor care sunt responsabili de comunicarea cu membrii echipei, cu managementul și/sau cu acționarii. Comunicarea inadecvată și ineficientă este o problemă frecvent întâlnită în cadrul multor proiecte. • Integrare - multe proiecte nu sunt de sine stătătoare, ci sunt părți componente ale unor sisteme mai complexe care se reflectă asupra unor părți importante dintr-o afacere. Trebuie luată în calcul cu atenție interacțiunea dintre proiectul curent și restul componentelor sau inițiativelor existente. Așadar, abordarea cu atenția și grija necesară a tuturor acestor faze din ciclul de viața al unui proiect este deosebit de importantă pentru succesul proiectului, pentru calitatea produsului oferit clientului (extern sau intern) și pentru satisfacția și totodată evoluția echipelor.

programare

Tick Tock on Beanstalkd Message Queues

n general,timpul e o dimensiune restrictivă, cu atât mai mult în industria IT, unde orice produs, în orice stagiu, se raportează direct la această unitate de măsură. Mai mult decât atât, dezvoltatorii de software au clasificat timpul în categorii, iar resursele alocate unui proiect se concentrează în esență pe eficientizarea timpului pentru dezvoltarea produsului. În acest articol mă voi referi doar la timpul de execuție a unei aplicații într-o sesiune dată. Tudor Mărghidanu

tudor.marghidanu@yardi.com Software Architect @ Yardi România

Sunt sigur că mulți dintre voi cunoașteți vocabularului Beanstalkd: termenul de cozi de mesaje (message queue), mai ales dacă ați avut ocazia de a lucra cu • Job: Reprezintă mesajul în sine, serialiaplicații care își desfășoară operațiile într-un zat după dorință sau în funcție de librăria mod asincron. Aceste cozi de mesaje oferă de client folosită. câteva avantaje majore cum ar fi: • Tube: Namespace-ul folosit pentru • Decuplare– Separarea logicii aplicației, coadă. Beanstalkd suportă mai multe cozi • Scalabilitate – Mai mulți clienți pot in același timp. procesa date în același timp, • Producer: Procesul care se ocupă de • Redundanță – Erorile nu se pierd, iar punerea mesajelor în coadă pe tuburi. procesarea lor poate fi reluată. • Consumer: Procesele care consumă mesajele puse în coadă pe unul sau mai Există mai multe servicii prin care se pot multe tuburi. implementa cozi de mesaje, dar acest articol • Operations: Producătorul sau conse referă doar la Beanstalkd. sumatorul pot să efectueze următoarele operații pe joburile puse pe tuburi. Beanstalkd • put Beanstalkd este un serviciu cu o interfață • reserve generică folosit pentru a reduce latența între • delete procesele unei aplicații care necesită un timp • release mare de execuție. Datorită interfeței gene• bury rice, serviciul reprezintă un punct major de scalabilitate în cadrul aplicației dezvoltate. Problemă Beanstalkd nu introduce nicio limitare de Tind să cred că cel mai ușor se învață din implementare (limbaj sau serializare) deoa- exemple; de aceea, m-am gândit la următoarece se bazează pe PUSH sockets pentru rea problemă: comunicare și are un protocol simplu prin care face acest lucru. Pentru a înțelege mai “Să se construiască o aplicație web unde bine restul articolului este important să avem utilizatorii pot să încarce fișiere video în câțiva termeni de bază. Iată o descriere a diverse formate, astfel încât ulterior aceste www.todaysoftmag.ro | nr. 21/Martie, 2014

programare Tick Tock on Beanstalkd Message Queues video-uri să fie disponibile într-un player video pe una dintre paginile aplicației.” Ce e important la acest enunț e faptul că e suficient de vag încât să lase loc pentru scalabilitatea problemei, care, în mod evident, atrage scalabilitatea soluției. Dar frumusețea ei este dată, în acest caz, de simplitatea Beanstalkd. Deoarece, odată implementat clientul, execuția lui se poate scala atât vertical (mai multe procese de sistem pe aceeași mașină), cât și orizontal (mai multe procese de sistem pe mai multe mașini) folosind aceeași regulă inițială.

Să presupunem următoarea situație: clienții încarcă pe o pagină definită un set de fișiere video care intră într-un proces predefinit. Acest proces îndeplinește două funcții: prima funcție se ocupă de stocarea fișierului într-un layer de persistență predefinit (sistem de fișiere distribuit sau bază de date), iar a doua pregătește și scrie un mesaj în Beanstalkd, care conține informații ce trimit la referința din layer-ul de persistență. Din acest punct operația devine una asincronă și distribuită. Dacă raportul dintre numărul de consumatori și frecvența datelor de intrare a fost determinată corect, fișierele încărcate ar trebui să fie procesate într-un timp scurt. package MyApp::Globals; # ... More static properties ... use JSON::XS; use Beanstalk::Client; class_has ‚message_queue’ => ( is => ‚ro’, isa => ‚Beanstalk::Client’, default => sub { return Beanstalk::Client->new( { # NOTE: This usually should come from a configuration file... server => ‚localhost’, # Making sure we serialize/deserialize via JSON. encoder => sub { encode_json( shift() ); }, decoder => sub { decode_json( shift() ); }, } ); } ); package MyApp::Web::Controllers::Videos; # ... sub upload { my $self = shift(); # Retrieving the uploaded video. my $video = $self->req()->upload( ‚video’ );

Figura ilustrează cum ar trebui să circule datele dintr-o parte în alta a aplicației și felul în care ar trebui să interacționeze aplicația web cu consumatorii folosind un layer de shared storage.

# Additional content and headers validation ... # Storing the video in the persistance layer ... my $object = MyApp::Globals->context() ->dfs()->raw_videos(

Objective C

jobs-cluj@yardi.com Yardi Romania

nr. 21/Martie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE { filename => $video->filename(), headers => $video->headers()->to_hash(), data => $video->slurp(), );

# ... additional user data }

# Making sure we use the right tube for sending the # data. MyApp::Globals->message_queue() ->use( ‚raw_videos’ ); # Storing the data in the queue... MyApp::Globals->message_queue() ->put( { priority => 10000, data => $object->pack(), # Serialization occurs automatically ... } ); }

}

Concluzii

Ca o notă personală, întotdeauna mi-au plăcut soluțiile simple și elegante care au un set redus de reguli și o terminologie simplă. Beanstalkd este un astfel de exemplu. În altă ordine de idei, este important să realizăm că adoptarea acestui serviciu reprezintă o muncă de integrare, într-o oarecare măsură, și roata nu ar trebui re-inventată în niciun punct de dezvoltare a aplicației. Un alt aspect important este faptul că, folosind un sistem distribuit în această manieră, el permite atât compresarea/dilatarea timpului, cât și fragmentarea execuției într-un mod evident, iar ceea ce ar dura câteva săptămâni, rulând în mod secvențial, se poate reduce la câteva zile sau chiar ore în funcție de durata procesului de bază.

Pros

• Rapididate Consumatorii lucrează în bucle continue cerând mesaje de • Persistență la Beanstalkd pe măsură ce procesează datele, marcând status-ul • Nu impune niciun model de serializare acțiunii în urma procesării, astfel încât să putem identifica atât numărul de rulări corecte, cât și erorile care au apărut pe parcurs. Cons Mai mult decât atât, în cazul erorilor putem relua mesajele marcate • Modul distribuit este suportat doar în client ca fiind eronate odată ce problema a fost corectată ulterior. • Lipsa model securitate Un alt aspect important este că paralelizarea consumatorilor se face prin procese de sistem, ceea ce înseamnă un management ușor. În același timp, se scoate din calcul locking-ul unor resurse la nivel de aplicație și implicit memory leaks. # Getting messages only from these tubes ... MyApp::Globals->message_queue() ->watch_only( ‚raw_videos’ ); while( 1 ) { # Retrieving a job from the message queue and # marking it as reserved... my $job = MyApp::Globals->message_queue() ->reserve(); eval { my $data = $job->args(); # Automatic data deserialization ... # Doing the magic on the data here ... }; # In case of an error we signal the error in # back-end and budy the job. if( my $error = $@ ) { $logger->log_error( $error ); $job->bury(); } else { $job->delete(); # If everything is ok we simply delete the job # from the tube!

www.todaysoftmag.ro | nr. 21/Martie, 2014

programare

Înapoi în viitor: Http 2.0

scurtă privire în istoria și dezvoltarea protocolului HTTP (Hypertext Transfer Protocol), pentru a înțelege mai bine modificările propuse pentru versiunea 2.0.

Nevoia de evoluție a protocolului HTTP Rareș Rusu

rares.rusu@betfair.com Inginer Software @ Betfair România

HTTP este unul din protocoalele care au alimentat evoluția spectaculoasă a Internetului: permite clienților să comunice cu serverele, fundamentul a ceea ce este azi Internetul. A fost conceput inițial ca un protocol simplu care să asigure transferul unui fișier de la un server către un client (versiunea 0.9 propusă în 1991). Succesul incontestabil al protocolului face ca azi miliarde de dispozitive să fie capabile să comunice folosind HTTP (versiunea curenta 1.1). Variația extraordinară de conținut și de aplicații disponibile azi, împreună cu cerințele utilizatorilor pentru interacțiuni rapide împing HTTP 1.1 peste limitele imaginate de cei care l-au proiectat. Prin urmare, pentru a satisface următorul salt în performanța Internetului este necesară o nouă versiune a protocolului, care să rezolve limitările actuale și să permită o nouă clasă de aplicații, mai performante.

Ca o analogie cu instalațiile sanitare ale unei locuințe, putem considera lățimea de bandă ca fiind diametrul unei țevi pentru apă. Un diametru mai mare permite să treacă mai multă apă. Pe de altă parte, în situația în care țeava e goală, indiferent de diametrul ei, apa va ajunge la destinație doar după ce va străbate întreaga lungime a țevii (latența). Este intuitiv să judecăm performanța unei conexiuni în funcție de lățimea de bandă (o conexiune de 10 Mbps este mai bună decât una de 5 Mbps), dar lățimea de bandă nu este singurul factor care controlează performanța: de fapt, din cauza particularității aplicațiilor web de a utiliza mai multe conexiuni de scurtă durată, lantența influențează mai mult performanța decât lățimea de bandă.

Latență versus lățime de bandă

Latența și lățimea de bandă sunt două caracteristici care dictează performanța traficului de date în rețea. Latența (dus/dus-întors) se referă la durata în care un pachet se propagă de la sursă la destinație(dus) și retur(dus-întors) Lățimea de bandă este capacitatea maximă a unui canal de comunicare.

nr. 21/Martie | www.todaysoftmag.ro

Figura 1. Evoluția timpului de încărcare a unei pagini (milisecunde) în funcție de lățimea de bandă (Megabit/s). Reprodusă din Mike Belshe - More Bandwidth Doesn’t Matter (much)3

Figura 2. Evoluția timpului de încărcare a unei pagini (milisecunde) în funcție de latență. Reprodusă

de pachete trimise către client pe măsură ce primește confirmarea livrării lor (algoritmul slow start). Astfel, lățimea de bandă nu va fi folosită integral imediat ce se realizează conexiunea. Prin contrast, majoritatea aplicațiilor web declanșează multe conexiuni de scurtă durată pentru a transfera conținut (conform HTTP Archive2 o aplicație web este compusă în medie din 90 de resurse - conținut HTML, Javascript, imagini etc.).

din Mike Belshe - More Bandwidth Doesn’t Matter (much)3

Concluzia acestor observații este că orice îmbunatățire în lantența comunicației are un efect direct asupra vitezei aplicațiilor web. Dacă prin îmbunătățirea protocoalelor am putea reduce necesarul de comunicare între cele două capete ale unei conexiuni, atunci am putea transfera aceleași date întrun timp mai scurt. Acesta este unul din obiectivele asumate de HTTP 2.0.

Scurtă incursiune în TCP

Pentru a înțelege limitările versiunii 1.1 este util să ne uităm puțin la protocolul TCP (Transmission Control Protocol), care asigură transportul datelor între client și server: • la stabilirea unei conexiuni este nevoie de un schimb de trei mesaje (three-way-handshake) între client și server, înainte de trimiterea oricărui pachet de date. Prin urmare latența conexiunii se reflectă direct în viteza cu care se transferă datele. • TCP este optimizat pentru conexiunile cu durată mare și pentru transferul unei cantități mari de date pe aceeași conexiune: după stabilirea unei conexiuni un server va crește gradual numărul

Deși funcționarea HTTP nu este condiționată de TCP ca protocol de transport, unul din obiectivele HTTP 2.0 este modificarea standardului pentru a profita de aceste particularități ale nivelului de transport în scopul îmbunătățirii substanțiale a vitezei percepute de utilizatorii aplicațiilor web.

Limitările HTTP 1.1

Unul din obiectivele HTTP 1.1 a fost de a îmbunătăți performanțele HTTP. Din păcate, deși standardul specifică lucruri cum ar fi procesarea cererilor în paralel (request pipelening), practica a invalidat aplicarea lor din cauza imposibilității utilizării corecte. În acest moment majoritatea browser-elor dezactivează în mod implicit această opțiune. Drept urmare, HTTP 1.1 impune o ordine strictă a cererilor adresate unui server: un client inițiază o cerere către server și trebuie să aștepte răspunsul înainte de a iniția altă cerere pe aceeași conexiune. Astfel, un răspuns de dimensiuni mai mari poate bloca o conexiune fără a permite procesarea altor cereri ale clientului în acest timp. Mai mult, serverul nu are posibilitatea de a acționa conform priorității cererilor unui client.

Dezvoltatorii de aplicații web au găsit soluții de evitare a acestor limitări, care în acest moment sunt considerate practici recomandate pentru performanța aplicațiilor web: • majoritatea browser-elor deschid până la șase conexiuni simultane către același domeniu - ca o alternativă la imposibilitatea practică de a cere mai multe resurse în paralel pe aceeași conexiune; am menționat deja că o pagină este compusă în medie din 90 de resurse; dezvoltatorii web au supralicitat această facilitate și distribuie conținut pe domenii diferite (domain sharding) pentru a forța descărcarea cât mai multor resurse în paralel • fișierele de același tip (Javascript, CSS - Cascading Style Sheets, imagini) sunt concatenate într-o singură resursă (resource bundling, image sprites) pentru a evita penalizarea impusă de HTTP la descărcarea multor resurse de dimensiuni mici; unele fișiere sunt incluse direct în sursa paginii pentru a evita complet o nouă cerere HTTP. Deși aceste metode sunt considerate “bune practici de dezvoltare” ele derivă din limitările curente ale standardul HTTP și creează alte probleme: utilizarea mai multor conexiuni și a mai multor domenii pentru a servi o singură pagină care duce la congestionarea rețelelor, operații suplimentare inutile (căutari DNS, inițieri de conexiuni TCP) și încărcarea suplimentară a serverelor și a intermediarilor din rețea (mai multe socketuri ocupate pentru a servi mai multe cereri); concatenarea fișierelor de același tip împiedică stocarea lor eficientă pe client (caching) și contravine modularității

www.todaysoftmag.ro | nr. 21/Martie, 2014

programare Înapoi în viitor: Http 2.0 aplicațiilor. HTTP 2.0 adresează aceste din cadre (frame). Cadrele pot fi livrate în limitări. orice ordine și vor fi reasamblate de către client. Acest mecanism de descompunere și recompunere a mesajelor este similar cu cel HTTP 2.0: design și obiective existent la nivelul protocolului TCP. Este Efortul de îmbunătățire a standardu- cea mai importantă schimbare din HTTP lui HTTP este unul considerabil. Ținând 2.0, pentru că permite dezvoltatorilor web cont de răspândirea actuală a protocolului următoarele: intenția este de a aduce îmbunătățiri clare • să inițieze mai multe cereri în paralel cu privire la aspectele menționate mai sus, și să proceseze mai multe răspunsuri în nu de a rescrie sau modifica substanțial paralel, specificațiile actuale. • să folosească o singură conexiune Principalele intenții ale noii versiuni: pentru aceste cereri și răspunsuri, • să îmbunătățească viteza de încărcare • să reducă timpul de încărcare al unei a paginilor față de versiunea 1.1, pagini datorită reducerii latenței, • să utilizeze paralelizarea cererilor dar • să elimine din aplicațiile web modiprin intermediul unei singure conexiuni ficările specifice versiunii 1.1 făcute cu TCP, scopul de a îmbunătăți performanța. • să păstreze semantica existentă în versiunea 1.1 cu privire la metode, Server push coduri de raspuns, header-e, Una din limitările evidente in HTTP • să definească interacțiunea cu versi- 1.1 este imposibilitatea serverului de a triunea 1.1. mite răspunsuri multiple pentru o singură cerere a unui client. În cazul unei pagini Paralelizarea cererilor în HTTP 2.0 web,serverul știe că pe lângă conținutul Schimbarea majoră introdusă în versi- HTML clientul va avea nevoie și de resurse unea 2.0 este felul în care conținutul unei Javascript, imagini, etc. . De ce să nu elicereri HTTP este transmis între server și minăm complet nevoia clientului de a client. Conținutul este binar, cu scopul de cere aceste resurse și să dăm posibilitatea a permite mai multe cereri și răspunsuri în serverului să le trimită ca răspunsuri supliparalel peste aceeași conexiune TCP. mentare cererii inițiale a clientului? Aceasta Următoarele noțiuni sunt utile pentru a este motivația funcționalității numită serînțelege mai bine cum anume se realizează ver push. Funcționalitatea este la fel cu ceea paralelizarea cererilor și răspunsurilor: ce se realizează în HTTP 1.1 prin inclu• Stream - un schimb de mesaje derea conținutului unor resurse direct în bidirecțional în cadrul unei conexiuni. pagina trimisă clientului (inlining). Totuși, Fiecare stream are un identificator și o marele avantaj al metodei server push este prioritate. că dă posibilitatea clientului de a stoca în • Frame (cadru) - unitatea de bază de cache resursele astfel primite evitând apecomunicare în HTTP 2.0 conținând o luri ulterioare. zonă de header care identifică stream-ul din care face parte și o zonă de date. Compresia header-elor • Mesaj - o secvență de cadre (frame) În HTTP 1.1 fiecare cerere făcută de care formează un mesaj în HTTP (cerere client conține toate header-ele aferente sau răspuns). domeniului serverului. În practică aceasta adaugă între 500 și 800 de bytes fiecărei În cadrul unei conexiuni pot exista un cereri. Îmbunătățirea adusă de HTTP 2.0 număr nelimitat de stream-uri bidirectio- este de a nu mai transmite header-ele care nale. Comunicarea în cadrul unui stream nu se schimbă.Ne bazăm pe faptul că avem se realizează prin mesaje, care sunt formate o singură conexiune deschisă cu serverul,

nr. 21/Martie, 2014 | www.todaysoftmag.ro

deci serverul poate deduce că o cerere nouă va avea aceleași header-e asemena celei precedente, în caz că nu specificăm altceva. În plus, toată informația cuprinsă în header-e este comprimată pentru eficientizare.

Scurtă privire în viitor

HTTP 2.0 este încă un standard aflat în lucru. Majoritatea ideilor care stau la baza lui au fost preluate din protocolul SPDY, inițiat de Google. SPDY continuă să existe în paralel cu efortul de standardizare a HTTP 2.0 pentru a oferi un teren de încercare și validare a ideilor experimentale. Calendarul anunțat în acest moment presupune ca în toamna anului 2014 specificația HTTP 2.0 să fie finală, urmând ca după acel moment să fie disponibile implementări. Bazat pe succesul extraordinar al HTTP, versiunea 2.0 încearcă să corecteze limitările actuale și să ofere mecanisme cu care dezvoltarea Internetului să poată fi susținută în continuare.

Referințe 1. Ilya Grigorik - High Performance Browser Networking [http://chimera.labs.oreilly.com/ books/1230000000545/index.html] 2. HTTP Archive [http://www.httparchive.org/ index.php] 3. Mike Belshe - More Bandwidth Doesn’t Matter (much) [https://docs.google.com/a/chromium.org/ viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3J nfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2]

programare

Bibliotecă JavaScript de logare pentru dezvoltatori

ea mai folosită metodă de logging a evenimentelor pentru depanarea (debugging) codului în JavaScript este prin apelarea „console.log(mesaj)”. Aceasta are ca efect afișarea mesajului în consola pentru dezvoltatori care folosesc browser-ul. Se mai pot folosi „console.warn(mesaj)” și „console.error(mesaj)” pentru înregistrarea avertismentelor, respectiv a erorilor. Bogdan Cornianu

bogdan.cornianu@3pillarglobal.com Java developer @ 3Pillar Global

Obiectul „console” este un obiect host (gazdă), ceea ce înseamnă că el este oferit de către mediul în care rulează script-ul JavaScript. Deoarece este un obiect gazdă, el nu este descris în nicio specificație. De aceea, implementările pot să difere sau în cazul Internet Explorer 7 să lipsească cu desăvârșire. Dacă există această funcționalitate în majoritatea browser-elor, de ce ar mai fi nevoie de o bibliotecă pentru același scop? Pentru a realiza diverse funcții suplimentare cum ar fi căutarea, filtrarea și formatarea mesajelor. Proiectul la care lucrez este o aplicație web cu partea de server scrisă în Java şi cea de client în JavaScript. Clientul pentru care am dezvoltat această soluție nu ne putea oferi log-urile de pe server într-un timp rezonabil. Pentru a putea rezolva defectele care apăreau cât mai repede, s-a implementat pe partea de server un mecanism prin care atunci când se arunca o excepție, se colectau informații despre tabelele implicate și împreună cu stack trace-ul Java erau arhivate și trimise către browser pentru a putea fi descărcate on the fly de către client. Acesta le putea trimite ulterior nouă pentru a investiga și remedia problema. În ceaa ce privește partea de front-end, pentru investigarea unei probleme semnalată

de către client,dar pe care noi n-o puteam reproduce, am apelat la conexiuni desktop la distanță, am instalat Firebug și am urmărit consola oferită de acesta. Pentru a îmbunătăți procesul şi a face mai facilă raportarea defectelor ne-am gândit să replicăm și pe partea de client funcționalitățile mecanismului de pe server. Așa s-a născut „Logger”, o bibliotecă JavaScript pentru înregistrarea evenimentelor. Ceea ce o diferențiază faţă de alte biblioteci asemănătoare este posibilitatea de salvare a evenimentelor atât în consola pentru dezvoltatori cât și în spațiul local de stocare al browser-ului (local storage) precum și posibilitatea exportului log-urilor într-un fișier text. Câteva cuvinte despre cum se folosește librăria. Includerea librăriei este foarte simplă, realizându-se cu o singură linie: “<script type=”text/javascript” src=”Logger.js”></script>”

Există două moduri prin care se pot înregistra evenimente:

1. Folosind Logger.log(nivel, mesaj, locație) >Logger.log(Logger.level.Error, „mesaj de eroare”, Logger.location.All); [ERROR]> mesaj de eroare

Deoarece am folosit ca locație ”All”,

www.todaysoftmag.ro | nr. 21/Martie, 2014

programare Bibliotecă JavaScript de logare pentru dezvoltatori mesajul va fi salvat și în spațiul local de stocare al browser-ului. >localStorage; Storage {1393948583410_ERROR: “mesaj de eroare”, length: 1} >

2. Folosind metode specifice pentru fiecare eveniment: Logger. error(mesaj, locație), Logger.warn(mesaj, locație), Logger. info(mesaj, locație)

>Logger.error(„al doilea mesaj de eroare”, Logger. location.All); [ERROR]> al doilea mesaj de eroare Logger.warn(„atentionare”, Logger.location.All); [WARN]> atentionare Logger.info(„informare”, Logger.location.All); [INFO]> informare

La apăsarea butonului vom primi următorul mesaj: Apăsarea butonului ”OK”, în funcție de setările browser-ului va salva înregistrările într-un fișier în locația prestabilită sau va afișa un dialog de salvare cu numele fișierului format din data și ora curentă. Dacă deschidem fișierul, vom vedea toate mesajele precum și eroarea de JavaScript. [ERROR]> mesaj de eroare [ERROR]> al doilea mesaj de eroare [WARN]> atentionare [INFO]> informare [ERROR]> Uncaught Error: eroare. la linia 19 in http://localhost:8080/logger/main.html

Fiecare eveniment este salvat în local storage sub forma de cheie și valoare. Cheia este formată din ”timestamp_nivel”, iar Putem observa că eroarea a apărut în fișierul ”main.html” la valorea conține mesajul. linia 19, locul în care am creat butonul la a cărui apăsare se aruncă Pentru a lista toate evenimentele împreună cu data la care s-au eroarea JavaScript: petrecut putem folosi Logger.getEvents(nivel): >Logger.getEvents(Logger.level.All); [ERROR]> mesaj de eroare [ERROR]> al doilea mesaj de eroare [WARN]> atentionare [INFO]> informare

<button onclick=”throw new Error(‚eroare.’)”>Buton </button>

Biblioteca folosește şablonul de proiectare ”Revealing Module” pentru a expune funcțiile ce pot fi apelate de către dezvoltatori. Cea mai simplă soluție pentru a scrie datele din local stor-

În continuare voi prezenta funcționalitatea care, după părerea noastră, va face programatorii mai productivi și anume exportarea tuturor mesajelor înregistrate în spațiul local de stocare al browserului într-un fișier text. Astfel programatorii pot avea acces mai rapid la mesajele și evenimentele petrecute în timpul rulării aplicației. Exportul înregistrărilor în fișierul text se poate face apelând Logger.exportLog() sau setând o funcție de callback în cazul apariției unei erori în aplicație: age într-un fișier era folosirea unei biblioteci JavaScript numită ”FileSaver.js” ce folosește API-ul FileSystem sau furnizează o ”Logger.onError(exportLog, suppressErrorAlerts, errorCallback)” alternativă la acesta în browser-ele care nu-l suportă nativ. Am vrut să evit folosirea de biblioteci suplimentare și astfel am recurs la o Dacă ”exportLog” este setat pe true, atunci eroarea apărută precum și toate înregistrările prezente în spațiul de stocare al browser-ului vor fi salvate într-un fișier text. În cazul în care ”suppressErrorAlerts” este setat pe true, eroarea apărută nu va mai fi afișată și în consola browser-ului. ”errorCallback” reprezintă funcția ce va fi executată în cazul apariției unei erori. Următoarea secvență de cod va afișa un mesaj de dialog în soluție alternativă. momentul în care apare o eroare de JavaScript. Logger.onError(true, true, function(errorMsg, url, lineNumber) { var errorMessage = errorMsg + ‚ la linia ‚ + lineNumber + ‚ in ‚ + url, raspuns = ‚’; Logger.error(errorMessage, Logger.location.LocalStorage); raspuns = confirm(„A aparut o eroare. Doriti sa salvati inregistrarile intr-un fisier text?”);

saveToDisk: function(content, filename) { var a = document.createElement(‚a’),

blob = new Blob([content], {‚type’ : ‚ application/octet-stream’}); a.href = window.URL.createObjectURL(blob); a.download = filename; a.click(); }

Am creat un element ancoră la a cărui atribut href am asociat un obiect URL creat dintr-un blob. Blob-ul reprezintă un obiect immutable (imuabil) ce conține date brute. Numele fișierului care este format din data și ora curentă sunt asociate atributului download,apoi se apelează funcția click() ce va avea ca efect Putem testa dacă acest cod funcționează prin adăugarea unui afișarea dialogului de salvare al browser-ului. buton la al cărui eveniment onClick() vom arunca o eroare: if (raspuns === true) { Logger.exportLog(); } return true;//suppress errors on console });

”<button onclick=”throw new Error(‚eroare.’)”>Buton</ button>”

nr. 21/Martie, 2014 | www.todaysoftmag.ro

Pentru a intercepta erorile care apar în JavaScript am creat

TODAY SOFTWARE MAGAZINE inițial o variabilă initialWindowErrorHandler ce conține o referință la window.onerror. Inițial, window.onerror scrie toate mesajele de eroare în consolă. În funcția onError() dacă parametrul errorCallback nu este nedefinit atunci se va executa funcția primită ca parametru la fiecare eroare JavaScript. saveToDisk: function(content, filename) { var a = document.createElement(‘a’), blob = new Blob([content], {‘type’ : ‘application/octet-stream’}); a.href = window.URL.createObjectURL(blob); a.download = filename; a.click(); }

Mozilla Developer Network 1. Create Object URL: https://developer.mozilla.org/en-US/docs/Web/API/ URL.createObjectURL 2. Blob: https://developer.mozilla.org/en-US/docs/Web/API/Blob 3. File System API: https://developer.mozilla.org/en-US/docs/WebGuide/API/ 4. Window.onerror: https://developer.mozilla.org/en-US/docs/Web/API/ GlobalEventHandlers.onerror Github 5. FileSaver.js: https://github.com/eligrey/FileSaver.js JSFiddle 6. Save to disk example: http://jsfiddle.net/koldev/cW7W5/

Se poate reveni oricând la comportamentul default al lui window.onerror prin apelarea Logger. resetWindowErrorHandler(). 7. Revealing Module Pattern: carldanley.com/js-revealing-module-pattern/ Aceasta este versiunea inițială a Logger-ului, fără funcționalități avansate. În viitor ar putea fi îmbunătățit prin adăugarea unei limite maxime a numărului de înregistrări, posibilitatea de a șterge anumite înregistrări după tipul evenimentului, filtrarea înregistrărilor exportate după tipul acestora, realizarea unei interfețe grafice pentru vizualizarea înregistrărilor existente și posibilitatea generării de statistici pentru a determina cât de stabilă a fost aplicația pe o anumită perioadă de timp, posibilitatea de a seta numele fișierului la o valoare ce poate fi configurată.

Referințe:

Our core competencies include:

Product Strategy

Product Development

Product Support

3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world. Our oﬀerings are business focused, they drive real, tangible value.

www.3pillarglobal.com

www.todaysoftmag.ro | nr. 21/Martie, 2014

programare

Cum să scrii un generator de cod bazat pe template-uri flexibile

acă ar fi să stăm să ne gândim, majoritatea dintre noi ne-am lovit cel puțin o dată în viață de situația în care bucăți similare de cod au fost scrise și rescrise, bucăți care diferă doar prin anumite detalii. Te-ai întrebat vreodată – în timp ce făceai copy-paste dintr-o clasă în alta, și poate apoi în alte 50 de clase – de ce faci acest lucru repetitiv, predispus erorilor și pe deasupra plictisitor când ar putea fi foarte ușor efectuat de o mașină? Mașinile sunt cele mai indicate pentru astfel de task-uri, dar de ce le evităm? În acest articol va fi prezentat un program care generează cod pe baza unui fișier xml de intrare și a unor template-uri flexibile. Generarea de cod sună mai mult ca o cerință pentru inginerii NASA, decât pentru un grup de programatori din Cluj care lucrează în industria de outsourcing. Mare ne-a fost surpriza când, într-o zi călduroasă și lungă de vară clientul ne anunța bucuros un nou topic: o aplicație care să genereze cod – și nu una oarecare, ci una care să genereze cod pentru mai multe platforme și pentru diferite limbaje de programare, folosind ca input un fișier xml și niște template-uri. Pentru a înțelege mai bine problema, să luăm un exemplu. Să ne imaginăm că avem de realizat o aplicație care presupune gestionarea unei magazii folosind baze de date care stochează diferite tipuri de aparate electronice și electrocasnice. Aceasta este o aplicație clasică cu baze de date care poate conține mai multe formuri și o mulțime de clase de tipul acces la date – DAL (Database Access Layer). Dacă această magazie este mică și conține doar câteva tipuri de produse atunci scrierea claselor de acces la date nu pare să fie o mare problemă. Dar cum ar fi să stocăm toate tipurile de aparate de la telefoane mobile până la monitoare, routere sau DVD playere și să creăm pentru fiecare categorie tabele? Scrierea tuturor claselor de acces la date, chiar dacă ele diferă doar puțin una de cealaltă, nu pare a fi totuși o problemă. Doar că în acest moment rezolvarea task-ului ar presupune o alocare mare de timp. O mică modificare sau o nouă cerință adusă aplicației poate genera schimbări în toate clasele, care prin mecanismul de copy-paste dintr-o clasă în alta ar duce la erori neașteptate. Într-un scenariu de acest tip, folosirea un generator de cod ne-ar ușura enorm munca: ar genera toate clasele necesare, în plus, pentru anumite modificări ulterioare ar implica schimbări doar în fișierele template. Astfel, refactorizarea codului ar fi ușoară și rapidă. Un generator de cod bine scris și flexibil, poate fi o unealtă ajutătoare în orice proiect.

Citirea fișierului de intrare

Fișierul de intrare trebuie să conțină toate informațiile necesare umplerii template-urilor. Acestea trebuie să fie dispuse într-o formă cât mai structurată și ușor de analizat de către o mașină. În acest articol va fi folosit un fișier xml. Vom exemplifica un caz în care codul generat va fi unul de C++, bazat pe librăria STL. Fișierul de intrare va trebui să conțină cât mai multe informații despre categoriile (<category>) care vor fi mapate către clase/table, cu câmpurile și proprietățile asociate fiecăreia (<field>). Este indicată folosirea structurii din fișierul xml prezentat, întrucât va ușura scrierea fișierelor template. Un fișier xml de intrare pentru o categorie oarecare, ar putea fi: <?xml version=”1.0”?> <categories> <category name=”smartphone”> <field name=”vendor” type=”string” cpptype=”std::string” sql-type=”VARCHAR(30)”/> <field name=”os” type=”string” cpp-type=”std::string” sql-type=”VARCHAR(10)”/> ... </category> <category name=”monitor”> <field name=”vendor” type=”string” cpptype=”std::string” sql-type=”VARCHAR(30)”/> <field name=”diagonal” type=”number” cpp-type=”int” sql-type=”INTEGER”/> ... </category> ... </categories>

Acest fișier xml conține de fapt o listă de categorii, fiecare categorie având la rândul ei o listă de câmpuri. Fiecare câmp are un nume, un tip și un tip specific platformei pentru care urmează a fi generat fișierul de ieșire. Salvarea informației specifică platformei în tag-uri nu este prea convenabilă nici măcar pentru două platforme. Ar fi mai ușor să stocăm doar un tip, independent de platformă, precum “string” sau “number” și să stocăm informația Arhitectura unui generator de cod de mapare spre platforma într-o altă parte a xml-ului, dar pentru Un generator de cod este structurat în două mari componente: a ușura exemplificarea, această informație va rămâne stocată în partea care citește și analizează fișierul de intrare și partea care tag-uri. Legat de parsarea unui xml – nimic nou sub soare; există analizează fișierele template și generează fișierele de ieșire. Prima o mulțime de librării sau parsere disponibile care pot fi folosite. componentă pasează datele celei de-a doua urmând un format bine definit. Prin urmare, orice modificare adusă acestui format Formatul intermediar necesită modificarea ambelor părți implicate. Datele analizate din fișierul de intrare trebuie stocate într-o primă fază într-un format intermediar, dar și în momentul în care

nr. 21/Martie, 2014 | www.todaysoftmag.ro

acestea sunt pasate către cealaltă componentă a generatorului. Detaliile acestui format nu sunt importante; ele sunt specifice, în funcție de cerințele și problema care trebuie adresată. De asemenea, ele depind și de cât de generic se dorește a fi generatorul de cod, și multe altele. Ar trebui totuși să respecte anumite cerințe: • categoriile să fie ușor de găsit, • câmpurile din fiecare categorie să fie accesibile.

Generarea fișierelor de ieșire

Aceasta este cea mai delicată parte a generatorului de cod. Este și cea mai importantă, dar și cea mai complicată. Dacă se dorește scrierea unui generator de cod flexibil și reutilizabil, hard-codările anumitor informații, precum platforma sau limbajul pentru care se urmărește a fi generat codul sau chiar bucăți din codul final sunt de evitat. Cea mai bună soluție sunt template-urile.

Fișierele template

Fișierele template conțin bucăți asemănătoare cu codul și reprezintă de fapt formatul fișierelor pe care le dorim la ieșire – în acest caz, clase C++ – dar folosesc totodată și un set de instrucțiuni pentru a putea umple informațiile lipsă la generarea fișierelor de output. Părțile care lipsesc sunt exact informațiile extrase din fișierul de intrare: atributele categoriilor și câmpurile acestora. Cel mai evident exemplu este numele clasei. Acesta depinde de numele categoriei. În fișierul template, numele clasei va avea un substituent, care va fi ulterior înlocuit în componenta de procesare a template-ului, cu un nume valid al unei categorii. Un astfel de proces va fi numit “substituirea unei variabile”. Dar pentru generarea unei clase complete, substituirea variabilelor nu este suficientă. De exemplu, este necesară declararea membrilor clasei bazându-ne pe câmpurile din fișierul de intrare. Astfel, avem nevoie de un fel de buclă care iterează prin toate câmpurile. De asemenea poate să apară cazul în care este necesară luarea unei decizii pe baza informațiilor din fișierul de intrare; astfel, vom avea nevoie de un fel de evaluare a unei expresii logice și probabil niște ramificări cu intrucțiuni de cod diferite. Variabile, bucle, instrucțiuni condiționale – sintaxa template-ului începe să semene cu cea a unui limbaj de programare. Scrierea unui parser pentru un astfel de template, care să fie și ușor de modificat în cazul în care apar schimbări în template, nu este ușoară. Dar înainte de a detalia parserul pentru fișierele template, să aruncăm o privire asupra unui posibil fișier de template: class <$category.name$> { public: <$category.name$>(); ~<$category.name$>(); <@foreach <$field$> in <$category.fields$> @> <$field.cpp-type$> get<$field.name$>(); void set<$field.name$>( const <$field.cpp-type$> &value); <@endforeach@> private: <@foreach <$field$> in <$category.fields$> @> <$field.cpp-type$> <$field.name$>; <@endforeach@> }

Acesta este un model de template pentru o clasă care ar putea reprezenta o categorie. Conține substituiri ale variabilelor și bucle. Variabilele sunt marcate cu simbolurile „<$” si „$>”, iar instrucțiunile cu „<@” si „@>”. Acești delimitatori permit oarecum citirea fișierului template, deși template-uri mai complexe ar părea indescifrabile. Când fișierul template întră în componenta de parsarea este analizat și completat: toate variabilele vor fi

înlocuite cu valori valide și tot ceea ce reprezintă bucla va fi evaluat iterație cu iterație.

Parsarea fișierului template

Scrierea unui parser pentru fișierul template pare o opțiune plauzibilă, însă nu e o idee chiar așa bună din mai multe motive. În primul rând – deși exemplul ilustrat nu este complicat – în viața reală un template are o sintaxă mai complexă, cu mult mai multe simboluri și cuvinte cheie. Scrierea unui parser pentru un minilimbaj de programare necesită timp și energie, iar rezultatul poate fi imprevizibil din cauza obstacolelor care pot apărea. În al doilea rând, de ce să reinventăm roata de la căruță? Există soluții fiabile care pot genera parsere dintr-un set bine definit de reguli. Cel mai cunoscut generator de parsere este perechea lex – yacc. Lex este folosit pentru a genera un analizor lexical și yacc este un generator de parsere. Atât lex cât și yacc sunt soluții open source, însă în exemplul din articol au fost folosite versiunile GNU, flex – bison. Procesarea fișierelor template si generarea fișierelor de ieșire este realizată în trei pași, ilustrați în imaginea de mai jos: Nu vom prezenta prea multe detalii, doar o scurtă prezentare a fiecărui pas.

Spargerea datelor de intrare în simboluri

În primul pas, fișierul template este analizat și spart în simboluri. Este exact ceea face preprocesorul C (printre multe altele). De fapt, fiecare grup de caractere care este considerat important este notat, dar celelalte sunt ignorate. De exemplu, grupul de caractere „<$” va fi notat cu „VAR_B” și împreună – notația și evaluarea sa – formează un simbol. O linie de cod C++ din fișierul template care nu conține nici un cuvânt cheie va fi notate ca “text”. Grupuri de caractere fără importanță sunt de exemplu comentariile sau spațiile libere (în anumite cazuri). Această spargere în simboluri este exact ceea ce face analizorul lexical generat de flex. Flex generează acest proces pe baza unui fișier de intrare. Fișierul de intrare al Flex conține un set de reguli care descriu ce fel de simboluri vor fi recunoscute și cum arată acestea. Regulile sunt sub forma unei expresii regulate și bucăți de cod care urmează a fi executate când expresiile regulate sunt îndeplinite pe o anumită parte din fișierul de intrare. Analizorul generat de Flex citește fișierul template de intrare caracter cu caracter și încearcă să mapeze peste regulile descrise. Imediat ce o potrivire a fost găsită, bucata de cod asociată se execută. Flex generează practic funcția yylex() care, la fiecare apel returnează următorul simbol din template.

Validarea gramaticii și construirea arborelui de sintaxă

În acest pas secvența cu simbolurile de intrare este validată împotriva legilor gramaticale care descriu limbajul template. Acest pas e efectuat de parser-ul generat de Bison. Bison generează parser-ul din fișierele de intrare care conțin regulile care descriu limbajul. Regulile gramaticale trebuie să descrie un LALR(1) cu gramatica independentă de context. Această gramatică, deși www.todaysoftmag.ro | nr. 21/Martie, 2014

programare Cum să scrii un generator de cod bazat pe template-uri flexibile constrânsă de faptul că nu poate manipula ambiguități, e potrivită pentru cele mai multe limbaje, chiar și mai complexe, cum ar fi Java. Limbajele LALR(1) sunt compuse din simboluri terminale și nonterminale. Simbolurile terminale sunt cele care pot fi cuplate cu un singur token de intrare. De exemplu, în acest limbaj template tokenul <$ e terminal, o componentă atomică a limbajului. Simbolurile nonterminale sunt compuse din mai multe simboluri terminale și nonterminale. Definiția unui simbol nonterminal alcătuiește regula gramaticală. O regulă este o listă cu toate combinațiile posibile de simboluri terminale și nonterminale care alcătuiesc acest nonterminal. De exemplu,dacă am vrea să definim un nonterminal pentru numele unei variabile, acesta ar arăta în felul următor: variable_name: word OR word.word

Simbolul nonterminal nume_variabilă este o componentă compusă a unui limbaj. Poate fi o parte a unei liste de definiții a unui alt simbol nonterminal pentru a alcătui alte nonterminale mai complexe, cum ar fi o instrucție foreach. Există un nonterminal special care reprezintă întregul limbaj. Acest nonterminal este nivelul cel mai de sus al limbajului. Toate combinațiile valide ale altor componente a limbajului trebuie să fie parte a definiției sale. Pentru că o intrare să fie validă, înseamnă că, gradual, dacă se substituie componentele mai mici cu unele mai mari, acest nonterminal master poate fi substituit la sfârșit cu toate input-urile. Parser-ul generat este un automat de stări. Parser-ul pune token-urile de intrare recepționate pe stivă. Această operație este numită mutare. Atunci când e cazul, e substituită cu nonterminale. Această operație numită reducere este aceeași procedură ca aceea descrisă mai sus. Dacă totul merge corect, toate input-urile sunt reduse la nonterminalul master și limbajul este valid. În timpul validării gramaticii arborele de sintaxă abstract este de asemenea construit. Acest pas reprezintă partea crucială a procedurii de parsare. Arborele de sintaxă abstract reprezintă tot template-ul sub

forma de arbore, unde părțile importante ale template-ului sunt reprezentate sub forma de noduri de arbore. Pentru a avea o idee cum arată acest arbore, ca exemplu avem arborele de sintaxă din imaginea de mai jos. În arborele exemplificat avem noduri cu text, foreach cu ceva text și câteva variabile. Dar cum este construit acest arbore? Cu ajutorul lui bison putem specifica cod customizabil care să fie executat de fiecare dată când se întâmplă o reducere. Prin urmare, se poate reacționa la fiecare eveniment apărut în urma parsării template-ului și vor fi create nodurile arborelui. În exemplul nostru, arborele va avea noduri pentru text, foreach și variabile. Bison generează metoda yyparse(). Aceasta apelează yylex()- metoda generată de flex – pentru a obține datele de întrare. În cazul în care analiza a fost cu succes se returnează valoare 0 și o altă valoare în caz de eroare. Utilizatorul metodei poate să specifice un parametru de intrare – cum ar fi un pointer spre rădăcina arborelui de sintaxă. Prin urmare, când analiza este gata, arborele construit din fișierul template poate fi returnat utilizatorului.

Concluzii

Scrierea unui generator de cod nu este o sarcină ușoară; este nevoie de mult efort, dar de cele mai multe ori se dovedește a fi o investiție bună. Prin acest articol, am încercat să expun principalele provocări care apar în realizarea unei astfel de aplicații într-un mod cât mai ușor de înțeles.De aici și multitudinea de exemple. În cazul nostru, decizia de a investi timp în aprofundarea flex – bison s-a dovedit a fi excelentă. Datorită faptului că există și că am găsit soluții fiabile, noi ne-am concentrat în mare parte pe definirea limbajului. Flex – bison este o soluție care ne-a satisfăcut cerințele, având și o documentație bine pusă la punct. Lucrând cu generatoare de parser-e, un avantaj ar fi de subliniat: în cazul unor schimbări majore sau minore din punct de vedere structural sau al introducerii unor noi cerințe în codul deja existent, prin utilizarea generării de cod vor fi modificate doar câteva fișiere. Acest lucru ar fi în avantajul oricărui programator. Generarea codului folosind generator de cod e într-adevăr deosebită.

Executarea instrucțiunilor din arborele de sintaxă

Partea de cod care va folosi arborele mai sus generat trebuie să știe concret ce se va executa pentru fiecare nod,astfel încât output-ul rezultat să fie conform specificațiilor. De exemplu, un nod care conține o variabilă va fi substituit cu o valoare găsita în fișierul xml de intrare. Fiecare nod trebuie să conțină destule informații astfel încât utilizatorul arborelui se poate genera output-ul dorit. În exemplul menționat, nodul de variabilă trebuie să conțină numele variabilei reprezentate. Pentru a genera întreg output-ul, arborele de sintaxă trebuie parcurs în adâncime. Un output generat pentru template-ul propus ca input, folosind doar una categoriile descrise de xml, ar fi: class Smartphone { public: Smartphone(); ~ Smartphone (); std::string getvendor(); void setvendor(const std::string &value); std::string getos(); void setos(const std::string &value); private: std::string vendor; std::string os; }

nr. 21/Martie, 2014 | www.todaysoftmag.ro

Dénes Botond

denes.botond@accenture.com Software engineer @ Accenture Romania

programare

TODAY SOFTWARE MAGAZINE

Mașina virtuală HipHop

n ziua de astăzi, când vine vorba de site-uri uriașe, problema performanței apare des, împreuna cu întrebarea “Noi cum putem deservi așa o masă mare de clienți la un preț rezonabil ? “. Ei bine, unul dintre cele mai mari site-uri de pe planetă, Facebook, au un răspuns destul de bun: HipHop Virtual Machine. Ce e acest soft, cum s-a născut, cum funcționează și de ce e mai bun ca alternativele ? Toate aceste întrebări voi încerca să le răspund în paginile care urmează. Informațiile prezente în acest articol sunt împrăștiate prin multe documente, interviuri, bloguri, wiki-uri etc..Acest articol încearcă să ofere o imagine de ansamblu asupra acestui proiect. Țineți cont că unele aspecte și funcționalități nu vor fi abordate decât foarte vag,iar altele,deloc. Dacă doriți informații detaliate despre o anumită funcționalitate, vă invit să consultați documentația sau blogul dedicat acestui proiect.

1. Ce e mașina virtuală HipHop ? Mașina virtuală HipHop este un motor de execuție a codului PHP. A fost creată de către Facebook în încercarea de a economisi resurse computaționale pe webserver-ele lor, care deveneau din ce în ce mai solicitate de numărul tot mai mare de vizitatori.

2. Istorie

Istoria începe în vara anului 2007 când Facebook a început dezvoltarea lui HPHPc. Modul de funcționare a lui HPHPc era următorul: • se construia un arbore abstract de sintaxă care reprezenta structura logică a codului PHP, • pe baza acelui arbore se făcea traducerea codului PHP în cod C++, • se compila acel cod C++ într-un binar (folosind g++), • acel executabil era apoi urcat pe

webserver-e unde era executat. În vremurile lui de glorie, HPHPc a reușit să obțină în unele cazuri performanțe cu până la 500 % mai mari decât platforma Zend (platforma PHP obișnuită). Aceste rezultate impresionante au convins inginerii de la Facebook că HPHPc merită păstrat și îmbunătățit. Aceștia au decis să-i dea și un frate: HPHPi (HipHop interpreted). HPHPi este varianta “developer-friendly” a lui HPHPc și, pe lângă eliminarea pasului de compilare, acesta oferă utilități pentru programatori, printre care un code debugger numit HPHPd, analiza statică a codului, performance profiling și multe altele. Cele două produse (HPHPc și HPHPi) au fost dezvoltate și menținute în paralel pentru a păstra compatibilitatea dintre ele. Dezvoltarea lui HPHPc a durat doi ani, iar la sfârșitul lui 2009, acesta motoriza 90 % din server-ele din producție ale site-ului. Performanța era excelentă, load-ul pe servere a scăzut simțitor (50 % în unele cazuri) și toată lumea era fericită. Așa că, în februarie 2010, codul sursă a lui HPHPc a devenit open-source și a fost publicat pe GitHub sub licența PHP License. Dar inginerii de la Facebook și-au dat seama că performanța superioară nu avea să garanteze succesul lui HPHPc pe termen lung. Iată de ce: • compilarea statică dura mult și era greoaie. • executabilul rezultat avea peste 1GB,

ceea ce îngreuna mult deployment-ul (codul nou trebuia pus în producție zilnic). • dezvoltarea lui HPHPc și HPHPi și menținerea compatibilității dintre ele devenea din ce în ce mai dificilă. Aceasta în special pentru că arborii de sintaxa folosiți de cele două produse erau diferiți și a-i menține compatibili nu era o sarcină ușoară. Așa că, la începutul lui 2010 (chiar după ce HPHPc a devenit open-source) Facebook a format o echipă care să cerceteze și să vină cu o alternativă viabilă la HPHPc, una care să poată fi menținută pe termen lung. O mașină virtuală care folosește un compilator JIT părea să fie răspunsul iar încarnarea acestei alternative a dat naștere lui HipHop Virtual Machine (HHVM). La început, HHVM-ul a înlocuit doar HPHPi-ul și a fost folosit doar pentru development, HPHPc rămânând în producție. Însă, la sfârșitul anului 2012, HHVM-ul a depășit în performanță HPHPc și, prin urmare, în februarie 2013, toate server-ele din producție ale Facebook-ului au fost trecute pe HHVM.

II. Arhitectura

Arhitectura generală a HHVM-ului e formată din două webserver-e, un translator, un compilator JIT și un garbage collector. HHVM-ul nu rulează pe orice sistem de operare. Mai exact:

www.todaysoftmag.ro | nr. 21/Martie, 2014

programare Mașina virtuală HipHop • sunt suportate multe distribuții de Linux, în special Ubuntu și CentOS, • pe Mac OS X, HHVM-ul nu poate funcționa cu JIT-ul pornit, • nu există suport pentru Windows. HHVM-ul va rula doar pe sisteme de operare pe 64 de biți. Conform echipei de ingineri, suportul pentru sisteme de operare pe 32 de biți nu va fi introdus niciodată.

1. Funcționare

Pașii generali de funcționare ai HHVMului sunt următorii: • pe baza codului PHP, se construiește un arbore abstract de sintaxă (implementarea acestui pas a fost reutilizată de la HPHPc). • folosind arborele, codul PHP este tradus în HHBC (HipHop bytecode). • pentru a nu repeta pașii anteriori la următorul request, bytecode-ul este stocat într-un cache. • Dacă compilatorul JIT e activat, bytecode-ul este pasat acestuia; JIT-ul va transforma bytecode-ul în cod mașină, care va fi executat. • Dacă compilatorul JIT e dezactivat, HHVM-ul va rula în mod interpretat și va executa direct bytecode-ul. Acest mod este mai lent, dar tot e mai rapid decât Zend PHP. Detalii despre pașii menționați mai sus puteți găsi în secțiunile următoare.

2. Cache-area bytecode-ului HHVM-ul ține bytecode-ul (HHBC) într-un cache implementat sub forma unei baze de date SQLite. Când HHVM-ul primește un request, trebuie să determine care fișier PHP să-l execute. După ce a facut aceasta, va verifica cache-ul pentru a determina dacă are deja bytecode-ul pentru acel fișier și dacă acel bytecode e actualizat. Dacă bytecode-ul există și e actualizat, va fi executat. Un bytecode executat cel puțin o dată va fi păstrat și în RAM. Dacă însă acesta nu există sau dacă fișierul PHP a fost modificat de la ultima generare a bytecode-ului, atunci acesta va fi recompilat și bytecode-ul lui va fi reintrodus în cache. Acest mod de operare e practic identic cu cel al APC-ului (Apache PHP Cache). Acest comportament înseamnă că, la prima execuție a fiecărui fișier, există o perioadă semnificativă de warm-up. Vestea

bună e că HHVM-ul păstrează cache-ul pe disk; asta înseamnă că, spre deosebire de APC, el va supraviețui dacă HHVM-ul sau webserver-ul fizic e restartat. Deci perioada de warm-up nu va trebui repetată. Chiar și așa, perioada de warm-up poate fi ocolită în totalitate. Acesta se poate face prin așa numita pre-analiză. Acest lucru înseamnă că cache-ul poate fi pre-generat înainte de a porni HHVM-ul. După instalarea HHVM-ului, există un executabil în pachet cu ajutorul căruia se poate genera bytecode-ul pentru întregul cod sursă al site-ului și introdus în cache. În acest fel, la pornirea HHVM-ului, cacheul e deja umplut și gata de folosire. Trebuie ținut cont de faptul că cheile de cache conțin, printre altele, build-IDul HHVM-ului. Deci dacă HHVM-ul va fi înlocuit cu o versiune mai nouă sau mai veche, conținutul cache-ului se va pierde și va trebui re-generat.

3. Modul RepoAuthoritative Un mod interesant de rulare a HHVMului este modul RepoAuthoritative. După cum am zis în secțiunea despre cache, HHVM-ul va verifica la fiecare request dacă fișierul PHP cerut a fost modificat de la ultima sa compilare. Aceasta înseamnă operațiuni de disk IO care, din câte se știe, sunt scumpe din punct de vedere computațional. Durează doar o fracțiune de secundă, dar e o fracțiune de secundă pe care n-o avem atunci când încercăm să deservim mii de request-uri pe minut. Când modul RepoAuthoritative e activat, HHVM-ul nu va mai verifica dacă fișierul PHP a fost modificat, ci va merge direct în cache. Numele vine de la faptul că cache-ul este denumit “repo” în terminologia HHVM-ul și că acest “repo” devine autoritatea principală a codului. Modul RepoAuthoritative se poate activa adăugând următoarele linii de cod în fișierul de configurare: Repo { Authoritative = true }

Trebuie avut grijă cu acest mod de rulare pentru că, dacă bytecode-ul unui fișier lipsește din cache, clientul va primi o eroare HTTP 404, chiar dacă fișierul PHP există și poate fi executat fără probleme. Modul RepoAuthoritative este recomandat pentru sistemele din producție din două motive: • eliminarea a majorității operațiunilor de disk IO îmbunătățește performanța, • există o oarecare siguranță că fișierele

nr. 21/Martie, 2014 | www.todaysoftmag.ro

PHP nu se vor modifica.

3. Compilatorul JIT Bytecode-ul este o formă intermediară de cod care nu este caracteristică vreunui procesor sau vreunei platforme, el este prin definiție portabil. La rulare, acest bytecode este transformat în cod mașină într-un proces numit Just-In-Time compilation (JIT). Compilatorul poate să transforme în cod mașină doar o bucată de cod, o funcție, o clasă sau chiar un întreg fișier. În general, sunt trei caracteristici ale compilatoarelor JIT care sunt importante pentru eficiența lor: • codul mașină generat de acestea este stocat în RAM pentru a nu face traducerea de mai multe ori, • se caută cele mai intense bucle din cod, bucle unde programul își petrece cel mai mult timp. Acele bucle sunt cel mai puternic optimizate. • codul mașină rezultat este optimizat special pentru platforma pe care rulează compilatorul în acel moment. De exemplu, dacă se detectează că procesorul suportă setul de instrucțiuni SSE3, atunci compilatorul se va folosi de această facilitate. Din acest motiv, compilatoarele JIT pot uneori să depășească ca performanță inclusiv compilatoarele statice/clasice. Compilatorul JIT din HHVM este bijuteria acestuia, modulul responsabil pentru tot succesul mașinii virtuale. În timp ce compilatorul JIT din mașina virtuală Java folosește metodele unei clase ca bloc unitar de compilare, compilatorul JIT din HHVM folosește așa numitele tracelet-uri. Un tracelet e de obicei o buclă pentru că, conform cercetării, cele mai multe programe își petrec mare parte din timp într-o buclă ale cărei iterații sunt foarte asemănătoare și, prin urmare, au căi identice de rulare. Tracelet-ul e format din trei părți: • type guard(s): previne execuția datelor de intrare care sunt de un tip incorect (de exemplu se așteaptă un număr întreg și se primește un boolean). • corpul tracelet-ului: instrucțiunile propriu-zise. • l e g ă t u r a c ă t r e u r m ă t o a r e l e tracelet-uri. Fiecare tracelet are libertate foarte mare în ceea ce privește instrucțiunile pe care are voie să le execute, dar trebuie ca mașina virtuală să rămână într-o stare consistentă la terminarea execuției unui tracelet.

TODAY SOFTWARE MAGAZINE Un tracelet are doar o singură cale de execuție: instrucțiune după instrucțiune după instrucțiune. Nu există branch-uri sau flow control. Asta le face foarte ușor de optimizat.

4. Garbage Collector În cele mai multe limbaje moderne, programatorul nu e nevoit să facă management al memoriei. Trecute sunt zilele în care trebuia să te chinui cu aritmetica pointer-ilor. Felul în care o mașină virtuală (inclusiv HHVM) face management-ul memoriei se numește Garbage Collection. Colectorii se împart în două mari categorii: • cei bazați pe refcounting: pentru fiecare obiect, se ține constant evidența numărului de referințe către acel obiect. Când numărul scade la 0 pentru un obiect, acesta e șters din memorie. • cei bazați pe tracing: periodic, în timpul execuției, garbage collector-ul scanează toate obiectele și, pentru fiecare, determină dacă se poate ajunge la ele printr-o referință. Obiectele la care nu se poate ajunge sunt șterse din memorie. Cei mai mulți colectori sunt un hibrid al celor două metode, însă mereu una dintre ele e dominantă. Colectorii bazați pe tracing sunt mai eficienți, mai performanți și mai ușor de implementat. Acest tip de garbage collector a fost intenționat și pentru HHVM dar, cum PHP-ul necesită un colector pe bază de refcounting, inginerii HHVM-ului au fost nevoiți să renunțe la idee, cel puțin temporar. PHP-ul are nevoie de un colector de tip refcounting pentru că: • clasele pot avea un destructor. Acesta trebuie apelat atunci când obiectul devine ,,gunoi”, nu atunci când e colectat. Dacă s-ar folosi un colector de tip tracing, nu s-ar putea ști când obiectul a devenit gunoi. • mecanismul de copiere al arrayurilor necesită păstrarea unei evidențe actualizate a referințelor către acest tip de date.

se materializeze în următorii ani. Un ultim punct: HHVM nu are un colector ciclic (obiectul A referențiază obiectul B care referențiază obiectul A). Un astfel de colector e present în codul sursă, dar e inactiv.

5. Sfaturi pentru cod HHVM-friendly HHVM-ul lucrează mai bine atunci când știe cât mai multe detalii statice despre cod înainte să-l ruleze. Având în vedere că mare parte din codebase-ul Facebook-ului este scris în stil orientat pe obiect, HHVM-ul se va descurca mai bine cu astfel de cod. Mai concret, e indicat să se evite: • accesarea dinamică a funcțiilor sau variabilelor: $function_name(),$a = $$x + 1, • f u n c ț i i l e c a re a c c e s e a z ă s au modifică variabile globale: compact(), get_defined_vars(), extract(), get_ object_vars() etc. . • accesarea dinamică a câmpurilor unui obiect: echo $obj->myvar (unde myvar nu e declarat în clasă). Dacă acel câmp e necesar, declară-l în clasa corespunzătoare. Altfel, accesarea lui va fi lentă deoarece va presupune căutare într-un hashtable. • funcțiile cu același nume, chiar dacă sunt în fișiere / clase diferite și nu vor interacționa niciodată. Dacă numele lor e unic, atunci HHVM-ul va putea determina mai ușor care parametrii sunt pasați prin valoare, care prin referință, ce tip de date returnează funcția, etc..Acest ultim punct e valabil doar dacă HHVM-ul rulează în modul RepoAuthoritative.

$a = 5; $b = new B(); echo $b;

Variabilele $a și $b sunt în scop global. Atunci când se apelează echo $b, metoda __toString din clasa B e apelată. Aceasta modifică tipul variabilei $a din număr întreg în șir de caractere. Dacă variabilele $a și $b ar fi trecute prin compilatorul JIT, acesta ar deveni foarte confuz în legătură cu tipul și conținutul variabilei $a. Prin urmare, e foarte indicat ca tot codul să fie pus în clase și funcții.

III. Facilități 1. Server de administrare După cum am zis în capitolul despre arhitectură, HHVM-ul conține două webserver-e. Unul dintre ele e webserver-ul care deservește trafic HTTP obișnuit prin portul 80. Al doilea se numește AdminServer și oferă acces la câteva operațiuni de administrare a HHVM-ului. Pentru a activa AdminServer-ul, adăugați următoarea secvență de cod în fișierul de configurare: AdminServer { Port = 9191 ThreadCount = 1 Password = mypasswordhaha }

AdminServer-ul se poate apoi accesa la adresa: http://localhost:9191/checkhealth?auth=mypasswordhaha

Opțiunea “check-health” din URI-ul de mai sus e doar una dintre opțiunile suportate de către AdminServer. Alte opțiuni permit afișarea de statistici legate de trafic, query-uri, memcache, încărcarea procesorului, numărul de thread-uri active și multe Atunci când e posibil, e bine să se altele. Se poate inclusiv opri webserver-ul specifice: principal de aici. • type hinting pentru parametrii funcțiilor, 2. FastCGI • tipul de date returnat de o funcție. Una dintre cele mai așteptate facilități Aceasta se poate realiza făcându-l evi- este suportul pentru FastCGI. Acesta a dent: return ($x == 0); fost introdus în versiunea 2.3.0 a HHVMului (decembrie 2013) și e un protocol de De asemenea, e bine de știut că o com- comunicare suportat de cele mai populare pilare a codului din scopul global nu va fi webserver-e, cum ar fi Apache sau nginx. niciodată realizată de către compilatorul Suportul pentru acest protocol înseamnă JIT. Aceasta se întâmplă pentru că starea că nu mai e nevoie să folosim webservervariabilelor din scopul global poate fi ul încorporat în HHVM, ci putem folosi de Inginerii HHVM-ului își doresc foarte modificată de oriunde altundeva. Un exem- exemplu Apache ca webserver și să lăsăm mult să facă trecerea către un garbage col- plu luat de pe blogul HHVM-ului: HHVM-ul să făcă ce știe mai bine: să exelector pe bază de tracing. Au și încercat la class B { un moment dat; însă, datorită restricțiilor public function __toString() { $GLOBALS[‘a’] = ‘I am a string menționate mai sus, codul a devenit now’; foarte complicat și ceva mai lent, așa că au } renunțat. Sunt totuși șanse ca acest plan să } cute cod PHP cu mare viteză. www.todaysoftmag.ro | nr. 21/Martie, 2014

programare Mașina virtuală HipHop Această facilitate e una crucială pentru că va garanta creșterea popularității HHVM-ului.

3. Extensii HHVM-ul are suport experimental pentru extensiile scrise pentru Zend PHP. Acest suport e obținut folosind un așa numit PHP Extension Compatibility Layer. Scopul acestui layer este să ofere acces la același API și macro-uri ca și PHP, altfel extensiile nu vor funcționa. Pentru ca o extensie PHP să funcționeze, trebuie re-compilată folosind implementarea HHVM-ului a respectivului API. De asemenea, trebuie compilată drept cod C++, nu C. Aceasta presupune de obicei modificări minore ale codului extensiei. HHVM suportă și extensii terțe, la fel ca Zend PHP. Ele pot fi scrise în PHP sau C++. Extensia va fi apoi adăugată în codul sursa al HHVM-ului ,iar întregul HHVM va fi recompilat. Noul executabil al HHVM-ului va conține extensia ,iar funcționalitatea oferită de aceasta va putea fi accesată în codul rulat. HHVM-ul include deja cele mai populare extensii, cum ar fi: MySQL, PDO, cURL, PHAR, XML, SimpleXML, JSON, memcache și multe altele. Momentan nu este inclusă extensia MySQLi.

X-Powered-By: HPHP ca răspuns.

V. Concluzie

În concluzie, HHVM-ul este un produs revoluționar, robust, rapid care se dezvoltă constant și, datorită suportului pentru FastCGI, se răspândește repede. Foarte multe concepte și soluții folosite de HPHPc și HHVM au fost introduse în Zend PHP. Este și motivul pentru care sunt așa de mari îmbunătățiri de performanță de la PHP 5.2 la PHP 5.5.

IV. Cod suportat

HHVM-ul pare a fi un produs solid, robust, rapid. Dar toate acestea nu ar conta deloc dacă HHVM-ul nu ar putea rula cod real din lumea reală. Inginerii HHVM-ului măsoară abilitatea aceasta prin rularea pe HHVM a unit-test-elor celor mai populare 20 de framework-uri și aplicații PHP, printre care Symfony, phpBB,

PHPUnit, Magento, CodeIgniter, phpMyAdmin și multe altele. (imagine de pe blog-ul HHVM, decembrie 2013) Cifrele din dreptul fiecarei aplicații reprezintă procentajul unit-test-elor care sunt executate cu succes. Inginerii HHVM-ului îmbunătățesc aceste cifre la fiecare release și speră că toate unittest-ele acestor aplicatii să treacă în cel mult un an. În lumea reală, se știe că următoarele site-uri folosesc HHVM pentru a rula: • facebook.com, • hhvm.com, • www.tuenti.com, • siapku.com. Multe din site-urile care folosesc HHVM vor trimite header-ul

nr. 21/Martie, 2014 | www.todaysoftmag.ro

Radu Murzea

rmurzea@pentalog.fr PHP Developer @ Pentalog

programare

TODAY SOFTWARE MAGAZINE

Autoencoders

n numărul anterior am prezentat Restricted Boltzmann Machines, care au fost introduse de Geoffrey Hinton, profesor la universitatea din Toronto în 2006 ca o metodă de a face ca antrenarea rețelelor neuronale să fie mult mai rapidă. În 2007, Yoshua Bengio, profesor la universitatea din Montreal, a venit cu o alternativă la RBM-uri: autoencodere.

Autoencoderele sunt rețele neuronale care învață să comprime și să proceseze datele lor de intrare. În urma procesării, din datele de intrare se extrag trăsături care sunt mai relevante și care permit o rezolvare mai ușoară a problemei de învățare automată pe care o avem, de exemplu de a clasifica imagini în funcție de conținutul lor. De obicei, autoencoderele au cel puțin trei straturi: • un strat de intrare (dacă lucrăm cu imagini, acesta va corespunde pixelilor din imagine). • unul sau mai multe straturi ascunse, care realizează procesarea propriu-zisă. • stratul de ieșire, care este fixat să fie identic cu primul.

Fig.1 - Un autoencoder cu 3 straturi, cu câte 6, 3, respectiv 6 neuroni pe fiecare strat

La autoencodere, valorile de ieșire sunt setate să fie egale cu cele de intrare (y = x). În mod normal, funcția cea mai simplă care realizează această „transformare” este funcția identitate, f(x) = x. De exemplu, dacă avem un strat de intrare cu 100 de intrări, dar pe stratul interior avem doar 50 de neuroni, atunci rețeaua neuronală va trebui să comprime

datele de intrare, pentru că altfel nu are o putere de reprezentare suficientă pentru a reproduce toate cele 100 de intrări în mod corect. Dacă datele noastre de intrare sunt complet aleatorii, atunci va eșua, deoarece aceasta este o problemă imposibil de rezolvat din punct de vedere al teoriei informației. Dar dacă datele de intrare au o structură, de exemplu sunt pixelii unei imagini de 10x10, atunci putem vorbi deja de o reprezentare mai compactă a pixelilor. Dacă un anumit pixel dintr-o imagine este verde, atunci de obicei cei 8 pixeli din jurul lui sunt tot verzui. Dacă observăm că anumiți pixeli de aceeași culoare sunt dispuși pe un cerc, în loc de a memora fiecare poziția fiecărui pixel (pentru un cerc cu raza de 4 pixeli,aceasta ar presupune vreo 25 de intrări), este suficient să știm că la poziția x,y avem un cerc cu raza r, care reprezintă deja doar 3 intrări. Desigur, o comprimare așa mare nu se va realiza din prima. Dar dacă punem autoencoder peste autoencoder, într-un mod similar cu ceea ce făceam în Deep Belief Networks cu Restricted Boltzmann Machines, vom obține succesiv trăsături tot mai compacte. Dacă privim un strat ca o funcție care primește un vector de date și returnează un alt vector, prelucrat, atunci într-un autoencoder cu 3 straturi avem 2 funcții (primul strat, cel vizibil, doar trimite mai departe intrările sale). Prima funcție va codifica intrările sale: h=f(x)=sf(Wx+bh) unde sf este o funcție de activare nelineară folosită de stratul ascuns, iar W și bh sunt ponderile legăturilor dintre stratul vizibil și cel ascuns, respectiv pragurile de activare neuronii din stratul ascuns.

A doua funcție va realiza o decodificare a datelor codificate de stratul intermediar: y = g(h) = sg(W’x+by) unde constantele au semnificații similare, doar că între stratul ascuns și stratul de ieșire de această dată. Combinația celor două funcții se dorește a fi funcția identitate, dar noi putem folosi apoi doar funcția de codificare, prelucrând datele noastre cu aceasta și obținând în acest fel o reprezentare de nivel mai înalt. Cuantificarea diferenței față de funcția de identitate se face cu ajutorul erorii de reconstruire, definită astfel: L(x, y) = ||x-y||2 Parametrii autoencoderului se aleg astfel încât această normă pătratică să fie minimală. Modelul prezentat mai sus este cel al unui autoencoder clasic, în care învățarea trăsăturilor relevante se face prin comprimarea datelor, datorită faptului că stratul intermediar are mai puțini neuroni decât stratul de intrare. Există și alte tipuri de autoencodere, unele dintre ele având chiar mai mulți neuroni pe stratul intermediar decât pe stratul de intrare, dar care evită problema memorării intrărilor prin alte metode. Autoencoderele rare (sparse autoencoders) încearcă să constrângă neuronii din stratul ascuns să fie activați cât mai puțin. Neuronii din stratul ascuns sunt activați atunci când trăsăturile pe care le reprezintă sunt prezente în datele de intrare. Dacă fiecare neuron este activat rar, înseamnă că fiecăruia îi corespund trăsături diferite, semnificative. Aceasta se realizează în practică prin adăugarea unui termen de

www.todaysoftmag.ro | nr. 21/Martie, 2014

programare Autoencoders penalizare pentru numărul de activări al fiecărui neuron, pe datele În Pylearn2, modelele de deep learning pot fi configurate cu de intrare pe care le avem: ajutorul unui fișier YAML, care apoi va fi executat de către scriptul train.py din librărie, care rulează antrenarea și apoi salvează rețeaua neuronală antrenată într-un fișier pickle. unde β este un parametru ce controlează gradul de intensitate a penalizărilor activărilor dese, ρj este media activărilor neuronului j, iar ρ este parametrul de raritate și reprezintă frecvența intențiilor de a activa fiecare neuron. De obicei are o valoare sub 0.1. Denoising autoencoders urmează o altă abordare. Atunci când este antrenat, unele valori din datele de intrare sunt corupte fie prin adăugarea unei valori mici aleatorii, fie prin aplicarea unei măști binare, care lasă neschimbate unele valori, iar pe altele le face 0. Cum rezultatul rămâne neschimbat (valorile originale), rețeaua neuronală trebuie să învețe să reproducă valorile corupte din valorile neschimbate. Pentru a face aceasta, ea trebuie să învețe ce corelări există între datele de intrare și să le aplice când vreuna din date este schimbată. Procesul de antrenare și funcția de cost sunt neschimbate. O altă variantă de autoencodere sunt contractive autoencoders. Acestea încearcă să învețe trăsături eficiente penalizând sensibilitatea rețelei față de intrările ei. Sensibilitatea reprezintă variația rezultatului când intrarea puține modificări . Cu cât sensibilitatea este mai mică, cu atât mai mult se vor extrage aceleași trăsături și pentru intrări care se caracterizează prin mici diferențe, ceea ce este un lucru dorit. Să ne imaginăm, de exemplu, problema recunoașterii de cifre scrise de mână. Unii oameni fac cifra 0 mai turtită, alții mai alungită, alții mai rotunjită, dar diferențele totuși rămân mici, de câțiva pixeli. Noi am vrea ca rețeaua noastră să învețe aceleași trăsături pentru cât mai multe variații ale datelor de intrare. Penalizarea sensibilității se face cu norma Frobenius a Jacobianului funcției dintre stratul de intrare și cel intermediar:

!obj:pylearn2.train.Train { dataset: !pkl: „cifar10_preprocessed_train.pkl”, model: !obj:pylearn2.models.autoencoder.ContractiveAutoencoder { nvis : 192, nhid : 400, irange : 0.05, act_enc: ‚tanh’, act_dec: ‚tanh’, }, algorithm: !obj:pylearn2.training_algorithms.sgd. SGD { learning_rate : 1e-3, batch_size : 500, monitoring_batches : 100, monitoring_dataset : !pkl: „cifar10_preprocessed_train.pkl”, cost : !obj:pylearn2.costs.autoencoder.MeanSquaredReconstructionError {}, termination_criterion : !obj:pylearn2.termination_criteria.MonitorBased { prop_decrease : 0.001, N : 10, }, }, extensions : [!obj:pylearn2.training_algorithms. sgd.MonitorBasedLRAdjuster {}], save_freq : 1 }

Fig. 2 - Filtrele învățate de un Contractive Autoencoder pe CIFAR-10

Toate aceste modele pot fi combinate, desigur. Putem impune condiții atât de raritate, cât și de corupere a datelor de intrare. A detecta care dintre aceste tehnici este cea mai utilă, depinde în mare parte și de natura datelor noastre, așa că trebuie experimentat cu diferite tipuri. Mai sunt și alte tipuri, cum ar fi Transforming Autoencoders sau Saturating Autoencoders, asupra cărora nu se va insista. Intenția este de a arăta cum se pot folosi autoencoderele cu ajutorul Pylearn2, o librărie de Python, dezvoltată de grupul de cercetare LISA de la University of Montreal. Cu ajutorul acestei librării s-au dezvoltat multe din rezultatele care au doborât recorduri în acest domeniu, mai ales legate de prelucrarea imaginilor.

nr. 21/Martie, 2014 | www.todaysoftmag.ro

Autoencoderele reprezintă o metodă de a lua un set de date și de a-l transforma într-un alt set de date, posibil mai comprimat, care reprezintă mai bine proprietățile datelor. Pornind de aici, se poate ajunge mai ușor la rezolvarea problemei noastre, fie că este de clasificare, cluster-izare, sau regresie. În următorul număr, vom prezenta îmbunătățirile aduse de Deep Learning la nivelul straturilor și alte tipuri noi de straturi.

Roland Szabo

roland.szabo@3pillarglobal.com Junior Python Developer @ 3 Pillar Global

programare

TODAY SOFTWARE MAGAZINE

AOP folosind .NET stack

n cele ce urmează vom discuta despre AOP și despre cum putem implementa propria noastră stivă (stack) AOP utilizând caracteristicile .NET Core. Acronimul vine de la Aspect Oriented Programming și este o altă paradigmă de programare cu scopul principal de a crește modularitatea unei aplicații. AOP încearcă să atingă acest țel permițând separarea aspectelor/relațiilor secante (cross-cutting concerns). Fiecare parte a aplicației este împărțită în unități distincte bazate pe funcționalitate (aspecte/relații). Bineînțeles, chiar dacă nu utilizăm această paradigmă, vom încerca să avem o separare clară a funcționalităților. Dar în AOP toate funcționalitățile sunt separate, chiar și cele pe care în OOP le acceptăm ca fiind secante. Un exemplu bun în acest caz este audit (controlul) și logging (jurnalizare). În mod normal, dacă utilizăm OOP pentru a dezvolta o aplicație care necesită logging și audit, vom avea într-o formă sau alta diferite apelări ale mecanismului de logging din codul nostru. În OOP, acest lucru poate fi acceptat, deoarece aceasta este singura modalitate de a scrie logaritmi, de a prelucra și așa mai departe. Când folosim AOP, implementarea sistemului de logging sau audit va trebui plasată într-un modul separat. În plus, vom avea nevoie de o modalitate de a scrie informația de logging fără a scrie cod în alte module care fac apelarea în sine a sistemului de logging. Există diferite opțiuni care pot fi utilizate în AOP pentru a soluționa această problemă. Depinde de tipul de tehnologie pe care îl utilizați, de tipul de stack (stivă) pe care doriți să-l folosiți și așa mai departe. Am putea utiliza atribute (adnotații) ale metodelor și claselor care ar activa logging și audit. O altă abordare este configurarea unor înlocuitori care vor fi folosiți de către sistem drept implementarea reală a unei funcționalități. Acest înlocuitor va fi capabil să scrie logs și să facă apelarea implementării de bază.

Interceptarea

Aproape toate cadrele disponibile pentru AOP sunt în jurul interceptării. Folosind interceptarea, dezvoltatorii pot specifica ce metode trebuie interceptate și ce ar trebui să se întâmple în acest caz. Prin interceptare, noi putem chiar să adăugăm noi câmpuri, proprietăți , metode sau chiar să modificăm implementarea curentă.

Cum este implementat?

De obicei, există două moduri oferite de diferitele cadre care oferă suport AOP în timpul de execuție și în timpul de compilare. Când cadrul oferă suport AOP în timpul execuției, înseamnă că va crea în timp real diverși reprezentanți care vor redirecționa apelările noastre. Aceasta ne va da o mare flexibilitate, făcându-ne capabili să modificăm în timpul execuției comportamentul aplicației noastre. O altă abordare este în timpul de compilare. Acest tip de cadre sunt de obicei integrate cu IDE și cu mediul de dezvoltare. În timpul de compilare, ele vor aduce modificări codului nostru și vor introduce apelările diferitelor functionalități. În final, va rezulta același cod ca și când am apela codul prin metoda noastră, dar codul pe care trebuie să îl întreținem este mai simplu, curat și cu toate aspectele clar separate.

Costuri

poate să scadă. Acest lucru se întâmplă deoarece există cineva la mijloc care interceptează apelările noastre și face anumite acțiuni. La acest nivel de obicei se folosește reflecția, iar noi știm cu toții că reflecțiile costă mult din perspectiva procesorului. A avea un cod care se modifică în timpul de compilare, înseamnă că putem avea anumite probleme când este nevoie să corectăm codul și să găsim o problemă. Aceasta se întâmplă deoarece în timpul de execuție nu rămâi doar cu codul tău, ci sfârșești prin a avea codul tău original din relația de bază, plus codul din a doua relație de care ai avut nevoie în relația de bază și cu codul cadru AOP care face redirecționarea. După cum putem vedea în diagrama de mai sus, numai primul și ultimul pas fac parte din ciclul normal. Restul sunt adăugați de cadrul AOP.

Componentele de bază ale AOP Join Points (Puncte de întâlnire) Un punct de întâlnire este reprezentat de punctul din cod unde este necesar să punem în aplicare operațiile propuse de noi. Acesta este un punct din cod unde poți face o apelare a unei alte funcționalități într-un mod foarte simplu. În general, cadrele care susțin AOP utilizează metode, clase și proprietăți care reprezintă principalele lor puncte de întâlnire.

Când cadrul AOP folosește reprezentanți în timp real, performanța aplicației noastre www.todaysoftmag.ro | nr. 21/Martie, 2014

programare AOP folosind .NET stack De exemplu, înainte și/sau în timpul apelării unei metode, poți Castle Project – Dynamic Proxy executa codul tău obișnuit. Același lucru se poate întâmpla pentru Asemănător cu AspectSharp. Aceasta este o bibliotecă clase și proprietăți. În general, vei descoperi că conceptele AOP susținută de către comunitate și veți putea găsi mult suport și sunt foarte simple, dar destul de dificil de implementat păstrând informații utile pe diferite forumuri și bloguri. un cod curat și simplu. Din perspectiva mea, instrumentul care oferă toate caractePointcuts risticile de care ai nevoie atunci când vrei să utilizezi AOP este Definesc o modalitate de a specifica un punct de întâlnire în PostSharp. Dar, în funcție de nevoile proprii, ar trebui să încercați sistemul tău. Aceasta oferă dezvoltatorului posibilitatea de a spe- să identificați instrumentul care satisface nevoile voastre. cifica și identifica un punct de întâlnire în sistem unde dorim să facem o anume apelare. Acest lucru poate fi realizat în diferite feluri, de la atribute (adnotații) la configurații diverse (în fișiere, Ce oferă .NET Code în cod și multe altele). Vestea bună este că noi putem utiliza AOP fără niciun fel de instrument. Poate fi mai complicat, dar ceea ce poți realiza utiliSfatul zând .NET API este destul de interesant. În următoarea parte a Sfatul se referă la codul pe care vrem să îl executăm când ajun- articolului vom vedea cum putem folosi clasa RealProxy pentru gem la un punct de întâlnire. În principiu, acesta este reprezentat a intercepta apelările metodei și pentru a injecta comportament de codul care este apelat în jurul unui punct de întâlnire. obișnuit. Clasa RealProxy poate fi găsită în stiva .NET Core. De exemplu, înainte ca o metodă să fie apelată, dorim să C e a m a i i mp o r t a nt ă m e t o d ă a R e a l P r ox y e s t e scriem niște informații pe traseu. ”Invoke”(Invocarea). Această metodă este apelată de fiecare dată când este apelată o metodă din clasa ta specifică. De aici, poți Aspect accesa numele metodei, parametrii și poți apela metoda ta reală Aspectul este format din două elemente diferite – pointcut și sau una falsă. sfatul. Combinarea acestor două elemente formează un aspect. În Este important de știut că aceasta va funcționa numai când general, când vrem să utilizăm AOP, avem o locație unde dorim să folosiți și interfețele. executăm codul și codul obișnuit care vrem să fie executat. În următorul exemplu, vom vedea cum putem implementa un mecanism de profilare obișnuit, utilizând clasa RealProxy. Primul pas este să creăm un atribut obișnuit, care acceptă un .NET Stacks mesaj obișnuit care va fi scris atunci când scriem durata pe traseu. Există moduri diferite de a implementa AOP în .NET. Pe piață, public class DurationProfillingAttribute : Attribute veți găsi numeroase cadre care oferă acest suport, o parte dintre { public DurationProfillingAttribute(string message) ele sunt gratuite. { Message = message;

Unity

}

Unity oferă suport pentru AOP într-o anumită parte a aplicației. În general, Unity oferă suport pentru scenariile cele mai comune, cum ar fi tratarea excepțiilor, logging, protecție sau acces la date.

public DurationProfillingAttribute() { Message = string.Empty; }

PostSharp

}

public string Message { get; set; }

Acesta este unul dintre cele mai cunoscute cadre în lumea Apoi avem nevoie de o clasă generală care extinde RealProxy .NET pentru AOP. Nu este un cadru gratuit, dar este plin de carac- și calculează durata apelării. În metoda Invocare va trebui să utiliteristici utile și este 100% integrat cu mediul de dezvoltare. zăm un cronometru care va calcula cât durează o apelare. La acest nivel, putem verifica dacă o metodă specifică este decorată cu atriAspect.NET butul nostru. Acesta este un instrument gratuit care poate fi găsit pe public class DurationProfilingDynamicProxy<T> : RealCodeplex. El oferă funcționalitățile de bază necesare pentru a Proxy { dezvolta o aplicație utilizând paradigma AOP. private readonly T _decorated;

Enterprise Library Această bibliotecă oferă de asemenea suport pentru AOP, furnizând diferite capabilități precum autorizarea, tratarea excepțiilor, validare, logging și calculator pentru performanță. Este destul de asemănătoare cu funcționalitățile oferite de Unity.

AspectSharp

public DurationProfilingDynamicProxy(T decorated) : base(typeof(T)) { _decorated = decorated; } public override IMessage Invoke(IMessage msg) { IMethodCallMessage methodCall = (IMethodCallMessage)msg;

Aceasta este o altă stivă similară cu Aspect.NET. În ambele MethodInfo methodInfo = methodCall.MethodBase as cazuri, trebuie să știți că aveți acces numai la funcționalitățile de MethodInfo; bază ale paradigmei AOP. DurationProfillingAttribute profillingAttribute = (DurationProfillingAttribute)methodInfo.

nr. 21/Martie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE GetCustomAttributes(typeof( DurationProfillingAttribute)).FirstOrDefault(); // Method don’t needs to be measured. if (profillingAttribute == null) { return NormalInvoke(methodInfo, methodCall); }

{ DurationProfilingDynamicProxy<IFoo> fooDurationProfiling = new DurationProfilingDynamicProxy<IFoo>(new Foo()); IFoo foo = (IFoo)fooDurationProfiling. GetTransparentProxy();

return ProfiledInvoke(methodInfo, methodCall, profillingAttribute.Message); }

}

foo.GetCurrentTime(); foo.Concat(„A”, „B”); foo.LongRunning(); foo.NoProfiling();

private IMessage ProfiledInvoke(MethodInfo methodInfo, IMethodCallMessage methodCall, string profiledMessage) { Stopwatch stopWatch = null; try { stopWatch = Stopwatch.StartNew(); var result = InvokeMethod(methodInfo, methodCall); stopWatch.Stop();

}

WriteMessage(profiledMessage, methodInfo.DeclaringType.FullName, methodInfo.Name, stopWatch.Elapsed);

[DurationProfilling(„After 2 seconds”)] void LongRunning();

return new ReturnMessage(result, null, 0, methodCall.LogicalCallContext, methodCall); } catch (Exception e) { if (stopWatch != null && stopWatch.IsRunning) { stopWatch.Stop(); } return new ReturnMessage(e, methodCall); } } private IMessage NormalInvoke(MethodInfo methodInfo, IMethodCallMessage methodCall) { try { var result = InvokeMethod(methodInfo, methodCall); return new ReturnMessage(result, null, 0, methodCall.LogicalCallContext, methodCall); } catch (Exception e) { return new ReturnMessage(e, methodCall); } } private object InvokeMethod(MethodInfo methodInfo, IMethodCallMessage methodCall) { object result = methodInfo.Invoke(_decorated, methodCall.InArgs);

return result; }

public interface IFoo { [DurationProfilling(„Some text”)] DateTime GetCurrentTime(); [DurationProfilling] string Concat(string a, string b);

string NoProfiling(); } public class Foo : IFoo { public DateTime GetCurrentTime() { return DateTime.UtcNow; } public string Concat(string a, string b) { return a + b; } public void LongRunning() { Thread.Sleep(TimeSpan.FromSeconds(2)); } public string NoProfiling() { return „NoProfiling”; } }

Concluzie

În concluzie, putem spune că AOP ne poate face viața mai ușoară. Aceasta nu înseamnă că de acum o vom folosi în toate proiectele. AOP trebuie utilizată numai acolo unde are sens și de obicei poate fi foarte utilă când lucrăm la un proiect care este foarte complicat, cu multe module și funcționalități. În următorul articol vom descoperi cum putem utiliza Unity pentru a implementa AOP.

private void WriteMessage(string message, string className, string methodName, TimeSpan elapsedTime) { Trace.WriteLine(string.Format(„ Duration Profiling: ‚{0}’ for ‚{1}.{2}’ Duration:’{3}’”, message, className,methodName, elapsedTime)); }

Am putea avea o altă abordare aici, calculând durata pentru toate metodele din clasă. Puteți găsi mai jos clasele utilizate pentru a testa implementarea. Folosind metoda ”GetTransparentProxy” putem obține o referință la interfața noastră. class Program { static void Main(string[] args)

Radu Vunvulea

Radu.Vunvulea@iquestgroup.com Senior Software Engineer @iQuest

www.todaysoftmag.ro | nr. 21/Martie, 2014

management

Disciplina în cadrul proiectelor Agile

ntr-o perioadă în care presiunea din partea pieței și nevoia de creștere a competitivității în toate sectoarele economiei sunt mai mult decât o realitate, industria IT își are locul ei aparte și joacă un rol foarte important ce poate face diferența între companiile care vor fi sustenabile și de succes și în următorul deceniu, investind în inovație, cercetare, eficientizare a proceselor, și cele care se mulțumesc cu ceea ce fac în momentul de față, riscând astfel dispariția de pe piață. În acest context foarte dinamic, în care una dintre certitudini e schimbarea continuă și adaptarea la noile tendințe ale pieței, provocarea pentru domeniul IT e să își desfășoare activitățile într-o manieră cât mai eficientă, cu livrabile cât mai rapide pe piață, cu o calitate cât mai bună și care să maximize investiția făcută de către acționari.

88% din companiile software optează pentru Agile

În mod evident, din punct de vedere al ciclului de viață complet al livrării soluției software, o abordare agilă pare a fi cea mai potrivită alegere în cele mai multe dintre situațiile care urmăresc beneficiile descrise mai sus. Un studiu recent elaborat de Agile Journal arată că peste 88% din companiile de software evaluate (multe cu peste 10.000 de angajați) folosesc deja sau au de gând să folosească practici agile pentru proiectele pe care le implementează. Ceea ce se întâmplă de obicei în majoritatea companiilor este că acestea își încep experiența agilă prin adoptarea practicilor legate de Scrum - care descriu o strategie foarte bună pentru conducerea activităților unei echipe de dezvoltare. Din nefericire, Scrum-ul reprezintă doar o mică componentă din livrarea unei soluții software finale. Ceea ce se întamplă în multe cazuri este că echipele încep să se uite în stânga și în dreapta, uneori prin studiu propriu, alteori apelând la firme de consultanță pentru a umple golurile pe care Scrum-ul

le ignoră în definiția sa, ideile căutate fiind în cea mai mare măsură legate de partea de construcție. Se poate întâmpla ca multitudinea de surse existente și terminologia folosită să creeze mai multă confuzie decât să aducă rezultatele scontate. Mai mult decât atât, nici profesioniștii din IT nu știu exact unde ar trebui să caute sfaturi pentru situația în se află și care probleme ar trebui tratate în mod primordial. Un exemplu - Scrum-ul vorbește despre existența unui Product/Scrum backlog și despre cum anume sunt tratate acestea în timpul unui sprint. Dar totuși, intrebare este de unde anume apare acest Product backlog? Apare acesta de nicăieri în proiect? Bineînțeles că nu, fiind rezultatul unei sesiuni de determinare a cerintelor inițiale care reprezintă unul dintre principalele obiective pe care trebuie să le atingem în faza de început a unui proiect.

Agili, dar într-o manieră structurată

Soluția pe care o implementăm în cadrul Yonder este una focusată pe o abordare agilă disciplinată prin oferirea de proceduri/sfaturi adaptate pentru fiecare client/proiect în parte. Disciplina constă pe de o parte într-o abordare secvențială și iterativă a proiectului (unde se urmărește atingerea anumitor obiective de-a lungul întregului ciclu de viață al livrării soluției), iar pe de altă parte prin oferirea de sfaturi concrete pentru atingerea fiecărui obiectiv în funcție de contextul proiectului.

nr. 21/Martie, 2014 | www.todaysoftmag.ro

Acest lucru este posibil prin adoptarea unor strategii din Scrum - XP, Agile Modeling, RUP, Lean/Kanban, DevOps întro manieră structurată și se evită o aplicare prescriptivă a unor rețete bine cunoscute – pentru că există riscul ca acestea să nu se potrivească cu contextul proiectului și se merge către atingerea anumitor obiective. Ideea care stă la bază este destul de simplă: avem de a face cu o abordare bazată pe faze concrete (Incepție, Construcție, Tranziție), în cadrul fiecărei faze existând o serie de obiective bine definite care trebuie atinse. De exemplu, unul dintre obiectivele fazei de Incepție este identificarea scopului inițial al aplicației (funcțional). Abordarea structurată are la bază descrierea mai multor aspecte sau procese care să ajute la îndeplinirea acestui obiectiv. De exemplu, în cazul de mai sus aspectele/procesele care trebuie luate în considerare sunt: • nivelul de detaliu al cerințelor ințiale (requirements envisioning, big requirements up front ), • modalități de vizualizare (usage modeling, domain modeling, process modeling), • strategii de modelare (formal, informal, interviews), • strategii de management al elementelor de lucru (scrum product backlog, work item pool, work item list, formal change management), • modalitatea de tratare a cerințelor non-funcționale (acceptance criteria, explicit list, technical stories).

management În funcție de contextul în care ne aflăm, vom alege pentru fiecare proces varianta care se potrivește cel mai bine necesităților actuale ale proiectului - dacă este vorba de un proiect în care trebuie să facem și suport putem alege un work item pool ca și modalitate de management al cerințelor de lucru în locul unui scrum product backlog. Pentru a ne asigura că aceste obiective sunt îndeplinite am introdus milestone-uri pe tot parcursul desfășurarii proiectului. Un exemplu concret al unui astfel de milestone este la finalul fazei de Incepție unde verificăm consensul tuturor părților în legătură cu scopul inițial al aplicației. Una dintre provocările cele mai mari ale acestei abordări este pe de o parte punerea la dispoziție a cât mai multor proceduri legate de cum anume obiectivele pot fi atinse și, pe de altă parte, evitarea situației de a deveni foarte prescriptivi . Metodologiile existente în momentul de față fie sunt foarte detaliate - când vine vorba de procesele pe care le implică (vezi cazul IBM RUP), fie descriu sumar activități importante din ciclul de viață al proiectului (vezi Scrum pentru partea de identificare a cerințelor inițiale sau instalarea soluției în producție).

Creșterea satisfacției clienților

Prin aplicarea acestor principii în cadrul tuturor proiectelor pe care le desfășuram în Yonder am reușit să creștem nivelul de satisfacție al clienților noștri, productivitatea crescută fiind unul dintre aspectele care au facut posibil acest lucru.

TODAY SOFTWARE MAGAZINE Această politică orientată către obiective crește foarte mult gradul de transparență în relația cu clienții, așteptările fiind setate și monitorizate corespunzător pe toata durata proiectului. Prin validarea continuă a “business case-ului” și a condițiilor inițiale care au generat proiectul - milestone multiplu în faza de Construcție – ne asigurăm de viabilitatea acestuia și punem la dispoziția factorilor de decizie toate informațiile necesare pentru ca hotărârile care se iau să fie bazate în primul rând pe numere și fapte concrete și mai puțin pe presupuneri. Un alt aspect important e legat de creșterea calității, care la o primă vedere pare a fi o componentă destul de subiectivă, prin adoptarea celor mai bune practici din metodologiile agile (XP, TDD) pentru a satisface anumite obiective și migrarea acestora către o zonă măsurabilă. Date fiind tendințele actuale de a lucra cu echipe mari, distribuite geografic, care activează în domenii complexe cu soluții tehnice la fel, scalabilitatea se impune ca un aspect important. Utilizând această abordare bazată pe obiective, în cadrul căreia se încurajează independența echipelor, menținem un nivel optim de guvernanță. În acest caz, scopul - dincolo de livrabilele aferente procesului de dezvoltare software - constă în oferirea unei soluții complete în care nevoile clientului sunt adresate în funcție de situația în care acesta se află. Astfel, punem bazele unui model care poate scala foarte ușor prin folosirea uneltelor potrivite, a practicilor și metodelor de succes dovedite

pe alte proiecte.

Concluzii

Această abordare disciplinată și structurată a proiectelor Agile, pe care am îmbrățișat-o în special în cadrul Yonder după obținerea certificarii CMMI level 3, ne-a ajutat la mărirea numărului de clienți actuali datorită exemplelor și rezultatelor pozitive, profesionalizarea serviciilor și creșterea predictibilității prin aplicarea și îmbunătățirea continuă a acestui model. Pentru ca cei interesați să nu treacă din nou printr-un proces de reinventare a roții și descoperirea tuturor acestor practici întrun mod empiric, cum se întâmplă în cele mai multe situații - un punct foarte bun de start al călătoriei către implementarea unui cadru agil disciplinat este cartea lui Scott Ambler și Mark Lines “Disciplined Agile Delivery”.

Mihai Buhai

mihai.buhai@tss-yonder.com Delivery Manager @ Yonder

www.todaysoftmag.ro | nr. 21/Martie, 2014

legal

Dezvoltatorii de aplicații mobile și datele personale. Vreo legătură?

utem avea de-a face cu date personale în activitatea noastră? Ce implică? Sunt întrebări legitime pentru un dezvoltator de aplicații mobile. Și aceasta, deoarece colectarea acestor date a devenit un fenomen inerent lumii digitale și un subiect din ce în ce mai controversat odată cu evoluția aplicațiilor mobile. De asemenea, subiectul este cu atât mai de interes cu cât, în viitor, se prefigurează o înăsprire a sancțiunilor pentru nerespectarea legislației datelor cu caracter personal. Prin urmare, fie că este interesat de o reputație bună în fața utilizatorului tot mai speriat de perspectiva de a i se invada viața personală, fie că vrea să se protejeze de eventuale sancțiuni legale, dezvoltatorul este obligat să țină cont de regulile aplicabile. Acestea sunt destul de multe și stufoase, iar acest articol nu își propune să le prezinte pe toate, detaliat. În schimb, pornind de la ipoteza de mai jos, ne-am propus să prezentam câteva principii relativ ușor de reținut pe care le puteți lua în considerare pentru a minimiza eventualele riscuri.

Ipoteză

A. este o societate din România și tocmai a finalizat procesul de dezvoltare a unei aplicații mobile. Este vorba despre o aplicație creată conform specificațiilor interne ale A., cu intenția de a o exploata comercial sub brandul propriu, nu despre o aplicație ce i-a fost comandată de către un client extern. Înainte de a „urca” aplicația pe platformele online relevante (Magazin Play, App Store, etc.) pentru a o face disponibilă utilizatorilor, A. află că ar trebui să mai aibă în vedere un aspect: prin intermediul aplicației se vor colecta pe serverul său unele date privind utilizatorii și, uneori, se vor transfera către parteneri din străinătate. Dar nu știe dacă acestea reprezintă date cu caracter personal și dacă implică respectarea unor norme legale.

Ce date cu caracter personal pot colecta aplicațiile mobile?

regim aparte - datele personale cu caracter special (în engleză, sensitive personal data) precum: preferințele sexuale ale utilizatorilor, originea lor rasială/etnică sau apartenența lor politică, etc. . Acestea necesită atenție sporită (mai ales, dacă sunt colectate pentru a fi apoi folosite în publicitatea targetată comportamental, analytics, etc.).

Conform Directivei europene ePrivacy1 (directivă transpusă și în legislația din România), tot ce înseamnă echipament terminal electronic (telefoane, tablete, laptopuri, etc.) și orice informații stocate pe acestea fac parte din sfera privată a utilizatorului și sunt protejate conform Convenției Europene pentru Protecția Drepturilor Omului și a Libertăților Câteva sfaturi utile Fundamentale. • Dacă dezvoltatorul este cel care Aceste informații pot fi considerate deține controlul datelor colectate prin date cu caracter personal indiferent dacă aplicație, poate fi considerat operator privesc o persoană fizică identificată (de de date cu caracter personal - adică perexemplu, prin nume) sau una identificabilă soana care stabilește scopul şi mijloacele (care poate fi identificată în mod direct sau de prelucrare a datelor - și va fi ținut de indirect). Pot avea legătură cu deținătorul obligațiile legale specifice, inclusiv înredispozitivului electronic sau cu oricare altă gistrarea la autoritatea competentă. persoană fizică (de exemplu, datele de con• Puneți la punct un mecanism intern tact ale prietenilor din agenda telefonica). și clar conturat privind prelucrarea dateIată câteva exemple: datele de localor cu caracter personal, încă dinainte lizare, geolocație, numele utilizatorului, de a începe lucrul la crearea aplicației și contactele din agenda telefonică, e-mail, de a scrie linii de cod. Acest procedeu se poze și videoclipuri, data nașterii, identinumește Privacy by Design2 (PBD) și este ficatori precum Unique Device Identifier un concept care facilitează un rezultat (număr IMEI, etc.), numărul de telefon, calitativ mai ridicat. Cu titlu de exemplu, istoricul apelurilor telefonice, a mesajesunt ghidurile realizatw de autoritățile lor sau a căutărilor pe Internet, informații din Marea Britanie3 și Australia4 pentru privind plățile efectuate prin card, date bioa veni în întâmpinarea dezvoltatorilor metrice precum recunoașterea facială, etc. . de aplicații mobile și pentru a promova Uneori, este posibil ca printre datele 2 http://en.wikipedia.org/wiki/Privacy_by_Design colectate să se regăsească și unele cu un 3 http://ico.org.uk/news/latest_news/2013/~/media/ 1 Directiva 2002/58/CE privind prelucrarea datelor personale și protejarea confidențialității în sectorul comunicațiilor publice (versiunea consolidată).

nr. 21/Martie, 2014 | www.todaysoftmag.ro

documents/library/Data_Protection/Detailed_specialist_guides/ privacy-in- mobile-apps-dp-guidance.pdf 4 http://www.oaic.gov.au/privacy/privacy-resources/ privacy-guides/guide-for-mobile-app-developers/privacy-by-design

TODAY SOFTWARE MAGAZINE Privacy by Design. În bună parte, aceste principii se pot aplica și dezvoltatorilor români. • Puteți face un studiu intern de impact prin care să abordați aspecte precum: (i) ce date personale vă trebuie și de ce, (ii) cum le colectați, folosiți, stocați, transferați, (iii) cum obțineți acordul utilizatorului pentru a-i colecta datele (inclusiv pentru cazul în care modificați scopul pentru care folosiți datele), (iv) dacă le dezvăluiți terților, (v) posibile riscuri și moduri în care le puteți evita/ reduce, etc. . • Încercați să mențineți colectarea datelor la un nivel minim, doar pentru scopuri determinate și legitime (de exemplu, să colectați numai datele necesare funcționării aplicației). Studiile 5 arată că utilizatorii tind să prefere și să rămână loiali aplicațiilor mobile cu o politică transparentă și minimală privind volumul de date colectate. • La momentul instalării aplicației, va trebui să obțineți acordul utilizatorilor nu doar pentru a descărca aplicația pe telefonul sau tableta lor, dar și pentru a le prelucra datele pe care aplicația le va colecta. • Pregătiți o politică privind prelucrarea datelor personale (în engleză, Privacy Policy) pe care să o puneți la dispoziția utilizatorilor (de exemplu, printr-un link) înainte să descarce și să instaleze aplicația și înainte să le colectați datele.

Puteți folosi grafică și culoare pentru a face informația mai accesibilă. • Privacy Policy ar trebui să indice, printre altele, tipurile de date colectate, scopul în care vor fi folosite (și de către cine), drepturile utilizatorilor, datele de contact ale dezvoltatorului aplicației. Aceste condiții esențiale trebuie îndeplinite pentru a se considera că ați oferit utilizatorilor informațiile necesare, iar aceștia și-au dat acordul informat și liber. Acordul liber implică să dați utilizatorului opțiunea să accepte sau să refuze prelucrarea datelor sale. De aceea, pentru a finaliza instalarea aplicației, ar trebui să fie disponibil și butonul „Refuză/ Anulează” (prelucrarea datelor), nu doar butonul „Da, accept”. • Păstrați securitatea datelor colectate - depuneți toate eforturile necesare (inclusiv tehnice) pentru a vă asigura că baza de date nu este în pericol de a fi „spartă” și copiată ilicit. În caz de utilizare ilicită, puteți fi chemați în judecată de către utilizatori care pot cere acordarea de daune. • În unele situații și în funcție de tipul aplicației, nu doar dezvoltatorul prelucrează aceste date, ci și distribuitorii aplicației, furnizorii de publicitate și analytics, librăriile third party, etc.; este util să explicați utilizatorilor modul în care datele lor vor fi folosite de către aceștia și de ce, etc.

Concluzie

Ca dezvoltatori, este în interesul vostru să implementați măsuri adecvate de protecție în aplicațiile mobile pe care le creați și le puneți pe piață. Privacy by Design este un concept din ce în ce mai popular și poate oferi o soluție tehnică unei probleme legale. Din ce în ce mai mult, aplicațiile care iau în serios și protecția datelor personale câștigă încrederea utilizatorilor, reușind să se diferențieze mai bine prin transparență.

Despre autori Claudia Jelea este avocat specializat pe aspecte ce implică mediul online, comerțul electronic și IT&C, mărcile, drepturile de autor și protecția datelor cu caracter personal. Este membră a Baroului București și a Camerei Naționale a Consilierilor în Proprietate Industrială (mărci). LinkedIn & Twitter: claudiajelea | www.jlaw.ro | www.avocatnet.ro/claudiajelea Cătălin Constantinescu este student în anul IV la Facultatea de Drept, Universitatea București și este interesat de interferența dintre drept și IT.

Claudia Jelea

claudia.jelea@jlaw.ro Avocat & Consilier in domeniul marcilor @ IP Boutique

5 http://www.truste.com/window.php?url=http:// download.truste.com/TVarsTf=7EDO6P8Z-187

www.todaysoftmag.ro | nr. 21/Martie, 2014

management

Cauza tuturor relelor în dezvoltarea soft…

e presupune că ar fi proasta definire a cerințelor. Este riscant să se adopte o poziție radicală și să se izoleze cauza determinantă la una singură. Extragerea defectuoasă a cerințelor este însă cu siguranță una dintre ele. Din scurta mea experiență, în timpul extragerii cerințelor, în ciuda celor mai bune intenții, nu se face uz de o înțelegere sau diferențiere exactă între noțiunile de cerințe și design al soluției. Nevoia și valoarea designului sunt incontestabile, dar in stadiile incipiente ale extragerii cerințelor, focusul ar trebui să fie îndreptat spre înțelegerea genezei cerinței pentru a putea genera cât mai multe opțiuni adecvate pentru sponsorii noștri. Riscurile de a nu face aceasta sunt multiple și se pot concretiza prin : • implementarea unei soluții specifice pentru o problema generală pe care nu suntem capabili să o surprindem și să o exprimăm; • pierderea interesului, a încrederii și a implicării persoanelor cu competență decizională în domeniul de specialitate, • confirmări false( urmând să suportăm consecințele mai târziu), sau mai rău, • efort de dezvoltare și costuri adiționale și în cele din urmă, eșecul proiectului.

aștepta de la ei să fie în întregime conștienți de relația dintre problemă și domeniu. Noi ca analiști de business, modelăm domeniul de business, mai exact, creăm o reprezentare simplificată și abstractizată a domeniului respectiv, cu toate avantajele și capcanele pe care modelarea le implică. Nu este cu nimic mai puțin valoros sau adevărat ca modelarea domeniului de business și a problemei : • ghidează activitatea de extragere a cerințelor, • ajută la formularea întrebărilor și la descoperirea problemelor, • a j u t ă l a d e s c o p e r i r e a inconsecvențelor, a cerințelor contradictorii și a disensiunilor dintre sponsori.

Dacă se ia în considerare o problemă exprimată prost, enunțată fără detalii, avansată prematur în etapa de analizare În cele ce urmează, câteva argumente a soluției – atunci începem să înțelegem din perspectiva unui analist de business. dificultățile cauzate în proiecte de cerințe slab definite.

O definiție magică

BAB OK def inește extragerea cerințelor (noțiunea de ”elicitation”) ca: a scoate la suprafață, a scoate la lumină ceva latent sau potențial; a extrage sub formă de informație sau răspuns. Conform IREB tehnicile de extragere a cerințelor îndeplinesc acel scop de a afla cerințele conștiente, inconștiente și subconștiente de la sponsori. Cuvinte precum : latent, potențial, conștient, inconștient și subconștient confirmă definiția latină a cuvântului: ”a extrage prin șiretlic sau magie”.Nu fără justificare. În opinia mea, totul se leagă de faptul că sponsorii nu au o viziune riguroasă asupra domeniului și din acest motiv nu ne putem

Obiectul activității de extragere a cerințelor

Este vorba atât despre cerințe venite din partea sponsorilor, cât și cerințe le g ate d e implement are a s oluț iei. Conform BABOK, cerința este : ” (1) O condiție sau abilitate de care un sponsor are nevoie pentru a rezolva o problema, sau pentru a atinge un obiectiv; Există mai multe definiții, dar cuvinte ca „problemă”, „oportunitate”, sau „const r ânge re” ( c u v a l o are p ote nț i a l ă pentru sponsori) apar în mod recurent. Designul pe de altă parte este o colecție de hotărâre cu referire la implementarea soluției.

nr. 21/Martie, 2014 | www.todaysoftmag.ro

Ușor de zis, greu de făcut, pentru că în mod aparent, nu ne pricepem prea bine la estimarea căror lucruri sunt de valoare pentru noi și în ce măsură. Mai mult decât atât, suntem predispuși să gândim în termeni de soluții, mai degrabă decât în termeni de probleme. Acest lucru este cauzat de ușurința de vizualizare. Acesta este motivul pentru care există dificultăți în găsirea demarcației dintre declararea/ definirea problemei pe de o parte, respectiv definirea soluției pe de altă parte. Bazându-se pe argumentul anterior, cerințele sunt „afirmații care traduc sau exprimă o nevoie și constrângerile și condițiile asociate acesteia”.Iată că astfel putem diferenția între cerințele sponsorilor și cerințele legate de implementarea soluției. Modelul Conceptelor de Bază în Analiza de Business are o definiție clară pentru concepte cum sunt : schimbare, nevoie, soluție, valoare, părți interesate, și context. Modelul asociază aceste valori, după cum urmează: • Cerințe: nevoie, valoare, sponsori; • Design: soluție, nevoie, context; Tragem concluzia că nu există nici o linie de demarcație precisă între cele două, întrucât acestea au în comun conceptul de „nevoie”. Ceea ce este sigur însă, este că atunci când începem activitatea de extragere a cerințelor, ar trebui să fie clar care este obiectul ei. În faza de inițializare a unui proiect ar trebui să stabilească regulile privind granularitatea dincolo de care noțiunile constituie mai degrabă detalii de design decât cerințe de business, detalii asupra cărora sponsorul nu insistă să imprime o direcție sau să își impună autoritate decizională.

TODAY SOFTWARE MAGAZINE Exemplul ferestrei

Să luam în considerare o situație banală. Un exemplu prin care aleg să abdic de la trivialitatea și de la modul în care această situație este tratată aproape de fiecare dată. Un exemplu pe care am de gând să îl utilizez ca pe o hiperbolă, pentru a ilustra un punct de vedere. Problema este reprezentată de imaginea de mai jos.

la curiozitate sau bârfă, instinctul de a se plânge, și nu în ultimul rând – obiceiuri inerente legate de munca de zi cu zi : consilierea, predarea, corectarea, provocatoare - sunt toate pârghii foarte importante pe care le putem utiliza în timpul extragerii cerințelor .

Se poate adopta una dintre abordările evidente cum ar fi : exprimarea unui interes comun, flatarea, quid pro quo sau,cei cu experiență sau îndrăzneți, pot exploata cu precauțiile necesare așa numitele referințe oblice (comentarii făcute indirect, fie într-o lumină pozitivă sau negativă,care generează, fie reacții de apărare sau critică; utilitatea acestora din urma constă validarea percepției domeniului de specialitate). De asemenea, fără ca partenerul să sesizeze, analiștii de business pot insinua în timpul discursului – o declarație provocatoare sau pot adopta o poziție antitetică, ceea ce va determina oameni competenți în domeniu să dorească să corecteze Observați răspunsul interlocutorului și în primul rând, reduceți amenințarea la adresa ego-ului. Nimănui nu îi place să fie arătat degetul în timp ce se află în lumina reflectorului. Pentru a fi mai câștigați pe termen lung, este mai bine sa ne comportăm mai degrabă ca un „complice” care înțelege provocările cuiva care trebuie să cunoască toate răspunsurile corecte și să evitam să cerem acele informații în mod nerespectuos, ca și cum ni se cuvin.

Pentru a o rezolva, am fi tentați să spunem ca trebuie să cumpărăm un geam termopan și dilema este rezolvată. Problema ar putea să fie formulată: - relativ la estetică, confort sau sănătate ( vântul și ploaia ajunge în casă, iar mobilierul și parchetul sunt distruse), sau - relativ la aspectul siguranței și a pierderii bunurilor materiale - expunerea la hoți. Să consideram puțin și contextul. Dacă acest cadru de fereastră gol este montat într-o instituție de sănătate mintală? Dar dacă aceasta se află într-o anexă gospodărească aflată pe un câmp de la țară? Este soluția evidentă,cea mai potrivită pentru ambele situații? În prima situație, ați fi cu siguranță interesați de siguranța și, de asemenea,de aspectul intimității. În acest caz, ar fi nevoie de sticlă nu doar izolatoare, ci și securizată, opacă. Pentru cadrul din mijlocul câmpului, s-ar putea să vrei doar să ai un adăpost temporar împotriva ploii - caz în care o folie mai rezistentă de plastic ar putea O combinație inspirată a tehnicilor de rezolva problema la fel de bine. extragere a cerințelor Una dintre tehnicile puse la dispoziție Tendințele naturii umane în timpul de către BABOK este interviul, care este activității de extragere a cerințelor definit ca o conversație care invită oameSe pot folosi spre avantajul nostru, mai nii să-ți spună în mod voluntar lucruri fără multe tendințe ale naturii umane în timpul a conștientiza neapărat că fac asta. Chiar etapei de extragere a cerințelor, dar nu și dacă este o conversație planificată, și pare dacă avem: că este simplu, faptul că trebuie să te bazezi • așteptări subiective, pe detalii pe care le primești în timpul • preconcepții, interviului și respectiv pe predispozițiile • dorință de auto-exprimare, psihologice - face din interviu un demers • dacă exploatăm anxietatea vizavi mai greu decât s-ar zice la o primă vedere. de performanța a celui intervievat. Se spune „nu planifica, și de fapt planifici să dai greș”; de aceea este Sentimente, cum ar fi : dorința de a recomandat să se înceapă prin formufi recunoscut sau apreciat, predispoziția larea întrebărilor relevante (deschise,

ipotetice) și să se ia în considerare relația cu interlocutorul, și anume atitudinea față de schimbul de informații. După aceasta, în timpul interviului, ar trebui să reformulăm întrebările primite pentru a motiva împărtășirea informațiilor și respectiv pentru a valida înțelegerea răspunsurilor primite și proiecția domeniului de business creată in mintea noastră. Există cuvinte cheie care pot fi utilizate pentru a menține atenția, și pentru a preveni ca informațiile importante să ne scape printre degete: DE CE - conduce la motivațiile profunde; CE - conduce la fapte, CUM - conduce la o discuție cu privire la proces, nu structură; POT - încurajează flexibilitate maximă. Alte întrebări utile sunt: Care anume este problema care trebuie rezolvată? Când apare problema? Ce generează problema? Ce situații sunt noi sau vechi? Cum este tratată problema acum? De ce există problema? Așa-numitele întrebări „situaționale” merg un pas mai departe, mai exact - prin acestea se întreabă despre o situație într-un mod care se testează înțelegerea domeniului. În opinia mea, acest lucru ar echivala cu înlocuirea variabilelor într-o formulă matematică, cu valori numerice. Cel mai important lucru pe care ar fi bine să îl facem în timpul etapei de extragere a cerințelor este nu să vorbim, ci să ascultăm, altfel riscăm să sugerăm în mod neintenționat răspunsurile celui intervievat. Atunci când punem întrebări, în primul rând trebuie să avem în vedere oportunitățile de abordat, problemele de rezolvat și constrângerile pe care trebuie să le respectăm. La fel ca majoritatea oamenilor, s-ar putea să fiți de părere că acest lucru este mai mult sau mai puțin o perdea de fum și că nu ajuta la scrierea codului și avansarea proiectului.Să luăm în considerare că s-a enunțat cu succes problema care trebuie să fie rezolvată, opțiunile pe care le avem la dispoziție să abordăm soluția, precum și restricțiile necesare pentru a asigura conformitatea. S-a întocmit de asemenea, o diagramă context (și acum știm dacă avem de

www.todaysoftmag.ro | nr. 21/Martie, 2014

management Cauza tuturor relelor în dezvoltarea soft… a face cu un cadru de fereastră aflat într-o anexă aflată pe un câmp de la țară sau întro instituție de sănătate mintală). În continuare vom aborda interfețele. Analiza interfețelor are scopul de a identifica legăturile dintre soluții și / sau componentele soluțiilor și de a defini modul în care acestea vor interacționa. Nu trebuie să uitam de interfețele aplicațiilor cu utilizatorii și nici despre interfețe cu dispozitive hardware externe sau de cele cu aplicații externe. Pentru definirea interfețelor, este important să se precizeze tipul și scopul acestora. Apoi se continuă cu datele de intrare și ieșire, definirea regulilor de validare care guvernează datele de intrare și ieșire, respectiv cu identificarea evenimentelor care declanșează interacțiuni.

elicitare a cerințelor recomandate de către specialiştii din industrie. Succesul sau eșecul de implementare a procesului soft depinde de calitatea specificaţiilor. Obținerea unor cerinţe clare, concrete şi punctuale depinde extrem de mult de metodele abordate în timpul fazei de colectare a cerinţelor. Toate tehnicile disponibile dau rezultate, atâta timp cât sunt folosite în circumstanțele adecvate. Cu atât mai mult, tehnicile sunt complementare unele altora, prin faptul că limitările unei tehnici sunt adresate de cealaltă. În continuare, vă prezentăm câteva recomandări : 1. Sesiuni de colaborare (workshops). Sunt modul standard de abordare a etapei de extragere a cerințelor. Avantaj : încurajează creativitatea și colaborarea între sponsori . 2. Best practice : • Este ideal pentru situații în care sunt implicați numeroși sponsori autonomi. • Se poate ține sesiunea sub control prin afișarea agendei și a regulilor întâlnirii respective, păstrați evidența ideilor rezultate, a subiectelor care urmează sa fie abordate ulterior și a subiectelor care blochează avansarea. • Încercați să aveți o persoană care facilitează întâlnirea și o persoană care ia notițe.

Există o dezbatere aprinsă cu privire la definirea cerințelor care ajută să clasăm acest subiect. Această dezbatere are schimburi de replici circulare, pentru a ajunge la concluzia viziunilor diferite ale grupurilor: ceea ce pentru un grup reprezintă cerința, pentru următorul grup, poate să reprezinte modul în care trebuie să rezolvăm problema, pe măsura ce trecem de la membri ai conducerii executive la ”executanți”. Nu există o rețetă unică pentru a preveni haosul în ceea ce privește cerințele, dar sunt și idei utile precum: acordarea importanței cuvenite etapei de determinare, după care conștientizarea și enunțarea Modele (data flow diagrams, state obiectivului și a obiectului activității charts, UML) dumneavoastră. După câteva runde de Această tehnică are o vechime istorică colectare a cerințelor, este recomandat ca care momentan joacă un rol în : treptat să facem trecerea spre proiecta• Facilitarea comunicării, rea soluției, definirea opțiunilor pentru • Identificarea detaliilor lipsă, a rezolva problema – presupunând că s-a • Organizarea informațiilor adunate înțeles problema / oportunitatea de adresat prin intermediul altor tehnici de elicitare, și… nivelul de granularitate impus de gru• Descoperirea inconsecvențelor. pul țintă al muncii de analiză.

Elicitarea cerinţelor – Best practices

Experienţa profesională acumulată de-a lungul timpului are o importanţă vitală în identificarea tehnicilor de elicitare corespunzătoare. Dragi colegi, noi ca analişti de business, dorim să livrăm în final un “business analysis approach” de o calitate ridicată. Gradul de mulțumire a cliențilori este extrem de greu de apreciat, însă nu e un target imposibil de atins. Prezentând într-o manieră coerentă şi punctuală situaţia, e firesc să ne întrebăm care sunt tacticile prin care vom obţine în final un client mulţumit? Doar prin aplicarea în practică a unor suite de tehnici de

Best practice

• Secvenţe de evenimente ordonate din punct de vedere cronologic utilizate pentru captarea interacţiunii dintre sisteme sau a oamenilor ce interacţionează cu sistemele. • Se recomandă crearea diagramelor DFD pe o tablă albă ca rezultat al colaborării, întrucât scopul acestora este acela de a crea un model mai bun al procesului, nefiind targetat ca documentaţie finală pentru client. • Construirea diagramelor DFD buttom – up având ca fundament de pornire analiza sistemelor iniţiale. • Utilizarea dicţionarelor de date ori de câte ori există mai multe grupuri de

nr. 21/Martie, 2014 | www.todaysoftmag.ro

interese diverse şi autonome. Dragi colegi, proiectele software analizate din perspectiva de business necesită abordări de elicitare a specificaţiilor ce se mulează pe cazuri reale şi pe constrângerile acestora. Noi, ca analişti de business avem nevoie de ghidare practică ce se articulează pe aplicarea bunelor practice aferente în faza de colectare a specificaţiilor.

Elicitarea cerinţelor – Provocări şi tendinţe viitoare

Înainte de a afla mai multe detalii utile legate de provocările şi tendințele viitoare ale procesului de elicitare, un analist de business experimentat ar trebui să aibă ca fundament de pornire imaginea întregului proces de colectare a cerinţelor.

Ce tehnici şi metode de elicitare să folosiţi în practică?

Se poate lua în calcul următorul exemplu: utilizarea mai multor tehnici de elicitare a specificaţiilor în proiecte caracterizate printr – o complexitate ridicată e posibil de aplicat în practică. Interviurile, tehnicile de prototyping şi interviurile, workshop – urile sunt combinate pentru a facilita procesul de colectare a specificaţiilor de pe acest tip de proiecte. Dacă se ia în calcul şi varianta echipelor virtuale distribuite geografic, în aceste circumstanţe este recomandată utilizarea technicilor de tip groupware (video conferinţe, cazuri de utilizare, sesiuni de brainstorming) ca un instrument adiacent procesului de management al cerinţelor. Acesta trebuie realizat extrem de punctual şi eficient. Nu trebuie omis faptul că technicile de elicitare au dezavantajele cât şi avantajele lor. Frumuseţea acestui proces constă în selectarea tehnicii corespunzătoare, iar această etapă presupune o înţelegere a audienţei business, cât şi a posibilităţilor avute la dispoziţie. Alt argument important: alegerea tehnicilor de elicitare a specificaţiilor e dependentă de contextul proiectului şi este considerat un factor critic în livrarea cu succes a procesului de elicitare. Factori importanţi: • Tehnica selectată e recomandată de metodologia abordată. • Tehnica aleasă e preferată de către analistul de business. • Orientarea către o anumită tehnică e guvernată de către simţul intuitive al analistului ca fiind “the best approach”av ând î n ve d e re c i rc u mst anţel e dateElicitarea unor specificaţii clare este

TODAY SOFTWARE MAGAZINE elaborată în parametri optimi dacă se va face apel la o suită de tehnici, nu doar la una singură – în majoritatea proiectelor, analiştii de business aduc în prim-plan utilizarea mai multor tehnici în funcţie de etapa SDLC – ului. Sfaturi utile pentru facilitarea activităţilor zilnice: • Lipsa motivaţiei stakeholder-ilor de s se implica proactiv în procesul de elicitare a cerinţelor; • Lipsa abilităţilor de captare abstracte: • Stakeholder-i clasificaţi în functie de nivelul de management; • Disponibilitatea temporală slabă a părţilor implicate; • Complexitatea ridicată a business matter-ului.

În AGILE

• Există riscul ca programatorii să nu înţeleagă specificaţiile primite. • Echipa de implementare nu are cunoştiinţe ale domeniului business afferent. Secretul evitării acestor situaţii mai mult sau mai puţin ortodoxe e unul extrem de simplu: ca analişti de business trebuie să ne motivăm continuu atât end user-ii, echipa de implementare,cât şi clienţii în vederea unei abordări colaborative, atât în planul comunicării şi spiritului de muncă în echipă. Un prim pas spre atingerea obiectelor menţionate în rândurile Provocări de mai sus constă în priDe-a lungul timpului s-au evidenţiat mul rând în selectarea o serie de provocări şi trenduri posibile în metodelor optime de elidomeniul elicitării cerinţelor. citare a specificaţiilor. Una dintre cele mai importante provocări este posibilitatea de implementare şi Tendinţe viitosre în elicitarea cerinţelor dezvoltare a unei strategii prin care să se În ciuda obținerii unei suite de succese reducă diferenţele existente dintre depar- și progrese în domeniul cerințelor, există tamentele de cercetare şi industrie. Aceste totuşi încă unele probleme care așteaptă diferenţe sunt definite la nivel de awareness, să fie luate în mod corespunzător, în acceptanţă sau adaptare la nevoile de busi- considerare. ness. Totodată, conform experţiilor BA, Potenţialele trăsături pe baza cărora se aceste target – uri pot fi atinse doar prin conturează viitoarele direcţii în domeniul setarea unor obiective concrete în practică elicitării specificaţiilor sunt listate în rânşi printr-o eficientă promovare a metode- durile de mai jos: lor corespunzătoare, astfel încât analiştii de • Reducerea decalajului dintre teorie și business să le aplice cu uşurinţă şi confipractică, precum și practicanţi cu experidenţă în munca lor zilnică. enţă și novici; Există probabilitatea ca analistul de • Creșterea gradului de conștientizare business să se mai confrunte cu următoași educație destinat celor interesaţi de rele provocări: acest domeniu, cât şi a părților interesate • Specificaţii conflictuale provenind de din industrie; la stakeholder diferiţi; • Dezvoltarea unor standarde pentru • Cerințe nerostite sau asumate; selecția tehnică și gestionarea impactului • Reticența părților interesate de a factorilor asupra procesului; schimba / sprijini proiectarea unui nou • Modalități de colectare și reutilizare a produs. cunoștințelor în ceea ce priveşte etapa de • Time management deficitar pentru colectare a specificaţiilor business; stabilirea unor şedinţe de lucru cu toate • Integrarea și utilizarea tehnologiilor grupurile de interese ale proiectului; actuale; • Aplicarea cu bună-ştiinţă a tehnicilor și metodelor de elicitare – creşte Concluzii nivelul de obţinere în final al unui client Procesul de elicitare a cerinţelor, alegemulțumit şi totodată asigurarea succesu- rea unei tehnici corespunzătoare depinde lui proiectului; de o suită de factori, dintre care merită să • Accesul limitat la părțile interesate îi amintim pe următorii: tipul proiectului de proiect; soft ce se află in curs de implementare, sta• Dispersarea geografică a stakeholder- diul în care se află proiectul sau domeniul ilor proiectului; business aferent. • Priorităţi conflictuale; Majoritatea abordărilor necesită atât un • Prea multe părți interesate sunt dor- nivel ridicat de experienţă în domeniu, cât nice de afirmarea unui efort participativ; şi ani de experienţă profesională solidă.

Cu toate acestea, există o suită de tehnici ce se folosesc cu o frecvenţă mai mare. Acestea sunt: interviuri, workshop-uri în grup, tehnici de observare, setare de obiective strategice şi scenarii – ele sunt utilizate cu un succes răsunător în practică. În cele din urmă, alegerea metodelor de elicitare a cerinţelor îi revine exclusiv analistului de business / inginerului de cerinţe, acesta luând decizia viabilă bazându-se pe mediul cultural, organizaţional sau pe constrângerile specifice domeniului de business.

Bibliografie 1.

2. 3.

6. 7.

A Guide to the Business Analysis Body of Knowledge(r) (Babok(r) Guide), by IIBA (Author), Kevin Brennan (Editor) Requirements Engineering, by Elizabeth Hull, Ken Jackson, Jeremy Dick Mastering the Requirements Process: Getting Requirements Right (3rd Edition), Suzanne Robertson, James Robertson Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam Foundation Level - IREB compliant (Rocky Nook Computing), by Klaus Pohl , Chris Rupp Ag i le S of t ware R e quirements: L e an R e qu i re m e nt s Pr a c t i c e s for Te ams , Programs, and the Enterprise (Agile Software Development Series),by Dean Leffingwell The Business Analyst’s Handbook, by Howard Podeswa Discovering Requirements: How to Specify Products and Services, by Ian Alexander, Ljerka Beus-Dukic OCEB Certification Guide: Business Process Management - Fundamental Level, by Tim Weilkiens , Christian Weiss , Andrea Grass Requirements by Collaboration: Workshops for Defining Needs, by Ellen Gottesdiener

Cluj Business Analysts www.meetup.com/ Business-Analysts-Cluj

Mădălina Crișan, CSPO, Business Analyst Monica Petraru, Product Manager Cătălin Anghel, Business Analyst

www.todaysoftmag.ro | nr. 21/Martie, 2014

management

Training de impact

n companiile mari, majoritatea angajaților primesc un training la momentul intrării în companie, iar apoi se practică repetarea acestora în funcție de nevoile de training ale companiei. În aceste condiții, am tinde să credem că angajați nu mai văd training-urile ca fiind speciale, dar ne înșelăm. Un studiu realizat de cercetătorii de la Universitatea Spaniolă Maderia ne arată că angajații se bucură de un training aproape la fel de mult ca de o mărire de salariu. Studiul aplicat pe 5000 de angajați din Spania arată că satisfacția față de angajator și implicit locul de muncă crește cu 18% după ce angajatul a participat la un training asigurat de companie. Același studiu demonstrează că pe 66% dintre acești angajați, trainingurile îi fac să se simtă mai bine în companie, iar 60% sunt mai puțin susceptibili de a pleca dintro firmă care oferă traininguri. În zile noastre, când oferirea unei măriri de salariu este puțin probabilă pentru multe business-uri, trebuie să ne calculăm pașii în avans și să dezvoltăm o strategie prin care să menținem satisfacția angajaților. Companiile care investesc constant în training au de regulă un turnover mai scăzut, care asociat cu un nivel ridicat de satisfacție a clienților va duce la profitabilitate. Pe de altă parte, companiile care nu sunt dispuse să investească în angajați, pun în pericol propriul succes și însăși supraviețuirea. Odată stabilită nevoia de training, survine întrebarea dacă să se externalizeze serviciul de training sau să fie susținut cu ajutorul resurselor interne. În acest context, există multe companii care au departamente interne de învățare și dezvoltare, care gestionează pregătirea și specializarea angajaților în funcție de nivelul la care au ajuns sau, de direcțiile dictate de piață. Însă, de cele mai multe ori, companile nu își permit să susțină un astfel de departament. Ideea principală este

de a satisfice nevoile de training pe care le are compania, pentru a putea supraviețui mediului concurențial. De luat în considerare atunci când trebuie să alegem între a externaliza trainingul sau a ne folosi de resursele proprii este faptul că angajații apreciază mai mult un trainer extern sau participarea la conferințe sau traininguri ce au loc în afara biroului. Din dorința de a rămâne cu calificări și certificate emise de o autoritate sau de o companie specializată, foarte mulți angajați se pare că apreciază mai mult un trainer extern. Pentru proaspătul angajat, faptul că trainerul este unul intern nu face o diferență. Lucrurile se schimbă atunci când un angajat vechi în companie are nevoie de o specializare și i se oferă un training ținut de un coleg de-al lui, care probabil este pe o poziție mai ridicată sau care la rândul lui a făcut acest curs în trecut și pentru care s-a plătit. Este clar că un astfel de training nu îi va aduce satisfacția mai sus menționată. Unele comanii aleg să externalizeze serviciile de training sau majoritatea nevoilor de training pe care le au. Alte companii aleg să țină trainingurile in-house și să creeze o curiculă originală a trainingului. Cu toate astea, majoritatea companiilor se află undeva la mijloc: când se descurcă, le țin in-house, când situația îi depășește aduc

nr. 21/Martie, 2014 | www.todaysoftmag.ro

trainer din exterior. O companie specializată în consultanță pe procese de dezvoltare a angajaților oferă certificate de specializare și vine cu tehnici de învățare și dezvoltare de ultimă oră. Ca urmare, există o multitudine de motive pentru care managementul unei companii ar decide să aducă un trainer din exterior: 1. Staff-ul este limitat ca număr și competențe 2. Existența unui număr mare de angajați care au nevoie de un training de specializare 3. Dorința managerilor de a avea angajații la current cu ceea ce se întâmplă în industrie Tipica investiție corporatistă în training și dezvoltare crește în fiecare an. Acest fapt este datorat vârstei companiilor ce consideră trainingul cea mai mare investiție în angajați. Tim Grant, HR Managerul companiei TAP Pharmaceuticals susține că într-o industrie în continuă dezvoltare și schimbare, angajații au nevoie de traininguri dictate de dinamica pieței. Totodată el apreciază că din moment ce angajații lor au nevoie de abilități și expertiză variată, companiile externe de training îi ajută să își obțină performanța dorită la momentul potrivit.

TODAY SOFTWARE MAGAZINE O altă companie ce consideră că trainerul extern este o variantă mai eficientă este Motorola Corporation. Fred Hamburg, Chief Learning Office la Motorola apelează tot timpul la traineri instruiți tehnic. El susține că partea de instruire a angajaților este consumatoare de timp și este foarte greu să scoți un om din producție pentru a-l pune să livreze traininguri. Hamburg este interesat de economisirea banilor, dar în același timp vrea să beneficieze de cei mai buni traineri din domeniu.

Avantajele colaborării cu un trainer extern sunt:

• Accesul la resurse adiționale și expertiză ridicată pe lângă faptul că trainerii reușesc să adapteze trainingul în funcție de cerințele clientului. • Instrumente de training de ultimă oră, aplicabile pe tipul de business • R e du c e re a r is c u r i l or pr iv i nd securitatea datelor și a informațiilor, administrarea datelor, un turnover mai scăzut al trainerilor experimentați. • Costuri mai scăzute – multe companii găsesc training-urile ca fiind costisitoare datorită sumei pe care trebuie să o disloce la un moment dat, însă la o privire mai atentă, costul explică expertiza și timpul trainerului, instrumentele folosite, și nu în ultimul rând materialele. Totodată, eșalonat în timp, costul angajării unui trainer full-time se dovedește a fi mult mai ridicat.

Dacă decizia de externalizare a fost luată, pentru a alege cel mai bun trainer trebuie să evaluați înainte mai mulți traineri, asta pentru că în ultimii ani au apărut foarte mulți pe piață. În evaluarea acestora trebuie să ținem cont de: experiența pe care o au în domeniu, deoarece majoritatea trainerilor nu au avut contact real cu ceea ce solicită clientul, ci doar o serie de cursuri și o certificare de trainer. Totodată puteți analiza un portofoliu al realizărilor, traseul și succesul înregistrat de acesta în carieră. Valorile pe care le promoveaza sunt și acestea importante, de asemenea dacă a scris cărți sau articole pe tema de interes, dacă sunt membrii ai unor organizații profesionale și testimoniale ale foștilor clienți. În cazul în care compania nu își permite un trainer, există și varianta trimiterii angajaților la conferințe și training-uri deschise. Aceasta poate fi o cale excelentă de a asimila informații și de a face networing cu persoane care au poziții asemănătoare cu ale lor. Dezavantajele sunt timpul petrecut în afara biroului și în unele cazuri, costurile. În multe cazuri, mai ales atunci când sunt implicați doar câțiva agajați, beneficiile conferințelor și a training-urilor deschise își merită banii. Atunci când alegem training-urile deschise la care să participăm trebuie să fim atenți din nou la expertiza trainerului, agenda training-ului, costul și nu în ultimul rând numărul de participanți – asta pentru că un număr prea mare de participanți poate să fie un obstacol în calea realizării exercițiilor

practice. În orice situație există argumente pro și contra externalizării serviciilor de training, ceea ce rămâne cert și constant este faptul că organizațiile trebuie să fie atente la nevoile specifice de training pentru a-și menține performanțele pentru însăși supraviețuirea brandului. Și pentru că angajații fericiți sunt cei mai buni ambasadori ai brandului, atunci când avem probleme în reținerea angajaților, putem miza pe faptul că un training îi va face la fel de fericiți precum o mărire de salariu.

Monica Soare

monica.soare@artwinconsulting.ro Manager @ Artwin

www.todaysoftmag.ro | nr. 21/Martie, 2014

diverse

MWC 2014: Smartphone-uri, Tablete, Phablete şi Smartwatch-uri

chipa Codespring tocmai a revenit de la Mobile World Congress 2014, locul unde are loc magia tehnologiei mobile! Samsung, Sony, HTC, LG, Nokia, Huawei au dezvăluit cele mai recente dispozitive şi inovaţii. O apariţie distinctă şi exotică totodată a fost echipa Yota din Rusia. Am remarcat bineînţeles şi echipa Allview care se strecoară cu ultimele sale dispozitive. Mai multe despre subiect, în rândurile următoare. Mai întâi trebuie să menţionăm multaşteptata intervenţie a lui Mark Zuckerberg - Fondator şi CEO Facebook. Purtând tipica sa ţinută confortabilă, Mark a răspuns întrebărilor legate de recenta sa achiziţie - WhatsApp şi a împărtăşit viziunea sa asupra viitorului prin prisma proiectului internet.org: “O mare parte din scopul nostru cu internet.org este de a crea o rampă către Internet. […] Într-o zi cineva ar trebui să încerce şi să ajute să conecteze toată lumea…” Conform explicaţiilor sale, planul pe anul viitor este de a construi câteva parteneriate pentru acest proiect şi de a testa modelul de lucru. Totodată a accentuat necesitatea de a creşte empatia dezvoltatorilor faţă de serviciile cu un mare consum de date pe care de fapt le dezvoltă. Luând în considerare perspectiva unei lumi hiperconectate şi transformarea stilului nostru de viaţă, principalii dezvoltatori şi inovatori de tehnologie mobile au încântat audienţa.

piaţă”, operând cu un sensor de 16MP mobile ce încorporează deja premiata lencapabil de video la rezoluţie de 4K, cu tilă G. Videourile background refocus, HDR în timp real şi f ilmate cu S ony o rată de captare de 0.3s. Camera faţă este Xperia Z2 vor încânta de 2.1MP. Estetica sa este captivantă: vor utilizatorii, dat fiind fi disponibile culori precum “Charcoal că poate capta la Black”, “Shimmery White”, “Electric Blue” rezoluţie 4k. Toate şi “Copper Gold”. Lansarea pe piaţă este acestea au la bază stabilită în aprilie 2014. Android KitKat, un procesor Qualcomm Snapdragon 801 – un CPU quad-core Krait de 2.3GHz – precum şi conectivitate 4G LTE, NFC, memorie RAM de 3GB şi o baterie de 3200mAh. Ecranul este pur şi simplu fascinant: display de 5.2 inchi , full HD cu know-how-ul Triluminos inspirat din Sony Bravia, asisS eria smar twatch dezvoltată de tat de GPU Adreno 330. Lansarea pe piaţă Samsung face un pas în faţă cu Samsung este stabilită în martie 2014. Gear 2 şi Samsung Gear 2 Neo. Aplicaţiile wrist-based sunt la modă şi pline de ima- Sony Xperia Z2 - Tabletă ginaţie. Conform declaraţiilor oficiale Cea mai uşoară şi subţire tabletă din ale reprezentanţilor Samsung , sistemul lume – Sony Xperia Z2 – este o mică şi Android va fi înlocuit cu noul sistem de fioroasă bestie tehnologică: are 6.4mm Samsung la MWC 2014 operare bazat pe platforma Tizen. grosime şi cântăreşte 426g! Este rezistentă Evenimentu l Samsung int itu lat la apă şi are multă putere: un procesor “Unpacked 5” organizat în data de 24 Sony la MWC 2014 Snapdragon 801 cu CPU quad-core Krait februarie 2014 a dezvăluit mult aşteptatul de 2.3GHz, şi pentru întregire un GPU Samsung Galaxy S5. Cu un ecran de 5.1 Sony Xperia Z2 - smartphone inchi Full HD Super AMOLED, Samsung Sony a făcut impresie la Mobile World Galaxy este rezistent la apă şi praf. Este Congress 2014 cu smartphone-ul de 5.2 echipat cu un chipset quad-core Krait inchi din gama de vârf: Sony Xperia Z2. 2.5GHz chipset, are o memorie RAM de Precum predecesorul său, Sony Xperia Z2 2GB şi o baterie de 2800mAh. În opinia este impermeabil şi acest fapt ne bucură! Samsung, camera încorporată în Samsung Capul de afiş este camera Sony de 20.7MP Galaxy S5 este “cea mai puternică de pe - un Exmor RS pentru senzorul de imagini

nr. 21/Martie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE concepute pentru segmentul low-cost şi aduc o perspectivă plină de culoare: verde deschis, roşu deschis, albastru deschis, galben, negru şi alb. Nokia X are un display IPS de 4 inchi, cu o camera de 3MP, carduri dual SIM şi stocare expandabilă cu un MicroSD. Cele două modele au la bază un procesor Qualcomm Snapdragon dual core Sony Smartwatch de 1GHZ, au 512MB RAM & 4GB eMMC generaţie. Inginerii programatori de la Alături de gama smartphone şi tablete, o baterie impresionantă de 1500mAh. Codespring sunt implicaţi în dezvoltaSony a dezvoltat şi o serie smartwatch: SW2 rea aplicaţiilor mobile de tip industrial şi şi Wrist Strap SE20. SmartWatch 2 extinde Huawei la MWC 2014 enterprise. Datorită expertizei câştigate, experienţa Android şi introduce modaliCu un aspect Premium, noul MediaPad înţelegem că mobilitatea este o reală forţă tăţi noi şi excitante de a trăi şi comunica. X1 dezvoltat de Huawei se remarcă prin- tractoare a lumii ITC actuale. Suntem preInteracţionează cu smartphone-ul prin tre produsele lansate de compania chineză gătiţi să discutăm proiecte dezvoltate pe Bluetooth®, iar ceea ce ţi se întâmplă în la MWC 2014. Una din cele mai mici următoarele arhitecturi: native, HTML5 şi viaţă se oglindeşte pe acest ceas. tablete de 7 inchi, MediaPad X1 este foarte cross-platform. portabilă şi confortabilă. Specificaţiile HTC la MWC 2014 impresionează: proPăstrându-şi premiera HTC One 2 pe cessor quad-core de data de 25 Martie 2014, HTC a adus în 1.6GHz, 2GB RAM, lumina reflectoarelor la MWC 2014 capul stocare internă de de serie din gama medie: HTC Desire 816. 1 6 G B, m i c ro SD, Cu un procesor quad-core Snapdragon 400 conectivitate 4G şi de 1.6GHz, are o capacitate de stocare de baterie de 5000mAh. 8GB şi este echipat cu o memorie RAM de Lansarea pe piaţă este 1.5GB. Capacitatea de stocare poate fi adusă programată la mijlocul la 64GB un card microSD. Tehnologia anului 2014. NFC, conectivitate DLNA, Bluetooth 4.0, Wi-Fi şi 4G/LTE – sunt toate disponibile. YOTA la MWC 2014 Lansarea este programată în aprilie 2014. Yota Devicescompania care a devenit Prototipurile de smartwatch ale HTC celebră prin crearea primului ecran dual au fost de asemenea prezente la MWC din lume și a smartphone-ului always2014, în regim huis-clos. on, a dezvăluit noua generaţie YotaPhone la Mobile World Congress 2014. Această LG la MWC 2014 nouă generaţie YotaPhone prevede conSupradimensiunile au frumuseţea pro- trol full-touch pe EPD-ul său always-on. prie! – Cel puţin aşa o demonstrează LG la Sloganul YotaPhone este: “1-Look, 1-Touch congresul de tehnologie mobilă MWC 2014 Always-On Display”. Rulând pe un procu noua sa phabletă sau smartphone-ul cessor Qualcomm quad-core 800, prevede supradimensionat: LG G PRO 2. Cu un dis- şi un mod Smart Power, încărcare wireplay full HD de 5.9 inchi, LG G PRO 2 este less, NFC, protecție avansată anti-furt, mai mare decât oricare din phabletele exis- IHF performant şi - în plus - YotaPhone tente. Specificaţiile sunt decente: 2.26GHz SDK-ul care tocmai a fost deschis pentru quad-core, RAM de 3GB, stocare internă de terţi dezvoltatori. 16/32GB, sistem Android 4.4 KitKat. Adreno 330. Ecranul de 10.1 inchi este un display Full HD Triluminos cu tehnologie X-Reality. Viteza de încărcare a bateriei a fost crescută cu 75%. Construit pe sistem Android Kitkat 4.0, tableta va fi disponibilă în negru şi alb. Lansarea pe piaţă va avea loc în martie 2014.

NOKIA la MWC 2014 În mod surprinzător, Nokia trece la Android cu Nokia X şi Nokia X+ prezentate la Mobile World Congress 2014. Perioada Windows Phone în exclusivitate s-a încheiat. Semănând mult cu Lumia, cele două noi dispositive sunt

Allview la MWC 2014

Echipa din Braşov – Allview – a lansat la MWC 2014 capul de serie din gama DualSIM: Viper S. Echipat cu un procesor Qualcomm Snapdragon Quad Core de 1,4 GHz, un displaz IPS HD OGS de 5 inchi, 2GB RAM, și stocare de 16GB expandabilă la 48 GB, Viper S are şi două camere Omnivision de 13 MP respectiv 5MP, tehnologie NFC, o baterie de 2500 mAh şi este dezvoltat în baza Android 4.3 Jelly Bean. Codespring, companie de dezvoltare software şi outsourcing, monitorizează inovaţiile şi tehnologiile mobile de nouă

Diana Ciorba

diana.ciorba@codespring.ro Marketing Manager @ Codespring

www.todaysoftmag.ro | nr. 21/Martie, 2014

diverse

Gogu și justificarea acțiunii - Gogule, probleme?! Șefu’ se proțăpise în fața biroului lui Gogu și încerca să-i deslușească fața din spatele display-ului. Toți ochii erau îndreptați spre ei: de vreo 10 minute se auzeau numai bolboroseli din zona strategic denumită „Gogu”, dar nimeni nu avuse curajul să verifice ce se întâmplă cu el, dacă și cine îl enervase. Era riscant să te afli în fața artileriei de remarci usturătoare a lui Gogu, iar bolboroselile neinteligibie erau un semn clar – și confirmat de multe situații similare - de pericol. - Gogu, vreo problemă, pot oare să te ajut cu ceva? Insistă inconștient Șefu’. - Apoi, soarele lor de mamuți, topi-li-s-ar ghețarii, cred că da, izbucni Gogu, iar colegii se așezară mai bine pe scaune, se lăsară pe spătarele fotoliilor, își întinseră picioarele, într-un cuvânt, toți se pregătiră de show. Șefu’ simți mai mult decât văzu mișcarea și decise să le facă jocul: - Ia zi, că te văd ușor nervos, ce s-a întâmplat? Gogu nu văzu din spatele display-ului zâmbetul abia mascat al lui Șefu’ și se lansă într-o tiradă tumultuoasă, spre deliciul colegilor încântați de spectacol. - Le-am zis de trei zile, de trei zile!... Și nimeni n-a răspuns. Cum e posibil?! Explică-mi matale, Șefule, cum se poate ca o echipă întreagă să ignore așa o cerință. Care, până la urmă, este în avantajul nostru... Și nimeni, dar nimeni! n-a catadicsit să răspundă la e-mail. Și voi ce vă holbați, măi, la mine, ca la circ? Continuă el, observând audiența care îi sorbea fiecare vorbă. Cum tonul rămăsese același iar întrebarea venise în continuarea întrebărilor retorice de până atunci, mulți nici nu își dăduseră seama că fuseseră prinși asupra faptei, respectiv că deveniseră ținta artileriei lui Gogu. Mișu însă simțise pericolul și încercă să se retragă ușor, alunecând cu scaunul spre biroul lui. Cum fusese unica mișcare în zonă, atrase imediat privirea lui Gogu care zise cu reproș: - Și tu, Brutus?! după care atacă imediat: Ah, păi da, „domnu’ Mișu”, că nici tu n-ai mișcat nimic, nici usturoi n-ai mâncat, nici gura nu-ți miroase... era greu, măi melc blocat în marșarier, să te uiți peste CV-ul ăla al tău, să actualizezi și tu două linii acolo și să mi-l trimiți înapoi? Că doar nu-mi trebuiau să i le dau lui mama! Rămăsese cu privirea atârnată de Mișu și era clar că – de această dată – nu era vorba despre o întrebare retorică: aștepta un răspuns. Mișu căută ajutor la Șefu’, dar acesta îi ocoli privirea. Savura scena din plin și era evident că nu voia să o întrerupă. - No, că nu te lua amu’ de mine, zise Mișu tărăgănat, încercând să tragă de timp doar-doar va găsi o scuză sau măcar o replică cât de cât inteligentă la acuzațiile lui Gogu. După principiul „cea mai bună apărare este atacul”, găsi rapid replica (în ciuda renumelui său de ardelean molcom) și contraatacă: - Da’ nici tu n-ai zis la ce-ți trebe’! Gogu rămase interzis: Da’ la ce-ți trebe’ ție să știi? gândi el, dar nu dădu glas replicii. Nu era o replică inteligentă și nici nu-i stătea în fire să arunce cuvinte aiurea. O idee năstrușnică i se înșurubă în creier: Hmm, oare asta să fi făcut diferența?

nr. 21/Martie, 2014 | www.todaysoftmag.ro

Mișu și ceilalți așteptau atacul furibund al lui Gogu. Care – surpriză! - nu mai veni: se vedea că Gogu procesează informația. Să fie oare justificarea atât de puternică încât să declanșeze acțiunea? Gogu se uită la Șefu’ după ajutor: - Șefule, ar fi contat? Conform arhicunoscutului său obicei, Șefu’ se sprijini pe un colț de masă, se lăsă ușor pe spate, își luă aerul sfătos și zise: - Da. După care plecă. *** Seara, acasă, Gogu încă era sub influența discuției din birou. După plecarea Șefului, ieși la o cafea cu Mișu și despicaseră firul în patru, discutând despre motivație, despre cum o formulare a unei cerințe poate influența satisfacerea ei, „chestii adânci” – după cum le numea Gogu - și care îi făceau mare plăcere. - Tata, vreau să mă uit la televizor – apăru pe neașteptate băiatul lui Gogu din camera lui. - Ei, da, vezi-ți de lecțiile tale și lasă televizorul. Te-am văzut că toată seara ai butonat calculatorul, acu’ vrei să treci la teveu? Ntz... - Gogule dragă – interveni soția - e o emisiune despre influența tehnologiei asupra dezvoltării mentale a tinerilor, este extrem de educativă și cred ca i-ar fi utilă copilului. La asta voia să se uite, eu zic că n-ar strica, dar e evident, decizia ta... Evident, evident – o maimuțări Gogu. În gând, evident, că doar nu era nebun să o facă cu voce tare. Pe de altă parte, pusă problema așa, mai putea să o contrazică?! Fir-ar să fie de treabă, ia uite cine știe de puterea justificării... Mormăi: - Ei, da, bine că mi-ați sărit amândoi în cap... dați-i drumu’ acum, ce pot să zic?! M-au biruit...

Simona Bonghez, Ph.D.

simona.bonghez@confucius.ro Speaker, trainer şi consultant în managementul proiectelor, Owner al Colors in Projects

partener gold

sponsori