Numarul 24/iunie 2014 - Today Software Magazine

Nr. 24 • Iunie 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

Java 8 – Procesarea colecțiilor ium

Modelarea obiectuală a testelor de Selen

Visual Studio Online Riscul de a nu avea riscuri Povestea product owner-ului Rețeaua StackExchange Profesioniști QA – creștere și dezvoltare integrarea datelor între sisteme cu Talend Open Studio

Ce este În neregulă cu IT-ul din România?

Cloud – perspectiva contează AOP și PostSharp Avantajele programelor libere Opțiuni pentru a interzice altor persoane să profite de marca dvs. înregistrată

6 Techsylvania Ovidiu Mățan

8 JS Camp 2014 Tudor Trișcă

10 I T.A.K.E. Unconference Cristi Cordoș

11 How to Web MVP Academy Irina Scarlat

12 Interviu Dan Romescu Ovidiu Măţan

15 PM în Agile Ciprian Ciplea

14 Java 8 – Procesarea colecțiilor Ovidiu Simionica

16 Instrumente Microsoft de Business Intelligence Cristian Pup

19 Adăugarea valorii în procesul de dezvoltare Alin Luncan

21 Modelarea obiectuala a testelor de Selenium Corina Pip

34 Visual Studio Online Marius Cotor

38 Rețeaua StackExchange Radu Murzea

42 Profesioniști QA – creștere și dezvoltare Mihaela Claudia

44 Farmecul și provocările dezvoltării unui software de calitate Cătălin Tudor

46 Ce este în neregulă cu IT-ul din România?

Ovidiu Șuța

48 De ce copiii noștri nu visează să devină Project Manageri?

Laurențiu Toma

50 „Cloud” – perspectiva contează!

Florin Asavoaie

51 Post Sharp Radu Vunvulea

54 Securizarea Codului Opensource via Analiza Statică Raghudeep Kannavara

56 Avantajele programelor libere Attila-Mihaly Balazs

25 Riscul de a nu avea riscuri

58 De ce să investim în management profesionist

Ramona Muntean

Dan Schipor

28 Inițierea unui produs Alexandru Bolboaca și Adrian Bolboacă

31 Povestea unui Product Owner Bogdan Giurgiu

59 O nouă schema de ajutor de stat pentru it Roxana Mircea

60 Opțiuni pentru marca dvs. înregistrată Claudia Jelea

editorial

N

Ovidiu Măţan

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

u credeam că este posibil, dar astăzi am luat prânzul împreună cu Richard Stallman, cel care a scris Emacs, GCC-ul, a creat GNU / Linux și a pornit mișcarea free software. O legendă ce a susținut o prezentare la Cluj prin fundația CEATA.org. Discursul său s-a concentrat pe diferența dintre open source și free software. Termenul de free software a fost definit de către Richard Stallman în 1985 în momentul începerii proiectului GNU și a Free Software Foundation (FSF.org). Acesta are scopul de a promova libertatea utilizatorului de a folosi și a modifica după bunul plac codul sursă și de a-l redistribui cu obligația de a menține aceeași licență GPL 3 și pentru produsul rezultat. Astfel, avem siguranța nu doar a creării unei aplicații ci a unui întreg ecosistem deschis ce este menținut în această stare. Opusul acestui concept este softwareul proprietar, care în viziunea lui Richard Stallman nu ar trebui folosit deoarece suntem la îndemâna programatorului și a marilor corporații. Exemplul dat a fost reprezentativ: în 2009, Amazon a șters direct de pe toate dispozitivele utilizatorilor cartea lui George Orwell, “1984”, fără a notifica sau cere acceptul utilizatorilor. Problemele invocate de Amazon la acea vreme au fost legate de copyright. În schimb, open source are ținta de a optimiza cât mai bine codul fără a lua în considerare faptul ca acel cod este înglobat în aplicații ce afectează libertatea utilizatorilor. De ce să folosim free software ? Pentru că acel software este validat de către comunitate și nu sunt acceptate bucățile de cod ce ar putea transforma o aplicație în malware. În timpul discuției cu Richard Stallman, am aflat că prima versiune Emacs a fost scrisă în 4-5 luni. Avem promisiunea unui interviu pe care îl vom publica în următoarele numere ale revistei.

Un alt eveniment important ce a avut loc în Cluj a fost Techsylvania, un eveniment dedicat antreprenoriatului și startup-urilor. Acesta a adus pe scenă antreprenori importanți precum HP Jin, CEO Telenav, Josef Dunne, Co-founder Babelverse sau Rohan Chandran Head of Product @ Telenav. Mai multe detalii veți putea citi în articolul dedicat special acestui eveniment.

Doresc să menționez evenimentul de lansare a revistei organizat împreună cu Cluj IT Innovation Cluster - IT-ul Brașovean găzduit de CRIsoft. Am avut parte de un public numeros și foarte interesat căruia îi promitem că vom reveni. Au fost prezentate ideea și motivația cluster-ului de IT clujean, ecosistem-ul de IT clujean din perspectiva startup-urilor, importanța documentării în project management, Best practices în Agile, framework-uri de dezvoltare web în Java precum și oportunități de finanțare pentru companii.

Acest număr vă propune o serie de articole tehnice scrise din prisma experienței autorilor: Java 8 - procesarea colecțiilor, Instrumente Microsoft de Business Intelligence și Visual Studio Online, PostSharp sau Securizarea codului Opensource via Analiza Statică.

Riscul de a nu avea riscuri ne amintește despre risk management, Povestea unui product owner prezintă provocările la care un product owner este supus. În Rețeaua StackExchange puteți citi despre crearea și dezvoltarea ecosistemului din care face parte și binecunoscutul site stackoverflow.com. Modelarea obiectuală a testelor de Selenium și Profesioniștii QA - cerere și dezvoltare acoperă domeniul testării, iar provocările din IT sunt dezbătute în Ce este în neregulă cu IT-ul din România? Încheiem cu un articol din zona de legal: Opțiuni pentru marca dvs. înregistrată.

Vă dorim o lectură plăcută !!!

Ovidiu Măţan

Fondator al Today Software Magazine

4

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

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

Lista autorilor Bogdan Giurgiu

Claudia Jelea

Group Product Owner @ Endava

Avocat & Consilier in domeniul marcilor

Bogdan.Giurgiu@endava.com

@ IP Boutique

Radu Vunvulea

Ramona Muntean

Senior Software Engineer @iQuest

Measurements & Best Practices Specialist @ ISDC

Tudor Trișcă

Alin Luncan

Radu.Vunvulea@iquestgroup.com

Copyright/Corector: Emilia Toma emilia.toma@todaysoftmag.com Traducător: Roxana Elena roxana.elena@todaysoftmag.com Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com

claudia.jelea@jlaw.ro

Tudor.Trisca@msg-systems.com Team Lead & Scrum Master @ msg systems România

Cătălin Tudor

ctudor@ixiacom.com

Ramona.Muntean@isdc.eu

alin.luncan@accesa.eu Software Engineer @ Accesa

Cristian Pup

cristian.pup@yardi.com

Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com

Principal Software Engineer @ Ixia

Contabil : Delia Coman delia.coman@todaysoftmag.com

Alexandru Bolboaca

Laurențiu Toma, PMP

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

Project Manager @ SOFTVISION

Florin Asavoaie

Radu Murzea

DevOps @ Yonder

PHP Developer @ Pentalog

Ovidiu Șuța

Ovidiu Simionica

Produs de

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

alex.bolboaca@mozaicworks.com

florin.asavoaie@tss-yonder.com

ovidiu.suta@improving-it.com QA & Bid Manager @ ISDC

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

laurentiu.toma@softvision.com

rmurzea@pentalog.fr

ovidiu.simionica@fortech.ro Team Lead @ Fortech

Corina Pip

Dan Schipor

Senior QA Engineer @ Betfair

Management Partner @ Casa de management Daris

corina.pip@betfair.ro

Copyright Today Software Magazine

Software Developer @ Yardi Romania

danschipor@daris.ro

Raghudeep Kannavara

Mihaela Claudia

Security Researcher, Software and Services Group @Intel USA

Senior QA Engineer @ HP România

raghudeep.kannavara@intel.com

mihaela-claudia.chis@hp.com

Attila-Mihaly Balazs

Marius Cotor

Code Wrangler @ Udacity Trainer @ Tora Trading

Technical Lead @ 3Pillar Global

dify.ltd@gmail.com

marius.cotor@3pillarglobal.com

www.todaysoftmag.ro | nr. 24/Iunie, 2014

5

eveniment

Techsylvania

A

m participat în 2 iunie la Techsylvania, un eveniment dedicat 100% antreprenoriatului din IT. Un astfel de eveniment ce poate fi considerat de nișă din prisma industriei locale a reprezentat pentru Cluj o premieră.

Ovidiu Măţan

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

Prima parte a acestui eveniment a constat într-un hackaton local, unde participanții au avut ocazia să dezvolte aplicații pentru device-uri precum Google Glasses, Small printer, Onyx Beacons, Leap motion, Sphero, Sony Smartwatch 2, Pebble, Oculus VR, EyeTribe Tracker1.

Rezultatul celor 24 de ore de hackaton a fost spectaculos din perspectiva inovației, ridicându-se peste multe dintre startup-urile pe care le-am văzut în ultima vreme. Ne adresăm de altfel întrebarea de ce nu există astfel de dispozitive permanent într-un club al IT-ului clujean? Noi, revista TSM, am încercat de o perioadă de timp crearea unui astfel de spațiu dar provocarea cea mai mare este existența spațiului fizic unde acesta să se desfășoare. Bineînțeles, realizarea în totalitate a acestuia este posibilă doar prin implicarea companiilor din domeniu care și-au anunțat disponibilitatea.

1 http://techsylvania.co/event-info

6

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

Revenind la Techsylvania, acesta s-a desfășurat la Cluj Arena, același loc în care a avut loc și IT Days2, astfel că a fost o plăcere revederea acestui spațiu într-o nouă formulă de organizare. Evenimentul a debutat cu prezentarea organizatorilor, executive producers: Vlad Ciurca și Oana Petruș. Prezentarea keynote a venit din partea lui HP Jim, CEO Telenav, care a constat în povestea succesului și a importanței perseverenței în tot ceea ce facem. A pornit ca un simplu student în China, ce a luptat pentru obținerea unei burse în SUA, acesta fiind primul pas pentru a avea șansa de a-și crea propria companie de software. A reușit să obțină o bursă la Standford, în condițiile în care erau alocate doar câte o bursă pentru fiecare domeniu de studiu în întreaga China. Aici a studiat aeronautica și astronautica și de aici i-a venit și ideea pentru compania sa: navigarea prin GPS. Astfel a

2 http://www.itdays.ro

TODAY SOFTWARE MAGAZINE

fost lansat prima aplicație de navigare prin GPS de pe telefoanele mobile. A strâns bani pentru finanțare, iar modalitatea de a obține banii a fost o simplă prezentare, dar afirmă că au contat însă în primul rând relațile personale.

Ghinionul a fost cel ce a caracterizat Telenav în perioada de creștere. În ziua în care au decis să vină în Europa pentru strângerea de fonduri, a avut loc atentatul din 9/11. Cu o zi înainte de a-și lansa intenția de a se lista la bursă, Google a anunțat hărțiile gratuite. Lista de ghinioane nu se oprește aici pentru că în data în care s-a pornit IPO roadshow, Microsoft a anunțat de asemenea hărțile gratuite. Vulcanul din Islanda ce a întrerupt pentru mai multe zile călătoriile cu avionul, a avut loc în timpul unei călătorii tot în Europa pentru promovarea companiei înainte de listarea la bursă. Cu toate aceste impedimente, Telenav a devenit o companie de succes care a achiziționat recent Skobbler. Visul lui HP Jim este să ridice Telenav din Top 100 în Top 10, iar în portofoliul de investiții se numără proiecte precum cel de realizare a unei mașini zburătoare. Sfatul dat participanților: God favor you because you are persistent.

Marcus Segal, fost COO Casino Division la Zynga și antreprenor a impresionat prin multitudinea de domenii în care a lucrat.

Acesta a pornit din industria de muzică, fiind VP la eMusic.com ,un serviciu de vânzare online a albumelor muzicale de la începutul anilor 2000. Fiind o noutate absolută la acea vreme, s-au lovit de problema educării utilizatorilor care de multe ori nu înțelegeau de ce cumpărăturile nu se finalizau cu un disc fizic al albumului cumpărat. În cele din urmă a apărut Napster, ceea ce a afectat vânzările, iar compania a fost achiziționată de către Universal.

Marcus a dat și câteva sfaturi practice: fă parte dintr-o comunitate, nu căuta pegacorns (pegas cu un corn de unicorn). Menționăm și abordarea inedită ce constă într-o întrebare legitimă ce ar trebui adresată unui VC: este cineva în rețeaua ta/voastră care m-ar putea

ajuta?

Andy Peper, developer advocate la Twitter, a prezentat o integrare a Twitter-ului și internet of things precum monitorizarea umidității solului în care cresc plante și alertarea proprietarului printr-un tweet în momentul în care este nevoie să fie udate. A fost prezentat bineînțeles și Twitter API-ul cu câteva exemple practice.

Josef Dunne, co-fondator al Bebelverse a prezentat conceptul Nemawashi, un procedeu de a lua un copac și de a-l replanta în altă parte. Călătoria sa în lumea startup-urilor este spectaculoasă, a început cu ideea aplicației Babelverse la un Startup Weekend în Grecia de unde a plecat în Chile prin programul Startup Chile.

Printre alte peripeții, cauzate în mare parte de lipsa finanțării, a ajuns pe podium la LeWeb, TheNextWeb și TechCrunch Disrupt.

Totodată visul de a nu avea constrângeri în dezvoltarea Babelverse l-a făcut ca să refuze la un moment dat o finanțare de 2 milioane de dolari. Spiritul disruptive și umanitar s-a materializat prin realizarea unui hackaton de 24 de ore după momentul tsunami-ului din Japonia din 11 martie 2011. Rezultatul a fost o aplicație foarte utilă de comunicare cu cei aflați în dificultate.

Voicu Oprean, CEO Arobs a prezentat povestea de succes a companiei și modalitățile de stimulare a angajaților de a-și dezvolta propriile idei de produs. În încheiere, doresc să îl menționez și pe Rohan Chandran, Head of Product and Global Services la Telenav ce a arătat latura profesionistă a dezvoltării de produse. Sucesul unui produs nu este o loterie, ci o analiză iterativă cauză-efect în funcție de care se iau deciziile.

Ne-a făcut plăcere să participăm la prima ediție a Techsylvania. care s-a remarcat în aria antreprenoriatului din mediul local de IT și sperăm să devină o tradiție locală.

www.todaysoftmag.ro | nr. 24/Iunie, 2014

7

eveniment

JS Camp România 2014

Î

n data de 3 iunie 2014, a avut loc la București conferința internațională JSCamp pentru România și Europa de Est, prima de acest gen în țara noastră. Evenimentul a fost dedicat în special persoanelor din zona de Web Design și Front-End Develoment.

Tudor Trișcă

Tudor.Trisca@msg-systems.com Team Lead & Scrum Master @ msg systems România

8

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

Această primă ediție a fost împărțită în patru sesiuni de conferințe intensive despre tendințele în web development, studii de caz și experiențe internaționale, tehnologii open-web și tool-uri avansate.

Cu sala plină, Robert Nyman începe prima sesiune de prezentări. El este un Technical Evangelist la Mozilla și editorul de la Mozilla Hacks. Prezentarea lui se numește „The five stages of development” în care face o corelare în perspectivă psihologică a dezvoltării unui proiect software cu modelul lui Kübler-Ross despre cele cinci stagii ale suferinței: negare, furie, negociere, depresie și acceptare. El mai prezintă și un nou proiect de la Mozilla, Open Web Apps, care reprezintă aplicații dezvoltate în HTML5 și JavaScript, funcționabile pe toate platformele. O altă noutate pe care o menționează este lansarea de canale de

feedback pentru Mozilla, unde dezvoltatorii pot să exprime opiniile și ideile legate de proiectele din cadrul Mozilla: “A face webul un loc mai bun nu se referă doar la a-ți da seama despre ceea ce este corect – ci este vorba despre ascultarea oamenilor, adunarea gândurilor și ideilor pe care le au în realizarea de rezultate mai bune”.

Tero Parviaien, un specialist independent în Software, oferă cea de-a doua prezentare, intitulată “How to build your own AngularJS”. El vorbește despre trei strategii care se pot aplica atunci când se dorește să se folosească într-un proiect un framework JavaScript: Respingere, Studiu, Construire. Se axează mai mult pe ce-a de-a treia strategie, unde spune că pentru a avea o înțelege mai aprofundată a frameworkului AngularJS, pentru a ști când și cum poate fi folosit, varianta recomandată e ca

TODAY SOFTWARE MAGAZINE dezvoltatorul să construiască de la zero, ceva asemănător cu o clonă a AngularJS-ului, pentru a-și forma un model mental. Prezintă și un demo, construiește o aplicație numită RocketLauncher unde exemplifică modul în care e construit dependency injection-ul în AngularJS. Sebastian Golasch, Specialist Senior Manager Software Developer la Deutsche Telekom, deschide cea de-a doua sesiune, cu o prezentare numită “The Glitch in the game”. Tematica aleasă e cea a testării paginilor web, care constituie o adevărată provocare în ziua de azi. El prezintă diferite unelte și tehnici pentru prevenirea problemelor, eșecurilor și comportamentului straniu al paginilor web. Vorbește despre automatizarea diferențierii de imagini, testarea CSS-ului, folosirea de „monkey testing” și testa-

rea performanței pentru a rămâne consecventă în timp.

Phil Hawksworth, JavaScript developer la R/Ga, este specializat în dezvoltarea site-urilor Web de la sfârșitul anilor 90. El vorbește despre „Static Site Strategies”. Prezentarea lui conține caracteristicile site-urilor statice, o serie de servicii și unelte ce pot fi folosite în crearea unor site-uri robuste, de mare performanță care pot deveni chiar mai dinamice decât altele mai greoaie și mai costisitoare. Vorbește și de construirea foarte rapidă a site-urilor, mai deștepte, fără back-end-uri complexe. Prezintă și conceptul de „Bake, don’t fry”, o metodă mai „sănătoasă”, care reduce complexitatea, ușurează dezvoltarea și crește portabilitatea.

Martin Kleppe, cofondatorul și Head of Development la Ubilabs, vorbește despre „Minified JavaScript Craziness”.

Prezentarea lui este despre arta numită code golfing, adică cum să scrii programe complexe în mai puțin de 1K de JavaScript. Printre exemplele demonstrate se numără un glob pământesc care se învârte, jocul 2048 și Flappy Bird. De asemenea, el expune modul cum poți trece de securitate folosind doar șase caractere diferite.

Peter Müller încheie cea de-a treia serie de prezentări cu o tematică numită „The no build system build system”. El este Frontend Lead la Podio și organizator al CopenhagenJS. În prezentare se concentrează pe partea de build și optimizare al ciclului de viață al dezvoltării. Explică de ce este nevoie de un sistem de build, care este problema generală a uneltelor de build din ziua de azi și prezintă un proiect numit AssetGraph care ajută la crearea workflow-ului și codul dezvoltat să fie mai „developer friendly”.

Patrick H. Lauke, Accessibility Consultant la The Paciello Group deschide ultima sesiune de prezentări cu tematica „Getting touchy – An introduction to Touch and Pointer Events”. El vorbește despre cum în ziua de azi dispozitivele cu touch sunt introduse atât în smartphone-uri și tablete, cât și în laptop-uri și chiar și calculatoare desktop. Prezentarea conține tratarea evenimentelor de touch, de la cele mai simple interacțiuni de tap până la multitouch, gesturi și folosirea evenimentelor de pointeri introduse de Microsoft.

Ziua se încheie cu Vince Allen, Software Engineering Manager în cadrul companiei Spotify, care vorbește despre „Braitenberg and the Browser”. Valentino Braitenberg a fost un neurolog în anii 1970 și a scris o carte în care a descris o serie de mașinării

imaginare cu senzori analogi atașați. Prezentatorul face o analogie între aceste mașinării descrise de către Braitenberg și omul modern din ziua de astăzi cu un telefon mobil. El vorbește despre conexiunea dintre oameni și astfel de dispozitive. Prezintă și cum se poate folosi JavaScript pentru a crea astfel de mașinării Braitenberg și alte simulări naturale într-un browser web.

Personal, conferința mi s-a părut foarte reușită și prezentatorii m-au ținut captivat până la sfârșit. Abia aștept ediția următoare unde sper că vor fi mai mulți prezentatori dar și mai mulți participanți!

www.todaysoftmag.ro | nr. 24/Iunie, 2014

9

eveniment

Î

I T.A.K.E. Unconference

n 29-30 mai, în București a avut loc I T.A.K.E. Unconference, organizată de Mosaic Works. I T.A.K.E Unconference și-a propus și a reușit să spargă tiparul clasic de conferință, oferind pe lângă clasicele prezentări și keynote-uri, workshop-uri, ateliere de codat, concursuri de codat și un interesant concept “open space”, care presupune organizarea spontană a participanților în grupuri de discuție pe teme diverse. A fost un eveniment cu și pentru geeks, temele fiind povești adevărate din lumea software, practice de arhitectură și design, și leadership tehnic.

Prima zi a debutat cu keynote-ul lui Michael Feathers, autor al cărții “Working Effectively with Legacy Code” și fost membru ObjectMentor. Keynote-ul său a gravitat în jurul legii lui Conway, care postulează că structura unei organizații se reflectă în designul codului produs de organizație.

Și pentru că oamenilor le plac poveștile, în a doua zi am ales track-ul “True Software Stories”. Aki Salmi ne-a prezentat, pas cu pas și cu multe exemple de cod, cum a adăugat două funcționalități noi într-un proiect fără teste și cu un cod murdar, refactorizându-l pe parcurs. Apoi Thomas Sundberg a demonstrat cum poți face Behavior Driven Development cu Cucumber JVM printr-o sesiune de live coding. Dimineața s-a încheiat cu Andreas Leidig, administratorul comunității Softwerkskammer, livrândune povestea tehnică a site-ului comunității.

Ultima după-masă a evenimentului a debutat cu Felienne Hermans, profesor la Universitatea din Delft, care a discutat pe marginea diferitor aserții demonstrate, dintre care am selectat: oamenii nu aleg limbajul în care codează pe criterii tehnice, cunoștințele de design patterns fac codul mai lizibil pentru alți programatori sau cele mai folosite limbaje sunt și cele mai puțin expresive.

În continuare, am ales să participăm la track-ul de technical leadership, care a constat dintr-un workshop și o prezentare, ambele ținute de Flavius Ștef, agile coach la MosaicWorks.

Workshop-ul “Leading Technical Teams” a fost unul interactiv, participanții dezbătând împreună cu Flavius diverse fațete ale leadership-ului tehnic. În cadrul workshop-ului, s-au dezbătut subiecte precum calitățile unui lider tehnic, modul cum aduci schimbarea într-o organizație tehnică și diverse aspecte ale comunicării și ascultării necesare unui lider.

După prânz am rămas cu Flavius la prezentarea “Scaling Agility: The Technical Angle” care ne-a vorbit despre o serie de Keynote-ul de încheiere a fost susținut de Tom Gilb, un veteran best practices tehnice care pot ajuta companiile agile cu un număr al industriei software, care a pledat pentru abordarea inginerească mare de oameni. a construirii software-ului în defavoarea abordării empirice adusă de scrum. De asemenea, acesta a subliniat că principala barieră în calea abordării inginerești o reprezintă greutatea alegerii metricilor. Și pentru că I T.A.K.E. Unconference a fost organizată de Mosaic Works, un promotor al practicilor de Software Craftsmanship dar si agile, aceasta s-a încheiat, cum altfel? - cu o retrospectivă, noi rămânând în așteptarea următoarei iterații.

Prima zi s-a încheiat cu un “open space” în care s-au dezbătut aprins atât teme tehnice precum “Continous integration”, CQRS sau code review, cât și teme organizaționale, ca tranziția la agile. În ultima discuție, am aflat despre TargetProcess, o companie organizată democratic, fără straturi de management, pe modelul celor de la Valve.

10

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

Cristi Cordoș

ccordos@ixiacom.com Engineering Manager @ Ixia

startups

TODAY SOFTWARE MAGAZINE

How to Web MVP Academy prezintă echipele admise în programul de pre-accelerare

B

ucurești, 26 mai 2014 – How to Web MVP Academy, program de pre-accelerare adresat startup-urilor în tehnologie din Europa Centrală și de Est, a selectat echipele finaliste. În perioada 2 iunie – 22 iulie acestea vor lucra alături de mentori și profesioniști consacrați la nivel regional pentru a-și dezvolta produsele și a învăța cum să profite de oportunitățile existente pe piața globală.

Startup-uri tech activând în domenii precum software, hardware, internet of things, mobile, medtech sau ecommerce au aplicat pentru participarea la How to Web MVP Academy. Acestea au fost evaluate de specialiști în domeniu luând în considerare experiența și capacitatea de execuție a echipei, dimensiunea și tendințele pieței, validarea inițială a produsului și tracțiunea acestuia, potențialul și impactul la nivel internațional, precum și fezabilitatea proiectului (scalabilitate, cost de achiziție al clienților).

Cei 15 finaliști au fost desemnați după o analiză atentă a juriului din care au făcut parte Cosmin Ochișor (Liaison Manager hub:raum), Zoli Herczeg (Partner Business Evangelist Microsoft România), Cristi Badea (Co-Fondator & Chief Product Officer MavenHut), Bogdan Iordache (Co-Fondator & CEO How to Web) și Monica Obogeanu (Program Manager How to Web MVP Academy).

Cine sunt echipele finaliste ale How to Web MVP Academy?

15 echipe care dezvoltă produse în domenii precum software, hardware, Internet of Things, mobile sau medtech din România, Bulgaria și Slovenia au fost admise la How to Web MVP Academy.

Startup-urile care vor participa la prima ediție a programului de pre-accelerare sunt: Axo Suits – exoschelete cu putere mare ; Bravatar – rețea de comunități de fani dezvoltate în jurul brand-urilor ; Complement – software pentru management educațional, catalog online și platformă de dezvoltare personală; Doctrina d.o.o. – Platformă care facilitează transferul de cunoștințe pentru farmaciști, ajutându-i pe aceștia să învețe mai multe despre produse prin participarea la web-inarii; Drimm.in – platformă socială care permite utilizatorilor să se asocieze pentru a-și ajuta prietenii să își îndeplinească dorințele; Fitter – aplicație mobile care conectează sălile de fitness cu clienții acestora într-un mod personal, intuitiv și eficient, oferindu-le o experiență de antrenament personalizat; Gloria Food – sistem de comenzi online gratuit care permite restaurantelor să interacționeze în mod direct cu clienții acestora; Hickery – music player web și mobile care permite utilizatorilor să interacționeze între ei și să asculte muzică în funcție de preferințele exprimate pe social media; Inovolt – produs care combină componente hardware și software și permite utilizatorilor să măsoare, să înregistreze și să analizeze consumul energetic în timp real; Lifebox – aplicație mobile care permite utilizatorilor să creeze albume de fotografii comune cu prietenii acestora și să creeze astfel amintiri împreună;

Pillbuzz – brățară conectată la o aplicație mobilă care îi ajută pe utilizatori să își respecte tratamentele medicale; Pocketo – aplicație mobile care, cu ajutorul unei componente hardware, permite dezvoltatorilor de produse IoT să creeze prototipuri rapid și ieftin; Qalendra – platformă de călătorii care permite persoanelor dornice de aventură să descopere noi oportunități și să își realizeze propriul calendar; StudyMentors – platformă online care pune în legătură tinerii care își doresc să aplice la studii în străinătate cu studenții și absolvenții universităților europene; Wallet Buzz – aplicație mobile care transmite utilizatorilor de smartphone-uri ofertele retailer-ilor în funcție de proximitate Între 2 iunie și 22 iulie, finaliștii How to Web MVP Academy vor acumula competențe esențiale de business care îi vor ajuta să își dezvolte produsele la scară globală. Startup-urile vor beneficia, pe lângă componenta educațională, de acces la spațiul de co-working oferit de TechHub Bucharest, mentorat, acces la comunitatea tech la nivel internațional și conexiuni cu investitori de tip angel, programe de accelerare și fonduri de investiții early stage. În plus, echipa How to Web MVP Academy va fi alături de acestea pe toată durata programului și îi va ajuta să își urmărească progresul și să acceseze resurse relevante pentru nevoile lor specifice.

How to Web MVP Academy este un program dezvoltat în parteneriat cu Microsoft, Romtelecom și Cosmote cu sprijinul Bitdefender, Raiffeisen Bank, Hub:raum și TechHub Bucharest.

Echipele finaliste vor începe să lucreze în spațiul de co-working de la TechHub Bucharest luni, 2 iunie și, o zi mai târziu, vor avea ocazia să cunoască mentorii locali și să interacționeze în mod direct cu aceștia în cadrul unui eveniment privat.

Startup-urile vor parcurge un program de 7 săptămâni în care vor lucra intensiv la dezvoltarea propriilor produse și vor participa la workshop-uri și sesiuni de mentorat 1 la 1. Programul se va încheia pe data de 22 iulie cu Demo Day, oferind astfel echipelor ocazia de a-și prezenta produsele și progresul în fața unei audiențe formate din reprezentanți ai unora dintre cele mai apreciate programe de accelerare la nivel european, investitori de tip angel, fonduri de investiții early stage, antreprenori și profesioniști în tehnologie.

Irina Scarlat

irina.scarlat@howtoweb.co Co-Fondator al Akcees @ How To Web

www.todaysoftmag.ro | nr. 24/Iunie, 2014

11

interviu

Interviu cu Dan Romescu

A

m avut plăcerea de a realiza un interviu cu Dan Romescu, fondator DruidCon și președintele Augmented Reality Fundation.

Dan va fi vorbi la evenimentul DevTalks - devtalks.ro ce va avea loc în 11 iunie la București.

Ce părere ai despre Google Glasses din perspectiva vieții private. Într-o prezentare recentă de-a ta ai menționat despre un led ce ar trebui inclus pentru a notifica celelalte persoane despre faptul că înregistrăm?

[Dan Romescu] Google Glasses prezintă, în acest moment, un caracter de intruziune foarte ridicat în viața de zi cu zi.

