Today Software Magazine N12/2013

No. 12 Iunie 2013 www.todaysoftmag.ro www.todaysoftmag.
com
TSM
T O D A Y S O F T WA R E MAG A Z I NE
Siste
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
te a z a me b
ds i r g ta a d pe
ti
Gemini Solutions Foundry TechHub Bucharest Din uneltele artizanului software: Unit Testing Cod curat = bani n buzunar Eclipse Rich Client Platform Big Data, Big Confusion NEO4j Graph Database Hadoop(II)
Haskell(II) JQuery Europe 2013 Behavior Driven Development n Python Planificarea Testrii de Performan Test Driven Development (TDD) Managementul performanei (II) Start me up - Akcees De ce ne rcim gura cu AGILE?
6 Susintorii startup-urilor romneti

Ovidiu Man
30 Test Driven Development (TDD)

Ladislau Bogdan i Tudor Trisca
9 TechHub Bucharest
Irina Scarlat
33 Big Data, Big Confusion

Mihai Nad
10 Gemini Solutions Foundry

Radu Popovici
35 Sisteme bazate pe data grids

Attila-Mihaly Balazs i Dan Berindei
11 Start Me Up
Irina Scarlat
37 NEO4j Graph Database modelarea datelor interconectate

Iulian Moneagu
12 NGO connect
Echipa NGO Connect
39 Hadoop (II)
Radu Vunvulea
13 Istoria IT-ului Clujean (VI)

Marius Mornea
41 Programare Funcional n Haskell (II)

Mihai Maruseac
15 Dezvoltarea de aplicaii iOS innd cont de securitate

Cristian Roa
44 Planificarea Testrii de Performan

Alexandru Cosma
18 JQuery Europe 2013

Andrei Otta
46 Recenzia crii: Eclipse Rich Client Platform

Silviu Dumitrescu
21 Managementul performanei (II)

Andreea Prvu
48 De ce ne rcim gura cu AGILE?

Bogdan Nicule
24 Din Uneltele Artizanului Software: Unit Testing

Alexandru Bolboaca i Adrian Bolboac
50 Cod curat = bani n buzunar

Dan Nicolici
27 Behavior Driven Development n Python

Ramona Suciu i Dan Pop
50 Gogu la drum cu jaloane

Simona Bonghez, Ph.D.
editorial
Ovidiu Man, PMP
ovidiu.matan@todaysoftmag.com Fondator i CEO al Today Software Magazine
m asistat de curnd la gala de nchidere a programului de antrepreonoriat n echipe Tandem organizat de GRASP Cluj unde am urmrit prezentrile a patru echipe ce au artat proiectele de antreprenoriat realizate n cele opt sptmni ct a durat programul. A fost interesant s constat c toate aceste proiecte nu aveau ca baz IT-ul, fiind propuse business-uri tradiionale din domeniul agriculturii precum cultivarea plantelor sau creterea animalelor. Timpul de dezvoltare estimat al unuia dintre ele se ntindea pe parcursul mai multor ani pn 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, stnd acas sau participnd la un hackaton. Este att de simplu i uor s materializezi o idee! Chiar dac nu eti din mediul de IT sau dac nu ai acum ideea ce va schimba lumea poi participa la Startup Weekend sau Startup Live i s te alturi uneia dintre echipe. La finalul weekend-ului vei avea deja disponibil un prototip iar n urmtoarea sptmn poi s obi suport din partea unor incubatoare locale. V ncurajm s facei acest exerciiu, iar pentru cei ce l-au fcut deja i au un prototip, am pregtit articolul Susintorii Startup-urilor romneti. Lansm i un nou serviciu, www.programez.ro, o nou modalitate de comunicare ntre specialiti. Practic, panelurile unconference ce se desfoar n cadrul evenimentelor de lansare vor putea fi continuate online pe acest forum de discuii. De asemenea, ne va face plcere s rspundem ntrebrilor tehnice pe care le avei din toat sfera de IT: programare, testare, management sau HR. Fiind o iniiativ TSM, v putem garanta rspunsuri venite direct de la specialiti. O alt noutate este introducerea unui nou canal de comunicare cu cititorii notri, prin suportul oferit de TXT Feedback. Aceste startup local ofer posibilitatea de a comunica n magazine i nu numai prin intermediul SMS-urilor. Astfel, ncepnd cu luna iunie, v oferim posibilitatea de a ne transmite feedback-ul sau ntrebrile voastre direct, printr-un SMS la numrul 0371700018. Un eveniment important, ICT Spring Europe 2013, va avea loc n Luxembourg n perioada 19-20 Iunie, la care vom fi prezeni la acesta cu numrul 12 TSM. V invitm s participai alturi de noi, iar pentru aceasta v oferim un cod promoional ce va ofer participarea gratuit la eveniment: TSMS13. Articolele din acest numr debuteaz cu o list de incubatore i cowork-uri implicate activ n susinerea startup-urilor romneti. Putei s o folosii cu ncredere. Testarea primete o atenie binemeritat printr-o serie de articole ce au n focus Test Driven Development (TDD), Behavior Driven Development (BDD) precum i Performance Testing. Dezvoltarea aplicaiilor n cloud este dezbtut 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).Continund n aceeai not de dezvoltare software vei gsi partea a II-a din Programare Funcional n Haskell. JQuery Europe 2013 a fost un eveniment de excepie, iar n acest numr avem un articol dedicat acestuia. nchei prin a reaminti de proiectul Timeline care este n derulare. Pe scurt, TSM a iniiat un proiect care vizeaz realizarea unui afi infografic referitor la dezvoltarea companiilor romneti i la principalele realizri ale acestora. Adresa de email timeline@ todaysoftmag.com este dedicat celor ce vor s fie parte din acest proiect.
V dorim o lectur plcut !!!
Fondator i CEO al Today Software Magazine
Ovidiu Man
nr. 12/Iunie, 2013 | www.todaysoftmag.ro
TODAY SOFTWARE MAGAZINE

Lista autorilor Redacia Today Software Magazine
Fondator / Editor n chief: Ovidiu Man ovidiu.matan@todaysoftmag.com Editor (startups i interviuri): Marius Mornea marius.mornea@todaysoftmag.com Graphic designer: Dan Hdru dan.hadarau@todaysoftmag.com Copyright/Corector: Emilia Toma emilia.toma@todaysoftmag.com Traductor: 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
alex.bolboaca@mozaicworks.com Agile Coach and Trainer, with a focus on technical practices @Mozaic Works
dan@infinispan.org Software Developer @ Infinispan
Irina Scarlat
irina.scarlat@howtoweb.co Irina Scarlat este Co-Fondator al Akcees
Mihai Maruseac
mihai.maruseac@gmail.com IxNovation @ IXIA membru ROSEdu, ARIA
Silviu Dumitrescu silviu.dumitrescu@msg-systems. com Consultant Java @ .msg systems Romania
Radu Vunvulea
Radu.Vunvulea@iquestgroup.com Senior Software Engineer @iQuest
Mihai Nad mihai.nadas@tss-yonder.com CTO @ Yonder
Adrian Bolboaca
adrian.bolboaca@mozaicworks.com Programmer. Organizational and Technical Trainer and Coach @Mozaic Works
Radu Popovici radu.popovici@geminisols.ro Software Engineer @ Gemini Solutions
Bogdan Nicule
BNicule@neverfailgroup.com Bogdan Nicule este un Manager IT cu o vast experien internaional.
Today Software Solutions SRL

str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag ISSN 2284 6352
Iulian Moneagu
iulian.mosneagu@geminisols.ro Senior Software Engineer @ Gemini Solutions
Dan Pop
dan.pop@3pillarglobal.com Senior Test Engineer @ 3Pillar Global
Andreea Prvu Attila-Mihaly Balazs

dify.ltd@gmail.com Code Wrangler @ Udacity Trainer @ Tora Trading
andreea.parvu@endava.com Recruiter n cadrul Endava
Andrei Otta
andrei.otta@accesa.eu Software developer @ Accesa
Ramona Suciu
Test Lead @ 3Pillar Global
ramona.suciu@3pillarglobal.com
Copyright Today Software Magazine

Reproducerea parial sau total a articolelor din revista Today Software Magazine fr acordul redaciei este strict interzis. www.todaysoftmag.ro www.todaysoftmag.com
simona.bonghez@confucius.ro Speaker, trainer i consultant n managementul proiectelor, Owner al Confucius Consulting
Cristian Roa
cristian.rosa@isdc.eu mobile developer @ ISDC
Alexandru Cosma
alexandru.cosma@isdc.eu Senior Tester @ iSDC
Tudor Tric
tudor.trisca@msg-systems.com Software Developer @ .msg systems Romania
www.todaysoftmag.ro | nr. 12/Iunie, 2013
startups
Susintorii startup-urilor romneti

ei ne aflm la nceput n privina startup-urilor romneti i nc nu ne putem mndri cu o cultur de mas a mediului de IT autohton, susintorii acestora ncep s i fac din ce n ce mult mult simit prezena. Prin aciunile i facilitile 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 dorete s lanseze un startup.
Co-work-urile sau spaiile de lucru comune
O practic nou pe piaa local este reprezentat de nchirierea unui birou pentru un anumit numr de ore sau zile. La finalul zilei acel spaiu este eliberat astfel nct ziua urmtoare altcineva poate s l foloseasc. Avantajul acestei abordri este diversitatea, posibilitatea de a realiza rapid legtura cu diferite alte business-uri i de a putea lua rapid pulsul local. Datorit naturii acestora de a nu avea un spaiu permanent dedicat, numrul de evenimente organizate este mare, iar prin legturile sau organizaiile afiliate vizibilitatea business-urile este mrit.
TechHub Bucureti
Serviciile oferite spaiu co-working, birouri de tip rezident cu acces 24/7, evenimente organizate de TechHub i comunitatea online.
Afilierea la o organizaie internaional TechHub, comunitate global dedicat exclusiv antrepre- Cluj HUB norilor n tehnologie, fiind reprezentat n prezent la Londra, Pe lng posibilitatea de a-i desfura activitatea profesional Manchester, Riga i Bucureti. 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 tu: 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, Bucureti, servicii de business development i consultan n atragerea bucharest.techhub.com de investitori, servicii de matchmaking i networking, Cluj CoWork servicii de gzduire a sediului social, Un spaiu plcut n centrul Clujului oferind senzaia de acas. servicii de printing i design, Exist suport de internet (WiFi), fructe, ap i cafea. Dac vre nchirieri sli pentru workshop-uri i conferine pn la mea este bun se poate lucra pebalcon i eti nconjurat de oameni maxim 90 de persoane. muncitori deschii s te ajute n cazul n care avei probleme. Cluj CoWork te face productiv ntr-un mod relaxant. Pentru startupNumrul 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 estimnd ca pn aplicaiilor. la sfritul anului 2013 vom ajunge la 35 companii i mai mult de Investiii: Au fost fcute investiii financiare, de timp i servicii 50 de membri. pentru startup-uri. Modul de atragere a investitorilor: Dintre companiile pe care le Cum sunt atrai investitorii? Folosim networking-ul propriu gzduim una dintre ele a obinut o finanare n cadrul unui propentru aceasta gram de accelerare de aproximativ 30 000 euro.
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 deschii la discuii. Care sunt criteriile pentru a fi acceptat? Aceleai pentru toat lumea ...dac eti serios, motivat, muncitor i open minded atunci eti acceptat. Care sunt activitiile din cadrul Cowork-ului? n fiecare sptmn se desfoar evenimente interesante cum este GeekMeet. n afar de aceste evenimente de relaxare i socializare cum ar fi Sangrianights, Cocktail courses, sushi making & eating i barbecues. Datele de contact: str. Emil Isac, nr. 3, Cluj-Napoca clujcowork.ro

Perioada de incubare:Investitorii cu care comunicm fac parte att din comunitatea local i ne ntlnim periodic cu ei dar avem i investitori din comunitatea internaional. Afilierea la o organizaie internaional: Nu avem o afiliere la o organizaie internaional, dar colaborm cu multe entiti similare. Modul de tarifare: Pentru a-i desfura 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 mergnd pe potrivirea lor cu ceilali membri ai comunitii dar plecm n profilarea noastr de la: freelanceri - profesii liberale sau startup-uri, strini cu delegaii n Cluj; n aceasta arie avem un parteneriat de lunga durat cu Cluj International Club, companii care vizeaz investiii locale, antreprenori care dezvolt servicii sau produse noi i care aduc inovaia n pia, antreprenori sociali i persoane care valorizeaz implicarea n comunitate, persoane open minded i deschise ctre colaborare i dezvoltare personal. Activitile din cadrul incubatorului: sunt multe evenimente care poate trebuie tratate separat pentru c din iunie vor fi mai numeroase. Datele de contact: str. Piteti, nr. 9, Cluj-Napoca clujhub.ro
Acceleratoare/incubatoare de startup-uri
Dac n soluiile de pn acum, suportul oferit era ca un serviciu adiional, iar motorul business-ului era reprezentat de nchirierea spaiului sau reinerea unui procent din suma obinut, 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 beneficiai de sprijin dedicat pentru transformarea startup-ului ntr-un business real.
Gemini Solutions Foundry

