Numarul 22/aprilie 2014 - Today Software Magazine by Today Software Magazine

Nr. 22 • Aprilie 2014 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

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

Cum câştigi jocul automatizării? Caching-ul imaginilor în aplicații iOS

Ingeniozitate, perseverență și conectivitate BDD, Javascript și Jasmine Managementul performanței în organizațiile orientate spre proiecte

Perspective asupra principiilor in design-ul orientat pe obiecte De ce durează atât de mult să terminăm un task?

O viziune din interiorul GPS Navigație

The Web’s Scaffolding Tool For Modern Webapps – Yeoman

OpenXML - Noţiuni introductive

IMAGINE – studiu al IT-ul clujean

Trenduri în HR (II) AOP folosind Unity

Machine learning in the Cloud Dezvoltare rapidă de aplicații web cu Oracle APEX

6 CCC - A ‘shot’ of programming George Platon

7 Bine aţi venit la Techsylvania! Vlad Ciurca

8 Cluj Innovation Days, 20-21 martie 2014 Andrei Kelemen

10 Ingeniozitate, perseverență și conectivitate Dhyan Or

11 Startup fără bani? Modelul de investiții Startcelerate Tudor Bîrlea și Gabriel Dombri

14 Cum câştigi jocul automatizării? Mihai Cristian

18 iOS image caching. Libraries benchmark Bogdan Poplauschi

21 THE WEB’S SCAFFOLDING TOOL FOR MODERN WEBAPPS – Yeoman Răzvan Ciriclia

23 OpenXML Noţiuni introductive Florentina Suciu și Gabriel Enache

26 BDD, Javascript și Jasmine Bogdan Cornianu

30 De ce durează atât de mult să terminăm un task? Gabriela Filipoiu

33 Metodologia Lean pentru Requirements Engineering Radu Orghidan

36 Trenduri în HR (II) Andreea Pârvu

38 Perspective asupra principiilor în design-ul orientat pe obiecte Cătălin Tudor

40 Machine learning in the cloud Roland Szabo

42 Dezvoltare rapidă de aplicații web cu Oracle APEX George Bara

44 O viziune din interiorul GPS Navigație Echipa iOS Skobbler

46 IMAGINE – studiu al IT-ul clujean Dan Ionescu

48 Managementul performanței în organizațiile orientate spre proiecte din România Adina Grigoroiu, CAPM

51 Lumy.ro usability testing Daniela Ferenczi

52 Optimizarea – de ce ar merita efortul? Tibor Laszlo

55 AOP folosind Unity Radu Vunvulea

58 Drept de autor și software. Câteva aspecte practice pentru programatori Claudia Jelea

editorial

Ovidiu Măţan, PMP

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

m fost la începutul lunii aprilie la …even mammoths can be Agile, în calitate de participant și organizator. A fost o bună ocazie de conectare la pulsul comunității și de reamintire a principiilor Agile, foarte importante în realizarea proiectelor inovative. Recent, s-a introdus o lege prin care se reglementa prezența dronelor. Practic nu ai voie să ridici drona în zone de locuințe, accesul fiind legal în spațiile deschise, filmatul nu este permis,dar nu se restricționează fotografierea aeriană. Nu vreau să comentez exact condițiile legii, dar în ceea ce privește dronele de dimensiuni mici, adresate publicului larg și care au mai puțin de un kilogram, dispozițile legii se încadrează în limitele acceptabile ale bunului simț. Totuși, din păcate, în câteva zile, ceea ce era perceput ca o tehnologie fantastică la care mulți se uitau cu admirație și pe care doreau să o obțină s-a transformat în ceva interzis. Până nu demult prima întrebare pe care o primeam în atunci când ridicam drona, era costul acesteia, acum prima întrebare este dacă e legală. Lipsa de informare corectă și plăcerea exagerări au fost din totdeauna cauzele unei percepții deformate. În cazul dronelor, unul dintre efectele acestei false percepții este o limitare a curiozității și a inovației publicului larg în această nouă cucerire a tehnicii, care este drona. Aceasta în condițiile în care asistăm la o cursă a celui ce va reuși să le folosească comercial pe scară largă, iar exemplul cel cel mai cunoscut în această direcție este Amazon. Trecând peste consecințele negative, aceasta este o bună lecție pentru cei ce conduc echipe și companii, un îndemn pentru o mai bună analiză a impactului legilor restrictive. O supralicitare a rolului de prevenție a incidentelor , pe care și-l arogă de fapt orice lege, poate duce la intimidarea spiritului antreprenorial. Revenind la conferința Agile, mi-am reamintit un lucru extrem de valoros: nu tot timpul știm ce vrem de la bun început și tocmai de aceea, această metodologie ne permite adaptarea în funcție de evoluția proiectului. Numărul 22 a avut tema principală tehnologiile cloud ,iar acest lucru este reflectat în paginile revistei. Începem cu câteva impresii de la Cluj Innovation Days. Vă adresăm o invitație la concursul de programare organizat de Catalyst CCC și la Techsylvania. Am povestit cu Vlad Ciurca, organizatorul Techsylvania, care ne-a promis în prima zi a evenimentului un hackaton în care vom putea programa dispozitive exotice precum Google Glass, pentru ca în cea de-a doua zi să asistăm la o serie de discuții interesante din zona antreprenoratului și a tehnologiei. Din Israel, descoperim un laureat al premiului Nobel și un mare antreprenor în Ingeniozitate, perseverență și conectivitate. Startcelerate ne promite în viitor startup-uri fără bătăi de cap pentru antreprenori din perspectiva implementării, iar pentru companii o conectare la inovația locală și din UK. Cum câştigi jocul automatizării? deschide seria articolelor tehnice. Acesta propune o foarte interesantă ierarhizare pe nivele a celor ce automatizează testarea aplicațiilor și propune de asemenea o platformă de lucru. Eficiența caching-ului imaginilor pe platforma iOS este abordată și demostrată prin câteva benchmark-uri.Îmbunătățirea productivității este analizată în articolul despre Yeoman. Celor curioși de conținutul unui fișier Excel xlslx vă recomand articolul OpenXML - Noţiuni introductive. BDD, Javascript și Jasmine ne prezintă pe larg ce este Behavior Driven Development și aplicarea acestuia. În aria management-ului vă propunem articolul Why does it take you so long to finish a task?, Requirements Engineering using the Lean methodology și Managementul performanței în organizațiile orientate spre proiecte din România. O analiză a programării orientate pe obiect din perspectiva entropiei Shannon o puteți găsi în Perspective asupra principiilor în design-ul orientat obiect iar Machine learning in the cloud ne prezintă soluții online pentru învățarea automată din perspectiva inteligenței artificiale. Încheiem propunerile noastre cu IMAGINE – studiu în IT-ul clujean, studiu care a urmărit percepția companiilor clujene din perspectiva studenților. Vă dorim o lectură plăcută !!!

Ovidiu Măţan

Fondator al Today Software Magazine

nr. 22/Aprilie | www.todaysoftmag.ro

Lista autorilor

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

Dhyan Or

Claudia Jelea

CEO & Co-fondator @ Social ReHub

Avocat & Consilier in domeniul marcilor @ IP Boutique

do@socialrehub.info

claudia.jelea@jlaw.ro

Andrei Kelemen

Roland Szabo

Director executiv @ IT Cluster

Junior Python Developer @ 3 Pillar Global

andrei.kelemen@clujit.ro

roland.szabo@3pillarglobal.com

Tudor Bîrlea

Vlad Ciurca

Co-fondator @ Startcelerate

Product Guy. Tech Events Producer. Connector @ Techsylvania

tudor@startcelerate.com

Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com

vlad@techsylvania.co

Cătălin Tudor

Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com Contabil : Delia Coman delia.coman@todaysoftmag.com Produs de

Today Software Solutions SRL str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com

Radu Orghidan

Requirements engineer @ ISDC

Gabriela Filipoiu

gabriela.filipoiu@accenture.com Software Engineering Analyst @ Accenture

Răzvan Ciriclia

www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag

ctudor@ixiacom.com

radu.orghidan@isdc.eu

razvan.ciriclia@betfair.com software engineer @ Betfair

Principal Software Engineer @ Ixia

Gabriel Enache

gabriel.enache@fortech.ro Software engineer @ Fortech

Mihai Cristian

mihai.cristian@hp.com Test Automation Engineer @ HP

ISSN 2284 – 6352 Claudiu Cosar

claudiu.cosar@3pillarglobal.com Software engineer @ #Pillar Global

Bogdan Poplauschi

bogdan.poplauschi@yardi.com Senior iOS Developer @ Yardi Romania

Florentina Suciu Adina Grigoroiu, CAPM

adina.grigoroiu@confucius.ro

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

Trainer și consultant @Colors in Projects

florentina.suciu@fortech.ro Software engineer @ Fortech

George Bara

Tibor Laszlo

Business Consultant @ SDL

Partner & Consultant @Improving-IT

gbara@sdl.com

tibor.laszlo@improving-it.com

www.todaysoftmag.ro www.todaysoftmag.com

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

eveniment

CCC - A ‘shot’ of programming

curt, intens și din ce în ce mai popular, CCC (Catalysts Coding Contest) a devenit un fel de atracție ‘sezonieră’ pentru programatorii clujeni și nu numai. Concursul Catalysts Coding Contest (http://contest.catalysts.cc ) a început în anul 2007 în Austria cu un număr relativ mic de participanți, dar feedback-ul primit a fost peste așteptări! În prezent, suntem la ediția cu numărul 18 a concursului care a ajuns să se extindă atât în România (Cluj) cât și în India. Concursul a căpătat notorietate în Cluj încă din 2011 de când a început să se desfășoare și pe plaiurile românești. De ce notorietate? Datorită structurii sale inovatoare. Fiecărui participant i se dă la dispoziție 4 ore să rezolve o singură problemă, structurată pe 7 nivele. Nu există constrângeri de limbaj, concurentul putând să scrie în orice limbaj de programare dorește și se pot forma chiar și echipe de maxim 3 persoane. Părerile despre problemă au fost diverse, dar majoritatea converg înspre “a fost greu!”. Dificultatea crește în mod evident, o dată cu nivelul, astfel încât la ultimul nivel ajung în medie maxim 3 sau 5 concurenți. Numărul participanților a crescut în mod constant atât în Cluj cât și în celelalte locații ajungând la ultima ediție la un total de 600 de concurenți! Condițiile de participare sunt cât se poate de simple: • Echipă de maxim trei persoane cu condiția să se folosească un singur calculator / echipă. • Nu există restricții asupra limbajelor de programare. • Nu există restricții asupra resurselor permise (cărți, internet, etc.). • Concurentul (sau echipa) trebuie să se înregistreze în prealabil online, pe site-ul oficial al concursului cât și la fața locului, la începerea concursului.

Exemplu de problemă: The Harvester

La primul nivel al acestei probleme se dă un câmp al unul fermier (Dave) care e parcelat în segmente egale în X linii și Y coloane. Fiecare segment are asociat un număr de la 1 la X*Y. Inițial se cere să se afișeze cea mai bună posibilitate de a parcurge parcele în timpul cel mai scurt. Una dintre soluții este să plece din stânga sus, mergând în serpentine înspre ultima parcelă din dreapta jos.Vezi figura de mai jos:

La cel de-al doilea nivel, jucătorului i se impune o constrângere: tractorul nu e neapărat să plece din poziția de stânga sus! La nivelul 3 tractorul trebuie să aibă posibilitatea să meargă atât de pe o coloană pe alta (E → V și invers) cât și de pe o linie pe alta (N → S, S → N). Problema se complică din ce în ce mai mult, intervenind mai multe tractoare și mai multe posibilități de a parcurge toate parcelele de pământ. Catalysts Coding Contest se dovedește a fi un mare succes atât pentru noi ca firmă, cât și pentru concurenții care reușesc să acumuleze cunoștințe noi și să întâlnească oameni pasionați de programare și de rezolvarea problemelor dificile.

Platforma CCC (https://catcoder.catalysts.cc) oferă posibilitatea de a participa online la concurs, fără a fi nevoit să se fi prezent fizic la vreuna din locații. Cu toate acestea, concurenții care aleg să participe online nu vor putea fi premiați cu premiile în bani. Păreri și o prezentare generală a concursului pot fi găsite aici:

CCC în India! După câteva luni de planificare, zilele de 9 și 15 martie 2014 ne-am bucurat să putem găzdui primul concurs CCC în India, în Kolkata respectiv Kharagpur. Numărul de participanți a fost de ~350 de participanți dintre care jumătate au ales să concureze în echipe de două persoane. Detalii și poze găsiți pe site-ul oficial al concursului: www.catalysts.cc/en/.

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

George Platon

George.Platon@catalysts.cc Software developer @ Catalyst

eveniment

TODAY SOFTWARE MAGAZINE

Bine aţi venit la Techsylvania!

iind situat în apropiere de Belgrad, Budapesta, Sofia, Kiev sau Bucureşti, Cluj-Napoca este un oraş cu o poziţie strategică în Europa de Est. Capitală europeană a tineretului în 2015 şi unul dintre cele mai ospitaliere oraşe din Europa potrivit Comisiei Europene, Cluj-Napoca are foarte multe oferit nu doar în ceea ce priveşte turismul, mâncarea sau locurile extraordinare care pot fi vizitate, dar şi atunci când vorbim despre ecosistemul IT local: cu peste 4000 de absolvenţi în domeniu în fiecare an, Clujul se bucură de un număr mare de tineri cu talent tehnic ale căror iniţiative inovatoare devin din ce în ce mai cunoscute pe plan internaţional. În acest context este firească apariţia Techsylvania, cel mai mare eveniment tech din regiune şi unul dintre cele mai importante din Europa Centrală şi de Est. Prima ediţie Techsylvania se va desfăşura între 31 mai şi 2 iunie şi va aduce împreună unele dintre cele mai creative persoane din regiune, experţi tehnici şi inovatori care îşi vor împărtăşi propriile experienţe şi cunoştinţe pentru a contribui la dezvoltarea tehnologică şi creşterea gradului de inovaţie din Cluj-Napoca. Techsylvania debutează pe data de 31 mai cu un hackathon cu durata de 24 de ore şi continuă până în 2 iunie cu o conferinţă de o zi, care va aduce în faţa audienţei unii dintre cei mai apreciaţi profesionişti în domeniul tehnologiei la nivel internaţional. Hackathon-ul care va avea loc se adresează dezvoltatorilor care îşi doresc să pună bazele unor aplicaţii cu potenţial disruptiv în domeniul tehnologiilor connected şi wearable. În plus, cei peste 100 de participanţi la eveniment vor avea ocazia să testeze dispozitivele puse la dispoziţie de partenerii programului. În timpul celor 24 de ore ale hackathon-ului, cei peste 100 de dezvoltatori vor avea ocazia să lucreze cu diferite tipuri de dispozitive mobile şi să folosească tehnologii conectate pentru a dezvolta propriile aplicaţii şi produse în domeniu. Participanţii la eveniment pot veni alături de echipele lor sau se pot alătura unei alte echipe şi au obiectivul de a construi o aplicaţie funcţională de-a lungul evenimentului. La final, fiecare echipă îşi va prezenta produsul în faţa audienţei pentru a convinge publicul de potenţialul acestuia. Cele mai bune proiecte vor fi premiate, iar primele 3 echipe vor primi bilete de acces la conferinţa care va avea loc pe data de 2 iunie şi, mai mult decât atât, vor avea şansa să îşi prezinte produsele în faţa întregii audienţe a Techsylvania. Cea de-a doua parte a evenimentului este conferinţa, unde sunt aşteptate peste 200 de persoane, speakeri şi invitaţi de excepţie din întreaga lume. Pasionaţii de tehnologie vor avea astfel ocazia să fie inspiraţi, să întâlnească potenţiali investitori, parteneri sau colaboratori şi mai mult decât atât, să interacţioneze în mod direct cu oameni cu preocupări şi pasiuni similare. Techsylvania se remarcă în peisajul evenimentelor locale prin calitatea speaker-ilor care vor urca pe scena evenimentului pentru a-şi împărtăşi propriile experienţe şi a discuta despre inovaţie în tehnologie şi dezvoltare de produse. Printre aceştia se numără: Marcus Segal (Ex-COO Casino Division Zynga & Entrepreneur in Residence la The Summit, strateg şi manager de operaţiuni cu peste 15 ani de experienţă în domeniul tehnologiei), Paddy Cosgrave (Fondator al The Summit şi F.ounders, descris de Bloomberg ca fiind „Davos for Geeks” şi organizator al întâlnirii anuale a 250 de CEO ai celor mai importante companii în tehnologie la nivel mondial), Jack Levine (Fondator şi CEO Electric

Objects, startup cu sediul în New York City care dezvoltă un ecran conectat ce aduce obiecte digitale speciale în casele utilizatorilor), HP Jin (Co-Fondator şi CEO Telenav, liderul global în domeniul serviciilor de localizare, navigare auto şi publicitate targetată în funcţie de locaţie, companie care a achiziţionat la începutul anului Skobbler) sau Aryk Grosz (Co-Fondator şi CTO Mixbook Inc., un serviciu de stocare online a fotografiilor care a primit numeroase premii până în prezent şi a fost menţionat în publicaţii precum New York Times, USA Today sau Today Show din Statele Unite). Deşi la prima ediţie, Techsylvania promite să revoluţioneze ecosistemul tech local şi să aducă o contribuţie importantă la dezvoltarea acestuia. Organizat de Vlad Ciurca şi Oana Petruş, Techsylvania se bucură de susţinerea unei echipe experimentate şi a unui board de advisor-i excepţional. Rezultatele înregistrate până în prezent de oamenii din spatele proiectului reprezintă o garanţie pentru succesul acestuia: membrii echipei au organizat trei ediţii de succes ale Startup Weekend Cluj, au dezvoltat comunităţi de business promiţătoare printre care se numără Romanian Managers Cluj cu peste 800 de membri şi Maramureş Business Club, şi au iniţiat evenimente educaţionale pentru studenţi în cadrul #defineCluj. Pasionaţii de tehnologie, inovaţie şi produse cu potenţial disruptiv nu trebuie să rateze prima ediţie a Techsylvania care va avea loc între 31 mai şi 2 iunie în Cluj-Napoca! Mai multe detalii despre program şi invitaţii evenimentului sunt disponibile pe siteul Techsylvania http://techsylvania.co, iar primii 25 de participanţi beneficiază de o ofertă specială şi pot achiziţiona 2 bilete la preţ de 1. Ulterior, preţul biletelor early bird va fi de 69 EUR, iar înregistrările pot fi efectuate online pe site-ul evenimentului. Techsylvania se adresează tuturor inovatorilor şi pasionaţilor de tehnologie care îşi doresc să discute în mod direct cu unii dintre cei mai buni profesionişti în domeniu din regiune, să înveţe şi să se conecteze cu oameni care pot face o diferenţă. Dacă te numeri printre ei, ne vedem la Techsylvania!

Vlad Ciurca

vlad@techsylvania.co Product Guy. Tech Events Producer. Connector @ Techsylvania

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

eveniment

Cluj Innovation Days, 20-21 martie 2014

red că ați ales cel mai bun moment pentru a crea această platformă (Cluj Innovation City – Cluj orașul inovației) și veți avea tot sprijinul meu și al Comisiei Europene pentru a materializa asemenea idei aducătoare de valoare. Vă mulțumesc și aflați că puteți conta pe sprijinul meu” - D-nul. Dacian Ciolos, Comisar European, Direcția Generală Agricultură și Dezvoltare Rurală

A doua ediție a Cluj Innovation Days (CID) a fost, din toate punctele de vedere, un succes. Pe perioada celor două zile Cluj-Napoca a devenit capitala inovației în România. Am reușit, încă o dată, să afirmăm orașul nostru drept unul dintre locurile unde se întâmplă lucruri importante. Pentru cititorii care nu știu ce reprezintă CID, voi încerca să rezum în paragrafele care urmează ceea ce avem noi în minte și cum a decurs evenimentul din acest an. Cluj Innovation Days este un eveniment anual internațional care este centrat pe încurajarea inovației, cercetării și antreprenoriatului drept ingrediente cheie înspre construirea sustenabilității în dezvoltarea afacerilor și a comunității. Obiectivul nostru pe termen lung este să facem din acest eveniment un reper internațional pentru oportunități de parteneriate între mediul academic, cel de afaceri și autoritățile publice, acolo unde inovația și transferul tehnologic sunt poduri de încredere, de legătură între diversele sectoare. Evenimentul din acest an a fost organizat de Cluj IT Cluster și și-a propus să reunească pe toți cei mai sus menționați, mai exact oameni de știință și studenți, reprezentanți ai guvernului, conducători și antreprenori. Pe parcursul celor două zile, peste 400 de participanți au fost implicați în conferințe și discuții dedicate rolului inovației și antreprenoriatului în dezvoltarea socio-economică. Evenimentul a fost găzduit cu amabilitate Facultatea de Științe Agricole și Medicină Veterinară din Cluj-Napoca, una dintre cele mai venerabile și totodată dinamice instituții de învățământ superior din România. Vă voi lăsa pe dumneavoastră să hotărâți dacă am avut sau nu succes, prezentându-vă faptele și cifrele conferinței. • 51 speake r i : 22 Ple nar, 12 Arta Inovației, 8 Facilitarea Antreprenoriatului, 9 Etalarea Inovației • 13 speakeri internaționali, • 2 Membri ai Comisiei Europene, • 4 Directori și alți delegați ai Comisiei Europene. • 18 ore de prezentări și discuții

Participarea la conferință în cele două zile numără: • 200+ participanți din mediul de afaceri • 130+ participanți din mediul academic • 40+ oficiali publici • 40+ studenți În ceea ce privește conținutul CID2014 a fost foarte variat și organizat pe patru direcții principale: Sesiunea Plenară, Arta Inovației, Facilitarea Antreprenoriatului și Etalarea Inovației. Mulți dintre oratorii și participanții noștri și-au exprimat impresiile p ozitive în legătură c u conținutul și organizarea evenimentului. Pe parcursul primei zile de conferință, am avut vorbitori importanți care au susținut discursuri esențiale și au transmis mesaje încurajatoare, cum ar fi cel al domnului Dacian Ciolos,Comisar European, Direcția Generală Agricultură și Dezvoltare Rurală, d-nul Johannes Hahn, Comisar European, Direcția Generală Politică Regională și Urbană, dl. Mihnea Costoiu, Ministru Delegat pentru Învățământul Superior din Guvernul României și un număr de alți oficiali importanți din guvern și conducerea locală. Arta Inovației a încercat să capteze esența unui proces unic și foarte important, acela de a genera idei valoroase care se pot concretiza în produse pentru economia reală. În timpul acestei teme, vorbitorii și participanții au dezbătut componentele principale ale managementului inovației și modalitățile de exploatare a rezultatelor sale, prin generarea de creștere și profit. Pe parcursul celei de-a doua zile a conferinței, am programat două teme paralele. Sub titlul Facilitarea Antreprenoriatului am discutat despre ce înseamnă antreprenoriatul și intraprenoriatul, cum să conduci un startup inovativ sau cum să gestionezi un produs secundar, cum să te asiguri că ideile primesc finanțarea de care au nevoie și cum să abordezi afacerile global. Etalarea Inovației a încercat să motiveze audiența cu o serie de povești de succes. Persoanele

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

din spatele unor asemenea povești ne-au împărtășit experiențele lor. Planul media pe care l-am conceput pentru eveniment a generat o acoperire mare în presă. Potrivit agenției noastre de PR, au existat de două ori mai multe relatări decât în medie pentru o conferință de aceste dimensiuni. Acoperire Media: • Activități media: 4 comunicate de presă / 5 interviuri/solicitări de informații; • Conferința de presă: 24 publicații naționale prezente și peste 30 de jurnaliști; • Publicații/TV: 10 publicații offline – tipar / 170+ publicații online / 4 emisiuni TV/știri; • Valoarea totală a acoperirii media a fost estimată la 80.422 euro. Evenimentul a avut propriul său website, www.clujinnovationdays.com; din momentul lansării sale și până imediat după eveniment, am avut 1857 de vizitatori unici și un total de peste 10.200 vizualizări de pagini.

Aș dori să închei prin a mulțumi tuturor partenerilor noștri, în special BRD Group Societe General, Microsoft și Huawei. O mențiune specială pentru gazdele noastre, Institutului de Științe ale Vieții din Campusul USAMV. Și, bineînțeles, cu invitația la ediția din anul următor a Cluj Innovation Days.

Andrei Kelemen

andrei.kelemen@clujit.ro Director executiv @ IT Cluster

eveniment

TODAY SOFTWARE MAGAZINE

BattleLab Robotica cea mai mare competiție sumo de roboți din Transilvania

acultatea de Inginerie Electrică din cadrul Universităţii Tehnice din ClujNapoca în colaborare cu organizația studențească BEST ClujNapoca te invită în data de 12 aprilie 2014 la a patra ediţie a competiţiei BattleLab Robotica. Evenimentul se va desfăşura pe data de 12 aprilie în incinta Universităţii Tehnice, pe strada Bariţiu nr. 26, în amfiteatrul P03 de la ora 10:30.

Competiția constă în implementarea de roboţi sumo autonomi, capabili să identifice şi să elimine de pe suprafaţa de joc robotul advers în competiţii de tip “1 la 1”. În cadrul acestei ediţii sunt înscrise peste 15 echipe de studenți care au muncit luni în șir la realizarea robotului aplicând cunoştinţe de inginerie electrică, mecanică, automatică şi calculatoare. Pentru a putea construi roboţii, studenţii au dezvoltat un proiect complex care implică atât partea tehnică cât şi cea de management investind sume de bani de ordinul a sute sau chiar mii de euro. Echipele sunt formate din maximum patru studenţi. Competiţia respectă regulile internaţionale de sumo robotic în ceea ce priveşte dimensiunile suprafeţei de joc precum regulile de desfăşurare şi de angajament. Roboţii respectă prevederile constructive ale clasei medii, masă totală: maxim 3kg, dimensiuni 20 x 20 cm, fără limită de înălţime. Echipele cu cele mai bune performanțe vor fi premiate şi vor fi ajutate să participe la Campionatele Internationale de Robotică de la Viena şi la alte competiţii importante de profil. Evenimentul BattleLab Robotica 2014 este susțínut de companiile partenere: BOSCH, msg systems Romania, Skobbler, Wenglor și sponsorii: EVOcomputers, Frequentis, Hama, Microchip, RoboFun, Madd Electronics Group. Sunt așteptați peste 200 de spectatori curioși să vadă aceste lupte sumo între roboți în data de 12 aprilie în incinta Universităţii Tehnice, pe strada Bariţiu nr. 26, în amfiteatrul P03 de la ora 10:30 Mai multe informaţii despre eveniment pot fi găsite la adresa www.battlelab.ro sau pe Facebook la adresa www.facebook.com/ BattleLabRobotica BEST (Board of European Students of Technology) este o organizaţie internaţională, nonprofit, în continuă creştere. Încă din anul 1989, BEST oferă studenţilor din toată Europa posibilitatea de a ajunge la o mai bună înţelegere a culturilor şi a

societăţilor pentru a-şi dezvolta capacitatea de a lucra în diverse medii culturale. Un alt scop este de a crea o legătură cât mai strânsă între partenerii din triunghiul „Student-Companie-Universitate”. În prezent, BEST este organizată în 96 de Grupuri Locale BEST, în 33 de ţări europene, cu mai mult de 3000 de membri activi. Grupul Local BEST ClujNapoca, creat în 1995, este format din voluntari din cadrul Universităţii Tehnicedin ClujNapoca. Scopul nostru este de a oferi toate condiţiile pentru dezvoltare personală, realizată prin educaţie complementară, încurajând fiecare student să participe la proiecte inovative şi provocatoare, cum ar fi: training-uri, workshop-uri, suport în carieră (Jobshop, Competiţii inginereşti), cursuri academice etc.

În anul 1960 ia ființă, în cadrul Facultății de Mecanică, secția de Inginerie Electrică, care în 1964 devine Facultatea de Inginerie Electrică, cu 528 de studenți. După 13 ani de la înființare, în 1977, Facultatea se dezvoltă prin secțiile noi de Electronică, respectiv, Telecomunicații și Automatică și Calculatoare. Misiunea Facultății de Inginerie Electrică este realizarea la un alt nivel de calitate a învățământului și cercetării științifice, în domeniile Inginerie Electrică, Inginerie Energetică, Științe Inginerești Aplicate, Inginerie și Management, în context național și internațional, răspunzând necesității de dezvoltare intelectuală, profesională și socială a individului și de progres a societății românești. Mai multe informații pe site-ul: ie.utcluj.ro

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

interviu

Ingeniozitate, perseverență și conectivitate

atorită recentei extinderi a rutelor de zbor din Cluj, pot acum să ajung cu mașina în 15 minute la aeroport, apoi să iau un avion, practic, către orice loc din Europa sau Orientul Mijlociu și să ajung acolo în aceeași zi, la timp pentru o întâlnire. În vizita mea recentă în Israel, am avut ocazia să întâlnesc niște oameni remarcabili: un laureat al premiului Nobel, foarte renumit și un investitor faimos, care este de asemenea și un activist în probleme sociale. Mai întâi, am făcut cunoștință, la Institulul de Tehnologie al Israelului, cu Dan Shechtman, care a primit premiul Nobel în Chimie acum trei ani. Profesorul Shechtman organizase un curs deschis de antreprenoriat. A expus studenților conceptul și practica începerii propriei lor afaceri și a invitat oameni de afaceri locali care și-au spus poveștile carierei lor. Toți aceștia au început de la zero și treptat au ajuns lideri în Dan Shechtman domeniile lor respective. Propria lui poveste este una neobișnuită. El a descoperit mai întâi ceea ce este cunoscut acum drept ”cvasi-cristale” în 1982, dar nimeni nu a crezut că e ceva serios. Toți oamenii de știință au luat în derâdere descoperirea sa, de la colegii de cercetare ai lui Shechtman și până la renumitul dublu laureat al Premiului Nobel, Linus Pauling, care a fost citat referindu-se la Shechtman, spunând: ”Nu există așa ceva ca cvasi-cristale, ci numai cvasi-savanți”. Shechtman a continuat să creadă în descoperirea sa, fără a ține seama de cei care i se opuneau, iar munca sa este un exemplu de încredere în sine, bazată pe experiență și perseverență. Aproape treizeci de ani mai târziu, el a reușit să demonstreze greșeala criticilor săi și a câștigat premiul Nobel. De atunci, a ținut mereu discursuri în întreaga lume, iar programul său este încărcat pentru încă mult timp. Când l-am rugat să vină și să vorbească în România, mi-a putut oferi câteva date probabile de vizitare abia pentru 2016. Altă persoană importantă întâlnită luna trecută la un eveniement dedicat startupurilor a fost Erel Margalit . În calitate de membru recent ales al parlamentului, el vorbea despre inițiativele sale în ceea ce privește oferirea de mai multe posibilități comunităților mai puțin favorizate din Israel. Margalit este mai bine cunoscut prin firma sa de investiții, Erel Margalit Jerusalem Venture Partners, care a gestionat peste 1 miliard $ în investiții, transformându-i în 17 miliarde $, lăudându-se cu câteva dintre cele mai memorabile succese din istoria startup-urilor israeliene, precum QlikTech, XtremIO, CyOptics, Netro Corp, Chromatis, Precise și Cogent. O parte din bani i-a câștigat din investiții în tehnologie, apoi Margalit s-a îndreptat înspre proiecte sociale și culturale

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

în Ierusalim, concentrându-și atenția pe cartierele defavorizate și familiile sărace. De asemenea, a deschis un club unde au loc spectacole și un incubator pentru startup-uri chiar lângă acesta, afirmând că profesioniștii IT trebuie să aibă legături cu muzicieni și artiști din alte domenii pentru a deveni creativi. Margalit spune că Ierusalimul ar trebui să atragă tineri prin oferirea de slujbe high tech, finanțare startup și viață culturală. Margalit mai spune că este pasionat de a detecta în ce anume excelează oamenii și comunitățile precum și de construirea unui cluster în jurul unei anumite industrii care are șansa de a concura la nivel mondial. Când nu împlinise încă treizeci de ani, s-a întâlnit cu Primarul Ierusalimului și i-a sugerat să transforme orașul bogat în istorie, dar sărac din punct de vedere economic într-un centru de tehnologie de vârf și să invite jucători internaționali să își construiască centrele R&D în Ierusalim. Acum, el face același lucru pentru orașul mai puțin cunoscut, din deșert, Be’er Sheva. Ideea este să facă din acesta capitala mondială a securității informației, atrăgând companii precum Telekom, IBM, Lockheed Martin, Oracle și EMC, care vor investi, împreună cu JVP și Ben Gurion University în ”Cyber Spark”-ul din Be’er Sheva. Be’er Sheva este, din întâmplare, un oraș înfrățit cu ClujNapoca. Este al șaptelea oraș ca mărime din Israel, cu aproximativ 200.000 de locuitori și cu peste 20.000 de studenți, mulți dintre aceștia, atrași din alte părți ale țării. Mulți ani, orașul a fost neglijat și lăsat pe dinafara bugetelor naționale de dezvoltare; tinerii s-au mutat la Tel Aviv și nu s-au mai întors, iar populația a devenit din ce în ce mai bătrână și mai săracă. Dar în ultimii ani, Be’er Sheva a reușit să atragă din nou interesul, mulțumită în parte unui nou primar, mai dinamic, și unui campus universitar vibrant. Orașul a fost legat recent de Tel Aviv, care se află la o distanță de 113 km, printr-un tren rapid care face mai puțin de o oră și permite un schimb mai mare de idei și capital uman între centru și periferie. Întors în Cluj, cu greu pot să mă abțin de la o comparație între cele două orașe înfrățite. În primul rând, găsirea unei teme în care comunitatea IT din Cluj să poată inova și concura la nivel mondial, atrăgând pioni internaționali drept parteneri și investitori, ar face orașul atractiv pentru locuitorii săi și pentru alți români și străini. În al doilea rând, mi-ar plăcea tare mult să pot ajunge de la Cluj la București într-un timp rezonabil, fie cu un tren de mare viteză, o autostradă bună sau o linie aeriană low cost. Călătoriile accesibile ar permite oamenilor să meargă la întâlniri în capitală, dimineața, poate să vadă un concert seara și să se întoarcă acasă în acceași noapte. Aceasta ar aduce, de asemenea, mai mulți oameni și mai multe idei din București, în beneficiul ambelor orașe. Dhyan Or

do@socialrehub.info CEO & Co-fondator @ Social ReHub

startups

TODAY SOFTWARE MAGAZINE

Startup fără bani? Modelul de investiții Startcelerate

tim cu toții că startup-urile au ajuns un hot trend, mai ales în ultimii 7-8 ani, cu povești de succes care ne uimesc, dar ne dau și o consistentă doză de serotonină. Dacă ești în technologie, Silicon Valley este fără îndoială un etalon și un fel de țară a speranței pentru orice antreprenor din această zonă. Și pe bună dreptate. Replicând mai mult sau mai puțin modelul, locuri precum Londra, Ierusalim, Berlin, Tallin sau chiar Paris încep să capete tot mai multă vizibilitate ca epicentre Europene de creare și dezvoltare a startupurilor. În ritm specific ardelean și la o scală diferită, Clujul e ghidat de același model.

Modelul Silicon Valley

Oricât de multă inovație ar fi în antreprenoriatul technologic, modelul pe care ecosistemul acesta se dezvoltă este unul surpinzător de liniar și rar contestat. El presupune mai mulți actori care se află într-un dans aproape nupțial în jurul unei speranțe comune: să creeze ceva (un produs sau un business) în cât mai scurt timp, în așa fel încât printr-o formă de exit toți cei care și-au asumat riscul extrem de mare de a-și pune resursele într-o asemenea aventură să poată să își multiplice investiția. Acești actori sunt de regulă: fondatorii, investitorii de diferite niveluri (de la Angel Investors la Venture Capitalists), instituțiile de accelerare (atât acceleratoare, cât și incubatoarele) și o întreagă rețea de furnizori de servicii. Flow-ul tipic acestui model e de asemenea liniar, deși se vrea geometric: investitorii scot niște bani din buzunar ca să permită unui startup să își verifice anumite ipoteze (fie pentru construirea unui demo, fie pentru upgrade-uri technologice, fie pentru generare de tracțiune), startupul se lansează într-o cursă de growth astfel încât aibă argumente suplimentare de a primi o altă investiție, care să îi permită să mai experimenteze în găsirea – cum spune Steve Blank – a unui business model scalabil și profitabil. Și lucrurile se iau de la capăt, până se ajunge fie la un exit de succes, fie la o împotmolire în faliment. Ecuația fundamentală a riscului balansează perfect ecuația valorii în acest sistem: cu cât o resursă externă apare mai devreme întrun startup, cu atât riscul este mai mare și prin urmare valoarea ei este mai semnificativă raportată la equity-ul startup-ului. Mecanismul funcționează perfect în zonă de vârf a spectrului (startup-urile de succes aduc beneficii majore pentru o mână de investitori și fonduri aventuroase), dar e falimentar pentru restul ecosistemului (majoritatea proiectelor antreprenoriale fie sunt blocate de lipsa de finanțare, fie se împotmolesc în căutare într-un limb fără ieșire). Și acest model poate funcționa și așa

cu două condiții: 1) să existe bani de risc suficienți disponibili într-un stadiu cât mai timpuriu; 2) să existe un număr mare de antreprenori motivați să creeze startupuri.

