Today Software Magazine N20/2014

TSM T O D A YS O F T WA R E

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

M AG A Z I N E

Interviu cu Philipp Kandal

Metrici în Visual Studio 2013

Clusterul Cluj IT și Antreprenoriatul

New business development analysis

Multithreading în standardul C++11 (II)

Startups: Evolso

Interviu cu Radu Georgescu

Interviu cu Alexandru Tulai

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

Craftsmanship si Lean Startup


6IT Innovation Days 2014

Ovidiu Mățan

7Interviu cu Philipp Kandal

Ovidiu Mățan

9Evolso

Alin Stănescu

11O privire de ansamblu

asupra testării performanței aplicațiilor Desktop

Sorin Lungoci

15Software Craftsmanship și

Lean StartupAlexandru Bolboaca și Adrian Bolboacă

17Vagrant pentru începători

Carmen Frățilă

22Startup marketing: provocări și repere

Sorina Mone

24Clusterul Cluj IT și

Antreprenoriatul Daniel Homorodean

26Interviu cu Radu Georgescu

Ovidiu Mățan

28Restricted Boltzmann MachinesRoland Szabo

30Maven, The Definitive Guide Silviu Dumitrescu

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

34Metrici în Visual Studio 2013 Radu Vunvulea

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

39Thinking in KanbanPüsök Orsolya

40New business development analysisIoana Matei

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

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

http://www.kinectforwindows.org



4 nr. 20/Februarie | www.todaysoftmag.ro

Cuvântul innovation plasat pe coperta revistei anunță tema acestui număr, startups & innovation. Dar cuvântul a fost ales și pentru a marca simbolic intra-rea î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ă cre-eze 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 tehno-logiilor 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 eveni-ment 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 antre-prenor: 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 gestio-narea 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 tine-rilor 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 mar-chează 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ăţanFondator al Today Software Magazine

Ovidiu Măţan, [email protected]

Editor-in-chief Today Software Magazine

editorial

mailto:[email protected]

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

Redacţia Today Software Magazine

Fondator / Editor în chief: Ovidiu Mățan [email protected]

Editor (startups și interviuri): Marius Mornea [email protected]

Graphic designer: Dan Hădărău [email protected]

Copyright/Corector: Emilia Toma [email protected]

Traducător: Roxana [email protected]

Reviewer: Tavi Bolog [email protected]

Reviewer: Adrian Lupei [email protected]

Contabil : Delia [email protected]

Produs de Today Software Solutions SRL

str. Plopilor, nr. 75/77Cluj-Napoca, Cluj, [email protected]

www.todaysoftmag.rowww.facebook.com/todaysoftmag

twitter.com/todaysoftmag

ISSN 2284 – 6352

Copyright Today Software Magazine

Reproducerea parțială sau totală a articolelordin revista Today Software Magazine

fără acordul redacției este strict interzisă.

www.todaysoftmag.rowww.todaysoftmag.com

Lista autorilor

Alexandru [email protected]

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

Adrian [email protected]

Programmer. Organizational and Technical Trainer and Coach@Mozaic Works

Radu [email protected]

Senior Software Engineer@iQuest

Attila-Mihaly [email protected]

Code Wrangler @ UdacityTrainer @ Tora Trading

Sorina [email protected]

Marketing manager@ Fortech

Daniel [email protected]

Membru în Consiliul Director@ Cluj IT Cluster

Roland [email protected]

Junior Python Developer@ 3 Pillar Global

Silviu [email protected]

Consultant Java@ msg systems Romania

Dumitrița [email protected]

Software engineer@ Arobs

Püsök [email protected]

Functional Architect@ Evoline

Ioana [email protected]

Project Manager@ Ogradamea

Ana-Loredana [email protected]

Training Manager@ Genpact

Simona Bonghez, [email protected]

Speaker, trainer şi consultant în managementul proiectelor,

Owner al Colors in Projects



Alin Stă[email protected]

Project manager@ Evolso

Sorin [email protected]

Tester@ ISDC

Carmen Frățilă[email protected]

Software engineer@ 3Pillar Global






www.todaysoftmag.ro

twitter.com/todaysoftmag

www.todaysoftmag.ro

www.todaysoftmag.com



TODAY SOFTWARE MAGAZINE

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

interviu

Ovidiu Mățan: Cluj IT Cluster orga-nizează î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 evenimen-tului 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 pen-tru 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îm-plă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 infra-structură 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.

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 manangemen-tul 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 antrepreno-rială și își propune să prezinte auditoriului principalele mecanisme și etape în conso-lidarea și valorificarea unei idei inovative, prin trimitere directă la ingredientele start-up-urilor, spin-off-urilor precum și forme de atragere a investițiilor și altor surse de finanțare disponibile. Ultima sesiune tema-tică, 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, evenimen-tul va reuni peste 400 de persoane, din țară și străinătate, printre care se numără

reprezentanți ai Comisiei Europene, ai Guvernului României și ai autorităților publice locale, oameni de business, reprezentanți ai mediului academic, amba-sadori, 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 repre-zentative 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.clujinnovati-ondays.com

Î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.

IT Innovation Days 2014





TODAY SOFTWARE MAGAZINE interviu

Interviu cu Philipp Kandal

Ovidiu Mățan: Phillip, felicitări pen-tru 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 com-parabilă 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 com-panie 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 gro-zav și o tehnologie remarcabilă, elaborată de o echipă de talie mondială care a făcut posibilă această afacere.

Probabil cel mai important aspect pen-tru 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 sigu-ranţă 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 con-struit, 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 supor-ter 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 vii-torul 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 eve-nimente 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.

Î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.






s ta rt u p w e e k e n d g l o b a l

s ta rt u p w e e k e n d c l u j

115+countries

556+cities

1200+ events

average of 93attendees per event

average of 10new ventures created

with a maximum of 150

h i s t o rY

2 0 1 2 + 2 0 1 3

20122013

now

250 4.8%

41.6%

53.6%NON TECH

DESIGNERS

DEVELOPERS

WOMEN 19.6%

MEN 80.4%& more juicy facts...

ideas pitched: articles about:

59 95

partners & media:

40

mentors:

28

jury:

19prizes value:

15,800€

connected devices:

580

chocolate:

24kg

energy drinks:

558

teams formed:

27

h o w a b o u t yo u w r i t e s o m e

COME, PITCH,h i s t o ry r i g h t n o w ?

FORM A TEAM& win!

BUT DON'T FORGETTO REGISTER

first!



Platforma 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 pen-tru 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 framework-uri sau implementarea noastră (pe care am ales-o într-un final), sau prin voce. Noi am vrut să implementăm VoIP din prima ver-siune 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 majo-ritatea au fost eliminate. Obiectivul nostru rămâne îmbunătăţirea aplicaţiei.

startups

Evolso

Alin Stă[email protected]

Project manager@ Evolso


Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: www.transylvania-jug.orgData înfiinţării: 15.05.2008 / Nr. Membri: 563 / Nr. Evenimente: 43

Comunitatea TSMComunitate construită în jurul revistei Today Software Magazine.Website: www.facebook.com/todaysoftmagData înfiinţării: 06.02.2012 /Nr. Membri: 1171/Nr. Evenimente: 16

Romanian Testing CommunityComunitate dedicata testerilor.Website: www.romaniatesting.roData înfiinţării: 10.05.2011 / Nr. Membri: 702 / Nr. Evenimente: 2

