Numarul 25/iulie 2014 - Today Software Magazine

Nr. 25 • Iulie 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

Principii de design Agile Scrum cu Programare Extremă

Folosirea JSON în PostgreSQL Du-te (GO) și găsește instrumentul Integrarea datelor între sisteme cu Talend Open Studio Securizarea Codului Opensource via Analiza Statică (II) iOS 7 blur

Drive Your Community for Better, alături de tineri antreprenori clujeni RICAP: drumul inovației de la laborator către piețe globale ZenQ Gogu și Bătrânu’ lui Mișu

6 Ecosistemul IT Clujean din perspectiva startup-urilor Ovidiu Mățan

10 RICAP: drumul inovației de la laborator către piețe globale Silvia Ursu

11 ZenQ Mihai Costea

12 Despre relevanța practicii studențești Andrei Kelemen

14 Drive Your Community for Better, alături de tineri antreprenori clujeni

24 Du-te (GO) și găsește instrumentul Marius Ciotlos

26 Scrum cu Programare Extremă Alina Chereches

29 Principii de design Agile Dumitrița Munteanu

34 iOS 7 blur Mihai Fischer

35 Integrarea datelor între sisteme cu Talend Open Studio

Paula Beudean

Dănuț Chindriș

17 IT-ul românesc quo vadis

37 AOP și LinFu

Ovidiu Simionica

Radu Vunvulea

19 Java 8, noutăţi şi îmbunătăţiri Silviu Dumitrescu

21 Suportul JSON în PostgreSQL Raul Rene Lepsa

40 Securizarea codului Open source (II) Raghudeep Kannavara

43 Gogu și Bătrânu’ lui Mișu Florin Asavoaie

editorial

U

Ovidiu Măţan

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

ltima noutate locală din Cluj este achiziționarea LiveRail de către Facebook.

Toate ziarele au publicat această informație și sunt convins că deja mulți dintre cititorii revistei știu detaliile despre această tranzacție. La ora apariției acestei știri încheiasem deja articolul despre ecosistemul de IT Clujean din perspectiva startupurilor pe care l-am încheiat într-o notă de optimism reținut. Principalul motiv era lipsa unui succes real, ce ar fi putut fi dat ca un exemplu. Acum însă, descoperind LiveRail ca o companie a cărei valoare a fost confirmată prin achiziția de către Facebook, lucrurile stau mult mai bine, cel puțin pe hârtie.

Rămânem tot în zona promovării IT-ului românesc și îmi face plăcere să vă spun în premieră despre o a doua ediție a IT Days, www.itdays.ro, 3-4 decembrie 2014. Un eveniment organizat de către Today Software Magazine și care pune pe scenă cei mai buni specialiști locali din zona IT-ului. Vom avea două secțiuni dedicate prezentărilor tehnice, una dedicată trendurilor și una pentru startup-uri și proiecte universitare. Primii invitați care au acceptat să ni se alăture sunt: Bogdan Iordache - organizator How To Web și cofondator TechHub Bucharest, Josef Dunne - co-fondator Babelverse și Silviu Dumitrescu - specialist Java și Line Manager Accesa. Lista este doar la început și vom reveni cu detalii.

Deoarece este vacanță, am pregătit pentru cititorii noștri un concurs alături de Honda Cluj. Este vorba de posibilitatea de a câștiga pe durata unui week-end o mașină pentru o drumeție plus un plin de benzină. Extragerea câștigătorului va avea loc la evenimentul de lansare a numărului 25 TSM. În acest număr veți găsi o serie de articole despre startup-uri. Ecosistemul IT clujean din perspectiva startup-urilor vă prezintă elementele principale implicate în suportul ideilor inovative precum și o listă a celor mai promițătoare startup-uri. ZenQ, un nou startup vă propune o nouă modalitate de a mulțumi prietenilor. Programul RICAP invită startupurile la un program de coaching, iar Fundația Danis prezintă realizările programului de educație financiară pentru tinerii antreprenori Drive your community for better. Studenții sunt în prim plan, iar Cluj IT Cluster propune o structurare a practicii universitare în Despre relevanța practicii studențești.

Trecem în revistă articolele tehnice din acest număr: Java 8, noutăţi şi îmbunătăţiri prezintă o parte din noile schimbări din Java 8 care ne vor schimba modul în care scriem cod Java. Suportul JSON în Postgress descrie abordarea inedită adăugată în ultima versiune de Postgress. Principii de design Agile vă supune atenției o serie de design pattern-uri care să se poată adapta arhitectura claselor la principiile Agile.

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

Ovidiu Măţan

Fondator al Today Software Magazine

4

nr. 25/Iulie, 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 Silviu Dumitrescu

silviu.dumitrescu@accesa.eu Java Line Manager @ Accesa

Raul Rene Lepsa raul.lepsa@3pillarglobal.com Java Devolper @ 3Pillar Global

Radu Vunvulea

Marius Ciotlos

Senior Software Engineer @iQuest

Delivery Manager @ Betfair

Alina Chereches

Andrei Kelemen

Senior Software Developer & Scrum Master @ Yardi

Director executiv @ IT Cluster

Dănuț Chindriș

Mihai Fischer

Java Developer @ Electrobit Automotive

iOS developer @ Dens.io

Mihai Costea mihai.costea@gmail.com

Simona Bonghez, Ph.D.

iOS Developer @ Zenq

Speaker, trainer and consultant in project management,

Radu.Vunvulea@iquestgroup.com

marius.ciotlos@betfair.com

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

alina.cherecheș@yardi.com

danut.chindris@elektrobit.com

andrei.kelemen@clujit.ro

mihai.fischer@gmail.com

Contabil : Delia Coman delia.coman@todaysoftmag.com Produs de

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

simona.bonghez@confucius.ro

Owner of Colors in Projects

Paula Beudean

paula.beudean@fundatiadanis.ro Coordonator Proiecte @ Fundația Danis

Ovidiu Simionica

ovidiu.simionica@fortech.ro Team Lead @ Fortech

Raghudeep Kannavara

Silvia Ursu

Security Researcher, Software and Services Group @Intel USA

Communications Coordinator @RICAP

raghudeep.kannavara@intel.com

silvia.ursu@cridl.org

Ovidiu Măţan

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

Copyright Today Software Magazine 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

www.todaysoftmag.ro | nr. 25/Iulie, 2014

5

analiză

Ecosistemul IT Clujean din perspectiva startup-urilor

T

ermenul ecosistem din titlul este utilizat ca o metaforă a contextului economic clujean care stabilește relații strânse între organisme precum comunitatea IT, universități și sursele de finanțare. Fiecare dintre acestea, comunitatea IT prin execuție, universitatea prin cercetare, iar sursele locale de finanțare prin susținerea primelor două, sunt implicate în crearea unei rețele de interdependențe și condiționări. Apariția startup-urilor în acest ecosistem este interpretată ca un instrument de măsurare a inovației și a culturii antreprenoriale.

Deși primii pași făcuți în această direcție sunt relativ timizi, importanța acordată acestora și susținerea locală sunt în creștere. Multe dintre evenimentele locale din zona IT-ului au o secțiune dedicată startup-urilor: Cluj Innovation Days, IT Days, Techsylvania. Același trend îl regăsim chiar și în cadrul unor evenimente cu caracter mai extins precum Cluj Business Days sau TedX. Toate acestea arată importanța acordată de comunitate dezvoltării unor produse locale, generarea acelui IP (Intellectual Property) ce oferă local o mai bună stabilitate și un mare potențial de dezvoltare. Pentru succesul unui startup într-o piață globală este nevoie însă de un întreg ecosistem care să ajute creșterea acestuia de la idee până la implementare, vizibilitate și profit. Victor Hwang a definit într-un mod foarte plastic imaginea de ansamblu. Industria clasică de outsourcing poate fi considerată o fermă în care semințele plantate cresc foarte repede, au toate aceeași dimensiune, excepțiile sunt puține și în general nu reprezintă un lucru benefic. Alternativ, într-o pădure, semințele plantate deși au o mică șansă de supraviețuire, pot ajunge niște copaci masivi, care să existe pentru multă vreme. În acest mediu, este în regulă să dai greș, iar acest lucru duce la diversitate, în opoziție cu ferma unde toate semințele trebuie să devină plante mature. În ambele exemple, ceea ce contează cel mai mult este solul în care aceste semințe cresc și care pentru noi reprezintă ecosistemul. Dezvoltarea unor produse noi înseamnă comunicare, încredere și împărtășirea experiențelor acumulate.

Vom analiza în continuare principalii factori ce definesc ecosistemul de IT clujean.

într-o piață globală: NTT Data ce a achiziționat EBS, Accenture a cumpărat Evoline, startup-ul Nok a fost luat de Intel sau Skobbler achiziționat de Telenav.

Din perspectiva dezvoltării personale, outsourcing-ul oferă posibilitatea de a lucra la proiecte importante, precum și asimilarea unei părți din cultura clienților, a modului acestora de lucru.

Din perspectiva mai generală a corporațiilor, outsourcing-ul oferă accesul la o parte din cultura celorlalte corporații, comunicarea între diferitele proiecte, dar și meeting-uri cu echipele din diferitele colțuri ale lumii.

Dacă acum zece ani, în Cluj exista doar simplă execuție, acum avem de-a face cu un ownership din ce în ce mai extins. În general arhitectura sistemelor se face acum local iar product manageri-i și analiștii de bussines sunt la mare căutare. Acest fapt înseamnă și multă încredere și recunoaștere a calității software-ului dezvoltat în Cluj, iar tendința este de a pune accent pe calitate în defavoarea costurilor. De altfel, costurile din ce în ce mai ridicate ce se reflectă și în salariile programatorilor reprezintă și un impediment important în dezvoltarea startup-urilor. Totodată creează acea comoditate aleasă de majoritatea în detrimentul încercării de dezvoltare a unor produse proprii.

Piața de software locală a ajuns la un prim nivel de maturitate. Există deja angajați ce au cincisprezece ani de experiență în domeniu, dar ponderea acestora este relativ scăzută. Piața în general este tânără fără să avem încă programatori cărunți. Din perspectiva recrutării există o bătălie continuă pentru atragerea talentelor. Din păcate, sunt situații în care persoane și-au dedicat 3-4 ani unui startup pentru a fi angajate. Aceasta poate fi o proComunitatea IT blemă, dar pe de altă parte asimilarea culturii unei companii și o Este alcătuită în majoritatea lor de companii de IT ce dezvoltă mai bună înțelegere a procesului de dezvoltare a produselor poate produse de outsourcing. Există câteva excepții locale, dintre care duce în câțiva ani spre crearea unui startup câștigător. aș menționa două aparținând industriei jocurilor, Exosyphen și Idea Studio dar și pe cele ale unor companii mari precum Arobs Universitățile sau Skobbler, acum devenit Telenav.

La cele două universități clujene, Babeș-Bolyai și Universitatea Un număr important de companii sunt și cele care sunt parte Tehnică sunt pregătiți aproximativ 1000 de studenți pentru a dintr-o companie internațională, au ownership pe produsele dez- deveni programatori. Numărul acestora este mic comparativ cu voltate și există o divizie locală de R&D. Numărul acestora este în necesitățiile pieței, iar acest lucru este observat prin numărul din creștere și putem enumera câteva dintre ele precum: Betfair, Yardi, ce în ce mai mare de companii care își deschid sucursale în alte Tora, HP, Ullink, SDL sau Gameloft. orașe. De asemenea, se construiesc programe alternative precum O categorie interesantă o reprezintă companiile care activau pe 42.fr sau Ruby Girls. piața locală și care au fost achiziționate și care se înglobează astfel Importanța universităților și rolul lor în contextul dezvoltării

6

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

startup-urilor locale este relativ scăzut. Încercăm prin evenimentul anual IT Days, www.itdays.ro și de asemenea prin revista Today Software Magazine să promovăm cunoștiințele și proiectele realizate de universități. Acestea trebuie să se transforme într-un motor al inovației și a ultimelor tehnologii, similar cu ceea ce face Standford pentru Silicon Valley.

Investitorii

Proiecte sociale O alternativă mai populară în special pentru companiile de IT ce activează în zona outsourcing-ului și doresc orientarea către produse o reprezintă proiectele sociale. Astfel se realizează un proiect gratuit pentru comunitate. Un exemplu sugestiv este aplicația Statui de daci, care promovează lucrarea istoricului Leonard Velcescu.

Pe plan local se poate profita de oportunitatea oferită anul viitor de Cluj, atunci când acesta va avea titlul de Capitala Europeană a Tineretului.

Realizarea unui astfel de proiect va însemna un plus pentru comunitate, dar și un mod simplu de a promova un brand și de a trece prin provocările dezvoltării unui produs.

Investițiile principale realizate până acum în zona startupurilor au fost reprezentate de către cele două acceleratoare din Bulgaria: Eleven și LAUNCHub. Cinci startup-uri locale au primit investiții de aproximativ 30,000 euro, dar din păcate toate au fost închise. Dintre învățămintele pe care le putem valorifica din această abordare le semnalăm pe acelea că banii acordați au fost insuficienți pentru atingerea pragului de afacere profitabilă, ideal Alte structuri la un nivel internațional și pe acela că necesitățile proiectelor nu au fost acoperite în ceea ce privește partea de development, mar- Cluj IT Cluster keting sau legal.

Este alcătuit dintr-un grup de companii românești, având ca scop principal atragerea unor mari proiecte ce nu ar putea fi Crowdsourcing realizate de o singură companie. În același timp se realizează o Reprezintă o alternativă simplă de finanțare. Cele două plat- comunicare eficientă între companiile implicate, creându-se forme locale, Creștem Idei și Multifinanțare, nu reușit să atragă condițiile pentru o mai bună coordonare mai bună a acțiunilor. publicul larg într-o măsură mare. Proiectele și sumele finanțate Evenimentul anual organizat de către cluster, Cluj IT Innovation astfel fiind la un nivel redus. Recent proiectul Multifinanțare a rea- Days a adus împreună companiile locale, reprezentanți ai guverlizat o colaborare cu Universitatea Babeș-Balyai prin crearea unui nului, ai Uniuni Europene precum și proiecte de cercetare. Recent, portal pentru sprijinirea proiectelor academice. revista Today Software Magazine împreună cu Cluj IT Cluster am organizat în Brașov evenimentul: IT-ul Brașovean: Oportunități de Angel investors colaborare. Acesta s-a bucurat de un interes real din partea publiDacă facem o paralelă cu alte centre de dezvoltare, o parte din cului și intenționăm să mai avem astfel de evenimente. sumele cu care sunt finanțate inițiativele locale vin de la cei ce au realizat un exit. Putem să îi enumerăm astfel pe Phillip Kandal, StartupWeekend unul dintre cei patru fondatori ai Skobbler, și pe Daniel Metz, cel Este un eveniment dedicat 100% creării startup-urilor. Dacă care a vândut compania EBS către NTT Data. Deocamdată cei doi nu ați participat până acum la un astfel de eveniment, vă sugerez nu au anunțat vreo investiție în zona de IT dar ne așteptăm ca să o faceți. Sunt acceptate doar ideile noi, iar echipele se formează acest lucru să se întâmple în următorul an. în jurul celor mai populare pitch-uri. Este un fenomen global și multe startup-uri au luat naștere în felul acesta. Câștigătorii din Acceleratoare ultimi trei ani sunt Mircea Vădan cu platforma UseTogether, Gemini Solutions Foundry vine cu o abordare diferită. echipa Cloud Copy, iar câștigătoarea de anul acesta a fost o veche Acceleratorul oferă tot ce este nevoie pentru a aduce startup-ul la colaboratoare a revistei, Antonia Onaca cu o idee ce ar trebui să stadiul de MVP. Aceasta înseamnă suport tehnic, mentorat, suport schimbe modul în care sunt evaluați angajații. legal, chiar și spațiu de lucru central în București, Cluj sau Iași.

Scopul acestui MVP este prezentarea startup-urilor unor mari Hackaton-ul Techsylvania fonduri de investiții din SUA în vederea obținerii finanțării. În Organizat în cadrul primei ediții a Techsylvania, acesta a pus momentul de față căutările și selecția candidaților este în plină la dispoziția participanților diverse dispozitive mobile precum desfășurare.

Google Glasses, Leap Motion, Sphero, Little Printer, Pebble și www.todaysoftmag.ro | nr. 25/Iulie, 2014

7

analiză Ecosistemul IT Clujean din perspectiva startup-urilor multe altele. Rezultatul a fost spectaculos, miniproiectele realizate fiind cu adevărat interesante. Acestea au combinat folosirea Google Glasses împreună cu Leap Motion pentru realizarea unui joc sau tastarea unui cod la bancomat prin monitorizarea mișcării ochilor. Probabil o combinație de Startup Weekend și hackaton în care sunt puse la dispoziție ultimele gadget-uri disponibile ar duce la crearea unor startup-uri cu adevărat inovative.

Today Software Magazine și IT Days Unul dintre scopurile declarate încă de la lansarea revistei a fost sprijinirea startup-urilor. Revista Today Software Magazine sprijină majoritatea inițiativelor din această zonă și ajutăm la promovarea acestora. De asemenea, prin evenimentul anual IT Days, ce va avea loc în 3-4 decembrie anul acesta, vom aduce pe scenă cele mai importante startup-uri locale.

Concluzii

Fenomenul startup-urilor și orientarea companiilor ce activează în zona outsourcing spre crearea de produse sunt în continuă creștere. Deși nu putem da un exemplu de succes real, ne așteptăm să putem face acest lucru în curând. Mă bucur să putem da un exemplu real, compania fondată de doi clujeni și un american, LiveRail, a fost recent achiziționată de către Facebook.

Aceasta demonstrează fără echivoc valoarea ecosistemului local și a educației.

Sfatul pe care îl dăm celor ce vor să își creeze un startup este să participe la cât de multe evenimente locale și internaționale, relațiile personale fiind foarte importante la început de drum.

Este puțin probabil că ideea ta va schimba lumea mâine, dacă nu interacționezi cu multă lume.

Există multe oportunități, pe care le remarcăm mai ales în faptul că programatorii vor din ce în ce mai mult să își creeze produsele proprii, iar acceleratoarele locale încep să își facă simțită prezența. Prin produsele dezvoltate în outsourcing sau parte dintro mare corporație, s-a demonstrat faptul că tehnic putem realiza orice, din păcate, din cauza confidențialității, majoritatea dintre ele nu pot fi făcute publice. Universitățile devin din ce în ce mai deschise în comunicarea cu specialiștii ce nu sunt parte a lumii academice și sperăm să vedem în curând mai multe cursuri despre antreprenoriat și de ce nu, chiar un accelerator pentru studenți în care practica și cercetarea se reunesc.

Startup-uri clujene

să comande mâncare la birou sau acasă. Marius Mocian, un În continuare vă propun o listă de startup-uri locale ce merită susținător local a startup-urilor este parte din această echipă. să fie urmărite. Mulțumesc lui Mircea Vădan și lui Marius Mornea Evolso5 - un startup pornit de către Alin Stănescu și este acum pentru realizarea acesteia. În numerele următoare vom reveni cu parte din programul de accelerare de la StartupYard. un infografic.

Mira Rehub6 - unul dintre cele mai promițătoare startup-uri locale. Au realizat un sistem de recuperare a celor cu probleme Squirrly1 - Este un plugin SEO de wordpress. Compania a fost locomotorii folosind senzorul Kinect. înființată de către Florin Mureșan și se bucură deja de un număr Mockups7 - implementeză creearea de mockup-uri online mare de clienți. De asemenea, este sprinjinit de către Phillip având o bază mare de useri online.

Kandal, co-fondator Skobbler.