La început oamenii sunt curioși, însă după ce realizează faptul că le poate fi lezată viața privată, devin refractari. Personal, consider că trebuie definite norme sociale și reguli foarte clare.

De exemplu, să îi ridici la 30%, exact cum ai proceda cu ochelarii de soare, când vrei ca cineva să îți vadă ochii. Acest gest oferă încredere interlocutorului și ajută la dezvoltarea unor conversații deschise.

Din punct al integrării Google Glasses într-un sistem deja existent, ce aspect ar trebui luate în considerare? În vertical markets există deja soluții în logistică, domeniul medical, sport management etc. Pentru piața de masă ar trebui să existe mai multe device-uri, lumea să fie educată în privința folosirii adecvate și să apară mai multe cazuri de utilizare și content pentru consumatori.

Ce părere ai despre evoluția internet of things și care este perspectiva ta asupra evoluției viitoare?

Eu l-aș numi Web of Things, Internet există și este inseparabil.

Explozia în atât de multe domenii, de la House Automation, la Sănătate până la Quatifiedself ne arată că nu mai este vorba de viitor, ci de realitate.

+

+

Dev(Talks): 11 JUNE // RADISSON BLU // BUCHAREST

Meet some of the brightest minds in software development.

+

Enjoy great talks with our speakers and our partners from the exposition booths.

Keep your skills up to date with the latest trends.

TERENCE EDEN

RARES VASILESCU

MARTIN PERCK

CRISTIAN NEICU

Innovation Catalyst

Software Development Director

Senior Technology Consulting Director

Application Innovation Service Mobile Practice Leader IBM

The Lab part of Telefonica

Gold partners

Star Storage

Oracle

Silver partner

Design powered by

www.devtalks.ro Media partners

T O D A Y S O F T WA R E M AG A Z I N E

Care este viziunea ta în ceea ce privește rețelele sociale și realitatea augmentată?

Rețelele Sociale se vor verticaliza, se vor diversifica după centralizarea accentuată din acest moment sub umbrelă FB. Eu văd AR ca un instrument creat pentru o interfață mai accesibilă în relația om - mașină. Dacă ne aducem aminte, la începuturi, existau doar comutatoare în interfața cu calculatorul. Apoi am trecut la cartele perforate - primul meu program în 1982 a fost pe cartele perforate.

Apoi linia de comandă, interfață grafică cu maus, touchpad. Apoi generația display cu touchscreen, parte de recunoaștere gesturi. Eu cred că nu suntem departe de a controla mașina cu forța gândurilor, vezi emotiv interfața pe care eu o consider cea mai evoluată.

Realitatea augmentată nu are o prezență reală în viața de zi cu zi, excepție fiind poate sectorul auto. Cum vezi evoluția acestui segment?

Pot să vă contrazic, realitatea augmentată există în viața de zi cu zi, doar că este în domeniul Audio. Walkman-ul a fost primul

12

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

device AR Audio. Partea de dolby surround a ridicat nivelul de AR Audio. Eu văd partea de context foarte necesară pentru a reda relevanța contentului. Un singur exemplu aș da la sfârșit, 4 iBeacon-uri așezate într-o piramidă pot arăta poziția senzorului video și crea noi experiențe. Perspectiva din care avem o experiență poate fi prelevată și prelucrată. Restul este geometrie analitică... .

Ovidiu Măţan

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

comunități

TODAY SOFTWARE MAGAZINE

Comunităţi IT

A

m intrat în perioada estivală, a vacanțelor, iar aceasta se reflectă și în numărul evenimentelor din IT. Rămân totuși evenimentele lunare precum lansarea revistei sau Mobile Monday care vor continua. Chiar mai mult, dacă luna trecută ne-am întâlnit cu Brașovul în cadrul unei lansări a revistei, luna aceasta vom merge și în Iași pentru Antreprenoriat și Inovație organizat de Gemini Solutions Foundry.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

Website: www.transylvania-jug.org Data înfiinţării: 15.05.2008 / Nr. Membri: 577 / Nr. Evenimente: 43 Comunitatea TSM Comunitate construită în jurul revistei Today Software Magazine.

Website: www.facebook.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 1545/Nr. Evenimente: 19 GeekMeet România Comunitate dedicată tehnologiilor web.

Website: geekmeet.ro Data înfiinţării: 10.06.2006 / Nr. Membri: 520 / Nr. Evenimente: 17 Cluj.rb Comunitate dedicată tehnologiilor Ruby.

Website: www.meetup.com/cluj-rb Data înfiinţării: 25.08.2010 / Nr. Membri: 178 / Nr. Evenimente: 40 The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software.

Website: www.agileworks.ro Data înfiinţării: 04.10.2010 / Nr. Membri: 396 / Nr. Evenimente: 55 Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice.

Website: www.meetup.com/Cluj-Semantic-WEB Data înfiinţării: 08.05.2010 / Nr. Membri: 183/ Nr. Evenimente: 27 Romanian Association for Better Software Comunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.

Website: www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 235/ Nr. Evenimente: 14 Tabăra de testare Un proiect care își dorește să strângă cât mai mulți oameni care lucrează ca și testeri.

Website: tabaradetestare.ro Data înfiinţării: 15.01.2012 / Nr. Membri: 314/ Nr. Evenimente: 30

Calendar Iunie 11 (Cluj) Lansarea numărului 24 al Today Software Magazine www.facebook.com/todaysoftmag Iunie 12 (Iași) Antreprenoriat și inovație gemsfoundry.com Iunie 12 (Cluj) Python and Ember.js meetup.com/Cluj-py/events/185193022/ Iunie 15 (București) Workshop Arduino it-events.ro/events/workshop-arduino-15-iunie/ Iunie 16 (Brașov) Innovation Monday Brasov ricap.ro/blog/ricap-innovation-monday-brasov/ Iulie 17 (Cluj) Conexiuni Cluj-Napoca – Office 365 pentru ONG-uri it-events.ro/events/conexiuni-cluj-napoca-office-365-pentru-ong-uri/ Iunie 19 (Cluj) Monthly BA Community Meetup #8 meetup.com/Business-Analysts-Cluj/events/165545862/ Iunie 24 (București) SEETEST it-events.ro/events/seetest-2014-south-east-europeansoftware-testing-conference-bucharest/ Iunie 30 (Cluj) Mobile Monday Cluj #9 meetup.com/Cluj-Mobile-Developers/events/177046772/

www.todaysoftmag.ro | nr. 24/Iunie, 2014

13

programare

Java 8 – Procesarea colecțiilor

J

ava 8 e frumoasă. Da, îi atribui oarecum genul feminin încă dinainte de a ajunge la magica cifra 8. În acest articol mă aventurez în a analiza în ce măsură această frumusețe este formă versus fond. Admit că de-a lungul competiției limbajelor de programare, Java a tot rămas datoare în a-și satisface comunitatea de entuziaști.

Ovidiu Simionica

ovidiu.simionica@fortech.ro Team Lead @ Fortech

Lambda expressions. Da, C# avea Lambda expressions de ceva vreme, mai precis din versiunea 3.0 din anul 2007.

Java a mai avut nevoie de încă șapte ani.

Functional programming atât de târziu.

Generics. O amăgire în forma către template metaprogramming eșuând prin type erasure1 sau doar eu speram la altceva?

Mă simt ca un iubitor de Nokia ce visează la high resolution și la Android. Ca tot javrar-ul, vă imaginați cum așteptam forțând butonul de refresh de pe site-ul Oracle pentru a da o descărcare la proaspăta versiune în ziua release-ului.

Aflându-se, la data articolului de față, de ceva vreme pe “masa de operații”, iată că am ajuns acum să împărtășesc impresii cu privire la o chestiune ce m-a tot frământat de-a lungul carierei: prelucrarea colecțiilor de date.

Ce este prelucrarea colecțiilor de date (aka filtrarea)?

Pentru cei familiarizați cu SQL, filtrarea este o operație de bază asupra unui set de date de tipul: SELECT * FROM Cars WHERE Cars.manufacturer = ‘VW’;

Dar ce ne facem dacă colecția este deja în memoria programului și vrem să o prelucrăm conform condițiilor de mai sus?

1 http://en.wikipedia.org/wiki/Type_erasure

14

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

Până la Java 8, programatorul scria: ArrayList filteredCars = new ArrayList();

for(Car c : allCars) { if (“VW”.equals( c.getManufacturer())) {

filteredCars.add(c); } }

Alții, arhitecți, mai scriau: interface Predicate<T> { boolean apply(T t); } class Filter { public static Collection<T> do (final Collection<T> items, Predicate<T> pred) {

Collection<T> result = new ArrayList<>();

for(T item : items) { if (pred.apply(item)) { result.add(c); } }

return result; } }

