Today Software Magazine N22/2014

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 ctigi jocul automatizrii? Caching-ul imaginilor n aplicaii iOS
Ingeniozitate, perseveren i conectivitate BDD, Javascript i Jasmine Managementul performanei n organizaiile orientate spre proiecte O viziune din interiorul GPS Navigaie OpenXML - Noiuni introductive Trenduri n HR (II) AOP folosind Unity
Perspective asupra principiilor in design-ul orientat pe obiecte De ce dureaz att de mult s terminm un task? The Webs Scaffolding Tool For Modern Webapps Yeoman IMAGINE studiu al IT-ul clujean Machine learning in the Cloud Dezvoltare rapid de aplicaii web cu Oracle APEX
6 CCC - A shot of programming

George Platon
36 Trenduri n HR (II)
Andreea Prvu
7 Bine ai venit la Techsylvania!

Vlad Ciurca
38 Perspective asupra principiilor n design-ul orientat pe obiecte

Ctlin Tudor
8 Cluj Innovation Days, 20-21 martie 2014

Andrei Kelemen
40 Machine learning in the cloud

Roland Szabo
10 Ingeniozitate, perseveren i conectivitate

Dhyan Or
42 Dezvoltare rapid de aplicaii web cu Oracle APEX

George Bara
11 Startup fr bani? Modelul de investiii Startcelerate

Tudor Brlea i Gabriel Dombri
44 O viziune din interiorul GPS Navigaie

Echipa iOS Skobbler
14 Cum ctigi jocul automatizrii?

Mihai Cristian
46 IMAGINE studiu al IT-ul clujean

Dan Ionescu
18 iOS image caching. Libraries benchmark

Bogdan Poplauschi
48 Managementul performanei n organizaiile orientate spre proiecte din Romnia

Adina Grigoroiu, CAPM
21 THE WEBS SCAFFOLDING TOOL FOR MODERN WEBAPPS Yeoman

Rzvan Ciriclia
51 Lumy.ro usability testing

Daniela Ferenczi
23 OpenXML Noiuni introductive

Florentina Suciu i Gabriel Enache
52 Optimizarea de ce ar merita efortul?

Tibor Laszlo
26 BDD, Javascript i Jasmine

Bogdan Cornianu
55 AOP folosind Unity

Radu Vunvulea
30 De ce dureaz att de mult s terminm un task?

Gabriela Filipoiu
58 Drept de autor i software. Cteva aspecte practice pentru programatori

Claudia Jelea
33 Metodologia Lean pentru Requirements Engineering

Radu Orghidan
editorial
Ovidiu Man, 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 comunitii i de reamintire a principiilor Agile, foarte importante n realizarea proiectelor inovative. Recent, s-a introdus o lege prin care se reglementa prezena dronelor. Practic nu ai voie s ridici drona n zone de locuine, accesul fiind legal n spaiile deschise, filmatul nu este permis,dar nu se restricioneaz fotografierea aerian. Nu vreau s comentez exact condiiile legii, dar n ceea ce privete dronele de dimensiuni mici, adresate publicului larg i care au mai puin de un kilogram, dispoziile legii se ncadreaz n limitele acceptabile ale bunului sim. Totui, din pcate, n cteva zile, ceea ce era perceput ca o tehnologie fantastic la care muli se uitau cu admiraie i pe care doreau s o obin s-a transformat n ceva interzis. Pn nu demult prima ntrebare pe care o primeam n atunci cnd ridicam drona, era costul acesteia, acum prima ntrebare este dac e legal. Lipsa de informare corect i plcerea exagerri au fost din totdeauna cauzele unei percepii deformate. n cazul dronelor, unul dintre efectele acestei false percepii este o limitare a curiozitii i a inovaiei publicului larg n aceast nou cucerire a tehnicii, care este drona. Aceasta n condiiile n care asistm la o curs a celui ce va reui s le foloseasc comercial pe scar larg, iar exemplul cel cel mai cunoscut n aceast direcie este Amazon. Trecnd peste consecinele negative, aceasta este o bun lecie pentru cei ce conduc echipe i companii, un ndemn pentru o mai bun analiz a impactului legilor restrictive. O supralicitare a rolului de prevenie a incidentelor , pe care i-l arog de fapt orice lege, poate duce la intimidrrea spiritului antreprenorial. Revenind la conferina 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 funcie de evoluia proiectului. Numrul 22 a avut tema principal tehnologiile cloud ,iar acest lucru este reflectat n paginile revistei. ncepem cu cteva impresii de la Cluj Innovation Days.V adresm cu o invitaie 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 Glasses, pentru ca n cea de-a doua zi s asistm la o serie de discuii 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 fr bti de cap pentru antreprenori din perspectiva implementrii, iar pentru companii o conectare la inovaia local i din UK.Cum ctigi jocul automatizrii?,deschide seria articolelor tehnice. Acesta propune o foarte interesant ierarhizare pe nivele a celor ce automatizeaz testarea aplicaiilor i propune de asemenea o platform de lucru. Eficiena caching imaginilor pe platforma iOS este abordat i demostrat prin cteva benchmark-uri.mbuntirea productivitii este analizat n articolul despre Yeoman. Celor curioi de coninutul unui fiier Excel xlslx v recomand articolul OpenXML - Noiuni 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 performanei n organizaiile orientate spre proiecte din Romnia. O analiz a programrii orientate pe obiect din perspectiva entropiei Shannon o putei gsi n Perspective asupra principiilor n design-ul orientat obiect iar Machine learning in the cloud ne prezint soluii online pentru nvarea automat din perspectiva inteligenei artificiale. ncheiem propunerile noastre cu IMAGINE studiu n IT-ul clujean, studiu care a urmrit percepia companiilor clujene din perspectiva studenilor. V dorim o lectur plcut !!!
Fondator al Today Software Magazine
Ovidiu Man
nr. 22/Aprilie | www.todaysoftmag.ro
Redacia Today Software Magazine

Fondator / Editor n chief: Ovidiu Man ovidiu.matan@todaysoftmag.com Editor (startups i interviuri): Marius Mornea marius.mornea@todaysoftmag.com Graphic designer: Dan Hdru dan.hadarau@todaysoftmag.com Copyright/Corector: Emilia Toma emilia.toma@todaysoftmag.com
Tudor Brlea Dhyan Or
Lista autorilor
do@socialrehub.info CEO & Co-fondator @ Social ReHub
Claudia Jelea
claudia.jelea@jlaw.ro Avocat & Consilier n domeniul marcilor @ IP Boutique
Andrei Kelemen
Director executiv @ IT Cluster
andrei.kelemen@clujit.ro
Roland Szabo
roland.szabo@3pillarglobal.com Junior Python Developer @ 3 Pillar Global
Traductor: Roxana Elena roxana.elena@todaysoftmag.com Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com Contabil : Delia Coman delia.coman@todaysoftmag.com
tudor@startcelerate.com
Vlad Ciurca
vlad@techsylvania.co Product Guy. Tech Events Producer. Connector @ Techsylvania
Co-fondator @ Startcelerate
Radu Orghidan
radu.orghidan@isdc.eu Requirements engineer @ ISDC
Ctlin Tudor
ctudor@ixiacom.com Principal Software Engineer @ Ixia
Today Software Solutions SRL

str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag ISSN 2284 6352
Produs de
Gabriela Filipoiu
gabriela.lipoiu@accenture.com Software Engineering Analyst @ Accenture
Gabriel Enache
gabriel.enache@fortech.ro Software engineer @ Fortech
Rzvan Ciriclia
razvan.ciriclia@betfair.com Software engineer @ Betfair
Mihai Cristian
mihai.cristian@hp.com Test Automation Engineer @ HP
Claudiu Cosar
claudiu.cosar@3pillarglobal.com Software engineer @ 3Pillar Global
Bogdan Poplauschi
Senior iOS Developer @ Yardi Romania
bogdan.poplauschi@yardi.com
Adina Grigoroiu, CAPM

Trainer i consultant @Colors in Projects
adina.grigoroiu@confucius.ro
Florentina Suciu
Software engineer @ Fortech
orentina.suciu@fortech.ro
Copyright Today Software Magazine

Reproducerea parial sau total a articolelor din revista Today Software Magazine fr acordul redaciei este strict interzis. www.todaysoftmag.ro www.todaysoftmag.com
George Bara
gbara@sdl.com Business Consultant @ SDL
Tibor Laszlo
tibor.laszlo@improving-it.com Partner & Consultant @Improving-IT
www.todaysoftmag.ro | nr. 22/Aprilie, 2014
eveniment
curt, intens i din ce n ce mai popular, CCC (Catalysts Coding Contest) a devenit un fel de atracie sezonier pentru programatorii clujeni i nu numai. Concursul Catalysts Coding Contest (http://contest.catalysts.cc ) a nceput n anul 2007 n Austria cu un numr relativ mic de participani, dar feedback-ul primit a fost peste ateptri! n prezent, suntem la ediia cu numrul 18 a concursului care a ajuns s se extind att n Romnia (Cluj) ct i n India. Concursul a cptat notorietate n Cluj nc din 2011 de cnd a nceput s se desfoare i pe plaiurile romneti. De ce notorietate? Datorit structurii sale inovatoare. Fiecrui participant i se d la dispoziie 4 ore s rezolve o singur problem, structurat pe 7 nivele. Nu exist constrngeri de limbaj, concurentul putnd s scrie n orice limbaj de programare dorete i se pot forma chiar i echipe de maxim 3 persoane. Prerile despre problem au fost diverse, dar majoritatea converg nspre a fost greu!. Dificultatea crete n mod evident, o dat cu nivelul, astfel nct la ultimul nivel ajung n medie maxim 3 sau 5 concureni. Numrul participanilor a crescut n mod constant att n Cluj ct i n celelalte locaii ajungnd la ultima ediie la un total de 600 de concureni! Condiiile de participare sunt ct se poate de simple: Echip de maxim trei persoane cu condiia s se foloseasc un singur calculator / echip. Nu exist restricii asupra limbajelor de programare. Nu exist restricii asupra resurselor permise (cri, internet, etc.). Concurentul (sau echipa) trebuie s se nregistreze n prealabil online, pe site-ul oficial al concursului ct i la faa locului, la nceperea concursului. Platforma CCC (https://catcoder.catalysts.cc) ofer posibilitatea de a participa online la concurs, fr a fi nevoit s se fi prezent fizic la vreuna din locaii. Cu toate acestea, concurenii care aleg s participe online nu vor putea fi premiai cu premiile n bani. Preri i o prezentare general a concursului pot fi gsite aici:
CCC - A shot of programming
Exemplu de problem: The Harvester
La primul nivel al acestei probleme se d un cmp al unul fermier (Dave) care e parcelat n segmente egale n X linii i Y coloane. Fiecare segment are asociat un numr de la 1 la X*Y. Iniial se cere s se afieze cea mai bun posibilitate de a parcurge parcele n timpul cel mai scurt. Una dintre soluii este s plece din stnga sus, mergnd n serpentine nspre ultima parcel din dreapta jos.Vezi figura de mai jos:
La cel de-al doilea nivel, juctorului i se impune o constrngere: tractorul nu e neaprat s plece din poziia de stnga sus! La nivelul 3 tractorul trebuie s aib posibilitatea s mearg att de pe o coloan pe alta (E V i invers) ct 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 posibiliti de a parcurge toate parcelele de pmnt. Catalysts Coding Contest se dovedete a fi un mare succes att pentru noi ca firm, ct i pentru concurenii care reuesc s acumuleze cunotine noi i s ntlneasc oameni pasionai de programare i de rezolvarea problemelor dificile.
CCC n India!
Dup cteva luni de planificare, zilele de 9 i 15 martie 2014 ne-am bucurat s putem gzdui primul concurs CCC n India, n Kolkata respectiv Kharagpur. Numrul de participani a fost de ~350 de participani dintre care jumtate au ales s concureze n echipe de dou persoane. Detalii i poze gsii pe site-ul oficial al concursului: www.catalysts.cc/en/.
George Platon
George.Platon@catalysts.cc Software developer @ Catalyst
nr. 22/Aprilie, 2014 | www.todaysoftmag.ro
TODAY SOFTWARE MAGAZINE
eveniment
iind situat n apropiere de Belgrad, Budapesta, Sofia, Kiev sau Bucureti, Cluj-Napoca este un ora cu o poziie strategic n Europa de Est. Capital european a tineretului n 2015 i unul dintre cele mai ospitaliere orae din Europa potrivit Comisiei Europene, Cluj-Napoca are foarte multe oferit nu doar n ceea ce privete turismul, mncarea sau locurile extraordinare care pot fi vizitate, dar i atunci cnd vorbim despre ecosistemul IT local: cu peste 4000 de absolveni n domeniu n fiecare an, Clujul se bucur de un numr mare de tineri cu talent tehnic ale cror iniiative inovatoare devin din ce n ce mai cunoscute pe plan internaional. n acest context este fireasc apariia Techsylvania, cel mai mare eveniment tech din regiune i unul dintre cele mai importante din Europa Central i de Est. Prima ediie Techsylvania se va desfura ntre 31 mai i 2 iunie i va aduce mpreun unele dintre cele mai creative persoane din regiune, experi tehnici i inovatori care i vor mprti propriile experiene i cunotine pentru a contribui la dezvoltarea tehnologic i creterea gradului de inovaie din Cluj-Napoca. Techsylvania debuteaz pe data de 31 mai cu un hackathon cu durata de 24 de ore i continu pn n 2 iunie cu o conferin de o zi, care va aduce n faa audienei unii dintre cei mai apreciai profesioniti n domeniul tehnologiei la nivel internaional. Hackathon-ul care va avea loc se adreseaz dezvoltatorilor care i doresc s pun bazele unor aplicaii cu potenial disruptiv n domeniul tehnologiilor connected i wearable. n plus, cei peste 100 de participani la eveniment vor avea ocazia s testeze dispozitivele puse la dispoziie 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 aplicaii i produse n domeniu. Participanii la eveniment pot veni alturi de echipele lor sau se pot altura unei alte echipe i au obiectivul de a construi o aplicaie funcional de-a lungul evenimentului. La final, fiecare echip i va prezenta produsul n faa audienei pentru a convinge publicul de potenialul acestuia. Cele mai bune proiecte vor fi premiate, iar primele 3 echipe vor primi bilete de acces la conferina care va avea loc pe data de 2 iunie i, mai mult dect att, vor avea ansa s i prezinte produsele n faa ntregii audiene a Techsylvania. Cea de-a doua parte a evenimentului este conferina, unde sunt ateptate peste 200 de persoane, speakeri i invitai de excepie din ntreaga lume. Pasionaii de tehnologie vor avea astfel ocazia s fie inspirai, s ntlneasc poteniali investitori, parteneri sau colaboratori i mai mult dect att, s interacioneze n mod direct cu oameni cu preocupri i pasiuni similare. Techsylvania se remarc n peisajul evenimentelor locale prin calitatea speaker-ilor care vor urca pe scena evenimentului pentru a-i mprti propriile experiene i a discuta despre inovaie n tehnologie i dezvoltare de produse. Printre acetia se numr: Marcus Segal (Ex-COO Casino Division Zynga & Entrepreneur in Residence la The Summit, strateg i manager de operaiuni 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 ntlnirii anuale a 250 de CEO ai celor mai importante companii n tehnologie la nivel mondial), Jack Levine (Fondator i CEO Electric
Bine ai venit la Techsylvania!
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 funcie de locaie, companie care a achiziionat 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 pn n prezent i a fost menionat n publicaii precum New York Times, USA Today sau Today Show din Statele Unite). Dei la prima ediie, Techsylvania promite s revoluioneze ecosistemul tech local i s aduc o contribuie important la dezvoltarea acestuia. Organizat de Vlad Ciurca i Oana Petru, Techsylvania se bucur de susinerea unei echipe experimentate i a unui board de advisor-i excepional. Rezultatele nregistrate pn n prezent de oamenii din spatele proiectului reprezint o garanie pentru succesul acestuia: membrii echipei au organizat trei ediii de succes ale Startup Weekend Cluj, au dezvoltat comuniti de business promitoare printre care se numr Romanian Managers Cluj cu peste 800 de membri i Maramure Business Club, i au iniiat evenimente educaionale pentru studeni n cadrul #defineCluj. Pasionaii de tehnologie, inovaie i produse cu potenial disruptiv nu trebuie s rateze prima ediie a Techsylvania care va avea loc ntre 31 mai i 2 iunie n Cluj-Napoca! Mai multe detalii despre program i invitaii evenimentului sunt disponibile pe siteul Techsylvania http://techsylvania.co, iar primii 25 de participani beneficiaz de o ofert special i pot achiziiona 2 bilete la pre de 1. Ulterior, preul biletelor early bird va fi de 69 EUR, iar nregistrrile pot fi efectuate online pe site-ul evenimentului. Techsylvania se adreseaz tuturor inovatorilor i pasionailor de tehnologie care i doresc s discute n mod direct cu unii dintre cei mai buni profesioniti n domeniu din regiune, s nvee 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
eveniment
A doua ediie a Cluj Innovation Days (CID) a fost, din toate punctele de vedere, un succes. Pe perioada celor dou zile Cluj-Napoca a devenit capitala inovaiei n Romnia. Am reuit, nc o dat, s afirmm oraul nostru drept unul dintre locurile unde se ntmpl 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 internaional care este centrat pe ncurajarea inovaiei, cercetrii i antreprenoriatului drept ingrediente cheie nspre construirea sustenabilitii n dezvoltarea afacerilor i a comunitii. Obiectivul nostru pe termen lung este s facem din acest eveniment un reper internaional pentru oportuniti de parteneriate ntre mediul academic, cel de afaceri i autoritile publice, acolo unde inovaia i transferul tehnologic sunt poduri de ncredere, de legtur ntre diversele sectoare. Evenimentul din acest an a fost organizat de Cluj IT Cluster i i-a propus s reuneasc pe toi cei mai sus menionai, mai exact oameni de tiin i studeni, reprezentani ai guvernului, conductori i antreprenori. Pe parcursul celor dou zile, peste 400 de participani au fost implicai n conferine i discuii dedicate rolului inovaiei i antreprenoriatului n dezvoltarea socio-economic. Evenimentul a fost gzduit cu amabilitate Facultatea de tiine Agricole i Medicin Veterinar din Cluj-Napoca, una dintre cele mai venerabile i totodat dinamice instituii de nvmnt superior din Romnia. V voi lsa pe dumneavoastr s hotri dac am avut sau nu succes, prezentndu-v faptele i cifrele conferinei. 51 speake r i : 22 Ple nar, 12 Arta Inovaiei, 8 Facilitarea Antreprenoriatului, 9 Etalarea Inovaiei 13 speakeri internaionali, 2 Membri ai Comisiei Europene, 4 Directori i ali delegai ai Comisiei Europene. 18 ore de prezentri i discuii
Cluj Innovation Days, 20-21 martie 2014

Participarea la conferin n cele dou zile numr: 200+ participani din mediul de afaceri 130+ participani din mediul academic 40+ oficiali publici 40+ studeni n ceea ce privete coninutul CID2014 a fost foarte variat i organizat pe patru direcii principale: Sesiunea Plenar, Arta Inovaiei, Facilitarea Antreprenoriatului i Etalarea Inovaiei. Muli dintre oratorii i participanii notri i-au exprimat impresiile p ozitive n legtur c u coninutul i organizarea evenimentului. Pe parcursul primei zile de conferin, am avut vorbitori importani care au susinut discursuri eseniale i au transmis mesaje ncurajatoare, cum ar fi cel al domnului Dacian Ciolos,Comisar European, Direcia General Agricultur i Dezvoltare Rural, d-nul Johannes Hahn, Comisar European, Direcia General Politic Regional i Urban, dl. Mihnea Costoiu, Ministru Delegat pentru nvmntul Superior din Guvernul Romniei i un numr de ali oficiali importani din guvern i conducerea local. Arta Inovaiei a ncercat s capteze esena 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 participanii au dezbtut componentele principale ale managementului inovaiei i modalitile de exploatare a rezultatelor sale, prin generarea de cretere i profit. Pe parcursul celei de-a doua zile a conferinei, 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 finanarea de care au nevoie i cum s abordezi afacerile global. Etalarea Inovaiei a ncercat s motiveze audiena cu o serie de poveti de succes. Persoanele din spatele unor asemenea poveti ne-au mprtit experienele lor. Planul media pe care l-am conceput pentru eveniment a generat o acoperire mare n pres. Potrivit ageniei noastre de PR, au existat de dou ori mai multe relatri dect n medie pentru o conferin de aceste dimensiuni. Acoperire Media: A ctiviti media: 4 comunicate de pres / 5 interviuri/solicitri de informaii; Conferina de pres : 24 publicaii naionale prezente i peste 30 de jurnaliti; Publicaii/TV: 10 publicaii offline tipar / 170+ publicaii online / 4 emisiuni TV/tiri; Valoarea total a acoperirii media a fost estimat la 80.422 euro. Evenimentul a avut propriul su website, www.clujinnovationdays.com; din momentul lansrii sale i pn imediat dup eveniment, am avut 1857 de vizitatori unici i un total de peste 10.200 vizualizri de pagini.
red c ai ales cel mai bun moment pentru a crea aceast platform (Cluj Innovation City Cluj oraul inovaiei) i vei avea tot sprijinul meu i al Comisiei Europene pentru a materializa asemenea idei aductoare de valoare. V mulumesc i aflai c putei conta pe sprijinul meu - D-nul. Dacian Ciolos, Comisar European, Direcia General Agricultur i Dezvoltare Rural
A dori s nchei prin a mulumi tuturor partenerilor notri, n special BRD Group Societe General, Microsoft i Huawei. O meniune special pentru gazdele noastre, Institutului de tiine ale Vieii din Campusul USAMV. i, bineneles, cu invitaia la ediia din anul urmtor a Cluj Innovation Days.
Andrei Kelemen
Director executiv @ IT Cluster
andrei.kelemen@clujit.ro
eveniment
Competiia const n implementarea de roboi sumo autonomi, capabili s identifice i s elimine de pe suprafaa de joc robotul advers n competiii de tip 1 la 1. n cadrul acestei ediii sunt nscrise peste 15 echipe de studeni care au muncit luni n ir la realizarea robotului aplicnd cunotine de inginerie electric, mecanic, automatic i calculatoare. Pentru a putea construi roboii, studenii au dezvoltat un proiect complex care implic att partea tehnic ct i cea de management investind sume de bani de ordinul a sute sau chiar mii de euro. Echipele sunt formate din maximum patru studeni. Competiia respect regulile internaionale de sumo robotic n ceea ce privete dimensiunile suprafeei de joc precum regulile de desfurare i de angajament. Roboii respect prevederile constructive ale clasei medii, mas total: maxim 3kg, dimensiuni 20 x 20 cm, fr limit de nlime. Echipele cu cele mai bune performane vor fi premiate i vor fi ajutate s participe la Campionatele Internationale de Robotic de la Viena i la alte competiii importante de profil. Evenimentul BattleLab Robotica 2014 este susnut de companiile partenere: BOSCH, msg systems Romania, Skobbler, Wenglor i sponsorii: EVOcomputers, Frequentis, Hama, Microchip, RoboFun, Madd Electronics Group. Sunt ateptai peste 200 de spectatori curioi s vad aceste lupte sumo ntre roboi n data de 12 aprilie n incinta Universitii Tehnice, pe strada Bariiu nr. 26, n amfiteatrul P03 de la ora 10:30 Mai multe informaii despre eveniment pot fi gsite la adresa www.battlelab.ro sau pe Facebook la adresa www.facebook.com/ BattleLabRobotica BEST (Board of European Students of Technology) este o organizaie internaional, nonprofit, n continu cretere. nc din anul 1989, BEST ofer studenilor din toat Europa posibilitatea de a ajunge la o mai bun nelegere a culturilor i a
BattleLab Robotica cea mai mare competiie sumo de roboi din Transilvania
acultatea de Inginerie Electric din cadrul Universitii Tehnice din ClujNapoca n colaborare cu organizaia studeneasc BEST ClujNapoca te invit n data de 12 aprilie 2014 la a patra ediie a competiiei BattleLab Robotica. Evenimentul se va desfura pe data de 12 aprilie n incinta Universitii Tehnice, pe strada Bariiu nr. 26, n amfiteatrul P03 de la ora 10:30. societilor pentru a-i dezvolta capacitatea de a lucra n diverse medii culturale. Un alt scop este de a crea o legtur ct mai strns 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 Universitii Tehnicedin ClujNapoca. Scopul nostru este de a oferi toate condiiile pentru dezvoltare personal, realizat prin educaie complementar, ncurajnd fiecare student s participe la proiecte inovative i provocatoare, cum ar fi: training-uri, workshop-uri, suport n carier (Jobshop, Competiii inginereti), cursuri academice etc. n anul 1960 ia fiin, n cadrul Facultii de Mecanic, secia de Inginerie Electric, care n 1964 devine Facultatea de Inginerie Electric, cu 528 de studeni. Dup 13 ani de la nfiinare, n 1977, Facultatea se dezvolt prin seciile noi de Electronic, respectiv, Telecomunicaii i Automatic i Calculatoare. Misiunea Facultii de Inginerie Electric este realizarea la un alt nivel de calitate a nvmntului i cercetrii tiinifice, n domeniile Inginerie Electric, Inginerie Energetic, tiine Inginereti Aplicate, Inginerie i Management, n context naional i internaional, rspunznd necesitii de dezvoltare intelectual, profesional i social a individului i de progres a societii romneti. Mai multe informaii pe site-ul: ie.utcluj.ro
interviu
atorit recentei extinderi a rutelor de zbor din Cluj, pot acum s ajung cu maina n 15 minute la aeroport, apoi s iau un avion, practic, ctre orice loc din Europa sau Orientul Mijlociu i s ajung acolo n aceeai zi, la timp pentru o ntlnire. n vizita mea recent n Israel, am avut ocazia s ntlnesc nite oameni remarcabili: un laureat al premiului Nobel, foarte renumit i un investitor faimos, care este de asemenea i un activist n probleme sociale. Mai nti, am fcut cunotin, 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 studenilor conceptul i practica nceperii propriei lor afaceri i a invitat oameni de afaceri locali care i-au spus povetile carierei lor. Toi acetia au nceput de la zero i treptat au ajuns lideri n Dan Shechtman domeniile lor respective. Propria lui poveste este una neobinuit. El a descoperit mai nti ceea ce este cunoscut acum drept cvasi-cristale n 1982, dar nimeni nu a crezut c e ceva serios. Toi oamenii de tiin au luat n derdere descoperirea sa, de la colegii de cercetare ai lui Shechtman i pn la renumitul dublu laureat al Premiului Nobel, Linus Pauling, care a fost citat referindu-se la Shechtman, spunnd: Nu exist aa ceva ca cvasi-cristale, ci numai cvasi-savani. Shechtman a continuat s cread n descoperirea sa, fr 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 trziu, el a reuit s demonstreze greeala criticilor si i a ctigat premiul Nobel. De atunci, a inut mereu discursuri n ntreaga lume, iar programul su este ncrcat pentru nc mult timp. Cnd l-am rugat s vin i s vorbeasc n Romnia, mi-a putut oferi cteva date probabile de vizitare abia pentru 2016. Alt persoan important ntlnit luna trecut la un eveniement dedicat startupurilor a fost Erel Margalit . n calitate de membru recent ales al parlamentului, el vorbea despre iniiativele sale n ceea ce privete oferirea de mai multe posibiliti comunitilor mai puin favorizate din Israel. Margalit este mai bine cunoscut prin firma sa de investiii, Erel Margalit Jerusalem Venture Partners, care a gestionat peste 1 miliard $ n investiii, transformndu-i n 17 miliarde $, ludndu-se cu cteva 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 ctigat din investiii n tehnologie, apoi Margalit s-a ndreptat nspre proiecte sociale i culturale n Ierusalim, concentrndu-i atenia pe cartierele defavorizate i familiile srace. De asemenea, a deschis un club unde au loc spectacole i un incubator pentru startup-uri chiar lng acesta, afirmnd c profesionitii IT trebuie s aib legturi cu muzicieni i artiti din alte domenii pentru a deveni creativi. Margalit spune c Ierusalimul ar trebui s atrag tineri prin oferirea de slujbe high tech, finanare startup i via cultural. Margalit mai spune c este pasionat de a detecta n ce anume exceleaz oamenii i comunitile precum i de construirea unui cluster n jurul unei anumite industrii care are ansa de a concura la nivel mondial. Cnd nu mplinise nc treizeci de ani, s-a ntlnit cu Primarul Ierusalimului i i-a sugerat s transforme oraul bogat n istorie, dar srac din punct de vedere economic ntr-un centru de tehnologie de vrf i s invite juctori internaionali s i construiasc centrele R&D n Ierusalim. Acum, el face acelai lucru pentru oraul mai puin cunoscut, din deert, Beer Sheva. Ideea este s fac din acesta capitala mondial a securitii informaiei, atrgnd companii precum Telekom, IBM, Lockheed Martin, Oracle i EMC, care vor investi, mpreun cu JVP i Ben Gurion University n Cyber Spark-ul din Beer Sheva. Beer Sheva este, din ntmplare, un ora nfrit cu ClujNapoca. Este al aptelea ora ca mrime din Israel, cu aproximativ 200.000 de locuitori i cu peste 20.000 de studeni, muli dintre acetia, atrai din alte pri ale rii. Muli ani, oraul a fost neglijat i lsat pe dinafara bugetelor naionale de dezvoltare; tinerii s-au mutat la Tel Aviv i nu s-au mai ntors, iar populaia a devenit din ce n ce mai btrn i mai srac. Dar n ultimii ani, Beer Sheva a reuit s atrag din nou interesul, mulumit n parte unui nou primar, mai dinamic, i unui campus universitar vibrant. Oraul a fost legat recent de Tel Aviv, care se afl la o distan de 113 km, printr-un tren rapid care face mai puin 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 abin de la o comparaie ntre cele dou orae nfrite. n primul rnd, gsirea unei teme n care comunitatea IT din Cluj s poat inova i concura la nivel mondial, atrgnd pioni internaionali drept parteneri i investitori, ar face oraul atractiv pentru locuitorii si i pentru ali romni i strini. n al doilea rnd, mi-ar plcea tare mult s pot ajunge de la Cluj la Bucureti ntr-un timp rezonabil, fie cu un tren de mare vitez, o autostrad bun sau o linie aerian low cost. Cltoriile accesibile ar permite oamenilor s mearg la ntlniri n capital, dimineaa, poate s vad un concert seara i s se ntoarc acas n acceai noapte. Aceasta ar aduce, de asemenea, mai muli oameni i mai multe idei din Bucureti, n beneficiul ambelor orae.
Dhyan Or
do@socialrehub.info CEO & Co-fondator @ Social ReHub
Ingeniozitate, perseveren i conectivitate
10
startups
Startup fr bani? Modelul de investiii Startcelerate
tim cu toii c startup-urile au ajuns un hot trend, mai ales n ultimii 7-8 ani, cu poveti de succes care ne uimesc, dar ne dau i o consistent doz de serotonin. Dac eti n technologie, Silicon Valley este fr ndoial un etalon i un fel de ar a speranei pentru orice antreprenor din aceast zon. i pe bun dreptate. Replicnd mai mult sau mai puin 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 acelai model. cu dou condiii: 1) s existe bani de risc suficieni disponibili ntr-un stadiu ct mai timpuriu; 2) s existe un numr mare de antreprenori motivai s creeze startupuri. cnd sunt indicaii puternice (n sensul de hard data precum generare de revenue) c startupul are o ecuaie clar de ROI i o dat n calendar pentru break-even. Setarile acestea, chiar dac sntoase dintr-o perspectiv de risc, sunt oarecum ciudate i creeaz un mare impediment de
Modelul Silicon Valley
Orict de mult inovaie ar fi n antreprenoriatul technologic, modelul pe care ecosistemul acesta se dezvolt este unul surpinztor de liniar i rar contestat. El presupune mai muli actori care se afl ntr-un dans aproape nupial n jurul unei sperane comune: s creeze ceva (un produs sau un business) n ct mai scurt timp, n aa fel nct printr-o form de exit toi cei care i-au asumat riscul extrem de mare de a-i pune resursele ntr-o asemenea aventur s poat s i multiplice investiia. Aceti actori sunt de regul: fondatorii, investitorii de diferite niveluri (de la Angel Investors la Venture Capitalists ), instituiile de accelerare (att acceleratoare, ct i incubatoarele) i o ntreag reea de furnizori de servicii. Flow-ul tipic acestui model e de asemenea liniar, dei se vrea geometric: investitorii scot nite 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 traciune), startupul se lanseaz ntr-o curs de growth astfel nct aib argumente suplimentare de a primi o alt investiie, care s i permit s mai experimenteze n gsirea cum spune Steve Blank a unui business model scalabil i profitabil. i lucrurile se iau de la capt, pn se ajunge fie la un exit de succes, fie la o mpotmolire n faliment. Ecuaia fundamental a riscului balanseaz perfect ecuaia valorii n acest sistem: cu ct o resurs extern apare mai devreme ntrun startup, cu att riscul este mai mare i prin urmare valoarea ei este mai semnificativ raportat la equity-ul startup-ului. Mecanismul funcioneaz perfect n zon de vrf a spectrului (startup-urile de succes aduc beneficii majore pentru o mn de investitori i fonduri aventuroase), dar e falimentar pentru restul ecosistemului (majoritatea proiectelor antreprenoriale fie sunt blocate de lipsa de finanare, fie se mpotmolesc n cutare ntr-un limb fr ieire). i acest model poate funciona i aa
Modelul european: clona defect a Silicon Valley-ului