GeekMeet RomâniaComunitate dedicată tehnologiilor web.Website: geekmeet.roData înfiinţării: 10.06.2006 / Nr. Membri: 572 / Nr. Evenimente: 17

Cluj.rbComunitate dedicată tehnologiilor Ruby.Website: www.meetup.com/cluj-rbData înfiinţării: 25.08.2010 / Nr. Membri: 170 / Nr. Evenimente: 40

The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 396 / Nr. Evenimente: 55

Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: www.meetup.com/Cluj-Semantic-WEBData înfiinţării: 08.05.2010 / Nr. Membri: 152/ Nr. Evenimente: 23

Romanian Association for Better SoftwareComunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.Website: www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 235/ Nr. Evenimente: 14

Tabăra de testareUn proiect care își dorește să strângă cât mai mulți oameni care lucrează ca și testeri.Website: tabaradetestare.roData înfiinţării: 15.01.2012 / Nr. Membri: 1025/ Nr. Evenimente: 27

Februarie ș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.

Calendar Februarie 13 (Cluj)Lansarea numărului 20 al Today Software Magazinewww.facebook.com/todaysoftmag

Februarie 15 (Cluj)Hacaton de programe libere, ediția a III-aceata.org/evenimente/aniversarea-fundației-ceata-în-cluj

Februarie 17 (Cluj)Question-Answering Systemsmeetup.com/Cluj-Semantic-WEB/events/150657862/

Februarie 20 (Cluj)Machine Learning in Pythonmeetup.com/Cluj-py/events/165522292/

Februarie 22 (Timișoara)Meet the Vloggersit-events.ro/events/meet-vloggers

Februarie 22 (București)Electronic Arts CodeWarsit-events.ro/events/electronic-arts-codewars/

Februarie 22 (Iași)ISTC February 2014 Editionhttp://it-events.ro/events/istc-february-2014-edition/

Februarie 24 (Cluj)Mobile Monday Cluj #5meetup.com/Cluj-Mobile-Developers/events/153087052/

Februarie 27 (București)Gemini Foundry Conf - recomandarea TSMwww.gemsfoundry.com

Februarie 28 (Cluj)Startup Weekend Cluj - recomandarea TSMcluj.startupweekend.org

Martie 2 (Cluj)UBBots 2014it-events.ro/events/ubbots-2014

Martie 20-21 (Cluj)Cluj Innovation Days - recomandarea TSMwww.clujinnovationdays.com

Comunităţi IT

comunități

http://www.transylvania-jug.org

http://www.romaniatesting.ro

http://geekmeet.ro

Cluj.rb

http://www.meetup.com/cluj

http://www.agileworks.ro

http://www.meetup.com/Cluj

http://www.rabs.ro


testare

Am ales acest subiect deoarece testa-rea 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ă înde-plinim 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ță.

ArhitecturaDin 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 arhi-tecturi 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ă uti-lizatorului 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 Client-Server este folosirea așa numitului “Thin Client”, care în acestă arhitectură (2-Tier) este folosit nu cu mult peste prelua-rea comenzilor utilizatorului și afișarea informațiilor prin intermediul unui moni-tor. 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.

Performanța aplicațiilor este un subiect frecvent abordat, indiferent de natura apreci-ativă 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 com-

panii și de asemenea asupra satisfacției clientului.

O privire de ansamblu asupra testării

performanței aplicațiilor Desktop

Sorin [email protected]

Tester@ ISDC


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

Această aplicație este desenată de ase-menea pe două nivele (2-Tier) și utilizată cu precădere într-o infrastructură de tip intranet având un număr limitat de utiliza-tori. 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ă cone-xiune 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.

AbordareTestarea aplicațiilor client-server nece-

sită câteva cunoștințe tehnice adiționale pentru a putea trata anumite efecte intro-duse 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 trafi-cului pe rețea sau vulnerabilitatea în cazul unui atac de securitate.

Testarea acestor sisteme este într-ade-var 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 manipu-late 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 rea-lizată luând în considerare următoarele aspecte:

• Impactul acțiunilor utilizatoru-lui – cât de rapid răspunde sistemul la

solicitările venite de la utilizator;• Impactul asupra resurselor sis-

temului 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ă pen-tru Web: se înregistrează un flow sau mai multe, se creează unul sau mai multe profi-luri de utilizatori finali (aici putem include comportamentul și numărul utilizatori-lor pe fiecare flow sau chiar performanța stațiilor sau a rețelelor). Bazându-ne pe aceste profiluri putem aloca un număr dife-rit de utilizatori virtuali și rula acele teste de la nivel de Service-layer. Serverul ar tre-bui să poată procesa solicitări concurente venind de la diferiți clienți, având diferite profile.