Este primul incubator destinat exclusiv startup-urilor IT din Romnia ce faciliteaz crearea conexiunilor ntre antreprenorii romni i investitori din Silicon Valley. Ofer echipelor acceptate n programul de incubare spaiu de birouri la cheie cu toate utilitile necesare i acces la sli de conferine i de prezentri. 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 pn la multinaionale n aproape toate domeniile existente, de la back-end la front-end, de la cloud computing la aplicaii destinate pentru mobile. Consultan financiar i cea legal oferite au ca scop uurarea muncii depuse n aceste direcii pentru a permite antreprenorilor s se concentreze la ceea ce conteaz cu adevrat ntr-un start-up i anume implementarea ideii. Dar poate cea mai interesant facilitate este reprezentat de conexiunile cu fonduri de investiii din Silicon Valley. Aceste conexiuni se fac n cadrul unui eveniment anual denumit Demo Day unde echipele vor prezenta att ideea lor ct i progresul efectuat n cadrul programului de incubare. Acest tip de finanare este foarte important pentru creterea ulterioar a echipei deoarece pe lng banii primii echipa beneficiaz i de conexiunile dar i de ndrumarea investitorului, altfel spus: Smart money. Datele de contact: gemsfoundry.com
Platforme de crowdfunding
Implicarea comunitii n suportul dezvoltrii proiectelor este un lucru inedit. Suportul vine direct de la utilizatorii ce doresc s devin clienii respectivei afaceri nainte ca aceasta s existe de fapt. Propunerea din acest numr, multifinanare.ro reprezint o abordare interesant.
multifinanare.ro
Ofer ser vicii de crowdfounding prin publicarea proiectelor pe platforma proprie. Fiecare proiect ce obine 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 investiional. Vom publica mai multe despre aceast iniiativ ntr-unul din numerele viitoare ale revistei. Date de contact: multifinantare.ro B-dul N. Titulescu Nr. 4 , Cluj-Napoca
NextPhase
NextPhase este interesat de proiecte inovative care au potenial comercial. Prin implicarea sa, Ne x t P h a s e c o m pleteaz resursele necesare proiectului pentru a asigura progresul corespunztor al acestuia. Astfel, n proiectele pe care le considerm de interes, noi putem s participm printr-o combinaie de servicii, cum ar fi: organizarea i managementul procesului de cercetaredezvoltare, elaborarea i managementul strategiei de proprietate intelectual, furnizarea de infrastructur,finanare, managementul business-ului, elaborarea i dezvoltarea strategiei de cretere, acces la surse suplimentare de investiie, programe de formare (training) pentru echipele de inventatori/antreprenori. Cu o adaptare
startups
corespunztoare a termenului, am putea afirma c NextPhase este un incubator de tehnologie de tip one stop shop unde ideile cu potenial comercial gsesc ceea ce au nevoie pentru a deveni afaceri de succes. Numrul de echipe nscrise -La 31 Dec 2012, aveam 2 proiecte n derulare i 3 proiecte n pregtire. Urmtorul 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 sfritul celui de-al treilea trimestru al acestui an. Modul de atragere a investitorilor - Pn la un anumit nivel, NextPhase este investitorul. Acest nivel depinde n principal de proiect, de necesarul de resurse n fazele planificate i evoluia proiectului pn n acel moment. Mai departe, strategia de atragere a investitorilor depinde foarte mult, din nou, de domeniul proiectului, de indicatorii i riscurile acestuia. Oricum, pn la urm, iniierea unei colaborri sntoase cu un investitor nu se poate baza dect pe o propunere de afaceri corect i transparent. Perioada de incubare - Din motive legate att de partea tehnic, ct i de partea comercial, noi intim o perioad de incubare de circa 12 18 luni de zile. Bineneles, pot exista i excepii, dar acestea trebuie s fie bine fundamentate. Afilierea la o organizaie internaional - NextPhase este subsidiar a Flogistics AG Elvetia i dispune de o reea proprie de consultani i poteniali investitori. NextPhase nu face parte din nici o reea notorie de incubatoare de tehnologie. Se pare c acest lucru poate fi un avantaj din punct de vedere a vitezei deciziilor i a adaptabilitii la specificul proiectelor. Suportul oferit dup ce echipele prsesc HUB-ul: Prin natura implicrii, NextPhase continu i i adapteaz suportul oferit i dup perioada de incubare, practic pn la momentul de ieire (exit) din afacere. Suportul i strategia de ieire depind de gradul de succes al proiectului i evoluia capacitii de funcionare autonom a acestuia. Modul de tarifare pentru co-work - n general, noi ne implicm doar n proiectele n care credem i uzual, aceast implicare se face n schimbul unei participaii 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 tarifm implicarea noastr, ci ne asumm 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/difereniator al conceptului care st la baza proiectului, potenialul comercial al ideii i, foarte important, echipa de inventatori/antreprenori. Ca i filozofie de aciune, credem c este nevoie de o idee bun, deo implementare corespunztoare, dar i de pasiunea i andurana de a face fa obstacolelor care, invariabil, sunt prezente de-a lungul proiectului. Activitile din cadrul incubatorului: - Pe lng activitatea principal de dezvoltare de proiecte, NextPhase organizeaz seminarii de prezentare, evenimente de networking, programe de formare pentru echipele de inventatori/antreprenori n dorina de a contribui la dezvoltarea comunitii antreprenoriale clujene. Datele de contact: nextphase.ro
Ovidiu Man, PMP
ovidiu.matan@todaysoftmag.com Fondator i CEO al Today Software Magazine
startups
n ultimii ani Romnia a urmat tendinele din vest, iar fenomenul de co-working a nceput s capete amploare. n marile orae din ar s-au dezvoltat hub-uri antreprenoriale: locuri n care antreprenori i freelanceri lucreaz mpreun. Mai mult dect att, membrii schimb idei i experiene, utilizeaz n comun resurse i i mprtesc leciile nvate unii altora, ceea ce duce la coagularea unei comuniti. La asta se adaug faptul c evenimentele care au loc n spaiile 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 puin de o lun de la lansare. Antreprenorii aflai la nceput de drum contientizeaz c apartenena la o comunitate i ajut s evolueze rapid i apreciaz deschiderea internaional pe care le-o ofer statutul de membru rezident. De ce TechHub i cum s-a nscut proiectul? TechHub este o comunitate global dedicat exclusiv antreprenorilor n tehnologie. Conceptul a luat natere n 2011 la iniiativa lui Mike Butcher (European Editor TechCrunch) i Elizabeth Varley. n ultimii doi ani, TechHub a sprijinit inovaia 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, aa c Bogdan i-a ntrebat cititorii, membrii ai comunitii, dac au nevoie de un hub. Rspunsurile pozitive au fost numeroase, aa c Bogdan s-a hotrt s dezvolte n continuare acest proiect. O zi mai trziu, publica o lista de criterii pe care The Next Hub (denumirea iniial a ceea ce astzi este Tech Hub) trebuia s le ndeplineasc.
TechHub Bucharest
A fost nevoie de mult munc, oameni excepionali, dedicare i pasiune, pentru a transforma proiectul The Next Hub n TechHub Bucharest de astzi. Bogdan Iordache a lucrat alturi de Daniel Dragomir i tefan Szakal, Co-Fondatori ai TechHub, iar mpreun au fcut lucrurile s se ntmple. 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 Clugreanu, Vodafone i Adobe Romnia. Astzi, TechHub Bucharest ndeplinete toate criteriile stabilite iniial: este n inima Bucuretiului (Str. Nicolae Filipescu nr. 39-41, la 5 minute de mers pe jos de staia de metrou de la Universitate), are un cost rezonabil i este un spaiu deschis n care membrii, mai mult dect acces la un birou i un spaiu de co-working, beneficiaz de interaciune de calitate i pot participa la evenimentele organizate de TechHub i comunitatea online. Spaiul de 420mp este mprit ntre 35 de birouri permanente pentru membrii rezideni, 60 de locuri pentru co-working, sli de ntlnire, i un spaiu de evenimente cu o capacitate de pn la 150 de persoane. TechHub i propune s devin centrul comunitii antreprenoriale din Bucureti i aduce mpreun antreprenori, freelanceri, investitori, companii tech, dezvoltatori, bloggeri sau jurnaliti. Pe 9 mai, sala de evenimente a devenit nencptoare pentru membrii comunitii care au venit din toate colurile rii pentru a participa la deschiderea oficial. Evenimentul de lansare a adus mpreun reprezentani importani de pe scena tech romneasc i s-a bucurat de prezena invitailor 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 prezeni 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 importana TechHub ca factor agregator pentru start-up-urile tech din Romnia. A venit apoi rndul investitorilor s urce pe scen. Andrei Piti, Marian Duan i R adu Georgescu au vorbit despre ce caut un investitor la un start-up, iar Paula Apreutesei (RomanianAmerican Foundation ), Ctlina Rusu ( Geekcelerator ), Mihai Sfinescu ( 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 inovaie cu reprezentanii celor mai mari centre de cercetare-dezvoltare autohtone: Alex Marinescu ( EA Games ), Teodor Ceauu (IXIA) i Drago Georgi (Adobe Romnia), iar la final, invitaii evenimentului au avut ocazia s interacioneze n cadrul unei petreceri aniversare. TechHub Bucharest pune nc o dat Romnia pe harta global a inovaiei i antreprenoriatului, iar spaiul din Nicolae Filipescu va deveni foarte curnd inima unei comuniti active la nivel naional i va aduce mpreun cele mai importante evenimente autohtone dedicate tehnologiei. TechHub Bucharest, engage!
una mai a nceput cu veti bune pentru comunitatea antreprenorilor n tehnologie din Romnia: s-a lansat oficial TechHub Bucharest, primul spaiu de co-working din Romnia care le este dedicat n exclusivitate i care face parte din reeaua internaional TechHub.
Irina Scarlat
startups
Gemini Solutions Foundry

Primul incubator de afaceri IT din Romnia cu deschidere ctre Silicon Valley
Un caz aparte este reprezentat de startup-urile din sfera IT datorit pieei extrem de dinamice ce poate duce fie la o ascensiune rapid (acompaniat de un numr mare de utilizatori) fie la o pierdere n anonimat. Urmnd exemplul Statelor Unite, aceast categorie de afaceri ncepe s se bucure de o atenie deosebit i n Romnia, atenie manifestat prin inaugurarea unor hub-uri (cunoscute i sub denumirea de spaii 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 desfurate, 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 poteniali clieni, parteneri i investitori. Datorit acestor modaliti diferite de abordare ntr-un hub vom gsi un numr mare de echipe ce pltesc o tax lunar pe cnd n cadrul unui incubator, datorit ateniei sporite acordate participanilor, vom ntlni un numr restrns de echipe care vnd un procent din companie ca modalitate de plat. n curnd se va deschide n Bucureti Gemini Solutions Foundry primul incubator destinat exclusiv startup-urilor IT din Romnia ce faciliteaz crearea conexiunilor ntre antreprenorii romni i investitori din
n ultima perioad antreprenorii romni au la dispoziie din ce n ce mai multe modaliti de a-i facilita dezvoltarea unei afaceri. Fie c vorbim despre fonduri nerambursabile, comuniti antreprenoriale sau incubatoare de afaceri, aceste programe sunt un ajutor incontestabil, mai ales n fazele incipiente ale dezvoltrii companiei. Silicon Valley. Localizat n Piaa Victoriei din Bucureti, la doi pai de staia de metrou cu acelai nume, Gemini Solutions Foundry ofer gratuit echipelor acceptate n programul de incubare spaiu de birouri la cheie cu toate utilitile necesare i acces la sli de conferine i de prezentri. 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 pn la multi-naionale n aproape toate domeniile existente, de la back-end la front-end, de la cloud computing la aplicaii destinate pentru mobile. Consultan financiar i cea legal oferite au ca scop uurarea muncii depuse n aceste direcii pentru a permite antreprenorilor s se concentreze la ceea ce conteaz cu adevrat ntr-un start-up i anume implementarea ideii. Dar poate cea mai interesant facilitate este reprezentat de conexiunile cu fonduri de investiii din Silicon Valley. Aceste conexiuni se fac n cadrul unui eveniment anual denumit Demo Day unde echipele vor prezenta att ideea lor ct i progresul efectuat n cadrul programului de incubare. Acest tip de finanare este foarte important pentru creterea ulterioar a echipei deoarece pe lng banii primii 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 scutete echipele de o cheltuial suplimentar n faza incipient cnd 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 pri. Prin serviciile oferite, Gemini Solutions Foundry vine n sprijinul antreprenorilor din mediul IT din Romnia i i ajut s i extind afacerea pe plan internaional, n special pe piaa Statelor Unite ale Americii una dintre cele mai mari, mai dinamice i mai competitive piee din lume. Cei interesai s participe n acest program sunt invitai 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
10
startups
5 de participani foarte bine pregtii selectai din peste 200 de aplicaii... un trainer internaional... 8 antreprenori i investitori consacrai din Romnia... 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 apariii n presa din Romnia. Aa arat n cifre prima ediie a colii de antreprenoriat Start Me Up care a avut loc anul trecut la Predeal. Pe parcursul evenimentului, participanii au nvat care sunt paii 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 prezentndu-l n faa unui juriu de specialitate. Fiecare zi a colii de antreprenoriat Start Me Up a fost dedicat unui anumit aspect al planului de afaceri. Astfel, participanii au nceput printr-un proces de generare i selecie de idei, au continuat cu realizarea planului de marketing i respectiv a planului financiar, i au pregtit apoi planul de afaceri i prezentarea propriului proiect. Participanii au avut ocazia s discute n mod direct cu unii dintre cei mai apreciai antreprenori i investitori romni i s afle povetile de succes ale acestora. Printre oamenii de excepie care au fost prezeni la Start Me Up se numr Peter Barta (Director Executiv Fundaia PostPrivatizare), Drago Anastasiu (Preedinte 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 & Asociaii), 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 investiii Phoenix Group i antreprenor serial. n ultima zi a evenimentului, echipele participante au prezentat proiectele dezvoltate pe toat durata programului n faa unui juriu de specialitate. Echipa ctigtoare a dezvoltat Boomerang, o companie de consiliere i orientare profesional pentru elevii de liceu, i a primit o investiie iniial de 2000 de euro pentru implementarea proiectului, alturi de nfiinarea gratuit a afacerii. Un premiu special pentru profesionalism a fost acordat i cofetriei Bartello, iar Bogdan Cange i Vlad Tudose, participani Start Me Up, au primit distincii speciale pentru curaj i respectiv perseveren. n contextul n care ara geme de probleme i toat lumea ateapt s li se dea, voi demonstrai c nu ateptai i vrei s facei ceva. Vzndu-v pe voi realizez c exist o ans pentru Romnia!, ne spunea anul trecut Drago Anastasiu, Preedinte Eurolines i TUI Travel Center. Rezultatele nu au ntrziat s apar i, la un an dup eveniment, impactul acestuia este vizibil. Pregtirea participanilor 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 apreciai antreprenori i investitori romni. Vlad Tudose, alumni Start Me Up care a primit premiul special al juriului pentru perseveren, i-a schimbat ideea iniial de business i a pus bazele unui start-up: Puzzled.by, o platform online de ntrebri i rspunsuri. Puzzled.by a primit deja o finanare iniial de 50.000 EUR de la un grup de investitori americani de tip angel, iar start-up-ul a fost acceptat n competiia organizat n cadrul conferinei internaionale Shift care are loc n Croaia. Pasionat de antreprenoriat, Sebastian Mrloiu este un alt alumni Start Me Up cu o poveste remarcabil. Se pregtea s lanseze versiunea alfa a Bring the Band, platform care permite publicului s i aduc artitii preferai la ei n localitate, cnd a identificat alturi de partenerul su de afaceri o oportunitate unic: Formspring, o platform de socializare cu peste 30 de milioane de utilizatori activi nu i putea susine creterea i urma s se nchid. Sebi i partenerul su au lucrat zi i noapte pentru a profita de aceast oportunitate i au reuit s lanseze dou sptmni mai trziu YouReply, o platform dezvoltat cu o investiie iniial de 50$ care are n prezent peste 14.000 utilizatori. Povetile 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 viei. Ca urmare, echipa Akcees se pregtete de cea de a doua ediie a proiectului care va avea loc n perioada 21 27 iulie la Pensiunea Sperana din Predeal. Reeta succesului este pstrat i de aceast dat: un trainer internaional, antreprenori i investitori romni de succes, participani de claitate i o experien care nu ar trebui ratat de nici un tnr care i dorete s porneasc la drum pe cont propriu. Ineditul acestei ediii const ns n organizarea unei campanii naionale de promovare a antreprenoriatului: Caravana Start Me Up. Intre 20 iunie i 4 iulie, echipa Akcees va susine workshop-uri despre antreprenoriat n 8 orae din Romnia i va aduce n faa audienei antreprenori care au reuit. Pentru Akcees, vara asta st sub semnul antreprenoriatului! Pentru tineri, este vara n care au ansa de a nva cum s-i transforme visele n realitate!
o altfel de coal de antreprenoriat
Start Me Up
Irina Scarlat
11
startups
GO CONNECT are n spate o minunat poveste ce a nceput n seara zilei de 24 mai. 7 tineri antreprenori care nu se cunoteau ntre ei, au venit din trei orae diferite (Cluj-Napoca, Iai, Bucureti) ctre Trgu Mure. Au cltorit sute de km pentru c ideea de Startup Weekend prea s fie o experien grozav. La sfrit s-a dovedit a fi una dintre cele mai frumoase experiene pentru ei, una care nu va fi uitat niciodat, una care poate s le aduc bucurie lor, dar cel mai important altora. Marius Chincian, cel care a avut ideea iniial, i cruia echipa ar dori s i mulumeasc pentru c i-a adus mpreun, a luat emoionat microfonul n mn i a spus c vrea sa construiasc o platform pentru ONG-uri, unde oricine interesat poate s gseasc diverse proiecte sociale i poate s se implice activ ntr-o anumit cauz. Acesta a fost nceputul NGO CONNECT , iar cuvntul magic care i-a reunit pe cei 7 a fost ONG. n acea noapte a nceput maratonul de 54 de orecu toii entuziasmai. S-au strns o mulime de idei care reflectau viziunea fiecruia asupra proiectului. Dup nenumrate ore de brainstorming rezultatul ncepea s prind contur: o platform web care s adune la un loc cele 4 entiti: ONG-uri, voluntari, donatori, i companii. n momentul de fa muncim la dezvoltarea acestei platforme pentru c noi credem cu trie c vom putea schimba lumea n bine i cel mai important, c putem aduce bucurie n vieile 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 aceleai cauze nobile. Se tie c e n natura uman s existe ndoial vizavi de orice. Noi nelegem c oamenii au reineri n a-i pune ncrederea n ceva sau cineva, cu att mai mult legat de banii proprii i de destinaia acestora. Aici intervine NGO CONNECT. Se vrea eliminarea acestor ndoieli printransparentizarea colectrii i cheltuirii fondurilor. Totodat prin intermediul platformei ncercm s ducem implicarea prilor la un alt nivel. De exemplu, dac un proiect vizeaz ajutarea unei fetie cu o situaie material precar,n momenul ndeplinirii scopului cauzei sociale, donatorul va primi un video de mulumire direct de la fetia n cauz, eventual i cteva poze, dar i date de contact ale cazului. Vrem s CONECTM toi factorii cheie din sfera cazurilor sociale i anume: ONG-uri, voluntari, donatori i mai ales corporaii. De ce corporaii? Pentru ca ele au politici i bugete de CSR (Corporate social responsibility ).Responsabilitatea social corporatistreprezint o parte integrant din cadrul oricrei mari companii, prin intermediul creia se implic activ n rezolvarea problemelor societii n care i desfoar 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 competiie. Nu au fost momente n care s se fi separat, sau s i fi dorit s renune i mereu au acionat 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 simit la fel de ctigtori ca i cei de pe locul 1. i nc cevaechipa a avut cu adevrat chimie, se vede i n poza articolului, care i are pe ei n prim plan. Au nceput ca strini i s-au desprit la sfritul weekendului ca nite prieteni. Concluzia este simpl: scopul platformei este s ajute ct mai muli oameni. Pentru c nu este un mit c atunci cnd oferi, primeti napoi dublu. Aceast echip a fost adus mpreun de ctre un singur scop i sper ca toi cei care citesc acest articol se vor implica activ n misiunea noastr, aceea de a face lumea mai bun.
mpreun pentru o lume mai bun!
NGO connect
Echipa NGO Connect contact@ngo-connect.com
12
istorie
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 nfiinarea primei instituii ITC pn la autoorganizarea comunitii actuale ntr-o breasl. Pe scurt contextul istoric, evoluia i situaia actual.
1957 nfiinarea
momentul naterii ITC la Cluj, anul n care Tiberiu Popoviciu, matematician de renume, fondeaz Institutul de Calcul cu Departamentul de Calculatoare prima instituie din domeniul ITC n Cluj. Instituie ce a dat tonul dezvoltrii cercetrii i educaiei, baza comunitii actuale. 1948 - Emil Petrovici fondeaz filiala Academiei Romne din Cluj 1951 - T. Popoviciu fondeaz Secia de matematic a filialei Academiei Romne 1959 - MARICA - calculator cu relee 1960 - Romnia 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 nfiineaz 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 Hngnu 1965 - se nfiineaz departamentul de tiina Calculatoarelor (la UTCN) sub conducerea lui Ioan Dancea 1968 - DACCIC-200 - calculator complet tranzistorizat 1971 - se nfiineaz primul liceu de informatic din Cluj, Liceul de Informatic Tiberiu Popoviciu 1975 - UBB Cluj nfiineaz Centrul de Calcul 1994 - UBB redenumete Facultatea de Matematic cu Facultatea de Matematic i Informatic
7400 absolvenii
n domeniul ITC din 1970 pn azi. Ei sunt produsul instituiilor de mai sus i alctuiesc o mare parte din generaia actual de profesioniti ITC. Au fost formai 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 angajai n ITC la Cluj in peste: 50+ - companii cu mai mult de 50 angajai 2,75% - din 310K locuitori ai Clujului fiind angajai n ITC
27 / 100M+ breasla
este o manifestare natural de cluster n care 27 dintre companiile ITC din Cluj, avnd o cifr de afaceri cumulat de peste 100 milioane de euro se organizeaz n Clusterul IT. Planurile de viitor includ: 300M - Euro investiii pe urmtorii 15 ani 20K - specialiti IT n Cluj Innovation City
196+ / 17+ comunitatea
a organizat cumulat cca. 200 de evenimente, de la ntlniri la bere, pn la evenimente de talie european, prin intermediul celor 17+ comuniti active de profesioniti. Acestea s-au nfiinat 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, Tabra de testare
Marius Mornea
marius.mornea@todaysoftmag.com Inginer interesat i implicat n diverse activiti IT, de la dezvoltare, management, pn la educaie i jurnalistic n cadrul Epistemio, UTCN i TSM
13
comuniti
Comuniti IT Cluj-Napoca
una mai a fost plin de eveniment majore, ne pare ru c nu am ajuns la toate dar v promitem s revenim cu o serie de interviuri i impresii de la acestea n numerele urmtoare.
Calendar
Transylvania Java User Group Comunitate dedicat tehnologiilor Java. Website: http://www.transylvania-jug.org/ Data nfiinrii: 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 nfiinrii: 06.02.2012 / Nr. Membri: 652 / Nr. Evenimente: 9 Romanian Testing Community Comunitate dedicata testerilor. Website: http://www.romaniatesting.ro Data nfiinrii: 10.05.2011 / Nr. Membri: 607 / Nr. Evenimente: 2 GeekMeet Cluj Comunitate dedicat tehnologiilor web. Website: http://geekmeet.ro/ Data nfiinrii: 10.06.2006 / Nr. Membri: 547 / Nr. Evenimente: 17 Cluj.rb Comunitate dedicat tehnologiilor Ruby. Website: http://www.meetup.com/cluj-rb/ Data nfiinrii: 25.08.2010 / Nr. Membri: 134 / Nr. Evenimente: 34 The Cluj Napoca Agile Software Meetup Group Comunitate dedicat metodelor Agile de dezvoltare software. Website: http://www.agileworks.ro Data nfiinrii: 04.10.2010 / Nr. Membri: 324 / Nr. Evenimente: 29 Cluj Semantic WEB Meetup Comunitate dedicat tehnologiilor semantice. Website: http://www.meetup.com/Cluj-Semantic-WEB/ Data nfiinrii: 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 nfiinrii: 10.02.2011 / Nr. Membri: 223/ Nr. Evenimente: 12 Iunie 6 Lansarea numrului 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 Iunie 14 Proiectarea si dezvoltarea unui e-business it-events.ro/events/proiectarea-si-dezvoltarea-unui-e-business Iunie 18 Business Analysis Community Group Meeting it-events.ro/events/business-analysis-community-groupmeeting/ Iunie 19-20 ITC Spring Europe, Luxemburg (recomdarea TSM) www.ictspring.com Mai 23-24 ITCAMP 2013 - Recomandat de TSM http://itcamp.ro Joi/sptmnal OpenConnect www.facebook.com/groups/355893314491424/ Miercuri/bilunar OpenCoffee www.facebook.com/opencoffeecluj
14
programare
Dezvoltarea de aplicaii iOS innd cont de securitate
ecuritatea a devenit din ce n ce mai important n dezvoltarea aplicaiilor mobile datorit informaiilor sensibile/confideniale de pe telefoanele noastre inteligente. Toate ateptrile i estimrile privind utilizarea sunt depite 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 mn a devenit portmoneul erei moderne, plin cu date personale (poze, filme, note) i date confideniale (de sntate, medicale, jurnale, permise sau cupoane).
Cristian Roa
cristian.rosa@isdc.eu mobile developer @ ISDC
Mai mult, exist un trend ce definete mobilele prin prisma modului n care sunt conectate afacerile, indiferent de categorie. Informaii bancare (numr de cont, card de credit, informaii de autentificare, token-uri de securitate) sunt stocate pe dispozitivele mobile sau sunt trimise prin intermediul reelelor wireless nesecurizate aadar exist un risc mai mare dect pentru aplicaiile de desktop. Este aadar esenial ca atunci cnd sunt dezvoltate aplicaii mobile s se in cont de securitate, din cauza multitudinii de atacuri ce pot produce prejudicii semnificative.
face dispozitivul aproape impenetrabil.
Sandbox-ul Aplicaiilor
iOS ngrdete fiecare aplicaie n propriul sandbox la momentul instalrii, fapt ce limiteaz accesul la fiiere, resurse de reea, hardware i date private. Calea ctre directorul home al aplicaiei are forma ../ApplicationRoot/ApplicationID
Arhitectura Apple
Apple a reuit s gseasc, pn acum, cel mai bun echilibru ntre uzabilitate i securitate prin arhitectura sa ce este strns legat de hardware i software. Acest lucru face ca n acelai timp s fie uor pentru clieni s cripteze date pe dispozitivele proprii i pentru hackeri s fie greu s fure i s decripteze informaii confideniale. Piatra de temelie a securitii 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 adnc n memoria flash, ea nsi criptat prin intermediul unei parole de utilizator. Setarea unei tergeri de date dup 12 ncercri euate de introducere a parolei
Chiar dac sandbox-ul limiteaz pagubele pe care un potenial atac le-ar putea produce, iOS-ul nu l poate preveni. Aceasta nseamn c un hacker poate s acceseze informaii confideniale din cadrul sandbox-ului, lsnd dezvoltatorului doar opiunea de a lua contramsuri suplimentare de securitate.
15
programare
Dezvoltarea de aplicaii iOS innd cont de securitate Cripteaz datele ct timp dispozitivul este blocat
de licen, numere de cont, etc. . Pentru a folosi Keychain Services, binarul aplicaiei trebuie s fie legat cu arhitectura Security.framework. Spre deosebire de alte arhitecturi iOS, aceasta este o arhitectur C aa c toate tipurile de apeluri de metode sunt n acel limbaj. n acelai mod n care criptarea datelor ct timp dispozitivul este blocat are niveluri de protecie, la fel i protecia datelor din keychain: ntotdeauna protejat, protejat AfterFirstUnlock sau WhenUnlocked. De asemenea, fiecare clas exist n variaii migrabile i non-migrabile sufixul ThisDeviceOnly ce leag criptarea de un dispozitiv anume. Cea mai bun abordare n folosirea Keychain Access este s declarai un dicionar de cutri de baz folosit pentru toate apelurile ctre serviciile keychain. Acesta va conine atribute ale itemului keychain de creat, gsit, actualizat sau ters. caracteristicile de auto-corectur setnd proprietatea de autocorrectionType la UITextAutocorrectionNo.
Ct timp dispozitivul este blocat, anumite fiiere marcate de ctre dezvoltator pot s fie criptate n mod automat, ns acest lucru presupune permiterea capacitilor de criptare i configurarea lor. n stadiul blocat, sandbox-ul aplicaiei mpiedic accesul altor aplicaii; mai mult, chiar i aplicaia propriu-zis nu are acces. Criptarea se realizeaz prin setarea nivelului dorit de protecie: fr protecie, complet, complet cu excepia faptului cnd e deja lansat i complet pn la prima logare. API-uri ce ofer Protec ia Datelor sunt NSData ce folosesc writeToFile:options:error ; NSFileManager pentru setarea atributelor fiierelor cu setAttributes:ofI temAtPath:error; schimbarea valorii NSFileProtectionKey i opiunea sqlite3_ open_v2 pentru sqlite3. Dup setarea proteciei fiierului, aplicaia trebuie s implementeze nite delegai Cache-ul tastaturii pentru a fi pregtit pentru pierderea temAi observat vreodat c atunci cnd porar a accesului la acel fiier. folosii browsere, auto-complete-ul i intr n rol atunci cnd ncercai s retastai Protecia datelor cu Keychain Access ceva? Ai observat c la fel se ntmpl i Keychain Services este o interfa cu iPhone-urile? Dac nu nc, ar trebui programabil ce v permite s gsii, ad- s tii c toate tastrile de pe un iPhone ugai, modificai i s tergei item-uri din ar putea fi salvate n cache dac nu se iau keychain. Keychain este singurul loc n care msuri pentru dezactivare. Acest lucru este putei stoca date n siguran, deoarece valabil pentru tot ceea ce tastai, cu excepsunt criptate n propriul lor set de item- ia cmpurilor de parol. uri ai aplicaiei. Acestor item-uri\ le este Vestea proast este c aproape orice creat o copie de siguran atunci cnd cuvnd non-numeric este salvat n cache i utilizatorul i sincronizeaz dispozitivele coninutul cache al tastaturii depete priprin intermediul iTunes i vor fi pstrai i vilegiile administrative ale aplicaiei, adic n cazul unei reinstalri. Toate acestea fac nu pot fi ndeprtate din aplicaie. din keychain principalul loc de depozitare a Acest lucru las dezvoltatorului o sindatelor confideniale, cum ar fi parole, chei gur opiune, i anume s dezactiveze
Capturi de ecran automate
Pentru a oferi o experien bogat utilizatorului, iOS are multe efecte de micorare, mpingere, apariie sau dispariie. Totui, acestea au i o latur negativ: atunci cnd aplicaia este mutat n fundal, iOS face o captur automat de ecran a ferestrei iPhone-ului n timp ce efectueaz efectul de micorare i dispariie. Toate aceste capturi de ecran sunt stocate n partea de sistem NANS flash a dispozitivului i sunt teoretic terse dup ce aplicaia a fost nchis. n cele mai multe cazuri, tergerea nu ndeprteaz fiierele permanent de pe dispozitiv. Acestea pot conine date privind utilizatorul i aplicaia. Ca o posibil soluie pentru aceast problem, este nevoie de blocarea cache-ului capturilor de ecran ale aplicaiei folosind un cod sau o configuraie API. Un mod uor de a face acest lucru este folosirea metodei API willEnterBackground, n care se poate implementa tergerea informaiilor confideniale. Apoi putei crea un ecran animat pe care aplicaia s l afieze n timp ce se mut n fundal.
Punerea n cache a datelor aplicaiei
Datele aplicaiei pot fi capturate ntr-o varietate de artefacte, cum ar fi fiiere de log/debug, cookies, fiiere list de proprieti sau baze de date SQLite. n timp ce fiierele list de proprieti, bazele de date SQLite i fiierele/documentele comune pot fi criptate oferind astfel un nivel de siguran, fiierele de log, debug sau crash sunt potenial accesibile.
16

Dac aplicaia se blocheaz, rezultatul este logat, lsnd atacatorului o potenial soluie pentru a sustrage date confideniale. Luai de asemenea n considerare dezactivarea NSAssert pentru iOS pentru c aplicaia 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 dezactivai logurile nainte de a publica aplicaia; acestea pot s stocheze date confideniale. Dezactivarea acestora pot s previn scurgerea de informaii confideniale i de asemenea se poate vedea o mic cretere n performan. la imaginea de mai jos. Sunt sigur c ai vzut asta n multe aplicaii iOS. Atunci cnd utilizatorul cere o operaiune de copiere sau tiere pe o bucat selectat din interfaa utilizatorului, un obiect scrie datele pe un pasteboard. Dac nu este setat un nivel adecvat de securitate, alte aplicaii pot avea acces la datele salvate anterior crend astfel riscuri mari de securitate. De asemenea, persistena acelor date trebuie controlat, deoarece, dac atributele nu sunt setate n mod corect, informaia copiat va fi stocat necriptat n sistemul de fiiere al telefonului i va fi meninut chiar i dup nchiderea aplicaiei. Ca o ultim remarc, s inei minte c practicile de securitate doar ngreuneaz viaa hackerilor. Nu se poate s v asigurai n proporie de 100% c msurile dumneavoastr nu vor putea fi ocolite. La urma urmei, toate versiunile de iOS au fost sparte/decodate. Dei devine din ce n ce mai greu pentru hackeri, ar trebui s v pregtii pentru situaii neprevzute. La urma urmei, trebuie s gsii proporia adecvat ntre uzabilitate i practici de intimidare ce vi se potrivesc cel mai bine dumneavoastr, clientului i utilizatorilor dumneavoastr. Mulumiri 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
PasteBoards
Clasa UIPasteboard permite unei aplicaii s mprteasc date n cadrul aplicaiei sau cu alt aplicaie folosind pasteboards la nivel de sistem sau specifice pentru aplicaie. Sun cunoscut? Uitai-v
17
conferin
JQuery Europe 2013

n web developer, Haymo Meran i fantoma prinului 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 ntmpl 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 vzut nici un semn c duhul prinului ni s-ar fi alturat, i am fost 300 de developeri (sau mai bine zis, entuziati jQuery), nu unul. Restul totui e chiar foarte adevrat i cu siguran nu o glum, pe ct de fabulos sun.
Andrei Otta
andrei.otta@accesa.eu Software developer @ Accesa
ntr-adevr, 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 excepional a fost Pe aceasta cale in s mulumesc organizatorilor, Gentics Software, i n special domnului Haymo Meran (CTO-ul Gentics i o foarte prietenoas gazd) pentru c au fcut posibil acest eveniment i s-au descurcat destul de bine n voiajul inaugural. Probabil singurul minus (amuzant) care merit menionat e afirmaia c participanii care ajung la staia de metrou Rossauer Lnde vor fi ghidai ctre locaia evenimentului de ctre o persoan purtnd un tricou personalizat pentru conferin. De ce ar fi asta amuzant, m ntrebai? Aceasta este Viena n prima zi a conferinei: Nu tocmai cea mai potrivit vreme
de umblat n tricou i dus lumea la conferine Dar destul cu deraiatu, s trecem la detaliile picante propriu-zise! Conferina s-a ntins pe durata a dou zile, din 22 pn n 23 februarie, i a fost plin ochi de Javascript, jQuery, CSS i alte bunti livrate de cei 16 vorbitori, presrate ici i colo cu prticele mai ciudate cum ar fi banane care cnt i coctail-uri tropicale. Evenimentul a nceput cu o bomb! Stai calmi, nu a fost nici un fel de atentat, securitatea a fost foarte strict, cu cteva sosii ale lui James Bond mereu cu ochii pe mulime dup cum putei vedea mai jos
Nu, bomba la care m refer descrie impactul primei sesiuni, al crei vorbitor a fost nimeni altul dect Richard D. Worth, directorul executiv al fundaiei jQuery. Dl. Worth a prezentat starea curent a jQuery,
18

acum la versiunea (stabil) 1.9.1, i a oferit o mic viziune asupra viitorului, invitnd participanii s se alture comunitii jQuery. Participanii au fost apoi incitai cu bucele de informaie despre urmtorul mare pas pentru jQuery, versiunea 2.0, dintre care de departe cel mai ovaionat (aclamat i aplaudat furtunos) a fost anunul c, ncepnd cu versiunea 2.0, jQuery nu va mai suporta Internet Explorer 8 (sau versiuni mai vechi). tiu, tiu, jos plria n faa lor pentru c au nchis ua i-au ncuiat-o bine i l-au lsat n strad pe ncul cel enervant care mereu face lucrurile altfel dect restul Totui, nefiind oameni cruzi i fr mil pentru bietele suflete care au nevoie ca site-ul lor s nu crape oribil pe IE, echipa jQuery va menine versiunea 1.9.1 n paralel cu 2.0, duplicnd n 1.9.1 tot ce se va dezvolta n 2.0 i mai departe, atta timp ct nu necesit cantiti industriale de adaptare. Dl. Worth a trecut de asemenea n revist modificrile recente n componente adiacente jQuery cum ar fi jQueryUI sau jQuery Mobile i a adus la lumin cteva iniiative jQuery, precum contribute. jquery.org (pentru cei interesai n a contribui la jQuery), plugins.jquery.com (noul i mbuntitul registru de plugin-uri) sau learn.jquery.com (dac URL-ul nu v-a dat un indiciu, aceasta e o iniiativ ndreptat ctre persoanele care vor s nvee jQuery). Considernd 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 zgazurile mentale i dnd drumul uvoiului de gnduri) al restului unei zile cu adevrat fascinante. Urmtorul 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 privete separarea codului Javascript/jQuery de CSS i HTML, lucru care ne va aduce mult mai mult mentenabilitate i mai puine dureri de cap. A facut de asemenea i o incursiune n lumea tranziiilor i animaiilor CSS i a echivalentului lor n jQuery. Sebastian Kurfrst a artat cum, folosind RequireJS, ne putem organiza codul Javascript n componente i s mbuntim claritatea n codul de client. Jrn Zaeffer ne-a deschis urechile i minile ctre modul n care web-ul e perceput de cei care nu pot experimenta lumea prin intermediul vzului, o categorie semnificativ de oameni de care din nefericire uitm deseori. Trebuie s recunosc c mi-a dat un sentiment de umilin, tristee chiar, s aflu cum sun unele pagini web. N-am fost pus nc ntr-o situaie n care a trebuit s m gndesc la accesibilitate i e greu s ai aspectul acesta n minte cnd eti n frenezia alinierii de pixeli i a ajustrii tonurilor de culoare, dar e ceva ce ar trebui luat mereu n considerare. Am vzut apoi de ce e n stare jQuery pe server ntr-o prezentare foarte ptrunztoare de ctre Golo Roden a Node.js, o unealt excepional de puternic pentru oricine e interesat de lucruri precum web scraping, crearea de web servere uoare sau aplicaii distribuite cu trafic intens de date. Urmtorul vorbitor n aciune, Sascha Wolter, e probabil persoana cea mai asemntoare cu un geniu nebun pe care am vzut-o pn acum, dar n modul cel mai bun. A fcut lucruri cu Javascript la care nu m-a gndi nici n cele mai creative zile. De la controlat roboi LEGO sau quad copters i trimis SMS-uri la aparate de fcut cafea pn la a chiar face banane s cnte, am savurat fiecare fascinant secund (s nu mai vorbim c am copt cteva idei nebune proprii de ncercat). Ziua s-a ncheiat cu prezentarea inut de Christian Heilmann, care a lansat o ntrebare foarte interesant: oare uneltele (librrii Javascript, frameworkuri, plugin-uri, etc.) pe care le folosim ne ajut sau ne fac ru? E bine s folosim unelte ca s facem procesul de dezvoltare mai rapid sau s dm mai mult claritate codului, dar e esenial s nelegem ce e de fapt n spatele acestor unelte, ce le face s funcioneze, ce le face atta de bune i ce le-ar putea face i mai bune. mi aduc aminte de cteva cifre menionate de dl. Worth n prezentarea de deschidere: 55.7% din site-urile existente n momentul de fa pe vastele cmpii ale internetului folosesc jQuery. Aceasta nseamn 90.7% din toate site-urile care folosesc Javascript. O majoritate copleitoare fr ndoial, dar stau s m ntreb oare ci 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 nuntru s vad ce soi de magiee n spatele framework-ului care le face viaa aa de uoar... i-aa am ajuns la a doua (i din pcate 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 capabilitile de RWD (Responsive Web Design) incluse n framework-ul jQuery Mobile i a artat cteva exemple reale de utilizare a media
19
conferin
JQuery Europe 2013
fost prezentat a fost foarte impresionant din punct de vedere vizual i fr ndoial de ultim or. Toate uneltele moderne de ncntat ochiul, cum ar fi CSS3, SVG, Canvas sau WebGL i-au primit o porie sntoas de atenie 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 etalri creative i uimitoare privirea. i apoi a trebuit s plec... i dei am avut o mic doz de regret pentru c am ratat o prticic, am fost extrem de satisfcut de ce am putut experimenta pe parcursul celor dou zile... i am plecat chicotind puin la gndul c m voi ntoarce pentru conferina de anul viitor, care garantat va avea loc, dup spusele lui Haymo. Cine tie ce va aduce 2014? query-urilor i a gndirii mobile-first n construirea coninutului responsiv, fie el pentru site-uri sau app-uri. De asemenea au fost evideniate cteva tehnici de mbuntire a performanei n ceea ce privete minimizarea utilizrii limii de band, utilizarea imaginilor cu rezoluii mari i stratificarea selectiv a coninutului n funcie de capabilitile dispozitivului. Maximilian Knor, un developer evangelist la Microsoft, a demonstrat cum ASP.NET MVC i ASP.NET SignalR (http://www. asp.net/signalr ncercai-l daca n-ai fcuto deja) construiesc peste jQuery i jQuery Mobile pentru funcionaliti client-side i aplicaii de o singur pagin. Mike West a evideniat esenialul securizrii codului de client mpotriva inteniilor maliioase, fie ele cross-site scripting sau alte forme de atac. Mai bine zis, a diminurii efectelor unui asemenea atac ca sa fiu sincer, pentru c dei am crede c am scris codul n aa fel nct 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 adugm cteva straturi pe zidul de crmid i chiar i atunci s ne dm seama c nu e destul de solid. Reinem prezentarea lui Patrick Lauke i Web on TV, o descriere a modului n care jQuery poate fi folosit pentru a interaciona cu televizorul dumneavoastr. n ziua de azi, orice companie respectabil care produce televizoare probabil are cel puin un reprezentant al generaiei SmartTV i n civa ani probabil cu greu ne vom aduce aminte de vremea cnd nu puteai s navighezi pe internet pe televizorul tu sau s te uii la YouTube sau s joci Angry Birds. Ce nseamn asta, pe lng un set nou de bti de cap n ceea ce privete suport inclus n site-uri sau app-uri pentru multiple dispozitive, e c folosind puin cunotin de Javascript/ jQuery am putea crea interfee 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, graie lui Dyo Synodinos. Primul pas al iluminrii a fost n legtur cu picturile de pe tavanul mreei i magistral decoratei sli n care ne aflam, care surprind scene din viaa 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 legtur cu prezentarea despre ultimul rcnet n materie de vizualizri ce urma i nu era nici pe departe umplutur de introducere. ntr-adevr, ceea ce a
20
HR
Managementul performanei (II)
doua parte a articolului dedicat managementului performanei va prezenta mijloacele utilizate n acest proces, precum i cteva modele care pot fi uor 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 performanei, care cuprinde: (1) definirea comportamentelor necesare pentru trirea celor cinci valori ale companiei, (2) obiectivele echipei: descrierea acestora, modalitatea de msurare a obiectivelor i rezultatele ateptate i (3) obiectivele individuale, care trebuie s fie aliniate cu obiectivele echipei. Obiectivele trebuie s fie SMART, obiectivelor. iar indicatorii de performan vor fi 1. Rezultatele : sunt produse finite, definii pentru fiecare obiectiv i valoare servicii, informaii care sunt ofea organizaiei n parte. rite clienilor. Rolul lor este de a Managerul este responsabil penndeplini ateptrile i cerinele acestora. tru alinierea obiectivelor cu cele Rezultatele eficiente trebuie s: organizaionale. se refere la obiectivele cheie ale afacerii i/sau prioritile funcionale Indicatorii de perfoman cheie, Este necesar a fi definii indicatori de fie formulate din perspectiva perfoman pe fiecare arie. Acetia sunt clientului, folosii pentru definirea obiectivelor de fie formulate ca stare final, echip. Formularea obiectivelor trebuie s includ obiective manageriale i fie un proces orientat spre clieni i pe facde leadership, torii interesai i trebuie s ia n considerare includ auto-dezvoltarea, indifetrei aspecte eseniale: rezultatele, cerinele rent de rol. de calitate i indicatorii de performan. Pentru o mai bun nelegere a aces2. Cerinele de calitate: descriu rezultui model, n continuare vor fi explicate tatul oferit ca i cnd acesta ar fi excelent toate cele 3 aspecte i rolul lor n definirea din perspectiva clientului i trebuie s
n cadrul fiecrui departament este indicat s existe un nivel general al perfomanei stabilit pe baza rezultatelor obinute n anii anteriori. De asemenea este indicat ca n fiecare lun s se ntocmeasc rapoarte pentru definirea nivelului de perfoman n cadrul echipelor. Perfomanele 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, activitile care contribuie la ndeplinirea obiectivelor i competena mbuntit. Activitile de dezvoltare sunt dintre cele mai diverse: de la programe de pregtire pentru angajai, la training la locul de munc, materiale electronice.
Scara de notare a performanei
Realizrile sunt evaluate pe o scar a performanei cu 6 niveluri, aa cum se poate observa n tabelul 1.2. Evaluarea se face cu ajutorul a dou dimensiuni: rezultatele obinute (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 ateptrilor) avnd feedback constant din partea managerului. Criterii pentru definirea obiectivelor: Obiectivele individuale vor fi n corelaie cu obiectivele echipei. Minimum un obiectiv al echipei i minimum trei obiective individuale.
Figura 1 de definire a obiectivelor n interiorul companiei
21
HR
Managementul performanei (II)
conin caracteristici ale valorii aduactiveaz i poate indentifica n acelai gate pentru a descrie CE-ul i CUM-ul timp viitoare tentine ale mediul extern performanei. i intern. 3. Indicatorii: au rolul de a spune dac i cum fiecare echip/individ a perforPe lng aceste competene de leamat fa de obiectivul stabilit, cu privire dership , persoanele care au poziii de la CE-ul i CUM-ul performanei. Mai management au un profil pe care trebuie s mult dect att indicatorii trebuie s fie l ndeplineasc. agreai anterior stabilirii obiectivelor. o cultur a performanei, iar acetia s devin acei ageni ai schimbrii n interiorul companiei. Problema care este adesea adus n discuie se refer la procesul de identificare i de alegere a campionilor managementului performanei. Principalele caracteristici pe care acetia trebuie s le aib sunt: nelegerea procesului de management al performanei i impactul acestuia n companie; competen n diverse aspecte (capacitate de nelegere a sistemului de notare a performanei, capacitate de a organiza ntlniri, capacitate de influenare); 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 angajailor, 2. Managementul talentului, adic dezvoltarea carierei tuturor angajailor, 3. Planul individual de dezvoltare, pe care angajaii, mpreun cu superiorul direct ar trebui s l realizeze. Succes n implementarea unui sistem de managementul performanei care s aduc cele mai bune rezultate att pentru angajai ct i pentru companie.
Competene de leadership i management
Campionii managementului performanei
Pentru un proces sustenabil de managementul performanei, este recomandabil crearea unui catalog al competenelor i abilitilor tehnice pe care fiecare angajat trebuie s le aib pentru a ndeplini responsabilitile postului. Competenele de leadership pe care le sugerez a fi folosite sunt cele enumerate mai jos. Se va pstra i denumirea n limba englez pentru a nu schimba semnificaia cuvintelor. Orientarea ctre oameni ( People leadership) care pune accentul pe capacitatea individului de a comunica, de a-i coordona pe ceilali i de a lucra la rndul su ntr-o echip. Leadership personal (Personal leadership ) capacitatea de a se adapta la situaii i medii noi i nu n ultimul rnd inteligena emoional. 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 nelege mediul de business i organizaia n care
Companiile ofer angajailor posibilitatea de a beneficia de ajutorul campionilor managementului performanei, care sunt grupai n dou categorii: (1) cei care au cunotine despre managementul performanei care pot oferi suport celor care sunt implicai n acest proces i (2) persoanele cu performane ridicate care sunt promovate n cadrul companiei n cadrul diferitelor evenimente de recunoatere a meritelor. Rolul acestora este de a: identifica, selecta i motiva un grup de ageni ai schimbrii care s contribuie la implementarea procesului n interiorul companiei; educarea echipelor i a indivizilor pentru a-i familiariza cu aplicaiile strategice ale managementului perfomanei; Modelul FLAME poate fi aplicat n orice companie. Pentru o viziune mai clar asupra rolului campionilor managementului performanei, se vor exemplifica situaii caracteristice acestui model, unde F facilitarea, L leaderi prin exemplu, A acioneaz ca o consecin, M msoar, E educ. Cheia reuitei este de a educa i de a le insufla celorlali membri ai echipei
Andreea Prvu
andreea.parvu@endava.com Recruiter n cadrul Endava
22

Definirea ateptrilor Descrierea obiectivului Cum se msoar? Revizuirea intermediar a obiectivelor Descrierea obiectivului Cum se msoar? Rezultate Scor (an anterior) Nivelul performanei (an anterior) Descrierea obiectivului Cum se msoar? Rezultate Scor ( an anterior ) Nivelul performanei ( an anterior ) Cum se msoar? Rezultate Nivelul Performanei Scorul este opional Scor total Evaluarea perfomanei Descrierea obiectivului Cum se msoar? Rezultate Scor (an anterior) Nivelul performanei (an anterior) Descrierea obiectivului Cum se msoar? Rezultate Scor ( an anterior ) Nivelul performanei ( an anterior) Cum se msoar? Rezultate Nivelul Performanei Scorul este opional Scor total Obiective de Dezvoltare Activiti de dezvoltare Competena dezvoltat n urma activitii de dezvoltare Rezultatul planului de dezvoltare
Obiective echip (cel puin una dintre subseciuni trebuie completat) Obiective Individuale (cel puin una dintre subseciuni trebuie completat) Valorile companiei
Descrierea obiectivului Cum se msoar?
Cum se msoar?
Nivelul General al Perfomanei Scorul Total al Evalurii ( an anterior ) Plan de Dezvoltare Profesional (cel puin un plan trebuie completat)
Scorul nu este disponibil Scor total (100% pentru validare ) Obiective de Dezvoltare Activiti de dezvoltare
Obiective de Dezvoltare Activiti de dezvoltare Competena dezvoltat Competena dezvoltat n urma n urma activitii de activitii de dezvoltare dezvoltare
Tabel 1.1. Model formular stabilire obiectivelor
Nivel Denumire nivel 5 Excepional
Descrierea nivelului din punct de vedere al rezultatului Performana obinut a fost peste obiectivele definite, prin propriile abiliti. Depsete constant ateptrile angajaiilor pe aceast poziie. Exceleaz n a ndeplini cerinele clienilor n termenul limit stabilit. Perfomana obinut a fost peste obiectivele definite, cu un minim de supervizare, demonstrnd n acelai timp iniiativ i independen n soluionarea problemelor. Performana obinut ndeplinete obiectivele definite, cu suport din partea superiorului direct.
Descrierea nivelului din punct de vedere al valorilor Este un model pentru ceilali n ceea ce privete trirea comportamentelor caracteristice fiecrei valori. Demonstreaz constant trirea comportamentelor fiecrei valori. Demonstreaz efectiv trirea comportamentelor caracteristice fiecrei valori.
4 3 2
Obiectiv depit Obiectiv ndeplinit Obiectiv ndeplinit parial Obiectiv nendeplinit Nemsurabil
Performana obinut ndeplinete parial 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 mbuntirea competenelor i a abilitilor. Performana obinut este sub obiectivele definite. Este nevoie de suportul constant al superiorului direct pentru ndeplinirea responsabilitilor postului. Angajai noi n cadrul companiei (mai puin de 6 luni). Majoritatea comportamentelor demonstrate nu sunt n concordan cu valorile.
1 0
Tabel 1.2. Scara de notare a performanei
Obiectivul: ______________________________________________________________ Numele echipei/ membrului individual ________________________________________ Rezultat Cerine de calitate Indicatori
Tabel 1.3. Modelul de definire al obiectivelor

23
programare
Din uneltele artizanului software: Unit Testing

maginai-v urmtoarea situaie: o echip a dezvoltat timp de 6 luni un produs grozav, care se vinde imediat. Utilizatorii i arat pasiunea pentru produs cernd mereu funcionaliti noi. Dac echipa nu livreaz noile funcionaliti destul de repede, fericirea lor va scdea, 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
Din pcate, validarea complet a produsului de ctre echipa de testare poate dura sptmni, dac nu luni. i asta fr a lua n calcul timpul necesar rezolvrii bugurilor gsite de testeri. Nu se poate aadar ca echipa s livreze la timp dac produsul este complet testat. Ce e de fcut? Alternativele cele mai comune sunt: testarea exclusiv a funcionalitilor noi, cu sperana c cele vechi nu s-au modificat; analiza impactului modificrilor i testarea exclusiv a funcionalitilor afectate; utilizatorii vor testa ntr-o perioad de stabilizare. Toate soluiile de mai sus nseamn scderea temporar a grijii acordate produsului, pentru a asigura livrarea ct mai rapid. Din pcate pentru echipa din scenariul descris mai sus, se asum riscuri care pot avea impact major asupra afacerii. Riscul major este scparea din vedere a unor zone din aplicaie i livrarea cu buguri. Acest risc poate duce la: Scderea mulumirii utilizatorilor i la apariia detractorilor. n afaceri, la fel ca n via, e greu s ctigi ncrederea unei persoane dar e foarte uor 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 nelegerea lui, rezolvarea, testarea i punerea n producie a noii versiuni. Costurile se acumuleaz n: call center, dezvoltare, testare, operaional.
Costul de oportunitate: ct timp echipa de dezvoltare rezolv bug-uri, competiia poate scoate funcionaliti noi care vor atrage utilizatorii. Rezolvarea bug-urilor este echivalent din punctul de vedere al afacerii cu alergatul pe loc.
Dar dac...
Adrian Bolboaca
adrian.bolboaca@mozaicworks.com Programmer. Organizational and Technical Trainer and Coach @Mozaic Works
Echipa ar putea valida ntreaga aplicaie n ore i nu n sptmni sau luni? Dac fiecare programator ar putea afla la fiecare mic modificare n cod, n cteva minute, c nu a stricat nimic (cu o probabilitate de 80+%) Articolul despre Software Craftsmanship, publicat n numrul 11 al Today Software Magazine, menioneaz ideea principal de la care a pornit micarea: un software craftsman poate livra calitate sub presiune. n aceast situaie, un software craftsman ar trebui s livreze funcionaliti noi n timpul alocat cu ct mai puine bug-uri. Ct de puine? Mai puin de 10 per release. Acest numr este conservator, pentru c metodele agile (inclusiv Scrum) au cerut de la nceput ca la finalul fiecrui sprint de 2-3 sptmni, echipa s livreze software cu 0 bug-uri cunoscute, dup ce aplicaia a fost validat de testeri.
Dar orice aplicaie are bug-uri!
Denumirea de bug este un eufemism pentru greeal. Greelile sunt normale n orice activitate uman, chiar i atunci cnd dezvoltm software. ntrebarea este cum poate fi redus numrul de greeli i impactul lor. Unit
24

testing este o unealt care poate ajuta, dar nu este singura. Alte unelte care pot ajuta sunt: code review, pair programming, reducerea numrului de linii de cod, design by contract.
Service{ public boolean valueToReturnOnPay; public boolean pay(Money amount){ return valueToReturn; } } 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); } } mock(PaymentService.class); PaymentProcessor paymentProcessor = new PaymentProcessor(paymentServiceMock); paymentProcessor.processPayment(amount); verify(paymentServiceMock).pay(amount); } }
Unit testing
Testarea unitar se refer la scrierea unor buci de cod, denumite cod de testare, care valideaz codul de producie. Testarea majoritii aplicaiei devine aadar 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 informaii despre execuie. Testele automate care rulau n acelai timp cu programul ddeau informaii mult mai bogate legate de sursa greelilor. Ce facem cu testerii? O temere ntlnit adesea este c testerii i vor pierde locul de munc o dat cu introducerea testrii automate. n realitate, testerii devin mult mai importani pentru c acum doar ei pot descoperi problemele ascunse, greu sau imposibil de gsit prin teste automate. Ei ajut s creasc probabilitatea c totul funcioneaz corect de la 80+% la aproape 100%. Testele unitare au cteva caracteristici importante: fiecare test valideaz un comportament din aplicaie; ruleaz foarte repede, maxim n cteva minute; sunt foarte scurte i uor de citit; ruleaz la apsarea unui buton, fr configurri suplimentare. Pentru a fi rapide, testele unitare folosesc adesea aa-numitele duble de testare. La fel cum piloii de avioane nva ntrun simulator nainte de a se urca n avion, testele unitare folosesc buci de cod care seamn cu codul de producie, dar n realitate folosesc doar la teste. Stub-urile i mock-urile sunt cele mai ntlnite duble de testare, existnd multe altele mai puin folosite. Un stub este o dubl de testare care ntoarce valori. Stub-ul este similar cu o simulare foarte simpl: atunci cnd apei un buton, apare o valoare. n cod, un stub poate arta astfel:
class PaymentServiceStub implements Payment-
Un mock este o dubl de testare care valideaz colaborarea ntre clase. Mock-ul valideaz apeluri de metode, cu anumii parametri, de un anumit numr 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); } }
Iniial 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, dnd natere metodei mockiste de testare unitar. Pentru mai multe detalii, articolul Mocks arent stubs de Martin Fowler 1 este edificator. Testele unitare sunt scrise de programator, n timp ce implementeaz o funcionalitate. Din pcate, cel mai ntlnit mod de a scrie teste este cndva dup ce a fost terminat implementarea. Rezultatul este c testele sunt scrise avnd n minte cum ar trebui s funcioneze codul i nu testarea lui. Test First Programming este o metod de a scrie teste care implic urmtorii pai: crearea unui design pentru implementarea funcionaliti 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 soluiei. 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); 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 =
Dureaz mai mult cnd scriu teste!
Studiile de caz2 i experiena personal a artat c ntr-adevr, timpul petrecut strict pe dezvoltarea unei funcionaliti crete o dat cu adoptarea unit testing. Aceleai studii au artat c timpul petrecut pe mentenan scade drastic, artnd ca unit testing poate aduce o mbuntire
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
25
programare
net n timpul de dezvoltare. Acest fapt nu poate schimba percepia programatorului care trebuie s scrie mai mult cod. De aceea, programatorii presupun adesea c per total proiectul merge mai ncet din cauza testrii automate. cu zi astfel nct productivitatea s fie ct mai puin afectat; 3. Testarea automat n primul rnd a celei mai importante pri din aplicaie i apoi a funcionalitilor cu cel mai mare risc de greeal; 4. Folosirea strategiei de testare de tip Piramida testelor3pentru a elimina ct mai multe greeli cu putin; 5. n cazul n care exist mult cod (legacy code), este recomandat nvarea unor tehnici suplimentare pentru a scrie teste pe cod existent. Mai multe detalii ntr-un articol viitor. putei afla dintr-un blog post de acelai autor, 5 common unit testing problems de la adresa http://mozaicworks.com/ blog/5-common-unit-testing-problems/.
Concluzie
Cum ncep?
Este bine ca adopia unit testing s se fac cu grij, incremental, urmrind cteva puncte importante: 1. Clarificarea conceptelor legate de unit testing nainte de a ncepe scrierea de teste.Programatorii trebuie s poat mnui fr team unelte precum: stub-uri, mock-uri, teste de stare, teste de Greeli comune colaborare, teste de contract, dependency Cteva greeli comune legate de unit injection. De asemenea, programatorii testing sunt: trebuie s neleag 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 cteva modaliti integrare(care implic mai multe clase prin care programatorii reuesc s stpsau module) lente i fragile n detrimenneasc aceste concepte: tul testelor unitare mici, rapide i uor de training specializat pe unit testing. ntreinut 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 participani. obinerea unor teste scurte i rapide. pair programming ntre un tester 3. Numele testelor nu exprim compori un dezvoltator. tamentul testat. Numele testului poate da pair programming ntre un dezfoarte multe informaii atunci cnd testul voltator experimentat n unit testing pic. i unul nceptor. 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 cri (vezi la pic. Debugging-ul este n continuare util final crii recomandate), de pe intern situaii exotice. net sau prin participarea la evenimente 5. Cod de testare nengrijit. Codul de de comunitate. testare este cel puin la fel de impor participarea la conferine unde se tant ca i codul de producie, i trebuie discut concepte de unit testing. ntreinut cu aceeai grij. 2. Un coach tehnic poate lucra cu programatorii, ajutndu-i s transfere Mai multe detalii despre aceste probleme informaiile teoretice n practica de zi 3 http://martinfowler.com/bliki/TestPyramid.html
Unit testing-ul este una dintre metodele pe care un programator o poate folosi cu scopul de a reduce numrul de greeli pe care le face cnd scrie cod. Folosit corect, unit testing-ul poate reduce semnificativ timpul petrecut cu repararea bug-urilor din aplicaii, reducnd ncrcarea colegilor care se ocup de suport i testare i permind introducerea de noi funcionaliti mai repede, ceea ce conduce la competitivitate crescut. Dar unit testing-ul trebuie adoptat cu grij, urmnd practicile din industrie (piramida testelor, folosirea dublelor de testare etc). Ajutorul extern (training i coaching tehnic) poate face diferena ntre o adopie reuit i una cu probleme. Un software craftsman stpnete unit testing i l folosete atunci cnd e nevoie s se protejeze de greeli, fie ale sale fie ale colegilor de echip. Aa este sigur c poate livra software fr bug-uri chiar i atunci cnd e sub presiunea timpului. Cu condiia, evident, s nvee unit testing att de bine nct s l foloseasc cu uurin chiar i atunci cnd e sub presiune.
Cri recomandate
The Art of Unit Testing, Roy Osherove xUnit Test Patterns, Gerard Meszaros Growing Object Oriented Software Guided by Tests, Steve Freeman, Nat Pryce
26
QA
Behavior Driven Development n Python
n ziua de azi, testerii sunt privii ca fiind cei care execut munca de rutin, de o dificultate mai uoar, i ale cror skill-uri tehnice nu sunt att de puternice pe ct cele ale programatorilor. Exist echipe fragmentate, dou tabere practic: developeri i testeri. Accentul nu se pune pe comunicare i colaborare, ci se investete efort i energie n acel vechi battle, n care fiecare dorete s demonstreze c echipa proprie e mai bun. Astfel de situaii au dus n final la apariia conceptului de Testers = second class citizens. Ce nseamn acest lucru mai exact? Nu se lucreaz constructiv mpreun, unde att testerul ct 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). ...este unul complex, unde lucreaz o echipa de aproximativ 50 persoane. Dac nu am insista foarte mult pe colaborare i comunicare, nu am reui s facem fa metodologiei Kanban ce o abordm, ce presupune un numr mare de teste automate, iniiativ i proactivitate din partea tuturor. Cum am ajuns noi s depim aceast situaie? Prin efort colaborativ i comunicare. Testerii nu trebuie s atepte 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 mndri 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 fr un numr 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 discuii n prealabil, care consum din timpul necesar scrierii i executrii testelor. Poate v gndii c o simpl abordare Agile-Scrum ar fi suficient, pentru c detaliile necesare implementrii i testrii unui feature nou se pot stabili n cadrul unui meeting de stand-up. Dar cred c tii cu toii c aceste meeting-uri pot devia de la formatul lor standard, depindu-se deseori numrul de 15 minute alocate n mod ideal, i nu se ajunge la un consens n ceea ce privete rolul fiecrui membru al echipei.
Ramona Suciu
Test Lead @ 3Pillar Global
ramona.suciu@3pillarglobal.com
Proiectul nostru
Dan Pop
dan.pop@3pillarglobal.com Senior Test Engineer @ 3Pillar Global
Pentru a mbunti i mai mult lucrul n echipa noastr, ne-am ndreptat atenia ctre Behavior Driven Development1, o metodologie ce se axeaz pe comunicare i colaborare ca puncte forte. Definiii pentru
1 http://dannorth.net/introducing-bdd/
Concepte teoretice Behavior Driven Development
27
QA
Behavior Driven Development n Python
BDD sunt multe, dar noi v prezentm cteva dintre conceptele BDD aa 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 uor de neles de ctre toat lumea. Vorbim aici de limbajul Gherkin (Given-When-Then), care permite i persoanelor non-tehnice din echip s contribuie la scrierea i meninerea testelor. 2. Comunicarea i Colaborarea reprezint fundamentele BDD. Fr aceste dou concepte, BDD nu poate fi aplicat cu succes. 3. Diferite perspective asupra sistemului sunt oferite atunci cnd se aplic BDD. i acest lucru este posibil pentru c BDD ne d ocazia s punem cteva ntrebri 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 Rspunznd la ntrebri de acest gen, putem s privim produsul din prisma product owner-ului, fiind capabili astfel s nelegem 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 relaionare cu clienii este un alt avantaj ce rezult aproape fr efort. 5. L i v i n g d o c u m e n t a t i o n - Documentaia format din testele scrise Dup cum v putei 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, aceeai reet BDD Practic, paii ce i urmm noi din ce funcioneaz pentru un proiect aducnd momentul n care apare o idee de feature alte rezultate dac aplicat altui proiect. nou, pn cnd aceasta se materializeaz Sunt multe challenge-uri ce pot aprea de-a sunt urmtorii: lungul timpului, iar noi am ncercat s le 1. Echipa de management are o idee abordm pe fiecare n parte, evitnd pe ct 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 soluie tehnic. duct management Aceast abordare este greit i aici este Challenge : rolul PO-ului este un aspect asupra cruia BDD ne permult mai mare ntr-un proces BDD, mite s lucrm. Product managementul iar aportul lor la scrierea i meninerea trebuie s propun ideea, iar toat testelor n limbajul Gherkin trebuie s echipa contribuie la gsirea celei mai fie ntr-un procentaj mai mare dect cel eficiente soluii tehnice. al echipei tehnice. n cazul nostru, nc 2. n mod ideal, product managemennu am ajuns n aceast situaie. innd tul i business analyst-ul particip la cont de timpul limitat pe care PO-ul l discuiile preliminare, unde se pun ntrepoate acorda acestui task, developerii brile cheie i se clarific diverse aspecte. i testerii sunt cei care scriu scenariile n lipsa unui business analyst, noi Gherkin, acestea urmnd a fi revizuite am descoperit c cel puin n acest caz, periodic mpreun cu managemenatribuiile business analyst-ului pot fi tul. Este o soluie de compromis ce preluate de ctre echipa tehnic: tech funcioneaz n acest moment pentru leads, developeri, testeri. echipa noastr. 3. Se discut pe seama ideii, pn cnd 2. Folosirea ct mai eficient a limbase ajunge la un consens asupra soluiei 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 soluie venit direct din BDD, dei n aparen poate prea despartea product management-ului, ci ca tul de simplu. A scrie teste astfel nct un rezultat al efortului colaborativ din s fie uor de neles, uor de meninut, partea ntregii echipe, ajungndu-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
Product Development
Product Support
3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world.
Our oerings are business focused, they drive real, tangible value.
www.3pillarglobal.com
28

