Numarul 33 - martie 2015 - Today Software Magazine

Nr. 33 • Martie 2015 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

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

spozitivele mobile

di Realitatea virtuala îmbunătățită pe Java Chronicle în acțiune

Analiza orientată spre tehnologiile viitoare Interviu cu Jon Shieber Senior Editor TechCrunch Apache Cassandra, Primii Pași

Importanța realizării de prototipuri Appium - testare automată cross-platform pentru dispozitive mobile Date de tip spațial în SQL Server

Quality Assurance în Agile Sisteme de mesagerie performante – Apache Kafka O introducere și tuning-ul Hadoop MapReduce Usable Software Design Abordare simplă a riscului în Scrum Dezvoltarea aplicatiilor securizate în Java

6 Interviu cu Jonathan Shieber, senior editor la TechCrunch și CrunchBase Ovidiu Măţan

7 Lansarea Different Angle primul Cluster de IT & C din București Ovidiu Măţan

8 De ce să vii la Startup Weekend Cluj 2015?

Cristina Juc

10 MVP Academy prezintă cele 13 startup-uri admise în programul de pre-accelerare Irina Scarlat

12 Alt-tester la Mobile World Congress 2015 Simina Rendler

15 Realitatea virtuală îmbunătățită pe dispozitivele mobile Alexandru Fediuc și Virgil Andreies

19 Introducerea și tuning-ul Hadoop MapReduce Tudor Lăpușan

22 Sisteme de mesagerie performante – Apache Kafka Tiberiu Nagy

25 Date de tip spațial în SQL Server Diana Muntea

28 Usable Software Design Alexandru Bolboacă

31 Quality Assurance în Agile Vasile Selegean

35 Dezvoltarea aplicațiilor securizate în Java Silviu Dumitrescu și Diana Bălan

38 Abordare simplă a riscului în Scrum Sebastian Botiș

42 Importanța realizării de prototipuri Cătălin Timofti

44 Java Chronicle în acțiune Vasile Mihali

46 Apache Cassandra, Primii Pași Sergiu Indrie

49 Appium - testare automată cross-platform pentru dispozitive mobile Vasile Pop

46 Analiza pentru tehnologiile viitoare Ioana Armean

editorial

Î

Ovidiu Măţan

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

ntr-una din serile trecute, încurajați de atmosfera relaxată, eu și cu un prieten ne-am permis să abordăm problema relației dintre echipele de programatori și de testeri dintr-o perspectivă filozofico-religioasă. Opoziția tester-programator, care-l plasează pe programator în postura de creator, iar pe cel de tester în postura de chițibușar veșnic în căutare de defecte și animat de a distruge ceea ce a creat cu atâta pasiune programatorul, poate fi dizolvată doar după ce fiecare parte își lasă orgoliul la o parte și nu se mai crede înger și respectiv, demon. Ne-a fost tare greu să ne debarasăm de ipostazele acestea ! Soluția a venit de la filozofia orientală, care îl pune pe fiecare într-o poziție avantajoasă: antagonismul programator-tester este asemenea principiilor Ying-Yang, adică un sistem a cărui valoare este mai mare decât cea a componentelor sale. Dar să părăsim lumea ideilor și să ne întoarcem în meandrele concretului, adică la evenimentele acestei primăveri.

Doresc să menționez două dintre ele care au avut loc recent. Este vorba de ..even mammoths can be Agile, singurul eveniment local ce strânge comunitatea locală de management. TSM a fost notat și de această dată la secțiunea organizatori. Contribuția noastră a fost implicarea în publicarea în format tipărit a tuturor poveștilor lui Gogu și care au apărut în revistă în ultimii trei ani. A fost un proiect inedit și ne bucurăm să publicăm astfel cea de-a doua carte TSM. Al doilea eveniment, la care TSM a participat ca partener iar subsemnatul ca moderator al unui track este Cluj Innovation Days 2015.

Acesta a crescut mult în ultimii ani, mutându-și atenția din zona politică spre dezvoltarea de produse. Tema aleasă pentru această ediție este transferul tehnologic. Am avut ocazia să vedem prezentări interesante din zona cercetării, inovației, a procesului de patentare, a modalității de a ieși pe bursa de valori. Important de semnlat a fost și Internet of Things, un workshop susținut de Google.

Trecem în revistă o parte din articolele acestui număr. Începem cu un scurt interviu acordat revistei de către Jonathan Shieber, senior editor la TechCrunch cu care am avut ocazia să discutăm în cadrul unui workshop organizat la Cluj. Viziunea sa asupra startup-urilor este scoaterea în evidență a esențialului, a factorului de diferențiere.

Continuăm cu o scurtă prezentare a Different Angle, primul Cluster de IT & C din București. Startup Weekend este un eveniment la care toți cei ce doresc dezvoltarea unui produs ar trebui să participe, publicăm în acest număr o serie de sfaturi de la cei ce s-au clasat primii la ultimele ediții. Mobile World Congress este unul dintre cele mai mari evenimente de IT din Europa de unde colaboratori ai revistei au venit cu noutăți și impresii. Seria de articole tehnice începe cu Realitatea virtuală îmbunătățită pe dispozitivele mobile, ce prezintă principalele framework-uri care ne ajută în crearea de aplicații destinate realității augmentate. Tehnologiile cloud sunt reprezentate printr-o serie de articole în acest număr: Introducerea și tuning-ul Hadoop MapReduce, Sisteme de mesagerie performante – Apache Kafka, Date de tip spațial în SQL Server, Java Chronicle în acțiune și Apache Cassandra, Primii Pași. Dualitatea cu zona de testare este păstrată prin: Appium - testare automată cross-platform pentru dispozitive mobile și Quality Assurance în Agile. Încheiem într-un ton optimist cu un articol interesant ce investighează viitorul tehnologiei: Analiza pentru tehnologiile viitoare.

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

Ovidiu Măţan

Fondator al Today Software Magazine

4

nr. 33/2015 | www.todaysoftmag.ro

Redacţia Today Software Magazine Fondator / Editor in chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com Copyright/Corector: Emilia Toma emilia.toma@todaysoftmag.com

Lista autorilor Alexandru Bolboacă

Silviu Dumitrescu

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

Java Line Manager @ Accesa

Alexandru Fediuc

Simina Rendler

Associate IT Consultant @ msg systems România

Software Tester @ Altom Consulting

Cătălin Timofti

Tiberiu Nagy

UX Designer @ SDL

Senior developer @ Betfair

Cristina Juc

Tudor Lăpușan

Organizatoare @ Startup Weekend Cluj

Java & Big Data developer @ Telenav

Diana Bălan

Vasile Mihali

Java developer @ Accesa

Senior Software Engineer @ Arobs

Diana Muntea

Vasile Pop

Software Developer @ Yardi România

Software Engineer @ Intel România

Ioana Armean

Vasile Selegean

alex.bolboaca@mozaicworks.com

alexandru.fediuc@msg-systems.com

silviu.dumitrescu@accesa.eu

simina.rendler@altom.ro

Traducător: Roxana Elena roxana.elena@todaysoftmag.com Editor startups: Mircea Vădan mircea.vadan@todaysoftmag.com

ctimofti@sdl.com

tiberiu.nagy@betfair.com

Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Contabil : Delia Coman delia.coman@todaysoftmag.com

cristinajuc@gmail.com

tudor.lapusan@telenav.com

Tipar realizat de Daisler Print House Produs de

Today Software Solutions SRL str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com

www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag

Diana.Balan@accesa.eu

diana.muntea@yardi.com

vasile.mihali@arobs.com

vasile.pop@intel.com

ISSN 2284 – 6352 ioanaa@imprezzio.com Business Analyst @ Imprezzio Global

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

QA Officer @ ISDC

Sebastian Botiș

Virgil Andreies

Delivery Manager @ Endava

Associate IT Consultant @ msg systems România

Sebastian.Botis@endava.com

Copyright Today Software Magazine

vasile.selegean@isdc.eu

virgil.andreies@msg-systems.com

Sergiu Indrie

sergiu-mircea.indrie@hp.com Software Engineer @ HP

www.todaysoftmag.ro www.todaysoftmag.com

www.todaysoftmag.ro | nr. 33/martie, 2015

5

business

A

Interviu cu Jonathan Shieber, senior editor la TechCrunch și CrunchBase

m avut ocazia să povestim cu Jonathan Shieber în cadrul unui workshop organizat în Cluj la începutul luni martie. Cei din zona startup-urilor, interesați să își exerseze pitch-ul, au avut ocazia să o facă și să primească sfaturi direct de la acesta. Așa cum ne-am așteptat, nu există o rețetă a succesului dar este important să se aibă în vedere esențialul și factorii de diferențiere a produsului fie că vorbim de o prezentare sau de publicarea unui articol în TechCrunch. În continuare vă prezentăm un scurt interviu cu Jon despre tendințele actuale.

Apple Watch va fi disponibil în curând; care este perspectiva ta asupra evoluției sale, dacă ne gândim la limitările sale actuale precum bateria de o zi, dependența de un iPhone, noile versiuni care îl vor face depășit versus ceasurile clasice?

[Jon] Chiar nu sunt persoana cea mai potrivită pentru a formula o părere în legătură cu iWatch de la Apple. Nu este punctul meu forte. Dar critica împotriva iWatch care spune că este ceva inutil mi se pare corectă. Nu văd o aplicație killer care m-ar putea convinge să îmi iau unul, dar aceasta a fost și critica inițială împotriva tabletei.

De fiecare dată când Apple lansează un nou dispozitiv în ecosistem, oamenii pun la îndoială utilitatea sa, și de fiecare dată acesta devine, în cele din urmă, standardul implicit de aur în categoria sa. Acesta este unul dintre acele cazuri în care este mai Dacă există reporteri pe care îi respectați, bine să așteptăm și să vedem. lăsați-le câteva rânduri și arătați-le asta.

Dacă oamenii observă cum ne facem Drept redactor șef la TechCrunch, ți se datoria, atunci este mai probabil ca și noi trimit noutăți, iar interesul pentru aceasta să observăm ceea ce fac ei. este foarte mare. Ce sfat ai da unei persoane care are un startup și dorește să publice un Este TechCrunch implicat activ într-un articol în TechCrunch? Vreun eveniment accelerator startup prin CrunchBase? important la care ar trebui să participe?

[Jon] TechCrunch nu este afiliat la [Jon] Am atins acest subiect în cadrul niciun accelerator sau incubator. Există discuțiilor la masa rotundă. Fiți conciși, un fond inițiat de către fondatorul descrieți punctul dureros pe care îl rezolvă TechCrunch, Michael Arrington, numit tehnologia companiei, menționați nou- CrunchFund, dar nu sunt sigur care tatea într-o propoziție, vorbiți despre este relația dintre acel fond de investiții dimensiunea potențială a oportunității și TechCrunch (dintr-o perspectivă de piață și cercetați cine este reporterul instituțională). potrivit pe care să îl contactați. Odată ce un antreprenor identifică reporterii potriviți pentru știrile pe care le anunță, ar trebui să fie stăruitor în contactarea acelor persoane. Începeți procesul din timp.

6

nr. 33/martie, 2015 | www.todaysoftmag.ro

Care este opinia ta sinceră în legătură cu startup-urile din România?

[Jon] Talentul este abundent în România. Am întâlnit mai mulți antreprenori pasionați care caută să înfăptuiască idei interesante, dar ecosistemul este destul de tânăr în România și foarte imatur.

Există o nevoie clară de mai mult capital și mai mult talent operațional cu experiență în dezvoltarea afacerilor.

Ovidiu Măţan

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

TODAY SOFTWARE MAGAZINE

eveniment

Lansarea Different Angle - primul Cluster de IT & C din București

2

6 martie 2015, Sky Tower, București - Lansarea oficială a primului Cluster de IT&C din București, Different Angle, coincide și cu anunțarea primului domeniu de interes comun promovat de membrii noii organizații: Smart Cities. Pornind de la premisa că orașele moderne, inteligente sunt capabile să asigure un mediu confortabil și sustenabil pentru locuitorii lor prin utilizarea eficientă a tehnologiei disponibile, Cluster-ul Different Angle a invitat la evenimentul de lansare trei veritabili ”ambasadori” ai conceptului de Smart Cities.

Astfel, evenimentul beneficiază de prezența Prof. dr. Sorin Coțofană de la Universitatea Tehnică din Delft, Olanda; Chrysses Nicolaides - Fondator al Clusterului Smart Cities Mediterranean și Giora Levi - CEO, Alvarion.

Studiile de caz prezentate de aceștia urmăresc implementări concrete ale principiilor de bază Smart City în domenii precum: • modalitățile optime de transfer de cunoștințe, resurse și experiență între furnizorii de soluții și beneficiarii mediilor urbane; • utilizarea rețelelor wireless ca fundament al dezvoltării orașelor inteligente; • capacitatea de acțiune a Cluster-elor IT&C în context european.

Inițiat de cele unsprezece companii membre – firme de consultanță și IT&C cu mai mult de cincisprezece ani de experiență pe piață, Cluster-ul Different Angle își propune să regândească și să dinamizeze formulele tipice de colaborare.

Obiectivele pe termen mediu și lung ale Cluster-ului Different Angle constau în: eficientizarea potențialului local de IT&C, transferul de knowledge între mediul academic și mediul privat, reducerea deficitului de forță de muncă specializată în domeniul IT&C din București.

Cluster-ul Different Angle are în alcătuire următoarele companii: Econo-heat, eSolutions Grup, Evolva Trend Consultant, Gemini Solutions, GreenTree Applications, Lasper Human Development, Nemetschek România Sales&Support, Power Net Consulting, Qualitance, RezolvIT, Tremend.

Ovidiu Măţan

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

www.todaysoftmag.ro | nr. 33/martie, 2015

7

antreprenoriat

De ce să vii la Startup Weekend Cluj 2015?

S

tartup Weekend este o mișcare globală care reunește oameni cu idei, aspirații, aparținând unor medii diferite, reuniți de dorința de a se ajuta reciproc pentru atingerea unui scop comun. Evenimentele Startup Weekend ajută oamenii să-și dezvolte încrederea în potențialul lor antreprenorial și să vadă cum ideile lor prind viață aproape într-o clipită. De asemenea, creează oportunitatea de a oferi mentorat de la antreprenorii care au reușit deja și se află acolo pentru a ajuta și sfătui echipele participante. mai veche, de a crea un obicei din faptul că îți arăți aprecierea pentru oamenii din jurul tău, pentru cine sunt și pentru ceea ce fac pentru tine în fiecare zi. Eu dobândisem acest obicei, și-l foloseam în relațiile cu câțiva oameni foarte apropiați mie, însă îmi doream să găsesc o modalitate de-a face uz de tehnologie pentru a putea aduce această idee la un alt nivel. Ideile noastre s-au suprapus, și astfel a apărut ZenQ.” Cum te-ai gândit la idee/concept?

Zornitsa Tomova (ZenQ) ”Ideea s-a născut în februarie 2014, - Winner at SWCluj 2014 într-o după amiază cu soare, pe o bancă din fața Cluj Cowork, unde lucram în acea În ce stadiu vă aflați în acest moment? perioadă împreună cu Mircea, co-fondator ”După SWCluj am avut nevoie să ne ZenQ . El mi-a povestit atunci despre ideea dăm seama cum ar funcționa Employee lui de a crea o aplicatie unde fiecare are un Engagement în viața reală, și dacă această profil de personalitate, creat de către prie- unealtă pe care am gândit-o în cadrul evetenii săi, pe care îl poate folosi pentru a-și nimentului ar putea avea un impact real, descoperi punctele forte, pentru a căuta un dar și modul în care ar influența implicarea. job sau pentru a câștiga încrederea oame- Se pare că răspunsul e Da, însă noi aveam nilor care nu te cunosc personal. În acel nevoie de o cercetare cară să confirme acest moment mi-am amintit de o idee de-a mea lucru. La momentul actual lucrăm asupra Ce-a de-a patra ediție Startup Weekend Cluj va avea loc anul acesta între 24 și 26 aprilie. Am putea să îți oferim o mulțime de motive pentru care merită să participi și să iți testezi ideea, dar am decis în schimb să le întrebăm pe câștigătoarele ediției anterioare. Pentru aceasta, le-am provocat să ne răspundă la câteva întrebări. Iată câteva dintre răspunsurile lor:

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

8

nr. 33/martie, 2015 | www.todaysoftmag.ro

acestui aspect. Ne-a luat foarte mult timp, pentru că Engagement-ul este un domeniu relativ nou, respectiv, cercetările încă nu ne pot oferi răspunsuri clare.”

A n ton i a O n a c a ( E n g a g e m e n t Management) - Winner at SWCluj 2014

3. Numește unele dintre cele mai mari greșeli pe care le-ai făcut în startup-ul tău până acum.

”Nu m-am mișcat suficient de repede, nu am păstrat legătura cu toți oamenii minunați pe care i-am cunoscut în timpul evenimentului și faptul că n-am profitat de toate oportunitățile care mi-au ieșit în cale.”

Mara Steiu (Teentrepreneur) - Winner at SWCluj 2014

TODAY SOFTWARE MAGAZINE

În prezent lucrezi împreună cu oamenii pe care i-ai cunoscut la SWCluj?

gândul că ești deja câștigător. În felul acesta vei putea avea parte și de distracție.” ”Dacă e să vorbim despre echipa actuZornitsa Tomova (ZenQ) ală, răspunsul este nu. Însă dacă e să - Winner at SW 2014 considerăm mentorii renumiți și inspiratori pe care am avut ocazia să-i cunoaștem Care este cea mai memorabilă atunci, răspunsul este da.” experiență pe care ai trăit-o la SWCluj?

Mara Steiu (Teentrepreneur) ”Șocul de-a cunoaște și de a interacționa - Winner at SWCluj 2014 cu toți acei oameni minunați, într-o perioadă de timp foarte scurtă, în timp ce Dacă ar fi să vii la ediția de anul acesta, aveam de lucru la proiect!” ce-ai face diferit față de anul trecut? Ce Mara Steiu (Teentrepreneur) - Winner sfat ai putea oferi participanților de anul at SWCluj 2014

finalul lunii martie este valabilă oferta ”Early Bird”. Poți și tu să fii câștigătorul ediției din acest an, tot ce trebuie să faci este să îți cumperi un bilet și să vii cu o idee. Poate anul viitor tu vei fi cel căruia îi vom lua un interviu?

acesta?

”Nu aș face nimic diferit. Mă consider Pentru a citi interviurile complete, poți norocoasă pentru felul în care au decurs intra pe blogul Startup Weekend Cluj: lucrurile. Singurul sfat pe care l-aș oferi cluj.startupweekend.org/blog/ este acesta: du-te la Startup Weekend nu doar pentru ca să te distrezi. Mergi acolo cu Este de menționat faptul că până la

Cristina Juc

cristinajuc@gmail.com Organizatoare @ Startup Weekend Cluj

Our core competencies include:

Product Strategy

Product Development

Product Support

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

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

www.3pillarglobal.com

www.todaysoftmag.ro | nr. 33/martie, 2015

9

antreprenoriat

MVP Academy prezintă cele 13 startup-uri admise în programul de pre-accelerare

B

ucurești, 18 martie 2015 – 13 startup-uri tech cu potențial la scară globală au fost selecționate pentru a participa la cea de a doua ediție a programului de preaccelerare MVP Academy. În perioada 23 martie – 14 mai, acestea vor lucra la dezvoltarea produselor și vor forma conexiuni valoroase în industrie participând la workshop-uri practice, sesiuni de mentorat și la alte activități specifice. Lista completă a echipelor finaliste este disponibilă online pe site-ul programului http://bit.ly/MVPClassof2015.

Cele 13 echipe finaliste ale programului de preaccelerare MVP Academy dezvoltă produse în domenii precum securitate, comerț online, comerț mobile, analytics sau fashion tech și s-au remarcat prin experiența lor. Astfel, majoritatea startup-urilor au înființat anterior alte companii sau sunt formate din profesioniști care au dezvoltat diferite inițiative în tehnologie de-a lungul timpului.

Selecția finaliștilor a fost realizată luând în considerare echipa și experiența acesteia, dimensiunea și tendințele actuale ale pieței, validarea utilizatorilor și costul de achiziție, tracțiunea inițială, scalabilitatea și fezabilitatea produsului. Din juriu au făcut parte Bogdan Iordache (Investment Manager, 3TS Capital Partners & Board Member, How to Web & TechHub Bucharest), Cosmin Ochișor (Business Development Manager, hub:raum, care a evaluat startup-urile din partea hub:raum și Telekom Romania) și Alex Negrea (Co-Fondator, docTrackr).

Startup-urile care vor participa la cea de-a doua ediție a programului de preaccelerare MVP Academy sunt: 1. Accelerole: software de management care ajută freeancer-ii și agențiile să își structureze sistemele de tarifare orară și să își gestioneze mai bine procesele interne; 2. Catwalk15: aplicație mobilă care ajută utilizatorii să

10

nr. 33/martie, 2015 | www.todaysoftmag.ro

primească sfaturi vestimentare și să se inspire; 3. Clepsisoft CyberFog: soluție proactivă de securitate care deviază atacurile cibernetice; 4. CloudHero: platformă de management și raportare care permite companiilor și persoanelor să își gestioneze mai bine infrastructura digitală și să controleze costurile; 5. Conversion Network: software de marketing integrat care permite marketer-ilor afiliați să își dezvolte și scaleze afacerile fără efort, cu rezultate mai bune; 6. InnerTrends: soluție de web analitics care ajută aplicațiile web și site-urile de ecommerce să monitorizeze activitatea clienților.

7. MyDog.xyz: platformă care pune în legătură stăpânii de câini cu furnizorii de servicii și proprietarii de parcuri canine; 8. SafeDrive: aplicație mobilă care îmbunătățește siguranța traficului răsplătind șoferii care nu utilizează telefonul la volan cu puncte care pot fi apoi convertite în produse și servicii; 9. Seeds: platformă integrată pentru realizarea de chestionare, adresată celor care gestionează un volum mare de date; 10. Squady: platformă care ajută utilizatorii să descopere, să creeze și să se alăture activităților sociale într-o manieră

TODAY SOFTWARE MAGAZINE simplă și intuitivă; 11. Swapr: aplicație mobilă care ajută femeile să facă schimb de haine în funcție de locație și preferințele vestimentare ale acestora; 12. SwipeTapSell: aplicație care îmbunătățește experiența cumpărătorilor de pe dispozitive mobile și tablete, ajutând astfel magazinele online să interacționeze cu clienții lor și să își mărească rata de conversie; 13. Unloq: software care propune o nouă modalitate de autentificare și autorizare a tranzacțiilor care înlocuiește parolele cu dispozitive, oferind astfel utilizatorilor mai multă siguranță, simplu și gratuit;

să demareze discuții pentru a încheia noi runde de finanțare sau parteneriate strategice.

MVP Academy este un program realizat în parteneriat cu Telekom Romania & Bitdefender, cu sprijinul CyberGhost, Raiffeisen Bank, hub:raum și Microsoft. Mediatizarea programului este asigurată de F6S, Netocratic, CrunchBase, Entrepreneur Global, Digjitale, Entrepreneur.bg, Newtrend.bg, Startup Date, Traction Tribe, Times New Roman, Hotnews, Capital, Evenimentul Zilei, România Liberă, Academia Cațavencu, Yoda. ro, Incont.ro, Wall-Street.ro, Forbes România, Business24, Ziare. com, Business Review, Computer Games, Comunicații Mobile, Computer World, PC World, Agora, Business Cover, Business Woman, Zelist.ro, Comunicatedepresa.ro, Trade Ads Interactive, MVP Academy este un program organizat în parteneriat Gadget Trends, Games Arena, Gadget Talk, Softlead, Today cu Telekom România & Bitdefender, cu sprijinul CyberGhost, Software Magazine, startups.ro și IQAds. Raiffeisen Bank, hub:raum și Microsoft. În perioada 23 martie – 14 mai, cele 13 echipe finaliste vor trece printr-un proces de MVP Academy se bucură de susținerea comunităților preaccelerare complex, adaptat pentru a corespunde nevoilor lor partenere Romanian Startups, Romanian Game Developers specifice, vor lucra la dezvoltarea produsului și vor învăța cum Association (RGDA), Softbinator, ANIS, Cluj Hub, Cluj Co-Work, să acceseze oportunitățile existente pe piața globală. Toate aces- Professional Gamers League, Tabăra de testare, comunitatea frontea participând la workshop-uri practice, sesiuni de mentorat și tend din România, Akcees, Startup Weekend România, Startup coaching 1 la 1, pitching practice și alte activități dedicate.