Pe diverse canale de informare (pre-zentă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ă simu-leze un anumit grup de utilizatori finali, și care evident să exercite un stres specific pe întreaga structură.

Tool-uriDacă 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.

Din exper iență propr ie ș i d in 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 gra-fice la nivel de interfață a utilizatorului în aplicațiile Desktop (de exemplu nu simu-lează apăsarea unui buton, scroll-ul sau poziția mouse-ului pe ecran), fapt pen-tru care nu este un tool potrivit pentru

1 http://jmeter.apache.org/

testarea performanței aplicațiilor desktop la nivel de interfață a clientului. Jmeter-ul este construit pentru a exercita un anu-mit 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 indepen-dent 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 plat-forma Web și Desktop WPF (Windows Presentation Foundation). Nu are suport pentru aplicațiile construite pe tehnolo-gia Windows Forms.

• Infragistic TestAdvantage for Windows Forms3 – Construit pen-tru 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 tes-tarea ser vicii lor WCF (Windows Communication Foundation). Acesta suportă aproape toate tipurile de conexiuni netTcpBinding, wsHttp-Binding ș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 forum-uri. 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, par-tea de client este o aplicație care trebuie instalată și utilizată de către un singur utilizator, ceea ce înseamnă că în majori-tatea cazurilor nu se așteaptă ca aplicația să execute o mulțime de call-uri concu-rente, î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 /

testautomation4 http://www.wcfstorm.com/wcf/home.aspx

testare



rezultatele fără o întârziere prea mare.Aplicația instalată pe client precum

și resursele consumate de aceasta este de obicei monitorizată cu ajutorul unui instrument numit Profiling5.

Acest Profiling împreună cu un Performance Counter6 la nivel de SQL7 de exemplu, poate constitui o metodă solidă pentru a realiza ce se întâmplă de fapt in sistem (client și server).

Visual Studio are un profiler integrat. Fiind destul de avansat, permite măsurarea timpului necesar executării unei metode, precum și numărul apelărilor.

Pentru realizarea unui profiler la nivel de memorie, CLR Profiler permite vizua-lizarea consumului de memorie necesar rulării aplicației, dar și observarea obiecte-lor create de diferite metode.

Multe dintre tool-urile construite pen-tru testarea performanței de la nivel de interfață al utilizatorului pot fi folosite pentru înregistrarea unor flow-uri și mai târziu folosite pentru play-back pe mai multe stații.

RezultateCâteva dintre problemele identificate

în urma testării performanței aplicațiilor desktop ar putea fi menționate:

• Multe instanțe de SQL, greșit conce-pute. După optimizare, performanța s-a îmbunătățit simțitor.

• Câteva SQL statement-uri care erau executate în mai mult de un minut, au fost îmbunătățite astfel încât să returneze rezultate în mai puțin de o secundă.

• Câteva view-tables au fost identificate 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 /

dotnet-development/ants-performance-profiler/6 http://msdn.microsoft.com/en-us/library/w8f5kw2e.

aspx7 http://www.extremeexperts.com/sql/articles/

sqlcounters.aspx

ca fiind incorecte• Câteva index-tables care nu au fost

stabilite încă de la început, au fost identi-ficate și create ulterior testării.

• Prea multă memorie consumată în timpul rulării pe un profil care simula 1Gb RAM memorie. În acest caz performanța aplicației scade cu aproxi-mativ 15% pe flow-urile principale.

• Programul crash-uia uneori atunci când o anumită funcționalitate sau fea-ture din aplicație era folosită mai des deoarece avea ca rezultat depășirea con-toarelor sau a limitei de array-uri interne.

• Performanța scăzută datorată unor “late binding”-uri excesive, plus ineficiență în crearea și distrugerea obiectelor.

• Memory leak identificat în cazul în care aplicația era deschisă și neutilizată pentru o perioadă mai lungă de timp (câteva ore).

RiscuriÎn testarea performanței sistemelor

desktop, cele mai întâlnite probleme sunt relaționate la software și environment. Stabilitatea aplicației se pare că reprezintă îngrijorarea predominantă a testerului, cauza fiind multitudinea de situații în care tester-ul trebuie să lucreze cu o aplicație imperfectă sau neterminată.

Voi expune mai departe câteva dintre riscurile identificate și relaționate la testa-rea performanței soluțiilor desktop:

• Un risc destul de întâlnit este legat de utilizarea resurselor locale în tim-pul scripting-ului primelor teste. Acest fapt duce de multe ori la blocarea siste-mului din cauza consumării memoriei. Unele aplicații eșuează destul de des

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 exercita-rea un anumit stres, fapt care generează utilizare mai intensă. Bineînțeles, aceste probleme vor trebui rezolvate, însă există un impact asupra timpului, iar scripting-ul 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 benefi-ciază 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 tre-buie construită de la început.

• Al doilea risc este legat de faptul că regulile de business cum ar fi ajusta-rea 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 persoa-nele 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


testare

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

• Ambiția8 prea optimistă, cel puțin în stadiul incipient al proiectului. Persoanele implicate de obicei pre-spun 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 tes-terii 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 capa-citatea 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 progra-matorilor care au realizat designul și au implementat o anumită funcționalitate li se cere să creeze o suită de teste auto-matizate pentru a putea fi utilizate la testarea performanței, dificultatea princi-pală 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 fami-liarizare 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În final putem evidenția câteva con-

cluzii referitoare la aplicațiile construite pe platforma Desktop:

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

• 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 utilizatori-lor finali cu privire la aplicație? Scenariile de acest tip: cele mai comune, cele mai critice din punct de vedere al busine-ssului 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, infra-structura, 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 tes-tarea 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 utilizato-rul, 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 întot-deauna 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,

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

versiunilor sau configurațiile hardware pot crea probleme în definirea profilu-rilor “utilizatorilor finali”. E imposibilă simularea tuturor acestor combinații, prin urmare o idee bună putând fi prio-ritizarea 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 testing-ului de performanță de ordin logistic, organizațional sau tehnic pot fi evitate aplicând principii cum ar fi:

a. abordarea testing-ului în arhi-tecturile 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 tes-tare 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, tre-buie 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 flow-uri 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 servi-ciu care transferă fișiere de exemplu, nu am găsit niciun tool capabil să facă browse pe disk pentru acel fișier;

b. aplicaț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.

L a o p r i m ă v e d e r e , t e s t a r e a performanței aplicațiilor desktop pare să fie destul de diferită, soluțiile existente ofe-rind o gamă destul de vastă în posibilitățile de testare. Cu toate acestea, să nu uităm că asigurarea calității fundamentale, împre-ună cu principiile de bază rămân la fel și se aplică tuturor.

Enjoy testing !!

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


Software Craftsmanship şi Lean Startup

Î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 tes-tul 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 produ-sul 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 pen-tru a putea valida ipoteza. Experimentele cele mai întâlnite, în special pentru pro-dusele 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 presu-pune o agilitate foarte mare determinată de lucrul într-un mediu necunoscut și în curs de descoperire. Dacă în modelul standard de dezvoltare de produs presupu-nem 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 meto-dei. Motivele sunt două: revoluția trebuia făcută în primul rând la nivel business și presupunerea autorilor a fost că progra-matorii își vor da seama ce practici tehnice trebuie să folosească.

management

Alexandru [email protected]

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

Adrian [email protected]

Programmer. Organizational and Technical Trainer and Coach@Mozaic Works



managementSoftware 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 experi-ment 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: monitori-zare, 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.

D a c ă l e g ă t u r a c u S o f t w a r e Craftsmanship nu este clară încă, o vom explora în continuare. După cum spuneam în ar t icolul despre Software Craftsmanship[http://www.todaysof tmag.com/ar t ic le/en/11/Software_Craftsmanship__404], mișcarea a apărut pentru a permite reducerea costu-lui de schimbare al codului prin aplicarea anumitor practici cunoscute și prin des-coperirea altor practici noi. Câteva dintre practicile pe care le cunoaștem acum sunt:

• Test Driven Development, pentru a obține incremental un design adap-tat problemei curente și deschis la modificare.

• Testarea automată, pentru evitarea regresiilor.

• Principiile SOLID, design patterns și cunoștințele de design pentru a evita problemele de design

• Clean Code pentru a scrie cod ușor de citit și de înțeles.

• Refactoring pentru a readuce design-ul la nivelul necesar atunci când începe să nu mai fie potrivit.

Î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 expe-rimente, nu are rost să investim mai mult decât este necesar. Cele mai bune experi-mente sunt cele care nu necesită cod scris. Dacă totuși trebuie scris cod, este impor-tant să îl scriem cât mai repede cu putință, chiar dacă pot scăpa greșeli.

Imediat ce o funcționalitate a fost vali-dată, 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ă programato-rii care au exersat îndeajuns aceste tehnici

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 atunci când viteza de implementare este extrem de importantă.

ConcluzieLean Startup se bazează pe artizani

software (craftsman). Experimentele cele mai bune sunt cele care nu necesită cod. Uneori, este nevoie și de implementarea unor experimente. Un artizan software va fi capabil să le implementeze rapid și fără a introduce probleme.

Dacă în faza de descoperire putem trăi și fără a aplica practici precum TDD, testare automată sau refactoring, faza de implementare are mare nevoie de ele pen-tru a permite punerea cât mai rapidă în producție a functionalităților validate de experimente. Cu cât sunt puse mai rapid în producție cu atât crește probabili-tatea de a avea clienți plătitori, asigurând supraviețuirea startup-ului și crescându-i șansele de succes.

http://www.todaysoftmag.com/article/en/11/Software_Craftsmanship__404




TODAY SOFTWARE MAGAZINE programare

Vagrant pentru începători

De 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ăs-puns 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 înce-put 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 pro-gramare 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 pen-tru 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 confi-gurare Vagrantfile, care este deja configurat, fără să-ți mai faci griji cum să reconfigurezi aplicația4.

1 https://github.com/mitchellh2 http://www.vagrantup.com/3 https://github.com/mitchellh/vagrant4 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 configu-

rat (Vagrantfile).• un fișier de configurare ușor de modificat –> infrastruc-

tură 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–> folo-

sind 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ă insta-

lezi 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 instala-rea 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.

$ vagrantUsage: vagrant [-v] [-h] command [<args>] -v, --version Print the ver-sion and exit. -h, --help Print this help.Available subcommands: box manages boxes: installation, re-moval, 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 envi-ronment by creating a Vagrantfile package packages a running vagrant envi-ronment into a box plugin manages plugin s: install, unin-stall, update, etc. provision provisions the vagrant machine reload restarts vagrant machine, loads

5 http://www.vagrantup.com/downloads


programareVagrant pentru începători

new Vagrantfile configuration resume resume a suspended vagrant machine ssh connects to machine via SSH ssh-config outputs OpenSSH valid configuration to connect to the machine status outputs status of the vagrant ma-chine suspend suspends the machine up starts and provisions the vagrant environment

Următorul pas este inițializarea instrumentului Vagrant în noul proiect, rulând comanda:

$ vagrant init

A `Vagrantfile` has been placed in this directory. You are nowready to `vagrant up` your first virtual environment! Please Read the comments in the Vagrantfile as well as docu-mentation on`vagrantup.com` for more information on using Vagrant.

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.

config.vm.box_url = “http://files.vagrantup.com/pre-cise32.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. 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 scheletului mașinii virtuale, trebuie verficat provider-ul pe care se 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 toate base-box-urile care sunt disponibile. Vagrant oferă de ase-menea, posibilitatea de a crea “cutii” personalizare. Un instrument util în acest scop este Veewee6, care are ca obiectiv automatizarea tuturor pașilor pentru construirea acestor “cutii” cât și colectarea celor mai bune practici într-o modalitate transparentă. O “cutie” poate fi adăugată și din linia de comandă tastând:

$ vagrant box add <name> <url>

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 -hUsage: vagrant box <command> [<args>]Available subcommands: add list remove repackageFor help on any individual command run `vagrant box COMMAND -h`

Selectarea provider-ului de virtualizareSunt 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

www.3pillarglobal.com

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

Our core competencies include:

ProductStrategy

ProductDevelopment

ProductSupport

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



“cutii”. O opțiune constă în specificarea provider-ului ca para-metru din linia de comandă. Dacă este selectată această metodă, trebuie să te asiguri că argumentul prevăzut coincide cu cel speci-ficat în directiva config.vm.provider.$ vagrant up --provider=virtualbox

Celalaltă opțiune este să se specifice provider-ul doar în direc-tiva config.vm.provider.

Important de menționat este faptul că unele “cutii” nu necesită specificarea provider-ului, deoarece pot funcționa cu orice tip de provider.

Configurarea parametrilor mașinei virtualeVagrantfile oferă posibilitatea configurării provider-ilor prin

adăugarea directivei vb.customize. De exemplu, dacă vrei să mărești memoria alocată mașinii virtuale, poți să faci cum este descris mai jos.

# Provider-specific configuration so you can fine-tune various # backing providers for Vagrant. These expose provider-specific options. # Example for VirtualBox: # config.vm.provider :virtualbox do |vb| # # Don’t boot with headless mode # vb.gui = true # # # Use VBoxManage to customize the VM. For exam-ple to change memory: vb.customize [“modifyvm”, :id, “--memory”, “2048”]

end

Configurarea rețeleiAccesarea 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 mașina virtuală, de pe mașina locală. Vagrantfile are trei directive care pot fi folosite pentru configurarea rețelei.

• config.vm.network :forwarded_port, guest: 80,

host: 8080

Traducând această directivă, deducem faptul că Apache-ul instalat pe mașina virtuală, creată de Vagrant, poate fi accesat de pe mașina locală, folosind url-ul http://127.0.0.1:8080. Aceasta înseamnă că tot traficul din rețea a fost redirecționat spre portul specificat pe mașina virtuală.

# Create a forwarded port mapping which allows ac-cess to a specific port # within the machine from a port on the host ma-chine. In the example below, # accessing “localhost:8080” will access port 80 on the guest machine. config.vm.network :forwarded_port, guest: 80, host: 8080

• config.vm.network :public_network

# Create a public network, which generally matched to bridged network. # Bridged networks make the machine appear as an-other physical device on # your network. config.vm.network :public_network

• config.vm.network :private_network, ip: “192.168.33.10”

# Create a private network, which allows host-only

access to the machine # using a specific IP. config.vm.network :private_network, ip: “192.168.33.10”

Modificarea setărilor SSHVagrantfile oferă posibilitatea de a confgura namespace-ul

config.ssh pentru a specifica numele utilizatorului, host-ul, port-ul, guest_port-ul, private_key_path, forward_agent, forward_x11 și shell.

Vagrant.configure(“2”) do |config| config.ssh.private_key_path = “~/.ssh/id_rsa” config.ssh.forward_agent = trueend

Sincronizarea directoarelor locale cu cele de pe mașina virtuală

În timp ce mulți utilizatori editează fișierele de pe mașinile virtuale folosind doar editoare sincronizate cu mașina virtuală prin SSH, Vagrant oferă posibilitatea de sincronizare automată a fișierelor de pe ambele mașini, folosind folder-ele sincronizate. În mod implicit Vagrant oferă posibilitatea da a sincroniza fișierele de pe mașina locală, cu directorul /vagrant de pe mașina virtu-ală. În acest fel directorul /vagrant localizat pe mașina virtuală, este identic cu cel de pe mașina locală. Astfel nu mai ești nevoit să folosești opțiunile de Upload și Download, din IDE pentru sincronizarea fișierelor. Dacă vrei să modifici directorul sincro-nizat de pe mașina sincronizată, o poți face adăugând următoarea directivă config.vm.synced_folder “../data”, “/vagrant_data” în Vagrantfile.

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

end

Provisionarea mașinii virtualeProvizionarea nu este o sarcină de care se ocupă în mod nor-

mal dezvoltatorii, deoarece administratorii de sistem sunt cei care fac lucrurile acestea. Ideea de la care se pornește este de a înregis-tra configurările setate pe un server, cu scopul de a le replica pe un alt server. Mai demult administratorii de sistem țineau un wiki pentru comenzile rulate pe servere, dar această metodă nu era cea mai bună. Altă opțiune este să creezi back-up-uri .box sau .iso, ast-fel încât noile servere să poată fi configurate pe baza acestor fișiere. Dar, menținerea la zi a acestor fișiere este dificilă și necesită mai multă muncă, fiind în același timp destul de greu să sincronizezi toate serverele în acest fel. Provizionarea în zilele noastre, oferă posibilitatea de a adăuga software special pentru creare fișierelor de configurare, pentru executarea comenzilor, pentru crearea utili-zatorilor sau managementul serviciilor, folosind sisteme moderne de provizionare. Vagrant poate fi integrat cu următoarele sisteme de provizionare: Shell, Ansible, Chef Solo, Chef Client, Puppet, Salt Stack. Cele mai populare sisteme de provizionare sunt Chef și Puppet, fiind menținute de o comunitate mare de utilizatori. Ambele sunt scrise în Ruby, având caracteristici similare cum ar fi modularizarea componentelor, pachete pentru instalarea software-ului sau template-uri pentru fișiere personalizate. Ambele sisteme sunt open source cu un model de plata pentru companii. O scurtă trecere în revistă pentru Puppet și Chef este prezentată în tabelul de mai jos.

Provizionarea cu ShellProvizionare cu Shell în Vagrant este relativ ușoară. Poți scrie


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

Comandă inlineconfig.vm.provision :shell, :inline => “curl -L htt-ps://get.rvm.io | bash -s stable”

Cale fișier localconfig.vm.provision :shell, :path => “install-rvm.sh”, :args => “stable”

Cale fișier externconfig.vm.provision :shell, :path=>”https://example.com/install-rvm.sh”, :args => “stable”

Provizionare cu PupppetModulele Puppet pot fi descărcate de pe https://github.com/

puppetlabs. Pe disc, un modul este un director care are structura prezentată în Fig. 1 Structura unui Modul Puppet. Programele

Puppet se numesc “manifests” și folosesc extensia .pp pentru fișiere.

Manifests pot folosi tipuri vari-ate de logică, cum sunt declarațiile condiționale, colecțiile de resurse, funcții pentru generarea textului, etc.. Dacă nu vrei să setezi manual fișierele manifest, există un instru-ment foarte simplu de utilizat cu GUI, care poate genera automat toate aceste fișiere. Acest instru-

ment se numește PuPHPet7. Pentru a configura manual

Vagrant cu Puppet, trebuie să setezi directivele Puppet după cum urmează:

config.vm.provision :puppet do |puppet| puppet.manifests_path = “./tools/puppet/mani-fests/” puppet.module_path = “./tools/puppet/modules” puppet.manifest_file = “init.pp” puppet.options = [‘--verbose’]End

unde init.pp este de forma

include mysql::serverclass { ‘::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_con-fig_file, $package_ensure = mysql::params::server_pack-age_ensure,)

7 https://puphpet.com

MySql params.pp, din module/manifests/params.pp

class mysql::params { $manage_config_file = true $old_root_password = ‘’ $root_password = “strongpassword”

}

module/manifests/templates

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

%>

Provizionarea cu Chef8 SoloRețetele Chef Solo pot fi descărcate de pe Opscode9. Structura

unei rețete Chef este prezentată în Fig. 2. Structura unei Rețete Chef Solo. Pentru adăugarea configurațiilor doar fișierele scrise îngroșat trebuie modificate.

Vagrantfile trebuie modificat după cum este afișat mai jos pentru a folosi Chef Solo ca provizionar. config.vm.provision :chef_solo do |chef| chef.cookbooks_path = “cookbooks” chef.add_recipe “va-grant_main” # chef.roles_path = “../my-recipes/roles”

# chef.data_bags_path = “../my- recipes/data_bags” # chef.add_role “web” # # # You may also specify custom JSON attributes: # chef.json = { :mysql_password => “foo” } end

unde vagrant_main are următoarea structură:

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/www8 http://www.getchef.com/9 http://community.opscode.com/

Table 1. Chef vs. Puppet

Fig. 1 Structura unui

Modul Puppet

Fig 2. Structura unei

Rețete Chef Solo

Vagrant pentru începătoriprogramare



<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-er-ror.log CustomLog <%= node[:apache][:log_dir] %>/tsm-access.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 folder-ul 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 confi-gurat. Î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.

D:\projects\tsm> vagrant upBringing machine ‘default’ up with ‘virtualbox’ pro-vider...[default] Box ‘precise32’ was not found. Fetching box from specified URL for the provider ‘virtual-box’. Note that if the URL does not have a box for this provider, you should interrupt Vagramt now and add the box yourself. Otherwise Vagrant will attempt to download the full box prior to discovering this error.Downloading box from URL: http://files.vagrantup.com/precise32.boxProgres: 1% <Rate: 41933/s, Estimated time remain-

ing: 2:15:30>

După ce a fost creată mașina virtuală, poți rula comanda vagrant ssh pentru accesare. Pentru sistemele de operate Windows poți instala clientul PuTTY SSH, pentru accesarea mașinii virtu-ale, folosind credențialele de mai jos.

D:\projects\tsm> vagrant ssh‘ssh’ executable not found in any directories in the %PATH% variable. Is an SSH client instaled? Try in-stalling 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.1Port: 2222Username: vagrantPrivate 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 --provision-with 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/

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.

Comparând metodologia de lucru a celor două instrumente, putem enunța următoarele afirmații:

1. Vagrant este mai bun pentru că păstrează codul sursă și informațiile de deployment în același loc.

2. Vagrant este mai bun pentru că este stabil și poate fi folosit în producție.

3. Vagrant este mai bun pentru că poate fi integrat cu Linux, Windows și Mac OS X.

4. Docker este mai bun pe parte de provizionare.5. Procedura de roll back este mai rapidă și mai ușoară datorită

sistemului de instantanee.6. Docker a venit cu un nou model de deployment.7. Docker poate fi integrat doar cu mașinile de Ubuntu.8. Docker nu este recomandat în producție deoarece este încă

în faza de dezvoltare.

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 reconfi-gurez de la 0. De când folosesc Vagrant, nu îmi mai fac asemenea griji, pentru că există Vagrantfile, care îmi păstrează toate confi-gură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 momen-tul 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.

Fig 4. Vagrant – Procesul de lucru

Carmen Frățilă[email protected]

Software engineer@ 3Pillar Global


Sorina [email protected]

Marketing manager@ Fortech

management

Startup marketing: provocări şi repere

Buget, 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ă dese-

ori 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 market-ing și cu siguranță “trăite” de multe organizații în primele etape ale existenței.

În primul rând, poate mai mult decât alte procese, marketingul în startup-uri este inovativ. Resursele limitate pun mana-gerii ș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 difi-cil 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 insta-bilă, situația socio-economică etc.).

În sfârșit, marketingul este puternic influențat de personalitatea manageru-lui 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 caracteristi-cile 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 neajun-suri. Un exemplu simplu e blocajul la nivel decizional; pot fi situații în care, în absența managerului - antreprenor, nu se iau deci-zii ș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 seg-mentare - ț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ăs-punde 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 viito-rului 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 caracte-ristici demografice, sociale, economice ale acestuia: vârstă, profesie, venituri, obice-iuri, ce interese are etc. .

Odată identificat consumatorul, nevoia adresată de produs și avantajul competi-tiv 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 (mis-sion 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 pen-tru 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 intelec-tuale: înregistrarea mărcii, a elementelor grafice, “parcarea” unui domeniu web dorit, a denumirilor paginilor pe rețelele sociale etc. .

Apoi urmează partea cea mai intere-santă și mai provocatoare pentru un om de marketing într-un startup: generarea cere-rii 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, efor-turi de outreach către segmentele țintă.

Inbound marketing - include eforturi de marketing care, dimpotrivă, fac produsul sau compania să fie “găsite” de consuma-tori și nu viceversa. În sfera marketingului digital, implică dezvoltarea unui website care să atragă vizitatorii în mod natural, prin optimizare pentru motoarele de cău-tare, 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 impor-tante, dar e important și ca acestea să aibă fundamente solide, și anume un produs de calitate, care încântă și nu dezamăgește uti-lizatorii. 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 spiritMature organizationA shared vision

Join our journey!

www.fortech.ro


Daniel [email protected]

Membru în Consiliul Director@ Cluj IT Cluster

management

Clusterul Cluj IT şi Antreprenoriatul

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ă compa-rativ 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 calita-tea 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ă sin-gura 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.

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 fundamen-tală, 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 pre-gă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ă

Î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 întreba-rea 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.


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 auto-educare 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.


interviu

Interviu cu Radu Georgescu

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 por-nit î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 fai-moasa 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 teh-nologia ș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 teh-nologia 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ă securita-tea 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 biro-uri î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 pro-blemă : este dependent în general de unul

Î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 con-

struirea 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.





sau doi clienți, este o vânzare ieftină de minute-om, nescalabilă, în timp ce produ-sul 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 intere-sante, 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 vizio-nar, 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 pan-tofii, 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 startup-uri 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 rate-urilor 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 la MavenHut , Uber vu, S of tpedia , 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 outsour-cing, 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.


startups

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 pro-puse 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 ima-gini 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 con-struiesc 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 „ener-gie”, 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.

Constrângerea impusă asupre RBM-urilor este că neuronii tre-buie să formeze un graf bipartit, ceea ce în practică înseamnă că nu există legături între neuronii din stratul vizibil, nici între neu-ronii 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

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 cores-punde 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 aso-ciate 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.

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:

Restricted Boltzmann Machines

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

programare

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


unde reprezintă probabilitatea de activare a unui singur neuron:

este funcția logistică

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

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.

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 com-plexe ș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

clasificarea notițelor sau pentru recomandare de muzică. În conti-nuare 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.

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) 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 pen-

tru literele B, R, S și pentru cifrele 0, 8, 7 și altele

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ă abor-dare la învățarea reprezentărilor interne, cu autoencodere.

startups

Roland [email protected]

Junior Python Developer@ 3 Pillar Global


Maven, The Definitive Guide

Maven este unul dintre cele mai cunos-cute project builder-e, alături poate de Ant, un produs tot Apache. Deosebirile majore între acestea două constau în faptul că Ant este orientat doar spre procesare, compi-lare, împachetare, testare și distribuţie. Pe lângă capabilităţile de build, amintite ante-rior, Maven poate rula rapoarte, genera rapoarte sau facilita comunicarea între membrii unei echipe de lucru.

Dacă rolul fundamental al lui Maven este acela de a pune împreună compo-nente, ce fac parte dintr-un proiect, putem afirma cu certitudine că știu proiecte de succes care nu folosesc Maven pentru aceste scopuri. Fie că fișierele Maven sunt generate și rulate automat, fie că nu există pur și simplu Maven. Dependenţa directă a diverselor componente elimină într-o mare măsura folosirea acestui instrument.

Revenind la cartea care reprezintă obiectul acestei recenzii, Maven The Definite Guide, apărută la O’Reilly în anul 2008, aceasta este un ghid complet de înţe-legere și folosire a Maven-ului.

Primele două capitole, care constituie și prima parte, sunt o scurtă introducere în Maven, dar care aduc și detalii foarte importante de instalare și rulare pe toate platformele (acestea includ Mac, Windows, Linux, FreeBSD sau Open BSD).

Partea a doua este centrată pe exem-ple. Exemplele pornesc gradual și ajung să constituie o sursă suficientă de informaţie pentru a utiliza cu succes Maven. Pe lîngă explicaţii, autorii furnizează exemple, care pot fi descărcate.

După dezvoltarea primului proiect, simplu, dar cu importante clarificări teo-retice, vom avea ocazia să customizăm

proiectul pentru a-l aduce aproape de o formă reală. Aceasta înseamnă adăuga-rea de dependenţe, resurse și unit teste. Proiectul, din punctul de vedere al compo-nentelor Java, va conţine un servlet simplu, pe care îl vom introduce într-un proiect multimodul.

În capitolele următoare se vor crea proiecte enterprise complexe, folosind fra-mework-urile Spring și Hibernate. Nu este obligatoriu să fii un bun cunoscător al aces-tor tehnologii. Ideile abordate sunt simple. Accentul se pune aproape exclusiv pe con-struirea fișierelor de Maven.

Partea a treia aduce în discuţie ideea de performanţă. Dacă până în acest moment ne-am familiarizat cu conceptele Maven și am construit un proiect enterprise simplu, dar cuprinzător, de acum încolo autorii încearcă să deschidă cititorilor drumul spre îmbunătăţirea controlului asupra dependenţelor și plugin-urilor pentru a ușura mentenanţa viitoare a construcţiilor. Curăţarea POM-ului, optimizarea depen-denţelor și a plugin-urilor sunt tehnici de minizare a duplicărilor, cu un rol esenţial în evitarea problemelor viitoare.

Capitolul nouă oferă o analiză amă-nunţită referitoare la conceptul și suportul fizic POM. Analogia, pentru începători, o fac cu fișierul web.xml din Java. Așa cum descrie aceasta, configurează și custo-mizează aplicaţia, în același fel pom.xml definește proiectul Maven. Probabil că citi-torii vor descoperi cu plăcere conceptele pe care autorii le introduc ca aparținând sferei POM: Super POM, Simplest POM, Effective POM, Real POM și nu în ultimul rând POM best practices.

Capitolul zece clarifică noţiunea de

ciclu de viaţă al unui build. Autorii, ca și în cazul lui POM, descriu mai multe tipuri de cicluri de viaţă, cititorul fiind îndem-nat să le citească: Clean Lifecycle, Default Lifecycle, Site Lifecycle.

Un profil de build ne permite să custo-mizăm un build pentru un anumit mediu, asigurând astfel portabilitatea între aceste medii. Cele considerate în carte sunt: pro-ducţia și dezvoltarea. Capitolul unsprezece aduce în discuţie conceptul de profil de build. În primul rând aflăm cât este de importantă portabilitatea, cât de mult influenţează portabilitatea performanţele proiectului și care este nivelul potrivit de portabilitate.

Maven Assemblies sunt discutate în capitolul doisprezece și aprofundate în capitolul treisprezece. Așadar, putem crea o paletă largă de arhive: JAR, WAR, EJB sau EAR. Asamblarea este un proces complex ce necesită descriptori cu o structură com-plicată, dar descrisă amănunţit în această carte.

Capitolul patrusprezece este un ghid excelent de utilizare al Maven-ului folosind Eclipse.

Ultimele capitole prezintă detaliat eta-pele generării unui site folosind Maven, un Repository Manager respectiv scrierea de plugin-uri.

Aștept cu mare plăcere comentariile și discuţiile cititorilor pe programez.ro.

Vă doresc lectură placută!

Voi î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.

Silviu [email protected]

Consultant Java@ msg systems Romania

programare

http://maven.apache.org


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.

Var iabi le le condiț iona le au în standardul C++11 nu o singură imple-mentare, ci două: std::condition_variable și std::condition_variable_any. Ambele imple-mentări pot fi folosite prin includerea header-ului <condition_variable>. Pentru a facilita comunicarea între thread-uri, variabilele condiționale sunt, de obicei, asociate cu un mutex, pentru std::condition_variable sau cu orice alt mecanism care oferă excludere mutu-ală, 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 nece-sitate 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; }

}