Ca apoi să apelăm: new Filter().do( allCars, new Predicate<Car>() { @Override

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

management

public boolean apply(Car c) { return “VW”.equals(c.getManufacturer()); } );

În Java 8 aplicăm: Collection<Car> filtered = allCars.stream().filter( c -> (“VW”.equals( c.getManufacturer())) ).collect( Collectors.toList());

TODAY SOFTWARE MAGAZINE este el însuși utilizat ca worker. Se mixează astfel thread-urile unui pool cu un thread ce are alt scop. Dacă cumva chiar acel thread prinde o porțiune de procesare ce durează neașteptat de mult, avem riscul unei blocări a procesărilor din cadrul pool-ului tocmai din cauza design-ului conceptului de Fork/Join (thread-ul apelant lucrează ca worker și celelalte thread-uri nu pot adăuga rezultate câtă vreme se așteaptă după finalizarea execuției threadului părinte). Avem o problemă!

Avem de a face aici cu fenomenul de Paraquential “[a portmanteau word derived by combining parallel with sequential] The illusion of parallelization. Processing starts out in parallel mode by engaging multiple threads but quickly reverts to sequential computing by restricting further thread commitment.” (Edward Hardned, 2014).

Soluția propusă de Oracle este utilizarea explicită a unui ForkJoinPool controlat de către dezvoltator. De tipul:

Și iată cum Java 8 ne oferă “high resolution”.

Dar trăim într-o eră a big data și aplicațiile “real-world” se cer a fi scalabile și performante, ca atare nu mai e suficient să procesăm secvențial milioane de înregistrări (dacă cumva a fost vreodată suficient).

Parallel processing și utilizarea optimă a core-urilor de procesor este “everyday business”.

Java 8 ne vine în ajutor și acum putem scrie: ForkJoinPool forkJoinPool = new ForkJoinPool(20); Collection<Car> filtered = allCars. parallel().filter( c -> (“VW”.equals(c.getManufacturer())) ). collect(Collectors.toList());

forkFoinPool.submit(()->allCars. parallel(). filter( c -> (“VW”.equals(c.getManufacturer())) ). collect(Collectors.toList())).get();

Astfel toate task-urile generate de procesarea paralelă rămân Doar prin acest simplu apel către metoda “parallel()” mă asi- în pool-ul specificat. gur că librăria de stream va face magie și va împărți stream-ul în Un efect pozitiv este acela că putem folosi un timeout pe bucățele mici ce vor fi procesate în paralel. metoda get(); situație dorită de obicei într-o aplicație real-world.

Dar aceasta ne întoarce la problema de bază: managementul Job done. Sau nu? pool-urilor din nou în responsabilitatea dezvoltatorului! Situația Îmi place să citesc javadoc-uri, consider că e un obicei ce devine mai dificilă în combinație cu situațiile complexe generate trebuie cultivat pentru că ne poate salva de la multe dezastre. Și de mediul multi-thread și cu reglarea atentă a configurărilor în am mai cultivat în timp un fel de “simț al pericolului”, în special funcție de arhitectura hardware (e.g. procesor). Și iată cum din când văd cuvinte mari de genul “parallel”, urmate apoi de magia nou Java ne dă jumătăți de măsură pe când speram la un thread rezultatului. container self-managed (sau măcar easy-managed).

Ce fire de execuție folosește metoda aceasta? Și folosește desChiar dacă pentru mulți dintre noi comportamentul implicit al tule? Cum determină câte să folosească și ce se întâmplă dacă framework-ului de streaming este și va fi mai mult decât suficient, metoda “parallel()” este apelată paralel la rândul ei? în ceea ce mă privește, metoda parallel va rămâne în lista mea de Documentația spune: “Arranges to asynchronously execute this “dangerous code” în activitățile de programare și code review. task in the pool the current task is running in, if applicable, or using Am atins doar vârful iceberg-ului prin această scurtă analiză. the ForkJoinPool.commonPool() if not inForkJoinPool().”

Pentru cei dintre voi curioși să vadă ce alte capcane se ascund Prin urmare, implicit folosim un singur pool indiferent de câte chiar în inima librăriei de ForkJoin, vă invit să urmăriți cu atenție thread-uri apelează metoda “parallel()” prin întreaga aplicație, un dude cu peste 30 de ani de experiență, ce detaliază foarte bine deoarece librăria de stream folosește librăria de ForkJoin2. aceste lucruri în postul său A Java Parallel calamity3. Și mai mult, thread-ul care trimite job-ul de procesare paralelă 2 http://gee.cs.oswego.edu/dl/papers/fj.pdf

3 http://coopsoft.com/ar/Calamity2Article.html

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

www.todaysoftmag.ro | nr. 24/Iunie, 2014

15

programare

management

Instrumente Microsoft de Business Intelligence

O

dată cu intrarea în era informației am găsit atât soluții la problemele anterioare cât și noi probleme ce așteaptă a fi rezolvate. Informația abundă în mediile digitale dar nu întotdeauna este ușor să se obțină o vizualizare a acesteia, astfel încât să ne fie utilă în luarea deciziilor importante.

Cristian Pup

cristian.pup@yardi.com Software Developer @ Yardi Romania

În acest scop instrumentele de Business Intelligence promit să aducă soluții pentru transformarea informației brute de care dispunem.

Business intelligence (BI) constă întrun set de teorii, metodologii, arhitecturi și tehnologii care transformă datele brute în informații relevante și utile pentru mediul de afaceri1.

Scopul instrumentelor de BI este de a prelucra cantități enorme de date nestructurate în scopul de a identifica, dezvolta și de a crea noi oportunități. Se spune că imaginile sunt o modalitate mai bună de a prezenta o informație decât cuvintele. Mintea umană înțelege mult mai ușor explicația grafică decât explicația teoretică. În scopul de a lua o decizie, informațiile noastre trebuie să fie afișate cu o prezentare adecvată în termeni de diagrame, rapoarte, etc. .Inițial, conceptul de Data Warehouse se referea doar la păstrarea datelor istorice. În zilele noastre, Data Warehouse constituie fundamentul pentru mediul BI. În general, Business Intelligence în calitate de concept este format dintr-un număr tot mai mare de componente printre care se numără următoarele: • agregare multidimensională și alocare a datelor, • d e n o r m a l i z a r e , e t i c h e t a r e ș i standardizare, • raportare în timp real, • i n t e r f a ț ă c u s u r s a d e d a t e nestructurate, 1 http://en.wikipedia.org/wiki/Business_intelligence

16

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

• consolidare la nivel de grup, bugetare și prognoză, • inferență statistică și simulare probabilistică, • indicatori de performanță, • control de versiune și gestionare a proceselor.

Conceptul BI este alcătuit din mai multe activități conexe, incluzând data mining, prelucrare analitică on-line, interogare și raportare.

Un exemplu de companii care folosesc instrumentele de BI sunt marile restaurante.

Acestea folosesc instrumentele BI în scopul luării deciziilor strategice cum ar fi: ce produse noi ar trebui să adauge la meniurile lor, ce feluri de mâncare ar trebui să elimine, care dintre magazine ar trebui să le închidă, atunci când renegociază contractele cu furnizorii de produse alimentare și atunci când încearcă să identifice noi oportunități pentru a îmbunătăți procesele ineficiente.

Instrumente BI de la Microsoft

Dintre toți furnizorii de software din întreaga lume, Microsoft pare a fi singurul autorizat să pretindă că oferă „Business Intelligence pentru toată lumea”. Acesta este modul în care Microsoft face publicitate noii sale platforme de Business Intelligence. În timp ce a proiectat noua platforma de Business Intelligence, Microsoft a folosit toată experiența pe care a acumulat-o în furnizarea de sisteme de operare și suite de birou pentru utilizatorii finali.

TODAY SOFTWARE MAGAZINE utilizatorilor din cadrul organizației să lucreze pe aceeași versiune de date crescând performanța acestora.

• Raportare și analiză. Raportarea și capacitățile analitice ale platformei Microsoft Business Intelligence permite utilizatorului să pregătească și să modifice rapoarte și analize. Mediul de lucru este în acest caz sigur și intuitiv, astfel încât nu există nevoie de specialiști pentru întreținerea sistemului.

• Data mining și analiză predictivă. Platforma oferă instrumente care ajută la analizarea în mod automat a datelor din diferite puncte de vedere și descoperirea tendințelor.

• Stocarea datelor. Platforma Microsoft Business Intelligence oferă procese ETL (Extract, Transform, Load) și sprijină separarea datelor și depozitarea acestora.

PowerPivot și SQL Server Analysis Services (SSAS) Modelul semantic BI - http://blogs.msdn.com/b/cathyk/ archive/2011/10/17/the-bi-semantic-model-mdx-dax-and-you.aspx

Platforma Microsoft BI este formată din cele mai utilizate instrumente, ce sunt operate printr-o interfață cu adevărat intuitivă. Platforma este formată din următoarele trei soluții Microsoft SQL Server, Microsoft SharePoint și Microsoft Office.

Marele avantaj al platformei Microsoft Business Intelligence este că aproape toți oamenii știu cum să o folosească, îi cunosc componentele sale iar interfața sa nu reprezintă cu adevărat ceva nou pentru ei.

Platforma Microsoft Business Intelligence suportă raportarea, analiza și partajarea informațiilor cu alți utilizatori din întreaga organizație. Ceea ce este cu adevărat important pentru companiile de astăzi este timpul necesar pentru ca datele să se răspândească în întreaga organizație. Cu cât este mai scurtă perioada cu atât mai bine, iar soluția Microsoft este perfectă din acest punct de vedere.

Platforma Microsoft BI poate fi utilizată pentru: • Pregătirea tablourilor de bord. Tablourile de bord realizate cu soluția Microsoft sunt complet interactive; prin urmare, se poate vizualiza rapid fiecare zonă de date pentru a obține o altă vizualizare a acesteia și pentru a afla mai mult informații.

• Stimularea colaborării. Colaborarea eficientă este foarte importantă pentru toate organizațiile moderne și platforma Microsoft Business Intelligence suportă acest lucru cu capacități de comunicare bine dezvoltate. Aceasta permite tuturor

PowerPivot și SSAS sunt instrumentele actuale oferite de Microsoft pentru piața de BI. Microsoft nu are în prezent un produs BI dar oferă utilizatorilor un motiv pentru a face upgrade la MS Office 2010 sau Microsoft Office 2013 și promovează ideea de BI self-service. Suita de instrumente BI de la Microsoft se bazează pe mai multe instrumente, cum ar fi Excel 2013 și SQL Server Analysis Services dar și componente precum Microsoft PowerPivot. Pentru ca utilizatorii de MS Excel să poată folosi tablourile de bord în cadrul fișierelor Excel mai multe companii angajează consultanți BI. Backend-ul API al PowerPivot este disponibil numai împreună cu SharePoint și SQL Server. Acest lucru înseamnă că utilizatorii enterprise vor avea nevoie de servicii de consultanță pentru a integra toate aceste elemente.

Business Intelligence Semantic Model (BISM)

În plus față de Excel, SSAS, SSRS și PowerPivot, Microsoft a publicat o nouă direcție a tehnologiilor sale cu un nou model de BISM în Analysis Services, care va alimenta Crescent (viitoarea tehnologie oferită de Microsoft pentru vizualizarea datelor), precum și alte soluții de frontend cum ar fi tablourile de bord din Excel, serviciile de raportare si SharePoint Insights.

Atunci când un dezvoltator BI creează o aplicație ce are la bază PowerPivot, modelul încorporat în interiorul fișierului Excel este, de asemenea, un Business Intelligence Semantic Model. Atunci când fișierul Excel este încărcat în cadrul SharePoint, modelul este găzduit în interiorul unui server SSAS și deservește de asemenea

Objective C

jobs-cluj@yardi.com Yardi Romania

www.todaysoftmag.ro | nr. 24/Iunie, 2014

17

programare Instrumente Microsoft de Business Intelligence şi alte aplicații sau servicii cum ar fi Excel, regulilor, modelelor și tendințelor în cadrul Reporting Services, etc. . informațiilor. În acest fel utilizatorii pot determina de ce anumite lucruri se întâmData Integration sau ETL (Extract, Transplă și pot prezice ce se va întâmpla în viitor. form and Load - Extrage, Transformă şi SSAS include deja mai mulți algoritmi de Încarcă) data mining în pachetul său software. SSAS O organizație poate avea una sau mai de asemenea vă permite să definiți KPI-uri multe tipuri diferite de aplicații în funcție (Key Performance Indicators) pentru cubul de nevoile organizației. Când discutăm SSAS în scopul de a evalua performanțele despre proiectarea și dezvoltarea unui Data de afaceri în timp față de obiectivul stabilit, Warehouse ca parte integrantă a sistemului așa cum sunt reflectate în datele din cub. de Business Intelligence trebuie de ase- În mod normal raportarea în front-end menea să definim strategiile achiziției de este furnizată de datele oferite de cubul date de la toate sistemele sursă și integrarea din SSAS. Aceste cuburi consolidează acestora în Data Warehouse. datele și prin caracteristicile de gestionare a cache-ului optimizează rezultatele interoSQL Server Integration Services (SSIS) gării. Interogările predefinite au un timp de Microsoft SQL Server Integration răspuns mai rapid în comparație cu însuServices (SSIS) este o platformă ETL de marea acestora pentru fiecare interogare a integrare a datelor la nivel enterprise, o utilizatorilor. soluție de transformare a acestora precum și o componentă a platformei SQL Livrarea informațiilor Server. SSIS oferă posibilitatea de a avea Când cuburile SSAS sunt create și de o imagine coerentă și centralizată a date- asemenea populate cu datele din Data lor din diferite sisteme sursă și ajută la Warehouse, diferite instrumente de raporasigurarea securității datelor prin integra- tare pot fi folosite pentru a analiza datele rea, curățarea, profilarea și managementul din perspective sau dimensiuni diferite. acestora. SSIS oferă un cadru ETL rapid și flexibil și are capacități de transformare a SQL Server Reporting Services (SSRS) datelor în cadrul memoriei pentru scenaSQL oferă o gamă completă de rii de integrare a datelor extrem de rapide. instrumente și servicii pentru a ajuta la SSIS are mai multe componente interne crearea, implementarea și gestionarea pentru conectarea la surse standard de date rapoartelor în cadrul organizației. SSRS (RDBMS, FTP, Web Services, XML, CSV, include funcționalități de programare Excel, etc.) împreună cu un set bogat de care permit extinderea și personalizarea componente pentru transformarea și inte- funcționalităților de raportare. Puteți crea grarea datelor. rapoarte tabelare precum și diferite tipuri de rapoarte ce pot conține diagrame, graAnaliză fice sau hărți. În plus pot fi de asemenea Odată ce Data Warehouse-ul este creat create rapoarte având la bază indicatorii și componentele de integrare a datelor KPI. încarcă datele în Data Warehouse aveți PowerPivot, Power View, Excel și SSRS nevoie de crearea unei structuri multi- oferă utilizatorilor posibilitatea de a defini dimensionale OLAP numită cub. Sistemul și executa rapoarte ad-hoc având la bază Microsoft Business Intelligence poate faci- un model standard de date. Prin utilizarea lita SSAS (SQL Server Analysis Services) cubului SSAS utilizatorii au posibilitatea de să facă datele disponibile pentru analiză și a analiza rapoartele într-un mod flexibil, raportare. SSAS, ca un instrument princi- bazat pe măsurile și dimensiunile expuse. pal OLAP, oferă procesare analitică on-line (OLAP) precum și o funcționalitate de Platformă de găzduire şi colaborare data mining pentru aplicațiile de business SharePoint 2010 sau 2013 poate fi folointelligence. SSAS calculează, sintetizează sit ca instrument de colaborare, găzduire și stochează datele într-o formă foarte sau ca platformă de partajare a informației; comprimată, ceea ce poate conduce la o rapoartele și tablourile de bord vor fi toate raportare și o analiză predictivă extrem de lansate sau găzduite de către un portal rapidă și interactivă a datelor agregate din SharePoint. SharePoint este una dintre cele diferite perspective. mai importante produse pentru managementul conținutului în cadrul organizației Data Mining ce oferă posibilități de partajare, comuniMo d e l e l e d e d ata mining c re - care în cadrul rețelelor sociale, business ate în SSAS pot ajuta la identificarea intelligence, etc. .

18

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

Nu este obligatorie existența instrumentului SharePoint ca interfață pentru raportare, deoarece rapoartele SSRS pot fi la fel de simplu încărcate şi rulate de pe Report Server. Platforma de găzduire SharePoint oferă mai multe caracteristici precum Performance Point pentru a crea tablouri de bord atrăgătoare. Mai mult, servicii precum Excel PowerPivot pot fi utilizate pentru implementarea acestora în cadrul SharePoint cu scopul de a le pune la dispoziție şi altor utilizatori.

Caracteristicile de securitate încorporate în cadrul SharePoint asigură securitatea la nivel de roluri. SSAS permite, de asemenea, definirea nivelurilor de securitate la nivel de rol şi celulă. Aceste nivele de securitate la nivel de rol sau celulă vor reglementa accesul la date și va asigura că un anumit utilizator are drepturi de acces la informațiile potrivite atunci când este necesar.

Concluzii

Domeniul Business Intelligence este în continuă dezvoltare. Aceste tehnologii sunt la începutul unei lungi călătorii, într-o lume în care cheia succesului stă în capacitatea de a lua decizii mai bune şi într-un timp mult mai scurt decât competiția. Microsoft a făcut pasul pe acest drum și a creat un set de produse ce permit o nouă viziune asupra acestui domeniu. Aștept să văd ce se va întâmpla mai departe. Probabil că următorul pas va fi Artificial Business Intelligence.

Referințe: [1] Microsoft BI în cadrul Office 365 http://www.blue-granite.com/blog/bid/322825/ Is-Microsoft-Power-BI-a-Game-Changer [2] Pași necesari pentru instalarea modelului tabular AdventureWorks în SQL Server 2012 h t t p : / / w w w. s q l s e r v e r c e n t r a l . c o m / blogs/sherr y-lis-bi-corner/2014/04/30/ dax-2-installing-adventureworks-dw-tabularmodel-sql-server-2012/

management

programare

Adăugarea valorii în procesul de dezvoltare. Un exemplu simplu

A

nul trecut în noiembrie, Fundația Comunitară Oradea (www.fundatiacomunitaraoradea.ro) a oferit câteva burse pentru idei care pot fi puse în practică în decurs de un an pentru a face comunitatea în care locuim un loc mai bun. Eu am fost unul dintre puținii norocoși al cărui proiect a fost aprobat și doresc să vă împărtășesc modalitatea mea de gândire din perioada dezvoltării proiectului.

Alin Luncan alin.luncan@accesa.eu Software Engineer @ Accesa

Proiectul propus se referea la procesul de feedback continuu către și de la autoritățile locale cu privire la starea orașului, printr-o aplicație web special concepută în acest scop: schimbare prin tehnologie. În cele mai multe domenii, feedback-ul permanent este utilizat drept un indicator timpuriu al progresului și o modalitate de a urmări și identifica greșelile din proces, dar în cazul unui oraș problema este că odată ce este destul de mare, este aproape imposibil să urmărești opiniile tuturor într-un mod precis, fără investiții majore în indivizi pregătiți special. Exact aceasta a fost ideea din spatele proiectului: o modalitate de a aduna opiniile oamenilor și nemulțumirile legate de mediul urban în care locuiesc, cu un cost mic.

Cum am adăugat valoare ideii

Prima întrebare la care a trebuit să răspund pentru proiectul meu, înainte de a începe a fost: cum merg lucrurile în prezent? Spre surpriza mea, am descoperit faptul că orașul în care locuiesc (Oradea) avea deja un sistem pe website-ul local unde oamenii puteau adresa întrebări / cereri către autoritățile locale în legătură cu problemele orașului, printr-un simplu formular web cu vreo 12-15 spații pentru completare, în care se puteau introduce informații precum: nume, adresă, descriere, email, descrierea problemelor și/ sau alte date personale. Prin studierea rapoartelor anuale ale orașului, era clar că, în ciuda volumului de informații adunate acolo, nimeni nu se gândea la ceea ce era

Figura 1. Cursul aplicației când adaugi un element

www.todaysoftmag.ro | nr. 24/Iunie, 2014

19

programare Adăugarea valorii în procesul de dezvoltare. Un exemplu simplu evident: statistica.

Aceasta era prima oportunitate de a aduce valoare prin proiectul propus: de ce să nu iei datele introduse și să creezi din ele o valoare statistică, adică o hartă centralizată cu toate problemele orașului sortate pe diferite probleme sociale, departamente ale primăriei sau chiar pe cartiere/zone? Ce metodă este mai bună decât aceea de a lăsa utilizatorii să își adauge problemele direct pe hartă, cu un click sau o tastare?

Odată ce harta este creată, utilizatorii ar trebui să aibă posibilitatea de a o vizualiza și de a vota alte probleme, astfel încât chestiunile importante să aibă un scor mai mare și să poată avea prioritate.

După ce harta și sistemul de votare au fost realizate, proiectul mai trebuieceas să dispună de un canal de feedback între oficialii orașului și utilizatorii săi. Pentru a obține aceasta, pentru fiecare chestiune semnalată, aplicația web va arăta un sistem de apreciere atunci când oricare dintre părți dorește să închidă chestiunea raportată (marcând-o drept soluționată sau abandonând-o) cu o mică căsuță prin care utilizatorul și oficialul local vor putea să aprecieze experiența.

Pentru baza de utilizatori a comunității, aceasta ar însemna un mod de a aprecia departamentele locale și responsabilii lor, iar administratorilor locali le-ar oferi o modalitate de a filtra utilizatorii abuzivi sau necuviincioși; din punct de vedere statistic ar însemna un mod de a reprezenta pe un tabel satisfacția în legătură cu un anumit tip de problemă (de mediu, socială sau

20

legală), după cum este apreciată de către într-un instrument statistic. utilizatori. Astfel, oficialii orașului vor ști în ce să investească mai mult.

Concluzie

Pentru a crea o aplicație ușor de utilizat, cu UI care nu are nevoie de lămuriri și care să fie disponibilă pentru o gamă de dispozitive fără a modifica experiența de la un dispozitiv la altul, alegerea a fost o aplicație web construită cu ASP.NET MVC cu imaginea bazată pe Foundation 5 (puteți citi mai multe despre Foundation și MVC la http:// www.responsivemvc.net). Furnizorul de hartă ales a fost OpenStreetMap, deoarece și această aplicație va fi opensource după ce se va finaliza dezvoltarea sa, astfel încât să poată beneficia de ea și alte comunități.

După discuții cu funcționari și oficiali ai orașului, care lucrează cu oamenii, am descoperit că trebuie neapărat introduse următoarele funcționalități: confirmare e-mail, CAPTCHA, filtru pentru vulgaritate, un mod de a semnala utilizatorii abuzivi cu o regulă de trei încercări și suport pentru limbi străine. Toate aceste funcționalități sunt ușor de dezvoltat utilizând tehnologia selectată și poate fi ușor scalată atunci când se instalează. Aceasta e tot – o aplicație web simplă în MVC care aduce mai multă valoare statistică oficialilor orașului.

Deci, când dezvoltați următorul proiect, nu vă gândiți numai la sarcina la îndemână, ci gândiți în termeni de a adăuga valoare aplicației voastre, care poate transforma o mulțime de date introduse

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

testare

Modelarea obiectuală a testelor de Selenium

Î

n mod obișnuit, un test scris cu Selenium, Java și TestNG dorește să verifice corectitudinea elementelor unei pagini sau a unui modul de pe o pagină web. Abordarea clasică a acestui tip de teste o reprezintă folosirea unui număr ridicat de assert-uri, pentru compararea tuturor proprietăților dorite cu valorile așteptate ale acestora.

Corina Pip

corina.pip@betfair.ro Senior QA Engineer @ Betfair

Această abordare are multe neajunsuri, printre care dificila mentenanță a testelor, risipa de linii de cod, lipsa de inteligibilitate.

Pentru a evita aceste neajunsuri, o abordare diferită a acestui tip de teste o reprezintă conceperea testelor bazate pe compararea unor obiecte.

Studiu de caz Să presupunem că pagina sau modulul de testat reprezintă un coș de cumpărături, afișat pe un site de cumpărături. După ce s-au făcut cumpărături, coșul conține un număr de produse. Fiecare produs, așa cum este el afișat pe pagină, conține: o etichetă (label) cu numele său, o descriere, o imagine, prețul per produs, cantitatea din acest produs care a fost pusă în coș, prețul total pentru acest produs (prețul per produs * cantitatea), și un buton prin care produsul poate fi scos din coș. Pe lângă produsele cumpărate, coșul are: o etichetă proprie, prețul total al produselor, un link pentru continuarea cumpărăturilor și un buton pentru trecerea la pasul de plată. Pagina poate conține și alte module, cum ar fi un modul lateral cu sugestii pentru cumpărături ulterioare. Acesta ar fi un modul minimal, conținând doar câteva produse, pentru care s-ar afișa doar o etichetă cu numele, o imagine și prețul său.

Coșul de cumpărături ar arăta similar celui din imaginea următoare: După adăugarea tuturor produselor

dorite, coșul este pregătit pentru a se testa dacă informațiile pe care le afișează sunt corecte: produsele afișate sunt cele care au fost cumpărate, fiecare produs există în cantitatea dorită, detaliile de plată sunt corecte, etc. . În mod obișnuit, testul creat pentru verificarea tuturor acestor proprietăți ale coșului ar fi o înșiruire de assert-uri. Chiar dacă s-ar scrie o metodă separată de cea de test, doar pentru verificările prin assert-uri (urmând ca aceasta să fie folosită în mai multe teste), respectivele linii de cod tot ar fi dificil de menținut și nu ar fi eficient scrise.

Pentru a evita scrierea acestor teste stufoase și nu foarte prietenoase, testele pot fi gândite obiectual, după cum urmează.

Soluția Analiza În primul rând, trebuie luată în vedere imaginea de ansamblu. Ce reprezintă pagina

www.todaysoftmag.ro | nr. 24/Iunie, 2014

21

testare Modelarea obiectuală a testelor de Selenium cu coșul de cumpărături? O colecție de obiecte de diverse tipuri.

Urmărind structura începând de la complex la simplu, se poate observa că cel mai complex obiect (cel care le conține pe restul), este coșul de cumpărături. El are ca proprietăți: eticheta, lista de produse cumpărate, un link, un buton și un modul lateral.

Dintre aceste proprietăți, eticheta este reprezentată în Java de un String, din punct de vedere al testului. Prețul poate fi reprezentat de asemenea de un String. Lista produselor reprezintă de fapt o listă conținând obiecte de tipul ‘produs’. Linkul afișat este și el un obiect, la fel și butonul sau modulul lateral. În urma identificării obiectelor de la cel mai de sus nivel, se poate descrie obiectul ‘ShoppingCart’ după cum urmează:

}

După această logică, se pot identifica toate proprietățile tuturor obiectelor afișate pe pagină și se pot construi aceste obiecte, ,,spărgându”-le până se descompun în proprietăți care sunt obiecte sau primitive Java.

Construirea conținutului ‘expected’

După terminarea structurării coșului de cumpărături în obiecte, trebuie înțeles cum vor fi folosite acestea în teste. Prima parte a testului (sau partea care se realizează înaintea testului) o reprezintă adăugarea produselor în coș. Testul trebuie doar să verifice că în coș se află produsele corecte.

Pentru a construi obiectul ‘coș de cumpărături’ la care se public class ShoppingCart { private String title; așteaptă testul (conținutul ‘expected’), trebuie creat constructorul private List<Product> productList; care atribuie tuturor proprietăților sale valori de tipul proprietăților private String totalPrice; private Button paymentButton; respective. Astfel, se pasează constructorului parametri care coresprivate Link shopMoreLink; pund proprietăților obiectului, având tipul acestor proprietăți (de private SuggestionsModule suggestionsModule; } exemplu pentru o proprietate de tip String se pasează în constructor un String, pentru un int se pasează un parametru int).

Analizând în continuare în adâncime structura obiectelor, se începând de la cel mai simplu obiect, se creează constructorii. observă că: un produs conține (are ca proprietăți) – o ‘imagine’ Pentru Link: (adică un alt tip de obiect), o etichetă care-i reprezintă numele public Link(String linkLabel, String linkURL) { (un String), un text descriptiv (un alt String), prețul per obiect this.linkLabel = linkLabel; (un String), cantitatea (un String), prețul total al produsului (un } this.linkURL = linkURL; String), și un buton (care reprezintă un obiect care a fost deja menționat ca proprietate a coșului). Reprezentarea obiectuală a Aici se poate observa că – obiectul Link are o etichetă și un produsului poate fi făcută, conform analizei, după cum urmează: URL, ambele de tip String, a căror valoarea se instanțiază cu valorile primite din parametrii constructorului. public class Product { private String productLabel; Pentru produs se generează următorul constructor: private private private private private private

String productDescription; Image image; String pricePerItem; String quantity; String totalPricePerProduct; Button removeButton;

Linkul menționat în cadrului coșului poate conține, ca un set minimal de proprietăți, o etichetă (un String, textul pe care-l vede userul afișat) și URL-ul care se deschide prin apăsarea linkului (un String). Reprezentarea sa obiectuală poate fi făcută astfel:

public Product(String productLabel, String productDescription, Image image, String pricePerItem, String quantity, String totalPricePerProduct, Button removeButton) { this.productLabel = productLabel; this.productDescription = productDescription; this.image = image; this.pricePerItem = pricePerItem; this.quantity = quantity; this.totalPricePerProduct = totalPricePerProduct; this.removeButton = removeButton; }

public class Link { private String linkLabel; private String linkURL;

public ShoppingCart(String title, List<Product> productList, String totalPrice, Button paymentButton,

}

22

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

Pentru coșul de cumpărături constructorul are forma:

TODAY SOFTWARE MAGAZINE Link shopMoreLink, SuggestionsModule suggestionsModule) { this.title = title; this.productList = productList; this.totalPrice = totalPrice; this.paymentButton = paymentButton; this.shopMoreLink = shopMoreLink; this.suggestionsModule = suggestionsModule; }

torul său specific, iar lista de produse, butonul și linkul au fost exemplificate deasupra liniei în care se construiește obiectul ‘coș de cumpărături’.

public static final Product LATTE_MACHIATTO_2 = new Product(“Latte Machiato”, “Classic latte machiato with a dash of cocoa on top”, Image.IMAGE_LATTE_MACHIATO, “5 Ron”, “2”, “10 RON”, Button.REMOVE_PRODUCT); → aici, obiectele de tip imagine

public Link(WebElement element) { this.linkLabel = element.getText(); this.linkURL = element.getAttribute(“href”); }

Construirea conținutului ‘actual’

Pentru construirea obiectului ‘actual’, adică pentru citirea proprietăților obiectelor direct de pe pagina unde acestea sunt Pe baza constructorului, se vor genera următoarele obiecte afișate, se va crea un nou constructor în fiecare obiect, care ia ca (cele car vor servi drept ‘expected’), pasând constructorului niște parametri fie un webElement, fie o listă de webElemente, atâtea valori având tipul parametrilor cărora li se vor atribui acestea: câte sunt necesare pentru generarea proprietăților obiectului.

• linkul de continuare a cumpărăturilor: WebElementele reprezintă descrierea elementelor HTML în formatul specific Selenium. public static final Link CONTINUE_SHOPPING_LINK = new Link(“Continue shopping”, Ca exemplu, pentru obiectul link: cele două proprietăți, “http://continue.shopping.com”); eticheta și URL-ul asociate se pot deduce dintr-un singur webEle ment. Un element de tip link este reprezentat din punct de vedere • butonul pentru avansarea la faza plății: al HTML-ului, ca un tag <a>, având un atribut ‘href ’ (prin extragerea căruia se identifică URL-ul). Apelând metoda getText() a public static final Button GO_TO_PAYMENT_BUTTON = librăriei de Selenium direct pe elementul ‘a’, se obține valoarea new Button(“Proceed to payment”, “http://some.url.com”); etichetei. Astfel, constructorul bazat pe webElement este descris

mai jos, și instanțiază proprietățile obiectului extrăgându-le din • produsul 1 din coș: elementul HTML corespunzător:

și buton au fost construite folosind constructorii specifici acelor obiecte • produsul 2 din coș:

public static final Product CHOCO_FRAPPE_3 = new Product(“Choco-whip Frappe”, “Frappe with a twist of whipped cream and chocolate syrup”, Image.IMAGE_CHOCO_FRAPPE, “5 Ron”, “3”, “15 RON”, Button.REMOVE_PRODUCT); → aici, obiectele de tip imagine

și buton au fost construite folosind constructorii specifici acelor obiecte • produsul 3 din coș:

public static final Product CARAMEL_MOCCACHINO_1 = new Product(“Caramel Moccachino”, “Your favourite moccachino with a refreshing taste of caramel”, Image.IMAGE_CARAMEL_MOCCACHINO, “5 Ron”, “1”, “5 RON”, Button.REMOVE_PRODUCT); → aici, obiectele de tip imagine

și buton au fost construite folosind constructorii specifici acelor obiecte • coșul de cumpărături:

public static final ShoppingCart SHOPPING_CART = new ShoppingCart(“My Shopping Cart”, ImmutableList.of(Product.LATTE_MACHIATTO_2, Product.CHOCO_FRAPPE_3, Product.CARAMEL_MOCCACHINO_1), ”30 RON”, Button.GO_TO_PAYMENT_BUTTON, Link.CONTINUE_SHOPPING_LINK, SuggestionsModule.SUGGESTIONS_MODULE); → aici, obiec-

tul de tip ‘modul de sugestie’ a fost construit folosind construc-

Pentru construirea obiectului ‘actual’ corespunzător unui produs, în funcție de câte webElemente sunt necesare pentru obținerea tuturor proprietăților, se va defini un constructor care să ia ca parametru fie un webElement, fie o listă de webElemente.

Presupunând că se folosește un singur element, constructorul va arăta astfel (ca exemplu): public Product(WebElement element) { this.productLabel = element.findElement( By.cssSelector(someSelectorHere)).getText(); this.productDescription = element.findElement( By.cssSelector(someOtherSelectorHere)).getText(); this.image = new Image(element); this.pricePerItem = element.findElement( By.cssSelector(anotherSelectorHere)).getText(); this.quantity = element.findElement( By.cssSelector(yetAnotherSelectorHere)).getText(); this.totalPricePerProduct = element.findElement( By.cssSelector(aSelectorHere)).getText(); this.removeButton = new Button(element); }

Se poate observa că în cazul produsului, pentru generarea unor proprietăți s-au apelat constructorii obiectelor de tipul corespunzător, mai exact constructorii care iau ca parametri tot webElemente. Practic, orice constructor bazat pe webElemente apelează doar constructori cu parametri de tip webElemente pentru inițializarea proprietăților sale. Proprietățile rămase se instanțiază în funcție de parametrul dat constructorului. De exemplu, pentru etichetă (productLabel), se apelează metoda din Selenium getText() pe un element relativ la elementul care este pasat în constructor.

O dată cu definirea tuturor constructorilor bazați pe webElemente, se poate genera și constructorul pentru cel mai complex dintre ele, coșul de cumpărături: public ShoppingCart(List<WebElement> webElementList) { this.title = webElementList.get(0).getText; www.todaysoftmag.ro | nr. 24/Iunie, 2014

23

testare Modelarea obiectuală a testelor de Selenium this.productList = productList; this.totalPrice = webElementList.get(2).getText; this.paymentButton = new Button(webElementList. get(3)); this.shopMoreLink = new Link(webElementList.get(4)); this.suggestionsModule = suggestionsModule; }

Astfel, dacă se presupune că site-ul de cumpărături este disponibil în 20 de limbi, testul care verifică afișarea corectă a coșului de cumpărături tradus va avea un număr redus de linii de cod și va fi scris o singură dată, fiind însă rulat pe toate limbile existente.

Testul

Modul de scriere a testelor prin compararea obiectelor generate din webElemente cu cele generate din obiecte și primitive are numeroase beneficii. În primul rând, testul este unul foarte scurt, cu un scop bine determinat, făcând un singur lucru: compararea valorilor ‘actual’ cu cele ‘expected’. Testul în sine nu necesită multă mentenanță, deoarece în urma schimbărilor în pagina accesată de user-i, trebuie schimbat nu testul, ci modul în care se generează proprietățile comparate. Schimbarea valorii unui label de pe pagină necesită doar schimbarea valorii ‘expected’ corespunzătoare unui obiect, această schimbare făcându-se într-un singur loc, dar de ea beneficiind un număr mare de teste. Astfel se separă partea de test de partea de generare a valorilor așteptate.

Un alt beneficiu îl reprezintă structura compactă a testului, nefiind necesară scrierea unui număr ridicat de assert-uri, sau pasarea unui număr mare de parametri unei metode care trebuie să verifice acele valori. În locul acelor mulți parametri, se pasează direct obiectul care conține proprietățile de comparat.

În urma definirii obiectelor și constructorilor, se trece la pasul de scriere a testelor. Cerința testului era de a compara coșul de cumpărături cu unul ‘expected’, adică compararea tuturor proprietăților coșului de cumpărături cu cele ale coșului așteptat.

Aceste proprietăți sunt la rândul lor obiecte, deci și proprietățile lor trebuie comparate cu proprietățile unor obiecte așteptate.

Deoarece valorile expected s-au construit prin intermediul primului tip de constructor (cel cu parametri având tipul proprietăților care se instanțiază) și avem un constructor pentru generarea conținutului ‘actual’ (prin interpretarea proprietăților unor webElemente), testul care trebuie scris conține un singur assert. Acesta va compara proprietățile ‘expected’ cu cele ‘actual’ prin simpla comparare a celor două obiecte. Ar trebui menționat că, o dată cu definirea obiectelor, trebuie implementată în cadrul fiecăruia și metoda de equals() (cea care verifică dacă două obiecte sunt egale).

Astfel, testul poate fi scris după cum urmează: @Test public void checkMyShoppingCart() { assertEquals(new ShoppingCart(theListOfWebElements), SHOPPING_CART, “There was an incorrect value in the shopping cart”); }

Bineînțeles, acest test nu descrie pașii necesari construirii coșului de cumpărături (navigarea pe site-ul de cumpărături și adăugarea produselor). Acești pași pot fi făcuți în cadrul testului dacă e necesar, sau în metode de tip ‘@Before’. În cazul în care se dorește, de exemplu, testarea aceluiași conținut dar pe limbi diferite, se poate pasa un dataProvider testului, în care să se țină un parametru folosit în test pentru schimbarea limbii, precum și valoarea ‘expected’ a coșului pentru limba respectivă. În acest caz, testul va deveni următorul: @Test(dataProvider = “theDataProvider”) public void checkMyShoppingCart( String theLanguage, ShoppingCart actualShoppingCartValuePerLanguage) { changeTheLanguageOnTheSite(theLanguage); assertEquals(new ShoppingCart( theListOfWebElements), actualShoppingCartValuePerLanguage, “There was an incorrect value in the shopping cart”); }

Dataprovider-ul folosit în acest test va arăta ca în exemplul de mai jos: @DataProvider public Object[][] theDataProvider() { return new Object[][]{ { “english”, SHOPPING_CART}, { “german”, SHOPPING_CART_GERMAN }, { “spanish”, SHOPPING_CART_SPANISH} }; }

24

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

Beneficii

management

TODAY SOFTWARE MAGAZINE

Riscul de a nu avea riscuri

M

anagementul riscului este un termen utilizat pe scară largă în lumea software engineering de astăzi. Aproape fiecare proiect suferă amenințări care îi pot afecta într-un mod negativ costul, termenii de livrare sau calitatea. Conform unui studiu IBM doar 40 % din proiecte ajung să își atingă obiectivele de buget, termenii de livrare și de calitate. Alte analize au concluzionat că între 65 și 80 % din proiectele IT nu reușesc să își atingă obiectivele, și ajung să coste în mod semnificativ mai mult decât a fost planificat sau sunt livrate cu întârziere.

Pentru a evita deviațiile critice la costul, momentul cel mai probabil în care riscul termenii de livrare sau calitatea proiectuar avea un impact asupra obiectivelor lui, este important ca fiecare manager de proiectului. proiect și nu numai, să recunoască faptul că există amenințări, că lucrurile ar Diferența între risc și problemă putea merge prost, și în consecință să fie • Riscul este un eveniment viitor care pregătiți să acționeze, fie prin reducerea poate avea un impact negativ asupra probabilității potențialei amenințări fie obiectivelor proiectului. Aspectul cheie prin reducerea pierderilor în cazul în care este acela că evenimentul de risc nu s-a aceasta se va materializa. întâmplat încă și s-ar putea să nici nu se întâmple.

Ce este un risc?

• Problema este un rezultat al unui Un risc reprezintă o potențială proeveniment care se întâmplă chiar acum blemă, un eveniment incert care, în cazul sau s-a întâmplat deja. O problemă are în care se produce, va avea un efect asupra un impact negativ asupra proiectului. obiectivelor proiectului. Efectul evenimenO problemă nu este un risc, dar un risc tului ar putea să fie benefic sau dăunător. poate deveni o problemă atunci când nu Când discutăm despre managementul risîi mai putem evita impactul. cului, care include atât efectele pozitive, cât și cele negative ale unui eveniment incert, Putem diferenția patru tipuri de riscuri: managerul de proiect trebuie să diferențieze • Riscuri de proiect - cele care între amenințări și oportunități. În articoamenință planul de proiect; acestea sunt lul curent, ne vom concentra doar asupra în mare parte legate de potențialele proriscurilor care amenință obiectivele probleme legate de buget, termeni de livrare, iectului, adică a celor care au un impact personal, resurse, cerințe funcționale, negativ asupra obiectivelor de succes ale client; acestuia.

• Riscurile tehnice - cele care amenință Orice risc implică trei atribute care trecalitatea și posibilitatea software-ului de buie să fie cuantificate : a fi produs; acestea sunt în mare parte • Probabilitatea ca riscul să se întâmlegate de potențialele probleme legate ple: de obicei exprimată în procente sau de proiectare, implementare, interfață, categorii: mica, medie, mare. verificare, întreținere. Ambiguitatea • Impactul: pierderea care va avea loc cerințelor, incertitudinile tehnice, uzura în cazul în care riscul devine o realitate, morală tehnică, tehnologia „de vârf ” poate fi exprimat prin categorii: scăzut, sunt factorii de risc in această categorie. mediu, ridicat.

• Riscurile de produs - cele care sunt • Proximitatea este exprimată în terlegate de consecințele potențialelor promeni de timp (data cea mai probabilă bleme care privesc produsul (de exemplu, la care evenimentul ar putea avea loc) riscuri de securitate). Aceste riscuri pot sau categorii (de exemplu iminentă, pe fi legate de utilizarea incorectă a protermen scurt, pe termen lung), având în dusului, sau defecte ale produsului care vedere intervalul de timp din momenafectează rezultatele prin erori de calcul tul în care riscul este identificat până în sau logice.

• Riscurile de business - sunt cele care amenință viabilitatea sau succesul proiectului; acestea privesc în mare parte potențialele probleme legate de piață, strategia companiei, forței de vânzare, management.

Activitățile de gestionare a riscurilor sunt în responsabilitatea managerului de proiect, dar identificarea lor este responsabilitatea fiecăruia și toate aceste activități trebuie să fie efectuate într-un mod proactiv. Obiectivul managementului riscurilor este de a oferi managerului de proiect cunoștințele și instrumentele necesare pentru a fi în măsură să facă față oricăror evenimente care ar putea avea un impact negativ asupra obiectivelor proiectului. Multe dintre problemele care apar în dezvoltarea de software au fost mai întâi cunoscute ca riscuri de către cineva din echipa de proiect. Identificate la timp, riscurile pot fi evitate, negate sau se poate acționa în vederea reducerii impactului acestora. Gestionarea proactivă a riscurilor implică stabilirea unei strategii care previne materializarea riscului și transformarea lui într-o problemă sau îi limitează impactul în cazul în care acesta se materializează. Strategia de gestionare a riscurilor include, de obicei, reducerea efectului negativ sau a probabilității de apariție a riscului, transferul amenințării către o altă parte, evitarea amenințării sau chiar acceptarea ei.

Paradigma managementului riscurilor

În timpul fazei de inițiere a proiectului și apoi în mod continuu în timpul ciclului de viață al întregului proiect, riscurile trebuie să fie identificate, analizate și ulterior trebuie planificate măsuri adecvate, iar

www.todaysoftmag.ro | nr. 24/Iunie, 2014

25

management Riscul de a nu avea riscuri apoi evaluate și puse în aplicare cand este Odată identificate, riscurile trebuie să nevoie. În derularea acestor pași, manage- fie înregistrate, comunicate, împărtășite rul de proiect este asistat de către părțile prin intermediul unui jurnal de risc (risk interesate în succesul proiectului. log) sau orice alt instrument care permite înregistrarea riscurilor.

Identificarea

O mare parte din riscurile unui proiect pot fi identificate în faza de inițiere a proiectului, unele dintre ele chiar în faza de ofertare. Există o serie de instrumente și modalități care îl pot ajuta pe managerul de proiect pentru a efectua în mod eficient această activitate. Se pot utiliza liste de verificare sau chestionare unde răspunsurile la întrebări vor dezvălui riscuri. Software Engineering Institute (SEI) a dezvoltat o taxonomie a riscurilor legate de dezvoltarea de software și un chestionar pe baza acestei taxonomii (TBQ-Taxonomy Based Questionnaire), care oferă condițiile pentru identificarea, organizarea și studierea diferitelor aspecte ale riscurilor în dezvoltarea de software.

Analiza Odată ce riscul a fost identificat, managerul de proiect (sau cineva care acționează în calitate de manager de risc pentru proiect) va evalua probabilitatea sa, impactul și proximitatea. În unele cazuri, acest pas necesită și o analiză de impact, care va lua în considerare toate obiectivele ce pot fi afectate de posibila apariție a riscului. În mod ideal, managerul de proiect ar trebui să determine și valoarea riscului, adică costul problemei în cazul în care riscul se materializează. Valoarea riscului = probabilitate x costurile pentru proiect (în cazul în care s-ar produce riscul). În absența cifrelor o clasificare relativă a valorii riscului va fi de asemenea utilă.

Managerul de proiect trebuie să se asigure că răspunderea pentru toate riscurile importante este atribuită în mod explicit unei persoane (risk owner). Aceasta va fi persoana cu profilul cel mai potrivit pentru a gestiona riscul respectiv în intervalul în care este posibil să se materializeze. Această responsabilitate poate fi atribuită unei persoane care nu este implicată direct în proiect, cum ar fi managerul de unit/departament, de vânzări, de infrastructură, etc..

Planificarea Cu toate acestea, riscurile există și apar de-a lungul întregului ciclu de viață al unui proiect; de aceea, ele trebuie să fie identificate în mod continuu, nu doar în faza de start-up. Identificarea riscurilor trebuie să facă parte din rutina proiectului. Este responsabilitatea profesională și morală a fiecărui membru al echipei să raporteze riscuri de îndată ce sunt identificate, chiar dacă acestea par să aibă o importanță redusă sau sună atipic.

26

strategia primară, una proactivă, care gestionează riscurile într-o manieră controlată și eficientă. Este de cele mai multe ori realizată printr-o atenuare, care include, de asemenea și un plan de intervenție în cazul în care riscul se produce.

2. Evitarea riscului - prespune eliminarea completă a riscului. Acest lucru înseamnă că nu se vor desfășura activitățile ce sunt purtătoare de risc.

Evitarea riscurilor înseamnă, de asemenea, a pierde potențialul câștig care ar fi putut fi obținut în cazul în care riscul ar fi fost acceptat.

3. Transferul riscului - presupune transferarea sau distriburea impactului riscului cu un terț, de exemplu cu compania de asigurări.

4. Rezerva riscului, cunoscut de asemenea și sub numele de plan de urgență, oferă o alternativă pentru situația în care riscul se va materializa.

5. Acceptarea riscului - presupune că nici un răspuns nu va fi implementat, riscul este lăsat să se producă.

Măsurile definite pentru a răspunde la riscuri generează costuri suplimentare pentru proiect. Măsurile de atenuare a riscului sunt eficiente atunci când câștigul obținut prin reducerea riscului depășește pierderea potențială care ar fi fost înregistrată în cazul în care riscul s-ar fi materializat.

Altfel spus, managementul riscului îl provoacă pe project manager să decidă cât de mult timp, bani, efort este dispus să investeasca pentru rezolvarea unei probleme care ar putea să nu apară niciodată.

O practică înțeleptă în managementul de proiect este aceea de a lua întotdeauna în considerare un buget de risc, atunci când se calculează bugetul inițial al proiectului.

Odată ce probabilitatea, impactul și proximitatea unui risc au fost evaluate, managerul de proiect va colabora cu părțile interesate pentru a defini și a planifica măsuri adecvate gestionării riscului.

Măsurile pe care un manager de proiect le poate lua în considerare atunci când va răspunde la un risc sunt: 1. Atenu are a r i s c u lu i - pre s u - Monitorizarea pune reducerea impactului și / sau a Riscurile trebuie să fie monitorizate probabilității de apariție a riscului. Este și revizuite periodic pentru a stabili dacă

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE răspunsurile planificate mai sunt sau nu de actualitate și dacă e necesar a fi planificate măsuri noi. În timpul ciclului de viață al unui proiect pot fi identificate sute de riscuri. Este imposibil ca toate acestea să poată fi monitorizate în mod regulat. De aceea, recomandarea este ca doar primele 10 riscuri (luând în considerare prioritățile stabilite) să fie monitorizate regulat. O matrice de Impact/Probabilitate poate ajuta managerul de proiect să decidă care dintre riscuri au nevoie de atenția lui.

Pentru a implementa cu succes un proiect, managerul de proiect trebuie să identifice și să își concentreze atenția asupra riscurilor moderate și extreme.

Riscurile din colțul dreapta sus (de mare impact și cu grad ridicat de probabilitate) sunt de importanță crucială, iar managerul de proiect trebuie să le acorde o atenție deosebită. Este posibil ca la un moment dat un risc moderat să necesite mai multă atenție decât unul extrem, a cărui proximitate este pe termen lung, din motiv că cel moderat este posibil să se materializeze în curând.

Riscurile cu probabilitate și impact redus pot fi de cele mai multe ori ignorate.

Corectarea / Ajustarea Deoarece contextul proiectului se poate schimba, răspunsurile deja planificate pentru un anumit risc s-ar putea să nu mai fie adecvate și prin urmare sunt necesare corecții la planurile și acțiunile de diminuare a riscului. Uneori chiar riscul în sine trebuie să fie re-analizat.

Riscul de a nu avea riscuri

Identificarea și gestionarea riscurilor este esența supraviețuirii și dezvoltării afacerii. În cele mai multe dintre companiile românești de IT, practicile de gestionare a riscurilor nu sunt formalizate iar acest lucru devine un risc în sine. Cu toate că managerul de proiect identifică riscurile pe baza experiențelor anterioare, a lecțiilor învățate sau doar pe bază de intuiție,

riscurile sunt rareori gestionate sau monitorizate în mod corespunzător. Iar atunci când lucrurile pot merge prost ele vor merge prost (dacă nu se vor lua măsuri).

De câte ori ați auzit expresia: „Știam eu că asta se va întâmpla”, după ce s-a întâmplat ceva rău? Și aceasta se datorează faptului că o persoană din echipa a intuit că ceva poate merge prost, dar nu a acționat pentru a preveni acel eveniment. Faptul că alegem să comunicăm și celorlalți îngrijorarea noastră și acționăm pentru a evita riscul este un semn de maturitate și arată că ne pasă. Este responsabilitatea noastră să împărtășim riscurile cu persoana care poate acționa pentru a le evita sau pentru a le diminua impactul. Fiecare dintre noi are propria sa perspectivă, cunoaștere și înțelegere a ceea ce se întâmplă, vede lucruri pe care alții nu le văd sau nu le pot vedea. Se spune că, în medie, fiecare dintre noi identificăm aproximativ cinci riscuri pe zi, dar, de obicei, le uităm la scurt timp după aceea dacă nu le notăm.

Având în vedere contextul companiei în care lucrați și aspectele prezentate în acest articol prevedeți vreun risc datorat faptului că ”nu există” riscuri? Sau altfel spus: „Având în vedere că nu există implementat un proces de management al riscului există riscul ca afacerea să eșueze? Sau de a pierde proiecte? Sau de a pierde angajați?

Este o provocare pentru fiecare dintre noi de a identifica și de a reacționa la aceste riscuri. Unii dintre noi pot identifica aceste riscuri, alții pot acționa pentru a răspunde la ele. Cu toate acestea, o gestionare eficientă a riscurilor începe de la nivelul de top-management, a board-ului, unde trebuie să existe claritate cu privire la strategia de risc și de guvernare, o înțelegerea corectă și responsabilități clare privind managementul riscului la nivel de board și la nivel executiv.

La ISDC, noi am înțeles importanța managementului riscurilor ca și proces, ca și mentalitate, ca și atitudine față de riscuri și acționăm continuu pentru eliminarea „riscului de a nu avea riscuri” prin : • Implementarea unui proces de management al riscului eficient la nivel de organizație. Acesta include politici, proceduri, instrumente și responsabilități implicate în activitățile de gestionare a riscurilor; • Implementarea unei aplicații dezvoltate intern care încurajează și sprijină identificarea riscurilor, urmărirea și analiza lor; • Încurajarea comunicării deschise privind identificarea riscurilor;

• Sesiuni de training de management al riscurilor pentru project manageri, șefi de echipă (team leader-i) și colegii din departamentul de asigurare a calității; • Analiza riscurilor din proiecte (număr de riscuri, categorii de riscuri, valoarea cumulată a riscurilor). Astfel suntem capabili să determinăm categoriile care determină cele mai multe riscuri, să identificăm și să înțelegem riscurile „care contează” și avem astfel posibilitatea de a acționa rapid pentru acoperirea lor.

În scopul facilitării procesului de management al riscurilor, în ISDC am dezvoltat propriul nostru sistem Risk Manager. Risk Manager este o aplicație web care permite înregistrarea riscurilor, urmărirea și analiza lor. Matricea Probabilitate / Impact este prezentată foarte vizual, pe un ecran în care riscurile sunt ușor de urmărit în funcție de probabilitatea, proximitatea și impactul lor.

Risk Manager poate fi accesat de către toate părțile interesate pe baza permisiunilor și drepturilor acordate anterior.

Următorul pas este de a încorpora partea de Business Intelligence și Analytics pentru a avea o raportare eficientă a riscurilor, o analiză aprofundată a datelor și tablouri de bord (dashboards) care afișează indicatori cheie ai riscurilor.

Toate aceste activități au fost și sunt în continuare de succes datorită programului ISDC de îmbunătățire continuă și de contribuția valoroasă a lui Peter Leeson (www.qpit.net). Peter ne-a inspirat prin sesiunile sale de training, evaluările CMMI pe care le-a condus, consultanța și suportul acordat de-a lungul ultimilor patru ani.

Putem concluziona că managementul riscului este un element esențial al succesului unei organizații. Secretul unui proiect de succes este în strânsă legătură cu capacitatea de asumare a riscurilor, gestionarea corectă a acestora și comunicarea rezultatelor. Totodată, împărtășirea experienței la nivel de organizație va oferi proiectelor viitoare o bibliotecă de bune practici la care pot apela atunci când va fi nevoie.

Ramona Muntean

Ramona.Muntean@isdc.eu Measurements & Best Practices Specialist @ ISDC

www.todaysoftmag.ro | nr. 24/Iunie, 2014

27

management

Inițierea unui produs

C

ât de repede ai putea crea un produs software începând de la o idee? Acesta este scopul prezentului articol. Vă vom prezenta etapele pe care le parcurge un concept o dată cu ideea inițială până la a găsi valoarea esențială a ideii și apoi de a o pune în mâinile utilizatorilor cât mai repede posibil.

Ideea ta Alexandru Bolboaca

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

Pentru a începe, trebuie să ai o idee clară în legătură cu produsul. Creează o listă simplă care să conțină puncte ale conceptului, valorile esențiale ale produsului și modul cum va fi capitalizat. Dar cum ai putea înțelege dacă este sau nu folositor?

Feedback – ingredientul cheie

Adrian Bolboaca

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

28

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

Toți avem idei, dar dacă am avea un sistem prin care să le punem în practică?

Principalul instrument pentru a înțelege dacă ideea ta poate fi transformată în bani este obținerea feedback-ului de la alții. Mai întâi de la prietenii tăi și familie. Apoi poți începe cu oamenii de pe la adunări publice, din comunități. Oriunde mergi, prezintă-le oamenilor ideea ta și notează-ți ceea ce le place, ce îi îngrijorează.

Produsul minim viabil (Minimum Viable Product)

Conceptul de Produs Minim Viabil (MVP) provine din lumea Lean Startup.

Acesta descrie necesarul minim al ideii esențiale de afacere care poate fi scoasă pe piață și pusă în mâinile utilizatorilor reali.

Produsul trebuie să fie util, funcțional și în mod ideal să aibă un impact.

Personaje

Înainte de a te ocupa de complexitatea modului în care produsul funcționează, trebuie să începi prin a înțelege utilizatorii și nevoile acestora. Pentru aceasta, recomandăm de obicei crearea personajelor.

Un personaj este o persoană fictivă care va avea toate caracteristicile unei persoane reale: nume, vârstă, sex, interese, ocupație și așa mai departe. Mai mult, personajul va Ideea ta structurată avea atât de multe detalii câte sunt necesare Ia fiecare element de la fiecare per- pentru a înțelege cum va interacționa cu soană cu care ai interacționat și gândește-te noul produs. bine dacă ar putea fi folosit pentru a-ți îmbunătăți produsul. Trebuie să fii foarte Teme deschis când filtrezi aceste idei. Acest proDe la ideea ta inițială, condimentată dus poate fi ideea ta, dar tu nu ești unicul cu sugestiile venite din partea prieteutilizator. După acest proces, vei avea o idee nilor, familiei și a altor cunoștințe, poți structurată cu care vei putea să continui avea o idee despre cum ar trebui să prin următorii pași. arate funcționalitățile principale. Aceste funcționalități principale sunt numite

TODAY SOFTWARE MAGAZINE teme. Ar trebui să existe numai câteva.

Aceste teme ar trebui să fie independente unele de altele. O temă este ca o funcționalitate principală a aplicației. [http://www.mountaingoatsoftware.com/ blog/stories-epics-and-themes]

Epopeea Când înțelegi care sunt direcțiile de bază ale dezvoltării aplicației tale, poți începe să despici aceste teme în mănunchiuri mai mici. Scopul principal al despicării lor este faptul că vrem să avem un feedback rapid de la utilizatori reali. Cu cât este mai mică funcționalitatea, cu atât mai rapid o putem valida prin utilizatori reali. În acest fel putem afla ce părere au cu adevărat utilizatorii despre aplicație. O epopee ar trebui livrată utilizatorului real în 1 – 2 săptămâni.

User Stories Aceste epopei sunt din nou despicate în mai multe user stories (scenarii utilizator).

O poveste utilizator ar trebui finalizată, în sensul că ar putea fi adăugată mediului de producție în 1-3 zile. De obicei, un user story și o epopee sunt scrise în următorul format „Ca <personaj> aș dori să <nevoia utilizatorului> astfel încât <un motiv/ valoare a afacerii>”. „În calitate de Charlotte, aș dori să pot transmite cu ușurință preferințele mele culinare prietenilor mei astfel încât ei să poată găti cina pentru noi înainte ca să ajung la locuința lor.” În principiu, Charlotte are nevoie de o metodă de a transmite ceea ce dorește să mănânce în acel moment și știe că prietenii ei sunt bucuroși să gătească orice. Aceasta ar fi o aplicație extrem de utilă pentru gurmanzii din întreaga lume.

Harta user stories Ceea ce am dori să facem este să realizăm o hartă a acestor user stories cu epopeile și temele. Partea de sus este înțelegerea generică a produsului, prezentată drept teme și/sau epopei. Partea de jos este reprezentată de user stories, care adaugă detalii fiecărei teme sau epopei.

Această tehnică este extrem de folositoare pentru a adăuga context la fiecare user story. Fiecare persoană implicată în producerea acestui software va înțelege întotdeauna „de ce-urile și „cum-urile” fiecărui scenariu, user story.

O opțiune bună ar fi să alegi vreo două user stories din fiecare epopee, astfel încât să poți avea un feedback mai rapid cu privire la fiecare dintre ideile tale. Deci, în principiu, ar trebui să tragi o linie pe harta ta și tot ce se află deasupra liniei va fi dezvoltat în perioada următoare (1-2 săptămâni, poate), iar restul va aștepta un pic mai mult. Scenariile utilizator pe care vei vrea să le alegi sunt acelea care au cea mai mare valoare de business.

Nu uita că fiecare dintre user stories este centrată pe utilizator, pentru că tu vrei să înțelegi cum vor folosi utilizatorii acest produs și vrei să îmbunătățești cât de mult poți experiența utilizatorului1.

http://commons.wikimedia.org/wiki/

Trebuie să pui în balanță cât costă să produci această primă incrementare și care este bugetul tău. Tu vrei să furnizezi prima incrementare cât de repede poți, pentru că s-ar putea să poți obține un profit rapid, dacă ideea ta a fost bună.

Livrează prima incrementare Trebuie să livrezi cât de repede poți.

Aceasta înseamnă zile sau săptămâni.

Nu aștepta să faci lucrurile frumoase și perfecte. Pus și simplu, livrează! Obține feedback! Dacă ai dezvoltat mai puțin, este mai ușor să modifici. Vei dori să livrezi cea mai simplă incrementare posibilă.

Obține feedback pentru prima incrementare Cu această incrementare, poți cere părerea prietenilor, familiei, cunoștințelor.

Poți de asemenea să mergi la grupurile de utilizatori, investitori și să le prezinți ideea ta. Ai ceva de arătat. Aceasta demonstrează oamenilor că tu ești într-adevăr hotărât să îmbunătățești acest produs, iar aceasta ajută mult să obții un feedback valoros în legătură cu îmbunătățirea produsului tău.

Pivotează Vei dori să rămâi fidel ideii „eșuează rapid, eșuează ieftin” din Lean Startup3.

Dacă prima incrementare nu obține feedback pozitiv, poți fie să îl îmbunătățești, fie să renunți pur și simplu la el. Să pivotezi înseamnă să schimbi calea de dezvoltare înspre cerințele reale ale utilizatorilor, înspre ceea ce ei doresc și au nevoie cu adevărat și pentru care vor plăti. S-ar putea să fii nevoit să pivotezi de mai multe ori până când vei găsi calea cea bună.

Livrează produsul minim viabil (MVP) Odată ce ai înțeles unde trebuie să mergi cu prima incrementare de produs, livreazăl utilizatorilor reali. Pune-l pe piață cât de repede poți și obține feedback de la lume.

Gândește la scară mare, gândește global. Încearcă să lansezi MVP pe piață oriunde mergi. Investește în prezentarea produsului tău minim viabil și păstrează-ți sistemul deschis pentru orice feedback legat de îmbunătățire. Feedback-ul de la utilizatorii reali este atât de prețios încât poate defini soarta produsului: un succes sau un eșec.

File:User_Story_Map_in_Action.png

Prioritizarea valorii de business

Nu estima efortul

După ce toate temele sunt despicate în epopei și toate epopeile sunt despicate în user stories, noi trebuie să găsim o cale de a ierarhiza aceste funcționalități conform priorităților. Deci, trebuie să analizăm fiecare user story și să înțelegem cât de repede și de eficient am putea transforma în capital valoarea reprezentată de partea „astfel încât <…>” din ea. Pentru a face asta, trebuie să creăm o balanță pentru estimarea valorii de afacere. În principiu, noi trebuie să găsim o cale pentru a realiza o ierarhie a scenariilor utilizatorilor, în ceea ce privește valoarea de business pe care o poate aduce utilizatorului. De asemenea, trebuie să mai luăm în calcul cât de ușor poate fi monetizată această valoare de către afacere.

Nu este nevoie să estimezi efortul. Pur și simplu începe să lucrezi și notează cât îți ia fiecare user story ție și echipei tale. După vreo două săptămâni sau o lună, ai datele pentru a înțelege viteza de dezvoltare pentru acest anumit produs. Folosește aceste date statistice pentru a face o previziune legată de ceea ce poți livra în realitate în următoarele trei luni. Estimarea efortului de la început este o pierdere de timp, în această etapă a dezvoltării produsului2.

Banii

Identifică efortul financiar pe care ești dispus Monetizează-ți efortul să îl faci Dacă primul tău MVP începe să 1 David Hussman explică User Story Mapping http:// vimeo.com/14499975 și http://www.infoq.com/presentations/ story-mapping 2 Vasco Duarte, #NoEstimates https://www.youtube. com/watch?v=0SD7Qk4ffPw

fie utilizat, înseamnă că poți începe să câștigi bani. Probabil că nu mulți, dar 3 http://theleanstartup.com/principles

www.todaysoftmag.ro | nr. 24/Iunie, 2014

29

management Inițierea unui produs este suficient. Este un semn că produsul tău aduce valoare reală utilizatorilor reali.

Dacă începi să câștigi bani înseamnă că poți să îi reinvestești în dezvoltarea ulterioară. De asemenea, mai înseamnă și că echipei de dezvoltare i s-a ridicat moralul: produsul pe care îl construiesc este util.

Pe de altă parte, dacă nu îți poți monetiza efortul, s-ar putea să vrei să continui să îi faci reclamă pe piață și să adaugi noi caracteristici, sau ai putea să dorești să te orientezi înspre o altă direcție .

trebuie să pivotezi.

Produsul

După cum am descris în acest articol, aceasta este o metodă de a transforma o idee într-un produs care poate fi monetizat.

Ar putea părea simplu, dar nu este. Trebuie să fii deschis schimbărilor și să înțelegi eșecul nu ca pe un lucru rău, ci ca pe un fapt din viața reală din care poți învăța atât de multe.

Așa poți începe inițierea produsului.

Ne-am bucura să vă ghidăm în acest proObține feedback în legătură cu MVP ces, așa că vă vom răspunde cu plăcere la Totuși, aceasta nu înseamnă că nu este orice întrebări sau remarci. nevoie să îmbunătățești produsul minim viabil. Ai întotdeauna nevoie să obții feedback de la utilizatori și să înțelegi dacă nu cumva poți aduce și mai multă valoare utilizatorilor tăi reali.

Pivotează Dacă eșuezi rapid, poți înțelege că este nevoie să schimbi direcția înspre care se îndrepta produsul. Pivotarea este întotdeauna o provocare și te obișnuiești cu ea pe măsură ce o practici din ce în ce mai des.

A pivota nu înseamnă că ai dat greș; înseamnă că ai învățat mai multe despre nevoile reale ale utilizatorilor. Iar acesta este cel mai bun lucru pe care îl poți face: să înțelegi utilizatorii și nevoile lor cât mai rapid posibil. În timpul acestui proces de a înțelege utilizatorii, ți-ai putea face o idee destul de bună despre direcția în care

30

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

management

Povestea unui Product Owner

S

copul acestui articol este de a clarifica rolul și responsabilitățile unui Product Owner*, după cum a fost observat și implementat în mediul software din Cluj de către autor.

Subiectul este vast și nu poate fi acoperit în întregime într-un singur articol, dar aș dori să ofer unul dintre numeroasele puncte de vedere prin care subiectul poate fi abordat în interiorul fiecărei echipe și companii.

Bogdan Giurgiu

Bogdan.Giurgiu@endava.com Group Product Owner @ Endava

Rolul Product Owner-ului (PO)

Mai întâi de toate să pregătim scena și să clarificăm un lucru de la bun început: rolul Product Owner-ului este asociat metodologiei Scrum și ar trebui să existe într-un mediu Agile sănătos. Este adevărat că fiecare companie este Agile în propriul său fel, iar acesta nu este un lucru rău. Diversitatea este bună atâta timp cât rămânem fideli principiului de bază „Inspectează și Adaptează”.

Dacă sunt de acord că oricine se poate auto-denumi Agile atâta timp cât respectă principiul de bază, cu Scrum este o poveste diferită. Fie aplici Scrum, fie ScrumBut. Este important să lămurim conexiunea directă dintre Scrum si rolul PO. În alte metodologii, responsabilitățile PO sunt de obicei împărțite între diferiți membri ai echipei, cum ar fi (dar fără a se limita la): managerul proiectului, managerul produsului, arhitect, etc. .

Aș dori să încep prin a-l cita pe Mike Cohn, unul dintre fondatorii Scrum-ului: Product Owner-ul este de obicei un utilizator important al sistemului, sau cineva din marketing, managementul produsului sau oricine are o înțelegere solidă a utilizatorilor, a sectorului de piață, a competiției și a tendințelor viitoare din domeniu sau tipul de

sistem care este dezvoltat.

Reținem ideea principală a acestui citat : existența unei paletă largi de potențiali candidați la acest rol. În rândurile următoare vom dedica o analiză acestui citat. Începem cu prima afirmație: „Product Owner-ul este de obicei un utilizator important al sistemului... .”Am lucrat într-un scenariu similar, în care un utilizator principal al sistemului a preluat responsabilitățile asociate produsului. Acest utilizator principal avea viziunea și el a fost cel care a trasat direcția. Dar cum acest utilizator venea dintr-un domeniu care nu avea legătură cu industria IT și Scrum, a fost nevoie de ajutor adițional pentru a transpune viziunea într-un Product Backlog. Acest ajutor poate fi oferit în diverse forme. Într-un prim scenariu, cu condiția ca utilizatorul principal să aibă lățimea de bandă necesară și dorința de a-și asuma responsabilități în plus, acesta poate deveni Product Owner (după cum este descris în metodologia Scrum), cu instruirea profesională adecvată. Nu am văzut să se întâmple prea des acest lucru, deoarece, în cele mai multe cazuri, utilizatorul principal nu are lățimea de bandă sau dorința de a se muta în această poziție. De aceea, al doilea (și

www.todaysoftmag.ro | nr. 24/Iunie, 2014

31

management Povestea unui Product Owner cel mai des întâlnit) scenariu este divizarea responsabilităților care vin cu acest rol în două, iar utilizatorul principal va deține viziunea și direcția, iar o persoană din echipa Scrum, un Product Owner delegat, va crea și va deține Product Backlog. Acest aranjament este ilustrat în Figura A de mai jos și este una dintre formulele în care am lucrat, jucând rolul Product Ownerului delegat. Din propria experiență, am observat că utilizatorul principal care joacă rolul de „Product Owner” așa cum este ilustrat mai jos, nu deține bugetul pentru a-și realiza viziunea, și nici nu e interesat de întoarcerea investiției (Return of Investment) pentru produs. Din perspectiva cuiva care nu investește direct bani în produs, dar resimte impactul direct al noii funcționalități, returnarea investiției este întotdeauna pozitivă. În acest scenariu, un alt jucător va intra în arenă și va lua responsabilitatea administrării bugetului. În funcție de companie și politica sa, această

persoană poate fi un manager de proiect sau un manager de resurse.

Figura A: Clientul sau Utilizatorul Principal drept Product Owner

Scenariul de mai sus are o valența diferită atunci când un Client preia rolul de Product Owner. Similar cu situația de mai sus, în majoritatea cazurilor acest Product Owner va lucra cu un Product Owner delegat, care este responsabil cu crearea

32

Product Backlog-ului. Schimbarea constă în deținerea bugetului, deoarece acest Product Owner va fi interesat direct de ROI, din cauză că banii investiți în produs provin din buzunarele sale.

Să trecem mai departe cu analizarea afirmației „Product Owner-ul este … cineva din marketing, managementul produsului…”. Convingerea mea puternică este că Departamentul de Marketing al unei companii ar trebui să aibă una dintre cele mai creative echipe. Ei trebuie să fie în fruntea afacerii și trebuie să aibă acea „înțelegere profundă a sectorului de piață și a competiției.” În mediul în care am lucrat, Marketingul avea o colaborare strânsă cu echipa de Produs. Ideile care erau uneori generate în interiorul departamentului creativ de marketing erau de obicei digerate și transformate în interiorul echipei de Produs. Acesta este un alt scenariu obișnuit pe care l-am întâlnit, în care cineva din echipa de Produs, în cele mai multe cazuri un Manager de Produs, va deține produsul. În această organizare, persoana care joacă rolul Managerului de Produs trebuie să aibă cunoștințele necesare și lățimea de bandă pentru a juca și rolul de Product Owner.

Acesta este scenariul perfect, într-adevăr, în care Product Owner-ul deține viziunea, creează backlog-ul și are și bugetul pentru realizarea viziunii. Această organizare este reprezentată în figura B de mai jos, iar eu am creat produse și din acest rol. Este un rol antrenant care îți dă o mare putere, căci ești direct răspunzător de ROI pentru fiecare caracteristică și eu a trebuit să pun în balanță funcționalitatea furnizată cu bugetul investit. În această organizare, putem afirma categoric că Product Owner-ul este dedicat produsului și echipei, pe toate

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

nivelurile.

Figura B: Reprezentantul Echipei de Produs drept Product Owner

Până acum am analizat diferite situații în care Product Owner-ul se poate regăsi, dar și o gamă largă de persoane care pot ocupa acest rol. Acum că am identificat câteva dintre responsabilități, vom săpa mai adânc în această zonă. Aș vrea să pun accentul pe cele prezentate mai jos, chiar dacă spectrul responsabilităților poate (și de obicei așa se întâmplă) să includă alte activități.

Responsabilități ale Prodcut Owner-ului

Product Owner-ul trebuie să reprezinte și să supravegheze interesul părților implicate. Această colaborare este crucială pentru succesul produsului. Comunicarea dintre beneficiarii produsului, PO și echipă este permanentă și are drept obiectiv clar menținerea implicarii tuturor față de produs și asigurarea unui feedback constant la toate nivelurile.

O altă responsabilitate importantă este aceea de a crea și de a „dichisi” în mod continuu Product Backlog-ul. În această activitate, Product Owner-ul ar trebui să caute ajutor de la Echipa Scrum. Odată ce viziunea a fost comunicată Echipei și unele funcționalități cheie au fost identificate, Echipa poate ajuta la cristalizarea Product Backlog-ului, care este mai detaliat decât

TODAY SOFTWARE MAGAZINE viziunea. Mie personal mi s-a întâmplat asta la începutul călătoriei, în timpul unui Sprint Zero și în mod constant pe parcursul vieții produsului în timpul sesiunilor de planificare al unui release. În timpul acestor sesiuni, detaliile fine sunt identificate sub formă de User Stories** care vor fi supuse unui proces de definire a priorității, condus din nou de Product Owner.

Aș dori să subliniez un aspect important: trebuie să existe o relație simbiotică între PO și Echipă. Unul nu poate exista fără celălalt, iar prin această simbioză, ambele părți implicate ar trebui să prospere. Mediul este un factor cheie pentru ca această simbioză să existe. Ce ar trebui să ofere mediul pentru a încuraja această relație? Personal, cred că un mediu sănătos trebuie să hrănească creativitatea și inovația mai întâi de toate. Mediul în care oamenilor li se dă putere și sunt încurajați să vină cu idei și soluții, este mediul în care se vor întâmpla lucruri benefice. Product Owner-ul are responsabilitatea de a crea și îngriji acest mediu, deoarece produsul său va fi direct afectat de gradul de motivare a echipei.Rolul unui lider într-o echipă poate fi jucat de mai multe persoane, dar este crucial pentru succesul produsului să existe un lider puternic în persoana Product Owner-ului.

Dar cum poate cineva să motiveze o echipă? Personal, cred că cel mai bun răspuns este: prin pasiune. Un Product Owner trebuie să fie pasionat de domeniul și de linia de afacere pe care încearcă să le acopere. Dacă faci ceva din pasiune, va fi natural să rămâi pe primul loc în acest joc și să fii la curent cu piața, competiția și cu toate noutățile legate de domeniul respectiv. Dacă cineva își îndeplinește sarcinile cu pasiune, aceasta nu va mai fi o doar slujbă

de la 9 la 6, în fond nu va mai fi o slujbă … va fi un hobby, ceva ce faci din pasiune. Dacă PO are această pasiune pentru domeniu, ea va fi contagioasă în interiorul echipei și, fără îndoială, va motiva pe fiecare membru în parte. Jack Welch, fost președinte și CEO al GE, sintetizează acest lucru foarte bine în următoarea afirmație: „Liderii de afaceri buni creează o viziune, articulează viziunea, dețin cu pasiune viziunea și o conduc neîncetat spre împlinire”.

O altă caracteristică esențială a unui bun Product Owner este competența sa în crearea unei experiențe unice pentru utilizator (UX). El sau ea nu va trebui să ofere soluții UX din acest rol de Product Owner, dar ar fi grozav ca să fie capabil(ă) să ofere ceva mai mult decât o viziune și un backlog.

Backlog-ul produsului este în esență un set de funcționalități și, nu mă înțelegeți greșit, acestea sunt esențiale pentru succesul produsului, dar felul în care „ambalezi” aceste funcționalități și le prezinți utilizatorului joacă, de asemenea, un rol crucial. Să analizăm exemplul clasic al iPhone-ului și competitorii din fruntea mediului Android.

Dispozitivele Android pot cu ușurință să se ridice la funcționalitatea unui iPhone, în hardware și software, dar diferența principală de astăzi constă în experiența utilizatorului, care a devenit un criteriu de vânzare major, cheie, pentru Apple. A devenit extrem de important ca Product Owner-ul să fie capabil să lucreze cu un expert UX pentru a defini mai bine partea de experiență pentru utilizator. În concluzie, eu îmi imaginez Product Owner-ul ca fiind un lider pasionat, cu o foarte bună cunoaștere a domeniului, a afacerii și cu suficiente cunoștințe Scrum pentru a face lucrurile să meargă bine, o

combinație care s-ar putea să nu fie atât de ușor de găsit…

Pentru a afla mai multe despre acest rol, apelați la adresa: careers.endava.com/ ProductOwnerTraining. * Product Owener – Cel care deține responsabilitatea pentru un produs. ** User Stories – Un format standard de definire a funcționalităților pentru a fi incluse în Product Backlog.

www.todaysoftmag.ro | nr. 24/Iunie, 2014

33

programare

Visual Studio Online Monitorizarea unei aplicaţii web folosind Application Insights

V

isual Studio Online este o platformă dezvoltată de Microsoft care oferă o colecție de servicii destinată dezvoltării aplicațiilor software. Serviciile disponibile sunt:

• Source repository (Team Foundation Version Control şi Git); • Tool-uri pentru planificarea și urmărirea proiectelor (work item tracking, planning, management – suport pentru Agile: Scrum, Kanban); • Test environment (Load testing); • Continuous integration (build server).

De fapt Visual Studio Online e un Team Foundation Server în cloud, care aduce avantajele specifice aplicațiilor din cloud pentru că nu necesită instalare, configurare, iar mentenanța e asigurată de Microsoft). Utilizatorii au nevoie doar să se logheze pe această platformă şi să o folosească.

Visual Studio Online aduce în plus şi o aplicație “Application Insight”, dedicată pentru monitorizarea şi culegerea datelor aplicaţiilor care rulează în mediul de producție.

Aplicaţiile care pot fi monitorizate pot fi de următorul tip: • Web service sau web application, • Web pages care folosesc JavaScript, • Aplicaţii Windows Phone 8, • Aplicaţii Windows Store. În continuare vom urmări cum se configurează aceasta aplicație şi modul în care ne oferă datele spre analiză.

Configurarea aplicaţiei

Intrarea în aplicaţia “Application Insight” se face din Visual Studio Online, după logare din dashboard se dă click pe link-ul “Try Application Insight” (Understand and optimize the performance of your application). În continuare vom urmări cum se configurează o aplicaţie web.

Printr-un scurt wizard (Add application) se va specifica ce tip de aplicaţie se va monitoriza. Utilizatorul trebuie să aleagă dacă aplicaţia este .Net sau Java, dacă e în Azure sau nu şi dacă se doreşte să se colecteze datele de pe o componentă server.

După aceea, în următorul ecran, utilizatorul specifică un nume pentru aplicaţie şi primeşte un fişier de configurare care trebuie copiat în folder-ul principal al aplicaţiei web.

Pentru colectarea informaţiilor în tip real de la site-ul web mai e necesară instalarea unei aplicaţii desktop “Microsoft Monitoring Agent” pe calculatorul pe care e instalată aplicaţia web, iar pentru colectarea datelor de la utilizatori (sistemul de operare, browser-ul, locația) sunt necesare câteva modificări în aplicaţie.

Astfel, ca să aflăm de câte ori a fost vizitată fiecare pagină din aplicaţie trebuie copiat un cod javascript în header-ul fiecărei Our core competencies include:

Product Strategy

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

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

www.3pillarglobal.com

34

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

Product Development

Product Support

TODAY SOFTWARE MAGAZINE pagini:

la culegerea informaţiilor care au avut loc (numărul de excepţii apărute în aplicaţie, problemele de memorie şi de performanţă depistate). În continuare vom urmări pe un exemplu concret modul în care sunt afişate informaţiile.

Iar dacă dorim să avem informații despre utilizatorii logaţi şi activităţile lor, e nevoie ca după logare să salvăm informaţii despre Overview utilizatori în obiectul javascript appInsights.

Dashboard-ul default conţine trei widget-uri: unul pentru Disponibilitate, unul pentru Perfomanţă şi unul pentru Utilizare.

Configurare avansată Cu ajutorul acestui dashboard se poate uşor observa dacă sunt proToate informaţiile care se culeg prin această aplicaţie pot fi bleme în aplicaţie. configurate ulterior prin acel fişier de configurare care a fost copiat în root-ul aplicaţiei web.

Fişierul de configurare conţine două profile: Production and Development şi putem configura aceste proprietăţi individual pentru fiecare profil.

Proprietăţile care se pot configura sunt următoarele: Proprietate

Descriere

Prod

Dev

Enabled

Atribut al nodului ServerAnalytics

True

True

False

True

False

True

False

True

60

0.1

Iniţial sunt afişate doar informaţiile din ultimele 24 de ore dar se poate uşor seta un alt interval de timp. Există preopţiuni pentru: “Last hour”, “Last 4 hours”, “Last 12 hours”, “Last 24 hours”, “Last 3 days”, “Last 7 days”, iar prin intermediul opțiunii “Custom” se poate selecta orice interval de dată dorit (ex. 1 ianuarie – 15 ianuarie).

True

True

Disponibilitatea aplicaţiei

True

True

– specifică dacă este activat sau nu serviciul de colectare de date SendToRawStream

Specifică daca se trimit datele pentru analiză în pagina Diagnostics/ Stream şi către widget-ul Raw Event

CollectUserName

Specifică daca se colectează username-ul utilizatorului curent

CollectMachineName

Dacă se colectează sau nu numele maşinii utilizatorului curent

DataUpload

Intervalul de timp la care se trimit

IntervalInSeconds

datele colectate (în secunde)

AutoFillClient

Colectează datele despre client din

PropertiesFromRequest

request-ul HTTP

CollectClientIPAddress

Colectează ip-ul clientului din request-ul HTTP

Există o versiune de “Application Insight” integrată cu IDE-ul Visual Studio, care se poate instala din meniul “Extensions & Updates” din Visual Studio.

După instalare, la click dreapta pe proiectul dorit mai apare o opţiune pentru adăugarea aplicaţiei “Application Insights” la proiectul dorit.

După adăugarea aplicaţiei la proiect, se va crea automat o aplicaţie în Visual Studio Online care va colecta date despre proiect.

În cel de-al doilea tab (Availability) se afișează un grafic mai detaliat despre disponibilitatea aplicaţiei.

Aici se pot defini mai multe zone din care să se verifice dacă aplicaţia este disponibilă.

Monitorizare

“Application Insight” are cinci secţiuni principale care afişează datele colectate: • Pagina principală (Overview) – aici se poate configura o pagină de start în care se pot defini care widget-uri să apară în pagina de start.

• Disponibilitatea (Availability) – afişează disponibilitatea aplicaţiei (raportul de timp) în care aplicaţia e disponibilă.

• Performanţa (Performance) – afişează informaţii despre performanţa aplicaţiei, durata request-urilor, numărul de request-uri, încărcarea calculatorului etc..

• Utilizarea (Usage) – colectează informaţii despre utilizarea aplicaţiei, paginile cele mai des accesate, numărul de utilizatori, locaţia de unde s-a accesat aplicaţia etc..

• Diagnostic – conţine metrici culeşi din aplicaţie care ajută

Definirea locaţiilor pentru verificarea disponibilităţii aplicaţiei

În exemplul de mai sus am definit câteva zone în lume: Australia, America de Sud (Brazilia), Europa (Londra, Moscova), America de Nord (USA) şi Asia (Japonia), de unde să se verifice dacă aplicaţia este disponibilă. Este afişat de asemenea şi cât a durat request-ul din fiecare zonă, putându-se astfel depista dacă aplicaţia are probleme doar într-o anumită zonă.

Exista de asemenea posibilitatea să se definească alerte. Astfel, dacă aplicaţia nu este disponibilă în una sau mai multe zone, se poate specifica să se trimită un mesaj (e-mail) la o anumită adresă (sau la mai multe) în care să se notifice de problema apărută. Un www.todaysoftmag.ro | nr. 24/Iunie, 2014

35

programare Visual Studio Online astfel de mail e prezentat mai jos.

Performanţa aplicaţiei

Această secţiune conţine mai multe widget-uri care prezintă informaţii despre performanţele aplicaţiei. Aceste widget-uri ajută foarte mult la identificarea problemelor de performanţă apărute în aplicaţie.

Pagini Vizualizate – de câte ori a fost vizualizată fiecare pagină din site

Diagnostic

În această pagină sunt prezentați diferite metrici care ajută la diagnosticarea problemelor care au apărut la rularea aplicaţiei.

Pagina de performanţă

Widget-uri care apar implicit sunt următoarele: • Response Time and Load vs. Dependencies - acest widget afişează tipul de răspuns al aplicaţiei, numărul de request-uri făcute şi timpul în care s-a răspuns la aceste request-uri; • Response time distribution – afişează o distribuţie a requesturilor din punctul de vedere al timpului de răspuns (câte au avut un timp de răspuns mai mic de 0.5 secunde, câte au durat mai mult de o secundă, câte au durat mai mult de 5 secunde); • Exception Rate – afişează câte excepţii apar pe secundă; • CPU – cât la sută este folosit procesorul de către aplicaţie; • Network – afișează cât de mult este folosită reţeaua; • Memory in use – memoria folosită; • Average instance count – numărul mediu de instanţe de aplicaţie.

• Top 10 slowest requests by issue count – afișează cele mai lente 10 request-uri. Analiza informaţiilor recepționate prin acest widget le vom analiza mai târziu în pagina de diagnosticare.

Observăm ca în pagina principală este afişat un sumar al evenimentelor din aplicaţie. În poza de mai sus apar doar trei metrici: excepţii, performanţă şi memorie; dar se pot alege uşor alte metrici dintr-o listă mai lungă de metrici predefinite puse la dispoziţie de către Microsoft. În continuare, vom vizualiza informaţiile oferite de două dintre metrici (exception şi performance).

Exception events – afișează toate excepţiile care au apărut la rularea aplicaţiei. Iniţial în pagina de diagnostic apare doar numărul excepţiilor apărute, dar dacă se doreşte vizualizarea mai detaliată a acestora prin click pe acel sumar, se intră într-o altă fereastră în care se pot vizualiza toate excepţiile.

Utilizabilitatea aplicaţiei

Această pagină conţine informaţii utile despre utilizatorii care accesează aplicaţia. Se poate vizualiza de aici care sunt paginile cele mai accesate din aplicaţie, câţi utilizatori au accesat site-ul, browser-ul folosit, rezoluţia cu care operează utilizatorii etc..

La prima vedere aceste informaţii par mai utile celor de la marketing, management; dar se poate de asemenea oferi şi informaţii utile dezvoltatorilor. Astfel se poate determina dacă e necesară implementarea unor noi funcționalităţi (ex: suport pentru un anumit tip de browser, rezoluţie sau limbă).

36

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

Dacă se doreşte aflarea mai multor detalii despre o excepţie prin dublu click pe eroarea dorită, se deschide un popup în care aflăm toate informaţiile despre eroare: parametri, stack, linia de cod.

Cu ajutorul acestor informaţii se poate identifica în ce condiţii a apărut eroarea, se poate reproduce şi apoi repara.

TODAY SOFTWARE MAGAZINE Logging

Un alt lucru foarte util pe care îl suportă “Application Insight” e integrarea cu logger-ul din aplicaţie. Printr-un mic wizard se selectează logger-ul folosit (Log4Net, NLog sau Trace Listener) iar apoi Visual Studio Online, generează un config care trebuie adăugat în fişierul de configurare al aplicaţiei.

Perf events - afişează toate evenimentele de tip performanţă Astfel informaţiile logate în aplicaţie vor apărea şi în apărute în aplicaţie.

“Application Insight” din Visual Studio Online.

Concluzii

La fel ca în widget-ul de excepţii, dacă se doreşte investigarea în detaliu a unei probleme de perfomanţă, se poate intra în fereastra de detalii, unde putem să aflăm toate informaţiile despre eveniment (parametri, durata de execuţie a fiecărei metode – inclusiv codul de sql care s-a executat).

Culegerea informaţiilor despre o aplicaţie în timp ce rulează nu e o operaţiune simplă, se poate folosi logging, performance counters etc; însă acestea necesită un timp suplimentar (performance counters pentru configurare, analiză; logging-ul pentru analiza datelor – uneori se caută în fişiere text de câţiva MB informaţii care ar putea ajuta dezvoltatorul să ştie ce s-a întamplat).

Application Insight are avantajul de a colecta aceste informaţii foarte ușor (nu se pierde decât foarte puţin timp pentru configurare) şi de a le prezenta într-un format uşor de interpretat.

Marius Cotor

marius.cotor@3pillarglobal.com

Cu ajutorul acestor informaţii se poate uşor identifica unde are aplicaţia probleme de performanţă şi se poate interveni în remedierea acestora.

Technical Lead @ 3Pillar Global

www.todaysoftmag.ro | nr. 24/Iunie, 2014

37

programare

Rețeaua StackExchange

D

acă citești acest articol, cel mai probabil ești programator. Și, ca orice programator, ai fost nevoit să cauți online soluții la problemele de programare pe care le întâmpini. Sunt convins că ați observat ceva interesant: în ultimii ani, atunci când căutăm un răspuns la o întrebare despre programare, printre primele trei rezultate afișate de Google se află aproape de fiecare dată un link către StackOverflow.

Aceasta nu e o coincidență: StackOverflow-ul s-a strecurat cumva în viața programatorilor, încet dar sigur. Ne folosim de el practic zilnic, dar am observat că cei mai mulți programatori nu știu prea multe despre cum s-a născut acest site, pe ce principii funcționează și de ce are atât de mult succes.

StackOverflow e doar unul din cele 119 site-uri ale rețelei StackExchange, cele două NU sunt sinonime. În acest articol, vom expune filosofi care stă la acestei rețele și vom arunca o privire de ansamblu asupra mecanismelor care îi permit să funcționeze practic independent.

Sperăm că aspectele aduse la lumină să ofere mai mult confort în utilizarea acestei rețele și să vedem o participare mai puternică din partea programatorilor români.

Filosofia rețelei Istorie și motivație Înainte de StackOverflow, era foarte dificil să găsești o soluție (corectă) la o problemă de programare, cu excepția celor des întâlnite. Motivele acestei situații sunt multiple: a. Oamenii care scriau documentație pentru un limbaj, un framework sau o tehnologie erau practic incapabili să o pună pe Internet și să-i facă conținutul ușor accesibil. b. Soluția putea fi într-o carte de programare. Însă realitatea e că extrem de puțini programatori mai învață din cărți. Această industrie e cam în moarte clinică. c. Răspunsurile existente pe forumuri erau îngropate în pagini și pagini de discuții. d. În multe locuri, răspunsurile aveau o tonă de probleme: de la sfaturi proaste și rezolvări care funcționau doar pentru anumiți oameni până la soluții sub forma de hack-uri și cod plin de vulnerabilități. Nu era nici o modalitate de a le modifica, repara și îmbunătăți. e. Multe probleme erau până la urma rezolvate de către platformă sau de către framework, dar nu știai aceasta pentru că soluția veche era încă prima în lista de rezultate de pe Google. f. Dacă problema era rară (un API care se comporta ciudat într-o anumită situație), atunci pagerank-ul motoarelor de căutare nu funcționa: problema afecta doar câțiva oameni, deci nimeni nu posta link-uri către soluție și prin urmare nu apărea în rezultatele căutărilor.

38

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

g. Sunt prea multe feluri în care poți formula o întrebare, trebuie să găsești cuvintele potrivite pentru a avea o șansă.

Pentru a rezolva aceste probleme și pentru a avea o mult mai bună accesibilitate a soluțiilor online, Joel Spolsky și Jeff Atwood decid în ianuarie 2008 să deschidă un site Q&A numit StackOverflow. Dezvoltarea acestuia a început în Aprilie 2008, iar în August 2008 acesta a fost lansat sub forma unui beta privat.

După 4 săptămâni, în Septembrie 2008, StackOverflow-ul a devenit public.

Joel avea blogul joelonsoftware.com iar Jeff avea codinghorror. com. Aceste bloguri cunoscute s-au dovedit a fi rețeta de succes a StackOverflow-ului pentru că, prin intermediul lor, Jeff și Joel au popularizat noua lor idee. Au făcut aceasta printr-un Podcast în care vorbeau despre site și pe care l-au postat pe cele două bloguri.

Acesta a fost un aspect important pentru ca un vizitator nou să poată găsi conținut de calitate încă de la bun început.

StackOverflow-ul e o combinație între un forum, un blog, un wiki și un agregator de știri. Ideea de bază e ca oamenii să întrebe și să primească răspunsuri, nu doar să comenteze aiurea. E un loc unde calitatea este votată și promovată, iar conținutul inutil este împins în jos și dispare. În StackOverflow se vrea acumularea a cât mai multe cunoștințe de programare și soluții ale problemelor din acest domeniu. Comunitatea evaluează toate problemele și soluțiile prin intermediul votării. Pe măsură ce voturile se acumulează, experții și oamenii de încredere ies la iveală, iar comunitatea are încredere tot mai mare în ei.

A fost un succes instantaneu, fapt care i-a convins pe fondatori să deschida ServerFault în Aprilie 2009, un site pentru administratorii de sistem bazat pe aceeași filosofie ca StackOverflow-ul. A urmat SuperUser în Iulie 2009, un site pentru utilizatori entuziaști ai computerelor.

Succesul acestor site-uri a pus baza rețelei StackExchange, care acum cuprinde o multitudine de site-uri, toate urmând aceeași structură și filosofie de funcționare pe care a fost construit StackOverflow-ul.

Modificarea și menținerea conținutului într-o stare cât mai actualizată este crucială pe site-urile StackExchange-ului.

Accesibilitatea conținutului este de asemenea foarte importantă, site-urile practicând politici agresive de SEO.

TODAY SOFTWARE MAGAZINE Popularitatea StackOverflow-ului și prezența constantă a programatorilor în mediul online are o consecință interesantă: atunci când apare o nouă tehnologie sau un nou limbaj de programare, în loc să fie create forumuri sau site-uri pentru suport, utilizatorii acestora sunt redirecționați spre tag-urile corespunzătoare de pe StackOverflow.

Varietate si profesionalism După cum am menționat în introducere, rețeaua StackExchange are 119 site-uri. Acest număr variază în timp (vezi capitolul “Area51”).

Fiecare dintre aceste site-uri funcționează pe aceleași principii de bază: sunt site-uri de Q&A, folosesc aceeași platformă și au ca utilizatori țintă acei oameni care activează în mod profesionist într-un anumit domeniu.

Diferența e că fiecare are propria lui comunitate care le conduce și administrează total independent de celelalte site-uri. De fapt, singura colaborare este atunci când întrebările migrează de la un site la altul; fiind vorba de aceeași platformă, acest lucru este posibil.

Fiecare site are propriul lui subiect, dar varietatea acestora menționată în titlu este prea modestă. Cele mai populare subiecte sunt cele axate în jurul programatorilor și tehnologiilor, remarcându-se printr-o diversitatea foarte mare: de la matematică, jocuri pe calculator, poker, sporturi, politică și fotografie până la management financiar, șah, design grafic, sfaturi părintești, istorie, religie și lingvistică. Sunt foarte slabe șanse să nu îți găsești măcar unul sau două hobby-uri sau interese printre multitudinea de subiecte.

După cum am menționat mai sus, fiecare site are ca scop acumularea a cât mai multă informație prin intermediul experților din acel domeniu prezenți pe site. Atunci când cineva caută o anumită informație, trebuie ca rezultatul să fie un răspuns profesionist, obiectiv și complet. Acesta e idealul comunităților StackExchange.

Licența asupra conținutului Filosofia rețelei include conceptul de a face publică întreaga informație a acesteia. Orice întrebare sau răspuns care ajunge pe rețea intră automat sub incidența licenței Creative Commons Attribution-ShareAlike. Aceasta înseamnă că fiecărei persoane îi este recunoscut dreptul de autor asupra respectivului text, care trebuie să rămână 100 % public, putând fi folosit și modificat de oricine (cu condiția ca modificarea să rămână sub incidența aceleași licențe), inclusiv cu scopuri comerciale.

Atribuirea acestei licențe conținutului permite folosirea datelor în multe feluri. Vezi capitolul “Big Data” pentru mai multe detalii.

Mecanisme de funcționare Q&A, repuțatie și privilegii În mare, sistemul este foarte simplu: o persoană pune o întrebare și alții răspund. Fiecare întrebare și fiecare răspuns pot fi votate cu un “upvote” sau cu un “downvote”. În funcție de aceste voturi, autorul primește “reputație” sub formă de puncte. Cu cât mai multe puncte se acumulează, cu atât mai multe privilegii vei primi și comunitatea va avea încredere mai mare în tine.

Un “upvote” aduce autorului +5 puncte dacă e vorba de o întrebare și +10 puncte dacă e vorba de un răspuns. Această discrepanță este pentru că răspunsurile sunt cele care oferă cel mai de calitate conținut, prin urmare sunt valorificate mai mult.

Un “downvote” scade reputația autorului cu 2 puncte, indiferent dacă e vorba de o întrebare sau de un răspuns. În schimb, dacă acorzi un “downvote” unui răspuns, și ție îți va scădea reputația cu 1 punct. Această decizie a fost luată pentru a încuraja îmbunătățirea răspunsurilor, nu doar marcarea lor ca fiind de calitate proastă.

Fiecare întrebare trebuie să aibă tag-uri: minim 1, maxim 5.

Aceste tag-uri ajută la categorisirea întrebărilor, pentru a fi mai ușor de sortat și găsit. De exemplu, o întrebare despre cum se aplica un Look-and-feel în Java va avea probabil tag-urile “java”, “swing” și “look-and-feel”.

Autorul întrebării este încurajat să aleagă un răspuns ca fiind cel mai bun. În acest caz, autorul răspunsului va primi +15 puncte, iar autorul întrebării va primi +2 puncte.

Privilegiile obținute pe măsură ce crește reputația sunt variate: crearea de bounty-uri, flag-uri de atenționare a moderatorilor, camere de chat, posibilități tot mai avansate de editare și protejare a conținutului și multe altele. www.todaysoftmag.ro | nr. 24/Iunie, 2014

39

programare Rețeaua StackExchange Moderare Fiind o rețea bazată pe ideea de rețea socială, moderarea se face un pic altfel.

Aceasta e împărțită în trei nivele: a) Membrii obișnuiți fac cele mai multe activități de moderare. Aceștia modifică conținutul de pe site-uri, pot vota să închidă sau chiar să șteargă anumite întrebări și pot atrage atenția moderatorilor asupra anumitor aspecte. Pentru a face toate astea, membrii au acces la niște unelte de revizuire care devin accesibile pe măsură ce membrul acumulează reputație.

Cei cu reputație foarte mare au acces chiar și la o parte din uneltele moderatorilor.

Prin urmare, cele mai multe și mai des întâlnite probleme sunt rezolvate de către membri, fiind o comunitate care se administrează singură. b) Moderatorii sunt polițiștii rețelei, aceștia intervin acolo unde comunitatea nu poate. Ei se ocupă de flag-urile de atenționare, identifică conturi duble, migrează întrebări de pe un site pe altul, fac managementul tag-urilor și multe altele.

Printre cele mai importante atribuții, însă, se află rezolvarea disputelor și certurilor.

Numărul de moderatori fluctuează constant, de obicei sunt între 700 și 1000 în întreaga rețea. Aceștia sunt aleși de către Community Managers atunci când un site e în private beta și în public beta. În aceste stagii ale site-urilor, moderatorii sunt aleși pe baza activității și diplomației de care dau dovada pe respectivul site.

Odată ce un site ajunge la maturitate, se organizează alegeri democratice, unde membrii se auto-nominalizează și apoi sunt votați de către restul comunității în funcție de discursurile oferite. Aceste alegeri pot avea loc de mai multe ori. De exemplu, pe StackOverflow, aceste alegeri sunt ținute o dată sau de două ori pe an. c ) At u n c i c â n d a p a r s i t u a ț i i excepționale, problemele sunt rezolvate de către un Community Manager. Aceștia sunt angajați ai StackExchange-ului, al căror rol este să se asigure că totul funcționează corect, monitorizează și ghidează activitatea în Area51, răspund la întrebari pe site-urile Meta și oferă ghidare în folosirea uneltelor disponibile în rețea.