Weekend Târgu Mureș, Startup Weekend Cluj, Girls in Tech Pe parcursul celor șapte săptămâni ale programului, startup- România și Girls Who Code. urile vor avea ocazia să dezvolte conexiuni valoroase cu mentori cunoscuți și lideri din industrie, printre care se numără Jon Bradford (Managing Director, Techstars UK), Mike Butcher Irina Scarlat irina.scarlat@howtoweb.co (Senior Editor, TechCrunch Europe), Alex Barrera (Co-Fondator, Tech.eu & Press42), Ivan Brezak Brkan (Editor, Netokracija), PR Manager @ How to Web & Olaf Lausen (Chief of CEO Staff & Business Development TechHub Bucharest Director, Telekom Romania) sau Florin Talpeș (CEO și Fondator, Bitdefender). Lista completă a mentorilor este disponibilă online la http://bit.ly/MVPmentors, iar aceasta va fi actualizată periodic în funcție de nevoile specifice ale echipelor participante. În plus, echipele vor discuta cu reprezentanți ai unora dintre cele mai cunoscute programe de accelerare la nivel internațional (Techstars, Startupbootcamp, Startup Wiseguys, Ignite 100 sau LAUNCHub), cu investitori de tip angel și fonduri de investiții early stage active în regiune (Early Bird, 3TS Capital Partners).

Programul de preaccelerare MVP Academy se va încheia joi, 14 mai, cu Demo Day, eveniment în cadrul căruia startup-urile participante își vor prezenta produsele și progresul înregistrat în fața audienței formate din investitori și lideri ai comunității profesioniștilor în tehnologie la nivel regional, având astfel ocazia

www.todaysoftmag.ro | nr. 33/martie, 2015

11

eveniment

Alt-tester la Mobile World Congress 2015

M

obile World Congress este evenimentul de anvergură al industriei tehnologiilor mobile. Un târg uriaș, lansări mult așteptate, conferințe și seminarii extraordinare, networking intens. Ce face la un asemenea eveniment o companie specializată în servicii de testare și, mai ales, de ce duce de mânuță un roboțel?

La unul dintre standurile din pavilionul Poloniei participanții la MWC15 puteau câștiga premii răspunzând la întrebări din domeniul tehnologiei informațiilor. „În ce an a avut loc prima ediție a CeBIT?” a fost una dintre întrebările la care am greșit, presupunând că un eveniment de acest tip nu poate fi mai vechi de 1987. Răspunsul corect este: CeBIT se desfășoară din 1970. Și atunci m-am întors la pagina web a evenimentului la care mă aflam ca să descopăr că nici Mobile World Congress nu e un eveniment chiar tânăr, ci dăinuie încă din 1987. Și uitându-mă în jur, constatam că nici mic nu este, din ce vedeam ca număr de participanți în stațiile de metrou din Barcelona -mulți purtam ostentativ ecusoanele, în pofida recomandărilor de securitate-, în locurile din Fira Gran Via amenajate pentru socializare și, în definitiv, în orice spațiu dedicat sau folosit pentru a ajunge la târg. Mulțimea aceasta de oameni a dat în statisticile organizatorilor un număr de peste 92 000 de participanți din peste 200 de țări.

De ce atât interes? Prin lentilele mele de tester/expozant/utilizator-de-smartphone, am zărit câteva motive pentru care cei care lucrează în IT ar vrea să meargă la MWC, dincolo de faptul că e în Barcelona lui Gaudí, în ținutul tapas-urilor și al sangriei. În primul rând, Mobile World Congress este locul lansărilor spectaculoase de

12

tehnologii, servicii și echipamente mobile.

Samsung a organizat aici primul lor eveniment de tip Unpacked din 2015 în cadrul căruia a lansat Galaxy S6 și Galaxy S6 Edge.

HTC a venit cu telefonul One M9, brățara Grip pentru monitorizarea activității fizice și o pereche de ochelari-înspre-căști pentru realitatea virtuală, Vive. LG a lansat ceasurile inteligente Urban, unul dintre ele pe un nou sistem de operare bazat pe WebOS. Pe lângă ei, cu siguranță nu mai puțin vizitate, în special de presă, au fost Microsoft, Lenovo, Acer, Huawei, Sony.

Să ai posibilitatea să explorezi în premieră astfel de device-uri la scurt timp după ce au fost lansate și să poți să discuți despre ele cu reprezentanții producătorului este o oportunitate pentru pasionații de gadgeturi, pentru trendsetter-ii din IT sau pentru cei care dezvoltă aplicații pe astfel de echipamente. Și pot spune că mulți au fructificat această oportunitate, dată fiind mișcarea browniană permanentă din spațiul dedicat acestor giganți de-a lungul întregului eveniment.

O altă componentă care atrage participanți numeroși la MWC este cea a conferințelor și seminariilor. Anul acesta au fost peste 40 de sesiuni susținute de reprezentanți din așa numitele poziții „de tip C” (CEO, CIO, CTO, CMO, COO) ale unor companii ca Deutsche Telekom, Ericsson, Huawei, Mozilla, SAP sau Wikipedia. Sesiunea cea mai așteptată pare să fi fost cea a lui Mark Zuckerberg, care a continuat saga despre Internet.org (poveste începută la MWC14), insistând acum pe provocările pe care Facebook le are în a coordona furnizorii de servicii în demersul de a asigura Internet în țările în curs de dezvoltare. Pe cât de incitantă suna din descriere prezentarea lui Mark, pe atât de dezamăgiți se pare că au fost unii participanți.

nr. 33/martie, 2015 | www.todaysoftmag.ro

După ce scoatem marile lansări și mult așteptatele conferințe, din MWC15 mai rămân doar 1 900 de expozanți distribuiți în 5 hale, fiecare din ele ca un mall de dimensiuni decente, distribuit pe orizontală. Nu exagerez când zic că în ghidul participantului neinițiat în ale târgurilor ar trebui să se insiste pe importanța încălțămintei cât mai comode. Ce presupune un târg al tehnologiei mobile? Fizic, pe suprafața acelor hale, multe standuri și pavilioane. De la standuri de tip „rafturi într-un dressing”, la pavilioane colorate, sonore sau animate (și de animatoare, da, sau de tot soiul de elemente dinamice), în care s-au investit fonduri europene sau pentru care au fost alocate bugete de marketing. Expozanții au folosit spațiul de care dispuneau fie mai sobru, rezumânduse în unele cazuri la slide-uri și broșuri cu serviciile sau produsele oferite, fie mai spectaculos: prezentări, demonstrații ale aplicațiilor sau ale device-urilor în acțiune, roboței circulând de colo până colo, echipamente sportive pe care să faci mișcare în timp ce testezi un wearable; o dansatoare de Flamenco, un barista alături de reprezentantul de vânzări pregătit să prezinte oferta sau să povestească cu tine, palmieri nefericit aleși, un autoturism parcat pe acolo să demonstreze cum comanzi pizza de la volan. Toate pentru a-i determina pe trecători să se oprească la stand, să încerce produsul sau serviciul, să ia materiale promoționale, să ceară o carte de vizită sau să inițieze un parteneriat de afaceri.

TODAY SOFTWARE MAGAZINE Dincolo de simpla nagivare din stand în stand, oportunitățile de a găsi noi parteneri de afaceri sunt mai variate. O astfel de nevoie nu a rămas neabordată, astfel că există ofertă de servicii de căutare și conectare la companii care pot răspunde nevoilor unei afaceri – servicii de B2B Matchmaking. Aceste servicii sunt oferite de firme specializate, dar am aflat că unele țări participante au reprezentanți oficiali care se ocupă de promovarea firmelor proprii printre ceilalți expozanți. Astfel, mulți participanți merg la MWC cu o agendă de întâlniri planificată din timp.

Sibiu).

Altap… se mișcă!

Altom s-a prezentat la MWC15 cu Altap. Printre altomi el e cunoscut sub numele de cod intern Măgăoaia, pentru a nu uita de dimensiunea lui inițială; sau Miska, la fel, pentru a nu pierde din memoria colectivă internă momentul emblematic din cadrul primului demo în care… s-a mișcat.

imaginilor și efortul colectiv al Altomilor pentru designul testelor automate, asamblarea și prezentarea roboțelului. Și alegerea numelui, să nu uităm. Legat de partea hardware, în speță imprimarea 3D a componentelor, am avut parte de ajutorul lui Alexandru Popescu, doctorand la Universitatea Tehnică Cluj Napoca.

RomaniaIT. Creative Talent, Technical Excellence

Patrusprezece companii din România au avut standuri la Mobile World Congress anul acesta. Asociația Română pentru Industria Electronică și Software Timișoara (ARIES-TM) cu sprijinul Ministerului Economiei facilitează prezența firmelor la MWC, în demersul de a schimba percepția asupra pieței IT românești de la companii de outsourcing la companii inovatoare.

Sprijinul pentru expozanți este de natură financiară și acoperă și unele aspecte logistice. Iar pentru a beneficia de el două criterii trebuie îndeplinite: primul susține centrarea pe inovație, astfel că la târg ajung firmele care prezintă servicii sau produse inedite; al doilea, mai pragmatic, este lipsa datoriilor către bugetele de stat.