Challenge : documentaia 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 situaia actual a codului, ii. s fie accesibil tuturor iii. s fie uor de neles, uor de meninut iv. presupunnd c se dorete o schimbare major, ntr-un sistem legacy , Living Documentation poate reda riscurile ce pot aprea ca urmarea implementrii schimbrii respective. Acest lucru este posibil pentru c avnd teste scrise corect n limbajul Gherkin, putem urmri interaciunea dintre componente, prin intermediul testelor, i vom reui astfel s anticipm posibilele riscuri. Am insistat asupra limbajului Gherkin, exemplificnd modul cum se poate descrie un feature prin scenarii scrise cu ajutorul acestui limbaj. Aceste teste sunt inute n acelai loc cu codul, reprezentnd 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 situaia actual a codului. permanen specific BDD, poate fi folosit cu Python 2. BDD depinde foarte mult de context, ...i lista poate continua aa c ncercm mereu s ne adaptm stilul de lucru astfel nct s acoperim particularitile fiecrui proiect 3. Codul scris de developeri trebuie s fie de la bun nceput testabil. Fr acest lucru, nu vom putea s scriem scenarii Gherkin care s ndeplineasc cerinele Living Documentation menionate mai sus. 4. Living Documentation reprezint goal-ul nostru principal pe toat durata existenei unui proiect unde se aplica BDD. BDD este un proces complex, dar avantajele sale sunt multe, i contribuie mult la nchegarea unei echipe n adevratul sens al cuvntului i la livrarea unui produs de succes. Recomandm sincer abordarea acestei metodologii, indiferent de complexitatea proiectului sau dimensiunea echipei. Aplicat astfel nct s in cont de nevoile clare ale proiectului, BDD poate deveni cu uurin o poveste de succes.
Bibliografie
Mai multe informaii cu privire la cum se pot descrie funcionaliti folosind un limbaj ubiquitos2 (Gherkin) , n funcie de tool-ul ales, se pot gsi la:
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
Concluzii
Conceptele BDD aplicate n acest moment cu succes, obin rezultatele dorite, dar suntem contieni de faptul c mai avem mult de lucru. Printre obiectivele noastre n viitor, amintim: 1. C omunic are i col ab orare n
html
2 http://martinfowler.com/bliki/UbiquitousLanguage.
29
QA
Test Driven Development (TDD)

