TO DAY SOFTWARE No. 6/ 2012 • www.todaysoftmag.ro MAGAZINE 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
Transcript
TSM T O D A YS O F T WA R E
No. 6/ 2012 • www.todaysoftmag.ro
M AG A Z I N E
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
6How to Web conecteaza
Europa de Sud-Est la inovatia web
Irina Scarlat
7Finanţare pentru
startup-uri tech prin reţeaua de investitori Tech Angels
Bogdan Iordache
8Made
in România
Ovidiu Mățan
10Istoria IT-ului
ClujeanMarius Mornea
12Arhitectură
pentru Flexibilitate
Attila Antal
15Tehnici SEO interne
Radu Popescu
1810 principii
de design (fabulă)
Stefan Baritchii
21Interviu cu
Scott BarberMariu Mornea
24A scrie cod frumos -
dincolo de valoarea estetică Attila-Mihaly Balazs
27Toate drumurile duc la SaaS - 7 provocări pentru a ajunge acoloMihai Nadăș
29Introducere în GrailsTavi Bolog
32Exemple practice de message paterns pentru Windows AzureRadu Vunvulea
34Poti fi agile în proiecte de pret fix?Claudiu Anghel
36O incursiune prin atacurile informatice din 2012Andrei Avădănei
38Agile, crash courseFlorian Ivan, PMP
40Echilibrul dintreviata profesională si cea personalăAndreea Pârvu
42Gogu si imaginea de ansambluSimona Bonghez, Ph.D.
4 nr. 6/2012 | www.todaysoftmag.ro
Editorial
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 tehnolo-gie 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 tre-buie 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.
How to Web conectează Europa de Sud-Est la inovaţia web
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 abor-date teme precum inovaţia în tehnologie, dezvoltarea de aplicaţii mobile, software-as-a-service ș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 teh-nologiei din întreaga lume.
În plus, How to Web contribuie la cre-area ș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 punc-tul 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 partici-panţ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 accele-rare 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 regi-une, How to Web are un impact puternic asupra fiecărei persoane din audienţă.
Ediţia de anul acesta aduce și alte nou-tăţ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 dezvolta-rea de produse tech la scară globală, cea de a doua scenă va aduce startup-urile în lumina reflectoarelor prin realizarea con-cursului 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 for-mare. 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ă contec-teze Europa de Sud-Est la inovaţia web globală.
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 maste-rat in Managementul Proiectelor Internationale (ASE Bucuresti)
Româ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 activi-tăţ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.
7www.todaysoftmag.ro | nr. 6/2012
TODAY SOFTWARE MAGAZINE
Finanţare pentru startup-uri tech prin reţeaua de investitori Tech Angels
în companii de tehnologie și internet, fon-dator 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 compa-nii tehnologice din România. Ne dorim să sprijinim atât antreprenorii, înlesnindu-le accesul la fonduri și expertiză, cât și inves-titorii, punându-i în contact cu startup-uri”, spune Ragu Georgescu, Founding Partner & Chairman GECAD Group.
Andrei Pitiș este la rândul său investi-tor activ și mentor în mai multe startup-uri, președinte al ANIS (Asociaţia Patronală a Industriei de Software și Servicii) și pro-fesor asociat la Universitatea Politehnică din București, cu o experienţă de peste 22 de ani în companii tech la toate nive-lurile. „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 antrepre-noriat și tehnologie din Europa de Sud-Est, și mentor la mai multe acceleratoare de afa-ceri 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 glo-bale”, 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 eva-luă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 medi-tech. 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 sim-plu. Primul pas este ca antreprenorii interesaţi să contacteze echipa Tech Angels prin intermediul formularului disponibil online. După o analiză completă a pro-dusului sau afacerii, echipa TechAngels realizează alături de antreprenor o pre-zentare 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 impor-tant pentru dezvoltarea ecosistemului antreprenorial din Europa de Sud Est deoarece le ofera startup-urilor inovatoare finanţarea iniţială de care au nevoie pen-tru a se putea concentra pe dezvoltarea unui produs inovator, cu potenţial disrup-tiv 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 antrepre-nori talentaţi aflaţi la început de drum.
Industria IT din Europa de Sud-Est este una emergentă, iar potenţialul și talentul tehnic existent în zonă reprezintă premisele dez-voltă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
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 inter-nationala a How to Web a castigat premiul IDG „Cel mai bun eveni-ment IT&C al anului din Romania”. Licentiat in automatica si calcula-toare 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 internship-uri in IT din Romania, si Conectoo, platforma de email marketing.
8 nr. 6/2012 | www.todaysoftmag.ro
Made in România
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 folositeRobert: 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 pen-tru 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ă por-tare să facem și un update masiv pentru jocul in sine, adăugând noi funcționalități.
Q: Câteva cuvinte despre companieRobert: 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 aproxi-
mativ un milion de jocuri și peste zece milioane de utilizatori au folosit variantele gratuite ale acestora. Câteva din principalele lor realizări:
• Î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 por-tare 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.
Inaugură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.
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 companieCă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.
Despre TriluliluTrilulilu 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.
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.
Hacker Evolution Duality
Serviciul de muzică românesc Zonga
10 nr. 6/2012 | www.todaysoftmag.ro
Istoria IT-ului Clujean
istoriearhitectură
Imediat după prezentarea stadiului curent al cluster-ului IT din Cluj (30 de firme înscrise, cumulând 3500 de angajați și o cifră de afaceri de 8 milioane de Euro), a luat cuvântul domnul profesor Sergiu Nedevschi. Înainte de a trece la prezentarea activității științifice a labora-torului pe care îl conduce, a ținut o mică lecție de istorie începând cu înființarea unei ramuri a Academiei Române la Cluj în anii 1950, continuând cu construirea primelor calculatoare, a unuia dintre primele compilatoare de Fortran și așa mai departe până la concluzia finală că aceștia sunt factorii determinanți pentru starea curenta a IT-ului clujean. În acest moment Răzvan se întoarce spre mine și mă întreabă de ce nu scriem despre asa ceva: Care este istoria IT-ului clujean?
Prima reacție a fost similară celei resimțită de fiecare dată la auzul sintag-mei “Clujul, Silicon Valley-ul României”, o ușoara neîncredere și nevoia puternică de dovezi și argumente care să susțină această comparație. Simțeam nevoia unei raportări ale realizărilor IT-ului local, la stadiul național și internațional, pen-tru a justifica importanța și nevoia unui articol. A doua zi mi-am dat seama că relevanța acestei raportări este minimă, dar evoluția și eventuale comparări ar fi totuși un subiect interesant. Așa au înce-put să apară întrebările:
Cine a introdus IT-ul în Cluj? În ce scop? În ce circumstanțe? Cum a ajuns să crească la nivelul actual? Care este nive-lul actual? Este adevărat că, atât numărul, cât și contribuția la bugetul local al angajaților din IT reprezintă o majori-tate? Cum au luat decizia antreprenorii, imediat după revoluție să înceapă afaceri în acest domeniu? Cine le-a fost men-tor sau inspirație? Cine a pregătit tehnic generațiile actuale de profesioniști în domeniu ? Cine a introdus aceste materii în curriculum universitar? De ce la Cluj exista această proporție mare și nu în alte
orașe vecine? Cum am ajuns fiecare din noi să lucrăm în IT?
Apoi am început să testez ideea pe alți oameni, care în loc de răspunsuri îmi puneau mai multe întrebări: Cine este Tiberiu Popoviciu ? Iar spre rușinea mea, absolvent al liceului care îi poartă numele, tot ce am putut sa zic este că a fost un matematician, fără să pot să explic clar și argumentat legătura lui cu domeniul informaticii; Cum au evoluat demografic generațiile de profesioniști IT? Ce alte domenii au fost influențate de IT? A generat IT-ul clujean premiere în domeniu? Care sunt metricile potrivite pentru comunitatea locală? Producția de Proprietate Intelectuala este o metrică semnificativă?
Deodată cu aceste întrebări s-au con-turat și diferitele perspective din care priveau interlocutorii mei subiectul: unii erau animați de curiozitate și amuzament, cautând o lectură plăcută; alții interesați de aspectele economice și oportunitățile născute de un studiu detaliat al stării curente; alții cuprinși de melancolie, în amintirea unor vremuri trecute. Am hotărât să explorez aceste perspective și să încerc să răspund întrebărilor de mai sus în cadrul unui nou proiect: Istoria IT-ului Clujean – de la 1957 până azi. Mai concret o serie de articole și even-tual ediții speciale dedicate întrebărilor de mai sus, interviurilor cu personalități actuale sau istorice dar și perspectivei personale: eu cred că există o comunitate IT la Cluj care a dovedit în nenumărate rânduri că a ajuns la o masă critică ce naște nevoia unei identități comune. Ori această identitate se definește prin răs-punsurile întrebărilor: Cine suntem? și de unde venim? Abia apoi putem răspunde întrebărilor: Unde vrem sa ajungem? și cum?
Aștept ajutorul vostru pentru a răs-punde întrebărilor de mai sus.
A început simplu, cu o singură întrebare, dar aceasta a dat naștere în zilele ime-diat 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”.
Fost senior software developerin cadrul Nokia, în prezentfondatorul platformei MintakaResearch
11www.todaysoftmag.ro | nr. 6/2012
TODAY SOFTWARE MAGAZINE
Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: http://www.transylvania-jug.org/Data înfiinţării: 15.05.2008 / Nr. Membri: 504 / Nr. Evenimente: 39
Romanian Testing CommunityComunitate dedicată QA.Website: http://www.romaniatesting.roData înfiinţării: 10.05.2011 / Nr. Membri: 536 / Nr. Evenimente: 1
Cluj.rbComunitate dedicată tehnologiilor Ruby.Website: http://www.meetup.com/cluj-rb/Data înfiinţării: 25.08.2010 / Nr. Membri: 127 / Nr. Evenimente: 30
The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: http://www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 249 / Nr. Evenimente: 13
Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: http://www.meetup.com/Cluj-Semantic-WEB/Data înfiinţării: 08.05.2010 / Nr. Membri: 132/ Nr. Evenimente: 19
Romanian Association for Better SoftwareComunitate dedicata oamenilor cu experienta din IT indiferent de tehnologie sau specializare.Website: http://www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 181/ Nr. Evenimente: 10
Comunitatea TSMComunitate construita in jurul revistei Today Software Magazine.Website: http://www.todaysoftmag.roData înfiinţării: 06.02.2012 / Nr. Membri: 263 / Nr. Evenimente: 3
Tabara de testareComunitate dedicată QA.Website: http://www.meetup.com/Tabara-de-Testare-Cluj/Data înfiinţării: 15.01.2012 / Nr. Membri: 100 / Nr. Evenimente: 7
Secţ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.
Calendar
Noiembrie 9Artificial Intelligence, Computational Game Theory, and Decision Theory - Unifying pathsContact: [email protected]
Noiembrie 17Open Agile Cluj 2012Contact: http://cluj2012.openagile.ro/
Noiembrie 22Lightning TalksContact: http://www.transylvania-jug.org/
Decembrie 8Global Day of Coderetreat 2012Contact: http://coderetreat.org/events/global-day-of-codere-treat-2012-cluj-napoca-romania
Decembrie 11 Socialization MeetupContact: http://www.meetup.com/Cluj-Semantic-WEB/
Comunităţi IT Cluj-Napoca
arhitectură
Google Technology User Group Cluj-NapocaComunitate dedicată tehnologiilor Google.Website: http://cluj-napoca.gtug.ro/Data înfiinţării: 10.12.2011 / Nr. Membri: 30 / Nr. Evenimente: 7
Cluj Mobile DevelopersComunitate dedicată tehnologiilor mobile.Website: http://www.meetup.com/Cluj-Mobile-Developers/Data înfiinţării: 08.05.2011 / Nr. Membri: 54 / Nr. Evenimente: 3
Arhitectură pentru Flexibilitate (Quality Attribute)
arhitectură
În articolul ce urmează voi dezvolta câteva idei despre acest topic, flexibilitatea, și despre impactul pe care îl are asupra pro-ceselor de arhitectură și development.
Quality AttributesQuality 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 majo-ritatea 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 cali-tate 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țituluiIn 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ă dife-rite ”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
diferitelor domenii (dezvoltare, operati-onal, 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.
AgileMajoritatea companiilor de dezvoltare
software folosesc metodologii agile. Dacă ne uităm la definiția acestei metodologii vom vedea ca e vorba exact depre o flexi-bilitate î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 impactDupă ce arhitectul are lista concepte-
lor, strategiilor, metodologiilor care vor fi prezente in proiect și au legatură cu fle-xibilitatea, 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 fle-xibilitate vor primi un semn ”+” și cele care
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.
Conform 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.
13www.todaysoftmag.ro | nr. 6/2012
TODAY SOFTWARE MAGAZINE
vor fi impactate vor primi un semn ”-”. În cazul nostru putem observa cum calitățiile de Extensibilitate și de Performanță sunt afectate negativ de Flexibilitate. În cazul impactului de performanță sunt destule măsurători prin care se pot explica riscu-rile și de multe ori acestea sunt acceptate de client .
În cazul extensibilității trebuie să avem documentat (și predat la client) riscul și eventual diminuarea riscului dacă struc-tura și cerintele proiectului permit acest lucru. Tabele de genul celei de mai sus sunt atuuri foarte valoroase în analiza de compromis și în negocierea calităților care trebuie să fie prezente (sau nu) în proiect.
Plugin ca și pattern arhitecturalDiminuarea riscului față de extensi-
bilitate este posibilă și prin alegerea unui pattern arhitectural inteligent. Sistemele bazate pe plugin-uri permit extensibilitatea exact prin flexibilitatea lor, prin metoda de grupare a funcționalităților în plu-gin-uri. În cazul in care avem nevoie de o funționalitate extinsă se schimbă un plugin cu celalalt sau se adaugă altele.
Figura 1 arată un sistem non-flexi-bil, monolitic sau monolitic core la nivel conceptual. O schimbare oricat de mică la oricare funcționalitate aduce după sine retestarea și relansarea intregului sistem.
Figura 2 arată un sistem flexibil la nivel
conceptual. Putem observa că nu toate funcționalitățille pot fi extrase în plugin acestea vor rămâne în core. Fiecare plugin comunică cu core și unele se izolează com-plet de alte sisteme. Aplicatia core trebuie sa aibă o fațadă pentru fiecare plugin. Aceste fațade pot să aibă interfețe și prin asta se poate face public accesul la plugin.
După ce studiem atent Figura 2, putem să observăm că un plugin poate să existe
complet izolat (de exemplu un encoder/decoder) sau poate fi folosit ca un agent de comunicare schimbând mesaje cu alte sisteme.
Avantajul la acest sistem este că anumite funcționalități bine plasate in pluginuri pot fi reutilizate, moment in care arhitectul tre-buie să aibă influență asupra procesului de development.
Succesul la sistemele cu plugin-uri este în a defini foarte clar comunicarea intre core și plugin-uri, a folosi plugin-uri
reutilizabile, control și orchestrație.
Arhitectura core-uluiCel 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 pozi-tive. Tocmai de aceea nu este o decizie inteligentă să avem în sistem numai un sin-gur 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.
UtilitățiE de menționat faptul că acest context al
aplicației trebuie să aibă tot timpul funcții sau utilitare de core cum ar fi de exemplu:
■ tratarea fișierelor de proprietăți ■ logare centrală ■ auditarea diferitelor evenimente ■ persistarea datelor in baza de date ■ manipularea tranzacțiilor
Aplicația core este și ea la randul sau un consumator al acestor utilități.
OrchestrareO foarte importantă funcționalitate
a core-ului este de a orchestra compor-tamentul pluginurilor. Înțelegem prin aceasta controlul de lansare sau de scoatere din funcțiune a unui plugin și manipula-rea diferitelor tipuri de evenimente de alte feluri.
CommunicareAplicatia core trebuie să aibă imple-
mentate 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ă business-ul clientului.
Micro-arhitectură în plugin Părerea mea este că un plugin trebuie
Tabelul 1
Figura 1
Figura 2
14 nr. 6/2012 | www.todaysoftmag.ro
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-
textului aplicației. Plugin-ul de obicei are numai o singură metodă de comunicare cu core pentru a păstra simplitatea integrării.
SumarScopul acestui articol a fost de a vă
ghida printr-un flow al deciziilor și al argumentelor prin care software arhitec-tul poate să sintetizeze o soluție bazată pe atributul de calitate numit flexibilitate. S-a început cu paralela dintre cerintele cli-entului proiectat în Quality Attributes și strategiile companiei. A urmat analiza de compromis prin care am observat impac-tul cu extensibilitate ca fiind principalul argument pentru folosirea pattern-ului de plugin. La final s-a detaliat arhitectura unui sistem bazat pe plugin-uri.
Arhitectură pentru Flexibilitatearhitectură programare
Robots.txt vs meta robotsPrecum cum spuneam în numerele tre-
cute, 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 cali-tate 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și-erele 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 rea-lizat 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ă actuali-zarea 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 layoutAm vorbit în numerele trecute des-
pre 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 organiza-rea conţinutului. Printre cele mai folosite tag-uri semantice în contrucţia unei inter-feţe sunt: <header>, <nav> (meniu, navigare), <footer>, <section>, <article>, <aside>. Pentru a înţelege mai bine modul
Vom 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.
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ău-gând următorul script în zona <head>:
Folosirea adreselor canoniceAdresa 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/lapto-puri). Î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 ase-menea se pot sorta și după nume (ex. www.site.ro/laptopuri?sort=name&type=asc) sau după alte criterii. Toate aceste URL-uri 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-buil-ding-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:
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 motoa-relor 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
ancore cât mai descriptive. Spre exem-plu, dacă cineva dorește să adauge un link către un articol foarte bun, despre neuro-marketing, 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 descrip-tive 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 sin-gură 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),
iar pentru al treilea avea mai multe ancore de tip partial-match (cuvinte cheie secun-dare). Rezultatele au fost surprinzătoare. În primele trei zile, situl care avea link-uri externe ce foloseau ancora „click here” a detinut prima poziţie în căutări. Dupa cele 3 zile, acesta a dispărut din SERPS și au apărut celelalte două pe poziţiile 1 și 2.
Link-urile interne şi rolul lorDe asemenea link-urile interne au un
rol foarte mare în SEO, nu doar cele venite din exterior. Dacă ne gândim la modul, standardizat oarecum, în care sunt con-struite astăzi site-urile, vom observa că dintodeauna în partea de jos avem o mul-ţime de link-uri interne. Ei bine, aceste link-uri interne din footer au ajutat mereu atât din punct de vedere al SEO cât și al usability. Ele creează o ierarhie a paginilor din site și transmit o parte din autoritatea acestora (link juice) celor apropiate.
Trebuie să ne asigurăm că nu există pagini (pe care le vrem indexate) ce nu pot
fi accesate de pe pagina principală, prin link-uri succesive. Pentru a profita la maxi-mum de puterea link-urilor interne trebuie să ţinem cont de câteva lucruri esenţiale:• Cu orice preţ trebuie evitate link-
urile interne din JavaScript sau Flash, pentru că acestea nu pot să fie parsate de către motoarele de cău-tare (în foarte multe cazuri).
• Link-urile interne către pagini blo-cate 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 150-200 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 inde-xate în Google și link-urilor interne între acestea. Fiecare pagină conţine cateva zeci de link-uri către alte pagini de pe același domeniu, creând astfel o retea internă solidă.
Atributul ALTDe foarte multe ori este trecut cu vede-
rea faptul că și imaginile au nevoie de optimizare SEO. Atributul ALT este folosit în interiorul tag-ului <img> și are rolul de a oferi informaţii despre conţinutul imaginii. Din cauza faptului că motoarele de căutare parseaza codul sursă și nu pot să înţeleagă imaginile, avem nevoie să le oferim infor-maţii cât mai detaliate despre acestea. Pe lângă numele imaginii, atributul ALT ajută la indexarea și afișarea imaginilor dintr-un site în rezultatele căutarilor.
Un alt rol foarte important al aces-tui atribut constă în aceea că valoarea din interiorul său este afișată în cazul în care nu se va putea afișa imaginea din cauza unor probleme din cod sau a unei surse greșite. Atributul ALT este foarte util și în cazul celor care folosesc browsere text-based,
programareprogramare
Tehnici SEO interne - partea a II-a
Figura 2
17www.todaysoftmag.ro | nr. 6/2012
TODAY SOFTWARE MAGAZINEprogramare
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ă mobi-lier. Lipsa unui conţinut cuprinzător și interesant, de tip text, a făcut ca situl să nu prezinte un interes foarte mare pen-tru motoarele de căutare. Nu exista destul conţinut pentru a putea fi relevant în cău-tă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 tra-ficului venit pe pe Google Images.
ConcluziiTehnicile 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 motoa-rele de căutare, fiecare acţiune, oricât de mică, poate influenţa rank-ul. Este impo-sibil 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 conti-nuă 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 folo-sesc î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 nici nouă, celor care folosim SEO într-un mod corect. Din această cauză, optimizarea
pentru motoarele de căutare necesită o atenţie constantă și o muncă susţinută.
18 nr. 6/2012 | www.todaysoftmag.ro
10 principii de design(fabulă)
1. Şi pentru că toată lumea voia să înţe-leagă 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ă.
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ăs-
punsuri 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 dalto-niș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ă tre-buie 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 functi-onală 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ă com-plet, cineva a întrebat:
După 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 fina-lizat 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.
“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ăspun-sul 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ă tre-buie 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 pro-dusul 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 semni-ficative joacă un rol important.
( În această secţiune vorbim despre
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 versiu-nea 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, atri-bute, 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 ace-leaș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 para-metri 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ân-deau 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 folo-sea 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,
management
20 nr. 6/2012 | www.todaysoftmag.ro
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)
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
la un virus de care industria farmaceutică nu profită atunci când apare. Prin urmare suntem sub presiune (industria farmace-utică 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 pre-dispus 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 memo-ria 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ă )
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 plictisi-toare 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 nos-tru 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
diverse10 principii de design (fabulă)
interviu
21www.todaysoftmag.ro | nr. 6/2012
TODAY SOFTWARE MAGAZINE
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 invi-tat 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 ief-tin ș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 reprezen-tativ, cred că aveți o comunitate excelentă”, una dintre constatările plăcute, tot mai des întâlnite în ultima vreme fiind „tehnolo-gia 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 eve-nimentul, 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 esteuro-peană, 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 uzu-ale, ș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 pen-tru 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 lao-laltă”, 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.
Q: Care unelte le considerați mai bune, cărțile sau uneltele software care automati-zează 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 speci-alizată [..] găsești aceeași informație din revistele de specialitate pe blogul autori-lor, 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,
Cu 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-decla-
rat, 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.
interviu
Interviu cu Scott Barber
foto: Scott Barber
22 nr. 6/2012 | www.todaysoftmag.ro
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 alt-cineva 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ă tes-tare de performanță chiar de la început. Asta nu înseamnă că tot timpul aceasta este făcută de tester, și asta poate crea con-fuzie, 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 dezvol-tatori și de administratori și de cei de la suport. Trebuie ca toate bucățile să se potri-vească ș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 schim-bare 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
un subiect fierbinte pen-tru 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 provo-carea 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 rea-liză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 pro-voca 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âm-plat. î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 perspec-tiva î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 exem-plu: 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 fie-care 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 încerca-rea 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 mana-gerul 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
interviuInterviu cu Scott Barber
23www.todaysoftmag.ro | nr. 6/2012
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: .. aaa-aaaaaaah! 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: pentrucaleamziscaeoideeproasta-sieamiatrimisunmailsiaziscatrebuiesaofac. 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 com-panii (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 infrastruc-tură 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 testa-
rea, 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 dez-voltare, îș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 actua-lizare 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 sis-tem 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 tre-bui 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”.
Q: Care ar fi cele mai importante
5 abilități din profilul unui tester de performanță?
„Doar 5? Glumesc. Mai demult glu-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 pro-blema, cum să caute cauzele, indiferent că e vorba de o problemă de performanță sau de business. Vreau să știe când e nevoie de un pas în spate, să arunce o privire de ansamblu, iar apoi să își dea seama unde trebuie să intre iar în detalii. Vreau oameni buni la rezolvarea problemelor. Apoi vreau
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 oame-nilor 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 stabili-tatea unui sistem de interes. Există multe alte definiții, dar la finalul zilei eu o folo-sesc 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, pre-supunând că funcționalitatea e ok, pentru că funcționalitatea nu ține de performanță, asta e performanța, iar cuvintele pe care le folosesc sunt viteză, scalabilitate și stabilitate.
Fost senior software developerin cadrul Nokia, în prezentfondatorul platformei MintakaResearch
24 nr. 6/2012 | www.todaysoftmag.ro
A scrie cod frumos -dincolo de valoarea estetică
În acest articol vom încerca sa demon-stră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 TroubleCe afișează următoarea bucată de cod?
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ă
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 obiec-tele 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 utili-zarea tipurilor primitive ar fi: eficienţă din punctul de vedere al memoriei consumate și evitarea definirii cazurilor speciale pen-tru 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-
Limbajele 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ă?”.
mal(„1.2”);BigDecimal d2 = new BigDeci-mal(„1.20”);System.out.println(d1.equals(d2));
Soluţia în acest caz (având în vedere faptul că nu există un tip primitiv echiva-lent pentru această clasă) ar fi să se utilizeze (în locul metodei equals) metoda compa-reTo ș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, deoa-rece condiţia este adevărată și v are valoarea null (null poate fi atribuit oricărei refe-rinţ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 :
„Dacă unul dintre operanzii doi și trei este de tip T primitiv, și tipul celălalt este rezultatul aplicării operaţiei de auto-boxing (§ 5.1.7) la T, atunci tipul expresiei ter-nare este T”. Cred că nu mulţi dintre noi au parcurs JLS-ul complet și chiar dacă am fi parcurs, nu am fi realizat implicaţi-ile subtile ale fiecărei fraze. Recomandarea din EJ2nd de la exemplul anterior ne ajută din nou: să folosim tipuri primitive. De asemenea, putem face o paralelă cu capi-tolul 43 din carte: Return empty arrays or collections, not nulls. Dacă am fi folosit un „element neutru” (analogul folosirii tabe-lelor/colecţiilor goale) problema nu ar fi apărut. (Elementul neutru ar fi 0.0d dacă însumăm sau 1.0d dacă înmulţim).
Exemplul 3: Un vas golCare este diferenţa dintre următoarele
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.
Exemplul 4: Atenţie la folosirea lui static!Ce afișează următorul fragment de cod?
public final class Test { 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 esteYour name is what?Your name is who?
Hello, my name is nullHello, my name is Test$Foo
Valoare nulă (probabil) neașteptată se afișează pentru că obţinem o referinţă către un obiect parţial construit:• Începem să creăm o instanţă a clasei
Foo la punctul 1;• Aceasta fiind prima referire la clasa
Foo, JVM-ul o încarcă și începe s-o iniţializeze;
• Iniţializarea clasei Foo implică iniţi-alizarea tuturor câmpurilor statice;
• Pentru iniţializarea primului câmp static trebuie apelat constructorul de la punctul 2, ceea ce se și întâmplă;
• În acest moment câmpul static NAME nu este încă iniţializat și ast-fel constructorul va afișa null.
Acest cod demonstrează cum câmpu-rile statice pot fi dificil de folosit în mod corect și că nu ar trebui să le utilizăm decât la declararea constantelor (și chiar și atunci să ne gândim dacă nu este mai bine să folo-sim un Enum in locul constantelor). În
aceeași ordine de idei trebuie să ne ferim de pattern-ul Singleton care – pe lângă proble-mele potenţiale de iniţializare – face codul mai greu de testat.
Tot aici trebuie sa menţionăm că folo-sirea 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ă veri-ficăm frecvent rezultatul lor (în mod ideal la fiecare schimbare de cod). De exem-plu, problema prezentată este detectată de Findbugs și uneltele care încorporează Findbugs.
Exemplul 5: Eliminarea codului vechiEnumeraţ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 struc-tură se face doar de pe un singur fir de execuţie (thread);
• În cazul în care structura este utili-zată 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 abando-narea 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 ).
management
26 nr. 6/2012 | www.todaysoftmag.ro
ConcluzieAceste exemple nu sunt singulare.
Cunoașterea unui limbaj de programare înseamnă mai mult decât stăpânirea sinta-xei la un nivel de bază. Dacă utilizaţi Java: faceţi-vă rost de câte o copie din „Effective Java, 2nd edition” și „Java™ Puzzlers: Traps, Pitfalls, and Corner Cases” și parcurgeţi-le, dacă nu aţi făcut deja acest lucru. De asemenea, utilizaţi analiza statică (static analysis/linting) pe codul sursă (Sonar este o alegere bună în acest domeniu) și rezol-vaţi problemele semnalate de aceasta sau cel puţin citiţi atent descrierile lor.
Concluziile sunt valabile și pentru alte limbaje de programare:• Încercaţi să citiţi despre modul cel
mai bun (best practices) / moduri idiomatice (idiomatic) de a scrie cod în limbajul dat. De exemplu, cea mai bună carte pentru Perl în momentul de faţă este ”Modern Perl” , scrisă de chromatic și disponibilă gratuit.
• Verificaţi dacă există o unealtă de analiză statică (static analysis / lin-ter) de bună calitate pentru limbajul respectiv. De exemplu pentru Perl 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 lim-baj de programare.
Lumea se schimbăNe aflăm la trecerea dintre două para-
digme 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ă contra-valoarea 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 ter-meni 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ă deter-mine 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%, adu-câ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 olan-dez, care a mizat timpuriu pe SaaS și acum beneficiează de venituri de peste 9 milioane de dolari din acea soluție.
Dincolo de statisticiPotențialul de a adresa piețe noi, avan-
tajul unui venit mai ușor de preconizat, cel al costurilor reduse de suport și mentenanță
Compania 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.
management
Toate drumurile duc la SaaS7 provocări pentru a ajunge acolo
este responsabil de activitățile R&D și creșterea nivelului de inovație al produselor partenerilor Yonder.
28 nr. 6/2012 | www.todaysoftmag.ro
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 con-cluzie 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 modelu-lui 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 perspec-tivelor financiare ale companiei.
Pot fi identificate cel puțin șapte provo-cări în drumul unui ISV către o soluție de succes bazată pe SaaS –
1. Identificarea pieței țintă pen-tru noua soluție – alegerea între abordarea unei piețe noi sau conso-lidarea celei existente;
2. Alegerea politicii de prețuri - balansul între accesibilitatea ofertei și riscul de canibalizare a venituri-lor 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 pro-dusului – în modelul tradițional stabilitatea produsului nu avea un
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;
5. „ Agilizarea” modelul de dez-voltare software – SaaS fructifică abilitatea unei companii de a răs-punde într-un mod agil schimbării, iar aceasta presupune pe de-o parte schimbarea modelului de dezvol-tare bazat pe cicluri de durată lungă și totodată profesionalizarea aces-tuia prin introducerea de procese mature care să scadă riscul pe mai multe paliere;
6. 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 schim-bată. Poveștile de succes pornesc de regulă de la o echipă nouă, inde-pendentă de cele existente sau chiar de la spin-off-uri;
7. Excelență în abordarea și execuția tehnică – întâi de toate, SaaS pre-spune 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 imple-mentarea 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?
• Cum s e t rate ază asp ec tu l multi-tenancy?
• Cum se partiționează datele și care este arhitectura aleasă pen-tru 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ă autenti-ficarea și autorizarea și care sunt aspectele arhitecturale care adre-sează problemele de securitate?
• Cum se asigură un proces robust și flexibil de Release Management?
ConcluziiNe 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 arun-cate, 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 busi-ness însă fără compromisuri în execuția tehnică, unde complexitatea poate fi mai ridicată decât indică aprențele.
Legături externe1. innovation.tss-yonder.com2. i n n ov at i on . t s s - y on d e r. c om /
sizing-the-cloud3. mihainadas.com
Toate drumurile duc la SaaS - 7 provocari în a ajunge acolo
management
29www.todaysoftmag.ro | nr. 6/2012
TODAY SOFTWARE MAGAZINE
Introducere în Grails
La o scurtă privire, Grails folosește:• Limbajul Groovy – pentru a conecta
toate stack-urile de mai jos;• Hibernate – pentru modelarea date-
lor folosing GORM (Groovy Object Relational Model);
• Groovy Server Pages – un lim-baj dinamic pentru construirea view-urilor;
• Spring – pentru controller, secu-ritate, 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).
Proiectul meu current (http://prime-place.nokia.com) folosește Grails 2.0.4. Partea web a fost tranziționată în aproxi-mativ 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 GrailsPentru 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 folde-rul în care a fost despachetat Grails și adaugă executabilul “grails” în PATH;
Grails 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.
• Rulează Grails, tastând: “grails” în terminalul/consola sistemului de operare;
• Aceasta va porni consola Grails și va aștepta comanda ta: grails >
Există două IDE-uri care ajută deve-loperii foarte bine în dezvoltarea folosind Grails:• Intellij IDEA;• Eclipse (and Spring Tool Suite)
și acum Groovy & Grails Tool Suite, ultimele două dezvoltate de VMware, având la bază Eclipse.
Momentan, folosim STS 3.10 cu support de Groovy și Grails bazat pe Eclipse 3.8.1. Am încercat Juno 4.2, dar laptopul de abia mai răspundea comenzilor, așa că am revenit la versiunea bazată pe Eclipse 3.8.1.
Crearea unei aplicații în GrailsCea 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țieiFolosind consola Grails, comanda cre-
ate-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 direc-torul GrailsSocialNetwork):• application.properties – conține
informații generale despre aplicație;• grails-app – conține majoritatea
conținutului Grails cum ar fi con-troller, 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
Spring;
Acum puteți rula prima aplicație Grails, executând comanda run-app în consola Grails. Aceasta va porni applicația: http://localhost:8080/GrailsSocialNetwork. Bineînteles acesta este doar un template fără prea multă valoare. Aplicația se poate porni si pe alt port rulând: run-app –Dserver.port=80 (va porni aplicația pe portul 80).
Crearea claselor de domeniuSă creăm acum clasele de domeniu
pentru aplicația noastră. În primul rând, avem nevoie de clasa User. Pentru a crea, vom folosi din nou consola Grails: create-domain-class com.todaysoftmag.gsn.User. Aceasta va crea două fișiere:| Created file grails-app/domain/com/todaysoftmag/gsn/User.groovy
| Created file test/unit/com/today-softmag/gsn/UserTests.groovy
Primul fișier este clasa domeniu, iar al doilea este clasa de unit test asociată. Să încercăm acum să folosim sintaxa Groovy și să adaugăm context clasei noastre dome-niu. Groovy este asemanator sintactic cu Java, dar suportă structure dinamice și nu este strict cu tipurile datelor.
Pentru a adăuga atribute clasei User, adaugă următoarele linii în clasă:String firstNameString lastNameString userNameString password
Acum dorim să adăugăm niște limi-tări valorilor atributelor. Grails deja a creat un closure gol pentru adăugarea de constrângeri:static constraints = {//atributul “firstName” nu poate fi //gol si trebuie să aibă lungimea //între 3 și 10
firstName size: 3..10, blank:false//atributul “lastName” nu poate fi //gol si trebuie să aibă lungimea //între 3 și 10
lastName size: 3..10, blank:false//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 }
În cazul în care oricare dintre aceste constrângeri va fi încălcată (verificarea este făcută prin apelul metodei “validate” dis-plonibilă in fiecare clasă domeniu), Grails va completa erorile în atributul “errors” al clasei User. Apoi, controller-ul este cel care va decide ce se va întâmpla mai departe. De
asemenea, Grails permite crearea de valida-tori 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-domain-class 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 messageDate 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 aplicația noastră există două relații:
Un user poate avea mai multe mesaje. Această relație va îmbogăți clasa User cu un nou atribut: messages. Mai jos este definite relația:static hasMany = [messages: Message]
Un mesaj aparține unui utilizator, însemnând că nu poate exista fără a fi aso-ciat unui user. Această relație va îmbogății clasa Message cu un nou atribut: user. Mai jos este definită relația:static belongsTo = [user: User]
Setarea datelor de testMomentan, aplicația noastră nu are
nici un storage permanent. Grails folosește în mod normal o bază de date în memo-rie care nu are persistență. Dar, putem să ne creăm noi niște date de test. Pentru aceasta, trebuie să specificăm o listă de obiecte pe care le dorim create la porni-rea aplicației. La pornire, Grails apelează closure BootStrap.init. Localizează clasa și adaugă bucata de code de mai jos: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: Sky-fall!”)) user2.addToMessages(new Message(message: „Waiting for the summer...”))
De asemena, observăm că mai există un closure “destroy” care se apelează când aplicația este închisă, deci poate fi folosit
Introducere în Grailsprogramare
31www.todaysoftmag.ro | nr. 6/2012
TODAY SOFTWARE MAGAZINE
pentru a executa operații de cleanup, etc.
Crearea controllerilorControllerii sunt cei care determină
f low-ul unei aplicații. Deoarece Grails folosește “convenție și nu configurare”, numele unui controller este de genul <ClasaDomeniu>Controller, deci vom cre-ate 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 control-ler, 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/today-softmag/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țieiO modalitate de autentificare a aplicației
este folosirea filtrelor. Pentru a crea un fil-tru, 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: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”)
Acțiunea va verifica username-ul și parola pentru potrivire și va adăuga obiec-tul “user” găsit pe sesiune, iar apoi va redirecta aplicația spre pagina care afișează lista de mesaje pentru user. Altfel, utilizato-rul 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 deli-
mita 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 ren-der, 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 înde-mână de a selecta date. In cazul nostru, verificăm dacă există un User care are “username” egal cu cel spe-cificat în formul de login (params.username).
• “Render” apelează un view cu para-metri 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ă contro-ller-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 retur-nată 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.)
32 nr. 6/2012 | www.todaysoftmag.ro
Exemple practice de message paterns pentru Windows Azure
Toată infrasctructura stă în cloud. În prin-cipal 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 distri-buirea de produse alimentare în toata ţara. Acesta se ocupa cu distribuirea acestor pro-duse 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 dife-rite, 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 capa-citatea 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ă regi-une. 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ă magazi-nele care urmează să fie notificate.
Fiecare magazin urmează să aibă o sub-scripţie unică. În cadrul acestei subscripție vor fi specificate datele despre magazine precum nume, regiune, adresa, tip maga-zin. Subscripţiile urmează să fie create doar de către clientul nostru, iar magazinele doar doar se vor inregistra la aceste sub-scripţ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ă sub-scripţii în cadrul acestui exemplu.
Î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.
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 spe-cial din punct de vedere software.
33www.todaysoftmag.ro | nr. 6/2012
TODAY SOFTWARE MAGAZINE
SqlFilter tipTop100Filter = new Sql-Filter(„ region LIKE ‚%Banat%’ OR shopName = ‚Tip Top’ OR shopType = ‚family’”);
namespaceManager.CreateSubscription( distributionTopic”, „TipTopShop100Subscription”, tipTop100Filter);SqlFilter stefan20Filter = new Sql-Filter(„ region LIKE ‚%Moldova%’ OR shopName = ‚Stefan’ OR shopType = ‚minimarker’”);
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ă tri-mitem 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.CreateFromCon-nectionString( CloudConfigurationManager.GetSetting(„ServiceBusConnectionString”), „distributionTopic”, „stefan20Subscription”);
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 pen-tru care filtrul de pe subscripţii va returna TRUE.TopicClient distributionTopicClient = TopicClient.CreateFromConnection-String( CloudConfigurationManager.GetSetting(„ServiceBusConnectionString”), „distributionTopic”);
BrokeredMessage offerMessage = new BrokeredMessage();
În exemplul de mai sus am văzut cât de usor este să distribuim ofertele la mai multe magazine fără să ne punem problema dacă magazinul va primi sau nu mesajul. Iar modul în care specificăm ce magazine tre-buie să primeasca oferta dată este extreme de simplu.
Din punct de vedere al scalabilitaţii, un topic poate să aibă pană la 2000 de sub-scripţii. Aceasta nu înseamnă că suntem limitați doar la 2000 de mesaje. Ne este extrem de usor să includem un alt topic.
În continuare ne imaginăm clientul nostru venind cu următoarea cerinţă. Din cauză că s-a extins extrem de mult în ulti-mul timp, și-a creat responsabili regionali care se ocupă de procesarea comenzilor pe care le face fiecare magazin. Din cauză că nu cunoaste modul în care piaţa se va dezvolta, clientul nostru are nevoie să gru-peze mai multe regiuni, iar apoi cu costuri minime să poată împarţi din nou regiu-nile. Totodata pentru a putea supraveghea activitatea pe care aceștia o au, el dorește sa creeze un mecanism de audit, iar toate comenzile trimise de către magazine să fie înregistrate.
Ca să rezolvăm aceasta cerinţă, putem să apelăm la Dynamic Router Message Pattern. Acest patern ne permite să ne definim o listă de reguli de direcţionare a mesajelor, care poate să fie schimbată la runtime fară nici un fel de probleme.
Iniţial clietul nostru va porni doar cu două grupuri de regiuni, iar în timp, în functie de cum se schimbă piaţa, acesta o să își defineasca grupe de regiuni mai mici. Fiecare grupare de regiuni va avea cate o subscripţie care aceptă comenzile pentru o listă de regiuni. Nu vom mai prezinta modul în care se crează un topic, acest lucru l-am văzut puţin mai sus.SqlFilter groupFirstRegionFilter = new SqlFilter(„ region LIKE ‚%Moldova%’ OR region LIKE ‚%Banat%’”);namespaceManager.CreateSubscription( „commandTopic”, „groupFirstRegionSubscription”, groupFirstRegionFilter);
Această primă subscripţie va deservi două regiuni. În cazul în care clientul nos-tru hotărăste ca cele doua regiuni să fie deservite de persoane diferite va fi necesar să modifice această subscripţie și să adauge o altă subscripţie.
Pentru fiecare subscripţie se poate adă-uga sau șterge o regula la runtime. În acest caz putem să ștergem regula deja definită și să adăugăm altă regulă. Pană acum am
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 regulă să aibă un nume unic. În general, o regulă conţine câte un filtru.SubscriptionClient groupFirstRegion-Subscription = SubscriptionClient. CreateFromConnectionString( CloudConfigurationManager. GetSetting( „ServiceBusConnectionString”), „commandTopic”, „groupFirstRegionSubscription”);
SqlFilter groupFirstRegionFilter = new SqlFilter(„ region LIKE ‚%Moldova%’ OR region LIKE ‚%Banat%’”); groupFirstRegionSubscription. AddRule(„ruleForMoldovaAndBanat”, groupFirstRegionFilter);
groupFirstRegionSubscription. RemoveRule( „ruleForMoldovaAndBanat”);SqlFilter banatRegionFilter = new SqlFilter(„ region LIKE ‚%Moldova%’”);
În exemplul de mai sus am adăugat un filtru pe care apoi l-am șters, iar apoi am adăugat o nouă regulă. Aceste reguli se aplică automat din momentul când sunt adăugate.
Prin acest mecanism, putem să schim-băm în mod dinamic regiunile deservite de către un responsabil. În cazul în care este nevoie, avem posibilitatea să adăugam sau să stergem o subscripţie ori o regulă fără să fie necesar să oprim sistemul.
O altă cerinţă a clientului nostru era ca toate comenzile să fie salvate, pentru a putea să fie mai tarziu verificate. Această cerinţă este ca și implementată. Avem nevoie să adaugăm o subscripţie care nu are nici o regulă sau nici un filtru definit. Mai simplu de atât nici nu putea să fie.namespaceManager.CreateSubscription( „commandTopic”, „allCommandsSubscription”);
Fiecare magazin va trebui să creeze un mesaj pentru fiecare comandă, unde ‘region’ va fi setat în mod automat cu regi-unea din care face parte.
Dacă vă puneţi problema costului, tre-buie să vă zic că șase milioane de mesaje trimise prin intermediul Windows Azure Service Bus ne costa 6$, dacă 10 magazine ascultă 24 de ore din 24 la o subcripţie ne costa circa 7$ pe lună. În viitor este posibil ca aceste preţuri să scadă și mai mult.
În cadrul acestui articol am văzut cat de usor este sa distribuim mesaje folosind infrastructura pe care Windows Azure o pune la dispozitie. Paternuri precum Content-Based Router Message Pattern și Dynamic Router Message Pattern pot să fie implementate cu ușurinţă și cu costuri minime. Scalabilitatea ne este oferită build-in de către Windows Azure.
34 nr. 6/2012 | www.todaysoftmag.ro
În același timp foarte multe compa-nii care au nevoie de produse software nu sunt dezvoltatori software și operează într-o piață tot mai apăsată de constrân-geri de cost și timp; marea majoritate a acestor companii doresc livrarea produse-lor 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 tele-fonie 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 parte-ner 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 admi-nistrare în paralel cu dezvoltarea sistemului
din backend. Ca urmare a rezultat următo-rul context la startul proiectului:• Specificații funcționale cu un nivel
de detaliere insuficient;• Servicii externe indisponibile pen-
tru integrare;• Detaliile tehnice de integrare necesi-
tau 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ă, iden-tificare de potențiale căi critice etc. . Din primele zile discutând cu echipa am reali-zat 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
Metodologiile 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 rezul-tatelor dorite.
Certified ScrumMasterare 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
35www.todaysoftmag.ro | nr. 6/2012
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 pro-iectului cât și de a livra conform cu angajamentele luate. În primele zile, săp-tamâni, specificațiile fiind insuficient de clare, energia echipei a mers pe lângă cla-rifică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 potri-vite pentru înaintarea proiectului. A fost esențial faptul că am avut în cadrul echipei roluri specializate precum:• Business Analyst – la nivelul între-
gii 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 clari-ficarea 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 corespun-ză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 ter-mene 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 flexibili-tate 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 pro-cess engineering pe care le-am amintit deja au fost esențiale, ne-au ajutat să avem o calitate bună, am câștigat timp prin auto-matizarea 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 cli-
entul 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 clien-tului 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 rele-ase-uri având pentru fiecare din cele două faze principale de livrare (soft și hard launch) mai multe sub-faze de testare).
Cost: dat fiind că am reușit să ne înca-dră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 specia-
lizate în propria echipă.
36 nr. 6/2012 | www.todaysoftmag.ro
tehnologii
atacuri din 2012. Concluziile articolului încearcă să
scoată în evidență riscurile la care sunt supuse infrastructurile romanești și cât de bine suntem pregătiți pentru atacuri infor-matice serioase. Prezentarea clasamentului va fi realizat în ordine descrescătoare, în funcție de complexitatea și pagubele făcute, dezvoltând un clasament realizat de ThreatMatrix.
10. GHOSTSHELL• grupul Anonymous int itu lat
GHOSTSHELL a furat peste 120,000 de înregistrări de la universități de top din lume injectând malware în site-uri;
• printre facultăți se numără Harvard, John Hopkins, The University of Michigan etc.
9. U.S Enviromental Protection Agency• o breșă în securitate a dus la compro-
miterea datelor a 8,000 de angajați și alte conturi bancare;
• e amuzant că au fost necesare 4 luni până când US EPA a anunțat persoa-nele afectate.
8. Go Daddy• Anonymous și-a însușit numeroase
atacuri DDoS pe 10 septembrie;• pentru o perioadă de timp au fost
afectate zeci de site-uri world wide, până și serviciile de email;
• Go Daddy a infirmat ipoteza.
7. Yahoo! Voice• un grup intitlulat D33DS Company
au obținut prin SQL Injection aproape 454,000 de conturi Y! Voice printr-un simplu SQL Injection;
• parolele erau stocate în plain text.6. Global Data Inc. (Visa & Master
Card)• o breșă în sistemul de procesare a
datelor de card a dus la pierderea a 1.5 milioane de numere ale unor carduri bancare;
• breșa nu a dus și la pierderea datelor de facturare nici a numelor.
5. Microsoft Internet Explorer• o problemă de securitate descoperită
în septembrie permite hackerilor să instaleze aplicații malițioase pe computerele personale;
• 41% dintre utilizatorii din America de Nord sunt afectați de vulnerabili-tate și peste 31% la nivel global;
• vulnerabilitatea de tip RCE(Remote Code Execution) poate rula un script de la distanță pe IE 6,7,8,9 dar nu pe 10;
• nici IE 10 nu scapă pentru că există o vulnerabilitate în Flash ce este folosită world wide.
4. Android• în această toamnă a fost sesizat că
aproape 200 de milioane de tele-foane cu Android sunt în pericol de a fi resetate complet, pierzându-se absolut toate datele de pe ele, exis-tând posibilitatea distrugerii și a SIM-urilor;
• sunt afectate telefoanele produse de Samsung, HTC, Motorola și Sony Ericsson și majoritatea versiunilor
Anul 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
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 mili-
oane 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 ata-cului, 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 mili-
oane 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-isla-mez 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 compromi-
terea 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 mana-gement și au făcut transfer de încredere ce s-a resimțit asupra lor;
• Zappos a trimis un email tutu-ror utilizatorilor și le-au cerut să schimbe parolele aproape imediat.
Deși aceste atacuri au fost extrem de mediatizate, acestea sunt doar cireașa de pe tort, sunt informațiile care ies la suprafață. Nu trebuie să uităm de atacurile
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 informa-tice 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 infor-matic 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 vir-tual. 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 nume-roase 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 infor-matică din Europa de Est, de aproape un deceniu, a deschis Crysys, un centru de cer-cetare 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ă.
Noi ce avem? DefCamp – conferință de hacking & securitate!
Aflată la a treia ediție, DefCamp 2012 @Bucuresti (http://defcamp.ro) este una dintre cele mai importante inițiative
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 prezen-tări susținute de oameni cu experiență în domeniul INFOSEC, vor putea monitoriza Wall of Sheep, ar putea participa la concur-sul 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 secu-rity 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 eve-nimentului între echipele finaliste. Temele competiției sunt extrem de variate și provocatoare – exploits, cryptography, pro-gramming, 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 reali-zarea 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ă. :-)
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 cer-tificare 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 com-portă 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ţu-rile 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 con-stituie partea mai pământeană a filosofiei Agile și anume unelte puse la dispoziţie de unele metodologii. Agile nu este o meto-dologie, este o grupare de metodologii. Și aceste metodologii, cel puţin cele mai fai-moase 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 metodologi-ile 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 compa-niei. 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”.
Orice 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 des-pre 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
Dincolo de perplexitatea că putem judeca, uneori atât de dur, o metodologie fără să o cunoaștem suficient, recomandăm tutu-ror 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 metodolo-gie 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ă pen-tru 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 pro-ducţ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 maximi-zarea valorii a ceea ce se livrează), echipa de dezvoltare (responsabilă cu livrarea unui potentially releasable, increment de funcţionalitate) și un Scrum Master (res-ponsabil cu împărtășirea conceptelor de Scrum către echipă și respectarea procese-lor 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ţi-onalităţ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 retros-pective (în care se analizează modul cum echipa a lucrat, dacă s-au respectat toate procesele, etc.).
A doua metodologie, în ordinea fai-mei ș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 respec-tul. 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 ime-diat 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 incremen-tal?), 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), refacto-ring (curaţarea codului fără a-i schimba efectul), continuous integration (fiecare membru trebuie să ofere propria contri-buţie tot timpul), collective code ownership (întreaga echipă lucrează la cod și oricând membrii echipei se pot roti între ei), plan-ning 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 suplimen-tare), 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 sim-ple ș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 pri-veș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 activi-tăţ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 dez-voltarea 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, pla-nificarea în funcţie de aceste feature-uri iar apoi design-ul și dezvoltarea fiecărui feature.
Cei mânaţi de curiozitate veţi des-coperi 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 sim-plu, de cele mai multe ori abordarea este superficială, ceea ce duce la un eșec rapid. Închei prin a menţiona încă o dată mode-lul 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.
40 nr. 6/2012 | www.todaysoftmag.ro
Cel care a introdus acest termen a fost Byrne, care îl definea ca fiind ”echilibrul între cele cinci aspecte esențiale ale vieții: serviciu, familie, prieteni, sănătate și spi-rit”, care nu înseamnă neapărat o divizare exactă a timpului aferent fiecărui aspect, ci este vorba despre crearea acelui nivel care să aducă satisfacția dorită pentru fie-care dintre cele cinci roluri. Nu aș vrea să insist foarte mult pe aspectele teoretice ale acestui concept, dar consider că pentru o înțelegere cât mai bună a lui, este necesar o trece succintă prin una dintre cele mai importante și cunoscute teorii, dezvoltată de către Tim O’Brien ”Diferitele părți ale unei vieți echilibrate” (en. ”the many sides of a balaced life”), care susține că există mai multe feluri de echilibru:• Echilibrul social: timpul pe care
petrecut cu sine sau cu ceilalți. Teoriile psihologice susțin că două dintre nevoile primare ale omului sunt: nevoia de socializare și nevoia de solitudine, astfel cu cât petreci mai mult timp singur riști să devi mai izolat si orientat către sine, iar cu cât socializezi mai mult cu ceilalți riști să duci o viață superficială.
• Echilibrul mental: timpul petre-cut pentru învățare și în scop recreațional. Echilibrul constă în îmbinarea plăcutului cu învățatul.
• Echilibrul emoțional: constă în sensibilitatea la probleme și obiec-tivitatea cu care sunt soluționate acestea. Cu cât devenim mai emoțional implicați, cu atât deciziile luate sunt mai dezechilibrate.
• Echilibrul fizic: implică sănătate corporală și mentală. Este nece-sar un echilibru în ceea ce privește exercițiile fizice și nutriția, pentru că nivelul de oboseală corporală și nivelul de stres au un impact asupra deciziilor luate.
• Echilibrul financiar: găsirea echi-librul între cheltuieli, venituri și economii și implică decizii care au un impact asupra stilului de viață.
• Echilibrul spiritual: obținerea acelei satisfacții spirituale, care te deter-mină să fii mulțumit cu tine însuți/însăți.
Echilibrul viață personală – viață pro-fesională perceput în cultura tării. Pe de altă parte, consider că un impact mare asupra stabilirii acestui echilibru îl are cul-tura țării în care trăim. De menționat că au fost implementate politici la nivel euro-pean care încearcă să îmbunătească viața prin trei obiective ale acestei strategii de dezvoltare.
1. Cât mai multe și mai bune locuri de muncă pentru cetățenii europeni, prin dezvoltarea unei politici active de angajare.
2. Dezvoltarea unor programe de educație și training pentru dezvolta-rea cunoștințelor.
3. Programe de incluziune socială. Prin acestea se dorește creșterea calității
vieții, nu doar definirea unui standard minim acceptat. În multe din statele vest europene deja există o îmbunătățire vizi-bilă a echilibrului între viața personală și cea profesională. Cu toate acestea ce se întâmplă la nivelul fiecărei țări este departe de situația ideală definită de către Comisia Europeană, iar principalele probleme iden-tificate au fost:
• Neuniformaadoptare:deșiregle-mentările sunt agreate la nivel global, ele nu sunt implementate în fiecare țară și cu atât mai mult în fiecare companie și sector în care aceasta activează. Studiile efectuate la nivel european, demonstrează că mai mult de o treime dintre companiile care activează în domeniul manufacturier nici măcar nu iau în considerare aceste poli-tici. Pe de altă parte, companiile care au un departament dezvoltat de resurse umane, au demonstrat o creștere semnificativă în crearea acelui echilibru între viața perso-nală și cea profesională. • Lipsă de formalizare: puține tări
au legi scrise care să reglementeze aceste politici europene.
• Cenzura și restricțiile impuse
angajaților: lipsa de educație a angajațiilor despre acest concept nou întâlnit pe piață.
• Presiunea business-ului: orice com-panie va înclina mereu balanța înspre interesele care îi vor păstra avantajul competitiv pe piață, decât înspre echilibrarea vieții personale a angajatului cu cea profesională, deoarece nu este înțeles pe deplin impactul pozitiv pe care aceasta îl poate avea în dezvoltarea companiei.
• Timpul de lucru: deși este stabilit un program de lucru de 8 ore pe zi, mulți dintre anjagați petrec mai mult timp la birou datorită volumului de muncă foarte ridicat pe care îl au, deoarece foarte rare sunt situațiile în care angajatorii iau măsuri pentru o reorganizare a muncii. Chiar dacă legislația muncii încearcă să prote-jeze angajații de astfel de abuzuri, posibilitatea de a lucra de acasă, dez-echilibrează mai mult acest balans.
Echilibrul viață personală – viață profe-sională perceput în cultura organizațională a companiei. Cu toate aceste impedimente, fiecare dintre noi ar trebui să înțeleagă că echilibrul între viața personală și cea pro-fesională este dat de eficiența și eficacitatea la locul de muncă. Cu cât reușesți să faci mai multe într-un timp mai scurt, cu atât ai mai mult timp pentru a-l dedica familiei și prietenilor. Drept o soluție la toate aces-tea companiile ar putea implementa politici care să încurajeze:• Programul flexibil: realizarea celor
40 ore legale conform codului mun-cii, dar permiterea unei flexibilități pentru rezolvarea unor situații per-sonale, cu condiția ca de încrederea care îi este acordată angajatului să nu se abuzeze și să se respecte timpul de lucru și mai ales să se îndeplinească sarcinile de lucru.
• Posibilitatea de a lucra de acasă: permite angajaților să își organizeze timpul și în jurul valorilor personale și în funcție de nevoile familiale. Mai
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.
HR
Echilibrul dintre viața profesională și cea personală
41www.todaysoftmag.ro | nr. 6/2012
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 demon-strat 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 angajamen-
tului 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 per-
sonală ș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 tim-pului 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 cul-turi organizaționale care să încurajeze
echilibrului între personal și profesional este încă un proces îndelungat pe care multe dintre companii abia l-au înce-put sau altele, din păcate nici măcar nu au făcut primii pași în această direcție. Echilibrul viață personală – viață profesi-onală 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 reflecta-rea satisfacției și împlinirii în mai multe domenii, cu implicații negative scăzute în altele. De exemplu, o persoană mate-rialistă, care poate ajunge la un nivel de satisfacție financiară ridicată nu este nea-pă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, comu-nitatea. 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 atin-gerii 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 nevoi-lor 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 profesi-onală sunt date de personalitatea fiecăruia dintre noi. Au fost realizate numeroase studii în care s-a demonstrat că persoa-nele ”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 comporta-ment 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ă încu-rajeze 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ă?”
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 nicio-dată. Î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 cli-entul 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 ofi-cială 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, evi-dent, dar aproape că îi scăpă lui Gogu. Șefu’ își mai drese o dată vocea, se uită pătrun-ză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 ansam-blu. Își reveni însă rapid.
