Numarul 30 - decembrie 2014 - Today Software Magazine

Nr. 30 • Decembrie 2014 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

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

Machine Learning la modul practic

Despre testare, descoperiri științifice

Riscuri aduse de modul de lucru cu branch-uri Testarea performanței de la waterfall la Agile Atlassian JIRA REST API Mai mult decât software Câștigătorii Startup Spotlight Dosar de startup: myDog

și revoluții

Despre antreprenoriat, la final de an Promisiunile JDK 9: O scrisoare pentru Moș Crăciun?!

Metrici în programarea obiectuală Interviu cu Tudor Gîrbă Utilizarea sistemelor de operare compatibile cu OSEK/VDX în sistemele embedded A fi sau a nu fi responsive

6 IT Days - imaginea IT-ului clujean Ovidiu Măţan

8 Despre antreprenoriat, la final de an Andrei Kelemen

10 Dosare de startup: MyDog Radu Popovici

12 Startupul Axosuits a câștigat How to Web Startup Spotlight 2014 Irina Scarlat

14 Metrici în programarea obiectuală - Interviu cu Tudor Gîrba Ovidiu Măţan

16 Despre testare, descoperiri științifice și revoluții Alexandra Casapu

20 Testarea de performanță de la Waterfall la Agile Claudiu Gorcan

22 Riscurile operării cu branch-uri Anghel Conțiu

25 Utilizarea sistemelor de operare compatibile cu OSEK/VDX în sistemele embedded Mircea Pătraș-Ciceu

28 Salveaza timpul utilizatorului cu o interfață bine proiectată Axente Paul

31 Design în loc de Programare Vlad Derdeicea

33 A fi sau a nu fi responsive Raul Rene Lepsa

35 Promisiunile JDK 9: O scrisoare pentru Moș Crăciun?!

Olimpiu Pop

37 Machine Learning la modul practic Sergiu Indrie

41 Mai mult decât software Sebastian Botiș

45 Sun Tzu ‘Arta Războiului’ și era informațională Liviu Ştefăniţă Baiu

41 Atlassian JIRA REST API Dănuț Chindriș

48 În căutarea engagement-ului în industria software Victor Gavronski

50 Serviciile de reţea din Microsoft Azure Radu Vunvulea

editorial

L

Ovidiu Măţan

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

a finalul anului 2014, doresc să mulțumesc cititorilor noștri pentru că au fost alături de noi online, dar și la evenimentele de lansare ale revistei și la cele ale partenerilor noștri. 2014 a însemnat enorm din punct de vedere al maturității revistei: am înregistrat un număr tot mai mare la evenimentele de lansar, iar online, pentru versiunile în română și engleză avem o medie de 7000 cititori pe lună, în perioada IT Days depășind 10000 de cititori. Acest an a contat mult și prin întâlnirile cu cititorii revistei în evenimentele speciale de lansare din București, Timișoara, Brașov, Iași și Târgu Mureș. Un proiect important a fost realizarea noii identități vizuale a website-ului nostru www.todaysoftmag.ro, respectiv www.todaysoftmag.com. În 2015 vom continua această dezvoltare prin lansarea unei pagini de joburi pentru companii și comunitate, având un suport special pentru startup-urile ce doresc să își găsească găsească colaboratori.

Societatea românească din zona IT-ului a evoluat mult în ultimul an, avem aproape toate ingredientele pentru ecosistemul ce va produce următoarea generație de produse software și de ce nu, hardware. Vă dorim succes și vă asigurăm că veți găsi în Today Software Magazine un partener și un promotor de încredere. Începem acest număr cu un articol despre antreprenoriat la final de an, după care continuăm cu MyDog, cel de-al doilea articol din seria de dosare dedicate startupurilor. Publicăm și două articole interesante, primul cu Tudor Gârba despre metrici și evaluarea sistemelor software iar cel de-al doilea interviu este cu consultantul Michael Bolton despre testarea și nu numai. Începem seria de articole tehnice cu Testarea de performanță de la Waterfall la Agile și Riscurile operării cu branch-uri, după care continuăm cu sistemele embedded. Web design-ul este bine reprezentat în acest număr printr-o serie de articole pe această temă: Salveaza timpul utilizatorului cu o interfață bine proiectată, De la Design la Development și A fi sau a nu fi responsive. Pentru că ne apropiem de crăciun, vă propunem revizuirea celor mai importante JPE-uri (JDK Enhacement Proposal) în Promisiunile JDK 9: O scrisoare pentru Moș Crăciun?! Lista poate continua și vă invităm să le citiți cu plăcere!!

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

Ovidiu Măţan

Fondator al Today Software Magazine

4

nr. 30/2014 | www.todaysoftmag.ro

Redacţia Today Software Magazine Fondator / Editor in chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com

Lista autorilor Liviu Ştefăniţă Baiu

Claudiu Gorcan

Senior Business Consultant @ Endava

Senior Delivery Service Engineer @ Betfair

Alexandra Casapu

Irina Scarlat

Software Tester @ Altom Consulting

PR Manager @ How to Web & TechHub Bucharest

Anghel Conțiu

Olimpiu Pop

Design Lead @ Endava

Senior Software Developer @ Ullink

Vlad Derdericea

Sebastian Botiș

Lead Graphic Designer @ Subsign

Delivery Manager @ Endava

Andrei Kelemen

Axente Paul

Director executiv @ IT Cluster

Senior UX Engineer @ 3Pillar Global

Radu Vunvulea

Dănuț Chindriș

Senior Software Engineer @iQuest

Java Developer @ Elektrobit Automotive

Victor Gavronski

Radu Popovici

Managing Director @ Loopaa

Associate @ Gemini Solutions Foundry

Raul Rene Lepsa

Mircea Pătraș-Ciceu

liviu.baiu@endava.com

Claudiu.Gorgan@betfair.com

Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com Copyright/Corector: Emilia Toma emilia.toma@todaysoftmag.com Traducător: Roxana Elena roxana.elena@todaysoftmag.com Editor startups: Mircea Vădan mircea.vadan@todaysoftmag.com

alexandra.casapu@altom.ro

Anghel.Contiu@endava.com

irina.scarlat@howtoweb.co

olimpiu.pop@ullink.com

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

office@subsign.co

Sebastian.Botis@endava.com

Contabil : Delia Coman delia.coman@todaysoftmag.com Produs de

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

ISSN 2284 – 6352

andrei.kelemen@clujit.ro

Radu.Vunvulea@iquestgroup.com

victor.gavronschi@loopaa.ro

raul.lepsa@3pillarglobal.com UI Developer @ SF AppWorks

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

paul.axente@3pillarglobal.com

danut.chindris@elektrobit.com

radu.popovici@geminisols.com

mircea.patras@arobs.com C++ Developer @ AROBS

Sergiu Indrie

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

www.todaysoftmag.ro www.todaysoftmag.com

www.todaysoftmag.ro | nr. 30/decembrie, 2014

5

interviu

IT Days - imaginea IT-ului clujean

A

Ovidiu Măţan

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

6

nr. 30/2014 | www.todaysoftmag.ro

m încheiat de curând cea de-a doua ediție a Cluj IT Days, evenimentul anual al revistei Today Software Magazine. Credem că am reușit să le oferim celor peste 200 de participanți prezenți anul acesta , ocazia de a-și face o imagine de ansamblu mai clară asupra IT-ului clujean și asupra ultimelor trenduri din industria locală. O noutate în cadrul evenimentului a fost publicarea cărții Cum să construiești un produs? semnată de nouăsprezece autori care au participat și în calitate de prezentatori la eveniment. Aceasta va fi de altfel disponibilă online pe site-ul revistei și cel al evenimentului.

Evenimentul a debutat cu o sesi- Lawrey, specialistul de top, invitat speune de prezentări dedicate direcțiilor de cial al acestei ediții a vorbit în prima sa evoluție și leadership-ului din planul local. prezentare din cadrul conferinței despre Tendințele companiilor locale precum modalitățile în care putem îmbunătăți Arobs, Accesa sau Pitech+Plus care au performanța aplicațiilor Java, un subiect fost expuse chiar de fondatorii/CEO ai de mare interes în rândul comunității acestora au în comun același principiu: locale. Vom încerca de altfel să păstrăm orientarea către dezvoltarea de produse legătura cu el în viitor prin publicarea de proprii în paralel cu menținerea calității în articole.

Prezentările au continuat cu subiecte serviciile de outsourcing. Acest lucru este binevenit și sperăm ca la următoarele ediții ce au variat de la arhitectură și big data la să vorbim despre noile produse IT clujene. soluții enterprise. S-a realizat inclusiv o Tot în această primă sesiune, participanții abordare transdisciplinară care stabilește au avut ocazia să descopere lucruri intere- corelații între evoluția conceptului de user sante precum sistemul de operare Firefox experience și istoria filozofiei. Aproape de OS, proiectele ce se desfășoară la ICT Lab final s-a discutat despre oportunitatea de a Budapesta și creșterea prezenței femeilor dezvolta aplicații culturale precum Statui de Daci. Am încheiat seara în jurul unui în lumea IT-ului.

Sesiunile tehnice din cea de-a doua pahar de vin și a unei prăjituri. Pentru că parte a primei zile au făcut încet tranziția vorbim de un eveniment IT, participanții la subiectele mai specializate. S-a vorbit au avut ocazia să își aleagă prăjitura predespre inovație, impactul diferențelor ferată online cu o zi înainte. Acestea i-au culturale, ajungând la limbajul Java. Peter așteptat cu numele fiecăruia notat pe ele

TODAY SOFTWARE MAGAZINE

împreună cu un mic cadou din partea celor de la HipMenu.

Atmosfera la standurile sponsorilor evenimentului a fost una destinsă. Cei de la Accesa au pregătit o cafea specială celor care își alegeau una din valorile de dezvoltare personală din cadrul companiei. Cei de la Yardi au oferit un premiu surpriză în urma unei tombole și anume un GoPro. Vizitatorii standului Accenture aveau ocazia să încerce aplicațiile dezvoltate de companie pentru Google Glasses, să primească mici cadouri și să descopere Industry 4.0. Binecunoscuta ruletă cu premii de la ISDC a fost și ea prezentă în standul lor, iar cei de la 3Pillar Global au fost prezenți cu veselie și voie bună.

A doua zi s-a deschis cu prezentarea keynote a lui Peter Lawrey despre avantajele și dezavantajele de a fi consultant software. Următoarele subiecte au fost startup-urile din perspectiva ecosistemului și ceea ce este bine de știut dacă se dorește obținerea unei finanțări. După prima pauză, am învățat cum se realizează un obiect la o imprimantă 3D. De asemenea, au putut fi văzute și examinate diferite obiecte realizate de către aceasta.

În continuare s-a discutat despre posibilitatea implicării companiilor software în startup-uri, precum și despre tendințele de dezvoltare Industry 4.0. Un alt subiect a demonstrat de ce nu este suficientă doar o idee pentru un startup de succes.

După prânz, am făcut cunoștință cu prezentările despre proiectele de cercetare dezvoltate de Universitatea Tehnică Cluj. Am văzut proiecte de cercetare ce au ca rezultat o mai bună interconectare a rețelelor urmate de un impresionant demo de procesare vocală. Practic după o procesare de aproximativ trei ore de înregistrări a vocii unei persoane, se poate simula un text to speech foarte autentic. Am încheiat seria de proiecte de cercetare cu o sinteză a platformelor de e-learning și contribuția la proiectele românești din acest domeniu.

Pauza de pizza din cea de-a doua zi a relaxat atmosfera și a pregătit audiența pentru ultima parte a prezentărilor tehnice. Primele două au avut ca subiect principal securitatea, fiind urmate de o discuție despre strategiile de testare realizate de marile companii precum Facebook. În încheierea celei de-a doua zile am discutat despre designul unui startup prin

prisma tehnologiilor Microsoft.

Gazda excepțională a acestui eveniment a fost Dan Suciu, lector la Universitatea Babeș-Bolyai și Director of Technical Training la 3Pillar Global. Deși introducerea fiecărei prezentări pe durata celor două zile a putut reprezenta o provocare reală, acesta și-a îndeplinit misiunea cu succes.

Mulțumim companiilor care ne-au susținut: ISDC, Accesa, Gemini Solutions, 3Pillar Global, Yardi, Accenture, Colors in projects, Mozaic Works, Telenav, Endava, Yonder, Betfair, SDL și Fortech. Mulțumim partenerilor care ne-au ajutat în promovarea evenimentului: Cluj IT Cluster, Starcelerate, ClujHub, JCI Cluj și Loopa.

Opiniile și feedback-ul vostru sunt importante pentru noi, oferindu-ne sugestii care să transforme evenimentul din 2015 într-unul și mai interesant și cu invitați valoroși.

www.todaysoftmag.ro | nr. 30/decembrie, 2014

7

antreprenoriat

P

Despre antreprenoriat, la final de an

rin amabilitatea lui Ovidiu (Mățan, desigur), am fost invitat să susțin o prezentare cu ocazia IT DAYS 2014. Cum nu am reușit să mă încadrez în timpul alocat prezentării, redactarea acestui articol îmi oferă ocazia de a completa prezentarea. Iată ce am vrut să spun neapărat !

Antreprenoriatul nu mai poate astăzi face abstracție de tehnologie, indiferent de domeniu. Ne putem imagina orice activitate economică doriți și, fără prea mult efort, vom putea atașa o funcție tehnologică care să deservească acea activitate.

Mai mult decât atât, tehnologia a devenit pe parcursul timpului un element diferențiator, care poate asigura avantajul competitiv necesar succesului. Astăzi se înregistrează o accelerare fără precedent a ritmului progresului socio-economic.

Majoritatea lumii își închipuie că progresul va continua să fie unul liniar, dar nu mai este așa. Progresul tehnologic sau cel favorizat de tehnologie este acum unul exponențial. Pentru ilustrare am ales un singur exemplu, dar concludent pentru impactul său asupra tuturor: proiectul descifrării genomului uman a durat 20 de ani, în primii 15 ani ai proiectului a fost descifrată o mică parte a genomului (sub o treime), progresele cele mai mari s-au făcut în ultimii cinci ani doar datorită avansului tehnologic. Ceea ce părea un eșec, a devenit un succes. Prezența tehnologiei nu garantează acest succes, însă pare să devină un ingredient de tipul “sarea din bucate” (dacă știți povestea). Dacă tot vorbim de “bucate”, există o rețetă infailibilă care ne garantează succesul în rândul mesenilor? Cu alte cuvinte putem urma o strategie anume pe care aplicând-o pas cu pas să ajungem la satisfacția dorită a clienților?

Un răspuns evident este că nu, altfel am fi toți milionari și am lansa produse și/ sau servicii în conferințe transmise peste tot în lume. După care am lansa fundații care să îi sprijine pe cei care nu au aplicat “rețeta”. Și atunci? Nu vă voi răspunde direct la întrebare ci voi lansa cel puțin altele două. Iată-le:

Care sunt celelalte ingrediente personale de care are nevoie un antreprenor (de succes)? Dar cele societale?

În rândurile următoare voi încerca să răspund acestor întrebări.

Spiritul antreprenorial este cel care ne îndeamnă să demarăm activități pe cont propriu, din care să producem profit, adică

8

beneficii personale și, eventual, de grup.

Antreprenoriatul, adică efectul nemijlocit al spiritului antreprenorial, este perceput de foarte mulți ca principalul factor de progres al lumii, iar businessul – sângele din organismul global care a continuat să “circule” chiar și în perioadele de conflicte mondiale grave. Există destule exemple în care inamicii (ideologici sau chiar în conflict armat) au continuat relațiile de business. Am ales doar două pentru că sunt cât se poate de ilustrative: • SUA și Germania, în timpul celui de-al doilea război mondial (un exemplu celebru este Ford, cu fabrica din Germania care, la un moment dat, folosea ca forța de muncă prizonieri de război francezi!)

• Germania și URSS (Rusia) în timpul războiului rece (URSS a furnizat continuu gaz Republicii Federale Germania; RFG a construit și întreținut instalațiile majore de exploatare a gazului rusesc).

RFG nu a suferit niciodată de frig, Republica Democrată Germană, în teorie un aliat ideologic al URSS, în schimb, da!

Asumarea riscului este o caracteristică personală esențială, fără de care antreprenoriatul nu este posibil. Felul în care conștientizăm riscul determină cursul acțiunilor noastre. Ne afectează viața personală, viața profesională și interacțiunea cu societatea în general. În esență felul în care înțelegem să ne asumăm un risc este o caracteristică personală, dat care poate fi, desigur, și educația. Totuși, existența ei nu ne garantează reușita în business.

Ce este de fapt spiritul antreprenorial?

Este același lucru cu cultura antreprenorială? Să pornim mai întâi cu etimologia cuvântului antreprenor. Cuvântul este de origine franceză și a desemnat o persoană aflată între două locuri de muncă, deci un șomer! Interesant cum un cuvânt care se referea la o persoană fără loc de munca a ajuns să însemne, în ziua de azi, o persoană care oferă locuri de muncă… Spiritul antreprenorial este definit în literatura de specialitate ca fiind însumarea, în proporții

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

ce pot diferi, a unor caracteristici individuale dintre care nu vor lipsi: • Asumarea riscului, pe care deja am menționat-o • Unicitatea, care nu este totuna cu • Creativitatea, • Adaptabilitatea, • C u n o a ș t e r e a d o m e n i u l u i d e business, • Dorința de exploatare a potențialului existent și • Autodistrugerea – adică, de cele mai multe ori, dacă businessul inițiat nu este trecut în responsabilitatea altora (pe direcții de management, creștere etc.), creatorul lui, din dorința puternică de a se angaja într-o nouă creație va distruge ceea ce există.

Cultura antreprenorială este un ansamblu de caracteristici societale tangibile și intangibile care favorizează manifestarea, altfel spus concretizarea spiritului antreprenorial. În ceea ce privește caracteristicile tangibile sau fizice lucrurile sunt destul de simple – adică vorbim aici despre infrastructura în special, care poate consta în căi de acces, utilități, teren etc.. Cele intangibile sunt reprezentate istoric de: • cadru legal, • educație / pregătire, • mentalitate individuală și de societate, cu accent pe două componente - acceptanța a eșecului și încredere. În continuare, vom inventaria aceste caracteristici tangibile și intangibile.

Operația de inventariere va debuta cu acele caracteristici pe care NU le avem, pentru a încheia cu acelea pe care le AVEM, rămânând în zona pozitivă a lucrurilor: • Nu există o politică națională privind educația antreprenorială, adică nu există programe sistematice, de amploare și pe termen lung, cu rezultate, care să încurajeze inițiativa privată.

• Nu avem istorie și nici istoric favorabile (câte companii de succes românești cunoașteți și care să aibă un trecut îndelungat în spate?)

• Nu acceptăm eșecul ca pe ceva firesc,

TODAY SOFTWARE MAGAZINE denumit acest fenomen “co-petiție”. Clusterele, conform definițiilor cu care s-a obținut premiul Nobel pentru economie acum 20 de ani (vezi prof. dr. Michael Porter precum și foarte interesanta politică federală a SUA de susținere a clusterizării

Young spirit Mature organization A shared vision Join our journey!

www.clustermapping. us), au funcție de

www.fortech.ro

ca pe o etapă de învățare; eșecul este blamat puternic de membrii familiei, de prieteni și de societate în general.

• Nu avem tradiția mentoratului, adică oamenii care au reușit în afaceri nu sunt preocupați să lase în urmă mai mult decât niște acumulări materiale; acest lucru se explică poate și prin faptul că cei care au reușit nu au aplicat întotdeauna metodele cele mai curate de a face business și doresc ca acest lucru să rămână necunoscut.

• Nu avem obișnuința asocierii, a parteneriatului.

• Nu avem capacitatea de introduce inovație / creativitate în ceea ce facem, deși spunem despre noi ca suntem “inventivi”. și am să vă dau un exemplu banal, din aceeași sferă culinară cu care am început acest articol. Să luăm câteva ingrediente: faină, brânză, busuioc, roșii.

Toate prezente și în culturile agricole și fermele strămoșilor noștri. Dar cine a inventat cel mai răspândit fel de mâncare din lume, pizza? Răspunsul îl știți și dvs. și lista poate continua, cu siguranță.

Totuși ce AVEM? Un răspuns posibil ar fi următorul: • Economie emergentă care înseamnă foarte multe oportunități.

• Un corp în creștere a celor care doresc să înceapă o afacere pe cont propriu, dar totuși încă departe de cele mai performante economii (locul 42 în lume și 25 în Europa, conform Global Entrepreneuship Index).

• O legătură nemijlocită cu medii de informare internaționale și expunere la culturi antreprenoriale cu tradiție, iar aici IT-ul clujean este într-o poziție foarte bună.

• O populație tânără (medie de vârstă mai scăzută decât în majoritatea țărilor europene) care asimilează, îmbrățișează repede cele mai noi tehnologii sau

inovațiile. Am auzit, în contextul alegerilor prezidențiale recente, de “partidul facebook”!

Trebuie să convenim că inițiativa / spiritul antreprenorial nu mai este suficient.

A fost poate în urmă cu 20 de ani. În ziua de azi, este necesar un grad de sofisticare care înseamnă: • studiu de piață, • cunoașterea domeniului (cu cât gradul de sofisticare a businessului este mai mare cu atât cunoașterea trebuie să fie mai aprofundată), • crearea/ educarea cererii prin strategii de marketing potrivite cu profilul consumatorului / clientului. Aceasta înseamnă cunoașterea acestuia – aici intervin cunoștințe din alte domenii decât cel al businessului cum ar fi sociologie, psihologie.

• muncă, dedicație, • mediu concurențial (concurența e bună!).

• capital (de preferință al altora, nu pentru că e bine să cheltuiești banii altora ci pentru că așa dovedești că și alții au încredere în ceea ce faci tu).

Dar este importantă prezența unui mediu în care afacerea noastră să se dezvolte firesc. Acest mediu este în fapt cultura antreprenorială.

susținere a dezvoltării ecosistemului. Dintre avantajele dezvoltării ecosistemului amintesc: • posibilitatea introducerii unor elemente noi, inovatoare și de reimpulsionare constantă a creșterii economice; • creșterea competiției care duce la creșterea competitivității; • propagarea bunăstării prin răspândirea unui model / unor modele de business de succes.

Este nevoie de ecosisteme inovative, adică de acele ecosisteme în care există capacitate antreprenorială, dar și capacitate socială (capacitatea de a genera inovație și de a asimila efectele ei). Iar Clujul este foarte bine poziționat din acest punct de vedere pentru domenii de business tehnologice deoarece: • există o populație tânără, cu capacitate mare de absorbție / adopție; • există universități bine cotate la nivel național, dar și internațional care atrag talente; • Ex. UMF – peste 1000 de studenți din Franța, iar trendul este în creștere, inclusiv pentru alte universități (chiar și USAMV începe să aibă studenți străini); • există o masă critică în formare care dorește un alt fel de dezvoltare, una bazată pe competiție reală, dar, în același timp, cu dorința de creștere socială pe scară.

Cu alte cuvinte există premise bune pentru ca noi și generațiile următoare să creeze istoricul antreprenoriatului românesc.

Cum se poate accelera formarea sau consolidarea culturii antreprenoriale? O parte a răspunsului îl reprezintă clusterele sau polii de competitivitate (pole de comLa mulți ani și un an antreprenorial cât petitivite) pentru gurmanzii / francofonii mai bun tuturor care își doresc acest lucru! dintre voi. Clusterele sunt structuri pe lanț de valoare a unei industrii, cu funcție economică și realizează o aliniere strategică Andrei Kelemen andrei.kelemen@clujit.ro pe zone de interes comun. Acest lucru este posibil deoarece, de la un anumit nivel în Director executiv @ IT Cluster sus, competiția între companii (mai ales IMM-uri) nu mai există. Economiștii au www.todaysoftmag.ro | nr. 30/decembrie, 2014

9

startups

Dosare de startup MyDog

Î

n apartamentul în care am crescut nu am avut animale de companie, deși atât eu cât și sora mea îi mai rugam din când în când pe părinți să luăm un cățel sau o pisică. Lucrul ăsta a făcut să aștept cu o mai mare nerăbdare verile petrecute la bunica mea. Și era ca și știut: când începea vacanța de vară atât eu cât și sora mea plecam de pe capul părinților și ne mutam la bunici. Acolo ni se alăturau peste zi și verișorii și distracția era garantată.

Coca (un nume de alint atribuit bunicii de către sora mea) locuia într-o casă cu ogradă prin care alergau, mereu veseli, cel puțin doi - trei căței. E de prisos să spun că aceștia nu aveau mereu un traseu bine stabilit și culcau deseori la pământ florile îngrijite zilnic de către dânsa. Astfel, cât era ziua de lungă, curtea era plină de o ceată de copii care alergau încolo și-ncoace însoțiți la fiecare pas de prietenii lor patrupezi.

Revenind în zilele noastre: de curând ne-am hotărât să adoptăm un câine. Și dacă, privind în urmă, cea mai mare grijă de atunci era o zi cu ploaie pentru că trebuia să mutăm tabăra între patru pereți, acum privesc cu alți ochi acest aspect și înțeleg faptul că adoptarea unui câine vine și cu o serie de responsabilități pe care nu le putem neglija. Mă refer aici la latura medicală (vaccinări si consultații periodice), îngrijirea periodică (tăiatul gheruțelor, tuns, spălat), dresaj, hrană și multe alte aspecte ce țin de bunăstarea animalului de companie. Așa că am început să mă documentez și să citesc din experiențele altora despre diversele trăsături ale raselor canine. Redau mai jos câteva lucruri pe care le-am găsit relevante înainte de adopție:

• Care rase se pretează mai bine la apartament în raport cu cei care au nevoie neapărată de spațiu mare de alergare.

• Care rase sunt mai ușor de dresat față de acei căței rebeli ce nu vor să te asculte cu nici un preț.

• La ce boli sunt predispuși.