est Driven Development (TDD) este o abordare a dezvoltrii 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 gndi prin prisma cerinelor sau a designului nainte de a ne apuca efectiv a scrie cod funcional (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 crui scop este acela de a scrie cod curat care funcioneaz. Voi descrie o situaie cu care majoritatea suntem familiari: programatorii scriu codul, iar la un moment dat acest cod ajunge la testare. Testerii descoper anumite anomalii n funcionalitatea 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 ctre programator ca i rezolvat, tester-ul descoper c de fapt nu s-a rezolvat i l trimite napoi la programator i tot aa. Pentru a nu se ajunge prea des n situaia prezentat anterior, una dintre msurile luate a fost cea ca programatorul s scrie teste nainte de a implementa o anumit funcionalitate. Aceast tehnic se numete TFD (Test First Development). Primul pas al TFD este de a se scrie un test care va eua. Urmtoarea micare 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 ntradevr testul adugat va eua. Urmeaz s facem o mic modificare n cod n aa fel nct o nou rulare a testelor s se termine cu succes. n cazul n care n-am reuit acest lucru vom modifica din nou codul i vom rula testele din nou pn cnd acestea se vor termina cu succes. n momentul n care rularea testelor s-a ncheiat cu succes putem s-o lum de la nceput cu adugarea unui nou test. TDD = TFD + Refactoring Dac, aplicnd TFD, nainte de a trece la scrierea unui nou test curm, optimizm codul nseamn c aplicm Test Driven Development, numit i RED GREEN REFACTOR workflow. Regulile TDD: 1. Este permis s scrii cod de producie doar dac scopul acestui cod este s fac un test ce eueaz s ruleze cu succes. 2. Nu este permis s scrii dect un test care eueaz. Trebuie s ncepi prin a scrie un test pentru funcionalitatea pe care vrei s-o implementezi. Conform celei de-a doua reguli nu poi s scrii prea multe teste. Imediat ce rularea unit testului se termin cu eec trebuie s te opreti din a scrie teste i s ncepi s scrii cod de producie n aa fel nct rularea testelor s se termine cu succes. Atenie ns la a treia regul care ne zice c imediatce am scris destul cod de producie pentru a face ca rularea testelor s se termine cu succes, suntem obligai s ne oprim din a scrie mai mult cod i s relum scrierea de teste. Dac stm i analizm puin cele trei reguli TDD vom realiza c nu putem scrie prea mult cod fr s compilm, rulm ceva. Acesta este de fapt scopul nostru. Orice am face: scriem teste, scriem cod de producie sau refactorizm trebuie s inem sistemul n execuie. 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. Cnd aud de aceasta tehnic, muli dintre programatori gndesc: Asta e o aberaie! O s m ncetineasc i mai mult, e o pierdere de timp i de efort. Nu o s m lase s m gndesc, nu o s pot face designul cum trebuie, pur i simplu o s strice bunul mers al lucrurilor. Perfect, s ne gndim ce s-ar ntmpla dac am intra ntr-un birou n care toi programatorii ar folosi TDD. Alegei aleator o persoan din respectivul birou n orice moment i ntrebai-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 cnd l-ai ales, rspunsul e acelai: Acum un minut tot codul lor rula!. Dac tot codul tu funcioneaz la fiecare minut, cam ct de des crezi c vei folosi debugger-ul? Rspunsul este: nu prea des. Este mult mai simplu s apei de cteva ori CTRL+Z s ajungi napoi la starea n care codul tu funciona, iar dup asta s ncerci s rescrii ceea ce ai scris greit n ultimele minute. Ct timp vei economisi dac nu faci prea mult debugging? Ct timp petreci acum fcnd debugging? Ct timp petreci acum rezolvnd bug-urile pe care le-ai descoperit fcnd debugging? Ce ai spune dac ai putea s scazi semnificativ acest timp? Adevratele beneficii ale acestei tehnici sunt ns i mai mari: dac foloseti TDD atunci produci cteva teste pe or. Zeci de teste pe zi. Sute de teste pe lun. Vei ajunge s scrii mii de teste ntr-un an. Poi s pstrezi aceste teste i s le rulezi oricnd vei dori. Cnd ar trebui s le rulm? Tot timpul. De fiecare dat cnd am modificat ceva n cod, indiferent de proporiile acelei modificri. De ce nu curm codul chiar dac tim c nu e prea curat? Pentru c ne este fric s nu-l stricm. Dar dac avem toate aceste teste putem fi siguri n cea mai mare msur c nu vom strica codul, iar n cazul n care acest lucru s-ar ntmpla l-am observa imediat. Dac avem teste vom fi linitii n momentul n care facem
30

modificri n cod. Dac vedem pe undeva cod murdar ( messy code ) putem s-l curm fr rezerve. Datorit testelor codul devine maleabil. Continum 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 gsi un test care conine rspunsul la ntrebarea ta. Testele sunt ca nite mici documente de design, mici exemple de cod care descriu cum funcioneaz sistemul i cum s-l foloseti. Ai integrat un third party library n proiectul vostru? Primii cu acest library i un manual plin de documentaie la finalul cruia avei o list cu cteva exemple. Care dintre cele dou le-ai citit? Exemplele, bineneles. Acestea sunt unit testele. Cea mai folositoare parte a documentaiei. Exemple ale modului n care s foloseti codul. Acestea sunt documente de design detaliate, clare, ce nu se pot desincroniza n raport cu codul de producie. Dac ai ncercat s adugai un unit test la un sistem deja funcional probabil c ai observat c nu este un lucru trivial. Este posibil ca pentru a face acest lucru s fi fost nevoii s schimbai anumite pri ale designului sistemului, sau s trebuiasc s pclii testele. Acest lucru se datoreaz faptului c sistemul pentru care ncercai s scriei testele nu a fost proiectat s fie testabil. De exemplu, s presupunem c vrei s testai 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 mpiedicm acest lucru. Asta nseamn c sistemul a fost proiectat n aa manier nct acesta nu este testabil. Cnd urmm cele trei reguli ale TDD tot codul nostru devine testabil prin definiie. Un alt cuvnt pentru testabil este decuplat. Pentru a testa izolat un modul acesta trebuie decuplat. TDD te foreaz s decuplezi module, iar aplicnd cele trei reguli TDD vei observa c vei folosi decuplarea mult mai des dect erai obinuit s-o faci pn acum. Acest lucru te va face s creezi un design mai bun, mai puin cuplat (less coupled). cu prima funcionalitate, 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 interfeele 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 eueaz. Deploy-ul i testarea unui proiect chiar de la nceput foreaz echipa s neleag cum sistemul lor se integreaz n lume. Scoate la iveal toat lipsa de cunotine tehnice i riscuri organizaionale care trebuie adresate ct mai este timp. nceperea cu un build, deploy, i test automatizat a unui sistem nonexistent sun ciudat, dar este esenial.Exist tot felul de cazuri de proiecte care au fost anulate dup cteva luni de dezvoltare deoarece nu puteau face un deploy stabil al sistemului lor. Feedback-ul este o unealt fundamental, i vrem s tim ct mai repede dac ne ndreptm n direcia potrivit. Dup ce avem primul test fcut, urmtoarele 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 funcionalitate implementat n aceelai timp. Modificri ntr-una din cele dou perturb orice progres fcut cu cealalt. Urmrirea eecurilor este dificil atunci cnd arhitectura, testele i tot codul de producie sunt n continu dezvoltare. Unul dintre simptomele unui mediu de dezvoltare instabil este c nu exist un prim loc evident de cutare cnd ceva eueaz. Acest paradox al primei funcionaliti poate fi mprit n dou probleme mai mici. Prima const n a afla cum se poate face build, deploy i testa acest walking skeleton. Apoi, se folosete aceast infrastructur nou creat pentru a scrie teste de acceptan pentru prima funcionalitateimportant. Dup toate acestea, se poate ncepe dezvoltarea test-driven a ntregului sistem. Un walking skeleton este o implementare a celei mai mici buci de funcionalitate 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 funcionaliti. Funcionalitatea aplicaiei schelet este att de simpl nct este evident i neinteresant, lsndu-ne liberi s ne concentrm pe infrastructur. De exemplu: pentru o aplicaie web cu o baz de date, scheletul ar trebui s consiste dintr-o pagin web uniform cu cmpuri din baza de date. n timpul construirii scheletului trebuie s ne concentrm doar pe structur i nu pe curarea testului. Scheletul i infrastructura sa sunt fcute pentru a ne ajuta s ncepem dezvoltarea test-driven. Este doar primul pas spre o soluie complet end-toend de testare de acceptan. Cnd scriem testul pentru prima funcionalitate, 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 aplicaiei. Nu putem automatiza un build, un deploy i un ciclu de test fr 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 cteva minute. Pentru designul structurii iniiale avem nevoie de o viziune high-level a cerinelor clientului, att funcionale ct i non-funcionale pentru a ne ghida deciziile. Figura de mai jos arat cum procesul de TDD se integreaz n acest context:
nceperea ciclului Test-Driven
Procesul TDD presupune c putem mri sistemul doar prin inserarea de teste pentru funcionaliti noi ntr-o infrastructur deja existent. Dar ce se ntmpl
Nu exist tot timpul luxul de a crea un nou sistem de la zero. Majoritatea proiectelor pe care lucrm 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 adaptm la cel existent, indiferent ct 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 dei 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 cnd 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 aduga teste end-to-end care acoper acele
31
QA
Test Driven Development (TDD)
regiuni de cod ce trebuie schimbate. Cu aceast protecie, se poate ncepe adresarea de probleme interne de calitate cu mai mult ncredere, refactorizarea codului i introducerea de unit teste pe msur ce se adaug funcionaliti. observat ntre timp i alte cazuri de succes. Vrem ca fiecare test s fie ct de clar posibil o reprezentare a comportamentului sistemului sau a obiectului. Cnd testul e lizibil, atunci construim infrastructura din spatele testului. tim c am implementat destul cod de test atunci cnd testul pic n modul n care ne ateptam, cu un mesaj de eroare clar, care descrie ce trebuie fcut. Doar atunci putem ncepe s scriem codul care va face testul sa treac. ntotdeauna trebuie s vedem testul cum eueaz nainte s scriem codul care-l va face s treac, i s verificm mesajul de diagnostificare. Dac testul eueaz ntr-un mod n care nu ne-am ateptat, atunci tim c ceva n-am neles bine sau codul este incomplet, i l putem repara. Cnd primim eecul la care ne ateptm, verificm dac diagnostificarea este de ajutor. Dac descrierea nu este clar, cineva va trebui s se chinuie atunci cnd codul se va strica n viitor. Ajustm codul de test i rulm testele din nou pn cnd mesajul de eroare ne ghideaz la problema cu codul nostru. Doar scrierea de multe teste, chiar i atunci cnd rezult n acoperirea mare a codului, nu garanteaz un codebase cu care se lucreaz uor. Muli developeri care adopt TDD i gsesc primele lor teste greu de neles cnd le revizuiesc mai trziu. Aceast greeal comun const n faptul c ei se gndesc s testeze doar metodele obiectului. De exemplu: un test ce se numete testBidAccepted() ne spune ceea ce face integrare, stm n alert pentru acele pri de cod care sunt greu de testat. Cnd gsim o astfel de funcionalitate, nu trebuie s ne ntrebm doar cum o testm, ci i de ce este aa de greu de testat. De cele mai multe ori, cel mai probabil e faptul c design-ul are nevoie de mbuntiri. Aceai 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 ct e nc la nceput.
Meninerea ciclului test-driven
Odat nceput procesul de TDD, trebuie meninut s ruleze fr probleme. Munca pentru o funcionalitate nou ncepe cu un test de acceptan care pic, ceea ce demonstreaz c sistemul nu are nc funcionalitatea pe care o vom implementa. Acest test se scrie folosind terminologia din domeniul aplicaiei, nu din tehnologiile care stau la baza ei (ex: baze de date sau servere web). Astfel, ne ajut s nelegem ce ar trebui s fac sistemul nostru i ne protejeaz suita de teste de acceptan mpotriva schimbrilor tehnice ale infrastructurii sistemului. Scrierea acestor teste naintea scrierii codului ne ajut s clarificm ceea ce vrem
Concluzii
Test-driven development nu nlocuiete testarea tradiional, ci n schimb definete o modalitate dovedit de a asigura testare eficient. Un efect secundar al TDD-ului este c testele rezultate sunt exemple funcionale de invocare a codului, oferind astfel o specificaie a codului scris. Din experiena noastr, TDD funcioneaz incredibil de bine n practic i este ceva ce toi dezvoltatorii de software ar trebui s adopte.
Referine:
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
s obinem. Testele care pic ne in concentrai n implementarea setului limitat de funcionaliti pe care le descriu, crescnd ansele noastre de a le livra. Unit testele sunt importante n realizarea design-ului claselor i n a ne da ncrederea c funcioneaz, dar ele nu ne spun nimic dac funcioneaz mpreun cu restul sistemului. De unde ncepem cnd trebuie s scriem o nou clas sau funcionalitate? E tentant s ncepi cu cazurile degenerate sau de eec pentru c sunt de obicei mai uoare. Cazurile degenerate nu aduc mult valoare sistemului, i cel mai important nu ne dau feedback despre validitatea ideilor noastre. Incidental, focusarea pe cazurile de eec la nceputul unei funcionaliti este rea pentru moral: dac ne ocupm doar de error handling, ne simim 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 soluiei, i putem prioritiza ntre a ne ocupa de posibilele eecuri ce le-am
Ladislau Bogdan
testul, dar nu pentru ce e folosit. Cel mai bine e atunci cnd ne focusm pe funcionalitile furnizate de ctre 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 exersm toate cile prin codul ei. Este de foarte mare ajutor s alegem numele testelor pentru a descrie cum se comport obiectul n scenariul testat. Cnd scriem unit teste i teste de
ladislau.bogdan@msg-systems.com Senior Software Developer @ .msg systems Romania
Tudor Tric
tudor.trisca@msg-systems.com Software Developer @ .msg systems Romania
32
tendine
Big Data, Big Confusion

ntr-o er n care costurile de stocare i procesare devin tot mai mici, optica tradiional a felului n care operm 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 situaia anului 2009 n care virusul H1N1 reprezenta o ngrijorare major a Organizaiei Mondiale a Sntii, dar n particular a guvernului American. Evoluia rapid a epidemiei punea n dificultate CDC (Center for Disease Control and Prevention), o agenie guvernamental, care a raportat situaia cu o ntrziere de dou sptmni fa de realitatea din teren,pentru c populaia nu intra n contact cu personalul medical dup apariia primelor simptome. Raportarea n timp real ar fi permis o mai bun nelegere a dimensiunii epidemiei, optimizarea tacticilor de prevenire i tratare, aciuni cu potenial n salvarea de viei ntr-un dezastru care, n final, a totalizat peste 284.000 de victime. ntmpltor cu cteva sptmni nainte ca H1N1 s ajung pe prima pagin a ziarelor Google a publicat n Nature, o publicaie tiinific, o lucrare n care prezentau rezultatele unui studiu care a pornit de la ntrebarea Exist oare o corelaie ntre rspndirea unei epidemii i cutrile efectuate prin Google?. Presupunerea de la care a plecat Google este c, n momentul n care cineva resimte efectele unei boli proaspt contactate se va folosi de Internet pentru a cuta informaii despre simptome. Astfel, utiliznd datele publicate ntre 2003 i 2008 de ctre CDC i cele mai frecvente 50 de milioane de cutri din aceeai perioad, Google a reuit s identifice un model matematic (iternd peste 400 de milioane de nregistrri) care s demonstreze corelaia dintre evoluia unei epidemii i felul n care lumea caut pe Internet. Cu ajutorul acestei noi tehnologii, intitulate Google Flu Trends, CDC a reuit n 2009 s monitorizeze mai eficient rspndirea H1N1. Povestea Google Flu Trends este din multe puncte de vedere exemplul arhetip att pentru beneficiile, ct i pentru tehnologia i provocrile implicate n soluionarea unei probleme din spaiul Big Data. Pornind de la o ipotez ce caut o corelaie i folosind cantiti mari, nestructurate de date, alturi de tehnologii moderne de procesare, se ncearc validarea corelaiei care, n final, aduce valoare prin transformarea datelor n informaii 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 ntlni n pia cnd vine vorba de a defini problema pe care Big Data o adreseaz i modul (sau modurile) n care o face. Cnd vorbeam n 2009 despre Cloud Computing m amuzam s constat c ntrebarea Ce este Cloud Computing? adresat unei sli cu 50 de participani avea potenialul de a primi 52 de rspunsuri din care, culmea, multe corecte. Situaia este similar n prezent n cazul Big Data i asta deoarece ne aflm ntr-o perioad apropiat de ceea ce Gartner numete peak of inflated expectations (vrful inflaiei ateptrilor). 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 pornete 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 vrf, conform volumului de cutri Google, n timp ce Big Data se afl n continuare n cretere. Problema fundamental ce determin confuzia i implicit ateptrile 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). Aadar Big Data nu poate fi tratat holistic la nivel tactic, ci doar principial, la nivel strategic.
Figura 1 - Volumul comparativ al cutrilor Big Data (albastru) i Cloud Computing (rou) (sursa: Google Trends)
33
tendine
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 puine date, un principiu folosit i n realizarea Google Translate, un serviciu de traducere automat bazat pe un corpus de More: pstreaz i nu arunca peste 95 de miliarde de propoziii 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 puin de 9 ceni / lun folosind un Correlation: fapte i nu explicaii serviciu de stocare n cloud (e.g. Windows Am fost nvai i ne-am obinuit Azure), iar pentru arhivare ajung la 1 cent / c efectul este determinat de o cauz, lun (e.g. Amazon Glacier), reducnd cos- motiv pentru care n mod natural suntem turile de stocare al unui petabyte (1.048.576 tentani s aflm de ce?. n lumea Big Data GB) la aproape $10.000,- (sau $10 pentru corelaia devine mai important dect cauun terabyte), de 1.000.000 de ori mai ieftin zalitatea. n 1997 Amazon avea pe statul dect la nceputul anilor 90, cnd costul de plat un ntreg departament responmediu de stocare / GB era de aproximativ sabil s ntocmeasc liste cu recomandri $10.000. n acest context tergerea datelor de lectur pentru cei ce vizitau librria digitale acumulate din procesele infor- online. Era un proces manual, costisitor i matice are tot mai puin sens. Google, cu impact limitat n generarea de vnzri. Facebook, Twitter ridic acest principiu la Astzi, graie unui algoritm intitulat itemnivel de lege fundamental, reprezentnd to-item collaborative filtering dezvoltat biletul lor pentru noi dimensiuni de dez- de ctre Amazon, recomandrile se fac n voltare i inovare, oportunitate deschis mod complet automatizat, dinamic i cu acum i celor care pn recent erau limitai un impact masiv n vnzri (o treime din de costurile prohibitive. veniturile generate de comerul electronic provenind din recomandrile automate). Messy: cantitatea precede calitii Amazon nu vrea s tie de ce clienii care Google Flu Trends a funcionat deoa- cumpr The Lord of the Rings de J. R. rece Google a reuit s introduc n R. Tolkien sunt interesai s cumpere i procesul de iteraie a modelelor matematice Friendship and the Moral Life de Paul J. cele mai frecvente 50.000.000 de cutri. Wadell, ns ce-i intereseaz este c exist o Multe dintre aceste cutri au fost irele- corelaie 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 reuit ori mai mari dect n lipsa unui astfel de s demonstreze corelaia. 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 tendina cea mai abuzat din pia, drept urmare gradul de confuzie generat de pletora de opinii ntlnite la tot pasul (categorie din care articolul de fa nu se exclude) este extrem de ridicat, conducnd la ateptri nerealiste i dezamgiri pe msura lor. Claritatea vine ns din nelegerea potenialului, adoptarea principiilor (i.e. more, messy, correlation) i acionarea preventiv pentru adaptarea sistemelor curente la noul mod de gndire din perspectiva infrastructurii de calcul, al arhitecturii i a competenelor tehnice ale celor ce le opereaz. Miza este aceea de a identifica noi oportuniti adresabile de transformare a datelor n informaii ce pot crete eficiena unui produs sau al unei afaceri, aa cu a fcut-o Google prin Flu Trends sau Amazon prin sistemul lor automatizat de recomandri. Yonder acumuleaz experien Big Data, investind strategic n proiecte de cercetare aplicat, alturi de companii de produs care au neles viziunea pe care am conturat-o i beneficiile pe care o asemenea investiie le poate genera att pe termen scurt ct i pe termen lung, acest trend reprezentnd una din cele patru direcii tehnologice alese ca tem de inovaie n 2013.
Mihai Nad mihai.nadas@tss-yonder.com CTO @ Yonder este responsabil de activitile R&D i creterea nivelului de inovaie al produselor partenerilor Yonder.
Figura 2 - Big Data Hype Cycle (sursa: Gartner, 2012)
34
programare
Sisteme cu perfoman/fiabilitate ridicat bazate pe data grids n Java

