[Title will be auto-generated] by Today Software Magazine

No. 12 • Iunie 2013 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

te a z a me b

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

ds” i r g ta a d “ pe ști

âne m o r r urilo p u t r a rii st o t ă in iOS r Susț o l i i licaț p a a ritate u c e S

Siste

Gemini Solutions Foundry TechHub Bucharest Din uneltele artizanului software: Unit Testing

Haskell(II) JQuery Europe 2013 Behavior Driven Development în Python

Cod curat = bani în buzunar

Planificarea Testării de Performanţă

Eclipse Rich Client Platform

Test Driven Development (TDD)

Big Data, Big Confusion

Managementul performanței (II)

NEO4j Graph Database Hadoop(II)

Start me up - Akcees De ce ne răcim gura cu AGILE?

6 Susținătorii startup-urilor românești

30 Test Driven Development (TDD)

Ovidiu Mățan

Ladislau Bogdan și Tudor Trisca

9 TechHub Bucharest

33 Big Data, Big Confusion

Irina Scarlat

10 Gemini Solutions Foundry Radu Popovici

11 Start Me Up Irina Scarlat

Mihai Nadăș

35 Sisteme bazate pe “data grids” Attila-Mihaly Balazs și Dan Berindei

37 NEO4j Graph Database modelarea datelor interconectate Iulian Moșneagu

12 NGO connect

39 Hadoop (II)

Echipa NGO Connect

Radu Vunvulea

13 Istoria IT-ului Clujean (VI) Marius Mornea

15 Dezvoltarea de aplicaţii iOS ţinând cont de securitate Cristian Roșa

18 JQuery Europe 2013 Andrei Otta

21 Managementul performanței (II) Andreea Pârvu

24 Din Uneltele Artizanului Software: Unit Testing

41 Programare Funcțională în Haskell (II) Mihai Maruseac

44 Planificarea Testării de Performanţă Alexandru Cosma

46 Recenzia cărții: Eclipse Rich Client Platform Silviu Dumitrescu

48 De ce ne răcim gura cu AGILE? Bogdan Nicule

50 Cod curat = bani în buzunar

Alexandru Bolboaca și Adrian Bolboacă

Dan Nicolici

27 Behavior Driven Development în Python

50 Gogu la drum cu jaloane

Ramona Suciu și Dan Pop

Simona Bonghez, Ph.D.

editorial

Ovidiu Măţan, PMP

ovidiu.matan@todaysoftmag.com Fondator și CEO al Today Software Magazine

m asistat de curând la gala de închidere a programului de antrepreonoriat în echipe Tandem organizat de GRASP Cluj unde am urmărit prezentările a patru echipe ce au arătat proiectele de antreprenoriat realizate în cele opt săptămâni cât a durat programul. A fost interesant să constat că toate aceste proiecte nu aveau ca bază IT-ul, fiind propuse business-uri tradiționale din domeniul agriculturii precum cultivarea plantelor sau creșterea animalelor. Timpul de dezvoltare estimat al unuia dintre ele se întindea pe parcursul mai multor ani până să ajungă la maturitate și să fie lansat pe piață. Din acest punct de vedere, al timpului implicat în materializarea unui proiect de antreprenoriat, domeniul IT este mult mai avantajat. Putem crea un prototip într-un week-end sau într-o noapte, stând acasă sau participând la un hackaton. Este atât de simplu și ușor să materializezi o idee! Chiar dacă nu ești din mediul de IT sau dacă nu ai acum ideea ce va schimba lumea poți participa la Startup Weekend sau Startup Live și să te alături uneia dintre echipe. La finalul weekend-ului vei avea deja disponibil un prototip iar în următoarea săptămână poți să obți suport din partea unor incubatoare locale. Vă încurajăm să faceți acest exercițiu, iar pentru cei ce l-au făcut deja și au un prototip, am pregătit articolul Susținătorii Startup-urilor românești. Lansăm și un nou serviciu, www.programez.ro, o nouă modalitate de comunicare între specialiști. Practic, panelurile unconference ce se desfășoară în cadrul evenimentelor de lansare vor putea fi continuate online pe acest forum de discuții. De asemenea, ne va face plăcere să răspundem întrebărilor tehnice pe care le aveți din toată sfera de IT: programare, testare, management sau HR. Fiind o inițiativă TSM, vă putem garanta răspunsuri venite direct de la specialiști. O altă noutate este introducerea unui nou canal de comunicare cu cititorii noștri, prin suportul oferit de TXT Feedback. Aceste startup local oferă posibilitatea de a comunica în magazine și nu numai prin intermediul SMS-urilor. Astfel, începând cu luna iunie, vă oferim posibilitatea de a ne transmite feedback-ul sau întrebările voastre direct, printr-un SMS la numărul 0371700018. Un eveniment important, ICT Spring Europe 2013, va avea loc în Luxembourg în perioada 19-20 Iunie, la care vom fi prezenți la acesta cu numărul 12 TSM. Vă invităm să participați alături de noi, iar pentru aceasta vă oferim un cod promoțional ce va oferă participarea gratuită la eveniment: TSMS13. Articolele din acest număr debutează cu o listă de incubatore și cowork-uri implicate activ în susținerea startup-urilor românești. Puteți să o folosiți cu încredere. Testarea primește o atenție binemeritată printr-o serie de articole ce au în focus Test Driven Development (TDD), Behavior Driven Development (BDD) precum și Performance Testing. Dezvoltarea aplicațiilor în cloud este dezbătută pe larg în Big Data, Big Confusion, Sisteme cu perfomanță/fiabilitate ridicată bazate pe “data grids” în Java, NEO4j Graph Database modelarea datelor interconectate și Hadoop (II).Continuând în aceeași notă de dezvoltare software veți găsi partea a II-a din Programare Funcțională în Haskell. JQuery Europe 2013 a fost un eveniment de excepție, iar în acest număr avem un articol dedicat acestuia. Închei prin a reaminti de proiectul Timeline care este în derulare. Pe scurt, TSM a inițiat un proiect care vizează realizarea unui afiș infografic referitor la dezvoltarea companiilor românești și la principalele realizări ale acestora. Adresa de email timeline@ todaysoftmag.com este dedicată celor ce vor să fie parte din acest proiect.

Vă dorim o lectură plăcută !!!

Ovidiu Măţan

Fondator și CEO al Today Software Magazine

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Lista autorilor 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 Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com Copyright/Corector: Emilia Toma emilia.toma@todaysoftmag.com Traducător: Roxana Elena roxana.elena@todaysoftmag.com Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com Produs de

Alexandru Bolboaca

Dan Berindei

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

Software Developer @ Infinispan

Irina Scarlat

Mihai Maruseac

Irina Scarlat este Co-Fondator al Akcees

IxNovation @ IXIA membru ROSEdu, ARIA

Silviu Dumitrescu silviu.dumitrescu@msg-systems. com

Radu Vunvulea

Consultant Java @ .msg systems Romania

Senior Software Engineer @iQuest

alex.bolboaca@mozaicworks.com

irina.scarlat@howtoweb.co

Mihai Nadăș mihai.nadas@tss-yonder.com CTO @ Yonder

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

Radu.Vunvulea@iquestgroup.com

Adrian Bolboaca

adrian.bolboaca@mozaicworks.com

Radu Popovici radu.popovici@geminisols.ro

Bogdan Nicule

Software Engineer @ Gemini Solutions

Bogdan Nicule este un Manager IT cu o vastă experienţă internaţională.

BNicule@neverfailgroup.com

Iulian Moșneagu

iulian.mosneagu@geminisols.ro

Dan Pop

dan.pop@3pillarglobal.com Senior Software Engineer @ Gemini Solutions

Senior Test Engineer @ 3Pillar Global

Andreea Pârvu Attila-Mihaly Balazs

ISSN 2284 – 6352

mihai.maruseac@gmail.com

Programmer. Organizational and Technical Trainer and Coach @Mozaic Works

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

dan@infinispan.org

dify.ltd@gmail.com

andreea.parvu@endava.com Recruiter în cadrul Endava

Code Wrangler @ Udacity Trainer @ Tora Trading

Andrei Otta

Ramona Suciu

Software developer @ Accesa

Test Lead @ 3Pillar Global

andrei.otta@accesa.eu

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

ramona.suciu@3pillarglobal.com

Simona Bonghez, Ph.D.

Cristian Roșa

Speaker, trainer şi consultant în managementul proiectelor,

mobile developer @ ISDC

simona.bonghez@confucius.ro

cristian.rosa@isdc.eu

Owner al Confucius Consulting

Alexandru Cosma

alexandru.cosma@isdc.eu Senior Tester @ iSDC

Tudor Trișcă

tudor.trisca@msg-systems.com Software Developer @ .msg systems Romania

www.todaysoftmag.ro | nr. 12/Iunie, 2013

startups

Susținătorii startup-urilor românești

eși ne aflăm la început în privința startup-urilor românești și încă nu ne putem mândri cu o cultură de masă a mediului de IT autohton, susținătorii acestora încep să își facă din ce în ce mult mult simțită prezența. Prin acțiunile și facilitățile oferite au un scop comun și anume suportul business-urilor locale și succes-ul acestora. Articolul de față se vrea a fi o listă de puncte de contact pentru oricine are sau dorește să lanseze un startup.

Co-work-urile sau spațiile de lucru comune

O practică nouă pe piața locală este reprezentată de închirierea unui birou pentru un anumit număr de ore sau zile. La finalul zilei acel spațiu este eliberat astfel încât ziua următoare altcineva poate să îl folosească. Avantajul acestei abordări este diversitatea, posibilitatea de a realiza rapid legătura cu diferite alte business-uri și de a putea lua rapid pulsul local. Datorită naturii acestora de a nu avea un spațiu permanent dedicat, numărul de evenimente organizate este mare, iar prin legăturile sau organizațiile afiliate vizibilitatea business-urile este mărită.

TechHub București Serviciile oferite • spațiu co-working, • birouri de tip rezident cu acces 24/7, • evenimente organizate de TechHub și comunitatea online.

Costurile lunare pentru a lucra în cadrul co-work-ului? 140 EUR/lună iar în prima lună se oferă un discount de 20 EUR. Pentru startup-uri suntem întotdeauna deschiși la discuții. Care sunt criteriile pentru a fi acceptat? Aceleași pentru toată lumea ...dacă ești serios, motivat, muncitor și open minded atunci ești acceptat. Care sunt activitățiile din cadrul Cowork-ului? În fiecare săptămână se desfășoară evenimente interesante cum este GeekMeet. În afară de aceste evenimente de relaxare și socializare cum ar fi Sangrianights, Cocktail courses, sushi making & eating și barbecue’s. Datele de contact: • str. Emil Isac, nr. 3, Cluj-Napoca • clujcowork.ro

Afilierea la o organizație internaţională • TechHub, comunitate globală dedicată exclusiv antrepre- Cluj HUB norilor în tehnologie, fiind reprezentată în prezent la Londra, Pe lângă posibilitatea de a-ți desfășura activitatea profesională Manchester, Riga și Bucureşti. de la unul dintre cele 4 nivele (+gradina) dotate cu birouri și mese colaborative, la ClujHub îți oferim și servicii conexe care aduc Criteriile de acceptare: valoare business-ului tău: • Startup-uri tech. • servicii financiare și contabilitate specializate pe start-up, Datele de contact • servicii juridice și de „intelectual property”, • blvd. Nicolae Filipescu nr. 39 - 41, etaj 1, sector 1, București, • servicii de business development și consultanță în atragerea • bucharest.techhub.com de investitori, • servicii de matchmaking și networking, Cluj CoWork • servicii de găzduire a sediului social, Un spațiu plăcut în centrul Clujului oferind senzația de acasă. • servicii de printing și design, Există suport de internet (WiFi), fructe, apă și cafea. Dacă vre• închirieri săli pentru workshop-uri și conferințe până la mea este bună se poate lucra pebalcon și ești înconjurat de oameni maxim 90 de persoane. muncitori deschiși să te ajute în cazul în care aveți probleme. Cluj CoWork te face productiv într-un mod relaxant. Pentru startupNumărul de echipe înscrise:În momentul de față mai mult de uri se oferă programe de mentorat, design și suport în dezvoltarea 10 companii fac parte din comunitatea noastră estimând ca până aplicațiilor. la sfârșitul anului 2013 vom ajunge la 35 companii și mai mult de Investiții: Au fost făcute investiții financiare, de timp și servicii 50 de membri. pentru startup-uri. Modul de atragere a investitorilor: Dintre companiile pe care le Cum sunt atrași investitorii? Folosim networking-ul propriu găzduim una dintre ele a obținut o finanțare în cadrul unui propentru aceasta gram de accelerare de aproximativ 30 000 euro.

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Perioada de incubare:Investitorii cu care comunicăm fac parte atât din comunitatea locală și ne întâlnim periodic cu ei dar avem și investitori din comunitatea internaţională. Afilierea la o organizație internaţională: Nu avem o afiliere la o organizație internaţională, dar colaborăm cu multe entități similare. Modul de tarifare: Pentru a-ți desfășura activitatea din cadrul ClujHUB, pe aria de cowork, tarifele pentru membri încep de la 30 euro și pot ajunge la 140 euro pentru nivelul full acces. Criteriile de acceptare: Criteriile de acceptare sunt destul de subiective mergând pe potrivirea lor cu ceilalți membri ai comunităţii dar plecăm în profilarea noastră de la: • freelanceri - profesii liberale sau startup-uri, • străini cu delegaţii în Cluj; în aceasta arie avem un parteneriat de lunga durată cu Cluj International Club, • companii care vizează investiţii locale, • antreprenori care dezvoltă servicii sau produse noi și care aduc inovația în piață, • antreprenori sociali și persoane care valorizează implicarea în comunitate, • persoane open minded și deschise către colaborare și dezvoltare personală. Activitățile din cadrul incubatorului: sunt multe evenimente care poate trebuie tratate separat pentru că din iunie vor fi mai numeroase. Datele de contact: • str. Pitești, nr. 9, Cluj-Napoca • clujhub.ro

Platforme de crowdfunding

Implicarea comunității în suportul dezvoltării proiectelor este un lucru inedit. Suportul vine direct de la utilizatorii ce doresc să devină clienții respectivei afaceri înainte ca aceasta să existe de fapt. Propunerea din acest număr, multifinanțare.ro reprezintă o abordare interesantă.

multifinanțare.ro Oferă ser vicii de crowdfounding prin publicarea proiectelor pe platforma proprie. Fiecare proiect ce obține 50% din suma cerută de la crowd va primi încă 50% din partea investitorului. Proiectele acceptate trebuie sa aibă o componentă inovativă. Acestea au asigurată consultanță juridică, financiară fiscală și investițională. Vom publica mai multe despre această inițiativă într-unul din numerele viitoare ale revistei. Date de contact: • multifinantare.ro • B-dul N. Titulescu Nr. 4 , Cluj-Napoca

Acceleratoare/incubatoare de startup-uri

Dacă în soluțiile de până acum, suportul oferit era ca un serviciu adițional, iar motorul business-ului era reprezentat de închirierea spațiului sau reținerea unui procent din suma obţinută, aceleratoarele/incubatoarele reprezintă o categorie unde succesulacestora este legat 100% de startup-uri. Problema principală în acest caz este acceptarea în cadrul acestora, iar odată acceptat beneficiați de sprijin dedicat pentru transformarea startup-ului într-un business real.

Gemini Solutions Foundry Este primul incubator destinat exclusiv startup-urilor IT din România ce facilitează crearea conexiunilor între antreprenorii români și investitori din Silicon Valley. Oferă echipelor acceptate în programul de incubare spațiu de birouri la cheie cu toate utilitățile necesare și acces la săli de conferințe și de prezentări. Mentorship-ul tehnic este asigurat de persoane cu o bogată experiență tehnică din echipa Gemini Solutions, persoane ce au lucrat pentru companii de diferite dimensiuni de la startup-uri până la multinaționale în aproape toate domeniile existente, de la back-end la front-end, de la cloud computing la aplicații destinate pentru mobile. Consultanţă financiară și cea legală oferite au ca scop ușurarea muncii depuse în aceste direcții pentru a permite antreprenorilor să se concentreze la ceea ce contează cu adevărat într-un start-up și anume implementarea ideii. Dar poate cea mai interesantă facilitate este reprezentată de conexiunile cu fonduri de investiții din Silicon Valley. Aceste conexiuni se fac în cadrul unui eveniment anual denumit Demo Day unde echipele vor prezenta atât ideea lor cât și progresul efectuat în cadrul programului de incubare. Acest tip de finanțare este foarte important pentru creșterea ulterioară a echipei deoarece pe lângă banii primiți echipa beneficiază și de conexiunile dar și de îndrumarea investitorului, altfel spus: Smart money. Datele de contact: • gemsfoundry.com

NextPhase NextPhase este interesată de proiecte inovative care au potenţial comercial. Prin implicarea sa, Ne x t P h a s e c o m pletează resursele necesare proiectului pentru a asigura progresul corespunzător al acestuia. Astfel, în proiectele pe care le considerăm de interes, noi putem să participăm printr-o combinaţie de servicii, cum ar fi: organizarea şi managementul procesului de cercetaredezvoltare, elaborarea şi managementul strategiei de proprietate intelectuală, furnizarea de infrastructură,finanţare, managementul business-ului, elaborarea şi dezvoltarea strategiei de creştere, acces la surse suplimentare de investiţie, programe de formare (training) pentru echipele de inventatori/antreprenori. Cu o adaptare www.todaysoftmag.ro | nr. 12/Iunie, 2013

startups corespunzătoare a termenului, am putea afirma că NextPhase este un incubator de tehnologie de tip “one stop shop” unde ideile cu potenţial comercial găsesc ceea ce au nevoie pentru a deveni afaceri de succes. Numărul de echipe înscrise -La 31 Dec 2012, aveam 2 proiecte în derulare și 3 proiecte în pregătire. Următorul proiect va fi în domeniul de software, mai precis modelare şi simulare şi va fi demarat în luna Iunie. Celelalte două proiecte, cel mai probabil, vor porni spre sfârşitul celui de-al treilea trimestru al acestui an. Modul de atragere a investitorilor - Până la un anumit nivel, NextPhase este investitorul. Acest nivel depinde în principal de proiect, de necesarul de resurse în fazele planificate şi evoluţia proiectului până în acel moment. Mai departe, strategia de atragere a investitorilor depinde foarte mult, din nou, de domeniul proiectului, de indicatorii şi riscurile acestuia. Oricum, până la urmă, iniţierea unei colaborări sănătoase cu un investitor nu se poate baza decât pe o propunere de afaceri corectă şi transparentă. Perioada de incubare - Din motive legate atât de partea tehnică, cât şi de partea comercială, noi ţintim o perioadă de incubare de circa 12 – 18 luni de zile. Bineînţeles, pot exista şi excepţii, dar acestea trebuie să fie bine fundamentate. Afilierea la o organizație internaţională - NextPhase este subsidiară a Flogistics AG Elvetia şi dispune de o reţea proprie de consultanţi şi potenţiali investitori. NextPhase nu face parte din nici o reţea notorie de incubatoare de tehnologie. Se pare că acest lucru poate fi un avantaj din punct de vedere a vitezei deciziilor şi a adaptabilităţii la specificul proiectelor. Suportul oferit după ce echipele părăsesc HUB-ul: Prin natura implicării, NextPhase continuă şi îşi adaptează suportul oferit şi după perioada de incubare, practic până la momentul de ieşire (“exit”) din afacere. Suportul şi strategia de ieşire depind de gradul de succes al proiectului şi evoluţia capacităţii de funcţionare autonomă a acestuia. Modul de tarifare pentru co-work - În general, noi ne implicăm doar în proiectele în care credem şi uzual, această implicare se face în schimbul unei participaţii la beneficiile care vor rezulta. Este destul de greu să participi la succesul unui proiect în fază de incubare prin a tarifa în avans consultanţă care este, în general, unul dintre serviciile cele mai scumpe. Astfel, de obicei, noi nu tarifăm implicarea noastră, ci ne asumăm misiunea şi riscurile proiectului, ulterior beneficiind de o parte din succesul financiar al acestuia. Criteriile de acceptare - Principali indicatori care-i folosim în evaluarea proiectelor sunt: caracterul inovativ/diferențiator al conceptului care stă la baza proiectului, potenţialul comercial al ideii şi, foarte important, echipa de inventatori/antreprenori. Ca şi filozofie de acţiune, credem că este nevoie de o idee bună, deo implementare corespunzătoare, dar şi de pasiunea şi anduranţa de a face faţă obstacolelor care, invariabil, sunt prezente de-a lungul proiectului. Activitățile din cadrul incubatorului: - Pe lângă activitatea principală de dezvoltare de proiecte, NextPhase organizează seminarii de prezentare, evenimente de networking, programe de formare pentru echipele de inventatori/antreprenori în dorinţa de a contribui la dezvoltarea comunităţii antreprenoriale clujene. Datele de contact: • nextphase.ro Ovidiu Măţan, PMP

ovidiu.matan@todaysoftmag.com Fondator și CEO al Today Software Magazine

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

startups

TODAY SOFTWARE MAGAZINE

TechHub Bucharest

una mai a început cu veşti bune pentru comunitatea antreprenorilor în tehnologie din România: s-a lansat oficial TechHub Bucharest, primul spaţiu de co-working din România care le este dedicat în exclusivitate şi care face parte din reţeaua internaţională TechHub.

În ultimii ani România a urmat tendinţele din vest, iar fenomenul de co-working a început să capete amploare. În marile oraşe din ţară s-au dezvoltat hub-uri antreprenoriale: locuri în care antreprenori şi freelanceri lucrează împreună. Mai mult decât atât, membrii schimbă idei şi experienţe, utilizează în comun resurse şi îşi împărtăşesc lecţiile învăţate unii altora, ceea ce duce la coagularea unei comunităţi. La asta se adaugă faptul că evenimentele care au loc în spaţiile de co-working sunt relevante pentru comunitate şi îi ajută să îşi dezvolte companiile mai repede şi mai eficient. Beneficiile de a lucra într-un astfel de loc explică gradul ridicat de ocupare al TechHub Bucharest la mai puţin de o lună de la lansare. Antreprenorii aflaţi la început de drum conştientizează că apartenenţa la o comunitate îi ajută să evolueze rapid şi apreciază deschiderea internaţională pe care le-o oferă statutul de membru rezident. De ce TechHub şi cum s-a născut proiectul? TechHub este o comunitate globală dedicată exclusiv antreprenorilor în tehnologie. Conceptul a luat naştere în 2011 la iniţiativa lui Mike Butcher (European Editor TechCrunch) şi Elizabeth Varley. În ultimii doi ani, TechHub a sprijinit inovaţia şi dezvoltarea start-up-urilor în tehnologie în Londra, Riga şi Manchester. Totul a început anul trecut, mai exact pe 5 iunie 2012, cu un simplu articol de blog scris de Bogdan Iordache (Co-Fondator al How to Web, cel mai important eveniment despre antreprenoriat şi tehnologie din Europa de Sud-Est). Echipa How to Web tocmai primise vestea că Bucharest Hub urma să se închidă, aşa că Bogdan şi-a întrebat cititorii, membrii ai comunităţii, dacă au nevoie de un hub. Răspunsurile pozitive au fost numeroase, aşa că Bogdan s-a hotărît să dezvolte în continuare acest proiect. O zi mai târziu, publica o lista de criterii pe care The Next Hub (denumirea iniţială a ceea ce astăzi este Tech Hub) trebuia să le îndeplinească.

A fost nevoie de multă muncă, oameni excepţionali, dedicare şi pasiune, pentru a transforma proiectul The Next Hub în TechHub Bucharest de astăzi. Bogdan Iordache a lucrat alături de Daniel Dragomir şi Ştefan Szakal, Co-Fondatori ai TechHub, iar împreună au făcut lucrurile să se întâmple. Toate astea cu multă determinare şi sprijinul unor oameni care au avut încredere în proiect încă de la început şi au contribuit semnificativ la dezvoltarea lui: Victor Anastasiu, Dan Călugăreanu, Vodafone şi Adobe România. Astăzi, TechHub Bucharest îndeplineşte toate criteriile stabilite iniţial: este în inima Bucureştiului (Str. Nicolae Filipescu nr. 39-41, la 5 minute de mers pe jos de staţia de metrou de la Universitate), are un cost rezonabil şi este un spaţiu deschis în care membrii, mai mult decât acces la un birou şi un spaţiu de co-working, beneficiază de interacţiune de calitate şi pot participa la evenimentele organizate de TechHub şi comunitatea online. Spaţiul de 420mp este împărţit între 35 de birouri permanente pentru membrii rezidenţi, 60 de locuri pentru co-working, săli de întâlnire, şi un spaţiu de evenimente cu o capacitate de până la 150 de persoane. TechHub îşi propune să devină centrul comunităţii antreprenoriale din Bucureşti şi aduce împreună antreprenori, freelanceri, investitori, companii tech, dezvoltatori, bloggeri sau jurnalişti. Pe 9 mai, sala de evenimente a devenit neîncăpătoare pentru membrii comunităţii care au venit din toate colţurile ţării pentru a participa la deschiderea oficială. Evenimentul de lansare a adus împreună reprezentanţi importanţi de pe scena tech românească şi s-a bucurat de prezenţa invitaţilor speciali – Mike Butcher (European Editor TechCrunch) şi James Knight (International Development Manager TechHub). Seara a început cu un mesaj din partea membrilor fondatori, Bogdan Iordache, Daniel Dragomir şi Ştefan Szakal şi a continuat cu un panel dedicat startup-urilor,