Astfel, la pavilionul României vizitatorii au putut vedea modelele noi ale telefonului Allview, oferte de soluții informatice în domenii dintre cele mai comune, dar care ameliorează existența cotidiană, precum simularea unui examen auto (la standul Dapredi Soft Systems din Timișoara) , monitorizarea flotelor auto (la colegii de la Arobs Transilvania), aplicații educaționale (la Sphinx IT din Timisoara) sau din domeniul medical (Ropardo din

Dincolo de complexitatea onomastică, Altap este un roboțel integrat într-o soluție de executare a testelor automate pe telefoane sau tablete. Sau pe ceasuri inteligente, cum ne-a sugerat unul dintre vizitatorii de la stand. El extinde capacitățile date de framework-urile de testare automată și realizează acțiuni pe care nu le putem efectua programatic.

Demonstrația de la MWC15 a fost a unui test scris în Appium și executat pe un iPad. Prin test verificam mesajul de eroare la login în aplicația Wordpress, atunci când setarea de Wifi era off. Dacă cele mai multe dintre acțiuni și verificări le putem realiza din Appium, pasul de comutare a opțiunii Wifi în starea off nu se poate realiza programatic; aici intervine Altap, care prin brațul mobil dotat cu stilou digital execută acțiunea pe care în mod normal un tester ar trebui să o realizeze manual.

Astfel, scripturile de testare care presupun interacțiunea cu un sistem de operare mai puțin permisiv, precum iOS, pot fi rulate fără întreruperi pentru acțiuni manuale.

Dincolo de dinamica dată la standul nostru, pentru vizitatori roboțelul a funcționat ca un exemplu al soluțiilor cu care venim pentru probleme de testare. „Agățați” de brațul lui Altap, am putut povesti cu ei despre viziunea noastră și modul în care abordăm testarea, despre serviciile de consultanță și cursurile pe care le organizăm pentru testeri.

Altap înglobează munca lui Bogdan Birnicu, colegul nostru, pentru proiectul de licență, soluția colegei noastre Ru pentru problema de recunoaștere a

Alt-tester la MWC

Fără a fi o promotoare în materie de device-uri și tehnologii mobile, ci doar o utilizatoare de smartphone și tester al unei aplicații mobile, eu m-am bucurat de participarea la MWC15 cât să o cataloghez drept cea mai faină experiență profesională de până acum. Pe de-o parte, plimbându-mă pe la celelalte standuri, am avut ocazia să discut cu profesioniști din domenii conexe, dar variate, despre produse, servicii, probleme întâmpinate; despre tendințele de pe piața tehnologiilor mobile, despre ce provocări aduc ele și cum am putea să le răspundem. Le-am urmărit structura prezentărilor, cum răspund la întrebări dificile, cum își promovează compania și cum își vând serviciile sau produsele. Și am explorat în premieră echipamente și dispozitive pe care probabil voi testa în viitor. Din partea cealaltă, cea de la standul nostru, am avut posibilitatea să discutăm despre provocările pe care le întâmpină dezvoltatorii de aplicații, managerii proiectelor IT sau oamenii de business în legătură cu testarea aplicațiilor. Acesta a fost un exercițiu excelent de a răspunde unor probleme de testare și de a înțelege mai bine ce nevoi au beneficiarii muncii noastre. Cumulat, a rezultat o experiență inedită de formare în materie de customer awareness despre care îmi face plăcere să povestesc. Deci, întrebați-mă despre ea.

Simina Rendler

simina.rendler@altom.ro Software Tester @ Altom Consulting

www.todaysoftmag.ro | nr. 33/martie, 2015

13

comunități

Comunităţi IT

A

șa cum menționam în editorial am avut parte în luna martie de două evenimente importante: ..even mammoths can be Agile și Cluj Innovation Days. În luna aprilie va avea loc Startup Weekend, un important eveniment dedicat creării de startup-uri. Salutăm de asemenea inițiativa grupului meetup Big Data pentru organizarea BigData Romanian Tour : Cluj-Timișoara-Bucu­rești.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

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

Websites: www.facebook.com/todaysoftmag www.meetup.com/todaysoftmag

www.youtube.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 2215/Nr. Evenimente: 30 Cluj Business Analysts Comunitate dedicată analizei de business Website: www.meetup.com/Business-Analysts-Cluj Data înfiinţării: 10.07.2013 / Nr. Membri: 91 / Nr. Evenimente: 8 Cluj Mobile Developers Comunitate dedicată tehnologiilor mobile Website: www.meetup.com/Cluj-Mobile-Developers Data înfiinţării: 05.08.2011 / Nr. Membri: 264 / Nr. Evenimente: 17 The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software.

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

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

Website: www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 251/ Nr. Evenimente: 14 Tabăra de testare Comunitate formată din testeri și alți profesioniști din industria IT care, în cadrul unor întâlniri informale lunare, împărtășesc din cunoștințele proprii și învață din experiențele profesionale ale celorlalți membri.

Website: www.tabaradetestare.ro Data înfiinţării: 15.01.2012/Nr. Membri: 1243/ Nr. Evenimente: 107

14

nr. 33/martie, 2015 | www.todaysoftmag.ro

Calendar Martie 24 (Cluj) Lansarea numărului 33 al Today Software Magazine www.todaysoftmag.ro Martie 24 (Timișoara) Timisoara WordPress March Meetup meetup.com/Timisoara-WordPress-Meetup/ events/220966568/ Martie 25 (Iași) Enki.js (what I learned building a web framework) meetup.com/Iasi-JS/events/221279113/ Martie 26 (Timișoara) TdT#29 - the Testing Map by Claudiu Draghia m e e t u p . c o m / Ta b a r a - d e - Te s t a r e - T i m i s o a r a / events/220453273/ Martie 26 (Brașov) Flying Penguins: Embedded Linux Applications for Autonomous UAVs meetup.com/bv-tech/events/219375757/ Martie 27 (Cluj) BigData Romanian Tour : Cluj-Timisoara-Bucu­resti me etup.com/Big-D at a-D at a-S cience-Me etup -Cluj-Napoca/events/220876181/ Martie 31(București) Mobile Advertising Congress conference-arena.com/mobile-advertising-congress Aprilie 1 (București) April BucharestJS Meetup meetup.com/BucharestJS/events/221195509/ Aprilie 14 (Cluj) UI/UX Cluj Meetup (open call4speakers) meetup.com/UXUICluj/events/220935531/ Aprilie 24 (Cluj) Cluj Startup Weekend - recomandat de TSM cluj.startupweekend.org/

programare

Realitatea virtuală îmbunătățită pe dispozitivele mobile

R

Alexandru Fediuc

alexandru.fediuc@msg-systems.com Associate IT Consultant @ msg systems România

Virgil Andreies

virgil.andreies@msg-systems.com Associate IT Consultant @ msg systems România

ealitatea augmentată a intrat în interesul consumatorilor, și bineînțeles și în cel al programatorilor, odată cu dezvoltarea procesoarelor și a plăcilor grafice pe dispozitivele mobile. Însă unul dintre primele dispozitive care s-a folosit de ideea din spatele acestei tehnologii a fost Sensorama, creată de Morton Heilig, acum mai bine de 40 de ani. Dispozitivul funcționa pe principii asemănătoare dar cu un mod de implementare mai „rudimentar”. Ceea ce a făcut cunoscută realitatea augmentată este apariția binecunoscutului Google Glass, iar cel care a reușit să împingă barierele mai departe este dispozitivul patentat de Microsoft, Kinect împreună cu căștile virtuale. Nu voi insista pe aceste subiecte, ele făcând parte din altă categorie, pe care aș numi-o „încă experimentală”. Totuși aceste „push”-uri tehnologice au făcut posibilă apariția Realității Augmentate (AR) și pe dispozitivele mobile.

Acum, chiar și un programator novice poate realiza o astfel de aplicație cu ajutorul unor SDKuri puternice puse la discreția oricui.

AR este un mod de a augmenta elementele fizice prin suprapunerea acestora cu conținut digital. Pentru dispozitivele mobile, aplicațiile se folosesc de diverși senzori ai acestuia precum GPS-ul, camera video sau microfonul. Industria cea mai „afectată” de acest trend este cea de gaming, venind puternic din urmă și cea retail; însă din ce în ce mai multe domenii găsesc realității augmentate o utilizare. Fie că sunt aplicații de e-learning, care pot identifica texte, logouri sau alte artificii grafice sau aplicații care îți pot spune informații doar poziționând camera în fața unui monument istoric, dovedesc faptul că această tehnologie prinde deja contur.

AR-ul creează o legătura între utilizator, mediul înconjurător și lumea virtuală.

Tehnica AR-ul este aceea de a atașa, de a fixa, elementelor reale imaginii 3D sau 2D prin așa numiții „markers”. Un exemplu de marker vizual este un cititor de bare 2D. De asemenea, în AR sunt folosiți numeroși senzori precum cei de mișcare și urmărire, senzori de recunoaștere sau analiza a imaginilor, a gesturilor și de cele mai multe ori GPS-ul.

Metode de tracking

Pentru ca aplicația să știe unde anume ești și la ce anume te uiți (locația și orientarea camerei) este nevoie o cameră video calibrată. Sistemul prin care este calculată locația și orientarea relativă a acesteia se numește tracking. Acesta este unul dintre fundamentele realității augmentate. Pentru a transpune însă un obiect virtual, în mod corect, în realitate este nevoie de ceva în plus, iar acesta este un marker. Rolul lui este a defini mărimea obiectului virtual precum și de a recunoaște orientarea camerei video. Un marker bun este un marker ușor de detectat în orice circumstanțe, așa cum sunt cei bazați pe diferențe de luminozitate și nu cei bazați pe variațiuni de culoare, ce pot deveni greu de interpretat datorită variației de lumină.

Multe dintre sistemele de marker se folosesc de pătrate alb-negru pentru a realiza o diferențiere evidentă între markers și nonmarkers. Markerele pot fi de mai multe feluri: • template markers – în care potrivirea se face cu ajutorul unui șablon alb-negru.

Este indicat să se folosească o imagine clar

www.todaysoftmag.ro | nr. 33/martie, 2015

15

programare Realitatea virtuala îmbunătățită pe dispozitivele mobile definită, încadrată de un chenar.

• codurile de bare – formate în majoritatea cazurilor din celule alb-negre încadrate de un chenar sau ce vin împreună cu niște repere grafice.

• Markere imperceptibile – imagini, markere infraroșii, miniaturi (markere imposibil de detectat de ochiul uman).

oferind multe instrumente în această direcție.

Metaio

O altă platformă la modă și foarte ușor de folosit este Metaio.

Ca și celelalte SDK-uri menționate mai sus, și aceasta acordă suport pentru majoritatea metodelor de tracking cunoscute: markeri, modele 3D, image target etc.. Importanți agenți economici au apelat la această platformă în dezvoltarea unor aplicații de succes: Ikea, Lego, Audi. Dar Metaio nu oferă instrumente de tipul „Code Once„ , de aceea e nevoie de a programa separat pentru iOS și Android. Metaio prezintă mult potențial, însă faptul că trebuie să plătești pentru a folosi framework-ul și existența unei documentații destul de slab realizată ține mulți potențiali programatori la distanță.

Un alt mod de tracking este cel bazat pe model. Acest sistem constă în compararea unui model digital cu un obiect real din cadrul unei scene. Acest concept se bazează pe analiza secvențială a unei scene vizuale și oferirea unor descrieri conceptuale a evenimentelor ce au loc într-însa. Pentru a înțelege mai bine acest sistem propun următorul scenariu: O stradă pe care circulă zilnic mașini si o cameră de filmat deasupra acesteia. E nevoie în primul rând de separarea elementelor statice de cele dinamice, mai conchis spus, segmentarea mișcării. Urmează crearea unor modele Crearea unei aplicații de “Augmented Reality” utigeometrice 3D care să se suprapună pe cât mai multe categorii de lizând motorul Unity3D și extensia Vuforia pentru mașini și crearea unui model de mișcare al mașinii în contrast cu Unity șoseaua statică. Astfel se poate crea o scenă în care mașinile sunt scoase din context și devin obiectul de interes.

Unity 3D

Frameworks

Există deja pe piață mai multe librării care vin în ajutorul programatorilor oferindu-le posibilitatea de a investi timpul lor mai mult în conceperea produsului și a ideii software decât în algoritmii necesari creării markerilor și folosirii diverșilor senzori ai unui dispozitiv mobil. Majoritatea acestor framework-uri sunt cross-platform, adică se pot folosi pe mai multe device-uri și sisteme. Dintre toate acestea, trei SDK-uri mi-au captat atenția și merită precizate.

Vuforia

Platforma celor de la Qualcomm oferă o gamă mare de suport pentru diverse sisteme având astfel posibilitatea de a scrie o aplicație nativă și de a o face disponibilă pe o marjă mare de device-uri. Utilizează tehnologie bazată pe Computer Vision pentru recunoașterea și urmărirea (tracking) imaginilor planare (Image Targets) și a obiectelor 3D simple, precum obiecte cuboide sau sfere, în timp real. Ca avantaje, este de menționat faptul că este o librărie gratuită ce oferă suport pentru iOS, android și Unity 3D. Obiectele 3D pot fi create și prin intermediul codului, suportă multi-tag, extended tracking (când markerul nu mai este existent în cadrul filmat) și face-tracking și nu în ultimul rând funcționează foarte bine cu motorul grafic NinivehGL. De asemenea, trackingul este mult mai stabil față de celelalte platforme.

Faptul că nu are interfață grafică, că dezvoltarea unei aplicații e mai greoaie până te deprinzi cu platforma și că va trebui să scrii cod separat pentru sisteme (acest lucru însă poate fi rezolvat o dată ce o integrezi cu Unity 3D) se numără printre dezavantaje.

D’Fusion

Pachetul celor de la Total Immersion deține o gamă mare de suport pentru majoritatea device-urilor. Are o interfață grafică destul de bună în care ai posibilitatea să creezi întregul scenariu. Partea de programare se realizează în LUA, iar librăriile de android și iPhone sunt deja precompilate, aplicațiile realizate în D’Fusion fiind independente de sistemul de operare. Oferă suport pentru Unity 3D și este compatibil cu fișiere din Maya sau Blender. Platforma de dezvoltare D’Fusion Studio poate fi descărcată gratuit. D’Fusion este orientat mai mult pe partea de retail,

16

nr. 33/martie, 2015 | www.todaysoftmag.ro

Ce este Unity 3D ?

Unity 3D reprezintă un motor 3D extrem de puternic precum și un mediu de dezvoltare de aplicații interactive extreme de “user friendly”. Acesta are avantajul de a fi foarte ușor de folosit, atât de persoane care nu au cunoștințe solide de programare, cât și de cei experimentați. Un alt beneficiu reprezintă faptul că Unity Technologies oferă două variante pentru dezvoltatori, cea gratuită și varianta Pro pentru care utilizatorul este nevoit să plătească.

Varianta Pro oferă mai multe feature-uri și unelte contra sumei de 1500$. Acest preț este însă pe deplin justificat având în vedere cât de permisivă este licența de publicare Unity. Pentru început, versiunea gratuită ar trebui să fie îndeajuns. O scurtă comparație între cele două versiuni poate fi găsită la adresa http://unity3d. com/unity/licenses , precum și locul de descărcare al versiunii gratuite.

Caracteristici generale Motorul se folosește de trei limbaje de programare: C#, Boo și Unity JavaScript și poate fi folosit în a dezvolta aplicații pentru majoritatea sistemelor de operare, chiar și cele mobile. De asemenea, oferă posibilitatea de a lucra direct în mediul 3D, adecvat pentru a crea niveluri de joc, meniuri, animații, pentru a realiza scripturi și a le atașa obiectelor. Iar toate acestea sunt accesibile cu doar câteva click-uri, interfața grafică fiind una extrem de ușor de învățat. Un proiect Unity reprezintă un fișier simplu care conține fiecare resursă ce aparține jocului sau aplicației interactive.

Assets Assets reprezintă fiecare resursă pe care aplicația o utilizează. Așadar în “Assets” amintim modele 3D, materiale, texturi, resurse audio, scripturi, fonturi. În afară de câteva obiecte simple, considerate primitive, precum cuburi și sfere, Unity nu are posibilitatea de a crea aceste “assets”. În schimb, acestea trebuie create extern utilizând aplicații de modelare 3D și unelte grafice de pictat, urmând ca ulterior, acestea sa fie importate în Unity. Acest lucru este extrem de ușor de realizat, importarea fiind în același timp robustă și inteligentă. Unity acceptă toate formatele de fișier populare, incluzând 3D Studio Max, Blender, Maya și FilmBox păstrând materialele, texturile și “rigging”.

TODAY SOFTWARE MAGAZINE Scenele

Scenele reprezintă locațiile unde obiectele din “assets” vor fi amplasate și aranjate pentru a crea ecrane de joc. Panoul cu ierarhia reprezintă conținutul scenei curente într-un format de arbore.

Scripting Script-urile sunt cunoscute ca “behaviours”. Ele asigură manipularea și crearea de interactivitate între resurse. Acestea pot fi reutilizate pentru mai multe obiecte, atașarea lor pe resursă realizându-se într-un mod extrem de simplu. În același timp, pot fi adăugate mai multe script-uri pe același obiect de joc.

Exemplu (C#): using UnityEngine; using System.Collections; public class PlayerScript : MonoBehaviour { // Use this for initialization void Start () { } // Update is called once per frame void Update () { } }

Observație: Numele clasei trebuie să aibă același nume cu fișierul în care a fost creată.

Toate script-urile care se atașează pe obiect conțin metodele start() și update(). Metoda start() este apelată o singură dată atunci când obiectul este creat, în timp ce metoda update() este apelată o dată pe cadru. void Update () { float horizontal = Input.GetAxis(“Horizontal”); float vertical = Input.GetAxis(“Vertical”); transform.Translate(horizontal, vertical, 0); }

Acum, după ce am creat script-ul, el trebuie asignat “assetului”. Aceasta se face cu “drag-and -drop” pe obiectul de joc. Cu script-ul asignat, se poate rula jocul.

Publicarea Unity poate publica în Windows, OS X, și prin intermediul plug-in-ului Web Player. Web Player este un plug-in pentru browsere care funcționează cu toate browserele cunoscute și oferă aceeași performanță cu aplicația stand-alone pentru desktop.

Cu Unity Pro se poate publica pentru o gama mai largă de platforme, incluzând: Android, iOS, Wii, Xbox One, Xbox 360, PS3, PS4, Windows Store, Windows Phone, Flash.

Vuforia Ce trebuie să știm despre Vuforia?

Vuforia are încorporat în SDK-ul său mai multe tehnologii ce vin în ajutorul dezvoltatorilor. Printre acestea se numără și Computer Vision, tehnologie prin care dezvoltatorii pot să poziționeze și să orienteze obiectele virtuale, cum ar fi obiectele 3D în corelație cu imaginile din lumea reală când se realizează o vizionare a acestora prin intermediul camerei unor dispozitive mobile. Obiectul virtual urmărește poziția și orientația imaginii în timp real, astfel ca perspectiva utilizatorului asupra obiectului va corespunde cu perspectiva imaginii target. Așadar, obiectul virtual va apărea ca parte a scenei din lumea reală. Vuforia permite câteva variații de implementare ale realității augmentate: modelul

peste care se suprapune această lume virtuală/obiect virtual este o imagine, o țintă unică numită Image Target, ce poate fi chiar un marker oferit de Qualcomm. Vuforia oferă și posibilitatea unor ținte multiple.

SDK-ul suportă o varietate de tipuri de ținte, incluzând ținte “markerless”, configurări 3D multi-țintă, “butoane virtuale” folosind “Occlusion Detection” și posibilitatea de a crea și reconfigura mulțimi de ținte la runtime. Vuforia oferă API-uri în C++, Java, Objective-C și în limbajele .NET prin extensia la motorul Unity. În acest mod, SDK-ul realizează suport atât pentru dezvoltarea în mediu nativ Android și iOS cât și dezvoltare de aplicații AR în Unity. Acestea pot fi la fel de ușor de portat pe mai multe platforme, incluzând Android și iOS. În exemplul descris în rândurile următoare se va folosi un marker Vuforia gratuit. Obiectul 3D a fost suprapus peste imagine. Acest obiect este realizat cu un set de instrumente Blender și Photoshop. Prin altgoritmii sofisticați de Computer Vision, proprietățile imaginii sunt detectate și urmărite. Ținta ajunge să fie cunoscută prin comparații succesive ale acestor trăsături și www.todaysoftmag.ro | nr. 33/martie, 2015

17

programare Realitatea virtuala îmbunătățită pe dispozitivele mobile caracteristici cu cele ale imaginii păstrate într-o bază de date. În momentul în care ținta este recunoscută, aceasta va fi urmărită cât timp se regăsește în câmpul de vizibilitate al camerei foto/ video. Crearea țintelor necesită acces în contul utilizatorului pe site-ul Vuforia. Țintele sunt create din fișiere .jpg sau .png(RGB sau greyscale). Caracteristicile sunt păstrate într-o bază de date, fiind organizate în seturi de date.

Crearea și rularea unui exemplu - tutorial Vom descrie sumar în următoarele rânduri toți pașii (uni dintre ei pot fi desigur omiși prin abordări alternative) pentru realizarea unei aplicații de AR. Se presupune că utilizatorul are instalate versiunile compatibile de Unity și extensia Vuforia pentru Unity. În plus, acesta are nevoie de o cameră web sau camera smartphone-ului sau tabletei . De asemenea, printați pe o foaie A4 imaginea țintă după creare.

După instalarea uneltelor, va trebui să vă creați un cont pe site-ul oficial Vuforia: https://developer.vuforia.com/user Pasul următor este acela de a crea ținta (Image Target).

Navigați la aplicația web Target Manager pe portalul de developer. Această aplicație permite crearea unei baze de date cu ținte pentru a putea fi folosite pe anumite dispozitive precum și în cloud. Creați o bază de date și dați-i un nume și atribuiți-i o țintă.

După ce încărcarea țintei este completă, Vuforia execută verificările și procesările necesare. Apoi puteți descărca imaginea țintă.

Descărcați fișierul cu extensia .unitypackage care conține ținta.

Porniți Unity, creați un proiect nou și importați fișierele .unitypackage ale Vuforia (SDK-ul și imaginea țintă). Ștergeți camera principală (Main Camera) din ierarhia scenei. Importați acum modelul 3D pe care doriți să îl amplasați peste imaginea țintă. În fereastra de Project, deschideți fișierul Assets/Qualcomm Augmented Reality/Prefabs. Amplasați obiectul ARCamera în scenă. Cu acest obiect selectat, căutați în Inspector și asigurați-vă că opțiunea „Load the Data Set” cu baza dvs. de date (Imagine Țintă) și setați-o ca „Active”. Din același fișier Prefabs importați imaginea țintă în scenă. Cu imaginea selectată căutați utilizând Inspector-ul și setați „Data Set-ul” ca imagine țintă. Imaginea creată anterior ar trebui să fie vizibilă în editorul Unity. Adăugați cu drag-and-drop modelul în obiectul cu imaginea țintă din ierarhia Unity. Utilizați-vă de facilitățile, valorile și uneltele de mișcare pe axele x,y,z pentru a fixa obiectul 3D exact în centrul țintei. De aici încolo, totul depinde de creativitatea dumneavoastră. O sugestie pe care v-o putem oferi este să amplasați o sursă de lumină (directional light) din Unity care să lumineze modelul. Exemplul poate fi rulat prin butonul de „Play”. Vuforia și Unity vor detecta camera web iar Vuforia va aplica algoritmii de detecție și urmărire și va amplasa obiectul pe imaginea printată. Aplicația poate fi apoi portată cu ajutorul instrumentelor interne din Unity pentru a rula pe un dispozitiv mobil.

18

nr. 33/martie, 2015 | www.todaysoftmag.ro

De ce abia acum realitatea augmentată?

Am încercat în aceste rânduri să realizăm o imagine de ansamblu a acestei tehnologii emergente. Nu e ca și cum abia acum s-a descoperit realitatea augmentată și implicațiile acesteia în viața de zi cu zi. Însă depășirea problemele care intervin în dezvoltarea acestei tehnologii (și implicit, regăsirea ei în mai multe arii) necesită timp de dezvoltare. Aceste probleme provin din mai multe domenii: sociologic - concepția prin care vedem dispozitivele mobile tot ca un fel de PC-uri când acestea pot fi mult mai mult de atât, tehnologic – aplicațiile de tipul AR necesită procesoare grafice puternice pentru a putea suprapune obiectul/obiectele 3D în timp real fără a-l distorsiona sau întrerupe; aceasta înseamnă și consum de energie mult mai mare , user interaction – crearea unor aplicații ușor de folosit și aplicabile în viața reală. O aplicație AR trebuie să ruleze în timp real, altfel aceasta va folosi informații vechi, false. Performanța aplicațiilor AR pentru dispozitivele mobile este complet dependentă de algoritmii de optimizare deoarece puterea de procesare și memoria sunt limitate pentru acestea.

Aplicațiile AR sunt necesare în situațiile unde percepția umană poate fi perfecționată și unde utilizarea obiectelor virtuale în viața cotidiană ne pot îmbunătăți semnificativ traiul.

Aceste aplicații ne pot aduce un nou mod de a vedea și de a interacționa cu mediul înconjurător și cel virtual totodată, o realitate îmbunătățită în propriu buzunar.

programare

Introducerea și tuning-ul Hadoop MapReduce

M

apReduce este principala tehnologie de procesare de date de volum mare a proiectului Apache Hadoop. A fost dezvoltată de către Google. În 2004, ei au publicat un articol care descria conceptul MapReduce.

Tudor Lăpușan

tudor.lapusan@telenav.com Java & Big Data developer @ Telenav

În 2006, Dug Cutting a reușit să implementeze acest concept și să îl includă într-un proiect Apache, mai exact în Apache Hadoop 1. Prima lansare a avut loc în 14 Septembrie 2007.

Acesta a fost începutul Marilor Date (Big Data) pentru toată lumea, începând de la persoane pur și simplu curioase, până la toate tipurile de companii. În scurt timp, Apache Hadoop a ajuns la dimensiunea unei comunități foarte puternice, atrăgând de asemenea jucători mari precum Yahoo, Facebook, Ebay, IBM, Linkedin și alții2.

Pentru o adaptare mai ușoară a tuturor, alte tehnologii au fost dezvoltate peste MapReduce, care sunt mult mai ușor de învățat și de utilizat. Un exemplu este Apache Hive 3, care a fost dezvoltat la Facebook.

Deoarece aproape toți cei din domeniul computer science au cunoștințe SQL, Facebook a dezvoltat Hive, care le-a permis să-și interogheze și să-și analizeze seturile de date prin simpla utilizare a limbajului HiveQL, care este foarte asemănător cu SQL. Astfel, oricine din echipa Facebook, care are cunoștințe SQL, avea capacitatea de a utiliza puterea tehnologiei MapReduce.

datelor. Are două faze principale, faza Map și faza Reduce și o altă fază, Shuffle, care nu este atât de bine cunoscută, dar în unele cazuri de utilizare, poate să vă încetinească sau să vă stimuleze întreaga execuție.

Pentru majoritatea cazurilor de utilizare a prelucrării de date folosind MapReduce, faza Map străbate toate seturile de date și aplică mai multe filtre, iar faza Reduce este locul unde ne aplicăm efectiv algoritmii.

Pentr u a înțelege mai bine c um funcționează MapReduce, vă recomand să citiți mai multe despre MapReduce He l l o Wo r l d , m a i p r e c i s e x e m p l u l Wordcount 4 . Acesta ne ajută să găsim frecvența fiecărui cuvânt dintr-un set de date.

Frumusețea MapReduce constă în faptul că același cod care funcționează pentru un set de date de câțiva MBs poate funcționa pe seturi mult mai mari, de TBs, PBs sau chiar mai mult de atât, fără vreo modificare de cod în programul nostru. Aceasta se datorează naturii execuției distribuite a MapReduce, care are grijă în mod automat de distribuția muncii și de eșecul proceselor.

Mai jos, puteți observa reprezentarea pseudocodului exemplului Wordcount.

O imagine de ansamblu a MapReduce.

mapper (filename, file-contents):

each word in file-contents: MapReduce este o tehnologie distribu- for emit (word,1) ită, care funcționează pe produse hardware (word, values): obișnuite și se folosește pentru prelucrarea reducer sum=0 1 http://hadoop.apache.org/

2 http://wiki.apache.org/hadoop/poweredby

3 https://hive.apache.org/

for each value in values: sum=sum + value emit (word, sum)

4 http://wiki.apache.org/hadoop/WordCount

www.todaysoftmag.ro | nr. 33/martie, 2015

19

programare Introducerea și tuning-ul Hadoop MapReduce

În imaginea de mai sus, puteți vedea procesul general al MapReduce pentru execuția Wordcount. Fiecare fază Map îsi primește setul de date și pregătește chei intermediare ca perechi de (cheie,valoare), unde ”cheie” (key) este cuvântul real, iar ”valoare” (value) este frecvența actuală a cuvântului, mai exact 1. Faza de shuffling garantează faptul că toate perechile cu aceeași cheie vor servi drept intrare pentru un singur reducer, astfel că în faza de reduce putem calcula foarte ușor frecvența fiecărui cuvânt

Pătrunderea MapReduce.

În primul rând, următoarele proprietăți și pași de configurare implicați în tuning-ul MapReduce se referă la MapReduce V1.

Există o nouă versiune MapReduce V2, care poate să aibă foarte puține modificări. Sunt necesare cunoștințe MapReduce mai mult decât elementare pentru a înțelege următoarele secțiuni.

După cum am menționat mai sus, în cadrul unei executări MapReduce complete, există două faze principale, map și reduce și o altă fază, shuffle între ele.

execută o sortare în memorie după cheie și dacă este disponibilă și o funcție de combinare, aceasta este rulată pe ieșirea procesului de sortare. Având o funcție de combinare, ne ajută să compactăm rezultatul functiei de map și astfel vom avea mai puține date de scris pe disc și de transferat prin rețea. De fiecare dată când pragul tamponului este atins, un nou fișier de vărsare este creat, astfel încât, în majoritatea executărilor de map, la final, putem să avem fișiere de vărsare multiple în cadrul unei executări a unui map.

După ce faza de map este încheiată, toate fișierele de vărsare sunt unite într-un unic fișier partiționat și sortat. Este recomandat, de asemenea, să comprimați rezultatul map-ului pe măsură ce este scris pe disc pentru a grăbi scrierea pe disc, pentru a economisi spațiul pe disc, dar și pentru a reduce cantitatea de date transferată reducerilor. Opțiunea de comprimare este dezactivată în mod implicit, însă poate fi modificată foarte ușor prin setarea proprietății mapred.compress.map.output pe ”true”. Algoritmii de comprimare susținuți sunt DEFLATE, gzip, bzip2, LZO, LZ4 și Snappy.

Faza Reduce își primește setul de date printr-o metodă de cerere de date folosind protocolul HTTP. Să vedem ce se întâmplă în partea de reduce.

Partea de reduce.

Partea de Map.

Fiecare fază Map primește ca intrare un block (input split – divizare de intrare) dintr-un fișier stocat în HDFS. Valoarea implicită pentru un fișier block este de 64 MB. Dacă dimensiunea totală a fișierului este mai mică de 64 MB, atunci faza Map va primi ca intrare întregul fișier.

Când faza Map începe să producă rezultate, acestea nu sunt scrise direct pe disc. Procesul este mai amplu și profită de memoria RAM prin alocarea unui tampon (buffer) acolo unde rezultatele intermediare sunt stocate. În mod implicit, dimensiunea acestui tampon este de 100 MB, însă poate fi reglată prin modificarea proprietății io.sort.mb. Când se atinge peste 80% din dimensiunea tamponului, un proces de fundal va vărsa conținutul pe disc. Pragul de 80% poate fi de asemenea modificat folosind proprietatea io.sort.spill.percent. Înainte ca datele să fie vărsate pe disc, acesta este partiționat pe baza numărului de procese de reduce. Pentru fiecare partiție, se

20

nr. 33/martie, 2015 | www.todaysoftmag.ro

După ce execuția map-ului este încheiată, este informat coordonatorul execuției (jobtracker), care știe la care procese de reduce să trimită fiecare partiție. Mai departe, reduce-ul are nevoie de rezultatele a mai multor faze de map care încep să fie copiate odată ce acestea sunt finalizate.

Rezultatele funcțiilor de map sunt copiate direct în memoria JVM a funcției de reduce, dacă sunt suficient de mici. În caz contrar, acestea sunt copiate pe disc. Când tamponul în memorie (in-memory) atinge o anumită dimensiune (controlată de mapred. job.shuffle.merge.percent) sau atinge un număr maxim de rezultate de map (mapred.inmem.merge.threshold), este unit și vărsat pe disc. Dacă este specificat un combinator, acesta va fi rulat în timpul unirii pentru a reduce cantitatea de date scrise pe disc.

Dacă în final vom avea multiple fișiere de vărsare pe disc, acestea sunt de asemenea unite în fișiere mai mari, sortate, pentru a economisi timp pentru mai târziu.

Când toate funcțiile de map sunt încheiate și rezultatele lor sunt copiate pentru fazele de reduce, intrăm în faza de unire, care unifică toate rezultatele funcțiilor de map, păstrându-le ordinea de sortare după cheie. Rezultatul acestei uniri servește drept intrare pentru faza de reduce. În timpul fazei de reduce, funcția de reduce este invocată pentru fiecare cheie din ieșirea sortată.

TODAY SOFTWARE MAGAZINE Ieșirea acestei faze este scrisă direct pe sistemul de fișiere, de obicei HDFS. Faza de shuffle înseamnă toate procesele din punctul în care functia map produce rezultate până unde funcția de reducerea le consumă. Cu alte cuvinte, faza de shuffle implică sortare, unire și copierea datelor între map și reduce.

Reglarea (tuning-ul) configurației MapReduce

După ce am văzut pașii interni ai MapReduce și îi înțelegem mai bine, putem începe acum să îmbunătățim execuția generală a MapReduce.

Acum vă voi oferi câteva sfaturi generale despre cum să vă reglați execuția MapReduce. În general, este mai bine să acordați fazei de shuffle cât mai multă memorie posibilă, astfel încât datele vor fi prelucrate în memoria RAM în loc de disc. Deoarece faza de shuffle folosește memoria RAM din memoria atribuită fazelor de map și reduce, trebuie să fim atenți în a lăsa suficientă memorie pentru ele. De aceea este mai bine să scrieți funcția de map și reduce pentru a utiliza cât mai puțină memorie posibil (evitarea acumulării valorilor într-o colecție, spre exemplu).

Cantitatea de memorie alocată fiecărei funcții de map și reduce este atribuită de proprietatea mapred.child.java.opts. Ar trebui să le alocăm cât mai multă memorie posibil, dar să nu depășească totuși cantitatea de memorie RAM a serverului.

Pe partea de map, cea mai bună performanță poate fi obținută prin evitarea vărsărilor multiple pe disc, una singură este vărsarea optimă. Pentru aceasta, ar trebui să detectăm dimensiunea rezultatelor funcției de map și să modificăm proprietățile corespunzătoare (de ex. io.sort.mb), pentru minimizarea numărului de fișiere de vărsare pe disc.

Pe partea de reduce, cea mai bună performanță se obține când datele intermediare pot să stea în totalitate în memorie. În mod implicit, aceasta nu se întâmplă, deoarece pentru cazul general, toată memoria este rezervată funcției de reduce. Însă, dacă funcția Dvs. de reduce are cerințe de memorie puține, atunci setarea proprietăților corecte poate să vă sporească performanța. Pentru aceasta, aruncați o privire la proprietățile mapred.inmem.merge.

threshold și mapred.job.reduce.input.buffer.percent.

Concluzie

Dacă doriți să faceți doar o încercare a tehnologiei MapReduce, nu vă recomand să vă deranjați cu reglarea (tuning-ul) de mai sus, deoarece configurația implicită funcționează destul de bine. Însă, dacă într-adevăr lucrați cu seturi mari de date și doriți să așteptați doar trei zile în loc de cinci zile pentru rezultatele analizelor Dvs., vă recomand cu încredere să luați în considerare reglarea (tuningul). Aici, în Cluj-Napoca, avem o comunitate BigData5 puternică, unde am început să avem subiecte și ateliere relevante despre BigData. Alăturați-vă nouă dacă doriți să descoperiți mai multe!

Următoarea întâlnire6 va fi cea mai mare de până acum, avem vorbitori excepționali din București și Timișoara, care vor vorbi despre Elasticsearch, Spark, Tachyon și Machine Learning.

5 http://www.meetup.com/big-data-data-science-meetup-cluj-napoca/ 6 http://www.meetup.com/big-data-data-science-meetup-cluj-napoca/events/220876181/

www.todaysoftmag.ro | nr. 33/martie, 2015

21

programare

Sisteme de mesagerie performante – Apache Kafka

O

Tiberiu Nagy

tiberiu.nagy@betfair.com

Senior developer @ Betfair

dată cu răspândirea arhitecturilor bazate pe evenimente, sistemele de mesagerie au devenit componentele de bază ale arhitecturilor enterprise. Deoarece aplicațiile enterprise prelucrează din ce în ce mai multe date, performanța sistemelor de mesagerie devine din ce în ce mai importantă pentru buna funcționare a aplicațiilor, necesitând platforme rapide și scalabile. Apache Kafka este un sistem nou de mesagerie, care se remarcă drept una dintre cele mai performante soluții la momentul actual, putând transfera până la un milion de mesaje pe secundă pe un grup de trei mașini de capacitate medie.

Kafka a fost dezvoltat inițial la LinkedIn, într-o perioadă în care LinkedIn-ul migra de la o bază de date monolitică la o arhitectură bazată pe servicii, în care fiecare serviciu își avea propriul lui model de stocare a datelor. Una dintre probleme care s-a ivit în timpul migrării a fost distribuirea în timp real a jurnalelor de acces de pe serverele web către serviciul de analiză a activității utilizatorilor. Inginerii de la LinkedIn aveau nevoie de o platformă care să poată transfera cantități mari de date către mai multe servicii, într-un timp cât mai scurt. Platformele existente s-au dovedit a fi ineficiente pentru volumul de date de care dispuneau, așa că și-au dezvoltat propriul lor sistem de mesagerie, sub numele Kafka. Ulterior, proiectul a fost lansat open source și donat la Apache Software Foundation. După lansare, Kafka a fost adoptat de mai multe companii care aveau nevoi similare de transfer de mesaje.

Viteză vs. funcționalități

Principalul obiectiv în proiectarea Kafka a fost maximizarea vitezei de transfer al mesajelor. Pentru a obține viteze cât mai mari, Kafka vine cu un model de publicare regândit și renunță la câteva dintre facilitățile oferite de platformele clasice de mesagerie.

Una dintre cele mai importante

22

nr. 33/2015 | www.todaysoftmag.ro

schimbări o reprezintă modul de retenție a mesajelor publicate. Producătorii publică mesaje în Kafka, care devin disponibile pentru procesat consumatorilor, însă consumatorii nu trebuie să confirme procesarea mesajelor. În schimb, Kafka reține toate mesajele primite pentru o perioadă fixă de timp, consumatorii având libertatea de a consuma orice mesaj reținut. Deși pare ineficient la prima vedere, acest model de lucru aduce o serie de avantaje: • S i m p l i f i c ă m u l t a r h i t e c t u r a sistemului, • Kafka nu trebuie să rețină care dintre mesaje au fost consumate și care nu.

Izolează producătorii de consumatori. În sistemele în care consumatorii sunt obligați să confirme procesarea mesajelor, performanța sistemului se poate degrada odată ce numărul de mesaje neconfirmate crește. Unele servicii limitează rata la care producătorii pot publica mesaje pentru a nu suprasolicita sistemul de mesagerie, însă această abordare poate duce la situații periculoase în care un consumator lent, dar neimportant afectează un producător critic pentru business, • Consumatorii nu trebuie să consume permanent, ei putând fi opriți oricând, fără a impact sistemul de mesagerie. Ei pot fi chiar și batch job-uri executate

TODAY SOFTWARE MAGAZINE periodic. Desigur, abordarea aceasta funcționează numai dacă mesajele sunt reținute în Kafka suficient de mult încât procesele respective să apuce să prelucreze datele acumulate între rulări.

Deoarece mesajele nu trebuie reținute selectiv, Kafka poate folosi un model de stocare foarte simplu și eficient: jurnalul de mesaje. Jurnalul nu e decât o listă de mesaje, în care mesaje noi sunt adăugate tot timpul la sfârșitul listei. Mesajele existente nu se modifică niciodată. Întrucât jurnalul se modifică numai la sfârșit prin adăugarea de mesaje noi, ea se poate stoca optim pe medii de stocare magnetice – scrierea pe harddisk se poate face secvențial, evitând astfel deplasarea capului de scriere, o operație costisitoare din punct de vedere al performanței. De asemenea, dacă consumatorii reușesc să țină pasul cu producătorii de mesaje, Kafka poate servi mesajele direct din memorie, folosindu-se în acest caz de mecanismele de caching oferite de sistemul de operare.

O altă diferență importantă față de sistemele tradiționale o reprezintă modul în care pot fi consumate mesajele. Sistemele tradiționale oferă două moduri de consum: coadă (queue) și publicare-abonare (publish-subscribe). În modelul coadă, fiecare mesaj ajunge la un singur consumator. În modelul publicare-abonare, fiecare mesaj ajunge la fiecare consumator. Kafka vine cu o singură abstractizare care acoperă ambele modele: grupuri de consumatori. În Kafka, fiecare consumator face parte dintr-un grup, chiar dacă e singurul consumator din grup. În cadrul grupului, numai un consumator poate primi un mesaj. În schimb mesajele sunt

livrate tuturor grupurilor de consumatori.

Această simplificare permite sistemului să ofere singură modalitate de a grupa mesajele: topica. Modelul Kafka e de fapt un fel de publish-subscribe, în care grupuri de consumatori și nu consumatori individuali se abonează la o topică. Dacă toți consumatorii fac parte din același grup, fiecare masaj va ajunge la un singur consumator din grup, topica funcționând ca o coadă de mesaje. Dacă în schimb fiecare consumator face parte din alt grup, fiecare consumator va primi mesajele publicate—modelul publish-subscribe clasic. În practică însă, vom avea de a face cu un număr mic de grupuri de consumatori, fiecare grup corespunzând de obicei unui serviciu interesat de datele publicate în Kafka. În cadrul grupurilor vom avea mai mulți consumatori (de obicei câte unul pentru fiecare mașină pe care rulează serviciul). Deoarece fiecare grup primește fiecare mesaj publicat pe o topică, serviciile vor primi toate mesajele publicate, dar în cadrul unui serviciu procesarea de mesaje se va distribui între mașini.

Arhitectura Kafka

În linii mari, un serviciu Kafka e format din mai multe mașini care au rolul de broker, ele reținând mesajele publicate. Pe lângă agenți, mai e nevoie și de un grup de 3–5 mașini care să ruleze Apache

Zookeeper. Kafka folosește Zookeeper pentru coordonarea și managementul brokerilor.

Deoarece volumul de mesajele publicate pe o topică poate depăși capacitatea unui broker, topicele se împart la rândul lor în mai multe partiții. Fiecare partiție e de fapt un jurnal de mesaje. Partițiile trebuie să încapă în totalitate pe un broker, în schimb, partițiile ce țin de un topic sunt distribuite uniform în cadrul brokerilor, fiecare broker găzduind un număr aproximativ egal de partiții.

Când un producător vrea să publice un mesaj în Kafka, producătorul interoghează un broker pentru a afla câte partiții sunt și cum sunt ele distribuite în cadrul brokerilor, decide în care dintre partiții să publice (pe baza conținutului mesajului, aleatoriu, sau luând pârtiile pe rând), după care trimite mesajul brokerului care găzduiește partiția aleasă. Pe partea de consumator însă, lucrurile nu sunt așa de simple. Partițiile topicii sunt distribuite în mod egal între consumatorii dintr-un grup, fiecărui consumator revenind una sau mai multe partiții din care poate citi mesajele. Pe lângă distribuirea uniformă a sarcinii de consum, alocarea partițiilor garantează că fiecare mesaj va

www.todaysoftmag.ro | nr. 33/martie, 2015

23

programare Sisteme de mesagerie performante – Apache Kafka fi procesat de un singur consumatori din grup. Indexul ultimului mesaj procesat din fiecare partiție se reține în Zookeeper, astfel că, dacă un consumator iese din grup, partițiile lui pot fi realocate altor consumatori, care poate relua procesarea de la ultimul mesaj citit. Partiționarea distribuie uniform sarcina în rândul brokerilor, dar ce se întâmplă în cazul în care un broker iese din grup sau devine inaccesibil? În funcție de natura problemei, partițiile găzduite de el pot deveni inaccesibile sau se pot pierde definitiv. Pentru a preveni astfel de situații, Kafka introduce conceptul de partiții replica (replica partitions). Fiecare partiție găzduită de un broker (numită de acum încolo partiție lider) poate avea una sau mai multe replici. Acestea sunt partiții la rândul lor, doar că sunt stocate pe alți brokeri decât cea pe care se află partiția lider. Producătorii nu pot publica în replici, numai în partiții lider, iar brokerii pe care găzduiesc partițiile lider se asigură că orice mesaj primit e salvat și în replici. În eventualitatea pierderii unui broker, unul dintre replicile fiecărei partiții lider de pe brokerul pierdut se promovează la statutul de lider, astfel încât Kafka continuă să funcționeze fără întreruperi și fără pierderi de date. Când brokerul e repus în funcțiune, el își sincronizează partițiile de la ceilalți brokeri, după care începe un

24

proces de desemnare a liderilor pentru fiecare partiție.

Concluzii

Kafka reprezintă o soluție bună pentru aplicațiile care necesită o viteză mare de transfer și o latență mică la livrarea mesajelor. Arhitectura lui simplă și modalitatea flexibilă de grupare a consumatorilor îl fac potrivit pentru o serie de aplicații: colectare de jurnale și metrici de performanță, procesare de secvențe de date și evenimente. Ca orice tehnologie, Kafka are și ea limitările ei. Faptul că mesajele nu pot fi reprocesate individual poate reprezenta o problemă pentru unele tipuri de aplicații. O altă problemă o poate reprezenta lipsa de programe și unelte de administrare. Spre deosebire de alte platforme gen ActiveMQ sau RabbitMQ, Kafka are un ecosistem slab dezvoltat. Necesitatea rulării unui cluster de Zookeeper pe lângă brokerii Kafka poate de asemenea reprezenta un impediment financiar sau administrativ. Sperăm însă că o parte dintre aceste limitări vor dispărea odată cu răspândirea și maturizarea tehnologiei.

nr. 33/martie, 2015 | www.todaysoftmag.ro

programare

Date de tip spațial în SQL Server

D

atele spațiale sunt folosite pentru a reprezenta informații despre locația și forma obiectelor geometrice. Aceste obiecte pot fi centrul unei locații, reprezentat sub forma unui punct, sau obiecte complexe: drumuri, râuri, orașe sau țări.

Diana Muntea

diana.muntea@yardi.com Software Developer @ Yardi România

Începând din 2008 suita de produse SQL Server de la Microsoft oferă suport pentru datele geospațiale. Acest lucru permite stocarea datelor în tabele sub formă de puncte,linii şi poligoane. De asemenea, oferă atât o gamă largă de funcții pentru manipularea lor, cât şi indecși spațiali pentru a permite o rulare eficientă. În SQL Server datele spațiale pot fi de două tipuri: • Geometrice (geometry) – date reprezentate într-un sistem euclidian (plan, 2D), • Geografice (geography) - date care țin cont de curbura Pământului și sunt reprezentate într-un sistem elipsoidal (3D sau 4D).

aceeași unitate de măsură în care sunt exprimate şi coordonatele punctelor, iar distanța, ca număr de unități, va fi mereu aceeași indiferent de unitatea folosită. În sistemul elipsoidal, care ține cont de curbura Pământului, coordonatele punctelor sunt exprimate folosind latitudinea și longitudinea, în timp ce pentru distanță sau suprafață se folosesc de obicei metri.

Unitatea de măsură depinde și de identificatorul SRID. • Ori entare a d atel or sp ați a l e – Orientarea nu este importantă pentru datele de tip geometric. În schimb datele geografice nu au nici o valoare dacă nu le specificăm orientarea, pentru că nu vom ști dacă sunt în emisfera nordică sau sudică. În SQL Server 2014 orice instanță de datele geografice trebuie să fie cuprinsă într-o singură emisfera. De asemenea și rezultatul operațiilor dintre două date de tip geografic (intersecție, uniune, diferență) trebuie să fie definit într-o singură emisferă.

Ambele tipuri de date sunt implementate folosind .NET common language runtime (CLR). Cele două tipuri se comportă de cele mai multe ori similar, dar între ele există totuși câteva diferențe: • Modul în care sunt conectate două puncte - pentru datele geometrice reprezintă o linie dreaptă în timp ce pentru cele geografice este un arc circular.

SRID - Spatial Reference Indentifiers • Măsurătorile spațiale – în sistemul Este un identificator care corespunde unui planar distanța este măsurată folosind sistem spațial de referință și unui anumit tip www.todaysoftmag.ro | nr. 33/martie, 2015

25

programare Date de tip spațial în SQL Server de elipsoid folosit pentru desenarea hărților. Identificatorul este definit de standardul European Petroleum Survey Group (EPSG).

O coloană poate conține date spațiale cu SRID diferite, dar nu se pot realiza operații între date care nu au același SRID, și nu sunt bazate pe aceeași unitate de măsură și aceeași proiecție. Cea mai comună unitate de măsură este metrul sau metrul pătrat. Pentru datele de tip geometric valoarea implicită pentru SRID este zero, iar pentru cele de tip geografic este 4326 (acesta este folosit și de către Google Maps API).

Tipuri de obiecte posibile pentru datele geometrice și geografice

INSERT INTO myTable (geometryData) VALUES (geometry::STGeomFromText(‘LINESTRING (100 100, 20 180, 180 180)’, 0)); INSERT INTO myTable (geometryData) VALUES (geometry::STGeomFromText(‘POLYGON ((0 0, 150 0, 150 150, 0 150, 0 0))’, 0)); GO SELECT @geom1 = geometryData FROM myTable WHERE id = 1; SELECT @geom2 = geometryData FROM myTable WHERE id = 2; SELECT @result = @geom1.STIntersection(@geom2);

Date Geografice CREATE TABLE myTable ( id int IDENTITY (1,1), geographyData geography, GO INSERT INTO myTable (geographyData) VALUES (geography::STPolyFromText(‘POLY GON((-73.9998722076416 40.726185523600634,74.00708198547363 40.73860807461818,73.99824142456055 40.7466717351717,-73.97326469421387 40.74628158055554,-73.97309303283691 40.7269010214160, -73.9998722076416 40.726185523600634))’, 4326));

Ce tip de date ar trebui să aleg pentru aplicația mea (geometry vs. geography)?

Imagine MSDN

Tipul de date ales depinde de aplicație și de scopul ei. Din punct de vedere al stocării datelor nu este nici o diferență între cele două tipuri de date spațiale. În schimb, dacă ne uităm la performanță, interogările pe date de tip geometric sunt mult mai rapide. În final cel mai important argument este funcționalitatea.

Dacă avem o aplicație în care dorim să realizăm măsurători între diverse locații sau trebuie să ținem cont de forma Pământului, va trebui să folosim date geografice. În alte cazuri, în care dorim doar să vizualizăm diverse poligoane, datele geometrice s-ar putea să fie suficiente.

SQL Server ne pune la dispoziție mai multe tipuri de funcții și metode pentru manipularea datelor de tip spațial : pentru importarea datelor (STGeomFromText, STGeomFromWKB), pentru a realiza diferite tipuri de operații(STContains, STOverlaps, STUnion, STIntersection) sau pentru a face diverse măsurători (STArea, STDistance), inclusiv pentru a determina cel mai apropiat vecin(STDistance(@me)) . Începând cu SQL Server 2012 este definită şi o formă geometrică numită FullGlobe, ea reprezintă un poligon care acoperă tot globul pământesc. Acest poligon are o suprafață, dar nu are margini.

Aplicații

Exemple Date Geometrice

CREATE TABLE myTable ( id int IDENTITY (1,1), geometryData geometry, GO

26

nr. 33/martie, 2015 | www.todaysoftmag.ro

Radius search Să presupunem că avem o colecție de puncte definite prin latitudine şi longitudine care reprezintă diverse locații. Acest tip de căutare constă în desenarea unui cerc, definit de un punct central şi o rază reprezentată într-o unitate de măsură (metri). În acest caz nu putem folosi decât date geografice, criteriul de căutare

TODAY SOFTWARE MAGAZINE fiind distanța dintre puncte.

Varianta optimă ar fi să salvăm punctele folosind trei coloane: latitudine, longitudine și punctul geografic. În acest fel , înainte de aplica filtrarea spațială, putem filtra datele folosind bounding box-ul cercului.

Referințe: 1.

2.

3.

4.

https://msdn.microsoft.com/en-us/library/bb933790.aspx http://en.wikibooks.org/wiki/Geospatial_Data_in_SQL_Server dotnetsolutions.co.uk/working-with-spatial-data-in-sql-server-2008/ https://devjef.wordpress.com/2013/01/12/geometry-vs-geography/

Punctul geografic

geoPoint = geography::STGeomFromText(‘POINT (-96.8501 32.7639)’, 4326) SELECT * from myTable WHERE latitude < 32.7871617669569 AND latitude > 32.7500254131114 AND longitude < -96.8143320623701 AND longitude > -96.8584966119462 AND geoPoint.STDistance( geography::STGeomFromText( ‘POINT(-96.836414337158146 32.768593590034193)’, 4326)) <= 2067

www.todaysoftmag.ro | nr. 33/martie, 2015

27

programare

Usable Software Design

Î

ntr-un articol anterior pentru Today Software Magazine - Patru idei pentru îmbunătățirea Software Design-ului - am scris despre faptul că avem tendința de a face software design care nu este orientat către utilizator.

Alexandru Bolboacă

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

28

nr. 33/2015 | www.todaysoftmag.ro

Ori de câte ori vorbim despre design în alte domenii decât software-ul, discutăm din punct de vedere orientat către utilizator. Produsele Apple sunt renumite pentru că se concentrează pe experiența utilizatorului cu dispozitivul: cum se simte, cum arată, cât de repede răspunde, sunetele pe care le scoate, etc. .

S of t ware D esig n-u l este singur u l tip de design care pare să nu aibă utilizator. La urma urmei utilizatorul final nu are nici o idee despre cum este organizată aplicația pe care o folosește și nici măcar nu-i pasă. Tot ce contează pentru el este ca aceasta să funcționeze bine.

Software Design-ul are un utilizator: programatorul care va trebui să schimbe codul scris de echipa ta. Dacă folosiți collective code ownership (ca majoritatea echipelor Scrum), ar fi bine să luați în considerare user-centric software design (software d e sig n or i e nt at c ăt re ut i l i z at or ) .

Idei precum “Clean Code” ating această abordare dar nu o dezvoltă. În continuare, aș vrea să explorez acest subiect în detaliu.

1. Dezvoltatorii noi care lucrează cu Usable Software Design vor deveni mai productivi mai repede

De ce este gradul de ușurință în folosire al aplicațiilor web un subiect atât de important astăzi? Aș argumenta că motivul îl constituie avantajul competitiv pe care îl aduce, deoarece utilizatorii găsesc mult mai ușor să înceapă să folosească o aplicație care este construită având utilizatorul în minte. Niciun utilizator nu are timp să învețe un produs nou; vrem să începem să îl folosim imediat și să ne aducă beneficii instant.

Noii utilizatori ai software designului sunt noii dezvoltatori care se alătură echipei. Vom presupune că știu limbajul de programare, framework-ul principal utilizat și au lucrat în domeniul business înainte. Cât timp le ia să devină productivi în mediul vostru? Timpul petrecut îi familiarizează cu designul aplicației și cu modul în care lucrurile se fac în mare parte, dar se traduce prin cheltuieli. În termenii produsului, se numește pierdere.

TODAY SOFTWARE MAGAZINE 2. Cerințele cele mai comune sunt implementate mult mai rapid cu Usable Software Design

Gândește-te la tipul de activități desfășurate pe produsul curent. Șansele sunt ca multe dintre ele să fie repetitive. În aplicația de eHealth pe care o dezvoltăm, primele funcționalități au luat ceva timp pentru a fi implementate (NB: în același timp învățăm și o nouă tehnologie). Privind atent la ceea ce ne-a încetinit lucrul și ajustând designul, am optimizat dezvoltarea și am ajuns la punctul în care aproximativ 60% din munca este UI / UX design. Acum, dezvoltarea nu mai are bottleneck. Ne-am uitat apoi la optimizarea activităților de UI / UX, dar asta e altă poveste.

Cheia acestei îmbunătățiri a stat în faptul că privind în urmă, ne-am dat seama a implementa fiecare caracteristică; că dezvoltam funcționalități care cores• discută deviațiile la retrospectivă; pund câtorva tipuri de muncă: • identifică ce ne împiedică să mergem • Adăugarea unei noi activități aplicată mai repede; pe situația medicală a pacientului:create, • definește și pune în aplicare display, change, hide; modificările; • Legarea unei entități medicale de o • repetă. intrare în jurnalul pacientului; • Afișarea unui istoric filtrat după Noi folosim un proces Kanban / XP, diverse criterii; Etc.. așa că am folosit the cycle time distribution diagram ​pentru a identifica punctele Din moment ce știam din roadmap-ul de deviație. Avem o retrospectivă recuproiectului că vor apărea din nou astfel de rentă la fiecare două săptămâni în care cerințe, am început optimizarea pentru discutăm impedimentele și identificăm aceste tipuri de muncă. soluțiile. Implementarea a fost făcută în Ocazional, trebuia să facem un nou tip următoarele două săptămâni, și ne-am de muncă care dura mai mult. Un exemplu păstrat un ochi la cycle time distribution în a fost un serviciu de căutare a unui medi- următoarele luni. A fost ușor să vedem cament, care este rapid, scalabil și ușor de îmbunătățirile deoarece majoritatea taskmodificat pentru a funcționa corect cu urilor s-au mutat la stânga. ultima versiune a bazei de date de mediÎntr-un context Scrum, echipele nu camente. A trebuit să învățăm să folosim măsoară cycle time, doar viteza. Problema vertx și mongodb pentru a face lucrul este că viteza este un indicator agregat penacesta, și ne-a luat de 3-5 ori mai mult timp tru toate funcțiile implementate pe durata decât o sarcină normală. Deoarece aceasta sprintului. Prin urmare, echipele Scrum este o situație locală, care este puțin proba- au două opțiuni pentru a ajunge la usable bil să se repete, nu am făcut nimic pentru software design: a optimiza.

• Cantitativă: începe măsurarea timIdeea este: ca o aplicație care este ușor pului efectiv petrecut pe user story; de folosit pentru taskuri mai comune, • Calitativă: executa o retrospectivă Usable Software Design permite implerecurentă pe tema de usable design. mentarea rapidă a celor mai frecvente Întreabă developer-ii ce le ia mai mult tipuri de caracteristici. timp decât ar trebui. Într-o echipă în Acestea sunt principalele beneficii pe care există încredere și transparență, veți care le văd pentru Usable Software Design. identifica imediat problemele.

Dar cum să-l obținem? Primul lucru este ...

Aceasta este metoda de bază pentru 3. Măsoară și îmbunătățește a obține usable software design. Metoda Procesul pe care l-am folosit pentru a avansată este preluată din practicile de face designul mai operațional a fost destul usability. de simplu: • măsoară cât timp este nevoie pentru

4. Rulează teste de usability pe Software Design-ul tău

Testele de usability pot fi rulate în mai multe moduri. Am găsit totuși un format care se potrivește cel mai bine pentru Software Design: • Notează o listă de task-uri pe care utilizatorul trebuie să le execute • Adu într-o cameră utilizatori care nu au văzut niciodată produsul ( sau părți ale produsului pe care vrei să le testezi).

• Cere-le să execute task-urile.

• Măsoară cât timp le ia să facă asta.

Notează-ți unde se blochează.

• Folosește feedbackul pentru a îmbunătăți produsul.

Iată câteva exemple de task-uri comune pentru o aplicație web: • adaugă un nou formular cu un câmp text și un buton save; • adaugă validari suplimentare unui câmp; • schimbă textul unei etichete (pentru o limbă sau toate limbile suportate); • adaugă o nouă regulă de business; • afișează o listă de entități într-o pagină etc.

Enumerăm câteva lucruri importante de știut despre teste de usability: • Asigură-te că le spui participanților că, dacă nu știu să facă ceva, este vina designului, nu a lor. Încurajează-i să pună întrebări când se blochează.

• Un test complet cu o singură persoană n-ar trebui să dureze mai mult de o oră.

• Începe cu task-urile cele mai comune întâi și cu cât mai puțină informație posibilă. Oferă informație doar atunci când cineva se blochează și cere ajutor.

www.todaysoftmag.ro | nr. 33/martie, 2015

29

programare Usable Software Design • Pregătește cam zece task-uri, dar Așa arată un pachet funcțional când utilizatori, mai exact de la dezvoltatori. așteaptă-te să finalizezi mai puține. este extins: Există două metode pentru a obține: prin retrospective și rulând teste de usability.

Acum știm cum să identificăm proIdeea nu este complet nouă. Principiile bleme. Sunt sigur că următoare întrebare precum claritate și consistență au fost este... folosite mulți ani la rând pentru a obține Design mai bun. Ideea de usable Software 5. Cum arată Usable Software Design?

Design este totuși o schimbare de perPentru început menționez că ideea spectivă; a te gândi la dezvoltator ca la de a se centra pe developer, ca utilizator utilizatorul software design-ului și a încerca al Software Design-ului, este foarte nouă.

Fiecare conține trei lucruri: activ să obținem feedback de la el sunt Am văzut discuții oarecum în jurul aces• o clasă de request, demersuri care vor aduce modificări în tui topic, și am contribuit și eu la unele.

• o clasă de controller, modul în care ne organizăm codul.

Literatura din trecut despre Software • o clasă de view.

Design a atins acest subiect, dar nu în mod Mulțumiri! explicit. Încă trebuie să găsesc un loc mai bun Am fost inspirat să scriu acest artiExistă totuși foarte multă literatură pentru InvoiceFileNameGenerator, după col după multe conversații cu: Sandro despre usability. Voi menționa doar trei cum puteți vedea limpede. Aceasta este Mancuso, Samir Talwar, participanții la principii de bază ale usability-ului care se o încălcare a celui de al treilea principiu, SoCraTes UK, Rebecca Wirfs-Brock, Adi aplică în Software Design: reducerea surprizei.

Bolboacă, Claudia Rosu și mulți alții.

• Claritate, • Consistență, Consistență: Fiecare tip de clasă trebuie Vă invit pentru o dezbatere mai apro• Reducerea surprizei. să aibă o interfață consistentă fundată în cadrul Workshopului de Am văzut mai devreme că un pachet Usable Software Design la I T.A.K.E. Prezentăm câteva exemple: funcțional constă din trei tipuri de clase: Unconference 20151. a clasă de request, o clasă de control1 h t t p : / / 2 0 1 5 . i t a k e u n c o n f . c o m / s e s s i o n s / Claritate: Numește pachetele în funcție ler și o clasă de view. Există și un nivel alex-bolboaca-usable-software-design/ de denumirea funcționalității (pachete mai ridicat de consistență la care se funcționale) poate ajunge, mai specific în interfața Iată un screenshot de la o aplicație pe fiecăreia dintre aceste tipuri de clase. care o dezvolt. Poți spune ce face doar pe În acest exemplu, toate clasele de baza numelor?

Request menționate mai sus au o metodă:response()​Toate funcțiile controllers au o metodă:render().Fiecare funcție de controller folosește un view pentru a reda informația. Aceste interfețe sunt consistente în toate pachetele funcționale.

Prima oară l-am auzit pe Sandro Mancuso vorbind despre ideea aceasta la Gânduri finale I T.A.K.E. Unconference 2014 (2014.itaUsable Software Design vor aduce keunconf.com) și am fost foarte interesat două beneficii economice majore: să încerc. Văd ideea ca pe un bun start în implementare mai rapidă pentru task-urile Usable Software Design. comune și integrare mai ușoară a oameniConsistență: Păstrează o struc- lor noi în proiect. tură consistentă pentru fiecare pachet Pentru a obține Usable Software funcțional Design, avem nevoie de feedback de la

30

nr. 33/martie, 2015 | www.todaysoftmag.ro

management

Quality Assurance în Agile

S

Vasile Selegean

vasile.selegean@isdc.eu QA Officer @ ISDC

ă presupunem că mașina noastră de colecție are nevoie de un strat nou de vopsea. Sau trebuie să zugrăvim noua noastră casă. Vom angaja cei mai buni profesioniști, le vom cere să folosească cele mai bune materiale de pe piață si chiar vom accepta să plătim un preț mai mare decât media. Echipa angajată termină la timp, fără să depășească bugetul. Toată lumea e fericită și poate va fi și o mică petrecere de inaugurare! Dar, într-o lună sau două, mici pete de rugină sau crăpături apar în vopseaua proaspătă.. Ce s-a întâmplat? Cea mai bună echipă nu a lăsat suficient timp pentru stratul de suport să se usuce și au aplicat vopseaua după numai patru ore, nu șase, cât ar fi fost nevoie în conformitate cu specificațiile producătorului.

Ce lipsește din acest scenariu este un proces de execuție corect definit și urmărit in timp. Nu a fost vorba despre un pas sărit în intregime, ceva ce s-ar fi putut observa la timp pentru a fi corectat înainte de finalizarea lucrării, doar o mica scăpare ce nu părea semnificativă în acel moment dar care, în timp, s-a dovedit mai costisitoare decît întârzierea ce s-ar fi întâmplat dacă s-ar fi urmat specificațiile.

Ce este Quality Assurance?

“Quality Assurance” reprezintă o suită de activități peste care se trece cu mult prea multă ușurință în echipele ce au adoptat modelul SCRUM. Motivele sau scuzele sunt multe, de la timpul scurt alocat dezvoltării și nevoii de a livra cât mai rapid un produs, la încrederea acordată echipei de testare până la neînțelegerea totală a conceptului de “calitate”.

Acest lucru nu este ceva ce poate fi trecut atât de ușor cu vederea sau amânat până când condițiile o vor permite – acel moment s-ar putea să nu vină niciodată. Consecințele pot fi semnnificative și pot merge de la timpul necesar fixării defectelor (pe cheltuiala proprie) până la pierderea încrederii clienților.

“Asigurarea Calității” nu trebuie confundată nici cu “Controlul calității” – cea din urmă

reprezintă ultima etapă în procesul de asigurare a calității, deoarece, pentru a fi siguri de rezultat, este nevoie de un produs funcțional, cât mai aproape de varianta finală.

Să începem cu definiția calității: calitatea unui produs (fie că e vorba despre un avion, un hot-dog, un serviciu sau un software) este un atribut distinctiv al produsului respectiv, în comparație cu un alt produs similar.

Folosim expresia “produsul A este de calitate”, dar aceasta are sens doar când comparăm acel produs cu un altul, similar. Mult mai des spunem “produsul X este de o calitate mai bună decât produsul Y”, iar aceasta este în conformitate cu spiritul definiției de mai sus. Pâna la urmă calitatea înseamnă să livrăm ce așteaptă clientul să primească. Nu mai puțin (motivul e clar) dar nici prea mult, pentru că s-ar putea să nu fim plătiți pentru munca noastră.

Calitatea unui produs sau serviciu este o sumă a mai multor criterii de calitate, fie că sunt definite explicit la începutul proiectului, de către toate părțile implicate, fie sunt subînțelese, fără un acord scris. Asemenea criterii sunt (sau ar trebui) să fie rezultatul unei analize riguroase și a înțelegerii nevoilor utilizatorului final. Aceste nevoi sunt traduse în ceea ce numim “factori de calitate” (quality factors) ce vor fi mai apoi integrați

www.todaysoftmag.ro | nr. 33/martie, 2015

31

management Quality Assurance în Agile în produsul final prin criteriile de calitate amintite mai sus. Aceste criterii trebuie să fie măsurabile și metricile astfel obținute vor fi folosite apoi atât pentru evaluarea calității produsului în timpul ciclului de dezvoltare și la momentul livrării cât și ca fundament pentru eventuale îmbunătățiri.

Calitatea unui produs este rezultatul unui mix a tot ce contribuie la dezvoltarea respectivului produs: factorul uman (echipa de proiect), echipamentul sau tehnologia pe care aceștia îl/o folosesc și procesul de lucru, prin care se transformă materia primă în produs final. Quality Assurance își propune să găsească acel echilibru perfect între cei trei actori ce contribuie la realizarea produsului.

Pâna la urmă calitatea este acel factor ce poate face diferența între produsul nostru și altele similare disponibile în piața liberă.

Cel mai probabil există undeva în lume alte organizații cu același nivel de cunoștințe cu al nostru; unele dezvoltă produse similare cu al nostru, unele mai ieftin, altele mai repede. Nimic nu oprește un consumator în anul 2015 să aleagă celălalt produs. Doar calitatea produsului propriu poate să facă remarcat produsul care nu trebuie să fie perfect – nici nu există produse perfectedar trebuie să răspundă cât mai bine unei nevoi a consumatorului și să fie puțin mai bun decât al concurenței.

Peter Leeson –CMMI and Process Improve me nt L ead Apprai s e r and Instructor- a rezumat aceasta în articolul “Understanding Quality” de pe blogul personal1: Understanding quality is the most critical aspect of your job, whatever it is. Quality is what differentiates your products and services from the others. If your sole focus - as reflected by measurements is quick and cheap, you will lose the battle: there will always be someone cheaper than you.

Asigurarea Calității este un set de activități ce au ca scop includerea atributelor de calitate în produsul final. Este nevoie de implicarea activă a tuturor celor ce participă, indiferent de etapa din viața produsului, de nivelul de senioritate sau de locul în organigramă. Atât timp cât cineva poate influența dezvoltarea unui produs sau serviciu, are și o responsabilitate în asigurarea calității produsului rezultat.

Asigurarea calității se împarte în două 1 www.qpit.net/blog/understanding-quality.html

32

Fig. 1: Rolul QA intr-un proiect.

categorii majore. În prima categorie intră activitățile de prevenire a defectelor în timpul procesului de dezvoltare prin definirea unui mod de lucru standardizat, stabilirea momentelor și frecvenței validărilor și verificarilor precum și revizuirea întregului proces. Măsurătorile a diferiți indicatori (KPIs), analiza acestor măsurători, măsurile de îmbunătățire sau de corectare a activității și evaluări periodice la toate nivelurile implicate sunt parte a acestui proces de prevenție. A doua categorie se concentrează pe detectarea defectelor în produsul final și este cunoscută și sub numele de Control al Calității.

Bineînțeles, toate cele de mai sus vin cu un cost asociat. În faza inițială a proiectului este nevoie de planificarea riguroasă a tuturor activităților legate de QA: identificarea nevoilor utilizatorului, translatarea acestora în obiective de calitate, planificarea monitorizării progresului, identificarea sau definirea celui mai bun model pentru întreg procesul de dezvoltare și lista poate continua. În timpul fazei de dezvoltare trebuie executate cu regularitate, conform planului, activități de monitorizare a performanței procesului de dezvoltare și a calității; este necesară planificarea momentelor de evaluare: frecvență, context și obiective; evaluarea progresului (sau a regresului) din perioada scursă de la ultima verificare; luarea măsurilor de corecție necesare dacă este cazul; evaluarea costurilor și a beneficiilor activităților executate (de exemplu: costul revizuirilor comparat cu costul necesar reparației unor eventuale defecte ce pot aparea în produsul final) și, în sfârșit, ajustarea întregului proces de muncă astfel încât să servească cât mai bine nevoilor proiectului.

nr. 33/martie, 2015 | www.todaysoftmag.ro

Mai mult, rezultatele măsurătorilor colectate în timpul existenței proiectului de dezvoltare, împreună cu setul de practici cu utilitate dovedită în timp, constituie un bun valoros pentru orice organizație.

Acestea pot fi folosite ca punct de plecare în dezvoltarea cu succes a unui nou produs sau în crearea unei noi echipe. Existența unui set de bune practici ce și-au dovedit în timp utilitatea pot fi de ajutor și în integrarea unor capacități suplimentare într-un sistem existent, fie că este vorba despre un nou membru în echipă, de un nou tool sau chiar un nou proces. În concluzie, activitățile grupate sub denumirea generică de Quality Assurance sunt o componentă vitală în orice proces de dezvoltare a unui produs.Quality Assurance poate fi asemănată cu un echipament GPS folosit pe scara foarte largă în zilele noastre. Ajută la stabilirea unei rute și oferă o estimare a costului călătoriei.

Totuși, acel aparat nu poate forța un șofer să urmeze ruta stabilită, dar, la nevoie, oferă rute alternative sau indicații către drumul ce a fost acceptat initial.

Cum se potrivesc acestea într-un mediu Agile?

Prima afirmație din Manifestul Agile spune că acei care vor îmbrățișa această filozofie vor prețui mai mult “Indivizii și interacțiunea dintre aceștia în locul proceselor”. Deci.. adăugarea unui proces nou într-un mediu Agile nu pare o idee foarte bună.

Citind mai departe manifestul Agile se spune limpede că, deși nu se contestă valoarea părții a doua din fiecare afirmație, se pune preț mai mare pe cea

TODAY SOFTWARE MAGAZINE din partea stângă. Mai mult, în pagina (și la nevoie execută fără nicio ezitare) și se dedicată istoriei mișcării Agile, scrisă de adaptează foarte repede oricărei schimbări Jim Highsmith, găsim următorul paragraf2: a mediului înconurător. Aceasta este mai mult definiția unui pluton al unei unități The Agile movement is not anti- din forțele speciale, nu al unei echipe de methodology, in fact, many of us want to programatori palizi. Din păcate, nivelul restore credibility to the word methodo- de maturitate necesar pentru funcționarea logy. We want to restore a balance. We efectivă a unei echipe Scrum nu este ceva embrace modeling, but not in order to ce se poate obține peste noapte. Membrii file some diagram in a dusty corporate echipei trebuie să înțeleagă la un nivel repository. We embrace documentation, acceptabil clientul și nevoile de business but not hundreds of pages of never-mai- ale acestuia astfel încât produsul dezvolntained and rarely-used tomes. tat să vină în întâmpinarea acestor nevoi.

Fiecare membru al echipei trebuie să aibă Putem verifica și printre cele douăspre- încredere totală în omul de lângă el și este zece principii Agile3: nimic nu interzice de așteptat ca ei să rateze de câteva ori definirea unui proces care să ne ajute în înainte de a ajunge la cea mai bună soluție munca noastră zilnică și astfel să ne folo- indiferent de problema asupra căreia își sim de ceea ce am învățat de-a lungul îndreaptă atenția într-un anume moment. timpului. Nu cred că a spus cineva vreoAșa cum am văzut mai sus fiecare dată că prețuiește mai mult colaborarea membru al echipei joacă un rol important într-o echipă în defavoarea calității. Sau, în construirea unui produs final de calitate. dacă a spus-o, e puțin probabil să mai con- Din păcate, nu întotdeauna este clar acest ducă vreo afacere acum. lucru – responsabilitatea se diluează între Oare este posibil ca un proces de toți participanții la procesul de producție management al calității să nu contravină și, câteodată, este ceva subînțeles („sunprincipiilor Agile? Oare s-ar putea defini tem profesioniști, știm fiecare dintre noi procese de lucru pentru diferite etape din ce avem de făcut”). Programatorii prograviața unui proiect (sau produs), pentru mează, tester-ii testează – pentru aceasta fiecare rol implicat, în așa fel ca aceste pro- suntem aici pâna la urmă, nu? De ce un cese să AJUTE o echipă Scrum? programator ar trebui să revizuiască scripScrum - cea mai folsită „aroma” de turile sau cazurile de test? Nu este vorba Agile - este un model al unui proces de despre o verificare din punct de vedere dezvoltare software. Se pune accent pe sintactic, dar să se asigure că munca procolaborarea între membrii echipei și între prie funcționează conform cu așteptările echipă și client în dorința de a răspunde clientului și dincolo de cazul trivial (happy mai repede nevoilor clientului, de a livra flow)! A contestat vreodată cineva rolul sau într-un timp mai scurt și de a reacționa activitățile managerului de proiect într-o mai bine la schimbare. Conform definiției, echipă Scrum? Doar există Scrum Master o echipă Scrum trebuie să fie capabilă să se care să conducă echipa! Sau, pentru că organizeze independent și să aibă un nivel există un Product Owner, de ce un rol de suficient de maturitate. Fiecare nevoie este Requirement Engineer specializat? Această acoperită, fiecare membru își cunoaște dezbatere ar putea continua la nesfârșit. reponsabilitățile, știe exact ce are de făcut Quality Assurance poate ajuta o echipă Scrum să-și clarifice scopul și să păstreze 2 http://agilemanifesto.org/history.html ritmul și direcția astfel încât să-și atingă 3 http://agilemanifesto.org/principles.html

acel scop fără prea multe devieri pe parcurs. Ajută de asemenea la stabilirea unor responsabilități clare fiecărui rol implicat în procesul de dezvoltare. Prin definirea clară a unui mod de lucru, indiferent că vorbim despre dezvoltare propriu-zisă, despre felul în care sunt tratate defectele sau despre implementarea unor metode efective de monitorizare și control, se poate reduce riscul repetării acelorași greșeli pe parcursul dezvoltării produsului sau în cazul unuia nou. Când există un traseu clar, măsurabil, înspre scopul final se pot observa mai ușor eventualele deviații și permite să se intervină înainte ca acestea să se transforme în adevărate probleme pentru parcursul proiectului.

Este un mecanism de siguranță ce poate preveni sau reduce semnificativ daunele ce pot să apară în unele cazuri. Un design sau un proces de dezvoltare perfect încă nu s-a inventat. Într-adevăr, câteodată costurile de implementare ale unui proces de calitate eficient pot fi și mai mari decât beneficiile (cum ar fi de exemplu un proiect mic, ce se poate realiza într-o perioadă scurtă iar corectarea eventualelor defecte poate fi suportată cu ușurință de către organizație). Într-un astfel de scenariu o firmă se poate baza pe experiența echipei, dar aceste cazuri sunt excepții și nu trebuie generalizate.

Prin observarea și revizuirea continuă a fiecărui aspect al produsului și a modului de lucru, întregul proces de dezvoltare prinde viață și evoluează în timp.

Metodologia Scrum se concentrează asupra procesului de dezvoltare propriu-zisă a software-ului, dar aceasta nu e suficient pentru crearea unui produs de succes.

Dacă cineva ajunge să cunoască cele două lumi (Agile/Scrum și metodologia bazată pe procese) poate ajunge la un moment „evrika”, în care își dă seama că acele două lumi nu se exclud reciproc!

Poți defini un proces de lucru viu, care

www.todaysoftmag.ro | nr. 33/martie, 2015

33

management Quality Assurance în Agile evoluează ca răspuns la schimbări, după modelul Agile. Sau, dacă se alege Scrum ca „armă” principală pentru dezvoltare, tot trebuie să implementăm un sistem de management al calității sau să ne asigurăm că cerințele produsului acoperă în întregime nevoile de business ale clientului. Acest fel de a privi lucrurile nu este nou și nici foarte dificil de implementat!

Cea mai dificilă încercare este schimbarea modului de a gândi al membrilor echipei, să privească dincolo de task-ul curent sau de obiectivele pe termen scurt. Să faci o întreagă echipă să înțeleagă că scopul final nu este terminarea tuturor task-urilor la timp pentru demo ci construirea unui produs de care cineva își va aminti și peste doi-trei ani. În plus, toată experiența câștigată în timpul proiectului nu se va pierde și va putea fi folosită în viitor.

Iată ce spune Peter Leeson despre acest subiect4: Over the years, different terminologies have come into existence, which are considered as the new way of doing things. In theory, it means that people have identified the weaknesses of the way they are working and are therefore trying to find a new, more successful approach. In reality, it appears that the weaknesses due to misunderstanding and misapplication of basic principles have led to results which are very different from what was originally expected.

We then get a group of people who believe that the new approach is the solution to all their previous problems and start following it with religious fervour, throwing out anything which does not correspond to the new vocabulary and focusing only on applying what they have understood from what they have read in a book - soon they are producing the same mistakes as previous generations and it becomes time for someone to re-create the basic ideas... În concluzie, la fel ca în multe aspecte ale vieții de zi cu zi, adevărul este undeva la miloc. Nu există un adevăr absolut și niciun grup nu poate susține că are răspuns la orice întrebare. Nu există niciun „silver bullet” sau panaceu pentru orice încercare ce am putea-o întâlni.

Care este viziunea asupra asigurării calității?

ISDC a răspuns provocărilor de mai 4 http://www.qpit.net/blog/getting-started-101-pro-

cess-agile-or-lean.html

34

sus urmând calea de miloc. În urmă cu mai mult de cinci ani, cu suport total din partea echipei manageriale, un grup entuziast a început munca la ceea ce avea să devină un mod de metoda internă standard de implementare a calității și de dezvoltare continuă a tuturor activităților zilnice.

Fiecare proiect de succes a fost analizat și un set de bune practici a fost extras din experiența câștigată de-a lungul anilor.

Aceste practici au fost grupate pe arii specifice ce acoperă fiecare aspect din „viața” unui proiect. Astăzi sunt 24 de procese definite ce includ aproximtiv 300 de taskuri descrise în detaliu (cine execută? Cum ar trebui executat? Când? Plus criterii de intrare/ieșire). Au fost definiți indicatori și măsurători specifice acestor indicatori.

Acest grup funcționează și azi, analizând măsurători, răspunzând întrebărilor colegilor și implementând sugestiile de îmbunătățire ce vin din organizație.

Procesele astfel definite au devenit un standard intern și apoi a început munca de răspândire a experienței sintetizate în procesele definite înapoi în organizație.

Este imposibil să definești un proces ce să se potrivească oricărei situații, în orice proiect. Ca urmare s-a creat și un set de reguli pentru ajustarea proceselor definite astfel încât procesele să răspundă cât mai bine nevoilor proiectului. Acest set de reguli este de asemenea revizuit constant și este îmbunătățit continuu împreună cu definițiile proceselor.

A fost creată și o echipă specializată în quality assurance, condusă de Quality Manager, pentru a asigura suport echipelor de proiect în definirea unui plan de management al calității, în definirea obiectivelor de calitate ale produsului ce urmează a fi dezvoltat și de definire a unui mod de lucru standard pentru întreaga durată de viață a proiectului. QA Team observă modul de lucru într-un proiect și propune îmbunătățiri pe baza definițiilor de proces de la nivelul organizației sau promovează practicile ce pot aduce îmbunătățiri în munca altor echipe. QA Officers sunt un grup independent iar prin aceasta se asigură obiectivitatea evaluărilor modului de lucru al echipelor cu care colaborează.

Pe lângă evaluări, QA Team identifică și documentează deviațiile, oferă feedback echipelor și conducerii pe tema caltății și a modului de lucru și se asigură că eventualele neconformități sunt adresate la timp. Pentru că lucrează aproape de echipele din proiecte QA Officers sunt în prima linie de promovare a standardelor interne și ajută la colectarea de feedback pentru

nr. 33/martie, 2015 | www.todaysoftmag.ro

dezvoltarea ulterioară a definițiilor de proces la nivel de organizație. Standardul intern ISDC a fost construit pe baza modelului “Capability Maturity Model Integration for Development” (CMMIDEV v1.3) creat de Software Engineering Institute, un centru de cercetare nonprofit de la Carnegie Mellon University5.

Practicile interne ISDC au fost evaluate și certificate la nivelul 3 de maturitate conform standardelor SEI – ISDC fiind una dintre puținele organizații ce au obținut această recunoaștere în România.

Asigurarea calității este permanent în atenția tuturor de la ISDC deja de multă vreme. În afară de dezvoltarea continuă a proceselor și a tool-urilor folosite există o preocupare constantă în direcția îmbunătățirii factorului uman din ecuația calității: se organizează sesiuni „Continuous Improvement” destinate angajaților, iar QA Officers se întâlnesc mereu, formal sau informal, cu oricine are nevoie de un răspuns legat de asigurarea calității. Suntem vizitați cu regularitate de consultantul nostru extern și sesiunile organizate în aceste ocazii sunt deschise tuturor. Chiar dacă principalul proces de dezvoltare al produselor noastre este Scrum există procese definite și pentru alte arii de proces. De exemplu: project planning; risk management; requirements development and management, release and configuration management, quality management și lista poate continua. Prin tot acest efort se încearcă reducerea probabilității apariției crăpaturilor în produsele noastre din cauza că vreun mic pas a fost trecut cu vederea la un moment dat și care se poate întoarce împotriva noastră într-un moment nepotrivit. Desigur, această posibilitate nu poate fi eliminată în întregime, dar depinde numai de noi să ne asigurăm că menținem aceasta la cel mai scăzut nivel posibil.

Bibliografie 1.

2.

3.

4.

CMMI® for Development, version 1.3 – Improving processes for developing better products and services, November 2010,Technical report http://agilemanifesto.org/ http://www.qpit.net/blog.html - o serie de articole scrise de Peter Leeson, CMMI and Process Improvement Lead Appraiser and Instructor at Q:PIT Ltd.(http://www.qpit.net/ contact-us.html) ”Quality Assurance - Making Process Work” – Peter Leeson la ISDC, Mai 2014 5 http://www.sei.cmu.edu/

programare

Dezvoltarea aplicațiilor securizate în Java

V

om începe acest articol cu câteva considerente generale despre securitate. Astfel, scopul securizării calculatoarelor este acela de a proteja informațiile existente pe acestea de furt, de corupere sau dezastre naturale.

Silviu Dumitrescu

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

Diana Bălan

Diana.Balan@accesa.eu Java developer @ Accesa

Securitatea trebuie înțeleasă ca o măsură existent este dificil și generator de erori. de compromis. De exemplu, cea mai bună • Duplicarea: codul duplicat este posimetodă de a face o aplicație complet secubil a nu fi tratat consistent la copiere. Mai rizată în Internet este să nu o conectăm la mult, aceasta violează și principiul prograInternet. mării Agile, Don’t Repeat Yourself (DRY).

Unul dintre aspectele importante ale • Restricționarea privilegiilor: când securității este confidențialitatea, care reprecodul operează cu privilegii reduse, atunci zintă ascunderea surselor de informații. exploatarea defectelor este dejucată.

Mecanismele folosite pentru realizarea • Trust boundaries: stabilirea limitelor confidențialității sunt: încriptarea, folosirea între diferitele părți ale aplicației. Spre parolelor și controlul accesului adică acordaexemplu, orice date care vin dintr-un rea accesului la resurse unui număr limitat browser web, într-o aplicație web, trebuie de persoane. verificate înaintea utilizării.

Un alt aspect este integritatea, care • Verificarea securității: efectuarea veriînseamnă că datele sunt protejate față de ficărilor de securitate în câteva puncte modificări neautorizate. Aceasta este readefinite și returnarea unui obiect pe care lizată de obicei prin autentificare. User-ul codul client îl reține, astfel încât să nu mai trebuie să furnizeze credențiale (username fie nevoie de verificări ulterioare. si password). În plus, sistemele de detecție • Încapsularea: folosirea privată a trebuie să fie folosite în cazul în care sisteinterfețelor și a câmpurilor și evitarea mul de autentificare eșuează. Acest sistem accesorilor. este format din loguri de acces și pattern-i de analiză.

Tipuri de amenințări de securitate Un ultim aspect este disponibilitatea, care Putem să împărțim amenințările în reprezintă abilitatea de a utiliza un sistem sau următoarele categorii: o resursă la nevoie.

• Injecția și incluziunea; Cel mai simplu mod în care un sistem • Gestionarea resurselor (buffer overeste vulnerabil îl reprezintă atacurile de refuflow, denial of service)Ș zare a serviciilor. Acestea blochează accesul • Informațiile confidențiale; la sistem al utilizatorilor sau reduce nivelul • Accesibilitatea și extensibilitatea; de performanță al sistemului. Sistemul ar • Mutabilitatea. trebui să fie atât de flexibil încât să detecteze aceste atacuri și să răspundă la ele.

Injecția și incluziunea reprezintă un atac ce determină un program să interpreteze date Aspecte de securitate la nivelul software- într-un mod neașteptat. De aceea, orice date urilor venite dintr-o sursă nesigură trebuie validate.

Orice sistem ce conține informații Principalele forme de atac sunt: confidențiale este foarte probabil o țintă a • Cross-site scripting (XSS), atacatorilor.

• SQL Injection, Câteva dintre conceptele fundamentale • OS Command Injection, de securitate sunt: • String-uri formatate necontrolat.

• API-uri securizate: este mult mai ușor să concepem un cod securizat încă de la Vulnerabilitățile XSS apar atunci când: început. Încercarea de a securiza codul • date provenind din surse lipsite de www.todaysoftmag.ro | nr. 33/martie, 2015

35

management Dezvoltarea aplicațiilor securizate în Java încredere intră într-o aplicație web.

• aplicația web generează dinamic o pagină web ce conține date nesigure.

• pe timpul generării paginii web aplicația nu previne datele din conținutul executat de browser, precum JavaScript, tag-uri HTML, atribute HTML, evenimente ale mouse-ului, Flash sau ActiveX. • utilizând un web browser, victima vizitează pagina generată, ce conține un script malițios ce a fost injectat de date nesigure.

• script-ul care vine dintr-o pagină web ce a fost trimisă de serverul web, victima execută script-ul malițios în contextul domeniului serverului web.

• victima violează politica unui browser web, care spune că script-urile dintr-un domeniu nu ar trebui să fie capabile să acceseze resurse sau să ruleze cod într-un alt domeniu.

Următorul exemplu ilustrează un atac XSS: <%@page contentType=”text/html” pageEncoding=”UTF-8”%> <!DOCTYPE html> <html> <head> <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8”> <title>Login Page</title> </head> <body> <h2>Bine ati venit</h2> <p>Va rog sa va logati</p> <form method=”GET” action=”/XssExample/ProcessForm”> <b>Login Name: </b> <input type=”text” size=”12” maxlength=”12” name=”userName” /> <br/> <b>Password: </b> <input type=”text” size=”12” maxlength=”12” name=”password” /> <br/> <b>Locatia: </b> <input type=”text” size=”12” name=”location” /><br/> <input type=”submit” value=”Submit” /> <input type=”reset” value=”Reset” /> </form> <p><a href=”http://localhost:8080/XSS/Pro cessForm?userName=Bob&password=Smith&location=</ p>%3CScript%20Language%3D%22Javascript%22%3Ealert(% 22Ai%20fost%20atacat!%22)%3B%3C%2FScript%3E”>Hacked URL</a></p> <p>URL Script text: %3CScript%20Lang uage%3D%22Javascript%22%3Ealert(%22vei%20fi%20 atacat!%22)%3B%3C%2FScript%3E</p> </body> </html>

Respectiv servletul: @WebServlet(“/ProcessForm”) public class ProcessForm extends HttpServlet { private static final long serialVersionUID = -5014955266331211217L; protected void processRequest( HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType(“text/html;charset=UTF-8”); PrintWriter out = response.getWriter(); try { out.println(“<html>”); out.println(“<head>”); out.println( “<title>Servlet de procesare</title>”); out.println(“</head>”); out.println(“<body>”); out.println(“<h2>Prima pagina</h2>”); out.println(“<p>sunteti logat ca: “ +

36

nr. 33/martie, 2015 | www.todaysoftmag.ro

request.getParameter(“userName”) + “</p>”); out.println(“<p>si sunteti in: “ + request.getParameter(“location”) + “</p>”); out.println(“</body>”); out.println(“</html>”); } finally { out.close(); } } @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); } @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); } @Override public String getServletInfo() { return “Servletul meu”; } }