Rețeaua ca un Wiki Rețeaua are o foarte puternică tendință de wiki. Membrii sunt încurajați să modifice și să îmbunătățească constant conținutul de pe site. Este atât de puternică această tendință încât membrii sunt încurajați să-și adauge cunoștințele sub formă de întrebări și răspunsuri, adică să-și

40

răspundă la propria întrebare. În acest sens, fiecare întrebare împreună cu răspunsurile asociate sunt un fel de pagină wiki despre un anumit subiect. Ca să vă faceți o idee: 39 % din întrebări și 19% din răspunsuri sunt modificate cel puțin o dată după post-are[1].

Există situații când, pentru a răspunde la o întrebare, este nevoie de multă cercetare care să conducă la un răspuns foarte complex care să implice mai mulți autori lucrând împreună sau liste lungi de răspunsuri. De exemplu o întrebare de tipul “Care sunt cele mai bune cărți de programare ?” implică un răspuns de o asemenea complexitate. În acest caz, întrebarea va primi foarte multe răspunsuri care vor deveni populare, vor primi “upvote”-uri și vor fi modificate foarte des de către mulți oameni. Aceste aspecte ridică o problemă interesantă: dacă atât de mulți oameni contribuie la respectivul conținut, este cinstit ca autorul original să primească atât de multă reputație ?