HackaServer2 și CTF3653 - un vechi startup clujean condus de Ovidiu Măţan ovidiu.matan@todaysoftmag.com către Marius Corâci și Marius Chiș. Acesta se adresează hackerilor ce doresc o provocare legală și administratorilor de sisteme ce Editor-in-chief doresc o îmbunătățire a securității printr-o testarea reală.

Today Software Magazine 4 HipMenu - este o aplicație ce se adresează celor ce vor 1 http://www.squirrly.co

5 http://www.evolso.com

2 http://hackaserver.com

6 http://www.mirarehab.com

3 http://ctf365.com

7 https://moqups.com

4 https://www.hipmenu.ro

8

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

www.todaysoftmag.ro | nr. 25/Iulie, 2014

9

eveniment

RICAP: drumul inovației de la laborator către piețe globale

L

a începutul lunii iunie, s-au lansat aplicațiile pentru cea de-a doua ediție a Programului de Asistență în Comercializarea Inovării din România (RICAP)!

RICAP a luat naștere din dorința de a oferi resurse inovatorilor din România pentru a ieși pe piețe internaționale cu produsele lor, fie că este vorba despre energie, bio-tehnologii, agricultură, ICT sau orice alt domeniu tehnologic. RICAP este astfel primul program din România care sprijină inovatorii și antreprenorii cu tehnologii inovatoare să le comercializeze pe piața globală, facilitând drumul din laborator către piață. În acest efort, programul se bazează pe un parteneriat internațional cu unul dintre cele mai importante institute din SUA care sprijină comercializarea inovăriiLarta Institute, pe legăturile internaționale și know-how-ul acestei rețele, precum și pe rețeaua de mentori pe care o consolidăm la nivel local. „Când se vorbește despre problemele business-urilor și startup-urilor, eu spun de fiecare dată că și banii sunt o parte a problemei, dar cea mai importantă problemă este lipsa de know-how(...) Experiența pe care am avut-o în programul RICAP a fost în primul rând o experiență de coaching.

De-asta am și intrat, asta am căutat, un mediu care să mă încurajeze să studiez eu, după programul pe care îl voiam eu, după prioritățile pe care consideram că le avem, și să atacăm problemele pas cu pas. ” Daniel Homorodean, director Arxia, antreprenor participant în program.

Aplicațiile se fac online, până pe 31 iulie 2014, direct pe site-ul programului: www. ricap.ro.

Ce s-a întâmplat până acum?

Prima ediție a RICAP a avut loc în perioada ianuarie – mai 2014. În acest timp, 15 inovatori au lucrat alături de o echipă dedicată de mentori și advisori extraordinari într-un program de mentorat personalizat,

10

pentru a dezvolta și implementa instrumente de comercializare: strategii de intrare pe piață, strategii de comercializare, prezentări pentru clienți. În funcție de nivelul de dezvoltare al companiilor, programul a facilitat peste 30 de legături strategice cu posibili parteneri și finanțatori din SUA și din Europa, inclusiv membri ai Fortune 1000 din Industry Advisory Board-ul Larta, partenerul american al programului. În plus, două companii au fost în Statele Unite unde au beneficiat de aproximativ 15 întâlniri de business cu posibili parteneri și finanțatori.

Experiența a fost diferită pentru cei 15 participanți.

“Acest program se poate adapta la nevoile participanților, oriunde v-ați afla în spectrul de la pur om de știință până la om de business.” Alexandru Floareș, SAIA și Onco Predict, om de știinta și antreprenor participant la RICAP.

Pitiș, profesor, antreprenor, business angel și neobosit susținător al ecosistemului inovării și al start-up-urilor tech din România, pe Norina Boru, antreprenor și consultant cu o vastă experiență în domeniul medical din România și la nivel internațional. De asemenea îi menționăm pe Alex Mircea Dascălu, un antrepenor și consultant cu experiență internațională, și pe Sanda Foamete, education lead la Microsoft.

Mai multe despre mentori cât și despre inovatorii care au participat la prima edițe RICAP, puteți citi pe www.ricap.ro/blog.

Cine suntem

RICAP este rezultatul unui parteneriat între Centrul Român pentru Inovație în Dezvoltare Locală (CRIDL) și Institutul Larta, localizat în Los Angeles, SUA. Programul este finanțat de Romanian-American Foundation (RAF) și implementat cu sprijinul GEA Strategy & Consulting. RICAP construiește pe rețeaua internațională și expertiza acumulată timp de 20 de ani de Larta Institute prin susținerea a circa 9.700 de inovatori din 17 țări.

La începutul lunii iunie, am lansat a doua ediție RICAP, în cadrul căreia am avut evenimente și întâlniri în mai multe orașe ale țării. Am avut ocazia să cunoaștem inovatori pasionați și cu viziune care au Contact dezvoltat produse incredibile. www.ricap.ro | www.ricap.ro/blog | Întâlnirile cu toți acești oameni și Facebook/LinkedIn: RICAP - Innovation discuțiile vibrante pe care le-am avut cu from lab to market | contact@ricap.ro mulți dintre ei ne-au validat că ceea ce facem la RICAP le poate oferi un sprijin real, atât lor cât și utilizatorilor produselor lor.

Un rol cheie în prima ediție RICAP l-au avut, alături de inovatorii selectați în Silvia Ursu silvia.ursu@cridl.org program, mentorii români care le-au fost alături și i-au sprijinit în definirea viziunii Communications Coordinator @RICAP și strategiei de comercializare și nu numai.

I-am avut alături de noi pe Andrei

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

startups

TODAY SOFTWARE MAGAZINE

ZenQ – “Modul de a spune mulțumesc și de a-ți aprecia prietenii și colegii extraordinari”

N

oi credem că fiecare om în parte este extraordinar și ar trebui să audă acest lucru mai des. De aceea construim ZenQ: modul de a spune mulțumesc și de a-ți aprecia prietenii și colegii extraordinari. Pe mobilul tău. În secunde.

Început la Startup Weekend Cluj în martie drept un MVP numai pentru iOS, proiectul a crescut rapid, cu aplicațiile iOS și Android live în magazine din 7 mai.

Cum funcționează ZenQ? Imaginați-vă cum ar fi să răsfoiți printre prietenii voștri de pe facebook și să îi aprobi, exact cum faci pe Linkedin, dar de data asta pentru calitățile lor (amuzant, deștept, creativ). Cineva ți-a făcut ziua mai frumoasă și vrei să faci cunoscut acest lucru? Poți găsi acea persoană în aplicație și îi poți lăsa o însemnare prin care îi arăți cât de nemaipomenită este. La

final, fiecare dintre noi dobândește un profil în care îți poți descoperi punctele forte prin ochii prietenilor tăi. Deci, în esență, ZenQ înseamnă răspândirea vibrațiilor pozitive, distracție, bucurie.

Din spatele cortinei, ZenQ este acționat de un backend Django care utilizează informațiile de login pe Facebook acumulate de clienți pentru a obține prietenii utilizatorului de pe Facebook și a-i oferi din nou clienților la cerere. Lista trăsăturilor este de asemenea furnizată de serviciul backend, făcând-o ușor de actualizat pe baza feed-back-ului de la utilizatori. Aceste informații sunt apoi folosite pentru a crea profilele utilizatorilor care acum arată o listă de trăsături cu care a fost învestit un utilizator, ordonate după numărul de susținători. „Fața” ZenQ o constituie clienții mobili: iOS și Android.

Interfața utilizează o paradigmă de navigare foarte simplă care necesită maxim două atingeri pentru a ajunge oricând la orice ecran. Totuși, atenția se concentrează în mare parte pe ecranul „ZenQify”, care este primul ecran pe care îl vede utilizatorul atunci când deschide aplicația. Mai mult, utilizatorul se poate întoarce ușor la el după ce a deschis alte ecrane, făcând din acesta punctul central al aplicației. Utilizatorii pot de asemenea să susțină anumiți prieteni, căutându-i și accesându-le profilul, unde pot lăsa și mesaje legate de trăsătura pentru care doresc să subscrie.

Procesul de dezvoltare al ZenQ este distractiv, iar feedback-ul de la câteva sute de utilizatori beta a fost pozitiv până acum. Acum câteva zile am lansat noile versiuni pentru iOS și Android. De abia așteptăm să primim mai mult feedback și să aflăm ce i-ar face pe utilizatori mai fericiți și mai implicați în aplicație. În primul rând, noi credem că ZenQ poate întări optimismul și interacțiunile pozitive din diverse comunități, organizații și companii. Se întâmplă adesea ca, în aceste tipuri de mediu, să ne concentrăm atât de mult pe îndeplinirea sarcinilor încât

relațiile să se ofilească, iar acest lucru, pe termen lung, afectează cu adevărat forța grupului. Într-un al doilea scenariu, noi credem că interacțiunea ușoară și distracția magică oferită de ZenQ le-ar face plăcere utilizatorilor și că se vor implica în acest joc social de susținere a prietenilor lor.

Vă rugăm să vizitați www.zenq.co pentru a obține aplicația pe smartphone-ul vostru și oferiți-ne feed-back la adresa contact@ zenq.co. Vă mulțumim mult!

Mihai Costea mihai.costea@gmail.com iOS Developer @ Zenq

www.todaysoftmag.ro | nr. 25/Iulie, 2014

11

business

Despre relevanța practicii studențești

U

na dintre preocupările constante ale Cluj IT Cluster este resursa umană din industrie. Este de notorietate faptul că IT-ul clujean, încă în mod substanțial bazat pe servicii de outsourcing, are nevoie constantă de oameni cât mai bine pregătiți și cât mai numeroși.

Este de asemenea cunoscut faptul că majoritatea companiilor de IT din orașul nostru sunt în continuă căutare de noi talente. După datele existente vehiculate, confirmate și de către membrii noștri, vorbim de sute de locuri de muncă vacante și pentru care este dificil să se găsească candidații potriviți. Este de asemenea cunoscut faptul că salariile din industria IT sunt ca medie mult peste nivelul național și că, într-o comparație a puterii de cumpărare, au devenit competitive și la nivel global. Ca o paranteză, remarc un fenomen interesant de migrație a forței de muncă, dar care este în același timp paradoxal, un fenomen pe care un CEO al uneia din companiile din Cluster l-a denumit “reversed outsourcing”. Practic, din ce în ce mai multe companii încearcă să suplinească penuria locală de talente de pe piața muncii prin importul ei din alte țări și, surprinzător, nu dintre cele cu standard mai scăzut de viață decât cel din România.

Dar cât de cunoscute sunt toate acestea de către cei pe care am dori să îi vedem că aleg o carieră în IT? Le sunt și lor cunoscute aceste realități? Sau, mai degrabă,

12

trăim cu impresia că realitățile care ne sunt nouă apropiate (ca nivel de cunoaștere sau ca interes) sunt la fel de bine cunoscute și de alții? După toate aparențele creionate de situația concretă a nealinierii ofertei cu o cerință certă a pieței muncii, realitățile acestea nu sunt cunoscute sau în cel mai bun caz, sunt puțin cunoscute. În această situație se naște întrebarea firească de ce anume se întâmplă acest lucru și care ar fi mecanismele prin care putem interveni pentru ca talentele de care avem nevoie să fie și disponibile. Sunt mai multe răspunsuri atât în ceea ce privește cauzele, cât și pentru soluții, dar cum spațiul e limitat am să mă refer acum doar la felul în care se organizează practica studențească în România, care, cel puțin teoretic, ar trebui să fie un instrument puternic de inserție pe piața muncii.

Planul de învățământ prevede efectuarea obligatorie, contra unui număr de credite, a unui stagiu de practică de specialitate care, de regulă, este de 90 de ore.

Acestea pot fi distribuite de-a lungul a două semestre, fapt care se și întâmplă în realitate. Fragmentarea a unui număr extrem

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

de puțin de ore este, cel puțin din punctul meu de vedere, o greșeală. Practic studentul nu are răgazul necesar pentru a înțelege și a trage concluziile referitoare la ceea ce se întâmplă în compania / organizația în care a ajuns, dacă acea instituție poate sau nu să fie opțiune reală de carieră. Mai mult decât atât, stagiul de practică este definit, prin lege, ca o disciplină de sine stătătoare!

Toate acestea mă îndreaptă spre o concluzie firească care spune multe despre felul în care este de fapt perceput acest instrument.

Ca să fiu mai explicit am să aduc exemple din alte state europene. În Olanda, de pildă, programele de masterat prevăd cel puțin un semestru, dacă nu chiar un an întreg de practică studențească în domeniul de pregătire al persoanei respective. În Germania, de exemplu, sunt implementate programe speciale duale de tip vocațional în care sunt îmbinate stagiile de practică cu cele teoretice, asigurându-se astfel un corp consistent de oameni bine pregătiți pentru ceea ce economia poate oferi. Exemplele pot continua, desigur, și toate relevă o preocupare pentru realizarea și susținerea unui mecanism cât mai eficient de inserție

TODAY SOFTWARE MAGAZINE

pe piața muncii.

Cadrul în care evoluăm în România nu este, după cum se poate constata, unul foarte favorabil, dar acest lucru nu ne descurajează. Ca parte a eforturilor de a aduce în atenția tinerilor, dar nu numai, a oportunităților de carieră și de viață pe care industria noastră le oferă, Cluj IT Cluster a demarat un program prin care încercăm să realizăm acel nivel de cunoaștere necesar pentru o decizie informată asupra pregătirii și dezvoltării profesionale, mai ales în cazul tinerilor care urmează studii superioare sau intenționează să se înscrie la o unviersitate.

Programul este mai amplu, cuprinde mai multe etape și niveluri de acțiune, unele în fază mai avansată de pregătire, altele încă în fază de idee. Nu este nici locul și, probabil, nici momentul pentru a intra în detalii, însă, un prim pas a fost deja făcut. Cluj IT Cluster este partener într-un proiect cu finanțare nerambursabilă europeană cu Universitatea Babeș-Bolyai prin care vom facilita accesul la stagii de practică organizate cu precădere la companii și organizații membre ale Cluj IT Cluster pentru un număr de 400 de studenți provenind de la Facultățile de Matematică și Informatică și Facultățile de Științe Economice și Gestiunea Afacerilor (FSEGA). Proiectul este intitulat „Creşterea oportunităţilor de ocupabilitate prin practică de success (PRACT-IT) și este cofinanţat din Fondul Social European prin Programul Op erational S ec tor ial D ezvolt are a Resurselor Umane 2007 – 2013.

Dincolo de declarație de intenție și de obiectivele seci ale unui proiect, această inițiativă dorim să fie una prin care reușim să facem mai bine înțeleasă industria de IT,

deopotrivă oportunitățile pe care le oferă, participanți vor reuși să valorifice o șansă dar și rigorile cerute de angajatorii din acest reală de carieră. Așa cum arată industria de domeniu. Acesta este și motivul pentru IT azi în Cluj, depinde doar de ei. care designul proiectului a prevăzut din start includerea studenților provenind de la FSEGA, nu doar pe cei de la Matematică și Informatică. Cu alte cuvinte am dorit să mergem dincolo de profilul clasic al angajatului care provine de la o facultate de profil unde industria este mai bine cunoscută și să extindem astfel cercul de cunoaștere și în alte domenii de pregătire.

Proiectul urmăreşte în cele din urmă creșterea atât a relevanței studiilor și competențelor dobândite în timpul stadiilor de învățare prin aprofundarea acestora în cadrul unor stagii de practică aplicată cât și o inserție cât mai bună a celor incluși în proiect pe piața muncii. Creșterea oportunităților de angajare va fi asigurată complementar și în prealabil prin acțiuni de informare si consiliere profesională pentru un număr de 450 de studenți. Studenții care vor participa la activitățile proiectului vor proveni de la specializările: matematică, informatică, informatică economică, statistică, marketing, afaceri internaţionale, economie generală şi contabilitate și vor fi selectați, în baza unui proces transparent pentru participare în proiect.

Proiectul are o durată de implementare de 18 luni și a demarat la data de 5 mai 2014, iar activitatea efectivă cu studenții va începe odată cu noul an universitar, adică din octombrie 2014, mai întâi cu selecția Andrei Kelemen lor, apoi parcurgerea etapei de consiliere andrei.kelemen@clujit.ro profesională și, în cele din urmă, stagiile de practică. Speranța este că vom reuși Director executiv @ IT Cluster să instituim un nou model de derulare a acestor stagii de practică și că studenții

www.todaysoftmag.ro | nr. 25/Iulie, 2014

13

startups

Drive Your Community for Better, alături de tineri antreprenori clujeni

L

