TSM_4_2012_ro

No. 4 / 2012 • www.todaysoftmag.ro

TSM

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

Impresii TechEd North America 2012 Metoda de estimare Function Point în practica Microsoft SQL Server Optimizarea performanței Analiza mecanismului Object–Relational Mapping (ORM) cu exemplificari Hibernate SEO QA adaptabilitatea la schimbarile algoritmilor de cautare Google Flame - arma cibernetica dezmembrata Restful Web Services folosing Jersey Microsoft Project si proiectele Agile Semantic Web scurta introducere Made in Cluj - Jumping Electron Big Data - Apache Hadoop Background tasks - Metro Gogu

8 Impresii TechEd North America 2012 Leonard Abu-Saa

10 Analiza mecanismului Object–Relational Mapping (ORM) cu exemplificari Hibernate Anghel Contiu

14 SEO QA adaptabilitatea la schimbarile algoritmilor de căutare Google Radu Popescu

17 Metoda de estimare Function Point în practică Ionel Mihali

20 Microsoft SQL Server Optimizarea performantei Cosmin Cristea

22 Restful Web Services folosing Jersey Tavi Bolog

25 Semantic Web scurta introducere Dia Miron

28 Flame arma cibernetica dezmembrată Andrei Avădănei

31 Big Data Apache Hadoop Robert Enyedi

34 Made in Cluj Jumping Electron finmouse

36 Background tasks Metro Radu Vunvulea

39 Microsoft Project si proiectele Agile Florian Ivan

41 Gogu Simona Bonghez

editorial

Editorial Salut,

Ovidiu Măţan, PMP

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

Ultimele luni s-au dovedit a fi pline de evenimente. ITCamp a fost foarte bine organizat implicând speakeri locali și internaționali care au oferit oportunitatea de a ne pune la curent cu ultimele trend-uri Microsoft. S-a remarcat importanța și sprijinul pe care Microsoft le acordă comunității. Mi-ar plăcea să văd desfășurându-se local conferințe de același rang și de la concurența Apple si Sun. Lista mea de impresii continuă cu Hack a Server unde a lansată platforma de testare a vulnerabilităților pusă la dispoziția hackerilor și a administratorilor de sisteme. Business Days Cluj-Napoca a fost un alt eveniment de excepție la care TSM a fost prezent. De data aceasta target-ul a fost mediul bussines iar interesul mare pentru astfel de subiect s-a vazut prin cei peste 800 de participanți.

Ultimele două evenimente la care am fost prezenți au fost axate pe tehnologii: Saturday Ruby - o sâmbătă alocată învățării și aprofundării Ruby - iar al doilea eveniment Code Camp - axat pe ultimele noutăși și tehnologii de la Microsoft. Mai multe detalii și imagini despre acestea veți găsi în articolul special dedicat acestor evenimente. Începând cu acest număr vom incerca să fim mai aproape de cititorii noștri prin crearea unui eveniment de lansare la fiecare apariție a unui număr TSM. Prin rotație, sponsorii revistei vor găzdui evenimentul. Cu ocazia acestor mini-conferințe vom pune în fața cititorilor pe autorii articolelor din ultimul număr, dând astfel ocazia creării unui dialog și formarea unei comunități. Fiecare participant va primi gratuit revista TSM. Acest număr al revistei se remarcă prin multitudinea de tehnologii abordate. Veți găsi în paginile revistei articole începând de la Restful Web Services folosind Jersey până la înțelegerea semantică a web-ului. Vechea dilemă legată de modul de a persista datele este analizată în Analiza mecanismului Object–Relational Mapping (ORM) cu exemplificari Hibernate. Daca dorim însă un mai mare control și alegem SQL, Microsoft SQL Server Optimizarea performantei prezintă modul de a optimiza performanța folosind datele din producție. O noutate este introducerea unei serii de articole pe tema virușilor informatici care se deschide cu un articol despre celebrul virus Flame, descendent al Stuxnet-ului.

Continuăm seria Big Data cu o introducere în Apache Hadoop. Promovăm inițiativele românești prin prezentarea realizării jocului Jumping Electron pe platforma Android de către compania Finmouse. Abordăm planificarea proiectelor Agile cu ajutorul tool-ului Microsoft Project iar asa cum v-am obișnuit deja încheiem cu Gogu, acel personaj distrat care greșește dar învață din greșelile sale.

Vă așteptăm la următoarele evenimente TSM!!!

Mulţumesc,

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

4

nr. 4/2012 | www.todaysoftmag.ro

Redacţie Fondator / Editor in chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com Editor (startups și interviuri): Marius Mornea marius.mornea@todaysoftmag.com Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com Colaborator marketing: Ioana Fane ioana.fane@todaysoftmag.com Reviewer: Romulus Pașca romulus.pasca@todaysoftmag.com Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com

Lista autorilor Cosmin Cristea cosmin.cristea@endava.com

Robert Enyedi robert.enyedi@betfair.com

CLD Head of Development Endava

Senior Software Developer @Betfair

Anghel Contiu

anghel.contiu@threepillarglobal.com

Andrei Kovacs

andrei@finmouse.com Fondator & CEO Finmouse

Senior software developer, Three Pillar Global

Radu Popescu

Radu Vunvulea

QA şi Web designer Small Footprint

Senior Software Engineer @iQuest,

rpopescu@smallfootprint.com

Radu.Vunvulea@iquestgroup.com

Produs de

Today Software Solutions SRL

Florian Ivan, PMP

florian.ivan@rolf-consulting.com

Ionel Mihali

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

Ionel.Mihali@isdc.eu Project MVP QA Officer @ISDC

Leonard Abu-Saa

Simona Bonghez, Ph.D.

System Architect Arobs

Speaker, trainer şi consultant în managementul proiectelor, partener al TSP(smartprojects.ro)

leonard.abu-saa@arobs.com

simona.bonghez@smartprojects.ro

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

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

Marius Mornea

marius.mornea@todaysoftmag.com Fondatorul platformei Mintaka Research

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

Ovidiu Măţan, PMP

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

Alina Dia Miron, Ph. D. dia.miron@recognos.ro Semantic Web Expert @Recognos Romania

www.todaysoftmag.ro www.todaysoftmag.com

www.todaysoftmag.ro | nr. 4/2012

5

evenimente

Evenimente locale Business days

Ovidiu Măţan, PMP

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

Evenimentul a fost primul de acest tip la care TSM a participat ca partener media.

Pe parcursul a două zile am putut participa la numeroase mese rotunde, workshopuri, conferințe și chiar la o întâlnire de networking. Trebuie să recunosc că nu am mai luat parte la așa ceva. Procesul este unul interesant în sensul că fiecare participant trebuie să dea o cartea de vizită celorlalți și să descrie în câteva cuvinte business-ul său, domeniul în care poate să dea recomandări și în ce domenii are nevoie de ele. Totul se petrece foarte repede iar după prezentări este o secțiune de networking. Veți fi uimiți de câtă lume poate fi interesată de business-ul vostru iar persoanele și domeniile care pot deveni conexe sunt inedite.

Un workshop foarte interesant la care am participat a fost cel despre social media, unde am asistat la deconstruirea mitului despre social media care îți aduce o mulțime de benefici financiare. Un milion de fani nu va aduce un milion de dolari automat. Se poate întâmpla și acest lucru, dar este nevoie de un produs care face față competiției, caz în care rețelele sociale vor fi folosite pentru a avea un dialog cu fanii și nu pentru a vinde efectiv produsul.

Hack a server

Nu mai sunt multe de spus despre aceasta platformă pentru că toată lumea ar trebui să știe deja despre existența sa după apariția unui interviu în numărul 3 al TSM precum și pe site-urile locale și postul de Televiziune Transilvania. Conform ultimei discuții cu Marius Corîci, platforma se transformă într-un succes, devenind din ce în ce mai populară. Vă vom ține la curent pe viitor cu evoluția ei.

Ruby

A fost un început plăcut de weekend.

Sâmbătă, de la ora 10, m-am dus la ISDC unde am avut parte de o introducere a limbajului Ruby, continuând cu subiecte mai avansate în cea de-a doua parte a zilei.

Remarc entuziasmul și pasiunea speakerilor și recomandăm viitoarele întâlniri ale acestui grup pentru tuturor celor care vor sa aprofundeze Ruby sau să învețe ceva nou.

Code camp

Pe data de 21 iulie am avut parte de un eveniment IT de vară organizat de către comunicatea CodeCamp din Cluj-Napoca.

Evenimentul a avut loc la sediul ISDC și deși a fost o zi de sâmbătă extrem de caldă și frumoasă, mai mult de 45 de specialiști IT s-au strâns la acest eveniment.

6

nr. 4/2012 | www.todaysoftmag.ro

evenimente

TODAY SOFTWARE MAGAZINE ITCamp

Marius Mornea

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

Având în vedere că în numărul trecut am explorat majoritatea aspectelor cantitative și calitative atât ale evenimentului în sine cât și ale organizatorilor și invitatilor, în acest articol ne propunem să prezentăm atmosfera ITCamp și impresiile cu care rămâi după acesta. În primul rând am fost impresionat de dimensiuni: 280 de participanți par mai puțini pe hârtie decât în realitate. Dintre toate evenimentele locale, de profil, la care am avut ocazia și plăcerea să particip până acum, ITCamp se încardează în altă ligă din punctul de vedere al numărului de participanți, vorbitori și conținut. Atmosfera cu care te întâmpină este una de entuziasm. O analogie un pic mai îndrăzneață ar fi asemănarea cu un parc de distracții: multă lume, dar și multe zâmbete, multe atracții și agitația în încercarea de a ajunge la cele mai bune, iar după fiecare atracție discuțiile aprinse și polarizarea între cei entuziaști și mulțumiți și cei ușor șifonați. Cam așa m-am simțit și eu cu orarul în mână, nu știam ce traseu să îmi aleg, ca să maximizez satisfacția finală. Cateodată ești tentat să alegi vorbitorul vedetă, câteodată ești curios de ce toată lumea se grăbește într-una dintre săli, iar câteodată te tentează tocmai sala cea mai goală, cu prezentatorul de care nu prea știi mare lucru. Înainte de a intra în detalii despre atmosfera din timpul prezentărilor, aș dori să remarc câteva aspecte organizatorice: prima impresie a fost una de profesionalism (echipa tehnică dedicată cu sunetist si cameraman, procesul de înregistrare relativ rapid și multe zâmbete), dar apoi au urmat câteva scăpări care ne-au adus aminte că suntem doar la a doua ediție, iar timpul limitat de organizare pentru un eveniment de asemenea dimensiuni își spune cuvântul (un cablu hdmi de negăsit, lipsa cafelei la prima ora și probabil cel mai supărător: conexiunea la internet foarte slabă, care a incurcat cel puțin câteva prezentări). Motivul pentru care am amintit aceaste scăpări este atitudinea publicului față de ele: dacă la început erau observate și aduse în discuție, în scurt timp erau uitate, deoarece pur și simplu nu era timp de pierdut cu detalii așa mici când aveai atatea prezentări de urmărit. Având în vedere rețeta succesului dată de Mihai în numărul trecut (“evident mâncarea și cafeaua sunt foarte importante, dar clar primul este conținutul”), țin să precieze că nici nu mai știu ce am mâncat în cele două zile, pauza de masa fiind plină de dezbateri, discutii, schimburi de impresii și încercări de a mai fura două răspunsuri de la un invitat sau altul. Conținutul primează clar în față mâncării, cafelei sau scăpărilor organizatorice, motiv pentru care doar conexiunea slabă la net rămâne singurul minus supărător, tocmai pentru că a interferat cu acesta.

Tocmai pentru ca întreaga atmosfera a fost dictata mai mult de continut decât de orice alt aspect organizatoric, merită să povestim un pic și de echipa despre prezentatori.

Am ales cuvântul echipă intentionat, pentru că acesta este sentimentul pe care îl lasă: de la disponibilitatea în a ajuta (de exemplu cele două prezentări extra ținute de Lino și Paula, pentru a acoperi golurile lăsate de un coleg bolnav sau absent motivat), până la chimia dintre ei: Tim glumind cu colegi din public, mai exact Tibi, pentru a acoperi cu râsete demo-ul care nu mergea; sau jocul de-a administrator versus programator făcut de Paula cu Tibi; iar nu în ultimul rând ușurința cu care se completează în open panelul despre comunități și reușesc să transmită un mesaj comun și coerent. Nu are rost să intru în detalii despre fiecare prezentare, prefer să vă invit să le urmăriți pe siteul evenimentului și să vă formati singuri o părere. Dar vreau să închei prin a preciza că atât valorile individuale ale prezentatorilor, care au compensat prin carisma atunci când nu mergea prezentarea sau depășeau timpul alocat, cât și spiritul de echipă și unitate, au construit o conferință solidă plina de conținut de calitate. Vă recomand cu căldură ediția viitoare. www.todaysoftmag.ro | nr. 4/2012

7

evenimente

Impresii TechEd North America 2012 TechEd? A dream come true. A fost primul eveniment de o asemenea anvergură la care am participat și pot spune că a fost senzațional. În termeni tehnici s-ar traduce prin “it’s a must”. Este, după părerea mea, ceea ce fiecare Dev/Architect/Project Manager/ Sysadmin/QA/etc. ar trebui să-și dorească.

Leonard Abu-Saa

leonard.abu-saa@arobs.com System Architect Arobs

Ca și desfășurare, evenimentul a avut loc în cinci zile consecutive, începându-se cu așa numitele PreConference seminars; numele este descriptiv, deci nu o să intru în detalii. În zilele de luni și marți am avut câte o sesiune de Keynote, pe care o voi descrie mai jos.

Keynote-ul de luni

S-a vorbit despre platforma cloud: private Cloud și public Cloud. Au fost acoperite topicurile System Center și Server 2012.

Trebuie să recunosc ca am fost uimit de realizările echipei atât pe partea de System Center cât și pe partea de Server 2012. Un demo care m-a impresionat a fost cel referitor la Server 2012 și Hyper-V. Acesta a evidențiat partea de acces la resurse, mai exact copierea unui fișier de 10 GB. Dacă până acum copierea dura … câteva minute, ei bine, acum va dura secunde! Viteza este de aproximativ 1 GB/sec! Awesome!

Keynote-ul de marți

Marți s-a prezentat Windows 8, sau cel puțin “s-a zgâriat suprafața”, dupa cum spunea Antoine Leblond.

Pe mine m-a convins chiar din prezentarea sa. Dupa keynote am ieșit în holul principal să văd cât costă și când va fi disponibilă pe piață o tabletă Samsung cu Windows 8. Arată absolut impecabil și se comportă la fel. Funcționează atât cu dispozitive touch, cât și cu tastatură și mouse.

Cu alte cuvinte, îmbină utilul cu plăcutul.

După keynote-uri, participanții aveau de ales (prea multe opțiuni, după părerea mea) dintr-o serie de domenii: 1. Architecture & Practices (AAP) 2. Database & Business Intelligence (DBI) 3. Developer Tools, Languages & Frameworks (DEV) 4. Exchange & Lync (EXL) 5. Management (MGT) 6. Office 7. Office 365 & SharePoint (OSP)

8

nr. 4/2012 | www.todaysoftmag.ro

8. Security & Identity (SIA) 9. Virtualization (VIR) 10. Windows Azure (AZR) 11. Windows Client (WCL) 12. Windows Server (WSV) În total au fost câteva sute de sesiuni pentru aceste domenii. Și dacă ne gândim la faptul că am avut 4 zile la dispoziție pentru acestea… ei bine, vă las să cugetați. Între sesiuni era o pauză de jumătate de oră, care trecea incredibil de repede: drumul din holul sud în holul nord sau invers + un suc pe drum.

Locația evenimentului

Orange County Convention Center - o clădire imensă. Nu vreau să exagerez, dar din holul sud al clădirii până în holul nord mergeam aproximativ 5-7 minute (depinde de cât eram de grăbit). Temperatura: -10°C. Evident exagerez, dar oricum era foarte rece înăuntru.

Concluzii

Dacă la început eram nedumerit de ce se termină evenimentul joi, ei bine, m-am lămurit. A fost într-adevăr foarte frumos, dar și cantitatea informației a fost pe măsură. Orarul zilnic destul de aglomerat, (08:00-18:00), dar și cantitatea informației au făcut simțită prezența oboselii. O zi în plus ar fi fost prea mult.

Finalul evenimentului nu a fost lipsit de surprize. Participanții au avut intrare liberă la Universal Studios, un parc de distracții foarte drăguț din Orlando, unde au putut să se delecteze cu ride-uri pline de adrenalină sau să asiste la concertul rock al unei formații de “nerds”. Cortina unui show extraordinar s-a tras joi noaptea, târziu.

Noapte bună, TechEd 2012! Ne vedem la anu’!

TODAY SOFTWARE MAGAZINE

Comunităţi IT Cluj-Napoca

S

ecţiunea comunitate îşi propune să ţină evidenţa grupurilor de profesionişti relevante pentru industria IT, dar şi un calendar de evenimente şi întâlniri din acest sector. Pentru început prezentăm principalele iniţiative din mediul local, în timp intenţionând să creştem acest index până ce va conţine toate comunităţile locale, dar şi cele naţionale. Criteriul ales pentru ordonare este în funcţie de numărul de membri şi activitatea grupurilor, astfel sperăm să obţinem o ierarhie bazată pe gradul de implicare al organizatorilor şi al membrilor.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

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

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

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

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

Recomandarea TSM

Calendar

August 30 – Septembrie 1

ICCP2012 (8th International Conference on Intelligent Computer Communication and Processing) Contact: http://www.iccp.ro/iccp2012/

Septembrie 5

Microformats Contact: http://www.meetup.com/Cluj-Semantic-WEB/ Romanian Association for Better Software Comunitate dedicata oamenilor cu experienta din IT indiferent de tehnologie sau specializare.

Website: http://www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 159 / Nr. Evenimente: 6 Google Technology User Group Cluj-Napoca Comunitate dedicată tehnologiilor Google.

Website: http://cluj-napoca.gtug.ro/ Data înfiinţării: 10.12.2011 / Nr. Membri: 25 / Nr. Evenimente: 7 Cluj Mobile Developers Comunitate dedicată tehnologiilor mobile.

Website: http://www.meetup.com/Cluj-Mobile-Developers/ Data înfiinţării: 08.05.2011 / Nr. Membri: 39 / Nr. Evenimente: 2

Open Coffee Club

Contact: https://www.facebook.com/opencoffeecluj Un club care se adresează antreprenorilor și acelora care vor să învețe din experiențelor unor persoane de succes.

Recomandăm acest grup pentru atmosfera informală, networking-ul de la finalul evenimentelor și calitatea invitaților. www.todaysoftmag.ro | nr. 4/2012

9

programare

Analiza mecanismului Object– Relational Mapping (ORM) cu exemplificări Hibernate

Anghel Contiu

anghel.contiu@threepillarglobal.com Senior software developer, Three Pillar Global

10

nr. 4/2012 | www.todaysoftmag.ro

