Today Software Magazine N2/2012

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

Microsoft Kinect de la SF la realitate

Agile Software Development folosind Scrum

Big Data

Programarea funcţională

Startups - SociaLook

Exploratory testing

Pregătirea unui interviu

No. 2 / 2012 • www.todaysoftmag.ro

M AG A Z I N E

6Microsoft Kinect

de la SF la realitateEchipa Simplex

12Agile Software Development

folosind Scrum Tavi Bolog

16Big Data

Robert Enyedi

18Programarea funcţională

Ovidiu Deac

22Exploratory Testing

Ioana Matros

24SociaLookHoraţiu Mocian

28Interviu Dan Luţaş - Portretul unui specialist în securitatea informaţieiMarius Mornea

32Pregătirea unui interviuAndreea Pârvu

36Faceţi cunoştinţă cu Gogu!Simona Bonghez

4 nr. 2/2012 | www.todaysoftmag.ro

Editorial

Revista s-a bucurat de un real succes pentru primul său număr, www.todaysoftmag.ro a avut peste 1373 de vizitatori unici de la lansarea din 6 Februarie 2012. Imboldul local s-a simțit prin cele 1420 de accesări a utili-

zatorilor din Cluj. Suportul comunității locale în sprijinirea acestei inițiative nu s-a lăsat așteptat. Mulțumim ISDC pentru încrederea acordată de a deveni primul nostru sponsor.

În 16 Martie am lansat versiunea internațională a revistei in engleză prin www.

todaysoftmag.com care a avut un nou look&feel și care a fost aplicat și versiunii locale. Diversitatea a fost principala caracteristică, cititorii fiind localizați în 25 de țări.

Odată cu acest număr inaugurăm rubrica Comunități locale în care vom prezenta grupuri precum Transylvania Java User Group sau Cluj Semantic Web Meetup și a eve-nimentelor organizate de acestea.

Conținutul numărului 2 este destul de variat, multe dintre articole reprezentând înce-putul unei serii. Trebuie să remarc prezența în revistă a d-nei Simona Bonghez, care apare cu un articol inedit despre cât de costisitor poate fi să îi oferi o lecție unui angajat. Prezentarea limbajelor funcționale, începută in primul număr, continuă cu o prezentare generală a acestora și a modului de folosire. Big Data ne arată care sunt provocările gene-rat de fluxul tot mai mare de date produs de rețelele sociale și nu numai. Acesta promite să fie primul dintr-o serie în care vor fi descrise provocările la care suntem supuși în analiza realtime a fluxului de datelor și cum se pot aplica tehnologiile disponibile pe piață. Început de serie este și articolul despre Kinect, un dispozitiv exotic care ne dă posi-bilitatea să programăm aplicații, nu doar jocuri, având ca și dispozitiv de intrare chiar corpul uman. Cum testăm o aplicație? Este o întrebare la care nu prea se învață răspunsul în facultate în condițiile în care numărul de ingineri QA este comparabil cu cel al pro-gramatorilor. În acest număr vom analiza Exploratory Testing ca modalitate de testare. Pregătirea pentru interviu și modul de susținere este un lucru trecut cu vederea de mulți programatori așa că am considerat utilă prezența unui articol special pe tema aceasta, mai ales că poate fi folosit cu succes și la altfel de întâlniri, nu doar în interviurile de angajare. Seria de startup-uri și interviuri continuă prin prezentarea SociaLook, un tool eficient pentru mediul de afaceri bazat pe Twiter și un interviu cu Dan Luţaș de la BitDefender.

Nu în ultimul rând, vă așteptăm comentariile pe www.todaysoftmag.ro unde vă puteți și înregistra la newsletter-ul revistei pentru a fi la curent cu ultimele apariții.

Mulţumesc,

Ovidiu Măţan

fondator Today Software Magazine

Ovidiu Măţan, [email protected]

Coordonates Gemini Solutions Cluj’s team, in the past worked as a Product Manager for Ovi Sync at Nokia, founder of Today Software Magazine.

editorial

5www.todaysoftmag.ro | nr. 2/2012

Redacţie

Fondator / Editor in chief: Ovidiu Mățan / [email protected] designer: Dan Hădărău / [email protected]

Editor (limbaje de programare): Ovidiu Deac / [email protected] (startups și interviuri): Marius Mornea / [email protected]

Colaborator marketing: Ioana Fane / [email protected]: Romulus Pașca / [email protected]

Adresă de contactstr. Plopilor, nr. 75/77

Cluj-Napoca, Cluj, [email protected]

www.todaysoftmag.rowww.facebook.com/todaysoftwaremagazine

twitter.com/todaysoftmag

ISSN 2284-6360


Microsoft Kinect de la SF la realitate

Project Natal era anunţat ca fiind un dispozitiv hardware periferic pentru consola XBOX 360 și avea să schimbe modul de interacţiune și gameplay între utilizatori și consola de jocuri Microsoft. În filmul demonstra-tiv al conceptului, utilizatorii puteau să se distreze cu jocuri de luptă sau cu mașini prin mișcări naturale ale corpurilor lor, fără să fie constrânși de utilizarea unei manete sau de un joystick. Mai mult, aparatul ar fi avut și un microfon încorporat special, iar pornirea sau opri-rea unui film spre exemplu, se puteau face prin simple comenzi vocale. Timp de un an de zile Microsoft nu a mai dezvăluit nimic despre produsul anunţat, iar la E3 – 2010, Project Natal a fost redenumit în Kinect și urma să fie lansat oficial la începutul lunii noiembrie a aceluiași an.

