TO DAY SOFTWARE No. 12 • Iunie 2013 • www.todaysoftmag.ro • www.todaysoftmag.com MAGAZINE Securitatea aplicațiilor iOS Susținătorii startupurilor românești Sisteme bazate pe “data grids” Haskell(II) JQuery Europe 2013 Behavior Driven Development în Python Planificarea Testării de Performanţă Test Driven Development (TDD) Managementul performanţei (II) Start me up - Akcees De ce ne răcim gura cu AGILE? 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)
Transcript
TSM T O D A YS O F T WA R E
No. 12 • Iunie 2013 • www.todaysoftmag.ro • www.todaysoftmag.com
M AG A Z I N E
Securitatea aplicațiilor iOSSusținătorii startupurilor româneștiSisteme bazate pe “data grids”
Haskell(II)
JQuery Europe 2013
Behavior Driven Development în Python
Planificarea Testării de Performanţă
Test Driven Development (TDD)
Managementul performanţei (II)
Start me up - Akcees
De ce ne răcim gura cu AGILE?
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)
6Susținătorii startup-urilor
româneștiOvidiu Mățan
9TechHub Bucharest
Irina Scarlat
10Gemini Solutions Foundry
Radu Popovici
11Start
Me Up
Irina Scarlat
12NGO connect
Echipa NGO Connect
13Istoria IT-ului
Clujean (VI)Marius Mornea
15Dezvoltarea de aplicaţii iOS
ţinând cont de securitateCristian Roșa
18JQuery
Europe 2013 Andrei Otta
21Managementul
performanței (II) Andreea Pârvu
24Din Uneltele Artizanului
Software: Unit TestingAlexandru Bolboaca și Adrian Bolboacă
27Behavior Driven Development
în PythonRamona Suciu și Dan Pop
30Test Driven Development (TDD)Ladislau Bogdan și Tudor Trisca
33Big Data, Big ConfusionMihai Nadăș
35Sisteme bazate pe “data grids”Attila-Mihaly Balazs și Dan Berindei
Am asistat de curând la gala de închidere a programului de antrepreonoriat în echipe Tandem organizat de GRASP Cluj unde am urmărit prezentările a patru echipe ce au arătat proiectele de antreprenoriat realizate în cele opt săptămâni
cât a durat programul. A fost interesant să constat că toate aceste proiecte nu aveau ca bază IT-ul, fiind propuse business-uri tradiționale din domeniul agriculturii precum cul-tivarea plantelor sau creșterea animalelor. Timpul de dezvoltare estimat al unuia dintre ele se întindea pe parcursul mai multor ani până să ajungă la maturitate și să fie lansat pe piață. Din acest punct de vedere, al timpului implicat în materializarea unui proiect de antreprenoriat, domeniul IT este mult mai avantajat. Putem crea un prototip într-un week-end sau într-o noapte, stând acasă sau participând la un hackaton. Este atât de simplu și ușor să materializezi o idee! Chiar dacă nu ești din mediul de IT sau dacă nu ai acum ideea ce va schimba lumea poți participa la Startup Weekend sau Startup Live și să te alături uneia dintre echipe. La finalul weekend-ului vei avea deja disponibil un prototip iar în următoarea săptămână poți să obți suport din partea unor incubatoare locale. Vă încurajăm să faceți acest exercițiu, iar pentru cei ce l-au făcut deja și au un prototip, am pregătit articolul Susținătorii Startup-urilor românești.
Lansăm și un nou serviciu, www.programez.ro, o nouă modalitate de comunicare între specialiști. Practic, panelurile unconference ce se desfășoară în cadrul evenimen-telor de lansare vor putea fi continuate online pe acest forum de discuții. De asemenea, ne va face plăcere să răspundem întrebărilor tehnice pe care le aveți din toată sfera de IT: programare, testare, management sau HR. Fiind o inițiativă TSM, vă putem garanta răspunsuri venite direct de la specialiști.
O altă noutate este introducerea unui nou canal de comunicare cu cititorii noștri, prin suportul oferit de TXT Feedback. Aceste startup local oferă posibilitatea de a comunica în magazine și nu numai prin intermediul SMS-urilor. Astfel, începând cu luna iunie, vă oferim posibilitatea de a ne transmite feedback-ul sau întrebările voastre direct, printr-un SMS la numărul 0371700018.
Un eveniment important, ICT Spring Europe 2013, va avea loc în Luxembourg în perioada 19-20 Iunie, la care vom fi prezenți la acesta cu numărul 12 TSM. Vă invităm să participați alături de noi, iar pentru aceasta vă oferim un cod promoțional ce va oferă participarea gratuită la eveniment: TSMS13.
Articolele din acest număr debutează cu o listă de incubatore și cowork-uri implicate activ în susținerea startup-urilor românești. Puteți să o folosiți cu încredere. Testarea primește o atenție binemeritată printr-o serie de articole ce au în focus Test Driven Development (TDD), Behavior Driven Development (BDD) precum și Performance Testing. Dezvoltarea aplicațiilor în cloud este dezbătută pe larg în Big Data, Big Confusion, Sisteme cu perfomanță/fiabilitate ridicată bazate pe “data grids” în Java, NEO4j Graph Database modelarea datelor interconectate și Hadoop (II).Continuând în aceeași notă de dezvoltare software veți găsi partea a II-a din Programare Funcțională în Haskell. JQuery Europe 2013 a fost un eveniment de excepție, iar în acest număr avem un articol dedicat acestuia.
Închei prin a reaminti de proiectul Timeline care este în derulare. Pe scurt, TSM a inițiat un proiect care vizează realizarea unui afiș infografic referitor la dezvoltarea companiilor românești și la principalele realizări ale acestora. Adresa de email [email protected] este dedicată celor ce vor să fie parte din acest proiect.
Vă dorim o lectură plăcută !!!
Ovidiu MăţanFondator și CEO al Today Software Magazine
Co-work-urile sau spațiile de lucru comune O practică nouă pe piața locală este reprezentată de închirierea
unui birou pentru un anumit număr de ore sau zile. La finalul zilei acel spațiu este eliberat astfel încât ziua următoare altcineva poate să îl folosească. Avantajul acestei abordări este diversitatea, posibi-litatea de a realiza rapid legătura cu diferite alte business-uri și de a putea lua rapid pulsul local. Datorită naturii acestora de a nu avea un spațiu permanent dedicat, numărul de evenimente organizate este mare, iar prin legăturile sau organizațiile afiliate vizibilitatea business-urile este mărită.
TechHub BucureștiServiciile oferite• spațiu co-working,• birouri de tip rezi-
dent cu acces 24/7,• evenimente orga-
nizate de TechHub și comunitatea online.
Afilierea la o organizație internaţională• TechHub, comunitate globală dedicată exclusiv antrepre-
norilor în tehnologie, fiind reprezentată în prezent la Londra, Manchester, Riga și București.
Criteriile de acceptare:• Startup-uri tech.Datele de contact• blvd. Nicolae Filipescu nr. 39 - 41, etaj 1, sector 1, București,• bucharest.techhub.com
Cluj CoWorkUn spațiu plăcut în centrul Clujului oferind senzația de acasă.
Există suport de internet (WiFi), fructe, apă și cafea. Dacă vre-mea este bună se poate lucra pebalcon și ești înconjurat de oameni muncitori deschiși să te ajute în cazul în care aveți probleme. Cluj CoWork te face productiv într-un mod relaxant. Pentru startup-uri se oferă programe de mentorat, design și suport în dezvoltarea aplicațiilor.
Investiții: Au fost făcute investiții financiare, de timp și servicii pentru startup-uri.
Cum sunt atrași investitorii? Folosim networking-ul propriu pentru aceasta
Costurile lunare pentru a lucra în cadrul co-work-ului?140 EUR/lună iar în prima lună se oferă un discount de 20
EUR. Pentru startup-uri suntem întotdeauna deschiși la discuții.Care sunt criteriile pentru a fi acceptat? Aceleași pentru toată lumea ...dacă ești serios, motivat, mun-
citor și open minded atunci ești acceptat.
C a r e s u n t activitățiile din cadrul Cowork-ului?
În fiecare săptă-mână se desfășoară e v e n i m e nt e i n t e -re s ant e c u m e s t e GeekMeet. În afară de aceste evenimente de relaxare și socializare cum ar fi Sangria-nights, Cocktail courses, sushi making & eating și barbecue’s.
Datele de contact:• str. Emil Isac, nr. 3, Cluj-Napoca• clujcowork.ro
Cluj HUBPe lângă posibilitatea de a-ți desfășura activitatea profesională
de la unul dintre cele 4 nivele (+gradina) dotate cu birouri și mese colaborative, la ClujHub îți oferim și servicii conexe care aduc valoare business-ului tău:
• servicii financiare și contabilitate specializate pe start-up,• servicii juridice și de „intelectual property”,• servicii de business development și consultanță în atragerea
de investitori,• servicii de matchmaking și networking,• servicii de găzduire a sediului social,• servicii de printing și design,• închirieri săli pentru workshop-uri și conferințe până la
maxim 90 de persoane.
Numărul de echipe înscrise:În momentul de față mai mult de 10 companii fac parte din comunitatea noastră estimând ca până la sfârșitul anului 2013 vom ajunge la 35 companii și mai mult de 50 de membri.
Modul de atragere a investitorilor: Dintre companiile pe care le găzduim una dintre ele a obținut o finanțare în cadrul unui pro-gram de accelerare de aproximativ 30 000 euro.
Deși ne aflăm la început în privința startup-urilor românești și încă nu ne putem mândri cu o cultură de masă a mediului de IT autohton, susținătorii acestora încep să își facă din ce în ce mult mult simțită prezența. Prin acțiunile și facilitățile oferite au un scop comun și anume suportul business-urilor locale și succes-ul acestora. Articolul de față se vrea a fi o listă de puncte
de contact pentru oricine are sau dorește să lanseze un startup.
7www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINE
Perioada de incubare:Investitorii cu care comunicăm fac parte atât din comunitatea locală și ne întâlnim periodic cu ei dar avem și investitori din comunitatea internaţională.
Afilierea la o organizație internaţională: Nu avem o afiliere la o organizație internaţională, dar colaborăm cu multe entități similare.
Modul de tarifare: Pentru a-ți desfășura activitatea din cadrul ClujHUB, pe aria de cowork, tarifele pentru membri încep de la 30 euro și pot ajunge la 140 euro pentru nivelul full acces.
Criteriile de acceptare: Criteriile de acceptare sunt destul de subiective mergând pe potrivirea lor cu ceilalți membri ai comu-nităţii dar plecăm în profilarea noastră de la:
• freelanceri - profesii liberale sau startup-uri,• străini cu delegaţii în Cluj; în aceasta arie avem un partene-
riat de lunga durată cu Cluj International Club,• companii care vizează investiţii locale,• antreprenori care dezvoltă servicii sau produse noi și care
aduc inovația în piață,• antreprenori sociali și persoane care valorizează implicarea
în comunitate,• persoane open minded și deschise către colaborare și dez-
voltare personală.
Activitățile din cadrul incubatorului: sunt multe evenimente care poate trebuie tratate separat pentru că din iunie vor fi mai numeroase.
Datele de contact:• str. Pitești, nr. 9, Cluj-Napoca• clujhub.ro
Platforme de crowdfundingImplicarea comunității în suportul dezvoltării proiectelor este
un lucru inedit. Suportul vine direct de la utilizatorii ce doresc să devină clienții respectivei afaceri înainte ca aceasta să existe de fapt. Propunerea din acest număr, multifinanțare.ro reprezintă o abordare interesantă.
multifinanțare.roO f e r ă s e r v i c i i d e
c r o w d f o u n d i n g p r i n publicarea proiectelor pe platforma proprie. Fiecare proiect ce obține 50% din suma cerută de la crowd va primi încă 50% din partea investitorului.
Proiectele acceptate trebuie sa aibă o compo-nentă inovativă. Acestea au asigurată consultanță juridică, financiară fis-cală și investițională. Vom publica mai multe despre această inițiativă într-unul din numerele viitoare ale revistei.
Date de contact:• multifinantare.ro• B-dul N. Titulescu Nr. 4 , Cluj-Napoca
Acceleratoare/incubatoare de startup-uriDacă în soluțiile de până acum, suportul oferit era ca un
serviciu adițional, iar motorul business-ului era reprezentat de închirierea spațiului sau reținerea unui procent din suma obţinută, aceleratoarele/incubatoarele reprezintă o categorie unde succesu-lacestora este legat 100% de startup-uri. Problema principală în acest caz este acceptarea în cadrul acestora, iar odată acceptat beneficiați de sprijin dedicat pentru transformarea startup-ului într-un business real.
Gemini Solutions FoundryEste primul incubator destinat exclusiv startup-urilor IT
d i n R om â n i a c e facilitează crearea conexiunilor între antreprenorii români ș i invest itori din Silicon Valley. Oferă echipelor acceptate în programul de incubare spațiu de birouri la cheie cu toate utilitățile necesare și acces la săli de conferințe și de prezentări.
Mentorship-ul tehnic este asigurat de persoane cu o bogată experiență tehnică din echipa Gemini Solutions, persoane ce au lucrat pentru companii de diferite dimensiuni de la startup-uri până la multinaționale în aproape toate domeniile existente, de la back-end la front-end, de la cloud computing la aplicații destinate pentru mobile.
Consultanţă financiară și cea legală oferite au ca scop ușurarea muncii depuse în aceste direcții pentru a permite antreprenorilor să se concentreze la ceea ce contează cu adevărat într-un start-up și anume implementarea ideii.
Dar poate cea mai interesantă facilitate este reprezentată de conexiunile cu fonduri de investiții din Silicon Valley. Aceste conexiuni se fac în cadrul unui eveniment anual denumit Demo Day unde echipele vor prezenta atât ideea lor cât și progresul efec-tuat în cadrul programului de incubare. Acest tip de finanțare este foarte important pentru creșterea ulterioară a echipei deoarece pe lângă banii primiți echipa beneficiază și de conexiunile dar și de îndrumarea investitorului, altfel spus: Smart money.
Datele de contact:• gemsfoundry.com
NextPhaseNextPhase este interesată de proiecte inovative care au
potenţial comercial. Prin implicarea sa, Ne x t P h a s e c om -pletează resursele necesare proiectului pentru a asigura pro-gresul corespunzător al acestuia. Astfel, în proiectele pe care le considerăm de interes, noi putem să participăm printr-o combinaţie de servicii, cum ar fi: organizarea și managementul procesului de cercetare-dezvoltare, elaborarea și managementul strategiei de proprietate intelectuală, furnizarea de infrastructură,finanţare, managementul business-ului, elaborarea și dezvoltarea strategiei de creștere, acces la surse suplimentare de investiţie, programe de formare (trai-ning) pentru echipele de inventatori/antreprenori. Cu o adaptare
TODAY SOFTWARE MAGAZINE
8 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
startups
corespunzătoare a termenului, am putea afirma că NextPhase este un incubator de tehnologie de tip “one stop shop” unde ideile cu potenţial comercial găsesc ceea ce au nevoie pentru a deveni afa-ceri de succes.
Numărul de echipe înscrise -La 31 Dec 2012, aveam 2 proiecte în derulare și 3 proiecte în pregătire. Următorul proiect va fi în domeniul de software, mai precis modelare și simulare și va fi demarat în luna Iunie. Celelalte două proiecte, cel mai probabil, vor porni spre sfârșitul celui de-al treilea trimestru al acestui an.
Modul de atragere a investitorilor - Până la un anumit nivel, NextPhase este investitorul. Acest nivel depinde în principal de proiect, de necesarul de resurse în fazele planificate și evoluţia proiectului până în acel moment. Mai departe, strategia de atra-gere a investitorilor depinde foarte mult, din nou, de domeniul proiectului, de indicatorii și riscurile acestuia. Oricum, până la urmă, iniţierea unei colaborări sănătoase cu un investitor nu se poate baza decât pe o propunere de afaceri corectă și transparentă.
Perioada de incubare - Din motive legate atât de partea teh-nică, cât și de partea comercială, noi ţintim o perioadă de incubare de circa 12 – 18 luni de zile. Bineînţeles, pot exista și excepţii, dar acestea trebuie să fie bine fundamentate.
Afilierea la o organizație internaţională - NextPhase este sub-sidiară a Flogistics AG Elvetia și dispune de o reţea proprie de consultanţi și potenţiali investitori. NextPhase nu face parte din nici o reţea notorie de incubatoare de tehnologie. Se pare că acest lucru poate fi un avantaj din punct de vedere a vitezei deciziilor și a adaptabilităţii la specificul proiectelor.
Suportul oferit după ce echipele părăsesc HUB-ul: Prin natura implicării, NextPhase continuă și își adaptează
suportul oferit și după perioada de incubare, practic până la momentul de ieșire (“exit”) din afacere. Suportul și strategia de ieșire depind de gradul de succes al proiectului și evoluţia capaci-tăţii de funcţionare autonomă a acestuia.
Modul de tarifare pentru co-work - În general, noi ne implicăm doar în proiectele în care credem și uzual, această implicare se face în schimbul unei participaţii la beneficiile care vor rezulta. Este destul de greu să participi la succesul unui proiect în fază de incu-bare prin a tarifa în avans consultanţă care este, în general, unul dintre serviciile cele mai scumpe. Astfel, de obicei, noi nu tarifăm implicarea noastră, ci ne asumăm misiunea și riscurile proiectului, ulterior beneficiind de o parte din succesul financiar al acestuia.
Criteriile de acceptare - Principali indicatori care-i folosim în evaluarea proiectelor sunt: caracterul inovativ/diferențiator al conceptului care stă la baza proiectului, potenţialul comercial al ideii și, foarte important, echipa de inventatori/antreprenori. Ca și filozofie de acţiune, credem că este nevoie de o idee bună, deo implementare corespunzătoare, dar și de pasiunea și anduranţa de a face faţă obstacolelor care, invariabil, sunt prezente de-a lungul proiectului.
Activitățile din cadrul incubatorului: - Pe lângă activitatea prin-cipală de dezvoltare de proiecte, NextPhase organizează seminarii de prezentare, evenimente de networking, programe de formare pentru echipele de inventatori/antreprenori în dorinţa de a contri-bui la dezvoltarea comunităţii antreprenoriale clujene.
În ultimii ani România a urmat tendin-ţele din vest, iar fenomenul de co-working a început să capete amploare. În marile orașe din ţară s-au dezvoltat hub-uri antre-prenoriale: locuri în care antreprenori și freelanceri lucrează împreună. Mai mult decât atât, membrii schimbă idei și expe-rienţe, utilizează în comun resurse și își împărtășesc lecţiile învăţate unii altora, ceea ce duce la coagularea unei comunităţi. La asta se adaugă faptul că evenimentele care au loc în spaţiile de co-working sunt relevante pentru comunitate și îi ajută să își dezvolte companiile mai repede și mai eficient.
Beneficiile de a lucra într-un astfel de loc explică gradul ridicat de ocupare al TechHub Bucharest la mai puţin de o lună de la lansare. Antreprenorii aflaţi la început de drum conștientizează că apartenenţa la o comunitate îi ajută să evolueze rapid și apreciază deschiderea internaţională pe care le-o oferă statutul de membru rezident.
De ce TechHub și cum s-a născut proiectul?
TechHub este o comunitate globală dedicată exclusiv antreprenorilor în teh-nologie. Conceptul a luat naștere în 2011 la iniţiativa lui Mike Butcher (European Editor TechCrunch) și Elizabeth Varley. În ultimii doi ani, TechHub a sprijinit inovaţia și dezvoltarea start-up-urilor în tehnologie în Londra, Riga și Manchester.
Totul a început anul trecut, mai exact pe 5 iunie 2012, cu un simplu articol de blog scris de Bogdan Iordache (Co-Fondator al How to Web, cel mai important eveni-ment despre antreprenoriat și tehnologie din Europa de Sud-Est). Echipa How to Web tocmai primise vestea că Bucharest Hub urma să se închidă, așa că Bogdan și-a întrebat cititorii, membrii ai comunităţii, dacă au nevoie de un hub. Răspunsurile pozitive au fost numeroase, așa că Bogdan s-a hotărît să dezvolte în continuare acest proiect. O zi mai târziu, publica o lista de criterii pe care The Next Hub (denumirea iniţială a ceea ce astăzi este Tech Hub) tre-buia să le îndeplinească.
A fost nevoie de multă muncă, oameni excepţionali, dedicare și pasiune, pen-tru a transforma proiectul The Next Hub în TechHub Bucharest de astăzi. Bogdan Iordache a lucrat alături de Daniel Dragomir și Ştefan Szakal, Co-Fondatori ai TechHub, iar împreună au făcut lucrurile să se întâmple. Toate astea cu multă determi-nare și sprijinul unor oameni care au avut încredere în proiect încă de la început și au contribuit semnificativ la dezvoltarea lui: Victor Anastasiu, Dan Călugăreanu, Vodafone și Adobe România.
Astăzi, TechHub Bucharest îndeplinește toate criteriile stabilite iniţial: este în inima Bucureștiului (Str. Nicolae Filipescu nr. 39-41, la 5 minute de mers pe jos de staţia de metrou de la Universitate), are un cost rezonabil și este un spaţiu deschis în care membrii, mai mult decât acces la un birou și un spaţiu de co-working, beneficiază de interacţiune de calitate și pot participa la evenimentele organizate de TechHub și comunitatea online.
Spaţiul de 420mp este împărţit între 35 de birouri permanente pentru membrii rezidenţi, 60 de locuri pentru co-working, săli de întâlnire, și un spaţiu de evenimente cu o capacitate de până la 150 de persoane. TechHub își propune să devină centrul comunităţii antreprenoriale din București și aduce împreună antreprenori, freelanceri, investitori, companii tech, dezvoltatori, bloggeri sau jurnaliști.
Pe 9 mai, sala de evenimente a devenit neîncăpătoare pentru membrii comuni-tăţii care au venit din toate colţurile ţării pentru a participa la deschiderea oficială. Evenimentul de lansare a adus împreună reprezentanţi importanţi de pe scena tech românească și s-a bucurat de prezenţa invi-taţilor speciali – Mike Butcher (European Editor TechCrunch) și James Knight (International Development Manager TechHub).
Seara a început cu un mesaj din partea membrilor fondatori, Bogdan Iordache, Daniel Dragomir și Ştefan Szakal și a con-tinuat cu un panel dedicat startup-urilor,
panel în care au fost prezenţi Bobby Voicu (Mavenhut), George Lemnaru (Green Horse Games) și Vladimir Oane (UberVu). Cei trei au povestit traseul par-curs cu propriile start-up-uri și au subliniat încă o dată importanţa TechHub ca factor agregator pentru start-up-urile tech din România.
A venit apoi rândul investitorilor să urce pe scenă. Andrei Pitiș, Marian Dușan și Radu Georgescu au vor-bit despre ce caută un investitor la un start-up, iar Paula Apreutesei (Romanian-American Foundation), Cătălina Rusu (Geekcelerator), Mihai Sfinţescu (3TS Capital Partners) și Dan Lupu (Earlybird) au vorbit despre programele de suport pen-tru antreprenori și fondurile de venture capital. S-a discutat ca de obicei și despre inovaţie cu reprezentanţii celor mai mari centre de cercetare-dezvoltare autohtone: Alex Marinescu (EA Games), Teodor Ceaușu (IXIA) și Dragoș Georgiţă (Adobe România), iar la final, invitaţii evenimen-tului au avut ocazia să interacţioneze în cadrul unei petreceri aniversare.
TechHub Bucharest pune încă o dată România pe harta globală a inovaţiei și antreprenoriatului, iar spaţiul din Nicolae Filipescu va deveni foarte curând inima unei comunităţi active la nivel naţional și va aduce împreună cele mai importante evenimente autohtone dedicate tehnolo-giei. TechHub Bucharest, engage!
Luna mai a început cu vești bune pentru comunitatea antreprenorilor în tehnologie din România: s-a lansat oficial TechHub Bucharest, primul spaţiu de co-working din România care le este dedicat în exclusivitate și care face parte din reţeaua interna-ţională TechHub.
Gemini Solutions FoundryPrimul incubator de afaceri IT din România cu deschidere către Silicon Valley
Un caz aparte este reprezentat de start-up-urile din sfera IT datorită pieței extrem de dinamice ce poate duce fie la o ascensi-une rapidă (acompaniată de un număr mare de utilizatori) fie la o pierdere în anonimat. Urmând exemplul Statelor Unite, această categorie de afaceri începe să se bucure de o atenție deosebită și în România, atenție manifestată prin inaugurarea unor hub-uri (cunoscute și sub denumirea de spații de co-work) și incubatoare de afaceri destinate exclusiv mediului IT.
Dacă în cazul hub-urilor accentul este pus pe comunitatea creată și pe eve-nimentele de networking desfășurate, în cazul unui incubator putem vorbi despre o implicare mai mare din partea organi-zatorilor prin oferirea unui mentorship tehnic și a unor servicii de consultanță financiară și legală. De asemenea și prin crearea conexiunilor cu potențiali clienți, parteneri și investitori. Datorită acestor modalități diferite de abordare într-un hub vom găsi un număr mare de echipe ce plă-tesc o taxă lunară pe când în cadrul unui incubator, datorită atenției sporite acor-date participanților, vom întâlni un număr restrâns de echipe care vând un procent din companie ca modalitate de plată.
În curând se va deschide în București Gemini Solutions Foundry – primul incu-bator destinat exclusiv startup-urilor IT din România ce facilitează crearea conexiunilor între antreprenorii români și investitori din
Silicon Valley. Localizat în Piața Victoriei din
București, la doi pași de stația de metrou cu același nume, Gemini Solutions Foundry oferă gratuit echipelor acceptate în progra-mul de incubare spațiu de birouri la cheie cu toate utilitățile necesare și acces la săli de conferințe și de prezentări.
Mentorship-ul tehnic este asigurat de persoane cu o bogată experiență tehnică din echipa Gemini Solutions, persoane ce au lucrat pentru companii de dife-rite dimensiuni de la start-up-uri până la multi-naționale în aproape toate domeniile existente, de la back-end la front-end, de la cloud computing la aplicații destinate pen-tru mobile.
Consultanţă financiară și cea legală oferite au ca scop ușurarea muncii depuse în aceste direcții pentru a permite antre-prenorilor să se concentreze la ceea ce contează cu adevărat într-un start-up și anume implementarea ideii.
Dar poate cea mai interesantă facilitate este reprezentată de conexiunile cu fonduri de investiții din Silicon Valley. Aceste cone-xiuni se fac în cadrul unui eveniment anual denumit Demo Day unde echipele vor pre-zenta atât ideea lor cât și progresul efectuat în cadrul programului de incubare. Acest tip de finanțare este foarte important pen-tru creșterea ulterioară a echipei deoarece pe lângă banii primiți echipa beneficiază și de conexiunile dar și de îndrumarea
investitorului, altfel spus: echipele benefi-ciază 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 com-panie, procent ce se negociază cu fiecare echipă în parte. Acest lucru scutește echi-pele de o cheltuială suplimentară în faza incipientă când banii sunt de multe ori o problemă, și în felul acesta prosperitatea startup-ului se reflectă și asupra incuba-torului. Acest lucru duce la o aliniere a intereselor ambelor părți.
Prin serviciile oferite, Gemini Solutions Foundry vine în sprijinul antreprenorilor din mediul IT din România și îi ajută să își extindă afacerea pe plan internațional, în special pe piața Statelor Unite ale Americii – una dintre cele mai mari, mai dinamice și mai competitive piețe din lume. Cei interesați să participe în acest program sunt invitați să trimită un mail la adresa [email protected] sau să completeze formularul de contact de pe site (http://gemsfoundry.com).
În ultima perioadă antreprenorii români au la dispoziție din ce în ce mai multe modalități de a-și facilita dezvoltarea unei afaceri. Fie că vorbim despre fonduri nerambursabile, comunități antreprenoriale sau incubatoare de afaceri, aceste programe sunt un ajutor incontestabil, mai ales în fazele incipiente ale dezvoltării companiei.
Pe parcursul evenimentului, parti-cipanţii au învăţat care sunt pașii pe care trebuie să îi parcurgă pentru a-și materi-aliza propriile idei, au realizat planuri de afaceri și au încheiat prin a-și valida con-ceptul de business prezentându-l în faţa unui juriu de specialitate.
Fiecare zi a școlii de antreprenoriat Start Me Up a fost dedicată unui anumit aspect al planului de afaceri. Astfel, par-ticipanţii au început printr-un proces de generare și selecţie de idei, au continuat cu realizarea planului de marketing și respec-tiv a planului financiar, și au pregătit apoi planul de afaceri și prezentarea propriului proiect.
Participanţii au avut ocazia să discute în mod direct cu unii dintre cei mai apre-ciaţi antreprenori și investitori români și să afle poveștile de succes ale acestora. Printre oamenii de excepţie care au fost prezenţi la Start Me Up se numără Peter Barta (Director Executiv Fundaţia Post-Privatizare), Dragoș Anastasiu (Președinte Eurolines și TUI Travel Center), Bogdan Iordache (antreprenor serial, co-fon-dator How to Web), George Lemnaru (antreprenor serial, co-fondator eRepu-blika), Bogdan Grosu (fondator Grosu & Asociaţii), Niels Schnecker (om de afaceri, analist economic, colonel în retragere al US Air Force și om de televiziune), sau Tiberiu Mitrea (antreprenor, fondator NaturaLact). Trainer pe toată durata programului a fost Daniel Ramamoorthy, CFO, director al companiei de investiţii Phoenix Group și antreprenor serial.
În ultima zi a evenimentului, echi-pele participante au prezentat proiectele dezvoltate pe toată durata programului în faţa unui juriu de specialitate. Echipa
câștigătoare a dezvoltat Boomerang, o companie de consiliere și orientare profe-sională pentru elevii de liceu, și a primit o investiţie iniţială de 2000 de euro pen-tru implementarea proiectului, alături de înfiinţarea gratuită a afacerii. Un premiu special pentru profesionalism a fost acor-dat și cofetăriei Bartello, iar Bogdan Cange și Vlad Tudose, participanţi Start Me Up, au primit distincţii speciale pentru curaj și respectiv perseverenţă.
„În contextul în care ţara geme de pro-bleme și toată lumea așteaptă să li se dea, voi demonstraţi că nu așteptaţi și vreţi să faceţi ceva. Văzându-vă pe voi realizez că există o șansă pentru România!”, ne spunea anul trecut Dragoș Anastasiu, Președinte Eurolines și TUI Travel Center.
Rezultatele nu au întârziat să apară și, la un an după eveniment, impactul aces-tuia este vizibil. Pregătirea participanţilor a continuat prin realizarea de sesiuni lunare de mentorat, sesiuni în care tinerii au avut ocazia să stea de vorbă cu unii dintre cei mai apreciaţi antreprenori și investitori români.
Vlad Tudose, alumni Start Me Up care a primit premiul special al juriului pentru perseverenţă, și-a schimbat ideea iniţială de business și a pus bazele unui start-up: Puzzled.by, o platformă online de întrebări și răspunsuri. Puzzled.by a primit deja o finanţare iniţială de 50.000 EUR de la un grup de investitori americani de tip angel, iar start-up-ul a fost acceptat în competiţia organizată în cadrul conferinţei internaţio-nale Shift care are loc în Croaţia.
Pasionat de antreprenoriat, Sebastian Mărăloiu este un alt alumni Start Me Up cu o poveste remarcabilă. Se pregătea să lanseze versiunea alfa a Bring the Band,
p l a t f o r m ă care permite pu b l i c u lu i să își aducă artiștii pre-feraţi la ei în localitate,
când a identificat alături de partene-rul său de afaceri o oportunitate unică: Formspring, o platformă de socializare cu peste 30 de milioane de utilizatori activi nu își putea susţine creșterea și urma să se închidă. Sebi și partenerul său au lucrat zi și noapte pentru a profita de această oportu-nitate și au reușit să lanseze două săptămâni mai târziu YouReply, o platformă dezvol-tată cu o investiţie iniţială de 50$ care are în prezent peste 14.000 utilizatori.
Poveștile de succes pot continua. Fie că își dezvoltă în prezent propriile start-up-uri sau că acumulează experienţă pentru a deveni în viitor antreprenori, Start Me Up a deschis orizonturi și a schimbat vieţi. Ca urmare, echipa Akcees se pregătește de cea de a doua ediţie a proiectului care va avea loc în perioada 21 – 27 iulie la Pensiunea Speranţa din Predeal. Reţeta succesului este păstrată și de această dată: un trainer internaţional, antreprenori și investitori români de succes, participanţi de claitate și o experienţă care nu ar trebui ratată de nici un tânăr care își dorește să pornească la drum pe cont propriu.
Ineditul acestei ediţii constă însă în organizarea unei campanii naţionale de promovare a antreprenoriatului: Caravana Start Me Up. Intre 20 iunie și 4 iulie, echipa Akcees va susţine workshop-uri despre antreprenoriat în 8 orașe din România și va aduce în faţa audienţei antreprenori care au reușit. Pentru Akcees, vara asta stă sub semnul antreprenoriatului! Pentru tineri, este vara în care au șansa de a învăţa cum să-și transforme visele în realitate!
25 de participanţi foarte bine pregătiţi selectaţi din peste 200 de aplicaţii... un trainer internaţional... 8 antreprenori și investitori consacraţi din România... 5 noi idei de afaceri... 5 companii responsabile care au oferit burse pentru viitorii antreprenori... 45 de parteneri care au asigurat mediatizarea proiectului și 176 de apariţii în presa din România. Așa arată în cifre prima ediţie a școlii
de antreprenoriat Start Me Up care a avut loc anul trecut la Predeal.
Marius Chincișan, cel care a avut ideea iniţială, și căruia echipa ar dori să îi mulţu-mească pentru că i-a adus împreună, a luat emoţionat microfonul în mână și a spus că vrea sa construiască o platformă pentru ONG-uri, unde oricine interesat poate să găsească diverse proiecte sociale și poate să se implice activ într-o anumită cauză. Acesta a fost începutul NGO CONNECT , iar cuvântul magic care i-a reunit pe cei 7 a fost ONG.
În acea noapte a început maratonul de 54 de ore…cu toţii entuziasmaţi. S-au strâns o mulţime de idei care reflectau vizi-unea fiecăruia asupra proiectului. După nenumărate ore de brainstorming rezulta-tul începea să prindă contur: o platformă web care să adune la un loc cele 4 entități: ONG-uri, voluntari, donatori, și companii. În momentul de față muncim la dezvoltarea acestei platforme pentru că noi credem cu tărie că vom putea schimba lumea în bine
și cel mai important, că putem aduce bucurie în vieţile altor oameni.
Fo c u s u l n o s t r u principal este să adu-cem în acelaș i loc ONG-uri și oameni care cred în aceleași cauze nobile. Se știe că e în natura umană să existe îndoială vizavi de orice. Noi înţelegem că oamenii au reţineri în a-și pune încrederea în ceva sau cineva, cu atât mai mult legat de banii proprii și de destinaţia acestora. Aici intervine NGO CONNECT. Se vrea eliminarea acestor îndoieli printranspa-rentizarea colectării și cheltuirii fondurilor. Totodată prin inter-m e d iu l p l at for m e i încercăm să ducem implicarea părților la un alt nivel. De exemplu, dacă un proiect vizează ajutarea unei fetiţe cu o situaţie materială precară,în momenul îndeplinirii scopului cauzei sociale, donato-rul va primi un video de mulţumire direct de la fetiţa în cauză, even-tual și câteva poze, dar
și date de contact ale cazului. Vrem să CONECTĂM toţi factorii
cheie din sfera cazurilor sociale și anume: ONG-uri, voluntari, donatori și mai ales corporaţii. De ce corporații? Pentru ca ele au politici și bugete de CSR (Corporate social responsibility).Responsabilitatea socială corporatistăreprezintă o parte inte-grantă din cadrul oricărei mari companii, prin intermediul căreia se implică activ în rezolvarea problemelor societății în care își desfășoară activitatea.
Echipa care se ocupă ca aceste lucruri să fie posibile e formată din tineri cu experiență în diverse domenii: economic, IT, ONG, blogging, etc.. Echipa aceasta a fost pe bună dreptate declarată ca fiind cea mai unită din competiţie. Nu au fost momente în care să se fi separat, sau să își fi dorit să renunţe și mereu au acţionat fairplay. Pe întreg weekendul, nu s-a folo-sit pronumele “eu”. Toată lumea a avut un singur focus și anume ca proiectul să fie un succes. Şi a fost. Am luat locul 3, dar noi ne-am simţit la fel de câștigători ca și cei de pe locul 1. Şi încă ceva…echipa a avut cu adevărat chimie, se vede și în poza articolu-lui, care îi are pe ei în prim plan. Au început ca străini și s-au despărţit la sfârșitul week-endului ca niște prieteni.
Concluzia este simplă: scopul platfor-mei este să ajute cât mai mulţi oameni. Pentru că nu este un mit că atunci când oferi, primești înapoi dublu. Această echipă a fost adusă împreună de către un singur scop și sper ca toţi cei care citesc acest arti-col se vor implica activ în misiunea noastră, aceea de a face lumea mai bună.
NGO CONNECT are în spate o minunată poveste ce a început în seara zilei de 24 mai. 7 tineri antreprenori care nu se cunoș-teau între ei, au venit din trei orașe diferite (Cluj-Napoca, Iași, București) către Tîrgu Mureș. Au călătorit sute de km pentru că ideea de Startup Weekend părea să fie o experienţă grozavă. La sfârșit s-a dovedit a fi una dintre cele mai frumoase experienţe
pentru ei, una care nu va fi uitată niciodată, una care poate să le aducă bucurie lor, dar cel mai important altora.
Inginer interesat și implicat în diverse activități IT, de la dezvoltare, management, până la educație și jurnalistică în cadrul Epistemio, UTCN și TSM
1957 înființareamomentul nașterii ITC la Cluj, anul în care Tiberiu Popoviciu, matematician de renume, fondează Institutul de Calcul cu Departamentul de Calculatoare – prima instituție din domeniul ITC în Cluj. Instituție ce a dat tonul dezvoltării cerce-tării și educației, baza comunității actuale.
1948 - Emil Petrovici fondează filiala Academiei Române din Cluj
1951 - T. Popoviciu fondează Secția de matematică a filialei Academiei Române
1959 - MARICA - calculator cu relee1960 - România ocupă locul 11 în lume
la dotarea cu calculatoare, Clujul locul 3 în țară
1963 - DACCIC-1 – calculator cu tuburi electronice și tranzistori
1965 - se înființează catedra de Automatică din cadrul Institutului Politehnic (actuala UTCN) în parteneriat cu Institutul de Fizică Atomică din Cluj (devenit ITIM în 1977 și INCDTIM în 1999), sub conducerea lui Marius Hăngănuț
1965 - se înființează departamentul de Ştiința Calculatoarelor (la UTCN) sub con-ducerea lui Ioan Dancea
1971 - se înființează primul liceu de informatică din Cluj, Liceul de Informatică Tiberiu Popoviciu
1975 - UBB Cluj înființează Centrul de Calcul
1994 - UBB redenumește Facultatea de Matematică cu Facultatea de Matematică și Informatică
7400 absolvențiiîn domeniul ITC din 1970 până azi. Ei sunt produsul instituțiilor de mai sus și alcătu-iesc o mare parte din generația actuală de profesioniști ITC. Au fost formați în peri-oada 1970-prezent și reprezintă:
6 0 , 2 0 0 , 4 0 0 - s u m a m e d i i -lor de abs olvenț i p er p er io adele 1970..1990..2000..2012
86% - din cei 8600 de angajați în ITC la Cluj in peste:
50+ - companii cu mai mult de 50 angajați
2,75% - din 310K locuitori ai Clujului fiind angajați în ITC
196+ / 17+ comunitateaa organizat cumulat cca. 200 de evenimente, de la întâlniri la bere, până la evenimente de talie europeană, prin intermediul celor 17+ comunități active de profesioniști. Acestea s-au înființat în anii:
2006 - GeekMeet Cluj2008 - Transylvania Java User Group2010 - Cluj.rb, The Cluj Napoca Agile
Software Meetup Group, Cluj Semantic WEB Meetup
2011 - Romanian Testing Community, Romanian Association for Better Software, Google Developer Group Cluj-Napoca
2012. Today Software Magazine, Tabăra de testare
27 / 100M+ breaslaeste o manifestare naturală de cluster în care 27 dintre companiile ITC din Cluj, având o cifră de afaceri cumulată de peste 100 milioane de euro se organizează în Clusterul IT. Planurile de viitor includ:
300M - Euro investiții pe următorii 15 ani
20K - specialiști IT în Cluj Innovation City
Am ales pentru acest articol o serie de numere: 1957, 7400, 196/17, 27/100000000. Ele descriu traseul de la înființarea primei instituții ITC până la autoorganizarea comunității actuale într-o breaslă. Pe scurt contextul istoric, evoluția și situația actuală.
TODAY SOFTWARE MAGAZINE
14 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: http://www.transylvania-jug.org/Data înfiinţării: 15.05.2008 / Nr. Membri: 539 / Nr. Evenimente: 42
Comunitatea TSMComunitate construită în jurul revistei Today Software Magazine.Website: www.facebook.com/todaysoftmagData înfiinţării: 06.02.2012 / Nr. Membri: 652 / Nr. Evenimente: 9
Romanian Testing CommunityComunitate dedicata testerilor.Website: http://www.romaniatesting.roData înfiinţării: 10.05.2011 / Nr. Membri: 607 / Nr. Evenimente: 2
GeekMeet ClujComunitate dedicată tehnologiilor web.Website: http://geekmeet.ro/Data înfiinţării: 10.06.2006 / Nr. Membri: 547 / Nr. Evenimente: 17
Cluj.rbComunitate dedicată tehnologiilor Ruby.Website: http://www.meetup.com/cluj-rb/Data înfiinţării: 25.08.2010 / Nr. Membri: 134 / Nr. Evenimente: 34
The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: http://www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 324 / Nr. Evenimente: 29
Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: http://www.meetup.com/Cluj-Semantic-WEB/Data înfiinţării: 08.05.2010 / Nr. Membri: 140/ Nr. Evenimente: 22
Romanian Association for Better SoftwareComunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.Website: http://www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 223/ Nr. Evenimente: 12
Luna mai a fost plină de eveniment majore, ne pare rău că nu am ajuns la toate dar vă promitem să revenim cu o serie de interviuri și impresii de la acestea în numerele următoare.
Calendar Iunie 6Lansarea numărului 12 TSMwww.todaysoftmag.ro
Iunie 7Project Managers Meetupwww.facebook.com/events/519200844808524
Iunie 12Linked Data Technology Stackwww.meetup.com/Cluj-Semantic-WEB
Iunie 12Functional Programming Retreatit-events.ro/events/functional-programming-retreat
Iunie 14Proiectarea si dezvoltarea unui e-businessit-events.ro/events/proiectarea-si-dezvoltarea-unui-e-busi-ness
Iunie 18Business Analysis Community Group Meetingit-events.ro/events/business-analysis-community-group-meeting/
Iunie 19-20ITC Spring Europe, Luxemburg (recomandarea TSM)www.ictspring.com
Mai mult, există un trend ce definește mobilele prin prisma modului în care sunt conectate afacerile, indiferent de categorie. Informaţii bancare (număr de cont, card de credit, informaţii de autentificare, token-uri de securitate) sunt stocate pe dispozitivele mobile sau sunt trimise prin intermediul reţelelor wireless nesecurizate – așadar există un risc mai mare decât pentru apli-caţiile de desktop.
Este așadar esenţial ca atunci când sunt dezvoltate aplicaţii mobile să se ţină cont de securitate, din cauza multitudinii de atacuri ce pot produce prejudicii semnificative.
Arhitectura AppleApple a reușit să găsească, până acum,
cel mai bun echilibru între uzabilitate și securitate prin arhitectura sa ce este strâns legată de hardware și software. Acest lucru face ca în același timp să fie ușor pentru clienţi să cripteze date pe dispozitivele pro-prii și pentru hackeri să fie greu să fure și să decripteze informaţii confidenţiale.
Piatra de temelie a securităţii Apple este algoritmul Advanced Encryption Standard (sau AES), un sistem de codare a datelor considerat de „ne-spart”. Implementarea acestuia pe dispozitivele Apple se face prin intermediul unei chei de criptare stocată adânc în memoria flash, ea însăși criptată prin intermediul unei parole de utilizator. Setarea unei „ștergeri de date” după 12 încercări eșuate de introducere a parolei
face dispozitivul aproape impenetrabil.
Sandbox-ul AplicaţiiloriOS „îngrădește” fiecare aplicaţie în
propriul sandbox la momentul instalării, fapt ce limitează accesul la fișiere, resurse de reţea, hardware și date private. Calea către directorul home al aplicaţiei are forma ../ApplicationRoot/ApplicationID
Chiar dacă sandbox-ul limitează pagu-bele pe care un potenţial atac le-ar putea produce, iOS-ul nu îl poate preveni. Aceasta înseamnă că un hacker poate să acceseze informaţii confidenţiale din cadrul sandbox-ului, lăsând dezvoltatorului doar opţiunea de a lua contramăsuri supli-mentare de securitate.
Dezvoltarea de aplicaţii iOS ţinând cont de securitate
Securitatea a devenit din ce în ce mai importantă în dezvoltarea aplicaţiilor mobile datorită informaţiilor sensibile/confidenţiale de pe telefoanele noastre inteligente. Toate așteptările și estimările privind utilizarea sunt depășite an după an de poto-
pul de utilizatori ai telefoanelor inteligente, în dezavantajul celor care folosesc laptopuri sau desktopuri. Şi cine poate să îi acuze? Dispozitivul ce poate fi ţinut în mână a devenit „portmoneul” erei moderne, plin cu date personale (poze, filme, note) și date confiden-ţiale (de sănătate, medicale, jurnale, permise sau cupoane).
Criptează datele cât timp dispozitivul este blocat
Cât timp dispozitivul este blocat, anu-mite fișiere marcate de către dezvoltator pot să fie criptate în mod automat, însă acest lucru presupune permiterea capacităţilor de criptare și configurarea lor. În stadiul blocat, sandbox-ul aplicaţiei împiedică accesul altor aplicaţii; mai mult, chiar și aplicaţia propriu-zisă nu are acces.
Criptarea se realizează prin seta-rea nivelului dorit de protecţie: fără protecţie, complet, complet cu excepţia faptului când e deja lansată și complet până la prima logare. API-uri ce oferă Protecţ ia Datelor sunt NSData ce folosesc writeToFile:options:error; NSFileManager pentru setarea atri-butelor fișierelor cu setAttributes:ofItemAtPath:error; schimbarea valorii NSFileProtectionKey și opţiunea sqlite3_open_v2 pentru sqlite3.
După setarea protecţiei fișierului, apli-caţia trebuie să implementeze niște delegaţi pentru a fi pregătită pentru pierderea tem-porară a accesului la acel fișier.
Protecţia datelor cu Keychain Access„Keychain Services” este o interfaţă
programabilă ce vă permite să găsiţi, adă-ugaţi, modificaţi și să ștergeţi item-uri din keychain. Keychain este singurul loc în care puteţi stoca date în siguranţă, deoarece sunt criptate în propriul lor set de item-uri ai aplicaţiei. Acestor item-uri\ le este creată o copie de siguranţă atunci când utilizatorul își sincronizează dispozitivele prin intermediul iTunes și vor fi păstraţi și în cazul unei reinstalări. Toate acestea fac din keychain principalul loc de depozitare a datelor confidenţiale, cum ar fi parole, chei
de licenţă, numere de cont, etc. .Pentru a folosi „Keychain Services”,
binarul aplicaţiei trebuie să fie legat cu arhitectura Security.framework. Spre deo-sebire de alte arhitecturi iOS, aceasta este o arhitectură C așa că toate tipurile de apeluri de metode sunt în acel limbaj.
În același mod în care criptarea datelor cât timp dispozitivul este blocat are nive-luri de protecţie, la fel și protecţia datelor din keychain: întotdeauna protejat, prote-jat AfterFirstUnlock sau WhenUnlocked. De asemenea, fiecare clasă există în vari-aţii migrabile și non-migrabile – sufixul ThisDeviceOnly ce leagă criptarea de un dispozitiv anume.
Cea mai bună abordare în folosirea Keychain Access este să declaraţi un dicţi-onar de căutări de bază folosit pentru toate apelurile către serviciile keychain. Acesta va conţine atribute ale itemului keychain de creat, găsit, actualizat sau șters.
Cache-ul tastaturiiAţi observat vreodată că atunci când
folosiţi browsere, auto-complete-ul își intră în rol atunci când încercaţi să retastaţi ceva? Aţi observat că la fel se întâmplă și cu iPhone-urile? Dacă nu încă, ar trebui să știţi că toate tastările de pe un iPhone ar putea fi salvate în cache dacă nu se iau măsuri pentru dezactivare. Acest lucru este valabil pentru tot ceea ce tastaţi, cu excep-ţia câmpurilor de parolă.
Vestea proastă este că aproape orice cuvând non-numeric este salvat în cache și conţinutul cache al tastaturii depășește pri-vilegiile administrative ale aplicaţiei, adică nu pot fi îndepărtate din aplicaţie.
Acest lucru lasă dezvoltatorului o sin-gură opţiune, și anume să dezactiveze
caracteristicile de auto-corectură setând proprietatea de autocorrectionType la UITextAutocorrectionNo.
Capturi de ecran automatePentru a oferi o experienţă bogată
utilizatorului, iOS are multe efecte de micșorare, împingere, apariţie sau dispari-ţie. Totuși, acestea au și o latură negativă: atunci când aplicaţia este mutată în fundal, iOS face o captură automată de ecran a ferestrei iPhone-ului în timp ce efectuează efectul de micșorare și dispariţie. Toate aceste capturi de ecran sunt stocate în par-tea de sistem NANS flash a dispozitivului și sunt teoretic șterse după ce aplicaţia a fost închisă.
În cele mai multe cazuri, ștergerea nu îndepărtează fișierele permanent de pe dis-pozitiv. Acestea pot conţine date privind utilizatorul și aplicaţia. Ca o posibilă solu-ţie pentru această problemă, este nevoie de blocarea cache-ului capturilor de ecran ale aplicaţiei folosind un cod sau o configuraţie API. Un mod ușor de a face acest lucru este folosirea metodei API willEnterBackgro-und, în care se poate implementa ștergerea informaţiilor confidenţiale. Apoi puteţi crea un ecran animat pe care aplicaţia să îl afișeze în timp ce se mută în fundal.
Punerea în cache a datelor aplicaţieiDatele aplicaţiei pot fi capturate într-o
varietate de artefacte, cum ar fi fișiere de log/debug, cookies, fișiere listă de proprietăţi sau baze de date SQLite. În timp ce fișierele listă de proprietăţi, bazele de date SQLite și fișierele/documentele comune pot fi crip-tate oferind astfel un nivel de siguranţă, fișierele de log, debug sau crash sunt poten-ţial accesibile.
programareDezvoltarea de aplicaţii iOS ţinând cont de securitate
17www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINE
Dacă aplicaţia se blochează, rezultatul este logat, lăsând atacatorului o potenţială soluţie pentru a sustrage date confidenţiale. Luaţi de asemenea în considerare dezac-tivarea NSAssert pentru iOS pentru că aplicaţia se va bloca imediat după o avarie; un mod elegant de rezolvare a problemei este interceptarea și prelucrarea acestor erori.
Ar trebui de asemenea să dezactivaţi logurile înainte de a publica aplicaţia; acestea pot să stocheze date confidenţi-ale. Dezactivarea acestora pot să prevină scurgerea de informaţii confidenţiale și de asemenea se poate vedea o mică creștere în performanţă.
PasteBoardsClasa UIPasteboard permite unei
aplicaţii să împărtășească date în cadrul aplicaţiei sau cu altă aplicaţie folosind pas-teboards la nivel de sistem sau specifice pentru aplicaţie. Sună cunoscut? Uitaţi-vă
la imaginea de mai jos. Sunt sigur că aţi văzut asta în multe
aplicaţii iOS. Atunci când utilizatorul cere o operaţiune de copiere sau tăiere pe o bucată selectată din interfaţa utilizatorului, un obiect scrie datele pe un pasteboard. Dacă nu este setat un nivel adecvat de securitate, alte aplicaţii pot avea acces la datele salvate anterior creând astfel riscuri mari de secu-ritate. De asemenea, persistenţa acelor date trebuie controlată, deoarece, dacă atributele nu sunt setate în mod corect, informaţia copiată va fi stocată necriptată în sistemul de fișiere al telefonului și va fi menţinută chiar și după închiderea aplicaţiei.
Ca o ultimă remarcă, să ţineţi minte că practicile de securitate doar îngreu-nează viaţa hackerilor. Nu se poate să vă asiguraţi în proporţie de 100% că măsurile dumneavoastră nu vor putea fi ocolite. La urma urmei, toate versiunile de iOS au fost sparte/decodate. Deși devine din ce în ce mai greu pentru hackeri, ar trebui să vă pre-gătiţi pentru situaţii neprevăzute. La urma urmei, trebuie să găsiţi proporţia adecvată între uzabilitate și practici de intimidare ce vi se potrivesc cel mai bine dumneavoastră,
clientului și utilizatorilor dumneavoastră.Mulţumiri speciale lui Mircea Botez și
lui Andrei Adiaconitei.
Bibliografie1. Apple iOS Developer Library2. “Top 10 iPhone Security Tips” de Kunjan Shah3. “Penetration Testing for iPhone / iPad Applications” de Kunjan Shah4. “iOS Keychain Weakness FAQ” de Jens Heider, Rachid El Khayari5. “Lost iPhone? Lost passwords!” de Jens Heider, Matthias Boll6. https://www.viaforensics.com7. http://www.useyourloaf.com8. http://www.technologyreview.com
18 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
Într-adevăr, a fost o conferință jQuery care a avut loc într-un veritabil palat, pala-tul Liechtenstein (sau Gartenpalais pentru localnici) din Viena ca să fiu mai exact, și ce eveniment excepțional a fost… Pe aceasta cale țin să mulțumesc organizatorilor, Gentics Software, și în special domnului Haymo Meran (CTO-ul Gentics și o foarte prietenoasă gazdă) pentru că au făcut posi-bil acest eveniment și s-au descurcat destul de bine în “voiajul inaugural”. Probabil singurul “minus” (amuzant) care merită menționat e afirmația că participanții care ajung la stația de metrou „Rossauer Lände” vor fi ghidați către locația evenimentului de către o persoană purtând un tricou perso-nalizat pentru conferință. De ce ar fi asta amuzant, mă întrebaţi? Aceasta este Viena în prima zi a conferinței:
Nu tocmai cea mai potrivită vreme
de umblat în tricou și dus lumea la conferințe… Dar destul cu deraiatu, să tre-cem la detaliile picante propriu-zise!
Conferința s-a întins pe durata a două zile, din 22 până în 23 februarie, și a fost plină ochi de Javascript, jQuery, CSS și alte bunătăți livrate de cei 16 vorbitori, presă-rate ici și colo cu părticele mai ciudate cum ar fi banane care cântă și coctail-uri tropi-cale. Evenimentul a început cu o bombă! Stați calmi, nu a fost nici un fel de atentat, securitatea a fost foarte strictă, cu câteva sosii ale lui James Bond mereu cu ochii pe mulțime după cum puteți vedea mai jos…
Nu, bomba la care mă refer descrie impactul primei sesiuni, al cărei vorbitor a fost nimeni altul decât Richard D. Worth, directorul executiv al fundației jQuery. Dl. Worth a prezentat starea curentă a jQuery,
JQuery Europe 2013
Un web developer, Haymo Meran și fantoma prințului Johann Adam Andreas von Liechtenstein intră într-un palat… Sună ca începutul unei glume ciudate, dar vă garantez că nimeni n-o să știe ce se întâmplă mai departe. Mai bine zis,
nimeni care nu a auzit de sau nu a participat la jQuery Europe 2013. Ca să fiu sincer, n-am văzut nici un semn că duhul prințului ni s-ar fi alăturat, și am fost 300 de developeri (sau mai bine zis, entuziaști jQuery), nu unul. Restul totuși e chiar foarte adevărat și cu siguranță nu o glumă, pe cât de fabulos sună.
acum la versiunea (stabilă) 1.9.1, și a oferit o mică viziune asupra viitorului, invitând participanții să se alăture comunității jQuery. Participanții au fost apoi “incitați” cu bucățele de informație despre următo-rul mare pas pentru jQuery, versiunea 2.0, dintre care de departe cel mai ovaționat (aclamat și aplaudat furtunos) a fost anunțul că, începând cu versiunea 2.0, jQuery nu va mai suporta Internet Explorer 8 (sau ver-siuni mai vechi). Ştiu, știu, jos pălăria în fața lor pentru că au închis ușa și-au încu-iat-o bine și l-au lăsat în stradă pe țâncul cel enervant care mereu face lucrurile altfel decât restul… Totuși, nefiind oameni cruzi și fără milă pentru bietele suflete care au nevoie ca site-ul lor să nu crape oribil pe IE, echipa jQuery va menține versiunea 1.9.1 în paralel cu 2.0, duplicând în 1.9.1 tot ce se va dezvolta în 2.0 și mai departe, atâta timp cât nu necesită cantități industriale de adaptare. Dl. Worth a trecut de asemenea în revistă modificările recente în compo-nente adiacente jQuery cum ar fi jQueryUI sau jQuery Mobile și a adus la lumină câteva inițiative jQuery, precum contribute.jquery.org (pentru cei interesați în a con-tribui la jQuery), plugins.jquery.com (noul și îmbunătățitul registru de plugin-uri) sau learn.jquery.com (dacă URL-ul nu v-a dat un indiciu, aceasta e o inițiativă îndreptată către persoanele care vor să învețe jQuery).
Considerând că a intra în toate detaliile a ceea ce a urmat ar însemna transforma-rea acestui articol într-o lectură destul de grea, voi face un rezumat (și probabil o să dau greș, într-un final slobozind zăgazu-rile mentale și dând drumul șuvoiului de gânduri) al restului unei zile cu adevărat fascinante. Următorul pe listă a fost Corey Frang, de asemenea un membru al echipei
jQuery, care a disecat un widget jQuery UI în componentele lui de bază și a demon-strat cum folosirea “widget factory”-ului poate genera rezultate foarte flexibile și extensibile. Doug Neiner a prezentat cateva practici bune în ceea ce privește separarea codului Javascript/jQuery de CSS și HTML, lucru care ne va aduce mult mai multă men-tenabilitate și mai puține dureri de cap. A facut de asemenea și o incursiune în lumea tranzițiilor și animațiilor CSS și a echiva-lentului lor în jQuery. Sebastian Kurfürst a arătat cum, folosind RequireJS, ne putem organiza codul Javascript în componente și să îmbunătățim claritatea în codul de client. Jörn Zaeffer ne-a deschis urechile și mințile către modul în care web-ul e perceput de cei care nu pot experimenta lumea prin intermediul văzului, o categorie semnificativă de oameni de care din neferi-cire uităm deseori. Trebuie să recunosc că mi-a dat un sentiment de umilință, tristețe chiar, să aflu cum “sună” unele pagini web. N-am fost pus încă într-o situație în care a trebuit să mă gândesc la accesibilitate și e greu să ai aspectul acesta în minte când ești în frenezia alinierii de pixeli și a ajustării tonurilor de culoare, dar e ceva ce ar trebui luat mereu în considerare. Am văzut apoi de ce e în stare jQuery pe server într-o pre-zentare foarte pătrunzătoare de către Golo Roden a Node.js, o unealtă excepțional de puternică pentru oricine e interesat de lucruri precum “web scraping”, crearea de web servere “ușoare” sau aplicații distri-buite cu trafic intens de date. Următorul vorbitor în acțiune, Sascha Wolter, e pro-babil persoana cea mai asemănătoare cu un geniu nebun pe care am văzut-o până acum, dar în modul cel mai bun. A făcut lucruri cu Javascript la care nu m-aș gândi
nici în cele mai creative zile. De la controlat roboți LEGO sau “quad copters” și trimis SMS-uri la aparate de făcut cafea până la a chiar face banane să cânte, am savurat fiecare fascinantă secundă (să nu mai vor-bim că am copt câteva idei nebune proprii de încercat). Ziua s-a încheiat cu prezen-tarea ținută de Christian Heilmann, care a lansat o întrebare foarte interesantă: oare uneltele (librării Javascript, framework-uri, plugin-uri, etc.) pe care le folosim ne ajută sau ne fac rău? E bine să folosim unelte ca să facem procesul de dezvoltare mai rapid sau să dăm mai multă claritate codului, dar e esențial să înțelegem ce e de fapt în spatele acestor unelte, ce le face să funcționeze, ce le face atâta de bune și ce le-ar putea face și mai bune. Îmi aduc aminte de câteva cifre menționate de dl. Worth în prezentarea de deschidere: 55.7% din site-urile existente în momentul de față pe vastele câmpii ale internetului folosesc jQuery. Aceasta înseamnă 90.7% din toate site-urile care folosesc Javascript. O majo-ritate copleșitoare fără îndoială, dar stau să mă întreb oare câți developeri care au folo-sit jQuery în acele site-uri au chiar luat o versiune ne-minificată a js-ului de jQuery și au tras cu ochiul înăuntru să vadă ce soi de magiee în spatele framework-ului care le face viața așa de ușoară...
Şi-așa am ajuns la a doua (și din păcate ultima) zi de jQuery Europe 2013. Ziua a început cu o prezentare grozavă pe tema “jQuery Mobile și Responsive Web Design” de Todd Parker, design lead al jQuery UI și membru al echipei jQuery Mobile.Dl. Parker a descris capabilitățile de RWD (Responsive Web Design) incluse în framework-ul jQuery Mobile și a arătat câteva exemple reale de utilizare a media
TODAY SOFTWARE MAGAZINE
20 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
query-urilor și a gândirii “mobile-first” în construirea conținutului responsiv, fie el pentru site-uri sau app-uri. De aseme-nea au fost evidențiate câteva tehnici de îmbunătățire a performanței în ceea ce privește minimizarea utilizării lățimii de bandă, utilizarea imaginilor cu rezoluții mari și stratificarea selectivă a conținutului în funcție de capabilitățile dispozitivului. Maximilian Knor, un “developer evangelist” la Microsoft, a demonstrat cum ASP.NET MVC și ASP.NET SignalR (http://www.asp.net/signalr încercați-l daca n-ați făcut-o deja) construiesc peste jQuery și jQuery Mobile pentru funcționalități client-side și aplicații de o singură pagină. Mike West a evidențiat esențialul securizării codului de client împotriva intențiilor malițioase, fie ele “cross-site scripting” sau alte forme de atac. Mai bine zis, a diminuării efec-telor unui asemenea atac ca sa fiu sincer, pentru că deși am crede că am scris codul
în așa fel încât e imposibil ca altcineva să îl spargă, lucruri precum JSFuck(http://www.jsfuck.com/) s-ar putea sa ne facă să ne întoarcem la codul nostru și să mai adăugăm câteva straturi pe “zidul de cără-midă” și chiar și atunci să ne dăm seama că nu e destul de solid. Reținem prezen-tarea lui Patrick Lauke și “Web on TV”, o descriere a modului în care jQuery poate fi folosit pentru a interacționa cu televizorul dumneavoastră. În ziua de azi, orice com-panie respectabilă care produce televizoare probabil are cel puțin un reprezentant al generației SmartTV și în câțiva ani proba-bil cu greu ne vom aduce aminte de vremea când nu puteai să navighezi pe internet pe televizorul tău sau să te uiți la YouTube sau să joci Angry Birds. Ce înseamnă asta, pe lângă un set nou de bătăi de cap în ceea ce privește suport inclus în site-uri sau app-uri pentru multiple dispozitive, e că folosind puțină cunoștință de Javascript/jQuery am putea crea interfețe sau app-uri de care oamenii să se bucure (și) pe televi-zoarele lor (îmi vine în minte o mică glumă despre a pune “peretele” de Facebook al unei persoane pe chiar peretele persoanei respective). Ultima prezentare la care am putut să particip a fost un fel de iluminare dublă, grație lui Dyo Synodinos. Primul pas al iluminării a fost în legătură cu picturile de pe tavanul măreței și magistral decoratei săli în care ne aflam, care surprind scene din viața lui Hercule (nu cel jucat de Kevin Sorbo). Al doilea pas a avut loc în momen-tul în care mi-am dat seama că primul avea chiar multă legătură cu prezentarea despre “ultimul răcnet” în materie de vizualizări ce urma și nu era nici pe departe umplu-tură de introducere. Într-adevăr, ceea ce a
fost prezentat a fost foarte impresionant din punct de vedere vizual și fără îndoială de ultimă oră. Toate uneltele moderne de “încântat ochiul”, cum ar fi CSS3, SVG, Canvas sau WebGL și-au primit o porție sănătoasă de atenție iar framework-uri pre-cum Raphael.js, D3.js sau Fabric.js, care aduc puterea acestor tehnologii într-un format mai accesibil ne-au delectat și ele cu etalări creative și uimitoare privirea.
Şi apoi a trebuit să plec... Şi deși am avut o mică doză de regret pentru că am ratat o părticică, am fost extrem de satisfăcut de ce am putut experimenta pe parcursul celor două zile... Şi am plecat chicotind puțin la gândul că mă voi întoarce pentru conferința de anul viitor, care garantat va avea loc, după spusele lui Haymo.
Cine știe ce va aduce 2014?
JQuery Europe 2013
conferință
21www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINE HR
În cadrul fiecărui departament este indi-cat să existe un nivel general al perfomanței stabilit pe baza rezultatelor obținute în anii anteriori. De asemenea este indicat ca în fiecare lună să se întocmească rapoarte pentru definirea nivelului de perfomanță în cadrul echipelor. Perfomanțele indivi-duale se evaluează la mijlocul perioadei de evaluare în principiu la mijlocul anu-lui și la finalul perioadei de evaluare la finalul lunii decembrie. Rezultatele sunt utilizate ulterior pentru întocmirea planu-rilor de dezvoltare personală, care cuprind obiectivele de dezvoltare, activitățile care contribuie la îndeplinirea obiectivelor și competența îmbunătățită.
Activitățile de dezvoltare sunt dintre cele mai diverse: de la programe de pregă-tire pentru angajați, la training la locul de muncă, materiale electronice.
Scara de notare a performanței Realizările sunt evaluate pe o scară
a performanței cu 6 niveluri, așa cum se poate observa în tabelul 1.2. Evaluarea se face cu ajutorul a două dimensiuni: rezul-tatele obținute (CE?) și aplicabilitatea valorilor companiei (CUM?).
Definirea obiectivelor Obiectivele profesionale pe termen lung
și termen scurt să fie integrate în prima fază a procesului (Definirea așteptărilor) având feedback constant din partea managerului.
Criterii pentru definirea obiectivelor:• Obiectivele individuale vor f i
în corelație cu obiectivele echipei. Minimum un obiectiv al echipei și mini-mum trei obiective individuale.
• Obiectivele trebuie să fie SMART, iar indicatorii de performanță vor fi definiți pentru fiecare obiectiv și valoare a organizației în parte. • Managerul este responsabil pen-
tru alinierea obiectivelor cu cele organizaționale.
Indicatorii de perfomanță Este necesar a fi definiți indicatori de
perfomanță pe fiecare arie. Aceștia sunt folosiți pentru definirea obiectivelor de echipă. Formularea obiectivelor trebuie să fie un proces orientat spre clienți și pe fac-torii interesați și trebuie să ia în considerare trei aspecte esențiale: rezultatele, cerințele de calitate și indicatorii de performanță.
Pentru o mai bună înțelegere a aces-tui model, în continuare vor fi explicate toate cele 3 aspecte și rolul lor în definirea
obiectivelor. 1. Rezultatele: sunt produse finite,
servicii, informații care sunt ofe-rite clienților. Rolul lor este de a îndeplini așteptările și cerințele acestora. Rezultatele eficiente trebuie să:
• se refere la obiectivele cheie ale afacerii și/sau prioritățile funcționale cheie,• fie formulate din perspectiva
clientului, • fie formulate ca stare finală, • includă obiective manageriale și
de leadership, • includă auto-dezvoltarea, indife-
rent de rol. 2. Cerințele de calitate: descriu rezul-
tatul oferit ca și când acesta ar fi excelent din perspectiva clientului și trebuie să
Managementul performanței (II)
A doua parte a articolului dedicat managementului performanței va prezenta mijloacele utilizate în acest proces, precum și câteva modele care pot fi ușor implementate în orice companie.În cele ce urmează va fi definit un model de definire al obiec-tivelor în cele trei faze ale procesului de management al performanței, care cuprinde:
(1) definirea comportamentelor necesare pentru trăirea celor cinci valori ale companiei, (2) obiectivele echipei: descrierea acestora, modalitatea de măsurare a obiectivelor și rezultatele așteptate și (3) obiectivele individuale, care trebuie să fie aliniate cu obiectivele echipei.
Figura 1 de definire a obiectivelor în interiorul companiei
22 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
conțină caracteristici ale valorii adău-gate pentru a descrie CE-ul și CUM-ul performanței.
3. Indicatorii: au rolul de a spune dacă și cum fiecare echipă/individ a perfor-mat față de obiectivul stabilit, cu privire la CE-ul și CUM-ul performanței. Mai mult decât atît indicatorii trebuie să fie agreați anterior stabilirii obiectivelor.
Competențe de leadership și manage-ment
Pentru un proces sustenabil de mana-gementul performanței, este recomandabilă crearea unui catalog al competențelor și abilităților tehnice pe care fiecare anga-jat trebuie să le aibă pentru a îndeplini responsabilitățile postului.
Competențele de leadership pe care le sugerez a fi folosite sunt cele enumerate mai jos. Se va păstra și denumirea în limba engleză pentru a nu schimba semnificația cuvintelor.
• Orientarea către oameni (People leadership) care pune accentul pe capa-citatea individului de a comunica, de a-i coordona pe ceilalți și de a lucra la rân-dul său într-o echipă. • Leadership personal (Personal lea-
dership) capacitatea de a se adapta la situații și medii noi și nu în ultimul rând inteligența emoțională. • Orientarea spre rezultate (Results
Leadership) exemplifică capacitatea angajatului de a-și îndeplini obiectivele și sarcinile, precum și capacitatea aces-tuia de a lua o decizie responsabilă în timp util. • L eadership analitic (Thought
Leadership) capacitatea de a înțelege mediul de business și organizația în care
activează și poate indentifica în același timp viitoare tentințe ale mediul extern și intern.
Pe lângă aceste competențe de lea-dership, persoanele care au poziții de management au un profil pe care trebuie să îl îndeplinească.
Campionii managementului performanței
Companiile oferă angajaților posibilita-tea de a beneficia de ajutorul campionilor managementului performanței, care sunt grupați în două categorii: (1) cei care au cunoștințe despre managementul performanței care pot oferi suport celor care sunt implicați în acest proces și (2) per-soanele cu performanțe ridicate care sunt promovate în cadrul companiei în cadrul diferitelor evenimente de recunoaștere a meritelor. Rolul acestora este de a:• identifica, selecta și motiva un grup
de agenți ai schimbării care să con-tribuie la implementarea procesului în interiorul companiei;
• educarea echipelor și a indivizilor pentru a-i familiariza cu aplicațiile strategice ale managementului perfomanței;
Modelul FLAME poate fi aplicat în
orice companie. Pentru o viziune mai clară asupra rolului campionilor manage-mentului performanței, se vor exemplifica situații caracteristice acestui model, unde F – facilitarea, L – leaderi prin exemplu, A – acționează ca o consecință, M – măsoară, E – educă.
Cheia reușitei este de a educa și de a le insufla celorlalți membri ai echipei
o cultură a performanței, iar aceștia să devină acei agenți ai schimbării în interi-orul companiei.
Problema care este adesea adusă în discuție se referă la procesul de identificare și de alegere a campionilor managementu-lui performanței. Principalele caracteristici pe care aceștia trebuie să le aibă sunt:
• înțelegerea procesului de mana-gement al performanței și impactul acestuia în companie;• competență în diverse aspecte (capa-
citate de înțelegere a sistemului de notare a performanței, capacitate de a organiza întâlniri, capacitate de influențare);• buni performeri;• buni comunicatori și facilitatori.
P r o c e s u l d e m a n a g e m e n t a l p er for manțe i are t re i cons e c ințe semnificative:
1. Recompensarea angajaților,2. Managementul talentului, adică dez-
voltarea carierei tuturor angajaților,3. Planul individual de dezvoltare, pe
care angajații, împreună cu superiorul direct ar trebui să îl realizeze.
Succes în implementarea unui sistem de managementul performanței care să aducă cele mai bune rezultate atât pentru angajați cât și pentru companie.
(cel puțin una dintre subsecțiuni trebuie completată)
Descrierea obiectivului Descrierea obiectivului Descrierea obiectivuluiCum se măsoară? Cum se măsoară? Cum se măsoară?
Rezultate RezultateScor ( an anterior ) Scor ( an anterior )Nivelul performanței ( an anterior ) Nivelul performanței ( an anterior)
Valorile companiei Cum se măsoară? Cum se măsoară? Cum se măsoară?Rezultate RezultateNivelul Performanței Nivelul Performanței
Nivelul General al Perfomanței
Scorul nu este disponibil Scorul este opțional Scorul este opțional
Scorul Total al Evaluării ( an anterior )
Scor total
(100% pentru validare )
Scor total Scor total
Plan de Dezvoltare Profesională
(cel puțin un plan trebuie completat)
Obiective de Dezvoltare Obiective de Dezvoltare Obiective de DezvoltareActivități de dezvoltare Activități de dezvoltare Activități de dezvoltare
Competența dezvoltată în urma activității de dezvoltare
Competența dezvoltată în urma activității de dezvoltare
Competența dezvoltată în urma activității de dezvoltareRezultatul planului de dezvoltare
Tabel 1.1. Model formular stabilire obiectivelor
Nivel Denumire nivel
Descrierea nivelului din punct de vedere al rezultatului Descrierea nivelului din punct de vedere al valorilor
5 Excepțional Performanța obținută a fost peste obiectivele definite, prin propriile abilități. Depăsește constant așteptările angajațiilor pe această poziție. Excelează în a îndeplini cerințele clienților în termenul limită stabilit.
Este un model pentru ceilalți în ceea ce privește trăirea comportamentelor caracteristice fiecărei valori.
4 Obiectiv depășit
Perfomanța obținută a fost peste obiectivele definite, cu un minim de supervizare, demonstrând în același timp inițiativă și independență în soluționarea problemelor.
Performanța obținută îndeplinește parțial obiectivele, ne fiind îndeplinite în termenul limită stabilit. Este nevoie de suportul superiorului direct și de îmbunătățirea competențelor și a abilităților.
Unele comportamente demonstrate nu sunt în concordanță cu valorile.
1 Obiectiv neîndeplinit
Performanța obținută este sub obiectivele definite. Este nevoie de suportul constant al superiorului direct pentru îndeplinirea responsabilităților postului.
Majoritatea comportamentelor demonstrate nu sunt în concordanță cu valorile.
0 Nemăsurabil Angajați noi în cadrul companiei (mai puțin de 6 luni).
Numele echipei/ membrului individual ________________________________________Rezultat Cerințe de calitate Indicatori
Tabel 1.3. Modelul de definire al obiectivelor
24 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
programare
Din păcate, validarea completă a pro-dusului de către echipa de testare poate dura săptămâni, dacă nu luni. Şi asta fără a lua în calcul timpul necesar rezolvării bug-urilor găsite de testeri. Nu se poate așadar ca echipa să livreze la timp dacă produsul este complet testat. Ce e de făcut?
Alternativele cele mai comune sunt:• testarea exclusivă a funcționalităților
noi, cu speranța că cele vechi nu s-au modificat;• analiza impactului modificărilor și
testarea exclusivă a funcționalităților afectate;• utilizatorii vor testa într-o perioadă
de stabilizare.
Toate soluțiile de mai sus înseamnă scăderea temporară a grijii acordate pro-dusului, pentru a asigura livrarea cât mai rapidă. Din păcate pentru echipa din sce-nariul descris mai sus, se asumă riscuri care pot avea impact major asupra aface-rii. Riscul major este scăparea din vedere a unor zone din aplicație și livrarea cu bug-uri. Acest risc poate duce la:
• Scăderea mulțumirii utilizatorilor și la apariția detractorilor. În afaceri, la fel ca în viață, e greu să câștigi încrede-rea unei persoane dar e foarte ușor să o pierzi.• C r e ș t e r e a c o s t u r i l o r c u
suportul. Fiecare bug raportat de utili-zator înseamnă timp petrecut pentru înțelegerea lui, rezolvarea, testarea și punerea în producție a noii versiuni. Costurile se acumulează în: call center, dezvoltare, testare, operațional.
• Costul de oportunitate: cât timp echipa de dezvoltare rezolvă bug-uri, competiția poate scoate funcționalități noi care vor atrage utilizatorii. Rezolvarea bug-urilor este echivalentă din punctul de vedere al afacerii cu alergatul pe loc.
Dar dacă...Echipa ar putea valida întreaga aplicație
în ore și nu în săptămâni sau luni? Dacă fiecare programator ar putea afla la fiecare mică modificare în cod, în câteva minute, că nu a stricat nimic (cu o probabilitate de 80+%)
A r t i c o l u l d e s p r e S o f t w a r e Craftsmanship, publicat în numărul 11 al Today Software Magazine, menționează ideea principală de la care a pornit mișcarea: un software craftsman poate livra calitate sub presiune. În această situație, un software craftsman ar trebui să livreze funcționalități noi în timpul alocat cu cât mai puține bug-uri. Cât de puține? Mai puțin de 10 per release.
Acest număr este conservator, pentru că metodele agile (inclusiv Scrum) au cerut de la început ca la finalul fiecărui sprint de 2-3 săptămâni, echipa să livreze software cu 0 bug-uri cunoscute, după ce aplicația a fost validată de testeri.
Dar orice aplicație are bug-uri!Denumirea de bug este un eufemism
pentru greșeală. Greșelile sunt normale în orice activitate umană, chiar și atunci când dezvoltăm software.
Întrebarea este cum poate fi redus numărul de greșeli și impactul lor. Unit
Imaginați-vă următoarea situație: o echipă a dezvoltat timp de 6 luni un produs gro-zav, care se vinde imediat. Utilizatorii își arată pasiunea pentru produs cerând mereu funcționalități noi. Dacă echipa nu livrează noile funcționalități destul de repede,
fericirea lor va scădea, poate chiar vor decide să migreze la concurență. Echipa trebuie să livreze rapid.
Programmer. Organizational and Technical Trainer and Coach@Mozaic Works
25www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINE
testing este o unealtă care poate ajuta, dar nu este singura. Alte unelte care pot ajuta sunt: code review, pair programming, redu-cerea numărului de linii de cod, design by contract.
Unit testingTestarea unitară se referă la scrierea
unor bucăți de cod, denumite cod de tes-tare, care validează codul de producție. Testarea majorității aplicației devine așadar automată.
Istorie: programatorii cred adesea în mod eronat că unit testing este o prac-tică 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 programu-lui și informații despre execuție. Testele automate care rulau în același timp cu pro-gramul dădeau informații mult mai bogate legate de sursa greșelilor.
Ce facem cu testerii? O temere întâlnită adesea este că testerii își vor pierde locul de muncă o dată cu introducerea testării automate. În realitate, testerii devin mult mai importanți pentru că acum doar ei pot descoperi problemele ascunse, greu sau imposibil de găsit prin teste automate. Ei ajută să crească probabilitatea că totul funcționează corect de la 80+% la aproape 100%.
Testele unitare au câteva caracteristici importante:
• fiecare test validează un comporta-ment din aplicație;• rulează foarte repede, maxim în
câteva minute;• sunt foarte scurte și ușor de citit;• rulează la apăsarea unui buton, fără
configurări suplimentare.
Pentru a fi rapide, testele unitare folo-sesc adesea așa-numitele „duble de testare”. La fel cum piloții de avioane învață într-un simulator înainte de a se urca în avion, testele unitare folosesc bucăți de cod care seamănă cu codul de producție, dar în realitate folosesc doar la teste. Stub-urile și mock-urile sunt cele mai întâlnite duble de testare, existând multe altele mai puțin folosite.
Un stub este o dublă de testare care întoarce valori. Stub-ul este similar cu o simulare foarte simplă: atunci când apeși un buton, apare o valoare. În cod, un stub poate arăta astfel:
class PaymentServiceStub implements Payment-
Service{ public boolean valueToReturnOnPay;
public boolean pay(Money amount){return valueToReturn; }}
class PaymentProcessorTest{
@Testpublic void paymentDoneWhenPaymentServiceAcceptsPayment(){ PaymentServiceStub paymentServiceStub = new PaymentServiceStub();
paymentServiceStub.valueToReturn = true; PaymentProcessor paymentProcessor = new PaymentProcessor(paymentServiceStub); paymentProcessor.processPayment( Money.RON(100));
Un mock este o dublă de testare care validează colaborarea între clase. Mock-ul validează apeluri de metode, cu anumiți parametri, de un anumit număr de ori. Din această cauză, un mock poate fi folosit și la validarea apelurilor de metode care nu întorc valori.
class PaymentServiceMock implements PaymentService{
public boolean payWasCalled; public Money actualAmount;
public void pay(Money amount){actualAmount = amount;payWasCalled = true; }}
Dublele de testare pot fi create și folo-sind framework-uri speciale, cum ar fi mockito pentru Java (a fost portat și pe alte limbaje) sau moq pentru .NET.class PaymentProcessorTest{
PaymentProcessor paymentProcessor = new PaymentProcessor(paymentServiceMock); paymentProcessor.processPayment(amount);
verify(paymentServiceMock).pay(amount);}
}
Inițial dublele de testare erau folosite doar în locurile unde era foarte greu să controlezi sistemul sau unde testele erau încetinite de apeluri la sisteme externe. În timp, dublele de testare au ajuns să fie folo-site în toate testele unitare, dând naștere metodei „mockiste” de testare unitară. Pentru mai multe detalii, articolul „Mocks aren’t stubs” de Martin Fowler1este edificator.
Testele unitare sunt scrise de pro-gramator, în timp ce implementează o funcționalitate.
Din păcate, cel mai întâlnit mod de a scrie teste este cândva după ce a fost ter-minată implementarea. Rezultatul este că testele sunt scrise având în minte cum ar trebui să funcționeze codul și nu testarea lui.
Test First Programming este o metodă de a scrie teste care implică următorii pași:
• crearea unui design pentru imple-mentarea funcţionalităţi• crearea minimului de cod necesar
(compilabil, dacă limbajul folosit este compilat) pe baza design-ului• scrierea unuia sau mai multor
teste care codează ceea ce trebuie să facă design-ul; testele vor pica în acest moment• implementarea codului care face tes-
tele să treacă.
Prin aplicarea Test First Programming, programatorii se asigură că scriu teste unitare și că testează ceea ce ar trebui să rezolve, nu implementarea soluției.
Test Driven Development (TDD) poate fi a treia metodă de a scrie teste. De fapt, TDD este o metodă de a face design incremental. Un articol viitor va trata pe larg ce înseamnă și de ce este util TDD.
Durează mai mult când scriu teste!Studiile de caz2 și experiența personală
a arătat că într-adevăr, timpul petrecut strict pe dezvoltarea unei funcționalități crește o dată cu adoptarea unit testing. Aceleași studii au arătat că timpul petre-cut pe mentenanță scade drastic, arătând ca unit testing poate aduce o îmbunătățire
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
TODAY SOFTWARE MAGAZINE
26 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
netă în timpul de dezvoltare.Acest fapt nu poate schimba percepția
programatorului care trebuie să scrie mai mult cod. De aceea, programatorii presu-pun adesea că per total proiectul merge mai încet din cauza testării automate.
Cum încep?Este bine ca adopția unit testing să se
facă cu grijă, incremental, urmărind câteva puncte importante:
1. Clarificarea conceptelor legate de unit testing înainte de a începe scrierea de teste.Programatorii trebuie să poată „mânui” fără teamă unelte precum: stub-uri, mock-uri, teste de stare, teste de colaborare, teste de contract, dependency injection. De asemenea, programatorii trebuie să înțeleagă ce cazuri merită și trebuie testate.Există câteva modalități prin care programatorii reușesc să stăpâ-nească aceste concepte:
• training specializat pe unit testing. Mozaic Works oferă un asemenea curs (http://bit.ly/unit-testing-workshop) care a avut constant feedback de peste 9.25/10 de la participanți.• pair programming între un tester
și un dezvoltator.• pair programming între un dez-
voltator experimentat în unit testing și unul începător. Dezvoltatorul expe-rimentat poate fi și un coach tehnic extern.• documentarea din cărți (vezi la
final cărţii recomandate), de pe inter-net sau prin participarea la evenimente de comunitate.• participarea la conferințe unde se
discută concepte de unit testing.2. Un coach tehnic poate lucra cu
programatorii, ajutându-i să transfere informațiile teoretice în practica de zi
cu zi astfel încât productivitatea să fie cât mai puțin afectată;
3. Testarea automată în primul rând a celei mai importante părți din aplicație și apoi a funcționalităților cu cel mai mare risc de greșeală;
4. Folosirea strategiei de testare de tip „Piramida testelor”3pentru a elimina cât mai multe greșeli cu putință;
5. În cazul în care există mult cod (legacy code), este recomandată învățarea unor tehnici suplimentare pentru a scrie teste pe cod existent. Mai multe detalii într-un articol viitor.
Greșeli comuneCâteva greșeli comune legate de unit
testing sunt:1. S c r i e r e a m u l t o r t e s t e d e
integrare(care implică mai multe clase sau module) lente și fragile în detrimen-tul testelor unitare mici, rapide și ușor de întreținut
2. Abandonarea dublelor de testare, sau folosirea lor în scopuri pentru care nu au fost create. Dublele de testare ajută la obținerea unor teste scurte și rapide.
3. Numele testelor nu exprimă compor-tamentul testat. Numele testului poate da foarte multe informații atunci când testul pică.
4. Folosirea intensivă a debugger-ului pe teste. Testele bine scrise vor spune ime-diat unde este problema în cazul în care pică. Debugging-ul este în continuare util în situații exotice.
5. Cod de testare neîngrijit. Codul de testare este cel puțin la fel de impor-tant ca și codul de producție, și trebuie întreținut cu aceeași grijă.
Mai multe detalii despre aceste probleme 3 http://martinfowler.com/bliki/TestPyramid.html
puteți afla dintr-un blog post de același autor, „5 common unit testing problems” de la adresa http://mozaicworks.com/blog/5-common-unit-testing-problems/.
ConcluzieUnit testing-ul este una dintre metodele
pe care un programator o poate folosi cu scopul de a reduce numărul de greșeli pe care le face când scrie cod. Folosit corect, unit testing-ul poate reduce semnificativ timpul petrecut cu repararea bug-urilor din aplicații, reducând încărcarea colegilor care se ocupă de suport și testare și permițând introducerea de noi funcționalități mai repede, ceea ce conduce la competitivitate crescută. Dar unit testing-ul trebuie adop-tat cu grijă, urmând practicile din industrie (piramida testelor, folosirea dublelor de testare etc). Ajutorul extern (training și coaching tehnic) poate face diferența între o adopție reușită și una cu probleme.
Un software craftsman stăpânește unit testing și îl folosește atunci când e nevoie să se protejeze de greșeli, fie ale sale fie ale colegilor de echipă. Așa este sigur că poate livra software fără bug-uri chiar și atunci când e sub presiunea timpului. Cu condiția, evident, să învețe unit testing atât de bine încât să îl folosească cu ușurință chiar și atunci când e sub presiune.
Cărți recomandate„The Art of Unit Testing”, Roy Osherove„xUnit Test Patterns”, Gerard Meszaros„Growing Object Oriented Software Guided by Tests”, Steve Freeman, Nat Pryce
programare
27www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINE QA
Astfel de situații au dus în final la apariția conceptului de Testers = second class citizens. Ce înseamnă acest lucru mai exact? Nu se lucrează constructiv împre-ună, unde atât testerul cât și developerul pot beneficia unul de expertiza celuilalt, ci testerul lucrează doar după ce o bună parte din munca developerului e gata (există ceva palpabil pentru testare).
Proiectul nostru...este unul complex, unde lucrează o
echipa de aproximativ 50 persoane. Dacă nu am insista foarte mult pe colaborare și comunicare, nu am reuși să facem față metodologiei Kanban ce o abordăm, ce presupune un număr mare de teste auto-mate, inițiativă și proactivitate din partea tuturor.
Cum am ajuns noi să depășim această situaţie? Prin efort colaborativ și comu-nicare. Testerii nu trebuie să aștepte ca un build să fie gata pentru testare, pentru a-și putea începe munca, ci pot lucra împreună cu developerii încă din momentul în care detaliile unui epic/story sunt clarificate. Împreuna pot stabili scenariile relevante ce trebuie testate, și scrie codul de automation necesar.
Suntem mândri să lucram într-un mediu unde fiecare membru al echipei se
ghidează după principiul Quality is a team effort.
Trebuie să ținem cont de un lucru: această abordare nu ar fi posibilă fără un număr mare de teste automate, care să asi-gure regression testing-ul. În caz contrar, toată această comunicare cu echipa de development ar deveni un overhead pentru testeri (și nu numai), deoarece presupune multe discuții în prealabil, care consumă din timpul necesar scrierii și executării testelor. Poate vă gândiți că o simplă abor-dare Agile-Scrum ar fi suficientă, pentru că detaliile necesare implementării și testării unui feature nou se pot stabili în cadrul unui meeting de stand-up. Dar cred că știți cu toții că aceste meeting-uri pot devia de la formatul lor standard, depășindu-se deseori numărul de 15 minute alocate în mod ideal, și nu se ajunge la un consens în ceea ce privește rolul fiecărui membru al echipei.
Concepte teoretice Behavior Driven Development
Pentru a îmbunătăți și mai mult lucrul în echipa noastră, ne-am îndreptat atenția către Behavior Driven Development1, o metodologie ce se axează pe comunicare și colaborare ca puncte forte. Definiții pentru
1 http://dannorth.net/introducing-bdd/
În ziua de azi, testerii sunt priviți ca fiind cei care execută munca de rutină, de o dificultate mai ușoară, și ale căror skill-uri tehnice nu sunt atât de puternice pe cât cele ale programatorilor. Există echipe fragmentate, două tabere practic: developeri și
testeri. Accentul nu se pune pe comunicare și colaborare, ci se investește efort și energie în acel vechi “battle”, în care fiecare dorește să demonstreze că echipa proprie e mai bună.
BDD sunt multe, dar noi vă prezentăm câteva dintre conceptele BDD așa cum le-am aplicat în cadrul proiectului nostru:
1. C omp ar ativ c u Test Driven Development (unde testele dic-tează arhitectura), Behavior Driven Development reprezintă o extensie. Ca și în TDD, testele reprezintă catalizato-rul metodologiei, dar sunt scrise într-un format ușor de înţeles de către toată lumea. Vorbim aici de limbajul Gherkin (Given-When-Then), care permite și persoanelor non-tehnice din echipă să contribuie la scrierea și menținerea testelor.
2. Comunicarea și Colaborarea repre-zintă fundamentele BDD. Fără aceste două concepte, BDD nu poate fi aplicat cu succes.
3. Diferite perspective asupra sis-temului sunt oferite atunci când se aplică BDD. Şi acest lucru este posibil pentru că BDD ne dă ocazia să punem câteva întrebări cheie echipei de product management:
a. De ce este nevoie de acest feature?b. Care este problema ce o adre-
sează? Care este publicul țintă?c. Care sunt alternativele?d. ...and so on
Răspunzând la întrebări de acest gen, putem să privim produsul din prisma product owner-ului, fiind capabili astfel să înțelegem mai bine business value-ul ce un produs/feature nou îl poate aduce.
4. De asemenea, dacă cele mai de sus se aplică cu succes, o mai bună relaționare cu clienții este un alt avantaj ce rezultă aproape fără efort.
5. L i v i n g d o c u m e n t a t i o n
- Documentația formată din testele scrise în limbajul Gherkin, constituie principa-lul avantaj al acestei metodologii.
Procesul BDD în echipa noastrăPractic, pașii ce îi urmăm noi din
momentul în care apare o idee de feature nou, până când aceasta se materializează sunt următorii:
1. Echipa de management are o idee despre un feature/produs nou, idee trans-pusă în backlog.
• Această idee este transpusă de multe ori direct ca soluție tehnică. Această abordare este greșită și aici este un aspect asupra căruia BDD ne per-mite să lucrăm. Product managementul trebuie să propună ideea, iar toată echipa contribuie la găsirea celei mai eficiente soluții tehnice.2. În mod ideal, product managemen-
tul și business analyst-ul participă la discuțiile preliminare, unde se pun între-bările cheie și se clarifică diverse aspecte.
• În lipsa unui business analyst, noi am descoperit că cel puțin în acest caz, atribuțiile business analyst-ului pot fi preluate de către echipa tehnică: tech leads, developeri, testeri.3. Se discută pe seama ideii, până când
se ajunge la un consens asupra soluției și a strategiei de implementare/testare.
4. În final, ideea este transpusă în bug tracker, nu ca o soluție venită direct din partea product management-ului, ci ca un rezultat al efortului colaborativ din partea întregii echipe, ajungându-se astfel la un epic/story cu detaliile bine clarificate.
După cum vă puteți da seama, BDD este un proces complex, care se poate aplica sub diferite “flavours” în cadrul mai multor echipe. Este o metodologie ce se ghidează după context, aceeași rețetă BDD ce funcționează pentru un proiect aducând alte rezultate dacă aplicată altui proiect. Sunt multe challenge-uri ce pot apărea de-a lungul timpului, iar noi am încercat să le abordăm pe fiecare în parte, evitând pe cât se poate recurgerea la compromisuri:
1. Implicarea activă a echipei de pro-duct management
• Challenge: rolul PO-ului este mult mai mare într-un proces BDD, iar aportul lor la scrierea și menținerea testelor în limbajul Gherkin trebuie să fie într-un procentaj mai mare decât cel al echipei tehnice. În cazul nostru, încă nu am ajuns în această situație. Ținând cont de timpul limitat pe care PO-ul îl poate acorda acestui task, developerii și testerii sunt cei care scriu scenariile Gherkin, acestea urmând a fi revizuite periodic împreună cu managemen-tul. Este o soluție de compromis ce funcționează în acest moment pentru echipa noastră.2. Folosirea cât mai eficientă a limba-
jului Gherkin• Challenge: acest lucru este unul
dintre cele mai complexe concepte ale BDD, deși în aparență poate părea des-tul de simplu. A scrie teste astfel încât să fie ușor de înţeles, ușor de menținut, din care să reiasă cu exactitate business value-ul feature-ului respectiv, se poate dovedi a fi un challenge în sine.3. Living Documentation
www.3pillarglobal.com
3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world.
Our core competencies include:
ProductStrategy
ProductDevelopment
ProductSupport
Our offerings are business focused, they drive real, tangible value.
29www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINE
• Challenge: documentația for-mată exclusiv din teste poate deveni un challenge, deoarece sunt multe checkpoint-uri ce trebuie bifate, pentru a atinge acest goal:
i. oglinda codului, reflectă întocmai situația actuală a codului,
ii. să fie accesibilă tuturoriii. să fie ușor de înțeles, ușor de
menținutiv. presupunând că se dorește
o schimbare majoră, într-un sis-tem legacy, Living Documentation poate reda riscurile ce pot apărea ca urmarea implementării schimbării respective. Acest lucru este posibil pentru că având teste scrise corect în limbajul Gherkin, putem urmări interacțiunea dintre componente, prin intermediul testelor, și vom reuși astfel să anticipăm posibilele riscuri.
Am insistat asupra limbajului Gherkin, exemplificând modul cum se poate descrie un feature prin scenarii scrise cu ajutorul acestui limbaj. Aceste teste sunt ținute în același loc cu codul, reprezentând datele de intrare ale unui tool specific BDD (Cucumber, Lettuce, Freshen, etc.). De aceea vom ști că sunt mereu up to date - testele sunt modificate de îndată ce codul este modificat, pentru a continua să reflecte situația actuală a codului.
ConcluziiConceptele BDD aplicate în acest
moment cu succes, obțin rezultatele dorite, dar suntem conștienți de faptul că mai avem mult de lucru. Printre obiectivele noastre în viitor, amintim:
1. C omunicare ș i colaborare în
permanență2. BDD depinde foarte mult de context,
așa că încercăm mereu să ne adaptăm stilul de lucru astfel încât să acoperim particularitățile fiecărui proiect
3. Codul scris de developeri trebuie să fie de la bun început testabil. Fără acest lucru, nu vom putea să scriem scenarii Gherkin care să îndeplinească cerințele Living Documentation menționate mai sus.
4. Living Documentation reprezintă goal-ul nostru principal pe toată durata existenței unui proiect unde se aplica BDD.
BDD este un proces complex, dar avan-tajele sale sunt multe, și contribuie mult la închegarea unei echipe în adevăratul sens al cuvântului și la livrarea unui produs de succes. Recomandăm sincer abordarea acestei metodologii, indiferent de com-plexitatea proiectului sau dimensiunea echipei. Aplicat astfel încât să țină cont de nevoile clare ale proiectului, BDD poate deveni cu ușurință o poveste de succes.
BibliografieMai multe informații cu privire la cum
se pot descrie funcționalități folosind un limbaj ubiquitos2 (Gherkin) , în funcție de tool-ul ales, se pot găsi la:• 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
specific BDD, poate fi folosit cu Python...și lista poate continua
30 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
QA
Test Driven Development (TDD)
Voi descrie o situație cu care majo-ritatea suntem familiari: programatorii scriu codul, iar la un moment dat acest cod ajunge la testare. Testerii descoperă anumite anomalii în funcționalitatea codului, numite bug-uri, pe care le trimit programatorilor spre a fi reparate. După ce programatorul a reparat bug-ul, trimite din nou codul la testare. De cele mai multe ori acest ”dialog” programator – tester nu este foarte clar și precis, un bug fiind pasat la tester de către programator ca și rezol-vat, tester-ul descoperă că de fapt nu s-a rezolvat și îl trimite înapoi la programator și tot așa. Pentru a nu se ajunge prea des în situația prezentată anterior, una dintre măsurile luate a fost cea ca programato-rul să scrie teste înainte de a implementa o anumită funcționalitate. Această tehnică se numește TFD (Test First Development).
Primul pas al TFD este de a se scrie un test care va eșua. Următoarea mișcare e cea de a rula toată suita de teste, sau, pentru a economisi timp se va rula doar un subset al suitei de teste, pentru a se dovedi că într-adevăr testul adăugat va eșua. Urmează să facem o mică modificare în cod în așa fel încât o nouă rulare a testelor să se termine cu succes. În cazul în care n-am reușit acest lucru vom modifica din nou codul și vom rula testele din nou până când acestea se vor termina cu succes. În momentul în
care rularea testelor s-a încheiat cu succes putem s-o luăm de la început cu adăugarea unui nou test.
TDD = TFD + RefactoringDacă, aplicând TFD, înainte de a trece
la scrierea unui nou test curățăm, opti-mizăm codul înseamnă că aplicăm Test Driven Development, numit și RED – GREEN – REFACTOR workflow.
Regulile TDD:1. Este permis să scrii cod de producție
doar dacă scopul acestui cod este să facă un test ce eșuează să ruleze cu succes.
2. Nu este permis să scrii decât un test care eșuează.
Trebuie să începi prin a scrie un test pentru funcționalitatea pe care vrei s-o implementezi. Conform celei de-a doua reguli nu poți să scrii prea multe teste. Imediat ce rularea unit testului se termină cu eșec trebuie să te oprești din a scrie teste și să începi să scrii cod de producție în așa fel încât rularea testelor să se termine cu succes. Atenție însă la a treia regulă care ne zice că imediatce am scris destul cod de producție pentru a face ca rularea testelor să se termine cu succes, suntem obligați să ne oprim din a scrie mai mult cod și să reluăm scrierea de teste.
Dacă stăm și analizăm puțin cele trei reguli TDD vom realiza că nu putem scrie prea mult cod fără să compilăm, rulăm ceva. Acesta este de fapt scopul nostru. Orice am face: scriem teste, scriem cod de producție sau refactorizăm trebuie să ținem sistemul în execuție. Intervalul de timp dintre rularea testelor poate să fie de ordinul secundelor sau al minutelor. Chiar și o durată de 10 minute poate fi conside-rată prea mare.
Când aud de aceasta tehnică, mulţi dintre programatori gândesc: ”Asta e o abe-raţie! O să mă încetinească și mai mult, e o
pierdere de timp și de efort. Nu o să mă lase să mă gândesc, nu o să pot face designul cum trebuie, pur și simplu o să strice bunul mers al lucrurilor”. Perfect, să ne gândim ce s-ar întâmpla dacă am intra într-un birou în care toți programatorii ar folosi TDD. Alegeți aleator o persoană din respectivul birou în orice moment și întrebați-l care e starea codului. Cu un minut înainte tot codul lor rula. Repet: ”Acum un minut tot codul lor rula!”. Şi nu contează pe cine ai ales sau când l-ai ales, răspunsul e același: ”Acum un minut tot codul lor rula!”.
Dacă tot codul tău funcționează la fie-care minut, cam cât de des crezi că vei folosi debugger-ul? Răspunsul este: nu prea des. Este mult mai simplu să apeși de câteva ori CTRL+Z să ajungi înapoi la starea în care codul tău funcționa, iar după asta să încerci să rescrii ceea ce ai scris greșit în ultimele minute. Cât timp vei economisi dacă nu faci prea mult debugging? Cât timp petreci acum făcând debugging? Cât timp petreci acum rezolvând bug-urile pe care le-ai des-coperit făcând debugging? Ce ai spune dacă ai putea să scazi semnificativ acest timp?
Adevăratele beneficii ale acestei tehnici sunt însă și mai mari: dacă folosești TDD atunci produci câteva teste pe oră. Zeci de teste pe zi. Sute de teste pe lună. Vei ajunge să scrii mii de teste într-un an. Poți să păs-trezi aceste teste și să le rulezi oricând vei dori. Când ar trebui să le rulăm? Tot tim-pul. De fiecare dată când am modificat ceva în cod, indiferent de proporțiile acelei modificări.
De ce nu curățăm codul chiar dacă știm că nu e prea curat? Pentru că ne este frică să nu-l stricăm. Dar dacă avem toate aceste teste putem fi siguri în cea mai mare măsură că nu vom strica codul, iar în cazul în care acest lucru s-ar întâmpla l-am observa imediat. Dacă avem teste vom fi liniștiți în momentul în care facem
Test Driven Development (TDD) este o abordare a dezvoltării de software ce combină Test First Development (TFD) cu refacto-rizarea. Legat de scopul test driven development-ului există mai multe puncte de vedere: specificarea codului și nu validarea lui. Cu alte cuvinte, este o cale de a gândi prin prisma cerințelor sau a designului înainte de a ne apuca efectiv a scrie cod funcțional
(TDD este o cerință agile - agile requirement - și o tehnică de design agile). Un alt punct de vedere este că TDD reprezintă o tehnică de programare al cărui scop este acela de a scrie cod curat care funcționează.
31www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINE
modificări în cod. Dacă vedem pe undeva cod „murdar” (messy code) putem să-l curățăm fără rezerve. Datorită testelor codul devine maleabil.
Continuăm cu beneficiile TDD: dacă vrei să știi cum să apelezi un anumit API, există un test ce face acest lucru. Dacă vrei să știi cum se creează un anumit obiect, este un test ce face acest lucru. Orice ai vrea să afli despre sistemul existent vei găsi un test care conține răspunsul la întrebarea ta. Testele sunt ca niște mici documente de design, mici exemple de cod care descriu cum funcționează sistemul și cum să-l folosești.
Ați integrat un third party library în proiectul vostru? Primiți cu acest library și un manual plin de documentație la finalul căruia aveți o listă cu câteva exemple. Care dintre cele două le-ați citit? Exemplele, bineînțeles. Acestea sunt unit testele. Cea mai folositoare parte a documentației. Exemple ale modului în care să folosești codul. Acestea sunt documente de design detaliate, clare, ce nu se pot desincroniza în raport cu codul de producție.
Dacă ați încercat să adăugați un unit test la un sistem deja funcțional probabil că ați observat că nu este un lucru trivial. Este posibil ca pentru a face acest lucru să fi fost nevoiţi să schimbați anumite părți ale designului sistemului, sau să trebuiască să păcăliți testele. Acest lucru se datorează faptului că sistemul pentru care încercați să scrieți testele nu a fost proiectat să fie tes-tabil. De exemplu, să presupunem că vreți să testați o anumită metodă, ”m”. Metoda ”m” apelează o altă metodă care șterge o înregistrare din baza de date. În testul nos-tru nu vrem ca această înregistrare să fie ștearsă din baza de date, dar nu avem cum să împiedicăm acest lucru. Asta înseamnă că sistemul a fost proiectat în așa manieră încât acesta nu este testabil.
Când urmăm cele trei reguli ale TDD tot codul nostru devine testabil prin definiție. Un alt cuvânt pentru ”testabil” este ”decuplat”. Pentru a testa izolat un modul acesta trebuie decuplat. TDD te forțează să decuplezi module, iar aplicând cele trei reguli TDD vei observa că vei folosi decuplarea mult mai des decât erai obișnuit s-o faci până acum. Acest lucru te va face să creezi un design mai bun, mai puțin cuplat (less coupled).
Începerea ciclului Test-DrivenProcesul TDD presupune că putem
mări sistemul doar prin inserarea de teste pentru funcţionalităţi noi într-o infra-structură deja existentă. Dar ce se întâmplă
cu prima funcţionalitate, înainte să avem infrastructura gata creată? Un test de acceptanţă trebuie să ruleze end-to-end. În plus, trebuie să ne ofere feedback-ul necesar despre interfeţele externe ale siste-mului, 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 nos-tru test care eșuează.
Deploy-ul și testarea unui proiect chiar de la început forţează echipa să înţeleagă cum sistemul lor se integrează în lume. Scoate la iveală toată lipsa de cunoștinţe tehnice și riscuri organizaţionale care tre-buie adresate cât mai este timp.
Începerea cu un build, deploy, și test automatizat a unui sistem nonexistent sună ciudat, dar este esenţial.Există tot felul de cazuri de proiecte care au fost anulate după câteva luni de dezvoltare deoarece nu puteau face un deploy stabil al sistemului lor. Feedback-ul este o unealtă fundamen-tală, și vrem să știm cât mai repede dacă ne îndreptăm în direcţia potrivită. După ce avem primul test făcut, următoarele vor fi scrise mult mai repede.
Dilema în a scrie și a trece primul test de acceptanţă stă în faptul că este dificil a face un build al sistemului și a testa noua funcţionalitate implementată în aceelași timp. Modificări într-una din cele două perturbă orice progres făcut cu cealaltă. Urmărirea eșecurilor este dificilă atunci când arhitectura, testele și tot codul de pro-ducţie sunt în continuă dez-voltare. Unul dintre simp-tomele unui mediu de dez-voltare instabil este că nu există un prim loc evident de căutare când ceva eșuează.
Acest paradox al primei funcţionalităţi poate fi împărţit în două probleme mai mici. Prima constă în a afla cum se poate face build, deploy și testa acest “walking skeleton”. Apoi, se folosește această infra-structură nou creată pentru a scrie teste de acceptanţă pentru prima funcţionalitate-importantă. După toate acestea, se poate începe dezvoltarea test-driven a întregului sistem.
Un “walking skeleton” este o imple-mentare a celei mai mici bucăţi de funcţionalitate pe care se poate face build, deploy, și testare end-to-end automatizată. Trebuie incluse doar componentele majore și mecanismele de comunicare care ne ajută la implementarea primei funcţiona-lităţi. Funcţionalitatea aplicaţiei schelet
este atât de simplă încât este evidentă și neinteresantă, lăsându-ne liberi să ne concentrăm pe infrastructură. De exem-plu: pentru o aplicaţie web cu o bază de date, scheletul ar trebui să consiste dintr-o pagină web uniformă cu câmpuri din baza de date.
În timpul construirii scheletului tre-buie să ne concentrăm doar pe structură și nu pe curăţarea testului. Scheletul și infra-structura sa sunt făcute pentru a ne ajuta să începem dezvoltarea test-driven. Este doar primul pas spre o soluţie completă end-to-end de testare de acceptanţă. Când scriem testul pentru prima funcţionalitate, acesta trebuie să fie un test pe care să putem să îl citim, pentru a ne asigura că e o reprezen-tare clară a comportamentului sistemului.
Dezvoltarea scheletului este momen-tul în care încep deciziile asupra structurii high-level a aplicaţiei. Nu putem automatiza un build, un deploy și un ciclu de test fără o idee asupra întregii structuri. Detaliile nu sunt necesare. Avem nevoie doar de o ima-gine de ansamblu asupra componentelor majore necesare pentru primul release pla-nificat, și comunicarea dintre componente. Regula de bază este că designul trebuie să poată fie desenat în doar câteva minute.
Pentru designul structurii iniţiale avem nevoie de o viziune high-level a cerinţelor clientului, atât funcţionale cât și non-func-ţionale pentru a ne ghida deciziile.
Figura de mai jos arată cum procesul de TDD se integrează în acest context:
Nu există tot timpul luxul de a crea un nou sistem de la zero. Majoritatea proiec-telor pe care lucrăm au început de la un sistem existent care trebuie extins, adaptat sau înlocuit. În aceste cazuri, nu putem începe sa construim un “walking skeleton”; trebuie să ne adaptăm la cel existent, indi-ferent cât de ostilă ar fi structura lui.
Procesul de începere al TDD-ului pe un asemenea sistem nu e prea diferit faţă de aplicarea lui pe un nou sistem – deși se poate dovedi mult mai dificil din cauza bagajului tehnic pe care sistemul deja il cară.
Este destul de riscant să lucrezi pe un sistem atunci când nu există teste care să detecteze regresiile. Cel mai sigur mod de a începe TDD-ul este de a automatiza procesele de build și de deploy, și de a adă-uga teste end-to-end care acoperă acele
regiuni de cod ce trebuie schimbate. Cu această protecţie, se poate începe adresa-rea de probleme interne de calitate cu mai multă încredere, refactorizarea codului și introducerea de unit teste pe măsură ce se adaugă funcţionalităţi.
Menţinerea ciclului test-drivenOdată început procesul de TDD, trebuie
menţinut să ruleze fără probleme. Munca pentru o funcţionalitate nouă începe cu un test de acceptanţă care pică, ceea ce demonstrează că sistemul nu are încă func-ţionalitatea pe care o vom implementa.
Acest test se scrie folosind terminologia din domeniul aplicaţiei, nu din tehnologiile care stau la baza ei (ex: baze de date sau ser-vere web). Astfel, ne ajută să înţelegem ce ar trebui să facă sistemul nostru și ne prote-jează suita de teste de acceptanţă împotriva schimbărilor tehnice ale infrastructurii sistemului.
Scrierea acestor teste înaintea scrierii codului ne ajută să clarificăm ceea ce vrem
să obţinem. Testele care pică ne ţin concen-traţi în implementarea setului limitat de funcţionalităţi pe care le descriu, crescând șansele noastre de a le livra.
Unit testele sunt importante în rea-lizarea design-ului claselor și în a ne da încrederea că funcţionează, dar ele nu ne spun nimic dacă funcţionează împreună cu restul sistemului.
De unde începem când trebuie să scriem o nouă clasă sau funcţionalitate? E tentant să începi cu cazurile degenerate sau de eșec pentru că sunt de obicei mai ușoare. Cazurile degenerate nu aduc multă valoare sistemului, și cel mai important nu ne dau feedback despre validitatea ideilor noastre. Incidental, focusarea pe cazurile de eșec la începutul unei funcţionalităţi este rea pen-tru moral: dacă ne ocupăm doar de error handling, ne simţim ca și cum nu am rea-lizat nimic.
Cel mai bine e să începem cu cel mai simplu caz de succes. Odată ce acel test merge, avem o mai bună idee a structurii reale a soluţiei, și putem prioritiza între a ne ocupa de posibilele eșecuri ce le-am
observat între timp și alte cazuri de succes.Vrem ca fiecare test să fie cât de clar
posibil o reprezentare a comportamentului sistemului sau a obiectului. Când testul e lizibil, atunci construim infrastructura din spatele testului. Ştim că am implementat destul cod de test atunci când testul pică în modul în care ne așteptam, cu un mesaj de eroare clar, care descrie ce trebuie făcut. Doar atunci putem începe să scriem codul care va face testul sa treacă.
Întotdeauna trebuie să vedem testul cum eșuează înainte să scriem codul care-l va face să treacă, și să verificăm mesajul de diagnostificare. Dacă testul eșuează într-un mod în care nu ne-am așteptat, atunci știm că ceva n-am înţeles bine sau codul este incomplet, și îl putem repara. Când pri-mim eșecul la care ne așteptăm, verificăm dacă diagnostificarea este de ajutor. Dacă descrierea nu este clară, cineva va trebui să se chinuie atunci când codul se va strica în viitor. Ajustăm codul de test și rulăm tes-tele din nou până când mesajul de eroare
ne ghidează la problema cu codul nostru.
Doar scrierea de multe teste, chiar și atunci când rezultă în acoperirea mare a codului, nu garantează un codebase cu care se lucrează ușor. Mulţi developeri care adoptă TDD își găsesc primele lor teste greu de înţeles când le revizuiesc mai târziu. Această
greșeală comună constă în faptul că ei se gândesc să testeze doar metodele obiec-tului. De exemplu: un test ce se numește testBidAccepted() ne spune ceea ce face
testul, dar nu pentru ce e folosit. Cel mai bine e atunci când ne focusăm pe funcţio-nalităţile furnizate de către obiectul testat, poate una dintre ele necesită o colaborare cu un alt obiect. Trebuie să știm cum să folosim clasa ca să atingem un ţel, nu doar să exersăm toate căile prin codul ei.
Este de foarte mare ajutor să alegem numele testelor pentru a descrie cum se comportă obiectul în scenariul testat.
Când scriem unit teste și teste de
integrare, stăm în alertă pentru acele părţi de cod care sunt greu de testat. Când găsim o astfel de funcţionalitate, nu trebuie să ne întrebăm doar cum o testăm, ci și de ce este așa de greu de testat. De cele mai multe ori, cel mai probabil e faptul că design-ul are nevoie de îmbunătăţiri. Aceași structură care face codul greu testabil acum, o va face și mai greu pe viitor.
Procesul de a scrie testele la început este un valoros avertisment a unei posibile probleme de mentenanţă și poate indica anumite indicii de rezolvare a problemei cât e încă la început.
ConcluziiTest-driven development nu înlocuiește
testarea tradiţională, ci în schimb definește o modalitate dovedită de a asigura testare eficientă. Un efect secundar al TDD-ului este că testele rezultate sunt exemple func-ţionale de invocare a codului, oferind astfel o specificație a codului scris. Din experi-enţa noastră, TDD funcţionează incredibil de bine în practică și este ceva ce toţi dez-voltatorii de software ar trebui să adopte.
Referinţe:Test Driven Development: By Example, Kent Beck, Addison-Wesley Longman, 2002Growing Object-Oriented Software Guided by Tests, Steve Freeman, Nat Pryce,2009http://butunclebob.comhttp://www.agiledata.orghttp://cumulative-hypotheses.org
33www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINE tendințe
Întâmplător cu câteva săptămâni îna-inte ca H1N1 să ajungă pe prima pagină a ziarelor Google a publicat în Nature, o publicație științifică, o lucrare în care pre-zentau rezultatele unui studiu care a pornit de la întrebarea “Există oare o corelație între răspândirea unei epidemii și căutările efectuate prin Google?”. Presupunerea de la care a plecat Google este că, în momen-tul în care cineva resimte efectele unei boli proaspăt contactate se va folosi de Internet pentru a căuta informații despre simptome. Astfel, utilizând datele publi-cate între 2003 și 2008 de către CDC și cele mai frecvente 50 de milioane de cău-tări din aceeași perioadă, Google a reușit să identifice un model matematic (iterând peste 400 de milioane de înregistrări) care să demonstreze corelația dintre evoluția unei epidemii și felul în care lumea caută pe Internet. Cu ajutorul acestei noi tehno-logii, intitulate Google Flu Trends, CDC a reușit în 2009 să monitorizeze mai eficient răspândirea H1N1.
Povestea Google Flu Trends este din multe puncte de vedere exemplul arhe-tip atât pentru beneficiile, cât și pentru tehnologia și provocările implicate în soluționarea unei probleme din spațiul Big Data. Pornind de la o ipoteză ce caută o corelație și folosind cantități mari, nestructurate de date, alături de tehnologii moderne de procesare, se încearcă validarea
corelației care, în final, aduce valoare prin transformarea datelor în informații noi.
Big Data: Noul “Cloud Computing”Big Data se află la început de drum. O
dovadă în acest sens o reprezintă confuzia pe care o putem întâlni în piață când vine vorba de a defini problema pe care Big Data o adresează și modul (sau modurile) în care o face. Când vorbeam în 2009 despre Cloud Computing mă amuzam să constat că întrebarea “Ce este Cloud Computing?” adresată unei săli cu 50 de participanți avea potențialul de a primi 52 de răspunsuri din care, culmea, multe corecte. Situația este similară în prezent în cazul Big Data și asta deoarece ne aflăm într-o perioadă apro-piată de ceea ce Gartner numește “peak of inflated expectations” (vârful inflației așteptărilor). Cu alte cuvinte, peste tot se discută despre Big Data, iar toată indus-tria este antrenată în a descoperi beneficii
într-un spectru larg de tehnologii și con-cepte, ce pornește de la un grad ridicat de maturitate/aplicabilitate (Predictive Analytics, Web Analytics) și se încheie cu scenarii inspirate din Star Trek (Internet of Things, Information Valuation, Semantic Web).
“Cloud Computing” a trecut deja de vârf, conform volumului de căutări Google, în timp ce “Big Data” se află în continuare în creștere. Problema fundamentală ce determină confuzia și implicit așteptările nerealiste este însă cauzată de faptul că Big Data este compus (conform modelu-lui “Hype Cycle” al Gartner) din peste 45 de concepte surprinse în diferite stadii: de la cel de pionierat (i.e. “Technology Trigger”) la cel de maturitate (i.e. “Plateau of Productivity”). Așadar Big Data nu poate fi tratat holistic la nivel tactic, ci doar prin-cipial, la nivel strategic.
În “Big Data: A Revolution That Will Transform How We Live, Work and Think” autorii Viktor Mayer-Schonberger și Kenneth Cukier încep prin a prezenta situația anului 2009 în care virusul H1N1 reprezenta o îngrijorare majoră a Organizației Mondiale a Sănătății, dar în particular a guvernului American. Evoluția rapidă a epidemiei punea în dificultate CDC (Center for Disease
Control and Prevention), o agenție guvernamentală, care a raportat situația cu o întârziere de două săptămâni față de realitatea din teren,pentru că populația nu intra în contact cu personalul medical după apariția primelor simptome. Raportarea în timp real ar fi permis o mai bună înțelegere a dimensiunii epidemiei, optimizarea tacticilor de prevenire și tratare, acțiuni cu potențial în salvarea de vieți într-un dezastru care, în final, a totalizat peste 284.000 de victime.
Big Data, Big Confusion
Într-o eră în care costurile de stocare și procesare
devin tot mai mici, optica tradițională a felului în care
operăm cu datele se schimbă decisiv
Figura 1 - Volumul comparativ al căutărilor „Big Data” (albas-
tru) și „Cloud Computing” (roșu) (sursa: Google Trends)
TODAY SOFTWARE MAGAZINE
34 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
Small Data Thinking, Small Data Results
Mayer-Schonberger și Cukier identifică trei principii fundamentale ce permit tre-cerea de la o abordare Small Data la una Big Data.
“More”: păstrează și nu aruncaCosturile de stocare a datelor au ajuns
în 2013 la un minim istoric. În momentul de față stocarea a 1 gigabyte (GB) de date costă mai puțin de 9 cenți / lună folosind un serviciu de stocare în cloud (e.g. Windows Azure), iar pentru arhivare ajung la 1 cent / lună (e.g. Amazon Glacier), reducând cos-turile de stocare al unui petabyte (1.048.576 GB) la aproape $10.000,- (sau $10 pentru un terabyte), de 1.000.000 de ori mai ieftin decât la începutul anilor ’90, când costul mediu de stocare / GB era de aproximativ $10.000. În acest context ștergerea datelor digitale acumulate din procesele infor-matice are tot mai puțin sens. Google, Facebook, Twitter ridică acest principiu la nivel de lege fundamentală, reprezentând biletul lor pentru noi dimensiuni de dez-voltare și inovare, oportunitate deschisă acum și celor care până recent erau limitați de costurile prohibitive.
“Messy”: cantitatea precede calitățiiGoogle Flu Trends a funcționat deoa-
rece Google a reușit să introducă în procesul de iterație a modelelor matematice cele mai frecvente 50.000.000 de căutări. Multe dintre aceste căutări au fost irele-vante, însă volumul a fost necesar pentru a determina modelul care în final a reușit să demonstreze corelația. Peter Norvig, expertul Google în inteligență artificială,
a afirmat în cartea sa “The Unreasonable Effectiveness of Data” că “modele simple alimentate cu un volum mare de date vor eclipsa modele mai elaborate bazate pe mai puține date”, un principiu folosit și în rea-lizarea Google Translate, un serviciu de traducere automată bazat pe un corpus de peste 95 de miliarde de propoziții formu-late în limba engleză, capabil să traducă în și din peste 60 de limbi.
“Correlation”: fapte și nu explicațiiAm fost învățați și ne-am obișnuit
că efectul este determinat de o cauză, motiv pentru care în mod natural suntem tentanți să aflăm “de ce?”. În lumea Big Data corelația devine mai importantă decât cau-zalitatea. În 1997 Amazon avea pe statul de plată un întreg departament respon-sabil să întocmească liste cu recomandări de lectură pentru cei ce vizitau librăria online. Era un proces manual, costisitor și cu impact limitat în generarea de vânzări. Astăzi, grație unui algoritm intitulat “item-to-item collaborative filtering” dezvoltat de către Amazon, recomandările se fac în mod complet automatizat, dinamic și cu un impact masiv în vânzări (o treime din veniturile generate de comerțul electronic provenind din recomandările automate). Amazon nu vrea să știe de ce clienții care cumpără “The Lord of the Rings” de J. R. R. Tolkien sunt interesați să cumpere și “Friendship and the Moral Life” de Paul J. Wadell, însă ce-i interesează este că există o corelație puternică între aceste două titluri, iar aceastfapt le va genera venituri de trei ori mai mari decât în lipsa unui astfel de sistem.
ConcluziiÎn momentul de față Big Data repre-
zintă tendința cea mai abuzată din piață, drept urmare gradul de confuzie generat de pletora de opinii întâlnite la tot pasul (categorie din care articolul de față nu se exclude) este extrem de ridicat, condu-când la așteptări nerealiste și dezamăgiri pe măsura lor. Claritatea vine însă din înțelegerea potențialului, adoptarea prin-cipiilor (i.e. more, messy, correlation) și acționarea preventivă pentru adaptarea sistemelor curente la noul mod de gândire din perspectiva infrastructurii de calcul, al arhitecturii și a competențelor tehnice ale celor ce le operează. Miza este aceea de a identifica noi oportunități adresabile de transformare a datelor în informații ce pot crește eficiența unui produs sau al unei afaceri, așa cu a făcut-o Google prin Flu Trends sau Amazon prin sistemul lor auto-matizat de recomandări.
Yonder acumulează experiență Big Data, investind strategic în proiecte de cercetare aplicată, alături de companii de produs care au înțeles viziunea pe care am conturat-o și beneficiile pe care o aseme-nea investiție le poate genera atât pe termen scurt cât și pe termen lung, acest trend reprezentând una din cele patru direcții tehnologice alese ca temă de inovație în 2013.
Big Data, Big Confusiontendințe
Figura 2 - Big Data „Hype Cycle” (sursa: Gartner, 2012)
este responsabil de activitățile R&D și creșterea nivelului de inovație al produselor partenerilor Yonder.
35www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINE programare
“Data grids” sunt o categorie de software middleware, care ajută la rezol-varea problemelor enumerate mai sus. În acest articol voi prezenta o implementare rudimentară de bursă electronică care - în ciuda simplității sale - are robustețea și performanța cerută de la sisteme reale grație librăriei pe care se bazează.
Bazele data grid-urilorData grid-urile furnizează trei servicii
principale:• Una sau mai multe structuri de
date de tip cheie-valoare (asemănător interfeței Map<K,V> din Java). Datele din aceste structuri sunt replicate pentru o fiabilitate ridicată.• În același timp permit definirea unui
set de reguli pentru plasarea a datelor (de exemplu: trebuie ținute N copii pentru fiecare element, dintre care K trebuie să fie pe un anumit set de noduri - pentru asigurarea replicării geografice de exem-plu) care măresc performanța (datele folosite împreună pot fi plasate pe același nod) și asigură garanții în cazul în care un subset de noduri devin indisponi-bile (fail-over între data-center-uri de exemplu).• Un serviciu de execuție care poate
rula task-uri pe noduri. Aceste servicii de obicei sunt parametrizate folosind cheile din structurile (Map-urile) cheie-valoare pentru a se asigura că codul rulează pe mașina unde se află datele care urmează să le proceseze pentru evitarea transpor-tul datelor prin rețea în mod repetat.• Posibilitatea de a fi notificat des-
pre evenimentele din structuri le cheie-valoare (adăugarea / eliminarea / actualizarea datelor)
Deși nu este o cerință ca un sistem săfie considerat “data-grid”, de obicei aceste librării pun la dispoziție o interfață confi-gurabilă care să persiste datele în sisteme externe - baze de date / fișiere simple / etc. - ca să fie păstrate în timpul repornirii complete a sistemului (data-grid-urile sto-chează datele exclusiv în memoria volatilă). De asemenea, ele implementează de obicei suport pentru operații tranzacționale pe structurile de date.
Biblioteca, prezentată în acest articol - Infinispan - folosește o tehnică numită hash-uri consistente1 pentru a oferi urmă-toarea configurație posibilă în timpul rulării: folosind N noduri, vrem să păstrăm fiecare bucată de date pe exact K dintre ele (K≤N - de obicei 2 sau 3). Dacă sunt adău-gate sau eliminate din cluster noduri, datele sunt redistribuite în așa fel încât proprieta-tea să fie menținută. Această redistribuție se întâmplă în mod transparent din punct de vedere funcțional (proprietățile non-funcționale a sistemului - cum ar fi latența - se schimbă în timpul procesului de redistribuție). Puteți vedea o ilustrare a conceptului în graficul alăturat:
Aici avem fiecare bucată de date (D1, D2 și D3) replicat în trei noduri, ceea ce înseamnă că oricare două noduri pot eșua în orice moment și datele vor fi disponibile în continuare. Un alt efect util al aces-tui mecanism de replicare este utilizarea optimă a resurselor în comparație cu oglin-direa (mirroring) simplă:
1 http://en.wikipedia.org/wiki/Consistent_hashing
De exemplu, să presupunem că avem N noduri, fiecare cu 12 GB de memorie. Dacă am păstra o copie identică a setului de date pe fiecare nod, dimensiunea maximă a datelor ar fi de 12 GB (dar am avea N copii, însemnând ca sistemul tolerează eșuarea a N-1 noduri). Dacă decidem că K exem-plare a datelor (unul primar și K-1 copii) sunt suficiente pentru a satisface cerințele noastre de fiabilitate și folosim un sistem bazat pe hash consistent (ca și cel oferit de Infinispan), avem un maxim teoretic pen-tru dimensiunea datelor de (N*12GB.)/K. De exemplu, pentru N = 10 și K = 3 obținem o dimensiune maximă de40 GB (în comparație cu 12GB pentru cazul cu replicare completă).
O scurtă istorie a Infinispan-uluiInfinispan2 este un proiect din cadrul
meta-proiectului JBoss susținut de RedHat. Este un data-grid extrem de configurabil cu un set extins de facilități. Este succesorul produsului JBoss Cache cu multe caracte-ristici interesante:
• scalabilitate înaltă,• suport pentru a rula ca server dedicat
sau încorporat (embedded) în proces,
• s u p o r t p e n t r u o p e r a ț i i tranzacționale,• replicare configurabilă între noduri și
între centre de date,• posibilitatea de accesarea datelor
prin interfețe standard, cum ar fi REST, protocolul memcached, WebSockets sau printr-un protocol binar numit Hotrod
2 http://www.jboss.org/infinispan/
O provocare importantă când construim un produs de succes este să ne asigurăm că produsul utilizează resursele hardware disponibile într-un mod eficient. Acest lucru înseamnă de obicei clustering (mai puțin pentru probleme foarte simple) pentru că seturile noastre de date au depășit calculatoarele individuale ca mărime și necesități de procesare. Cu toate acestea cluste-
ring-ul aduce o serie de noi probleme: împărțirea procesării între noduri, orchestrarea procesului și - foarte important - garanția că nu vom pierde datele / progresul dacă un subset de noduri devine indisponibill - o posibilitate care crește dramatic în momentul în care adăugăm mai multe noduri la cluster-ul nostru.
Sisteme cu perfomanță/fiabilitate ridicată bazate pe
“data grids” în Java
36 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
Folosirea Infinispan-ului este simplă - doar adăugăm dependența de Maven în POM și putem începe să o utilizăm. Se bazează pe JGroups, o soluție de messa-ging fiabil pur Java, ceea ce înseamnă că nu există un cod nativ care trebuie com-pilat / instalat. Infinispan este disponibil sub licența LGPL 2.13, ceea ce înseamnă că poate fi utilizat în orice proiect (comer-cial sau open-source). De asemenea, este disponibil suport comercial pentru el de la RedHat sub denumirea “Red Hat JBoss Data Grid”.
Descrierea proiectuluiAcest proiect modelează „inima” unei
burse electronice: motorul de potrivire (matching engine). Ea face acest lucru cu o performanță similară cu sistemele reale (peste 500 de evenimente pe secundă, în timp ce cea mai populară bursă de Bitcoin - MtGox - are în medie mai puțin de o tranzacție pe secundă). Fiind construit cu Infinispan, fiecare operațiune este replicată într-un nod secundar, ceea ce înseamnă că pierderea unui nod arbitrar poate fi tolerată fără pierdere date. De fapt, în codul sursă există un test care simulează chiar acest scenariu - pornește și oprește noduri în mod aleator în timp ce rulează motorul de potrivire.
Sursă pentru întregul sistem este dispo-nibil pe GitHub4sub licența liberă Apache 2. Structura sistemului poate fi văzută în schema de mai jos:
Clientul folosește datele capturate de la bursa Bitcoin MtGox pentru a crea comenzi (intenții de tranzacționare - cum-părare / vindere - la un anumit preț dat sau mai bun - așa-numitele “limit or better order”). Comenzile sunt transmise printr-o interfață HTTP / REST (implementat folosind Jersey) la unul din nodurile. Se demonstrează astfel interoperabilitatea cu alte sisteme non-Java, prin folosirea proto-coalelor standard.
După ce o comandă este transmisă nodul corespunzător, acesta este plasat în cartea de comenzi (orderbook - lista ordo-nată a tuturor comenzilor), algoritmul de potrivire este rulat și toate tranzacțiile rezultate sunt stocate. Toate acestea se întâmplă într-un mod tranzacțional, ceea ce înseamnă că nu se stochează rezultate parțiale / inconsistente. Clientul comu-nică cu un singur nod la un moment dat și comută la nodul următor (fail-over) dacă se observă o eroare. Nu este implementat în acest proiect, dar putem adăuga cu ușurință o conexiune care primește date în timp real despre tranzacții folosind de exemplu pro-tocolul WebSockets.
Cărțile de comenzi (orderbook) sunt serializate și deserializate într-un mod efi-cient pentru a fi sincronizate între nodurile primare și secundare utilizând faciliatatea de replicare delta din Infinispan prin care numai modificările (delta) sunt trimise print rețea . Acest lucru ne permite să păs-trăm obiecte mari pentru o anumită cheie
fără a sacrifica eficiența în timpul replicării. Practic putem separa problema modelării datelor (ce subset de date trebuie păstrate împreună) de problema plasării datelor.
Testul final repornește în mod alea-tor nodurile la fiecare câteva minute, fără ca acesta lucru să schimbe corectitudinea rezultatului.
ConcluziiData-grid-urile sunt o soluție excelentă
pentru sisteme care necesită performanță și fiabilitate ridicată. Proiectul prezentat în acest articol procesează cu un ordin de mărime mai multe date decât necesar în sistemele reale și poate fi integrat cu schimbări de cod minime. Face acest lucru într-un mod eficient, tolerând repornirea oricărui nod în timpul rulării.
Sisteme cu perfomanță/fiabilitate ridicată bazate pe “data grids” în Java
Neo4j face parte din fenomenul NOSQL încadrându-se încategoria bazelor de date de tip graf. O caracteristică unică a acestora este gradul ridicat de adaptibilitate la modelele reale de date.
Atât în cazul bazelor de date relaționale cât și în cazul unor soluțiiNOSQL (non-graph) procesulde modelare / design trece prin două faze :
• Definirea conceptelor , a entitățilorși a interacțiunii dintre ele – model logic/real• Materializarea modelului logic într-
un model fizic/abstract ( Ex. În cazul bazelor de date relaționale schemă)
De cele mai multe ori modelul logic este foarte diferit de modelul fizic. În cadrul unei organizații software în prima fază poate participa orice echipă nu nea-părat tehnică(management / sales ) pentru o mai bună definire a cerințelor sau con-ceptelor.În cea de a doua fază însă are loc abstractizarea modelului logic în funcție de opțiunea de stocare. Astfel gradul de înțelegere al modelului logic scade odată cu creșterea complexității datelor.
Marele avantaj al bazelor de date de tip graf și implicit utilizarea Neo4j este că modelul logic este același cu modelul fizic. Având acest mod de reprezentare uniformă sau astfel spus o reprezentare “human rea-dable” ce oferă un mare grad de flexibilitate
, adaptibilitate și expresivitate în modelarea datelor reale.
Acest tip de bază de date permite o abordare iterativă putând fi utilizată cu succes în strategia de development de tip Agile.
Reprezentarea datelor în Neo4JÎn Neo4j datele sunt reprezentate prin
noduri și relații. Atât nodurile cât și relațiile pot fi avea proprietăți.Relațiile au un rol foarte important în cadrul bazei de date de tip graf pentru că traversarea grafului și implicit manipularea datelor se realizează prin intermediul lor.
O relație implică întotdeauna două noduri, are o direcțieși un tip identificat unic printr-un nume.
În exemplul de mai sus relaț ia “KNOWS” conectează nodurile “Autor 1” cu “Autor 2 ” precizând de asemenea pro-prietatea adițională “since”.
Relativ la un nod relațiile se pot clasi-fica în două tipuri :
• incoming,
• outgoing.Atât proprietățile unui nod cât și
cele aleunei relații pot fi indexate pentru îmbunătățirea performanței de traversare a grafului ( similar cu indexarea coloanelor în bazele de date tradiționale ).
Forțând o comparație cu bazele de date tradiționale, vă puteți imagina un nod ca o înregistrare dintr-un tabel, iar o relație ca o înregistrare dintr-un tabel de legătură sau o pereche de coloane din același tabel în cazul unei reprezentări tip denormalizat.
Limbajul de interogare CypherNeo4j are propriul limbaj de intero-
gare a datelor organizate în structuri de graf.Este folosit conceptul de “Traversal” prin intermediul căruia se navighează în graf, se indentifică drumurile și implicit se selecteză nodurile pentru rezultatul unei interogări.
Limbajul Cypher este un limbaj de interogare declarativ fiind foarte intuitiv și “human readable”, putând fi înțeles cu ușurință chiar și de o persoană non-tehnică.
Unele cuvinte cheie sunt inspirate din SQL cum ar fi: where, order by , limit, skip (echivalentul offset)
Limbajul este alcătuind din următoa-rele clauze :
• START – punctul de intrare în graf. Orice interogare în graf are cel puțin un nod de start, • MATCH –șablonul pentru căutarea
nodurilor și care este legat de nodul de start,• WHERE–condițiile de filtrare a
nodurilor / relațiilor,• RETURN –rezultatul interogării,• CREATE –creează noduri sau relații ,• DELETE –șterge noduri sau relații, • SET –setează proprietăți noduri sau
relații,• FOREACH –update pe liste de
noduri, • WITH –împarte interogarea în mai
multe părți distincte.
Pentru exemplificare vă propun urmă-torul graf care reprezintă autorii care publică în TSM relaționați după cum urmează :
Neo4j este o baza de date open-source fondată pe teoria grafurilor, fiind o soluție optimizată pentru a modela și interoga volume mari de date strâns relaționate, reprezentabile prin structuri de tip graf. Dinamismul,creșterea volumului datelor, precum și evolutia continuă a procesării informațiilora impus ieșirea din spațiul bazelor de date relaționale tradiționale și orientarea
Cum observați și mai sus crearea nodurilor și a relațiilor este foarte intuitivă și flexibilă.
Exemple de interogări pe graful de mai sus:
1.start n=node(*) match n-[:WROTE]->(a) return n, count(a) (rezultatul va afisa fiecare autor cu numarul de arti-colo publicate)
2.start magazine=node(*) match magazine<-[:Published_in]-(article)<-[:Wrote]-(author)-[:Interested_in]->(subject) where magazine.name?=’’TSM’ and subject.subject?=’Java’ return au-thor.name, article; (rezultatul va afisa toate articolele cu subiectul Java impreuna cu numele autorului)3.start n=node(*)match n<-[:Published_in]-(article) return count(article)( rezulatul afiseaza numarul de articolo publicate în TSM)
În cazul în careavem milioane de autori și avem cerința de a adăuga o nouă relație ( ex. RATING între un autor și un articol), trebuie doar adăugată relația și funcționalitatea de a conecta autori cu articole se poate realiza. În cadrul unei baze de date relaționale, operațile de modificare de schema sunt de obicei costisitoare și nu neapărat simple.
Astfel că se poate spune ca modelul evoluează în mod natural odată cu datele reale și cerințele impuse de business.
SpringData și Neo4jNeo4j expune un API Java foarte variat care permite crearea și
manipularea grafurilor. O alta opțiune este utilizarea platformei REST. Fondatorii
Spring Framework au creat un nou modul adresat bazelor de date NOSQL.
Numele lui este String Data și are la bază aceeași abstactizare a interacțiunii cu bazele de date princonceptul “Templates” ( ex. JDBCTemplate) .
Ca analogie, la fel cum interacțiunea cu SQL se realizează prin hibernate, interacțiunea cu Cypher se realizează prin Spring Data Neo4j support.
Oriunde este nevoie de Hadoop, se impune prezența unui nod numit: NameNode. Acest nod reprezintă nodul de tip master, stocând locația tuturor fișierelor din sistem. El este singurul nod care poate să identifice locația unui fișier pe baza numelui. În jurul acestui nodexistă DataNode-uri, care stochează conținutul fișierelor.
Procesarea datelorFaima Hadoop-ului vine de la proce-
sarea datelor și extragerea informațiilor de care avem nevoie. În următoarele rân-duri vom descrie mecanismul acestei performanțe.
Un prim element este MapReduce. Această paradigmă nu a fost inventată de către Hadoop, dar a ajuns să facă acest lucru cel mai bine. La prima întâlnire cu MapReduce avem senzația că este compli-cat, dar odată înțeleasă, această paradigmă ne ajută foarte mult.
Totodată, nu încercați să folosiți Hadoop dacă nu ați înțeles MapReduce în totalitate. Fără să înțelegem MapReduce nu putem ști ce anume vrem să cerem de la Hadoop și la ce rezultate să ne așteptăm.
MapReduce și TupluriÎn comparație cu un sistem care sto-
chează datele în tabele, să nu vă așteptați ca Hadoop să fie similar. Acesta știe să lucreze cu date sub forma unui tuplu – o pereche de tip (cheie, valoare). Fiecare task pe care Hadoop trebuie să îl execute are ca input tupluri de tip (cheie, valoare), iar rezultatul pe care îl obținem de la un task are aceeiași formă de tip (cheie, valoare).
Deși pare destul de banal, vom vedea că nu este nevoie de mai mult decât atât pen-tru a putea obține datele dorite.
MapProcesul de MapReduce este format din
două părți total separate – Map și Reduce.
Map se referă la procesul prin care datele pe care dorim să le procesăm sunt convertite la un nou set de date. Datele pe care le obținem după acest pas sunt doar niște date inter-mediare care în starea în care sunt nu pot fi folosite.
Operația de tip Map nu se execută doar pe un sin-gur nod în cadrul sistemului. Această acțiune va fi exe-cutată pe mai multe noduri de tip DataNode. Fiecare DataNode va genera un rezul-tat intermediar. Din punct de vedere a cantității de date care se generează după procesul de Map, aceasta este mult mai mică în comparație cu datele originale.
Ne putem imagina că după acest pas, Hadoop ne generează un sumar a datelor noastre în funcție de parametri de care noi suntem interesați. Este important să știm că datele intermediare pe care le obținem nu trebuie să aibă același format ca și datele de input.
În momentul de față, cheile ajung să fie partiționate pe baza unei funcții – în gene-ral o funcție de hash.
Odată ce procesul s-a finalizat cu succes, Hadoop poate să execute diferite operații peste ele, precum sortarea, sepa-rarea sau shuffle – această funcționalitate este destul de nouă, circa un an. Acești pași pregătesc datele intermediare pentru urmă-torul pas. Atenție, acest pas se execută și în cadrul operației de Reduce.
Din punct de vedere al paralelismului, pe fiecare nod unde se execută operația de tip Map, putem să avem de la 10 până la 100-150 de operații. Totul depinde de cât de performante sunt nodurile cu care lucrăm.
Reduce
Odată ce avem datele intermediare, putem să le procesăm pentru a obține datele finale, de care suntem interesați. Până în acest moment puteam executa operațiile de tip Map pe fiecare din nodurile din clus-ter care conțineau datele noastre. Operația Reduce se va executa doar pe un număr limitat de noduri. Datele sunt partiționate pentru fiecare Reducer în parte.
Dacă operația de Map era formată dintr-un singur pas, operația de Reduce este formată din 3 pași separați
• Shuffle,• Sort,• Reduce.
În momentul în care se face shuffle, datele de la nodurile care au fost implicate în procesul de Map sunt trimise la nodu-rile care urmează să execute următorul pas. Acest lucru se face folosind o conexiune HTTP. Din cauză că suntem într-o rețea privată, nu trebuie să ne facem probleme din punct de vedere al securității.
Toate tuplurile care sunt trimise, sunt apoi sortate pe baza cheii. Acest lucru este necesar deoarece putem avea aceleași chei de la diferite noduri. În general, procesul de sortare se execută simultan cu procesul
În ultimul număr am descoperit lumea pe care Hadoop o formează și care este secretul prin care putem să stocăm zeci și chiar sute de TB fără nici un fel de probleme. Aceasta se bazează pe un sistem de tip master-slave extrem de simplu, dar care funcționează foarte bine.
Hadoop (II)
programare
TODAY SOFTWARE MAGAZINE
40 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
management
de shuffle. Odată ce operația de shuffle s-a finali-
zat, Hadoop va mai executa încă o sortare. În acest moment putem să controlăm modul în care datele să fie grupate și chiar să facem o sortare intermediară după diferiți parametri. Operația de sortare este o operație care se execută atât pe disk cât și în memorie.
Ultima operație care a mai rămas de executat este reduce. În momentul în care această operație se execută, rezultatele finale vor fi scrise pe disk. La acest pas fiecare tuplu este format dintr-o cheie și o
colecție de valori. Din această colecție de valori operația de reduce va selecta valoa-rea finală.
Deși pasul de reduce este extrem de important, pot să existe cazuri când nu dorim să facem acest lucru. În astfel de cazuri, putem să specificăm că rezultatul obținut după Map să fie scris direct pe disk și să fie considerat rezultat final.
JobTracker, TaskTrackerOperația de tip MapReduce implică
două tipuri de servicii care poartă numele de JobTracker și TaskTracker. Acestea două sunt într-o relație de tip master-slave, extrem de asemănătoare cu cea pe care am văzut-o la nivelul modului în care datele sunt stocate – NameNode și DataNode.
Scopul principal pe care JobTracker
îl are este să facă scheduling și să moni-torizeze fiecare acțiune. În cazul în care una din operații nu se termină cu succes, JobTracker va reprograma această operație. JobTracker-ul discută în permanență cu NameNode-ul și are grijă ca operația care trebuie să se execute să fie pe același DataNode sau cel puțin în același rack în care datele pot fi găsite.
TaskTracker-ul este un nod care acceptă operații de tip Map, Reduce sau Suffle. Acesta poate să fie DataNode-ul unde datele sunt stocate, dar acest lucru nu este obligatoriu. Fiecare TaskTracker
are un număr limitat de job-uri pe care le poate executa (slot). Din această cauză JobTracker-ul va căuta întot-deauna TaskTracker-ul care are cât mai multe slot-uri libere.
Un lucru destul de inte-resant care a fost făcut pe TaskTracker este modul în care fiecare job se execută. Acesta se execută într-un proces JVM separat. Prin acest mod în cazul în care apare o eroare, aceasta nu va fi propagată la toate job-urile care rulează pe TaskTracker-ul curent.
ExempluPână în acest moment am prezentat din
punct de vedere teoretic cum MapReduce funcționează. Vă propun ca în următoa-rea parte a articolului să analizăm peste un exemplu practic. În acest mod ne va fi mult mai simplu și ușor să înțelegem ce se întâmplă cu adevărat.
Vom porni de la următoarea problemă. Avem sute de fișiere ce conțin date despre numărul de accidente din fiecare județ din România care s-au întâmplat în fiecare lună. Am ajuns la un număr foarte mare deoarece există nenumărate firme de asi-gurare, iar fiecare firmă de asigurare are una sau mai multe centre regionale. Din această cauză fiecare fișier poate să conțină mai multe date despre același oraș. Un fișier ar putea avea următoarea formă:
Cluj, Ianuarie 2013, 20
Sibiu, Ianuarie 2013, 10Brașov, Ianuarie 2013, 3București, Ianuarie 2013, 100Cluj, Mai 2013, 50Brașov, Iulie 2013, 18 …Se cere să calculăm numărul maxim
de accidente care a avut loc în fiecare oraș în decursul unei luni. Această problemă devine destul de greu de rezolvat dacă avem 500 GB de date. În acest caz, Hadoop ne poate ajuta.
Prima operație pe care MapReduce o face este cea de Map. În acest moment din fiecare fișier vom putea obține o colecție de tip (cheie, valoare). Pentru noi cheia va reprezinta orașul, iar valoarea va indica numărul de accidente. Din fiecare fișier dorim să extragem numărul maxim de accidente per oraș. Pentru exemplul dat mai sus rezultatul pe care l-am putea obține ar avea următoarea formă
(Cluj, 50)(Sibiu, 10)(Brașov, 18)(București, 100)Din alte fișiere vom obține și alte date.
Dacă punem toate aceste date împreună (operația de shuffle) am avea următorul rezultat intermediar
Peste acest rezultat intermediar putem să aplicăm operația de Reduce, care ar genera rezultatul final – numărul maxim de accidente din fiecare oraș. La final obținem următorul rezultat
(Cluj, 50)(Brașov, 20)(Sibiu, 10)(București, 100)
ConcluzieD up ă c um am putut obs er va ,
MapReduce este o operație simplă, care se bazează pe împărțirea unui task în operații cât mai mici care să poată să fie rulate în paralel. Odată ce fiecare operație a fost executată pe o parte din date, rezultatele intermediare obținute sunt aduse în forma finală. Limbajul nativ pentru Hadoop este Java, dar există suport pentru folosirea sa împreună cu alte limbaje precum Python, C# și chiar și PHP.
Dar, să începem lent, cu începutul. Primul lucru pe care-l vom menționa că, spre deosebire de C, Java și alte limbaje similare, tipurile nu sunt o pacoste: descri-erea lor este opțională. Puteți scrie foarte mult cod fără a scrie o singură definiție de tip. Compilatorul și interpretorul vor apela la modulul de sinteză de tip pentru a infera tipurile cele mai generale pentru codul scris. Pe de altă parte, este bine să cunoaștem tipurile expresiilor și să pro-gramăm folosindu-ne de aceste informații, după cum se va vedea în continuare.
Cel mai simplu tip este cel al expre-siilor booleene, True și False. Atenție! Aceste valori se scriu cu literă mare și vom vedea în acest articol de ce. Tipul acestor două valori este Bool. Ca o regulă, tipu-rile în Haskell se scriu cu literă mare. Este o convenție cu o anumită logică pe care o vom vedea imediat.
Mergem acum la tipurile numerice. Pentru început, numerele întregi. Aici avem un lucru interesant. Valoarea 7 poate fi de tip Int sau de tip Integer. Diferența între ele este de nivel semantic/implemen-tare: tipul Int este limitat de registrele și arhitectura sistemului în timp ce tipul Integer presupune folosirea bibliotecii pentru numere de înaltă precizie – se vor putea reprezenta numere oricât de mari.
Pentru numerele reale, avem tipurile Float și Double, exact ca în C.
Poate vă întrebați acum cum se face conversia între Int și Integer. Să zicem că aveți o funcție f ce primește un argu-ment de tip Int și aveți o expresie x de tip Integer. Nu veți putea realiza direct apelul f x deoarece cele două tipuri nu se potri-vesc și compilatorul va arunca o eroare. Din fericire, există funcția toInteger ce va realiza conversia argumentului la un rezultat de tip Integer. Așadar, apelul va fi f (toInteger x) sau, dacă vrem să eliminăm ceva paranteze folosind operatorul $, vom ajunge la apelul f $ toInteger x.
Este foarte probabil ca acum tipărirea statică să vi se pară problematică și greu de folosit. Este necesară puțină experiență cu limbajul până când vă veți obișnui cu aceste mici inconveniențe și veți observa de ce sunt ele necesare și cum vă pot scuti de multe erori.
În continuare, vom analiza tipuri mai complexe. După cum ați citit și în artico-lul trecut, există tipul listă de elemente de tip a, [a]. Observați că tipul este scris cu literă mică, avem de fapt o variabilă de tip ce poate fi instanțiată pentru fiecare caz particular. De exemplu, lista [1,2,3] este de tipul [Integer] (notația pentru această frază fiind [1,2,3] :: [Integer]). Revenind la
Articolul din numărul trecut a realizat o scurtă introducere în limbaj prezentând mai mult istoria și beneficiile lui și mult mai puțin elemente de cod propriu-zis. Astăzi, ne apropiem de acest deziderat discutând despre tipurile limbajului. Un
lucru absolut definitoriu pentru limbaj este faptul că Haskell are tipare statică: fiecare expresie are un tip cunoscut de la compilare. În plus, nu există conversii implicite între tipuri similare: programatorul va trebui să facă explicit conversiile în locurile în care acestea sunt necesare.
programare programareProgramare Funcțională în Haskell (II)
notația tipului listă, [a], observăm imediat și restricția ca toate elementele unei liste să fie de același tip, a. În final, tipul standard al șirurilor de caractere, String, nu este altceva decât o listă de caractere (Char): [Char].
În final, ultimul tip de bază al limba-jului este tipul tuplu. Un tuplu de două elemente are tipul (a, b), un tuplu de 5 elemente are tipul (a, b, c, d, e). Observați imediat că fiecare element al tuplului poate avea un tip diferit. Astfel, putem avea atât (“ana”, “mere”) :: (String, String) cât și (“ana”, 42) :: (String, Integer). Ca un caz particular, există și tuplul cu zero elemente, (), având o singură valoare () :: ().
În final, cum orice expresie din Haskell are un tip, rezultă că putem vorbi și de un tip pentru o funcție. Acesta ne dă informații despre ce valori de intrare sunt acceptate și ce fel de valori sunt returnate. În unele cazuri, tipul funcției ne dă și deta-lii despre ce face funcția, funcționează ca o documentație. De exemplu, o funcție f :: a -> a ne zice ca primește un argument de orice tip și întoarce un rezultat de fix același tip. Dacă ne limităm la funcțiile care se ter-mină (excludem cazurile de forma f x = f x), nu dau eroare (fără f x = undefined sau f x = error ...) și nu sunt complicate inu-til (excludem și f x = head [x, f x, f (f x)]) obținem o singură expresie validă pentru f: funcția identitate. Așadar, pornind de la tipul acesteia putem deduce imediat ce semantică are, fără a ne uita în implemen-tare. Desigur, nu putem deduce totul din tipuri, cel puțin nu la nivelul celor prezen-tate până acum.
Cazul funcțiilor cu mai multe argu-mente este interesant de studiat. De exemplu, funcțiaaddBothWith2 x y = x + y + 2
are tipul Integer -> Integer -> Integer (de fapt, tipul real este puțin mai complex dar vom reveni asupra lui spre finalul arti-colului). Fiecare argument este separat de următorul în semnătura de tip prin ->. De ce această semnătură? Pentru a captura un aspect interesant al programării în Haskell: putem transmite funcțiilor un număr mai mic de argumente decât este cerut și obținem înapoi o funcție nouă. În teorie se zice că funcțiile în Haskell sunt curry (după numele lui Haskell Curry) și acest lucru este posibil doar pentru că funcțiile sunt valori de prim ordin (nu există nici o diferență între a-i trimite fucției identitate un număr sau o funcție, de exemplu).
Î n t o r c â n d u - n e l a f u n c ț i a addBothWith2 de mai sus observăm că
addBothWith2 3 are tipul Integer -> Integer. Așadar, Integer -> Integer -> Integer și Integer -> (Integer -> Integer) sunt expresii similare. Pe de altă parte, (Integer -> Integer) -> Integer reprezintă semnătura unei funcții ce primește ca argument o funcţie de la întreg la întreg și întoarce un rezultat. Un exemplu ar putea fi următoarea funcție:
applyTo42 f = f 42
pe care dacă o apelăm cu (+1) vom obține 43 iar dacă o apelăm cu (addBothWith2 3) vom obține 47.
Având toate aceste elemente putem scrie orice program dorim. Doar că dacă ne limităm doar la tipurile prezentate nu vom obține nici un beneficiu de pe urma tipării statice din Haskell, ba chiar vom avea și ceva probleme. De exemplu, există funcții predefinite doar pentru tuplurile cu două elemente. Pentru toate celelalte va trebui să scriem noi de mână funcții pen-tru accesarea și modificarea elementelor componente.
Din fericire, limbajul Haskell ne per-mite să ne construim tipuri proprii pentru a avea un program mai expresiv, mai decla-rativ. Le vom menționa pe toate în acest articol.
Pentru început, am afirmat mai sus că tipul String este de fapt un sinonim pen-tru tipul [Char]. Este mult mai usor de citit un cod care folosește [String] versus un cod care folosește [[Char]]. Idem, este mult mai comod să lucrați un program care are Vector2D, Point2D, Size față de un program care folosește (Integer, Integer) pentru toate trei valorile. În Haskell, putem declara orice sinonim de tip folosind type. De exemplu, tipul String este definit astfel:type String = [Char]
Compilatorul lucrează în spate cu tipul original. Doar anumite semnături de tip vor folosi sinonimul. Şi programatorul îl poate folosi oriunde în program.
Pentru a construi un tip nou folosim data. Tipurile noi în Haskell se definesc pe baza constructorilor: pur și simplu listăm fiecare constructor împreună cu argumen-tele necesare lui. De exemplu, următorul cod listează definiția exactă a tipului Bool.data Bool = True | False
Tipul are doi constructori, numiți True și False. De fapt, cei doi constructori sunt exact cele doi valori ale tipului. Putem enunța acum în întregime regula legată de capitalizarea atomilor din sintaxa Haskell, la nivelul valorilor (pentru nivelul tipuri-lor trebuie să mai introducem un concept):
toți constructorii unui tip se scriu cu literă mare și numai ei.
Un tip ceva mai complex este tipul Maybe. El ne permite să avem o valoare sau posibilitatea de a semnaliza faptul că funcția a ajuns într-un caz de eroare. Astfel, suntem salvați de la a obtine un null-poin-ter-exception la runtime: programatorul va trebui să trateze ambele cazuri în funcțiile scrise de el.data Maybe a= Just a | Nothing
Observați că tipul este generic: primește ca argument un alt tip sub forma variabilei de tip a. Unul dintre constructori folosește acest tip pentru a împacheta valoarea. Putem avea deci tipul Maybe Int sau tipul Maybe (Maybe String), fiecare cu seman-tica proprie.
Dezavantajul folosirii tipului Maybe este că în cazul în care funcția eșuează nu se poate salva și motivul eșecului. Din fericire, există și tipul Either, definit cadata Either a b= Right a| Left b
Despre aceste tipuri și cum le vom folosi într-un cod real vom mai discuta în viitor. Se poate întâmpla ca uneori numărul de câmpuri din constructor să fie foarte mare. Sau, se poate întâmpla să avem nevoie să accesăm anumite câmpuri din interiorul tipului. Din fericire, există o notație specială:data Person = P { nume :: String, prenume :: String, varsta :: Int}
Ca rezultat, nu numai că se creează tipul de date Person și constructorul P :: String -> String -> Int -> Person, dar avem acces și la funcțiile nume :: Person -> String, prenume :: Person -> String și varsta :: Person -> String.
Ca reprezentare internă, tipurile defi-nite cu data necesită zone de memorie pentru a salva valoarea constructorului și fiecare parametru în parte. Acest lucru este ineficient pentru cazul în care tipul are un singur constructor și acesta are un singur argument. Este cazul în care am putea folosi un sinonim de tip, dar am vrea să profităm în totalitate de inferența de tip (pe care o putem obține în întregime doar folosind tipuri cu constructori proprii). Din fericire, Haskell are și a treia metodă de a defini tipuri noi: folosim newtype.newtype State s a = S { runState :: s -> (s, a) }
Putem afla tipul oricărei expresii în ghci, folosind :t expresie. De exemplu:Prelude> :t map map :: (a -> b) -> [a] -> [b]
programare
43www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINEprogramare
De unde deducem imediat că map va aplica funcția pe o listă și va întoarce lista rezultatelor. Putem să mai aflăm tipul unei expresii consultând lambdabot pe #haskell (canal de IRCpe Freenode) sau via Hoogle1. De fapt, Hoogle ne ajută și în căutarea inversă: putem căuta după tipul aproxima-tiv al unei funcții, să zicem String -> Int -> Char și vom ajunge prin pagina de rezul-tate2 la (!!) :: [a] -> Int -> a, funcția care ne întoarce elementul de pe o anumită poziție din listă.
Ca exercițiu pentru astăzi, vom simula un program de manipulat baze de date. Momentan vor realiza doar o căutare în una din cele trei tabele ce reprezintă informații despre oameni. Începem prin a defini câteva sinonime de tip, pentru a înțelege codul mai ușor:type Name = Stringtype Age = Inttype Address = Stringtype PhoneNumber = Integer
Definim acum tipurile pentru cele trei tabele de intrare:newtype NameAgeTable = NAgT [(Name, Age)] deriving Shownewtype NameAddressTable = NAdT [(Name, Address)] deriving Shownewtype NamePhoneTable = NPT [(Name, PhoneNumber)] deriving Show
Am folosit newtype și tupluri pentru eficiența reprezentării și pentru a avea inferență de tipuri. Partea deriving Show este necesară pentru a putea afișa valorile de aceste tipuri (o vom prezenta în amă-nunt data viitoare).
Să construim acum câteva valori pen-tru cele trei tabele pe care le folosim:
După cum observați, am avea nevoie 1 http://www.haskell.org/hoogle/2 h t t p : / / w w w . h a s k e l l . o r g /
hoogle/?hoogle=String+-%3E+Int+-%3E+Char
de o funcție de căutat în listele respective: căutăm perechea al cărei prim element este un nume dorit și ne interesează al doilea element al perechii. Desigur, am putea să scriem noi o funcție recursivă pentru aceasta dar este un exercițiu interesant să folosim Hoogle. Dacă am căuta o funcție [(String, a)] -> String -> Maybe a nu vom găsi nici un rezultat (am generalizat doar tipul celui de-al doilea element din tuplu). În schimb, dacă vom generaliza ambii para-metri și vom căuta [(a, b)] -> a -> Maybe b primul rezultat din listă este funcția lookup 3(ignorați momentan partea Eq a => din semnătură, o vom trata tot data viitoare).
Putem scrie acum imediat funcțiile de căutat în cele trei tabele:
searchNameAge name (NAgT l) = lookup name l searchNameAddress name (NAdT l) = lookup name l searchNamePhone name (NPT l) = lookup name l
După cum observați, în partea dreaptă a egalului am folosit exact aceeași expresie. Vom vedea data viitoare cum se realizează apelul potrivit, conversia potrivită pentru tipul așteptat și cum putem reduce codul și mai mult, fiind fideli principiului DRY (don’t repeat yourself).
Pentru astăzi, ne mai rămâne doar să testăm funcțiile scrise. Pentru început, priviți cum compilatorul ne anunță imediat ce folosim o tabelă nepotrivită:
*Main> searchNameAge „Ion” nameAd-dress <interactive>:21:21: Couldn’t match expected type `NameAgeTable’ with actual type `NameAddressTable’
In the second argument of `search-NameAge’, 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
Vom continua data viitoare aplicația pentru a realiza și operații de tip join pe aceste tabele.
După cum vedeți, folosirea tipurilor ne ajută dar ne și încurcă. Depinde foarte mult de programator să aleagă varianta corectă de design. După ce tipurile au fost puse în scenă, compilatorul devine mai mult sau mai puțin (în funcție de design) un aliat și ne ajută să avem cât mai puține bug-uri la runtime.
Data viitoare ne vom ocupa tot de tipuri dar dintr-o perspectivă mai interesantă: vom vedea cum este implementat poli-morfismul și cum putem captura șabloane comune la nivelul tipurilor.
44 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
QA
Ce este testarea de performanţă și de ce avem nevoie de ea?
Definiţia ISTQB pentru Testarea de Performanţă este “procesul de testare prin care se determină performanţa unui produs”. Cu alte cuvinte scopul nostru este de a afla cât de bun este un produs software, cât de rapid, câţi useri poate să susţină precum și timpul de răspuns pentru fiecare dintre ei, sau care sunt limitele produsului.
Rezultatele obţinute în urma testelor de performanţă vor ajuta factorii de decizie din Business să ia o decizie informată cu privire la lansarea unui produs.
Testarea de performanţă va oferi infor-maţii despre cum se va comporta produsul în utilizarea zilnică, cu acces concurent din partea utilizatorilor. Rezultatele vor folosi în estimarea resurselor hardware nece-sare pentru a susține un anumit număr de utilizatori.
Există câteva categorii de Teste de Performanţă, fiecare având particularităţi în ceea ce privește scopul, planificarea și execuţia:
• Load – al cărui scop este de a vedea comportamentul sistemului când un anumit număr de utilizatori îl folosește simultan• Stress – al cărui scop este de a deter-
mina limitele și robusteţea sistemului • Soak – al cărui scop este de a deter-
mina comportamentul sistemului pe o perioadă mai mare timp în care un anu-mit număr de utilizatori îl folosește
Cum planificăm Testarea de Performanţă?
Ca orice fel de testare, Testarea de Performanţă trebuie planificată cu grijă. Cerinţele, resursele necesare, crearea sce-nariilor și rularea lor, colectarea și analiza rezultatelor, raportarea rezultatelor, tool-urile necesare sunt câteva dintre artefactele de luat în considerare.
Planificarea Testării de Performanţă se
poate face într-un document separat sau într-un capitol ca parte a Test Plan-ului proiectului.
De obicei se iau în considerare urmă-toarele aspecte în planificarea Testării de Performanţă:
CerinţeleEste cel mai important aspect alături de
tehnologia folosită în dezvoltarea produsu-lui. Necesarul de tool-uri este de asemenea determinat pe baza cerinţelor și a tehnolo-giei folosite. Cerinţele Non-funcționale vor conţine cifrele exacte pentru timpul de răs-puns, număr de acţiuni concurente.
Resursele umane necesareSkill-urile necesare pentru designul,
scrierea și executarea testelor de perfor-manţă trebuie analizate cu grijă. Consider Testarea de Performanţă ca un efort de echipa în care trebuie sa fie implicaţi arhitecţii și programatorii. Expertiza arhi-tecţilor în arhitectura produsului este de folos în design-ultestelor care vor desco-peri vulnerabilităţile sistemului, pe când expertiza developerilor este folositoare în scrierea script-urilor. De asemenea trebuie să participe în analiza rezultatelor pentru o mai bună înţelegere a comportamentului sistemului și a acţiunilor coercitive ?.
Design-ultestelor și execuţia lorA. Testele de performanţă sunt conce-
pute să acopere cerinţele non-funcționale cu scenarii reflectând situaţii reale. Scenariile folosite de mine au ca părți componente importante următoarele:
a. Ramp-up – este timpul necesar ca toți utilizatorii să fie gata pentru a exe-cuta acţiunile testului (de exemplu să fie logati și să înceapă să ruleze acţiunile)
b. Distribuţia încărcării și a acţiunilor în timp – scenariile apropiate de realitate vor fi create având în vedere tipurile de utilizatori ai aplicaţiei și acţiunile pe care le pot face fiecare dintre ei
c. Ramp-down – este timpul nece-sar utilizatorilor să termine acţiunile și încărcarea serverului să înceteze
B. Momentul rulării testelor de perfor-manţă în timpul dezvoltării produsului este important. Rularea testelor de performanță e bine să fie făcută când majoritatea func-ţionalităţilor sunt implementate și sunt stabile (un procent de 80% minim). Dacă funcţionalitatea nu este finalizată în mare parte, rezultatele testelor pot fi irelevante. Orice schimbare majoră a codului va afecta rezultatele testelor de performanţă și com-pararea rezultatelor rulărilor succesive a testelor de performanţă nu va putea fi făcută. Se pot rula teste de performanţă pe funcţionalităţi separate sau servicii atunci când acea funcţionalitate se poate testa independent. Astfel, rezultatele oferă un feedback continuu și relevant asupra per-formanţei sistemului. E bine să se planifice testarea de performanţă în mod continuu, mai ales în contextul Agile, când se livrează funcţionalitate completă în fiecare Sprint sau un număr relative mic de Sprint-uri.
În timpul unui release, testele de per-formanţă se rulează de un număr limitat de ori datorită timpului necesar rulării lor și resurselor hardware necesare. Rularea testelor, analiza rezultatelor și fixurile sunt realizate într-un ciclu iterativ.
O altă abordare în obținerea informa-ţiilor despre performanţa unui sistem este de a adăuga listener-i în Unit test și în tes-tele de API. Astfel se vor obține informaţii despre cât de performante sunt anumite metode/fluxuri.
C. Colectarea rezultatelor și raportareaSetul de rezultate colectate în cursul
testelor de performanţă trebuie definit cu grijă și să fie minimalist pentru
• a colecta rezultatele relevante. Tool-urile pentru teste de performanţă oferă o larga varietate de rezultate ce pot fi colec-tate în special în ceea ce privește timpul
În acest articol aș dori să vă prezint o scurtă introducere în planificarea Testării de Performanţă, precum și în planificărea colec-tării și analizării rezultatelor prin prisma experienţei mele în acest domeniu. Voi porni de la prezumţia că cititorul are cunoștinţe despre terminologia folosită în Testarea de Performanţă. În cadrul articolului voi face referire la unele metrici folosite, cerinţe
Non-funcţionale pe care le voi folosi ca exemple.
Planificarea Testării de Performanţă
programare
45www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINEprogramare
de răspuns. Resursele hardware pot fi monitorizate prin intermediul acestor tool-uri sau instalând tool-uri de moni-torizare direct pe sistemul aflat în test• a nu colecta prea multe rezultate.
Colectarea prea multor rezultate va avea impact atât asupra mașinii pe care rulează tool-ul de testare, consumând din resursele necesare susţinerii load-ului cât și a resurselor de pe sistemul aflat în test afectând numărul de acţiuni executate
Voi prezenta o lista cu rezultatele pe care obișnuiesc să le colectez:
• Timpul de răspuns. Analizând timpii de răspuns se pot observa spre exemplu peak-urile, care pot fi corelate cu gradul de utilizare a resurselor hardware ale sis-temului aflat în teste
• Timpul de răspuns minim și maxim• Timpul de răspuns mediu. Pe
lângă timpul de răspuns mediu este relevant să se vadă câte acţiuni au fost realizate în mai puţin timp sau mai mult decât timpul mediu de răspuns. Este important câţi timpi de răspuns au fost foarte lungi. Procentele (90, 95, 99) sunt folosite pentru a afla numărul de acţiuni ale căror timp de răspuns au fost 90%, 95%, 99% cele mai încete pe o scara de la cel mai mic la cel mai mare timp de răspuns• Throughput: câte acţiuni concurente
poate să susţină sistemul. Acest rezultat este important și ajută în determina-rea resurselor hardware ale sistemul de
producţie• Erori: rata de eroare va arăta câte
acţiuni și din ce cauza nu s-au înche-iat cu succes. Analiza erorilor va releva dacă sistemul nu poate susţine o anumită încărcare și dă time-out.• Consumul resurselor hardware
(CPU, memorie, disk, retea). Load-ul tre-buie făcut până la un consum de 85% din resursele hardware ale sistemului testat astfel încât să se poată interveni și opri testul de performanţă înainte ca sistemul să devine inoperabil.
D. Raportarea: Rapoartele testelor de performanţă vor prezenta eficienţa sistemu-lui cu privire la cerinţele Non-funcţionale.
Următoarele detalii, dar nu și singurele, sunt parte ale raportului asupra testelor de performanţă:
a. Detaliile legate de sistemul testat, IP, detalii despre hardware-ul folosit, Sistemul de Operare, topologia de reţea, build-ul folosit, data;
b. Scenariile rulate și scopul fiecăruia dintre ele;
c. Tool-urile de performanţă folosite;d. Măsurătorile efective.
Tool-uriAlegerea tool-urilor folosite pentru
testarea de performanţă va avea în vedere următoarele criterii:
a. Suportul oferit în rularea scenariilor complexe;
b. Capacitatea de distribuire a incărcării și profilurilor utilizatorilor;
c. Rapoartele oferite.
Evaluarea tool-urilor gratuite sau ale celor oferite de producătorii de tool-uri de performanţă trebuie făcută având în vedere contextul proiectului și a cunoștinţelor existente în echipa. Pentru anumite tool-uri va fi nevoie de cunoștinţe de programare pentru a rula scenarii complexe (cum ar fi JMeter), pe când alte tool-uri (cum ar fi LoadRunner) oferă aceasta funcţionalitate.
ConcluziiVoi prezenta câteva concluzii din expe-
rienţa mea utile unei planificari cât mai eficientă a testării de performanţă:
• Planificarea și execuţia testării de performanţă ar trebui să fie un efort comun al echipei de proiect incluzând software arhitecţi și developeri.• Importanţa capabilităţilor tool-uri-
lor și a skill-urilor necesare nu trebuie neglijată
Deși foarte populară ca temă, apli-caţia Hyperbola prezentată în această carte, este, practic, transpunerea utilizând Eclipse RCP a unui serviciu de mesagerie, cu funcționalităţi clasice: stabilirea unui grup de prieteni, comunicarea propriu zisă între ei, history și multe altele. Aplicaţia se constituie ca un model de aplicaţie ce folosește RCP, dar și ca sursa de inspiraţie pentru părţi componente ale unor alte apli-caţii RCP. Pe lângă implementarea propriu zisă penultimul capitol al cărţii prezintă și o modalitate de structurare, împachetare și livrare a aplicaţiei, astfel încât să putem crea sisteme dinamice ce rulează pe o mare varietate de sisteme de operare.
Am început destul de abrupt prezen-tarea cărţii Eclipse Rich Client Platform, având ca autori pe Jeff McAffer, Jean-Michel Lemieux și Chris Aniszczyk, în dorinţa de a atrage cât mai mulţi cititori. Pe lângă stârnirea interesului pentru tehno-logia prezentată, cartea aduce și plusul de aplicabilitate și înţelegere imediate.
Clienţii rich (sau fat) pot fi destul de mult asemănaţi cu aplicaţiile stand alone, ce folosesc în comun resurse la distanţă (spre exemplu baze de date). Ei se deose-besc de clienţii thin (care au drept client browser-ul) prin aceea ca folosesc puter-nic resursele hard și soft ale calculatorului
client pe lângă, eventual, resurse accesate de la distanţă.
Probabil cea mai mare problemă în cazul clienţilor thin era dată de faptul că instalările și modificările trebuiau să ţină cont de configuraţia hard a calculatorului pe care rula aplicaţia. Cum știm foarte bine că numărul acestor configuraţii este foarte mare, dificultăţile erau o provocare greu de rezolvat. Totuși existau și multe avan-taje, printre acestea: posibilitatea de a lucra offline (fără o conexiune permanentă la o reţea) sau performanţe multimedia sporite.
După părerea mea acest gen de clienţi a fost foarte greu de dezvoltat cu calităţi arhitecturale bune, până la apariţia fra-mework-urilor. Framework-urile au venit în sprijinul dezvoltatorilor de soft oferind cadre de dezvoltare ce urmăreau cele mai bune practici. Evoluţia tehnologică a dus apoi la apariţia platformelor, care erau colecţii de framework-uri precum și de arhitecturi hard ce permiteau soft-ului să ruleze.
Primele platforme rich client ofereau doar atât: o posibilitate de rulare a logicii unei aplicaţii într-un sistem de operare. Astăzi platformele oferă mult mai mult: un model de componentă numit și plu-gin (ușor de gestionat, updatat, integrat etc), un middleware deasupra acestor
Cartea pe care v-o supun atenţiei face parte din acea serie de cărţi care au un impact imediat asupra cititorului. Accentul este pus pe latura practică. Conceptele teo-retice sunt introduse gradual, de la noţiuni cu caracter general până la lucruri
de fineţe și best practices,dar particularitatea cărţii constăînfaptul că ele sunt integrate imediatîntr-o aplicaţie care are numeroase funcţionalităţi și care este, la rândul ei, dez-voltată treptat pe tot parcursul materialului. Din acest motiv, timpul scurs în prezentarea conceptului teoretic, implementarea și evidenţierea utilităţii sale se scurtează semnifica-tiv. Astfel, nu mai suntem pușiînsituaţia de a citi despre un concept, pe care îl înţelegem mai mult sau mai puţin, apoi o aplicaţie relativ dummy ce îl implementează și după mult timp, dacă există, o aplicaţie ce integrează conceptele abordate.
componente (ce permite extensibilitate, flexibilitate, scalabilitate, update-uri etc.), au portabilitate la rulare (de la PC-uri până la dispozitive mobile și nu numai), posedă instrumente de dezvoltare asistată, au posibilitate de instalare inteligentă și multe altele.
În această carte este prezentată ver-siunea Eclipse 3.5 (Galileo) a platformei. Aceasta nu este ultima versiune de Eclipse, dar cuprinde o serie de îmbunătăţiri remarcabile faţă de versiunile anterioare. Ultima versiune este Eclipse 4 (Juno) apă-rută în iunie 2012. Doresc să fac unele specificări referitor noutățile din Eclipse 4 și să precizez că întreaga tehnologie prezentată în carte merită toată atenţia. Eclipse 4 se bazează foarte mult pe ver-siunile anterioare și o bună înţelegere a acestora va conduce la bune rezultate în dezvoltarea aplicaţiilor. Așadar, în Eclipse 4:
• aplicaţia este descrisă pe baza unei structuri numită modelul aplicaţiei;• acest model poate fi modificat la
dezvoltare sau la rulare. Modelul poate fi apoi extins;• există suport pentru adnotări și
dependency injection cu importante implicaţii în ceea ce privește folosirea unităţilor de testare;• widget-urile Eclipse pot fi stilizate
folosind fișiere CSS, ca în cazul pagini-lor web;• modelul aplicaţiei este decuplat
de prezentare ceea ce ne permite, ca la
nivelul interfeţei utilizator, să putem folosi toolkit-uri precum SWT sau JavaFX p e n t r u r e n d e r i z a r e a modelului.
Lucrarea este structu-rată în trei mari părți. Prima zonă cuprinde o introducere în RCP cu funcționalităţi elementare (logare, key bin-ding, meniu) dar și elemente mai complexe (help, uptate). Partea a doua aduce detali-ile de implementare (despre perspective, view-uri, editori, acţiuni, comenzi, plugin-uri dinamice, testare) necesare obţinerii performanţei data de: rafinarea și refactorizarea prototipului obţinut ante-rior, customizarea interfeţei utilizator precum și constru-irea și livrarea produsului către utilizator. Partea a treia
este a referinţelor. Aici se face o trecere în revistă a specificaţiilor framework-ului OSGi, a framework-ului Eclipse databin-ding precum și a altor plugin-uri folositoare pentru dezvoltarea aplicaţiilor RCP.
Framework-ul OSGi este descris amă-nunţit într-o altă lucrare – OSGi în Action, a cărei recenzie o găsiţi în numărul 9 al revistei Today Software Magazine.
Nu în ultimul rând este interesant de arătat cui i se adresează această carte. Evident, în primul rând, celor care dez-voltă aplicaţii RCP. Chiar dacă sunt programatori cu experienţă în utilizarea acestei tehnologii, parcurgerea cărţii este foarte utilă. Pe lângă evidenţierea arhitec-turii de succes a unei aplicaţii bine puse la punct, se fundamentează și detaliază numeroase concepte teoretice. În al doilea rând, celor care doresc să aplice principiile rich client-ului în dezvoltarea RIA (Rich Internet Applications). Experienţa dobân-dită la nivelul unui rich client este foarte utilă pentru aplicaţiile Rich Internet.
Desigur, cunoașterea limbajului Java pe platforma standard este absolut nece-sară, iar unele deprinderi de folosire a IDE-ului Eclipse sunt, de asemenea, bine-venite. Cred că orice persoană dornică să înveţe sau să se perfecteze în folosirea RCP găsește în această carte un suport de preţ.
Personal, cred că evoluţia platformei Eclipse RCP este senzaţională și va con-tinua. Introducerea pattern-ului MVC, folosirea OSGi-ului, internaţionalizarea, adnotările și dependency injection sunt
doar câteva exemple dintre progresele remarcabile făcute de această platformă. Deși conţine numeroase ghidaje lucrul într-o astfel de platformă necesită cunoș-tinţe vaste și bine înţelese pentru a putea obţine cu adevărat performanţă.
Vă aștept, ca de obicei, cu toată plăce-rea și interesul, pentru discuţii legate de acest subiect.
Lectură plăcută!Silviu Dumitrescu
business
48 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
Teoria (bună ca întotdeauna)În compararea oricăror două entități
se utilizează de obicei criterii de evaluare comune. În acest caz vom vedea cum pot fi caracterizate celedouă metode de lucru în funcție de: modul lor de a se adapta la schimbările continue ale cerințelor inițiale ale unui proiect, capacitatea de respectare a termenelor de livrare, calitatea produsului livrat și predictibilitatea evoluției proiectu-lui pe parcursul acestuia, atât sincronic cât și diacronic.
Așadar:1. Adaptabilitate – caracteristica funda-
mentală a metodologiei Agile este aceea că echipa care o utilizează poate face față cu ușurință schimbărilor constante de pe parcursul unui proiect. Includerea reprezentantului clientului în echipă per-mite ajustarea ușoară la noile lui cerințe și schimbarea rapidă a priorităților. În cazul metodologiei Waterfall schimbările pe parcursul proiectului sunt mai greu de inclus.
2. Termene de livrare – pentru o echipă care folosește metodologia Agile livrarea la timp nu este o preocupare. Produsul ar trebui să fie livrabil și stabil la finalul fiecărui sprint încheiat. În cazul utilizării metodologiei Waterfall, există
riscul amânării livrării dacă se descoperă defecte majore în ultima parte a perioa-dei de testare.
3. Calitatea produsului livrat – în cazul utilizării metodologiei Agile, cali-tatea produsului este crescută întrucât acesta a trecut prin mai multe faze de testare completă până la momentul livră-rii. O echipă care utilizează metodologia Waterfall acceptă riscul ca defecte majore să fie detectate într-o fază înaintată de testare. Costul necesitat în acest caz pen-tru remedieri poate fi destul de ridicat.
4. Predictibilitate – este unul din atuu-rile importante ale utilizării metodologiei Agile. Predictibilitatea este crescută sin-cronic, deoarece în orice moment al proiectului se știe ce funcționalități exis-tau la finalul sprint-ului anterior și, cu o precizie crescută, cele care vor fi adăugate pe parcursul sprint-ului curent. În cazul metodologiei Waterfall, predictibilitatea este crescută diacronic. Ea crește o dată cu apropierea finalului perioadei de tes-tare și depinde de întreaga succesiune de evenimente din cadrul proiectului de până atunci.
Tabelul de mai jos sintet izează informațiile prezentate în această primă
Articolul de față prezintă câteva din beneficiile utilizării metodologiei Agile în viața de zi cu zi în domeniul IT. Elementul de comparație este cea mai utilizată metodologie până pe la începutul anilor 2000, metodologia Waterfall, cea în care
mulți dintre noi au lucrat și continuă să lucreze.
Bogdan Nicule este un Manager IT cu o vastă experienţă internaţională. Şi-a început cariera în urmă cu 12 ani pe post de developer și a evoluat ca Team Leader, Project Manager, Department Manager, până la poziţii cu responsabilităţi executive. Este un constructor de echipe de succes. A coordonat proiecte în Asia de Sud-Est (Singapore, Malaysia), America de Nord (Canada) și Europa (România, Germania, Olanda, UK). Lucrează cu metodologia Agile din 2006, pe care a utilizat-o în diverse contexte și cu echipe de diferite mărimi.
49www.todaysoftmag.ro | nr. 12/Iunie, 2013
TODAY SOFTWARE MAGAZINE
parte.
Practica Voi prezenta în cele ce urmează trei
contexte de lucru în care am utilizat meto-dologia Agile.
Disciplina Americii de Norda. Locație: Toronto;b. Mărimea echipei: 150;c. Experiența membrilor echipei: foarte
experimentați, echipă existentă;d. Tipul proiectului: proiect în derulare;e. Calitatea livrării: excelentă.
Datorită implementării eficiente a metodologiei Agile la nivel de companie și a gradului înalt de cooperare între membrii echipei, coroborate cu o disciplină model și asigurarea unei activități de QA de cea mai înaltă clasă, acesta poate fi un exem-plu ideal pentru conferința a cărei temă centrală este Agile, ”Even mamooths can be agile”.Toate aspectele specific metodolo-giei (negocierea inițială, întâlnirile zilnice, pair programming) funcționau cu o precizie elvețiană. Prin urmare, modelul Agile este utilizabil la nivel de corporații și echipe cu un număr mare de membri.
ritatea junior, echipa nouă;d. Tipul proiectului: proiect existent,
rulat anterior în manieră Waterfalle. Calitatea livrării: excelentă.
În acest caz, aș putea spune că valoa-rea produsului livrat s-a datorat în cea mai mare parte disciplinei de care a dat dovadă echipa, entuziasmului specific vârstei (o medie de vârstă sub 30 de ani) și deschi-derii membrilor de a învăța și a pune în practică lucruri noi. Confirmarea valorii echipei și a produsului livrat s-a întâmplat într-un moment de decizie a continuării colaborării. Reprezentanții clientului au decis fără echivoc continuarea colaborării cu această echipă, care atunci a primit mai multe voturi de încredere din afara compa-niei decât dinăuntrul ei.
Variabila numită Contexta. Locație: Cluj și Germaniab. Mărimea echipei: 9c. Experiența membrilor echipei: toate
nivelurile, echipa nouăd. Tipul proiectului: proiect noue. Calitatea livrării: bună
Acesta este un exemplu în care tranziția de la metodologia folosită anterior spre Agile s-a făcut cu dificultate. Din această cauză, eficiența procesului de livrare a avut de suferit și valoarea produsului final a fost la nivel mediu. Câțiva dintre membrii echipei au făcut cu greu trecerea spre noua modalitate de lucru, iar disciplina a fost un capitol sensibil, nu foarte ușor de gestionat.
Tabelul de mai jos sintetizează
informațiile incluse în partea a doua a articolului.
ConcluzieLa întrebarea dacă metodologia Agile e
bună, răspunsul ar fi următorul: metodo-logia Agile e foarte bună, dar e alergică la context. Ține foarte mult de deschiderea echipei care utilizează Agile, disciplina ei, dorința reală de a învăța lucruri noi și de a le aplica.
Dacă ar fi să ne gândim la întrebarea clasică dacă metodologia Agile e mai bună față de Waterfall putem spune că aduce câteva beneficii însemnate față de Waterfall și că rezultatele oferite de fiecare țin mult de disciplina echipei care le utilizează.
Prin urmare, pentru lumea în continuă schimbare în care ne aflăm, o lume care vrea să aibă vizibilitate cât mai bună asu-pra lucrurilor, putem spune că metodologia Agile e mai potrivită prin claritatea și gra-dul de siguranță pe care le oferă.
50 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
Ce este codul?“În știința calculatoarelor, codul sursă
este orice colecție de instrucțiuni pentru cal-culator (posibil cu comentarii) scrise folosind un limbaj de calculator citibil de către om, de obicei ca și text. Codul sursă al unui program este conceput special pentru a facilita munca programatorilor, aceștia specificând acțiunile ce trebuie îndeplinite de un calculator, cel mai adesea prin cod sursă“ - Wikipedia
Iată niște căi posibile de a scrie cod sursă: shell scripting, SQL, C#, java, C, Python.
În paragraful de mai sus, am subliniat cuvântul “facilita“, pentru că reprezintă un concept cheie în a produce cod curat.
Dar ce este “cod curat“? Cod curat este codul care: se citește foarte ușor, e facil de schimbat, scoate la suprafață deciziile de design, e foarte bine protejat de o suită de teste, e plăcut de modelat și lista poate continua. Simplu spus, codul curat este cod foarte ușor de întreținut.
Programatorul care scrie cod curat, “facilitează“ munca altor programatori ce îl vor modifica.
Cum e codul în general?În practică, situația e foarte diferită
de cele descrise mai sus. Vedem cod care e o dezordine generală, care face foarte dificilă chiar și adăugarea unei mici funcționalități la sistem fără a fi nevoie de a petrece nenumărate ore de citit și rulat în debug printr-un teritoriu necunoscut.
Există nenumărate sisteme, în producție, care rulează pe milioane de linii de cod pe care nimeni nu vrea să le atingă de frică sau pentru că ar fi imposibil să genereze o contribuție pozitivă la business.
Iată câțiva dintre indicatorii care arată că avem de a face cu cod rău: nu există o separare clară a responsabilităților (clase, metode sau funcții imense), modularitate sărăcăcioasă (totul e interconectat), multe globale, teste rele sau în care nu putem avea încredere.
Toate aceste lucruri rele generează o datorie tehnică imensă.
“Datoria tehnică (cunoscută și sub numele de datoria design-ului sau datoria codului) este un neologism metaforic, ce se referă la eventualele consecințe ale unei arhitecturi sărăcăcioase sau care evoluează, și la dezvoltarea de software. Datoria poate fi considerată munca ce trebuie făcută îna-inte ca o sarcină să fie considerată completă“. - Wikipedia
Cu alte cuvinte, lăsând codul sursă într-o stare proastă (printre alte sarcini nelegate direct de codare), generăm datorie tehnică. De obicei, dobânda crește odată cu trecerea timpului, pe măsură ce codul “putrezește“ (ca să îl citez pe Robert C. Martin). Această continuă creștere a datoriei teh-nice rezultă într-o descreștere a calității produsului și o creștere a costului adăugă-rii de funcționalitate. Un mod simplu de a măsura calitatea unui produs este formula DRE (defect removal efficiency - eficiența de
Cod curat = bani în buzunar
Scriu acest articol, pentru că am văzut ecuația “cod murdar = bani pierduți” de prea multe ori. Articolul este scris atât pentru audiența tehnică, cât și pentru cea non-tehnică din industria IT. Voi face o introducere scurtă și la obiect despre codul
curat și cum influențează pozitiv aspectele financiare ale unui produs.
DRE = Cantitatea de defecte găsite la testing / (Cantitatea de defecte găsite la testing + Cantitatea de defecte găsite de useri)
Exemplu:DRE = 1 / (1 + 9) = 0.1 (10%) => DRE răuDRE = 9 / (9 + 1) = 0.9 (90%) => DRE bun
Capers Jones, un american specializat în metodologii pentru inginerie software, adesea asociate cu modelul pentru estima-rea costului punctajului unei funcții, afirmă următoarele despre cuantificarea concepte-lor legate de datoria tehnică:
“Există o măsurătoare mai veche, numită ‘costul calității’ care a fost folosită la cuantificarea datelor existente de ani buni. Unul dintre lucrurile pe care le-am măsu-rat la IBM, ITT și multe alte companii, este cât costa cu adevărat atingerea unor nivele ale calității. Dați-mi voie să vă dau niște numere din industrie ca exemplu. Costul mediu pentru a implementa un oarecare software în S.U.A., este de aprox. 1000$ per punct funcțional și, în timpul developmen-tului, este aprox. jumătate - 500$ per punct funcțional, reprezintă costul găsirii și repa-rării defectelor. Odată ce soft-ul este pus în producție, în primul an, companiile chel-tuiesc aprox. 200$ per punct funcțional ca să găsească și să repare defecte și, mai apoi, cheltui aprox. 250$ per punct funcțional ca
să adauge specificații și îmbunătățiri. După cinci ani, dacă au procedat corect, vor scădea la aprox. 50$ per punct funcțional la repara-rea de defecte, iar ce cheltuie pe îmbunătățiri, rămâne constant. Deci, dacă au procedat corect, costul din primul an pentru repa-rarea defectelor va scădea repede odată cu trecerea timpului. Pe de altă parte, dacă au făcut o mizerie, dacă nu au construit soft-ul bine și nu au fost atenți, vor cheltui 1200$ per punct funcțional pentru adăugarea de specificații noi și 600$ per punct funcțional pentru repararea defectelor înainte și 300$ după punerea lui în producție. Și în loc să scadă după cinci ani, costul va rămâne con-stant sau va crește. Deci, după cinci ani, pot ajunge să aibă un produs foarte rău, pe care cheltuiesc 350$ per punct funcțional, găsind și reparând defecte când ar fi trebuit deja să fi scăzut costul la 50$ per punct funcțional. De altfel, acest tip de informație - costul calității - este relativ bine cunoscut. [...] Cu cât aplicațiile sunt mai mari, procentajul de proiecte care sunt abandonate și nepuse în producție crește - la peste 10.000 de puncte funcționale, aprox. 35% dintre proiecte care sunt pornite, nu văd niciodată lumina zilei în producție. Cel mai des întâlnit motiv pentru care nu sunt puse în producție este pentru că au avut atât de multe defecte, încât nu au funcționat niciodată. Este o conexiune directă intre costul calității și exe-cutarea lucrurilor în mod greșit, sfârșind cu proiectele abandonate.“ - extrase dintr-un
interviu din 22 ianuarie 2013Conform celor spuse de Jones, datele ne
arată că suntem foarte predispuși să plătim de șapte ori mai mult pentru mentenanța unui produs scris greșit. Iată date financiare directe! Aceasta ar trebui să fie un indiciu major pentru atât cei care investesc, cât și pentru cei care scriu (codează) un produs.
Aceasta, bineînțeles, înseamnă că scri-ind soft de calitate este mai ieftin. Așadar, pentru că la temelia produselor software stă codul: cod curat = bani în buzunar!
Surse1. Int e r v iu c u C ap e r s Jon e s : ht tp : / /
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-discus-sion-on-technical-debt/
2. Formula DRE: http://qatest lab.com/knowledge-center/QA-Testing-Materials/what-is-defect-removal-eff iciency-in-software-testing/
3. Wikipedia
52 nr. 12/Iunie, 2013 | www.todaysoftmag.ro
- Pe-ăla mi l-am luat și eu. E un GPS simplu, ieftin și își face treaba, ți-l recomand.
Şefu’ apăruse fără știre în spatele lui Gogu. „Auch... m-a prins teleleu pe Google”. Îi trecu prin cap să răspundă cu o scuză, dar își dădu seama imediat cât de penibil ar fi fost. Plus că era prea interesat de detaliile tehnice ale GPS-ului. Le află imediat, Şefu’ îi dădu rapid toate informațiile.
- Da’ unde mergi?- Le-am promis părinților că merg cu toată familia la ei. Ne
vedem rar cu toții, 450 de km nu-s ușor de parcurs cu copilul. Își schimbă vocea și își maimuțări copilul: „Tati, mai avem mult? Când ajungem? Cât mai avem până la Buni? Taaati, m-am plicti-sit...” Şi mai e și mama – adică Buni - care vrea să știe exact la ce oră ajungem. Dacă întârziem, intră în panică, își închipuie catas-trofe și i se face rău; dacă ajungem mai repede, de ce-am ajuns înainte de ora programată, probabil am mers cu viteză prea mare. Nicicum nu e bine. Mi-e groază de drumul ăsta, Şefule...
- Stai măi Gogule, că nu e așa tragică situația. Totul se rezolvă ușor, ai nevoie doar de niște jaloane.
Gogu simți cum i se lasă un gol în stomac. Sigur că nu era tragică, dar în o mie de ani nu ar fi crezut și nu s-ar fi așteptat ca Şefu’ să râdă de el atunci când era necăjit cu adevărat. Şi acum când i se destăinuise sincer... Încercă să spună ceva, dar i se puse un nod în gât și nu putu decât să lase privirea în jos, dezarmat, trist și incredibil de dezamăgit. „Nu mă așteptam...” își spuse. Dintr-o dată totul luă dimensiuni apocaliptice, problema lui nu mai era doar o problemă de familie, ci o nenorocire de proporții, lipsa de înțelegere a Şefului deveni semnul clar al unei complicate conspirații împotriva sa...
- Gogule, alo, ești cu mine? Ce-ai pățit?Zâmbetul larg al lui Şefu’ îl lăsă perplex pe Gogu. Teoria
conspirației se disipă imediat lăsând locul unei singure nedume-riri majore:
- Nu înțeleg, Şefu’, ce e cu jaloanele. Că doar n-oi fi vrând să înfig țăruși din Cluj până în București...
Hă-hă-hă... Hai, măi Gogule, zău așa, e vorba de jaloanele din teoria managementului de proiect.Un element care marcheză un moment important în derularea unui proiect... îți dă o indicație asupra poziției tale în timp și îți permite să raportezi modul în care proiectul se încadrează în duratele estimate. Adică exact ce îți trebuie ție, măi Gogule, pentru drumul tău.
Fața lui Gogu nu denota nici strop de inteligență – Ba chiar e ușor tâmpă, gândi Şefu’ amuzat – așa că se grăbi să adauge: îți stabilești niște repere, localități importante pe drumul tău. Acelea vor fi jaloanele voastre. Calculezi cât timp îți trebuie pentru a ajunge de la unul la altul, astfel încât să știi – în funcție de ora la care plecați -, la ce oră vei ajunge la fiecare dintre ele. Dacă vor apărea întârzieri, vei ști imediat cum se reflectă acestea asupra orei de sosire. Copilului îi faci un desen și îi arăți de fiecare dată când atingeți un jalon. Îi dai sarcina să o informeze pe Buni și uite așa
ai doi stakeholderi la curent cu evoluția călătoriei voastre. Cum ți se pare?
Încet-încet fața lui Gogu se lumină iar Şefu’ răsuflă ușurat: Nu-ți stătea bine cu fața dinainte, Gogule. Se pare că acum lucru-rile s-au mai luminat puțin, ce zici?
Gogu în schimb îl ignoră total și se apucă să deseneze traseul. Se vedea că îi place ideea și deși desenul nu era tocmai conform cu realitatea, arăta cât de cât a traseul dintre Cluj și București. Estimă durata deplasării în funcție de viteză și drum... Se și vedea dând explicații docte fiului său și se bucura și la ideea comunicării „poziției” de către acesta către Buni. Ha! S-ar putea să nu fie chiar atât de rău pe cât își închipuise...
- Şefu’, ești mare! Cum aș putea să îți mulțumesc?- Credeam că nu mai întrebi! La începutul lunii viitoare trebuie
să facem un workshop pe teme de management de proiect; ții tu o prezentare despre jaloane?! Că acum te pricepi. De fapt de-asta venisem la tine, doar că atunci încă nu știam ce subiect să abor-dăm, mulțam și eu de idee...
![Page 1: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/1.jpg)
![Page 2: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/2.jpg)
![Page 3: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/3.jpg)
![Page 4: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/4.jpg)
![Page 5: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/5.jpg)
![Page 6: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/6.jpg)
![Page 7: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/7.jpg)
![Page 8: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/8.jpg)
![Page 9: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/9.jpg)
![Page 10: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/10.jpg)
![Page 11: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/11.jpg)
![Page 12: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/12.jpg)
![Page 13: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/13.jpg)
![Page 14: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/14.jpg)
![Page 15: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/15.jpg)
![Page 16: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/16.jpg)
![Page 17: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/17.jpg)
![Page 18: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/18.jpg)
![Page 19: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/19.jpg)
![Page 20: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/20.jpg)
![Page 21: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/21.jpg)
![Page 22: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/22.jpg)
![Page 23: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/23.jpg)
![Page 24: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/24.jpg)
![Page 25: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/25.jpg)
![Page 26: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/26.jpg)
![Page 27: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/27.jpg)
![Page 28: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/28.jpg)
![Page 29: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/29.jpg)
![Page 30: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/30.jpg)
![Page 31: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/31.jpg)
![Page 32: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/32.jpg)
![Page 33: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/33.jpg)
![Page 34: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/34.jpg)
![Page 35: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/35.jpg)
![Page 36: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/36.jpg)
![Page 37: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/37.jpg)
![Page 38: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/38.jpg)
![Page 39: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/39.jpg)
![Page 40: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/40.jpg)
![Page 41: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/41.jpg)
![Page 42: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/42.jpg)
![Page 43: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/43.jpg)
![Page 44: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/44.jpg)
![Page 45: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/45.jpg)
![Page 46: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/46.jpg)
![Page 47: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/47.jpg)
![Page 48: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/48.jpg)
![Page 49: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/49.jpg)
![Page 50: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/50.jpg)
![Page 51: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/51.jpg)
![Page 52: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/52.jpg)
![Page 53: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/53.jpg)
![Page 54: [Title will be auto-generated]](https://reader030.documente.net/reader030/viewer/2022020717/568c4fe21a28ab4916ad1328/html5/thumbnails/54.jpg)