SQL Injection se bazează pe date nefiltrate pentru a modifica rezultatele SQL. Fie următorul cod: ResultSet rs = stmt.executeQuery (“SELECT * FROM DEMO.Table1 WHERE NAME=’” + nameParam + “’ AND AGE =’” + ageParam + “’”);

Dacă atacatorul trimite: ‘valori’ OR ‘a’ = ‘a’, acesta va face predicatul de selecție adevărat, ceea ce este echivalent cu: ResultSet rs = stmt.executeQuery (“SELECT * FROM DEMO.Table1”);

Prin aceasta atacatorul poate accesa informații confidențiale sau chiar modifica date din baza de date. De aceea orice input trebuie filtrat înainte de utilizare.

OS command injection se bazează pe date nefiltrate ce modifică o comandă a sistemului de operare.

Fie următorul exemplu: public class ListHomeDir { public static void main(String[] args) { String userName = “Silviu”; String curLine = “”; try {

Process p = Runtime.getRuntime().exec(

“cmd /c dir C:\\Users\\” + userName);

BufferedReader stdInput = new BufferedReader(new InputStreamReader( p.getInputStream()));

BufferedReader stdError = new BufferedReader(new InputStreamReader( p.getErrorStream()));

TODAY SOFTWARE MAGAZINE System.out.println(“Home directory este:”); while ((curLine = stdInput.readLine()) != null) { System.out.println(curLine); } if (stdError.ready()) { System.out.println(“eroare:”); } while ((curLine = stdError.readLine()) != null) { System.out.println(curLine); } System.exit(0); } catch (IOException e) { System.out.println(“exceptie: “); System.out.println(e.getMessage()); System.exit(-1); } } }