Așadar, Kinect este un dispozitiv periferic dezvoltat de Microsoft, care detectează mișcarea și permite utilizatori-lor să interacţioneze cu consola XBOX 360, precum și cu orice Windows PC (odată cu

lansarea versiunii oficiale pentru Windows: http://www.kinectforwindows.org) folo-sind, cum am menționat anterior, gesturi ale corpului și comenzi vocale. Deși scopul inițial a fost de a îmbogăți experiența jocu-rilor pe consola XBOX 360, în scurt timp sfera de utilizare pentru Kinect s-a extins considerabil. În prezent, dispozitivul e folo-sit în domenii precum medicina, industria de advertising sau robotica, mergând cu mult mai departe decât funcția inițială de divertisment.

Chiar dacă în primă fază, Kinect era destinat doar utilizatorilor de XBOX 360, la câteva săptămâni de la lansare au

Încă din anul 2002, de la lansarea filmului Minority Report regizat de Steven Spielberg în care personajul principal John Anderton, jucat de Tom Cruise, inter-acţionează cu un calculator folosind o mănușă și gesturi ale mâinilor și degetelor,

lumea tehnologică a început să vorbească despre un nou mod de utilizare a calculatoa-relor, un mod în care butoanele și mouse-ul să nu fie principala metodă de interacţiune între om și PC, un mod care să ofere utilizatorilor o interfaţă naturală (Natural User Interface - NUI). Pe parcursul anilor următori s-au făcut publice diferite proiecte și con-cepte asemănătoare, dar abia după șapte ani, la Electronic Entertainment Expo 2009 (E3), Microsoft a anunţat Project Natal, punând accent pe ideea „You are the controller” („Tu eşti Controller-ul”).

Echipa [email protected]

programare


TODAY SOFTWARE MAGAZINE

început să apară diferite proiecte sub forma unor hack-uri. Controlul mouse-ului în Windows, cântatul la o chitară digitală, generarea 3D în timp real a unei camere de apartament, mașinuţe teleghidate ce oco-leau singure obstacole plasate în faţa lor au fost doar câteva din zecile de proiecte pe bază de Kinect construite de pasionaţi. După scurt timp au apărut și SDK-uri (Software Development Kit) Open Source pentru ca oricine să poată să dezvolte pro-iecte cu noua tehnologie de la Microsoft.

Drept răspuns, în iunie 2011, Microsoft a lansat primul Kinect-SDK oficial, dar fără licenţă de comercializare. Versiunea finală, de asemenea și comercială, a fost lansată pe 1 Februarie 2012, împreună cu o nouă ediție de Kinect, numit Kinect for Windows. Noul dispozitiv e asemănător cu ediția pen-tru XBOX, cea mai notabilă adiție fiind suportul pentru Near-Mode, un mod de funcționare în care utilizatorul se poate apropia foarte mult de cameră, iar aceasta poate detecta mișcări mult mai fine, cum ar fi mișcarea degetelor.

Detalii tehniceKinect are în componenţa sa o cameră

RGB cu o rezoluţie de 640 x 480, un microfon format din 4 capsule ce oferă o acurateţe mare când vine vorba de iden-tificarea vocii, un sistem pentru înclinare motorizată care permite aparatului să-și ridice sau să-și coboare unghiul de orien-tare asupra mediului și, probabil cea mai interesantă trăsătură, senzorul de adâncime 3D.

Senzorul de adâncime 3D este format dintr-un proiector de unde infraroșu și un senzor CMOS, care capturează informaţii

3D. Cu ajutorul tehnologiei software, Kinect poate recunoaște gesturi (gesture recognition) și oferă un sistem foarte avan-sat de interacţiune naturală.

Aparatul poate urmări șase persoane simultan, dar doar la două din acestea se poate analiza mișcarea. Mișcarea analizată se obţine cu ajutorul scheletului pe care software-ul Kinectului îl oferă. Un număr de puncte sunt plasate asupra corpului și sunt folosite pentru a recunoaște anumite mișcări făcute de utilizator. Aceste puncte, sau încheieturi, sunt: cap, gât, umăr stâng/drept, cot stâng/drept, încheietura mâi-nii stânga/dreapta, mână stânga/dreapta, coloană, pelvis, șold stâng/drept, genuchi stâng/drept, gleznă stânga/dreapta, laba piciorului stânga/dreapta.

Urmărirea acestor puncte pe corp e posibilă prin intermediul proiectorului de unde infraroșu. Acesta transmite undele și măsoară timpul lor de întoarcere, după ce au lovit unele obstacole fizice din mediul înconjurător. Principiul e asemănător cu modul în care funcționează sonarul: dacă putem detecta timpul necesar undelor pentru a se întoarce la senzorul infraroșu, putem afla și distanța la care se află cor-purile de care acestea s-au ciocnit. Toate aceste distanțe se pot stoca și în final mapa într-o imagine sau un fel de hartă a câmpu-lui vizual al camerei. Fiecarui punct de pe această hartă îi e atașat un indice de adân-cime în spațiu, iar toate aceste puncte pot fi transmise pentru o procesare aprofundată, unde, prin intermediul unor algoritmi, se pot detecta anumite forme sau obiecte, cum ar fi corpul uman, împreună cu poziția unor puncte importante pe acesta (cap, mâini, în principiu, exact punctele de care am discutat anterior).

Pe lângă acuratețe și viteză de reacție, tehnologia infraroșu aduce și un avantaj în plus: rezolvarea problemei luminii ambi-entale. Pentru că senzorul nu e proiectat să capteze lumina vizibilă, Kinect poate fi folosit și în încăperi unde luminozitatea e foarte redusă.

Pentru a funcționa, Kinect are nevoie de o sursă de curent mai mare decât cea obţinută prin USB. De aceea apara-tul are nevoie de un cablu de alimentare. Transferul de informaţii și conexiunea cu XBOX 360 (sau PC) se face prin USB,


iar alimentarea se face de la priză. Noile modele XBOX 360 Slim, lansate în 2010, includ un adaptor special care elimină nevoia de alimentare de la priză.

Conectarea Kinect-ului la PC se face prin USB și necesită instalare unor dri-vere ce se pot obţine de pe internet. Dacă se dorește instalarea unui SDK, fie Open Source sau cel oficial, driverele se instalează odată cu ele.

SDK-ul oficial oferă posibilitatea de dezvoltare a unor aplicaţii în limbajele C++, C#, sau Visual Basic, utilizând mediul de dezvoltare Microsoft Visual Studio 2010. Utilizarea SDK-ului necesită o mașină ce rulează sistemul de operare Windows 7.

CompetitoriPrincipalii competitori ai Kinect-

ului sunt Nintendo Wii și Playstation Move, fiecare având diferite atribute care le diferenţiază. În continuare vom face o comparație între cele trei dispozitive și vom încerca să-l găsim pe cel care imple-mentează cel mai bine o interfeță umană naturală.

În ceea ce privește camera video, Microsoft Kinect iese în evidență și e oarecum de așteptat, întrucât camera e fundamentală în funcționarea sa. Pe lângă camera ce emite în infraroșu și camera receptor atașată acesteia, Kinect dispune și de o camera RGB care sporește funcția de recunoaștere a formelor în imagini și poate fi folosită pentru detectarea expresi-ilor faciale și a detaliilor de finețe pe care camera infraroșu nu le poate capta. În plus, poate fi folosită și ca un fel de webcam mai performant pentru Skype sau alte conversații video pe internet. Playstation Move dispune de o camera RGB, dar pen-tru că funcționează în tandem cu un alt controller, Move nu oferă o soluție bazată pe infraroșu, iar asta face destul de difi-cilă urmărirea corpului utilizatorului în întregime. Wii nu dispune de nici un fel de cameră, întrucât dispozitivul celor de la Nintendo se bazează în special pe accele-rometru și giroscop. Nintendo Wii poate detecta mișcarea, dar nu cu o precizie foarte ridicată.

Controlul audio e foarte bine integrat de Kinect: dispozitivul dispune de un set de microfoane direcționale care îi permit să “asculte” doar comenzile utilizatorului și să ignore zgomotul de fond. Ca și camera RGB, setul de microfoane poate fi perfect folosit pentru Skype sau alte aplicații pentru

captare de sunet. Move oferă un set asemă-nător de microfoane, deci performanțele audio sunt comparabile cu cele găsite la Kinect. Wii-ul nu integrează nici un fel de microfon, deci comenzile vocale sau capta-rea audio nu sunt o opțiune.

Cât despre controllere fizice atașate, Kinect iese din start din discuție, iar asta e chiar partea interesantă. Potrivit Microsoft, când vine vorba de Kinect, controller-ul este chiar utilizatorul și orice mișcare sau gest al acestuia sunt automat captate de dispozitiv și procesate în continuare. Controller-ul fizic e elementul central al Nintendo Wii, iar accelerometrele și giroscopul său îl fac destul de eficient și distractiv pentru unele jocuri mai simple. Însă, deși se află printre deschizătorii de drumuri în domeniu, Nintendo Wii a pier-dut puțin teren între dispozitivele ce pot oferi o interfață umană naturală cu adevă-rat performantă. Playstation Move dispune de un controller asemănător cu maneta Wii ce măsoară accelerația mișcărilor

utilizatorului. E un sistem de funcționare bun, iar împreună cu camera video, poate oferi și o precizie bună în detectarea gestu-rilor, însă pentru a folosi Playstation Move, utilizatorul trebuie să țină tot timpul în mână și controller-ul atașat. E un mic dez-avantaj pentru că în timp poate provoca disconfort și ca atare depărtează puțin soluția oferită de Playstation de o interfață umană cu adevărat naturală.

Code SampleÎn continuare, vom include un exem-

plu de cod, scris în C# și având rolul de a inițializa un Kinect atașat la un PC. Mai mult, secvența de cod setează anumiți para-metri de funcționare și, ca o funcționalitate simplă, afișează pe ecran o elipsă roșie în funcție de poziția mâinii drepte a utiliza-torului. Deocamdată, vom include doar codul propriu-zis, urmând ca în nume-rele viitoare ale revistei, să îl parcurgem în detaliu și să venim și cu unele exemple mai complicate.

Microsoft Kinect - de la SF la realitateprogramare

Punctele plasate asupra corpului de Kinect

Imagine infraroşu (stânga) şi imagine RGB (dreapta), captate de senzorul de care dispune Kinect



public partial class KinectSample : Window { public KinectSample() { InitializeComponent(); } bool closing = false; const int skeletonCount = 6; Skeleton[] allSkeletons = new Skeleton[skeletonCount];

private void Window_Loaded(object sender, RoutedEventArgs e) { kinectSensorChooser.KinectSensorChanged += new DependencyPropertyChangedEventHandler(kinectSensorChooser_KinectSensorChanged); }

void kinectSensorChooser_KinectSensorChanged(object sender, DependencyPropertyChangedEventArgs e) { KinectSensor old = (KinectSensor)e.OldValue; StopKinect(old); KinectSensor sensor = (KinectSensor)e.NewValue; if (sensor == null) { return; }

var parameters = new TransformSmoothParameters { Smoothing = 0.3f, Correction = 0.0f, Prediction = 0.0f, JitterRadius = 1.0f, MaxDeviationRadius = 0.5f }; sensor.SkeletonStream.Enable(parameters); sensor.SkeletonStream.Enable(); sensor.AllFramesReady += new EventHandler<AllFramesReadyEventArgs>(sensor_AllFramesReady); sensor.DepthStream.Enable(DepthImageFormat.Resolution640x480Fps30); sensor.ColorStream.Enable(ColorImageFormat.RgbResolution640x480Fps30);

try { sensor.Start(); } catch (System.IO.IOException) { kinectSensorChooser.AppConflictOccurred(); } }

void sensor_AllFramesReady(object sender, AllFramesReadyEventArgs e) { if (closing) { return; }

Skeleton first = GetFirstSkeleton(e);

if (first == null) { return; }

MainCanvas.Children.Clear(); Ellipse rightEllipse = new Ellipse(); rightEllipse.Fill = Brushes.Red; rightEllipse.Width = 20; rightEllipse.Height = 20; MainCanvas.Children.Add(rightEllipse); ScalePosition(rightEllipse, first.Joints[JointType.HandRight]); }

Skeleton GetFirstSkeleton(AllFramesReadyEventArgs e) { using (SkeletonFrame skeletonFrameData = e.OpenSkeletonFrame()) { if (skeletonFrameData == null) { return null; } skeletonFrameData.CopySkeletonDataTo(allSkeletons);

Skeleton first = (from s in allSkeletons where s.TrackingState == SkeletonTrackingState.Tracked select s).FirstOrDefault(); return first; } } private void StopKinect(KinectSensor sensor) { if (sensor != null) { if (sensor.IsRunning) { sensor.Stop(); if (sensor.AudioSource != null) { sensor.AudioSource.Stop(); } } } } private void ScalePosition(FrameworkElement element, Joint joint) { Joint scaledJoint = joint.ScaleTo(1280, 720, .3f, .3f); Canvas.SetLeft(element, scaledJoint.Position.X); Canvas.SetTop(element, scaledJoint.Position.Y);

} private void Window_Closing(object sender, System.ComponentModel.CancelEventArgs e) { closing = true; StopKinect(kinectSensorChooser.Kinect); } }


Secvența de cod este inspirată din unele resurse educaționale oficiale de pe site-ul http://www.kinectforwindows.org, iar rularea lui necesită o instalare a SDK-ului oficial, oferit de Microsoft și găsit pe același site.

ConcluziiKinect oferă multe oportunităţi pentru

dezvoltarea de aplicații inovative, ce asigură un mod intuitiv și natural de interacţiune între om și calculator. Deși este o tehnolo-gie încă relativ nouă, dispozitivul a captat atenția multor dezvoltatori independenți și entuziaști, dar și a unor corporații și a unor companii mari, comericale. Astfel, în ulti-mele luni, au început să apară numeroase proiecte și aplicații care, folosind Kinect, aduc numeroase soluții în cele mai diverse domenii.

Kinect se poate folosi cu ușurință în advertising sau în magazine de retail, unde clienții ar putea proba haine în fața unui calculator. Mai mult, dispozitivul e ideal și pentru domenii în afara sferei de divertisment. Momentan, e propus în școli, unde elevii ar avea parte de un mod mult mai interactiv și captivant de a învăța. De exemplu, la ora de chimie, elevii ar putea să interacțieze cu unii compuși chimici și să facă unele experimente pe un calculator cu Kinect, fără a fi expuși direct la unele ele-mente chimice sau reacții periculoase.

Dispozitivul atrage și foarte mulți studenți, iar pentru asta Microsoft, dar și

alte organizații sau companii, organizează unele competiții sau proiecte de finanțare. Un exemplu e Imagine Cup, un concurs internațional adresat studenților pasionați de tehnologie, unde în 2012 s-a format o categorie specială dedicată Kinect și numită Kinect Fun Labs Challenge.

În final, Kinect este o tehnologie cu un potențial enorm ce aduce un progres important în interacțiunea naturală dintre om și calculator. Drept dovadă stă impactul pe care l-a avut în trecutul său încă foarte scurt.

Noi vom continua cu unele articole despre această nouă tehnolgie, iar în nume-rele viitoare ale revistei Today Software Magazine, ne propunem să publicăm unele idei și detalii despre cum și ce se poate dez-volta cu Kinect și SDK-ul oficial al său.

Link-uri utile P r o j e c t N a t a l

- http://www.youtube.com/watch?v=g_txF7iETX0&feature=youtube_gdata

Microsoft E3 2010 Kinect Demo - http://www.youtube.com/watch?v=LUsiFjeRWjw

OpenKinect SDK - http://openkinect.org/wiki/Main_Page

Kinect for Windows SDK - http://www.microsoft.com/en-us/kinectforwindows/develop/

Nintendo Wii - http://www.nintendo.com/wii

P l a y S t a t i o n M o v e - h t t p : / /us.playstation.com/ps3/playstation-move/

Microsoft Kinect - de la SF la realitateprogramare

We are seeking Senior C++ software engineer, experienced in game development.

Required knowledge:• very experienced C++ programmer• design patterns• understanding of game development process• experienced in using rendering engines & physics engines.• proven track of of working on released games

Position available for Cluj-Napoca, București, Iași

Apply at [email protected]



Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: http://www.transylvania-jug.org/Data înfiinţării: 15.05.2008 / Nr. Membri: 459 / Nr. Evenimente: 37

Romanian Testing CommunityComunitate dedicată QA.Website: http://www.romaniatesting.ro Data înfiinţării: 10.05.2011 / Nr. Membri: 422 / Nr. Evenimente: 1

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

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

Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: http://www.meetup.com/Cluj-Semantic-WEB/Data înfiinţării: 08.05.2010 / Nr. Membri: 109 / Nr. Evenimente: 14

Google Technology User Group Cluj-NapocaComunitate dedicată tehnologiilor Google.Website: http://cluj-napoca.gtug.ro/Data înfiinţării: 10.12.2011 / Nr. Membri: 25 / Nr. Evenimente: 4

Cluj Mobile DevelopersComunitate dedicată tehnologiilor mobile.Website: http://www.meetup.com/Cluj-Mobile-Developers/Data înfiinţării: 08.05.2011 / Nr. Membri: 38 / Nr. Evenimente: 2

Secţiunea comunitate își propune să ţină evidenţa grupurilor de profesioniști relevante pentru industria IT, dar și un calendar de evenimente și întâlniri din acest sector. Pentru început prezentăm principalele iniţiative din mediul local, în timp intenţionând să creștem acest index până ce va conţine toate comunităţile locale, dar și cele naţionale cu prezenţă și activitate pe plan local.

Criteriul ales pentru ordonare este o funcţie dată de numărul de membrii și activitatea grupurilor (evenimente locale) raportate la durata de viată, astfel sperăm să obţinem o ierarhie bazată pe gradul de implicare, atât al organizatorilor, cât și al membrilor.

Calendar

Aprilie 10The Social Web – part2Contact: http://www.meetup.com/Cluj-Semantic-WEB/

Aprilie 18 – Mai 18Mobile TrainingContact: [email protected]

Aprilie 22 – Mai 22AROBSchool .Net ClassAROBSchool C/C++ ClassContact: [email protected]

Aprilie 23 - 26JobShopContact: http://www.jobshop.ro/cluj/2012/

Aprilie 25Machine Learning for Pairwise DataContact: http://www.meetup.com/Cluj-Semantic-WEB/

Mai 24 – 27AQTR2012 (2012 IEEE International Conference on Automation, Quality and Testing, Robotics)Contact: http://www.aqtr.ro/

Mai 28 – 29ITCamp 2012Contact: http://itcamp.ro/

Menţionăm și salutăm recenta înfiinţare a grupului Cluj Perl Mongers (www.cluj.pm), in data de 2 Martie a acestui an.

În încheiere vă invităm să ne trimiteţi propunerile voastre sau să vă pronunţaţi asupra propunerilor de mai jos, pentru a completa lista cu grupuri pe care le consideraţi active și relevante pentru mediul ITC românesc. O parte din grupurile pe care le analizăm și dorim să le adăugăm pentru a extinde atât domeniile și tehnologiile, cât și pentru a oferi perspective care nu sunt legate strict de o anumită tehnologie sunt: GeekMeet (http://geekmeet.ro/), ITSpark (http://itspark.ro/default.aspx), Codecamp (http://www.codecamp.ro/), CodExpert (http://www.codexpert.ro/), PHPRomania (http://www.phpromania.net/), ARIES (http://www.aries.ro/).

Comunităţi locale


Modelul waterfall este unul secvențial, așa cum arată diagrama de mai jos. Cea mai mare critică adusă modelului este rigidita-tea. În realitate, s-a dovedit că un proiect software nu poate fi planificat în întregime de la început până la sfârșit și că este foarte important ca echipele de dezvoltare să se adapteze pe parcursul proiectului la cerințe noi.

Revenind la Scrum, metoda a fost pre-zentată pentru prima dată in 1995, de către Jeff Sutherland și Ken Schwaber, în cadrul unui workshop la OOPSLA ’95. Ideea de Scrum nu a fost legată inițial de software development, ci a fost descrisă ca o metodă de a crește viteza de execuție și flexibilita-tea unei echipe folosind aceeași abordare ca și în rugby (o echipă încearcă să avanseze cu mingea cât mai mult pasând înainte și înapoi).

Scrum folosește o abordare incre-mentală si iterativă, având ca scop final dezvoltarea unei soluții software care satisface nevoile clienților, din punct de vedere funcțional și calitativ și este rulată într-un mediu de producție încă din stadi-ile inițiale:

Aceasta filozofie, la care aderă toate metodele agile precum extreme program-ming, kanban, lean software development etc., a fost formalizată în 2001 sub numele de Agile manifesto:• Indivizii şi interacţiunea înaintea pro-

ceselor şi uneltelor• Software funcţional înaintea documen-

taţiei vaste• Colaborarea cu clientul înaintea nego-

cierii contractuale• Receptivitatea la schimbare înaintea

urmăririi unui planCu alte cuvinte, deși există valoare în

elementele din dreapta, le apreciem mai mult pe cele din stânga.

Agile Software Development folosind Scrum

Pe la începutul lui 2008, compania în care lucram la momentul respectiv a decis că trebuie să devenim agili și să folosim Scrum. Nu am înțeles exact de ce ar trebui să ne schimbăm modul de lucru pe care îl foloseam ca echipă, mai ales

că până la urmă urmam SDLC (software development life cycle): cerințe, design, imple-mentare, testare, mentenanță și aveam câte un release la 3-4 luni folosind waterfall.

Cerinţe

Design

Implementare

Mentenanţă

Testare

Cerinţe

Design

Implementare

Mentenanţă Testare

Tavi [email protected]

Development Lead at Nokia, enjoying Berlin and buil-ding software together with an enthusiastic team

management



Implementarea ScrumScrum-ul pare relativ simplu de imple-

mentat pentru că rolurile și procesul în sine sunt simple. Însă asta înseamnă că fiecare echipă va trebui să definească detaliile (de exemplu vezi definiția lui done de mai jos). De asemenea, Scrum se bazează pe valo-rile umane (vezi agile manifesto). Fiecare membru al echipei va trebui să contribuie la atingerea țelurilor echipei fiind onest, punctual, disponibil în a-și ajuta colegii, multi-funcțional (contribuind la toate fazele de dezvoltare software sau definiției lui done). Filozofia scrum sugerează că echipele trebuie să se auto-organizeze, iar interacțiunile de management din exterior reduse la minim.

Ca metodologie de dezvoltare, Scrum este foarte simplu ca roluri si proces. Rolurile sunt:• Product Owner: este interfața cu clien-

tul, asigurându-se că produsul dezvoltat de echipă este prioritizat corespunză-tor și aduce valoare de business pentru client.

• Scrum Master: este responsabil cu faci-litarea procesului de Scrum (planning, grooming, daily scrum, retrospective, review, etc) si se asigură că echipa are toate condițiile pentru a-și atinge scopul: se ocupă de îndepărtarea impedimentelor, protejează echipa de intervenții din exterior. Scrum mas-ter-ul nu este managerul sau liderul grupului, însă are un rol de facilitator și protector.

• Echipa: este responsabilă să producă software care ar putea să fie folosit de către utilizatori într-un mediu de producție. Echipa are toate calificările necesare pentru a face software deve-lopment: cerințe, design, implementare, testare. Este recomandat să fie formată din până la 10 membri.

Procedeul Scrum se desfășoara în jurul unui interval fix de timp, numit Sprint. Durata unui sprint este de 1 - 4 săptă-mâni. Echipelor care încep sa folosească Scrum le este recomdat să folosească patru săptamâni pentru a se adapta la noua modalitate de lucru. Cum timpul, echi-pele vor micșora durata unui sprint, dar este important cu durata să fie menținută constantă în intervale mari de timp. În echipa mea folosim momentan sprint-uri cu durata de o săptămână.

Sprint-ul în sine trebuie considerat ca o

structură atomică. Acest lucru înseamnă că odată pornit, conținutul lui nu se schimbă. În cazuri excepționale, cu acordul echi-pei conținutul poate suferi modificări minore. De asemenea echipa poate decide să oprească un sprint prematur în cazul în care conținutul lui nu mai este relevant pentru business.

Product BacklogÎnainte de începerea unui sprint pro-

priu-zis este important ca product owner-ul să aibă creat un Product Backlog. Acesta descrie funcționalitatea dorită pentru pro-dus și priorititățile pentru funcționalitatea respectivă. Backlog-ul este un document viu, care va fi modificat constant de către product owner în cazul în care prioritățile sau functionalitatea se schimbă sau funcționalitate nouă este necesară pro-dusului. Product owner-ul este persoana care poate modifica backlogul, dar depin-zând de situație, am văzut cazuri în care și membri echipei contribuie. Din acest punct de vedere, poate fi o modalitate de a stimula membri unei echipe. Pe de altă parte, product owner-ul este singurul care prioritizează functionalitatea.

O modalitate simplă de a formula funcționalitatea cerută este folosirea for-matului de user story (folosit de extreme programming). Un user story are forma:

Ca [utilizator] aş vrea să [face ceva] pentru a [obține un scop].

Acesta este un exemplu mai specific:Ca utlizator aş vrea să mă pot loga pen-

tru a folosi functionalitea produsului.Un user story este de obicei însoțit de

criterii de acceptanță care definesc deta-lii adiționale care trebuie implementate pentru a considera un user story complet. Pentru exemplul de mai sus, criteriile de acceptanță ar putea fi:• Sistemul trebuie să afişeze pagina [X] în

cazul în care autentificarea este făcută cu success.

• Sistemul trebuie să returneze mesaje de eroare pentru combinații greşite de nume utilizator şi parolă.

Pentru produsele complexe, backlog-ul va crește considerabil și este foarte impor-tant ca acesta să fie revizuit. Procedul de revizuire se numește grooming. Revizuirea constă în evaluarea priorităților story-uri-lor, spargerea user story-urilor complexe în user story-uri mai simple, revizuirea conținutului user story-urilor și a criteriilor

de acceptanță. Revizuirea backlog-ului va face ca planificarea unui sprint să fie mai simplă. În echipa mea, groomingul se face o dată pe săptamână pe durata unei ore.

Definiția lui “Done”Înainte de a începe planificarea, orice

echipă trebuie să își definească criteriile după care un user story va fi considerat încheiat cu success. Aceste criterii formează definiția lui done. Iată câteva exemple de criterii pe care le-am folosit de-a lungul timpului, fiecare echipă de Scrum trebuind să determine ce are sens:• Cerințele definite împreună cu criteriile

de acceptanță.• Designul soluției agreat (și documentat

dacă e cazul).• Soluția implementată.• Codul soluției revizuit de către alți

developeri.• Unit testele implementate și rulate cu

success.• Testele de acceptanță implementate și

rulate cu success (automatizarea lor este benefică; aici se pot include și tes-tele de load).

• Documentația necesară este modificată (de exemplu: parametrii de configurare noi apăruți sunt menționați).

• Procesul de build modificat si toate tes-tele executate cu success.

• Soluția demonstrată cu success la sfârșitul sprint-ului.

Sprint PlanningSprint-ul este început cu o ședință

numită Sprint Planning. Aceasta folosește un interval fix de timp (de exemplu 8 ore) care este împărțit în două.

În prima parte, product owner-ul pre-zintă scopul dorit pentru sprint, împreună cu prioritatea fiecărui funcționalități din Backlog. Echipa încercă să înțeleagă cât mai mult din funcționalitate discutând si punând întrebări product owner-ului.

În partea a doua a sprint planning-ului, bazat pe informațiile pe care le are până la momentul de față, echipa va defini sco-pul sprint-ului creând așa numitul Sprint backlog. În sprint backlog se vor adăuga toate user story-urile pe care echipa consi-deră că le va putea implementa pe parcursul sprint-ului respectiv și care potențial vor putea folosite de către utilizatori la sfârșitul sprint-ului. Product owner-ul este de aseme-nea prezent pentru a răspunde la întrebări sau pentru a discuta împreună cu echipa


reducerea/creșterea scopului. Fiecare user story din sprint backlog

este estimat de către echipă folosing story points. Acestea reprezintă complexitea relativă a user story-urilor si nu neapărat timpul efectiv necesar pentru a termina un user story. O metodă clasică de măsurare a complexității (story points) ar fi nume-rele lui Fibonacci: 1, 2, 3, 5, 8, 13, 21, etc. În echipa mea am decis în ultima vreme să ne oprim la 13. Dacă un user story pare mai complex de 13 story points, încer-căm să creem user story-uri mai mici (vezi grooming).

Estimarea în sine se face ca și echipă. Există suficiente date statistice prin care s-a demonstrat că estimarea colectivă este întotdeauna mai aproape de realitate așa că nu o să insist asupra acestui aspect. Estimarea colectivă poate fi făcută folo-sim poker planning: fiecare membru din echipă estimează individual, dar toți mem-bri echipei își prezintă estimarea deodată pentru a se evita influențarea unor membri de către alții. De obicei, estimările exteme se discută pentru ca echipa să înțeleagă de ce anumiți membri consideră un user story prea simplu sau prea complex. În cele din urma, echipa poate să mai estimeze odată bazat pe discuțiile avute. La noi în echipă aplicăm un principiu al majorității în momentul în care estimările sunt foarte apropiate. Estimarea în story points este relativă și depinde de fiecare echipă (nu are sens să se compare dacă un user story cu 3 story points al unei echipe va avea aceeasi complexitate și în altă echipă). Estimarea în story points o să ajute echipa să încerce să evalueze cam în ce sprint va fi implementat un anumit user story.

Acest lucru este posibil pentru că după câteva sprint-uri echipa își va crea o viteză de execuție (velocity). Aceasta repre-zintă numărul de story points asociat user story-urilor pe care echipa reușește să le termine într-un sprint conform definiției lui “done”. Folosind această informație sta-tistică se poate crea o estimare a timpului necesar terminării backlogului folosind aceeași echipă. O echipă matura va reuși să stabilizeze viteza de execuție ca urmare a experienței acumulate în sprint-urile precedente.

Echipele care încep să facă Scrum, ar putea începe prin a asocia un story points cu interval de timp. Aceasta soluție ar compensa lipsa eventualelor date statistice ale echipei. De exemplu, un story point ar

putea fi ceva care dureaza patru ore.Odată încheiată planificarea, sprint-ul

poate să înceapă.

Daily ScrumÎn fiecare dimineață, membri echipei se

întâlnesc la o oră exactă pentru a discuta progresul sprint-ului. Participarea este obli-gatorie. Pentru a tine discuția focusată, toți membri echipei stau în picioare. Fiecare membru al echipei va răspunde doar la trei întrebări:• Ce a făcut de la ultimul daily scrum?• Ce își propune să facă până la următo-

rul daily scrum?• Ce impedimente nu îl lasă să își

desfășoare activitatea

Scrum master-ul poate pedepsi membri echipei care întărzie sau lipsesc. Încă nu am văzut asta în practică, dar o pedeapsă de 1 leu care eventual poate fi donat pare of idee bună. De asemenea Scrum master-ul este responsabil în a nu depăși 15 minute/daily scrum și a limita discuțiile la cele 3 întrebări specifice.

În cazul în care anumite impedimente sau probleme necesită o atenție specială, ele se pot discuta după daily scrum, implicând doar oamenii relevanți. În general, Scrum master-ul este responsabil cu eliminare impedimentelor, dar vor exista situații în care va avea nevoie de suport de la mem-bri echipei sau externi, deci delegarea este acceptabilă, atât timp cât rezolvarea proble-mei în sine va fi urmărită de către scrum master.

Sprint BurndownOdată scopul unui sprint definit, echipa

trebuie să aibă o modalitate de a-și urmări progresul zilnic. Sprint Burndown este de cele mai multe ori un grafic care arată cât mai este până când toate user story-urile sprint-ului vor fi terminate. Mai jos este un exemplu în care:• Axa X arată numărul de zile al

sprint-ului.• Axa Y arată numărul de story points al

sprint-ului (alte echipe pot folosi numă-rul de user story-uri).

• “Ideal” înseamnă progresul ideal pen-tru ca echipa să termine la timp tot ce și-a propus.

• “Actual” înseamnă progresul actual al echipei.

Este important ca burndown-ul să

fie modificat conform definiției lui done pe care echipa o folosește și să arate pro-gres doar cand un user story este done. Ca și regulă de bază, în scrum se preferă să ai 50% din user story-uri done, decât să ai toate use story-urile “aproape” done. Ideea e că un user story done reprezintă funcționalitate care poate fi demonstrată sau pusă în producție astfel încât să poată

fi folosită.

Sprint Review În ultima zi a sprint-ului, împreuna cu

product owner-ul, se face un review a ceea ce s-a realizat. Echipa demonstrează pro-duct owner-ului funcționalitatea realizată. Product owner-ul este încurajat să își pre-zinte feedbackul. Aceasta va fi folosit de către echipă in sprint-urile următoare sau poate face ca un user story sa nu mai fie considerat done și să fie planificat din nou. În echipa mea, folosim sprint review și pen-tru a decide dacă o să punem în producție funcționalitatea implementată în sprint-ul respectiv. Durata reviewului este de obicei în jur de două ore.

Sprint RetrospectiveDupă review, membrii echipei ana-

lizează ce a mers bine și ce trebuie îmbunățățit în desfășurarea procesului de scrum. Fiecare membru al echipei trebuie să participle cu idei. Prin rotație, un mem-bru al echipei notează punctele importante. Este important ca focusul retrospectivei să fie pe lucrurile pozitive care s-au întâmplat de-a lungul sprint-ului. De asemenea este important ca pentru lucrurile negative să se planifice acțiuni specific pentru corectarea acestor situații.

Membri echipei trebuie să fie deschiși în a da și a primi feedback ca parte a retros-pectivei. Faptul că oamenii pot discuta deschis problemele întâmpinate cât și rea-lizările este un exemplu clar al unei echipe mature de scrum.

Subiectele discutate în retrospectivă trebuie să fie specific și nu generale pe cât posibil. De exemplu:

“Comunicarea în echipă a fost bună” ar

Agile Software Development folosind Scrummanagement



avea mai mult sens ca “Andrei m-a ajutat să rezolv problema X. Făra ajutorul lui nu aș fi reușit asta”.

Când Scrum nu funcționeazăExistă situații în care folosirea Scrum

nu este recomandată, sau cel puțin e nevoie de adaptări specifice. Iată câteva exemple:

A. Echipe distribuite: dacă membri echipei nu sunt în aceeasi locație este destul de complicat ca ei să funcționeze ca o echipă Scrum. Distribuirea afectează cel mai mare asset al Scrum-ului: interacțiunea. Același lucru este aplicabil dacă product owner-ul nu este colocat cu echipa. O alternativă ar fi împărțirea echipei astfel încât să se limiteze efectele distribuirii.

B. Echipe neechilibrate: dacă o echipă nu are în componență câțiva oameni seniori, ideea de echipa care se auto-orga-nizează se va transforma destul de repede în haos. Din ce am văzut o rație de 1:2 între seniori și juniori funcționează destul de bine.

C. Organizații care nu oferă suport pentru Scrum: există organizații care consideră că dacă vor cere echipei de dez-voltare să fie agilă, înseamnă că schimbări de direcție pot exista în orice moment fără a avea impact asupra ceea ce se execută sau asupra datelor de release.

D. Echipe care fac mentenanță: proce-sul de mentenanță înseamnă în principiu fixarea de probleme care apar în sisteme de producție. În cazul astă, o abordare Kanban pare mai simplă, pentru că eli-mină necesitatea planificări unui sprint, fiecare zi putând schimba cel mai prioritar bug care trebuie fixat. De asemenea, unele bug-uri de producție sunt mai greu de fixat din cauza informației limitate (mai puține loguri), făcând astfel irelevantă o eventuală estimare a efortului necesar. Am încercat să folosesc Scrum pentru situația asta și am realizat că este nu este prea folositor com-parat cu Kanban.

Lucruri necesare pentru a face Scrum

Product backlog-ul în sine trebuie menținut folosind un tool. Am vazut exem-ple de product backlog în MS Excel. În ultimul timp am folosit Scrum Works Pro și Jira. De asemenea ambele tool-uri oferă suport de a vizualiza sprint burndown, dar am renunțat la această funcționalitate și folosim un poster pe un perete care este modificat zilnic de către Scrum master.

Pare că această abordare are un efect mai bun asupra echipei: îl putem modifica și vizualiza în timpul daily scrum-ului.

Limitarea lucrului în progres este o recomandare care vine din principiile de lean manufacturing. Echipa trebuie să se focuseze în a termina user stories conform definiției lui done și nu la a începe cât mai multe. În momentul când cineva lucrează la mai mult de două lucruri simultan intervine o problemă de concentrare care afectează productivitatea. Recomandarea ar fi să îți ajuți mai bine un coleg dacă ai terminat ce aveai sau este temporar blocat, decât să începi ceva nou.

Feedback-ul rapid al calității poate fi dat doar de către tool-uri automate. Orice echipă care face Scrum trebuie să aibă un sistem de build continuu. Noi folosim Jenkins în mometul de față. Sistemul de build continuu trebuie sa creeze un build, dar să și ruleze teste automate pe buildul respectiv. Noi folosim JUnit si diferite variații de implementari Mock (JMock, Mockito, etc). Membri echipei au obligația să scrie teste automate pentru codul nou scris. O tehnică interesantă se numește Test Driven Development (TDD) și implică scrierea de teste înainte de scrierea de funcționalitate. Nu am vazut-o însă folosită prea mult de către developeri. De aseme-nea, Sonar ruleaza o dată pe săptămână pentru a colecta metrici legate de calitatea din punct de vedere a folosirii Java ca lim-baj de programare.

Pentru testele de acceptanță folosim Selenium împreună cu o implementare custom care ne permite generarea de rapoarte implementată in Ruby on Rails. Testele de accepanță rulează de câteva ori pe zi pe un server care este instalat într-un mediu similar cu cel din producție și veri-fică corectitudinea aplicației din punct de vedere functional. Este posibil, folosind Selenium să verificăm și corectitudinea UI-ului dar necesită un volum mai mare de muncă. În trecut am mai folosit JMeter pentru load testing.

Pentru menținerea calității codului si răspândirea cunoștințelor se poate folosi fie code review fie pair programming. Code review implică revizuirea codului după ce a fost scris și poate fi făcut ad-hoc sau for-mal. Există chiar si tool-uri care ajută cum ar fi Code Collaborator. O altă modalitate ar fi pair programming, împrumutată din extreme programming, în care doi develo-peri stau în fața unei singure tastaturi pe

care o împart pentru a scrie code pentru aceeași funcționalitate. Această metodă este mai dinamică decât code reviewul și eventual mai puțin plictisitoare. Totuși nu am vazut-o folosită full time de către echipă, dar mai mult în moment de nevoie.

Membrii echipei trebuie sa aibă calități multi-funcționale. De câteva săptamâni experimentăm ca echipă testarea manulă. Adică toată lumea este responsabilă să ajute echipa de testare cu rularea testelor manu-ale. Ca urmare, sistemul de bug tracking a fost suprasolicitat, dar până la urmă ceea ce dorim este să avem avem o situație clară a calității și o confidență sporită în a face un release. Acesta e doar un exemplu care a funcționat bine la noi în echipă.

ConcluzieScrum este un proces foarte simplu

ca și ceremonii. Puterea lui stă în puterea unei echipe de a funcționa din ce în ce mai bine, favorizând interacțiunea mem-brilor ei. Scopul final este de a avea un client mulțumit care poate să evalueze rapid impactul pe care o funcționalitate a produsului său o are asupra utilizatorilor. Dacă o organizație decide să facă Scrum sau orice altă formă de agile software development este recomdat să nu încerce să adapteze procesul de la început, ci doar după ce echipele se simt confortabil în a folosi metoda respectivă.


Big Data

VolumBeneficiul obținut de pe urma iefti-

nirii continue a hardware-ului, inclusiv a mijloacelor de stocare constă în capacita-tea de a stoca cantități imense de date la prețuri rezonabile și care nu mai sunt doar la îndemîna Google sau Yahoo.

Date a căror cantitate în ultima peri-oada a crescut exponențial, datorită: social media prin care mai toată lumea conec-tată la internet generează și consumă date, probelor de GPS generate de smartphone-uri, imaginilor din satelit, ș.a.m.d și nu în ultimul rând a rețelelor de WIFI și 3G care facilitează toate acestea.

Dar stocarea datelor este doar jumătate din ecuație, cealaltă jumătate o reprezintă

capacitatea de a analiza volume uriașe de date.

Trebuie menționat ca există o relație duală între cantitatea de date și capacitatea de a le analiza. Făra una nu ar exista cea-laltă. Mai exact avînd mai multe date e mai valoros decît a avea modele matematice mai bune, adică chiar și folosind o mate-matică primară se pot extrage informații foarte valoroase avînd seturi de date mari, pe când dacă cantitatea de date e insufi-cientă nici cei mai buni algoritmi nu pot extrage informații valoroase.

Volumul de date este și cel care dezvă-luie problema cea mai evidentă, cea legată de stocarea scalabilă a datelor și necesitatea interogării distribuite a datelor.

De ce “big data”? Pentru că e un subiect la modă, pentru că piața pentru “big data” este un business de 70 de miliarde de dolari pe an cu o creștere de 15% de la an la an.

Pentru că mai toate companiile mari de soft investesc în soluții orientate către “big data”, pentru că pe internet, zilnic, se generează o cantitate imensă de date (de ordinul sutelor de petabytes) și pentru ca toate aceste date sunt stocate și marea majoritate sunt supuse unor procese de analiză a datelor. Analiză care sa extragă informații utile pentru cei care le dețin, informații care de regulă duc la creșterea business-ului, amintim doar cîteva: detectarea patternului de cumpărare a utilizatorilor, o mai bună targetare a recla-melor, detectarea fraudelor, etc.

Pentru că “big data” și tehnologiile care-l inconjoară atrag “talentele”, programatorii de top, de pe piața.

Dar ce este “big data”? Anecdotic vorbind “big data” este “buzzwordul” anului 2012.Dacă ar fi sa dăm o definiție oarecum formală, aceasta ar fi: “cantitatea de date a căror

dimensiune duce la depășirea capacității de procesare a unei baze de date convenționale”. Depășire datorată fie efectiv cantității uriașe de date, fie din cauză că se generează o can-titate mare de date la intervale de timp foarte scurte si repetate, fie din cauza că datele nu se supun regulilor stricte ale sistemelor RDBMS.

Altfel spus ca să caracterizăm “big data” putem folosi cele 3V-uri, volum, viteză și varietate.

Robert [email protected]

Senior Software Developer @Betfair

programare



Dacă eliminăm ca și opțiune siste-mele RDBMS pentru rezolvarea acestei probleme practic avem de ales între două soluții. Pe de o parte sisteme de tip “data warehouse” (de exemplu: Greenplum), pe de altă parte sisteme bazate pe Hadoop .

De obicei alegerea uneia sau alteia se face ținînd cont de celelalte 2 V-uri. De regulă sistemele de tip “data warehouse” implică scheme predefinite, pe de altă parte Hadoop nu impune nicio restricție asupra structurii datelor.

L a bază , Hado op este o plat -formă pentru distribuirea problemelor computaționale pe mai multe servere. A fost dezvoltat și mai apoi ”open sourced” de către Yahoo, și are la bază MapReduce, care la rîndul lui a luat naștere în cadrul Google fiind folosit la indecșii de căutare.

Hadoop MapReduce implică distribu-irea unui set de date pe mai multe servere și executarea de operații pe acestea, faza de ”map”, operații care se execută concurent. Rezultatele parțiale sunt apoi combinate pentru a obține rezultatul final, partea de ”reduce”.

Pentru a stoca datele Hadoop are pro-priul lui sistem de fișiere distribuit, numit HDFS (Hadoop filesystem).

VitezăRata de creștere a vitezei cu care curg

datele a urmat un tipar asemănător cu cel al creșterii volumului de date. Probleme care acum ceva timp se aplicau unor domenii specifice, cum ar fi cele de trading, au ajuns să fie mult mai generale.

Modalitățile prin care livrăm și con-sumăm produse online sunt din ce în ce mai instrumentate, fiecare click și fiecare interacțiune este urmărită, nu doar cum-părarea efectivă. Cei care sunt în măsură să analizeze rapid aceasta informație, de exemplu, recomandînd produse simi-lare, au un avantaj competițional iar era smartphone-urilor și a internetului mobil a amplificat acest fenomen.

Problema nu o constituie doar viteza cu care intră datele, acestea s-ar putea stoca pentru o procesare ulterioară, ci importanța rezidă în viteza buclei de feed-back. Sunt situații cînd pur și simplu nu există timp pentru a aștepta ca un job de Hadoop să se execute.

Terminologia folosită pentru datele care se “mișca” atît de rapid e “flux de date” (data streaming). Există doua motive pen-tru a lua în considerare “fluxul de date”.

Primul caz este cînd datele de intrare “curg” prea repede ca să poată fi stocate în totalitate, astfel că o analiză a datelor este necesară înainte de stocarea propriu-zisă. Al doilea caz este cînd aplicația necesită un răspuns imediat referitor la datele de intrare. Ca și produse open source folo-site pentru manipularea “fluxului de date” amintim Storm de la Twitter și Yahoo S4.

Cum am menționat mai sus, nu este vorba doar despre datele de intrare. Viteza cu care se generează rezultatele contează și ea. Cu cît este mai scurta bucla de feedback cu atît mai mare este avantajul competițional. Rezultatele pot ajunge direct într-un produs, sau pot ajunge în console care sunt folosite pentru luarea deciziilor.

Această nevoie pentru viteză, în spe-cial pe web, a dus la dezvoltarea bazelor de date de tip cheie-valoare, de tip coloana și de tip document. Aceste tipuri de baze de date formează categoria bazelor de date de tip NoSQL, folosite atunci cînd modelele relaționale nu sunt cele potrivite. Cîteva din cele mai cunoscute baze date de tip NoSQL sunt: MongoDB, Couchbase, Apache Cassandra, Voldemort, HBase, Riak.

VarietateRareori datele se prezintă într-o forma

ordonată perfect și gata spre a fi proce-sată. O temă comuna a “big data” este faptul că datele sunt diverse, eterogene și nu se muleaza pe structuri relaționale. Datele pot fi text din rețele sociale, pagini web care trebuiesc indexate, imagini, date brute provenite de la diverși senzori. Unul din principalele scopuri ale proce-sării “big data” este să transforme și să extragă din date nestructurate sens, care mai apoi poate fi interpretat de oameni sau să fie folosit ca și input structurat pentru aplicații. Procesul prin care se realizează această transformare implică pierderea de date, ceea ce inseamnă că invariabil anu-mite informații se vor “arunca”. Unul din principiile “big data” spune că atunci cînd este posibil păstrează toate datele, deoarece odată pierdută informația nu mai există cale de întoarcere.

Chiar daca sitemele RDBMS sunt în prezent populare și bine înțelese, ele nu ar trebui să fie destinația de facto nici pentru informațiile obținute de pe urma proce-sării “big data”. Anumite tipuri de date se pretează a fi stocate de alte tipuri de baze de date. Spre exemplu documentele de tip XML se pretează a fi stocate în sisteme de

stocare dedicate pentru XML (de exemplu MarkLogic). Datele din rețele sociale se prezintă mai degrabă sub forma de grafuri, iar pentru acestea ar fi de preferat bazele de date de tip graf (de exemplu Neo4j).

Chiar dacă datele s-ar putea reprezenta într-o structură relaționala relativ ușor, un alt dezavantaj al sistemelor RDBMS constă în natura statică a schemei bazei de date. Ori într-un mediu agil, evolutiv structura rezultatelor se schimbă odată cu evoluția operațiilor de analiză. Iar din acest motiv bazele de date semi-structurate, de tip NoSQL sunt de preferat.

Concluzie În încheiere trebuie precizat că “big

data” nu este leacul universal. Ca acesta să funcționeze trebuie să fie foarte clar ce anume vrem să tratam. Un sfat pentru cei care vor să pornească pe calea “big data”, ar fi să clarifice ce problemă vor să rezolve.

Daca alegeți să rezolvați o problemă de business reală, spre exemplu care din modalitățile de publicitate măresc numă-rul consumatorilor, aceasta vă va ghida și implementarea.

În articole viitoare vom detalia folosi-rea Hadoop, baze de date NoSQL și partea de analytics (mai ales legată de vizualizarea datelor).

Aștept comentari i le voastre pe www.todaysoftmag.ro.


Programarea funcţională

Programarea funcţională (FP) https://en.wikipedia.org/wiki/Functional_pro-gramming este un concept destul de vechi apărut în anii ‘50 odată cu crearea limbajului Lisp. Se bazează pe “calculul lambda”, care e o ramură a matematicii

introdusă în anii ‘30 de catre Alonzo Church https://secure.wikimedia.org/wikipedia/en/wiki/Lambda_calculus.

Elementul central în FP sunt funcțiile și în general se lucrează cu structuri de date imutabile și funcții pure. În general limbajele funcționale oferă un set de unelte care ușurează mult lucrul cu funcții.

Limbaje funcționaleCele mai cunoscute limbaje funcționale

pot fi grupate în urmatoarele familii: Lisp (Lisp, Common Lisp, Scheme, Clojure), ML (Standard ML, CAML, OCAML, F#), lim-bajele funcționale pure (Haskell, Clean), limbaje concurente (Erlang, Oz, Scala). Tabelul de mai jos arata o harta a principa-lelor limbaje funcționale, anul aparitiei lor și influentele dintre ele.

Nici un limbaj de uz general nu poate fi exclusiv funcțional. Toate limbajele enume-rate mai sus sunt predominant funcționale,

dar au și elemente imperative pentru că un program scris pur funcțional, fără “side effects”, nu poate comunica cu exteriorul. Cineva glumea: pentru a observa un pro-gram pur funcțional, tot ce putem face este sa punem mâna pe carcasa calculato-rului și sa simțim cum se încălzește. Deci, în general limbajele de programare sunt “multi-paradigmă”: unele predominant imperative cu elemente funcționale, iar altele predominant funcționale cu elemente imperative.

Ovidiu [email protected]

Consultant software independent specializat în metode de dezvol-tare agile şi limbaje funcţionale.

În timpul liber practică înotul, alpinismul şi motocrossul.

programare



Lisp/Common Lisp/SchemeA apărut în anii ‘50 ca primul lim-

baj care suporta tehnici de programare funcțională. Este un limbaj multiparadigmă cu tipuri dynamic-typed și strong-typed și evaluare imediată .

Numele ii provine de la LISt Processing pentru că este specializat pe lucrul cu liste. Totul este o lista în LISP, atât datele cat și codul. Astfel în Lisp se poate modifica codul ca și pe niște structuri de date printr-un un sistem de macrouri foarte puternic care permite programatorilor să modifice sin-taxa și să creeze limbaje specializate pentru diverse domenii (DSL)http://en.wikipedia.org/wiki/Domain-specific_language

În timp au apărut multe dialecte Lisp, cele mai cunoscute fiind Scheme, Common Lisp și Clojure.

ClosureEste un dialect modern al Lisp

creat în 2007. Unul dintre atuurile sale este suportul pentru concurență prin “Software Transactional Memory” h t t p s : / / e n . w i k i p e d i a . o r g / w i k i /Software_transactional_memory.

Rulează în JVM și CLR iar un subset al Clojure, ClojureScript, poate fi compilat în Javascript.

ML/Standard MLEste un limbaj funcțional impur dezvol-

tat în anii ‘70 la Universitatea Edinburgh. Tipurile sunt statice iar evaluarea expresii-lor se face imediat (eager).

Cele mai cunoscute dialecte sunt Standard ML (SML), Caml, OCaml și F# iar limbaje cum ar fi Haskell și Clean au fost puternic influențate.

OCamlEste un limbaj ML multi-paradigmă cu

suport atât pentru programare funcțională cât și pentru programare orientată obiect.

Limbajul este static-typed, dar în majoritatea cazurilor tipurile pot fi omise, iar compilatorul, prin mecanismul de inferență, le deduce singur.

O C am l e s t e c u n o s c u t p e nt r u performanța sa destul de apropiată de o implementare echivalentă în C.

F#Este partial compatibil cu OCaml și

a fost creat de Microsoft pentru a rula în mediul .NET. Are suport pt .NET și ruleaza pe CLR și Mono.

ErlangEste un l imbaj de programare

funcțional și concurent dezvoltat în anii ‘80 de către Ericson și a fost folosit initial în aplicații de telefonie. Este gândit pentru scrierea de aplicații concurente, distribuite, tolerante la erori și soft-real-time. Este un limbaj dynamic-typed și strong-typed.

Concurența este implementată folosind modelul actorului. http://en.wikipedia.org/wiki/Actor_model iar mașina virtu-ală poate suporta sute de mii de procese lightweight independente. Fiecare proces are date proprii și accesează date comune doar read-only (cu mici excepții) deci gar-bage-collectorul poate rula per-proces, cu rezultate foarte bune din punct de vedere a performanței.

ScalaEste un limbaj de programare orien-

tat obiect și funcțional, static-typed și cu inferența de tipuri.

Rulează pe JVM, CLR sau Android și poate folosi biblioteci scrise în Java sau C#.

Concurența este suportată atât prin pri-mitive de sincronizare, cât și prin modelul actorului, asemănător cu abordarea Erlang.

HaskellEste un limbaj pur funcțional, lazy și

static typed. . Lucrul în stil imperativ se face prin folosirea monadelor. Efectele secundare ale funcțiilor trebuie declarate în semnătura acestora.

Fiind un limbaj pur funcțional concurența și paralelismul sunt foarte ușor de implementat. Pentru paralelism se pot folosi thread-uri clasice combinate cu date shared mutabile (MVars). Alte soluții sunt Software Transactional Memory - concept implementat pentru prima data în Haskell - , “sparks” - operatii care pot fi executate în paralel dacă mașina virtuală considera ca e avantajos - sau paralelizarea operațiilor pe unele structuri de date (“data paralelism”).

CleanEste un limbaj pur funcțional dezvol-

tat în anii ‘80. E destul de asemănător cu Haskell dar cu o abordare diferită în ceea ce privește efectele secundare. Funcțiile care produc efecte secundare folosesc tehnica “uniqueness typing” astfel un obiect odată alterat nu mai poate fi folosit mai departe, fapt care e verificat de compilator. Această tehnică permite compilatorului să producă un cod mai eficient, motiv pentru care

Clean e considerat mai eficient și mai ușor de optimizat decât Haskell.

Tehnici de programare funcționalăVoi prezenta câteva elemente de bază

prezente în limbajele funcționale. O parte dintre ele se găsesc și în unele limbaje imperative.

Functiile sunt “first class citizens”Un limbaj funcțional are în primul

rând funcțiile ca “first class citizens”. Asta înseamnă că funcțiile sunt tratate ca orice alte variabile. O funcție poate primi ca parametru alte funcții și poate returna funcții noi.

Un exemplu ar fi decoratorii din Python:

Decoratorul de mai sus poate fi folosit astfel:

... cu urmatorul rezultat:

Un exemplu de funcții pasate ca para-metrii în Haskell ar putea fi un operator “forward pipe” pe care îl putem defini astfel

...și care primește o valoare și o funcție si returnează rezultatul aplicării funcției. Acesta ne permite să folosim sintaxa urmatoare:

Odată ce funcțiile sunt folosite ca orice alte obiecte, în mod natural, urmează alte

def log_call(f): def wrapper(*args, **kwargs): print “Calling f with arguments (%s,%s)” % ( args, kwargs) try: result = f(*args, **kwargs) print “Result: %s” % result except Exception as ex: print “Exit by exception %s” % ex raise return wrapper

@log_calldef my_function(a, b, c): return (a+b)/cmy_function(1,2,3)my_function(4, 2, 0)

$ python example.pyCalling f with arguments ((1, 2, 3),{})Result: 1Calling f with arguments ((4, 2, 0),{})Exit by exception integer division or modulo by zeroTraceback (most recent call last): File “example.py”, line 18, în my_function(4, 2, 0) File “example.py”, line 5, în wrapper result = f(*args, **kwargs) File “example.py”, line 14, în my_func-tion return (a+b)/cZeroDivisionError: integer division or modulo by zero

x |> f = f x

double x = 2 * xdoubleAppliedThreeTimes x = x |> double |> double |> double


câteva elemente esențiale care ne ușurează mult lucrul cu funcții.

Functii “inner” și “closures”Funcțiile declarate în interiorul altor

funcții, ca si decoratorul din exemplul de mai sus, se numesc “inner functions”. Uneori o funcție inner accesează valori din namespace-ul funcției părinte, caz în care se numește “closure”. Valorile accesate sunt transmise transparent funcției inner.

Mai jos e un exemplu de closure în C#:...care la rulare va tipari:

În exemplul acesta, funcția internă

“delegate” folosește variabilele name și value din contextul în care a fost creată.

Funcții anonimeCând se lucrează în stil FP de multe ori

e nevoie de funcții simple folosite într-un singur loc. În general, se folosesc împreună cu funcțiile de nivel înalt map, fold, filter sau ca și predicate pentru funcții cum sunt find, count etc

În exemplul anterior delegate-ul este o funcție anonimă iar mai jos avem un exem-plu de folosire în C++ 0x11, ca predicat în apelul funcției count_if

Compunere de funcțiiÎn matematică dacă h(x) = f(g(x))

...putem scrie că h = f *g...care se citeste “h este funcția obtinută

prin compunerea funcției f cu funcția g”.Evident a doua sintaxă este mult mai

curată pentru ca exprima ideea direct, fără a ne arăta cum se transmit parametrii.

Să presupunem că sunt deja implemen-tate funcțiile reverse(care inversează o lista) și sort(care sortează în ordine crescătoare o lista) și dorim să implementam o funcție care sortează în ordine descrescătoare o listă.

În Python codul ar arata în felul urmator.

În C++ codul e similar, având în plus doar acoladele pentru definirea blocurilor respectiv tipurile parametrilor și de retur.

În schimb în F# se preferă operatorul de compunere care arată astfel:

...și care produce o sintaxă ușor lizibilă.În Haskell, se poate implementa prin

compunere de funcții, folosind operatorul (.) sau prin “forward pipe” folosind opera-torul (>>>). Astfel cele două funcții de mai jos sunt (aproape) echivalente:

După cum se vede în Python sau C++ ne lovim de detaliile referitoare la trans-miterea parametrilor, iar în limbajele care suportă compunerea de funcții, codul e mult mai clar și concis.

Acest stil de a scrie funcțiile, fără para-metrii expliciti se numeste “point-free style”. În stilul funcțional se preferă defini-rea funcțiilor în stil point-free când acest lucru e posibil.

Aplicare parțialăÎn teoria calculului lambda o funcție

poate primi doar un singur parametru. O funcție care primește doi parametri int și

returnează un int este văzută ca și o funcție care primește un parametru int și retur-nează o funcție care primește un parametru int și returnează o funcție.

Astfel pentru o funcție care primește N parametri putem fixa primii M parametri (M < N) și obtinem o funcție care primește N-M parametri.

De exemplu, în Haskell, dacă avem definită funcția multiply astfel:

...putem defini funcția double și triple astfel:

Functia double apelată de exemplu cu parametrul 10 returnează rezultatul apelu-lui multiply 2 10.

Astfel o funcție care înmulțește cu 2 toate elementele unei liste ar putea fi scrisă astfel:

... sau scrisă în stil “point free”:

...sau folosind o funcție anonimă în loc de multiply:

Acest lucru a fost posibil datorită fap-tului că limbajul suportă funcții ca “first class citizens”, functii anonime si aplicarea parțială.

Notă: În plus Haskell suporta “operator sections” pentru operatorii binari, astfel funcția de mai sus s-ar putea scrie și mai concis astfel:

Este remarcabil cât de concis și de lizi-bil este acest cod, odată ce suntem familiari cu funcția map.

List comprehensionAvând în vedere faptul că în stil

funcțional se lucrează foarte mult cu liste, e nevoie sa descriem transformările aplicate pe liste într-un mod clar și concis.

În Python o funcţie care returnează elementele din produsul cartezian a două mulțimi, în care prima componenta este mai mare decât a doua, arată în felul următor:

În Haskell aceeași funcție se scrie astfel:

În Erlang, pe lângă list comprehension, există și binary comprehension, prin care în loc de liste se produc structuri de date

using System;class Example { static Action CreateAction(string name, int value) { Action a = delegate { System.Console.WriteLine(“Action name: ‘” + name + “’ value: “ + value); }; return a; } static void Main(string[] args) { Action a1 = CreateAction(“action1”, 10); Action a2 = CreateAction(“action2”, 20); a1(); a2(); }}

#include <algorithm>#include <iostream>#include <vector>int main(){ std::vector<int> v = {1,2,3,4,5,5,5,6,6,7,7,7,8}; int even_count = std::count_if(v.begin(), v.end(), [] (int n) { return n % 2 == 0;}); std::cout << “Even numbers: “ << even_count << std::endl;}

$ mcs closure.cs && mono closure.exeAction name: action1 value: 10Action name: action2 value: 20

def reverse_sort(seq): return reverse(sort(seq))

std::vector<int> reverse_sort(const std::vector<int>& seq) { return reverse(sort(seq));}

reverse_sort = sort >> reverse

reverseSort = reverse.sort reverseSort’ = sort >>> reverse

multiply a b = a * b

double = multiply 2triple = multiply 3

doubleAll xs = map (multiply 2) xs

doubleAll = map (multiply 2)

doubleAll = map (\x -> x * 2)

doubleAll = map (*2)

def f(m1, m2):return [(x,y) for x in m1 for y in m2 if x>y]

f m1 m2 = [ (x,y) | x <- m1, y<- m2, x>y]

Programarea funcţionalăprogramare



binare. E o funcționalitate foarte utilă în lucrul cu protocoale binare, care e una din-tre specialitățile Erlang.

Toate tehnicile prezentate mai sus ne dau posibilitatea să scriem un cod foarte clar și concis. Din acest motiv limbajele imperative moderne au introdus tehnici funcționale.

Limbaje pur funcționaleUn limbaj pur funcțional este un limbaj

funcțional în care structurile de date sunt imutabile, iar funcțiile nu produc efecte secundare nedeclarate. Limbaje cum ar fi Haskell sau Clean separă prin sistemul de tipuri funcțiile pure de cele impure, dar folosesc abordări diferite.

În Haskell, felul în care este executată o secvență de funcții impure care produc efecte secundare de un anumit tip este descris de o “monadă”. Pentru fiecare tip de efecte secundare avem o alta monadă. Astfel toate funcțiile care produc efecte de input/output se execută în monada IO, funcțiile care modifica stare externă se exe-cută în monada State etc. Pentru a putea produce efecte secundare, o funcție tre-buie sa fie executată în monada respectivă. Astfel compilatorul va da o eroare în cazul în care o funcție care nu este în monada X apelează o altă funcție cu efecte secundare de tip X.

În Clean funcțiile impure, care alterează starea unor obiecte vor primi obiectele respective ca și “obiecte unice”. Un obiect unic poate fi folosit o singura data. Astfel o funcție, odată ce a alterat un obiect unic, va returna pe lângă valoarea normală de retur și noua versiune a obiectului alterat. Apelatorul funcției va folosi obiectul nou în continuare, utilizarea celui vechi fiind interzisă de compilator.

Concluzie

AvantajeÎn primul rând limbajele funcționale ne

pun la dispoziție niște unelte de nivel foarte înalt care ne fac foarte productivi. Apoi, în limbajele pur functionale, faptul că efec-tele secundare sunt foarte clar localizate ne ajută să scriem un cod mai robust. Astfel nu putem avea surpriza neplăcută că o funcție “product”, pe lângă faptul că returnează produsul parametrilor mai și scrie rezul-tatul într-un fișier. Această separare poate fi garantată de către compilator. Asta crește mult claritatea și calitatea codului rezultat.

Se zice că în Haskell compilarea e cea mai dificilă parte, iar odată codul compilat el este fără bug-uri. Desigur e o exagerare, dar are totuși o parte de adevăr. Sistemul de tipuri este atât de bine pus la punct încât greșelile normale pentru alte limbaje aici sunt sesizate în faza de compilare.

În cazul limbajelor funcționale impure efectele secundare pot fi prezente, dar în general ele sunt descurajate, iar stilul de lucru funcțional ne face în general mai atenți la prezența acestora.

Un alt avantaj al faptului că se lucrează predominant cu funcții pure este că testa-rea, refactorizarea, paralelizarea și diverse optimizări devin mult mai simple. În articolul precedent din serie am discutat aceasta problema.

Chiar dacă nu avem de-a face cu limbaje funcționale pure paralelizarea e mult mai usoară dacă se lucrează în stil funcțional. Limbaje ca Erlang, Clojure, F#, Haskell sunt cunoscute pentru usurința cu care se scriu aplicațiile paralele.

Tendința “many-core” din arhitecturile hardware de azi cere tot mai mult para-lelism, iar estimările zic că numărul de core-uri dintr-un procesor “standard” se vor dubla la fiecare 2 ani. Asta înseamnă ca într-un viitor destul de apropiat vom ajunge să lucrăm pe sisteme cu zeci sau sute de core-uri. Aplicațiile nu vor putea profita automat de numărul mare de core-uri decât dacă arhitectura lor permite paralelismul masiv și procesarea pe zeci, sute sau mii de fire de execuție. Ca si exem-plu, în Erlang aplicațiile cu zeci sau sute de mii de fire de executie sunt întâlnite frec-vent în producție. E destul de evident că cele mai potrivite limbaje pentru scrierea unor aplicații masiv paralele sunt limbajele funcționale care de multe ori fac paralelis-mul aproape trivial.

DezavantajePercepția generală este că limbajele

funcționale au performanță mai scazută. Este doar parțial adevărat. În general lucrînd în stil funcțional se folosesc struc-turi de date imutabile care sunt mai puțin eficiente.

De exemplu modificarea unui element într-o listă înlănțuită presupune:

1. crearea unei liste noi care contine aceleași elemente de la început până înain-tea elementului modificat.

2. crearea unui nod nou cu valoarea nouă a elementului.

3. legarea nodului nou de restul listei existente.

Deci, atât din punctul de vedere a memoriei consumate, dar și ca timp de execuție, modificarea listei imutabile este mai costisitoare. Pe de altă parte avem un avantaj în faptul că nu avem nevoie de sincronizare. Lista originală rămâne nemo-dificată și ceilalti utilizatori ai ei nu sunt deloc afectați. Acesta este un câștig dacă utilizatorii respectivi sunt în thread-uri diferite de executie sau pe mașini diferite.

Pe de alta parte, avem posibilitatea de a folosi structuri de date mutabile și eficiente acolo unde e nevoie chiar și într-un limbaj funcțional. Deci putem identifica zonele cu probleme de performanță și să schimbăm eleganța și robustețea codului funcțional pentru performanța codului imperativ unde e nevoie. Deci afirmația că limbajele funcționale sunt mai slabe din punctul de vedere al performanței este falsă. Conteaza în mare parte ce structuri de date folosim.

De asemenea, referitor la performanță, sunt destul de frecvente situațiile în care aplicatii scrise original în limbaje impera-tive și apoi rescrise în limbaje funcționale cum ar fi Haskell, Ocaml sau F# sunt cel puțin la fel de rapide ca și implementarea originală, dar cu un cod mult mai mic și mai robust.

O altă problemă ar fi faptul ca în limba-jele funcționale “lazy” (ex Haskell) e greu de estimat cât va dura o anumită operație. Aceasta pune probleme în special în siste-mele soft-real-time.

Totuși, pricipala problemă care î n c e t i n e ș te a d opt are a l i mb aj e l or funcționale este faptul că programatorii trebuie să își schimbe radical felul de a gândi. În abordarea funcțională problema se pune “ce face aplicația?” si nu “cum face?”. Gândind astfel nevoia de produce efecte secundare dispare într-o mare parte din cod, excepție facând doar acele com-ponente care interacționează cu lumea imperativă din jur.

Cu toate acestea industria face din ce în ce mai mult loc limbajelor functi-onale. Exemple ar fi Erlang în care s-au scris aplicații foarte populare cum ar fi RabbitMQ, CouchDb, Riak sau ejabb-erd, Haskell care e din ce în ce mai folosit în aplicații în care calitatea codului este esențială.


Exploratory Testing,o dezbatere…la modă

Despre Exploratory testing e în principal tes-

tarea pe care o faci evitând urmărirea și executarea unor testcase-uri deja scrise. Exploratory presupune să înveti produsul, să creezi și să corelezi o suită de teste cu o suită de date, în cele din urmă să le execuți. Toate acestea într-un singur om, în aceelași timp și într-o maniera mai degajată, con-sider eu.

Să vedem… Ca să o luam de la înce-put, am primit o aplicație pe care trebuie să o demonstrăm fie ca e bună, fie că e ne-bună. Aici se pare că opiniile variază destul de mult în funcție de orizontul fiecăruia. Discuția, evident, e una mai complexă și adevărul e de cele mai multe ori la mijloc. De data aceasta voi merge pe varianta în care demonstrăm că aplicația noastră nu e cea mai bună.

ContextȘi cum bug-urile sunt un fel centru de

atracție în domeniul nostru, ne vom referi la ele în cele ce urmează, doar asta ne face plăcere, nu? Având aplicația, totul ar tre-bui să înceapă de la niște scenarii de bază care să urmăreasca “flow-ul”. Și dezvol-tând aceste scenarii să vedem dacă fiecare

părticică din pretinsul tot al aplicației își joacă bine rolul.

Și dacă e să o luăm de la început, am putea să ne lăudam cu niște teste scrise pe baza unor “Cerințe”, cum am zice noi “Requirement-uri”, care ar fi cazul ideal, după mine. Specie rară – Clientul care știe ce vrea - din punct de vedere funcțional, estetic și tehnic. Daca aș fi eu Clientul aș ști că vreau un produs calitativ, care să fie livrat ieri, cu costuri minimale, probabil asta știu toți Clienții, nu? Evident această abordare ne afectează nouă cursivitatea și succe-sul testării. Gândindu-mă la experiențe și discuții aș putea zice ca am întâlnit destul de des sintagma – de la Client de data asta: “Dacă nu-l poți convinge, zăpăcește-l “

Acum că am așezat totul într-un context am putea să dăm prima Contră. Folosind explorarea s-ar putea să ne scape flow-uri de bază și să deviem cu bună știința în credința că scenariile de bază merg. Nu e cea mai constructivă gândire, dar cred ca măcar o dată tot am căzut în păcat.

Contra• Să zicem că am terminat de explo-

rat aplicația și precum ne-am așteptat am găsit o sumedenie de bug-uri care

În ultima vreme am auzit/văzut în diferite contexte(grupuri, meetinguri…) subiec-tul Exploratory Testing despicat ca “firul în patru”. Targetul meu pentru acest articol e un rezumat – util, sper al ideilor primite, însușite, testate de către mine.

Am tot ascultat dialoguri și monologuri legate de exploratory fie ele pro, fie contra. Urmărind un parcurs firesc al unei aplicații o să încerc să creionez și să subliniez câteva dintre argumente.

Ioana [email protected]

QA Engineering at Gemini Solutions Cluj

QA



câteodata ne-au făcut ziua ori mai frumoasă ori mai nervoasă, după caz. Expresia “terminat explorat aplicația” e una mai relativă, e aproape la fel cum am zice că aplicația nu are buguri), se poate? Contra. Cum gestionăm și măsuram ce am testat, doar nu vrem sa repetam aceeași explorare. Evident e mai greu decăt să dăm un pass sau un fail la niște teste deja scrise. Ar fi aici de fapt și un Pro, existând modalități de măsurare: Checklist, Recording, Notes, Bug Hunt, Questioning…

• Nu prea avem parte de automation, proces destul de important al testă-rii. Și cum mai întotdeauna există o soluție, de ajutor aici este automatiza-rea bugurilor găsite în incursiunea în necunoscutul aplicației. Teste care se pot rula ori de cate ori se fixeaza un bug, sau se modifică, adaugă cod în aria respectivă.

Pro• Abordarea în sine, prin natura ei, te

invață să cunoști produsul.• Faci și înveți să faci cam de toate: să cre-

ezi teste, să le rulezi,să investighezi, să contabilizezi…

• Folosește partea mai curioasă si crea-tivă din fiecare, zic eu. E momentul mai multor întrebări “ce ar fi dacă”, “ce ar fi să”, comparativ cu testarea dupa mai mulți pași din exceluri, worduri, qc…sau orice altă metodă ar fi folosită.

• Ar trebui sa conducă la creșterea responsabilității, având în vedere că fie-care explorator trebuie să decidă traseul

prin vrea să facă o anumită testare, iar in realizarea lui sa găsească, investi-gheze, folosească orice mijloc care l-ar putea ajuta, pornind de la specificațiile (ne)existente, la produse similare tes-tate, la produse concurente.. Ce ar putea să ajute aici e conștientizarea faptului că explorarea fiecaruia e unică prin simplul fapt că fiecare tester e unic.

• Duce câteodata(la unii mai mult la alții mai puțin sau la un produs mai mult la altul mai puțin) la “mari des-coperiri” de genul “NullPointer” in Java or”TooManyOpenCursors” in Oracle, care au șanse să nu fie găsite prin testarea “à la carte”. Momentul NullPointerException e unul savurat de testeri, deoarece marchează în general sfârșitul sau rareori, de ce nu începu-tul unei investigații care devine la un moment dat mai …personală, să zicem prin manifestarea si gravitatea lor. Da, știu că e relativă găsirea unor astfel de erori, dar in general în aceasta scriere am facut referire la un cod care nu e la prima mâna, presupunînd că am fi in code complete.

Cam astea ar fi câteva dintre argumen-tele disputate momentan, fiecare dintre ele poate constitui un nou subiect de discuții pe care o lăsam pe altă dată, când vom avea mai multă hârtie, mai multă mină la creion, mai mult timp.

Dacă ar fi să trag acum o linie, aș zice Pro, dar nu ca metoda unica de testare.


SociaLook

ÎnceputulPovestea SociaLook a început în aprilie

2011, când proaspăt revenit după primul meu startup, eșuat, am început să plănu-iesc o nouă afacere. Ideea a venit într-un mod natural: când lucram la primul meu start-up, Newistic, eram în România și trebuia să găsesc clienți printre agențiile de comunicare din Anglia și SUA. Astfel, am petrecut câteva săptămâni folosind LinkedIn si Twitter pentru a căuta oameni care sunt activi pe aceste medii și contac-tându-i direct. Metoda a funcționat, și am reușit să stabilesc întâlniri în Londra cu patru persoane, iar trei dintre acestea au devenit clienți. În concluzie, LinkedIn si Twitter s-au dovedit a fi mult mai eficiente decât e-mailul.

Am observat că acest proces de a găsi date din social media poate fi automatizat și este o oportunitate destul de mare pentru un startup. Am convins un business angel din Belgia pe care îl știam de pe vremea când lucram la Newistic, să investească în această idee născându-se astfel SociaLook.

Primul produsPrimul produs al SociaLook a fost

destul de simplu: crearea unei aplicații web ce conținea cât mai multe date despre

startup-urile din SUA si Europa, în special ce runde de finanțare au primit și de la cine, și care sunt oamenii din spatele lor. Pentru fiecare persoană produsul afișa conturile de social media: Twitter, blog, LinkedIn, Facebook. Dar cea mai interesantă funcționalitate era crearea de conexiuni între oameni bazate pe investiții si pozițiile în diferite companii. Spre exemplu, dacă un utilizator căuta cea mai buna conexiune la un investitor, SociaLook îi putea oferi urmatoarea legătura: utilizatorul era conec-tat pe Twitter cu o persoana care lucrează la un startup care primise finanțare de la investitorul respectiv. Spre deosebire de LinkedIn, SociaLook oferea conexiuni de pe mai multe rețele sociale, si calcula un scor pentru fiecare conexiune – o conexi-une între doi oameni e mai puternică dacă au lucrat zece ani împreună, decât dacă s-au întâlnit la o conferință, pe când în LinkedIn toate conexiunile sunt la fel.

Am început să lucrăm la produs în mai, în Târgu Mureș. După ce am avut un prototip, a urmat un alt pas important: validarea produsului. Astfel, în iunie-iulie, am petrecut trei săptămâni în Londra unde am avut întâlniri cu antreprenori și posi-bili investitori. Feedback-ul primit a fost promițător: majoritatea celor cu care am

Mă numesc Horaț iu Mocian, ș i sunt fondatorul SociaLook, www.socialook.net, un startup care urmărește prezența companiilor și a a angajaților acestora în social media, în special Twitter si bloguri. Chiar

dacă startup-ul este încă destul de tânăr, aproximativ un an, povestea din spatele lui este destul de interesantă.

Horaţiu [email protected]

Tanar antreprenor in social media. A absolvit un Master in Advanced Computing la Imperial College London, iar in momentul de fata isi imparte timpul intre Targu Mures si Londra in rolul de CEO si fondator al SociaLook.

startup



discutat vedeau o oportunitate pentru un astfel de produs. Am decis să lucrăm în continuare la el și să pregătim o versiune beta pentru luna septembrie. În timpul verii am pregătit produsul pentru testarea beta, reușind să ajungem la o versiune sta-bilă spre sfârșitul lui septembrie.

Turneu de prezentăriÎncepând cu luna septembrie focusul

s-a mutat pe participarea la evenimente și pe creșterea vizibilității produsului. Am participat la Capital on Stage în Amsterdam (septembrie) și la Venture Connect în Cluj (octombrie). Dar punc-tul de maxim a fost în noiembrie: am prezentat SociaLook pe scenă la How To Web, cea mai mare conferință de tehno-logie din sud-estul Europei, și am luat locul 3 (cea mai bună clasare pentru o echipă românească). Apoi, am prezentat în fața investitorilor la Venture Connect în București. Această conferință reunește cele mai bune startup-uri din România cu majoritatea investitorilor români, precum și cu un număr important de investitori străini. Pentru mine feedback-ul a fost destul de bun, am început discuții de finanțare, însă acestea nu au ajuns la un rezultat final. Turneul de prezentare a SociaLook s-a încheiat cu încă o vizită în Londra pentru întâlniri cu potențiali clienți.

În tot acest timp, începeam să pri-mim și feedback de la clienții care au început să folosească produsul. Părerea majoritară a fost că produsul era des-tul de interesant, însă utilitatea lui era restrânsă. În primul rând, piața adresată (antreprenori ce caută investiție) era des-tul de mică. În plus, un antreprenor care încă nu a luat o rundă de finanțare nu și-ar putea permite să plătească pentru un ast-fel de produs, iar după ce a primit runda de finanțare nu mai are nevoie de produs (chiar și pentru rundele următoare, inves-titorii existenți vor fi mult mai utili decât cei găsiți de SociaLook). În al doilea rând, ne-am dat seama că produsul este greu de mutat pe alte verticale (vânzări, business development), pentru că nu avem surse de date destul de bune și majoritatea sunt plă-tite (LinkedIn, CapitalIQ, Bloomberg, etc).

SociaLook 2.0În ianuarie 2012, după ce am coro-

borat tot feedbackul primit în ultimele luni, am început reinventarea produsului

SociaLook. S-au luat câteva decizii impor-tante: nu se vor folosi alte surse de date în afara celor din social media, vor fi constru-ite profile automate pentru orice companie iar sursa principală de date va fi Twitter. În concluzie, focusul s-a mutat de la găsirea conexiunilor, la găsirea oamenilor care au conturi de Twitter, LinkedIn sau bloguri, din orice companie. De asemenea, noul produs va fi orientat oamenilor care fac vânzări sau business development.

Din luna martie, lucrăm la un nou design al site-ului care să reflecte noua direcție. La momentul scrierii articolului se lucrează intens la noul produs, care va putea fi testat de primii useri în aprilie. De asemenea, în aprilie, voi face demo-uri ale noului produs în Londra.

ViitorulPlanurile pentru următoarele luni sunt

destul de clare: finalizarea noului produs, prezentarea la mai multe conferințe, discu-tarea unui posibil parteneriat pentru date cu LinkedIn, și creșterea echipei. Dacă totul merge conform planului, în vară se va discuta de o nouă rundă de finanțare, și extinderea prezenței SociaLook în Londra.

În final, dacă tot am amintit de echipă, voi descrie pe scurt componența ei. Eu sunt singurul implicat full-time, însă investitorul inițial e implicat în discuțiile despre strategia companiei. Din ianuarie 2012, Răzvan Roman ni s-a alăturat ca advisor, fiind implicat în definirea pro-dusului pentru oamenii de vânzări și în aducerea de posibili clienți. Eu am făcut design-ul funcțional al produsului și am construit back-endul, însă pe partea de design vizual și front-end lucrez cu Reea, o firmă din Târgu Mureș.

În următoarele luni, voi căuta încă o persoana tehnică care să se alăture echipei ca CTO, urmând a fi responsabil de întreaga parte tehnică a produsului. Principalele provocări tehnice ale proiec-tului sunt procesarea unui volum mare de date și crearea unor componente de proce-sare a limbajului natural (NLP).

Managing Multiple Projects in a Program Environment•••••••••••••••••••••••• •• • • • • •• ••• • •• ••• • • • • • • • • • • • • • • • • • • •••

May 14-15 2012, Bucharest, Romania 16PDUs

This 2-day seminar provides key skills for Project and Program managers in today’s increasingly complex global project & program world

Seminar Focus Learn how multiple projects can be effectively controlled, especially where change is ‘business as usual’ Review the ‘show-stoppers’ which repeatedly impact upon the delivery of complex & multiple projects Analyze the strategic alignment of projects and issues around delivering trans-national projects Discover how Program Managers ensure a portfolio or program is managed at the correct level Explore what a ‘best practice’ organizational structure for the management of multiple projects looks like Develop a personal action plan to apply your learning back at work Familiarize yourself with Program Management Professional (PgMP) credential requirements & exam criteria

Agile

The

PMP

May 14-15 2012 Zagreb, Croatia 16PDUs

May 17-18 2012 Bucharest, Romania

16PDUs

By blending the very best of Lean-Agile methodology with traditional project-management approach, this course shows you how to achieve the ultimate success on your projects and programs by driving the productivity and ROI.

Seminar Focus What is Agile, who uses it, and what challenges does it resolve Agile Project Management with Scrum How do the Waterfall and Scrum life cycles compare Agile, Lean, Flexible, Waterfall, Scrum, DSDM and more Explore Lean-Agile to successfully deliver your projects Pragmatic hybrid approaches: Implementations from the real world Why you stand out as an Agile PMP® What competitive advantage does your organization gain Learn pragmatic Lean-Agile


Interviu Dan Luţaş Portretul unui specialist în securitatea

informaţiei

Am să încep prin a vă prezenta o dilemă legată de alegerea inter-vievatului din acest număr al

revistei: Dan Luţaș. Mi-a fost coleg de liceu și facultate și îmi place să îl consider prie-ten, lucru care a generat iniţial un conflict intern între obiectivitatea în alegerea și prezentarea articolului, și subiectivismul adus de amestecul vieţii personale cu cea profesională. Există destui profesioniști în mediul local ale căror realizări îi reco-mandă pentru interviu, fără a genera acest conflict, așa că am să prezint pe scurt de ce am rămas la această alegere. Totul a pornit de la un amic comun care mi-a ară-tat articolul “30 sub 30, generaţia restart”, publicat de Forbes România, în care Dan este alăturat altor 29 de tineri cu potenţi-alul de a schimba viitorul în bine. Trecând peste senzaţional, trecând și peste reacţia lui modestă (el consideră că a ajuns acolo din greșeală), am analizat la rece profilul lui profesional și m-am convins de ceea ce știam demult: Dan face parte din acei oameni care se identifică total cu ceea ce fac. Aparţine acelei categorii care dedică 10,000 ore de efort unei preocupări, care nu este doar hobby, carieră sau pasiune, ci este manifestarea unui echilibru intre acti-vitatea zilnică și ceea ce sunt ei ca persoane. Munca de la birou, cercetarea pentru doc-torat și orele predate la universitate, toate sunt dedicate securităţii, la fel cum în liceu programarea, și în facultate ingineria, au făcut tot timpul parte natural din cine este el. Eu cred că acest gen de dedicaţie este

unul din ingredientele principale ale unui profesionist din orice domeniu. Să vedem așadar cum a ajuns, ce îl definește și care sunt preocupările unui inginer IT specialist în securitate.

Având în vedere că interviul a durat peste o oră jumătate, și prima tentativă de al transpune integral în text creștea alar-mant ca și dimensiune, am decis să folosesc un stil concis și cu permisiunea dumnea-voastră am să sintetizez principalele idei discutate.

Totul a început la Satu-Mare acum 29 de ani, când Dan s-a născut și după doar 3 zile s-a mutat la Cluj. Primul contact cu cal-culatorul îl va avea imediat după revoluţie, când în repetate rânduri curiozitatea îl va ajuta să strice calculatorul bunicului, fiind nevoie de reparaţii tot la două săptămâni. Tot atunci a făcut cunoștinţă și cu primul său virus: OneHalf, care s-a strecurat în sistem pe o dischetă cu un joc, și i-a oferit provocări și recompense mai mari decât jocul în sine: „am vrut să văd despre ce este vorba, am săpat și mi-a plăcut foarte mult și de atunci mi-a rămas întipărit în minte: asta trebuie să faci, ăsta este viitorul. Domeniul calculatoarelor a venit natural, profesia de inginer la fel de natural, deci a fost trasat totul de la început.” Prin urmare Liceul de Informatica „Tiberiu Popoviciu” și secţia de Calculatoare a Facultăţii de Automatică și Calculatoare din UTCN, cu diploma de inginer, cea de Master și actualul statut de

Marius [email protected]

Fost senior software developerin cadrul Nokia, în prezentfondatorul platformei MintakaResearch

interviu



doctorand, au alcătuit traseul normal al evenimentelor.

Și-a început cariera în timpul facultăţii și primii 3 ani a programat în C și Java, fără preocupări legate de securitate. Intrarea în acest domeniu a venit, când Dan a: „văzut că Bitdefender recruta și am revenit la vechea mea pasiune din copilărie. Am zis: hai să încercăm să vedem ce iese [..] și astfel s-a deschis Bitdefender Cluj, împre-ună cu mine și încă 4 colegi în 2005.” În cei 7 ani care ne aduc până în ziua de azi, poziţiile ocupate au variat de la: analist de viruși (2 ani și jumătate), timp în care a făcut: „mult mult mult reverse engineering (eng. Inginerie inversă), studiat codul x86, studiat formate de fișiere, analizat foarte multi viruși, făcut ture (lucrul la analiză este non-stop, în foc continuu), lucram weekendurile, lucram nopţile, dar era o muncă foarte plină de recompense, simţeai că înveţi tot timpul lucruri noi și puteai să evoluezi.”; apoi a trecut pe partea de dez-voltare de tehnologii de detecţie, din modul utilizator a trecut în modul kernel, un pas necesar pentru a ţine pasul cu ameninţările din domeniu. Tot la asta lucrează și astăzi, doar că în rolul de conducător al echipei de cercetare metode de protecţie kernel și proactive, la un nivel tehnologic mai înalt, avansând la tehnici de hipervizoare și introspecţie.

Odată cu dezvoltarea carierei s-au dezvoltat și provocările și a crescut com-plexitatea ameninţărilor informatice. Dacă: „la început scopul principal era să creezi un virus prin care să arăţi cât de priceput ești, să afișezi un mesaj pe ecran sau să distrugi datele, această tipologie a dispărut. În ziua de azi accentul se pune pe furtul de infor-maţii și pe valorificarea acestor informaţii. Trebuie să înţelegem că ies foarte mulţi bani din a crea malware care să spioneze și care să fure identităţi. Din acest motiv nu mai avem de a face cu creatori de viruși care sunt oameni singuratici și fixaţi pe o idee, ci este vorba de o întreagă industrie de malware, în care se folosesc metodologii de dezvoltare de malware, acesta are un ciclu de viaţă, este actualizat, controlat, se aduc îmbunătăţiri. Avem de a face cu o chestie profesionista, și ca să răspunzi la asemenea ameninţări trebuie să ai o abordare profe-sionistă.” Abordarea curentă în industrie este una proactivă: „E mult mai ușor să previi decât să tratezi.” Practic modelul a

evoluat de la folosirea antivirusului pentru a devirusa un calculator gata infectat, la a împiedica infectarea acestuia prin oprirea atacurilor înainte de a avea loc.

Trecând de la istorie în prezent am hotărât să ne oprim un pic asupra firmei Bitdefender, în opinia mea una dintre cele mai de succes firme IT românești, printre singurele care au în portofoliu un produs ce se bate constant pentru primul loc, la nivel mondial, în categoria lui, și generează can-tităţi însemnate de Proprietate Intelectuala. Eu văd în asta un semn pozitiv, o dovadă a competenţei și competitivităţii mediului IT din România, dar în același timp și o pată de culoare în marea de outsourcing. Prin urmare am vrut să aflu o părere din inte-rior: „Pe avtest.org Bitdefender este chiar pe primul loc, dacă te uiţi în ultimul an, am ieșit în fiecare semestru primii la detecţie și la partea de curăţare. Suntem în topul topurilor, suntem cei mai buni și ne mân-drim cu asta.” a spus Dan zâmbind. „Vreau să mai spun că este un produs 100% româ-nesc, toată tehnologia se face în România, nu se face nimic în afară, nu avem outsour-cing, totul este făcut de specialiștii români.” Aceste echipe locale sunt și primul ingredi-ent în reţeta succesului: „cred că oamenii sunt cei mai importanţi pană la urmă și există oameni în Bitdefender care lucrează de 12-13 ani încontinuu, și lucrează cu aceeași pasiune și cu aceeași dorinţă de a fi cei mai buni. De asemenea este vorba și de viteza de reacţie și abilitatea cu care poţi să anticipezi ceea ce urmează să se întâmple. Șeful meu chiar avea o zicală: <<the fas-ter you are, the less you get fired>> adică cu cât ești mai rapid, cu atât șansele să te concediem scad. Viteza este o componentă foarte importantă în acest domeniu, dacă nu reușești să previi, trebuie să ai detecţie la nivel de ore, de minute dacă se poate. O altă componentă a succesului este inovaţia [..] Bitdefender a fost primul produs antivi-rus cu update online de semnături.” acesta fiind doar un exemplu de inovaţie adusă de Bitdefender în domeniul securităţii și pre-luată de industrie, devenind un standard în oferta de servicii.

Lăsând realizările companiei să vor-bească de la sine, pe viitor, am decis să discutam un pic despre primul ingredient: echipele de dezvoltatori. Cum? și de unde? se găsesc resurse în securitatea IT, un domeniu de nișă. „Să găsesc un specialist

gata format și gata pregătit îmi este aproape imposibil, aici în Cluj și pot să zic chiar în România. [..] trebuie făcut un training, și acesta în Bitdefender durează mult, 4 luni de zile, poate chiar mai mult. De aceea ideea este să găsim persoane cu potenţial, interesate de domeniu [..] și care sa ajungă la nivelul cerut de noi. Prin implicarea în viaţa universitară, încercăm să atragem oamenii direct de la sursă.” Însă implica-rea lui Dan în viaţa universitară nu are ca principală preocupare recrutarea, el fiind mai degrabă interesat de procesul educati-onal, predând laboratoare sub convingerea că: „În momentul în care acumulezi niște cunoștinţe, dacă le ţi numai pentru tine nu rezolvi nimic, ideea este să le împărtășești și să ii ajuţi și pe alţii să dobândească acele cunoștinţe și să crești nivelul de conștienti-zare al celor din jur.”, mai ales asupra unui aspect important ca: „Securitatea este la fel de puternică, ca și cea mai slabă veriga a sa, și cea mai slabă verigă a sa sunt oamenii. [..] iar prin implicarea mea în învăţământ, asta încerc să fac [..] să popularizez acest domeniu și să le atrag atenţia de la înce-put la ce riscuri se expun.” Important este și sentimentul de satisfacţie simţit când: „studenţii chiar au fost interesaţi și au sim-ţit ca pot să înveţe lucruri noi. Cam asta este raţiunea mea, de asta vreau eu să ţin acele laboratoare, să diseminez și să cresc gradul de conștientizare asupra securită-ţii.” Prin urmare securitatea tine la fel de mult de tehnologie, cât tine și de educarea factorului uman: formal, prin politici în interiorul companiilor, începând din faza de dezvoltare, până în producţie; dar și educational: „securitatea ar trebui să stră-bată ca un fir rosu, din anul întâi până în anul 6 la master”.

Pentru a explora până la capăt sfera academică, am decis să comparăm un pic activitatea de cercetare de la doctorat și din industrie. Practic, deși Dan încearcă să le păstreze aliniate există unele diferenţe fundamentale: în cea academică „prezinţi o idee, fără să iei în considerare aspectele de performanţă, stabilitate, scalabilitate, implementare în viaţa reală. Pe când în industrie e cu totul altfel, fix pe dos.” pri-mează specificaţiile non-funcţionale, practice, înaintea ideilor teoretice revo-luţionare. „Dacă ești protejat de cupola academică” poţi să faci „cercetare de dragul cercetării, sperând să ajungi la un panaceu, care să rezolve totul”, dar în industrie, Dan


crede că este important să rămâi pragma-tic și să te păstrezi în sfera aplicabilităţii rapide, fără a lăsa efortul de implementare pe generaţiile următoare și a avansa doar teoretic.

Revenind la mediul economic am decis să trecem scurt în revistă schimbă-rile curente din IT, cum ar fi trecerea de paradigmă de la vechile structuri fixe la combinaţia dintre mobil și cloud, atât din perspectiva consumatorului individual, cât și din cea industrială. Schimbare ce des-chide o întreagă paletă de vulnerabilităţi noi: pierderea confidenţialităţii, nevoia de contracte SLA (Service Level Agreement) pentru a asigura accesul și integritatea datelor etc. Securitatea trebuie să tina pasul și echipa Bitdefender, deja a lansat pe piaţă o soluţie pentru infrastructura în medii virtualizate VMware, Hyper-V, Xen. Deși există schimbări rapide în toate domeniile ITC, este remarcabila viteza de schimbare și de reacţie din domeniul securităţii. Practic trebuie tot timpul sa fii pregătit, nu doar pentru atacuri din părţile rău intenţionate, dar și pentru schimbări în tehnologiile și produsele soft cu distribuţie masivă pe piaţă.

Înainte de a explora paleta larga de opţiuni, din care putem să ne alegem, când ne construim o carieră în securitate, am decis să atingem un pic partea senzaţio-nală a acestui gen de muncă. Există multe știri din categoria 007: Stuxnet, războaie cibernetice, etc.; care fac din ramura asta una dintre puţinele din IT, care iţi oferă adrenalină la locul de muncă. Așa că mi-am întrebat interlocutorul: cât de mult din rutina zilnică ţine de senzaţional și de lupta pe viata și pe moarte? Zâmbind, Dan a făcut o paralelă între filmele cu James Bond și agenţii secreţi din viaţa reală, unde mult sub 10% din activitate are adrenalina și acţiunea din filme. Există firme de securitate care oferă soluţii foarte avansate și specializate, dar sunt la un alt nivel și este nevoie de certificări și inves-tiţii majore pentru a ajunge acolo. Chiar și asa unele ameninţări foarte sofisticate, ca și Stuxnet (care a reușit să afecteze progra-mul nuclear iranian) pot fi prinse de către un antivirus de uz casnic. Diferenţa apare în aplicarea soluţiilor corective, deoarece, spre deosebire de filme, în realitate există procese bine puse la punct, cu proceduri stricte care trebuiesc respectate. Nimeni

nu aplică strategia „lupul singuratic care merge pe urmele hackerului și îl arestează”. Există satisfacţie personală când reușești să găsești o soluţie pentru a opri un atac, însă: „nu ii legal să faci ceva tu singur, [..] dar poţi să mergi în sfera juridică, să lucrezi cu autorităţile competente și în urma unui mandat, să oprești reţeaua respectivă”. Cu alte cuvinte, chiar și sistemele controlate de hackeri sunt protejate de lege și se urmăresc canalele juridice oficiale pentru oprirea lor.

Dacă tot am pornit pe drumul senza-ţionalului, i-am dat satisfacţia lui Dan de a demitiza un alt subiect comun în presa locală: atacurile hackerilor romani asupra FBI, Pentagon și alte astfel de fortăreţe și celebrul cuib de hackeri de la Râmnicu Vâlcea (supranumit și Hacker Ville). Răspunsul lui Dan împarte hackerii în trei categorii distincte: amatorii ce folosesc instrumente automate, escrocii și hackerii reali.

Practic prima categorie este alcătuită, de cele mai multe ori, din tineri care uti-lizează instrumente automate, foarte ușor de folosit: „orice om care știe să folosească yahoo messenger, dă trei click-uri și gata”, care identifică automat vulnerabilităţi și iţi permit să le exploatezi (tot prin interme-diul interfeţei grafice). Acești „hackeri” au, de cele mai multe ori, un nivel foarte scă-zut de cunoștinţe tehnice și nu reușesc să exploateze mai departe accesul la date de mare importanţă, fiind prinși cu ușurinţă și ajungând pe prima pagină din ziare. Dan consideră că ar trebui trataţi cu indulgenţă și introduși într-un proces de reeducare.

A doua categorie, cei din Hacker Ville, se ocupa de fapt cu: „înșelătorie la drumul mare [..] anunţuri false pe ebay [..] puneau preţuri de dumping și se bazau pe veriga cea mai slaba din lanţul de securitate, pe om, care nu mirosea escrocheria. Nu aș merge întra-colo încât să numesc astfel de activităţi, activităţi de hacking. [..] Nu este nici o diferenţă între hackerul vâlcean și unul care te înșeală la un schimb valutar, practic exploatează inocenţa umană.”

Ultima categorie o reprezinta hackerii reali, însa aici apar unele nuanţe de gri: „în accepţiunea veche: hackerul este o persoană foarte curioasă, care este foarte pasionată de un domeniu și încearcă să înţeleagă cât mai multe din acel domeniu.”

În acest sens, zice Dan: „îmi place să ma consider hacker.” Cum facem atunci să separăm hackerii în Black Hats și White Hats, adică în băieţi răi și buni. „Diferenţa [..] este dată de autorizaţia și etica, ca să fii white, trebuie să ai autorizaţia din partea companiei pe care o ataci sau ii descoperi vulnerabilităţi; și să ai etică, adică să nu dezvălui datele respective, să le faci publice sau să le folosești pentru avantajul tău per-sonal. În rest, la nivel de cunoștinţe tehnice, la nivel de tehnologii sau abilităţi personale, nu ar trebui să fie nici o diferenţă.” Cu alte cuvinte moralitatea ii separă pe pen-testeri (cei plătiţi să găsească vulnerabilităţi), de hackeri. Primii primesc bani, ceilalţi ajung la închisoare, dar ambii merita respect din perspectiva abilităţilor tehnice.

Ca să complicam și mai tare lucrurile și să fie și mai greu de definit graniţa dintre nivelurile de gri, am povestit un pic despre pen-testing și am aflat că, dacă în cazul atacurilor asupra companiilor, lucrurile sunt destul de clare, nu la fel stau lucrurile în cazul unor produse comerciale publice. De exemplu este o practică curentă să se ia o aplicaţie foarte folosită, să se ruleze pe ea instrumente și teste de descoperire a vulnerabilităţilor, iar odată găsite, există două posibilităţi. Ori anunţi compania producătoare și le dai ocazia să repare vul-nerabilitatea, caz în care iţi construiești o reputaţie bună și faci un serviciu public; ori poţi organiza legal o licitaţie pentru a vinde vulnerabilitatea pentru profit finan-ciar personal. Există o dezbatere aprinsă în comunitate, atât din perspectiva etică, cât și legală a celei de a doua abordări.

Părăsim senzaţionalul de gazetă și gra-niţele fine ale nuanţelor de gri din etică, și ne întoarcem un pic la statistici și realitatea industriei securităţii. Chiar dacă am hotă-rât că un angajat în securitatea IT nu este un agent 007, cifrele oficiale ale Norton Cybercrime report 2011 arată că: în fie-care secundă 14 persoane cad victimă unei infracţiuni cibernetice, iar totalul prejudi-ciilor cauzate de încălcări ale securităţii IT în 2011 se ridică la 388 miliarde de dolari, în condiţiile în care valoarea totală a pie-ţei drogurilor este estimată la 288. Chiar dacă Dan se ferește de cuvântul mafie, eu consider că magnitudinea cifrelor de mai sus descriu clar o formă de crimă organi-zată, care a pus bazele unei industrii de exploatare a vulnerabilităţilor de securitate.

Interviu Dan Luţaş – Portretul unui specialist în securitatea informaţieiinterviu



Amândoi cădem de acord că avem în faţă o cursă a înarmărilor, iar dacă acum 10 ani raportul de forţe era clar în favoarea securităţii, în momentul de fată lupta este deschisă și de partea cealaltă a baricadei, stă un adversar la fel de bine pregătit tehno-logic și financiar. Cu toate acestea Dan mă asigură că, deși suntem: „atacaţi non-stop, îmi place să cred ca putem face faţă. Dacă nu ne bazăm doar pe tehnologie, ci suntem atenţi pe ce site-uri intrăm și ce operaţii facem și la ce ne expunem, în același timp avem o soluţie anti-malware, că deja nu mai vorbim de antivirus, ci de o întreagă paletă de creaturi virtuale.. cred că suntem ok.” Aleg să am încredere și să îl cred, dar întreb ce strategie au pentru a ţine pasul pe viitor. Mai exact prin ce mijloace reușesc să se ţină la curent cu tehnologia: certificări, traininguri sau studiu personal.

„Cel mai mare accent se pune pe stu-diu personal [..] trebuie să depui tu efort, să fii tu la curent cu toate atacurile nou apărute, ideal ar fi să fii conectat la listele de vulnerabilităţi, să știi ce se întâmplă în industrie”; cât despre traininguri: „Nu vreau să par lipsit de modestie, dar trainin-gurile le cam ţinem noi!”, a declarat Dan râzând. Rolul certificărilor, în viziunea lui Dan, este de a oferi perspective noi asupra industriei. Desigur, există ramuri și poziţii care necesită formal anumite certificări, dar în cazul lui, contribuţia principală a fost explorarea unor concepte cu care nu se întâlnește în viaţa de zi cu zi, în rolul

său de developer din tranșee. Dan deţine certificările: CISSP (Certified Information Security Professional, eng. Profesionist Certificat în Securitatea Informaţiei), CEHv7 (Certified Ethical Hacker, eng. Hacker Etic Certificat) și CISA (Certified Information Security Auditor, eng, Auditor Certificat în Securitatea Informaţiei). Unele au fost o provocare (CISSP a avut 250 de întrebări în 6 ore), timpul de pregătire pentru fiecare ajungând la 2-3 luni, dar au meritat, de exemplu CEH i-a prilejuit contactul cu: „Un întreg arsenal de tool-uri (eng. instrumente), te crucești când vezi ce au la dispoziţie cei care vor să atace și cât de simplu e”.

După cum se vede în toate paragrafele de mai sus, este nevoie de o investiţie con-siderabilă de timp și efort, pentru a reuși să ţii pasul într-un mediu adversarial atât de dinamic cum este domeniul securităţii IT. Așa că, în încheiere, am discutat des-pre aspectele sociale: cât timp alocă zilnic un inginer de securitate pentru a fi la zi, iar Dan aproximează la 10-12 ore pentru a păstra ritmul, și 13-14 dacă dorești să ajungi în elită. În condiţiile în care seara este dedicată familiei, mai ales celor doi copii ai săi, este de înţeles de ce unii din pri-eteni îl consideră agent 007. În final cred că am subestimat investiţia la doar 10.000 de ore și sunt sigur că Dan se va dedica secu-rităţii tot restul vieţii, deoarece: „Eu cred că fac ceea ce îmi place cu adevărat.”


Pregătirea unui interviu

Cum să mă pregătesc pentru un inter-viu? Răspunsul în mintea mea este extrem de familiar. Dar, când încerc să-l pun pe hârtie, devine din ce în ce mai complicat. Așa este și cu participarea la interviuri. Te gândești că e o discuție degajată pe care o vei purta cu una sau mai multe persoane. Pus în fața faptului împlinit realizezi că ai emoții, pe care uneori nu știi cum să le con-trolezi și din teama de a nu avea momente stânjenitoare de liniște, răspunzi cât de repede poți la întrebarea care îți este adre-sată. De cele mai multe ori se întâmplă să nu fii mulțumit de informația pe care ai transmis-o. La fel ca și mine, te sfătuiesc să îți iei zece secunde, să tragi aer adând în piept, să îți formulezi în minte niște idei, pe care ulterior să le exprimi.

Unii spun că principalul și cel mai important lucru pe care îl ai de făcut îna-inte unui interviu este să te pregătești. De exemplu, să cauți informații despre top 99 cele mai des întrebări formulate de anga-jator. Eu cred că poate fi un exercițiu util, de auto-cunoaștere și de câștigare a încre-derii în tine. Te sfătuiesc, însă să nu duci la extrem acest exercițiu și să nu înveți

niște întrebări pe de rost. Îți spun că există posibilitatea să îi păcălești pe recruiterii începători, dar ce te faci când întâlnești o “vulpe bătrână”, care îți citește foarte bine intențiile și începe să te scoată din rutina răspunsurilor prestabilite? Suntem amân-doi conștienți că unul dintre riscuri este să te pierzi și să nu obții, poate, “job-ul viselor tale”.

Eu consider că lucrul cel mai important pe care ar trebui să îl faci pe parcursul unui interviu este să ai un scop bine stabilit: “ să descoperi dacă acel job este potrivit pen-tru tine”. Să fii cât se poate de sincer cu tine și cu intervievatorul tău, având mereu în minte trei idei : (1)“Pot să îndeplinesc sar-cinile pe acest post în mod performant?”, (2) “Îmi va plăcea compania și mediul de lucru?” și (3) “Care este motivația mea de a lucra în această firmă?”. Nefiind cinstit cu tine îți asumi, din nou, un risc. Te înhami într-o companie nouă în care vei ajunge să nu fii un performer și să nu te integrezi. În felul acesta vei fi într-o continuă căutare a unui loc de muncă.

Un alt mit despre cum să te prezinți la un interviu este ”ținuta”. În articolele

Când am acceptat invitația de a scrie despre ”Cum să te pregătești pentru un interviu” am crezut că va fi simplu. Mi-am propus ca articolul să fie ușor de citit și de înțeles și, nu în ultimul rând, o oportunitate de a deprinde ceva util.

Când am început să-l editez însă, am realizat că limba română nu e tocmai ușoară și cu atât mai mult e destul de dificil să exprimi idei complexe într-o manieră simplă. După ce am pus punctul de final, l-am dat unui copil de zece ani să-l citească, cu scopul de a-i testa simplitatea și coerența. Mi-a spus că nu a înțeles nimic. Așa că am luat-o de la capăt.

Andreea Pâ[email protected]

Recruiter în cadrul Endava şi trainer specializat în dezvoltarea abilităților si competenețelor de leadership, comunicare şi muncă în echipă

HR



de specialitate (nu că acesta nu ar fi unul) spune că trebuie să te îmbraci elegant, pen-tru a face o impresie cât mai bună. Mai este menționat și că machiajul (în cazul femeilor) și parfumul (în ambele cazuri) în exces poate atrage atenția interlocutorului într-un sens negativ. Dacă este să fim onești unii cu alții, consider că în orice împreju-rări machiajul excesiv poate atrage atenția într-un sens negativ. Am apreciat întot-deauna persoanele cât mai naturale. Dacă tu ca individ nu folosești machiaj, atunci de ce să îl aplici în situațiile în care participi la un interviu ? Nu sunt de acord cu exa-gerările și conștientizez că și alți recruteri gândesc la fel. Revenind la îmbrăcăminte, eu sunt de părere că dacă aplici pentru pos-tul de ”Director Vânzări și Marketing” și te prezinți la interviu, atunci este important și chiar relevant să porți costum. Dar, dacă discutăm de un mediu mai relaxant (cum este în majoritatea companiilor de IT), atunci poți adopta stilul ”smart casual”. Știu că este un concept des folosit, dar poate că, uneori, este greu de înțeles. ”Smart casual”: un fel de combinație între elegant și uzual. O combinație reușită poate fi o pereche de blugi și o cămașă (în cazul bărbaților) și o fustă semi-elegantă sau o pereche de pan-taloni semi eleganți și o cămașă (în cazul femeilor). Consider că este suficient să ai o îmbrăcăminte curată și decentă, deoa-rece esențial este ce ai de spus în cele 45-60 minute pe care le vei petrece impreună cu recruiterul.

Te sfătuiesc în schimb să ai ”cei șapte ani de acasă” pe tot parcursul interviului. Să fii respectuos, înainte de orice. Să dai mâna ferm cu recruiterul, chiar dacă e femeie (să nu o strângi însă foarte tare). Închide-ți telefonul mobil și uită de ceas. De cele mai multe ori este bine să clarifici încă de la început cu recruiterul cât va dura discuția. Uitându-te la ceas, arăți nerăbdare și dorința de a se termina cât mai repede. Adică, în cuvinte cât mai simple, transmiți intervievatorului o lipsă de interes pentru job și o motivație scăzută. Totodată, ce mai face parte din codul bunelor maniere este evitarea gesturile exagerate. Este extrem de important să-ți corelezi limbajul verbal cu cel non-verbal. Studiază puțin îna-inte ce înseamnă să ai o poziție deschisă și una închisă. Poate fi un plus să cunoști importanța pe care gesturile, mimica și postura corpului o pot avea în cadrul comunicării interpersonale. Limbajul non-verbal este un element semnificativ

în crearea unei imagini în ochii celorlalți. Recruiterii experimentați interpretează gesturile, ajungând să cunoască persoana cu care discută chiar înainte ca aceasta să înceapă să vorbească. Așadar, adoptă o postură relaxată, dar fermă și fii sigur pe răspunsurile oferite. Iar la final, salută și mulțumește.

Până să ajungi totuși la un interviu mai ai câțiva pași pe care trebuie să îi par-curgi. Primul este să ai un CV care să pună în evidență experiența și competențele pe care le ai pentru a face față acelui job. Iar cel de-al doilea este să îți faci un brand per-sonal. Acesta din urmă îți va fi mai de folos pe parcursul primului contact pe care îl vei avea cu intervievatorul.

Cum ar zice Caragiale “Ce este acela un CV?” . Curriculum Vitae – pe scurt sau “Cursul Vieții”. Ce ai făcut tu până acum și ce îți dorești pe viitor.. Este Cartea ta de Vizită în fața angajatorului. Și, ca orice carte de vizită, CV-ul trebuie personalizat astfel încât să atragă atenția celui care o să aibă un prim contact cu el. Ca recruiter am observat că un CV atractiv îndeplinește două mari criterii (1) captează atenția încă de la început (spre exemplu, am văzut, pen-tru un post de marketing, un CV extrem de inovativ, sub forma unui afiș publicitar; este cât se poate de evidentă creativitatea apli-cantului, fiind atu-ul căutat pentru o astfel de poziție); (2) să fie clar și să urmărească un fir roșu. Bineînțeles, urmează întrebarea firească: ce înseamnă acel fir roșu? Mai jos sunt cei șase pași pe care este indicat să îi urmărești:• Informații personale• Obiectivul în carieră• Reușite profesionale • Experiența profesională • Educația formală și informală• Competențe. Abilități. Cunoștințe.

Să le analizăm pe rând, pentru a avea, atât eu, cât și tu, cititorule, aceeași viziune asupra lucrurilor.

Informațiile personale interesează orice recruiter sunt: numele (evident este necesar să se cunoască identitatea persoanei cu care se discută), localitatea de proveniență și datele tale de contact. Restul: adresa exactă, sexul, vârsta, numărul la pantofi etc. sunt mai puțin relevante. Și te întreb acum: de ce să ocupe atâta amar de spațiu?

Obiectivul în carieră. Mi s-a întâmplat zilele trecute să mă amuz copios la citirea unui CV, văzând că respectivul și-a fixat ca obiectiv in carieră “Chelner barman

.... agent paza...si altele”, cu dorința acerb exprimată în CV de a “ajunge departe.” Departe? unde? a fost prima mea reacție în condițiile în care persoana aplica pe un post de java developer. Eu „încă” nu am găsit asemănarea între barman/agent de pază/chelner și developer. Poate au și ei un “cod secret”, pe care îl dezvoltă în vreun fel sau altul. Am dat acest exemplu, care într-adevăr e dus la extrem, pentru a sublinia importanța liniarității între obiectivul în carieră și poziția pe care ai aplicat. Îți mai dau un sfat, formulează-ți obiectivul cât se poate de SMART (Specific, Measurable, Achievable, Realistic, Timelined). Celor care nu au auzit de acest concept, vă dau un exemplu simplu “Să devin Project Manager în următorii cinci ani , într-o companie de IT cu peste 100 de angajați”.

Reușite profesionale. Sunt informații care ar fi indicat să apară în orice CV. Indiferent de postul pe care aplici, rezul-tatele și performanțele tale contează. Cu atât mai distinctiv este în IT. Dacă oferi detalii despre proiectele în care ai fost implicat și tehnologiile cu care ai lucrat, recruiter-ul va putea mai ușor să schițeze profilul tău tehnic. Mai mult decât atât, se poate compara amploarea proiectelor și a rezultatelor pe care le-ai avut tu cu cele ale altor candidați. Utilizează această secțiune în CV, pentru că marea majoritate nu o fac și atunci apare încă un element distinctiv care atrage atenția.

Experiența profesională. Această secțiune începe cu cel mai recent job și continuă cu cele relevante pentru poziția pe care aplici. Vrei un post de Java Senior, nu văd de ce mi-ai trece în CV, practică în timpul facultății la “Cantina studențească”. Între cele două poziții nu există nicio conexiune. Încarci CV-ul fără vreun rezul-tat favorabil ție. Cu cât este mai detaliată experiența profesională, cu atât este mai semnificativă și orice recruiter ajunge să analizeze CV-ul pentru următorul pas în procesul de selecție și anume interviul.

Educația formală și informală. Am văzut CV-uri care aveau în această parte a CV-ului inclusiv școala generală și mate-riile studiate acolo. Te încurajez să îți treci studiile superioare și dacă îți dorești în mod deosebit, trece și liceul absolvit. Pe lângă studii, “laudă-te cu toate certifi-cările obținute”, fie că sunt tehnice (SCJP, MCSD), sau traininguri soft (leadership si comunicare) la care ai participat. Asta demonstrează că ești orientat spre propria


învățare și ai dobândit niște abilități. Competențe. Abilități. Cunoștințe.

Aici poți expune pe rând competențele dobândite fie pe parcursul trainingurilor, fie pur și simplu “on the job”. În domeniul IT este simplu, enumeri tehnologiile și framework-urile cu care ai lucrat. Ceea ce este util și ceea ce te poate diferenția față de alți aplicanți este să precizezi perioada de când lucrezi cu ele. Amintește-ți că în această secțiune un rol important îl au și cunoștințele de limbă străină. Recomand să le menționezi doar pe cele al căror nivel este cel puțin intermediar.

Majoritatea articolelor cu acest subiect sunt ceva de genul ”76 de lucuri pe care să nu le faci la un interviu”. Nu am vrut să îți spun ce să faci și ce nu, dar am considerat de bun simț ca fiecare intervievat să aibă cât de cât o idee depre ce înseamnă ”pre-gătirea pentru un interviu”. În final, vă

recomand să fiți voi înșivă/însevă pe tot parcursul discuției. Să nu prezentați lucruri neadevărate, pentru că, la urma urmei, angajatorul va descoperi personalitatea fie-căruia și poate va constata că nu este ceea ce se potrivește culturii organizaționale a companiei. Da, poate suna clișeistic, dar un lucru incontestabil este că fiecare indi-vid influențează această cultură într-un fel sau altul.

În final, când acceptați un nou loc de muncă, să simțiti acea conexiune cu com-pania și mai ales cu superiorul direct. E important să fiți pe aceeași lungime de undă. De asta cel mai bine este să nu eziți în a adresa întrebări, pentru a-ți clarifica toate aspectele dorite. Grijă mare la gradul de ”familiaritate”, pentru că la urma urmei interviul este o discuție formală. Acesta poate avea loc într-un cadru informal sau poate aveți ocazia să întâlniți recruiter-i mai

relaxați, care nu vin cu o fișă de interviu, dar care, cu siguranță, au niște competențe/ comportamente pe care le evaluează.

Mult succes!

Un recruiter 3.0.

Pregătirea unui interviuHR

ITa lent -‐maximize potent ia l Cine suntem?

ITalent este o companie care investește în potențialul studenților de la universitățile tehnice,

atât secțiile din cadrul Universității Babeș Bolyai cât și din cadrul Universității Tehnice. Suntem

pionieri pe aceastănișă, deoarece credem cu tărie că investiția în dezvoltarea unor competențe va

avea un impact pozitiv în mediul de business clujean.

Programe de excelență

ITalent Academyeste un program de excelențăcare oferă traininguristudenților cu scopul de

adobândi abilități de orientare către persoane (ITalent People Focus), orientare către sarcini (ITalent

Task Focus), precum și acumulare de cunoștințe tehnice prin intermediul unor internshipuri (ITalent

Technical)în cadrul marilor companii IT din Cluj.

Program evenimente

Partener: Contact:

[email protected]

• Leadership • Team management • CommunicaMon • Change management and Accountability

ITalent People Focus

• Team work • Project management • Time management • Change management and Accountability

ITalent Task Focus

• Internship program

ITalent Technical

Inscriere pentru ITalent Academy

Aprilie

• Selecție parMcipanți academie • Sesiuni de training

Mai

• Sesiuni de training • ITalent Academy closing

Iunie

Programe internship în companii de IT din Cluj

Iulie-‐ Septembrie


Faceți cunoştință cu Gogu!

Lui Gogu i se strânse stomacul instan-taneu. Revăzu valorile și mai citi o dată emailul în speranța deșartă că ceva, undeva, se schimba, că poate n-a înțeles corect mesajul. În paralel însă mintea lui prelucra informația primită și construia primele scenarii de răspuns. Mai bine spus încerca să construiască scenarii căci niciu-nul dintre cele ce-i treceau prin minte nu era aplicabil. În special cel în care duhul din lampa dădea timpul înapoi sau cel în care devenea invizibil pentru Șefu’.

- Oh, Doamne... oftatul ii scăpa fără voie.

- Probleme, Gogule?Tresări, uitase de prezența lui Mișu.

Mormăi în barba: - Nimic, obișnuitele probleme... Simțea

însă dureros de acut cât de neobișnuită era problema pe care o avea acum.

Recapitula șirul acțiunilor în ideea de a identifica punctul de start al dezastrului. Filmul evenimentelor începu să se deruleze în mintea lui: sosirea invitației de partici-pare la licitație, construirea argumentării participării cu beneficiile aferente. Ce feri-cit o să fie Miţă sa-mi dea acum peste nas!

iar apoi prezentarea în cadru larg. Retrăi mândria simțită atunci când Șefu’ i-a trasat lui această sarcină („sunt sigur Gogule că te vei descurca în pregatirea ofertei finale, evident ai tot suportul nostru”). Ha-ha, na mândrie acum – se apostrofa singur. Apoi neliniștea resimțită când s-a văzut în fața formularului pentru ofertă, fără să stie sigur cum și de unde să îl apuce; satisfacția de după întalnirea organizata de el pentru stabilirea soluției și a alocării sarcinilor (nu s-a descurcat rău aici, Șefu’ arăta mulțumit, iar fiecare și-a înteles bine sarcina/responsabilitatea)

Apoi iar neliniște până când au venit primele răspunsuri de la colegi, satisfacția documentului final, nervii cauzați de docu-mentele de eligibilitate, printerul care a căzut evident în cel mai prost moment și ușurarea după trimiterea ofertei și primirea confirmării. Se pomeni zâmbind, după care se gratula singur: Zâmbește, Gogule, că n-ai să mai zâmbești mult timp de-acu-nainte...

Derulase filmul mult prea repede, tre-cuse peste momentul dezastrului fără să îl identifice. Ca și atunci, de altfel. Devenise mult prea arogant, prea ii merseseră

Gogu este un personaj amuzant, cinic pe alocuri, un introvertit pentru care monologul interior reprezintă o alternativă la viața reală. Cu ajutorul lui Gogu, analizăm diferite ipostaze din viața managerului de proiect și a echi-

pei sale și sugerăm soluții ușor de înțeles și aplicat. Cum ar spune Gogu...„aproape de bun simț”.

Vă invităm să-l urmăriți pe Gogu și să-i trimiteți sugestiile voastre.

Simona Bonghez, [email protected]

Speaker, trainer şi consultant în managementul proiectelor, partener al TSP(smartprojects.ro)

“Cred cu tărie în puterea jocului şi a metaforei şi îmi place la nebunie ca sesiunile mele de training să fie distractive şi interactive, în aşa fel încât participanţii să acumuleze informaţiile într-o manieră cât mai plăcută…”

diverse



lucrurile struna iar el, în loc să devină precaut, căzuse pradă delăsarii. Își aduse aminte: văzu în minte momentul în care era în fața excelului. Introdusese toate sesiunile de instruire, adăugase prețurile, a inserat coloana nouă pentru cheltuieli adiționale legate de transport și cazare...

- Of, Doamne!!! Și n-a actualizat for-mula în coloana de total...

- Probleme, Gogule, măh?Iar lăsase oftatul să-i scape. De data asta

insă raspunse:- Doar ce-am fost declarati câștigători

la licitație. - He i sup er ves te , s ăr i Mișu .

Nedumerirea își făcu însă imediat loc pe fața lui: care e problema?

- Am dat-o în bară. Am greșit prețurile totale în ofertă.

În liniștea lasată, stomacul i se strânse și mai tare, avea prima confirmare a gravității problemei pe care o cauzase. Vocea lui Mișu abia se auzi:

- Cât e pierderea?- N-am calculat, abia ce-am primit

emailul și am realizat ca lipsește ceva.În mod ciudat nu pierderea sau valoa-

rea pierderii îl afectase, ci faptul că o asemenea eroare a putut sa-i scape lui, cel ordonat, structurat, obsesiv perfecționist. Și cu tabieturi, da’ asta n-are a face, gândi el. El care are standarde atat de înalte, care le cere celor din jur aceeași minuțiozitate de care dă dovada el. Mă rog, dădea dovadă, că de acum... Un sentiment de rușine și de neputință îl năpădi. Reveniră gândurile dinainte, duhul din lampă, omul invizibil. Sau măcar de s-ar putea ascunde undeva. Subit il fulgeră singura ieșire posibilă din situația creată: demisia. Incercă să se îmbărbăteze singur: Asta e, tu ți-ai făcut-o, arată că ai coloana verticală, că înțelegi gra-vitatea situației și ești capabil să iți asumi responsabilitatea.

Ridică privirea către Mișu care conti-nua să-l privească parcă fără a-l înțelege. Probabil că în mintea lui se intreaba cum oi fi reusit?! Răspunse:

- Mă uit și calculez acum.Se așeză, dar nu deschise excelul cu

pricina, ci un document nou cu antetul companiei pe care scrise mare, pocnind demn tastatura: Demisie

Remarcă, intr-o doara, că nu mai are stomacul strâns, în schimb un gust amar îi invadase gura. Ii plăcea să lucreze aici. Nu vroia să plece. Dar nu exista altă opțiune. Hmm, și proiectul la care lucra acum, doar ce se pusese pe picioare, rezultatele

se arătau mai bune decat se așteptaseră. Contribuise și el la asta. Se crispă la auzul sunetului telefonului. Șefu’. Ce să-i spun? Răspunse automat.

- Gogule, ești tare băiete, ai dovedit-o cu prisosință. Nu că unii dintre noi n-ar fi fost convinși de asta. Vocea șefului răsuna plină de optimism, de bună dispoziție. Gogu înghiți în sec:

- Șefu, putem sta de vorbă câteva minute? Vin eu la matale.

- Când mă iei tu cu „matale” nu prea e a buna. Ce s-a întâmplat? Nemaiașteptând detaliile, poate înțelegând și din ton, Șefu’ adăugă: Ajung la firmă în 2 ore, trec pe la tine să te iau. Super treabă, Gogule! adaugă înainte de a închide.

„Ha-ha, super întradevar”, adăugă Gogu în sinea lui cu amărăciune. Are timp să iși scrie demisia.

Deschise totuși excelul cu oarece urma de speranță în suflet, poate totuși valoa-rea nu e atat de mare. Măcar pierderile financiare să fie acceptabile căci lovitura psihologică era greu de îndurat, iar imi-nenta întâlnire cu Șefu’ nu avea darul să atenueze cu nimic impactul.

Când Șefu’ băgă capul pe ușă, aproape ii păru mai rău de zâmbetul Șefului decât de poziția ingrată în care se afla el. Demisia era în plic, plicul în buzunarul sacoului, excelul cu calculele pierderii și opțiunile de reducere a impactului în fața lui. Lua foaia și il urma pe Șefu’.

Îl puse la curent imediat ce au intrat în birou. Deși iși repetase textul de câteva ori, cuvintele i-au ieșit greu, de parcă n-ar fi vrut să-l părăsească. Nu era o veste ușor de dat, dar nici de primit. Șefu’ stătea cu excelul în față de câteva minute bune în momentul în care vorbi:

- N-avem cum să acoperim diferența în totalitate, chiar dacă punem în aplicare toate sugestiile tale. Varianta discuției cu clientul n-aș exclude-o, deși sansele sunt mici. Era destul de clară specificația pri-vind erorile de calcul: valorile de la total prevalează.

Vocea era calmă, abătută. Gogu ar fi vrut ca el să strige, să-l ocărască, să-i reproșeze fel de fel, să-l amenințe cu datul afară. Și-atunci el ar fi scos demisia, să-i arate că nu e nevoie să fie dat afară, ci că iși dă el demisia: un triumf amar... Numai ca Șefu’ nu apelase la amenințări. Îi ceru deta-lii legate de una dintre opțiunile propuse de Gogu, discutaseră alternativele, ba chiar stabiliseră o întâlnire cu clientul. După aproape doua ore, încă nu era dat afară și

nici semne nu se arătau, iar el nu știa ce să facă cu demisia. După înca o ora, aveau un plan cu cap și coada care, dacă le iesea, diminua pierderile în mod considerabil. Dar și cu un efort considerabil...

- Ok, Gogule, ne vedem mâine dimineață să vedem ce ne iese din toate astea – încheie Șefu’ după ce mai trecuseră înca o data în revistă fiecare acțiune planifi-cată. Gogu insă nu se mișca. Demisia parca îl ardea în buzunar numai ca scenariul închipuit de el nu-i permitea să o scoată: trebuia să fie dat afără și-abia atunci demi-sia avea să fie înmânată cu demnitate.

- Gogule?! Șefu’ nu ințelegea ce era cu stana de piatră în fața lui.

- Aaaa... hmm... aaa... Cuvintele nu ieșeau și pace.

- Zi Gogule, crezi că a mai rămas ceva?- Pai... ăhm... eu... Sunt concediat, nu?!

Era mai mult o afirmatie decât întrebare, iar tonul era ușor sfidător, chiar revendicator.

- Auzi Gogule, nu crezi că am cheltuit prea mult ca să te dau acum afara?

- Nu ințeleg... Gocu fuse luat prin sur-prindere. Ce vrei să spui?

- Ia zi Gogule, crezi că mai faci vreodată o asemenea eroare ca și-acum?

- Oh, Doamne, cum să repet așa ceva? Niciodata! Sub nici o formă!

- Păi vezi, Gogule? Întradevăr ne costă ceva lecția asta, dar e o lecție învățată. Crezi că mai vreau să dau bani și altădată, să mai trecem o data prin toata tărășenia asta?!


Workshop

Managementul conflictelor

cu Simona Bonghez

Imaginaţi-vă cât de puternice ar putea fi relaţiile pe care le aveţi dacă aţi înţelege cu

adevărat ce îi stimulează pe ceilalţi - atât când lucrurile merg bine cât şi atunci când

există conflicte şi opoziţie…

Vă invităm să petrecem împreună o zi de descoperiri: ce stă la baza comportamentului celor din jurul nostru, ce îi face să “ticăie”, ce determină reacţiile lor în diverse situaţii. Vom învăţa să le interpretăm şi să gestionăm astfel relaţiile noastre, inclusiv conflictele. Va fi o zi încărcată, dar plină de bună dispoziţie, deschisă doar celor ce sunt gata să exploreze zone mai puţin convenţionale...

Instrumentul pus la dispoziţia participanţilor le va oferi o cale de acces spre ceea ce ne motivează, pe noi şi pe cei din jurul nostru şi îi va ajuta să comunice într-o manieră prin care să obţină rezultatele dorite. Se numeşte SDI (Strength Deployment Inventory, în română Inventarul Punctelor Forte Personale) şi reprezintă o suită de teste psihometrice dar şi o metodologie practică ce ne poate oferi puterea de a ne îmbunătăţi relaţiile şi de a gestiona în mod mai eficient conflictul.

Workshop-ul se va desfășura în București – 17 martie, Cluj – 4 aprilie și Timișoara – 27 aprilie (intervalul orar 9.30 – 16.30). Taxa de participare la acest workshop este de 400 lei + TVA (include pauza de cafea și prânzul) iar numărul de locuri este limitat. Detalii şi înscrieri: [email protected].

powered by

sponsor

Date post:	31-Jul-2015
Category:	Documents
Upload:	sergiucebotari
View:	69 times
Download:	3 times

Today Software Magazine N2/2012

Documents