TO DAY SOFTWARE Nr. 33 • Martie 2015 • www.todaysoftmag.ro • www.todaysoftmag.com MAGAZINE 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 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 Java Chronicle în acțiune Realitatea virtuala îmbunătățită pe dispozitivele mobile
Transcript
TSM T O D A YS O F T WA R E
Nr. 33 • Martie 2015 • www.todaysoftmag.ro • www.todaysoftmag.com
M AG A Z I N E
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
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
Java Chronicle în acțiune
Realitatea virtuala îmbunătățită pe dispozitivele mobile
6Interviu cu Jonathan Shieber,
senior editor la TechCrunch și CrunchBase
Ovidiu Măţan
7Lansarea Different Angle -
primul Cluster de IT & C din București
Ovidiu Măţan
8De ce să vii la
Startup Weekend Cluj 2015?Cristina Juc
10MVP Academy prezintă cele 13
startup-uri admise în programul de pre-accelerare
Irina Scarlat
12Alt-tester la Mobile
World Congress 2015Simina Rendler
15Realitatea virtuală îmbunătățită
pe dispozitivele mobileAlexandru Fediuc și Virgil Andreies
19Introducerea și tuning-ul
Hadoop MapReduceTudor Lăpușan
22Sisteme de mesagerie
performante – Apache KafkaTiberiu Nagy
25Date de tip spațial în SQL Server
Diana Muntea
2
28UsableSoftwareDesignAlexandru Bolboacă
31Quality Assurance în AgileVasile Selegean
35Dezvoltarea aplicațiilor securizate în JavaSilviu Dumitrescu și Diana Bălan
38Abordare simplă a riscului în ScrumSebastian Botiș
42Importanța realizării de prototipuriCătălin Timofti
44Java Chronicle în acțiuneVasile Mihali
46Apache Cassandra, Primii PașiSergiu Indrie
49Appium - testare automată cross-platform pentru dispozitive mobileVasile Pop
46Analiza pentru tehnologiile viitoareIoana Armean
4 nr. 33/2015 | www.todaysoftmag.ro
Î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 dez-voltarea 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 inter-viu 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 asu-pra 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 crea-rea 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.
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 bine să așteptăm și să vedem.
Drept redactor șef la TechCrunch, ți se trimit noutăți, iar interesul pentru aceasta este foarte mare. Ce sfat ai da unei persoane care are un startup și dorește să publice un articol în TechCrunch? Vreun eveniment important la care ar trebui să participe?
[Jon] Am atins acest subiect în cadrul discuțiilor la masa rotundă. Fiți conciși, descrieți punctul dureros pe care îl rezolvă tehnologia companiei, menționați nou-tatea într-o propoziție, vorbiți despre dimensiunea potențială a oportunității de piață și cercetați cine este reporterul 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 ace-lor persoane. Începeți procesul din timp.
Dacă există reporteri pe care îi respectați, lăsați-le câteva rânduri și arătați-le asta. Dacă oamenii observă cum ne facem datoria, atunci este mai probabil ca și noi să observăm ceea ce fac ei.
Este TechCrunch implicat activ într-un accelerator startup prin CrunchBase?
[Jon] TechCrunch nu este afiliat la niciun accelerator sau incubator. Există un fond inițiat de către fondatorul TechCrunch, Michael Arrington, numit CrunchFund, dar nu sunt sigur care este relația dintre acel fond de investiții și TechCrunch (dintr-o perspectivă instituțională).
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 antrepre-nori pasionați care caută să înfăptuiască idei interesante, dar ecosistemul este des-tul 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.
Am 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 inter-viu cu Jon despre tendințele actuale.
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 com-panii: 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.
26 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 con-ceptului de Smart Cities.
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 provo-cat să ne răspundă la câteva întrebări. Iată câteva dintre răspunsurile lor:
Cum te-ai gândit la idee/concept?”Ideea s-a născut în februarie 2014,
într-o după amiază cu soare, pe o bancă din fața Cluj Cowork, unde lucram în acea perioadă împreună cu Mircea, co-fondator ZenQ . El mi-a povestit atunci despre ideea lui de a crea o aplicatie unde fiecare are un profil de personalitate, creat de către prie-tenii săi, pe care îl poate folosi pentru a-și descoperi punctele forte, pentru a căuta un job sau pentru a câștiga încrederea oame-nilor care nu te cunosc personal. În acel moment mi-am amintit de o idee de-a mea
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ân-disem 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.”
Zornitsa Tomova (ZenQ) - Winner at SWCluj 2014
În ce stadiu vă aflați în acest moment?”După SWCluj am avut nevoie să ne
dăm seama cum ar funcționa Employee Engagement în viața reală, și dacă această unealtă pe care am gândit-o în cadrul eve-nimentului ar putea avea un impact real, dar și modul în care ar influența implicarea. Se pare că răspunsul e Da, însă noi aveam nevoie de o cercetare cară să confirme acest lucru. La momentul actual lucrăm asupra
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.”
Anton i a O n a c a ( E ng a g em ent 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
antreprenoriat
De ce să vii la Startup Weekend Cluj 2015?
Startup 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.
Young spiritMature organizationA shared vision
Join our journey!
www.fortech.ro
9www.todaysoftmag.ro | nr. 33/martie, 2015
TODAY SOFTWARE MAGAZINE
În prezent lucrezi împreună cu oamenii pe care i-ai cunoscut la SWCluj?
”Dacă e să vorbim despre echipa actu-ală, răspunsul este nu. Însă dacă e să considerăm mentorii renumiți și inspira-tori pe care am avut ocazia să-i cunoaștem atunci, răspunsul este da.”
Mara Steiu (Teentrepreneur) - Winner at SWCluj 2014
Dacă ar fi să vii la ediția de anul acesta, ce-ai face diferit față de anul trecut? Ce sfat ai putea oferi participanților de anul acesta?
”Nu aș face nimic diferit. Mă consider norocoasă pentru felul în care au decurs lucrurile. Singurul sfat pe care l-aș oferi este acesta: du-te la Startup Weekend nu doar pentru ca să te distrezi. Mergi acolo cu
gândul că ești deja câștigător. În felul acesta vei putea avea parte și de distracție.”
Zornitsa Tomova (ZenQ) - Winner at SW 2014
Care este cea mai memorabilă experiență pe care ai trăit-o la SWCluj?
”Șocul de-a cunoaște și de a interacționa cu toți acei oameni minunați, într-o peri-oadă de timp foarte scurtă, în timp ce aveam de lucru la proiect!”
Mara Steiu (Teentrepreneur) - Winner at SWCluj 2014
Pentru a citi interviurile complete, poți intra pe blogul Startup Weekend Cluj: cluj.startupweekend.org/blog/
Este de menționat faptul că până la
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?
www.3pillarglobal.com
3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world.
Our core competencies include:
ProductStrategy
ProductDevelopment
ProductSupport
Our offerings are business focused, they drive real, tangible value.
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 eva-luat 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 pro-gramului 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ă
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ă
MVP Academy prezintă cele 13 startup-uri admise în
programul de pre-accelerare
Bucureș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.
antreprenoriat
11www.todaysoftmag.ro | nr. 33/martie, 2015
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 ast-fel 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;
MVP Academy este un program organizat în parteneriat cu Telekom România & Bitdefender, cu sprijinul CyberGhost, Raiffeisen Bank, hub:raum și Microsoft. În perioada 23 martie – 14 mai, cele 13 echipe finaliste vor trece printr-un proces de preaccelerare complex, adaptat pentru a corespunde nevoilor lor specifice, vor lucra la dezvoltarea produsului și vor învăța cum să acceseze oportunitățile existente pe piața globală. Toate aces-tea participând la workshop-uri practice, sesiuni de mentorat și coaching 1 la 1, pitching practice și alte activități dedicate.
Pe parcursul celor șapte săptămâni ale programului, startup-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 (Senior Editor, TechCrunch Europe), Alex Barrera (Co-Fondator, Tech.eu & Press42), Ivan Brezak Brkan (Editor, Netokracija), Olaf Lausen (Chief of CEO Staff & Business Development 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
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 programu-lui 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, Gadget Trends, Games Arena, Gadget Talk, Softlead, Today Software Magazine, startups.ro și IQAds.
MVP Academy se bucură de susținerea comunităților partenere Romanian Startups, Romanian Game Developers Association (RGDA), Softbinator, ANIS, Cluj Hub, Cluj Co-Work, Professional Gamers League, Tabăra de testare, comunitatea fron-tend din România, Akcees, Startup Weekend România, Startup Weekend Târgu Mureș, Startup Weekend Cluj, Girls in Tech România și Girls Who Code.
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ă des-copă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, con-statam 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 recoman-dă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 orga-nizatorilor 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
tehnologii, servicii și echipamente mobile. Samsung a organizat aici primul lor eveni-ment 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 pen-tru 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 premi-eră astfel de device-uri la scurt timp după ce au fost lansate și să poți să discuți des-pre 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.
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âr-gurilor ar trebui să se insiste pe importanța încălțămintei cât mai comode. Ce presu-pune 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ându-se î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, echi-pamente sportive pe care să faci mișcare în timp ce testezi un wearable; o dansatoare de Flamenco, un barista alături de repre-zentantul de vânzări pregătit să prezinte oferta sau să povestească cu tine, palmi-eri 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.
Mobile 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 speci-alizată în servicii de testare și, mai ales, de ce duce de mânuță un roboțel?
Alt-tester la Mobile World Congress 2015
13www.todaysoftmag.ro | nr. 33/martie, 2015
TODAY SOFTWARE MAGAZINE
Dincolo de simpla nagivare din stand în stand, oportunitățile de a găsi noi par-teneri 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 pro-prii printre ceilalți expozanți. Astfel, mulți participanți merg la MWC cu o agendă de întâlniri planificată din timp.
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 vizi-tatorii 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
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, pen-tru 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.
Dincolo de complexitatea onomastică, Altap este un roboțel integrat într-o soluție de executare a testelor automate pe tele-foane 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 rea-lizează 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 rea-liza 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 stan-dul 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 proiec-tul de licență, soluția colegei noastre Ru pentru problema de recunoaștere a
imaginilor și efortul colectiv al Altomilor pentru designul testelor automate, asam-blarea ș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 ajuto-rul lui Alexandru Popescu, doctorand la Universitatea Tehnică Cluj Napoca.
Alt-tester la MWCFă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 parti-ciparea 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, pro-bleme î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 vii-tor. 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 pro-iectelor 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.
Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: www.transylvania-jug.orgData înfiinţării: 15.05.2008 / Nr. Membri: 599 / Nr. Evenimente: 47
Comunitatea TSMComunitate construită în jurul revistei Today Software Magazine.Websites: www.facebook.com/todaysoftmag www.meetup.com/todaysoftmag www.youtube.com/todaysoftmagData înfiinţării: 06.02.2012 /Nr. Membri: 2215/Nr. Evenimente: 30
Cluj Business AnalystsComunitate dedicată analizei de businessWebsite: www.meetup.com/Business-Analysts-ClujData înfiinţării: 10.07.2013 / Nr. Membri: 91 / Nr. Evenimente: 8
Cluj Mobile DevelopersComunitate dedicată tehnologiilor mobileWebsite: www.meetup.com/Cluj-Mobile-DevelopersData înfiinţării: 05.08.2011 / Nr. Membri: 264 / Nr. Evenimente: 17
The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 437 / Nr. Evenimente: 93
Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: www.meetup.com/Cluj-Semantic-WEBData înfiinţării: 08.05.2010 / Nr. Membri: 192/ Nr. Evenimente: 29
Romanian Association for Better SoftwareComunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.Website: www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 251/ Nr. Evenimente: 14
Tabăra de testareComunitate 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.roData înfiinţării: 15.01.2012/Nr. Membri: 1243/ Nr. Evenimente: 107
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.
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 Draghiam 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 restim e e t u p . c o m / B i g - D a t a - D a t a - S c i e n c e - Me e t u p -Cluj-Napoca/events/220876181/
Martie 31(București)Mobile Advertising Congress conference-arena.com/mobile-advertising-congress
Aprilie 1 (București)April BucharestJS Meetupmeetup.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 TSMcluj.startupweekend.org/
Comunităţi IT
comunități
15www.todaysoftmag.ro | nr. 33/martie, 2015
programare
AR este un mod de a augmenta elemen-tele 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 puter-nic 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 arti-ficii 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 utiliza-tor, 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 aseme-nea, î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 trackingPentru ca aplicația să știe unde anume
ești și la ce anume te uiți (locația și orien-tarea 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 folo-sesc de pătrate alb-negru pentru a realiza o diferențiere evidentă între markers și non-markers. 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
Realitatea 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 dispo-zitivele 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 SDK-uri puternice puse la discreția oricui.
programareRealitatea 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).
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 eve-nimentelor 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 con-chis spus, segmentarea mișcării. Urmează crearea unor modele geometrice 3D care să se suprapună pe cât mai multe categorii de mașini și crearea unui model de mișcare al mașinii în contrast cu șoseaua statică. Astfel se poate crea o scenă în care mașinile sunt scoase din context și devin obiectul de interes.
FrameworksExistă 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 sen-zori 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.
VuforiaPlatforma 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 cubo-ide 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 ase-menea, 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 scena-riu. 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ăr-cată gratuit. D’Fusion este orientat mai mult pe partea de retail,
oferind multe instrumente în această direcție.
MetaioO 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: mar-keri, modele 3D, image target etc.. Importanți agenți economici au apelat la această platformă în dezvoltarea unor aplicații de suc-ces: 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 progra-matori la distanță.
Crearea unei aplicații de “Augmented Reality” uti-lizând motorul Unity3D și extensia Vuforia pentru Unity
Unity 3D
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 generaleMotorul 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 ase-menea, 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.
AssetsAssets reprezintă fiecare resursă pe care aplicația o utili-
zează. 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 posi-bilitatea de a crea aceste “assets”. În schimb, acestea trebuie create extern utilizând aplicații de modelare 3D și unelte grafice de pic-tat, 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”.
17www.todaysoftmag.ro | nr. 33/martie, 2015
TODAY SOFTWARE MAGAZINE
SceneleScenele reprezintă locațiile unde obiectele din “assets” vor fi
amplasate și aranjate pentru a crea ecrane de joc. Panoul cu ierar-hia reprezintă conținutul scenei curente într-un format de arbore.
ScriptingScript-urile sunt cunoscute ca “behaviours”. Ele asigură mani-
pularea și crearea de interactivitate între resurse. Acestea pot fi reutilizate pentru mai multe obiecte, atașarea lor pe resursă rea-lizâ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.
Acum, după ce am creat script-ul, el trebuie asignat “asset-ului”. Aceasta se face cu “drag-and -drop” pe obiectul de joc. Cu script-ul asignat, se poate rula jocul.
PublicareaUnity poate publica în Windows, OS X, și prin interme-
diul 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 tehnolo-
gii 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 vir-tual 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” folo-sind “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 plat-forme, 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 ima-gine. 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
18 nr. 33/martie, 2015 | www.todaysoftmag.ro
programareRealitatea 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 - tutorialVom 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 compati-bile 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 develo-per. 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 cre-ată 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 suges-tie 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 pen-tru a rula pe un dispozitiv mobil.
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 aces-teia î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 obiec-tul/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 algo-ritmii 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 vir-tuale î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 rea-litate îmbunătățită în propriu buzunar.
19www.todaysoftmag.ro | nr. 33/martie, 2015
MapReduce este principala tehnologie de procesare de date de volum mare a pro-iectului Apache Hadoop. A fost dezvoltată de către Google. În 2004, ei au publicat un articol care descria conceptul MapReduce.
În 2006, Dug Cutting a reușit să imple-menteze acest concept și să îl includă într-un proiect Apache, mai exact în Apache Hadoop1. 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 tutu-ror, alte tehnologii au fost dezvoltate peste MapReduce, care sunt mult mai ușor de învățat și de utilizat. Un exemplu este Apache Hive3, care a fost dezvoltat la Facebook. Deoarece aproape toți cei din domeniul com-puter science au cunoștințe SQL, Facebook a dezvoltat Hive, care le-a permis să-și intero-gheze și să-și analizeze seturile de date prin simpla utilizare a limbajului HiveQL, care este foarte asemănător cu SQL. Astfel, ori-cine din echipa Facebook, care are cunoștințe SQL, avea capacitatea de a utiliza puterea teh-nologiei MapReduce.
O imagine de ansamblu a MapReduce.MapReduce este o tehnologie distribu-
ită, care funcționează pe produse hardware obișnuite și se folosește pentru prelucrarea
1 http://hadoop.apache.org/
2 http://wiki.apache.org/hadoop/poweredby
3 https://hive.apache.org/
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.
Pentru a înțelege mai bine cum funcționează MapReduce, vă recomand să citiți mai multe despre MapReduce He l l o Wor l d , m a i pre c i s e x e mp lu l Wordcount4. 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 pse-udocodului exemplului Wordcount.
mapper (filename, file-contents): for each word in file-contents: emit (word,1)
reducer (word, values): sum=0 for each value in values: sum=sum + value emit (word, sum)
Introducerea și tuning-ul Hadoop MapReduceprogramare
Î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.
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, dimensi-unea 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
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 recoman-dat, 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 eco-nomisi 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âm-plă în partea de reduce.
Partea de reduce.După ce execuția map-ului este încheiată, este informat coor-
donatorul 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 memo-ria 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 rezul-tate 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 eco-nomisi 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ă.
21www.todaysoftmag.ro | nr. 33/martie, 2015
TODAY SOFTWARE MAGAZINE
Ieșirea acestei faze este scrisă direct pe sistemul de fișiere, de obi-cei 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 valo-rilor î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ărsa-rea optimă. Pentru aceasta, ar trebui să detectăm dimensiunea rezultatelor funcției de map și să modificăm proprietățile cores-punză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.
ConcluzieDacă 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 (tuning-ul). 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.
Odată cu răspândirea arhitecturilor bazate pe evenimente, sistemele de mesa-gerie au devenit componentele de bază ale arhitecturilor enterprise. Deoarece aplicațiile enterprise prelucrează din ce în ce mai multe date, performanța sis-
temelor 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 momen-tul 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 servi-cii, î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 dez-voltat 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ățiPrincipalul obiectiv în proiectarea
Kafka a fost maximizarea vitezei de trans-fer 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 din-tre facilitățile oferite de platformele clasice de mesagerie.
Una dintre cele mai importante
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 pro-cesarea 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 mp l i f i c ă mu l t a r h i t e c tu r a sistemului,
• Kafka nu trebuie să rețină care din-tre mesaje au fost consumate și care nu. Izolează producătorii de consumatori. În sistemele în care consumatorii sunt obligați să confirme procesarea mesa-jelor, 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ă abor-dare poate duce la situații periculoase în care un consumator lent, dar neim-portant 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
periodic. Desigur, abordarea aceasta funcționează numai dacă mesajele sunt reținute în Kafka suficient de mult încât procesele respective să apuce să prelu-creze 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 exis-tente 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 magne-tice – scrierea pe harddisk se poate face secvențial, evitând astfel deplasarea capu-lui de scriere, o operație costisitoare din punct de vedere al performanței. De ase-menea, 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 sis-temele tradiționale o reprezintă modul în care pot fi consumate mesajele. Sistemele tradiționale oferă două moduri de con-sum: coadă (queue) și publicare-abonare (publish-subscribe). În modelul coadă, fiecare mesaj ajunge la un singur con-sumator. În modelul publicare-abonare, fiecare mesaj ajunge la fiecare consuma-tor. Kafka vine cu o singură abstractizare care acoperă ambele modele: grupuri de consumatori. În Kafka, fiecare consuma-tor 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 indi-viduali se abonează la o topică. Dacă toți consumatorii fac parte din același grup, fiecare masaj va ajunge la un singur con-sumator din grup, topica funcționând ca o coadă de mesaje. Dacă în schimb fie-care consumator face parte din alt grup, fiecare consumator va primi mesajele publicate—modelul publish-subscribe cla-sic. În practică însă, vom avea de a face cu un număr mic de grupuri de consuma-tori, 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 for-
mat din mai multe mașini care au rolul de broker, ele reținând mesajele publi-cate. 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 publi-cate 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 tre-buie 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 aproxi-mativ egal de partiții.
Când un producător vrea să publice un mesaj în Kafka, producătorul inte-roghează 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 bro-kerului 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 reve-nind 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
24 nr. 33/martie, 2015 | www.todaysoftmag.ro
fi procesat de un singur consumatori din grup. Indexul ultimului mesaj procesat din fiecare partiție se reține în Zookeeper, ast-fel că, dacă un consumator iese din grup, partițiile lui pot fi realocate altor consu-matori, 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ăz-duite 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 conti-nuă 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
proces de desemnare a liderilor pentru fie-care partiție.
ConcluziiKafka reprezintă o soluție bună pentru
aplicațiile care necesită o viteză marede transfer și o latență mică la livrarea
mesajelor. Arhitectura lui simplă șimodalitatea flexibilă de grupare a con-
sumatorilor î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 tehno-logie, Kafka are și ea limitările ei. Faptul că mesajele nu pot fi reprocesate indivi-dual poate reprezenta o problemă pentru unele tipuri de aplicații. O altă problemă o poate reprezenta lipsa de programe și unelte de administrare. Spre deose-bire de alte platforme gen ActiveMQ sau RabbitMQ, Kafka are un ecosistem slab dezvoltat. Necesitatea rulării unui clus-ter de Zookeeper pe lângă brokerii Kafka poate de asemenea reprezenta un impedi-ment financiar sau administrativ. Sperăm însă că o parte dintre aceste limitări vor dispărea odată cu răspândirea și maturiza-rea tehnologiei.
Sisteme de mesagerie performante – Apache Kafkaprogramare
25www.todaysoftmag.ro | nr. 33/martie, 2015
Datele 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.
Începând din 2008 suita de produse SQL Server de la Microsoft oferă suport pentru datele geospațiale. Acest lucru permite stoca-rea 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 repre-zentate într-un sistem euclidian (plan, 2D),
• Geografice (geography) - date care țin cont de curbura Pământului și sunt repre-zentate într-un sistem elipsoidal (3D sau 4D).
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 repre-zintă o linie dreaptă în timp ce pentru cele geografice este un arc circular.
• Măsurătorile spațiale – în sistemul planar distanța este măsurată folosind
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 punc-telor 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 identi-ficatorul SRID.
• Orientarea datelor spația le – 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 sin-gură emisfera. De asemenea și rezultatul operațiilor dintre două date de tip geogra-fic (intersecție, uniune, diferență) trebuie să fie definit într-o singură emisferă.
SRID - Spatial Reference Indentifiers Este un identificator care corespunde unui
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 geo-grafice
Imagine MSDN
SQL Server ne pune la dispoziție mai multe tipuri de funcții și metode pentru manipularea datelor de tip spațial : pentru impor-tarea 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 apro-piat 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.
Exemple
Date GeometriceCREATE TABLE myTable ( id int IDENTITY (1,1), geometryData geometry, 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
Ce tip de date ar trebui să aleg pentru aplicația mea (geometry vs. geography)?
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.
Aplicații
Radius searchSă presupunem că avem o colecție de puncte definite prin lati-
tudine ș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
programareDate de tip spațial în SQL Server
27www.todaysoftmag.ro | nr. 33/martie, 2015
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.
Punctul geografic geoPoint = geography::STGeomFromText(‘POINT (-96.8501 32.7639)’, 4326)
SELECT * from myTableWHERE 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
Î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.
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 dispoziti-vul: cum se simte, cum arată, cât de repede răspunde, sunetele pe care le scoate, etc. . Sof tware Design-ul este s ingurul tip de design care pare să nu aibă utiliza-tor. 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 col-lective code ownership (ca majoritatea echipelor Scrum), ar fi bine să luați în consi-derare user-centric software design (software des ig n or ient at căt re ut i l i zator) . 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 folo-sire al aplicațiilor web un subiect atât de important astăzi? Aș argumenta că moti-vul î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 uti-lizatorul î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 design-ului 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ă produc-tivi î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 ter-menii produsului, se numește pierdere.
Agile Coach and Trainer, with a focus on technical practices@Mozaic Works
29www.todaysoftmag.ro | nr. 33/martie, 2015
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 dez-voltăm, primele funcționalități au luat ceva timp pentru a fi implementate (NB: în același timp învățăm și o nouă tehnolo-gie). 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 bot-tleneck. Ne-am uitat apoi la optimizarea activităților de UI / UX, dar asta e altă poveste.
Cheia acestei îmbunătățiri a stat în fap-tul că privind în urmă, ne-am dat seama că dezvoltam funcționalități care cores-pund câtorva tipuri de muncă:
• Adăugarea unei noi activități aplicată pe situația medicală a pacientului:create, display, change, hide;
• Legarea unei entități medicale de o intrare în jurnalul pacientului;
• Afișarea unui istoric filtrat după diverse criterii; Etc..
Din moment ce știam din roadmap-ul proiectului că vor apărea din nou astfel de cerințe, am început optimizarea pentru aceste tipuri de muncă.
Ocazional, trebuia să facem un nou tip de muncă care dura mai mult. Un exemplu a fost un serviciu de căutare a unui medi-cament, care este rapid, scalabil și ușor de modificat pentru a funcționa corect cu ultima versiune a bazei de date de medi-camente. A trebuit să învățăm să folosim vertx și mongodb pentru a face lucrul acesta, și ne-a luat de 3-5 ori mai mult timp decât o sarcină normală. Deoarece aceasta este o situație locală, care este puțin proba-bil să se repete, nu am făcut nimic pentru a optimiza.
Ideea este: ca o aplicație care este ușor de folosit pentru taskuri mai comune, Usable Software Design permite imple-mentarea rapidă a celor mai frecvente tipuri de caracteristici.
Acestea sunt principalele beneficii pe care le văd pentru Usable Software Design. Dar cum să-l obținem? Primul lucru este ...
3. Măsoară și îmbunătățeșteProcesul pe care l-am folosit pentru a
face designul mai operațional a fost destul de simplu:
• măsoară cât timp este nevoie pentru
a implementa fiecare caracteristică;• discută deviațiile la retrospectivă;• identifică ce ne împiedică să mergem
mai repede;• def inește și pune în aplicare
modificările;• repetă.
Noi folosim un proces Kanban / XP, așa că am folosit the cycle time distribu-tion diagram pentru a identifica punctele de deviație. Avem o retrospectivă recu-rentă la fiecare două săptămâni în care discutăm impedimentele și identificăm soluțiile. Implementarea a fost făcută în următoarele două săptămâni, și ne-am păstrat un ochi la cycle time distribution în următoarele luni. A fost ușor să vedem îmbunătățirile deoarece majoritatea task-urilor s-au mutat la stânga.
Într-un context Scrum, echipele nu măsoară cycle time, doar viteza. Problema este că viteza este un indicator agregat pen-tru toate funcțiile implementate pe durata sprintului. Prin urmare, echipele Scrum au două opțiuni pentru a ajunge la usable software design:
• Cantitativă: începe măsurarea tim-pului efectiv petrecut pe user story;
• Calitativă: executa o retrospectivă recurentă pe tema de usable design. Întreabă developer-ii ce le ia mai mult timp decât ar trebui. Într-o echipă în care există încredere și transparență, veți identifica imediat problemele.
Aceasta este metoda de bază pentru a obține usable software design. Metoda avansată este preluată din practicile de usability.
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ă per-soană 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.
30 nr. 33/martie, 2015 | www.todaysoftmag.ro
• Pregătește cam zece task-uri, dar așteaptă-te să finalizezi mai puține.
Acum știm cum să identificăm pro-bleme. Sunt sigur că următoare întrebare este...
5. Cum arată Usable Software Design?Pentru început menționez că ideea
de a se centra pe developer, ca utilizator al Software Design-ului, este foarte nouă. Am văzut discuții oarecum în jurul aces-tui topic, și am contribuit și eu la unele. Literatura din trecut despre Software Design a atins acest subiect, dar nu în mod explicit.
Există totuși foarte multă literatură despre usability. Voi menționa doar trei principii de bază ale usability-ului care se aplică în Software Design:
• Claritate,• Consistență,• Reducerea surprizei.
Prezentăm câteva exemple:
Claritate: Numește pachetele în funcție de denumirea funcționalității (pachete funcționale)
Iată un screenshot de la o aplicație pe care o dezvolt. Poți spune ce face doar pe baza numelor?
Prima oară l-am auzit pe Sandro Mancuso vorbind despre ideea aceasta la I T.A.K.E. Unconference 2014 (2014.ita-keunconf.com) și am fost foarte interesat să încerc. Văd ideea ca pe un bun start în Usable Software Design.
Consistență: Păstrează o struc-tură consistentă pentru fiecare pachet funcțional
Așa arată un pachet funcțional când este extins:
Fiecare conține trei lucruri:• o clasă de request,• o clasă de controller,• o clasă de view.
Încă trebuie să găsesc un loc mai bun pentru InvoiceFileNameGenerator, după cum puteți vedea limpede. Aceasta este o încălcare a celui de al treilea principiu, reducerea surprizei.
Consistență: Fiecare tip de clasă trebuie să aibă o interfață consistentă
Am văzut mai devreme că un pachet funcțional constă din trei tipuri de clase: a clasă de request, o clasă de control-ler și o clasă de view. Există și un nivel mai ridicat de consistență la care se poate ajunge, mai specific în interfața fiecăreia dintre aceste tipuri de clase. În acest exemplu, toate clasele de Request menționate mai sus au o metodă:response() Toate funcțiile control-lers au o metodă:render().Fiecare funcție de controller folosește un view pentru a reda informația. Aceste interfețe sunt con-sistente în toate pachetele funcționale.
Gânduri finale Usable Software Design vor aduce
două benef icii economice majore: implementare mai rapidă pentru task-urile comune și integrare mai ușoară a oameni-lor noi în proiect.
Pentru a obține Usable Software Design, avem nevoie de feedback de la
utilizatori, mai exact de la dezvoltatori. Există două metode pentru a obține: prin retrospective și rulând teste de usability.
Ideea nu este complet nouă. Principiile precum claritate și consistență au fost folosite mulți ani la rând pentru a obține Design mai bun. Ideea de usable Software Design este totuși o schimbare de per-spectivă; a te gândi la dezvoltator ca la utilizatorul software design-ului și a încerca activ să obținem feedback de la el sunt demersuri care vor aduce modificări în modul în care ne organizăm codul.
Mulțumiri!Am fost inspirat să scriu acest arti-
col după multe conversații cu: Sandro Mancuso, Samir Talwar, participanții la SoCraTes UK, Rebecca Wirfs-Brock, Adi Bolboacă, Claudia Rosu și mulți alții. Vă invit pentru o dezbatere mai apro-fundată în cadrul Workshopului de Usable Software Design la I T.A.K.E. Unconference 20151.
1 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 /
alex-bolboaca-usable-software-design/
programareUsable Software Design
31www.todaysoftmag.ro | nr. 33/martie, 2015
management
Să 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 finaliza-rea 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âr-zierea 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 pro-prie) 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 asigu-rare 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 respec-tiv, î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 spu-nem “produsul X este de o calitate mai bună decât produsul Y”, iar aceasta este în confor-mitate 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 proiec-tului, 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 nevo-ilor utilizatorului final. Aceste nevoi sunt traduse în ceea ce numim “factori de calitate” (quality factors) ce vor fi mai apoi integrați
î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 dezvolta-rea 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 perfecte- dar 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 Improvement Lead Apprai ser 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 measu-rements 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 atri-butelor 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 responsabi-litate în asigurarea calității produsului rezultat.
Asigurarea calității se împarte în două
1 www.qpit.net/blog/understanding-quality.html
categorii majore. În prima categorie intră activitățile de prevenire a defectelor în timpul procesului de dezvoltare prin definirea unui mod de lucru standardi-zat, stabilirea momentelor și frecvenței validărilor și verificarilor precum și revi-zuirea î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 peri-odice 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 cunos-cută ș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 proiectu-lui este nevoie de planificarea riguroasă a tuturor activităților legate de QA: identi-ficarea nevoilor utilizatorului, translatarea acestora în obiective de calitate, planifica-rea 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, con-form planului, activități de monitorizare a performanței procesului de dezvoltare și a calității; este necesară planificarea momentelor de evaluare: frecvență, con-text și obiective; evaluarea progresului (sau a regresului) din perioada scursă de la ultima verificare; luarea măsurilor de corecție necesare dacă este cazul; evalua-rea 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 pro-ces de muncă astfel încât să servească cât mai bine nevoilor proiectului.
Mai mult, rezultatele măsurătorilor colectate în timpul existenței proiectului de dezvoltare, împreună cu setul de prac-tici 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 dove-dit î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 pro-ces de dezvoltare a unui produs.Quality Assurance poate fi asemănată cu un echi-pament 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 con-testă valoarea părții a doua din fiecare afirmație, se pune preț mai mare pe cea
managementQuality Assurance în Agile
Fig. 1: Rolul QA intr-un proiect.
33www.todaysoftmag.ro | nr. 33/martie, 2015
TODAY SOFTWARE MAGAZINE
din partea stângă. Mai mult, în pagina dedicată istoriei mișcării Agile, scrisă de Jim Highsmith, găsim următorul paragraf2:
The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodo-logy. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-mai-ntained and rarely-used tomes.
Putem verifica și printre cele douăspre-zece principii Agile3: nimic nu interzice definirea unui proces care să ne ajute în munca noastră zilnică și astfel să ne folo-sim de ceea ce am învățat de-a lungul timpului. Nu cred că a spus cineva vreo-dată că prețuiește mai mult colaborarea într-o echipă în defavoarea calității. Sau, dacă a spus-o, e puțin probabil să mai con-ducă vreo afacere acum.
Oare este posibil ca un proces de management al calității să nu contravină principiilor Agile? Oare s-ar putea defini procese de lucru pentru diferite etape din viața unui proiect (sau produs), pentru fiecare rol implicat, în așa fel ca aceste pro-cese să AJUTE o echipă Scrum?
Scrum - cea mai folsită „aroma” de Agile - este un model al unui proces de dezvoltare software. Se pune accent pe colaborarea între membrii echipei și între echipă și client în dorința de a răspunde mai repede nevoilor clientului, de a livra într-un timp mai scurt și de a reacționa mai bine la schimbare. Conform definiției, o echipă Scrum trebuie să fie capabilă să se organizeze independent și să aibă un nivel suficient de maturitate. Fiecare nevoie este acoperită, fiecare membru își cunoaște reponsabilitățile, știe exact ce are de făcut
2 http://agilemanifesto.org/history.html
3 http://agilemanifesto.org/principles.html
(și la nevoie execută fără nicio ezitare) și se adaptează foarte repede oricărei schimbări a mediului înconurător. Aceasta este mai mult definiția unui pluton al unei unități din forțele speciale, nu al unei echipe de programatori palizi. Din păcate, nivelul de maturitate necesar pentru funcționarea efectivă a unei echipe Scrum nu este ceva ce se poate obține peste noapte. Membrii echipei trebuie să înțeleagă la un nivel acceptabil clientul și nevoile de business ale acestuia astfel încât produsul dezvol-tat să vină în întâmpinarea acestor nevoi. Fiecare membru al echipei trebuie să aibă încredere totală în omul de lângă el și este de așteptat ca ei să rateze de câteva ori înainte de a ajunge la cea mai bună soluție indiferent de problema asupra căreia își îndreaptă atenția într-un anume moment.
Așa cum am văzut mai sus fiecare membru al echipei joacă un rol important în construirea unui produs final de calitate. Din păcate, nu întotdeauna este clar acest lucru – responsabilitatea se diluează între toți participanții la procesul de producție și, câteodată, este ceva subînțeles („sun-tem profesioniști, știm fiecare dintre noi ce avem de făcut”). Programatorii progra-mează, tester-ii testează – pentru aceasta suntem aici pâna la urmă, nu? De ce un programator ar trebui să revizuiască scrip-turile sau cazurile de test? Nu este vorba despre o verificare din punct de vedere sintactic, dar să se asigure că munca pro-prie funcționează conform cu așteptările clientului și dincolo de cazul trivial (happy flow)! A contestat vreodată cineva rolul sau activitățile managerului de proiect într-o echipă Scrum? Doar există Scrum Master care să conducă echipa! Sau, pentru că există un Product Owner, de ce un rol de Requirement Engineer specializat? Această dezbatere ar putea continua la nesfârșit.
Quality Assurance poate ajuta o echipă Scrum să-și clarifice scopul și să păstreze ritmul și direcția astfel încât să-și atingă
acel scop fără prea multe devieri pe par-curs. 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 produsu-lui 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 pro-iect 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 conti-nuă a fiecărui aspect al produsului și a modului de lucru, întregul proces de dez-voltare prinde viață și evoluează în timp. Metodologia Scrum se concentrează asu-pra 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
34 nr. 33/martie, 2015 | www.todaysoftmag.ro
Quality Assurance în Agilemanagement
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 asi-gurăm că cerințele produsului acoperă în întregime nevoile de business ale clientu-lui. 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-uri-lor 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 termino-logies 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 diffe-rent 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 fer-vour, 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 generati-ons 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ăs-puns la orice întrebare. Nu există niciun „silver bullet” sau panaceu pentru orice încercare ce am putea-o întâlni.
sus urmând calea de miloc. În urmă cu mai mult de cinci ani, cu suport total din par-tea 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 anali-zat ș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 spe-cifice ce acoperă fiecare aspect din „viața” unui proiect. Astăzi sunt 24 de procese definite ce includ aproximtiv 300 de task-uri 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, anali-zâ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 pro-cesele 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 defi-nite 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 mana-gement 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 asi-gură 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ă even-tualele neconformități sunt adresate la timp. Pentru că lucrează aproape de echi-pele din proiecte QA Officers sunt în prima linie de promovare a standardelor interne și ajută la colectarea de feedback pentru
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” (CMMI-DEV v1.3) creat de Software Engineering Institute, un centru de cercetare non-profit de la Carnegie Mellon University5. Practicile interne ISDC au fost evaluate și certificate la nivelul 3 de maturitate con-form standardelor SEI – ISDC fiind una dintre puținele organizații ce au obținut această recunoaștere în România.
Asigurarea calității este perma-nent în atenția tuturor de la ISDC deja de multă vreme. În afară de dezvolta-rea 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ă sesi-uni „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 pro-dusele 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.
Bibliografie1. CMMI® for Development, version 1.3
– Improving processes for developing better products and services, November 2010,Technical report
2. http://agilemanifesto.org/ 3. 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)
4. ”Quality Assurance - Making Process Work” – Peter Leeson la ISDC, Mai 2014
5 http://www.sei.cmu.edu/
35www.todaysoftmag.ro | nr. 33/martie, 2015
Vom î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.
Securitatea trebuie înțeleasă ca o măsură de compromis. De exemplu, cea mai bună metodă de a face o aplicație complet secu-rizată în Internet este să nu o conectăm la Internet.
Unul dintre aspectele importante ale securității este confidențialitatea, care repre-zintă ascunderea surselor de informații. Mecanismele folosite pentru realizarea confidențialității sunt: încriptarea, folosirea parolelor și controlul accesului adică acorda-rea accesului la resurse unui număr limitat de persoane.
Un alt aspect este integritatea, care înseamnă că datele sunt protejate față de modificări neautorizate. Aceasta este rea-lizată de obicei prin autentificare. User-ul trebuie să furnizeze credențiale (username si password). În plus, sistemele de detecție trebuie să fie folosite în cazul în care siste-mul de autentificare eșuează. Acest sistem este format din loguri de acces și pattern-i de analiză.
Un ultim aspect este disponibilitatea, care reprezintă abilitatea de a utiliza un sistem sau o resursă la nevoie.
Cel mai simplu mod în care un sistem este vulnerabil îl reprezintă atacurile de refu-zare a serviciilor. Acestea blochează accesul la sistem al utilizatorilor sau reduce nivelul de performanță al sistemului. Sistemul ar trebui să fie atât de flexibil încât să detecteze aceste atacuri și să răspundă la ele.
Aspecte de securitate la nivelul software-urilor
Orice sistem ce conține informații confidențiale este foarte probabil o țintă a atacatorilor.
Câteva dintre conceptele fundamentale de securitate sunt:
• API-uri securizate: este mult mai ușor să concepem un cod securizat încă de la început. Încercarea de a securiza codul
existent este dificil și generator de erori.• Duplicarea: codul duplicat este posi-
bil a nu fi tratat consistent la copiere. Mai mult, aceasta violează și principiul progra-mării Agile, Don’t Repeat Yourself (DRY).
• Restricționarea privilegiilor: când codul operează cu privilegii reduse, atunci exploatarea defectelor este dejucată.
• Trust boundaries: stabilirea limitelor între diferitele părți ale aplicației. Spre exemplu, orice date care vin dintr-un browser web, într-o aplicație web, trebuie verificate înaintea utilizării.
• Verificarea securității: efectuarea veri-ficărilor de securitate în câteva puncte definite și returnarea unui obiect pe care codul client îl reține, astfel încât să nu mai fie nevoie de verificări ulterioare.
• Încapsularea: folosirea privată a interfețelor și a câmpurilor și evitarea accesorilor.
Tipuri de amenințări de securitatePutem să împărțim amenințările în
următoarele categorii:• Injecția și incluziunea;• Gestionarea resurselor (buffer over-
flow, denial of service)Ș• Informațiile confidențiale;• Accesibilitatea și extensibilitatea;• Mutabilitatea.
Injecția și incluziunea reprezintă un atac ce determină un program să interpreteze date într-un mod neașteptat. De aceea, orice date venite dintr-o sursă nesigură trebuie validate. Principalele forme de atac sunt:
î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 gene-rată, 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.
@Override public String getServletInfo() { return “Servlet-ul meu”; }}
SQL Injection se bazează pe date nefil-trate pentru a modifica rezultatele SQL. Fie următorul cod:ResultSet rs = stmt.executeQuery (“SELECT * FROM DEMO.Table1 WHERE NAME=’” + name-Param + “’ AND AGE =’” + ageParam + “’”);
Dacă atacatorul trimite: ‘valori’ OR ‘a’ = ‘a’ , acesta va face predica-tul de selecție adevărat, ceea ce este echivalent cu:
ResultSet rs = stmt.executeQuery (“SELECT * FROM DEMO.Table1”);
Prin aceasta ata-catorul 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 modi-fică 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()));
managementDezvoltarea aplicațiilor securizate în Java
Î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 exemplu de for-mat necontrolat de string-uri:
public class Main {static Calendar c = new Gregori-anCalendar(1995, GregorianCalen-dar.MAY, 23);
public stat-ic void main(String[] args) {String param = “%1$tY”; System.out.printf(param + “ nu se potriveste! A fost emis in ziua %1$te \n”, c); }}
În acest cod pro-gramatorul încearcă să printeze rezul-tatele atunci când două valori nu se potrivesc. Problema poate apare atunci când este trimis un
string format în loc de lună. Atacatorul își poate da seama de an, spre exemplu, atunci când un card expiră.
Din punct de vedere al managementului de resurse avem:• buffer overflows: copierea unui buffer de intrare într-un
buffer de ieșire fără verificarea dimensiunii. Are ca rezultat faptul că un atacator poate executa cod în afara unui program normal. Java este imună la acest tip de atac deoarece deține un management automat al memoriei.
• denial of service: este încă posibil în Java prin folosi-rea nepotrivită a resurselor. Iată câteva exemple de atacuri 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 bloca procesorul și înghiți un spațiu mare de memorie. Ca măsură de protecție putem limita dimensiunea și procesarea ce pot fi făcute într-o resursă ca aceasta.
• 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 parsa-rea 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(); }
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.
Dăm mai jos un exemplu de creare și folosire a unui fișier de log.
public class BasicLogging { Logger logger = Logger.getLogger(“com.example.BasicLogging”);
public void logMessages(){ logger.severe(“A aparut o problema severa”); logger.warning(“Avertisment”); logger.log(Level.INFO,”Informatie utila”); logger.config(“Informatii despre CONFIG”); } public static void main(String[] args) { BasicLogging bl = new BasicLogging(); bl.logger = Logger.getLogger(“com.example”+ “.BasicLogging”); try { bl.logger.addHandler(new FileHandler( “Basic.log”)); bl.logger.setLevel(Level.INFO); bl.logMessages(); } catch (IOException e){ e.getMessage(); } }}
Vă dorim lectură plăcută și așteptăm cu interes întrebările voastre!
38 nr. 33/2015 | www.todaysoftmag.ro
programare
Abordare simplă a riscului în Scrum
Î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 necesi-tatea punerii în aplicare a unor remedii. Un prim demers a fost să se obțină opi-nia 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 chesti-onar axat tocmai pe această problemă, care a fost lansat nu cu mult timp în urmă.
Managementul de riscuri este o dis-ciplină 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 riscu-rile 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 deter-
mina nivelul efectelor negative.• Ierarhizarea riscurilor identificate
în funcție de frecvență și de gravitatea consecințelor.
• Crearea planurilor de acțiuni (răs-punsuri) 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ăs-pundă la două întrebări esențiale:
• Ar fi bine ca riscurile să fie monitori-zate doar la nivel de iterație? Răspunsul este Nu.
• Este necesar să monitorizăm riscu-rile 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 pro-iect și a cerințelor acestuia.
• Procesul de risc management la nivel de iterație este făcut luând în con-siderare 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.
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 verificareCred 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 Descriere Da/NuCerințe Sunt cerințele pregătite?Cerințe Product Owner-ul a identificat sco-
pul proiectului?Design Designul și arhitectura sunt deja
stabilite sau vor fi analizate într-o iterație separată?
Design Designul și arhitectura sunt deter-minate și echipa a înțeles acest aspect?
Proces Echipa a mai fost implicată în traininguri Agile înainte? În caz negativ, este necesar?
Proces Întreaga echipă este pregătită și a înțeles Agile-ul înainte de a fi implicați în proiect?
Proces Scrum master-ul a înțeles matricele care ar trebui folosite în proiectele de tip Agile?
Managementul iterațiilor
Scrum master-ul este informat des-pre cerințele din backlog?
Managementul iterațiilor
Scrum master-ul știe de metodolo-gia de estimare în Agile?
Managementul Iterațiilor
Există un tool care poate fi folosit în managementul activităților?
Infrastructură Infrastructura este pregătita pentru execuția proiectului?
Infrastructură Există un canal de comunicare asupra căruia ați căzut de-acord în cazul în care echipa este global distribuită?
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 apla-narea 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 proiectProcesul 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 riscurilorLa începutul unui proiect, riscurile proiectului sunt identifi-
cate 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.
40 nr. 33/martie, 2015 | www.todaysoftmag.ro
testaremanagement
Monitorizarea riscurilorToate riscurile identificate anterior, sunt revizuite și monito-
rizate în sesiunile dintre iterațiile proiectului. Lista de riscuri este actualizată, marcându-se acele riscuri care s-au închis, sau adău-gâ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 proiectuluiLista 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, docu-mente 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 manage-ment 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țieiLa începutul unei iterații, o ședință despre managementul ris-
curilor 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.
Î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.
Identificarea: din momentul în care avem o primă versiune a backlog-ului produsului și o bună înțelegere a cerințelor, echipa
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 ter-minată, 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 cla-sificate ș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 pre-cedente) 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ăs-puns 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 riscu-rilor la nivel de iterație, detaliind pașii implicați.
În timpul iterațieiMonitorizarea este cheia procesului de management al ris-
curilor. Aceasta trebuie să existe pe parcursul întregii execuții a
Abordare simplă a riscului în Scrum
41www.todaysoftmag.ro | nr. 33/martie, 2015
TODAY SOFTWARE MAGAZINEtestare
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ă.
SondajeAnul 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-mativ 70 de manageri de proiect, cu obiectivul de a afla care sunt practicile uzuale relative al managementul riscurilor din manage-mentul Agile al proiectelor.
Rezultatele au fost următoarele:• 67% din respondenți analizează riscurile proiectului
săptămânal.• 87% din respondenți susțin că managerul de proiect este cel
responsabil de managementul riscurilor.• 27% din respondenți au susținut că în același timp, și pro-
duct owner-ul este responsabil de managementul riscurilor.
Respondenții au fost întrebați cine este responsabil principal de identificarea riscurilor. Răspunsurile au fost: echipa proiectu-lui și membrii ei (80%), managerul de proiect (67%), echipa de dezvoltare și membrii ei (40%) și scrum master-ul (40%).
În același timp, 73% din respondenți folosesc o listă de ris-curi pentru documentare, analiză și mentenanță, iar restul de 23% folosesc o altă tehnică de monitorizare sau nu documentează ris-curile î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.
ConcluziiExistă foarte multă informație și foarte multe detalii despre
instrumente specifice folosite în identificarea, clasificarea (pe baza unor indicatori cantitativi sau calitativi), și monitorizarea riscurilor în timpul iterațiilor.
Chiar dacă utilizarea metodelor Agile reduce riscurile încă din fazele inițiale ale dezvoltării de software, trebuie să luăm în considerare tendința actuală de a include timp într-o manieră mult mai formalizată și pentru managementul riscurilor.
“Risc este pauză în livrare, nu muncitori inactivi” - Ken Rubin
Resurse1. Risk Management in Agile Model – Monika Singh & Ruhi Saxena2. Project Risk Management model based on Prince2 and Scrum
Frameworks – Martin Tomanel and Jan Juricek3. Three Key Agile Risk Management Activities – Ken Rubin
42 nr. 33/martie, 2015 | www.todaysoftmag.ro
În momentul de față am ocupația de UX Designer într-un mediu Agile, într-o echipă de 17 designeri, care au ca scop principal livrarea celei mai bune experiențe utilizatorilor, prin produsele software dez-voltate de către companie.
Mediul mereu inovator în care am șansa să lucrez și libertatea de a experi-menta diverse metodologii, mi-au permis să încerc noi procedee de a dezvolta un design. Comparând cu metodele utilizate în trecut, am decis într-un final să mă opresc asupra uneia singure, pe care o con-sider cea mai bună pentru a livra un design de succes: utilizarea prototipurilor.
Așadar, consider că realizarea unui produs trebuie să înceapă mereu cu un prototip, indiferent că produsul este de tip software sau de tip hardware. Prototipul este cel care dă o idee clară, o previzuali-zare exactă a produsului final. Prototipul este o clonă, este un screenshot al produsu-lui viitor, care va deveni complet funcțional după finalizarea implementării.
Pentru mine nu există nici o excepție de la această regulă. Pentru fiecare pro-iect la care lucrez, pornesc de la o idee de ansamblu, proiectată pe o bucată de hârtie, ajungând până la momentul în care pot să furnizez un prototip al produsului final, în cele mai mici detalii, indiferent că acesta este o machetă interactivă a unui website sau o simulare 3D a unui obiect.
Procesul se desfășoară în iterații, cu fiecare iterație prototipul căpătând mai multe detalii, devenind mai puternic, până în momentul în care este considerat funcțional și gata pentru implementare.
Dezvoltând ideea, fiecare iterație are caracteristicile sale:
a. Prima iterație este întotdeauna partea în care se colectează toate informațiile necesare de la experții din domeniu asupra produsului pentru care urmează să creez designul. Toate informațiile sunt reverificate și de echipă din punct de vedere tehnic. Apoi stabi-lim ce funcționalitate se dorește, pentru ca ulterior să trasez prima schiță a vii-torului produs și să stabilesc flow-ul în care designul proiectului se va desfășura.
b. Următorul pas, iterația a doua, se concentrează în special pe interacțiunea utilizatorului cu prototipul și pe vali-darea funcționalității stabilite în prima iterație. Ce urmărim în special în această iterație este modul în care prototipul este utilizat de către publicul țintă, mai exact punem o primă versiune a acestuia la dispoziția sa și analizăm modul de interacțiune. Urmărim dacă utilizatorul se simte confortabil cu poziția anumitor elemente grafice, dacă este obositor pen-tru utilizare îndelungată, dacă identifică ușor componentele esențiale, etc. .
c. În final, în ultima iterație a pro-cesului de design, concentrarea este asupra detaliilor vizuale și a finisă-rii detaliilor prototipului realizat. Prototipul primește forma comerci-ală, prin elemente grafice complexe și repoziționarea componentelor, dacă este necesar, pe baza feedbackului rezul-tat din analiza interacțiunii utilizatorilor cu acesta. Colectarea acestui feedback este esențială, întrucât, în momentul în care designul este validat, trece în etapa
de implementare cu specificații clare și complete și se transformă în cele din urmă în produsul dorit de beneficiar.
Iterații în conceperea unui prototip
Fiecare des igner are propr i i le preferințe în ceea ce privește tool-urile de care se folosește pentru îndeplinirea task-urilor și realizarea prototipurilor. Personal, eu prefer utilizarea tool-ului Axure pentru a crea prototipuri și creionul și coala de hârtie ori de câte ori am nevoie să trasez o idee rapidă. De ce Axure? Pentru că se poate dezvolta cu ajutorul său un prototip html care va evolua într-un mod organic de la schițe simple, în prima iterație, la un prototip interactiv, cu design complet, gata de user-testing și implementare.
Totuși, tool-ul cel mai bun este cel ală-turi de care te simți cel mai confortabil și cu care îți poți realiza designurile într-un timp rezonabil. Ceea ce contează cu adevă-rat este rezultatul final, un design ușor de înțeles, utilizabil și implementabil.
Realizarea unui prototip are doar avantaje și din experienta mea cu diverse modalități de lucru, este o metodă prefera-bilă în detrimentul realizării unui produs pe principiul “mergem înainte, implemen-tăm din mers și îmbunătățim pe parcurs”. Beneficiarul produsului va ști exact ce intră în producție și ce va primi la finalul acesteia.
Î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.
Importanța realizării de prototipuri
design
43www.todaysoftmag.ro | nr. 33/martie, 2015
TODAY SOFTWARE MAGAZINE
Voi detalia cinci dintre multiplele avantaje ale utilizării unui prototip:
1. Simulează produsul realCel mai important avantaj al unui
prototip este acela că simulează produ-sul real și viitor. Cu ajutorul acestuia se pot atrage clienți care să investească în produs, înainte de a aloca orice resursă necesară implementării. Se poate testa corectitudinea designului înainte ca acesta să ajungă în producție și se pot descoperi erori de proiectare, evitând compromite-rea întregului proiect. De asemenea, un prototip pus la dispoziția unui eșantion de utilizatori ajută la descoperirea din timp a modului de interacțiune al acestora cu produsul și se cunosc așteptările lor.
2. Provoacă la crearea de idei noiFiecare persoană are propria viziune
asupra produsului ce urmează a fi imple-mentat și, în principiu, dorește ca această viziune să se regăsească în produsul final. Expunerea prototipului ajută la o unifor-mizare a tuturor ideilor și dă posibilitatea beneficiarilor să vadă produsul dintr-o altă perspectivă, să îl vadă materializat și să ofere un feedback mai concentrat pe detaliile dorite, pe ceea ce inițial aveau în minte. Începând de la un prototip low-fidelity care este axat pe flow-uri și care direcționează utilizatorul spre review-uri ale funcționalității, se ajunge în cele din urmă la un prototip high-fidelity unde se obține feedback privitor la detaliile de modelare vizuală, cum ar fi fonturile, culorile, alinierile, mărimea butoanelor, etc.. Feedbackul este esențial pentru a des-coperi care sunt necesitățile și așteptările utilizatorilor, cerințele de business și pen-tru a avea o idee clară a direcției în care se îndreaptă produsul.
3. Previne orice problemă majorăConceperea unui prototip care poate
fi supus cât mai rapid testării permite rezolvarea problemelor majore înainte ca acestea să provoace pagube financiare, dacă ar ajunge în producție. Prin punerea prototipului la dispoziție unor utilizatorii reali pentru testare, se obțin în avans toate sugestiile și așteptările, înaintea intrării produsului în producție.
Dintre multiplele metode de a depista problemele cu care se confruntă utiliza-torii, Google Analytics spre exemplu, un tool folosit foarte des de către mine, oferă posibilitatea de a interpreta datele de utilizare ale unui produs de către un uti-lizator aflat în spațiul său confortabil, fără
ca acesta să cunoască faptul că este anali-zat. Comportamentul său în interacțiunea cu produsul va fi natural și realist, diferit de atunci când este invitat la o sesiune de user testing, sesiune în care ar ști că este analizat.
Cu toate acestea, user testing-ul în care utilizatorul este monitorizat live este cea mai bună metodă în a depista problemele cu care se confruntă acesta, deoarece există posibilitatea de a culege cât mai multe feedbackuri și să vedem unde greșește în îndeplinirea task-urilor de utilizare. În cadrul mediului nostru de lucru mereu includem în procesul de design aplica-rea de survey-uri potențialilor utilizatori în legătură cu produsul ce urmează a fi dezvoltat. Dintre respondenți, îi selec-tăm pe aceia care ar avea cea mai mare tangență cu produsul dezvoltat și care au bifat opțiunea pentru disponibilitate de a participa la sesiunile de usability tes-ting. Aceste sesiuni se desfășoară online. Fiecare utilizator partajează propriul ecran, pentru a ne demonstra modul în care interacționează cu prototipul, rolul nostru fiind de a depista acele secțiuni ale designului unde întâmpină dificultăți. În funcție de informațiile colectate din aceste sesiuni, modificăm prototipul și organi-zăm ulterior altă sesiune de testare.
4. PlanificareEchipele care implementează desig-
nul primesc informații esențiale care îi ajută să planifice ceea ce trebuie să imple-menteze. Un prototip poate fi considerat, cel mai adesea specificația proiectului și ajută întreaga echipă să creeze user stories și să se concentreze asupra necesităților utilizatorilor.
Dacă acesta este realizat la timp, îna-intea începerii unui Sprint, va aduce doar beneficii în echipele de Scrum. Din experiența mea, am observat că deținerea unui prototip interactiv ajută programatorii care se ocupă de imple-mentare să aibă o idee mult mai clară asupra modului în care trebuie să conceapă interacțiunea componentelor designului. Prin prototip se comunică mult mai clar ceea ce am dori să se implementeze în realitate, materializându-se viziunea din prima iterație.
5. Este rapid și ușor de creatChiar și un beneficiar al produsului
poate ajuta la dezvoltarea unui prototip. Esențial este să furnizeze o simplă idee pe hârtie, pentru ca designerul să înțeleagă 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.
ConcluzieAm î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.
Procesarea 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.
Dar așteptați, aceasta nu e tot…Dacă adaug ca procesarea să fie o acțiune de tipul totul-
sau-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 repre-zintă 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ă vali-dă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 tre-buie 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).
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:
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)
Î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 ief-tin, dar memorarea folosind chronicle-queue devine ceva trivial.
ConcluziiDupă 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:
Este evident că exista mulți alți factori care ar trebui luați în considerare, dar bazat pe nevoile noastre, această soluție este sca-labilă și a fost aplicată cu cel mai mic efort.
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.
Acest articol va prezenta cum se instalează o bază de date de tip Cassandra și cum se poate crea un cluster Cassandra prin adă-ugarea mai multor noduri. Vom vedea cum se utilizează linia de comandă, cum arată limbajul de interogare (CQL) și un exemplu de clasă Java care folosește un client API Cassandra. În final vom discuta despre limitările acestei soluții NoSQL, modul cum aces-tea pot fi depășite și câteva recomandări generale.
Cum se instalează CassandraBaza de date Cassandra este una din cele mai utilizate baze
de date NoSQL oferind cele mai bune rezultate pentru scalarea performanței și posibilitatea de a distribui în mod partiționat setul de date pe nodurile din cluster în mod gratuit (licența Apache 2.0). Următorul grafic creat de compania DataStax compară 5 din cele mai utilizate soluții NoSQL din care reiese performanța superioară a bazei de date Cassandra în ceea ce privește creșterea volumului de date procesate odată cu creșterea numărului de noduri din cluster.
Necesare pentru instalare: 1. JDK 7+2. Python 2.7.x
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ă foarte familiar. Limbajul de interogare, CQL (Cassandra Query Language) e aproape identic cu SQL.
cqlsh:demo> create keyspace demo with replication = ... {’class’:’SimpleStrategy’, ’replication_factor’:1};cqlsh:demo> create table users ( ... id varchar primary key, ... name varchar ... );cqlsh:demo> insert into users (id, name) values ... (’1’, ’John’);
cqlsh:demo>cqlsh:demo> select * from users where id = ’1’;
id | name----+------ 1 | John
(1 rows)
Singurul aspect necunoscut din exemplul de mai sus ar trebui să fie conceptul de keyspace care se aseamănă cu schema din baza de date Oracle și conține informații despre cum trebuie replicate datele în cluster-ul de Cassandra.
Clustere CassandraPentru a putea scala performanța unei aplicații, Cassandra
permite configurarea de clustere de noduri Cassandra. Prin utili-zarea cluster-elor o aplicație poate beneficia de un grad ridicat de disponibilitate, o scalare liniară a performanței și de o interfață simplă de acces către o multitudine de servere de cost redus fără 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 interme-diul 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:
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.Sim-pleSeedProvider parameters: - seeds: ”16.22.70.184”listen_address: 16.22.70.184
După ce fișierul de configurare este finalizat, instalați pache-tul Cassandra și copiați fișierul cassandra.yaml pe toate nodurile din cluster. Valoarea cluster_name trebuie să fie identică pe toate mașinile. Nodurile seed sunt utilizate de către fiecare nod din cluster pentru a descoperi topologia cluster-ului (Pentru acest exemplu alegeți un nod ca și nod seed și completați IP-ul aces-tuia pe restul mașinilor). Setați câmpul listen_address la adresa IP a fiecărei mașină, aceasta va fi folosită pentru a comunica cu celelalte noduri.
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:
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În ceea ce privește clienții de API, Cassandra oferă o gamă
largă de posibilități în funcție de limbajul de programare utili-zat. 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 eco-sistemul 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.
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 cluster-ul Cassandra utilizând nodul contact primit (în acest caz, mașina locală) care are rolul de a-i descoperi clientului topologia cluster-ului. 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 reconec-tare ș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:
Connected to cluster: Test Cluster[Row[1, John]][Row[1, John]]
Cassandra, limitări și soluțiiCu toate că baza de date Cassandra oferă multe avantaje com-
parativ cu soluțiile clasice de tip relațional, prezintă de asemenea și câteva dezavantaje semnificative. Punctele slabe ale acestei soluții sunt:
i. Fără tranzacții,ii. Fără JOIN-uri,
iii. Fără interogări complexe.
Fără tranzacțiiCassandra nu oferă garanția atomicității și izolării la nivel de
TODAY SOFTWARE MAGAZINE
48 nr. 33/martie, 2015 | www.todaysoftmag.ro
Apache Cassandra, Primii Pașiprogramare
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-orien-ted 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 clus-ter, 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 progra-mator și autor, Martin Fowler, spune că nu trebuie privită ca și un dezavantaj major fiindcă în majoritatea cazurilor utiliza-rea 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ă JOIN-uriAceastă 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 aceas-tea, în funcție de modelul de business al aplicației, utilizarea de modele agregate ar putea simplica mult codul de persistență.
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 inte-rogari 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.
ConcluzieNoSQL reprezintă un pas important în dezvoltarea mecanis-
melor 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 teh-nologie ce merită învățată.
Bibliografie1. Introduction to NoSQL by Martin Fowler, https://www.youtube.com/
whatsNew2.html5. Apache Hive, https://hive.apache.org/6. Apache Pig, http://pig.apache.org/7. Cassandra High Performance Cookbook by Edward Capriolo8. martinfowler.com/eaaCatalog/optimisticOfflineLock.html
Necesitatea 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 vir-tuale 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 sin-cronizate din punct de vedere al managementului, pentru a oferi funcții și experiență similară pentru utilizatorii celor două sis-teme 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ă tes-tarea 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 lim-baj. 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 lim-baje 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 AppiumAppium este construit pe baza arhitecturii client/server, partea
de server fiind bazată pe node.js, iar cea de client fiind reprezen-tată 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
50 nr. 33/martie, 2015 | www.todaysoftmag.ro
testareAppium - testare automată cross-platform pentru dispozitive mobile
testelor. În principal vorbim de faptul ca testele de IOS pot fi exe-cutate doar pe platforma MAC OSX, din cauza dependenței de XCode (desigur, se pot executa remote de pe o mașină Windows). Pe de altă parte testele de Android pot fi executate de pe mașini folosind Windows, OSX sau Linux, condiția principală fiind 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 folo-sirea 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):
Totul începe cu pregătirea testelor, o practică adesea folo-sitoare 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 testu-lui 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:
@BeforeMethodpublic void setUp(){ File app = new File(“appFolder”, “myApp.apk”); DesiredCapabilities capabilities = new DesiredCapabilities();
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:
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ă inco-rectă, se validează că butonul SignIn este activat.
4. Utilizatorul face o acțiune touch pe butonul SignIn, se vali-dează apariția unui mesaj de eroare în și că butonul este în continuare vizibil.
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 auto-mate 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 mode-lează î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 clasei, astfel respectând filosofia OOP, acțiunile sau caracteristi-cile elementelor vor fi expuse ca metode publice, ușor de utilizat în testul propriu-zis. Acest pattern este similar cu PageFactory utilizat în testele Selenium WebDriver.
Clasa care va modela ecranul (de fapt porțiunea de ecran care conține elementele de autentificare) este prezentată mai jos, explicațiile fiind prezentate sub forma comentariilor Java, por-nind de la premisa unui cod self-describing.
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;
//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;
public LoginScreen(final AppiumDriver driver) { this.driver = driver; //criteriile de identificare annotated //mai sus sunt inițializate PageFactory.initElements(new AppiumFieldDecorator(driver), this);
Această organizare a testelor ajută mult la mentenanță, ade-sea 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, presupu-nâ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 imple-mentat 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 predica-tes), oferind flexibilitate foarte mare și complexitate pe măsură.
ConcluziiAppium 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
finală nefiind necesare nici un fel de intervenție asupra codului pentru a face aplicația testabilă, număr mare de limbaje supor-tate, 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 dezavan-taje: 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.
Am î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 viito-rul ș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 vii-toare (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 ana-liză?’ 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 bio-genetică, 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 tehnologii-lor, 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 transportu-rilor 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 schim-bare 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 teh-nice ale competiției.
Roadmapping – folosește avansul teh-nologic anticipat pentru a genera planuri de
Analiza pentru tehnologiile viitoare
diverse
54 nr. 33/martie, 2015 | www.todaysoftmag.ro
Analiza pentru tehnologiile viitoarediverse
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 tre-buie 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.
În continuare, este prezentat generic procesul previziunii. La intrări sunt lucrurile care se întâmplă în prezent. Înăuntrul pro-cesului 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, expli-cativ și participativ.
Cum spațiul articolului e limitat, pentru cei mai curioși din-tre 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).
Se folosesc de aceste discipline deopotrivă oameni de la nivel guvernamental, centre de cercetare, organizații non-profit pre-cum și compani private care doresc să se mențină pe piață sau să își crească profitabilitatea.
Este foarte valoros pentru societate că aceste discipline faci-litează 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.
Biografie1. 1 . h t t p : / / w w w . n e s t a . o r g . u k / p u b l i c a t i o n s /