Pentru a rezolva această problemă, întrebările de acest gen sunt marcate ca fiind “Community Wiki”. Aceasta înseamnă că reputația generată de acea întrebare și de răspunsurile asociate ei nu va fi atribuită nimănui. Autorul nu va mai fi afișat, ci membrul care a contribuit cel mai mult la respectivul conținut. De asemenea, modificarea lor e mult mai accesibilă pentru că pragul privilegiului pentru aceasta cade de la reputație 2000 la reputație 100.

Comentarii, chat și site-urile Meta În vremurile timpurii ale rețelei, se puteau adăuga doar întrebări și răspunsuri. Dar membrii aveau nevoie de un loc unde să discute regulile site-urilor, variatele situații excepționale care apăreau și calitatea întrebărilor și răspunsurilor.

Așa că s-a introdus un sistem prin care membrii să poată adăuga comentarii atât întrebărilor cât și răspunsurilor. Aceste comentarii pot primi “upvote”-uri, însă fără a genera reputație.

Un alt sistem de acest gen este chat-ul, unde membrii pot vorbi despre tot și orice.

Chat-ul este împărțit în “camere”, fiecare având propria discuție. În general, fiecare site are camera lui, însă noi camere pot fi create de membri care au suficiente privilegii pentru aceasta. Există și camere dedicate exclusiv moderatorilor, pentru ca aceștia să poată discuta probleme de moderare fără intervenția utilizatorilor obișnuiți.

Fiecare site din rețea are un site Meta asociat. Acestea sunt separate dar funcționează pe aceleași principii. Singurul

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

lucru pe care-l au în comun cu site-ul părinte sunt moderatorii. Pe ele se discută doar aspecte legate de site-ul părinte, adăugarea sau eliminarea de reguli, se pun anunțuri și multe altele. Site-urile Meta sunt create atunci când site-ul părinte ajunge în stadiul de private beta (vezi “Area51”).

Area51 După cum am menționat în capitolele precedente, rețeaua are un număr foarte mare de site-uri, fiecare cu subiectul lui.

Dar cum se nasc aceste site-uri ? Și cine decide care site-uri se deschid și ce subiecte vor avea ? Răspunsul este: tu, membrul de rând. Rețeaua e socială la bază, prin urmare comunitatea este cea care decide ce site-uri noi trebuie să apară și pe baza căror reguli vor funcționa.

Acest proces are loc în Area51, un site special unde site-urile sunt definite și lansate aplicând următorii pași: a. se propune un nou site. Acesta trebuie să aibă un nume, un subiect (ex: arhitectură navală) și o descriere. Oricine poate să facă o astfel de propunere. b. urmează stagiul de definire, când se încearcă atragerea de oameni interesați de noul site și crearea unor întrebări ipotetice care s-ar potrivi pe acesta. Se face asceata pentru a se stabili ce domeniu va avea noul site, ce subiecte de discuție vor fi acceptabile, ce se consideră o întrebare bună, un răspuns bun ș.a.m.d. Aceste întrebări vor fi modificate și discutate până când se ajunge la un comun acord legat de conținutul lor. Odată ce se atinge cifra critica de 40 de astfel de întrebări și un număr minim de oameni care urmăresc dezvoltarea, site-ul e considerat “definit”. c. următorul stagiu este angajamentul. În acest stagiu se încearcă acumularea unui număr cât mai mare de oameni care “își iau angajamentul” că vor participa pe site odată ce e lansat. Aceștia trebuie să “semneze digital” o petiție care confirmă acest lucru.Motivul pentru acest angajament e faptul că un site are nevoie de o masă critică de oameni care să îl folosească și să-l popularizeze în prima perioadă a existenței. Nu se poate trece la stagiul următor fără minim 200 de astfel de persoane. d. Urmeaza beta-ul privat când site-ul este efectiv lansat, împreună cu un site Meta asociat acestuia. În acest stagiu, site-ul nu e disponibil decât celor care, în stagiul precedent, și-au luat angajamentul că-l vor folosi. Acum se definește FAQ-ul site-ului, se atribuie primele

TODAY SOFTWARE MAGAZINE funcții de moderator și se fac ultimele șlefuiri. De asemenea, se începe adăugarea unui număr cât mai mare de întrebări și răspunsuri și popularizarea site-ului prin Facebook, Twitter, blog-uri ș.a.m.d. e. Următorul stagiu este beta-ul public când site-ul este deschis publicului și toată lumea îl poate folosi. f. Dacă site-ul îndeplinește criteriile de trafic și activitate cerute, atinge o masă critică de utilizatori și comunitatea are certitudinea că acesta va rămâne popular, atunci se îndeplinesc toate condițiile de trecere în stagiul matur al site-ului.

Când se ajunge aici, site-ul va primi un design grafic unic care să-i reflecte cât mai bine subiectul. De asemenea, acum se organizează alegeri democratice ale moderatorilor.

Careers StackOverflow are momentan 3 milioane de utilizatori și 6.6 milioane de vizitatori zilnici. Este cel mai popular site al rețelei și generează peste 80 % din întrebările, răspunsurile și traficul acesteia [2].

Prezența unei astfel de audiențe uriașe de programatori deschide porțile unei oportunități unice: job-uri și cariere. Așa s-a născut Careers.StackOverflow, un fel de LinkedIn strict pentru programatori și profesioniști IT. Fiecare membru își poate crea un profil, un CV electronic. Pe acesta se pot trece o sumedenie de informații: de la istoria job-urilor avute, tehnologiile cu care s-a lucrat și articole scrise până la proiectele realizate și cărțile citite. Pentru o cât mai bună funcționare, site-ul are integrare cu LinkedIn, GitHub, BitBucket, Amazon, SourceForge și multe altele. Profilele avute pe diferitele site-uri StackExchange pot fi listate și ele aici, împreună cu cele mai bune și mai votate răspunsuri de pe acestea.

Nici companiile nu sunt lăsate mai prejos: acestea pot să își creeze propriile pagini de profil unde să includă o descriere a companiei, o hartă cu locația acesteia, job-urile disponibile în acel moment, poze, lista cu profilele unor angajați cheie, beneficii, tehnologiile folosite în proiecte și multe altele.

Data.StackExchange Acesta este un site special care permite oricui accesul la conținutul rețelei StackExchange. Membrii pot scrie queryuri SQL într-un câmp mare de text, pot să execute aceste query-uri și să vadă rezultatele în timp real. Pentru a ajuta utilizatorul în acest sens, site-ul permite vizualizarea completă a structurii tabelelor bazelor de date.

Datorită faptului că arhitectura StackExchange-ului funcționează folosind baze de date SQL Server, query-urile trebuie să respecte sintaxa corespunzătoare acestui produs.

Bazele de date folosite de acest site nu sunt aceleași ca acele folosite în producție de către site-urile StackExchange, ci e vorba de o copie a acestora. Aceasta înseamnă că nu vei obține cele mai actualizate date. O actualizare a bazelor de date de pe Data.

StackExchange are loc de obicei o dată pe lună.

Utilizatorii care se loghează pe acest site pot să-și salveze query-urile și să revină oricând la ele pentru a le modifica și îmbunătăți.

Având în vedere natura publică a datelor, anumite informații nu sunt accesibile prin acest site, cum ar fi de exemplu e-mailurile membrilor.

munca a milioane de oameni din toate domeniile. Personal, economisesc foarte multe ore folosind aceste site-uri, ore care altfel le-aș petrece scormonind colțuri îndepărtate ale Internetului pentru a găsi răspunsuri la întrebări. Este practic imposibil să calculezi câți bani se economisesc folosind StackExchange-ul, dar e clar că e vorba de multe miliarde de dolari [3].

Referințe [1] Cristoph Treude, Ohad Barzilay, MargaretAnne Storey. How do programmers ask and answer questions on the web? In ACM, 21-28 May 2011.

[2] http://stackexchange.com/sites#traffic [3] http://skeptics.stackexchange.com/q/18539

StackExchange API și StackApps

Un alt mod de a accesa datele de pe rețea e prin StackExchange API, care e un webservice REST cu rezultate în format JSON sau JSONP (padded JSON).

Acest API poate fi folosit în aplicații 3rdparty orientate spre rețeaua StackExchange; deja există o multitudine publicate, în special pentru platformele mobile.

O mare parte din date nu pot fi accesate prin acest API decât prin autentificare.

Pentru a face aceasta, aplicația trebuie înregistrată în StackApps, moment în care se va primi o cheie de autentificare și se va permite efectuarea unui trafic mult mai mare către API. StackApps este, după cum am afirmatmai sus, un site unde aplicațiile care se folosesc de API pot fi înregistrate. Autorii își prezintă aici aplicația împreună cu Big Data instrucțiuni pentru instalarea acestora. De Toate profilele, întrebările, răspun- asemenea, discuții legate de API și folosirea surile, comentariile adăugate în rețeaua lui au loc tot aici.

StackExchange sunt puse la dispoziția publicului printr-o serie specială de site-uri Concluzie și API-uri. Acest lucru este posibil datoFormatul și filosofia pe care a fost conrită licenței, vezi capitolul “Licența asupra struită rețeaua StackExchange este de un conținutului”. real succes, popularitatea acesteia fiind evidentă. Site-urile de aici au ușurat mult

Radu Murzea

rmurzea@pentalog.fr PHP Developer @ Pentalog

www.todaysoftmag.ro | nr. 24/Iunie, 2014

41

testare