În exemplu dorim să obținem un listing al unui director.

Atacatorul poate trimite: username;&&del *.*;, ceea ce va determina pierderea de date.

Fie următorul e xe mplu de format necontrolat de string-uri: public class Main { static Calendar c = new GregorianCalendar(1995, GregorianCalendar.MAY, 23); public static void main(String[] args) {String param = “%1$tY”;

System.out. printf(param + “ nu se potriveste!

A fost emis in ziua %1$te \n”, c); } }

• billion laughs attack: dacă utilizăm API-ul DOM pentru un document XML trebuie să încărcăm întregul document în memorie. Un atac ca acesta poate înghiți întreaga memorie.

• XPath: este un limbaj pentru interogări și traversări de documente XML. Unele interogări pot fi recursive și pot returna un volum de date mai mare decât cel așteptat.

• Object Graph: un obiect graf construit prin parsarea unui text sau a unui stream binar poate avea cerințe de memorie mult mai mari decât datele originale.

Fie următorul exemplu:

public class FileException {

Properties appProps = new Properties();

public static void main(String[] args) {

FileException app = new FileException();

app.readProps(“AppConfig.properties”);

app.printProps(); }

public void readProps(String fileName) {

try {

appProps.load(new FileInputStream(fileName));

} catch (IOException e) {

System.out.println(“Nu putem gasi fisierul “+

“de configurare: “ + e.getMessage());

e.printStackTrace();

System.exit(-1); } } public void printProps() { appProps.list(System.out); } }