panel în care au fost prezenţi Bobby Voicu (Mavenhut), George Lemnaru (Green Horse Games) şi Vladimir Oane (UberVu). Cei trei au povestit traseul parcurs cu propriile start-up-uri şi au subliniat încă o dată importanţa TechHub ca factor agregator pentru start-up-urile tech din România. A venit apoi rândul investitorilor să urce pe scenă. Andrei Pitiş, Marian Duşan şi R adu Georgescu au vorbit despre ce caută un investitor la un start-up, iar Paula Apreutesei (RomanianAmerican Foundation), Cătălina Rusu (Geekcelerator), Mihai Sfinţescu (3TS Capital Partners) şi Dan Lupu (Earlybird) au vorbit despre programele de suport pentru antreprenori şi fondurile de venture capital. S-a discutat ca de obicei şi despre inovaţie cu reprezentanţii celor mai mari centre de cercetare-dezvoltare autohtone: Alex Marinescu (EA Games), Teodor Ceauşu (IXIA) şi Dragoş Georgiţă (Adobe România), iar la final, invitaţii evenimentului au avut ocazia să interacţioneze în cadrul unei petreceri aniversare. TechHub Bucharest pune încă o dată România pe harta globală a inovaţiei şi antreprenoriatului, iar spaţiul din Nicolae Filipescu va deveni foarte curând inima unei comunităţi active la nivel naţional şi va aduce împreună cele mai importante evenimente autohtone dedicate tehnologiei. TechHub Bucharest, engage!

Irina Scarlat

irina.scarlat@howtoweb.co Irina Scarlat este Co-Fondator al Akcees

www.todaysoftmag.ro | nr. 12/Iunie, 2013

startups

Gemini Solutions Foundry Primul incubator de afaceri IT din România cu deschidere către Silicon Valley

n ultima perioadă antreprenorii români au la dispoziție din ce în ce mai multe modalități de a-și facilita dezvoltarea unei afaceri. Fie că vorbim despre fonduri nerambursabile, comunități antreprenoriale sau incubatoare de afaceri, aceste programe sunt un ajutor incontestabil, mai ales în fazele incipiente ale dezvoltării companiei.

Un caz aparte este reprezentat de startup-urile din sfera IT datorită pieței extrem de dinamice ce poate duce fie la o ascensiune rapidă (acompaniată de un număr mare de utilizatori) fie la o pierdere în anonimat. Urmând exemplul Statelor Unite, această categorie de afaceri începe să se bucure de o atenție deosebită și în România, atenție manifestată prin inaugurarea unor hub-uri (cunoscute și sub denumirea de spații de co-work) și incubatoare de afaceri destinate exclusiv mediului IT. Dacă în cazul hub-urilor accentul este pus pe comunitatea creată și pe evenimentele de networking desfășurate, în cazul unui incubator putem vorbi despre o implicare mai mare din partea organizatorilor prin oferirea unui mentorship tehnic și a unor servicii de consultanță financiară și legală. De asemenea și prin crearea conexiunilor cu potențiali clienți, parteneri și investitori. Datorită acestor modalități diferite de abordare într-un hub vom găsi un număr mare de echipe ce plătesc o taxă lunară pe când în cadrul unui incubator, datorită atenției sporite acordate participanților, vom întâlni un număr restrâns de echipe care vând un procent din companie ca modalitate de plată. În curând se va deschide în București Gemini Solutions Foundry – primul incubator destinat exclusiv startup-urilor IT din România ce facilitează crearea conexiunilor între antreprenorii români și investitori din

Silicon Valley. Localizat în Piața Victoriei din București, la doi pași de stația de metrou cu același nume, Gemini Solutions Foundry oferă gratuit echipelor acceptate în programul de incubare spațiu de birouri la cheie cu toate utilitățile necesare și acces la săli de conferințe și de prezentări. Mentorship-ul tehnic este asigurat de persoane cu o bogată experiență tehnică din echipa Gemini Solutions, persoane ce au lucrat pentru companii de diferite dimensiuni de la start-up-uri până la multi-naționale în aproape toate domeniile existente, de la back-end la front-end, de la cloud computing la aplicații destinate pentru mobile. Consultanţă financiară și cea legală oferite au ca scop ușurarea muncii depuse în aceste direcții pentru a permite antreprenorilor să se concentreze la ceea ce contează cu adevărat într-un start-up și anume implementarea ideii. Dar poate cea mai interesantă facilitate este reprezentată de conexiunile cu fonduri de investiții din Silicon Valley. Aceste conexiuni se fac în cadrul unui eveniment anual denumit Demo Day unde echipele vor prezenta atât ideea lor cât și progresul efectuat în cadrul programului de incubare. Acest tip de finanțare este foarte important pentru creșterea ulterioară a echipei deoarece pe lângă banii primiți echipa beneficiază și de conexiunile dar și de îndrumarea

