TSM_6_2012_ro

No. 6/ 2012 • www.todaysoftmag.ro

TSM

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

Made in Romania Istoria IT-ului Clujean Arhitectură pentru Flexibilitate Tehnici SEO interne (II) Agile, crash course Introducere în Grails Interviu cu Scott Barber A scrie cod frumos - dincolo de valoarea estetică 10 principii de arhitectură software Poți fi agile în proiecte de preț fix?

Echilibrul dintre viața profesională și cea personală O incursiune prin atacurile informatice din 2012 Agile, crash course Gogu și imaginea de ansamblu Toate drumurile duc la SaaS - 7 provocări pentru a ajunge acolo How to Web conecteaza Europa de Sud-Est la inovatia web Finanţare pentru startup-uri tech prin reţeaua de investitori Tech Angels

6 How to Web conecteaza Europa de Sud-Est la inovatia web Irina Scarlat

7 Finanţare pentru startup-uri tech prin reţeaua de investitori Tech Angels Bogdan Iordache

8 Made in România Ovidiu Mățan

10 Istoria IT-ului Clujean Marius Mornea

12 Arhitectură pentru Flexibilitate Attila Antal

15 Tehnici SEO interne Radu Popescu

18 10 principii de design (fabulă) Stefan Baritchii

21 Interviu cu Scott Barber Mariu Mornea

24 A scrie cod frumos dincolo de valoarea estetică Attila-Mihaly Balazs

27 Toate drumurile duc la SaaS - 7 provocări pentru a ajunge acolo Mihai Nadăș

29 Introducere în Grails Tavi Bolog

32 Exemple practice de message paterns pentru Windows Azure Radu Vunvulea

34 Poti fi agile în proiecte de pret fix?

Claudiu Anghel

36 O incursiune prin atacurile informatice din 2012 Andrei Avădănei

38 Agile, crash course Florian Ivan, PMP

40 Echilibrul dintre viata profesională si cea personală Andreea Pârvu

42 Gogu si imaginea de ansamblu Simona Bonghez, Ph.D.

editorial

Editorial

Ovidiu Măţan, PMP

ovidiu.matan@todaysoftmag.com Fondator și CEO al Today Software Magazine

Câteodată ne place să ne considerăm foarte neîndreptățiți, să spunem că la noi nu se întâmplă nimic, într-o țară mediatizată extern și mai ales intern cu o imagine negativă. Îmi amintesc că, odată citind un ziar de dimineață în Tokyo am fost surprins să văd multitudinea de știri pozitive fapt care m-a făcut să pornesc de dimineață cu optimism și chef de lucru. Nerăbdarea de a savura în același fel și presa românească ne-a determinat sa dam noi startul cu o trecere în revistă a celor mai importante evenimente din sfera IT-ului românesc.

How To Web 2012, cea mai importantă conferință despre antreprenoriat și tehnologie din România are loc la București. Vor fi peste 800 de participanți și nume importante din sfera startup-urilor de succes. TSM va fi prezent la aceasta și vom avea chiar o mini lansare în cadrul evenimentului. Mai multe detalii în articolul dedicat acestuia din revistă, iar în numărul următor vom reveni cu detalii.

Next 2012, conferința organizată de Softvision la Cluj l-a avut invitat pe Scott Barber, un profesionist în testarea performanței. Un interviu cu acesta este disponibil în acest număr.

Antreprenor vs. Investitori, organizată de către Business Days și avându-l ca invitat principal pe Robert Hisrich, s-a desfășurat la București și Cluj. Aceasta a adus în fața auditoriului principalele nume din atreprenoriatul românesc. Alături de Robert Hisrich am putut asista la o zi întreagă de dezbateri despre cum să îți începi o afacere sau ce trebuie să faci ca business angel.

Tech Angels www.techangels.ro este un grup business angels românesc care vrea să sprijine startup-urile locale din sfera IT-ului. Primul pas pentru un dialog în acest sens se poate face aplicând online.

Sper ca cele de mai sus să vă ajute să începeți ziua cu o notă de optimism. Pentru a fi mai convingători, din acest număr am inaugurat o rubrică Made in România, unde veți putea citi despre produse și companii de software românești de suces. Colegul meu, Marius Mornea, va începe să scrie o istorie a IT-ul clujean, efort ce se va întinde pe mai multe luni, iar cei ce vor să sprijine acest efort sunt bineveniți. Continuăm seria de articole tehnice printr-o Introducere în Grails și deja cunoscuta serie de Tehnici SEO interne. Arhitectura este subiectul principal în Arhitectură pentru flexibilitate și Exemple practice de message paterns pentru Windows Azure iar cele 10 principii de design ne prezintă conceptele într-o abordare diferită sub forma unei fabule. Project management-ul este acoperit de către Poți fi agile în proiecte de preț fix? și Agile, crash course. Un articol interesant despre atacurile informatice din 2012 și poziționarea României în războiul cibernetic, vine și cu o invitație la DefCamp, unicul eveniment de acest gen din România. Echilibrul dintre viața profesională și cea personală reprezintă o continuare a articolelor de HR scrise de către Andreea, iar la final vi-l propun pe Gogu pentru o lecție plină de învățăminte.

Ovidiu Măţan Fondator și CEO al Today Software Magazine

4

nr. 6/2012 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Redacţie Fondator / Editor in 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 Colaborator marketing: Ioana Fane ioana.fane@todaysoftmag.com Traducător: Cintia Damian cintia.damian@todaysoftmag.com

Lista autorilor Irina Scarlat

Attila-Mihaly Balazs

Co-Fondator al Akcees, organizatie care promoveaza antreprenoriatul in randul tinerilor, si al Prove PR

Code Wrangler @ Udacity Trainer @ Tora Trading

Bogdan Iordache

Andreea Pârvu

Bogdan Iordache este Co-Fondator al How to Web, cel mai important eveniment web din Europa de Est

Recruiter în cadrul Endava și trainer specializat în dezvoltarea abilităților si competenețelor de leadership

Ovidiu Măţan, PMP

Radu Vunvulea

irina.scarlat@howtoweb.co

dify.ltd@gmail.com

bogdan.iordache@howtoweb.co

ovidiu.matan@todaysoftmag.com Founder & CEO Today Software Magazine

Marius Mornea

marius.mornea@todaysoftmag.com Fost senior software developer in cadrul Nokia, în prezent fondatorul platformei Mintaka Research

str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag

Simona Bonghez, Ph.D.

Simona.bonghez@confucius.ro Speaker, trainer şi consultant în managementul proiectelor, Owner al Confucius Consulting

Produs de

Today Software Solutions SRL

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

Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com

andreea.parvu@endava.com

Attila Antal

Attila.Antal@isdc.eu

Andrei Avădănei andrei@worldit.info

Software Arhitect @ ISDC

Fondator si CEO DefCamp CEO worldit.info

Tavi Bolog

Mihai Nadăș mihai.nadas@tss-yonder.com

tavi.bolog@nokia.com

CTO @ Yonder

Development lead @Nokia

ISSN 2284 – 6352 Radu Popescu

rpopescu@smallfootprint.com

Claudiu Anghel

claudiu.anghel@iquestgroup.com Project Manager @iQuest

QA şi Web designer @ Small Footprint

Stefan Baritchii

Florian Ivan, PMP, ACP, CSM, MVP

Technical Lead @ 3Pillar Global Romania

Project MVP

stefan.baritchii@3pillarglobal.com

florian.ivan@rolf-consulting.com

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. 6/2012

5

conferințe

How to Web conectează Europa de Sud-Est la inovaţia web

R

omânia şi ţările din regiune sunt renumite pentru numărul mare de oameni cu talent şi abilităţi tehnice. Cu toate acestea, piaţa regională este bazată pe activităţi de outsourcing, iar inovaţia şi dezvoltarea de produs joacă un rol secundar, neglijabil. În contextul dat, există antreprenori care cred în viitorul acestei industrii şi care organizează an de an în regiune unul dintre cele mai importante evenimente despre antreprenoriat şi tehnologie din Europa: How to Web.

Irina Scarlat

irina.scarlat@howtoweb.co Irina Scarlat este Co-Fondator al Akcees, organizatie care promoveaza antreprenoriatul in randul tinerilor, si al Prove PR, companie care ofera servicii de comunicare specializate pentru startup-uri si ONG-uri. Irina a lucrat in trecut ca trainer, consultant business, si a condus timp de doi ani departamentul de comunicare al Ligii Studentilor Romani din Strainatate. Este licentiata in Economie si Afaceri Internationale (ASE Bucuresti) si are un masterat in Economie Politica obtinut la BI Norwegian School of Management si ESCP Europe. In prezent, Irina isi finalizeaza cel de al doilea masterat in Managementul Proiectelor Internationale (ASE Bucuresti)

6

nr. 6/2012 | www.todaysoftmag.ro

De la an la an, How to Web a avut o evoluţie foarte interesantă, atât din punct de vedere cantitativ cât şi calitativ. Cea de a patra ediţie a evenimentului va avea avea loc în luna noiembrie la Bucureşti şi va reuni peste 800 de participanţi care vor avea ocazia să discute cu peste 40 de vorbitori internaţionali din mai bine de 15 ţări. Printre vorbitorii care vor fi prezenţi la această ediţie se numără: Phil Libin (CEO Evernote), Bill Liao (Co-Fondator XING), Mark Pascarella (CEO UberVU), David Noel (VP Community SoundCloud), sau Patrick DeLaive (Co-Fondator The Next Web). În cadrul How to Web vor fi abordate teme precum inovaţia în tehnologie, dezvoltarea de aplicaţii mobile, softwareas-a-ser vice şi jocuri pe calculator, particularităţile înfiinţării afacerilor web în Europa de Est, dezvoltarea la scară globală şi finanţarea acestora. Ceea ce este inedit la eveniment este că poţi discuta în mod direct şi poţi pune întrebări unora dintre cei mai apreciaţi oameni în domeniul tehnologiei din întreaga lume. În plus, How to Web contribuie la crearea şi descoperirea de noi oportunităţi de afaceri. Numărul de poveşti de succes înregistrate până în prezent confirmă acest lucru şi reprezintă o recomandare în sine.

Pentru Cristian Andreica (Co-Fondator Nexi.me), How to Web a reprezentat punctul de plecare la acceleratorul Rockstart (Amsterdam), de unde s-a îndreptat către Silicon Valley. O poveste similară este şi cea a lui Bobby Voicu (Co-Fondator Mavenhut), care l-a întâlnit la How to Web pe Eoghan Jennings şi a plecat ulterior în Dublin la Startup Bootcamp.

Dacă unii pentru unii dintre participanţi How to Web a reprezentat paşaportul către acceeleratoare din întreaga lume, alţii

au obţinut finanţare pentru ideea lor. Este cazul băieţilor de la 123contactform, care l-au întâlnit pe Adrian Gheară şi au obţinut susţinerea lui, dar şi a celor de la Squirrly, care au obţinut investiţii de la Philip Kandal (CTO Skobbler) şi Ibrahim Evsan. Fie că obţii finanţare, că eşti admis la unele dintre cele mai importante programe de accelerare din lume, că te hotărăşti să porneşti la drum pe cont propriu sau că pleci inspirat şi încrezător în potenţialul tehnic din regiune, How to Web are un impact puternic asupra fiecărei persoane din audienţă.

Ediţia de anul acesta aduce şi alte noutăţi. De această dată va exista o separare foarte clară între zona antreprenorială şi zona de dezvoltare de produse tech. Dacă pe scena principală vorbitorii vor aborda subiecte care ţin de inovaţie şi dezvoltarea de produse tech la scară globală, cea de a doua scenă va aduce startup-urile în lumina reflectoarelor prin realizarea concursului Startup Spotlight. În acest an, cele mai bune 32 de echipe din regiune vor avea ocazia de a-şi prezenta produsul în faţa reprezentanţilor a 12 dintre cele mai importante acceleratoare de afaceri web din lume, printre care se numără GrowLab, Springboard, HackFwd, Rockstart sau Blackbox. Câştigătorii Startup Spotlight vor beneficia de premii în valoare totală de 20000$. În contextul unei pieţe regionale de dimensiuni reduse, How to Web înseamnă foarte mult, fiind principalul ambasador al unei comunităţi tehnologice aflate în formare. Actorii de pe piaţa regională mai au mult de învăţat, însă premisele dezvoltării unui ecosistem antreprenorial puternic au fost deja create. Până la atingerea acestui obiectiv, How to Web continuă să contecteze Europa de Sud-Est la inovaţia web globală.

startups

TODAY SOFTWARE MAGAZINE

Finanţare pentru startup-uri tech prin reţeaua de investitori Tech Angels

I

ndustria IT din Europa de Sud-Est este una emergentă, iar potenţialul şi talentul tehnic existent în zonă reprezintă premisele dezvoltării unui ecosistem antreprenorial puternic. În urmă cu puţin timp, startup-urile din regiune erau nevoite să se uite în afara graniţelor pentru a găsi investitori care să le finanţeze ideile. Din luna septembrie însă, reţeaua de investitori privaţi Tech Angels facilitează accesul la capital pentru antreprenorii în tehnologie.

TechAngels este o iniţiativă ce aparţine lui Radu Georgescu, Andrei Pitiş şi Bogdan Iordache. Antreprenor în serie şi investitor în companii de tehnologie şi internet, fondator al GECAD Group şi al companiile Epayment (acum PayU şi Avangate), Radu Georgescu a realizat până în prezent unele dintre cele mai importante exit-uri de pe piaţa tehnologică românească. „Facilitarea accesului la finanţarea de tip business angel este vitală pentru dezvoltarea noilor companii tehnologice din România. Ne dorim să sprijinim atât antreprenorii, înlesnindu-le accesul la fonduri şi expertiză, cât şi investitorii, punându-i în contact cu startup-uri”, spune Ragu Georgescu, Founding Partner & Chairman GECAD Group.

Andrei Pitiş este la rândul său investitor activ şi mentor în mai multe startup-uri, preşedinte al ANIS (Asociaţia Patronală a Industriei de Software şi Servicii) şi profesor asociat la Universitatea Politehnică din Bucureşti, cu o experienţă de peste 22 de ani în companii tech la toate nivelurile. „Experienţa mea profesională şi investiţională îmi spun că avem lângă noi profesionişti foarte talentaţi care merită susţinuţi”, a motivat Andrei Pitiş decizia de a pune bazele primei reţele de investitori privaţi din România.

Bogdan Iordache este antreprenor în serie şi a pus bazele stagiipebune.ro (cel mai mare portal de stagii de practică în IT din România), Conectoo (platformă de e-mail marketing). Bogdan este de asemenea Co-Fondator şi CEO al How to Web, cea mai importantă conferinţă despre antreprenoriat şi tehnologie din Europa de Sud-Est, şi mentor la mai multe acceleratoare de afaceri web din Europa printre care se numără Springboard Londra, HackFWD Berlin sau Rockstart Amsterdam. „În ultimii ani antreprenorii tech au fost finanţaţi mai mult de către investitorii europeni decât români. Tech Angels va facilita includerea de capital şi expertiză locală în afaceri globale”, a spus Bogdan Iordache, CEO How to Web.

Lansată în urmă cu mai puţin de două luni, reţeaua cuprinde în prezent 20 de antreprenori şi profesionişti din domeniul tech care completează investiţiile de natură pur financiară cu expertiză şi conexiuni relevante. Printre investitorii implicaţi în momentul actual se numără Lucian Todea (CEO ITNT, Soft32.com), Laurent Asscher (CEO Airtek Capital Group), Adrian Gheară (antreprenor serial, business angel şi consultant), sau Paul Maravei (business angel şi profesionist IT&C).

TechAngels va facilita realizarea de investiţii cu valoare cuprinsă între 10.000 şi 200.000 de euro corespondente unei evaluări a afacerii de maxim 1.000.000 de euro.

Reţeaua vizează în primul rând echipe cu expertiză dovedită şi un istoric profesional relevant, ale căror proiecte sunt dezvoltate cu precădere în domeniile web, mobile, embeded software, hardware sau meditech. Sunt preferate proiectele care au cel puţin un prototip sau care au fost validate de către clienţi.

Mecanismul de funcţionare este simplu. Primul pas este ca antreprenorii interesaţi să contacteze echipa Tech Angels prin intermediul formularului disponibil online. După o analiză completă a produsului sau afacerii, echipa TechAngels realizează alături de antreprenor o prezentare care este trimisă în reţeaua de investitori. Antreprenorii sunt ulterior puşi în legătură directă cu investitorii cărora le-au captat interesul şi vor primi asistenţă de la TechAngels pentru încheierea rundei de investiţii.

TechAngels reprezintă un pas important pentru dezvoltarea ecosistemului antreprenorial din Europa de Sud Est deoarece le ofera startup-urilor inovatoare finanţarea iniţială de care au nevoie pentru a se putea concentra pe dezvoltarea unui produs inovator, cu potenţial disruptiv la nivel global. Prin investiţii realizate,

TechAngels îşi propune să valorifice potenţialul existent în regiune şi să reprezinte o rampă de lansare pentru tinerii antreprenori talentaţi aflaţi la început de drum.

Bogdan Iordache

bogdan.iordache@howtoweb.co Bogdan Iordache este Co-Fondator al How to Web, cel mai important eveniment web din Europa de Est care abordeaza antreprenoriatul in tehnologie. Prima editie internationala a How to Web a castigat premiul IDG „Cel mai bun eveniment IT&C al anului din Romania”.

Licentiat in automatica si calculatoare la Universitatea Politehnica din Bucuresti si absolvent al unui program DEA la Université Lumiére din Lyon, Bogdan a dezvoltat stagiipebune.ro, cel mai complex program de internshipuri in IT din Romania, si Conectoo, platforma de email marketing.

www.todaysoftmag.ro | nr. 6/2012

7

noutăți

Made in România

I

naugurăm o nouă rubrică în revistă în care vom încerca să arătăm o parte din aplicațiile de succes ale companiilor autohtone.

Vom vedea companii care deși de succes în exterior nu sunt foarte cunoscute pe plan local, inițiative locale pentru sprinjinirea pieței de IT locale sau produse de foarte bună calitate lansate recent.

www.exosyphen.com

Hacker Evolution Duality Q: Descrieți produsul tocmai lansat Robert: Inception este un DLC (pachet de 10 nivele noi) lansat pentru ultimul nostru joc, Hacker Evolution Duality. Nivelele sunt cele din jocul original Hacker Evolution (lansat in 2007), portate pe noul motor de joc pentru a oferi o experiență diferita celor care au jucat jocul original. Momentan este disponibil exclusiv pe STEAM. Q: Descrieți tehnologiile folosite Robert: Jocul este dezvoltat pe un motor 2D dezvoltat in-house, care are la baza OpenGL, fiind disponibil pe Windows, Linux, MacOS si in curand iOS. Q: Descrieți principalele provocari care au apărut în dezvoltarea produsului și ce soluții ați găsit Robert: Principala provocare a fost să rescriem nivelele care au fost gândite pentru un motor de joc bazat pe consola de comenzi pentru a fi jucate pe un motor care este intensiv orientat GUI. Flexibilitatea jocului ne-a permis ca odată cu această portare să facem și un update masiv pentru jocul in sine, adăugând noi funcționalități.

Robert Mureșan

mrobert@exosyphen.com Technical Director, Exosyphen studios

Q: Câteva cuvinte despre companie Robert: Momentam compania are 5 angajați permanenți. Modelul nostru este să mergem pe o echipa compactă și foarte talentată. Mai există și oamenii cu care colaborăm periodic în funcție de necesități (muzica, branding, etc).

Q: Care este urmatorul produs la care vă gândiți să îl lansați ?

Robert: Momentan lucrăm la un motor 3D dezvoltat in-house pentru a aduce pe piață un joc complet nou, atât ca și tehnologie cât ca și gameplay. Este și primul proiect în care eu am renunțat să lucrez direct. Dezvolt în paralel un motor 3D cu scopul de a testa tehnologii noi și a le integra în jocul curent. Urmează să publicăm și niște documente despre research-ul care îl facem aici.

Despre Exosyphen

Este un studio de jocuri din Cluj-Napoca. Au fost vândute până acum aproximativ un milion de jocuri și peste zece milioane de utilizatori au folosit variantele gratuite ale acestora. Câteva din principalele lor realizări: • • •

8

nr. 6/2012 | www.todaysoftmag.ro

În 2002 a lansat primul joc comercial românsc, acesta fiind si prima versiune a simulatorului Hacker Evolution, La începutul lui 2004 a lansat primul joc 3D pentru dispozitive mobile, o portare Quake pe Windows Mobile, în 2010 jocul Hacker Evolution a fost publicat pe STEAM si a ajuns pe locul 4 în topul vanzarilor din acea perioadă. În total au fost vândute peste 200.000 de copii din această serie.

noutăți

www.zonga.ro

TODAY SOFTWARE MAGAZINE

Serviciul de muzică Zonga Q: Descrieți produsul tocmai lansat Călin: Zonga este serviciul de muzică lansat de Trilulilu, împreună cu Vodafone România. Practic este un serviciu pe bază de abonamet unde ai acces la muzică oficială de la casele de discuri locale și internaționale. Sunt peste 16 milioane de melodii pe care le poți asculta din browser, dintr-o aplicație de desktop sau de pe iPhone, Android sau smartphone-uri Nokia.

Pentru a folosi serviciul ai nevoie de internet însă utilizatorii premium au o opțiune specială de a asculta offline playlisturile create. Vodafone oferă două planuri speciale de abonament prin care ai trafic gratuit de pe mobil pentru Zonga. Dacă ești în rețeaua Vodafone poți încerca gratuit serviciul pentru trei luni. Mai multe detalii se găsesc pe pagina de abonamente http://www.zonga.ro/abonamente Q: Câteva cuvinte despre companie Călin: Compania care a dezvotlat Zonga este din Cluj-Napoca, iar echipa este formată din 20 de specialiști.