Ceea ce s-a ncercat n ecosistemele europene de startups funcioneaz pe aceeai structur, cu o excepie important: existena fondurilor de risc este mai restrns local i, nc mai i mp or t ant , d e c i ziile de investiii se bazeaz pe alt model de risc. S ne explicm. Diferena esenial dintre investitorii europeni i cei de pe coasta vestic american este c primii vor scoate o sum de investiii cu att mai dificil cu ct startupul este mai early stage i mai ne-validat. Aceti investitori, cu rare excepii, nu risc seed money (cteva zeci de mii de Euro) pentru a pune n pia un demo, de exemplu, sau pentru a testa ipoteze. Ei se ateapt ca fondatorii s-i fi asumat deja aceste riscuri i s fi trecut de acel stadiu. Muli dintre ei au o setare i mai sntoas: pun bani doar
11
startups
Startup fr bani? Modelul de investiii Startcelerate
dezvoltare a ntregului ecosistem. Dar aici intervine Startcelerate, ca un nou model de accelerare a dezvoltarii startupurilor printr-o nou structur investiional. cuantificabil n bani, ea este tratat ca un aport la capital (equity round). Pentru a adresa problemele din modelul existent, Startcelerate vine cu cteva soluii: Investitorii pot lua decizii calculate. Startcelerate va permite cutarea, analiza i compararea startupurilor pe baza unui profil standardizat i a unor metrici relevani 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 esenial. Implicarea investiional poate fi una gradual i multipl. Pentru a limita expunerea, fondurile i resursele pot fi alocate pas cu pas, atingerea unui obiectiv funcionnd ca declanatori pentru urmtoarea rund de investiie. Practic, startupul spune unde se afl, unde este urmtorul 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 rnd 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 preferenial. 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 att de investiii, ct i de acces la o zon de inovaie care uneori este dificil de integrat ntr-o companie al crei focus este s factureze ore de dezvoltare pentru clieni. De aceea, am i decis ca lansarea public a Startcelerate s fie fcut n Cluj, printr-un eveniment pilot de testare a modelului n ecosistemul antreprenorial local, la sfritul 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.
Startcelerate: direct resurse, nu bani i mai mare transparen a progresului
Cnd am nceput s lucrm la modelul Startcelerate, am pornit de la urmtorea setare: ce ar fi ca startupurile s aib un mod n care s fie conectate cu companii puternice de dezvoltare IT n aa fel nct 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 pltesc (fie care le folosesc 100%, fie c nu) pentru a-i crea un portofoliu investiional 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 oportunitile depesc de departe costurile ntr-o asemenea structur partenerial-investiional.
Soluiile Startcelerate
Startcelerate este setat ca o platform de investiii 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 soluii unor startupuri n schimbul unei forme de proprietate asupra unei pri din acel proiect. Pe de alt parte, startupurile au posibilitatea s acceseze direct resursele de care au nevoie pentru dezvoltare, cnd 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 tehAtta timp ct resursa investit este una nologic pe care o are (vorbim att de
Tudor Brlea
tudor@startcelerate.com
Gabriel Dombri
gabriel@startcelerate.com
12
comuniti
Comuniti 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 trecui n seciunea de organizatori. Luna aprilie ne aduce diverse evenimente precum prezena lui Adam Bien la Cluj, Project Tango Hackaton n Timioara sau Product Inception n Bucureti.
Calendar
Aprilie 10 (Cluj) Lansarea numrului 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/ Aprilie 14 (Cluj) Transylvania JUG - Adam Bien transylvania-jug.org/future-meetings/ meeting-47-cu-adam-bien Aprilie 14 (Cluj) Startup Lounge - hub:raum Incubating and Accelerating Innovation facebook.com/events/282160681951576/ Aprilie 24 (Cluj) Lets meetup and discuss about project management meetup.com/PMI-Romania-Cluj-NapocaProject-Management-Meetup-Group/ events/173955922/ Aprilie 25 (Timioara) 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 (Bucureti) Android Testing and Continuous Integration it-events.ro/events/android-testing-continuous-integration/ Mai 8 (Bucureti) Product Inception it-events.ro/events/product-inception/ Mai 15-16 (Cluj) Romanian Testing Conference www.romaniatesting.ro
Transylvania Java User Group Comunitate dedicat tehnologiilor Java. Website: www.transylvania-jug.org Data nfiinrii: 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 nfiinrii: 06.02.2012 /Nr. Membri: 1321/Nr. Evenimente: 18 Romanian Testing Community Comunitate dedicata testerilor. Website: www.romaniatesting.ro Data nfiinrii: 10.05.2011 / Nr. Membri: 730 / Nr. Evenimente: 2 Cluj.rb Comunitate dedicat tehnologiilor Ruby. Website: www.meetup.com/cluj-rb Data nfiinrii: 25.08.2010 / Nr. Membri: 176/ Nr. Evenimente: 40 The Cluj Napoca Agile Software Meetup Group Comunitate dedicat metodelor Agile de dezvoltare software. Website: www.agileworks.ro Data nfiinrii: 04.10.2010 / Nr. Membri: 425 / Nr. Evenimente: 63 Cluj Semantic WEB Meetup Comunitate dedicat tehnologiilor semantice. Website: www.meetup.com/Cluj-Semantic-WEB Data nfiinrii: 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 nfiinrii: 10.02.2011 / Nr. Membri: 238/ Nr. Evenimente: 14 Tabra de testare Un proiect care i dorete s strng ct mai muli oameni care lucreaz ca testeri. Website: tabaradetestare.ro Data nfiinrii: 15.01.2012 / Nr. Membri: 294/ Nr. Evenimente: 28
13
testare
Cum ctigi jocul automatizrii?

n ziua de azi una dintre primele ntrebri care i sunt adresate ca inginer n testare este dac foloseti testarea automat. Cu siguran, n ultimii ani, testarea automat a fost i rmne un subiect la mod. Toat lumea vorbete despre ea, ncearc sa o foloseasc sau se plnge de ea. Cu toate acestea, ea rmne eminamente un subiect intern, fiecare companie dezvoltnd soluii proprietare, croite pentru produsele i nevoile proprii. Acesta este un lucru firesc avnd n vedere ca produsele difer mult, n special cnd vorbim de enterprise software, aa c e greu de crezut c vom putea folosi o singur soluie de automatizare indiferent de produsul dezvoltat. Acestea fiind spuse, dup civa ani petrecui n domeniul testrii automate, observnd att prile rele ct i cele bune, ajungi la un momentdat s te ntrebi: Cum ctigi jocul automatizrii? Articolul acesta ncearc s prezinte aspectele cheie ale dezvoltrii implementrii cu success a unei soluii de automatizare . Vom prezenta un ghid pas-cu-pas bazat pe soluia utilizat n momentul de fa de produsul HP Server Automation numit AXIS. Dei articolul se concentreaz n mare parte pe testarea automat a planului funcional (backend), ideile prezentate pot fi aplicate pentru orice soluie de testare automat indiferent de tehnologia utiltizat n dezvoltarea ei. cunoatem n primul rnd cum se joac jocul. Considerai partea aceasta ca fiind manualul de instruciuni pentru jocul nostru. Atunci ce este o soluie de automatizare? n viziunea noastr o soluie de automatizare este alctuite din trei elemente de baz: Framework-ul, Coninutul, Interfaa cu utilizatorul.
Mihai Cristian
mihai.cristian@hp.com Test Automation Engineer @ HP
Un framework de testare automat este de obicei definit ca fiind un set de presupuneri, Soluia 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
Framework-ul
14
www.todaysoftmag.ro | nr. 21/Martie, 2014
management
soluii de automatizare. Acesta se ocup de alocarea resurselor, execuia testelor, validarea opiunilor selectate i gestionarea mediului de testare utilizat. Este foarte important s utilizm un framework care se potrivete att cu tipul automatizrii propuse ct i cu produsul testat. Produsul nostru faciliteaz gestionarea de data center-e mari alctuite 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 fiierelor 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. Soluia 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 implementm premisele necesare testelor i s verificm validitatea operaiilor 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 cnd implementm o soluie de testare automat. Exist numeroase produse de automatizare pe pia pentru toate gusturile i, chiar n cazul n care implementam soluii proprii, acestea pot fi de ajutor. Un alt aspect cheie care trebuie luat n considerare cnd dezvoltm un framework este procesul de descoperire. Pe scurt acest proces va traduce informaia despre mediul de testare din limbajul produsului testat in limbajul framework-ului de automatizare. Folosind acest proces putem defini un mediu de testare, specificnd intele testelor i orice alt informaie considerat necesar, ntr-un format convenabil aplicaiei proprii nainte de a rula efectiv testele.

suportat de framework i de produs. Crearea coninutului necesit o bun nelegere a produsului ce va fi testat, astfel c echipele de testare ar trebui s joace un rol important n dezvoltarea testelor automate. backend, pe cnd altele s-ar putea s nu aib o interfa grafic (GUI) pe care s o automatizai. 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 asigurai c abordarea aleas se pliaz pe produsul testat. Putei s lucrai mpreuna cu echipa de development pentru a face produsul compatibil cu tipul de automatizare ales, ns acest lucru trebuie fcut ct 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 dorii s o automatizai. Dorii s automatizai execuia testelor sau validarea rezultatelor? Unele soluii de automatizare se concentreaz exclusiv pe partea de execuie, lsnd validarea rezultatelor n sarcina testerilor, n timp ce altele acoper ambele procese. Revenind la exemplul nostru putem vedea c AXIS este o soluie bun pentru nivelul 1. AXIS realizeaz doar automatizare backend. Testele sunt scrise n Python i implementeaz diferite scenarii apelnd metodele produsului expuse prin API, replicnd astfel comportamentul unui utilizator prin diferite script-uri. Validarea rezultatelor este de asemenea automatizat, testele verificnd valorile returnate de diferite metode prin compararea cu un set de valori predefinite i prezentnd 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 ai ales abordarea pentru soluia voastr de automatizare i ai verificat faptul c aceasta funcioneaz pentru produsul testat putei s trecei la umtorul nivel.
Interfaa cu utilizatorul
Framework-ul i testele automate sunt inutile dac nimeni nu le poate folosi. Una din cele mai ntltnite probleme n soluiile proprietare de testare automat este c doar specialitii n automatizare tiu cum s ruleze testele i cum s interpreteze rezultatele. La fel ca n cazul oricrui 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. Uurina de a utiliza un produs este unul din aspectele cheie ale unei soluii automatizare. Cu ct mai muli oameni utilizeaz soluia cu att 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 uurin. AXIS folosete 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 aceeai funcionalitate.
Jocul testrii automate
Coninutul
Coninutul este reprezentat de testele automate n sine. Este bine s avem o separare clar ntre framework i coninut astfel nct soluia de automatizare s poat fi folosit pentru mai multe produse. Testele n sine pot fi dezvoltate n orice limbaj de programare ales, att timp ct acesta este
Acum c tim ce este jocul automatizrii putem s ncepem s l jucm. Acest ghid v va da toate informaiile necesare pentru a construi propria soluie de automatizare. Este foarte important s nu srii peste nivele pentru c, cel mai probabil, vei fi nevoii s v ntoarcei la ele pentru a le parcurge la un moment dat. S nceap Nivelul 2: Povestea din spatele jocului jocul!!! S intrm n lumea jocului! Orice joc care merit jucat are i o poveste n spate. Nivelul 1: Caracterul vostru Dac vrem s nelegem contextul n care S ncepem cu nceputul. n primul au loc aventurile eroului nostru, merit rnd trebuie s alegei ce fel de juctor vei s cunoatem povestea nainte de a ncepe fi. Dorii s mergei spre automatizarea s atacm tot ce mic. interfeei grafice sau vei alege automaCum realizm acest lucru? Simplu, tretizarea backend? Poate amndou. Orice buie doar s revizuim procesul de testare alegere facei este important s definii existent. Trecei 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 cunoaterea produsului. Unele pro- zarea lor. Colaborai cu echipa de testare duse nu sunt compatibile cu automatizarea pentru a alctui o list cu testele ce trebuie
15
testare
Cum ctigi jocul automatizrii?
automatizate. Cele mai la ndemn exemple sunt suitele de regresie, suitele de teste smoke sau testele instalare a produsului. Identificai testele cheie care, n cazul n care nu trec, vor produce defecte cu prioritate mare. De asemenea, definii din start noiunea de Pass i Fail pentru teste cu scopul de a evita orice confuzii ulterioare. O alt operaiune ce trebuie aplicat la acest nivel este stabilirea unei legturi clare ntre testele manuale i cele automate. Aceast legtur v va ajuta s determinai gradul de acoperire al testelor. Poate c acest nivel nu pare foarte distractiv dar, dac facei acest efort acum, nainte de a ncepe efectiv s automatizai, vei vedea c rezultatele muncii voastre vor fi vizibile mult mai devreme. AXIS folosete anumite fiiere text ataate fiecrui test ce conin informaia ce leag testul automat de cel manual, sub forma unui numr de identificare. Acestea sunt folosite n procesul de raportare a rezultatelor testelor automate ctre sistemul de monitorizare utilizat de management. Considerai aceast parte ca o tabel de scor a jocului. Cu siguran vei dori ca lumea s tie la ce nivel se afl eroul vostru i ce misiuni a ndeplint. Odat ce avei lista de teste ce trebuie automatizate, condiiile de Pass/Fail i testele scrise ntr-un format agreat de echipa de automatizare putei s avansai la urmtorul nivel. teste i suntei sigur c testele sunt scrise ntr-un format ce faciliteaz automatizarea lor. E momentul s creai User Stories pentru efortul de automatizare. Fiecare user story trebuie estimat i trebuie s conin condiii clare ce determin momentul cnd este considerat ncheiat. Este important s facei progresul efortului de automatizare ct mai vizibil astfel nct celealte echipe vor ti cnd testele automate devin disponibile i ce funcionalitate acoper. Una dintre greelile des ntlnite la acest nivel este s ncercai s facei prea multe. Exist de obicei o presiune de a automatiza ct mai multe teste. Acest tip de automatizare nu este util pentru nimeni. Prin definirea clar a cerinelor vei ti exact ct trebuie s automatizai i cnd putei considera c o anumit component este acoperit de testele automate. Utilizai acest proces pentru toate obiectivele de automatizare propuse: regression, validare de build-uri, teste de instalare. Odat ce avei definite cerinele pentru toate sarcinile de automatizare, putei trece la nivelul 4. ncercai jocul multiplayer, deoarece ctigi mai mult experien, cnd te afli ntr-un grup. Colaborai cu echipele de testare pentru a v asigura c testele sunt rulate i acoper toate aspectele definite n cerine. Ei sunt singurii care pot decide cnd misiunile voastre sunt ndeplinite. Reinei c n calitate de inginer de automatizare, scopul vostru este s implementai i s oferii suport pentru soluia de automatizare, nu s rulai teste pentru alte echipe i s investigai rezultatele lor. Odat ce ai ndeplinit misiunile definite i coechipierii confirm acest lucru, putei avansa la urmtorul nivel.
Nivelul 5: Echipamentul este tot!
Nivelul 4: Mcinarea
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 alegei clasa caracterului vostru. Alegerea clasei potrivite pentru abordarea decis va face eroul vostru mult mai eficient. Vrei s alegei calea lupttorului, a magului sau cea a arcaului? Fiecare alternativ are punctele ei forte dar i slbiciunile ei i va influena fundamental modul n care vei juca jocul. n acest nivel trebuie s definii ce dorii s fac soluia de automatizare propus i cum vrei s realizai acest lucru. Va trebui s definii cerine care vor reprezenta scopurile soluiei. n acest fel vei avea un standard clar pentru contorizarea progresului i vei ti momentul n care soluia propus este gata de a fi folosit. S presupunem c vrei s automatizai testele de regresie pentru un produs. Datorit faptului c ai parcurs deja nivelele 1 i 2, ar trebui s avei definit o list de teste ce acoper toate aspectele produsului ce trebuie verificate. Vei ti de asemenea care sunt condiiile de Pass/Fail pentru
Am petrecut destul timp studiind povestea din spatele jocului i crend caracterul nostru. E momentul s ncepem jocul. Orice gamer tie c nainte s ajungi s ai un erou cu adevrat puternic e necesar sa macini nti. Acest lucru presupune ndeplinirea unor misiuni mai uoare la nceput pentru a crete abilitile eroului, a-i mbunti echipamentul i a crete n experien. n orice joc, ntr-o prim etap eroul este implicat nr-o serie de misiuni facile pn s ajung la adversarii cu adevrat puternici. Din pcate nu exist nici o scurttur la nivelul 4. ns, trecnd de nivelul 3 vei avea la dispoziie un set clar de cerine sau misiuni, pe care trebuie s le ndeplinii. O idee bun este s ncepei cu testele de smoke. Acestea sunt teste de baz care, teoretic, ar trebui s fie mai uor de automatizat, i care pot fi apoi folosite pentru a determina dac un build este valid sau nu nainte de a intra pe mna echipei de testare. O alt opiune bun este automatizarea testelor de instalare a produsului. Odat ce avei un set de teste smoke automatizate precum i posibilitate de a instala produsul folosind teste automate putei implementa un proces de Continous Integration. Principalul obiectiv la acest nivel este s v facei utili celorlate echipe ct mai repede. Un sfat pentru acest nivel este s
Trecnd prin nivelul 4 avei deja experien n jocul automatizrii. Ai ndeplinit o serie de misiuni i ncepei s realizai ct de important e s ai un echipament bun. Pentru ca eroul vostru s fie cu adevrat puternic el trebuie s aib echipamentul potrivit i s l menin n stare bun. n acest nivel vom nva de asemenea c este bine s avem diferite rnduri de echipament pentru diferite misiuni. Dar care este echipamentul eroului n acest joc? Singurele arme pe care le avei la dispoziie sunt testele n sine. n continuare vom prezenta cteva atribute care ar trebui luate n seam pentru testele automate: Capacitatea de a fi reviziuite: Testele trebuie s fie uor de neles i revizuit. E important ca ele s fie bine documentate, iar log-urile trebuie s conin toat informaia necesar pentru a ca utilizatorul s determine motivul pentru care testul a czut. Doar pentru c un test trece de fiecare dat, nu nseamn c este un test bun. Exist o posibilitate ca el s nu funcioneze corect. Utilizatorul trebuie s poat identifica astfel de probleme. Dac funcionalitatea testat se schimb, testele automate trebuie s fie uor de revizuit i modificat. Acuratee: Atunci cnd un test trece, sau pic, trebuie ca utilizatorul s fie sigur c rezultatul obinut este unul corect. Orice test trebuie s aib interfee pentru implementarea premiselor scenariului i pentru a readuce sistemul la starea iniial dup rularea testului. Atunci cnd automatizai scenarii complexe, adugai condiii speciale pentru a v asigura c o eroare aprut n metodele ce implementeaz premisele testului nu va face ca testul s fie picat, ci mai degrab srit. Obiectivul testrii automate este de a oferi o imagine asupra strii curente a
16

produsului nu de a avea suite de teste ce trec tot timpul. Consisten: De fiecare dat cnd sunt executate, testele trebuie s aib acelai comportament. Interfeele pre i post execuie implementate trebuie s asigure aceast consisten la fiecare rulare a testelor. Independen: Utilizatorii vor dori s aib opiunea 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). Oferii utilizatorilor ct mai multe opiuni pentru a v asigura c testele sunt folosite la potenial maxim. Reutilizare : Pentru a evita duplicarea codului i pentru a face mai uor procesul de dezvoltare al testelor noi, putei crea anumite utilitare. Extragerea funcionalitii 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 primii, valori returnate) pentru a putea fi folosite cu uurin. O idee bun este s folosii 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 avei cte o versiune a testelor pentru fiecare versiune a produsului. Anumite funcionaliti 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 reputaie in nivelul 6. bun. Utilizai sistemul de versionare implementat pentru produs i pentru testele automate. Astfel vei avea un pachet nou de teste la fiecare build nou al produsului. Acest lucru v va permite s v modificai testele rapid, n concordan cu schimbrile din produs. Nu uitai c automatizarea este util doar dac este folosit. La acest nivel cheia este s oferii un acces ct mai facil la testele automate indiferent de versiunea testat. Acum c ne-am ndeplinit misiunile propuse, avem cel mai bun echipament, am furit arme i pentru coechipieri ce mai rmne de facut? pregtii din timp, depunei efortul necesar la toate nivelele i nu triai, la final vei iei nvingtori. Aadar, haidei s ctigm jocul automatizrii.
Bibliograe
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: Conductorul de breasl
Nivelul 6: Furirea
Sigur, e distractiv s v folosii armele n care ai investit timp i efort n nivelul 5 pentru a ndeplini misiuni, dar pentru a avansa n jocul automatizrii e necesar s mprii echipamentul cu ali juctori. Furirea de echipament v va ajuta s v construi o reputaie, iar dac v facei prieteni puternici vei progresa mult mai rapid n joc. Ideea de baz la nivelul 6 este s fii darnici. Testele automate trebuie s fie disponibile tuturor utilizatorilor. Grupai testele n pachete ce pot fi utilizate de pe orice platorm. Dup cum am spus i la nivelul 5 versionarea codului este o idee
Acesta este ultimul nivel al jocului nostru. Acum suntei cu adevrat un conductor de breasl. Juctorii de nivel mai mic v caut pentru a cere asisten, echipament i sfaturi. Dar se termin jocul automatizrii aici? Doar pentru c acum suntei numrului unu,nu nseamn c vei rmne la acest nivel mereu. Natura jocului automatizrii este mereu schimbtoare. Trebuie s fii tot timpul n gard dac nu vrei s regresai la nivelele anterioare. Cutai mereu s mbuntii soluia de automatizare implementat. Meninei suitele de teste ntr-o stare bun. Adugai teste noi, revizuii testele vechi pentru a v asigura ca sunt la curent cu schimbrile din produs i eliminai testele care nu mai sunt utile. Lucrai la framework-ul de automatizare pentru a-i imbunti perferomanele i fiabilitatea. mprtii cunotinele acumulate. Organizai edine pentru a ine la curent echipele de testare referitor la starea soluiei de automatizare. Comunicai clar modificrile ce ar putea avea impact n procesul de testare. O soluie bine gndit i bine implementat va permite echipelor de testare s i dezvolte singure testele elibernd din timpul vostru, timp ce poate fi folosit pentru mbuntiri. Oferii suport pentru echipele ce utilizeaz testele automate. Modificrile din produs vor produce mereu noi sarcini pentru echipa de automatizare. Comunicai cu managerii de produs pentru a afla din timp de modificrile ce v vor afecta i pentru a v asigura c automatizarea este luat n calcul in procesul de dezvoltare a noilor funcionaliti. Urmnd paii din acest ghid vei putea s implementai o soluie de automatizare ce poate fi utilizat eficient i produce rezultate utile i vizibile. n cele din urm, ca n orice alt joc, dac studiai regulile, v
17
programare
management
iOS image caching. Libraries benchmark
n ultimii ani, tendina aplicaiilor iOS se ndreapt spre un design ct mai interactiv i plcut ochiului. Deoarece prezentarea imaginilor este un element cheie n tot acest proces, majoritatea aplicaiilor folosesc imagini care trebuie downloadate i afiate. Foarte muli developeri au fost pui la un moment dat n situaia de a-i popula controalele UI cu diferite imagini. Descrcarea 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 aa 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 afiate (modificarea dimensiunii, ndeprtarea efectului de ochi roii, ndeprtarea marginilor etc.). se stocheaz imaginile pe flash drive (unitatea intern de stocare). se citesc de pe flash drive i se afieaz la cerere.
Pentru a dobndi un user experience ct mai bun, este foarte important s nelegem ce se ntmpl n interiorul sistemului iOS, atunci cnd stocm imagini n cache sau le ncrcm. n plus, consider c un set de benchmarks pentru bibliotecile open-source de i mage Matematica FPS caching poate fi foarte util n alegerea soluiei - 60 FPS este idealul pentru orice actualpotrivite. izare de UI, pentru a asigura o experien fr cusur.
// 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; }); }]; }
18