a final de iunie, Deutsche Welle publica o analiză economică arătând cum Germania e în continuare o ţară cu „două economii”, din cauza diferenţelor uriaşe de venit dintre Germania de Vest şi Germania de Est (http://www.dw.de/mapping-differencesin-two-german-economies/a-17734799). Toate acestea s-au întâmplat, după eforturi uriaşe făcute de guvernul federal, precum transferul a aproape trei trilioane de euro dinspre Vest spre Est. Banii s-au dus cel mai mult în infrastructură şi nu în a porni „motorul dezvoltării” – iniţiativele antreprenoriale, spune profesorul Gerald Braun, de la University of Rostock, citat în articol. Cu alte cuvinte, antreprenoriatul face diferenţa… iar Fundaţia Danis pentru Dezvoltare Managerială crede şi promovează ideea că o comunitate puternică se bazează pe afaceri profitabile şi stabile.

Cel mai recent proiect al Fundaţiei Danis de educaţie antreprenorială este – „Drive Your Community for Better”.

Proiectul sprijină tineri antreprenori clujeni şi, în acelaşi timp, mobilizează comunitatea pentru recunoaşterea rolului important pe care antreprenoriatul de succes îl joacă în dezvoltarea economică a unei societăţi. Astfel, proiectul este finanţat exclusiv de donatori individuali – peste 100 de oameni, până acum!

Educaţie antreprenorială, dincolo de clasicul plan de afaceri

Odată trecuţi de etapa esenţială a planului de afaceri, antreprenorii trebuie să înveţe să îşi construiască businessul pas cu pas, atrăgând în „visul” lor investitori, finanţatori, parteneri şi clienţi. „Drive Your Community for Better” oferă tinerilor antreprenori cunoştinţe de bază de educaţie financiară şi de economie comportamentală, cunoştinţe care contribuie la dezvoltarea şi stabilizarea financiară a firmelor aflate la început de drum. Proiectul s-a născut din nevoile pe care le au

14

tinerii antreprenori şi care au fost identificate de fundaţie în ultimii ani de activitate: „Prin proiectele noastre, până acum, am ajutat peste 200 de antreprenori aflaţi la început de drum să îşi facă planuri de afaceri temeinice, să îşi deschidă afacerile visate sau să participe la schimburi de experienţă cu antreprenori de succes. Din interacţiunile cu aceşti antreprenori am văzut că cei mai mulţi dintre ei au carențe în cunoștințe și competențe în domeniul educației financiare, mai precis în realizarea planificărilor financiare, în înțelegerea principiilor de bază de contabilitate şi în obținerea și gestionarea finanțărilor.”

(Cordelia Bădescu, Director Executiv Fundaţia Danis).

De asemenea, un studiu Capital din 2013 arată că un IMM din trei moare în primul an de activitate (http://www.

capital.ro/un-imm-din-treimoare-in-primul-an-dela-infiintare-183199.html ).

Aproape 10% din firmele din România se închid în primul an de activitate și aproximativ 30% dintre cele care rămân înființate

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE sunt inactive. Peste 75% dintre antreprenori au renunțat la business pentru că nu au avut suficiente resurse, ceea ce indică slabe cunoștințe și competențe de a atrage finanțări și a le gestiona în mod eficient.

Proiectul „Drive Your Community for Better” răspunde acestor nevoi oferind antreprenorilor care vor fi acceptaţi în proiect ateliere de educaţie financiară, organizate pe următoarele direcţii: obținerea de finanțări (linii de finanțare, atragere de investitori) şi planificarea și gestionarea resurselor financiare (realizarea planului financiar, calcularea pragului de rentabilitate, bugetare, folosirea cashflow-ului). De asemenea, antreprenorii vor participa şi la un work-shop de economie comportamentală, cu focus pe elemente de iraţionalitate în luarea deciziilor. Acesta este organizat probono de Danis Consulting. De asemenea, o parte dintre antreprenorii participanţi la proiect vor primi şi resurse financiare pentru mici investiţii de început de afacere.

Atelierele din cadrul proiectului vor avea loc în a doua parte a lunii septembrie. Peste vară, are loc selecţia celor mai motivaţi 15 tineri antreprenori. În proiect vor fi acceptaţi antreprenori care acum sunt în faza de planificare sau deschidere a unui business sau au o experienţă în administrarea unei afaceri mai mică de trei ani. Selecţia se face pe baza completării unei aplicaţii online şi a unui interviu. Aplicaţia poate fi completată la următorul link: https://

Cele mai importante criterii de selecţie sunt înclinaţia antreprenorială, motivaţia pentru participarea la proiect şi planul concret de activităţi pentru dezvoltarea afacerii pentru următorul an. Înscrierile se fac până la finalul lunii iulie. Detalii la: office@fundatiadanis.ro.

Astfel, până atunci, sunt şanse mari ca numărul celor care susţin proiectul „Drive Your Community for Better” să crească şi mai mult.

Proiect susţinut exclusiv de donatori individuali, oameni care cred în antreprenoriat

„Drive Your Community for Better” este un proiect finanţat în mod exclusiv de donatori individuali, adică de oameni care cred în valoarea şi importanţa antreprenoriatului. Până acum peste 100 de oameni au ales să susţină proiectul Fundaţiei Danis, prin două iniţiative de mobilizare de resurse.

Una dintre iniţiative este un eveniment de strângere de fonduri organizat de Fundaţia Danis în parteneriat cu Toyota Cluj-Napoca şi Tokyo Restaurant Japanese, la finalul lunii mai. În cadrul acestui eveniment de test drive asortat cu specialităţi culinare japoneze, manageri şi antreprenori cu experienţă din Cluj au ales să susţină financiar proiectul „Drive Your Community for Better”.

A doua iniţiativă este înscrierea proiectului la Swimathon, un eveniment de strângere de fonduri organizat de Fundaţia Comunitară Cluj. La Swimathon, proiectul e susţinut de şapte înotători, care la rândul lor sunt sprijiniţi de prieteni, docs.google.com/a/fundatiadanis.ro/ familie şi cunoştinţe, care contribuie forms/d/1lyG9GmdKjNiDfm4DoZ5z_ financiar la dezvoltarea antreprenoriatului i S m g B 7 _ e x x 5 q C n H 6 0 - Q 8 g E / clujean. Campania de strângere de fonduri viewform. a Swimathon-ului se încheie la finalul verii.

Paula Beudean

paula.beudean@fundatiadanis.ro Coordonator Proiecte @ Fundația Danis

www.todaysoftmag.ro | nr. 25/Iulie, 2014

15

comunități

Comunităţi IT

L

una iulie vine cu mai puține evenimente. Vă propunem Cluj Business Days și bineînțeles vă așteptăm în 22 iulie la lansarea număului 25 TSM.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

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

Website: www.facebook.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 1606/Nr. Evenimente: 20 Cluj Business Analysts Comunitate dedicată analizei de business Website: www.meetup.com/Business-Analysts-Cluj Data înfiinţării: 10.07.2013 / Nr. Membri: 77 / Nr. Evenimente: 6 Cluj Mobile Developers Comunitate dedicată tehnologiilor mobile Website: www.meetup.com/Cluj-Mobile-Developers Data înfiinţării: 05.08.2011 / Nr. Membri: 196 / Nr. Evenimente: 13 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: 433 / Nr. Evenimente: 76 Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice.

Website: www.meetup.com/Cluj-Semantic-WEB Data înfiinţării: 08.05.2010 / Nr. Membri: 184/ 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: 244/ 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: 323/ Nr. Evenimente: 31

16

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

Calendar Iulie 9-10 (Cluj) Cluj Business Days - recomandarea TSM businessdays.ro/Evenimente/Cluj-2014 Iulie 19 (Iași) Iasi Inaugural MUG mongostat meetup.com/Iasi-MongoDB-User-Group/events/191672362/ Iulie 14 (Cluj) Personalized information discovery meetup.com/Cluj-Semantic-WEB/events/186829692 Iulie 19-20 (București) Startcelerate bucharest.startcelerate.com Iulie 22 (Cluj) Lansarea numărului 25 a Today Software Magazine (Cluj) www.todaysoftmag.ro Iulie 23 (Cluj) Requirements Engineering - Factor of successful projects meetup.com/Business-Analysts-Cluj/events/192771622/ Iunie 28 (Cluj) Mobile Monday Cluj #10 meetup.com/Cluj-Mobile-Developers/events/177046842/

programare

IT-ul românesc quo vadis

I

nspirat de Ovidiu Șuța (ISDC) prin articolul său “Ce este în neregulă cu IT-ul din România?” din ediția 23 a TSM, simt nevoia de a face un exercițiu de imaginație (sau nu) prin a picta o posibila direcție a viitorului IT-ului românesc.

Ovidiu Simionica

ovidiu.simionica@fortech.ro Team Lead @ Fortech

Părerea care reiesea din articolul menționat și pe care o împărtășesc este aceea că businessul de volum specific modelului outsourcing a devenit dăunator înseși pieței pe care o adresează. În rândurile următoare vom încerca să propunem moduri care ar putea schimba fața software-ului românesc.

Ca și în cazul unui chirurg, totul se reduce la modul de execuție. Îmbinarea cunoștințelor cu tehnica de lucru trebuie să rezulte în perfecțiune.

Deci avem două părti ale ecuației: pregătirea personalului și calitatea execuției. În domeniul pregătirii personalului lucrurile stau mult mai bine decât acum 10 ani. Internetul abundă de informații, firmele de atestare s-au maturizat și acum poți obține validarea cunoștințelor în practic orice aspect al activităților software (de la management la framework-uri și limbaje de programare specifice, până la aptitudini de testare validate ISTQB). Singurul obstacol este modul de aplicare în cadrul companiilor. Învățarea este parte din munca de la birou și orice afacere care își propune să fie pe piață și peste 30 de ani va înțelege că, dacă n-a făcut-o deja, trebuie să își regândească strategia astfel încât să își permită o investiție zilnică în training pe angajat cu tot

ce presupune aceasta (e.g. schimbarea formulelor de ofertare a proiectelor, achiziționarea programelor de training etc.). În ceea ce privește asigurarea calității produselor software consider că practicile autohtone sunt deficitare. Folosirea departamentelor de testare în validarea calității unui produs software este greșit înțeleasă și aplicată.

Contrar convingerilor (care par generalizate) ale organizatiilor care s-au grăbit să-și promoveze pe site-urile proprii, spre exemplu, alinierea la standardele ISO, producția de software are foarte puține lucruri în comun cu producția de lapte sau ouă.

Alte mijloace sunt în schimb mult mai potrivite și voi scrie despre acestea în continuare. Ele alcătuiesc corpul acestui articol și le consider absolut necesare când ne referim la calitate.

Versioning tool

Versionarea codului sursă în IT-ul românesc a devenit de ceva vreme status quo, în mare parte datorită dinamicii echipelor de dezvoltare, dar și cerințelor clienților.

Singurul sfat ar fi să nu rămâneți în urmă cu tendințele, nu folosiți CVS când la modă este GIT.

www.todaysoftmag.ro | nr. 25/Iulie, 2014

17

programare IT-ul romanesc quo vadis Project documentation & issue tracking

Folosiți tool-uri integrate și “full-feature” deoarece sunt atât de ieftine și aduc un aport enorm calității. Clientul va avea prin intermediul lor un acces și control de top asupra stării proiectului și îi va spori încrederea în parteneriat.

Continuous integration

scrierea de unit teste, refactoring, etc.) cu prioritate codul care are complexitate ridicată și coverage scăzut.

• Dependency analysis: nu permiteți dependențe circulare în cod atât la nivel de pachete, cât și la nivel de fișiere.

Code review