Dumitrița [email protected]

Software engineer@ Arobs


programareMultithreading î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 ape-lează 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ă standar-dului 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 retur-nează 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 înde-plinită. 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, folo-sită 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.

FuturesUn 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 mode-late 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 asin-cronă al cărei rezultat nu este imediat necesar. În loc să așteptăm

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_re-sult.get() << std::endl;

}

Un obiect std::async este o utilitate de nivel înalt care furni-zează 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ă.

PackagesUn 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 ape-labil ș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 din-tre acestea poate fi mapată într-o instanță std::package_task<>, care va fi returnată managerului de operații. Astfel, se abstracti-zează 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).



PromisesAșa cum am văzut la secțiunea Futures, transmi-

terea datelor între thread-uri se poate efectua prin transmiterea acestora ca parametri către funcția thread-ului 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 ulte-rior 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_fu-ture()); //-- (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 pen-tru 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 pen-tru 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 apela-rea 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 exclu-sivitate 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 inter-mediul unui std::future.

AtomicsPe lângă mecanismele de excludere mutuală prezentate ante-

rior, standardul C++11 introduce și tipurile atomice.Un tip atomic std::atomic<T> se poate folosi cu orice tip T și

garantează că orice operație asupra obiectului std::amotic<T> va fi atomică, adică se va executa în întregime sau deloc.

