Numarul 20/februarie 2014 - Today Software Magazine

Nr. 20 • Februarie 2014 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

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

Craftsmanship si Lean Startup Cum să (nu) măsurăm latenţa

Interviu cu Radu Georgescu

Interviu cu Philipp Kandal

Interviu cu Alexandru Tulai

Metrici în Visual Studio 2013

Cum să (nu) măsurăm latenţa Thinking in Kanban Pitching în business reclama întreprinzătorilor de azi O privire de ansamblu asupra testării performanței aplicațiilor Desktop

Clusterul Cluj IT și Antreprenoriatul New business development analysis Multithreading în standardul C++11 (II) Startups: Evolso

6 Cluj Innovation Days 2014 Ovidiu Mățan

7 Interviu cu Philipp Kandal Ovidiu Mățan

9 Evolso Alin Stănescu

28 Restricted Boltzmann Machines Roland Szabo

30 Maven, The Definitive Guide Silviu Dumitrescu

31 Multithreading în standardul C++11 (II) Dumitrița Munteanu

11 O privire de ansamblu asupra testării performanței aplicațiilor Desktop Sorin Lungoci

15 Software Craftsmanship și Lean Startup Alexandru Bolboaca și Adrian Bolboacă

17 Vagrant pentru începători Carmen Frățilă

22 Startup marketing: provocări și repere Sorina Mone

24 Clusterul Cluj IT și Antreprenoriatul Daniel Homorodean

26 Interviu cu Radu Georgescu Ovidiu Mățan

34 Metrici în Visual Studio 2013 Radu Vunvulea

36 Cum să (nu) măsurăm latenţa Attila-Mihaly Balazs

39 Thinking in Kanban Püsök Orsolya

40 New business development analysis Ioana Matei

42 Pitching-ul în business: cum să vinzi în patru paşi simpli Ana-Loredana Pascaru

44 Gogu și velierul Simona Bonghez, Ph.D.

editorial

C

Ovidiu Măţan, PMP

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

uvântul innovation plasat pe coperta revistei anunță tema acestui număr, startups & innovation. Dar cuvântul a fost ales și pentru a marca simbolic intrarea într-o nouă etapă a IT-ului autohton, aceea a inovării. Dacă acum câțiva ani execuția și performanța erau printre cei mai vehiculați termeni, asistăm acum la un ascendent fără precedent în piața românească al termenului de inovație. Această nouă tendință reflectă o evoluție a mentalității antreprenorului român, care devine din ce în ce mai conștient de capacitatea sa de a se metamorfoza dintr-un executant într-un creator de produse. Asumarea noului statut trebuie să țină cont de o stare de fapt pe care sugestiv o sintetizează Radu Georgescu într-un interviu acordat la How To Web 2013: outsourcing înseamnă vânzarea de ore de lucru, iar produsul înseamnă să vinzi același produs de o mie de ori. Sfatul pe care acesta îl dă pentru firmele de outsourcing este să încerce să creeze mici echipe de dezvoltare a unor produse proprii.

Conceptul de inovare (eng. innovation) poate avea multe forme. O simplă căutare a acestui cuvânt pe site-ul revistei www.todaysoftmag.ro ne dă câteva dintre fațetele sale posibile: Innovation in Big projects, Inovarea în IT, proiect public-privat, conectarea tehnologiilor inovative la piața globală, Lead Six Sigma și managementul inovației. Acestea sunt doar câteva dintre abordările care dezvăluie totodată posibilitățiile nelimitate de referință ale acestui concept. Ca o completare menită să argumenteze materializarea spiritului inovativ menționată în rândurile de mai sus, realizăm o trecere în revistă a evenimentelor care au ca temă principală inovația: Startup Weekend Cluj - cel mai important eveniment local dedicat creării de noi startup-uri. Echipa desemnată câștigătoare în 2013 a fost Omnipaste aka Cloud Copy care se află în prezent în acceleratorul Deutsch Telekom Hub:raum; Startup Pirates - un eveniment nou ce oferă mentorat celor ce doresc să își creeze un startup; Cluj Innovation Days - organizat de Cluj IT Cluster își propune ca pe durata a două zile să ofere participanților trei sesiuni paralele de prezentări pe această temă; Innovation Labs 2.0 - este un hackaton organizat în București și în Cluj. Așadar vă invităm să luați și voi parte la aceste evenimente unde sperăm că vom vedea exprimate idei revoluționare care să aducă beneficii pieței românești.

Ediția de față a revistei vă propune o serie de interviuri cu Radu Georgescu, Philipp Kandal și Alexandru Tulai precum și detalii despre evenimentele prezentate mai sus. Începem primul articol tehnic al revistei pe tema testării și anume: O privire de ansamblu asupra testării performanței aplicațiilor Desktop, urmat de Craftsmanship si Lean Startup ce propune două posibile faze de dezvoltare ale unei aplicații din perspectiva unui antreprenor: descoperirea și implementarea. Vagrant este titlul unui alt articol cu tematică tehnică precum și denumirea unui tool puternic atunci când avem de-a face cu gestionarea mașinilor virtuale. Articolul din acest număr reprezintă o introducere precum și o privire de ansamblu a posibilitățiilor acestuia. Urmează o nouă serie de articole tehnice: Restricted Boltzmann Machines, recenzia cărții Maven, The Definitive Guide și Cum să (nu) măsurăm latenţa. Startup marketing: provocari si repere oferă câteva sfaturi tinerilor antreprenori despre cum ar trebui să fie făcut marketingul având resurse limitate.

Un alt articol dedicat startup-ului este cel cu titlul Clusterul Cluj IT și Antreprenoriatul care prezintă implicarea Cluster-ului în sprijinirea antreprenoriatului. Articolele dedicate managementului continuă cu Thinking in Kanban, New business development analysis’, Pitching în business - reclama întreprinzătorilor de azi. În încheiere, doresc să vă menționez că numărul 20 al Today Software Magazine marchează doi ani de existență a revistei. Mulțumim că ați fost alături de noi și vă promitem în continuare multe ediții cel puțin la fel de interesante !!!

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

Ovidiu Măţan

Fondator al Today Software Magazine

4

nr. 20/Februarie | www.todaysoftmag.ro

Redacţia Today Software Magazine Fondator / Editor în chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com Editor (startups și interviuri): Marius Mornea marius.mornea@todaysoftmag.com Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com

Lista autorilor Alexandru Bolboaca

Daniel Homorodean

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

Membru în Consiliul Director @ Cluj IT Cluster

Radu Vunvulea

Roland Szabo

Senior Software Engineer @iQuest

Junior Python Developer @ 3 Pillar Global

Attila-Mihaly Balazs

Sorina Mone

alex.bolboaca@mozaicworks.com

Radu.Vunvulea@iquestgroup.com

daniel.homorodean@clujit.ro

roland.szabo@3pillarglobal.com

Copyright/Corector: Emilia Toma emilia.toma@todaysoftmag.com Traducător: Roxana Elena roxana.elena@todaysoftmag.com

dify.ltd@gmail.com

Code Wrangler @ Udacity Trainer @ Tora Trading

Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com

Adrian Bolboaca

Software engineer @ Arobs

Programmer. Organizational and Technical Trainer and Coach @Mozaic Works

dumitrita.munteanu@arobs.com

Sorin Lungoci

Today Software Solutions SRL str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag ISSN 2284 – 6352

Marketing manager @ Fortech

Dumitrița Munteanu

Contabil : Delia Coman delia.coman@todaysoftmag.com Produs de

sorina.mone@fortech.ro

sorin.lungoci@isdc.eu

adrian.bolboaca@mozaicworks.com

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

Tester @ ISDC

Carmen Frățilă Ana-Loredana Pascaru

carmen.fratila@3pillarglobal.com

ana.pascaru1@genpact.com Training Manager @ Genpact

Software engineer @ 3Pillar Global

Alin Stănescu

Püsök Orsolya

Project manager @ Evolso

Functional Architect @ Evoline

Stanescu.Alin91@yahoo.com

Ioana Armean

ioana@ogradamea.ro Project Manager @ Ogradamea

pusok.orsolya@evoline.ro

Simona Bonghez, Ph.D.

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

Copyright Today Software Magazine Ovidiu Măţan, PMP

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

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

www.todaysoftmag.ro www.todaysoftmag.com

www.todaysoftmag.ro | nr. 20/Februarie, 2014

5

interviu

Cluj Innovation Days 2014

Î

n martie va avea loc cea de-a doua ediție a Cluj Innovation Days, evenimentul principal organizat de către Cluj IT Cluster.

Președintele cluster-ului, Alexandru Tulai, ne-a răspuns în exclusivitate la câteva întrebări.

Ovidiu Mățan: Cluj IT Cluster organizează în perioada 20 – 21 martie cea de-a doua ediție a evenimentului Cluj Innovation Days, găzduit de această dată de Universitatea de Ştiinţe Agricole şi Medicină Veterinară din Cluj-Napoca. De ce Cluj Innovation Days și nu Cluj IT Innovation Days, așa cum s-a numit conferința anul trecut?

Alexandru Tulai: Ediția din acest an a Cluj Innovation Days își propune prin tematică, invitați și structura evenimentului să coaguleze principalii actori la nivel național și internațional implicați în procesul inovării, factorii decizionali și persoanele interesate de schimbarea de paradigmă în mentalitate, business și educație, rezultată în urma orientării spre generarea de idei și produse inovative, cu valoare adăugată mare. Este și motivul pentru care evenimentul nostru, care dorim să devină în timp unul de referință, nu se mai numește Cluj IT Innovation Days. Nici locația în care va avea loc nu este întîmplătoare: dorim să subliniem și pe această cale importanța colaborării între mediul de cercetare și comunitatea de business.

Viziunea noastră asupra industriei de IT este una în care IT&C-ul devine o infrastructură indispensabilă pentru dezvoltare, prezentă în toate verticalele economiei și ale societății. Cluj Innovation Days este, în opinia mea, tipul de eveniment prin care putem contribui la consolidarea pe termen lung a comunității IT şi la dezvoltarea legăturilor cu parteneri de afaceri naționali și internaţionali.

6

Ce v-ați propus cu ediția din acest an Cluj Innovation Days?

Cluj Innovation Days este structurat în trei sesiuni tematice, și anume Mastering Innovation, Fostering Entrepreneurship și Showcasing Innovation, fiind organizat astfel pentru a surprinde cele trei apecte constitutive ale inovării. Prima sesiune tematică vizează inovarea într-un context mai general și urmărește aspecte legate de gestionarea inovării prin manangementul produsului inovativ și de proprietatea intelectuală sau de suportul obținut prin politicile și strategiile la nivel european. De asemenea sunt și alte aspecte precum cele legate de capacitatea de a implementa și susține procesele inovării. Cea de-a doua sesiune este orientată spre zona antreprenorială și își propune să prezinte auditoriului principalele mecanisme și etape în consolidarea și valorificarea unei idei inovative, prin trimitere directă la ingredientele startup-urilor, spin-off-urilor precum și forme de atragere a investițiilor și altor surse de finanțare disponibile. Ultima sesiune tematică, Showcasing Innovation, își propune să exemplifice toate mijloacele și mecanismele ce susțin inovația prin povești de succes din zona de business, menite să motiveze și să inspire tinerii în dezvoltarea unor inițiative antreprenoriale, dar și micile companii, aflate într-un stadiu incipient de dezvoltare.

Cine sunt participanții pe care îi așteptați la eveniment?

Pe durata celor două zile, evenimentul va reuni peste 400 de persoane, din țară și străinătate, printre care se numără

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

reprezentanți ai Comisiei Europene, ai Guvernului României și ai autorităților publice locale, oameni de business, reprezentanți ai mediului academic, ambasadori, membri ai altor clustere naționale și internaționale, dar și reprezentanți ai unor asociații de business, ai sectorului financiar-bancar și investitori străini. În calitate de invitați așteptăm și reprezentanți de la nivelul instituțiilor academice reprezentative precum universități, Academia Română și institute de cercetare. Prin numărul mare de participanți, dar mai ales prin natura preocupărilor acestora, putem aprecia că, pentru cele două zile, Clujul va deveni capitala regională a inovării.

Mai multe detalii despre evenimentul Cluj Innovation Days 2014 sunt disponibile pe site-ul web dedicat: www.clujinnovationdays.com

Ovidiu Măţan, PMP

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

TODAY SOFTWARE MAGAZINE

interviu

Interviu cu Philipp Kandal

Î

n ultimul timp am avut parte de o serie de achiziții ale companiilor locale. Este cazul EBS-ului achiziționat de către NTT Data, Kno de către Intel sau Evoline de către Accenture. Ultima tranzacție de acest fel a fost achiziționarea Skobbler către Telenav. Philipp Kandal, co-fondatorul Skobbler, a avut amabilitatea să ne răspundă la câteva întrebări.

Ovidiu Mățan: Phillip, felicitări pentru vânzarea Skobbler către Telenav.

Menționează trei puncte cheie care au făcut posibilă această tranzacție.

Philipp Kandal: Ne-am concentrat atenţia pe OpenStreetMap care este comparabilă cu o Wikipedia a hărţilor. Aceasta creşte într-un ritm foarte alert şi este pe cale să devină cea mai importantă hartă din lume. Suntem cea mai de succes companie din zonă şi de aceea Telenav a dorit să achiziţioneze Skobbler. Pe lângă tehnologia noastră puternică OpenStreet Map, calităţile principale pe care le-am dezvoltat sunt o puternică bază instalată de utilizatori (> 4 mil. utilizatori) şi posibilitatea unică de a fi accesaţi offline, care permite oamenilor să utilizeze produsele noastre offline, fără o conexiune la internet. Aşa că în final am obţinut o combinaţie între un produs grozav şi o tehnologie remarcabilă, elaborată de o echipă de talie mondială care a făcut posibilă această afacere.

Probabil cel mai important aspect pentru comunitatea locală de IT este modul în care va fi afectată echipa Skobbler pe termen scurt și lung Această tranzacţie a urmărit dublarea eforturilor noastre şi dezvoltarea echipelor şi produselor pe care le-am creat aici. Deci, evident, ne aşteptăm să creştem echipa în Cluj, iar, cu mai mult capital, să elaborăm produse şi mai remarcabile. Vom fi foarte agresivi cu promovarea produselor pe care le creăm şi introducerea lor pe piaţă şi ne vom extinde şi în alte regiuni noi.

Pe termen scurt, vom încerca să unificăm

brandurile Skobbler şi Telenav, dar cu siguranţă vom continua să ne concentrăm pe dezvoltarea unor produse extraordinare pentru clienţi pe viitor. Știm că ai condus echipa și din punct de vedere tehnic. Cum se va schimba aceasta, vei continua colaborarea cu Telenav?

Sunt foarte ataşat de ceea ce am construit, aşa că voi rămâne cu siguranţă Manager General al birourilor noastre din Cluj. Pe termen lung, voi vedea, dar toţi cei care mă cunosc ştiu că sunt un mare suporter al antreprenoriatului, deci asta este fără îndoială o cale pe care aş explora-o din nou şi între timp am posibilitatea acum să mai fac câteva investiţii în Cluj ;).

Ce vei face în continuare? O sa rămâi în zona de hărți și navigare sau o sa faci ceva total diferit?

Bună întrebare. După cum am spus, vreau să văd că produsele noastre ajung la zeci de milioane de utilizatori, aşa că în viitorul previzibil voi rămâne la Telenav. Dacă ar fi să încep ceva nou la un moment dat, cel mai probabil ar fi într-o zonă nouă, în afara hărţilor / navigaţiei, căci sunt interesat să explorez câteva domenii care au nevoie să fie regândite de la temelie, cu siguranţă nu aş face ceva ca să fiu doar încă unul în plus, ci doar ceva care ar putea fi revoluţionar.

Ai fost implicat în organizarea unor evenimente locale precum Startup Weekend și ai sponsorizat multe altele precum IT Days.

De asemenea ai ajutat startup-ul Squirrly.

Care sunt planurile tale în continuare?

Vei rămâne în Cluj pentru construi o altă afacere?

Cred cu adevărat că Clujul este un loc fantastic pentru antreprenori, aşa că, fără îndoială, voi rămâne în Cluj pentru mult timp. De fapt, chiar mă gândesc să cumpăr un apartament aici, aşa că vă puteţi aştepta să mă vedeţi pe aici pe termen lung. Sper ca noi toţi să putem face din acest loc unul cu adevărat competitiv pentru antreprenori şi să creăm nişte companii respectate pe plan internaţional şi sunt foarte dornic să ajut în acest proces în orice fel pot.

Ovidiu Măţan, PMP

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

www.todaysoftmag.ro | nr. 20/Februarie, 2014

7

startup weekend global

115+

556+

1200+ events

cities

countries

250

2012

2013

DESIGNERS

2012+2013 & more juicy facts...

average of 10 new ventures created

now

startup weekend cluj

historY

average of 93 attendees per event with a maximum of 150

4.8%

19.6%

41.6%

DEVELOPERS

NON TECH

WOMEN

MEN

53.6%

90.4%

ideas pitched:

articles about:

partners & media:

mentors:

jury:

59

95

40

28

19

teams formed:

energy drinks:

chocolate:

connected devices:

prizes value:

27

558

24kg

how about you write some

COME, PITCH, 8

FORM A TEAM & win!

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

580 history right now?

BUT DON'T FORGET

TO REGISTER

first!

15,800â‚Ź

startups

TODAY SOFTWARE MAGAZINE

Evolso

P

latforma evolso are mai multe componente tehnice: aplicaţia web, aplicaţia mobile, servicii REST. Aplicaţia Web se poate găsi pe adresa:http://evolso.com.Pe această adresa sunt afişate mai multe informaţii despre aplicaţie, despre cum se foloseşte aplicaţia/site-ul, precum și informaţii despre echipă şi evenimente. În acelaşi timp există o parte accesibilă doar partenerilor noştri, unde ei se loghează cu un cont şi pot vedea statistici legate de locaţiile lor (ex.: câte persoane au dat check-in, câte persoane participă la evenimente, etc.).

Aplicaţia mobile este creată pentru utilizatori şi este punctul principal al platformei. Noi am pornit pe Android, luând în considerare faptul că în România Androidul are o piaţă de desfacere mai mare, majoritatea utilizatorilor de telefoane au sistem de operare Android. Dar avem şi versiunea iOS care va fi lansată la sfârşitul acestei luni.

Aplicaţia se conectează la server prin servicii REST, iar răspunsul este în JSON. Iar unele informaţii sunt transmise prin Push Notification către device-uri. În spatele „magiei” se află o bază de date MongoDB. Am ales MongoDB pentru că e o bază de date NoSQL, e uşor de extins, foloseşte documente în stil JSON, e open-source şi suportă GeoLocation „out of the box”. MongoDB ne ajută să facem diferite „query”-uri pe baza de date legate

de locaţii, un criteriu important care se află la baza aplicaţiei evolso. Aici aş mai menţiona că toate procentajele între utilizatori sunt calculate real-time pe server, ceea ce înseamnă că MongoDB oferă o viteză extraordinară.

Dificultăţi tehnice am întâlnit în momentul când căutăm metode de a conecta doi utilizatori. Conectarea se putea rezolva prin mesaje, cu diferite frameworkuri sau implementarea noastră (pe care am ales-o într-un final), sau prin voce. Noi am vrut să implementăm VoIP din prima versiune să oferim un plus utilizatorilor noştri.