Profesioniști QA – creștere și dezvoltare

L

ucrez de mai bine de șapte ani în domeniul managementului calității produselor software, după o experiență de treisprezece ani ca programator, fiind implicată în ultimii patru ani și în recrutarea de specialiști. Datorită parcursului carierei mele, am auzit opinii variate despre meseria de tester, care îmi dau sentimentul că această meserie și potențialul ei de a dezvolta o carieră, este încă greșit înțeleasă. De asemenea, termenii de tester și QA engineer sunt adesea interschimbați folosindu-se impropriu.

Există încă mulți candidați la o poziție de tester care privesc această oportunitate, ca pe o potecă de acces spre ceea ce consideră ei a fi triumful carierei în IT și anume programarea, fără a-și da șansa de a înțelege posibilitatea de dezvoltare profesională în domeniul managementului calității.

O parte din cei care practică meseria de tester la un nivel de începător, se grăbesc să folosească impropriu denumirea de QA engineer, al cărei înțeles adesea le scapă. Și atunci, mă întreb în mod firesc: cât de încrezător poți fi în cariera pe care ai putea să o dezvolți, atâta timp cât îți este rușine să pronunți numele meseriei pe care o practici?

Pe de altă parte, în mediul nostru sunt încă manageri de proiecte implicați în recrutarea de testeri, care minimizează rolul pe care un tester trebuie să și-l asume pentru asigurarea calității produsului software, ajungând astfel să omită a cere cunoștințe tehnice candidaților la această poziție. În consecință, dezvoltarea oamenilor profesioniști în asigurarea și controlul calității are de suferit. Ținând cont de faptul că între multitudinea de produse software care pot fi găsite pe piață calitatea este cea mai importantă, creșterea și dezvoltarea profesioniștilor în domeniu are o importanță majoră. Ca urmare, atunci când căutăm oameni care să exercite meseria de tester sau căutăm un loc de muncă în domeniu, trebuie să privim dincolo de nevoile imediate ale proiectului.

Cerințele pe care le avem la angajarea unui

42

tester, trebuie să fie de așa natură încât să sprijine dezvoltarea carierei.

Cu riscul de a vorbi despre lucruri bine știute, să începem prin a reaminti faptul că Managementul Calității produsului software este realizat prin corelarea și conlucrarea a două ramuri mari, care interferă, rămânând diferite în esența lor: Asigurarea Calității care are ca scop câștigarea încrederii că cerințele de calitate vor fi îndeplinite, având orientare spre proces și folosind ca pârghii: • Standarde, • Proceduri, • Audit, • Planificare.

Controlul Calității care are ca scop verificarea faptului că cerințele de calitate ale produsului sunt îndeplinite folosind: • Tehnici de testare, • Raportarea defectelor, • Evaluare prin măsurare și control, • Ghidarea procesului, • Identificarea uneltelor folosite.

a testelor (manual sau automat). Această etapă, ținând cont de curba de învățare, trebuie să fie de scurtă durată. De aceea, pretențiile pe care le avem la angajare e bine să aibă în vedere, pe lângă nevoia imediată de a avea un junior tester, perspectiva profesională pe care o avem de oferit.

La acest nivel de experiență, în general, nu putem vorbi despre QA engineering, lucru care presupune optimizare de procese și planificare.

Apoi, în calitate de testeri, ne dezvoltăm abilitatea de control al calității unei cerințe funcționale, în concordanță cu cerințele generale de calitate ale produsului, prin acoperirea cu un volum necesar si suficient de teste. Pentru a parcurge această etapă, este nevoie de o bună cunoaștere a aspectelor tehnice și funcționale ale unei componente precum și de cunoașterea tehnicilor de testare. Privind etapa menționată anterior ca un prim pas în evoluția carierei, dacă este ușor de parcurs, satisfacția și implicit motivarea noastră se reflectă într-o atitudine pozitivă. Timpul în care realizăm acest progres este, în general, strict corelat cu bagajul de cunoștințe tehnice pe care îl avem în diferite domenii cum ar fi: • Programare, • Sisteme de operare, • Rețele de calculatoare, • Tehnici de testare, • Test scripting, • Procese de dezvoltare.

În timp ce Asigurarea Calității produsului software este în responsabilitatea factorilor decizionali, Controlul Calității este responsabilitatea testerilor. Ținând cont de aceste aspecte, să identificăm modul de implementare pentru a sprijini dezvoltarea unei cariere în Managementul Calității. În general, primul pas în carieră este acela de junior tester, care adesea primește Buna cunoaștere a procesului și atenția sarcini de verificare a defectelor și rulare acordată respectării acestuia, personal și de

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE către ceilalți membri ai echipei, precum și o atenta estimare și o corectă măsurare a calității funcționalității testate, contribuie la procesul de asigurare a calității produsului.

Cunoașterea produsului din punct de vedere al utilității, al arhitecturii funcționale și tehnice precum și învățarea tipurilor și tehnicilor de testare funcțională și non-funcțională este un pas important pe care trebuie să îl parcurgem în procesul de creștere profesională. Pentru facilitarea acestuia, trebuie să avem o preocupare continuă în: • Ap r o f u n d a r e a ș i e x t i n d e r e a cunoștințelor tehnice, • Dezvoltarea abilităților de test design pentru diferite tipuri de testare, • Însușirea cunoștințelor legate de unelte de testare, raportare și măsurare a calității produsului, • Aprofundarea cunoștințelor legate de procesele de dezvoltare.

software, ne vor ajuta în elaborarea unei strategii care să asigure o calitate competitivă a acestuia. Succesul strategiei de testare este în strânsă interdependență cu implementarea corectă a procesului de dezvoltare, fapt pentru care, implicarea noastră ca testeri în buna desfășurare a procesului, devine iminentă.

Ajunși în acest punct, după ce am parcurs drumul cu răbdare și dedicație, putem vedea perspectiva cu claritatea și siguranța pe care o dobândesc profesioniștii.

Dezvoltarea poate continua în zona managementului, cea de arhitectură funcțională sau analiză de business la fel de bine cum poate continua în zona de programare sau consultanță. Totul depinde de abilitați, de dedicare și scop.

Dezvoltarea unei cariere în testare până la a ajunge un factor decizional responsabil pentru asigurarea calității, se poate face doar folosind aceleași cunoscute ingrediente: • Implicare personală , • Pro-activitate, • Însușirea continuă a cunoștințelor tehnice, • Înțelegerea rolului în contextul proiectului, • Învățarea și aplicarea proceselor, • Îmbunătățirea continuă a abilităților.

Dacă privim lucrurile din perspectiva asigurării calității, acum putem vorbi despre o contribuție adusă acesteia prin planificarea tipurilor de testare, vegherea procesului având opinii pertinente legate de eventualele derapaje apărute, precum și idei de îmbunătățire sau adaptare a acestuia. În continuare, ne putem implica în elaborarea planului de testare, având în Un avantaj important pe care îl putem vedere toate caracteristicile funcționale și avea este șansa de a face parte dintr-o non-funcționale ale produsului precum și echipă care să ne susțină și să ne ajute prin: caracteristicile businessului căruia acesta • Training, îi este dedicat. Cunoașterea uneltelor de • Coaching, testare, măsurare și raportare a caracteristi• Integrarea idealurilor personale în cilor de calitate specifice rolului produsului scopul echipei.

Să revenim asupra ideii că printre multitudinea de produse software existente pe piață, ceea ce contează este calitatea.

Experiența a dovedit că pentru a ocupa un loc de top în această competiție este nevoie de un proces bine implementat și mulți profesioniști atât în managementul de proiect, în arhitectură și programare cât și în managementul calității. Produsul este un întreg al cărui rotunjime este dată de toate acestea la un loc.

Maturizarea managementului care începe să se facă simțită și în comunitatea noastră, vine în sprijinul rolului pe care Managementului Calității îl are în succesul produselor software și în consecință, a dezvoltării de specialiști în domeniu, așa încât povestea pe care am spus-o are tot mai multe exemple concrete.

Pentru a crește și a ne dezvolta ca profesioniști QA, trebuie să ne dăm șansa de a înțelege meseria de tester cu nevoile și potențialul ei. Să încetăm a o privi ca o alternativă pe care o alegem pentru că nu suntem încă destul de buni să facem altceva sau ca pe un rol de “ajutor de developer”, pentru că, dincolo de aceste înțelesuri izvorâte din superficialitate și necunoaștere, se află o carieră frumoasă pe care o putem dezvolta foarte departe, cu efort și dedicare.

Mihaela Claudia

mihaela-claudia.chis@hp.com Senior QA Engineer @ HP România

www.todaysoftmag.ro | nr. 24/Iunie, 2014

43

prezentare

Farmecul și provocările dezvoltării unui software de calitate

S

crierea unui software de calitate nu este o sarcină ușoară. Există multe situații neașteptate la care trebuie să fii cu ochii în patru.

Gama posibilelor dificultăți este cu adevărat infinită și poate varia de la înțelegerea greșită a cerințelor reale ale proiectului și pierderea unor oportunități bune de design, până la a nu avea o interacțiune corectă și eficientă cu restul membrilor echipei.

Lucrurile devin și mai neplăcute în cazul proiectelor complexe, iar simplul fapt că nu îți place limbajul de programare ales pentru dezvoltare poate fi proverbiala picătură care umple paharul.

Vă invit să identificăm caracteristicile disciplinelor de dezvoltare software care înlesnesc membrilor echipelor de dezvoltare să se simtă bine şi să fie implicați în scrierea unui software de calitate. Începem studiul nostru analizând: • Calitatea software-ului, • St are a d e bi ne ș i i mpl i c are a participanților, • Considerațiile practice.

Să începem cu starea de bine și implicarea (în această ordine) şi să discutăm mai apoi despre calitatea software-ului şi considerațiile practice imediat ce contextul va fi potrivit. .

Starea de bine şi implicarea Ați observat cum toată lumea (sau poate aproape toată lumea) nu ratează nicio ocazie pentru a se implica cu plăcere în spargerea bulelor de aer de pe foliile de ambalat (bubble wrappers)? De ce se întâmplă asta? Ce face ca ambalajul cu bule de aer să fie atât de atractiv încât oamenii spun adesea că îi ajută să se relaxeze și că este o activitate nestresantă? Oare forma fină cu multe bule este cea care îl face interesant, sau este altceva?

Răspunsul este destul de surprinzător,

44

neavând de a face de fapt cu ambalajul sau cu bule de aer în sine, ci cu însăși disciplina necesară pentru spargerea bulelor!

Dar cum poate fi vorba despre o disciplină, când, după cum bine știm, o disciplină presupune existența unor reguli și restricții care nu îți permit întotdeauna să faci cu plăcere ceea ce este necesar? Dacă gândiți așa, tocmai ați descris o disciplină care nu este pentru oameni. O disciplină pentru oameni trebuie să inducă ordine și armonie între produsul care este creat și persoana sau persoanele care îl creează. În fascinanta carte „Creativity: Flow and the Psychology of Discovery and Invention”1 , Mihaly Csikszentmihalyi descrie caracteristicile acestui tip de experiențe pozitive.

• Există scopuri clare la fiecare pas • Există feedback imediat la acțiunile executate.

• Există un echilibru între provocări și competențe.

• Fiecare acțiune este conștientizată.

• Sunt eliminate sursele de distragere a atenției.

• Nu există teamă de eșec.

Când toate cerințele de mai sus sunt satisfăcute, oamenii se simt bine executând acel task, iar implicarea (ceea ce autorul denumește flow) nu este decât la un singur pas: • Conștiința de sine este suprimată.

1 h t t p : / / w w w . a m a z o n . c o m / Creativity-Flow-Psychology-Discovery-Invention/dp/0060928204

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

• Pe r c e p e r e a t i m p u l u i d e v i n e distorsionată.

• Activitatea devine autotelică (ceea ce înseamnă că ne place activitatea doar pentru a o face și nu pentru rezultatul ei final).

Ca de obicei, indicațiile și sugestiile potrivite ne fac să vedem faptele într-o lumină nouă și putem să analizăm în continuare efectele spartului bulelor de aer drept efectele unei discipline având caracteristicile de mai sus.

Evident, există scopuri clare la fiecare pas, deoarece ceea ce trebuie să faci este să spargi câte o bulă pe rând (sau două sau trei, nu te oprește nimeni), poți doar spera că folia nu va rămâne niciodată fără bule.

Există feedback imediat pentru acțiunile tale, faptul că o bulă se sparge înseamnă că ești pe drumul cel bun, acest feedback simplu îți dă sentimentul de confort și relaxare (care acționează eliberând stresul).

Există un echilibru între provocări și competențe pentru că provocările pot fi soluționate prin utilizarea degetului mare și a aplica o oarecare presiune pe ambalaj.

Fiecare acțiune este conștientizată. Ești atent la ce se întâmplă cu ambalajul cu bule.

Dacă o bulă nu se sparge, poți oricând să încerci din nou prin aplicarea unei presiuni ușor mai mare.

Sunt eliminate sursele de distragere a atenției. Imaginați-vă că folosiți ambalajul și cineva vă întreabă dacă îl poate

TODAY SOFTWARE MAGAZINE împrumuta (astfel de încercări pot pune capăt prieteniilor!).

Nu există teama de eșec. V-a fost vreodată teamă că nu veți reuși să spargeți o bulă? Pariez că nu. Teama de eșec este una dintre modalitățile cele mai bune de a ne inhiba capacitățile cognitive, de aceea trebuie evitată.

Fiecare dintre cele șase caracteristici este necesară pentru ca starea de bine să apară. Este suficient să ignori numai una dintre ele și lucrurile se pot schimba dramatic. De exemplu, există anumite ambalaje cu bule în care bulele comunică (bulele nu sunt izolate unele de altele), astfel încât prin aplicarea presiunii asupra unei bule, aerul va fi transferat către bula următoare, făcând imposibilă spargerea manuală. Aceasta cauzează un ușor dezechilibru între provocări și aptitudini, transformând sarcina într-una cu adevărat frustrantă, pentru că bulele nu se vor mai sparge fără ajutorul unui instrument adecvat. Eu cred că această observație simplă confirmă ideea că stare de bine și implicarea nu se datorează ambalajului, ci disciplinei din spatele activității respective.

Poate că vă întrebați ce legătură aceasta cu disciplina dezvoltării de software.

Răspunsul este chiar în fața noastră. Nu ar fi frumos ca job-ul fiecăruia, poate contrar așteptărilor, să fie un motiv de relaxare? Aceasta situație nu este rezervată doar celor norocoși. Pentru a te bucura de proiectul tău și a deveni implicat total

în el, mai întâi, cele șase principii trebuie În articolul următor vă invit să descosă fie ținta disciplinei tale. Odată ce aceste perim cum putem îmbina starea de bine principii sunt acolo, după cum se întâmplă și implicarea pentru a crea o disciplină în adesea în lumea reală, trebuie să fii atent și scopul dezvoltării unui software de calitate. să faci ajustări pe parcurs, astfel încât, pe cât posibil să nu deviezi de la ele pe parcursul proiectul. Acesta necesită antrenament și nu este numai sarcina managerilor, ci a întregii echipe, deoarece cu toții suntem responsabili pentru a face ca timpul petrecut în cadrul proiectului să merite.

[O scurtă notă despre Agile: unul din principalele motive pentru care modul de lucru Agile este atractiv este pentru că manifestul său ne permite să punem preț pe interacțiunea umană și pe softwareul funcțional și din nou pe interacțiunea umană fiind pregătiți oricând pentru a face față schimbărilor ce pot apărea (așa că nu ar trebui să vă îngrijorați cu privire la eșec).

Agile ne promite o disciplină a dezvoltării software-ului care implementată bine conduce la satisfacerea celor șase principii.] În concluzie, starea de bine și implicarea aduc beneficii uriașe proiectelor și persoanelor care lucrează pentru a le transforma în realitate (gândiți-vă de exemplu la îmbunătățirea creativității și a capacității de inovare). Fiecare dintre noi trebuie să Cătălin Tudor lupte pentru a le realiza, acordând atenție ctudor@ixiacom.com felului în care ne planificăm și executăm sarcinile zilnice în conformitate cu cele șase Principal Software Engineer principii. @ Ixia

www.todaysoftmag.ro | nr. 24/Iunie, 2014

45

opinii

Ce este în neregulă cu IT-ul din România?

D

ezvoltarea și direcția industriei de IT din România și în special din Cluj Napoca, este un subiect care m-a preocupat în mod constant. Sunt genul de persoană care încearcă să descopere imaginea de ansamblu, să înțeleagă mecanismul și cum funcționează el ca să îl pot optimiza.

Ca să ne facem o idee despre fragilitatea mediului de afaceri din ziua de azi, în anii 1900 durata medie de viață a unei companii era de 80 de ani, în anii 1950 ea s-a redus la 50 de ani pentru ca ultimul studiu din 2011 să ne arate ca ea s-a redus la doar 8 ani. Acest trend abrupt ne demonstrează volatilitatea pieței de azi și cât timp au la dispoziție companiile pentru a lua decizii majore care să le alinieze schimbărilor din mediul de afaceri.

Cazul nostru particular, al industriei de IT, este unul special și dificil. În acest moment în cele 5 orașe principale din România în domeniul IT (București, ClujNapoca, Iași, Brașov, Timișoara) lucrează în jur de 80.000 de angajați în industria noastră. Cunosc companii din India care au mai mulți angajați decât toată țara noastră. Iar aceasta e o problemă și o provocare pentru noi.

Devine din ce în ce mai evident că dezvoltarea industriei noastre nu (mai) poate fi făcută prin volum. La început, și chiar și acum în unele cazuri, multe companii de IT se bazau pe o creștere a numărului de angajați de două cifre anual. Majoritatea muncii fiind bazată pe ore (așa zisul model de capacitate sau de outsourcing), această creștere însemna în termeni matematici, mai mulți oameni – mai multe ore – mai mult venit. Destul de simplu, dar acest model a pus o presiune incredibilă asupra forței de lucru cauzând o severă lipsă de personal. Aproape am epuizat așa-zisa “resursă” după cum departamentele de HR ar eticheta-o. Folosirea la extrem a modelului de capacitate a creat două probleme majore în lumea IT-ului românesc.

Oamenii calificați ce muncesc în această industrie reprezintă prima problemă. De fapt mai bine aș zice că lipsa lor este prima problemă. La ora actuală studiile

46

din Cluj-Napoca arată că ținând cont de rata de promovabilitate a universităților de profil plus oamenii care se mută în oraș, forța de munca va putea acoperi peste 5 ani abia 52% din totalul necesarului la acel moment. Această estimare ține cont de previziunile de creștere a companiilor ce există în acest moment pe piață (fără să ia în calcul companiile noi care se vor înființa).

Această situație este comparabilă și în restul centrelor de IT din România. Având în vedere cererea ridicată pentru forță de muncă calificată presiunea pe salarii s-a mărit în mod constant în ultima perioadă până la un punct în care devine dăunătoare. În lupta pentru angajați, firmele sunt dispuse să plătească din ce în ce mai mult.

Pentru angajați aceasta înseamnă că oricând există cineva dispus să plătească mai mult. O persoană poate să schimbe locul de muncă relativ rapid și cu o mărire salarială de fiecare dată. Aparent suntem într-o licitație constantă, care cauzează de exemplu concursuri pe Facebook cine ajunge primul la xxxx EUR salar. Nu mă înțelegeți greșit, nu am nimic împotriva drepturilor angajaților și a salariilor ridicate, o piață unde angajații dețin controlul nu este rea în sine, dar când un angajat schimbă locul de muncă cu o creștere de salariu, dar fără să adauge cunoștințe sau abilități noi, aceasta este o problemă majoră. Oamenii sunt din ce în ce mai puțin învățați să învețe lucruri noi sau să rafineze cele pe care le au deja pentru că pot găsi o slujbă mai bine plătită cu relativ puțin efort. Totodată când un angajat își exprimă dorința de a pleca, aproape întotdeauna angajatorul va veni cu o contra-ofertă. Această practică a contraofertelor nu este restrânsă la industria de IT sau la România, dar livrează un mesaj contradictoriu: de fapt spunem angajatului că “valorezi mai mult, dar până în

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

acest moment te plăteam mai puțin, dar acum îți vedem adevărata valoare”. Nu este o regulă, dar această luptă pe piața muncii încurajează un comportament de mercenariat, care are un impact asupra așa zisei productivități (și totodată asupra creativității și eficienței). Având costurile care urcă (mult) mai repede decât valoarea adăugată a serviciilor prestate înseamnă că per ansamblu ei industria de IT devine din ce în ce mai puțin atractivă față de alte țări din jurul nostru, sau având în vedere cuvântul cheie al secolului nostru, globalizarea, competiția este peste tot și nu doar restrânsă la Europa de Est. Nu cu foarte mult timp în urmă cursa pentru remunerație crescând fără aptitudini suplimentare a fost cea care a cauzat restructurarea industriilor de IT din multe țări din Europa de Vest și America și totodată unul din motivele care a cauzat companiile să se re-orienteze către țări ca și a noastră.

Modelul folosit este a doua problemă în special pentru că este unul ce se învârte în jurul orelor. Mai multe ore vândute înseamnă mai mult venit. Acest tip de muncă implică activități de codare și de testare în principal și pune mai puțin accent pe lucruri de genul arhitectură, specificații, design sau interfețe. Parțial aceasta are drept cauză interesul scăzut pentru ele. Din ce în ce mai multe companii realizează că fără a se dezvolta în zone care aduc mai multă valoare clienților ei nu pot deveni niciodată parteneri pentru clienții lor. Companiile încep să realizeze că a rămâne la nivel de furnizor de resurse este cel mai scurt drum către a-ți pierde clienții: oricând un client va găsi mai ieftin în altă parte. Fără capacitatea de a înțelege nevoile clientului, de a anticipa problemele lui și de a da soluții constructive o companie va deveni redundantă relativ rapid.

TODAY SOFTWARE MAGAZINE Companiile încep să exploreze zone ca serviciile, consultanță și produse pentru a se dezvolta. Acesta este pasul următor. Dacă ar fi să ne uităm la drepturile de proprietate intelectuală (deși nu există o statistică oficială în acest sens), foarte puțin rămâne în România. În general noi facem schimb de ore pentru venit, iar tot ce înseamnă drepturi de proprietate intelectuală rămâne la clienții noștri.

Dar cum poate o companie să treacă de la un model bazat pe capacitate la unul bazat pe servicii / produse? Acest subiect este unul vast și poate va face parte dintrun articol viitor, dar pe scurt în principiu este vorba despre a investi capitalul obținut din modelul de capacitate în dezvoltarea acestor servicii noi. Cuvântul cheie este a investi, iar această investiție trebuie să fie în primul rând în angajați. Pentru că angajații sunt cel mai de bază activ pe care compania îl are, ei sunt cei care trebuie să crească pentru a adopta această filozofie nouă. În acest moment în multe companii este un curent de opinie conform căruia datorită fluxului de angajări/plecări nu este benefic să investești în instruirea angajaților pentru că oricum urmează să plece. O persoană inteligentă a replicat la asta cu: “ce se întâmplă dacă nu investești în instruirea angajaților și ei nu pleacă?” Angajații și aptitudinile lor sunt cel mai important lucru într-o companie. Dezvoltarea unei companii este strâns legată de dezvoltarea angajaților ei.

Până acum am vorbit mult despre probleme și prea puțin despre soluții. Ca și în politică orice poate vorbi despre ce nu merge bine, asta e ușor. Să încerci să dai o soluție este partea mai dificilă.

Să vorbim despre calitate. Acest mic cuvânt pe care îl auzim atât de des în companiile de IT acompaniat de sintagme de genul “Calitatea nu este negociabilă”, “Calitatea este cea mai importantă”, Calitatea este cheia”, etc.. Dar în momentul în care întrebăm cum este ea definită, măsurată și care este nivelul ei curent și tendințele viitoare, majoritatea oamenilor

ridică din umeri, ei consideră că este suficient să vorbești despre calitate pentru ca ea să se întâmple (dar aceeași oameni vor ține sub un control foarte strict orele și bugetul).

Răspunsul la problemele enunțate mai sus stă în calitate: a înțelege ce înseamnă ea, a o putea măsura și urmări este primul pas spre rezolvarea problemei. Pentru că o dată ce am reușit aceasta, implementarea serviciilor și specializărilor despre care am vorbit devine mai ușor de realizat. Companiile, dar și fiecare individ în parte, trebuie să înțeleagă că nivelul lor de calitate este ceva propriu și este singurul diferențiator față de restul lumii. Este ceea ce îi separă de competiție și aduce noi clienți, sau îi face pe cei existenți să se reîntoarcă și să promoveze compania altor clienți. Când începem să povestim despre calitate, a plăti pentru funcționalitate și nu pentru ore, acesta este primul pas din ieșirea din capcana oameni-ore-venit. Întotdeauna putem găsi mai ieftin în altă parte, dar calitatea pe care o livrați este principala armă în lupta cu competiția.

O metodă de a mări nivelul de calitate dintr-o organizație este un program de îmbunătățire, după cum colegul meu Tibor Laszlo menționa în numărul 22 al revistei TSM în articolul “Improving-why bother? “. Orice metodă ați alege, axarea pe calitate este una din cele mai dificil de implementat schimbări într-o organizație pentru că este o schimbare de mentalitate.

Deși există câteva scurtături și beneficii pe termen scurt cu efort minim, o schimbare de genul acesta într-o organizație este dificilă pentru că implică oameni, psihologie și crearea unei schimbări durabile în modul în care oamenii gândesc și lucrează. Este o adevărată transformare.

Așadar, la final dacă sunteți un angajat al unei companii de IT puneți-vă următoarele întrebări: În momentul în care bula de pe piața muncii se va sparge în ce fel de companie doriți să vă aflați? O companie bazată pe ore unde sunteți văzut ca o resursă sau o

companie care investește în angajații ei, în instruirea lor și îi vede ca și activi?

Ce ați făcut în ultima vreme pentru a ridica nivelul de calitate a ceea ce livrați?

Iar dacă sunteți într-o poziție de a influența viitorul companiei: Cum vă veți asigura că firma va mai exista în 5 ani și ce faceți acum pentru asta?

Ovidiu Șuța ovidiu.suta@improving-it.com QA & Bid Manager @ ISDC

www.todaysoftmag.ro | nr. 24/Iunie, 2014

47

management

De ce copiii noștri nu visează să devină Project Manageri?

A

ceasta a fost întrebarea adresată de Jon Duschinsky – keynote speaker la Congresul Internațional organizat de Project Management Institute (PMI), la care am avut privilegiul să particip, la începutul lunii mai în Dubai. Jon a fost într-adevăr extraordinar și am să încerc să vă transmit câteva din puternicele mesaje insuflate de discursul lui.

Jon, votat recent al doilea cel mai influent comunicator în inovație socială din lume, fiind întrecut doar de Bill Clinton, își desfășoară activitatea în principal în filantropie și inovație socială. El, împreună cu câteva dintre cele mai creative și inteligente personalități din lume, a fondat o organizație numită “Ferma conversației” (The Conversation Farm), care folosește creativitatea ca să rezolve probleme globale. Ei sunt angajați de companii și de organizații de caritate pentru a veni cu idei sclipitoare care să implice milioane de oameni, să determine o interacțiune între aceștia care să rezulte în schimbări de atitudini și comportamente.

Jon menționează foarte des cuvântul “conversații” și nu se referă la conversația pe care o aveau predecesorii noștri la întâlniri, petreceri și alte evenimente mondene ale vremurilor, ci la ceva mult mai mare: o conversație care nu avea cum să se întâmple acum 10 ani când începea să se vorbească despre Web 2.0 la prima conferință pe această temă și când Mark Zuckerberg abia fonda Facebook împreună cu cei câțiva colegi de la Universitatea Harvard și Twitter nici nu exista!

Amploarea “conversațiilor” din ziua de azi este într-adevăr incredibilă datorită pe de o parte schimbărilor în plan tehnic care permit “crearea internetului” în timp real și accesul incredibil de ușor la internet de pe dispozitivele mobile, iar pe de altă parte datorită uriașelor comunități formate de popularele site-uri de socializare globale și cele regionale (să nu uităm de Weibo și Vkontakte care împreună se apropie de 1 miliard de utilizatori). Dar probabil știți deja aceste lucruri…

48

Revenind la întrebarea din titlul acestei povestiri, Jon crede că o parte din soluția la problema menționată este să pornim conversații. Ce fel de conversații? veți întreba. Despre ce facem? Nicidecum!

Dacă îi spui copilului tău că tu în fiecare zi ai grijă ca echipa să livreze la timp și încadrându-se în buget, că urmărești riscuri, scrii rapoarte și negociezi cu stakeholderii o să înțeleagă ceva? Nimic!

Mai mult, credeți că va visa să devină și el “Project Manager”? Nici măcar nu va reuși să pronunțe aceste două cuvinte! Nu că ar ști să pronunțe “astronaut”, dar dacă stâlcește cuvântul “astronaut” măcar o să sune distractiv!

Problema este mesajul pe care îl transmitem. Prin definiția muncii noastre (sau mai bine spus “defect profesional”), ne concentrăm asupra detaliilor, asupra procesului, în loc să ne concentrăm asupra rezultatului care este vizibil și sperăm apreciat. Cum facem ca mesajul nostru să ajungă în adâncul sufletului copiilor noștri într-un asemenea fel încât să îi facă să își dorească să devină ca noi? Și cred că nu este greșit dacă merg mai departe și întreb cum facem ca echipa și întreaga noastră organizație să înțeleagă ce facem noi cu adevărat astfel încât să obținem sprijinul lor, absolut necesar să ne atingem obiectivele propuse?

Răspunsul este destul de simplu: trebuie să ne adresăm sufletului lor, emoțiilor lor.

Primul pas pentru a realiza asta este să înțelegem în ce credem - noi înșine și ca organizație. Care e motivația pentru care facem munca noastră de zi cu zi? De ce este important să pornim pe drumul deseori anevoios al unui proiect? În momentul în

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

care reușim să înțelegem aceste lucruri ne va fi mult mai ușor să ducem mesajul mai departe echipei noastre, să fim cu toții motivați să lucrăm împreună pentru același obiectiv. În dinamismul vremurilor “agile” în care trăim, nu ajunge să faci un proiect doar pentru scopurile lui prestabilite pentru că acesta poate deveni irelevant încă înainte să se încheie. Un proiect trebuie să se muleze pe valorile reale ale companiei care îl inițiază, la fel cum și noi trebuie să ne identificăm cu aceste valori. Dacă nu credem în proiectul nostru, nu are cum să aibă succes.