U n a v a n t a j a l f o l o s i r i i t i p u r i l o r a t o -mice p entr u exc ludere mutua lă es te p er for manț a ,

deoarece în acest caz se folosește o tehnică lock-free, mult mai economică decât utilizarea unui mutex care poate fi relativ costi-sitor î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 obiec-tul atomic returnând în același timp valoarea setată anterior. De asemenea, mai sunt două metode compare_exchange_weak și com-pare_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 pen-tru 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 incre-mentată 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, decre-mentă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.

ConcluziiAm 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 com-porte conform așteptărilor. Pentru o aprofundare a celor discutate dar și o extindere a cunoștințelor referitoare la noile concepte dis-ponibile în standardul C++11, recomand cu încredere cartea lui Anthony Williams, C++ Concurency in Action, precum și ultima ediție a clasicei The C++ Standard Library, de Nicolai Josuttis. Veți găsi acolo nu doar o detaliere a subiectelor prezentate anterior ci și descrierea altor caracteristici specifice standardului C++11, incluzând tehnici de utilizare ale acestora, pentru programarea multithreding la un nivel avansat.


programare

Î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 dezvol-tare 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 metri-cele pe care le putem calcula folosind direct ceea ce ne pune la dispoziție Visual Studio.

De ce ar trebui să rulăm un astfel de tool?