Aderați la principiile solide1 și tindeți către simplitate atunci Un “must” indiferent de limbajul de programare. Nu pot con- când inspectați codul. cepe un proiect fără a ști starea codului în orice moment. Unelte ca și Jenkins sunt indispensabile. La orice modificare adusă codului Cum ne asigurăm că IT-ul din România nu o va lua pe drumul veți fi înștiințați dacă testele automate s-au executat cu succes și Indiei? dacă metricile de calitate sunt în limitele propuse. Combinat și cu Dând un exemplu în Cluj care să inspire restul comunității. scripturi de instalare, puteți configura un sistem live unde clien- E nevoie de un cadru formal care să ofere greutate și care să fie o tul poate accesa oricând cea mai nouă versiune a produsului. Am declarație de anagajament către menținerea unui standard ridicat lucrat în trecut în Germania la un client de renume (ce activa în de performanță și profesionalism. Un astfel de cadru ar trebui să industria de creare soluții software) care avea ca și unică moda- fie susținut de firmele de software autohtone. Sunt cunoscute deja litate de a produce o versiune a produsului compilarea în IDE și diverse forme dintre care cel mai recent și promițător este clusterarhivarea manuală. Nici urma de Gradle, Maven, Ant sau măcar ul Cluj IT (http://www.clujit.ro) și citez: un bash script. Inutil să spun că o astfel de abordare nu poate fi acceptabilă când discutăm despre calitate (chiar și când nu discuAbout us tăm despre calitate).

Cluj IT is a cluster association aiming to enhance the innovation capabilities and competitiveness of the Romanian IT sector.

Testare automată

Nu există motiv să nu folosim testare automată. Și mai mult, trebuie să fie de toate formele: unit testing, integration testing, regression automation (e.g. selenium). Am auzit toate motivele pentru a nu le face, însă nici unul întemeiat. Recent mi s-a spus că nu are rost să testăm javascript-ul pentru că oricum e acoperit de tastarea manuală. Am insistat să fie testat automat. Argumentele apoi s-au schimbat: e foarte dificil de testat... Dar “dificil” nu e un argument.

Pare promițător și mă determină să îmi imaginez un grup de programatori formând o comisie comună de acreditare a calității proiectelor din fiecare firmă partener la custer. Poate o idee ambițioasă, dar cu siguranță cu un impact bun pe termen lung.

Aștept păreri de la cititori.

Metrici de calitate

Sunt foarte multe la alegere, unele mai simple analizează convențiile de stil, altele merg până la a măsura complexitatea unui bloc de cod. Construirea unui pachet de bază și aderarea la el face parte din orice setup de proiect. Cele mai relevante sunt: • Code coverage: ca regulă generală până în 74% e prea puțin, peste 85% este prea mult și în special acordați atențe la conditional coverage.

• Code complexity versus coverage matrix: atacați (prin

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

18

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

1 http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29

programare

programare

Java 8, noutăţi şi îmbunătăţiri

Î

n numărul 23 al revistei Today Software Magazine am început o discuţie despre ceea ce aduce nou Java SE8. Aproape unanim, specialiştii în Java susţin că expresiile lambda, ca topic general, dar şi implicaţiile produse de acestea, reprezintă cele mai importante feature-uri ale versiunii actuale. De aceea am considerat util ca primul articol să fie despre acest topic.

Silviu Dumitrescu

silviu.dumitrescu@accesa.eu Java Line Manager @ Accesa

Discuţiile din acest articol sunt purtate la un nivel de dificultate mai ridicat, pentru a permite evidenţierea unor aspecte de performanţă, productivitate şi de reducere a dimensiunii codului scris.

Pentru început revin la expresiile lambda.

Prin expresii lambda putem crea metode anonime. Uneori însă, expresiile lambda apelează metode care au deja un nume.

Pentru a clarifica lucrurile revin la exemplul din articolul amintit la început. Avem o clasă Product cu două atribute, name și price, getter-i şi setter-i. Voi mai adăuga proiectului nostru o clasă POJO în care se află diverse metode de comparare, cu semnături apropiate de ale metodei compare() din interfaţa Comparator: public class ProductComparisons { public int compareByName( Product a, Product b) { }

return a.getName(). compareTo(b.getName());

Această sintaxă este posibilă pentru că rezultatul expresiei lambda este o clasă anotată @FunctionalInterface, în cazul nostru, Comparator. În locul folosirii expresiilor lambda, Java SE8 oferă posibilitatea utilizării referinţelor de metode, prin intermediul operatorului de domeniu ::. Sintaxa este astfel mult simplificată.

Revin la exemplul nostru şi aplic operatorul anterior. Sintaxa devine: Arrays.sort(basket, myComparison::compareByName);

Avem următoarele tipuri de referinţe: • La o metodă a unui obiect (exemplul anterior).

• La o metodă statică (exemplul anterior poate fi uşor customizat).La o metodă a unui obiect arbitrar de un tip particular: Arrays.sort(stringArray, String::compareToIgnoreCase).

public int compareByPrice( Product a, Product b) { return a.getPrice() b.getPrice(); } }

• La un constructor:

În clasa de test vom crea două obiecte Product, p1 şi p2, pe care le vom pune într-un array: Product[] basket = { p1, p2 };

Vom sorta array-ul folosind expresiile: ProductComparisons myComparison = new ProductComparisons();

Arrays.sort(basket, (a,b)->myComparison. compareByName(a, b));

Supplier<Product> s = Product::new;

unde Supplier este din

java.util.function.Supplier;

Un alt subiect pe care vreau să vi-l supun atenţiei este legat de interfeţe. Interfeţele conţineau, până la această versiune, doar semnături de metode şi constante. Java 8 propune o abordare care să îmbunătăţescă

www.todaysoftmag.ro | nr. 25/Iulie, 2014

19

programare Java 8, noutăţi şi îmbunătăţiri utilizabilitatea interfeţelor. Dacă adaugăm noi semnături în API-urile folosite în discuţiile anterioare. interfaţa atunci clasele ce o implementează ar trebui rescrise.

• java.util.function, ce furnizează interfeţele funcţionale Pentru a evita procesul rescrierii s-au introdus metodele default. ce sunt returnate ca tip prin intermediul expresii lambda.

Pe lângă semnături şi constante, interfeţele vor conţine astfel şi Interfeţele funcționale reprezintă concepte abstracte precum implementări. funcţiile, acțiunile sau predicatele.

Voi da un exemplu simplu, care să evidenţieze noile abordări: • java.util.stream, ce furnizează clase pentru operaţii pe stream-uri de elemente. Stream-urile diferă de colecţii prin: public interface MyInterface {

void myClassicMethod(); • stream-ul nu este o structură de date, ci transformă o structură de date într-un pipeline de operaţii.

default void myDefaultMethod() { System.out.println(“hello default!”); • o operaţie pe un stream produce o operaţie, dar nu } modifică sursa.

static void myStaticMethod(){ • Operațiile pe stream-uri sunt implementate lazy, ceea ce System.out.println(“hello static!”); înseamnă că pot expune oportunităţi de optimizare. } } • stream-urile sunt practic infinite. Există şi operații Respectiv clasa ce implementează interfaţa: de scurtcircuitare care să producă ieşiri într-un timp finit (limit(), findFirst()) public class MyClass implements MyInterface {

@Override • stream-urile sunt consumabile, adică elementele sunt

public void myClassicMethod() { vizitate o singură dată. Pentru o revizitare trebuie creat un System.out.println(“hello classic!”); alt stream. } • toate clasele wrapper (Boolean, Integer, etc.) au fost îmbu} nătăţite cu metode care folosesc expresiile lambda şi referinţe Ca test avem: de metode. public static void main(String[] args) { MyInterface mine = new MyClass();

mine.myClassicMethod();

mine.myDefaultMethod(); MyInterface.myStaticMethod(); }

Surprindem astfel cele trei comportamente: • C el predef init, c u calif icator ul public abstrac t (myClassicMethod).

• Cel cu implementare default.

• Cel cu implementare static default.

Procesul de moştenire are suport și pentru acest nou comportament. Altfel: • Metodele default care nu sunt menţionate în interfaţa derivată moştenesc comportamentul default din interfaţa de bază.

• Metodele default redeclarate în interfaţa derivată devin abstracte.

• Metodele default redefinite în interfaţa derivată vor fi folosite suprascris.

Nu voi încheia acest articol fără să descriu câteva dintre

20

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

Discuţiile despre Java SE8 vor continua şi în ediţiile viitoare ale TSM. Pînă atunci lectură plăcută şi o vară frumoasă!

management

programare

Suportul JSON în PostgreSQL

E

xistă o nevoie crescândă incontestabilă pentru flexibilitate și scalabilitate în ceea ce privește datele, acesta fiind și motivul pentru care mulți au apelat la baze de date NoSQL pe durata ultimilor ani. Există avantaje și dezavantaje în ceea ce privește folosirea lor, mai ales că acestea nu au fost destinate să înlocuiască bazele de date relaționale.

Raul Rene Lepsa raul.lepsa@3pillarglobal.com Java Devolper @ 3Pillar Global

Dezvoltatorii și arhitecții soft au deseori dificultăți în a alege una sau alta, în special când formatul datelor ce urmează să fie folosite este necunoscut sau poate fi modificat ulterior. O soluție de compromis este folosirea atât a bazelor de date relaționale cât și a celor non-relaționale și crearea unui sistem de comunicare între ele. Însă această soluție poate ajunge să dea mai multe dureri de cap și probleme decât dacă s-ar folosi doar un sistem de baze de date.

De ce nu 2 în 1?

Companii precum IBM și Oracle au început să ofere metode prin care Sistemele de Baze de Date Relaționale (RDBMS) și cele non-relaționale să coexiste. PostgreSQL oferă o alternativă prin tipuri de date speciale, cu o structură mai liberă și flexibilă, care imită comportamentul NoSQL într-un RDBMS. Începând cu versiunea 8.3, PostgreSQL a introdus tipul de date hstore, care este folositor pentru rânduri cu multe atribute care sunt rar examinate și date semi-structurate.

Permite stocarea de perechi cheie-valoare (similar cu unele NoSQL-uri), suportă diferite operații și oferă funcții pentru manipularea lor. În versiunea 9.2 a fost introdus tipul de date JSON, căruia i s-au adus îmbunătățiri în

ceea ce privește performanța în versiunea 9.3 beta. JSON (Javascript Object Notation) este un format lightweight, lizibil și independent de limbaj, pe care Postgres îl stochează sub formă de text.

De ce l-ai lua în considerare?

Aproape toți dezvoltatorii au sau au avut de-a face cu cerințe schimbătoare din partea clienților și au simțit nevoia de flexibilitate din partea sistemului de stocare a datelor în special când vine vorba de aplicații cu clienți multipli. În același timp, clienții simt deseori nevoia de câmpuri personalizate și cer flexibilitate. Dar ce e de făcut când unii clienți vor un câmp particular și alții vor patru, pentru aceeași funcționalitate? Sunt sigur că majoritatea ați văzut coloane precum customField1, customField2, customField3, anotherCustomField, ș.a.m.d. Acestea pot fi evitate folosind un tablou (array), dar ce facem când avem de stocat perechi? Sau triplete? Dacă câmpul particular are atât o etichetă cât și o valoare?

Sau chiar o dată asociată? Lucrurile devin mai complicate.

O altă problemă generală o reprezintă tratarea numelor. Există o listă de 40 de neadevăruri despre nume1, și doar ca să vă 1

Patrick McKenzie, Falsehoods Programmers Believe

www.todaysoftmag.ro | nr. 25/Iulie, 2014

21

programare Suportul JSON în PostgreSQL faceți o idee, am enumerat câteva pe care dezvoltatorii în general omit să le ia în calcul: • numele oamenilor pot conține numere; • oamenii pot avea un număr nedefinit de nume; • oamenii pot să nu aibă un prenume sau nume de familie; • oamenii pot avea mai mult de un nume canonic complet; • numele nu sunt neapărat în ASCII și nu sunt neapărat scrise într-un singur set de caractere; • oamenii pot să nu aibă nume.

este dependentă de aplicație și de clienții țintă ai acesteia, dar reprezentarea de mai sus oferă multă flexibilitate în comparație cu modul clasic de stocare a numelor din cadrul bazelor de date relaționale. Având rar nevoie de accesarea tuturor numelor, putem vedea utilitatea acestui tip de reprezentare. De ce am crea o coloană pentru numele mamei când avem rareori nevoie de el? De ce s-ar crea o coloană pentru poreclă sau nume de alint când unele entități ar putea avea mai mult de unul singur? Aceeași logică poate fi aplicată și celorlalte nume.

Desigur, probabil nu avem de a face cu multe din aceste cazuri, dar nu poți fi niciodată sigur că sistemul nu va trebui pe viitor să suporte nume chinezești. Un mod tradițional de a stoca nume este o combinație de prenume, nume de familie și eventual al doilea prenume care este opțional. Însă dacă o persoană nu are prenume sau nume de familie, această implementare devine eronată.

O posibilă cale de a rezolva această problemă este prin folosirea unui JSON:

Cu toate că lista completă de funcții și operatori poate fi găsită în documentația celor de la Postgres, este important de menționat că un obiect JSON e accesat folosind operatorul ”->” (poate fi returnat și ca text folosind operatorul ”->>”). De exemplu, pentru o coloană nume, accesarea numelui de familie s-ar face folosind: names->>’last_name’. Operatorul prezentat anterior poate fi folosit și pentru accesarea unui element aflat la o anumită poziție într-un tablou: (names->’nicknames’)->0 ar întoarce primul obiect din tabloul nicknames din cadrul coloanei.

Pe lângă operatori, începând cu versiunea 9.3 au fost adăugate și multiple funcții, pentru a ajuta dezvoltatorii în folosirea acestui tip de coloană, precum funcții pentru extragerea obiectelor dintr-un tablou de JSON, pentru transformarea unui rând într-un obiect JSON, pentru expandarea unui JSON într-un set de perechi cheievaloare sau pentru conversia oricărui element într-un obiect JSON.

{

“first_name” : “Ronaldo”, “mother_name”: ”de Assis”, “last_name” : “Moreira”, “nicknames” :[“Ronaldinho”,

“Gaúcho”] }

Implementarea de mai sus poate adăuga muncă în plus prin schimbarea câmpului de full_name de fiecare dată când unul din restul câmpurilor este schimbat, dar acesta este doar un exemplu. În general, soluția

Funcții și Operatori

About Names, Kalzumeus Blog, Iunie 2010

Avantajele tipului de coloană JSON

Primul avantaj ale acestui tip de coloană este caracterul de format ”open standard”, fiind independent de limbaj. În al doilea rând, facilitează tratarea cerințelor schimbătoare ale clienților prin scalabilitate și flexibilitate. Devine folositor când e nevoie de stocarea grafurilor de obiecte multi-nivel, deoarece oferă performanță ridicată și codul în sine este mai ușor de scris și de menținut decât în implementările obișnuite de grafe. Coloana JSON nu ocupă mult spațiu (e stocată ca și text) și permite stocarea de până la 1 GB de date într-o singură coloană. În plus, previne SQL injection în mod implicit, deoarece obiectele JSON sunt validate înainte de a fi persistate.

Cheile străine pot fi evitate prin denormalizarea datelor și câmpurile din cadrul interogărilor complexe pot fi accesate fără să fie nevoie de join cu alte tabele (posibil mari), oferind astfel un comportament similar cu NoSQL-uri într-un sistem de baze de date relațional.

Se poate dovedi a fi un plus în aplicațiile web, facilitând transportul și conversia datelor de pe client către controller-e, și apoi către nivelul de acces la date, stocând obiectele JSON venite dinspre client.

Aceste tipuri de date pot fi indexate, iar în plus indecși pot fi creați în cadrul obiectelor JSON (de exemplu, pentru tablouri din cadrul unui JSON). Indecșii curenți suportați atât de hstore cât și de coloanele JSON sunt aproape la fel de performanți ca și cei ai tipurilor de date standard. Dar se lucrează la noua generație de indecși GIN2.

2

Alexander Korotkov, Oleg Bartunov, Next

Generation of GIN, PostgreSQL Conference Europe 2013, Dublin

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

22

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

Product Development

Product Support

TODAY SOFTWARE MAGAZINE Aceștia au fost deja implementați pentru hstore în versiunea în curs de dezvoltare 9.4. Comparațiile de performanță cu MongoDB arată că deși scanarea secvențială este aproape la fel la nivel de performanță, scanarea de indecși este mai rapidă decât în Mongo.

Acești indecși vor fi cel mai probabil aplicați și tipului de date JSON începând cu versiunea 9.4.

Dezavantaje

Cel mai mare dezavantaj al tipului de date JSON este faptul că nu e portabil, fiind momentan suportat doar în PostgreSQL. Alte dezavantaje includ imposibilitatea de a adăuga chei străine și sintaxa ciudată, mai puțin lizibilă decât în cazul interogărilor obișnuite. În plus, interogările care sunt simple pe tipuri de date comune devin complicate când se folosește tipul de date JSON, în special când avem de-a face cu tablouri de obiecte. Pentru a exemplifica acest aspect, considerați o tabelă de utilizatori users care stochează numerele de telefon ca și un tablou de obiecte JSON, precum este prezentat în Figura 1. Cu toate că acest tip de configurare arată mai bine decât crearea de coloane pentru fiecare tip de număr, precum home_number, work_number ș.a.m.d., interogarea tabelei pentru a aduce numerele de telefon de tip primary de exemplu este destul de complicată.Rezultatul interogării este afișat în Figura 2:

Concluzii

A opta doar pentru un sistem de baze de date relațional sau pentru unul NoSQL nu reprezintă întotdeauna o soluție viabilă.

Cu toate că se fac pași pentru a ușura integrarea acestor două tipuri de baze de date, cel puțin pentru moment acest lucru poate să se dovedească a fi o prea mare bătaie de cap.

PostgreSQL oferă o soluție de ”compromis” prin suportul pentru coloane hstore care imită mediile de stocare cheie-valoare și pentru coloane de tip JSON, care permit stocarea de obiecte și tablouri JSON. În plus, oferă operatori și funcții pentru a facilita manipularea datelor, suportând în același timp și indecși atât pe date JSON cât și pe câmpuri din interiorul lor.

Dacă această soluție este sau nu optimă este o întrebare subiectivă, dependentă de sistem și de cerințele pe care acesta trebuie să le îndeplinească. Ceea ce este important de ținut minte este că dezvoltatorul are la dispoziție puterea și complexitatea sistemului de baze de date relațional Postgres, indiferent dacă alege sau nu să folosească tipul de date JSON.

SELECT users.id, phone->>’number’ AS number FROM users INNER JOIN ( SELECT id, json_array_elements(phones) AS phone FROM users WHERE id=users.id ) phones ON phones.id = users.id WHERE phone->>’type’=’primary’

Figura 1 - Numere de telefon stocate ca tablou de obiecte JSON, fiecare având un tip și un număr.

Figura 2 - Numerele de tip ”primary” returnate de interogare

În general, nu putem fi siguri că numărul de telefon de tip primary se află pe prima poziție a tabloului, acest lucru fiind subiectiv și dependent de sistem. Cu toate acestea, impunerea unor astfel de constrângeri pot duce la interogări simplificate, având operatorul ”->” pentru a accesa direct elementul de pe poziția n a unui tablou.

De asemenea, important de notat este că exemplul precedent prezintă un caz simplu de stocare de numere de telefon. Interogările devin cu atât mai complicate cu cât datele stocate în tablourile JSON sunt mai complexe, în special când apare nevoia de a face join acestor date din cadrul tabloului cu alte tabele.

www.todaysoftmag.ro | nr. 25/Iulie, 2014

23

programare

testare

Du-te (GO) și găsește instrumentul

D

e când am început să lucrez în industria IT, am avut multe roluri diferite, de la dezvoltare software până la suport rețea și suport tehnic computer.

Marius Ciotlos

marius.ciotlos@betfair.com Delivery Manager @ Betfair

După o perioadă destul de îndelungată de muncă în această industrie, am constatat că puține instrumente sunt cu adevărat inovatoare. De asemnea, multe dintre instrumentele existente sunt se deosebesc între ele prin puține nuanțe sau sunt atât de specifice în sarcina lor încât depinde de tine cum îți formezi procesul de lucru cu ele. În rândurile următoare, voi atrage atenția asupra unui instrument care se numește GO și este dezvoltat de ThoughtWorks. Este dificil de găsit din cauza numelui simplu, elegant, aceasta pe lângă dezavantajul că limbajul de programare GO are același nume.

Ce este acest instrument?

Dar destul cu introducerea; să trecem la detaliile din spatele acestui instrument.

GO a fost conceput drept un instrument cu care să poți face „Livrare continuă”. Aș dori să evit atingerea acestui subiect, din cauză că există atât de multe lucrări pe această temă și fiecare autor tehnic imprimă terminologiei propria sa particularitate.Este un instrument foarte personalizabil pentru fluxul de lucru. Și mai presus de toate, este acum sursă deschisă (open source).

Am aflat de GO de abia acum o lună, într-un seminar din cadrul companiei mele. Unii ar putea crede că ni s-au inoculat informații subiective de către vreun furnizor plătit de către ThoughtWorks. Este departe de adevăr. GO era în acel moment doar numele unui instrument obscur (pentru mine). Am fost sceptic în privința instrumentelor complexe „universale”, căci am avut partea mea de dezamăgiri cu unele dintre ele, care întotdeauna se promovează

24

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

drept făcând multe, dar sfârșesc de multe ori prin a te încurca.

Structura lui GO: Privire de ansamblu de la nivel înalt, privind instrumentul din spațiu GO este un Server →Arhitectură de tip agent, unde ai serverul principal cu UI și mulți agenți care se conectează cu acest Server și primesc comenzi. Agenții pot rula pe Windows, Linux și Mac OSX, și depinde de tine cât de mulți vrei (poți chiar să rulezi mai mulți agenți pe un aparat).

Pe server ai: • Task-uri care se derulează succesiv.

• Job-uri care se derulează în paralel și conțin task-uri.

• Etape care se derulează succesiv și conțin job-uri.

• Pipeline-uri care rulează în paralel sau secvențial în funcție de modul în care sunt definite, care conțin Etape.

Agenții tăi vor avea etichete (tags) care specifică ceea ce pot face (de exemplu, să ruleze bash, să ruleze python să ruleze GIT, să ruleze SSH), iar operațiile tale (jobs) au și ele eticheta pentru a specifica resursele de care ai nevoie pentru ca acea lucrare să se deruleze. Serverul doar potrivește agentul potrivit pentru job-ul potrivit!

Ce poți face cu GO?

Noi îl utilizăm pentru punerea în funcțiune a serverelor (server deployments), rularea testelor și a automatizării de infrastructură. Totuși modul în care este construit, vă permite să-l utilizați pentru multe alte scopuri. Cum funcționează:

TODAY SOFTWARE MAGAZINE • Găsești niște comenzi (instrumente sau scrieri sau pur și simplu comenzi de pe consolă) pe care le rulezi după un pattern repetitiv (le vom numi sarcini).

• Grupezi acele comenzi care pot fi rulate ca un unit, să spunem că creezi un utilizator în AD, îi creezi e-mailul, repartizezi utilizatorul într-un grup (pe aceasta o vom numi o lucrare (job)).

• Grupezi împreună lucrări (jobs) care pot să se deruleze în paralel ca și după ce ai utilizatorul în AD, creând diverse permisiuni bazate pe grupul AD în multe instrumente diferite () • Grupezi etapele (stages) într-o secvență, astfel încât să poți face grupuri de comenzi înlănțuite și complexe. Ai putea avea o primă etapă care să facă toate cele de mai sus, iar o a doua etapă care să pregătească instalarea unui laptop sau a unui desktop în paralel (vom numi asta un produs în curs de dezvoltare) • Poți avea chiar produse în curs de dezvoltare legate împreună sau care să se deruleze în paralel.

utilizare într-o Etapă diferită sau la un Produs în dezvoltare diferit. Imaginați-vă un script care generează un binar temporar de care ai nevoie mai încolo în cursul dezvoltării produsului. Ai putea utiliza artefacte pentru a nu mai avea nevoie de un repo extern pentru ceva care este atât de volatil. De asemenea, Artefactele Test sunt felul în care GO poate interpreta rezultatele testelor pentru o Etapă.

Pe baza artefactelor poți avea niște tab-uri speciale care să încarce HTML-ul pe care l-ai generat cu o comandă, pentru a-l vedea direct în instrument.

Configurația XML

Întreaga configurație pentru server stă într-o versiune de fișier XML. Dacă interfața pentru utilizator nu este suficientă, poți oricând să editezi manual. Această funcție este disponibilă numai pentru Super Admin deoarece este foarte ușor și posibil să încurci lucrurile de acolo. Configurația XML stă într-o zonă Principalele caracteristici care îți permit să atingi acest nivel de text care are multă validare, dar un lucru pe care probabil îl ridicat de flexibilitate: vei face în timp ce îți definești fluxul de lucru este să redenumești anumite Produse care sunt în dezvoltare, iar acest lucru poate să Comenzi personalizate îți cauzeze probleme.

Comenzile personalizate (custom) sunt o listă de comenzi pe care le poți folosi pentru a face lucruri într-o sarcină. Ce e frumos la GO este că poți rula literalmente orice utilizând un terminal Bibliografie (Linux, Windows, Mac OSX). Dacă comenzile de bază nu sunt Forum public: https://groups.google.com/forum/#!forum/ suficiente pentru tine, este posibil să îți creezi singur comenzi mai go-cd complexe, utilizând script-uri (gândește-te la PowerShell, Python, Documentație: https://go.app.betfair/go/help/index.html etc.). Comenzile personalizate îți permit de asemenea să urmărești Pagină comunitate mai veche: http://support.thoughtworks. statutul unei comenzi care tocmai a rulat. Noi am folosit script-uri com/categories/20002778-Go-Community-Support Python pentru a avea și mai multă flexibilitate în procesarea rezulWebinar introductiv: http://www.go.cd/2014/03/10/go-webitatului (output-ul) și trimiterea înapoi a „codului status” astfel nar-recording.html încât să știi dacă o sarcină (care rulează comanda) a eșuat sau nu.

Artefacte – Construiește și testează

Artefactele sunt al doilea concept grozav în GO, unde o lucrare (care are sarcini multiple cu comenzi personalizate) poate genera un rezultat și tu ai putea să „îi spui” lui GO că acesta este un artefact. Chiar dacă ai doar două tipuri de artefacte permise de GO, Artefactul Build este destul de generic pentru a fi orice.

Cu artefactele poți aduce în instrument mai multe informații de la output (rezultat), dar poți de asemenea să le furnizezi pentru

www.todaysoftmag.ro | nr. 25/Iulie, 2014

25

management

Scrum cu Programare Extremă

M

anagementul unei echipe de dezvoltare software este o meserie pe care trecerea timpului nu a transformat-o, așa cum se întâmplă de obicei, într-una mai ușoară. De la publicarea lucrării Agile Manifesto, în 2001, multe companii și echipe care dezvoltă produse soft au practicat și testat metodele și tehnicile Agile cu succes.

Alina Chereches

alina.cherecheș@yardi.com Senior Software Developer & Scrum Master @ Yardi

Cunoscută și sub numele de Extreme Project Management (XPM), această abordare a managementului de proiect are ca scop îmbunătățirea răspunsului produsului la schimbarea specificațiilor clientului. Așadar, în timp ce echipa Agile se concentrează pe creșterea nivelului de adaptabilitate, se pierde din importanța acordată în mod normal, predictibilității.

Lipsa de predictibilitate a echipei este într-adevăr dezavantajul metodologiei Agile. Acest articol vorbește despre modul în care metodele Agile sunt aplicate în XPM și prezintă câteva exemple, sperăm noi utile, legate de modul în care putem traduce teoria Agile în proiecte de succes pentru echipă și profit pentru organizație.

Echipa Agile

Întâi de toate, XPM nu se potrivește oricărei echipe. După cum se specifică în Agile Manifesto, vorbim despre echipe care se organizează singure, formate dintr-un număr mic de dezvoltatori seniori, care lucrează pe proiecte ale căror specificații se schimbă frecvent. De aceea, am avea nevoie de o cultură în echipă bazată pe un răspuns pozitiv la schimbări - o echipă în care există comunicare, colaborare și în care rolurile se pot schimba în orice moment.

Rolurile într-o echipă Agile sunt de asemenea foarte importante. O echipă Agile nu are nevoie de managerul clasic, membrii acesteia sunt direct resposabili de munca lor. Scrum Master este managerul echipei, iar rolul său este ca acela al unui antrenor.

26

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

El are abilități de organizare, obține resurse pentru echipă și conduce echipa spre realizarea obiectivelor sale. Alte roluri în echipa Agile sunt: Domain Expert, Technical Lead, Independent Tester, Product Owner și alți Stakeholders. Așa cum vom vedea mai târziu, fiecare dintre acești membri se concentrează pe diferite aspecte ale proiectului în care sunt toți implicați și aceasta este adevărata provocare a echipei Agile.

Aspectele pe care metodele Agile își propun să le dezvolte într-o echipă, le-am structurat în trei categorii: comunicare, eficiență și calitate.

După cum am menționat mai sus, XPM se bazează pe o comunicare constantă și productivă. Prin intermediul procedurilor Agile un astfel de mediu de lucru poate fi construit pentru a asigura evoluția și optimizarea proceselor. Iată care sunt instrumentele Agile: ședința de planificare (Iteration Planning), Poker Planning, sistemul de urmărire a vitezei de lucru a echipei (Velocity Tracking), ședințele de retrospec tivă.

Eficiența echipei este asigurată de ședințele zilnice de Scrum (stand-ups) și obținerea de feed-back în timp scurt, ceea ce conduce la un ciclu de lucru (Sprint) foarte adaptabil. Echipa Agile se concentrează, în același timp, pe calitate, prin procesul de integrare continuă, pair-programming, procesele de testare, refactorizare și review al codului, D3 (Design Driven Development) și TDD (Test Driven Development).

management

TODAY SOFTWARE MAGAZINE

Dimensiunile Agile

Metodologia Agile ne învață multe lucruri și abordează dezvoltarea de produs din diferite puncte de vedere. Cred că una dintre cele mai importante dimensiuni ar fi Procesul Agile Nedefinit (the Agile Undefined Process) - principiul conform căruia un proces sau proiect Agile nu este în nici un moment pe deplin definit. De asemenea, se referă la conceptul de Agile Modeling: documentare, arhitectură și cerințe care se pot schimba în orice moment și care trebuie să fie întotdeauna clare și transparente. Este principiul care pune accentul pe diferența dintre Development Release și Production Release, sau diferența dintre viteza de lucru a echipei și îndeplinirea angajamentelor privind lansarea produsului la client.

Așa cum am menționat mai sus, Agile nu vizează proiecte care necesită previziuni. Nu se focalizează pe proceduri sau artefacte, ci pe metodologii pentru oameni. În terminologia Agile acestea sunt numite Crystal Methods: lansarea frecventă de cod utilizabil pentru client, îmbunătățirea prin re-evaluare, testarea prin intermediul utilizatorilor experți, teste automate.

O altă dimensiune Agile este Feature Driven Development. Aceasta prezintă cele mai bune practici din perspectiva înțelegerii businessului și a clientului, așa numitul Domain Driven Development (D3), lansări regulate și transparență în ceea ce privește progresul proiectului și rezultatele sale. Și cu aceste practici ne apropiem tot mai mult de cealaltă parte a Agile: managemenul resurselor și livrarea la timp. În Agile, managementul timpului, al

calității și al costului se numește Dynamic System Development Method. Se referă la concentrarea pe necesitățile businessului, dezvoltarea și lansarea rapidă, fără a se compromite însă calitatea, la demonstrarea controlului prin dezvoltarea graduală și la comunicarea constantă. Această dimensiune introduce termenul de prioritizare (the musts, the shoulds, the coulds and the won’t haves).

Chiar dacă voi prezenta utilizarea Scrum în XPM, există următoarele principii din metodologia Kanban, care vin să completeze foarte bine ideea pe care încerc să o conturez privind livrarea la timp și controlul resurselor. Și aceste principii ar putea fi rezumate prin fraza: “Oprește-te să începi și începe să termini” (“Stop starting and start finishing”). Cu alte cuvinte, echipa ar trebui să convină să urmărească schimbarea progresivă și să respecte

procesul curent și rolurile care s-au stabilit la începutul proiectului.

A m s pu s d e j a c ă Ag i l e nu s e concentrează pe proceduri, ci pe oameni și metode pentru oameni. Există această ultimă dimensiune Agile care se referă la ce anume se dezvoltă, mai degrabă decât la cum se dezvoltă. Este vorba de teoria Agile cunoscută sub numele de Lean Software Development - politici și proceduri scrise în scopul de a controla consumul de resurse.

Unele dintre aceste politici sunt: ​​eliminarea pierderilor, luarea unor decizii cât mai târziu posibil, livrarea cât mai rapidă posibil, asigurarea unei viziuni de ansamblu și demonstrarea integrității.

Provocarea

Ne vom întoarce acum la mențiunea mea cum că membri diferiți ai echipei Agile au interese diferite atunci când participă la

Objective C

jobs-cluj@yardi.com Yardi Romania

www.todaysoftmag.ro | nr. 25/Iulie, 2014

27

management Scrum cu Programare Extremă dezvoltarea unui proiect. Desigur, cu toții își fac treaba în cel mai bun mod posibil și înțeleg și respectă Scopul Proiectului Agile (ce software trebuie construit și livrat). Dar, în timp ce membrii echipei sunt interesați de metodele de inginerie și de practicile Extreme Programming (XP), precum și de scrierea de cod de calitate, Scrum Master se axează pe adaptarea la cerințelor de sistem imprevizibile, în același timp fiind capabil să măsoare viteza de lucru a echipei. Pe de altă parte, Product Owner-ul nu este interesat însă nici de viteza echipei, nici de calitatea codului. El ar dori ca echipa să fie în măsură să facă estimări exacte privind termenul de finalizare a proiectelor. Cu alte cuvinte, Product Owner-ul, precum și alți Stakeholders, ar dori ca echipa să fie ... previzibilă.

Pentru a putea prezice lansarea produsului, o echipă trebuie să fie capabilă să estimeze, în primul rând, etapele de dezvoltare. Pentru aceasta avem instrumentele Scrum pentru managementul de proiect: Poker Planning, Velocity Tracking și Sprint Retrospectives.

Vă voi prezenta în continuare câteva exemple concrete despre cum Scrum și XP pot conlucra pentru a ne ajuta să atingem scopul predictibilității.

Scrum și XP - Cum facem să funcționeze?

De obicei, veți găsi mai multe articole care vorbesc despre diferențele dintre Scrum și XP. Deși ambele se concentrează pe producerea de software funcțional în cel mai scurt timp posibil și pun accentul pe importanța comunicării între echipe, ele sunt descrise mai degrabă ca abordări opuse în dezvoltarea de produse soft.

Acum că am văzut care sunt diferențele dintre Scrum și XP, ne vom axa pe instrumentele care îmbină avantajele celor două metodologii.

Documentare și Testare

Water - Cerințe și specificații (toate documentele necesare, actualizate) Scrum - Proiectare și implementare (practici de inginerie) Fall - Verificare, întreținere (testare automată, lansare și livrare) XPM se referă la crearea de rezultate de calitate, funcționale, care furnizează cea mai mare valoare financiară posibilă, în același timp reducând riscul de eșec. Prin adoptarea Water-Scrum-Fall, se face în mod subtil trecerea de la modelul Agile, axat pe echipă, la modelul Agile axat pe nevoile de business. Prin combinarea beneficiilor aduse de metodologiile de dezvoltare Agile și Waterfall, se preia controlul asupra felului în care echipa interacționează cu alte părți ale organizației, reducând treptat consumul de resurse și crescând predictibilitatea în ceea ce privește estimările și livrarea.

Măsurarea vitezei În Scrum, viteza este reprezentată de cât de mult poate dezvolta o echipă în cadrul unei iterații. Acest lucru poate fi estimat analizând iterații anterioare, presupunând că membrii echipei și durata sprintului rămân aceleași. Rapoartele de viteză sunt folosite la ședințele de planificare, cu scopul de a defini următorul sprint.

Odată stabilită, viteza va fi folosit pentru planificarea livrărilor.

Grafice de măsurarea a vitezei unei echipe: • Burndown Chart • Velocity Tracking Cu XP, sprint-urile sunt flexibile și noi task-uri pot fi integrate pe măsură ce apar, în timpul unei iterații. Această abordare îngreunează procesul de măsurare a vitezei și face aproape imposibilă folosirea unui Burndown Chart.

Atunci când un nou task este adăugat în timpul unui sprint, un altul ar trebui să se întoarcă în backlog. În acest fel, numărul de puncte (story points) stabilite pentru un sprint rămâne așa cum a fost plănuit inițial.

Dacă acest lucru nu se întâmplă și taskuri noi sunt adăugate la volumul de lucru existent, echipa nu va putea să completeze sprint-ul conform planului și, prin urmare, nu-și va putea respecta angajamentele.

Ecuația Velocity Tracking:

O echipă Scrum cuprinde toate persoanele necesare în dezvoltarea de software funcțional. Acest lucru înseamnă dezvoltatori, testeri și analiști care lucrează împreună pentru un obiectiv comun.

Chiar dacă am acceptat principiile Agile de dezvoltare, managementul de livrare și planificarea proiectului se fac în continuare în concordanță cu modelul Waterfall. (sp) + Added (sp) Realitatea Agile în cadrul organizațiilor a Planned - Removed (sp) = Assigned (sp) deviat de la ideile inițiale descrise în Agile = Burned (sp) Manifesto și a devenit mai mult o abordare hibridă a managementului unui ciclu de dezvoltare, numită Water-Scrum-Fall.

28

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

Pair-programming și Code reviewing

Un principiu important al XP este proprietatea colectivă asupra codului: e important să vă asigurați că nici o bucată de cod nu ajunge în producție fără a fi revizuită de o a doua persoană. Scopul acestei abordări nu este numai de a livra cod de calitate, cu mai puține bug-uri, ci și de a face informația și cunoștințele să circule între membrii echipei. Totodată, un alt scop este acela de a da o șansă developerilor să preia ideile bune de la colegii lor.

Pentru a vă asigura că toate costurile de revizuire a codului nu depășesc beneficiile, vă oferim o idee privind ce ar putea funcționa și când.

S-ar putea să cunoașteți care sunt etapele unei echipe Agile: Forming, Storming, Norming și Performing. În funcție de etapa în care se află echipa în momentul respectiv, anumite abordări pentru revizuirea de cod sunt mai potrivite decât altele. În etapa de Forming, este indicat ca membrii echipei să formeze perechi și să lucreze împreună. În felul acesta, cei cu mai puțină experiență pot lucra cu senior developers și membrii echipei care au mai multe cunoștințe despre proiect pot comunica din informații și celorlalți. În felul acesta, echipa este mai productivă și mai eficientă decât dacă fiecare membru ar lucra pe cont propriu.

Când echipa se află în faza Norming, sesiunile de revizuire a codului sunt mai eficiente dacă participă întreaga echipă.

Acesta este momentul în care echipa își stabilește standardele și principiile pentru codare și când se iau multe decizii importante. În cele din urmă, dacă echipa este matură și în faza de Performing, lucrul individual este mult mai eficient decât dacă mai multe persoane lucrează pe aceeași bucată de cod. Peer-reviewing este tipul de verificare cel mai potrivit în acest caz.

Practica bate teoria!

Ultima, dar și cea mai importantă regulă în XPM este să ne asigurăm că punem în practică cât mai multe dintre cunoștințele pe care le avem, cât mai repede posibil. Fiecare ședință a echipei ar trebui să se finalizeze cu un set de concluzii și propuneri de acțiuni și nicio retrospectivă nu ar trebui să stabilească noi scopuri pentru echipă atâta timp cât cele anterioare nu au fost îndeplinite. Trebuie să menținem echipa responsabilă, concentrată și conștientă de propriile responsabilități.

arhitectură

TODAY SOFTWARE MAGAZINE

Principii de design Agile

P

rogramarea agile se bazează pe dezvoltarea produsului software în blocuri mici și incrementale, în care cerințele clienților și soluțiile oferite de programatori evoluează simultan.

Programarea agile are la bază o strânsă legătură între calitatea finală a produsului și livrările frecvente ale funcționalităților dezvoltate incremental. Cu cât se realizează mai multe livrări, cu atât calitatea produsului final va fi mai ridicată. Într-un proces de implementare agile, cerințele de modificare sunt privite ca un lucru pozitiv, indiferent de faza de dezvoltare în care se află proiectul. Aceasta deoarece cerințele de modificare evidențiază faptul că echipa a înțeles ceea ce este necesar pentru ca produsul software să satisfacă necesitățile pieței.

Din acest motiv este necesar ca o echipă agile să mențină structura codului cât mai flexibilă, astfel încât noile cerințe ale clienților să aibă un impact cât mai redus asupra arhitecturii existente. Aceasta nu înseamnă însă că echipa va face un efort suplimentar luând in considerare viitoarele cerințe și necesități ale clienților sau că va investi mai mult timp pentru a implementa o infrastructură care să suporte posibile cerințe necesare în viitor. Dar evidențiază faptul că accentul este pus de dezvoltarea produsului curent cât mai eficient. În acest acest scop, vom investiga câteva dintre principiile de software design care se impun aplicate de la o iterație la alta de către un programator agile, pentru a menține cât mai curat și flexibil posibil codul și designul proiectului. Principiile au fost propuse de către Robert Martin în lucrarea Agile Software Development: Principles, Patterns, and Practices [1].

vor implica modificări asupra celorlalte responsabilități ale clasei. Acesta corelație conduce către un design fragil.

Fragilitatea însemnă că o modificare adusă sistemului produce o ruptură în design, în locuri care nu au nici o legătură conceptuală cu partea care a fost modificată.

În acest exemplu cele două responsabilități sunt separate, astfel încât clasa care le utilizează - Phone, nu trebuie să le cupleze pe amândouă. Schimbările asupra conexiunii nu vor influența metodele responsabile cu transmisia datelor.

Pe de altă parte în cazul în care cele două responsabilități nu prezintă motive Exemplu: de modificare în timp, nu este neceSă presupunem că aveam o clasă sară nici separarea lor. Cu alte cuvinte care încapsulează conceptul de tele- responsabilitățile unei clase trebuie sepaf o n ș i f u n c ț i o n a l i t ăț i l e a f e r e nt e . rate, numai dacă există șanse reale ca responsabilitățile să producă modificări, class Phone influențându-se reciproc. { public void Dial(const string& phoneNumber);

Concluzii

Principiul singurei responsabilități este unul dintre cele mai simple și cu toate acestea unul dintre cele mai dificil de aplicat. public Receive(const string& Identificarea și separarea responsabilităților message); este unul dintre aspectele fundamentale ale }; designului software. În principiile de agile Acesta clasă ar putea fi considerată software design pe care le vom analiza în rezonabilă. Toate cele patru metode defi- continuare, vom vedea că vom reveni, întrnite reprezintă funcționalități referitoare la un fel sau altul, asupra acestui principiu. conceptul de telefon. Și totuși această clasă are două responsabilități. Metodele Dial si Principiul Deschis-Închis (Open Hangup sunt responsabile pentru realiza- Closed Principle: OCP) rea conexiunii, în timp ce metodele Send și Receive sunt responsabile pentru transEntitățile software (clase, module, miterea datelor. funcții, etc.) trebuie să fie deschise pentru În cazul în care signatura metodelor extensii, dar închise pentru modificări. responsabile pentru realizarea conexiunii Atunci când o singură modificare ar fi supuse schimbărilor, acest design ar fi asupra unui modul software rezultă rigid, deoarece toate clasele care apelează în necesitatea de a modifica o serie de metodele Dial și Hangup ar trebui recom- alte module, atunci designul suferă de Principiul Singurei Responsabilițăti pilate. Pentru a evita această situație este rigiditate. Principiul OCP susține refacto(Single Responsability Principle : SRP) necesar un re-design care să separe cele rizarea designului astfel încât modificări două responsabilități. ulterioare de același tip, nu vor mai proO clasă trebuie să aibă un singur motiv duce modificări asupra codului existent pentru a fi modificată. , care deja funcționează, în schimb va În contextul SRP, responsabilitatea necesita doar adăugarea de noi module. poate fi definită ca “un motiv pentru modificare”. Atunci când cerințele proiectului se Un modul software care respectă princimodifică, modificările vor fi vizibile prin piul Deschis-Închis are două caracteristici modificarea responsabilității claselor. Dacă principale: o clasă are mai multe responsabilități, atunci • “ D e s c h i s p e n t r u e x t e n s i i .” va avea mai multe motive de schimbare.

Acesta înseamnă că acel comportament Având mai multe responsabilități cuplate, Figura 1 al codului poate fi extins. Atunci când modificări asupra unei responsabilități cerințele proiectului se modifică, codul public void Hangup(); public void Send(const string& message);

www.todaysoftmag.ro | nr. 25/Iulie, 2014

29

arhitectură Principii de design Agile poate fi extins cu implementarea noilor cerințe, adică se poate modifica comportamentul modulului deja existent.

• “Închis pentr u modific ări.”

Implementarea noilor cerințe nu necesită modificări asupra codului deja existent.

Abstractizarea este metoda care permite modificarea comportamentului unui modul software, fără a modifica și codul deja existent al acestuia. În C++, Java sau oricare alt limbaj orientat obiect, este posibil să se creeze o abstractizare care oferă o interfață fixă și un număr nelimitat de implementări, adică de comportamente diferite [2]. În Fig. 2 este prezentată o diagramă de clase care nu respectă principiul deschisînchis. Atât clasa Client cât și clasa Server sunt clase concrete. Clasa Client folosește clasa Server. Dacă mai târziu se dorește ca această clasă Client să folosească un alt tip de server, va fi nevoie să se modifice clasa Client astfel încât să utilizeze noul server.

Figure 2 Exemplu care nu respecta principiul OCP 1

În Fig. 3 se prezintă același design ca și în Fig. 2, dar de această dată principiul deschis-închis este respectat. În acest caz a fost introdusă clasa abstractă AbstractServer, iar clasa Client folosește această abstractizare. Totuși clasa Client va folosi de fapt clasa Server care implementează clasa ClientInterface. Dacă în viitor se dorește folosirea unui alt tip de server tot ce trebuie făcut va fi să se implementeze o nouă clasă derivată din clasa ClientInterface, dar de această dată clientul nu mai trebuie modificat.

Figura 3 Exemplu care respectă principiul OCP 2

Un aspect particular în acest exemplu, este modul în care am denumit clasa abstractă ClientInterface și nu ServerInterface, spre exemplu. Motivul pentru această alegere este faptul că clasele abstracte sunt mai apropiate de clasele client pe care le folosesc, decât de clasele concrete pe care le implementează.

Principiul Deschis -Închis este utilizat și

30

în design pattern-urile Strategy și Plugin [3].

Spre exemplu, Fig.4 prezintă designul corespunzător care respectă principiul deschis-închis.

element central din programarea orientată obiect. Conformarea la acest principiu conduce la cele mai mari beneficii ale programării orientate obiect, acestea fiind flexibilitatea, reutilizarea și mentenanța codului.

Principiu de substituire Liskov (LSP)

Figura 4

Clasa Sort_Object efectuează o operație de sortare a obiectelor, operație care poate fi descrisă în interfața abstractă Sort_Object_Interface. Clasele derivate din clasa abstractă Sort_Object_Interface sunt obligate să implementeze metoda Sort_ Function(), dar au în același timp libertatea de a oferi orice implementare doresc pentru această interfață. Astfel comportamentul specificat de interfața metodei void Sort_ Function(), poate fi extins și modificat prin crearea de noi subtipuri ale clasei abstracte Sort_Object_Interface. În definiția clasei Sort_Object vom avea următoarele metode: void Sort_Object::Sort_Function() { m_sort_algorithm>sortFunction(); } void Sort_Object::Set_Sort_ Algorithm(const Sort_Object_Interface* sort_algorithm) { std::cout << „Setting a new sorting algorithm...” << std::endl; m_sort_algorithm = sort_algorithm; }

Concluzii

Principalele mecanisme în spatele acestui principiu sunt abstractizarea și polimorfismul. Ori de câte ori codul trebuie modificat pentru implementarea unei noi funcționalități, trebuie să se ia în considerare și crearea unei abstracții care să furnizeze o interfață pentru comportamentul dorit și care să ofere în același timp posibilitatea de a adăuga în viitor noi comportamente pentru aceeași interfață. Desigur nu întotdeauna este necesară crearea unei abstractizări. Acestea metodă este utilă în general acolo unde apar modificări frecvente.

Conformarea la principiul deschis-închis este costisitoare. Aceasta necesită timp de dezvoltare și efort pentru a crea abstracțiile necesare. Aceste abstracții incrementează complexitatea designului software. În schimb, principiul deschis-inchis reprezintă din multe puncte de vedere un

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

Tipurile de bază trebuie să poată fi substituite de tipurile derivate. În limbaje precum C++ sau Java, mecanismul principal prin care se realizează abstractizarea și polimorfismul este moștenirea. Pentru a crea o ierarhie de moștenire corectă trebuie să ne asigurăm că clasele derivate, extind fără a înlocui funcționalitatea claselor de bază. Cu alte cuvinte, funcțiile care utilizează pointer-i sau referințe la clasele de bază trebuie să poată folosi instanțe ale claselor derivate fară să își dea seama de acest lucru. În caz contrar, noile clase pot produce efecte nedorite când sunt utilizate în entitațile programului deja existent. Importanța principiului LSP devine evidentă în momentul în care este incălcat.

Exemplu: Să presupunem că avem o clasă Shape, a cărei obiecte sunt deja folosite undeva în aplicație și care are o metoda SetSize, care proprietatea mSize ce poate fi folosită ca latură sau diametru, în funcție de figura reprezentată. class Shape { public: void SetSize(double size); void GetSize(double& size); private: double mSize; };

Mai târziu extindem aplicația și adăugăm clasele Square și Circle. Având în vedere faptul că moștenirea modelează o relație „este de tipul” ( IS_A relationship) noile clase Square si Circle, pot fi derivate din clasa Shape.

Figura 5

Să presupunem în continuare că obiectele Shape sunt returnate de o metodă factory, pe baza unor condiții stabilite la run time, astfel încât nu cunoaștem exact tipul

TODAY SOFTWARE MAGAZINE obiectului returnat. Dar știm că este Shape.

Obținem obiectul Shape, îi setăm proprietatea size de 10 unități și îi calculăm aria.

Pentru un obiect square aria va fi 100. void f(Shape& shape, float& area) { shape.SetSize(10); shape.GetArea(area); assert(area == 100); // Oups! // for circle area = 314.15927! }

În acest exemplu, atunci când funcția f, primește ca parametru r, o instanță a clasei Circle va avea un comportament greșit.

Deoarece, în funcția f, obiectele de tip Square nu pot substitui obiecte de tip Rectangle, principiul LSP este violat. Funcția f, este fragilă în raport cu ierarhia Square/Circle.

Design by Contract

Desigur că mulți programatori, se vor simți inconfortabil cu noțiunea de „comportament” care trebuie să fie „corect”. Cum am putea presupune ceea ce așteaptă utilizatorii/clienții claselor pe care le implementăm? În acest scop, ne vine în ajutor tehnica designului prin contract (design by contract - DBC). Contractul unei metode îl informează pe autorul unei clase client despre comportamentele pe care se poate baza cu siguranță. Contractul este specificat prin declararea precondițiilor și a postcondițiilor pentru fiecare metodă.

Precondițiile trebuie să fie adevarate pentru ca metoda să se execute. Iar în final, după execuția metodei, aceasta garantează că postcondițiile sunt adevărate.

Anumite limbaje, precum Eiffel oferă suport direct pentru precondiții și postcondiții.

Acestea trebuie doar declarate, iar în timpul rulării sunt verificate automat. În C++ sau Java, această funcționalitate lipsește.

Contractele pot fi în schimb specificate prin teste unitare (unit test). Prin testarea comportamentului unei clase, testele unitare clarifică comportamentul unei clase.

Programatorii care vor folosi clasele pentru care s-au implementat teste unitare, pot folosi aceste teste pentru a ști care este comportamentul pe care îl oferă claselor client.

Principiul Inversării Dependenței (Dependency Inversion Principle) A. Modulele de pe nivelurile ierarhice superioare nu trebuie să depindă de modulele de pe nivelurile ierarhice inferioare. Toate ar trebui să depindă doar de module abstracte.

B. Abstractizările nu trebuie să depindă de detalii. Detaliile trebuie să depindă de abstractizări.

Acest principiu enunță faptul că modulele de pe nivelul ierarhic superior trebuie să fie decuplate de cele de pe nivelurile ierarhice inferioare. Această decuplare se realizează prin introducerea unui nivel de abstractizare între clasele care formează nivelul ierarhic superior și cele care formează nivelurile ierarhice inferioare. În plus principiul spune și faptul că abstractizarea nu trebuie să depindă de detalii, ci detaliile trebuie să depindă de abstractizare.

Acest principiu este foarte important pentru reutilizarea componentelor software.

De asemenea, aplicarea corectă a acestui principiu face ca întreținerea codului să fie mult mai ușor de realizat. În Fig. 6 este prezentată o diagramă de clase organizată pe trei niveluri. Astfel clasa PolicyLayer reprezintă nivelul ierarhic superior, ea accesează funcționalitatea din clasa MechanismLayer aflată pe un nivel ierarhic inferior. La rândul ei, clasa MechanismLayer accesează funcționalitatea din clasa UtilityLayer care de asemenea se află pe un nivel ierarhic inferior. În concluzie, este evident faptul că în diagrama de clase prezentată nivelurile superioare depind de nivelurile inferioare. Acest lucru înseamnă că dacă apare o modificare la unul din nivelurile inferioare există șanse destul de mari ca modificarea să se propage în sus spre nivelurile ierarhice superioare. Ceea ce înseamnă că nivelurile superioare mai abstracte depind de nivelurile inferioare care sunt mai concrete.

Așadar se încalcă principiul inversării dependenței.

Concluzii

Principiul LSP este doar o extensie a principiului Deschis-Închis și înseamnă că, atunci când adăugăm o nouă clasă derivată într-o ierarhie de moștenire, trebuie să ne asigurăm că clasa nou adăugată extinde comportamentul clasei de bază, fară a-l modifica.

dependenței. Astfel, fiecărui nivel care accesează funcționalitatea dintr-un nivel ierarhic inferior i s-a adăugat o interfață care va fi implementată de nivelul ierarhic inferior. În acest fel interfața prin care cele două niveluri comunică este definită în nivelul ierarhic superior astfel încât dependența a fost inversată și anume nivelul ierarhic inferior depinde de nivelul ierarhic superior. Modificări făcute la nivelurile inferioare nu mai afectează nivelurile superioare ci invers. În concluzie, diagrama de clase din Fig. 7 respectă principiul inversării dependenței.

Figura 7

Concluzii

Programarea tradițională procedurală creează polițe de dependențe în care modulele ierarhice superioare depind de detaliile modulelor ierarhice inferioare . Acestă metodă de programare este ineficientă deoarece modificari ale detaliilor conduc către modificări și în modulele superioare.

Programarea orientată obiect inversează acest mecanism de dependență, astfel încât atat detaliile cât și nivelurile superioare depind de abstractizări, iar serviciile aparțin deseori clienților.

Indiferent de limbajul de programare folosit, dacă dependențele sunt inversate atunci designul codului este orientat obiect. Dacă dependențele nu sunt inversate, atunci designul este procedural.

Principiul dependenței inversate reprezintă mecanismul fundamental de nivel scăzut (low level) ce stă la baza multor beneficii oferite de programarea orientată obiect. Respectarea acestui principiu este fundamentală pentru crearea de module reutilizabile. Este de asemenea esențială pentru a scrie cod rezistent la modificari.

Atât timp cât abstracțiile și detaliile sunt izolate reciproc, codul este mult mai ușor de menținut.

Figura 6

În Fig. 7 este prezentată aceeași diagramă de clase ca și în Fig. 6, dar de această dată este respectat principiul inversării www.todaysoftmag.ro | nr. 25/Iulie, 2014

31

arhitectură Principii de design Agile

Principiul Segregării Interfeței (The Interface Segregation Principle) Clienții nu trebuie să depindă de interfețe pe care nu le folosesc.

Acest principiu pune în evidență faptul că atunci când se definește o interfață trebuie avut grija ca doar acele metode care sunt specifice clientului să fie puse în interfață. Dacă într-o interfață sunt adăugate metode care nu au ce căuta acolo, atunci clasele care implementează interfața vor trebui să implementeze și acele metode. Spre exemplu, dacă se consideră interfața Angajat care are metoda Mănâncă, atunci toate clasele care implementează această interfața vor trebui să implementeze și metoda Mănâncă. Ce se întâmplă însă dacă Angajatul este un robot?

Interfețele care conțin metode nespecifice se numesc interfețe poluate sau grase. În Fig. 8 este prezentată o diagramă de clase care conține: interfața TimerClient, interfața Door și clasa TimedDoor. Interfața TimerClient trebuie implementată de orice clasă care are nevoie să intercepteze evenimente generate de un Timer. Interfața Door trebuie să fie implementată de orice clasă care implementează o ușă. Având în vedere că a fost nevoie de modelarea unei uși care se închide automat după un anumit interval de timp în Fig. 3.7 este prezentată o soluție în care a fost introdusă clasa TimedDoor derivată din interfața Door, iar pentru a dispune și de funcționalitatea din TimerClient a fost modificată interfața Door astfel încât să moșteneascaă interfața TimerClient. Aceasta soluție însă poluează interfața Door deoarece toate clasele care vor moșteni această interfața vor trebui să implementeze și funcționalitatea din TimerClient [4]. class Timer { public:

void Register(int timeout, TimerClient* client); } ; class TimerClient { public:

virtual void TimeOut(); }; class Door { public:

virtual void Lock() = 0;

virtual void Unlock() = 0;

virtual bool IsDoorOpen() = 0; } ;

32

Figura 8

Separarea interfețelor se poate realiza prin mecanismul moștenirii multiple. În Fig 9 se poate observa cum moștenirea multiplă poate fi folosită pentru a respecta în design principiul segregării interfețelor. În acest model, interfața TimeDoor, moștenește din ambele interfețe Door și TimerClient.

Designul agile reprezintă un proces care se bazează pe aplicarea continuă a principiilor agile și a design pattern-urilor astfel încât designul aplicației rămâne în mod constant simplu, curat și cât se poate de expresiv.

Pentru o aprofundare a principiilor enunțate, recomand cu încredere cartea lui Robert C. Martin, Agile Software Development - Principles, Patterns, and Practices.

Bibliografie [1] Robert Martin. Agile Software Development: Principles, Patterns, and Practices. Editura Prentice Hall. 2012.

[2] Gamma, et al. Design patterns. reading Ma: Addison-Wesley, 1998.

[3] Liskov, Barbara. Data Abstraction and Hierarchy. SIGPLAN Notices, 23.5 (May 1988) [4] Meyer, Bertrand. Object oriented software construction, 2nd ed. upper Saddle River, Nj: Prentice Hall, 1997.

Figura 9

Concluzii

Clasele poluate sau ,,grase” conduc către cuplări greșite pentru clienții lor.

Când un client efectuează o modificare asupra unei clase poluate, toți ceilalți clienți ai clasei poluate sunt afectați. De aceea, clienții trebuie să depindă numai de metodele pe care le apelează efectiv.

Acest lucru poate fi realizat prin separarea interfețelor poluate, în mai multe interfețe specifice clienților. Fiecare interfața specifică unui client va conține numai metodele care sunt efectiv apelate de către client.

Clasele ,,grase” pot apoi să moștenească toate interfețele specifice clienților și să le implementeze. Acest mecanism decuplează dependența clienților de metode pe care nu le apelează niciodată și permite clienților să fie independenți unii de alții.

Concluzii Agile Design

Prin aplicarea repetată - de la o iterație la alta, a principiilor mai sus enunțate, se evită cele trei caracteristici care definesc o arhitectură software de slabă calitate: rigiditatea - sistemul este greu de modificat pentru că fiecare modificare afectează prea multe părți ale sistemului, fragilitatea dacă se modifică ceva, apar tot felul de erori neașteptate și imobilitatea - este dificil să se reutilizeze părți dintr-o aplicație pentru că nu pot fi separate de aplicația pentru care au fost dezvoltate inițial.

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

Dumitrița Munteanu

dumitrita.munteanu@arobs.com Software engineer @ Arobs

programare

TODAY SOFTWARE MAGAZINE

iOS 7 blur Introducere în flat design

Î

n ultimul an toată lumea mobile a adoptat conceptul de flat design, fie vorba de Android, iOS sau Windows, fiecare dintre sisteme cu variațiunile proprii. În esența scopul e același: o mai bună înțelegere a interfeței grafice de către utilizator. where you are” astfel ca utilizatorii să aibă o mai bună înțelegere a contextului în care se află. Cel mai bun exemplu este Notification Center, care odată deschis, blurează conținutul din spatele său.

Acest lucru permite vederea noului conținut peste vechea pagină fără să blocheze vederea Home View-ului. Un alt exemplu bun ar fi atunci când vrem să afișăm o alertă: blurând conținutul din spatele ei va conduce natural atenția utilizatorului spre mesajul primit, fără a-l scoate însă din contextul în care se afla anterior.

Cum reușește Apple Pentru realizarea acestui lucru, cei de la Apple lucrează direct cu GPU-ul, acest lucru asigurându-le viteză și calitate. De asemenea, le permite să realizeze așa numitul “live blur” , adică mișcarea elementelor din spate să fie redată prin blur. Din păcate, Apple nu furnizează nici un API pentru a realiza acest lucru în iOS7 SDK, probabil din diverse motive de securitate, iar să lucrezi de la zero cu GPU necesită multe linii de cod și timp. Ca să fim sinceri, vrem să implementăm doar o interfață grafică pentru un Odată cu iOS 7, Apple a introdus flat design împreună cu ecran de alertă, nu un joc 3D. câteva concepte de user experience printre care și ideea de “know

Soluție

Aici apare întrebarea firească, cum obținem așa ceva în aplicațiile noastre? Există mai multe opțiuni, dar în acest articol am să prezint doar una, aleasă pentru simplitatea și rapiditatea cu care poate fi implementată. Această variantă constă în capturarea ecranului prezent, blurarea capturii de imagine și afișarea ei ca imagine de fundal în spatele mesajului de alertă creat. Începem prin a crea clasa noastră proprie de alertă, un view controller bazat pe UIViewController. Pentru capturarea imaginii și blurarea ei avem nevoie de o clasă numită “UIImage+ImageEffects.h” pe care o vom importa în controller-ul paginii. #import “UIImage+ImageEffects.h”

Într-una dintre metodele de lifecycle ale controlle-rului adăugăm următoarele linii și avem deja cea mai simplă modalitate de a obține un fundal blurat: -(void)viewWillAppear:(BOOL)animated { UIImage *snapshot = [self takeScreenSnapshot]; www.todaysoftmag.ro | nr. 25/Iulie, 2014

33

programare iOS 7 blur UIColor *tintColor = [UIColor colorWithWhite:0.2 alpha:0.15];

self.view.backgroundImage = [snapshot

applyBlurWithRadius:8 tintColor:

tintColor saturationDeltaFactor: 1.8 maskImage:nil]; } - (UIImage *)takeScreenSnapshot { UIGraphicsBeginImageContext(self.bounds.size); if([self respondsToSelector:@selector( drawViewHierarchyInRect:afterScreenUpdates:)]){ [self drawViewHierarchyInRect: self.bounds afterScreenUpdates:NO]; } else{ [self.layer renderInContext: UIGraphicsGetCurrentContext()]; } UIImage *image = UIGraphicsGetImageFromCurrentImageContext(); UIGraphicsEndImageContext(); NSData *imageData = UIImageJPEGRepresentation(image, 0.75); image = [UIImage imageWithData:imageData]; return image; }

1. applyBlurWithRadius este numărul de pixeli luați în calculul blur-ului. Cu cât mai mare numărul, cu atât veți avea o imagine mai blurată.

2. tintColor este nuanța care va fi adaugată imaginii procesate. În exemplul de mai sus, am optat pentru un tint mai întunecat.

3. saturationDeltaFactor este nivelul de saturație de culoare aplicat imaginii procesate. maskImage deși nil în exemplul de mai sus, are întrebuințări folositoare în momentul în care vrem să blurăm doar o parte din imagine ca în exemplul de mai jos:

Printre noile metodele din UIImage+ImageEffects.h se numără și applyDarkEffectWithTent. Această variantă a blurului utilizează un filtru bazat pe algoritmul tent, mai rapid decât inițialul alrgoritm box. Iar în loc de 3 treceri necesare printr-un filtru de tip box, în cazul algoritmului “tent” este necesară o singură trecere.

- (UIImage *)applyBlurWithRadius:(CGFloat)blurRadius blurType: (BlurType) blurType tintColor:(UIColor *) tintColor saturationDeltaFactor:(CGFloat) saturationDeltaFactor maskImage:(UIImage *)maskImage { … if (blurType == BOXFILTER) { vImageBoxConvolve_ARGB8888(&effectInBuffer, &effectOutBuffer, NULL, 0, 0, radius, radius, 0, kvImageEdgeExtend); vImageBoxConvolve_ARGB8888(&effectOutBuffer, &effectInBuffer, NULL, 0, 0, radius, radius, 0, kvImageEdgeExtend); vImageBoxConvolve_ARGB8888(&effectInBuffer, &effectOutBuffer, NULL, 0, 0, radius, radius, 0, kvImageEdgeExtend); } else { vImageTentConvolve_ARGB8888(&effectInBuffer, &effectOutBuffer, NULL, 0, 0, radius, radius, 0, kvImageEdgeExtend); } … }

În acest mod se reduce timpul de procesare de la 184 ms la 16 ms. Până la urmă vrem o aplicație cu animații și tranziții cât se poate de fluente, fără timpi morți de așteptare și sacadări, iar calitatea rezultatului e comparabilă cu aceea obținută de Apple în Notification Center.

Finalizez prin a sugera totuși folosirea cât mai simplă și doar în locurile în care credem că ne foloșeste blur-ul pentru a evita îngreunarea funcționării fluide a aplicației.

În detaliu

Pentru cei care vor performață mai bună sau un altfel de blur putem arunca o privire în interiorul “UIImage+ImageEffects.h” și să facem câteva modificări. typedef enum { NOBLUR, BOXFILTER, TENTFILTER } BlurType; @import UIKit; @interface UIImage (ImageEffects) - (UIImage - (UIImage - (UIImage - (UIImage dius; - (UIImage tintColor;

*) *) *) *)

applyLightEffect; applyExtraLightEffect; applyDarkEffect; applyDarkEffectWithTent: (CGFloat) ra-

*) applyTintEffectWithColor:(UIColor *)

- (UIImage *)applyBlurWithRadius:(CGFloat)blurRadius blurType: (BlurType) blurType tintColor:(UIColor *) tintColor saturationDeltaFactor: (CGFloat)saturationDeltaFactor maskImage:(UIImage *) maskImage; @end

34

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

Mihai Fischer

mihai.fischer@gmail.com iOS developer @ Dens.io

programare

TODAY SOFTWARE MAGAZINE

Integrarea datelor între sisteme cu Talend Open Studio

A

şa cum menţiona Jonathan Bowen în cartea sa, „Getting Started with Talend Open Studio for Data Integration”, de îndată ce a apărut cel de-al doilea calculator, integrarea sistemelor a devenit o parte esenţială a muncii echipelor IT.

Complexitatea sistemelor de astăzi, împreună cu ritmul alert în care afacerile evoluează, evidenţiază nevoia de a avea la îndemână un set de unelte care să ne permită executarea rapidă a sarcinilor de integrare. De asemenea, trebuie să fim în stare să reacţionăm cu promptitudine la oportunităţile de noi afaceri.

Experienţa ne-a arătat că, de cele mai multe ori, noii clienţi vin cu cerinţa de a integra în ecosistemul acestora produsul pe care noi îl oferim. Rareori un sistem informatic funcţionează izolat, în propriul său univers. În mai multe rânduri am observat că succesul proiectului propus unui client a depins de capacitatea noastră de a integra sistemul cu produsele pe care acesta deja le folosea.

Procesul despre care vorbim poate însemna sincronizarea a două baze de date o singură dată sau recurent, consumarea unor servicii – fie ele servicii web sau de altă natură – generarea şi transferul de fişiere în diferite formate etc. Aşadar, observăm că avem de-a face cu o varietate de modalităţi prin care putem duce la îndeplinire aceste sarcini, acest lucru contribuind la creşterea complexităţii problemei. De asemenea, uneori este la latitudinea noastră să decidem modalitatea prin care vom realiza integrarea însă, de multe ori, clientul are cerinţe specifice şi în legătură cu acest aspect.

Atunci când ne confruntăm cu o astfel de situaţie, putem fie să construim manual interfaţa între sisteme, ca o soluţie custom, fie să utilizăm un tool specializat pe rezolvarea problemelor de integrare. Un astfel de tool este Talend Open Studio, care vine cu o ofertă interesantă pentru a ne ajuta la rezolvarea sarcinilor noastre de integrare.

Talend Open Studio este reprezentată de modelarea grafică a proceselor pe care dorim să le definim. În tot acest timp, platforma îşi face treaba de zidar în background, generând cod Java. În fond, fiecare componentă pe care o utilizăm are asociat un comportament, descris prin intermediul codului Java.

Având în vedere faptul că acesta este un tool grafic, produsul poate fi utilizat atât de programatori, cât şi de persoane care nu au cunoştinţe de programare. Totuşi, pentru a putea defini anumite comportamente complexe, este nevoie să scriem din când în când cod Java, lucru care ne determină să concluzionăm că utilizatorii care nu cunosc programare se confruntă cu anumite limitări.

Talend Open Studio este relativ uşor de folosit, este o modalitate rapidă de a modela scenarii de integrare, de cele mai multe ori reducând timpul de implementare de la săptămâni sau luni, la zile sau chiar ore, în funcţie de complexitatea proiectului. Totuşi, trebuie să avertizăm cititorii că, asemeni multor altor domenii, dacă din cauza excesului de zel sau a unui design nepotrivit facem overengineering, riscăm să obţinem o soluţie complexă, greu de înţeles pentru alţi utilizatori sau chiar ineficientă. Există şi aici necesitatea respectării unor bune practici, care să asigure calitatea soluţiei noastre.

Printre alte beneficii ale utilizării Talend Open Studio, trebuie să remarcăm că acesta este un produs open source, care permite utilizatorilor să extindă platforma după nevoie. De asemenea, utilizându-l creşte productivitatea, deoarece dezvoltatorii se pot concentra mai mult la definirea procesului decât la implementarea tehnică a acestuia. Ne sunt puse la dispoziţie o mulţime de componente, potrivite situaţiilor mai mult sau mai puţin obişnuite, cu Un overview al mediului Talend Open Studio care putem opera pentru a ne defini procesele. În plus, comunitaTalend Open Studio for Data Integration este un mediu de tea utilizatorilor Talend este activă şi gata să ofere sfaturi tehnice. dezvoltare grafic care, după cum spune şi numele acestuia, este specializat în integrarea datelor între sisteme. La baza sistemului Scenarii de utilizare open source stă mediul Eclipse. Alături de crearea soluţiilor de După cum am menționat în secțiunea anterioară, cele mai integrare, Talend Open Studio cuprinde şi mecanismele necesare obișnuite scenarii de utilizare a proiectului Talend Open Studio livrării acestora – job-urile pot fi rulate atât din interiorul mediu- sunt următoarele: lui, cât şi ca script-uri de sine stătătoare.

• Transfer între baze de date: Atunci când sunt create sisteme Pentru modelarea proceselor, sistemul utilizează conectori. noi sau cele existente sunt actualizate, este nevoie ca datele să fie Dezvoltatorii produsului ne oferă peste 800 de astfel de conectori, migrate într-o nouă bază de date. Aceasta poate să aibă aceeași care ne dau posibilitatea să conectăm cu uşurinţă baze de date, schemă sau una diferită, iar Talend Open Studio ne oferă conecsă citim informaţii din diverse surse, să transferăm fişiere şi să torii și acțiunile necesare acestui proces. efectuăm operaţii asupra lor. De asemenea, avem posibilitatea de a • Schimb de fișiere: Sarcinile de integrare pot necesita tranconecta componente specializate pentru a defini procese complexe sferuri de date în cantități mari. Acest lucru se realizează adesea de integrare. prin intermediul fișierelor. Un exemplu de astfel de fișier este O bună parte din munca pe care o îndeplinim cu ajutorul clasicul CSV (comma separated values). De asemenea, este www.todaysoftmag.ro | nr. 25/Iulie, 2014

35

programare Integrarea datelor între sisteme cu Talend Open Studio posibil ca sistemul care primește fișierul de transfer să aibă nevoie de date într-un alt format. Și acest caz este acoperit de către Studio, fiindcă ne dă posibilitatea să definim procese care efectuează transformări asupra datelor transferate. În plus, avem la dispoziție capabilități de management al fișierelor, prin operații cum ar fi transferul prin FTP sau arhivarea.

• Sincronizare: Sistemele care colaborează nu sunt conectate întotdeauna la același data repository, ceea ce înseamnă că anumite informații pot fi duplicate într-un ecosistem. În consecință, avem nevoie să ne asigurăm că acestea sunt sincronizate periodic. Acesta este cazul datelor despre clienții unei companii, care pot fi prezente, spre exemplu, în sistemul de finanțe, cel de distribuție sau în platforma CRM. Talend Open Studio poate fi folosit pentru a realiza sincronizarea sistemelor, cu ajutorul unor job-uri care automatizează procesul.

• ETL: Acesta este un acronim pentru Extract, Transform, Load, termeni care descriu un proces de bază pentru sistemele data warehouse. Un astfel de proces extrage date din sisteme operaționale, le transformă aplicând reguli sau funcții, iar apoi le încarcă în data warehouse. Din nou, Talend Open Studio ne face viaţa mai uşoară, ajutându-ne substanţial la implementarea acestui tip de proces.

pe care am definit-o, fără ca noi să scriem vreo linie de cod. Tot ce a trebuit să configurăm în componenta de ieșire a fost calea și numele fișierului CSV. Bineînțeles, putem extinde acest job, conectând în continuare alte componente, cum ar fi cele care lucrează cu conexiuni FTP, pentru a transfera fișierul nostru către sistemul țintă.

Concluzii

În secțiunile anterioare am văzut pe scurt care este contextul în care sunt realizate procesele de integrare, ce este Talend Open Studio și care sunt beneficiile utilizării acestui produs. De asemenea, printr-un mic exemplu am încercat să ilustrăm simplitatea utilizării Studio-ului, rapiditatea implementării job-urilor și să ne facem o părere despre capacitatea acestei platforme.

Exemplu

Pentru a ilustra uşurinţa utilizării acestei platforme, creăm un proiect cu un job care transformă un fişier XML într-un fişier CSV. Modelul grafic pentru acest job simplu este ilustrat în figura de mai jos.

În partea stângă avem o componentă de tip tFileInputXML, iar în partea dreaptă o componentă de tip tFileOutputDelimited.

Acestea sunt conectate printr-un conector Main. Înainte de a trage componenta de intrare în designer am definit un obiect metadata, căruia i-am asociat un fișier XML. Studio-ul a detectat automat schema documentului și ne-a dat posibilitatea să selectăm ce noduri să fie transferate către output. Prin intermediul conectorului Main, Talend a transferat către fișierul de ieșire exact structura

36

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

Dănuț Chindriș

danut.chindris@elektrobit.com Java Developer @ Electrobit Automotive

programare

TODAY SOFTWARE MAGAZINE

AOP și LinFu

Î

n ultimele trei numere ale TSM, am descoperit lumea AOP folosind trei stack-uri diferite - .NET, Unity și PostSharp. Dacă ne uităm la aceste framework-uri cu un ochi critic, putem să observăm că PostSharp este un framework extrem de robust care face magia AOP-ului în momentul compilării. Pe când Unity sau .NET stack inserează toată această funcționalitate la runtime.

Run-time vs Build-Time

Este foarte important momentul în care această funcționalitate este injectată deoarece poate să ne afecteze performanța și modul în care aplicația noastră funcționează. În graficul de mai jos putem să vedem o listă cu aceste framework-uri în funcție de momentul în care AOP este injectat în sistem.

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).

Ce este LinFu

Este un set de librării ce ne oferă suport de AOP plus alte câteva funcționalități precum. Mai jos găsiți lista cu toate aceste funcționalități (am lăsat denumirile în engleză, deoarece traducerea în română suna extrem de ciudat): • Aspect-Oriented Programming , • Dynamic Proxies , • Late Binding Mixins, • Universal Event Handling, • Closures with Lambda Arguments, După cum putem observa în diagrama de mai sus, cel mai • Duck Typing, robust framework și flexibil este PostSharp. Acesta injectează în • Design by Contract. momentul compilării tot ce este nevoie în cod pentru a putea adăuga funcționalitatea de care avem nevoie. Pe când un fraAm putea spune că LinFu este o colecție de funcționalități mework ca Unity nu va modifica codul generat de compilator, iar de care am avut nevoie mereu în .NET, dar nu le-am avut niciola runtime va injecta prin reflection și alte mecanisme cu această dată suportate de către .NET stack. Din această cauză am apelat funcționalitate. Din punct de vedere a performanței, injectarea la la framework-uri precum LinFu sau Castle (dacă nu ne-am scris runtime a funcționalități are un preț – performanța. propiile noastre framework-uri). În acest articol vom analiza caracteristicile LinFu- ului. Un Caracteristica cea mai importantă a LinFu este ușurința cu framework de AOP este un framework hibrid, o combinație între care poate să fie învățat. Acesta este un framework extrem de simtipul static și dinamic. Dar înainte să facem acest lucru, haideți să plu, care poate să fie învățat și integrat doar în câteva minute în ne aducem puțin aminte ce este AOP. aplicația noastră.

Deși LinFu are extrem de multe funcționalități, noi ne vom Recapitulare concentra doar asupra celor care sunt legate de AOP. Cât despre AOP este o paradigmă de programare care are drept scop prin- celelalte funcționalități, vă las pe voi să le descoperiți. cipal creșterea modularității unei aplicații. AOP încearcă să atingă acest scop prin permiterea separării aspectelor secante (cross- De unde vine numele cutting concerns) – utilizând interceptarea diferitelor comenzi sau De unde credeți că vine numele de LinFu? Un nume asiatic, al cereri. unui programator care a inițiat acest stack? Nu. În ultimele articole am descoperit cum putem utiliza AOP Language INdependent Features Underneath [.NET] folosind Unity, PostSharp și proprietăți .NET 4.5 (RealProxy).

La urma urmei LinFu este exact ce spune și numele său. O Unity ne oferă posibilitatea de a înregistra acțiunile care pot fi colecție de assembli-uri care extinde funcționalitatea pe care .NET executate înainte și după o acțiune specifică. Clasa RealProxy o are. Această funcționalitate este extinsă folosind librării, fără să este clasa principală în jurul tuturor acestor proprietăți, care este modifice sintaxa limbajului, precum alte framework-uri de AOP. www.todaysoftmag.ro | nr. 25/Iulie, 2014

37

programare AOP și LinFu DynamicProxy

DynamicProxy ne ajută să injectăm la runtime cod și funcționalitate în codul nostru fără să modificăm aplicația deja existentă. De exemplu, dacă dorim să injectăm un sistem de traceing sau audit fară să fim nevoiți să poluăm codul aplicației noastre.

LinFu ne permite să interceptăm orice metodă la runtime, atâta timp cât este virtuală. Din păcate aceasta este o limitare pe care o are LinFu și alte framework-uri de AOP. Metodele pe care le interceptăm trebuie să fie metode virtuale.

Interceptarea unei metode se poate face implementând una din cele două interfețe pe care DynamicProxy ni le pune la dispoziție IInterceptor sau IInvokeWrapper. public interface IInterceptor { object Intercept(InvocationInfo info); } public interface IInvokeWrapper { void BeforeInvoke(InvocationInfo info); object DoInvoke(InvocationInfo info); void AfterInvoke(InvocationInfo info,

object returnValue); }

• Calling Method (metoda apelată), • TypeArguments (tipul parametrilor), • Arguments ( valoarea parametrilor).

O altă caracteristică a acestui framework este constructorul la interceptor, care primește ca parametru o referință la obiectul propriu zis. Acest lucru se întâmplă deoarece LinFu are nevoie de această referință pentru a putea intercepta apelul și a suprascrie metoda virtuală pe care noi vrem să o interceptăm. Până la urma, LinFu doar redirectează apelurile spre un proxy intern.

Tot ce ne-a mai rămas de făcut este să facem legătura între cele două – clasa Foo și interceptor. Acest lucru realizându-se în felul următor: ProxyFactory factory = new ProxyFactory(); Foo foo = new Foo(); FooInterceptor fooInterceptor = new FooInterceptor(foo); Foo customFoo = factory.CreateProxy<Foo>(interceptor);

Da, codul de mai sus nu arată tocmai foarte frumos, dar poate foarte să fie foarte ușor pus într-o metodă generică și să nu mai fie nevoie să ne batem capul cu acest setup. Odată ce avem o referință la customFoo putem să apelăm fără nici o problemă metoda “Do”.

După cum putem observa din definiția celor doua interfețe, Se poate observa foarte clar diferența majoră între PostSharp și putem doar să interceptăm apelul sau să avem un control direct LinFu. PostSharp nu cere folosirea unui proxy, deoarece face totul înainte de apel, după apel sau chiar în momentul apelului și să în momentul compilării generând un cod IL care are deja acest apelăm cu totul altă metodă. hook. Pe când LinFu are nevoie de o configurare din cod. În exemplul de mai jos interceptăm metoda Do din clasa Foo și logăm apelul, fară să apelăm o altă metodă, decât cea originală IProxy din clasa Foo. Un lucru foarte interesant la LinFu este interfața IProxy și în public class Foo special proprietatea “Interceptor”. În momentul în care generăm {

public virtual int Do(int a, int b) un proxy avem o referință la această interfață. Folosind proprieta { tea amintită mai sus, putem să schimbăm la runtime interceptorul, return a+b; } fără să fim nevoiți să generăm un nou proxy sau să schimbăm ceva. } public class FooInterceptor : IInvokeWrapper { private Foo _target; public FooInterceptor(Foo target) { _target = target; } public void BeforeInvoke(InvocationInfo info) { Trace.WriteLine(„Before Do() called”); }

public object DoInvoke(InvocationInfo info) { object result = null; result = info.TargetMethod.Invoke(_target, info.Arguments); return result; }

public void AfterInvoke(InvocationInfo info, object returnValue) { Trace.WriteLine(„After Do() called”); }

IProxy proxy = (IProxy) customFoo; proxy.Interceptor = fooInterceptor2;

Acest lucru se întâmplă deorece CreateProxy ne returnează o instanță a obiectului nostru ușor modificată. Aceasta implementează interfața IProxy și extinde clasa noastră (în cazul nostru Foo).

Ceea ce se generează de CreateProxy arată asemănator cu: public class FooProxy : Foo, IProxy { …

public ovverite int Do(int a, int b) { … } … }

Performanță

Din punct de vedere a performanței, LinFu este mult mai rapid ca Castle sau Unity, dar nu se poate compara cu PostSharp. LinFu } este extrem de folositor în momentul în care avem foarte multe Dacă dorim să apelăm o altă metodă sau să facem ceva spe- metode pe care dorim să le controlăm prin intermediul unui AOP cific în momentul apelului, trebuie să adăugăm cod în metoda framework.

DoInvoke. Putem chiar să apelăm cu totul o altă metodă, fără să mai apelăm metoda de baza din Foo. Acest lucru se poate Limitări face dacă ștergem linia de cod care face apelul propriu zis “info.

LinFu poate să ofere suport de AOP doar pentru metodele TargetMethod.Invoke(…)”. virtuale. O metodă care nu este marcată ca virtuală sau face parte Clasa InvocationInfo conține toată informația de care avem dintr-o clasă sealed, nu poate să fie controlată. nevoie: • Target (instanța proxy-ului), Licențiere • TargetMethod (metoda apelată), Acesta este un framework sub licența GNU. Putem să îl folosim • StackTrace (stack-ul în momentul apelului), și să îl modificăm fără nici un fel de probleme.

38

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Concluzie

Acesta este ultimul articol despre AOP. În cele patru articole pe care le-am citit până acuma despre AOP, am descoperit diferite mecanisme prin care putem să avem suport AOP în aplicația noastră. Fiecare framework are avantaje și dezavantaje. Putem spune că PostSharp este cel mai complet, având cele mai multe funcționalități și cea mai bună performanță, doar că acest lucru vine cu un cost. PostSharp nu este gratis. În tabelul de mai jos putem să vedem funcționalitățile suportate de fiecare framework de AOP: PostSharp

LinFu

Castle (Sprint .NET)

Unity

M e t h o d Interception

Yes

Yes

Yes

Yes

Private/Sealed Member Interception

Yes

Yes

No

No

E v e Interception

t

Yes

No

No

No

M e m b e r Introduction

Yes

No

No

No

n

Radu Vunvulea

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

www.todaysoftmag.ro | nr. 25/Iulie, 2014

39

programare

Securizarea codului Open source (II)

D

upă cum am menționat anterior în această lucrare, rulăm Klocwork Insight peste nucleul Linux (versiunea 2.6.32.9) și analizăm rezultatele analizei noastre. Versiunea Klocwork Insight utilizată pentru această analiză a fost 9.2.0.6223. Figura 3 arată verificatorii Klocwork pe care i-am utilizat pentru a analiza codul sursă C/C++. Acestea sunt de fapt ,,familii de verificatori″ sau ,,categorii″, deoarece fiecare dintre aceste 3 elemente (din figura 3) conține un număr de verificatori individuali.

Acești verificatori au fost validați pe Klocwork pentru analiza noastră pentru a identifica toate problemele semnificative din codul sursă care este analizat. Metricile proiectului raportate de Klocwork după analizarea codului Linux kernel (2.6.32.9) sunt indicate în tabelul 1.

TABELUL 1 METRICILE PROIECTULUI RAPORTATE PENTRU SCA A NUCLEULUI LINUX Număr total de fișiere

13999

Număr total de fișiere C/C++ analizate

13868

Număr total de fișiere de sistem analizate

131

Total linii de cod (Sursă LOC)

4309863

Total linii de comentarii

1358746

Număr total de entități

944835

Număr total de funcții / metode

162814

Numărul total al claselor / tipurilor

42797

Fig.3 Verificările Klocwork pentru codul C/C++

În următoarele două secțiuni vom prezenta analiza vulnerabilității și analiza complexității nucleului Linux, după efectuarea SCA pe codul Linux kernel.

Analiza vulnerabilității

Anumiți identificatori ai Vulnerabilităților și Expunerilor Comune (CVE) pentru vulnerabilitățile de securitate a informațiilor publice pentru numeroase versiuni ale Linux

40

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

kernel, inclusiv versiunea 2.6.32.9 sunt prezentați în tabelul 2.

Vulnerabilitățile enumerate în tabelul 2 nu sunt în nici un caz complete, ci sunt o submulțime a vulnerabilităților publicate în National Vulnerability Database (NVD), după lansarea versiunii 2.6.32.9 a nucleului Linux. Lansarea versiunii 2.6.32.9 a nucleului Linux a fost anunțată în februarie 2010. Vulnerabilitățile enumerate în tabelul 2 au fost publicate în NVD între lunile februarie 2010 și iulie 2011, ceea ce constituie perioada noastră de luare de probe. NVD este depozitul guvernului Statelor Unite de date de management al vulnerabilităților bazat pe standarde, reprezentate prin Security Content Automation Protocol (SCAP).

Aceste date permit automatizarea managementului vulnerabilității , măsurarea securității și conformitatea. NVD include baze de date ale tabelelor de control securitate, defecte software legate de securitate, configurații greșite, nume de produse și metrici de impact (13).

Prin efectuarea SCA pe versiunea Linux kernel anterior menționată, noi putem identifica vulnerabilitățile prezentate în tabelul 2. Mai mult, aceste vulnerabilități identificate folosind SCA reprezintă aproximativ 10% din toate vulnerabilitățile Linux kernel (v2.6.32.9) raportate între februarie 2010 (lansarea versiunii Linux kernel 2.6.32.9) și iulie 2011 (sfârșitul perioadei noastre de probă) în NVD. Chiar dacă nu toate vulnerabilitățile publicate în NVD care corespund versiunii 2.6.32.9 a Linux kernel au putut fi detectate numai prin analiza statică, procentul de 10% din probleme, pe care SCA a fost în stare să le identifice, după cum arată tabelul 2, include un număr semnificativ de probleme de securitate și calitate. Din acest 10% vulnerabilități, aproximativ 22.3% au fost clasificate drept ,,Ridicate″, 44.3% au fost considerate ,,Medii″ și 33.3% au fost apreciate drept ,,Scăzute″ pe Sistemul de Evaluare al Vulnerabilităților Comune (CVSS). Acest exercițiu indică cu succes faptul că anumite vulnerabilități (după cum se arată în tabelul 2) din nucleul Linux (inclusiv versiunea 2.6.32.9), publicate încă din iulie 2011 în NVD, ar fi putut fi detectate mult mai devreme, dacă s-ar fi efectuat mai devreme o analiză statică și o revizuire sârguincioasă.

Un alt factor important de luat în considerare este tipul vulnerabilităților care pot fi identificate prin SCA. Tipurile de vulnerabilități pe care SCA a reușit să le detecteze în experimentul nostru includ buffer overflows, integer overflows/underflows, eroare integer signedness și inițiere memorie necorespunzătoare. Acestea sunt câteva din vulnerabilitățile care au fost exploatate frecvent pentru a lansa atacuri malițioase asupra diverselor aplicații software. De exemplu, anomaliile buffer overflow au o tradiție în a fi exploatate de către viruși ai computerelor precum virusul Morris (1988) sau mai recent virusul Conficker (2008). Merită efortul de a identifica asemenea viruși de timpuriu atunci când incorporăm cod opensource în codul patentat, de vreme ce experimentul nostru demonstrează că SCA are capacitatea de a detecta un număr

TODAY SOFTWARE MAGAZINE semnificativ de astfel de viruși și este un factor motivant puternic să efectuezi SCA pe codul opensource adoptat.

TABELUL II. VULNERABILITĂȚILE LINUX KERNEL DETECTATE DE SCA Dincolo de faptul că a reușit să detecteze aceste vulnerabilități cunoscute dinainte, instrumentul SCA a fost capabil să semnaleze anumite probleme critice din cod, care ar putea necesita o investigare suplimentară pentru a evalua veridicitatea lor și gradul în care pot fi exploatate. Chiar dacă exploatabilitatea unora dintre aceste vulnerabilități nu poate fi justificată numai prin analiza statică, este în interesul oricărui vânzător de software să rezolve aceste probleme înainte ca software-ul să fie lansat pe piață. Acest lucru stabilește importanța efectuării SCA pe codul sursă pentru a identifica și repara anumite probleme de codare de timpuriu, spre deosebire de a aștepta comunitatea opensource să identifice și să raporteze aceste probleme, deoarece, cu cât o vulnerabilitate sau un virus pot fi detectate mai devreme, cu atât mai ieftin este

neincluse în categoriile de mai sus.

Figura 4. Numărul vulnerabilităților per categorie semnificativă a Linux Kernel (v2.6) publicat în NVD (anii 2010- 2011).

O privire rapidă peste NVD arată că cele mai multe vulnerabilități publicate (între anii 2010 și 2011) pentru nucleul Linux au loc în componentele ,,networking″ ale nucleului, urmate de componentele ,,drivere″ și ,,filesystems″, după cum se poate vedea în Figura 4. Acest lucru poate fi atribuit faptului că grupul network, care, bineînțeles, are de a face cu capacitățile de networking, este unul dintre componentele cel mai frecvent exploatate ale nucleului Linux. Acest lucru este compatibil cu ,,propunerea atrăgătoare″ de a lansa atacuri izolate și, de aceea, mulțimea network este o țintă obișnuită pentru exploatare, ceea ce ar putea justifica numărul crescut de vulnerabilități care sunt raportate.

Analiza complexității

să le repari.

Pentru a analiza ce componente ale nucleului Linux au mai mare incidența de vulnerabilități raportate, separăm fișierele nucleului în șase categorii importante, care sunt următoarele (12): • Core (Nucleu): Acesta include fișierele din subdirectoarele init, block, ipc, kernel, lib, mm și virt.

• Drivers (Drivere): Acesta include fișierele din subdirectoarele crypto, drivers, sound, security, include/acpi, include/ crypto, include/drm, include/media, include/mtd, include/pcmcia, include/rdma, include/rxrpc, include/scsi, include/sound, și include/vide.

• Filesystems (Sisteme fișiere): Acesta include fișierele din subdirectorul fs.

• Networking (Rețea): Acesta include fișierele din subdirectoarele net și include/net.

• Architecture-specific (Specifice arhitecturii): Acesta include fișierele din subdirectoarele arch, include/xen, include/mathemu, și include/asm-generic.

• Miscellaneous (Diverse): Acesta include tot restul fișierelor

De obicei, instrumentele SCA pot calcula parametrul complexității pentru programele pe care le analizează. Pe scurt, parametrul complexității măsoară numărul deciziilor care există într-un program; măsoară în mod direct numărul căilor independente liniare prin codul sursă al unui program. Cu cât există mai multe decizii posibile de luat în timpul rulării, cu atât sunt posibile mai multe direcții de date. Institutul Național al Standardelor și Tehnologiei (NIST) recomandă programatorilor să calculeze complexitatea modulelor pe care le dezvoltă și să le separe în module mai mici ori de câte ori complexitatea ciclomatică a modulului depășește 10. Dar în anumite circumstanțe, poate fi adecvată lărgirea restricției și îngăduirea modulelor cu o complexitate până la 15, dacă este oferită o explicație în scris a motivelor pentru care a fost depășită limita (9). Un parametru ridicat de complexitate face aproape imposibil ca un programator uman să poată urmări toate căile posibile, iar de aici rezultă probabilitatea crescută ca programatorul să introducă un defect nou atunci când codul este modificat sau când se adaugă cod nou. Dacă complexitatea ciclomatică a programului este mai mare de 50, un asemenea program este considerat ne-testabil și având un risc foarte mare. Studiile arată o corelare între complexitatea ciclomatică a programului și mentenabilitatea și testabilitatea sa, sugerând că la fișierele cu complexitate mai mare există o probabilitate mai mare de erori atunci când se repară, se îmbunătățește sau se reutilizează codul sursă. Într-un proiect opensource similar lui Linux, cea mai mare parte a efortului de dezvoltare este comunicată prin liste de adrese.

Dezvoltatorii sunt împrăștiați în jurul lumii și prezintă niveluri variate de abilități de dezvoltare software. De aceea, această situație ar putea reprezenta o sarcină provocatoare pentru orice entitate centrală responsabilă cu coordonarea eforturilor de dezvoltare. www.todaysoftmag.ro | nr. 25/Iulie, 2014

41

programare Securizarea codului Open source (II) Numărul metodelor cu o complexitate mai mare de 20 conținute în componentele nucleului Linux este ilustrat în figura 5. Raportul de complexitate medie (Complexitatea maximă a metodelor / Numărul total de metode) pentru metodele cu o complexitate mai mare de 20 per categorie semnificativă a nucleului Linux este ilustrat în figura 6. Prima coloană din figura 6 reprezintă complexitatea medie pentru întregul nucleu Linux (v2.6.32.9), în timp ce restul coloanelor reprezintă complexitatea medie pentru componentele semnificative conținute de nucleul Linux. Din figura 6 reiese în mod evident faptul că complexitatea medie pentru componentele individuale importante din Linux kernel este mult mai mare (peste 2x) decât complexitatea medie pentru întregul Linux kernel. O privire rapidă prin NVD arată că cele mai multe vulnerabilități publicate pentru nucleul Linux se găsesc în componentele care conțin un număr mare de metode de complexitate crescută care cel mai adesea includ componentele ,,drivers″, ,,filesystems″ și ,,networking″, după cum se arată în Figura 4.

Mărimea procentului per categorie semnificativă din nucleul Linux (versiunea 2.6) este ilustrată în figura 7. Numărul de linii modificate per categorie importantă din nucleu Linux (versiunea 2.6) este arătat în figura 8. Este interesant de observat că, în ciuda faptului că componenta ,,networking″ a nucleului Linux conține un număr mai mic de metode de complexitate ridicată ( din figura 5) și mai puține Linii de Cod (LOC) (din figura 7) în comparație cu componentele ,,drivers″ și ,,filesystems″, o majoritate a vulnerabilităților publicate în NVD au loc în componenta ,,networking″ (din figura 4). Motivul pentru aceasta a fost discutat în secțiunea anterioară despre analiza vulnerabilității. Mai mult, chiar dacă componenta ,,networking″ a nucleului Linux conține mai puține linii de cod, complexitatea medie (din fig.6) pentru componenta ,,networking″ este cea mai ridicată în comparație cu alte componente ale Linux kernel, ceea ce sugerează că componentele ce au o complexitate ridicată tind să conțină un număr mai mare de erori. Un alt lucru interesant de notat se referă la componenta ,,architecture-specific″ a nucleului Linux care are un număr mai mic de metode de complexitate ridicată (din fig.5), are mai multe linii de cod (din fig.7) și a suferit un număr important de modificări în liniile de cod (din fig.8). În plus, complexitatea medie (din fig.6) pentru componenta ,,architecture-specific″ este ridicată, ceea ce sugerează că acele componentele care primesc un număr mare de modificări în liniile de cod tind să aibă o complexitate mai mare.

Figura 6. Raportul de complexitate medie (Complexitatea maximă a metodelor / Numărul total al metodelor) pentru metodele cu o complexitate >20 per categorie semnificativă a Linux kernel (v2.6)

Figura 7. Mărimea procentajului per categorie semnificativă a Linux kernel (v2.6)

În general, din analiza noastră, observăm următoarele tipare: • Probabilitatea ridicată de erori în componentele cu o complexitate mai mare (din fig. 4, 5 și 6), de exemplu componentele ,,drivers″, ,,filesystems″ și ,,architecture-specific″.

• Componentele complexe cu un număr mai mare de linii de cod au primit un număr mai mare de modificări de cod și actualizări (din fig.7 și 8), de exemplu componentele ,,drivers″ și ,,architecture-specific″.

• Componentele critice, cum ar fi ,,networking″, tind să prezinte incidențe mai mari de erori raportate (din fig. 4).

Prin observarea acestor tipare, am putea să concentrăm aria de acoperire a SCA asupra acestor componente critice ale codului, ceea ce vom explica în secțiunile următoare.

Raghudeep Kannavara

raghudeep.kannavara@intel.com

Figura 5. Numărul de metode cu complexitate >20 per categorie semnificativă a Linux kernel (v2.6)

42

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

Security Researcher, Software and Services Group @Intel USA

diverse

TODAY SOFTWARE MAGAZINE

Gogu și Bătrânu’ lui Mișu

- No, mii de buciume și bâte să le zîcă de dor! răbufni Mișu cu ciudă. Cu ciudă numai pentru cei care-l cunoșteau foarte bine, altfel - pentru un străin – ar fi părut o simplă constatare, împărtășită calm dar apăsat, cu vocea în surdină. Evident, nu era cazul lui Gogu, care privi stupefiat spre Mișu, nevenindu-i să creadă că a reușit cineva să-l scoată - pe Mișu! - din starea lui de molcomă înțelegere și totală detașare de vâltoarea lumii din jurul lui. Se pare însă că, într-un final, imposibilul se produse, și vâltoarea reușise să-l agațe și pe el , își zise Gogu, oarecum înciudat.

- Buciume, bâte și opinci în spinare, sublinie Mișu, la fel de molcom, dar puțin mai apăsat de această dată. Gogu nu mai putu să se abțină: - Probleme, Mișule?!

Mișu ridică privirea spre Gogu, îi zâmbi cald și consimți: - Îs ceva probleme... Incredibil, ăsta ar fi în stare să-i zâmbească și plutonului de execuție, gândi Gogu și mai puse un lemn pe foc: - De natură să te enerveze?

- No, mi-o venit să le zîc vreo doua așa... da’ mi-o trecut.

Numa’ nu știu cum oi rezolva.

- Păi ia s-aud și eu, poate o scoatem împreună la capăt, se oferi Gogu, nu de alta dar îl sfredelea curiozitatea.

-Apăi să vezi, știi că m-o pus Șefu’ manager de proiect...

- Știu, îi tăie Gogu vorba, toată firma știe, ne-ai astenizat pe toți. Noaptea dacă ne trezești, ăsta-i primu’ lucru care ne vine în minte. Văzu fața profund jignită a lui Mișu și continuă pe un tot mai cald: Hai, spune, să vedem care e problema.

- Tu știi că ăsta îi un proiect diferit...

- Toate proiectele sunt diferite, că de-aia le cheamă proiecte, nu se putu Gogu abține.

- Bine că ești tu deștept, nu se lăsă Mișu mai prejos, dar cum subiectul era mult prea important pentru el, se decise să ignore remarcile lui Gogu și să continue. Știi ce-am vrut să spun: că față de proiectele noastre uzuale de outsourcing, ăsta - care lansează un produs nou – are cu totul alte caracteristici, alte cerințe, alte constrângeri; nu avem doar dezvoltare, ci și elemente de

marketing. Adică e mult mai complex.

- Auzi, dacă iar o iei de la Ana la Caiafa, și mă zăpăcești cu complexitatea, stakeholderii și-alte alea, te rog să cânți la altă masă.

Fața lui Mișu exprima uluială în formă pură: Cum adică să cânt? Spuse el rar, foarte rar, încercând să cuprindă sensul celor spuse de Gogu. Ce-are a face una cu alta? Ăsta nu mai învață, frate, își zise Gogu în gând, unde-o fi crescut, la stână? Ha-ha-ha, se trezi râzând tare, spre totala stupefacție a lui Mișu. Păi chiar că la stână! Ha-ha, nu se putu opri din râs. Mișu nu pricepea care e motivul râsului sănătos al lui Gogu, dar intuia că e – cumva – vorba de el. Așa că își încrucișă brațele la piept arătând că așteaptă clarificări. Pe care le așteptă destul de mult, lui Gogu luându-i ceva vreme până să se domolească.

- Gata, Mișule, iartă-mă, nu mai fac, zi-i mai departe.

Se dovedi că problema nu era deloc complicată - greșiseră unii niște materiale de promovare -, dar se agravase datorită întârzierii în rezolvare. Abordarea nu excelase în diplomație, comunicarea s-a realizat exclusiv prin e-mailuri, iar tonul acestora devenise din ce în ce mai dur pe măsură ce ping-pong-ul epistolar se prelungise.

Se deraiase demult de la problemă, ultimele e-mailuri rezumându-se la amenințări destinate persoanelor, sursa discuțiilor și problema în sine fiind deja uitate.

- Și-acum vin și te-ntreb pe tine, Gogule, eu cum rezolv problema asta?! Că între timp tot restul proiectului a mers înainte, iar noi avem lansarea oficială peste trei zile. Online-ul a mers strună, dar prezentarea live presupune și toate materialele astea... Ufff, oftă el, un oftat venit din adâncul sufletului lui de ardelean care nu înțelegea cum pot să-ți aducă niște cuvinte atâtea probleme.

- Hi-hi... adicătelea tu crezuseși că s-a terminat totul și poți considera proiectul închis?! Ha-ha, se văzuse cu sacii în căruță!

Măi, Mișule, ori tu nu știi vorba aceea: primele 90 de procente din proiect se fac în 90% din timp, iar pentru ultimele 10 procente mai ai nevoie de alte 90% de timp... ha-ha...

- Auzi , Gogule, n-oi ști-o io pe asta, da’ o știu pe-ailaltă, aia de zice că îmi trebe’ 42 de mușchi să mă încrunt, 28 să zâmbesc, www.todaysoftmag.ro | nr. 25/Iulie, 2014

43

diverse Gogu și Bătrânu’ lui Mișu da’ numa’ 4 să-mi întind brațul și să te pocnesc în plină figură...

Gogu se uită rapid la el dar se liniști, Mișu era în continuare cu zâmbetul pe față. Mda, când n-o mai zâmbi, vom avea cu toții de furcă, gândi Gogu, calculându-și șansele în fața unei posibile locomotive Mișu, concluzionând rapid că nu și-ar dori nimeni să-l enerveze vreodată pe colosul ardelean. Care colos știe însă să se joace cu atâta dezinvoltură cu copiii, își aduse aminte Gogu vacanța ce abia se terminase. Și atunci avu revelația!

- Auzi, Mișule, ții minte cum te-ai jucat săptămâna trecută de-a castelanul care își repară fortificațiile înainte de atacul inamicului?

Ușor surprins de întorsătura discuției, Mișu își reveni repede și dădu vesel, dar și foarte mândru, din cap a aprobare. Fuseseră împreună în concediu la mare, prima ieșire a lui Mișu la soare grecesc, mare turcoaz și nisip alb, strălucitor. Intervenise o situație și soția lui Gogu fusese nevoită să rămână acasă, iar Gogu nu avusese sufletul să îi refuze copilului o vacanță la care cel mic visa de luni de zile. Așa că îi propuse lui Mișu să-i însoțească. Și ceea ce fusese o invitație făcută mai mult într-o doară, devenise o super vacanță pentru Mișu și copil, care s-au distrat – împreună – incredibil de bine.

Mișu rememoră secvența cu reparatul fortificațiilor în nisipul grecesc și fața i se lumină.

- Adică, zici tu, că ce-a mers cu fi-tu, merge și-aici? Păi e corect, sigur c-ar merge, stai așa, că știu exact ce trebe’ să fac... și se întoarse spre calculator, ignorându-l total pe Gogu.

- Mai concret, ce-a făcut Mișu cu fi-tu? Gogu îl văzu pe Șefu’ cu o secundă înainte ca acesta să-și facă cunoscută prezența prin întrebarea aruncată șoptit, parcă fără a vrea să-l deranjeze pe Mișu.

Nu că ăsta ar auzi ceva dacă se afundă el într-ale lui, poți să tragi cu tunu’ la urechea lui și el te ignoră total, remarcă Gogu în gând, apoi continuă cu voce tare: - Ei, mă căzneam să-l scot din apă pe copil, iar el nu și nu, că de-aia merge omu’ la mare să facă baie. Și dăi cu vorba bună, dă-i cu amenințări, s-a ajuns la strigăte (eu) și ignorare completă (el), cuvinte grele (eu), las’ că-i spun eu mamei ce-ai zis (el), ce mai, război total. Și în mijlocul luptei, numai ce-l aud pe Mișu, cu calmul ăla de ne scoate pe noi din minți, spunându-i copilului că are nevoie de ajutor la construcția lui mirifică din nisip, că nu se mai descurcă singur cu nu-ș-ce fortificație, ori zid de apărare, ce-o fi fost. Iar al meu iese instant din apă și se apucă de lucru.

Abia peste vreo cinci minute mi-am revenit și mi-am așezat la loc falca căzută... Evident, seara mi-am avut porția de introducere în psihologia copilului, viziunea Mișu sleș Bătrânu’ lui Mișu...

-Hmm, nu e rea viziunea asta, zâmbi Șefu’. Presupun că până deseară avem și porția de Introducere în viziune... Să mă ții la curent. *** ‚Introducerea în viziune’ veni însă mult mai târziu, respectiv la ședința de închidere a proiectului, la vreo două săptămâni după lansarea oficială a noului produs; o lansare încununată de succes și care a adus felicitări întregii echipe coordonate de Mișu.

La ședință, Mișu a cerut fiecărui membru al echipei să spună trei

44

nr. 25/Iulie, 2014 | www.todaysoftmag.ro

lucruri: ce crede că a mers bine, ce crede că n-a mers bine și, în final, ce-ar face altfel dacă ar fi să ia proiectul de la capăt. Șefu’ a vrut să afle cum s-a rezolvat problema cu print-urile eronate, declanșând ‚viziunea’: - No, că n-o fost bai mare. Oamenii erau supărați că nu s-or înțeles ei pe e-mailuri, cine o fo’ vinovat, cine ce-o zis și ce-o cerut, de unde s-o plecat și pe cine să pedepsim. Pe mine Bătrânu’ meu așa m-o învățat: să caut numa’ care îi problema și pe aia s-o rezolv.

Nu era problema mea cine ce-o-nceput, ci cum or ajunge materiale corecte la lansare. Așa că am scris un e-mail frumos în care i-am rugat să mă ajute să pot să mă țin de data anunțată pentru evenimentul oficial și să îmi trimită materialele corecte direct la zona expo. Ceea ce or și făcut, iar eu le-am mulțumit. C-așa m-o învățat Bătrânu’, zicea el că omu’ mai repede reacționează la o cerere de ajutor decât la o indicație...

Simona Bonghez, Ph.D.

simona.bonghez@confucius.ro Speaker, trainer and consultant in project management, Owner of Colors in Projects

sponsori

powered by