Sistemul nu ar trebui să furnizeze potențialilor atacatori locația exactă a fișierului de configurare al aplicației.

Informațiile confidențiale ar trebui să fie disponibile spre citire doar într-un context limitat, să nu fie disponibile pentru manipulare, să se furnizeze utilizatorilor doar informațiile de care au nevoie, informațiile să nu fie hard cod-ate în surse.

Datele confidențiale nu ar trebui incluse în excepții sau fișiere de log. De asemenea, nu ar trebui să hard cod-ăm username-ul și parola în codul sursă. Ar trebui folosit un fișier de proprietăți pentru a stoca acest tip de informații. În acest cod proDăm mai jos un exemplu de creare și folosire a unui fișier gramatorul încearcă de log. să printeze rezul- public class BasicLogging { tatele atunci când Logger logger = Logger.getLogger(“com.example. două valori nu se BasicLogging”); potrivesc. Problema public void logMessages(){ logger.severe(“A aparut o problema severa”); poate apare atunci logger.warning(“Avertisment”); când este trimis un logger.log(Level.INFO,”Informatie utila”); logger.config(“Informatii despre CONFIG”); string format în loc de lună. Atacatorul își poate da seama de an, } spre exemplu, atunci când un card expiră. public static void main(String[] args) { Din punct de vedere al managementului de resurse avem: BasicLogging bl = new BasicLogging(); • buffer overflows: copierea unui buffer de intrare într-un bl.logger = Logger.getLogger(“com.example”+ “.BasicLogging”); buffer de ieșire fără verificarea dimensiunii. Are ca rezultat faptul că un atacator poate executa cod în afara unui program try { bl.logger.addHandler(new FileHandler( normal. Java este imună la acest tip de atac deoarece deține un “Basic.log”)); management automat al memoriei. bl.logger.setLevel(Level.INFO); bl.logMessages(); • denial of service: este încă posibil în Java prin folosi} catch (IOException e){ rea nepotrivită a resurselor. Iată câteva exemple de atacuri e.getMessage(); } potențiale denial-of-service: } • zip bomb: un fișier zip ce este relativ mic, dar care } include multe alte zip-uri în el. De-zip-area fișierelor poate Vă dorim lectură plăcută și așteptăm cu interes întrebările bloca procesorul și înghiți un spațiu mare de memorie. Ca voastre! măsură de protecție putem limita dimensiunea și procesarea ce pot fi făcute într-o resursă ca aceasta. www.todaysoftmag.ro | nr. 33/martie, 2015

37

management

programare

Abordare simplă a riscului în Scrum

Î

Sebastian Botiș

Sebastian.Botis@endava.com Delivery Manager @ Endava

38

nr. 33/2015 | www.todaysoftmag.ro

n modelul tradițional waterfall, riscurile sunt de obicei detectate și analizate folosind metode tradiționale de management. În zilele noastre, există o oarecare deficiență în ceea ce privește identificarea și prevenirea riscurilor în dezvoltarea de software care urmează principiile Agile. Modele Agile susțin faptul că tratează riscurile implicit. Prin modul în care este definit conceptul, abordarea sa iterativă favorizează o atenție deosebită la riscuri, care pot fi reduse prin diferite practici, cum ar fi continuous software integration. Din păcate, în realitate, modelele de tip agile implementează doar câteva practici din zona de risc al managementului.

Această stare de fapt a impus necesitatea punerii în aplicare a unor remedii.

Un prim demers a fost să se obțină opinia unor manageri de proiecte implicați în managementul diferitelor proiecte din toate zonele lumii. În rândurile următoare, vom oferi o analiză referitoare la un chestionar axat tocmai pe această problemă, care a fost lansat nu cu mult timp în urmă.

Managementul de riscuri este o disciplină care se ocupă cu identificarea, monitorizarea și limitarea riscurilor.

Managementul de risc ideal/eficient este considerat acela care stabilește o ierarhie a gravității riscurilor. Se acordă prioritate riscurilor care ar cauza mari pierderi și care implică o frecvență ridicată de apariție. În ordine descrescătoare, vor fi vizate riscurile cu probabilitate mai mică de a apărea și cu efecte mai puțin dezastruoase.

Efectiv, managementul de riscuri implică următoarele: • Identificarea riscului.

• Analiza fiecărui risc pentru a determina nivelul efectelor negative.

• Ierarhizarea riscurilor identificate în funcție de frecvență și de gravitatea consecințelor.

• Crearea planurilor de acțiuni (răspunsuri) pentru a aborda riscurile cu prioritatea cea mai mare.

• Monitorizarea continuă pentru a ne asigura că planul de acțiuni dă rezultate.

Managementul de risc în procesele agile este similar celui din managementul convențional al riscului, cu mici variații. O prezentare elocventă a ceea ce presupune managementul de risc ar trebui să răspundă la două întrebări esențiale: • Ar fi bine ca riscurile să fie monitorizate doar la nivel de iterație? Răspunsul este Nu. • Este necesar să monitorizăm riscurile la nivel de proiect? Răspunsul este Da. Considerăm că managementul de risc în agile ar trebui să fie făcut la două nivele : de proiect și de iterație.

• Procesul de risc management la nivel de proiect este realizat prin luarea în considerare a datelor generale de proiect și a cerințelor acestuia.

• Procesul de risc management la nivel de iterație este făcut luând în considerare detaliile ce țin de fiecare iterație în parte.

Aceste două procese par a fi separate, dar ele merg mână în mână pe durata de execuție a proiectului.

programare

TODAY SOFTWARE MAGAZINE

Este necesar să înțelegem, să identificăm, să monitorizăm și să reducem riscurile la cele două nivele. Managementul de risc la nivel de proiect ar oferi date de intrare pentru managementul de risc la nivel de iterație. Să luăm aminte că nu toate riscurile de la nivelul proiectului, sunt parte din riscurile la nivel de iterație.

Unele riscuri pot fi diferite și altele pot fi unice doar la nivelul iterației. Monitorizarea riscurilor se face în timpul iterației, iar sesiunile de analiză a riscurilor ar trebui să aibă loc între iterații.

Se recomandă ca situația riscurilor la nivel de iterație și de proiect să fie foarte bine cunoscută.

Lista de verificare

Cred că fiecare manager de proiect, Scrum master și echipă, ar trebui să înțeleagă cerințele pentru a înțelege riscurile majore care pot apărea într-un proiect. Cel mai probabil, crearea unei liste de verificare (una similară se poate găsi mai jos) care ar putea ajuta la identificarea potențialelor riscuri, reducerea lor încă din stadiile inițiale sau planificarea unor acțiuni de atenuare a lor, ar reduce cu mult costurile proiectului.

Zona Cerințe Cerințe Design

Design

Proces

Proces

Proces

Managementul iterațiilor

Descriere Sunt cerințele pregătite?

Product Owner-ul a identificat scopul proiectului?

Designul și arhitectura sunt deja stabilite sau vor fi analizate într-o iterație separată?

Designul și arhitectura sunt determinate și echipa a înțeles acest aspect?

Echipa a mai fost implicată în traininguri Agile înainte? În caz negativ, este necesar? Întreaga echipă este pregătită și a înțeles Agile-ul înainte de a fi implicați în proiect?

Scrum master-ul a înțeles matricele care ar trebui folosite în proiectele de tip Agile?

Scrum master-ul este informat despre cerințele din backlog?

Da/Nu

Managementul iterațiilor

Scrum master-ul știe de metodologia de estimare în Agile?

Managementul Iterațiilor Infrastructură

Există un tool care poate fi folosit în managementul activităților?

Infrastructura este pregătita pentru execuția proiectului?

Există un canal de comunicare asupra căruia ați căzut de-acord în cazul în care echipa este global distribuită?

Infrastructură

Lista de verificare pentru riscuri creată înaintea unei ședințe, poate fi folosită pentru o mai ușoară identificare a acestora. În timpul ședințelor, toate riscurile sunt identificate, discutate și se ajunge la un consens asupra acțiunilor ce se vor lua pentru aplanarea acestora. Lista riscurilor la nivel de proiect și lista riscurilor la nivel de iterație sunt create și făcute cunoscute în interiorul echipei, și vor fi menținute și completate pe parcursul proiectului și a iterației.

Managerul de proiect și/sau Scrum Masterul au obligația să mențină aceste artefacte.

Managementul riscurilor la nivel de proiect

Procesul de management al riscurilor la nivel de proiect include identificarea riscurilor, planificarea, monitorizarea și activitățile de închidere a riscurilor, de la sfârșitul unui proiect.

Fiecare din acești pași are importanța sa, explicată în continuare.

Identificarea riscurilor

La începutul unui proiect, riscurile proiectului sunt identificate dintr-o perspectivă largă. Lista de verificare (dacă se creează) ar putea fi de ajutor în identificarea acestora.

Planificarea riscurilor

În timpul ședinței de planificare, planurile de atenuare ale riscurilor identificate sunt prezentate. Lista riscurilor la nivel de proiect este creată de managerul de proiect / scrum master, și echipa se poate servi de această listă la nevoie. Această activitate se face numai la demararea proiectului, iar lista de riscuri este actualizată pe parcursul derulării întregului proiect.

www.todaysoftmag.ro | nr. 33/martie, 2015

39

management

testare Abordare simplă a riscului în Scrum

Monitorizarea riscurilor

Toate riscurile identificate anterior, sunt revizuite și monitorizate în sesiunile dintre iterațiile proiectului. Lista de riscuri este actualizată, marcându-se acele riscuri care s-au închis, sau adăugându-se riscuri noi identificate pe măsura înaintării proiectului.

Aceste informații sunt apoi folosite în sesiunile dintre iterații.

Managementul riscurilor la terminarea proiectului

Lista riscurilor ar trebui actualizată cu diferite detalii despre ceea ce s-a întreprins în momentul în care echipa s-a confruntat cu diferite riscuri pe parcursul proiectului. Aceasta listă ar fi un bun punct de plecare în alte proiecte viitoare. De asemenea, documente cu cele mai bune practici și cu diferite concluzii ar putea fi create și distribuite între proiecte și echipe. În imaginea de mai jos se poate observa procesul de management al riscurilor într-un mediu de dezvoltare Agile:

Procesul de management al riscurilor la nivel de iterație

Acest proces începe chiar după prima sesiune de identificare a riscurilor la nivel de proiect. La nivel de iterație, managementul riscurilor implică mai multi pași. În mare, sunt două procese pe parcursul unei iterații, identificarea și planificarea la începutul iterației, și monitorizarea, pe tot parcursul iterației.

Startul iterației La începutul unei iterații, o ședință despre managementul riscurilor este programată. Această ședință este structurată în mai multe etape ca: înțelegerea, identificarea, analiză, prioritizarea și maparea riscurilor. Fiecare etapă are semnificația ei. Această discuție ar trebui să dureze 2 - 3 ore și ar trebui să includă toată echipa. Concluziile discuției similare la nivelul proiectului pot fi folosite ca puncte de pornire pentru aceasta discuție.

Fiecare etapă este detaliată mai jos.

ar putea începe procesul de identificare a riscurilor. În timpul sesiunii, fiecare membru al echipei ar trebui să identifice riscurile potențiale. Sunt multe metode de a modela această sesiune, iar un mod simplu și eficient ar putea fi ceva similar cu identificarea cerințelor unui proiect folosind post-it-uri . Ca o regulă de urmat, în această sesiune, nu ar trebui adresate întrebări și nici nu ar trebui se creeze discuții pe marginea cerințelor. De ce? Deoarece această sesiune are un anumit timp fix alocat, care nu ar trebui depășit.

Analiza: în această etapă, colaborarea între membrii echipei va avea un rol foarte important. Fiecare risc identificat trebuie analizat și clasificat într-o o categorie logică sau arie. De exemplu: infrastructura, proces, dependințe externe, etc. . În timpul acestui proces, fiecare risc este cuantificat și i se dă o valoare (scala nu este predefinită, dar ar trebui să fie simplă). Odată clasificarea terminată, riscurile de aceeași categorie sunt grupate și valorile lor însumate. În locul valorilor nominale, o altă posibilitate de a grupa riscurile ar fi pe baza unor probabilități de apariție, sau al valorii impactului riscului respectiv.

Stabilirea ierarhiei riscurilor : în momentul în care toate riscurile sunt clasificate și evaluate, acestea sunt ordonate descrescător, începând cu grupul cu cea mai mare valoare în fruntea listei. Pentru o iterație, luați primele trei grupuri și amânați discuțiile despre restul grupurilor pentru o alta ședință viitoare. Pe parcursul execuției unei iterații, versiunea precedentă a listei riscurilor (actualizată în timpul iterației precedente) este consultată pentru a identifica riscurile care încă sunt prezente. Acest proces va fi repetat până la finalul proiectului.

Maparea: maparea este un exercițiu rapid care se face înainte de a da startul iterației.

Primele cinci cele mai importante riscuri sunt mapate cu cerințele din backlog. Acest lucru este esențial pentru ca riscurile să fie foarte atent urmărite în timpul în care cerințele sunt implementate. Dacă nu s-a creat un backlog, acum e momentul să fie creat. Apoi ar trebui creată și lista riscurilor din iterație, împreună cu un plan de atenuare și un plan de răspuns pentru fiecare din riscurile identificate. Această listă va fi un punct de referință pentru echipă, pe tot parcursul iterației. Acest document este menținut și actualizat în timpul execuției iterației.

Poza de mai jos arată procesul uzual de management al riscurilor la nivel de iterație, detaliind pașii implicați.

Înțelegerea: echipa ar trebui să aibă o imagine foarte clară asupra cerințelor de funcționalitate cât și a celor non-funcționale. Înțelegerea cerințelor poate fi foarte folositoare în procesul de identificare a riscurilor la nivel de iterație. În timpul iterației Identificarea: din momentul în care avem o primă versiune a Monitorizarea este cheia procesului de management al risbacklog-ului produsului și o bună înțelegere a cerințelor, echipa curilor. Aceasta trebuie să existe pe parcursul întregii execuții a

40

nr. 33/martie, 2015 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE iterației. Echipa răspunde și reacționează la riscuri cum și când apar în timpul execuției, dar și pe baza listei de riscuri. Scrum master-ul/managerul de proiect ține o evidență a fiecărui risc din iterație. În cazul în care un risc amânat inițial totuși apare în iterația curentă, acest risc trebuie să fie parte din iterația următoare. Nu trebuie să pierdem din timpul acestei iterații pentru riscurile amânate, doar dacă acele riscuri devin atât de critice încât este necesar să fie cercetate în iterația curentă.

Sondaje Anul trecut, mai multe sondaje s-au efectuat în întreaga lume, implicând diferiți manageri de proiect de la companii mai mari sau mai mici, despre riscuri și managementul acestora. Am găsit recent un sondaj interesant din Europa de Est, incluzând aproxi- Concluzii mativ 70 de manageri de proiect, cu obiectivul de a afla care sunt Există foarte multă informație și foarte multe detalii despre practicile uzuale relative al managementul riscurilor din manage- instrumente specifice folosite în identificarea, clasificarea (pe mentul Agile al proiectelor. baza unor indicatori cantitativi sau calitativi), și monitorizarea riscurilor în timpul iterațiilor.

Rezultatele au fost următoarele: Chiar dacă utilizarea metodelor Agile reduce riscurile încă • 67% din respondenți analizează riscurile proiectului din fazele inițiale ale dezvoltării de software, trebuie să luăm în săptămânal. considerare tendința actuală de a include timp într-o manieră • 87% din respondenți susțin că managerul de proiect este cel mult mai formalizată și pentru managementul riscurilor. responsabil de managementul riscurilor.

• 27% din respondenți au susținut că în același timp, și pro“Risc este pauză în livrare, nu muncitori inactivi” - Ken Rubin duct owner-ul este responsabil de managementul riscurilor.

Resurse

Respondenții au fost întrebați cine este responsabil principal 1. de identificarea riscurilor. Răspunsurile au fost: echipa proiectu- 2. lui și membrii ei (80%), managerul de proiect (67%), echipa de dezvoltare și membrii ei (40%) și scrum master-ul (40%).

3. În același timp, 73% din respondenți folosesc o listă de riscuri pentru documentare, analiză și mentenanță, iar restul de 23% folosesc o altă tehnică de monitorizare sau nu documentează riscurile în nici un mod.

Respondenții au fost întrebați și care sunt atributele riscurilor pe care le documentează și le țin sub observație. Răspunsurile se pot vedea în graficul de mai jos. Respondenții au fost întrebați care din ceremoniile din Scrum este cea mai potrivită / folosită pentru a discuta riscurile cu echipa de development. Răspunsurile lor se pot vedea în graficul următor.

Risk Management in Agile Model – Monika Singh & Ruhi Saxena Project Risk Management model based on Prince2 and Scrum Frameworks – Martin Tomanel and Jan Juricek Three Key Agile Risk Management Activities – Ken Rubin

www.todaysoftmag.ro | nr. 33/martie, 2015

41

design

Importanța realizării de prototipuri

Î

n urmă cu câțiva ani, mai exact în anul 2011, am obținut primul job ca UX Designer la o companie multinațională. De atunci și până în prezent am avut oportunitatea să lucrez cu diferite metodologii de dezvoltare ale unui design, reușind să descopăr plusurile și minusurile fiecăreia.

În momentul de față am ocupația de Dezvoltând ideea, fiecare iterație are de implementare cu specificații clare și UX Designer într-un mediu Agile, într- caracteristicile sale: complete și se transformă în cele din o echipă de 17 designeri, care au ca scop a. Prima iterație este întotdeauna urmă în produsul dorit de beneficiar. principal livrarea celei mai bune experiențe partea în care se colectează toate utilizatorilor, prin produsele software dezinformațiile necesare de la experții din voltate de către companie. domeniu asupra produsului pentru Mediul mereu inovator în care am care urmează să creez designul. Toate șansa să lucrez și libertatea de a experiinformațiile sunt reverificate și de echipă menta diverse metodologii, mi-au permis din punct de vedere tehnic. Apoi stabisă încerc noi procedee de a dezvolta un lim ce funcționalitate se dorește, pentru Iterații în conceperea unui prototip design. Comparând cu metodele utilizate ca ulterior să trasez prima schiță a viiîn trecut, am decis într-un final să mă torului produs și să stabilesc flow-ul în F i e c are d e s i g ne r are propr i i l e opresc asupra uneia singure, pe care o concare designul proiectului se va desfășura. preferințe în ceea ce privește tool-urile de sider cea mai bună pentru a livra un design b. Următorul pas, iterația a doua, se care se folosește pentru îndeplinirea taskde succes: utilizarea prototipurilor. concentrează în special pe interacțiunea urilor și realizarea prototipurilor. Personal, Așadar, consider că realizarea unui utilizatorului cu prototipul și pe vali- eu prefer utilizarea tool-ului Axure pentru produs trebuie să înceapă mereu cu un darea funcționalității stabilite în prima a crea prototipuri și creionul și coala de prototip, indiferent că produsul este de tip iterație. Ce urmărim în special în această hârtie ori de câte ori am nevoie să trasez software sau de tip hardware. Prototipul iterație este modul în care prototipul o idee rapidă. De ce Axure? Pentru că se este cel care dă o idee clară, o previzualieste utilizat de către publicul țintă, mai poate dezvolta cu ajutorul său un prototip zare exactă a produsului final. Prototipul exact punem o primă versiune a acestuia html care va evolua într-un mod organic este o clonă, este un screenshot al produsula dispoziția sa și analizăm modul de de la schițe simple, în prima iterație, la un lui viitor, care va deveni complet funcțional interacțiune. Urmărim dacă utilizatorul prototip interactiv, cu design complet, gata după finalizarea implementării. se simte confortabil cu poziția anumitor de user-testing și implementare.

Pentru mine nu există nici o excepție elemente grafice, dacă este obositor penTotuși, tool-ul cel mai bun este cel alăde la această regulă. Pentru fiecare protru utilizare îndelungată, dacă identifică turi de care te simți cel mai confortabil și iect la care lucrez, pornesc de la o idee de ușor componentele esențiale, etc. . cu care îți poți realiza designurile într-un ansamblu, proiectată pe o bucată de hârtie, c. În final, în ultima iterație a pro- timp rezonabil. Ceea ce contează cu adevăajungând până la momentul în care pot să cesului de design, concentrarea este rat este rezultatul final, un design ușor de furnizez un prototip al produsului final, în asupra detaliilor vizuale și a finisă- înțeles, utilizabil și implementabil. cele mai mici detalii, indiferent că acesta rii detaliilor prototipului realizat.

Realizarea unui prototip are doar este o machetă interactivă a unui website Prototipul primește forma comerci- avantaje și din experienta mea cu diverse sau o simulare 3D a unui obiect. ală, prin elemente grafice complexe și modalități de lucru, este o metodă preferaProcesul se desfășoară în iterații, cu repoziționarea componentelor, dacă bilă în detrimentul realizării unui produs fiecare iterație prototipul căpătând mai este necesar, pe baza feedbackului rezul- pe principiul “mergem înainte, implemenmulte detalii, devenind mai puternic, tat din analiza interacțiunii utilizatorilor tăm din mers și îmbunătățim pe parcurs”. până în momentul în care este considerat cu acesta. Colectarea acestui feedback Beneficiarul produsului va ști exact ce funcțional și gata pentru implementare. este esențială, întrucât, în momentul în intră în producție și ce va primi la finalul care designul este validat, trece în etapa acesteia.

42