- 60 FPS => 16.7 ms/cadru. Acest lucru nseamn c, dac 4. O soluie robust de caching a imaginilor n iOS ar trebui oricare dintre operaiunile 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 nct main queue s CPU se va ocupa de alte operaii, i nu de actualizarea UI. fie folosit ct mai puin posibil, decomprime imaginile pe un background queue. Acest lucru 3. Dezavantajele abordrii clasice nu e deloc simplu. Pentru mai multe detalii, accesai http:// ncrcarea imaginilor sau a fiierelor n general, de pe flash www.cocoanetics.com/2011/10/avoiding-image-decompresdrive, e o operaie costisitoare (accesarea flash drive-urilor este sion-sickness/ . mult mai lent dect cea a memoriei RAM). stocheze imaginea att n cache-ul din memorie, ct i n cel Crearea unei instane Ullmage va avea ca rezultat o verside pe flash drive. Procesul de caching pe flash drive este imporune comprimat a imaginii, mapat pe o seciune de memorie tant deoarece aplicaia 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 afiat direct. n cazul ncrcrii de pe flash drive, imaginea este re-ncrcarea imaginilor de pe flash drive este mult mai rapid doar mapat, urmnd ca ncrcarea n memorie s se fac la cerdect descrcarea lor. ere. Decomprimarea unei imagini este de asemenea costisitoare. Atribuirea proprietii image din imageView n acest caz Not: dac folosii NSCache pentru memoria cache, aceast va crea un CATransaction care va fi nregistrat n run loop. La clas va elibera toate resursele refereniate, n caz de memory urmtoarea iteraie, executarea CATransaction-ului implic (n warning. Pentru mai multe detalii despre NSCache, accesai http:// funcie 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 fiiere 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 uor de citit i de scris. n prezent, GCD i block-urile decomprimarea de imagini (rezult un raw bitmap ) sunt indispensabile pentru operaiile asincrone. implic un consum ridicat de CPU, bonus 1: categoria peste UllmageView pentru a face inte imaginile nealiniate corect pe bii sunt copiate de ctre grarea uoar. CoreAnimation pentru a fi corectate i redate corespunztor. bonus 2: capacitatea de a procesa imaginile dup descrcare Acest lucru nu este menionat n Apple docs, dar folosirea i nainte de a le stoca n cache. Instruments arat apeluri CA::Render::copy_image chiar i atunci cnd 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, ncepnd cu iOS 7, decodorul hardware JPEG mai este acce- despre cum funcioneaz framework-urile din cadrul iOS SDK sibil doar aplicaiilor sistem. Aceasta nseamn c aplicaiile (CoreGraphics, Image IO, CoreAnimation, CoreImage), CPU vs. noastre se bazeaz pe un decodor software care este mult GPU i altele, citii acest articol bun3, scris de @rsebbe. mai ncet. Acest aspect a fost documentat de ctre echipa FastImageCache pe pagina lor Github,1 dar i de Nick Lockwood Este Core Data un candidat valid? ntr-un post pe Twitter2. Aici4 avei un benchmark pentru caching de imagini folosind Core Data versus File System. Rezultatele recomand File System (dup cum ne ateptam).
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
19
programare
iOS image caching. Libraries benchmark Rezultatele
Rezultatele complete pot fi gsite 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 nelegem flash drive (dispozitivul de stocare intern).
5. Benchmarks
Rezultate pentru iPhone 4
Doar uitndu-ne la conceptele de mai sus nelegem 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 apelm la soluii open source. Majoritatea dintre voi ai auzit de SDWebImage sau FastImageCache. Pentru a decide care vi se potrivete mai bine, le-am comparat i am analizat felul n care rspund cerinelor noastre.
Bibliotecile testate
Legend
SDWebImage FastImageCache AFNetworking TMCache Haneke
Not: AFNetworking a fost adugat comparaiei pentru c, ncepnd cu iOS7, ofer i un cache de tip flash drive (NSURLCache).
Pentru fiecare bibliotec am realizat o instalare de la zero a aplicaiei de benchmark, apoi am pornit aplicaia, scroll ncet, pn ce imaginile s-au ncrcat, apoi scroll repede / ncet alternativ. Am 6. Concluzii nchis apoi aplicaia pentru a fora ncrcarea de pe flash drive Elaborarea unei componente de caching de imagini pentru (cnd aceasta era disponibil), apoi am rulat din nou acelai sce- iOS este dificil. nariu de scroll. SDWebImage i AFNetworking sunt proiecte serioase, cu muli contribuitori i care sunt ntreinute n mod corect. Aplicaia benchmark proiect FastImageCache se ndreapt spre acelai statut destul de repede. Sursa proiectului demo poate fi gsit pe Github sub denu- Dac analizm informaiile oferite mai sus, cred c putem fi de mirea de ImageCachingBenchmark5, mpreun cu diagramele, accord c SDWebImage este cea mai bun soluie la momentabelele cu date i altele. tul actual, chiar dac pentru unele proiecte AFNetworking sau Sursele proiectului de pe Github au trebuit modificate, la fel FastImageCache s-ar potrivi mai bine. Totul depinde de cerinele ca cele ale bibliotecilor, adugndu-se tipul cache-ului din care proiectului n cauz. s-a fcut ncrcarea. Nedorind s includ n repository i sursele Cocoapods (acest lucru nu este recomandat) i pentru c proiectul Link-uri utile trebuia s fie compilabil dup instalarea clean a Cocoapods, vari- https://github.com/rs/SDWebImage anta de proiect din Github este uor diferit de cea cu care s-au https://github.com/path/FastImageCache efectuat msurtorile. https://github.com/AFNetworking/AFNetworking Dac unii dintre voi doresc s ruleze din nou benchmark- https://github.com/tumblr/TMCache urile, va trebui s creai un completionBlock pentru ncrcarea https://github.com/hpique/Haneke imaginilor pentru toate bibliotecile, similar celui default din http://bpoplauschi.wordpress.com/2014/03/21/ SDWebImage, care returneaz tipul SDImage CacheType. ios-image-caching-sdwebimage5 github.com/bpoplauschi/ImageCachingBenchmark
Scenariul
async download = biblioteca ofer suport pentru descrcare 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 obinut cele mai bune rezultate la timpii de ncrcare din cache (memorie sau flash drive).
vs-fastimage/ https://github.com/bpoplauschi/ImageCachingBenchmark
20
management
programare
THE WEBS SCAFFOLDING TOOL FOR MODERN WEBAPPS Yeoman
Yo
Rzvan Ciriclia
razvan.ciriclia@betfair.com Software engineer @ Betfair
LESS or SASS - fiecare dintre noi poate Ajut la crearea structurii de fiiere i alege ori unul, ori cellalt - Grunt le tie pe defineste deja configurri generale pentru amndou. Grunt i Bower. Puin cam rapid introducerea despre Grunt - dar o parte din calitile unui task Grunt runner nu puteau fi prezentate dect scurt Nu i s-ar prea interesant s tii dac i la obiect. CSS-ul este valid i aa va rmne ntr-o vineri seara cnd tocmai te pregteti s Bower pleci de la serviciu i pe diagonal citeti Economisete din timp, download-nd not working ntr-un mail de la eful / cli- librriile necesare noului proiect precum i entul tu? dependinele acestuia. i-ai dori ca CSS-ul, JS-ul HTML-ul s Utilizarea, instalarea i funcionarea fie deja optimizat nainte cu cel puin o zi corect YEO este condiionat de instalarea de a ajunge n producie? n prealabil a Node.JS i Git. De asemenea, Ai testat codul tu fr 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 aceeai reea? Ai uitat c Romnia ntrece SUA, Germania, Instalare YEOMAN Norvegia, Japonia i multe alte ri dezvolYEOMAN va fi instalat asemnenea genetate n topuri internaionale privind viteza rator-webapp folosind npm de conectare la Internet? Grunt te va ajuta npm install -g yo s-i optimizezi dimensiunea imaginilor fr s afecteze calitatea acestora! PROJECT STARTUP i place s-i structurezi munca pe Odat YEOMAN i dependinele acesmodule; iar fiecare s aib propriile fiiere tuia instalate, putem da start noului proiect. CSS sau JS? i place s vezi fiiere mai mari Pentru aceasta trebuie s navigai n folder-ul de 100 de linii doar n producie, unde (unul nou creat sau fr alte directoare sau este necesar s ai ct mai puine resurse fiiere n el) unde dorii s dezvoltai noul ncrcate?Grunt poate face asta pentru tine proiect i lansai din linia de comand: compactnd CSS sau minificnd JS.
yo webapp www.todaysoftmag.ro | nr. 22/Aprilie, 2014
niierea unui proiect poate fi de cele mai multe ori plictisitoare cnd deja nu mai e o provocare. Atunci cnd ncepe un proiect nou, pentru a mbunti productivitatea i plcerea de a lucra, Yeoman are la baz trei tool-uri:
21
programare
THE WEBS SCAFFOLDING TOOL FOR MODERN WEBAPPS Yeoman
n acest moment jQuery, Gruntfile.js i HTML5 Boilerplate sunt instalate automat, iar pe lng acestea, mai avei la dispoziie s includei n aplicaia abia nceput, framework -uri precum: Bootstrap, Sass sau Modernizr. Timpul total de ateptare pentru a putea avea acces la cod i a ncepe editarea cu specificaiile proiectului este de aproximativ dou minute. node_models sunt adugate n .gitignore, nainte de rularea acestei comenzi vor treCreeaz sampleDirective.js, varianta bui rulate: iniial 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 fiierele pentru producie. n acest pas Grunt ruleaz taskyo angular:filter boldRed urile definite n Gruntfile.js, fiier aflat n Caz concret Creeaz boldRed.js, varianta iniial a rdcina proiectului. unui filtru n app/scripts/directives Un exemplu de aplicaie realizat cu npm install -g generator-angular Creeaz boldRed.js, varianta testului Yeoman poate fi descarcat de aici https:// Instaleaz generatorul pentru aplicaiile unui filtru n test/specs/directives github.com/razvancg/yeomanDemo bazate pe AngularJs
yo angular:app imdbApp yo angular:service getepisode yo angular:directive sampleDirective
Creeaz getepisode.js, varianta iniial 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 caia curent imdbApp Creeaz getepisode.js, varianta a testu- s se obinuiasc cu YEOMAN. Opiunea lui unui service n test/specs/services de a nu mai cuta ultimele versiuni ale unor yo angular:route movies framework-uri de care ai nevoie n proiect, Creeaz un nou path n aplicaie, un yo angular:factory getseasons de a le download-a, dezarhiva i copia n view i controller -ul asociat. Rezultatul Creeaz getseasons.js, varianta iniial locaia proiectului, pe lng crearea autoacestei comenzi este: a unui factory n app/scripts/services mat a structurii de fiiere i task-urile pe Creeaz movies.js, varianta iniial 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 pn Creeaz movies.js, varianta iniial a acum! yo angular:provider getmovies unui test n test/specs/controllers Creeaz movies.html - template n app/ Creeaz getmovies.js, varianta iniial 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 rdcina Creeaz movie.js, varianta iniial a proiectului se ruleaz: unui controller n app/scripts/controllers grunt serve Creeaz movie.js, varianta iniial a unui test in test/specs/controllers n cazul n care proiectul a fost clonat din Git, datorit faptului ca fiierele din
Concluzii
22
programare
OpenXML - Noiuni introductive
n acest articol, ncercm s trasm o hart de baz pentru a manipula programatic fiiere xlsx folosind librria Office Xml. Multe aplicaii necesit lucrul cu fiierele excel, fie pentru citirea i importarea datelor din el, fie pentru exportarea datelor ntr-un raport, astfel c este important s cunoatem cum s manipulm programatic fiierele excel. ncepnd cu anul 2007, fiierele Excel i-au schimbat complet structura lor intern. Xls a fost un format de fiier binar proprietar, n timp ce xlsx este un format bazat pe Xml, numit Office Open Xml (OOXML). cinci elemente, Workbook, WorksheetPart, Worksheet, Sheet, SheetData. Sarcina principal a unui WorkbookPart este de a ine evidena foilor de lucru, setrilor globale i a componentelor partajate ale registrului de lucru (Workbook) . Documentul trebuie s conin cel puin o foaie de lucru (Worksheet) care este definit n interiorul unui WorksheetPart. O foaie de lucru are trei seciuni principale: Foaia (Sheet), declarat n registrul de lucru (Workbook), conine proprietile. De exemplu: nume, un id utilizat pentru sortarea foilor i un id de relaie, id care o conecteaz la WorksheetPart; SheetData care conine datele efective;
Florentina Suciu
Software engineer @ Fortech
orentina.suciu@fortech.ro
Excel ca ier zip
Gabriel Enache
gabriel.enache@fortech.ro Software engineer @ Fortech
Un fiier xlsx este un pachet zip care conine un fiier xml pentru fiecare parte major a unui fiier Excel (foi, stiluri, diagrame, tabele pivot). Dac dorii s verificai coninutul unui xlsx, tot ce trebuie s facei este s schimbai extensia fiierului din xlsx n zip i apoi s-l dezarhivai.
Componente ale ierelor Excel
Un d o c u m e nt E xc e l c on i n e u n WorkbookPart central i pri separate O parte pentru suportarea caracteristicipentru fiecare foaie de lucru. Pentru a lor cum ar fi protecia i filtrarea. crea un document valid, trebuie s unii
Figura 1 - Elemente ale unui fiier Excel zip
23
programare
OpenXML - Noiuni 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), SheetId = (uint)document.WorkbookPart.Workbook. Sheets.Count() + 1, Name = MyFirstSheet }); // save the workbook document.WorkbookPart.Workbook.Save(); }
Figura 2 Componente ale unui document Excel
Librria OpenXml
Un tabel pivot este un tabel folosit pentru sumarizarea datelor, Toate clasele necesare pentru a manipula un fiier xlsx pot fi care poate sorta, calcula sau aplica media automat la datele stocate gsite 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 pri 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 instaniem o var workbookPart = document. AddNewPart<WorkbookPart>(); list de PivotCaches, cu un PivotCache descendent. n imaginile urmtoare, putei 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 }));
Crearea unui tabel pivot (Pivot Table)
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>();
Young spirit Mature organization A shared vision Join our journey!