Modelul european: clona defectă a Silicon Valley-ului Ceea ce s-a încercat în ecosistemele europene de startups funcționează pe aceeași structură, cu o excepție importantă: existența fondurilor de risc este mai restrânsă local și, încă mai i mp or t ant , d e c i ziile de investiții se bazează pe alt model de risc. Să ne explicăm. Diferența esențială dintre investitorii europeni și cei de pe coasta vestică americană este că primii vor scoate o sumă de investiții cu atât mai dificil cu cât startupul este mai early stage și mai ne-validat. Acești investitori, cu rare excepții, nu riscă seed money (câteva zeci de mii de Euro) pentru a pune în piață un demo, de exemplu, sau pentru a testa ipoteze. Ei se așteaptă ca fondatorii să-și fi asumat deja aceste riscuri și să fi trecut de acel stadiu. Mulți dintre ei au o setare și mai sănătoasă: pun bani doar

când sunt indicații puternice (în sensul de hard data precum generare de revenue) că startupul are o ecuație clară de ROI și o dată în calendar pentru break-even. Setarile acestea, chiar dacă sănătoase dintr-o perspectivă de risc, sunt oarecum ciudate și creează un mare impediment de

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

startups Startup fără bani? Modelul de investiții Startcelerate dezvoltare a întregului ecosistem. Dar aici intervine Startcelerate, ca un nou model de accelerare a dezvoltarii startupurilor printr-o nouă structură investițională.

Startcelerate: direct resurse, nu bani și mai mare transparență a progresului

Când am început să lucrăm la modelul Startcelerate, am pornit de la următorea setare: ce ar fi ca startupurile să aibă un mod în care să fie conectate cu companii puternice de dezvoltare IT în așa fel încât să poată crea mai repede produse pe care să le poată testa în piață, iar companiile de IT să-și folosească o parte din resursele pe care oricum le plătesc (fie care le folosesc 100%, fie că nu) pentru a-și crea un portofoliu investițional care să le dea posibilitatea să iasă din blocajul pe care outsourcing-ul îl creează. Pentru companii, riscul este minor, iar pentru fondatorii de startupuri oportunitățile depășesc de departe costurile într-o asemenea structură partenerial-investițională.

Soluțiile Startcelerate

cuantificabilă în bani, ea este tratată ca un aport la capital (equity round). Pentru a adresa problemele din modelul existent, Startcelerate vine cu câteva soluții: • Investitorii pot lua decizii calculate. Startcelerate va permite căutarea, analiza și compararea startupurilor pe baza unui profil standardizat și a unor metrici relevanți tipului de proiect și stadiului în care startupul se află. În acest mod procesul de decizie pentru a lucra cu un startup se completează cu o zonă de informatie specifică și esențială. • Implicarea investițională poate fi una graduală și multiplă. Pentru a limita expunerea, fondurile și resursele pot fi alocate pas cu pas, atingerea unui obiectiv funcționând ca declanșatori pentru următoarea rundă de investiție. Practic, startupul spune unde se află, unde este următorul milestone, ce se va face ca să se ajungă acolo și ce resurse externe sunt necesare, întreg progresul fiind înregistrat și accesibil în cadrul platformei. • Contrac te simple și e f iciente de investment. Pe latura juridică, Startcelerate vine în primul rând cu o simplificare și eficientizare a întregului process, realizate printr-o serie de contracte de tip security, configurabile direct pe platformă. Contractul permite investitorilor să cumpere actiunile emise printr-o majorare de capital ulterioară sau într-un termen prestabilit, la un preț preferențial.

Startcelerate este setată ca o platformă de investiții alternative în startupuri în care, pe de o parte, companiile de IT (în prima fază) pot să își aloce o parte din resursele interne să ofere soluții unor startupuri în schimbul unei forme de proprietate asupra unei părți din acel proiect. Pe de altă parte, startupurile au posibilitatea să acceseze direct resursele de care au nevoie pentru dezvoltare, când au nevoie, într-un mod Avantajul Clujului în modelul Startcelercare să le scoată din blocajul frecvent al ate fundraising-ului pe modelul actual. Prin infrastructura de dezvoltare tehAtâta timp cât resursa investită este una nologică pe care o are (vorbim atât de

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

companiile de IT în sine, dar și de matricea academică care dă în fiecare an un nou val de talent), și deja prin istoria relevantă în dezvoltarea de proiecte de outsourcing, Clujul pare a fi pe un picior de avantaj în modelul pe care Startcelerate îl propune. Companiile clujene au toate premisele să folosească Startcelerate ca un intrument atât de investiții, cât și de acces la o zonă de inovație care uneori este dificil de integrat într-o companie al cărei focus este să factureze ore de dezvoltare pentru clienți. De aceea, am și decis ca lansarea publică a Startcelerate să fie făcută în Cluj, printr-un eveniment pilot de testare a modelului în ecosistemul antreprenorial local, la sfârșitul lunii mai 2014. Acest eveniment va aduce împreună companii de IT din zonă și antreprenori sau fondatori cu idei de startupuri într-o structură de pitching reciproc și apoi dezvoltare intensivă a ideilor selectate.

Tudor Bîrlea

tudor@startcelerate.com

Co-fondator @ Startcelerate

Gabriel Dombri

gabriel@startcelerate.com Co-fondator @ Startcelerate

comunități

Comunităţi IT

m încheiat luna martie cu o serie de evenimente la care TSM a fost prezent. Este vorba de Cluj Innovation Days 2014 și ...even mammoths can be Agile, la acesta din urmă fiind trecuți în secțiunea de organizatori. Luna aprilie ne aduce diverse evenimente precum prezența lui Adam Bien la Cluj, Project Tango Hackaton în Timișoara sau Product Inception în București.

Calendar

Transylvania Java User Group Comunitate dedicată tehnologiilor Java. Website: www.transylvania-jug.org Data înfiinţării: 15.05.2008 / Nr. Membri: 567 / Nr. Evenimente: 43 Comunitatea TSM Comunitate construită în jurul revistei Today Software Magazine. Website: www.facebook.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 1321/Nr. Evenimente: 18

Aprilie 10 (Cluj) Lansarea numărului 22 al Today Software Magazine www.facebook.com/todaysoftmag Aprilie 12 (Cluj) BattleLab Robotica 2014 www.facebook.com/BattleLabRobotica Aprilie 12 (Cluj) Squirrly Hackathon it-events.ro/events/squirrly-hackathon/

Romanian Testing Community Comunitate dedicata testerilor. Website: www.romaniatesting.ro Data înfiinţării: 10.05.2011 / Nr. Membri: 730 / Nr. Evenimente: 2

Aprilie 14 (Cluj) Transylvania JUG - Adam Bien transylvania-jug.org/future-meetings/ meeting-47-cu-adam-bien

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

Aprilie 14 (Cluj) Startup Lounge - „hub:raum Incubating and Accelerating Innovation” facebook.com/events/282160681951576/

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

Aprilie 24 (Cluj) Let’s meetup and discuss about project management meetup.com/PMI-Romania-Cluj-NapocaProject-Management-Meetup-Group/ events/173955922/

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

Aprilie 25 (Timișoara) 1st ever Project Tango Hackathon it-events.ro/events/1st-ever-project-tango-hackathon 1 Mai (Cluj) Unplug Cluj-Napoca facebook.com/events/145391158983499 Mai 7 (București) Android Testing and Continuous Integration it-events.ro/events/android-testing-continuous-integration/ Mai 8 (București) Product Inception it-events.ro/events/product-inception/ Mai 15-16 (Cluj) Romanian Testing Conference www.romaniatesting.ro

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

testare

Cum câştigi jocul automatizării?

Mihai Cristian

mihai.cristian@hp.com Test Automation Engineer @ HP

n ziua de azi una dintre primele întrebări care îţi sunt adresate ca inginer în testare este dacă foloseşti testarea automată. Cu siguranţă, în ultimii ani, testarea automată a fost şi rămâne un subiect la modă. Toată lumea vorbeşte despre ea, încearcă sa o folosească sau se plânge de ea. Cu toate acestea, ea rămâne eminamente un subiect intern, fiecare companie dezvoltând soluţii proprietare, croite pentru produsele și nevoile proprii. Acesta este un lucru firesc având în vedere ca produsele diferă mult, în special când vorbim de enterprise software, aşa că e greu de crezut că vom putea folosi o singură soluţie de automatizare indiferent de produsul dezvoltat. Acestea fiind spuse, după câţiva ani petrecuţi în domeniul testării automate, observând atât părţile rele cât şi cele bune, ajungi la un momentdat să te întrebi: Cum câştigi jocul automatizării? Articolul acesta încearcă să prezinte aspectele cheie ale dezvoltării şî implementării cu success a unei soluţii de automatizare . Vom prezenta un ghid pas-cu-pas bazat pe soluţia utilizată în momentul de faţă de produsul HP Server Automation numită AXIS. Deşi articolul se concentrează în mare parte pe testarea automată a planului funcţional (backend), ideile prezentate pot fi aplicate pentru orice soluţie de testare automată indiferent de tehnologia utiltizată în dezvoltarea ei.

cunoaştem în primul rând cum se joacă jocul. Consideraţi partea aceasta ca fiind manualul de instrucţiuni pentru jocul nostru. Atunci ce este o soluţie de automatizare? În viziunea noastră o soluţie de automatizare este alcătuite din trei elemente de bază: • Framework-ul, • Conţinutul, • Interfaţa cu utilizatorul.

Framework-ul

Un framework de testare automată este de obicei definit ca fiind un set de presupuneri, Soluţia de automatizare concepte și practici utilizate pentru a oferi un Să începem. Ca şi în orice alt joc în care suport pentru testarea automată a unui provrem să fim cei mai buni este important să dus software[4]. Framework-ul este baza unei

nr. 22/Aprilie | www.todaysoftmag.ro

www.todaysoftmag.ro | nr. 21/Martie, 2014

management soluţii de automatizare. Acesta se ocupă de alocarea resurselor, execuţia testelor, validarea opţiunilor selectate și gestionarea mediului de testare utilizat. Este foarte important să utilizăm un framework care se potriveşte atât cu tipul automatizării propuse cât şi cu produsul testat. Produsul nostru facilitează gestionarea de data center-e mari alcătuite din servere ce au diferite sisteme de operare, oferind toate uneltele necesare unui administrator de sistem, cum ar fi provizionarea sistemelor de operare, gestiunea pachetelor și a fişierelor de configurare precum și impunerea unor standarde de conformitate (compliance). Pentru a executa teste automate pe un asemenea produs avem nevoie de un framework ce poate gestiona un mediu de testare cu multi-platformă. Soluţia AXIS se bazează pe un framework de automatizare existent numit STAF (Software Testing Automation Framework). STAF este un framework open source dezvoltat în jurul ideii de componente reutilizabile numite servicii (cum ar fi invocarea proceselor, gestiunea resurselor, logging şi monitorizare)[5]. Folosind STAF putem să implementăm premisele necesare testelor și să verificăm validitatea operaţiilor efectuate pe toate platformele importante utilizate în ziua de azi. Acest exemplu face dovada faptului că nu trebuie mereu să începem de la zero atunci când implementăm o soluţie de testare automată. Există numeroase produse de automatizare pe piaţă pentru toate gusturile şi, chiar în cazul în care implementam soluţii proprii, acestea pot fi de ajutor. Un alt aspect cheie care trebuie luat în considerare când dezvoltăm un framework este procesul de “descoperire”. Pe scurt acest proces va traduce informaţia despre mediul de testare din limbajul produsului testat in limbajul framework-ului de automatizare. Folosind acest proces putem defini un mediu de testare, specificând ţintele testelor şi orice altă informaţie considerată necesară, într-un format convenabil aplicaţiei proprii înainte de a rula efectiv testele.

Conţinutul

Conţinutul este reprezentat de testele automate în sine. Este bine să avem o separare clară între framework şi conţinut astfel încât soluţia de automatizare să poată fi folosită pentru mai multe produse. Testele în sine pot fi dezvoltate în orice limbaj de programare ales, atât timp cât acesta este

TODAY SOFTWARE MAGAZINE suportat de framework și de produs. Crearea conţinutului necesită o bună înţelegere a produsului ce va fi testat, astfel că echipele de testare ar trebui să joace un rol important în dezvoltarea testelor automate.

Interfaţa cu utilizatorul

Framework-ul şi testele automate sunt inutile dacă nimeni nu le poate folosi. Una din cele mai întâltnite probleme în soluţiile proprietare de testare automată este că doar specialiştii în automatizare ştiu cum să ruleze testele şi cum să interpreteze rezultatele. La fel ca în cazul oricărui alt produs testat exclusiv de persoanele ce l-au dezvoltat şi îi cunosc din start punctele forte și cele slabe, această abordare va duce inevitabil la probleme de calitate. Uşurinţa de a utiliza un produs este unul din aspectele cheie ale unei soluţii automatizare. Cu cât mai mulţi oameni utilizează soluţia cu atât mai bună va fi aceasta. De aceea este foarte important să avem o interfaţă ce permite utilizatorilor să ruleze teste şi să interpreteze rezultatele acestora cu uşurinţă. AXIS foloseşte o interfaţă grafică, bazată pe un server web, ce permite utilizatorilor să selecteze testele dorite şi mediul de testare pe care să le ruleze, precum şi să vizualizeze rezultate testelor într-un format de tabel, în care pot observa rezultatul testului şi pot accesa log-urile la nivel de suită sau test pentru a indentifica posibile erori. Aceasta interfaţă este dublată de o interfaţă line de comandă cu aceeaşi funcţionalitate.

Jocul testării automate

backend, pe când altele s-ar putea să nu aibă o interfaţă grafică (GUI) pe care să o automatizaţi. Automatizarea GUI se bazează deseori pe produse de înregistrare și redare în timp ce automatizarea backend se bazează pe faptul că produsul testat are un API expus ce permite apelarea metodelor sale din testele automate. Trebuie să vă asiguraţi că abordarea aleasă se pliază pe produsul testat. Puteţi să lucraţi împreuna cu echipa de development pentru a face produsul compatibil cu tipul de automatizare ales, însă acest lucru trebuie făcut cât mai devreme în ciclul de dezvoltare al produsului. Un alt aspect de luat in considerare la nivelul 1 este care parte a procesul de testare doriţi să o automatizaţi. Doriţi să automatizaţi execuţia testelor sau validarea rezultatelor? Unele soluţii de automatizare se concentrează exclusiv pe partea de execuţie, lăsând validarea rezultatelor în sarcina testerilor, în timp ce altele acoperă ambele procese. Revenind la exemplul nostru putem vedea că AXIS este o soluţie bună pentru nivelul 1. AXIS realizează doar automatizare backend. Testele sunt scrise în Python și implementează diferite scenarii apelând metodele produsului expuse prin API, replicând astfel comportamentul unui utilizator prin diferite script-uri. Validarea rezultatelor este de asemenea automatizată, testele verificând valorile returnate de diferite metode prin compararea cu un set de valori predefinite şi prezentând rezultatul utilizatorului într-un format simplu: Passed/Failed/Skipped. Apoi utilizatorii pot să navigheze prin log-urile testelor pentru a investiga eventualele probleme. Odată ce aţi ales abordarea pentru soluţia voastră de automatizare şi aţi verificat faptul că aceasta funcţionează pentru produsul testat puteţi să treceţi la umătorul nivel.

Acum că ştim ce este jocul automatizării putem să începem să îl jucăm. Acest ghid vă va da toate informaţiile necesare pentru a construi propria soluţie de automatizare. Este foarte important să nu săriţi peste nivele pentru că, cel mai probabil, veţi fi nevoiţi să vă întoarceţi la ele pentru a le parcurge la un moment dat. Să înceapă Nivelul 2: Povestea din spatele jocului jocul!!! Să intrăm în lumea jocului! Orice joc care merită jucat are şi o poveste în spate. Nivelul 1: Caracterul vostru Dacă vrem să înţelegem contextul în care Să începem cu începutul. În primul au loc aventurile eroului nostru, merită rând trebuie să alegeţi ce fel de jucător veţi să cunoaştem povestea înainte de a începe fi. Doriţi să mergeţi spre automatizarea să atacăm tot ce mişcă. interfeţei grafice sau veţi alege automaCum realizăm acest lucru? Simplu, tretizarea backend? Poate amândouă. Orice buie doar să revizuim procesul de testare alegere faceţi este important să definiţi existent. Treceţi în revistă testele manuale abordarea de la bun început. existente pentru a vă asigura că acestea sunt Cel mai important aspect la acest nivel scrise într-o manieră ce permite automatieste cunoaşterea produsului. Unele pro- zarea lor. Colaboraţi cu echipa de testare duse nu sunt compatibile cu automatizarea pentru a alcătui o listă cu testele ce trebuie www.todaysoftmag.ro | nr. 22/Aprilie, 2014

testare Cum câştigi jocul automatizării? automatizate. Cele mai la îndemână exemple sunt suitele de regresie, suitele de teste smoke sau testele instalare a produsului. Identificaţi testele cheie care, în cazul în care nu trec, vor produce defecte cu prioritate mare. De asemenea, definiţi din start noţiunea de Pass și Fail pentru teste cu scopul de a evita orice confuzii ulterioare. O altă operațiune ce trebuie aplicată la acest nivel este stabilirea unei legături clare între testele manuale şi cele automate. Această legătură vă va ajuta să determinaţi gradul de acoperire al testelor. Poate că acest nivel nu pare foarte distractiv dar, dacă faceţi acest efort acum, înainte de a începe efectiv să automatizaţi, veţi vedea că rezultatele muncii voastre vor fi vizibile mult mai devreme. AXIS foloseşte anumite fișiere text ataşate fiecărui test ce conţin informaţia ce leagă testul automat de cel manual, sub forma unui număr de identificare. Acestea sunt folosite în procesul de raportare a rezultatelor testelor automate către sistemul de monitorizare utilizat de management. Consideraţi această parte ca o tabelă de scor a jocului. Cu siguranţă veţi dori ca lumea să ştie la ce nivel se află eroul vostru şi ce misiuni a îndeplint. Odată ce aveţi lista de teste ce trebuie automatizate, condiţiile de Pass/Fail şi testele scrise într-un format agreat de echipa de automatizare puteţi să avansaţi la următorul nivel.

Nivelul 3: Alegerea clasei eroului

În momentul de faţă ştim deja cum se joacă jocul şi care este povestea din spatele lui. E momentul să alegeţi clasa caracterului vostru. Alegerea clasei potrivite pentru abordarea decisă va face eroul vostru mult mai eficient. Vreţi să alegeţi calea luptătorului, a magului sau cea a arcaşului? Fiecare alternativă are punctele ei forte dar şi slăbiciunile ei şi va influenţa fundamental modul în care veţi juca jocul. În acest nivel trebuie să definiţi ce doriţi să facă soluţia de automatizare propusă şi cum vreţi să realizaţi acest lucru. Va trebui să definiţi cerinţe care vor reprezenta scopurile soluţiei. În acest fel veţi avea un standard clar pentru contorizarea progresului şi veţi şti momentul în care soluţia propusă este gata de a fi folosită. Să presupunem că vreţi să automatizaţi testele de regresie pentru un produs. Datorită faptului că aţi parcurs deja nivelele 1 şi 2, ar trebui să aveţi definită o listă de teste ce acoperă toate aspectele produsului ce trebuie verificate. Veţi şti de asemenea care sunt condiţiile de Pass/Fail pentru

teste şi sunteţi sigur că testele sunt scrise într-un format ce facilitează automatizarea lor. E momentul să creaţi User Stories pentru efortul de automatizare. Fiecare user story trebuie estimat şi trebuie să conţină condiţii clare ce determină momentul când este considerat încheiat. Este important să faceţi progresul efortului de automatizare cât mai vizibil astfel încât celealte echipe vor şti când testele automate devin disponibile şi ce funcţionalitate acoperă. Una dintre greşelile des întâlnite la acest nivel este să încercaţi să faceţi prea multe. Există de obicei o presiune de a automatiza cât mai multe teste. Acest tip de automatizare nu este util pentru nimeni. Prin definirea clară a cerinţelor veţi şti exact cât trebuie să automatizaţi şi când puteţi considera că o anumită componentă este acoperită de testele automate. Utilizaţi acest proces pentru toate obiectivele de automatizare propuse: regression, validare de build-uri, teste de instalare. Odată ce aveţi definite cerinţele pentru toate sarcinile de automatizare, puteţi trece la nivelul 4.

Nivelul 4: “Măcinarea”

Am petrecut destul timp studiind povestea din spatele jocului şi creând caracterul nostru. E momentul să începem jocul. Orice gamer știe că înainte să ajungi să ai un erou cu adevărat puternic e necesar sa “macini” întâi. Acest lucru presupune îndeplinirea unor misiuni mai uşoare la început pentru a creşte abilităţile eroului, a-i îmbunătăţi echipamentul şi a creşte în experienţă. În orice joc, într-o primă etapă eroul este implicat înr-o serie de misiuni facile până să ajungă la adversarii cu adevărat puternici. Din păcate nu există nici o scurtătură la nivelul 4. Însă, trecând de nivelul 3 veţi avea la dispoziţie un set clar de cerinţe sau misiuni, pe care trebuie să le îndepliniţi. O idee bună este să începeţi cu testele de “smoke”. Acestea sunt teste de bază care, teoretic, ar trebui să fie mai uşor de automatizat, şi care pot fi apoi folosite pentru a determina dacă un build este valid sau nu înainte de a intra pe mâna echipei de testare. O altă opţiune bună este automatizarea testelor de instalare a produsului. Odată ce aveţi un set de teste smoke automatizate precum şi posibilitate de a instala produsul folosind teste automate puteţi implementa un proces de Continous Integration. Principalul obiectiv la acest nivel este să vă faceţi utili celorlate echipe cât mai repede. Un sfat pentru acest nivel este să

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

încercaţi jocul multiplayer, deoarece câștigi mai multă experiență, când te afli într-un grup. Colaboraţi cu echipele de testare pentru a vă asigura că testele sunt rulate şi acoperă toate aspectele definite în cerinţe. Ei sunt singurii care pot decide când misiunile voastre sunt îndeplinite. Reţineţi că în calitate de inginer de automatizare, scopul vostru este să implementaţi şi să oferiţi suport pentru soluţia de automatizare, nu să rulaţi teste pentru alte echipe şi să investigaţi rezultatele lor. Odată ce aţi îndeplinit misiunile definite şi coechipierii confirmă acest lucru, puteţi avansa la următorul nivel.

Nivelul 5: Echipamentul este tot!

Trecând prin nivelul 4 aveţi deja experienţă în jocul automatizării. Aţi îndeplinit o serie de misiuni şi începeţi să realizaţi cât de important e să ai un echipament bun. Pentru ca eroul vostru să fie cu adevărat puternic el trebuie să aibă echipamentul potrivit şi să îl menţină în stare bună. În acest nivel vom învăţa de asemenea că este bine să avem diferite rânduri de echipament pentru diferite misiuni. Dar care este echipamentul eroului în acest joc? Singurele arme pe care le aveţi la dispoziţie sunt testele în sine. În continuare vom prezenta câteva atribute care ar trebui luate în seamă pentru testele automate: • Capacitatea de a fi reviziuite: Testele trebuie să fie uşor de înţeles şi revizuit. E important ca ele să fie bine documentate, iar log-urile trebuie să conţină toată informaţia necesară pentru a ca utilizatorul să determine motivul pentru care testul a căzut. Doar pentru că un test trece de fiecare dată, nu înseamnă că este un test bun. Există o posibilitate ca el să nu funcţioneze corect. Utilizatorul trebuie să poată identifica astfel de probleme. Dacă funcţionalitatea testată se schimbă, testele automate trebuie să fie uşor de revizuit şi modificat. • Acurateţe: Atunci când un test trece, sau pică, trebuie ca utilizatorul să fie sigur că rezultatul obţinut este unul corect. Orice test trebuie să aibă interfeţe pentru implementarea premiselor scenariului şi pentru a readuce sistemul la starea iniţială după rularea testului. Atunci când automatizaţi scenarii complexe, adăugaţi condiţii speciale pentru a vă asigura că o eroare apărută în metodele ce implementează premisele testului nu va face ca testul să fie picat, ci mai degrabă sărit. Obiectivul testării automate este de a oferi o imagine asupra stării curente a