nr. 33/martie, 2015 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Voi detalia cinci dintre multiplele ca acesta să cunoască faptul că este analiavantaje ale utilizării unui prototip: zat. Comportamentul său în interacțiunea cu produsul va fi natural și realist, diferit 1. Simulează produsul real de atunci când este invitat la o sesiune de Cel mai important avantaj al unui user testing, sesiune în care ar ști că este prototip este acela că simulează produ- analizat. sul real și viitor. Cu ajutorul acestuia se Cu toate acestea, user testing-ul în care pot atrage clienți care să investească în utilizatorul este monitorizat live este cea produs, înainte de a aloca orice resursă mai bună metodă în a depista problemele necesară implementării. Se poate testa cu care se confruntă acesta, deoarece există corectitudinea designului înainte ca acesta posibilitatea de a culege cât mai multe să ajungă în producție și se pot descoperi feedbackuri și să vedem unde greșește în erori de proiectare, evitând compromite- îndeplinirea task-urilor de utilizare. În rea întregului proiect. De asemenea, un cadrul mediului nostru de lucru mereu prototip pus la dispoziția unui eșantion de includem în procesul de design aplicautilizatori ajută la descoperirea din timp rea de survey-uri potențialilor utilizatori a modului de interacțiune al acestora cu în legătură cu produsul ce urmează a fi produsul și se cunosc așteptările lor. dezvoltat. Dintre respondenți, îi selectăm pe aceia care ar avea cea mai mare 2. Provoacă la crearea de idei noi tangență cu produsul dezvoltat și care Fiecare persoană are propria viziune au bifat opțiunea pentru disponibilitate asupra produsului ce urmează a fi imple- de a participa la sesiunile de usability tesmentat și, în principiu, dorește ca această ting. Aceste sesiuni se desfășoară online. viziune să se regăsească în produsul final. Fiecare utilizator partajează propriul Expunerea prototipului ajută la o unifor- ecran, pentru a ne demonstra modul în mizare a tuturor ideilor și dă posibilitatea care interacționează cu prototipul, rolul beneficiarilor să vadă produsul dintr-o nostru fiind de a depista acele secțiuni ale altă perspectivă, să îl vadă materializat și designului unde întâmpină dificultăți. În să ofere un feedback mai concentrat pe funcție de informațiile colectate din aceste detaliile dorite, pe ceea ce inițial aveau sesiuni, modificăm prototipul și organiîn minte. Începând de la un prototip low- zăm ulterior altă sesiune de testare. fidelity care este axat pe flow-uri și care direcționează utilizatorul spre review-uri 4. Planificare ale funcționalității, se ajunge în cele din Echipele care implementează desigurmă la un prototip high-fidelity unde nul primesc informații esențiale care îi se obține feedback privitor la detaliile ajută să planifice ceea ce trebuie să implede modelare vizuală, cum ar fi fonturile, menteze. Un prototip poate fi considerat, culorile, alinierile, mărimea butoanelor, cel mai adesea specificația proiectului și etc.. Feedbackul este esențial pentru a des- ajută întreaga echipă să creeze user stories coperi care sunt necesitățile și așteptările și să se concentreze asupra necesităților utilizatorilor, cerințele de business și pen- utilizatorilor. tru a avea o idee clară a direcției în care se Dacă acesta este realizat la timp, înaîndreaptă produsul. intea începerii unui Sprint, va aduce doar beneficii în echipele de Scrum.

3. Previne orice problemă majoră Din experiența mea, am observat că Conceperea unui prototip care poate deținerea unui prototip interactiv ajută fi supus cât mai rapid testării permite programatorii care se ocupă de implerezolvarea problemelor majore înainte ca mentare să aibă o idee mult mai clară acestea să provoace pagube financiare, asupra modului în care trebuie să conceapă dacă ar ajunge în producție. Prin punerea interacțiunea componentelor designului. prototipului la dispoziție unor utilizatorii Prin prototip se comunică mult mai clar reali pentru testare, se obțin în avans toate ceea ce am dori să se implementeze în sugestiile și așteptările, înaintea intrării realitate, materializându-se viziunea din produsului în producție. prima iterație.

Dintre multiplele metode de a depista problemele cu care se confruntă utiliza- 5. Este rapid și ușor de creat torii, Google Analytics spre exemplu, un Chiar și un beneficiar al produsului tool folosit foarte des de către mine, oferă poate ajuta la dezvoltarea unui prototip. posibilitatea de a interpreta datele de Esențial este să furnizeze o simplă idee pe utilizare ale unui produs de către un uti- hârtie, pentru ca designerul să înțeleagă lizator aflat în spațiul său confortabil, fără funcționalitățile și logica produsului. Acest

simplu sketch, care, de exemplu, poate fi o ilustrație cu câteva butoane pentru un website, va fi transformată de un designer experimentat într-un produs complex, extrem de detaliat, gata spre a fi aprobat pentru implementare.

Concluzie

Am încredere că acest articol a adus un plus de valoare asupra conceptului de prototip în cadrul producției software, demonstrând cât este de important a-l avea. Impactul său asupra produsului final este fenomenal. Nu doar că previne orice problemă majoră în cadrul producției și protejează compania de costuri neprevăzute, dar duce și la o eficientizare a muncii, formează o imagine de ansamblu a tuturor părților implicate (programatori, ingineri de testare, product owner-i, beneficiari) și de asemenea, este o resursă excelentă care poate fi folosită în pre-sales.

Cătălin Timofti

ctimofti@sdl.com UX Designer @ SDL

www.todaysoftmag.ro | nr. 33/martie, 2015

43

programare

Java Chronicle în acțiune

P

rocesarea fișierelor relativ mari nu este o operație atât de ușoară care să poată fi realizată prin apelul la instrumente, care au tradiție în aceste chestiuni, precum Hadoop, mașini foarte puternice, librării pentru concurență, altele decât cele standard Java.

Folosirea acestora are drept efect costuri suplimentar de timp, de bani și de personal specializat.

De exemplu, dacă în timpul procesării trebuie să validezi părți din conținut cu ajutorul unui serviciu extern și folosim Hadoop-ul pentru procesarea fișierului, se demonstrează că această practică este greșită. Toate informațiile cu care interacționează procesul ar trebui să fie parte din HDFS. Folosirea mașinilor mai puternice (virtuale sau fizice – scalare orizontală) este un subiect destul de sensibil, pentru că unii clienți nu doresc să plătească sume mai mari de bani doar pentru a face o singură funcționalitate să fie mai rapidă, care de multe ori nici nu este prea des folosită.

Utilizarea tehnologiilor pentru concurență încă reprezintă un impediment destul de mare, chiar și cu noile abstractizări care ne sunt puse la dispoziție precum tehnologiile bazate pe conceptul de actori. Lucrurile nu s-au simplificat ci au devenit mai neclare deocamdată.Din păcate, trendul este să înțelegem/cunoaștem cât mai puțin din aceste librarii, chiar și din pachetul de concurență pus la dispoziție de Java. Știu că pentru unii, realizarea acestei funcționalități e deja clară: citirea fișierului linie cu linie, o procesăm, apoi salvăm starea folosind clase de bază din Java. Banal! – notez această idee de acțiune cu 1.

Soluția aplicată: Chronicle. Java Chronicle.

Ce dorește să fie acestă tehnologie: “Comunicare între procese ( IPC ) cu latență foarte mică de sub o milisecundă și capabilă să salveze fiecare mesaj.”

Img. Schema pentru model de utilizare - Chronicle-Queue (2015)

Schema noastră de utilizare:

Dar așteptați, aceasta nu e tot…

Dacă adaug ca procesarea să fie o acțiune de tipul totulsau-nimic, unde avem proces de validare pentru fiecare linie în parte, contorizări ale lor, alte detalii din antet sau subsoluri chiar și grupuri de entități, adică grupuri de linii care de fapt reprezintă o singură entitate. Apoi, dacă fișierul e validat cu cerințele specifice fiecărei funcționalități, salvăm entitățile create pentru fiecare linie, sau grup de linii. Cu noua cerință observăm că ideea notată cu 1, nu ne mai ajută pentru că mai întâi trebuie să validăm fișierul, iar dacă acesta e valid, atunci să salvăm datele create pe baza lui. Salvarea pe heap a datelor cu dorința de a le persista la final reprezintă o soluție pentru fișierele mici - dar totuși să nu uităm că într-o aplicație “multitenancy” resursele fizice trebuie atent distribuite – astfel că memorarea lor temporară poate cauza OOME (JVM-ul rămâne fără resurse, ceea ce cauzează ca aplicația să fie oprită) pentru fișierele mai mari (de ex. > 500 MB).

44

nr. 33/martie, 2015 | www.todaysoftmag.ro

Proces: 1. creează cronica (IndexedChronicle).

ChronicleConfig config = ChronicleConfig.DEFAULT. clone(); Chronicle entitiesChronicle = new IndexedChronicle(“path”, config);

2. citirea liniilor din fișier.

3. deserializarea liniilor (folosind tehnologia BeanIO – nu intră în scopul acestui articol) în POJO. 4. validarea entității citite (în funcție de tip).

5. crearea de entități adiacente (legate de logica aplicației)

TODAY SOFTWARE MAGAZINE folosind detalii din entitatea citită anterior.

6. serializarea (BytesMarshallable) entitatății/entităților : public void writeMarshallable(@NotNull Bytes out) { if (null == entityUuid) { out.writeBoolean(false); } else { out.writeBoolean(true); out.writeUTFΔ(entityUuid.toString()); } … writeListEntityMessages(messages, out); out.writeStopBit(-1); }

7. scrierea lor în cronică (ExcerptAppender): // Start an excerpt with given chunksize int objectSize = getObjectSize(entity); //how many bytes entitiesAppender.startExcerpt(objectSize); // Write the object bytes entity.writeMarshallable(entitiesAppender); // pad it for later. entitiesAppender.position(objectSize);

Întrucât un număr poate exprima mai mult decât o mie de cuvinte, rezultatele sunt în tabelul de mai jos. Ținerea acestor entități în memoria heap nu este ceva realizabil pe hardware ieftin, dar memorarea folosind chronicle-queue devine ceva trivial.

Concluzii

După cum se poate observa,timpul necesar pentru scrierea și citirea din cronică (memory-mapped file) durează aproximativ cât citirea fișierului. Așadar, dacă optați să citiți fișierul încă o dată (după validare) și să folosiți chronicle, serializarea și deserializarea obiectelor vin fără alt cost, întrucât timpii de mai sus includ acest lucru. În plus, a durat doar două ore până am avut capacitatea să salvam entitățile în cronică, deoarece API-ul e foarte simplu de utilizat și înțeles.

Versiuni mai noi ale librăriei aduce funcționalități mai specializate: • chronicle queue, • chronicle map, • chronicle logger, • chronicle engine, • chronicle set.

8. citirea fișierului dacă toate condițiile sunt trecute cu succes.

Este evident că exista mulți alți factori care ar trebui luați în 9. citim din cronica (ExcerptTailer): considerare, dar bazat pe nevoile noastre, această soluție este scalabilă și a fost aplicată cu cel mai mic efort.

ExcerptTailer reader = entitiesChronicle.createTailer(); Entity entity = new Entity (); entity.readMarshallable(reader);

10. deserializăm: public void readMarshallable(@NotNull Bytes in) throws IllegalStateException { StringBuilder valueToRead = new StringBuilder(100); boolean hasId = in.readBoolean(); if (hasId) { entityUuid = readUuidValue(valueToRead, in); } … messages = readListEntityMessages(in); in.readStopBit(); }

Vasile Mihali

vasile.mihali@arobs.com

11. salvăm entitățile și alte stări în Cassandra: 12. închidem și ștergem cronica:

Senior Software Engineer @ Arobs

entitiesChronicle.close(); entitiesChronicle.clear();

Nr. linii

Citire linii Entitate (de bază) (millis)

FileEntity (adiacentă)

BusinessEntity1 BusinessEntity2 S c r i e r e î n C i t i r e d i n (adiacentă) (adiacentă) c ron i c ă c ron i c ă (millis) (millis)

1068107 (~200M)

850

5000

5000

5000

5000

918

350

2136214 (~400M)

1312

10000

10000

10000

10000

1290

448

12817284 (~2.3G)

7423

60000

60000

60000

60000

5071

1530

25634568 (~4.7G)

13382

120000

120000

120000

120000

9026

3154

CPU Intel i5-2410M @2.3GHz, 16GB Ram, JVM - 1GB

www.todaysoftmag.ro | nr. 33/martie, 2015

45

programare

Apache Cassandra, Primii Pași

A

fost o vreme când tehnologiile NoSQL erau considerate un trend, un termen la modă, în esență ceva care nu era aplicabil în viața de zi cu zi. În ziua de azi însă, cred că NoSQL nu mai reprezintă o moda și chiar și companiile de dimensiune medie se confruntă cu problema volumului crescător de date. În această situație, scenariul migrării de la o bază de date relațională la una de tip NoSQL devine tot mai comun datorită avantajului principal al acestor tehnologii: posibilitatea de a scala aplicațiile în clustere. cqlsh:demo>

Acest articol va prezenta cum se instalează o bază de date de cqlsh:demo> select * from users where id = ’1’; tip Cassandra și cum se poate crea un cluster Cassandra prin adăid | name ugarea mai multor noduri. Vom vedea cum se utilizează linia de ----+-----1 | John comandă, cum arată limbajul de interogare (CQL) și un exemplu de clasă Java care folosește un client API Cassandra. În final vom (1 rows) discuta despre limitările acestei soluții NoSQL, modul cum acestea pot fi depășite și câteva recomandări generale.

Singurul aspect necunoscut din exemplul de mai sus ar trebui să fie conceptul de keyspace care se aseamănă cu schema din baza Cum se instalează Cassandra de date Oracle și conține informații despre cum trebuie replicate Baza de date Cassandra este una din cele mai utilizate baze datele în cluster-ul de Cassandra. de date NoSQL oferind cele mai bune rezultate pentru scalarea performanței și posibilitatea de a distribui în mod partiționat setul Clustere Cassandra de date pe nodurile din cluster în mod gratuit (licența Apache Pentru a putea scala performanța unei aplicații, Cassandra 2.0). Următorul grafic creat de compania DataStax compară 5 permite configurarea de clustere de noduri Cassandra. Prin utilidin cele mai utilizate soluții NoSQL din care reiese performanța zarea cluster-elor o aplicație poate beneficia de un grad ridicat de superioară a bazei de date Cassandra în ceea ce privește creșterea disponibilitate, o scalare liniară a performanței și de o interfață volumului de date procesate odată cu creșterea numărului de simplă de acces către o multitudine de servere de cost redus fără noduri din cluster. un punct unic de eșec (single point of failure). În cadrul unui context de cluster se pot defini cantitatea de date pe care un anumit nod poate să o proceseze (prin intermediul token-ilor) și pe care nod din cluster să ajungă o anumită înregistrare. Gradul de disponibilitate al cluster-ului se poate regla prin intermediul strategiei de replicare care indică numărul de copii (replica) al fiecărui rând dintr-un tabel ce trebuie să existe în cluster la un moment dat.

Pentru a crea un cluster Cassandra simplu, editați fișierul cassandra.yaml și completați următoarele valori:

Necesare pentru instalare: 1. JDK 7+ 2. Python 2.7.x

cluster_name: ’Test Cluster’ seed_provider: # Addresses of hosts that are deemed contact points. # Cassandra nodes use this list of hosts to find each other and learn # the topology of the ring. You must change this if you are running # multiple nodes!

- class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: ”16.22.70.184” listen_address: 16.22.70.184

Această bază de date poate fi instalată atât pe Linux cât și pe Windows, iar procesul de instalare este unul simplu: descărcarea și decomprimarea arhivei software, configurarea a câteva adrese pe disc folosite pentru stocarea datelor în fișierului cassandra. yaml și rularea executabilului cassandra.

După ce linia de comandă este pornită totul ar trebui să pară După ce fișierul de configurare este finalizat, instalați pachefoarte familiar. Limbajul de interogare, CQL (Cassandra Query tul Cassandra și copiați fișierul cassandra.yaml pe toate nodurile Language) e aproape identic cu SQL. din cluster. Valoarea cluster_name trebuie să fie identică pe toate mașinile. Nodurile seed sunt utilizate de către fiecare nod din cqlsh:demo> create keyspace demo with replication = ... {’class’:’SimpleStrategy’, ’replication_ cluster pentru a descoperi topologia cluster-ului (Pentru acest factor’:1}; exemplu alegeți un nod ca și nod seed și completați IP-ul acescqlsh:demo> create table users ( ... id varchar primary key, tuia pe restul mașinilor). Setați câmpul listen_address la adresa ... name varchar IP a fiecărei mașină, aceasta va fi folosită pentru a comunica cu ... ); cqlsh:demo> insert into users (id, name) values celelalte noduri. ... (’1’, ’John’);

46

nr. 33/martie, 2015 | www.todaysoftmag.ro

legal # Node 1 Configuration cluster_name: ’Test Cluster’ seed_provider: - class_name: org.apache.cassandra.locator.

SimpleSeedProvider parameters: - seeds: ”16.22.70.184” listen_address: 16.22.70.184 # Node 2 Configuration cluster_name: ’Test Cluster’ seed_provider: - class_name: org.apache.cassandra.locator.

SimpleSeedProvider parameters: - seeds: ”16.22.70.184” listen_address: 16.22.70.193

După ce toate nodurile au fost configurate și pornite, putem verifica pornirea cu succes a fiecărei mașini căutând mesajul “Listening for thrift clients...” în consola de pornire Cassandra.

Pentru a verifica starea cluster-ului, putem utiliza comanda de mai jos: e:\programs\apache-cassandra-2.1.2\bin> nodetool status Starting NodeTool Datacenter: datacenter1 ======================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack DN 16.59.61.100 ?

256 ?

9ae29fc3-b218-4ee2-904a-0db4ff5e28a3 rack1 DN 16.60.161.225 ?

256 ?

48045f86-26a4-4e1f-80fc-12dc16480319 rack1 UN 16.22.70.184 330.11 KB 256 ?

8b42a1e4-abe3-406a-96d8-12c12382b075 rack1 DN 16.22.69.37 ?

256 ? c3b3feef-41e2-4346-a86e-ec443fbd2fa5 rack1

Utilitarul nodetool folosit mai sus permite adăugarea/ștergerea de noduri în/din cluster precum și executarea unor operații de întreținere și management.

Cod Java