• Cam la ce investiție financiară recurentă ar trebui să mă aștept. Și internetul este plin de astfel de detalii atunci când știi ce vrei să cauți, însă informația este foarte disipată între n site-uri / domenii / forumuri. În plus, am început să discut cu diverse persoane ce și-au întregit familia cu un câine și am aflat detalii foarte generale; însă cercul meu de prieteni și cunoștințe m-a putut ajuta numai până la un pas. Mi-ar fi plăcut să pot discuta cu cineva care are rasa de câine care mi-a plăcut și îmi place în continuare (Labrador). Iar abordarea pe stradă nu mi se pare cea mai bună soluție în această direcție. O soluție de genul MyDog m-ar fi ajutat foarte mult la momentul respectiv, deoarece sunt de părere că și acest pas - de documentare - este foarte important. Altfel ajungem în situații (pe care încă le întâlnim destul de frecvent din păcate) în care

posesorul își dă seama că s-a înhămat la mai mult decât poate duce și preferă găsirea altui stăpân sau, mai rău, abandonarea cățelului. Și, după cum menționam anterior, responsabilitățile abia acum încep. Acestea variază de la sănătate, la îngrijire periodică, până la educație și bunăstare. Câți dintre voi știu ce cabinete veterinare aveți în vecinătate? Sau ce servicii oferă? Pe câte forumuri trebuie să intrați până găsiți un thread de actualitate despre comparații între mâncărurile pentru câini (Aceasta, dacă nu ați discutat deja cu medicul veterinar pentru o recomandare)? Las întrebări deschise și pentru restul subiectelor dezbătute.

Un ultim aspect asupra căruia doresc să atrag atenția este cel de socializare.

Asemenea noastră, cel-mai-bun-prietenal-omului are și el nevoie să socializeze cu alți căței, iar acest lucru încă de la o vârstă fragedă pentru a nu deveni agresivi sau fricoși când se întâlnesc cu alți câini. În acest caz socializarea se întâmplă doar în mediul real, fie cunoscând prieteni noi în parc, sau reîntâlnind câini ce însoțesc prietenii stăpânului, cu care acesta alege să își petreacă plimbările de dimineața și seara. Nu putem discuta (încă) de o soluție IT dedicată exclusiv cățeilor. Însă o soluție ce se adresează posesorilor este o cu totul altă discuție.

Cu un astfel de concept ni se alătură astăzi Dan Damian, fondatorul MyDog1.

Acesta nu este primul proiect antreprenorial al lui Dan. El a fondat acum șase ani CodeSphere2 alături de alți doi asociați.

1 http://www.mydog.xyz/ 2 http://www.codesphere.ro/

10

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE a produsului?

[Dan] Așa este, numărul de utilizatori este doar unul din indicatori, însă foarte important este și procentul de utilizatori noi versus utilizatori vechi ce revin. De asemenea este foarte importantă durata medie a unei sesiuni sau bounce rate-ul.

Acești indicatori arată cât de atras este utilizatorul de platforma după ce își face cont, cât de des revine și cât timp petrece aici. Până la urmă aceasta contează cel mai mult. Ok, convingi pe cineva de ideea ta, ajunge să își facă cont, dar ulterior dacă nu oferi cu adevărat valoare adăugată el va înceta să revină.

CodeSphere este un furnizor de serviAi utilizat o extensie destul de cii software ce a crescut foarte frumos în tot acest timp. Acum însă Dan dorește să neobișnuită pentru domeniu. De ce .xyz?

[Dan] Am pornit în căutări având schimbe un pic traiectoria și să se concentreze asupra zonei de generare de numele aplicației bine fixat - mydog, și mi-a rămas să variez doar extensia. Evident proprietate intelectuală. că .com era cumpărat și la fel multe alte [Radu] Ce înseamnă, de fapt, MyDog? extensii uzuale. Am descoperit în cele din [Dan] myDog este o rețea de sociali- urmă noua extensie .xyz. M-a lovit noul, zare dedicată proprietarilor și iubitorilor de ciudățenia și nonconformismul cu care câini. Pe myDog te poți înregistra cu câi- venea. Mi-am dat seama că va fi ușor de nele tău în câteva secunde, ai la dispoziție reținut și că va prezenta un avantaj major o pagină de profil unde te poți lăuda cu de branding, așa că iată mydog.xyz. pozele prietenului tău, poți posta cele mai Înainte de lansare ai prezentat prointeresante momente, ai un wall unde vezi ce postează și prietenii tăi și nu în ultimul iectul la a treia ediție a Conferințelor rând poți căuta alți câini după rasă, sex, Foundry. Cum a fost?

[Dan] A fost o experiență foarte utilă. vârstă și locație. myDog s-a lansat în România pe 15 Dialogul cu voi ne-a forțat să ne punem la nov, iar până acum am strâns peste 1500 punct aspecte strategice legate de publicul de membri, dovedind că nevoia este una țintă, de strategia de lansare, de cum vom monetiza tot acest efort. cât se poate de reală.

De asemenea, ne-a ajutat foarte mult și introducerea voastră în emisiunea lui Cum a pornit această idee?

[Dan] Eu am un Amstaff de aproape Georghe Buhnici, de la Pro Tv - I Like 4 ani și deseori m-am gândit să îi găsesc IT. Desigur totul a culminat cu pitch-ul o iubită. În plus, mi-am dorit să pot “da susținut în fața unui investitor, ocazie check-in” într-un țarc sau să văd cine este cu care am putut să observăm ce este cu deja acolo pentru a putea să evit țarcurile adevărat important și din punctul lor de atunci când erau prea aglomerate. Mi-am vedere. dorit de asemenea să am acces la o listă Cum a fost primită de comunitate cu cele mai apropiate clinici veterinare, să am unde să caut un dresor. Și...dacă mă aceasta platformă?

[Dan] Putem afirma cu mândrie că gândesc bine, înainte să-l am pe Sawyer oscilam între două rase: Shar-Pei și feedback-ul este unul foarte pozitiv. Avem American Staffordshire Terrier (Amstaff), peste 1500 de înregistrări până acum și și mi-ar fi prins bine să am pe cine să sperăm să ajungem la 2000 de utilizatori în întreb, să pot vorbi cu cineva care are de prima luna de la lansare. Dacă se întâmplă ceva timp ambele rase și să aflu direct care asta, ne vom alinia cu proiecțiile noastre de sunt avantajele și dezavantajele fiecăreia. înainte de lansare.

Am căutat un site sau o aplicație mobilă Multă lume se oprește la numărul de care să mă ajute în toate aceste privințe însă n-am găsit ceva satisfăcător. După trei utilizatori când vine vorba de indicatori. luni de validări și cercetări de piață ne-am Ce alte metrici sunt importante pentru tine în determinarea traiectoriei viitoare decis să începem dezvoltarea.

Ce urmează?

[Dan] Noi pivotări (conform conceptelor de Lean Startup, promovate de, deja celebrul, Eric Ries). Am pivotat deja odată, atunci când am decis să nu lansăm cu toate cele tre funcționalități planificate (Socializare, Țarcuri și Clinici) ci doar una și anume modulul de Socializare. Și am făcut foarte bine, pentru că nu am fi avut timpul necesar și am fi amânat lansarea și în același timp nu ne-am fi putut concentra pe feedback-ul utilizatorilor noștri.

La o lună de la lansarea fazei beta, putem spune că am fixat o mulțime de bug-uri minore, am adăugat exact funcționalitățile de care era cu adevărat nevoie și știm în ce direcție să mergem mai departe. În ianuarie 2015 vom lansa secțiunea “Dog Services” (deci nu doar Clinici) unde se vor putea înscrie toți furnizorii de servicii dedicate câinilor: clinici veterinare, saloane cosmetice canine, hoteluri canine, canise, dresori și chiar persoane care se oferă să îți plimbe câinele sau să ți-l țină peste week-end.

Odată cu venirea primăverii vom lansa și modulul Țarcuri, alături -sperăm noi- și de versiunea pentru mobil a aplicației.

Radu Popovici

radu.popovici@geminisols.com Associate @ Gemini Solutions Foundry

www.todaysoftmag.ro | nr. 30/decembrie, 2014

11

startups

Startupul Axosuits a câștigat How to Web Startup Spotlight 2014

B

ucureşti, 24 Noiembrie 2014 – Axosuits, echipă care dezvoltă exoscheleţi uşor de folosit şi accesibili ca preţ pentru persoanele cu dizabilităţi, este marele câştigător al How to Web Startup Spotlight, cea mai importantă competiţie şi program de mentorat pentru startup-urile din Europa Centrală şi de Est. Locul al doilea a fost ocupat de Avandor, în timp ce IXIA Innovation Award a fost câştigat de ProjectWipe. Cea mai bună prezentare a fost susţinută de echipa de la Lat.io. Câştigătorii competiţiei au fost anunţaţi recent pe scena principală a How to Web Conference 2014, cel mai important eveniment dedicat inovaţiei şi tehnologiei din regiune care s-a desfăşurat la Bucureşti pe 20 şi 21 noiembrie.

Cea de- a treia ediţie Startup Spotlight a avut loc în paralel cu How to Web Conference 2014 şi a adus împreună 31 de echipe care dezvoltă produse tech cu potenţial disruptiv la nivel global din 10 ţări din regiune. Pe parcursul programului, acestea au avut ocazia să întâlnească mentori şi profesionişti cu experienţă şi să discute în mod direct cu reprezentanţi ai programelor de accelerare şi fondurilor de investiţii early stage la nivel global.

Programul a debutat cu prezentarea echipelor selecţionate în concurs, iar la final juriul a anunţat cele 8 echipe finaliste ale competiţiei care au intrat astfel în cursa pentru câştigarea premiului pentru cel mai bun startup. Acestea sunt: Marketizator (platformă 3 în 1 pentru optimizarea ratei de conversie pe siteurile de ecommerce); ProjectWipe (ochelari electronici care ajută persoanele cu dizabilităţi de vedere să se orienteze şi să evite obstacolele), Attensee (statistici online de eye-tracking pentru optimizarea conversiei pe site-urile web), Fittter (aplicaţie mobilă şi web în domeniul sănătăţii şi fitnessului care conectează călătorii de business cu antrenorii şi îi ajută să îşi menţină obiceiurile

12

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

sănătoase de viaţă pe durata deplasărilor), Avandor (platformă deschisă de date ale consumatorilor disponibilă ca Software-asa-Service întregului ecosistem format din site-uri web, agenţii, companii de ecommerce sau publicitate), CloudPress (platformă prin care designerii pot crea site-uri Wordpress receptibile în manieră vizuală şi le pot publica la final printr-un singur click), Axosuits (exoscheleţi uşor de folosit şi accesibili ca preţ pentru persoanele cu dizabilităţi) şi ViewFlux (platformă de colaborare online pentru designeri care îi ajută să îşi îmbunătăţească procesul de lucru). În cea de-a doua parte a zilei, echipele participante în concurs au avut întâlniri 1 la 1 cu profesionişti de excepţie de pe scena globală şi au participat la paneluri şi sesiuni de discuţii care au avut loc la TechHub Bucharest. Toate startup-urile participante la How to Web Startup Spotlight au avut anul acesta oportunitatea de a-şi prezenta produsele pe scena principală a How to Web Conference în faţa întregii audienţe şi au beneficiat de sesiuni de mentorat 1 la 1 cu unii dintre cei mai apreciaţi profesionişti ai

TODAY SOFTWARE MAGAZINE industriei la nivel global.

Bogdan Iordache (Investitor 3TS Capital Partners şi fondator How to Web), Robert Knapp (Fondator & CEO Cyberghost), Adrian Gheară (investitor de tip angel), Bogdan Ripa (Master Product Owner Adobe Romania), Bogdan Ţenea (IXIA Innovation & Entrepreneurship Appointee), Sitar Teli (Managing Partner Connect Ventures) şi Cosmin Ochişor (Business Development Manager hub:raum) au făcut parte din juriul care a desemnat câştigătorii How to Web Startup Spotlight luând în considerare experienţa echipei, dimensiunea pieţei şi tendinţele actuale, validarea utilizatorilor, creşterea iniţială, costul de achiziţie al utilizatorilor, scalabilitatea şi fezabilitatea afacerii.

Marele câştigător al How to Web Startup Spotlight 2014 este Axo Suits, dezvoltatorii unui exoschelet accesibil ca preţ şi uşor de folosit pentru persoanele cu dizabilităţi. Avandor, platformă deschisă de date ale consumatorilor disponibilă ca Software-asa-Service întregului ecosistem format din site-uri web, agenţii, companii de ecommerce sau publicitate, a ocupat locul al doilea în competiţie. Echipa de la ProjectWipe, care dezvoltă ochelari electronici pentru a ajuta persoanele cu dizabilităţi de vedere să se orienteze şi să evite obstacolele, a primit IXIA Innovation Awards, iar premiul pentru cea mai bună prezentare a fost câştigat de Lat. io, kit de dezvoltare software personalizabil, care permite dezvoltatorilor şi companiilor să integreze tehnologiile iBeacon fără a se pierde în detalii. Echipele câștigătoare au primit premii cash în valoare totală de 20.000 USD oferite de IXIA, partener principal al programului.

How to Web Startup Spotlight s-a încheiat oficial sâmbătă, 22 noiembrie, cu un eveniment social în cadrul căruia participanţii vor avea ocazia să formeze conexiuni valoroase cu personalităţi cheie din industria de tehnologie la nivel global.

Startup Spotlight a avut loc în cadrul How to Web Conference 2014, cel mai important eveniment despre inovaţie, tehnologie şi antreprenoriat din Europa de Sud-Est care a reunit pe 20 şi 21 noiembrie la Bucureşti peste 1000 de reprezentanţi ai comunităţii din întreaga regiune şi mai bine de 70 de invitaţi speciali de pe 4 continente.

Organizat cu sprijinul partenerilor principali Telekom Romania, Bitdefender, IXIA şi Grapefruit şi al partenerilor Avangate, Softlayer, Ambasada Canadei în România, Hub:raum, CyberGhost, Domain.me, TechHub Bucharest, Mobaba şi Reea, How to Web Conference 2014 a marcat un nou început pentru eveniment şi a propus de această dată audienţei un format mai dată alături de noi, tuturor voluntarilor care s-au asigurat că complex, care a abordat în profunzime subiecte specifice, rele- lucrurile se desfăşoară conform planului, echipei How to Web, vante pentru diferite categorii de audienţă. şi, mai mult decât atât, fiecărui participant care a venit aici

Astfel, pe scena principală a evenimentului a avut loc How to Web – Future Trends & Entrepreneurship Track şi a adus în atenţia audienţei subiecte precum „internetul lucrurilor” şi oportunităţile de business create de acesta, evoluţia şi implicaţiile cripto-monedelor, tendinţele viitorului în securitate cibernetică, tehnologii mobile şi industria transporturilor, sau obţinerea de investiţii prin diferite metode de finanţare. „How to Web este mai mult decât o conferinţă. Este o manifestare şi un punct de întâlnire pentru comunitatea tech din regiune şi are loc anual pentru comunitate, dar mai ales cu sprijinul acesteia. Ajunşi la finalul celei de a cincea ediţii internaţionale a evenimentului vreau să le mulţumesc tuturor celor care au făcut şi de această lucrurile să se întâmple: partenerii evenimentului, mentorii şi invitaţii care au fost şi de această

pentru a schimba idei cu alţi profesionişti în tehnologie. Am descoperit în acest an ce ne rezervă viitorul în tehnologie şi continuăm să creştem alături de comunitatea regională, care este astăzi mai puternică şi mai unită decât oricând!”, - Daniel Dragomir, CEO How to Web Conference 2014

Irina Scarlat

irina.scarlat@howtoweb.co PR Manager @ How to Web & TechHub Bucharest

www.todaysoftmag.ro | nr. 30/decembrie, 2014

13

interviu

Metrici în programarea obiectuală Interviu cu Tudor Gîrba

T

udor este cercetător și consultant software. El a devenit recent cunoscut prin câștigarea premiului anual la categoria Junior oferit de către AITO (Association Internationale pour les Technologies Objets), organizație ce promovează cercetarea din aria tehnologiilor orientate pe obiect. El a fost prezent în 13 decembrie la Cluj, la evenimentul Be Fast & Curious ! organizat de către compania 3Pillar Global.

[Ovidiu] Descrie pentru cititorii revistei noastre capabilitățile engine-ul Mondrian care a primit premiul al II-lea la ESUG 2006 Innovation Awards și totodată a contribuit pentru cel oferit de către AITO. [Tudor] Mondrian este o platformă de vizualizare a datelor. Particularitatea lui constă în faptul că s-a numărat printre primele astfel de platforme care a oferit o modalitate de „scriptare” succintă. De exemplu, vizualizarea unei ierarhii de clase arată așa: view nodes: classes. view edgesToAll: #directSubclasses. view treeLayout

Dacă dorim să extindem vizualizarea în așa fel încât fiecare clasă să fie reprezentată de un dreptunghi ale cărui dimensiuni să fie date de metrici de cod, putem scrie: view shape rectangle height: #numberOfMethods; width: #numberOfAttributes. view nodes: classes. view edgesToAll: #directSubclasses. view treeLayout

Mondrian a deschis un nou drum în domeniul vizualizărilor arătând cum se pot exprima succint vizualizări complicate.

Platforma de analiză a software-ului și a datelor Moose a parcurs din 2003 sub îndrumarea ta trecerea de la o platformă academică la una ce poate fi folosită cu ușurință și în mediul comercial. Așa cum este descris în The Moose Book avem un proces bine definit prin module de achiziție a datelor, descriere a modelelor și engine-uri de prelucrare a datelor și tool-uri. Poți să

14

ne dai câteva exemple de folosire a sa în aplicații software sau de analiză a datelor ?

[Tudor] Moose este un proiect opensource larg care a început acum 17 ani în Elveția la Universitatea din Berna. Eu îl conduc de 12 ani, iar în prezent e susținut de mai multe companii și grupuri de cercetare din lume. Scopul platformei Moose este acela de a face cât mai ușoară programarea analizelor. Această abilitate conferă programatorilor posibilitatea de a combina servicii de analiză generice pentru a le adapta la contextul sistemelor.

O clasă mare de astfel de utilizări e dată de „testarea” arhitecturii sistemelor software. De exemplu, întrun sistem client-server JEE poate fi de dorit să nu se folosească @Stateful beans. Un astfel de test ar arăta așa:

(((allTypes select: #isUIType) flatCollect: #clientTypes) select: #isServerType) allSatisfy: [ :type | type isInterface and: [ type directSubclasses anySatisfy: [:class | class isAnnotatedWith: ‚Remote’ ]]]

Aplicațiille Moose nu se limitează doar la astfel de testări, ci la tool-uri de analiză de date care pot avea interacțiuni sofisticate. De exemplu, în poza de mai jos putem vedea o sesiune de analiză formată din patru pași. În primul panou se construiește o vizualizare a claselor, iar vizualizarea e arătată în al doilea panou; selectarea unei clase din această vizualizare duce la deschiderea unui nou panou cu detalii ale clasei. În acest al treilea panou, se mai poate construi o altă vizualizare care arată în partea dreaptă cum sunt utilizate atributele de către metodele clasei curente. Acesta este doar un exemplu care arată cum se pot combina și contextualiza allTypes noneSatisfy: [ :type | type isAnnotatedWith: ‚Stateful’ ] analizele într-un mediu vizual și interactiv.

Acesta a fost un exemplu oarecum Mai multe informații despre Moose pot fi simplu. O regulă puțin mai complicată găsite la: http://moosetechnology.org ar putea să specifice ca apelurile dinspre Tema pe care ai abordat-o la evenicodul interfeței cu utilizatorul către server să se realizeze doar prin interfețe care mentul Be Fast & Curious! este Humane sunt implementate de @Remote beans. Assessment ce reprezintă o nouă metodă Un „test” în direcția aceasta ar arăta așa: de software engineering cu scopul de

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

a ajuta în luarea deciziilor. Poți să ne descrii în linii mari despre ce este vorba?

[Tudor] Inginerii software petrec mai mult de jumătate din timp evaluând starea curentă a sistemelor pentru a înțelege cum să purceadă mai departe. Cu alte cuvinte, evaluarea sistemelor software (software assessment) e cea mai costisitoare activitate din cadrul dezvoltării software-ului.

Cu toate acestea, nimeni nu vorbește despre această activitate. O consecință a acestui fapt e că inginerii software ajung să consume cea mai mare parte din timpul alocat evaluării citind cod. Din păcate, cititul codului e practic cea mai puțin scalabilă modalitate de a înțelege codul și nu e metoda adecvată pentru înțelegerea sistemelor mari. Ca un exemplu, dacă un om care citește rapid are nevoie de 2 secunde pentru a citi o linie de cod, el ar avea nevoie de aproximativ o lună de lucru pentru a citi 250’000 de linii de cod (dimensiunea unui sistem mediu). Având în vedere faptul că inginerii software au nevoie de a înțelege starea sistemului în fiecare zi, în cele din urmă deciziile se iau pe baza unor impresii parțiale și de multe ori incorecte despre realitate.

Dar lucrurile nu trebuie să stea așa.

Humane Assessment este o metodă care

oferă o abordare sistematică a luării deciziilor și la baza ei stă ideea că adunarea de informații poate fi realizată de către tooluri automate. În același timp, astfel de tool-uri trebuie să fie contextualizate pentru că un sistem are multe detalii specifice.

De aceea e necesar ca inginerii software să poată să construiască astfel de tool-uri in timpul dezvoltării software.

Pentru a face acest lucru practicabil avem nevoie de un nou gen de platforme care să ofere posibilitatea programatorilor de a construi tool-uri contextuale rapid și necostisitor. Aici intervin abilitățile platformei Moose. Prin Moose, noi arătăm că acest lucru este într-adevăr posibil, iar eu susțin că tipul de funcționalități oferite de platformă ar trebui să devină comune în tool-urile de dezvoltare (IDE-uri).

Tool-urile sunt necesare, dar nu sunt suficiente. De aceea, Humane Assessment oferă un ghid atât în ceea ce privește tipurile de abilități pe care inginerii ar trebui să le posede, cât și în ceea ce privește modificarea proceselor de dezvoltare. De exemplu, având în vedere faptul că structura sistemului se modifică permanent, este nevoie să se urmărească și ajusteze zilnic arhitectura sistemului. În acest scop Humane Assessment recomandă o ședință zilnică scurtă care să includă doar ingineri și în cadrul căreia se abordează doar probleme care au fost evidențiate printro analiză automată dezvoltată în înaintea ședinței.

Mai multe informații despre Humane Assessment se pot găsi la: http://humaneassessment.com

oamenilor?

[Tudor] Tehnologia va avea un rol din ce în ce mai pregnant în viața noastră de zi cu zi. Acesta este o direcție evidentă. Mai puțin evident e ceea ce implică acest lucru.

Viteza cu care producem sisteme noi crește pe zi ce trece. Pe de o parte, acesta e un lucru bun. Pe de alta parte, abilitatea noastră de a ne debarasa de sisteme vechi nu a ținut pasul. Să luam un exemplu: un studiu Gartner arată ca în lume mai există în uz circa 10.000 de sisteme de tip mainframe. Acestea sunt sisteme care pot ajunge chiar mai în vârstă decât majoritatea programatorilor din ziua de astăzi. Aceasta ne arată că software-ul nu e chiar atât de “soft” pe cât am putea crede. Odată creat un sistem, el produce consecințe și dependențe inclusiv la nivel economic și social care îi cimentează poziția și îl face aproape imposibil de „aruncat”. Singurele opțiuni rămân „recondiționarea și reciclarea”.

Datorita proporției și impactului industriei software, e nevoie să privim producția de sisteme software ca pe o problemă de importanță și dimensiune ecologică. Orice sistem trebuie să fie construit în așa fel încât în viitor să poată fi ușor de dezasamblat. Aceasta e o responsabilitate pe care noi, ca ingineri ai lumii de mâine, trebuie să ne-o însușim.

Dacă mâine ar trebui să scrii un articol despre software, care ar fi titlul acestuia ?

[Tudor] Software environmentalism.

Ovidiu Măţan

Care este perspectiva ta asupra evoluției tehnologiei peste 10 ani și impactul acesteia în viața de zi cu zi a

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

www.todaysoftmag.ro | nr. 30/decembrie, 2014

15

interviu

Despre testare, descoperiri științifice și revoluții - O discuție cu Michael Bolton

M

ichael Bolton s-a aflat în Cluj-Napoca în perioada 17-20 noiembrie pentru a susține cursurile Rapid Software Testing și Critical Thinking. Înainte de a-și continua călătoria prin lume, echipa Altom l-a oprit pentru un interviu, pentru a afla câteva din perspectivele lui în legătură cu testarea software și educația în testare, legătura între testare și procesul de descoperire științifică, precum și părerea lui despre comunitățile de tester-i și rolul lor în potențiale revoluții în testare.

[RamonaMer] Care sunt temele principale abordate în cursul RST? [Michael] Sunt foarte multe… cel mai important lucru este să descoperim care este esența testării. Ne concentrăm atenția asupra setului de abilități și a modului de gândire al tester-ului ca individ.

Vorbim mult despre euristici - metode non-infailibile de rezolvare a unei probleme. Vorbim mult despre oracole - metode care ne ajută să recunoaștem o problemă. Vorbim și despre test coverage - cum să ne uităm la un program dintro diversitate de perspective, ca demersul nostru să descopere o varietate de probleme relevante.

Acestea sunt cele mai importante lucruri care îmi vin în minte: dezvoltarea setului de abilități și a modului de gândire al tester-ului.

Cum evoluează conținutul cursului?

Crește în continuare?

[Michael] E îngrozitor! În prezent avem material pentru aproximativ șapte zile, iar cursul durează trei zile. De fapt, dacă am vrea să facem toate exercițiile pe care le-am dezvoltat de-a lungul anilor, pe toate temele care ne-ar plăcea să fie acoperite, chiar nu am idee cât de mult ar dura cursul… 2-3 săptămâni? Poate patru?

Un alt proiect care s-a conturat de-a lungul anilor a fost cursul de Rapid Testing for Managers. Iar anul acesta James a lansat un curs de două zile pentru programatori sau pentru oameni care scriu cod (Rapid Software Testing for Programmers - http://www.ministryoftesting.com/ training-events/rapid-software-testingprogrammers/). E foarte interesant!

Majoritatea exercițiilor din acel curs sunt gândite în jurul informației care poate fi obținută prin folosirea programelor și a

scripting-ului. Astfel de aspecte sunt greu de încorporat în cursul obișnuit. Între timp, există o constantă evoluție a materialului, prin căutarea de aspecte din lumea reală pe care le includem în curs. Cea mai presantă problemă pentru moment este să ne dăm seama cum să evidențiem mai mult aspectele legate de cunoașterea explicită și tacită. Pentru moment ele se află în materialul cursului într-un mod implicit, sau tacit, dacă vrei. Aș vrea să rezervăm timpul necesar să discutăm mai mult despre asta și poate să facem câteva exerciții legate de cum se aplică conceptele în testare.

Aș vrea să fac și mai multe exerciții de raportare, să le dăm participanților șansa să încerce ceva și să greșească. Apoi să exerseze de câteva ori, pentru a-și îmbunătăți modul de raportare.

Deci materialul evoluează încontinuu, întotdeauna descoperim ceva nou. De

Objective C

jobs-cluj@yardi.com Yardi Romania

16

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE exemplu, James a început să lucreze cu R în ultima vreme - un limbaj care îți permite să vizualizezi date și să le modelezi în feluri foarte interesante.

Testarea se schimbă, prin urmare cursul se schimbă și asta e un lucru bun.

Cum ai descrie persoana care ar beneficia de cursul de Rapid Software Testing sau cursul Critical thinking? De ce sunt aceste cursuri valoroase și pentru cine?

[Michael] Spunem de multă vreme că RST se potrivește pentru tester-i de orice nivel, pentru că am conceput exercițiile inspirați de munca lui Jerry Weinberg. Și eu și James am fost studenții lui în acest mod informal în care poți fi student al lui Jerry. Am participat la multe dintre workshop-urile lui, la multe dintre cursurile lui, din care am învățat enorm despre cum să structuram cursul.

Jerry este de mult timp un susținător al workshop-urilor experiențiale și odată ne-a dezvăluit unul din secretele lui, despre care vorbește și în cărțile lui, de altfel.

Secretul este că dintr-un exercițiu rezonabil, toți învață ce au nevoie să învețe, indiferent de nivelul lor de cunoștințe sau abilități.

Deci unii oameni vor învăța lucruri de bază din exercițiile noastre, pentru că ei sunt la un nivel de bază. Alți oameni, care sunt mai avansați, poate vor observa altceva, sau vor descoperi ceva în comportamentul oamenilor mai puțin experimentați și vor înțelege cum să îi ghideze. Uneori oamenii înțeleg mai bine cum să observe. Aspectul frumos în abordarea lui Jerry este că depinde de fiecare ce va învăța. Asta e destul de relaxant pentru noi în sensul că deși avem câteva lucruri pe care am vrea ca oamenii să le învețe și despre care vorbim, nu e obligatoriu să învețe exact acele lucruri. Ca o consecință, participanții învață lucruri diferite. Noi îi observăm făcând asta și astfel adunăm subiecte despre care am putea vorbi, pentru că înțelegem mai bine ce au nevoie oamenii să învețe, cu ce rămân din exerciții, ce obțin din experiența oferită.

Așa că ambele cursuri, și RST și Critical Thinking, pot fi folositoare pentru oricine la orice nivel. E un proces cu caracter dual: sunt în jur de 24 de oameni în sală, iar noi nu putem să învățam 24 de persoane diferite în același fel. Așa că e nevoie să le oferim spațiul să învețe. Noi le dăm oamenilor o oportunitate să învețe, în loc să încercam să îi învățam noi ceva anume, mai ales când procesul lor de învățare pare promițător.

Ce sfat ai da cuiva care face testare și ar vrea să găsească pasiune în ceea ce face, dar încă nu a ajuns acolo?

[Michael] Am un răspuns standard pentru această problemă legată de cum insufli pasiune oamenilor: nu cred că e nevoie să faci asta. Testarea implică curiozitate, iar oamenii sunt curioși prin natura lor. Sunt întrebat adesea: “Cum motivezi testerii?”. Răspunsul meu e că nu e nevoie să faci altceva decât să te oprești din a-i demotiva! Asta e o mare problemă în domeniul nostru. O dată ce le iei responsabilitatea oamenilor și îi transformi în executanți pentru munca altor oameni, ei renunță la implicare și își pierd interesul.

Dacă le încredințezi oamenilor o misiune de a descoperi ceva, ei vor merge să descopere acel ceva de unii singuri.

Ce carte ai citit recent și ai recomanda-o unui tester?

[Michael] Acum citesc o carte care se cheamă ”The organized mind” de David Levithan, dar tot întrerup lectura ei. În ultima vreme am citit câteva cărți despre probabilitate, risc și statistică, dar aceste lecturi fac parte din aria mea personală de interes. Însă nu aș putea spune că am avut o revelație recentă în legătură cu o carte, cu excepția anului petrecut citind cărțile lui Harry Collins. Fiecare dintre cărțile lui mi se pare valoroasă. E un scriitor foarte prolific, care abordează o diversitate minunată de teme, pe lângă sociologia științei, care e tema lui centrală.

Aș recomanda testerilor să citească o serie de cărți numită “The Golem” golemul este o creatură din mitologia evreiască, un uriaș neîndemânatic, care se mișcă greoi, iar această metaforă a inspirat eseurile lui Harry Collins, Trevor Pinch

și ale altor colegi de-ai lor incluse în cele două cărți.

Una dintre cărți se numește “The golem and what everyone needs to know about science”, iar cealaltă “The golem at large - what everyone needs to know about technology”. Ambele sunt foarte interesante pentru tester-i, pentru că vorbesc despre natura sinuoasă a descoperirii, despre faptul că descoperirile nu se întâmplă așa cum ni le imaginăm de obicei.

Cărțile includ mici studii de caz și investigații legate de ce s-a întâmplat cu adevărat în studii științifice. De exemplu, experimentul Michaelson-Moorley, unul dintre cele mai cunoscute experimente din istoria științei, nu a fost niciodată finalizat. Dar despre asta nu prea se vorbește când se discută despre experiment, ci dimpotrivă, el apare ca o unitate completă.

Asta ilustrează faptul că știința e haotică și derutantă. De asemenea, e nevoie de timp pentru a discerne “știința bună” de “știința rea” sau de a diferenția un om de știință “bun” de unul “rau”. Mai ales că atunci când are loc o descoperire revoluționară, reacția naturală a comunității este: “Nu poate fi corectă! Acest om e incompetent!”.

Galileo a fost în mod evident un geniu, despre care contemporanii lui credeau că e nebun!

Singura excepție la istoria lungă a acestui comportament a fost Einstein. El a fost excepțional din punctul acesta de vedere, dar și multe din elementele teoriilor lui au fost controversate până în anii ‘60. Abia după aproape 60 de ani de la descoperirile lui, ultimele obiecții au fost înlăturate.

Felul în care Harry a descris în mai multe locuri imaginea noastră asupra procesului științific, e ca o corabie într-o sticlă.

Noi o vedem ca pe un lucru gata făcut. El

www.todaysoftmag.ro | nr. 30/decembrie, 2014

17

interviu

spune că nu vedem dezordinea, nu vedem lipiciul vărsat, catargul rupt, încercările care nu au funcționat, părțile care nu s-au potrivit, și altele. În schimb, vedem proiectul terminat. Cred că acesta este un aspect foarte interesant în legătură cu modul în care știința este percepută de către publicul larg. Autorul prezintă o imagine diferită de cea a unui geniu singuratic undeva într-o mansardă, care a avut subit o revelație miraculoasă, iar lumea din jur a acceptat instant acea idee că fiind un lucru normal și minunat. De fapt, știința e presărată cu aceleași tipuri de controverse cu care se confruntă și testeri-ii zi de zi atunci când există dubii în legătură cu gravitatea unei probleme sau cu existența efectivă a unei probleme într-un anumit context.

Cu fiecare proiect ne place să ne gândim “Gata, am terminat!”. Dar nu există certitudine absolută în legătură cu acest gen de concluzii. Jerry Weinberg spune că un singur bit e de ajuns pentru a pulveriza valoarea unui program, un singur bit. Mai mult, până când nu se întâmplă asta, nu putem ști exact care este acel bit.

Sunt niște cărți fantastice! Sunt foarte plăcute și sunt scrise într-un mod captivant și distractiv. Și raportul numărului de revelații pe pagină e foarte mare.

18

Cum vezi rolul comunităților de tester-i? Se mai pot declanșa revoluții în testare?

[Michael] Am participat în mai multe comunități. Am început una în Toronto (Toronto workshops in software testing), am fost la formarea unei alte comunități în Olanda, numită DEW T (Dutch Exploratory Workshops on Testing) care a fost în mare parte inspirată de LEWT, London Exploratory Workshops on Testing, înființată de James Lyndsay. Am fost la toate acestea trei, și cred că de fapt de aici începe REVOLUȚIA! Începe cu un număr mic de oameni, ca orice altă revoluție. Începe cu un grup mic de oameni care se adună și vorbesc despre interesele lor, își împărtășesc experiențele și experimentează idei împreună. Mă simt foarte privilegiat să fiu parte din aceste grupuri! Sunt invitat din când în când la astfel de evenimente, sau uneori sunt într-un loc în care cineva organizează o astfel de întâlnire spontană, ceea ce e mereu minunat. Este minunat, pentru că așa începem să punem testeri-i în centrul testării, prin faptul că împărtășim fiecare experiențele noastre, în loc să stăm să ascultăm un material care ni se recită de către o singură persoană. Pe cât de mult îmi plac cărțile, nu cred că putem obține

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

totul din cărți. Avem nevoie de discuții între noi, de a învăța unul de la celălalt, de a interacționa unul cu celălalt, de a ne ajuta reciproc să rezolvăm problemele cu care ne confruntăm.

La o scară mai mare, conferințele sunt foarte bune într-un anumit sens, pentru că ne dau ocazia să întâlnim mulți oameni noi. Mie îmi plac întâlnirile mici, care încep cu un grup de oameni care se întâlnesc să bea cafea sau bere. Una din cele mai interesante de acest fel e probabil Weekend Testers din India, creată de Ajay Balamurugadas. Am văzut o prezentare a lui Ajay despre acest subiect. A fost atât de captivant! A descris evoluția acestei comunități. După o perioadă de 15 săptămâni în care în fiecare week-end s-au întâlnit mai întâi în persoană, după care online, au creat o comunitate de tester-i cu abilități remarcabile în India. Totul a început cu patru prieteni și mentorul lor, după care s-a răspândit la alți patru prieteni, și destul de curând oameni din Mumbay și Chenai, după ce au auzit despre întâlniri prin zvonuri, întrebau “Hei! am putea să ne implicăm și noi în această inițiativă?”

Așa cresc comunitățile, așa încep revoluțiile, așa sunt inițiate schimbările mari. Marile schimbări încep mereu cu schimbări mici.

Concept și brainstorming de întrebări: Echipa Altom Selecția întrebărilor: Alexandra Casapu Reporter: Ramona Tripa Sunet: Alexandra Casapu Transcript: Levente Balint Traducere: Ramona Tripa, Levente Balint și Alexandra Casapu Editare: Oana Casapu Alexandra Casapu

alexandra.casapu@altom.ro Software Tester @ Altom Consulting

comunități

TODAY SOFTWARE MAGAZINE

Comunităţi IT

Î

ncheiem acest an cu satisfacția participării la multe evenimente de calitate iar ediția a II-a a IT Days a încununat finalul de an.

Să nu uităm și de cele 12 evenimente de lansare din Cluj și de cele 4 evenimente pe care le-am organizat în București, Timișoara, Iași și Târgu Mureș. Peste 100 de prezentări de articole au fost susținute iar majoritatea lor sunt disponibile pe canalul nostru de YouTube www.youtube.com/todaysoftmag.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

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

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

www.youtube.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 2011/Nr. Evenimente: 27 Cluj Business Analysts Comunitate dedicată analizei de business Website: www.meetup.com/Business-Analysts-Cluj Data înfiinţării: 10.07.2013 / Nr. Membri: 91 / Nr. Evenimente: 8

Calendar Decembrie 16 (Cluj) Lansarea numărului 30 al Today Software Magazine www.todaysoftmag.ro Decembrie 18 (Cluj) PM Meetup - Monitoring & Controlling (2) meetup.com/PMI-Romania-Cluj-NapocaProject-Management-Meetup-Group/ events/218942428/ Decembrie 16 (București) Lean Startup Buchares - Last end of the year meetup meetup.com/lean-startup-bucharest/events/219062023/

Cluj Mobile Developers Comunitate dedicată tehnologiilor mobile Website: www.meetup.com/Cluj-Mobile-Developers Data înfiinţării: 05.08.2011 / Nr. Membri: 264 / Nr. Evenimente: 17 The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software.

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

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

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

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

www.todaysoftmag.ro | nr. 30/decembrie, 2014

19

testare

programare

Testarea de performanță de la Waterfall la Agile

C

Claudiu Gorcan

Claudiu.Gorgan@betfair.com Senior Delivery Service Engineer @ Betfair

a orice altă poveste de succes, atunci când vine vorba de testele de performanță povestea noastră îmbină armonios oameni și procese. Companii diferite au la baza culturi diferite, astfel încât acestea jonglează cu un amalgam diferit de oameni și procese . Echipele versate, care au persoane dedicate testelor de performanță ar putea folosi doar ghidări generale ca un proces, în timp ce echipele mai agile în care se rotește rolul responsabilului în testarea de performanță, între membrii echipei, probabil că ar avea nevoie de procese mai detaliate, liste de verificare etc. astfel încât întregul flux de testare de performanță să fie consecvent de la un sprint la altul, iar rezultatele să ofere același nivel de încredere.

Paragrafele următoare se vor concentra mai mult pe modul de lucru de tip Agile, dar va sublinia și importanța bazei solide a întregului proces în sine, care a fost construit de-a lungul anilor și a implicat mulți experți în domeniu.

Waterfall

În multe cazuri, procesul de testare de performanță ar fi arătat ca și cel de mai jos: o echipă de testare de performanță (echipa perfqa), care are ultimul cuvânt, înainte ca un produs să ajungă în producție: Chiar dacă echipa perfqa ar fi fost implicată în stadiile incipiente ale unui produs, prin intermediul ședinței de începere a proiectului (Kick-off meeting), aceasta nu făceam parte din sprint-uri, nu era lângă programatori și nici nu aveau același manager ca și echipa de dezvoltare. Toate cele de mai sus au generat câteva neconcordanțe cu modul de lucru Agile, după care s-au ghidat echipele de dezvoltare: • Noi (echipa perfqa) urmăm propriul program, construit pe baza cerințelor pe care le au echipele de dezvoltare.

• Nu simțeam ritmul și dificultățile echipei de dezvoltare - pentru care rulăm testele de performanță • Responsabilitatea pentru livrarea unui produs de calitate și performant a fost împărțită între echipe diferite.

20

nr. 30/2014 | www.todaysoftmag.ro

”Minunea” Agile

În timp, procesul de perfqa a început să se schimbe și a încercat să rezolve problemele de mai sus. Drept urmare, a luat naștere conceptul de „performance champions”. Chiar dacă conceptul a fost nou, nu aducea nimic inovator sau extraordinar. Era vorba mai mult de o comunitate ai cărei membri au fost programatori sau tester-i din diferite echipe de dezvoltare. Acești „performance champions” au început să fie direct implicați în procesul de perfqa aducând astfel testarea de performanță și responsabilitatea testelor de performanță mai aproape de echipele de dezvoltare în timp ce echipa de perfqa le-a oferit coaching, mentorat și îndrumare.

Ca un susținător și într-un fel îndrumător a conceptului de „performance champions”, voi prezenta câteva dintre gândurile mele precum le-ar fi prezentat Clint Eastwood:

Binele

Până acuma aveam programarea, testarea funcțională, managementul de proiect, analiza de business, devops cu rol de componente ale unei echipe, dacă la toate acestea adăugăm și testarea de performanță, echipa devine completă și pe deplin responsabilă de produsele livrate.

Testarea de performanță poate face parte acuma din planificarea sprint și poate fi adaptată în funcție de nevoile fiecărei

programare echipe. Însă odată cu aceasta apar și noi provocări și oamenii vor fi nevoiți să își extindă domeniul de expertiză cu: strategii de testare de performanță, instrumente, reglare și monitorizare.

Răul

Trebuie ținut cont de diferența dintre un expert pe un anumit domeniu (ex.: expert pe testarea de performanță) și o persoană mai versatilă care este specializată pe diferite tehnologii (ex.: dezvoltare și testare de performanță sau testare funcțională și testare de performanță).

Urâtul

Având în vedere ca testele de performanță intră acum în responsabilitatea fiecărei echipe, ei le vor adapta nevoilor pe care le au. Acesta ar putea să nu fie neapărat un lucru urât, având în vedere că până la sfârșitul zilei toții ar trebui să aibă o înțelegere coerentă despre performanța unei componente (ex. :100 de tranzacții pe secundă TPS ar însemna același lucru pentru toți) și toți ar dori să aibă un produs integrat și nu o grămadă de componente mari și performante.

Mediile de testare de performanță vor trebui menținute de diferite părți ale organizației.

Suporterii pentru conceptul ”performance champions” (comunitatea de experți) ar trebui să încerce cel puțin schimbarea de mai sus – însă desigur nu trebuie schimbate lucrurile care deja merg bine (”Binele”). Expertiza poate consta din următoarele: • M e d i u p e n t r u t e s t a r e a d e performanță: pregătirea mediului ar

TODAY SOFTWARE MAGAZINE trebui abordată cât mai curând posibil, mai ales în cazul în care nu există nici un responsabil pentru asta. Folosind mediul, echipa ar trebui să aloce timp pentru reîmprospătarea (refreshing) componentei de testat și a dependințelor sale. Mediul de performanță ar putea fi o replică la scală a mediului de producție sau un mediu pentru disaster recovery.

• Modelul de testare: De obicei este sugerat să se folosească principiul lui Pareto, care s-ar traduce: 20% din fluxurile de aplicare ar genera 80% din încărcare. Deci practic, aceasta este partea asupra căreia trebuie să ne concentrăm din perspectiva testelor de performanță. Modelarea procesului de ”real life user” (cum ar fi: în orice moment dat 10% dintre utilizatori sau dintre cei care se autentifică, 20% încărca pagina de start, etc.) este destul de important pentru înțelegerea comportamentului de performanță a unei cereri care acceptă ~ tps 60k la vârf.

• Strategia de testare: încărcarea, capacitatea, scalabilitatea și soak testing sunt critice, iar întrebarea care se pune este: „Cât de mult pot face față”. Acest flux ar trebui să înceapă în mod natural cu partea de load testing și înțelegerea performanței în sarcină normală, apoi să se treacă la testarea pentru capacitate (capacity testing) care ar trebui să genereze cererea de tuning (cum ar fi tuning GC) și să dezvăluie punctul slab al aplicației și mai important motivul acestei slăbiciuni care poate fi: CPU starving, memoria, un thread pool sau o interogare db eronată. Apoi, să investească în testarea scalabilității, fie că este scalare verticală ca sistemul bursei

de valori fie scalare orizontală care din nou ar trebui să genereze optimizări de scalabilitate deoarece majoritatea aplicațiilor nu se scalează 100% adăugând un extra server .Am văzut cele mai multe scalând ~ 80%, astfel încât, dacă un server poate duce ~ 100tps, două ar duce ~ 180tps). Cu toate acestea, un soak test de 8 ore ar putea dezvălui probleme de stabilitate și chiar posibile pierderi de memorie (chiar dacă mici).

• Testarea componentelor vs testarea integrată: De obicei, limitările de timp nu permit testarea de performanță a componentelor, însă mimând dependințele și aplicând load testing pentru toate componentele ar putea fi identificate problemele de performanță încă din stadiile incipiente ale procesului de dezvoltare .

• Monitorizarea producției: Cu toate că ar putea suna mai degrabă ca și o sarcină operațională, munca tester-ului de performanță nu se oprește odată ce produsul a intrat în producție.

Monitorizarea în producție și culegerea de feedback ajută la ajustarea modelului și înțelegerea rezultatelor – în producție ar putea apărea probleme care nu au putut fi replicate în mediul de testare.

www.todaysoftmag.ro | nr. 30/decembrie, 2014

21

programare

Riscurile operării cu branch-uri.

Alternativa de branching prin abstractizare

F

Anghel Conțiu

Anghel.Contiu@endava.com Design Lead @ Endava

olosirea instrumentelor de control al versiunii a devenit un obicei în modul nostru de lucru, iar una dintre proprietățile lor, aceea de a folosi branch-uri, poate fi fructificată după cum consideră fiecare echipa că aduce valoare. S-au scris multe articole despre strategiile de branching și în timp ce unele dintre ele au devenit foarte populare, aproape toate au o problemă comună care trebuie abordată. Aceasta este problema procesului merging între branch-uri. Există un motiv pentru care se discută nu doar în termeni de strategie de branching, ci in termeni de strategie de branching și merging.

Fuziunea se poate transforma ușor în deveni disponibile pentru restul echipei. coșmar atunci când strategia abordată este De urmărit următoarea situație: • George lucrează pe branch-ul greșită. Putem să luăm ca exemplu una dintre cele mai populare strategii de fuzibranch-George și îl creează din branch “develop”; une, strategia Vincent Driessen prezentată în Figura 1. Această strategie poate să nu • Andrei lucrează deja pe branch-ul lui, branch-Andrei, de ieri; fie cea mai potrivită în anumite condiții întâlnite destul de des.

• Maria își termină de implementat funcționalitatea după 6 zile de lucru și efectuează operația de merge a branchului pe care a lucrat, branch-Maria, în branch-ul “develop”; • Dan, QA-ul nostru, începe testarea funcționalității implementate de Maria.

Acesta pare a fi un workflow sănătos, însă ascunde câteva riscuri care în final vor duce la un efort adițional atât pe partea de dezvoltare, cât și pe cea de testare. Iată câteva dintre aceste riscuri:

Riscul retestării funcționalității

Figura 1: modelul Vincent Driessen

Ne concentrăm pe cele două branchuri care sunt intens folosite: “feature” și “develop”.

Branch-ul “feature” este creat din branch-ul “develop” și este folosit de programator pentru a implementa o nouă funcționalitate.

Când termină implementarea, va aduce modificările de pe branch-ul “feature” în branch-ul “develop” astfel încât acestea vor

22

nr. 30/2014 | www.todaysoftmag.ro

Dan își petrece o zi testând toate particularitățile implementării Mariei și în final își dă acordul. Totul funcționează bine. Ceea ce el încă nu știe este faptul că Andrei lucrează cu două dintre fișierele modificate de Maria. Andrei își efectuează un merge al branch-ului său trei zile mai târziu în branch-ul develop și e bucuros că nu întâmpină conflicte. Dan începe testarea dar observă că funcționalitatea Mariei nu se mai comportă bine. Dan creează un tichet pentru Maria, Maria rezolvă problema folosind de această dată și modificările aduse de Andrei, iar Dan urmează să testeze din nou atât funcționalitatea Mariei, cât și pe cea a lui Dan. Așadar Maria a pierdut timp pentru reparația respectivă, iar Dan a pierdut timp

diverse

TODAY SOFTWARE MAGAZINE

deoarece a trebuit să testeze cel puțin de automat script-uri care aduc starea bazei două ori ambele funcționalități. de date la versiunea corectă. Din cauza faptului că programatorii vor crea aceste script-uri iîn izolare, pe branch-uri diferite, Riscul fuzionării Se întâmplă des ca dezvoltarea există riscul de a strica ordinea în care ele funcționalităților și scrierea de teste uni- trebuie rulate.

Dacă privim cu atenție rădăcina acestare pentru ele să dureze câteva zile.

Pentru a micșora riscul apariției de con- tor probleme, observăm izolarea în care flicte la fuziune programatorii încearcă să lucrează programatorii pe branch-uri difeîși aducă branch-ul “develop” cât mai des rite. O alternativă pentru acest mod de (probabil în fiecare zi) în branch-ul pe lucru este folosirea tehnicii de branching care ei dezvoltă separat funcționalitatea. prin abstractizare.

Faptul că se implementează simultan mai multe funcționalități diferite pe branch- Branching prin abstractizare uri diferite este cert, iar riscul de conflicte Este definită de Martin Fowler ca fiind la fuziune este oricum ridicat, iar cu cât “o tehnică de a face o schimbare pe scară programatorii petrec mai mult timp pe largă unui sistem software într-un mod branch-ul lor specific, cu atât riscul crește. gradual care permite lansarea sistemului în mod regulat în timp ce schimbarea e încă în desfășurare”.

Riscul pentru integrarea continuă Tehnica implică adăugarea unui nivel Programatorii ar trebui să scrie teste unitare, teste între componente și teste de de abstractizare deasupra funcționalității integrare. Atunci când aceste teste sunt la care se lucrează astfel încât codul clidezvoltate împreună cu funcționalitatea, ent va comunica doar cu acest nivel de în izolare, pe branch-ul de implementare abstractizare, nefiind conștient dacă a funcționalității, și în același timp o altă folosește versiunea originală sau nouă a funcționalitate este dezvoltată împreună implementării.

Oricare ar fi modul în care este folosită cu testele corespunzătoare pe un alt branch, la momentul efectuării operației de tehnica, există câteva puncte comune: • Folosirea unui nivel de abstractizare merge șansele ca testele scrise să pice sunt pentru a permite existența în același ridicate. Testele nu au fost scrise luând în timp a mai multor versiuni ale unei considerare comportamentul dezvoltat în funcționalități; paralel pe celelalte branch-uri. Ele vor tre• Migrarea graduală către noua bui revizuite și reparate, ceea ce aduce un implementare; efort în plus.

• A s i g u r a r e a c ă s i s t e m u l s e construiește și rulează corect în orice Riscul pentru rularea script-urilor pe moment, astfel încât livrarea continuă baza de date este posibilă.

Multe echipe încearcă să își automatizeze procesul de instalare al produsului. În timp ce programatorul scrie teste La nivel de baze de date rulează în mod

pentru funcționalitatea lui, el este sigur ca testele sale folosesc ultima versiune a codului deoarece colegii lui își adaugă modificările pe același branch. În acest fel nu vor exista operații de merge ulterioare care să strice testele, deoarece alte branchuri nu există.

Este importantă plasarea corectă a nivelului de abstractizare și modul în care obiectele dintr-o versiune sau alta ale aceleiași funcționalități sunt instanțiate.

Din acest punct de vedere există mult loc pentru creativitate deoarece această decizie depinde și de contextul problemei. Pot exista mai multe variante, dintre care vor fi prezentate două.

Branching prin abstractizarea componentei

Această tehnică se aplică acolo unde este necesară modificarea sau rescrierea unei componente mari.

Un nivel de abstractizare trebuie adăugat astfel încât codul client să nu mai depindă de componentă ci de abstractizare. Această acțiune ar putea implica unele modificări (refactoring) la nivel de componentă și teste adiționale ar putea fi scrise. Modificările necesare în vederea extragerii nivelului de abstractizare ar putea fi costisitor, de aceea acesta este un punct important pentru a lua o decizie asupra strategiei de branching.

Noua implementare a componentei va fi făcută pas cu pas, astfel funcționalitățile vor fi adăugate în funcție de priorități.

Când un set de funcționalități e finalizat, clientul codului poate schimba legăturile cu instanțele folosite și poate migra la noua componentă. Este important de reținut că aplicația trebuie să poată fi construită

www.todaysoftmag.ro | nr. 30/decembrie, 2014

23

programare Riscurile operării cu branch-uri

Figura 2: Branching prin abstractizarea componentei. ClientCode este într-un process de migrare pentru a folosi NewComponent.

și rulată în oricare moment. În final nu vor mai exista dependențe către vechea implementare.

Branching prin abstractizare la nivel de punct de folosire

Să luăm în considerare cazul în care abstractizarea la nivel de componentă nu este cea mai bună soluție. Motivele ar putea consta în efort prea mare de modificări pentru a extrage nivelul de abstractizare la nivel de componenta. Pentru astfel de situații putem lăsa codul așa cum este și să alegem o altă tehnică.

Figura 3 face referință la codul care folosește clasa (grupul de clase) ce trebuie actualizată. Descrierea claselor din figura: 1. Versiunea veche și versiunea nouă a implementării clasei care folosește codul ce trebuie actualizat: • Punctul de abstractizare este la nivel de clasă care folosește codul ce trebuie actualizat.

• Inițial vom avea versiunea originală a clasei client și o copie a ei care va deveni noua versiune (da, nu trebuie să copiem o clasă, aceasta va fi o situație temporară până când noua versiune devine stabilă; vom avea apoi posibilitatea de a folosi versiunea originală dacă vor fi probleme în timpul folosirii noii versiuni; versiunea originală în final va fi ștearsă).

• Vom avea o interfață nouă pe

condiții diferite în locuri diferite.

3. Spațiul de activitate al clasei client („the scope”) • Având componenta „factory” ca responsabilă pentru instanțierea clasei client, avem oportunitatea să stabilim spațiul de activitate al instanței; • În general noua versiune ar trebui să aibă același spațiu de activitate ca și cea originală, iar aceasta decizie poate fi specificată la nivelul „factory”.

4. Rularea aplicației în medii diferite • Componenta „factory” poate deveni conștientă de mediul în care activează și va instanția versiunea clasei client adecvată mediului respectiv; • Posibilitatea de a putea instanția o implementare sau alta constituie și un mecanism de rezervă în cazul în care noua versiune nu funcționează la nivelul așteptărilor. Dezactivarea ei și activarea instanței originale se efectuează ușor si rapid.

care atât clasa client originală, cât și noua versiune a acestei clase client o vor implementa („Interface” în Figura 3). Interfața va conține probabil metodele publice din implementarea originală a clasei client.

• Noua versiune a clasei client va fi modificată treptat pentru a aduce noile funcționalități.

• Versiunea originală va fi ștearsă la final.

2. „The Factory” Sintetizăm afirmațiile de mai sus pri• Va avea responsabilitatea de a instanția versiunea originală vitoare la aspectele asupra cărora se vor sau versiunea nouă a clasei client; concentra membrii echipei: Programatorii: Responsabilitatea verificării dacă una • Vor folosi un singur branch de sau cealaltă dintre versiuni trebuie dezvoltare; instanțiată se face în interiorul com• Vor implementa nivelul de abstracponentei „factory”. tizare, mecanismul de instanțiere a unei • Poate deveni mai inteligentă instanțe sau a celeilalte și vor scrie noi în măsura în care este nevoie; spre teste pentru a crește încrederea în aceste exemplu, poate alege între cele două componente; versiuni la pornirea aplicației sau în • Se vor concentra apoi pe noua vertimpul rulării acesteia, poate să fie siune și o vor modifica pentru a adăuga conștientă de mai multe informații din noile funcționalități. mediul în care există și să ia măsuri în Persoanele care testează: funcție de acestea, etc. .

• Vor testa faptul că versiunile pot fi • Se va folosi interfața clasei client schimbate la rularea aplicației sau în oriastfel încât implementarea originală care moment ar fi nevoie; sau cea nouă va fi instanțiată și injec• Vor testa noua funcționalitate; tată acolo unde este nevoie de ea; • Vor testa și vechea funcționalitate • Va constitui garanția faptului că dacă a fost modificată pentru a permite acolo unde e nevoie de o implemencrearea nivelului de abstractizare (nu se tare sau de alta, modul de alegere între aplică pentru abstractizarea la nivel de ele va fi unul consistent, și nu vor fi punct de folosire); • Sunt ajutați de faptul că nu există cod care vine de pe alte branch-uri care poate interfera cu ceea ce au testat deja.

De îndată ce nivelul de încredere în noua funcționalitate devine suficient mecanismul de schimbare între instanțe și instanța originală pot fi șterse. Important este de luat în considerare faptul că sistemul trebuie să poată fi construit și rulat cu succes în oricare moment.

Figura 3: Ramificarea prin absractizare la nivel de punct de folosire. Versiunea originală și cea nouă a clasei care folosește codul ce trebuie actualizat.

24

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

securitate

programare

Utilizarea sistemelor de operare compatibile cu OSEK/VDX în sistemele embedded

S

istemele embedded au la bază microcontrolere care procesează datele primite ca intrare și execută acțiunile corespunzătoare conform rutinelor programate.

Porturile I/O facilitează interfațarea cu lumea exterioară, iar rularea rutinelor/ algoritmilor proiectului aplicației este efectuată de către unitatea CPU.

Mircea Pătraș-Ciceu

mircea.patras@arobs.com C++ Developer @ AROBS

Proiectul software trebuie să conțină, pe lângă fișierele de configurație adaptate tipului de microcontroler folosit, un programator de activități (eng.: task scheduler), rutine pentru controlul unităților periferice (driver-e) și rutinele aplicației.

Proiectul poate să mai conțină și servicii de comunicație, librării și altele. În continuare vom menționa două metode comune de programare a activităților: „super loop” și mașini de stare; apoi vom prezenta mai detaliat algoritmii de programare, utilizați în sistemele de operare OSEK/VDX și vom evidenția pe scurt avantajele și dezavantajele folosirii fiecăruia dintre ele.

Ne vom referi mai jos la OSEK/VDX în mod simplificat: OSEK.

Algoritmi de programare a activităților Algoritmul de programare a activităților într-un proiect embedded reprezintă modalitatea în care se apelează funcțiile aplicației. Această secvență de apelare a activităților poate fi configurată în mod explicit (cum e cazul sistemelor de operare compatibile OSEK) sau poate fi o consecință directă a modului de implementare a aplicației (în cazul „super loop”).

Prin configurarea explicită a secvenței de execuție a activităților înțelegem conectarea acestora la câte un eveniment și definirea clasei și priorității lor (OSEK).

Continuăm cu prezentarea metodelor de programare a activităților:

Super loop E un mod simplist, dar „la îndemână” de a executa activitățile unei aplicații embedded. Funcționarea e simplă: într-o buclă WHILE(1) sunt verificate secvențial și periodic (cu o perioadă nedeterminată ce depinde mult de activitatea care rulează la un moment dat) toate condițiile

de rulare a activităților. Atunci când o condiție este îndeplinită, activitatea corespunzătoare este executată. În acest timp celelalte activități sunt blocate și nu se verifică nici condițiile de executare a lor.

Pro: implementarea e simplă (dar și simplistă); Contra: resursele CPU sunt folosite ineficient, activitățile sunt executate în mod necontrolat, mentenanța codului sursă e anevoioasă.

Mașini de stare Folosind această metodă, aplicația este mai bine structurată decât în cazul „super loop”. Activitățile sunt executate în funcție de starea curentă a mașinii de stări.

Activități de o complexitate mai mare pot fi implementate folosind mașini de stare imbricate.

Pro: pregătirea și mentenanța codului sursă este facilă; Contra: resursele CPU nu sunt folosite într-un mod optim, algoritmul de programare a activităților este puternic integrat în aplicație astfel că el este practic creat de la zero de la o aplicație la alta.

Programatoarele de activități OSEK: OSEK oferă un standard pentru proiectarea sistemelor embedded în domeniul automotive. Unele din ariile de acoperire OSEK sunt sistemele de operare folosite în aplicațiile embedded. Există două tipuri de sisteme de operare propuse de standardul OSEK: OSEK OS cu programatorul de activități condus de evenimente și OSEKtime OS cu programatorul de activități periodic. Configurarea sistemelor de operare OSEK se realizează cu fișiere .oil (ce includ definirea activităților și proprietăților acestora) și alte elemente specifice sistemelor de operare: rutine

www.todaysoftmag.ro | nr. 30/decembrie, 2014

25

programare Utilizarea sistemelor de operare compatibile cu OSEK/VDX în sistemele embedded poate face manual sau utilizând unelte de configurare de nivel înalt specifice (dacă sunt disponibile). Fișierele .oil sunt apoi interpretate de generatorul de sistem care creează fișiere sursă.

Aceste fișiere sursă, împreună cu restul modulelor aplicației formează proiectul software compilabil. Acest mecanism înlesnește procesul de portare a aplicațiilor pe mai multe sisteme de operare compatibile OSEK și pe mai multe tipuri de microcontrolere (suportate de OS).

Fig. 1 Pașii dezvoltării / configurării aplicației

Rularea aplicației

În orice moment, programatorul de activități o rulează pe cea „hook”, „resurse”, alarme, evenimente, mesaje, moduri de rulare cu prioritatea mai mare dintre cele în starea „ready”. Dintre două activități cu aceeași prioritate, cea activată prima va fi reactivată a aplicației, rutine pentru tratarea erorilor. întâi, după o întrerupere cauzată de o altă activitate mai importantă (principiul FIFO). Cealaltă activitate va fi activată după OSEK terminarea sau intrarea în așteptare a celei curente. Terminarea Următoarele elemente sunt disponibile în OSEK OS: activități, evenimente, API-uri pentru controlul resurselor și al întrerupe- „benevolă” a unui task se face prin apelul programatorului de rilor, alarme, mesaje. Activitățile sunt programate în funcție de activități. În funcție de nevoile aplicației se pot activa mai multe prioritate, astfel încât o activitate va fi întreruptă dacă alta, cu moduri de programare a activităților care permit sau nu prezența prioritate mai mare, a primit semnalul de activare. După termi- activităților extinse și permit sau nu întreruperea lor. Activitățile narea acestei activități, vechea activitate este reluată dacă are cea care pot fi întrerupte sunt utile, de exemplu, atunci când, într-o mai mare prioritate. O activitate poate fi lansată prin mai multe aplicație, sunt activități atât cu timp mare cât și mic de execuție. moduri: direct din altă activitate, la expirarea contorului unei alarme, dintr-o întrerupere configurată sau de către un mesaj. Activități Activitățile extinse pot intra în modul de așteptare al unui eveCum am amintit și mai sus, există două tipuri de activități: niment, eliberând astfel resursele CPU și permițând rularea unei simple și extinse. Cele extinse au în plus starea de așteptare a unui alte activități. La apariția evenimentului, activitatea care rulează eveniment față de stările activităților comune: suspendată, preeste întreruptă și se reia execuția activității extinse (dacă priori- gătită de rulare și în execuție. La nivelul OS implementarea este tatea acesteia este mai mare). Resursele utilizate de activități pot semnificativ mai complexă atunci când sunt acceptate și task-uri fi și ele blocate, astfel încât alte activități ce necesită accesul la extinse: necesitatea controlului unui stack suplimentar pentru aceeași resursă să nu o poată întrerupe pe prima, chiar dacă are o fiecare activitate extinsă față de un stack unic pentru activitățile prioritate mai mare. simple. Consumul de memorie este astfel crescut.

Sistemul de operare poate rula în mai multe moduri de Activitățile mai au o proprietate: disponibilitatea de a fi întreaplicație (definite static în fișierele .oil). Practic, fiecare mod dife- rupte. Astfel, ele pot fi întrerupte sau cooperative (adică nu pot rit al aplicației are un set distinct de activități (ex.: modul normal, fi întrerupte). modul de diagnosticare, bootloader). Aplicația decide în timpul rulării când se trece de la un mod la altul.

Mecanisme de sincronizare Rutinele de tip „hook” pentru tratarea erorilor sunt rulate de OSEK este un OS „condus” de evenimente ce oferă variate sistemul de operare la apariția acestora. Aceste rutine pot fi adap- metode de sincronizare (obiecte și servicii). Fiecare obiect genetate aplicației. rează un eveniment specific transmițând o anumită informație: • Obiectul eveniment: orice activitate poate genera un „eveniment”.

Totuși, doar activitățile extinse le pot consuma.

Pașii utilizării OSEK OS • A l ar ma: este repre zent at ă de obie c te at aș ate Primul pas este configurarea elementelor sistemului de opeunui contor (software sau hardware) care rare (definite mai sus) în fișierele .oil. Editarea acestor fișiere se

26

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Rulare aplicație Sistemul de operare va începe executarea activităților din tabela implicită. În aplicație, utilizatorul poate cere schimbarea tabelei de activități folosind un serviciu OS dedicat. Schimbarea va avea loc efectiv doar la sfârșitul parcurgerii tabelei curente (când toate activitățile sunt oprite).

Stările activităților

Fig. 2 OSEK/VDX task state

numără anumite evenimente (pot fi intervale de timp, apăsări de butoane, impulsuri de la un encoder etc.). Contorul este comparat cu valoarea predefinită în obiect la fiecare incrementare. La atingerea valorii dorite, alarma este activată și una din următoarele acțiuni este posibilă: activarea unei activități, activarea unui obiect „event”, execuția unei funcții callback.

• Întreruperi hardware: OSEK oferă servicii de control al întreruperilor care au rolul (în general) de a sincroniza activitățile cu evenimentele hardware.

• Mecanisme de comunicație/mesaje. Mesajele pot fi vehiculate între activitățile din același procesor sau între activități din procesoare diferite. Mesajele sunt configurate static (la dezvoltarea proiectului) în fișierul *.oil: se configurează, printre altele, modul de transmitere a mesajului, sursa și destinația lui.

Pro: resursele CPU sunt folosite în mod optim, implementarea software a activităților este facilă; Contra: configurarea OS este laborioasă.

Activitățile sunt activate la expirarea „timer”-ului asignat.

Acest „timer” este reîncărcat, în momentul startului activității, cu perioada configurată în tabela de activități. Dacă activitatea curentă (A) se termină înainte de expirarea „timer-ului” altei activități (B), atunci starea ei trece din activă în inactivă. Dacă nu, atunci A este întreruptă și B devine activă și se execută. La terminarea activității B, se reia activitatea A de unde a fost întreruptă.

Notă: la fel se întâmplă și când „timer-ul” activității A expiră înainte de terminarea execuției lui B. Astfel observăm că nu este definit, implicit sau explicit, un mecanism de prioritizare a activităților.

Detecția erorilor Timpul de execuție a activităților este comparat cu timpul de monitorizare predefinit în tabela de activități. La depășirea acestui timp, sistemul de operare va rula rutina corespunzătoare de tratare a erorii. Ulterior este inițiată procedura de oprire a OS și se va rula o nouă rutină utilizator pentru acțiuni specifice la oprirea sistemului de operare. După rularea acestei rutine OS va reporni.

Rutine de întrerupere

Utilizatorul configurează timpul minim de recurență a rutinelor de întrerupere pe lângă implementarea efectivă a acestora.

După activarea unei întreruperi, aceasta va fi dezactivată până OSEKtime Resursele puse la dispoziție în aplicațiile embedded compa- expiră timpul minim de recurență. Astfel se asigură un timp tibile OSEKtime sunt: întreruperile și activitățile. OSEKtime procesor minim pentru rularea activităților chiar în cazurile actiprogramează activitățile în mod periodic conform configurației vărilor repetate și rapide a întreruperilor. din tabela de programare. Programatorul de activități are capacitatea de a întrerupe activitatea curentă pentru a rula o alta, care Activitatea „idle” este pregătită de rulare. După terminarea rulării acesteia, prograPrima activitate rulată de OS este cea „idle”, al cărei conținut matorul reia execuția celei întrerupte (dacă există una). Totuși, este definit de utilizator. Activitatea „idle” rulează doar atunci o activitate nu se poate întrerupe pe ea însăși, această condiție când toate celelalte sunt inactive. Astfel, ea este întreruptă de fiind considerată o anomalie. În acest caz programatorul de oricare din celelalte activități. O metodă de utilizare a activității activități va rula o rutină specifică de tratare a erorii, configu- „idle” este de a apela instrucțiunea de trecere a microcontrolerrabilă de către aplicație (ex.: repornirea SO sau chiar resetarea ului în modul „sleep” astfel încât, atunci când nicio activitate microcontroler-ului). periodică nu rulează, procesorul să consume mai puțin curent.

Pro: resursele CPU sunt folosite într-un mod optim și se asigură un comportament previzibil al aplicației în toate situațiile; Pașii utilizării OSEKtime OS Contra: utilizatorul trebuie să țină cont de limitările acestui La dezvoltarea proiectului, primul pas este configurarea uneia sau mai multor tabele de activități. Mai multe astfel de tabele tip de programator de activități când implementează funcțiile permit rularea aplicației în mai multe moduri (ex.: inițializare, aplicației: suma funcțiilor din orice activitate trebuie să determine mod de funcționare normală etc.). În fiecare din aceste tabele, un timp de execuție mai mic decât timpul de monitorizare. Metoda activitățile sunt configurate prin definirea „offset-ului”, perioa- de implementare a activităților este constrânsă de faptul că acestea dei de activare, timpului de monitorizare a execuției și adresa se execută periodic. activității (un pointer la funcția care implementează activitatea).

Utilizatorul mai configurează și timpul de „tick” al sistemului COM de operare. Regula calculării acestuia este următoarea: valoarea OSEK oferă specificații standardizate și pentru serviciile de lui trebuie să fie cel puțin egală cu cel mai mare divizor comun al comunicație. Mesajele configurate pot fi vehiculate între activități perioadelor activităților configurate. Cu cât valoarea „tick-ului” din același CPU sau din microcontroler-e diferite. este mai mare, cu atât sistemul de operare va aloca mai mult timp CPU pentru activități și mai puțin pentru rularea rutinei de pro- REFERINȚE gramare a activităților.

1. http://www.osek-vdx.org/ www.todaysoftmag.ro | nr. 30/decembrie, 2014

27

programare

management

Salveaza timpul utilizatorului cu o interfață bine proiectată

T

impul este foarte important pentru utilizatori, motiv pentru care nouă ar trebui să ne pese. La fiecare proiect trebuie să ne punem întrebările: ”Mă scutesc pe mine de câteva ore de dezvoltare în defavoarea utilizatorului?” și ”Cum aș putea să îmbunătățesc experiența pe care utilizatorul o are?”

Axente Paul

paul.axente@3pillarglobal.com Senior UX Engineer @ 3Pillar Global

28

nr. 30/2014 | www.todaysoftmag.ro

Oamenii urăsc să piardă timpul, mai ales online. Petrecem atât de mult timp online încât și cele mai mici interacțiuni necesită timp. O mică “bubă” nu pare cine știe ce, dar mai multe adunate aduc frustrare și cresc probabilitatea că utilizatorii să renunțe la folosirea serviciului pe care încerci să îl furnizezi.

Suntem atenți la timpul nostru când începem un proiect. Avem milestone-uri de atins, demo-uri de făcut, bug-uri de rezolvat și, de parcă toate acestea nu-s de ajuns, avem și Internet Explorer. Uităm un lucru esențial: tot ce facem are efect pozitiv sau negativ asupra experienței utilizatorului.

Nu trebuie să lăsăm ca sentimentele noastre față de proiect să vină înaintea experienței utilizatorului. În cele mai multe cazuri, utilizatorul suferă pentru că nouă nu ne place proiectul, nu avem timp și așa mai departe.

De multe ori, puțin și bine e tot ceea ce trebuie comparativ cu mult și rău.

Steve Jobs susținea că prin îmbunătățirea timpului de pornire al Macintosh-ului ar putea salva vieți. Jobs era obsedat de a nu pierde timpul utilizatorilor ce-i folosesc produsele. Și noi ar trebui să fim la fel de atenți când vine vorba de “produsele” noastre.

Probabil milioane de oameni nu îți vor folosi site-ul dar milioane folosesc WWW-ul. La un loc furăm vieţile oameniilor prin interacţiuni făcute greşit. Când lucrez la un site, o întrebare mă macină mereu: “Mă scutesc pe mine de

câteva ore de dezvoltare în defavoarea utilizatorului?”.

Acesta este miezul problemei. În disperarea de a nu depăşi deadline-ul sau bugetul ne salvăm pe noi şi totul se reflectă asupra utilizatorului. Haideţi să vedem mai exact ce efect au deciziile noastre asupra utilizatorilor.

Performanţa site-ului - Criminalul din umbra

Cel mai evident şi mai dureros mod prin care poţi frustra utilizatorii e timpul de încărcare al unui site, iar când vorbim de performanţă nu doar utilizatorii suferă ci şi clientul. Povestea cu performanţă e un pic mai complicată, majoritatea dăm vină pe server şi pe internet sau clasică poveste: “La mine pe calculator merge bine!”. În fond şi la urmă urmei e valid argumentul că serverul sau internetul e de vină, dar totodată sunt o mulţime de aplicaţi native (HTML5 API - câteva exemple - http://www.sitepoint.com/10-html5-apis-worth-looking/) care ne vin în ajutor. Putem detecta dacă utilizatorul este pe dispozitiv mobil sau nu, dacă e conectat la WI-FI sau internet mobil şi tot aşa. Avem atâtea resurse care ne vin în ajutor, dar mulţi dintre noi nu le folosim. În funcţie de tot ceea ce ştim despre un utilizator- dacă e mobil sau nu, dacă are internet de mare viteză, dacă mai are baterie la dispozitiv- putem îmbunătăţi performanţa şi totodată să oferim experienţe unice.

TODAY SOFTWARE MAGAZINE Problema e că îmbunătăţirea performanţei este de multe ori ultimul lucru la care ne gândim şi totodată e unul din cele mai ocolite de dezvoltatori. Am devenit leneşi odată cu extinderea internetului de mare viteză. Trişăm la optimizarea imaginilor, la reducerea cererilor HTTP şi a bibliotecilor de JavaScript. Toate acestea se întâmplă pentru că mulţi dintre noi ştim să dezvoltăm o grămadă de chestii pe web, dar nu ştim un lucru esenţial: cum funcţionează un browser şi cum redă conţinutul, informaţii elementare pentru a putea construi un web-browser performant.

Așadar, întrebările de tipul “Cum pot optimiza încărcarea acestui fişier?”, “Cum pot face această bucată de cod mai performantă?”, “Cum pot scrie aceeaşi funcţie de javascript în mai puţine linii?”, sunt cele care se circumscriu unei atitudini preocupate de performanța site-ului.

Formularele - Bătăi de cap eterne

Fiecare formular are specificul lui, cu regulile şi cu problemele lui pe care le împarte cu restul formularelor. Nu există un standard, probabil ar fi util să existe unul, dar din păcate nu e aşa. Fiecare e liber să facă ce vrea pe web, mai mult sau mai puţin. Iar la formulare fiecare serviciu are algoritmii lui, unii mai complicaţi decât alţii. E de apreciat totuşi încercarea de a fluidiza procesul de înregistrare şi intrare în cont prin folosirea profilelor sociale.

Mulţi dintre noi ne oprim din completarea unui formular când întâlnim un anumit “suspect” CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart).

Inventat în anul 2000 având la bază un proces destul de simplu şi inutil în acelaşi

timp. Primeşti o poză cu ceva caractere pe care doar un om le poate recunoaşte, le introduce şi trece la pasul următor. Foarte util în blocarea roboţilor în anul 2000. Au trecut 14 ani şi am avansat considerabil, nu cred că mai este necesar să pierdem timpul utilizatorilor cu completarea de CAPTCHA. Milioane de ore s-au pierdut pentru că utilizatorii au fost forţaţi să completeze în nenumărate rânduri un câmp, doar pentru a putea trimite un amărât de formular.

Toate acestea pentru că nu am rezolvat încă problema roboților. Şi aici nu vorbesc doar de CAPTCHA, vorbesc de orice sistem care obligă utilizatorii să dovedească că sunt oameni. În primul rând, de ce trebuie utilizatorii să dovedească că sunt oameni?

Problema roboţilor putea fi rezolvată dacă am fi alocat un pic de timp. “The honeytrap tehnique” este un foarte bun exemplu în acest sens. De asemenea, există soluţii server-side care ne ajută să filtrăm request-urile automate. Adevărul e că aruncând un CAPTCHA în pagină e mai rapid si efortul e relativ minim.

De regulă CAPTCHA e ultimul lucru dintr-un formular, ceea ce este bine.

De ce sunt parolele așa complicate?

Majoritatea ar răspunde “Din motive de securitate”. E adevărat că parolele trebuie să fie sigure. Dar în ultima vreme aproape fiecare te forţează ca parola să fie într-un anume fel.

De ce sunt obligat ca parola să fie un mix între numere, caractere şi caractere speciale, cu majuscule, fără majuscule, etc.? De ce nu rămâne la latitudinea utilizatorului să îşi aleagă parola? Fie ea o

combinaţie de caractere sau o propoziţie.

“Parolă mea e aceasta şi va provoc să o ghiciţi!”. Numărul de caractere face parola mai sigură, iar o parolă ca cea din exemplu e şi mai uşor de reţinut. Iar dacă sistemul nu acceptă spaţii, ignoră-le. De asemenea am mai putea oferi opţiunea de a vedea ce scrii în câmpul de parolă.

Nu forţa utilizatorii să “îşi corecteze” greşelile în formulare!

E de apreciat când se încearcă prepopularea conținutulului unui formular.

De exemplu, pe baza codului poştal să îţi genereze adresa aproape completă. Ar putea scuti utilizatorul de completarea a patru sau cinci câmpuri. E un lucru destul de interesant şi nu mulţi îl practică, din păcate. O parte din scripturile care populează adresa după codul poştal necesită ca informaţiile introduse să nu aibă spaţii, virgule, etc. . În loc să se scoată toate caracterele înafara de cifre din configurarea scriptului, utilizatorul e forţat “să-şi corecteze greşeală”. De ce trebuie utilizatorul să introducă datele într-un mod anume?

De ce le pierdem timpul şi îi obligăm să reintroducă datele într-un mod anume?

De ce nu formatăm noi datele respective?

Dacă un câmp nu trebuie să conţină caractere gen punct, virgulă, e mult mai simplu să formatăm noi corect din script decât să obligăm utizatorul să corecteze o greşeală care poate nici nu-i din vină lui.

Selectorii de ţară sunt o pacoste şi ar trebui să fie îmbunătăţiţi mult. De ce să nu fie cele mai comune ţări primele în listă sau să introducem un câmp de căutare, care să filtreze ţăriile în timp ce utilizatorul completează acel câmp? Sunt multe soluții care pot ameliora calitatea selectorilor de ţară, Our core competencies include:

Product Strategy

Product Development

Product Support

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

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

www.3pillarglobal.com

www.todaysoftmag.ro | nr. 30/decembrie, 2014

29

programare Salveaza timpul utilizatorului cu o interfață bine proiectată tot ce trebuie să facem e să acordăm un pic mai multă atenţie lucrurilor mărunte.

Un lucru care trebuie luat în considerare este şi interacţiunea cu un formular pe dispozitivele mobile. Trebuie să ne gândim la controale alternative (swipe, pull, push etc.). Să fluidizăm un pic modul în care utilizatorul completează un formular. De nenumărate ori am văzut forumulare pe telefoane care sunt imposibil de completat.

Ar mai fi multe de zis la capitolul formulare, dar mă opresc aici, pentru că articolul ar deveni prea lung.

Interacţiunile repetitive

Trebuie să fim atenţi la interacţiuni elementare. Putem reduce o fracţiune de secundă din interacţiunile repetitive?

Căutarea în site de exemplu. E nevoit utilizatorul să dea click pe butonul de “Caută” sau funcţionează şi dacă apasă tasta “Return”? În primul rând nu ar trebui să apese pe butonul caută pentru a primi rezultatele. În zilele noastre majoritatea formularelor de căutare funcţionează în ambele moduri, dar doar pentru că butonul de “Caută” e în apropierea câmpului de căutare majoritatea utilizatoriilor sunt tentaţi să apese pe el.

Am început să neglijăm opţiunea de “Ţine-mă minte!” şi aceasta pentru că browser-ele moderne ne vin în ajutor, ceea ce nu-i tocmai un lucru rău. Totuşi ce facem dacă utilizatorul foloseşte un calculator public? Un răspuns relativ simplu ar fi: “Foloseşte sesiune privată!”. Sesiunile private în browser sunt ceva relativ nou, iar utilizatorii de ocazie nu sunt încă destul de familiarizaţi cu această opţiune.

Nav i g are a ş i me n iu r i l e d e t ip dropdown. De câte ori nu ne-au scos din minţi meniurile pe trei nivele şi cât de greu era să ajungi la ultimul nivel. Dacă ai mai mult de două nivele de dropdown, cu toate că şi două sunt un pic cam mult, e clar că nu faci ceva bine, iar ceea ce iniţial trebuia să fie simplu şi rapid se transformă într-un proces demn de abilităţile unui chirurg, unde precizia milimetrică e la ea acasă. În majoritatea cazurilor o navigare grea e principala cauză pentru care utilizatorii părăsesc site-ul.

texte, zone mult mai aerisite şi aşa mai departe încât să formatăm conţinutul întrun mod în care utilizatorii să îl scaneze şi să extragă informaţii esenţiale cât mai repede.

E foarte uşor să distragi atenţia utilizatorului de la ce-i important şi să-l duci în zone din care îl poţi pierde, de aceea trebuie să fim foarte atenţi la ce punem în jurul zonelor de interes. În procesul de design împart conținutul în trei zone: • Zona unu. Navigarea, câmpul de caută, zona de intră în conta şi cont, coş de cumpărături dacă e magazin online, lista de produse, lista de articole, lista de servicii şi uneori pagină de contact şi aşa mai departe.

• Zona doi. Informaţii utile, pagini secundare (despre noi, întrebări frecvente, ajutor, profile sociale, newsletter etc.)

• Zona trei de obicei e zona de footer, la care nu prea multă lume acordă atenţie.

Iau ca exempul un magazin online, care ca principală cale va alege produs, adaugă în coş, plăteşte. Cu cât procesul e mai complicat, cu atât utilizatorul pierde mai mult timp şi rapdarea îi scade rezultând în abandonarea comenzii.

Toate cele menţionate mai sus sunt doar o mică parte din problemele cu care utilizatorii se confruntă zi de zi, din cauza noastră, în căutarea lor după informație.

Am putea face mult mai multe în toate domeniile de pe web. De cele mai multe ori suntem conştienţi că pierdem timpul utilizatorilor, dar nu facem nimic împotriva, de aceea trebuie să fim vigilenţi și să ne întrebăm un lucru: “Cum aş putea salva puţin din timpul utilizatorului în această situaţie?”. Și mai ales să nu uităm ceea ce a spus Steve Jobs “Things don’t have to change the world to be important.”

Ajută utilizatorii să proceseze conţinutul mai rapid

Pierdem aşa mult din timpul utilizatorilor cu conţinut mult şi scris prost încât e imposibil că ei să găsească bucăţile de informaţie de care au nevoie. Pentru început am putea folosi mai bine titlurile, paragrafele, liste, citate, spaţii mari între

30

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

programare

programare

Design în loc de programare

Î

office@subsign.co Lead Graphic Designer @ Subsign

n ultima perioadă pe măsură ce web-ul devine tot mai divers, din ce în ce mai mulţi designeri având cunoştinţe tehnologice limitate reuşesc să contruiască site-uri reuşite.

Din start vrem să recunoaștem că designerii sunt total dependenţei de developer-i pentru a le aduce creaţiile la viaţă. Pe cont propriu mulţi dintre noi suntem buni la a crea un demo static sau o animaţie de bază dacă suntem norocoşi, dar aceasta nu înseamnă că este gata.

Astfel avem nevoie de un developer care să ne traducă designul în cod pe care orice device să îl înţeleagă și să îl execute oriunde în lume.

Cum comunică de multe ori designerii cu developer-ii? Designerii trimit o adunătură de imagini, site-uri exemplu, psd-uri încurcate și documentaţii incomplete. Odată începută faza de development apar inevitabil modificări la grafică sau la structura de bază. Această adunătură este ţinută împreună de întălniri scurte și de notițe superficiale, iar la sfârșitul proiectului toată lumea speră să semene cu ce a trimis designerul în primă fază.

Cu toţii suntem de acord că există un decalaj între designeri și developer. Nu am o soluţie simplă în această privinţa însă am câteva sfaturi căpătate de-a lungul timpului.

înţelege developerul care sunt aşteptările tale și ale clientului. O bună soluţie de a evita neînţelegerile este de a îi arăta developerului din start care îți este wireframe-ul și dacă ceea ce vrei tu să creezi este realizabil. Este cea mai bună perioadă să pui întrebări de genul: “Putem realiza acest lucru în bugetul stabilit?” sau “Vezi [introdu grija] ca fiind o problemă pentru respectarea deadline-ului?”

Generează un mock-up bun al design-ului tău

Înainte de a deschide Photoshop-ul structurează site-ul cu un grid adecvat pentru diferite rezoluţii și device-uri. Utilizarea unei lățimi de content a maxim 1080 de px este o bună modalitate de a fi sigur că îi vei face Fă-ți un plan solid Crearea unui plan este esenţială pentru viaţa mai uşoară developer-ului. Generarea a face website-uri de succes dar și pentru a unui grid este și o metodă mai uşoară pentru

www.todaysoftmag.ro | nr. 30/decembrie, 2014

31

programare Design în loc de programare ca el să observe lucrurile aliniate. Folosirea unui layout pe bază de grid este cea mai ușoară și cea mai bună modalitate de a obține un design “Pixel Perfect”.

Odată ce designul este gata, acesta poate fi modificat de client sau poate trece mai departe la faza de development unde este important să prevezi cum va arăta scalabil pe mobil, tabletă și desktop. Cum va fi afectat layout-ul tău dacă va mai fi adaugată o categorie, sau dacă clientul vrea să mai adauge încă 5 paragrafe de text. Toate aceste întrebări trebuie să aibă un răspuns înainte de a trimite proiectul la development.

Organizează PSD-ul în așa fel încât și alții să înțeleagă cu ce layer-e și grupuri să lucreze. O soluție bună este să îți grupezi layer-ele și să le dai numele pe care l-ar avea în web (Header, Footer, Content, Video, etc.) Fă tot posibilul ca fiecare element grafic să fie pe câte un layer separat, nu există nimic mai rău decât să încerci să separi două elemente de pe un singur layer. Toate aceste lucruri sună firesc dar micșorează substanțial durata de development dacă sunt organizate.

De asemenea este esenţial să ai și câteva imagini cu detalii (diferite stări ale butoanelor, meniurilor de hover, call to actionuri, etc.) O bună aplicaţie pentru a comunica feedback-uri pe imagine sau alte detalii este “Skitch”.

Învaţă funcționalitatea UI-ului tău.

Atunci când creezi elemente diferite cu funcționalități și animații speciale cel mai bine este să găseşti exemple sau să scrii documentaţii precise. Developer-ii nu pot (încă) să îți citească gândurile dacă le dai o imagine statică fără nici o notița sau fără demo.

32

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

Dă un feedback productiv.

Odată ce developer-ul și-a terminat treaba vor apărea revizii din partea ta sau a clientului. Foarte rar se întâmplă ca el să nimerească din prima revizie varianta finală așa că va trebui să îi prezinți cât se poate de clar și de specific ce modificări vrei să fie făcute. Pentru a evita orice fel de confuzie e recomandat să țineți cont de modificări prin versiuni. În concluzie, cu cât ești mai organizat cu atât iți va veni mai ușor să modifici și să îi faci pe alţii să îţi înţeleagă și aprecieze viziunea. Dacă ești nou în webdesign nu lăsa nici o oportunitate să treacă pe lângă tine. Întreabă-ți developer-ul cum poți să îi salvezi câteva ore și în același timp să faci lucruri cât mai inovatoare. Învată din greșelile tale pentru ca pe măsură ce avansezi, să te poți ține mai ușor de deadline-ul stabilit.

programare

TODAY SOFTWARE MAGAZINE

A fi sau a nu fi responsive

W

eb-ul este în mod implicit creat să răspundă nevoilor utilizatorilor. Noi suntem cei care l-au stricat în toți acești ani, plasând conținut în container-e de dimensiuni fixe - Andy Hume, “Responsive by default”, blog personal, iulie 2011

Pe măsură ce designul site-urilor într-o manieră sensibilă la nevoile utilizatorului devine o necesitate în ultima vreme, trebuie să ne reamintim că nu există o soluție universal corectă pentru nimic, nici măcar pentru web design. Deși poate constitui o funcționalitate atractivă pentru utilizator, se poate dovedi a fi un dezavantaj dacă nu e folosit așa cum trebuie. În acest articol propun o analiză a ceea ce semnifică responsive web design: cum ar trebui aplicat, când ar trebui aplicat și cel mai important: când trebuie evitat.

Ce este Web Design-ul Responsive

Importanța nivelului de prezentare se justifică prin implicarea în interacțiunea cu utilizatorul; este ceea ce user-ul final vede după toate procesările aplicației; prezentarea trebuie să se ridice la nivelul complexității aplicației. Trebuie să fie simplu și intuitiv, chiar dacă sistemul este unul complex, deoarece utilizatorului nu-i pasă de cât de încărcat este sistemul sau de cât de elaborată e structura sa; dorința lui este de a naviga în aplicație cât se poate de direct și de rapid. În ceea ce privește aplicațiile web, interfața este conținutul redat de browser. Conținutul poate fi static, dinamic, dar în general este o combinație a acestor două. Sunt multe provocări pe care le implică dezvoltarea aplicațiilor web, datorită numeroaselor tipuri și versiuni de browser-e, multe dintre ele având particularități și excepții. Nu există un număr corect de principii de luat în calcul când se realizează interfața sau designul unui produs software, dar există unul central: simplicitatea.

Figura 1 – Exemplu de layout responsive pe un monitor, tabletă și telefon mobil

Un aspect important al stilizării conținutului web este verificarea pe mai multe browser-e și scrierea de cod concis, care este în același timp și specific și generic și care se afișează bine în cât mai multe dispozitive de redare posibil [Cod09].

Se poate folosi CSS pentru a afișa documentul diferit în funcție de dimensiunea ecranului sau în funcție de dispozitivul de pe care este vizualizat. Scrierea de cod în acest sens e cunoscută sub numele de design web responsive. Scopul este de a realiza site-uri care oferă o experiență vizuală optimă, independent de dimensiunea display-ului folosit. În plus, navigarea trebuie să poată fi făcută cu un minim de redimensionări, zoom-uri sau scroll-uri (preferabil fără nici una din aceste acțiuni).

Un website cu design responsive se adaptează layout-ului mediului în care e vizualizat (după cum se poate vedea în Figura 1) folosind grile fluide, imagini flexibile [Mar11] și media queryuri CSS3. Explicat simplu, media query-urile sunt „clauze IF” pentru browser-ul care redă pagina: browser-ul știe că unele stiluri trebuie aplicate doar atunci când o condiție e îndeplinită (de obicei condiția are legătură cu lățimea ecranului).

A fi sau a nu fi responsive? - aceasta este întrebarea

Principala dilemă cu acest concept este că designerii și dezvoltatorii definesc termenul „responsive” diferit, aspect care duce la probleme de comunicare1. Să reactualizăm prima definiție a termenului din în 20102: Ethan Marcotte l-a definit ca un concept care oferă o experiență vizuală optimă pe o varietate largă de dispozitive folosind trei tehnici: grile fluide, imagini flexibile și interogări media (media query-uri).

Trebuie să înțelegem că principalul scop al experienței web mobile este de a fi rapidă și de a oferi o experiență compatibilă pe toate dispozitivele precum și faptul că majoritatea site-urilor eșuează la prima parte a acestei afirmații: la capitolul performanță.

Web design-ul responsive nu a avut menirea de a rezolva problemele de performanță, motiv pentru care nu poate fi învinuită tehnica. O nouă mișcare apărută recent, numită de unii „web design responsive responsabil”, propune ca designul responsive să nu fie folosit ca unică soluție pentru dispozitivele mobile, ci folosit împreună cu alte tehnici, precum încărcarea condițională sau comportamentul responsive în conformitate cu un grup de dispozitive.

1

“What we mean when we say responsive”, Lyza Danger Gardner, A List Apart, 2014

2

“Responsive web design”, Ethan Marcotte, A List Apart, 2010

www.todaysoftmag.ro | nr. 30/decembrie, 2014

33

programare A fi sau a nu fi responsive Încărcarea condițională a resurselor

Media query-urile sunt de obicei fie stocate într-un singur fișier CSS cu mai multe declarații @media, fie în mai multe fișiere CSS legate de pagina principală prin atribute media (ex. <link rel=”stylesheet” href=”mobile.css” media=”(max-width: 480px)”>).

Cu toate că majoritatea tutorialelor și site-urilor folosesc prima tehnică, aceasta este greșită. În plus, unii consideră că folosind a doua opțiune fiecare dispozitiv încarcă numai fișierul CSS corespunzător rezoluției sale - ceea de asemenea este greșit.

Ambele tehnici sunt greșite din punct de vedere al performanței, deoarece forțează browser-ul să descarce tot conținutul CSS posibil și să-l traverseze pentru a ști ce stiluri să aplice. Acest lucru afectează performanța deoarece browser-ele mobile, pe lângă faptul că sunt mai încete, sunt nevoite să încarce și stiluri CSS destinate doar pentru rezoluții mari (desktop), iar în plus CSS-ul blochează redarea (rendering).

O soluție pentru încărcarea condițională a resurselor este înlocuirea media query-urilor cu query-uri Javascript matchMedia queries și încărcarea numai a stilurilor gândite a fi folosite pe rezoluția respectivă. Instrumente precum Modernizr ajută prin detectarea funcționaltăților și particularităților dispozitivelor prin metode ce nu depind doar de rezoluție.

nu vor fi mulțumiți fără un website de mare performanță [Fri14].

Păstrând proaspete aceste informații, încheiem într-o notă veselă cu un citat din Brad Frost: “Pe vizitatorii tăi îi doare în cot dacă site-ul tău e sau nu responsive”4. Ei în general nu vor face resize la browser și nici nu-i interesează ce înseamnă responsive.

Ei vor ceva rapid și ușor de folosit.

Bibliografie [Cod09] - Ivan Codesido, What is frond-end development, The Guardian, septembrie 2009 [Fri14] - Maximiliano Firtman, You May Be Losing Users If Responsive Web Design Is Your Only Mobile Strategy, Smashing Magazine, iulie 2014 [Mar11] - Ethan Marcotte, Flexible Images, A List Apart 328, iunie 2011

4

“Responsive Web Design: Missing the Point”, Brad Frost, blog personal, 2013

Cum dezvolt responsive?

Nu există o soluție concretă pentru web design responsive (încă), dar sunt câteva trucuri care ajută la sporirea performanței atunci când se dezvoltă soluții responsive: • urmărește o abordare „mobile-first” - acest aspect este extrem de important. Gândește-te la performanța dispozitivelor mobile când dezvolți sau refaci un site.

• încarcă doar codul Javascript și stilurile necesare rezoluției dispozitivului curent folosind încărcare condițională.

• expune imaginile responsive prin Javascript, până ce apare o metodă mai bună.

• furnizează documentele tuturor dispozitivelor prin același URL și având același conținut, dar cu structuri diferite.

• testează ce se întâmplă pe dispozitive reale (nu doar prin resize la browser), preferabil pe conexiuni mobile slabe.

Concluzii

Răspunsul este da, ar trebui să fim responsive când vine vorba de a face design și de a dezvolta site-uri, însă metodele de realizare trebuie schimbate. Caracterul responsive este important în special datorită creșterii exponențiale a utilizatorilor mobili, care încet dar sigur îi vor depăși pe cei desktop în anii ce urmează.

Răspunsul însă depinde mult de natura conținutului: dacă e prea mult conținut ce trebuie afișat pe un telefon de exemplu, o soluție mai bună ar fi păstrarea unei versiuni simplificate a siteului pe mobil și crearea unei aplicații native pentru a oferi toate funcționalitățile sistemului complex (un exemplu în acest sens sunt băncile, care în general oferă aplicații native pentru managementul conturilor personale). A depinde de un website responsive versus de o aplicație mobilă e mai mult o decizie de business3 decât una tehnică. Țelul suprem al unui site ar trebui să fie „utilizatori fericiți” și nu „a fi responsive”. Când scopul este cunoscut, poți decide ce instrumente și tehnici să folosești pentru a-l atinge. Utilizatorii 3

“Responsive Website or Mobile App: Do You Need Both?”, Rahul Varshneya,

Entrepreneur, 2014

34

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

Raul Rene Lepsa raul.lepsa@3pillarglobal.com UI Developer @ SF AppWorks

programare

TODAY SOFTWARE MAGAZINE

Promisiunile JDK 9: O scrisoare pentru Moș Crăciun?!

I

arna este anotimpul propice pentru vise. Vremea când copii de toate vârstele aștern în gânduri sau pe hârtie scrisori către Moș Crăciun. Se pare că în acest an, atitudinea aceasta a fost contagioasă și s-a transmis și echipei din spatele JDK 9 care și-a așternut pe foile WWW-ului gândurile cu referire la JEP-urile ce vor deveni (sperăm!!!) la începutul lui 2016 realitate. Desigur, dacă luăm în considerare vorba românească,socoteala de-a acasă nu-i la fel cu cea din târg, lista aceasta poate suferi scurtări, corecturi și adăugiri. Dar e momentul să fim optimiști.

De luat în seamă este faptul că lista este într-o continuă evoluție.

JEP 1021 - Actualizarea API-ului pentru manipularea proceselor Acei dintre voi care l-au necăjit pe moș au fost destul de „norocoși” și au lucrat cu API-ul din Java pentru manipularea proceselor.Imaginația v-a ajutat să ocoliți limitările lui. Începând cu JDK 8, acest API a primit îmbunătățiri, direcția fiind urmată. Astfel acest JEP promite să aducă următoarele abilități API-ului: • extragerea numărului de identificare al procesului și lista proceselor create de acest API; • posibilitatea de a numi și de a extrage numele mașinii virtuale Java pe care rulează programul; • posibilitatea de a enumera mașinile virtuale Java și procesele sistemului; • posibilitatea de a manipula arbori de procese, mai ales posibilitatea de a opri execuția unor astfel de arbori; • posibilitatea de a gestiona sute de sub proces.

JEP 1432 - Îmbunătățirea sincronizării

Evangheliștii performanței pentru aplicații Java, consideră că performanța unei aplicații Java poate fi foarte eficient îmbunătățită prin micșorarea pe cât posibil a concurenței și implicit a blocurilor de sincronizare. Dacă JDK 9 va conține următoarele modificări, importanța acestei reguli va fi cu siguranță diminuată:

• reordonarea câmpurilor la nivel de JVM și alinierea cache-urilor; • îmbunătățirea performanței apelurilor metodei PlatformEvent::unpark(); • performanță îmbunătățită pentru intrarea în blocurile de sincronizare; • performanță îmbunătățită pentru ieșirea din blocurile de sincronizare; • performanță îmbunătățită pentru apelurile metodelor notify și notifyAll

JEP 1583 - Logare unificată pentru JVM

Titlul acestui JEP este cât se poate de explicit. Acei dintre voi ce au avut de-a face cu aplicații complexe Java, cu siguranță v-ați ciocnit o dată sau de două ori de loguri ale colectorului de gunoi al mașinii virtuale Java. Nu știu voi, dar pe mine m-a făcut să mă scarpin în creștet cantitatea de informație ce am găsit-o în acele log-uri.

Mai fain, a fost momentul post migrare între versiuni java, moment în care îți dai seama că log-ul din noua versiune nu prea mai seamăna cu cel din versiunea anterioară, iar orice încercare de-a fi automizat procesul este rapid executată. Dar, să ne concentrăm pe îmbunătățirile aduse de noua versiune cu promisiunea ca după ce noua versiune va fi disponibilă, ne om tângui că înainte era mai bine.

Se pare că JDK încearcă să se alinieze cel puțin din punct de vedere estetic cu alte librării de logare Java (precum log4j).

Deci, vom avea diferite nivele de criticitate pe care vom putea loga informația (eroare, avertisment, informativ, detaliat, extrem de detaliat). Pentru a nu afecta

performanța aplicațiilor aflate în medii de producție, JEP-ul vine cu directive menite să crească performanța. Astfel nivelele corespunzătoare erorilor și avertismentelor nu ar trebui să afecteze performanța aplicațiilor, mai ales că celelalte nivele nu au constrângeri din această perspectivă. O linie de log inițială ar putea arăta: [gc][info][6.456s] Old collection complete

Pentru a asigura flexibilitatea mecanismului de logare, acesta va putea fi adaptat prin parametrii mașinii virtuale Java, intenția fiind să existe o abordare unificată în această direcție. Pentru a oferi conformitate cu parametrii versiunilor anterioare, aceștia vor fi echivalați cu noii parametri ori de câte ori este posibil.

Pentru a fi cât se poate de potrivit pentru aplicațiile în execuție, configurarea logurilor poate fi modificată prin apeluri prin intermediul jcmd-ului sau MBean-urilor.

Desigur, implementarea acestui JEP nu înseamnă că logurile existente vor fi automat mai lizibile - scopul acestui JEP este doar de a oferi mecanismele prin care logurile pot fi mai facil de citit nu și schimbarea manierei în care diferitele librării scriu în loguri.

JEP 1654 - Controlul compilatorului

Cum probabil știți, platforma Java folosește compilare instantă pentru asigurarea execuției optimă a aplicațiilor. În acest moment există două compilatoare în cadrul platformei Java, denumite

1 http://openjdk.java.net/jeps/102 2 http://openjdk.java.net/jeps/143

3 http://openjdk.java.net/jeps/158

4 http://openjdk.java.net/jeps/165

www.todaysoftmag.ro | nr. 30/decembrie, 2014

35

programare Promisiunile JDK 9: O scrisoare pentru Moș Crăciun?! foarte intuitiv C1 și C2. Ele corespund parametrilor -client compilării la nivelul secțiunii de import respectiv -server ai mașinii virtuale Java. Scopul acestui JEP este Odată cu integrarea acestui JEP numărul de avertismente din îmbunătățirea controlului(până la nivel de metodă) asupra aces- secțiunile de import a claselor, va descrește. Motivul principal tor compilatoare. Mai precis posibilitatea de a schimba opțiunile fiind curățarea claselor din această perspectivă. în timpul execuției, desigur totul fără înrăutățirea performanței.

JEP 197 - Cache pentru cod segmentat 5

Se pare că îmbunătățirea performanței este una dintre țintele Java 9, luând în vedere că și acest JEP are ca țintă îmbunătățirea performanței prin: • separarea ariilor rezervate codului generat pentru metode sau codului măsurat; • timp de curățare a gunoiului la nivel de mașină virtuală îmbunătățit prin folosirea iteratorilor specializați ce scurtcircuitează ariile de memorie intangibile; • control îmbunătățit al amprentei memoriei mașinii virtuale; • descreșterea fragmentării codului optimizat; • îmbunătățirea localizării codului considerând că diferite secțiuni de cod asemănătoare vor fi accesate în momente de timp apropiate; • comportament mai performant pentru iTBL și iCache; • formarea unei baze pentru extensii ulterioare; • îmbunătățirea controlului asupra codului eterogen.

JEP 1986 - API pentru JSON

Luând în considerare omniprezența JSON-ului, acest JEP nu este surprinzător. Surprinzător din punctul meu de vedere este că nu a fost disponibil mai devreme, mai ales că JSON a înlocuit XML-ul ca principală manieră de a exprima datele. Țintele acestui JEP sunt următoarele: • capacitatea de a parcurge și genera documente JSON bazându-te pe standardul JSON RFC7159; • funcționalitatea este adaptată nevoilor programatorilor; • parcurgerea bazată pe evenimente sau fluxuri de date; • subset al API-ului pentru profilele ME și compacte; • API imutabil pe principiul constructorului de obiecte.

JEP 21910 - Securitate pentru transportul datagramelor

Numărul crescut de protocoale ce folosesc UDP (precum SIP) au crescut îngrijorarea când vine vorba de securitate. Având în vedere că protocoale precum TLS au nevoie de protocoale garantate (precum TCP), este nevoie de implementarea protocolului de securitate DTLS în versiunea 1.0 (RFC 4347) și 1.2 (RFC 6347).

JEP 22011 - Imagini de execuție modulare

Acest JEP vine ca o completare naturală a JEP 201, cu intenția clară de a restructura structura JDK-ului și a mediului de execuție java astfel încât să poată găzdui module și să îmbunătățească performanța, securitatea și mentenanța.

JEP 22412 - Adaptarea documentației Java la standardul HTML 5 JEP 23113 - Renunțarea la posibilitatea de a selecta versiunea în timpului execuției unei aplicații Java Îndepărtarea posibilității de a cere (folosind -version) versiunea Java pentru o aplicație JRE pornită va fi efectuată în două etape: prima, afișarea unui avertisment în versiunea 9 a Java și a doua etapă, renunțarea completă la această posibilitate începând cu Java 10 și aruncarea unei exepții.

Cam așa arată lista JEP pe baza cărora se va construi JDK 9. Să vă spun sincer, deși schimbările nu sunt cele mai revoluționare, eu sunt nerăbdător să văd noua versiune. Având în vedere că e destul de lucru, eu vă încurajez să implicați în implementarea Java 9.

Acest articol face parte din seria Java Advent Calendar, mai multe articole din serie pe www.javaadvent.com.

Calendarul Java pentru Advent este o inițiativă clujeană de a Desigur, JDK-ul va fi aliniat cu JSR 353 și de asemenea adaptarea la stilul de programare impus de JDK 8 prin adăugirea întâmpina Crăciunul în fiecare an (începând cu 2012) cu o suită de articole tehnice legate de Java sau JVM. Aceste articole sunt lambda și a fluxurilor de date. publicate în intervalul 1-24 Decembrie pe www.javaadvent.com, 7 ulterior fiind promovate pe diverse site-uri de specialitate. Până JEP 199 - Compilare inteligentă, faza a II-a în acest moment, grupul contribuitorilor a fost unul internațional sjavac este un utilitar care extinde capacitățile deja faimosului javac. Noul utilitar are ca intenție performanțe îmbunătățite cu participanți din toată lumea. Un Crăciun fericit și vă așteptăm pentru proiectele de mărime considerabile, primul scop al acestui alături de noi ca voluntar,cititor sau contribuitor sau chiar și toate JEP fiind oferirea posibilității de a compila proiectul JDK folosind trei simultan. sjavac. Mai mult oferirea posibilității de a compila și alte proiecte mari folosind sjavac.

JEP 2018 - Cod sursă modular

Primii pași în această direcție au fost făcuți pentru implementarea proiectului jigsaw, având ca scop final reorganizarea codului sursă ca module extinzând capacitățile utilitarelor de compilare la a construi module și la a respecta limita modulelor.

JEP 2119 - Renunțarea la avertismentele din timpul

olimpiu.pop@ullink.com Senior Software Developer @ Ullink CoOrganizer @ Java Advent

10 http://openjdk.java.net/jeps/219

5 http://openjdk.java.net/jeps/197

11 http://openjdk.java.net/jeps/220

6 http://openjdk.java.net/jeps/198

12 http://openjdk.java.net/jeps/224

7 http://openjdk.java.net/jeps/199

13 http://openjdk.java.net/jeps/231

8 http://openjdk.java.net/jeps/201 9 http://openjdk.java.net/jeps/211

36

Olimpiu Pop

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

programare

programare

Machine Learning la modul practic

C

Sergiu Indrie

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

onsider că software de calitate înseamnă a face viața utilizatorului cât de ușoară posibil. Această calitate nu constă doar în îndeplinirea sarcinii în mod corect și eficient, dar și în simplificarea operaţiei fără a pierde funcționalitate. Foarte multe din sarcinile noastre zilnice ar putea fi simplificate dacă software-ul nostru ar fi capabil să facă sugestii, să încerce să ghicească și să automatizeze munca noastră. Aceasta este o posibilă utilizare pentru tehnicile machine learning. Pe lângă aceasta, aplicaţii precum motoare de căutare web, sisteme de recunoaștere a imaginilor și a sunetelor, detectarea spam-ului și multe altele folosesc machine learning pentru a soluționa probleme care altfel ar fi aproape irezolvabile.

Explicația

Cu toate că machine learning poate apărea ca o tehnică complexă și grea de aplicat, asemănător cu toate conceptele din domeniul calculatoarelor, totul se rezumă la secvențe de 1 și 0 (poate chiar mai mult ca de obicei). Principiul de bază din spatele acestei idei este matematică simplă.

Dacă vreau să determin gradul de asemănare dintre două elemente complexe, dar definirea declarativă a unor funcții de comparare este mult prea dificilă, atunci voi transforma elementele complexe în numere și voi lăsa calculatorul să determine similitudinea lor.

id_utilizator

oraș

Vârstă

1

1

32

2

2

40

3

3

41

Exemplu Avem o bază de utilizatori cu următoarele informații: id_utilizator

Oraș

Vârstă

Hobby

1

Londra

32

Tehnologia

2

Paris

40

Plante

3

Kansas

41

<gol>

Dorim să oferim utilizatorilor similari conținut asemănător despre hobby-uri (ideea fiind că oamenii asemănători preferă lucruri similare). Astfel, prin transformarea datelor de intrare în date numerice (în mod manual sau automat) ca în tabelul următor:

putem să trasăm următorul grafic: Pe baza graficului putem observa faptul că cele două puncte din partea superioară sunt mai apropiate (mai ales dacă atribuim greutăți caracteristicilor importante).

Acestă apropiere a punctelor indică asemănarea utilizatorilor (utilizatorii cu id-ul 2 și 3). În acest caz, această asemănare este dată de valorile apropiate ale vârstei.

Determinarea acestei asemănări în mod matematic s-ar realiza prin calcularea distanței dintre cele 2 puncte, o funcție similară cu distanța Euclidiană dar cu parametri de greutate:

www.todaysoftmag.ro | nr. 30/decembrie, 2014

37

programare Machine Learning la modul practic

unde u și v sunt doi vectori, reprezentând 2 puncte (elemente), iar fiecare vector este compus din 2 valori, vârstă și oraș (uage, ucity) ; iar uage și ucity reprezintă greutățile celor 2 atribute, vârstă și oraș.

Cu ajutorul a numeroase exemple pozitive și negative (training data), algoritmul se poate ajusta astfel încât să determine în mod corect asemănarea a două elemente.

începe cu numărul 2, indicând 2 apariții ale cuvântului “Eu”).

Pentru a simplifica această aplicație vom folosi un model parțial bag-of-words. Vom defini un dicționar care va conține doar un cuvânt cheie relevant pentru fiecare categorie. cuvânt

index categorie

categorie

tată

1

Principal

felicitări

2

Social

Trei utilizări importante pentru machine learning care utili- reducere 3 Promoții zează principiul de mai sus sunt: 1. Recomandări - analizează preferințele unui utilizator și alertă 4 Noutăți ,pe baza asemănării dintre utilizatori, oferă sugestii privind potențiale preferințe noi. grup 5 Forum 2. Clustering - grupează elemente similare (nu necesită training data explicit).

Folosind dicționarul de mai sus vom reprezenta următorul 3. Clasificare - atribuie categorii elementelor pe baza atribu- e-mail: irilor anterioare.

Salut tată. Să nu uiți să mă iei de la grădiniță. A și tată, să nu întârzii! în următorul vector de cuvinte: Exemplificarea aplicației Una din cele mai populare librării de machine learning în Java 2, 0, 0, 0, 0 este Weka. Vom folosi API-urile Weka pentru a scrie un simplu program de clasificare machine learning.

Cod Weka Dorim să replicăm funcționalitatea Gmail Priority Inbox în Pentru a începe să scriem programul folosind API-ul Weka, în aplicația desktop de e-mail Geary, astfel încât la recepționarea unui prima fază trebuie să definim formatul de date. Vom începe prin nou e-mail, vom putea determina în mod automat apartenența a descrie un rând de date. acestuia la una din cele cinci categorii: Principal, Social, Promoții, // create the 5 numeric attributes corresponding to // the 5 category keywords Noutăți și Forum.

Reprezentarea datelor

Primul pas este reprezentarea datelor. Definirea celor 5 categorii este simplă, vom folosi un index de la 1 la 5. Codificarea conținutului unui e-mail este puțin mai dificilă. În acest gen de probleme, soluția este de obicei reprezentarea unui segment de text prin utilizarea modelului bag-of-words. Ideea din spatele acestui model este ilustrarea segmentului de text printr-un vector de numărare a cuvintelor.

Să luăm următoarele enunțuri: 1. Eu mănânc mere.

2. Eu mănânc. Eu programez.

Utilizând cele două texte de mai sus, putem crea un dicționar comun atribuind indecși fiecărui cuvânt unic.

Eu

1

mănânc

2

mere

3

programez

4

Astfel putem obține următoarele reprezentări ale celor două segmente de text:

Attribute dadCount = new Attribute(„dad”); Attribute congratulateCount = new Attribute(„congratulate”); Attribute discountCount = new Attribute(„discount”); Attribute reminderCount = new Attribute(„reminder”); Attribute groupCount = new Attribute(„group”);

Fiecare rând trebuie să fie asociat cu una din cele 5 categorii, astfel continuăm cu definirea atributului pentru categorie. // Declare the class/category attribute along with // its values FastVector categories = new FastVector(5); categories.addElement(„1”); categories.addElement(„2”); categories.addElement(„3”); categories.addElement(„4”); categories.addElement(„5”); Attribute category = new Attribute(„category”, categories);

În final colectăm toate atributele într-un vector de atribute. // Declare the feature vector (the definition of one data row) FastVector rowDefinition = new FastVector(6); rowDefinition.addElement(dadCount); rowDefinition.addElement(congratulateCount); rowDefinition.addElement(discountCount); rowDefinition.addElement(reminderCount); rowDefinition.addElement(groupCount); rowDefinition.addElement(category);

Training Data

Algoritmii de clasificare de tip machine learning necesita date de antrenament pentru ajustarea parametrillor interni cu scopul de a oferi cele mai bune rezultate. În scenariul nostru, trebuie să Fiecare număr din vectorii de mai sus indică numărul de oferim programului exemple de categorizări a e-mail-urilor.

Pentru scopul acestui program vom genera training data prin apariții ale cuvântului cu acel index în dicționar. (Al 2-lea vector 1, 1, 1, 0 2, 1, 0, 1

38

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

utilizarea clasei de mai jos: public class TrainingDataCreator { public static void main(String[] args) throws IOException { ICombinatoricsVector<String> valuesVector = Factory.createVector(new String[]{„0”, „1”, „2”, „3”, „4”}); Generator<String> gen = Factory. createPermutationWithRepetitionGenerator( valuesVector, 5); File f = new File( „category-training-data.csv”); FileOutputStream stream = FileUtils. openOutputStream(f); for (ICombinatoricsVector<String> perm : gen) { if (Math.random() < 0.3) { // restrict the training set size String match = determineMatch(perm.getVector()); // first highest count wins String features = StringUtils. join(perm.getVector(), „,”); IOUtils.write(String.format(„%s,%s\n”, features, match), stream); } } }

}

stream.close();

Clasa TrainingDataCreator folosește permutări pentru a genera toate rândurile de antrenament cu numărul maxim de apariții 4 (numărul de apariții al fiecărui cuvânt variază de la 0 la 4). Deoarece dorim ca acesta să fie un set de date de antrenament real, vom folosi doar 30% din permutări. De asemenea, dorim ca algoritmul de clasificare să poată extrage o logică de atribuire a categoriilor din aceste date, astfel că vom asigna pentru fiecare rând generat de date prima categorie cu cel mai mare număr de apariții (ex. Pentru vectorul de cuvinte tată=2, felicitări=3, reducere=0, alertă=1, grup=3; felicitări este primul cuvânt cu numărul cel mai mare de apariții, 3).

Fișierul generat va conține linii precum: 3,1,1,0,0,1 4,1,1,0,0,1 3,3,2,4,1,4

trainingRow.setValue((Attribute) rowDefinition. elementAt(2), Integer.valueOf(values[2])); trainingRow.setValue((Attribute) rowDefinition. elementAt(3), Integer.valueOf(values[3])); trainingRow.setValue((Attribute) rowDefinition. elementAt(4), Integer.valueOf(values[4])); trainingRow.setValue((Attribute) rowDefinition. elementAt(5), values[5]); // add the instance trainingSet.add(trainingRow);

Următorul pas este construcția clasificatorului utilizând setul generat de date. // Create a naïve bayes classifier Classifier cModel = new NaiveBayes(); cModel.buildClassifier(trainingSet);

Pentru a testa algoritmul nostru de clasificare, să zicem că am primit un e-mail care conține cuvântul tată de 5 ori, iar restul cuvintelor cheie au 0 apariții. (Observăm faptul că setul de date de antrenament conține numărul maxim de apariții 4, obligând clasificatorul să extrapoleze pentru a determina categoria corectă, și anume, 1 - Principal) // Create the test instance Instance incomingEmail = new Instance(6); incomingEmail.setValue((Attribute) rowDefinition. elementAt(0), 5); incomingEmail.setValue((Attribute) rowDefinition. elementAt(1), 0); incomingEmail.setValue((Attribute) rowDefinition. elementAt(2), 0); incomingEmail.setValue((Attribute) rowDefinition. elementAt(3), 0); incomingEmail.setValue((Attribute) rowDefinition. elementAt(4), 0); incomingEmail.setDataset(trainingSet); // inherits format rules double prediction = cModel.classifyInstance( incomingEmail); System.out.println(trainingSet.classAttribute(). value((int) prediction));

Codul de mai sus va afișa 1, adică categoria Principal.

Câteva exemple de date de test sunt prezente în tabelul de mai jos: vector de intrare

Rezultat

Acum că am generat datele de antrenament, trebuie să antrenăm clasificatorul. Începem prin a crea setul de date de antrenament.

0, 0, 0, 5, 0

4

0, 5, 0, 5, 0

2

// Create an empty training set and set the class (category) index Instances trainingSet = new Instances(„Training”, rowDefinition, TRAINING_SET_SIZE); trainingSet.setClassIndex(5);

7, 1, 0, 4, 9

1 – greșit

După cum putem vedea, acuratețea de predicție nu este niciodata 100%, dar prin ajustarea parametrilor algoritmilor și selecția addInstances(rowDefinition, trainingSet, „categoryatentă a atributelor din vectorul de date, precum și datele de training-data.csv”); antrenament, se poate obține o rată mare de corectitudine.

Weka oferă API-uri pentru a evalua soluțiile implementate. În interiorul metodei addInstances vom citi fișierul CSV și vom crea un obiect de tip Instance pentru fiecare rând din fișierul Prin crearea a două seturi de date, setul de date inițial conținând 30% din permutări și un al 2-lea set conținând toate permutările CSV, care va reprezenta o atribuire de categorie unui e-mail. pentru numărul de apariții maxim 4; și utilizarea clasei Evaluation // Create the instance obținem o rată de corectitudine de 95%.

Instance trainingRow = new Instance(6); trainingRow.setValue((Attribute) rowDefinition. elementAt(0), Integer.valueOf(values[0])); trainingRow.setValue((Attribute) rowDefinition. elementAt(1), Integer.valueOf(values[1]));

// Test the model Evaluation eTest = new Evaluation(trainingSet); eTest.evaluateModel(cModel, testSet); www.todaysoftmag.ro | nr. 30/decembrie, 2014

39

programare Machine Learning la modul practic System.out.println(eTest.pctCorrect());

Concluzie

Codul de mai sus a fost scris folosind Weka deoarece am considerat că API-urile expuse sunt mai ușor de folosit și de înțeles comparativ cu o altă librărie comună de machine learning, Apache Mahout. Dacă aveți un scenariu care acceptă o rată de acuratețe mai mică de 100% și există posibilitatea construcției de date de antrenament, avantajele pot depăși costurile. În ceea ce privește performanța, am rulat teste care indică faptul că prin alegerea celui mai performant algoritm pentru setul de date, se pot obține timpi de antrenament de sub o secundă pentru 28000 de rânduri de antrenament (5 atribute + categorie) și timpi similari de predicție pentru 1000 de rânduri de date.

Machine Learning are un mare potențial pentru a fi utilizat în toate domeniile software (chiar și aplicații mobile), și după cum am văzut în exemplul de mai sus, nu trebuie să fii un matematician pentru a folosi uneltele existente. Să înceapă învățarea!

Bibliografie 1.

2.

3.

4.

5.

6.

7.

40

http://architects.dzone.com/articles/machine-learning-measuring http://en.wikipedia.org/wiki/Bag-of-words_model http://www.cs.waikato.ac.nz/ml/weka/ https://github.com/rjmarsan/Weka-for-Android https://github.com/fgarcialainez/ML4iOS Introduction to Machine Learning, by Alex Smola, S.V.N. Vishwanathan Mahout in Action, by Sean Owen, Robin Anil, Ted Dunning, Ellen Friedman

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

programare

TODAY SOFTWARE MAGAZINE

Mai mult decât software

C

ele mai mari succese în business coincid cu statutul de a fi în vârful ierarhiei pieței, după ce ai făcut față unora dintre cele mai mari provocări precum abilitatea de a dejuca planurile adversarilor direcți și adaptabilitatea cât mai rapidă la condiții noi. Domeniul cel mai tehnologic oferă atât povești de succes cât și eșecuri. Prima mare rețea de socializare, Friendster, a fost “păcălită” de către cei de la Myspace, care la rândul lor au fost “păcăliți” de cei de la Facebook. Netscape au fost “păcăliți” de cei de la Yahoo!, care la rândul lor au fost “păcăliți” de cei de la Google. Cu toții știm că aceste situații nu se termină aici, și, undeva, într-un subsol sau garaj, cineva lucrează la următorul “big thing” care ar putea deveni cel mai mare actor pe piață.

Toate companiile mici și mijlocii doresc să crească într-un timp foarte scurt, să devină tot mai complexe în organizare și să poată să manevreze cât mai ușor situațiile neașteptate, pentru a putea să reacționeze cât mai ușor la cererile clienților din piață.

Este foarte important să se poată adapta cât mai repede și cât mai ușor la schimbările propuse și impuse de către clienții din piață.

De fapt, singura variabilă constantă rămâne schimbarea. Cu cât reușim mai repede să ne adaptăm, cu atât vom avea mai mult timp să progresăm, reușind să furnizăm servicii premium la timp.

Cu permisiunea dumneavoastră, pentru a simplifica și mai mult traducerea și interpretarea pe mai departe, aș dori să considerăm următoarea convenție, în cazul celor doi termeni din limba engleză - outcome și output – utilizați în rândurile următoare: Output – un produs/rezultat finit așteptat și agreat de beneficiar; Outcome – un produs/rezultat finit care adaugă valoare mare la beneficiar mergând spre zona de satisfacție mare .

Ce-ar putea schimba și ne-ar putea diferenția de alții?

Este suficient doar să livrăm ceva anume?

Care este diferența între un output și un outcome?

Există o distincție clară între cele două?

Mulți dintre noi ar crede sau ar considera, la prima vedere, că întrebările sunt mai mult retorice sau că nu ar exista nici o diferență relevantă între cei doi termeni.

Am putea da ca exemplu, diferența dintre mediocritate și a unui lucru care ar putea dura și ar aduce valoare în timp. Multe dintre companii sunt marcate de faptul că deciziile sunt luate pe baza lucrurilor care nu aduc neapărat valoare (output), în timp ce organizațiile mari încearcă să facă acest lucru luând în considerare, pe cât posibil, rezultatele care aduc și valoare mare în timp pentru clienți (outcome).

Dacă considerăm un simplu rezultat ca fiind extrinsec, și acele rezultate care aduc valoare adăugată clienților ca fiind intrinseci, cred că ar merita un efort în plus pentru a încerca să înțelegem mai bine semnificația fiecăruia dintre acestea.

În general, companiile măsoară succesul în termeni ca venituri și economii, ceea ce nu este cu nimic greșit, fiind chiar o practică comuna sau recomandată. Dar privind doar din această perspectivă, se omite interesul legat de motivul pentru care se face ceea ce se face. Se evită de fapt interesul pentru a înțelege ce dorește cu adevărat clientul și ce anume poate să-i aducă lui cu adevărat valoare. Dar pentru a găsi răspunsuri la aceste gen de întrebări și frământări, este nevoie de foarte multă colaborare, context favorabil, înțelegere între părți și respectarea principiilor agile de bază.

Din păcate, multe dintre companiile de outsourcing actuale, pun mai multă valoare pe “output” decât pe “outcome”. Practic, se pune accentul mai mult pe volum decât pe calitate. Tendința actuală este de a măsura cât de repede putem să satisfacem cerințele clientului. Sugestiv în acest sens este cazul echipelor agile unde se pune un accent deosebit pe indicatori de performanță ca număr total de “stories” finalizat sau număr total de “story points” finalizat pe durata unui interval de timp (vezi “sprint/iteration”). Un alt exemplu, în cazul echipelor “Lean”, se folosesc indicatori de performanță ca “cycle time” și/sau “lead time”. Practic, ideea de “output” conține numărul de linii de cod scris, numărul total de funcționalități finalizate.

Mulți reprezentanți marcanți în lumea Agile cred cu ardoare că merită investit timp în a găsi variante care să dea o nouă dimensiune proceselor agile. Se poate începe prin a reevalua forma curentă a “Agile Manifesto”, care există deja de cel puțin un deceniu. Cunoaștem deja ceea ce recomandă acest agile manifesto.

Aceleași persoane direct implicate în acest fenomen, au început să observe că în zilele noastre, dacă nu aducem un plus la ceea ce am putea numi “software la cheie”, multe colaborări se vor deteriora sau se vor răci, ajungându-se la pierderea clienților existenți, aceștia îndreptându-se spre alte alternative. Cred că este important să oferim clienților acel WOW. Din nou, cu permisiunea voatră, aș dori să deviez, mai mult sau mai puțin de la subiect, și să încerc să aduc câteva exemple care pot fi considerate modalități de a aborda puțin diferit forma curentă de exprimare Agile. Aceste exemple sunt inspirate din www.todaysoftmag.ro | nr. 30/decembrie, 2014

41

management Mai mult decât software colaborarea personală, directă sau indirectă cu câteva persoane marcante în curentul Agile la nivel global (Ken Rubin, Mitch Lacey, Steve Denning, etc).

Aș începe cu favorita mea:

Schimbarea abordării din “ouptut” la “outcome” Scopul implicit în Agile manifesto ar fi “working software” care s-ar traduce în realizarea/producerea unui “output”. Chiar și finalizarea și release-ul unui “story” este considerat parte din output. În contrast, prin impresionarea unui client prin efectul de WOW, ne referim de fapt la “outcome” care poate fi considerat mai mult ca o experiență umană. Așadar, schimbarea mentalității de la “output” la “outcome” este fundamentală.

Proupunerea de WOW în ideea de DONE în SCRUM Cu toții cunoaștem faptul că în Scrum există o lungă discuție pe tema definirii termenului de “DONE” în cazul funcționalităților care trebuiesc livrate la final de sprint. Multe companii refuză însă să accepte faptul că funcționalitatea nu este completă până când clientul nu trăiește efectul de WOW.

Schimbarea de la scopul implicit la cel explicit Ideal, se consideră că metodologiile agile surprind plăcut clienții oferind efectul de WOW. Bineînțeles, toate acestea au un cost, iar acest cost este strâns legat de fiecare persoană implicată. Când persoanele direct implicate decid să părăsească organizația, se ajunge în punctul din care s-a plecat, făcându-se doar “software la cheie”. Este vital să se consolideze scopul definit și să se cunoască faptul ca acest scop este unul explicit.

Inceperea măsurării gradului de satisfacție al clientului Importanța măsurării gradului de satisfacție al clientului prin “Net Promoter Score” nu poate fi niciodată exagerată.

Fără aceste măsurători, satisfacția clientului poate deveni o simplă afirmație. Ca urmare, organizațiile revin din nou la vechile priorități legate DOAR de partea financiară. Doar prin aceste măsurători, organizațiile își pot concentra atenția și pot atinge obiectivul de a satisface clienții prin efectul de WOW. Mai sunt și multe alte abordări îmbunătățite a versiunii inițiale de “agile manifesto” care pot aduce rezultate

42

uimitoare clienților, însă scopul articolului curent, nu face referire doar la acest aspect.

Revenind la subiectul principal, livrare cu efect de WOW, livrarea strategică ar fi considerată de mulți ca un efort colectiv în schimbarea percepției din a avea un număr mare de output-uri la o calitate mai bună a rezultatului (outcome). În loc să se concentreze pe producerea mai multor output-uri, tot mai multe persoane influente consideră ca țelul organizațiilor orientate pe servicii ar trebui să fie producerea de outcome-uri mai bune. Cheia ar putea fi înțelegerea și conștientizarea obiectivelor și outcomurilor corecte, și apoi, găsirea celei mai coerente, simple și ieftine căi de a le realiza.

Am menționat la începutul articolului importanța manevrabilității simple și corecte. A fi obiectivi și concentrați pe outcome-uri, ajută oamenii în particular și companiile în general, să se adapteze rapid la schimbare și să iasă în față competitorilor.

Totul sună perfect până acum, dar marea încercare începe în momentul în care ne concentrăm să facem această schimbare de mentalitate și ajungem să ne întrebăm cum o facem de fapt.

Personal, cred că este alegerea fiecărei companii, folosind diferite unelte și concepte, dar trebuie să luăm în considerare o abordare care ar permite inovare rapidă, în ritm cu oportunitățile care apar mereu.

Există în mediul business o zicală: clientul are întotdeauna dreptate. Aceasta ar putea fi un principiu bun în unele situații, dar nu mai este suficient pentru situațiile și organizațiile de azi orientate pe servicii.

Cred că putem găsi o formulare mai bună și mai actuală: dacă nu ne ascultăm clienții, vom eșua, iar dacă ascultăm numai de clienții noștri, vom eșua.

Cu toții știm că doleanțele clienților sunt transformate într-o listă de cerințe numită backlog în lumea agile, care este prioritizată. Apoi, noi încercăm să realizăm acele părți despre care credem că vor îndeplini acele cerințe. Toate echipele fac acest lucru din nou și din nou, cu o concentrare colectivă pe prioritizarea și realizarea și mai multor cerințe într-un mod din ce în ce mai eficient. Dar este un lucru chiar responsabil, având în vedere că în final dezvoltăm ceea ce ne cer clienții.

Așadar ce ar fi greșit? Toți directorii de pe partea de business vor fi satisfăcuți.

Mulți dintre noi pun semnul egal între dezvoltarea cerințelor și succesul în piață, așadar echipele se concentrează rapid pe designul, dezvoltarea și testarea soluțiilor care îndeplinesc cerințele, în loc să încerce

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

să înțeleagă pe deplin problemele și cauzele lor sau dorințele ascunse în backlog.

Până când oamenii nu înțeleg pe deplin ce încearcă să rezolve, nu vor putea să găsească cel mai bun mod de a rezolva acea problemă. Până când o organizație nu înțelege pe deplin care sunt obiectivele pe care dorește să le atingă și ce fel de outcom-uri dorește să prezinte, nu poate să înțeleagă ce oportunități să urmărească. Ca să dezlegăm acest mister, trebuie să știm ce se întâmplă, de ce se întâmplă și cine se confruntă cu ce probleme.

Outcom-ul muncii noastre este cel care contează cu adevărat. Cu toții intuim că obiectivul nostru nu este să dezvoltăm 10 funcționalități, ci să îmbunătățim viețile clienților noștri cât de bine putem. Pentru a realiza acest lucru, trebuie să ne concentrăm asupra outcom-ului și a impactului pe care îl va avea munca noastră asupra utilizatorilor produselor noastre.

Totuși, nu putem să ne limităm gândirea numai asupra outcom-ului. Ca să avem cel mai mare impact posibil asupra vieților clienților noștri, trebuie să lucrăm activ pentru a minimiza output-urile în timp ca să maximizăm outcom-urile sau valoarea serviciilor noastre. Ca ingineri, ne concentrăm mereu pentru a crește output-ul echipelor noastre.

Cu fiecare “story”, țintim să înțelegem valoarea pe care încercăm să o dăm clienților noștri, ceea ce în general se traduce prin crearea unui produs minim viabil (conceptul cunoscut de toată lumea, MPV).

Este foarte important să facem alegerea corectă și să începem dezvoltarea “story”-ului potrivit. Chiar dacă, această alegere și această decizie sunt în principal responsabilitatea unui “product owner”, eu sunt adeptul ideei conform căreia și noi ca ingineri putem să aducem o contribuție foarte importantă prin simplul fapt de a ne întreba “alegem sau nu să dezvoltăm acele story-uri, punând în balanță efortul necesar și valoarea rezultată, astfel încât să avem cel mai mare impact asupra vieților clienților noștri ?”

Care va fi cea mai bună alegere pentru noi: să dezvoltăm 10 lucruri mediocru sau doar 5 dar sclipitoare ?

Bucla Mobius, descoperită de matematicienii germani August Ferdinand Mobius și Johann Benedict (conform Wikipedia, o fâșie Mobius este o “suprafață cu o singur plan și o singură componentă ca și limita”), arată ca o buclă continuă cu o răsucire în mijloc. Această buclă poate reprezenta fluxul constant de informație care ar trebui

management

TODAY SOFTWARE MAGAZINE

să existe într-o organizație pentru a explica pentru a avea un produs viabil, scurtăm cu claritate obiectivele companiei la toate timpul până la ieșirea pe piață.

Investițiile sunt făcute în tranșe, redunivele ei. când astfel riscurile și posibilitatea apariției unor costuri suplimentare neprevăzute.

Realizarea unui produs minim viabil înseamnă mai puțin cod sursă de dezvoltat și menținut, reducând costurile generice ale SDLC.

Mobius are la bază patru principii esențiale

În bucla Mobius, putem începe oriunde considerăm că situația o cere, dar e foarte important să se înceapă cu o înțelegere clară a problemei sau a situației, și după aceea, putem să aprofundăm înțelegerea.

Pot fi situații în care putem avea de la început un set definit de opțiuni și trebuie să ne uităm înapoi pentru a fi siguri că avem o foarte bună înțelegere a problemei sau a situației.

Cu bucla Mobius în minte, ca o alternativă la modul tradițional al businessului, putem oferi transparență asupra luării deciziilor și a investițiilor. Acest lucru aduce un adaos important pentru a putea urmări investițiile și a verifica dacă acestea aduc valoarea dorită sau dacă ar trebui ca aceste investiții să fie făcute în alte arii (această schimbare ar fi vizibilă prin reprioritizarea listei de story-ri în backlog).

Nu este ușor să ne motivăm oamenii să facă această schimbare de mentalitate către crearea de outcom-uri. Mulți tind să rămână în zona lor de confort. Poate e mai potrivit ca această schimbare să se facă în paralel, încercând să se pună accentul treptat pe outcom-uri.

Cu ajutorul lui Gabrielle și al lui Ryan, am descris mai jos câteva din beneficiile, principiile și pașii pe care această mentalitate bazată pe outcom-uri le include și cere.

Beneficii Idei multiple pot fi testate într-un timp scurt, influențând astfel deciziile luate având în vedere aceste rezultate palpabile și nu doar previziuni.

Realizând doar minimul necesar

Concluzie Dacă nu ne ascultam clienții vom eșua, iar dacă ne ascultăm numai clienții, vom eșua!

Resurse 1.

2.

3.

4.

Atenția sporită pe outcom-uri care 5. aduc valoare, decât pe output-uri care aduc efort mărit.

6.

Concentrarea echipelor de dezvoltare în rezolvarea problemelor și a urmăririi oportunităților de care beneficiază atât compania cât și clienții acesteia.

Măsurarea valorii în mod continuu pentru a asigura că se merge în direcția corectă. Împuternicirea echipelor de dezvoltare pentru a atinge outcom-urile propuse în cadrul constrângerilor existente.

Mobius are 7 pași care lucrează împreună (ce întrebări trebuie să punem și să răspundem) Problema sau oportunitatea - ce problemă încercăm să rezolvăm și ce oportunitate dorim să urmărim?

Outcome-uri - care sunt cele mai importante outcome-uri pe care urmează să le îmbunătățim ?

Profunzime - descoperirea amănuntelor problemei sau alte oportunități.

Opțiuni - care sunt opțiunile curente pe care le avem pentru a putea îmbunătăți cele mai importante outcome-uri?

Livrarea - livrăm cea mai optimă opțiune incremental și învățăm din ea.

Măsurare - cât de mult am mișcat acul balanței ?

Adaptabilitate - ar trebui să continuăm pe direcția de acum, sau ar trebui să ne schimbăm opțiunile? În final, aș dori să recomand tuturor, să continuăm să îmbunătățim ajustările proceselor agile, prin a analiza și revizui versiunea actuală a Agile Manifesto, pentru a reuși să identificăm neajunsurile și a reuși sistematic să le îndepărtăm.

Mike Cohn - “Coaching Agile Teams” Mike Cohn - “User Stories Applied” Mitch Lacey - “The Scrum Field Guide” Steve Denning - “The Leader’s Guide to Radical Management” Gabrielle Benefield & Ryan Shriver - “Mobius - Create, deliver and measure value” http://www.mobiusloop.com

Sebastian Botiș

Sebastian.Botis@endava.com Delivery Manager @ Endava

www.todaysoftmag.ro | nr. 30/decembrie, 2014

43

management

programare

Sun Tzu ‘Arta Războiului’ și era informațională

A

cest articol este al doilea din seria legată de ‘Arta Războiului’ scrisă de Sun Tzu și aduce mai multe argumente pentru a considera acest tratat militar vechi de 2500 de ani drept un ghid pentru rolul contemporan de Product Owner.

Argument

economia statului. Calitatea generalului (și Așa cum am prezentat în articolul ante- succesul PO) sunt determinate de moralul rior (Sfaturi străvechi pentru un Product oamenilor din subordine și de modul în Owner – TSM, Nr. 29), există o serie de care este gestionat bugetul. asemănări între PO și Generalul așa cum este el prezentat de Sun Tzu. Pentru a Informarea prealabilă extinde lista de similitudini între cele două ‘3. Or, dacă prințul luminat și generaroluri, voi expune în acest articol modul în lul avizat înving inamicul de câte ori trec la care este obținută informația și importanța acțiune, dacă realizările lor depășesc pe cele acesteia pentru General ca și pentru PO. obișnuite, aceasta se datorește informării Capitolul al treisprezecelea al cărții prealabile. lui Sun Tzu – Folosirea agenților secreți – 4. Ceea ce se numește “informare preeste dedicat rolului pe care îl au spionii alabilă” nu provine de la spirite, nici de la în obținerea informațiilor despre mane- divinități, nici din analogie cu evenimenvrele și efectivele trupelor inamice. Scopul tele trecute, nici din calcule. Ea trebuie războiului este obținerea victoriei rapide, obținută de la oamenii care cunosc situația iar generalul trebuie să fie în permanență inamicului.’ informat despre armatele inamice pentru Prin urmare, generalul trebuie să a putea să adapteze manevrele propriei aibă tot timpul informații valide și actuarmate. Trupele de spionaj trebuie să fie ale despre poziția, efectivele și manevrele eficace pentru a putea să ofere datele nece- inamicului, dar și despre planurile acessare despre inamic. tuia. De asemenea, citatul de mai sus Astăzi, PO trebuie să fie informat în evidențiază faptul că informațiile relevante permanență despre tendințele pieței, ale nu pot fi obținute decât din surse credibile. comportamentului consumatorilor de În era informațională pe care o trăim, produse de același tip și despre produ- este evident ca un PO trebuie să fie la sele concurente. Poziționarea corectă a curent cu starea pieței pe care va fi lansat produsului pe piață, plus-valoarea adusă produsul, iar deciziile pe care le ia referide acesta – care este convertită în profitul toare la funcționalitățile acestuia trebuie organizației pentru care este creat –, sunt să fie luate pe baza unor informații valide posibile doar dacă PO este la curent cu despre schimbările care apar. starea pieței pe care se va lansa produsul.

Activitățile de planificare pe care le Sun Tzu descrie și alte elemente care efectuează PO și echipa SCRUM ca parte sunt afectate de calitatea informației pe a dezvoltării produsului software trebuie care o are generalul la dispoziție, cum ar fi să aibă la bază informații, iar dacă acesmoralul trupelor dar și bugetul regatului, tea sunt învechite sau incorecte, succesul pentru că o campanie lungă crește cos- proiectului este pus în pericol sau chiar turile de întreținere ale armatei, afectând compromis. Concluzia este că deținerea

44

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

unor date provenite din surse credibile este un aspect crucial pentru succesul unui proiect și implicit pentru succesul unui PO.

Sursele de informație

Sun Tzu descrie cinci tipuri de agenți secreți care pot fi folosiți de un general: • Indigeni – cetățeni din statul inamic; • Interiori – funcționari ai inamicului; • Dubli – spioni ai inamicului care pot fi folosiți; • Lichidabili – spioni cărora li se dau în mod deliberat ‘...informații inventate în toate felurile.’; • Volanți – cei care revin cu informații din teritoriul inamic.

Toate aceste tipuri sunt corespondente cu tipurile de informații pe care un general trebuie să le obțină și să le folosească: • Despre starea economică și de spirit a națiunii inamicului (spionii indigeni); • Despre politica inamicului (agenții interiori); • Contrainformații (cele folosite de spionii dubli și lichidabili); • Tactice și strategice (furnizate de agenții volanți).

Se poate observa că aceste tipuri de informații sunt similare celor care stau la baza deciziilor unui PO: • Studiile de marketing care dau informații despre starea curentă și despre trendurile pieței și consumatorilor; • Rapoartele care oferă date despre cele mai frecvent utilizate tehnologii;

programare

TODAY SOFTWARE MAGAZINE

• Acordurile de confidențialitate despre modul de recrutare și organizarea încheiate cu angajații – forma legală a administrativă în China antică: cea mai mică unitate administrativă era gospocontrainformațiilor. dăria familială, iar opt familii formau o Paralela dintre general și PO se referă comunitate. Dacă o familie trimitea un doar la utilizarea informațiilor nu și la res- bărbat la război, restul comunității contriponsabilitatea coordonării activității de buia la întreținerea familiei afectate, prin spionaj. Astăzi, responsabilitatea pentru suplinirea obligațiilor acesteia la munca prelucrarea datelor este a departamentelor pământului. Astfel se ajungea la cifrele specializate din companii, sau a firmelor citate.

Devine destul de clar efectul pe specializate în studii de piață. Însă PO este responsabil să solicite organizației care va care o campanie de durată îl avea asudeține sau folosi produsul, rapoartele nece- pra populației civile și asupra economiei sare și să le folosească în planificare și în naționale, acesta aducând o noua perspectivă asupra costurilor implicate de procesul decizional.

Agenții secreți și datele pe care le fur- serviciile de informații. Cheltuielile cu spinizează ei, precum și modul în care acestea onii devin justificate dacă reduc perioada sunt folosite au și rolul lor în evaluarea de campanie militară.

PO este responsabil de valoarea adăcalităților generalului, așa cum subliniază Sun Tzu: ’13. Cine nu este experimentat și ugată a funcționalităților dezvoltate în prudent, omenos și drept, nu poate folosi fiecare sprint și trebuie să ia în consiagenți secreți.’ și ‘...Nu există nici un loc derare costurile legate de dezvoltarea acestuia, astfel încât valoarea adusă de unde să nu fie folosit spionajul’. fiecare funcționalitate să depășească Costurile dezvoltării software și costurile echivalentul prețului plătit pentru echipa de dezvoltare. Prioritatea cerințelor în informației În zilele noastre, informația implică o Product backlog și Sprint backlog este serie de costuri, cum ar fi plățile pentru stabilită în funcție de valoarea acestora, realizarea studiilor de piață, pentru abona- iar prioritizarea trebuie făcută pe baza informației deținute de către PO. mentele la publicațiile de specialitate .

Existența unor costuri inerente pentru campaniile militare ca și pentru Concluzii menținerea unui serviciu de spionaj este Cu toții suntem conștienți de costusubliniată de Sun Tzu: ‘1. Or, atunci când rile pe care le implică livrarea unui produs o armată de o sută de mii de oameni va fi software. În acest articol am demonstrat și ridicată și trimisă în campanie la distanță, faptul că succesul proiectului de livrare are cheltuielile suportate de populație, adăugate și alte dependențe, iar una dintre acestea la sumele plătite din tezaur, se vor ridica la este informația – de calitate și recentă – pe o mie de galbeni pe zi. Va domni o agitație care PO o folosește în procesul decizional permanentă atât în interiorul, cât și în și în planificare. Informațiile pot proveni exteriorul țării, populația va fi epuizată din din surse externe (studii de piață, statistici) cauza cerințelor transporturilor și treburile sau pot proveni din interiorul organizației a șapte sute de mii de familii vor fi dezorga- (de la responsabilii externi ai proiectului nizate.’ Pentru a înțelege modul de calcul – ‘stakeholders’). Ambele categorii sunt al impactului campaniei asupra populației importante pentru procesul decizional este nevoie de o precizare suplimentară efectuat de PO, contribuind la succesul

proiectului. Încă o dată, cartea lui Sun Tzu se dovedește a fi o sursă de învățăminte pentru un PO mai ales pentru că prezintă în detaliu modul în care se poate construi imaginea de ansamblu a factorilor de influență ai proiectului.

Liviu Ştefăniţă Baiu

liviu.baiu@endava.com Senior Business Consultant @ Endava

www.todaysoftmag.ro | nr. 30/decembrie, 2014

45

testare

programare

Atlassian JIRA REST API

N

u cred că este o coincidenţă faptul că Atlassian JIRA este tool-ul folosit pentru issue tracking în toate proiectele la care am luat parte până acum. Deşi există destul de multe produse de genul acesta pe piaţă, JIRA este unul dintre numele recunoscute de majoritatea actorilor implicaţi în proiecte informatice. Alături de alte titluri sonore precum Bugzilla sau Redmine, JIRA iese în evidenţă prin setul complet de funcţionalităţi, calitate, uşurinţa utilizării, dar şi prin extensibilitatea sa.

Atlassian JIRA a fost conceput ca un produs flexibil, uşor extensibil prin intermediul plugin-urilor. De asemenea, sistemul comunică cu lumea exterioară printr-o interfaţă REST, prin intermediul căreia clienţii platformei pot efectua diverse operaţii. În rândurile care urmează ne vom concentra atenţia asupra trăsăturilor acestui API, discutând câteva use case-uri clasice, cum ar fi căutarea unui issue sau adăugarea unui comentariu. De asemenea, vom petrece puţin timp uitându-ne atât la clientul Java pus la dispoziţie de Atlassian, cât şi la implementarea unui client REST utilizând Jersey, implementarea de referinţă de la Oracle.

JIRA REST Java Client

Atlassian ne pune la dispoziţie o bibliotecă de clase menită să ne înlesnească lucrul cu API-ul REST, aceasta numindu-se sugestiv JIRA REST Java Client. Această bibliotecă expune la rândul său un API aproape complet pentru operațiile pe care le putem face într-un proiect JIRA. Spre exemplu, prin intermediul acestui client avem posibilitatea să găsim un anume proiect după cheie, să creăm tichete, să le ştergem, să adăugăm atașamente, să adăugăm worklog-uri și multe altele.

Metodele pe care le avem la dispoziție sunt grupate în mai multe clase, în funcție de obiectul business despre care este vorba. De exemplu, putem apela metodele ce țin de administrarea issue-urilor doar după ce obținem un obiect de tip IssueRestClient. Înainte de aceasta, avem nevoie de un obiect de tip JiraRestClient, creat prin intermediul unei implementări asincrone a interfeței JiraRestClientFactory.

Detaliile menționate mai sus pot fi observate în clasa JiraClient care face parte din proiectul demonstrativ ce însoțește acest articol. Proiectul poate fi descărcat de la adresa menționată în secțiunea Resurse. Trebuie să observăm faptul că acest proiect Java are scop didactic, codul sursă fiind unul minimal, care nu urmăreşte să respecte bunele practici.

Să presupunem că dorim să obținem cu ajutorul bibliotecii JRJC un obiect de tip Issue, ce modelează detaliile unui tichet JIRA. Acum că avem la dispoziție un obiect de tip JiraRestClient putem scrie următoarele: Promise<Issue> promise = jiraRestClient.getIssueClient(). getIssue(„JRA-9”); Issue issue = promise.claim();

obținerea altor obiecte, cum ar fi proiecte, worklogs etc. .

Unul dintre avantajele utilizării acestei biblioteci îl reprezintă faptul că nu trebuie să ne preocupăm de subtilitățile lucrului cu servicii REST. În fond, până în acest moment pentru noi a fost transparent faptul că avem de-a face cu un API REST. Pentru a ne face o părere mai clară despre ce înseamnă JIRA REST API, trebuie să realizăm propria noastră implementare a unui client REST, lucru pe care îl vom face utilizând Jersey.

Client REST cu Jersey

Jersey ne oferă un mod simplu și rapid de a crea un client REST, aspect pe care îl ilustrăm în continuare: String auth = new String(Base64.encode(USERNAME + „:” + PASSWORD)); Client client = Client.create(); WebResource webResource = client.resource(JIRA_SERVER + REST_PATH + query); Builder builder = webResource.header(„Authorization”, „Basic „ + auth)

.type(MediaType.APPLICATION_JSON).accept(MediaType.APPLICATION_JSON);

Revenind la scenariul în care dorim să regăsim un tichet pe baza cheii, presupunem că parametrul query conține o cale de genul issue/JRA-9, unde JRA-9 este cheia tichetului. Pentru a obține obiectul Issue apelăm metoda get(), care corespunde metodei HTTP GET. ClientResponse clientResponse = builder.get(ClientResponse.class);

În acest moment putem obține obiectul JSON serializat, sub forma unui String: String json = clientResponse.getEntity(String.class);

Acest String poate fi apoi deserializat într-un bean creat de noi cu ajutorul bibliotecii Jackson, care ne pune la dispoziție diverse unelte de lucru cu JSON. Acest scenariu este unul dintre cele mai simple, însă lucrurile devin mai complicate atunci când trebuie să creăm un worklog, spre exemplu. În acest caz, mai întâi trebuie să creăm un bean cu ajutorul căruia să modelăm un worklog și să populăm o instanță cu informațiile pe care dorim să le salvăm. Apoi trebuie să serializăm acest obiect sub forma unui String și să-l transmitem serviciului REST după modelul de mai sus, însă folosind metoda HTTP POST de data aceasta. Răspunsul serviciului va conține obiectul salvat sub formă serializată, îmbogățit cu noi informații, cum ar fi id-ul worklog-ului.

Observăm că metoda getIssue (String issueKey) returnează un obiect de tip Promise<Issue>, motiv pentru Concluzii care, pentru a obține instanța Issue trebuie să apelăm metoda JIRA REST API este o interfață către lumea exterioară care are claim(). În aceeași manieră trebuie să procedăm și pentru o valoare business incontestabilă. Acest API oferă organizațiilor

46

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE posibilitatea să integreze cu ușurință tool-ul în ecosistemul propriu, pentru a defini procese dintre cele mai creative și complexe.

Totuși, se poate observa că JIRA REST API nu acoperă în totalitate scenariile de utilizare JIRA. Unul dintre aspectele pentru care utilizatorii așteaptă o rezolvare îl reprezintă imposibilitatea de a lucra cu filtrele salvate. Există și un tichet pe acest subiect (JRA36045), care încă este deschis.

Pe de altă parte, trebuie să menționăm că API-ul REST vine cu funcționalități importante, cum ar fi posibilitatea de a regăsi câmpurile custom și valorile acestora, operație pe care nu o puteam face cu API-ul SOAP. JIRA REST API a ajuns la versiunea a doua şi, chiar dacă există loc de îmbunătăţiri, putem spune că este un produs matur, care vine cu funcţionalităţi importante față de predecesorul său.

Resurse 1.

2.

3.

4.

https://jira-rest-client-ro-leje.googlecode.com/svn/trunk https://docs.atlassian.com/jira/REST/latest/ http://www.j-tricks.com/tutorials/java-rest-client-for-jira-using-jersey http://www.baeldung.com/jackson-ignore-null-fields

Dănuț Chindriș

danut.chindris@elektrobit.com Java Developer @ Elektrobit Automotive

www.todaysoftmag.ro | nr. 30/decembrie, 2014

47

management

În căutarea engagement-ului în industria software

M

arketingul s-a schimbat în mod dramatic în ultimii ani, influențându-ne și pe noi, fie că suntem marketeri sau antreprenori. Până în prezent, am fost martori la decăderea mijloacelor de comunicare tradiționale, la apariția și dezvoltarea unui volum imens de informații dar și la inovații tehnologice pe toate planurile.

La această serie de inovații se adaugă și modul în care consumatorul percepe conceptul de brand. Astăzi, consumatorul are nevoie să se simtă implicat în povestea brandului companiei noastre și va cere acest lucru, deoarece așteptările lui au evoluat și, odată cu ele, întregul său comportament. Astfel, în acest moment, se pune problema dacă brandurile vor înțelege acest lucru și vor răspunde pe măsură.

Termenul de engagement nu are o traducere exactă în limba română așa că îl vom folosi pentru a indica procesul de implicare al angajaților sau clienților unei companii în diversele activități întreprinse de aceasta.

Dar să începem cu începutul: avem nevoie de engagement? În mod cert e mai mult o întrebare retorică pentru că toate afacerile au nevoie de aplicarea unui anumit nivel de engagement, fie că vorbim de relația cu proprii colegi sau clienți. Întotdeauna a existat această nevoie, doar că acum o și conștientizăm în condițiile unor piețe foarte competitive.

Acum câțiva ani, a obține acoperire media cât mai mare era tot ce îți puteai dori de la marketing. Aveai acoperire,

48

aveai rezultate. Cu toate acestea, odată cu creșterea exponențială a informațiilor transmise în piață de către marketer-i, acoperirea media nu mai reprezintă singurul factor decisiv al succesului în comunicare.

De data asta, trebuie să ne asigurăm de faptul că audiența noastră țintă recepționează mesajul nostru, îl înțelege și răspunde conform așteptărilor sau obiectivelor trasate.

Bătălia pentru un brand memorabil a început. Concentrează-te pe esența nevoilor consumatorilor tăi și interacționează cu aceștia. Doar așa vei stabili o conexiune reală între publicul țintă și brandul tău.

Industria Software

O dată cu dezvoltarea industriei de IT&Software, a apărut provocarea de a angaja și de a fideliza pe cei mai buni specialiști din domeniu, din cauza lipsei de candidați și a competitivității în recrutarea acestora. În acest caz, care este totuși soluția?

Engagement marketing poate fi singura cale prin care să-i determinăm pe angajații noștri să se dedice valorilor brandului nostru, sporind astfel nivelul lor de satisfacție și productivitate la locul de muncă.

Companiile de software ar trebui să conștientizeze clar faptul că-și derulează

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

activitatea într-un ecosistem de comunicare și că procesul de engagement poate fi aplicat în diverse contexte: 1. Social Media. Întregul concept al rețelelor sociale se bazează pe nevoia indivizilor de a face parte dintr-o comunitate . Acest lucru le permite brandurilor să devină mai apropiate de fanii lor, iar Social Media oferă instrumentele perfecte pentru a facilita această conexiune. Rețineți însă un singur lucru: Social Media NU înseamnă doar Facebook!

2. Rețelele profesionale. Acestea oferă oportunitatea brandurilor de a se poziționa într-o comunitate cu interese similare. Generarea de conținut relevant joacă un rol vital în tot acest proces prin faptul că împărtășirea experienței de brand poate convinge profesioniștii din domeniu că le putem oferi acel mediu de lucru în care ei trebuie și își doresc să se regăsească.

3. Comunitățile locale. O imagine de brand recognoscibilă și respectată în comunitate este cheia diferențierii.

Oamenii se simt mai aproape de brandurile implicate în activități ale comunității și este mult mai probabil să-și dorească să facă parte din construcția acestor branduri, fie din postura de angajați, parteneri de afaceri sau fani.

TODAY SOFTWARE MAGAZINE 4. Compania în sine. Angajații pot fi cei mai buni ambasadori ai brandului tău. Mai mult decât atât, faptul că sunt implicați în construcția brandului va adăuga un plus de motivare non-materială, scăzând importanța motivației financiare.

Oferă-le pur și simplu șansa de a simți că pun umărul la creșterea unui brand de succes cu valori solide și care le apreciază aportul și susținerea.

Cum putem crea engagement?

Engagementul e ca o promisiune dintre doi parteneri de viață care ar trebui să se transforme într-un mariaj frumos. (en. engagement=logodnă) Iar principiul de bază pentru acest lucru este reprezentat de o comunicare eficientă și deschisă, ce duce la stabilirea unei relații pe termen lung.

Următorii factori sunt de luat în calcul pentru a îndeplini un proces de engagement: 1. cunoaște-ți audiența. Dacă lucrurile sunt neclare în această etapă... nu încerca să mergi mai departe. Altcumva spus, dacă nu cunoști cui te adresezi, cum să știi modul în care să i te adresezi sau implici în diverse activități? Iar pentru asta, lansează întrebări specifice, care să urmărească acele dimensiuni ce te vor ajuta să comunici mai eficient cu audiența ta.

2. creează (sau găsește) contextul de comunicare cu audiența ta: folosește cele mai potrivite canale de comunicare, la momentul potrivit. Aici intervine capacitatea de a identifica acele canale de comunicare eficiente prin care să transmitem mesajul nostru. De reținut însă faptul că nu este suficient un singur canal de comunicare, fiind important să găsim mixul de comunicare potrivit publicului căruia ne adresăm. În ziua de azi, eficiența și performanța sunt date de integrarea comunicării online cu cea offline, dar și de transmiterea unui mesaj unitar pe mai

multe canale.

3. generează conținutul relevant pentru audiența ta, conținut bazat întotdeauna pe nevoile acestei audiențe care ar trebui analizate în preliminar cu mare, mare atenție. Calitatea conținutului este direct influențată de nivelul de cunoaștere asupra așteptărilor audienței țintă. Într-un mediu atât de disruptiv, cu volume mari de informații, conținutul te poate departaja față de alte companii, setând un avantaj competitiv.

4. interacționează cu audiența ta.

De multe ori conștientizăm importanța engagementului abia în acest stadiu.

Interacțiunea în sine permite să obținem feedback dar și să descoperim noi oportunități. De asemenea: e un job fulltime. Primește feedback-ul audienței în orice moment și nu-ți fie frică să răspunzi reacțiilor generate... în timp util, desigur.

ne motivăm partenerii de afaceri și până la modul în care încercăm să creștem valoarea brandului nostru. Relațiile interumane sunt redefinite și astfel, întreaga societate în care trăim. E cam înfricoșător acest gând, însă este un proces natural până la urmă, ce contribuie la evoluția noastră și la eforturile depuse pentru a găsi în permanență cele mai eficiente soluții în tot ceea ce facem.

Provocarea noastră

Engagement marketing face referire la crearea unui context prin care să livrăm experiențe personalizate clienților, angajaților și partenerilor noștri, pe baza nevoilor acestora, conștientizate sau nu.

Scopul de bază și provocarea reală este de a avea oameni dedicați complet viziunii noastre de business, fapt ce ne va permite să atingem rezultatele mult dorite.

Engagement online sau offline?

Ambele. Sau cel puțin ar trebui să fim pregătiți pentru ambele medii. Viața noastră de zi cu zi a devenit foarte dinamică, datorită dispozitivelor mobile, obligându-ne să fim mereu conectați la o serie de informații ce țin de timpul, locul sau contextul în care ne aflăm. Adevărata provocare pentru un business este să fie adaptabil în permanență, în funcție de nevoile publicului țintă. Și nici măcar nu e nevoie să vorbim despre engagement online sau offline. E vorba strict de înțelegerea audienței și de comunicarea eficientă cu aceasta.

Alte implicații

Pe lângă toate aspectele discutate mai sus, engagementul produce schimbări majore în conceptul de bază al modului în care conducem un business: de la modul în care comunicăm cu colegii noștri, cum distribuim produsele/ serviciile noastre, cum

Victor Gavronski

victor.gavronschi@loopaa.ro Managing Director @ Loopaa

www.todaysoftmag.ro | nr. 30/decembrie, 2014

49

programare

Serviciile de reţea din Microsoft Azure

Î Radu Vunvulea

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

n acest articol vom analiza cele mai importante servicii care ne ajută să creăm o reţea mai bună pe infrastructura Azure. Presupun că deja cunoaşteţi conceptele de bază din cloud.

Cele trei servicii care intră în această categorie sunt: • Virtual Networks, • Express Route , • Traffic Manager.

Vom analliza fiecare serviciu separat.

Traffic Manager

Traffic Manager ne permite să distribuim traficul către diferite endpoints.

Acestea pot fi pe centre de date diferite.

Din anumite perspective putem privi Traffic Manager-ul ca pe un Load Balancer la nivel global. În acest fel putem instala o soluţie pe centre de date multiple şi putem redirecţiona traficul în funcţie de locaţia utilizatorului.

Caracteristici principale A. Utilizat numai ca şi rezolver DNS Traffic Manager este utilizat numai pentru a rezolva adresa endpoint. Odată ce endpoint-ul este rezolvat, cererea va merge direct către endpoint şi nu va trece prin managerul de trafic.

B. Numele DNS al Managerului de Trafic

Fiecare instanţă Traffic Manager va avea propriul său nume DNS. Noi vom înregistra acest DNS în spatele DNS-ului nostru real dacă dorim să redirecţionăm Cum funcţionează?

Traffic Manager verifică starea traficul de la site-ul nostru (www.foo.com) endpoint-ului la anumite intervale de timp. prin Traffic Manager.

Dacă de patru ori la rând endpoint-ul este oprit, endpoint-ul va fi marcat drept oprit, C. Instrumente de configurare iar traficul nu va mai fi redirecţionat către Îl putem configura folosind Power acel endpoint. Utilizatorii care ştiu deja Shell, REST API sau Management Portal. despre acel endpoint, vor mai încerca să se Toate caracteristicile sunt disponibile din conecteze la acel endpoint până când DNS fiecare instrument. cache expiră (DNSTTL).

50

nr. 30/2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE D. DNS TTL

comportamentul lor (testând suprafaţa cu noi caracteristici).

Putem specifica cât timp va fi depozitat numele DNS rezolvat de Traffic Manager de către clienţii noştri.

Reducerea perioadei de nefuncţionare a aplicaţiei Traffic Manager ne permite să trecem automat la un endpoint funcţional dacă originalul este oprit.

Metoda de echilibrare a volumului de date (Load Balancing) Există trei tipuri de echilibrare a volumului de date suportate în acest moment: Distribuirea traficului în mai multe locaţii • Performanţa – Pe baza performanţei şi a volumului fiecărui Fiind capabil să înregistreze endpoint-uri multiple de la centre endpoint (bazată pe latenţă); de date diferite, traficul va fi distribuit celui mai apropiat endpoint • Round Robin – Traficul este redirecţionat către toate pe baza timpului de răspuns şi a altor configuraţii – în funcţie de endpoint-urile într-un mod echilibrat (prima cerere merge metoda de echilibrare a volumului de date pe care am selectat-o. către endpoint 1, a doua către endpoint 2 şi aşa mai departe); • Failover (Reluare în caz de nereuşită) – Atunci când primul Limitări endpoint este oprit, traficul este redirecţionat către al doilea endpoint (şi aşa mai departe). Noi putem specifica ordinea Nu sunt susţinute toate serviciile Azure reluării.

Nu puteţi include în Traffic Manager servicii precum Service Bus, SQL Azure sau Storage. În general, nu doriţi să faceţi aşa ceva. Încărcătură Endpoints Fiecare endpoint poate avea o încărcătură specifică care va fi utilizată de către Traffic Manager pentru distribuţia traficului. Endpoint-urile externe nu sunt susţinute Valori mai mari înseamnă că acel endpoint poate primi mai mult Nu vă este permis să monitorizaţi endpoint-uri externe, de la trafic. Acesta este utilizat de metodele de echilibrare date Round locaţia voastră sau din alte subscripţii Azure.

Robin (acesta poate fi configurat numai din PowerShell sau REST API).

Monitorizare configuraţie Nu aveţi acces la monitorizarea configuraţiei. Clienţii nu pot seta cât de des să fie verificată starea endpoint-urilor.

Endpoint monitor la comandă Traffic Manager ne permite să specificăm ce endpoint să monitorizăm. Putem utiliza endpoint-uri HTTP/HTTPS. Putem Cazuri de utilizare de asemenea specifica un port sau o cale la comandă. Pentru toate În continuare, veţi vedea trei cazuri de utilizare a punctele finale va fi utilizat acelaşi endpoint monitor. serveruluiTraffic Manager.

Profiluri

Web Site-uri puse în funcţiune în mai multe centre de date

Un profil Traffic Manager reprezintă toată configuraţia pentru Dacă aveţi un web site care este pus în funcţiune în mai multe un nod specific. centre de date, echilibrarea volumului de trafic poate fi făcut cu uşurinţă prin utilizarea Traffic Manager-ului. Dacă volumul unui web site creşte sau a scăzut, traficul va fi redirecţionat automat Profiluri în serie Traffic Manager ne permite să specificăm un alt punct final către alt endpoint. de trafic. În acest fel, noi putem defini profiluri complexe de reluare şi putem gestiona diferite reguli de echilibrare a volumului Distribuirea uniformă a datelor introduse de date.

Atunci când aveţi un sistem care este distribuit în centre de date diferite şi aveţi o normă de a specifica dacă un endpoint poate accepta clienţi noi sau nu, puteţi folosi cu succes Traffic Manager.

DNS real Traffic Manager poate fi utilizat de către propriul tău DNS de Ar trebui să implementaţi calea url care este utilizată pentru a verifica starea endpoint-ului cu scopul de a returna un cod de domeniu. DNS-ul tău trebuie să indice DNS TRaffic Manager. eroare HTTP diferit de 200 OK, dacă endpoint-ul curent nu mai poate accepta clienţi noi.

Locaţia endpoint-urilor Toate endpoint-urile trebuie să fie din aceeaşi subscripţie. Nu poate fi utilizat cu endpoint-uri externe.

Reluare în caz de eşec pentru web site-uri Puteţi utiliza traffic manager numai drept mecanism de reluare în caz de eşec pentru web site-urile voastre şi să configuraţi Redirecţionarea utilizatorului în funcţie de locaţie Utilizatorii vor fi redirecţionaţi către endpoint-ul cel mai apro- ultimul failover endpoint din Traffic Manager pentru a returna piat. În acest fel, clienţii pot ajunge la endpoint-ul care este în cea numai o simplă pagină HTTP. În acest fel, chiar dacă sistemul vostru este oprit, clienţii vor putea să vadă ceva „frumos”. mai bună formă şi cel mai apropiat de ei.

Reluare automată în caz de nereuşită Traffic Manager este capabil să treacă în mod automat la alt endpoint atunci când cel original este oprit.

Testarea noilor puneri în folosinţă Noi putem foarte uşor să adăugăm endpoint-uri cu configuraţie diferită sau versiune diferită a aplicaţiei noastre şi să verificăm

Pro şi Contra

Pro • Uşor de utilizat, • Metode diferite de echilibrare a volumului de date introduse, • DNS TTL. Contra www.todaysoftmag.ro | nr. 30/decembrie, 2014

51

programare Serviciile de reţea din Microsoft Azure • Nu se pot specifica endpoint-uri externe; • Nu se pot specifica endpoint-uri din subscripţii diferite; • Un punct de eşec dacă Traficul este oprit;

Costuri

parte din acelaşi domeniu de trafic şi nu sunt izolate între ele.

Dacă doriţi izolare între acestea, atunci va trebui să creaţi rute expres diferite pentru fiecare dintre ele.

Limitări

Când calculaţi costul utilizării Traffic Manager-ului în sistemul vostru, ar trebui să luaţi în considerare și L1. Numărul rutelor numărul cererilor DNS pentru managerul de trafic. În acest moment există o limită de până la 4.000 de rute pentru peering public şi 3.000 de rute pentru peering privat. S2S sau P2S nu pot fi folosite în combinaţie cu Express Route.

Express Route Nu puteţi utiliza ambele metode pentru a vă conecta la infraExpress Routes este o conexiune privată între reţeaua voastră (din locaţie) şi Azure Data Centers. Atunci când utilizaţi această structura Azure. Dacă folosiţi Express Route, nu veţi putea să funcţie, aveţi o conexiune directă cu Azure Data Centers, care utilizaţi S2S sau P2S pentru aceeaşi conexiune. nu este împărţită cu alţi utilizatori. Din această cauză, o conexiune ca aceasta nu este numai rapidă, ci şi extrem de sigură. L2. Furnizori multiplii Întregul trafic de la clienţii care utilizează această funcţie este Fiecare Rută Expresă poate fi asociată numai cu un singur furîmpărţit în două „canale”. Un canal este folosit pentru traficul care nizor. Din această cauză, nu puteţi asocia aceeaşi Express Route ajunge la serviciile publice Azure, iar al doilea pentru traficul care cu mai mulţi furnizori. ajunge la resursele Azure Compute. Pentru fiecare dintre aceste canale (Direct Layer 3 şi Layer 3), există viteze diferite care sunt L3. VLANs şi Azure Express Route garantate.

Extensiile de conectivitate Layer 2 la Azure nu sunt suportate.

Caracteristici principale

Situații de utilizare

Mai jos puteţi găsi patru cazuri de aplicare în care Express Route poate fi utilizat cu succes: A. Nu pe Internetul public Conexiunile care sunt făcute prin Express Route trec printr-o conexiune privată care nu este conectată la „internetul cunoscut”. A. Derulare video (Video Streaming) Atunci când folosiţi Azure Media Services pentru derularea video, veţi dori să puteţi să derulaţi conţinut live prin Azure B. Mai sigur Datele transmise prin cablu sunt în siguranţă deoarece cone- Media Services tot timpul. În acest caz, aveţi nevoie de o conexiunea este printr-un canal privat care nu poate fi accesat de către xiune stabilă între studiourile voastre şi Azure Data Centers.

Express Route poate fi o opţiune bună pentru voi. utilizatori publici.

C. Viteză mai mare

B. Monitorizare şi suport

Vitezele oferite prin această conexiune sunt mai mari, iar lăţiDacă infrastructura şi serviciile voastre sunt pe Azure, atunci mea de bandă vă este dedicată. veţi avea nevoie în faza de monitorizare şi suport de o Conexiune Express între voi şi Azure. Echipa de suport trebuie să poată accesa serviciile voastre Azure într-un mod rapid şi de încredere.

D. Latenţă scăzută Conexiunea directă între voi şi centrul de date Azure reduce latenţa care există în mod normal între două endpoint-uri.

C. Stocarea datelor Când utilizaţi Azure Storage sau SQL Azure pentru a memora datele voastre, veţi dori de asemenea o latenţă scăzută şi o coneE. Lăţimea de bandă disponibilă Există opţiuni diferite de lărgime de bandă care sunt disponi- xiune rapidă între datele voastre şi infrastructura din locaţia voastră. Express Route poate fi o soluţie pentru această problemă. bile de la 10 Mbps şi până la 10 Gbps.

F. Exces de conexiune

D. Confidenţialitatea datelor bancare

Da, avem chiar şi exces de conexiune. Conectivitatea Layer 3 Dacă sunteţi o bancă şi aveţi nevoie de o conexiune sigură (prin Network Service Providers) poate avea un exces de conexi- între site-urile din locaţie şi serviciile voastre Azure, Express une (conexiune Activă).

Route poate fi o soluţie foarte bună. Prin utilizarea sa, veţi avea o conexiune sigură care nu poate fi accesată de pe internet.

G. Migrare uşoară de la S2S şi P2S

Dacă deja utilizaţi Site to Site sau Point to Site şi doriţi să Pro şi contra migraţi la Express Route, veţi descoperi că migrarea se poate face Pro foarte uşor.

• Rapid • Sigur • De încredere H. Reţele virtuale • Exces Toate reţelele virtuale care sunt conectate la aceeaşi Express • Uşor de conectat Route pot comunica unele cu altele. Veţi putea conecta reţele virtuale din diferite subscripţii, atâta timp cât toate sunt conectate Contra la aceeaşi rută expres.

• Nu este disponibil în întreaga lume încă.

Toate Reţelele Virtuale conectate la aceeaşi Rută Express fac

52

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Costuri

Utilizând aceste script-uri, cele două reţele pot deveni una sinCostul se bazează pe traficul expediat departe. O parte din gură, fără configurare adiţională. acesta este gratuit, inclus în subscripţie. Depăşirea lui va fi taxată cu un tarif mic per GB. Traficul de transfer date inclus poate să F. Interval IP şi Subnet Mask difere în funcţie de viteza portului furnizorului Exchange pe care Când creaţi o reţea virtuală aveţi posibilitatea de a stabili un preferaţi să o utilizaţi. interval de IP şi o mască subnet. Vă puteţi crea propria configuraţie pe baza nevoilor voastre şi a cerinţelor reţelei.

Atunci când calculaţi costurile utilizării Express Route, ar trebui să luaţi în considerare: viteza port furnizor schimb și tran- G. Adresă IP privată permanentă sferul de date expdiate. În Virtual Network resursele vor avea un IP static care nu se modifică în timp. De exemplu, o maşină virtuală (VM) va avea acelaşi IP şi nu se va schimba. În plus, puteţi atribui manual un Reţele virtuale IP specific resurselor voastre din intervalul IP al reţelei voastre O reţea virtuală este o reţea „privată” pe care o puteţi defini în cadrul infrastructurii Azure. În fiecare reţea virtuală (Virtual virtuale.

Network), utilizatorii au posibilitatea de a adăuga servicii Azure şi VM pe care şi le doresc şi de care au nevoie.

H. Resurse Azure susţinute Numai VM-urile şi serviciile Azure din aceeaşi reţea virtuală În acest moment, numai Virtual Machnes şi resurse PaaS pot se pot vedea unele pe altele. Implicit, resursele externe nu pot fi adăugate unei Virtual Network. Resurse precum Service Bus nu accesa resurse din Virtual Network. Bineînţeles, utilizatorii pot pot fi încă adăugate unei reţele virtuale. configura o reţea virtuală care să fie accesată din lumea exterioară.

Ne putem imagina o Reţea Virtuală drept o reţea privată pe I. Instrumente care pot fi utilizate care o creăm acasă sau la serviciu. Noi putem adăuga la aceasta Pentru instalare şi configurare avem două instrumente pe orice resurse, putem aloca IPuri specifice şi Subnet Masks, putem care le putem utiliza: deschide diverse porturi pentru acces extern şi aşa mai departe.

• Netcfg –un fişier geneat de platforma Azure, care poate fi Este o reţea în interiorul unei reţele, dacă putem să spunem aşa. utilizat pentru a face diferite configurări.

De multe ori mă refer la ea ca şi Reţea Privată, deoarece îi puteţi • Portalul de management. adăuga resurse şi puteţi limita accesul resurselor externe la ea.

J. Limitare Subnet Masks

Caracteristici principale

Puteţi defini numărul de subnet-uri, atâta timp cât nu se suprapun. Aceleaşi reguli se aplică pentru orice reţea (din locaţii sau cloud).

A. Izolarea resurselor de accesul public Utilizând Virtual Networks, vă puteţi crea propriul vostru colţ privat în Azure, unde numai voi aveţi acces. Toate resursele voas- K. Tipuri şi intervale IP tre sunt izolate de restul lui Azure.

Virtual Network ne permite să folosim orice tip de IP, de la adrese IP publice la orice tip de intervale IP.

B. Trei tipuri de modele

În general, există trei tipuri de configuraţii utilizate cu Virtual Networks: • Cloud-Only – O reţea virtuală cu resurse numai în Azure, utilizată pentru a gestiona, securiza şi a izola resursele cloud.

• Cross-Premises Virtual Network – Pentru soluţii hibride, unde Virtual Network este utilizat pentru a crea un spaţiu în Azure care poate fi accesat şi este integrat cu o reţea din locaţie.

Ambele reţele formează o singură reţea care permite accesul reciproc.

• No-Virtual Network – No-Virtual Network utilizat pentru resursele cloud.

C. Conexiunea încrucişată între locaţii

L. Tip de reţea Virtual Network este o reţea Layer 3 care este responsabilă cu expedierea şi dirijarea mesajelor.

Protocoale susţinute

Există trei tipuri de protocoale susţinute în acest moment: TCP, UDP, ICMP.

VPN-uri Conexiunile VPN sunt suportate (RRAS – servere Remote Access şi Windows Server 2012 Routing).

Suport Linux

În cazurile în care aveţi nevoie să conectaţi soluţia voastră din Toată distribuţia Linux care este suportată pe Azure poate fi locaţie cu resursele Azure, Virtual Network este o necesitate şi utilizată într-o reţea virtuală. trebuie să vă gândiţi la ea încă din primul moment.

D. Rezoluţie nume resurse

Limitări

Odată ce integraţi reţeaua voastră cu o Reţea Virtuală, vă L1. Nu puteţi muta resurse pe o reţea virtuală odată ce au fost create puteţi accesa resursele direct prin numele lor DNS (de exemplu, Odată ce o resursă, cum ar fi un aparat virtual (VM), a fost numele Virtual Machine). creată şi pusă în funcţiune, nu mai poate fi mutată pe o reţea virtuală. Acest lucru se întâmplă deoarece informaţia reţelei este obţinută în timpul punerii în folosinţă. Bineînţeles, puteţi repune E. Program de integrare automat Atunci când creaţi o reţea virtuală, Azure vă poate genera în folosinţă aparatul vostru, dar va interveni o mică perioadă de programul care trebuie rulat pe IT pe reţeaua voastră din locaţie. nefuncţionare. www.todaysoftmag.ro | nr. 30/decembrie, 2014

53

programare Serviciile de reţea din Microsoft Azure L2. VPN este limitat numai la Windows OS

C. Soluţii hibride

Puteţi utiliza VPN numai pentru Windows OS (W7, W8, Când soluţia voastră este găzduită la locaţie dar şi în cloud, Windows Server 2008 R2 64b, Windows server 2012).

Virtual Network poate fi folosit cu succes pentru a unifica sistemul şi resursele.

L3. Nu poate fi utilizat cu toate Serviciile Azure

În acest moment, numai resursele Virtual Machines şi PaaS D. Pentru a vă conecta la Azure VM într-un mod sigur pot fi adăugate unei reţele virtuale. Alte tipuri de servicii nu pot Dacă doriţi să accesaţi VM într-un mod sigur şi de încrefi adăugate la Virtual Network. dere din reţelele voastre proprii, atunci Virtual Network este o necesitate.

L4. Inter-regiuni

O regiune virtuală poate fi definită numai într-o singură Pro şi contra regiune. Dacă doriţi să creaţi o reţea inter-regională, va trebui să Pro creaţi mai multe reţele virtuale şi să le conectaţi între ele.

• Uşor de configurat, • Resurse izolate de Internet, • Sigur .

L5. Dimensiunea reţelei Cea mai mică reţea subnet suportată este /29 iar cea mai mare Contra este /8.

• Pot fi utilizate numai resurse VM şi PaaS, • IPv6 nu este susţinut încă.

L6. VLAN-uri nu pot fi adăugate Deoarece Virtual Network este o reţea Layer 3, nu există suport pentru VLAN-uri (care operează la Layer 2).

Costuri Tracert Când calculaţi costul pentru Virtual Network, ar trebui să Acest instrument de diagnostic nu poate fi folosit într-o reţea luaţi în considerare următoarele componente: transfer de date virtuală. expediate (Inter V-NET) și durata VPN Gateway.

IPv6 În acest moment nu există suport pentru IPv6.

Concluzie Difuzare (Broadcast) În acest articol, am descoperit diferite modalităţi de manageÎn acest moment nu există suport pentru difuzarea pachetelor. ment al reţelelor pentru aplicaţiile care sunt găzduite de Microsoft Multicast Azure. În funcţie de nevoile voastre, ar trebui să luaţi în consideÎn acest moment nu există suport pentru multicast. rare aceste servicii.

Pachete încapsulate IP-in-IP În acest moment nu există suport.

Generic Routing Encapsulation (GRE) În acest moment nu există suport.

SQL DB În acest moment SQL DBs nu pot fi utilizate în combinaţie cu Virtual Networks.

Situații de utilizare

Vă prezint mai jos patru cazuri în care aş utiliza Virtual Network:

A. Pentru a izola o aplicaţie care conţine resurse multiple (precum VM) În acest caz, veţi dori ca toate resursele voastre să facă parte din aceeaşi reţea şi să fie izolate de lumea externă.

B. Scalarea resurselor din locaţia voastră Atunci când aveţi nevoie de mai multe resurse cu putere de calcul (VM) şi doriţi să creşteţi resursele din locaţia voastră întrun mod simplu şi sigur, Virtual Network vă poate crea mediul sigur pentru a face aşa ceva.

54

nr. 30/decembrie, 2014 | www.todaysoftmag.ro

sponsori

powered by