Acest tip de tool ne ajută să detectam posibilele probleme pe care aplicația noas-tră le are, informându-ne în același timp și asupra calității codului pe care l-am scris. Așa cum se va vedea în rândurile de mai jos, toate regulile și recomandările pe care Microsoft le are legate de cod se regăsesc în acest tool.

O parte dintre defectele pe care le des-coperă un astfel de tool sunt uneori extrem de greu de găsit folosind unit teste. Datorită unui tool de acest gen, putem avea certitu-dinea că aplicația pe care o scriem este de calitate.

Ce metrice putem să obținem?Începând cu Visual Studio 2013, toate

versiunile de Visual Studio (mai puțin Visual Studio Test Professional) ne oferă posibilitatea să calculăm metricele direct din el. De la bun început trebuie să știm că numărul de metrici pe care le putem cal-cula folosind Visual Studio este limitat. Din păcate, nu avem posibilitatea să cal-culăm toate metricele care sunt disponibile în Sonar, dar există câteva extensii pentru Visual Studio care ne ajută să calculăm și alte metrice, nu doar pe cele care există în Visual Studio.

Visual Studio ne permite să calculăm o parte dintre metrice folosind Static Code Analysis. Acesta analizează codul încercând

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 posi-bile probleme legate de:

• Design,• Performanță,• Securitate,• Globalizare,• Interoperabilitate,• Cod duplicat,• Cod care nu este folosit.