www.fortech.ro
24

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);
n pasul urmtor, trebuie s definii regulile cu ajutorul obiectului ConditionalFormatting care are ca descendent un obiect ConditionalFormattingRule. Mai jos putei vedea un exemplu n care aplicm o formatare condiionat 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);
PivotTablePart descrie layout -ul. Descendentul su, PivotTableDefinition, stocheaz locaia tabelului i PivotFields. Sunt dou tipuri de PivotFields (cmpuri pivot): RowFields i DataFields. RowFields sunt date statice i PivotField-ul lor corespunztor are proprietatea Ax (Axis) setat pe AxisRow; DataFields sunt date calculate (de exemplu totaluri) i PivotField-ul lor corespunztor are proprietatea DataField setat pe true. Definiia tabelului pivot trebuie s cunoasc id-ul PivotCacheului pe care l-am definit mai sus. n definiia tabelului pivot putei specifica formatul n care dorii s afiai tabelul. Acestea pot fi: Compact (setai flag-ul compact pe true), Outline (setai flag-ul Outline pe true), sau formatul Tabular (tabelar) (setai flag-ul GridDropZones pe true). PivotTableC acheDefinitionPar t c u des cendentu l PivotCacheDefinition, definete cmpurile cache (cache fields). Este necesar s declarm un cache field pentru fiecare coloan din tabel. De asemenea, acesta conine 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.
Concluzie
n acest articol am trasat o hart de baz a modului n care se poate naviga prin OpenXML n generarea fiierelor xlsx. Chiar i atunci cnd ncerci s-l prezini ct mai simplu posibil, se poate vedea c i pentru cele mai simple operaiuni codul poate i va deveni complex.
Aplicarea formatrii condiionate
Vom prezenta cum se poate aplica datelor formatarea condiionat, adic s formatm i s evideniem anumite celule pe baza valorilor lor. Pentru a face acest lucru, trebuie s definii dou lucruri. n primul rnd, definii stilurile pe care dorii s le aplicai celulelor evideniate, n special fonturile i culorile. Stilurile sunt declarate n Stylesheet al prii registrului de lucru (workbook part).
25
programare
BDD, Javascript i Jasmine
n acest moment, partea de client a aplicaiei noastre crete Aceast descriere, o vom diviza pe mai multe seciuni, n cele n complexitate, drept urmare va avea mai multe responsabiliti. ce urmeaz. Este important de subliniat c odat cu creterea numrului de responsabilitai cresc i costurile de mentenan ale unui proiect. Loop-ul (bucla) BDD S-a demonstrat stiinific c partea de mentenana 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% specificaie high-level. [1]. Drept urmare, pe lng factorii de performan i scalabilitate 2. Scrie un test unitar care nu compileaz sau nu trece ( de ai aplicaiei noastre se numr 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 uor la modificrile din viitor. treac i nimic mai mult (folosind cea mai simpl soluie posibil, returnnd chiar o constant, dac aceasta satisface condiia Diferite interpretri testului. Acest pas este identificat drept pasul GREEN din n practic, dac ntrebm zece programatori ce nseamn bucla TDD). BDD, sunt mari anse s primim zece rspunsuri diferite. Unii 4. Refactorizeaz ( pentru a elimina informaia duplicat din spun c BDD este doar Test Driven Development (TDD) implemenimplementare, acest pas introduce designul incremental i pretat bine, alii spun c BDD este a doua generaie a metodologiei supune o implementare reala a cerinei ). Agile, iar alii afirm ca BDD este o tehnic elegant de exprimare a specificaiilor executabile, i lista ar putea continua. BDD moteneste 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 cteva 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, cnd managerul aloc task-uri, menionnd nceput, am putea recunoate c sun puin ciudat, dar voi ncerca n cele din urm: vreau ca task-ul sta s fie implementat pn la s fac mai expresiv aceasta nentelegere. sfritul sptmnii. n acest fel, programatorul este constrns s Paii elementari prin care fiecare programator trece, atunci foloseasc tehnologii si limbaje, altele dect cele pe care dorete s cnd face TDD sunt urmtorii: le urmreasc. 1. La primul pas, orice programator ncepe prin a scrie codul BDD nchide aceast fereastr prin expunerea unui backlog. de producie, urmat de o sesiune de teste unitare, folosind unul Ne putem gndi la un backlog ca la un queue( coad de mesaje din framework-urile existente. ). Se bazeaz pe acelai principiu ca binecunoscutul design pattern 2. La pasul al doilea, dup ceva practic, programatorul des- Producer Consumer, unde fiecare programator joac rolul unui coper cteva beneficii n a scrie prima dat testele, ctignd 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, ntrete comunicarea dintre programator i stakeholder, pentru c Spies), etc.. fiecare cerina, 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 realizrii o tehnic de design, care-l ajut s construiasc un cod elegant, tehnice a funcionalitii (sigur exist situaii n care tehnicul intr decuplat i abstractizat. n discuie). Dup aceasta programatorul mparte aceste cerine 4. La ultimul pas, programatorul descoper c, n fapt, TDD n task-uri, care sunt apoi prioritizate n funcie de valoarea lor de nu are nimic n comun cu scrierea de teste automate. business. Aceast abordare ntrete sigurana c stakeholder-ul va ajunge s primeasc ceea ce a solicitat n cerina iniial, lsnd n La acest punct 4 vom oferi explicaii. acelai timp libertatea programatorului s aleag soluiile tehnice Din nefericire, majoritatea programatorilor nu reuesc 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 aplicaii, prin descrierea comDup cum tim, abordarea test-first-code impune de la bun portamentului din perspectiva clientului, numit de acum nainte nceput o gndire axat pe ce anume trebuie ndeplinit pentru stakeholder. a face testul s treac. ncepnd cu un test, vom scrie doar cod
n acest articol, voi ncerca s dezvolt conceptul de Behavior Driven Development (BDD) folosind framework-ul de testare din JavaScript, Jasmine. Cum muli dintre noi cunoatem JavaScript ca un limbaj care nu mai este unul de scripting, deseori se ntmpl s avem o migrare, poate nedorit, a logicii de business de pe partea de server pe cea de client.
26

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 producie i apoi testele, n cele mai multe cazuri, se creeaz greuti sau chiar imposibilitatea de a scrie mai trziu testele pentru acest cod. De ce? Pentru c designul sistemului nu a fost iniial conceput a fi testabil. Urmnd aceast cale se ajunge la un cod fragil, tightly coupled, care are multe depedene i care nu poate fi reutilizat. Finalmente un cod pe care noi, programatorii, l-am numi unreliable. De cte ori nu ni se ntmpl c schimbnd ceva ntr-o parte, aa-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 aplicaiei. Este important de amintit c trebuie testat logica aplicaiei, comportamentul ei, i nu doar chestiuni triviale, cum ar fi getter-i/ setter-i, sau mai ru, API-uri de la tere prti, care au propriile lor teste. n special, n lumea Agile unde testarea exhaustiv a produsului in fiecare iteraie 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 cnd BDD-ul se focuseaz pe o caracteristic fundamental a codului i anume comportamentul. Un test va verifica dac o condiie este ndeplinit sau nu, n timp ce un comportament descrie printr-o reprezentare mai expresiv logica sistemului. n BDD testul ia forma unei specificaii. Finalmente att TDD-ul ct i BDD-ul furnizeaz specificaii executabile care servesc ca documentaie vie living documentation. S insistm puin asupra sintagmei living documentation. De cele mai multe ori avem specificaiile date ntr-o form static, fie sub forma unui document, fie sub forma de story-uri. Folosim cuvntul static aici pentru a puncta antiteza acestui gen de specificaii vizavi de nite specificaii dinamice date de o abordare BDD. Aadar, acest gen de specificaii statice, combinate cu specificaii executabile, ajung s ncalce principiul Dont Repeat Yourself ( DRY) , fiindc exist o duplicare a informaiei. Cnd cerinele aplicaiei se schimb, trebuie s adaptm aceast schimbare i s o transpunem n implementarea real a sistemului. De cele mai multe ori specificaia static va rmne n urm, pierzndu-i n cele din urm valoarea. Aadar att documentaia static ct i cea dinamic, reprezentat de specificaiile executabile, trebuie sincronizate ntr-un fel, lucru care finalmente introduce o povar pentru fiecare programator. BDD-ul promoveaz ideea de a pstra detaliile tehnice n specificaiile executabile, astfel prin rularea lor putem dovedi c cerina din implementare este finalizat. Aadar vom ti cu O mai bun expresivitate exactitate cnd am terminat. Diferena dintre TDD i BDD este c Acest tip de specificaii dinamice trTDD-ul induce deseori starea de confuzie iesc alturi de codul nostru de producie. Dac exist o form de development numit Outside In, intuiia ne spune c ar trebui s existe i o form numit Inside Out(sau bottom-up), pe care cred, cu toii am urmat-o la un moment dat. S ncepem cu cea din urm. Urmnd o abordare Inside Out ncepem implementarea pe baza unor operaii sau funcii, pe care le considerm ca main-stream n cadrul funcionalitii. Este foarte uor s realizm prematur abstracii, construcii, care sunt pur i simplu greite de la bun nceput. Inside Out ne oblig s ne gndim de la nceput la toate ramificaiile, toate dependenele ntre componente, fcnd procesul de dezvoltare complicat. Pe msur ce logica de business devine mai complex, va fi din ce n ce mai dificil s gsim calea corect n implementarea funcionalitii. Deseori aceast form de dezvoltare ne foreaz s scriem cod care mai trziu nu este reutilizabil i care devine repede mbtrnit. Aceasta duce la folosirea ineficient a timpului i a costurilor de proiect. n sensul pur al Object Oriented Design -ului (OOD) putem spune c violm un principiu fundamental din lumea Xtreme Programming (XP), si anume YAGNI ( You Aint Gonna Need It) [4] n Outside In ncepem prin a scrie o documentaie high-level, care are o valoare de business. ncepnd cu aceste funcionaliti high-level we code our way in, prin divizarea specificaiilor n entiti coezive, aadar implementm doar ceea ce este parte a cerinei iniiale i nimic mai mult. Scriind cod n aceast form, top-bottom, suntem forai s ne comportm ca i
Our core competencies include:
Development Outside-In
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 oerings are business focused, they drive real, tangible value.
www.3pillarglobal.com
27
programare
BDD, Javascript i Jasmine
cnd entitile dependente ar exista deja. Aceasta poate fi perceput ca un dezavantaj, fiindc nu vom putea s rulm specificaiile pn cnd ntreaga funcionalitate este implementat. Astfel se contrazice regula BDD-ului( sau TDD-ului ) de a rula specificaiile ct mai des posibil, pentru a surprinde ct mai repede eventualele probleme. n acelai context, implementnd ntr-o manier Outside-In, pornind de la o specificaie high-level, nu putem afirma c aceasta este chiar un baby-step. Scopul este s derivm specificaii lowlevel din cele high-level. Principiul care st la baza acestui concept este divide et impera [5]. Este mult mai uor s rezolvm o problem complex, dac gsim o soluie 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 rezolvrii problemei iniiale. O alt variant de a gndi ntr-o manier BDD, este relaionarea One-To-Many. Elementul One este subiectul specificaiilor/ testelor noastre( Subject Under Test SUT ), iar entitile Many sunt dependenele cu care SUT interacioneaz. Este o idee bun s amnm orice implementare concret a dependenelor pe mai trziu, timp pe care-l putem folosi s deprindem o mai bun cunoatere a domeniului i a problemei pe care vrem s o rezolvm. n acest mod, SUT se va baza pe test-doubles i nu pe o implementare concret a dependenelor. n acelai context bazndu-ne, spre exemplu, pe abstracii, i nu pe entitai concrete, vom reui s integrm un design loosely-coupled ntre SUT i colaboratorii lui. Structurarea specificaiilor bazat pe Fixture permite o mai bun aranjare, datorit posibilitaii de a avea mai multe contexte de execuie. Lund cazul teoretic al unei operaii online, putem avea un context de execuie atunci cnd coul de cumprturi este gol sau coul de cumprturi a ajuns la suma maxim admis. Aceast abordare de structurare a specificaiilor duce la un design elegant i curat, avnd suita noastr de operaii 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 execuie. 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 fiecrei operaii n parte, adic by Method. Poate fi un proces incomod, lund cazul practic n care avem definite dou metode foo() i bar(). Cum, probabil, suntem test-infected, avem o suit de specificaii scrise att pentru foo(), ct i pentru bar(). Acum, operaia foo() se poate folosi de operaia bar(), dar noi avem deja scrise testele pentru bar(), astfel c testele pentru foo() vor acoperi i cazurile operaiei bar(). Cnd introducem o redundan n specificaiile noastre ntre componentele testate, acestea vor deveni greu de neles, fiind totodat redundante. Dac o singur problem va aprea n testele noastre, cum ar fi cazul, mult ntlnit, n care un test se comport ntr-un mod non-deterministic, acea problem va virusa toat suita noastr de teste, fcndu-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 construiete pe un limbaj business, denumit GHERKIN [6]. Acesta este un simplu Domain Specific Language (DSL). Acest DSL i-a fcut prima dat apariia 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 uor interpretat i neles 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 instruciuni ne ajut s structurm codul ntr-un test, ntr-o manier mentenabil i uor de citit. Din nefericire, simpla structurare a codului, nu va ajuta un expert n domeniu s neleag codul nostru. Pe de alt parte GHERKIN augmenteaz aceast comunicare dintre programator i stakeholder. Un limbaj ubicuu se nate ntre cele dou lumi. Cele trei instruciuni 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 uor 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, cerina este foarte uor de interpretat. Aceast form ntrete expresivitatea folosind un limbaj natural pentru a declara o cerin real. nainte de a termina prima parte a acestui articol, vreau s mai amintesc cteva dintre avantajele BDD fa de tradiionalul TDD: 1. ntrete comunicarea dintre programator i stakeholder( prin specificaiile high-level private de orice detaliu tehnic, se nate un limbaj ubicuu ntre ambele lumi ). 2. Concentreaz mindset-ul programatorului mai aproape de
Cum organizm specicaiile n BDD?
Putem adopta mai multe soluii de organizare a specificaiilor, ns cele mai cunoscute pattern-uri de structurare a specificaiilor, permit gruparea bazat pe: 1. Feature, 2. Fixture, 3. Operation/Method. n cele ce urmeaz le voi descrie punctele forte ale fiecrei modaliti de structurare. Voi ncepe cu gruparea bazat pe Feature care permite organizarea codului n specificaii, n funcie de subiectul cerinei iniiale. Putem lua cazul practic n care domeniul logic este un magazin online. Cerina este de a calcula totalul produselor din coul de cumprturi. n logica acestei cerine vom avea cteva 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 operaii pot fi structurate ca un singur feature. Partea bun este c acest mod de structurare, permite izolarea fiecrui feature n parte, astfel nct putem avea o suit de specificaii pentru fiecare feature n parte i putem nelege funcionalitatea unui feature doar rulnd aceste specificaii. Dezavantajul acestei metode de organizare este c, n timp, cerinele se schimb, noi funcionaliti augmenteaz feature-ul iniial, ca urmare specificaia se poate degrada ntr-un timp foarte scurt datorit numrului mare de modificri. Scopul final este s avem o suit de specificaii care exprim ntr-un mod clar cerinele testate din requirement-ul iniial, astfel nct ele s serveasc ca living documentation. Calitatea codului nostru din specificaii trebuie s fie tranzitiv egal cu codul nostru de producie.
28