Object / Relational Mapping (ORM) este o tehnică de programare ce face posibilă accesarea și manipularea obiectelor fără ca programatorii să fie interesați de sursa de date de unde provin aceste obiecte. Această tehnică a apărut din nevoia de a depăși diferențele de paradigmă dintre modelul orientat pe obiecte (susținut de limbajele de programare de nivel înalt actuale) și modelul relațional (utilizat de cele mai populare sisteme de gestiune a bazelor de date).

Limbajele de programare orientate pe obiecte reprezintă datele într-un graf interconectat de obiecte, pe când bazele de date relaționale folosesc un mod tabelar de reprezentare. Efortul de a conecta atributele claselor definite prin intermediul unui limbaj orientat pe obiecte cu câmpurile tabelelor din baza de date nu poate fi ignorat, iar scopul unui ORM este acela de a crea o relație naturală, transparentă, fiabilă și de durată între cele două modele.

Această nepotrivire de paradigmă pare să nu își fi găsit încă o soluționare definitivă care să fie aprobată de toți actorii din industria IT, însă opinia generală este aceea că framework-urile ORM reprezintă un important pas înainte.

Procesul automat de stocare a obiectelor într-o bază de date relațională folosind un framework ORM, constă în maparea obiectelor la tabelele corespunzătoare, asocierea dintre ele fiind descrisa folosind metadata. Un framework ORM complet include următoarele funcționalități: • un API pentru operațiile CRUD (create, read, update, delete) aferente claselor persistente; • un limbaj pentru specificarea interogărilor adresând clasele persistente și atributele acestora; • un mod care sa faciliteze definirea metadata pentru mapările dintre obiect și tabela; • o abordare consistentă a tranzacțiilor, a metodelor de stocare a datelor („caching”) și a asocierilor dintre clase;

•

tehnici de optimizare în funcție de natura aplicației.

Acest articol propune o discuție de ansamblu asupra deciziei de utilizare a framework-urilor ORM prin descrierea câtorva dintre cele mai importante provocări și prin menționarea argumentelor pro și contra în aceste cazuri. Pentru exemplificări sunt folosite limbajul Java și framework-ul ORM Hibernate, acesta beneficiind de o popularitate ridicata în rândul programatorilor. Componentele implicate în mecanismul de ORM sunt prezentate în Figura 1.

Provocări ale ORM Concurenţă și tranzacții

Într-un mediu concurențial partajarea resurselor devine extrem de importanta și problema menținerii integrității datelor tinde sa devină complexă. Din acest motiv modul în care această partajare se implementează trebuie să fie cât mai simplu, să corespundă specificațiilor proiectului și să asigure integritatea datelor. În continuare vor fi descrise câteva dintre tehnicile de manipulare a datelor care trebuie folosite la un moment dat de programatori și care implică o atenție deosebită în ceea ce privește partajarea resurselor.

Figura 1. Componentele implicate în mecanismul ORM. Cele două entități sunt persistate în tabelele corespunzătoare prin intermediul framework-ului ORM.

TODAY SOFTWARE MAGAZINE

Blocarea optimistă a resurselor într-un mediu concurențial (“optimistic concurrency”)

Blocarea resurselor este folosită pentru ca datele să nu fie alterate între momentul citirii și cel al folosirii. Varianta optimistă a acestei blocări se bazează pe presupunerea conform căreia mai multe tranzacții pot fi executate simultan fără ca una dintre ele să altereze datele alteia, în timp ce varianta pesimistă presupune blocarea unor resurse pe termen mai lung. Figura 2 descrie blocarea optimistă în varianta ei fundamentală. Într-o aplicație pentru care scalabilitatea și concurența reprezintă cerinţe non-funcționale importante se pune problema implementării concurenței cu “optimistic control”, deoarece aceasta funcționează bine pentru scenarii cu citiri multiple și modificări rare.

Din acest punct de vedere, într-o implementare care folosește JDBC API pur, fără ORM, responsabilitatea verificării integrității obiectelor încărcate și care urmează a fi manipulate revine programatorului. În acest sens trebuie o verificare a versiunii obiectelor care poate fi făcută manual, însă doar în cazul scenariilor simpliste. Pentru scenariile complexe această sarcină devine dificilă întrucât se ajunge la grafuri de obiecte greu de urmărit și controlat. În aceasta situație sunt dificil de implementat manual șabloane de tranzacții precum: • sesiune per conversație(„sessionper-conversation”); • sesiune per cerere („session -per-request”); • sesiune per cerere cu obiecte detașate („session-per-request-with-detached-objects”).

Pe de altă parte, folosirea unui ORM simplifică această sarcină. Spre exemplu, implementarea de Hibernate oferă implicit verificarea automată a versionării atât pentru sesiuni extinse cât și pentru instanțe detașate. Hibernate abordează problema concurenței cu optimistic control folosind versionare automată, obiecte detașate

și sesiuni extinse. Vom detalia în cele ce urmează fiecare dintre mecanisme.

Versionare automată. Versionarea implementată de Hibernate folosește un număr de versiune sub forma unui întreg sau al unui timestamp pentru a detecta conflictele de actualizare ale obiectului și pentru a evita pierderea de date. O proprietate a obiectului este marcată ca și proprietate de versionare, iar valoarea ei este incrementată de câte ori se observă că obiectul are o valoare modificată (“dirty”).

Obiecte detașate. În cazul obiectelor detașate (obiecte neatașate unei sesiuni) acestea devin atașate diferitelor sesiuni, și la fel ca și în cazul sesiunilor extinse, versiunea lor este verificată la momentul sincronizării stării obiectelor persistente din memorie cu starea din bază de date („flush”), urmând a fi aruncată o excepție în cazul în care este detectată o modificare concurentă.

Sesiuni extinse. În cazul sesiunilor extinse, Hibernate verifică versiunea obiectelor la momentul sincronizării stărilor obiectelor, lansând o excepție dacă este detectată o modificare concurentă.

Performanţa Interogările

Unul dintre cele mai puternice argumente în defavoarea ORM-urilor este cel conform căruia interogările SQL generate de instrumentele de mapare au o eficiență redusă în multe dintre cazuri în comparație cu interogările SQL scrise manual.

Din punct de vedere al performanței interogărilor, la o analiză mai generală care nu se concentrează strict pe interogări, se poate observa că numărul punctelor critice nu sunt atât de multe încât să influențeze performanța generală a aplicației. În punctele cheie se poate interveni ulterior cu un cod mai eficient (eventual manual), dar cu atenție la partea de mentenanță. Separarea logicii de aducere a datelor aduce un avantaj în cazul în care trebuie efectuate schimbări, numărul acestora devenind mai redus datorită duplicării reduse a codului.

Pe parcursul dezvoltării aplicației se poate evita optimizarea prematură a i n t e r o g ă r i l o r.

Utilizarea unui framework ORM duce la Figura 2. Blocarea optimistă a resurselor scrierea mai rapida a

codului, o lizibilitate mai bună, iar duplicările de cod sunt mai ușor de evitat. Odată cu creșterea numărului de interogări se poate folosi un instrument de verificare a vitezei de execuție pentru a identifica punctele sensibile ale performanței și la diferite intervale de timp se poate interveni manual acolo unde e nevoie. De asemenea, printre cele mai la îndemână acțiuni care pot fi luate pentru optimizarea performanței e folosirea stocării în memorie a datelor și indexarea bazei de date. Este de așteptat ca performanța să fie acceptabilă, iar beneficiile folosirii unui mecanism ORM să depășească problemele de performanță.

Maparea entităților

Performanța unui mecanism ORM și productivitatea programatorului depind mult de o bună mapare a entităților la tabelele bazei de date. Printre riscurile unei mapări greșite se numără: • g e n e r a r e a i n t e r o g ă r i l o r neperformante; • supraîncărcarea memoriei cu obiecte care nu sunt necesare în urma execuţiei interogărilor; • productivitate sub așteptări a programatorului din pricina scenariilor complexe determinate de mapări.

Folosirea eficientă a unei implementări ORM presupune o cunoaștere minimă a modului în care implementarea respectivă funcționează „în interior” pentru a evita riscurile descrise mai sus. Un scenariu obișnuit cu risc ridicat constă din însumarea următoarelor condiții: • cuplare strânsă între entități și existența atributelor de tip colecție de entități; • relații de 1-n, m-n sau n-1 între entități; • cascadare pe mai mult de un nivel; • lipsa unei optimizări din punct de vedere a obținerii datelor („fetching”).

Odată ajuns într-un astfel de scenariu și în situația de a repara o problemă, șansele de apariţie a unor efecte secundare în alte părţi ale proiectului cresc. Testele ajută programatorul să observe dacă soluția găsită creează o problemă într-o alta zona a aplicației, însă provocarea consta în a găsi soluția care face faţă tuturor îngrădirilor datorate mapărilor și nu strică o altă parte din proiect, ceea ce este dificil.

De aceea, în procesul de stabilire a entităților care urmează să fie mapate programatorul trebuie sa fie concentrat pe www.todaysoftmag.ro | nr. 4/2012

11

programare

principiul de a menține maparea simplă.

Mapările simple și relațiile cat mai simple între entități duc la o întreţinere mai ușoară pe parcurs datorită constrângerilor mai relaxate.

Stocarea datelor în memorie

Stocarea datelor în memorie („caching”) reprezintă o modalitate de creștere a performanței aplicației, principalul său obiectiv fiind de a stoca anumite date în memorie, evitând astfel interogările pe baza de date pentru datele respective.

Stocarea datelor în memorie folosind JDBC API

API-ul de JDBC („Java Database Connectivity”) oferă acces universal la date din limbajul Java și este compus din doua pachete: java.sql și javax.sql. Soluțiile existente pentru stocarea datelor folosind JDBC API sunt restrânse, se poate aminti interfața javax.sql.rowset.CachedRowSet reprezentând un container de înregistrări pe care și le stochează în memorie. Se constituie totodată o componentă JavaBeans ce dispune de scrolling și posibilități de actualizare și serializare. Implementarea de bază acceptă preluarea de date dintr-un set de rezulte, dar poate fi extinsă pentru a obține date și din alte surse tabulare. Cu un astfel de obiect se poate lucra în modul deconectat de baza de date, fiind nevoie de o conexiune doar atunci când datele trebuie sincronizate.

• Pe baza JDBC API s-au dezvoltat și alte biblioteci care oferă mai multe soluții de stocare a datelor în memorie, astfel de exemple fiind: • Extensia Oracle pentru JDBC – oferă o interfața și implementare pentru statement cache (stocarea statementurilor care sunt folosite în mod repetat) • Implementarea PostgreSQL pentru JDBC – oferă un wrapper de stocare a statement-urilor peste implementarea de baza a JDBC-ului.

Există și alte soluții de stocare în memorie oferite de părți terțe care pot fi integrate într-o aplicație care folosește direct JDBC API. Astfel de exemple sunt: • Commons JCS • Ehcache

Stocarea datelor în memorie folosind ORM

Din punct de vedere al framework-urilor

12

nr. 4/2012 | www.todaysoftmag.ro

Analiza mecanismului Object–Relational Mapping (ORM) cu exemplificari Hibernate

ORM, acestea completează discuția despre “a nu discuta cu baza de date” cu subiectul “a nu discuta cu API-ul JDBC” în cazul Java, în sensul de a face transparentă programatorului relația cu API-ul JDBC, și de a manipula obiectele stocate în memorie doar la nivelul ORM-ului și al implementărilor sale pentru astfel de stocări.

Hibernate oferă un prim nivel de stocare („first-level cache”) care e asociat cu sesiunea și e folosit implicit; mai oferă un al doilea nivel („second-level cache)” care e asociat cu fabrica de sesiuni și e opțional (Figura 3).

Primul nivel de stocare e folosit pentru a reduce numărul interogărilor pe baza de date la nivelul unei sesiuni. Datele nu pot fi stocate în memorie și folosite de alte sesiuni în afara celeia care a adus datele inițial.

Cel de-al doilea nivel de stocare este localizat la nivelul fabricii de sesiuni și este capabil de a depozita date din diferite sesiuni. Acest lucru înseamnă că toate obiectele de sesiune pot accesa aceleași date stocate.

Hibernate suportă patru implementări „open source” pentru folosirea nivelului 2 de stocare. Acestea sunt: • Ehcache • OSCache • JBoss TreeCache • Swarm Cache Prin faptul că primul nivel de cache e folosit în mod implicit, Hibernate aduce deja un plus important în ceea ce privește performanța din punct de vedere al comunicării cu baza de date față de folosirea API-ul de JDBC. De asemenea, cel de-al doilea nivel de stocare, folosit în general pentru optimizarea aplicațiilor relativ bune din punct de vedere al performantei, duce la o creștere importantă a acesteia, iar programatorul are flexibilitatea de a alege implementarea care se potrivește cel mai bine contextului dat.

Folosirea extensivă a reflexiei

Un alt argument care care este vehiculat în defavoarea framework-urilor ORM este cel conform căruia folosirea reflexiei („reflection”) în mod intensiv cauzează probleme de performanță. Într-adevăr, conform documentației Oracle anumite operațiuni de optimizare făcute de mașina virtuală nu pot fii efectuate deoarece reflecția implică tipuri rezolvate dinamic, astfel viteza operațiilor efectuate în acest mod este mai redusă, iar recomandarea este de a le evita dacă sunt repetitive în cadrul aplicațiilor sensibile din punct de vedere al performanței.

Problema care se pune este în ce măsură aceasta încetinește aplicația și cât de avantajos este compromisul între viteza și flexibilitatea oferită de accesul obiectelor în acest mod. Având în vedere pe de-o parte timpii de execuție ai operațiilor prin reflexie, iar pe de altă parte faptul că majoritatea problemelor legate de performanța în ceea ce privește comunicarea cu baza de date se datorează în mare parte unor deficiențe de arhitectură a acesteia sau a modului greșit de a o interoga, operațiile prin reflexie nu contribuie în mod semnificativ la reducerea performanței. Se poate lua însă în calcul o decizie de optimizare pentru aplicațiile cu o performanță bună, unde în urma testelor se observă că timpii pentru aceste apeluri reprezintă un procent important din timpul necesar comunicării cu baza de date.

Operațiile prin reflexie tind să devină tot mai eficiente fiind susținute și de dezvoltarea instrumentelor de manipulare de bytecode precum Java Assist sau ASM. Un semnal important în acesta direcție îl constituie adoptarea bibliotecii Java Assist de către Hibernate pentru eficientizarea acestui tip de operații și folosirea bibliotecii ASM de instrumente precum Oracle TopLink, Apache OpenEJB, AspectJ și multe altele, atât pentru eficientizarea operațiilor de reflexie cat și a programării orientată pe aspecte.

Mentenanța

Figura 3. Nivelele unu și doi de stocare a datelor oferit de Hibernate.

Întreţinerea softului reprezintă un capitol extrem de important indiferent care dintre soluții ar fi aleasă și constituie unul dintre subiectele principale discutate atunci când trebuie făcută o alegere între a folosi un ORM sau nu. O interogare SQL eficientă aduce performanță, însă trebuie observat compromisul făcut din punct de vedere al mentenanței. În general, programatorii

TODAY SOFTWARE MAGAZINE

sunt relativ familiari cu limbajul SQL și cu bazele de date relaționale, astfel încât primul gând e să meargă direct pe această direcție.

Utilizarea interogărilor SQL pentru comunicarea cu baza de date rezultă întro cantitate foarte mare de cod folosit doar pentru operații de tip CRUD, necesitând mult timp pentru a fi scris, iar modificările claselor de model îl afectează direct, ducând la o mentenanță dificilă.

JDBC API și SQL oferă o abordare de tip comandă pentru a manipula datele în baza de date. Astfel, tablele și coloanele implicate într-o manipulare de date trebuie specificate de mai multe ori (insert, select, update), ducând la o scădere a flexibilității, la o cantitate mai mare de cod și la o creștere a timpului de implementare. De asemenea, scrierea manuală a codului SQL induce o dependență serioasă între structura tabelelor și codul respectiv. Orice schimbare într-una dintre parți are consecințe imediate în cealaltă parte, ducând în final la o mentenanță dificilă a aplicației și compromisuri lipsite de eleganța în ceea ce privește codul.

Integrarea instrumentelor ORM cu modul de programare orientat pe obiecte duce la dezvoltarea unui design general în cadrul căruia codul de acces al datelor are locul lui, alcătuind adesea o componentă separată. Aceasta duce la evitarea codului duplicat, crește potențialul de reutilizare, iar programatorul are posibilitatea de a interacționa cu un graf de obiecte, de a folosi moștenirea, polimorfismul, șabloane de design și alte practici eficiente corespuzătoare programării orientate pe obiecte.

Pentru aplicații mici, în care domeniul de business este unul simplu, s-ar putea ca modul de interogare mai apropiat de baza de date să fie mai eficient, în sensul de a folosi JDBC API și de a renunța la efortul de a folosi un ORM. Pentru o aplicație mică mentenanța e mai simplă iar cantitatea de cod e de așteptat să fie redusă.

Concluzii

Folosirea unui framework ORM și alegerea lui sunt decizii care trebuie luate în cunoștință de cauză și care depind de specificul proiectului. Tabelul următor descrie pe scurt avantajele și dezavantajele folosirii unui astfel de framework.

Dificultatea inițială în dezvoltarea unui cod bazat pe un framework ORM constă în curba de învățare a frameworkului respectiv, urmată fiind de dificultatea mapării datelor la coloanele tabelelor, o operație care trebuie făcută manual ținând cont și de modul în care aceste relații vor defini în final structura tabelelor și a coloanelor. Curba de învățare ar trebui (cel puțin teoretic) să fie răsplătită pe termen lung, mai ales în cazul proiectelor medii și mari. Odată înțeles mecanismul ORM,

timpul de dezvoltare ar urma să scadă ducând la o productivitate îmbunătățită a programatorului.

Pentru a folosi eficient un framework ORM nu ajunge experiența dobândită într-un limbaj de programare orientat pe obiecte; e necesară cunoașterea modelului relațional și a limbajului SQL. Framework-urile ORM permit evitarea scrierii de cod repetitiv și creșterea productivității, însă doar prin cunoașterea detaliată a framework-ului folosit el poate fi întrebuințat în mod optim, iar cunoașterea limbajului SQL ajută programatorul în cazul problemelor importante de performanță. Scopul final este acela de a avea productivitate și performanță în managementul datelor persistente.

www.todaysoftmag.ro | nr. 4/2012

13

programare

SEO QA adaptabilitatea la schimbarile algoritmilor de căutare Google

În ultimii ani, Google a venit cu o mulţime de modificări asupra algoritmilor de căutare. În 2012 au fost cel puţin două modificări în fiecare lună, lucru care a afectat în mod negativ traficul multor site-uri. Controversatele update-uri Pinguin şi Panda au scos din rezultatele căutarilor şi site-urile cu un conţinut bun şi util. Astăzi SEO nu se mai bazează doar pe optimizarea conţinutului şi pe link-uri externe ci şi pe alţi factori, mai deosebiţi, precum user experience sau prezenţa pe site-urile sociale. Pentru a ţine pasul cu schimbările Google şi pentru a nu fi penalizaţi, trebuie să fim mereu la curent. Haideţi să vedem, în continuare, cele mai importante schimbări ale algoritmilor din punct de vedere al SEO. Radu Popescu

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