provocare important cnd construim un produs de succes este s ne asigurm c produsul utilizeaz resursele hardware disponibile ntr-un mod eficient. Acest lucru nseamn de obicei clustering (mai puin pentru probleme foarte simple) pentru c seturile noastre de date au depit calculatoarele individuale ca mrime i necesiti de procesare. Cu toate acestea clustering-ul aduce o serie de noi probleme: mprirea procesrii ntre noduri, orchestrarea procesului i - foarte important - garania c nu vom pierde datele / progresul dac un subset de noduri devine indisponibill - o posibilitate care crete dramatic n momentul n care adugm 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 simplitii sale - are robusteea i performana cerut de la sisteme reale graie librriei pe care se bazeaz. Dei nu este o cerin ca un sistem sfie considerat data-grid, de obicei aceste librrii pun la dispoziie o interfa configurabil care s persiste datele n sisteme externe - baze de date / fiiere simple / etc. - ca s fie pstrate n timpul repornirii complete a sistemului (data-grid-urile stocheaz datele exclusiv n memoria volatil). De asemenea, ele implementeaz de obicei suport pentru operaii tranzacionale pe structurile de date. Biblioteca, prezentat n acest articol - Infinispan - folosete o tehnic numit hash-uri consistente1 pentru a oferi urmtoarea configuraie posibil n timpul rulrii: folosind N noduri, vrem s pstrm fiecare bucat de date pe exact K dintre ele (KN - de obicei 2 sau 3). Dac sunt adugate sau eliminate din cluster noduri, datele sunt redistribuite n aa fel nct proprietatea s fie meninut. Aceast redistribuie se ntmpl n mod transparent din punct de vedere funcional (proprietile non-funcionale a sistemului - cum ar fi latena - se schimb n timpul procesului de redistribuie). Putei vedea o ilustrare a conceptului n graficul alturat: De exemplu, s presupunem c avem N noduri, fiecare cu 12 GB de memorie. Dac am pstra o copie identic a setului de date pe fiecare nod, dimensiunea maxim a datelor ar fi de 12 GB (dar am avea N copii, nsemnnd ca sistemul tolereaz euarea a N-1 noduri). Dac decidem c K exemplare a datelor (unul primar i K-1 copii) sunt suficiente pentru a satisface cerinele 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 obinem o dimensiune maxim de40 GB (n comparaie cu 12GB pentru cazul cu replicare complet).
Bazele data grid-urilor
Data grid-urile furnizeaz trei servicii principale: Una sau mai multe structuri de date de tip cheie-valoare (asemntor interfeei Map<K,V> din Java). Datele din aceste structuri sunt replicate pentru o fiabilitate ridicat. n acelai 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 replicrii geografice de exemplu) care mresc performana (datele folosite mpreun pot fi plasate pe acelai nod) i asigur garanii n cazul n care un subset de noduri devin indisponibile (fail-over ntre data-center-uri de exemplu). Un serviciu de execuie 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 maina unde se afl datele care urmeaz s le proceseze pentru evitarea transportul datelor prin reea n mod repetat. Posibilitatea de a fi notificat despre evenimentele din structurile cheie-valoare (adugarea / eliminarea / actualizarea datelor)
O scurt istorie a Infinispan-ului
Infinispan2 este un proiect din cadrul meta-proiectului JBoss susinut de RedHat. Este un data-grid extrem de configurabil cu un set extins de faciliti. Este succesorul produsului JBoss Cache cu multe caracteristici interesante: scalabilitate nalt, suport pentru a rula ca server dedicat sau ncorporat (embedded) n proces,
Aici avem fiecare bucat de date (D1, D2 i D3) replicat n trei noduri, ceea ce nseamn c oricare dou noduri pot eua 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 comparaie cu oglindirea (mirroring) simpl:
1 http://en.wikipedia.org/wiki/Consistent_hashing
s u p o r t p e n t r u o p e r a i i tranzacionale, replicare configurabil ntre noduri i ntre centre de date, posibilitatea de accesarea datelor prin interfee standard, cum ar fi REST, protocolul memcached, WebSockets sau printr-un protocol binar numit Hotrod
2 http://www.jboss.org/infinispan/
35
programare
Sisteme cu perfoman/fiabilitate ridicat bazate pe data grids n Java
Folosirea Infinispan-ului este simpl - doar adugm dependena de Maven n POM i putem ncepe s o utilizm. Se bazeaz pe JGroups, o soluie de messaging fiabil pur Java, ceea ce nseamn c nu exist un cod nativ care trebuie compilat / instalat. Infinispan este disponibil sub licena 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. Clientul folosete datele capturate de la bursa Bitcoin MtGox pentru a crea comenzi (intenii de tranzacionare - cumprare / vindere - la un anumit pre dat sau mai bun - aa-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 corespunztor, acesta este plasat n cartea de comenzi (orderbook - lista ordonat a tuturor comenzilor), algoritmul de potrivire este rulat i toate tranzaciile rezultate sunt stocate. Toate acestea se ntmpl ntr-un mod tranzacional, ceea ce nseamn c nu se stocheaz rezultate pariale / inconsistente. Clientul comunic cu un singur nod la un moment dat i comut la nodul urmtor (fail-over) dac se observ o eroare. Nu este implementat n acest proiect, dar putem aduga cu uurin o conexiune care primete date n timp real despre tranzacii folosind de exemplu protocolul WebSockets. Crile de comenzi (orderbook) sunt serializate i deserializate ntr-un mod eficient pentru a fi sincronizate ntre nodurile primare i secundare utiliznd faciliatatea de replicare delta din Infinispan prin care numai modificrile (delta) sunt trimise print reea . Acest lucru ne permite s pstrm obiecte mari pentru o anumit cheie fr a sacrifica eficiena n timpul replicrii. Practic putem separa problema modelrii datelor (ce subset de date trebuie pstrate mpreun) de problema plasrii datelor. Testul final repornete n mod aleator nodurile la fiecare cteva minute, fr ca acesta lucru s schimbe corectitudinea rezultatului.
Concluzii
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 puin de o tranzacie pe secund). Fiind construit cu Infinispan, fiecare operaiune este replicat ntr-un nod secundar, ceea ce nseamn c pierderea unui nod arbitrar poate fi tolerat fr pierdere date. De fapt, n codul surs exist un test care simuleaz chiar acest scenariu - pornete i oprete noduri n mod aleator n timp ce ruleaz motorul de potrivire. Surs pentru ntregul sistem este disponibil pe GitHub4sub licena liber Apache 2. Structura sistemului poate fi vzut n schema de mai jos:
Data-grid-urile sunt o soluie excelent pentru sisteme care necesit performan i fiabilitate ridicat. Proiectul prezentat n acest articol proceseaz cu un ordin de mrime mai multe date dect necesar n sistemele reale i poate fi integrat cu schimbri de cod minime. Face acest lucru ntr-un mod eficient, tolernd repornirea oricrui nod n timpul rulrii.
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
36
NEO4j Graph Database