TODAY SOFTWARE MAGAZINE produsului nu de a avea suite de teste ce trec tot timpul. • Consistenţă: De fiecare dată când sunt executate, testele trebuie să aibă acelaşi comportament. Interfeţele pre şi post execuţie implementate trebuie să asigure această consistenţă la fiecare rulare a testelor. • Independenţă: Utilizatorii vor dori să aibă opţiunea de a executa fie un singur test (pentru a verifica un defect anume), o suită întreagă (pentru a determina starea unei anumite componente) sau un grup de suite (pentru a determina starea produsului). Oferiţi utilizatorilor cât mai multe opţiuni pentru a vă asigura că testele sunt folosite la potenţial maxim. • Reutilizare: Pentru a evita duplicarea codului şi pentru a face mai ușor procesul de dezvoltare al testelor noi, puteţi crea anumite utilitare. Extragerea funcţionalităţii comune şi gruparea în clase de utilitare ce pot fi apoi importate în teste, va facilita dezvoltarea testelor noi precum şi investigarea unor posibile erori. Clasele de utilitare trebuie să fie bine documentate (parametri primiţi, valori returnate) pentru a putea fi folosite cu uşurinţă. O idee bună este să folosiţi un sistem de versionare a codului pentru testele automate, la fel ca şi pentru produsul testat. Dacă produsul testat are mai multe versiuni lansate e bine să aveţi câte o versiune a testelor pentru fiecare versiune a produsului. Anumite funcţionalităţi ale produsului pot fi modificate în diferite versiuni astfel că un singur test s-ar putea să nu fie suficient. Acum că avem un echipament competitiv e momentul să ne construim o reputaţie in nivelul 6.

Nivelul 6: Făurirea

Sigur, e distractiv să vă folosiţi armele în care aţi investit timp şi efort în nivelul 5 pentru a îndeplini misiuni, dar pentru a avansa în jocul automatizării e necesar să împărţiţi echipamentul cu alţi jucători. Făurirea de echipament vă va ajuta să vă construiţî o reputaţie, iar dacă vă faceţi prieteni puternici veţi progresa mult mai rapid în joc. Ideea de bază la nivelul 6 este să fiţi darnici. Testele automate trebuie să fie disponibile tuturor utilizatorilor. Grupaţi testele în pachete ce pot fi utilizate de pe orice platormă. După cum am spus şi la nivelul 5 versionarea codului este o idee

bună. Utilizaţi sistemul de versionare implementat pentru produs şi pentru testele automate. Astfel veţi avea un pachet nou de teste la fiecare build nou al produsului. Acest lucru vă va permite să vă modificaţi testele rapid, în concordanţă cu schimbările din produs. Nu uitaţi că automatizarea este utilă doar dacă este folosită. La acest nivel cheia este să oferiţi un acces cât mai facil la testele automate indiferent de versiunea testată. Acum că ne-am îndeplinit misiunile propuse, avem cel mai bun echipament, am făurit arme şi pentru coechipieri ce mai rămâne de facut?

pregătiţi din timp, depuneţi efortul necesar la toate nivelele şi nu trişaţi, la final veţi ieşi învingători. Aşadar, haideţi să câştigăm jocul automatizării.

Bibliografie 1. 2. 3. 4. 5.

Test Automation Architecture: Planning for Test Automation – Douglas Hoffman, 1999 Test Automation Frameworks – Carl J. Neagle, 2000 Common Mistakes in Test Automation – Mark Fewster, 2001 Wikipedia, The Free Encyclopedia Software Testing Automation Framework (STAF) - http://staf.sourceforge.net/

Nivelul 7: Conducătorul de breaslă

Acesta este ultimul nivel al jocului nostru. Acum sunteţi cu adevărat un conducător de breaslă. Jucătorii de nivel mai mic vă caută pentru a cere asistenţă, echipament şi sfaturi. Dar se termină jocul automatizării aici? Doar pentru că acum sunteţi numărului unu,nu înseamnă că veţi rămâne la acest nivel mereu. Natura jocului automatizării este mereu schimbătoare. Trebuie să fiţi tot timpul în gardă dacă nu vreţi să regresaţi la nivelele anterioare. Căutaţi mereu să îmbunătăţiţi soluţia de automatizare implementată. Menţineţi suitele de teste într-o stare bună. Adăugaţi teste noi, revizuiţi testele vechi pentru a vă asigura ca sunt la curent cu schimbările din produs şi eliminaţi testele care nu mai sunt utile. Lucraţi la framework-ul de automatizare pentru a-i imbunătăţi perferomanţele şi fiabilitatea. Împărtăşiţi cunoştinţele acumulate. Organizaţi şedinţe pentru a ţine la curent echipele de testare referitor la starea soluţiei de automatizare. Comunicaţi clar modificările ce ar putea avea impact în procesul de testare. O soluţie bine gândită şi bine implementată va permite echipelor de testare să îşi dezvolte singure testele eliberând din timpul vostru, timp ce poate fi folosit pentru îmbunătăţiri. Oferiţi suport pentru echipele ce utilizează testele automate. Modificările din produs vor produce mereu noi sarcini pentru echipa de automatizare. Comunicaţi cu managerii de produs pentru a afla din timp de modificările ce vă vor afecta şi pentru a vă asigura că automatizarea este luată în calcul in procesul de dezvoltare a noilor funcţionalităţi. Urmând paşii din acest ghid veţi putea să implementaţi o soluţie de automatizare ce poate fi utilizată eficient şi produce rezultate utile şi vizibile. În cele din urmă, ca în orice alt joc, dacă studiaţi regulile, vă www.todaysoftmag.ro | nr. 22/Aprilie, 2014

programare

management

iOS image caching. Libraries benchmark

n ultimii ani, tendința aplicațiilor iOS se îndreaptă spre un design cât mai interactiv și plăcut ochiului. Deoarece prezentarea imaginilor este un element cheie în tot acest proces, majoritatea aplicațiilor folosesc imagini care trebuie downloadate și afișate. Foarte mulți developeri au fost puși la un moment dat în situația de a-și popula controalele UI cu diferite imagini. Descărcarea de astfel de imagini consumă destul de multe resurse, cum ar fi date din serviciul de internet mobil, baterie, CPU. Prin urmare, din nevoia de a minimiza consumul acestor resurse, s-a dezvoltat așa numitul pattern cache. Bogdan Poplauschi

bogdan.poplauschi@yardi.com Senior iOS Developer @ Yardi Romania

2. Abordarea Clasică

• se downloadează imaginile în mod asincron. • se procesează imaginile pentru a fi afișate (modificarea dimensiunii, îndepărtarea efectului de ochi roșii, îndepărtarea marginilor etc.). • se stochează imaginile pe flash drive (unitatea internă de stocare). • se citesc de pe flash drive și se afișează la cerere.

// assuming we have an NSURL *imageUrl and UIImageView *imageView, we need to load the image from the URL and display it in the imageView if ([self hasImageDataForURL:imageUrl] { NSData *data = [self imageDataForUrl:imageUrl]; UIImage *image = [UIImage imageWithData:imageData]; dispatch_async(dispatch_get_main_ queue(), ^{ imageView.image = image; }); } else { [self downloadImageFromURL:imageUrl withCompletion:^(NSData *imageData, …) { [self storeImageData:imageData …]; UIImage *image = [UIImage imageWithData:imageData]; dispatch_async(dispatch_get_ main_queue(), ^{ imageView.image = image; }); }]; }

Pentru a dobândi un user experience cât mai bun, este foarte important să înțelegem ce se întâmplă în interiorul sistemului iOS, atunci când stocăm imagini în cache sau le încărcăm. În plus, consider că un set de benchmarks pentru bibliotecile open-source de image Matematica FPS caching poate fi foarte util în alegerea soluției - 60 FPS este idealul pentru orice actualpotrivite. izare de UI, pentru a asigura o experiență fără cusur.

nr. 22/Aprilie | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE - 60 FPS => 16.7 ms/cadru. Acest lucru înseamnă că, dacă 4. O soluție robustă de caching a imaginilor în iOS ar trebui oricare dintre operațiunile de pe main queue durează mai mult de să: 16.7 ms, FPS-ul la scroll scade vizibil (efect de sacadare) deoarece • descarce imagini în mod asincron, astfel încât main queue să CPU se va ocupa de alte operații, și nu de actualizarea UI. fie folosit cât mai puțin posibil, • decomprime imaginile pe un background queue. Acest lucru 3. Dezavantajele abordării clasice nu e deloc simplu. Pentru mai multe detalii, accesați http:// Încărcarea imaginilor sau a fișierelor în general, de pe flash www.cocoanetics.com/2011/10/avoiding-image-decompresdrive, e o operație costisitoare (accesarea flash drive-urilor este sion-sickness/ . mult mai lentă decât cea a memoriei RAM). • stocheze imaginea atât în cache-ul din memorie, cât și în cel Crearea unei instanțe Ullmage va avea ca rezultat o verside pe flash drive. Procesul de caching pe flash drive este imporune comprimată a imaginii, mapată pe o secțiune de memorie tant deoarece aplicația ar putea fi închisă sau ar putea fi nevoită (mapped memory). Imaginea comprimată este mică și nu poate să elibereze memorie din cauza resurselor limitate. În acest caz, fi afișată direct. În cazul încărcării de pe flash drive, imaginea este re-încărcarea imaginilor de pe flash drive este mult mai rapidă doar mapată, urmând ca încărcarea în memorie să se facă la cerdecât descărcarea lor. ere. Decomprimarea unei imagini este de asemenea costisitoare. Atribuirea proprietății “image” din imageView în acest caz Notă: dacă folosiți NSCache pentru memoria cache, această va crea un CATransaction care va fi înregistrat în run loop. La clasă va elibera toate resursele referențiate, în caz de memory următoarea iterație, executarea CATransaction-ului implică (în warning. Pentru mai multe detalii despre NSCache, accesați http:// funcție de imagine), crearea unor copii ale tuturor imaginilor care nshipster.com/nscache/ . au fost setate ca layer contents. Copierea de imagini include: • stocheze imaginea decomprimată pe flash drive și în • alocarea de buffere pentru scriere/citire de fișiere și memorie pentru a evita repetarea procesului de decomprimare. decomprimare, • folosească GCD și block-uri. Acestea fac codul mai perfor• citirea datelor de pe flash drive în memorie, mant, mai ușor de citit și de scris. În prezent, GCD și block-urile • decomprimarea de imagini (rezultă un raw bitmap) – sunt indispensabile pentru operațiile asincrone. implică un consum ridicat de CPU, • bonus 1: categoria peste UllmageView pentru a face inte• imaginile nealiniate corect pe biți sunt copiate de către grarea ușoară. CoreAnimation pentru a fi corectate și redate corespunzător. • bonus 2: capacitatea de a procesa imaginile după descărcare Acest lucru nu este menționat în Apple docs, dar folosirea și înainte de a le stoca în cache. Instruments arată apeluri CA::Render::copy_image chiar și atunci când instrumentul CoreAnimation nu indică nicio imag- Folosirea avansată a imaginilor pe iOS ine copiată. Pentru a afla mai multe despre folosirea de imagini pe iOS, • începând cu iOS 7, decodorul hardware JPEG mai este acce- despre cum funcționează framework-urile din cadrul iOS SDK sibil doar aplicațiilor sistem. Aceasta înseamnă că aplicațiile (CoreGraphics, Image IO, CoreAnimation, CoreImage), CPU vs. noastre se bazează pe un decodor software care este mult GPU și altele, citiți acest articol bun3, scris de @rsebbe. mai încet. Acest aspect a fost documentat de către echipa FastImageCache pe pagina lor Github,1 dar și de Nick Lockwood Este Core Data un candidat valid? într-un post pe Twitter2. Aici4 aveți un benchmark pentru caching de imagini folosind Core Data versus File System. Rezultatele recomandă File System (după cum ne așteptam). 1 github.com/path/FastImageCache#the-problem 2 twitter.com/nicklockwood/status/401128101049942016

3 www.slideshare.net/rsebbe/2014-cocoaheads-advimaging 4 biasedbit.com/filesystem-vs-coredata-image-cache/

Objective C

jobs-cluj@yardi.com Yardi Romania

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

programare iOS image caching. Libraries benchmark Rezultatele

Rezultatele complete pot fi găsite pe pagina proiectului Github. Deoarece acele tabele sunt foarte mari, am decis să creez diagrame folosind date de la cel mai rapid (iPhone 5s) și cel mai lent device (iPhone 4).

Rezultate pentru iPhone 5s

Notă: Prin disk înțelegem flash drive (dispozitivul de stocare internă).

5. Benchmarks

Doar uitându-ne la conceptele de mai sus înțelegem că e destul de greu să scrii o asemenea componentă de unul singur; mai mult, va lua mult timp și va fi extrem de dificil. Tocmai de aceea apelăm la soluții open source. Majoritatea dintre voi ați auzit de SDWebImage sau FastImageCache. Pentru a decide care vi se potrivește mai bine, le-am comparat și am analizat felul în care răspund cerințelor noastre.

Bibliotecile testate

• SDWebImage • FastImageCache • AFNetworking • TMCache • Haneke

Notă: AFNetworking a fost adăugat comparației pentru că, începând cu iOS7, oferă și un cache de tip flash drive (NSURLCache).

Scenariul

Rezultate pentru iPhone 4

Legendă

• async download = biblioteca oferă suport pentru descărcare asincronă. • backgr decompr = decomprimarea imaginilor se face pe un background queue/thread. • store decompr = imaginile sunt stocate in varianta decomprimată. • memory/flash drive cache = suport pentru cache pe flash drive sau în memorie. • UIImageView categ = biblioteca include o categorie peste UIImageView. • from memory/flash drive = au obținut cele mai bune rezultate la timpii de încărcare din cache (memorie sau flash drive).

Pentru fiecare bibliotecă am realizat o instalare de la zero a aplicației de benchmark, apoi am pornit aplicația, scroll încet, până ce imaginile s-au încărcat, apoi scroll repede / încet alternativ. Am 6. Concluzii închis apoi aplicația pentru a forța încărcarea de pe flash drive Elaborarea unei componente de caching de imagini pentru (când aceasta era disponibilă), apoi am rulat din nou același sce- iOS este dificilă. nariu de scroll. SDWebImage și AFNetworking sunt proiecte serioase, cu mulți contribuitori și care sunt întreținute în mod corect. Aplicația benchmark – proiect FastImageCache se îndreaptă spre același statut destul de repede. Sursa proiectului demo poate fi găsită pe Github sub denu- Dacă analizăm informațiile oferite mai sus, cred că putem fi de mirea de ImageCachingBenchmark5, împreună cu diagramele, accord că SDWebImage este cea mai bună soluție la momentabelele cu date și altele. Sursele proiectului de pe Github au tre- tul actual, chiar dacă pentru unele proiecte AFNetworking sau buit modificate, la fel ca cele ale bibliotecilor, adăugându-se tipul FastImageCache s-ar potrivi mai bine. Totul depinde de cerințele cache-ului din care s-a făcut încărcarea. Nedorind să includ în proiectului în cauză. repository și sursele Cocoapods (acest lucru nu este recomandat) și pentru că proiectul trebuia să fie compilabil după instalarea clean Link-uri utile a Cocoapods, varianta de proiect din Github este ușor diferită de https://github.com/rs/SDWebImage cea cu care s-au efectuat măsurătorile. https://github.com/path/FastImageCache Dacă unii dintre voi doresc să ruleze din nou benchmark- https://github.com/AFNetworking/AFNetworking urile, va trebui să creați un completionBlock pentru încărcarea https://github.com/tumblr/TMCache imaginilor pentru toate bibliotecile, similar celui default din https://github.com/hpique/Haneke SDWebImage, care returnează tipul SDImage CacheType. http://bpoplauschi.wordpress.com/2014/03/21/

5 github.com/bpoplauschi/ImageCachingBenchmark

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

ios-image-caching-sdwebimagevs-fastimage/ https://github.com/bpoplauschi/ImageCachingBenchmark

management

programare

THE WEB’S SCAFFOLDING TOOL FOR MODERN WEBAPPS – Yeoman

nițierea unui proiect poate fi de cele mai multe ori plictisitoare când deja nu mai e o provocare. Atunci când începe un proiect nou, pentru a îmbunătăți productivitatea și plăcerea de a lucra, Yeoman are la bază trei tool-uri:

Răzvan Ciriclia

razvan.ciriclia@betfair.com software engineer @ Betfair

LESS or SASS - fiecare dintre noi poate Ajută la crearea structurii de fişiere şi alege ori unul, ori celălalt - Grunt le ştie pe defineste deja configurări generale pentru amândouă. Grunt şi Bower. Puţin cam rapidă introducerea despre Grunt - dar o parte din calitățile unui “task Grunt runner” nu puteau fi prezentate decât scurt • Nu ţi s-ar părea interesant să știi dacă şi la obiect. CSS-ul este valid și aşa va rămâne într-o vineri seara când tocmai te pregăteşti să Bower pleci de la serviciu şi pe diagonală citești Economiseşte din timp, download-ând “not working” într-un mail de la șeful / cli- librăriile necesare noului proiect precum şi entul tău? dependinţele acestuia. • Ţi-ai dori ca CSS-ul, JS-ul HTML-ul să Utilizarea, instalarea și funcționarea fie deja optimizat înainte cu cel puțin o zi corectă YEO este condiționată de instalarea de a ajunge în producţie? în prealabil a Node.JS și Git. De asemenea, • Ai testat codul tău fără să-ţi aduci generator-webapp trebuie instalat via npm aminte să verifici load time-ul? Cu dev (npm install -g generator-webapp). environmentul legat la aceeaşi reţea? Ai uitat că România întrece SUA, Germania, Instalare YEOMAN Norvegia, Japonia şi multe alte ţări dezvolYEOMAN va fi instalat asemnenea genetate în topuri internaţionale privind viteza rator-webapp folosind npm de conectare la Internet? Grunt te va ajuta npm install -g yo să-ţi optimizezi dimensiunea imaginilor fără să afecteze calitatea acestora! PROJECT STARTUP • Îţi place să-ţi structurezi munca pe Odată YEOMAN şi dependinţele acesmodule; iar fiecare să aibă propriile fişiere tuia instalate, putem da start noului proiect. CSS sau JS? Îţi place să vezi fişiere mai mari Pentru aceasta trebuie să navigaţi în folder-ul de 100 de linii doar în producţie, unde (unul nou creat sau fără alte directoare sau este necesar să ai cât mai puţine resurse fişiere în el) unde doriţi să dezvoltaţi noul încărcate?Grunt poate face asta pentru tine proiect şi lansaţi din linia de comandă: compactând CSS sau minificând JS. yo webapp

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

programare THE WEB’S SCAFFOLDING TOOL FOR MODERN WEBAPPS – Yeoman În acest moment jQuery, Gruntfile.js şi HTML5 Boilerplate sunt instalate automat, iar pe lângă acestea, mai aveți la dispoziţie să includeţi în aplicaţia abia începută, framework-uri precum: Bootstrap, Sass sau Modernizr. Timpul total de aşteptare pentru a putea avea acces la cod şi a începe editarea cu specificaţiile proiectului este de aproximativ două minute.

yo angular:directive sampleDirective

node_models sunt adăugate în .gitignore, înainte de rularea acestei comenzi vor treCreează sampleDirective.js, varianta bui rulate: iniţială a unei directive în app/scripts/ npm install directives bower update Creează sampleDirective.js, varianta testului unei directive în test/specs/ grunt build directives Creează folderul cu fișierele pentru producție. În acest pas Grunt rulează taskyo angular:filter boldRed urile definite în Gruntfile.js, fișier aflat în Caz concret Creează boldRed.js, varianta iniţială a rădăcina proiectului. unui filtru în app/scripts/directives Un exemplu de aplicație realizată cu npm install -g generator-angular Creează boldRed.js, varianta testului Yeoman poate fi descarcată de aici https:// Instalează generatorul pentru aplicaţiile unui filtru în test/specs/directives github.com/razvancg/yeomanDemo bazate pe AngularJs yo angular:app imdbApp

yo angular:service getepisode

Concluzii

Creează getepisode.js, varianta iniţială Pentru cineva care nu a mai lucrat cu un Creează structura de bază pentru apli- a unui service în app/scripts/services generator de cod este posibil să fie mai greu caţia curentă “imdbApp” Creează getepisode.js, varianta a testu- să se obişnuiască cu YEOMAN. Opţiunea lui unui service în test/specs/services de a nu mai căuta ultimele versiuni ale unor yo angular:route movies framework-uri de care ai nevoie în proiect, Creează un nou path în aplicaţie, un yo angular:factory getseasons de a le download-a, dezarhiva şi copia în view şi controller-ul asociat. Rezultatul Creează getseasons.js, varianta iniţială locaţia proiectului, pe lângă crearea autoacestei comenzi este: a unui factory în app/scripts/services mată a structurii de fişiere şi task-urile pe Creează movies.js, varianta iniţială a Creează getseasons.js, varianta a testu- care le putem seta pentru Grunt, pot spune unui controller în app/scripts/controllers lui unui factory în test/specs/services ca YEOMAN este “ce nu am avut până Creează movies.js, varianta iniţială a acum”! yo angular:provider getmovies unui test în test/specs/controllers Creează movies.html - template în app/ Creează getmovies.js, varianta iniţială a views unui filtru în app/scripts/services Adaugă path-ul movies în modulul de Creează getmovies.js, varianta a testubază app/scripts/app.js lui unui filtru în test/specs/services Generează automat codul pentru a yo angular:view seasons include movies.js în index.html Creează un view în app/views. yo angular:controller movie Pentru rularea proiectului, din rădăcina Creează movie.js, varianta iniţială a proiectului se rulează: unui controller în app/scripts/controllers grunt serve Creează movie.js, varianta iniţială a unui test iîn test/specs/controllers În cazul în care proiectul a fost clonat din Git, datorită faptului ca fișierele din

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

programare

OpenXML - Noţiuni introductive

n acest articol, încercăm să trasăm o hartă de bază pentru a manipula programatic fişiere xlsx folosind librăria Office Xml. Multe aplicaţii necesită lucrul cu fişierele excel, fie pentru citirea şi importarea datelor din el, fie pentru exportarea datelor într-un raport, astfel că este important să cunoaştem cum să manipulăm programatic fişierele excel.

Florentina Suciu

florentina.suciu@fortech.ro Software engineer @ Fortech

Începând cu anul 2007, fişierele Excel şi-au schimbat complet structura lor internă. Xls a fost un format de fişier binar proprietar, în timp ce xlsx este un format bazat pe Xml, numit Office Open Xml (OOXML).

Excel ca fişier zip

Gabriel Enache

gabriel.enache@fortech.ro Software engineer @ Fortech

Un fişier xlsx este un pachet zip care conţine un fişier xml pentru fiecare parte majoră a unui fişier Excel (foi, stiluri, diagrame, tabele pivot). Dacă doriţi să verificaţi conţinutul unui xlsx, tot ce trebuie să faceţi este să schimbaţi extensia fişierului din xlsx în zip şi apoi să-l dezarhivaţi.

Componente ale fişierelor Excel

cinci elemente, Workbook, WorksheetPart, Worksheet, Sheet, SheetData. Sarcina principală a unui WorkbookPart este de a ţine evidenţa foilor de lucru, setărilor globale şi a componentelor partajate ale registrului de lucru (Workbook). Documentul trebuie să conţină cel puţin o foaie de lucru (Worksheet) care este definită în interiorul unui WorksheetPart. O foaie de lucru are trei secţiuni principale: • Foaia (Sheet), declarată în registrul de lucru (Workbook), conţine proprietăţile. De exemplu: nume, un id utilizat pentru sortarea foilor şi un id de relaţie, id care o conectează la WorksheetPart; • SheetData care conţine datele efective;

Un d o c u m e nt E xc e l c onţ i n e u n WorkbookPart central şi părţi separate O parte pentru suportarea caracteristicipentru fiecare foaie de lucru. Pentru a lor cum ar fi protecţia şi filtrarea. crea un document valid, trebuie să uniţi

Figura 1 - Elemente ale unui fişier Excel zip

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

programare OpenXML - Noţiuni introductive // save the worksheet worksheetPart.Worksheet.Save(); // create the sheet properties var sheetsCount = document.WorkbookPart.Workbook. Sheets.Count() + 100; {

document.WorkbookPart.Workbook.Sheets. AppendChild(new Sheet()

Id = document.WorkbookPart. GetIdOfPart(worksheetPart),

Figura 2 – Componente ale unui document Excel

Librăria OpenXml

SheetId = (uint)document.WorkbookPart.Workbook. Sheets.Count() + 1, Name = „MyFirstSheet” }); // save the workbook document.WorkbookPart.Workbook.Save(); }

Crearea unui tabel pivot (Pivot Table)