În primul rând ar trebui să înţelegem de ce ne raportăm la Google atunci când vorbim despre căutare şi optimizare SEO, fără a mai aduce măcar în discuţie binecunoscuţii competitori Yahoo şi Bing. În perioada ianuarie - iunie 2012, Google a avut în România o cotă de piaţă de peste 98% (conform datelor furnizate de StatCounter.com). Dacă mai avem în vedere faptul că, în ultimii patru ani, cota de piaţă a Google nu a scăzut sub 91%, întelegem că trebuie să ne orientăm toate eforturile doar spre acest motor de căutare.

Actualizarea Panda şi Inteligenţa Artificială

Încă de la începutul anului 2011, prin introducerea update-ului Panda, bazat pe un avansat algoritm <machine-learning>, Google a început să clasifice site-urile web în baza unor factori mai deosebiţi precum design şi user-experience, procentul de conţinut din zona above the fold, încrederea pe care o prezintă situl sau dacă s-au creat multe discuţii în jurul său pe platformele sociale. Realizarea acestor algoritmi a fost posibilă şi datorită celebrilor “human raters”, plătiţi de către Google, care vizitau

14

nr. 4/2012 | www.todaysoftmag.ro

sute de site-uri zilnic şi le catalogau în funcţie de factorii menţionaţi mai înainte. Prin această metodă, inginerii puteau vedea dacă algoritmii lor funcţionează corect.

Toate aceste modificări au retrogradat chiar si site-urile vechi, cu un conţinut bun şi util, care erau în topul căutărilor, dar care nu ofereau şi o experienţă plăcută în navigare. Update-ul afectează şi site-urile care au doar câteva pagini ce nu respectă noile cerinţe, astfel încât un site foarte bun poate fi scos din rezultatele Google pentru câteva pagini cu design şi conţinut mediocru. În aceste cazuri, o bună soluţie este blocarea paginilor care nu inspiră încredere şi calitate, folosind fişierul Robots. Vechea zicală “Content is king” nu mai are aceeaşi valoare. Există foarte mult conţinut unic şi bun în acest moment, dar simplul fapt că un site are conţinut unic şi optimizat, în care foloseşte un cuvânt cheie de câteva ori printre care şi în titlu, nu mai e de ajuns.

Conţinut bun înseamnă un conţinut care să fie plăcut de utilizatorii sitului, care să fie împărtăşit pe reţelele sociale sau să fie citat în alte site-uri. Blocurile plictisitoare de text, reclamele sau împărţirea conţinutului pe mai multe pagini afectează în mod

TODAY SOFTWARE MAGAZINE

negativ poziţionarea în SERPS. Recomandările mele, pentru a face faţă acestei actualizări sunt : • Paginile care au un conţinut de slabă calitate trebuie scoase din site. O bună metodă pentru a face acest lucru este folosirea meta-tagului robots pentru blocarea lor; • Apariţia paginilor pe site-urile sociale arată faptul că ele au un conţinut interesant, pe care vizitatorii doresc să îl împărtăşească prietenilor; • Menţinerea bounce-rateului în limitele optime (35-65%), prin creare de linkuri interne şi fidelizarea vizitatorilor; • Îmbunătăţirea user-experience este un factor important. Navigarea uşoară prin site, numărul scăzut de reclame, viteza de încărcare a paginii sau designul influențează poziţia în SERPS.

Prospeţimea contează si ea

Update-ul “Frehsness”, introdus în noiembrie 2011, care a avut un impact destul de mare asupra rezultatelor în căutările Google, afectând aproximativ 35% din căutari, indică oarecum direcţia spre care trebuie să meargă site-urile pentru a se menţine în top, şi anume conţinutul proaspăt. În acest moment, blogurile reprezintă cea mai proaspătă sursă de conţinut.

Orice prezenţă online trebuie să conţină şi un blog. Să luăm, spre exemplu, cazul site-urilor companiilor unde este aproape imposibilă adăugarea, în mod regulat, a unui conţinut proaspăt. În acest caz blogul vine şi rezolvă respectiva problemă.

Persoane din interiorul companiei pot scrie articole săptămânale despre diferite tehnologii folosite, noutăţi din domeniul de activitate al firmei sau simple postări informative.

Bineînţeles că nu este nevoie mereu de rezultate cât mai proaspete. În cazul în care căutăm un tutorial despre folosirea corectă a proprietăţii CSS “float”, nu avem nevoie de cel mai nou tutorial. Îmbunătăţirile ulterioare ale acestui algoritm ştiu să facă diferenţa dintre diferite tipuri de căutare şi nivelul de prospeţime a rezultatelor. În dezvoltarea acestui algoritm, Google a luat în considerare şi situaţiile în care unele persoane vor încerca să profite de pe urma acelui algoritm, schimbând doar câteva caractere sau propoziţii pe o pagină. Aceste pagini nu vor fi considerate proaspete, pentru că inginerii celebrului motor

de căutare verifică noutatea conţinutului în raport cu prima indexare a paginii respective. În continuare, am selectat câteva metode prin care putem folosi această actualizare în ajutorul nostru: • Blogul de companie sau de produs, ajută la crearea de conţinut proaspăt în mod regulat; • Comunicatele de presă publicate întro secţiune a sitului, generează şi ele conţinut proaspăt; • Prezenţa unei paginii pe mai multe site-uri sociale într-o perioadă scurtă de timp semnifică pentru Google conţinut proaspăt;

Actualizarea Pinguin şi spam-ul

Update-ul Panda are ca scop principal retrogradarea site-urilor care nu respectă termenii şi condiţiile impuse de Google referitoare la black-hat SEO. Acest update penalizează pe oricine foloseşte conţinut duplicitar, ferme de link-uri, cloaking sau keyword stuffing. De asemenea, Google retrogradează şi site-urile care folosesc tehnici white-hat SEO în mod excesiv.

Practic orice lucru care nu pare natural, bazat pe acţiunea utilizatorilor, va fi penalizat. O nişă foarte importantă afectată de acest update este cea a site-urilor care folosesc marketingul afiliat. Prezentarea unor produse pe mai multe site-uri, folosind aceleaşi imagini sau descrieri, fără a crea plus valoare a fost penalizată drastic. Foarte multe magazine online care foloseau informaţiile producătorilor au fost nevoite să îşi schimbe întregul mod de prezentare a produselor, introducând review-uri interne, fotografii proprii sau conţinut generat de utilizatori.

Printre cele mai celebre cazuri de revenire după penalizările generate de update-ul Pinguin, a fost cazul WPMU.org, unul dintre cele mai bune site-uri care oferă resurse, ştiri şi informaţii din jurul platformei Wordpress. Acesta a înregistrat, în doar cateva zile o scădere a traficului venit din rezultatele Google de peste 80%, având un

impact devastator asupra veniturilor.

Problema principală în acest caz a fost calitatea slabă a linku-rilor externe, care proveneau din două mari surse.

WPMU.com deţine şi serviciul de blogging EDUblogs.org, care permite oricărei persoane din aria educaţională să îşi creeze un blog gratuit (în acelaşi fel ca Blogspot). În subsolul tuturor paginilor acestor bloguri exista un link către domeniul WPMU. com. Având în vedere că numărul acestor link-uri era de peste 500.000, ei aveau o jumătate de milion de link-uri (artificiale) către adresa WPMU.com. Pe lângă aceasta, fiind un hub de resurse, WPMU.com oferea spre descărcare şi teme Wordpress. În acel moment, toate acele teme conţineau, tot în footer, un link spre pagina de unde au fost downloadate. Acest lucru a dus la crearea a peste 21.000 de link-uri provenind de la tot atâtea domenii, de această dată independente. Problema cea mai mare a fost că majoritatea respectivelor domenii aveau un conţinut de slabă calitate sau făceau spam, factor care şi el a contribuit la penalizare.

Noii algoritmii Google au considerat toate aceste link-uri ca fiind de slabă calitate şi WPMU.com a fost drastic penalizat.

După o scurtă documentare, deţinătorii sitului au trecut la scoaterea tuturor linkurilor artificiale, ceea ce a însemnat renunţarea la aproximativ 30% din linkurile externe, precum şi un mic SEO update intern, iar problema a fost rezolvată.

Pentru a face faţă actualizarii Pinguin, trebuie să avem în vedere urmatoarele aspecte: • Calitatea link-urilor de provenienţă externă este foarte importantă, în sensul în care link-urile de proastă calitate pot să te afecteze; • Atenţie la optimizarea excesivă.

Conţinutul sitului trebuie creat pentru vizitatori, nu pentru motoarele de căutare, prin urmare, densitatea cuvintelor cheie trebuie să fie sub 4%; • Conţinutul duplicitar este penalizat drastic. În cazul site-urilor de comerţ

Figura 1. Evoluţia WPMU.com înainte şi după update-ul Panda (sursa : webpronews.com). www.todaysoftmag.ro | nr. 4/2012

15

programare

online, prezenţa descrierilor proprii, precum şi a imaginilor originale este foarte importantă; Link-urile externe trebuie să pară naturale. Ancora din interiorul linkului trebuie să fie diferită. A avea 100 de link-uri cu aceaşi ancoră, către site-ul tău, îţi poate aduce o penalizare, chiar dacă aceste linkuri sunt de calitate.

La ce să ne aşteptăm?

Prin toate aceste schimbări, Google încearcă să schimbe modul de căutare pentru todeauna. Calitatea este cuvântul cheie al noilor actualizări, iar prin calitate nu ne referim doar la conţinut, ci şi la calitatea designului sau a link-urilor externe.

Reţelele sociale joacă un rol tot mai important în SEO, iar Google+ va fi în centrul acestor schimbări, după cum arată tendinţele. Cert este faptul că din punct de vedere al SEO trebuie să fim mereu la curent şi să updatăm acţiunile, iar optimizarea pentru motoarele de căutare este o muncă full time. De asemenea, jobul de consultant SEO se transformă încet într-unul de web strategist, avându-se în vedere faptul că orice acţiune de pe Internet poate afecta ranking-ul în SERPS.

16

nr. 4/2012 | www.todaysoftmag.ro

SEO QA adaptabilitatea la schimbarile algoritmilor de cautare Google

management

TODAY SOFTWARE MAGAZINE

Metoda de estimare Function Point în practică

Ca urmare a publicării unui articol pe această temă într-un număr precedent am dat curs invitaţiei de a explora mai in detaliu practica FPA. Scopul articolului precedent a fost expunerea în linii mari a aplicabilității metodei FPA (Analiza punctelor funcţionale) și explicarea terminologiei de bază. În acest articol, mă voi axa mai mult pe cum se aplică metoda concret.

Ionel Mihali

Ionel.Mihali@isdc.eu QA Officer, implicat in sistemul de asigurare al calitatii la nivel de proiect si organizatie, cu peste 6 ani de experienta in domeniul informational.

Am decis că, pentru o mai bună înţelegere, voi lua o aplicaţie deja construită - nu o să merg pe o estimare bazată pe cerinţe funcţionale - pe care voi aplica metoda detaliată de măsurare.

Am vrut să număr pentru acest articol o aplicaţie care are o funcţionalitate mai mult sau mai puţin standard, pentru a mă putea axa pe explicarea măsurătorii şi nu a funcţionalităţii; am avut nevoie de o aplicaţie care nu impune constrângeri de confidenţialitate în condiţiile în care trebuie să analizăm şi structura bazei de date. Ca urmare, am descărcat de pe siteul http://www.comersus.com/ o aplicaţie care funcţionează pe principiul coşului de cumpărături. În capitolele care urmează se vor parcurge paşii principali în execuţia unei măsurători.

Vor fi utilizați termenii: FTR – Tip fişier referenţiat (File type referenced) RET – Tip înregistrare elemente (Record element type) DET – Tip element de date (Data element type) EI – Intrare externă (External Input) EO – Ieşire externă (External output) EQ – Interogare externă (External

Inquiry) ILF – Fişier logic intern (Internal Logical File) Dacă se întâmpină dificultăţi în a înţelege termenii, articolul «Metoda de estimare Function Point » din numărul precedent al revistei este un ghid bun în acest sens: http:// www.todaysoftmag.com/article/ro/3/ Metoda_de_estimare_Function_Point_22.

Colectarea documentaţiei. După cum am menţionat mai sus, pentru a executa numărătoarea se va folosi aplicaţia în sine iar în capitolele următoare vor fi câteva imagini pentru fiecare funcţionalitate.

Determinarea tipului de numărătoare. Se va utiliza numărătoarea detaliată.

Determinarea graniţei. În cazul nostru aplicaţia nu comunică cu alte aplicaţii, deci nu trebuie să ne punem problema dacă avem date care vin din sau se transmit în alte sisteme. În ceea ce priveşte scopul, din motive de timp si spaţiu am decis să număr doar o parte din funcţionalitatea sistemului.

Identificarea funcţiilor de date

În Figura 1 avem o serie de tabele pe care le-am grupat într-o serie de funcţii de date: ILF_Produse: Este un fişier logic www.todaysoftmag.ro | nr. 4/2012

17

management

Metoda de estimare Function Point în practică

Avem două EI cu câte două elemente.

Figura 5 arată implementarea funcţionalităţii de adăugare a unui produs în tabela “products”. Avem un EI cu 18 elemente.

Figura 6 arată implementarea funcţio-

Figura 1. Identificarea funcţiilor de date intern pentru că este în interiorul graniţei aplicaţiei numărate şi mentenanţa tabelelor se face de către aplicaţia numărată.

Acest fişier conţine tabelele: “categories”, “products”, “relatedproducts”, “cartrows”, “cartrowsoptions” . Le-am grupat aşa pentru că există dependenţe între ele, de exemplu, un produs face parte dintro anumită categorie.

ILF_Mesaje, ILF_Setări: Sunt două fişiere de date cu câte o tabelă fiecare.

Entităţi de legătură: Nu se numără tabelele care nu stochează date cu valoare pentru un tilizator. De obicei acestea sunt tabele de legătură iar în terminologia FPA ele se numesc “key-key entities” deci ele sunt excluse din scopul măsurătorii.

Identificarea funcţiilor de tip utilizator

Aplicaţia are două părţi principale:

una de administrare şi una de navigare / comandare a produselor.

Mai jos, am ales o serie de funcţionalităţi pe care le-am pus în imagini; va fi selectată fiecare imagine explicându-se ce funcţionalitate implementează şi cum se face numărătoarea.

După cum sugerează şi numele, Figura 2, defineşte setările de sistem.

Această funcţionalitate conţine un EI, care este funcţionalitatea de salvare a setărilor în tabela “settings”. Numărul de elemente este 11

18

nr. 4/2012 | www.todaysoftmag.ro

Figura 6. Listă produse nalităţii de listare a produselor care există în tabela “products”. Avem un EO cu cinci elemente: SKU, descriere, număr vizite, pret, imagine.

Determinarea complexităţii şi calcularea numărului de puncte funcţionale.

Figura 3. Mesaj utilizator În Figura 3, utilizatorul primeşte un mesaj legat de statusul acţiunii de salvare.

Acesta este un EQ cu un singur element returnat din tabela “screenmessages”

Figura 4. Mentenanţă categorii Figura 2. Definirea setărilor

Figura 5. Adăugare produse

Figura 4 arată implementarea funcţionalităţii de modificare şi ştergere a unei categorii de produse în tabela: “categories”.

Având funcţiile şi elementele lor determinate mai sus, ne mai rămâne să determinăm complexitatea fiecărei funcţii şi numărul de puncte funcţionale asociate.

Acestea sunt determinate în tabelul din Figura 7. Există o excepţie de la regulă, care zice că pe lânga funcţiile existente se mai numără câte un EQ, EO, EI pentru tabelele de tip FPA. Determinarea complexităţii se face pe baza numărului de DET şi RET pentru funcţiile de date, respectiv numărului de FTR şi DET pentru funcţiile de tip utilizator, acestea fiind specificate în detaliu în articolul din numărul precedent.

Exemplul din acest articol are doar scop informativ. Deoarece această metodă de numărare are o marjă de eroare, ca orice metodă, literatura de specialitate nu

TODAY SOFTWARE MAGAZINE mai mic de 100 puncte funcţionale.

Concluzie

Măsurătoarea de mai sus are ca scop determinarea productivităţii unui sistem deja construit (ore / punct funcţional) care se poate folosi în estimarea unor aplicaţii asemănătoare de dezvoltat în viitor.

Figura 7. Număr puncte funcţionale recomandă aplicarea ei pentru sisteme care pot să aibă un număr

www.todaysoftmag.ro | nr. 4/2012

19

programare

Microsoft SQL Server Optimizarea performanței

De câte ori v-ați pus problema de a îmbunătăți performanța interogărilor voastre pe SQL Server fără să știți de unde să vă apucați? Eu, cel puțin, mi-am suflecat mânecile de câteva ori până am ajuns să înțeleg o funcționalitate specifică SQL Server care îmi rezolvă problema.

Toți știm că în faza de dezvoltare problemele de performanță majore sunt rare, și

Cosmin Cristea cosmin.cristea@endava.com CLD Head of Development Endava

20

nr. 4/2012 | www.todaysoftmag.ro

asta se întâmplă din mai multe motive: date puține, mediul de dezvoltare perfect, scenarii principale de lucru fără variații, etc.

Soluția e bazată pe statisticile făcute de SQL Server. Cu ele puteți să vă dați seama de stresul aplicat serverului, însă necesită un ciclu de rulare a aplicației pe scenarii utilizator și nu cele de dezvoltare. Se pretează la aplicații care rulează într-un mediu de producție sau cât mai aproape de cel real.

Dacă vă întrebați ce înseamnă statisticile, răspunsul dat de wikipedia e: „Statistics is the study of the collection, organization, analysis, and interpretation of data”. Mdah, nici mie nu mi-a plăcut statistica în facultate.

Specific însă pe o bază de date, de la creare se setează o opțiune care întreține statisticile de pe fiecare tabelă. Statisticile sunt folosite pentru a optimiza interogările pe SQL Server și a crea planurile de execuție. SQL Server creează câte o statistică pentru fiecare tabelă și stochează informații despre cum s-a folosit tabela respectivă, proces care se realizează automat prin opțiunile “auto create” și “auto update” pe baza de date.

Cum se folosesc? Se pornește de la un view de sistem, și anume

sys.dm_db_missing_index_group_stats

în care se adună statistici legate de, așa cum îi spune și titlul, indecși lipsă în baza de date. Informația se modifică la fiecare execuție de query, și se șterge când serverul e repornit. Deci atenție la ce date interpretați, fiind informații doar de la ultimul restart. Apoi e nevoie de încă două view-uri pentru a scoate informații relevante: sys.dm_db_missing_index_details și sys.dm_db_missing_index_groups.

O interogare care oferă un set de date pertinent arată astfel: select top 100 priority = s.user_seeks *