modelarea datelor interconectate
eo4j este o baza de date open-source fondat pe teoria grafurilor, fiind o soluie optimizat pentru a modela i interoga volume mari de date strns relaionate, reprezentabile prin structuri de tip graf. Dinamismul,creterea volumului datelor, precum i evolutia continu a procesrii informaiilora impus ieirea din spaiul bazelor de date relaionale tradiionale i orientarea spre soluii NOSQL. Neo4j face parte din fenomenul NOSQL ncadrndu-se ncategoria bazelor de date de tip graf. O caracteristic unic a acestora este gradul ridicat de adaptibilitate la modelele reale de date. , 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 putnd 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 cruia 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 interogri. noduri i relaii. Att nodurile ct i relaiile Limbajul Cypher este un limbaj de pot fi avea proprieti.Relaiile au un rol interogare declarativ fiind foarte intuitiv foarte important n cadrul bazei de date i human readable, putnd fi neles cu de tip graf pentru c traversarea grafului i uurin 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 relaie implic ntotdeauna dou (echivalentul offset) noduri, are o direciei un tip identificat Limbajul este alctuind din urmtoaunic printr-un nume. rele clauze : START punctul de intrare n graf. Orice interogare n graf are cel puin un nod de start, MATCH ablonul pentru cutarea n exemplul de mai sus relaia nodurilor i care este legat de nodul de KNOWS conecteaz nodurile Autor 1 start, cu Autor 2 preciznd de asemenea pro WHERE condiiile de filtrare a prietatea adiional since. nodurilor / relaiilor, Relativ la un nod relaiile se pot clasi RETURN rezultatul interogrii, fica n dou tipuri : CREATE creeaz noduri sau relaii , incoming, DELETE terge noduri sau relaii, SET seteaz proprieti noduri sau relaii, FOREACH update pe liste de outgoing. noduri, Att proprietile unui nod ct i WITH mparte interogarea n mai cele aleunei relaii pot fi indexate pentru multe pri distincte. mbuntirea performanei de traversare a grafului ( similar cu indexarea coloanelor Pentru exemplificare v propun urmn bazele de date tradiionale ). torul graf care reprezint autorii care Fornd o comparaie cu bazele de date public n TSM relaionai dup cum tradiionale, v putei imagina un nod ca urmeaz : o nregistrare dintr-un tabel, iar o relaie ca o nregistrare dintr-un tabel de legtur sau o pereche de coloane din acelai tabel n cazul unei reprezentri tip denormalizat.
NOSQL Stores
Att n cazul bazelor de date relaionale ct i n cazul unor soluiiNOSQL (nongraph) procesulde modelare / design trece prin dou faze : Definirea conceptelor , a entitilori a interaciunii dintre ele model logic/ real Materializarea modelului logic ntrun model fizic/abstract ( Ex. n cazul bazelor de date relaionale schem) De cele mai multe ori modelul logic este foarte diferit de modelul fizic. n cadrul unei organizaii software n prima faz poate participa orice echip nu neaprat tehnic(management / sales ) pentru o mai bun definire a cerinelor sau conceptelor.n cea de a doua faz ns are loc abstractizarea modelului logic n funcie de opiunea de stocare. Astfel gradul de nelegere al modelului logic scade odat cu creterea complexitii datelor. Marele avantaj al bazelor de date de tip graf i implicit utilizarea Neo4j este c modelul logic este acelai cu modelul fizic. Avnd acest mod de reprezentare uniform sau astfel spus o reprezentare human readable ce ofer un mare grad de flexibilitate
37
programare
NEO4j Graph Database - modelarea datelor interconectate
[:Interested_in]->(subject4);
Cum observai i mai sus crearea nodurilor i a relaiilor este foarte intuitiv i flexibil. Exemple de interogri 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 cerina de a aduga o nou relaie ( ex. RATING ntre un autor i un articol), trebuie doar adugat relaia i funcionalitatea de a conecta autori cu articole se poate realiza. n cadrul unei baze de date relaionale, operaile de modificare de schema sunt de obicei costisitoare i nu neaprat simple. Astfel c se poate spune ca modelul evolueaz n mod natural odat cu datele reale i cerinele impuse de business. Graful de mai sus se poate crea cu urmtoarea instruciune Neo4j expune un API Java foarte variat care permite crearea i Cypher : manipularea grafurilor. O alta opiune 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 aceeai abstactizare (autor1)-[:Wrote]->(articol1), a interaciunii cu bazele de date princonceptul Templates ( ex. (autor1)-[:Wrote]->(articol2), JDBCTemplate) . revista = { name : TSM, domain : IT , Ca analogie, la fel cum interaciunea cu SQL se realizeaz prin poweredBy:Gemini Solutions}, hibernate, interaciunea 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 },
SpringData i Neo4j
Iulian Moneagu
iulian.mosneagu@geminisols.ro Senior Software Engineer @ Gemini Solutions
subject3 = { subject : Agile },subject4 = { subject : Android}, (autor1)-[:Interested_in]->(subject1), (autor1)[:Interested_in]->(subject3), (autor2)-[:Interested_in]->(subject2),(autor3)-
38
programare
Hadoop (II)
Oriunde este nevoie de Hadoop, se impune prezena unui nod numit: NameNode. Acest nod reprezint nodul de tip master, stocnd locaia tuturor fiierelor din sistem. El este singurul nod care poate s identifice locaia unui fiier pe baza numelui. n jurul acestui nodexist DataNode-uri, care stocheaz coninutul fiierelor.
n ultimul numr am descoperit lumea pe care Hadoop o formeaz i care este secretul prin care putem s stocm zeci i chiar sute de TB fr nici un fel de probleme. Aceasta se bazeaz pe un sistem de tip master-slave extrem de simplu, dar care funcioneaz foarte bine. Map se refer la procesul prin care datele pe care dorim s le procesm sunt convertite la un nou set de date. Datele pe care le obinem dup acest pas sunt doar nite date intermediare care n starea n care sunt nu pot fi folosite. Operaia de tip Map nu se execut doar pe un singur nod n cadrul sistemului. Aceast aciune va fi executat pe mai multe noduri de tip DataNode. Fiecare DataNode va genera un rezultat intermediar. Din punct de vedere a cantitii de date care se genereaz dup procesul de Map, aceasta este mult mai mic n comparaie cu datele originale. Ne putem imagina c dup acest pas, Hadoop ne genereaz un sumar a datelor noastre n funcie de parametri de care noi suntem interesai. Este important s tim c datele intermediare pe care le obinem nu trebuie s aib acelai format ca i datele de input. n momentul de fa, cheile ajung s fie partiionate pe baza unei funcii n general o funcie de hash. Odat ce procesul s-a finalizat cu succes, Hadoop poate s execute diferite operaii peste ele, precum sortarea, separarea sau shuffle aceast funcionalitate este destul de nou, circa un an. Aceti pai pregtesc datele intermediare pentru urmtorul pas. Atenie, acest pas se execut i n cadrul operaiei de Reduce. Din punct de vedere al paralelismului, pe fiecare nod unde se execut operaia de tip Map, putem s avem de la 10 pn la 100-150 de operaii. Totul depinde de ct de performante sunt nodurile cu care lucrm.
Procesarea datelor
Faima Hadoop-ului vine de la procesarea datelor i extragerea informaiilor de care avem nevoie. n urmtoarele rnduri vom descrie mecanismul acestei performane. Un prim element este MapReduce. Aceast paradigm nu a fost inventat de ctre Hadoop, dar a ajuns s fac acest lucru cel mai bine. La prima ntlnire cu MapReduce avem senzaia c este complicat, dar odat neleas, aceast paradigm ne ajut foarte mult. Totodat, nu ncercai s folosii Hadoop dac nu ai neles MapReduce n totalitate. Fr s nelegem MapReduce nu putem ti ce anume vrem s cerem de la Hadoop i la ce rezultate s ne ateptm.
MapReduce i Tupluri
n comparaie cu un sistem care stocheaz datele n tabele, s nu v ateptai 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 obinem de la un task are aceeiai form de tip (cheie, valoare). Dei pare destul de banal, vom vedea c nu este nevoie de mai mult dect att pentru a putea obine datele dorite.
Odat ce avem datele intermediare, putem s le procesm pentru a obine datele finale, de care suntem interesai. Pn n acest moment puteam executa operaiile de tip Map pe fiecare din nodurile din cluster care conineau datele noastre. Operaia Reduce se va executa doar pe un numr limitat de noduri. Datele sunt partiionate pentru fiecare Reducer n parte. Dac operaia de Map era format dintr-un singur pas, operaia de Reduce este format din 3 pai separai 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 urmtorul pas. Acest lucru se face folosind o conexiune HTTP. Din cauz c suntem ntr-o reea privat, nu trebuie s ne facem probleme din punct de vedere al securitii. Toate tuplurile care sunt trimise, sunt apoi sortate pe baza cheii. Acest lucru este necesar deoarece putem avea aceleai chei de la diferite noduri. n general, procesul de sortare se execut simultan cu procesul
Map
Procesul de MapReduce este format din dou pri total separate Map i Reduce. Reduce
39
programare
Hadoop (II)
de shuffle. Odat ce operaia de shuffle s-a finalizat, Hadoop va mai executa nc o sortare. n acest moment putem s controlm modul n care datele s fie grupate i chiar s facem o sortare intermediar dup diferii parametri. Operaia de sortare este o operaie care se execut att pe disk ct i n memorie. Ultima operaie care a mai rmas de executat este reduce. n momentul n care aceast operaie 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 aciune. n cazul n care una din operaii nu se termin cu succes, JobTracker va reprograma aceast operaie. JobTracker-ul discut n permanen cu NameNode-ul i are grij ca operaia care trebuie s se execute s fie pe acelai DataNode sau cel puin n acelai rack n care datele pot fi gsite. TaskTracker-ul este un nod care accept operaii 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 numr limitat de joburi pe care le poate executa (slot). Din aceast cauz JobTracker-ul va cuta ntotdeauna TaskTracker-ul care are ct mai multe slot-uri libere. Un lucru destul de interesant care a fost fcut 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. Pn n acest moment am prezentat din punct de vedere teoretic cum MapReduce funcioneaz. V propun ca n urmtoarea parte a articolului s analizm peste un exemplu practic. n acest mod ne va fi mult mai simplu i uor s nelegem ce se ntmpl cu adevrat. Vom porni de la urmtoarea problem. Avem sute de fiiere ce conin date despre numrul de accidente din fiecare jude din Romnia care s-au ntmplat n fiecare lun. Am ajuns la un numr foarte mare deoarece exist nenumrate firme de asigurare, iar fiecare firm de asigurare are una sau mai multe centre regionale. Din aceast cauz fiecare fiier poate s conin mai multe date despre acelai ora. Un fiier ar putea avea urmtoarea form: Cluj, Ianuarie 2013, 20
management
Sibiu, Ianuarie 2013, 10 Braov, Ianuarie 2013, 3 Bucureti, Ianuarie 2013, 100 Cluj, Mai 2013, 50 Braov, Iulie 2013, 18 Se cere s calculm numrul 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 operaie pe care MapReduce o face este cea de Map. n acest moment din fiecare fiier vom putea obine o colecie de tip (cheie, valoare). Pentru noi cheia va reprezinta oraul, iar valoarea va indica numrul de accidente. Din fiecare fiier dorim s extragem numrul maxim de accidente per ora. Pentru exemplul dat mai sus rezultatul pe care l-am putea obine ar avea urmtoarea form (Cluj, 50) (Sibiu, 10) (Braov, 18) (Bucureti, 100) Din alte fiiere vom obine i alte date. Dac punem toate aceste date mpreun (operaia de shuffle) am avea urmtorul rezultat intermediar (Cluj, 13), (Braov, 20), (Cluj, 40), (Sibiu, 2), (Cluj, 50), (Sibiu, 10), (Braov, 18), (Bucureti, 100), (Sibiu, 8) Peste acest rezultat intermediar putem s aplicm operaia de Reduce, care ar genera rezultatul final numrul maxim de accidente din fiecare ora. La final obinem urmtorul rezultat (Cluj, 50) (Braov, 20) (Sibiu, 10) (Bucureti, 100)
colecie de valori. Din aceast colecie de valori operaia de reduce va selecta valoarea final. Dei pasul de reduce este extrem de important, pot s existe cazuri cnd nu dorim s facem acest lucru. n astfel de cazuri, putem s specificm c rezultatul obinut dup Map s fie scris direct pe disk i s fie considerat rezultat final.
Exemplu
JobTracker, TaskTracker
Operaia de tip MapReduce implic dou tipuri de servicii care poart numele de JobTracker i TaskTracker. Acestea dou sunt ntr-o relaie de tip master-slave, extrem de asemntoare cu cea pe care am vzut-o la nivelul modului n care datele sunt stocate NameNode i DataNode. Scopul principal pe care JobTracker
Concluzie
D up c u m a m put ut o b s e r v a , MapReduce este o operaie simpl, care se bazeaz pe mprirea unui task n operaii ct mai mici care s poat s fie rulate n paralel. Odat ce fiecare operaie a fost executat pe o parte din date, rezultatele intermediare obinute 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
40
programare
Programare Funcional n Haskell (II)