Sau multe alte probleme. Totul ține și de abilitatea pe care o are dezvoltato-rul pentru a interpreta aceste metrice. Un aspect interesant la acest analizator este faptul că toate regulile și recomandările pe care Microsoft le are legate de cod, de sti-lul codului și de modul în care trebuie să folosim diferite clase și metode se regăsesc în acest analizator. Toate aceste reguli sunt grupate în diferite categorii.

Prin acest mod identificăm cu ușurință zone din aplicația noastră care nu folosesc un API așa cum ar trebui. În cazul în care doriți să creați o regula specifică veți avea nevoie de Visual Studio 2013 Premium sau Ultimate. Aceste două versiuni de Visual Studio ne permit să adăugăm reguli noi, specifice proiectului sau companiei în care lucrăm. Odată aceste reguli adăugate, anali-zatorul de cod va verifica dacă acestea sunt respectate, avertizându-ne în cazul unei abateri de la reguli. Din păcate în acest moment putem să analizăm doar codul scris C#, F#, VB și C/C++.

O parte dintre cititori ar putea să spună că acest lucru se putea face și în versiunile mai vechi de Visual Studio. Se poate sub-scrie la afirmația lor, dar trebuie adăugat că această nouă versiune (2013) a adus în plus posibilitatea de a analiza codul fără să fie

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ă enforsa-rea 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ă selec-tă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 imple-mentează 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ă

Metrici în Visual Studio 2013



rulăm acest tool și ca parte din buid. Pentru aceasta este nevoie să activăm această 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ă pro-blemă. Î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ă mer-gem î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

avem la dispoziție alte două tool-uri interesante.

Code ClonesAcest tool ne permite să

detectăm automat codul care este duplicat. Important de pre-cizat 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.

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ă metrică ne putem da seama destul de ușor de câte linii de cod am putea să scăpăm.

Code MetricsPrin intermediul acestui tool analizăm

fiecare proiect pe care îl avem în soluție și extragem diferite metrice. Fiind un tool integrat cu Visual Studio, putem să navi-găm în fiecare proiect și să vedem valoarea fiecărei metrice de la nivel de proiect, până la nivel de namespace, de clasă și metodă.

Există cinci metrice analizabile folosind Code Metrics:

• Lines Of Code ne precizează numă-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ă

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ă nive-lul 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.

ConcluzieÎn acest articol am descoperit că și

Visual Studio ne pune la dispoziție diferite metode pentru a verifica calitatea codului. Unele dintre aceste tool-uri sunt disponi-bile în versiuni normale de Visual Studio, iar altele doar în varianta Ultimate. În comparație cu Sonar, Visual Studio nu per-mite efectuarea de share la aceste metrice prin intermediul unui portal. În schimb, ne permite să le exportăm într-un Excel pen-tru a le putea trimite la echipă. Tool-urile din Visual Studio sunt un bun început pen-tru orice echipă sau dezvoltator care vrea să se informeze asupra calității codului scris de el sau de echipă.

Radu [email protected]

Senior Software Engineer@iQuest


Cum putem construi un astfel de model? Pentru sisteme sim-ple (embedded) putem să calculăm direct ciclurile de procesor necesare pentru executarea programului. Dar pentru programe tipice există prea mulţi factori ca să putem aplica metoda directă (sistemul de operare, alte procese care rulează concomitent, JIT-ul, GC-ul, etc.). Alternativa pe care o avem este să executăm teste empirice și să construim modelul pe baza rezultatelor obţinute.

În cazul acesta trebuie să ţinem cont de câteva reguli ca să obţinem un rezultat corect:

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

Folosind JMeter1 rulăm un test de încărcare (load test) și obţi-nem 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*dis-persie2. Suntem încrezători în rezultat pentru că:

• am folosit URL-uri realistice în teste (nu am accesat un sin-gur 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 con-cret: presupunem (pentru simplitate) că am executat 100 de teste și valorile de latenţă măsurate au fost următoarele (valorile numerice

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

pot fi accesate aici3 pentru verificarea calculelor):

Imediat putem observa că valorile se pot clasifica în trei categorii:

• 30% - valori mici (poate datele se aflau în cache deja);• 60% - valori medii (datele nu se aflau în cache și s-a executat

codul tipic);• 10% - valori foarte mari (am întâmpinat cazuri limită - cor-

ner case);

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 ime-diat 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 dife-renţ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ă (gaus-siană) 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 coordonateOmisiunea 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

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

Latenţ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).


programare



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:

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

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.

ConcluzieDin 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ăl-zească” (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 tes-tare 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

Attila-Mihaly [email protected]

Code Wrangler @ UdacityTrainer @ Tora Trading


management

Thinking in Kanban

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 realiza-rea și asigurarea unui control de calitate.

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

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

Principiile Kanban Kanban se bazează pe două principii

fundamentale:1. Vizualizarea fluxului de muncă,2. Limitarea activităţilor în progres.

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

pentru a fi înţelese şi procesate mai uşor şi mai rapid. Pe de-o parte, toţi memb-rii 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 proi-ect, un exemplu clasic de Kanban board pentru software development se poate urmări în figura ataşată.

Limita WIP (Work-In-Progress) asigură muncă focusată și astfel mai efi-cientă. 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 mul-titasking-ului se elimină timpul necesar pentru alternare. Prin executarea task-uri-lor în mod secvenţial, rezultatele apar mai repede și timpul total al efectuării acestora este mai scurt.

Metrici în KanbanPentru a putea estima cât mai corect

dimensiunile de timp și volumul de muncă în Kanban există metrici ce ajută la defini-rea 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ă clien-tului ş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 pro-cesului şi reflectă eficienţa de muncă a echipei.

Pentru a mări performanţa echipei, scopul este diminuarea metricilor de Lead-time și Cycle-time.

Legea lui Little:

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

Carte 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.



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

Flexibilitatea în KanbanUn Kanban board este complet con-

figurabil î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 onlineLa î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 cola-borarea ș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ă funcţiile similare unui board fizic. Mai mult

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 KanbanMenţionam în rândurile de mai sus fle-

xibilitatea ș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.

Personal KanbanÎn anul 2011 Jim Benson a introdus

ideea conform căreia Kanban este perfect pentru organizarea timpului şi a task-urilor personale. Conceptul devine din ce în ce mai popular şi utilizatorii Personal Kanban spun că metoda funcţionează.

Î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ă productivitatea personală şi să faciliteze atingerea scopurilor pe termen lung.

Scrumban. PomodoroBanNumele sugestive indică combinarea

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în-treruptă, 5 minute pauză. PomodoroBan păstrează și aplică principiile Kanbanului adăugându-i un plus de eficienţă.

ConcluziiFie 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 rapide de îmbunătăţire a calităţii și proce-sului de muncă.

Referinţehttp://www.kanbanblog.com http://kanbantool.comJim Benson: Personal Kanban (2011)

Püsök [email protected]

Functional Architect@ Evoline

http://kanbantool.com


Astăzi, știm clar că, înainte de a demara un proiect nou indiferent de industrie, este nevoie de un plan de acțiune. În majori-tatea 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, tra-sează 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 caracteris-tici, 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 tre-buie 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

concept de business, nu avem premise de succes, chiar dacă ideea de business pare spectaculoasă și unică.”

În cazul unui proiect software demon-strarea 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 busi-ness angels agreează ideea unui POC în locul unui plan de business clasic.

Wayne Sutton, blogger la Wall Street Journal susține acest lucru în artico-lul ‘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

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 crea-tivi 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 impor-tante 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.

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 anali-zează cu atenție pașii mărunți care au dus spre succes.

New business development analysis

startups



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 supli-mentare. Cu toate acestea, e vitală existența unei liste cu toate posibilele funcții ale vii-torului 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 start-up-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 exem-plu, 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.

Toate obiectivele setate împreună compun un set de use case-uri care arată

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 dez-voltarea 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ă imple-mentarea 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 fami-liarizată cu user stor-urile. Aceste ‘povești’ fac legătura între stakeholder-i, use case-uri și părți din use case-uri. Acest mod de a transmite cerințele pentru noul sistem este foarte răspândit pentru că ajută mult 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 trans-mite 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 Bittner3.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 [email protected]

Project Manager@ Ogradamea

http://blogs.wsj.com/accelerators/2012/11/29/embrace-the-executive-summary/

http://blogs.wsj.com/accelerators/2012/11/29/embrace-the-executive-summary/


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 busi-ness 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 valoa-rea adaugată, pe care o poate oferi prin intermediul acestora.

Deși conceptul a început să fie pro-movat destul de recent ca atare în lumea business, mai explicit, în mediul startup-urilor, cum se întamplă în Statele Unite, în Europa si chiar în Cluj în ultimii ani, el reflectă o realitate străveche. Din toate tim-purile conducătorii de popoare migratoare au fost nevoiţi să își asume teritoriile cuce-rite, prin scurte cuvântări proclamatoare. În fond, chiar simplul gest de a vorbi exclu-siv 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ădui-torii 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 asoci-ere, 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

unui aperitiv. Un aperitiv pentru comuni-care: “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 conver-saţ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 pitch-ului 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 întregu-lui 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 pro-gramare de șapte ani, fie pasionat de cărți medievale, oricare din acestea în concor-danţă cu aria ta de activitate și proiectul promovat aici de tine, tu îi determini pe cei

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 prin-cipală 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

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?

management


TODAY SOFTWARE MAGAZINEprogramare

pitch-ul? Invit la acțiune.

Mai departe, în a treia secţiune a scur-tului 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 inal , recomand 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ţi-onezi 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, pro-gramare 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 persuasiu-nii în vorbitul în public, pe care îl puteţi

exersa într-un mediu prietenos și temei-nic într-un club Toastmasters, se numără folosirea de cuvinte-cheie, cum sunt ver-bele, 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 aseme-nea 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 pro-movează cel mai bine. Apoi, nu-ți rămâne decât să cauţi oportunităţi de promovare, evenimente de networking, târguri de job-uri, 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 fie-care 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 dife-rite, 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 evo-luţ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 inves-titori, 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 Week-end 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.

Bibliografiehttp://www.elevatorpitchexamples.com/www.businessweek.comhttp://mindyourpitch.com/www.forbes.com

Ana-Loredana [email protected]

Training Manager@ Genpact

http://www.elevatorpitchexamples.com/

http://www.businessweek.com

http://mindyourpitch.com/

http://www.forbes.com


diverse

- 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ăs-puns 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 uni-formă... Recapitulă lista copilului: pompier, medic, polițist. Ei, cum să concurezi cu ei? E clar că au ce povesti, întâmplări extraordi-nare, 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ăp-tă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.

Îș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 vor-bească 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?!

Gogu şi velierul

Simona Bonghez, [email protected]

Speaker, trainer şi consultant în managementul proiectelor,

Owner al Colors in Projects

powered by

sponsori

Today Software Magazine N20/2014

Documents

Transcript of Today Software Magazine N20/2014