Un tabel pivot este un tabel folosit pentru sumarizarea datelor, Toate clasele necesare pentru a manipula un fişier xlsx pot fi care poate sorta, calcula sau aplica media automat la datele stocate găsite în Open Xml SDK. Mai jos este un exemplu simplu de apli- într-un tabel de date. Un tabel pivot are nevoie de un tabel de date care a unei sume la o coloană de date. sursă. Vom presupune că avem deja tabelul de date, într-o foaie numită “DataSheet”. using (SpreadsheetDocument document = Un tabel pivot are patru părţi principale: WorksheetPart, SpreadsheetDocument.Create(path, SpreadsheetDocumentType.Workbook)) P i v o t Ta b l e Pa r t , P i v o t Ta b l e C a c h e D e f i n i t i o n Pa r t ş i { PivotCacheRecordsPart. De asemenea, trebuie să instanţiem o var workbookPart = document. AddNewPart<WorkbookPart>(); listă de PivotCaches, cu un PivotCache descendent. În imaginile următoare, puteţi vedea “harta” unui tabel pivot. workbookPart.Workbook = new Workbook(); var worksheetPart = document. AddNewPart<WorkbookPart>();

// create sheet data var sheetData = worksheetPart.Worksheet. AppendChild(new SheetData()); // create a row and add a data to it sheetData.AppendChild(new Row(new Cell() { CellValue = new CellValue(„5”), DataType = CellValues.Number })); sheetData.AppendChild(new Row(new Cell() { CellValue = new CellValue(„3”), DataType = CellValues.Number })); sheetData.AppendChild(new Row(new Cell() { CellValue = new CellValue(„65”), DataType = CellValues.Number })); sheetData.AppendChild(new Row(new Cell() { CellFormula = new CellFormula(„=SUM(A1:A3)”), DataType = CellValues.Number }));

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

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

Figura 4 – Componente necesare pentru a crea un tabel pivot

var pivotWorksheetPart = document.WorkbookPart. AddNewPart<WorksheetPart>(); pivotWorksheetPart.Worksheet = new Worksheet(); var pivotTablePart = pivotWorksheetPart. AddNewPart<PivotTablePart>();

TODAY SOFTWARE MAGAZINE var pivotTableCacheDefinitionPart = pivotTablePart. AddNewPart<PivotTableCacheDefinitionPart>(); document.WorkbookPart.AddPart( pivotTableCacheDefinitionPart); var pivotTableCacheRecordsPart = pivotTableCacheDefinitionPart. AddNewPart<PivotTableCacheRecordsPart>(); var pivotCaches = new PivotCaches(); pivotCaches.AppendChild(new PivotCache() { CacheId = pivotCacheId, Id = document.WorkbookPart. GetIdOfPart(pivotTableCacheDefinitionPart) }); document.WorkbookPart.Workbook. AppendChild(pivotCaches);

PivotTablePart descrie layout-ul. Descendentul său, PivotTableDefinition, stochează locaţia tabelului şi PivotFields. Sunt două tipuri de PivotFields (câmpuri pivot): RowFields şi DataFields. • RowFields sunt date statice şi PivotField-ul lor corespunzător are proprietatea Axă (Axis) setată pe “AxisRow”; • DataFields sunt date calculate (de exemplu totaluri) şi PivotField-ul lor corespunzător are proprietatea DataField setată pe true. Definiția tabelului pivot trebuie să cunoască id-ul PivotCacheului pe care l-am definit mai sus. În definiţia tabelului pivot puteţi specifica formatul în care doriţi să afişaţi tabelul. Acestea pot fi: Compact (setaţi flag-ul compact pe true), Outline (setaţi flag-ul Outline pe true), sau formatul Tabular (tabelar) (setaţi flag-ul GridDropZones pe true). PivotTableC acheDefinitionPar t c u des cendentu l PivotCacheDefinition, defineşte câmpurile cache (cache fields). Este necesar să declarăm un cache field pentru fiecare coloană din tabel. De asemenea, acesta conţine tipul de sursă cache (cache source type) (ca SourceValues.Worksheet) şi sursa foii de lucru (worksheet source). PivotCacheRecordsPart trebuie doar să fie definit şi anexat, această parte fiind populată automat cu valorile cache ale tabelului.

În pasul următor, trebuie să definiţi regulile cu ajutorul obiectului ConditionalFormatting care are ca descendent un obiect ConditionalFormattingRule. Mai jos puteţi vedea un exemplu în care aplicăm o formatare condiţionată pentru celulele care au o valoare mai mică de 3. var pivotWorksheetPart = document.WorkbookPart.AddNewPart<WorksheetPart>(); pivotWorksheetPart.Worksheet = new Worksheet(); var pivotTablePart = pivotWorksheetPart. AddNewPart<PivotTablePart>(); var pivotTableCacheDefinitionPart = pivotTablePart. AddNewPart<PivotTableCacheDefinitionPart>(); document.WorkbookPart. AddPart(pivotTableCacheDefinitionPart); var pivotTableCacheRecordsPart = pivotTableCacheDefinitionPart. AddNewPart<PivotTableCacheRecordsPart>(); var pivotCaches = new PivotCaches(); pivotCaches.AppendChild(new PivotCache() { CacheId = pivotCacheId, Id = document.WorkbookPart. GetIdOfPart(pivotTableCacheDefinitionPart) }); document.WorkbookPart.Workbook. AppendChild(pivotCaches);

Concluzie

În acest articol am trasat o “hartă” de bază a modului în care se poate naviga prin OpenXML în generarea fişierelor xlsx. Chiar şi atunci când încerci să-l prezinţi cât mai simplu posibil, se poate vedea că şi pentru cele mai simple operaţiuni codul poate şi va deveni complex.

Aplicarea formatării condiţionate

Vom prezenta cum se poate aplica datelor formatarea condiţionată, adică să formatăm şi să evidenţiem anumite celule pe baza valorilor lor. Pentru a face acest lucru, trebuie să definiţi două lucruri. În primul rând, definiţi stilurile pe care doriţi să le aplicaţi celulelor evidenţiate, în special fonturile şi culorile. Stilurile sunt declarate în Stylesheet al părţii registrului de lucru (workbook part).

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

programare

BDD, Javascript și Jasmine

n acest articol, voi încerca să dezvolt conceptul de Behavior Driven Development (BDD) folosind framework-ul de testare din JavaScript, Jasmine. Cum mulți dintre noi cunoaștem JavaScript ca un limbaj care nu mai este unul de scripting, deseori se întâmplă să avem o migrare, poate nedorită, a logicii de business de pe partea de server pe cea de client.

În acest moment, partea de client a aplicației noastre crește Această descriere, o vom diviza pe mai multe secțiuni, în cele în complexitate, drept urmare va avea mai multe responsabilități. ce urmează. Este important de subliniat că odată cu creșterea numărului de responsabilitați cresc și costurile de mentenanță ale unui proiect. “Loop”-ul (bucla) BDD S-a demonstrat stiințific că partea de mentenanța a unui proiect 1. Scrie un test de acceptanță, care poate fi interpretat ca o este de aproximativ 75%, iar partea de dezvoltare este de doar 25% specificație high-level. [1]. Drept urmare, pe lângă factorii de performanță și scalabilitate 2. Scrie un test unitar care nu compilează sau nu trece ( de ai aplicației noastre se numără și procesul de mentenanță. În acest obicei identificat de pasul “RED” ). context, metologia BDD ne ajută să construim un sistem decuplat, 3. Scrie doar suficient cod, pentru a face testul care a picat, să matur și care se poate „adapta” ușor la modificările din viitor. treacă și nimic mai mult (folosind cea mai simplă soluție posibilă, returnând chiar o constantă, dacă aceasta satisface condiția Diferite interpretări testului. Acest pas este identificat drept pasul “GREEN” din În practică, dacă întrebăm zece programatori ce înseamnă bucla TDD). BDD, sunt mari șanse să primim zece răspunsuri diferite. Unii 4. Refactorizează ( pentru a elimina informația duplicată din spun că BDD este doar Test Driven Development (TDD) implemenimplementare, acest pas introduce designul incremental și pretat bine, alții spun că BDD este a doua generație a metodologiei supune o implementare reala a cerinței ). Agile, iar alții afirmă ca BDD este o tehnică elegantă de exprimare a specificațiilor executabile, și lista ar putea continua. BDD moșteneste din TDD, regula “pull-based” Pentru că BDD vine ca o augmentare peste TDD, trebuie să Din perspectiva programatorului, cred că fiecare din noi descriem în câteva cuvinte metodologia TDD. Programatorii ne-am lovit de-a lungul timpului de dezavantajele conceptului care fac TDD au ajuns la concluzia că singurul lucru în comun ce “push-based”. Pe scurt, conceptul “push-based” descrie acele are TDD-ul cu testele, este cuvantul “test” și nimic mai mult. La timpuri “primitive”, când managerul alocă task-uri, menționând început, am putea recunoaște că sună puțin ciudat, dar voi încerca în cele din urmă: “vreau ca task-ul ăsta să fie implementat până la să fac mai expresivă aceasta neîntelegere. sfârșitul săptămânii”. În acest fel, programatorul este constrâns să Pașii elementari prin care fiecare programator trece, atunci folosească tehnologii si limbaje, altele decât cele pe care dorește să când face TDD sunt următorii: le urmărească. 1. La primul pas, orice programator începe prin a scrie codul BDD închide această fereastră prin expunerea unui “backlog”. de producție, urmat de o sesiune de teste unitare, folosind unul Ne putem gândi la un “backlog” ca la un queue( coadă de mesaje din framework-urile existente. ). Se bazează pe același principiu ca binecunoscutul design pattern 2. La pasul al doilea, după ceva practică, programatorul des- Producer Consumer, unde fiecare programator joacă rolul unui coperă câteva beneficii în a scrie prima dată testele, câștigând consumer, iar stakeholder-ul rolul producer-ului, unde cel din totodată experiență în folosirea unor pattern-e de testare, ca urmă pune requirements-urile în acest queue. Această abordare AAA(Arrange Act Assert), Test Doubles [2] (Mocks, Stubs, întărește comunicarea dintre programator și stakeholder, pentru că Spies), etc.. fiecare cerința, este un high-level feature, expus din perspectiva sta3. Acum programatorul descoperă că TDD poate fi folosit ca keholder-ului care nu este interesat de procesul intern al realizării o tehnică de design, care-l ajută să construiască un cod elegant, tehnice a funcționalității (sigur există situații în care tehnicul intră decuplat și abstractizat. în discuție). După aceasta programatorul împarte aceste cerințe 4. La ultimul pas, programatorul descoperă că, în fapt, TDD în task-uri, care sunt apoi prioritizate în funcție de valoarea lor de nu are nimic în comun cu scrierea de teste automate. business. Această abordare întărește siguranța că stakeholder-ul va ajunge să primească ceea ce a solicitat în cerința inițială, lăsând în La acest punct 4 vom oferi explicații. același timp libertatea programatorului să aleagă soluțiile tehnice Din nefericire, majoritatea programatorilor nu reușesc să cele mai potrivite pentru problema expusă. treacă de pasul al doilea. Dan North, fondatorul metodologiei BDD, descrie BDD-ul ca În esență BDD este TDD pe o tehnică de implementare a unei aplicații, prin descrierea comDupă cum știm, abordarea test-first-code impune de la bun portamentului din perspectiva clientului, numit de acum înainte început o gândire axată pe ce anume trebuie îndeplinit pentru stakeholder. a face testul să treacă. Începând cu un test, vom scrie doar cod

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE pentru a face acest test să treacă și nimic mai mult. În acest context TDD-ul evită Big Design Up Front (BDUF). Cel care scrie testul este și primul utilizator al API-ului. După cum Kent Beck explică în binecunoscuta sa carte, ”TDD By Example” [3], programatorul trebuie să se transpună în cel care va utiliza API-ul – clientul final al serviciului– și apoi va scrie testul. Din nefericire, scriind codul de producție și apoi testele, în cele mai multe cazuri, se creează greutăți sau chiar imposibilitatea de a scrie mai târziu testele pentru acest cod. De ce? Pentru că designul sistemului nu a fost inițial conceput a fi testabil. Urmând această cale se ajunge la un cod fragil, “tightly coupled”, care are multe depedențe și care nu poate fi reutilizat. Finalmente un cod pe care noi, programatorii, l-am numi “unreliable”. De câte ori nu ni se întâmplă că schimbând ceva într-o parte, așa-zis, izolată de cod, se ajunge să se impacteze o componentă dependentă? În fond testele trebuie considerate o plasă de siguranță sub orice refactorizare și orice posibilă schimbare în logica aplicației. Este important de amintit că trebuie testată logica aplicației, comportamentul ei, și nu doar chestiuni triviale, cum ar fi getter-i/ setter-i, sau mai rău, API-uri de la terțe părti, care au propriile lor teste. În special, în lumea Agile unde testarea exhaustivă a produsului in fiecare iterație este practic imposibilă, este nevoie încă o dată de o suită de teste foarte bine pusă la punct care să reducă riscul viitoarelor regresii.

dată de un test, pe când BDD-ul se focusează pe o caracteristică fundamentală a codului și anume comportamentul. Un test va verifica dacă o condiție este îndeplinită sau nu, în timp ce un comportament descrie printr-o reprezentare mai expresivă logica sistemului. În BDD testul ia forma unei specificații. Finalmente atât TDD-ul cât și BDD-ul furnizează specificații executabile care servesc ca documentație vie – “living documentation”. Să insistăm puțin asupra sintagmei living documentation. De cele mai multe ori avem specificațiile date într-o formă statică, fie sub forma unui document, fie sub forma de story-uri. Folosim cuvântul static aici pentru a puncta antiteza acestui gen de specificații vizavi de niște specificații dinamice date de o abordare BDD. Așadar, acest gen de specificații statice, combinate cu specificații executabile, ajung să încalce principiul Dont Repeat Yourself (DRY), fiindcă există o duplicare a informației. Când cerințele aplicației se schimbă, trebuie să adaptăm această schimbare și să o transpunem în implementarea reală a sistemului. De cele mai multe ori specificația statică va rămâne “în urmă”, pierzându-și în cele din urmă valoarea. Așadar atât documentația statică cât și cea dinamică, reprezentată de specificațiile executabile, trebuie sincronizate într-un fel, lucru care finalmente introduce o povară pentru fiecare programator. BDD-ul promovează ideea de a păstra detaliile tehnice în specificațiile executabile, astfel prin rularea lor putem dovedi că cerința din implementare este finalizată. Așadar vom ști cu O mai bună expresivitate exactitate când am terminat. Diferența dintre TDD și BDD este că Acest tip de specificații dinamice trăTDD-ul induce deseori starea de confuzie iesc alături de codul nostru de producție.

Development Outside-In

Dacă există o formă de development numită Outside In, intuiția ne spune că ar trebui să existe și o formă numită Inside Out(sau bottom-up), pe care cred, cu toții am urmat-o la un moment dat. Să începem cu cea din urmă. Urmând o abordare Inside Out începem implementarea pe baza unor operații sau funcții, pe care le considerăm ca “main-stream” în cadrul funcționalității. Este foarte ușor să realizăm prematur abstracții, construcții, care sunt pur și simplu greșite de la bun început. Inside Out ne obligă să ne gândim de la început la toate ramificațiile, toate dependențele între componente, făcând procesul de dezvoltare complicat. Pe măsură ce logica de business devine mai complexă, va fi din ce în ce mai dificil să găsim calea corectă în implementarea funcționalității. Deseori această formă de dezvoltare ne forțează să scriem cod care mai târziu nu este reutilizabil și care devine repede îmbătrânit. Aceasta duce la folosirea ineficientă a timpului și a costurilor de proiect. În sensul pur al Object Oriented Design-ului (OOD) putem spune că violăm un principiu fundamental din lumea Xtreme Programming (XP), si anume YAGNI ( You Ain’t Gonna Need It) [4] În Outside In începem prin a scrie o documentație high-level, care are o valoare de business. Începând cu aceste funcționalități high-level “we code our way in”, prin divizarea specificațiilor în entități coezive, așadar implementăm doar ceea ce este parte a cerinței inițiale și nimic mai mult. Scriind cod în această formă, top-bottom, suntem forțați să ne comportăm ca și Our core competencies include:

Product Strategy

Product Development

Product Support

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

www.3pillarglobal.com

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

programare BDD, Javascript și Jasmine când entitățile dependente ar exista deja. Aceasta poate fi percepută ca un dezavantaj, fiindcă nu vom putea să rulăm specificațiile până când întreaga funcționalitate este implementată. Astfel se contrazice regula BDD-ului( sau TDD-ului ) de a rula specificațiile cât mai des posibil, pentru a surprinde cât mai repede eventualele probleme. În același context, implementând într-o manieră Outside-In, pornind de la o specificație high-level, nu putem afirma că aceasta este chiar un “baby-step”. Scopul este să derivăm specificații lowlevel din cele high-level. Principiul care stă la baza acestui concept este “divide et impera” [5]. Este mult mai ușor să rezolvăm o problemă complexă, dacă găsim o soluție prin care să spargem problema mare într-un set de probleme mai specifice, într-un context mai redus, care în final pot fi agregate în scopul rezolvării problemei inițiale. O altă variantă de a gândi într-o manieră BDD, este relaționarea “One-To-Many”. Elementul “One” este subiectul specificațiilor/ testelor noastre( Subject Under Test – SUT ), iar entitățile “Many” sunt dependențele cu care SUT interacționează. Este o idee bună să amânăm orice implementare concretă a dependențelor pe mai târziu, timp pe care-l putem folosi să deprindem o mai bună cunoaștere a domeniului și a problemei pe care vrem să o rezolvăm. În acest mod, SUT se va baza pe “test-doubles” și nu pe o implementare concretă a dependențelor. În același context bazându-ne, spre exemplu, pe abstracții, și nu pe entitați concrete, vom reuși să integrăm un design “loosely-coupled” între SUT și colaboratorii lui.

Cum organizăm specificațiile în BDD?

Putem adopta mai multe soluții de organizare a specificațiilor, însă cele mai cunoscute pattern-uri de structurare a specificațiilor, permit gruparea bazată pe: 1. Feature, 2. Fixture, 3. Operation/Method. În cele ce urmează le voi descrie punctele forte ale fiecărei modalități de structurare. Voi începe cu gruparea bazată pe “Feature” care permite organizarea codului în specificații, în funcție de subiectul cerinței inițiale. Putem lua cazul practic în care domeniul logic este un magazin online. Cerința este de a calcula totalul produselor din coșul de cumpărături. În logica acestei cerințe vom avea câteva rutine care comunică între ele prin diverse mesaje. De exemplu: var shoppingCart = getShoppingCart(user) var totalAmount = ItemCalculator.calculateTotal(shoppingCart) var totalAmountWithVAT = Taxes.applyVAT(totalAmount)

Aceste operații pot fi structurate ca un singur feature. Partea bună este că acest mod de structurare, permite izolarea fiecărui feature în parte, astfel încât putem avea o suită de specificații pentru fiecare feature în parte și putem înțelege funcționalitatea unui feature doar rulând aceste specificații. Dezavantajul acestei metode de organizare este că, în timp, cerințele se schimbă, noi funcționalități augmentează feature-ul inițial, ca urmare specificația se poate degrada într-un timp foarte scurt datorită numărului mare de modificări. Scopul final este să avem o suită de specificații care exprimă într-un mod clar cerințele testate din requirement-ul inițial, astfel încât ele să servească ca “living documentation”. Calitatea codului nostru din specificații trebuie să fie tranzitiv egală cu codul nostru de producție.

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

Structurarea specificațiilor bazată pe “Fixture” permite o mai bună aranjare, datorită posibilitații de a avea mai multe contexte de execuție. Luând cazul teoretic al unei operații online, putem avea un context de execuție atunci când coșul de cumpărături este gol sau coșul de cumpărături a ajuns la suma maximă admisă. Această abordare de structurare a specificațiilor duce la un design elegant și curat, având suita noastră de operații grupate pe baza contextului în care ele sunt executate. În scurt timp, vom avea parte și de un exemplu practic, în care voi descrie cum putem ajunge la o astfel de structurare a codului pe mai multe contexte de execuție. Exemplul practic este o mică librarie, un EventBus, care ajută la o mai bună decuplare a obiectelor comunicante. Ultimul mod de structurare este bazat pe gruparea fiecărei operații în parte, adică “by Method”. Poate fi un proces incomod, luând cazul practic în care avem definite două metode foo() și bar(). Cum, probabil, suntem “test-infected”, avem o suită de specificații scrise atât pentru foo(), cât și pentru bar(). Acum, operația foo() se poate folosi de operația bar(), dar noi avem deja scrise testele pentru bar(), astfel că testele pentru foo() vor acoperi și cazurile operației bar(). Când introducem o redundanță în specificațiile noastre între componentele testate, acestea vor deveni greu de înțeles, fiind totodată redundante. Dacă o singură problemă va apărea în testele noastre, cum ar fi cazul, mult întâlnit, în care un test se comportă într-un mod non-deterministic, acea problemă va virusa toată suita noastră de teste, făcându-le “unreliable”. Capacitatea de abstractizare face ca orice programator care vede o problemă într-unul din teste, să asocieze toată suita de teste cu acel test “infectat”. BDD construiește pe un limbaj business, denumit GHERKIN [6]. Acesta este un simplu Domain Specific Language (DSL). Acest DSL și-a făcut prima dată apariția în cadrul unui alt framework de testare denumit Cucumber [7]. Spunem că GHERKIN este un limbaj business, pentru că nu se adresează în totalitate programatorului, ci poate fi ușor interpretat și înțeles și de un non-tehnic. După cum bine știm TDD are propriul pattern de organizare a codului din corpul testelor, denumit Arrange Act Assert (AAA). Aceste instrucțiuni ne ajută să structurăm codul într-un test, într-o manieră mentenabilă și ușor de citit. Din nefericire, simpla structurare a codului, nu va ajuta un expert în domeniu să înțeleagă codul nostru. Pe de altă parte GHERKIN augmentează această comunicare dintre programator și stakeholder. Un limbaj ubicuu se naște între cele două lumi. Cele trei instrucțiuni iau acum forma: 1. GIVEN( an execution context ), 2. WHEN( this operation is invoked ), 3. THEN( we should get this expected result ). În acest context, putem identifica foarte ușor o cerință care poate fi interpretată de un non-programator: “GIVEN the employees from a department, WHEN payday comes and computeSalary() is invoked, THEN i want to receive a salary report for all employees”. În această manieră, cerința este foarte ușor de interpretat. Această formă întărește expresivitatea folosind un limbaj natural pentru a declara o cerință reală. Înainte de a termina prima parte a acestui articol, vreau să mai amintesc câteva dintre avantajele BDD față de tradiționalul TDD: 1. Întărește comunicarea dintre programator și stakeholder( prin specificațiile high-level private de orice detaliu tehnic, se naște un limbaj ubicuu între ambele lumi ). 2. Concentrează mindset-ul programatorului mai aproape de

TODAY SOFTWARE MAGAZINE valoare business a cerinței, forțându-l să gândească la nivel de comportamente ale aplicației și nu de teste. 3. Aduce un nou pattern de structurare a codului din teste, făcând specificațiile ușor de înțeles și pentru un non-tehnic. 4. Putem înțelege comportamentul unei aplicații urmărind fluxul de execuție al specificațiilor. A doua parte a acestui articol are o amprentă practică, având ca principal actor framework-ul Jasmine [8]. Scopul inițial a fost să construiesc o simplă librărie urmărind metodologia BDD, dar articolul a reușit să înghită câteva pagini bune până acum, așa că o să descriu câteva părți importante și las cititorului ocazia de a inspecta codul pe github [9]. În câteva cuvinte, Jasmine este un framework de testare unitară și nu un “integration-framework”, după cum alții presupun. Permite structurarea specificțtiilor bazat pe “fixture”, permițând a avea blocuri “describe” imbricate. Totodată vine cu câteva obișnuințe comune pentru a configura contextul de execuție al specificațiilor( setup & tearDown ). Ca implementare concretă a patternului Test Doubles folosește Spies( Spioni ). O simplă utilizare poate fi exprimată în următorul mod: describe(“EventBus – SUT”, function () { // various fixtures it(“should do this and that – describe behavior”, function() { // some executions expect(thisResult).toBeTruthy(); }); });

În contextul de față, SUT-ul nostru este EventBus. După cum sugerează și numele, este un data-bus, responsabil de managementul event-urilor și al listener-ilor. O abordare din punc de vedere al beneficiilor designului bazat pe un Event Bus, ar conduce către un design “loosely-coupled” între obiectele comunicante. Strămoșul său este binecunoscutul Observer Design Pattern. Pentru a evita o strânsă legătură între obiectele comunicante, delegăm această responsabilitate Event Bus-ului, entitate care știe de fiecare event înregistrat și de fiecare listener. Logica decuplată aici este că nici un event nu va ști nimic despre cel care va trata, onora acel request, adică despre listener. Fiecare event este înregistrat în acest EventBus, așteptând să fie tratat de un listener. După cum bine știm jQuery este o librărie care simplifică mult operațiile ( bazate pe evenimente ) la nivel de DOM. În acest context, EventBus-ul prezentat, ne lasă să manevrăm evenimentele axate pe comportamente la nivel de aplicație. O utilizare practică a EventBus-ului o poate avea binecunoscutul, până acum, scenariu al unui magazin online. Când utilizatorul apasă pe butonul de “buy”, deseori am vrea ca o suită de operații să fie cascadate, astfel încât produsul cumpărat să fie adăugat în coșul nostru de cumpărături, o fereastră, posibil modală, de înștiințare să fie afișată, iar produsul cumpărat am vrea să dispară din lista de produse sugerate. În exemplul de față, vom înregistra câteva evenimente în Event Bus, după care vom subscrie un singur listener, care va trata doar un singur tip de eveniment. describe(“EventBus”, function () { var openConnectionEvent, sendStreamEvent; beforeEach(function () { openConnectionEvent = “openConnectionEvent”; sendStreamEvent = “sendStreamEvent”; ); describe(“having a collection of event/listeners – fixture”, function () { beforeEach(function () { EventBus.registerEvent(sendStreamEvent, openConnectionListener);

EventBus.registerEvent(sendStreamEvent, sendStreamListener); }); afterEach(function () { EventBus.cleanBus(); }); describe(“#fireEvents – operation”, function () { it(“should trigger all registered listeners to handle the operation”, function () { spyOn(console, ‘log’).andCallThrough(); EventBus.fireEvent(sendStreamEvent); expect(console.log).toHaveBeenCalled(); // ... other related expectations }); }); }); }) ;

Pe scurt, Jasmine permite o bună structurare a specificațiilor, astfel încât putem urmări foarte ușor firul comportamental al execuției doar citind descrierea din cadrul blocurilor “describe”. Jasmine oferă out-of-the-box mecanismul de “setup” și “teardown” pentru o mai bună organizare a codului din cadrul specificațiilor, “spies” ca implementare concretă a pattern-ului “Test Doubles”. Pe scurt “spies” ne permit să inspectăm ce rutine au fost invocate și opțional, care sunt parametrii cu care au fost invocate aceste rutine. În același context, putem instrui anumite apeluri de rutine să returneze rezultate specifice cerințelor noastre și putem opta pentru o invocare reală a rutinei folosind un ,,spy”și nu un “fake-call”. Integrarea specificațiilor în contextul de Continuous Integration (CI) este relativ trivială.

Sumar

BDD vine ca o augmentare peste tradiționalul TDD. Ca și metodologia TDD, BDD induce designul aplicației către o arhitectură decuplată. Designul incremental face parte din acest proces și este întâlnit în faza de refactorizare. Orice specificație high-level trebuie divizată în mai multe entități coezive care în final ne ajută să implementăm funcționalitatea dorită. Fiecare cerință este prioritizată în funcție de valoarea de business. Cu acest arsenal de tehnici putem foarte ușor să evităm să implementăm un BDUF prematur. Forma de dezvoltare software Outside In este motorul care angrenează conceptul BDD. Dintr-un punct de vedere, această formă, ne constrânge, neputând să rulăm toate testele până în momentul în care avem o implementare concretă a întregii cerințe. Unele framework-uri asigură mecanismul de “cross-this-specification”, care ne permite să evităm rularea unei specificații high-level, sau altfel spus un test de acceptanță. Pe de altă parte Outside In, ne încurajează să gândim în abstracții și să evităm o implementare reală, care de multe ori se dovedește a fi prematură, până când deprindem destulă cunoaștere a domeniului/problemei. Partea și mai bună este că putem face BDD într-un limbaj dinamic ca și JavaScript. “Probably if we do TDD well, we are already doing BDD”.

Claudiu Cosar

claudiu.cosar@3pillarglobal.com Software engineer @ #Pillar Global

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

management

De ce durează atât de mult să terminăm un task?

ezolvarea unui task sau chiar citirea unui articol dintr-o revistă, indiferent că e pe suport fizic sau online, durează în mod normal doar câteva minute. În aceste câteva minute, șansele sa îți întrerupi activitatea curentă – pentru verificarea telefonului, a e-mailului, a notificărilor primite pe Facebook sau Twitter – sunt destul de mari. Iar dacă ești în birou, discuțiile dintre colegi fie ele despre mașini, fotbal sau fashion sau ieșirile din seara precedentă, îți captează într-o oarecare măsura atenția. Chiar dacă până acum te-ai menținut concentrat, nu poți să nu îi răspunzi colegului care te roagă amabil să îl ajuți şi astfel ţi se va pierde focusul. Iar cu toate acestea, când intră şeful în birou, acesta te întreabă de ce task-ul de ieri nu este încă gata.

Realitatea cruntă

De multe ori, realizarea unui task devine din ce în ce mai greoaie din cauza factorilor perturbatori. Se spune că în cadrul biroului ești întrerupt cam o dată la 3 minute, cauzele fiind atât de natură umană cât şi de natură digitală. Odată întrerupt, îți poate lua până la 20 de minute ca să îți revii la concentarea inițială. În momentul în care oamenii realizează această perturbare, încearcă să compenseze întreruperile şi astfel tind să lucreze mai repede, însă acest lucru are un preț: mai mult stres, frustrare, lucru sub presiunea timpului, efort mai mult. Factorii perturbatori din mediul de lucru au existat dintotdeauna. Paradoxal, evoluția erei digitale a avut un impact puternic asupra productivității indivizilor, dar în zilele noastre, tehnologia parcă are un singur scop: să atenteze asupra concentrării. Odată cu apariția device-urilor inteligente, explozia aplicațiilor web, eCommerce-ul, dar şi altele, e din ce în ce mai greu să ne menținem concentrați. De multe ori pornim la începutul zilei cu o lista de to-do-uri,

iar spre sfârșitul zilei constatăm că încă mai sunt lucruri nerezolvate. Astfel, indiferent de ce presupun acele sarcini, acestea ar trebui să fie cât mai mărunte, pentru a putea fi terminate într-un timp cât mai scurt, cu rezultate vizibile.

Productivitatea

Însă, ce este de fapt productivitatea? Am putea să o măsurăm destul de exact: numărul de unităţi realizate într-o anumită perioadă de timp, de exemplu: numărul de linii de cod scrise într-o oră. Dar acest calcul nu reflectă adevărata productivitate care ar trebui cântărită în raport cu rezultatele obținute într-o anumită perioadă; de exemplu, la sfârșitul zilei clientul a primit produsul, business-ul pe care îl conducem a avut o perioadă favorabilă, am învăţat un lucru nou în ziua respectivă și câte altele. De asemenea, productivitatea se referă şi la modul în care ne administrăm timpul şi pe noi înşine astfel încât să avem cât mai multe realizări, într-un timp cât mai scurt. Cu alte cuvinte – să maximizăm realizările dar, în acelaşi timp, să minimizăm efortul depus.

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

Autodisciplina

Pentru a fi cu adevărat productiv şi a avea o concentrare adecvată este nevoie de multă disciplină. Dar ce te faci când creierul este cel indisciplinat? În majoritatea timpului ne folosim creierul pentru a extrage din el informaţii pe care deja le ştim: fie le-am învăţat, fie le-am citit sau le-am auzit undeva. Partea cea mai grea vine în momentul în care avem o problema de rezolvat şi trebuie să gândim: acest lucru pare – într-o primă instanţă – destul de greu pentru creier şi prin urmare, ne îndeamnă să ne mutam atenţia şi să ne ocupam timpul cu altceva, în speranţa că poate problema se va rezolva de la sine ( lucru care – evident – nu se va întâmpla ). Astfel, ne verificăm e-mailul, telefonul, 2-3 bloguri pe care le urmărim, încercăm să revenim, încă nu merge, o luăm pe altă parte şi tot aşa; şi astfel ne pierdem printre site-uri, articole, e-mail-uri în încercarea de a evita un lucru pentru care suntem concepuţi: să gândim. Ajungem astfel la așa numitul multitasking. El este dușmanul numărul unu

TODAY SOFTWARE MAGAZINE al productivității, din motive destul de obiective: creierul nostru are o anumită capacitate de atenţie şi este ideal ca aceasta să fie asociată unui singur task la un moment dat. Nu poţi avea o concentrare maximă asupra unui lucru, dacă în paralel mai încerci să răspunzi şi la un mail şi mai şi dai raport şefului1.

interfereze cu prioritățile lor. Totodată, se spune că dimineaţa oamenii au în general o voinţa mai puternică decât în restul zilei şi prin urmare sunt mai optimişti şi mai deschişi către noi provocări. Aşa că, trezitul de dimineaţă este una din cheile unei zile productive. Orele de dimineață pot fi folosite pentru practicarea unui sport sau planificarea target-urilor pentru ziua respectivă. De asemenea, anumite sarcini care necesită concentrare mai mare pot fi rezolvate în orele dimineţii.

To do sau NotTo do

Se poate însă evita multi-tasking-ul folosindu-ne de psihologia flow-ului. Flow-ul este momentul acela pe care l-am avut cu toţii, în care eşti total absorbit de problemă, de task şi nimeni şi nimic nu te poate deranja. Ar trebui profitat de aceste momente. Partea mai puţin bună este că flow-ul e ceva ce nu prea poate fi programat, iar o noapte cu mai puţină odihnă se resimte. Flow-ul mai este influenţat şi de provocarea adusă de task în concordanţă cu încrederea individului că are abilităţile necesare de a rezolva problema. Dar deja alunecăm în psihologie; prin urmare, sunt anumite momente când simţi că eşti mai creativ şi mai productiv, iar acele momente ar trebui fructificate. Articolul prezintă activităţi şi/sau situaţii din viaţa de zi cu zi, ilustrând probleme dar şi îmbunătăţiri care pot fi aduse pentru a creşte productivitatea. Având în vedere că fiecare individ în parte este diferit şi are propriul stil de lucru, ideile prezentate mai jos s-ar putea să nu fie utile tuturor.

25h/zi

După cum ziceam, productivitatea se referă la modul în care ne organizăm ziua, munca, gândurile. Există numeroase articole despre ce obiceiuri au unii dintre cei mai de succes oameni. Citind astfel de articole, ajungi să crezi că pentru unii ziua are mai mult de 24 de ore şi te întrebi cum reuşesc alţii să facă atâtea lucruri în aceeaşi unitate de timp în care ţie îţi încap doar câteva chestii de bază. Ei bine, sunt câteva trucuri pe care aceştia le folosesc şi susţin că le-au îmbunătăţit substanțial viața şi modul de lucru. Majoritatea investesc orele de dimineaţă în lucruri importante pentru ei, înainte ca activitățile celorlalți să 1 http://w w w.car to onaday.com/ the-role-of-smartphones-in-business-productivity/

Un lucru pe care îl face destul de multă lume şi care nu este neapărat un truc este lista de to do-uri. Aceasta poate să conţină task-uri care necesită rezolvare imediată, lucruri de care ar trebui să îţi aduci aminte până la un moment dat (ex: să răspunzi la un mail până la o anumită dată) sau chiar şi lucruri pe care ţi-ar plăcea să le faci sau ai vrea să le faci, dar care suportă amânare. Deşi o unii nu o consideră necesară, lista de to do-uri are un rol destul de important: există o mulţime de gânduri, presiuni, idei pe care creierul e forţat să le ţină minte. Faptul că acestea ajung scrise e un win-win şi pentru noi şi pentru creier. În cazul concret al programatorilor, pe lista de to do-uri am putea adăuga obiectivul sau sarcina pe care vrem să o ducem la bun sfârșit într-un timp cât mai scurt. Definirea unui obiectiv clar înainte de a începe lucrul efectiv, duce la împlinirea rezultatelor într-un mod mai eficient. De multe ori ne apucăm de lucru şi pe parcurs este posibil să deviem de la ideea iniţială sau ne dăm seama că voiam de fapt cu totul altceva; se ajunge astfel la situaţia în care s-ar putea ca nici noi să nu ştim exact ceea ce vrem să obţinem. De aceea, este extrem de important definirea cât mai specifică a sarcinilor. Pe de altă parte, unii sugerează faptul că o lista de genul Not To do ar putea fi mai utilă în managementul timpului şi pentru creşterea productivității. Realizând o simplă statistică asupra activităților zilnice, se pot determina acelea care aduc sau nu beneficii, în funcţie de timpul şi de efortul depus. În final, fiecare decide dacă să folosească sau nu o listă şi dacă da, o va alege pe cea potrivită lui.

îţi permite gestionarea activităților astfel încât să poţi lucra „pe mai multe fronturi” în decursul unei zile. În acest fel te simți oarecum protejat de multi-tasking, deoarece știi că ţi-ai rezervat timp şi pentru celelalte activităţi. Un caz în care tehnica de timeboxing ajută – având și un impact psihologic – ar fi momentul începerii unui task nou: e mult mai uşor să începi un task cu gândul că ai două ore asociate lui, decât să te gândeşti că ai timp suficient de lucru, neștiind de fapt când se va încheia task-ul. Altfel, după două zile de lucru pe acelaşi task, ai vrea sa te apuci de altceva. Totodată, setând o anumită limită de timp, îţi poţi gestiona şi munca mai bine: astfel, nu te vei forța să scrii „un roman” în cele 2 ore, ci doar ciorna primului capitol. Un exemplu de timeboxing este şi tehnica Pomodoro. Aceasta a fost creată de italianul Francesco Cirillo în anii 1980, frustrat fiind de faptul că nu se putea menţine concentrat pentru o perioadă mai lungă de timp. Tehnica presupune alegerea unui task şi folosind un timer se lucrează la acel task timp de 25 minute, urmate apoi de o pauză de 5 minute. Acesta este un „pomodoro”. Se pot realiza mai multe pomodoro consecutive2.

Practici. Obiceiuri.

În special în domeniul IT, dar nu numai se vorbeşte destul de des despre best practices. Numele este destul de sugestiv, însă fiecare domeniu sau limbaj de programare are propriile reguli/practici. La fel cum zice şi Will Durant în The Story of Philosophy (deşi unii atribuie zicala lui Aristotel) :„We are what we repeatedly do. Excellence, then, is not an act but a habit”, iar „bagajul” de best pratices şi lessons learned se acumulează în timp. Prin urmare, stabilirea unor obiceiuri şi a unor practici bune, duce automat la o mai bună calitate a codului, a rezultatelor. Astfel, una dintre metodele de învăţare sau stabilire a obiceiurilor este Seinfeld Calendar. Această metodă a fost concepută de comedianul Jerry Seinfeld la începutul carierei sale, moment în care era nevoit să scrie cât mai mult pentru a îşi construi un repertoriu de glume bune. Tehnica este foarte simplă: se alege un task, o activitate şi se bifează într-un calendar ziua în care s-a efectuat acea activitate. Ideea Managementul timpului este să-ţi îndeplineşti task-ul în fiecare zi, Un alt termen legat de productivitate iar pe măsura ce zilele trec, în calendar se este şi timeboxing-ul. Acesta este o tehnică va forma un lanţ. Neîntreruperea acestui de management al timpului care prinde din lanţ duce la stabilirea acelei activităţi ca ce în ce mai mult teren în rândul progra2 http://blog.clarity.fm/25-minutes-is-all-you-needmatorilor şi nu numai. Este util deoarece how-the-pomodoro-technique-increases-productivity/ www.todaysoftmag.ro | nr. 22/Aprilie, 2014

management De ce durează atât de mult să terminăm un task? obicei. Această tehnică funcţionează în orice domeniu, deoarece acţiunile repetitive, zilnice, duc la implantarea obiceiurilor. Totodată, tehnica duce spre gamification, trezind astfel în noi dorinţa de competiţie, realizare şi împlinire.

Decizii? Un concept relativ nou, din cauza căruia alegerile şi deciziile noaste se înrăutăţesc pe măsură ce ziua se scurge este – aşa cum o numesc jurnaliştii de la New York Times – „decision fatigue”3. Aceasta are la bază faptul că în fiecare decizie luată sau alegere făcută pe parcursul zilei, creierul oboseşte și ajunge spre sfârşitul zilei să ia cu greu deciziile cele mai bune. Astfel, la sfârşitul zilei, când nivelul energiei este scăzut, este foarte probabil să acţionăm după impuls sau să evitam luarea unei decizii. De cele mai multe ori nu realizăm această oboseală mentală şi o conştientizăm abia după o alegere mai puţin inspirată. De aceea este bine să planificăm deciziile importante dimineaţa. Un exemplu pe care mulţi oameni de succes îl adoptă, probabil şi din alte motive nu doar pentru a-şi uşura deciziile este utilizarea unei garderobe cât mai simple. De exemplu, Mark Zuckerberg are o mulţime de tricouri gri de acelaşi fel; Barack Obama are doar costume gri şi albastre, pe care le alternează; de asemenea şi Steve Jobs se îmbraca la fel în fiecare zi. Astfel, ei elimină până şi puţinul efort de a se decide cu ce să se îmbrace dimineaţa, decizie care pentru unii, poate dura zeci de minute bune. Până şi deciziile precum ce să mănânc azi, să merg la sală sau la bazin, ne consumă întrun fel sau altul, fără să ne dam seama.

80/20 Din categoria „Life isn’t fair”, principiul Pareto sau legea 80/20 subliniază faptul că majoritatea lucrurilor din viaţă nu sunt distribuite în mod egal. Enunţul generic al principiului spune că 20% din efort creează 80% din rezultate. Dacă ar fi să inversăm enunţul, ar ieşi ceva de genul: 80% din efort creează 20% din rezultate. Cel din urmă parcă sună ceva mai productiv, mai multă muncă – şi mulţi se ghidează după aceasta, investind efort şi timp în ceva ce nu este necesar4. Deşi ne-am dori uneori ca viaţa să fie conform linei roşii din grafic, majoritatea lucrurilor au o distribuţie inegală. Acest lucru are însă şi un avantaj: de multe ori, 3 http://www.nytimes.com/2011/08/21/magazine/doyou-suffer-from-decision-fatigue.html 4 h t t p : / / b e t t e r e x p l a i n e d . c o m / a r t i c l e s / understanding-the-pareto-principle-the-8020-rule/

înlocuirea unei căi lungi spre un fişier cu un nume mai scurt. De exemplu, dacă se doreşte rularea personalizată a anumitor comenzi, cum ar fi cea de remove - să fie mereu rulată cu opţiunea pentru confirmare, putem seta un alias comenzii rm: rm –i. Un alt exemplu ar putea fi comenzile lungi sau cele mai des folosite în lucrul cu sistemul de versionare git. O altă idee, care pare foarte productivă este pair programming-ul. Pe lângă faptul că lucrezi împreună cu un coleg – şi lucrezi, că doar nu îţi arăţi mail-urile celuilalt – pair programming-ul îmbunătăţeşte productivitatea pe termen lung, dar şi calitatea codului. Deşi pe termen scurt, productivitatea şi timpul fiecăruia sunt afectate pair programming-ul aduce în plus cunoştinţe legate de cod, design şi arhitectură, mediu de dezvoltare şi instrumentele folosite. Cu alte cuvinte, persoana cu care lucrezi poate avea idei şi practici diferite pe care noi ni le putem însuşi. Astfel, prin learn şi share se dezvolta cunoştinţele în cadrul unei echipe. Iar în final, pentru a ne scuti o parte din muncă ce ar fi să plasăm anumite sarcini pe seama calculatorului: acesta însemnând automatizare, de la cele mai mici şi mărunte comenzi care sunt efectuate cu o frecvenţă mare, până la aplicaţii care sunt capabile să genereze cod în locul nostru (Numărul 21 Today Software Magazine: „Cum să scrii un generator de cod bazat pe template-uri flexibile”, Denes Botond).

în realizarea unui nou produs clientul are o idee sau un pic mai mult decât o idee, însă rar se întâmplă să aibă în faţă o imagine completă asupra rezultatului final. Astfel, ca dezvoltatori ar fi ideal să investim doar 20% din efort şi să îi propunem clientului un prototip sau chiar două, în loc să investim mult efort doar într-o singură direcţie pe care să o ducem cât mai aproape de finalizare. Iar acel prototip propus se va regăsi cu siguranţă, într-un procent foarte mare în produsul final; ceea ce urmează sunt trăsături adiţionale. Dacă am fi investit mult timp doar într-o direcţie care s-ar fi dovedit a fi una greșită, am fi consumat 80% din efort pentru doar 20% din rezultate. Deci, aceeaşi unitatea de intrare ( efort, timp, forţă de muncă ) nu contribuie în mod egal la rezultate. Prin urmare, în distribuirea timpului, resurselor şi a efortului soluţia optimă este cea care presupune 20% efort şi care gene- Concluzii rează 80% rezultate. Sunt câteva pattern-uri care ne distrug productivitatea. Printre cele mai evidente Axiome se numără multi-tasking-ul şi întreruperile Multe dintre lucrurile amintite mai sus cauzate de notificări sau cereri din partea pot fi sau nu aplicate în funcţie de princi- colegilor sau cunoscuţilor. Acestea, dar şi piile fiecăruia. Următoarele idei ar putea fi celelalte obiceiuri mai puţin bune pot fi încadrate ca axiome, fiind general valabile evitate sau diminuate apelând la voinţă şi şi neavând nevoie de nici o demonstrație. disciplină. În cazul în care Fabebook-ul şi Un mod evident de a face mai multe email-ul sunt mai puternice , există aplicaţii lucruri într-un timp mai scurt este folosi- care îţi pot restricţiona accesul la anumite rea shortcut-urilor sau a short key-urilor. pagini web. Unelte mai puţin drastice, şi Indiferent că sunt pentru sistemul de ope- mai mult cu titlu informativ sunt cele de rare, editorul preferat, browser sau IDE monitorizare a timpului petrecut pe anushort key-urile contribuie la îmbunătăţirea mite pagini web sau în anumite aplicaţii. O stilului de lucru. Fiind multe şi variate, astfel de unealtă este chiar utilă pentru o o bună strategie ar fi învăţarea acestora statistică personală legată de timpul petregradual: câteva short key-uri pe zi. De ase- cut în faţa calculatorului. Având o astfel menea, o lista cu short key-urile des folosite de statistică, se pot identifica şi corecta pusă pe monitor ajută la recapitularea oca- obiceiurile care ne scad productivitatea şi zională a acestora. concentrarea. Gabriela Filipoiu Tot la shortcut-uri putem adăuga şi gabriela.filipoiu@accenture.com alias-urile pentru comenzile shell. Aliasuri se pot crea fie pentru comenzi lungi, Software Engineering Analyst fie pentru că dorim mereu rularea perso@ Accenture nalizată a unei anumite comenzi sau chiar

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

management

Metodologia Lean pentru Requirements Engineering

n prezent, datorită evoluției rapide a tehnologiei și a ușurinței accesului la informație, aproape oricine are posibilitatea de a construi produse sau servicii software pe care să le adreseze pieței globale. Așadar, în ciuda istoriei relativ recente a acestui domeniu, industria software a devenit înfloritoare generând un interes uriaș în domenii de activitate precum dezvoltarea, testarea sau distribuția. Radu Orghidan

radu.orghidan@isdc.eu Requirements engineer @ ISDC

Ingineria specificațiilor, cunoscută sub denumirea de Requirements Engineering (RE) [1,2], este o parte importantă a procesului de dezvoltare de software. S-a demonstrat, atât în literatura [3,4,5] cât și din experiența noastră în ISDC, că erorile rezultate din modelarea imprecisă a proceselor sau neînțelegerea corectă a funcționalității de implementat generează costuri mult mai mici atunci când sunt descoperite în timpul definirii specificațiilor decât atunci când defectele apar în producție. În plus, cea mai mare parte a costurilor unui proiect software este absorbită în faza de mentenanță, aceste costuri fiind influențate în mod direct de calitatea specificațiilor și analizei inițiale. Directorul de produs (eng. Product Owner - PO) este cel care interacționează cu comunitatea RE și este implicat în procesul aferent pentru a descrie, a documenta și în cele din urmă pentru a construi produsul final cerut de proprii clienți. Pentru un PO comunitatea RE este unul dintre instrumentele folosite pentru a satisface nevoile clienților. Schimbând sistemul de referință, procesul de RE poate fi văzut ca produsul pe care companiile software, prin intermediul echipei de RE, îl oferă clienților lor. Metodologia Lean a fost introdusă și implementată de Toyota în sistemul propriu de producție. Aceasta se concentrează pe aspectele care produc valoare utilizatorului crescând astfel calitatea produsului obținut, în timp ce durata de dezvoltare și costurile scad. Eric Ries, în cartea sa „The Lean Startup” [6] definește startupurile ca fiind “instituții umane construite pentru a livra un nou produs sau serviciu în condiții de incertitudine”.

Un startup implică deci o interacțiune umană ce are loc într-un mod structurat. Similar, specificațiile se obțin folosind tehnici de investigație bine definite precum interviurile, sesiunile de workshop, observarea, construirea de prototipuri etc.. A doua parte a definiției pune accentul pe faptul că startupurile livrează un produs sau serviciu fără să știe cu certitudine cum se va adapta acesta la nevoile utilizatorilor finali. Iată din nou o similitudine cu activitatea comunității RE care trebuie să dezvolte o serie de cerințe [7,8,9] ce vor trebui să se adapteze nevoilor clientului în timp ce descriu un nou produs cât mai precis posibil. Pornind de la observația că departamentul de RE al unei companii producătoare de software poate fi asimilat cu ușurința unui startup, vom analiza ideea extrapolării principiilor Lean dezvoltate pentru startup-uri și pentru activitatea de RE. Obiectivul acestui articol este de a prezenta o nouă paradigmă a procesului de RE: În primul rând, activitatea de RE va fi prezentată precum un produs vândut companiilor care investesc în dezvoltarea de produse software; în al doilea rând, vom arăta cum metodologia Lean poate fi aplicată activității de RE. Ca o observație interesantă, metodologia Lean poate fi simultan aplicată ambelor părți implicate în activitatea de RE: clientul o poate folosi pentru a defini activitățile pe care startup-ul trebuie să le desfășoare pentru a construi un produs de succes în timp ce echipa de RE poate aplica metodologia Lean pentru a defini procesul necesar definirii specificațiilor necesare pentru obținerea unui produs software cu funcționalitatea dorită.

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

management Metodologia Lean pentru Requirements Engineering Învață, Măsoară, Construiește

Produsele software pot fi dezvoltate folosind diverse metodologii precum: waterfall, iterative sau agile. Independent de soluția aleasă, activitatea de RE este un pas obligatoriu care precedă dezvoltarea de software. În mod obișnuit, faza de RE este urmată de dezvoltare și apoi de lansarea în producție. Așadar, perioada de învățare a unei companii ce lansează un produs nou este împărțită între faza de RE și cea de intrare în producție, cu pondere majoritară după Figura 2. Crearea unui Produs Minimum Viabil ce produsul începe să fie folosit de clienții permite comunității RE să îndeplinească nevoile reale finali. ale clienților. Imagine preluată de pe site-ul Lean Figura 1 descrie un flux tipic de Entrepreneur (http://LeanEntrepreneur.com/) producție care începe cu construirea specificațiilor urmată de dezvoltare și asi- și analizarea cerințelor, dezvoltarea gurarea calității produsului terminând cu specificațiilor, managementul specificațiilor, lansarea produsului. transmiterea și auditarea specificațiilor. Așa cum se arată în Figura 3, acest proces urmărește fluxul Construiește, Măsoară, Învață. Figura 1. Perioada de învățare a unei companii ce lansează un produs nou începe în etapa de RE și se finalizează după ce produsul începe să fie folosit de clienții finali. Figura 3. Procesul folosit în cadrul

În timpul primei etape, trebuie să trecem printr-un proces de învățare pentru a adapta cerințele clientului la domeniul de activitate și la constrângerile de ordin tehnic. Cu toate acestea, în faza inițială există foarte puține date despre impactul produsului asupra utilizatorilor finali, despre cum va fi primit și înțeles de piață. Atunci când produsele dezvoltate includ o componentă de inovare importantă este foarte dificil să se anticipeze reacția clienților. În timp ce în cele două etape ce succed procesul de RE efortul principal se concentrează pe dezvoltarea propriu zisă, partea cea mai importantă a procesului de învățare este „recoltată” după lansarea produsului. Metodologia Lean inversează procesul industrial de producție format din secvența „Construiește, Măsoară, Învață”. În loc de aceasta, teoria Lean susține ideea creării unui ”Produs Minimum Viabil” care se folosește pentru a învăța ce doresc utilizatorii finali cu adevărat și, prin urmare, permite dezvoltarea unui produs adaptat nevoilor reale ale clienților, după cum este ilustrat în Figura 2. Dacă ne concentrăm pe stadiul de RE și continuăm analogia dintre comunitatea RE și un startup, în ISDC am încercat să înțelegem cum să aplicăm metodologia Lean în cadrul unui proces intern de RE. În mod tradițional, procesul de RE cuprinde următorii pași principali: planificarea, obținerea

comunității RE din ISDC.

Pentru a adapta acest proces metodologiei Lean, RE trebuie să dezvolte specificațiile în iterații scurte și să valideze continuu rezultatele cu clientul. Scrierea specificațiilor trebuie să fie o prioritate deoarece aportă informații valoroase echipei de dezvoltare a produsului atât din punct de vedere funcțional cât și din perspectiva înțelegerii modului de lucru al clientului, ale valorilor acestuia și ale așteptărilor pe care le are de la RE. Prin aplicarea metodologiei Lean, se încearcă acumularea câtor mai multe cunoștințe în fazele incipiente ale procesului de RE. Steve Jobs spunea: „nu este treaba clientului să știe ce vrea”. La fel, și comunitatea de RE trebuie să poată să obțină informația corectă creând un Produs de Specificații cu Valoare Minimă (PSVM) și măsurând feedback-ul clientului. Încercarea de a identifica un concept și de a-l valida prin experimente empirice este cunoscut în metodologia Lean ca „învățare validată” (eng., validated learning). Din experiența noastră, lipsa informațiilor de învățare validată duc la frustrări de ambele părți și la întârzieri în dezvoltarea produsului.

construirea unui startup. Prin urmare, Lean canvas poate fi folosit de asemenea de către comunitatea RE. Considerând „Produsul” și „Piața” ca fiind principalii piloni în jurul cărora se construiește un startup, următoarele aspecte trebuie luate in considerare: • Produs • Problema: Identificarea problemelor de rezolvat pentru client, • Soluția: Identificarea soluției și validarea experimentală, • Metricile: Modalitățile de măsurare a succesului • Costurile: Identificarea costurilor fixe și variabile. • Piața • Segmentele de clienți și pionierii: trebuie să se facă o distincție între clienți și utilizatori.Pionierii sunt acele persoane care vor folosi produsul încă de la lansarea acestuia sau chiar dinaintea lansării. • Oferta unică: definirea unei oferte unice sau a unui PSVM. • Canale: definirea canalelor pentru a ajunge la client. • Surse de venit: dacă este posibil, identificarea surselor de monetizare a afacerii.

Unul dintre pașii cei mai importanți în construirea unui startup este identificarea clientului final. În procesul de RE din ISDC, aceasta este echivalentă cu identificarea părților interesate care sunt responsabile cu dezvoltarea produsului. Pentru a identifica persoanele potrivite, analiza trebuie să considere numărul potrivit de candidați. Pe de o parte, nu va trebui să includă un cerc prea extins deoarece acesta va duce la un set de reguli dificil de controlat. Totuși, grupul nu trebuie să fie prea restrâns deoarece segmentul țintă se va micșora ceea ce va duce la pierderea din vedere a opiniilor unor clienți importanți. Odată ce se stabilesc persoanele responsabile de proiect, cel mai important segment dintre aceștia va trebui să fie identificat. Acesta poate include clienții care au o conexiune cu comunitatea de RE – de exemplu, sunt mai ușor de atins sau pot comunica mai bine. În această fază, este foarte important să fie realizată distincția între clienți și utilizatori: clienții plătesc în timp ce utilizatorii nu. Grupul celor care folosesc primii produsul este format în acele persoane care au cea mai mare nevoie de produs. Acest grup Unealta Lean Canvas este foarte important deoarece furnizează Unealta „Lean canvas”, oferită de Lean informații despre cele mai valoroase caracStack [10], este deosebit de utilă în analiza și teristici ale produsului chiar și înainte de

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE lansarea acestuia. Ca și în orice startup, comunitatea RE din ISDC trebuie să poată identifica problemele de rezolvat pentru client. O lecție învățată din proiectele noastre este aceea de a identifica cele mai importante trei probleme ale utilizatorilor folosind analiza cauzală bazată pe cinci întrebări. Este de asemenea foarte interesant de analizat soluțiile pe care clienții le folosesc în momentul construirii produsului pentru a-l substitui. Se pot identifica astfel alternative pentru a îmbunătăți situația existentă. Produsul sau serviciul oferit de RE nu trebuie să fie perfect însă trebuie să fie o îmbunătățire clară a alternativelor existente. De exemplu, în comunitatea noastră, aducem experți în domeniile abordate. Acest lucru ne permite să oferim clientului o privire mai proaspătă și obiectivă comparativ cu ceea ce s-ar obține folosind experții interni ai clientului. Un alt aspect care trebuie evaluat când se definește o soluție pentru problemele clientului este să se înțeleagă ce anume înlocuiește produsul. Orice produs înlocuiește ceva și echipele noastre de pre-sales și RE au misiunea de a clarifica motivația clientului de a-și asuma riscul prin adoptarea produsului propus. Suntem deosebit de atenți cu aceste aspecte deoarece serviciile oferite clienților noștri vor înlocui probabil unele sarcini realizate de echipe interne sau, în unele cazuri, vor înlocui chiar echipe întregi. PSVM, adică soluția ce implică cel mai mic efort de dezvoltare care oferă valoare utilizatorului, trebuie să fie definită. Soluția poate să nu fie unică, iar clientul are în general mai multe propuneri, incluzândule bineînțeles și pe cele ale concurenței. Pentru a atrage atenția clientului ne concentrăm pe a defini o propunere unică. Aceasta trebuie să se poziționeze la intersecția principalei probleme a utilizatorului și soluția propusă de noi. Pentru a avea un impact maxim, propunerea trebuie să fie enunțată

cu claritate și să includă descrierea rezultatului livrat utilizatorului, să fie încadrată în timp și să anticipeze potențialele obiecții. De exemplu, o propunere poate să aibă următorul conținut: “Specificații definite cu claritate, livrate în x zile lucrătoare și cu garanția unei soluții fără defecte”. Bariera de intrare este un factor intrinsec al companiei sau a soluției propuse, precum brand-ul, experiența în domeniu, dimensiunea sau componenta echipei, nișa de specializare etc.. Acești factori nu pot fi copiați sau cumpărați cu ușurință și pot fi folosiți pentru a întări propunerea noastră. Este de asemenea util de pregătit o metaforă care să ofere clienților mai puțin familiarizați cu termeni tehnici, o imagine clară a serviciilor RE oferite și a caracteristicilor acestora. Dacă este necesar, se vor defini canalele prin care se poate ajunge la client. În general, se poate începe cu câteva canale și altele vor apărea în mod natural, pe parcurs. Definirea metricilor de succes este esențială pentru proiectele noastre. Pentru a construi metrici corecte, comunitatea RE identifică ce anume clientul percepe și valorează ca succes. Costurile fixe și variabile sunt de asemenea evaluate pe baza acestor metrici pentru a le putea stabili ordinea de prioritate în mod corect.

Concluzii

Acest articol s-a concentrat pe serviciile RE în contextul oferit de compania noastră. În ISDC, vedem activitatea de RE atât ca un produs în sine cât și ca o activitate antreprenorială. Această viziune a dus la ideea adaptării principiilor Lean activității de RE pentru a îmbunătăți procesul existent. Metodologia Lean se concentrează pe acele activități care produc valoare clientului ducând în același timp la reducerea duratei ciclului de dezvoltare și a costurilor precum și la creșterea calității produsului. Una dintre conceptele cheie ale Lean este MVP (Minimum Viable Product) care reprezintă soluția cu un efort minim de implementare

și care totodată oferă valoare clientului. Arătăm, prin analogie, că și specificațiile pot fi elaborate ca un PSVM (Produs de Specificații cu Valoare Minimă). Alte contribuții ale metodologiei Lean folosite în procesul comunității RE din ISDC sunt conceptele de “Învățare validată” (eng. Validated Learning) și ideea inversării procesului tradițional de construire a documentelor de specificații și transformarea fluxului în secvența “Învață, Măsoară, Construiește”. Dezvoltarea specificațiilor în pași mici și validarea rezultatelor cu clienții sunt cruciale. Respectând aceste principii comunitatea RE acumulează cunoștințe importante atât din punct de vedere funcțional cât și în ceea ce privește modul de lucru al clientului și așteptările acestuia în urma procesului de dezvoltare al specificațiilor.

Bibliografie „Requirements Engineering in an Agile Environment”, Yunyun Zhu, Department of Information Technology, Uppsala University, 2009 “Best Practices for Requirements Gathering”, Michael Krasowski, Online course at http://pluralsight.com/ “Dependency based Process Model for Impact Analysis: A Requirement Engineering Perspective”, Chetna Gupta, Yogesh Singh, Durg Singh Chauhan, International Journal of Computer Applications (0975 – 8887), Volume 6– No.6, September 2010. “Impact Analysis of Goal-Oriented Requirements in Web Engineering”, Jose Alfonso Aguilar, Irene Garrigos, Jose-Norberto Mazon, The 11th International Conference on Computational Science and Its Applications (ICCSA 2011). “Requirements Engineering”, Elizabeth Hull, Ken Jackson, Jeremy Dick, Springer, 5 oct. 2010. “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses”, Eric Ries, Crown Business (September 13, 2011), ISBN-10: 0307887898, ISBN-13: 978-0307887894

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

Trenduri în HR (II)

șa cum menționam în articolul din numărul 19 TSM, această parte a doua a HR Trends în 2014 va acoperi încă cinci tendințe identificate pe piața din Cluj. La începutul acestui articol, menționăm că este expresia un punct de vedere subiectiv, bazat pe experiența realizată în zona de HR, neavând la bază un studiu întreprins în această direcție.

Dacă în prima parte ați putut citi despre: 1. HR Business Partnering (HR privit ca partener de business și nu ca funcție support), 2. Attract and retain top talents (Atragerea și retenția angajațiilor de top), 3. Employer branding (Poziționarea companiilor pe piață), 4. Career path and development plans (Planuri de dezvoltare a carierei pe temen mediu și lung), 5. Employee engagement (Creșterea angajamentului în cadrul companiei).

organizației. Rolul lor este să introducă cele mai bune practici și să le aplice în companie astfel încât acestea să aibă un impact pozitiv în dezvoltarea business-ului. Ca un punct de vedere subiectv, se poate afirma că un expert în domeniu, poate aduce un plus de valoare în câteva zone cheie: • Îmbunătățirea procesului de definire a cerințelor (en.: requirements); • Alinierea priorităților proiectului utilizând cele mai bune practici în domeniu, precum și îmbunătățirea modelului de business prin capacitatea de înțelegere a celor mai bune practici în industrie; Articolul din numărul acesta acesta se va concentra asupra • Plasarea nevoilor utilizatorilor în centrul procesului, pentru celorlalte cinci trenduri. a avea un impact in ceea ce înseamnă strategia de livrare a unui produs (en.: product delivery/ product strategy); 6. Subject Matter Expertise (Dezvoltarea experților în dome• Scăderea costurilor pe proiecte. Experții în domeniu pot niu) livra sarcini mai repede și mai corect, costurile pentru proiect Un expert în domeniu este o persoană care posedă cunoștințe fiind mai mici. temeinice într-o anumită zonă în cazul de față cel tehnic și un bun specialist. Termenul de ”expert în domeniu” este frecvent De asemenea, un expert în domeniu nu ar trebui să fie legat utilizat mai ales în companiile IT și reprezintă o persoană ce are de o aplicație anume, deoarece aplicațiile se pot învăța mai ușor cunoștințe speciale și specifice sau competențe atât în zona de decât business-ul care stă în spatele lor.De aceea cu cât o persoană business cât și în zona de IT care să crească performanța în cadrul este mai expertă într-un anumit domeniu, cu atât e mai valoroasă

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE și poate aduce un plus semnificativ în compania în care lucrează.

7. Workforce planning processes (Dezvoltarea proceselor de planificare a forței de muncă)

Planificarea resurselor umane este procesul de bază în asigurarea pe termen lung a competențelor și aptitudinilor în rândul angajaților, necesare îndeplinirii obiectivelor strategice. Pentru ca planificarea să fie cât mai exactă se vor lua în considerare două variabile: contextul organizațional (mediul intern) și contextul pieței muncii (mediul extern). Procesul nu are neapărat un traseu liniar, care să înceapă cu strategia economică a întreprinderii și să parcurgă logic etapa planurilor de procurare a resurselor, cea a planurilor de flexibilizare și cea a planurilor de păstrare. Mai degrabă poate fi vazut ca un proces circular. De exemplu, planificarea pe bază de scenarii poate avea efect asupra strategiei de procurare, care la rândul ei, poate influența strategia economică. Planificarea resurselor umane este unul dintre rolurile strategice fundamentale ale proceselor de resurse umane, care poate să vină cu o contribuție majoră la dezvoltarea capabilității de resurse umane a organizației și, prin urmare, la dezvoltarea capabilității strategice a acesteia, prin revizuirea sistematică a obiectivelor strategice ale firmei. Obiectivul planificării resursei umane: este de a evita lipsa sau surplusul de resurse umane în cadrul companiei și de a asigura competențele și abilitățile potrivite la locul potrivit și la momentul potrivit. Aș prezenta planificarea resursei umane într-un proces integrat, care cuprinde șapte pași. • Pașii 1 și 2: urmăresc înțelegerea obiectivelor și strategiei organizației, pentru a identifica nevoile companiei. • Pasul 3: presupune evaluarea organigramei curente și a resurselor prezente. Pentru aceasta este nevoie de actualizarea organigramei și a fișelor de post, din punctul de vedere al responsabilităților, competențelor și abilităților. • Pașii 4 și 5: pentru o bună planificare/ organizare/programare a resursei umane, este necesară utilizarea planurilor de succesiune, pentru a putea previziona eventualele demisii, promovări în cadrul companiei. De asemenea se evaluează rata de retenție a angajaților și motivele pentru care aceștia părăresc organizația. • Pasul 6: strategia de dezvoltare a companiei, va evidenția o discrepanță

între nevoile existente în companie și nevoile viitoare. Pentru o bună planificare a resursei umane, se vor crea profilele angajațiilor care se doresc a fi recrutați și se compară dacă abilitățile și competențele căutate pot fi găsite în interiorul sau exteriorul companiei. • Pasul 7: dezvoltarea strategiei de resurse umane, luând în considerare cei șase pași enumerați anterior.

8. Leadership development (Dezvoltarea abilităților de leadership)

Într-un ar ticol anterior despre importanța dezvoltării abilităților de leadership într-o companie, afirmam atunci că există patru categorii de competențe care ar trebui cultivate de către fiecare lider în parte: • Orientarea către oameni (People leadership) care pune accentul pe capacitatea individului de a comunica, de a-i coordona pe ceilalți și de a lucra la rândul său într-o echipă. • Leadership personal (Personal leadership) capacitatea de a se adapta la situații și medii noi și nu în ultimul rând inteligența emoțională. • Orientarea spre rezultate (Results Leadership) exemplifică capabilitatea angajatului de a-și îndeplini obiectivele și sarcinile, precum și capacitatea acestuia de a lua o decizie responsabilă în timp util. • L ead e r ship analiti c ( T houg ht Leadership) capacitatea de a înțele mediul de business și organizația în care activează și poate indentifica în același timp viitoare tendințe ale mediului extern și intern.

• Retenția angajaților - ce creează un nivel ridicat de angajament și de retenție? • Analiza abilităților de leadership care sunt liderii cei mai de succes și care este procesul de dezvoltare a abilităților lor? • Acoperirea unor diferențe între abilitățile care există în companie și cele care trebuie dezvoltate – cum ar trebui aceste lacune previzionate și ce măsuri se pot întreprinde pentru a le acoperi? • Pipeline de candidați - cum putem mai bine atrage și selecta oameni care știm că vor reuși în cadrul organizației?

10. Innovation (Inovație în departamentul de HR)

Departamentul de resurse umane, ar trebui să gândească mai mult ”în afara cutiei ”, atât în ceea ce privește procesele, dar și în ceea ce privește adaptarea la nevoile business-ului. Cred că HR-ul de pe piața din România, ar trebui să fie din ce în ce mai concentrat și pe implementarea de bune practici în domeniu. Este îmbucurător progresul unor companii care au trecut de la ”personal” care se ocupa doar cu partea administrativă și tot ce însemna angajarea la ”talent management” – sintagmă care semnifică o abordare a angajatului ca deținător de talente care trebuie descoperite și dezvoltate. Inovația în departamentul de HR ar trebui să vină și din abordarea mai informală și printr-o apropiere de angajați și management. HR-ul să devină un bun mediator. Pe lângă abordare consider relevantă și aducerea unui dram de creativitate în implementarea unor procese, adoptarea chiar a unor metodologii de lucru în funcție de domeniul de activitate al fiecărei companii. Am susținut 9. Talent Analytics (Analiza datelor si a în articole anterioare cât de important este surselor de obținere a lor) ca HR-ul să devină AGILE, pentru a răsMajoritatea companiilor au o mulțime punde eficient și eficace atât nevoilor de de date despre resursele umane, fie că vor- business cât și nevoilor angajaților. bim despre date demografice, evaluări de performanță, fie despre studii formale și Succes Maxim ! informale, dar de cele mai multe ori nu știu cum să fie folosite, pentru că sistemele de resurse umane fie sunt prea vechi, fie nu există. Un alt factor care influențează analiza datelor este și nevoia de competențe în analiza de date și realizarea statisticilor. Cei mai mulți profesioniști de resurse umane nu au încă aceste aptitudini, astfel încât companiile trebuie să-i găsească pe acești oameni și să îi aducă împreună Andreea Pârvu andreea.parvu@endava.com pentru a extrage cât mai multe informații relevante. Este un moment oportun în care Senior Recruiter @ Endava profesioniștii de resurse umane să se concentreze pe analiza unor aspecte esențiale: www.todaysoftmag.ro | nr. 22/Aprilie, 2014

programare

Perspective asupra principiilor în design-ul orientat pe obiecte

efiniția entropiei pe care cu siguranță am auzit-o cu toții nu lasă loc de interpretare: cu cât entropia este mai mare cu atât dezordinea și haosul încep să îsi facă de cap. Acest lucru înseamnă impredictibilitate care nu se numără cu siguranță printre calitățile dorite ale unui design bun. Cu toate acestea, după cum vom vedea în cele ce urmează, o entropie mare (si aici mă refer la entropia Shannon și nu la versiunea sa termodinamică, deși există similitudini între cele două) nu este defectul principal al unui design prost. De fapt, folosind ca reper doar entropia design-ului în ansamblul, nu suntem în măsură să spunem foarte multe despre acel design, putem spune de exemplu că el rezolvă o anumită problemă care are nevoie de un anumit număr de stări. Poate părea contraintuitiv, dar pentru a obține un design bun clasele care moștenesc alte clase trebuie să aibă o entropie mai mare decât cea a claselor de bază, orice încercare de a reduce entropia într-o clasă derivată va duce în general la situații de strong-coupling și la un comportament ciudat, în general complicat și nedorit. S copul acestui ar ticol este s ă studieze modul în care principiile binecunoscute de OOD (Object Oriented Design) influențează entropia locală a designului. Voi începe cu Principiul Substituției Liskov (LSP) pentru că influența entropiei este observabilă într-un mod clar și p ermite exemplif icări concrete. În câteva cuvinte, LSP este o regulă care ajută programatorii să decidă când anume o clasă poate să moștenească o altă clasă. Unul dintre cele mai cunoscute exemple de încalcare LSP este următorul: Imaginați-vă că ați creat o aplicație care gestionează dreptunghiuri. Aplicația are un success atât de mare încât utilizatorii solicită un nou feature pentru ca aplicația să poată gestiona și pătrate. Știind că un pătrat este un dreptunghi cu toate laturile egale, cea mai la îndemâna alegere de a extinde designul este să folosim moștenirea.Astfel, adăugăm o nouă

clasa numita Square care va moșteni clasa transferul in rețea. În cazul în care acestă Rectangle, în acest fel putem reutiliza toate observație nu vi se pare suprinzătoare, funcționalitățile deja implementate. aflați că o singură aruncare a unei monede (datul cu banul) are o entropie de un bit! class Rectangle Entropia măsoară cantitatea de informație { public: necesară pentru a reprezenta toate stările void SetWidth(double w) { unei variabile aleatoare. width = w; } Pentru cantități mici de informație double GetWidth() const { putem identifica reguli simple de reprereturn width; } zentare concisă a tuturor stărilor variabilei. void SetHeight(double h) { Însă în cazul haosulului sau al secvențelor height = h; } de numere aleatorii avem de a face cu double GetHeight() const { entropii uriașe, adevărate explozii de return height; } informație unde nu există reguli simple private: pentru a anticipa, de exemplu, următorul double height; double width; număr din secvență. }; [Vă oferim câteva detalii legate de asemăIn Square suprascriem SetWidth si nărea dintre entropia din termodinamică SetHeight pentru a ne asigura că cele patru și entropia Shannon. În final,ambele reprelaturi sunt egale. zintă de fapt același lucru. Imaginați-vă un container cu două lichide (unul alb și unul void Square::SetWidth(double w) { negru) separate de un perete. După îndeRectangle::SetWidth(w); părtarea peretelui lichidele se amestecă, prin Rectangle::SetHeight(w); } urmare entropia termodinamica crește. Din void Square::SetHeight(double h) punctul de vedere al teoriei informației, iden{ Rectangle::SetHeight(h); tificarea poziției fiecărei particule în raport Rectangle::SetWidth(h); cu poziția sa inițială față de peretele des} părtitor (la stânga sau la dreapta de acesta) Această alegere nu este una fericită necesită mult mai multă informație decât insă nu voi insista asupra motivelor cla- atunci când lichidele nu sunt amestecate.] sice1. Vă voi arăta însă o altă perspectivă Există, de asemenea, o definiție și a implicațiilor acestei alegeri de extindere o formulă pentru calculul entropiei: a design-ului, din punctul de vedere al Pentru o variabilă aleatoare X cu n valori variației entropiei. posibile (x1, x2, x3…, xn) entropia Shannon Mai întâi, câteva cuvinte despre entro- (notata cu H (X)) se poate calcula după pie. Entropia Shannon este o măsură a formula: incertitudinii asociată unei variabile aleatoare și este de obicei măsurată în biți. Remarcați că este aceeași unitate de măsura folosită pentru a determina capacitatea memoriei sau lățimea de bandă pentru unde p(xi) reprezintă probabilitatea ca 1 o discuție interesantă despre acest subiect găsiți de variabila aleatoare să ia valoarea x . i exemplu pe site-ul Obiect Mentor al lui Robert Martin (http://www. objectmentor.com/resources/articles/lsp.pdf Să luăm câteva exemple în scopul de a

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE căpăta o înțelegere asupra a ceea ce repre- Știm de la primul exercițiu că entropia este zintă formula și de ce are sens să măsurăm egala cu 1 în acest caz. entropia în biți. [Mai exact, în funcție de baza logaritmului H(XS)=1 (bit) entropia este măsurată în biți (baza 2), nats (baza e) sau in bans (pentru baza 10)] E s te m om e ntu l s ă i d e nt i f i c ăm prima regulă a modului în care entroExemplul 1 pia trebuie să varieze într-un design: Cât de multă informație este necesară Ori de câte ori o clasă S (Square) pentru a stoca o variabilă aleatoare X care extinde o clasă R (Rectangle), este neceia valori în mulțimea {0, 1}? sar ca H(X S)>=H(X R). În cazul nostru Considerăm [Aceasta înseamnă ca 0 și 1 1=H(XS)<H(XR)=2 ! Ce se întâmplă de fapt au aceeași șansă, 50%, de a fi atribuite lui când încălcăm „regula entropiei”? X]. • Să presupunem că avem metoda (funcția) m care folosește obiecte de tip R. • În cazul în care clasa S extinde clasa R prin încălcarea regulii entropiei, atunci Exemplul 2 metoda m va trebui să plătească prețul Cât de multă informație este necesară entropiei lipsă din clasa S (a se citi strongpentru a stoca o variabilă aleatoare X care coupling, de exemplu un scenariu posibil ia valori în mulțimea {00, 01, 10, 11}? Luăm este adăugarea de if-uri prin care să se în considerare [Aceasta înseamnă discrimineze între Square și Rectangle). că toate valorile au aceeași șansă, 25%, de a fi atribuite lui X]. Formula ne spune că [Aici aspectul important este modul în care designul crește entropia, deoarece haos-ul și dezordinea din interiorul codului provine și din modul în care entropia este crescută, [Întrebați-vă dacă stiți definiția bitului. structurată și utilizată în cadrul claselor.] Definiția nu este evidentă însă fiecare programator crede că o cunoaște (este într-un Un exemplu din lumea reală fel amuzant când realizezi că poate nu ți-ai Putem exemplifica regula entropiei pus niciodată această întrebare)] folosind o ușă. Ce anume Dacă s-au mai clarificat lucrurile în face o ușă? Care este comprivința entropiei, e important să vedem portamentul ei? Evident cum se aplică ea în analiza design-ului. o ușă se deschide (dacă Pentru început, vom încerca să răspundem nu cumva este blocată) și la o întrebarea: Cât de mare este entropia folosește interiorul unei clasei Rectangle? Analizăm domeniul în camere pentru a face acest care ia valori, mai precis combinațiile posi- lucru. Iată un mod simplu de a scrie aceasta bile de lățime și înălțime. Vom folosi un caz în cod: simplificat în care acestea pot lua numai class Door valorile 0 și 1. Se pare că putem defini clasa { void Open(Room r) Rectangle ca o variabilă aleatoare XR={wh}, { XR cu valori în multimea {00, 01, 10, 11} …. the door opens inside the room } fiecare valoare reprezentând o combinație } de lățime (w) și înălțime (h). Din exemplul anterior știm că entropia unei astfel de variImaginați-vă că entropia camerei este abile aleatoare este egală cu 2. proporțională cu volumul său. Ce s-ar întâmpla dacă am extinde clasa Room H(XR)=2 (biți) prin reducerea entropiei (a volumului)? Să numim această nouă clasa FakeRoom. Cât de mare este entropia clasei Square? Ei bine ... următoarea imagine vorbește de Observăm domeniul în care iau valori la sine. lățimea și înălțimea în cazul simplificat cu Informația (entropia) lipsă din noua valorile permise 0 și 1. De asemenea, putem camera ajunge să fie codificată în ușă (pardefini clasa Square ca o variabilă aleatoare tea de jos a fost decupată pentru a se putea XS={wh}, XS. În acest caz însă, entropia este deschide). Acum ușa și camera sunt cuplate diferită, deoarece lățimea și înălțimea nu (strong-coupling). Nu vom mai putea utiliza mai variază în mod independent. De fie- această ușă la o altă cameră fără a ridica care dată când este setată lățimea (w) este semne de intrebare! setată și înălțimea (h) cu aceeași valoare. [Dezvoltatorii trebuie să înțeleagă că

designul lor va arăta la fel ca sistemul din această imagine sfatul meu fiind să nu ignore aceste semne, vaza si florile nu sunt suficiente pentru a-l transforma într-un design bun.] [Ne putem imagina un alt doilea exemplu, cu o pompă de apă si țevi de diferite dimensiuni.]

Concluzii

1. Scăderea entropiei prin utilizarea moștenirii este un semn de încălcare a încapsulării unei clase. 2. Agregarea este recomandată în locul moștenirii. Nu există o modalitate de a încălca regula entropiei atunci când se utilizează agregarea. Entropia poate fi variată după dorință. 3. Să depinzi de abstractizări este o practică recomandată pentru că interfațele nu au o limită inferioară a entropiei. 4. Matematicienii ar spune despre regula entropiei că este necesară dar nu și suficientă pentru a semnala o încălcare a LSP în sensul că, dacă ne supunem regulii am putea obține un design bun, în timp ce dacă încălcăm regula acest lucru duce cu siguranță la un design prost. 5. Entropia design-ului este o perspectivă care poate îmbunătăți metodele deja existente de detectare a încălcării LSP.

Cătălin Tudor

ctudor@ixiacom.com Principal Software Engineer @ Ixia

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

programare

Machine learning in the cloud

nul dintre factorii cei mai importanți în explozia învățării automate în ultimii zece ani a fost puterea crescută de calcul. În 2010, Dan Cireșan et al. au doborât recordul de recunoaștere de cifre scrise de mână, folosind un algoritm inventat prin anii 1980 și augmentând setul de date printr-un procedeu descris în 1990. Singura diferență a fost puterea de calcul: folosind o placă grafică modernă, ei au terminat antrenarea algoritmului într-o zi, pe când pe un CPU ar fi durat mai mult de 50 de zile. Dar odată cu creșterea puterii de calcul a procesoarelor, cantitatea de informație disponibilă a crescut și ea, chiar mai repede decât frecvența CPU-urilor. Pentru a face față situației, au apărut tot felul de soluții cloud, majoritatea oferite de startup-uri, care se specializează pe diferite nișe de învățare automată.

Printre primii care au oferit servicii de învățare automată în cloud au fost cei de la BigML, care sunt pe piață de aproape doi ani. Ei au început cu arbori de decizie și apoi au dezvoltat acest produs, oferind diferite îmbunătățiri, cum ar fi diverse strategii de fasonare și opțiunea de agregare a mai multor modele. Odată ce am antrenat un model, putem să îl vizualizăm prin două tipuri de diagrame, care ne ajută să vedem cum influențează fiecare trăsătură rezultatul dorit. Una din vizualizări este un Sunburst diagram pentru același model arbore interactiv pe care putem să urmăm decizia luată la fiecare nivel, iar cealaltă vizualizare este numită „Sunburst diagram”, care prezintă numărul de instanțe din datele de antrenare pe care este bazată fiecare decizie în parte, precum și intervalul de eroare pe care îl va avea rezultatul obținut mergând pe acea cale. Cei de la Ersatz labs sunt mai noi. Fiind în private beta deoServiciul poate fi folosit în două moduri: dintr-o interfață web camdată, ei plănuiesc să se deschidă publicului prin aprilie-mai. și dintr-un API HTTP.

Grafice pentru acuratețea și valoarea funcție de cost Vizualizarea arborelui de decizie pentru un model al notelor obținute de un student

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

Ei se specializează pe deep learning. Oferă diferite modele de rețele neuronale, se setează hiperparametrii lor și apoi se pornește antrenarea, pe care ei o efectuează pe GPU pentru a obține viteză

TODAY SOFTWARE MAGAZINE mai mare. Ei analizează datele pe care le încărcăm la ei și oferă o analiză euristică prin care sugerează ce valori ale hiperparametrilor se potrivesc cel mai bine datelor noastre. Cu câteva ajustări, am reușit să obțin în cinci minute un model care îmi recunoștea litere și cifre de pe bonuri cu o precizie de 80%. După ce se efectuează antrenarea, putem vedea statistici legate de modul în care a evoluat acuratețea, valoarea funcției de cost și valorile maxime ale ponderilor rețelei neuronale de-a lungul iterațiilor. Apoi, bazându-ne pe acestea, putem să decidem cum să continuăm, în ce direcții să mai ajustăm hiperparametrii.

suficient de generale ca să funcționeze în orice domeniu. Problema apare când vrem să folosim o limbă care nu este bine integrată, ca de exemplu româna, la care deocamdată serviciul pur și simplu nu știe ce să răspundă. AlchemyAPI poate fi folosit prin intermediul unor SDK-uri oferite de ei pentru diferite limbaje, cum ar fi Python, PHP, Node. js, C++, Java, C#, care apoi pot fi integrate în aplicațiile noastre.

Deși invite-urile pentru beta se primesc de obicei în aceeași zi, trebuie ținut cont de faptul că încă este în beta. Când am testat servicul, pe primul set de date pe care l-am încercat am întâmpinat o eroare misterioasă, „Training failed”. Apoi persoana de la suport tehnic a informat că a fost descoperit un bug în Pylearn2, librărie pe care o folosesc ei în spate pentru definirea modelelor de rețele neuronale. Au fost destul de prompți în rezolvarea acelui bug, dar tot am mai întâlnit chestii care nu prea aveau sens. Modelele pe care le oferă deocamdată sunt autoencoder-e pentru date sub formă de imagini, rețele recurente pentru date temporale, rețele neuronale cu straturi sigmoide sau ReLU și rețele neuronale convoluționale cu sau fără maxout.

Entități găsite de AlchemyAPI într-un post des-

PredictionIO este un pic diferit față de celelalte produse din această listă. Deși este dezvoltat de o firmă, TappingStone, care oferă suport comercial pentru el, produsul în sine este distribuit în mod liber, fiind pus pe GitHub cu o licență open-source. PredictionIO este un engine de recomandare, construit pe tehnologii scalabile, cum ar fi MongoDB și Hadoop. Acesta permite ca, având un istoric al acțiunilor efectuate de un utilizator (vizionarea, cumpărarea sau acordarea unei note unui produs), să îi sugerăm alte produse care l-ar interesa. Engine-ul are două componente. Prima este o interfață web de management al algoritmilor pe care îi folosim. De aici putem selecta ce algoritmi vrem să folosim, care sunt parametrii acestora și putem să rulăm evaluări simulate. Cealaltă parte este un API HTTP (cu SDK-uri pentru diferite limbaje) prin care putem să adăugăm user-i, produse, acțiuni și apoi să obținem recomandări. Faptul că este bazat pe MongoDB și pe Hadoop oferă o putere destul de mare la PredictionIO, dar în același timp face ca să fie și mai complicat. În momentul în care vrei să schimbi setup-ul de Hadoop cu care vine în mod normal, care rulează pe o singură mașină totul și să îl faci să ruleze pe un cluster, deja trebuie să te descurci cu Hadoop, pe când la celelalte servicii menționate, când ai nevoie de mai multă putere de procesare, doar faci un click în browser (și plătești mai mult). AlchemyAPI oferă și ei servicii de deep learning, dar la un nivel mult mai înalt decât cei de la Ersatz. În loc de a-ți oferi posibilitatea de a antrena rețele neuronale pe orice fel de date dorești, ei s-au specializat pe procesarea de limbaj natural și oferă doar un API prin care se pot extrage entitățile menționate în text, cuvintele cheie, sentimentele exprimate despre diferite lucruri, autori, limba și alte atribute ale textului. Ei nu oferă prea multe la nivel de customizare, mare parte din serviciu fiind gata făcut deja. Atâta timp cât ne limităm la limbile pentru care au suport, nu vom avea probleme, problemele de extragere de entități, cuvinte cheie, autor sau sentimente fiind

pre noul limbaj al lui Stephen Wolfram

Acestea sunt doar câteva din serviciile de învățare automată în cloud. Mai sunt altele, cum ar fi Google Prediction API (care este complet închis și nu se știe exact ce algoritmi folosesc pentru predicții), sau ŷhat, care este la latura complet opusă, oferind un framework în care noi trebuie să integrăm ce algoritm de învățare automată dorim.

Roland Szabo

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

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

programare

Dezvoltare rapidă de aplicații web cu Oracle APEX

ți dorit vreodată să dezvoltați o aplicație web foarte rapid, fără să fiți nevoiți să învățați un nou limbaj de programare? V-ați întrebat de ce este încă dificil să creați pagini web cu formulare și rapoarte și de ce fiecare tool de Rapid Application Development devine „rapid” doar după ce investiţi câteva luni pentru a-l învăţa?

Aflați că există un produs trecut cu vederea numit Oracle Application Express (APEX) care ar putea să fie răspunsul pentru dezvoltatorii „one-off ” de aplicaţii web, cei de baze de date, dar şi programatorii experimentaţi. Folosind un mediu de dezvoltare declarativ, puteţi construi aplicaţii web profesioniste cu o abordare click-and-click. Surpriza vine din faptul că acest tool este dezvoltat de Oracle, o corporaţie renumită pentru produsele sale scumpe şi exclusiviste. APEX este un tool gratis (dar nu open source) care s-a născut dintr-un proiect intern al Oracle menit să facă facă mai uşoară viaţa programatorilor şi administratorilor de baze de date. Experienţa mea cu APEX a început în anul 2009, pe când lucram ca Oracle database developer la o companie specializată în asigurări de viaţă. Principalul task era integrarea mai multor sisteme software, atât interne cât şi folosite de clienţi. Partea bună era că toate componentele software foloseau Oracle ca baze de date; partea proastă era că nu aveam la dispoziţie suficient timp şi resurse umane pentru a dezvolta interfeţele între sisteme în Java, .NET, PHP sau alt limbaj de programare sau framework. Managerul de dezvoltare avea puţină experienţă la început cu APEX, însă avea mare încredere în capacităţile acestui tool. Aşa a început o experienţă intensivă cu APEX 3.2 pe durata a trei ani, într-un moment când documentaţia era puţină, iar experţii în domeniu şi entuziaştii APEX puteau fi număraţi pe degete. Rezultatul a fost o experienţă de software development unică, multă documentaţie scrisă, guide-uri şi whitepapers create pe parcurs precum şi o carte publicată în 2013 cu titlul „Oracle APEX Reporting Tips & Tricks” (disponibilă pe Amayon, iBookStore şi Barnes and Noble). Oracle Application Express, cunoscut ca APEX, este tool de Rapid Application Development (RAD) care a atins un nivel de maturitate o dată cu lansarea versiuniii 4.0 în iunie 2010. APEX combină ciclurile de dezvoltare rapidă pentru aplicaţii web, în jurul unei baze de date Oracle, cu o comunitate de programatori specializaţi în creştere şi evanghelişti dedicaţi care promovează această tehnologie. Tehnica de programare este foarte declarativă şi se desfăşoară într-un mediu web-based, investind un efort de codare minim. APEX foloseşte un concept unic care poate fi considerat opusul trendurilor actuale din dezvoltare aplicaţiilor web. În timp ce acum majoritatea aplicaţiilor web ar trebui să fie cuplate cât mai „loose” de bazele de date din backend, cu o emfază pe interacţiunea client-side, APEX are o abordare radicală, în care totul este stocat în bazele de date, de la datele până la meta-datele folosite pentru generarea paginilor web. Un web server al RDBMS-ului

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

Oracle este folosit pentru a genera pagini HTML direct din baza de date, unde atât datele folosite de aplicaţie cât şi meta-datele care descriu paginile aplicaţiilor. Cu toate că APEX este un produs gratis, acesta funcţionează doar cu bazele de date Oracle, marea parte a procesărilor de backend, dar şi frontend fiind realizate de procedurile stocate. O aplicaţie web Oracle APEX este dezvoltată folosindu-se SQL şi PL-SQL, cu toate că marea parte a efortului de codare poate fi realizat într-un mod declarativ, folosind interfaţa de dezvoltate din web browser. APEX este un tool database-centric, adică necesită şi rulează doar cu o bază de date Oracle. Istoria APEX începe în anul 2004, pe când era doar un tool intern al Oracle numit HTML DB. În 2006 a fost redenumit în Oracle Application Express (versiunea 2.1). În acest moment versiunea stabilă este 4.2.4 şi deja este lansată şi versiunea early adopter 5.0 (https://apexea.oracle. com/i/index.html). Pentru a utiliza APEX în cadrul unei instanţe a unei baze de date Oracle, chiar şi cu varianta free de baze de date Oracle XE, nu este nevoie de licensing adiţional, pentru că numărul de developeri, aplicaţii şi end-users nu este restricţionat. Suportă toate versiunile de baze de date Oracle începând cu 10gR2 şi poate fi folosit şi cu setup-uri Exadata, ORA şi RAC. În mod implicit, Oracle APEX este distribuit cu toate ediţiile bazelor de date Oracle. Din punct de vedere arhitectural, APEX foloseşte o arhitectură simplă de tip 2-tier. Paginile web sunt generate dinamic folosindu-se metadata stocată în baza de date şi nu se generează cod compilabil sub forma unor fişiere. De fapt, APEX rulează o dată cu baza de date. APEX foloseşte un principiu de multitenant hosting, organizând paginile web în aplicaţii şi workspace-uri, care pot folosi la rândul lor baze de date distincte sau shared.

Cu toate că marea partea a codului din spate este scris în PLSQL, pentru a începe să lucrezi cu APEX nu ai nevoie de

TODAY SOFTWARE MAGAZINE cunoştinţe avansate de programare, cu excepţia unor elemente de HTML. Fiind un tool web-based, procesul de development consistă dintr-o serie de pagini şi obiecte predefinite, de la formulare şi rapoarte până la grafice. Toate paginile şi componentele sunt stocate în obiecte din baza de date Oracle, de obicei tabele şi view-uri, aşa că este pus la dispoziţie şi un tool de management a schemei bazei de date. Crearea de tabele, views şi proceduri stocate se poate face direct în APEX, aşa încât întregul proces de dezvoltare se face în acelaşi environment, cel de dezvoltare web-based. APEX se poate accesa prin intermediul unui URL într-un browser web, fie că folosiţi o instanţă instalată local, o instanţă de private cloud (SaaS) sau serviciul Oracle Database Cloud Service, produsul cloud al Oracle care foloseşte APEX pentru dezvoltare de aplicaţii web (http://cloud.oracle.com). Cu toate acestea, Oracle APEX nu este un tool care este potrivit oricărui proiect. Cazurile tipice unde APEX poate fi folosit sunt cele de aplicaţii data-driven (aplic aţii de productivitate la nivel de department sau aplicaţii ad-hoc), reporting online bazat de queryuri SQL, transformarea spreadsheet-urilor Excel sau de alt tip în aplicaţii web sau pentru centralizarea acesului la date (unde APEX se poate fi folosit ca un central point of access pentru scheme multiple într-una sau mai multe baze de date Oracle).

Administration, pentru administrarea contului, a workspaceurilor şi a dashbord-urilor. Ca majoritate uneltelor RAD, Oracle APEX facilitează dezvoltarea de aplicaţii într-un mod declarativ, folosind item-uri de pagini web deja existente cum ar fi: rapoarte, formulare, grafice, calendare, template-uri de UI, navigaţie, validări, procese de pagină şi aplicaţie, servicii web, servicii de e-mail şi localizare (traducere), autentificare, autorizare, logging şi monitorizare. Pentru mai multe detalii legate de dezvoltare aplicaţiilor APEX, puteţi achiziţiona cartea “Oracle APEX Reporting Tips&Tricks”: http://www.apexninjas.com/blog/2013/06/ oracle-apex-reporting-tips-tricks-out-now/ De asemenea, puteţi încerca o aplicaţie simplă de blogging dezvoltată integral în APEX aici: http://apex.oracle.com/pls/ apex/f?p=20559:101:

Principalele componente ale mediului de dezvoltare APEX sunt: Application Builder, unde sunt construite paginile şi aplicaţiile web în mod declarativ prin folosirea unor wizzards. Fiecare aplicaţie este compusă din una sau mai multe pagini, fiecare pagină este împărţită în regiuni. Fiecare regiune a unei pagini poate să conţină test, cod PLSQL, rapoarte, grafice, hărţi, calendare, formulare sau rezultate aduse prin intermediul unor servicii web. De asemenea sunt disponibile obiecte care sunt specifice nu doar paginilor, ci intregii aplicații, cum ar fi application items, processes, computations, scheme de autentificare și autorizare sau obiecte de navigare ca tabs, lists sau breadcrumbs. SQL Workshop, un tool care permite managementul obiectelor din baza de date Oracle. Query-uri SQL ad-hoc, wizards pentru crearea de tabele, view-uri, proceduri stocate şi alte obiecte de baze de date pot fi utilizate de developer pentru a face management-ul schemei Oracle din acest tool browser- based. Team Development, o unealtă de team management pentru development pentru urmărirea feature-urilor, bugs şi milestones. Acest tool este legat direct de paginile APEX.

George Bara

gbara@sdl.com Business Consultant @ SDL

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

prezentare

O viziune din interiorul GPS Navigație

n articolul de față ne propunem să oferim o viziune de ansamblu asupra evoluției aplicației de navigație pe platforma de iOS, abordată din punct de vedere al dezvoltatorilor. De asemenea, vor fi analizate și funcționalitățile, arhitectura și inovațiile ce se regăsesc în versiunea 5.0, disponibilă în AppStore din decembrie 2013.

GPS Navigație a fost lansat pentru prima dată în octombrie 2009. În acea perioadă, Skobbler a fost prima companie care a folosit hărțile OpenStreetMap, dezvoltate de o mică comunitate de entuziaști. Aplicația oferea navigație pas cu pas cu condiția unei conexiuni permanente la internet. După aproape doi ani de update-uri și îmbunătățiri regulate, 1.5 milioane de utilizatori foloseau aplicația. Pe lângă calitatea oferită de funcționalitățile existente, era nevoie de ceva nou. Axându-ne pe nevoile utilizatorilor, am decis că sunt necesare navigarea offline și schimbarea radicală a designului. Noul produs a fost lansat în octombrie 2011. Aplicația era singura din industrie care oferea funcționalitate online-offline (“hibridă”) – instalabilă pe iPhone și iPaduri echipate cu suport 3G. Ne-am concent rat atenț i a asupra utilizatorilor și elementelor de UI/ UX, rezolvând și problema aplicațiilor tradiționale de navigație care necesită cost ridicat de roaming și descărcarea pachetelor mari de date. Soluția oferită de noi a fost o interfață simplă, intuitivă, adaptată la mediul de utilizare a navigației în trafic.

Am dezvoltat două prototipuri cu elemente diferite de UI. Primul se axa mai mult pe un model de meniu tradițional, pe când cel de-al doilea aborda o direcție

complet nouă, diferențiată prin paleta de Setul de funcționalități ale versiunii culori folosită și poziționarea butoanelor. curente include următoarele: Pentru început am testat aplicația la Stilurile de hartă – stilurile custominivel intern, iar feedback-ul echipei a gene- zabile permit utilizatorilor să modifice rat îmbunătățiri ale produsului final. “skin-ul” hărții în funcție de vreme sau timp. Stilurile de hartă disponibile sunt – stilul de zi-noapte, gray scale și stilul exterior. Pentru modul de navigație există stilul adițional de atenționare radare. Funcționalitatea offline – aplicația oferă opțiunea de a cumpăra și desDupă o perioadă îndelungată de dez- c ărc a p achete de voltare și testare, produsul final a fost lansat hărți pentru țări și pe AppStore. Noul UI inserat în aplicație a orașe, oferind acces contribuit la dublarea numărului de utiliza- la navigație, afișare tori în primele săptămâni de după lansare. hartă, rutare și căutare fără conexiune la internet. Căutarea online cât și offline utilizează serviciile Apple pentru căutarea adreselor și Tripadvisor, iar pentru puncte de interes (POI) utilizează motorul de căutare skobbler. Fără o conexiune la internet căutarea se bazează pe serviciile Skobbler precum căutarea pas cu pas pentru adrese și căutarea de POI-uri Următorul update major – GPS pe categorii. Navigație 5.0 – a fost făcut în decembrie Ghidul de călătorie – bazat pe 2013. Noutățile acestei lansări au fost sti- conținutul Wikitravel, utilizatorii au acces lurile noi și funcționalitate Tripadvisor. la articole despre țări, orașe și POI-uri Aplicația a primit 4 stele și jumătate pe afișate pe hartă. Articolele individuale sunt AppStore-ul din Germania și are în prezent disponibile atât online cât și offline. peste 4 milioane de utilizatori. Navigație și modul free-drive (radar) – Echipat cu iOS SDK care oferă navigația poate fi începută pe o rută deja funcționalitați de navigație și mapare, calculată, oferind utilizatorului informații aplicația folosește hărțile skobbler (cunos- referitoare la destinație, durata estimată, cute și sub denumirea de hărți OSM+) numele străzilor, direcții și distanțe, ghibazate pe date OSM. Datele extrase din dare vocală, viteză curentă, limită de viteză OSM trec printr-un process de analiză și și avertizări de depășire a vitezei. îmbunătățire și sunt compilate de către Modul free-drive poate fi folosit fără skobbler în propriul format. a avea o destinație specifică. Acesta oferă

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE un mod de vizualizare 2D și 3D, detecție de radare și informații referitoare la strada curentă.

Volumul de date colectat este aproximativ de 7 milioane kilometri pe zi.

Arhitectura proiectului

Radare – baza de date pentru detecția radarelor este la zi, radarele fixe sunt actualizate zilnic, în timp ce radarele mobile sunt actualizate la intervale de 5 minute. Serviciul de detecție al radarelor fixe este gratuit, în timp ce opțiunea detecție radare mobile este accesibilă ca serviciu premium. FCD (floating car data) - aplicația utilizată zilnic de către milioane de utilizatori colectează un număr mare de date FCD. Informația referitoare la rețeaua de drumuri, viteză, direcție, timp sunt folosite pentru a îmbunătăți hărțile OSM+.

Aplicația GPS Navigație are la bază tehnologia NGx a skobbler și iOS SDK. Secțiunea curentă oferă o imaine de ansamblu asupra arhitecturii proiectului și componentelor acestuia. OSM+ - oferă hărțile necesare pentru randare, rutare și navigare. Componenta core – o componentă C++ crossplatform responsabilă pentru randarea hărților (Open GL), rutare, navigare, căutare. iOS SDK – un layer objective C++ (similar cu MapKit oferit de Appla). Acesta asigură integrarea setului de funcționalități suportate de către component Core în aplicația nativă iOS. Clientul iOS – interfață utilizator native iOS construită în jurul iOS SDK.

Echipa iOS @ Skobbler

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

IMAGINE – studiu al IT-ul clujean

cest articol prezintă rezultatele unui studiu privind percepţia studenţilor asupra a zece firme de IT, mai cunoscute din Cluj. Fiind foarte probabil viitori angajaţi în aceste firme, percepţiile lor (evident subiective) pot să ajute firmele de IT să îşi reconsidere politicile de atragere de candidaţi, atât pentru politicile de HR, cât şi pentru cele de PR. Astfel, îşi pot defini mai bine şi locul în comunitatea IT locală. Ca firmǎ de consultanţǎ în Dezvoltare Organizaţionalǎ şi Managerialǎ, care a lucrat cu mai multe firme de IT din Cluj, am dorit sǎ aflǎm mai multe despre aceastǎ industrie. De o bunǎ perioadă de timp se vorbeşte despre IT Cluster-ul din Cluj care doreşte sǎ dezvolte o realǎ comunitate de afaceri în acest domeniu. Dar cum este aceastǎ comunitate? Din cine este formatǎ şi care sunt legǎturile dintre principalii actori? Cu ce probleme se confruntǎ şi cum pot fi rezolvate acestea? Anul trecut am fǎcut o cercetare, pe baza discuţiilor cu oameni de HR din IT-ul clujean, ca sǎ vedem cum au evoluat firmele, care sunt principalele provocǎri ale momentului şi cum se vede ideea de comunitate IT. Am publicat concluziile discuţiilor în numerele 13, 15, 16, 19 din TSM. Atunci a rezultat, de departe, cea mai mare problemǎ cu care se confruntǎ firmele de IT din Cluj : lipsa personalului calificat care sǎ stea la baza creşterii doritǎ de patroni sau prea puţini absolvenţi de specialitate faţǎ de nevoile în creştere. S-au încercat diverse soluţii, susţinute de firme – reconversia profesionalǎ a unor posibili angajaţi care sǎ uite vechea pregǎtire profesionalǎ (mult mai slab plǎtitǎ) şi sǎ înveţe sǎ programeze; aducerea de profesionişti buni din alte localitǎţi sau deschiderea de filiale prin ţarǎ (de obicei unde existǎ universitǎţi); chiar includerea elevilor în programe care vizau atragerea lor ca angajaţi. Şi totuşi, problema rǎmâne – o luptǎ durǎ pentru împǎrţirea resursei umane. Iar pentru aceasta firmele au fǎcut o serie de acţiuni legate de vizibilitate sau climat de lucru. Noi am fost interesaţi, de data aceasta, sǎ vedem ce pǎreri au tocmai aceia pentru care se duce lupta: viitorii angajaţi. Ce

imagine au ei despre firmele posibil angajatoare? Ce ştiu despre acestea (este vorba despe percepţia lor - nu despre o realitate greu de definit – care îi va determina sǎ facǎ o alegere în viitor). Pentru studiul realizat de firma noastrǎ ne-am consultat cu cadre didactice din UBB, cu competenţe în domeniul sociologiei şi a managementului. Pentru construirea chestionarului s-a ţinut seama şi de opiniile unor angajaţi din firme IT (mai nou angajaţi sau cu mai multǎ experienţǎ), oameni de HR, respectiv patroni din firme IT.

Metodologie.

Prima decizie a fost legatǎ de participanţii la studiu. S-a convenit ca aceştia sǎ fie dintre studenţii la Calculatoare sau Automatizǎri (UTCN), respectiv Informaticǎ (UBB), indiferent de predarea în limba românǎ sau englezǎ. Acesta reprezintǎ, de departe, cel mai vizat sector de interes pentru angajare în IT, chiar dacǎ nu e singurul. Apoi am ales anul de pregǎtire al studenţilor. Am considerat cǎ cei din anul I sunt încǎ destul de puţin cunoscǎtori privind firmele din Cluj, iar cei din anii superiori, foarte mulţi, deja lucreazǎ şi pǎrerea lor poate fi influențată de prezentul loc de muncǎ. Aşa cǎ am ales sudenţii din anul II (deja în semestrul doi). A urmat alegerea firmelor care sǎ fie studiate. Am folosit douǎ criterii care sǎ creascǎ şansa cunoaşterii lor de cǎtre studenţi: mǎrimea firmei (numǎr de angajaţi) şi vechimea acesteia în Cluj. În final, 10 firme au fost selectate: 1. AROBS 2. EBS 3. ENDAVA

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

4. EVOLINE 5. EVOZON 6. FORTECH 7. ISDC 8. IQUEST 9. SOFTVISION 10. YONDER Urmǎtorul pas a fost alegerea unor cuvinte care sǎ poatǎ descrie oricare/toate firmele din industrie. I-am numit descriptori şi i-am ales dupǎ mai multe discuţii cu persoane din firme de IT. I-am rugat pe respondenţi sǎ aleagǎ maxim trei descriptori, dintre cei 13 posibili, din dorinţa de a vedea rezultate polarizate – principalele caracteristici ale firmelor, vǎzute de studenţi. Aceşti descriptori au fost: 1. Oferă multă instruire 2. Secretoşi 3. Mediu foarte plăcut 4. Interesaţi doar de bani 5. Stabili pe piaţă 6. Pretenţioşi 7. Proiecte complexe 8. Au angajaţi valoroşi 9. Foarte flexibili 10. Plătesc bine 11. Au produse proprii 12. Fac mult outsourcing 13. Aroganţi În final am realizat un chestionar cu douǎ pǎrţi principale. În prima parte, respondenţii trebuiau sǎ spunǎ dacǎ cunosc sau nu fiecare dintre cele 10 firme. În a doua parte trebuiau sǎ exprime opinii despre firmele pe care le cunosc, pe baza descriptorilor amintiţi. Au mai fost adǎugate câteva întrebǎri informative: facultatea la care sunt studenţii, genul respondentului, adresa de e-mail pentru

TODAY SOFTWARE MAGAZINE

trimiterea informaţiilor finale. Cum s-a întâmplat! În perioada 26 februarie – 3 martie 2014 au rǎspuns la chestionar 400 de studenţi de la facultǎţile vizate, ceea ce ne face sǎ considerǎm opiniile relevante statistic. Pe aceastǎ cale, dorim sǎ le mulţumim studenţilor şi profesorilor care ne-au facilitat obţinerea rǎspunsurilor. Fiecare firmă inclusă în studiu a primit un raport cu detalii despre percepţia studenţilor privind respectiva firmă, ceea ce le permite să vadă cum se raportează fiecare la concurenţă. În prezentul articol nu vom corela răspunsurile primite cu numele unor firme, pentru păstrarea confidenţialităţii, dar sperăm că, analizând comparativ datele, fiecare firmă va reuşi să-şi îmbunătăţească politicile de recrutare sau de PR. Scopul nostru a fost să fim de folos şi orice feedback este binevenit.

Despre rezultate!

Pentru ca firmele să îşi atragă candidaţi pentru recrutare, este important ca aceştia să le cunoască. De aceea, prima întrebare a fost dacă respondenţii cunosc (cât de cât) firmele de IT. Răspunsurile lor au fost distribuite pe o plajă destul de largă, de la 25,3% până la 80,2%. Fiindcă, practic, toate aceste firme de IT au planuri de a-şi crea o notorietate cât mai mare şi ţinând cont că majoritatea sunt firme vechi şi/sau mari, scoruri de 25-30% sunt, după părerea noastră, destul de mici. Probabil că strategia de imagine, marketing, sau PR ar trebui revăzută. Rezultatele privind descriptorii, aşa cum au fost aleşi de către studenţi, relevă diferenţe de percepţie. Media sau mediana rezultatelor nu credem că este foarte relevantă. Este interesant de văzut scorurile comparative dintre firme – aceasta dă

o imagine mai clară despre cum se poziţionează firma, în percepţia subiectivă a studenţilor, faţă de concurenţă. Rezultatele sintetice sunt prezentate în tabelul următor (am avut grijă ca ordinea firmelor în tabel să nu fie alfabetică, deci e imposibil de ghicit scorul fiecărei firme; pentru firmele interesate avem mai multe detalii, fără să deconspirăm identitatea fiecăreia). Am marcat scorurile maxime pentru a se vedea mai bine diferenţele. În multe cazuri, raportul percepţiilor depăşeşte raportul 2:1; în cazul percepţiei despre Aroganţă raportul depăşeşte 8,5:1, chiar dacă notele totale sunt relativ mici. Studenţii percep aproximativ la fel firmele ca făcând outsourcing (3,9-5,6%). O firmă iese în evidenţă, fiind percepută de către respondenţi ca având produse proprii (12,9% faţă de cel mai mic scor de 4,1%). Polarizări interesante apar şi la percepţia despre cea mai sensibilă caracteristică: Plata! Raportul percepţiei, în cazul extrem, este de peste 2,25:1. Astfel, pentru angajare, un student ar merge întâi la firma G, nu la firma D, cu o probabilitate de 225%. Sigur că sunt mulţi factori care îi pot determina pe studenţi să prefere un angajator în defavoarea altuia. Acestea sunt percepţiile exprimate de către aceştia şi, credem, pot să fie food for thinking pentru firmele intrate în studiu, dar nu numai pentru acestea.

Dan Ionescu dan.ionescu@danis.ro Executive director @ Danis Consulting

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

management

Managementul performanței în organizațiile orientate spre proiecte din România

eși nu este un concept nou, managementul performanței a atras în ultimii ani o atenție sporită din partea organizațiilor datorită transferării aplicabilității acestuia la nivelul întregii organizații. Dacă până nu demult acesta era legat de Resursele Umane, evaluând măsura în care angajații își îndeplineau obiectivele impuse de organizație, astăzi managementul performanței este o funcție integrată ce vizează alinierea tuturor componentelor (indivizi, departamente, procese) la obiectivele organizației. Din perspectiva disciplinei managementu lui st rateg ic, pro cesu l de management al performanței are la bază premisa conform căreia angajații pot implementa cu adevărat o strategie numai atunci când o înțeleg pe deplin și descoperă modul în care ei pot contribui la obținerea rezultatului scontat (Cokins, 2004, p. 23). Managementul performanței este văzut ca un proces iterativ, care cuprinde atât o parte de planificare, cât și una de execuție (Cokins, 2004, p. 25). Astfel, managementul stabilește obiectivele pe care le transmite mai departe angajaților, de la care, la rândul său, primește în mod constant informații de natură financiară sau operațională asupra stadiului de performanță în realizarea obiectivelor, informații pe baza cărora va întreprinde acțiunile corective necesare menținerii organizației pe traseul stabilit. „Motorul” unei organizații este reprezentat de angajații săi, de aceea un factor decisiv în managementul perfomanței la nivel strategic îl reprezintă gestionarea performanței angajaților și a structurilor pe care aceștia le alcătuiesc (departamente, echipe). Din acest motiv, este lesne de înțeles, de ce, pentru o lungă perioadă de timp, managementul performanței a stat sub apanajul disciplinei Resurselor Umane. Departamentul de Resurse Umane este cel responsabil de evaluarea performanței angajaților, dar și să se asigure că această performanță contribuie la realizarea performanței organizației ca întreg, iar angajații sunt recompensați corespunzător pentru această contribuție. Cercetarea de față s-a realizat în anul 2013 și s-a axat pe analiza modului în care, în organizațiile orientate spre proiecte, personalul implicat în proiecte este evaluat și recompensat pentru activitatea din cadrul proiectelor. Aceste organizații sunt

definite ca organizații care își desfășoară activitatea în principal prin intermediul proiectelor sau în care acestea au o pondere relativ mare pe lângă activitățile recurente (operaționale). (Turner și Keegan, 2000, p. 8) Provocarea a luat naștere din particularitatea organizațiilor cu structură matriceală, în care angajații care lucrează în proiecte sunt subordonați atât managerului de proiect, cât și managerului de departament. Astfel, s-a urmărit identificarea măsurii în care această dublă subordonare influențează procesul de management al performanței în organizațiile românești cu acest tip de structură: cine este persoana abilitată să facă evaluarea performanței și să aducă modificări salariale (managerul de departament sau managerul de proiect), ce indicatori sunt măsurați la evaluarea membrilor echipei și a managerului de proiect, precum și ce tipuri de recompense sunt (dacă sunt) oferite pentru performanța din cadrul proiectelor. În urma analizei literaturii de specialitate au fost extrase următoarele concluzii: • În organizațiile orientate spre proiecte, managementul performanței urmărește alinierea obiectivelor indivizilor, departamentelor și proiectelor la obiectivele organizaționale . • În organizațiile orientate spre proiecte cu structură matriceală, evaluarea performanței personalului trebuie să țină cont atât de activitatea din cadrul departamentului, cât și de cea din cadrul proiectului. • La evaluarea personalului implicat în proiecte, managerul de departament colaborează cu managerul de proiect. • Evaluarea performanței din cadrul proiectului este strâns legată de succesul acelui proiect.

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

Pornind de la cele de mai sus, au fost stabilite trei ipoteze de cercetare care au fost măsurate prin aplicarea unui chestionar. Eșantionul cercetării întreprinse a fost alcătuit din angajați implicați, fie ca manageri de proiect, fie ca membri în echipă, în proiectele companiilor în care lucrează. Datele au fost prelucrate pentru 32 din cei 42 de respondenți, deoarece, în cazul a 10 dintre companii, nu se realiza nicio formă de evaluare a angajaților. Ipotezele cercetării au fost următoarele: I1 - În companiile în care se realizează evaluarea performanței angajaților, la evaluarea performanței se ia în considerare doar activitatea lor din cadrul departamentelor, nu și cea din cadrul proiectelor. I2 -Recompensele oferite anagajaților țin cont doar de activitatea desfășurată în departamente, nu și în proiecte. I3 - În companiile în care se ia în considerare activitatea din proiect la evaluarea performanței, evaluarea este realizată exclusiv de către managerul de department. În Tabelul 1 sunt centralizate rezultatele obținute la întrebările care au măsurat gradul în care la evaluare este luată în considerare performanța din proiecte. Conform tabelului de mai sus, în cazul companiilor în care activează cei 32 de respondenți, managerul de departament colaborează în mare măsură (scor 3,97) cu subalternii în stabilirea obiectivelor de performanță, iar evaluarea se face conform acestor obiective (scor 4,00). Interesant, din perspectiva acestei cercetări, este scorul obținut la cea de-a treia variabilă (4,41). Aceasta indică faptul că activitatea din cadrul proiectelor este luată în considerare în mare măsură la evaluarea performanței și, deși ne-am așteptat să existe o corelație între această variabilă și numărul de

TODAY SOFTWARE MAGAZINE Kerzner, 2010) pentru evaluarea managerilor de proiect și a membrilor din echipa de proiect.

Tabelul 1 - Medie răspunsuri pentru variabilele care măsoară gradul de evaluare a performanței din proiecte

proiecte desfășurate de companie într-un an, rezultatele analizei au infirmat acest fapt. Numărul de proiecte din companie nu determină măsura în care activitatea din acele proiecte este luată în considerare la evaluare. Pe de altă parte, evaluarea performanței din cadrul proiectelor nu este urmată în aceeași măsură de recompensarea acesteia (în 16 din cele 32 companii evaluarea ține cont în foarte mare măsură de activitatea din proiect, însă în numai 5 dintre acestea este și recompensată). În ceea ce privește natura recompenselor, ponderea cea mai mare (16 din 32 răspunsuri) au înregistrat-o recompensele de tip recunoaștere, urmate de cele financiare (8 din 32) și apoi, în egală măsură, de beneficii materiale și altă formă de recompensă (combinație de recompensă financiară și recunoaștere în fața colegilor sau cursuri plătite de companie). Rezultatele obținute la cele două întrebări privind gradul de recompensare a

activității din proiecte și natura recompenselor ne permit următoarea concluzie: deși media (3,72) indică o tendință de a recompensa personalul implicat în proiecte pentru activitatea din proiecte, faptul că recompensele sunt preponderent sub formă de recunoaștere sugerează interesul relativ scăzut pentru aceste recompense. Cu toate acestea, putem conchide că ipoteza I2 a fost infirmată. Un alt aspect interesant este faptul că, deși succesul unui proiect nu este în majoritatea cazurilor clar definit (3,25), acesta este în mare măsură (4,06) luat în considerare în momentul evaluării performanței membrilor echipei de proiect. Ceea ce sugerează că obiectivele de performanță în cazul proiectelor nu sunt la fel de clar definite ca acelea pentru activitatea din departament. În Figura 1 sunt prezentate rezultatele obținute pentru fiecare dintre indicatorii primari de performanță (conform Harold

Figura 1 - Medie răspunsuri privind indicatorii de performanță luați în considerare la evaluarea managerilor de proiect

La indicatorii primari de performanță pentru managerii de proiect s-au validat 27 de răspunsuri, dat fiind faptul că cinci dintre cei 32 respondenți nu au lucrat ca manageri de proiect în niciunul din proiectele companiei. Media totală obținută la acești indicatori a fost 3,65. Conform graficului de mai sus, factorii care sunt în mare măsură luați în considerare la evaluarea performanței managerilor de proiect sunt cei direct legați de calitate – „calitatea rezultatului proiectului” și „realizările tehnice ale proiectului” – precum și de constrângerile de timp și cost, măsurate împreună în cadrul indicatorului „planificarea bugetului și graficului de execuție” și, separat, prin indicatorii „respectarea costurilor țintă ale proiectului” și „respectarea jaloanelor proiectului. Acești cinci indicatori au obținut cele mai mari scoruri. Surpinzător este, însă, scorul obținut la indicatorul „stabilirea obiectivelor proiectului conform cerințelor proiectului”, care denotă că acestui aspect îi este acordată o atenție relativ scăzută în comparație cu indicatorii anteriori care trimit la tripla constrângere. Pe de altă parte, un interes relativ ridicat se acordă profitului obținut prin implementarea proiectului (3,78) și stabilirii „regulilor jocului” din cadrul proiectului (3,70). Indicatorul de performanță căruia i se acordă cea mai puțină importanță (2,85) comparativ cu ceilalți este cel care vizează stabilirea mecanismelor de control pentru performanța proiectului. Acest rezultat poate fi un indiciu asupra nivelului (relativ redus) al maturității companiilor analizate în managementul performanței în cadrul proiectelor. Ca și în cazul managerilor de proiect, indicatorii cărora li se acordă cea mai mare importanță la evaluarea performanței membrilor echipei de proiect sunt cei legați de constrângerile de timp, cost și calitate: „calitatea rezultatului”, „respectarea jaloanelor principale”, „costuri țintă, proiectarea tehnică cu plafon de cost”. În companiile analizate se așteaptă de la un membru ca în echipa de proiect acesta nu doar să se încadreze în cele trei constrângeri, ci să o facă inovând (3,94) și fiind orientat spre schimbare (3,97). Aceste scoruri, coroborate cu cele relativ scăzute în cazul indicatorilor „implementarea tehnică conform

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

management Managementul performanței în organizațiile orientate spre proiecte din România orientate spre proiecte cu structură matriceală din România. În plus, cele 32 de companii au fost repartizate inegal pe sectoare de activitate, ceea ce nu a permis realizarea unor corelații pertinente.

Bibliografie Cokins, Gary. 2004. Performance Management. Finding the Missing Pieces (to Close the Intelligence Gap). Hoboken, New Jersey: Wiley & Sons, Inc. Kerzner, Harold Ph.D. 2010. O abordare sistemică a planificării, programării și controlul activității de proiect. București, Editura CODECS. Turner, R.J., Keegan, A., Crawford, L. 2000. Learning by experience in the project-based organization. În Erasmus Research Institute of Management Report Series Research in Management, ERS-2000-58-ORG. Figura 14 Medie răspunsuri privind indicatorii de performanță luați în considerare la evaluarea membrilor echipei de proiect

cerințelor” și „compromisuri între cerințe”, denotă faptul că există o flexibilitate destul de mare în definirea ariei de cuprindere a proiectelor, iar acestei constrângeri nu i se acordă o importanță la fel de mare ca celor de timp și cost. Această „construire din mers” a ariei de cuprindere poate fi o explicație pentru rezultatul privind definirea clară a succesului proiectului. Astfel, este dificil de identificat succesul unui proiect atunci când nu se cunoaște cu exactitate ce se face în acel proiect. Conform rezultatelor cercetării întreprinse, toate cele trei ipoteze au fost infirmate. În cazul primei ipoteze, media celor 32 de răspunsuri a evidențiat faptul că, în companiile respective, evaluarea performanței ține cont în mare măsură de activitatea din cadrul proiectelor, iar aceasta din urmă este evaluată pe baza unor indicatori de performanță și a succesului proiectului respectiv (chiar dacă acesta nu este în majoritatea cazurilor foarte clar definit). În ceea ce privește recompensarea, deși scorul obținut (3,72) relevă o importanță relativ ridicată acordată acestui aspect, natura recompenselor (preponderent de tip recunoaștere) ar putea indica un sistem de recompense nu foarte bine pus la punct pentru activitatea din proiecte. Însă, subiectul ar mai trebui investigat pentru a putea fi extrase concluzii valide. Referitor la responsabilitatea evaluării personalului implicat în proiect, contrar așteptărilor inițiale, într-o pondere foarte mare (20 din cele 32 companii ) a reieșit ca evaluarea se realizează cu ajutorul managerului de proiect.

Aceste rezultate deschid calea către cercetări mai extinse în domeniu, însă, pentru moment, pornind de la ele, pot fi extrase câteva recomandări: • Dacă în cazul activității din departament obiectivele de performanță ale angajaților sunt stabilite în mare măsură prin colaborarea managerului de departament cu angajatul din subordine, în cazul activității din proiecte situația nu mai este la fel de clară. Din cercetare a reieșit faptul că, deși succesul proiectului este un factor foarte important în evaluare, acesta nu este întotdeauna foarte clar definit. În acest caz, recomandarea propusă este ca, în momentul stabilirii obiectivelor de performanță pentru anul în curs, managerul de departament să traseze, împreună cu managerii de proiect, câteva criterii generale de performanță pentru toate proiectele, urmând ca la acestea să fie adăugate alte criterii specifice în funcție de fiecare proiect. • Dată fiind diferența de durată între activitățile recurente care se desfășoară în cadrul departamentelor pe durata întregului an și caracterul temporar al proiectelor, crearea unui sistem de recompense specific proiectelor, care să existe în paralel cu cel pentru activitatea din departament, ar putea fi o soluție viabilă pentru recompensarea întregii activități din organizație a personalului implicat în proiecte. Limitarea majoră a cercetării de față constă în dimensiunea redusă a eșantionului, ceea ce nu permite generalizarea concluziilor pentru toate oranizațiile

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

Adina Grigoroiu, CAPM adina.grigoroiu@confucius.ro Trainer și consultant @Colors in Projects

prezentare

TODAY SOFTWARE MAGAZINE

Lumy.ro - usability testing

umy.ro este prima platformă de usability testing din România, lansată de compania REEA. Pentru prima dată în țara noastră, companiile, dar și persoanele fizice, au posibilitatea să afle părerea utilizatorilor pe care îi targetează prin produsele lor web și mobile. În urma testelor, platforma va da informații exacte în legatură cu website-ul sau aplicația de Facebook pe care dezvoltatorii din industrie le-au realizat, chiar înainte de a le lansa pe piață. Platforma Lumy.ro oferă servicii de usability testing la cerere. Astfel, se folosesc teste de utilitate pentru a verifica navigabilitatea website-ului, relevanța conținutului, eficiența designului și ușurința cu care clienții/utilizatorii pot realiza anumite procese critice în cadrul website-ului și/sau aplicației. În cadrul platformei, există două tipologii de testeri: tester începător și tester avansat. Singura diferență între aceste două tipologii de conturi este accesibilitatea la diferite tipuri de teste. În funcție de dificultatea acestora, pentru fiecare test realizat, utilizatorului i se va aloca în cont un număr de puncte lumy. Există cinci tipuri de teste de utilitate: heatmap, clickmap, preferințe, feedback și video feedback. Preţurile sunt accesibile şi se ajustează în funcţie de bugetul disponibil. Cu suma de 50 de lei, o companie va obţine 17 teste video, din care va reieşi un feedback real. Numărul testerilor înscrişi în platformă a ajuns la aproape 520 și este într-o continuă creștere. Daniela Ferenczi, UX specialist în cadrul companiei REEA, este inițiatorul Lumy. Construcția a tot ceea ce înseamnă Lumy a început în luna iunie 2013, la Tîrgu-Mureș. Denumirea provine de la cuvântul ”lumină”. Ideea acestui nume a pornit de la faptul că, atunci când realizezi un proiect îl creezi în propriul tău birou, bazându-te pe propriile cunoștințe și pe know-how-ul echipei cu care lucrezi. La finalizarea proiectului, munca și creativitatea ta pe partea de usability se lansează în întuneric, fără usability testing. Practic, nu știi dacă utilizatorii tăi au primit un produs sau serviciu ce poate fi folosit ușor, are logică pentru ei și le oferă o experiență, nu doar o întrebuințare. LUMY are rolul de ”a te lumina” în ceea ce privește munca unui UX Designer, a unui Information Architect și chiar a unui web designer, prin serviciile de usability testing pe care le oferă.

de brainstorming a tuturor echipelor implicate, realizarea unui wireframe de la care s-a pornit. Apoi, s-a continuat implementarea platformei cu cele două versiuni, cea destinată testerilor și cea pentru companii, în mai multe faze: • versiunea pentru testeri și realizarea de teste video și feedback de către testeri prin intermediul aplicației Lumy Recorder; • versiunea pentru companii; • integrarea testelor de tip preferințe, clickmap, heatmap; • comenzi teste pe partea destinată companiilor; • valorificarea câștigurilor testerilor; • versiunea platformei în limba engleză; • upgrade pe partea de companii străine; • implementare API pentru aplicația iOS. Aceste etape au fost implementate în cadrul echipei .NET. În paralel, echipa iOS a implementat aplicația Lumy pentru iPhone și Lumy Recorder pentru iPhone. Totodată, s-a adaptat website-ul pentru telefoane mobile și tablete. Ca tehnologii folosite, putem enumera: Axure, MVC4, C#, MS SQL Server, Microsoft TFS, Node. js, HTML5, CSS3, Adobe Photoshop, Responsive Web Design, MailChimp, NearForums, Scrum Project Management. Pe partea de iOS, s-au utilizat limbajele de programare Objective C și C++ și s-a folosit iOS SDK și OpenGL.

Ce este Lumy Recorder?

Lumy Recorder este o aplicație desktop stand-alone, care se ocupă cu înregistrarea unor sesiuni de testare, în cadrul cărora se captează răspunsul în format text al utilizatorului, al vocii acestuia și al acțiunilor petrecute pe ecranul acestuia. Datele capturate se transmit instantaneu către un server, care le stochează într-o bază de date centralizată. Tehnologiile folosite sunt Implementarea următoarele: Prima etapă, a fost evident analiza proi• pentru captura ecranului: filtru de ectului, ceea ce se dorește în faza inițială și captură ecran împreună cu Ffmpeg. unde vrem să ajungem. Au fost multe ore • pentru captura audio: se folosește

Ffmpeg mapat cu Windows Core Audio pentru detecția și selectarea microfonului. Comunicarea între browser și aplicație se face prin intermediul unui server local http. Comunicarea cu server-ul este făcută prin TCP. Pe parte de server pentru stocarea stream-ului de date, se folosește NodeJs, care pornește instanțe de ffmpeg. Cele mai dificile task-uri au fost găsirea unui mod eficient de captură a ecranului și comprimarea cât mai bună a fluxului de date audio și video. O altă situație solicitantă a fost maparea microfonului reprezentat în felul ffmpeg cu cele existente deja în sistem.

Lumy Recorder pentru iOS

Prin intermediul acestei aplicații, testerii înscriși în cadrul platformei vor putea realiza teste de tip feedback și video, iar companiile vor primi o reacție reală pentru versiunile mobile ale website-urilor realizate. Aplicația Lumy Recorder pentru iPhone a fost realizată utilizând limbajele de programare Objective C și C++ și folosind iOS SDK și OpenGL. O echipă formată din trei dezvoltatori a lucrat peste 600 de ore, pentru a reuși publicarea în Apple Store. Cea mai complicată parte din dezvoltarea aplicației a fost realizarea capturii video. SDK-ul nativ nu permite captură video de pe browser, astfel că dezvoltatorii au fost nevoiți să găsească o altă metodă, folosind OpenGL. Accesând link-ul http://www.youtube. com/watch?v=CeqXjD99z1o&feature= youtu.be , puteți vedea un exemplu de test video, realizat pe un iPhone 5S. Platforma de usability testing – Lumy – a fost dezvoltată integral, de la concept până la implementare, de REEA.

Daniela Ferenczi daniela.ferenczi@reea.net UX designer REEA, inițiator Lumy @ REEA

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

management

Optimizarea – de ce ar merita efortul?

n urmă cu cinci ani mă aflam în fața acestei întrebări, în momentul în care am acceptat mandatul de a implementa un program de optimizări într-o organizație de servicii IT cu peste 150 angajați. La vremea respectivă am estimat-o ca fiind o sarcină relativ simplă, de câteva luni, care se termină în momentul în care “ne definim procesele și obținem certificarea CMMI”. Ce gândire simplistă și naivă! Mi-ar plăcea să fi avut gândirea de azi la acea vreme… Totuși este util să împărtășesc din aceste experiențe – uneori nu tocmai plăcute – în speranța că ele vor fi de ajutor pentru alții. Ceea ce s-a întâmplat în acești cinci ani nu a fost doar o structurare, o implementare a unor procese, ci o schimbare completă de gândire privind calitatea si optimizarea modului de lucru, cu ajutorul mentorilor extraordinari cu care am avut plăcerea de a lucra. În realitate această sarcină asumată s-a transformat în cinci ani de eforturi serioase, determinare puternică de a nu renunța, care la final a schimbat gândirea și modul de lucru al întregii organizații. Astfel de programe nu sunt de neglijat. Ele sunt dificile, intruzive, imprevizibile și deseori sunt privite ca devieri fără sens de la ‘modul normal de lucru’. Prin urmare, întrebarea naturală este: “merită efortul?”. În cursul acestor ani am mai avut ocazia să observ foarte multe persoane din domeniul IT – atât programatori cât și manageri, în companii mici și mari – punând această întrebare: “merită efortul?”. Desigur cu alte cuvinte și alte nuanțe, dar cu aceeași esență, prin variații precum: • “Lucrurile au funcționat și până acum, de ce le-am schimba?” • “Nu ne dorim ISO sau CMMI, de ce ne-am complica?” • “Suntem o firmă mică, nu ne dorim gândire corporatistă, nu avem nevoie de asta.” • “Nu avem timp anul acesta, poate altădată.” • “Implică costuri ridicate, mai degrabă angajăm doi programatori.” • “Am lucrat deja la procese și lucrurile nu s-au schimbat.” • “Alții au inițiat astfel de programe și au eșuat.” • “Noi am mai inițiat astfel de programe și am eșuat.” • …și lista poate continua. Uneori răspunsul vine din partea clienților (sau potențialilor clienți) care doresc o colaborare doar cu parteneri care pot dovedi o anumită maturitate organizațională. Acest lucru poate genera una din cele două reacții: fie (1) căutarea unor căi de ocolire, scurtături pentru obținerea unei certificări, fie (2) efectuarea unei

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

investiții pe termen lung, optimizată pentru maximizarea beneficiilor. Din fericire, majoritatea managerilor ar opta pentru a doua variantă, însă grupul complementar este de o dimensiune deloc neglijabilă. Însă acei clienți (sau potențiali clienți) interesați de acea maturitate organizațională sunt rareori interesați de ștampila sau de certificatul afișat la recepție. Ei sunt interesați de faptul că acele cazuri de succes afișate pe site-urile noastre sunt repetabile. Că ele au fost analizate, că ingredientele pentru succesul lor au fost identificate și sunt disponibile pentru proiectele de viitor efectuate în colaborare. Acest aspect este de importanță extremă pentru companiile de servicii IT din Europa Centrală și de Est. Deoarece întotdeauna se va găsi un competitor care oferă aceleași servicii fie la un preț mai redus, fie într-un timp mai scurt sau chiar ambele. Prin urmare, șansa de a rămâne competitivi pe o piață de servicii IT supra-aglomerată și volatilă, unde competiția devine globală, se regăsește în calitatea demonstrată și continuu optimizată. Dar calitatea înseamnă mai mult decât un slogan. În primul rând, aceasta trebuie DEFINITĂ, apoi trebuie MĂSURATĂ și DEMONSTRATĂ, iar în timp trebuie vizibil OPTIMIZATĂ. Din păcate acesta nu se poate obține prin ședinte. Modul în care se poate obține sunt programele de optimizare care necesită angajament și investiții. Termenul de “Quality Assurance” are în fond o semnificație mult mai largă decât cea cu care ne-am obișnuit deja, dincolo de testare și dincolo de controlul calității. Existența unui sistem de QA funcțional poate reprezenta o diferență semnificativă și un avantaj competitiv major pentru o organizație. Există o percepție greșită asupra ceea ce reprezintă QA: în marea majoritate a cazurilor prin QA se înțeleg activitățile efectuate de personalul de testare într-o echipă. Mai mult, uneori acest personal este simplist denumit “QA”, nefiind parte din echipa de dezvoltare, în schimb testând rezultatele produse cu un decalaj de o iterație completă. În realitate,activitățile de testare sunt parte a QC (Quality Control)

TODAY SOFTWARE MAGAZINE din ciclul de dezvoltare, verificând reactiv produsele/serviciile care s-au dezvoltat. În contrast, QA are o importanță net superioară: asigurarea calității produselor/serviciilor ce urmează a fi dezvoltate. Diferența dintre cele două concepte este majoră. De exemplu, QA include activități precum revizuirea artefactelor, activitate capabilă să detecteze de 8-10 ori mai multe defecte decât testarea în aceeași unitate de timp. QA facilitează reutilizarea experienței, metricilor și cunoștințelor – având ca una din urmări, creșterea preciziei estimărilor. QA creează condițiile ca fiecare persoană din echipă să-și înțeleagă rolul în echipă și așteptările față de acel rol, având la dispoziție practicile care să o faciliteze în efactuarea sarcinilor. QA verifică eficiența colectării și analizei metricilor, a raportării eficiente, ceea ce asigură planificări mai precise. Și lista poate continua… Orice efort, timp sau buget alocat unui program de optimizări trebuie privit ca o investiție și nu un cost. O investiție care generază beneficii semnificative, superioare investiției. Cele mai multe metode de “ocolire” a investițiilor nu vor asigura succesul programului de optimizări, ci vor asigura opusul acestuia: schimbarea investiției într-o risipă irecuperabilă de resurse. Astfel de metode includ: • Doar execuție – fără training, fără suport, fără o viziune sau un plan. • Achiziția unui “tool” care să rezolve problemele. • Achiziția proceselor altora. • Elaborarea proceselor de către o singură persoană (preferabil într-o săptămână). • Inventarea proceselor noi. • Cumularea de multiple roluri pentru o singură persoană – de la definiție, măsurare, implementare și evaluare. Totuși, cu o abordare corectă, sănătoasă, sunt posibile optimizări semnificative prin aplicarea unor principii simple: • Având ca punct de pornire actualul mod de lucru (optimizări, nu invenții). • Documentarea practicilor existente, identificarea zonelor problemă. • Concentrare pe aspectele importante ale organizației. • Colectarea măsurătorilor relevante, publicarea lor în organizație. • Implicarea personalului în definirea nevoilor. • Apelarea la asistența profesională, training și mentoring adecvat. Așadar, revenind la întrebarea originală: de ce ar merita efortul? 1. Deoarece facilitează supraviețuirea speciei de companie de servicii IT din Europa Centrală și de Est, în special sub-speciei caracterizate prin servicii outsourcing. Industria de servicii ITși în special cel de outsourcing, este extrem de expus competiției globale în timp ce comunitatea de freelancer-i oferă o alternativă accesibilă clienților. De aceea, companiile trebuie să poată demonstra evoluție, optimizări continue în timp pentru a nu fi eclipsate de competiție. 2. Deoarece promovează cel mai puternic avantaj competitiv: calitatea. Competiția poate oferi servicii mai accesibile și cu termene mai scurte, însă mult mai dificil poate demonstra calitatea superioară. Putem oare găsi o companie care să nu promoveze calitatea? Desigur, nu.Toate companiile oferă servicii și produse de calitate. Însă este extrem de dificilă definirea ei. De cele mai

multe ori această definiție – dacă ea există măcar – se reduce la măsurarea termenelor și a costurilor pentru a demonstra calitatea oferită. De aici întrebarea naturală ar fi: aceasta înseamnă că ieftin și rapid este definiția calității? În realitate, definirea calității este o sarcină dificilă: puține companii reușesc să definească, să poată măsura și optimiza calitatea, iar aceste detalii pot oferi un avantaj competitiv extrem de important. 3. Deoarece reduce costurile corecțiilor reactive cum ar fi testarea, activitățile de fixing sau refactoring. Implementarea unui sistem de QA în organizație promovează mesajul “calitatea nu e problema altora” și asigură că oricine poate contribui la calitate, nu rămâne exclusiv în responsabilitatea echipei de testare. Asigură împărtășirea cunoștințelor, a practicilor de succes dovedite, pentru ca ele să fie refolosite. Asigură că metricile sunt colectate, analizate și consolidate în statistici care contribuie la precizie și predictabilitate pentru viitor. Asigură implementarea calității începând din primele faze ale proiectelor, unde investiția în training și în planificare poate garanta beneficiile pe parcursul proiectelor. 4. Deoarece facilitează învățarea continuă. Deseori se învață din greșeli. Orice persoană, echipă sau organizație produce greșeli și este normal ca acestea împreună cu concluziile aferente să fie analizate periodic în vederea evoluției. Însă aceasta nu înseamnă că pentru evoluție trebuie comise greșeli! Deseori ele nu sunt permise. De ce nu s-ar pune obiectivul realizării corecte a sarcinilor din prima încercare? Limitarea cea mai frecventă este timpul – sau mai precis lipsa lui. Lipsa timpului pentru revizuirea artifactelor, sau pentru o planificare corectă, sau pentru un design tehnic corect, sau pentru activități corective. În realitate, timpul alocat acestor activități la începutul unui proiect se recuperează triplat în fazele ulterioare prin efort mult mai redus în activități de testare sau corective. Există o varietate largă de practici aplicabile, cum ar fi refolosirea cunoștințelor, experiențelor, a practicilor de succes dovedite sau a statisticelor. 5. Deoarece este practic și aplicabil, pretabil organizațiilor mici sau mari. A fi o mică firmă de start-up sau, din contră, o corporație nu mai reprezintă o scuză validă pentru a nu investi în optimizări. a. Companiile mici au nevoie de creșterea cifrei de afaceri, de contracte mai valoroase, de clienți mai mari. Acești clienți pot fi exigenți, pot avea criterii bine definite pentru parteneri. Ar putea fi interesați de modelul SDLC, care nu ar reprezenta o problemă. Însă ar putea cere detalii și explicații pentru modul și raționamentul din spatele modelului, ceea ce necesită o bună pregătire. De multe ori modelul SDLC se descrie prin activitățile de design + dezvoltare + testare. Dar activitățile de planificare? Cele de monitorizare și control? Cele de configuration management sau change management? Poate risk management? Neavând definite aceste activități, modelul nu poate fi considerat complet. Planificarea fără monitorizare este o risipă de efort și timp. Monitorizarea fără o planificare adecvată este nonsens. Iar aceste detalii pot amenința un contract promițător în primele faze. b. Marile corporații pot genera pierderi semnificative dacă nu sunt optimizate. Un efect al absenței optimizării este situația schizofrenică în care există munți întregi de cunoștințe în cadrul organizației fără ca ele să poată fi valorificate. Fără a avea o coordonare și viziune clară asupra rolului departamentelor sau activităților, strategiile și planurile își pierd claritatea, rezultând în confuzie și ineficiență în cadrul www.todaysoftmag.ro | nr. 22/Aprilie, 2014

management Optimizarea – de ce ar merita efortul? echipelor, ceea ce se traduce în întârzieri, timpi de așteptare și rework. Aplicat la echipe sau departamente de sute de persoane, pierderile pot fi surprinzătoare. 6. Deoarece conduc la rezultate tangibile, măsurabile, concrete. Iată câteva exemple publicate de Software Engineering Institute: a. Reducerea anuală a TTM – câștiguri între 15% și 23%, b. C reșterea anuală a ratei de detectare a defectelor – câștiguri între 6% si 25%, c. Reducerea anuală a erorilor raportate – câștiguri între 11% si 94%, d. ROI global – câștiguri între 400% și 880%. 7. Deoarece serviciile și produsele se adresează unor clienți din ce în ce mai exigenți, pentru care afișarea succeselor din trecut nu mai este suficientă. Trebuie demonstrate cauzele care le-au făcut să fie succese, factorii care au asigurat diferența dintre succes și eșec. Trebuie demonstrat modul de lucru în care ele s-au realizat. Și cel mai important, vor trebui convinși că repetarea modului de lucru va asigura repetarea succesului – iar pentru aceasta avem nevoie de procese repetabile. Acestea sunt doar câteva motive pentru care optimizare modului de lucru merită efortul. Deși un program de optimizări complet, cu buget ridicat nu este accesibil întotdeauna,acest fapt nu ar trebui să reprezinte un impediment dacă există determinare. Există pași mărunți care se pot aplica în prima fază a optimizărilor: • Pornirea de la practicile existente în companie. Documentarea SDLC existent, identificarea lacunelor. • Definirea obiectivelor. Plan de acțiuni pentru atingerea lor. • Organizarea unor training-uri specifice pentru dobândirea competențelor critice cum ar fi project management, process improvements, risk management, dar și pentru familiarizarea cu unul din modelele aplicabile (CMMI, ISO, Six Sigma, TickIT Plus, etc.) • Concentrarea în primul rând asupra personal, deoarece este factorul principal în realizarea serviciilor și produselor de calitate, pe când un model sau un set de procese are doar rolul de a facilita personalul.

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

• Consultanță profesională, pentru a face eforturile cât mai practice și a maximiza beneficiile cu aceleași investiții. • Abordarea în orice activitate, în orice circumstanțe, a ciclului Sheward-Deming: Plan-Do-Check-Act. • Organizarea de retrospective, colectarea și analizarea experiențelor și a metricilor • Revizuirea artefactelor, frecvent, aplicată pe toate tipurile de artifacte (specificații, planuri, design tehnic, cod, test case, etc.) .

Cu un angajament puternic, un astfel de program poate deveni mai simplu decât ar părea la prima vedere. În mod categoric efortul investit nu devine pierdere, beneficiile pot fi uimitoare. Sperăm că în viitorul apropiat mulți dintre cititorii acestui articol se vor pronunța în mod asemănător. La final, rămâne întrebarea: de ce nu ar merita efortul să ne optimizăm afacerea?

Tibor Laszlo tibor.laszlo@improving-it.com Partner & Consultant @Improving-IT

programare

TODAY SOFTWARE MAGAZINE

AOP folosind Unity

n ultimul număr al revistei Today Software Magazine, am discutat despre principiile de bază ale AOP și despre cum putem implementa conceptul de bază al AOP utilizând caracteristici ale .NET 4.5, fără a folosi alte cadre. În acest articol, vom vorbi despre Unity și vom vedea cum putem utiliza acest cadru pentru a implementa AOP.

instrumentele din .NET 4.5, cum sunt RealProxy și Attribute. RealProxy este ingredientul special în cazul nostru, dându-ne Într-o primă parte , vă prezentăm o definiție a acronimului posibilitatea de a intercepta toate cererile adresate unei metode AOP și cum o putem utiliza în .NET 4.5 fără alte cadre. sau proprietăți. Aspect Oriented Programming (Programarea Orientată pe Aspecte) este o paradigmă de programare având ca scop principal Unity creșterea modularității unei aplicații. AOP încearcă să atingă acest Acesta este un cadru binecunoscut de către dezvoltatorii .NET scop prin permiterea separării aspectelor secante (cross-cutting drept un dependency injection container. Acesta este parte a comconcerns), folosind interceptarea diferitelor comenzi sau cereri. ponentelor care formează Pattern-urile și Practicile Microsoft și Un exemplu bun pentru acest caz este audit-ul și logging-ul. În este un dependency injection container în cazul aplicației ASP.NET mod normal, dacă utilizăm OOP pentru a dezvolta o aplicație care MVC. Unity a atins un punct critic în momentul în care a fost necesită logging sau audit, vom avea într-o formă sau alta diverse complet integrat cu ASP.NET MVC. Din acel moment, mii de proapelări ale mecanismului de logging în codul nostru. În OOP, acest iecte web au început să îl utilizeze. lucru poate fi acceptat, deoarece aceasta este singura modalitate Din punctul de vedere al unui container de injectare de a scrie log-uri, de a face prelucrare și așa mai departe. Când dependențe, Unity este un cadru matur care are toate funcțiile pe utilizăm AOP, implementarea sistemului de logging sau audit va care un dezvoltator se așteaptă să le găsească la un astfel de cadru. trebui să se afle într-un modul separat. Mai mult decât atât, vom Caracteristici precum configurare XML, înregistrare, rezolver avea nevoie de o cale de a scrie informația de logging fără a scrie implicit sau special, injectare de proprietăți, container-e personacod în alte module care vor face apelarea în sine a sistemului de lizate, sunt în întregime susținute de Unity. logging, folosind interceptarea. În următorul exemplu, vom vedea cum putem înregistra Această funcționalitate poate fi implementată utilizând interfața IFoo în containerul de injectare dependențe și cum

Recapitulare

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

programare AOP folosind Unity putem obține o referință la această exemplificare. IUnityContainer myContainer = new UnityContainer(); myContainer.RegisterType<IFoo, Foo>(); //or myContainer. RegisterInstance<IFoo>( new Foo()); IFoo myFoo = myContainer.Resolve<Foo>();

Când este folosit cu ASP.NET MVC, dezvoltatorii nu mai trebuie să gestioneze durata resurselor utilizate de Controller-i, Unity este cel care se ocupă de acest aspect în locul lor. Singura operație pe care trebuie să o facă este să înregistreze aceste resurse și să le solicite în controller, ca în următorul exemplu: public class HomeController : Con troller { Foo _foo; public HomeController(Foo foo) { _foo = foo; } public ActionResult Index() { ViewData[„Message”] = „Hello World!”; }

}

return View();

public ActionResult About() { return View(); }

După cum putem observa în exemplul de mai sus, Unity va putea rezolva toate dependențele în mod automat.

Unity și AOP

Înainte de a analiza acest subiect mai în amănunt, este necesar să abordăm a atitudine obiectivă. Unity nu este un cadru AOP și, de aceea, nu vom avea toate caracteristicile care formează AOP. Unity susține AOP la nivel de interceptare. Aceasta înseamnă că avem posibilitatea de a intercepta apelurile către obiectul nostru de la dependency injection container și de a configura un comportament special la acel nivel. Unity ne oferă posibilitatea de a injecta codul nostru înainte și după o apelare a obiectului nostru țintă. Aceasta poate fi făcută numai cu obiectele care sunt înregistrate în Unity. Noi nu putem modifica cursul pentru obiecte care nu se află în container-ul Unity. Unity ne oferă această funcționalitate utilizând un mecanism similar cu cel care este obținut prin Decorated Pattern. Singura diferență este că în cazul Unity, container-ul este cel care decorează apelul cu un comportament – atribut ”făcut la comandă”. La sfârșitul articolului vom vedea cât de ușor este să adaugi un mecanism de urmărire utilizând Unity sau să faci toate apelurile către baza de date să execute, folosind tranzacții. Putem utiliza Unity pentru obiecte care au fost create în Unity și înregistrate în diferite container-e sau obiecte care au fost create în alte părți ale aplicației noastre. Singura cerință de la Unity este să aibă acces la aceste obiecte într-un fel sau altul.

Cum poate Unity să intercepteze apeluri?

Interceptor va intercepta apelul, va declanșa comportamentul la comandă și va face apelul real către obiectul țintă. Toate aceste apeluri sunt interceptate prin folosirea unui substitut care trebuie să fie configurat de către dezvoltator. Odată ce substitutul este setat, toate apelurile vor trece prin Unity. Nu există nicio cale prin care cineva să poată ”sparge” sistemul și să treacă pe lângă interceptor. Comportamentul care este injectat utilizând Unity poate schimba valoarea parametrului de intrare sau valoarea returnată.

Cum să configurezi interceptarea?

Există două moduri de a configura interceptarea – de la cod sau utilizând fișiere de configurare. În ambele cazuri, este nevoie să definim comportamentul special care va fi injectat în containerele Unity. Personal, eu prefer să folosesc codul, utilizând fluentul API care este disponibil. Recomand utilizarea fișierelor de configurare numai atunci când sunteți siguri că va trebui să schimbați configurarea în timpul execuției sau fără a recompila codul. Chiar dacă facem această recomandare, noi am utilizat frecvent configurarea din fișiere pentru că aceasta este mai flexibilă. Atunci când folosiți fișiere de configurare, vă asumați riscul de a introduce mai ușor probleme de configurare – scrierea greșită a numelui claselor sau redenumirea unui tip și omiterea de a actualiza și fișierele de configurare. Primul pas este acela de a defini comportamentul pe care dorim să îl executăm atunci când realizăm interceptarea apelului. Acest lucru se face numai prin cod, implementând InterceptionBehavior. Cea mai importantă metodă a acestei interfețe este ”Invoke” (Invocarea), care este declanșată când cineva apelează metodele care sunt interceptate. De la această metodă este nevoie să facem apelul propriu-zis către metoda reală. Înainte și după apel, putem injecta orice tip de comportament. Deși era previzibilă existența a două metode, una care este apelată înainte de apelul propriu-zis și una după apel, această funcție nu o deține Unity. O altă componentă importantă a acestei interfețe este proprietatea ”WillExecute”. Stabilirea drept TRUE (adevărată) a proprietății, condiționează interceptarea apelului. Utilizând această interfață, avem posibilitatea de a controla apelurile către orice metode de la obiectele aplicației noastre. Avem deplin control de a face apelul real sau de a-l mima: public class FooBehavior : IInterceptionBehavior { public IEnumerable<Type> GetRequiredInterfaces() { return Type.EmptyTypes; } public IMethodReturn Invoke(IMethodInvocation input, GetNextInterceptionBehaviorDelegate getNext) { Trace.TraceInformation(„Before call”); // Make the call to real object var methodReturn = getNext().Invoke(input, getNext); }

Trace.TraceInformation(„After call”); return methodReturn;

public bool WillExecute

{ Toate apelurile de la client pentru tipuri specifice trec prin get { return true; } Unity Interceptor. Acesta este o componentă a cadrului care poate } intercepta toate apelurile și poate injecta unul sau mai multe com- } portamente la comandă, înainte sau după apel. Aceasta înseamnă Apoi va trebui să adăugăm acest comportament la Unity. Vom că între apelul clientului și obiectul țintă, componenta Unity adăuga o secțiune specială la fișierul nostru de configurare care

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE să specifice pentru ce tip dorim să facem această interceptare. În Chiar dacă nu avem metode specifice apelate de Unity înainte următorul exemplu, vom face această interceptare numai pentru și după invocare, aceasta poate fi foarte ușor extinsă. Vă invit pe tipul Foo: toți să încercați Unity. <sectionExtension type=”Microsoft.Practices.Unity. InterceptionExtension. Configuration.InterceptionConfigurationExtension, Microsoft.Practices.Unity.Interception.Configuration”/> … <container> <extension type=”Interception” /> <register type=”IFoo” mapTo=”Foo”> <interceptor type=”InterfaceInterceptor” /> <interceptionBehavior type=”FooBehavior” /> </register> </container>

În acest exemplu, specificăm în Unity să folosească interceptorul interfață folosind FooBehavior pentru toate exemplele de obiecte IFoo care sunt asociate cu Foo. Aceeași configurare poate fi realizată din cod, utilizând configurare fluentă. unity.RegisterType<IFoo, Foo>( new ContainerControlledLifetimeManager(), new Interceptor<InterfaceInterceptor>(), new InterceptionBehavior<FooBe havior>());

Din acest moment, toate apelurile la exemple Ifoo din containerul Unity vor fi interceptate de către interceptorul (comportamentul) nostru special creat. Mai există și o altă metodă de a implementa acest mecanism, folosind atribute. Dacă utilizați atribute, va trebui să implementați interfața IcallHandler pentru a specifica comportamentul special și pentru a crea atribute speciale care vor fi folosite pentru a decora metoda pe care dorim să o interceptăm. Din punctul nostru de vedere , este de preferat prima versiune, cea a utilizării IInterceptionBehavior.

Concluzie

În acest articol am văzut cât de ușor putem adăuga funcționalitate AOP unui proiect care utilizează deja Unity. Implementarea acestei funcții este foarte simplă și flexibilă. Ne putem imagina foarte ușor scenarii mai complexe, combinând IinterceptionBehavior și atribute speciale.

Radu Vunvulea

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

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

legal

Drept de autor și software. Câteva aspecte practice pentru programatori

eseori, programatorii români și companiile software sunt insuficient familiarizați cu unele noțiuni de bază privind dreptul de autor – noțiuni ce îi pot ajuta substanțial în activitatea lor. Din experiența noastră, am ales câteva aspecte care ni se par mai relevante. Bineînțeles, lista rămâne deschisă, dar cele de mai jos pot fi un bun început.

Dreptul de autor asupra unui program pentru calculator

Pot fi protejate prin drept de autor: orice expresie a unui program, programele de aplicaţie şi sistemele de operare (exprimate în orice limbaj – cod-sursă sau cod-obiect), materialul de concepţie pregătitor, manualele. Dreptul de autor asupra unui program pentru calculator (software) se naşte din momentul creării acestuia (când programatorul începe să scrie liniile de cod). Autorul este programatorul (persoana fizică), iar titularul dreptului de autor asupra programului poate fi programatorul și/sau angajatorul/clientul său (în funcție de situația concretă și de înțelegerea scrisă dintre ei). Nu sunt protejate prin drept de autor: ideile, procedeele, metodele de funcţionare, conceptele matematice şi principiile care stau la baza oricărui element dintr-un software, inclusiv cele care stau la baza interfeţelor sale.

Cum se poate valorifica dreptul de autor asupra unui software?

În principiu, prin cesiunea – exclusivă sau neexclusivă – a tuturor sau doar a unora dintre drepturile patrimoniale de autor. Cesiunea trebuie să aibă loc în anumite condiții foarte specifice. Spre deosebire de cesiunea exclusivă, în cazul cesiunii neexclusive, titularul dreptului de autor păstrează și el drepturile cedate (putând utiliza el însuși programul) şi le poate transmite și altor persoane.

Confuzia dintre licență și cesiune

De cele mai multe ori, sub influența practicii americane, se folosește impropriu noțiunea de licență pentru software. Dar termenul de licență nu există în legislația aplicabilă în România, în cazul programelor pentru calculator; de fapt, este vorba despre o cesiune a dreptului de utilizare a unui program (unul dintre drepturile patrimoniale de autor). Această cesiune a dreptului de utilizare este echivalentul unui license agreement – adică acea autorizare scrisă dată de titularul dreptului de autor (pe hârtie sau în format digital) care însoţește un software și prin care se arată că acesta este licenţiat, nu vândut. Este, de fapt, un contract încheiat între titularul dreptului de autor şi utilizator, prin care utilizatorul primește – de cele mai multe ori – dreptul neexclusiv de a folosi acel software (fără a-l putea modifica sau transmite altcuiva). Nu implică transferul tuturor componentelor dreptului de autor asupra software-ului.

nr. 22/Aprilie, 2014 | www.todaysoftmag.ro

Open source

În practică, probleme interesante apar și în cazul integrării programelor open-source în diverse soluții software dezvoltate pentru clienți. Caracteristica open source este permisiunea de a copia, modifica și distribui în mod liber. Dar cum există multe tipuri de licențe open source, este util să cunoașteți ce tip de licență se aplică utilizării unui anumit soft open source și care sunt implicațiile de natură comercială (și legală, de ce nu) ale fiecărei licențe (fie că este vorba despre GPL, Apache, etc.).

Înscrierea / înregistrarea în Registrul Programelor pentru Calculator

Probabil ați aflat de Registrul Național al Programelor pentru Calculator (RNPC) administrat de Oficiul Român pentru Drepturile de Autor (ORDA), dar nu știți exact ce obligații au producătorii de software. În RNPC, este obligatorie: (i) Înscrierea programelor de calculator produse în România şi comercializate de către comercianţi specializaţi; (ii) Înregistrarea societăților comerciale (și a persoanelor fizice autorizate) care produc în România programe destinate comercializării prin magazine. Există și excepții de la această regulă. De exemplu, nu este obligatorie înscrierea în RNPC a programelor realizate la comandă și care vor fi folosite de beneficiarul comenzii (clientul producătorului software), a programelor destinate utilizării interne de către instituţii, organizaţii, operatori economici – dacă nu sunt distribuite prin magazine, etc.

Sancțiunea?

Neînregistrarea sau neînscrierea în RNPC este contravenţie: amendă 2.000 – 10.000 lei pentru persoanele fizice și 6.000 – 30.000 lei – în cazul societăților comerciale. Condiţiile și procedurile privind cererile de înregistrare şi de înscriere, eliberarea certificatului de înregistrare sau alte operațiuni sunt detaliate în legislația specifică – destul de amplă și uneori ambiguă, fiind necesar ajutor specializat pentru a o interpreta corespunzător. Claudia Jelea

claudia.jelea@jlaw.ro Avocat & Consilier in domeniul marcilor @ IP Boutique

legal

TODAY SOFTWARE MAGAZINE

www.todaysoftmag.ro | nr. 22/Aprilie, 2014

sponsori