rticolul din numrul trecut a realizat o scurt introducere n limbaj prezentnd mai mult istoria i beneficiile lui i mult mai puin elemente de cod propriu-zis. Astzi, ne apropiem de acest deziderat discutnd 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 meniona c, spre deosebire de C, Java i alte limbaje similare, tipurile nu sunt o pacoste: descrierea lor este opional. Putei scrie foarte mult cod fr a scrie o singur definiie 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 cunoatem tipurile expresiilor i s programm folosindu-ne de aceste informaii, dup cum se va vedea n continuare. Cel mai simplu tip este cel al expresiilor booleene, True i False . Atenie! 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 convenie 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. Diferena 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 orict de mari. Pentru numerele reale, avem tipurile Float i Double, exact ca n C. Poate v ntrebai acum cum se face conversia ntre Int i Integer. S zicem c avei o funcie f ce primete un argument de tip Int i avei o expresie x de tip Integer. Nu vei putea realiza direct apelul f x deoarece cele dou tipuri nu se potrivesc i compilatorul va arunca o eroare. Din fericire, exist funcia toInteger ce va realiza conversia argumentului la un rezultat de tip Integer. Aadar, apelul va fi f (toInteger x) sau, dac vrem s eliminm ceva paranteze folosind operatorul $, vom ajunge la apelul f $ toInteger x. Este foarte probabil ca acum tiprirea static s vi se par problematic i greu de folosit. Este necesar puin experien cu limbajul pn cnd v vei obinui cu aceste mici inconveniene i vei observa de ce sunt ele necesare i cum v pot scuti de multe erori. n continuare, vom analiza tipuri mai complexe. Dup cum ai citit i n articolul trecut, exist tipul list de elemente de tip a, [a]. Observai c tipul este scris cu liter mic, avem de fapt o variabil de tip ce poate fi instaniat pentru fiecare caz particular. De exemplu, lista [1,2,3] este de tipul [Integer] (notaia pentru aceast fraz fiind [1,2,3] :: [Integer]). Revenind la
Mihai Maruseac
mihai.maruseac@gmail.com IxNovation @ IXIA membru ROSEdu, ARIA
41
programare
Programare Funcional n Haskell (II)
notaia tipului list, [a], observm imediat i restricia ca toate elementele unei liste s fie de acelai tip, a. n final, tipul standard al irurilor de caractere, String, nu este altceva dect 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). Observai imediat c fiecare element al tuplului poate avea un tip diferit. Astfel, putem avea att (ana, mere) :: (String, String) ct i (ana, 42) :: (String, Integer). Ca un caz particular, exist i tuplul cu zero elemente, (), avnd o singur valoare () :: (). n final, cum orice expresie din Haskell are un tip, rezult c putem vorbi i de un tip pentru o funcie. Acesta ne d informaii despre ce valori de intrare sunt acceptate i ce fel de valori sunt returnate. n unele cazuri, tipul funciei ne d i detalii despre ce face funcia, funcioneaz ca o documentaie. De exemplu, o funcie f :: a -> a ne zice ca primete un argument de orice tip i ntoarce un rezultat de fix acelai tip. Dac ne limitm la funciile care se termin (excludem cazurile de forma f x = f x), nu dau eroare (fr f x = undefined sau f x = error ...) i nu sunt complicate inutil (excludem i f x = head [x, f x, f (f x)]) obinem o singur expresie valid pentru f: funcia identitate. Aadar, pornind de la tipul acesteia putem deduce imediat ce semantic are, fr a ne uita n implementare. Desigur, nu putem deduce totul din tipuri, cel puin nu la nivelul celor prezentate pn acum. Cazul funciilor cu mai multe argumente este interesant de studiat. De exemplu, funcia
addBothWith2 x y = x + y + 2
programare
addBothWith2 3 are tipul I nteger -> Integer. Aadar, Integer -> Integer -> Integer i Integer -> (Integer -> Integer) sunt expresii similare. Pe de alt parte, (Integer -> Integer) -> Integer reprezint semntura unei funcii ce primete ca argument o funcie de la ntreg la ntreg i ntoarce un rezultat. Un exemplu ar putea fi urmtoarea funcie:
applyTo42 f = f 42
toi 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 funcia a ajuns ntr-un caz de eroare. Astfel, suntem salvai de la a obtine un null-pointer-exception la runtime: programatorul va trebui s trateze ambele cazuri n funciile scrise de el. Observai c tipul este generic: primete ca argument un alt tip sub forma variabilei de tip a. Unul dintre constructori folosete 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 funcia eueaz nu se poate salva i motivul eecului. Din fericire, exist i tipul Either, definit ca Despre aceste tipuri i cum le vom folosi ntr-un cod real vom mai discuta n viitor. Se poate ntmpla ca uneori numrul de cmpuri din constructor s fie foarte mare. Sau, se poate ntmpla s avem nevoie s accesm anumite cmpuri din interiorul tipului. Din fericire, exist o notaie special:
data Person = P { nume :: String, prenume :: String, varsta :: Int} data Either a b = Right a | Left b data Maybe a = Just a | Nothing
pe care dac o apelm cu ( +1 ) vom obine 43 iar dac o apelm cu (addBothWith2 3) vom obine 47. Avnd toate aceste elemente putem scrie orice program dorim. Doar c dac ne limitm doar la tipurile prezentate nu vom obine nici un beneficiu de pe urma tiprii statice din Haskell, ba chiar vom avea i ceva probleme. De exemplu, exist funcii predefinite doar pentru tuplurile cu dou elemente. Pentru toate celelalte va trebui s scriem noi de mn funcii 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 meniona 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 folosete [String] versus un cod care folosete [[Char]]. Idem, este mult mai comod s lucrai un program care are Vector2D, Point2D, Size fa de un program care folosete (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]
are tipul Integer -> Integer -> Integer (de fapt, tipul real este puin mai complex dar vom reveni asupra lui spre finalul articolului). Fiecare argument este separat de urmtorul n semntura de tip prin ->. De ce aceast semntur? Pentru a captura un aspect interesant al programrii n Haskell: putem transmite funciilor un numr mai mic de argumente dect este cerut i obinem napoi o funcie nou. n teorie se zice c funciile n Haskell sunt curry (dup numele lui Haskell Curry) i acest lucru este posibil doar pentru c funciile sunt valori de prim ordin (nu exist nici o diferen ntre a-i trimite fuciei identitate un numr sau o funcie, de exemplu). ntorcndu-ne la funcia addBothWith2 de mai sus observm c
Compilatorul lucreaz n spate cu tipul original. Doar anumite semnturi 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 listm fiecare constructor mpreun cu argumentele necesare lui. De exemplu, urmtorul cod listeaz definiia exact a tipului Bool.
data Bool = True | False
Tipul are doi constructori, numii 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 enuna acum n ntregime regula legat de Putem afla tipul oricrei 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):
Ca rezultat, nu numai c se creeaz tipul de date Person i constructorul P :: String -> String -> Int -> Person, dar avem acces i la funciile 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 profitm n totalitate de inferena de tip (pe care o putem obine n ntregime doar folosind tipuri cu constructori proprii). Din fericire, Haskell are i a treia metod de a defini tipuri noi: folosim newtype.
42
programare
De unde deducem imediat c map va aplica funcia pe o list i va ntoarce lista rezultatelor. Putem s mai aflm tipul unei expresii consultnd lambdabot pe #haskell (canal de IRCpe Freenode) sau via Hoogle1. De fapt, Hoogle ne ajut i n cutarea invers: putem cuta dup tipul aproximativ al unei funcii, s zicem String -> Int -> Char i vom ajunge prin pagina de rezultate2 la (!!) :: [a] -> Int -> a, funcia care ne ntoarce elementul de pe o anumit poziie din list. Ca exerciiu pentru astzi, vom simula un program de manipulat baze de date. Momentan vor realiza doar o cutare n una din cele trei tabele ce reprezint informaii despre oameni. ncepem prin a defini cteva sinonime de tip, pentru a nelege codul mai uor:
type type type type Name = String Age = Int Address = String PhoneNumber = Integer

de o funcie de cutat n listele respective: cutm perechea al crei prim element este Acum, s cutm 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 funcie recursiv pentru nameAge aceasta dar este un exerciiu interesant s Just 25 *Main> searchNameAddress Mihai folosim Hoogle. Dac am cuta o funcie nameAddress [(String, a)] -> String -> Maybe a nu vom Just a random address *Main> searchNameAddress Gabrigsi 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 cuta [(a, b)] -> a -> Maybe b Nothing *Main> searchNamePhone Mihai primul rezultat din list este funcia lookup namePhone 3 (ignorai momentan partea Eq a => din Just 24828542 semntur, o vom trata tot data viitoare). Vom continua data viitoare aplicaia Putem scrie acum imediat funciile de pentru a realiza i operaii de tip join pe cutat n cele trei tabele: aceste tabele. Dup cum vedei, 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 puin (n funcie de design) un aliat i Dup cum observai, n partea dreapt ne ajut s avem ct mai puine bug-uri la a egalului am folosit exact aceeai 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 ateptat i cum putem reduce codul vom vedea cum este implementat polii mai mult, fiind fideli principiului DRY morfismul i cum putem captura abloane (dont repeat yourself). comune la nivelul tipurilor. Pentru astzi, ne mai rmne doar s testm funciile scrise. Pentru nceput, privii cum compilatorul ne anun imediat ce folosim o tabel nepotrivit:
*Main> searchNameAge Ion nameAddress <interactive>:21:21: Couldnt 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
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 eficiena reprezentrii i pentru a avea inferen de tipuri. Partea deriving Show este necesar pentru a putea afia valorile de aceste tipuri (o vom prezenta n amnunt data viitoare). S construim acum cteva 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 observai, 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
43
QA
programare
Planificarea Testrii de Performan

n acest articol a dori s v prezint o scurt introducere n planificarea Testrii de Performan, precum i n planificrea colectrii i analizrii rezultatelor prin prisma experienei mele n acest domeniu. Voi porni de la prezumia c cititorul are cunotine despre terminologia folosit n Testarea de Performan. n cadrul articolului voi face referire la unele metrici folosite, cerine Non-funcionale pe care le voi folosi ca exemple. poate face ntr-un document separat sau c. Ramp-down este timpul necentr-un capitol ca parte a Test Plan-ului sar utilizatorilor s termine aciunile i proiectului. ncrcarea serverului s nceteze Definiia ISTQB pentru Testarea de De obicei se iau n considerare urmPerforman este procesul de testare prin toarele aspecte n planificarea Testrii de B. Momentul rulrii testelor de perforcare se determin performana unui produs. Performan: man n timpul dezvoltrii produsului este Cu alte cuvinte scopul nostru este de a afla important. Rularea testelor de performan ct de bun este un produs software, ct de Cerinele e bine s fie fcut cnd majoritatea funcrapid, ci useri poate s susin precum i Este cel mai important aspect alturi de ionalitilor sunt implementate i sunt timpul de rspuns 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 funcionalitatea nu este finalizat n mare Rezultatele obinute n urma testelor determinat pe baza cerinelor i a tehnolo- parte, rezultatele testelor pot fi irelevante. de performan vor ajuta factorii de decizie giei folosite. Cerinele Non-funcionale vor Orice schimbare major a codului va afecta din Business s ia o decizie informat cu conine cifrele exacte pentru timpul de rs- rezultatele testelor de performan i comprivire la lansarea unui produs. puns, numr de aciuni concurente. pararea rezultatelor rulrilor succesive Testarea de performan va oferi infora testelor de performan nu va putea fi maii despre cum se va comporta produsul Resursele umane necesare fcut. Se pot rula teste de performan pe n utilizarea zilnic, cu acces concurent din Skill-urile necesare pentru designul, funcionaliti separate sau servicii atunci partea utilizatorilor. Rezultatele vor folosi scrierea i executarea testelor de perfor- cnd acea funcionalitate se poate testa n estimarea resurselor hardware nece- man trebuie analizate cu grij. Consider independent. Astfel, rezultatele ofer un sare pentru a susine un anumit numr de Testarea de Performan ca un efort de feedback continuu i relevant asupra perutilizatori. echipa n care trebuie sa fie implicai formanei sistemului. E bine s se planifice Exist cteva categorii de Teste de arhitecii i programatorii. Expertiza arhi- testarea de performan n mod continuu, Performan, fiecare avnd particulariti tecilor n arhitectura produsului este de mai ales n contextul Agile, cnd se livreaz n ceea ce privete scopul, planificarea i folos n design-ultestelor care vor desco- funcionalitate complet n fiecare Sprint execuia: peri vulnerabilitile sistemului, pe cnd sau un numr relative mic de Sprint-uri. Load al crui scop este de a vedea expertiza developerilor este folositoare n n timpul unui release, testele de percomportamentul sistemului cnd un scrierea script-urilor. De asemenea trebuie forman se ruleaz de un numr limitat anumit numr de utilizatori l folosete s participe n analiza rezultatelor pentru de ori datorit timpului necesar rulrii lor simultan o mai bun nelegere a comportamentului i resurselor hardware necesare. Rularea Stress al crui scop este de a deter- sistemului i a aciunilor coercitive ?. testelor, analiza rezultatelor i fixurile sunt mina limitele i robusteea sistemului realizate ntr-un ciclu iterativ. Soak al crui scop este de a deter- Design-ultestelor i execuia lor O alt abordare n obinerea informamina comportamentul sistemului pe o A. Testele de performan sunt conce- iilor despre performana unui sistem este perioad mai mare timp n care un anu- pute s acopere cerinele non-funcionale cu de a aduga listener-i n Unit test i n tesmit numr de utilizatori l folosete scenarii reflectnd situaii reale. Scenariile tele de API. Astfel se vor obine informaii folosite de mine au ca pri componente despre ct de performante sunt anumite Cum planificm Testarea de importante urmtoarele: metode/fluxuri. Performan? a. Ramp-up este timpul necesar ca Ca orice fel de testare, Testarea de toi utilizatorii s fie gata pentru a exeC. Colectarea rezultatelor i raportarea Performan trebuie planificat cu grij. cuta aciunile testului (de exemplu s fie Setul de rezultate colectate n cursul Cerinele, resursele necesare, crearea scelogati i s nceap s ruleze aciunile) testelor de performan trebuie definit cu nariilor i rularea lor, colectarea i analiza b. Distribuia ncrcrii i a aciunilor grij i s fie minimalist pentru rezultatelor, raportarea rezultatelor, tooln timp scenariile apropiate de realitate a colecta rezultatele relevante. Toolurile necesare sunt cteva dintre artefactele vor fi create avnd n vedere tipurile de urile pentru teste de performan ofer o de luat n considerare. utilizatori ai aplicaiei i aciunile pe care larga varietate de rezultate ce pot fi colecPlanificarea Testrii de Performan se le pot face fiecare dintre ei tate n special n ceea ce privete timpul
Ce este testarea de performan i de ce avem nevoie de ea?
44

de rspuns. Resursele hardware pot fi monitorizate prin intermediul acestor tool-uri sau instalnd tool-uri de monitorizare direct pe sistemul aflat n test a nu colecta prea multe rezultate. Colectarea prea multor rezultate va avea impact att asupra mainii pe care ruleaz tool-ul de testare, consumnd din resursele necesare susinerii load-ului ct i a resurselor de pe sistemul aflat n test afectnd numrul de aciuni executate Voi prezenta o lista cu rezultatele pe care obinuiesc s le colectez: Timpul de rspuns. Analiznd timpii de rspuns 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 rspuns minim i maxim Timpul de rspuns mediu. Pe lng timpul de rspuns mediu este relevant s se vad cte aciuni au fost realizate n mai puin timp sau mai mult dect timpul mediu de rspuns. Este important ci timpi de rspuns au fost foarte lungi. Procentele (90, 95, 99) sunt folosite pentru a afla numrul de aciuni ale cror timp de rspuns au fost 90%, 95%, 99% cele mai ncete pe o scara de la cel mai mic la cel mai mare timp de rspuns Throughput: cte aciuni concurente poate s susin sistemul. Acest rezultat este important i ajut n determinarea resurselor hardware ale sistemul de producie Erori: rata de eroare va arta cte aciuni i din ce cauza nu s-au ncheiat cu succes. Analiza erorilor va releva dac sistemul nu poate susine o anumit ncrcare i d time-out. Consumul resurselor hardware (CPU, memorie, disk, retea). Load-ul trebuie fcut pn la un consum de 85% din resursele hardware ale sistemului testat astfel nct 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 productorii de tool-uri de performan trebuie fcut avnd n vedere contextul proiectului i a cunotinelor existente n echipa. Pentru anumite tool-uri va fi nevoie de cunotine de programare pentru a rula scenarii complexe (cum ar fi JMeter), pe cnd alte tool-uri (cum ar fi LoadRunner) ofer aceasta funcionalitate.
Voi prezenta cteva concluzii din expeD. Raportarea: Rapoartele testelor de riena mea utile unei planificari ct mai performan vor prezenta eficiena sistemu- eficient a testrii de performan: lui cu privire la cerinele Non-funcionale. Planificarea i execuia testrii de Urmtoarele detalii, dar nu i singurele, performan ar trebui s fie un efort sunt parte ale raportului asupra testelor de comun al echipei de proiect incluznd performan: software arhiteci i developeri. a. Detaliile legate de sistemul testat, Importana capabilitilor tool-uriIP, detalii despre hardware-ul folosit, lor i a skill-urilor necesare nu trebuie Sistemul de Operare, topologia de reea, neglijat build-ul folosit, data; b. Scenariile rulate i scopul fiecruia dintre ele; c. Tool-urile de performan folosite; d. Msurtorile efective.
Concluzii
Tool-uri
Alegerea tool-urilor folosite pentru testarea de performan va avea n vedere urmtoarele criterii: a. Suportul oferit n rularea scenariilor complexe; b. Capacitatea de distribuire a incrcrii i profilurilor utilizatorilor;
Alexandru Cosma
alexandru.cosma@isdc.eu Senior Tester @ iSDC
45
programare
Recenzia crii:
Eclipse Rich Client Platform de Jeff McAffer, Jean-Michel Lemieux i Chris Aniszczyk
artea pe care v-o supun ateniei face parte din acea serie de cri care au un impact imediat asupra cititorului. Accentul este pus pe latura practic. Conceptele teoretice sunt introduse gradual, de la noiuni cu caracter general pn la lucruri de finee i best practices,dar particularitatea crii constnfaptul c ele sunt integrate imediatntr-o aplicaie care are numeroase funcionaliti i care este, la rndul ei, dezvoltat treptat pe tot parcursul materialului. Din acest motiv, timpul scurs n prezentarea conceptului teoretic, implementarea i evidenierea utilitii sale se scurteaz semnificativ. Astfel, nu mai suntem puinsituaia de a citi despre un concept, pe care l nelegem mai mult sau mai puin, apoi o aplicaie relativ dummy ce l implementeaz i dup mult timp, dac exist, o aplicaie ce integreaz conceptele abordate. Dei foarte popular ca tem, aplicaia Hyperbola prezentat n aceast carte, este, practic, transpunerea utiliznd Eclipse RCP a unui serviciu de mesagerie, cu funcionaliti clasice: stabilirea unui grup de prieteni, comunicarea propriu zis ntre ei, history i multe altele. Aplicaia se constituie ca un model de aplicaie ce folosete RCP, dar i ca sursa de inspiraie pentru pri componente ale unor alte aplicaii RCP. Pe lng implementarea propriu zis penultimul capitol al crii prezint i o modalitate de structurare, mpachetare i livrare a aplicaiei, astfel nct s putem crea sisteme dinamice ce ruleaz pe o mare varietate de sisteme de operare. Am nceput destul de abrupt prezentarea crii Eclipse Rich Client Platform, avnd ca autori pe Jeff McAffer, JeanMichel Lemieux i Chris Aniszczyk, n dorina de a atrage ct mai muli cititori. Pe lng strnirea interesului pentru tehnologia prezentat, cartea aduce i plusul de aplicabilitate i nelegere imediate. Clienii rich (sau fat) pot fi destul de mult asemnai cu aplicaiile stand alone, ce folosesc n comun resurse la distan (spre exemplu baze de date). Ei se deosebesc de clienii thin (care au drept client browser-ul) prin aceea ca folosesc puternic resursele hard i soft ale calculatorului client pe lng, eventual, resurse accesate de la distan. Probabil cea mai mare problem n cazul clienilor thin era dat de faptul c instalrile i modificrile trebuiau s in cont de configuraia hard a calculatorului pe care rula aplicaia. Cum tim foarte bine c numrul acestor configuraii este foarte mare, dificultile erau o provocare greu de rezolvat. Totui existau i multe avantaje, printre acestea: posibilitatea de a lucra offline (fr o conexiune permanent la o reea) sau performane multimedia sporite. Dup prerea mea acest gen de clieni a fost foarte greu de dezvoltat cu caliti arhitecturale bune, pn la apariia framework-urilor. Framework-urile au venit n sprijinul dezvoltatorilor de soft oferind cadre de dezvoltare ce urmreau cele mai bune practici. Evoluia tehnologic a dus apoi la apariia platformelor, care erau colecii de framework-uri precum i de arhitecturi hard ce permiteau soft-ului s ruleze. Primele platforme rich client ofereau doar att: o posibilitate de rulare a logicii unei aplicaii ntr-un sistem de operare. Astzi platformele ofer mult mai mult: un model de component numit i plugin (uor de gestionat, updatat, integrat etc), un middleware deasupra acestor
Silviu Dumitrescu silviu.dumitrescu@msg-systems.com Consultant Java @ .msg systems Romania
46
business