Q: Care este următorul produs pe care vă gândiți să îl lansați ?

Călin: În acest moment ne concentrăm pe Zonga și Trilulilu.

Călin Biriș

calin.biris@trilulilu.ro Călin Biriş este Crocodilul de Marketing la Trilulilu şi Preşedinte al IAA Young Professionals Cluj.

Pasionat fiind de mediul online şi de marketing, a ţinut zeci de prezentări despre publicitate online şi marketing, atât pentru studenţi cât şi pentru mediul de business. Este o persoană activă în mediul online pe blogul personal www.calinbiris.ro şi pe reţelele sociale.

Despre Trilulilu

Trilulilu este cea mai mare comunitate online din Romania, unde vizitatorii pot urmări şi contribui cu clipuri video, audio şi imagini. Trilulilu a fost lansat în ianuarie 2007, fiind în prezent cel mai vizitat site romanesc de divertisment, conform SATI. În acest moment, trilulilu.ro are peste 2.2 milioane de vizitatori unici lunar.

Hacker Evolution Duality

Serviciul de muzică românesc Zonga www.todaysoftmag.ro | nr. 6/2012

9

istorie

Istoria IT-ului Clujean

A

Marius Mornea

marius.mornea@todaysoftmag.com Fost senior software developer in cadrul Nokia, în prezent fondatorul platformei Mintaka Research

10

nr. 6/2012 | www.todaysoftmag.ro

început simplu, cu o singură întrebare, dar aceasta a dat naștere în zilele imediat următoare unor șiruri întregi de întrebări care au trezit curiozitatea, nu doar a mea, dar și a tuturor celor pe care testam noua idee. Întrebarea inițială a fost formulată de Răzvan Florian, iar contextul în care a apărut este următorul: stăteam unul lângă altul la o întâlnire regioNet cu numele “Clustere și rețele – Motoare ale dezvoltării pentru creșterea competitivității și a capacității de inovare”.

Imediat după prezentarea stadiului orașe vecine? Cum am ajuns fiecare din curent al cluster-ului IT din Cluj (30 de noi să lucrăm în IT? firme înscrise, cumulând 3500 de angajați Apoi am început să testez ideea pe și o cifră de afaceri de 8 milioane de alți oameni, care în loc de răspunsuri Euro), a luat cuvântul domnul profesor îmi puneau mai multe întrebări: Cine Sergiu Nedevschi. Înainte de a trece la este Tiberiu Popoviciu ? Iar spre rușinea prezentarea activității științifice a labora- mea, absolvent al liceului care îi poartă torului pe care îl conduce, a ținut o mică numele, tot ce am putut sa zic este că lecție de istorie începând cu înființarea a fost un matematician, fără să pot să unei ramuri a Academiei Române la Cluj explic clar și argumentat legătura lui cu în anii 1950, continuând cu construirea domeniul informaticii; Cum au evoluat primelor calculatoare, a unuia dintre demografic generațiile de profesioniști primele compilatoare de Fortran și așa IT? Ce alte domenii au fost influențate de mai departe până la concluzia finală că IT? A generat IT-ul clujean premiere în aceștia sunt factorii determinanți pentru domeniu? Care sunt metricile potrivite starea curenta a IT-ului clujean. În acest pentru comunitatea locală? Producția moment Răzvan se întoarce spre mine și de Proprietate Intelectuala este o metrică mă întreabă de ce nu scriem despre asa semnificativă? ceva: Care este istoria IT-ului clujean?

Deodată cu aceste întrebări s-au conPrima reacție a fost similară celei turat și diferitele perspective din care resimțită de fiecare dată la auzul sintag- priveau interlocutorii mei subiectul: unii mei “Clujul, Silicon Valley-ul României”, erau animați de curiozitate și amuzament, o ușoara neîncredere și nevoia puternică cautând o lectură plăcută; alții interesați de dovezi și argumente care să susțină de aspectele economice și oportunitățile această comparație. Simțeam nevoia unei născute de un studiu detaliat al stării raportări ale realizărilor IT-ului local, curente; alții cuprinși de melancolie, la stadiul național și internațional, pen- în amintirea unor vremuri trecute. Am tru a justifica importanța și nevoia unui hotărât să explorez aceste perspective și articol. A doua zi mi-am dat seama că să încerc să răspund întrebărilor de mai relevanța acestei raportări este minimă, sus în cadrul unui nou proiect: Istoria dar evoluția și eventuale comparări ar fi IT-ului Clujean – de la 1957 până azi. totuși un subiect interesant. Așa au înce- Mai concret o serie de articole și evenput să apară întrebările: tual ediții speciale dedicate întrebărilor Cine a introdus IT-ul în Cluj? În ce de mai sus, interviurilor cu personalități scop? În ce circumstanțe? Cum a ajuns să actuale sau istorice dar și perspectivei crească la nivelul actual? Care este nive- personale: eu cred că există o comunitate lul actual? Este adevărat că, atât numărul, IT la Cluj care a dovedit în nenumărate cât și contribuția la bugetul local al rânduri că a ajuns la o masă critică ce angajaților din IT reprezintă o majori- naște nevoia unei identități comune. Ori tate? Cum au luat decizia antreprenorii, această identitate se definește prin răsimediat după revoluție să înceapă afaceri punsurile întrebărilor: Cine suntem? și de în acest domeniu? Cine le-a fost men- unde venim? Abia apoi putem răspunde tor sau inspirație? Cine a pregătit tehnic întrebărilor: Unde vrem sa ajungem? și generațiile actuale de profesioniști în cum? domeniu ? Cine a introdus aceste materii Aștept ajutorul vostru pentru a răsîn curriculum universitar? De ce la Cluj punde întrebărilor de mai sus. exista această proporție mare și nu în alte

arhitectură

TODAY SOFTWARE MAGAZINE

Comunităţi IT Cluj-Napoca

S

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

Criteriul ales pentru ordonare este numărul de membri şi activitatea grupurilor concretizată în evenimente locale. Astfel obţinem o ierarhie a gradul de implicare, al organizatorilor şi al membrilor acestora.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

Website: http://www.transylvania-jug.org/ Data înfiinţării: 15.05.2008 / Nr. Membri: 504 / Nr. Evenimente: 39 Romanian Testing Community Comunitate dedicată QA. Website: http://www.romaniatesting.ro Data înfiinţării: 10.05.2011 / Nr. Membri: 536 / Nr. Evenimente: 1 Cluj.rb Comunitate dedicată tehnologiilor Ruby.

Website: http://www.meetup.com/cluj-rb/ Data înfiinţării: 25.08.2010 / Nr. Membri: 127 / Nr. Evenimente: 30

Calendar Noiembrie 9

Artificial Intelligence, Computational Game Theory, and Decision Theory - Unifying paths Contact: workshop2012@rist.ro

Noiembrie 17

Open Agile Cluj 2012 Contact: http://cluj2012.openagile.ro/

Noiembrie 22

Lightning Talks Contact: http://www.transylvania-jug.org/

The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software.

Website: http://www.agileworks.ro Data înfiinţării: 04.10.2010 / Nr. Membri: 249 / Nr. Evenimente: 13

Decembrie 8

Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice.

Website: http://www.meetup.com/Cluj-Semantic-WEB/ Data înfiinţării: 08.05.2010 / Nr. Membri: 132/ Nr. Evenimente: 19

Decembrie 11

Romanian Association for Better Software Comunitate dedicata oamenilor cu experienta din IT indiferent de tehnologie sau specializare.

Website: http://www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 181/ Nr. Evenimente: 10

Global Day of Coderetreat 2012 Contact: http://coderetreat.org/events/global-day-of-coderetreat-2012-cluj-napoca-romania Socialization Meetup Contact: http://www.meetup.com/Cluj-Semantic-WEB/ Google Technology User Group Cluj-Napoca Comunitate dedicată tehnologiilor Google.

Website: http://cluj-napoca.gtug.ro/ Data înfiinţării: 10.12.2011 / Nr. Membri: 30 / Nr. Evenimente: 7

Cluj Mobile Developers Comunitatea TSM Comunitate dedicată tehnologiilor mobile.

Comunitate construita in jurul revistei Today Software Magazine. Website: http://www.meetup.com/Cluj-Mobile-Developers/ Website: http://www.todaysoftmag.ro Data înfiinţării: 08.05.2011 / Nr. Membri: 54 / Nr. Evenimente: 3 Data înfiinţării: 06.02.2012 / Nr. Membri: 263 / Nr. Evenimente: 3 Menţiuni: Cluj Perl Mongers (www.cluj.pm), GeekMeet Tabara de testare (http://geekmeet.ro/), ITSpark (http://itspark.ro/default.aspx), Comunitate dedicată QA. CodeCamp (http://www.codecamp.ro/), CodExpert (http:// Website: http://www.meetup.com/Tabara-de-Testare-Cluj/ www.codexpert.ro/), PHPRomania (http://www.phpromania.