Spre exemplu, companii petroliere au încercat să se definească ca fiind aproape de comunitățile în care activează, dar în același timp au departamente întregi de juriști care lucrează pentru singurul scop de a ocoli legile pentru protecția mediului.

Fiind niște valori false, aceste campanii de îmbunătățire a imaginii lor au eșuat.

Așadar, dacă reușim să identificăm aceste valori autentice și să legăm proiectul nostru de ele, echipa nu doar va executa un proiect, ci va contribui la realizarea unor obiective mărețe, menținând relevanța proiectului.

Pasul al doilea ar fi să vedem pentru cine facem acest produs sau serviciu? Să ne identificăm cu cei care îl vor folosi, să le înțelegem nevoile, să identificăm motivația lor de a-l folosi și cum le influențăm noi viața prin acest proiect. Astfel pe de o parte va fi mult mai natural să livrăm ce trebuie, pe de altă parte putem fi siguri că va fi o “conversație” pozitivă despre ce am reușit să facem.

Al treilea pas este să oferim tuturor o modalitate de a se implica în conversație,

TODAY SOFTWARE MAGAZINE ceva palpabil pe care ei îl pot face ca să participe la conversația noastră și cu care să îi influențeze și pe ceilalți.

Una din marile cauze la care a contribuit, după cum ne-a povestit în cadrul discursului său, a fost strângerea de fonduri substanțiale ce vor susține cercetări în vederea găsirii unui tratament pentru ALS – o boală degenerativă descoperită încă din 1896 care afectează milioane de oameni la nivel global, dar care până acum nu a primit niciun fel de atenție din partea cercetătorilor.

Jon crede că motivul de bază pentru care aceasta boală (ca multe altele de altfel – Parkinsons, cunoscută încă din 1817, malaria, care afectează un milion de oameni în fiecare an), nu a primit nici un fel de atenție, chiar dacă a fost descoperită de mai bine de 100 de ani, este pentru că nu au existat “conversații” despre ea.

Ca să confirme această teorie, Jon aduce exemplul HIV/SIDA, descoperită recent (în 1981), dar pentru care în doar 9 ani a fost găsit un tratament ce are drept efect ameliorarea substanțială a efectelor bolii, chiar dacă nu aduce vindecarea totală a bolnavului.

Jon și “Ferma conversației” au fost rugați de Steve Gleason, un celebru fost jucător de fotbal american bolnav de ALS, să “schimbe conversația” despre această boală. Steve a creat un clip video de un minut în care foști colegi de echipă și antrenori din New Orleans (orașul natal al lui Steve) vorbesc cu cuvintele lor despre efectele bolii asupra oamenilor, despre cum îți fură viața puțin câte puțin. Până acum nimic inovativ, au mai fost atâtea campanii similare care nu au avut efecte remarcabile.

Acest clip, în schimb, a fost făcut în așa fel încât să atingă latura emoțională a oamenilor. Partea incredibilă a acestei povestiri este că acest scurt film nu a fost difuzat la televiziune, ci locația lui a fost

trimisă prin email către patru jurnaliști de la New York Times, CNN, USA Today și ESPN cu câteva zile înainte de ediția 2013 a “Super Bowl”-ului. Astfel a ajuns în fața ochilor a zeci de milioane de oameni arătând puterea pe care o are social media în ziua de azi.

Această “conversație” a avut drept efect postarea a peste 8 milioane de mesaje pe cunoscuta rețea de socializare Twitter și aceasta doar pe durata meciului menționat anterior! Rezultatul a fost răsunător, în 48 de ore fiind strânse câteva milioane de dolari dedicate cercetării. La scurt timp după eveniment, 150 de cercetători s-au strâns în aceeași încăpere să discute despre pașii care trebuie urmați, iar la mai puțin de un an după aceea câteva universități importante din SUA făceau deja un plan de afaceri pentru găsirea unui tratament pentru ALS. În concluzie, cei care au lucrat pentru această campanie au crezut în ea, s-au identificat cu cauza ALS-ului, au creat un mesaj simplu pe care l-au adresat inimilor oamenilor și prin care oamenii au înțeles ce înseamnă această boală, le-a oferit acestora o modalitate prin care să se implice – să transmită mesajul mai departe și să contribuie financiar și în acest fel au schimbat conversația despre ALS. Amploarea conversației a motivat cercetătorii, mobilizându-i să își întreprindă activitatea cu scopul suprem de a găsi un tratament pentru această boala.

Mesajul transmis este că trebuie să ne schimbăm modul în care vorbim despre Project Management. Trebuie să schimbăm conversația, să îi facem pe cei de lângă noi să vadă lumea noastră diferit. Și dacă reușim să facem aceasta, o să reușim mult mai mult decât plănuiam: echipele noastre vor fi mai motivate pentru că vor înțelege care e scopul muncii lor, ceilalți stakeholder-i vor fi mai aproape de proiect,

iar noi înșine vom înțelege pentru ce fel de organizație lucrăm, de ce facem un proiect și care e scopul măreț la care vrem să ajungem.

Laurențiu Toma, PMP laurentiu.toma@softvision.com Project Manager @ SOFTVISION

www.todaysoftmag.ro | nr. 24/Iunie, 2014

49

programare

C

„Cloud” – perspectiva contează!

loud este probabil unul dintre cei mai folosiți termeni în industria IT a acestui deceniu, dar ce înseamnă, de fapt, norișorul? Încă de la începuturile ei, rețeaua „Internet” a fost reprezentată vizual, în diagrame, printr-un nor, arătând astfel faptul că ea este oferită ca serviciu, fără a dezvălui informații legate de implementarea tehnică, ea oferind doar o interfață de comunicare cu alte rețele. Iată în imaginea alăturată un exemplu de astfel de diagramă: avem mai multe elemente pe care le cunoaștem (firewall, web server, utilizatori – vezi fig . 1) și apoi un element care ne este oferit ca serviciu, așa cum am descris mai sus.

Acest element este Internetul, reprezentat printr-un norișor. Cei mai mulți utilizatori nu cunosc detalii despre cum funcționează Internetul ca rețea. Ei știu că au la dispoziție o interfață de accesare a lui (o rețea fără fir, un cablu de date etc.) și se pot folosi de el în activitățile de zi cu zi.

Evident, aceasta este utilitatea serviciilor de Cloud pentru utilizatorii casnici.

Pe de altă parte, există și alte tipuri de utilizatori. Unul dintre partenerii noștri a dezvoltat o aplicație pentru organizații guvernamentale locale, pe care o numește „Government as a Service”. Vânzările aces-

tei aplicații se bazează, evident, pe magicul cuvânt „Cloud”.

Angajații administrațiilor locale (pentru că lor le este destinată aplicația) au la dispoziție o aplicație web pe care o vor folosi intens în munca de zi cu zi, aplicație care le pune la dispoziție toate instrumentele de care au nevoie în serviciile pe care le oferă cetățenilor (ex. înregistrare de nașteri, decese, căsătorii și altele).

Aplicația va fi găzduită de către producătorii softului – tot ce au nevoie administrațiile locale este un computer pentru fiecare angajat, conectat la rețea.

Putem spune că este un serviciu de tip Cloud, din punctul lor de vedere? Cu siguranță! Nu îi interesează prin ce firewall-uri trec conexiunile, unde și cum sunt stocate datele (cel puțin nu pe angajații de la ghișeu), nu trebuie să facă nici un fel de mentenanță la nici un fel de sisteme, nu au nici un fel de interacțiune cu nimic decât cu ceea ce au ei nevoie: instrumentele de procesare a datelor și evenimentelor de stare civilă. Mai pe scurt, se conectează la

50

Cloud și fac treabă!

Putem spune același lucru despre firma care produce softul? Ce înseamnă Cloud pentru ei? Aplicația este, în mod evident, un produs al lor, ei oferă suport, fac mentenanță pe ea, știu exact cum funcționează fiecare bucățică, iar diagrama de arhitectură este una complexă.

Dar, dacă ne uităm pe diagrame, ar trebui, totuși, să vedem câte un norișor. Ar trebui să existe un serviciu specializat de platformă de aplicații (PaaS). O săgeată țintește, pe diagramă, din mediul de dezvoltare al firmei (de ce nu, poate chiar de pe computerul programatorilor) direct către „Cloud”. Codul scris de dezvoltatori ajunge direct într-un mediu gata pregătit.

Nici programatorii, nici testerii, nici business analiști-i, nici nimeni altcineva nu este dependent de modul cum funcționează această platformă, ci doar de interfața pusă la dispoziție de prestatorul de servicii care oferă platforma (în general un set de APIuri). Analog, distribuitorul de platformă poate avea un distribuitor de infrastructură (IaaS), și tot așa.

De asemenea, nu este neapărat ca tot acest lanț sa fie extern, se poate ca aceste servicii să fie oferite pur și simplu de un alt departament al aceleași companii. De exemplu „băieții de la IT” oferă partea de Infrastructură, o echipă de „devops” oferă partea de platformă, iar programatorii își văd liniștiți de treaba lor.

Când vorbim despre servicii de tip „Cloud” ne gândim, din punctul de vedere al furnizorului, la atribute cum ar fi: • Agilitatea - posibilitatea de a putea realoca resursele de care dispunem. Dacă o municipalitate are licență de software pentru 10 utilizatori, poate șterge sau dezactiva contul unui angajat care a ieșit la pensie și crea unul nou.

• Existența unei API - ne putem crea programatic noi instanțe de platformă.

• Reducerea și controlul costurilor - prin faptul că știm exact pe ce plătim banii: număr de utilizatori activi,

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

procesor consumat, memorie consumată.

• Independență față de locație geografică - ne putem conecta de la birou, de acasă sau din biroul unui client la care ne aflăm.

• „Multitenancy” - nu avem nevoie de câte un server separat pentru fiecare client în parte, toți rulează pe aceeași aplicație.

• Fiabilitate și elasticitate - ne putem aloca singuri resurse în timp real, la nevoie.

O situație interesantă apare atunci când avem un soft care are funcționalitate asemănătoare cu cea a unui Cloud dar rulează pe o infrastructură care nu este „cloud-like”, multe din atributele descrise mai sus fiind emulate prin diverse soluții auxiliare, în cadrul aplicației. Putem vorbi, în acest caz, despre „Cloud”? Este suficient ca o aplicație să fie desenată în diagramele beneficiarilor serviciului ca pe un norișor ca să fie „cloud-based”? Eu consider că nu! Da, este oferită „as a service” dar dacă partea de scalabilitate lipsește (și este nevoie ca ea să fie implementată la toate nivelele!), atunci aplicația nu va putea susține perioade neașteptate de trafic mai mare, nu vom putea discuta despre o reducere a costurilor dacă nu putem scala automat resursele la nevoile curente. La fel și cu celelalte atribute care ajută la definirea unui „nor”.

Așadar, în funcție de perspectiva din care privim lucrurile (beneficiar vs. furnizor de servicii) și de specificul unui proiect, acest cuvânt poate avea mai multe semnificații, deci să nu ne lăsăm păcăliți de nori falși care nu aduc ploaia atât de necesară de funcționalitate de care are nevoie recolta noastră!

Florin Asavoaie florin.asavoaie@tss-yonder.com DevOps @ Yonder

programare

TODAY SOFTWARE MAGAZINE

PostSharp

Î

n ultimele săptămâni am descoperit împreună principiile de bază ale Programării Orientate pe Aspecte (AOP). Acum este timpul să vedem cum putem valorifica adevăratul potențial caracteristicile AOP utilizând PostSharp.

AOP

Înainte de a intra în subiect, să facem o scurtă recapitulare.

AOP este o paradigmă de programare care are drept scop principal creșterea modularității unei aplicații. AOP încearcă să atingă acest scop prin permiterea separării aspectelor secante(cross-cutting concerns) – utilizând interceptarea diferitelor comenzi sau cereri. În ultimele articole am descoperit cum putem utiliza AOP folosind Unity și proprietăți .NET 4.5 (RealProxy). Unity ne oferă posibilitatea de a înregistra acțiunile care pot fi executate înainte și după o acțiune specifică. Clasa RealProxy este clasa principală în jurul tuturor acestor proprietăți, care este utilizată de către framework-uri precum Unity pentru a oferi această proprietate.

Cea mai mare diferență dintre RealProxy și un stack care ne oferă AOP este din perspectiva proprietăților. Utilizarea RealProxy în mod direct ne va cere să scriem toată funcționalitatea de care avem nevoie – aceasta se poate traduce în timp, bani și mai mult cod care necesită mentenanță (în cele din urmă, nu dorim să reinventăm roata).

diferite fire de execuție (threads) și poziția (în prim plan sau în fundal).

Model Pattern Library – ne oferă proprietățile complete ale AOP utilizând interfața INotifyPropertyChanged. De toate setările și de celelalte lucruri se va ocupa PostSharp. Comportamentul mai complicat poate fi implementat foarte simplu când începem să utilizăm Code Contracts.

Architecture Framework –validează diferite aspecte ale calității codului și designului, șabloane de design, relații nucleu, analiză de cod și multe altele.

Odată menționate principalele proprietăți ale PostSharp, vă prezentăm partea tehnică și modul cum putem adăuga AOP în proiectul nostru, utilizând PostSharp.

Cum funcționează

Cea mai mare diferență între PostSharp și alte soluții AOP constă în modalitatea în care se adaugă comportament la comandă (custom behaviour). În general, acest comportament se adaugă în timpul de execuție, dar nu și în cazul PostSharp. Toate anexele PostSharp (hooks) sunt adăugate în timpul de compilare. Astfel, performanța PostSharp este primul framework nu este afectată prea mult. Bineînțeles, ca și în cazul oricărui cadru AOP real prezentat în această serie de AOP, performanța este afectată puțin, dar în cazul PostSharp, articole. Până acum ne-am uitat la diferite moduri în care putem performanța este aproape la fel ca și fără aceasta. utiliza proprietățile AOP, dar fără a utiliza un stack AOP real și dedicat.

Am decis să încep cu PostSharp, deoarece atunci când ai nevoie de un framework AOP pentru un proiect real care este destul de mare și de complex, mai întâi ar trebui să îți îndrepți atenția înspre PostSharp. Este tipul de framework care îți oferă aproape toate proprietățile AOP de care ai nevoie.

De obicei, eu compar PostSharp cu ReSharper din punctul de În principiu, PostSharp este o acțiune post-procesor, care ia vedere al calității produsului. Este tipul de produs care are toate codul care este compilat și îl modifică. Toate anexele (hooks) sunt proprietățile de care ai nevoie atunci când vorbești despre o pro- adăugate la acest nivel. Rezultatul compilatorului este preluat de prietate specifică.

PostSharp și prelucrat.

PostSharp are multe proprietăți care nu pot fi discutate într-un singur articol. În viitorul apropiat, vom studia separat fiecare din- Înainte și după tre aceste proprietăți, dar pentru moment, vom arunca o privire Utilizarea cea mai obișnuită a AOP este să execute o specificație asupra celor mai importante proprietăți care sunt în jurul AOP. înainte și după ce o metodă a proprietății este apelată (de exemplu, pentru logare). Aceasta se poate face foarte simplu utilizând Proprietăți PostSharp, cu câteva linii de cod.

Principalele proprietăți ale PostSharp sunt: Primul pas este să definim comportamentul pe care dorim să îl Threading Pattern Library – ne permite să controlăm nivelul executăm în acel moment anume. Acest lucru poate fi realizat prin de abstracție din jurul threading, să detectăm și să diagnosticăm extinderea OnMethodBoundaryAspect. Putem să supra-reglăm blocajele, să controlăm modul în care sunt executate acțiunile pe OnEntry, OnSuccess și OnException. În fiecare dintre aceste www.todaysoftmag.ro | nr. 24/Iunie, 2014

51

programare PostSharp metode, noi avem acces la parametri de intrare, la rezultat și așa atunci când este adăugată funcția de notificare. mai departe. Noi putem chiar să modificăm rezultatul apelării.

Pentru un cod mic, aceasta este acceptabilă, dar dacă ai o [Serializable] aplicație complicată, ai adăuga mult cod duplicat pentru a susține public class FooAOPAttribute : OnMethodBoundaryAspect această proprietate. { PostSharp rezolvă această problemă pentru noi, prin public override void OnEntry(MethodExecutionArgs NotifyPropertyChangedAttribute. Odată ce adăugăm această proargs) prietate clasei noastre prin Smart Tag, nu va mai trebui să ne facem { griji în privința notificărilor. PostSharp se va ocupa de restul. }

...

public override void OnSuccess(MethodExecutionArgs args) { ... }

public override void OnException(MethodExecutionArgs args) { ... } }

Din acest moment putem utiliza acest atribut pentru a adnota toate metodele pentru care dorim să avem această proprietate.

Bineînțeles, putem specifica lista metodelor și în alte feluri. Putem specifica lista metodelor din AssemblyInfo.cs, unde putem defini filtre personalizate pentru metodele pentru care am dori să avem această proprietate.

Injectare de cod Această proprietate ne permite să adăugăm cod la clasa noastră în timpul perioadei de rulare. Utilizând un atribut personalizat sau de la AssemblyInfo.cs, putem injecta cod specific în clasa noastră.

De exemplu, putem specifica ca o clasă să implementeze o interfață specifică sau putem injecta o metodă specifică de proprietăți. În exemplul de mai jos, vom descoperi cum putem injecta o proprietate specifică în clasa noastră.

[Serializable] public class FooAOPAspect : InstanceLevelAspect { public string FirstName { get; set; } }

[NotifyPropertyChanged] public class StudentEdit { public string FirstName { get; set; } public string LastName { get; set; } public string FullName { get

{

return FirstName + LastName); } } public string Email { get; set; } }

Ceea ce mi-a plăcut a fost suportul Transitive Dependencies.

Aceasta înseamnă că, dacă valoarea FirstName este modificată, se va declanșa o notificare și pentru FullName.

Dacă dorim să adăugăm un atribut specific tuturor claselor noastre dintr-un spațiu de nume (namespace), putem să o facem relativ ușor prin utilizarea atributului multicasting. Acest lucru se face direct în fișierul AssemblyInfo.cs și ne va permite să specificăm pentru care clase este nevoie să adăugăm un atribut anume.

Avem posibilitatea de a adăuga filtre, de a exclude anumite clase și așa mai departe. Bineînțeles, această setare multicasting poate fi făcută și direct din cod, utilizând IAspectProvider.

Ultimul lucru pe care trebuie să îl știți în legătură cu aceasta este că mai aveți de asemenea și alte atribute care pot fi utilizate pentru a ignora anumite proprietăți sau pentru a trata notificările într-un mod personal.

Code Contracts

După cum ne spune numele, Code Contracts (Contractele codului) ne oferă posibilitatea de a defini un acord la nivelul codului între apelare și metoda proprietății care este apelată. În acest fel, validarea input-ului nu va mai trebui să fie făcută cu un IF (dacă) personalizat. Este destul de asemănătoare cu validarea care poate [IntroduceMember] fi făcută prin ActionFilter și atributele de validare din MVC, de public string FirstName { get; set; } exemplu. Avantajul este că putem defini acest acord la orice nivel, de exemplu atunci când expunem o bibliotecă API. [FooAOPAspect] public class Student Cel mai simplu exemplu este verificarea NULL. De obicei, { când dorim să facem o verificare NULL, adăugăm un IF (dacă) în metoda/proprietatea noastră și dăm o excepție când valoarea } nu este NULL. Același lucru poate fi făcut dacă utilizăm atributul Codul IL care va fi generat va conține în interior proprietatea Required.

FirstName.

Vezi exemplul de mai jos:

INotifyPropertyChange Când lucrăm pe un desktop sau pe o aplicație nativă, trebuie să folosim această interfață pentru a putea primi notificații atunci când valoarea proprietății este modificată (pe UI sau în cod). De obicei, aceasta se face prin implementarea interfeței de mai sus.

Pentru a nu complica prea mult codul, o clasă de bază este creată

52

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

public class Student {

public void SetLastName([Required] string newLastName)

{ ... } }

TODAY SOFTWARE MAGAZINE Fără PostSharp ar trebui să verificăm în corpul mesajului valoarea input și să dăm o excepție. Imaginați-vă cum ar fi să scrieți același cod de 1000 de ori. Acest tip de atribute pot fi folosite și la nivelul proprietății sau al câmpului. Un lucru interesant este atunci când le folosim la valoarea câmpului. Atunci când setăm această valoare la valoarea câmpului sau a proprietății, nu este important de unde este setată valoarea (de exemplu, dintr-o altă metodă), verificarea pentru NULL va fi făcută. public class Student {

[Required]

private string _lastName = „Default”

public void SetLastName(string newLastName)

{

_lastName = newLastName; }

public string LastName

{

get { return _lastName; }

set { _lastName = value; } }

public void SetFullName(string newFullName)

{ ...

_lastName = lastName; } }

O parte din acțiunile de validare default sunt deja definite.

Oricând, noi putem defini propria noastră validare la comandă, prin implementarea ILocationValidationAspect. Avem metoda ValidateValue de care avem nevoie pentru a implementa, unde putem să facem validarea noastră personalizată.

Alte proprietăți Mai sunt și alte proprietăți grozave pe care încă nu le-am discutat, de la cea care ne permite să interceptăm evenimente, aspect compus, injectare de cod, tratarea excepțiilor, securitate, persistență obiect și multe altele. O altă proprietate care îmi place la PostSharp este posibilitatea de a specifica faptul că o interfață nu poate fi implementată de către alte ansambluri și poate fi doar utilizată.

Vă invit pe toți să vizitați web site-ul PostSharp și să îl încercați.

Licențe și costuri

Există trei tipuri de licențe PostSharp. Pentru uz individual, puteți folosi cu succes versiunea Express, care este foarte bună dacă doriți să învățați și să înțelegeți cum funcționează PostSharp.

Pe lângă versiunea Express, mai există cea Professional și Ultimate, care vin cu alte proprietăți care pot fi utilizate cu succes în producție.

Nu uitați că modelul cu licență este per dezvoltator și nu per produse dezvoltate, ceea ce înseamnă că puteți utiliza aceeași licență pentru 1 sau 100 de proiecte.

Concluzie

Bineînțeles că toate aceste proprietăți pot fi implementate de către noi, dar PostSharp ne oferă toate aceste lucruri de-a gata.

Este un stack AOP utilizat în întreaga lume, extrem de matur și de bun.

Radu Vunvulea

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

www.todaysoftmag.ro | nr. 24/Iunie, 2014

53

programare

Securizarea codului Opensource via Analiza Statică (I)

A

naliza de cod static (SCA)este analiza programelor de computer care se efectuează fără a executa programele utilizând frecvent un instrument automatizat. SCA a devenit o parte integrală a ciclului de viață a dezvoltării de software și unul dintre primii pași pentru a detecta și elimina din timp erorile de programare din faza de dezvoltare software. Deși instrumentele SCA sunt folosite în mod obișnuit în dezvoltarea de software patentat pentru a asigura calitatea software-ului, aplicarea unor asemenea instrumente la întinderea vastă de cod opensource reprezintă o provocare intensă, deși interesantă, mai ales atunci când codul opensource se regăsește în software-ul comercial. Chiar dacă au existat eforturi recente în această direcție, în lucrarea de față abordăm această provocare într-o oarecare măsură, prin aplicarea analizei statice pe un proiect opensource cunoscut, de exemplu, nucleul Linux. De asemnea, discutăm rezultatele analizei noastre și pe baza acestora, vom propune un flux de lucru alternativ care poate fi adoptat când software-ul opensource este integrat într-un proces de dezvoltare de software comercial. În continuare, vom prezenta beneficiile și provocările întâmpinate atunci când adoptăm fluxul de lucru alternativ propus.

Deși SCA nu este o tehnologie nouă, recent i s-a acordat multă atenție și este rapid adoptată ca o activitate integrată în ciclul Dezvoltării de software pentru a îmbunătăți calitatea, fiabilitatea și siguranța software-ului. Cele mai multe instituții de dezvoltare software patentat au o echipă dedicată de profesioniști pentru validarea software-ului, a căror responsabilitate include de asemenea rularea anumitor instrumente de analiză statică pe softwareul aflat în dezvoltare, fie într-un mediu agil, fie într-un model waterfall tradițional.

Instrumentele SCA sunt capabile să analizeze cod dezvoltat prin utilizarea mai multor limbaje de programare și framework-uri care includ, fără a se limita la Java, .Net și C/ C++. Indiferent dacă scopul este dezvoltarea de software pentru aplicații sau a unui soft integrat (firmware) critic pentru misiune, instrumentele de analiză statică s-au dovedit a fi unul dintre primii pași înspre identificarea și eliminarea erorilor din software și sunt indispensabile pentru succesul general al proiectului software.

Acestea fiind spuse, este clar că există în mod tipic fie interese comerciale și/ sau probleme de securitate implicate în brevetarea și aplicarea exhaustivă a unor instrumente scumpe de analiză statică în efortul de dezvoltare software cu posibilitate inexistentă sau foarte mică de eșec.

Ceea ce rămâne apoi drept un spațiu vid expansiv și neexplorat este tărâmul nesfârșit al codului opensource care este de obicei considerat a fi bine reexaminat, întrucât software-ul opensource a fost utilizat și reutilizat în nenumărate aplicații de către numeroase instituții academice și comerciale din toată lumea. „Expansivă indică faptul că adaugă în permanență cod sursă

54

nou și „neexplorat”, indică absența unei organizații dedicate, obiective, care să analizeze static fiecare linie de cod opensource.

Recent, companiile SCA au avut o inițiativă în această direcție. Dar chiar și așa, rata cu care versiunile mai noi ale softwareului opensource sunt lansate și actualizate reprezintă o barieră în calea unor asemenea eforturi. Deși un astfel de efort ar fi atribuit paranoiei de către mulți, este evident că declinul financiar și micșorarea bugetelor IT au făcut ca software opensource să intre în aplicațiile comerciale, de exemplu Linux, Apache, MySQL sau OpenSSL.

Figura 1. Segment de proces de dezvoltare software obișnuit, care incorporează analiza statică (2)

Fluxul de lucru convențional, în care rezultatul instrumentului SCA este inclus în pachetul de verificare software formal este după cum se arată în figura 1. În cele mai multe instituții de dezvoltare și testare software, chiar dacă produsul software luat în întregime este supus analizei dinamice, ca testarea fuzzing sau black box, iar codul software nou dezvoltat este supus analizei statice și unei verificări riguroase, codul opensource încorporat în software nu este supus unei analize statice sau unei verificări

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

asemănătoare codului patentat nou dezvoltat, așa cum este ilustrat în figura 1. De obicei, un binar al software-ului opensource necesar este încorporat în pachetul software complet. Probabil că aceasta se bazează pe presupunerea că software-ul opensource este mai sigur și cu mai puține defecte decât software-ul closed source, deoarece sursa este disponibilă gratuit, mulți oameni vor căuta defecte de securitate și alte erori în software într-un fel care nu se va întâmpla în lumea comercială. În ciuda faptului că această presupunere a trecut testul timpului și probabil nu poate fi dovedită drept greșită, ar fi totuși un exercițiu interesant să aplicăm instrumentele analizei statice la codul opensource și să analizăm rezultatele. Chiar dacă au mai existat anterior eforturi de a analiza static codul opensource utilizând instrumente SCA comerciale sau opensource, în lucrarea de față, încercăm să verificăm dacă anumite probleme ale codului pot fi detectate încă de la început prin SCA. Mai mult, propunem un flux de lucru alternativ care poate fi adoptat când se încorporează cod opensource într-un proces de dezvoltare de software comercial. Vom discuta beneficiile, provocările și posibilele compromisuri ale adoptării fluxului de lucru alternativ propus. Un asemenea efort va prezenta interes și pentru comunitatea de ingineri software și pentru comunitatea opensource în general. De aceea, pentru a experimenta, vom alege Klocwork Insight drept instrument preferat, deoarece este unul dintre liderii industriei în SCA. Vom alege un proiect opensource cunoscut, Linux kernel (nucleul Linux), pentru analiza noastră de cod. Apoi, vom începe să rulăm Klocwork Insight pe codul nucleu Linux și vom discuta rezultatele analizei noastre. În general,

TODAY SOFTWARE MAGAZINE Klocwork este un instrument reprezentativ pentru SCA, iar Linux este un proiect opensource reprezentativ pentru analiza noastră, care poate fi extinsă la alte instrumente SCA și alte proiecte opensource.

Organizarea lucrării

Restul lucrării este organizat după cum urmează: Secțiunea 2 oferă contextul alegerii codului Linux kernel pentru analiză și SCA utilizând Klocwork Insight. Secțiunea 3 discută rezultatele SCA. În secțiunea 4, vom discuta un flux de lucru alternativ care poate fi urmat când se încorporează software opensource într-un proces de dezvoltare de software comercial și vom discuta beneficiile și provocările întâlnite atunci când urmăm fluxul de lucru alternativ propus. În final, în secțiunea 5, vom trage concluziile, rezumând observațiile importante.

aplicare aceste verificări. Compilatoarele tipice, precum gcc, încorporează analiza statică într-o oarecare măsură în forma avertismentelor sau a erorilor raportate pe perioada procesului de compilare. Acestea necesită, în general, un efort minim și de asemenea, raportează cel mai mic număr de erori (bugs). În timp ce, pe de altă parte, verificarea formală a software-ului, de exemplu, utilizarea controlului model (model checking), este o abordare mult mai complexă către automatizarea SCA, care necesită o cantitate mai mare de efort, dar este capabilă să detecteze un număr mai mare de erori (bugs) de o complexitate ridicată. Chiar dacă verificarea formală nu este adoptată în mod extensiv în industria de software, din cauza legii diminuării profitului, există câteva sisteme de operare care sunt verificate formal, cum e micronucleul Secure Embeded L4 al NICTA (6).

Figura 2. Curbă tipică Efort –Beneficiu

PRELIMINARII A. Linux kernel (nucleu) Linux kernel este un nucleu de sistem de operare utilizat de către familia Linux de sisteme de operare asemănătoare cu Unix.

