TSM_13_2013_ro by Today Software Magazine

No. 13 • Iulie 2013 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

set d n i ct M

Prod

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

e 20 p o r u ing E

pr ICT S

ll (II e k s Ha

HTML 5: WebSockets Agile Summer Camp Cluj-Napoca

Fresh de portocale Hadoop (III)

Migrare website MVC 3 și DB în Azure

Recenzia cărții: Java Message Service

Prețul mare al lean software development

România, rățușca cea urâtă din lacul software outsourcing

Adoptia tehnicilor software craftsmanship: coaching tehnic Interviu cu Peter Lawrey

SPRE COMUNITATEA IT – via HR (II) Team building (I)

6 ICT SPRING EUROPE 2013 Ovidiu Mățan

9 I T.A.K.E. UNCONFERENCE Ana Maria Constantinescu

28 SPRE COMUNITATEA IT via HR (II) Dan Ionescu și Cristina Nicule

33 Interviu cu Peter Lawrey Attila-Mihaly Balazs

10 3 luni de Springboard

34 Prețul mare al lean software development

Bogdan Iordache

Florian Ivan

12 Agile Summer Camp Diana Tîrnovan

15 Product Mindset Dan Suciu

18 Din uneltele artizanului software: Coaching tehnic Alexandru Bolboaca și Adrian Bolboacă

20 Recenzia cărții: Java Message Service Silviu Dumitrescu

35 România, rățușca cea urâtă din lacul software outsourcing Mihai Nadăș

37 Migrare website MVC 3 și DB în Azure (II) Dragoș Andronic

39 Hadoop (III) Radu Vunvulea

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

22 HTML5: Web Sockets

44 Fresh de portocale

Radu Olaru

Antonia Onaca

22 Team building (I) Andreea Pârvu

46 E vreme de concedii .... Simona Bonghez

editorial

Ovidiu Măţan, PMP

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

articiparea TSM la ICT Spring Europe 2013, eveniment desfășurat luna trecută în Luxemburg, a reprezentat o experiență inedită. Au fost 3300 de participanți din Europa, America și Asia. Printre principalii invitați s-au numărat Jimmy Walles, fondatorul Wikipedia, care a povestit despre ce înseamnă puterea informației atunci când avem de-a face cu o bibliotecă globală de cunoștiințe: Wikipedia. Trip Hawkins, fondatorul Electronic Arts, a prezentat puterea jocurilor în societatea noastră, mutarea acestora pe dispozitivele mobile, anticipând o posibilă evoluție a educației unde tinerii nu mai acceptă rolul unui ascultător pasiv în clasă. Am avut parte de două zile pline de prezentări în sala de conferințe. Un colț special a fost dedicat startup-urilor unde am avut parte doar de pitch-uri. De asemenea a fost creat și un colț al experților. Networking-ul a fost cuvântul cheie, încurajat prin marea prezență a standurilor tehnice și a evenimentelor dedicate precum Networking Cocktail. Vă invit să citiți mai multe detalii în primul articol dedicat ICT Spring. Numărul 13 este o ediție cu o ușoară briză de vacanță. În acest sens publicăm articolul Andreei Pârvu despre organizarea de team building-uri, cel al Simonei Bonghez E vreme de concedii .... și Fresh de portocale semnat de Antonia Onaca. Ne face plăcere să publicăm a doua parte a studiului realizat de compania Danis despre mediul de IT din Cluj ce are ca țintă crearea unor best practice-uri de HR în acest domeniu. Totodată avem un interviu interesant cu Peter Lawrey, realizat de Attila Balazs, despre realizarea de aplicații cu un grad înalt de concurență și performanță în Java folosite în special în domeniul bancar și bursier. Revenind la evenimente, felicit Yonder pentru inițiativa de a organiza un eveniment la cinematograful Victoria din Cluj-Napoca precum și pentru proiecția în cadrul acestuia a unui episod din Războiului Stelelor. A fost un eveniment local inedit în care a fost împărtășită viziunea lor asupra evoluției pieței de software. Puteți puteți să o cunoașteți și voi în articolul lui Mihai Nadăș. Tot în secțiunea de evenimente avem un review al I T.A.K.E Unconference, organizat de Mozaic Works în București. Pentru cei ce sunt în Cluj în perioada 18-19 iulie, Florian Ivan va ține un workshop Agile de două zile. Mai multe detalii puteți găsi în articolul dedicat acestuia. Seria de articole tehnice a ajuns la numărul trei pentru Programare Funcțională în Haskell și Hadoop. HTML 5: Web Socket ne arată o soluția practică de comunicare client server disponibilă în HTML 5. Product Mindset semnat de Dan Suciu ne arată stategia orientării pe produs față de orientarea spre servicii în domeniul de outsourcing. Vă dorim o lectură plăcută !!!

Ovidiu Măţan

Fondator și CEO al Today Software Magazine

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Lista autorilor Redacţia Today Software Magazine Fondator / Editor în chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com Editor (startups și interviuri): Marius Mornea marius.mornea@todaysoftmag.com Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com Copyright/Corector: Emilia Toma emilia.toma@todaysoftmag.com Traducător: Roxana Elena roxana.elena@todaysoftmag.com Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com Produs de

Alexandru Bolboaca

Dan Suciu

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

Director of Delivery @ 3Pillar Global

Ana Maria Constantinescu

Mihai Maruseac

Community Manager @ Akcees

IxNovation @ IXIA membru ROSEdu, ARIA

Silviu Dumitrescu silviu.dumitrescu@msg-systems. com

Radu Vunvulea

alex.bolboaca@mozaicworks.com

anamaria@akcees.com

Consultant Java @ .msg systems Romania Mihai Nadăș mihai.nadas@tss-yonder.com CTO @ Yonder

dan.suciu@3pillarglobal.com

mihai.maruseac@gmail.com

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

Adrian Bolboaca

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

Bogdan Iordache bogdan.iordache@howtoweb.co este Co-Fondator al How to Web, cel mai important eveniment web din Europa de Est

Today Software Solutions SRL

Radu Olaru

rolaru@smallfootprint.com Senior Software Developer @ Small Footprint

Diana Tîrnovan

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

Diana.tirnovan@tech-league.net

Cristina Nicule

cristina.nicule@danis.ro

Coordinator @ TechLeague

Consultant @ Danis Consulting

Attila-Mihaly Balazs

Andreea Pârvu

Code Wrangler @ Udacity Trainer @ Tora Trading

Recruiter în cadrul Endava

Dan Ionescu

Florian Ivan, PMI-ACP, CSM, PMP, Prince2 Practitioner, MVP, MCTS

dify.ltd@gmail.com

dan.ionescu@danis.ro

andreea.parvu@endava.com

florian.ivan@rolf-consulting.com Director Executiv @ Danis Consulting

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

Managing Partner @Rolf Consulting Germany

Simona Bonghez, Ph.D.

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

Antonia Onaca

anto@aha-ha.com de aproape 10 ani trainer, psiholog, consultant sub formă de antreprenor, intraprenor şi antreprenor din nou

Owner al Colors in Projects

Dragoș Andronic

www.todaysoftmag.ro www.todaysoftmag.com

dragos@txtfeedback.net CTO @ TXTFeedback

www.todaysoftmag.ro | nr. 13/Iulie, 2013

evenimente

ICT SPRING EUROPE 2013

rima delegație TSM în afara țării s-a realizat prin participarea la evenimentul ICT SPRING EUROPE 2013. Un eveniment ce a avut loc în Luxemburg pe durata a două zile. Am avut parte de un public numeros iar în calitate de parteneri am avut ocazia să distribuim revista în cadrul evenimentului. Vedetele evenimentului au fost Jimmy Walles, fondatorul Wikipedia și Trip Hawkins, fondatorul Electronic Arts.

Să începem povestea evenimentului. Din Cluj, Luxemburgul nu este foarte departe, un zbor până în Charloi (Belgia), iar de aici un shuttle direct către destinația noastră finală. Luxemburg-ul are în jur de 500.000 locuitori rezidenți, iar orașul în sine are aproximativ 300.000 locuitori. O mare parte a celor ce lucrează aici vin din țările vecine: Franța, Germania sau Belgia. Tradițional, economia țării se bazează pe sectorul bancar, având ca și atu secretul bancar. Acest drept va fi pierdut însă în 2014, dar focusul actual vizează zona IT, în special comunicațiile, data center-urile precum și dezvoltarea de software bancar. Acest lucru fiind realizat printro bună implicare a politicului în susținerea business-ului local, în promovarea acestuia și acordarea de facilități. Remarcăm posibilitatea deduceri a 80% din costurile IP (Intellectual Property) din impozit sau suportul a până la 50% a cheltuielilor realizate prin participarea companiilor la evenimente externe. Luând în considerare toate acestea, nu este de mirare faptul că avem aici cel mai ridicat nivel al venitului pe cap de locuitor din Europa.

Revenind la ICT Spring, evenimentul a fost organizat în patru arii: 1. Standurile expozanților care au cuprins produse tehnice, startup-uri și organizații, 2. Sala de conferință unde s-au desfășurat keynotes-urile, 3. Colțul startup-urilor, unde de-a lungul celor două zile am avut parte de pitch-urile startup-urilor, 4. Colțul experților unde au avut loc o serie de prezentări mai tehnice abordând domenii restrânse. Prezentările au fost interesante, axându-se pe inovație. Oliver Royant, editor chief la Paris Match. A explicat importanța mesajului în media, pasiunea reporterilor pentru meseria lor și importanța acesteia în viața noastră. Fiecare platformă media: print, web, mobile are nevoie de experiență și conținut specific. Peter Sondergaard - Senior Vice President Research, Gartner. Selectăm câteva dintre opiniile exprimate: • În următorii ani, toate bugetele vor fi doar bugete de IT. • Enterprise este reprezentat de Facebook deoarece ei dețin controlul datelor, nu corporațiile.

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE • Paradoxal, tehnologia va scădea vânzările de mașini, deoarece tot mai multă lume va prefera mediul virtual contactului direct. • Recesiunea rămâne o problemă, dar tehnologia nu este încetinită. Tot mai multe business leaderi se orientează spre digital. Conform graficului Gartner, doar 2% din cei 391 CEO și Senior Business Executives au o strategie digitală ca strategie de business. 49% însă o au pe aceasta în plan, iar 14% nu o consideră deloc. • În vreme ce pozițiile tradiționale de CEO sau de director IT rămân la același nivel sau scad, rolul inovației crește, iar poziția de Head of Innovation devine tot mai importantă. • Datele și clienții reprezintă investițiile cheie în IT, dar leaderii de vânzări și marketing nu vor mai avea controlul absolut. • În topul priorităților investițiilor se află pe primele trei poziții: business analytics, enterprise mobility, business process outsourcing.

împărtășit din experiența sa, acumulată în ultima campanie prezidențială și a prezentat câteva din acțiunile întreprinse pentru creșterea impactului mesajelor prezentate pe site. Pentru creșterea impactului unei aplicații sau a unei pagini web reduceți numărul de optiuni: less is more. Printre exemplele date a fost pagina de vânzări online Sim City unde prin renunțarea la un banner online au fost crescute vânzările cu 43.8%. În timpul campaniei pentru alegerile prezidențiale donațiile au fost mărite cu 15.2% prin schimbarea textului din „Donate now” în “Donate and get a gift” pentru cei ce nu s-au mai înregistrat pe site. În schimb același opțiune a redus donațiile cu 24.6% pentru cei înregistrați și care nu au mai donat. Pentru aceștia, cea mai bună alegere a fost Please donate, care a crescut donațiile cu 27.8%. Lecția învățată: explorează pentru a găsi cea mai bună opțiune în loc să rafinezi soluția existentă (http://insideintercom. io/criticism-and-two-way-streets/). Încheierea discursului ne-a oferit o recapitulare a regulilor expuse: 1. Definiți metrici de succes ce pot fi măsurate. 2. Mai puțin este mai mult. Reduceți opțiunile. 3. Cuvintele contează. Concentrează-te pe acțiune. Nexus of forces – reprezintă modul în care vor interacționa 4. Încearcă să atingi maximul global. oamenii între ei în viitor și cu informațiile lor. Alegerea va fi făcută 5. Pornește azi. în patru planuri: mobile, social, Cloud și informație. Finalul prezentării a fost inedit prin adresarea următorului îndemn: start a Bart Vercammen - Director Product Managent, Technicolor, marketing program digitization. May the IT force be with you !!! ne-a povestit despre device-urile si aplicațiile interconectate: În continuare am asistat la prezentarea startup-ului Kidoria, Services of Things. Termenul Technicolor este sinonim cu modacare au construit o aplicație ce permite adăugarea tuturor datelor litatea specială de procesare a filmelor color dar compania este despre copii, începând cu pozele acestora și continuând cu datele și leader în producția de home gatemedicale sau notele luate la școală. way. Principalele provocări dintr-un Aplicația se bazează pe un abonament connected home din zilele noastre sunt lunar și există posibilitatea de a crea multitudinea de protocoale folosite de albume de fotografii cu pozele stocate. diferite device-uri, numărul device-uriPână acum au opținut o finanțare de lor, App’ification of the connected home. 180.000 de euro, majoritatea sumei fiind Controlul acestora reprezintă o provofolosită pentru dezvoltarea aplicației și care, iar soluția propusă de Technicolor anume salariile programatorilor. este: Qeo1. Acesta este un framework de comunicare bazat pe o Dan Siroker – Co-founder & CEO al Optimizely – fost director arhitectură Publish-Subscriber care folosește resurse hardware pentru analytics în campania prezidențială a lui Barack Obama. Ne-a limitate, având modele de date extensibile și tranferul de date criptat. Acesta este open-source și se poate descărca gratuit. În paralel a fost creat standardul Qeopedia pentru interconectarea diferitelor ecosisteme. Prima zi a evenimentului s-a încheiat la 17:30 după care a avut loc evenimentul special de socializare: Networking Cocktail unde i-am întâlnit pe Oana Casapu și Alexandru Rotaru, de la Altom Consulting. A fost o surpriză să ne cunoaștem acolo, TSM nu a trecut neobservat prin numărul mare de tweet-uri postate ce erau afișate în sala de conferință și în zona de expoziție, realizând astfel conectarea. De asemenea, au folosit codul de participare pus la 1 http://www.i-speak-qeo.com/

www.todaysoftmag.ro | nr. 13/Iulie, 2013

startups dispoziție în ultimul număr și în comunitatea Facebook TSM. Am continuat cu cina oficială, European ICT Awards Gala Dinner, eveniment deschis de către Xavier Bettel, primarul orașului Luxemburg. În cadrul acesteia, au fost aunțați câștigătorii premiilor European ICT din acest an au fost. Aceste premii fiind o recompensă a bunelor practici ICT.

European CIO of the Year

Lance Fisher, CIO al companiei SThree, companie specializată în resurse umane din Londra. Premiul a fost acordat ca rezultat al strategiei globale și al proiectelor implementate, alegerile tehnice și cunoștințele de management ale acestuia.

European ICT Innovation of the Year

Applidget, o companie de web development din Paris specializată în soluții software pentru organizarea evenimentelor. Premiul a fost acordat pentru produsele inovative și contribuția adusă în acest domeniu.

European Startup of the Year

Premiul a fost câștigat de Uplike, o aplicație care transformă bookmark-urile în lucruri „reale” prin posibilitatea de a da share dintr-un simplu click. În următorul număr vom relata a doua zi a evenimentului când și-au făcut apariția vedetele Jimmy Walles, fondatorul Wikipedia și Trip Hawkins, fondatorul Electronic Arts.

Ovidiu Măţan, PMP

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

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

evenimente

TODAY SOFTWARE MAGAZINE

I T.A.K.E. UNCONFERENCE mai mult decât o conferință

onferința I T.A.K.E. UNCONFERENCE a avut loc in București pe 30-31 Mai și a fost mult mai mult decât o conferință. Partea de speaking a vizat discuțiile despre cod sau tehnici pentru programatori, testeri, arhitecți, manageri tehnici. Pe parcursul celor două zile s-au întâmplat multe lucruri interesante.

Au fost organizate workshopuri în timpul cărora participanții au fost puși să scrie cod și au avut de învățat foarte multe datorită nivelului ridicat de interacțiune cu membrii grupului. Temele abordate au fost: Agile Architecture Techniques and Values, TDD, DDD și BDD. Pe lângă asta, a fost partea de Open Space în care participanții au propus un topic, și-au ales ora și împreuna cu cei interesați au purtat discuții informale. S-au dezbătut subiecte precum: „Cum încep să scriu Unit Test?”, „Cum păstrez controlul când fac Refactoring?”, „Probleme cu baze de date

si soluții”, etc. Mai mult decât atât, la I T.A.K.E. UNCONFERENCE am văzut ce presupune o poziție de Product Owner și care sunt responsabilitățile lui. În partea de Product Management, atât participanții cât și speakerii s-au alăturat echipei pentru a contribui la dezvoltarea unei aplicații web numită KeepInTouch care să le permită participanților să păstreze legătura și după conferință. Product Owner-ul, Flavius Ștef, a pregătit un backlog inițial de la care s-a pornit și a ghidat prioritizările pașilor de dezvoltare a aplicației pe parcursul celor două zile. Participanții au practicat tehnici de Agile Software Development, au iterat la fiecare oră, au folosit pair programming,

unit testing și TDD. Rezultatul? O aplicație complet funcțională conform planului! Speaking, Open Space, Workshops, Product Development și asta nu e tot. Pentru că un programator trebuie să lucreze să își îmbunătățească abilitățile de a scrie cod, organizatorii I T.A.K.E. UNCONFERENCE au pregătit un Kata Lounge, o zonă în care o urnă cu provocări îi aștepta pe programatori să le rezolve. Fiecare participant care a rezolvat una dintre problemele denumite katas a primit feedback din partea un speaker. Câștigătorii la secțiunea cel mai curat cod scris au fost Cătălin Lazăr care a câștigat participarea la un workshop în cadrul firmei Mozaic Works și trei luni de abonament la revista Today Software Magazine și Eduard Stănculeț care va primi la fel un abonament pe trei luni la revista Today Software Magazine. Conferința a debutat cu Rebecca WirfsBrock, președinte Wirfs-Brock Associates și cronicar de design ( Eng. Design Columnist) la IEEE Software, foarte cunoscută și respectată pentru activitatea sa de object-oriented practician. Ea a inventat modul de a gândi despre obiecte cunoscut sub numele Responsability-Driven Design și este autoarea cărților: Object Design: Roles, Responsabilities, and Collaborations (2003) și Designing Object-oriented Software (1990). În pre zent are a ț inut ă p e tema menținerii codului în stil Clint Eastwood ( Eng. Maintaining your code Clint Estwood Style) a vorbit despre cum să te descurci cu cod bun, prost sau urât ( Eng. Good, bad or ugly code) scris de tine sau de altcineva. Când vorbește despre cod bun, Rebecca sfătuiește să se scrie cod cât mai simplu în ciuda complexității sale, ținându-se însă minte că în viitor codul respectiv va crește în complexitate pentru că va rezolva mai mult decât rezolvă astăzi. Mai mult, pleacă de la ideea susținută de Clint Eastwood și anume că în general, successul în viață se datorează în mare parte instinctului combinat cu puțin noroc.

( Eng. „Whatever success I’ve had is due to a lot of instict and a little luck”). Părerea ei in schimb este că tot ce a realizat până acum se datorează în mare parte faptului că a muncit mult și a avut puțin noroc. („ Whatever success I’ve had is through a lot of hard work and a little luck.”) Agile Coach, Vasco Duarte a ținut un workshop despre TDD. Vasco are experiență de Manager de Proiect si Produs si lucrează în industria software-ului din 1997. Lucrează pentru Avira unde este un leader și catalyst în metode Agile și a lucrat anterior pentru Nokia și F-Secure. Spune că TDD este o investiție în a deveni programatori mai buni. Printre problemele pe care le remarcă în ceea ce privește TDD-ul, menționează că este greu ca programator să detectezi repetiția și de obicei există

tendința de a complica soluțiile. De aceea recomandă să se scrie cod cât mai ușor de citit și să se facă cât mai mult Refactoring. Aimee Rivers, cu o experiență de ani de zile în programare web și behaviour driven development, a ajutat cu testarea pentru Video Player-ul interactiv al BBC-ului pentru Jocurile Olimpice.La urmatoarea adresă http://aimeerivers.com/weather/berlin puteți vedea afișată vremea din Berlin pe pagina web, și desigur poate fi introdus orice alt oraș. În mare parte conferința a pus accent pe Clean Code, Architecture, Design, Unit testing, TDD, Functional programming, Domain Driven Design, Legacy Code, Productivity, Testing. Ana Maria Constantinescu anamaria@akcees.com Community Manager @ Akcees

www.todaysoftmag.ro | nr. 13/Iulie, 2013

startups

3 luni de Springboard

n decembrie 2012 am acceptat o provocare foarte interesantă: să fiu program manager al Springboard, unul dintre cele mai bune (fără modestie, știu, dar asta e) programe europene de accelerare. Ediția din 2013 avea și un element de noutate absolută: era primul program european dedicat startupurilor hardware, o mișcare foarte interesantă care urma unui 2012 plin de noutăți pentu dezvoltatorii de hardware. Cele 3 luni au trecut cu mare viteză, iar volumul de muncă a fost uneori copleșitor. Să conduci programul de la Springboard, în timp ce mai dai câte o mână de ajutor la lansarea TechHub București, în timp ce îți ajuți colegii de la Conectoo și începi să organizezi How to Web 2013 este definiția unui program încărcat. Ăsta e și motivul pentru care nu am mai avut timp sa scriu pe blog, sper să recuperez în perioada următoare. După 3 luni petrecute în Cambridge pot spune ca a fost una dintre cele mai interesante experiențe profesionale pe care le-am trăit în ultimii ani. Am avut ocazia să lucrez alături de Jon și Jess, cei care au fondat/condus/dezvoltat acceleratorul Springboard în ultimii 3 ani, dar și alături de 8 echipe fantastice, strânse din toate colțurile lumii (UK, Spania, Portugalia, Canada, Bulgaria). Nota de subsol: echipa Springboard va conduce de anul acesta TechStars Londra, prima extindere în afara US a celei mai importante rețele de programe de accelerare și o dezvoltare extraordinar de importantă pentru ecosistemul european, care capătă o poartă deschisă spre piața din US. Cambridge este unul dintre punctele cheie ale hardware-ului european (dacă nu chiar punctul cheie), un oraș cu 100.000 locuitori în care au apărut firme precum ARM (producătorii procesoarelor din mai toate smarthphone-urile și tabletele din lume, cu o producție de 9 miliarde de procesoare anul trecut), Raspberry PI, Acorn Computers (pentru pasionații de istorie), dar și mai noile Neul și Weightless. Am acceptat propunerea lui Jon (primul meu job propriu zis de la 21 de ani

încoace) pentru că eram interesat să înțeleg cum este organizat un program de accelerare și care sunt elementele cheie care fac un astfel de program de success. În afara multor considerente practice (între care, cea mai importantă este că un program de accelerare trebuie condus de catre antreprenori și/sau investitori), îmi este acum evident ca cele mai importante ingrediente sunt calitatea echipelor și a mentorilor, sau mai pretențios spus contextul pe care îl creezi în jurul programului. În momentul în care ai printre mentori personalități precum Hermann Hauser, David Cleevely, Eben Upton sau Peter Cowley, alături de reprezentanți ai (fără exagerare) zeci de fonduri/grupuri de investiții de primă mână, precum și corporații precum Unilever (venituri de 51.32 mld EUR în 2012) sau Bosch (venituri de 52.3 mld EUR în 2012) și care își fac directorii de top disponibili pentru întâlniri și prezentari cu echipele, combinat cu o arie de selecție globală, ei bine, rău nu are cum să-ți fie. Toate aceste interacțiuni îți construiesc un context care te poate ajută din multiple puncte de vedere: vei primi feedback valid pentru toate variantele de dezvoltare pe care le analizezi, vei afla o tonă de informații interesante și relevante pentru ceea ce faci și îți poți cunoaște, în cazul ideal, viitori investitori și parteneri. Însă nimic nu este mai concret decât tensiunea fantastica ce plutește în aer atunci când discuțiile se întețesc și dezbaterea te provoacă să găsești soluții și alternative alături de oameni excelent pregătiți profesional, pentru că acelea sunt momentele în care, precum un atlet ce aleargă în compania unor atleți mai buni, te

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

autodepășești profesional. Simt că, după doar 3 luni acolo, am nevoie de încă 3 luni în care să înțeleg pe deplin experiența prin care am trecut. Și pe care, într-o formă sau alta, v-o doresc și vouă.

Cum arată un program de accelerare pentru startups din interior

În cele două săptămâni de când m-am întors în România primesc insistent, aproape la fiecare discuție, întrebări precum “Ce este mai exact Springboard?”, “Ce anume ai făcut acolo?”. Mă scuzați, revin cu completări suplimentare. Springboard este (a fost?) unul dintre cele mai importante acceleratoare europene, plasat cu siguranță în top 3, alături de (my 2 cents) Seedcamp și Startupbootcamp. Programul din primavara/vara lui 2013 a fost dedicat startupurilor din domeniul “Internet of Things”, și a reprezentat ultimul batch al Springboard din viitorul apropiat. În februarie Springboard a anunțat fuziunea cu TechStars, iar echipa Springboard va gestiona începând din această lună programul de accelerare TechStars Londra (fuziunea Springboard – TechStars este o reușită extraordinară, ce aduce cea mai bună rețea de acceleratoare în Europa). Brandul Springboard este deocamdată pus la păstrare. Suprapunerea celor două programe (TechStars Londra a început să fie pregătit intens din mai) a făcut ca echipa Springboard (Jon & Jess) să aibă nevoie de o mână de ajutor. Asta a fost, foarte pe scurt, felul în care am ajuns să lucrez pentru Springboard ca program manager timp de 3 luni, dornic să văd cum arată un program

TODAY SOFTWARE startups MAGAZINE

de accelerare din interior (și nu din perspectiva unui startup). Springboard IoT a avut structura clasică a unui accelerator mentor-driven: 3 luni de program, în care în prima jumătate echipele întâlnesc peste 80 de mentori, iar în a doua jumătate echipele își pun ordine în informațiile primite, iau decizii strategice privind piața țintă, clientul tipic și strategia de dezvoltare și itereaza produsele în direcția dorită. Deși titlul de program manager suna oarecum pretențios, Jon Bradford, fondatorul Springboard (și un irlandez dintr-o bucată) și un vechi amic (primul tricou oficial al Springboard a apărut în How to Web 2010) m-a trecut prin toate taskurile posibile pe care cineva le face într-un accelerator. Așadar, ce face un program manager? Ei bine, întâi de toate multă muncă logistica: • Organizarea și gestionarea întâlnirilor cu mentori, ce sunt de o suprinzătoare complexitate datorită numărului mare al acestora (peste 80 în cazul Springboard) • Organizarea workshopurilor ce au avut teme diverse, de la business modeling, probleme legale, marketing, financing, la crearea campaniilor pe Kickstarter • Organizarea întâlnirilor de pitching care pregătesc echipele pentru Demo Day • Organizarea Demo Day, evenimentul de final al programului, când startupurile își prezintă progresul în fața investitorilor, a presei etc. Partea mea favorită a fost însă lucrul individual cu echipele: • Sesiunea (aproape) săptămânală de Office Hours, în care discutam individual cu fiecare echipă despre problemele strategice pe care le întâmpinau • Show & Tell, întâlnirea săptămânală în care echipele își prezentau progresul din ultima săptămână și provocările săptămânii următoare • (un pic de) Analiza competitivă, analiză a investitorilor strategici dintr-o anumită verticală etc. Pentru că rolul nostru nu era cel de a da sfaturi (decât dacă ne erau cerute în mod explicit), ci de acela de a facilita procesul prin care treceau startupurile, dezbaterile rezultate erau uneori de un rafinament spectaculos. Rolul de facilitator a fost o experiență nouă și extrem de utilă, care m-a ajutat sa înțeleg mult mai bine procesele de decizie. Un program de accelerare de calitate are cu siguranță impact asupra echipelor ce îl urmează, dar calitatea lui depinde în foarte mare măsură de mentorii și echipele implicate. În egală măsură, este extrem de ușor ca programul să fie replicat ca structură, dar să nu aiba nici un fel de consistență din punct de vedere al rezultatelor. Uitați-vă cu grija cu cine urmează să vă întâlniți când alegeți acceleratorul la care aplicați! Bogdan Iordache bogdan.iordache@howtoweb.co este Co-Fondator al How to Web, cel mai important eveniment web din Europa de Est

www.todaysoftmag.ro | nr. 13/Iulie, 2013

evenimente

Agile Summer Camp Cluj-Napoca

lorian Ivan – CSM, PMI-AC, PMP, Prince2Practitioner și MVP Microsoft - vă provoacă la două zile cu și despre cele mai faimoase practici Agile din lume, un training care promite să puteți deveni cu adevărat Agile. Devenit un must pentru profesioniștii din software, Agile este o unealtă indispensabilă pentru a livra software de calitate. Indiferent dacă proiectele se referă la dezvoltarea de produse, soluții software sau la outsourcing, Agile este unanim recunoscută ca o soluție care permite livrarea la timp și la o calitate ridicată, păstrând constrângerile de cost. Diana Tîrnovan

Diana.tirnovan@tech-league.net Coordinator @ TechLeague

Agile Summer Camp este incursiunea în metodologii Agile precum Scrum, XP, Kanban, Lean, FDD, Crystal, DSDM), ce-și propune să contribuie la: • Crearea şi creşterea motivaţiei echipei; • Dezvoltarea unei relaţii apropiate cu clientul; • Creşterea productivităţii; • Creşterea gradului de organizare personală; • Încheierea proiectelor la timp şi în bugetul stabilit. Experiența de peste 15 ani în industria software a lui Florian Ivan face ca acest eveniment să fie o adevărată experiență. Nu doar teorie și frameworks, ci și relatări ale unor experiențe reale de viață. Vezi Agile în acțiune prin diferite scenarii atât pentru start-up-uri cât și pentru corporații mari. Totul cât se poate de real, cuprinzând tematici ca: • Introducere în metodologiile și standardele Agile; • Metodologiile principale Agile: Scrum, XP, Kanban, Lean, FDD, Crystal, DSDM; • E c h ip el e d e l i v r are : ro lu r i , responsabilități, comunicare și management, leadership, unelte și practici,

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

schimb de informații în proiectele Agile • Începerea proiectului: managementul de proiect și portofoliu, indicatori cheie, viziune și organizare; • Backlog management: tehnici de colectare a specificațiilor, planificare, organizare și prioritizare, reprioritizare și ajustare, management al schimbărilor, user story; • Release, iterații: conceptele Agile de planificare, tehnici de estimare, Story points și alți indicatori de estimare; • În interiorul și în jurul iterațiilor : înainte de iterații, ședințe zilnice, recenzii și retrospective. Un obiectiv al cursului este să înţelegem şi să utilizăm corect practicile și uneltele Agile. Un asemenea caz este estimarea în puncte a story-urilor. Vom discuta astfel de ce un măr are mai multe puncte decât o cireaşă şi de ce drumul până la Bucureşti mai multe decât cel până la Sibiu. Şi, bineînţeles, vom încerca să înţelegem task management dintr-o perspectivă nouă şi anume cea de mărimi relative şi nu absolute cu care am fost obişnuiţi până acum. Florian Ivan aduce o viziune unică asupra managementului de proiecte prin convingerea că printr-o educație profundă,

TODAY SOFTWARE MAGAZINE experiența pragmatică și atitudinea corectă cu toții putem obține rezultate foarte bune. În prezent managing partner al Rolf Consulting- companie specializată în servicii de consultanţă şi training, cu focus asupra metodelor Agile, Florian a acumulat o vastă experiență, ca Partner Program Manager și implicarea în programe de start-up specializate în business intelligence și de gestionare a datelor. Agile Summer Camp se desfășoară în 1-2 Iulie la București și 18-19 iulie la Cluj-Napoca. Evenimentul clujean este sponsorizat de Accesa și organizat de TechLeague - divizia profesioniștilor din domeniul IT creată din pasiunea pentru tehnologie. Înglobând în egală măsură evenimente de tip: prezentări, trainings, workshop-uri - dedicate tehnologiilor Microsoft îndeosebi - și prezentat pentru prima oară publicului clujean prin evenimentul Agile Summer Camp, TechLeague își propune să devină contextul ideal prin care pasiunea

pentru tehnologie te provoacă să descoperi, cunoști și împărtășesti metodele de excelență tehnică. Agile Summer Camp este un eveniment cu numărul de locuri limitate, de aceea aşteptăm, cu mare interes, cât mai curând, înscrierile voastre la adresele: • florian@rolf-consulting.com • diana.tirnovan@tech-league.net Pentru detalii suplimentare accesaţi: http://www.rolf-consulting.com/ http://www.tech-league.net/

www.todaysoftmag.ro | nr. 13/Iulie, 2013

comunități

Comunităţi IT

una iulie înseamnă luna în care mulți dintre noi pleacă în concediu, iar aceasta se reflectă asupra numărului de evenimente. Considerând numărul de cititori din toată țara, am decis ca începând cu acest număr pagina dedicată comunităților să o transformăm într-una națională.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java. Website: http://www.transylvania-jug.org/ Data înfiinţării: 15.05.2008 / Nr. Membri: 545 / Nr. Evenimente: 43 Comunitatea TSM Comunitate construită în jurul revistei Today Software Magazine. Website: www.facebook.com/todaysoftmag Data înfiinţării: 06.02.2012 / Nr. Membri: 708 / Nr. Evenimente: 10 Romanian Testing Community Comunitate dedicata testerilor. Website: http://www.romaniatesting.ro Data înfiinţării: 10.05.2011 / Nr. Membri: 614 / Nr. Evenimente: 2 GeekMeet Cluj Comunitate dedicată tehnologiilor web. Website: http://geekmeet.ro/ Data înfiinţării: 10.06.2006 / Nr. Membri: 547 / Nr. Evenimente: 17

Calendar Iulie 3 Behavior Driven Development (Cluj) w w w . m e e t u p . c o m / Ta b a r a - d e - Te s t a r e - C l u j / events/120531312/ Iulie 4 Lansarea numărului 13 TSM (Cluj) www.todaysoftmag.ro Iulie 5 LEAN Start Up (Cluj) it-events.ro/events/lean-start-up-cluj-transform-youridea-into-a-sustainable-business/ Iulie 9 PyTim #2 (Timișoara) www.meetup.com/PyTim-Meetup/events/123419912/

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

Iulie 8-12 Introduction to memory management in C (București) it-events.ro/events/introduction-to-memory-managementin-c/

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

Iulie 8-13 Haskell from N00b to Real World Programmer (București) workshop.rosedu.org/2013/sesiuni/haskell

Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice. Website: http://www.meetup.com/Cluj-Semantic-WEB/ Data înfiinţării: 08.05.2010 / Nr. Membri: 143/ Nr. Evenimente: 22 Romanian Association for Better Software Comunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare. Website: http://www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 224/ Nr. Evenimente: 12 Tabăra de testare Un proiect care își dorește să strângă cât mai mulți oameni care lucrează ca și testeri. Website: http://tabaradetestare.ro Data înfiinţării: 15.01.2012 / Nr. Membri: 212/ Nr. Evenimente: 18

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

Iulie 8-30 Oracle Summer School 2nd Edition (București) it-events.ro/events/oracle-summer-school-2nd-edition/ Iulie 13 Firefox OS hackathon (Iași) it-events.ro/events/firefox-os-hackathon/ Iulie 18-19 Agile Summer Camp (Cluj) anis.ro/2013/07/02/agile-summer-camp-cluj-napoca-18-19iulie/ Joi/săptămânal OpenConnect (Cluj) www.facebook.com/groups/355893314491424/ Miercuri/bilunar OpenCoffee (Cluj) www.facebook.com/opencoffeecluj

management

TODAY SOFTWARE MAGAZINE

Product Mindset

otrivit specialiştilor în resurse umane, în România IT-ul este unul dintre puţinele domenii în care numărul de poziţii disponibile a crescut după izbucnirea crizei economice şi unul în care companiile se află în competiţie pentru cei mai buni specialişti.

Dan Suciu

dan.suciu@3pillarglobal.com Director of Delivery @ 3Pillar Global

Se aude tot mai pregnant ideea că, în competiţia cu costurile reduse ale salariaţilor din alte zone geografice (cum ar fi, de exemplu, Asia) soluţia este să se migreze de la outsourcing la produse proprii, sau, într-un poces mai puţin radical, să se petreacă o schimbare în ceea ce priveşte relaţia cu clienţii şi să se transforme statutul de simplu executant (aşa cum ar putea fi el indus de modelul outsourcing) într-un statut de consultant (ce ar transforma firmele IT în parteneri pentru clienţii lor). Product Mindset reprezintă o abordare modernă şi provocatoare având la bază ideea dezvoltării unui produs propriu aplicată întro cultură specifică furnizării de servicii IT prin păstrarea principalele avantaje ale celor două direcţii. Această abordare vine atât cu avantaje cât şi cu dezavantaje, iar articolul de faţă îşi propune să detalieze cele mai importante dintre ele.

Companii orientate pe Servicii (CoS) şi Companii orientate pe Produs (CoP)

Înainte de a oferi o imagine cât mai detaliată a ceea ce ar reprezenta product mindset pentru segmentul de outsourcing al industriei software, vom prezenta câteva definiții. Product mindset se referă la ideea de a extrage informaţii despre ceea ce îşi doresc clienţii de la un produs, fără ca aceştia să

precizeze direct sau foarte exact acest lucru, dezvoltând în final un rezultat care să le fie pe plac. În contrast, services mindset reprezintă ideea de a realiza foarte bine ceea ce doreşte şi specifică un client anume. Clienţii enunţă cerinţele, iar dacă aceste cerinţe nu sunt bine definite se adresează întrebări succesive cu scopul de a clarifica toate aspectele. Diferenţa majoră între cele două abordări constă în implicarea decisivă a celui care dezvoltă produsul în identificarea funcţionalitătilor si definirea formei sale finale. Dacă abordarea services mindset vede echipa de dezvoltare formată din simpli (dar foarte buni) executanţi, product mindset vede echipa de dezvoltare ca o echipă de consultanţi pentru dezvoltarea produsului, clientul şi echipa devenind astfel parteneri. Vom detalia în cele ce urmează câteva aspecte definitorii ale companiilor orientate pe servicii (CoS) în contrast cu cele ale companiilor orientate pe produse (CoP). Pentru fiecare dintre cele două abordări am enumerat acele aspecte care ni s-au părut relevante pentru subiectul prezentului articol. În cazul CoS se întâmplă deseori ca un proiect să dureze câteva luni după care membrii echipei de proiect să continue să lucreze (împreună sau nu) la proiecte total diferite, ce ţin de domenii diferite şi, de ce nu, cu tehnologii diferite (sau cu aceeaşi tehnologie

www.todaysoftmag.ro | nr. 13/Iulie, 2013

management Product Mindset dar cu framework-uri şi versiuni diferite). Aproximativ 50-60% dintre noii angajaţi vor învăţa şi vor face tranziţia către tehnologii noi încă de la început şi aproape toţi urmează să schimbe tehnologia pe durata angajamentului. Într-o proporţie foarte mare (90%) candidaţii pe poziţii deschise în CoS nu vor fi intervievaţi de echipa în care vor lucra. În contrast, candidaţii în CoP sunt intervievaţi mult mai atent pentru a se vedea dacă se potrivesc echipei în care vor lucra atât din punct de vedere tehnic cât şi din punct de vedere al personalităţii. În plus, pe perioada angajamentului vor schimba mult mai greu echipa şi tehnologia. CoP acordă în general o importanţă mare satisfacţiei angajaţilor şi consideră că plecarea unuia dintre angajaţii companiei constituie o pierdere importantă. Experienţa acumulată de-a lungul timpului în dezvoltarea produselor companiei face ca o anumită persoană să fie dificil de înlocuit. Pe de altă parte, în cazul CoS plecările angajaţilor sunt mai dese şi afectează rareori compania în mod semnificativ. Impactul scăzut asupra companiei se datorează faptului că în majoritatea CoS angajaţii dezvoltă rareori expertiză la nivelul unui produs, fiind suficiente doar cunoştinţele de programare pentru a-şi duce la bun sfârşit sarcinile. Pe de altă parte, frecvenţa acestor schimbări dese de loc de muncă se explică într-o oarecare măsură prin faptul că angajatul are ocazia să lucreze de-a lungul timpului cu proiecte diverse şi în echipe diferite în cadrul companiei ( tranziţia către o altă companie poată să pară un proces obişnuit ). Contextul tehnologic dinamic contribuie la

rândul său schimbarea mai facilă a angajatorului. În CoP există posibilitatea de a lucra o perioadă lungă de timp pe o tehnologie foarte particulară. În acest context, angajaţii sunt mult mai interesaţi să rămână şi să se specializeze în cadrul companiei. În companiile orientate pe servicii angajaţii sunt măsuraţi după cantitatea de muncă depusă, responsabilităţile asumate şi gradul de satisfacţie a clientului. Conexiunea dintre efort şi promovare sau remuneraţie este, în general mai clară. În cazul companiilor orientate pe produs efortul depus pentru a îndeplini obiectivele produsului este privit ca o activitate normală, de bază. Promovarea sau un salt mai consistent din punct de vedere salarial au loc atunci când se realizează activităţi ce nu sunt legate de activitatea normală de lucru, cum ar fi redactarea de articole sau întreţinerea unor bloguri de specialitate, susţinerea de prezentări tehnice la diverse evenimente, etc. . În consecinţă există un oarecare contrast şi în ceea ce priveşte denumirea poziţiei/seniorităţii ocupate de angajaţi. Trecerea de la programator junior la intermediar şi apoi la senior se face mai rapid şi cu mai mare uşurintă în CoS şi într-o relaţie directă cu vechimea. În CoP o persoană rămâne pe o poziţie de senioritate constantă o perioadă lungă de timp, iar numărul de ani petrecuţi într-un domeniu nu constituie un argument suficient de promovare, principalul argument fiind cel al expertizei pe domeniul pe care angajatul activează. Ca o paranteză trebuie spus că poziţia “câştigată” de o persoană într-o CoP rămâne continuă şi se solidifică în timp. În

CoS la fiecare nou proiect poziţia trebuie reconfirmată şi încrederea clientului în persoana care joacă un anumit rol trebuie recâştigată. Spre deosebire de proiectele noi în CoP unde o persoană intră împreună cu reputaţia sa câştigată pe proiectele precedente, în CoS lucrurile pornesc de la zero şi clientul trebuie convins de calitateaechipei ca şi cum nu ar exista nici un istoric relevant în spate. În altă ordine de idei, CoS câştigă contracte în faţa competitorilor asigurând o livrare mai rapidă la aceeaşi calitate (şi/sau costuri reduse). Aceasta se concretizează în multe cazuri printr-un efort susţinut al echipei şi finalul proiectului este sărbătorit de echipă. CoP livrează în foarte rare cazuri produsele la data planificată însă de multe ori sunt mai bogate în funcţionalităţi decât era planificat iniţial. Un alt paradox interesant este dat de faptul că în CoS proiectele sunt obţinute pe baza demonstrării profesionalismului angajaţilor şi a istoricului referinţelor. Totuşi, pentru majoritatea proiectelor nou obţinute se vor angaja oameni noi pentru echipa de proiect şi al căror profesionalism nu este încă demonstrat. Nu vom întâlni o companie orientată exclusiv pe produsele proprii încercând să obţină un certificat de maturitate. De ce ar avea nevoie de certificarea unei organizaţii externe când aceasta deja dezvoltă produse noi pe piaţă? Pe de altă parte o astfel de certificare asigură clienţii că produsele realizate de o CoS respectă anumite standarde de calitate. Financiar, CoS cresc liniar cu creşterea numărului de proiecte şi a numărului de angajaţi. Necesarul de capital însă este Our core competencies include:

Product Strategy

3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world. Our oﬀerings are business focused, they drive real, tangible value.

www.3pillarglobal.com

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

Product Development

Product Support

TODAY SOFTWARE MAGAZINE scăzut, deoarece banii pe serviciile oferite vor intra încă de la începutul proiectului. În CoP creşterea financiară este în concordanţă cu numărul clienţilor şi a pieţelor de desfacere pentru produsele realizate, raportul dintre profit şi numărul de angajaţi fiind mult mai favorabil decât în cazul CoS. În plus este nevoie de un capital mai mare necesar în dezvoltarea, promovarea şi vânzarea produsului. Se alocă buget special pentru marketing şi vânzări. În practică nu vom întâlni aproape niciodată implementată în mod pur una dintre cele două abordări. Pentru fiecare dintre caracteristicile discutate putem să ne gândim la contraexemple valide printre companiile pe care le vedem în jurul nostru. Acest lucru se întâmplă pe de o parte datorită vizunii pe care o au managerii unora dintre companii dar pe de altă parte şi lipsei de maturitate ale altor companii ce duce, uneori, la aplicarea unor strategii greşite ignorând contextul. Totuşi trăsăturile esenţiale se păstrează în marea majoritate a cazurilor şi reprezintă un foarte bun punct de start pentru discuţia despre product mindset.

Product Mindset

Una dintre cele mai interesante provocări este aceea de a combina laolaltă avantajele celor două abordări amintite mai sus şi de a atenua dezavantajele ce derivă din fiecare dintre ele. Combinarea se referă la introducerea de elemente specifice abordării proiectelor bazat pe servicii în CoP sau la implementarea unei abordări centrate pe produse în CoS. Există şi un al treilea tip de combinare, şi anume acela în care avem de-a face cu o companie orientată atât pe servicii cât şi pe produse, însă acest caz se poate reduce la precedentele cazuri dacă discutăm independent de departamentele ce gestionează produsele şi serviciile unei astfel de companii. Ne vom concentra în cele ce urmează pe cel de-al doilea tip de combinare lăsândule pe celelalte două ca subiecte pentru un posibil viitor articol. Product Mindset este un mod de abordare a serviciilor ce presupune o valoare semnificativă adăugată serviciilor prestate, asigură satisfacţii mai mari clienţilor, iar profitul obţinut este vizibil îmbunătăţit. În cazul industriei IT, produsul sau produsele clienţilor sunt “adoptate” de către compania ce implementează un astfel de product mindset iar implicarea companiilor software nemaifiind exclusiv axată pe execuţie. Apar roluri noi care dublează sau

uneori chiar înlocuiesc roluri care în mod firesc intră în responsabilitaţile clientului (cum este, de exemplu, rolul de product owner). Există două elemente caracteristice CoS ce impun o oarecare rigiditate în activitate şi care necesită o atenţie deosebită atunci când se doreşte implementarea unui product mindset. În primul rând avem rezistenţa echipei de a lucra cu specificaţii incomplete. În general, echipa se aşteaptă ca toate detaliile legate de o funcţionalitate (sau un user story) să fie clarificate de către client înainte de a începe dezvoltarea sa. Argumentându-se în acest fel se evită irosirea efortului de dezvoltare şi rescrierea unor porţiuni ale unei aplicaţii de două sau mai multe ori, echipa de proiect amână dezvoltarea unor elemente esenţiale ale aplicaţiei, efortul fiind concentrat pe un “ping-pong” de e-mail-uri sau şedinţe de clarificare ce pot dura nedefinit. Abordarea proiectului având un product mindset presupune implementarea de funcţionalităţi care nu au fost complet specificate de către client. Evident acest lucru presupune o cunoaştere cât mai bună a domeniului de business al clientului şi în acelaşi timp şi un grad mai ridicat de risc. În acest fel însă se deblochează dezvoltarea unor funcţionalităţi importante, deoarece clientul este mult mai în măsură acum să îşi clarifice nevoile plecând de la un exemplu deja implementat. Al doilea element esenţial îl reprezintă incapacitatea echipei de proiect de a înţelege şi urma sugestiile clientului cu privire la finalizarea unui produs sau modul în detrimentul calităţii acestuia. O soluţie particulară şi nu una generică, flexibilă şi adaptabilă (dar care necesită o dezvoltare mai îndelungată), întreţinerea unor componente scrise într-o tehnologie “antică” în locul rescrierii şi “modernizării” acestora, o implementare parţială a unor funcţionalităţi sau testarea incompletă a produsului reprezintă uneori cerinţe exprese ale clienţilor pentru a forţa atingerea unor deadline-uri esenţiale pentru soarta produsului. Astfel de propuneri, în cazul în care nu întâlnesc o echipă cu un product mindset, au darul de a conduce la frustrarea membrilor săi şi chiar la refuzul unora dintre ei de a continua munca pe proiect acuzând o presupusă lipsă de profesionalism. Rezolvarea acestei situaţii presupune efort din ambele direcţii: clientul va trebui să fie deschis la a partaja cu echipa de proiect elementele ce ţin de viaţa produsului însă şi echipa trebuie sa fie

interesată de aceste aspecte şi nu concentrată exclusiv pe execuţie. O abordare product mindset ajută la colaborări pe termen lung între CoS şi clienţii lor, aceştia din urmă văzând echipa de dezvoltare ca parte a propriei organizaţii, creditând-o cu încredere şi respect. Această apropriere însă dezvoltă un ataşament, uneori exagerat, al membrilor echipei pentru client si produsul sau produsele acestuia, unii dintre ei considerându-se angajaţi ai clientului şi nu a companiei de servicii din care fac parte. Trebuie acordată de asemenea o atenţie deosebită încheierii proiectelor, deoarece astfel de momente pot determina părăsirea companiei de către mulţi dintre cei care au dezvoltat un ataşament crescut pentru proiect.

Concluzii

Analiza implementării unei abordări orientate pe produs într-o companie a cărei activitate este preponderent orientată pe servicii este departe de a fi una exhaustivă. Totuşi, aspectele atinse sunt unele relevante ce influenţează hotărâtor parcursul şi succesul unei CoS în IT, iar avantajele implementării unei astfel de combinaţii sunt evidente. Modul de implementare a acestei combinaţii este, bineînţeles, o altă discuţie acesta depinzând, intr-o mare măsură de cultura organizaţională şi procedurile interne existente în fiecare companie în parte.

www.todaysoftmag.ro | nr. 13/Iulie, 2013

programare

Din uneltele artizanului software: Coaching tehnic

Alexandru Bolboaca

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

Adrian Bolboaca

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

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

tim din experiența industriei că tehnicile promovate de mișcarea software craftsmanship au potențialul de a crește productivitatea echipelor de dezvoltare. Test Driven Development ajută la obținerea unor soluții cu design mai bun și mai.. stabile într-un timp mai scurt.

Pair Programming ajută la eliminarea greșelilor în timp ce codul este produs, la diseminarea rapidă a cunoștințelor într-o echipă și la găsirea unor soluții mai simple. Continuous Integration ajută la rezolvarea rapidă și fără stress a problemelor de integrare între diverse componente. Refactoring-ul continuu ajută la păstrarea flexibilității codului, astfel că atunci când clienții cer funcționalități neprevăzute, echipa să le poată introduce foarte repede. Există însă și reversul medaliei. Test Driven Development poate duce la teste greu de întreținut și la abandonarea lor în timp. Refactoring-ul este adesea înțeles ca „iterații” sau „perioade” de refactoring, care se pot lungi săptămâni întregi, uneori fără niciun rezultat. Încercarea de a face pair programming poate fi interpretată ca neîncredere în programatori: „vine cineva să mă supravegheze când scriu cod”. Continuous integration poate genera multe probleme când este aplicat pe proiecte care au zeci de componente diferite, rezultând într-un return of investment discutabil. Ce anume face diferența între exemplele de succes și cele de eșec? Ce poate conduce către o adopție de succes? Răspunsul constă în gestionarea schimbării. Aici intervine partea de coaching; în acest caz, din cauză ca practicile ce se doresc adoptate sunt uber-tehnice, vorbim de coaching tehnic. Adopția practicilor tehnice într-o organizație Un coach tehnic se preocupă de câteva aspecte importante ale adopției unei practici: • Identificarea scopului: de ce adoptăm practica respectivă? Dintr-un motiv de business (ex. reducerea ciclului de

release de la 12 la 3 luni, de la 3 luni la 2 săptămâni, continuous delivery, creșterea satisfacției clienților)? Dintr-unul operațional (ex. reducerea numărului de unbillable hours, reducerea numărului de apeluri la suport)? Motive gen „am auzit de TDD și e cool”, “am auzit de practica X și ne va ajuta” nu sunt îndeajuns de bune; un coach poate ajuta la identificarea practicilor tehnice potrivite pentru atingerea obiectivelor organizației. • Definirea unui roadmap de adopție. De obicei este definit un proiect pilot în cadrul căruia 2-4 echipe se oferă voluntare pentru adopție. Rezultatele adopției sunt monitorizate și discutate în continuu cu managementul. • Identificarea și gestiunea riscurilor. Unele riscuri sunt vizibile de la început (de exemplu lipsa cunoștințelor necesare pentru a scrie teste unitare simple, un release plasat în timpul perioadei de coaching), pe când altele apar pe parcursul adopției. • Lucrul direct, hands-on, pe codul de producție cu echipele de programatori. • Mini-training-uri ad-hoc, în funcție de necesități. • Introducerea unor comunități de exersare (communities of practice), unde orice persoana interesată poate vedea și încerca practicile care se vor adoptate. Coach-ul tehnic poate fi intern sau extern companiei care încearcă să adopte TDD, refactoring, sau chiar Extreme Programming. Ambele abordări au avantaje și dezavantaje. Coach-ul intern are avantajul că înțelege structura companiei și proiectele, dar are de obicei dezavantajul că face parte din sistem și îi este mai greu

TODAY SOFTWARE MAGAZINE coding dojo, code retreat sau conferințe tehnice este utilă pentru menținerea motivării. Pair programming-ul cu persoane selectate este o altă metodă care poate fi aplicată pentru continuarea învățarii. Nu toți dezvoltatorii au însă voința și automotivarea necesară pentru a dobandi o aptitudine. Pentru ei, un coach tehnic este unul din mijloacele de a-și atinge scopul de a învăța o practica tehnică prin: • Identificarea punctelor tari și punctelor care pot fi îmbunătățite. De exemplu, înțelege cod foarte repede dar scrie teste unitare prea complicate; • Stabilirea scopului pe următoarele 3-4 luni. De exemplu, simplificarea testelor unitare; • Definirea unui plan de învățare format din: citit cărți, scrierea de cod revizuit de către coach, sesiuni de pair programming etc; • Urmărirea programului de învățare. Coach-ul se asigură că programatorul se Este uneori dificil de înțeles cum un ține de promisiuni, și îl/o ajută să elimine coach tehnic extern poate deveni foarte blocajele care apar în învățare. rapid productiv într-o echipă și într-o aplicație complet nouă. Pare magie, nu-i La nivel individual, activitățile de așa? Explicația este de fapt simplă: coach-ul coaching sunt foarte similare cu cele de tehnic nu trebuie să înțeleagă business- mentoring sau relația craftsman - master. ul și toate detaliile interne ale aplicației. Un coach tehnic ajută în plus față de un Produsul coach-ului este echipa; echipa se mentor tradițional la identificarea și reduîngrijește de a înțelege aplicația și business- cerea impedimentelor. Impedimentul tipic ul. Coach-ul tehnic se bazează pe cunoștințe declarat de către programatori este lipsa de solide despre practicile care se vor adoptate timp de învățare, care poate fi ușor rezolvat și pe pattern-uri de arhitectură, design, prin: sesiuni de învățare scurte (30-45’ pe cod și interacțiune interumană pentru a zi), planificare mai bună sau sesiuni mai duce întreaga echipă la un nivel mai înalt intense și mai rare (ex. pair programming, de productivitate. Coach-ul nu poate lucra coding dojos sau code retreats). fără echipă, la fel cum produsul software Merită explicat rolul pair programmingnu poate fi creat fără echipă. Doar printr-o ului în procesul de învățare, pentru că este colaborare strânsă cu echipa, prin discuții uneori confuz. Pair programming poate fi și comunicare sinceră și continuă, prin folosit în producție, pentru învățarea proîncredere și respect reciproc, poate coach- iectului și pentru prevenirea greșelilor din ul să ajute echipa să adopte o practică nouă. cod. În contextul adoptării unei practici, pair programming-ul poate fi folosit ca Adopția practicilor tehnice la nivel modalitate prin care coach-ul tehnic transindividual mite cunoștințele sale legate de o anumită Până acum am prevăzut unele aspecte practică a programatorului. Pentru a aplica despre adopția unei practici tehnice noi pair programming în producție, este nevoie într-o companie. La nivel individual, lucru- de asemenea de o perioadă de adopție, iar rile sunt similare dar mult mai simple. adoptarea pair programming se face prin Un programator motivat și care are sesiuni de pairing între doi programatori, condițiile necesare poate să învețe singur sub supervizarea coach-ului tehnic. În timp o practică tehnică nouă. Folosirea tehnici- ce programatorii se concentrează să rezolve lor individuale de exersare precum coding problema la care lucrează, coach-ul se va kata sau proiect personal este recoman- concentra pe interacțiunea dintre cei doi dată în combinație cu urmărirea resurselor și pe eliminarea problemelor de comunide pe web (ex. http://katacasts.org) și citirea care și a discuțiilor ineficiente. Așadar, e o a două-trei cărți recomandate pe subiectul diferența majoră între adoptarea pair prorespectiv. Mai departe, totul ține de tenaci- gramming, folosirea tehnicii în producție tate, voință și automotivare. Participarea la și învățarea altor tehnici prin intermediul să vadă anumite lucruri care trebuie schimbate. Un coach extern are câteva avantaje ce merită luate în seamă: • Experiența cu echipe și contexte diverse: un coach tehnic specializat trece prin zeci de echipe și proiecte, prin tehnologii și soluții diverse. Această experiență îi permite să se adapteze rapid la un mediu nou. • Relațiile cu alți consultanți, coach-i tehnici sau programatori de elită: parte din job-ul de coach tehnic este învățarea și vorbitul la conferințe. Un coach tehnic bun își creează o rețea de cunoștințe care îi pot răspunde la întrebări tehnice mai specifice, ajutând la rezolvarea mai rapidă a unor probleme spinoase. • Leadership și comunicare: un coach tehnic bun trebuie să fie capabil ca împreună cu managerii, să definească o viziune pe care să o urmeze dezvoltatorii și să o comunice convingător.

pair programming. Coach-ul tehnic trebuie să stăpânească foarte bine tehnicile de pairing, pentru a reuși să transmită informație chiar acelor programatori care nu au făcut niciodată pairing dar vor să învețe una din tehnicile descrise mai sus.

Concluzie

În concluzie, un coach tehnic gestionează procesul de adopție a uneia sau mai multor practici tehnice la nivel individual, de echipă sau cu 2-4 echipe. Expertiza sa poate face diferența între succes și eșec când o companie sau un programator dorește adopția practicilor gen unit testing, TDD, refactoring incremental, îmbunătățirea design-ului software, diminuarea problemelor legate de cod existent greu de înțeles. Coach-ul poate fi intern sau extern organizației. Avantajul unui coach intern este familiarizarea cu contextul organizației și al aplicațiilor, dar dezavantajul unei experiențe limitate și a faptului că face parte din sistem. Un coach extern are că avantaj faptul că a participat în zeci de proiecte cu constrângeri și nevoi diferite și ca poate privi organizația cu ochi proaspeți, din afara sistemului. Coach-ul extern trebuie să înțeleagă doar punctual nevoile de business și ale aplicației, și se încrede în echipa cu care lucrează în legătură cu detaliile specifice proiectului. Produsul coach-ului tehnic este echipa; o echipă care învață tehnici noi, pe care le poate aplica direct în producție cu încredere, reușind în același timp să își atingă obiectivele de business. Colaborarea strânsă între coach tehnic și echipă, bazată pe respect reciproc, comunicare și sinceritate este principalul factor de succes al adopției. După perioada inițială de coaching, echipa are instrumentele necesare pentru a continua învățarea, coach-ul având doar un rol de suport (“vocea conștiinței”). Gândiți-vă așadar ce ratați de fiecare dată când spuneți că nu aveți timp de a adopta o anumită practică. Poate pierdeți clienți, oportunități, potențial inovator, un job mai bun. Un coach tehnic vă poate ajuta să decideți care practică este utilă în contextul business-ului și al aplicațiilor curente și vă poate ajuta să adoptați practicile care duc la împlinirea potențialului. Așteptăm întrebările voastre pe programez.ro !!!

www.todaysoftmag.ro | nr. 13/Iulie, 2013

programare

Recenzia cărții: Java Message Service de Mark Richards, Richard Monson-Haefel şi David A. Chappell

erviciul de mesagerie oferit de Java şi arhitecturile asociate reprezintă o alternativă la metodele de comunicare clasice şi arhitecturile asociate, precum RPC şi sitemele distribuite. Gradele de încredere, flexibilitate, extensibilitate şi modularitate ale unei aplicaţii sunt mult mai mari prin folosirea acestor arhitecturi decât în cazurile clasice, anterior amintite.

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

Iată alte câteva dintre avantajele folosirii sistemului de mesagerie: • Integrarea platformelor eterogene. Spre exemplu a platformelor ActiveMQ şi IBM WebSphere MQ, dar şi a clienţilor non Java precum cei dezvoltaţi în C şi C++; • Arhitecturi hibride, care reprezintă o combinaţie de arhitecturi centralizate şi descentralizate; • Modele de mesaje, point to point şi publish-and-subscribe. Aceasta înseamnă că un producător adresează mesajul fie unui singur consumator fie unui grup de consumatori. Dezvoltarea serviciului de mesagerie a avut numeroase momente importante în ultimii zece ani. Apariţia noilor tehnici si tehnologii printre care Message Driven Bean (MDB), Spring messaging framework, Event Driven Archite c ture, S er v iceOriented Architecture, RESTful JMS interfaces şi Enterprise Service Bus (ESB) sunt doar câteva dintre reperele importante în această dezvoltare. S e r v i c iu l de mes agerie este gestionat prin

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

intermediul unui API, ajuns la versiunea 1.1. Acesta este de fapt a doua versiune a specificaţiilor, după versiunea 1.0 iniţială. Platforma cu versiunea 7 a Enterprise Java, care este aproape de a fi lansată oficial, aduce o nouă versiune a specificaţiilor JMS şi anume 2.0. Îmbunătăţirile sunt numeroase, cele mai multe fiind pe partea de simplificare a codului şi adaptarea la noile dezvoltări ale tehnologiilor (trimiterea asincronă a mesajelor, introducerea

business factory-urilor, etc). Cartea pe care v-o supun atenţiei, Java Message Service, a doua ediție, avându-i ca autori pe Mark Richards, Richard Monson-Haefel şi David A. Chappell, reprezintă un ghid complet pentru folosirea mesajelor şi a arhitecturilor bazate pe acestea. Împărţită în 11 capitole, cartea prezintă gradual aspecte legate de atingerea performanţei în utilizarea serviciului de mesagerie în Java. Dacă în primul capitol se discută aspectele generale legate de mesaje, precum consideraţii şi paralele cu alte arhitecturi, în capitolele doi, trei, patru şi cinci se prezintă cam tot ce ar trebui să ştie un novice despre această arhitectură. Anatomia unui mesaj cuprinde trei părţi importante: header-ele, proprietăţile şi tipurile de mesaje. Apoi, folosirea mesajelor point-to-point şi publish-andsubscribe sunt descrise cu discuţii asupra variantelor posibile de implementare. Fiecare dintre aceste capitole sunt ilustrate din plin cu exemple concludente. De la o aplicaţie de chat clasică pîna la o aplicaţie de împrumut şi creditori, toate scot în evidenţă aspectele teoretice prezentate. Capitolul 6 se referă la filtrarea mesajelor. Filtrarea dintr-o coada sau dintr-un topic se face prin selectorii de mesaje. Selectorii de mesaje se aplică consumatorilor de mesaje. Consumatorii vor primi doar acele mesaje ce satisfac condiţiile de filtrare. Selectorii vor folosi proprietăţile şi header-ele de mesaj pentru a testa expresiile condiţionale ale filtrelor. Capitolul se încheie cu consideraţii privitoarele la design-ul aplicaţiilor ce folosesc filtre. Capitolul şapte este împărţit în două subpărţi înrudite, prima legată de modul de confirmare al mesajelor şi implicit de consumare al acestora, iar cea de-a doua legată de tranzacţii. Tranzacţiile JMS sunt determinate de perspectiva diferită pe care producatorul şi consumatorul o au faţă de un mesaj. Producătorul are un contract cu serverul de mesaje ce asigură că mesajul va fi furnizat serverului. Serverul are un contract cu consumatorul prin care se asigură că mesajul îi va fi livrat. Cele două operaţii sunt separate, ceea ce este un beneficiu indiscutabil pentru mesageria asincronă. Tranzacţiile urmăresc această separare a operaţiilor de trimitere şi recepţionare, dar grupează mesajele astfel încât vor ajunge la server toate sau nici unul. Tranzacţiile JMS, deşi asemanatoare cu JTA (Java Transaction API) sunt gestionate de furnizorul de mesagerie. Capitolul opt prezintă un mare pas înainte în gestionarea optimă a acestei arhitecturi şi anume Message-Driven Bean-urile (MDB). MDB-urile sunt componente logice, care se instanţiază automat de către container şi care asteaptă şi consumă mesajele primite de la diverşi producători. Avantajele sunt substanţiale pentru că întreg ciclul de viaţă este gestionat de container, iar procesele asincrone primesc un suport considerabil. Capitolul se încheie cu bune practici de folosire aMDB-urilor şi anume pattern-ul facade. Capitolul nouă prezintă suportul oferit de Spring pentru dezvoltarea aplicaţiilor bazate pe JMS. Capitolul zece este concentrat pe cosideraţii de desfăşurare pe server a resurselor folosite de arhitecturile JMS. În sfârșit, ultimul capitol se bazează pe consideraţii asupra design-ului mesageriei, cu discuţii punctuale asupra destinaţiilor interne sau externe, design-ul mesageriei request/reply, dar şi antipattern-uri în design-ul de mesagerie. Cartea cuprinde şi patru appendix-uri relativ la API-ul JMS, message header-e, message properties şi instalarea, respectiv, configurarea lui ActiveMQ. Părerea mea este că serviciul de mesagerie oferit de Java nu este folosit, probabil pentru că nu este cunoscut suficient, la adevăratul său potenţial. Avantajele majore evidenţiate la începutul

TODAY SOFTWARE MAGAZINE

recenziei alături de îmbunătăţirile aduse de versiunea 2.0 fac ca acest serviciu să merite un interes mult mai mare decât cel actual. Cred că la nivel de backend, pe parte de comunicare asincronă, JMS şi MDB sunt soluţii excelente. Vă doresc lectură plăcută şi aştept cu interes discuţii pe acest subiect pe programez.ro !

www.todaysoftmag.ro | nr. 13/Iulie, 2013

programare

HTML5: Web Sockets

robabil cea mai importantă influență în conectivitatea calculatoarelor o are protocolul HTTP. Acest protocol a permis realizarea web-ului pe care îl folosim azi aproape continuu și care a produs revoluție după revoluție în ultimii ani. Primele pagini web au fost cele statice, poate presărate cu puțin conținut multimedia de prost gust, apoi au apărut aplicațiile web din ce în cel mai complexe. Imediat utilizatorii au descoperit atât posibilitățile noi cât și granițele și limitele care urmau să bântuie Internetul pentru următorii ani. Radu Olaru

rolaru@smallfootprint.com Senior Software Developer @ Small Footprint

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

TCP și HTTP

Protocoalele de comunicare între sisteme presupun o discuție lungă. Simplificat, există un protocol care definește comunicarea între sisteme, numit TCP și un protocol care definește comunicarea web între un client și un server web, numit HTTP. HTTP este implementat peste TCP, adică folosește comunicarea definită prin TCP, dar adaugă elementele specifice paginilor web: un client cere o pagină web, serverul oferă un răspuns după care comunicarea este considerată încheiată. Pentru noi informații de la server, clientul trebuie să facă o cerere nouă. Astfel protocolul HTTP implementează comunicarea simplă și eficientă între o aplicație și un server oferită de protocolul TCP, garantând transferul mesajelor la

destinație – dar permite serverului să dea un singur răspuns. Acest gen de comunicare este util pentru aplicații, dar e departe de a fi suficient. Serverul nu poate transmite mesaje clienților pe cont propriu. Orice mesaj de la server spre client poate fi transmis doar dacă clientul inițiază un act nou de comunicare. Dacă serverul primește o informație utilă clientului, de exemplu o actualizare a datelor pe care clientul tocmai le-a cerut, nu are cum să le transmită până când clientul va cere din nou aceste informații.

De la soluții rezonabile la pluginuri

Peste ani s-au încercat mai multe metode de a depăși această limită. Între timp aplicațiile web s-au dezvoltat, au definit noi tendințe și în cele din urmă au

TODAY SOFTWARE MAGAZINE devenit indispensabile companiilor dornice să-și facă prezența simțită printre milioanele de navigatori ai Internetului. A apărut revoluția AJAX care crea iluzia unei conectivități permanente între server și clienți. S-au inventat chiar mecanisme care să forțeze protocolul HTTP să imite conectivitatea permanentă – un efort totuși insuficient. Soluția poate cea mai drastică a fost crearea plugin-urilor pentru browsere, care pur și simplu deschideau un port nou TCP, pe lângă cel de conectare la pagina web. Flash și Silverlight sunt probabil cele mai răspândite exemple. Comunicarea permanentă cu întârzieri minime părea să aibă nevoie de soluții nepractice care concurau cu rescrierea protocolului. Soluția? Deoarece HTTP nu este un protocol de sine stătător ci funcționează peste TCP, dacă browserul ar ști folosi acest protocol, s-ar putea conecta permanent la un server pentru a comunica nestingherit. Ei bine HTML5 definește o specificație care permite tocmai acest lucru: interpretarea unui protocol similarTCP într-un browser.

Upgrade la protocolul WebSockets

Implementarea este chiar eleganta: browserul cere o pagină web oarecare, funcționând pe principiile protocolului HTTP, însă pagina poate modifica apoi conexiunea pentru a folosi protocolul WebSockets: var connection = new WebSocket( ‘ws://site.org/echo’, [‘soap’, ‘xmpp’]); connection.onopen = function () { connection.send(‚Ping’); };

platformelor curente de programare care oferă această implementare. De asemenea pot fi trimise mesaje binare: var img = canvas_context.getImageData(0, 0, 400, 320); var binary = new Uint8Array(img.data.length); for (var i = 0; i < img.data.length; i++) binary[i] = img.data[i]; connection.send(binary.buffer);

Traversarea proxy-urilor

Sau fișiere: var file = document.querySelector( ‘input[type=”file”]’).files[0]; connection.send(file);

Diferențe față de protocolul TCP și HTTP

WebSocket modifică conexiunea HTTP într-una similară cu TCP. Protocolul de comunicare ulterior nu este TCP, ci este o variantă modernizată a acestuia. Protocolul WebSockets implementează comunicarea full duplex, cu diferența că mesajele trimise nu sunt fluxuri de bytes, ci fluxuri de mesaje (desigur, pot fi și mesaje în format binar). Mesajul trimis peste HTTP pentru a iniția noua formă de comunicație este următorul: GET /mychat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat Sec-WebSocket-Version: 13 Origin: http://example.com

Serverul răspunde apoi cu mesajul: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat

Mecanismul este identic cu transferul de la protocolul HTTP la HTTPS. Mesajul HTTP permite serverelor să primească connection.onmessage = function (e) { console.log(‚Server: ‚ + e.data); }; atât conexiuni HTTP cât și WebSocket pe Mai sus se poate vedea cum pagina același port, însă sunt transmise informații inițiază comunicarea websocket si stabilește specifice WebSocket. handlere pentru evenimentele conexiunii. La deschiderea conexiunii se trimite mesajul Ping spre server, in cazul erorilor intervenite în comunicare acestea sunt logate în consola browser-ului, iar dacă serverul trimite vreun mesaj spre client, va fi de asemenea logat în consolă. Bineînțeles, la primirea unui mesaj se pot executa orice alte instrucțiuni javascript. Prin execuția codului de mai sus nu se deschide nici un port nou TCP. Pur și simplu conexiunea HTTP deja existentă primește un upgrade request care schimbă protocolul de comunicare. Protocolul nu va Odată ce conexiunea este stabilită, climai fi HTTP, ci WebSocket – direct peste entul și serverul își pot trimite date între TCP. ei în mod full duplex. Datele conțin un Pentru a trimite mesaje, serverul overhead minim, practic folosesc un heatrebuie să implementeze de asemenea der scurt urmat de corpul propriu-zis. specificațiile WebSocket. Există mai multe Transmisiile WebSocket se numesc mesaje librării pentru majoritatea limbajelor si și un singur mesaj poate fi împărțit în mai connection.onerror = function (error) { console.log(‚Error: ‚ + error); };

multe pagini trimise separat (întocmai ca în cazul protocolului TCP). Aceasta permite transferul unui mesaj foarte mare a cărui dimensiune nu este cunoscută de la început – se trimit paginile pe rând, ultima fiind marcată cu un flag special. Implementările protocolului WebSocket încearcă să determine dacă browserul este configurat să folosească un proxy când se conectează la o destinație. Dacă determină existența unui proxy, folosește metoda HTTP CONNECT pentru a crea un tunel persistent. Deși protocolul WebSocket în sine nu este conștient de existența proxy-urilor și a firewall-urilor, folosește un handshake compatibil HTTP care permite serverelor web să ofere acces la porturile HTTP și HTTPS (80 și respectiv 443). Protocolul WebSocket definește prefixul ws:// și wss:// care indică tipul de conexiune: simplă sau securizată. Ambele folosesc mecanismul de upgrade descris anterior. Desigur, în final proxy-urile decid dacă permit un asemenea trafic sau nu. Esențial este că protocolul WebSocket nu necesită deschiderea unor porturi noi sau formularea unor mesaje complexe, diferite de standardul HTTP. La fel, protocolul nu necesită intervenții suplimentare în definițiile firewall-urilor – dacă portul 80 este deschis, comunicarea WebSocket va funcționa automat alături de cea HTTP.

WebSockets cu Node.JS

Am văzut cât de simplu se inițiază conversațiile WebSocket de pe client folosind javascript. Ei bine pe server este la fel de simplu. Internet Information Services necesită versiunea 8 alături de o configurare suplimentară din Windows pentru a permite funcționarea noului protocol, dar pentru simplitate vom folosi Node.JS – și tot limbajul javascript: var WebSocketServer = require(‚websocket’). server; var http = require(‚http’); var clients = []; var server = http. createServer(function(request, response) { // aici se procesează cererile HTTP // dacă implementăm un server pur WebSocket, nu // trebuie să scriem nimic aici }); server.listen(1337, function() { }); // inițializăm serverul WebSocket var wsServer = new WebSocketServer( { httpServer: server }); wsServer.on(‘request’, function(request) { var connection = request.accept(null, request. origin); // mesajele primite de la client vor fi // procesate aici connection.on(‚message’, function(message) { if (message.type === ‚utf8’) { connection.sendUTF(‚Hello’);

www.todaysoftmag.ro | nr. 13/Iulie, 2013

programare HTML5: Web Sockets // trimite înapoi un mesaj la client clients.push(connection); // rețin clientul } }); connection.on(‚close’, function(connection) { // închide conexiunea și anunță toți clienții for (var i = 0; i < clients.length; i++) clients[i].sendUTF(‚someone left’); }); });

Practic modelul de funcționare este similar șablonului Observer: se reține o listă de subscrieri, iar când serverul are un mesaj de publicat, mesajul este transmis pe rând întregii liste.

Cerințe și limitări

După cum am văzut, WebSockets este mai mult decât un API HTML5. Desigur, instrucțiunile de comunicare din client sunt standardizate în specificația HTML5 – dar există nevoia implementării acestui protocol și la nivelul serverului. Partea de server este specificată în RFC 6455. Din acest motiv, comunicarea WebSockets necesită în primul rând un browser care să suporte protocolul, dar și un server care să-l implementeze. În prezent majoritatea serverelor web uzuale au fost actualizate să suporte WebSockets: IIS 8, Apache, LightHTTPD și bineînțeles, Node.JS care poate crea servere web compatibile. Totuși limitarea esențială rămân versiunile vechi de IIS – IIS8 este disponibil doar în Windows 8. În ce privesc browser-ele, din nou, toate browser-ele actuale permit comunicarea prin WebSockets – dar pentru firmele care limitează utilizatorii la Internet Explorer, singura versiune compatibilă este Internet Explorer 10 – care apare din nou, doar în Windows 8.

Resurse și referințe • http://www.html5rocks.com/en/tutorials/websockets/basics/ • http://www.websocket.org/ • https://developer.mozilla.org/en/docs/WebSockets • http://tools.ietf.org/html/rfc6455

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

Team building (I)

umeroase companii organizează în această perioadă team building-uri, motiv pentru care am auzit diverse discuții legate de ce fel de activități de învățare prin joc sunt recomandabile pentru a fi folosite. Am vrut să scriu de data aceasta un alt fel de articol, care să fie mai mult concentrat pe partea practică. Nu consider că este necesar să mai ofer o definiție a unui team-building, pentru că deja este un concept des utilizat, dar aș vrea să fac câteva mențiuni legate de cum anume este recomandabil a se organiza unul.

Andreea Pârvu

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

Aș defini șapte pași de bază. Pasul 1: Analiza nevoilor participaților. Cea mai simpla metodă este utilizarea unui chestionar. Partea interesantă este definirea întrebărilor corespunzătoare care să susțină cel mai bine acest proces. Răspunsurile sunt interpretate, iar pe baza lor se stabilesc obiectivele team-buildingului. Pe de altă parte două alte metode utilizate sunt: interviul structurat care să urmărească criterii clar definite sau observația în cazul grupurilor mai mici. În funcție de numărul membrilor echipei se poate folosi un singur instrument sau chiar toate cele trei menționate mai sus. Pasul 2: Determinarea obiectivelor. Pentru măsurarea impactului team-building-ului asupra participanților obiectivele trebuie să fie cât mai SMART definite. (S=simple, M=measurable, A=achievable, R=realistic, T=timeline). Pasul 3: Stabilirea blocurilor de pregătire. Rolul acestora este de a îngloba mai multe activități care să aibă același obiectiv de dezvoltare. Pentru a argumenta cât mai bine acest concept voi prezenta un scurt exemplu : dezvoltarea abilităților de comunicare în echipă.

Pasul 4: Definirea activităților de teambuilding. Pentru fiecare bloc se stabilesc activitățile cu scopul și obiectivele aferente. Pasul 5: Stabilirea duratei fiecărei activități. Trebuie luate în considerare scopul și obiectivele acestora. Vor fi activități care vor avea mai mult timp alocat, unele mai puțin, în funcție de importanța și de impactul pe care acestea îl pot avea asupra participanților. Pasul 6: Găsirea echipei de traineri. Este un proces complex, deoarece este necesar ca această echipă să fie pregătită și competentă. Pasul 7: Pregătirea team-buildingului, care este în concordanță cu obiectivele definite la pasul 2. Fiecare activitate din team-building trebuie să aibă o schiță predefinită după care trainer-ul să se ghideze pe parcurs. Pasul 8: Coordonarea activităților pe parcursul team-building-ului, pentru o cât mai bună încadrare în timp și pentru o cât mai bună transmitere a informației către participanți. În a doua parte a articolului voi prezenta două activități pe care le puteți utiliza pentru a consolida echipele pe care le coordonați.

www.todaysoftmag.ro | nr. 13/Iulie, 2013

HR Team building (I)

Activitatea 1

Timp alocat activitate

5 minute/ participant

Nume activitate

Total: RULMENTUL

Impărțire pe echipe Localizare Materiale

4 echipe (10 membri/ echipa – maxim) Indoor / outdoor Un flipchart pe care să fie notate următoarele întrebări : Care este cel mai nebunesc vis ? Care este cea mai mare năzbâtie pe care ai făcut-o în copilărie ? Care este cel mai interesant loc vizitat vreodată și de ce ? Care este locul în care îți dorești cel mai mult să ajungi. Sunt 4 întrebări care urmăresc o cunoaștere personală a colegului de lucru. De menționat este faptul ca aceste întrebări pot fi modificare în funcție de aspectele care se doresc a fi aflate pe parcursul acestei activități. Recomandarea mea este o abordare cât mai personală, pentru a se stabili o legătură între aceștia.

Obiective Descriere Necesar

Cunoașterea celorlalți membri Aranjați în cercuri concentrice (numărul cercurilor depinde de numărul participanților), participanții vor avea ocazia să afle detalii interesante despre colegii lor, după modelul speed-dating. (5’ cu fiecare alt participant). Fiecare participant să aibă o listă cu întrebări (coală A4)

Este recomandabil ca aceste activități de cunoaștere a celorlalți membrii din echipă să fie desfășurate în prima parte a team-building-ului. Cu cât persoanele se cunosc mai bine cu atât interacțiunea dintre ele în momentul în care lucrează este mai ușoară, iar abordarea în soluționarea conflictelor va fi mult mai personală. De menționat este faptul că aceste activități de cunoaștere să nu depășească mai mult de 30% din timpul total alocat pentru team-building.

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

Activitate 2

Timp alocat activitate

Nume activitate Impărțire pe echipe Localizare Materiale Obiective

echipe * 20 minute + debriefing 30 min (este recomandabil ca numărul maxim într-o echipă să fie 10). Total: TURNURILE GENERAȚIEI Echipe Outdoor/indoor Descriere reguli pentru facilitatori. Facilitatorii sunt acele persoane care observă fiecare echipă și ia notițe care sunt folosite ulterior în partea de debriefing. Planificarea activităților Comunicare organizatională Responsabilizare – ce înseamna să construiești pe ideile celorlalți Feedback (prin debriefing)

Descriere

Debriefing

Gestionarea conflictelor Echipele (în funcție de numărul participanților vor fi împărțiți – nu însă în grupuri mai mari de 10) vor porni construcția a trei turnuri de minim 2,5 metri inălțime și care să țină în vârf o minge de tenis (orice minge ). După 20 minute, echipele își vor schimba locul și vor trebui să continue munca celor de dinainte. După alte 20 minute se va face următoarea schimbare până când toate echipele vor ajunge la turnul pe care au început să îl construiască. Cum e să depinzi de munca altuia? De ce e important să ai planuri scrise? Cum coincide viziunea voastră cu rezultatul final? Ce ați îmbunătăți? Ați ales să continuați/distrugeti munca celor de dinainte?

Necesar

Cum ați creat frontul de lucru pentru ceilalți? Sfoara, carton, PET-uri, hartie, mingi tenis (orice fel de minge) , foarfece, scotch X

Activitățile de îmbunătățire a comunicării, capacitatea de a lucra în echipă pentru atingerea unui obiectiv comun, precum și partea de câștigare a încrederii celorlalți sunt cu atât mai relevante cu cât partea de debrifing este mai detaliată și mai personalizată pe modul în care echipa implicată în joc a reacționat în îndeplinirea sarcinilor. Debriefing-ul este necesar să aibă întotdeauna niște concluzii clare și comun agreate de membrii echipei, care să vadă relevanța activității întreprinse în munca de zi cu zi. Scopul următorului articol va fi de a continua această serie și de a prezenta și alte activități. Succes și distracție plăcută !

www.todaysoftmag.ro | nr. 13/Iulie, 2013

SPRE COMUNITATEA IT – via HR (II)

Cristina Nicule

cristina.nicule@danis.ro Consultant @ Danis Consulting

Dan Ionescu

dan.ionescu@danis.ro Director Executiv @ Danis Consulting

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

evenim cu al doilea articol care sintetizează părerile unor reprezentanţi HR din firme IT clujene de marcă, reuniţi în al doilea workshop din cele patru pe care ni le-am propus în anul 2013. Dorim să identificăm practici din sfera resurselor umane, trecute şi prezente, posibil utile pentru procesul de constituire a unei comunităţi mature de IT în zona Clujului. Ne-ar plăcea ca acest demers să fie urmat şi de alte „bresle” profesionale din regiune. Deocamdată credem că industria IT, fiind „pe val”, se poate constitui într-un veritabil model de succes, care să seteze standarde de muncă şi pentru alţii (venituri decente, mediu de lucru incitant, şefi apropiaţi oamenilor). Dar pentru asta mai este puţin de lucru! Dacă în articolul anterior, apărut în nr. 11 TSM, am surprins factorii ce au favorizat evoluția firmelor ce a folosit firmelor de IT ca să crească în anii din urmă şi ce practici de conducere au fost mai apreciate, în întâlnirea din 11 iunie, de la sediul firmei Danis, am abordat câteva dintre cele mai actuale preocupări ale firmelor de IT în sfera managementului resurselor umane. Acest demers a fost facilitat de prezenţa reprezentanţilor HR-ului din următoarele firme cu sediul în Cluj: AROBS, IQUEST, FORTECH, RECOGNOS, cărora le mulţumim pentru dedicaţie şi interes onest!

Cu ce probleme se confruntă HR-ul din IT acum, în Cluj?

Vrem să specificăm de la început că este mai mult decât evident pentru toţi că MAREA PROBLEMĂ cu care se confruntă HR-ul din IT-ul clujean este aducerea şi reţinerea oamenilor în companii. Acest proces a devenit ca un fel de „obsesie” şi o abilitate-cheie a unui om de HR aflat întro companie de IT. În acelaşi timp, este şi un subiect devenit oarecum „tabu” tocmai pentru că recrutarea de oameni este atât de dificilă. Noi NU am abordat acest subiect în discuţiile noastre pentru că este oarecum saturat şi, credem noi, aproape inutil să o facem: nu este cum să găseşti metode noi să aduci oameni (şi fără să-i „furi” de la alte companii…) dacă nu ai numărul de

oameni necesari pe piaţă. Diferenţa între cererea firmelor de IT şi numărul de angajaţi disponibili pe piaţă este atât de mare încât credem că, în acest punct al proiectului nostru – discuţii despre practici de succes în resurse umane – ar fi inutil să discutăm despre strategii eficiente de recrutare… Poate va reapărea subiectul pe tapet atunci când vom aborda idei legate de o comunitate matură de profesionişti IT aici în Cluj… Dar, până atunci… Subiectele abordate în acest al doilea workshop s-au bazat şi pe sugestiile participanţilor şi dezbaterile din cadrul discuţiilor panel realizate în cadrul lansării TSM nr. 11. Principalele idei de practici pe care vi le vom prezenta în continuare se pot structura în două mari categorii: 1. Procesul de dezvoltare a angajaţilor din companiile de IT cu referire la particularităţi ale modului de abordare a propriei dezvoltări, tehnici de atragere a oamenilor în astfel de acţiuni, provocări oferite de angajaţii din IT faţă de alţi angajaţi din alte arii profesionale; 2. Modalităţi de construire şi menţinere a echipelor de lucru performante în domeniul IT vizâmd practici pentru atingerea rapidă a gradului de maturitate şi, implicit, a rezultatelor; depăşirea provocărilor legate de fluctuaţia mare;

TODAY SOFTWARE MAGAZINE Ideile şi părerile împărtăşite în cadrul acestui articol pot fi utile oricărui manager/ specialist de Resurse Umane dintr-o companie de IT, precum şi oricărui lider (de la nivele de top, până la cel de team-leader) care îşi asumă cu adevărat răspunderea pentru creşterea performanţei oamenilor pe care îi organizează. Dacă sunt noi pentru dumneavoastră, vă invităm cu drag să le aplicaţi în propriile dumneavoastră organizaţii. Dacă aţi utilizat deja unele practici similare sau altele eficiente, am fi încântaţi să le dezbatem în cadrul discuţiilor panel din cadrul lansării actualului număr TSM – la care vă invităm să participaţi. Să le luăm pe rând!

Procesul de dezvoltare a angajaţilor din companiile de IT

De ce este o provocare pentru HR dezvoltarea angajaţilor din IT? Cel puţin din două motive: 1) sunt oameni tehnici, logici, raţionali care au nevoie de chestiuni practice – de aceea formele de învăţare la care participă trebuie să fie de foarte bună calitate; 2) Oamenii din industria IT-ului se află într-un context privilegiat, pozitiv: au de regulă, foarte devreme, poziţii bune, sunt „hrăniţi emoţional” bine la locul de muncă (este satisfăcător în ceea ce priveşte beneficiile de toate felurile), sunt oameni implicaţi în proiecte tari – toate acestea reprezintă un set de avantaje, dar în acelaşi timp pot reprezenta şi o capcană a autosuficienţei care poate împiedica pe unii reprezentanţi ai domeniului să mai aibă motivaţia internă de a se dezvolta, considerându-se deja suficient de buni. Aceste provocări au fost surmontate în mare măsură în companiile prezente la workshop printr-un set de practici menite să crească gradul de determinare, implicare şi dorinţă reală a angajaţilor din IT pentru propria lor dezvoltare. Tendinţa spre a opune rezistenţă în faţa propunerilor de dezvoltare venite din partea companiei, a HR-ului sau a managerilor se pare că este mai mare în cazul angajaţilor din IT decât din alte domenii. Oamenii din IT sunt oameni inteligenţi şi mult mai independenţi decât cei formaţi în alte profesii / companii. Ca atare, orice formă de impunere – chiar şi blândă – nu funcţionează! De aceea, pentru ca acţiunile de dezvoltare (cursuri, programe, conferinţe etc.) să aibă rezultate, oamenii trebuie implicaţi în procesul de decizie. Acest lucru se poate face prin mai multe căi. Monica David de la AROBS susţine ideea utilizării surveyurilor interne pentru a evalua nevoile şi

interesele angajaţilor pentru dezvoltare, care sunt ariile de îmbunătăţire dorite, cine sunt persoanele care doresc să se implice în acţiuni de învăţare şi dezvoltare. „Dacă omul nu simte din interior nevoia de dezvoltare, degeaba!”. Şi celelalte companii prezente la discuţii susţin ideea folosirii formelor de analiză şi evaluare a nevoilor de dezvoltare / training în companii – periodice, sau legate de sistemele interne de evaluare a performanţelor. Prin aceste survey-uri poţi face şi comparaţii între ceea ce doresc oamenii şi ceea ce doresc managerii lor (pentru oameni) în termeni de nevoi de învăţare. Acolo unde sunt discrepanţe se poate analiza în detaliu de unde provine acea discrepanţă – unde se întrerupe comunicarea directă între manager şi angajat, foarte importantă în cadrul echipelor din IT. Însă, de regulă, cei prezenţi la întâlnire ne-au spus că nu au observat mari discrepanţe între aceste două tipuri de percepţii: IT-iştii şi managerii lor aveau cam aceleaşi tipuri de păreri despre obiectivele de dezvoltare necesare – în Fortech, de exemplu. După sondarea tuturor acestor opinii, este mult mai sănătos să organizezi orice formă de training / dezvoltare bazându-te pe rezultatele survey-ului – tendinţa de respingere va fi mult mai mică. Aceste survey-uri îţi pot oferi informaţii valoroase, dar uneori generice: poţi afla „chunk-uri” mari (= categorii mari de domenii de dezvoltare), pattern-uri dorite în organizaţii (susţine Răzvan Voica), nu însă şi nevoi punctuale, personalizate. De aceea, o cale de conştientizare şi implicare în stabilirea în detaliu a nevoilor de dezvoltare – complementară surveyului poate fi sistemul de management al performanţei dintr-o organizaţie. În iQuest de exemplu, sistemul – pomenit şi în articolul anterior – de „career management” este din start prevăzut şi cu obiectivul de a ajuta la dezvoltarea angajaţilor, nu doar de a evalua performanţele. Astfel, se pot obţine informaţii şi conştientizări despre nevoi de dezvoltare „la cald”, deoarece managerul care conduce discuţii lunare cu angajaţii este ca şi un coach pentru aceştia, oferindu-le suport şi ghidare în dezvoltare lor. De asemenea, atunci când, cel puţin o dată pe an, fiecare angajat are şi ocazia unei evaluări de tip 360grade, cresc şansele ca nevoile de dezvoltare reale să fie acceptate de cel care beneficiază de un feedback atât de complex. În cazul tuturor acestor sugestii de abordare a procesului de dezvoltare şi de alcătuire a planului de training-uri într-o

companie de IT, principiul central este cel al transparenţei – valorizat explicit şi în Fortech. Oamenii din IT – poate mai mult decât în alte industrii – au nevoie de claritate şi argumente, „trebuie să ştie de ce au fost selectaţi pentru un curs” pentru a obţine angajamentul lor real în procesul de dezvoltare (Alexandra Bayer). Tendinţa oamenilor din IT de a respinge o formă de dezvoltare este şi mai accentuată în cazul domeniului de „softskills”. Este uşor de înţeles de ce: IT-iştii sunt oameni tehnici care operează uşor cu informaţii exacte şi cu calculatoare. Atunci când vine vorba de relaţionare interumană, comunicare interpersonală, informaţii extrem de variate legate de natura umană – lucrurile nu mai sunt aşa exacte şi oamenii din HR se confruntă cu o provocare suplimentară în a „vinde” nevoia de dezvoltare şi pe această arie. În acest caz, cele mai de succes strategii sunt discuţiile cât mai apropiate, repetate cu oamenii despre importanţa acestor abilităţi în muncă, în lucrul în echipe şi în relaţionarea cu clienţii. Cele mai de impact mesaje însă nu vor fi neapărat cele care vin de la HR, ci vor fi cele care vin de la persoane recunoscute, apreciate în acea organizaţie (în mod oarecum ciudat, aceste persoane sunt recunoscute pentru competenţelor lor tehnice şi de business, competenţe „hard”). Cu alte cuvinte: oamenii din IT vor crede că softskills-urile sunt importante, dacă cei mai competenţi dintre ei pe hard-skills-uri le vor spune acest lucru! Practic, dacă liderii competenţi din organizaţie vor practica şi „propovădui” învăţarea şi pe partea de relaţionare interumană, comunicare, lucru în echipă, atunci angajaţii din acea companie vor accepta mult mai uşor să participe la astfel de forme de dezvoltare. Legat de folosirea de forme de dezvoltare inteligente pentru oamenii inteligenţi din IT, Monica David, de exemplu, susţine clar ideea că training-ul / conferinţa / workshop-ul la care participă un angajat din IT trebuie să aibă o componentă direct aplicativă care să dea rezultate imediate – altfel, IT-iştii vor semnala imediat inutilitatea. Răzvan Voica şi Cosmin Molnar din iQuest susţin această idee şi ne-au împărtăşit experienţa din compania lor din ultimii ani când au început să caute forme de dezvoltare cât mai valoroase şi care să poate fi absorbite cât mai natural în organizaţie. Practicile care s-au dovedit de succes au fost pe de-o parte, aducerea de furnizori / traineri cu renume (a căror calitate nu mai era necesar să fie testată, fiind recunoscuţi pentru aceasta) şi, pe de altă parte,

www.todaysoftmag.ro | nr. 13/Iulie, 2013

HR SPRE COMUNITATEA IT – via HR (II) conceperea unor programe de dezvoltare de mai lungă durată. Training-urile simple au fost completate cu sesiuni de follow-up la câteva săptămâni sau luni de zile care cresc probabilitatea ca lucrurile discutate în training să fie aplicate / reamintite şi să determine rezultate concrete. Şi acest lucru este valabil mai ales în cazul soft-skills-urilor care au nevoie de timp pentru a se vedea rezultate palpabile. În Recognos, până în prezent, s-a aplicat mai mult tehnica training-urilor interne care sunt foarte bine primite în rândul angajaţilor, săptămânal adunând un număr mare de developeri, atât juniori, cât şi seniori. Continuitatea acestor sesiuni de training arată interesul real de a acumula şi a învăţa tehnologii şi tendinţe noi în acest domeniu care este într-o continuă schimbare.

Modalităţi de construire şi menţinere a echipelor de lucru performante

Lucrul în echipe este cea mai uzuală modalitate de organizare în companiile de IT. Mai mult decât atât, constituirea echipelor este de cele mai multe ori o provocare pentru HR-i şi liderii de echipă, deoarece echipa trebuie să obţină rezultate şi să lucreze bine împreună rapid, chiar dacă e proaspăt formată. Timpul scurt în care trebuie să atingă performanţe este clar o particularitate în domeniul IT. În plus, gradul de fluctuaţie şi dinamica într-o echipă din domeniul IT – cel puţin pe piaţa Clujului – poate fi foarte mare. Oameni noi pot intra în echipe frecvent, ceea ce aduce aproape întotdeauna echipa la o nevoie de readaptare permanentă. De aceea, am dezbătut împreună cu participanţii la acest workshop cum se poate depăşi această provocare pentru echipele din IT. O echipă performantă şi matură în IT este o echipă care obţine rezultate în primul rând, dar care şi lucrează bine împreună; este o echipă care reflectă cultura companiei din care face parte şi este compusă din toată diversitatea de roluri şi personalităţi necesare. Ai şi oameni creativi, dar şi persoane bune executante şi finalizatori; există şi buni organizatori, şi buni comunicatori etc. . De asemenea, o echipă sănătoasă este o echipă care are un mecanism natural de „auto-curăţare”, prin care membrii care nu se potrivesc culturii şi stilului de lucru în echipă pot ieşi din echipă atunci când performanţa lor devine o piedică pentru întreaga echipă. Acest mecanism este important pentru ca activitatea echipei să

nu se blocheze. Cosmin Molnar de la iQuest consideră că cea mai eficientă metodă de constituire a unei echipe performante în IT este alcătuirea ei dintr-un mix bine ponderat de seniori (sau mai vechi în companie), midlevel developeri/ testeri şi juniori. Procentul poate fi diferit în funcţie şi de ceea ce îţi poţi permite ca alocare de resurse, însă prezența celor mai experimentaţi este vitală din cel puţin două puncte de vedere: 1) competenţele tehnice ale membrilor seniori se pot transfera mai rapid, prin mentorat, celor juniori; 2) oamenii cu mai multă vechime din companie pot asigura o infuzie rapidă de modalitate de lucru acceptată şi valorizată în companie – o infuzie de cultură, de fapt. Prezenţa seniorităţii într-o echipă nouă are avantajul recunoaşterii din partea celorlalţi membri care vor urma track-ul gândit de seniori, făcând mai rapidă obţinerea de rezultate bune. Această soluţie a fost susţinută şi de ceilalţi participanţi la workshop, Alexandra Bayer adăugând faptul că, din experienţa Fortech-ului nu a fost nevoie de un procent prea mare de seniori, ajungând câteva persoane mai vechi la o echipă de angajaţi noi. De asemenea, ea a accentuat importanţa procesului de „on-boarding” / inducţie a noilor veniţi într-o echipă deja formată. Acest proces este foarte important să fie făcut rapid, eficient şi să conţină atât elemente tehnice cât şi de conduită a muncii. Pe anumite proiecte mari, de lungă durată, în Fortech s-au realizat video-tutoriale care erau obligatoriu de parcurs de noii veniţi în acele echipe şi care ajutau mult procesul de eficientizare a echipei. În cazurile de constituire a unei echipe total nouă, cu oameni noi şi în care nu există posibilitatea de a folosi resurse umane mai vechi din companie (de ex., o filială a companiei în alt oraş, sau o echipă pentru un client / produs total nou), prioritatea celor de la Resurse Umane, împreună cu managementul companiei ar trebui să fie infuzia de cultură organizaţională. Acest lucru se poate face prin diverse sisteme de tipul „tutorilor”, „buddy system”, „mentor” în care fiecare nou angajat este preluat de un angajat mai vechi (din altă echipă) pentru a-l ajuta în procesul de inducţie, mai ales în a-i transmite acel cod despre „cum se lucrează la noi în firmă”. De asemenea, oameni mai vechi în companie trebuie să fie cât mai prezenţi în vizite la noua echipă, să-i ajute cu sisteme, proceduri de lucru pentru a deveni cât mai rapid funcţională. Un test că procesul de creare a unei echipe

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

total noi a reuşit (dincolo de rezultatele palpabile) este ca atunci când te duci în vizită la acea echipă să simţi că te afli tot în cadrul aceleiaşi companii, nu într-o altă organizaţie. O metodă rapidă şi des utilizată în companiile de IT pentru creşterea gradului de coeziune reciprocă într-o echipă este şi celebrul „team-building”. Dar şi aici sunt câteva particularităţi în cazul IT-iştilor care trebuie respectate pentru ca rezultatul acestor ieşiri să fie reuşite. Pe lângă implicarea membrilor echipei în alegerea tipurilor de activităţi dorite, a locaţiei, a serviciilor, este important ca activităţile planificate într-un team-building să îi ghideze pe participanţi să facă lucruri împreună! Degeaba îi trimiţi pe banii companiei la Barcelona, trei zile, dacă acolo fiecare va face ce-şi doreşte individual sau pe „bisericuţe”. Este important ca membrii echipei să facă activităţi împreună la care să le găsească un sens şi să fie atractive pentru ei. În unele situaţii ajută destul de mult să existe facilitatori care să analizeze puţin comportamentul participanţilor în diverse activităţi, să-i ajute să-şi dea feedback reciproc şi să conştientizeze aportul individual la rezultatul echipei – însă părerea celor prezenţi la workshop a fost că procentul şi profunzimea acestor discuţii trebuie să fie rezonabilă, deoarece oamenii din IT se pot simţi mai uşor invadaţi dacă se intră în analize prea personale. *** După cum putem vedea din aceste păreri ale oamenilor care se ocupă de oamenii din IT, angajaţii din această industrie au o serie de particularităţi legate de experienţa de viaţă, stil de abordare a lucrurilor, inteligenţă, modalitate de lucru, context economi, care trebuie neapărat luate în calcul atunci când dorim să ne gândim la practici eficiente în organizaţiile de IT. Suntem nerăbdători să ajungem şi la momentul în care vom dezbate cum toate aceste particularităţi – provocări depăşite mai mult sau mai puţin în interiorul fiecărei organizaţii în parte – pot fi luate în calcul în contextul nevoii de constituire a unei comunităţi mature de IT în Cluj… O comunitate în care inovaţia, eficienţa, calitatea, seriozitatea să fie atuurile care să consolideze o imagine a Clujului în ochii clienţilor din toată lumea ca „acolo unde sunt cei super-inteligenţi, care lucrează bine în IT, la care merită să ne ducem”. Merită să ne batem capul?

TODAY SOFTWARE MAGAZINE Monica David (Arobs Transilvania Software) – psiho-pedagog de profesie, şi-a început cariera în HR în 2008, direct întro companie de IT veche pe piaţa Clujului (Brinel), iar de curând ocupă poziţia de HR Coordinator în Arobs. Înainte de a încerca domeniul privat, a acumulat experienţă valoroasă în domeniul ONG-urilor, unde a învăţat un mod de lucru structurat – al finanţatorilor străini. Comparând mediul privat cu cel non-profit găseşte o mare provocare în ambele: lucrul cu oamenii. Glumind spune că principala diferenţă este că, dacă în ONG-uri lucra cu categorii „defavorizate”, acum, în mediul IT, lucrează cu categorii „favorizate”!

domeniul Resurselor Umane a fost dificilă şi foarte provocatoare pentru el. De când este în iQuest a iniţiat şi dezvoltat foarte multe sisteme şi procese interne de management al Resursei Umane de care ar fi în stare să povestească cu mândrie şi pasiune câteva ore!

Cosmin Molnar (iQuest) psiholog de profesie, are o experienţă de 7 ani în domeniul Resurselor Umane, trecând prin aproape toate tipurile de companii: automotive, producţie, distribuţie, HR şi acum, IT. Având aceste experienţe în industrii diferite poate să analizeze foarte obiectiv profilul angajatului din IT şi diferenţele specifice. În iQuest este responsabil de proAlexandra Bayer (Fortech) a început vocarea cea mai grea a oamenilor de HR munca în domeniul IT în urmă cu 7 ani, din IT: recrutarea şi selecţia de personal… când a devenit membră a echipei Fortech. îi dorim succes! Practic, a crescut odată cu compania şi a învăţat alături de colegii ei din conducere Andrea Chaimovits (Recognos) este cum să câştige încrederea oamenilor din o angajată fidelă – din 2007 – a compaIT: cu argumente logice, concrete, statistici. niei cu tradiţie în Cluj: Recognos, trecând Profesia de bază de inginer a ajutat-o mult prin diverse poziţii în organizaţie: tehnice, în această abordare structurată a activităţi- administrative şi acum resurse umane lor de Resurse Umane. Chiar şi acum, când – completând, în această ultimă poziţie în Fortech sunt aproape 300 de angajaţi, expertiza printr-un masterat de specialitate. Alexandra se vede ca un ajutor pentru toată A trecut, odată cu compania Recognos, compania, ca având „ochi şi urechi” pentru prin schimbările specifice datorate creşterii toţi, deşi devine din ce în ce mai dificil la de la o companie mică la una din ce în ce această dimensiune a companiei. mai mare. Având aceste experienţe directe în companie poate să înţeleagă mai multe Răzvan Voica (iQuest) are un backgro- puncte de vedere şi nevoile colegilor ei. und „vechi” în IT (din 1997), având o diversitate mare de experienţe profesionale, inclusiv ca şi programator. Din 2011 a ajuns în echipa de management a companiei iQuest – unul din jucătorii importanţi pe piaţa IT-ului din Cluj (şi nu numai). Recunoaşte că această poziţie de management în

www.todaysoftmag.ro | nr. 13/Iulie, 2013

interviu

Interviu cu Peter Lawrey

sisteme cu perfomanță ridicată în Java

ună, tuturor! Sunt Attila, pentru Today Software Magazine și astăzi îl am cu mine pe Peter Lawrey. Peter, îți multumesc că ai acceptat să ne oferi acest interviu în care vom vorbi despre performanța Java. Te rog să te prezinți. [Peter] Da. Mă numesc Peter Lawrey, sunt consultant Java în domeniul low latency. Am un blog bine cunoscut, numit „Vanilla Java”, care are aproximativ 120.000 de accesări lunar; am de asemenea și o bibliotecă numită „Chronicle” pentru low latency persistence IPC și stocare de date și sunt al treilea din StackOverflow pentru Java. Când oamenii se gândesc la low latency / performanță crescută, de obicei spun lucruri cum ar fi „C++ este mai bun”, referindu-se în termenii limbajului de programare. Cât de important crezi că este limbajul de programare și ce alți factori influențează latency sau throughput al sistemului, în afară de limbajul de programare? [Peter] Ceea ce am descoperit este că diferite limbaje de programare pot atrage diferite stiluri de dezvoltare și dezvoltări diferite și, în mod special, dacă ai un limbaj low level cum este C++ sau C și nu ai o înțelegere prea bună în legătură cu ceea ce se întâmplă cu exactitate, este ca și cum te-ai împușca singur în picior și ai învăța rapid să te descurci. Nu ai de ales. Pe când în Java, mulți dezvoltatori sunt în mod intenționat protejați și nu este nevoie să cunoască toate aceste detalii și, de aceea, nici nu o fac, ceea ce este în general un lucru bun, cu excepția momentului în care vrei să fi capabil să programezi în low latency și ai nevoie să înțelegi mai bine ceea ce face codul cu adevărat. Așa că nu putem spune că nu se poate cu Java, ci mai degrabă că nu există atât de mulți dezvoltatori Java care să aibă respectivul set de aptitudini, iar în C++ ești oarecum obligat să ai acel set de aptitudini – nu vei supraviețui dacă nu. Bibliotecile pot face de asemenea diferența, dar cel mai mare avantaj pentru Java este faptul că atât de multe dintre bibliotecile comune de care este posibil să ai nevoie, sunt încorporate, pe când în C++ trebuie să apelezi la biblioteci terțe pentru a face multe din aceleași lucruri. Deci crezi că este fondată opinia generală conform căreia C++ este mai rapid sau că limbajele compilate sunt mai rapide decat Java, sau este doar un mit? [Peter] În teorie, C++ este întotdeauna mai rapid. În teorie. Numai că, în practică, ai resurse limitate, ai timp limitat, expertiză limitată și ai cerințele care se schimbă și, într-un astfel de mediu, ceea ce se poate întâmpla este să nu ai suficient timp pentru

a micro-optimiza fiecare bucățică mică. Nu poți regla fin totul, deoarece datele devin greu de gestionat. Deci, dacă avem la dispoziție o săptămână sau o lună, un dezvoltator care este la fel de competent în ambele limbaje, va produce oarecum aceeași performanță. Dar dacă, în schimb, dai aceluiași dezvoltator un an pentru a rezolva aceeași sarcina, va fi mai rapid în C++. Și când vezi bibliotecile care sunt în mod special mai rapide în C++ și C, sunt probleme ușor de înțeles, care nu se schimbă prea mult și care sunt tuned to death, lucruri precum procesarea video, operațiuni matrice, genul de operațiuni care au existat de foarte mult timp, care implică un impuls foarte mare, coduri simple repetate de multe ori, și în aceste situații vei găsi că C este mai rapid. Dar în cele mai multe aplicații comerciale, cantitatea de reglaj fin al codului pe care poți să o faci nu este așa de importantă precum performanța în ansamblu a aplicației tale și logica afacerilor tinde să se modifice în timp, iar apoi, tindem să ne gândim la mentenabilitate și rezistență și odată ce aceasta începe să se ivească și ai de înfruntat multe schimbări, atunci trebuie să dai înapoi în C++, oricum. Vei sfârși construind multe din protecțiile pe care Java ți le oferă deja, de exemplu, vei sfârși prin a avea un fel de sistem de brokering mesaje pentru a izola componentele sistemului tău, pentru a-l proteja împotriva distrugerii, de exemplu,toate acele lucruri pe care Java le va face pentru tine în mod eficient. Așa că nu există garanții că C++ ar fi mai rapid. Am lucrat într-un loc în care toate aplicațiile pentru clienți erau scrise în C++ și acestea erau less latency sensitive, pe când asigurarea tuturor fondurilor, codul sensibil la latency era scris în Java deoarece aveam un timp mai rapid de lansare pe piață și de fapt toate livrările rapide, multe dintre noile schimbări treceau în sistemul Java, pentru că pur și simplu C++ ajunsese la punctul în care era dificil de susținut. Și se tipăreau zilnic rapoarte de avarie. În loc să apară câte o

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

Peter Lawrey

excepție, întregul sistem se prabușea și repornea, iar aceste lucruri ar fi considerate inacceptabile în Java. Interesant. Deci ce sfat ai da cuiva care este programator Java și de abia începe să fie interesat de performanța sistemului său? Poate că îi interesează pe ei personal sau poate există un motiv extern, de exemplu clientul spune că sistemul este prea încet. Care ar fi primii pași pe care ar trebui să îi facă? [Peter] Cel mai folositor aspect este vizibilitatea. Ce se întâmplă în sistemul tău, unde se pierde timp, folosirea de lucruri cum ar fi profilers drept o primă etapă pentru a privi întreaga aplicație. Dar mai apoi, odată ce simți că ai înțeles ceea ce face aplicația ta, poți introduce indicatori de timp și îi poți nota, fie prin înregistrarea lor, fie folosind ceva ca și Cronica mea pentru a-i înregistra în modalitatea low latency. Aceasta iți va oferi vizibilitate cu privire la ceea ce face aplicația și iți permite să vezi unde se pierde timpul tău, cum este utilizat, iar apoi poți rezolva problemele simple, luându-le pe bucăți și făcându-le să meargă din ce în ce mai rapid. Cum am ajuns eu în spațiul low latency? Inițial am început cu o companie care nu era în mod special low latency, dar aveam acest țel de a face sistemul de zece ori mai rapid decât trebuia să fie, iar apoi, pentru următorul client și următorii oameni pentru care am lucrat, am făcut același lucru, și tot așa, iar și iar. Și cu timpul am știut de la

TODAY SOFTWARE MAGAZINE sute de milisecunde la sute de microsecunde și în final la nivel de subunități de sute de microsecunde. Așa că o poți face pas cu pas, dar am descoperit că, dacă faci un sistem care face față unui volum de zece ori mai mare decât este de fapt necesar, acesta este de obicei și foarte stabil. Deci există beneficii dacă lucrezi așa, în loc să faci mereu numai minimul. În regulă. Deci, Peter, care este lucrul tău preferat în legătură cu Java? Limbajul sau platforma? [Peter] Ceea ce îmi place cel mai mult la Java este faptul că are încorporat foarte mult din ceea ce ai nevoie, iar setul de instrumente este foarte bun și matur. Există multe limbaje noi acum, dar nu au profilers și debuggers bune și nici seturi de instrumente care să te ajute să scrii codul și analiza codului. Setul de instrumente este cu adevărat ceea ce aduce Java la viață, ca să spun așa, mai degrabă decât limbajul în sine. Parte a motivului pentru care există un set atât de bun de instrumente este că Java este un limbaj foarte sărac în caracteristici, în sensul că este foarte economic în privința caracteristicilor pe care le adaugă, dar asta înseamnă că fiecare caracteristică este bine înțeleasă, interacțiunea dintre caracteristici este ușor de înțeles și este relativ ușor pentru o aplicație să le deducă, în termeni de verificare, profilare, analizare, privire la efectele secundare și așa mai departe. Deci, datorită faptului că este un limbaj simplu în sine, setul de instrumente este în general foarte bun și te poate salva de multă muncă. Așa că multe din nemulțumirile pe care oamenii le au în legătură cu Java, lucruri precum că „este foarte prolix”, multe din ele pot fi înlăturate folosind seturi bune de instrumente. Și, cu siguranță aș recomanda oricui nu folosește un IDE cu profiler, să o facă. Și învățați să folosiți debugger-ul când încercați să vă devirusați programul și vă va salva de multe bătăi de cap. Bun. Java 8 urmează să apară și ar trebui lansat în toamnă, cred. Există anumite caracteristici care iți plac în mod special? [Peter] Cred că lucrul cel mai captivant este că sunt multe caracteristici adăugate, nu unele imense în sine, dar multe îmbunătățiri. Closures au primit cea mai mare atenție din partea presei, chiar dacă, tehnic vorbind, nu este decât o ajungere din urmă a C#. Nu s-au putut pune de acord cu privire la specificațiile pe care ar trebui să le aibă closures, așa că în final s-au mulțumit cu ceea ce face C#. Au adăugat extensii virtuale, care în interior sunt numite altfel, nu îmi amintesc, dar de ce le-au numit „extensii virtuale?” – Ei bine, așa le-a denumit C#. Deci, într-un fel, nu

este decât o ajungere din urmă a ceea ce fac alte limbaje. Dar multe dintre celelalte caracteristici – există 66 de îmbunătățiri, dintre care 3 sunt legate de closures – multe dintre ele sunt îmbunătățiri mai mici, dar se pot vedea destul de multe progrese în evoluția JVM, lucruri precum introducerea în limbaj a JodaTime’s DateTime – probabil unul dintre accesoriile cele mai populare până acum, care iți permite să folosești un DateTime potrivit, iar pentru mine, la un nivel lower, lucruri precum a avea bariere de memorie discrete adecvate. Unsafe are o barieră de memorie de încărcare (force load)/ depozitare (force store) care este explicită. În trecut, trebuia să o realizezi într-un mod indirect, utilizând alte operațiuni care aveau de asemenea aceste caracteristici, pe când acum poți să te ocupi de ele în mod explicit. Dar aceasta este o caracteristică foarte low level. Există alte caracteristici pe care ai dori să le vezi în Java și nu sunt incluse în Java 8? [Peter] Probabil cel mai important lucru pe care aș dori să îl văd îmbunătățit este, din cauză că folosesc Unsafe destul de mult, nu adăugarea unei caracteristici, ci de fapt includerea ei ca parte a specificației. Există multă funcționalitate în Unsafe care este utilizată în Chronicle și Disruptor și alte biblioteci care sunt în afara specificațiilor, așa că ele există în OpenJDK și HotSpot și alte JVMuri compatibile, cum ar fi Jrocket sau Azul Zing, dar acestea nu sunt standarde. Deci, nu ar trebui să facă nimic în termeni de adăugare de funcționalitate, ci doar ar fi nevoie să transforme aceasta într-o caracteristică standard a tuturor platformelor Java. Astfel ai avea o modalitate standard de a te ocupa de accesul la memorie low level. Și asta, întro manieră lipsită de amenințare. Există resurse cum ar fi cărți, bloguri, video, cursuri de pregătire pe care le-ai recomanda programatorilor Java care sunt interesați de domeniul performanței? Există, bineînțeles, blogul tău, pe care l-ai menționat la început și vom face referire la el, dar ce alte resurse ai recomanda? [Peter] Aș recomanda să se uite pe Performance Java User’s Group, deoarece acolo postez tot ceea ce consider a fi cele mai interesante video pe acest subiect și sper să încurajez și pe alții să posteze acolo, de asemenea. Deci, cred că acesta este cel mai bun loc de pornire. Mai sunt alte două blog-uri. Scuze, nu sunt chiar blog-uri, ci forum-uri, forum-uri de email la care merită să vă uitați, și anume “The Mechanical Sympathy”, condus de Martin Thompson, care a fost CTO la L-MAX când Disruptor a fost dezvoltat, dar acesta este totuși foarte low level. Chiar cei mai mulți oameni interesați de performanța

Java nu ar putea utiliza aproximativ 99% de acolo, dar este o discuție foarte interesantă, totuși. Mai există un forum numit “Friends” la jClarity, condus de niște tipi care au dezvoltat “Well Grounded Java Developer” pentru Java 7, și anume Benjamin Evans și Martijn Verburg. Ei se concentrează foarte mult pe GC și chestiuni conexe, dar sunt foarte practici și oferă sfaturi bune și de asemenea consultanță celor interesați. Mai au și câteva produse în acel spațiu, dar acel forum este foarte interesant dacă dorești să îți îmbunătățești GC-ul. Bun. Vom include linkuri la toate acestea în secțiunea de comentarii la acest video. Mai este altceva ce ai dori să adaugi cu privire la acest subiect? [Peter] Da. Urmează să apară o nouă versiune a Chronicle, care este adăugată la o nouă organizație pe GitHub, numită OpenHFT care este o librărie open source de trading pentru concurență ridicată. Și Chronicle în sine este divizată în secțiuni: memorie, manipularea memoriei și deserializare, separate de la înregistrare, astfel încât nu trebuie să folosești înregistrarea pe disc pentru a-i utiliza caracteristicile și de asemenea a fost făcută mai eficientă, de exemplu, pe acest laptop pot primi 80 de milioane de mesaje pe secundă, trecute de la un fir la altul și asta, cu fiecare mesaj persistând. De asemenea, va avea un suport pentru rolling logs, ceea ce puteai să faci în Chronicle 1, dar mulți oameni ar fi dorit ca biblioteca să facă asta în locul lor, așa că, aceasta va fi o caracteristică adăugată la Chronicle 2. S-au mai pus și bazele unei noi biblioteci, care va încerca stocarea unor cantități enorme de date off-heap. În special în fișierele hărții de memorie, așa că va oferi caracteristici similare cu ceea ce face Terracotta’s BigData, dar în schimb, va fi limitată numai de dimensiunea spațiului tău de pe disc, mai degrabă decât de memoria principală, astfel încât să poți introduce și scoate date mai rapid și totodată să utilizezi mai puțin spațiu. Și va fi open source. Și încă ceva care urmează să apară este FIX engine care va fi bazat de asemenea în jurul Chronicle, astfel încât să poți beneficia de derivare low latency și scriere de FIX messages. Va fi bazat în linii mari pe QuickFix, cu excepția faptului că este conceput pentru a fi mult mai eficient. Attila-Mihaly Balazs dify.ltd@gmail.com

Code Wrangler @ Udacity Trainer @ Tora Trading

www.todaysoftmag.ro | nr. 13/Iulie, 2013

management

Prețul mare al lean software development

ntr-un fel cred că mereu am fost un mare fan al filosofiei lean. Chiar când nici nu știam că așa se numește. Și nu pentru că aș fi special, poate am doar un ușoară înclinare către perfecționism, dar pentru că mi s-a părut întotdeauna ca ceva natural. Probabil sunt unul dintre oamenii aceia care cred că lumea se mișcă tot timpul, chiar și când noi suntem în repaus.

Florian Ivan, PMI-ACP, CSM, PMP, Prince2 Practitioner, MVP, MCTS florian.ivan@rolf-consulting.com Managing Partner @Rolf Consulting Germany

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

Lean înseamnă mișcare. Înseamnă să accepți că, indiferent de domeniul în care te joci, nu poți fi inert. Și nu pentru vreun motiv comercial ce ține de concurența care veghează tot timpul. Sau vreunul tehnic care face ca tot ce are un chip înăuntru se evolueze major la fiecare șase luni, ci pentru că este în natura umană să evoluăm. Și, pe cât posibil, programat și controlat. Nu întâmplător, la oameni, starea de expectativă se numește lene și are conotații atât de negative. Istoria lean ne duce la începuturile industrializării, la început de secol XIX. E teorie pură dar merită. La început oamenii erau artizani. Faceau lucuri bune dar scumpe și mai ales greu de replicat. Problema: oamenii, și atunci ca și acum, vroiau lucruri ieftine și mai ales diverse. Așa a apărut nevoia de a produce în volume mari, adică producția de masă. Ce înseamnă producția de masă? Înseamnă ieftin și mult. Să se ajungă la toată lumea chiar dacă uneori calitatea este compromisă în virtutea unor alte criterii cum ar fi accesibilitatea sau funcționalități avansate. Iarăși, care este problema? Lumea de fapt ar vrea și lucruri de calitate. Dar nu se mai poate (sau a devenit foarte, foarte scump!) pentru că, între timp, ne-am resetat întreaga capacitate de producție pentru a face ieftin și mult. Și, pentru a nu rămâne prea mult în zona de teorie, să ne imaginăm, în același context, industria de software. La început, pentru a putea face software trebuia să fii estimeed engineer. Doar cei cu studii avansate de engineering și cu o bogată experiență practică puteau scrie programe pentru calculator. Sigur regăsiți printre prieteni și colegi pe cineva care să vă aducă aminte de cartelele perforate. Doar că odată cu dezvoltarea calculatorului personal și al nevoii de tehnologie, trebuia schimbată paradigma. Era nevoie de software mult, repede și ieftin. Pentru toată lumea. Sună cunoscut? Da, și

industria de software a trecut prin aceeași epocă de mass production. Cei drept, este mult mai cunoscută sub numele de offshore outsourcing dar, în esență însemnă același lucru. Să facem software mult, repede și foarte ieftin. O întreagă (și mare țară) și-a bazat strategia de IT pe acest trend așa cum o alta, și mai mare, și-a bazat strategia de țară pe a produce ieftin. Ceea ce ne duce la cea mai actuală problemă a zilelor noastre: cum facem să vindem valoare și să nu mai fim considerați niște simpli executanți de taskuri dintr-o țară pe care puțini o pot localiza pe o hartă? Lean, mai cunoscut în lumea software prin implementările sale agile sau scrum, este soluția pe care lumea industrială a descoperit-o încă de acum 50 de ani ca fiind cea mai eficientă metodă de a furniza valoare, de a fi competitivi (atenție, este foarte diferit de a fi ieftin) și de a maximiza singura resursă cu adevărat nelimitată, inteligența și creativitatea umană. Simplist, lean înseamnă să fii obsedat de valoare. Așa de mult încât să vânezi orice acțiune care nu contribuie direct la această valoare și să o etichetezi drept waste. Înseamnă oameni care să fie motivați să devină mai buni pe zi ce trece, să fie mai productivi și mai eficienți în tot ceea ce fac. Pe scurt, oameni dedicați ideii de a oferi valoare clienților lor. Pare greu? Ce-i drept nu este ușor... Pe de altă parte, care este alternativa? Să rămânem ieftini și să sperăm că în continuare vor exista clienți care vor doar ieftin, fără pretenții de calitate și, în același timp să ne rugăm ca, nu cumva, pe undeva printr-o țară cu nume greu de pronunțat, nu s-a mai trezit vreun guvern să transforme software-ul ieftin în strategie de țară. Pentru că atunci nu ne-ar mai rămâne decât să ne plângem că noi putem mai mult dar condițiile nu ne permit. Când, de fapt, ne-am uitat moștenirea genetică de a fi agili.

tendințe

TODAY SOFTWARE MAGAZINE

România, rățușca cea urâtă din lacul software outsourcing Într-o eră a globalizării, centrele tradiționale de outsourcing trebuie să-și regândească strategia avantajului competitiv.

nii ’90 au fost dominați în Europa de efectul căderii cortinei de fier. Piețele est-europene marcate de principiile economiei planificate au fost deschise către capitalism. A urmat o creștere haotică ce nu a lăsat nicio industrie neatinsă. Dacă unii mamuți precum metalurgia, siderurgia și mineritul intră la categoria perdanți, o nouă specie a luat amploare, distingându-se printre câștigători: tehnologia informației, în general, și dezvoltarea software în particular.

Mihai Nadăș mihai.nadas@tss-yonder.com CTO @ Yonder este responsabil de activitățile R&D și creșterea nivelului de inovație al produselor partenerilor Yonder.

În 1993 un programator din Cluj-Napoca câștiga aproximativ 50 mărci germane, echivalentul a 25 euro. Astăzi, cei mai buni profesioniști au așteptări ce depășesc 2.000 euro, o creștere de aproape 1.000% în mai puțin de 20 de ani. Este probabil cea mai spectaculoasă creștere salarială din economia românească modernă. În același timp, în Europa de Vest salariul net al unui programator se află în vecinătatea sumelor vehiculate în România, iar în cazul în care trendul de creștere se păstrează, în câțiva ani avantajul competitiv bazat pe costul redus și poziționarea geografică convenabilă (i.e. nearshoring) vor păli în fața unor destinații precum Ucraina, Serbia, Rusia sau tradiționala India. Acest context de forțe obligă companiile de outsourcing din România să gândească diferit când vine vorba de strategia lor și să-și diversifice portofoliul de servicii pentru a justifica prețul semnificativ mai ridicat decât în urmă cu 10 ani. Cu alte cuvinte, companiile de outsourcing trebuie să se reinventeze, să inoveze pentru a rămâne competitive într-o piață globalizată, într-o lume plată, cum o numea Thomas L. Friedman în The World is Flat.

Proiectele software, pe de altă parte, reprezintă eforturi de optimizare a unor procese de business prin software, secundare din perspectiva strategiei companiilor ce le finanțează și le regăsim de cele mai multe ori sub forma unor inițiative interne, punctuale ale unor departamente care-și proiectează propriul sistem software pentru a-și face munca mai ușoară (e.g. sistem intern de gestiune a rezervărilor unui tur-operator) sau ale unor site-uri web de prezentare. Această distincție este importantă, deoarece, dacă obiectivul este creșterea valorii pe care România o aduce prin outsourcing, atunci efortul trebuie concentrat pe zona în care impactul este cel mai mare, iar din acest punct de vedere pariul trebuie făcut pe produsele software și felul în care outsourcing-ul românesc poate crea valoare în această zonă. “Proiectele”, așa cum sunt introduse mai sus, sunt prin definiție de impact redus și, prin urmare, dispuse la outsourcing bazat pe cost redus, zonă în care companiile de outsourcing din România intră în competiție cu destinații mai ieftine, erodându-și astfel potențialul de avantaj competitiv.

Proiecte Software vs. Produse Software

Valoarea este dată de adresarea unor nevoi, iar dacă impactul cel mai mare pe care companiile de outsourcing îl pot crea se află în sfera companiilor de produse software atunci înțelegerea nevoilor acestora este primul pas ce trebuie făcut. În esență, din această perspectivă putem discuta de două mari nevoi: nevoia de adaptare la schimbare și nevoie de predictibilitate în livrare. Nevoie de adaptare la schimbare se referă

Aș vrea să disting între două mari categorii software: proiecte și produse. Când vorbim despre produse mă refer la Microsoft Office, Google Search, Salesforce.com, Skype, Evernote sau Dropbox. Acestea reprezintă elementul central din strategia companiilor care le produc, au impact pe scară largă și sunt folosite de mii, milioane și uneori chiar miliarde de utilizatori.

Nevoile unei companii de produse software

www.todaysoftmag.ro | nr. 13/Iulie, 2013

tendințe România, rățușca cea urâtă din lacul software outsourcing la faptul că trăim într-o lume în care singura constantă e schimbarea. Cerințele din piață se schimbă, concurențala fel și nu în ultimul rând tehnologia se schimbă într-un ritm tot mai alert. Iar dacă privim tehnologia în particular putem observa cum pentru o companie de produs pierderea unui ciclu de inovație (unde prin inovație înțeleg adaptarea la noi tehnologii și tendințe tehnologice) poate destabiliza decisiv poziția sa pe piață. O companie de produs medie nu-și permite să investească prea mult în inovație, motiv pentru care riscul din această perspectivă și prin urmare nevoia sunt ridicate. Nevoie de predictibilitate în livrare ține de profesionalism. Vorbim de livrarea la timp, conform standardelor de calitate agreate și în bugetul stabilit. Este un domeniu vast în care inițiative precum Capability Maturity Model Integrated (CMMI), un model dezvoltat de Software Engineering Institute (Carnegie Mellon University), caută să descifreze o problemă complexă. Lipsa de predictibilitate în livrare este, din nou, un factor de risc ce, nu o dată, a scos din joc companii de produs (e.g. Netscape).

Un model funcțional

Schimbarea pornește de la viziune, însă viziunea în sine nu produce schimbare. Schimbarea are nevoie de modele, rezultate și dovezi. Viziunea descrisă mai sus a fost pusă în aplicare în Yonder și, de aproape 2 ani, putem vorbi de un model funcțional în care observăm cum adresarea nevoii de schimbare și predictibilitate în piața europeană a companiilor de produse software generează valoare ce ne diferențiează și oferă perspective complet noi de dezvoltare față de modelul tradițional de outsourcing bazat pe costuri mici și valoare adăugată scăzută. Dincolo de eforturile pentru adresarea

Este un moment ce marchează nu doar trecerea de la o atitudinea reactivă către una proactivă în outsourcing-ul autohton, ci și o implementare a unei viziuni ce prezintă o alternativă clară și funcțională la modelul actual în spatele căreia se găsesc deja o serie de studii de caz de succes.

Concluzii

nevoii de predictibilitate concretizate prin certificări precum CMMI și schimbarea structurii organizaționale, evenimente ce au avut loc în 2012, anul acesta am marcat un nou moment prin lansarea unui material ce concentrează viziunea noastră asupra nevoii de adaptare la schimbare a companiilor de produse software. Intitulată “The Innovation Roadmap of Successful Software Product Companies 1”, lucrarea prezintă un model de inovație pe care companiile de produse software trebuie să-l adopte pentru a rămâne relevante în piață pe termen lung și descrie pe larg patru tendințe pe care credem că acestea trebuie să le considere în momentul în care-și definesc planurile de dezvoltare a produselor sale. Cele patru tendințe identificate sunt: 1. Contextual, Social and Modern User Interfaces, 2. Mobile-Centric User Applications, 3. Cloud Computing: IaaS, PaaS, SaaS, 4. Big Data and Next Generation Analytics.

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

1 http://tss-yonder.com/latest-news/downloads/

Pe 11 noiembrie 1843 Hans Christian Andersen publica o poveste despre transformarea în bine, încredere și perserverență. România, ca destinație de outsourcing, se aseamănă cu povestea semnată de autorul danez însă spre deosebire de rățușca din narațiune, care a beneficiat de pe urma moștenirii genetice asistând la un proces de transformare fatalist, outsourcing-ul românesc trebuie să-și determine propriul fenotip pentru a trece la următorul nivel de maturitate. La fel cum companiile de produse software au nevoie de inovație pentru a rămâne relevante pe termen lung, în aceeași măsură putem vorbi și de companiile de outsourcing autohtone unde adoptarea unei viziuni și a unei strategii bazate pe valoare adăugată va face diferența à la longue.

Referințe 1. tss-yonder.com/vision 2. innovation.tss-yonder.com 3.http://www.youtube.com/ watch?v=c1AsihGwuxU)

TODAY SOFTWARE MAGAZINE

programare

Migrare website MVC 3 și DB în Azure (II)

ncep cu un scurt rezumat al articolului precedent: Se dădea o arhitectură „clasică” de web: un portal dezvoltat în ASP.net MVC (3 şi 4) având în spate o bază de date ce rula pe MS SQL server ascunsă de Entity Framework.

Dragoș Andronic

dragos@txtfeedback.net CTO @ TXTFeedback

date. În primul rând trebuie să vedem dacă SQL Azure şi SQL Server sunt compatibile – ce se poate migra, ce trebuie schimbat şi ce nu se poate migra. Un loc bun de documentare este Windows Azure General Guidelines and Limitations 1. Dacă lucraţi cu o bază de date enterprise trebuie să parcurgeţi tot articolul, dacă nu atunci ajunge să ştiţi că următoarele nu sunt suportate de

Aceasta arhitectură trebuia pregatită de „scalare” – trecută pe un sistem ce permitea SQL Azure: deservirea unui număr mare de request-uri. • Proceduri stocate ce folosesc mai multe După ce am analizat mai multe opţiuni de baze de date (cross db stored procedures) upgrade a arhitecturii (discursul logic poate – dacă aveţi un astfel de scenariu atunci fi revăzut în articolul precendet) ne-am decis trebuie să mutaţi join-urile la un nivel asupra SQL Azure şi Windows Azure ca platsuperior (e.g. LINQ); formă de migrare. • Tranzacţii pe operaţii ce folosesc mai În articolul curent vom descrie pas cu multe baze de date (automatic transactions pas cum exact am făcut migrarea, ce tooling on operations across multiple databases) am folosit şi ce probleme au apărut sau pot – la fel ca mai sus, va trebui să mutaţi sinapărea. cronizarea & procedura de rollback la un nivel superior de abstracţiune; Baza de date • SQL Server agent sau SQL server jobs – Baza de date era ascusă în spatele Entity SQL agent lipseşte cu desavârşire din SQL Framework – aceasta ne uşurează consideraAzure aşa că va trebui să mutaţi toată logica bil munca, unul dintre scopurile unui ORM într-un serviciu exterior ce va fi executat fiind exact transparenţa în alegerea bazei de 1 http://msdn.microsoft.com/en-us/librar y/windowsazure/ee336245.aspx

www.todaysoftmag.ro | nr. 13/Iulie, 2013

programare Migrare website MVC 3 și DB în Azure (II) periodic (de exemplu să creaţi un thread pe un Azure WebRole). Mai multe soluţii alternative sunt dezbătute aici2 • Tabele fără index tip cluster (tables without clustered indexes) – partea bună e ca pe fiecare tabel se poate adăuga un index de tip cluster fără probleme. Dacă vă întrebaţi de ce există această limitere citiţi acestarticol3. Pentru a afla rapid dacă baza noastră de date este compatibilă cu SQL Azure putem folosi unul din tool-urile de migrare şi încercând migrarea propriu-zisă – în caz de incompatibilitate, toate tool-urile ne vor da un raport detaliat.

Cum decurge procedura de migrare: 1. Selectăm din Management Studio baza de date ce dorim să o migrăm şi selectam din Tasks -> Deploy database to Azure. 2. Selectăm numele bazei de date pe care dorim să o creem + serverul de Azure unde dorim să rulăm baza de date (serverul va trebui creat în prealabil în windows azure management dashboard4 ). Notă: dacă deja am mai creat baze de date în Azure, wizard-ul are prostul obicei de a seta în Connection Properties la „Connect to database” baza de date ce a

Tooling migrare

Se poate folosi pentru a migra baza de date în SQL Azure? 1. SQL Management Studio 2012 (SSMS) – neapărat versiunea 2012 (sau mai nouă) pentru că în această versiune a fost introdus un task special pentru migrarea în Azure. Dacă nu aveţi licenţa de SSMS atunci puteţi folosi varianta Express. 2. RedGate SQL Toolkit – ca grad de complexitate şi utilitate e comparabil cu SSMS. Şi pentru SQL Tookit veţi avea nevoie de licenţă – în funcţie de preferinţe şi necesităţi echipa voastră va avea (probabil) ori SQL Toolkit ori SSMS. 3. SQL Azure Migration Wizard – disponibil pe codeplex, e alternativa free (dar nu mai puţin bună) la migrare. Noi am folosit SQL Management Studio 2012 (ca membru în Bizspark avem acces gratuit la SSMS)

2 h t t p : / / b l o g s . m s d n . c o m / b / s q l a z u r e / archive/2010/07/30/10044271.aspx 3 h t t p : / / b l o g s . m s d n . c o m / b / s q l a z u r e / archive/2010/05/12/10011257.aspx

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

fost creată anterior. Cum noi dorim să creăm o nouă bază de date trebuie să ne asigurăm că acolo e trecut „default” – în caz contrar o eroare va fi semnalată în raportul de migrare 3. Dăm drumul la procedura de migrare şi citim Logul migrării – aici vor fi semnalate eventualele incompatibilităţi. În cazul nostru am scăpat uşor: singura problemă era că nu toate tabelele aveau indecşi tip cluster-a trebui să îi adăugăm

manual pe fiecare tabelă. Operaţiunea 4 http://www.manage.windowsazure.com

aceasta se poate face uşor tot din SSMS. 4. După ce am rezolvat toate incompatibilităţile se repetă pasul 1

Verificare şi validare

După ce am migrat baza de date, ca să verificăm corectitudinea migrării schimbăm connection string-ul în proiectul ce foloseşte baza de date veche. O dată redirecţionat către SQL Azure totul ar trebui să funcţioneze fără ca nici o altă schimbare să fie necesară.

Note finale Cam atât despre migrarea bazei de date. Dacă întâmpinaţi probleme la migrare, sau aveţi întrebări mă puteţi contacta direct la dragos(at)txtfeedback.net În urmatorul articol voi detalia cum am transferat arhitectura si structura de websiteri/directoare virtuale in Azure.

programare

TODAY SOFTWARE MAGAZINE

Hadoop (III)

n numerele trecute am descoperit lumea pe care Hadoop o formează. O lume în care fișierele de 100GB sau 500GB sunt la ordinea zilei. Acesta ne permite să facem lucruri pe care nu le puteam face până acum.

Radu Vunvulea

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

Când?

Costuri

Datele pe care firma noastră le colectează pot să devină o mină de aur. Putând prelucra cantități mari de date, avem posibilitatea să vizualizăm datele într-un mod pe care nu l-am putut face până acuma. Prima întrebare pe care trebuie să o punem când dorim să analizăm datele cu Hadoop este: Ce dorim să analizăm? Răspunsul la această întrebare este important, deoarece trebuie să identificăm ce vrem să facem cu datele, ce informație dorim să analizăm și care este valoarea acestor date. Un scenariu simplu, este identificarea profilului unui utilizator. Putem astfel să recomandăm sau sa facem reclamă la diferite produse. Totodată prin folosirea unui sistem ca Hadoop putem să creăm un mecanism de identificare a fraudelor, prin selectarea excepțiilor de la șabloanele cunoscute.

În comparație cu restul soluțiilor care sunt pe piață, Hadoop vine cu costuri extrem de mici. Acesta nu are nevoie de hardware special pe care să ruleze. Poate să funcționeze fără nici un fel de probleme pe orice sistem, chiar dacă acesta este laptopul de acasă, server-ul de la lucru la mașina de 500.000 de euro pe care clientul a cumpărat-o. În funcție de task-ul pe care dorim îl facem un job poate să dureze de la câteva minute până la ore sau zile. Hadoop nu are nici o constrângere din acest punct de vedere, putând rula un job zile întregi fără nici un fel de probleme. Prin abstractizarea mediului unde rulează și modului în care Hadoop este construit, se permite să facem un lucru care nu poate să fie pe orice fel de sistem de acest fel. Scalabilitatea este liniară. Aceasta înseamnă că dacă dublăm numărul de noduri o să

www.todaysoftmag.ro | nr. 13/Iulie, 2013

management

programare Hadoop (III) putem înjumătăți timpul de analiză. În acest mod putem să pornim cu o configurație simplă, iar dacă volumul de date creste, putem să creștem și numărul de noduri. Datorită acestei proprietăți, există mulți furnizori de cloud care oferă acest serviciu. Orice furnizor de cloud poate să își folosească mașinile pe care le are pentru a rula Hadoop și să scaleze numărul de mașini în funcție de necesitățile pe care clientul le are. O povestioară destul de interesantă este cea a lui Pete Warden care a folosit Hadoop pentru a analiza profilul a 220 de milioane de utilizatori a Facebook. Acest lucru a luat doar 11 ore, iar costul a fost extrem de mic. Vă întrebați oare cât de mic? Costul final a fost de 100$. Acesta este exemplul perfect unde Hadoop își poate face treaba bine și cu costuri minime.

Cum? Așa cum am văzut și până acuma, arhitectura Hadoop este simplă, bazându-se pe HDFS – Hadoop Distributed File System și MapReduce. HDSF este în stare să împartă, distribuie și să facă management la date foarte mari. Toate aceste date, odată stocate în Hadoop pot să fie procesate folosind MapReduce. În momentul în care datele sunt procesate, Hadoop nu trimite datele la nodurile care se ocupa cu procesarea. Fiecare nod din sistem care stochează datele urmează să proceseze datele pe care le stochează. În acest fel, analiza datelor se face mult mai repede, iar sistemul este mult mai scalabil.

Operația de MapReduce este o operație care se desfășoară în doua faze. În prima fază, operația de Map rulează pe fiecare nod în parte. A doua faza de analiză, care poartă numele de Reduce este opțională. Toată logica pe care noi o scriem – modul în care analizăm datele, stă in operațiile de Map și Reduce.

Limbaj Logica pe care trebuie să o scriem pentru a putea scrie procesele de analiză poate să fie scrisă în diferite limbaje. Ce nu trebuie să uităm este că limbajul în care Hadoop a fost scris este Java. Din această cauză chiar dacă putem să folosim și alte limbaje în afară de Java,

cea mai bună performanță o vom obținem Pig și Hive folosind Java. De exemplu dacă folosim În cazul în care nu sunteți dezvoltatori Streaming API s-ar putea ca performanța și nu știți nici un limbaj de programare să scadă cu până la 20%. nu înseamnă că nu puteți să vă definiți operațiile de Map și Reduce. Prin folosirea Environment Pig si Hive orice persoană fără cunoștințe de programare poate să îți definească propriile reguli. Hive se bazează pe un limbaj numit HiveQL. Acesta este extrem de asemănător cu SQL. Iar tot ce trebuie să facă o persoană este să își definească un query de felul: SELECT * FROM CARS WHERE type = ‘BMW’ AND value > 30000

Dacă dorim să ne configurăm un sistem Hadoop, trebuie să fim pregătiți să folosim Linux. Chiar dacă acesta rulează fără nici un fel de probleme de Windows, inițial Hadoop a fost făcut să ruleze pe Linux. Cunoștințele de Linux ne vor fi folositoare în momentul în care trebuie să configurăm acest sistem. Sub Linux, Hadoop rulează pe o versiune de Linux derivată din Ubuntu și RedHat. Aceasta poartă numele de CDH – Cloudera Distribution of Hadoop. O soluție pe care o recomand la acest pas este folosirea unor imagini care au deja instalat și configurat acest sistem. Prin acest mod, în 10 minute putem să avem deja un sistem funcțional și pregătit pentru lucru.

Hive se va ocupa de translatarea acestui query în job-uri pe care Hadoop poate să le execute. Pig este destul de asemănător cu Hive. Acesta folosește un limbaj propriu denumit PigLatin. PigLatin este un limbaj simplu, cu operații precum FOREACH, comparare de valori și funcții de SQL precum MAX, MIN, JOIN, etc. Acesta translatează comenzile pe care le primește în comenzi de tip MapReduce. Ambele sisteme sunt ușor de folosit și de optimizate. Pentru cei care nu sunt dezvoltatori, folosirea la Pig sau Hive este o opțiunea mult mai bună decât învățarea unui limbaj de la zero.

Dezvoltare

Concluzie

Dacă suntem la faza de development atunci nu este recomandat să rulam codul direct pe un sistem real, deoarece procesul de debug poate să fie extrem de anevoios. În primă fază, putem să folosim Local Jobrunner Mode, care ne permite să rulăm teste de dimensiuni mici și să facem debug pe operațiile de tip Map și Reduce. Odată ce avem un cod funcțional, putem să trecem la următorul pas și să folosim Pseudo-Distributed Mode. Acest mod replica mediul real dar ne oferă câteva funcționalități pentru debug. Dacă am trecut și de acest pas cu bine, atunci putem să facem pasul final și să trecem la următorul mod Fully-Distributed Mode. Aceste este mediul nostru real, cel de producție. Prin dezvoltarea și rularea codului în cele trei moduri, costul de dezvoltare scade, iar numărul de bug-uri pe care le găsim va fi mare. Stilul de programare pe care trebuie să îl aplicam în momentul în care folosim Hadoop este cel de tip defensive. Trebuie să încercăm să prindem toate excepțiile cu putință și să le tratăm corespunzător. Rulând pe mai multe noduri, este nevoie să tratăm fiecare excepție cu grijă.

În ultimele trei articole din această serie am descoperit lumea Hadoop. Cum poate să stocheze și să proceseze un volum atât de mare de date. Tot ce ne-a mai rămas de făcut este să facem următorul pas și să începem să îl folosim. Vă urez succes!

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

programare

TODAY SOFTWARE MAGAZINE

Programare Funcțională în Haskell (III)

rticolul din numărul trecut a realizat o trecere în revistă a tipurilor din Haskell, atât a celor preexistente cât și modalităților prin care un programator își poate crea propriile lui tipuri. Continuăm excursia în tărâmul acestui limbaj cu o scurtă prezentare a unei alte caracteristici a sistemului de tipuri, prin evidențierea modului prin care se realizează polimorfismul în acest limbaj: clasele de tipuri. Mihai Maruseac

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

Deși noțiunile de clasă și polimorfism duc imediat cu gândul la programarea orientată pe obiecte, țineți minte că suntem în alt tărâm. Veți vedea până la sfârșitul articolului că aproprierea de OOP este destul de forțată, aici avem de-a face cu concepte total diferite. Vom începe întâi cu funcția (+). Data trecută i-am forțat tipul la Integer -> Integer -> Integer, dar este evident că astfel nu vom putea aduna două numere reale. Dacă am generaliza tipul la a -> b -> c avem două probleme: nu putem construi tipul c pornind de la a și b (dacă era un tip constant puteam alege un constructor nular al acelui tip și aveam o funcție constantă – desigur, nu e o implementare corectă pentru (+)) și putem avea și expresii de forma True + “ana are mere”. Restricționăm semnătura la a -> a -> a pentru a rezolva cele 2 probleme mai sus menționate, dar tot vom putea scrie expresia fără sens semantic dar corectă din punct de vedere al compilatorului True + False. Ar trebui cumva să restricționăm tipul valorilor din variabila de tip a la tipurile numerice. Să considerăm un alt exemplu: conversia unei valori la un șir de caractere. În Java avem funcția toString din clasa Object pe care o putem suprascrie în orice altă clasă. Numai că, spre deosebire de majoritatea limbajelor, în Haskell funcțiile sunt valori de prim ordin (sunt obiecte ca oricare altele). Dacă luăm în calcul și faptul că nu se poate scrie o funcție de conversie a unei funcții la un șir de

caractere (excluzând cazul în care returnăm un șir constant sau un șir ce ține cont doar de elemente lexicale – “function at line 42”) obținem imediat următoarea problemă: ne trebuie o funcție a -> String dar cu valorile tipurilor din variabila de tip a restricționate la acele tipuri pentru care conversia are sens. Desigur, avem și cazul invers, al unei funcții String -> a de conversie de la un șir de caractere la tipul potrivit. Putem considera și funcțiile (==) :: a -> a -> Bool, (<) :: a -> a -> Bool, etc. În fiecare caz, avem nevoie de o restricție suplimentară asupra tipurilor valorilor variabilelor de tip din semnătură. Restricții la nivelul tipurilor, nu la nivelul expresiilor tipate din program. În final, să considerăm un exemplu mai interesant: are sens să definim funcții similare map :: (a -> b) -> [a] -> [b] și pentru alte tipuri de date de tip container (arbori binari, stive, grafuri, etc.). Am prefera să generalizăm semnătura funcției în loc să definim funcții cu nume diferite pentru fiecare container. Astfel, în loc să avem mapTree :: (a -> b) -> Tree a -> Tree b și mapStack :: (a -> b) -> Stack a -> Stack b am prefera să avem fmap :: (a -> b) -> f a -> f b unde f reprezintă un constructor de tip unar (primește un singur tip propriu). Desigur, restricționând f la acei constructori de tip ce vor reprezenta un container de valori. Observați că f în semnătura fmap anterioară nu poate fi un tip propriu (de exemplu,

www.todaysoftmag.ro | nr. 13/Iulie, 2013

programare

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

nu poate fi Bool). Practic, ajungem să avem nevoie de un sistem de tipuri pentru tipuri. În Haskell, acesta se cheamă sistemul de kinds, fiecare tip are asociat un kind. Tipurile proprii (Bool, Integer, tipurile funcții de la tipuri proprii la tipuri proprii – fără variabile de tip) au toate kindul *, în timp ce tipurile constructorilor de tip sunt de forma * -> *, * -> * -> *, etc. În GHCi, puteți afla kind-ul unei expresii de tip folosind :k. Vom reveni asupra kind-urilor peste un număr de articole, momentan descrierea de aici ajută la a înțelege eventualele erori de kind ce vor apărea ca urmare a experimentării lucrurilor prezentate în acest articol și pentru a ilustra faptul că inferența de tipuri nu este un subsistem simplu al compilatorului. Dimpotrivă, sunt cazuri în care și sistemul de kinds nu este de ajuns – dar vom reveni asupra acestui aspect. Întorcându-ne la restricțiile impuse variabilelor de tip, facem un mic detour prin lumea limbajelor orientate obiect: pentru a face ca anumite clase să implementeze un anumit set de operații foloseam moștenire și – în special – interfețe. În lumea OOP, o interfață era un contract suplimentar: dacă o clasă implementează o interfață suntem siguri că toate metodele din interfață au o implementare și pot fi folosite. Exact aceeași este și ideea din spatele claselor de tipuri din Haskell. O clasă de tip specifică un set de funcții asociate tipului și obligativitatea ca în momentul în care un tip este înrolat în această clasă programatorul/compilatorul să declare definiții pentru fiecare funcție din clasa de tip. După cum vedeți, este posibil ca definițiile unor funcții să fie date de compilator, nu de programator. Este cazul clauzelor deriving (introduse în articolul anterior) când se generează o implementare implicită dar este și cazul în care o clasă de tip are definiții implicite pentru anumite funcții din aceasta. Așadar, echivalentul unei clase de tip într-un limbaj orientat obiecte este mai aproape de o interfață, cât timp se permite definirea de metode implicite și definirea automată a metodelor în cazul unei implementări a interfeței. Să vedem acum cum clasele de tipuri rezolvă problemele cu care am început acest articol.Pentru tipurile numerice, există clasa Num (și o ierarhie de clase construită peste aceasta: Real, Rational, Integral, etc). Definiția clasei este următoarea: class Num a where

(+), (-), (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a x – y = x + negate y negate x = 0 - x

singur comentariu). {-# LANGUAGE #-} {-# LANGUAGE cies #-} {-# LANGUAGE #-} {-# LANGUAGE

MultiParamTypeClasses FunctionalDependenTypeSynonymInstances

Se observă imediat că metodele (-) FlexibleInstances #-} și negate sunt definite una în funcție de cealaltă. Pentru înrolarea unui tip în clasa Num vor trebui definite toate metodele mai Ne amintim definițiile de tipuri din puțin una din cele 2. articolul trecut: Pentru conversia la șiruri de caractere Name = String avem clasa Show ce conține funcția show type type Age = Int :: a -> String. Similar, pentru conversia type Address = String inversă avem clasa Read cu funcția read type PhoneNumber = Integer :: String -> a. Pentru testele de egalitate/ newtype NameAgeTable = NAgT Age)] deriving Show inegalitate avem clasa Eq din care va tre- [(Name, newtype NameAddressTable = NAdT bui să implementăm una din (==) sau (/=). [(Name, Address)] deriving Show NamePhoneTable = NPT În fine, pentru a ordona două elemente ale newtype [(Name, PhoneNumber)] deriving unui tip avem clasa Ord Show class Eq a => Ord a where compare :: a -> a -> Ordering (<), (<=), (>), (>=) :: a -> a -> Bool max, min :: a -> a -> a

Observați cum am folosit deriving Show pentru a putea afișa tabela în cazul în care vrem să vedem ce conține aceasta. Să construim acum câteva valori penDin această clasă ajunge să implemen- tru cele trei tabele pe care le folosim: tăm metoda compare sau cele 4 teste de = NAgT [(„Ana”, 24), inegalitate. Observați că există o restricție: nameAge („Gabriela”, 21), („Mihai”, 25), un tip nu poate fi înrolat în clasa Ord fără („Radu”, 24)] a fi înrolat și în clasa Eq. Altfel nu ar avea nameAddress = NAdT [(„Mihai”, „a sens operațiile (<=) și (>=). random address”), („Ion”, „another În final, funcția fmap poate fi aplicată address”)] tuturor tipurilor înrolate în clasa Functor. namePhone = NPT [(„Ana”, 2472788), Numele provine dintr-un concept din teo- („Mihai”, 24828542)] ria categoriilor și clasa este mult mai utilă decât pare acum. Vom reveni asupra acestui Este momentul să definim o clasă aspect într-unul din articolele următoare. pentru căutarea în aceste tabele și apoi să înrolăm cele trei tipuri la această clasă. class Functor f where fmap :: (a -> b) -> f a -> f b

Cunoscând clasele, să vedem cum înrolăm un tip nou la acestea. Putem folosi clauza deriving pentru a lăsa compilatorul să deducă automat definițiile rezonabile sau vom folosi instance. De exemplu, pentru liste, avem următoarea instanțiere a tipului Functor: instance Functor [] where fmap = map

Continuăm acum exemplul de data trecută cu cele trei tabele în care căutăm informații despre persoane. Dacă mai țineți minte, am fost nevoiți să definim trei funcții diferite de căutare. Respectând șablonul oferit de Functor / fmap am prefera să facem același lucru și aici. Vom folosi câteva extensii ale compilatorului GHC. Le vom activa folosind directiva LANGUAGE (le-am scris câte una pe rând pentru lizibilitate, de regulă se scriu într-un

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

class SearchableByName t a | t -> a where search :: Name -> t -> Maybe a

Observați că a trebuit să folosim două variabile de tip în definiția clasei deoarece avem nevoie de două variabile de tip în semnătura funcției search: t pentru tabela în care căutăm și a pentru rezultatul întors. Deoarece tabela determină tipul rezultatului întors am folosit o dependență funcțională pe care o vedeți între | și where. Din cauza acestei dependențe a trebuit să activăm extensiile mai sus menționate (cea cu sinonimele deoarece vom folosi sinonime în momentul înrolării tipurilor tabelelor). Instanțierea este relativ evidentă: instance SearchableByName NameAgeTable Age where search name (NAgT l) = lookup name l instance SearchableByName NameAd-

programare dressTable Address where search name (NAdT l) = lookup name l instance SearchableByName NamePhoneTable PhoneNumber where search name (NPT l) = lookup name l

Aparent, am scris mai mult cod decât data trecută și pare a fi mai mult cod repetat. E drept, este un exemplu simplu și nu avem multe metode în clasa noastră. Dar, șablonul de a căuta într-o tabelă după primul câmp este complet capturat de aceasta. Acum, să căutăm în tabele: *Main> search „Ion” nameAge

TODAY SOFTWARE MAGAZINE Tipul tabelei în care căutăm specifică tipul rezultatului, dar interfața de căutare este unică. Vom continua data viitoare aplicația pentru a realiza și operații de tip join pe aceste tabele, folosind faptul că avem o interfață unificată pentru a căuta în acestea. Vom vedea atunci cum vom putea evita problema unei înlănțuiri de teste pentru Nothing / Just _ ce apare în acest moment dacă încercați să scrieți codul pentru join. Vom porni de la Functor și vom extinde ierarhia de clase ce capturează șabloane inspirate din teoria categoriilor.

Nothing *Main> search „Mihai” nameAge Just 25 *Main> search „Mihai” nameAddress Just „a random address” *Main> search „Gabriela” nameAddress Nothing *Main> search „Gabriela” namePhone Nothing *Main> search „Mihai” namePhone Just 24828542

www.todaysoftmag.ro | nr. 13/Iulie, 2013

programare

Fresh de portocale

xperienta e bună. Sau nu? Experienţa e bună atâta timp cât trebuie să rezolvi aceleaşi probleme. Experienţa e din păcate ne-bună atunci când ai probleme noi sau ai nevoie de soluţii noi.

De ce? Antonia Onaca

anto@aha-ha.com de aproape 10 ani trainer, psiholog, consultant sub formă de antreprenor, intraprenor şi antreprenor din nou

Mintea umană gândeşte simplu. Asta e foarte bine atunci când trebuie să reacţionezi repede sau când ai ca scop eficienţa. Ştim totuşi că în ziua de azi ne trebuie şi altceva decât quick and easy. Ne trebuie nou, nemaivăzut, creativ, inovativ, fresh … Oamenii fără experienţa have it easy. Ei nu au pattern-uri anterioare validate care să se activeze atunci când se confruntă cu o problemă ce trebuie rezolvată. Pentru ei problema este nouă și pot să creeze o soluţie nouă. Totuşi, câteodată ai nevoie de o soluţie nouă în sine nu doar nouă pentru tine. Asta înseamnă ca ai nevoie de o soluţie nouă, diferită de soluţiile vechi. Cum se face fresh de portocale? Sunt multe metodologii pentru stimularea creativității şi a gândirii divergente. Eu vă propun una singură care până acum a adus idei noi şi relevante. Durează ceva vreme să o implementati dar la final merită efortul. It’s a kind of magic. Magic54, versiunea 1.

într-un loc care îmi place?” până la “Cum să îmi motivez echipa?” E bine să formulezi începând de la: Cum să? Pentru a-ţi lăsa mintea să accepte mai mult decât soluţii alb/negru (îmi iau apartament sau nu; le dau un bonus sau nu) Nu intra în foarte multe detalii. Nu sunt necesare.

Începe să generezi soluții. 54 de soluţii. Da, ştiu, sunt multe 54. Totuşi soluţiile noi vor veni doar după ce ai scris soluţiile la care te-ai gândit deja. Prima soluţie ti-o sugerez eu: “Nu fac nimic, las situaţia aşa cum este.” Reguli pentru generarea celor 54 de soluţii: • Scrie ce îţi vine în minte (indiferent dacă pare o soluţie bună sau nu). Cel mai bine este să nici nu evaluezi soluţiile pe măsură ce le scrii. • Nu te gândi la soluţii, scrie-le doar. • Nu nota detalii la soluţii și nu încerca să te gândeşti cum vor funcţiona. • Chiar dacă simţi că ai găsit soluţia perfectă, continuă să scrii. • Soluţiile scrise pot fi reformulări sau variante ale soluţiilor anterioare.

Cum merge de obicei? Primele aproximativ 12 soluţii vor fi variaţii ale soluţiilor În primul rând hai să vedem unde ai la care te-ai gândit deja înainte să începi nevoie de o solutie fresh? exerciţiul. Următoarele 12 soluţii vor fi din Poate fi orice: de la “Cum să locuiesc categoria “play it safe/let’s not rock the boat”.

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Abia după ce ai trecut de 24 vei ajunge Următorul pas este să combini soluţii să te gândeşti cu adevărat la problemă. după urmatoarele formule: 3+12 Câteva recomandări pentru a face 24+39 acest proces facil. De fiecare data când te 29+53 blochezi poţi să foloseşti oricare din urma13+25+37 toarele “de-blocaje” sau altele noi: 3+42+47 • Reciteşte lista şi vezi dacă poți refor7+17+29+52 mula sau nuanţa soluţii anterioare. 19+? (choose your solution) • Vorbeşte cu cineva care nu cunoşte 26+? deloc situaţia şi încearcă să o explici. 4+14+24+? • Bea un pahar mare de apă. ?+? • Fă un duş. ?+? • Fă exerciţii de matematică sau citeşte. ?+? poezii. 45+?+? • Uita-te la poze. ?+?+? • Rezolva mind-puzzles. ?+?+? • Cântă. ?+?+? … orice care să reprezinte o activitate care să îţi activeze procese cognitive pe care fie nu le-ai folosi în mod normal pentru această problemă fie îţi redefinesc problema sau nevoia. Ţine minte! Nu toate soluţiile trebuie să fie perfecte. Poţi scrie şi soluţii care par ciudate sau chiar nefezabile. Acest pas nu are ca scop să identifici soluţia, ci doar să îţi pună mintea la treabă. Dacă crezi că te ajută, dă un search şi vezi ce soluţii oferă vastul internet. E un proces frustrant, nu am să te amăgesc. Dar după ce treci de frustrare si reuşeşti să îţi mobilizezi ambiţia … vei fi impresionat de ce surprize îţi poate face mintea ta.

Combinarea lor presupune crearea unei noi soluţii având caracteristicile celor combinate.

Bonus feature. Aceasta este de departe partea mea favorită. Notează 10 non-soluţii. Non-soluţii sunt lucruri care nu vor rezolva situaţia sau lucruri care o vor înrăutăţi. De ce să faci asta? Pentru a dezactiva safe mode. Dacă generezi non-soluţiile mintea ta se va relaxa şi va mai domoli puţin stresul legat de performanţă (cât de bune sunt soluţiile). După ce ai făcut lista asta, imediat după, mai notează câteva soluţii care îţi vin în minte (cel puţin 5).

nouă. E foarte important să scrii pe hartie, ajută la gândit. Ţine minte: când alegi, chiar dacă unele soluţii par inconfortabile, trebuie să te gândeşti ce va rezolva sau schimba situaţia, ce îţi va satisface nevoia sau va anula aspectele negative de la situaţia curentă.

Gandeşte un plan!

Am observat că rar se întâmplă ca o singură soluţie să rezolve o situaţie aşa ca îţi recomand să faci un plan de punere în realitate toate soluţiile din short list. Dacă e cazul vei modifica planul atunci când el devine realitate.

Merită?

Acum ai o lista de cel puţin 5 soluţii care ţi se par ca vor rezolva situaţia şi un plan care să le pună în realitate. Gândește-te dacă merită. Cântăreşte dacă aspectele pozitive şi negative ale rezolvării cuplate cu efortul de a rezolva situaţia cântăreşte mai mult decât situaţia actuală. E posibil să descoperi că nu merită efortul sau chiar e posibil să îţi găseşti motivaţia suplimentară pentru a pune planul în mişcare. E un exerciţiu ce va necesita încăpăţânare să îl finalizezi. Dar în acest caz încăpăţânarea e bună.

Alege!

Ok. Acum ai o lista de soluţii. Unele Acum ai o listă de soluţii. Alege cel bune altele ne-bune. puţin 6 dintre ele și notează-le pe o foaie

www.todaysoftmag.ro | nr. 13/Iulie, 2013

management

E vreme de concedii .... Gogu îl văzu pe Șefu’ intrând în birou și își înghiți replica. Mișu, cu spatele la ușă, nu remarcă mișcarea și în lipsa oricărui comentariu al lui Gogu, conchise: - Va să zică, gândești tu că i s-a urcat șefia la cap?! - Cui i s-a urcat șefia la cap?! întrebă Șefu’. Alo, Șefu’ către Mișu, recepție! Insistă el către un Mișu care înțepenise, doar ochii mijiți către Gogu țipau tăcut a ajutor. Gogu îl ignoră însă și uitându-se la Șefu’ mai puse un lemn pe foc: - Hai Mișule, nu sta ca ciobanu’ la oi, te-a întrebat Șefu’ ceva! Zâmbi cu drag pe sub mustață, Mișu era incredibil de simpatic în inocența lui și nu se putea abține să nu-l zgândăre. Ochii mijiți ai lui Mișu trecură de la ruga tăcută la reproș mut, iar Gogu izbucni de-a binelea în râs: -Înainte să îți spunem, Șefu’, despre ce e vorba, poate ne lămurești matale puțin și pe noi. Ochii lui Mișu trecură acum la spaimă. ”Hi-hi, pluralul ‚noi’ nu îi sună bine deloc”, gândi Gogu și continuă: - De două săptămâni ne ții numai în exerciții de alarmare, de zici că suntem celulă de urgență. Visăm deja cine răspunde dacă apare o cerere de ofertă, cine și cui solicită clarificări pentru detalii, cine sare la o revendicare pe contractele în derulare, cine la ce întâlnire merge, cine poate negocia și până la ce nivel. Mai rămâne să stabilim ce facem în caz de atac nuclear, că pe restul le-am clarificat pe toate. Cred că poți pleca liniștit și-acasă... Hopa! Zdrang, îi pică fisa lui Gogu. Șefu’, matale te pregătești de concediu?! - Păi... cam așa ceva, zâmbi Șefu’. Te-ai prins până la urmă, Gogule. Tot omu’ trebuie să se mai și recreeze, până și eu. Tu când pleci în concediu? - Hă-hă... Păi ce? Pot pleca?! La jumate’ proiect? Să-mi sune telefonu’ pe plajă din 10 în 10 minute? Mă omoară nevasta!!! Nu plec, Șefu’, până nu închidem proiectul. - Adică vara asta nu-ți scoți nevasta și copilul la mare, munte, soare?! Mare greșeală, Gogule! Se pare că mai ai de învățat în materie de management. - Ce vrei să spui, Șefu’? Ori nu ești mulțumit de mine? Că nu te-ai plâns până acum de felul în care conduc proiectele... se supără Gogu. Și tu nu te mai zgâi la mine, se rățoi el la Mișu, care și-o luă nevinovat. Mișu chiar nu avea săracul habar despre ce se discuta în propoziție, se uita siderat la amândoi, schimbul de replici fusese probabil mult prea rapid și undeva pe parcurs pierduse șirul. Șefu’ se uită complice spre Mișu (care tot nu pricepea nimic, așa că nu înțelese nici sensul privirii complice a lui Șefu’) și continuă: - Stai așa, Gogule, nu te-aprinde, că nimeni de-aici nu ți-ar nega vreodata capacitatea de a ține un proiect în frâu. Dar omu’ cât trăiește învață... Na, că acum scoatem din buzunar înțelepciunea populară, gândi Gogu, dar se abținu să comenteze. Așteptă să vadă ce urmează. - Ia gândește-te la ce ai zis mai acu’ câteva minute legat de pregătirea din departament. Am delegat atât responsabilitățile cât

nr. 13/Iulie, 2013 | www.todaysoftmag.ro

și autoritatea de a lua decizii pentru majoritatea situațiilor care pot interveni. Știi la ce ajută?! Plec în concediu, două săptămâni! Și n-am de gând să-mi verific emailul și nici nu voi răspunde la nici un apel telefonic. Știi care va fi rezultatul? - Da, eu te-aș da afară! Ei nu, replica n-o spuse Gogu cu voce tare, o gândi doar și așteptă ca Șefu’ să continue, era evident că fusese doar o întrebare retorică. - Voi sta liniștit la plajă, îmi voi savura fiecare moment de concediu, iar aici totul va merge ca pe roate. Zâmbi larg, satisfăcut, iar Gogu, deși enervat la culme, nu putu decât să-i dea dreptate. Toți știau ce aveau de făcut, iar pentru situațiile speciale Șefu’ avusese grijă zilele acestea să stabilească clar atât responsabilitățile cât și limitele decizionale. - Păi da, Șefu’, da’ în proiect lucrurile stau diferit, încercă el. - Zău?! Și cam în ce fel stau diferit? zâmbi cu răbdare Șefu’. Ce zici, Mișule, or fi lucrurile diferite în proiecte? se întoarse el spre tânărul lor coleg. Gogu privi și el spre Mișu: Na, culmea, i-a revenit și ăstuia inteligența în privire, gândi el în timp ce-i arunca lui Mișu privirea lui clasică de „Să nu dea Sfântul să comentezi ceva!”. Se pare însă că juniorului nu-i plăcea să rămână dator, așa că ignoră mesajul mut din ochii lui Gogu și cu satisfacție prea puțin ascunsă îi răspunse lui Șefu’: - No, nu-i nici o diferență. Management îi și într-un caz și-n altul. Numa’ că matale ești mult mai experimentat... Șarpe! Am crescut un șarpe la sân, își spuse Gogu cu năduf. Dar remarcase tonul șăgalnic al lui Mișu și constată încă o dată cu mulțumire că deși încet la vorbă, Mișu făcea în timp util toate conexiunile necesare. Poate chiar prea multe conexiuni, mâinepoimâine te pomenești că-mi dă și lecții, își mai spuse el, dar era mai degrabă mândru de Mișu decât supărat. Se simți asta și în tonul cu care îi răspunse: - Așa, Mișule, ia dă-te tu deștept, că cererea ta de concediu e la mine. Nu cred că ți-o pot aproba, că n-am pe cine altcineva să las în locul meu când plec în concediu. - Păi n-ai zis că nu pleci? Cum să plece managerul de proiect în mijlocul proiectului? se sperie Mișu. - Ce-am discutat noi până acum?! Un manager trebuie să se relaxeze măcar o dată pe an iar dacă e cu adevărat bun atunci nu i se simte lipsa atunci când pleacă. Pentru că știe să delege, nu-i așa?! Stai să vezi cum mi se urcă mie șefia la cap...

Simona Bonghez, Ph.D.

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

sponsori

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

SMS 0371700018 numﾄビ cu tarif normal