TODAY SOFTWARE MAGAZINE public class CassandraTestClient { private Cluster cluster; private Session session; public void connect(String node) { cluster = Cluster.builder().addContactPoint(node). build(); System.out.printf(”Connected to cluster: %s\n”, cluster.getMetadata().getClusterName()); session = cluster.connect(); } public List<Row> getUsers() { ResultSet execute = session.execute(”select * “+ ”from demo.users;”); return execute.all(); // don’t do this outside a demo } public List<Row> getUsersUsingQueryBuilder() { Select select = QueryBuilder.select().all(). from(”demo”, ”users”); return session.execute(select).all(); // don’t do this outside a demo } public void close() { session.close(); cluster.close(); } public static void main(String[] args) { CassandraTestClient client = new CassandraTestClient(); client.connect(”127.0.0.1”); System.out.println(client.getUsers()); System.out.println(client. getUsersUsingQueryBuilder()); client.close(); } }

În exemplul de mai sus, codul client se conectează la clusterul Cassandra utilizând nodul contact primit (în acest caz, mașina locală) care are rolul de a-i descoperi clientului topologia clusterului. După ce obiectul Session a fost obținut putem construi și executa interogări într-un mod foarte asemănător cum am face cu o bază de date Oracle.

Metoda getUsers execută interogarea CQL și returnează toate rândurile ca și rezultat (a se folosi doar pentru un număr mic de rânduri în tabel deoarece forțează aducerea tuturor rândurilor din tabel odată). API-ul DataStax permite și mecanismele avansate de execuție a interogărilor prezente în clienții tradiționali ai bazelor de date cum ar fi prepared și batch statements (cu toate acestea aveți grijă, batch-urile nu trebuiesc utilizate pentru performanță) și setări cum ar fi fetch size și selectarea unor politici de reconectare și reîncărcare.

Pe lângă construcția de statement-uri CQL, DataStax oferă API-ul QueryBuilder care permite crearea dinamică a interogărilor cu beneficiul de a elimina atacurile de tip injection. Metoda getUsersUsingQueryBuilder ilustrează acest mecanism.

Rezultatul rulării metodei CassandraTestClient.main() trebuie să fie:

În ceea ce privește clienții de API, Cassandra oferă o gamă largă de posibilități în funcție de limbajul de programare utilizat. Cel puțin 6 din acești clienți sunt scriși în limbajul Java, iar DataStax, Astyanax și Hector sunt printre cei mai utilizați. Pentru exemplul de mai jos vom folosi API-ul DataStax deoarece este unul din alegerile mature care dispune de o documentație clară și detaliată. (Compania DataStax este una ce investeste activ în ecosistemul Cassandra, oferind documentație pentru această bază de date ca și soluție open-source dar și dezvoltând în paralel o soluție comercială bazată pe Cassandra).

Pentru a scrie o aplicație Java simplă pentru Cassandra, începem prin a adauga dependința cassandra-driver-core în fișierul de configurare Maven, pom.xml.

Connected to cluster: Test Cluster <dependency> <groupId>com.datastax.cassandra</groupId> <artifactId>cassandra-driver-core</artifactId> <version>2.1.3</version> </dependency>

[Row[1, John]] [Row[1, John]]

Cassandra, limitări și soluții

Cu toate că baza de date Cassandra oferă multe avantaje comClasa de mai jos se conectează la instanța locală de Cassandra parativ cu soluțiile clasice de tip relațional, prezintă de asemenea și interoghează utilizatorii din tabelul creat anterior prin linia de și câteva dezavantaje semnificative. Punctele slabe ale acestei comandă. soluții sunt: i. Fără tranzacții, import com.datastax.driver.core.Cluster; import com.datastax.driver.core.ResultSet; ii. Fără JOIN-uri, import com.datastax.driver.core.Row; iii. Fără interogări complexe. import com.datastax.driver.core.Session; import com.datastax.driver.core.querybuilder.QueryBuilder; import com.datastax.driver.core.querybuilder.Select; import java.util.List;

Fără tranzacții

Cassandra nu oferă garanția atomicității și izolării la nivel de www.todaysoftmag.ro | nr. 33/martie, 2015

47

programare Apache Cassandra, Primii Pași tranzacție (de fapt, conceptul de tranzacție nu există), cu toate acestea, asigură aceste proprietăți la nivelul unui rând de tabel.

Avînd în vedere natura bazei de date Cassandra (column-oriented key-value store), garanția la nivel de rând are sens din punct de vedere al design-ului deoarece într-o baza de date NoSQL de acest tip fiecare rând ar trebui să reprezinte o entitate complexa întreagă (iar accesul atomic și izolat la acea entitate ar trebuie să fie suficient pentru a asigura consistența datelor). În ceea ce privește consistența datelor la nivel de cluster, Cassandra oferă posibilitatea de a folosi diferite nivele de consistență pentru citire și scriere. Aceste nivele pot fi rezumate la următoarea idee: Câte noduri din cluster trebuie să confirme operația de citire/scriere?

De asemenea, pentru a ajuta programatorii în a asigura consistența datelor, începând cu Cassandra 2.0, s-a adăugat conceptul de tranzacție lightweight. Cu toate că numele este promițător, functionalitatea permite operații de tip compare and set cum ar fi crearea unei inregistrări noi doar dacă nu există deja sau actualizarea unei inregistrari dacă o anumită condiție e indeplinită.

Despre problema lipsei tranzacțiilor, cunoscutul programator și autor, Martin Fowler, spune că nu trebuie privită ca și un dezavantaj major fiindcă în majoritatea cazurilor utilizarea tranzacțiilor pe perioade mari de timp poate afecta serios performanța. Astfel în [9] el propune soluția de offline lock în care setul de date este versionat iar fiecare commit necesită verificarea informației de versiune pentru setul de date implicat în operație.

Următoarea diagramă prezintă un exemplu pentru acest concept.

Fără interogari complexe

Dacă o aplicație necesită multă flexibilitate în ceea ce privește condițiile interogărilor, Cassandra nu va fi de mare ajutor. De fapt, Cassandra nu va permite • setarea unei condiții pe o coloană care nu face parte din cheia primară sau nu e indexată • In exemplul demo.users de mai sus nu putem executa CQL-ul: select * from users where name = ‘John’;

fără a crea explicit un index pe coloana name • setarea unei condiții folosind unul din operatorii IN, =, >, >=, <, or <= fără a adauga o condiție de egalitate pe cel puțin una din coloanele ce fac parte din cheie, • Dacă definim un index pe coloana name în exemplul demo.users de mai sus, folosind CQL-ul create index users_name_index on users(name);

putem executa interogarea select * from users where name = ’John’;

însă nu putem executa interogarea similară

select * from users where name in (’John’);

deoarece interogarea nu contine o condiție de egalitate În aceasta situație suntem forțați să implementăm unele interogari manual. Însă, din fericire majoritatea soluțiilor NoSQL permit integrări Hadoop iar în acest caz specific, Cassandra poate fi integrată cu 2 framwork-uri ce permit execuția de interogări, Apache Hive [5] și Apache Pig [6] (din păcate documentația despre integrarea propriu-zisă lipsește cu desăvîrșire, însă vă recomand să căutați câteva cărți cu Cassandra care includ aceste informații). Apache Hive oferă o interfață foarte similară cu SQL și CQL care nu necesită învățarea de concepte noi însă poate avea penalizări de performanță, pe când Apache Pig dispune de un limbaj de programare care permite execuția de interogări într-o manieră programatică și cu un grad mai mare de control.

Concluzie

NoSQL reprezintă un pas important în dezvoltarea mecanismelor de persistare a datelor care necesită o schimbare în modul care trebuie să gândim aplicațiile. Fie că o facem din necesitate sau din curiozitate programatică, consider că NoSQL este o tehnologie ce merită învățată.

Bibliografie 1.

2.

Fără JOIN-uri

Această binecunoscută limitare a bazelor de date NoSQL este una cu care trebuie să începeți. Crearea (sau migrarea) unei aplicații cu ajutorul Cassandra va necesita gândire NoSQL. Aceasta înseamnă remodelarea structurii bazei de date în jurul ideii de modele agregate (nu stoca un tabel cu utilizatori și un tabel cu adrese, ci stochează un singur tabel pentru utilizatori în care înregistrarea pentru utilizator include adresele necesare) chiar dacă presupune un anumit nivel de redundanță a datelor în db sau o rescriere majoră a data acces layer-ului. Cu toate aceastea, în funcție de modelul de business al aplicației, utilizarea de modele agregate ar putea simplica mult codul de persistență.

48

nr. 33/martie, 2015 | www.todaysoftmag.ro

3.

4.

5.

6.

7.

8.

Introduction to NoSQL by Martin Fowler, https://www.youtube.com/ watch?v=qI_g07C_Q5I Apache Cassandra 2.1 Documentation, http://www.datastax.com/documentation/cassandra/2.1/cassandra/gettingStartedCassandraIntro.html Apache Cassandra Installation on Windows, http://kimola.com/articles/ cassandra-installation-on-windows-platform datastax.com/documentation/developer/java-driver/2.1/java-driver/ whatsNew2.html Apache Hive, https://hive.apache.org/ Apache Pig, http://pig.apache.org/ Cassandra High Performance Cookbook by Edward Capriolo martinfowler.com/eaaCatalog/optimisticOfflineLock.html Sergiu Indrie

sergiu-mircea.indrie@hp.com Software Engineer @ HP

testare

TODAY SOFTWARE MAGAZINE

Appium - testare automată cross-platform pentru dispozitive mobile

N

ecesitatea de a scrie cod care să poată fi rulat pe mai multe platforme nu este o veste nouă. Ideea a stat la baza mașinii virtuale din Java, la platforma Mono. Această nevoie este amplificată de apariția sistemelor de operare mobile IOS și Android.

Windows Mobile nu face obiectul acestui articol, deși o bună parte din platformele enumerate sunt compatibile. Un număr imens de aplicații există pentru ambele platforme, o bună parte din ele încercând să păstreze aceeași interfață, în ciuda specificului vizual al platformei.

Existența a două platforme separate de dezvoltare pentru aceeași aplicație mai are un dezavantaj important, contracarat parțial poate de cazurile aplicațiilor care necesită performanțe maxime: necesitatea de a avea echipe separate de dezvoltare, cu expertiză în limbaje diferite (Objective-C și Java) care trebuie sincronizate din punct de vedere al managementului, pentru a oferi funcții și experiență similară pentru utilizatorii celor două sisteme de operare. Nevoia ridicată pentru o platformă de dezvoltare unitară a generat o puzderie de soluții: Xamarin (probabil cea mai populară soluție, bazată pe C#), PhoneGap (HTML5/JavaScript), Appcelerator (JavaScript), Sencha, Corona, etc. .Și pentru că testarea automată are exact aceeași nevoie, din aceleași motive, soluțiile nu au întârziat să apară. În cele ce urmează vom discuta despre Appium, una dintre cele mai eficiente soluții. (Calabash este o altă soluție care adresează aceleași probleme, dar într-un mod diferit). În mod tradițional, testele automate pentru Android folosesc framework-ul uiautomator de la Google, o soluție care folosește Java ca limbaj de programare, sau monkeyrunner, o unealtă mai simplă bazată pe Python. Testele de IOS folosesc UI Automation API, soluție oferită nativ de Apple ce folosește JavaScript ca limbaj. Ambele soluții necesită cunoștințe relativ ridicate despre specificul platformei, dar problema principală este faptul că nu există compatibilitate între ele. Orice tester care va scrie teste automate pentru ambele platforme va trebui să cunoască două limbaje de program, să întrețină două medii de testare diferite, să întrețină două seturi separate de teste, chiar și în cazul în care flow-ul este exact același pe ambele platforme. Următorul pas înspre unificarea mediului de testare a fost apariția Selendroid, respectiv ios-driver, soluții bazate pe Selenium WebDriver API, respectiv pe protocolul JSON Wire. Cu alte cuvinte, aceste soluții sunt un middleware situat între testarea automată bazată pe soluțiile native și codul familiar din Selenium WebDriver. Însă aceste soluții nu rezolvă complet problemele inițiale, reducând doar limbajul de programare la Java.

Unificarea reală a mediului de dezvoltare de testare automată

este adus de Appium (inițial folosit pentru testarea aplicațiilor IOS). Appium pornește de la patru idei esențiale: • Aplicația testată trebuie să fie nemodificată, adică să nu fie necesar instrumentation sau rooting, modificări care pot face ca testele să nu realiste – Appium nu necesită instrumentation și funcționează cu orice dispozitiv.

• Flexibilitate ridicată: existența opțiunii a mai multor limbaje de programare, de librării utilizate – există clienți Appium pentru Java, Python, JavaScript, C#, etc.; se poate integra ușor cu librării de validare ca TestNG sau jUnit.

• Utilizarea uneltelor consacrate – WebDriver este soluția cea mai utilizată pentru testare web, ca atare se folosește și în Appium, pentru testarea dispozitivelor mobile.

• Open-source – Appium este open-source și este sprijinit de o comunitate puternică.

Fiind construit peste Selenium WebDriver, Appium nu se rezumă la testarea aplicațiilor native, ci simplifică și testarea aplicațiilor mobile hibride sau web, practic reducând testul sau părțile aferente la un test clasic Selenium.

Arhitectura Appium

Appium este construit pe baza arhitecturii client/server, partea de server fiind bazată pe node.js, iar cea de client fiind reprezentată de lista de clienți disponibili pentru limbajele enumerate mai sus. Comunicarea între server și client se face prin REST, acest fapt permițând executarea de teste remote, pe alte mașini decât cea la care este conectat dispozitivul fizic sau emulatorul. Există chiar servicii cloud pentru executarea de teste, Sauce Labs fiind cel mai important serviciu de acest tip. Varianta cea mai simplă de pornire a aplicației este folosirea unui wrapper GUI, disponibil pe site-ul Appium, care nu necesită instalarea node.js și a modulului aferent, în plus oferind și un Inspector grafic util în procesul de dezvoltare pentru identificarea componentelor din aplicație.

Deoarece Appium este un layer suplimentar peste platformele de automation native, există anumite condiții pentru executarea www.todaysoftmag.ro | nr. 33/martie, 2015

49

testare Appium - testare automată cross-platform pentru dispozitive mobile

@BeforeMethod

testelor. În principal vorbim de faptul ca testele de IOS pot fi exe- public void setUp(){ File app = new File(“appFolder”, “myApp.apk”); cutate doar pe platforma MAC OSX, din cauza dependenței de DesiredCapabilities capabilities = XCode (desigur, se pot executa remote de pe o mașină Windows). new DesiredCapabilities(); Pe de altă parte testele de Android pot fi executate de pe mașini capabilities.setCapability(“platformName”, folosind Windows, OSX sau Linux, condiția principală fiind MobilePlatform.ANDROID); capabilities.setCapability(“deviceName”, instalarea și configurarea Android SDK pe mașina respectivă.

Codul face cât 1000 de imagini, iar fiecare imagine face cât 1000 de cuvinte Abordarea din punct de vedere a codului este în mare similară cu codul scris într-o platformă bazată pe Selenium WebDriver. În cele ce urmează, vom prezenta o organizare a codului care are în vedere în principal simplificarea mentenanței testelor, utilizând din plin pattern-ul PageFactory alături de versiunea Appium a assertion-urilor specifice Selenium. Ca test framework vom folosi TestNG care este mai util în testarea automată decât jUnit, dar Appium este total în această privință.

Ne vom imagina partea de login a unei aplicații cu look identic pe Android și IOS, care are un splash screen la pornire. Ecranul de login este simplu, conține două câmpuri text pentru utilizator și parolă și un buton SignIn. Există și un element label care va afișa un mesaj de eroare dacă datele utilizatorului sunt incorecte.

Cel mai simplu mod de a crea un proiect Appium este folosirea Maven, fișierul aferent de configurare pom.xml va trebui să conțină dependințele de Selenium și următoarea secțiune (în funcție de versiunea curentă de client Java Appium): <dependency> <groupId>io.appium</groupId> <artifactId>java-client</artifactId> <version>2.1.0</version> </dependency>

Totul începe cu pregătirea testelor, o practică adesea folositoare este crearea unei clase părinte gen BaseTest care va fi moștenită de clasele de test. Aici este locul unde putem face configurarea inițială pentru suita de teste într-o metodă care are annotation-ul @BeforeSuite, pentru fiecare test generic în metoda marcată cu @BeforeTest și, desigur, partea de tearDown.

Cea mai simplă variantă ar cere instanțierea unui obiect de tipul AppiumDriver (sau AndroidDriver/IOSDriver în versiunile mai noi) în metoda de setup a testelor, a atașa acestui obiect un obiect DesiredCapabilities care practic furnizează informații despre dispozitivul folosit. Acest obiect va fi folosit pe parcursul testului pentru a trimite comenzi spre dispozitivul mobil și pentru a extrage informații. Odată testul finalizat, obiectul va fi închis explicit în metoda de teardown. Mai jos, vă oferim un exemplu pentru o tabletă Nexus 10:

50

nr. 33/martie, 2015 | www.todaysoftmag.ro

}

“Nexus 10”); capabilities.setCapability(“platformVersion”, “5.0.1”); capabilities.setCapability(“app”, app.getAbsolutePath()); capabilities.setCapability(“appPackage”, “org.myapp.demo”;); capabilities.setCapability(“appActivity”, “org.myapp.SplashActivity”); capabilities.setCapability(“noReset”, false); AndroidDriver driver = new AndroidDriver( new URL(“http://127.0.0.1:4723/wd/hub”), capabilities);

Părțile esențiale în această configurare sunt: app – locația aplicației care va fi încărcată automat în tabletă, appPackage – specifică tipul de pachet ce va fi executat (specific Android), appActivity – specifică felul de activity trebuie să aștepte testul, noReset/fullReset – specifică dacă aplicația va fi reinițializată, respectiv reinstalată. Partea de tearDown va închide aplicația și obiectul driver: @AfterMethod public void tearDown() throws Exception { driver.closeApp(); driver.quit(); }

Pentru a simplifica înțelegerea exemplelor, în continuare listăm ierarhia porțiunii din ecran, pentru ambele platforme:

Android

<android.widget.RelativeLayout resource-id=”org.myapp.demo:id/signin_layout” class=”android.widget.RelativeLayout” package=”org.myapp.demo”> <android.widget.EditText text=”JohnDoe” resource-id=”org.myapp.demo:id/signin_email_text” class=”android.widget.EditText” package=”org.myapp.demo”/> <android.widget.EditText resource-id=”org.myapp.demo:id/signin_password_text” password=”true” class=”android.widget.EditText” package=”org.myapp.demo” /> <android.widget.TextView resource-id=”org.myapp.demo:id/signin_result” class=”android.widget.TextView” package=”org.myapp.demo”/> <android.widget.Button text=”Sign In” resource-id=”org.myapp.demo:id/signin_ok_button” class=”android.widget.Button” package=”org.myapp.demo” contentdesc=”SignInButton”/> </android.widget.RelativeLayout>

TODAY SOFTWARE MAGAZINE IOS

<UIATableView name=”authentication” enabled=”true” visible=”true”> <UIATableCell name=”” label=”” visible=”true”> <UIATextField name=”user” label=”JohnDoe” value=”username” visible=”true”> </UIATextField> </UIATableCell> <UIATableCell name=”” label=”” visible=”true”> <UIATextField name=”password” label=”” value=”password” visible=”true”> </UIATextField> </UIATableCell> <UIATableCell name=”” label=”” visible=”true”> <UIAButton name=”SignIn” label=”SignIn” value=”SignIn” enabled=”false” visible=”true”> </UIAButton> </UIATableCell> <UIATableCell name=”” label=”” visible=”false”> <UIAStaticText name=”labelSignIn” label=”” value=”” visible=”false”> </UIAStaticText> </UIATableView>

Testul prezentat va fi simplu, dar suficient pentru a prezenta conceptul și designul testelor. Pașii: 1. Utilizatorul pornește aplicația și verifică apariția ecranului de SignIn, existența unui text demonstrativ în câmpul username („JohnDoe”) și faptul că butonul de SignIn este dezactivat.

2. Utilizatorul face o acțiune touch în câmpul username și verifică dispariția textului demonstrativ inițial.

3. Utilizatorul introduce un username corect și o parolă incorectă, se validează că butonul SignIn este activat.

4. Utilizatorul face o acțiune touch pe butonul SignIn, se validează apariția unui mesaj de eroare în și că butonul este în continuare vizibil.

public class LoginScreen { final String PKG = “org.myapp.demo”; private AppiumDriver driver;

//elementele sunt identificate pentru ambele //platforme, simplificând mult testele în cazul în //care interfața este identică @iOSFindBy(name = “user”) @AndroidFindBy(id = PKG + “/signin_email_text”) private MobileElement userTxt; @iOSFindBy(name = “password”) @AndroidFindBy(id = PKG + “/signin_password_text”) private MobileElement passwdTxt; //utilizăm un criteriu de identificare xpath, //în cazul de față cu scop didactic @iOSFindBy(xpath = “//UIAStaticText [@name=’labelSignIn’]”) @AndroidFindBy(xpath = “//android.widget.TextView [@id=’” + PKG + “/signin_result’]”) private MobileElement labelTxt; @iOSFindBy(className = “UIAButton”) @AndroidFindBy(uiAutomator = “text(\”Sign In\”)”) private MobileElement signinBtn;

public LoginScreen(final AppiumDriver driver) { this.driver = driver; //criteriile de identificare annotated //mai sus sunt inițializate PageFactory.initElements(new AppiumFieldDecorator(driver), this); //testul va aștepta MAXIM 10 secunde pentru //vizibilitatea câmpului user și password final WebDriverWait wait = new WebDriverWait(driver, 10); wait.until(ExpectedConditions.visibilityOf(userTxt)); wait.until(ExpectedConditions. visibilityOf(passwdTxt)); } public void touchUserNameBox() { userTxt.click(); } public void typeUserName(String username) { userTxt.sendKeys(username); } public String getVisibleUsername() { return userTxt.getText(); } public void typePassword(String pwd) { passwdTxt.sendKeys(pwd); } public boolean isSignInBtnEnabled() { return signinBtn.isEnabled(); } public boolean hasErrorMessage() { return labelTxt.isDisplayed(); } public boolean isSignInBtnVisible() { return signinBtn.isDisplayed(); } public void touchSignInBtn() { signinBtn.click(); } public String getErrorMessage(){ return labelTxt.getText(); } }

Abordarea simplă și de obicei ineficientă este de a scrie un test care să reproducă acești pași prin identificarea obiectelor cu care interacționează testul, efectuarea acțiunilor și validarea. Problema majoră în această abordare, de altfel în general la testele automate de acest gen indiferent de produsul folosit, este faptul că mentenanța testelor devine dificilă când numărul lor crește. Dacă vom avea douăzeci de teste care fac acțiuni pe aceleași elemente, în momentul în care unul din elemente se modifică, acesta va trebui modificat în toate testele. Chiar dacă extragem din teste criteriile utilizate pentru identificarea elementelor și le facem membri ai clasei de test, mentenanța este în continuare relativ dificilă și mai mult, testele vor trebui duplicate pentru ambele platforme.

O abordare mai elegantă și eficientă în cazul suitelor mari de teste este de a separa testele propriu zise de obiectele care modelează în cod ecranele aplicației. Practic fiecare ecran va avea o clasă corespondentă Java, existând și posibilitatea de a modela separat porțiuni ale ecranului, în cazurile ecranelor mai complexe.

Criteriile de identificare ale elementelor vor fi membri privați ai Testul corespunzător va folosi metodele publice din clasa de clasei, astfel respectând filosofia OOP, acțiunile sau caracteristi- mai sus și, desigur, assertions pentru validare: cile elementelor vor fi expuse ca metode publice, ușor de utilizat @Test în testul propriu-zis. Acest pattern este similar cu PageFactory public void testLogin(){ LoginScreen screen = new LoginScreen(driver); utilizat în testele Selenium WebDriver. assertEquals(screen.getVisibleUsername(), Clasa care va modela ecranul (de fapt porțiunea de ecran “JohnDoe”); care conține elementele de autentificare) este prezentată mai jos, assertFalse(isSignInBtnEnabled()); screen.touchUserNameBox(); explicațiile fiind prezentate sub forma comentariilor Java, por- assertEquals(screen.getVisibleUsername(), “”); screen.typeUserName(“TotallyValid”); nind de la premisa unui cod self-describing. screen.typePassword(“badpassword”); assertTrue(screen.isSignInBtnEnabled()); screen.touchSignInBtn();

www.todaysoftmag.ro | nr. 33/martie, 2015

51

testare Appium - testare automată cross-platform pentru dispozitive mobile assertTrue(screen.hasErrorMessage()); assertEquals(screen.getErrorMessage(), “Invalid credentials”); assertTrue(screen.isSignInBtnVisible()); }

Această organizare a testelor ajută mult la mentenanță, adesea modificările din UI necesitând doar modificare a criteriilor de identificare a elementelor în clasele care modelează ecranele aplicației, testele funcționând corect fără modificare, presupunând desigur că nu există schimbări în flow-ul aplicației). Un alt plus important este faptul că testul devine ușor de citit și că se observă ușor pașii și validările. Desigur, devine simplu de implementat BDD pentru a simplifica mai mult testele -acolo unde se poate aplica- folosind unul din tool-ulurile existente pe piață sau implementând o variantă proprie. Criteriile de identificare a elementelor pot fi xpath, id, name, className și UIAutomator.

Acest ultim criteriu folosește din plin API-urile IOS (predicates) și Android pentru a identifica elementele când celelalte variante nu sunt optime. Uneori acest tip de identificare necesită un studiu prealabil al specificațiilor implementării (în special IOS predicates), oferind flexibilitate foarte mare și complexitate pe măsură.

Concluzii

Appium a devenit în scurt timp la fel de popular în testarea aplicațiilor mobile ca Selenium WebDriver pentru aplicațiile web.

Lista de avantaje este mare: open-source, aplicația testată este cea

52

nr. 33/martie, 2015 | www.todaysoftmag.ro

finală nefiind necesare nici un fel de intervenție asupra codului pentru a face aplicația testabilă, număr mare de limbaje suportate, compatibilitate ridicată cu dispozitivele și versiunile de sisteme de operare, testele se scriu o singură dată pentru ambele platforme (când interfața este similară), suport pentru aplicații native/hybrid/web, comunitate mare. Există desigur și dezavantaje: testele de IOS pot fi executate doar pe mașini MAC și nu se pot executa mai mult de un test simultan. Acest ultim dezavantaj poate fi înlăturat prin utilizarea unui serviciu cloud ca Sauce Lab.

Vasile Pop

vasile.pop@intel.com Software Engineer @ Intel România

diverse

TODAY SOFTWARE MAGAZINE

Analiza pentru tehnologiile viitoare

A

m început să scriu la acest articol cu gândul la cum va arăta tehnologia în viitor, la modul în care putem să anticipăm și să ne pregătim pentru schimbările care vor avea loc în anii ce urmează. Oamenii de știință caută astăzi să descopere care va fi viitorul științei, tehnologiei, economiei și societății pentru a putea identifica arii de cercetare strategică care pot genera beneficii în economie și în societate.

Analiza orientată spre tehnologiile viitoare (FTA- Future oriented Technology Analysis) se definește ca un set de activități care facilitează luarea unor decizii și declanșarea unor acțiuni coordonate în special in domeniul științei, tehnologiei și inovației (Eerola and Miles, 2011). ‚Cine este interesat de o astfel de analiză?’ s-ar putea întreba unii. La momentul actual, analiza orientată spre tehnologiile viitoare este un subiect important pe agenda U.E sau a companiilor multinaționale.

Industriile mari unde analiza orientată către viitor este des întâlnită sunt: energie și mediu, tehnologia informației, comerțul online, producție și roboți, medicină și biogenetică, transport, spațiu.

În cele ce urmează, voi detalia ce înseamnă analiza orientată spre viitor și ce implică ea. Câteva dintre principiile de bază ale FTA sunt: • Orientarea către viitor • Participarea • Dovezi concrete • Multidisciplinaritate • Coordonare de resurse și oameni • Orientare spre acțiune Disciplinele care fac parte din domeniul analizei orientate spre viitor conform lui Alan L. Porter sunt: previziunea (foresight), prognoza (forcasting), evaluarea tehnologiilor, inteligența tehnică (technical intelligence) și roadmapping. Acestea contribuie la

înțelegerea mai bună a provocărilor viitoare și modelarea unor soluții sustenabile pentru viitor.

Voi trece defini succint patru dintre discipline și voi detalia mai mult partea de previziune.

Prognoza (Forecasting) – disciplina care calculează și anticipează direcția unui eveniment precum și ritmul schimbării.

Acesta este rezultat al unui studiu rațional și a unei analize pe date pertinente.

Un exemplu în acest sens ar fi decizia unui stat să susțină un program spațial.

Acesta va avea un impact major în industria electronică, folosirea de materiale noi mai avansate etc. În același timp această decizie poate afecta negativ domeniul transporturilor terestre care pot rămâne subfinanțate.

Evaluarea tehnologiilor (Technology Assessment) – încercarea sistematică de a prevedea consecințele introducerii unei tehnologii noi.

La momentul actual a devenit dificil să separăm activitățile zilnice ale oamenilor de tehnologie. Prin urmare, am putea defini tehnologia ca fiind modalitatea și mijlocul prin care oamenii produc bunuri materiale. În momentul în care se produce o schimbare de tehnologie întregul sistem din care fac parte și oamenii se poate schimba.

Inteligența tehnică – Se mai poate numi și inteligența competitivă. Folosirea inteligenței în raport cu posibilitățile tehnice ale competiției.

Roadmapping – folosește avansul tehnologic anticipat pentru a genera planuri de

www.todaysoftmag.ro | nr. 33/martie, 2015

53

diverse Analiza pentru tehnologiile viitoare acțiune.

Se folosește cel mai adesea în planificarea produselor de către companii.

Previziunea (Foresight)– abilitatea de a prezice ce se va întâmpla sau de ce va fi nevoie în viitor. Este disciplina care trebuie aplicată exclusiv de experți pentru a putea avea încredere în rezultatele analizei.

Experții analizează orice informație pentru a identifica potențiale previziuni. La acest nivel se va stabili o strategie care implică de multe ori un mecanism participativ. Abordările tradiționale nu mai sunt la fel de relevante. Planul este cel mai puțin important element care se adaugă rezultatelor la final.

Este important de menționat că nu se discută despre un viitor predeterminat ci despre explorarea modului în care poate evolua viitorul în funcție de acțiunile și deciziile care se iau în prezent.

Avem mai jos prezentat contextul în care are loc previziunea.

Se folosesc de aceste discipline deopotrivă oameni de la nivel guvernamental, centre de cercetare, organizații non-profit precum și compani private care doresc să se mențină pe piață sau să își crească profitabilitatea.

Este foarte valoros pentru societate că aceste discipline facilitează luarea de decizii și coordonarea acțiunilor în special în domeniul științei, tehnologiei și inovarea în elaborarea de politici sustenabile pe viitor de care, de ce să nu recunoaștem, beneficiem cu toții.

Biografie 1.

2.

3.

4.

5.

1.http://w w w.nest a.org .u k/public at ions/ quantitative-analysis-technology-futures-part-1 2. https://ec.europa.eu/jrc/en/event/site/fta2014 3. http://thinkingfutures.net/wp-content/uploads/2010/10/ An-Overview-of-Foresight-Methodologies1.pdf 4.http://www.techmonitor.net/tm/images/3/37/03jul_aug_sf2.pdf 5. http://web.mit.edu/smadnick/www/wp/2008-15.pdf

În continuare, este prezentat generic procesul previziunii. La intrări sunt lucrurile care se întâmplă în prezent. Înăuntrul procesului de previziune are loc analiza detaliată.

Pentru fiecare din disciplinele FTA definite mai sus se folosesc un set de metode combinate de tip explorativ, consultativ, explicativ și participativ.

Cum spațiul articolului e limitat, pentru cei mai curioși dintre voi care doresc o imagine mai bună a metodelor de analiză folosite pentru previziune puteți căuta pe internet schema numită Futures Diamond a lui Popper.

Ca și concluzie la un subiect așa de complex cum este Analiza orientată spre tehnologiile viitoare, putem spune că acesta este un termen generic folosit pentru a putea cuprinde un set mai mare de discipline (previziune, prognoză, evaluarea tehnologiilor, inteligență tehnică și roadmapping).

54

nr. 33/martie, 2015 | www.todaysoftmag.ro

Ioana Armean

ioanaa@imprezzio.com Business Analyst @ Imprezzio Global

sponsori

powered by