s.avg_total_user_cost * s.avg_user_ impact, s.user_seeks, s.avg_total_user_cost, s.avg_user_impact, d.statement, d.equality_columns, d.inequality_columns, d.included_columns from sys.dm_db_missing_index_ group_stats s join sys.dm_db_missing_index_groups g on s.group_handle = g.index_group_handle join sys.dm_db_missing_index_details d on g.index_handle = d.index_handle order by priority desc

Un rezultat din viața reală se poate vedea în Figura 1.

TODAY SOFTWARE MAGAZINE

Figura 1. tabele si coloane anonimizate După cum observați coloana „priority” e calculată având ca scop calcularea impactului total asupra performanței. Dar cel mai bine ar fi să le analizăm pe rând: • Rezultatul 1, sugerează planuri de execuție care iau in considerare coloana StatusID din tabela 1, care participă in condiții de filtrare cu egalitate pe coloană. Având în vedere că sunt ~30k căutari cu condiția respectivă cu un impact mare asupra utilizatorului (78.4%), merită studiată adăugarea indexului pe coloana respectivă.

• Rezultatul 3, sugerează index pe aceeași coloană, precizând execuții care folosesc coloana pentru căutari pe diferențe (>,<, !=). Încă un motiv în plus să luăm în considerare un index pe StatusID.

•

Ultimul rezultat are unele caracteristici interesante. Impactul asupra utilizatorului e 98%. Dacă ar fi să ne uităm mai în detaliu sugestia afirmă că indexul ar trebui aplicat pe 3 coloane, din care una este probabil cheie primară. Sugestia ar fi de fapt un index compus, însă nu săriți în decizie până nu faceți o analiză atentă pe interogarile care cauzează înregistrarea. Și de-aici incepe munca propriu-zisă.

Trebuie analizată fiecare înregistrare în parte. După primele câteva zeci încep să se contureze cele pentru care e nevoie de atenție mărită și cele care nu intră in aria de interes imediat. E nevoie și de cineva care să cunoască bine regulile de business ale aplicației pentru a putea aplica regula 80/20.

Atenție foarte mare la câți indecși folosiți pentru o tabelă, având in vedere de zavant aj ele inde cși lor mu lt ipli.

Statisticile nu sunt destinate unui astfel de proces, însă pot fi folosite ca și informații de intrare. Mai jos prezentăm câteva dezavantaje ale funcționalității oferite: • Destinația principală nu este pentru optimizări.

• Nu poate aduna statistici pentru mai mult de 500 grupuri de indecși lipsă.

• Nu spune care să fie ordinea de indexare.

• Pentru condiții de filtrare inegale rezultatele nu sunt precise.

• Coloanele sugerate pentru incluziune nu sunt returnate consistent. Analize ulterioare sunt necesare.

Concluzie

Folosirea unor astfel de informații în optimizarea indecșilor și a interogărilor e utilă. Însă nu vă apucați să puneți indecși pe tot ce mișcă, acesta nefiind scopul statisticilor. Munca nu vi se simplifică, pentru că tot e nevoie de o analiză ulterioară.

Rămâne la decizia voastră să hotarâți dacă folosiți sau nu informația. De exemplu: un index pe o coloană unde variația datelor e mica nu-și are rostul. Dar știți unde sunt coarnele taurului. Suflecări de mâneci plăcute!

www.todaysoftmag.ro | nr. 4/2012

21

programare

RESTful Web Services folosind Jersey RESTful Web Services sunt servicii web bazate pe metodele HTTP și conceptul de REST. De obicei următoare patru metode HTTP sunt folosite în definirea serviciilor

Tavi Bolog tavi.bolog@nokia.com

Developing lead @Nokia

22

nr. 4/2012 | www.todaysoftmag.ro

RESTful: • POST: upload-ul unei noi resurse (creare sau modificare). Execuții repetate pot avea efecte distincte.

• PUT: crearea unei noi resurse.

Execuții repetate vor avea același efect ca și o singură execuție IDEMPOTENT. • GET: cititrea unei resurse fără a modifica resursa. Operația nu trebuie să fie folosită la creare de resurse.

• DELETE: stergerea unei resurse.

Execuții repetate vor avea același efect ca și o singură execuție IDEMPOTENT. Conceptul de REST a fost introdus pentru prima dată în 2000, de Roy Fielding.

Mai jos sunt câteva aspecte importante legate de REST: • Este un stil architectural simplu bazat pe standarde Web și HTTP (câștigând teren în fața unor model e ca și SOAP) • Este o arhitectură client-server bazată pe folosirea resurselor. Exemplu de resurse: carte, produs, mașină, etc.

• Comparativ cu SOAP, REST nu este foarte strict cu tipurile de date, este mai ușor de citit folosind substantive și verbe și este mai puțin “verbose” • Tratarea erorilor se face conform tratării erorilor în protocolului HTTP. • Este o arhitectură scalabilă datorită separării de responsabilități între client și server. De exemplu, responsabilitatea unui client este să mențină starea unui utilizator, în timp ce serverul nu menține nici o stare, dar este resposabil de managementul datelor. De asemenea între request-uri

serverul nu trebuie să se mențină starea clientului (stateless).

• Clienții pot folosi tehnici de caching pentru creștrea performanței și scalabilității unei soluției.

• Partea de server poate să conțină mai multe nivele, fără ca modificări ale acestora să afecteze în vreun fel clienții. Aceasta abordare ar putea duce la o separare de responsibilități a diferitelor nivele, ca de exemplu: load balancing, securitate, stocarea datelor, caching de resurse.