Este unul dintre exemplele cele mai evidente de software sursă liberă și deschisă și, deci, o alegere naturală pentru analiza noastră. Linux kernel este lansat sub licența GNU General Public versiunea 2 (GPLv2) și este dezvoltat de contribuitori din întreaga lume. Zilnic au loc discuții despre dezvoltare pe adresele de mail ale Linux kernel. Linux kernel a primit contribuții de la mii de programatori. Multe distribuții Linux au fost lansate pe baza nucleului Linux (8). Am ales pentru analiza noastră, versiunea Linux kernel 2.6.32.9, lansat în februarie 2010.

Analiza statică a codului (Static Code Analysis)

Unicul avantaj al analizei statice este abilitatea sa de a scana baze întregi de cod pentru a identifica erori logice sau de securitate. Este mult mai cuprinzătoare ca și rază de acțiune decât testarea sistemelor black-box. Totuși, anumite probleme sunt dependente de perioada de rulare și pot fi descoperite numai prin executarea codului, așa că analiza statică nu poate rămâne singură. O curbă reprezentativă efort – beneficiu pentru utilizarea unui instrument SCA este ilustrată în figura 2. Se observă faptul că pe măsură ce se aplică mai multe verificări, proporția de erori detectate crește odată cu creșterea cantității de efort necesar pentru a pune în

pentru utilizarea instrumentelor SCA (1)

În analiza noastră, utilizăm instrumentul Klocwork Insight pentru a efectua SCA (analiza statică a codului). Klocwork Insight este un instrument SCA care este folosit pentru a identifica probleme de calitate și securitate pentru C, C++, Java și C#.

Produsul include numeroase desktop plugins pentru dezvoltatori, un instrument de analiză arhitectură, metrici și raportare.

Este suportat pe platformele bazate pe MS Windows și Linux OS (3). În general, cele mai multe verificări cu instrumente SCA includ în mod tipic declarații neutilizate, contradicții / incompatibilități de dactilografiere, utilizare înaintea definiției, cod inaccesibil, valori raportate ignorate, căi de execuție fără întoarcere, bucle infinite asemănătoare și cazuri fall through. Verificarea poate fi configurată și de asemenea poate fi personalizată pentru a selecta ce clase de erori sunt raportate. În plus, verificări la comandă pot fi create de către utilizator pentru a găsi condiții specifice într-o anume bază de cod. De obicei, fișierul de

configurare a regulilor de utilizare a instrumentului SCA poate fi editat pentru a captura probleme specifice în codul sursă.

De exemplu, fișierul de configurare reguli de utilizare Klocwork poate fi actualizat cu reguli de verificare pentru a semnala utilizarea unor API-uri interzise de pe lista de API-uri interzise (banned.h) a Microsoft Security Development Lifecycle (SDL).

Această libertate de a edita fișierul de configurare asigură integrarea unor verificări mai eficiente sau mai specifice proiectului în rezultatele SCA. Pe măsură ce se depune mai mult efort pentru ajustarea instrumentului SCA la codebase și native compiler, rezultatele verificării sunt mai bune. În general, cele mai multe instrumente SCA sunt concepute să fie flexibile și să permită programatorilor sau celor care analizează calitatea să selecteze puncte adecvate pe curba efort-beneficiu pentru proiecte specifice. Pe măsură ce sunt porniți diverși verificatori, numărul erorilor care pot fi detectate crește dramatic; aceasta poate avea drept rezultat și alarme false. Alarmele false (false positives) pot fi reduse prin editarea regulilor de verificare din fișierele de configurare, activând verificatorii ceruți și dezactivându-i pe cei care nu sunt necesari proiectului. Instrumentele SCA pot fi făcute să înțeleagă mai bine semantica unei funcții sau metode date dacă sunt configurate să înțeleagă cuvintele cheie speciale care pot fi utilizate de către native compiler și prin adăugarea mai multor informații în baza de cunoștințe a instrumentului. Astfel, utilizatorii pot defini noi reguli și verificări asociate pentru a extinde verificarea instrumentului SCA sau pentru a aplica proprietăți specifice aplicației. În general, procesul de construcție automatizat care încorporează SCA poate fi divizat în două etape. Prima etapă implică generarea unui fișier de „specificații de construcție” (build specification), care este generat drept parte a procesului de compilare și stabilire de legătură. A doua etapă implică rularea instrumentului de analiză statică pe rezultatul link-ului (link output), adică fișierul build specification pentru a genera rapoarte de analiză statică. Klocwork prezintă rezultatele analizei statice via browser window, de exemplu Internet Explorer, Mozilla Firefox, a căror interfață utilizator poate fi personalizată într-o oarecare măsură.

Raghudeep Kannavara

raghudeep.kannavara@intel.com Security Researcher, Software and Services Group @Intel USA

www.todaysoftmag.ro | nr. 24/Iunie, 2014

55

programare

Avantajele programelor libere

F

olosirea programelor libere (Free/Libre Software) conferă multe avantaje persoanelor și organizațiilor care fac acest lucru, mai ales dacă acești utilizatori sunt tehnici . Acest articol prezintă aceste avantaje și va încerca să alunge câteva dintre miturile format în jurul programelor libere.

Ce este un program liber?

Un program liber este un program (software) care respectă libertățile tale1 (ale utilizatorului). În engleză de obicei se folosește formula ”Free/Libre” pentru a sublinia faptul că nu vorbim despre preț ci despre drepturile utilizatorului. Din fericire în română avem cuvinte distincte pentru cele două concepte. Programele libere pot fi vândute comercial - cea ce o să menționăm și mai încolo în articol.

Există patru libertăți esențiale pentru programe, așa cum ele sunt definite de către Free Software Foundation. În ceea ce urmează vom analiza fiecare dintre libertăți și vom vedea de ce sunt ele importante pentru noi ca oameni tehnici.

Libertatea 0

Libertatea de rula programul, în orice scop. Programele libere nu judecă.

Programul este doar o unealtă și modul de utilizare este decizia / responsabilitatea persoanei care o folosește. Comparativ, programele proprietare (ne-libere) limitează frecvent cum / când / unde pot fi rulate și nu există o modalitate ușoară de a obține o licență care să permită folosirea lor în orice scop.

Restricțiile care apar frecvent în licențele programelor proprietare includ: • restricționarea numărului de instanțe ale programului care pot rula la un moment dat; • numărul de echipamente pe care se poate instala programul (chiar dacă acestea nu sunt folosite în același timp); • de câte ori aveți posibilitatea să reinstalați programul (după reinstalarea sistemului de operare de exemplu); • restricționarea numărului de CPU / cantității de memorie pe care le poate folosi programul; • interzicerea rulării a testelor de performanță.

Aceste restricții nu au motive tehnice întemeiate și există doar ca o practică monopolistă care extrage cât mai mulți bani de la utilizatori. Acest lucru distorsionează 1 https://www.gnu.org/philosophy/free-sw.html

56

peisajul de piață. De exemplu: cum poți Libertatea 2 judeca calitatea unui program de bază de Libertatea de a distribui copii ca să ajuți date dacă nimeni nu are voie să publice pe vecinul tău. Schimbul de programe este teste de performanță? benefic pentru toată lumea pe termen lung: Evident nu există astfel de restricții în • mai mulți oameni învață cum să folocazul programelor libere. sească programul (devenind astfel mai valoroși ca angajați).

Libertatea 1 • barierele sunt îndepărtate din calea Libertatea de a studia modul în care inovatorilor. funcționează programul, și libertatea de Această prevedere garantează că proa schimba ca să funcționeze cum dorește gramele (libere) nu formează un cartel utilizatorul. Accesul la codul sursă este o monopolist unde trebuie să plătești mereu precondiție pentru aceasta. Codul sursă taxe (și probabil, cu cât afacerea este mai este ”sursa supremă a adevărului” în cazul de succes cu atât vor cere din ce în ce mai întrebărilor despre programe. Având mulți bani). O indicație clară a faptului că codul sursă înseamnă că putem răspunde folosirea programelor proprietare nu este cu ușurință cele mai frecvente întrebări sustenabilă pe termen lung este faptul că care apar în timpul utilizării sau integrării Internetul rulează pe programe libere2. programelor: • este programul capabil să facă X? Libertatea 3 • cum pot convinge programul ca să Libertatea de a distribui copii ale versiufacă X? nilor modificate de alții. Făcând acest lucru • de ce nu funcționează pașii pe care întreaga comunitate poate să beneficieze de le fac? modificările tale (la fel cum beneficiezi și • Dacă contrastăm cu programele pro- tu de modificările altora). Accesul la codul prietare, opțiunile oferite sunt slabe: sursă este o precondiție pentru aceasta.

• putem citi documentația - dar Această libertate asigură că alții pot documentațiile au diferite niveluri de interveni atunci când există o oportunicorectitudine și prospețime. Codul sursă tate de piață. În cazul în care un program este documentația adevărată. proprietar nu mai este dezvoltat, nu poți • putem să ne folosim de contractul face altceva decât să-l abandonezi (sau de suport (dacă avem așa ceva). Pe lângă să-l utilizezi în continuare și să speri că faptul că este costisitor, există un timp nu se strică). În cazul în care dezvoltatominim de răspuns de o zi. Codul sursă rul original al unui program liber nu mai este acolo când ai nevoie de el poate sau nu vrea să continue dezvoltarea, • putem studia programul final pot interveni alții pentru a oferi sprijin în (prin reverse engineering) - dacă avem continuare. Sau chiar mai multe persoane instrumentele și expertiza necesară. De / organizații pot concura în a oferi servicii asemenea, acest lucru poate dura un de asistență și/sau de dezvoltare. timp lung și este potențial ilegal în multe În contrast: în cazul programelor jurisdicții. proprietare producătorii încearcă să desMențiune: unii furnizori de programe curajeze pe alții de la acordarea de sprijin. proprietare oferă acces la (o parte din) codul lor sursă, de obicei sub condiții foarte Avantaje stricte. Aceasta lucru satisface doar una După ce am caracterizat cele patru dintre cerințele pentru un program liber libertăți care definesc programele libere, să (și probabil și acela doar parțial - furnizorii discutăm puțin despre avantajele pe care le rareori dau acces la codul sursă complet și oferă. instrumentele necesare pentru a recompila sistemul). Aceste programe sunt în conti2 http://news.netcraft.com/archives/2014/04/02/aprilnuare ne-libere/proprietare.

2014-web-server-survey. html

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Transparența

Programele libere sunt transparente.

Putem verifica fiecare afirmație care se face despre ei. Comparativ, în cazul programelor proprietare suntem nevoiți să ne bazăm pe materialele de marketing și alte surse create sau aprobate de către furnizor.

Programele libere sunt de asemenea transparente cu privire la planurile de viitor, creându-se posibilitatea de a judeca cu ușurință nivelul de activitate și viteza cu care problemele sunt rezolvate sau trăsături noi sunt implementate. În cazul în care proiectul nu mai este menținut, vom putea vedea ușor acest lucru și avem o multitudine de opțiuni pentru a rezolva problema.

Comparați acest lucru cu programe proprietare unde producătorul poate elimina un produs din motive (aparent) arbitrare, în mod brusc și fără alte opțiuni decât migrarea pe alte platforme.

nesigure, cum ar fi certificările.

Este un efort cu adevărat capitalist Piețele produc cele mai bune rezultate când informația este disponibilă în mod egal tuturor participanților. Programele libere creează un astfel de mediu. Cuplat cu costul aproape zero de a transporta informația în ziua de azi, avem o evoluție foarte rapidă a proiectelor libere.

Poate să ne scape de întreținere

Este posibil că veți găsi un program (liber) care are 99% din ceea ce ai nevoie, dar cel 1% final lipsește. Fiind un program liber, putem lua codul sursă și să adăugăm acel 1%. Ba chiar mai mult, dacă dai contribuțiile înapoi la proiectul original, ei le vor încorpora și le vor menține. Acest lucru înseamnă că, dacă există schimbări majore (cum ar fi schimbările de API în versiunea 2 al unor biblioteci de exemplu), Nivel potrivit de sprijin Cu programele libere există multe nu trebuie să-ți petreci timpul cu recreaopțiuni pentru sprijin (support) în funcție rea modificărilor - probabil altcineva din de suma pe care vrem să investim. comunitatea se va ocupa de acest lucru.

Posibilitățile obișnuite pentru a obține spriManagementul licențelor jin pentru programe libere sunt: Menținerea la curent a licențelor • ​​căutarea pe Internet - programele libere tind să aibă utilizatori mai tehnici software este greu de făcut. Eșecul în a face care documentează soluțiile pentru pro- acest lucru poate duce la pierdere de problemele întâlnite frecvent. Există o șansă ductivitate: de ce nu pot folosi software-ul? mult mai mare de a găsi soluția prin cău- Ah, Ion îl folosește și avem doar o singură tarea pe Internet atunci când se folosesc licență! Dar Ion este într-o pauză de cafea și trebuie să-l aștept! De asemenea, poate programe libere.

• solicitările de ajutor pe listele de cauza probleme juridice:sunteți sigur că discuții / forumuri - programele libere aveți o licență valabilă pentru fiecare copie sunt creații ale unor oameni dedicați a programelor de pe cele 100+ dispozitive și entuziaști care vă pot ajuta mult mai din compania dumneavoastră?

Programele libere în schimb înseamnă bine decât sprijinul elementar (first level support) oferit de furnizorii de software. ”termeni de licențiere simpli și siguranța că Ei fac acest lucru în mod gratuit, dar tim- ești în conformitate cu ele”. pul de răspuns poate să varieze.

• puteți angaja unul din dezvoltatorii Comunitate în mod part-time sau full-time - în cazul Folosind și contribuind la prograîn care există mai mulți dezvoltatori, mele libere, devii parte din comunitate. puteți să alegeți pe cel mai convenabil.

Interacționezi cu oameni interesanți.

• puteți angaja o companie care oferă Colaborezi cu persoane din toată lumea. Ai suport pentru produs. Din nou, licența posibilitatea de a învăța de la cei mai buni. permite concurență în acest spațiu, astfel că în cazul proiectelor populare vor Alte informații exista mai multe opțiuni.

După ce am prezentat avantajele programelor libere, mai doresc să menționez Ușor de găsit oameni cu cunoștințe câteva informații mai puțin cunoscute desdespre proiectul respectiv pre ele: Pentru că dezvoltarea se face în public, putem găsi cu ușurință contribuitorii care ar Nu te obligă să dai codul sursă tuturor putea să fie interesați de a lucra pentru noi.

Programul liber cere numai să oferi De asemenea, putem judeca competența opțiunea de a accesa codul sursă utilizatolor direct (pe baza contribuțiilor la proiect rilor (într-un format care poate fi utilizat / comunitate), fără să folosim proxy-uri pentru a reproduce produsul final). Acest

lucru înseamnă că nu ești obligat să dai codul sursă oricărei persoane care cere, doar pentru utilizatorilor programului.

De asemenea: • dacă utilizați cod sub licența LGPL și este inclus într-un sistem mai mare (de exemplu, utilizați o bibliotecă licențiată sub LGPL), trebuie doar să furnizați codul sursă pentru modificările efectuate la bibliotecă, nu de la întreg sistem.

• dacă utilizați cod sub licența GPL, dar acesta nu este vital pentru funcționarea sistemului (este un plugin de exemplu), trebuie doar oferit sursa pentru modificările efectuate la ea, nu de la întregul sistem.

• dacă utilizați cod sub licența GPL pentru a crea produsul dar partea GPL nu se livrează sub formă binară cu produsul final (de exemplu utilizați GCC pentru a compila codul sursă), nu este nevoie să furnizați codul sursă pentru produsul complet.

• dacă utilizați cod sub licența GPL intern și expuneți rezultatul prin rețea (aveți un produs SaaS de exemplu), nu este nevoie să furnizați codul sursă.

Trebuie doar să oferiți codul sursă persoanelor care execută binarul, care, în acest caz, este chiar compania.

Deși nu este nevoie să furnizați codul sursă în niciunul dintre cazurile de mai sus, totuși este o idee bună de a face acest lucru. Cele mai multe companii nu sunt în afacerea de „software” - folosesc softwareul doar pentru a accelera lucrurile (de exemplu: valoarea principală a unui broker financiar nu este platforma software, ci mai degrabă conexiunile pe care le are cu mulți jucători de pe piață). Furnizarea codului sursă clienților companiei în astfel de cazuri le asigură că nivelul de risc al este redus și ei vor veni în continuare la companie, deoarece l-au ales în primul rând datorită conexiunilor.

Programele libere pot fi vândute

”Free” înseamnă liber, nu gratuit în acest context. Nimic în licențele programelor libere nu vă împiedică să vindeți produsul final.

Attila-Mihaly Balazs dify.ltd@gmail.com

Code Wrangler @ Udacity Trainer @ Tora Trading

www.todaysoftmag.ro | nr. 24/Iunie, 2014

57

management

De ce să investim în management profesionist?

Î

n ultima perioadă previziunile macroeconomice par mai degrabă pozitive pentru România. Ultimele știri în această direcție vorbesc despre o creștere economică dintre cele mai mari din Europa, despre îmbunătățirea semnificativă a rating-ului de țară acordat de una din cele mai importante agenții de rating la nivel global și despre o nouă lege privind neimpozitarea profiturilor reinvestite în tehnologie.

Personal cred că toate aceste știri și previziuni pozitive vor avea un efect concentrat de accelerare a investițiilor în România. Singurul factor care ar putea stopa sau chiar infirma previziunile pozitive ar fi escaladarea situației conflictuale din Ucraina. În speranța că acest lucru nu se va întâmpla și având între ipoteze perspectivele pozitive despre care tocmai am discutat, aș vrea să atrag atenția asupra investiției pe care fiecare companie trebuie să o facă în managementul profesionist.

Din păcate, după cum am mai spus în câteva rânduri, în trecut, pozițiile de management din companiile românești erau mai degrabă o modalitate de premiere a oamenilor performanți din alte domenii (vânzări, administrativ, financiar, etc.) în loc să reprezinte coloana vertebrală de funcționare a unei organizații. Firmele își concentrau toate eforturile pe vânzări, achiziții sau investiții în tehnologie și neglijau în mare măsură investițiile susținute în crearea unei structuri de management performant. Singurele semne ale unei astfel de preocupări erau legate de trimiterea la câte un curs sau training a unor persoane, acțiuni văzute tot ca o modalitate de premiere sau de aliniere la ceea ce făceau alții și mai puțin ca o investiție conștientă și susținută în crearea unei structuri organizaționale care să dea consistență rezultatelor firmei. Știu că din perspectivă financiar-contabilă sau chiar din perspectiva finanțelor manageriale, resursele financiare utilizate pentru crearea unei structuri de management profesionist nu sunt văzute ca investiții ci ca niște cheltuieli. Oricum le-am vedea, este obligatoriu să alocăm timp, efort și

58

resurse financiare pentru crearea unor ast- management, își va scoate banii. Un manafel de structuri în organizațiile noastre. În ger profesionist va putea demonstra acest lipsa acestora, beneficiile obținute în urma lucru încă înainte de a face investiția. influențelor pozitive ale macro-mediului pot dispărea rapid, investițiile pe care le facem în tehnologie sau alte domenii nu vor fi valorificate corespunzător, climatul organizațional se poate înrăutăți cu efecte negative asupra percepției pe termen lung asupra organizației. Știu că este greu de făcut acest lucru când unele organizații abia găsesc resursele necesare pentru capitalul de lucru curent, atât cel financiar cât și cel uman. Să aloci o parte importantă a resurselor de timp, efort și bani pentru management pare destul de greu cu atât mai mult cu cât managementul profesionist este uneori greu de identificat, fiind perceput mai degrabă ca ceva abstract și care ține mult de percepție și conjunctură. Managerii profesioniști știu că nu este așa. Pentru toți ceilalți aș vrea să punctez ce poate aduce investiția în managementul profesionist pentru companiile pe care le conduc: mai multă stabilitate pe termen mediu și lung, o predictibilitate mai mare a rezultatelor, o dezvoltare armonioasă și eficiență fără stres și riscuri inutile, atragerea mult mai facilă de resurse financiare și umane de calitate, respectul concurenților, angajaților și partenerilor etc. .

Prin urmare nu uitați, atunci când veți avea planuri de dezvoltare să alocați o parte importantă de timp, efort și bani pentru crearea unui sistem de management profesionist în organizația voastră.

Dan Schipor danschipor@daris.ro Orice investiție în manageri profesioniști, realizata prin training-uri sau sisteme de Management Partner @ Casa de management Daris coaching, structuri, instrumente și sisteme de management, cursuri sau consultanță în

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

business

TODAY SOFTWARE MAGAZINE

O NOUĂ SCHEMA DE AJUTOR DE STAT PENTRU IT 50% nerambursabil din costul salarial pe 2 ani, minim 20 de locuri de muncă nou create

M

inisterul Finanțelor prin Departamentul de Ajutor de Stat va derula începând cu 1 iulie o nouă schemă de ajutor de stat ce fi valabilă până la 31 decembrie 2020 -și va avea un buget total de aproximativ 600 mil. euro, cu posibilitatea suplimentării.

Numărul total estimat al întreprinderilor care urmează să beneficieze de ajutor de stat în baza schemei este de 1.500.

Cheltuieli eligibile

Sunt considerate cheltuieli eligibile costurile salariale, înregistrate pe o perioadă de 2 ani consecutivi, ca urmare a creării de locuri de muncă.

Ajutorul de stat aferent cheltuielilor eligibile se acordă cu îndeplinirea următoarelor condiții: • locurile de muncă sunt create direct de un proiect de investiții; • Nu se impune o valoare minimă a proiectului de investiții însă trebuie demarat după emiterea acordului de finanțare.

• locurile de muncă sunt create după data primirii acordului pentru finanțare, dar nu mai târziu de 3 ani de la data finalizării investiției.

Se poate depune un proiect pentru mai multe locații, sediul social și punctele de lucru ale companiei, cu condiția să se creeze minim 20 noi locuri de muncă /locație.

Se iau în considerare locurile de muncă nou-create în cazul în care între angajați și angajator sau întreprinderi asociate acestuia nu există raporturi de muncă în ultimele 12 luni anterior datei înregistrării cererii de acord pentru finanțare.

Activități eligibile

Sunt eligibile activități de editare a producției software (582), activități de

servicii în tehnologia informației (620), activități de servicii informatice (63); sunt excluse activități precum: agricultura, comerț, hoteluri, restaurante, transporturi, jocuri de noroc, telecomunicații, închiriere, leasing etc. .

Companii eligibile

Pot aplica atât întreprinderi existente cât și nou create. Întreprinderile existente trebuie să fi avut o situație financiară bună în 2013: capitaluri proprii pozitive, rentabilitatea cifrei de afaceri mai mare decât , etc. . Întreprinderile nou create sunt eligibile doar în cazul în care acționarii nu desfășoară sau nu au mai desfășurat activitatea pentru care solicită finanțare prin intermediul altor companii în ultimii 2 ani.

Ajutorul nerambursabil

Intensitatea brută a ajutorului de stat regional esteraportată la cheltuielile eligibile Beneficiarii pot solicita plata ajutorului nerambursabil de patru ori pe an, strict raportat la costurile salariale efectuate și în conformitate cu proiectul aprobat; rambursările se vor efectua în 45 de zile lucrătoare de la data la care cererea de rambursare este considerată completă.

Procedura de lucru

Schema va fi activă începând cu data de 1 iulie a.c.. Se va depune în cadrul unei sesiuni de depunere de 20 de zile o documentație preliminară (calendarul de creare a locurilor de muncă, certificate de atestare fiscală etc) pe baza căreia se acordă un punctaj societății.

Criteriile pe baza cărora se calculează punctajul întreprinderilor solicitante de ajutor de stat sunt: numărul de locuri de munca nou create, perioada de creare a minim 20 locuri de muncă, locația realizării investiției, rentabilitatea cifrei de afaceri, valoarea capitalului social subscris vărsat.

Companiile care se vor califica vor depune planul de afaceri complet, iar dintre acestea, cele eligibile vor primi acord de finanțare nerambursabilă.

Estimativ, companiile vor trebui să aștepte circa 6 luni până la emiterea acordurilor de finanțare, prin urmare, vor trebui să își planifice să demareze atât proiectul de investiții cât și crearea noilor locuri de muncă după această dată.

IMM-urile sunt obligate să mențină noii angajați timp de 3 ani de la data creării lor, iar companiile mari timp de 5 ani.

www.todaysoftmag.ro | nr. 24/Iunie, 2014

59

legal

Opțiuni pentru a interzice altor persoane să profite de marca dvs. înregistrată

O

rice antreprenor (inclusiv din domeniul IT) cunoaște cât de greu se clădește și ce importanță are un brand într-o afacere – o marcă recunoscută pe piață, dar și investiții de timp, energie și bani pentru publicitate sau promovare. Marca joacă un rol important în strategia de marketing a oricărei companii și contribuie la consolidarea imaginii și reputației acesteia. Pentru unele companii, ea reprezintă chiar activul cel mai de preț.

De aceea, veți fi prejudiciați când marca dvs. este folosită ilegal de alte persoane - în principal, din cauza riscului de confuzie ce se poate crea în percepția consumatorilor (consumatorii trebuie să poată distinge ușor între produse sau servicii identice sau asemănătoare).

Iată câteva opțiuni la îndemâna titularului unei mărci înregistrate, pentru a reduce riscul unor eventuale litigii în instanță, cauzate de încălcarea mărcii sale.

Monitorizarea mărcii

aveți opțiunea clasică să inițiați o acțiune în justiție sau chiar să sesizați organele de cercetare penală.

Ca alternativă mai puțin costisitoare și mai rapidă, puteți transmite o notificare formală prin care să solicitați persoanei respective să nu vă mai încalce dreptul la marcă. Este vorba despre așa-numita cease and desist letter din practica anglo-saxonă.

Astfel, o puteți informa asupra unui posibil conflict și să-i cereți să nu mai folosească marca respectivă sub amenințarea chemării în judecată, ori să-i propuneți să negociați un acord de coexistență a celor două mărci.

Conținutul unei astfel de notificări diferă de la caz la caz, în funcție de situația concretă, și presupune invocarea unor texte legale și argumente pertinente. De aceea, este recomandabil să fiți asistat de un specialist care să vă ajute să dați o notă cât mai formală și oficială notificării și să o documenteze corespunzător.

Aceste notificări nu au mereu efectul scontat. În practică, sunt destule cazuri în care notificările sunt ignorate și încălcările continuă nestingherit. Ce se poate face în acest caz?

Alte soluții mai pot fi, de la caz la caz: arbitrajul, medierea, acțiuni la instanța judecătorească competentă, măsurile la frontieră pentru prevenirea importului de produse contrafăcute. Totuși, în ciuda a ceea ce poate ați auzit, arbitrajul în România nu este neapărat mai puțin costisitor și mai rapid decât instanța judecătorească. Iar medierea poate da roade doar dacă și partea adversă este de bună-credință și vrea să găsiți împreună o modalitate amiabilă de a stinge conflictul.

În prezent, fiecare nouă cerere de înregistrare a unei mărci se publică electronic, într-un buletin oficial al OSIM1. Într-un termen de două luni de la publicare, persoanelor interesate li se permite să se opună respectivei înregistrări. Astfel, în acest termen, în calitate de titular al unei mărci protejate (și) pe teritoriul României, aveți posibilitatea să vă opuneți, dacă considerați că înregistrarea noii mărci ar putea dăuna mărcii dvs.

Astfel, dacă nu sunteți diligent și nu vă opuneți în termenul acordat de lege, puteți avea surpriza ca un competitor să reușească să înregistreze o marcă asemănătoare sau chiar identică cu marca dvs. . În principiu, acest lucru implică în practică să urmăriți lunar buletinele în care OSIM publică noile cereri de marcă și să verificați, printre altele, dacă vreuna este identică sau similară cu marca dvs. .

Dacă nu aveți resursele necesare (timp, răbdare, competență, etc.) să urmăriți în permanență ce noi cereri de mărci sunt depuse la OSIM și să stabiliți care anume poate crea un conflict cu marca dvs., puteți opta pentru un serviciu de monitorizare oferit de consilierii autorizați în domeniul Protecția mărcii pe Internet. Numele de mărcilor. domeniu În practică, se consideră că un nume de Notificări de încetare domeniu de Internet care include o denuDacă ați aflat că o altă persoană vă mire asemănătoare sau identică unei mărci, folosește marca pe piață fără acordul dvs., poate încălca drepturile titularului acelei mărci – din cauza riscului de confuzie 1. Oficiul de Stat pentru Invenții și Mărci (osim.ro)

60

nr. 24/Iunie, 2014 | www.todaysoftmag.ro

în rândul clienților. De aceea, pentru un antreprenor care ține la unicitatea mărcii sale, este utilă monitorizarea domeniilor noi de Internet.

Exista cazuri, nu puține la număr, când antreprenorul nu este suficient de atent în mediul online și se poate găsi în situația în care află că marca lui este deja înregistrată de altcineva ca nume de domeniu: fie cybersquatters – adică cei care înregistrează cu rea-credință nume de domenii ce conțin mărci deținute de diverse companii cu scopul de a le revinde acestora ulterior, fie chiar comercianți care vând același tip de produse precum titularul mărcii.

Până recent, de cele mai multe ori, «războiul» s-a dat pe extensiile .ro și .com – fie prin acțiuni în instanță, fie prin arbitraj la WIPO Arbitration and Mediation Centre 2 . Dar există și alte motive de îngrijorare în contextul apariției noilor și variatelor nume de domenii (gTLD) care urmează să fie date în folosință curând de către ICANN (exemple de noi posibile gTLD: .game, .software, .clothing, .shop, .car, .tourism, .kodak, etc.).

Puteți găsi aici3 un infografic realizat de ICANN privind modul în care titularii își pot proteja mărcile în mediul online, în urma «revoluției» numelor noi de domenii.

Un exemplu de protejare ar fi printr-o înregistrare în Trademark Clearinghouse. În concluzie, există o serie de opțiuni pentru a rezolva situațiile neplăcute create de încălcarea mărcilor – rămâne să le alegeți pe cele pe care le considerați potrivită situației dvs. concrete.

2 Organizația Mondială a Proprietății Intelectuale www.wipo.int/amc/en/domains 3 h t t p : / / n e w g t l d s . i c a n n . o r g / e n / announcements-and-media/infographics/tm-protection

Claudia Jelea

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

sponsori

powered by