Pentru a oferi acest serviciu ne-am folosit de un framework oferit de Rebtel (http:// www.rebtel.com/). Acest framework este gratuit şi se poate implementa pe Android şi iOS. Alte probleme care au apărut pe parcurs este fragmentarea sistemelor de

operare. În aplicaţie apăreau diferite erori pe diferite versiuni de OS, din care majoritatea au fost eliminate. Obiectivul nostru rămâne îmbunătăţirea aplicaţiei.

Alin Stănescu

Stanescu.Alin91@yahoo.com Project manager @ Evolso

www.todaysoftmag.ro | nr. 20/Februarie, 2014

9

comunități

Comunităţi IT

F

ebruarie și martie sunt în general marcate de evenimente dedicate startup-urilor și inovației. Acum este momentul să plănuim ce vom face în restul anului și să primim validarea conceptelor din partea publicului și a mentorilor prezenți la evenimente.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

Website: www.transylvania-jug.org Data înfiinţării: 15.05.2008 / Nr. Membri: 563 / Nr. Evenimente: 43 Comunitatea TSM Comunitate construită în jurul revistei Today Software Magazine.

Website: www.facebook.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 1171/Nr. Evenimente: 16 Romanian Testing Community Comunitate dedicata testerilor.

Website: www.romaniatesting.ro Data înfiinţării: 10.05.2011 / Nr. Membri: 702 / Nr. Evenimente: 2 GeekMeet România Comunitate dedicată tehnologiilor web.

Website: geekmeet.ro Data înfiinţării: 10.06.2006 / Nr. Membri: 572 / Nr. Evenimente: 17 Cluj.rb Comunitate dedicată tehnologiilor Ruby.

Website: www.meetup.com/cluj-rb Data înfiinţării: 25.08.2010 / Nr. Membri: 170 / Nr. Evenimente: 40 The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software.

Website: www.agileworks.ro Data înfiinţării: 04.10.2010 / Nr. Membri: 396 / Nr. Evenimente: 55 Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice.

Website: www.meetup.com/Cluj-Semantic-WEB Data înfiinţării: 08.05.2010 / Nr. Membri: 152/ Nr. Evenimente: 23 Romanian Association for Better Software Comunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.

Website: www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 235/ Nr. Evenimente: 14 Tabăra de testare Un proiect care își dorește să strângă cât mai mulți oameni care lucrează ca și testeri.

Website: tabaradetestare.ro Data înfiinţării: 15.01.2012 / Nr. Membri: 1025/ Nr. Evenimente: 27

10

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

Calendar Februarie 13 (Cluj) Lansarea numărului 20 al Today Software Magazine www.facebook.com/todaysoftmag Februarie 15 (Cluj) Hacaton de programe libere, ediția a III-a ceata.org/evenimente/aniversarea-fundației-ceata-în-cluj Februarie 17 (Cluj) Question-Answering Systems meetup.com/Cluj-Semantic-WEB/events/150657862/ Februarie 20 (Cluj) Machine Learning in Python meetup.com/Cluj-py/events/165522292/ Februarie 22 (Timișoara) Meet the Vloggers it-events.ro/events/meet-vloggers Februarie 22 (București) Electronic Arts CodeWars it-events.ro/events/electronic-arts-codewars/ Februarie 22 (Iași) ISTC February 2014 Edition http://it-events.ro/events/istc-february-2014-edition/ Februarie 24 (Cluj) Mobile Monday Cluj #5 meetup.com/Cluj-Mobile-Developers/events/153087052/ Februarie 27 (București) Gemini Foundry Conf - recomandarea TSM www.gemsfoundry.com Februarie 28 (Cluj) Startup Weekend Cluj - recomandarea TSM cluj.startupweekend.org Martie 2 (Cluj) UBBots 2014 it-events.ro/events/ubbots-2014 Martie 20-21 (Cluj) Cluj Innovation Days - recomandarea TSM www.clujinnovationdays.com

testare

O privire de ansamblu asupra testării performanței aplicațiilor Desktop

P

erformanța aplicațiilor este un subiect frecvent abordat, indiferent de natura apreciativă sau critică a contextului.Această performanță este de obicei clasificată ca fiind una din primele trei coordonate de impact asupra reputației și veniturilor unei companii și de asemenea asupra satisfacției clientului.

Sorin Lungoci

sorin.lungoci@isdc.eu Tester @ ISDC

Am ales acest subiect deoarece testarea performanței unei soluții Desktop nu oferă o documentație extensivă pe internet sau un suport atât de bogat cum ne-am fi așteptat. Din acest motiv m-am gândit să împărtășesc nu doar din experiența proprie, dar și din cunoștințele altora exprimate în idei, orientări, preocupări sau riscuri de luat în considerare atunci când ni se cere să îndeplinim o astfel de sarcină.

Dacă vorbim de performanța unei aplicații, ar trebui să convenim încă de la început ce înțelegem prin “performanță”.

Vorbim de viteza de reacție a aplicației?

Resursele consumate? Altceva? În aplicațiile desktop aceasta poate avea diferite semnificații, pe care le voi explica în articolul de față.

Arhitectura

Din punct de vedere arhitectural există câteva stiluri de aplicații desktop. Layer-ele sunt în mare parte aceleași, dar așezarea lor sau interacțiunea dintre ele generează mai multe tipuri de aplicații desktop.

Printre cele mai utilizate layer-e amintim: UI (User Interface), BL (Business Layer), TL (Transfer Layer) and DB (Database Layer).

Voi menționa câteva exemple de arhitecturi folosite pe platforma desktop cu precizarea că nu acoperă toate combinațiile dintre tipurile și stilurile arhitecturale: 1. 100% pur desktop – unde atât clientul cât și serverul împreună cu baza de date sunt instalate pe aceeași mașină, fără a avea nevoie de conexiune la rețea. Un exemplu aici poate fi Microsoft Money (o aplicație de managementul finanțelor destinată utilizatorului casnic). Este o aplicație pe un singur nivel (1-Tier), instalată și rulată pe un singur sistem de către un singur user.

2. O altă soluție în arhitectura ClientServer este folosirea așa numitului “Thin Client”, care în acestă arhitectură (2-Tier) este folosit nu cu mult peste preluarea comenzilor utilizatorului și afișarea informațiilor prin intermediul unui monitor. Aplicația este copiată și instalată pe server, rulată la nivel de client, și folosită pe scară largă în infrastructurile de tip intranet ale universităților sau fabricilor.

Un exemplu putând fi un student care folosește un client CITRIX instalat pe mașina proprie și rulând o aplicație internă pe serverul universității.

3. Aplicația Client-Server care folosește mai mulți clienți de tip ‘Rich Client’ și unul sau mai multe Servere este cea mai întâlnită arhitectură pe platforma Desktop.

www.todaysoftmag.ro | nr. 20/Februarie, 2014

11

testare Această aplicație este desenată de asemenea pe două nivele (2-Tier) și utilizată cu precădere într-o infrastructură de tip intranet având un număr limitat de utilizatori. Conexiunea persistă până la log-out, iar aplicația este manipulată utilizând un meniu.

Un exemplu poate fi Microsoft Outlook sau oricare altă aplicație desktop pentru e-mail. Aplicația este instalată pe mașina locală, care se conectează din când în când sau permananet la server pentru primirea sau trimiterea email-urilor. Bineînțeles, această aplicație funcționează și fără conexiune la server, dar fără această conexiune nu se va putea duce la bun sfârșit operația de trimitere a unui e-mail.

Abordare

Testarea aplicațiilor client-server necesită câteva cunoștințe tehnice adiționale pentru a putea trata anumite efecte introduse de arhitectura client-server. De exemplu - separarea sau mutarea business layer-ului de pe client pe server ar putea crește încrederea și stabilitatea în datele oferite, dezavantajul fiind creșterea traficului pe rețea sau vulnerabilitatea în cazul unui atac de securitate.

Testarea acestor sisteme este într-adevar mai diferită comparativ cu testarea aplicatiilor web, dar această diferență nu este chiar atât de mare. Am putea chiar afirma că se apropie mai mult de testarea pe platforma mobile.

Ca să înțelegem cum putem testa aceste sisteme trebuie întâi să înțelegem exact când și de ce ar putea apărea aceste probleme de performanță. Având această înțelegere, soluția care ar trebui abordată în testare de multe ori este evidentă.

Testarea la nivel de client este mai mult percepută ca o testare funcțională. Acest lucru se întâmplă din cauză că aplicațiile desktop sunt concepute pentru a fi manipulate de un singur utilizator. Nu este adecvată abordarea testării performanței folosind abordarea specifică web. Dacă înregistrăm un flow după care folosim 100 de utilizatori virtuali cu scopul de a testa performanța întregului sistem, ne înșelăm. În acest caz nu vom testa performanța întregului sistem ci software-ul și hardware-ul stației pe care rulează testul/ele. De asemenea, resursele acesteia se vor consuma, fapt care va duce la blocare.

Testarea la nivel de client trebuie realizată luând în considerare următoarele aspecte: • Impactul acțiunilor utilizatorului – cât de rapid răspunde sistemul la

12

O privire de ansamblu asupra testării performanței aplicațiilor Desktop solicitările venite de la utilizator; • Impactul asupra resurselor sistemului utilizatorului – cât de ‘light’ este aplicația pentru stația utilizatorului.

De exemplu: cât de rapid se deschide aplicația, câtă memorie utilizează sau compatibilitatea aplicaței cu alte aplicații instalate.

Partea de back-end dintr-o aplicație client-server este de obicei zona unde se concentrează testarea performanței. De multe ori abordarea pe partea de server este destul de apropiată față de cea folosită pentru Web: se înregistrează un flow sau mai multe, se creează unul sau mai multe profiluri de utilizatori finali (aici putem include comportamentul și numărul utilizatorilor pe fiecare flow sau chiar performanța stațiilor sau a rețelelor). Bazându-ne pe aceste profiluri putem aloca un număr diferit de utilizatori virtuali și rula acele teste de la nivel de Service-layer. Serverul ar trebui să poată procesa solicitări concurente venind de la diferiți clienți, având diferite profile.

Pe diverse canale de informare (prezentări, forumuri) am aflat că pentru a testa aplicații client-server, unii testeri au decis să folosească mai multe stații (de la 2 la 5) în calitate de clienți, pentru amble tipuri de testări funcțional-automatizată și de performanță. Fiecare stație era setată conform unui anumit profil care să simuleze un anumit grup de utilizatori finali, și care evident să exercite un stres specific pe întreaga structură.

Tool-uri

Dacă este să comparam tool-urile de pe piață care oferă suport pentru testarea performanței aplicațiilor Desktop și cele orientate Web, am putea afirma că există un dezechilibru; destul de puține în prima categorie. Însă și mai puține tool-uri oferă suport pe mai multe platforme cum ar fi: Desktop, Web sau Mobile.

D i n e x p e r i e nț ă propr i e ș i d i n investigațile făcute, am remarcat câteva tool-uri: • Apache JMeter1 unul dintre cele mai cunoscute tool-uri gratuite și folosite mai cu seamă în testarea performanței la nivel de server, bază de date sau servicii; JMeter-ul nu controlează elementele grafice la nivel de interfață a utilizatorului în aplicațiile Desktop (de exemplu nu simulează apăsarea unui buton, scroll-ul sau poziția mouse-ului pe ecran), fapt pentru care nu este un tool potrivit pentru 1 http://jmeter.apache.org/

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

testarea performanței aplicațiilor desktop la nivel de interfață a clientului. Jmeter-ul este construit pentru a exercita un anumit stres asupra aplicațiilor care folosesc mai multe thread-uri sau utilizatori. Din moment ce avem o aplicație instalată pe un client, cel mai probabil vom avea un singur utilizator și nu ar avea niciun sens folosirea acestui tool în acest context. În schimb, mai multă logică ar avea testarea performanței unei baze de date independent de aplicația desktop • Telerik Test Studio2 – rulează teste funcționale ca teste de performanță, oferind o vizionare destul de avansată asupra rezultatelor testelor, perspectivă cronologică și comparații între mai multe teste. Acest tool este construit pentru testarea performanței aplicațiilor pe platforma Web și Desktop WPF (Windows Presentation Foundation). Nu are suport pentru aplicațiile construite pe tehnologia Windows Forms.

• Infragistic TestAdvantage for Windows Forms 3 – Construit pentru testarea performanței aplicațiilor care folosesc tehnologiile controalelor Windows Forms și WPF. • WC F S t o r m 4 – e s t e u n t o o l simplu și ușor de utilizat pentru testarea ser viciilor WCF (Windows Communication Foundation). Acesta suportă aproape toate tipurile de conexiuni netTcpBinding, wsHttpBinding și namedPipesBinding, cu excepția webHttp. De asemenea, poate fi utilizat pentru crearea de test case-uri funcționale și de performanță.

Datorită timpului limitat, nu am reușit să verific și alte tool-uri promovate în diferite prezentări, articole sau forumuri. Le-aș adăuga totuși pentru a oferi o perspectivă mai bogată asupra acestui aspect: Microsoft Visual Studio, Borland Silk Performer, Seapine Resource Thief, Quotium Qtest Windows Robot (WR), LoginVSI, TestComplete împreună cu AQtime, WCF Load Test, Grinder sau Load Runner. Într-un sistem clasic client-server, partea de client este o aplicație care trebuie instalată și utilizată de către un singur utilizator, ceea ce înseamnă că în majoritatea cazurilor nu se așteaptă ca aplicația să execute o mulțime de call-uri concurente, însă trebuie să răspundă cât mai prompt acțiunilor utilizatorului și să afișeze 2 http://www.telerik.com/automated-testing-tools/ 3 h t t p : / / w w w. i n f r a g i s t i c s . c o m / p r o d u c t s / testautomation 4 http://www.wcfstorm.com/wcf/home.aspx

TODAY SOFTWARE MAGAZINE rezultatele fără o întârziere prea mare. ca fiind incorecte Aplicația instalată pe client precum • Câteva index-tables care nu au fost și resursele consumate de aceasta este stabilite încă de la început, au fost identide obicei monitorizată cu ajutorul unui ficate și create ulterior testării. instrument numit Profiling5.

• Prea multă memorie consumată în Acest Profiling împreună cu un timpul rulării pe un profil care simula Performance Counter6 la nivel de SQL7 de 1Gb RAM memorie. În acest caz exemplu, poate constitui o metodă solidă performanța aplicației scade cu aproxipentru a realiza ce se întâmplă de fapt in mativ 15% pe flow-urile principale. sistem (client și server).

• Programul crash-uia uneori atunci Visual Studio are un profiler integrat. când o anumită funcționalitate sau feaFiind destul de avansat, permite măsurarea ture din aplicație era folosită mai des timpului necesar executării unei metode, deoarece avea ca rezultat depășirea conprecum și numărul apelărilor. toarelor sau a limitei de array-uri interne.

Pentru realizarea unui profiler la nivel • Performanța scăzută datorată de memorie, CLR Profiler permite vizuaunor “late binding”-uri excesive, plus lizarea consumului de memorie necesar ineficiență în crearea și distrugerea rulării aplicației, dar și observarea obiecteobiectelor. lor create de diferite metode.

• Memory leak identificat în cazul în Multe dintre tool-urile construite pencare aplicația era deschisă și neutilizată tru testarea performanței de la nivel de pentru o perioadă mai lungă de timp interfață al utilizatorului pot fi folosite (câteva ore). pentru înregistrarea unor flow-uri și mai târziu folosite pentru play-back pe mai Riscuri multe stații. În testarea performanței sistemelor desktop, cele mai întâlnite probleme sunt Rezultate relaționate la software și environment.

Câteva dintre problemele identificate Stabilitatea aplicației se pare că reprezintă în urma testării performanței aplicațiilor îngrijorarea predominantă a testerului, desktop ar putea fi menționate: cauza fiind multitudinea de situații în care • Multe instanțe de SQL, greșit conce- tester-ul trebuie să lucreze cu o aplicație pute. După optimizare, performanța s-a imperfectă sau neterminată. îmbunătățit simțitor.

Voi expune mai departe câteva dintre • Câteva SQL statement-uri care erau riscurile identificate și relaționate la testaexecutate în mai mult de un minut, au rea performanței soluțiilor desktop: fost îmbunătățite astfel încât să returneze • Un risc destul de întâlnit este legat rezultate în mai puțin de o secundă. de utilizarea resurselor locale în tim• Câteva view-tables au fost identificate pul scripting-ului primelor teste. Acest 5 h t t p : / / w w w . r e d - g a t e . c o m / p r o d u c t s / fapt duce de multe ori la blocarea sistedotnet-development/ants-performance-profiler/ 6 http://msdn.microsoft.com/en-us/library/w8f5kw2e. mului din cauza consumării memoriei. aspx 7 http://www.extremeexperts.com/sql/articles/ Unele aplicații eșuează destul de des sqlcounters.aspx

atunci când una dintre funcționalități este folosită mai intens. Testerul trebuie să urmeze flow-ul real în aplicație, să verifice și să permită tool-ului exercitarea un anumit stres, fapt care generează utilizare mai intensă. Bineînțeles, aceste probleme vor trebui rezolvate, însă există un impact asupra timpului, iar scriptingul va trebui amânat până în momentul în care se rezolvă aceste probleme.

• Crearea bazei de date specifică testării performanței implică probabil generarea a zeci de mii de intrări. Există două riscuri identificate în legătura cu această acțiune: • Simularea datelor ‘inventate’ din tabele și integritatea lor nu sunt menținute. Nu toate proiectele beneficiază de o migrare a unui sistem mai vechi, caz în care o bază de date din producție poate fi adaptată. Riscul este mai mare atunci când baza de date trebuie construită de la început.

• Al doilea risc este legat de faptul că regulile de business cum ar fi ajustarea financiară în diferite tabele nu este respectată. În amândouă cazurile, este posibil ca simularea load-ului să nu fie compromisă, însă s-ar putea ca aplicația să nu poată manipula inconsistențele și să devină disfuncțională. Este important ca persoanele care pregătesc baza de date împreună cu popularea ei, să înțeleagă regulile de business, design-ul bazei de date și rolul aplicației.

• Subestimarea efortului necesar pregătirii și rulării testelor poate fi de asemenea considerat un risc. Testarea performanței unui sistem client-server este o activitate complexă, mai ales din

www.todaysoftmag.ro | nr. 20/Februarie, 2014

13

testare

O privire de ansamblu asupra testării performanței aplicațiilor Desktop

În final putem evidenția câteva concluzii referitoare la aplicațiile construite pe platforma Desktop:

• Tool-urile sunt importante și esențiale, dar problemele nu se leagă doar de ele, provocarea ar fi mai degrabă identificarea scopului pentru care trebuie executate testele de performanță. Care ar putea fi îngrijorările legate de business, infrastructura sau așteptările utilizatorilor finali cu privire la aplicație? Scenariile de acest tip: cele mai comune, cele mai critice din punct de vedere al businessului sau cele care solicită cel mai mult aplicația din punct de vedere tehnic ar trebui luate în considerare chiar dacă la ele nu au consimțit în prealabil clientul.

• Factori ca: firewall-uri, aplicația antivirus, arhitectura rețelei, infrastructura, sistem de operare cu Service pack-ul aferent sau chiar alte programe care rulează în același timp pe stație, toate afectează performanța întregului sistem. Toate acestea împreună formează un set de variabile pe care trebuie să le luăm în considerare.

• Testarea performanței aplicațiilor desktop, este percepută ca fiind foarte apropiată de testarea functională si de asemenea de a scrie cod în acest scop.

Pe forumurile de profil există o ușoară tendință ca persoanele implicate în testarea performanței să-și creeze propriul tool9 scris în .NET, Java, Perl, Python sau alte tehnologii pe care mai târziu să-l folosească deopotrivă în automatizarea testelor și testarea performanței.

• Dacă ne referim strict la performanță, majoritatea vor înclina către testarea la nivel de Service layer/Bază de Date.

• Este difícil să găsești un tool deja creat care să se potrivească majorității tehnologiilor folosite în aplicațiile desktop. Mai mult decat atât, să poată fi folosit și la înregistrarea flow-urilor din aplicație la nivel de interfață cu utilizatorul, apoi la play-back folosind mai multe stații sau utilizatori virtuali.

• Pentru unele teste de performanță la nivel de client nici nu este nevoie întotdeauna de un tool special, ci mai degrabă de câteva cazuri de test bine desenate și gândite, grupate în suite, având câteva variabile.

• Administratorii de baze de date, de sistem sau de rețea nu pot crea singuri suportul pentru testele de performanță.

Din acest motiv, ei trebuie implicați în stadiile incipiente ale proiectului.

Perspectivele lor îmbunătățesc calitatea testing-ului.

• Multitudinea sistemelor de operare,

8 1995 Eurostar presentation of Paul Gerard – Client/ Server Performance Testing

9 http://msdn.microsoft.com/en-us/magazine/ cc188784.aspx

cauza problemelor care apar în timpul încercării de simulare a mediului și infrastructurii.

• Ambiția8 prea optimistă, cel puțin în stadiul incipient al proiectului.

Persoanele implicate de obicei prespun că baza de date este populată cu date valide, că fiecare tranzacție trebuie cuprinsă în testele de performanță sau că toți timpii trebuie măsurați. De obicei următoarea regulă, 80/20 se aplică: 80% din volumul bazei de date este furnizat de 20% dintre tabele. 80% din stresul asupra sistemului va fi generat de 20% dintre tranzacții. Doar 20% din tranzacțiile sistemului ar trebui măsurate deși testerii experimentați ar presupune că aici s-ar putea aplica regula 90/10. Managerii neexperimentati par să amestece valorile 90 și 10.

• Tool-urile folosite pentru execuția testelor de performanță nu necesită cunoștințe extrem de bogate, având în vedere că aproape peste tot în dezvoltarea și testing-ul aplicațiilor există principii la care, dacă se aderă, ar trebui să ofere și testerilor cu o experiență medie capacitatea de a crea teste de performanță.

Există o tendință comună în rândul managerilor și testerilor fără experiență în testarea performanței sistemelor, de a crede că procesul testării constă în două etape: scripting și rulare. Mai mult decât atât, riscul crește dacă există nevoia de a personaliza anumite tool-uri pe care acei testeri le folosesc.

• Un alt risc identificat este legat de cunoștintele și abilitățile persoanelor implicate în proiect. Atunci când programatorilor care au realizat designul și au implementat o anumită funcționalitate li se cere să creeze o suită de teste automatizate pentru a putea fi utilizate la testarea performanței, dificultatea principală o reprezintă experiența în testare. Pe de altă parte, testerii experimentați care nu au nicio cunoștință în ceea ce privește sistemul pe care îl vor testa, de obicei vor avea nevoie de o mică perioadă de familiarizare cu aplicația. Ideal ar fi să lucreze împreună, însă dacă există probleme legate de resurse/cunoștințe, managerul de proiect va trebui să ia deciziile bazate pe risc și impact.

Concluzii

14

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

versiunilor sau configurațiile hardware pot crea probleme în definirea profilurilor “utilizatorilor finali”. E imposibilă simularea tuturor acestor combinații, prin urmare o idee bună putând fi prioritizarea configurațiilor OS vs. Hardware.

Există tool-uri care pot simula limitările de hardware (disk, memory, network) unul dintre ele este Seapine Resource Thief.

• În general, problemele testingului de performanță de ordin logistic, organizațional sau tehnic pot fi evitate aplicând principii cum ar fi: a. abordarea testing-ului în arhitecturile cu două sau trei nivele este similar, diferă doar complexitatea; b. tool-urile brevetate și cunoscute ajută, dar mai mult decât atât, se cere improvizare și inovare pentru ca o testare eficientă să se ‘întâmple’; c. atunci când se alege un tool care se dorește a fi folosit de la nivel de UI, trebuie avut în vedere tehnologia folosită la implementare. Nu am găsit un tool care să poată trata toate tehnologiile.

De exemplu, unele tool-uri cum ar fi Telerik Test Studio pot înregistra flowuri pe o aplicație implementată in WPF (Windows Presentation Foundation) și nu poate fi folosit dacă implementarea este făcută în Windows Forms.

• Iată câteva deficiențe ale unora dintre tool-urile investigate: a. dacă dorim să testăm un serviciu care transferă fișiere de exemplu, nu am găsit niciun tool capabil să facă browse pe disk pentru acel fișier; b. a plicația desktop trebuie să fie deja pornită pentru majoritatea tool-urilor; c. acțiunea Play-back este oprită dacă apare o pagină pop-up în timpul flow-ului (QA Wizard Pro); d. operațiile de genul: Save, Open etc. , nu sunt suportate de tool-urile investigate.

La o primă vedere, testarea performanței aplicațiilor desktop pare să fie destul de diferită, soluțiile existente oferind o gamă destul de vastă în posibilitățile de testare. Cu toate acestea, să nu uităm că asigurarea calității fundamentale, împreună cu principiile de bază rămân la fel și se aplică tuturor.

Enjoy testing !!

management

Software Craftsmanship și Lean Startup

Î Alexandru Bolboaca

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

Adrian Bolboaca

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

n lumea startup-urilor, mișcarea Lean Startup a fost o revoluție deși a pornit de la o observație simplă. Modelul standard de creare a unui startup era până de curând “Build, Measure, Learn” adică: • Un antreprenor are o viziune de produs.

• După ce obține finanțarea necesară, construiește produsul conform viziunii sale.

• Produsul este testat pe piață.

• Dacă are succes, perfect! Dacă nu are succes, este modificat pentru a fi mai aproape de nevoile utilizatorilor reali.

Problema acestui model este că la momentul la care produsul poate trece testul pieței, el a fost deja construit, deci s-au investit bani și efort în el. Din punct de vedere tehnic, se întâmplă adesea ca produsul să fi fost grăbit, programatorii să lucreze sub presiune și rezultatul să fie un cod greu de modificat și plin de bug-uri.

Steve Blank și Eric Ries au venit cu ideea de a inversa acest ciclu și de a folosi “Learn, Measure, Build”, adică: • Un antreprenor are o viziune de produs.

• Viziunea este transfomată într-un set de ipoteze.

• Fiecare ipoteză este testată printr-un experiment. Rezultatul experimentului este măsurabil și comparat cu așteptările definite de ipoteză.

• O dată ce o ipoteză a fost validată, poate fi dezvoltată soluția rezultată și inclusă într-un produs.

Experimentul poate include crearea unui prototip funcțional al unei aplicații, dar nu este neapărat necesar. Arta constă în a identifica minimul de investiție pentru a putea valida ipoteza. Experimentele cele mai întâlnite, în special pentru produsele online, sunt de tip “A/B testing”: două posibilități sunt puse în competiție și “votate” de utilizatorii potențiali. Cea

mai populară este de obicei aleasă ca fiind câștigătoare.

La nivel tehnic, Lean Startup presupune o agilitate foarte mare determinată de lucrul într-un mediu necunoscut și în curs de descoperire. Dacă în modelul standard de dezvoltare de produs presupunem că știm care este viziunea, care sunt funcționalitățile și care sunt următoarele cerințe, în modelul lean startup viziunea se poate modifica în funcție de piață (prin pivotare), funcționalitățile sunt descoperite pe parcurs, iar cerințele următoare pot fi extrem de surprinzătoare.

Un exemplu clasic este Flickr, serviciul de stocare de imagini care a fost cumpărat de yahoo. Inițial, viziunea produsului era de a face un joc numit “Game Neverending” în care adăugarea de fotografii era una dintre funcționalități. După un timp, echipa și-a dat seama că jocul nu era foarte bine primit, dar serviciul de stocare de poze era foarte interesant pentru utilizatori. Ca urmare, au decis să se concentreze pe flickr.com și să oprească dezvoltarea jocului.

Literatura de Lean Startup menționează doar în treacăt aspectele tehnice ale metodei. Motivele sunt două: revoluția trebuia făcută în primul rând la nivel business și presupunerea autorilor a fost că programatorii își vor da seama ce practici tehnice trebuie să folosească.

www.todaysoftmag.ro | nr. 20/Februarie, 2014

15

management Software Craftsmanship și Lean Startup Imaginați-vă însă contextul în care lucrează multe din startup-urile online de azi. Multe dintre ele fac deployment al unei versiuni noi în producție de sute de ori pe zi. Fiecare deployment este fie un experiment de tip A/B testing, fie implementarea unei funcționalități deja validate.

Acest ritm de dezvoltare necesită abilități de programare precum: • G â n d i r e i n c r e m e n t a l ă – împărțirea unei funcționalități mari în funcționalități foarte mici ce pot fi implementate rapid și pe care se poate lua feed-back rapid din piață.

• Testare automată – o combinație de teste unitare, teste de acceptanță, teste de performanță, teste de securitate, este necesară pentru a valida rapid orice modificare în cod.

• Design deschis la modificare – dacă design-ul este inflexibil, orice modificare va lua prea mult timp.

• Cod ușor de modificat – urmărirea coding guidelines comune, optimizarea pentru lizibilitate și scrierea de cod ușor de înțeles sunt factori esențiali pentru păstrarea vitezei de implementare.

• Refactoring – este inevitabil ca design-ul să fie închis la modificare în anumite puncte. Refactoring-ul rapid este o abilitate esențială pentru a-l transforma în design ușor de modificat. În plus, aceste echipe folosesc fluxuri de lucru clare care includ adesea: monitorizare, revenirea la versiuni care funcționează corect în caz de bug-uri majore, porți de validare înainte de deployment.

Dar poate nu este nevoie de sute de puneri în producție pe zi. Poate ajunge ca ciclul de feed-back să fie de o săptămână sau câteva zile. Chiar și atunci, abilitățile necesare pentru programatorii care lucrează la produs sunt aceleași. Singura diferență este că își pot împărți munca în incremente mai mari.

16

Dacă legătura cu Software Craftsmanship nu este clară încă, o vom explora în continuare. După c um spune am în ar t icolu l despre Software Craftsmanship[ http://www.

pot termina mai repede implementarea dacă le folosesc. Acesta este de fapt idealul Software Craftsmanship: a-ți dezvolta atât de bine abilitățile încât să devină modul implicit și cel mai rapid de lucru, mai ales to d ay s of t mag . c om / ar t i cl e / e n / 1 1 / atunci când viteza de implementare este Software_Craftsmanship__404], mișcarea extrem de importantă. a apărut pentru a permite reducerea costului de schimbare al codului prin aplicarea Concluzie anumitor practici cunoscute și prin desLean Startup se bazează pe artizani coperirea altor practici noi. Câteva dintre software (craftsman). Experimentele cele practicile pe care le cunoaștem acum sunt: mai bune sunt cele care nu necesită cod.

Uneori, este nevoie și de implementarea • Test Driven Development, pentru unor experimente. Un artizan software va a obține incremental un design adap- fi capabil să le implementeze rapid și fără a tat problemei curente și deschis la introduce probleme. modificare.

Dacă în faza de descoperire putem • Testarea automată, pentru evitarea trăi și fără a aplica practici precum TDD, regresiilor. testare automată sau refactoring, faza de • Principiile SOLID, design patterns implementare are mare nevoie de ele penși cunoștințele de design pentru a evita tru a permite punerea cât mai rapidă în problemele de design producție a functionalităților validate de • Clean Code pentru a scrie cod ușor experimente. Cu cât sunt puse mai rapid de citit și de înțeles. în producție cu atât crește probabili• Refactoring pentru a readuce design- tatea de a avea clienți plătitori, asigurând ul la nivelul necesar atunci când începe supraviețuirea startup-ului și crescându-i să nu mai fie potrivit. șansele de succes. Întrebarea care se pune este când merită investit în aceste practici într-un startup și când nu. Pentru cei care urmează modelul lean startup, răspunsul ar trebui să fie simplu: atât timp cât suntem la început și încercăm să dezvoltăm clienții prin experimente, nu are rost să investim mai mult decât este necesar. Cele mai bune experimente sunt cele care nu necesită cod scris.

Dacă totuși trebuie scris cod, este important să îl scriem cât mai repede cu putință, chiar dacă pot scăpa greșeli.

Imediat ce o funcționalitate a fost validată, codul trebuie scris, sau rescris, astfel încât să poată fi ușor de modificat. Altfel, riscăm să nu putem beneficia îndeajuns de rapid de pe urma lucrurilor pe care le aflăm prin experimente.

Trebuie să menționăm că programatorii care au exersat îndeajuns aceste tehnici

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

programare

TODAY SOFTWARE MAGAZINE

Vagrant pentru începători

D

e câte ori ai auzit “Dar funcționează pe mașina mea” sau “Dar la mine pe local merge”? Cât timp îți ia să-ți setezi mediul de lucru? De câte ori ai întâlnit diferențe între serverul de pe producție și cel de dezvoltare? Imaginează-ți o lume ideală în care toți dezvoltatorii lucrează pe aceeași platformă, în care platformele de dezvoltare și cele de producție au fost construite bazându-se pe aceleași specificații. Această lume există și se numește virtualizare. Vagrant este un tool de virtualizare, care are un răspuns la toate aceste întrebări, transformând această lume ideală într-o lume reală. Vagrant poate fi folosit pentru a crea și a configura medii de dezvoltare performante, portabile și reproductibile.

Vagrant este dezvoltat în Ruby de către Mitchell Hashimoto1.

Mithchell este un developer pasionat de automatizare. A început proiectul Vagrant în 2010, în timpul liber. În următorii ani proiectul a crescut și a început să fie folosit cu încredere de un număr tot mai mare de dezvoltatori. Ca urmare în 2012 Mitchell a înființat propria lui companie HashiCorp, pentru a dezvolta și pentru a oferi training-uri și suport profesional pentru Vagrant. În momentul de față Vagrant2 este un proiect open source, fiind rezultatul a sute de contribuitori pe GitHub3.

Ce este Vagrant?

Pentru a realiza magia, Vagrant se bazează pe giganții lui, acționând ca un layer în fața providerilor VirtualBox, VMware, AWS sau alții. De asemenea, instrumente din industria-standard de provisionare, cum sunt script-urile Shell, Chef și Puppet pot fi folosite pentru a seta automat un nou mediu de dezvoltare.

Vagrant poate fi folosit și în proiecte scrise în alte limbaje de programare cum ar fi PHP, Pyton, Java, C# sau JavaScript și poate fi instalat atât pe sisteme Linux, Mac OS X cât și pe Windows.

Vagrant oferă mașini virtuale tranzistorii, portabile care se pot muta dintr-o parte într-alta, fără a avea o locație fixă, exact ca un vagabond. Dacă ești programator, poți folosi Vagrant pentru a izola dependințele și configurațiile lor cu un singur mediu de dezvoltare consistent. Odată ce a fost creat Vagrantfile trebuie doar să rulezi comanda vagrant-up pentru ca totul să funcționeze pe mașina ta. Ca inginer de sistem, Vagrant îți oferă un mediu disponibil și un flux de muncă consistent pentru dezvoltarea și testarea script-urilor de management a infrastructurii. Poți testa foarte rapid shell script-uri, rețete Chef și module Puppet, folosind virtualizarea pe mașini locale cum sunt VirtualBox sau VMware. Apoi cu aceleași configurări, poți testa script-urile remote din clouds cum sunt AWS sau RackSpace, folosind același mod de lucru. Ca designer, folosind Vagrant poți să setezi cu ușurință un nou mediu de dezvoltare bazat pe fișierul de configurare Vagrantfile, care este deja configurat, fără să-ți mai faci griji cum să reconfigurezi aplicația4.

1 https://github.com/mitchellh 2 http://www.vagrantup.com/ 3 https://github.com/mitchellh/vagrant 4 http://docs.vagrantup.com/v2/why-vagrant/index.html

Folosind Vagrant poți obține următoarele beneficii: • un mediu de dezvoltare per proiect–> poți avea fișiere de configurare diferite pentru fiecare proiect.

• același fișier de configurare pentru mediile de dezvoltare, pentru serverele pre-staging, staging și cele de producție.

• un fișier de configurare ușor de transportat și de configurat (Vagrantfile).

• un fișier de configurare ușor de modificat –> infrastructură cu rol de cod.

• fișiere de configurare versionate –> poți să faci commit la toate fișierele de provizionare și la fișierul Vagrantfile.

• aceleași fișiere de configurare pentru toată echipa–> folosind același fișier de configurare (Vagrantfile)

Vagrant — de la instalare până la mașina virtuală funcțională. Înainte de a începe primul proiect Vagrant, trebuie să instalezi VirtualBox sau orice alt provider suportat de Vagrant. Pentru acest exemplu eu am folosit VirtualBox. Primul pas constă în instalarea instrumentului Vagrant, prin descărcarea și instalarea pachetului sau a executabilului corespunzător, de pe pagina5 oficială de descărcare a Vagrant-ului. Executabilul va adăuga automat vagrant în calea de sistem, fiind disponibil în terminal imediat după instalare, cum se poate vedea mai jos. $ vagrant Usage: vagrant [-v] [-h] command [<args>] -v, --version Print the version and exit.

-h, --help Print this help.

Available subcommands: box manages boxes: installation, removal, etc. destroy stops and deletes all traces of the vagrant machine halt stops the vagrant machine help shows the help for a subcommand init initializes a new Vagrant environment by creating a Vagrantfile package packages a running vagrant environment into a box plugin manages plugin s: install, uninstall, update, etc. provision provisions the vagrant machine reload restarts vagrant machine, loads 5 http://www.vagrantup.com/downloads

www.todaysoftmag.ro | nr. 20/Februarie, 2014

17

programare Vagrant pentru începători new Vagrantfile resume ssh ssh-config to connect to

status chine suspend up environment

configuration resume a suspended vagrant machine connects to machine via SSH outputs OpenSSH valid configuration

config.vm.box_url = “http://files.vagrantup.com/precise32.box”

Directiva config.vm.box = “precise32”, descrie tipul mașinii virtuale. “Box-ul” reprezintă scheletul pe care mașinile virtuale Vagrant vor fi construite. Acestea sunt fișiere portabile care pot fi folosite de către oricine, pe orice platformă pe care rulează Vagrant. suspends the machine starts and provisions the vagrant Un lucru important de observat este faptul că aceste așa-zise cutii sunt create pe baza provider-ilor. În aces sens, înainte de instalarea Următorul pas este inițializarea instrumentului Vagrant în scheletului mașinii virtuale, trebuie verficat provider-ul pe care se noul proiect, rulând comanda: bazează. Pentru a selecta un schelet pentru mașina virtuală puteți accesa http://www.vagrantbox.es. Aici poate fi găsită o listă cu $ vagrant init toate base-box-urile care sunt disponibile. Vagrant oferă de aseA `Vagrantfile` has been placed in this directory. menea, posibilitatea de a crea “cutii” personalizare. Un instrument You are now util în acest scop este Veewee6, care are ca obiectiv automatizarea ready to `vagrant up` your first virtual environment!

Please tuturor pașilor pentru construirea acestor “cutii” cât și colectarea Read the comments in the Vagrantfile as well as docucelor mai bune practici într-o modalitate transparentă. O “cutie” mentation on`vagrantup.com` for more information on using Vagrant. poate fi adăugată și din linia de comandă tastând: the machine outputs status of the vagrant ma-

$ vagrant box add <name> <url> După rularea acestei comenzi, Vagrantfile este generat automat în directorul proiectului pe care s-a făcut inițializarea.

Vagrantfile este scris în Ruby, dar nu este necesară cunoașterea acestui limbaj de programare, deoarece majoritatea modificărilor constau într-o simplă atribuire de variabile. Fișierul Vagrantfile are următoarele roluri: • Selectarea schelet-ului pentru mașina virtuală, • Selectarea provider-ului de virtualizare, • Configurarea parametrilor mașinei virtuale, • Configurarea rețelei, • Modificarea setărilor SSH, • Sincronizarea directoarelor locale cu cele de pe mașina virtuală, • Provisionarea mașinii virtuale.

Selectarea scheletului pentru mașina virtuală

Fișierul Vagrantfile generat automat conține următoarele linii:

# Every Vagrant virtual environment requires a box to build off of. config.vm.box = “precise32” # The url from where the ‘config.vm.box’ box will be fetched if it # doesn’t already exist on the user’s system.

Unde <name> poate fi definit oricum, singurul lucru de care trebuie ținut cont este ca parametrul respectiv să coincidă cu cel definit în cadrul directivei config.vm.box. <url> reprezintă locația “cutiei”. Poate fi calea spre un fișier local sau un HTTP URL spre o “cutie” externă. $ vagrant box add precise32 http://files.vagrantup. com/precise32.box

Comenzile disponibile pentru management-ul “cutiilor” sunt listate mai jos. $ vagrant box -h Usage: vagrant box <command> [<args>] Available subcommands: add list remove repackage For help on any individual command run `vagrant box COMMAND -h`

Selectarea provider-ului de virtualizare

Sunt două modalități care pot fi folosite pentru specificarea provider-ului, similar modului cum a fost descris mai sus pentru 6 https://github.com/jedi4ever/veewee

Our core competencies include:

Product Strategy

3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world.

Our offerings are business focused, they drive real, tangible value.

www.3pillarglobal.com

18

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

Product Development

Product Support

TODAY SOFTWARE MAGAZINE access to the machine

# using a specific IP. “cutii”. O opțiune constă în specificarea provider-ului ca paraconfig.vm.network :private_network, ip: metru din linia de comandă. Dacă este selectată această metodă, “192.168.33.10” trebuie să te asiguri că argumentul prevăzut coincide cu cel specificat în directiva config.vm.provider.

Modificarea setărilor SSH $ vagrant up --provider=virtualbox Vagrantfile oferă posibilitatea de a confgura namespace-ul config.ssh pentru a specifica numele utilizatorului, host-ul, portCelalaltă opțiune este să se specifice provider-ul doar în direc- ul, guest_port-ul, private_key_path, forward_agent, forward_x11 tiva config.vm.provider. și shell.

Important de menționat este faptul că unele “cutii” nu necesită do |config| specificarea provider-ului, deoarece pot funcționa cu orice tip de Vagrant.configure(“2”) config.ssh.private_key_path = “~/.ssh/id_rsa” provider. config.ssh.forward_agent = true end

Configurarea parametrilor mașinei virtuale

Sincronizarea directoarelor locale cu cele de pe mașina

Vagrantfile oferă posibilitatea configurării provider-ilor prin virtuală adăugarea directivei vb.customize. De exemplu, dacă vrei să În timp ce mulți utilizatori editează fișierele de pe mașinile mărești memoria alocată mașinii virtuale, poți să faci cum este virtuale folosind doar editoare sincronizate cu mașina virtuală descris mai jos. prin SSH, Vagrant oferă posibilitatea de sincronizare automată a fișierelor de pe ambele mașini, folosind folder-ele sincronizate. În # Provider-specific configuration so you can fine-tune mod implicit Vagrant oferă posibilitatea da a sincroniza fișierele various # backing providers for Vagrant. These expose de pe mașina locală, cu directorul /vagrant de pe mașina virtuprovider-specific options. ală. În acest fel directorul /vagrant localizat pe mașina virtuală, # Example for VirtualBox: # este identic cu cel de pe mașina locală. Astfel nu mai ești nevoit config.vm.provider :virtualbox do |vb| să folosești opțiunile de Upload și Download, din IDE pentru # # Don’t boot with headless mode # vb.gui = true sincronizarea fișierelor. Dacă vrei să modifici directorul sincro# nizat de pe mașina sincronizată, o poți face adăugând următoarea # # Use VBoxManage to customize the VM. For example to change memory: directivă config.vm.synced_folder “../data”, “/vagrant_data” în

vb.customize [“modifyvm”, :id, “--memory”, Vagrantfile.

“2048”] end

Configurarea rețelei

Vagrant.configure(“2”) do |config| config.vm.synced_folder “../data”, “/vagrant_ data” end

Accesarea paginilor web în curs de dezvoltare, de pe mașina virtuală nu este o idee prea bună. Tocmai de aceea, Vagrant oferă funcționalități pentru configurarea rețelei, cu scopul de a accesa Provisionarea mașinii virtuale mașina virtuală, de pe mașina locală. Vagrantfile are trei directive Provizionarea nu este o sarcină de care se ocupă în mod norcare pot fi folosite pentru configurarea rețelei. mal dezvoltatorii, deoarece administratorii de sistem sunt cei care fac lucrurile acestea. Ideea de la care se pornește este de a înregis• config.vm.network :forwarded_port, guest: 80, tra configurările setate pe un server, cu scopul de a le replica pe host: 8080 un alt server. Mai demult administratorii de sistem țineau un wiki Traducând această directivă, deducem faptul că Apache-ul pentru comenzile rulate pe servere, dar această metodă nu era cea instalat pe mașina virtuală, creată de Vagrant, poate fi accesat de mai bună. Altă opțiune este să creezi back-up-uri .box sau .iso, astpe mașina locală, folosind url-ul http://127.0.0.1:8080. Aceasta fel încât noile servere să poată fi configurate pe baza acestor fișiere. înseamnă că tot traficul din rețea a fost redirecționat spre portul Dar, menținerea la zi a acestor fișiere este dificilă și necesită mai specificat pe mașina virtuală. multă muncă, fiind în același timp destul de greu să sincronizezi toate serverele în acest fel. Provizionarea în zilele noastre, oferă # Create a forwarded port mapping which allows acposibilitatea de a adăuga software special pentru creare fișierelor cess to a specific port # within the machine from a port on the host made configurare, pentru executarea comenzilor, pentru crearea utilichine. In the example below, zatorilor sau managementul serviciilor, folosind sisteme moderne # accessing “localhost:8080” will access port 80 on the guest machine. de provizionare. Vagrant poate fi integrat cu următoarele sisteme config.vm.network :forwarded_port, guest: 80, host: de provizionare: Shell, Ansible, Chef Solo, Chef Client, Puppet, 8080 Salt Stack. Cele mai populare sisteme de provizionare sunt Chef • config.vm.network :public_network și Puppet, fiind menținute de o comunitate mare de utilizatori.

Ambele sunt scrise în Ruby, având caracteristici similare cum ar fi # Create a public network, which generally matched to bridged network. modularizarea componentelor, pachete pentru instalarea software# Bridged networks make the machine appear as anului sau template-uri pentru fișiere personalizate. Ambele sisteme other physical device on # your network. sunt open source cu un model de plata pentru companii. O scurtă config.vm.network :public_network trecere în revistă pentru Puppet și Chef este prezentată în tabelul • config.vm.network :private_network, ip: de mai jos.

“192.168.33.10”

# Create a private network, which allows host-only

Provizionarea cu Shell Provizionare cu Shell în Vagrant este relativ ușoară. Poți scrie www.todaysoftmag.ro | nr. 20/Februarie, 2014

19

programare Vagrant pentru începători MySql params.pp, din module/manifests/params.pp class mysql::params { $manage_config_file = true $old_root_password = ‘’ $root_password = “strongpassword” }

module/manifests/templates Table 1. Chef vs. Puppet

Mysql Template [client] password=<%= scope.lookupvar(‘mysql::root_password’) %>

comenzi inline sau poți menționa calea spre script-ul shell. Calea poate fi spre un director local sau extern.

Comandă inline Provizionarea cu Chef8 Solo config.vm.provision :shell, :inline => “curl -L httRețetele Chef Solo pot fi descărcate de pe Opscode9. Structura ps://get.rvm.io | bash -s stable” unei rețete Chef este prezentată în Cale fișier local Fig. 2. Structura unei Rețete Chef config.vm.provision :shell, :path => “install-rvm.

Solo. Pentru adăugarea configurațiilor sh”, :args => “stable” doar fișierele scrise îngroșat trebuie Cale fișier extern modificate. config.vm.provision :shell, :path=>”https://example.

Vagrantfile trebuie modificat com/install-rvm.sh”, :args => “stable” după cum este afișat mai jos pentru a Provizionare cu Pupppet folosi Chef Solo ca provizionar.

Modulele Puppet pot fi descărcate de pe https://github.com/ config.vm.provision :chef_solo puppetlabs. Pe disc, un modul este un director care are structura do |chef| chef.cookbooks_path = prezentată în Fig. 1 Structura unui Modul Puppet. Programele “cookbooks” Puppet se numesc “manifests” și chef.add_recipe “vafolosesc extensia .pp pentru fișiere. grant_main” # chef.roles_path = Manifests pot folosi tipuri vari- “../my-recipes/roles” Fig 2. Structura unei ate de logică, cum sunt declarațiile Rețete Chef Solo # chef.data_bags_path = condiționale, colecțiile de resurse, “../my- recipes/data_bags” funcții pentru generarea textului, # chef.add_role “web” etc.. Dacă nu vrei să setezi manual # # # You may also specify custom JSON attributes: fișierele manifest, există un instru# chef.json = { :mysql_password => “foo” } ment foarte simplu de utilizat cu end GUI, care poate genera automat unde vagrant_main are următoarea structură: toate aceste fișiere. Acest instrument se numește PuPHPet7.

Fig. 1 Structura unui Pentru a configura manual Modul Puppet Vagrant cu Puppet, trebuie să setezi directivele Puppet după cum urmează: config.vm.provision :puppet do |puppet| puppet.manifests_path = “./tools/puppet/manifests/” puppet.module_path = “./tools/puppet/modules” puppet.manifest_file = “init.pp” puppet.options = [‘--verbose’] End

unde init.pp este de forma include mysql::server class { ‘::mysql::server’: root_password => ‘strongpassword’ }

MySql init.pp, din module/manifests/init.pp class mysql::server ( $config_file = $mysql::params::config_file, $manage_config_file = $mysql::params::manage_config_file, $package_ensure = mysql::params::server_package_ensure, ) 7 https://puphpet.com

20

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

vagrant_main/recipes/default.rb include_recipe “apache2” include_recipe “apache2::mod_rewrite” package “mysql-server” do package_name value_for_platform(“default” => “mysql-server”) action :install end

vagrant_main/templates/default.rb NameVirtualHost *:80 <VirtualHost *:80> ServerAdmin webmaster@localhost ServerName cfratila.tsm.com ServerAlias www.cfratila.tsm.com DocumentRoot /var/www

8 http://www.getchef.com/ 9 http://community.opscode.com/

TODAY SOFTWARE MAGAZINE <Directory “/var/www/sites/all/cfratila.tsm. com”> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny Allow from all </Directory> ErrorLog <%= node[:apache][:log_dir] %>/tsm-error.log CustomLog <%= node[:apache][:log_dir] %>/tsmaccess.log combined LogLevel warn </VirtualHost>

Odată ce ai terminat configurarea fișierului Vagrantfile ești gata pentru crearea mașinii virtuale. Pentru acest pas trebuie să deschizi interfața în linia de comandă și să navighezi în folderul proiectului, unde ar trebui să fie fișierul Vagrantfile, pentru a sincroniza directoarele. Apoi rulează vagrant up pentru crearea și pornirea mașinii virtuale. Prima dată când vei rula vagrant up va dura puțin mai mult, pentru că Vagrant va descărca box-ul configurat. În exemplul meu, eu nu am adăugat box-ul rulând comanda vagrant box add <name> <url>, motiv pentru care box-ul va fi adăugat la rularea comenzii vagrant up.

Fig 4. Vagrant – Procesul de lucru

bază constă în crearea componentelor per aplicație. Componenta este de fapt un instantaneu al aplicației făcut la un moment dat.

Dacă s-au modificat componentele, poți să faci commit la noul status al instantaneului, ceea ce face foarte ușoară procedura de roll back. Acest proiect, care este încă în stadiu de dezvoltare, sună promițător, pentru că nu folosește mașini virtuale cum funcționează Vagrant, ceea ce înseamnă că atât timpul de pornire cât și modalitatea de folosire a resurselor, sunt mai bune.

D:\projects\tsm> vagrant up Comparând metodologia de lucru a celor două instrumente, Bringing machine ‘default’ up with ‘virtualbox’ provider... putem enunța următoarele afirmații: [default] Box ‘precise32’ was not found. Fetching 1. Vagrant este mai bun pentru că păstrează codul sursă și box from specified URL for the provider ‘virtualbox’. Note that if the URL does not have a box for informațiile de deployment în același loc. this provider, you should interrupt Vagramt now and 2. Vagrant este mai bun pentru că este stabil și poate fi folosit add the box yourself. Otherwise Vagrant will attempt to download the full box prior to discovering this în producție. error.

3. Vagrant este mai bun pentru că poate fi integrat cu Linux, Downloading box from URL: http://files.vagrantup.com/ precise32.box Windows și Mac OS X. Progres: 1% <Rate: 41933/s, Estimated time remain4. Docker este mai bun pe parte de provizionare. ing: 2:15:30> 5. Procedura de roll back este mai rapidă și mai ușoară datorită După ce a fost creată mașina virtuală, poți rula comanda sistemului de instantanee. vagrant ssh pentru accesare. Pentru sistemele de operate Windows 6. Docker a venit cu un nou model de deployment. poți instala clientul PuTTY SSH, pentru accesarea mașinii virtu7. Docker poate fi integrat doar cu mașinile de Ubuntu. ale, folosind credențialele de mai jos.

8. Docker nu este recomandat în producție deoarece este încă în faza de dezvoltare.

D:\projects\tsm> vagrant ssh ‘ssh’ executable not found in any directories in the %PATH% variable. Is an SSH client instaled? Try installing Cygwin, MinGW or Git, all of which contain SSH client. Or use the PuTTY SSH client with the following authentication information shown below: Host: 127.0.0.1 Port: 2222 Username: vagrant Private key: C:/Users/Carmen/.vagrant.d/insecure_ private_key

Dacă ai modificat doar fișierele de provizionare și vrei să testezi rapid, poți rula doar vagrant provision sau vagrant --provisionwith x,y,z, unde x,y,z reprezintă provizionarul :shell, de exemplu.

Dacă vrei să salvezi statusul mașinii virtuale pentru a nu boot-a de fiecare dată, poți rula vagrant suspend. Cu vagrant resume se rezumă mașina Vagrant care a fost suspendată.

Procesul de lucru cu Vagrant10 nu este deloc complicat după cum reiese și din Fig.4. Doar rulând comanda vagrant up pe baza fișierului Vagrantfile, a configurațiilor setate pentru provizionar și provider, mașina virtuală este pornită și funcțională.

Mai sunt instrumente similare cu Vagrant?

Docker11 este un proiect open source folosit pentru ambalarea, tansportarea și rularea oricărei aplicații ca un container. Ideea de 10 http://www.digitalforreallife.com/2012/11/boosting-teamwork-with-vagrant/ 11 http://www.docker.io/

De ce merită să folosești Vagrant?

Eu sunt un developer focusat pe PHP nu administrator de sistem. Vreau să petrec cât mai mult timp codând. Nu vreau să îmi fac griji legate de setarea mediului de lucru sau de setarea mașinilor virtuale. Tot ceea ce vreau este să îmi setez mediul de lucru într-un mod cât mai simplu și cât mai rapid. Vreau să evit situațiile în care mașina mea virtuală crapă, și trebuie să o reconfigurez de la 0. De când folosesc Vagrant, nu îmi mai fac asemenea griji, pentru că există Vagrantfile, care îmi păstrează toate configurările. Sincronizarea directoarelor și redirecționarea traficului prin forwarding port sunt două caracteristici de care sunt foarte mulțumită. Pe când dezvoltam fără a folosi Vagrant, pierdeam mult timp așteptând să se sincronizeze fișierele de pe mașina mea locală, cu cele de pe mașina virtuală. Cu ajutorul directivei “synced folders” pot să lucrez în timp real pe mașina virtuală. În momentul de față, comunitatea de utilizatori Vagrant este în creștere, dar este posibil ca într-un timp relativ scurt, Docker să devină cel mai folosit instrument în comunitatea de dezvoltatori.

Carmen Frățilă

carmen.fratila@3pillarglobal.com Software engineer @ 3Pillar Global

www.todaysoftmag.ro | nr. 20/Februarie, 2014

21

management

Startup marketing: provocări și repere

B

uget, echipă și în general resurse limitate, anonimat și nevoia de a crea conștientizare, uneori nevoia de a educa piața și nevoia de generare de oportunități pentru vânzare - sunt doar câteva dintre provocările cu care se confruntă deseori afacerile la început de drum. În acest context, procesul și abordarea de marketing în startup-uri are cel puțin câteva particularități, deseori semnalate în literatura de marketing și cu siguranță “trăite” de multe organizații în primele etape ale existenței.

Sorina Mone

sorina.mone@fortech.ro Marketing manager @ Fortech

22

nr. 20/Februarie | www.todaysoftmag.ro

În primul rând, poate mai mult decât alte procese, marketingul în startup-uri este inovativ. Resursele limitate pun managerii și specialiștii de marketing (dacă există persoane dedicate!) în situația de a găsi soluții la aceste neajunsuri, deseori neconvenționale. Se spune că disperarea duce la inovare. Tocmai de aceea este foarte popular în contextul startup-urilor din domeniul tehnologiei conceptul de “growth hacking”, introdus de Sean Ellis și care are în centru creativitatea și folosirea de metode neconvenționale pentru a obține creșteri rapide și spectaculoase. Sigur că nu implică reinventarea roții, ci mai degraba folosirea unor concepte și practici deja populare (precum cele din zona content marketing sau community marketing), dar într-un mod inedit, care atrage atenția și facilitează diseminarea rapidă. Produse cunoscute precum Dropbox, LinkedIn sau YouTube sunt deseori date ca exemple de growth hacking.

Apoi, abordarea este pe termen scurt.

Este oarecum firesc să fie așa: nu există un istoric al afacerii, previziunile sunt mai dificil de realizat și în plus, scopul este până la un anumit punct supraviețuirea. Din păcate uneori, și mai cu seamă în economii mai puțin mature cum este cazul țării noastre, la

acest lucru contribuie și factorii din mediul extern, în special cel macro (legislație instabilă, situația socio-economică etc.). În sfârșit, marketingul este puternic influențat de personalitatea managerului care este cel mai adesea și proprietarul afacerii (antreprenor). Deseori, cultura organizațională a unei companii tinere sau de dimensiuni reduse se conturează în jurul antreprenorului și preia caracteristicile definitorii ale personalității acestuia. În esență, nu este un aspect negativ, însă pot fi situații în care dependența prea mare de antreprenor poate determina neajunsuri. Un exemplu simplu e blocajul la nivel decizional; pot fi situații în care, în absența managerului - antreprenor, nu se iau decizii și lucrurile nu se mișcă, în condițiile în care agilitatea trebuie să fie un punct forte al unui startup.

Având în vedere aceste provocări, strategia de marketing (procesul de segmentare - țintire - poziționare și întregul mix de marketing: produs, preț, promovare, distribuție) într-un startup constă cel mai adesea din a identifica un set de priorități, a lua niște decizii și a le executa. Câteva repere sunt esențiale într-un asemenea context:

În primul rând, este necesar a se răspunde la o serie de întrebări menite a contura poziționarea produsului: Cui se adresează? Ce nevoi sau probleme rezolvă pentru acești consumatori? Ce-l diferențiază de alte produse similare existente deja pe piață (mai cu seamă că inovarea înseamnă cel mai adesea în mediul actual abordări noi sau produse modificate și mai puțin un produs total nou)? Cunoașterea cât mai detaliată a viitorului client potențial este esențială, putând furniza baza unor decizii importante inclusiv în faza de concepție și dezvoltare a produsului (decizii legate de funcționalități și caracteristici). Ca metodă practică, se recurge deseori la “creionarea” unui profil cât mai comprehensiv al consumatorului (i.e. buyer persona), care să vizeze caracteristici demografice, sociale, economice ale acestuia: vârstă, profesie, venituri, obiceiuri, ce interese are etc. .

Odată identificat consumatorul, nevoia adresată de produs și avantajul competitiv al acestei soluții, acest avantaj trebuie comunicat. Intervine aici procesul de branding, care la un nivel de bază include alegerea unui nume, formularea unor declarații de misiune și de viziune (mission and vision statements) și a unor mesaje cheie (key value propositions). În raport cu naming-ul, mai ales dacă discutăm de un produs software B2C, adresat utilizatorilor de tip consumatori individuali, e important să fie ușor de identificat și de reținut, să fie memorabil. Iar mesajele cheie, pentru a fi recepționate într-o măsură cât mai mare și a nu fi doar unele dintre numeroasele mesaje cu care un consumator este “bombardat”, e de preferat să articuleze beneficiile pentru utilizatori, soluții la probleme cu care

aceștia se confruntă, mai degrabă decât caracteristici obiective ale produsului. Nu în ultimul rând, trebuie luate în considerare aspectele de protecție a proprietății intelectuale: înregistrarea mărcii, a elementelor grafice, “parcarea” unui domeniu web dorit, a denumirilor paginilor pe rețelele sociale etc. .

Apoi urmează partea cea mai interesantă și mai provocatoare pentru un om de marketing într-un startup: generarea cererii pentru produs și crearea oportunităților de vânzare. Acțiunile care definesc această etapă pot intra într-una din cele două categorii: Outbound marketing - include acțiuni de marketing precum publicitate, e-mail marketing și telemarketing, participare la târguri, evenimente etc. - în general, eforturi de outreach către segmentele țintă.

Inbound marketing - include eforturi de marketing care, dimpotrivă, fac produsul sau compania să fie “găsite” de consumatori și nu viceversa. În sfera marketingului digital, implică dezvoltarea unui website care să atragă vizitatorii în mod natural, prin optimizare pentru motoarele de căutare, prin platformele de social media sau presă. Eforturile de inbound marketing sunt de durată, dar mai puțin costisitoare în general decât publicitatea (necesită doar capacități editoriale, creativitate și timp) și, foarte important, odată puse bazele, sunt cu efecte și rezultate pe termen lung.

Aceste lucruri nu doar că pot face diferența dintre supraviețuirea sau eșecul unui startup, ci pot oferi premisele pentru creșterea dorită. Aici intervine și growth hacking-ul, mai cu seamă dacă se dorește obținerea unor surse de finanțare pentru dezvoltarea startup-ului. Investitorii doresc

povești de succes, nu doar idei cu potențial și, mai ales, doresc afaceri sănătoase. De aceea, growth hacking-ul trebuie abordat cu precauție, întrucât numerele sunt importante, dar e important și ca acestea să aibă fundamente solide, și anume un produs de calitate, care încântă și nu dezamăgește utilizatorii. O experiență corectă cu produsul poate determina ca utilizatorii să devină principalul motor al creșterii afacerii, situația ideală pentru un startup cu planuri mărețe.

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

www.todaysoftmag.ro | nr. 20/Februarie, 2014

23

management

Clusterul Cluj IT și Antreprenoriatul

Î

Daniel Homorodean

daniel.homorodean@clujit.ro Membru în Consiliul Director @ Cluj IT Cluster

ncă din prima zi a existenței Clusterului Cluj IT ni s-a adresat întrebarea: “Ce va face Clusterul pentru sprijinirea antreprenoriatului ?” Această întrebare a venit mereu, în decursul a mai bine de un an de la înființarea Clusterului, la toate conferințele și evenimentele la care reprezentanții organizației au participat. Sigur, întotdeauna întrebarea a primit un răspuns, pe care l-am simțit mereu nesatisfăcător, nu doar în ochii celor care întrebau, ci chiar în mintea noastră, a celor din Cluster. Pentru că ne-am asumat un rol important în sprijinirea industriei IT românești, am creat și am cultivat așteptări, care trebuie îndeplinite, pentru că rezultatele vizibile și accesibile sunt cele după care suntem judecați.

Clusterul Cluj IT s-a născut dintr-o nevoie directă, din conștientizarea faptului că modul în care industria IT românească a crescut și a funcționat timp de mulți ani nu mai poate fi sustenabil pe termen lung. Avem peste 8000 de specialiști IT în Cluj, o densitate extraordinară comparativ cu populația orașului. Am ajuns aici printr-o creștere organică și relativ rapidă, mizând la început pe costul redus al forței de muncă, iar apoi pe costul competitiv în raport cu calitatea pregătirii și calitatea serviciilor programatorilor noștri. Dar a miza în continuare pe preț nu e doar o strategie periculoasă, ci una sinucigașă, în condițiile în care diferența între costul de producție dintre noi și piețele tradiționale ale IT-ului clujean ( vestul Europei și US) scade permanent.

Nu este un secret pentru nimeni că singura cale de dezvoltare pe termen lung este crearea de valoare adăugată sustenabilă, iar modul cel mai sănătos de a o face este prin crearea și valorificarea de produse bazate pe inovație.

24

nr. 20/Februarie | www.todaysoftmag.ro

Cum reușim să creăm și să valorificăm produse inovative în România ? Fără a avea un răspuns la aceasta întrebare fundamentală, fără a avea soluții conturate pentru aceasta, celelalte întrebări au răspunsuri fragile. Inovația nu este un act punctual, ci un proces. Un proces care trebuie pregătit și care trebuie executat cu maturitate și cu înțelepciune. Într-adevăr pregatirea durează mai mult decât oricare dintre noi am vrea, pentru că în sine este un proces de învățare, iar schimbarea direcției de la outsourcing la inovare necesită o schimbare de cultură. În primul an al existenței Clusterului am căutat căile de a construi fundamentul acestei schimbări.

Schimbarea de cultură este prioritară și constă în trecerea de la un mediu IT fragmentat, măcinat de neîncredere spre un mediu bazat pe cooperare între firme, universități și instituții publice. Dorim schimbare în modul în care cercetarea fundamentală ajunge să slujească unor scopuri pragmatice și lucrative, în urma transferului tehnologic, în loc să rămână

cantonată în cercul restrâns al cercetătorilor. Schimbarea s-ar impune și în cultura companiilor noastre, care nu sunt formate din “resurse” vândute la ora, ci sunt formate din oameni valoroși care pot și care vor să contribuie cu inițiative la succesul companiilor lor, și care merită să beneficieze de pe urma acestui succes.

Schimbate trebuie să fie și sistemele rigide, reticente la risc, unde locul fiecăruia este strict reglementat, în sisteme dinamice și adaptative, unde inițiativele curajoase sunt susținute și pot înflori organic. Pentru toate acestea a fost și este încă nevoie de timp.

Dar acum, după mai bine de un an în care am lucrat împreună în Cluster, chiar dacă mai puțin vizibil dinspre exterior, știm că suntem pe drumul cel bun și că putem să ne asumăm cu mai mare îndrăzneală pașii următori.

România și în mod particular Clujul se află acum într-un moment de mare efervescență a culturii start-up în IT. Avem acces la informație, avem exemple extraordinare din piețele mai dezvoltate, începem să avem oameni și organizații care coagulează aceasta mișcare, prin evenimente, centre de întălnire și co-work și chiar acceleratoare. Mai știm și că bani există, că nu e imposibil să ajungem la ei atâta timp cât putem să susținem o propunere de valoare și să convingem că avem capacitatea și maturitatea să ne punem ideile în execuție. Și mai știm că produsele inovative sunt construite și susținute de către antreprenori, pe care este esențial să îi avem și să îi sprijinim.

Acum, suntem la stadiul de maturitate organizațională pentru a putea să o facem, într-un mod relevant.

Cluj IT urmărește să fie un catalizator al mediului antreprenorial în Cluj și în România. Un factor de coagulare și facilitare a cooperării între startupuri și mediul de afaceri matur, mediul academic și factorii administrației publice. Urmărim să operăm un cadru permanent de educație antreprenorială, adresat nu doar startupurilor ci și organizațiilor mature, aflate în fața provocării de a se reinventa, de a vedea potențialul oamenilor lor și de a dezvolta antreprenoriatul intern. Termenul de intraprenoriat a fost creat tocmai pentru aceasta. Între mediul matur de business și mediul startupurilor există încă un clivaj, pe care este necesar să îl surmontăm pentru a crea un ecosistem sănătos. Firmele mature au resurse disponibile, atât umane cât și financiare, au experiență operațională, înțeleg verticalele de business, au relații parteneriale relevante și cunosc mecanismele piețelor externe pe care operează. În multe dintre ele însă structurile și procesele sunt mai rigde, există o mare reticență la risc iar inițiativa intraprenorială nu este încurajată.

De cealaltă parte, tinerii antreprenori pornesc fără resurse, fără experiență operațională, cu cunoștințe precare în domeniul segmentelor de business pe care ar dori să le servească și fără a cunoaște specificul piețelor geografice în care ideile lor s-ar putea transforma în succes. Entuziasmul este esențial, dar nu suplinește lipsa experienței, iar greutățile inerente procesului de autoeducare antreprenorială riscă să devină descurajatoare. Aceste două laturi au nevoie una de alta, iar fără o punte între ele mediul IT românesc riscă să evolueze cu opinteli, în loc să își valorifice plenar potențialul. Este foarte important pentru noi să adresăm aceasta problemă și să creăm un dialog relevant între cele două părți pentru a încuraja dezvoltarea de parteneriate.

De asemenea, schimbul de informații și cunoștinte între firmele de IT este esențial, privind metodologii și bune practici sau specificul piețelor geografice. Urmărim să facilităm accesul la consultanța relevantă venită din piețele mature, accesul la parteneri operaționali sau financiari, și la finanțare directă, în special capital de risc ( venture capital). În relația cu mediul

academic, un program permanent de brokeraj este pregătit pentru a facilita cooperarea în domeniul cercetării, direcționarea cercetării în funcție de cerințele pieței precum și transferul tehnologic în vederea realizării de produse inovative.

Avem strategie, așadar. Veți întreba desigur dacă avem și un plan. Avem, dar contează mai puțin să îl declarăm și mult mai mult să îl demonstrăm. Pentru că, după cum spun mulți investitori și antreprenori cunoscuți, ideile sunt valoroase, dar esențială este execuția.

www.todaysoftmag.ro | nr. 20/Februarie, 2014

25

interviu

Interviu cu Radu Georgescu

Î

ncepem publicarea unei serii de interviuri luate în cadrul How To Web 2013, cel mai important eveniment dedicat inovaţiei, antreprenoriatului şi tehnologiei din Europa de Sud-Est. Radu Georgescu este un cunoscut antreprenor IT din România prin construirea mai multor produse românești ce au fost achiziționate de companii importante precum: RAV Antivirus a fost cumpărat de Microsoft, Gecad ePayment de către Napster, iar ultima mare tranzacție fiind vânzarea Avangate.

Ovidiu Măţan, PMP

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

26

nr. 20/Februarie | www.todaysoftmag.ro

Q: Bună, Radu, ești unul dintre cei mai faimoși antreprenori din România! Poți să ne spui pentru cititorii revistei Today Software Magazine, cum a început totul? De la ce s-a pornit ?

Radu Georgescu: Este istorie, am pornit în 1992, am terminat facultatea, am vândut primele programe, după aceea au fost începute altele, dintre care unele au ratat.

Q: Primele aplicații au fost antiviruși?

RG: Am început prin a scrie o aplicație peste Autcad/Autodesk, după aceea am continuat cu alte trei produse, toate trei au ratat, antivirusul s-a vândut la Microsoft.

După aceea am făcut alte companii, unele au ratat, Gecad ePayments s-a vândut către Napsters.

Q: Dacă vorbim despre Gecad și faimoasa vânzare către Microsoft, poți să ne spui dacă Microsoft a fost atras de aspectul tehnic al aplicației sau a existat o parte de marketing către aceștia?

RG: Microsoft a fost interesată fix de aspectul tehnic. Microsoft a cumpărat tehnologia și pe oamenii tehnici care au venit împreună cu tehnologia.

Q: Oamenii tehnici încă lucrează la Microsoft?

RG: Absolut, dar nu din București, din Redmond. Practic compania a făcut tehnologia pentru Microsoft, iar Microsoft le-a făcut o ofertă oamenilor respectivi să se mute în Redmond și ei s-au mutat toți acolo unde sunt și acuma. Ei sunt partea principală a echipei care dezvoltă securitatea pentru Microsoft în ziua de azi.

Q: Legat de ultimul succes Avangate, poți să ne spui câteva cuvinte despre acesta ? Cât timp a durat dezvoltarea?

RG: Compania a început în 2006, de șapte ani cu o creștere de 70% anual.

Q: Clienții erau români?

RG: Compania era multinațională, cu headquarter în Statele Unite, cu birouri în România, Olanda, China, Rusia și Cambodgia.

Q: Startup-urile încep să fie la modă în România, cum vezi evoluția lor în viitor?

Ne putem aștepta ca la un moment dat să depășească outsourcing-ul ?

RG: Sunt și vicepreședinte ANIS, iar Andrei Pitiș este președinte și împreună cu el ne-am făcut un obiectiv din a convinge companiile de outsourcing să își facă în interiorul lor și o mică bucată de produs.

Cred că outsourcing-ul are următoarea problemă : este dependent în general de unul

sau doi clienți, este o vânzare ieftină de minute-om, nescalabilă, în timp ce produsul este scalabil exponențial, independent de furnizor. Încercăm să construim acest trend de migrare dinspre outsourcing spre product și sper să se întâmple lucrul acesta.

Vedem că încet, încet se întâmplă. ANIS a făcut și un studiu care s-a lansat acum două săptămâni.

Q: Care crezi că vor fi domeniile interesante, cu potențial în viitor?

RG: A fost prezentarea lui Robin azi dimineață care a fost excepțională și are multă dreptate. Nu știu, nu sunt un vizionar, nu văd viitorul, nu pot să răspund la această întrebare.

RG: Dă-mi voie să-ți adresez și eu o întrebare. De ce nu îți faci revista în engleză?

Ovidiu Mățan: Este și în engleză. De obicei cea în engleză apare cu o lună în urmă RG: Foarte tare ! Felicitări! Revistă de software făcută în România. Și ai și cititori din străinătate?

OM: Da, dar majoritatea sunt cititori din România - câteva mii- și câteva sute din străinătate. Ultima parte este tehnică, iar prima parte este despre evenimente.

RG: Mi s-ar părea foarte simpatic să faci din asta o revistă internațională cum este TechCrunch și The Next Web. Ar fi absolut senzațional să faci așa ceva !

Q: Ce părere ai despre Google Glasses și cum o să evolueze tehnologia în viitor?

Nu știu dacă Google Glasses va fi câștigătorul, dar este evident că ceea ce americanii numesc whearables vor ajunge în viața noastră. Sunt ochelarii de la Google sau din altă parte, sunt ceasurile, sunt pantofii, sunt telefoanele, sunt bentițele, habar nu am, dar cred foarte tare că ceva va ajunge.

Q: Ce părere ai despre startup-urile românești? Nu avem neapărat niște startupuri de succes.

Cum nu avem ? Este Oxygen XML, este cel mai tare tool de editat XML-uri din lume, este un business extraordinar. Nici Avangate nu părea spectaculos [..] De ce companiile bune sunt companiile provenite din Radu Georgescu și Florin Talpeș?! Sunt atâtea mii de antreprenori extraordinari. Să judecăm o companie pentru ce este ea și nu pentru omul din spate. OxygenXML, fără a avea nici o legătură cu el, se vinde pentru că este atât de bun, ce vrei mai spectaculos de atât? Puteau să facă o treabă și mai bună și să îl promoveze? Da, dar produsul acela este un produs extraordinar.

Q: Care este ingrendientul lipsă care poate lipsește startup-urilor din România?

Se construiește. Timpul este elementul lipsă. Să găsim exemple de succes.Oamenii să construiască, oamenii ratează, iar noi trebuie să învățăm din experiențele rateurilor mele, ale tale, ale oamenilor și să începem să încercăm din ce în ce mai mult.

Se construiește infrastructura de angel

investment, se construiește infrastructura de VC-uri, se construiesc evenimente, totul se construiește și în timp va fi. Gândește-te l a Mave n Hut , U b e r v u, S of tp e d i a , gândește-te la Emi Gal. Toți sunt exemple de succes.

Q: Există o rețetă de success?

Ceea ce încerc eu împreună cu Andrei este să convingem companiile de outsourcing, care sunt chiar cele care pot să facă asta, să își construiască mici produse care să takeover.

Q: Un sfat pentru tinerii care vor să își facă un startup ?

Nu dau sfaturi, nu îmi permit să dau sfaturi. Nu poți să dai sfaturi generale de la înțelepții pământului.

www.todaysoftmag.ro | nr. 20/Februarie, 2014

27

startups

programare

Restricted Boltzmann Machines

D

upă ce în articolul trecut am prezentat pe scurt istoria deep learning-ului și am enumerat câteva dintre tehnicile care se folosesc, acum voi oferi detalii despre părțile componente ale unui sistem de deep learning.

Deep learning a obținut primul succes în 2006, când Geoffrey Hinton și Ruslan Salakhutdinov au publicat articolul „Reducing the Dimensionality of Data with Neural Networks”, care a fost prima aplicare eficientă și rapidă a mașinilor Boltzmann restrânse (Restricted Boltzmann Machines sau, pe scurt, RBM).

După cum sugerează și numele, RBM-urile sunt un fel de mașini Boltzmann, cu anumite constrângeri. Acestea au fost propuse de Geoffrey Hinton și Terry Sejnowski în 1985 și au fost primele rețele neuronale care puteau să învețe reprezentări interne (modele) ale datelor de intrare și să se folosească de aceasta pentru a rezolva apoi diferite probleme, cum ar fi completarea de imagini incomplete. Ele nu au fost folosite multă devreme deoarece, în lipsa unor constrângeri, algoritmul de învățare a reprezentării interne era foarte ineficient.

Conform definiției, mașinile Boltzmann sunt rețele neuronale recurente stochastice generative. Stochasticitatea lor înseamnă că au un element probabilistic în ele și neuronii din rețea nu sunt activați în mod deterministic, ci cu o anumită probabilitate, în funcție de intrările lor. Faptul că sunt generative înseamnă că învață distribuția de probabilitate a variabilelor de intrare și construiesc un model pentru acestea, care poate fi folosit apoi pentru a genera alte date aleatorii, similare celor cu care au fost antrenate.

Dar există și un alt mod de a privi mașinile Boltzmann, ca fiind modele grafice bazate pe energie. Aceasta înseamnă că fiecărei combinații de date de intrare asociem un număr, numit „energie”, iar pentru combinațiile pe care le avem între datele de intrare dorim ca energia să fie cât mai mică, iar pentru toate celelalte să fie cât mai mare.

care generează stratul de intrare. Dacă analizăm notele date de utilizatori unor filme, atunci stratul de intrare corespunde notelor date de un utilizator la mai multe filme, iar stratul ascuns corespunde categoriilor de filme. Aceste categorii nu sunt predefinite, ci RBM-ul construiește un model intern în care grupează filmele astfel încât energia totală să fie minimizată. Dacă datele de intrare sunt pixeli ai unei imagini, atunci putem considera stratul ascuns drept trăsături ale obiectelor care generează acei pixeli (cum ar fi margini de obiecte, colțuri, linii drepte și alte trăsături care diferențiază obiectele).

Privind RBM-urile ca modele bazate pe energie, putem să ne folosim de tehnici preluate din fizica statistică ca să estimăm distribuția de probabilitate și apoi să facem predicții. De altfel, partea de Boltzmann din nume vine de la faptul că distribuția pe care o va învăța este de tip Boltzmann, o distribuție clasică din fizica statistică.

Energia unui astfel de model, știind vectorul v (stratul de intrare), vectorul h (stratul ascuns), matricea W (ponderile asociate fiecărei conexiuni dintre un neuron din stratul de intrare și cel ascuns), și vectorii a și b (care corespund pragurilor de activare specifice fiecărui neuron din stratul de intrare, respectiv stratul ascuns) este dată de următoarea formulă:

Deși pare urâtă formula, este vorba doar de adunare și înmulțire de matrici.

Odată ce avem energia pentru o stare, probabilitatea ei este dată de:

Z este un factor de normalizare, ca să dea bine probabilitățile.

Model grafic pentru un RBM cu 4 unități de intrare și 3 unități ascunse.

Constrângerea impusă asupre RBM-urilor este că neuronii trebuie să formeze un graf bipartit, ceea ce în practică înseamnă că nu există legături între neuronii din stratul vizibil, nici între neuronii din stratul ascuns, ci doar între cele două straturi. În figura de alături se observă că nu avem conexiuni între v-uri, nici între h-uri, ci doar între fiecare v cu fiecare h.

Stratul ascuns din RBM se poate considera ca fiind factorii

28

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

Aici este unul din locurile unde constrângerile din RBM ne ajută. Pentru că neuronii din stratul vizibil nu sunt conectați între ei înseamnă că dacă fixăm neuronii din stratul ascuns, atunci neuronii din stratul vizibil sunt independenți unii de alții. Așa că putem obține ușor probabilitatea unor date de intrare pentru o valoare fixă a neuronilor din stratul ascuns:

unde neuron:

reprezintă probabilitatea de activare a unui singur clasificarea notițelor sau pentru recomandare de muzică. În continuare vom prezenta ce ușor se poate antrena un RBM pe un set de imagini care conțin litere și cifre, după care vom vizualiza filtrele pe care le învață acesta. este funcția logistică

În mod analog se poate defini și probabilitatea pentru stratul ascuns, având stratul vizibil fixat.

from sklearn.neural_network import BernoulliRBM as RBM import numpy as np import matplotlib.pyplot as plt import cPickle X,y = cPickle.load(open(„letters.pkl”)) X = (X - np.min(X, 0)) / (np.max(X, 0) + 0.0001) 0-1 scaling rbm = RBM(n_components=900, learning_rate=0.05, batch_size=100, n_iter=50) print(„Init rbm”)

#

rbm.fit(X)

La ce ne ajută dacă știm aceste probabilități?

Să presupunem că știm valorile corecte ale ponderilor și ale pragurilor de activare a neuronilor pentru un RBM și că vrem să vedem ce obiecte sunt într-o imagine. Punem pixelii imaginii ca fiind intrările RBM-ului și calculăm probabilitățile de activare pentru stratul ascuns. Aceste probabilități le putem interpreta drept filtre pe care le-a învățat RBM-ul despre obiectele care pot exista în imagini.

Luăm valorile probabilităților, și le introducem într-un alt RBM ca date de intrare. Acest RBM scoate și el la rândul lui alte probabilități, care sunt filtre pentru intrările lui. Aceste filtre sunt de un nivel mai înalt deja. Repetăm acest procedeu de câteva ori, punem unul peste altul RBM-urile, peste ultimul strat punem un strat de clasificare (chiar și regresia logistică funcționează bine) și obținem un Deep Belief Network.

plt.figure(figsize=(10.2, 10)) for i, comp in enumerate(rbm.components_): plt.subplot(30, 30, i + 1) plt.imshow(comp.reshape((20, 20)), cmap=plt. cm.gray_r, interpolation=’nearest’) plt.xticks(()) plt.yticks(()) plt.suptitle(‚900 components extracted by RBM’, fontsize=16) plt.show()

O parte din filtrele învățate de RBM. Se observă filtre pentru literele B, R, S și pentru cifrele 0, 8, 7 și altele

Antrenare într-un mod greedy a unui DBN

Ideea care a stat la baza revoluției deep learning a fost aceasta: că poți învăța strat cu strat filtre pentru trăsături tot mai complexe și astfel la sfârșit nu mai clasifici ce este într-o poză direct din pixeli, ci din trăsături de nivel înalt, care sunt mult mai bune indicatore pentru conținutul unei poze. Învățarea parametrilor unui RBM se face cu un algoritm numit „contrastive divergence”. Acesta pornește cu un exemplu din datele de intrare, calculează valorile pentru stratul ascuns, pentru ca din aceste valori obținute pentru stratul ascuns să se simuleze apoi ce valori de intrare au produs. Parametrii sunt apoi schimbați cu diferența dintre valoarea originală și valoarea simulată (sub formă de produs matriceal). Aceasta se repetă pentru fiecare exemplu din datele de intrare, de mai multe ori, până când fie eroarea devine suficient de mică, fie au trecut un număr predefinit de iterații.

RBM-urile sunt implementate în multe librării de învățare automată. Una dintre acestea este scikit-learn, o librărie Python care este folosită de firme cum ar fi Evernote sau Spotify pentru

RBM-urile sunt o componentă esențială de la care a pornit deep learning-ul și sunt unul din puținele modele care ne permit să ne construim eficient o reprezentare internă a problemei pe care dorim să o rezolvăm. În articolul următor, vom vedea o altă abordare la învățarea reprezentărilor interne, cu autoencodere.

Roland Szabo

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

www.todaysoftmag.ro | nr. 20/Februarie, 2014

29

programare

Maven, The Definitive Guide

V

oi începe această recenzie prin a clarifica ce este Maven. Conform site-ului oficial: http://maven.apache.org, Maven, care este un produs Apache, reprezintă un instrument de gestiune a unui proiect software. Gestiunea cuprinde construirea, raportarea şi documentarea unui proiect, bazându-se pe conceptul de POM (Project Object Model). Un POM este unitatea fundamentală de lucru în Maven şi este de fapt un fişier XML, ce conţine informaţii despre proiect şi detaliile de configurare, folosite în construirea proiectului.

Maven este unul dintre cele mai cunos- proiectul pentru a-l aduce aproape de o ciclu de viaţă al unui build. Autorii, ca şi cute project builder-e, alături poate de Ant, formă reală. Aceasta înseamnă adăuga- în cazul lui POM, descriu mai multe tipuri un produs tot Apache. Deosebirile majore rea de dependenţe, resurse şi unit teste. de cicluri de viaţă, cititorul fiind îndemîntre acestea două constau în faptul că Ant Proiectul, din punctul de vedere al compo- nat să le citească: Clean Lifecycle, Default este orientat doar spre procesare, compi- nentelor Java, va conţine un servlet simplu, Lifecycle, Site Lifecycle. lare, împachetare, testare şi distribuţie. Pe pe care îl vom introduce într-un proiect Un profil de build ne permite să custolângă capabilităţile de build, amintite ante- multimodul. mizăm un build pentru un anumit mediu, rior, Maven poate rula rapoarte, genera În capitolele următoare se vor crea asigurând astfel portabilitatea între aceste rapoarte sau facilita comunicarea între proiecte enterprise complexe, folosind fra- medii. Cele considerate în carte sunt: promembrii unei echipe de lucru. mework-urile Spring şi Hibernate. Nu este ducţia şi dezvoltarea. Capitolul unsprezece Dacă rolul fundamental al lui Maven obligatoriu să fii un bun cunoscător al aces- aduce în discuţie conceptul de profil de este acela de a pune împreună compo- tor tehnologii. Ideile abordate sunt simple. build. În primul rând aflăm cât este de nente, ce fac parte dintr-un proiect, putem Accentul se pune aproape exclusiv pe con- importantă portabilitatea, cât de mult afirma cu certitudine că ştiu proiecte de struirea fişierelor de Maven. influenţează portabilitatea performanţele succes care nu folosesc Maven pentru Partea a treia aduce în discuţie ideea de proiectului şi care este nivelul potrivit de aceste scopuri. Fie că fişierele Maven sunt performanţă. Dacă până în acest moment portabilitate. generate şi rulate automat, fie că nu există ne-am familiarizat cu conceptele Maven şi Maven Assemblies sunt discutate în pur şi simplu Maven. Dependenţa directă a am construit un proiect enterprise simplu, capitolul doisprezece şi aprofundate în diverselor componente elimină într-o mare dar cuprinzător, de acum încolo autorii capitolul treisprezece. Aşadar, putem crea măsura folosirea acestui instrument. încearcă să deschidă cititorilor drumul o paletă largă de arhive: JAR, WAR, EJB sau Revenind la cartea care reprezintă spre îmbunătăţirea controlului asupra EAR. Asamblarea este un proces complex obiectul acestei recenzii, Maven The dependenţelor şi plugin-urilor pentru a ce necesită descriptori cu o structură comDefinite Guide, apărută la O’Reilly în anul uşura mentenanţa viitoare a construcţiilor. plicată, dar descrisă amănunţit în această 2008, aceasta este un ghid complet de înţe- Curăţarea POM-ului, optimizarea depen- carte. legere şi folosire a Maven-ului. denţelor şi a plugin-urilor sunt tehnici de Capitolul patrusprezece este un ghid Primele două capitole, care constituie minizare a duplicărilor, cu un rol esenţial excelent de utilizare al Maven-ului folosind şi prima parte, sunt o scurtă introducere în evitarea problemelor viitoare.

Eclipse. în Maven, dar care aduc şi detalii foarte Capitolul nouă oferă o analiză amăUltimele capitole prezintă detaliat etaimportante de instalare şi rulare pe toate nunţită referitoare la conceptul şi suportul pele generării unui site folosind Maven, un platformele (acestea includ Mac, Windows, fizic POM. Analogia, pentru începători, o Repository Manager respectiv scrierea de Linux, FreeBSD sau Open BSD). fac cu fişierul web.xml din Java. Aşa cum plugin-uri.

Partea a doua este centrată pe exem- descrie aceasta, configurează şi custoAștept cu mare plăcere comentariile și ple. Exemplele pornesc gradual şi ajung să mizează aplicaţia, în acelaşi fel pom.xml discuţiile cititorilor pe programez.ro. constituie o sursă suficientă de informaţie defineşte proiectul Maven. Probabil că citiVă doresc lectură placută! pentru a utiliza cu succes Maven. Pe lîngă torii vor descoperi cu plăcere conceptele Silviu Dumitrescu explicaţii, autorii furnizează exemple, care pe care autorii le introduc ca aparținând silviu.dumitrescu@msg-systems.com pot fi descărcate. sferei POM: Super POM, Simplest POM, Consultant Java După dezvoltarea primului proiect, Effective POM, Real POM şi nu în ultimul @ msg systems Romania simplu, dar cu importante clarificări teo- rând POM best practices. retice, vom avea ocazia să customizăm Capitolul zece clarifică noţiunea de

30

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

programare

Multithreading în standardul C++11 (II)

Î

n exemplele anterioare am prezentat și analizat metode de protejare a datelor comune între mai multe thread-uri. Uneori însă nu este suficientă doar protejarea datelor comune, fiind necesară și sincronizarea operațiilor executate de diferite thread-uri. În general se dorește ca un thread să aștepte până când are loc un anumit eveniment sau până când o anumită condiție devine adevărată. În acest scop, librăria standard C++ oferă primitive precum variabilele condiționale și futures.

Dumitrița Munteanu

dumitrita.munteanu@arobs.com Software engineer @ Arobs

Var i abi l e l e c on d iț i on a l e au î n standardul C++11 nu o singură implementare, ci două: std::condition_variable și std::condition_variable_any. Ambele implementări pot fi folosite prin includerea header-ului <condition_variable>. Pentru a facilita comunicarea între threaduri, variabilele condiționale sunt, de obicei, asociate cu un mutex, pentru std::condition_variable sau cu orice alt mecanism care oferă excludere mutuală, pentru std::condition_variable_any.

Thread-ul care așteaptă ca o variabilă condițională să devină adevărată trebuie, mai întâi, să blocheze un mutex, folosind primitiva std::unique_lock, a cărei necesitate o vom vedea ulterior. Mutex-ul este deblocat atomic atunci când thread-ul începe să aștepte ca variabila condițională să devină adevărată. În momentul în care se primește o notificare relativă la variabila condițională, thread-ul este repornit, blocând din nou mutex-ul.

Un exemplu practic poate fi un buffer care este folosit pentru a transmite date între două thread-uri:

std::mutex mutex; std::queue<buffer_data> buffer; std::condition_variable buffer_ cond; void data_preparation_thread() { while(has_data_to_prepare()) //-- (1) { buffer_data data = prepare_ data(); std::lock_quard<std::mutex> lock(mutex); //-- (2) buffer.push(data); buffer_cond.notify_one(); //-- (3) } } void data_processing_thread() { while(true) { std::unique_lock<std::mutex> lock(mutex); //-- (4) buffer_cond.wait(lock, [] {return ! buffer.empty()}) //-(5) buffer_data data = buffer. front(); buffer.pop(); lock.unlock(); //-- (6) process(data); if(is_last_data_entry(data)) break; } }

www.todaysoftmag.ro | nr. 20/Februarie, 2014

31

programare Multithreading în standardul C++11 (II) Atunci când datele sunt pregătite de procesare (1), thread-ul care pregătește datele blochează mutex-ul (2), pentru a proteja buffer-ul când adaugă noile valori. Apoi apelează medota notify_one() asupra variabilei condiționale buffer_cond (3) pentru a notifica thread-ul care aștepta date (dacă este vreunul) că buffer-ul conține date ce pot fi procesate.

Thread-ul care procesează datele din buffer mai întâi blochează mutex-ul dar, de data aceasta, folosește un std::unique_lock (4). Thread-ul apelează apoi metoda wait() asupra variabilei condiționale buff_cond, trimițându-i ca parametri obiectul lock și o funcție lambda care reprezintă condiția pentru care se așteaptă (5). Funcțiile lambda sunt o altă caracteristică specifică standardului C++11 care permit ca funcții anonime să fie parte din alte expresii. În acest caz funcția lambda []{return ! buffer.empty()} este scrisă inline în codul sursă și verifică dacă în buffer sunt date ce pot fi procesate. Metoda wait() verifică apoi dacă condiția este adevărată (apelând funcția lambda care i-a fost transmisă) și returnează rezultatul. Dacă condiția nu este îndeplinită (funcția lambda returnează false), atunci funcția wait deblochează mutex-ul și pune thread-ul într-o stare de blocare sau așteptare. Când variabila condițională este notificată prin apelul funcției notify_one() din data_preparetion_thread(), thread-ul care procesează datele este deblocat, reblochează mutex-ul și verifică condiția din nou, ieșind din metoda wait() cu mutex-ul încă blocat dacă condiția este îndeplinită. Dacă condiția nu este îndeplinită, thread-ul deblochează mutex-ul și așteaptă din nou. Acesta este motivul pentru care se folosește std::unique_lock, deoarece thread-ul care procesează date trebuie să deblocheze mutex-ul în timp ce așteaptă, pentru ca apoi să îl blocheze din nou. În acest caz std::lock_guard nu furnizează această flexibilitate. Dacă mutex-ul ar rămâne blocat în timp ce thread-ul care așteaptă date de procesare este blocat, atunci thread-ul care pregătește datele nu ar putea bloca mutex-ul pentru a insera în buffer noile valori iar thread-ul ce procesează datele nu ar avea niciodată condiția îndeplinită.

Flexibilitatea de a debloca un obiect std::unique_lock nu este folosită doar în apelarea metodei wait(), ci este, de asemenea, folosită atunci când datele sunt pregătite de procesare dar înainte de a fi procesate (6). Aceasta deoarece buffer-ul este folosit doar pentru a transfera datele de la un thread către celălalt. Dar în acest caz nu este indicat să blocăm mutex-ul pe durata procesării datelor, deoarece ar putea fi o operație costisitoare în timp.

Futures

Un alt mecanism de sincronizare este un future, adică un obiect returnat asincron (un obiect care citește un rezultat al unei stări comune mai multor thread-uri) implementat în librăria standard C++11 prin intermediul a doua clase template, declarate în header-ul <futures>: unique futures (std::future<>) și shared futures (std::shared_future<>), ambele fiind modelate după mecanismele std::unique_ptr si std::shared_ptr.

Spre exemplu, să presupunem că avem o operație care efectuează un calcul foarte costisitor în timp iar rezultatul operației nu este imediat necesar. În acest caz putem porni un nou thread care să efectueze operația în background , dar aceasta presupune că este nevoie ca rezultatul să fie transferat înapoi metodei din care thread-ul a fost lansat, deoarece obiectul std::thread nu include un mecanism pentru această situație. Aici intervine funcția template std::async, inclusă de asemenea în header-ul <future>.

Un obiect std::async este folosit pentru a lansa o operație asincronă al cărei rezultat nu este imediat necesar. În loc să așteptăm

32

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

ca un obiect std::thread să își încheie execuția furnizând rezultatul operației, funcția std::async returnează un std::future, care poate incapsula rezultatul operației. Când rezultatul este necesar, se poate apela metoda get() pe obiectul std::future(), iar thread-ul se blochează până când obiectul future este ready, adică poate furniza rezultatul operației. Spre exemplu: #include <future> #include <iostream> int long_time_computation(); void do_other_stuff(); int main() { std::future<int> the_result = std::async(long_time_computation); do_other_stuff(); std::cout << “The result is ” << the_result.get() << std::endl; }

Un obiect std::async este o utilitate de nivel înalt care furnizează un rezultat asincron și care se ocupă intern de crearea unui provider asincron și de pregătirea datelor comune când operația se finalizează. Acest obiect poate fi emulat prin intermediul unui obiect std::package_task (sau std::bind si std::promise) și un std::thread, însă folosirea unui obiect std::async este mai sigură și mai ușoară.

Packages

Un obiect std::package face legătura dintre o funcție și un obiect apelabil. Atunci când obiectul std::package<> este apelat, acesta apelează la rândul său funcția asociată sau obiectul apelabil și pregătește obiectul future în starea ready, cu valoarea returnată de către operația efectuată ca valoare asociată. Acest mecanism poate fi utilizat spre exemplu atunci când se dorește ca fiecare operație să fie executată de un thread separat sau să ruleze secvențial pe un thread în background. Dacă o operație de mari dimensiuni se poate divide în mai multe suboperații, fiecare dintre acestea poate fi mapată într-o instanță std::package_task<>, care va fi returnată managerului de operații. Astfel, se abstractizează detaliile operațiilor iar managerul operează doar cu instanțe std::package_task<>, în loc de funcții individuale. Spre exemplu: #include <future> #include <iostream> int execute(int x, int y) { return std::pow(x,y); } void main() { std::packaged_task<int()> task(std::bind(execute, 2, 10)); std::future<int> result = task.get_future(); //-- (1) task();

//-- (2)

std::cout << „task_bind:\t” << result.get() << ‚\n’; //-- (4) }

Când obiectul std::packaged_task este apelat (2), implicit este apelată și funcția asociată cu acesta, execute, căreia i se transmit parametrii 2 și 10 iar rezultatul operației va fi salvat asincron în obiectul std::future (1). Astfel, este posibil să incapsulăm o operație într-un std::package_task și să obținem obiectul std::future, care conține rezultul operației înainte ca obiectul std::package_task să fie apelat. Când rezultatul operației este necesar, acesta se poate obține atunci când obiectul std::future este în starea ready (3).

TODAY SOFTWARE MAGAZINE Promises

Așa cum am văzut la secțiunea Futures, transmiterea datelor între thread-uri se poate efectua prin transmiterea acestora ca parametri către funcția threadului iar obținerea rezultatului se poate obține prin returnarea argumentelor prin referință, utilizând metoda async().

Un alt mecanism pentru transmiterea datelor rezultate în urma operatiilor efectuate de diferite thread-uri este folosirea unei perechi std::promise/std::future. Un obiect std::promise<T> oferă un mecanism pentru a seta o valoare de tip T, care poate fi ulterior citită prin intermediul unui obiect std::future<T>. În timp ce un obiect std::future permite accesarea datelor rezultat (folosind metoda get()), obiectul promise este responsabil pentru furnizarea datelor (folosind una dintre medotele set_...()). Spre exemplu: #include <future> #include <iostream> void execute(std::promise<std::string>& promise) { std::string str(“processed data”); promise.set_value(std::move(str)); //-- (3) } void main() { std::promise<std::string> promise; //-- (1) std::thread thread(execute, std::ref(promise)); //-- (2) std::future<std::string> result(promise.get_future()); //-- (4) std::cout << „result: „ << result.get() << std::endl; //-- (5) }

După includerea header-ului <futures>, unde sunt declarate obiectele std::promise, se declară un obiect promise specializat pentru valoarea pe care trebuie să o păstreze, std::string (1). Intern, obiectul std::promise creează o stare comună (shared state) care este utilizată pentru a salva valoarea corespunzătoare tipului std::string și care este utilizată de către obiectul std::future pentru a obține această valoare, ca rezultat al operației thread-ului.

Această promisiune este apoi transferată cu rol de parametru către funcția unui thread separat (2). În interiorul thread-ului se setează valoarea obiectului promise (3), moment în care starea comună devine automat ready. Pentru a obține valoarea setată în funcția execute, este necesară utilizarea unui obiect std::future care să aibă aceeași stare comună cu obiectul std::promise (4). Odată creat obiectul future, valoarea acestuia se poate obține prin apelarea metodei get() (5). Este important de știut faptul ca thread-ul curent (main) rămâne blocat până când starea comună este ready (atunci când este executată metoda set_value (3)), adică datele sunt disponibile.

Utilizarea obiectelor std::promise nu se adresează în exclusivitate programării multithreading. Acestea se pot folosi și în aplicațiile cu un singur fir de execuție, pentru a păstra o valoare sau o excepție care urmează să fie procesată mai târziu prin intermediul unui std::future.

deoarece în acest caz se folosește o tehnică lock-free, mult mai economică decât utilizarea unui mutex care poate fi relativ costisitor în termeni de resurse și latență datorată excluderii mutuale.

Operațiile principale oferite de clasa std::atomic sunt funcțiile de store și load, care setează și returnează atomic valorile stocate în obiectul std::atomic. O altă metodă specifică acestor obiecte este funcția exchange, care setează o nouă valoare pentru obiectul atomic returnând în același timp valoarea setată anterior. De asemenea, mai sunt două metode compare_exchange_weak și compare_exchange_strong care efectuează schimbări atomice, numai dacă valoarea curentă este egală cu valoarea actuală așteptată.

Aceste ultime două funcții pot fi folosite pentru implementarea algoritmilor lock-free. Spre exemplu: #include <atomic> std::atomic<int> counter = 0; //-- (1) void increment() { ++counter; //-- (2) } int query() { return counter.load(); }

În acest exemplu se include mai întâi header-ul <atomic> unde este declarată clasa template std::atomic<>. Apoi se declară un obiect atomic counter (1). În principiu, se poate folosi orice tip trivial, integral sau un tip pointer cu rol de parametru pentru template. Atenție la inițializarea obiectului std::atomic<int> ! Acesta trebuie inițializat întotdeauna, deoarece constructorul default nu îl inițializează complet. Spre deosebire de exemplul de la secțiunea Mutex, în acest caz variabila counter poate fi incrementată direct, fără necesitatea utilizării mutex (2), deoarece atât funcțiile membre obiectului std::atomic cât și operațiile triviale precum asignările, conversiile automate, incrementările, decrementările sunt garantate să se execute atomic.

Este indicat să se folosească tipurile atomice atunci când se dorește utilizarea operațiilor atomice, în special asupra tipurilor integrale.

Concluzii

Am prezentat în linii generale modalitățile de folosire a thread-urilor în standardul C++11, acoperind atât aspecte despre managementul thread-urilor cât și mecanisme de sincronizare a datelor și operațiilor folosind mutex-uri, variabile condiționale, futures, promises, packed tasks și tipuri atomice. După cum se poate observa, utilizarea thread-urilor din librăria standard C++ nu este dificilă, urmând practic aceleași mecanisme de utilizare ca și thread-urile din libraria Boost. În schimb, complexitatea crește odată cu complexitatea și design-ul codului care trebuie să se comporte conform așteptărilor. Pentru o aprofundare a celor discutate dar și o extindere a cunoștințelor referitoare la noile concepte disponibile în standardul C++11, recomand cu încredere cartea lui Atomics Anthony Williams, C++ Concurency in Action, precum și ultima Pe lângă mecanismele de excludere mutuală prezentate ante- ediție a clasicei The C++ Standard Library, de Nicolai Josuttis. Veți rior, standardul C++11 introduce și tipurile atomice. găsi acolo nu doar o detaliere a subiectelor prezentate anterior ci Un tip atomic std::atomic<T> se poate folosi cu orice tip T și și descrierea altor caracteristici specifice standardului C++11, garantează că orice operație asupra obiectului std::amotic<T> va incluzând tehnici de utilizare ale acestora, pentru programarea fi atomică, adică se va executa în întregime sau deloc. multithreding la un nivel avansat.

Un avantaj al folosirii tipurilor atom i c e p e nt r u e x c lu d e re mutu a l ă e s t e p e r for m anț a , www.todaysoftmag.ro | nr. 20/Februarie, 2014

33

programare

Metrici în Visual Studio 2013

Î

n articolul din numărul trecut am analizat modul cum putem să măsurăm metricele software folosind Sonar. Acesta este un tool care poate fi util liderului echipei cât și restului echipei. Orice membru din echipă poate extrem de ușor să verifice pe interfața web a Sonar-ului care este valoarea la diferite metrice.

Dacă folosim ca mediu de dezvoltare Visual Studio 2013 vom descoperi că avem opțiunea de a calcula o parte dintre metrici direct din Visual Studio, fără să fim obligați să folosim alte aplicații sau tool-uri. În cadrul acestui articol vom descrie metricele pe care le putem calcula folosind direct ceea ce ne pune la dispoziție Visual Studio.

să ofere dezvoltatorilor date despre proiect și codul pe care l-au scris, înainte ca aceștia să îl înainteze spre source control. Pe baza acestei analize putem să identificăm posibile probleme legate de: • Design, • Performanță, • Securitate, • Globalizare, De ce ar trebui să rulăm un astfel de • Interoperabilitate, tool?

• Cod duplicat, Acest tip de tool ne ajută să detectam • Cod care nu este folosit. posibilele probleme pe care aplicația noastră le are, informându-ne în același timp și Sau multe alte probleme. Totul ține asupra calității codului pe care l-am scris. și de abilitatea pe care o are dezvoltatoAșa cum se va vedea în rândurile de mai rul pentru a interpreta aceste metrice. Un jos, toate regulile și recomandările pe care aspect interesant la acest analizator este Microsoft le are legate de cod se regăsesc faptul că toate regulile și recomandările pe în acest tool. care Microsoft le are legate de cod, de stiO parte dintre defectele pe care le des- lul codului și de modul în care trebuie să coperă un astfel de tool sunt uneori extrem folosim diferite clase și metode se regăsesc de greu de găsit folosind unit teste. Datorită în acest analizator. Toate aceste reguli sunt unui tool de acest gen, putem avea certitu- grupate în diferite categorii. dinea că aplicația pe care o scriem este de Prin acest mod identificăm cu ușurință calitate. zone din aplicația noastră care nu folosesc un API așa cum ar trebui. În cazul în care Ce metrice putem să obținem? doriți să creați o regula specifică veți avea Începând cu Visual Studio 2013, toate nevoie de Visual Studio 2013 Premium sau versiunile de Visual Studio (mai puțin Ultimate. Aceste două versiuni de Visual Visual Studio Test Professional) ne oferă Studio ne permit să adăugăm reguli noi, posibilitatea să calculăm metricele direct specifice proiectului sau companiei în care din el. De la bun început trebuie să știm că lucrăm. Odată aceste reguli adăugate, analinumărul de metrici pe care le putem cal- zatorul de cod va verifica dacă acestea sunt cula folosind Visual Studio este limitat. respectate, avertizându-ne în cazul unei Din păcate, nu avem posibilitatea să cal- abateri de la reguli. Din păcate în acest culăm toate metricele care sunt disponibile moment putem să analizăm doar codul în Sonar, dar există câteva extensii pentru scris C#, F#, VB și C/C++.

Visual Studio care ne ajută să calculăm și O parte dintre cititori ar putea să spună alte metrice, nu doar pe cele care există în că acest lucru se putea face și în versiunile Visual Studio. mai vechi de Visual Studio. Se poate subVisual Studio ne permite să calculăm o scrie la afirmația lor, dar trebuie adăugat că parte dintre metrice folosind Static Code această nouă versiune (2013) a adus în plus Analysis. Acesta analizează codul încercând posibilitatea de a analiza codul fără să fie

34

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

nevoie să îl executăm. Acest lucru se putea mai mult sau mai puțin și în Visual Studio 2012.

Cum rulăm acest tool?

Aceste tool-uri pot să fie rulate în diferite moduri, atât manual din meniul “Analyze” cât și în mod automat. Pentru a le putea rula în mod automat este nevoie să selectăm opțiunea de “Enable Code Alalysis on Build” pentru fiecare proiect pe care dorim să îl analizăm.

O altă opțiune destul de interesantă este să activăm din TFS un policy prin care dezvoltatorul să fie obligat să ruleze acest analizator înainte ca acesta să poată să facă check-in pe TFS. Această opțiune se poate activa din zona “Check-in Policy”, unde este nevoie să adăugăm o nouă regulă de tip “Code Analysis”.

Trebuie să conștientizăm că enforsarea unei astfel de reguli nu ne garantează că dezvoltatorul își va citi raportul care se generează și că va ține cont de el. Tot ceea ce ni se garantează este că acest raport a fost generat. De aceea fiecare echipă trebuie educată să valorifice aceste rapoarte și să le analizeze în momentul în care ne decidem să folosim astfel de tool-uri. În momentul în care facem enforce la acestă regulă avem posibilitatea să selectăm ce reguli nu trebuie încălcate când se face un chec-in pe TFS. De exemplu, nu se va putea face check-in pe TFS la un cod ce foloseste o instanță a unui obiect ce implementează IDisposable fără să apeleze și metoda Dispose.

Când dezvoltatorul va încerca să facă check-in la un cod care nu respectă una dintre reguli, va primi o eroare care nu îi va permite să trimită pe TFS modificarea fără să rezolve problema.

La fel de bine, avem posibilitatea să

TODAY SOFTWARE MAGAZINE rulăm acest tool și ca parte din buid. Pentru avem la dispoziție alte două aceasta este nevoie să activăm această tool-uri interesante. opțiune din Build Definition.

Ce ne spune Code Analysis?

Rezultatul rulării acestui tool este un set de warning-uri. Cele mai importante informații pe care un warning le conține sunt: • Titlul: tipul de warning; • Descriere: o scurtă descriere a warning-ului; • Categoria: categoria din care face parte; • Acțiunea: ce putem face pentru a putea rezolva problema;

Fiecare warning ne permite să navigăm exact la linia de cod unde este această problemă. În plus, pentru fiecare warning avem un link la MSDN care prezintă în detaliu cauza warning-ului și ceea ce putem face pentru a-l elimina.

Cum putem să creăm reguli custom?

Așa cum am menționat în rândurile de mai sus, crearea de reguli custom se poate face doar din Visual Studio Premium sau Ultimate. Apoi este nevoie să mergem în “New>File>General>Installed Templates>Code Analysis Rule Set”.

Odată ce avem o regulă blank, putem să specificăm diferite proprietăți pe care noi dorim să le aibă.

Pe lângă acest tool în Visual Studio

Code Clones

Acest tool ne permite să detectăm automat codul care este duplicat. Important de precizat este că există mai multe tipuri de cod duplicat (clonat) pe care acesta poate să îl detecteze: • Exact match: când codul este exact la fel, fără nici un fel de diferență.

• Stron match: codul este asemănator, dar nu 100% (de exemplu diferă prin valoarea unui string sau prin acțiunea care se execută pe un anumit caz) .

• Medium match: codul este la fel, destul de asemănator, dar există câteva diferențe.

• Weak match: codul este puțin asemănător, șansele ca acest cod să fie duplicat sunt cele mai mici.

nivelul de moștenire a unei clase.

Asemenea metricii class coupling, cu cât valoarea este mai mică cu atât este mai bine.

• Cyclomatic Complexity indică nivelul de complexitate a unei clase, a unui proiect. Trebuie avut grijă deoarece, dacă implementăm un algoritm complex, atunci vom avea întotdeauna această metrică cu o valoare relativ mare.

• Maintainability Index: este o valoare între 0 și 100 care ne indică cât de ușor se poate întreține codul respectiv. O valoare mare indică că avem mari probleme (peste 20). Orice valoare sub 10 indică zonă bună, iar tot ceea ce este între 10 si 20 este de nivel mediu. Nu este grav, dar trebuie să avem grijă. Această metrică se calculează pe baza altor metrice.

Pe lângă aceste informații, putem să știm pentru fiecare cod duplicat, în câte locații acesta este duplicat și putem naviga până la linia de cod unde acesta apare. O altă metrică eficientă este numărul total de linii duplicat (clonat). Apelând la această Concluzie metrică ne putem da seama destul de ușor În acest articol am descoperit că și de câte linii de cod am putea să scăpăm.

Visual Studio ne pune la dispoziție diferite metode pentru a verifica calitatea codului.

Code Metrics Unele dintre aceste tool-uri sunt disponiPrin intermediul acestui tool analizăm bile în versiuni normale de Visual Studio, fiecare proiect pe care îl avem în soluție iar altele doar în varianta Ultimate. În și extragem diferite metrice. Fiind un tool comparație cu Sonar, Visual Studio nu perintegrat cu Visual Studio, putem să navi- mite efectuarea de share la aceste metrice găm în fiecare proiect și să vedem valoarea prin intermediul unui portal. În schimb, ne fiecărei metrice de la nivel de proiect, până permite să le exportăm într-un Excel penla nivel de namespace, de clasă și metodă. tru a le putea trimite la echipă. Tool-urile din Visual Studio sunt un bun început penExistă cinci metrice analizabile folosind tru orice echipă sau dezvoltator care vrea să Code Metrics: se informeze asupra calității codului scris • Lines Of Code ne precizează numă- de el sau de echipă. rul de linii de cod pe care îl avem la nivel de metodă, clasă, namespace, proiect.

Este bine de știut că această metrică când este la nivel de proiect ne indică numărul total de linii de cod pe care proiectul îl are.

• Class Coupling ne indică câte clase/ o clasă folosește – cu cât valoarea este mai mică, cu atât este mai bine.

• Depth Of Inheritance ne indică Radu Vunvulea

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

www.todaysoftmag.ro | nr. 20/Februarie, 2014

35

programare

Cum să (nu) măsurăm latenţa

L

atenţa este definită ca “intervalul de timp între stimul şi răspuns” şi este o valoare care ne interesează în multe sisteme de calcul (financiare, jocuri, site-uri web, etc.). În calitate de ingineri ne interesează crearea unui model matematic din care să rezulte valorile minime/maxime/tipice care pot să apară în sistemul nostru (fie el un site web sau un sistem de tranzacţionare automată pe burse).

Cum putem construi un astfel de model? Pentru sisteme sim- pot fi accesate aici3 pentru verificarea calculelor): ple (embedded) putem să calculăm direct ciclurile de procesor necesare pentru executarea programului. Dar pentru programe Imediat putem observa că valorile se pot clasifica în trei tipice există prea mulţi factori ca să putem aplica metoda directă categorii: (sistemul de operare, alte procese care rulează concomitent, JIT-ul, • 30% - valori mici (poate datele se aflau în cache deja); GC-ul, etc.). Alternativa pe care o avem este să executăm teste • 60% - valori medii (datele nu se aflau în cache şi s-a executat empirice şi să construim modelul pe baza rezultatelor obţinute. codul tipic); În cazul acesta trebuie să ţinem cont de câteva reguli ca să • 10% - valori foarte mari (am întâmpinat cazuri limită - corobţinem un rezultat corect: ner case);

Folosirea percentilelor

Să presupunem că testăm un site web care rulează în Tomcat.

Folosind JMeter1 rulăm un test de încărcare (load test) şi obţinem valoarea medie a lanteţei şi dispersia (standard deviation).

Având aceste valori concluzionăm că 99.73% dintre utilizatori vor observa o lanteţă care se încadrează în intervalul medie +-3*dispersie2. Suntem încrezători în rezultat pentru că: • am folosit URL-uri realistice în teste (nu am accesat un singur URL de un milion de ori); • am testat pe un sistem identic cu cel de producţie; • am luat în calcul timpul de încălzire (warmup) de care are nevoie JIT-ul; Şi totuşi rezultatul ar fi greşit (ceea ce poate să aibă consecinţe monetare grave dacă valorile respective se includ în contracte).

De unde provine problema? Să considerăm un exemplu concret: presupunem (pentru simplitate) că am executat 100 de teste şi valorile de latenţă măsurate au fost următoarele (valorile numerice

O astfel de distribuţie este tipică pentru sisteme medii spre mari din viaţa reală care sunt compuse din multe părţi (gen N-tier architecture) şi se numeşte distribuţie multimodală. Vedem imediat de ce este important acest lucru.

Folosind LibreOffice Calc (sau Excel, după gust) putem calcula rapid că media acestor valori este 40 şi conform regulii trei sigma4, 99.73% din utilizatori ar trebui să observe latenţe mai mici de 137.

Dacă studiem diagrama observăm că media se află spre partea stângă (nu în centru cum ne-am aştepta) şi percentila 99 este 148, nu 137 cum am calculat. Poate că diferenţa nu pare mare, dar dacă am scris un contract pe baza acestor valori, poate să însemne diferenţa între profit şi pierdere.

Unde am greşit? Să citim încă o dată atent regula trei sigma: “o variabilă normal repartizată ia valori semnificative numai în intervalul (μ-3σ, μ+3σ)”.

Problema noastră este că nu avem o distribuţie normală (gaussiană) ci o distribuţie multimodală cum am văzut mai devreme. O metodă pentru evitarea acestor probleme este folosirea modelelor matematice care nu depind de natura distribuţiei.

Evitarea omisiunii coordonate

Omisiunea coordonată (coordinated omission) este o expresie inventată de Gil Tene5 de la Azul Systems (un JVM alternativ care nu necesită oprirea programelor în timpul GC-ului). Omisiunea coordonată apare dacă programul de test arată în felul următor: start: t = time() do_request() record_time(time() - t) wait_until_next_second() jump start

1 http://jmeter.apache.org/ 2 http://en.wikipedia.org/wiki/68–95–99.7_rule

36

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

3 https://gist.github.com/cdman/7846275 4 http://ro.wikipedia.org/wiki/Distribu%C8%9Bia_Gauss#Regula_celor_3.CF.83 5 http://www.linkedin.com/in/giltene

TODAY SOFTWARE MAGAZINE Cu acest program de test încercăm să trimitem o cerere la fiecare secundă şi să măsurăm latenţa (aceeaşi problemă apare cu orice interval fix de trimitere - de exemplu 100ms - folosim o secundă aici pentru simplitate). Multe programe de test au o astfel de implementare.

Să presupunem că rulăm testul şi (învăţând din greşelile anterioare) raportăm că 85% din cereri vor fi satisfăcute sub 0.5 secunde dacă există o cerere pe secundă. Şi modelul nostru tot greşit ar fi. Să analizăm graficul de mai jos, pentru a stabili cauza:

aşteptat după al doilea cât timp acesta era blocat) ca să ascundă cererile potenţiale care puteau să apară în timp ce serverul era blocat. Așadar, după cum se poate vedea din exemplu, acest lucru duce la subestimarea latenţei.

Concluzie

Din problemele discutate anterior putem să distilăm câteva recomandări care să ne ajute în crearea modelelor robuste: 1. Să ne asigurăm că nu ne limitează utilitarul de testare - să-l rulăm contra unui URL care nu face nimic de exemplu şi să verificăm că putem să generăm numărul de accesări pe secundă dorită; 2. Să considerăm particularităţile sistemului - să folosim hardware identic cu cel de producţie, să lăsăm să se “încălzească” (warm up) dacă e vorba de un sistem JIT-ed (JVM, .NET, LuaJIT, etc.); 3. Să folosim percentile6. Când discutăm rezultatele să folosim fraze de genul “50% din vizitatori vor observa o latenţă sub…” sau ”99.99% din vizitatori vor observa o latenţă sub…” sau chiar ”latenţa maximă este…”

4. Să nu calculăm media. Să nu folosim dispersia (standard deviation). Dacă vedem astfel de valori, să presupunem că cei care au generat raportul nu ştiu despre ce vorbesc sau vor să ne inducă în eroare în mod intenţionat; 5. Să ne asigurăm că fiecare cerere a durat mai puţin decât intervalul de probare (sampling) sau să folosim o unealtă de testare care nu suferă de această problemă sau să folosim o librărie precum HdrHistogram de la Gil Tene care poate să corecteze ulterior rezultatele.

6 http://en.wikipedia.org/wiki/Percentile

Pe prima linie avem cererile în timpul testului. Între secunda 3 şi 6 sistemul este blocat (de exemplu din cauza unei pauze de GC).

Dacă calculăm percentila 85 din cererile de test vom obţine 0.5. În schimb dacă avem 10 clienţi independenţi (situaţia pe care încercăm să o simulăm cu testul) valoarea 85% a latenţei va fi 1.5 secunde (de trei or mai mare decât ne-a estimat modelul!).

De unde apare discrepanţa? Problema este că programul de testare şi sistemul testat au colaborat (prin faptul că primul a

Attila-Mihaly Balazs dify.ltd@gmail.com

Code Wrangler @ Udacity Trainer @ Tora Trading

www.todaysoftmag.ro | nr. 20/Februarie, 2014

37

management

Thinking in Kanban

C

arte vizuală - aceasta ar fi traducerea exactă a cuvântului japonez “Kan Ban”, termen folosit cu frecvenţă în lumea IT-ului.

Sensul cunoscut actualmente se referă la metodologia de dezvoltare a sistemelor software, renumită pentru simplitatea şi pentru eficienţa ei.

Primul sistem Kanban a fost creat acum mai bine de 60 de ani în cadrul companiei Toyota în încercarea de a excela pe piaţa de autoturisme. Pentru că la momentul respectiv, Toyota nu putea concura pe baza tehnologiei, a pieţei de dezvoltare sau a volumului de maşini produse, a ales să concureze prin redefinirea modului de organizare a procesului de producţie.

Toyota Production System a pus bazele sistemului Kanban pentru Producţie, având următoarele direcţii de bază: • Reducerea costurilor prin eliminarea deşeurilor.

• Crearea unui cadru de muncă care răspunde rapid la schimbări.

• Facilitarea metodelor pentru realizarea şi asigurarea unui control de calitate.

• Crearea unui mod de lucru ce se bazează pe încredere şi susţinere reciprocă, unde angajaţii pot să îşi atingă potenţialul maxim.

Chiar dacă în anii ce au trecut de atunci, IT-ul a redefinit sensul Kanbanului, i-a atribuit valori noi, l-a completat cu metrici şi reguli, impresia generală este că se respectă principiile de bază ale companiei Toyota.

Principiile Kanban

Kanban se bazează pe două principii fundamentale: 1. Vizualizarea fluxului de muncă, 2. Limitarea activităţilor în progres.

pentru a fi înţelese şi procesate mai uşor şi mai rapid. Pe de-o parte, toţi membrii echipei pot vizualiza în orice moment starea în care se află proiectul, pe de altă parte, vizualizarea acestei stări globale ajută în descoperirea rapidă a problemelor și blocajelor în proiect.

Structura de bază a unui Kanban board se rezumă la trei stări (coloane): To-Do, Ongoing (sau In Progress), Done. Se pot însă defini stări specifice nevoilor de proiect, un exemplu clasic de Kanban board pentru software development se poate urmări în figura ataşată.

Pentru a putea estima cât mai corect dimensiunile de timp şi volumul de muncă în Kanban există metrici ce ajută la definirea acestora. Asemenea regulilor de bază, calcularea metricilor este simplă.

Lead Time: este timpul măsurat de la introducerea unui task în sistem până la momentul în care acesta este livrat.

Este important de reţinut că Lead-time măsoară timpul şi nu efortul depus pentru executarea task-ului.

Lead-time este metrica relevantă clientului şi va evalua perfomanţa de lucru a echipei în funcţie de aceasta.

Cycle Time: este timpul măsurat de la momentul în care s-a început munca la un task până în momentul în care acesta este livrat. În comparaţie cu Lead-time, aceasta este o măsură mecanică a capacității procesului şi reflectă eficienţa de muncă a Limita WIP (Work-In-Progress) echipei. asigură muncă focusată şi astfel mai eficientă. Coloanele de tip “Ongoing” din Kanban board au atribuite o astfel de limită, iar numărul de task-uri existente la un moment dat nu trebuie să depăşească limita specificată. Prin reducerea multitasking-ului se elimină timpul necesar pentru alternare. Prin executarea task-uriPentru a mări performanţa echipei, lor în mod secvenţial, rezultatele apar mai scopul este diminuarea metricilor de Leadrepede şi timpul total al efectuării acestora time şi Cycle-time. este mai scurt.

Legea lui Little:

Vizualizarea se obţine cu ajutorul unui Kanban board, care mapează task-urile în funcţie de starea în care se află acestea.

Stările board-ului se definesc în funcţie de complexitatea proiectului şi de numărul etapelor existente în proces. Task-urile sunt scrise pe bileţele (sau sticky-notes) colorate

38

Metrici în Kanban

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

Pentru a îmbunătăţi Cycle-time sunt două opţiuni posibile: • reducerea numărului de task-uri în proces, • îmbunătăţirea ratei de completare a task-urilor.

Prin reducerea metricilor de Lead şi

TODAY SOFTWARE MAGAZINE Cycle-time, echipa de dezvoltare îi poate oferi certitudinea clientului că produsul va fi livrat la timp.

Flexibilitatea în Kanban

Un Kanban board este complet configurabil în funcţie de scopul pe care îl deserveşte, calitate ce face ca metodologia în sine să poată fi utilizată într-o varietate de domenii. Având rădăcinile în producţie şi fabricaţie, acesta are un mod natural de a se mula pe orice proces de business non-IT. Kanban board-ul poate fi configurat în funcţie de domeniu şi în funcţie de etapele procesului prin care se ajunge la produsul/ serviciul final. În afară de IT, iată câteva domenii în care sistemul Kanban şi utilizarea unui Kanban board se poate integra cu uşurinţă: • Marketing şi PR, • Resurse Umane, • Logistică şi Supply Chain, • Financiar, • Legal/ Juridic.

Beneficiile pe termen scurt şi lung sunt similare celor menţionate în domeniul IT: vizibilitate mai bună a procesului de lucru, productivitate crescută şi colaborare mai bună în echipă.

Tipuri de Kanban Board fizic. Board online

de atât, acestea au şi o serie de posibiliăţi şi de avantaje adiţionale: configuraţie uşoară, arhivarea task-urilor, editare, clasificare, temporizare, accesare remote, colaborare între echipe împărţite în mai multe locaţii, etc. .

Time-driven & Event-driven Kanban Menţionam în rândurile de mai sus flexibilitatea şi modul în care creăm structura board-ului Kanban în funcţie de nevoile specifice a proiectului propus. De-a lungul anilor, câteva tipuri generale de structură s-au dovedit a fi elementare în folosirea metodologiei.

Time-driven Kanban Board: folosit în planificarea temporală a activităţilor.

Event-driven Kanban Board: util atunci când e nevoie şi de o intervenţie externă (ex: aprobare) pentru a continua cu executarea task-urilor în proces.

metodei Kanban cu alte metode şi tehnici.

Scrumban este combinaţia între SCRUM şi Kanban. Pe scurt, înseamnă aplicarea unor principii şi reguli ale celor două metodologii în funcţie de preferinţele echipei de lucru.

PomodoroBan combină tehnica Pomodoro şi Kanban. Conform tehnicii Pomodoro eficienţa se poate dobândi prin alternarea urmatoarelor două cicluri: 25 de minute de muncă concentrată şi neîntreruptă, 5 minute pauză. PomodoroBan păstrează şi aplică principiile Kanbanului adăugându-i un plus de eficienţă.

Concluzii

Fie că aplicăm Kanban în IT, în domenii conexe sau chiar în viaţa personală se pare că “less is more” este adevărat de fiecare dată. Kanban se remarcă prin uşurinţa cu care se aplică oricărui proces, simplitatea principiilor și regulilor de bază şi efectele Personal Kanban rapide de îmbunătăţire a calităţii şi proceÎn anul 2011 Jim Benson a introdus sului de muncă. ideea conform căreia Kanban este perfect pentru organizarea timpului şi a task-urilor Referinţe personale. Conceptul devine din ce în ce http://www.kanbanblog.com mai popular şi utilizatorii Personal Kanban http://kanbantool.com spun că metoda funcţionează.

Jim Benson: Personal Kanban (2011) În cele mai multe cazuri se foloseşte un board cu proces simplificat, cu multe efecte vizuale. Într-un final, scopul Personal Kanban este să îmbunătăţească Püsök Orsolya productivitatea personală şi să faciliteze pusok.orsolya@evoline.ro atingerea scopurilor pe termen lung.

La început un Kanban board avea o definiţie simplă, o tablă sau un spaţiu improvizat pe perete pe care se lipeau bileţele sau notiţe marcate cu task-uri. Board-ul se afla în încăperea unde membrii echipei lucrau şi reprezenta punctul de focus al echipei.

Conceptul de a avea un board fizic este şi acum foarte popular şi considerat un prilej excelent pentru a îmbunătăţi colaborarea şi comunicarea între membrii unei echipe.

Cu toate acestea, interesul crescut în folosirea metodologiei Kanban a inspirat o serie de programe şi tool-uri online ce oferă Scrumban. PomodoroBan funcţiile similare unui board fizic. Mai mult Numele sugestive indică combinarea

Functional Architect @ Evoline

www.todaysoftmag.ro | nr. 20/Februarie, 2014

39

startups

New business development analysis

S

ă privești din exterior cum crește o afacere este o adevarată plăcere. Puțini însă se gândesc la detalii și puțini sunt cei care analizează cu atenție pașii mărunți care au dus spre succes.

Astăzi, știm clar că, înainte de a demara un proiect nou indiferent de industrie, este nevoie de un plan de acțiune. În majoritatea domeniilor planul de afaceri este cel mai cunoscut și mai des întâlnit. Recent însă în industria software, a apărut un nou concept de analiza POC. Conform Wikipedia, un POC (proof of concept - concept de business) se definește ca fiind realizarea unei metode sau idei în scopul de a-i demonstra fezabilitatea. În unele cazuri acest POC ia forma unui prototip care oferă multe informații despre viitorul proiect, identifică nevoile, trasează caracteristicile principale și prezintă riscurile.

Conceputul POC s-a impus rapid în inginerie și industria software și este agreat de executant și de client pentru că permite evaluarea corectă și poate estima cât mai bine ce și cum trebuie făcut. Într-un POC se ia în considerare strategia de caracteristici, de preț, de piață, branding și modelul de business.

După cum relatează și Marius Ghenea într-un interviu dat cu ocazia Business Days, business-urile în care investește trebuie să fie validate în piață : “Este esențial să existe un proof-of-concept, ceea ce înseamnă o anumită validare, ce se poate face, în faza inițială, înainte de comercializare, pe focus-grupuri, beta-testeri, proiecte pilot, teste comerciale limitate sau alte tipuri de testare în piață. Dacă piața nu validează un

40

concept de business, nu avem premise de succes, chiar dacă ideea de business pare spectaculoasă și unică.” În cazul unui proiect software demonstrarea funcționalității înainte de a începe dezvoltarea propriu-zisă, este mai mult decât benefică. Drept urmare nu este de mirare că tot mai mulți investitori și business angels agreează ideea unui POC în locul unui plan de business clasic.

Wayne Sutton, blogger la Wall Street Journal susține acest lucru în articolul ‘Don’t Need No Stinking’ Business Plan’. Argumentul ar fi că pornirea unui nou business este mult mai ușoară decât acum 15 ani și compară business plan-ul cu metoda waterfall de dezvoltare care e ‘outdated’.

Totul trebuie să fie rapid și să înveți tot timpul odată cu clienții pe care-i servești și îi implici în proces din prima zi. Orice antreprenor trebuie să fie conectat și să își

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

folosească experiențele din viața reală cât mai mult posibil. Autorul articolului se referă exclusiv la startup-urile în industria IT și lasă deoparte businessurile clasice.

Deoarece mediul antreprenorial din România e încă în curs de dezvoltare și pașii se fac mai timid de către tinerii creativi care își caută finanțare, business plan-ul mai rămâne o vreme un punct important de referință.

Menționăm câteva documente importante pentru un tech start-up: 1. Use Cases – cine sunt clienții și cum vor folosi produsul/serviciul.

2. Planul de vânzări – ce, cât, unde, cum și cine va vinde produsul/serviciul.

3. Resursele umane – asigurarea continuității businessului chiar dacă oamenii vor pleca din firmă.

4. Cash flow-ul – de câți bani e nevoie și când.

TODAY SOFTWARE MAGAZINE

Am observat de-a lungul timpului că tinerilor antreprenori le e greu să facă de la început distincția clară între core-business (activitatea principală) și celelalte activități suplimentare. Într-un startup e greu de stabilit funcțiile principale pe care trebuie să le îndeplinească un sistem și funcțiile suplimentare. Cu toate acestea, e vitală existența unei liste cu toate posibilele funcții ale viitorului sistem, după care se prioritizează și se împart în funcții principale și secundare.

Voi detalia în continuare partea de use case-uri ca fiind relevantă pentru tech startup-uri și care ajută mult antreprenorul să nu se abată de la planul stabilit inițial.

Use case-urile sunt modalitatea de a folosi un sistem pentru a atinge cu anumit țel pentru un anumit utilizator. Spre exemplu, un utilizator autentificat pe Amazon dorește să poată plăti cu cardul de credit un produs de pe site. Acesta se poate defini ca un obiectiv de atins.

modalitatea în care poate fi folosit un sistem și arată valoarea pe care acesta o aduce utilizatorilor.

Cartea Use-Case 2.0 The Guide to Succeeding with Use Cases scrisă de Ivar Jacobson, Ian Spence, Kurt Bittner prezintă dezvoltarea bazată pe use case-uri într-o variantă foarte accesibilă și practică.

Use case-urile pot fi folosite în dezvoltarea businessurilor noi, caz în care se asociază toată afacerea cu un sistem.

Sistemul este cel care implementează cerințele și este subiectul unui model de use case. Calitatea si nivelul de finalizare al sistemului este verificată de un set de teste.

Testele au rolul de a verifica dacă implementarea pe felii a use case-urilor a fost un succes sau nu.

Mergâng mai departe cu folosirea use case-urilor, cred că toată lumea e deja familiarizată cu user stor-urile. Aceste ‘povești’ fac legătura între stakeholder-i, use caseuri și părți din use case-uri. Acest mod de a transmite cerințele pentru noul sistem Toate obiectivele setate împreună este foarte răspândit pentru că ajută mult compun un set de use case-uri care arată la identificarea părților de bază ce trebuie implementate pentru a putea crea un sistem functional de bază. Când se descrie o idee de afacere, modul cel mai bun de a transmite celorlalți începe natural cu ‘Vreau să fac o aplicație care să permită utilizatorilor de smartphone-uri să facă comandă la taxi prin intermediul unei aplicații care să poată

fi instalată pe Android și iOS’. Închei scurta incursiune în analiza de dezvoltare a noilor businessuri cu mențiunea că fără o idee clară și un plan pus la punct de la început, șansele de reușită ale unui proiect sunt extrem de reduse. Fie că se pornește de la un business plan clasic, se merge pe ideea unui proof of concept sau se ajunge chiar la o listă prioritizată de use case-uri pentru noul sistem, planificarea fiecăriu pas înainte trebuie să se facă cu grijă și responsabilitate astfel încât să se poată evita toate riscurile cunoscute.

Bibliografie: 1. http://blogs.wsj.com/accelerators/2012/11/29/ embrace-the-executive-summary/ 2. Use-Case 2.0 The Guide to Succeeding with Use Cases, Ivar Jacobson, Ian Spence, Kurt Bittner 3.http://www.avocatnet.ro/content/articles/ id_30930/In/ce/investesc/antreprenorii/care/au/ adoptat/o/cariera/de/business/angel/in/Romania. html#ixzz2pwAZCe5

Ioana Armean

ioana@ogradamea.ro Project Manager @ Ogradamea

www.todaysoftmag.ro | nr. 20/Februarie, 2014

41

management

Pitching-ul în business: cum să vinzi în patru paşi simpli

Ţ

i s-a întâmplat vreodată să fii la un eveniment interesant cu oameni şi mai interesanţi pe care ai fi vrut din tot sufletul să îi cunoşti mai bine, dar nu ai ştiut cum să-i abordezi? Sau ai fi vrut să “îţi faci intrarea” în relaţia cu unii dintre ei, dar parcă nu aveai cuvintele chiar în buzunarul tău drept?

De cele mai multe ori, ai maxim 60 de secunde să vorbeşti despre ce ştii tu să faci cel mai bine în profesia sau afacerea ta, în faţa viitorilor tăi parteneri sau colaboratori.

Un pitch sau un discurs scurt de business este o cuvântare de aproximativ 30 secunde - 3 minute, în genere, aparent spontană, prin care o persoană îşi poate promova competenţele, serviciile, ce le poate oferi, sau afacerea, precum şi valoarea adaugată, pe care o poate oferi prin intermediul acestora.

Deşi conceptul a început să fie promovat destul de recent ca atare în lumea business, mai explicit, în mediul startupurilor, cum se întamplă în Statele Unite, în Europa si chiar în Cluj în ultimii ani, el reflectă o realitate străveche. Din toate timpurile conducătorii de popoare migratoare au fost nevoiţi să îşi asume teritoriile cucerite, prin scurte cuvântări proclamatoare. În fond, chiar simplul gest de a vorbi exclusiv limba proprie, maternă, ignorând limba locului, a constituit un început de discurs de promovare, în înţelesul contemporan al cuvântului. Solii de pace sau propovăduitorii religiilor au fost şi ei premergătorii pitching-ului de astăzi, prin mesajul de pace sau divin pe care aveau tot interesul să îl transmită.

De ce să pitch-uim? Abilitatea de a vinde este înnăscută, se spune că cei mai buni vânzători sunt copiii. Astfel, ne-ar fi foarte greu să ne debarasăm de pitching, un instrument, pe care îl avem aproape instinctual, de a obţine ceea ce dorim.

Dintr-un alt punct de vedere, avem nevoia de asociere cu relevanţa ei de netăgăduit în piramida nevoilor, iar pentru asociere, avem nevoie de persuasiune ca de o monedă de schimb. Şi mai ales, dincolo de toate celelalte sensuri de profunzime ale unui scurt discurs business, el are rolul

42

unui aperitiv. Un aperitiv pentru comunicare: “Un pitch nu este folosit doar pentru a-l impresiona pe celălalt să îţi adopte o idee, ci pentru a oferi ceva atât de atractiv, încât să determine începerea unei conversaţii.” (Daniel H. Pink, To Sell is Human).

Privind în jur, în viaţa ta, în cercurile sociale pe care le frecventezi, sau chiar la tine, în experienţele tale de până acum, fie ele personale sau profesionale, vei putea observa negreşit, că în nenumărate contexte, te-ai folosit de câteva fraze de introducere, explicative, descriptive şi motivante, întrucâtva, pentru o acţiune sau alta. Cu alte cuvinte, pitching facem în aproape orice domeniu şi în orice moment al vieţii noastre, fie că am făcut aceasta ca să primim bani de excursie în copilărie, fie că ne-am dorit o mărire de salariu, fie un asociat valoros, un angel investor sau o investiţie pentru afacerea noastră la început de drum.

Dacă este de la sine înţetels de ce să facem acest lucru, pasul următor este să construim şi să pregătim structura pitchului nostru. În primul rând, un pitch eficient trebuie să conţină nu mai mult de patru secţiuni, respectiv, aproximativ patru fraze mari.

Pentru început, este necesar să spui cine eşti, simplu, cu nume şi prenume şi să redai un atribut-cheie pentru rolul, profesia sau afacerea în care eşti implicat. Numele e unic şi dă identitate şi autenticitate întregului discurs, iar atributul este esenţial pentru a-ţi conferi legitimitate, în demersul pe care îl prezinţi sau îl susţii în pitch. Prin calitatea pe care alegi să o prezinţi ca atribut-cheie, fie CEO al companiei tale, specialist în programare de șapte ani, fie pasionat de cărți medievale, oricare din acestea în concordanţă cu aria ta de activitate şi proiectul promovat aici de tine, tu îi determini pe cei

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

din audienţa ta să te asculte cu atenţie, să creadă în tine şi în ceea ce urmează să le spui.

Apoi, în cea de-a doua secţiune principală a discursului tău, şi chiar, a doua frază, de multe ori, vei prezenta ce faci tu şi cum aduci valoare adăugată. Exemplul care mă inspiră mult, dintre pitch-urile pe care le-am analizat până acum, este cel al lui Phil Libin: “[Sunt Phil Libin, CEO-ul Evernote.]

Evernote este memoria ta externă.” Ceea ce face cu excelenţă Phil aici, este că reuşeşte să redea în cuvinte valoarea adăugată a aplicaţiei Evernote, care funcţionează în sistem “cloud”, printr-o metaforă de mare efect. Esenţa publicitară a pitch-ului se regăseşte aici, în cum exprimi valoarea adăugată şi în partea finală, în cum faci îndemnul la acţiune. Aşa că şi efortul de pregătire, creator şi, de ce nu, estetic, trebuie să se depună cu mai mare forţă în aceste două secţiuni critice.

1. Cine sunt și un atribut-cheie (funcție/experiență/pasiuni/interese).

2. Ce fac și cum adaug valoare prin produsul sau servicul meu.

3. Cum mă diferențiez de concurență?

4. Care sunt obiectivele mele pe termen scurt/mediu? De ce susţin

TODAY SOFTWARE MAGAZINE pitch-ul? Invit la acțiune.

Mai departe, în a treia secţiune a scurtului tău discurs, trebuie să redai modul în care te diferenţiezi de concurenţă. Sunt mari şanse ca ceea ce oferi tu pe piaţă, prin produsul sau serviciul tău, ori ca profesionist, prin competenţele, expertiza şi experienţa ta, să mai ofere şi altcineva.

Astfel, că trebuie să subliniezi subtil, pe scurt, de ce eşti diferit. De ce să te aleagă pe tine? De ce merită mai multă atenţie decât competiţia ta, ceea ce tu poţi face? În funcţie de durata pitch-ului tău, de dimensiunea audienţei şi de contextul în care susţii cuvântarea, această parte poate fi mai mult decât celelalte, scurtată, pentru a prezerva ritmul şi concizia comunicării. De multe ori, nu este necesar să menţionezi explicit numele organizaţiilor, startup-urilor sau experţilor cu care îţi împarţi piaţa, ci doar să sugerezi cum faci tu altfel ceea ce faci mai bine: nu doar că oferim o platformă de stocare de informaţii în “sistem cloud”, însă este chiar “memoria ta externă” sau „al doilea creier al tău”. În f ina l, re comand s ă numeşt i obiectivele pe care le ai pe termen scurt (1-2 idei), ceea ce, de fapt dă specificul şi motivul pentru care ai decis să interacţionezi cu publicul tău, în acel context de timp şi spaţiu. Spre exemplu, la competiţia de startup-uri la care participi, de regulă, pe tot parcursul evenimentului, se susţin discursuri de pre-selectare graduală. Cu această ocazie, se susţine pitch-ul cu ideea de afacere în prima lui formă, nerafinată, însă obiectivele pot fi: identificarea de noi membri în echipă, după abilităţi sau după arii de expertiză (marketing online, business development, copyrighting, programare etc.), influenţarea investitorilor prezenţi să susţină afacerea, promovarea echipei şi ideii pentru includerea într-un program de accelerare a afacerii şi multe altele. De fapt, prin concluzia pitch-ului tău, tu le arăţi celor care te ascultă cum te pot ajuta, ce îţi doreşti să obţii de la ei, cu ei şi care este etapa pe care o parcurgi, implicit, în dezvoltarea afacerii tale. Dintre regulile scrise şi nescrise ale persuasiunii în vorbitul în public, pe care îl puteţi

exersa într-un mediu prietenos şi temeinic într-un club Toastmasters, se numără folosirea de cuvinte-cheie, cum sunt verbele, pentru a inspira la acţiune: “Aceştia suntem noi, haideţi în echipa noastră!”, “Dacă eşti programator pe iOS şi vrei să devii cunoscut, alătură-te nouă!”, “Hai să facem lumea mai bună, creând o platformă pentru îmbunătăţirea relaţiilor tale, aşa că te invităm să susţii campania noastră de crowdfunding.”

Dacă te-am convins că oricine are nevoie de pitching, dacă te-ai acomodat cu motivul pentru care tu însuţi ai nevoie de asta, dacă ţi-ai dat seama că deja ai făcut asta de nenumărate ori până acum, dar nu l-ai numit chiar aşa, mai rămâne să stabileşti când te poţi aştepta şi pe viitor, la oportunităţi de pitching. Un asemenea discurs de business se cade să fie de o spontaneitate exersată, dezvoltată în timp.

Dacă îţi cauţi parteneri pentru ideea ta de afacere, o slujbă nouă şi te pregăteşti de interviuri, cu siguranţă merită să investeşti o oră din timpul tău ca să pui bazele unei formule potrivite, particularizate, de pitch pentru tine. Poţi scrie pe hârtie, te poţi înregistra audio sau video (şi nu e nevoie de echipament mai performant decât o cameră foto sau un smartphone, pentru început), ca să identifici cuvintele, tonul, conţinutul, care te recomandă şi te promovează cel mai bine. Apoi, nu-ți rămâne decât să cauţi oportunităţi de promovare, evenimente de networking, târguri de joburi, sau să fii spontan şi la petrecerile sau evenimentele de sărbătoare profesionale sau chiar personale, te bucuri de ambianţă şi răspunzi relaxat la o întrebare simplă: “Dar tu cu ce te ocupi?”.

Fiecare dintre noi poate să aibă nevoie de mai multe pitch-uri, în concordanţă cu fiecare proiect în care e implicat, cu fiecare rol profesional pe care îl are sau cu fiecare echipă ori organizaţie din care face parte. Astfel, discursul poate fi cu uşurinţă adaptat la audienţă, prin modificarea şi particularizarea perspectivei, limbajului şi conţinutului comunicării. La nivel foarte tehnic, dacă vorbeşti de afaceri total diferite, se vor modifica: atributul-cheie al tău din secţiunea întâi, numele activităţii tale

şi cum oferi voaloare adăugată, cum te diferenţiezi şi invitaţia la acţiune. Dacă, însă, modifici pitch-ul doar cronologic, pe măsură ce avansezi în stadiile de evoluţie a afacerii tale în creştere, atunci, cel mai adesea vei modifica doar concluzia, cu obiective şi invitaţia la acţiune. La „Startup Week-end”, îţi vei căuta colegi de echipă, iar la „Le Web”, poate îţi vei căuta deja investitori, după ce prototipul serviciului sau produsului tău sunt deja lansate.

Pentru mine, să îmi creez primul pitch a fost o reală provocare. În primă instanţă, una psihologică şi motivaţională, căci nu m-am simţit că aş fi chiar eu însămi, dacă ajung să repet, ca pentru olimpiadă, cine sunt şi ce vreau de la ceilalţi. Însă beneficiile unei asemenea resurse de autopromovare sunt mult mai mari decât costurile. Aşa că, participarea mea la ediţia Startup Weekend din 2013, m-a determinat să îmi fac conştiincioasă temele şi să învăţ să mă vând cu folos şi entuziasm. Setează-ţi ca obiectiv să răspunzi exemplar, timp de trei luni, de acum înainte, la banala întrebare “Tu cu ce te ocupi?” şi pitching-ul va deveni pentru tine un gest reflex. Aducător de venituri, prieteni, rezultate, parteneri sau, cel puţin, conversaţii pline de interes.

Bibliografie http://www.elevatorpitchexamples.com/ www.businessweek.com http://mindyourpitch.com/ www.forbes.com

Ana-Loredana Pascaru

ana.pascaru1@genpact.com Training Manager @ Genpact

www.todaysoftmag.ro | nr. 20/Februarie, 2014

43

diverse

Gogu și velierul - Tata, mai zi-mi o dată, ce faci tu la serviciu?

Frec menta, îi trecu prin cap lui Gogu, dar se abținu să spună cu voce tare. Îi era ciudă că nu reușise până acum să dea un răspuns pe înțelesul copilului, dar nici nu avea idee ce explicație să îi dea. Frate, n-o fi ușor să gestionezi un proiect, dar uite că și mai greu e să explici cum faci asta. Mormăi: - Conduc proiecte, asta fac. Da’ ce-ți veni iar?

- Ne-a zis Doamna să ne invităm părinții să ne povestească cu ce se ocupă ei la serviciu, să ne dea exemplu. Și a mai zis să le spunem să vină în uniformă. Dacă au... adaugă repede văzând grimasa lui Gogu. Că tatăl lui Mircea e pompier și poate veni în uniforma și vine și mama Mariei care e doctor și are halat și tatal lui Dănuț e polițist...

- Aha... - zise Gogu - și eu cum ai vrea să vin îmbrăcat?

Copilul se uită la el cu ochii mari, se vedea că rotițele i se învârt, se gândea intens dacă îl văzuse vreodată pe tatăl lui în vreun fel de îmbrăcăminte specială. Probabil că nu găsise nimic în memorie, că nu mai zise nimic, rămăsese doar cu ochii agățați de tatăl lui, în așteptarea unui verdict. Și uite-așa se complică lucrurile, gândi Gogu. În loc să explic unuia singur, trebuie să explic unei clase întregi. Și nici n-am uniformă... Recapitulă lista copilului: pompier, medic, polițist. Ei, cum să concurezi cu ei? E clar că au ce povesti, întâmplări extraordinare, situații care mai de care mai spectaculoase. Plus uniforma...

Vocea copilului sparse reveria: - Și cum vă cheamă pe voi?

Superman. Sau Wonderwoman, după caz. Ei, nu, nu spuse asta cu voce tare. În loc de asta întrebă: - Da’ când e întâlnirea asta a voastră cu părinții?

- Oricând săptămâna viitoare, numai să anunțăm din timp.

Așa a spus Doamna.

Așa a spus Doamna, îl maimuțări Gogu pe copil în gând. S-a dus și posibilitatea de a scăpa. Ce scuză să găsești ca să țină o săptămână întreagă?! Mda, e serioasă treaba.

- Uite, lasă-mă să mă gândesc și îți spun când pot să vin, să o anunți pe Doamna. Și mă gândesc exact și ce să vă povestesc, să nu te fac de râs. E bine așa?

Copilului îi sticliră ochii, zâmbi satisfacut, își sărută tatăl și vizibil ușurat, aruncă de după umăr în timp ce ieșea din cameră: - Da, tata, e foarte bine. Mă bazez pe tine.

Pompier, medic, polițist. Pentru prima oară Gogu se gândea că are o meserie anostă. Ei, de unde? își reveni el. Că doar îmi place ceea ce fac! Doar că n-am uniformă, adăugă cu o urmă de regret. Dar nu haina face pe om. Și-apoi zău dacă nu sunt un fel de superman câte-odată... Se surprinse zâmbind la gândul unor colanți strâmți și a unei pelerine roșii aruncate pe umăr, dar alungă imaginea hilară și se concentră pe speech. *** Gogu transpirase iar, mâinile îi erau reci. El care ținea – fără nici o emoție - prezentări pentru management și pentru client, era timorat la gândul că va vorbi unor copii, colegi ai fiului său.

44

nr. 20/Februarie, 2014 | www.todaysoftmag.ro

Își dădu seama că voia să-i impresioneze mai mult decât pe orice potențial client.

Toți ochii erau ațintiți pe Gogu. Îl căută din ochi pe fiul său, îl găsi și îi zâmbi. Se concentră asupra lui și începu: - Fiul meu mi-a spus că până acum ați auzit despre ce face un mecanic auto, un pompier, un medic, un polițist. Așa e?

- Și farmacistă! adăugă o fetiță din spate.

Alta cu uniformă, nu se putu abține Gogu să gândească, un inginer n-ați găsit și voi... Dar știa exact despre ce vrea să le vorbească copiilor, așa că nu mai stătu pe gânduri ci continuă, scoțând din geantă o pelerină groasă de ploaie, cauciucată, uzată și cu iz de apă sărată: - Eu sunt manager de proiect. Își puse tacticos pelerina, făcu o pauză teatrală, râse în sinea lui, și continuă: și am pelerina de ploaie a unui căpitan de velier. Pentru că ăsta este rolul nostru, de căpitan, doar că pe uscat. Coordonăm echipa pentru a duce velierul cu succes la destinație. Din momentul în care luăm nava în primire, noi suntem cei care decidem dacă folosim motorul sau velele, dacă și când e momentul să ridicăm ancora, care este viteza optimă cu care navigăm. Ne coordonăm echipa să țină un drum compas, să programeze un marș , să folosească instrumentele de navigație, să ridice și să coboare pânzele. Toți cei din echipă își știu rolul, dar căpitanul este cel care îi ajută să se sincronizeze, el interpretează datele meteo și mesajele de la țărm, el urmărește poziționarea pe GPS, decide dacă ancorează peste noapte sau își continuă drumul. Pe timp frumos sau pe furtună, rolul meu este să păstrez echipa în siguranță și să mă asigur că munca ei nu este afectată de factorii externi.

O fetiță blondă, cu codițe, din primul rând ridică brusc două degete în aer, dar nu mai așteptă încuviințarea lui Gogu: - Nene, dar cine e în echipa ta?

- Oricine poate fi în echipa mea: mecanici auto, pompieri, medici, polițisti... chiar și farmaciste.

- Și pelerina de ploaie la ce îți folosește?!

Simona Bonghez, Ph.D.

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

sponsori

powered by