nivelul interfeei utilizator, s putem folosi toolkit-uri precum SWT sau JavaFX pentru renderizarea modelului. Lucrarea este structurat n trei mari pri. Prima zon cuprinde o introducere n RCP cu funcionaliti elementare (logare, key binding, meniu) dar i elemente mai complexe (help, uptate). Partea a doua aduce detaliile de implementare (despre perspective, view-uri, editori, aciuni, comenzi, plugin-uri dinamice, testare) necesare obinerii performanei data de: rafinarea i refactorizarea prototipului obinut anterior, customizarea interfeei utilizator precum i construirea i livrarea produsului ctre utilizator. Partea a treia este a referinelor. Aici se face o trecere n revist a specificaiilor framework-ului OSGi, a framework-ului Eclipse databinding precum i a altor plugin-uri folositoare pentru dezvoltarea aplicaiilor RCP. Framework-ul OSGi este descris amnunit ntr-o alt lucrare OSGi n Action, a crei recenzie o gsii n numrul 9 al revistei Today Software Magazine. Nu n ultimul rnd este interesant de artat cui i se adreseaz aceast carte. Evident, n primul rnd, celor care dezvolt aplicaii RCP. Chiar dac sunt programatori cu experien n utilizarea acestei tehnologii, parcurgerea crii este foarte util. Pe lng evidenierea arhitecturii de succes a unei aplicaii bine puse la punct, se fundamenteaz i detaliaz numeroase concepte teoretice. n al doilea rnd, celor care doresc s aplice principiile rich client-ului n dezvoltarea RIA (Rich Internet Applications). Experiena dobndit la nivelul unui rich client este foarte util pentru aplicaiile Rich Internet. Desigur, cunoaterea 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 nvee sau s se perfecteze n folosirea RCP gsete n aceast carte un suport de pre. Personal, cred c evoluia platformei Eclipse RCP este senzaional i va continua. Introducerea pattern-ului MVC, folosirea OSGi-ului, internaionalizarea, adnotrile i dependency injection sunt doar cteva exemple dintre progresele remarcabile fcute de aceast platform. Dei conine numeroase ghidaje lucrul ntr-o astfel de platform necesit cunotine vaste i bine nelese pentru a putea obine cu adevrat performan. V atept, ca de obicei, cu toat plcerea i interesul, pentru discuii legate de acest subiect. Lectur plcut! Silviu Dumitrescu
componente (ce permite extensibilitate, flexibilitate, scalabilitate, update-uri etc.), au portabilitate la rulare (de la PC-uri pn 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 mbuntiri remarcabile fa de versiunile anterioare. Ultima versiune este Eclipse 4 (Juno) aprut n iunie 2012. Doresc s fac unele specificri referitor noutile din Eclipse 4 i s precizez c ntreaga tehnologie prezentat n carte merit toat atenia. Eclipse 4 se bazeaz foarte mult pe versiunile anterioare i o bun nelegere a acestora va conduce la bune rezultate n dezvoltarea aplicaiilor. Aadar, n Eclipse 4: aplicaia este descris pe baza unei structuri numit modelul aplicaiei; acest model poate fi modificat la dezvoltare sau la rulare. Modelul poate fi apoi extins; exist suport pentru adnotri i dependency injection cu importante implicaii n ceea ce privete folosirea unitilor de testare; widget-urile Eclipse pot fi stilizate folosind fiiere CSS, ca n cazul paginilor web; modelul aplicaiei este decuplat de prezentare ceea ce ne permite, ca la
47
management
De ce ne rcim gura cu AGILE?
rticolul de fa prezint cteva din beneficiile utilizrii metodologiei Agile n viaa de zi cu zi n domeniul IT. Elementul de comparaie este cea mai utilizat metodologie pn pe la nceputul anilor 2000, metodologia Waterfall, cea n care muli 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 internaional. i-a nceput cariera n urm cu 12 ani pe post de developer i a evoluat ca Team Leader, Project Manager, Department Manager, pn la poziii cu responsabiliti executive. Este un constructor de echipe de succes. A coordonat proiecte n Asia de Sud-Est (Singapore, Malaysia), America de Nord (Canada) i Europa (Romnia, Germania, Olanda, UK). Lucreaz cu metodologia Agile din 2006, pe care a utilizat-o n diverse contexte i cu echipe de diferite mrimi.
riscul amnrii livrrii dac se descoper n compararea oricror dou entiti 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 utilizrii metodologiei Agile, calin funcie de: modul lor de a se adapta la tatea produsului este crescut ntruct schimbrile continue ale cerinelor iniiale acesta a trecut prin mai multe faze de ale unui proiect, capacitatea de respectare a testare complet pn la momentul livrtermenelor de livrare, calitatea produsului rii. O echip care utilizeaz metodologia livrat i predictibilitatea evoluiei proiectuWaterfall accept riscul ca defecte majore lui pe parcursul acestuia, att sincronic ct s fie detectate ntr-o faz naintat de i diacronic. testare. Costul necesitat n acest caz penAadar: tru remedieri poate fi destul de ridicat. 1. Adaptabilitate caracteristica funda4. Predictibilitate este unul din atuumental a metodologiei Agile este aceea rile importante ale utilizrii metodologiei c echipa care o utilizeaz poate face Agile. Predictibilitatea este crescut sinfa cu uurin schimbrilor constante cronic, deoarece n orice moment al de pe parcursul unui proiect. Includerea proiectului se tie ce funcionaliti exisreprezentantului clientului n echip pertau la finalul sprint-ului anterior i, cu o mite ajustarea uoar la noile lui cerine precizie crescut, cele care vor fi adugate i schimbarea rapid a prioritilor. n pe parcursul sprint-ului curent. n cazul cazul metodologiei Waterfall schimbrile metodologiei Waterfall, predictibilitatea pe parcursul proiectului sunt mai greu de este crescut diacronic. Ea crete o dat inclus. cu apropierea finalului perioadei de tes2. Termene de livrare pentru o tare i depinde de ntreaga succesiune echip care folosete metodologia Agile de evenimente din cadrul proiectului de livrarea la timp nu este o preocupare. pn atunci. Produsul ar trebui s fie livrabil i stabil la finalul fiecrui sprint ncheiat. n cazul Tabelul de mai jos sintetizeaz utilizrii metodologiei Waterfall, exist informaiile prezentate n aceast prim
48

parte. rulat anterior n manier Waterfall e. Calitatea livrrii: excelent. informaiile incluse n partea a doua a articolului.
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 vrstei (o Disciplina Americii de Nord medie de vrst sub 30 de ani) i deschia. Locaie: Toronto; derii membrilor de a nva i a pune n b. Mrimea echipei: 150; practic lucruri noi. Confirmarea valorii c. Experiena membrilor echipei: foarte echipei i a produsului livrat s-a ntmplat experimentai, echip existent; ntr-un moment de decizie a continurii d. Tipul proiectului: proiect n derulare; colaborrii. Reprezentanii clientului au e. Calitatea livrrii: excelent. decis fr echivoc continuarea colaborrii cu aceast echip, care atunci a primit mai Datorit implementrii eficiente a multe voturi de ncredere din afara compametodologiei Agile la nivel de companie i niei dect dinuntrul ei. a gradului nalt de cooperare ntre membrii echipei, coroborate cu o disciplin model Variabila numit Context i asigurarea unei activiti de QA de cea a. Locaie: Cluj i Germania mai nalt clas, acesta poate fi un exemb. Mrimea echipei: 9 plu ideal pentru conferina a crei tem c. Experiena membrilor echipei: toate central este Agile, Even mamooths can nivelurile, echipa nou be agile.Toate aspectele specific metodolod. Tipul proiectului: proiect nou giei (negocierea iniial, ntlnirile zilnice, e. Calitatea livrrii: bun pair programming) funcionau cu o precizie elveian. Prin urmare, modelul Agile este Acesta este un exemplu n care tranziia utilizabil la nivel de corporaii i echipe cu de la metodologia folosit anterior spre un numr mare de membri. Agile s-a fcut cu dificultate. Din aceast cauz, eficiena procesului de livrare a avut Succesul fulminant al nceptorilor de suferit i valoarea produsului final a a. Locaie: Cluj; fost la nivel mediu. Civa dintre membrii b. Mrimea echipei: 10; echipei au fcut cu greu trecerea spre noua c. Experiena membrilor echipei: majo- modalitate de lucru, iar disciplina a fost un ritatea junior, echipa nou; capitol sensibil, nu foarte uor de gestionat. d. Tipul proiectului: proiect existent, Tabelul de mai jos sintetizeaz
Practica
Concluzie
La ntrebarea dac metodologia Agile e bun, rspunsul ar fi urmtorul: metodologia Agile e foarte bun, dar e alergic la context. ine foarte mult de deschiderea echipei care utilizeaz Agile, disciplina ei, dorina real de a nva lucruri noi i de a le aplica. Dac ar fi s ne gndim la ntrebarea clasic dac metodologia Agile e mai bun fa de Waterfall putem spune c aduce cteva 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 aflm, o lume care vrea s aib vizibilitate ct mai bun asupra lucrurilor, putem spune c metodologia Agile e mai potrivit prin claritatea i gradul de siguran pe care le ofer.
49
management
HR
Cod curat = bani n buzunar
criu acest articol, pentru c am vzut ecuaia cod murdar = bani pierdui de prea multe ori. Articolul este scris att pentru audiena tehnic, ct i pentru cea nontehnic din industria IT. Voi face o introducere scurt i la obiect despre codul curat i cum influeneaz pozitiv aspectele financiare ale unui produs.
Ce este codul?
Dan Nicolici
dnicolici@neverfailgroup.com Senior Java Developer @ Neverfail Group
Exist nenumrate sisteme, n producie, 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 contribuie pozitiv la business. Iat civa dintre indicatorii care arat c avem de a face cu cod ru: nu exist o separare clar a responsabilitilor (clase, metode sau funcii imense), modularitate srccioas (totul e interconectat), multe globale, teste rele sau n care nu putem avea Iat nite ci 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 cuvntul 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 citete foarte uor, e facil de se refer la eventualele consecine ale unei schimbat, scoate la suprafa deciziile de arhitecturi srccioase sau care evolueaz, design, e foarte bine protejat de o suit i la dezvoltarea de software. Datoria poate de teste, e plcut de modelat i lista poate fi considerat munca ce trebuie fcut nacontinua. Simplu spus, codul curat este cod inte ca o sarcin s fie considerat complet. foarte uor de ntreinut. - Wikipedia Programatorul care scrie cod curat, Cu alte cuvinte, lsnd codul surs ntrfaciliteaz munca altor programatori ce l o stare proast (printre alte sarcini nelegate vor modifica. direct de codare), generm datorie tehnic. De obicei, dobnda crete odat cu trecerea Cum e codul n general? timpului, pe msur ce codul putrezete n practic, situaia e foarte diferit (ca s l citez pe Robert C. Martin). de cele descrise mai sus. Vedem cod care Aceast continu cretere a datoriei tehe o dezordine general, care face foarte nice rezult ntr-o descretere a calitii dificil chiar i adugarea unei mici produsului i o cretere a costului adugfuncionaliti la sistem fr a fi nevoie de rii de funcionalitate. Un mod simplu de a a petrece nenumrate ore de citit i rulat msura calitatea unui produs este formula n debug printr-un teritoriu necunoscut. DRE (defect removal efficiency - eficiena de n tiina calculatoarelor, codul surs este orice colecie de instruciuni pentru calculator (posibil cu comentarii) scrise folosind un limbaj de calculator citibil de ctre om, de obicei ca i text. Codul surs al unui program este conceput special pentru a facilita munca programatorilor, acetia specificnd aciunile ce trebuie ndeplinite de un calculator, cel mai adesea prin cod surs - Wikipedia
50
HR
nlturare a defectelor): DRE = Cantitatea de defecte gsite la testing / (Cantitatea de defecte gsite la testing + Cantitatea de defecte gsite de useri) Exemplu:
DRE = 1 / (1 + 9) = 0.1 (10%) => DRE ru DRE = 9 / (9 + 1) = 0.9 (90%) => DRE bun

s adauge specificaii i mbuntiri. Dup cinci ani, dac au procedat corect, vor scdea la aprox. 50$ per punct funcional la repararea de defecte, iar ce cheltuie pe mbuntiri, rmne constant. Deci, dac au procedat corect, costul din primul an pentru repararea defectelor va scdea repede odat cu trecerea timpului. Pe de alt parte, dac au fcut o mizerie, dac nu au construit soft-ul bine i nu au fost ateni, vor cheltui 1200$ per punct funcional pentru adugarea de specificaii noi i 600$ per punct funcional pentru repararea defectelor nainte i 300$ dup punerea lui n producie. i n loc s scad dup cinci ani, costul va rmne constant sau va crete. Deci, dup cinci ani, pot ajunge s aib un produs foarte ru, pe care cheltuiesc 350$ per punct funcional, gsind i reparnd defecte cnd ar fi trebuit deja s fi sczut costul la 50$ per punct funcional. De altfel, acest tip de informaie - costul calitii - este relativ bine cunoscut. [...] Cu ct aplicaiile sunt mai mari, procentajul de proiecte care sunt abandonate i nepuse n producie crete - la peste 10.000 de puncte funcionale, aprox. 35% dintre proiecte care sunt pornite, nu vd niciodat lumina zilei n producie. Cel mai des ntlnit motiv pentru care nu sunt puse n producie este pentru c au avut att de multe defecte, nct nu au funcionat niciodat. Este o conexiune direct intre costul calitii i executarea lucrurilor n mod greit, sfrind cu proiectele abandonate. - extrase dintr-un interviu din 22 ianuarie 2013 Conform celor spuse de Jones, datele ne arat c suntem foarte predispui s pltim de apte ori mai mult pentru mentenana unui produs scris greit. Iat date financiare directe! Aceasta ar trebui s fie un indiciu major pentru att cei care investesc, ct i pentru cei care scriu (codeaz) un produs. Aceasta, bineneles, nseamn c scriind soft de calitate este mai ieftin. Aadar, pentru c la temelia produselor software st codul: cod curat = bani n buzunar!
Capers Jones, un american specializat n metodologii pentru inginerie software, adesea asociate cu modelul pentru estimarea costului punctajului unei funcii, afirm urmtoarele despre cuantificarea conceptelor legate de datoria tehnic: Exist o msurtoare mai veche, numit costul calitii care a fost folosit la cuantificarea datelor existente de ani buni. Unul dintre lucrurile pe care le-am msurat la IBM, ITT i multe alte companii, este ct costa cu adevrat atingerea unor nivele ale calitii. Dai-mi voie s v dau nite numere din industrie ca exemplu. Costul mediu pentru a implementa un oarecare software n S.U.A., este de aprox. 1000$ per punct funcional i, n timpul developmentului, este aprox. jumtate - 500$ per punct funcional, reprezint costul gsirii i reparrii defectelor. Odat ce soft-ul este pus n producie, n primul an, companiile cheltuiesc aprox. 200$ per punct funcional ca s gseasc i s repare defecte i, mai apoi, cheltui aprox. 250$ per punct funcional ca
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
2.
3.
51
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 apruse fr tire n spatele lui Gogu. Auch... m-a prins teleleu pe Google. i trecu prin cap s rspund cu o scuz, dar i ddu seama imediat ct de penibil ar fi fost. Plus c era prea interesat de detaliile tehnice ale GPS-ului. Le afl imediat, efu i ddu rapid toate informaiile. - Da unde mergi? - Le-am promis prinilor c merg cu toat familia la ei. Ne vedem rar cu toii, 450 de km nu-s uor de parcurs cu copilul. i schimb vocea i i maimuri copilul: Tati, mai avem mult? Cnd ajungem? Ct mai avem pn la Buni? Taaati, m-am plictisit... i mai e i mama adic Buni - care vrea s tie exact la ce or ajungem. Dac ntrziem, intr n panic, i nchipuie catastrofe i i se face ru; 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 mi Gogule, c nu e aa tragic situaia. Totul se rezolv uor, ai nevoie doar de nite jaloane. Gogu simi 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 ateptat ca efu s rd de el atunci cnd era necjit cu adevrat. i acum cnd i se destinuise sincer... ncerc s spun ceva, dar i se puse un nod n gt i nu putu dect s lase privirea n jos, dezarmat, trist i incredibil de dezamgit. Nu m ateptam... i spuse. Dintr-o dat totul lu dimensiuni apocaliptice, problema lui nu mai era doar o problem de familie, ci o nenorocire de proporii, lipsa de nelegere a efului deveni semnul clar al unei complicate conspiraii mpotriva sa... - Gogule, alo, eti cu mine? Ce-ai pit? Zmbetul larg al lui efu l ls perplex pe Gogu. Teoria conspiraiei se disip imediat lsnd locul unei singure nedumeriri majore: - Nu neleg, efu, ce e cu jaloanele. C doar n-oi fi vrnd s nfig rui din Cluj pn n Bucureti... H-h-h... Hai, mi Gogule, zu aa, e vorba de jaloanele din teoria managementului de proiect.Un element care marchez un moment important n derularea unui proiect... i d o indicaie asupra poziiei tale n timp i i permite s raportezi modul n care proiectul se ncadreaz n duratele estimate. Adic exact ce i trebuie ie, mi Gogule, pentru drumul tu. Faa lui Gogu nu denota nici strop de inteligen Ba chiar e uor tmp, gndi efu amuzat aa c se grbi s adauge: i stabileti nite repere, localiti importante pe drumul tu. Acelea vor fi jaloanele voastre. Calculezi ct timp i trebuie pentru a ajunge de la unul la altul, astfel nct s tii n funcie de ora la care plecai -, la ce or vei ajunge la fiecare dintre ele. Dac vor aprea ntrzieri, vei ti imediat cum se reflect acestea asupra orei de sosire. Copilului i faci un desen i i ari de fiecare dat cnd atingei un jalon. i dai sarcina s o informeze pe Buni i uite aa ai doi stakeholderi la curent cu evoluia cltoriei voastre. Cum i se pare? ncet-ncet faa lui Gogu se lumin iar efu rsufl uurat: Nu-i sttea bine cu faa dinainte, Gogule. Se pare c acum lucrurile s-au mai luminat puin, ce zici?
Gogu n schimb l ignor total i se apuc s deseneze traseul. Se vedea c i place ideea i dei desenul nu era tocmai conform cu realitatea, arta ct de ct a traseul dintre Cluj i Bucureti. Estim durata deplasrii n funcie de vitez i drum... Se i vedea dnd explicaii docte fiului su i se bucura i la ideea comunicrii poziiei de ctre acesta ctre Buni. Ha! S-ar putea s nu fie chiar att de ru pe ct i nchipuise... - efu, eti mare! Cum a putea s i mulumesc? - 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 abordm, mulam i eu de idee...
simona.bonghez@confucius.ro Speaker, trainer i consultant n managementul proiectelor, Owner al Confucius Consulting
52
sponsori
Comunicm mai simplu direct prin SMS. Propune un titlu de articol pentru numrul urmtor sau trimite-ne sugestiile tale.
powered by
SMS 0371700018
numr cu tarif normal

Today Software Magazine N12/2013

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Today Software Magazine N12/2013

Încărcat de

Drepturi de autor:

Formate disponibile

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

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

6 Susintorii startup-urilor romneti

30 Test Driven Development (TDD)

33 Big Data, Big Confusion

10 Gemini Solutions Foundry

35 Sisteme bazate pe data grids

37 NEO4j Graph Database modelarea datelor interconectate

13 Istoria IT-ului Clujean (VI)

41 Programare Funcional n Haskell (II)

15 Dezvoltarea de aplicaii iOS innd cont de securitate

44 Planificarea Testrii de Performan

18 JQuery Europe 2013

46 Recenzia crii: Eclipse Rich Client Platform

21 Managementul performanei (II)

48 De ce ne rcim gura cu AGILE?

24 Din Uneltele Artizanului Software: Unit Testing

50 Cod curat = bani n buzunar

27 Behavior Driven Development n Python

50 Gogu la drum cu jaloane

Ovidiu Man, PMP

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

V dorim o lectur plcut !!!

Fondator i CEO al Today Software Magazine

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