• Resursele pot avea diferite reprezentări (JSON, XML, definit de user, etc), folosirea lor determinându-se conform protocolului HTTP (de exemplu folosind HTTP Headers) Un serviciu RESTful definește, în mod tipic, URI-ul de bază (de exemplu: http:// myserver.com/myresources), MIMEtypurile pe care le consumă/produce (de exemplu: JSON, XML, definit de user, etc) și operațiile asociate (prezentate anterior).

Java și RESTful Web Services

În Java, suportul pentru servicii RESTful se numește Java API for Restful Web Services (JAX-RS) și este definit de JSR 311. JAX-RS se bazează foarte multe pe annotations după cum se va vedea în exemplul de mai jos. Jersey este o implementare open source a JAX-RS, care are calitate de producție și pe care am folosit-o în proiectele mele. Exemplul de mai jos a fost implementat folosind Jersey. De menționat că JAXB este folosit pentru suportul de JSON și XML al JAX-RS. Alte implementări ar fi: Apache CXF, Restlet,

TODAY SOFTWARE MAGAZINE JBOss RESTEasy.

Implementarea unui client-server folosing Jersey

Să încercăm să construim o mică aplicație folosind Jersey. Aplicația va oferi o interfață pentru managementul unei resurse numite “books”. Totodată voi prezentă o modalitate de a folosi serviciul Web creat, folosind suportul de client oferit to de Jersey.

Partea de server va expune o serie de metode folositoare în a administra resursa “books”: reset, get, list, delete și add.

Partea de client va fi creată sub forma unui JUnit și va expune o serie de metode de test pentru a valida funcționalitatea serviciul Web.

Crearea proiectului

Proiectul a fost implementat folosind SpringSource Tool Suite (incluzând Web Serverul WMware vFabric), openJDK 7 si Maven 3 pe Ubuntu 12. Jersey are nevoie de patru librarii (și dependințele acestora): • jersey-server: conține implementarea de jersey pe partea de server • jersey-json: conține suportul de JAXB pentru Jersey • jersey-servlet: conține suportul pentru containere de tip servlet • jersey-client: conține implementarea de jersey pe partea de client Folosirea Jersey client împreună cu Jersey server nu este o cerință absolută conform definiției Restful WebServices (s-a folosit abordarea aceasta doar pentru a exemplifica mai multe aspecte ale Jersey).

Maven și pom.xml

Maven oferă o modalitate built-in de rezolvare a dependințelor acestor librării deci este recomandată folosirea acestui tool. Pentru detalii, vezi: https://github. com/tavibolog/TodaySoftMag/blob/master/pom.xml .

Web.xml

Orice aplicația care va fi instalată întrun container de tip servlet va avea nevoie de un fisier web.xml de configurare. Aici se va specifica servlet-ul de care Jersey are nevoie pentru a se inițializa și totodată calea spre serviciile Restful oferite, se specifică pachetul Java ca valoare a parametrului com.sun.jersey.config.property. packages:

<servlet> <servlet-name>

Jersey REST Service </servlet-name> <servlet-class> com.sun.jersey.spi.container.servlet.

ServletContainer </servlet-class> <init-param> <param-name> com.sun.jersey.config.property.packages </param-name> <param-value> com.todaysoftmag.examples.rest </param-value> </init-param> <load-on-startup> 1 </load-on-startup> </servlet> <servlet-mapping> <servlet-name>

Jersey REST Service </servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping>

Servlet mapping specifică pattern-ul de URL pe care se va apela servlet-ul Jersey.

Pentru un URL de forma: http://<server>:<ip>/<AppName>/ <JerseyDomain>/<WebService>/<method>

maparea se referă la <JerseyDomain>.

Dacă în URL pattern folosim “/*”, atunci requestul va fi de genul: http://<server>:<ip>/<AppName>/<WebSe rvice>/<method>

Dacă în URL pattern folosim de examplu “/home”, atunci requestul va fi de genul: http://<server>:<ip>/<AppName>/ home/<WebService>/<method>

Definirea clasei domeniu

Clasa domeniu definește structura obiectelor folosite de către serviciile Web. În principiu clasele domeniu sunt POJO. Annotările @XmlRootElement și @ XmlElement sunt necesare pentru ca JAXB să poată fi folosit să mapeze automat date în formate XML sau JSON la POJO și viceversa. Acest support este oferit de către JAX-RS. În cazul în care clasa domain (Book în cazul nostru) definește un constructor, atunci și constructorul default trebuie definit, el fiind folosit de JAXB în procesul de mapare. @XmlRootElement public class Book { @XmlElement(name = „id”) String id; @XmlElement(name = „name”) String name; @XmlElement(name = „author”) String author; … }

Codul complet al clasei domeniu este aici: https://g it hub.com/ tavibolog/TodaySoftMag/blob/master/src/ main/java/com/todaysoftmag/examples/ rest/Book.java.

Implementarea serviciului

După cum am menționat anterior, JAX-RS folosește din plin annotări.

Majoritatea annotărilor se găsesc în

pachetele: javax.ws.rs.* și javax.ws.rs. code.* din dependința jersey-core. Să încercăm să le discutăm pe cele mai importante.

Pentru definirea serviciului este suficient să definim o clasă care se află în pachetul Java definit în web.xml de parametrul com.sun.jersey.config.property.packages. În cazul nostru va fi com. todaysoftmag.examples.rest. package com.todaysoftmag.examples. rest; // importurile sunt omise @Path(„/books”) public class BookService { … }

După cum observați definiția clasei este precedată de o annotare: @Path. Aceasta definește calea spre serviciul Web. Dacă folosim exemplu de mai sus, URL-ul va fi: http://<server>:<ip>/<AppName>/ books/<method>

De asemenea annotarea @Path este folosită și la nivelul metodelor expuse de serviciul Web: @PUT @Path(„/add”) @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public Book add(Book book) { …. }

În acest caz, valoarea definită in annotare se va adăuga ca parte a URL-ul serviciului pentru metoda respectivă. În cazul nostru, pentru a adăuga o “carte”, URL-ul va fi: http://<server>:<ip>/<AppName>/books/ add

Această metodă mai este precedată de o serie de annotări: • @PUT (similară cu @GET, @POST, @DELETE): specifică metoda serviciului (“add”) va răspunde la un request HTTP PUT (sau similar HTTP GET, HTTP POST, HTTP DELETE) • @Consumes: definește ce MIME type poate fi consumat de metoda respectivă. În acest caz, metoda “add” va accepta “application/json”.

Este posibil ca o metodă să accepte mai multe MIME type-uri care pot fi separate prin “,” când sunt declarate în annotare.

• @Produces: definește ce MIME type poate fi produs de metoda respective. În acest caz, metoda “add” va produce “application/json”. Este posibil ca o metodă să producă mai multe MIME type-uri care pot fi separate prin “,” când sunt declarate în annotare.

Există cazuri în care dorim să trimitem parametri ca și parte a URL-ului de request. JAX-RS definește o serie de annotări www.todaysoftmag.ro | nr. 4/2012

23

programare

care pot fi folosite în aceste sens. Cele mai uzuale sunt: • @PathParam: folosită pentru a injecta valori din URL-ul de request în parametri metodei unui s e r v i c iu . În e xe mp lu d e m ai jos, dacă URLul de request este http://<server>:<ip>/<AppName>/ books/delete/1, metoda “delete” a serviciului va primi “1” ca valoare a parametrului String id. Această annotare supportă o annotare aditională: @ DefaultValue(“valoare”) care poate fi folosită ca un place-holder implicit în cazul în care URL-ul de request nu conține patternul respectiv. @DELETE @Path(„/delete/{id}”) public Book delete(@ PathParam(„id”) String id) { … }

•

•

•

24

Restful Web Services folosing Jersey

@POST @Path(„/reset”) public Response reset(@ HeaderParam(„clearOnly”) boolean clearOnly , @ CookieParam(„credentials”) String credentialsȘ) { … }

Codul complet al serviciului “Books” este aici: https://github.com/tavibolog/ TodaySoftMag/blob/master/src/main/ java/com/todaysoftmag/examples/rest/ BookService.java

Implementarea clientului

Există diferite modalități de implementare a unui client rest: folosind pagini HTML, folosing Apache HTTP Client, folosing Jersey Client, etc. in acest articol se va prezenta folosirea clientului Jersey.

Configurarea unui client Jersey se face folosind interfața com.sun.jersey.api. client.config.ClientConfig. Configurarea clientului se referă la nume de proprietăți, funcționalități, etc. care vor putea fi folosite de către clientul Jersey. Jersey oferă o implementare default a interfeței, numită DefaultClientConfig. O inițializare a configurării clientul Jersey este foarte simplă:

@QueryParam: folosită pentru a injecta parametri de request în parametri metodei unui serviciu. În exemplul de mai jos, dacă URLul de request este http://<server>:<ip>/<AppName>/ books/list?s=abc , metoda “list” a serviciului va primi “abc” ca valoare a parametrului String search. În cazul ClientConfig config = new DefaultClient Config(); în care parametrul “s” nu este specificat în request, metoda va primi Pasul următor este crearea clientu“” ca valoare a parmetrului String lui Jersey (clasa com.sun.jersey.api.client. search, datorită folosirii annotării @ Client). Este important de reținut că această DefaultValue. operație este foarte costisitoare și necesită @GET resurse considerabile. De aceea este recom@Path(„/list”) @Produces({MediaType.APPLICATION_ dată refolosirea unui client Jersey.

JSON, MediaType.TEXT_XML}) public Book[] list(@ QueryParam(„s”) @DefaultValue(„”) String search) { … }

@HeaderParam: folosită pentru a injecta parametri din HTTP headerul unui request în parametri unui serviciu. Mai jos este un exemplu de folosire. În cazul în care header-ul nu este trimis, valoarea parametrului se va evalua de la “null” înspre valoarea default a tipul parametrului metodei serviciului (e.g null petru String, 0 pentru int sau false pentru boolean). @CookieParam: folosită pentru a injecta HTTP cookie-urile în parametric unui serviciu. Mai jos este un exemplu de folosire. În cazul în care cookie-ul nu este trimis, valoarea parametrului se va evalua de la “null” înspre valoarea default a tipul parametrului metodei serviciului ca și mai sus. nr. 4/2012 | www.todaysoftmag.ro

Client client = Client.create(config);

l o c a l ho st : 7 0 0 0 / To d ay S of t Mag , adăugarea unui nou path o va transforma în http://localhost:7000/ TodaySoftMag/books. Mai multe apeluri ale metodei path vor contribui la modificarea URI-ului resursei Web. • Metoda “accept” specifică media type-ul acceptat ca răspuns de WebResource. În cazul nostru este “text/html”. Media type-urile accepate ar trebui să fie un subset al media type-urilor produse de serviciu Web și declarate de annotarea @Produces.

• Metoda “get” execută un request HTTP GET și încercă să mapeze resultatul la o instanță a clasei Book.

Mai multe exemple găsiți în unit testul proiectului: https://github.com/tavibolog/TodaySoftMag/blob/master/src/test/ java/com/todaysoftmag/examples/rest/ BookServiceTest.java . Exemplele folosesc metodele WebResource prezentate mai sus, plus următoarele: • Metoda “post” folosită pentru a executa un HTTP POST; • Metoda “header” folosită pentru a adăuga un HTTP header requestului; • Metoda “cookie” folosită pentru a adăuga un cookie requestului; • Metoda “queryParam” folosită pentru a adăuga un query parametru requestului; • Metoda “put” pentru a executa un HTTP PUT; • Metoda “type” folosită pentru a seta content-type-ul requestului; • Metoda “delete” pentru a executa un HTTP delete.

Odată ce avem clientul Jersey va trebui să ne creăm un obiect WebResource (clasa com.sun.jersey.api.client.WebResource).

Acesta ne va permite să executăm În concluzie, consider că folosirea request-uri înspre metodele unui serviciu Jersey ca framework de dezvoltare și testare Web, oferind totodată capabilități de pro- a serviciilor Restful este ușor de aprofuncesare a răspunsurilor. dat, oferind developerilor un set extins WebResource resource = client. de functionalități pentru dezvoltarea resource(UriBuilder.fromUri(“http:// localhost:7000/TodaySoftMag”). aplicațiilor. build());

Odată avut obiectul WebResource Bibliografie putem începe să îl folosim pentru a trimite http://en.wikipedia.org/wiki/ request-uri. Veți identifica în exemplele de Hypertext_Transfer_Protocol mai jos și folosirea patternul-ui Builder http://en.wikipedia.org/wiki/REST folosit pentru crearea request-urilor. http://jcp.org/aboutJava/commuSă luam următorul exemplu de request nityprocess/final/jsr311/index.html și să îl explicăm: http://jersey.java.net/ Book book = resource.path(“/books”). path(“/list”).accept(MediaType.TEXT_ HTML).get(Book.class);

•

Metoda “path” este folosită pentru a adauga un path URI-ului resurse Web. Dacă resursa Web este: http://

programare

TODAY SOFTWARE MAGAZINE

Semantic Web scurtă introducere eb-ul Semantic este o extensie a Web-ului actual ce permite descrierea formală a resurselor existente pe Internet (pagini Web, documente text şi multimedia, baze de date, servicii etc). Dintre avantajele acestuia se impune ca principală identificarea rapidă și precisă a resurselor relevante pentru utilizator precum şi exploatarea automată

Alina Dia Miron, Ph. D. dia.miron@recognos.ro Semantic Web Expert @Recognos Romania

a resurselor de către agenţii inteligenţi.

Ideea de Web Semantic a apărut în urmă cu aproximativ 15 ani şi a fost introdusa de către Tim Berners-Lee, inventatorul Webului . Nevoia din care s-a născut ideea de Web Semantic poate fi explicată foarte uşor printr-un exemplu.

Să presupunem că un utilizator doreşte să afle informaţii despre un agent software, entitate din Inteligenţa Artificială care observă şi acţionează într-o lume definită cu scopul atingerii unui obiectiv.

Prin executarea unei căutări a sintagmei agent software într-unul dintre motoarele de căutare cunoscute (Google, Bing, Ask, Yahoo etc), se returnează documentele în care au fost identificate cuvintele introduse în interogare. Dezavantajul motoarelor de căutare actuale este că funcţionează pe bază de string matching – cu alte cuvinte identifică cuvinte specificate în query într-un corpus de documente ţintă, astfel că sunt returnate documentele în care se găseşte cel puţin unul dintre cele două cuvinte din exemplul nostru.

Totuşi subiectul acestor documente s-ar putea să nu fie cel de interes pentru utilizator. Prin urmare utilizatorul este nevoit să parcurgă şi să sorteze manual rezultatele pentru a extrage doar acele documente care îl interesează. În schimb, un motor de căutare semantic ar lua în considerare întreaga sintagmă, prin urmare conceptul de agent software şi

nu stringul corespondent şi ar returna doar rezultatele care sunt relevate pentru utilizator. Rezultatul unei astfel de interogări semantice ar fi o descriere a conceptului de agent software în termeni de proprietăţi pe care acest concept le are şi eventual o listă de exemple. Putem duce acest raţionament şi mai departe şi să ne imaginăm un motor de căutare semantic care să răspundă la întrebări de genul : Care sunt universităţile din regiune în a căror curiculă sunt incluse cursuri despre agenţi software ?

Arhitectura Web-ului Semantic: Semantic Web Layer Cake

Web-ul Semantic poate fi văzut ca o suită de tehnologii, foarte sugestiv organizate de

Figura 1. Semantic Web Layer Cake T i m www.todaysoftmag.ro | nr. 4/2012

25

programare

Semantic Web scurtă introducere

Berners-Lee într-o piramida cunoscută sub numele de layer cake, ilustrată în Figura 1.

La baza piramidei găsim standardul Unicode folosit în reprezentarea şi manipularea textului în diferite limbi precum şi standardul de construcţie a URI-urilor, util pentru identificarea resursele publicate pe Web (documente multimedia, pagini Web, bloguri etc.). În prezent, standardul de facto pentru descrierea şi transferul de date pe Web este XML, care însa prezintă o serie de limitări. Printre acestea, putem aminti lipsa unei semantici formale a Schemelor XML, care face greoaie cumunicarea între aplicaţii sau servicii care nu partajează aceeaşi schemă sau aceeaşi interpretare a unei scheme. Din dorinţa de a adăuga un anumit nivel de semantică limbajului XML s-a născut limbajul RDF, un limbaj de descriere a resurselor folosind triplete de tipul <Resursa, Proprietate, Valoare>, asambalate în structuri asemănătoare grafurilor.

Pentru a organiza resursele şi proprietăţile într-o ierarhie de tipuri se foloseşte RDF Schema. Limbajul OWL extinde limbajul RDF(S) introducând o serie de constructori mai avansaţi care permit descrieri mai expresive decât cele posibile folosind triplete RDF(S). OWL permite de asemenea definirea de constrângeri asupra proprietăţilor cum ar fi constrângerile de cardinalitate, restricţiile de valori sau impunerea unor caracteristici predefinite pentru proprietăţi (i.e. tranzitivitate,

simetrie etc.). De remarcat este faptul că limbajele RDF(S) şi OWL au la bază teoria logicilor de descriere, ceea ce garantează o interpretare semantică non-ambiguă a declaraţiilor făcute în aceste limbaje. Mai mult, folosind motoarele de inferenţă specifice logicilor de descriere, cunoştinte noi pot fi derivate automat din descrieri RDF(S) sau OWL. Cunoştintele descrise folosind limbajele RDF(S) şi OWL pot fi interogate folosind limbajul standard SPARQL, foarte asemănător cu SQL. Celelalte layere din Figura 1 nu sunt încă complet standardizate. Ele vizează definirea unor limbaje standard de reguli (i.e. RIF, SWRL, SPIN), foarte utile, de exemplu în definirea de relaţii care nu pot fi descrise folosind constructorii disponibili în OWL, definirea unor sisteme de determinare a nivelului de încredere care se poate asocia cu un triplet RDF (i.e. verifică dacă premisele statement-ului vin din surse de încredere şi ce fel de sistem de inferenţe a fost folosit etc.). Layer-ul de criptografie este de asemenea foarte important pentru a verifica provenienţa statement-urilor RDF(S) şi/ sau OWL şi se bazează pe folosirea de semnături digitale.

Reprezentarea şi interogarea datelor în Web-ul Semantic – câteva exemple

În mod tradiţional datele pot fi reprezentate ierarhic într-o structură XML, sau relaţional într-o bază de date. Web-ul

Semantic introduce o nouă organizare a datelor sub forma graf-urilor RDF (Resource Description Framework). RDF este un model simplu de descriere a resurselor de pe Web (documente multimedia, bloguri, pagini Web, servicii Web, baze de date, etc) şi a meta-datelor asociate cu acestea din urmă cum ar fi titlul, autorul, data publicării etc. RDF descrie o resursă prin prisma proprietăţilor pe care aceasta le are. Concret, un exemplu simplu de graf RDF(S) este ilustrat în Figura 2. În cazul în care descrierea folosind RDF(S) nu este suficient de expresivă pentru a modela domenii mai complexe, avem la dispoziţie un limbaj de reprezentare a cunoştinţelor pe bază de ontologii numit OWL (Web Ontology Language). Detalii despre ontologii si limbajul OWL se gasesc în secţiunea Semantic Web (http:// www.w3.org/standards/semanticweb/) de pe pagina oficială W3C, organismul responsabil de specificarea şi standardizarea acestor limbaje.

Un framework util pentru dezvoltarea de aplicaţii semantice este AllegroGraph, care pune la dispoziţie funcţionalităţi de stocare şi management al tripletelor RDF(S) într-o structură numită triplestore. Interogarea datelor din AllegroGraph se face cu SPARQL - limbaj standard definit de W3C - prin intermediul interfeţei grafice AllegroGraph Web View sau programatic prin intermediul unui API pus la dispoziţie de Franz (http://www.franz.

<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xml:base="http://www.example.fake/comp#">

subClassOf ITCompany

range

subClassOf FinancialInstitution

domain providesITSolutions

TBox ABox

Company

type

Recognos

providesITSolutions

type FisherInvestment

<rdfs:Class rdf:ID=“Company" /> <rdfs:Class rdf:ID=“ITCompany"> <rdfs:subClassOf rdf:resource="#Company"/> </rdfs:Class> <rdf:Property rdf:ID=“providesITSolutions"> <rdfs:range rdf:resource=“#ITCompany"/> <rdfs:domain rdf:resource=“#Company"/> </rdf:Property> <FinancialInstitution rdf:about="#FisherInvestment" /> <rdf:Description rdf:ID=“Recognos"> <providesITSolutions rdf:resource="#FisherInvestment"/> </rdf:Description> </rdf:RDF> 0

RDF/XML

Figura 2. Examplu de graf RDF(S) simplu ce descrie două tipuri de companii între care pot exista relaţii de tipul furnizare de servicii IT. Graful este descris folosind sintaxa grafică (informală) şi sintaxa RDF/XML.

26

nr. 4/2012 | www.todaysoftmag.ro

HR

hub-uri principale se afla DBpedia (baza de date semantice din spatele Wikipediei), GeoNames (o ontologie care descrie locaiile geografice), Freebase etc. Multe dintre aceste date sunt publice şi pot fi foarte uşor exploatate pentru construirea de noi aplicaţii şi servicii.

com/agraph/downloads/). Interogările efectuate cu SPARQL sunt similare interogărilor SQL iar rezultatele obţinute sunt nişte sub-grafuri RDF(S) ale grafurilor ţintă. De obicei, informaţiile extrase sunt prezentate sub forma tabelară.

Un exemplu simplu, este query-ul « găseşte toti artiştii născuţi în Austria în secolul al XIX-lea », care se transpune întro interogare SPARQL astfel: SELECT * WHERE { ?person a <http://dbpedia.org/ontology/Artist>; <http://dbpedia.org/ontology/birthPlace> ?birthPlace. ?birthPlace <http://dbpedia.org/ontology/country> ?country. ?country rdfs:label „Austria”@en. ?person <http://dbpedia.org/property/ dateOfBirth> ?dob FILTER (?dob > „1/1/1800”^^xsd:date && ?dob < „12/31/1899”^^xsd:date) }

Aceast query poate fi rulat în sparqlend-point-ul oferit de dbpedia (http:// dbpedia.org/snorql/), şi afisează ca rezultat o listă de artişti, pentru care se specifică numele, locul, ţara şi data naşterii.

Figura 3. Ciclul de adoptare al tehnologiilor semantice (Octombrie 2009)

Stadiul actual de implementare

În ultimii zece ani, ideea de Web Semantic s-a răspandit tot mai mult, la fel şi adoptarea tehnologiilor de către marii actori de pe piaţa IT. Consorţiul W3C consideră tehnologiile semantice ca fiind tehnologii mature şi în curs de adoptare la scară largă cel puţin în rândul celor care urmăresc evoluţiile tehnologice

Semantic Web Meetup

Figura 4. Linked Data Cloud diagram (early adopters) (vezi Figura 3). De asemenea, analiştii de piaţă sunt foarte optimişti în legatură cu evoluţia tehnologiilor semantice şi adoptarea lor viitoare.

De exemplu, un studiu realizat în 2012 pe un set de 12 miliarde de pagini web indexate de Yahoo!Search arată că utilizarea microformatelor RDFa pentru adnotarea paginilor a crescut cu 510% din martie 2009 până în octombrie 2010, de la 0.6% din paginile analizate pana la 3.6% (430 de milioane de pagini din 12 miliarde).

Una dintre motivaţiile principale pentru adnotarea şi publicarea datelor/ resurselor folosind tehnologiile semantice vine şi din avantajelele oferite de integrarea cu Linked Data Cloud. Linked Data Cloud este o colecţie de date care au fost deja adnotate şi publicate pe Web şi care poate fi exploatată pentru a spori valoarea şi vizibilitatea datelor proprii. Cu alte cuvinte, cu Linked Data se încearcă dărâmarea barierelor de exploatare a silozurile de date dispersate şi izolate. Descriind datele cu ajutorul limbajelor semantice (RDF(S) sau OWL) acestea pot fi exploatate într-o manieră uniformă, pot fi interconectate şi sunt disponibile tuturor. În Figura 4 se pot observa diferitele seturi de date publicate şi interconectate în cadrul grafului Linked Data. În centrul diagramei, ca

În paralel cu activitatea de cercetare-dezvoltare, echipa Semantic Web se concentrează şi asupra creării şi menţinerii active a unei comunităţi locale de profesionişti interesaţi de tehnologiile semantice. Prin intermediul grupului de meetup din Cluj (http://www.meetup. com/Cluj-Semantic-WEB/), ajuns la un număr aproximativ de 110 membri cărora li se adaugă cei 70 de membri ai grupului de meetup din Târgu-Mureş (http://www.meetup.com/Targu-MuresSemantic-Web/) cu care colaborăm îndeaproape, încercăm să menţinem ridicat nivelul de interes şi de conştientizare a comunităţii locale vis-a-vis de ultimele tehnologii semantice apărute pe piaţă. În această direcţie organizăm periodic întâlniri de tip seminar de mediatizare, la care invităm în măsura posibilităţilor cercetători de mare nume în domeniu. Printre aceştia îi putem aminti pe Rada Mihalcea, Constantin Orasan sau Elena Simperl.

Grupurile de meetup sunt deschise tuturor celor interesaţi de Semantic Web iar subiectele discutate sunt stabilite împreună cu comunitatea. Prin urmare, dacă vreţi să aflaţi mai multe despre tehnologiile semantice, vă aşteptăm la următoarele evenimente!

www.todaysoftmag.ro | nr. 4/2012

27

technologii

Flame arma cibernetică dezmembrată Războiul cibernetic – termenul care face înconjorul Internetului și care pătrunde prin toate colțurile lumii moderne. Atitudinea presei este înțeleasă pentru că domeniul IT

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

generează tot atât de multe fețe mulțumite cat și fețe speriate, iar domeniul INFOSEC este de departe un domeniu fascinant, plin de surprize. În ultimii ani descoperirea aplicațiilor Stuxnet și Duqu - două dintre cele mai periculoase aplicații malware targetate, dezvoltate în întreagă istorie a planetei - dar și atacurile realizate de hacktiviști sau de gruparea descentralizată Anonymous asupra serviciilor guvernamentale, au adus în discuție tot mai des amenințarea războiului cibernetic. Multe state ale planetei se conformează și iau măsuri în această direcție.

De la Stuxnet la Flame

Deși Stuxnet reprezintă un șablon, un pioner în războiul cibernetic, ultimele luni ale acestui an au fost zbuciumate de o nouă descoperire, o aplicație malware mult mai complexă decât a putut fi vreodată Stuxnet. Kaspersky Lab, MAHER Center of Iranian Național Computer Emergency Response Team (CERT) și CrySyS Lab of the Budapest University of Technology and Economics au anunțat pe 28 mai 2012 descoperirea malware-ului modular Flame, cunoscut și ca Flamer sKyWIper/Skywiper.

Ultimii dintre cei care au contribuit la descoperire au menționat că sKyWIper (Flame) este de departe cel mai sofisticat malware întâlnit de ei până acum și cu siguranță cel mai complex descoperit în istorie.

Flame se poate răspândi pe alte sisteme prin intermediul rețelelor locale (LAN) sau prin stick-uri USB. Programul periculos, identificat de produsele Kaspersky Lab cu numele Worm.Win32.Flame, a fost creat

28

nr. 4/2012 | www.todaysoftmag.ro

pentru spionaj cibernetic și are capacitatea de a fura date confidențiale, de a face capturi de ecran, a strânge informații despre sistemele atacate, fișierele stocate, traficul din rețea, datele de contact și poate înregistra chiar conversații audio, dacă acel computer are atașat un microfon (inclusiv de la camera web) sau tastele apăsate.

Datele sunt trimise pe unul din serverele CC (Comandă & Control) ce sunt răspândite pe întreg globul așteptând apoi noi comenzi.

Conform primelor estimări din mai 2012, Flame a infectat inițial aproximativ 1,000 de computere, majoritatea dintre acestea fiind ale unor organizații guvernamentale, instituții educaționale și persoane individuale. În acel moment, majoritatea țintelor proveneau din Iran, Israel, Sudan, Syria, Lebanon, Arabia Saudita și Egipt, ajungându-se mai târziu la concluzia că Iran a fost ținta vizată. Flame a avut și o comandă “kill” care poate opri serviciile Flame și șterge orice urme ale existenței acestuia. La scurt timp după ce presa a publicat primele informații despre Flame, comanda “kill” a fost trimisă pe întreaga rețea Flame, iar virusul a dispărut de pe calculatoarele victimelor.

Cercetările preliminare indică faptul că acest malware există “in the wild” (fără să fi fost detectat până acum) de mai bine de doi ani, adică din luna martie 2010. Din cauza nivelului extrem de complex, dar și a naturii direcționate a atacurilor (nu atacă decât anumite ținte), niciun software antivirus nu a reușit să-l identifice.

Cei de la Kaspersky spun pe blogul oficial al companiei că acest vierme informatic

TODAY SOFTWARE MAGAZINE este cu totul deosebit fiindcă nu e gândit să fure bani din conturi și este cu totul diferit fată de atacurile așa-numiților “hacktivisti”.

Mai rămâne o singură variantă, cea cum că ar fi inițiat de o națiune care a sponsorizat dezvoltarea Flame și răspândirea lui. În sprijinul acestui argument stă atât faptul că atacul este desosebit de complex dar și extrem de bine țintit (cele mai multe ținte vizate sunt din Orientul Mijlociu).

Cu toate că funcționalitățile lui Flame diferă de cele ale deja celebrelor arme cibernetice Duqu și Stuxnet, geografia atacurilor, exploatarea anumitor vulnerabilități software și faptul că doar anumite computere sunt vizate de atacuri îl plasează în aceeași categorie a superarmelor cibernetice.

“De câțiva ani buni, riscul izbucnirii unui război cibernetic este subiectul cel mai fierbinte al securității informatice”, spune Evegheni Kaspersky, CEO și co-fondator Kaspersky Lab. “Stuxnet și Duqu făceau parte dintr-un singur lanț de atac, care a ridicat mari semne de întrebare în întreaga lume. Flame reprezintă o nouă etapă în acest război și este deosebit de important să înțelegem că astfel de arme cibernetice pot fi utilizate cu ușurință împotriva oricărui stat. Însă, această situație este diferită de cea a unui război tradițional, deoarece statele cele mai dezvoltate sunt, de fapt, cele mai vulnerabile în cazul unui conflict informatic”, completează Kaspersky.

Legătura dintre Flame și Stuxnet

Toată lumea a simțit că modul în care lucrează Flame și Stuxnet seamănă de la distanță dar BitDefender a reușit să demonstreze acest lucru. Una dintre cele mai evidente asemănări este algoritmul de decriptare pentru string-uri. Acest lucru este vizibil în componente precum atmpsvcn.ocx, s7otbxdx.dll sau mssecmgr.ocx.

Spre exemplu, în cazul atmpsvcn.ocx și s7otbxdx.dll (DLL pentru proxy SCADĂ de la Siemens), algoritmul arată astfel: for (i=0; i < strlen(s); i++) {

sum = (0xB + s[i]) * (0x11 + s[i]);

s[i] -= (sum >> 0x18) ^ (sum >> 0x10) ^ (sum >> 0x8) ^ sum; }

În principala componentă Flame (mssecmgr.ocx) algoritmul araăa astfel: for (i=0; i < strlen(s); i++) {

sum = (0xB + s[i]) * (0x17 + s[i]);

s[i] -= (sum >> 0x18) ^ (sum >> 0x10) ^ (sum >> 0x8) ^ sum; }

instalează în sistem. Pentru mai multe detalii tehnice, intrați aici: http://www. securelist.com/en/blog/208193558/ Gadget_in_the_middle_Flame_ malware_spreading_vector_identified

Detalii despre serverele de Comandă & Control ale lui Flame

Singura diferență este constanta folosită. Astfel, putem spune cu certitudine că Stuxnet și Flame au cel puțin o componentă comună : atmpsvcn.ocx. Totuși, dacă se intră mai în detaliu în anatomia acestei biblioteci, se pot află mai multe.

Un articol detaliat pe această tema scris de reprezentanții BitDefender puteți citi aici: http://labs.bitdefender.com/2012/06/ stuxnets-oldest-component-solves-theflamer-puzzle/

Cum se răspândește Flame?

Modulul principal din structura Flame este un fișier de tip DLL, pe nume MSSECMGR.OCX. În momentul in care se activează, acesta se înregistrează in lista de registri Windows, iar la următorul restart al computerului este încărcat automat de către sistemul de operare. Apoi, MSSECMGR începe sa descărce module adiționale precum Beetlejuice, Microbe, Euphoria, Limbo etc, lista completă fiind aici. Dintre toate acestea modulul Gadget se ocupă de răspândirea Flame. În timpul analizei, cei de la Kaspersky au fost surprinși să afle că stații cu sisteme de operare Microsoft Windows 7, cu toate actualizările la zi, erau infectate cu Flame.

Cum era posibil acest lucru? Ei bine, este posibil doar dacă există o vulnerabilitate 0-day in Windows. Pe lângă asta, modulul Gadget are un rol crucial in răspândirea malware-ului în rețea, ajutându-se de un alt modul, numit Munch.

Gadget si Munch lansează un atac de tip man-in-the-middle împotriva celorlalte computere din rețea. Mai exact, in momentul in care un computer încearcă să se conecteze la site-ul oficial Microsoft Windows Update, conexiunea este redirecționată prin intermediul unei mașini infectate și trimite computerului un Update de Windows fals. Falsa actualizare pretinde că se numește Desktop Gadget Platform și ajută la afișarea gadget-urilor pe desktop. Folosind un certificat fals al Microsoft, Flame se

Având in vedere faptul că geografia atacurilor inițiate de Flame este similară cu cea a lui Duqu, Kaspersky a făcut o comparație a serverelor de Comandă & Control. În cazul Duqu, numărul domeniilor serverelor nu era cunoscut, dar pentru Flame am aflat că acesta depășește cifra de 80. În momentul în care un computer este infectat cu Flame, acesta se conectează în mod implicit la cinci servere C&C, numărul acestora crescând apoi la zece.

Fiecare domeniu era înregistrat cu identități false, prin intermediul GoDaddy.

De asemenea, adresele folosite erau fie false, fie aparțineau unor hoteluri, cea mai veche înregistrare datând din 2008.

Printre numele false se numărau Adrien Leroy, Arthur Vangen, George Wirtz, Gerard Caraty, Ivan Blix, Jerard Ree, Karel Schmid, Maria Weber, Mark Ploder, Mike Bassett, Paolo Calzaretta, Robert Fabous, Robert Wagmann, Romel Bottem, Ronald Dinter, Soma Mukhopadhyay, Stephane Borrail, Traian Lucescu, Werner Goetz or Will Ripmann. Majoritatea serverelor CC aveau ca sistem de operare Windows 7 sau Windows XP. Conform studiilor realizate de Kaspersky, aceștia au observat că Flame are un mecanism de auto-upgrade. Spre exemplu, versiunea 2.212 a devenit 2.242 în două dintre situații. Asta sugerează existența a cel puțin un server de C&C care are un alt nivel de control.

Fișierele încărcate către serverul de C&C este criptat folosind un cifru XOR, cuplat cu o substituție. Pe lângă asta, multe blocuri sunt compresate folosind zlib și ppdm. Toate datele sunt transmise prin pachete de 8192 de bytes, confirmând încă o dată interesele pentru țările din Orientul Mijlociu ce au conexiune la Internet slabă și instabilă. Mai multe detalii aici: http://www.securelist.com/en/ blog/208193540/The_Roof_Is_on_Fire_ Tackling_Flames_C_C_Servers.

De ce a rezistat Flame nedetectat cel puțin cinci ani?

Echipa de analiști de la Bitdefender a făcut cercetări și pe un modul mai puțin mediatizat al aplicației malware www.todaysoftmag.ro | nr. 4/2012

29

tehnologii

Flame denumit advnetcfg.ocx – modul care se ocupă cu monitorizarea anitivirusilor dar care este și o componentă de debugging. Modulul a fost etichetat ca fiind componenta ce se ocupă cu adunarea informațiilor despre Flame pentru a îmbunătăți calitatea și funcționalitatea aplicației. Oricând Flame descoperă vreun ecran ce conține informații cu privire la fișierele aplicației malware, sau conține cuvinte cheie precum “injected” sau “File mssecmgr.exe looks suspicious”, modulul de debugging realizează o captură de ecran iar aceasta este trimisă către serverul de C&C unde este analizată de echipa de programatori din spatele Flame. Subiectul a fost tratat în detaliu pe blogul laboratorului Bitdefender http://labs.bitdefender. com/2012/07/flamer-used-qa-module-tothwart-antivirus/.

Distracția continuă…

După scandalul virusului Flame, încă un virus “politic” a fost descoperit de firmele de securitate IT în Orientul Mijlociu. Virusul Madi sau Mahdi, folosit pentru obținerea de informații secrete, a

fost depistat în Iran, Israel și Afganistan pe 17 iulie 2012. Peste 800 de PC-uri ale agențiilor guvernamentale, ale instituțiilor financiare și companiilor de infrastructura au fost infectate de virusul Madi, susțin experții Kaspersky Lab și Seculert.

Virusul Madi sau Mahdi, ce este echivalent cu “Mesia” în Israel, are ca scop obținerea de informații secrete, de la emailuri și parole până la transferul de fișiere.

Troianul Madi permite infractorilor cibernetici să fure informații confidențiale de pe computerele cu sisteme de operare Microsoft Windows, să monitorizeze

30

nr. 4/2012 | www.todaysoftmag.ro

Flame - arma cibernetica dezmembrată

comunicarea prin email și programele de mesagerie instant, să înregistreze audio și intrările de la tastatură, precum și să realizeze capturi de ecran. Analiza confirmă faptul că mai mulți gigabytes de informație au ajuns pe serverele infractorilor.

Printre aplicațiile și paginile web spionate se numără conturile de Gmail, Hotmail, Yahoo! Mail, ICQ, Skype, Google+ și Facebook ale victimelor.

Supravegherea era condusă și prin intermediul sistemelor ERP/CRM integrate, a contractelor de business și sistemelor de administrare financiară. Nouă amenințare malware a fost detectată mult mai ușor și are un cod mult mai puțin complex decât virusul Flame, considerat cel mai sofisticat din istoria tehnologiei informatice. Mai multe detalii pe http://www. s ecurelist.com/en/blog/208193677/ The_Madi_Campaign_Part_I.

În loc de încheiere

Flame se remarcă prin complexitate și prin numeroasele opțiuni de care dispune, întreg codul aplicației malware însumând peste 20MB. Asta îl face de departe una din cele mai non-conformiste unelte folosite în războiul cibernetic. România, alături de alte state din această zonă geografică au fost luate în calcul că având materia cenușie necesară pentru a construi o astfel de aplicație. În realitate, tot ce înseamnă războiul cibernetic până în acest moment se bazează pe noroc și ipoteze, nimic nu este concret, nimic nu este dovedit cu privire la scopurile acestor servicii. La nivel mondial, există jucători care știu ce fac mai bine decât avem impresia iar la ei termeni precum anonimitatea sau inflitrarea în instituții (non)guvernamentale au sens și reprezintă o chestie de timp și resurse, nu de tehnologie. Dacă în ultimii 3 ani, Stuxnet, Duqu și Flame au reușit să demonstreze că mediul online mai are de lucru, trebuie să luăm în calcul ce alte mutații ale acestora există sau se construiesc chiar în aceste clipe. E posibil ca acesta să fie începutul celui de-al treilea Război Mondial, doar că de aceasta

dată va fi un război rece, tehnologizat, care va începe prin distrugerea economiei și prin controlul informațional dar nu putem ști unde și cum se va opri. Partea frumoasă a acestui război e că aici toate statele lumii moderne se pot confrunta de la egal la egal și nu putem veni cu ipoteze asupra celor care se duelează sau asupra celor care vor câștiga pentru că nu știm ce surprize ascunde fiecare stat preocupat de securitatea informațională. O altă caracteristică a acestui război e viteza cu care se va derula – ne putem aștepta la un război mascat, ascuns și pe termen lung sau ne putem confrunta cu un război foarte rapid și dur, cu impact pe termen lung. În aceste momente, nu putem face altceva decât să ne găsim locul pe tabla de șah și să ne îmbunătățim poziția. Stay safe, stay tuned!

Bibliografie http://en.wikipedia.org/wiki/Flame_(malware) http://labs.bitdefender.com/2012/06/stuxnetsoldest-component-solves-the-flamer-puzzle/ http://labs.bitdefender.com/2012/06/flame-thestory-of-leaked-data-carried-by-human-vector/ h t t p : / / l a b s . b i t d e f e n d e r. c o m / 2 0 1 2 / 0 7 / flamer-used-qa-module-to-thwart-antivirus/ http://www.securelist.com/en/blog/208193522/ The_Flame_Questions_and_Answers ht t p : / / w w w. k a s p e r s k y. r o / b l o g / flame_%E2%80%93_cel_mai_complex_%C5%9Fi_ interesant_malware_pe_care_ lam_v%C4%83zut_p%C3%A2n%C4%83_acum http://economie.hotnews.ro/ stiri-it-12374275-flame-vierme-informatic-complexitate-fara-precedent-ataca-tinte-din-orientulmijlociu-spun-cei-kaspersky-lab.htm

programare

TODAY SOFTWARE MAGAZINE

Big Data Apache Hadoop Continuând seria de articole despre “big data”, începută cu introducerea în lumea “big data” în numărul 2 al revistei și urmată de articolul despre bazele de date de tip “nosql” din numărul 3, a venit rîndul unui articol care să prezinte mai pe larg una din tehnologiile semnificative din lumea “big data” și anume Apache Hadoop.

Robert Enyedi robert.enyedi@betfair.com Senior Software Developer @Betfair

Apache Hadoop este un framework care facilitează procesarea unor seturi de date mari și foarte mari, pe mai multe calculatoare folosind un model de programare simplu: paradigma map/reduce.

Este proiectat în așa fel, încît să scaleze de o mașiniă la mii de mașini, fiecare din ele punînd la dispoziție putere de procesare și spațiu de stocare. În loc să se bazeze efectiv pe hardware pentru “high-availability”, framework-ul în sine este proiectat în așa fel încît să detecteze erorile la nivel de aplicație.

Este un proiect open source aflat sub tutela Apache Foundation, cu o comunitate globală de contributori, dintre care cel mai semnificativ la dezvoltarea lui a fost Yahoo!.

Apache Hadoop este folosit de Yahoo! pentru motorul de căutare, Facebook se laudă cu cel mai mare cluster de Hadoop (30 petabytes de date), folosit pentru printre altele și la Facebook Messaging.

Amazon pune la dispoziție o platformă de tip MapReduce ca parte a Amazon Web Services numită Amazon Elastic

MapReduce.

Numeroase alte firme din IT și nu doar folosesc Apache Hadoop (Twitter, IBM, HP, Fox, American Airlines, Foursquare, Linkedin, Chevron, etc), pentru a-i ajuta în rezolvarea problemelor de diverse tipuri: călătorii online, e-commerce, detectare de fraude, procesare de imagini, sănătate, etc

Istoric

Hadoop a fost creat de către Doug Cutting, care l-a numit după jucăria de pluș a fiului lui.

A fost dezvoltat inițial pentru a oferi un sistem distribuit pentru motorul de căutare Nutch, prin anii 2004-2006 și se bazează pe articolele despre GFS (Google File System) si MapReduce făcute publice de către Google în perioada respectivă. În anul 2006 Yahoo! a angajat o echipă dedicată (inclusiv pe Doug), care a contribuit semnifcativ la dezvoltarea frameworkului, care între timp a devenit un proiect de sine stătător, independent de Nutch.

www.todaysoftmag.ro | nr. 4/2012

31

programare

Arhitectura

Apache Hadoop este dezvoltat în Java și are două componente principale: • HDFS (Hadoop Distributed File System) • MapReduce

HDFS

Este un sistem de fișiere distribuit care pune la dispoziție acess, cu throughput ridicat, la datele applicațiilor.

HDFS dispune de o arhitectură de tip master/slave. Un cluster HDFS este compus (de obicei) dintr-un singur Namenode, un server master care gestionează namespaceul sistemului de fișiere și reglementează accesul clienților la fișiere. În plus, există un număr de servere Datanode, de obicei unul pentru fiecare mașină din cluster, care gestionează spațiul de stocare al mașinii pe care rulează. HDFS expune un namespace al sistemului de fișiere și permite stocarea datelor utilizator in fișiere.

Intern, un fișier este împărțit în unul sau mai multe blocuri (dimensiunea blocului este configurabilă, de obicei este între16128 MB), iar aceste blocuri sunt stocate pe Datanode-uri. Namenode-ul execută operații asupra sistemului de fișiere, precum: deschiderea, ștergerea, redenumirea fișierelor și a directoarelor. Totodată determină și maparea blocurilor de date la Namenode-uri. Datanodurile sunt responsabile pentru servirea cererilor de citire și scriere primite de la clienții sistemului de fișiere. De asemenea, Datanode-urile execută operații de creare, ștergere și replicare de blocuri, ca urmare a comenzilor primite de la Namenode.

HDFS implementează un model de permisi pentru fișiere și directoare care împărtășește mult cu modelul POSIX.

MapReduce

MapReduce este un framework care permite scrierea de aplicații care proceseză cantitați mari de date, în paralel, într-un mod sigur și cu toleranță la erori.

Un job MapReduce împarte setul de date de intrare în părți independente care sunt procesate de task-urile de map în paralel. Framework-ul sortează si concatenează output-ul task-urilor de map fiind pe urma folosit ca și date de intrare pentru task-ul de reduce. Tipic, atît datele de intrare cît si cele de ieșire sunt stocate în HDFS. Framework-ul are grijă de planificarea rulării task-urilor, monitorizarea

32

nr. 4/2012 | www.todaysoftmag.ro

Big Data - Apache Hadoop

lor, precum și re-executarea task-urilor cu erori.

De obicei, nodurile de calcul și cele care stochează datele (Datanode) sunt aceleași.

Cu alte cuvinte, framework-ul MapReduce și HDFS-ul rulează pe același set de noduri.

Această configurație permite frameworkului să planifice rularea task-urilor pe nodurile pe care datele de intrare sunt deja prezente, rezultând în optimizarea traficului de date din rețeaua cluster-ului.

MapReduce constă dintr-un singur proces master JobTracker, și câte un proces TaskTracker pentru fiecare nod din cluster.

JobTracker-ul este responsabil cu planificarea task-urilor pe TaskTracker-e. Totodată ține evidența taskurilor de MapReduce care rulează pe diferite TaskTracker-e, dacă vreunul din aceste task-uri nu reușește, realocă task-ul altui TaskTracker. În termeni simpli JobTracker trebuie să se asigure ca un query pe un set de date mare se execută cu success și că rezultatul ajunge la client într-un mod sigur.

TaskTracker excută task-urile de map și reduce, care-i sunt asignate de către JobTracker.

Totodată TaskTracker trimite constant mesaje de heartbeat către JobTracker, fapt care ajută JobTracker-ul să decidă dacă poate delega un nou task nodului respectiv, sau dacă trebuie să re-execute respectivul task pe alt nod din cauza erorilor.

Pentru a specifica un job MapReduce, applicațiile trebuie să specifice cel puțin următoarele: locația în HDFS a datelor de intrare, locația unde vor fi stocate datele de ieșire, o funcție de map și o funcție de reduce. Acestea precum și alți parametri ai jobului alcătuiesc configurația jobului.

O d at ă c e s u nt c re ate j o bu l s i configurația, utilizatorul le poate înainta JobTracker-ului, care își va asuma responsabilitatea pentru planificarea rulării jobului, precum și a distribuirii și rulării pe node-urile TaskTracker, monitorizarea lor, precum și expunerea statusului către utilizator.

Datele de intrare sunt trimise către funcția map ca perechi cheie-valoare, care la rîndul ei produce perechi cheievaloare, posibil de alt tip. Odată ce partea de map s-a terminat, rezultatele, de tip cheie-valoare, de la toate map-urile sunt concatenate și mai apoi ordonate servind ca date de intrare pentru funcția de reduce, aceasta va produce rezultate tot de tip perechi cheie-valoare.

Limitări

Implementarea curentă a frameworkului MapReduce începe să-și arate vîrsta.

Observând trendurile în dimensiunea și puterea de procesare a clusterelor Hadoop, componenta JobTracker are nevoie de o drastică reproiectare pentru a adresa deficiențele de scalabilitate, memorie consumata, model de threading si performanță.

C er ințele p ent r u f rame work-u l MapReduce, care să satisfacă toate limitarile menționate anterior ar fi: • siguranță (reliability) • disponibilitate (availability) • scalabilitate (clustere de ~10000 de mașini), implementarea curentă suportă cam 4000 de mașini • evoluție • latență predictibilă • utlilizarea optimă a clusterului • suport pentru paradigme alternative la MapReduce

MapReduce 2.0 (YARN sau MRv2)

Următoarea generație MapReduce a fost proiectată pentru a adresa limitările menționate anterior și totodată să satisfacă cerințele de mai sus.

Ideea fundamentală a rearhitecturării, a fost sa se împartă cele doua funcții majore ale JobTracker, managementul resurselor și programarea/monitorizarea joburilor, în componente separate. Noul ResourceMananger se ocupă de alocarea globală a resurselor de calcul pentru aplicații, iar câte un ApplicationMaster per aplicație se ocupă de coordonarea/planificarea aplicației. O aplicație este fie un singur job MapReduce sau un DAG (directed acyclic graph) de joburi.

ResourceManager-ul si serverul slave NodeManager, al fiecărei mașini, care dirijează procesele user de pe masina respectivă, formeaza structura de calcul. ApplicationMaster-ul, per aplicație, este de fapt o librărie a framework-ului a cărei rol este de a negocia resursele de la ResourceManager, și a lucra cu NodeManger(i) pentru a executa și monitoriza task-urile.

ResourceManager-ul are doua componente principale: • Scheduler (S) • ApplicationsManager (ASM) Scheduler-ul este responsabil cu alocarea resurselor pentru diferitele aplicații

programare

care rulează, supuse constrîngerilor de capacitate, cozi, etc. Scheduler-ul este un planificator pur, în sensul că nu se ocupă de monitorizarea sau urmărirea statusului aplicației. Totodata nu oferă nici o garanție cu privire la restartarea taskurilor cu erori, datorate fie erorilor hardware sau la nivel de aplicație.

Scheduler-ul își executa funcția de planificator bazat pe nevoile de resurse ale aplicațiilor, și face asta bazându-se pe noțiunea de Resource Container, care încorporează elemente ca memorie, procesor, disc, rețea, etc.

Scheduler-ul permite o politică de tip plug-in, responsabilă cu împărțirea resurselor clusterului între diferitele cozi, aplicații, etc. Scheduler-ul standard folosește FIFO. Planificatoarele MapReduce existente, precum CapacityScheduler și FairScheduler ar fi exemple plugin-uri.

CapacityScheduler-ul permite cozi ierarhice, pentru a oferi o mai predictibilă partajare a resurselor clusterului. A fost dezvoltat de către Yahoo!. Menirea FairScheduler-ului este să ofere timpi de execuție rapizi pentru joburile mici și QoS (quality of service) pentru joburile de producție.

ApplicationsManager-ul este responsabil cu acceptarea joburilor, negocierea primului container pentru execuția ApplicationMaster-ului specific aplicației,

Figura 2. Arhitectura MRv2 și oferă serviciul pentru restartarea ApplicationMaster-ului în caz de eroare.

NodeManager-ul este, procesul, per mașină, responsabil cu lansarea containerelor aplicațiilor, monitorizarea utilizării resurselor, de către aplicații, și raportarea către Scheduler.

ApplicationMaster-ul, per aplicație, este responsabil cu negocierea de containere de resurse de la Scheduler, urmărirea statusului si monitorizarea progresului.

TODAY SOFTWARE MAGAZINE

MRv2 face parte dintr-un release major de Hadoop (2.x) care pe lîngă MRv2 include și HDFS Federation.

HDFS Federation vine să rezolve o altă posibila limitare a framework-ului, și anume natura singulară a Namenode-ului.

Pentru a putea scala orizontal serviciul de nume, federația folosește mai multe Namenode-uri independente, fiecare din ele avînd un namespace, al sistemului de fișiere, diferit. Namenode-urile sunt independente și nu necesită o coordonare a lor. Datanode-urile sunt folosite ca și spațiu comun de stocare al blocurilor de date, de către toate Namenod-urile.

Fiecare Datanode se înregistrează la toate Namenode-urile din cluster și raspunde la comenzile primite de la acestea. Totodata trimit periodic heartbeat-uri, precum și rapoarte la Namenode-uri.

Tool-uri adiacente

Dezoltarea Apache Hadoop a dus cu sine și la dezvoltarea unui adevărat eco-system de tool-uri/framework-uri adiacente, unele bazate pe Hadoop altele folosite pentru a facilita anumite aspecte ale folosirii Hadoop.

Enumerăm mai jos cîteva dintre cele mai importante.

• Scribe - este un server pentru agregarea fluxilor de loguri, care se poate integra cu HDFS (fișiere de loguri care mai apoi pot fi folosite ca și date de intrare pentru joburi MapReduce).

• Sqoop - este un tool folosit pentru a transfera (importa și exporta) date, în masa, între HDFS și datastores structurate, precum baze de date relaționale.

• Hive - un tool, de tip data warehouse, care oferă posibilitatea de interogări ad-hoc (prin intermediul HiveQL) a seturilor de date stocate în HDFS. • HBase - bază de date de tip NoSQL, având la baza modelul Google BigTable, care folosește ca si mediu de stocare HDFS. • Pig- este o platformă folosită pentru analizarea unor seturi de date mari având un limbaj propriu, pentru descrierea programelor de analiză a datelor. Caracteristica principală a Pig este că prin natura programelor Pig, permite paralelizarea lor la momentul rulării. Complilatorul Pig produce joburi MapReduce.

• ZooKeper - este un serviciu de

• •

• •

c o ord onare p e nt r u apl i c aț i i l e distribuite Oozie - este un tool pentru managementul workflowului/coordonarea joburilor MapReduce.

Cascading - este un nivel de abstracție soft pentru Apache Hadoop. Este folosit pentru a crea și executa workflowuri de procesare a datelor într-un cluster Hadoop, astfel ascunzând complexitatea joburilor MapReduce.

Mahout - este o librarie ce conține algoritimi de “machine learning” și “data mining”, bazată pe MapReduce.

Chukwa - este un tool pentru monitorizarea aplicațiilor distribuite, bazându-se pe arhitectura HDFS și MapReduce.

Concluzii

Acest articol se vrea o introducere în ceea ce înseamnă Apache Hadoop și a unor technologii ce-l înconjoară. Pentru cei interesați de mai multe detalii, numeroase surse sunt disponibile pe internet incepând cu http://hadoop.apache.org.

De asemenea, există o mulțime de soluții comerciale bazate pe Apache Hadoop, una din cele mai cunoscute fiind cea oferită de Cloudera (www.cloudera.com - aici existând și numeroase prezentări precum și traininguri).

www.todaysoftmag.ro | nr. 4/2012

33

programare

Made in Cluj Jumping Electron

Jumping Electron este un joc dezvoltat cu Unity 3D Engine care va rula pe smartphoneuri cu sistem de operare Android, iOS și tabletele aferente. Primele două capitole și 40 de nivele sunt o cursă pe o pistă în interiorul unui Radio și a unui Tonomat, acțiunea următoarelor 40 de nivele urmează să se desfășoare în interiorul unei Centrale Telefonice și a unui Televizor.

Andrei Kovacs

andrei@finmouse.com Fondator & CEO Finmouse Antreprenor cu vastă experiență internațională, axat pe dezvoltarea de afaceri în jurul diferitelor produse IT, de la jocuri până la aplicații sociale.

Unity 3D are o versiune open source, însă pentru Android și iPhone se plătește o licență. Pentru o echipă cu un programator este ok; însă pentru o echipă mai mare se recomandă Unity PRO pentru a se putea face source control, merging changes etc.

De asemenea, Unity 3D permite exportul și către alte platforme (PC, Flash, etc) deci nu excludem pe viitor acest lucru.

Ideea principală a jocului constă în folosirea accelerometrului pentru a controla mișcarea stânga - dreapta a unui electron pe ecran și de asemenea folosirea funcționalității tap screen pentru a sări peste obstacole.

Jocul este gratis, dar cine dorește poate cumpară Volți pe care să îi folosească pentru a achiziționa diverse upgrade-uri – de la electroni mai deosebiti, la extra energy, no adds, level booster etc. Volții pot fi colectați jucând sau dând click pe un Video Add, respectiv rejucând un nivel.

Prezentarea generala a arhitecturii

Practic în Unity se importă modele 3D și animațiile care pot fi făcute în Blender sau în alte programe de modelare.

Unity are un IDE care îți permite să lucrezi cu toate aceste obiecte și să

34

nr. 4/2012 | www.todaysoftmag.ro

vizualizezi în timp real rezultatul final.

De asemenea, se pot atașa diverse script-uri la obiecte, acestea activându-se în funcție de diverse criterii. De exemplu, dacă se atașează un “collider” la un obiect atunci în momentul când un alt obiect interactțonează cu el atunci se poate executa un anumit script. În cazul nostru vom porni animația exploziei în momentul în care electronul se lovește de un perete.

De asemenea, am integrat diverse plugin-uri pentru: • Google Play In-App purchases • Mobclix, dispay add-uri între nivele • OpenFeint, rețea socială de mobile gaming • Playtomic, analytics • Facebook și Twitter • Custom In-House Adds (în meniul principal există un televizor – dacă se dă click pe butoanele lui, acesta coboară și se vede add-ul).

Pentru In-House Adds folosim un web service – accesăm un php pe partea de server care ne returnează poză și URL-ul la care se merge în caz că se dă click pe add.

Avantajul php-ului este că este suportat de

TODAY SOFTWARE MAGAZINE Planuri de viitor

Încă 40 de nivele pentru Jumping Electron Android, și lansarea pe iOS. Plănuim încă două jocuri mergând pe aceeași temă dar introducând elemente noi, urmând să le lansăm anul acesta.

De asemenea, mai avem o lungă listă de idei de jocuri.

Pe partea de aplicații am intrat în testare Alpha cu o aplicație socială pentru mobil care va fi lansată în Cluj, urmând să ne extindem rapid în România și nu numai. Tot ce putem să vă spunem deocamdată este că aplicația va fi un “Cocktail de Interese”.

Câteva cuvinte despre Finmouse, de cand exista pe piata din Cluj, ce produse dezvoltă .. toate serviciile de găzduire web, deci nu a fost necesar să ne mutăm serverele.

Toată partea de mișcare este implementată folosind “Physics Engine” din Unity – practic electronul sare conform legilor fizicii, viteza lui fiind constantă în afara momentelor când utilizatorul colectează un “speed booster”. Săriturile de pe trabulină vor fi evident conforme cu mărul lui Newton. (photo: Speed booster)

Challange-uri întâlnite în dezvoltarea jocului

Unity 3D este o platformă foarte bună pentru dezvoltarea de jocuri. Cea mai dificilă parte este integrarea cu alte sisteme, gen servicii de advertisement.

Pe partea de modelare, optimizarea numărului de poligoane fără a face ca obiectele să apara low polly este un challenge.

Animația de trailer a fost probabil cea mai dificilă parte a modelatorului 3D. Pe partea de programare au existat mici diferențe la physics între device-uri – când inițiai o trambulină cîteodată bila sărea mai mult pe Samsung Galaxy S decât pe HTC Desire, deci a fost nevoie de mici modificări.

Best practice-uri si sfaturi pentru cine doreste sa scrie un joc pe device-uri

Un sfat bazat pe experiența noastră ar fi ca în primul rând să începeți să dezvoltați un joc mai simplu. Noi am lucrat pe un joc 3D mult mai complex, care din păcate a rămas “on hold” fiind depășiți de situație, plănuim însă să îl terminăm în viitor.

Recomandăm Unity 3D p ent r u

jocuri 3D. Se poate folosi și pentru 2D. Recomandat este totuși un singur engine pentru o firmă mică.

Ca limbaj de programare al motorului de grafică am folosit UnityScript asemănător cu Javascript, dar plănuim să trecem la C# în viitorul apropiat, acesta fiind un limbaj mai evoluat și mai ușor de folosit. De asemenea plugin-urile de Unity se scriu în C#. Aceste plugin-uri îti permit să extinzi aplicația cu alte optiuni, de exemplu integrare cu diverse aplicatii. În cazul texturilor complexe, am învățat că mai puține fișiere de textură ajută la performanță. În ceea ce privește loop-urile de muzică, mp3 nu se poate folosi pentru loop-uri infinite (15 sec de muzica rulând incontinuu). OGG Vorbis este bun, dar Unity are probleme cu el. Ce am facut noi a fost să importăm WAV-ul direct în Unity și l-am compresat Unity intern.

De asemenea, tot din experiență am realizat că display add-uri inserate în nivele scad foarte mult FPS-ul (Frame Per Second). De exemplu, pe un HTC Desire de la 17-18 FPS la 3-4 FPS și nu se poate juca. Pe Samsung Galaxy S avem 35-40 FPS și pe Tegra 2 devices 70+ cu grafica dată la maximum.

Când folosiți librării externe încercați să le puneți într-un “sandbox” și să prindeți toate excepțiile pentru că de multe ori au bug-uri. Chiar și așa nu există nici o garanție.

Preferabil ar fi să fie scrise toate pluginurile in-house, dar evident necesită un efort suplimentar și nu merită decât la firme care au zeci de jocuri live.

Finmouse a luat ființă în 2010 și este o companie axată pe dezvoltarea de aplicații și jocuri pentru industria mobile.

Am început cu proiecte de outsourcing și o aplicatie proprie de business/productivity (Call Reminder Notes – care îți permite să atașezi un reminder unui contact și să vezi acel reminder pe ecran în momentul în care persoana respectivă te sună sau o suni tu).

Avem experiență pe majoritatea platformelor de mobile, dar recent ne axăm pe Android, iOS și Unity 3D pentru jocuri.

Suntem o firmă axată foarte mult pe produse interne, plănuind să lansăm încă două jocuri anul acesta precum si un “social mobile network” în vara aceasta.

Lansarea de jocuri și aplicații proprii presupune multă muncă și este mult mai dificil din toate punctele de vedere, dar și satisfacția unui produs live și feedback-ul pozitiv din partea utilizatorilor si a reviewer-ilor este o recompensă pe măsură…

“Challenging and fun” descrie cel mai bine acest lucru.

www.todaysoftmag.ro | nr. 4/2012

35

Background tasks Metro

Noul sistem de operare lansat de către cei de la Microsoft a adus destul de multe schimbări. Una dintre aceste schimbări este şi background tasks pentru aplicaţiile Metro. Înainte să putem vorbi despre background task-urile din Windows 8 este nevoie să întelegem de ce au fost introduse. Windows 8 a apărut din necesitatea unui sistem de operare de a rula pe mai multe tipuri de device-uri. Pe lângă cele cu care suntem obişnuiţi din ce în ce mai multe persoane au început să folosească tabletele. Chiar Radu Vunvulea

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

dacă din punctul de vedere a procesorului şi a memoriei acestea devin din ce în ce mai puternice, aşteptările pe care le avem de la o tableta sunt diferite. Durata bateriei este extrem de importantă pentru o tabletă.

Din această cauză noul sistem de operare a celor de la Microsoft schimbă puţin lifecycle-ul pe care o aplicaţie îl are.

Aplicaţiie de tip Metro sunt total diferite faţă de cele cu care ne-am obişnuit până acuma pe un sistem de operare cu Windows. Totodata conceptul de Windows Services dispare când discutăm despre o aplicaţie Metro pentru Windows 8.

Aceste aplicaţii sunt gândite să conserve cât mai mult din resursele pe care le are device-ul (procesor, memorie şi conexiune la internet şi baterie). Din această cauză doar aplicaţia care este în foreground într-un anumit moment rulează. Restul aplicaţiilor care sunt deschise dar nu sunt în foreground intră într-o stare specială

Figura 1. Lifetime-ul aplicației

36

nr. 4/2012 | www.todaysoftmag.ro

numită „suspended”. În cadrul acestei stări toate thread-urile sunt îngheţate, aplicaţia existând doar în memorie dar fără să execute nici un fel de cod. O aplicaţie aflată în această stare poate să revină înapoi în foreground fără nici o problemă.

Sistemul de operare poate să decidă ca o aplicaţie care este în starea „suspended” să fie oprită, iar toate resursele care sunt ocupate de aceasta să fie eliberate. Acest caz apare când sistemul nu mai are destule resurse disponibile pentru utilizator.

Nu puţine sunt aplicaţiile care au nevoie de a rula cod în background. Pentru a putea suporta această funcţionalitate Windows 8 suportă background task-ul.

Acestea nu sunt chiar noi, ele existând şi pe Windows Phone 7. Conceptul de bază pentru background task din Windows 8 este destul de asemănător cu cel din Windows Phone.

Un background task reprezintă un task care rulează în fundal. Acesta nu necesită ca aplicaţia noastra să fie pornită. Momentul când acesta este pornit durata sa de viaţă este în totalitate controlată de către sistemul de operare. În funcţie de anumite condiţii sistemul de operare poate să decidă ca background task-urile să nu ruleze pentru o periodă de timp. De exemplu dacă nivelul bateriei este mic, iar sistemul de operare doreşte să işi

TODAY SOFTWARE MAGAZINE acest tip putem să monitorizam progresul puteti găsi flow-ul de înregistrare şi apelare și/sau să ne creăm un cancelation token pe a unui background task. care îl putem folosi pentru a putea face canCodul care dorim să se execute întrcel la download. un backgrond task trebuie să fie pus într-o clasa sealed care implementează interfaţa IBackgroundTask. Această interfaţă vine cu CancellationTokenSource cancellationmetoda Run care o să fie apelată de fiecare Token = new CancellationTokenSource(); await download.AttachAsync().AsTask( dată când background task-ul este apelat. cancellationToken.Token,

new Progress<DownloadOperatio n>(DownloadProgress));

conserve resursele, acesta nu va mai putea să ruleze background task-urile.

Figura 2. Procesele în care rulează task-urile de background Există mai multe tipuri de background task-uri pe care sistemul de operare ni le pune la dispoziţie. În principiu putem să le grupăm în două tipuri principale, definite de utilizator şi cele default care vin odată cu acesta.

By default, avem câteva background task-uri definite de către Windows 8.

Acestea sunt folosite pentru a executa diferite task-uri de către sistemul de operare.

Totodată acestea pot fi folosite de către dezvoltatori. Se recomandă să fie folosite, deoarece nu are rost să reinventăm roata.

Mai jos gasiţi lista de background task-uri care sunt definite de sistemul de operare: • Background audio • Background upload • Background download • Sharing • Device sync • Live tiles • Scheduled notifications Toate aceste background task-uri sunt deja definite şi implementate de Windows 8.

De exemplu pentru a putea face download la un fişier, tot ce trebuie să facem este să setăm locaţia de unde facem download şi locaţia pe disk unde să copiem fişierul.

Sistemul de operare se va ocupa automat de procesul de download, iar în cazul în care conexiunea se pierde sau device-ul se restartează, Windows 8 va continua copierea fişierului automat, fără să fie necesar să facem ceva.

BackgroundDownloader downloader = new BackgroundDownloader(); DownloadOperation download = downloader.CreateDownload(mySource, myDestinationFile);

await download.StartAsync().AsTask(); În exemplul de mai sus am creat un background task care face download la un fişier de pe internet. Pentru fiecare task de

Din păcate task-urile definite default de către Windows 8 nu vor ajunge pentru toate scenariile pe care ni le putem noi imagina.

Pentru a veni în ajutorul nostru, Windows 8 ne permite să ne definim background task-uri custom, care se apelează automat de către sistemul de operare în funcţie de anumite evenimente.

Există nenumărate tipuri de trigger-e care ne sunt puse la dispoziţie, începând de la trigger-e care sunt apelate când avem conexiune la internet sau o nouă sesiune este creată, până la trigger-e care se apelează la un interval definit de timp. Dacă vreţi să folosiţi TimeTrigger trebuie să ţineţi cont de faptul că intervalul minim de timp este de 15 minute.

Ceea ce este foarte important de subliniat aici este faptul că un background task poate avea doar un trigger. În schimb o aplicaţie Metro poate avea oricâte background task-uri. În unele cazuri ajungem să avem task-uri care se rulează în background care au diferite dependinţe. De exemplu putem avea un backgrond task care trimite locaţia curentă a userului la un anumit interval de timp spre un server. Pentru a putea trimite datele la server avem nevoie de o conexiune la internet. Pentru a putea suporta aceste cazuri, un background task poate avea definite zero sau mai multe condiţii. Doar în momentul în care toate condiţii sunt îndeplinite acesta va fi rulat. În cazul în care una dintre condiţii nu este îndeplinită, iar după un interval de timp aceasta este îndeplinită, background task-ul o să fie rulat automat de către sistemul de operare.

Mai jos puteţi găsi lista de condiţii disponibile: • InternetAvailable • InternetNotAvailable • SessionConnected • SessionDisconnected • UserNotpresent • UserPresent Primul pas pe care trebuie să îl facă o aplicaţie Metro este să işi înregistreze trigger-ul şi clasa care o să fie apelată când se face fire pe trigger. Sistemul de operare o să apeleze automat clasa noastră. Mai jos

public sealed class MyBackgroundTask:I BackgroundTask { private int globalcount; void IBackgroundTask.

Run(IBackgroundTaskInstance taskInstance) { Log.WriteInfo(„My Background task was called.”): } }

În cazul unei aplicaţii Metro scrisă în C# este nevoie să ne creăm un proiect separat în care să punem această clasă. Acest lucru este necesar din cauză că acest assembly trebuie să fie încărcat de către sistemul de operare când se face fire la un trigger.

Odată ce ne-am creat un background task, acesta trebuie să fie înregistrat prin intermediul clasei BackgroundTaskBuilder.

BackgroundTaskBuilder taskBuilder = new BackgroundTaskBuilder(); taskBuilder.Name = „MyBackgroundTask”; taskBuilder.TaskEntryPoint = „MyNamespace.MyBackgroundTask”; IBackgroundTrigger timeTrigger = new TimeTrigger(30, true); builder.SetTrigger(timeTrigger); IBackgroundCondition condition = new SystemCondition (SystemConditionType.InternetAvailable); taskBuilder.AddCondition(condition); IBackgroundTaskRegistration myTask = builder.Register();

În exemplul de mai sus am înregistrat background task-ul nostru că să fie apelat odata la 30 de minute doar dacă există conexiune la internet. Prin intermediul instanţei myTask putem sa ne înregistrăm la evenimentele de progress change şi de complete. În cadrul background task-ului acestea pot fi apelate prin intermediul instanţei IBackgroundTaskInstance, pe care o primim ca şi parametru în metoda Run. myTask.Progress += new BackgroundTaskP rogressEventHandler(TaskProgress); myTask.Completed += new BackgroundTask CompletedEventHandler(TaskCompleted);

Un task trebuie să fie înregistrat o singură dată, dar de fiecare dată când aplicaţia noastră este oprită şi reporneşte este

Figura 3. Limitările de procesare pentru un background task

Figura 4. Constrângerile utilizării WiFi www.todaysoftmag.ro | nr. 4/2012

37

programare

nevoie să ne înregistrăm la evenimentele de Progress şi Completed.

Pentru a putea face acest lucru, în cadrul aplicaţiei putem itera prin toate background task-urile înregistrate de către aplicaţia noastră. În exemplul de mai jos, pentru fiecare background task în parte ne înregistrăm la evenimentul de Progress şi Completed.

Fiecare background task înregistrat de către aplicaţia noastră trebuie să fie declarat în fişierul de manifest. În cazul în care acesta nu este înregistrat, nu o să poată rula deloc. Pentru fiecare background task declarat în manifest este nevoie să specificăm ce tip de task-uri suportă şi entry point-ul pentru acesta. În funcţie de trigger există background task-uri care pot fi pe lock screen. Aplicaţiile care sunt în lock screen sunt privilegiate, având acces la mai multe resurse faţă de o aplicaţie normală. Din această cauză numărul aplicaţiilor care pot fi pe acest screen este limitat.

Resursele la care are access un background task sunt limitate. Din unele puncte de vedere acestea au mai fost numite şi Windows Services din Metro style app. În comparaţie cu Windows Services, background task-urile au acces la resurse limitate.

Aceste limitări au apărut din dorinţa de conservare a resurselor pe care un device le are, aici nu ne referim doar la baterie, cât şi la alte resurse precum conexiunea la

Background tasks - Metro

internet.

Cea mai mare limitare apare la procesor. Fiecare background task care aparţine unei aplicaţii care se află pe lock screen are dreptul la 2 CPU seconds la un interval de 15 minute. Pentru cele care nu se află în lock screen, fiecare background task are dreptul la 1 CPU second la fiecare 2 ore. În cazul în care aveţi apeluri asyncrone spre resurse externe (de exemplu un apel spre un serviciu aflat pe un server) nu trebuie să vă faceţi griji. Înainte de acest tip de apeluri este nevoie să obţineţi o instanţă a unui obiect de tip BackgroundTaskDeferral. void IBackgroundTask.

Run(IBackgroundTaskInstance taskInstance) {

BackgroundTaskDeferral deferral = taskInstance.GetDeferral();

var result = await SomeActionAsync(); deferral.Complete(); Log.WriteInfo(„My Background task was called.”): } public async void Run(IBackgroundTaskInstance taskInstance) { // // Create the deferral by requesting it from the task instance. // BackgroundTaskDeferral deferral = taskInstance.GetDeferral(); // // Call asynchronous method(s) using the await keyword. //

var result ExampleMethodAsync(); //

Figura 3. Înregistrarea și apelarea unui task de background

38

nr. 4/2012 | www.todaysoftmag.ro

=

await

// Once the asynchronous method(s) are done, close the deferral. // deferral.Complete(); } Intervalul de timp în care serviciul trimite răspunsul, nu se contorizează.

Limitări asemănătoare apar şi în legătură cu accesul la reţea şi traficul maxim care se poate face la un interval de timp.

Dar cea mai mare constrângere este legată de CPU. Folosirea background task-urilor ne poate ajuta extrem de mult. Limitările pe care acestea le au sunt gândite pentru a salva cât mai multe resurse, recomandându-se ca ele să fie utlizate doar când este cu adevărat nevoie de ele.

management

TODAY SOFTWARE MAGAZINE

Microsoft Project şi proiectele Agile

Toţi cei care au interacţionat, indiferent cât de puţin cu Microsoft Project sunt unanim de acord că este o foarte puternică unealtă de scheduling. Altfel spus, dacă îi definim şi detaliem task-urile, se pricepe foarte bine să construiască un plan (mai corect spus un schedule) mai bine ca oricine. Dar, pentru a putea defini clar task-urile, este nevoie să

Florian Ivan, PMP

florian.ivan@rolf-consulting.com Project MVP

ştim cu exactitate ce dorim de la proiect. Ce anume trebuie el să livreze, în ce condiţii, respectând ce criterii, etc. Pare simplu, nu-i aşa? În practică, ştim cu toţii cât de complicat (imposibil?) este să definim încă de la început scopul proiectului şi livrabilul. Şi atunci, cum mă poate ajuta Microsoft Project dacă eu (sau clientul meu) nu ştiu ce vreau de la proiect?

Acesta este motivul principal pentru care au apărut metodologiile sau mişcările Agile. Pentru că, în foarte multe domenii,

în software în special, este foarte greu să ştii de la început ce anume trebuie să livrezi.

Este suficient să ne gândim la un site web a cărui dezvoltare durează câteva luni şi deja este evident că este imposibil să îl putem planifica minuţios încă de la început. Pe

scurt, Agile (şi bineînţeles derivaţiile sale Scrum, XP, FDD, etc.) propovăduieşte faptul că schimbarea este binevenită, că este în regulă să începi proiectul fără să ştii prea multe despre ce anume urmează să livrezi şi, foarte important, că produsul sau livrabilul proiectului se defineşte pe parcurs.

Pare magie dar, în realitate, este doar o schimbare de paradigmă care introduce noţiunea de planificare iterativă. În imaginea de mai jos este exprimat grafic acest concept.

Lucrurile par mai simple acum, nu?

Planificăm puţin, atât cât ştim, executăm ce am planificat, apoi o luam de la capăt. Şi aşa până terminăm ce avem de făcut sau până când clientul nostru nu mai are idei. Într-adevăr, Agile reprezintă o soluţie la îndemâna companiilor de software pentru a putea pune puţină ordine în proiectele care altfel par fără cap şi coadă. Ajută la scop management, care este definit incremental, funcţionalitate cu funcţionalitate, ajută la planificare care este şi ea un întreg compus din bucăţele, dar este util mai ales în implementarea a ceea ce a fost planificat.

39 www.todaysoftmag.ro | nr. 4/2012

39

management

Aşadar, Agile ne oferă un cadru ca să definim scopul proiectului, să planificăm, să urmărim progresul şi să o luăm de la capăt.

Pentru a ne face o idee şi mai bună despre Agile îi putem opune o altă metodologie. Opusul Agile se numeşte waterfall.

O metodologie waterfall este una în care, încă de la început ştim foarte clar ce trebuie să livram (scopul proiectului), ce termene trebuie să respectăm (un scheduling foarte precis) şi, bineînţeles, care sunt limitele de buget în care ne putem încadra. Desigur, sunt multe proiecte din multe domenii de activitate în care o abordare waterfall este foarte potrivită. În special acolo unde este nevoie de acurateţea aceasta încă de la început iar sponsorul proiectului sau condiţiile mediului impun o asemenea stricteţe. Doar că în software lucrurile nu stau chiar aşa şi deci aici intervine Agile.

Acum, că am definit procesele, este nevoie să trecem la nivelul următor să standardizăm şi automatizăm aceste procese. Aici intră din nou în scenă Microsoft Project.

Cum spuneam şi mai sus, acest software este folosit şi apreciat, în primul rând, pentru capabilităţile sale de scheduling.

Bineînţeles că mai ştie şi alte lucuri cum ar fi managementul resurselor sau rapoarte dar principala sa utilitate este să gestionze şi automatizeze complexitatea task-urilor dintr-un proiect. Nu vom intra în detalii legate de portofolii sau lucru colaborativ, caracteristici mai degrabă de Project Server ci ne vom limita la funcţionalităţile unei Project Professional.

Ce face un project manager în momentul în care deschide un Microsoft Project?

Experienţa arată că 90% dintre ei se apucă să scrie o listă de task-uri pe care apoi le pun într-o secvenţă ca să arate frumos într-un grafic Gantt. Doar că pentru acest lucru este nevoie să ştim lista de task-uri care derivă din scopul proiectului cunoscut în prealabil în detaliu. Ceea ce, aşa cum am argumentat mai sus, într-un proiect software nu prea este cazul şi de aceea folosim abordări Agile. Şi totuşi, cum putem folosi Microsoft Project în acest scenariu.

40

nr. 4/2012 | www.todaysoftmag.ro

Microsoft Project si proiectele Agile

Planificarea iterativă a fost întotdeauna parte din project management indiferent de cât de agilă a fost metodologia folosită. Aşadar, în orice proiect putem avea o abordare de planificare, execuţie şi apoi iar planificare. Ideea de a folosi o aplicaţie software specializată de project management nu schimbă cu nimic incertitudinea, și nici nu impune o anume rigurozitate care, în mod normal nu caracterizează proiectele noastre. Imaginea de mai jos exemplifică, în Microsoft Project acest ciclu de planificare şi execuţie iterativă. După cum se vede din imagine, după ce am planificat, atât cât a fost posibil, trecem mai departe la execuţie, după care revenim la planificare.

Acest ciclu de planificare este ceea ce PMI numeşte rolling wave planning.

A ne impune o planificare riguroasă în condiţiile în care nu avem suficiente date nu face decât să aducă în proiectul nostru un element de risc dat de nişte estimări nerealiste. Din imaginea de mai sus, totuşi, nu reiese foarte clar că ar fi un ciclu de planificare-execuţie. Aşa cum şi pare din graficul Gantt, replanificare pare o întoarcere în timp. Ceea ce nu este posibil! Şi atunci, pentru a putea reflecta cât mai fidel realitatea, putem crea task-urile pe iteraţii, aşa cum este ilustrat mai jos.

Practic, se definesc în Microsoft Project task-uri pentru fiecare iteraţie atât pentru planificare cât şi pentru execuţie. În exemplul de mai sus se pot adăuga oricâte iteraţii

sunt necesare proiectului. Acest lucru îl pot face înserând un set de task-uri pentru planificare şi execuţie legând noua iteraţie de ultima pe care o avem definită anterior.

Urmărind această secvenţialitate, se poate planifica un proiect Agile folosind o unealtă care tradiţional a fost privită ca fiind una destinată proiectelor waterfall.

Mai departe, Microsoft Project permite alocarea de resurse şi monitorizarea progresul acestor task-uri. Este extrem de important ca după ce s-adefinit acest plan (sau schedule) să nu se renunţe şi să continuie cu monitorizarea proiectului. Este foarte posibil ca în timpul execuţiei să mai apară alte elemente necunoscute care să ducă către replanificare sau modificarea unor task-uri existente. Este suficient să ne gândim la modificarea unui task dintr-un proiect care are sute de asemenea task-uri ca să vedem importanţa Microsoft Project pentru planificarea şi urmărirea proiectelor. Dacă asta nu v-a convins, mai trebuie să ştiţi că se integrează nativ cu suita Visual Studio, astfel încât echipele de dezvoltare îşi regăsesc task-urile asignate direct în mediul de dezvoltare.

diverse

TODAY SOFTWARE MAGAZINE

Gogu

Simona Bonghez, Ph.D.

simona.bonghez@confucius.ro speaker, trainer si consultant, director al Confucius Consulting “Cred cu tărie în puterea jocului şi a metaforei şi îmi place la nebunie ca sesiunile mele de training să fie distractive şi interactive, în aşa fel încât participanţii să acumuleze informaţiile într-o manieră cât mai plăcută…”

Gogu armă alarma, stinse luminile şi ieşi din clădire. Salută portarul care fuma impasibil în faţa intrării, cu un aer de stăpân peste zecile de birouri rămase în întuneric şi îşi înăbuşi un oftat. „Că doar nimeni nu mă obligă să stau ca portaru’ până la ora asta”. Orgoliul îl obligase, „da’ asta nu se pune”. Altădată ar fi zâmbit la propriai remarcă, dar acum era prea amărât: păi cum, vine o copiliţă şi-i dă lui indicaţii, lui, care e în compania asta de şapte ani, „mă rog, şase jumate’”se corectă el singur. Dar nu despre asta era vorba, ci despre faptul că el, Gogu, nu numai că ştia tot ce mişcă în companie, ci mai mult, el era autorul procedurilor care acum erau puricate de „copiliţă”. „Care proceduri n-ar exista nici acum dacă n-aş fi tras eu acum trei ani o vară întreagă”. Şi fusese felicitat de însuşi GM-ul companiei care acum, uite, îi aduce „copiliţa” cu idei de optimizare. „Şi Mişu ăsta care e în concediu tocmai acum…” La remarca asta i se declanşă în minte filmul cu plecarea lui Mişu: apăru întâi imaginea unui Mişu ezitând la plecare şi imediat imaginea unui Gogu spunând cu încredere în glas: Du-te, Mişule, liniştit, mă descurc, nu-i o problemă! „Mda, ce-şi face omu’ cu mâna lui...”

Afară se făcuse întuneric bine iar trecători erau doar câţiva, dar el stătea aproape, la o aruncătură de băţ. Rămăsese mult peste program ca să verifice încă o dată dosarul cu descrierea proceselor din firmă, să printeze ultimele versiuni, „căci da – reluă el şirul monologului interior – am făcut şi noi optimizări, cam peste tot. De aici şi versiunile. Doar că la aceste optimizări au contribuit cei din firmă, care ştiu cu ce se mănâncă treaba pe la noi. Uff...” Remarcă privirile ciudate ale unui trecător şi îşi dădu seama că monologul interior a devenit un fel de bolboroseală neinteligibilă. „Hai ca o iau razna”. Intră în casa scării şi îl izbi un miros de friptură care îi alungă orice gând de procese, proceduri sau copiliţe cu idei de optimizare. „Pui umplut la cuptor” gândi el şi înghiţi în sec. „Mamă, şi cât de bun ştie să îl facă!” Un zâmbet de satisfacţie i se lăţi pe toată faţa, îşi iubea soţia mult şi la fel de mult iubea şi ceea ce îi gătea ea.

- Ia uite cum rânjeşte fasolea la mine, unde-ai stat până la ora asta? Parcă te-ai însurat cu firma, nu cu mine. Ia să-ţi dea firma de mâncare, dacă stai acolo până

noaptea târziu!

Dar ochii îi râdeau iar Gogu simţea dragostea ei în fiecare cuvânt. În timp ce se pregătea de masă, îi povesti soţiei toată tărăşenia cu optimizarea, raportă cu onestitate vârsta „copiliţei” - care împlinise treizeci -, dar îndârjirea îi trecuse deja, iar mintea îi stătea doar la mâncare. Când tava cu puiul umplut îşi ocupă regal locul în mijlocul mesei, captă în totalitate atenţia lui Gogu care nu mai prididea cu laudele.

- Dar n-are târtiţă ?! De ce i-ai tăiat-o, de obicei o laşi...

- Nu m-am gândit prea mult, am tăiat-o că aşa ştiam că se face. Aşa face şi mama.

- Păi şi de ce?

- Măi Gogule, ţie nu ţi-e foame? Ce contează de ce, am tăiat-o şi gata.

- Ba mi-e foame şi o să şi mănânc, dar vreau să ne lămurim – zise Gogu, pus pe şotii, şi se întinse după telefon.

- Cum adică să nu ştim de ce facem ce facem? mai adaugă el râzând, în timp ce căuta în memorie numărul mamei soacre. Ştia că la ora asta urmăreşte serialul preferat şi n-ar fi ratat pentru nimic în lume să o „scoată din atmosferă” - citat din mamasoacră. Plus că n-avea cum să se lungească la vorbă, decât dacă – Doamne fereşte! – ar fi prins momentul de publicitate.

Răspunsul îl luă prin surprindere: - Nu se taie, dragă, târtiţa, ce vă veni?!

- Dar mamă, tu întotdeauna o tăiai când făceam acasă pui umplut! sări de colo şi soţia, sub presiunea nedreptăţii ce i se făcea.

- Ah, păi pe-atunci aveam tava aia mică, de nu încăpea puiul întreg, deaia tăiam târtiţa! Acum pot să mă întorc la serial? Că n-aţi suna şi voi în pauză să putem vorbi liniştiţi...

Discuţia cu mama soacră fu scurtă – evident, de vreme ce se uita la serial – şi îl şi binedispuse „hi-hi, îmi place să o enervez un pic”, dar îl puse pe gânduri.

Constrângerile s-au schimbat, dar obiceiul s-a păstrat... „Ce chestie..., iar dacă eşti în interior, nu îţi dai seama că anumite lucruri se modifică şi continui să lucrezi aşa cum te-ai obişnuit. În schimb, o „copiliţă” din exterior poate să vadă imediat unde nu mai sunt necesare vechile obiceiuri, așa cum am văzut și eu văzut târtiţa” www.todaysoftmag.ro | nr. 4/2012

41

...even mammoths can be agile…

Lansarea numarului numarului #5 Lansarea #5alalrevistei revistei TodaySoftware Software Magazine oday Magazine 21 septembrie 2012

21 septembrie 2012 Ce legătură exista între mamuţi şi abordările Agile? Vă invităm să aflaţi pe 21 septembrie 2012, la City Plaza în Cluj Napoca (Str. Sindicatelor 9-13).

08:30 - 09:00 Primire participanti Confucius Consulting, în parteneriat cu Today Software Magazine, găzduieşte un eveniment ce va 09.15 clarifica această dilemă09:00 dar va -face lumină şi în Deschidere tema abordăriloreveniment de managementul proiectelor în industria software.

09:15 - 10:30

Speakeri invitati

Cu ocazia acestui eveniment va fi lansat şi numărul 5 al revistei Today Software Magazin iar unii dintre autorii consacraţi ai revistei vor răspunde participanţilor la întrebări legate de adaptabilitate şi flexibilitate.

10:30 - 10:45 Pauza de cafea Speakerii invitaţi ne vor vorbi despre metodologiile AgileLupei în managementul proiectelor, despre Adrian 10:45 11:30 avantajele lor în comparaţie cu abordările tradiţionale, despre dificultăţi în implementarea lor în How to pay off your technical debt organizaţii şi despre abilităţile necesare pentru a le putea gestiona în mod eficient.

11:30 - 12:15 Speaker invitat Participarea este gratuită, dar numai pe baza înscrierii, numărul de locuri fiind limitat. Pentru mai multe detalii dar şi pentru înscriere, vă rugăm să ne scrieți la adresa training@confucius.ro sau lansare@todaysoftmag.com . - 13:00 12:15 Pauza de pranz Vă așteptăm să aflăm împreună dacă ... și mamuții pot fi AGILE...

13:00 - 14:00

Speakeri TSM

14:00 - 14:15

Oferire premii tombola

sponsori

powered by