valoare business a cerinei, forndu-l s gndeasc la nivel de comportamente ale aplicaiei i nu de teste. 3. Aduce un nou pattern de structurare a codului din teste, fcnd specificaiile uor de neles i pentru un non-tehnic. 4. Putem nelege comportamentul unei aplicaii urmrind fluxul de execuie al specificaiilor. A doua parte a acestui articol are o amprent practic, avnd ca principal actor framework-ul Jasmine [8]. Scopul iniial a fost s construiesc o simpl librrie urmrind metodologia BDD, dar articolul a reuit s nghit cteva pagini bune pn acum, aa c o s descriu cteva pri importante i las cititorului ocazia de a inspecta codul pe github [9]. n cteva cuvinte, Jasmine este un framework de testare unitar i nu un integration-framework, dup cum alii presupun. Permite structurarea specifictiilor bazat pe fixture, permind a avea blocuri describe imbricate. Totodat vine cu cteva obinuine comune pentru a configura contextul de execuie al specificaiilor( setup & tearDown ). Ca implementare concret a patternului Test Doubles folosete Spies( Spioni ). O simpl utilizare poate fi exprimat n urmtorul mod:
describe(EventBus SUT, function () { // various fixtures it(should do this and that describe behavior, function() { // some executions expect(thisResult).toBeTruthy(); }); }); 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 specificaiilor, astfel nct putem urmri foarte uor firul comportamental al execuiei 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 specificaiilor, spies ca implementare concret a pattern-ului Test Doubles. Pe scurt spies ne permit s inspectm ce rutine au fost invocate i opional, care sunt parametrii cu care au fost invocate aceste rutine. n acelai context, putem instrui anumite apeluri de rutine s returneze rezultate specifice cerinelor noastre i putem opta pentru o invocare real a rutinei folosind un ,,spyi nu un fake-call. Integrarea specificaiilor n contextul de Continuous Integration (CI) este relativ trivial.
Sumar
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 ctre un design loosely-coupled ntre obiectele comunicante. Strmoul su este binecunoscutul Observer Design Pattern. Pentru a evita o strns legtur ntre obiectele comunicante, delegm 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, ateptnd s fie tratat de un listener. Dup cum bine tim jQuery este o librrie care simplific mult operaiile ( bazate pe evenimente ) la nivel de DOM. n acest context, EventBus-ul prezentat, ne las s manevrm evenimentele axate pe comportamente la nivel de aplicaie. O utilizare practic a EventBus-ului o poate avea binecunoscutul, pn acum, scenariu al unui magazin online. Cnd utilizatorul apas pe butonul de buy, deseori am vrea ca o suit de operaii s fie cascadate, astfel nct produsul cumprat s fie adugat n coul nostru de cumprturi, o fereastr, posibil modal, de ntiinare s fie afiat, iar produsul cumprat am vrea s dispar din lista de produse sugerate. n exemplul de fa, vom nregistra cteva 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);
BDD vine ca o augmentare peste tradiionalul TDD. Ca i metodologia TDD, BDD induce designul aplicaiei ctre o arhitectur decuplat. Designul incremental face parte din acest proces i este ntlnit n faza de refactorizare. Orice specificaie high-level trebuie divizat n mai multe entiti coezive care n final ne ajut s implementm funcionalitatea dorit. Fiecare cerin este prioritizat n funcie de valoarea de business. Cu acest arsenal de tehnici putem foarte uor s evitm s implementm un BDUF prematur. Forma de dezvoltare software Outside In este motorul care angreneaz conceptul BDD. Dintr-un punct de vedere, aceast form, ne constrnge, neputnd s rulm toate testele pn n momentul n care avem o implementare concret a ntregii cerine. Unele framework-uri asigur mecanismul de cross-this-specification, care ne permite s evitm rularea unei specificaii high-level, sau altfel spus un test de acceptan. Pe de alt parte Outside In, ne ncurajeaz s gndim n abstracii i s evitm o implementare real, care de multe ori se dovedete a fi prematur, pn cnd deprindem destul cunoatere 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 @ 3Pillar Global
29
management
De ce dureaz att de mult s terminm 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 cteva minute. n aceste cteva minute, ansele sa i ntrerupi activitatea curent pentru verificarea telefonului, a e-mailului, a notificrilor primite pe Facebook sau Twitter sunt destul de mari. Iar dac eti n birou, discuiile dintre colegi fie ele despre maini, fotbal sau fashion sau ieirile din seara precedent, i capteaz ntr-o oarecare msura atenia. Chiar dac pn acum te-ai meninut concentrat, nu poi s nu i rspunzi colegului care te roag amabil s l ajui i astfel i se va pierde focusul. Iar cu toate acestea, cnd 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 eti ntrerupt cam o dat la 3 minute, cauzele fiind att de natur uman ct i de natur digital. Odat ntrerupt, i poate lua pn la 20 de minute ca s i revii la concentarea iniial. 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, evoluia erei digitale a avut un impact puternic asupra productivitii indivizilor, dar n zilele noastre, tehnologia parc are un singur scop: s atenteze asupra concentrrii. Odat cu apariia device-urilor inteligente, explozia aplicaiilor web, eCommerce-ul, dar i altele, e din ce n ce mai greu s ne meninem concentrai. De multe ori pornim la nceputul zilei cu o lista de to-do-uri,
iar spre sfritul zilei constatm c nc mai sunt lucruri nerezolvate. Astfel, indiferent de ce presupun acele sarcini, acestea ar trebui s fie ct mai mrunte, pentru a putea fi terminate ntr-un timp ct mai scurt, cu rezultate vizibile.
Autodisciplina
Productivitatea
ns, ce este de fapt productivitatea? Am putea s o msurm destul de exact: numrul de uniti realizate ntr-o anumit perioad de timp, de exemplu: numrul de linii de cod scrise ntr-o or. Dar acest calcul nu reflect adevrata productivitate care ar trebui cntrit n raport cu rezultatele obinute ntr-o anumit perioad; de exemplu, la sfritul zilei clientul a primit produsul, business-ul pe care l conducem a avut o perioad favorabil, am nvat un lucru nou n ziua respectiv i cte altele. De asemenea, productivitatea se refer i la modul n care ne administrm timpul i pe noi nine astfel nct s avem ct mai multe realizri, ntr-un timp ct mai scurt. Cu alte cuvinte s maximizm realizrile dar, n acelai timp, s minimizm efortul depus.
Pentru a fi cu adevrat productiv i a avea o concentrare adecvat este nevoie de mult disciplin. Dar ce te faci cnd creierul este cel indisciplinat? n majoritatea timpului ne folosim creierul pentru a extrage din el informaii pe care deja le tim: fie le-am nvat, 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 gndim: acest lucru pare ntr-o prim instan destul de greu pentru creier i prin urmare, ne ndeamn s ne mutam atenia i s ne ocupam timpul cu altceva, n sperana c poate problema se va rezolva de la sine ( lucru care evident nu se va ntmpla ). Astfel, ne verificm e-mailul, telefonul, 2-3 bloguri pe care le urmrim, ncercm s revenim, nc nu merge, o lum pe alt parte i tot aa; i astfel ne pierdem printre site-uri, articole, e-mail-uri n ncercarea de a evita un lucru pentru care suntem concepui: s gndim. Ajungem astfel la aa numitul multitasking . El este dumanul numrul unu
30

al productivitii, din motive destul de obiective: creierul nostru are o anumit capacitate de atenie i este ideal ca aceasta s fie asociat unui singur task la un moment dat. Nu poi avea o concentrare maxim asupra unui lucru, dac n paralel mai ncerci s rspunzi i la un mail i mai i dai raport efului1. interfereze cu prioritile lor. Totodat, se spune c dimineaa oamenii au n general o voina mai puternic dect n restul zilei i prin urmare sunt mai optimiti i mai deschii ctre noi provocri. Aa 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 dimineii. Un lucru pe care l face destul de mult lume i care nu este neaprat un truc este lista de to do-uri. Aceasta poate s conin task-uri care necesit rezolvare imediat, lucruri de care ar trebui s i aduci aminte pn la un moment dat (ex: s rspunzi la un mail pn la o anumit dat) sau chiar i lucruri pe care i-ar plcea s le faci sau ai vrea s le faci, dar care suport amnare. Dei o unii nu o consider necesar, lista de to do-uri are un rol destul de important: exist o mulime de gnduri, presiuni, idei pe care creierul e forat 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 aduga obiectivul sau sarcina pe care vrem s o ducem la bun sfrit ntr-un timp ct 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 apucm de lucru i pe parcurs este posibil s deviem de la ideea iniial sau ne dm seama c voiam de fapt cu totul altceva; se ajunge astfel la situaia n care s-ar putea ca nici noi s nu tim exact ceea ce vrem s obinem. De aceea, este extrem de important definirea ct 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 creterea productivitii. Realiznd o simpl statistic asupra activitilor zilnice, se pot determina acelea care aduc sau nu beneficii, n funcie 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 activitilor astfel nct s poi lucra pe mai multe fronturi n decursul unei zile. n acest fel te simi oarecum protejat de multi-tasking, deoarece tii c i-ai rezervat timp i pentru celelalte activiti. Un caz n care tehnica de timeboxing ajut avnd i un impact psihologic ar fi momentul nceperii unui task nou: e mult mai uor s ncepi un task cu gndul c ai dou ore asociate lui, dect s te gndeti c ai timp suficient de lucru, netiind de fapt cnd se va ncheia task-ul. Altfel, dup dou zile de lucru pe acelai task, ai vrea sa te apuci de altceva. Totodat, setnd o anumit limit de timp, i poi gestiona i munca mai bine: astfel, nu te vei fora 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 menine 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.
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 toii, n care eti total absorbit de problem, de task i nimeni i nimic nu te poate deranja. Ar trebui profitat de aceste momente. Partea mai puin bun este c flow-ul e ceva ce nu prea poate fi programat, iar o noapte cu mai puin odihn se resimte. Flow-ul mai este influenat i de provocarea adus de task n concordan cu ncrederea individului c are abilitile necesare de a rezolva problema. Dar deja alunecm n psihologie; prin urmare, sunt anumite momente cnd simi c eti mai creativ i mai productiv, iar acele momente ar trebui fructificate. Articolul prezint activiti i/sau situaii din viaa de zi cu zi, ilustrnd probleme dar i mbuntiri care pot fi aduse pentru a crete productivitatea. Avnd 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.
Practici. Obiceiuri.
25h/zi
Dup cum ziceam, productivitatea se refer la modul n care ne organizm ziua, munca, gndurile. 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 reuesc alii s fac attea lucruri n aceeai unitate de timp n care ie i ncap doar cteva chestii de baz. Ei bine, sunt cteva trucuri pe care acetia le folosesc i susin c le-au mbuntit substanial viaa i modul de lucru. Majoritatea investesc orele de diminea n lucruri importante pentru ei, nainte ca activitile celorlali s
1 http://w w w.car to onaday.com/ the-role-of-smartphones-in-business-productivity/
n special n domeniul IT, dar nu numai se vorbete 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 (dei 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 nvare 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 ct 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 ndeplineti task-ul n fiecare zi, Un alt termen legat de productivitate iar pe msura ce zilele trec, n calendar se este i timeboxing-ul. Acesta este o tehnic va forma un lan. Nentreruperea acestui de management al timpului care prinde din lan duce la stabilirea acelei activiti ca ce n ce mai mult teren n rndul progra2 http://blog.clarity.fm/25-minutes-is-all-you-needmatorilor i nu numai. Este util deoarece how-the-pomodoro-technique-increases-productivity/
31
management
De ce dureaz att de mult s terminm un task?
obicei. Aceast tehnic funcioneaz n orice domeniu, deoarece aciunile repetitive, zilnice, duc la implantarea obiceiurilor. Totodat, tehnica duce spre gamification, trezind astfel n noi dorina de competiie, realizare i mplinire. nlocuirea unei ci lungi spre un fiier cu un nume mai scurt. De exemplu, dac se dorete rularea personalizat a anumitor comenzi, cum ar fi cea de remove - s fie mereu rulat cu opiunea 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 lng faptul c lucrezi mpreun cu un coleg i lucrezi, c doar nu i ari mail-urile celuilalt pair programming -ul mbuntete productivitatea pe termen lung, dar i calitatea codului. Dei pe termen scurt, productivitatea i timpul fiecruia sunt afectate pair programming-ul aduce n plus cunotine 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 nsui. Astfel, prin learn i share se dezvolta cunotinele n cadrul unei echipe. Iar n final, pentru a ne scuti o parte din munc ce ar fi s plasm anumite sarcini pe seama calculatorului: acesta nsemnnd automatizare, de la cele mai mici i mrunte comenzi care sunt efectuate cu o frecven mare, pn la aplicaii care sunt capabile s genereze cod n locul nostru (Numrul 21 Today Software Magazine: Cum s scrii un generator de cod bazat pe template-uri flexibile, Denes Botond).
Decizii?
Un concept relativ nou, din cauza cruia alegerile i deciziile noaste se nrutesc pe msur ce ziua se scurge este aa cum o numesc jurnalitii de la New York Times decision fatigue3. Aceasta are la baz faptul c n fiecare decizie luat sau alegere fcut pe parcursul zilei, creierul obosete i ajunge spre sfritul zilei s ia cu greu deciziile cele mai bune. Astfel, la sfritul zilei, cnd nivelul energiei este sczut, este foarte probabil s acionm dup impuls sau s evitam luarea unei decizii. De cele mai multe ori nu realizm aceast oboseal mental i o contientizm abia dup o alegere mai puin inspirat. De aceea este bine s planificm deciziile importante dimineaa. Un exemplu pe care muli oameni de succes l adopt, probabil i din alte motive nu doar pentru a-i uura deciziile este utilizarea unei garderobe ct mai simple. De exemplu, Mark Zuckerberg are o mulime de tricouri gri de acelai 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 pn i puinul efort de a se decide cu ce s se mbrace dimineaa, decizie care pentru unii, poate dura zeci de minute bune. Pn i deciziile precum ce s mnnc azi, s merg la sal sau la bazin, ne consum ntrun fel sau altul, fr s ne dam seama.
80/20
Din categoria Life isnt fair, principiul Pareto sau legea 80/20 subliniaz faptul c majoritatea lucrurilor din via nu sunt distribuite n mod egal. Enunul generic al principiului spune c 20% din efort creeaz 80% din rezultate. Dac ar fi s inversm enunul, ar iei ceva de genul: 80% din efort creeaz 20% din rezultate. Cel din urm parc sun ceva mai productiv, mai mult munc i muli se ghideaz dup aceasta, investind efort i timp n ceva ce nu este necesar4. Dei ne-am dori uneori ca viaa s fie conform linei roii din grafic, majoritatea lucrurilor au o distribuie 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/
n realizarea unui nou produs clientul are o idee sau un pic mai mult dect o idee, ns rar se ntmpl 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 direcie pe care s o ducem ct mai aproape de finalizare. Iar acel prototip propus se va regsi cu siguran, ntr-un procent foarte mare n produsul final; ceea ce urmeaz sunt trsturi adiionale. Dac am fi investit mult timp doar ntr-o direcie care s-ar fi dovedit a fi una greit, am fi consumat 80% din efort pentru doar 20% din rezultate. Deci, aceeai unitatea de intrare ( efort, timp, for de munc ) nu contribuie n mod egal la rezultate. Prin urmare, n distribuirea timpului, resurselor i a efortului soluia optim este cea care presupune 20% efort i care gene- Concluzii reaz 80% rezultate. Sunt cteva pattern-uri care ne distrug productivitatea. Printre cele mai evidente Axiome se numr multi-tasking-ul i ntreruperile Multe dintre lucrurile amintite mai sus cauzate de notificri sau cereri din partea pot fi sau nu aplicate n funcie de princi- colegilor sau cunoscuilor. Acestea, dar i piile fiecruia. Urmtoarele idei ar putea fi celelalte obiceiuri mai puin bune pot fi ncadrate ca axiome, fiind general valabile evitate sau diminuate apelnd la voin i i neavnd nevoie de nici o demonstraie. disciplin. n cazul n care Fabebook-ul i Un mod evident de a face mai multe email-ul sunt mai puternice , exist aplicaii lucruri ntr-un timp mai scurt este folosi- care i pot restriciona accesul la anumite rea shortcut-urilor sau a short key-urilor. pagini web. Unelte mai puin 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 mbuntirea mite pagini web sau n anumite aplicaii. O stilului de lucru. Fiind multe i variate, astfel de unealt este chiar util pentru o o bun strategie ar fi nvarea acestora statistic personal legat de timpul petregradual: cteva short key-uri pe zi. De ase- cut n faa calculatorului. Avnd 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 aduga i gabriela.lipoiu@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
32
management
Metodologia Lean pentru Requirements Engineering

n prezent, datorit evoluiei rapide a tehnologiei i a uurinei accesului la informaie, aproape oricine are posibilitatea de a construi produse sau servicii software pe care s le adreseze pieei globale. Aadar, n ciuda istoriei relativ recente a acestui domeniu, industria software a devenit nfloritoare genernd un interes uria n domenii de activitate precum dezvoltarea, testarea sau distribuia.
Radu Orghidan
radu.orghidan@isdc.eu Requirements engineer @ ISDC
Ingineria specificaiilor, cunoscut sub denumirea de Requirements Engineering (RE) [1,2], este o parte important a procesului de dezvoltare de software. S-a demonstrat, att n literatura [3,4,5] ct i din experiena noastr n ISDC, c erorile rezultate din modelarea imprecis a proceselor sau nenelegerea corect a funcionalitii de implementat genereaz costuri mult mai mici atunci cnd sunt descoperite n timpul definirii specificaiilor dect atunci cnd defectele apar n producie. n plus, cea mai mare parte a costurilor unui proiect software este absorbit n faza de mentenan, aceste costuri fiind influenate n mod direct de calitatea specificaiilor i analizei iniiale. Directorul de produs (eng. Product Owner - PO) este cel care interacioneaz 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 clieni. Pentru un PO comunitatea RE este unul dintre instrumentele folosite pentru a satisface nevoile clienilor. Schimbnd sistemul de referin, procesul de RE poate fi vzut ca produsul pe care companiile software, prin intermediul echipei de RE, l ofer clienilor lor. Metodologia Lean a fost introdus i implementat de Toyota n sistemul propriu de producie. Aceasta se concentreaz pe aspectele care produc valoare utilizatorului crescnd astfel calitatea produsului obinut, n timp ce durata de dezvoltare i costurile scad. Eric Ries, n cartea sa The Lean Startup [6] definete startupurile ca fiind instituii umane construite pentru a livra un nou produs sau serviciu n condiii de incertitudine.
Un startup implic deci o interaciune uman ce are loc ntr-un mod structurat. Similar, specificaiile se obin folosind tehnici de investigaie bine definite precum interviurile, sesiunile de workshop , observarea, construirea de prototipuri etc.. A doua parte a definiiei pune accentul pe faptul c startupurile livreaz un produs sau serviciu fr s tie cu certitudine cum se va adapta acesta la nevoile utilizatorilor finali. Iat din nou o similitudine cu activitatea comunitii RE care trebuie s dezvolte o serie de cerine [7,8,9] ce vor trebui s se adapteze nevoilor clientului n timp ce descriu un nou produs ct mai precis posibil. Pornind de la observaia c departamentul de RE al unei companii productoare de software poate fi asimilat cu uurina unui startup, vom analiza ideea extrapolrii 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 rnd, activitatea de RE va fi prezentat precum un produs vndut companiilor care investesc n dezvoltarea de produse software; n al doilea rnd, vom arta cum metodologia Lean poate fi aplicat activitii de RE. Ca o observaie interesant, metodologia Lean poate fi simultan aplicat ambelor pri implicate n activitatea de RE: clientul o poate folosi pentru a defini activitile pe care startup-ul trebuie s le desfoare pentru a construi un produs de succes n timp ce echipa de RE poate aplica metodologia Lean pentru a defini procesul necesar definirii specificaiilor necesare pentru obinerea unui produs software cu funcionalitatea dorit.
33
management
Metodologia Lean pentru Requirements Engineering nva, Msoar, Construiete
Produsele software pot fi dezvoltate folosind diverse metodologii precum: waterfall, iterative sau agile. Independent de soluia aleas, activitatea de RE este un pas obligatoriu care preced dezvoltarea de software. n mod obinuit, faza de RE este urmat de dezvoltare i apoi de lansarea n producie. Aadar, perioada de nvare a unei companii ce lanseaz un produs nou este mprit ntre faza de RE i cea de intrare n producie, cu pondere majoritar dup Figura 2. Crearea unui Produs Minimum Viabil ce produsul ncepe s fie folosit de clienii permite comunitii RE s ndeplineasc nevoile reale finali. ale clienilor. Imagine preluat de pe site-ul Lean Figura 1 descrie un flux tipic de Entrepreneur (http://LeanEntrepreneur.com/) producie care ncepe cu construirea specificaiilor urmat de dezvoltare i asi- i analizarea cerinelor, dezvoltarea gurarea calitii produsului terminnd cu specificaiilor, managementul specificaiilor, lansarea produsului. transmiterea i auditarea specificaiilor. Aa cum se arat n Figura 3, acest proces urmrete fluxul Construiete, Msoar, nva.
Figura 1. Perioada de nvare a unei companii ce lanseaz un produs nou ncepe n etapa de RE i se finalizeaz dup ce produsul ncepe s fie folosit de clienii finali. Figura 3. Procesul folosit n cadrul
n timpul primei etape, trebuie s trecem printr-un proces de nvare pentru a adapta cerinele clientului la domeniul de activitate i la constrngerile de ordin tehnic. Cu toate acestea, n faza iniial exist foarte puine date despre impactul produsului asupra utilizatorilor finali, despre cum va fi primit i neles de pia. Atunci cnd produsele dezvoltate includ o component de inovare important este foarte dificil s se anticipeze reacia clienilor. 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 nvare este recoltat dup lansarea produsului. Metodologia Lean inverseaz procesul industrial de producie format din secvena Construiete, Msoar, nva . n loc de aceasta, teoria Lean susine ideea crerii unui Produs Minimum Viabil care se folosete pentru a nva ce doresc utilizatorii finali cu adevrat i, prin urmare, permite dezvoltarea unui produs adaptat nevoilor reale ale clienilor, dup cum este ilustrat n Figura 2. Dac ne concentrm pe stadiul de RE i continum analogia dintre comunitatea RE i un startup, n ISDC am ncercat s nelegem cum s aplicm metodologia Lean n cadrul unui proces intern de RE. n mod tradiional, procesul de RE cuprinde urmtorii pai principali: planificarea, obinerea
comunitii RE din ISDC.
Pentru a adapta acest proces metodologiei Lean, RE trebuie s dezvolte specificaiile n iteraii scurte i s valideze continuu rezultatele cu clientul. Scrierea specificaiilor trebuie s fie o prioritate deoarece aport informaii valoroase echipei de dezvoltare a produsului att din punct de vedere funcional ct i din perspectiva nelegerii modului de lucru al clientului, ale valorilor acestuia i ale ateptrilor pe care le are de la RE. Prin aplicarea metodologiei Lean, se ncearc acumularea ctor mai multe cunotine 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 obin informaia corect crend un Produs de Specificaii cu Valoare Minim (PSVM) i msurnd feedback-ul clientului. ncercarea de a identifica un concept i de a-l valida prin experimente empirice este cunoscut n metodologia Lean ca nvare validat (eng., validated learning). Din experiena noastr, lipsa informaiilor de nvare validat duc la frustrri de ambele pri i la ntrzieri n dezvoltarea produsului.
construirea unui startup. Prin urmare, Lean canvas poate fi folosit de asemenea de ctre comunitatea RE. Considernd Produsul i Piaa ca fiind principalii piloni n jurul crora se construiete un startup, urmtoarele aspecte trebuie luate in considerare: Produs Problema: Identificarea problemelor de rezolvat pentru client, Soluia : Identificarea soluiei i validarea experimental, Metricile: Modalitile de msurare a succesului Costurile: Identificarea costurilor fixe i variabile. Piaa Segmentele de clieni i pionierii: trebuie s se fac o distincie ntre clieni i utilizatori.Pionierii sunt acele persoane care vor folosi produsul nc de la lansarea acestuia sau chiar dinaintea lansrii. 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 paii cei mai importani n construirea unui startup este identificarea clientului final. n procesul de RE din ISDC, aceasta este echivalent cu identificarea prilor interesate care sunt responsabile cu dezvoltarea produsului. Pentru a identifica persoanele potrivite, analiza trebuie s considere numrul potrivit de candidai. 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. Totui, grupul nu trebuie s fie prea restrns deoarece segmentul int se va micora ceea ce va duce la pierderea din vedere a opiniilor unor clieni importani. Odat ce se stabilesc persoanele responsabile de proiect, cel mai important segment dintre acetia va trebui s fie identificat. Acesta poate include clienii care au o conexiune cu comunitatea de RE de exemplu, sunt mai uor de atins sau pot comunica mai bine. n aceast faz, este foarte important s fie realizat distincia ntre clieni i utilizatori: clienii pltesc 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 informaii despre cele mai valoroase caracStack [10], este deosebit de util n analiza i teristici ale produsului chiar i nainte de
34

lansarea acestuia. Ca i n orice startup, comunitatea RE din ISDC trebuie s poat identifica problemele de rezolvat pentru client. O lecie nvat din proiectele noastre este aceea de a identifica cele mai importante trei probleme ale utilizatorilor folosind analiza cauzal bazat pe cinci ntrebri. Este de asemenea foarte interesant de analizat soluiile pe care clienii le folosesc n momentul construirii produsului pentru a-l substitui. Se pot identifica astfel alternative pentru a mbunti situaia existent. Produsul sau serviciul oferit de RE nu trebuie s fie perfect ns trebuie s fie o mbuntire clar a alternativelor existente. De exemplu, n comunitatea noastr, aducem experi n domeniile abordate. Acest lucru ne permite s oferim clientului o privire mai proaspt i obiectiv comparativ cu ceea ce s-ar obine folosind experii interni ai clientului. Un alt aspect care trebuie evaluat cnd se definete o soluie pentru problemele clientului este s se neleag ce anume nlocuiete produsul. Orice produs nlocuiete ceva i echipele noastre de pre-sales i RE au misiunea de a clarifica motivaia clientului de a-i asuma riscul prin adoptarea produsului propus. Suntem deosebit de ateni cu aceste aspecte deoarece serviciile oferite clienilor notri vor nlocui probabil unele sarcini realizate de echipe interne sau, n unele cazuri, vor nlocui chiar echipe ntregi. PSVM, adic soluia ce implic cel mai mic efort de dezvoltare care ofer valoare utilizatorului, trebuie s fie definit. Soluia poate s nu fie unic, iar clientul are n general mai multe propuneri, incluzndule bineneles i pe cele ale concurenei. Pentru a atrage atenia clientului ne concentrm pe a defini o propunere unic. Aceasta trebuie s se poziioneze la intersecia principalei probleme a utilizatorului i soluia propus de noi. Pentru a avea un impact maxim, propunerea trebuie s fie enunat cu claritate i s includ descrierea rezultatului livrat utilizatorului, s fie ncadrat n timp i s anticipeze potenialele obiecii. De exemplu, o propunere poate s aib urmtorul coninut: Specificaii definite cu claritate, livrate n x zile lucrtoare i cu garania unei soluii fr defecte. Bariera de intrare este un factor intrinsec al companiei sau a soluiei propuse, precum brand-ul, experiena n domeniu, dimensiunea sau componenta echipei, nia de specializare etc .. Aceti factori nu pot fi copiai sau cumprai cu uurin i pot fi folosii pentru a ntri propunerea noastr. Este de asemenea util de pregtit o metafor care s ofere clienilor mai puin familiarizai 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 cteva canale i altele vor aprea n mod natural, pe parcurs. Definirea metricilor de succes este esenial 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. i care totodat ofer valoare clientului. Artm, prin analogie, c i specificaiile pot fi elaborate ca un PSVM (Produs de Specificaii cu Valoare Minim). Alte contribuii ale metodologiei Lean folosite n procesul comunitii RE din ISDC sunt conceptele de nvare validat (eng. Validated Learning) i ideea inversrii procesului tradiional de construire a documentelor de specificaii i transformarea fluxului n secvena nva, Msoar, Construiete. Dezvoltarea specificaiilor n pai mici i validarea rezultatelor cu clienii sunt cruciale. Respectnd aceste principii comunitatea RE acumuleaz cunotine importante att din punct de vedere funcional ct i n ceea ce privete modul de lucru al clientului i ateptrile acestuia n urma procesului de dezvoltare al specificaiilor.
Bibliograe
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 Todays Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Eric Ries, Crown Business (September 13, 2011), ISBN-10: 0307887898, ISBN-13: 978-0307887894
Concluzii
Acest articol s-a concentrat pe serviciile RE n contextul oferit de compania noastr. n ISDC, vedem activitatea de RE att ca un produs n sine ct i ca o activitate antreprenorial. Aceast viziune a dus la ideea adaptrii principiilor Lean activitii de RE pentru a mbunti procesul existent. Metodologia Lean se concentreaz pe acele activiti care produc valoare clientului ducnd n acelai timp la reducerea duratei ciclului de dezvoltare i a costurilor precum i la creterea calitii produsului. Una dintre conceptele cheie ale Lean este MVP (Minimum Viable Product) care reprezint soluia cu un efort minim de implementare
35
HR
Trenduri n HR (II)
organizaiei. Rolul lor este s introduc cele mai bune practici i s le aplice n companie astfel nct 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 cteva zone cheie: mbuntirea procesului de definire a cerinelor (en.: requirements); Alinierea prioritilor proiectului utiliznd cele mai bune practici n domeniu, precum i mbuntirea modelului de business prin capacitatea de nelegere a celor mai bune practici n industrie; Articolul din numrul 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 experilor n dome Scderea costurilor pe proiecte. Experii n domeniu pot niu) livra sarcini mai repede i mai corect, costurile pentru proiect Un expert n domeniu este o persoan care posed cunotine 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 aplicaie anume, deoarece aplicaiile se pot nva mai uor cunotine speciale i specifice sau competene att n zona de dect business-ul care st n spatele lor.De aceea cu ct o persoan business ct i n zona de IT care s creasc performana n cadrul este mai expert ntr-un anumit domeniu, cu att e mai valoroas
a cum menionam n articolul din numrul 19 TSM, aceast parte a doua a HR Trends n 2014 va acoperi nc cinci tendine identificate pe piaa din Cluj. La nceputul acestui articol, menionm c este expresia un punct de vedere subiectiv, bazat pe experiena realizat n zona de HR, neavnd la baz un studiu ntreprins n aceast direcie.
Dac n prima parte ai putut citi despre: 1. HR Business Partnering (HR privit ca partener de business i nu ca funcie support), 2. Attract and retain top talents (Atragerea i retenia angajaiilor de top), 3. Employer branding (Poziionarea companiilor pe pia), 4. Career path and development plans (Planuri de dezvoltare a carierei pe temen mediu i lung), 5. Employee engagement (Creterea angajamentului n cadrul companiei).
36

i poate aduce un plus semnificativ n compania n care lucreaz. ntre nevoile existente n companie i nevoile viitoare. Pentru o bun planificare a resursei umane, se vor crea profilele angajaiilor care se doresc a fi recrutai i se compar dac abilitile i competenele cutate pot fi gsite n interiorul sau exteriorul companiei. Pasul 7 : dezvoltarea strategiei de resurse umane, lund n considerare cei ase pai enumerai anterior. Retenia angajailor - ce creeaz un nivel ridicat de angajament i de retenie? Analiza abilitilor de leadership care sunt liderii cei mai de succes i care este procesul de dezvoltare a abilitilor lor? Acoperirea unor diferene ntre abilitile care exist n companie i cele care trebuie dezvoltate cum ar trebui aceste lacune previzionate i ce msuri se pot ntreprinde pentru a le acoperi? Pipeline de candidai - cum putem mai bine atrage i selecta oameni care tim c vor reui n cadrul organizaiei?
7. Workforce planning processes (Dezvoltarea proceselor de planicare a forei de munc)
Planificarea resurselor umane este procesul de baz n asigurarea pe termen lung a competenelor i aptitudinilor n rndul angajailor, necesare ndeplinirii obiectivelor strategice. Pentru ca planificarea s fie ct mai exact se vor lua n considerare dou variabile: contextul organizaional (mediul intern) i contextul pieei muncii (mediul extern). Procesul nu are neaprat 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 pstrare. 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 rndul ei, poate influena strategia economic. Planificarea resurselor umane este unul dintre rolurile strategice fundamentale ale proceselor de resurse umane, care poate s vin cu o contribuie major la dezvoltarea capabilitii de resurse umane a organizaiei i, prin urmare, la dezvoltarea capabilitii strategice a acesteia, prin revizuirea sistematic a obiectivelor strategice ale firmei. Obiectivul planificrii resursei umane: este de a evita lipsa sau surplusul de resurse umane n cadrul companiei i de a asigura competenele i abilitile potrivite la locul potrivit i la momentul potrivit. A prezenta planificarea resursei umane ntr-un proces integrat, care cuprinde apte pai. Paii 1 i 2 : urmresc nelegerea obiectivelor i strategiei organizaiei, pentru a identifica nevoile companiei. Pasul 3: presupune evaluarea organigramei curente i a resurselor prezente. Pentru aceasta este nevoie de actualizarea organigramei i a fielor de post, din punctul de vedere al responsabilitilor, competenelor i abilitilor. Paii 4 i 5: pentru o bun planificare/ organizare/programare a resursei umane, este necesar utilizarea planurilor de succesiune, pentru a putea previziona eventualele demisii, promovri n cadrul companiei. De asemenea se evalueaz rata de retenie a angajailor i motivele pentru care acetia prresc organizaia. Pasul 6 : strategia de dezvoltare a companiei, va evidenia o discrepan
8. Leadership development (Dezvoltarea abilitilor de leadership)
ntr-un ar ticol anterior despre importana dezvoltrii abilitilor de leadership ntr-o companie, afirmam atunci c exist patru categorii de competene care ar trebui cultivate de ctre fiecare lider n parte: Orientarea ctre oameni ( People leadership) care pune accentul pe capacitatea individului de a comunica, de a-i coordona pe ceilali i de a lucra la rndul su ntr-o echip. Leadership personal ( Personal leadership ) capacitatea de a se adapta la situaii i medii noi i nu n ultimul rnd inteligena emoional. 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 nele mediul de business i organizaia n care activeaz i poate indentifica n acelai timp viitoare tendine ale mediului extern i intern.
Departamentul de resurse umane, ar trebui s gndeasc mai mult n afara cutiei, att n ceea ce privete procesele, dar i n ceea ce privete adaptarea la nevoile business-ului. Cred c HR-ul de pe piaa din Romnia, ar trebui s fie din ce n ce mai concentrat i pe implementarea de bune practici n domeniu. Este mbucurtor 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 deintor de talente care trebuie descoperite i dezvoltate. Inovaia n departamentul de HR ar trebui s vin i din abordarea mai informal i printr-o apropiere de angajai i management. HR-ul s devin un bun mediator. Pe lng abordare consider relevant i aducerea unui dram de creativitate n implementarea unor procese, adoptarea chiar a unor metodologii de lucru n funcie de domeniul de activitate al fiecrei companii. Am susinut 9. Talent Analytics (Analiza datelor si a n articole anterioare ct de important este surselor de obinere a lor) ca HR-ul s devin AGILE, pentru a rsMajoritatea companiilor au o mulime punde eficient i eficace att nevoilor de de date despre resursele umane, fie c vor- business ct i nevoilor angajailor. bim despre date demografice, evaluri 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 influeneaz analiza datelor este i nevoia de competene n analiza de date i realizarea statisticilor. Cei mai muli profesioniti de resurse umane nu au nc aceste aptitudini, astfel nct companiile trebuie s-i gseasc pe aceti oameni i s i aduc mpreun Andreea Prvu andreea.parvu@endava.com pentru a extrage ct mai multe informaii relevante. Este un moment oportun n care Senior Recruiter @ Endava profesionitii de resurse umane s se concentreze pe analiza unor aspecte eseniale:
10. Innovation (Inovaie n departamentul de HR)
37
programare
Perspective asupra principiilor n design-ul orientat pe obiecte

efiniia entropiei pe care cu siguran am auzit-o cu toii nu las loc de interpretare: cu ct entropia este mai mare cu att dezordinea i haosul ncep s si fac de cap. Acest lucru nseamn impredictibilitate care nu se numr cu siguran printre calitile 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, dei 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 msur s spunem foarte multe despre acel design, putem spune de exemplu c el rezolv o anumit problem care are nevoie de un anumit numr de stri. Poate prea contraintuitiv, dar pentru a obine un design bun clasele care motenesc alte clase trebuie s aib o entropie mai mare dect cea a claselor de baz, orice ncercare de a reduce entropia ntr-o clas derivat va duce n general la situaii 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) influeneaz entropia local a designului. Voi ncepe cu Principiul Substituiei Liskov (LSP) pentru c influena entropiei este observabil ntr-un mod clar i p ermite exemplif icri concrete. n cteva cuvinte, LSP este o regul care ajut programatorii s decid cnd anume o clas poate s moteneasc o alt clas. Unul dintre cele mai cunoscute exemple de ncalcare LSP este urmtorul: Imaginai-v c ai creat o aplicaie care gestioneaz dreptunghiuri. Aplicaia are un success att de mare nct utilizatorii solicit un nou feature pentru ca aplicaia s poat gestiona i ptrate. tiind c un ptrat este un dreptunghi cu toate laturile egale, cea mai la ndemna alegere de a extinde designul este s folosim motenirea.Astfel, adugm o nou clasa numita Square care va moteni clasa transferul in reea. n cazul n care acest Rectangle, n acest fel putem reutiliza toate observaie nu vi se pare suprinztoare, funcionalitile deja implementate. aflai c o singur aruncare a unei monede (datul cu banul) are o entropie de un bit! class Rectangle Entropia msoar cantitatea de informaie { public: necesar pentru a reprezenta toate strile void SetWidth(double w) { unei variabile aleatoare. width = w; } Pentru cantiti mici de informaie double GetWidth() const { putem identifica reguli simple de reprereturn width; } zentare concis a tuturor strilor variabilei. void SetHeight(double h) { ns n cazul haosulului sau al secvenelor height = h; } de numere aleatorii avem de a face cu double GetHeight() const { entropii uriae, adevrate explozii de return height; } informaie unde nu exist reguli simple private: pentru a anticipa, de exemplu, urmtorul double height; double width; numr din secven. }; [V oferim cteva detalii legate de asemIn Square suprascriem SetWidth si nrea dintre entropia din termodinamic SetHeight pentru a ne asigura c cele patru i entropia Shannon. n final,ambele reprelaturi sunt egale. zint de fapt acelai lucru. Imaginai-v un container cu dou lichide (unul alb i unul void Square::SetWidth(double w) { negru) separate de un perete. Dup ndeRectangle::SetWidth(w); prtarea peretelui lichidele se amestec, prin Rectangle::SetHeight(w); } urmare entropia termodinamica crete. Din void Square::SetHeight(double h) punctul de vedere al teoriei informaiei, iden{ Rectangle::SetHeight(h); tificarea poziiei fiecrei particule n raport Rectangle::SetWidth(h); cu poziia sa iniial fa de peretele des} prtitor (la stnga sau la dreapta de acesta) Aceast alegere nu este una fericit necesit mult mai mult informaie dect ins nu voi insista asupra motivelor cla- atunci cnd lichidele nu sunt amestecate.] sice1. V voi arta ns o alt perspectiv Exist, de asemenea, o definiie i a implicaiilor 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 variaiei entropiei. posibile (x1, x2, x3, xn) entropia Shannon Mai nti, cteva cuvinte despre entro- (notata cu H (X)) se poate calcula dup pie. Entropia Shannon este o msur a formula: incertitudinii asociat unei variabile aleatoare i este de obicei msurat n bii. Remarcai c este aceeai unitate de msura folosit pentru a determina capacitatea memoriei sau limea de band pentru unde p(xi) reprezint probabilitatea ca 1 o discuie interesant despre acest subiect gsii 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 lum cteva exemple n scopul de a
38

cpta o nelegere asupra a ceea ce repre- tim de la primul exerciiu c entropia este zint formula i de ce are sens s msurm egala cu 1 n acest caz. entropia n bii. [Mai exact, n funcie de baza logaritmului H(XS)=1 (bit) entropia este msurat n bii (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: Ct de mult informaie este necesar Ori de cte ori o clas S (Square) pentru a stoca o variabil aleatoare X care extinde o clas R (Rectangle), este neceia valori n mulimea {0, 1}? sar ca H(X S)>=H(X R) . n cazul nostru Considerm [Aceasta nseamn ca 0 i 1 1=H(XS)<H(XR)=2 ! Ce se ntmpl de fapt au aceeai ans, 50%, de a fi atribuite lui cnd nclcm regula entropiei? X]. S presupunem c avem metoda (funcia) m care folosete obiecte de tip R. n cazul n care clasa S extinde clasa R prin nclcarea regulii entropiei, atunci Exemplul 2 metoda m va trebui s plteasc preul Ct de mult informaie 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 mulimea {00, 01, 10, 11}? Lum este adugarea de if-uri prin care s se n considerare [Aceasta nseamn discrimineze ntre Square i Rectangle). c toate valorile au aceeai ans, 25%, de a fi atribuite lui X]. Formula ne spune c [Aici aspectul important este modul n care designul crete entropia, deoarece haos-ul i dezordinea din interiorul codului provine i din modul n care entropia este crescut, [ntrebai-v dac stii definiia bitului. structurat i utilizat n cadrul claselor.] Definiia nu este evident ns fiecare programator crede c o cunoate (este ntr-un Un exemplu din lumea real fel amuzant cnd 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 comprivina 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 rspundem nu cumva este blocat) i la o ntrebarea: Ct de mare este entropia folosete interiorul unei clasei Rectangle? Analizm domeniul n camere pentru a face acest care ia valori, mai precis combinaiile posi- lucru. Iat un mod simplu de a scrie aceasta bile de lime i nlime. 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 reprezentnd o combinaie } de lime (w) i nlime (h). Din exemplul anterior tim c entropia unei astfel de variImaginai-v c entropia camerei este abile aleatoare este egal cu 2. proporional cu volumul su. Ce s-ar ntmpla dac am extinde clasa Room H(XR)=2 (bii) prin reducerea entropiei (a volumului)? S numim aceast nou clasa FakeRoom. Ct de mare este entropia clasei Square? Ei bine ... urmtoarea imagine vorbete de Observm domeniul n care iau valori la sine. limea i nlimea n cazul simplificat cu Informaia (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 ua i camera sunt cuplate diferit, deoarece limea i nlimea nu (strong-coupling). Nu vom mai putea utiliza mai variaz n mod independent. De fie- aceast u la o alt camer fr a ridica care dat cnd este setat limea (w) este semne de intrebare! setat i nlimea (h) cu aceeai valoare. [Dezvoltatorii trebuie s neleag 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. Scderea entropiei prin utilizarea motenirii este un semn de nclcare a ncapsulrii unei clase. 2. Agregarea este recomandat n locul motenirii. Nu exist o modalitate de a nclca regula entropiei atunci cnd se utilizeaz agregarea. Entropia poate fi variat dup dorin. 3. S depinzi de abstractizri este o practic recomandat pentru c interfaele 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 nclcare a LSP n sensul c, dac ne supunem regulii am putea obine un design bun, n timp ce dac nclcm regula acest lucru duce cu siguran la un design prost. 5. Entropia design-ului este o perspectiv care poate mbunti metodele deja existente de detectare a nclcrii LSP.
Ctlin Tudor
ctudor@ixiacom.com Principal Software Engineer @ Ixia
39
programare
Machine learning in the cloud

nul dintre factorii cei mai importani n explozia nvrii automate n ultimii zece ani a fost puterea crescut de calcul. n 2010, Dan Cirean et al. au dobort recordul de recunoatere de cifre scrise de mn, folosind un algoritm inventat prin anii 1980 i augmentnd 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 cnd pe un CPU ar fi durat mai mult de 50 de zile. Dar odat cu creterea puterii de calcul a procesoarelor, cantitatea de informaie disponibil a crescut i ea, chiar mai repede dect frecvena CPU-urilor. Pentru a face fa situaiei, au aprut tot felul de soluii cloud, majoritatea oferite de startup-uri, care se specializeaz pe diferite nie de nvare automat.
Printre primii care au oferit servicii de nvare 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 mbuntiri, cum ar fi diverse strategii de fasonare i opiunea de agregare a mai multor modele. Odat ce am antrenat un model, putem s l vizualizm prin dou tipuri de diagrame, care ne ajut s vedem cum influeneaz fiecare trstur rezultatul dorit. Una din vizualizri este un Sunburst diagram pentru acelai model arbore interactiv pe care putem s urmm decizia luat la fiecare nivel, iar cealalt vizualizare este numit Sunburst diagram, care prezint numrul de instane din datele de antrenare pe care este bazat fiecare decizie n parte, precum i intervalul de eroare pe care l va avea rezultatul obinut mergnd 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 plnuiesc s se deschid publicului prin aprilie-mai. i dintr-un API HTTP.
Grafice pentru acurateea i valoarea funcie de cost Vizualizarea arborelui de decizie pentru un model al notelor obinute de un student
Ei se specializeaz pe deep learning. Ofer diferite modele de reele neuronale, se seteaz hiperparametrii lor i apoi se pornete antrenarea, pe care ei o efectueaz pe GPU pentru a obine vitez
40

mai mare. Ei analizeaz datele pe care le ncrcm la ei i ofer o analiz euristic prin care sugereaz ce valori ale hiperparametrilor se potrivesc cel mai bine datelor noastre. Cu cteva ajustri, am reuit s obin n cinci minute un model care mi recunotea 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 acurateea, valoarea funciei de cost i valorile maxime ale ponderilor reelei neuronale de-a lungul iteraiilor. Apoi, bazndu-ne pe acestea, putem s decidem cum s continum, n ce direcii s mai ajustm hiperparametrii. Dei invite-urile pentru beta se primesc de obicei n aceeai zi, trebuie inut cont de faptul c nc este n beta. Cnd am testat servicul, pe primul set de date pe care l-am ncercat am ntmpinat o eroare misterioas, Training failed. Apoi persoana de la suport tehnic a inforrmat c a fost descoperit un bug n Pylearn2, librrie pe care o folosesc ei n spate pentru definirea modelelor de reele neuronale. Au fost destul de prompi n rezolvarea acelui bug, dar tot am mai ntlnit chestii care nu prea aveau sens. Modelele pe care le ofer deocamdat sunt autoencoder-e pentru date sub form de imagini, reele recurente pentru date temporale, reele neuronale cu straturi sigmoide sau ReLU i reele neuronale convoluionale cu sau fr maxout. suficient de generale ca s funcioneze n orice domeniu. Problema apare cnd vrem s folosim o limb care nu este bine integrat, ca de exemplu romna, la care deocamdat serviciul pur i simplu nu tie ce s rspund. 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 aplicaiile noastre.
Entiti gsite de AlchemyAPI ntr-un post des-
PredictionIO este un pic diferit fa de celelalte produse din aceast list. Dei 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, avnd un istoric al aciunilor efectuate de un utilizator (vizionarea, cumprarea sau acordarea unei note unui produs), s i sugerm 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 rulm evaluri simulate. Cealalt parte este un API HTTP (cu SDK-uri pentru diferite limbaje) prin care putem s adugm user-i, produse, aciuni i apoi s obinem recomandri. Faptul c este bazat pe MongoDB i pe Hadoop ofer o putere destul de mare la PredictionIO, dar n acelai 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 main totul i s l faci s ruleze pe un cluster, deja trebuie s te descurci cu Hadoop, pe cnd la celelalte servicii menionate, cnd ai nevoie de mai mult putere de procesare, doar faci un click n browser (i plteti mai mult). AlchemyAPI ofer i ei servicii de deep learning, dar la un nivel mult mai nalt dect cei de la Ersatz. n loc de a-i oferi posibilitatea de a antrena reele neuronale pe orice fel de date doreti, ei s-au specializat pe procesarea de limbaj natural i ofer doar un API prin care se pot extrage entitile menionate 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 fcut deja. Atta timp ct ne limitm la limbile pentru care au suport, nu vom avea probleme, problemele de extragere de entiti, cuvinte cheie, autor sau sentimente fiind
pre noul limbaj al lui Stephen Wolfram
Acestea sunt doar cteva din serviciile de nvare 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 predicii), sau hat, care este la latura complet opus, oferind un framework n care noi trebuie s integrm ce algoritm de nvare automat dorim.
Roland Szabo
roland.szabo@3pillarglobal.com Junior Python Developer @ 3 Pillar Global
41
programare
Dezvoltare rapid de aplicaii web cu Oracle APEX
Aflai c exist un produs trecut cu vederea numit Oracle Application Express (APEX) care ar putea s fie rspunsul pentru dezvoltatorii one-off de aplicaii web, cei de baze de date, dar i programatorii experimentai. Folosind un mediu de dezvoltare declarativ, putei construi aplicaii web profesioniste cu o abordare click-and-click. Surpriza vine din faptul c acest tool este dezvoltat de Oracle, o corporaie renumit pentru produsele sale scumpe i exclusiviste. APEX este un tool gratis (dar nu open source) care s-a nscut dintr-un proiect intern al Oracle menit s fac fac mai uoar viaa programatorilor i administratorilor de baze de date. Experiena mea cu APEX a nceput n anul 2009, pe cnd lucram ca Oracle database developer la o companie specializat n asigurri de via. Principalul task era integrarea mai multor sisteme software, att interne ct i folosite de clieni. Partea bun era c toate componentele software foloseau Oracle ca baze de date; partea proast era c nu aveam la dispoziie suficient timp i resurse umane pentru a dezvolta interfeele ntre sisteme n Java, .NET, PHP sau alt limbaj de programare sau framework. Managerul de dezvoltare avea puin experien la nceput cu APEX, ns avea mare ncredere n capacitile acestui tool. Aa a nceput o experien intensiv cu APEX 3.2 pe durata a trei ani, ntr-un moment cnd documentaia era puin, iar experii n domeniu i entuziatii APEX puteau fi numrai pe degete. Rezultatul a fost o experien de software development unic, mult documentaie 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 aplicaii web, n jurul unei baze de date Oracle, cu o comunitate de programatori specializai n cretere i evangheliti dedicai care promoveaz aceast tehnologie. Tehnica de programare este foarte declarativ i se desfoar ntr-un mediu web-based, investind un efort de codare minim. APEX folosete un concept unic care poate fi considerat opusul trendurilor actuale din dezvoltare aplicaiilor web. n timp ce acum majoritatea aplicaiilor web ar trebui s fie cuplate ct mai loose de bazele de date din backend, cu o emfaz pe interaciunea client-side, APEX are o abordare radical, n care totul este stocat n bazele de date, de la datele pn la meta-datele folosite pentru generarea paginilor web. Un web server al RDBMS-ului
i dorit vreodat s dezvoltai o aplicaie web foarte rapid, fr s fii nevoii s nvai un nou limbaj de programare? V-ai ntrebat de ce este nc dificil s creai pagini web cu formulare i rapoarte i de ce fiecare tool de Rapid Application Development devine rapid doar dup ce investii cteva luni pentru a-l nva? Oracle este folosit pentru a genera pagini HTML direct din baza de date, unde att datele folosite de aplicaie ct i meta-datele care descriu paginile aplicaiilor. Cu toate c APEX este un produs gratis, acesta funcioneaz doar cu bazele de date Oracle, marea parte a procesrilor de backend, dar i frontend fiind realizate de procedurile stocate. O aplicaie 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 interfaa 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 cnd 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 instane a unei baze de date Oracle, chiar i cu varianta free de baze de date Oracle XE, nu este nevoie de licensing adiional, pentru c numrul de developeri, aplicaii i end-users nu este restricionat. Suport toate versiunile de baze de date Oracle ncepnd cu 10gR2 i poate fi folosit i cu setup-uri Exadata, ORA i RAC. n mod implicit, Oracle APEX este distribuit cu toate ediiile bazelor de date Oracle. Din punct de vedere arhitectural, APEX folosete 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 fiiere. De fapt, APEX ruleaz o dat cu baza de date. APEX folosete un principiu de multitenant hosting, organiznd paginile web n aplicaii i workspace-uri, care pot folosi la rndul 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
42

cunotine avansate de programare, cu excepia 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 pn la grafice. Toate paginile i componentele sunt stocate n obiecte din baza de date Oracle, de obicei tabele i view-uri, aa c este pus la dispoziie i un tool de management a schemei bazei de date. Crearea de tabele, views i proceduri stocate se poate face direct n APEX, aa nct ntregul proces de dezvoltare se face n acelai environment, cel de dezvoltare web-based. APEX se poate accesa prin intermediul unui URL ntr-un browser web, fie c folosii o instan instalat local, o instan de private cloud (SaaS) sau serviciul Oracle Database Cloud Service, produsul cloud al Oracle care folosete APEX pentru dezvoltare de aplicaii web (http://cloud.oracle.com). Cu toate acestea, Oracle APEX nu este un tool care este potrivit oricrui proiect. Cazurile tipice unde APEX poate fi folosit sunt cele de aplicaii data-driven (aplic aii de productivitate la nivel de department sau aplicaii ad-hoc), reporting online bazat de queryuri SQL, transformarea spreadsheet-urilor Excel sau de alt tip n aplicaii 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 aplicaii ntr-un mod declarativ, folosind item-uri de pagini web deja existente cum ar fi: rapoarte, formulare, grafice, calendare, template-uri de UI, navigaie, validri, procese de pagin i aplicaie, servicii web, servicii de e-mail i localizare (traducere), autentificare, autorizare, logging i monitorizare. Pentru mai multe detalii legate de dezvoltare aplicaiilor APEX, putei achiziiona cartea Oracle APEX Reporting Tips&Tricks: http://www.apexninjas.com/blog/2013/06/ oracle-apex-reporting-tips-tricks-out-now/ De asemenea, putei ncerca o aplicaie 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 aplicaiile web n mod declarativ prin folosirea unor wizzards. Fiecare aplicaie este compus din una sau mai multe pagini, fiecare pagin este mprit n regiuni. Fiecare regiune a unei pagini poate s conin test, cod PLSQL, rapoarte, grafice, hri, calendare, formulare sau rezultate aduse prin intermediul unor servicii web. De asemenea sunt disponibile obiecte care sunt specifice nu doar paginilor, ci intregii aplicaii, 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 urmrirea feature-urilor, bugs i milestones. Acest tool este legat direct de paginile APEX.
George Bara
gbara@sdl.com Business Consultant @ SDL
43
prezentare
O viziune din interiorul GPS Navigaie
GPS Navigaie a fost lansat pentru prima dat n octombrie 2009. n acea perioad, Skobbler a fost prima companie care a folosit hrile OpenStreetMap, dezvoltate de o mic comunitate de entuziati. Aplicaia oferea navigaie pas cu pas cu condiia unei conexiuni permanente la internet. Dup aproape doi ani de update-uri i mbuntiri regulate, 1.5 milioane de utilizatori foloseau aplicaia. Pe lng calitatea oferit de funcionalitile existente, era nevoie de ceva nou. Axndu-ne pe nevoile utilizatorilor, am decis c sunt necesare navigarea offline i schimbarea radical a designului. Noul produs a fost lansat n octombrie 2011. Aplicaia era singura din industrie care oferea funcionalitate 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, rezolvnd i problema aplicaiilor tradiionale de navigaie care necesit cost ridicat de roaming i descrcarea pachetelor mari de date. Soluia oferit de noi a fost o interfa simpl, intuitiv, adaptat la mediul de utilizare a navigaiei n trafic.
n articolul de fa ne propunem s oferim o viziune de ansamblu asupra evoluiei aplicaiei de navigaie pe platforma de iOS, abordat din punct de vedere al dezvoltatorilor. De asemenea, vor fi analizate i funcionalitile, arhitectura i inovaiile ce se regsesc n versiunea 5.0, disponibil n AppStore din decembrie 2013. complet nou, difereniat prin paleta de Setul de funcionaliti ale versiunii culori folosit i poziionarea butoanelor. curente include urmtoarele: Pentru nceput am testat aplicaia la Stilurile de hart stilurile custominivel intern, iar feedback-ul echipei a gene- zabile permit utilizatorilor s modifice rat mbuntiri ale produsului final. skin-ul hrii n funcie de vreme sau timp. Stilurile de hart disponibile sunt stilul de zi-noapte, gray scale i stilul exterior. Pentru modul de navigaie exist stilul adiional de atenionare radare. Funcionalitatea offline aplicaia ofer opiunea de a cumpra i desDup o perioad ndelungat de dez- c rc a p achete de voltare i testare, produsul final a fost lansat hri pentru ri i pe AppStore. Noul UI inserat n aplicaie a orae, oferind acces contribuit la dublarea numrului de utiliza- la navigaie, afiare tori n primele sptmni de dup lansare. hart, rutare i cutare fr conexiune la internet. Cutarea online ct i offline utilizeaz serviciile Apple pentru cutarea adreselor i Tripadvisor, iar pentru puncte de interes (POI) utilizeaz motorul de cutare skobbler. Fr o conexiune la internet cutarea se bazeaz pe serviciile Skobbler precum cutarea pas cu pas pentru adrese i cutarea de POI-uri Urmtorul update major GPS pe categorii. Navigaie 5.0 a fost fcut n decembrie Ghidul de cltorie bazat pe 2013. Noutile acestei lansri au fost sti- coninutul Wikitravel, utilizatorii au acces lurile noi i funcionalitate Tripadvisor. la articole despre ri, orae i POI-uri Aplicaia a primit 4 stele i jumtate pe afiate pe hart. Articolele individuale sunt AppStore-ul din Germania i are n prezent disponibile att online ct i offline. peste 4 milioane de utilizatori. Navigaie i modul free-drive (radar) Echipat cu iOS SDK care ofer navigaia poate fi nceput pe o rut deja funcionalitai de navigaie i mapare, calculat, oferind utilizatorului informaii aplicaia folosete hrile skobbler (cunos- referitoare la destinaie, durata estimat, cute i sub denumirea de hri OSM+) numele strzilor, direcii i distane, ghibazate pe date OSM. Datele extrase din dare vocal, vitez curent, limit de vitez OSM trec printr-un process de analiz i i avertizri de depire a vitezei. mbuntire i sunt compilate de ctre Modul free-drive poate fi folosit fr skobbler n propriul format. a avea o destinaie specific. Acesta ofer
Am dezvoltat dou prototipuri cu elemente diferite de UI. Primul se axa mai mult pe un model de meniu tradiional, pe cnd cel de-al doilea aborda o direcie
44

un mod de vizualizare 2D i 3D, detecie de radare i informaii referitoare la strada curent.
Volumul de date colectat este aproximativ de 7 milioane kilometri pe zi. Aplicaia GPS Navigaie are la baz tehnologia NGx a skobbler i iOS SDK. Seciunea curent ofer o imaine de ansamblu asupra arhitecturii proiectului i componentelor acestuia. OSM+ - ofer hrile necesare pentru randare, rutare i navigare. Componenta core o component C++ crossplatform responsabil pentru randarea hrilor (Open GL), rutare, navigare, cutare. iOS SDK un layer objective C++ (similar cu MapKit oferit de Appla). Acesta asigur integrarea setului de funcionaliti suportate de ctre component Core n aplicaia nativ iOS. Clientul iOS interfa utilizator native iOS construit n jurul iOS SDK.
Arhitectura proiectului
Radare baza de date pentru detecia radarelor este la zi, radarele fixe sunt actualizate zilnic, n timp ce radarele mobile sunt actualizate la intervale de 5 minute. Serviciul de detecie al radarelor fixe este gratuit, n timp ce opiunea detecie radare mobile este accesibil ca serviciu premium. FCD ( floating car data ) - aplicaia utilizat zilnic de ctre milioane de utilizatori colecteaz un numr mare de date FCD. Informaia referitoare la reeaua de drumuri, vitez, direcie, timp sunt folosite pentru a mbunti hrile OSM+.
Echipa iOS @ Skobbler
45
HR
IMAGINE studiu al IT-ul clujean

cest articol prezint rezultatele unui studiu privind percepia studenilor asupra a zece firme de IT, mai cunoscute din Cluj. Fiind foarte probabil viitori angajai n aceste firme, percepiile lor (evident subiective) pot s ajute firmele de IT s i reconsidere politicile de atragere de candidai, att pentru politicile de HR, ct i pentru cele de PR. Astfel, i pot defini mai bine i locul n comunitatea IT local. Ca firm de consultan n Dezvoltare Organizaional i Managerial , care a lucrat cu mai multe firme de IT din Cluj, am dorit s aflm mai multe despre aceast industrie. De o bun perioad de timp se vorbete despre IT Cluster-ul din Cluj care dorete 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 fcut o cercetare, pe baza discuiilor cu oameni de HR din IT-ul clujean, ca s vedem cum au evoluat firmele, care sunt principalele provocri ale momentului i cum se vede ideea de comunitate IT. Am publicat concluziile discuiilor 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 creterii dorit de patroni sau prea puini absolveni de specialitate fa de nevoile n cretere. S-au ncercat diverse soluii, susinute de firme reconversia profesional a unor posibili angajai care s uite vechea pregtire profesional (mult mai slab pl tit ) i s nvee s programeze; aducerea de profesioniti buni din alte localiti sau deschiderea de filiale prin ar (de obicei unde exist universiti); chiar includerea elevilor n programe care vizau atragerea lor ca angajai. i totui, problema rmne o lupt dur pentru mprirea resursei umane. Iar pentru aceasta firmele au fcut o serie de aciuni legate de vizibilitate sau climat de lucru. Noi am fost interesai, de data aceasta, s vedem ce preri au tocmai aceia pentru care se duce lupta: viitorii angajai. Ce imagine au ei despre firmele posibil angajatoare? Ce tiu despre acestea (este vorba despe percepia 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 competene n domeniul sociologiei i a managementului. Pentru construirea chestionarului s-a inut seama i de opiniile unor angajai din firme IT (mai nou angajai sau cu mai mult experien ), oameni de HR, respectiv patroni din firme IT. Prima decizie a fost legat de participanii la studiu. S-a convenit ca acetia s fie dintre studenii la Calculatoare sau Automatiz ri (UTCN), respectiv Informatic (UBB), indiferent de predarea n limba romn 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 pregtire al studenilor. Am considerat c cei din anul I sunt nc destul de puin cunosc tori privind firmele din Cluj, iar cei din anii superiori, foarte muli, deja lucreaz i prerea lor poate fi influenat de prezentul loc de munc. Aa c am ales sudenii din anul II (deja n semestrul doi). A urmat alegerea firmelor care s fie studiate. Am folosit dou criterii care s creasc ansa cunoaterii lor de ctre studeni: mrimea firmei (numr de angajai) i vechimea acesteia n Cluj. n final, 10 firme au fost selectate: 1. AROBS 2. EBS 3. ENDAVA 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 discuii cu persoane din firme de IT. I-am rugat pe respondeni s aleag maxim trei descriptori, dintre cei 13 posibili, din dorina de a vedea rezultate polarizate principalele caracteristici ale firmelor, vzute de studeni. Aceti descriptori au fost: 1. Ofer mult instruire 2. Secretoi 3. Mediu foarte plcut 4. Interesai doar de bani 5. Stabili pe pia 6. Pretenioi 7. Proiecte complexe 8. Au angajai valoroi 9. Foarte flexibili 10. Pltesc bine 11. Au produse proprii 12. Fac mult outsourcing 13. Arogani n final am realizat un chestionar cu dou pri principale. n prima parte, respondenii 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 amintii. Au mai fost ad ugate cteva ntreb ri informative: facultatea la care sunt studenii, genul respondentului, adresa de e-mail pentru
Metodologie.
46

o imagine mai clar despre cum se poziioneaz firma, n percepia subiectiv a studenilor, fa de concuren. Rezultatele sintetice sunt prezentate n tabelul urmtor (am avut grij ca ordinea firmelor n tabel s nu fie alfabetic, deci e imposibil de ghicit scorul fiecrei firme; pentru firmele interesate avem mai multe detalii, fr s deconspirm identitatea fiecreia). Am marcat scorurile maxime pentru a se vedea mai bine diferenele. n multe cazuri, raportul percepiilor depete raportul 2:1; n cazul percepiei despre Arogan raportul depete 8,5:1, chiar dac notele totale sunt relativ mici. Studenii percep aproximativ la fel firmele ca fcnd outsourcing (3,9-5,6%). O firm iese n eviden, fiind perceput de ctre respondeni ca avnd produse proprii (12,9% fa de cel mai mic scor de 4,1%). Polarizri interesante apar i la percepia despre cea mai sensibil caracteristic: Plata! Raportul percepiei, n cazul extrem, este de peste 2,25:1. Astfel, pentru angajare, un student ar merge nti la firma G, nu la firma D, cu o probabilitate de 225%. Sigur c sunt muli factori care i pot determina pe studeni s prefere un angajator n defavoarea altuia. Acestea sunt percepiile exprimate de ctre acetia i, credem, pot s fie food for thinking pentru firmele intrate n studiu, dar nu numai pentru acestea.
trimiterea informaiilor finale. Cum s-a ntmplat! n perioada 26 februarie 3 martie 2014 au rspuns la chestionar 400 de studeni de la facultile vizate, ceea ce ne face s considerm opiniile relevante statistic. Pe aceast cale, dorim s le mulumim studenilor i profesorilor care ne-au facilitat obinerea rspunsurilor. Fiecare firm inclus n studiu a primit un raport cu detalii despre percepia studenilor privind respectiva firm, ceea ce le permite s vad cum se raporteaz fiecare la concuren. n prezentul articol nu vom corela rspunsurile primite cu numele unor firme, pentru pstrarea confidenialitii, dar sperm c, analiznd comparativ datele, fiecare firm va reui s-i mbunteasc 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 candidai pentru recrutare, este important ca acetia s le cunoasc. De aceea, prima ntrebare a fost dac respondenii cunosc (ct de ct) firmele de IT. Rspunsurile lor au fost distribuite pe o plaj destul de larg, de la 25,3% pn la 80,2%. Fiindc, practic, toate aceste firme de IT au planuri de a-i crea o notorietate ct mai mare i innd cont c majoritatea sunt firme vechi i/sau mari, scoruri de 25-30% sunt, dup prerea noastr, destul de mici. Probabil c strategia de imagine, marketing, sau PR ar trebui revzut. Rezultatele privind descriptorii, aa cum au fost alei de ctre studeni, relev diferene de percepie. Media sau mediana rezultatelor nu credem c este foarte relevant. Este interesant de vzut scorurile comparative dintre firme aceasta d
Dan Ionescu dan.ionescu@danis.ro Executive director @ Danis Consulting
47
management
Managementul performanei n organizaiile orientate spre proiecte din Romnia

ei nu este un concept nou, managementul performanei a atras n ultimii ani o atenie sporit din partea organizaiilor datorit transferrii aplicabilitii acestuia la nivelul ntregii organizaii. Dac pn nu demult acesta era legat de Resursele Umane, evalund msura n care angajaii i ndeplineau obiectivele impuse de organizaie, astzi managementul performanei este o funcie integrat ce vizeaz alinierea tuturor componentelor (indivizi, departamente, procese) la obiectivele organizaiei. Din perspectiva disciplinei managementu lui st rateg ic, pro cesu l de management al performanei are la baz premisa conform creia angajaii pot implementa cu adevrat o strategie numai atunci cnd o neleg pe deplin i descoper modul n care ei pot contribui la obinerea rezultatului scontat (Cokins, 2004, p. 23). Managementul performanei este vzut ca un proces iterativ, care cuprinde att o parte de planificare, ct i una de execuie (Cokins, 2004, p. 25). Astfel, managementul stabilete obiectivele pe care le transmite mai departe angajailor, de la care, la rndul su, primete n mod constant informaii de natur financiar sau operaional asupra stadiului de performan n realizarea obiectivelor, informaii pe baza crora va ntreprinde aciunile corective necesare meninerii organizaiei pe traseul stabilit. Motorul unei organizaii este reprezentat de angajaii si, de aceea un factor decisiv n managementul perfomanei la nivel strategic l reprezint gestionarea performanei angajailor i a structurilor pe care acetia le alctuiesc (departamente, echipe). Din acest motiv, este lesne de neles, de ce, pentru o lung perioad de timp, managementul performanei a stat sub apanajul disciplinei Resurselor Umane. Departamentul de Resurse Umane este cel responsabil de evaluarea performanei angajailor, dar i s se asigure c aceast performan contribuie la realizarea performanei organizaiei ca ntreg, iar angajaii sunt recompensai corespunztor pentru aceast contribuie. Cercetarea de fa s-a realizat n anul 2013 i s-a axat pe analiza modului n care, n organizaiile orientate spre proiecte, personalul implicat n proiecte este evaluat i recompensat pentru activitatea din cadrul proiectelor. Aceste organizaii sunt definite ca organizaii care i desfoar activitatea n principal prin intermediul proiectelor sau n care acestea au o pondere relativ mare pe lng activitile recurente (operaionale). (Turner i Keegan, 2000, p. 8) Provocarea a luat natere din particularitatea organizaiilor cu structur matriceal, n care angajaii care lucreaz n proiecte sunt subordonai att managerului de proiect, ct i managerului de departament. Astfel, s-a urmrit identificarea msurii n care aceast dubl subordonare influeneaz procesul de management al performanei n organizaiile romneti cu acest tip de structur: cine este persoana abilitat s fac evaluarea performanei i s aduc modificri salariale (managerul de departament sau managerul de proiect), ce indicatori sunt msurai la evaluarea membrilor echipei i a managerului de proiect, precum i ce tipuri de recompense sunt (dac sunt) oferite pentru performana din cadrul proiectelor. n urma analizei literaturii de specialitate au fost extrase urmtoarele concluzii: n organizaiile orientate spre proiecte, managementul performanei urmrete alinierea obiectivelor indivizilor, departamentelor i proiectelor la obiectivele organizaionale . n organizaiile orientate spre proiecte cu structur matriceal, evaluarea performanei personalului trebuie s in cont att de activitatea din cadrul departamentului, ct i de cea din cadrul proiectului. La evaluarea personalului implicat n proiecte, managerul de departament colaboreaz cu managerul de proiect. Evaluarea performanei din cadrul proiectului este strns legat de succesul acelui proiect. Pornind de la cele de mai sus, au fost stabilite trei ipoteze de cercetare care au fost msurate prin aplicarea unui chestionar. Eantionul cercetrii ntreprinse a fost alctuit din angajai implicai, 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 respondeni, deoarece, n cazul a 10 dintre companii, nu se realiza nicio form de evaluare a angajailor. Ipotezele cercetrii au fost urmtoarele: I1 - n companiile n care se realizeaz evaluarea performanei angajailor, la evaluarea performanei se ia n considerare doar activitatea lor din cadrul departamentelor, nu i cea din cadrul proiectelor. I2 -Recompensele oferite anagajailor in cont doar de activitatea desfurat n departamente, nu i n proiecte. I3 - n companiile n care se ia n considerare activitatea din proiect la evaluarea performanei, evaluarea este realizat exclusiv de ctre managerul de department. n Tabelul 1 sunt centralizate rezultatele obinute la ntrebrile care au msurat gradul n care la evaluare este luat n considerare performana din proiecte. Conform tabelului de mai sus, n cazul companiilor n care activeaz cei 32 de respondeni, managerul de departament colaboreaz n mare msur (scor 3,97) cu subalternii n stabilirea obiectivelor de performan, iar evaluarea se face conform acestor obiective (scor 4,00). Interesant, din perspectiva acestei cercetri, este scorul obinut la cea de-a treia variabil (4,41). Aceasta indic faptul c activitatea din cadrul proiectelor este luat n considerare n mare msur la evaluarea performanei i, dei ne-am ateptat s existe o corelaie ntre aceast variabil i numrul de
48

Kerzner, 2010) pentru evaluarea managerilor de proiect i a membrilor din echipa de proiect. La indicatorii primari de performan pentru managerii de proiect s-au validat 27 de rspunsuri, dat fiind faptul c cinci dintre cei 32 respondeni nu au lucrat ca manageri de proiect n niciunul din proiectele companiei. Media total obinut la aceti indicatori a fost 3,65. Conform graficului de mai sus, factorii care sunt n mare msur luai n considerare la evaluarea performanei managerilor de proiect sunt cei direct legai de calitate calitatea rezultatului proiectului i realizrile tehnice ale proiectului precum i de constrngerile de timp i cost, msurate mpreun n cadrul indicatorului planificarea bugetului i graficului de execuie i, separat, prin indicatorii respectarea costurilor int ale proiectului i respectarea jaloanelor proiectului. Aceti cinci indicatori au obinut cele mai mari scoruri. Surpinztor este, ns, scorul obinut la indicatorul stabilirea obiectivelor proiectului conform cerinelor proiectului, care denot c acestui aspect i este acordat o atenie relativ sczut n comparaie cu indicatorii anteriori care trimit la tripla constrngere. Pe de alt parte, un interes relativ ridicat se acord profitului obinut prin implementarea proiectului (3,78) i stabilirii regulilor jocului din cadrul proiectului (3,70). Indicatorul de performan cruia i se acord cea mai puin importan (2,85) comparativ cu ceilali este cel care vizeaz stabilirea mecanismelor de control pentru performana proiectului. Acest rezultat poate fi un indiciu asupra nivelului (relativ redus) al maturitii companiilor analizate n managementul performanei n cadrul proiectelor. Ca i n cazul managerilor de proiect, indicatorii crora li se acord cea mai mare importan la evaluarea performanei membrilor echipei de proiect sunt cei legai de constrngerile de timp, cost i calitate: calitatea rezultatului, respectarea jaloanelor principale, costuri int, proiectarea tehnic cu plafon de cost. n companiile analizate se ateapt de la un membru ca n echipa de proiect acesta nu doar s se ncadreze n cele trei constrngeri, ci s o fac inovnd (3,94) i fiind orientat spre schimbare (3,97). Aceste scoruri, coroborate cu cele relativ sczute n cazul indicatorilor implementarea tehnic conform
Tabelul 1 - Medie rspunsuri pentru variabilele care msoar gradul de evaluare a performanei din proiecte
proiecte desfurate de companie ntr-un an, rezultatele analizei au infirmat acest fapt. Numrul de proiecte din companie nu determin msura n care activitatea din acele proiecte este luat n considerare la evaluare. Pe de alt parte, evaluarea performanei din cadrul proiectelor nu este urmat n aceeai msur de recompensarea acesteia (n 16 din cele 32 companii evaluarea ine cont n foarte mare msur de activitatea din proiect, ns n numai 5 dintre acestea este i recompensat). n ceea ce privete natura recompenselor, ponderea cea mai mare (16 din 32 rspunsuri) au nregistrat-o recompensele de tip recunoatere, urmate de cele financiare (8 din 32) i apoi, n egal msur, de beneficii materiale i alt form de recompens (combinaie de recompens financiar i recunoatere n faa colegilor sau cursuri pltite de companie). Rezultatele obinute la cele dou ntrebri privind gradul de recompensare a
activitii din proiecte i natura recompenselor ne permit urmtoarea concluzie: dei 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 recunoatere sugereaz interesul relativ sczut pentru aceste recompense. Cu toate acestea, putem conchide c ipoteza I2 a fost infirmat. Un alt aspect interesant este faptul c, dei succesul unui proiect nu este n majoritatea cazurilor clar definit (3,25), acesta este n mare msur (4,06) luat n considerare n momentul evalurii performanei 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 obinute pentru fiecare dintre indicatorii primari de performan (conform Harold
Figura 1 - Medie rspunsuri privind indicatorii de performan luai n considerare la evaluarea managerilor de proiect
49
management
Managementul performanei n organizaiile orientate spre proiecte din Romnia
orientate spre proiecte cu structur matriceal din Romnia. n plus, cele 32 de companii au fost repartizate inegal pe sectoare de activitate, ceea ce nu a permis realizarea unor corelaii pertinente.
Bibliograe
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 planificrii, programrii i controlul activitii de proiect. Bucureti, 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 rspunsuri privind indicatorii de performan luai n considerare la evaluarea membrilor echipei de proiect
cerinelor i compromisuri ntre cerine, denot faptul c exist o flexibilitate destul de mare n definirea ariei de cuprindere a proiectelor, iar acestei constrngeri 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 explicaie pentru rezultatul privind definirea clar a succesului proiectului. Astfel, este dificil de identificat succesul unui proiect atunci cnd nu se cunoate cu exactitate ce se face n acel proiect. Conform rezultatelor cercetrii ntreprinse, toate cele trei ipoteze au fost infirmate. n cazul primei ipoteze, media celor 32 de rspunsuri a evideniat faptul c, n companiile respective, evaluarea performanei ine cont n mare msur 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 privete recompensarea, dei scorul obinut (3,72) relev o importan relativ ridicat acordat acestui aspect, natura recompenselor (preponderent de tip recunoatere) 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 evalurii personalului implicat n proiect, contrar ateptrilor iniiale, ntr-o pondere foarte mare (20 din cele 32 companii ) a reieit ca evaluarea se realizeaz cu ajutorul managerului de proiect.
Aceste rezultate deschid calea ctre cercetri mai extinse n domeniu, ns, pentru moment, pornind de la ele, pot fi extrase cteva recomandri: Dac n cazul activitii din departament obiectivele de performan ale angajailor sunt stabilite n mare msur prin colaborarea managerului de departament cu angajatul din subordine, n cazul activitii din proiecte situaia nu mai este la fel de clar. Din cercetare a reieit faptul c, dei 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, cteva criterii generale de performan pentru toate proiectele, urmnd ca la acestea s fie adugate alte criterii specifice n funcie de fiecare proiect. Dat fiind diferena de durat ntre activitile recurente care se desfoar 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 soluie viabil pentru recompensarea ntregii activiti din organizaie a personalului implicat n proiecte. Limitarea major a cercetrii de fa const n dimensiunea redus a eantionului, ceea ce nu permite generalizarea concluziilor pentru toate oranizaiile
Adina Grigoroiu, CAPM adina.grigoroiu@confucius.ro Trainer i consultant @Colors in Projects
50
prezentare
umy.ro este prima platform de usability testing din Romnia, lansat de compania REEA. Pentru prima dat n ara noastr, companiile, dar i persoanele fizice, au posibilitatea s afle prerea utilizatorilor pe care i targeteaz prin produsele lor web i mobile. n urma testelor, platforma va da informaii exacte n legatur cu website-ul sau aplicaia 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, relevana coninutului, eficien a designului i u urin a cu care clienii/utilizatorii pot realiza anumite procese critice n cadrul website-ului i/sau aplicaiei. n cadrul platformei, exist dou tipologii de testeri: tester nceptor i tester avansat. Singura diferen ntre aceste dou tipologii de conturi este accesibilitatea la diferite tipuri de teste. n funcie de dificultatea acestora, pentru fiecare test realizat, utilizatorului i se va aloca n cont un numr de puncte lumy. Exist cinci tipuri de teste de utilitate: heatmap, clickmap, preferine, feedback i video feedback. Preurile sunt accesibile i se ajusteaz n funcie de bugetul disponibil. Cu suma de 50 de lei, o companie va obine 17 teste video, din care va reiei un feedback real. Numrul testerilor nscrii n platform a ajuns la aproape 520 i este ntr-o continu cretere. Daniela Ferenczi, UX specialist n cadrul companiei REEA, este iniiatorul Lumy. Construcia a tot ceea ce nseamn Lumy a nceput n luna iunie 2013, la Trgu-Mure. Denumirea provine de la cuvntul lumin. Ideea acestui nume a pornit de la faptul c, atunci cnd realizezi un proiect l creezi n propriul tu birou, bazndu-te pe propriile cunotine i pe know-how-ul echipei cu care lucrezi. La finalizarea proiectului, munca i creativitatea ta pe partea de usability se lanseaz n ntuneric, fr usability testing. Practic, nu tii dac utilizatorii ti au primit un produs sau serviciu ce poate fi folosit uor, are logic pentru ei i le ofer o experien, nu doar o ntrebuinare. LUMY are rolul de a te lumina n ceea ce privete 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 ctre testeri prin intermediul aplicaiei Lumy Recorder; versiunea pentru companii; integrarea testelor de tip preferine, clickmap, heatmap; comenzi teste pe partea destinat companiilor; valorificarea ctigurilor testerilor; versiunea platformei n limba englez; upgrade pe partea de companii strine; implementare API pentru aplica ia iOS. Aceste etape au fost implementate n cadrul echipei .NET. n paralel, echipa iOS a implementat aplicaia 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. Ffmpeg mapat cu Windows Core Audio pentru detecia i selectarea microfonului. Comunicarea ntre browser i aplicaie se face prin intermediul unui server local http. Comunicarea cu server-ul este fcut prin TCP. Pe parte de server pentru stocarea stream-ului de date, se folosete NodeJs, care pornete instane de ffmpeg. Cele mai dificile task-uri au fost gsirea unui mod eficient de captur a ecranului i comprimarea ct mai bun a fluxului de date audio i video. O alt situaie solicitant a fost maparea microfonului reprezentat n felul ffmpeg cu cele existente deja n sistem. Prin intermediul acestei aplicaii, testerii nscrii n cadrul platformei vor putea realiza teste de tip feedback i video, iar companiile vor primi o reacie real pentru versiunile mobile ale website -urilor realizate. Aplicaia Lumy Recorder pentru iPhone a fost realizat utiliznd 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 reui publicarea n Apple Store. Cea mai complicat parte din dezvoltarea aplicaiei a fost realizarea capturii video. SDK-ul nativ nu permite captur video de pe browser, astfel c dezvoltatorii au fost nevoii s gseasc o alt metod, folosind OpenGL. Accesnd link-ul http://www.youtube. com/watch?v=CeqXjD99z1o&feature= youtu.be , putei vedea un exemplu de test video, realizat pe un iPhone 5S. Platforma de usability testing Lumy a fost dezvoltat integral, de la concept pn la implementare, de REEA.
Lumy.ro - usability testing
Lumy Recorder pentru iOS
Lumy Recorder este o aplicaie desktop stand-alone, care se ocup cu nregistrarea unor sesiuni de testare, n cadrul crora se capteaz rspunsul n format text al utilizatorului, al vocii acestuia i al aciunilor petrecute pe ecranul acestuia. Datele capturate se transmit instantaneu ctre un server, care le stocheaz ntr-o baz de date centralizat. Tehnologiile folosite sunt Implementarea urmtoarele: Prima etap, a fost evident analiza proi pentru captura ecranului: filtru de ectului, ceea ce se dorete n faza iniial i captur ecran mpreun cu Ffmpeg. unde vrem s ajungem. Au fost multe ore pentru captura audio: se folose te
Ce este Lumy Recorder?
Daniela Ferenczi daniela.ferenczi@reea.net UX designer REEA, iniiator Lumy @ REEA
51
management
Optimizarea de ce ar merita efortul?
n urm cu cinci ani m aflam n faa acestei ntrebri, n momentul n care am acceptat mandatul de a implementa un program de optimizri ntr-o organizaie de servicii IT cu peste 150 angajai. La vremea respectiv am estimat-o ca fiind o sarcin relativ simpl, de cteva luni, care se termin n momentul n care ne definim procesele i obinem certificarea CMMI. Ce gndire simplist i naiv! Mi-ar plcea s fi avut gndirea de azi la acea vreme Totui este util s mprtesc din aceste experiene uneori nu tocmai plcute n sperana c ele vor fi de ajutor pentru alii. Ceea ce s-a ntmplat n aceti cinci ani nu a fost doar o structurare, o implementare a unor procese, ci o schimbare complet de gndire privind calitatea si optimizarea modului de lucru, cu ajutorul mentorilor extraordinari cu care am avut plcerea de a lucra. n realitate aceast sarcin asumat s-a transformat n cinci ani de eforturi serioase, determinare puternic de a nu renuna, care la final a schimbat gndirea i modul de lucru al ntregii organizaii. Astfel de programe nu sunt de neglijat. Ele sunt dificile, intruzive, imprevizibile i deseori sunt privite ca devieri fr 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 att programatori ct i manageri, n companii mici i mari punnd aceast ntrebare: merit efortul?. Desigur cu alte cuvinte i alte nuane, dar cu aceeai esen, prin variaii precum: Lucrurile au funcionat i pn acum, de ce le-am schimba? Nu ne dorim ISO sau CMMI, de ce ne-am complica? Suntem o firm mic, nu ne dorim gndire corporatist, nu avem nevoie de asta. Nu avem timp anul acesta, poate altdat. Implic costuri ridicate, mai degrab angajm doi programatori. Am lucrat deja la procese i lucrurile nu s-au schimbat. Alii au iniiat astfel de programe i au euat. Noi am mai iniiat astfel de programe i am euat. i lista poate continua. Uneori rspunsul vine din partea clienilor (sau potenialilor clieni) care doresc o colaborare doar cu parteneri care pot dovedi o anumit maturitate organizaional. Acest lucru poate genera una din cele dou reacii: fie (1) cutarea unor ci de ocolire, scurtturi pentru obinerea unei certificri, fie (2) efectuarea unei investiii 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 clieni (sau poteniali clieni) interesai de acea maturitate organizaional sunt rareori interesai de tampila sau de certificatul afiat la recepie. Ei sunt interesai de faptul c acele cazuri de succes afiate 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 gsi un competitor care ofer aceleai servicii fie la un pre mai redus, fie ntr-un timp mai scurt sau chiar ambele. Prin urmare, ansa de a rmne competitivi pe o pia de servicii IT supra-aglomerat i volatil, unde competiia devine global, se regsete n calitatea demonstrat i continuu optimizat. Dar calitatea nseamn mai mult dect un slogan. n primul rnd, aceasta trebuie DEFINIT, apoi trebuie MSURAT i DEMONSTRAT, iar n timp trebuie vizibil OPTIMIZAT. Din pcate acesta nu se poate obine prin edinte. Modul n care se poate obine sunt programele de optimizare care necesit angajament i investiii. Termenul de Quality Assurance are n fond o semnificaie mult mai larg dect cea cu care ne-am obinuit deja, dincolo de testare i dincolo de controlul calitii. Existena unui sistem de QA funcional poate reprezenta o diferen semnificativ i un avantaj competitiv major pentru o organizaie. Exist o percepie greit asupra ceea ce reprezint QA: n marea majoritate a cazurilor prin QA se neleg activitile 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 testnd rezultatele produse cu un decalaj de o iteraie complet. n realitate,activitile de testare sunt parte a QC (Quality Control)
52

din ciclul de dezvoltare, verificnd reactiv produsele/serviciile care s-au dezvoltat. n contrast, QA are o importan net superioar: asigurarea calitii produselor/serviciilor ce urmeaz a fi dezvoltate. Diferena dintre cele dou concepte este major. De exemplu, QA include activiti precum revizuirea artefactelor, activitate capabil s detecteze de 8-10 ori mai multe defecte dect testarea n aceeai unitate de timp. QA faciliteaz reutilizarea experienei, metricilor i cunotinelor avnd ca una din urmri, creterea preciziei estimrilor. QA creeaz condiiile ca fiecare persoan din echip s-i neleag rolul n echip i ateptrile fa de acel rol, avnd la dispoziie practicile care s o faciliteze n efactuarea sarcinilor. QA verific eficiena colectrii i analizei metricilor, a raportrii eficiente, ceea ce asigur planificri mai precise. i lista poate continua Orice efort, timp sau buget alocat unui program de optimizri trebuie privit ca o investiie i nu un cost. O investiie care generaz beneficii semnificative, superioare investiiei. Cele mai multe metode de ocolire a investiiilor nu vor asigura succesul programului de optimizri, ci vor asigura opusul acestuia: schimbarea investiiei ntr-o risip irecuperabil de resurse. Astfel de metode includ: Doar execuie fr training, fr suport, fr o viziune sau un plan. Achiziia unui tool care s rezolve problemele. Achiziia proceselor altora. Elaborarea proceselor de ctre o singur persoan (preferabil ntr-o sptmn). Inventarea proceselor noi. Cumularea de multiple roluri pentru o singur persoan de la definiie, msurare, implementare i evaluare. Totui, cu o abordare corect, sntoas, sunt posibile optimizri semnificative prin aplicarea unor principii simple: Avnd ca punct de pornire actualul mod de lucru (optimizri, nu invenii). Documentarea practicilor existente, identificarea zonelor problem. Concentrare pe aspectele importante ale organizaiei. Colectarea msurtorilor relevante, publicarea lor n organizaie. Implicarea personalului n definirea nevoilor. Apelarea la asistena profesional, training i mentoring adecvat. Aadar, revenind la ntrebarea original: de ce ar merita efortul? 1. Deoarece faciliteaz supravieuirea speciei de companie de servicii IT din Europa Central i de Est, n special sub-speciei caracterizate prin servicii outsourcing. Industria de servicii ITi n special cel de outsourcing, este extrem de expus competiiei globale n timp ce comunitatea de freelancer-i ofer o alternativ accesibil clienilor. De aceea, companiile trebuie s poat demonstra evoluie, optimizri continue n timp pentru a nu fi eclipsate de competiie. 2. Deoarece promoveaz cel mai puternic avantaj competitiv: calitatea. Competiia poate oferi servicii mai accesibile i cu termene mai scurte, ns mult mai dificil poate demonstra calitatea superioar. Putem oare gsi 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 definiie dac ea exist mcar se reduce la msurarea termenelor i a costurilor pentru a demonstra calitatea oferit. De aici ntrebarea natural ar fi: aceasta nseamn c ieftin i rapid este definiia calitii? n realitate, definirea calitii este o sarcin dificil: puine companii reuesc s defineasc, s poat msura i optimiza calitatea, iar aceste detalii pot oferi un avantaj competitiv extrem de important. 3. Deoarece reduce costurile coreciilor reactive cum ar fi testarea, activitile de fixing sau refactoring. Implementarea unui sistem de QA n organizaie promoveaz mesajul calitatea nu e problema altora i asigur c oricine poate contribui la calitate, nu rmne exclusiv n responsabilitatea echipei de testare. Asigur mprtirea cunotinelor, 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 calitii ncepnd din primele faze ale proiectelor, unde investiia n training i n planificare poate garanta beneficiile pe parcursul proiectelor. 4. Deoarece faciliteaz nvarea continu. Deseori se nva din greeli. Orice persoan, echip sau organizaie produce greeli i este normal ca acestea mpreun cu concluziile aferente s fie analizate periodic n vederea evoluiei. ns aceasta nu nseamn c pentru evoluie trebuie comise greeli! Deseori ele nu sunt permise. De ce nu s-ar pune obiectivul realizrii 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 activiti corective. n realitate, timpul alocat acestor activiti la nceputul unui proiect se recupereaz triplat n fazele ulterioare prin efort mult mai redus n activiti de testare sau corective. Exist o varietate larg de practici aplicabile, cum ar fi refolosirea cunotinelor, experienelor, a practicilor de succes dovedite sau a statisticelor. 5. Deoarece este practic i aplicabil, pretabil organizaiilor mici sau mari. A fi o mic firm de start-up sau, din contr, o corporaie nu mai reprezint o scuz valid pentru a nu investi n optimizri. a. Companiile mici au nevoie de creterea cifrei de afaceri, de contracte mai valoroase, de clieni mai mari. Aceti clieni pot fi exigeni, pot avea criterii bine definite pentru parteneri. Ar putea fi interesai de modelul SDLC, care nu ar reprezenta o problem. ns ar putea cere detalii i explicaii pentru modul i raionamentul din spatele modelului, ceea ce necesit o bun pregtire. De multe ori modelul SDLC se descrie prin activitile de design + dezvoltare + testare. Dar activitile de planificare? Cele de monitorizare i control? Cele de configuration management sau change management? Poate risk management? Neavnd definite aceste activiti, modelul nu poate fi considerat complet. Planificarea fr monitorizare este o risip de efort i timp. Monitorizarea fr o planificare adecvat este nonsens. Iar aceste detalii pot amenina un contract promitor n primele faze. b. Marile corporaii pot genera pierderi semnificative dac nu sunt optimizate. Un efect al absenei optimizrii este situaia schizofrenic n care exist muni ntregi de cunotine n cadrul organizaiei fr ca ele s poat fi valorificate. Fr a avea o coordonare i viziune clar asupra rolului departamentelor sau activitilor, strategiile i planurile i pierd claritatea, rezultnd n confuzie i ineficien n cadrul
53
management
Optimizarea de ce ar merita efortul?
echipelor, ceea ce se traduce n ntrzieri, timpi de ateptare i rework. Aplicat la echipe sau departamente de sute de persoane, pierderile pot fi surprinztoare. 6. Deoarece conduc la rezultate tangibile, msurabile, concrete. Iat cteva exemple publicate de Software Engineering Institute: a. Reducerea anual a TTM ctiguri ntre 15% i 23%, b. C reterea anual a ratei de detectare a defectelor ctiguri ntre 6% si 25%, c. Reducerea anual a erorilor raportate ctiguri ntre 11% si 94%, d. ROI global ctiguri ntre 400% i 880%. 7. Deoarece serviciile i produsele se adreseaz unor clieni din ce n ce mai exigeni, pentru care afiarea succeselor din trecut nu mai este suficient. Trebuie demonstrate cauzele care le-au fcut s fie succese, factorii care au asigurat diferena dintre succes i eec. Trebuie demonstrat modul de lucru n care ele s-au realizat. i cel mai important, vor trebui convini c repetarea modului de lucru va asigura repetarea succesului iar pentru aceasta avem nevoie de procese repetabile. Acestea sunt doar cteva motive pentru care optimizare modului de lucru merit efortul. Dei un program de optimizri complet, cu buget ridicat nu este accesibil ntotdeauna,acest fapt nu ar trebui s reprezinte un impediment dac exist determinare. Exist pai mruni care se pot aplica n prima faz a optimizrilor: Pornirea de la practicile existente n companie. Documentarea SDLC existent, identificarea lacunelor. Definirea obiectivelor. Plan de aciuni pentru atingerea lor. Organizarea unor training-uri specifice pentru dobndirea competenelor 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 rnd asupra personal, deoarece este factorul principal n realizarea serviciilor i produselor de calitate, pe cnd un model sau un set de procese are doar rolul de a facilita personalul. Consultan profesional, pentru a face eforturile ct mai practice i a maximiza beneficiile cu aceleai investiii. Abordarea n orice activitate, n orice circumstane, a ciclului Sheward-Deming: Plan-Do-Check-Act. Organizarea de retrospective, colectarea i analizarea experienelor i a metricilor Revizuirea artefactelor, frecvent, aplicat pe toate tipurile de artifacte (specificaii, planuri, design tehnic, cod, test case, etc.) .
Cu un angajament puternic, un astfel de program poate deveni mai simplu dect ar prea la prima vedere. n mod categoric efortul investit nu devine pierdere, beneficiile pot fi uimitoare. Sperm c n viitorul apropiat muli dintre cititorii acestui articol se vor pronuna n mod asemntor. La final, rmne ntrebarea: de ce nu ar merita efortul s ne optimizm afacerea?
Tibor Laszlo tibor.laszlo@improving-it.com Partner & Consultant @Improving-IT
54
programare
AOP folosind Unity
instrumentele din .NET 4.5, cum sunt RealProxy i Attribute. RealProxy este ingredientul special n cazul nostru, dndu-ne ntr-o prim parte , v prezentm o definiie a acronimului posibilitatea de a intercepta toate cererile adresate unei metode AOP i cum o putem utiliza n .NET 4.5 fr alte cadre. sau proprieti. Aspect Oriented Programming (Programarea Orientat pe Aspecte) este o paradigm de programare avnd ca scop principal Unity creterea modularitii unei aplicaii. AOP ncearc s ating acest Acesta este un cadru binecunoscut de ctre dezvoltatorii .NET scop prin permiterea separrii 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 aplicaiei ASP.NET mod normal, dac utilizm OOP pentru a dezvolta o aplicaie 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 proapelri 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 aa mai departe. Cnd dependene, Unity este un cadru matur care are toate funciile pe utilizm AOP, implementarea sistemului de logging sau audit va care un dezvoltator se ateapt s le gseasc la un astfel de cadru. trebui s se afle ntr-un modul separat. Mai mult dect att, vom Caracteristici precum configurare XML, nregistrare, rezolver avea nevoie de o cale de a scrie informaia de logging fr a scrie implicit sau special, injectare de proprieti, container-e personacod n alte module care vor face apelarea n sine a sistemului de lizate, sunt n ntregime susinute de Unity. logging, folosind interceptarea. n urmtorul exemplu, vom vedea cum putem nregistra Aceast funcionalitate poate fi implementat utiliznd interfaa IFoo n containerul de injectare dependene i cum
n ultimul numr al revistei Today Software Magazine, am discutat despre principiile de baz ale AOP i despre cum putem implementa conceptul de baz al AOP utiliznd caracteristici ale .NET 4.5, fr a folosi alte cadre. n acest articol, vom vorbi despre Unity i vom vedea cum putem utiliza acest cadru pentru a implementa AOP.
Recapitulare
55
programare
AOP folosind Unity
putem obine o referin la aceast exemplificare.
IUnityContainer myContainer = new UnityContainer(); myContainer.RegisterType<IFoo, Foo>(); //or myContainer. RegisterInstance<IFoo>( new Foo());
IFoo myFoo = myContainer.Resolve<Foo>();
Cnd 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 operaie pe care trebuie s o fac este s nregistreze aceste resurse i s le solicite n controller, ca n urmtorul exemplu:
public class HomeController : Con troller { Foo _foo; public HomeController(Foo foo) { _foo = foo; } public ActionResult Index() { ViewData[Message] = Hello World!; } return View();
Interceptor va intercepta apelul, va declana comportamentul la comand i va face apelul real ctre obiectul int. Toate aceste apeluri sunt interceptate prin folosirea unui substitut care trebuie s fie configurat de ctre 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 lng interceptor. Comportamentul care este injectat utiliznd Unity poate schimba valoarea parametrului de intrare sau valoarea returnat.
Cum s congurezi interceptarea?
public ActionResult About() { return View(); }
Dup cum putem observa n exemplul de mai sus, Unity va putea rezolva toate dependenele n mod automat.
Unity i AOP
nainte de a analiza acest subiect mai n amnunt, este necesar s abordm a atitudine obiectiv. Unity nu este un cadru AOP i, de aceea, nu vom avea toate caracteristicile care formeaz AOP. Unity susine AOP la nivel de interceptare. Aceasta nseamn c avem posibilitatea de a intercepta apelurile ctre 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 fcut 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 funcionalitate utiliznd un mecanism similar cu cel care este obinut prin Decorated Pattern. Singura diferen este c n cazul Unity, container-ul este cel care decoreaz apelul cu un comportament atribut fcut la comand. La sfritul articolului vom vedea ct de uor este s adaugi un mecanism de urmrire utiliznd Unity sau s faci toate apelurile ctre baza de date s execute, folosind tranzacii. 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 pri ale aplicaiei noastre. Singura cerin de la Unity este s aib acces la aceste obiecte ntr-un fel sau altul.
Exist dou moduri de a configura interceptarea de la cod sau utiliznd fiiere de configurare. n ambele cazuri, este nevoie s definim comportamentul special care va fi injectat n containerele Unity. Personal, eu prefer s folosesc codul, utiliznd fluentul API care este disponibil. Recomand utilizarea fiierelor de configurare numai atunci cnd suntei siguri c va trebui s schimbai configurarea n timpul execuiei sau fr a recompila codul. Chiar dac facem aceast recomandare, noi am utilizat frecvent configurarea din fiiere pentru c aceasta este mai flexibil. Atunci cnd folosii fiiere de configurare, v asumai riscul de a introduce mai uor probleme de configurare scrierea greit a numelui claselor sau redenumirea unui tip i omiterea de a actualiza i fiierele de configurare. Primul pas este acela de a defini comportamentul pe care dorim s l executm atunci cnd realizm interceptarea apelului. Acest lucru se face numai prin cod, implementnd InterceptionBehavior. Cea mai important metod a acestei interfee este Invoke (Invocarea), care este declanat cnd cineva apeleaz metodele care sunt interceptate. De la aceast metod este nevoie s facem apelul propriu-zis ctre metoda real. nainte i dup apel, putem injecta orice tip de comportament. Dei era previzibil existena a dou metode, una care este apelat nainte de apelul propriu-zis i una dup apel, aceast funcie nu o deine Unity. O alt component important a acestei interfee este proprietatea WillExecute. Stabilirea drept TRUE (adevrat) a proprietii, condiioneaz interceptarea apelului. Utiliznd aceast interfa, avem posibilitatea de a controla apelurile ctre orice metode de la obiectele aplicaiei 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;
Cum poate Unity s intercepteze apeluri?
{ 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 adugm acest comportament la Unity. Vom c ntre apelul clientului i obiectul int, componenta Unity aduga o seciune special la fiierul nostru de configurare care
public bool WillExecute
56

s specifice pentru ce tip dorim s facem aceast interceptare. n Chiar dac nu avem metode specifice apelate de Unity nainte urmtorul exemplu, vom face aceast interceptare numai pentru i dup invocare, aceasta poate fi foarte uor extins. V invit pe tipul Foo: toi s ncercai 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, specificm n Unity s foloseasc interceptorul interfa folosind FooBehavior pentru toate exemplele de obiecte IFoo care sunt asociate cu Foo. Aceeai configurare poate fi realizat din cod, utiliznd 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 ctre interceptorul (comportamentul) nostru special creat. Mai exist i o alt metod de a implementa acest mecanism, folosind atribute. Dac utilizai atribute, va trebui s implementai interfaa 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 interceptm. Din punctul nostru de vedere , este de preferat prima versiune, cea a utilizrii IInterceptionBehavior.
Concluzie
n acest articol am vzut ct de uor putem aduga funcionalitate AOP unui proiect care utilizeaz deja Unity. Implementarea acestei funcii este foarte simpl i flexibil. Ne putem imagina foarte uor scenarii mai complexe, combinnd IinterceptionBehavior i atribute speciale.
Radu Vunvulea
Radu.Vunvulea@iquestgroup.com Senior Software Engineer @iQuest
57
legal
Drept de autor i software. Cteva aspecte practice pentru programatori
Dreptul de autor asupra unui program pentru calculator
eseori, programatorii romni i companiile software sunt insuficient familiarizai cu unele noiuni de baz privind dreptul de autor noiuni ce i pot ajuta substanial n activitatea lor. Din experiena noastr, am ales cteva aspecte care ni se par mai relevante. Bineneles, lista rmne deschis, dar cele de mai jos pot fi un bun nceput.
Pot fi protejate prin drept de autor: orice expresie a unui program, programele de aplicaie i sistemele de operare (exprimate n orice limbaj cod-surs sau cod-obiect), materialul de concepie pregtitor, manualele. Dreptul de autor asupra unui program pentru calculator (software) se nate din momentul crerii acestuia (cnd 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 su (n funcie de situaia concret i de nelegerea scris dintre ei). Nu sunt protejate prin drept de autor: ideile, procedeele, metodele de funcionare, conceptele matematice i principiile care stau la baza oricrui element dintr-un software, inclusiv cele care stau la baza interfeelor sale.
Open source
n practic, probleme interesante apar i n cazul integrrii programelor open-sourcen diverse soluii software dezvoltate pentru clieni. Caracteristica open source este permisiunea de a copia, modifica i distribui n mod liber.Dar cum exist multe tipuri de licene open source, este util s cunoatei ce tip de licen se aplic utilizrii unui anumit soft open source i care sunt implicaiile de natur comercial (i legal, de ce nu) ale fiecrei licene (fie c este vorba despre GPL, Apache, etc.).
nscrierea / nregistrarea n Registrul Programelor pentru Calculator
Cum se poate valorica 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 condiii foarte specifice. Spre deosebire de cesiunea exclusiv, n cazul cesiunii neexclusive, titularul dreptului de autor pstreaz i el drepturile cedate (putnd utiliza el nsui programul) i le poate transmite i altor persoane.
Confuzia dintre licen i cesiune
De cele mai multe ori, sub influena practicii americane, se folosete impropriu noiunea de licen pentru software. Dar termenul de licen nu exist n legislaia aplicabil n Romnia, 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 hrtie sau n format digital) care nsoete un software i prin care se arat c acesta este liceniat, nu vndut. Este, de fapt, un contract ncheiat ntre titularul dreptului de autor i utilizator, prin care utilizatorul primete de cele mai multe ori dreptul neexclusiv de a folosi acel software (fr a-l putea modifica sau transmite altcuiva). Nu implic transferul tuturor componentelor dreptului de autor asupra software-ului.
Probabil ai aflat de Registrul Naional al Programelor pentru Calculator (RNPC) administrat de Oficiul Romn pentru Drepturile de Autor (ORDA), dar nu tii exact ce obligaii au productorii de software. n RNPC, este obligatorie: (i) nscrierea programelor de calculator produse n Romnia i comercializate de ctre comerciani specializai; (ii) nregistrarea societilor comerciale (i a persoanelor fizice autorizate) care produc n Romnia programe destinate comercializrii prin magazine. Exist i excepii 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 productorului software), a programelor destinate utilizrii interne de ctre instituii, organizaii, operatori economici dac nu sunt distribuite prin magazine, etc.
Sanciunea?
Nenregistrarea sau nenscrierea n RNPC este contravenie: amend 2.000 10.000 lei pentru persoanele fizice i 6.000 30.000 lei n cazul societilor comerciale. Condiiile i procedurile privind cererile de nregistrare i de nscriere, eliberarea certificatului de nregistrare sau alte operaiuni sunt detaliate n legislaia specific destul de ampl i uneori ambigu, fiind necesar ajutor specializat pentru a o interpreta corespunztor.
Claudia Jelea
claudia.jelea@jlaw.ro Avocat & Consilier in domeniul marcilor @ IP Boutique
58
legal
sponsori
powered by

Today Software Magazine N22/2014

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Today Software Magazine N22/2014

Uploaded by

Copyright:

Available Formats

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

Cum ctigi jocul automatizrii? Caching-ul imaginilor n aplicaii iOS

6 CCC - A shot of programming

7 Bine ai venit la Techsylvania!

38 Perspective asupra principiilor n design-ul orientat pe obiecte

8 Cluj Innovation Days, 20-21 martie 2014

40 Machine learning in the cloud

10 Ingeniozitate, perseveren i conectivitate

42 Dezvoltare rapid de aplicaii web cu Oracle APEX

11 Startup fr bani? Modelul de investiii Startcelerate

44 O viziune din interiorul GPS Navigaie

14 Cum ctigi jocul automatizrii?

46 IMAGINE studiu al IT-ul clujean

18 iOS image caching. Libraries benchmark

48 Managementul performanei n organizaiile orientate spre proiecte din Romnia

21 THE WEBS SCAFFOLDING TOOL FOR MODERN WEBAPPS Yeoman

51 Lumy.ro usability testing

23 OpenXML Noiuni introductive

52 Optimizarea de ce ar merita efortul?

26 BDD, Javascript i Jasmine

55 AOP folosind Unity

30 De ce dureaz att de mult s terminm un task?

58 Drept de autor i software. Cteva aspecte practice pentru programatori

33 Metodologia Lean pentru Requirements Engineering

Ovidiu Man, PMP

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

Fondator al Today Software Magazine

nr. 22/Aprilie | www.todaysoftmag.ro

Redacia Today Software Magazine

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

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

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

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

radu.orghidan@isdc.eu Requirements engineer @ ISDC

ctudor@ixiacom.com Principal Software Engineer @ Ixia

Today Software Solutions SRL

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

gabriel.enache@fortech.ro Software engineer @ Fortech

razvan.ciriclia@betfair.com Software engineer @ Betfair

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

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

Adina Grigoroiu, CAPM

Copyright Today Software Magazine

gbara@sdl.com Business Consultant @ SDL

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

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

CCC - A shot of programming

Exemplu de problem: The Harvester

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