investitorului, altfel spus: echipele beneficiază de smart money. Echipele ce se bucură de interesul investitorilor în urma acestui eveniment vor fi ajutate să își restructureze compania într-o entitate bazată în Statele Unite, să își deschidă un birou în Silicon Valley și să angajeze o echipa de executives. În schimbul serviciilor enumerate mai sus incubatorul preia un procent din companie, procent ce se negociază cu fiecare echipă în parte. Acest lucru scutește echipele de o cheltuială suplimentară în faza incipientă când banii sunt de multe ori o problemă, și în felul acesta prosperitatea startup-ului se reflectă și asupra incubatorului. Acest lucru duce la o aliniere a intereselor ambelor părți. Prin serviciile oferite, Gemini Solutions Foundry vine în sprijinul antreprenorilor din mediul IT din România și îi ajută să își extindă afacerea pe plan internațional, în special pe piața Statelor Unite ale Americii – una dintre cele mai mari, mai dinamice și mai competitive piețe din lume. Cei interesați să participe în acest program sunt invitați să trimită un mail la adresa info@gemsfoundry.com sau să completeze formularul de contact de pe site (http:// gemsfoundry.com).

Radu Popovici radu.popovici@geminisols.ro Software Engineer @ Gemini Solutions

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

startups

TODAY SOFTWARE MAGAZINE

Start Me Up

o altfel de şcoală de antreprenoriat

5 de participanţi foarte bine pregătiţi selectaţi din peste 200 de aplicaţii... un trainer internaţional... 8 antreprenori şi investitori consacraţi din România... 5 noi idei de afaceri... 5 companii responsabile care au oferit burse pentru viitorii antreprenori... 45 de parteneri care au asigurat mediatizarea proiectului şi 176 de apariţii în presa din România. Aşa arată în cifre prima ediţie a şcolii de antreprenoriat Start Me Up care a avut loc anul trecut la Predeal. Pe parcursul evenimentului, participanţii au învăţat care sunt paşii pe care trebuie să îi parcurgă pentru a-şi materializa propriile idei, au realizat planuri de afaceri şi au încheiat prin a-şi valida conceptul de business prezentându-l în faţa unui juriu de specialitate. Fiecare zi a şcolii de antreprenoriat Start Me Up a fost dedicată unui anumit aspect al planului de afaceri. Astfel, participanţii au început printr-un proces de generare şi selecţie de idei, au continuat cu realizarea planului de marketing şi respectiv a planului financiar, şi au pregătit apoi planul de afaceri şi prezentarea propriului proiect. Participanţii au avut ocazia să discute în mod direct cu unii dintre cei mai apreciaţi antreprenori şi investitori români şi să afle poveştile de succes ale acestora. Printre oamenii de excepţie care au fost prezenţi la Start Me Up se numără Peter Barta (Director Executiv Fundaţia PostPrivatizare), Dragoş Anastasiu (Preşedinte Eurolines şi TUI Travel Center), Bogdan Iordache (antreprenor serial, co-fondator How to Web), George Lemnaru (antreprenor serial, co-fondator eRepublika), Bogdan Grosu (fondator Grosu & Asociaţii), Niels Schnecker (om de afaceri, analist economic, colonel în retragere al US Air Force şi om de televiziune), sau Tiberiu Mitrea (antreprenor, fondator NaturaLact). Trainer pe toată durata programului a fost Daniel Ramamoorthy, CFO, director al companiei de investiţii Phoenix Group şi antreprenor serial. În ultima zi a evenimentului, echipele participante au prezentat proiectele dezvoltate pe toată durata programului în faţa unui juriu de specialitate. Echipa

câştigătoare a dezvoltat Boomerang, o companie de consiliere şi orientare profesională pentru elevii de liceu, şi a primit o investiţie iniţială de 2000 de euro pentru implementarea proiectului, alături de înfiinţarea gratuită a afacerii. Un premiu special pentru profesionalism a fost acordat şi cofetăriei Bartello, iar Bogdan Cange şi Vlad Tudose, participanţi Start Me Up, au primit distincţii speciale pentru curaj şi respectiv perseverenţă. „În contextul în care ţara geme de probleme şi toată lumea aşteaptă să li se dea, voi demonstraţi că nu aşteptaţi şi vreţi să faceţi ceva. Văzându-vă pe voi realizez că există o şansă pentru România!”, ne spunea anul trecut Dragoş Anastasiu, Preşedinte Eurolines şi TUI Travel Center. Rezultatele nu au întârziat să apară şi, la un an după eveniment, impactul acestuia este vizibil. Pregătirea participanţilor a continuat prin realizarea de sesiuni lunare de mentorat, sesiuni în care tinerii au avut ocazia să stea de vorbă cu unii dintre cei mai apreciaţi antreprenori şi investitori români. Vlad Tudose, alumni Start Me Up care a primit premiul special al juriului pentru perseverenţă, şi-a schimbat ideea iniţială de business şi a pus bazele unui start-up: Puzzled.by, o platformă online de întrebări şi răspunsuri. Puzzled.by a primit deja o finanţare iniţială de 50.000 EUR de la un grup de investitori americani de tip angel, iar start-up-ul a fost acceptat în competiţia organizată în cadrul conferinţei internaţionale Shift care are loc în Croaţia. Pasionat de antreprenoriat, Sebastian Mărăloiu este un alt alumni Start Me Up cu o poveste remarcabilă. Se pregătea să lanseze versiunea alfa a Bring the Band, platformă care permite publicului să îşi aducă artiştii preferaţi la ei în localitate,

când a identificat alături de partenerul său de afaceri o oportunitate unică: Formspring, o platformă de socializare cu peste 30 de milioane de utilizatori activi nu îşi putea susţine creşterea şi urma să se închidă. Sebi şi partenerul său au lucrat zi şi noapte pentru a profita de această oportunitate şi au reuşit să lanseze două săptămâni mai târziu YouReply, o platformă dezvoltată cu o investiţie iniţială de 50$ care are în prezent peste 14.000 utilizatori. Poveştile de succes pot continua. Fie că îşi dezvoltă în prezent propriile start-upuri sau că acumulează experienţă pentru a deveni în viitor antreprenori, Start Me Up a deschis orizonturi şi a schimbat vieţi. Ca urmare, echipa Akcees se pregăteşte de cea de a doua ediţie a proiectului care va avea loc în perioada 21 – 27 iulie la Pensiunea Speranţa din Predeal. Reţeta succesului este păstrată şi de această dată: un trainer internaţional, antreprenori şi investitori români de succes, participanţi de claitate şi o experienţă care nu ar trebui ratată de nici un tânăr care îşi doreşte să pornească la drum pe cont propriu. Ineditul acestei ediţii constă însă în organizarea unei campanii naţionale de promovare a antreprenoriatului: Caravana Start Me Up. Intre 20 iunie și 4 iulie, echipa Akcees va susţine workshop-uri despre antreprenoriat în 8 oraşe din România şi va aduce în faţa audienţei antreprenori care au reuşit. Pentru Akcees, vara asta stă sub semnul antreprenoriatului! Pentru tineri, este vara în care au şansa de a învăţa cum să-şi transforme visele în realitate!

Irina Scarlat

irina.scarlat@howtoweb.co Irina Scarlat este Co-Fondator al Akcees

www.todaysoftmag.ro | nr. 12/Iunie, 2013

startups

NGO connect

împreună pentru o lume mai bună!

GO CONNECT are în spate o minunată poveste ce a început în seara zilei de 24 mai. 7 tineri antreprenori care nu se cunoşteau între ei, au venit din trei oraşe diferite (Cluj-Napoca, Iași, București) către Tîrgu Mureş. Au călătorit sute de km pentru că ideea de Startup Weekend părea să fie o experienţă grozavă. La sfârşit s-a dovedit a fi una dintre cele mai frumoase experienţe pentru ei, una care nu va fi uitată niciodată, una care poate să le aducă bucurie lor, dar cel mai important altora. Marius Chincișan, cel care a avut ideea iniţială, şi căruia echipa ar dori să îi mulţumească pentru că i-a adus împreună, a luat emoţionat microfonul în mână şi a spus că vrea sa construiască o platformă pentru ONG-uri, unde oricine interesat poate să găsească diverse proiecte sociale şi poate să se implice activ într-o anumită cauză. Acesta a fost începutul NGO CONNECT , iar cuvântul magic care i-a reunit pe cei 7 a fost ONG.

În acea noapte a început maratonul de 54 de ore…cu toţii entuziasmaţi. S-au strâns o mulţime de idei care reflectau viziunea fiecăruia asupra proiectului. După nenumărate ore de brainstorming rezultatul începea să prindă contur: o platformă web care să adune la un loc cele 4 entități: ONG-uri, voluntari, donatori, și companii. În momentul de față muncim la dezvoltarea acestei platforme pentru că noi credem cu tărie că vom putea schimba lumea în bine şi cel mai important, că putem aduce bucurie în vieţile altor oameni. Focusul nostru principal este să aduc e m î n a c el aş i l o c ONG-uri şi oameni care cred în aceleași cauze nobile. Se ştie că e în natura umană să existe îndoială vizavi de orice. Noi înţelegem că oamenii au reţineri în a-şi pune încrederea în ceva sau cineva, cu atât mai mult legat de banii proprii şi de destinaţia acestora. Aici intervine NGO CONNECT. Se vrea eliminarea acestor îndoieli printransparentizarea colectării și cheltuirii fondurilor. Totodată prin intermediul platformei încercăm să ducem implicarea părților la un alt nivel. De exemplu, dacă un proiect vizează ajutarea unei fetiţe cu o situaţie materială precară,în momenul îndeplinirii scopului cauzei sociale, donatorul va primi un video de mulţumire direct de la fetiţa în cauză, eventual şi câteva poze, dar

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

şi date de contact ale cazului. Vrem să CONECTĂM toţi factorii cheie din sfera cazurilor sociale şi anume: ONG-uri, voluntari, donatori şi mai ales corporaţii. De ce corporații? Pentru ca ele au politici și bugete de CSR (Corporate social responsibility).Responsabilitatea socială corporatistăreprezintă o parte integrantă din cadrul oricărei mari companii, prin intermediul căreia se implică activ în rezolvarea problemelor societății în care își desfășoară activitatea. Echipa care se ocupă ca aceste lucruri să fie posibile e formată din tineri cu experiență în diverse domenii: economic, IT, ONG, blogging, etc.. Echipa aceasta a fost pe bună dreptate declarată ca fiind cea mai unită din competiţie. Nu au fost momente în care să se fi separat, sau să îşi fi dorit să renunţe şi mereu au acţionat fairplay. Pe întreg weekendul, nu s-a folosit pronumele “eu”. Toată lumea a avut un singur focus şi anume ca proiectul să fie un succes. Şi a fost. Am luat locul 3, dar noi ne-am simţit la fel de câştigători ca şi cei de pe locul 1. Şi încă ceva…echipa a avut cu adevărat chimie, se vede şi în poza articolului, care îi are pe ei în prim plan. Au început ca străini şi s-au despărţit la sfârşitul weekendului ca nişte prieteni. Concluzia este simplă: scopul platformei este să ajute cât mai mulţi oameni. Pentru că nu este un mit că atunci când oferi, primeşti înapoi dublu. Această echipă a fost adusă împreună de către un singur scop şi sper ca toţi cei care citesc acest articol se vor implica activ în misiunea noastră, aceea de a face lumea mai bună.

Echipa NGO Connect contact@ngo-connect.com

istorie

TODAY SOFTWARE MAGAZINE

Istoria IT-ului Clujean (VI) Istoria IT-ului în numere

m ales pentru acest articol o serie de numere: 1957, 7400, 196/17, 27/100000000. Ele descriu traseul de la înființarea primei instituții ITC până la autoorganizarea comunității actuale într-o breaslă. Pe scurt contextul istoric, evoluția și situația actuală.

1957 înființarea

momentul nașterii ITC la Cluj, anul în care Tiberiu Popoviciu, matematician de renume, fondează Institutul de Calcul cu Departamentul de Calculatoare – prima instituție din domeniul ITC în Cluj. Instituție ce a dat tonul dezvoltării cercetării și educației, baza comunității actuale. 1948 - Emil Petrovici fondează filiala Academiei Române din Cluj 1951 - T. Popoviciu fondează Secția de matematică a filialei Academiei Române 1959 - MARICA - calculator cu relee 1960 - România ocupă locul 11 în lume la dotarea cu calculatoare, Clujul locul 3 în țară 1963 - DACCIC-1 – calculator cu tuburi electronice și tranzistori 1965 - se înființează catedra de Automatică din cadrul Institutului Politehnic (actuala UTCN) în parteneriat cu Institutul de Fizică Atomică din Cluj (devenit ITIM în 1977 și INCDTIM în 1999), sub conducerea lui Marius Hăngănuț 1965 - se înființează departamentul de Știința Calculatoarelor (la UTCN) sub conducerea lui Ioan Dancea 1968 - DACCIC-200 - calculator complet tranzistorizat 1971 - se înființează primul liceu de informatică din Cluj, Liceul de Informatică Tiberiu Popoviciu 1975 - UBB Cluj înființează Centrul de Calcul 1994 - UBB redenumește Facultatea de Matematică cu Facultatea de Matematică și Informatică

7400 absolvenții

în domeniul ITC din 1970 până azi. Ei sunt produsul instituțiilor de mai sus și alcătuiesc o mare parte din generația actuală de profesioniști ITC. Au fost formați în perioada 1970-prezent și reprezintă: 60, 200, 400 - suma mediil or d e a b s o l v e nț i p e r p e r i o a d e l e 1970..1990..2000..2012 86% - din cei 8600 de angajați în ITC la Cluj in peste: 50+ - companii cu mai mult de 50 angajați 2,75% - din 310K locuitori ai Clujului fiind angajați în ITC

27 / 100M+ breasla

este o manifestare naturală de cluster în care 27 dintre companiile ITC din Cluj, având o cifră de afaceri cumulată de peste 100 milioane de euro se organizează în Clusterul IT. Planurile de viitor includ: 300M - Euro investiții pe următorii 15 ani 20K - specialiști IT în Cluj Innovation City

196+ / 17+ comunitatea

a organizat cumulat cca. 200 de evenimente, de la întâlniri la bere, până la evenimente de talie europeană, prin intermediul celor 17+ comunități active de profesioniști. Acestea s-au înființat în anii: 2006 - GeekMeet Cluj 2008 - Transylvania Java User Group 2010 - Cluj.rb, The Cluj Napoca Agile Software Meetup Group, Cluj Semantic WEB Meetup 2011 - Romanian Testing Community, Romanian Association for Better Software, Google Developer Group Cluj-Napoca 2012. Today Software Magazine, Tabăra de testare

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. 12/Iunie, 2013

comunități

Comunităţi IT Cluj-Napoca

una mai a fost plină de eveniment majore, ne pare rău că nu am ajuns la toate dar vă promitem să revenim cu o serie de interviuri și impresii de la acestea în numerele următoare.

Calendar Transylvania Java User Group Comunitate dedicată tehnologiilor Java. Website: http://www.transylvania-jug.org/ Data înfiinţării: 15.05.2008 / Nr. Membri: 539 / Nr. Evenimente: 42 Comunitatea TSM Comunitate construită în jurul revistei Today Software Magazine. Website: www.facebook.com/todaysoftmag Data înfiinţării: 06.02.2012 / Nr. Membri: 652 / Nr. Evenimente: 9 Romanian Testing Community Comunitate dedicata testerilor. Website: http://www.romaniatesting.ro Data înfiinţării: 10.05.2011 / Nr. Membri: 607 / Nr. Evenimente: 2

Iunie 6 Lansarea numărului 12 TSM www.todaysoftmag.ro Iunie 7 Project Managers Meetup www.facebook.com/events/519200844808524 Iunie 12 Linked Data Technology Stack www.meetup.com/Cluj-Semantic-WEB Iunie 12 Functional Programming Retreat it-events.ro/events/functional-programming-retreat

GeekMeet Cluj Comunitate dedicată tehnologiilor web. Website: http://geekmeet.ro/ Data înfiinţării: 10.06.2006 / Nr. Membri: 547 / Nr. Evenimente: 17

Iunie 14 Proiectarea si dezvoltarea unui e-business it-events.ro/events/proiectarea-si-dezvoltarea-unui-e-business

Cluj.rb Comunitate dedicată tehnologiilor Ruby. Website: http://www.meetup.com/cluj-rb/ Data înfiinţării: 25.08.2010 / Nr. Membri: 134 / Nr. Evenimente: 34

Iunie 18 Business Analysis Community Group Meeting it-events.ro/events/business-analysis-community-groupmeeting/

The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software. Website: http://www.agileworks.ro Data înfiinţării: 04.10.2010 / Nr. Membri: 324 / Nr. Evenimente: 29

Iunie 19-20 ITC Spring Europe, Luxemburg (recomandarea TSM) www.ictspring.com

Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice. Website: http://www.meetup.com/Cluj-Semantic-WEB/ Data înfiinţării: 08.05.2010 / Nr. Membri: 140/ Nr. Evenimente: 22 Romanian Association for Better Software Comunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare. Website: http://www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 223/ Nr. Evenimente: 12

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

Joi/săptămânal OpenConnect www.facebook.com/groups/355893314491424/ Miercuri/bilunar OpenCoffee www.facebook.com/opencoffeecluj

programare

TODAY SOFTWARE MAGAZINE

Dezvoltarea de aplicaţii iOS ţinând cont de securitate

ecuritatea a devenit din ce în ce mai importantă în dezvoltarea aplicaţiilor mobile datorită informaţiilor sensibile/confidenţiale de pe telefoanele noastre inteligente. Toate aşteptările şi estimările privind utilizarea sunt depăşite an după an de potopul de utilizatori ai telefoanelor inteligente, în dezavantajul celor care folosesc laptopuri sau desktopuri. Şi cine poate să îi acuze? Dispozitivul ce poate fi ţinut în mână a devenit „portmoneul” erei moderne, plin cu date personale (poze, filme, note) şi date confidenţiale (de sănătate, medicale, jurnale, permise sau cupoane). Cristian Roșa

cristian.rosa@isdc.eu mobile developer @ ISDC

Mai mult, există un trend ce defineşte mobilele prin prisma modului în care sunt conectate afacerile, indiferent de categorie. Informaţii bancare (număr de cont, card de credit, informaţii de autentificare, token-uri de securitate) sunt stocate pe dispozitivele mobile sau sunt trimise prin intermediul reţelelor wireless nesecurizate – aşadar există un risc mai mare decât pentru aplicaţiile de desktop. Este aşadar esenţial ca atunci când sunt dezvoltate aplicaţii mobile să se ţină cont de securitate, din cauza multitudinii de atacuri ce pot produce prejudicii semnificative.

face dispozitivul aproape impenetrabil.

Sandbox-ul Aplicaţiilor

iOS „îngrădeşte” fiecare aplicaţie în propriul sandbox la momentul instalării, fapt ce limitează accesul la fişiere, resurse de reţea, hardware şi date private. Calea către directorul home al aplicaţiei are forma ../ApplicationRoot/ApplicationID

Arhitectura Apple

Apple a reuşit să găsească, până acum, cel mai bun echilibru între uzabilitate şi securitate prin arhitectura sa ce este strâns legată de hardware şi software. Acest lucru face ca în acelaşi timp să fie uşor pentru clienţi să cripteze date pe dispozitivele proprii şi pentru hackeri să fie greu să fure şi să decripteze informaţii confidenţiale. Piatra de temelie a securităţii Apple este algoritmul Advanced Encryption Standard (sau AES), un sistem de codare a datelor considerat de „ne-spart”. Implementarea acestuia pe dispozitivele Apple se face prin intermediul unei chei de criptare stocată adânc în memoria flash, ea însăşi criptată prin intermediul unei parole de utilizator. Setarea unei „ştergeri de date” după 12 încercări eşuate de introducere a parolei

Chiar dacă sandbox-ul limitează pagubele pe care un potenţial atac le-ar putea produce, iOS-ul nu îl poate preveni. Aceasta înseamnă că un hacker poate să acceseze informaţii confidenţiale din cadrul sandbox-ului, lăsând dezvoltatorului doar opţiunea de a lua contramăsuri suplimentare de securitate.

www.todaysoftmag.ro | nr. 12/Iunie, 2013

programare Dezvoltarea de aplicaţii iOS ţinând cont de securitate Criptează datele cât timp dispozitivul este blocat

de licenţă, numere de cont, etc. . Pentru a folosi „Keychain Services”, binarul aplicaţiei trebuie să fie legat cu arhitectura Security.framework. Spre deosebire de alte arhitecturi iOS, aceasta este o arhitectură C aşa că toate tipurile de apeluri de metode sunt în acel limbaj. În acelaşi mod în care criptarea datelor cât timp dispozitivul este blocat are niveluri de protecţie, la fel şi protecţia datelor din keychain: întotdeauna protejat, protejat AfterFirstUnlock sau WhenUnlocked. De asemenea, fiecare clasă există în variaţii migrabile şi non-migrabile – sufixul ThisDeviceOnly ce leagă criptarea de un dispozitiv anume. Cea mai bună abordare în folosirea Keychain Access este să declaraţi un dicţionar de căutări de bază folosit pentru toate apelurile către serviciile keychain. Acesta va conţine atribute ale itemului keychain de creat, găsit, actualizat sau şters.

Cât timp dispozitivul este blocat, anumite fişiere marcate de către dezvoltator pot să fie criptate în mod automat, însă acest lucru presupune permiterea capacităţilor de criptare şi configurarea lor. În stadiul blocat, sandbox-ul aplicaţiei împiedică accesul altor aplicaţii; mai mult, chiar şi aplicaţia propriu-zisă nu are acces. Criptarea se realizează prin setarea nivelului dorit de protecţie: fără protecţie, complet, complet cu excepţia faptului când e deja lansată şi complet până la prima logare. API-uri ce oferă Protec ţia Datelor sunt NSData ce folosesc writeToFile:options:error ; NSFileManager pentru setarea atributelor fişierelor cu setAttributes:ofI temAtPath:error; schimbarea valorii NSFileProtectionKey şi opţiunea sqlite3_ open_v2 pentru sqlite3. După setarea protecţiei fişierului, aplicaţia trebuie să implementeze nişte delegaţi Cache-ul tastaturii pentru a fi pregătită pentru pierderea temAţi observat vreodată că atunci când porară a accesului la acel fişier. folosiţi browsere, auto-complete-ul îşi intră în rol atunci când încercaţi să retastaţi Protecţia datelor cu Keychain Access ceva? Aţi observat că la fel se întâmplă şi „Keychain Services” este o interfaţă cu iPhone-urile? Dacă nu încă, ar trebui programabilă ce vă permite să găsiţi, adă- să ştiţi că toate tastările de pe un iPhone ugaţi, modificaţi şi să ştergeţi item-uri din ar putea fi salvate în cache dacă nu se iau keychain. Keychain este singurul loc în care măsuri pentru dezactivare. Acest lucru este puteţi stoca date în siguranţă, deoarece valabil pentru tot ceea ce tastaţi, cu excepsunt criptate în propriul lor set de item- ţia câmpurilor de parolă. uri ai aplicaţiei. Acestor item-uri\ le este Vestea proastă este că aproape orice creată o copie de siguranţă atunci când cuvând non-numeric este salvat în cache şi utilizatorul îşi sincronizează dispozitivele conţinutul cache al tastaturii depăşeşte priprin intermediul iTunes şi vor fi păstraţi şi vilegiile administrative ale aplicaţiei, adică în cazul unei reinstalări. Toate acestea fac nu pot fi îndepărtate din aplicaţie. din keychain principalul loc de depozitare a Acest lucru lasă dezvoltatorului o sindatelor confidenţiale, cum ar fi parole, chei gură opţiune, şi anume să dezactiveze

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

caracteristicile de auto-corectură setând proprietatea de autocorrectionType la UITextAutocorrectionNo.

Capturi de ecran automate

Pentru a oferi o experienţă bogată utilizatorului, iOS are multe efecte de micşorare, împingere, apariţie sau dispariţie. Totuşi, acestea au şi o latură negativă: atunci când aplicaţia este mutată în fundal, iOS face o captură automată de ecran a ferestrei iPhone-ului în timp ce efectuează efectul de micşorare şi dispariţie. Toate aceste capturi de ecran sunt stocate în partea de sistem NANS flash a dispozitivului şi sunt teoretic şterse după ce aplicaţia a fost închisă. În cele mai multe cazuri, ştergerea nu îndepărtează fişierele permanent de pe dispozitiv. Acestea pot conţine date privind utilizatorul şi aplicaţia. Ca o posibilă soluţie pentru această problemă, este nevoie de blocarea cache-ului capturilor de ecran ale aplicaţiei folosind un cod sau o configuraţie API. Un mod uşor de a face acest lucru este folosirea metodei API willEnterBackground, în care se poate implementa ştergerea informaţiilor confidenţiale. Apoi puteţi crea un ecran animat pe care aplicaţia să îl afişeze în timp ce se mută în fundal.

Punerea în cache a datelor aplicaţiei

Datele aplicaţiei pot fi capturate într-o varietate de artefacte, cum ar fi fişiere de log/debug, cookies, fişiere listă de proprietăţi sau baze de date SQLite. În timp ce fişierele listă de proprietăţi, bazele de date SQLite şi fişierele/documentele comune pot fi criptate oferind astfel un nivel de siguranţă, fişierele de log, debug sau crash sunt potenţial accesibile.

TODAY SOFTWARE MAGAZINE Dacă aplicaţia se blochează, rezultatul este logat, lăsând atacatorului o potenţială soluţie pentru a sustrage date confidenţiale. Luaţi de asemenea în considerare dezactivarea NSAssert pentru iOS pentru că aplicaţia se va bloca imediat după o avarie; un mod elegant de rezolvare a problemei este interceptarea şi prelucrarea acestor erori. Ar trebui de asemenea să dezactivaţi logurile înainte de a publica aplicaţia; acestea pot să stocheze date confidenţiale. Dezactivarea acestora pot să prevină scurgerea de informaţii confidenţiale şi de asemenea se poate vedea o mică creştere în performanţă.

PasteBoards

Clasa UIPasteboard permite unei aplicaţii să împărtăşească date în cadrul aplicaţiei sau cu altă aplicaţie folosind pasteboards la nivel de sistem sau specifice pentru aplicaţie. Sună cunoscut? Uitaţi-vă

la imaginea de mai jos. Sunt sigur că aţi văzut asta în multe aplicaţii iOS. Atunci când utilizatorul cere o operaţiune de copiere sau tăiere pe o bucată selectată din interfaţa utilizatorului, un obiect scrie datele pe un pasteboard. Dacă nu este setat un nivel adecvat de securitate, alte aplicaţii pot avea acces la datele salvate anterior creând astfel riscuri mari de securitate. De asemenea, persistenţa acelor date trebuie controlată, deoarece, dacă atributele nu sunt setate în mod corect, informaţia copiată va fi stocată necriptată în sistemul de fişiere al telefonului şi va fi menţinută chiar şi după închiderea aplicaţiei. Ca o ultimă remarcă, să ţineţi minte că practicile de securitate doar îngreunează viaţa hackerilor. Nu se poate să vă asiguraţi în proporţie de 100% că măsurile dumneavoastră nu vor putea fi ocolite. La urma urmei, toate versiunile de iOS au fost sparte/decodate. Deşi devine din ce în ce mai greu pentru hackeri, ar trebui să vă pregătiţi pentru situaţii neprevăzute. La urma urmei, trebuie să găsiţi proporţia adecvată între uzabilitate şi practici de intimidare ce vi se potrivesc cel mai bine dumneavoastră,

clientului şi utilizatorilor dumneavoastră. Mulţumiri speciale lui Mircea Botez și lui Andrei Adiaconitei.

Bibliografie 1. Apple iOS Developer Library 2. “Top 10 iPhone Security Tips” de Kunjan Shah 3. “Penetration Testing for iPhone / iPad Applications” de Kunjan Shah 4. “iOS Keychain Weakness FAQ” de Jens Heider, Rachid El Khayari 5. “Lost iPhone? Lost passwords!” de Jens Heider, Matthias Boll 6. https://www.viaforensics.com 7. http://www.useyourloaf.com 8. http://www.technologyreview.com

www.todaysoftmag.ro | nr. 12/Iunie, 2013

conferință

JQuery Europe 2013

n web developer, Haymo Meran și fantoma prințului Johann Adam Andreas von Liechtenstein intră într-un palat… Sună ca începutul unei glume ciudate, dar vă garantez că nimeni n-o să știe ce se întâmplă mai departe. Mai bine zis, nimeni care nu a auzit de sau nu a participat la jQuery Europe 2013. Ca să fiu sincer, n-am văzut nici un semn că duhul prințului ni s-ar fi alăturat, și am fost 300 de developeri (sau mai bine zis, entuziaști jQuery), nu unul. Restul totuși e chiar foarte adevărat și cu siguranță nu o glumă, pe cât de fabulos sună. Andrei Otta

andrei.otta@accesa.eu Software developer @ Accesa

Într-adevăr, a fost o conferință jQuery care a avut loc într-un veritabil palat, palatul Liechtenstein (sau Gartenpalais pentru localnici) din Viena ca să fiu mai exact, și ce eveniment excepțional a fost… Pe aceasta cale țin să mulțumesc organizatorilor, Gentics Software, și în special domnului Haymo Meran (CTO-ul Gentics și o foarte prietenoasă gazdă) pentru că au făcut posibil acest eveniment și s-au descurcat destul de bine în “voiajul inaugural”. Probabil singurul “minus” (amuzant) care merită menționat e afirmația că participanții care ajung la stația de metrou „Rossauer Lände” vor fi ghidați către locația evenimentului de către o persoană purtând un tricou personalizat pentru conferință. De ce ar fi asta amuzant, mă întrebaţi? Aceasta este Viena în prima zi a conferinței: Nu tocmai cea mai potrivită vreme

de umblat în tricou și dus lumea la conferințe… Dar destul cu deraiatu, să trecem la detaliile picante propriu-zise! Conferința s-a întins pe durata a două zile, din 22 până în 23 februarie, și a fost plină ochi de Javascript, jQuery, CSS și alte bunătăți livrate de cei 16 vorbitori, presărate ici și colo cu părticele mai ciudate cum ar fi banane care cântă și coctail-uri tropicale. Evenimentul a început cu o bombă! Stați calmi, nu a fost nici un fel de atentat, securitatea a fost foarte strictă, cu câteva sosii ale lui James Bond mereu cu ochii pe mulțime după cum puteți vedea mai jos…

Nu, bomba la care mă refer descrie impactul primei sesiuni, al cărei vorbitor a fost nimeni altul decât Richard D. Worth, directorul executiv al fundației jQuery. Dl. Worth a prezentat starea curentă a jQuery,

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE acum la versiunea (stabilă) 1.9.1, și a oferit o mică viziune asupra viitorului, invitând participanții să se alăture comunității jQuery. Participanții au fost apoi “incitați” cu bucățele de informație despre următorul mare pas pentru jQuery, versiunea 2.0, dintre care de departe cel mai ovaționat (aclamat și aplaudat furtunos) a fost anunțul că, începând cu versiunea 2.0, jQuery nu va mai suporta Internet Explorer 8 (sau versiuni mai vechi). Știu, știu, jos pălăria în fața lor pentru că au închis ușa și-au încuiat-o bine și l-au lăsat în stradă pe țâncul cel enervant care mereu face lucrurile altfel decât restul… Totuși, nefiind oameni cruzi și fără milă pentru bietele suflete care au nevoie ca site-ul lor să nu crape oribil pe IE, echipa jQuery va menține versiunea 1.9.1 în paralel cu 2.0, duplicând în 1.9.1 tot ce se va dezvolta în 2.0 și mai departe, atâta timp cât nu necesită cantități industriale de adaptare. Dl. Worth a trecut de asemenea în revistă modificările recente în componente adiacente jQuery cum ar fi jQueryUI sau jQuery Mobile și a adus la lumină câteva inițiative jQuery, precum contribute. jquery.org (pentru cei interesați în a contribui la jQuery), plugins.jquery.com (noul și îmbunătățitul registru de plugin-uri) sau learn.jquery.com (dacă URL-ul nu v-a dat un indiciu, aceasta e o inițiativă îndreptată către persoanele care vor să învețe jQuery). Considerând că a intra în toate detaliile a ceea ce a urmat ar însemna transformarea acestui articol într-o lectură destul de grea, voi face un rezumat (și probabil o să dau greș, într-un final slobozind zăgazurile mentale și dând drumul șuvoiului de gânduri) al restului unei zile cu adevărat fascinante. Următorul pe listă a fost Corey Frang, de asemenea un membru al echipei

jQuery, care a disecat un widget jQuery UI în componentele lui de bază și a demonstrat cum folosirea “widget factory”-ului poate genera rezultate foarte flexibile și extensibile. Doug Neiner a prezentat cateva practici bune în ceea ce privește separarea codului Javascript/jQuery de CSS și HTML, lucru care ne va aduce mult mai multă mentenabilitate și mai puține dureri de cap. A facut de asemenea și o incursiune în lumea tranzițiilor și animațiilor CSS și a echivalentului lor în jQuery. Sebastian Kurfürst a arătat cum, folosind RequireJS, ne putem organiza codul Javascript în componente și să îmbunătățim claritatea în codul de client. Jörn Zaeffer ne-a deschis urechile și mințile către modul în care web-ul e perceput de cei care nu pot experimenta lumea prin intermediul văzului, o categorie semnificativă de oameni de care din nefericire uităm deseori. Trebuie să recunosc că mi-a dat un sentiment de umilință, tristețe chiar, să aflu cum “sună” unele pagini web. N-am fost pus încă într-o situație în care a trebuit să mă gândesc la accesibilitate și e greu să ai aspectul acesta în minte când ești în frenezia alinierii de pixeli și a ajustării tonurilor de culoare, dar e ceva ce ar trebui luat mereu în considerare. Am văzut apoi de ce e în stare jQuery pe server într-o prezentare foarte pătrunzătoare de către Golo Roden a Node.js, o unealtă excepțional de puternică pentru oricine e interesat de lucruri precum “web scraping”, crearea de web servere “ușoare” sau aplicații distribuite cu trafic intens de date. Următorul vorbitor în acțiune, Sascha Wolter, e probabil persoana cea mai asemănătoare cu un geniu nebun pe care am văzut-o până acum, dar în modul cel mai bun. A făcut lucruri cu Javascript la care nu m-aș gândi

nici în cele mai creative zile. De la controlat roboți LEGO sau “quad copters” și trimis SMS-uri la aparate de făcut cafea până la a chiar face banane să cânte, am savurat fiecare fascinantă secundă (să nu mai vorbim că am copt câteva idei nebune proprii de încercat). Ziua s-a încheiat cu prezentarea ținută de Christian Heilmann, care a lansat o întrebare foarte interesantă: oare uneltele (librării Javascript, frameworkuri, plugin-uri, etc.) pe care le folosim ne ajută sau ne fac rău? E bine să folosim unelte ca să facem procesul de dezvoltare mai rapid sau să dăm mai multă claritate codului, dar e esențial să înțelegem ce e de fapt în spatele acestor unelte, ce le face să funcționeze, ce le face atâta de bune și ce le-ar putea face și mai bune. Îmi aduc aminte de câteva cifre menționate de dl. Worth în prezentarea de deschidere: 55.7% din site-urile existente în momentul de față pe vastele câmpii ale internetului folosesc jQuery. Aceasta înseamnă 90.7% din toate site-urile care folosesc Javascript. O majoritate copleșitoare fără îndoială, dar stau să mă întreb oare câți developeri care au folosit jQuery în acele site-uri au chiar luat o versiune ne-minificată a js-ului de jQuery și au tras cu ochiul înăuntru să vadă ce soi de magiee în spatele framework-ului care le face viața așa de ușoară... Și-așa am ajuns la a doua (și din păcate ultima) zi de jQuery Europe 2013. Ziua a început cu o prezentare grozavă pe tema “jQuery Mobile și Responsive Web Design” de Todd Parker, design lead al jQuery UI și membru al echipei jQuery Mobile.Dl. Parker a descris capabilitățile de RWD (Responsive Web Design) incluse în framework-ul jQuery Mobile și a arătat câteva exemple reale de utilizare a media

www.todaysoftmag.ro | nr. 12/Iunie, 2013

conferință JQuery Europe 2013 fost prezentat a fost foarte impresionant din punct de vedere vizual și fără îndoială de ultimă oră. Toate uneltele moderne de “încântat ochiul”, cum ar fi CSS3, SVG, Canvas sau WebGL și-au primit o porție sănătoasă de atenție iar framework-uri precum Raphael.js, D3.js sau Fabric.js, care aduc puterea acestor tehnologii într-un format mai accesibil ne-au delectat și ele cu etalări creative și uimitoare privirea. Și apoi a trebuit să plec... Și deși am avut o mică doză de regret pentru că am ratat o părticică, am fost extrem de satisfăcut de ce am putut experimenta pe parcursul celor două zile... Și am plecat chicotind puțin la gândul că mă voi întoarce pentru conferința de anul viitor, care garantat va avea loc, după spusele lui Haymo. Cine știe ce va aduce 2014? query-urilor și a gândirii “mobile-first” în construirea conținutului responsiv, fie el pentru site-uri sau app-uri. De asemenea au fost evidențiate câteva tehnici de îmbunătățire a performanței în ceea ce privește minimizarea utilizării lățimii de bandă, utilizarea imaginilor cu rezoluții mari și stratificarea selectivă a conținutului în funcție de capabilitățile dispozitivului. Maximilian Knor, un “developer evangelist” la Microsoft, a demonstrat cum ASP.NET MVC și ASP.NET SignalR (http://www. asp.net/signalr încercați-l daca n-ați făcuto deja) construiesc peste jQuery și jQuery Mobile pentru funcționalități client-side și aplicații de o singură pagină. Mike West a evidențiat esențialul securizării codului de client împotriva intențiilor malițioase, fie ele “cross-site scripting” sau alte forme de atac. Mai bine zis, a diminuării efectelor unui asemenea atac ca sa fiu sincer, pentru că deși am crede că am scris codul

în așa fel încât e imposibil ca altcineva să îl spargă, lucruri precum JSFuck(http:// www.jsfuck.com/) s-ar putea sa ne facă să ne întoarcem la codul nostru și să mai adăugăm câteva straturi pe “zidul de cărămidă” și chiar și atunci să ne dăm seama că nu e destul de solid. Reținem prezentarea lui Patrick Lauke și “Web on TV”, o descriere a modului în care jQuery poate fi folosit pentru a interacționa cu televizorul dumneavoastră. În ziua de azi, orice companie respectabilă care produce televizoare probabil are cel puțin un reprezentant al generației SmartTV și în câțiva ani probabil cu greu ne vom aduce aminte de vremea când nu puteai să navighezi pe internet pe televizorul tău sau să te uiți la YouTube sau să joci Angry Birds. Ce înseamnă asta, pe lângă un set nou de bătăi de cap în ceea ce privește suport inclus în site-uri sau app-uri pentru multiple dispozitive, e că folosind puțină cunoștință de Javascript/ jQuery am putea crea interfețe sau app-uri de care oamenii să se bucure (și) pe televizoarele lor (îmi vine în minte o mică glumă despre a pune “peretele” de Facebook al unei persoane pe chiar peretele persoanei respective). Ultima prezentare la care am putut să particip a fost un fel de iluminare dublă, grație lui Dyo Synodinos. Primul pas al iluminării a fost în legătură cu picturile de pe tavanul măreței și magistral decoratei săli în care ne aflam, care surprind scene din viața lui Hercule (nu cel jucat de Kevin Sorbo). Al doilea pas a avut loc în momentul în care mi-am dat seama că primul avea chiar multă legătură cu prezentarea despre “ultimul răcnet” în materie de vizualizări ce urma și nu era nici pe departe umplutură de introducere. Într-adevăr, ceea ce a

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

Managementul performanței (II)

doua parte a articolului dedicat managementului performanței va prezenta mijloacele utilizate în acest proces, precum și câteva modele care pot fi ușor implementate în orice companie.În cele ce urmează va fi definit un model de definire al obiectivelor în cele trei faze ale procesului de management al performanței, care cuprinde: (1) definirea comportamentelor necesare pentru trăirea celor cinci valori ale companiei, (2) obiectivele echipei: descrierea acestora, modalitatea de măsurare a obiectivelor și rezultatele așteptate și (3) obiectivele individuale, care trebuie să fie aliniate cu obiectivele echipei.

În cadrul fiecărui departament este indicat să existe un nivel general al perfomanței stabilit pe baza rezultatelor obținute în anii anteriori. De asemenea este indicat ca în fiecare lună să se întocmească rapoarte pentru definirea nivelului de perfomanță în cadrul echipelor. Perfomanțele individuale se evaluează la mijlocul perioadei de evaluare în principiu la mijlocul anului și la finalul perioadei de evaluare la finalul lunii decembrie. Rezultatele sunt utilizate ulterior pentru întocmirea planurilor de dezvoltare personală, care cuprind obiectivele de dezvoltare, activitățile care contribuie la îndeplinirea obiectivelor și competența îmbunătățită. Activitățile de dezvoltare sunt dintre cele mai diverse: de la programe de pregătire pentru angajați, la training la locul de muncă, materiale electronice.

• Obiectivele trebuie să fie SMART, obiectivelor. iar indicatorii de performanță vor fi 1. Rezultatele: sunt produse finite, definiți pentru fiecare obiectiv și valoare servicii, informații care sunt ofea organizației în parte. rite clienților. Rolul lor este de a • Managerul este responsabil penîndeplini așteptările și cerințele acestora. tru alinierea obiectivelor cu cele Rezultatele eficiente trebuie să: organizaționale. • se refere la obiectivele cheie ale afacerii și/sau prioritățile funcționale Indicatorii de perfomanță cheie, Este necesar a fi definiți indicatori de • fie formulate din perspectiva perfomanță pe fiecare arie. Aceștia sunt clientului, folosiți pentru definirea obiectivelor de • fie formulate ca stare finală, echipă. Formularea obiectivelor trebuie să • includă obiective manageriale și fie un proces orientat spre clienți și pe facde leadership, torii interesați și trebuie să ia în considerare • includă auto-dezvoltarea, indifetrei aspecte esențiale: rezultatele, cerințele rent de rol. de calitate și indicatorii de performanță. Pentru o mai bună înțelegere a aces2. Cerințele de calitate: descriu rezultui model, în continuare vor fi explicate tatul oferit ca și când acesta ar fi excelent toate cele 3 aspecte și rolul lor în definirea din perspectiva clientului și trebuie să

Scara de notare a performanței

Realizările sunt evaluate pe o scară a performanței cu 6 niveluri, așa cum se poate observa în tabelul 1.2. Evaluarea se face cu ajutorul a două dimensiuni: rezultatele obținute (CE?) și aplicabilitatea valorilor companiei (CUM?).

Definirea obiectivelor

Obiectivele profesionale pe termen lung şi termen scurt să fie integrate în prima fază a procesului (Definirea așteptărilor) având feedback constant din partea managerului. Criterii pentru definirea obiectivelor: • Obiectivele individuale vor fi în corelație cu obiectivele echipei. Minimum un obiectiv al echipei și minimum trei obiective individuale.

Figura 1 de definire a obiectivelor în interiorul companiei

www.todaysoftmag.ro | nr. 12/Iunie, 2013

HR Managementul performanței (II) conțină caracteristici ale valorii adăuactivează și poate indentifica în același gate pentru a descrie CE-ul și CUM-ul timp viitoare tentințe ale mediul extern performanței. și intern. 3. Indicatorii: au rolul de a spune dacă și cum fiecare echipă/individ a perforPe lângă aceste competențe de leamat față de obiectivul stabilit, cu privire dership, persoanele care au poziții de la CE-ul și CUM-ul performanței. Mai management au un profil pe care trebuie să mult decât atît indicatorii trebuie să fie îl îndeplinească. agreați anterior stabilirii obiectivelor.

Competențe de leadership și management

Pentru un proces sustenabil de managementul performanței, este recomandabilă crearea unui catalog al competențelor și abilităților tehnice pe care fiecare angajat trebuie să le aibă pentru a îndeplini responsabilitățile postului. Competențele de leadership pe care le sugerez a fi folosite sunt cele enumerate mai jos. Se va păstra și denumirea în limba engleză pentru a nu schimba semnificația cuvintelor. • Orientarea către oameni (People leadership) care pune accentul pe capacitatea individului de a comunica, de a-i coordona pe ceilalți și de a lucra la rândul său într-o echipă. • Leadership personal (Personal leadership) capacitatea de a se adapta la situații și medii noi și nu în ultimul rând inteligența emoțională. • Orientarea spre rezultate (Results Leadership) exemplifică capacitatea angajatului de a-și îndeplini obiectivele și sarcinile, precum și capacitatea acestuia de a lua o decizie responsabilă în timp util. • L eadership analitic (Thought Leadership) capacitatea de a înțelege mediul de business și organizația în care

Campionii managementului performanței

Companiile oferă angajaților posibilitatea de a beneficia de ajutorul campionilor managementului performanței, care sunt grupați în două categorii: (1) cei care au cunoștințe despre managementul performanței care pot oferi suport celor care sunt implicați în acest proces și (2) persoanele cu performanțe ridicate care sunt promovate în cadrul companiei în cadrul diferitelor evenimente de recunoaștere a meritelor. Rolul acestora este de a: • identifica, selecta și motiva un grup de agenți ai schimbării care să contribuie la implementarea procesului în interiorul companiei; • educarea echipelor și a indivizilor pentru a-i familiariza cu aplicațiile strategice ale managementului perfomanței; Modelul FLAME poate fi aplicat în orice companie. Pentru o viziune mai clară asupra rolului campionilor managementului performanței, se vor exemplifica situații caracteristice acestui model, unde F – facilitarea, L – leaderi prin exemplu, A – acționează ca o consecință, M – măsoară, E – educă. Cheia reușitei este de a educa și de a le insufla celorlalți membri ai echipei

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

o cultură a performanței, iar aceștia să devină acei agenți ai schimbării în interiorul companiei. Problema care este adesea adusă în discuție se referă la procesul de identificare și de alegere a campionilor managementului performanței. Principalele caracteristici pe care aceștia trebuie să le aibă sunt: • înțelegerea procesului de management al performanței și impactul acestuia în companie; • competență în diverse aspecte (capacitate de înțelegere a sistemului de notare a performanței, capacitate de a organiza întâlniri, capacitate de influențare); • buni performeri; • buni comunicatori și facilitatori. Procesul de management al p e r f or m a nț e i a re t re i c on s e c i nț e semnificative: 1. Recompensarea angajaților, 2. Managementul talentului, adică dezvoltarea carierei tuturor angajaților, 3. Planul individual de dezvoltare, pe care angajații, împreună cu superiorul direct ar trebui să îl realizeze. Succes în implementarea unui sistem de managementul performanței care să aducă cele mai bune rezultate atât pentru angajați cât și pentru companie.

Andreea Pârvu

andreea.parvu@endava.com Recruiter în cadrul Endava

TODAY SOFTWARE MAGAZINE

Cum se măsoară?

Revizuirea intermediară a obiectivelor Descrierea obiectivului Cum se măsoară? Rezultate Scor (an anterior) Nivelul performanței (an anterior) Descrierea obiectivului Cum se măsoară? Rezultate Scor ( an anterior ) Nivelul performanței ( an anterior ) Cum se măsoară?

Nivelul General al Perfomanței

Scorul nu este disponibil

Rezultate Nivelul Performanței Scorul este opțional

Scorul Total al Evaluării ( an anterior )

Scor total

Plan de Dezvoltare Profesională

Obiective de Dezvoltare Activități de dezvoltare

Obiective echipă (cel puțin una dintre subsecțiuni trebuie completată) Obiective Individuale

Definirea așteptărilor Descrierea obiectivului Cum se măsoară?

Descrierea obiectivului Cum se măsoară?

(cel puțin una dintre subsecțiuni trebuie completată) Valorile companiei

(cel puțin un plan trebuie completat)

Evaluarea perfomanței Descrierea obiectivului Cum se măsoară? Rezultate Scor (an anterior) Nivelul performanței (an anterior) Descrierea obiectivului Cum se măsoară? Rezultate Scor ( an anterior ) Nivelul performanței ( an anterior) Cum se măsoară?

(100% pentru validare ) Obiective de Dezvoltare Activități de dezvoltare Competența dezvoltată Competența dezvoltată în urma în urma activității de activității de dezvoltare dezvoltare

Obiective de Dezvoltare Activități de dezvoltare Competența dezvoltată în urma activității de dezvoltare Rezultatul planului de dezvoltare

Tabel 1.1. Model formular stabilire obiectivelor

Nivel Denumire nivel

Descrierea nivelului din punct de vedere al rezultatului

Descrierea nivelului din punct de vedere al valorilor

Excepțional

Performanța obținută a fost peste obiectivele definite, prin propriile abilități. Depăsește constant așteptările angajațiilor pe această poziție. Excelează în a îndeplini cerințele clienților în termenul limită stabilit.

Este un model pentru ceilalți în ceea ce privește trăirea comportamentelor caracteristice fiecărei valori.

Obiectiv depășit

Perfomanța obținută a fost peste obiectivele definite, cu un minim de supervizare, demonstrând în același timp inițiativă și independență în soluționarea problemelor.

Demonstrează constant trăirea comportamentelor fiecărei valori.

Obiectiv îndeplinit

Performanța obținută îndeplinește obiectivele definite, cu suport din partea superiorului direct.

Demonstrează efectiv trăirea comportamentelor caracteristice fiecărei valori.

Obiectiv îndeplinit parțial

Performanța obținută îndeplinește parțial obiectivele, ne fiind Unele comportamente demonstrate nu sunt în îndeplinite în termenul limită stabilit. Este nevoie de suportul concordanță cu valorile. superiorului direct și de îmbunătățirea competențelor și a abilităților.

Obiectiv neîndeplinit

Performanța obținută este sub obiectivele definite. Este nevoie de suportul constant al superiorului direct pentru îndeplinirea responsabilităților postului.

Nemăsurabil

Angajați noi în cadrul companiei (mai puțin de 6 luni).

Majoritatea comportamentelor demonstrate nu sunt în concordanță cu valorile.

Tabel 1.2. Scara de notare a performanței

Obiectivul: ______________________________________________________________ Numele echipei/ membrului individual ________________________________________ Rezultat

Cerințe de calitate

Indicatori

Tabel 1.3. Modelul de definire al obiectivelor www.todaysoftmag.ro | nr. 12/Iunie, 2013

programare

Din uneltele artizanului software: Unit Testing

maginați-vă următoarea situație: o echipă a dezvoltat timp de 6 luni un produs grozav, care se vinde imediat. Utilizatorii își arată pasiunea pentru produs cerând mereu funcționalități noi. Dacă echipa nu livrează noile funcționalități destul de repede, fericirea lor va scădea, poate chiar vor decide să migreze la concurență. Echipa trebuie să livreze rapid. Alexandru Bolboaca

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

Adrian Bolboaca

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

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

Din păcate, validarea completă a produsului de către echipa de testare poate dura săptămâni, dacă nu luni. Și asta fără a lua în calcul timpul necesar rezolvării bugurilor găsite de testeri. Nu se poate așadar ca echipa să livreze la timp dacă produsul este complet testat. Ce e de făcut? Alternativele cele mai comune sunt: • testarea exclusivă a funcționalităților noi, cu speranța că cele vechi nu s-au modificat; • analiza impactului modificărilor și testarea exclusivă a funcționalităților afectate; • utilizatorii vor testa într-o perioadă de stabilizare. Toate soluțiile de mai sus înseamnă scăderea temporară a grijii acordate produsului, pentru a asigura livrarea cât mai rapidă. Din păcate pentru echipa din scenariul descris mai sus, se asumă riscuri care pot avea impact major asupra afacerii. Riscul major este scăparea din vedere a unor zone din aplicație și livrarea cu buguri. Acest risc poate duce la: • Scăderea mulțumirii utilizatorilor și la apariția detractorilor. În afaceri, la fel ca în viață, e greu să câștigi încrederea unei persoane dar e foarte ușor să o pierzi. • C r e ș t e r e a c o s t u r i l o r c u suportul. Fiecare bug raportat de utilizator înseamnă timp petrecut pentru înțelegerea lui, rezolvarea, testarea și punerea în producție a noii versiuni. Costurile se acumulează în: call center, dezvoltare, testare, operațional.

• Costul de oportunitate: cât timp echipa de dezvoltare rezolvă bug-uri, competiția poate scoate funcționalități noi care vor atrage utilizatorii. Rezolvarea bug-urilor este echivalentă din punctul de vedere al afacerii cu alergatul pe loc.

Dar dacă...

Echipa ar putea valida întreaga aplicație în ore și nu în săptămâni sau luni? Dacă fiecare programator ar putea afla la fiecare mică modificare în cod, în câteva minute, că nu a stricat nimic (cu o probabilitate de 80+%) Articolul despre Software Craftsmanship, publicat în numărul 11 al Today Software Magazine, menționează ideea principală de la care a pornit mișcarea: un software craftsman poate livra calitate sub presiune. În această situație, un software craftsman ar trebui să livreze funcționalități noi în timpul alocat cu cât mai puține bug-uri. Cât de puține? Mai puțin de 10 per release. Acest număr este conservator, pentru că metodele agile (inclusiv Scrum) au cerut de la început ca la finalul fiecărui sprint de 2-3 săptămâni, echipa să livreze software cu 0 bug-uri cunoscute, după ce aplicația a fost validată de testeri.

Dar orice aplicație are bug-uri!

Denumirea de bug este un eufemism pentru greșeală. Greșelile sunt normale în orice activitate umană, chiar și atunci când dezvoltăm software. Întrebarea este cum poate fi redus numărul de greșeli și impactul lor. Unit

TODAY SOFTWARE MAGAZINE testing este o unealtă care poate ajuta, dar nu este singura. Alte unelte care pot ajuta sunt: code review, pair programming, reducerea numărului de linii de cod, design by contract.

Unit testing

Testarea unitară se referă la scrierea unor bucăți de cod, denumite cod de testare, care validează codul de producție. Testarea majorității aplicației devine așadar automată. Istorie: programatorii cred adesea în mod eronat că unit testing este o practică nouă. În realitate, era folosită chiar de pe vremea calculatoarelor mainframe cu cartele perforate. Pe vremea aceea, debugging-ul era foarte dificil din cauză că implica citirea unor foi lungi de zeci de metri imprimate cu rezultatul programului și informații despre execuție. Testele automate care rulau în același timp cu programul dădeau informații mult mai bogate legate de sursa greșelilor. Ce facem cu testerii? O temere întâlnită adesea este că testerii își vor pierde locul de muncă o dată cu introducerea testării automate. În realitate, testerii devin mult mai importanți pentru că acum doar ei pot descoperi problemele ascunse, greu sau imposibil de găsit prin teste automate. Ei ajută să crească probabilitatea că totul funcționează corect de la 80+% la aproape 100%. Testele unitare au câteva caracteristici importante: • fiecare test validează un comportament din aplicație; • rulează foarte repede, maxim în câteva minute; • sunt foarte scurte și ușor de citit; • rulează la apăsarea unui buton, fără configurări suplimentare. Pentru a fi rapide, testele unitare folosesc adesea așa-numitele „duble de testare”. La fel cum piloții de avioane învață întrun simulator înainte de a se urca în avion, testele unitare folosesc bucăți de cod care seamănă cu codul de producție, dar în realitate folosesc doar la teste. Stub-urile și mock-urile sunt cele mai întâlnite duble de testare, existând multe altele mai puțin folosite. Un stub este o dublă de testare care întoarce valori. Stub-ul este similar cu o simulare foarte simplă: atunci când apeși un buton, apare o valoare. În cod, un stub poate arăta astfel: class PaymentServiceStub implements Payment-

Service{ public boolean valueToReturnOnPay;

mock(PaymentService.class); PaymentProcessor paymentProcessor = new PaymentProcessor(paymentServiceMock); paymentProcessor.processPayment(amount);

public boolean pay(Money amount){ return valueToReturn; } }

verify(paymentServiceMock).pay(amount); }

class PaymentProcessorTest{ @Test public void paymentDoneWhenPaymentServiceAcceptsPayment(){ PaymentServiceStub paymentServiceStub = new PaymentServiceStub(); paymentServiceStub.valueToReturn = true; PaymentProcessor paymentProcessor = new PaymentProcessor(paymentServiceStub); paymentProcessor.processPayment( Money.RON(100)); assertPaymentWasCorrectlyPerformed( paymentProcessor); } }

Un mock este o dublă de testare care validează colaborarea între clase. Mock-ul validează apeluri de metode, cu anumiți parametri, de un anumit număr de ori. Din această cauză, un mock poate fi folosit și la validarea apelurilor de metode care nu întorc valori. class PaymentServiceMock implements PaymentService{ public boolean payWasCalled; public Money actualAmount; public void pay(Money amount){ actualAmount = amount; payWasCalled = true; } } class PaymentProcessorTest{ @Test public void paymentServiceCalledOnPaymentProcessing(){ PaymentServiceMock paymentServiceMock = new PaymentServiceMock(); PaymentProcessor paymentProcessor = new PaymentProcessor(paymentServiceMock); Money expectedAmount = Money.RON(100); paymentProcessor. processPayment(expectedAmount); assertTrue(paymentServiceMock.payWasCalled); assertEquals(expectedAmount, paymentServiceMock.actualAmount); } }

}

Inițial dublele de testare erau folosite doar în locurile unde era foarte greu să controlezi sistemul sau unde testele erau încetinite de apeluri la sisteme externe. În timp, dublele de testare au ajuns să fie folosite în toate testele unitare, dând naștere metodei „mockiste” de testare unitară. Pentru mai multe detalii, articolul „Mocks aren’t stubs” de Martin Fowler 1 este edificator. Testele unitare sunt scrise de programator, în timp ce implementează o funcționalitate. Din păcate, cel mai întâlnit mod de a scrie teste este cândva după ce a fost terminată implementarea. Rezultatul este că testele sunt scrise având în minte cum ar trebui să funcționeze codul și nu testarea lui. Test First Programming este o metodă de a scrie teste care implică următorii pași: • crearea unui design pentru implementarea funcţionalităţi • crearea minimului de cod necesar (compilabil, dacă limbajul folosit este compilat) pe baza design-ului • scrierea unuia sau mai multor teste care codează ceea ce trebuie să facă design-ul; testele vor pica în acest moment • implementarea codului care face testele să treacă.

Prin aplicarea Test First Programming, programatorii se asigură că scriu teste Dublele de testare pot fi create și folo- unitare și că testează ceea ce ar trebui să sind framework-uri speciale, cum ar fi rezolve, nu implementarea soluției. mockito pentru Java (a fost portat și pe alte Test Driven Development (TDD) limbaje) sau moq pentru .NET. poate fi a treia metodă de a scrie teste. De class PaymentProcessorTest{ fapt, TDD este o metodă de a face design @Test incremental. Un articol viitor va trata pe public void paymentDoneWhenPaymentServiceAcceptsPaymentlarg ce înseamnă și de ce este util TDD. WithMockitoStub(){

Money amount = Money.Ron(100); PaymentServiceStub paymentServiceStub = mock(PaymentService.class);

Durează mai mult când scriu teste!

when(paymentServiceStub.pay(amount)). thenReturn(true); PaymentProcessor paymentProcessor = new PaymentProcessor(paymentServiceStub); paymentProcessor.processPayment(amount); assertPaymentWasCorrectlyPerformed( paymentProcessor); } @Test public void paymentServiceCalledOnPaymentProcessingWithMockitoMock(){ Money amount = Money.RON(100); PaymentServiceMock paymentServiceMock =

Studiile de caz2 și experiența personală a arătat că într-adevăr, timpul petrecut strict pe dezvoltarea unei funcționalități crește o dată cu adoptarea unit testing. Aceleași studii au arătat că timpul petrecut pe mentenanță scade drastic, arătând ca unit testing poate aduce o îmbunătățire html

1 http://martinfowler.com/articles/mocksArentStubs.

2 Cel mai cunoscut studiu de caz legat de unit testing a fost facut la Microsoft: http://collaboration.csc.ncsu.edu/laurie/ Papers/Unit_testing_cameraReady.pdf

www.todaysoftmag.ro | nr. 12/Iunie, 2013

programare netă în timpul de dezvoltare. Acest fapt nu poate schimba percepția programatorului care trebuie să scrie mai mult cod. De aceea, programatorii presupun adesea că per total proiectul merge mai încet din cauza testării automate.

Cum încep?

cu zi astfel încât productivitatea să fie cât mai puțin afectată; 3. Testarea automată în primul rând a celei mai importante părți din aplicație și apoi a funcționalităților cu cel mai mare risc de greșeală; 4. Folosirea strategiei de testare de tip „Piramida testelor”3pentru a elimina cât mai multe greșeli cu putință; 5. În cazul în care există mult cod (legacy code), este recomandată învățarea unor tehnici suplimentare pentru a scrie teste pe cod existent. Mai multe detalii într-un articol viitor.

Este bine ca adopția unit testing să se facă cu grijă, incremental, urmărind câteva puncte importante: 1. Clarificarea conceptelor legate de unit testing înainte de a începe scrierea de teste.Programatorii trebuie să poată „mânui” fără teamă unelte precum: stub-uri, mock-uri, teste de stare, teste de Greșeli comune colaborare, teste de contract, dependency Câteva greșeli comune legate de unit injection. De asemenea, programatorii testing sunt: trebuie să înțeleagă ce cazuri merită și 1. S c r i e r e a m u l t o r t e s t e d e trebuie testate.Există câteva modalități integrare(care implică mai multe clase prin care programatorii reușesc să stăpâsau module) lente și fragile în detrimennească aceste concepte: tul testelor unitare mici, rapide și ușor de • training specializat pe unit testing. întreținut Mozaic Works oferă un asemenea curs 2. Abandonarea dublelor de testare, sau (http://bit.ly/unit-testing-workshop) folosirea lor în scopuri pentru care nu care a avut constant feedback de peste au fost create. Dublele de testare ajută la 9.25/10 de la participanți. obținerea unor teste scurte și rapide. • pair programming între un tester 3. Numele testelor nu exprimă comporși un dezvoltator. tamentul testat. Numele testului poate da • pair programming între un dezfoarte multe informații atunci când testul voltator experimentat în unit testing pică. și unul începător. Dezvoltatorul expe4. Folosirea intensivă a debugger-ului pe rimentat poate fi și un coach tehnic teste. Testele bine scrise vor spune imeextern. diat unde este problema în cazul în care • documentarea din cărți (vezi la pică. Debugging-ul este în continuare util final cărţii recomandate), de pe interîn situații exotice. net sau prin participarea la evenimente 5. Cod de testare neîngrijit. Codul de de comunitate. testare este cel puțin la fel de impor• participarea la conferințe unde se tant ca și codul de producție, și trebuie discută concepte de unit testing. întreținut cu aceeași grijă. 2. Un coach tehnic poate lucra cu programatorii, ajutându-i să transfere Mai multe detalii despre aceste probleme informațiile teoretice în practica de zi 3 http://martinfowler.com/bliki/TestPyramid.html

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

puteți afla dintr-un blog post de același autor, „5 common unit testing problems” de la adresa http://mozaicworks.com/ blog/5-common-unit-testing-problems/.

Concluzie

Unit testing-ul este una dintre metodele pe care un programator o poate folosi cu scopul de a reduce numărul de greșeli pe care le face când scrie cod. Folosit corect, unit testing-ul poate reduce semnificativ timpul petrecut cu repararea bug-urilor din aplicații, reducând încărcarea colegilor care se ocupă de suport și testare și permițând introducerea de noi funcționalități mai repede, ceea ce conduce la competitivitate crescută. Dar unit testing-ul trebuie adoptat cu grijă, urmând practicile din industrie (piramida testelor, folosirea dublelor de testare etc). Ajutorul extern (training și coaching tehnic) poate face diferența între o adopție reușită și una cu probleme. Un software craftsman stăpânește unit testing și îl folosește atunci când e nevoie să se protejeze de greșeli, fie ale sale fie ale colegilor de echipă. Așa este sigur că poate livra software fără bug-uri chiar și atunci când e sub presiunea timpului. Cu condiția, evident, să învețe unit testing atât de bine încât să îl folosească cu ușurință chiar și atunci când e sub presiune.

Cărți recomandate „The Art of Unit Testing”, Roy Osherove „xUnit Test Patterns”, Gerard Meszaros „Growing Object Oriented Software Guided by Tests”, Steve Freeman, Nat Pryce

TODAY SOFTWARE MAGAZINE

Behavior Driven Development în Python

n ziua de azi, testerii sunt priviți ca fiind cei care execută munca de rutină, de o dificultate mai ușoară, și ale căror skill-uri tehnice nu sunt atât de puternice pe cât cele ale programatorilor. Există echipe fragmentate, două tabere practic: developeri și testeri. Accentul nu se pune pe comunicare și colaborare, ci se investește efort și energie în acel vechi “battle”, în care fiecare dorește să demonstreze că echipa proprie e mai bună.

Ramona Suciu

ramona.suciu@3pillarglobal.com Test Lead @ 3Pillar Global

Astfel de situații au dus în final la apariția conceptului de Testers = second class citizens. Ce înseamnă acest lucru mai exact? Nu se lucrează constructiv împreună, unde atât testerul cât și developerul pot beneficia unul de expertiza celuilalt, ci testerul lucrează doar după ce o bună parte din munca developerului e gata (există ceva palpabil pentru testare).

Proiectul nostru

Dan Pop

dan.pop@3pillarglobal.com Senior Test Engineer @ 3Pillar Global

...este unul complex, unde lucrează o echipa de aproximativ 50 persoane. Dacă nu am insista foarte mult pe colaborare și comunicare, nu am reuși să facem față metodologiei Kanban ce o abordăm, ce presupune un număr mare de teste automate, inițiativă și proactivitate din partea tuturor. Cum am ajuns noi să depășim această situaţie? Prin efort colaborativ și comunicare. Testerii nu trebuie să aștepte ca un build să fie gata pentru testare, pentru a-și putea începe munca, ci pot lucra împreună cu developerii încă din momentul în care detaliile unui epic/story sunt clarificate. Împreuna pot stabili scenariile relevante ce trebuie testate, și scrie codul de automation necesar. Suntem mândri să lucram într-un mediu unde fiecare membru al echipei se

ghidează după principiul Quality is a team effort. Trebuie să ținem cont de un lucru: această abordare nu ar fi posibilă fără un număr mare de teste automate, care să asigure regression testing-ul. În caz contrar, toată această comunicare cu echipa de development ar deveni un overhead pentru testeri (și nu numai), deoarece presupune multe discuții în prealabil, care consumă din timpul necesar scrierii și executării testelor. Poate vă gândiți că o simplă abordare Agile-Scrum ar fi suficientă, pentru că detaliile necesare implementării și testării unui feature nou se pot stabili în cadrul unui meeting de stand-up. Dar cred că știți cu toții că aceste meeting-uri pot devia de la formatul lor standard, depășindu-se deseori numărul de 15 minute alocate în mod ideal, și nu se ajunge la un consens în ceea ce privește rolul fiecărui membru al echipei.

Concepte teoretice Behavior Driven Development

Pentru a îmbunătăți și mai mult lucrul în echipa noastră, ne-am îndreptat atenția către Behavior Driven Development1, o metodologie ce se axează pe comunicare și colaborare ca puncte forte. Definiții pentru 1 http://dannorth.net/introducing-bdd/

www.todaysoftmag.ro | nr. 12/Iunie, 2013

QA Behavior Driven Development în Python BDD sunt multe, dar noi vă prezentăm câteva dintre conceptele BDD așa cum le-am aplicat în cadrul proiectului nostru: 1. C omp a r at i v c u Te s t D r i v e n De velopment (unde testele dictează arhitectura), Behavior Driven Development reprezintă o extensie. Ca și în TDD, testele reprezintă catalizatorul metodologiei, dar sunt scrise într-un format ușor de înţeles de către toată lumea. Vorbim aici de limbajul Gherkin (Given-When-Then), care permite și persoanelor non-tehnice din echipă să contribuie la scrierea și menținerea testelor. 2. Comunicarea și Colaborarea reprezintă fundamentele BDD. Fără aceste două concepte, BDD nu poate fi aplicat cu succes. 3. Diferite perspective asupra sistemului sunt oferite atunci când se aplică BDD. Și acest lucru este posibil pentru că BDD ne dă ocazia să punem câteva întrebări cheie echipei de product management: a. De ce este nevoie de acest feature? b. Care este problema ce o adresează? Care este publicul țintă? c. Care sunt alternativele? d. ...and so on Răspunzând la întrebări de acest gen, putem să privim produsul din prisma product owner-ului, fiind capabili astfel să înțelegem mai bine business value-ul ce un produs/feature nou îl poate aduce. 4. De asemenea, dacă cele mai de sus se aplică cu succes, o mai bună relaționare cu clienții este un alt avantaj ce rezultă aproape fără efort. 5. L i v i n g d o c u m e n t a t i o n

- Documentația formată din testele scrise După cum vă puteți da seama, BDD în limbajul Gherkin, constituie principa- este un proces complex, care se poate lul avantaj al acestei metodologii. aplica sub diferite “flavours” în cadrul mai multor echipe. Este o metodologie ce se Procesul BDD în echipa noastră ghidează după context, aceeași rețetă BDD Practic, pașii ce îi urmăm noi din ce funcționează pentru un proiect aducând momentul în care apare o idee de feature alte rezultate dacă aplicată altui proiect. nou, până când aceasta se materializează Sunt multe challenge-uri ce pot apărea de-a sunt următorii: lungul timpului, iar noi am încercat să le 1. Echipa de management are o idee abordăm pe fiecare în parte, evitând pe cât despre un feature/produs nou, idee trans- se poate recurgerea la compromisuri: pusă în backlog. • Această idee este transpusă de 1. Implicarea activă a echipei de promulte ori direct ca soluție tehnică. duct management Această abordare este greșită și aici este • Challenge: rolul PO-ului este un aspect asupra căruia BDD ne permult mai mare într-un proces BDD, mite să lucrăm. Product managementul iar aportul lor la scrierea și menținerea trebuie să propună ideea, iar toată testelor în limbajul Gherkin trebuie să echipa contribuie la găsirea celei mai fie într-un procentaj mai mare decât cel eficiente soluții tehnice. al echipei tehnice. În cazul nostru, încă 2. În mod ideal, product managemennu am ajuns în această situație. Ținând tul și business analyst-ul participă la cont de timpul limitat pe care PO-ul îl discuțiile preliminare, unde se pun întrepoate acorda acestui task, developerii bările cheie și se clarifică diverse aspecte. și testerii sunt cei care scriu scenariile • În lipsa unui business analyst, noi Gherkin, acestea urmând a fi revizuite am descoperit că cel puțin în acest caz, periodic împreună cu managemenatribuțiile business analyst-ului pot fi tul. Este o soluție de compromis ce preluate de către echipa tehnică: tech funcționează în acest moment pentru leads, developeri, testeri. echipa noastră. 3. Se discută pe seama ideii, până când 2. Folosirea cât mai eficientă a limbase ajunge la un consens asupra soluției și jului Gherkin a strategiei de implementare/testare. • Challenge: acest lucru este unul 4. În final, ideea este transpusă în bug dintre cele mai complexe concepte ale tracker, nu ca o soluție venită direct din BDD, deși în aparență poate părea despartea product management-ului, ci ca tul de simplu. A scrie teste astfel încât un rezultat al efortului colaborativ din să fie ușor de înţeles, ușor de menținut, partea întregii echipe, ajungându-se din care să reiasă cu exactitate business astfel la un epic/story cu detaliile bine value-ul feature-ului respectiv, se poate clarificate. dovedi a fi un challenge în sine. 3. Living Documentation Our core competencies include:

Product Strategy

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

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

Product Development

Product Support

TODAY SOFTWARE MAGAZINE • Challenge: documentația formată exclusiv din teste poate deveni un challenge, deoarece sunt multe checkpoint-uri ce trebuie bifate, pentru a atinge acest goal: i. oglinda codului, reflectă întocmai situația actuală a codului, ii. să fie accesibilă tuturor iii. s ă fie ușor de înțeles, ușor de menținut iv. presupunând că se dorește o schimbare majoră, într-un sistem legacy, Living Documentation poate reda riscurile ce pot apărea ca urmarea implementării schimbării respective. Acest lucru este posibil pentru că având teste scrise corect în limbajul Gherkin, putem urmări interacțiunea dintre componente, prin intermediul testelor, și vom reuși astfel să anticipăm posibilele riscuri. Am insistat asupra limbajului Gherkin, exemplificând modul cum se poate descrie un feature prin scenarii scrise cu ajutorul acestui limbaj. Aceste teste sunt ținute în același loc cu codul, reprezentând datele de intrare ale unui tool specific BDD (Cucumber, Lettuce, Freshen, etc.). De aceea vom ști că sunt mereu up to date testele sunt modificate de îndată ce codul este modificat, pentru a continua să reflecte situația actuală a codului.

permanență specific BDD, poate fi folosit cu Python 2. BDD depinde foarte mult de context, ...și lista poate continua așa că încercăm mereu să ne adaptăm stilul de lucru astfel încât să acoperim particularitățile fiecărui proiect 3. Codul scris de developeri trebuie să fie de la bun început testabil. Fără acest lucru, nu vom putea să scriem scenarii Gherkin care să îndeplinească cerințele Living Documentation menționate mai sus. 4. Living Documentation reprezintă goal-ul nostru principal pe toată durata existenței unui proiect unde se aplica BDD. BDD este un proces complex, dar avantajele sale sunt multe, și contribuie mult la închegarea unei echipe în adevăratul sens al cuvântului și la livrarea unui produs de succes. Recomandăm sincer abordarea acestei metodologii, indiferent de complexitatea proiectului sau dimensiunea echipei. Aplicat astfel încât să țină cont de nevoile clare ale proiectului, BDD poate deveni cu ușurință o poveste de succes.

Bibliografie

Mai multe informații cu privire la cum se pot descrie funcționalități folosind un limbaj ubiquitos2 (Gherkin) , în funcție de tool-ul ales, se pot găsi la: •

Concluzii

Conceptele BDD aplicate în acest • moment cu succes, obțin rezultatele dorite, dar suntem conștienți de faptul că mai • avem mult de lucru. Printre obiectivele noastre în viitor, amintim: 1. C omunic are și col ab orare în •

html

Lettuce tutorial (http://lettuce.it/tutorial/ simple.html#id1)-tool specific BDD, poate fi folosit cu Python Cucumber tutorial (http://cukes.info/) - tool specific BDD, poate fi folosit cu Ruby Freshen tutorial (https://github.com/rlisagor/ freshen)- tool specific BDD, poate fi folosit cu Python Behat tutorial (http://behat.org/) - tool

2 http://martinfowler.com/bliki/UbiquitousLanguage.

www.todaysoftmag.ro | nr. 12/Iunie, 2013

Test Driven Development (TDD)

est Driven Development (TDD) este o abordare a dezvoltării de software ce combină Test First Development (TFD) cu refactorizarea. Legat de scopul test driven development-ului există mai multe puncte de vedere: specificarea codului și nu validarea lui. Cu alte cuvinte, este o cale de a gândi prin prisma cerințelor sau a designului înainte de a ne apuca efectiv a scrie cod funcțional (TDD este o cerință agile - agile requirement - și o tehnică de design agile). Un alt punct de vedere este că TDD reprezintă o tehnică de programare al cărui scop este acela de a scrie cod curat care funcționează. Voi descrie o situație cu care majoritatea suntem familiari: programatorii scriu codul, iar la un moment dat acest cod ajunge la testare. Testerii descoperă anumite anomalii în funcționalitatea codului, numite bug-uri, pe care le trimit programatorilor spre a fi reparate. După ce programatorul a reparat bug-ul, trimite din nou codul la testare. De cele mai multe ori acest ”dialog” programator – tester nu este foarte clar și precis, un bug fiind pasat la tester de către programator ca și rezolvat, tester-ul descoperă că de fapt nu s-a rezolvat și îl trimite înapoi la programator și tot așa. Pentru a nu se ajunge prea des în situația prezentată anterior, una dintre măsurile luate a fost cea ca programatorul să scrie teste înainte de a implementa o anumită funcționalitate. Această tehnică se numește TFD (Test First Development). Primul pas al TFD este de a se scrie un test care va eşua. Următoarea mișcare e cea de a rula toată suita de teste, sau, pentru a economisi timp se va rula doar un subset al suitei de teste, pentru a se dovedi că întradevăr testul adăugat va eşua. Urmează să facem o mică modificare în cod în așa fel încât o nouă rulare a testelor să se termine cu succes. În cazul în care n-am reușit acest lucru vom modifica din nou codul și vom rula testele din nou până când acestea se vor termina cu succes. În momentul în

care rularea testelor s-a încheiat cu succes putem s-o luăm de la început cu adăugarea unui nou test. TDD = TFD + Refactoring Dacă, aplicând TFD, înainte de a trece la scrierea unui nou test curățăm, optimizăm codul înseamnă că aplicăm Test Driven Development, numit și RED – GREEN – REFACTOR workflow. Regulile TDD: 1. Este permis să scrii cod de producție doar dacă scopul acestui cod este să facă un test ce eşuează să ruleze cu succes. 2. Nu este permis să scrii decât un test care eşuează. Trebuie să începi prin a scrie un test pentru funcționalitatea pe care vrei s-o implementezi. Conform celei de-a doua reguli nu poți să scrii prea multe teste. Imediat ce rularea unit testului se termină cu eșec trebuie să te oprești din a scrie teste și să începi să scrii cod de producție în așa fel încât rularea testelor să se termine cu succes. Atenție însă la a treia regulă care ne zice că imediatce am scris destul cod de producție pentru a face ca rularea testelor să se termine cu succes, suntem obligați să ne oprim din a scrie mai mult cod și să reluăm scrierea de teste. Dacă stăm și analizăm puțin cele trei reguli TDD vom realiza că nu putem scrie prea mult cod fără să compilăm, rulăm ceva. Acesta este de fapt scopul nostru. Orice am face: scriem teste, scriem cod de producție sau refactorizăm trebuie să ținem sistemul în execuție. Intervalul de timp dintre rularea testelor poate să fie de ordinul secundelor sau al minutelor. Chiar și o durată de 10 minute poate fi considerată prea mare. Când aud de aceasta tehnică, mulţi dintre programatori gândesc: ”Asta e o aberaţie! O să mă încetinească și mai mult, e o

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

pierdere de timp și de efort. Nu o să mă lase să mă gândesc, nu o să pot face designul cum trebuie, pur și simplu o să strice bunul mers al lucrurilor”. Perfect, să ne gândim ce s-ar întâmpla dacă am intra într-un birou în care toți programatorii ar folosi TDD. Alegeți aleator o persoană din respectivul birou în orice moment și întrebați-l care e starea codului. Cu un minut înainte tot codul lor rula. Repet: ”Acum un minut tot codul lor rula!”. Și nu contează pe cine ai ales sau când l-ai ales, răspunsul e același: ”Acum un minut tot codul lor rula!”. Dacă tot codul tău funcționează la fiecare minut, cam cât de des crezi că vei folosi debugger-ul? Răspunsul este: nu prea des. Este mult mai simplu să apeși de câteva ori CTRL+Z să ajungi înapoi la starea în care codul tău funcționa, iar după asta să încerci să rescrii ceea ce ai scris greșit în ultimele minute. Cât timp vei economisi dacă nu faci prea mult debugging? Cât timp petreci acum făcând debugging? Cât timp petreci acum rezolvând bug-urile pe care le-ai descoperit făcând debugging? Ce ai spune dacă ai putea să scazi semnificativ acest timp? Adevăratele beneficii ale acestei tehnici sunt însă și mai mari: dacă folosești TDD atunci produci câteva teste pe oră. Zeci de teste pe zi. Sute de teste pe lună. Vei ajunge să scrii mii de teste într-un an. Poți să păstrezi aceste teste și să le rulezi oricând vei dori. Când ar trebui să le rulăm? Tot timpul. De fiecare dată când am modificat ceva în cod, indiferent de proporțiile acelei modificări. De ce nu curățăm codul chiar dacă știm că nu e prea curat? Pentru că ne este frică să nu-l stricăm. Dar dacă avem toate aceste teste putem fi siguri în cea mai mare măsură că nu vom strica codul, iar în cazul în care acest lucru s-ar întâmpla l-am observa imediat. Dacă avem teste vom fi liniștiți în momentul în care facem

TODAY SOFTWARE MAGAZINE modificări în cod. Dacă vedem pe undeva cod „murdar” (messy code) putem să-l curățăm fără rezerve. Datorită testelor codul devine maleabil. Continuăm cu beneficiile TDD: dacă vrei să știi cum să apelezi un anumit API, există un test ce face acest lucru. Dacă vrei să știi cum se creează un anumit obiect, este un test ce face acest lucru. Orice ai vrea să afli despre sistemul existent vei găsi un test care conține răspunsul la întrebarea ta. Testele sunt ca niște mici documente de design, mici exemple de cod care descriu cum funcționează sistemul și cum să-l folosești. Ați integrat un third party library în proiectul vostru? Primiți cu acest library și un manual plin de documentație la finalul căruia aveți o listă cu câteva exemple. Care dintre cele două le-ați citit? Exemplele, bineînțeles. Acestea sunt unit testele. Cea mai folositoare parte a documentației. Exemple ale modului în care să folosești codul. Acestea sunt documente de design detaliate, clare, ce nu se pot desincroniza în raport cu codul de producție. Dacă ați încercat să adăugați un unit test la un sistem deja funcțional probabil că ați observat că nu este un lucru trivial. Este posibil ca pentru a face acest lucru să fi fost nevoiţi să schimbați anumite părți ale designului sistemului, sau să trebuiască să păcăliți testele. Acest lucru se datorează faptului că sistemul pentru care încercați să scrieți testele nu a fost proiectat să fie testabil. De exemplu, să presupunem că vreți să testați o anumită metodă, ”m”. Metoda ”m” apelează o altă metodă care șterge o înregistrare din baza de date. În testul nostru nu vrem ca această înregistrare să fie ștearsă din baza de date, dar nu avem cum să împiedicăm acest lucru. Asta înseamnă că sistemul a fost proiectat în așa manieră încât acesta nu este testabil. Când urmăm cele trei reguli ale TDD tot codul nostru devine testabil prin definiție. Un alt cuvânt pentru ”testabil” este ”decuplat”. Pentru a testa izolat un modul acesta trebuie decuplat. TDD te forțează să decuplezi module, iar aplicând cele trei reguli TDD vei observa că vei folosi decuplarea mult mai des decât erai obișnuit s-o faci până acum. Acest lucru te va face să creezi un design mai bun, mai puțin cuplat (less coupled).

Începerea ciclului Test-Driven

Procesul TDD presupune că putem mări sistemul doar prin inserarea de teste pentru funcţionalităţi noi într-o infrastructură deja existentă. Dar ce se întâmplă

cu prima funcţionalitate, înainte să avem infrastructura gata creată? Un test de acceptanţă trebuie să ruleze end-to-end. În plus, trebuie să ne ofere feedback-ul necesar despre interfeţele externe ale sistemului, ceea ce înseamnă că trebuie să avem deja implementat un sistem automatizat de build, deploy şi test. Este multă muncă de depus înainte să putem vedea primul nostru test care eşuează. Deploy-ul și testarea unui proiect chiar de la început forţează echipa să înţeleagă cum sistemul lor se integrează în lume. Scoate la iveală toată lipsa de cunoştinţe tehnice și riscuri organizaţionale care trebuie adresate cât mai este timp. Începerea cu un build, deploy, și test automatizat a unui sistem nonexistent sună ciudat, dar este esenţial.Există tot felul de cazuri de proiecte care au fost anulate după câteva luni de dezvoltare deoarece nu puteau face un deploy stabil al sistemului lor. Feedback-ul este o unealtă fundamentală, şi vrem să ştim cât mai repede dacă ne îndreptăm în direcţia potrivită. După ce avem primul test făcut, următoarele vor fi scrise mult mai repede. Dilema în a scrie şi a trece primul test de acceptanţă stă în faptul că este dificil a face un build al sistemului și a testa noua funcţionalitate implementată în aceelaşi timp. Modificări într-una din cele două perturbă orice progres făcut cu cealaltă. Urmărirea eşecurilor este dificilă atunci când arhitectura, testele și tot codul de producţie sunt în continuă dezvoltare. Unul dintre simptomele unui mediu de dezvoltare instabil este că nu există un prim loc evident de căutare când ceva eşuează. Acest paradox al primei funcţionalităţi poate fi împărţit în două probleme mai mici. Prima constă în a afla cum se poate face build, deploy și testa acest “walking skeleton”. Apoi, se foloseşte această infrastructură nou creată pentru a scrie teste de acceptanţă pentru prima funcţionalitateimportantă. După toate acestea, se poate începe dezvoltarea test-driven a întregului sistem. Un “walking skeleton” este o implementare a celei mai mici bucăţi de funcţionalitate pe care se poate face build, deploy, și testare end-to-end automatizată. Trebuie incluse doar componentele majore și mecanismele de comunicare care ne ajută la implementarea primei funcţionalităţi. Funcţionalitatea aplicaţiei schelet

este atât de simplă încât este evidentă şi neinteresantă, lăsându-ne liberi să ne concentrăm pe infrastructură. De exemplu: pentru o aplicaţie web cu o bază de date, scheletul ar trebui să consiste dintr-o pagină web uniformă cu câmpuri din baza de date. În timpul construirii scheletului trebuie să ne concentrăm doar pe structură şi nu pe curăţarea testului. Scheletul și infrastructura sa sunt făcute pentru a ne ajuta să începem dezvoltarea test-driven. Este doar primul pas spre o soluţie completă end-toend de testare de acceptanţă. Când scriem testul pentru prima funcţionalitate, acesta trebuie să fie un test pe care să putem să îl citim, pentru a ne asigura că e o reprezentare clară a comportamentului sistemului. Dezvoltarea scheletului este momentul în care încep deciziile asupra structurii high-level a aplicaţiei. Nu putem automatiza un build, un deploy și un ciclu de test fără o idee asupra întregii structuri. Detaliile nu sunt necesare. Avem nevoie doar de o imagine de ansamblu asupra componentelor majore necesare pentru primul release planificat, şi comunicarea dintre componente. Regula de bază este că designul trebuie să poată fie desenat în doar câteva minute. Pentru designul structurii iniţiale avem nevoie de o viziune high-level a cerinţelor clientului, atât funcţionale cât şi non-funcţionale pentru a ne ghida deciziile. Figura de mai jos arată cum procesul de TDD se integrează în acest context:

Nu există tot timpul luxul de a crea un nou sistem de la zero. Majoritatea proiectelor pe care lucrăm au început de la un sistem existent care trebuie extins, adaptat sau înlocuit. În aceste cazuri, nu putem începe sa construim un “walking skeleton”; trebuie să ne adaptăm la cel existent, indiferent cât de ostilă ar fi structura lui. Procesul de începere al TDD-ului pe un asemenea sistem nu e prea diferit faţă de aplicarea lui pe un nou sistem – deşi se poate dovedi mult mai dificil din cauza bagajului tehnic pe care sistemul deja il cară. Este destul de riscant să lucrezi pe un sistem atunci când nu există teste care să detecteze regresiile. Cel mai sigur mod de a începe TDD-ul este de a automatiza procesele de build și de deploy, şi de a adăuga teste end-to-end care acoperă acele

www.todaysoftmag.ro | nr. 12/Iunie, 2013

QA Test Driven Development (TDD) regiuni de cod ce trebuie schimbate. Cu această protecţie, se poate începe adresarea de probleme interne de calitate cu mai multă încredere, refactorizarea codului şi introducerea de unit teste pe măsură ce se adaugă funcţionalităţi.

Menţinerea ciclului test-driven

Odată început procesul de TDD, trebuie menţinut să ruleze fără probleme. Munca pentru o funcţionalitate nouă începe cu un test de acceptanţă care pică, ceea ce demonstrează că sistemul nu are încă funcţionalitatea pe care o vom implementa. Acest test se scrie folosind terminologia din domeniul aplicaţiei, nu din tehnologiile care stau la baza ei (ex: baze de date sau servere web). Astfel, ne ajută să înţelegem ce ar trebui să facă sistemul nostru și ne protejează suita de teste de acceptanţă împotriva schimbărilor tehnice ale infrastructurii sistemului. Scrierea acestor teste înaintea scrierii codului ne ajută să clarificăm ceea ce vrem

să obţinem. Testele care pică ne ţin concentraţi în implementarea setului limitat de funcţionalităţi pe care le descriu, crescând şansele noastre de a le livra. Unit testele sunt importante în realizarea design-ului claselor şi în a ne da încrederea că funcţionează, dar ele nu ne spun nimic dacă funcţionează împreună cu restul sistemului. De unde începem când trebuie să scriem o nouă clasă sau funcţionalitate? E tentant să începi cu cazurile degenerate sau de eşec pentru că sunt de obicei mai uşoare. Cazurile degenerate nu aduc multă valoare sistemului, şi cel mai important nu ne dau feedback despre validitatea ideilor noastre. Incidental, focusarea pe cazurile de eşec la începutul unei funcţionalităţi este rea pentru moral: dacă ne ocupăm doar de error handling, ne simţim ca și cum nu am realizat nimic. Cel mai bine e să începem cu cel mai simplu caz de succes. Odată ce acel test merge, avem o mai bună idee a structurii reale a soluţiei, şi putem prioritiza între a ne ocupa de posibilele eşecuri ce le-am

observat între timp și alte cazuri de succes. Vrem ca fiecare test să fie cât de clar posibil o reprezentare a comportamentului sistemului sau a obiectului. Când testul e lizibil, atunci construim infrastructura din spatele testului. Ştim că am implementat destul cod de test atunci când testul pică în modul în care ne aşteptam, cu un mesaj de eroare clar, care descrie ce trebuie făcut. Doar atunci putem începe să scriem codul care va face testul sa treacă. Întotdeauna trebuie să vedem testul cum eşuează înainte să scriem codul care-l va face să treacă, şi să verificăm mesajul de diagnostificare. Dacă testul eşuează într-un mod în care nu ne-am aşteptat, atunci ştim că ceva n-am înţeles bine sau codul este incomplet, și îl putem repara. Când primim eşecul la care ne aşteptăm, verificăm dacă diagnostificarea este de ajutor. Dacă descrierea nu este clară, cineva va trebui să se chinuie atunci când codul se va strica în viitor. Ajustăm codul de test și rulăm testele din nou până când mesajul de eroare ne ghidează la problema cu codul nostru. Doar scrierea de multe teste, chiar şi atunci când rezultă în acoperirea mare a codului, nu garantează un codebase cu care se lucrează uşor. Mulţi developeri care adoptă TDD îşi găsesc primele lor teste greu de înţeles când le revizuiesc mai târziu. Această greşeală comună constă în faptul că ei se gândesc să testeze doar metodele obiectului. De exemplu: un test ce se numeşte testBidAccepted() ne spune ceea ce face

integrare, stăm în alertă pentru acele părţi de cod care sunt greu de testat. Când găsim o astfel de funcţionalitate, nu trebuie să ne întrebăm doar cum o testăm, ci și de ce este aşa de greu de testat. De cele mai multe ori, cel mai probabil e faptul că design-ul are nevoie de îmbunătăţiri. Aceaşi structură care face codul greu testabil acum, o va face şi mai greu pe viitor. Procesul de a scrie testele la început este un valoros avertisment a unei posibile probleme de mentenanţă și poate indica anumite indicii de rezolvare a problemei cât e încă la început.

Concluzii

Test-driven development nu înlocuieşte testarea tradiţională, ci în schimb defineşte o modalitate dovedită de a asigura testare eficientă. Un efect secundar al TDD-ului este că testele rezultate sunt exemple funcţionale de invocare a codului, oferind astfel o specificație a codului scris. Din experienţa noastră, TDD funcţionează incredibil de bine în practică și este ceva ce toţi dezvoltatorii de software ar trebui să adopte.

Referinţe: Test Driven Development: By Example, Kent Beck, Addison-Wesley Longman, 2002 Growing Object-Oriented Software Guided by Tests, Steve Freeman, Nat Pryce,2009 http://butunclebob.com http://www.agiledata.org http://cumulative-hypotheses.org

Ladislau Bogdan

testul, dar nu pentru ce e folosit. Cel mai bine e atunci când ne focusăm pe funcţionalităţile furnizate de către obiectul testat, poate una dintre ele necesită o colaborare cu un alt obiect. Trebuie să ştim cum să folosim clasa ca să atingem un ţel, nu doar să exersăm toate căile prin codul ei. Este de foarte mare ajutor să alegem numele testelor pentru a descrie cum se comportă obiectul în scenariul testat. Când scriem unit teste și teste de

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

ladislau.bogdan@msg-systems.com Senior Software Developer @ .msg systems Romania

Tudor Trișcă

tudor.trisca@msg-systems.com Software Developer @ .msg systems Romania

tendințe

TODAY SOFTWARE MAGAZINE

Big Data, Big Confusion Într-o eră în care costurile de stocare și procesare devin tot mai mici, optica tradițională a felului în care operăm cu datele se schimbă decisiv

n “Big Data: A Revolution That Will Transform How We Live, Work and Think” autorii Viktor Mayer-Schonberger și Kenneth Cukier încep prin a prezenta situația anului 2009 în care virusul H1N1 reprezenta o îngrijorare majoră a Organizației Mondiale a Sănătății, dar în particular a guvernului American. Evoluția rapidă a epidemiei punea în dificultate CDC (Center for Disease Control and Prevention), o agenție guvernamentală, care a raportat situația cu o întârziere de două săptămâni față de realitatea din teren,pentru că populația nu intra în contact cu personalul medical după apariția primelor simptome. Raportarea în timp real ar fi permis o mai bună înțelegere a dimensiunii epidemiei, optimizarea tacticilor de prevenire și tratare, acțiuni cu potențial în salvarea de vieți într-un dezastru care, în final, a totalizat peste 284.000 de victime. Întâmplător cu câteva săptămâni înainte ca H1N1 să ajungă pe prima pagină a ziarelor Google a publicat în Nature, o publicație științifică, o lucrare în care prezentau rezultatele unui studiu care a pornit de la întrebarea “Există oare o corelație între răspândirea unei epidemii și căutările efectuate prin Google?”. Presupunerea de la care a plecat Google este că, în momentul în care cineva resimte efectele unei boli proaspăt contactate se va folosi de Internet pentru a căuta informații despre simptome. Astfel, utilizând datele publicate între 2003 și 2008 de către CDC și cele mai frecvente 50 de milioane de căutări din aceeași perioadă, Google a reușit să identifice un model matematic (iterând peste 400 de milioane de înregistrări) care să demonstreze corelația dintre evoluția unei epidemii și felul în care lumea caută pe Internet. Cu ajutorul acestei noi tehnologii, intitulate Google Flu Trends, CDC a reușit în 2009 să monitorizeze mai eficient răspândirea H1N1. Povestea Google Flu Trends este din multe puncte de vedere exemplul arhetip atât pentru beneficiile, cât și pentru tehnologia și provocările implicate în soluționarea unei probleme din spațiul Big Data. Pornind de la o ipoteză ce caută o corelație și folosind cantități mari, nestructurate de date, alături de tehnologii moderne de procesare, se încearcă validarea

corelației care, în final, aduce valoare prin transformarea datelor în informații noi. Big Data: Noul “Cloud Computing” Big Data se află la început de drum. O dovadă în acest sens o reprezintă confuzia pe care o putem întâlni în piață când vine vorba de a defini problema pe care Big Data o adresează și modul (sau modurile) în care o face. Când vorbeam în 2009 despre Cloud Computing mă amuzam să constat că întrebarea “Ce este Cloud Computing?” adresată unei săli cu 50 de participanți avea potențialul de a primi 52 de răspunsuri din care, culmea, multe corecte. Situația este similară în prezent în cazul Big Data și asta deoarece ne aflăm într-o perioadă apropiată de ceea ce Gartner numește “peak of inflated expectations” (vârful inflației așteptărilor). Cu alte cuvinte, peste tot se discută despre Big Data, iar toată industria este antrenată în a descoperi beneficii

într-un spectru larg de tehnologii și concepte, ce pornește de la un grad ridicat de maturitate/aplicabilitate (Predictive Analytics, Web Analytics) și se încheie cu scenarii inspirate din Star Trek (Internet of Things, Information Valuation, Semantic Web). “Cloud Computing” a trecut deja de vârf, conform volumului de căutări Google, în timp ce “Big Data” se află în continuare în creștere. Problema fundamentală ce determină confuzia și implicit așteptările nerealiste este însă cauzată de faptul că Big Data este compus (conform modelului “Hype Cycle” al Gartner) din peste 45 de concepte surprinse în diferite stadii: de la cel de pionierat (i.e. “Technology Trigger”) la cel de maturitate (i.e. “Plateau of Productivity”). Așadar Big Data nu poate fi tratat holistic la nivel tactic, ci doar principial, la nivel strategic.

Figura 1 - Volumul comparativ al căutărilor „Big Data” (albastru) și „Cloud Computing” (roșu) (sursa: Google Trends)

www.todaysoftmag.ro | nr. 12/Iunie, 2013

tendințe Big Data, Big Confusion Small Data Thinking, Small Data a afirmat în cartea sa “The Unreasonable Concluzii Results Effectiveness of Data” că “modele simple În momentul de față Big Data reprealimentate cu un volum mare de date vor eclipsa modele mai elaborate bazate pe mai puține date”, un principiu folosit și în realizarea Google Translate, un serviciu de traducere automată bazat pe un corpus de “More”: păstrează și nu arunca peste 95 de miliarde de propoziții formuCosturile de stocare a datelor au ajuns late în limba engleză, capabil să traducă în în 2013 la un minim istoric. În momentul și din peste 60 de limbi. de față stocarea a 1 gigabyte (GB) de date costă mai puțin de 9 cenți / lună folosind un “Correlation”: fapte și nu explicații serviciu de stocare în cloud (e.g. Windows Am fost învățați și ne-am obișnuit Azure), iar pentru arhivare ajung la 1 cent / că efectul este determinat de o cauză, lună (e.g. Amazon Glacier), reducând cos- motiv pentru care în mod natural suntem turile de stocare al unui petabyte (1.048.576 tentanți să aflăm “de ce?”. În lumea Big Data GB) la aproape $10.000,- (sau $10 pentru corelația devine mai importantă decât cauun terabyte), de 1.000.000 de ori mai ieftin zalitatea. În 1997 Amazon avea pe statul decât la începutul anilor ’90, când costul de plată un întreg departament responmediu de stocare / GB era de aproximativ sabil să întocmească liste cu recomandări $10.000. În acest context ștergerea datelor de lectură pentru cei ce vizitau librăria digitale acumulate din procesele infor- online. Era un proces manual, costisitor și matice are tot mai puțin sens. Google, cu impact limitat în generarea de vânzări. Facebook, Twitter ridică acest principiu la Astăzi, grație unui algoritm intitulat “itemnivel de lege fundamentală, reprezentând to-item collaborative filtering” dezvoltat biletul lor pentru noi dimensiuni de dez- de către Amazon, recomandările se fac în voltare și inovare, oportunitate deschisă mod complet automatizat, dinamic și cu acum și celor care până recent erau limitați un impact masiv în vânzări (o treime din de costurile prohibitive. veniturile generate de comerțul electronic provenind din recomandările automate). “Messy”: cantitatea precede calității Amazon nu vrea să știe de ce clienții care Google Flu Trends a funcționat deoa- cumpără “The Lord of the Rings” de J. R. rece Google a reușit să introducă în R. Tolkien sunt interesați să cumpere și procesul de iterație a modelelor matematice “Friendship and the Moral Life” de Paul J. cele mai frecvente 50.000.000 de căutări. Wadell, însă ce-i interesează este că există o Multe dintre aceste căutări au fost irele- corelație puternică între aceste două titluri, vante, însă volumul a fost necesar pentru iar aceastfapt le va genera venituri de trei a determina modelul care în final a reușit ori mai mari decât în lipsa unui astfel de să demonstreze corelația. Peter Norvig, sistem. expertul Google în inteligență artificială, Mayer-Schonberger și Cukier identifică trei principii fundamentale ce permit trecerea de la o abordare Small Data la una Big Data.

zintă tendința cea mai abuzată din piață, drept urmare gradul de confuzie generat de pletora de opinii întâlnite la tot pasul (categorie din care articolul de față nu se exclude) este extrem de ridicat, conducând la așteptări nerealiste și dezamăgiri pe măsura lor. Claritatea vine însă din înțelegerea potențialului, adoptarea principiilor (i.e. more, messy, correlation) și acționarea preventivă pentru adaptarea sistemelor curente la noul mod de gândire din perspectiva infrastructurii de calcul, al arhitecturii și a competențelor tehnice ale celor ce le operează. Miza este aceea de a identifica noi oportunități adresabile de transformare a datelor în informații ce pot crește eficiența unui produs sau al unei afaceri, așa cu a făcut-o Google prin Flu Trends sau Amazon prin sistemul lor automatizat de recomandări. Yonder acumulează experiență Big Data, investind strategic în proiecte de cercetare aplicată, alături de companii de produs care au înțeles viziunea pe care am conturat-o și beneficiile pe care o asemenea investiție le poate genera atât pe termen scurt cât și pe termen lung, acest trend reprezentând una din cele patru direcții tehnologice alese ca temă de inovație în 2013.

Mihai Nadăș mihai.nadas@tss-yonder.com CTO @ Yonder

Figura 2 - Big Data „Hype Cycle” (sursa: Gartner, 2012)

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

este responsabil de activitățile R&D și creșterea nivelului de inovație al produselor partenerilor Yonder.

programare

TODAY SOFTWARE MAGAZINE

Sisteme cu perfomanță/fiabilitate ridicată bazate pe “data grids” în Java

provocare importantă când construim un produs de succes este să ne asigurăm că produsul utilizează resursele hardware disponibile într-un mod eficient. Acest lucru înseamnă de obicei clustering (mai puțin pentru probleme foarte simple) pentru că seturile noastre de date au depășit calculatoarele individuale ca mărime și necesități de procesare. Cu toate acestea clustering-ul aduce o serie de noi probleme: împărțirea procesării între noduri, orchestrarea procesului și - foarte important - garanția că nu vom pierde datele / progresul dacă un subset de noduri devine indisponibill - o posibilitate care crește dramatic în momentul în care adăugăm mai multe noduri la cluster-ul nostru. “Data grids” sunt o categorie de software middleware, care ajută la rezolvarea problemelor enumerate mai sus. În acest articol voi prezenta o implementare rudimentară de bursă electronică care în ciuda simplității sale - are robustețea și performanța cerută de la sisteme reale grație librăriei pe care se bazează.

Bazele data grid-urilor

Data grid-urile furnizează trei servicii principale: • Una sau mai multe structuri de date de tip cheie-valoare (asemănător interfeței Map<K,V> din Java). Datele din aceste structuri sunt replicate pentru o fiabilitate ridicată. • În același timp permit definirea unui set de reguli pentru plasarea a datelor (de exemplu: trebuie ținute N copii pentru fiecare element, dintre care K trebuie să fie pe un anumit set de noduri - pentru asigurarea replicării geografice de exemplu) care măresc performanța (datele folosite împreună pot fi plasate pe același nod) și asigură garanții în cazul în care un subset de noduri devin indisponibile (fail-over între data-center-uri de exemplu). • Un serviciu de execuție care poate rula task-uri pe noduri. Aceste servicii de obicei sunt parametrizate folosind cheile din structurile (Map-urile) cheie-valoare pentru a se asigura că codul rulează pe mașina unde se află datele care urmează să le proceseze pentru evitarea transportul datelor prin rețea în mod repetat. • Posibilitatea de a fi notificat despre evenimentele din structurile cheie-valoare (adăugarea / eliminarea / actualizarea datelor)

Deși nu este o cerință ca un sistem săfie considerat “data-grid”, de obicei aceste librării pun la dispoziție o interfață configurabilă care să persiste datele în sisteme externe - baze de date / fișiere simple / etc. - ca să fie păstrate în timpul repornirii complete a sistemului (data-grid-urile stochează datele exclusiv în memoria volatilă). De asemenea, ele implementează de obicei suport pentru operații tranzacționale pe structurile de date. Biblioteca, prezentată în acest articol - Infinispan - foloseşte o tehnică numită hash-uri consistente1 pentru a oferi următoarea configurație posibilă în timpul rulării: folosind N noduri, vrem să păstrăm fiecare bucată de date pe exact K dintre ele (K≤N - de obicei 2 sau 3). Dacă sunt adăugate sau eliminate din cluster noduri, datele sunt redistribuite în așa fel încât proprietatea să fie menținută. Această redistribuție se întâmplă în mod transparent din punct de vedere funcțional (proprietățile non-funcționale a sistemului - cum ar fi latența - se schimbă în timpul procesului de redistribuție). Puteți vedea o ilustrare a conceptului în graficul alăturat:

De exemplu, să presupunem că avem N noduri, fiecare cu 12 GB de memorie. Dacă am păstra o copie identică a setului de date pe fiecare nod, dimensiunea maximă a datelor ar fi de 12 GB (dar am avea N copii, însemnând ca sistemul tolerează eșuarea a N-1 noduri). Dacă decidem că K exemplare a datelor (unul primar și K-1 copii) sunt suficiente pentru a satisface cerințele noastre de fiabilitate și folosim un sistem bazat pe hash consistent (ca și cel oferit de Infinispan), avem un maxim teoretic pentru dimensiunea datelor de (N*12GB.)/K. De exemplu, pentru N = 10 și K = 3 obținem o dimensiune maximă de40 GB (în comparație cu 12GB pentru cazul cu replicare completă).

Aici avem fiecare bucată de date (D1, D2 și D3) replicat în trei noduri, ceea ce înseamnă că oricare două noduri pot eșua în orice moment și datele vor fi disponibile în continuare. Un alt efect util al acestui mecanism de replicare este utilizarea optimă a resurselor în comparație cu oglindirea (mirroring) simplă:

• s u p o r t p e n t r u o p e r a ț i i tranzacționale, • replicare configurabilă între noduri și între centre de date, • posibilitatea de accesarea datelor prin interfețe standard, cum ar fi REST, protocolul memcached, WebSockets sau printr-un protocol binar numit Hotrod

1 http://en.wikipedia.org/wiki/Consistent_hashing

O scurtă istorie a Infinispan-ului

Infinispan2 este un proiect din cadrul meta-proiectului JBoss susținut de RedHat. Este un data-grid extrem de configurabil cu un set extins de facilități. Este succesorul produsului JBoss Cache cu multe caracteristici interesante: • scalabilitate înaltă, • suport pentru a rula ca server dedicat sau încorporat (embedded) în proces,

2 http://www.jboss.org/infinispan/

www.todaysoftmag.ro | nr. 12/Iunie, 2013

programare Sisteme cu perfomanță/fiabilitate ridicată bazate pe “data grids” în Java Folosirea Infinispan-ului este simplă - doar adăugăm dependența de Maven în POM și putem începe să o utilizăm. Se bazează pe JGroups, o soluție de messaging fiabil pur Java, ceea ce înseamnă că nu există un cod nativ care trebuie compilat / instalat. Infinispan este disponibil sub licența LGPL 2.13, ceea ce înseamnă că poate fi utilizat în orice proiect (comercial sau open-source). De asemenea, este disponibil suport comercial pentru el de la RedHat sub denumirea “Red Hat JBoss Data Grid”.

Descrierea proiectului

Acest proiect modelează „inima” unei burse electronice: motorul de potrivire (matching engine). Ea face acest lucru cu o performanță similară cu sistemele reale (peste 500 de evenimente pe secundă, în timp ce cea mai populară bursă de Bitcoin - MtGox - are în medie mai puțin de o tranzacție pe secundă). Fiind construit cu Infinispan, fiecare operațiune este replicată într-un nod secundar, ceea ce înseamnă că pierderea unui nod arbitrar poate fi tolerată fără pierdere date. De fapt, în codul sursă există un test care simulează chiar acest scenariu - pornește și oprește noduri în mod aleator în timp ce rulează motorul de potrivire. Sursă pentru întregul sistem este disponibil pe GitHub4sub licența liberă Apache 2. Structura sistemului poate fi văzută în schema de mai jos:

Clientul foloseşte datele capturate de la bursa Bitcoin MtGox pentru a crea comenzi (intenții de tranzacționare - cumpărare / vindere - la un anumit preț dat sau mai bun - așa-numitele “limit or better order”). Comenzile sunt transmise printro interfață HTTP / REST (implementat folosind Jersey) la unul din nodurile. Se demonstrează astfel interoperabilitatea cu alte sisteme non-Java, prin folosirea protocoalelor standard. După ce o comandă este transmisă nodul corespunzător, acesta este plasat în cartea de comenzi (orderbook - lista ordonată a tuturor comenzilor), algoritmul de potrivire este rulat și toate tranzacțiile rezultate sunt stocate. Toate acestea se întâmplă într-un mod tranzacțional, ceea ce înseamnă că nu se stochează rezultate parțiale / inconsistente. Clientul comunică cu un singur nod la un moment dat și comută la nodul următor (fail-over) dacă se observă o eroare. Nu este implementat în acest proiect, dar putem adăuga cu ușurință o conexiune care primește date în timp real despre tranzacții folosind de exemplu protocolul WebSockets. Cărțile de comenzi (orderbook) sunt serializate și deserializate într-un mod eficient pentru a fi sincronizate între nodurile primare și secundare utilizând faciliatatea de replicare delta din Infinispan prin care numai modificările (delta) sunt trimise print rețea . Acest lucru ne permite să păstrăm obiecte mari pentru o anumită cheie

fără a sacrifica eficiența în timpul replicării. Practic putem separa problema modelării datelor (ce subset de date trebuie păstrate împreună) de problema plasării datelor. Testul final repornește în mod aleator nodurile la fiecare câteva minute, fără ca acesta lucru să schimbe corectitudinea rezultatului.

Concluzii

Data-grid-urile sunt o soluție excelentă pentru sisteme care necesită performanță și fiabilitate ridicată. Proiectul prezentat în acest articol procesează cu un ordin de mărime mai multe date decât necesar în sistemele reale și poate fi integrat cu schimbări de cod minime. Face acest lucru într-un mod eficient, tolerând repornirea oricărui nod în timpul rulării.

Attila-Mihaly Balazs dify.ltd@gmail.com

Code Wrangler @ Udacity Trainer @ Tora Trading

Dan Berindei

dan@infinispan.org Software Developer @ Infinispan

3 http://www.jboss.org/infinispan/license 4 https://github.com/cdman/infinispan-exchange

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

NEO4j Graph Database modelarea datelor interconectate

eo4j este o baza de date open-source fondată pe teoria grafurilor, fiind o soluție optimizată pentru a modela și interoga volume mari de date strâns relaționate, reprezentabile prin structuri de tip graf. Dinamismul,creșterea volumului datelor, precum și evolutia continuă a procesării informațiilora impus ieșirea din spațiul bazelor de date relaționale tradiționale și orientarea spre soluții NOSQL. Neo4j face parte din fenomenul NOSQL încadrându-se încategoria bazelor de date de tip graf. O caracteristică unică a acestora este gradul ridicat de adaptibilitate la modelele reale de date.

NOSQL Stores

Atât în cazul bazelor de date relaționale cât și în cazul unor soluțiiNOSQL (nongraph) procesulde modelare / design trece prin două faze : • Definirea conceptelor , a entitățilorși a interacțiunii dintre ele – model logic/ real • Materializarea modelului logic întrun model fizic/abstract ( Ex. În cazul bazelor de date relaționale schemă) De cele mai multe ori modelul logic este foarte diferit de modelul fizic. În cadrul unei organizații software în prima fază poate participa orice echipă nu neapărat tehnică(management / sales ) pentru o mai bună definire a cerințelor sau conceptelor.În cea de a doua fază însă are loc abstractizarea modelului logic în funcție de opțiunea de stocare. Astfel gradul de înțelegere al modelului logic scade odată cu creșterea complexității datelor. Marele avantaj al bazelor de date de tip graf și implicit utilizarea Neo4j este că modelul logic este același cu modelul fizic. Având acest mod de reprezentare uniformă sau astfel spus o reprezentare “human readable” ce oferă un mare grad de flexibilitate

, adaptibilitate și expresivitate în modelarea datelor reale. Limbajul de interogare Cypher Acest tip de bază de date permite o Neo4j are propriul limbaj de interoabordare iterativă putând fi utilizată cu gare a datelor organizate în structuri de succes în strategia de development de tip graf.Este folosit conceptul de “Traversal” Agile. prin intermediul căruia se navighează în graf, se indentifică drumurile și implicit se Reprezentarea datelor în Neo4J selecteză nodurile pentru rezultatul unei În Neo4j datele sunt reprezentate prin interogări. noduri și relații. Atât nodurile cât și relațiile Limbajul Cypher este un limbaj de pot fi avea proprietăți.Relațiile au un rol interogare declarativ fiind foarte intuitiv foarte important în cadrul bazei de date și “human readable”, putând fi înțeles cu de tip graf pentru că traversarea grafului și ușurință chiar și de o persoană non-tehnică. implicit manipularea datelor se realizează Unele cuvinte cheie sunt inspirate din prin intermediul lor. SQL cum ar fi: where, order by , limit, skip O relație implică întotdeauna două (echivalentul offset) noduri, are o direcțieși un tip identificat Limbajul este alcătuind din următoaunic printr-un nume. rele clauze : • START – punctul de intrare în graf. Orice interogare în graf are cel puțin un nod de start, • MATCH –șablonul pentru căutarea În exemplul de mai sus relația nodurilor și care este legat de nodul de “KNOWS” conectează nodurile “Autor 1” start, cu “Autor 2 ” precizând de asemenea pro• WHERE–condițiile de filtrare a prietatea adițională “since”. nodurilor / relațiilor, Relativ la un nod relațiile se pot clasi• RETURN –rezultatul interogării, fica în două tipuri : • CREATE –creează noduri sau relații , • incoming, • DELETE –șterge noduri sau relații, • SET –setează proprietăți noduri sau relații, • FOREACH –update pe liste de • outgoing. noduri, Atât proprietățile unui nod cât și • WITH –împarte interogarea în mai cele aleunei relații pot fi indexate pentru multe părți distincte. îmbunătățirea performanței de traversare a grafului ( similar cu indexarea coloanelor Pentru exemplificare vă propun urmăîn bazele de date tradiționale ). torul graf care reprezintă autorii care Forțând o comparație cu bazele de date publică în TSM relaționați după cum tradiționale, vă puteți imagina un nod ca urmează : o înregistrare dintr-un tabel, iar o relație ca o înregistrare dintr-un tabel de legătură sau o pereche de coloane din același tabel în cazul unei reprezentări tip denormalizat. www.todaysoftmag.ro | nr. 12/Iunie, 2013

programare NEO4j Graph Database - modelarea datelor interconectate [:Interested_in]->(subject4);

Cum observați și mai sus crearea nodurilor și a relațiilor este foarte intuitivă și flexibilă. Exemple de interogări pe graful de mai sus: 1.start n=node(*) match n-[:WROTE]->(a) return n, count(a) (rezultatul va afisa fiecare autor cu numarul de articolo publicate) 2.start magazine=node(*) match magazine<[:Published_in]-(article)<-[:Wrote]-(author)[:Interested_in]->(subject) where magazine. name?=’’TSM’ and subject.subject?=’Java’ return author.name, article; (rezultatul va afisa toate articolele cu subiectul Java impreuna cu numele autorului) 3.start n=node(*)match n<-[:Published_in]-(article) return count(article) ( rezulatul afiseaza numarul de articolo publicate în TSM)

În cazul în careavem milioane de autori și avem cerința de a adăuga o nouă relație ( ex. RATING între un autor și un articol), trebuie doar adăugată relația și funcționalitatea de a conecta autori cu articole se poate realiza. În cadrul unei baze de date relaționale, operațile de modificare de schema sunt de obicei costisitoare și nu neapărat simple. Astfel că se poate spune ca modelul evoluează în mod natural odată cu datele reale și cerințele impuse de business.

SpringData și Neo4j

Graful de mai sus se poate crea cu următoarea instrucțiune Neo4j expune un API Java foarte variat care permite crearea și Cypher : manipularea grafurilor. O alta opțiune este utilizarea platformei REST. Fondatorii CREATE autor1 = { name : ‚Autor1, worksAt : Spring Framework au creat un nou modul adresat bazelor de date ‚Company1’ }, articol1 = { title : ‚Articol1’ }, articol2= { title NOSQL. : ‚Articol2’ }, Numele lui este String Data și are la bază aceeași abstactizare (autor1)-[:Wrote]->(articol1), a interacțiunii cu bazele de date princonceptul “Templates” ( ex. (autor1)-[:Wrote]->(articol2), JDBCTemplate) . revista = { name : ‚TSM’, domain : ‚IT’ , Ca analogie, la fel cum interacțiunea cu SQL se realizează prin poweredBy:’Gemini Solutions’}, hibernate, interacțiunea cu Cypher se realizează prin Spring Data (articol1)-[:Published_in {date:’2013} ]->(revista), Neo4j support. autor2 = { name : ‚Autor2, worksAt : ‚Company2’ }, articol3 = { title : ‚Articol3’ }, (autor2)[:Wrote]->(articol3)}, autor3 = { name : ‚Autor3, worksAt : ‚Company3’ }, articol4 = { title : ‚ Articol4’ }, (autor3)[:Wrote]->(articol4)} (autor2)-[:Knows]->(autor3), subject1 = { subject : ‚ Spring Framework’ }, subject2 = { subject : ‚ NOSQL },

subject3 = { subject : ‚ Agile’ },subject4 = { subject : ‚ Android’}, (autor1)-[:Interested_in]->(subject1), (autor1)[:Interested_in]->(subject3), (autor2)-[:Interested_in]->(subject2),(autor3)-

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

Iulian Moșneagu

iulian.mosneagu@geminisols.ro Senior Software Engineer @ Gemini Solutions

programare

TODAY SOFTWARE MAGAZINE

Hadoop (II)

n ultimul număr am descoperit lumea pe care Hadoop o formează și care este secretul prin care putem să stocăm zeci și chiar sute de TB fără nici un fel de probleme. Aceasta se bazează pe un sistem de tip master-slave extrem de simplu, dar care funcționează foarte bine.

Oriunde este nevoie de Hadoop, se impune prezența unui nod numit: NameNode. Acest nod reprezintă nodul de tip master, stocând locația tuturor fișierelor din sistem. El este singurul nod care poate să identifice locația unui fișier pe baza numelui. În jurul acestui nodexistă DataNode-uri, care stochează conținutul fișierelor.

Procesarea datelor

Faima Hadoop-ului vine de la procesarea datelor și extragerea informațiilor de care avem nevoie. În următoarele rânduri vom descrie mecanismul acestei performanțe. Un prim element este MapReduce. Această paradigmă nu a fost inventată de către Hadoop, dar a ajuns să facă acest lucru cel mai bine. La prima întâlnire cu MapReduce avem senzația că este complicat, dar odată înțeleasă, această paradigmă ne ajută foarte mult. Totodată, nu încercați să folosiți Hadoop dacă nu ați înțeles MapReduce în totalitate. Fără să înțelegem MapReduce nu putem ști ce anume vrem să cerem de la Hadoop și la ce rezultate să ne așteptăm.

MapReduce și Tupluri

În comparație cu un sistem care stochează datele în tabele, să nu vă așteptați ca Hadoop să fie similar. Acesta știe să lucreze cu date sub forma unui tuplu – o pereche de tip (cheie, valoare). Fiecare task pe care Hadoop trebuie să îl execute are ca input tupluri de tip (cheie, valoare), iar rezultatul pe care îl obținem de la un task are aceeiași formă de tip (cheie, valoare). Deși pare destul de banal, vom vedea că nu este nevoie de mai mult decât atât pentru a putea obține datele dorite.

Map

Map se referă la procesul prin care datele pe care dorim să le procesăm sunt convertite la un nou set de date. Datele pe care le obținem după acest pas sunt doar niște date intermediare care în starea în care sunt nu pot fi folosite. Operația de tip Map nu se execută doar pe un singur nod în cadrul sistemului. Această acțiune va fi executată pe mai multe noduri de tip DataNode. Fiecare DataNode va genera un rezultat intermediar. Din punct de vedere a cantității de date care se generează după procesul de Map, aceasta este mult mai mică în comparație cu datele originale. Ne putem imagina că după acest pas, Hadoop ne generează un sumar a datelor noastre în funcție de parametri de care noi suntem interesați. Este important să știm că datele intermediare pe care le obținem nu trebuie să aibă același format ca și datele de input. În momentul de față, cheile ajung să fie partiționate pe baza unei funcții – în general o funcție de hash. Odată ce procesul s-a finalizat cu succes, Hadoop poate să execute diferite operații peste ele, precum sortarea, separarea sau shuffle – această funcționalitate este destul de nouă, circa un an. Acești pași pregătesc datele intermediare pentru următorul pas. Atenție, acest pas se execută și în cadrul operației de Reduce. Din punct de vedere al paralelismului, pe fiecare nod unde se execută operația de tip Map, putem să avem de la 10 până la 100-150 de operații. Totul depinde de cât de performante sunt nodurile cu care lucrăm.

Procesul de MapReduce este format din două părți total separate – Map și Reduce. Reduce

Odată ce avem datele intermediare, putem să le procesăm pentru a obține datele finale, de care suntem interesați. Până în acest moment puteam executa operațiile de tip Map pe fiecare din nodurile din cluster care conțineau datele noastre. Operația Reduce se va executa doar pe un număr limitat de noduri. Datele sunt partiționate pentru fiecare Reducer în parte. Dacă operația de Map era formată dintr-un singur pas, operația de Reduce este formată din 3 pași separați • Shuffle, • Sort, • Reduce. În momentul în care se face shuffle, datele de la nodurile care au fost implicate în procesul de Map sunt trimise la nodurile care urmează să execute următorul pas. Acest lucru se face folosind o conexiune HTTP. Din cauză că suntem într-o rețea privată, nu trebuie să ne facem probleme din punct de vedere al securității. Toate tuplurile care sunt trimise, sunt apoi sortate pe baza cheii. Acest lucru este necesar deoarece putem avea aceleași chei de la diferite noduri. În general, procesul de sortare se execută simultan cu procesul

www.todaysoftmag.ro | nr. 12/Iunie, 2013

management

programare Hadoop (II) de shuffle. Odată ce operația de shuffle s-a finalizat, Hadoop va mai executa încă o sortare. În acest moment putem să controlăm modul în care datele să fie grupate și chiar să facem o sortare intermediară după diferiți parametri. Operația de sortare este o operație care se execută atât pe disk cât și în memorie. Ultima operație care a mai rămas de executat este reduce. În momentul în care această operație se execută, rezultatele finale vor fi scrise pe disk. La acest pas fiecare tuplu este format dintr-o cheie și o

îl are este să facă scheduling și să monitorizeze fiecare acțiune. În cazul în care una din operații nu se termină cu succes, JobTracker va reprograma această operație. JobTracker-ul discută în permanență cu NameNode-ul și are grijă ca operația care trebuie să se execute să fie pe același DataNode sau cel puțin în același rack în care datele pot fi găsite. TaskTracker-ul este un nod care acceptă operații de tip Map, Reduce sau Suffle. Acesta poate să fie DataNode-ul unde datele sunt stocate, dar acest lucru nu este obligatoriu. Fiecare TaskTracker are un număr limitat de joburi pe care le poate executa (slot). Din această cauză JobTracker-ul va căuta întotdeauna TaskTracker-ul care are cât mai multe slot-uri libere. Un lucru destul de interesant care a fost făcut pe TaskTracker este modul în care fiecare job se execută. Acesta se execută într-un proces JVM separat. Prin acest mod în cazul în care apare o eroare, aceasta nu va fi propagată la toate job-urile care rulează pe TaskTracker-ul curent.

colecție de valori. Din această colecție de valori operația de reduce va selecta valoarea finală. Deși pasul de reduce este extrem de important, pot să existe cazuri când nu dorim să facem acest lucru. În astfel de cazuri, putem să specificăm că rezultatul obținut după Map să fie scris direct pe disk și să fie considerat rezultat final.

Până în acest moment am prezentat din punct de vedere teoretic cum MapReduce funcționează. Vă propun ca în următoarea parte a articolului să analizăm peste un exemplu practic. În acest mod ne va fi mult mai simplu și ușor să înțelegem ce se întâmplă cu adevărat. Vom porni de la următoarea problemă. Avem sute de fișiere ce conțin date despre numărul de accidente din fiecare județ din România care s-au întâmplat în fiecare lună. Am ajuns la un număr foarte mare deoarece există nenumărate firme de asigurare, iar fiecare firmă de asigurare are una sau mai multe centre regionale. Din această cauză fiecare fișier poate să conțină mai multe date despre același oraș. Un fișier ar putea avea următoarea formă: Cluj, Ianuarie 2013, 20

JobTracker, TaskTracker

Operația de tip MapReduce implică două tipuri de servicii care poartă numele de JobTracker și TaskTracker. Acestea două sunt într-o relație de tip master-slave, extrem de asemănătoare cu cea pe care am văzut-o la nivelul modului în care datele sunt stocate – NameNode și DataNode. Scopul principal pe care JobTracker

Exemplu

Sibiu, Ianuarie 2013, 10 Brașov, Ianuarie 2013, 3 București, Ianuarie 2013, 100 Cluj, Mai 2013, 50 Brașov, Iulie 2013, 18 … Se cere să calculăm numărul maxim de accidente care a avut loc în fiecare oraș în decursul unei luni. Această problemă devine destul de greu de rezolvat dacă avem 500 GB de date. În acest caz, Hadoop ne poate ajuta. Prima operație pe care MapReduce o face este cea de Map. În acest moment din fiecare fișier vom putea obține o colecție de tip (cheie, valoare). Pentru noi cheia va reprezinta orașul, iar valoarea va indica numărul de accidente. Din fiecare fișier dorim să extragem numărul maxim de accidente per oraș. Pentru exemplul dat mai sus rezultatul pe care l-am putea obține ar avea următoarea formă (Cluj, 50) (Sibiu, 10) (Brașov, 18) (București, 100) Din alte fișiere vom obține și alte date. Dacă punem toate aceste date împreună (operația de shuffle) am avea următorul rezultat intermediar (Cluj, 13), (Brașov, 20), (Cluj, 40), (Sibiu, 2), (Cluj, 50), (Sibiu, 10), (Brașov, 18), (București, 100), (Sibiu, 8) … Peste acest rezultat intermediar putem să aplicăm operația de Reduce, care ar genera rezultatul final – numărul maxim de accidente din fiecare oraș. La final obținem următorul rezultat (Cluj, 50) (Brașov, 20) (Sibiu, 10) (București, 100)

Concluzie

D up ă c u m a m put ut o b s e r v a , MapReduce este o operație simplă, care se bazează pe împărțirea unui task în operații cât mai mici care să poată să fie rulate în paralel. Odată ce fiecare operație a fost executată pe o parte din date, rezultatele intermediare obținute sunt aduse în forma finală. Limbajul nativ pentru Hadoop este Java, dar există suport pentru folosirea sa împreună cu alte limbaje precum Python, C# și chiar și PHP. Radu Vunvulea

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

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

programare

TODAY SOFTWARE MAGAZINE

Programare Funcțională în Haskell (II)

Mihai Maruseac

mihai.maruseac@gmail.com IxNovation @ IXIA membru ROSEdu, ARIA

rticolul din numărul trecut a realizat o scurtă introducere în limbaj prezentând mai mult istoria și beneficiile lui și mult mai puțin elemente de cod propriu-zis. Astăzi, ne apropiem de acest deziderat discutând despre tipurile limbajului. Un lucru absolut definitoriu pentru limbaj este faptul că Haskell are tipare statică: fiecare expresie are un tip cunoscut de la compilare. În plus, nu există conversii implicite între tipuri similare: programatorul va trebui să facă explicit conversiile în locurile în care acestea sunt necesare. Dar, să începem lent, cu începutul. Primul lucru pe care-l vom menționa că, spre deosebire de C, Java și alte limbaje similare, tipurile nu sunt o pacoste: descrierea lor este opțională. Puteți scrie foarte mult cod fără a scrie o singură definiție de tip. Compilatorul și interpretorul vor apela la modulul de sinteză de tip pentru a infera tipurile cele mai generale pentru codul scris. Pe de altă parte, este bine să cunoaștem tipurile expresiilor și să programăm folosindu-ne de aceste informații, după cum se va vedea în continuare. Cel mai simplu tip este cel al expresiilor booleene, True și False. Atenție! Aceste valori se scriu cu literă mare și vom vedea în acest articol de ce. Tipul acestor două valori este Bool. Ca o regulă, tipurile în Haskell se scriu cu literă mare. Este o convenție cu o anumită logică pe care o vom vedea imediat. Mergem acum la tipurile numerice. Pentru început, numerele întregi. Aici avem un lucru interesant. Valoarea 7 poate fi de tip Int sau de tip Integer. Diferența între ele este de nivel semantic/implementare: tipul Int este limitat de registrele și arhitectura sistemului în timp ce tipul Integer presupune folosirea bibliotecii pentru numere de înaltă precizie – se vor putea reprezenta numere oricât de mari.

Pentru numerele reale, avem tipurile Float și Double, exact ca în C. Poate vă întrebați acum cum se face conversia între Int și Integer. Să zicem că aveți o funcție f ce primește un argument de tip Int și aveți o expresie x de tip Integer. Nu veți putea realiza direct apelul f x deoarece cele două tipuri nu se potrivesc și compilatorul va arunca o eroare. Din fericire, există funcția toInteger ce va realiza conversia argumentului la un rezultat de tip Integer. Așadar, apelul va fi f (toInteger x) sau, dacă vrem să eliminăm ceva paranteze folosind operatorul $, vom ajunge la apelul f $ toInteger x. Este foarte probabil ca acum tipărirea statică să vi se pară problematică și greu de folosit. Este necesară puțină experiență cu limbajul până când vă veți obișnui cu aceste mici inconveniențe și veți observa de ce sunt ele necesare și cum vă pot scuti de multe erori. În continuare, vom analiza tipuri mai complexe. După cum ați citit și în articolul trecut, există tipul listă de elemente de tip a, [a]. Observați că tipul este scris cu literă mică, avem de fapt o variabilă de tip ce poate fi instanțiată pentru fiecare caz particular. De exemplu, lista [1,2,3] este de tipul [Integer] (notația pentru această frază fiind [1,2,3] :: [Integer]). Revenind la

www.todaysoftmag.ro | nr. 12/Iunie, 2013

programare

programare Programare Funcțională în Haskell (II)

notația tipului listă, [a], observăm imediat și restricția ca toate elementele unei liste să fie de același tip, a. În final, tipul standard al șirurilor de caractere, String, nu este altceva decât o listă de caractere (Char): [Char]. În final, ultimul tip de bază al limbajului este tipul tuplu. Un tuplu de două elemente are tipul (a, b), un tuplu de 5 elemente are tipul (a, b, c, d, e). Observați imediat că fiecare element al tuplului poate avea un tip diferit. Astfel, putem avea atât (“ana”, “mere”) :: (String, String) cât și (“ana”, 42) :: (String, Integer). Ca un caz particular, există și tuplul cu zero elemente, (), având o singură valoare () :: (). În final, cum orice expresie din Haskell are un tip, rezultă că putem vorbi și de un tip pentru o funcție. Acesta ne dă informații despre ce valori de intrare sunt acceptate și ce fel de valori sunt returnate. În unele cazuri, tipul funcției ne dă și detalii despre ce face funcția, funcționează ca o documentație. De exemplu, o funcție f :: a -> a ne zice ca primește un argument de orice tip și întoarce un rezultat de fix același tip. Dacă ne limităm la funcțiile care se termină (excludem cazurile de forma f x = f x), nu dau eroare (fără f x = undefined sau f x = error ...) și nu sunt complicate inutil (excludem și f x = head [x, f x, f (f x)]) obținem o singură expresie validă pentru f: funcția identitate. Așadar, pornind de la tipul acesteia putem deduce imediat ce semantică are, fără a ne uita în implementare. Desigur, nu putem deduce totul din tipuri, cel puțin nu la nivelul celor prezentate până acum. Cazul funcțiilor cu mai multe argumente este interesant de studiat. De exemplu, funcția addBothWith2 x y = x + y + 2

are tipul Integer -> Integer -> Integer (de fapt, tipul real este puțin mai complex dar vom reveni asupra lui spre finalul articolului). Fiecare argument este separat de următorul în semnătura de tip prin ->. De ce această semnătură? Pentru a captura un aspect interesant al programării în Haskell: putem transmite funcțiilor un număr mai mic de argumente decât este cerut și obținem înapoi o funcție nouă. În teorie se zice că funcțiile în Haskell sunt curry (după numele lui Haskell Curry) și acest lucru este posibil doar pentru că funcțiile sunt valori de prim ordin (nu există nici o diferență între a-i trimite fucției identitate un număr sau o funcție, de exemplu). Întorcându-ne la funcția addBothWith2 de mai sus observăm că

addBothWith2 3 are tipul Integer -> Integer. Așadar, Integer -> Integer -> Integer și Integer -> (Integer -> Integer) sunt expresii similare. Pe de altă parte, (Integer -> Integer) -> Integer reprezintă semnătura unei funcții ce primește ca argument o funcţie de la întreg la întreg și întoarce un rezultat. Un exemplu ar putea fi următoarea funcție: applyTo42 f = f 42

pe care dacă o apelăm cu (+1) vom obține 43 iar dacă o apelăm cu (addBothWith2 3) vom obține 47. Având toate aceste elemente putem scrie orice program dorim. Doar că dacă ne limităm doar la tipurile prezentate nu vom obține nici un beneficiu de pe urma tipării statice din Haskell, ba chiar vom avea și ceva probleme. De exemplu, există funcții predefinite doar pentru tuplurile cu două elemente. Pentru toate celelalte va trebui să scriem noi de mână funcții pentru accesarea și modificarea elementelor componente. Din fericire, limbajul Haskell ne permite să ne construim tipuri proprii pentru a avea un program mai expresiv, mai declarativ. Le vom menționa pe toate în acest articol. Pentru început, am afirmat mai sus că tipul String este de fapt un sinonim pentru tipul [Char]. Este mult mai usor de citit un cod care folosește [String] versus un cod care folosește [[Char]]. Idem, este mult mai comod să lucrați un program care are Vector2D, Point2D, Size față de un program care folosește (Integer, Integer) pentru toate trei valorile. În Haskell, putem declara orice sinonim de tip folosind type. De exemplu, tipul String este definit astfel: type String = [Char]

Compilatorul lucrează în spate cu tipul original. Doar anumite semnături de tip vor folosi sinonimul. Și programatorul îl poate folosi oriunde în program. Pentru a construi un tip nou folosim data. Tipurile noi în Haskell se definesc pe baza constructorilor: pur și simplu listăm fiecare constructor împreună cu argumentele necesare lui. De exemplu, următorul cod listează definiția exactă a tipului Bool. data Bool = True | False

toți constructorii unui tip se scriu cu literă mare și numai ei. Un tip ceva mai complex este tipul Maybe. El ne permite să avem o valoare sau posibilitatea de a semnaliza faptul că funcția a ajuns într-un caz de eroare. Astfel, suntem salvați de la a obtine un null-pointer-exception la runtime: programatorul va trebui să trateze ambele cazuri în funcțiile scrise de el. data Maybe a = Just a | Nothing

Observați că tipul este generic: primește ca argument un alt tip sub forma variabilei de tip a. Unul dintre constructori folosește acest tip pentru a împacheta valoarea. Putem avea deci tipul Maybe Int sau tipul Maybe (Maybe String), fiecare cu semantica proprie. Dezavantajul folosirii tipului Maybe este că în cazul în care funcția eșuează nu se poate salva și motivul eșecului. Din fericire, există și tipul Either, definit ca data Either a b = Right a | Left b

Despre aceste tipuri și cum le vom folosi într-un cod real vom mai discuta în viitor. Se poate întâmpla ca uneori numărul de câmpuri din constructor să fie foarte mare. Sau, se poate întâmpla să avem nevoie să accesăm anumite câmpuri din interiorul tipului. Din fericire, există o notație specială: data Person = P { nume :: String, prenume :: String, varsta :: Int}

Ca rezultat, nu numai că se creează tipul de date Person și constructorul P :: String -> String -> Int -> Person, dar avem acces și la funcțiile nume :: Person -> String, prenume :: Person -> String și varsta :: Person -> String. Ca reprezentare internă, tipurile definite cu data necesită zone de memorie pentru a salva valoarea constructorului și fiecare parametru în parte. Acest lucru este ineficient pentru cazul în care tipul are un singur constructor și acesta are un singur argument. Este cazul în care am putea folosi un sinonim de tip, dar am vrea să profităm în totalitate de inferența de tip (pe care o putem obține în întregime doar folosind tipuri cu constructori proprii). Din fericire, Haskell are și a treia metodă de a defini tipuri noi: folosim newtype.

Tipul are doi constructori, numiți True State s a = S { runState și False. De fapt, cei doi constructori sunt newtype :: s -> (s, a) } exact cele doi valori ale tipului. Putem enunța acum în întregime regula legată de Putem afla tipul oricărei expresii în capitalizarea atomilor din sintaxa Haskell, ghci, folosind :t expresie. De exemplu: :t map la nivelul valorilor (pentru nivelul tipuri- Prelude> map :: (a -> b) -> [a] -> [b] lor trebuie să mai introducem un concept):

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

programare De unde deducem imediat că map va aplica funcția pe o listă și va întoarce lista rezultatelor. Putem să mai aflăm tipul unei expresii consultând lambdabot pe #haskell (canal de IRCpe Freenode) sau via Hoogle1. De fapt, Hoogle ne ajută și în căutarea inversă: putem căuta după tipul aproximativ al unei funcții, să zicem String -> Int -> Char și vom ajunge prin pagina de rezultate2 la (!!) :: [a] -> Int -> a, funcția care ne întoarce elementul de pe o anumită poziție din listă. Ca exercițiu pentru astăzi, vom simula un program de manipulat baze de date. Momentan vor realiza doar o căutare în una din cele trei tabele ce reprezintă informații despre oameni. Începem prin a defini câteva sinonime de tip, pentru a înțelege codul mai ușor: type type type type

Name = String Age = Int Address = String PhoneNumber = Integer

Definim acum tipurile pentru cele trei tabele de intrare: newtype [(Name, newtype [(Name, newtype [(Name, Show

NameAgeTable = NAgT Age)] deriving Show NameAddressTable = NAdT Address)] deriving Show NamePhoneTable = NPT PhoneNumber)] deriving

Am folosit newtype și tupluri pentru eficiența reprezentării și pentru a avea inferență de tipuri. Partea deriving Show este necesară pentru a putea afișa valorile de aceste tipuri (o vom prezenta în amănunt data viitoare). Să construim acum câteva valori pentru cele trei tabele pe care le folosim: nameAge = NAgT [(„Ana”, 24), („Gabriela”, 21), („Mihai”, 25), („Radu”, 24)] nameAddress = NAdT [(„Mihai”, „a random address”), („Ion”, „another address”)] namePhone = NPT [(„Ana”, 2472788), („Mihai”, 24828542)]

După cum observați, am avea nevoie 1 http://www.haskell.org/hoogle/ 2 h t t p : / / w w w . h a s k e l l . o r g / hoogle/?hoogle=String+-%3E+Int+-%3E+Char

TODAY SOFTWARE MAGAZINE de o funcție de căutat în listele respective: căutăm perechea al cărei prim element este Acum, să căutăm în tabele: un nume dorit și ne interesează al doilea *Main> searchNameAge „Ion” nameAge element al perechii. Desigur, am putea Nothing *Main> searchNameAge „Mihai” să scriem noi o funcție recursivă pentru nameAge aceasta dar este un exercițiu interesant să Just 25 *Main> searchNameAddress „Mihai” folosim Hoogle. Dacă am căuta o funcție nameAddress [(String, a)] -> String -> Maybe a nu vom Just „a random address” *Main> searchNameAddress „Gabrigăsi nici un rezultat (am generalizat doar ela” nameAddress tipul celui de-al doilea element din tuplu). Nothing *Main> searchNamePhone „Gabriela” În schimb, dacă vom generaliza ambii para- namePhone metri și vom căuta [(a, b)] -> a -> Maybe b Nothing *Main> searchNamePhone „Mihai” primul rezultat din listă este funcția lookup namePhone 3 (ignorați momentan partea Eq a => din Just 24828542 semnătură, o vom trata tot data viitoare). Vom continua data viitoare aplicația Putem scrie acum imediat funcțiile de pentru a realiza și operații de tip join pe căutat în cele trei tabele: aceste tabele. După cum vedeți, folosirea tipurilor ne searchNameAge name (NAgT l) = ajută dar ne și încurcă. Depinde foarte mult lookup name l searchNameAddress name (NAdT l) = de programator să aleagă varianta corectă lookup name l de design. După ce tipurile au fost puse în searchNamePhone name (NPT l) = lookup name l scenă, compilatorul devine mai mult sau mai puțin (în funcție de design) un aliat și După cum observați, în partea dreaptă ne ajută să avem cât mai puține bug-uri la a egalului am folosit exact aceeași expresie. runtime. Vom vedea data viitoare cum se realizează Data viitoare ne vom ocupa tot de tipuri apelul potrivit, conversia potrivită pentru dar dintr-o perspectivă mai interesantă: tipul așteptat și cum putem reduce codul vom vedea cum este implementat poliși mai mult, fiind fideli principiului DRY morfismul și cum putem captura șabloane (don’t repeat yourself). comune la nivelul tipurilor. Pentru astăzi, ne mai rămâne doar să testăm funcțiile scrise. Pentru început, priviți cum compilatorul ne anunță imediat ce folosim o tabelă nepotrivită: *Main> searchNameAge „Ion” nameAddress <interactive>:21:21: Couldn’t match expected type `NameAgeTable’ with actual type `NameAddressTable’ In the second argument of `searchNameAge’, namely `nameAddress’ In the expression: searchNameAge „Ion” nameAddress In an equation for `it’: it = searchNameAge „Ion” nameAddress 3 h t t p : / / w w w . h a s k e l l . o r g / hoogle/?hoogle=[(a,+b)]+-%3E+a+-%3E+Maybe+b

www.todaysoftmag.ro | nr. 12/Iunie, 2013

programare

Planificarea Testării de Performanţă

n acest articol aş dori să vă prezint o scurtă introducere în planificarea Testării de Performanţă, precum și în planificărea colectării și analizării rezultatelor prin prisma experienţei mele în acest domeniu. Voi porni de la prezumţia că cititorul are cunoştinţe despre terminologia folosită în Testarea de Performanţă. În cadrul articolului voi face referire la unele metrici folosite, cerinţe Non-funcţionale pe care le voi folosi ca exemple. poate face într-un document separat sau c. Ramp-down – este timpul neceîntr-un capitol ca parte a Test Plan-ului sar utilizatorilor să termine acţiunile şi proiectului. încărcarea serverului să înceteze Definiţia ISTQB pentru Testarea de De obicei se iau în considerare urmăPerformanţă este “procesul de testare prin toarele aspecte în planificarea Testării de B. Momentul rulării testelor de perforcare se determină performanţa unui produs”. Performanţă: manţă în timpul dezvoltării produsului este Cu alte cuvinte scopul nostru este de a afla important. Rularea testelor de performanță cât de bun este un produs software, cât de Cerinţele e bine să fie făcută când majoritatea funcrapid, câţi useri poate să susţină precum și Este cel mai important aspect alături de ţionalităţilor sunt implementate şi sunt timpul de răspuns pentru fiecare dintre ei, tehnologia folosită în dezvoltarea produsu- stabile (un procent de 80% minim). Dacă sau care sunt limitele produsului. lui. Necesarul de tool-uri este de asemenea funcţionalitatea nu este finalizată în mare Rezultatele obţinute în urma testelor determinat pe baza cerinţelor şi a tehnolo- parte, rezultatele testelor pot fi irelevante. de performanţă vor ajuta factorii de decizie giei folosite. Cerinţele Non-funcționale vor Orice schimbare majoră a codului va afecta din Business să ia o decizie informată cu conţine cifrele exacte pentru timpul de răs- rezultatele testelor de performanţă şi comprivire la lansarea unui produs. puns, număr de acţiuni concurente. pararea rezultatelor rulărilor succesive Testarea de performanţă va oferi infora testelor de performanţă nu va putea fi maţii despre cum se va comporta produsul Resursele umane necesare făcută. Se pot rula teste de performanţă pe în utilizarea zilnică, cu acces concurent din Skill-urile necesare pentru designul, funcţionalităţi separate sau servicii atunci partea utilizatorilor. Rezultatele vor folosi scrierea și executarea testelor de perfor- când acea funcţionalitate se poate testa în estimarea resurselor hardware nece- manţă trebuie analizate cu grijă. Consider independent. Astfel, rezultatele oferă un sare pentru a susține un anumit număr de Testarea de Performanţă ca un efort de feedback continuu și relevant asupra perutilizatori. echipa în care trebuie sa fie implicaţi formanţei sistemului. E bine să se planifice Există câteva categorii de Teste de arhitecţii și programatorii. Expertiza arhi- testarea de performanţă în mod continuu, Performanţă, fiecare având particularităţi tecţilor în arhitectura produsului este de mai ales în contextul Agile, când se livrează în ceea ce priveşte scopul, planificarea și folos în design-ultestelor care vor desco- funcţionalitate completă în fiecare Sprint execuţia: peri vulnerabilităţile sistemului, pe când sau un număr relative mic de Sprint-uri. • Load – al cărui scop este de a vedea expertiza developerilor este folositoare în În timpul unui release, testele de percomportamentul sistemului când un scrierea script-urilor. De asemenea trebuie formanţă se rulează de un număr limitat anumit număr de utilizatori îl foloseşte să participe în analiza rezultatelor pentru de ori datorită timpului necesar rulării lor simultan o mai bună înţelegere a comportamentului și resurselor hardware necesare. Rularea • Stress – al cărui scop este de a deter- sistemului şi a acţiunilor coercitive ?. testelor, analiza rezultatelor și fixurile sunt mina limitele și robusteţea sistemului realizate într-un ciclu iterativ. • Soak – al cărui scop este de a deter- Design-ultestelor și execuţia lor O altă abordare în obținerea informamina comportamentul sistemului pe o A. Testele de performanţă sunt conce- ţiilor despre performanţa unui sistem este perioadă mai mare timp în care un anu- pute să acopere cerinţele non-funcționale cu de a adăuga listener-i în Unit test şi în tesmit număr de utilizatori îl foloseşte scenarii reflectând situaţii reale. Scenariile tele de API. Astfel se vor obține informaţii folosite de mine au ca părți componente despre cât de performante sunt anumite Cum planificăm Testarea de importante următoarele: metode/fluxuri. Performanţă? a. Ramp-up – este timpul necesar ca Ca orice fel de testare, Testarea de toți utilizatorii să fie gata pentru a exeC. Colectarea rezultatelor și raportarea Performanţă trebuie planificată cu grijă. cuta acţiunile testului (de exemplu să fie Setul de rezultate colectate în cursul Cerinţele, resursele necesare, crearea scelogati şi să înceapă să ruleze acţiunile) testelor de performanţă trebuie definit cu nariilor și rularea lor, colectarea și analiza b. Distribuţia încărcării şi a acţiunilor grijă şi să fie minimalist pentru rezultatelor, raportarea rezultatelor, toolîn timp – scenariile apropiate de realitate • a colecta rezultatele relevante. Toolurile necesare sunt câteva dintre artefactele vor fi create având în vedere tipurile de urile pentru teste de performanţă oferă o de luat în considerare. utilizatori ai aplicaţiei şi acţiunile pe care larga varietate de rezultate ce pot fi colecPlanificarea Testării de Performanţă se le pot face fiecare dintre ei tate în special în ceea ce priveşte timpul

Ce este testarea de performanţă și de ce avem nevoie de ea?

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE de răspuns. Resursele hardware pot fi monitorizate prin intermediul acestor tool-uri sau instalând tool-uri de monitorizare direct pe sistemul aflat în test • a nu colecta prea multe rezultate. Colectarea prea multor rezultate va avea impact atât asupra maşinii pe care rulează tool-ul de testare, consumând din resursele necesare susţinerii load-ului cât şi a resurselor de pe sistemul aflat în test afectând numărul de acţiuni executate Voi prezenta o lista cu rezultatele pe care obişnuiesc să le colectez: • Timpul de răspuns. Analizând timpii de răspuns se pot observa spre exemplu peak-urile, care pot fi corelate cu gradul de utilizare a resurselor hardware ale sistemului aflat în teste • Timpul de răspuns minim și maxim • Timpul de răspuns mediu. Pe lângă timpul de răspuns mediu este relevant să se vadă câte acţiuni au fost realizate în mai puţin timp sau mai mult decât timpul mediu de răspuns. Este important câţi timpi de răspuns au fost foarte lungi. Procentele (90, 95, 99) sunt folosite pentru a afla numărul de acţiuni ale căror timp de răspuns au fost 90%, 95%, 99% cele mai încete pe o scara de la cel mai mic la cel mai mare timp de răspuns • Throughput: câte acţiuni concurente poate să susţină sistemul. Acest rezultat este important și ajută în determinarea resurselor hardware ale sistemul de

producţie • Erori: rata de eroare va arăta câte acţiuni şi din ce cauza nu s-au încheiat cu succes. Analiza erorilor va releva dacă sistemul nu poate susţine o anumită încărcare şi dă time-out. • Consumul resurselor hardware (CPU, memorie, disk, retea). Load-ul trebuie făcut până la un consum de 85% din resursele hardware ale sistemului testat astfel încât să se poată interveni şi opri testul de performanţă înainte ca sistemul să devine inoperabil.

c. Rapoartele oferite. Evaluarea tool-urilor gratuite sau ale celor oferite de producătorii de tool-uri de performanţă trebuie făcută având în vedere contextul proiectului şi a cunoştinţelor existente în echipa. Pentru anumite tool-uri va fi nevoie de cunoştinţe de programare pentru a rula scenarii complexe (cum ar fi JMeter), pe când alte tool-uri (cum ar fi LoadRunner) oferă aceasta funcţionalitate.

Concluzii

Voi prezenta câteva concluzii din expeD. Raportarea: Rapoartele testelor de rienţa mea utile unei planificari cât mai performanţă vor prezenta eficienţa sistemu- eficientă a testării de performanţă: lui cu privire la cerinţele Non-funcţionale. • Planificarea și execuţia testării de Următoarele detalii, dar nu şi singurele, performanţă ar trebui să fie un efort sunt parte ale raportului asupra testelor de comun al echipei de proiect incluzând performanţă: software arhitecţi și developeri. a. Detaliile legate de sistemul testat, • Importanţa capabilităţilor tool-uriIP, detalii despre hardware-ul folosit, lor şi a skill-urilor necesare nu trebuie Sistemul de Operare, topologia de reţea, neglijată build-ul folosit, data; b. Scenariile rulate și scopul fiecăruia dintre ele; c. Tool-urile de performanţă folosite; d. Măsurătorile efective.

Tool-uri Alegerea tool-urilor folosite pentru testarea de performanţă va avea în vedere următoarele criterii: a. Suportul oferit în rularea scenariilor complexe; b. Capacitatea de distribuire a incărcării şi profilurilor utilizatorilor;

Alexandru Cosma

alexandru.cosma@isdc.eu Senior Tester @ iSDC

www.todaysoftmag.ro | nr. 12/Iunie, 2013

programare

Recenzia cărții: Eclipse Rich Client Platform de Jeff McAffer, Jean-Michel Lemieux şi Chris Aniszczyk

Silviu Dumitrescu silviu.dumitrescu@msg-systems.com Consultant Java @ .msg systems Romania

artea pe care v-o supun atenţiei face parte din acea serie de cărţi care au un impact imediat asupra cititorului. Accentul este pus pe latura practică. Conceptele teoretice sunt introduse gradual, de la noţiuni cu caracter general până la lucruri de fineţe şi best practices,dar particularitatea cărţii constăînfaptul că ele sunt integrate imediatîntr-o aplicaţie care are numeroase funcţionalităţi şi care este, la rândul ei, dezvoltată treptat pe tot parcursul materialului. Din acest motiv, timpul scurs în prezentarea conceptului teoretic, implementarea şi evidenţierea utilităţii sale se scurtează semnificativ. Astfel, nu mai suntem puşiînsituaţia de a citi despre un concept, pe care îl înţelegem mai mult sau mai puţin, apoi o aplicaţie relativ dummy ce îl implementează şi după mult timp, dacă există, o aplicaţie ce integrează conceptele abordate. Deşi foarte populară ca temă, aplicaţia Hyperbola prezentată în această carte, este, practic, transpunerea utilizând Eclipse RCP a unui serviciu de mesagerie, cu funcționalităţi clasice: stabilirea unui grup de prieteni, comunicarea propriu zisă între ei, history şi multe altele. Aplicaţia se constituie ca un model de aplicaţie ce foloseşte RCP, dar şi ca sursa de inspiraţie pentru părţi componente ale unor alte aplicaţii RCP. Pe lângă implementarea propriu zisă penultimul capitol al cărţii prezintă şi o modalitate de structurare, împachetare şi livrare a aplicaţiei, astfel încât să putem crea sisteme dinamice ce rulează pe o mare varietate de sisteme de operare. Am început destul de abrupt prezentarea cărţii Eclipse Rich Client Platform, având ca autori pe Jeff McAffer, JeanMichel Lemieux şi Chris Aniszczyk, în dorinţa de a atrage cât mai mulţi cititori. Pe lângă stârnirea interesului pentru tehnologia prezentată, cartea aduce şi plusul de aplicabilitate şi înţelegere imediate. Clienţii rich (sau fat) pot fi destul de mult asemănaţi cu aplicaţiile stand alone, ce folosesc în comun resurse la distanţă (spre exemplu baze de date). Ei se deosebesc de clienţii thin (care au drept client browser-ul) prin aceea ca folosesc puternic resursele hard şi soft ale calculatorului

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

client pe lângă, eventual, resurse accesate de la distanţă. Probabil cea mai mare problemă în cazul clienţilor thin era dată de faptul că instalările şi modificările trebuiau să ţină cont de configuraţia hard a calculatorului pe care rula aplicaţia. Cum ştim foarte bine că numărul acestor configuraţii este foarte mare, dificultăţile erau o provocare greu de rezolvat. Totuşi existau şi multe avantaje, printre acestea: posibilitatea de a lucra offline (fără o conexiune permanentă la o reţea) sau performanţe multimedia sporite. După părerea mea acest gen de clienţi a fost foarte greu de dezvoltat cu calităţi arhitecturale bune, până la apariţia framework-urilor. Framework-urile au venit în sprijinul dezvoltatorilor de soft oferind cadre de dezvoltare ce urmăreau cele mai bune practici. Evoluţia tehnologică a dus apoi la apariţia platformelor, care erau colecţii de framework-uri precum şi de arhitecturi hard ce permiteau soft-ului să ruleze. Primele platforme rich client ofereau doar atât: o posibilitate de rulare a logicii unei aplicaţii într-un sistem de operare. Astăzi platformele oferă mult mai mult: un model de componentă numit şi plugin (uşor de gestionat, updatat, integrat etc), un middleware deasupra acestor

business

TODAY SOFTWARE MAGAZINE nivelul interfeţei utilizator, să putem folosi toolkit-uri precum SWT sau JavaFX pentru renderizarea modelului.

componente (ce permite extensibilitate, flexibilitate, scalabilitate, update-uri etc.), au portabilitate la rulare (de la PC-uri până la dispozitive mobile şi nu numai), posedă instrumente de dezvoltare asistată, au posibilitate de instalare inteligentă şi multe altele. În această carte este prezentată versiunea Eclipse 3.5 (Galileo) a platformei. Aceasta nu este ultima versiune de Eclipse, dar cuprinde o serie de îmbunătăţiri remarcabile faţă de versiunile anterioare. Ultima versiune este Eclipse 4 (Juno) apărută în iunie 2012. Doresc să fac unele specificări referitor noutățile din Eclipse 4 şi să precizez că întreaga tehnologie prezentată în carte merită toată atenţia. Eclipse 4 se bazează foarte mult pe versiunile anterioare şi o bună înţelegere a acestora va conduce la bune rezultate în dezvoltarea aplicaţiilor. Aşadar, în Eclipse 4: • aplicaţia este descrisă pe baza unei structuri numită modelul aplicaţiei; • acest model poate fi modificat la dezvoltare sau la rulare. Modelul poate fi apoi extins; • există suport pentru adnotări şi dependency injection cu importante implicaţii în ceea ce priveşte folosirea unităţilor de testare; • widget-urile Eclipse pot fi stilizate folosind fişiere CSS, ca în cazul paginilor web; • modelul aplicaţiei este decuplat de prezentare ceea ce ne permite, ca la

Lucrarea este structurată în trei mari părți. Prima zonă cuprinde o introducere în RCP cu funcționalităţi elementare (logare, key binding, meniu) dar şi elemente mai complexe (help, uptate). Partea a doua aduce detaliile de implementare (despre perspective, view-uri, editori, acţiuni, comenzi, plugin-uri dinamice, testare) necesare obţinerii performanţei data de: rafinarea şi refactorizarea prototipului obţinut anterior, customizarea interfeţei utilizator precum şi construirea şi livrarea produsului către utilizator. Partea a treia este a referinţelor. Aici se face o trecere în revistă a specificaţiilor framework-ului OSGi, a framework-ului Eclipse databinding precum şi a altor plugin-uri folositoare pentru dezvoltarea aplicaţiilor RCP. Framework-ul OSGi este descris amănunţit într-o altă lucrare – OSGi în Action, a cărei recenzie o găsiţi în numărul 9 al revistei Today Software Magazine. Nu în ultimul rând este interesant de arătat cui i se adresează această carte. Evident, în primul rând, celor care dezvoltă aplicaţii RCP. Chiar dacă sunt programatori cu experienţă în utilizarea acestei tehnologii, parcurgerea cărţii este foarte utilă. Pe lângă evidenţierea arhitecturii de succes a unei aplicaţii bine puse la punct, se fundamentează şi detaliază numeroase concepte teoretice. În al doilea rând, celor care doresc să aplice principiile rich client-ului în dezvoltarea RIA (Rich Internet Applications). Experienţa dobândită la nivelul unui rich client este foarte utilă pentru aplicaţiile Rich Internet. Desigur, cunoaşterea limbajului Java pe platforma standard este absolut necesară, iar unele deprinderi de folosire a IDE-ului Eclipse sunt, de asemenea, binevenite. Cred că orice persoană dornică să înveţe sau să se perfecteze în folosirea RCP găseşte în această carte un suport de preţ. Personal, cred că evoluţia platformei Eclipse RCP este senzaţională şi va continua. Introducerea pattern-ului MVC, folosirea OSGi-ului, internaţionalizarea, adnotările şi dependency injection sunt

doar câteva exemple dintre progresele remarcabile făcute de această platformă. Deşi conţine numeroase ghidaje lucrul într-o astfel de platformă necesită cunoştinţe vaste şi bine înţelese pentru a putea obţine cu adevărat performanţă. Vă aştept, ca de obicei, cu toată plăcerea şi interesul, pentru discuţii legate de acest subiect. Lectură plăcută! Silviu Dumitrescu

www.todaysoftmag.ro | nr. 12/Iunie, 2013

management

De ce ne răcim gura cu AGILE?

rticolul de față prezintă câteva din beneficiile utilizării metodologiei Agile în viața de zi cu zi în domeniul IT. Elementul de comparație este cea mai utilizată metodologie până pe la începutul anilor 2000, metodologia Waterfall, cea în care mulți dintre noi au lucrat și continuă să lucreze.

Teoria (bună ca întotdeauna) Bogdan Nicule

BNicule@neverfailgroup.com Bogdan Nicule este un Manager IT cu o vastă experienţă internaţională. Şi-a început cariera în urmă cu 12 ani pe post de developer şi a evoluat ca Team Leader, Project Manager, Department Manager, până la poziţii cu responsabilităţi executive. Este un constructor de echipe de succes. A coordonat proiecte în Asia de Sud-Est (Singapore, Malaysia), America de Nord (Canada) şi Europa (România, Germania, Olanda, UK). Lucrează cu metodologia Agile din 2006, pe care a utilizat-o în diverse contexte şi cu echipe de diferite mărimi.

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

riscul amânării livrării dacă se descoperă În compararea oricăror două entități defecte majore în ultima parte a perioase utilizează de obicei criterii de evaluare dei de testare. comune. În acest caz vom vedea cum pot 3. Calitatea produsului livrat – în fi caracterizate celedouă metode de lucru cazul utilizării metodologiei Agile, caliîn funcție de: modul lor de a se adapta la tatea produsului este crescută întrucât schimbările continue ale cerințelor inițiale acesta a trecut prin mai multe faze de ale unui proiect, capacitatea de respectare a testare completă până la momentul livrătermenelor de livrare, calitatea produsului rii. O echipă care utilizează metodologia livrat și predictibilitatea evoluției proiectuWaterfall acceptă riscul ca defecte majore lui pe parcursul acestuia, atât sincronic cât să fie detectate într-o fază înaintată de și diacronic. testare. Costul necesitat în acest caz penAșadar: tru remedieri poate fi destul de ridicat. 1. Adaptabilitate – caracteristica funda4. Predictibilitate – este unul din atuumentală a metodologiei Agile este aceea rile importante ale utilizării metodologiei că echipa care o utilizează poate face Agile. Predictibilitatea este crescută sinfață cu ușurință schimbărilor constante cronic, deoarece în orice moment al de pe parcursul unui proiect. Includerea proiectului se știe ce funcționalități exisreprezentantului clientului în echipă pertau la finalul sprint-ului anterior și, cu o mite ajustarea ușoară la noile lui cerințe precizie crescută, cele care vor fi adăugate și schimbarea rapidă a priorităților. În pe parcursul sprint-ului curent. În cazul cazul metodologiei Waterfall schimbările metodologiei Waterfall, predictibilitatea pe parcursul proiectului sunt mai greu de este crescută diacronic. Ea crește o dată inclus. cu apropierea finalului perioadei de tes2. Termene de livrare – pentru o tare și depinde de întreaga succesiune echipă care folosește metodologia Agile de evenimente din cadrul proiectului de livrarea la timp nu este o preocupare. până atunci. Produsul ar trebui să fie livrabil și stabil la finalul fiecărui sprint încheiat. În cazul Tabelul de mai jos sintetizează utilizării metodologiei Waterfall, există informațiile prezentate în această primă

TODAY SOFTWARE MAGAZINE parte.

Practica

rulat anterior în manieră Waterfall e. Calitatea livrării: excelentă.

Voi prezenta în cele ce urmează trei În acest caz, aș putea spune că valoacontexte de lucru în care am utilizat meto- rea produsului livrat s-a datorat în cea mai dologia Agile. mare parte disciplinei de care a dat dovadă echipa, entuziasmului specific vârstei (o Disciplina Americii de Nord medie de vârstă sub 30 de ani) și deschia. Locație: Toronto; derii membrilor de a învăța și a pune în b. Mărimea echipei: 150; practică lucruri noi. Confirmarea valorii c. Experiența membrilor echipei: foarte echipei și a produsului livrat s-a întâmplat experimentați, echipă existentă; într-un moment de decizie a continuării d. Tipul proiectului: proiect în derulare; colaborării. Reprezentanții clientului au e. Calitatea livrării: excelentă. decis fără echivoc continuarea colaborării cu această echipă, care atunci a primit mai Datorită implementării eficiente a multe voturi de încredere din afara compametodologiei Agile la nivel de companie și niei decât dinăuntrul ei. a gradului înalt de cooperare între membrii echipei, coroborate cu o disciplină model Variabila numită Context și asigurarea unei activități de QA de cea a. Locație: Cluj și Germania mai înaltă clasă, acesta poate fi un exemb. Mărimea echipei: 9 plu ideal pentru conferința a cărei temă c. Experiența membrilor echipei: toate centrală este Agile, ”Even mamooths can nivelurile, echipa nouă be agile”.Toate aspectele specific metodolod. Tipul proiectului: proiect nou giei (negocierea inițială, întâlnirile zilnice, e. Calitatea livrării: bună pair programming) funcționau cu o precizie elvețiană. Prin urmare, modelul Agile este Acesta este un exemplu în care tranziția utilizabil la nivel de corporații și echipe cu de la metodologia folosită anterior spre un număr mare de membri. Agile s-a făcut cu dificultate. Din această cauză, eficiența procesului de livrare a avut Succesul fulminant al începătorilor de suferit și valoarea produsului final a a. Locație: Cluj; fost la nivel mediu. Câțiva dintre membrii b. Mărimea echipei: 10; echipei au făcut cu greu trecerea spre noua c. Experiența membrilor echipei: majo- modalitate de lucru, iar disciplina a fost un ritatea junior, echipa nouă; capitol sensibil, nu foarte ușor de gestionat. d. Tipul proiectului: proiect existent, Tabelul de mai jos sintetizează

informațiile incluse în partea a doua a articolului.

Concluzie

La întrebarea dacă metodologia Agile e bună, răspunsul ar fi următorul: metodologia Agile e foarte bună, dar e alergică la context. Ține foarte mult de deschiderea echipei care utilizează Agile, disciplina ei, dorința reală de a învăța lucruri noi și de a le aplica. Dacă ar fi să ne gândim la întrebarea clasică dacă metodologia Agile e mai bună față de Waterfall putem spune că aduce câteva beneficii însemnate față de Waterfall și că rezultatele oferite de fiecare țin mult de disciplina echipei care le utilizează. Prin urmare, pentru lumea în continuă schimbare în care ne aflăm, o lume care vrea să aibă vizibilitate cât mai bună asupra lucrurilor, putem spune că metodologia Agile e mai potrivită prin claritatea și gradul de siguranță pe care le oferă.

www.todaysoftmag.ro | nr. 12/Iunie, 2013

management

Cod curat = bani în buzunar

criu acest articol, pentru că am văzut ecuația “cod murdar = bani pierduți” de prea multe ori. Articolul este scris atât pentru audiența tehnică, cât și pentru cea nontehnică din industria IT. Voi face o introducere scurtă și la obiect despre codul curat și cum influențează pozitiv aspectele financiare ale unui produs.

Ce este codul? Dan Nicolici

dnicolici@neverfailgroup.com Senior Java Developer @ Neverfail Group

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

Există nenumărate sisteme, în producție, care rulează pe milioane de linii de cod pe care nimeni nu vrea să le atingă de frică sau pentru că ar fi imposibil să genereze o contribuție pozitivă la business. Iată câțiva dintre indicatorii care arată că avem de a face cu cod rău: nu există o separare clară a responsabilităților (clase, metode sau funcții imense), modularitate sărăcăcioasă (totul e interconectat), multe globale, teste rele sau în care nu putem avea Iată niște căi posibile de a scrie cod încredere. sursă: shell scripting, SQL, C#, java, C, Toate aceste lucruri rele generează o Python. datorie tehnică imensă. În paragraful de mai sus, am subliniat cuvântul “facilita“, pentru că reprezintă un “Datoria tehnică (cunoscută și sub concept cheie în a produce cod curat. numele de datoria design-ului sau datoria Dar ce este “cod curat“? Cod curat este codului) este un neologism metaforic, ce codul care: se citește foarte ușor, e facil de se referă la eventualele consecințe ale unei schimbat, scoate la suprafață deciziile de arhitecturi sărăcăcioase sau care evoluează, design, e foarte bine protejat de o suită și la dezvoltarea de software. Datoria poate de teste, e plăcut de modelat și lista poate fi considerată munca ce trebuie făcută înacontinua. Simplu spus, codul curat este cod inte ca o sarcină să fie considerată completă“. foarte ușor de întreținut. - Wikipedia Programatorul care scrie cod curat, Cu alte cuvinte, lăsând codul sursă într“facilitează“ munca altor programatori ce îl o stare proastă (printre alte sarcini nelegate vor modifica. direct de codare), generăm datorie tehnică. De obicei, dobânda crește odată cu trecerea Cum e codul în general? timpului, pe măsură ce codul “putrezește“ În practică, situația e foarte diferită (ca să îl citez pe Robert C. Martin). de cele descrise mai sus. Vedem cod care Această continuă creștere a datoriei tehe o dezordine generală, care face foarte nice rezultă într-o descreștere a calității dificilă chiar și adăugarea unei mici produsului și o creștere a costului adăugăfuncționalități la sistem fără a fi nevoie de rii de funcționalitate. Un mod simplu de a a petrece nenumărate ore de citit și rulat măsura calitatea unui produs este formula în debug printr-un teritoriu necunoscut. DRE (defect removal efficiency - eficiența de “În știința calculatoarelor, codul sursă este orice colecție de instrucțiuni pentru calculator (posibil cu comentarii) scrise folosind un limbaj de calculator citibil de către om, de obicei ca și text. Codul sursă al unui program este conceput special pentru a facilita munca programatorilor, aceștia specificând acțiunile ce trebuie îndeplinite de un calculator, cel mai adesea prin cod sursă“ - Wikipedia

HR înlăturare a defectelor): DRE = Cantitatea de defecte găsite la testing / (Cantitatea de defecte găsite la testing + Cantitatea de defecte găsite de useri) Exemplu: DRE = 1 / (1 + 9) = 0.1 (10%) => DRE rău DRE = 9 / (9 + 1) = 0.9 (90%) => DRE bun

Capers Jones, un american specializat în metodologii pentru inginerie software, adesea asociate cu modelul pentru estimarea costului punctajului unei funcții, afirmă următoarele despre cuantificarea conceptelor legate de datoria tehnică: “Există o măsurătoare mai veche, numită ‘costul calității’ care a fost folosită la cuantificarea datelor existente de ani buni. Unul dintre lucrurile pe care le-am măsurat la IBM, ITT și multe alte companii, este cât costa cu adevărat atingerea unor nivele ale calității. Dați-mi voie să vă dau niște numere din industrie ca exemplu. Costul mediu pentru a implementa un oarecare software în S.U.A., este de aprox. 1000$ per punct funcțional și, în timpul developmentului, este aprox. jumătate - 500$ per punct funcțional, reprezintă costul găsirii și reparării defectelor. Odată ce soft-ul este pus în producție, în primul an, companiile cheltuiesc aprox. 200$ per punct funcțional ca să găsească și să repare defecte și, mai apoi, cheltui aprox. 250$ per punct funcțional ca

TODAY SOFTWARE MAGAZINE să adauge specificații și îmbunătățiri. După cinci ani, dacă au procedat corect, vor scădea la aprox. 50$ per punct funcțional la repararea de defecte, iar ce cheltuie pe îmbunătățiri, rămâne constant. Deci, dacă au procedat corect, costul din primul an pentru repararea defectelor va scădea repede odată cu trecerea timpului. Pe de altă parte, dacă au făcut o mizerie, dacă nu au construit soft-ul bine și nu au fost atenți, vor cheltui 1200$ per punct funcțional pentru adăugarea de specificații noi și 600$ per punct funcțional pentru repararea defectelor înainte și 300$ după punerea lui în producție. Și în loc să scadă după cinci ani, costul va rămâne constant sau va crește. Deci, după cinci ani, pot ajunge să aibă un produs foarte rău, pe care cheltuiesc 350$ per punct funcțional, găsind și reparând defecte când ar fi trebuit deja să fi scăzut costul la 50$ per punct funcțional. De altfel, acest tip de informație - costul calității - este relativ bine cunoscut. [...] Cu cât aplicațiile sunt mai mari, procentajul de proiecte care sunt abandonate și nepuse în producție crește - la peste 10.000 de puncte funcționale, aprox. 35% dintre proiecte care sunt pornite, nu văd niciodată lumina zilei în producție. Cel mai des întâlnit motiv pentru care nu sunt puse în producție este pentru că au avut atât de multe defecte, încât nu au funcționat niciodată. Este o conexiune directă intre costul calității și executarea lucrurilor în mod greșit, sfârșind cu proiectele abandonate.“ - extrase dintr-un

interviu din 22 ianuarie 2013 Conform celor spuse de Jones, datele ne arată că suntem foarte predispuși să plătim de șapte ori mai mult pentru mentenanța unui produs scris greșit. Iată date financiare directe! Aceasta ar trebui să fie un indiciu major pentru atât cei care investesc, cât și pentru cei care scriu (codează) un produs. Aceasta, bineînțeles, înseamnă că scriind soft de calitate este mai ieftin. Așadar, pentru că la temelia produselor software stă codul: cod curat = bani în buzunar!

Surse 1.

Inter viu cu Capers Jones: http:// w w w. o n t e c h n i c a l d e b t . c o m / b l o g / ward-cunningham-capers-jones-a-discussion-on-technical-debt/ For mu la DRE: http://qatest lab.com/ knowledge-center/QA-Testing-Materials/ what-is-defect-removal-efficiency-insoftware-testing/ Wikipedia

www.todaysoftmag.ro | nr. 12/Iunie, 2013

management

Gogu la drum cu jaloane - Pe-ăla mi l-am luat și eu. E un GPS simplu, ieftin și își face treaba, ți-l recomand. Șefu’ apăruse fără știre în spatele lui Gogu. „Auch... m-a prins teleleu pe Google”. Îi trecu prin cap să răspundă cu o scuză, dar își dădu seama imediat cât de penibil ar fi fost. Plus că era prea interesat de detaliile tehnice ale GPS-ului. Le află imediat, Șefu’ îi dădu rapid toate informațiile. - Da’ unde mergi? - Le-am promis părinților că merg cu toată familia la ei. Ne vedem rar cu toții, 450 de km nu-s ușor de parcurs cu copilul. Își schimbă vocea și își maimuțări copilul: „Tati, mai avem mult? Când ajungem? Cât mai avem până la Buni? Taaati, m-am plictisit...” Și mai e și mama – adică Buni - care vrea să știe exact la ce oră ajungem. Dacă întârziem, intră în panică, își închipuie catastrofe și i se face rău; dacă ajungem mai repede, de ce-am ajuns înainte de ora programată, probabil am mers cu viteză prea mare. Nicicum nu e bine. Mi-e groază de drumul ăsta, Șefule... - Stai măi Gogule, că nu e așa tragică situația. Totul se rezolvă ușor, ai nevoie doar de niște jaloane. Gogu simți cum i se lasă un gol în stomac. Sigur că nu era tragică, dar în o mie de ani nu ar fi crezut și nu s-ar fi așteptat ca Șefu’ să râdă de el atunci când era necăjit cu adevărat. Și acum când i se destăinuise sincer... Încercă să spună ceva, dar i se puse un nod în gât și nu putu decât să lase privirea în jos, dezarmat, trist și incredibil de dezamăgit. „Nu mă așteptam...” își spuse. Dintr-o dată totul luă dimensiuni apocaliptice, problema lui nu mai era doar o problemă de familie, ci o nenorocire de proporții, lipsa de înțelegere a Șefului deveni semnul clar al unei complicate conspirații împotriva sa... - Gogule, alo, ești cu mine? Ce-ai pățit? Zâmbetul larg al lui Șefu’ îl lăsă perplex pe Gogu. Teoria conspirației se disipă imediat lăsând locul unei singure nedumeriri majore: - Nu înțeleg, Şefu’, ce e cu jaloanele. Că doar n-oi fi vrând să înfig țăruși din Cluj până în București... Hă-hă-hă... Hai, măi Gogule, zău așa, e vorba de jaloanele din teoria managementului de proiect.Un element care marcheză un moment important în derularea unui proiect... îți dă o indicație asupra poziției tale în timp și îți permite să raportezi modul în care proiectul se încadrează în duratele estimate. Adică exact ce îți trebuie ție, măi Gogule, pentru drumul tău. Fața lui Gogu nu denota nici strop de inteligență – Ba chiar e ușor tâmpă, gândi Șefu’ amuzat – așa că se grăbi să adauge: îți stabilești niște repere, localități importante pe drumul tău. Acelea vor fi jaloanele voastre. Calculezi cât timp îți trebuie pentru a ajunge de la unul la altul, astfel încât să știi – în funcție de ora la care plecați -, la ce oră vei ajunge la fiecare dintre ele. Dacă vor apărea întârzieri, vei ști imediat cum se reflectă acestea asupra orei de sosire. Copilului îi faci un desen și îi arăți de fiecare dată când atingeți un jalon. Îi dai sarcina să o informeze pe Buni și uite așa

nr. 12/Iunie, 2013 | www.todaysoftmag.ro

ai doi stakeholderi la curent cu evoluția călătoriei voastre. Cum ți se pare? Încet-încet fața lui Gogu se lumină iar Șefu’ răsuflă ușurat: Nu-ți stătea bine cu fața dinainte, Gogule. Se pare că acum lucrurile s-au mai luminat puțin, ce zici?

Gogu în schimb îl ignoră total și se apucă să deseneze traseul. Se vedea că îi place ideea și deși desenul nu era tocmai conform cu realitatea, arăta cât de cât a traseul dintre Cluj și București. Estimă durata deplasării în funcție de viteză și drum... Se și vedea dând explicații docte fiului său și se bucura și la ideea comunicării „poziției” de către acesta către Buni. Ha! S-ar putea să nu fie chiar atât de rău pe cât își închipuise... - Șefu’, ești mare! Cum aș putea să îți mulțumesc? - Credeam că nu mai întrebi! La începutul lunii viitoare trebuie să facem un workshop pe teme de management de proiect; ții tu o prezentare despre jaloane?! Că acum te pricepi. De fapt de-asta venisem la tine, doar că atunci încă nu știam ce subiect să abordăm, mulțam și eu de idee...

Simona Bonghez, Ph.D.

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

sponsori

Comunicﾄノ mai simplu direct prin SMS. Propune un titlu de articol pentru numﾄビul urmﾄフor sau trimite-ne sugestiile tale.

SMS 0371700018 numﾄビ cu tarif normal