Data înfiinţării: 15.01.2012 / Nr. Membri: 100 / Nr. Evenimente: 7 net/), ARIES (http://www.aries.ro/)

www.todaysoftmag.ro | nr. 6/2012

11

arhitectură

Arhitectură pentru Flexibilitate (Quality Attribute)

C

onform definiției, flexibilitatea reprezintă capacitatea unui sistem de a se adapta la diferite medii și situații pentru a face față schimbărilor ce apar în politicile și regulile aferente mediului de afaceri. În ziua de azi regăsim acest atribut de calitate în orice business și din acest motiv îi este foarte probabilă prezența și în cerințele clientilor pentru proiectul ce urmeaza a fi dezvoltat. În articolul ce urmează voi dezvolta câteva idei despre acest topic, flexibilitatea, și despre impactul pe care îl are asupra proceselor de arhitectură și development.

Attila Antal

Attila.Antal@isdc.eu Software Arhitect @ ISDC are o experiență de peste 16 ani în domeniul IT, ultimii 3 ani dedicându-i în special arhitecturii software.

Paleta proiectelor în care s-a implicat e largă și foarte variată, domeniul principal fiind Java dar și iOS și Android.

Membru fondator RABS (http:// www.rabs.ro/) și autorul ideii „Crosscutting Architectural Concerns” prezentat prima dată in primăvara anului asta în cadrul acestei asociații.

Quality Attributes

Quality Attribute este o caracteristică sau o calitate non-funcțională (în unele cazuri și funcțională) a unei componente sau a sistemului. Pe scurt aceste atribute se mai numesc și ”ilities”, pentru că în majoritatea cazurilor denumirea lor include sufixul “ility”: maintenability, accessibility, etc.

Din păcate există mai multe standarde pentru aceste atribute (IEEEE 1061, ISO/ IEC 9126-1) care denumesc aceeași calitate prin diferiți termeni, creând astfel ințelegeri diferite sau uneori confuzii.

Articolul nostru va trata cazul în care cerințele din partea clientului se focusează pe flexibilitate cu statutul de calitate.

Tăișul cuțitului

In faza de fundamentare a proiectului, arhitectul software poartă diferite discuții cu părțile implicate (stakeholders) ca să-și clarifice cât mai bine cerintele legate de proiect. De obicei cerintele enumeră diferite ”ilities” fără a argumenta decizia.

Arhitectul trebuie să facă o analiză de compromis tocmai pentru a argumenta și în aceeași timp a filtra lista de ”ilities”.

Pe de altă parte, un aspect important de considerat în procesul de decizie e legat și de strategia companiei din perspectiva

12

nr. 6/2012 | www.todaysoftmag.ro

diferitelor domenii (dezvoltare, operational, etc.) și a proceselor (development, arhitectură, calitate, etc.). Arhitectul trebuie să vadă aceste strategii prin prisma Quality Attributes și să le aibă în vedere în timpul procesului de analiză de compromis.

Agile

Majoritatea companiilor de dezvoltare software folosesc metodologii agile. Dacă ne uităm la definiția acestei metodologii vom vedea ca e vorba exact depre o flexibilitate în procesul de development. Acum se poate striga sus si tare: “Dar ce are de-a face asta cu arhitectura?” Bine, în mod direct nu are prea multe, dar are o influență puternica fiindcă flexibilitatea și răspunsul rapid la schimbări este posibil doar dacă mediul de dezvoltare, structura proiectului (module), infrastructura, SCM-ul, release management-ul sunt si ele la randul lor flexibile. Toate astea sunt în legatură cu deciziile luate de un software arhitect.

Analiză de impact

După ce arhitectul are lista conceptelor, strategiilor, metodologiilor care vor fi prezente in proiect și au legatură cu flexibilitatea, urmează o altă analiză în care flexibilitatea drept calitate se pune cap la cap cu celălalte calități așa cum este arătat în tabela Tabelul 1. Am folosit doar acele calități care sunt cele mai des folosite extras din ultimul ITABoK de la IASA. Acele atribute care vor fi favorizate de flexibilitate vor primi un semn ”+” și cele care

TODAY SOFTWARE MAGAZINE

reutilizabile, control și orchestrație.

Arhitectura core-ului

Cel mai important prim pas în definirea unei arhitecturi este selectarea tipurilor de comunicare. Tabelul 2 de mai jos enumeră tipurile de comunicare cele mai frecvente dintr-un sistem. Rândurile evidențiate cu fundal gri sunt cele care sunt binevenite în orice sistem.

Trebuie să observați că orice tip de comunicare are părțile ei negative și pozitive. Tocmai de aceea nu este o decizie inteligentă să avem în sistem numai un singur tip de comunicare, arhitectul trebuie să decidă ce alege pentru anumite pluginuri, întărind astfel alte calități ca securitate, performanță etc.. Pentru a vizualiza cât mai bine rolul și funcția unui core, am pregătit o diagramă Figura 3 care arată o aplicație model și evidențiază sarcinile acestuia.

Tabelul 1 vor fi impactate vor primi un semn ”-”. În conceptual. Putem observa că nu toate cazul nostru putem observa cum calitățiile funcționalitățille pot fi extrase în plugin de Extensibilitate și de Performanță sunt acestea vor rămâne în core. Fiecare plugin afectate negativ de Flexibilitate. În cazul comunică cu core și unele se izolează comimpactului de performanță sunt destule plet de alte sisteme. Aplicatia core trebuie sa măsurători prin care se pot explica riscu- aibă o fațadă pentru fiecare plugin. Aceste rile și de multe ori acestea sunt acceptate fațade pot să aibă interfețe și prin asta se de client . poate face public accesul la plugin. În cazul extensibilității trebuie să avem După ce studiem atent Figura 2, putem documentat (și predat la client) riscul și să observăm că un plugin poate să existe eventual diminuarea riscului dacă structura și cerintele proiectului permit acest lucru. Tabele de genul celei de mai sus sunt atuuri foarte valoroase în analiza de Utilități compromis și în negocierea calităților care E de menționat faptul că acest context al trebuie să fie prezente (sau nu) în proiect. aplicației trebuie să aibă tot timpul funcții sau utilitare de core cum ar fi de exemplu: Plugin ca și pattern arhitectural ■■ tratarea fișierelor de proprietăți Diminuarea riscului față de extensi■■ logare centrală bilitate este posibilă și prin alegerea unui Figura 1 ■■ auditarea diferitelor evenimente pattern arhitectural inteligent. Sistemele ■■ persistarea datelor in baza de date bazate pe plugin-uri permit extensibilitatea complet izolat (de exemplu un encoder/ ■■ manipularea tranzacțiilor exact prin flexibilitatea lor, prin metoda decoder) sau poate fi folosit ca un agent Aplicația core este și ea la randul sau un de grupare a funcționalităților în plu- de comunicare schimbând mesaje cu alte consumator al acestor utilități. gin-uri. În cazul in care avem nevoie de o sisteme. funționalitate extinsă se schimbă un plugin Avantajul la acest sistem este că anumite Orchestrare cu celalalt sau se adaugă altele. funcționalități bine plasate in pluginuri pot O foarte importantă funcționalitate Figura 1 arată un sistem non-flexi- fi reutilizate, moment in care arhitectul tre- a core-ului este de a orchestra comporbil, monolitic sau monolitic core la nivel buie să aibă influență asupra procesului de tamentul pluginurilor. Înțelegem prin conceptual. O schimbare oricat de mică development. aceasta controlul de lansare sau de scoatere la oricare funcționalitate aduce după sine Succesul la sistemele cu plugin-uri din funcțiune a unui plugin și manipularetestarea și relansarea intregului sistem. este în a defini foarte clar comunicarea rea diferitelor tipuri de evenimente de alte Figura 2 arată un sistem flexibil la nivel intre core și plugin-uri, a folosi plugin-uri feluri.

Communicare

Aplicatia core trebuie să aibă implementate toate tipurile de comunicare care vor fi folosite in context. Este și mai bine dacă arhitectul cercetează viitorul aplicației și anticipat pregătește core-ul, pentru că în felul acesta să știe și mai multe decât ceea ce solicită clientul, deoarece modificările ulterioare în core aduc după sine relansarea întregii aplicații și scoaterea ei din timpul de execuție, lucru care afectează businessul clientului.

Figura 2

Micro-arhitectură în plugin

Părerea mea este că un plugin trebuie

www.todaysoftmag.ro | nr. 6/2012

13

arhitectură

Arhitectură pentru Flexibilitate

văzut tot timpul ca un black box. Primește stimuli și creează răspunsul după funcția implementată. Fiecare plugin trebuie să aibă arhitectura sa, vezi figura Figura 4.

Comportamentul pluginului este monitorizat prin sistemul de orchestrare a core-ului, el are acces la utilitățiile con-

Tabelul 2

Figura 4 textului aplicației. Plugin-ul de obicei are numai o singură metodă de comunicare cu core pentru a păstra simplitatea integrării.

Sumar

Scopul acestui articol a fost de a vă ghida printr-un flow al deciziilor și al argumentelor prin care software arhitectul poate să sintetizeze o soluție bazată pe atributul de calitate numit flexibilitate.

S-a început cu paralela dintre cerintele clientului proiectat în Quality Attributes și strategiile companiei. A urmat analiza de compromis prin care am observat impactul cu extensibilitate ca fiind principalul argument pentru folosirea pattern-ului de plugin. La final s-a detaliat arhitectura unui sistem bazat pe plugin-uri.

Figura 3

WE HIRE

IN GOOD COMPANY PROJECT MANAGER

.NET DEVELOPERS JAVA DEVELOPERS JAVA ARCHITECT .NET ARCHITECT

ISDC.EU/CAREERS

14

nr. 6/2012 | www.todaysoftmag.ro

WE DO PROJECTS

OUR CUSTOMERS

ISDC

WITH IMPACT. WE

ARE IMPRESSED

ENGINEERS

DELIVER RESULTS,

BY OUR AWESOME

YOUR

NOT RESOURCES.

TECH TEAMS.

DREAMS!

RALUCA HIREME @ISDC.EU

SIMONA HELLO @ISDC.EU

programare

TODAY SOFTWARE MAGAZINE

Tehnici SEO interne partea a II-a

V

om continua, în acest număr, cele descrise în articolul precedent unde vorbeam despre câteva din cele mai importante tehnici de SEO intern. În această a doua parte vom vorbi despre modul cum ne poate ajuta o interfaţă creată cu HTML5, despre blocarea paginilor cu un conţinut slab şi despre link-uri. Sperăm că cele două părţi vor crea un mic ghid SEO care să poată fi aplicat de orice proprietar de site pentru îmbunătăţirea rank-ului în rezultatele motoarelor de căutare.

Radu Popescu

rpopescu@smallfootprint.com QA şi Web designer @ Small Footprint

Robots.txt vs meta robots

Precum cum spuneam în numerele trecute, actualizarea Panda penalizează chiar şi site-urile care au doar câteva pagini cu un conţinut slab. Pentru a nu fi afectaţi de acest lucru, va trebui să blocăm de la indexare paginile care nu respectă cerinţele de calitate ale Google. Pentru a face acest lucru există două metode, fie folosim fişierul robots.txt în care adăugăm pe fiecare linie locaţia relativă către un anumit fişier sau folder, fie adăugăm în fişierul vizat meta tagul robots. Diferenţa dintre robots.txt şi meta tagul robots este aceea că fişierul nu blochează cu adevărat de la indexare fişierele menţionate în interiorul său. Acestea sunt indexate de către Google, dar nu apar în căutări. Prin urmare, cea mai bună metodă de a bloca indexarea unei pagini este prin meta tagul robots: <meta name=”robots” content=”noindex, nofollow”>

Cel mai indicat lucru este să folosim fişierul robots pentru a bloca foldere întregi (de exemplu, un folder care conţine fişiere de configurare sau imagini cu layout-ul sitului), iar meta tagul robots este indicat să-l folosim pentru a bloca fişiere de tip HTML. Ca să întelegem mai bine rolul meta robots, putem observa studiul de caz realizat de Johannes Beus în care prezenta o

listă cu 25 de situri afectate de faptul că aveau indexate foarte mute pagini cu un conţinut de slabă calitate. După actualizarea Panda, acest lucru a fost dezastuos.

Ezinearticles.com şi FAQS.org au avut o scădere a traficului organic de peste 30%, iar suite101.com de peste 40%. Scăderea traficului a atras după sine şi o scădere a veniturilor din publicitate.

HTML5 layout

Am vorbit în numerele trecute despre modul în care motoarele de căutare percep anumite tag-uri HTML, ce pentru noi oamenii par identice (bold sau strong).

Spuneam atunci că diferenţa stă în valoarea semantică pe care acestea o oferă. HTML5 vine cu o serie de tag-uri pentru organizarea conţinutului. Printre cele mai folosite tag-uri semantice în contrucţia unei interfeţe sunt: <header>, <nav> (meniu, navigare), <footer>, <section>, <article>, <aside>. Pentru a înţelege mai bine modul

Figura 1 www.todaysoftmag.ro | nr. 6/2012

15

programare Tehnici SEO interne - partea a II-a de utilizare, în Figura 1 am creat o interfaţă folosind numai aceste tag-uri.

Tag-urile semantice ajută la o parsare mai rapidă a codului sursă şi oferă informaţii foarte utile motoarelor de căutare despre conţinut. Spre exemplu, în zonele <nav> sau <footer> se vor găsi link-uri interne care ajută la indexarea paginilor pe când în zona <aside> vor fi prezente unele bannere sau reclame ce nu au o importanţă foarte mare pentru vizitator.

Anumite versiuni mai vechi ale browser-elor nu suportă aceste tag-uri.

Există totuşi o metodă prin care putem să ne bucurăm de o interfaţă HTML5 chiar şi pe Internet Explorer 6 de exemplu, adăugând următorul script în zona <head>: <script> document.createElement(„header”); document.createElement(„footer”); document.createElement(„article”); document.createElement(„section”); document.createElement(„nav”); document.createElement(„aside”); </script>

Folosirea adreselor canonice

Adresa canonică reprezintă acea adresă care este preferată, în dauna altora care au un conţinut identic. Pentru a întelege mai bine acest concept, vom lua un exemplu: să spunem că avem o pagină care ne arată câteva laptopuri (ex. www.site.ro/laptopuri). În acelaşi timp, produsele de pe acea pagină se pot sorta, după preţ, de la cel mai mic la cel mai mare (ex. www.site.ro/ laptopuri?sort=price&type=asc). De asemenea se pot sorta şi după nume (ex. www. site.ro/laptopuri?sort=name&type=asc) sau după alte criterii. Toate aceste URLuri reprezintă în viziunea Google pagini diferite (care au acelaşi conţinut). Pentru a evita indexarea tuturor acestor pagini (lucru ce poate să fie văzut ca spam) şi pentru a nu împărţi beneficiile link-building-ului, trebuie să avem o adresă unică (canonică) şi anume www.site.ro/laptopuri.

Pentru a declara o adresă canonică, trebuie să introducem în zona de <head> a paginii următorul cod: <link rel=”canonical” href=”http://www.site.ro/laptopuri”/>

Optimizarea ancorelor link-urilor

În primul rând trebuie să înţelegem ce este o ancoră. Ancora unui link reprezintă textul (pe care se poate face click) acelui link. Ea influenţează foarte mult rata de click şi oferă informaţii preţioase motoarelor de căutare, despre subiectul care se găseşte la capătul respectivului link.

Este bine să evităm ancorele de tipul “aici”, ”site” sau “download” şi să folosim

16

nr. 6/2012 | www.todaysoftmag.ro

ancore cât mai descriptive. Spre exemplu, dacă cineva doreşte să adauge un link către un articol foarte bun, despre neuromarketing, de pe situl nostru, şi va folosi ancora “aici” (în contextul: “un articol pe această temă poate să fie găsit aici”) nu vor fi generate la fel de multe clickuri precum în cazul folosirii unei ancore mai descriptive de tipul “efectele neuromaketingului în publicitate”.

Un alt lucru foarte important de ştiut este că atunci când avem două ancore diferite, care au acelaşi link, într-o singură pagină, contează doar prima dintre ele. În exemplul de mai jos, deşi a doua ancoră e mai descriptivă, ea nu este luată în considerare.

SEOMoz.com, a realizat un experiment folosind trei domenii noi spre care a trimis câte zece link-uri externe. Pentru primul domeniu, link-urile aveau ancora „click here”, pentru al doilea aveau o ancora de tip exact-match (cuvânt cheie principal),

fi accesate de pe pagina principală, prin link-uri succesive. Pentru a profita la maximum de puterea link-urilor interne trebuie să ţinem cont de câteva lucruri esenţiale: • Cu orice preţ trebuie evitate linkurile interne din JavaScript sau Flash, pentru că acestea nu pot să fie parsate de către motoarele de căutare (în foarte multe cazuri).

• Link-urile interne către pagini blocate prin meta robots sau robots. txt, trebuie să conţină atributul rel=”nofollow”.

• Trebuie să ne asigurăm că nu avem link-uri interne către o anumită pagină, doar din rezultatele unui motor de căutare intern. Google nu va executa căutări pe situri, pentru a descoperi pagini noi, ci se va baza pe link-urile interne şi sitemap-ul XML despre care am vorbit în numărul trecut.

• Nu trebuie să abuzăm de aceste lnkuri interne. Motoarele de căutare pot accesa un număr maxim de 150200 de link-uri. Prin urmare, sunt de evitat paginile de tip sitemap, pentru site-urile care au mai mult de 150 de pagini.

De amintit aici este cazul sitului NorthPole.com, care este în acest moment pe locul 2 în rezultatele căutării cuvantului „santa”. Situl a reuşit această performanţă datorită numarului mare de pagini indeFigura 2 xate în Google şi link-urilor interne între acestea. Fiecare pagină conţine cateva zeci iar pentru al treilea avea mai multe ancore de link-uri către alte pagini de pe acelaşi de tip partial-match (cuvinte cheie secun- domeniu, creând astfel o retea internă dare). Rezultatele au fost surprinzătoare. solidă. În primele trei zile, situl care avea link-uri externe ce foloseau ancora „click here” a Atributul ALT detinut prima poziţie în căutări. Dupa cele De foarte multe ori este trecut cu vede3 zile, acesta a dispărut din SERPS şi au rea faptul că şi imaginile au nevoie de apărut celelalte două pe poziţiile 1 şi 2. optimizare SEO. Atributul ALT este folosit în interiorul tag-ului <img> şi are rolul de a Link-urile interne şi rolul lor oferi informaţii despre conţinutul imaginii.

De asemenea link-urile interne au un Din cauza faptului că motoarele de căutare rol foarte mare în SEO, nu doar cele venite parseaza codul sursă şi nu pot să înţeleagă din exterior. Dacă ne gândim la modul, imaginile, avem nevoie să le oferim inforstandardizat oarecum, în care sunt con- maţii cât mai detaliate despre acestea. Pe struite astăzi site-urile, vom observa că lângă numele imaginii, atributul ALT ajută dintodeauna în partea de jos avem o mul- la indexarea şi afişarea imaginilor dintr-un ţime de link-uri interne. Ei bine, aceste site în rezultatele căutarilor. link-uri interne din footer au ajutat mereu Un alt rol foarte important al acesatât din punct de vedere al SEO cât şi al tui atribut constă în aceea că valoarea din usability. Ele creează o ierarhie a paginilor interiorul său este afişată în cazul în care nu din site şi transmit o parte din autoritatea se va putea afişa imaginea din cauza unor acestora (link juice) celor apropiate. probleme din cod sau a unei surse greşite.

Trebuie să ne asigurăm că nu există Atributul ALT este foarte util şi în cazul pagini (pe care le vrem indexate) ce nu pot celor care folosesc browsere text-based,

programare

TODAY SOFTWARE MAGAZINE

ei neputând vizualiza imagini. Adăugarea unei descrieri a imaginii în atributul ALT iar nu a unor înşiruiri de cuvinte cheie va avea cele mai bune rezultate. Pe lângă acest lucru, este recomandat ca imaginile să aibă un nume descriptiv, iar cuvintele din el să fie despărţite prin cratimă.

Un exemplu foarte bun, este al sitului Jeromes.com care comercializează mobilier. Lipsa unui conţinut cuprinzător şi interesant, de tip text, a făcut ca situl să nu prezinte un interes foarte mare pentru motoarele de căutare. Nu exista destul conţinut pentru a putea fi relevant în căutări. Partea bună este că avea foarte multe imagini. Prin adaugarea atribulului ALT imaginilor, au reuşit să crească traficul organic. Au avut o creştere de 1400% a traficului venit pe pe Google Images.

Concluzii

Tehnicile de SEO intern stau în mâna proprietarului sitului. Prin urmare ele sunt de multe ori trecute cu vederea. Trebuie să întelegem că în optimizarea pentru motoarele de căutare, fiecare acţiune, oricât de mică, poate influenţa rank-ul. Este imposibil să influenţăm unele elemente externe, precum vârsta domeniului sau factorul de încredere astfel încât să avem rezultate bune într-un timp relativ scurt. În acelaşi timp ne este foarte uşor să folosim tehnicile SEO interne, asupra cărora avem control pentru a creşte poziţia în SERPS. Nu trebuie să uităm că algoritmii motoarelor de căutare sunt într-o continuă schimbare. Google este atent la fiecare mişcare a noastră în online şi vede modul cum folosim aceste tehnici de optimizare.

De multe ori, anumite persoane le folosesc într-un mod abuziv, iar motoarele de căutare ajustează algoritmii pentru a nu le ma oferi beneficii. Din păcate, acest lucru însemnă că nu ne vor mai oferi beneficii pentru motoarele de căutare necesită o nici nouă, celor care folosim SEO într-un atenţie constantă şi o muncă susţinută. mod corect. Din această cauză, optimizarea

www.todaysoftmag.ro | nr. 6/2012

17

diverse

10 principii de design (fabulă)

D

upă ce oamenii s-au plictisit să se joace cu dinozaurii (dar şi pentru că aceştia au dispărut la un moment dat “goniţi” de un meteorit) au încercat să-şi găsească diverse alte preocupări: unii s-au dus sa vâneze pinguini, alţii au downloadat primul Starcraft (pentru că ultimul încă nu era finalizat - de fapt “ultimul” nu va fi finalizat niciodată!), iar restul erau nerăbdători să se distreze cu zebre. Răbdarea lor urma să fie pusă la grea încercare deoarece nu exista nici o zebră :-(. Zebrele nici măcar nu fuseseră inventate.

Stefan Baritchii

stefan.baritchii@3pillarglobal.com Technical Lead @ 3Pillar Global Romania

1. Şi pentru că toată lumea voia să înţeleagă ce este o zebră, s-au dus să-l întrebe pe bătrânul satului, care le-a zis că toate aceste informaţii pot fi găsite într-un document de specificare funcţională. ( În această secţiune se povesteşte despre cum trebuie scris un document de specificare funcţională util pentru a explica ce este o

zebră şi de ce este ea necesară. ) Bătrânul satului era un guru şi un guru cunoaşte totul. Gândeşte-te la un guru ca la o versiune îmbunătăţită a lui Chuck Norris.

El este singurul din sat care stie cum arată o zebră. De asemenea, el ştie câtă iarbă va mânca o zebră. Zebrelor le place iarba, prin urmare sunt foarte lacome când vine vorba despre asta. Un guru știe câte zebre trebuie să vadă lumina zilei, care sunt primele care trebuie concepute, şi ce e mai important pentru această secţiune – cum arată o zebră.

18

nr. 6/2012 | www.todaysoftmag.ro

Tăcerea înseamnă înțelepciune şi se zice că un guru deţine asa ceva din belșug.

Prin urmare, pentru a-l face să vorbească el trebuie să fie întrebat. Întrebarile corecte sunt întrebări normale care ne-ar ajuta să facem o zebră adevărată. Pentru a specifica ce este aceea o zebră trebuie să întrebi guru:

“CE ÎNSEAMNĂ... o zebră?”

La o astfel de întrebare vei primi răspunsuri de genul: “este un animal colorat în alb şi negru”. Dar pentru daltonisti, de exemplu, acest răspuns nu este suficient.

Chiar şi o parte din cei care nu sunt daltonişti şi-ar putea imagina că trebuie să facă un panda.

Când guru a auzit chestia asta și-a reformulat răspunsul: “În nici un caz.

Panda e panda şi zebra e zebră. O zebră trebuie să arate mai mult a... cal, un cal dungat în alb şi negru”. Dar de aici au apărut alte întrebari: “Ce înseamnă o dungă?”, “Ce inseamna alb?”, “Ce inseamna negru?”... si pentru numele lui Dumnezeu, “CE E UN CAL”? Presupunând că la un moment dat sumerienii au (re?-)inventat scrisul, toate răspunsurile au fost consemnate în ceva numit document de specificare funcțională.

Un document de specificare functională conţine răspunsurile care definesc entităţile proiectului şi trebuie explicate în aşa fel încât să fie înţelese de toată lumea din echipa de proiect. Și tocmai când toți credeau că au un document de specificare funcţională complet, cineva a întrebat:

management

“DE CE AVEM NEVOIE DE... o zebră?”

În caz că vă puneţi problema: da, este o întrebare foarte pertinentă care ar trebui să-şi găsească răspunsul într-un document de specificare funcțională. Având răspunsul la această întrebare, viaţa zebrei are un scop. Zebra va şti ce problemă rezolvă şi cum se încadrează în sălbăticie (veți auzi mai des termenul de “context”). Ştiind care este problema, vom putea refolosi aceeaşi soluţie în caz că apare o problema asemănătoare, sau cel putin ne putem inspira. Şi totuşi documentul nu este complet fără o idee despre performanţele zebrei:

“CÂT DE PERFORMANTĂ vrei să fie zebra?”

Înainte să te gândeşti că zebra ar trebui să aibă un singur picior, gândește-te că trebuie să fie în stare să scape de lei. Intrebarea este: cât de rapid vrei să fugă zebra? ( Care sunt premisele pentru a construi un soft în aşa fel încât să îşi atingă performanţele?

Răspunsul la această întrebare TREBUIE să fie într-un document de specificare funcțională, pentru că în viaţa reală există şi clienţi care semnează SLA – Service Level Agrrement – iar dacă performanţa nu este considerată a fi parte din design, poate costa mult mai mult clientul după ce produsul este gata ).

2. Şi pentru că i-au zis zebră, şi pentru că fiecare iubea numele atât de mult dânduşi seama imediat la ce se referă ceilalţi când spun acest nume, au decis că numele semnificative joacă un rol important. ( În această secţiune vorbim despre

TODAY SOFTWARE MAGAZINE

variabile, atribute, nume de clase, nume de pachete, nume de servicii şi nume de metode care corespund comportamentului unei zebre. ) Când te gândeşti la un nume pentru ceva, trebuie să te gândeşti la cum ai descrie acel ceva într-un singur cuvânt. Doar atât.

Daca cineva arată un animal dungat şi te intreabă: “Ce este asta?” vei raspunde: este o zebră. Este atât de intuitiv că doar un singur cuvânt iţi vine în minte. Este atât de intuitiv încât cel care te-a întrebat se gândeste exact la acelaşi cuvânt fără să-ţi zică.

Aşadar, când alegi un nume încearcă urmatorul joc: întreaba pe cineva “Ce este chestia asta?” şi gândeşte-te la un cuvânt care descrie acel lucru. Dacă răspundeţi amândoi acelaşi cuvânt (sau dacâ nu te gândeai chiar la acelaşi cuvânt, dar versiunea ceiluilalt pare mai bună şi trişezi puţin zicând că te-ai gândit totuşi la cuvântul lui), atunci acela este numele pe care il cauţi!

Jocul asta poate fi aplicat la variabile, atribute, clase sau nume de pachete.

Lucrurilor ce corespund unei acţiuni le asociem altă intrebare. Un nume de metodă este o acţiune şi prin urmare când vorbeşti despre zebre te întrebi: “Ce fac zebrele?” iar raspunsul poate fi: aleargă, halesc, seJoacă, morDeFoame, sePlictisesc... Toate verbele scrise inclinat sunt nume de metode valide. (evident, clienţii vor aprecia foarte mult dacă scrieţi aceste răspunsuri în engleză. Şi foarte probabil ca şi colegii vostri.).

Când este vorba de servicii aplicaţi aceleaşi reguli. Un serviciu este de fapt o clasă care îşi expune acţiunile prin metode. Ce intrebări pui pentru a stabili numele atunci

când vrei faci un serviciu şi acţiunile lui aferente?

3. Şi pentru că oamenii erau atât de dornici să ajute să creeze o zebră, au decis să păstreze lucrurile simple şi clare pentru a realiza rapid ceea ce voiau. (În această secţiune se povesteşte despre metode mari, clase mari, liste lungi de parametri care iţi pot consuma timp preţios ce altfel ar fi folosit în a-i ajuta pe ceilalţi să creeze o zebră)

Deşi cei care au creat zebrele se gândeau acum la ei înşişi ca la niste zei, ei nu erau totuşi nemuritori (mai mult, unii dintre ei aveau şi neveste acasă). Aveau o viaţă finită, deci nu puteau să şi-o irosească citind o metodă lungă, sau un miliard de linii de descriere a unei clase. Prin urmare au decis să ţină totul simplu şi clar pentru a salva timp şi pentru că atunci când cineva intra în echipa lor de construit zebre folosea mai puțin timp să înteleagă ce făcuseră deja, şi pe unde se aflau cu proiectul.

Ei... dar ce se întâmplă dacă, totuşi,

www.todaysoftmag.ro | nr. 6/2012

19

diverse 10 principii de design (fabulă)

o chestie devine prea mare? Nu ezita să o “spargi” în mai multe bucăţi. Când faci acest lucru consideră doar faptul că ai putea să o utilizezi în altă parte şi de asemenea consideră impactul pe care îl are asupra performanţei.

4. Şi pentru că doreau să distingă o zebră de celelalte, atunci creatorii ei au decis că nu ar trebui să aibă duplicate*. (În această secţiune vom vorbi despre evitarea functionalităţilor duplicate sau proiectarea în vederea evitarea duplicării codului)

la un virus de care industria farmaceutică nu profită atunci când apare. Prin urmare suntem sub presiune (industria farmaceutică nefiind interesată, suntem pe cont propriu). Dar stai! Nu numai zebra ta e bolnavă, dar toate zebrele care arată la fel au acelaşi virus. Înspăimântatoare imagine atunci când vezi un câmp plin de zebre, nu?

Codul fiind scris de oameni este predispus la erori. Prin duplicarea codului se duplică şi erorile. Având două sau mai multe bucăţi de cod care arată la fel vom avea implicit parte de o întreţinere dificilă, anevoioasă. De asemenea, timpul de testare creşte foarte mult când testezi soft care face acelaşi lucru, dar foloseşte cod diferit.

Pentru a ocoli coşmarul gândeşte codul în aşa fel încât să fie refolosibil; şi bineînţeles refoloseşte-l oricând este cazul, în loc să-l duplici; *Această secţiune a fost scrisă în memoria oiţei Dolly ( 5 Iulie 1996 – 14 Februarie 2003 ) 5. Şi pentru că ei credeau la un moment dat că zebra ar trebui să se joace cu toata lumea s-au gândit să evite tight coupling. ( În această secţiune se povesteşte cum să separi interfaţa de implementare, cum să scrii codul unui serviciu, fie el web/rest/jms, unde este cazul şi de asemenea ce au toate lucrurile astea de a face cu o zebră )

A şti care este zebra ta dintr-o turmă de zebre este un lucru destul de complicat.

Acum să ne imaginăm că cineva iţi zice ca zebra ta are un virus “căruia nu i s-a prea facut marketing”, şi ea trebuie vindecată cât de curând posibil deoarece acel virus se răspândeşte rapid şi afectează întreaga turmă. Dacă te întrebi ce e un virus “căruia nu i s-a prea facut marketing”, gândeşte-te

20

nr. 6/2012 | www.todaysoftmag.ro

Cu totii ştim cum cântă Rihanna. Dacă vreodată o zebră ar încerca sa cânte precum Rihanna restul turmei va înnebuni instant.

Deci dacă chiar vrei cu adevarat ca să nu i se intample turmei aşa ceva, las-o pe Rihanna să cânte şi pe zebră să facă playback. Cum ar trebui să implementăm? E timpul să te pregatesti pentru câteva rânduri plictisitoare despre programare.

Putem avea o interfaţă numită Singer care are o metodă sing. Rihanna este o clasă care implementează (binişor) metoda sing.

Relaţia este: Rihanna is a Singer (Rihanna este o cântăreață). Zebra va avea (has a) caracteristica de Singer (o relaţie has a înseamnă definirea unui atribut de acel tip în cadrul clasei Zebra). Pentru a ne distra puţin vom adăuga metoda lipSync() care va apela în metoda Singer.sing() (în cazul nostru cântăreţul va fi Rihanna).

După cum observaţi zebra nu va cânta deloc. Va delega doar cântatul cuiva care este capabil de aşa ceva. Dar din punct de vedere al unui observator extern, care se uită la zebră, va vedea că zebra cântă. Te gândesti ce avantaje ai obţine cu aşa ceva?

La un moment dat Rihanna se va îndrăgosti de vreun blogger şi se va opri din cântat.

Atunci, zebra ta va putea face playback la atlceva (de exemplu Sepultura), fără ca cineva să fie afectat. va urma

interviu

TODAY SOFTWARE MAGAZINE

Interviu cu Scott Barber

C

u ocazia conferinței NEXT 2012, organizată de Softvision, am avut plăcerea să îl cunoaștem și să îl urmărim pe parcursul a câteva ore pe Scott Barber, supranumit și “the face of performance testing” (eng. fața testării performanței). Un geek auto-declarat, care în baza informaţiilor pe care le găseşti deja publicate despre el nu te pregăteşte pentru supriza întâlnirii față în față şi care te frapează în mod plăcut.

Scott este un pragmatic care preferă oricând implicarea directă, în detrimentul unei abordări academice, dovadă fiind și predilecția spre a învăța din proiectele în care se implică și a împărtăși cunoștințele acumulate prin articole de natură practică (dar des referențiate), în locul publicării cărților sau articolelor științifice. Abordarea lui principală este să ajute cât mai multe companii, prin servicii de consultanță și cât mai mulți indivizi prin interacțiune directă (în calitate de organizator sau invitat al conferințelor și asociațiilor de testeri). În oricare rol se găsește, încearcă să rezolve rapid problema răspunzând la întrebările: ce resurse avem? unde vrem să ajungem? cum ajungem acolo? cât mai rapid, mai ieftin și mai simplu cu putință. În continuare, am ales să îi punem și noi câteva întrebări, iar în cele ce urmează găsiți răspunsurile lui. Pentru a sparge gheața l-am întrebat cum se simte în România, la eveniment alături de gazda Softvision, și ce crede despre comunitatea locală de testeri.

Răspunsul: „dacă acest grup este reprezentativ, cred că aveți o comunitate excelentă”, una dintre constatările plăcute, tot mai des întâlnite în ultima vreme fiind „tehnologia este un factor de egalizare grozav. Nu contează dacă o țară este bogată sau săracă, dacă știi tehnologie, poți să ai succes, iar asta este un lucru foarte bun”; ori atât evenimentul, cât și participanții au dat dovadă de profesionalism, creând „o experiență foarte plăcută”, „oamenii au fost grozavi și testerii au fost grozavi, sunt impresionat de abilitățile și cunoștințele lor [..] m-aș întoarce într-o clipită”.

Legat de atmosfera de la conferință am fost curioși ce anume este diferit, din punct de vedere cultural, atât în zona esteuropeană, cât și mai specific la NEXT. O primă observație a fost, nu atât de natură culturală,

cât mai degrabă un specific local: vârsta relativ scăzută, față de conferințele uzuale, și dorința de a învăța a participanților, manifestată activ. Tot specific NEXT ar fi implicarea participanților, comparat cu multe conferințe, unde conținutul și publicul este „superficial și generalist, nu neapărat în sensul rău, ci mai degrabă plictisitor”, aici „nu este nimic superficial, întrebările sunt adânci și pasionate”.

Păstrându-ne în contextul NEXT, am explorat care sunt pașii următori, atât pentru Scott, cât și recomandările lui pentru noi. „Dacă o iau ad literam, mă duc acasă, spăl haine și merg la nuntă”, dar în acest context „mi-am schimbat complet prezentarea din Sydney, chiar în această dimineață, bazat pe ce am învățat aici”, iar „din cauză că sunt foarte pasionat [..] și iubesc ceea ce fac [..] pasul meu următor este să învăț eu și să ii învăț pe alții mai departe tot mai mult”. „Dacă îmi voi petrece timpul umblând prin lume și învățând oamenii, vreau ca aceștia să îmi zică cum a mers”, vreau ca „următorii mei doi pași să fie o îmbunatățire continuă și să strâng feedback”. Cât despre participanți: „continuați cu acest format, oameni care au informații și training-uri relevante pentru comunitatea asta; țineți comunitatea laolaltă”, pentru că „cel mai apropiat lucru de o profesie, pe care îl avem ca și testeri, este comunitatea, și cred că această comunitate este sigura cale ca să învățăm și să creștem.

Aveți o comunitate bogată [..] oferiții o casă, aceasta este provocarea mea pentru voi: nu o lăsați să moară!”

Odată spartă gheața întrebările au început să curgă, iar în continuare mă voi mulțumi să le reproduc integral, cu unele mici editări și completări de context în cazul răspunsurilor primite.

foto: Scott Barber Q: Care unelte le considerați mai bune, cărțile sau uneltele software care automatizează munca? „Wow! Vreau să vă zic că sunt încă atașat de unele lucruri tradiționale, fie că sunt cărți sau altceva, dar sunt în același timp un geek și îmi plac și uneltele software, așa că de cele mai multe ori depinde de scopul în care le folosesc. [..] Dar ce îmi place cel mai mult este să am de unde alege.”

Q: Ai anumite instrumente pentru a învăța zilnic, surse de informații gen reviste etc. ? „Deși de multe ori oamenii consideră blog-urile, doar opinii personale, în lumea testerilor, în care nu există un manual de utilizare sau diplome de facultate specializată [..] găsești aceeași informație din revistele de specialitate pe blogul autorilor, mult mai repede”. Important este să „învățați de la ei, dar priviți informația ca un tester: cum s-au gândit la asta? și cum o aplic eu în cazul meu?” O altă soluție foarte bună e „încercând să înveți pe altcineva înveți singur, așa că opțiunea numărul unu pentru mine este să îi învăț pe alții.”

Q: Tot la capitolul instrumente, care sunt instrumentele cele mai folosite în rutina zilnică? „ Aaaahh! Ca să fiu sincer, cele pe care le folosesc cel mai des sunt cele gratuite, open source sau care au o perioadă de încercare suficient de lungă. Prin urmare sunt atașat de JMeter, OpenSTA, și în ultima vreme de unealta cloud SOASTA, www.todaysoftmag.ro | nr. 6/2012

21

interviu Interviu cu Scott Barber pentru că au o versiune gratuită suficient de robustă pentru a putea face testare reală de performanță. Acestea fiind zise, unele din cele mai scumpe unelte sunt foarte foarte puternice și îmi plac, dar nu mi le permit, așa că depind de clienți să le pot folosi. Dar sunt distractiv de folosit, mai ales când altcineva le-a cumpărat.”

Q: La capitolul procese, cum se poate compara testarea în metodologia „agile” (eng. agilă) cu varianta „waterfall” (eng. cascadă)? „Când a apărut manifestul „agile” mi-am întrebat colegii: nu toată lumea lucrează așa deja? Iar ei au răspuns: cel puțin noi așa lucrăm. Ani mai târziu când am intrat în contact cu companii care încă foloseau „waterfall” mi-am pus întrebarea: cum poate cineva să facă metodologia asta să funcționeze?Testarea performanței este în mod inerent agilă, iar prin asta vreau să spun că nu poți fii cu adevărat eficient în a furniza, cel puțin consistent, aplicații performante, dacă nu faci o minimă testare de performanță chiar de la început.

Asta nu înseamnă că tot timpul aceasta este făcută de tester, și asta poate crea confuzie, pentru că există o diferență între activități și roluri. Ceea ce s-a schimbat însă, este că cu cat mai multe companii și echipe lucrează la adoptarea principiilor „agile”, cu atât mai ușor este pentru mine să transmit mesajul că responsabilitatea performanței este împărțită și de dezvoltatori și de administratori și de cei de la suport. Trebuie ca toate bucățile să se potrivească și dacă nu împărtășim informațiile și nu lucrăm împreună, atunci suntem în cazul tradițional „waterfall” în care testerul furnizează multă informație când nu mai este timp pentru reparații. Iar repararea problemelor de performanță este de cele mai multe ori scumpă, implicând achiziții hardware și refacerea arhitecturilor. Cu cât integrăm performanța în activitățile „agile” zilnice, cu atât mai capabili vom fi să livrăm aplicații performante consistent și cu atât mai fericiți vor fii utilizatorii.”

Q: Poți să alcătuiești un top 3 buzzwords (eng. cuvinte la modă), din ultimii ani? „Subiecte mari care trezesc pasiuni și polarizează lumea în ultimii 4-5 ani ar fi certificarea, automatizarea și.. probabil „agile”, dar doar pentru că implică o schimbare de cultură organizațională. După ani de „waterfall” [..] la schimbare, testerii nu își mai găsesc locul, o vreme, și asta cauzează stres [..] însă mulți, odată ce se integrează le place mult „agile”. Automatizarea a fost

22

nr. 6/2012 | www.todaysoftmag.ro

un subiect fierbinte pentru că multă lume crede că prin ea putem înlocui testerul uman. Dar adevărul este că automatizarea poate face foarte multe lucruri și mie îmi place să automatizez, dar încă nu am întâlnit o bucată de software care să poată lua decizii și să găsească erori la fel de bine ca un om instruit. Cu alte cuvinte nu poți înlocui, dar poți îmbunătăți, poți ajuta un tester uman să testeze mai bine, mai rapid, să acopere mai mult, dar nu poți înlocui oamenii cu unelte automate. Iar provocarea cu certificatele este că sunt multe și este greu de înțeles ce înseamnă fiecare.

Managerii de recrutare văd certificările, dar nu înțeleg ce înseamnă.”

Q: Poți să ne dai exemple de realizări cu care te mândrești? „Ceea ce e interesant este definiția realizării – majoritatea oamenilor cred că voi vorbi de rularea unui test grozav, găsirea unui bug important sau oprirea livrării unui produs, cu probleme, care putea provoca prejudicii de milioane de dolari.

Da! sunt realizări, dar se întâmplă odată, cândva, poate am avut noroc, poate sunt bun, nu contează, pur și simplu s-au întâmplat. în schimb pentru mine o realizare e când ajut o persoană sau o organizație să li se aprindă un beculeț, să aibă o idee sau să își schimbe modul de gândire și perspectiva în așa fel încât să îi conducă la succes, mult după ce am plecat. De multe ori nu aflu de asta decât după ani. Un mic exemplu: odată, după doar 90 de minute la un client, știam care era problema, la fiecare 10 minute un alt vicepreședinte intra și le dădea altceva de lucru. Iar acești VP nu vorbeau între ei. Soluția a fost să mă așez cu scaunul în ușă și să îi țin de vorbă de fiecare dată când apăreau. După doar 3 zile aveau rezultate excelente, iar eu nu m-am atins de nimic. Bineînțeles că la plecarea mea lucrurile au revenit la problema inițială, dar șeful echipei mi-a zis că între timp nu mai lucrează la ei și că are acum propria echipă, cu care aplică aceeași rețetă și lucrurile merg de minune. Când am auzit asta am fost atât de mândru, un lucru atât de simplu și prostuț, care nu are nimic de a face cu testarea performanței, dar care poate face o diferență atât de mare.”

Q: Poți să ne zici care ar fi diferențele între metodologiile de testare a dispozitivelor desktop, server și mobile? „Iată ce am învățat eu: testarea e ceva ce devine o parte din tine, iar dacă ești bun la testat, nu mai contează ce anume testezi. O să iți dai seama cum să faci fiecare lucru, când ai nevoie de o unealtă de automatizare, când să testezi manual, când ai nevoie de ajutor de la un programator, când să o faci mai devreme sau mai târziu sau la mijloc, pentru că nu astea sunt cele mai importante pentru un tester. Ceea ce e important este să înveți cum funcționează sau cum ar trebui să funcționeze și apoi să găsești toate felurile în care nu merge cum ar trebui să meargă. Știți ceva? .. eu testez totul. Testez frigiderul, testez paharele, mai devreme mă jucam cu dopul de la sticlă, de ce? Pentru că nu mă pot abține. Unii zic că așa sunt eu Scott. Dar eu urmăresc oamenii care au instinctul de tester și toți fac asta tot timpul, fără să țină de metodologie.

Metodologiile diferă ca implementare, dar nu ca și proces de gândire.

Q: Ai recomandat participanților să strice din când în când câte ceva în încercarea de a învăța ceva nou. Ai putea să ne dai exemple în care ai stricat și tu ceva? „Eram la al doilea proiect, [..] primul a fost 6 săptămâni de training și al doilea 8 săptămâni ca și șef de testare pe un proiect în valoare de mai multe milioane de dolari [..] pe vremea când 150 de utilizatori într-o oră erau mulți. Testam la client [..] cu 53 de hopuri de rețea între cele două mașini fizice aflate una lângă alta, așa că m-am mutat la biroul propriu de peste drum. Am primit un mail care zicea să urc încărcarea la 500 de utilizatori, iar eu am refuzat zicând că nu e o idee bună. Atunci mi s-a spus că au trebuit să convingă un șef mare să cumpere o licență de 500 de utilizatori și au nevoie de asta. Am zis că tot nu cred că e o idee bună, dar am totul în email așa că am dat drumu la test și am plecat la un prânz de 3 ore. [..] La întoarcere, monitorul plin de notițe lipite: vino să mă vezi! de la managerul meu; vino să mă vezi, te rog! de la director; vino să mă vezi acum! de la CTO; vino la mine în birou când te întorci! de la

TODAY SOFTWARE MAGAZINE CEO. Reacția mea: asta nu e bine!, așa că am făcut ce orice tester bun ar face, am dat jos toate notițele și am început să mă uit la mesajele de eroare să îmi dau seama ce s-a întâmplat. în câteva minute toți stăteau în spatele meu și mă întrebau: ai idee ce ai făcut? - Da! Am rulat un 500; - și ai idee ce a făcut asta? - Nu, asta încerc să îmi dau seama, pentru că mă gândeam că o să mă întrebați și încă mă uit. CTO-ul, în mod normal un tip calm și tăcut: Îți zic eu ce ai făcut, le-ai dărâmat întreaga rețea externă și avocatul lor ne sună din 15 în 15 minute să ne anunțe că au mai adăugat un milion de dolari pierderilor. Reacția mea: .. aaaaaaaaaah! Mă gândeam că sunt cel puțin concediat, dacă am noroc. La care m-au întrebat de ce am rulat un 500, iar eu am răspuns: pentrucaleamziscaeoideeproastasieamiatrimisunmailsiaziscatrebuiesaofac.

Iar ei au întrebat dacă am emailul și când am răspuns Da! au început să râdă, să îmi bată palma, să îmi spună că doar glumeau și totul ii ok. Dar eu am cauzat acelei companii (chiar dacă ziceau un milion de dolari la 15 minute) toată rețeaua externă a fost picată o săptămâna. Am generat o încărcare asa mare, că dispozitive fizice s-au încălzit atât de tare că s-au topit și a fost nevoie să se comande altele în schimb. Cum de s-a întâmplat asta? Păi întreaga lor infrastructură rula la mult peste limita normală, încă înainte să dau eu drumul la test. A fost vina mea? Nu, dacă rețeaua îți funcționează la 95% din capacitate, trebuie să faci un upgrade înainte de a modifica ceva în încărcarea ei.”

Q: În cât timp crezi că va afecta testarea, schimbarea de paradigmă spre „cloud” și mobilitate? „Companiile inovatoare tehnologic, cele care au software-ul ca și business, nu doar utilizatorii sau dezvoltarea de servicii, intern, pentru a evita achiziții scumpe, sunt deja acolo. La Facebook, singurele lucruri care nu sunt în „cloud” sunt laptopurile angajaților. Google avea, am să îl numesc un cloud intern, acum 10 ani. Ai putea să îl numești rețea virtuală, dar nu era. Era construit cum este construit în ziua de azi cloud-ul. Multe companii la care mă duc, de înaltă tehnologie, au totul, cu excepția mașinilor proprii ale personalului, în cloud.

Mulți programatori în ziua de azi, în loc să își comande laptopuri de top pentru dezvoltare, își comandă unele relativ ieftine, pentru că lucrează în cloud. Așa că suntem deja acolo, în sensul că nu mai este cale de întoarcere. Cât de repede se va muta totul în cloud, este greu de zis din cauza

îngrijorărilor vizavi de securitate. Eu am făcut un tur al unui centru de date și pot să vă zic că securitatea fizică este dincolo de orice îmi pot imagina că poate asigura o companie, camerei de servere proprii.

Este incredibil! Dar furnizorii de cloud nu sunt dispuși să semneze hârtia care zice: ne asumăm responsabilitatea. Prin urmare companiile cu securitate mare nu vor să facă tranziția. Dar pentru toți restul, cred că este foarte curând. În opinia mea puține companii vor mai face următoarea actualizare a infrastructurii hardware proprii și vor prefera să se mute în cloud.”

Q: Ce anume ați adăuga în programa universitară, dacă ați avea ocazia? „Încercări de injectare a unor cursuri de testare în universități, nu au dus până acum nicăieri. Cu cât mă gândesc mai mult la asta, deși mi-ar place să văd astfel de cursuri, nu doar în dezvoltare software, dar în orice legat de tehnologie, adevărul este că ce îmi doresc cu adevărat sunt cursuri în teoria sistemelor. Vreau ca oamenii să învețe cum să gândească despre sisteme.

Eu ca și inginer în construcții civile, mă uit la un pod și văd vectori de forțe. Știu că sună ciudat, dar asta văd, pentru că asta am învățat. Dacă mă uit la schema unui sistem de calcul pe un monitor, mă gândesc la unde merg toate pachetele și ce anume fac, și mă ajută mai mult decât orice curs de testare sau programare am urmat. Așa că mă gândesc că în loc să devenim tot mai specifici în învățământul universitar, ar trebui să ne întoarcem la unele cursuri care erau foarte importante, cursuri de bază în inginerie, care nu erau despre a construi ceva, ci erau despre cum trebuie să gândim pentru a rezolva o problemă de inginerie.

Cred că urmăm mult prea multe cursuri „cum să programezi în Java” și nu destule „cum să rezolvi probleme reale”.

excelente abilități de comunicare. Știu că toată lumea cere abilități de comunicare scrise și verbale, dar ce am eu nevoie e un pic diferit. Eu vreau pe cineva care e în stare să explice lucruri tehnice ciudate, unor oameni cărora nu le pasă, într-un fel care ii face să înțeleagă, care are sens și are o acuratețe suficientă. Eu de exemplu prefer imaginile și analogiile. Apoi vreau oameni cu înclinații spre tehnologie. Nu trebuie să știe totul despre toate, dar vreau să iubească tehnologia și să iubească să învețe despre noi tehnologii. Și vreau să aibă abilități de business, peste nivelul majorității oamenilor tehnici, deoarece când cineva are nevoie de un nivel de performanță ridicat, de obicei înseamnă că are multi utilizatori.

Iar dacă sunt multi utilizatori, înseamnă că sunt și multi bani în joc, iar dacă nu poți să vorbești în limbajul banilor cu un manager, o să fie foarte greu să îl ajuți să ia decizii bune. Sunt doar 4, dar nu îmi vine un 5 fabulos așa că nu vreau să intru în alte detalii, care sunt cam echivalente în opinia mea. Sună distractiv nu? Credeați că o să zic scripting?

Q: În încheiere poți să ne dai o definiție cât mai concisă a performanței? „Când zic performanță, mă refer la tot ce ține de viteza, scalabilitatea și stabilitatea unui sistem de interes. Există multe alte definiții, dar la finalul zilei eu o folosesc pe mama ca și model. La Microsoft le zice „persona”. Mama mea e „persona” mea, iar ei nu ii pasă câți oameni sunt pe site, ce servicii sunt căzute, nimic de genul acesta. Tot ce știe ea e că uneori merge cum mergea înainte, alteori nu. Eu vreau ca mama să aibă tot timpul aceeași experiență, și ar fi chiar mai bine ca aceasta să fie o experiență bună de fiecare dată.

Așadar când mă gândesc la mama stând în fața calculatorului și la experiența ei, presupunând că funcționalitatea e ok, pentru Q: Care ar fi cele mai importante că funcționalitatea nu ține de performanță, 5 abilități din profilul unui tester de asta e performanța, iar cuvintele pe care performanță? le folosesc sunt viteză, scalabilitate și „Doar 5? Glumesc. Mai demult glu- stabilitate. meam că trebuie să fii nivel mediu în toate, iar apoi că trebuie să fii ca și cei din CSI Las Vegas, adică expert în toate. Dar pe primul loc este să știi cum să abordezi o problemă.

Vreau să înțeleagă cum să rezolve problema, cum să caute cauzele, indiferent că Marius Mornea marius.mornea@todaysoftmag.com e vorba de o problemă de performanță sau de business. Vreau să știe când e nevoie Fost senior software developer de un pas în spate, să arunce o privire de in cadrul Nokia, în prezent ansamblu, iar apoi să își dea seama unde fondatorul platformei Mintaka Research trebuie să intre iar în detalii. Vreau oameni buni la rezolvarea problemelor. Apoi vreau www.todaysoftmag.ro | nr. 6/2012

23

programare

A scrie cod frumos dincolo de valoarea estetică

L

imbajele de programare cele mai cunoscute conţin o mulţime de funcţionalităţi şi librarii standard. Din acest motiv devine important să ştim răspunsul nu doar la întrebarea „cum” se face ceva (întrebare la care există de obicei o multitudine de răspunsuri), dar şi la „care este calea recomandată?”.

Attila-Mihaly Balazs dify.ltd@gmail.com

Code Wrangler @ Udacity Trainer @ Tora Trading

În acest articol vom încerca sa demonstrăm că prin cunoaşterea şi aplicarea practicilor recomandate pentru scrierea codului sursă (en. best practices) rezultă atât programe mai scurte (mai uşor de scris), mai uşor de citit, mai usor de înţeles şi menţinut, dar şi programe corecte.

Acest articol necesită un minim de cunoştinţe Java pentru a putea fi savurat, dar ideea de bază este general aplicabilă: cunoaşterea unui limbaj de programare implică mai mult decât învăţarea sintaxei.

Exemplul 1: Double Trouble

Ce afişează următoarea bucată de cod?

Double d1 = (5.0d - 5.0d) * 1.0d; Double d2 = (5.0d - 5.0d) * -1.0d; System.out.println(d1.equals(d2));

Dar aceasta?

double d1 = (5.0d - 5.0d) * 1.0d; double d2 = (5.0d - 5.0d) * -1.0d; System.out.println(d1 == d2);

Răspunsul pare să fie clar: în ambele cazuri înmulţim zero cu diferite valori (plus şi minus unu) iar rezultatul este tot zero; dacă am compara rezultatele, ele ar trebui să fie egale, indiferent de metoda de comparaţie utilizată (apelarea metodei equals pe obiecte sau folosind operatorul de egalitate pe valorile primitive). Însă rezultatul execuţiei s-ar putea să

24

nr. 6/2012 | www.todaysoftmag.ro

ne surprindă: primul exemplu afişează false iar ce cel de-al doilea afişează true.

Ce se întâmplă? Motivul tehnic pentru acest rezultat este faptul că valorile de tip virgulă mobilă (en. floating point) sunt stocate de către Java (şi multe alte limbaje de programare) folosind notaţia semnşi-magnitudine (en. sign and magnitude) definite în standardul IEEE 754. Din cauza acestui detaliu tehnic atât „plus zero” cât şi „minus zero” pot fi reprezentate în variabile de acest tip, iar metoda „equals” pe obiectele Double (sau Float) din Java consideră că aceste valori sunt diferite.

Am fi putut evita această problemă în întregime prin utilizarea valorilor primitive aşa cum s-a arătat în al doilea fragment de cod şi cum este sugerat în capitolul 49 din Effective Java : „Prefer primitive types to boxed primitives”. Alte motive pentru utilizarea tipurilor primitive ar fi: eficienţă din punctul de vedere al memoriei consumate şi evitarea definirii cazurilor speciale pentru referinţa nulă (null reference).

Avem o situaţie similară cu clasa BigDecimal la care valorile scalate în mod diferit nu sunt considerate egale de metoda equals. De exemplu şi următorul fragment afişează false: BigDecimal d1 = new BigDeci-

management

mal(„1.2”); BigDecimal d2 = new BigDecimal(„1.20”); System.out.println(d1.equals(d2));

Soluţia în acest caz (având în vedere faptul că nu există un tip primitiv echivalent pentru această clasă) ar fi să se utilizeze (în locul metodei equals) metoda compareTo şi compararea valorii întoarse cu zero (o metodă care poate fi, de asemenea, folosită pentru a rezolva problema în cazul claselor Double/Float dacă nu suntem îngrijoraţi de valorile nule).

Exemplul 2: Unde a dispărut valoarea null?

Ce afişează următorul fragment de cod?

Double v = null; Double d = true ? v : 0.0d; System.out.println(d);

La prima vedere am spune: null, deoarece condiţia este adevărată şi v are valoarea null (null poate fi atribuit oricărei referinţe, indiferent de tipul ei, deci codul este corect). Dacă rulăm codul, rezultatul este un NullPointerException la linia a doua.

Acest lucru se datorează faptului că tipul expresiei din partea dreaptă a atribuirii este de fapt double (tip primitiv) nu Double (tip boxed) cum ne-am aştepta, care este transformat în Double de compilator (prin auto-boxing). Codul generat de compilator arată astfel: Double d = Double.valueOf(true ? v.doubleValue() : 0.0d);

Acest comportament este specificat în Java Language Specification :

TODAY SOFTWARE MAGAZINE

Putem spune că ele sunt echivalente din moment ce o colecţie goală conţine zero elemente. Cu toate acestea, a doua condiţie este mai uşor de înţeles (aproape ca o putem citi cu voce tare: „if items is empty then ...”). Și are încă un avantaj: în unele cazuri poate fi mult, mult mai rapidă.

Două exemple din biblioteca standard Java unde timpul necesar pentru a executa ”size” creşte liniar cu numărul de elemente din colecţie în timp ce ”isEmpty” se execută în timp constant: ConcurrentLinkedQueue şi ”vederile” (views) întoarse de metodele headSet/tailSet din clasa TreeSet .

Acesta este încă un exemplu în care codul mai frumos este şi mai rapid.

aceeaşi ordine de idei trebuie să ne ferim de pattern-ul Singleton care – pe lângă problemele potenţiale de iniţializare – face codul mai greu de testat.

Tot aici trebuie sa menţionăm că folosirea claselor statice interioare (static inner classes) este de preferat (capitolul 22 în EJ2nd). Clasele statice în Java sunt distincte conceptual de câmpurile statice şi este regretabil faptul că acelaşi cuvânt a fost folosit pentru a descrie amândouă conceptele.

De asemenea, este foarte recomandat să rulăm unelte de analiză statică (static analysis tools) pe codul nostru şi să verificăm frecvent rezultatul lor (în mod ideal la fiecare schimbare de cod). De exemExemplul 4: Atenţie la folosirea lui static! plu, problema prezentată este detectată Ce afişează următorul fragment de cod? de Findbugs şi uneltele care încorporează public final class Test { Findbugs. private static final class Foo { static final Foo INSTANCE = new Foo(); // 2

static final String NAME = Foo.class.getName(); // 3 Foo() { System.err.println( „Hello, my name is „ + NAME); } } public static void main( String[] args) { System.err.println( “Your name is what?\n”+ “Your name is who?\n”); }

new Foo(); // 1 }

Rezultatul este

Your name is what?

Your name is who?

Hello, my name is null Hello, my name is Test$Foo

„Dacă unul dintre operanzii doi şi trei Valoare nulă (probabil) neaşteptată se este de tip T primitiv, şi tipul celălalt este afişează pentru că obţinem o referinţă către rezultatul aplicării operaţiei de auto-boxing un obiect parţial construit: (§ 5.1.7) la T, atunci tipul expresiei ter• Începem să creăm o instanţă a clasei nare este T”. Cred că nu mulţi dintre noi Foo la punctul 1; au parcurs JLS-ul complet şi chiar dacă • Aceasta fiind prima referire la clasa am fi parcurs, nu am fi realizat implicaţiFoo, JVM-ul o încarcă şi începe s-o ile subtile ale fiecărei fraze. Recomandarea iniţializeze; din EJ2nd de la exemplul anterior ne ajută • Iniţializarea clasei Foo implică iniţidin nou: să folosim tipuri primitive. De alizarea tuturor câmpurilor statice; asemenea, putem face o paralelă cu capi• Pentru iniţializarea primului câmp tolul 43 din carte: Return empty arrays or static trebuie apelat constructorul de collections, not nulls. Dacă am fi folosit un la punctul 2, ceea ce se şi întâmplă; „element neutru” (analogul folosirii tabe• În acest moment câmpul static lelor/colecţiilor goale) problema nu ar fi NAME nu este încă iniţializat şi astapărut. (Elementul neutru ar fi 0.0d dacă fel constructorul va afişa null. însumăm sau 1.0d dacă înmulţim).

Acest cod demonstrează cum câmpuExemplul 3: Un vas gol rile statice pot fi dificil de folosit în mod Care este diferenţa dintre următoarele corect şi că nu ar trebui să le utilizăm decât două expresii condiţionale? la declararea constantelor (şi chiar şi atunci Collection<V> items; să ne gândim dacă nu este mai bine să foloif (items.size() == 0) { ... } if (items.isEmpty()) { ... } sim un Enum in locul constantelor). În

Exemplul 5: Eliminarea codului vechi

Enumeraţi patru lucruri în neregulă cu următorul fragment de cod: // WRONG! DON’T DO THIS! Vector v1; ... if (!v1.contains(s)) { v1.add(s); }

Problemele ar fi: Tipul de container folosit este greşit.

Se doreşte ca fiecare şir să fie prezent cel mult o dată, ceea ce sugerează utilizarea unui Set<> care rezultă în cod mai scurt şi mai rapid (timpul de execuţie al metodei de mai sus depinde în mod liniar de numărul de elemente); • Nu sunt folosite adnotările de tip (generics); • Codul foloseşte metode sincronizate în mod inutil dacă accesul la structură se face doar de pe un singur fir de execuţie (thread); • În cazul în care structura este utilizată de mai multe fire de execuţie, codul nu este thread-safe, numai „exception safe” (nicio excepţie nu va fi aruncată, dar structura de date poate deveni coruptă, fapt care poate duce la probleme greu de diagnosticat).

•

Toate acestea pot fi evitate prin abandonarea clasei Vector şi fraţii săi (Hashtable, StringBuffer) şi folosind Java Collections Framework (disponibil de 14 de ani ) cu adnotările de tip (disponibile de 8 ani ).

www.todaysoftmag.ro | nr. 6/2012

25

programare A scrie cod frumos - dincolo de valoarea estetică

Concluzie

Concluziile sunt valabile şi pentru alte Aceste exemple nu sunt singulare. limbaje de programare: Cunoaşterea unui limbaj de programare • Încercaţi să citiţi despre modul cel înseamnă mai mult decât stăpânirea sintamai bun (best practices) / moduri xei la un nivel de bază. Dacă utilizaţi Java: idiomatice (idiomatic) de a scrie cod faceţi-vă rost de câte o copie din „Effective în limbajul dat. De exemplu, cea mai Java, 2nd edition” şi „Java™ Puzzlers: Traps, bună carte pentru Perl în momentul Pitfalls, and Corner Cases” şi parcurgeţide faţă este ”Modern Perl” , scrisă de le, dacă nu aţi făcut deja acest lucru. De chromatic şi disponibilă gratuit. asemenea, utilizaţi analiza statică (static • Verificaţi dacă există o unealtă de analysis/linting) pe codul sursă (Sonar este analiză statică (static analysis / lino alegere bună în acest domeniu) şi rezolter) de bună calitate pentru limbajul vaţi problemele semnalate de aceasta sau respectiv. De exemplu pentru Perl cel puţin citiţi atent descrierile lor. există Perl::Critic , pentru Python

pep8 şi pylint , toate acestea fiind gratuite şi open-source.

A fi un un bun programator este un proces de învăţare continuă, iar resursele enumerate mai sus pot fi instrumente care să ne ajute să învăţăm cu adevărat un limbaj de programare.

Bibliografie Joshua Bloch: Effective Java, Second Edition. ISBN: 0321356683 http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html # JLS-15.25 http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html # Dimensiune () http://docs.oracle.com/javase/7/docs/api/java/util/TreeSet.html http://findbugs.sourceforge.net/bugDescriptions.html # SI_INSTANCE_BEFORE_FINALS_ASSIGNED http://en.wikipedia.org/wiki/Java_version_history # J2SE_1.2_.28December_8.2C_1998.29 http://en.wikipedia.org/wiki/Java_version_history # J2SE_5.0_.28September_30.2C_2004.29 http://www.sonarsource.org/ http://www.onyxneon.com/books/modern_perl/index.html http://search.cpan.org/ ~ thaljef/Perl-Critic-1.118/lib/Perl/Critic.pm http://pypi.python.org/pypi/pep8 http://pypi.python.org/pypi/pylint

26

nr. 6/2012 | www.todaysoftmag.ro

management

TODAY SOFTWARE MAGAZINE

Toate drumurile duc la SaaS 7 provocări pentru a ajunge acolo

C

ompania de cercetare Forrester indică faptul că până în 2020 piața globală de cloud computing va ajunge la valoarea de 160 de miliarde de dolari, 83% fiind reprezentată de soluțiile SaaS. Indiferent de acuratețea previziunilor, un lucru este sigur – SaaS va avea un impact major asupra companiilor ISV ce-și bazează veniturile pe vânzarea de licențe.

Lumea se schimbă Mihai Nadăș mihai.nadas@tss-yonder.com CTO @ Yonder este responsabil de activitățile R&D și creșterea nivelului de inovație al produselor partenerilor Yonder.

Ne aflăm la trecerea dintre două paradigme de monetizare a produselor software.

Prima este cea bazată pe vânzarea de licențe care a ajutat în ultimele decenii companii precum Microsoft să ajungă la cea mai mare valoare de piață înregistrată vreodată de o companie publică, și anume 618,9 miliarde de dolari, record înregistrat pe data de 30 decembrie 1999. În acest caz, putem discuta în esență de un model prin care produsul software este cumpărat de către beneficiar, acesta plătind contravalorea sa înmulțită cu numărul de licențe achiziționate.

Convergența internetului cu tehnologia de virtualizare și scăderea prețului puterii de calcul ne-a dăruit ceea ce numim acum sub o formă sau alta „cloud computing” – un stil nou de a consuma servicii computaționale și de persistență de date. Odată cu aceasta s-a născut și conceptul de închiriere de produse software sau Software as a Service (SaaS), model în care beneficiarul achită contravaloarea utilizării produsului ca serviciu pe baza unui abonament a cărui valoare variază în funcție de numărul de utilizatori finali.

Evident, nimic nou sub soare, însă dacă privim către graficele ce pot fi determinate pe baza studiului Forrester se observă un

lucru interesant – curba de creștere anuală absolută prinde contur începând cu 2012, culminând în 2014 când piața ar urma să se mărească cu 63,19 miliarde de dolari. În termeni practici, aceasta înseamnă un singur lucru – adopția de soluții SaaS va cunoaște cea mai accelerată creștere în următorii doi ani, iar aceasta se corelează cu scăderea pieței de licențiere a produselor software, reprezentând un aspect ce trebuie să determine companiile ISV să-și pună în execuție strategia legată de SaaS, în cazul în care au una.

Exact Software, unul dintre cei mai mari ISV din Olanda, a înregistrat în 2011 o scădere a veniturilor obținute din vânzarea de software cu 13% în Benelux în timp ce soluția bazată pe SaaS a crescut cu 46%, aducând venituri de 11,6 milioane de euro față de 7,9 milioane în 2010. Aceeași situație o regăsim și în cazul UNIT4, un alt ISV olandez, care a mizat timpuriu pe SaaS și acum beneficiează de venituri de peste 9 milioane de dolari din acea soluție.

Dincolo de statistici

Potențialul de a adresa piețe noi, avantajul unui venit mai ușor de preconizat, cel al costurilor reduse de suport și mentenanță www.todaysoftmag.ro | nr. 6/2012

27

management Toate drumurile duc la SaaS - 7 provocari în a ajunge acolo

corelate cu oportunitatea de a cunoaște mai multe despre comportamentul de utilizare ai propriilor clienți fac din SaaS o perspectivă mai mult decât interesantă pentru companiile ISV. Privind obiectiv, companiile ISV au două motive de a adopta o strategie SaaS: creșterea business-ului curent și protejarea acestuia. Google a văzut o oportunitate de creștere în momentul în care a introdus Google Apps, o soluție SaaS ce atacă piața tradițională Microsoft Office. Microsoft pe de altă parte, a reacționat introducând suita Office 365, o alternativă la propria soluție bazată pe vânzarea de licențe.

Privind la cele două motivații, o concluzie ar fi că există puține argumente ce ar putea determina companiile ISV să ignore în siguranță SaaS. Pentru a face lucrurile și mai clare aș spune că există de fapt un set extrem de limitat de argumente pentru care un ISV debutant ar alege să practice modelul tradițional în defavoarea SaaS.

Cele 7 provocări în drumul unui ISV către SaaS

Adopția SaaS în contextul modelului tradițional de licențiere reprezintă o schimbare majoră pentru companiile ISV. Vorbim practic despre două cateogrii de provocări: cele ce țin de business și cele tehnice. Chiar dacă provocările tehnice sunt serioase și presupun investiții majore de renovare a soluției existente, setul celor de business reprezintă de cele mai multe ori cheia succesului deoarece presupun decizii ce au impact direct asupra perspectivelor financiare ale companiei.

Pot fi identificate cel puțin șapte provocări în drumul unui ISV către o soluție de succes bazată pe SaaS – 1. Identificarea pieței țintă pentru noua soluție – alegerea între abordarea unei piețe noi sau consolidarea celei existente; 2. Alegerea politicii de prețuri balansul între accesibilitatea ofertei și riscul de canibalizare a veniturilor existente; 3. Schimbarea stilului de vânzare și de marketing – clienții SaaS iau decizia de cumpărare într-un mod diferit față de cei ai soluțiilor tradiționale, iar aceasta deoarece însuși factorii de decizie se schimbă; 4. Consolidarea robusteței produsului – în modelul tradițional stabilitatea produsului nu avea un

28

nr. 6/2012 | www.todaysoftmag.ro

5.

6.

7.

•

• • • •

•

impact centralizat asupra întregii baze de clienți pe când cu SaaS orice eroare sau întrerupere a serviciului este sesizată de către toată lumea; „ Agilizarea” modelul de dezvoltare software – SaaS fructifică abilitatea unei companii de a răspunde într-un mod agil schimbării, iar aceasta presupune pe de-o parte schimbarea modelului de dezvoltare bazat pe cicluri de durată lungă și totodată profesionalizarea acestuia prin introducerea de procese mature care să scadă riscul pe mai multe paliere; Restructurarea organizațională – datorită numărului crescut de schimbări ce apar în modul de abordare SaaS, de cele mai multe ori însăși organizația trebuie schimbată. Poveștile de succes pornesc de regulă de la o echipă nouă, independentă de cele existente sau chiar de la spin-off-uri; Excelență în abordarea și execuția tehnică – întâi de toate, SaaS prespune interacțiunea cu un UI web, iar de cele mai multe ori acest lucru prezintă prima provocare tehnică întrucât modelul tradițional este în general bazat pe aplicații cu UI non-web. Dincolo de acest aspect trebuie găsite răspunsurile și implementarea potrivită la următoarele întrebări – Ce platformă de cloud computing se alege și sub ce formă? IaaS sau PaaS? Public sau Private? AWS, Windows Azure, Google App Engine, VMware Cloud Foundry, Heroku, CloudBees, AppFog, AppScale, Apprenda sau altceva?

Cu m s e t r at e a z ă a s p e c tu l multi-tenancy?

Cum se partiționează datele și care este arhitectura aleasă pentru izolarea acestora?

Cum se asigură scalabilitatea și disponibilitatea ridicată (i.e.

99,95% uptime) a soluției?

Cum se proiectează procesele de Onboarding, Feature Bundling, Subscription Management, Billing și Revenue Management?

Cum se implementează autentificarea și autorizarea și care sunt aspectele arhitecturale care adresează problemele de securitate?

•

Cum se asigură un proces robust și flexibil de Release Management?

Concluzii

Ne aflăm în pragul unei schimbări majore pentru companiile ISV. Dacă astăzi încă vorbim de SaaS în termeni de inovație, cel mai probabil la finalul acestui deceniu când zarurile vor fi deja aruncate, SaaS va reprezenta normalitatea în ceea ce privește consumul de software.

Conform predicțiilor, acum este cel mai potrivit moment pentru implementarea unei strategii de tranziție la SaaS, iar din experimența acumulată până acum în Yonder se poate spune că succesul e bazat întâi de toate pe decizii înțelepte de business însă fără compromisuri în execuția tehnică, unde complexitatea poate fi mai ridicată decât indică aprențele.

Legături externe

1. innovation.tss-yonder.com 2. i n n o v a t i o n . t s s - y o n d e r. c o m / sizing-the-cloud 3. mihainadas.com

programare

TODAY SOFTWARE MAGAZINE

Introducere în Grails

G

rails este un framework web bazat pe Java și Groovy. Grails împrumută concepte din frameowork-uri precum Rails în dorința de a simplifica web development-ul în Java.

La o scurtă privire, Grails folosește: Limbajul Groovy – pentru a conecta toate stack-urile de mai jos; • Hibernate – pentru modelarea datelor folosing GORM (Groovy Object Relational Model); • Groovy Server Pages – un limbaj dinamic pentru construirea view-urilor; • Spring – pentru controller, securitate, injectarea de dependințe, internaționalizare, etc.; • Consolă scrisă în Groovy; • Servlet containerul Tomcat inclus pentru a putea face hot-deploy la modificările de cod (în cele mai multe cazuri).

•

Tavi Bolog tavi.bolog@nokia.com Development lead @ Nokia

Proiectul meu current (http://primeplace.nokia.com) folosește Grails 2.0.4.

Partea web a fost tranziționată în aproximativ două luni de efort din Apache Wicket (un framework pe care nu îl prea plăceam) fără a avea un bagaj de cunoștințe avansate

de Grails înainte de începerea proiectului. În același timp am adăugat funcționalități noi, continuând să menținem release-ul bazat pe Apache Wicket. Bineînțeles, încă tot învățăm lucruri noi și uimitoare despre lumea Grails și Groovy.

Setarea Grails

Pentru a folosi Grails, ai nevoie de urmatoarele: • Descarcă și instalează Java JDK de la Oracle: http://www.oracle.com/ technetwork/java/javase/downloads/ index.html; • Pentru unele sisteme de operare, va trebui să setezi de mână JAVA_ HOME și să adaugi executabilul “java” in PATH; • Descarcă Grails: http://grails.org/ și extrage conținutul; • Setează GRAILS_HOME spre folderul în care a fost despachetat Grails și adaugă executabilul “grails” în PATH;

www.todaysoftmag.ro | nr. 6/2012

29

programare

Introducere în Grails

•

Rulează Grails, tastând: “grails” în Spring; terminalul/consola sistemului de operare; Acum puteți rula prima aplicație Grails, • Aceasta va porni consola Grails și va executând comanda run-app în consola aștepta comanda ta: grails > Grails. Aceasta va porni applicația: http:// localhost:8080/GrailsSocialNetwork.

Există două IDE-uri care ajută deve- Bineînteles acesta este doar un template loperii foarte bine în dezvoltarea folosind fără prea multă valoare. Aplicația se poate Grails: porni si pe alt port rulând: run-app – • Intellij IDEA; Dserver.port=80 (va porni aplicația pe • Eclipse (and Spring Tool Suite) portul 80). și acum Groovy & Grails Tool Suite, ultimele două dezvoltate de Crearea claselor de domeniu VMware, având la bază Eclipse.

Să creăm acum clasele de domeniu pentru aplicația noastră. În primul rând, Momentan, folosim STS 3.10 cu avem nevoie de clasa User. Pentru a crea, support de Groovy și Grails bazat pe Eclipse vom folosi din nou consola Grails: create3.8.1. Am încercat Juno 4.2, dar laptopul de domain-class com.todaysoftmag.gsn.User. abia mai răspundea comenzilor, așa că am Aceasta va crea două fișiere: revenit la versiunea bazată pe Eclipse 3.8.1. | Created file grails-app/domain/com/

Crearea unei aplicații în Grails

Cea mai simplă metodă de a introduce Grails, este construirea unei aplicații web.

Exemplul din articol va fi despre o rețea socială (Grails Social Network) – datorită importanței rețelelor sociale în ziua de azi. Utilizatorii aplicației se vor putea loga, publica mesaje și vedea mesajele publicate de alții.

Crearea structurii aplicației

Folosind consola Grails, comanda create-app va crea o nouă aplicație Grails.

Sintaxa scriptului este simplă: create-app GrailsSocialNetwork (executată așa cum este descris în “Setarea Grails”, această comandă creează structura de directoare necesară Grails, care arată astfel(în directorul GrailsSocialNetwork): • application.properties – conține informații generale despre aplicație; • grails-app – conține majoritatea conținutului Grails cum ar fi controller, servicii, domenii, fișierele de internaționalizare, configurări, tag libs, clase utilitare, etc.; • lib – conține librăriile 3rd party folosite de aplicație; • scripts – conține scripturi Gant; • src – conține clase Java și Groovy folosite de logica aplicației; • test – conține Unit testele și testele de Integrare; • web-app – conține imagini, js, css și alte fisiere de configurare, incluzând fișierul de inițializare a contextului

30

nr. 6/2012 | www.todaysoftmag.ro

asemenea, Grails permite crearea de validatori customizați pentru a defini contrângeri avansate domeniilor unei aplicații, dar vom discuta despre ei în articolul următor.

Să adăugăm acum și cealaltă clasă domeniu, numită Message. Aceasta va conține un mesaj postat de un utilizator.

Folosind consola Grails: create-domainclass com.todaysoftmag.gsn.Message.

Comanda va genera clasa domeniu și unit testul asociat. Să adăugăm câteva attribute și o constrângere clasei Message: String message Date date = new Date() static constraints = { // mesajul nu poate fi gol si trebuie // să aibă lungimea între 5 și 100. message size:5..100, blank:false

}

Pentru a construi structura de stocare a datelor unei aplicații, Grails trebuie să știe relația dintre obiectele aplicației. În todaysoftmag/gsn/User.groovy aplicația noastră există două relații: | Created file test/unit/com/todaysoftmag/gsn/UserTests.groovy Un user poate avea mai multe mesaje.

Primul fișier este clasa domeniu, iar al Această relație va îmbogăți clasa User cu un doilea este clasa de unit test asociată. Să nou atribut: messages. Mai jos este definite încercăm acum să folosim sintaxa Groovy relația: și să adaugăm context clasei noastre dome- static hasMany = [messages: Message] niu. Groovy este asemanator sintactic cu Un mesaj aparține unui utilizator, Java, dar suportă structure dinamice și nu însemnând că nu poate exista fără a fi asoeste strict cu tipurile datelor. ciat unui user. Această relație va îmbogății Pentru a adăuga atribute clasei User, clasa Message cu un nou atribut: user. Mai adaugă următoarele linii în clasă: jos este definită relația: String String String String

firstName lastName userName password

static belongsTo = [user: User]

Setarea datelor de test

Acum dorim să adăugăm niște limiMomentan, aplicația noastră nu are tări valorilor atributelor. Grails deja a nici un storage permanent. Grails folosește creat un closure gol pentru adăugarea de în mod normal o bază de date în memoconstrângeri: rie care nu are persistență. Dar, putem să static constraints = { ne creăm noi niște date de test. Pentru //atributul “firstName” nu poate fi //gol si trebuie să aibă lungimea aceasta, trebuie să specificăm o listă de //între 3 și 10 obiecte pe care le dorim create la pornifirstName size: 3..10, blank:false //atributul “lastName” nu poate fi rea aplicației. La pornire, Grails apelează //gol si trebuie să aibă lungimea //între 3 și 10 closure BootStrap.init. Localizează clasa și lastName size: 3..10, blank:false adaugă bucata de code de mai jos: //atributul “username” nu poate fi //gol, trebuie să fie unic între toate //obiectele de tip User și trebuie să //aibă lungimea între 3 și 10 userName size: 3..10, blank:false, unique:true //atributul “password” trebuie să //aibă dimensiunea între 3 și 10 password size: 3..10

}

def init = {servletContext -> def user1 = new User(firstName: „John”, lastName: „Doe”, userName: „jdoe”, password: „passwd”) def user2 = new User(firstName: „Joanne”, lastName: „Doe”, userName: „jodoe”, password: „passwd”) user1.addToMessages(new Message(message: „Good morning!”)) user1.addToMessages(new Message(message: „Nice movie: Skyfall!”)) user2.addToMessages(new Message(message: „Waiting for the summer...”))

În cazul în care oricare dintre aceste constrângeri va fi încălcată (verificarea este făcută prin apelul metodei “validate” disuser1.save(failOnError:true) user2.save(failOnError:true) plonibilă in fiecare clasă domeniu), Grails } va completa erorile în atributul “errors” al De asemena, observăm că mai există clasei User. Apoi, controller-ul este cel care un closure “destroy” care se apelează când va decide ce se va întâmpla mai departe. De aplicația este închisă, deci poate fi folosit

TODAY SOFTWARE MAGAZINE

pentru a executa operații de cleanup, etc.

Crearea controllerilor

Controllerii sunt cei care determină flow-ul unei aplicații. Deoarece Grails folosește “convenție și nu configurare”, numele unui controller este de genul <ClasaDomeniu>Controller, deci vom create UserController și MessageController.

Pentru crearea de controller, Grails oferă un script numit create-controller. Rulând create-controller com.todaysoftmag.gsn.

UserController, Grails va crea clasa controller, testul asociat și un folder pentru fișierele de view pe care le vom discuta în capitolul următor: | Created file grails-app/controllers/ com/todaysoftmag/gsn/UserController. groovy | Created file grails-app/views/user | Created file test/unit/com/todaysoftmag/gsn/UserControllerTests. groovy

Acum, repetăm exercițiul pentru a crea MessageController. Momentan, controllerii nostri nu fac prea multe, dar vom schimba aceasta în următoarele capitole.

Autentificarea aplicației

O modalitate de autentificare a aplicației este folosirea filtrelor. Pentru a crea un filtru, rulăm create-filters com.todaysoftmag. gsn.SecurityFilters. Aceasta va crea clasa Groovy și testul asociat. În filtru vom adăuga un closure care va verifica existența unei sesiuni de utilizator înainte de procesare oricărui request pentru fiecare controller și acțiune: def filters = { loginCheck(controller: ‚*’, action: ‚*’) { before = { if (!session.user && actionName != „login”) { redirect(controller: „user”, action: „login”) return true } } } }

În cazul în care nu există un obiect “user” pe sesiune, aplicația va redirecta user-ul spre controllerul “user” și acțiunea “login”, care va renderiza view-ul de “login” pe care îl discutăm în “Crearea viewurilor”.

Altfel, logica aplicației va continua. În UserController, vom adăuga acțiunea de “login” care va procesa autentificarea unui utilizator:

} } render(view: „login”, model: [message: „Wrong username or password!”])

}

Acțiunea va verifica username-ul și parola pentru potrivire și va adăuga obiectul “user” găsit pe sesiune, iar apoi va redirecta aplicația spre pagina care afișează lista de mesaje pentru user. Altfel, utilizatorul va primi un mesaj de eroare și va vedea din nou pagina de login.

Câteva lucruri de menționat aici: • “;” nu este obligatoriu pentru a delimita linii de comandă Groovy; • Controller-ii au acces la obiecte Groovy specifice cum ar fi: request, params, session, etc și metode pentru a manipula view-urile, cum ar fi render, redirect, etc.; • Valoarea tipurilor de date nu este verificată la compilare; • If (u) se evaluează ca adevărat dacă u are valoare, sau false în caz contrar.

• GORM (Groovy Object Relational Mapping) oferă modalități la îndemână de a selecta date. In cazul nostru, verificăm dacă există un User care are “username” egal cu cel specificat în formul de login (params. username).

• “Render” apelează un view cu parametri specifici și produce pagina HTML • [ “ 1 ”, “ 2 ” ] e s t e u n ș i r, i a r [model:modelObj. User:userObj] este o mapă • “Redirect” redirectează aplicația spre un controller și acțiune. Dacă controller-ul nu este specificat, redirectul se va face în controller-ul current spre acțiunea specificată.

• Metodele nu specifică foarte clar valoarea returnată (nu trebuie returnată o valoare neapărat sau diferite tipuri pe diferite căi de execuție, deci va trebui să fim atenți pentru că aceasta poate cauza probleme la runtime. Am văzut la un moment dat “MissingMethodException” în logurile aplicației noastre.)

def login() { if (request.get) { return } //this is for loading login view def u = User.findByUserName( params.username) if (u) { if (u.password == params.password) { session.user = u redirect( controller: „messages”, action: „list”)

www.todaysoftmag.ro | nr. 6/2012

31

programare

Exemple practice de message paterns pentru Windows Azure

Î

n cadrul acestui articol vom discuta două design patern-uri pe care le putem folosii când trebuie să rezolvăm anumite probleme într-o solutie enterprise.

Cele doua soluţii care urmează să fie prezentate se bazează pe Windows Azure Service Bus. Acesta este un sistem de distribuire de mesaje oferit de către Microsoft.

Pentru a îl putea folosi nu este necesar să instălam sau să configurăm nici un server.

Radu Vunvulea

Radu.Vunvulea@iquestgroup.com Senior Software Engineer @iQuest, proiectele pe care lucrează sunt de tip LoB, în general folosind ultimele tehnologii Microsoft. Face parte din grupul entuziaștilor, motiv pentru care ii place să fie la curent cu tot ce apare nou in domeniul IT, in special din punct de vedere software.

32

nr. 6/2012 | www.todaysoftmag.ro

Toată infrasctructura stă în cloud. În principal acest mecanism se folosește când avem nevoie de distribuire mesaje spre un singur consumator sau spre mai mulţi consumatori.

Când mesajele sunt distribuite la un singur consumator atunci putem să folosim Windows Azure Service Bus Queues. În cazul în care avem nevoie ca același mesaj să ajungă la mai multi ascultători putem să apelăm la Windows Azure Service Bus Topics. Prin intermediul acestui mecanism putem să distribuim acelaşi mesaj la mai mulţi consumatori. Fiecare consumator poate să filtreze mesajele şi să accepte doar mesajele care respecta o anumită regulă.

Toate problemele legate de persistarea datelor, operaţii tranzacţionale sau death lock-uri sunt rezolvate de către Windows Azure Service Bus. Haideţi să vedem ce problemă putem să rezolvăm cu acest serviciu. Să ne imaginam că avem un client care se ocupă cu distribuirea de produse alimentare în toata ţara.

Acesta se ocupa cu distribuirea acestor produse la diferite magazine – atât magazine de cartier cat şi hiper-marketuri. În funcție de perioada anului, a cursului leu-euro sau a datei de expirare a produselor dorim să oferim un API prin care magazinele pot să fie notificate. În funcţie de client, reducerile pot să difere.

Fiecare magazin foloseşte aplicaţii diferite, din această cauză oferirea unei aplicaţii care să facă acest lucru este exclus. Clientul nostru doreşte să expună aceste date, iar fiecare magazine îsi poate implementa integra această funcţionalitate în sistemul propriu.

O soluţie la acesta problemă este să folosim Content-Based Router Message Pattern. Acest patern se bazează pe capacitatea de a trimite mesajele la fiecare

consumator în parte în functie de datele pe care mesajul le conţine.

Fiecare ofertă pe care clientul nostru o va adăuga va fi reprezentată printr-un mesaj care pe langă datele de preț va conține şi atributele care specifică la ce magazine trebuie să ajungă. De exemplu, vom putea specifica ca mesajele să fie trimise doar la magazinele Tip Top dintr-o anumită regiune. Alte oferte dorim să le trimitem doar la hiper-marketuri.

Acestă soluţie poate să fie implementată extrem de uşor folosind Windows Azure Service Bus Topics. Fiecare mesaj care urmează să ajungă într-un topic urmează să conţină atributele care specifică magazinele care urmează să fie notificate.

Fiecare magazin urmează să aibă o subscripţie unică. În cadrul acestei subscripție vor fi specificate datele despre magazine precum nume, regiune, adresa, tip magazin. Subscripţiile urmează să fie create doar de către clientul nostru, iar magazinele doar doar se vor inregistra la aceste subscripţii. În momentul în care va exista un mesaj disponibil pentru acestea, ele îl vor primi automat.

Clientul nostru va fi extrem de fericit datorită faptului că este nevoit să trimită notificări diferite pentru fiecare magazin în parte. Acesta va putea crea un singur mesaj, în care să specifice cui îi este adresat.

Primul pas este să cream topicul şi câte o subscripţie pentru fiecare magazin în parte. Urmează să creez doar două subscripţii în cadrul acestui exemplu.

NamespaceManager namespaceManager = NamespaceManager.CreateFromConnectionString( CloudConfigurationManager.GetSett ing(“ServiceBusConnectionString”)); if (!namespaceManager.TopicExists(„di stributionTopic”)) { namespaceManager.CreateTopic(„dis tributionTopic”); }

TODAY SOFTWARE MAGAZINE SqlFilter tipTop100Filter = new SqlFilter(„ region LIKE ‚%Banat%’ OR shopName = ‚Tip Top’ OR shopType = ‚family’”); namespaceManager.CreateSubscription( distributionTopic”, „TipTopShop100Subscription”, tipTop100Filter); SqlFilter stefan20Filter = new SqlFilter(„

region LIKE ‚%Moldova%’

OR shopName = ‚Stefan’

OR shopType = ‚minimarker’”); namespaceManager.CreateSubscription( „distributionTopic”, „stefan20Subscription”, stefan20Filter);

Odată create aceste subscripţii, putem să începem să distribuim mesajele. Fiecare client va fi notificat când o nouă promoţie este disponibilă. În orice moment putem să adaugăm, modifica sau sterge o subscripţie, fără să fie necesar să oprim sistemul sau să notificăm clienţii.

Fiecare magazin umează să fie notificat în mod automat. În cazul în care aplicaţia sa nu este pornită, mesajul va fi păstrat până când va devini activ. Fiecare mesaj poate să conțină şi un expiration date. Windows Azure Service Bus Topics urmează să șteargă în mod automat mesajele care au expiration date invalid. Tot ce trebuie să trimitem la fiecare magazin în parte, pe lângă datele de autentificare şi numele la topic, este numele la subscripţie. Pentru aceştia, putem să creeăm o componentă care se ocupă automat de acest lucru. Codul care poate să extragă mesajul din subscripţie ar fi următorul: SubscriptionClient subscriptionClient = SubscriptionClient.CreateFromConnectionString( CloudConfigurationManager.GetSetti ng(„ServiceBusConnectionString”), „distributionTopic”, „stefan20Subscription”); while(true) { BrokeredMessage offerMessage = subscriptionClient.Receive(); if (message != null) { try { ... offerMessage.Complete(); } catch (Exception) { offerMessage.Abandon(); } } } }

După cum puteti să observaţi, în cazul în care oferta nu este procesată cu success, oferta nu va fi pierdută şi va fi procesată din nou de către magazin.

Odată ce am creat subscripţiile pentru fiecare magazine în parte, tot ce ne rămane de făcut este să adaugăm mesajul în topic.

Acesta va ajunge la toate magazinele pentru care filtrul de pe subscripţii va returna TRUE. TopicClient distributionTopicClient = TopicClient.CreateFromConnectionString( CloudConfigurationManager.GetSetti ng(„ServiceBusConnectionString”), „distributionTopic”); BrokeredMessage offerMessage = new BrokeredMessage();

offerMessage.Properties[„region”] = „Banat Moldova”;

adaugat doar filtre. Fiecare filtru poate să fie însoţit de un nume. Totodată, în loc de filtre putem să adăugăm reguli, iar fiecare distributionTopicClient.

Send(offerMessage); regulă să aibă un nume unic. În general, o În exemplul de mai sus am văzut cât de regulă conţine câte un filtru. usor este să distribuim ofertele la mai multe SubscriptionClient groupFirstRegionSubscription = SubscriptionClient. magazine fără să ne punem problema dacă CreateFromConnectionString( CloudConfigurationManager. magazinul va primi sau nu mesajul. Iar GetSetting( „ServiceBusConnectionString”), modul în care specificăm ce magazine tre„commandTopic”, „groupFirstRegionSubscription”); buie să primeasca oferta dată este extreme SqlFilter groupFirstRegionFilter = de simplu. new SqlFilter(„ region LIKE ‚%Moldova%’ Din punct de vedere al scalabilitaţii, OR region LIKE ‚%Banat%’”); un topic poate să aibă pană la 2000 de sub- groupFirstRegionSubscription.

AddRule(„ruleForMoldovaAndBanat”, scripţii. Aceasta nu înseamnă că suntem groupFirstRegionFilter); limitați doar la 2000 de mesaje. Ne este groupFirstRegionSubscription.

RemoveRule( extrem de usor să includem un alt topic. „ruleForMoldovaAndBanat”); SqlFilter banatRegionFilter = În continuare ne imaginăm clientul new SqlFilter(„ region LIKE ‚%Moldova%’”); nostru venind cu următoarea cerinţă. Din groupFirstRegionSubscription. cauză că s-a extins extrem de mult în ultiAddRule(„ruleForMoldovaAndBanat” ,banatRegionFilter); mul timp, şi-a creat responsabili regionali care se ocupă de procesarea comenzilor În exemplul de mai sus am adăugat un pe care le face fiecare magazin. Din cauză filtru pe care apoi l-am şters, iar apoi am că nu cunoaste modul în care piaţa se va adăugat o nouă regulă. Aceste reguli se dezvolta, clientul nostru are nevoie să gru- aplică automat din momentul când sunt peze mai multe regiuni, iar apoi cu costuri adăugate. minime să poată împarţi din nou regiuPrin acest mecanism, putem să schimnile. Totodata pentru a putea supraveghea băm în mod dinamic regiunile deservite de activitatea pe care aceştia o au, el dorește către un responsabil. În cazul în care este sa creeze un mecanism de audit, iar toate nevoie, avem posibilitatea să adăugam sau comenzile trimise de către magazine să fie să stergem o subscripţie ori o regulă fără să înregistrate. fie necesar să oprim sistemul.

Ca să rezolvăm aceasta cerinţă, putem O altă cerinţă a clientului nostru era să apelăm la Dynamic Router Message ca toate comenzile să fie salvate, pentru a Pattern. Acest patern ne permite să ne putea să fie mai tarziu verificate. Această definim o listă de reguli de direcţionare a cerinţă este ca şi implementată. Avem mesajelor, care poate să fie schimbată la nevoie să adaugăm o subscripţie care nu are runtime fară nici un fel de probleme. nici o regulă sau nici un filtru definit. Mai Iniţial clietul nostru va porni doar cu simplu de atât nici nu putea să fie. două grupuri de regiuni, iar în timp, în namespaceManager.CreateSubscription( „commandTopic”, functie de cum se schimbă piaţa, acesta o „allCommandsSubscription”); să își defineasca grupe de regiuni mai mici.

Fiecare magazin va trebui să creeze Fiecare grupare de regiuni va avea cate o un mesaj pentru fiecare comandă, unde subscripţie care aceptă comenzile pentru ‘region’ va fi setat în mod automat cu regio listă de regiuni. Nu vom mai prezinta unea din care face parte. modul în care se crează un topic, acest Dacă vă puneţi problema costului, trelucru l-am văzut puţin mai sus. buie să vă zic că șase milioane de mesaje SqlFilter groupFirstRegionFilter = trimise prin intermediul Windows Azure new SqlFilter(„ region LIKE ‚%Moldova%’ Service Bus ne costa 6$, dacă 10 magazine OR region LIKE ‚%Banat%’”); namespaceManager.CreateSubscription( ascultă 24 de ore din 24 la o subcripţie ne „commandTopic”, „groupFirstRegionSubscription”, costa circa 7$ pe lună. În viitor este posibil groupFirstRegionFilter); ca aceste preţuri să scadă şi mai mult.

Această primă subscripţie va deservi În cadrul acestui articol am văzut cat două regiuni. În cazul în care clientul nos- de usor este sa distribuim mesaje folosind tru hotărăste ca cele doua regiuni să fie infrastructura pe care Windows Azure deservite de persoane diferite va fi necesar o pune la dispozitie. Paternuri precum să modifice această subscripţie şi să adauge Content-Based Router Message Pattern şi o altă subscripţie.

Dynamic Router Message Pattern pot să Pentru fiecare subscripţie se poate adă- fie implementate cu uşurinţă şi cu costuri uga sau şterge o regula la runtime. În acest minime. Scalabilitatea ne este oferită buildcaz putem să ștergem regula deja definită in de către Windows Azure. şi să adăugăm altă regulă. Pană acum am offerMessage.Properties[„shopType”]= „family”;

www.todaysoftmag.ro | nr. 6/2012

33

management

Poți fi agile în proiecte de preț fix?

M

etodologiile de tip agile sunt tot mai preferate de către dezvoltatorii de software într-o lume în care cerințele funcționale, dictate de dinamica pieței, se schimbă continu iar timpul cât mai redus în care produsul software trebuie să ajungă în folosința utilizatorilor finali are o pondere tot mai mare în obținerea rezultatelor dorite.

Claudiu Anghel

claudiu.anghel@iquestgroup.com Project Manager @iQuest Certified ScrumMaster are 11 ani de exepriență în domeniu, conduce echipe mari, dezvoltă soluții software pentru eCommerce, Airline, Telecom; experiență în aplicarea diferitelor metodologii: waterfall, RUP, Agile / SCRUM

În același timp foarte multe companii care au nevoie de produse software nu sunt dezvoltatori software și operează într-o piață tot mai apăsată de constrângeri de cost și timp; marea majoritate a acestor companii doresc livrarea produselor software în condițiile unui proiect de preț fix. Prin proiect de preț fix înțelegem că de la bun început stabilim împreună cu clientul: • Scopul (cerințe funcționale și nefuncționale); • Termenele de livrare; • Prețul. În cele va fi prezentată experiența pe care am avut-o în contextul unui proiect software de preț fix din domeniul telecom, unde elementele agile ne-au ajutat să livrăm la timp funcționalitățile cerute în condiții de profitabilitate.

Clientul, o companie care dezvoltă produse software pentru operatorii de telefonie mobilă, avea în dezvoltare o soluție ce consta din mai multe sisteme; sistemul din partea de backend nu dispunea de un GUI de administrare; clientul a dorit un partener care să dezvolte acest Admin GUI în condițiile unui proiect de preț fix pentru a avea garanția livrării în condiții invariabile de preț, scop, termen de livrare. Datorită termenelor strânse de proiect a fost nevoie de începerea dezvoltării aplicației de administrare în paralel cu dezvoltarea sistemului

34

nr. 6/2012 | www.todaysoftmag.ro

din backend. Ca urmare a rezultat următorul context la startul proiectului: • Specificații funcționale cu un nivel de detaliere insuficient; • Servicii externe indisponibile pentru integrare; • Detaliile tehnice de integrare necesitau clarificări semnificative.

Ce am făcut noi? Inițial am implicat colegi cu experiență tehnică mare pentru a analiza specificațiile existente și bazat pe analiza lor am făcut o ofertă de preț fix. Ulterior după ce oferta noastră a fost acceptată, am creat echipa de proiect și proiectul a început; ca manager de proiect prima intenție a fost de a crea un plan de proiect mai detaliat cu task-uri granulare, cu dependențe, repartizare în echipă, identificare de potențiale căi critice etc. . Din primele zile discutând cu echipa am realizat că, dat fiind contextul de proiect, acest lucru nu este fezabil. M-am gândit atunci la avantajele pe care le aduc elementele din metodologiile de tip agile: • Angajamentul echipei în locul unui plan de proiect impus; • Responsabilitatea echipei de a se organiza; • Colaborare în echipă, între echipă și client, 3rd parties pentru a clarifica și rezolva (în cazul nostru aceasta includea clarificarea specificațiilor funcționale, a detaliilor de integrare

TODAY SOFTWARE MAGAZINE cu sistemele externe).

Am realizat că nu am cum să impun echipei un plan forțat și fiind clar că avem în față un proiect cu riscuri și provocări, era esențial ca echipa să creadă pas cu pas în angajamentele intermediare și să fie cea care are responsabilitatea atât în a influența modul de avansare al proiectului cât și de a livra conform cu angajamentele luate. În primele zile, săptamâni, specificațiile fiind insuficient de clare, energia echipei a mers pe lângă clarificările de specificații către engineering practices: a fost pus pe roate încă de la început un proces care includea: • Task & bug tracking, • Source control, • Packaging, • Continuous Integration (CI), • Unit testing & Mocking, • Code coverage, • Code review.

Serviciile externe nefiind oricum încă disponibile, s-a pus la punct un mod de a utiliza stub-uri în locul acestor servicii.

Pe parcurs echipa a fost cea care a găsit pas cu pas soluțiile, a clarificat specificațiile, a găsit alternative, a discutat continuu cu clientul și a stabilit alternativele mai potrivite pentru înaintarea proiectului. A fost esențial faptul că am avut în cadrul echipei roluri specializate precum: • Business Analyst – la nivelul întregii soluții și nu doar pentru Admin GUI, • Software Architect – la nivelul întregii soluții și nu doar pentru Admin GUI, • User Experience specialist.

Acești colegi ne-au ajutat mult în clarificarea cerințelor, interacțiunea cu clientul, promovarea celor mai bune soluții care să ușureze progresul proiectului. Dacă facem o paralelă cu rolurile din SCRUM, ei au fost pentru noi Product Owner-ul din SCRUM și chiar mai mult. De asemenea, colegi din echipă au fost în mai multe rânduri onsite la client, dar și într-un workshop în locația

dezvoltatorului soluției din backend cu care trebuia să ne integram: ne-a ajutat mult, foarte multe lucruri s-au clarificat, comunicarea ulterioară a mers mult mai ușor – din perspectiva costurilor cred că a meritat deoarece clarificările de la distanță tind să treneze uneori (mai ales între supplieri diferiți) și întârzierile ca timp de livrare ar fi adus costuri mai mari.

Desigur că rulând într-un context de preț fix, nu am putut uita nici un moment de ceea ce am stabilit la început: termene de livrare, scop, cost. Pentru fiecare dintre acestea au fost câteva elemente care ne-au ajutat.

Termene de livrare: ne-am înțeles cu clientul de la început să avem două faze de livrare: soft launch și hard launch; fiecare din aceste faze a avut sub-faze corespunzătoare fazelor de testare pe care le avea clientul (și în context de telecom ele nu sunt puține); ca să ne încadrăm în termene am progresat faze diferite în paralel (de exemplu fază de testare de soft launch în paralel cu faza de development de hard launch) – aici procesul de code review, expunerea continuă a colegilor din echipă la zone diferite de cod a permis flexibilitate colegilor de a prelua task-uri diverse; comunicarea în echipă a fost continuă indiferent de locație (skype grup deschis permanent a ajutat); elementele de process engineering pe care le-am amintit deja au fost esențiale, ne-au ajutat să avem o calitate bună, am câștigat timp prin automatizarea build-urilor, rularea testelor automate și desigur mult mai puțin efort necesar pentru bug fixing.

Scop: așa cum am subliniat deja am discutat foarte mult cu clientul pentru a clarifica specificațiile: • În unele situații am stabilit cu clientul alternative mai bune și care s-au tradus în efort de dezvoltare mai redus – per ansamblu scopul nu s-a schimbat: nevoia GUI-ului de a articula toate funcționalitățile din backend a rămas neschimbată • În alte situații am arătat clar clientului că funcționalitatea cerută nu se regăsea în specificațiile inițiale

•

– aici am avut Change Requests (CRs) care au însemnat costuri adiționale, În alte situații ne-am adaptat noi având feedback prin release-urile intermediare (am avut multe release-uri având pentru fiecare din cele două faze principale de livrare (soft și hard launch) mai multe subfaze de testare).

Cost: dat fiind că am reușit să ne încadrăm în termenele de livrare și unde a fost cazul să obținem CRs, am reușit să ținem costul sub control și în final să avem un proiect profitabil; desigur faptul că echipa a reușit să livreze la timp, să înțeleagă ce are de făcut și sa găsească soluțiile potrivite a fost factorul cheie aici.

Ca o concluzie nu credem că răspunsul la întrebarea din titlu este da sau nu, 0 sau 1, el poate fi da în anumite condiții și poate fi nu în alte condiții. În cazul proiectului nostru a fost da și personal nu cred că am fi reușit altfel – dar am avut condițiile de care v-am vorbit. Încurajarea mea este de a investi cât mai mult în: • Responsabilizarea echipei, • I n t e r a c ț i u n e , c o m u n i c a r e , colaborare, • Engineering practices – calitate încă de la început, • Posibilitatea de a avea roluri specializate în propria echipă.

www.todaysoftmag.ro | nr. 6/2012

35

tehnologii

O incursiune prin atacurile informatice din 2012 și poziționarea României în războiul cibernetic

A

nul 2012 a fost unul dintre cei mai activi din istoria Internetului atunci când discutăm de atacuri informatice asupra unor sisteme și infrastructuri mari. Prin acest articol atingem un subiect sensibil referitor la securitatea IT în România prin prisma intervențiilor din țările străine folosind un top 10 al celor mai importante

Andrei Avădănei andrei@worldit.info Fondator si CEO DefCamp CEO worldit.info

36

nr. 6/2012 | www.todaysoftmag.ro

atacuri din 2012.

7. Yahoo! Voice Concluziile articolului încearcă să • un grup intitlulat D33DS Company scoată în evidență riscurile la care sunt au obținut prin SQL Injection supuse infrastructurile romanești și cât de aproape 454,000 de conturi Y! Voice bine suntem pregătiți pentru atacuri inforprintr-un simplu SQL Injection; matice serioase. Prezentarea clasamentului • parolele erau stocate în plain text. va fi realizat în ordine descrescătoare, în 6. Global Data Inc. (Visa & Master funcție de complexitatea și pagubele Card) făcute, dezvoltând un clasament realizat de • o breșă în sistemul de procesare a ThreatMatrix. datelor de card a dus la pierderea a 1.5 milioane de numere ale unor 10. GHOSTSHELL carduri bancare; • g r upu l A nony mou s i nt itu l at • breșa nu a dus și la pierderea datelor GHOSTSHELL a furat peste 120,000 de facturare nici a numelor. de înregistrări de la universități de 5. Microsoft Internet Explorer top din lume injectând malware în • o problemă de securitate descoperită site-uri; în septembrie permite hackerilor • printre facultăți se numără Harvard, să instaleze aplicații malițioase pe John Hopkins, The University of computerele personale; Michigan etc.

• 41% dintre utilizatorii din America 9. U.S Enviromental Protection de Nord sunt afectați de vulnerabiliAgency tate și peste 31% la nivel global; • o breșă în securitate a dus la compro• vulnerabilitatea de tip RCE(Remote miterea datelor a 8,000 de angajați și Code Execution) poate rula un alte conturi bancare; script de la distanță pe IE 6,7,8,9 dar • e amuzant că au fost necesare 4 luni nu pe 10; până când US EPA a anunțat persoa• nici IE 10 nu scapă pentru că există nele afectate. o vulnerabilitate în Flash ce este 8. Go Daddy folosită world wide.

• Anonymous și-a însușit numeroase 4. Android atacuri DDoS pe 10 septembrie; • în această toamnă a fost sesizat că • pentru o perioadă de timp au fost aproape 200 de milioane de teleafectate zeci de site-uri world wide, foane cu Android sunt în pericol de până și serviciile de email; a fi resetate complet, pierzându-se • Go Daddy a infirmat ipoteza. absolut toate datele de pe ele, existând posibilitatea distrugerii și a SIM-urilor; • sunt afectate telefoanele produse de Samsung, HTC, Motorola și Sony Ericsson și majoritatea versiunilor

UIX de Android sunt vizate; a fost scos patch dar până în acest moment doar versiunile foarte noi de mobile l-au aplicat.

3. Linkedin & eHarmony • în mai puțin de 24 de ore 65 de milioane de conturi de Linkedin au fost scăpate de sub control, 30,000 dintre acestea au fost sparte; • 1.5 milioane de parole eHarmony au fost furate și publicate pe un site de „spargere” a parolelor; • au fost diverse interpretări ale atacului, cert e că Linkedin a scăzut în ochii multora atunci.

2. Wells Fargo • site-ul a fost supraîncărcat printr-un atac de tipul DDoS; • estimările susțin că peste 70 de milioane de potențiali clienți au fost compromiși și peste 8.5 milioane de spectatori; • atacul și l-au însușit Cyber Fighters of Izz ad-din Al Qassam că protest împotriva unui videoclip anti-islamez apărut pe Youtube - Innocence of Muslims deși analizele ulterioare au scos la iveală că tehnologia și lista suspecților indică spre o implicare guvernamentală a Iranului; • au fost afectate mai multe bănci în timpul aceleiași campanii, printre care Bank of America, JPMorgan Chase, Citigroup, U.S. Bancorp.

1. Zappos / Amazon Inc. • un singur atac a dus la compromiterea a 24 de milioane de conturi Zappos / Amazon Inc.; • au fost comrpomise nume, adrese de email, numere de telefon, cărți de credit, adrese de facturare; • “The individual isn’t the value here — it’s the list that’s the value”, a declarat Rob Holmes, CEO al agenției de detectivi IPCybercrime. com în urma atacului; • una din cele mai mari greșeli ale celor de la Amazon e că după momentul cumpărării în 2009 a celor de la Zappos, aceștia le-au dat mână liberă pe partea de management și au făcut transfer de încredere ce s-a resimțit asupra lor; • Zappos a trimis un email tuturor utilizatorilor și le-au cerut să schimbe parolele aproape imediat.

•

TODAY SOFTWARE MAGAZINE targetate ce au vizat în ultima vreme atât Europa cât și orientul mijlociu. Nu trebuie să uităm că până și Google a fost vizat, printre alții la numeroase atacuri informatice targetate, extrem de complexe și bine puse la punct. Nu trebuie să uităm de Sony, de Flame, Duqu samd.

Unde se regăsește România în acest moment?

Răspunsul simplu e că ne aflăm pe teren neutru, dar, din păcate, din perspectiva geografiei virtuale suntem tot la mijloc. Mai rău decât atât, se pare că în acest moment suntem complet nepregătiți. Nu cred că suntem capabili să gestionăm un atac informatic asupra unei infrastructuri românești importantă, nu cred că suntem pregătiți să analizăm un atac informatic complex. De asemenea, nu cred că există vreun program de contra-ofensivă pregătit măcar teoretic, după cum nu cred și sunt aproape sigur că nu există echipe de intervenție care sa fie pregătite în acest sens și să știe exact ce e de făcut într-o astfel de situație. Într-adevar, în acest moment, din punct de vedere al tehnologiei, stăm puțin mai jos decât alte state Europene, dar în curând majoritatea cumpărăturilor, majoritatea facturilor și multe altele le vom realiza virtual. Infrastructura migrează spre Internet și nu suntem pregătiți pentru incidente. Nu există nici măcar promisiuni concrete care să susțină în acest moment niște inițiative adevărate pentru dezvoltarea internă la incidente din spațiul cibernetic. Dacă China, Iran, Israel, SUA, Rusia și numeroase alte țări din Europa și din afara ei au investitiții semnificative în aceasta direcție și au chiar echipe oficiale de intervenție, de cercetare, de spionaj, de contra-ofensivă pentru spațiul cibernetic, noi încă discutăm despre înființarea programelor de protecție cibernetică la modul general.

Ne putem uita și la vecini, iar unul în cunoștință de cauză e chiar Ungaria. Are cel mai mare eveniment de securitate informatică din Europa de Est, de aproape un deceniu, a deschis Crysys, un centru de cercetare malware care a contribuit la cele mai complexe și populare analize din istoria noastră ca planetă tehnologizată – Stuxnet, Flame, Duqu etc. .De asemenea, are au un sistem CERT mult mai bine pus la punct și lista continuă.

din domeniul INFOSEC & hacking din România de până acum, fiind așteptate în capitală aproape 250 de persoane, ce vor asista la peste 20 de prezentări susținute de speakeri din cinci țări.

Evenimentul va avea loc in perioada 30 noiembrie – 2 decembrie la Hotelul Yesterday in București și promite o conferință de trei zile desfășurată în cele mai bune condiții pentru ca orice participant să poate interacționa cu numeroase persoane cu experiență vastă în domeniul INFOSEC. Pe parcursul celor trei zile, participanții vor putea urmări numeroase prezentări susținute de oameni cu experiență în domeniul INFOSEC, vor putea monitoriza Wall of Sheep, ar putea participa la concursul DCTF (DefCamp Capture the Flag) sau își vor putea pune site-ul la dispoziția unei echipe de testare. Evenimentul din această toamnă atinge în cele peste 20 de prezentări subiecte precum 0days, captcha breaking, mail security, digipass bypass, mobile security problems, DDOS, networking, P2P networks, D&D APT’s, social engineering și lista continuă, prezentările fiind susținute atât de specialiști din România cât și din străinătate.

Competiția DCTF (DefCamp Capture the Flag) va avea o etapă de pre-calificări online urmată de un duel în timpul evenimentului între echipele finaliste. Temele competiției sunt extrem de variate și provocatoare – exploits, cryptography, programming, steganography, forensics, reverse engineering, aceste subiecte fiind atinse în 30 de probleme din etapa de calificare.

Una dintre noutățile cu care vine DefCamp 2012 @Bucuresti este DHME (DefCamp Hack ME). Orice participant își poate înscrie website-ul, aplicația sau proiectul iar echipa DHME se va ocupa pe perioada evenimentului de analiza și realizarea unui audit de securitate asupra lui. La finalul evenimentului, cei înscriși vor primi pe email câte un raport cu privire la analiza făcută.

Poate mai e o șansă. :-)

Noi ce avem? DefCamp – conferință

Deși aceste atacuri au fost extrem de hacking & securitate! de mediatizate, acestea sunt doar cireașa Aflată la a treia ediție, DefCamp 2012 de pe tort, sunt informațiile care ies la @Bucuresti (http://defcamp.ro) este una suprafață. Nu trebuie să uităm de atacurile dintre cele mai importante inițiative www.todaysoftmag.ro | nr. 6/2012

37

management

Agile, crash course

O

rice revistă dacă am deschide sau la orice conferinţă am merge, cu certitudine am da peste un articol sau o prezentare despre Agile. Toată lumea vorbeşte despre Agile şi agilitate, experţii au apărut şi ei în cantităţi uriaşe şi orice companie, cu atât mai mult în software, pretinde că face Agile. Cei mai sceptici, rămân rezervaţi şi aşteaptă să treacă „moda asta cu Agile”. Doar că „moda” nu numai că nu trece, au trecut deja mai bine de 10 ani de când a apărut, ba chiar tinde să se dezvolte dacă nu chiar să explodeze. Nokia, Microsoft, Adobe, Google, Philips, Siemens, Yahoo sunt nume grele care

Florian Ivan, PMP, ACP, CSM, MVP florian.ivan@rolf-consulting.com Project MVP

38

nr. 6/2012 | www.todaysoftmag.ro

au pariat pe Agile. Având în vedere mizele uriaşe, parcă am tinde să ne luăm după ei. Mai mult chiar, „rigidul” PMI (Project Management Institute) a creat chiar o certificare specială pentru Agile demumită Agile Certified Practitioner (ACP). Deși a fost lansată cu numai câteva luni în urmă, ACP numără deja peste 1000 de certificaţi la nivel mondial. Aşadar, pare un lucru serios, în plină dezvoltare şi plin de învăţăminte. Nu ne rămâne decât să îi acordăm importanţa cuvenită.

Agile nu este un silver bullet. Sunt încă multe domenii în care abordarea tradiţională, waterfall, încă dă foarte multe rezultate. Datorită naturii sale iterative, Agile îşi găseşte o aplicabilitate perfectă în situaţiile în care scopul proiectului nu este sau nu poate fi definit în detaliu încă de la început precum şi în mediile supuse unor schimbări frecvente. Fie că este vorba de un client care se răzgândeşte în fiecare zi sau într-o piaţă extrem de dinamică ce comportă modificări succesive într-o perioadă scurtă de timp.

Pentru cei mai mulți Agile înseamnă sprinturi, daily stand ups şi backlog. Ceea ce este corect, dar nu şi complet. Agile este mai degrabă o mişcare, un curent chiar o atitudine. Era să folosesc cuvântul

„filosofie”, dar e un cuvânt care are colţurile atât de tocite că e greu să mai discerni ce ascunde. Agile este o umbrelă mare sub care se adăpostesc lucuri mai concrete, mai palpabile cum sunt cele menţionate mai sus: sprinturi, review-uri şi retrospective, product sau sprint backlog. Acestea constituie partea mai pământeană a filosofiei Agile şi anume unelte puse la dispoziţie de unele metodologii. Agile nu este o metodologie, este o grupare de metodologii. Şi aceste metodologii, cel puţin cele mai faimoase sunt: Scrum (atât de faimos că este confundat de multe ori chiar cu Agile), XP (extreme programming), Kanban, Lean, FDD. Problema cea mai mare cu metodologiile este că ele nu funcţionează. Pare ciudată afirmaţia? Cel puţin asta e ce tot aud de la foarte multe companii. Că oricare dintre metodologii ar folosi (deşi în 99% din cazuri este vorba despre Scrum), cei mai mulţi spun că de fapt metodologia este bună dar mai trebuie adaptată la specificul companiei. Pentru că, nu-i aşa, fiecare dintre noi suntem foarte speciali şi nicio metodologie nu ni se potriveşte. Prima întrebare care vine în minte în asemenea situaţii este „de cât timp folosiţi Agile?” urmată invariabil de răspunsul: „abia acum implementăm”.

TODAY SOFTWARE MAGAZINE Dincolo de perplexitatea că putem judeca, uneori atât de dur, o metodologie fără să o cunoaştem suficient, recomandăm tuturor celor aflaţi la început de drum modelul ShuHaRi al lui Alistair Cockburn (Agile Software Development: The Cooperative Game, 2007 sau, mai simplu, Google it) în care unul dintre fondatorii acestei mişcări vorbeşte exact despre asta. Înainte de a emite orice judecată, foloseşte o metodologie până îi decoperi limitele. Abia apoi poţi spune care îi sunt limitările. Este suficient să ne gândim la numele mari pe care le-am dat la începutul articolului şi să constatăm că daca metodele Agile funcţionează pentru ei şi pentru noi nu, probabil facem ceva greşit. Şi acum să ne uităm rapid la fiecare dintre metodologiile prezentate mai sus. Începem cu cea mai titrată dintre ele, Scrum. Această metodologie, ca mai toate celelalte, se caracterizează printr-o producţie iterativă şi incrementală a scopului final al proiectului. Ceea ce înseamnă că, la început facem un schelet asupra căruia tot revenim până când seamănă cu ceea ce îşi doreşte clientul. Atenţie, clientul de cele mai multe ori nu ştie ce îşi doreşte de fapt şi are nevoie de aceste increment-uri de funcţionalitate pentru a afla. Rolurile tipice pentru un proiect Scrum sunt: Product Owner (responsabil cu maximizarea valorii a ceea ce se livrează), echipa de dezvoltare (responsabilă cu livrarea unui potentially releasable, increment de funcţionalitate) şi un Scrum Master (responsabil cu împărtăşirea conceptelor de Scrum către echipă şi respectarea proceselor specifice). Documentele cele mai uzual folosite în Scrum sunt: product backlog (lista de cerinţe prioritizată în funcţie de valoarea pentru client a fiecărei funcţionalităţi), sprint backlog (un subset din product backlog care va întra în producţie în sprintul imediat următor), burndown/ burnup charts (pentru ilustrarea evoluţiei cumulative a progresului). Ceremoniile din Scrum sunt: daily stand-ups (întâlnirea zilnică a echipei în care fiecare membru spune despre ce a lucrat ieri, la ce va lucra azi şi ce eventuale piedici sau probleme întâmpină), sprint planning meetings (în care product ownerul şi echipa decid ce se va livra în sprintul următor), sprint review (în care se discută ce anume s-a livrat în sprintul proaspăt încheiat) şi sprint retrospective (în care se analizează modul cum echipa a lucrat, dacă s-au respectat toate procesele, etc.).

A doua metodologie, în ordinea faimei şi răspândirii este XP - Extreme

Programming. În mod sigur niciun client întreg la cap, nu şi-ar dori ca proiectul lui să fie gestionat într-o chestie care include cuvântul „extreme”. De aceea, este nevoie să înţelegem bine ce se ascunde în spatele acestei metodologii şi, de ce nu, chiar să i-o prezentăm şi clientului drept „poliţă de asigurare” pentru proiectul său. Valorile pe care XP le promovează sunt: comunicarea, simplitatea, curajul, feedback-ul şi respectul. Când veți citi în cele ce urmează despre practicile XP, în mod sigur le veţi pune cap la cap şi veţi înţelege ce e cu aceaste valori. Rolurile din XP sunt (poate vreţi să aruncaţi o privire mai sus pe rolurile din Scrum înainte de a citi mai departe): coach (este mentor şi facilitator pentru echipă), customer (stabileşte ce anume se dezvoltă şi în ce ordine), programmer (cred că este evident ce face el!), tester (vom vedea imediat că XP are un mare focus pe testare).

Menţionam mai sus practicile XP. Ele sunt cele care transformă o teorie în ceva foarte practic şi pragmatic. Acestea sunt: small releases (vă aduceţi aminte de incremental?), whole team (XP este un fel de echipă de muşchetari în care toţi trag pentru echipă), system metaphor (funcţionalitatea de implementat trebuie descrisă cât mai clar), test-driven development (testele sunt stabilite şi scrise încă înainte de a începe dezvoltarea), simple design (clientul trebuie să vadă repede ceva funcţional), refactoring (curaţarea codului fără a-i schimba efectul), continuous integration (fiecare membru trebuie să ofere propria contribuţie tot timpul), collective code ownership (întreaga echipă lucrează la cod şi oricând membrii echipei se pot roti între ei), planning games (Google „planning poker”!), coding standards (fără de care nu poţi avea codul partajat cu toată echipa), sustainable pace (toată lumea în acelaşi ritm, pe toată durata proiectului = fără ore suplimentare), pair programming (doi programatori la un calculator lucrează la acelaşi cod) şi customer tests (clientul, foarte implicat în proiect este parte din echipă şi îşi aduce aportul). Parcă nu mai pare aşa extrem, nu?

Kanban este una dintre cele mai noi metodologii apărute în peisajul Agile şi vine, aşa cum şi banuiaţi, de la japonezi.

Kanban se uită la tot fluxul pe care îl are un proiect, cu toate fazele şi etapele sale şi se concentreză pe a limita ceea ce se numeşte work in progress. Lucrurile sunt foarte simple şi pornesc de la principiul că, dacă te apuci de mai multe lucruri în acelaşi timp , probabil nu vei termina niciunul şi nici nu vei face o treabă foarte bună. Secretul este

să îţi limitezi acest work in progress după ce ai aflat care este limita la care performezi cel mai bine fără să îi faci pe alţii să aştepte după tine.

Lean, foarte la modă şi el alături de Kanban, cu care se şi aseamănă. Lean priveşte şi tot fluxul proiectului şi împarte toate activităţile în activităţi care aduc valoare şi activităţi rezidue (denumite waste). După cum probabil intuiţi, tot secretul este să reduci cât mai mult activităţile waste astfel încât cea mai mare parte din munca făcută la un proiect să fie de valoare. Şi mai simplu, prin lean aflaţi cât de mult staţi pe Facebook în timpul unui proiect. Şi da, Facebook e considerat waste!

FDD (Feature Driven Developement) este extrem de popular în special în dezvoltarea de aplicaţii software. Procesul are cinci paşi şi urmăreşte: construirea unui model general, construirea unei liste de feature-uri care trebuie dezvoltate, planificarea în funcţie de aceste feature-uri iar apoi design-ul şi dezvoltarea fiecărui feature.

Cei mânaţi de curiozitate veţi descoperi că mai există şi alte metodologii demne de interes (Crystal şi DSDM sunt doar doua dintre ele) dar cele menţionate mai sus sunt nucleul mişcării Agile. Pare simplu, nu-i aşa? Din păcate, aceasta este şi marea problemă cu implementarea lor.

Tocmai pentru că totul pare aşa de simplu, de cele mai multe ori abordarea este superficială, ceea ce duce la un eşec rapid. Închei prin a menţiona încă o dată modelul ShuHaRi alături de două recomandări: asiguraţi-vă că aveţi alături pe cineva care ştie bine metodologia aleasă şi evitaţi să criticaţi o metodologie la mai puţin de un an de la implementare.

www.todaysoftmag.ro | nr. 6/2012

39

HR

Echilibrul dintre viața profesională și cea personală

M

ă fascinează conceptul de ”work-life balance” sau mai simplu găsirea acelui echilibru despre care se vorbește din ce în ce mai des, între viața personală și cea profesională. Într-o eră tehnologică, în care timpul parcă zboară, este din ce în ce mai greu să îmbini cariera cu viața personală. Am întâlnit persoane care să reușească cu brio acest lucru și care mi-au ridicat câteva semne de întrebare despre cum ar fi necesar să îmi organizez timpul cât mai bine pentru a avea rezultate excepționale la serviciu, pentru a avea suficient timp, pentru a practica hobby-urile pe care le am, pentru a ieși la o cafea cu prietenii. Nu pot spune că am descoperit secretul, deoarece încă sunt momente în care agenda nu arată chiar cum mi-aș dori eu să fie. Puțini sunt cei care știu că acest concept a fost de-a lungul timpului studiat.

Cel care a introdus acest termen a fost • Echilibrul spiritual: obținerea acelei angajaților: lipsa de educație a Byrne, care îl definea ca fiind ”echilibrul satisfacții spirituale, care te deterangajațiilor despre acest concept între cele cinci aspecte esențiale ale vieții: mină să fii mulțumit cu tine însuți/ nou întâlnit pe piață. serviciu, familie, prieteni, sănătate și spiînsăți.

• Presiunea business-ului: orice comrit”, care nu înseamnă neapărat o divizare Echilibrul viață personală – viață propanie va înclina mereu balanța exactă a timpului aferent fiecărui aspect, fesională perceput în cultura tării. Pe de înspre interesele care îi vor păstra ci este vorba despre crearea acelui nivel altă parte, consider că un impact mare avantajul competitiv pe piață, decât care să aducă satisfacția dorită pentru fie- asupra stabilirii acestui echilibru îl are culînspre echilibrarea vieții personale care dintre cele cinci roluri. Nu aș vrea să tura țării în care trăim. De menționat că a angajatului cu cea profesională, insist foarte mult pe aspectele teoretice ale au fost implementate politici la nivel eurodeoarece nu este înțeles pe deplin acestui concept, dar consider că pentru o pean care încearcă să îmbunătească viața impactul pozitiv pe care aceasta îl înțelegere cât mai bună a lui, este necesar prin trei obiective ale acestei strategii de poate avea în dezvoltarea companiei. o trece succintă prin una dintre cele mai dezvoltare.

• Timpul de lucru: deși este stabilit importante și cunoscute teorii, dezvoltată 1. Cât mai multe și mai bune locuri de un program de lucru de 8 ore pe zi, de către Tim O’Brien ”Diferitele părți ale muncă pentru cetățenii europeni, mulți dintre anjagați petrec mai mult unei vieți echilibrate” (en. ”the many sides prin dezvoltarea unei politici active timp la birou datorită volumului de of a balaced life”), care susține că există mai de angajare. muncă foarte ridicat pe care îl au, multe feluri de echilibru: 2. Dezvoltarea unor programe de deoarece foarte rare sunt situațiile • Echilibrul social: timpul pe care educație și training pentru dezvoltaîn care angajatorii iau măsuri pentru petrecut cu sine sau cu ceilalți. rea cunoștințelor. o reorganizare a muncii. Chiar dacă Teoriile psihologice susțin că două 3. Programe de incluziune socială. legislația muncii încearcă să protedintre nevoile primare ale omului Prin acestea se dorește creșterea calității jeze angajații de astfel de abuzuri, sunt: nevoia de socializare și nevoia vieții, nu doar definirea unui standard posibilitatea de a lucra de acasă, dezde solitudine, astfel cu cât petreci minim acceptat. În multe din statele vest echilibrează mai mult acest balans. mai mult timp singur riști să devi europene deja există o îmbunătățire viziEchilibrul viață personală – viață profemai izolat si orientat către sine, iar bilă a echilibrului între viața personală sională perceput în cultura organizațională cu cât socializezi mai mult cu ceilalți și cea profesională. Cu toate acestea ce se a companiei. Cu toate aceste impedimente, riști să duci o viață superficială. întâmplă la nivelul fiecărei țări este departe fiecare dintre noi ar trebui să înțeleagă că • Echilibrul mental: timpul petre- de situația ideală definită de către Comisia echilibrul între viața personală și cea procut pentru învățare și în scop Europeană, iar principalele probleme iden- fesională este dat de eficiența și eficacitatea recreațional. Echilibrul constă în tificate au fost: la locul de muncă. Cu cât reușesți să faci îmbinarea plăcutului cu învățatul.

• Neuniforma adoptare: deși regle- mai multe într-un timp mai scurt, cu atât • Echilibrul emoțional: constă în mentările sunt agreate la nivel global, ele ai mai mult timp pentru a-l dedica familiei sensibilitatea la probleme și obiec- nu sunt implementate în fiecare țară și cu și prietenilor. Drept o soluție la toate acestivitatea cu care sunt soluționate atât mai mult în fiecare companie și sector tea companiile ar putea implementa politici acestea. Cu cât devenim mai în care aceasta activează. Studiile efectuate care să încurajeze: emoțional implicați, cu atât deciziile la nivel european, demonstrează că mai • Programul flexibil: realizarea celor luate sunt mai dezechilibrate. mult de o treime dintre companiile care 40 ore legale conform codului mun• Echilibrul fizic: implică sănătate activează în domeniul manufacturier nici cii, dar permiterea unei flexibilități corporală și mentală. Este nece- măcar nu iau în considerare aceste polipentru rezolvarea unor situații persar un echilibru în ceea ce privește tici. Pe de altă parte, companiile care au un sonale, cu condiția ca de încrederea exercițiile fizice și nutriția, pentru departament dezvoltat de resurse umane, care îi este acordată angajatului să nu că nivelul de oboseală corporală și au demonstrat o creștere semnificativă în se abuzeze și să se respecte timpul de nivelul de stres au un impact asupra crearea acelui echilibru între viața persolucru și mai ales să se îndeplinească deciziilor luate. nală și cea profesională. sarcinile de lucru.

• Echilibrul financiar: găsirea echi• Lipsă de formalizare: puține tări • Posibilitatea de a lucra de acasă: librul între cheltuieli, venituri și au legi scrise care să reglementeze permite angajaților să își organizeze economii și implică decizii care au aceste politici europene. timpul și în jurul valorilor personale un impact asupra stilului de viață.

• Cenzura și restricțiile impuse și în funcție de nevoile familiale. Mai

40

nr. 6/2012 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE mult decât atât le permite să lucreze într-un mediul propriu, care poate fi mai relaxant decât cel de la job.

Sunt însă puține companiile care adoptă o astfel de politică, deoarece de cele mai multe ori s-a demonstrat că angajații din România nu rămân concentrați pe sarcinile care este necesar să le realizeze.

Prin implementarea acestor politici, multe dintre companii au văzut beneficiile mari pe care le-au obținut: • Reducerea absenteismului; • Creșterea productivității; • Creșterea beneficiului de imagine al companiei; • Creșterea loialității și a angajamentului față de companie; • Creșterea retenției angajațiilor; • Reducerea stresului.

Pe de altă parte beneficiile angajațiilor sunt și ele ridicate: • Creșterea satisfacției la locul de muncă; • Găsirea unui echilibru între viața personală și cea profesională; • Reducerea nivelului de stres la locul de muncă; Crearea echilibrului între viața personală și profesională este pentru binele tuturor: creșterea business-ului, facilitarea procesului de recrutare printr-o creștere a ratei retenției angajațiilor în companie, creștere economică printr-o creștere a productivității muncii, dezvoltarea unei cariere care să permită și petrecerea timpului liber cu familia, dar în același timp asigurare unei bunăstrări financiare. Cu cât angajații simt că au un control mai mare asupra vieții lor, cu atât își găsesc mai bine echilibrul în viața personală.

Cu toate acestea implementarea unei culturi organizaționale care să încurajeze

echilibrului între personal și profesional este încă un proces îndelungat pe care multe dintre companii abia l-au început sau altele, din păcate nici măcar nu au făcut primii pași în această direcție.

Echilibrul viață personală – viață profesională perceput ca obicei personal Martin Seligman spunea că fericirea autentică este un obiectiv final al ceea ce înseamnă obținerea acestui echilibru. Dorința îi împinge pe oameni la atingere unui nivel de fericire în momentul în care aceștia îndeplinesc o listă de obiective: realizările în carieră, relațiile de prietenie, confort material, dobândirea unui nivel ridicat de educație, etc. Echilibrul este reflectarea satisfacției și împlinirii în mai multe domenii, cu implicații negative scăzute în altele. De exemplu, o persoană materialistă, care poate ajunge la un nivel de satisfacție financiară ridicată nu este neapărat fericită în alte domenii, deoarece nenumărate studii au demonstrat că astfel de persoane au tentința clară de a-și neglija viața personală, familia, prietenii, comunitatea. Crearea acestei stări negative, în final îi afectează și satisfacția financiară, care în primă fază era extrem de ridicată și de mulțumitoare. Teoria dezvoltată pe această temă susține că există două lucruri care contribuie la atingerea echilibrului: 1. Definirea unor limite de satisfacție, care constă în definirea a ceea ce înseamnă satisfacție pentru fiecare domeniu și care este impactul atingerii acelui nivel față de celelalte domenii. Cu cât sunt indeplinite mai multe nevoi pe care oamenii le au, cu atât nivelul lor de satisfacție este mai ridicat.

2. S a t i s f a c e r e a n e v o i l o r d e supraviețuire și nevoia de creștere: se poate argumenta că nivelul

ridicat al vieții nu poate fi neapărat atins doar prin satisfacerea nevoilor de supraviețuire, este nevoie de o creștere a lor și de ajungere la un alt nivel.

Ceea aș aduce în completare este că această stare de satisfacție și stabilirea echilibrului între viața personală și profesională sunt date de personalitatea fiecăruia dintre noi. Au fost realizate numeroase studii în care s-a demonstrat că persoanele ”workaholice”, care sunt caracterizate ca fiind acele persoane care lucrează peste program, chiar dacă nu sunt nevoite să o facă, au tentința de a se concentra prea mult asupra carierei, pierzându-și focusul pentru alte domenii ale vieții lor.

Scopul articolului a fost de a prezenta succint conceptul de ”echilibru între viața personală și profesională” (en. Work life balance), pentru o mai bună înțelegere a impactului pe care fiecare comportament al nostru ca indivizi, dar și mediul organizațional în care ne desfășurăm activitatea îl poate avea în obținerea unor satisfacții profesionale care să nu fie umbrite de neîmpliniri personale. Pași în această direcție au fost întreprinși, este necesar în schimb o continuă îmbunătățire și implementare a politicilor care să încurajeze acest aspect atât de important într-o eră în care tehnologia controlează inconștient mare parte a vieții noastre. Aș vrea să închei prin a vă ridica mingea la fileu și a vă adresa următoarea întrebare: ”Cât de multă importanță acordați găsirii echilibrului între viața personală și cea profesională?”

Andreea Pârvu

andreea.parvu@endava.com Recruiter în cadrul Endava

www.todaysoftmag.ro | nr. 6/2012

41

diverse

Gogu și imaginea de ansamblu

Simona Bonghez, Ph.D.

simona.bonghez@confucius.ro Speaker, trainer şi consultant în managementul proiectelor, Owner al Confucius Consulting

42

nr. 6/2012 | www.todaysoftmag.ro

Sângele lui Gogu fierbea iar el simțea că încet, încet, presiunea în interiorul capului său crește ireversibil. Deveni subit conștient că va exploda, iar sentimentul îl umplu de o liniște nefirească care îi șterse parcă orice emoție, rămăsese doar un gust amar... Era momentul pentru o reacție, acum ori niciodată. Îl întrerupse pe Șef: - Zău, Șefu’, chiar nu e drept... Te iei de două săptămâni de întârziere în condițiile în care am reușit să finalizăm proiectul cu bine, e acceptat de client, am făcut profit, am economisit din bugetul de risc... Iar clientul ne cere să mai lucrăm cu ei... Zău că nu e drept.

Vocea lui Gogu era calmă și nimeni nu zise nimic, toate privirile care înainte erau adânc înfipte în podeaua sălii de ședințe, acum se întoarseră spre Șefu’. Era clar că Gogu exprimase frustrarea fiecăruia dintre ei: chiar făcuseră o treabă bună. Și condițiile n-au fost chiar ideale. Până la întâlnirea cu Șefu’, fuseseră foarte mândri de ce au reușit să facă, s-au felicitat unii pe alții...

- Hmm... - făcu Șefu’ oarecum descumpănit. „Te pomenești că îmi dă dreptate”, gândi Gogu ușor descumpănit. Era deja pornit și vroia o discuție clarificatoare și era pregătit „de luptă”, „chiar vreau o recunoaștere oficială a meritelor noastre” își zise el decis să nu se lase cu una cu două.

- Mda... – continuă Șefu’ onomatopeele.

Se vedea că procesează la greu, lucru oarecum nou la el. Rar reușea cineva să-l prindă pe Șefu’ pe picior greșit, veșnic avea replică, veșnic avea el ultimul cuvânt. Deh, ca de-aia e Șef.

- Hmm... repetă Șefu’.

Auzi Șefu’, zici ceva odată ori ba? Întrebarea n-a fost pusă cu voce tare, evident, dar aproape că îi scăpă lui Gogu. Șefu’ își mai drese o dată vocea, se uită pătrunzător la Gogu, apoi la fiecare dintre ei. Era unul dintre momentele acelea despre care mai apoi îți aduci aminte ca putând să tai tăcerea cu cuțitul.

- Da. (liniște). Cred... (iar liniște). Se

pare că Gogu are dreptate de această dată. (și iar liniște).

Gogu făcea eforturi disperate să nu își afișeze zâmbetul victorios. Se pare însă că nu îi reuși prea bine: - Hai, Gogule, lasă rânjetul de satisfacție pe mai târziu, ați dat-o în bară cu încadrarea în timp dar, într-adevăr, în rest, proiectul s-a finalizat cu succes și mai degrabă meritați laude decât observații. Mă mir că v-au acceptat cârcotașii ăia proiectul dar adevărul e că v-ați străduit și i-ați dat clientului ceea ce vroia. Măi, ce mai încolo și încoace, meritați felicitări. Bravo. Ce ziceți, ieșim să sărbătorim?

Tonul Șefului se schimbase total, parcă nu era el cel ce se îndoise de rezultate doar cu câteva minute mai înainte. Echipa era în ceață iar privirile se mutau de la Șef la Gogu, de la Gogu la Șef. Până și monologul intern al lui Gogu era redus la tăcere.

- Păi, dacă n-aveți obiecții, facem o rezervare de la șase la ăștia de peste drum, zâmbi Șefu’ șmecherește. Fac cinste...

Ajuns acasă, Gogu încă nu înceta să se mire de rapiditatea cu care își schimbase Șefu’ atitudinea. Era adâncit în fotoliul favorit când apăru fiul lui de la footbal.

Tocmai luase vacanță și, evident, era cât se poate de fericit. Știind foarte bine care va fi prima întrebare a tatălui său, se înființă rapid înaintea acestuia cu carnetul de note.

Zece, zece, nouă, zece, ȘASE?!, zece, nouă, zece, nouă...

- Ce e cu șasele ăsta? Cum s-a ajuns la media asta, ce s-a întamplat?!

- Zău, măi tata, și-așa sunt aproape tocilarul clasei. Nu vezi ce medie am?! Ce contează șasele ăsta când în rest am numai note bune. Chiar vrei sa fiu un geniu la desen?

Pe Gogu îl străfulgeră întâmplarea de la serviciu. Doamne – gândi el – fac și eu ca Şefu’... pierd din vedere imaginea de ansamblu. Își reveni însă rapid.

- Hai măi, gata, ce, nu mai știi de glumă deloc?

sponsori

powered by