Numarul 32 - februarie 2015 - Today Software Magazine by Today Software Magazine

Nr. 32 • Februarie 2015 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

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

Today Software Magazine a împlinit

Cluj Innovation Days 2015 Soluții non-invazive ale tehnologiei în domeniul medical (Kinect)   Experimentul cu WATCHKIT SDK JavaFX şi comunicarea prin RESTful Web Services (II) Patru idei pentru îmbunătățirea Software Design-ului Gândirea critică în analiza de business

trei ani !

Dinamicile adoptării unei mentalități Agile Programatorii testează? Testerii scriu cod? Dezvoltarea Marketingului Intern (MI) în România! Analiza sentimentelor şi complexitatea opiniilor online IoT Flavour: Sensoriada

6 Today Software Magazine împlinește 3 ani Ovidiu Măţan

7 CLUJ INNOVATION DAYS 2015 Andrei Kelemen

8 Impactul evenimentelor Startup Weekend la nivel global și local Cristina Juc și Cristina Tare

9 O întâlnire cu știința, tehnologia și antreprenoriatul Oana Călugăr

10 How to Web MVP Academy Irina Scarlat

12 Registrul de biciclete Diana Silaghi

15 Experimentul cu WATCHKIT SDK Chertes Cristian și Korosi Csongor

27 Rolul unui Business Analyst într-un proiect de dezvoltare software Liviu Ştefăniţă Baiu

30 Patru idei pentru îmbunătățirea Software Design-ului Alexandru Bolboacă

33 Programatorii testează? Testerii scriu cod? Raluca Morariu

35 Aromă IoT: Sensoriada Andrei Crăciun

38 Analiza sentimentelor şi complexitatea opiniilor online Cosmin Gabriel Popa

41 Gândirea critică în analiza de business Răzvan Costa

43 Java 8 Optional Peter Lawrey

18 JavaFX și comunicarea prin RESTful Web Services (II)

44 Aprofundare a SLA-urilor furnizorilor de servicii cloud

Silviu Dumitrescu și Diana Bălan

Radu Vunvulea

22 Soluții non-invazive ale tehnologiei în domeniul medical Mursa Bogdan

24 Dinamicile adoptării unei mentalități Agile Călin-Vlad Gîngă

46 Dezvoltarea Marketingului Intern (MI) în România! Adrian Abrudan

47 Gogu la mici Simona Bonghez, Ph.D.

editorial

Ovidiu Măţan

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

n această lună am împlinit trei ani de la apariția primului număr al revistei Today Software Magazine. Au fost trei ani plini de satisfacții dar și de multă muncă și implicare din partea întregii echipe. Toate acestea nu ar fi fost posibile fără entuziasmul comunității clujene de IT și al colaboratorilor din toată țara și din străinătate. Fiecare număr are povestea sa. Articolele selectate nasc multe întrebări în cadrul fiecărui eveniment de lansare a revistei. Dar mai multe despre evoluția acestui proiect veți putea citi în articolul cu care începem acest număr. O scurtă trecere în revistă a articolelor din acest număr vă poate atrage atenția asupra diversității subiectelor abordate.Vă invit să citiți unul dintre primele articole dedicate programării Apple Watch: Experimentul cu WATCHKIT SDK. Analiza sentimentelor și complexitatea opiniilor online ne prezintă modalitatea de a descoperi într-un mod programatic o analiză a părerilor exprimate online prin câteva exemple de cod scrise în Python. Proiectele bazate pe Kinect sunt reprezentate de un proiect născut din Microsoft Imagine Cup și al cărui coordonator este Dan Suciu: Soluții non-invazive ale tehnologiei în domeniul medical. Articolul intitulat JavaFX și comunicarea prin RESTful Web Services precum și un articol semnat de Peter Lawrey: Java 8 Optional nu este doar pentru înlocuirea unei valori null continuă seria destinată limbajului Java. Finalul acestui număr este marcat de un articol din sfera marketingului, Dezvoltarea Marketingului Intern (MI) în România! , și de aventura lui Gogu la mici.

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

Ovidiu Măţan

Fondator al Today Software Magazine

nr. 32/2015 | www.todaysoftmag.ro

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

Adrian Abrudan

Korosi Csongor

Senior partner & research director @ Loopaa

iOS Developer @ Telenav

Alexandru Bolboacă

Liviu Ştefăniţă Baiu

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

Senior Business Consultant @ Endava

adrian.abrudan@loopaa.ro

alex.bolboaca@mozaicworks.com

korosi.csongor@telenav.com

liviu.baiu@endava.com

Andrei Crăciun

Mursa Bogdan

Mobile Developer @ Intel

Software Developer @ Yardi

Andrei Kelemen

Oana Călugăr

Director executiv @ IT Cluster

Ambassador în România @ Hello Tomorrow

Călin-Vlad Gîngă

Peter Lawrey

Software developer @ ISDC

CEO @ Higher Frequency Trading Ltd

Chertes Cristian

Cosmin Gabriel Popa

iOS Developer @ Telenav

SA R&D Osprov Team @ HP

Cristina Juc

Raluca Morariu

Organizatoare @ Startup Weekend Cluj

Senior QA Engineer @ Betfair

Cristina Tare

Răzvan Costa

Organizatoare @ Startup Weekend Cluj

Business Analyst @ Endava

Diana Bălan

Silviu Dumitrescu

Java developer @ Accesa

Java Line Manager @ Accesa

Diana Silaghi

Simona Bonghez, Ph.D.

PR Manager @ Registrul de Biciclete

Speaker, trainer and consultant in project management,

contact@andreicraciun.com

mursa.bogdan@yardi.com

Editor startups: Mircea Vădan mircea.vadan@todaysoftmag.com Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com

andrei.kelemen@clujit.ro

calugar.oana@gmail.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

calin.ginga@isdc.eu

chertes.cristian@telenav.com

cristinajuc@gmail.com

cristinatare@gmail.com

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

Diana.Balan@accesa.eu

diana@registruldebiciclete.ro

peter.lawrey@higherfrequencytrading.com

cosmin-gabriel.popa@hp.com

raluca.morariu@betfair.com

Razvan.Costa@endava.com

silviu.dumitrescu@accesa.eu

simona.bonghez@confucius.ro

Owner of Colors in Projects

www.todaysoftmag.ro | nr. 32/februarie, 2015

business

Today Software Magazine împlinește trei ani

n 6 februarie 2012, a apărut primul număr al revistei Today Software Magazine. Îmi amintesc cum la inaugurarea revistei, alături de colegii mei de la Gemini Solutions, ne-am străduit să creăm o listă cu toate cunoștințele noastre din zona de IT. Ne-am strâns douăzeci de oameni, constituindu-se astfel primul eveniment de lansare. Atunci nu ne-am gândit să prezentăm articolele, doar am stat la povești și am împărțit revista participanților. De atunci acest proiect a trecut prin mai multe transformări și colaborări pentru a ajunge în forma de astăzi. Today Software Magazine este un proiect care a demonstrat două lucruri importante: necesitatea unei informări locale la nivelul specialiștilor IT, iar pe de altă parte nevoia de exprimare a acestora într-un spațiu în care tehnologia și experiența acumulată sunt cele mai importante aspecte. De altfel, în editorialul publicat în primul număr au fost publicate cele trei direcții ce au fost urmate: • Conectarea specialiștilor prin promovarea tehnologiilor și a trendurilor locale; • Promovarea companiilor și a startup-urilor românești ce dezvoltă produse proprii; • Realizarea unei elite în domeniu ce se va putea promova și prin publicarea de articole. Deși niciodată nu ne-am considerat un startup, evoluția revistei are toate ingredientele specifice acestora: 1. Latura disruptive prin publicarea în mod gratuit a tuturor informațiilor, spre deosebire de publicațiile tradiționale de specialitate unde conținutul se plătește; 2. Primii pași unde au contat enorm prietenii și conexiunile acestora; 3. Evoluția ulterioară care a reprezentat o adaptare la ecosistemul local.

Ingredientele importante

Realizarea conținutului pentru primul număr a reprezentat o provocare. O mare parte dintre prieteni s-au mobilizat și au contribuit fiecare cu câte un articol. Principala dilemă era atunci de a rămâne doar online sau de a avea revista și în format tipărit. Multă lume se declara susținătoare a principiilor ecologiste, deci a variantei online, în momentul în care le ceream părerea. Dar întotdeauna, la

plecare, mulți dintre aceștia doreau să mai ia cu ei câteva reviste pentru prieteni. Am rămas așadar cu ambele formate. Un alt aspect de care trebuia să țin cont a fost finanțarea. Fiind un proiect personal, era în regulă să acopăr costurile din resurse proprii. În acest mod cred că am fi avut câteva numere în primul an și încă câteva după aceea. Dar dorința companiilor locale de a se implica și de a sprijini efortul meu de promovare a trendurilor locale din IT i-a asigurat proiectului meu continuitate și legitimitate. ISDC a fost prima companie care s-a implicat începând cu cel de-al doilea număr. Au urmat în scurt timp 3Pillar Global, Small Footprint, Endava și mulți alții. Comunitatea este poate cel mai important aspect. După evenimentul de lansare inițial, am rămas mai mult online .Lipsa unei comunicări reale a fost simțită sub forma unei absențe a feedbackului din partea cititorilor. Soluția a venit tot de la ISDC care s-a oferit să găzduiască un eveniment de lansare. După aceea a devenit evidentă oportunitatea pe care această publicație o oferea comunității de a se reuni în cadrul unor astfel de evenimente. Reușita oricărui proiect este condiționată de consecvență și ritmicitate. În primul an revista apărea cu o frecvență relativ neclară : aproximativ la o lună și jumătate sau la două luni. Această stare de fapt și-a avut cauza în mare parte în lipsa de articole. După primul an, am decis apariția lunară a revistei, iar acest lucru a dus la un mai mare număr de articole trimise spre publicare deoarece fiecare știa să se raporteze în planificare la o anumită lună. Nevoia unei calități a exprimării conținutului a reieșit după primul număr. Deși programatorilor nu li se pretinde

nr. 32/februarie, 2015 | www.todaysoftmag.ro

elocință și jonglerii stilistice , cititorii trebuie respectați cu o scriitură clară, și corectă din punct de vedere gramatical . De aceea, verificarea gramaticală și de exprimare s-a impus ca obligatorie pentru orice text publicat atât pentru versiunea în română cât și pentru cea în engleză. Evenimentul Cluj IT Days, www.itdays. ro., care anul trecut a fost la cea de-a doua ediției este un corolar al activității revistei, oferind o punere pe scenă a celor mai buni specialiști și colaboratori ai revistei alături de invitați internaționali. Deși sunt strâns legate, Cluj IT Days tinde să devină în timp un brand independent.

Planurile de viitor

Recent am lansat cardul TSM pentru da o șansă comunității să se implice întrun mod activ. De asemenea vom încerca să aducem mai mulți specialiști recunoscuți la nivel internațional în paginile revistei și să o ținem tot așa!

Ovidiu Măţan

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

eveniment

TODAY SOFTWARE MAGAZINE

CLUJ INNOVATION DAYS 2015 De la cunoaştere la valorile pieţei

regătirile sunt în curs pentru a treia ediţie a Cluj Innovation Days, eveniment ce a devenit un punct de referinţă printre cei care pun accentul pe promovarea inovaţiei în domeniile industriei. Ambiţia noastră este să facem din această conferinţă, în anii ce vor urma, „Evenimentul” dedicat rolului inovaţiei în afaceri.

Ediţia din acest an a conferinţei explorează modul în care au loc procesele tehnologice, de la apariţia ideii la cercetarea ei sau modelarea ei printr-un proces de inovaţie până când prinde formă şi la transferul efectiv al rezultatului în economie. Sunt aşteptaţi o serie de vorbitori din diferite domenii ale vieţii: oficiali din Comisia Europeană, din autorităţile române (naţionale şi locale), cercetători şi profesionişti cu o pregătire tehnică solidă, oameni de afaceri, organizaţii ale cluster-ului şi asociaţii de afaceri din toată Europa. Ei vor susţine prezentări cu un conţinut atractiv, relevant şi de calitate înaltă pentru fiecare participant, fie el dezvoltator, inginer, cercetător sau om de afaceri. În încercarea de a aduce acest eveniment cât mai aproape de interesele voastre, am luat o decizie îndrăzneaţă. Dorim ca de această dată să deveniţi parte într-un eveniment unic, care combină cu măiestrie afacerea cu tehnologia, astfel încât antreprenoriatul va deveni următorul pas firesc. Veţi fi purtaţi în două zile de experienţe intense şi vă vom da posibilitatea de a interacţiona atât cu colegi cât şi cu persoane cu un profil remarcabil. Cluj Innovation Days 2015 se va desfăşura joi şi vineri, pe 19 şi 20 martie, la Grand Hotel Napoca.

În weekendul dinainte (14 şi 15 martie) vom organiza de asemenea un hackathon pentru aproximativ 150 de persoane care îşi vor pune ideile în practică sub îndrumarea şi feedbackul unor experţi recunoscuţi. Profit de această şansă pentru a vă invita să nu rataţi acest mare eveniment. Găsiţi mai multe despre conferinţa noastră pe http://clujinnovationdays.com/ şi înscrieţi-vă pentru a obţine bilete cu reducere pentru primii participanţi. Ne vedem acolo!

Andrei Kelemen

andrei.kelemen@clujit.ro Director executiv @ IT Cluster

www.todaysoftmag.ro | nr. 32/februarie, 2015

antreprenoriat

Impactul evenimentelor Startup Weekend la nivel global și local

entru cei care nu cunosc conceptul, Startup Weekend (SW) este un eveniment ce reunește antreprenori, graficieni, designeri, programatori, marketer-i și mulți oameni cu idei numai bune de pus în practică. Pentru cei care îl cunosc, noi, organizatorii StartupWeekend Cluj, vă invităm la următoarea ediție care se va desfășura în weekendul 24-26 Aprilie 2015.

Startup Weekend este un concept creat în America și exportat apoi la nivel global care se axează pe ideea de educație și dezvoltare personală. Organizatorii îți oferă un spațiu , resurse, mentori și, cel mai important, oportunitatea de a întâlni persoane care să urmărească aceleași idealuri privind dezvoltarea unui startup. Ideea de bază este foarte simplă: timp de 54 de ore ai ocazia să-ți pui bazele propriei tale afaceri. Inițial, fiecărui participant i se oferă oportunitatea de a-și prezenta ideea în fața întregului grup, în faza de pitching. Odată votate de către participanți ideile mai interesante, se formează echipe în jurul acestor idei. Următorul pas se referă la dezvoltarea ideii care trebuie să țină cont de toate aspectele importante pentru un business: partea tehnică, cea vizuală, funcționalitate, dar și strategii de marketing. La finalul ediției, echipele prezintă proiectele finale în fața unui juriu format din antreprenori, specialiști din mediul IT și business care va premia cele mai bune proiecte. Primul eveniment de acest gen a avut loc în 2007, în Colorado, când Andrew Hyde a strâns împreună 70 de antreprenori și le-a propus să creeze un startup timp de 54 de ore. Modelul a prins la public și s-a extins foarte repede în toată lumea: în 2010 a fost creată în mod oficial organizația Startup Weekend.

Din momentul întemeierii și până în prezent au avut loc mai mult de 1000 de evenimente SW, implicând peste 100.000 de antreprenori, în peste 600 de orașe, din mai mult de 120 de țări, cuantificabile în peste 8000 de startup-uri create. În Cluj Napoca, inițiativa a ajuns acum trei ani. Pe parcursul edițiilor anterioare, s-au format multe echipe, oamenii au învățat, au împărtășit experiențe și au trecut la nivelele superioare prezentând ideile lor în cadrul incubatoarelor de afaceri (LaunchHub, Hubraum) și la alte evenimente de profil: HowToWeb, Tech Open Air, IT4Change Summit. O prezentare succintă a câștigătorilor edițiilor anterioare de la SW Cluj se concretizează în următoarele produse. • în 2012 a lu at naștere pl at forma UseTogether- comunitatea axată pe consumul colaborativ; • în 2013, OmniPaste își propunea să schimbe modul de transfer a datelor ; • în 2014, e chip a Engagement Management își propunea să transforme, printr-o aplicație de e-mail, procesele de management al performanței . Motivul pentru care ideea de startup a devenit atât de populară în ultimii câțiva ani, este foarte simplu : abundența de creativitate și de energie, dorința de a face ceva diferit, de-a participa într-un fel sau altul la dezvoltarea societății, care au pus bazele

nr. 32/februarie, 2015 | www.todaysoftmag.ro

unui trend aflat în continuă creștere. Suntem siguri că există multe persoane dornice de o astfel de experiență, de aceea vă așteptăm la cea de-a patra ediție. Detalii pe twitter și facebook.

Surse: 1.

3. 4.

http://startupweekend.org/wp-content/ blogs.dir/1/files/2013/04/Impact-ReportGuide-TEST-42C-4_11.pdf http://cluj.startupweekend.org/2013/03/05/ w inning-te ams-at-st ar tup-we ekendcluj-2013/ http://cluj.startupweekend.org/2014/03/10/ winning-teams-swcluj-2014/ http://cluj.startupweekend.org/2012/02/23/ w inning-te ams-at-st ar tup-we ekendcluj-2012/

Cristina Juc

cristinajuc@gmail.com Organizatoare @ Startup Weekend Cluj

Cristina Tare

cristinatare@gmail.com Organizatoare @ Startup Weekend Cluj

antreprenoriat

TODAY SOFTWARE MAGAZINE

O întâlnire cu știința, tehnologia și antreprenoriatul

redem că tehnologiile disruptive pot rezolva problemele majore ale lumii. De aceea, unul dintre scopurile noaste este acela de a accelera dezvoltarea unui ecosistem dedicat inovațiilor tehnologice utile. Hello Tomorrow reunește pe cei care aduc schimbarea, de toate vârstele și din toate categoriile, de la știință și tehnologie la afaceri și elaborarea politicilor, prin organizarea unei Comunități Interdisciplinare, un eveniment global Tech Startup Challenge și a unei Conferințe Internaționale. Hello Tomorrow este o inițiativă globală non-profit unde știința și tehnologia întâlnesc spiritul antreprenorial pentru a construi viitorul. Îi provocăm pe cei ambițioși și dornici să aducă schimbarea, pe cei care conștientizează problemele a șase domenii distincte cu care se confruntă azi societatea, precum și pe cei care vor să își ducă proiectele lor la nivelul următor sau să concureze pentru mentorat. Premiile sunt în valoare de peste 400.000 USD. Termenul limită pentru aplicații este 28 Februarie 2015. Cele șase domenii vizate sunt: • Alimentație și agricultură, • Transport & mobilitate, • Producție și materiale, • Sănătate, • Energie și mediu, IT.

investitori internaționali, potențiali parteneri și clienți, precum și alte startup-uri consacrate. Mentoring: un program de mentorat de trei luni: în funcție de nevoile sale, fiecare echipă va fi mentorată de către un expert dedicat din domeniul lor. Vizibilitate: participarea la conferința anuală de la Paris, unde vom găzdui vorbitori de clasă mondială, vom prezenta cele mai inovatoare tehnologii și vom încheia cu marea finală a competiției Hello Tomorrow. Anul trecut i-am găzduit pe scenă, alături de alții, pe Massimo Banzi, inventatorul Arduino, și Demis Hassabis, expert în Inteligența Artificială și cofondatorul DeepMind (Google). Oportunități de contacte B2B: semifinaliștii vor avea posibilitatea de a semna contractele B2B anticipate cu cei mai importanți parteneri din industria lor. Premii: Cei 7 finaliști vor câștiga Scopul nostru: să îi transformăm pe 15.000 EUR fiecare, iar marele câștigător inventatorii din întreaga lume în antrepre- va primi 100.000 EUR. nori de succes, prin accelerarea dezvoltării inovației și prin introducerea ei pe piață. Condiții de aplicare < 250.000 EUR din investiții externe, Ce câștigă cei 30 de semifinaliști? < 2 ani de la fondare. Credibilitate și networking: startup-urile va fi puse în contact cu

Date importante în 2015:

Credem că sunt startup-uri din România care merită să fie pe scenă la Marea Finală din 25 iunie la Paris! Aștept cu nerăbdare să vă arăt scena pariziană a tehnologiei și inovației. Aplicați acum la http://hello-tomorrow.org !

Termenul limită pentru aplicații: 28 Februarie 2015 Dacă ai nevoie de alte informații, scrie-ne la adresa cluj@hello-tomorrow. org, urmărește-ne pe Twitter twitter.com/ HT_Cluj și Facebook: facebook.com/ HelloTomorrowRomania. Oana Călugăr

calugar.oana@gmail.com Ambassador în România @ Hello Tomorrow

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

www.todaysoftmag.ro | nr. 32/februarie, 2015

antreprenoriat

How to Web MVP Academy

ucurești, 27 ianuarie 2015 – Finanțări în valoare totală de 207.000 EUR... Patru startup-uri admise în programe de accelerare cunoscute la nivel internațional... Progrese semnificative în dezvoltarea produselor și a echipelor. În rândurile următoare vă prezentăm bilanțul How to Web MVP Academy pentru echipele finaliste, la șase luni de la absolvirea programului de pre-accelerare. Axosuits, startup care dezvoltă exoscheleți medicali accesibili ca preț și ușor de folosit pentru persoanele cu dizabilități, a obținut cea de-a doua rundă de finanțare și se pregătește să demareze testele clinice pentru produs. În plus, au câștigat premiul pentru cel mai bun startup în cadrul Startup Spotlight, competiție și program de mentorat cu premii în valoare totală de 20.000 USD, precum și finala Get in the Ring Romania, favorizându-se extinderea echipei de dezvoltare a produsului.

asemenea printre echipele care au înregistrat rezultate excepționale: după absolvirea programului, aceștia au fost acceptați în Health Wildcatters, cel mai apreciat program de accelerare din SUA în domeniul sănătății, obținând în același timp și prima rundă de finanțare. Echipa getFittter Inc. s-a extins și este astăzi formată din 11 colegi și colaboratori aflați în Dallas, New York, Dusseldorf și București. S-au început deja discuțiile pentru a obține cea de-a doua rundă de finanțare. Mai mult, în luna februarie vor demara primele proiecte pilot cu trei angajatori din Statele Unite. Pe lângă acestea, sunt în tratative și cu diferite centre importante de welness și fitness din București.

“Participarea la How to Web MVP Academy ne-a ajutat să facem mulți pași înainte, iar sesiunile de mentorat ne-au încurajat să ne uităm la proiectul nostru dintr-o altă perspectivă și să gândim “out of the box”. La asta se adaugă oportunitățile de “MVP Academy a avut o contribuție networking excelente, printre cele mai bune majoră atât prin faptul că am fost acceptați din România”, a declarat Andras Kapy, într-un accelerator valoros din US, cât și prin Fondator Axosuits. evoluția foarte bună pe care am avut-o ulterior. Mai mult decât atât, programul ne-a getFittter Inc., aplicație care oferă ajutat să rafinăm și să cristalizăm anumite utilizatorilor o experiență de antre- idei pe care am avut ocazia să le discutăm și nament personalizată, se numără de să le evaluăm cu o serie de mentori extrem

nr. 32/februarie, 2015 | www.todaysoftmag.ro

de valoroși. Apreciem foarte mult lucrurile pe care le-am descoperit și învățat în cadrul programului și suntem mândri că am făcut parte din primul lot de echipe al MVP Academy”, a declarat Bogdan Predușcă, Fondator getFitter Inc. Poveștile de succes nu se opresc aici. Qalendra, motor de căutare dedicat călătoriilor, a obținut deja două runde de finanțare, pentru ca în perioada următoare să continue procesul de creștere rapidă în cadrul unui program de accelerare cunoscut din Statele Unite. Lifebox (platformă care oferă utilizatorilor oportunitatea de a crea albume de fotografii private cu prietenii acestora) și Pocketo (platformă de dezvoltare pentru dispozitive portabile) au ridicat și ele prima rundă de finanțare și sunt în prezent accelerate în Ignite 100, unul dintre cele mai apreciate programe de accelerare din UK, în timp ce Gloria Food (platformă gratuită pentru comenzi de mâncare online) a înregistrat o creștere consistentă a bazei de date de utilizatori și a lansat primele funcționalități contra cost

TODAY SOFTWARE MAGAZINE

ale produsului. Iar exemplele pot continua: peste jumătate dintre absolvenții How to Web MVP Academy au adus îmbunătățiri considerabile produselor, și-au mărit echipele și au în prezent primii clienți. Evoluția echipelor la șase luni de la finalizarea programului este prezentată în raportul de evaluare disponibil online aici. Prima ediție How to Web MVP Academy a avut loc în perioada 2 iunie – 22 iulie 2014 la TechHub Bucharest și a adus împreună 14 startup-uri din regiune care dezvoltă produse inovatoare în domeniul tehnologiei. Pe parcursul celor șapte săptămâni ale programului, acestea au participat la 11 workshop-uri dedicate și au beneficiat de 30 de ore de coaching 1 la 1 și peste 3500 de ore de mentorat oferite de 60 de profesioniști cunoscuți din industrie. Pe lângă componenta educațională, finaliștii MVP Academy au avut ocazia să dezvolte conexiuni valoroase în industrie la nivel global, intrând în legătură directă

cu investitori de tip angel, programe de accelerare și fonduri de investiții early stage. În plus, aceștia au beneficiat pe toată durata programului de acces la spațiul de co-working oferit de TechHub Bucharest și la evenimentele organizate periodic pentru comunitatea profesioniștilor în tehnologie. Pa r t i c ip â n d l a w o r k sh o p - u r i l e susținute de specialiști consacrați la nivel internațional, finaliștii MVP Academy au acumulat noțiuni esențiale de business și au înțeles cum pot dezvolta produse de succes la scară globală. Workshop-ul despre storytelling și pitching susținut de Alex Barrera (Fondator şi Editor Tech.eu şi Chief WOWness Officer Press 42), sau cel despre networking susținut de Paul Renaud (Executive Coach) se numără printre momentele cheie ale programului. În plus, Jon Bradford (Managing Director TechStars London) a fost timp de o zi alături de startup-urile din program și le-a oferit feedback într-o sesiune de private pitching.

Prima ediție a programului de preaccelerare How to Web MVP Academy s-a încheiat cu Demo Day, eveniment în cadrul căruia echipele finaliste și-au prezentat produsele și progresul înregistrat în fața a peste 180 de membri ai comunității tech regionale. O scurtă trecere în revistă a programului și a tuturor echipelor participante este disponibilă online aici. Șase luni mai târziu, patru dintre cele paisprezece echipe finaliste au fost admise în programe de accelerare cunoscute la nivel internațional, iar cinci dintre ele au primit finanțări în valoare totală de 207.000 EUR. În plus, o parte dintre echipe au demarat deja discuțiile cu potențiali investitori pentru a obține cea de-a doua rundă de finanțare. How to Web MVP Academy continuă. Echipele care dezvoltă produse inovatoare în domeniul tehnologiei vor putea aplica pentru cea de-a doua ediție a programului începând cu luna februarie. Până atunci, acestea sunt invitate să se înscrie pe siteul MVP Academy pentru a fi la curent cu ultimele noutăți. Irina Scarlat

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

www.todaysoftmag.ro | nr. 32/februarie, 2015

diverse

Registrul de biciclete

ouă biciclete furate prietenilor în aceeași săptămână, un link cu un proiect din UK asemănător primit la momentul potrivit precum și o discuție la cafea cu prietenii, au fost cei trei pași importanți care au dus la demararea Registrului de Biciclete un proiect ambițios care își propune descurajarea hoților de biciclete din România și recuperarea celor dispărute.

Ce este Registrul de Biciclete Pe scurt, Registrul de Biciclete vine în întâmpinarea unei probleme din ce în ce mai apăsătoare - furturile de biciclete. Știm cu toții din experiență sau din auzite cât de neplăcut este să te trezești fără bicicletă, mai ales când bicicleta devine un mod de viață, un fel de extensie a personalității tale. Noi am pățit-o și întâmplarea a făcut să ne găsim într-o poziție de unde am putut să luăm atitudine. Împreună cu susținătorii noștrii de la Night Build, am creat Registrul de Biciclete - o platformă menită să folosească forța comunității de bicicliști în vederea descurajării furturilor și a recuperării bicicletelor dispărute.

Cum funcționează Proiectul încurajează bicicliștii să-și lege bicicleta de numele lor pe baza seriei de cadru a fiecărei biciclete. De asemenea, încurajăm evidențierea înregistrării printr-un tag special aplicat pe cadru, care avertizează hoții că bicicleta face parte dintr-un sistem și că poate fi mai ușor reperată. Astfel, după crearea unui cont pe site, biciclistul își poate înregistra bicicleta după cum urmează:

1. Citește-i seria de cadru

2. Adaugă poze

3. Introdu caracteristici

4. Aplică un tag de identificare

Dacă ți se fură bicicleta

Statusul la ora actuală • 4200 de bicicliști înregistrați; • O rețea de 88 Info Points în toată țara; • Parteneriate semnate cu Poliția din Prahova și Cluj Napoca, cu demersuri de a obține sprijinul Poliției Române; • Demersuri de colaborare cu alte sisteme asemănătoare din Europa; • Vizibilitate și susținere din partea principalelor concursuri și festivaluri velo din toată țară; • Promovare și afișe informative în principalele localuri frecventate de bicicliști din țară; • Promovare și susținere din partea multor concursuri și festivaluri de sport, muzică și film din toată țara;

1. Intri pe site și schimbi statusul bicicletei în “Furată” lăsând datele tale de contact; 2. Bicicleta apare pe site în secțiunea “Biciclete furate”, vizibilă la nivel național; 3. Dacă hoțul încearcă să o vândă, orice potențial cumpărător va putea verifica bicicleta în sistem înainte de cumpărare; 4. Dacă bicicleta se dovedește a fi furată, potențialul cumpărător nu doar ca va fi descurajat să cumpere, dar va putea contacta proprietarul de drept Mișcarea “Bike2Work” și organele de poliție, acționând ca un În toamna anului trecut, împreună cetățean responsabil. cu JCI Cluj Napoca am demarat mișcarea “Bike Funcția Transfer 2 Work”, un proiect care își propune stimularea mersului la serviciu cu bicicleta. Printre altele, ne propunem să unim vocile angajaților care merg cu bicicleta, să facilităm comunicarea dintre Bineînțeles, bicicleta se poate înstrăina, nevoile lor și ale companiilor în contextul de exemplu în cazul vânzării, prin funcția infrastructurii locale și a siguranței de “Transfer” de pe site. circulației în general. Până în momentul de față, am elaborat două chestionare - unul adresat companiilor și celălalt angajaților pentru a afla părerea ambelor părți despre bicicletă, ca mijloc de transport la locul de muncă. De asemenea am organizat și un marș de conștientizare încheiat cu câteva discursuri printre care și cel informativ din partea Poliției locale. S-au acordat și câteva premii surpriză participanților.

nr. 32/februarie, 2015 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Cum vi se pare ideea de a încuraja angajații să vină la lucru cu bicicleta?

companiei. Putem menționa aici date statistice1 care arată că bicicliștii își iau cu aproximativ 15% mai puține zile de concediu medical anual și faptul că se O idee bună, susținem! constată o îmbunătățire a imaginii și Depinde de a performanțelor companiilor care își implicațiile din încurajează angajații să facă sport. partea companiei. Avem în acest sens un plan elaboNu suntem interesați. rat prin care propunem diverse facilități angajaților în vederea încurajării folosirii Altele. bicicletei fie în timpul liber, ca o alternativă Ai aprecia efortul companiei tale de a-ți oferi a mersului la sală, fie ca mijloc de transport facilități legate de biciclete? la serviciu.

Pentru bicicliștii existenți în companie

Da. Nu. Altele.

Propunerea noastră pentru companii

• autocolante de identificare a bicicletelor; • card de reduceri la magazine de biciclete; • tricouri; • echipament și accesorii personalizate cu identitatea companiei; • sisteme alternative de securizare (trackere GPS).

alese individual de către angajați (detaliile urmând a se discuta cu fiecare companie în parte, în funcție de preferințe).

Planuri de viitor • Creșterea masei critice de bicicliști înregistrați; • Semnarea unui parteneriat stabil cu Poliția Română; • O aplicație mobile pentru înregistrare rapidă și alte funcționalități utile; • Diversificarea metodelor de protejare a bicicletelor; • Consolidarea colaborării cu sisteme asemănătoare din Europa; • Promovarea mersului cu bicicleta în cadrul companiilor, universităților și a altor instituții.

Cum menționamși mai sus dorim să stimulăm mersul cu bicicleta din mai multe direcții, în cazul de față adresându-ne companiilor. Există nenumărate studii care arată beneficiile mersului cu bicicleta, atât din perspectiva sănătății cât și a mediului, Pentru cei care nu au încă bicicletă cu implicații directe sau indirecte asupra Am dezvoltat împreună cu comercianții de biciclete care susțin proiectul nostru, o schemă de achiziții de biciclete. Probabil ați auzit de scheme asemănătoare în alte țări europene, una dintre ele fiind cea din Marea Britanie - Cycle Scheme, prin care companiile oferă biciclete ca beneficiu pentru angajați. Pornind de la acest model am încercat să adaptăm totul la cadrul legislativ din România și am găsit câteva variante posibile pentru a facilita achiziționarea de biciclete prin companie, fie ca parc de biciclete și rasteluri personalizate ale companiei, fie ca biciclete

Diana Silaghi

diana@registruldebiciclete.ro PR Manager @ Registrul de Biciclete

1 ecf.com/press-corner/cycling-facts-and-figures/

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 oﬀerings are business focused, they drive real, tangible value.

www.3pillarglobal.com

www.todaysoftmag.ro | nr. 32/februarie, 2015

comunități

Comunităţi IT

untem într-o perioadă a anului plină de evenimente mari și de calitate. TSM va încerca să participe la toate aceste evenimente, invitându-vă și pe voi. Noile ediții MOBOS, ..even mammoths can be Agile, Cluj Innovation Days 2015 vor atrage cu siguranță noi participanți, pe lângă publicul care îi cunoaște deja din edițiile precedente. Semnalăm la Timișoara prezența lui Neal Ford, director și arhitect la ThoughtWorks, care va prezenta în cadrul Software Architecture Day Timișoara .

Transylvania Java User Group Comunitate dedicată tehnologiilor Java. Website: www.transylvania-jug.org Data înfiinţării: 15.05.2008 / Nr. Membri: 599 / Nr. Evenimente: 47 Comunitatea TSM Comunitate construită în jurul revistei Today Software Magazine. Websites: www.facebook.com/todaysoftmag www.meetup.com/todaysoftmag www.youtube.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 2068/Nr. Evenimente: 28 Cluj Business Analysts Comunitate dedicată analizei de business Website: www.meetup.com/Business-Analysts-Cluj Data înfiinţării: 10.07.2013 / Nr. Membri: 91 / Nr. Evenimente: 8 Cluj Mobile Developers Comunitate dedicată tehnologiilor mobile Website: www.meetup.com/Cluj-Mobile-Developers Data înfiinţării: 05.08.2011 / Nr. Membri: 264 / Nr. Evenimente: 17 The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software. Website: www.agileworks.ro Data înfiinţării: 04.10.2010 / Nr. Membri: 437 / Nr. Evenimente: 93 Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice. Website: www.meetup.com/Cluj-Semantic-WEB Data înfiinţării: 08.05.2010 / Nr. Membri: 192/ Nr. Evenimente: 29 Romanian Association for Better Software Comunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare. Website: www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 251/ Nr. Evenimente: 14 Tabăra de testare Comunitate formată din testeri și alți profesioniști din industria IT care, în cadrul unor întâlniri informale lunare, împărtășesc din cunoștințele proprii și învață din experiențele profesionale ale celorlalți membri. Website: www.tabaradetestare.ro Data înfiinţării: 15.01.2012/Nr. Membri: 1243/ Nr. Evenimente: 107

nr. 32/februarie, 2015 | www.todaysoftmag.ro

Calendar Februarie 18 (Cluj) Lansarea numărului 32 al Today Software Magazine www.todaysoftmag.ro Februarie 19-20 (Cluj) MOBOS - recomandat de TSM http://romobos.com/ Februarie 18 (Iași) Open Hack Night meetup.com/Hackerspace-Iasi/events/220554784/ Februarie 18 (Timișoara) Introduction to kdb+ meetup.com/Kx-Timisoara/events/220274397/ Februarie 24 (Timișoara) Software Architecture Day Timișoara timisoara.softwarearchitectureday.ro Martie 6 (Cluj) ...even mammoths can be Agile - recomandat de TSM colorsinprojects.ro/eveniment-cluj-6-7-martie-2015 Martie 19-20 (Cluj) Cluj Innovation Days - recomandat de TSM http://clujinnovationdays.com/ Februarie 28 (Cluj) Selenium Saturday t e c h a c a d e m y . r o / s c h e d u l e / february-workshop-selenium-saturday/ Martie 31(București) Mobile Advertising Congress conference-arena.com/mobile-advertising-congress

programare

Experimentul cu WATCHKIT SDK Crearea unei aplicații de navigație

dată cu apariția WatchKit SDK https://developer.apple.com/watchkit/), mulți programatori pe iOS au început să experimenteze cu acesta și au scris articole despre provocările întâmpinate în timpul implementării.

Chertes Cristian

chertes.cristian@telenav.com iOS Developer @ Telenav

Urmărind acest trend, articolul de față descrie prima noastră impresie după abordarea WatchKit SDK-ului și provocările întâmpinate în timpul creării aplicației de navigație pentru ceasuri folosind Scout SDK-ul nostru1.

De exemplu, unui obiect care afișează text i se poate schimba doar culoarea și textul, în timp ce pe telefon sunt mult mai multe customizații posibile. E posibil ca acest lucru să se schimbe cu apariția următoarei versiuni a WatchKit SDK. Interfața cu utilizatorul a aplicației de pe ceas poate fi actualizată cu ajutorul extensiei care rulează pe telefon. Extensia poate să comunice cu aplicația iWatch prin outlet-urile legate cu obiectele de interfața din iWatch – toată logica din spate rulează în extensie.

Configurarea proiectului în Xcode Korosi Csongor

korosi.csongor@telenav.com iOS Developer @ Telenav

Arhitectura unei aplicații Watch După cum se poate observa în diagrama de jos, o aplicație pentru ceasuri este compusă din două parți: o extensie care rulează pe telefon și o aplicație care rulează pe iWatch2. Aplicația pentru ceas conține doar interfața cu utilizatorul - un fișier de tip storyboard și imagini statice care sunt afișate în interfața aplicației. Obiectele de interfață afișate pe ceas nu sunt obiecte moștenite din UIView, ci obiecte proxy care moștenesc din clasa NSObject. Aceasta înseamnă că randarea customizată sau animațiile nu sunt posibile. Deocamdată, customizarea acestor obiecte este foarte limitată comparativ cu obiectele UI folosite pe aplicațiile iPhone. 1 http://developer.skobbler.com/support#download 2 https://www.apple.com/watch/

1. Pentru început, trebuie să aveți instalată versiunea 6.2 a aplicației Xcode. 2. Pentru adăugarea target-ului aplicației pentru ceas la un proiect existent, adăugați un Watch App target (File -> New target) 3. Cele doua target-uri noi vor fi create.

Una pentru extensie și una pentru aplicația pentru ceas. După cum se observă în imaginea de mai jos, target-ul aplicației pentru ceas include doar un fișier de tip storyboard și imagini statice care vor fi afișate pe ceas. Logica aplicației va fi implementată în extensie.

www.todaysoftmag.ro | nr. 32/februarie, 2015

programare Experimentul cu WATCHKIT SDK

WatchKitDemo: com.skobbler.WatchKitDemo

WatchKit Extension: com.skobbler.Watch4. Selectați target-ul Watch app și rulați aplicația. Asigurați-vă WatchKitDemo KitDemo.watchkitextension că unul din display-urile externe ale simulatorului e selectat. WatchKitDemo Watch App: com.skobbler.WatchKitDemo. watchapp

7. Selectați secțiunea Capabilities a target-urilor iOS și Watch app. Navigați la secțiunea App Groups și activați-o. Ar trebui să vedeți următoarele:

5. Înainte de a trece la următorul capitol, mai este un lucru de făcut - comunicarea între aplicația iOS și extensia WatchKit, care este posibilă doar printr-un fișier comun. În primul rând, deschideți secțiunea Identifiers de pe https://developer.apple. com Selectați ID-ul aplicației și activați opțiunea App Group. După configurare, regenerați profilul care folosește acest ID. Notă: vă rugam să folosiți app id-ul propriu pentru activarea App Groups. 6. Întoarceți-vă în Xcode și configurați bundle identifiers pentru fiecare target pe baza app id-ului configurat pe portalul Apple.

Aplicația WatchKitDemo

Prima dată, să aruncăm o privire la rezultatul final: dropbox.com/s/afngxdskl8l1390/WathKitDemo.mov

Aplicația WatchKitDemo pornește o navigație între două locații de pe hartă folosind Scout SDK. Cu aplicația rulând pe ceas, iar extensia și aplicația mobila pe iPhone, utilizatorii văd instrucțiuni vizuale și distanța până la acestea. Când ecranul ceasului e atins, se afișează o imagine a hărții cu o rută și poziția curentă. Aceasta este actualizată la câteva milisecunde. Comunicarea între extensie și aplicația de pe iPhone se face printr-un fișier comun. Pentru aceasta, programatorii trebuie să activeze opțiunea App Groups în iTunes Connect și să configureze bundle identifiers pentru fiecare target. Pentru că nu este vreun API pentru comunicarea directă între aplicația de pe iPhone și extensie, inițial am vrut să folosim un NSTimer pentru actualizarea informațiilor afișate pe ceas la câteva milisecunde. Aici provocarea era că nu am fost notificați când fișierul comun era modificat. Soluția a fost utilizarea unui obiect MMWormhole. El notifică aplicația și extensia când fișierul comun era modificat, astfel încât nu am mai avut nevoie de NSTimer. Obiectul MMWormHole trebuie inițializat atât în aplicația de pe iPhone cât și în extensie: self.wormHole = [[MMWormhole alloc] initWithApplicationGroup Identifier:@”group.WatchKitDemoGroup” optionalDirectory:nil];

Pentru a trimite și primi informații între aplicație și extensie folosiți:

nr. 32/februarie, 2015 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

//send message from the app to the extension [self.wormHole passMessageObject:imageData identifier:@”image”]; //listen for messages in the extension [self.wormHole listenForMessageWithIdentifier:@”image” listener:^(id messageObject) {}];

• WatchKit SDK nu trimite informații în legătură cu orientarea ceasului. Sperăm ca în următoarea versiune a librăriei aceste probleme să poată fi rezolvate.

Aplicația creată este o demonstrație a ceea ce pot face programatorii cu Scout SDK și WatchKit SDK. Câteva scenarii posibile sunt: • afișarea hărții (demonstrată în aplicația demo); • afișarea adnotațiilor; • calcularea și afișarea rutelor; • navigare (în aplicația demo este un exemplu de navigare turn by turn cu indicații vizuale); • efectuarea căutărilor și afișarea rezultatelor; • descărcarea pachetelor de hartă care pot fi utilizate în mod offline; • afișarea rutelor bazate pe fișiere GPX; • desenarea poligoanelor, cercurilor și liniilor pe hartă. Proiectul demo se poate descărca de aici: skobbler.com/iphonebuilds/20150116/WatchKitDemo.zip

Rezumat și observații

• WatchKit SDK este ușor de folosit și bine documentat, cum ne așteptăm de la o librărie nativă Apple. Implementarea aplicației a durat o singură zi, fără cunoștințe anterioare despre SDK. • Unul din cele mai mari dezavantaje a WatchKit SDK este că aplicația trebuie să ruleze pe iPhone în timpul funcționării acesteia pe ceas. Acest lucru se întâmplă datorită faptului că toate informațiile provin de la aplicația de pe iPhone. Am fi preferat să putem folosi aplicația pe ceas chiar și în absența iPhone-ului. • Nu există vreun API public pentru trimiterea informațiilor de la aplicația de pe iPhone la extensie. Singura soluție este folosirea unui fișier comun care conține perechi cheie-valoare. Acestea pot fi accesate și modificate în același timp de doi participanți.

www.todaysoftmag.ro | nr. 32/februarie, 2015

programare

JavaFX și comunicarea prin RESTful Web Services (II)

n continuarea articolului din numărul trecut vă supunem atenției crearea unor servicii web REST care interacționează cu date persistate. Pentru început vă oferim o introducere în JAXB.

Silviu Dumitrescu

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

Diana Bălan

Diana.Balan@accesa.eu Java developer @ Accesa

Java Architecture for XML Binding este un standard Java ce definește modul în care obiectele Java sunt convertite în și din XML. El folosește o colecție de mapări standard și definește un API pentru citirea și scrierea obiectelor Java în și din XML. Următoarele adnotații importante se folosesc pentru JAXB: • @lR o ot E lement ( namesp ace = „namespace”), definește elementul rădăcină al arborescenței XML, • @XmlType(propOrder = { „field2”, „field1”,.. }), permite definirea ordinii în care câmpurile sunt scrise în fișierul XML, • @XmlElement(name = „newName”), definește numele elementului XML, în cazul în care folosim un nume diferit față de cel din JavaBean .

public String getAuthor() { return author; }

Alte adnotații vor fi descrise direct în cod, în momentul în care ele apar. Primul exemplu este al unei aplicații stand alone. Modelul obiectului, ce va fi scris în, respectiv citit din fișierul XML este dat de următorul cod: @XmlRootElement(name = „message”) // Mandatory @XmlType(propOrder = { „author”, „description”}) // Optional public class Message { private String name; private String author; @XmlElement( name = „description”) // Optional public String getName() { return name; } public void setName(String name) { this.name = name; }

nr. 32/2015 | www.todaysoftmag.ro

public void setAuthor( String author) { this.author = author; } }

Vom complica un pic modelul anterior împachetându-l într-un alt model: @XmlRootElement( namespace = „topic”) public class Topic { @XmlElementWrapper( name = „topicList”)

diverse

TODAY SOFTWARE MAGAZINE

// the name of the wrapper element

topicList.add(message2);

@XmlElement(name = „message”) // the name of the collection // element

Topic topics = new Topic(); topics.setTopicDescription(„about topic”); topics.setTopicList(topicLst);

private ArrayList<Message> topicList; private String topicDescription;

// create JAXB context and instantiate marshaller JAXBContext context = JAXBContext. newInstance(Topic.class);

public voidsetTopicList (ArrayList<Message> topicList) { }

Marshaller m = context.createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);

this.topicList = topicList;

// Write to System.out m.marshal(topic, System.out);

public ArrayList<Message> getTopicList() { return topicList; }

// Write to File m.marshal(topic, new File(TOPIC_XML));

public String getTopicDescription() { return topicDescription; } public void setTopicDescription (String topicDescription) { }

this.topicDescription = }

topicDescription;

În aplicația de test vom crea fișierul xml corespunzător modelului anterior și apoi îl vom citi.

}

// get variables from our xml file, created before System.out.println(); System.out.println(„Output: „); Unmarshaller um = context.createUnmarshaller(); Topic topic2 = (Topic) um.unmarshal(new FileReader( TOPIC_XML)); ArrayList<Message> list = topic2.getTopicList(); for (Message message : list) { System.out.println(„Message: „ + message.getName() + „ from „ + message.getAuthor()); } }

JAX-RS suportă crearea automată a fișierelor XML și JSON prin JAXB. Pentru aceasta într-un Dynamic Web Project facem următoarele setări:

Servicii RESTful CRUD (Create, Read, Update, Delete) Acest tip de servicii ne permite să gestionăm o listă de modelele create, prin apeluri HTTP. Pentru început, într-un Dynamic web project vom crea un model și un singleton, ce servește ca provider de date pentru model. Pentru definirea singleton-ului am folosit implementarea bazată pe enumerare.

public class TopicMain { private static final String TOPIC_XML = „./topic.xml”; public static void main(String[] args) throws JAXBException, IOException { ArrayList<Message> topicList = new ArrayList<Message>(); Message message1 = new Message(); message1.setName(„message 1”); message1.setAuthor(„Ion Ionescu”); topicList.add(message1); Message message2 = new Message(); message2.setName(„message 2”); message2.setAuthor(„Vasile Vasilescu”);

@XmlRootElement public class Todo { private String id; private String summary; private String description; public Todo() { } public Todo(String id, String summary) { this.id = id; this.summary = summary; } public String getId() { return id; } public void setId(String id) { this.id = id; } public String getSummary() { www.todaysoftmag.ro | nr. 32/februarie, 2015

programare JavaFX și comunicarea prin RESTful Web Services (II) }

return summary;

public void setSummary(String summary) { this.summary = summary; } public String getDescription() { return description; } public void setDescription(String description) { this.description = description; } } public enum TodoDao { instance; private Map<String, Todo> contentProvider = new HashMap<String, Todo>();

}

private TodoDao() { Todo todo = new Todo(„1”, „Learn REST”); todo.setDescription(„web service”); contentProvider.put(„1”, todo); todo = new Todo(„2”, „Do something”); todo.setDescription(„something else”); contentProvider.put(„2”, todo);

public Map<String, Todo> getModel() { return contentProvider; } }

Următoarele clase vor fi folosite ca resurse REST

public class TodoResource { @Context UriInfo uriInfo; @Context Request request; String id; public TodoResource(UriInfo uriInfo, Request request, String id) { this.uriInfo = uriInfo; this.request = request; this.id = id; } @GET @Produces(MediaType.TEXT_XML) public Todo getTodoHTML() { Todo todo = TodoDao.instance.getModel().get(id); if (todo == null) throw new RuntimeException(„Get: Todo with „ + id + „ not found”); return todo; } @PUT @Consumes(MediaType.APPLICATION_XML) public Response putTodo(JAXBElement<Todo> todo) { Todo c = todo.getValue(); return putAndGetResponse(c); } @DELETE public void deleteTodo() { Todo c = TodoDao.instance.getModel().remove(id); if (c == null) throw new RuntimeException(„Delete: Todo with „ + id + „ not found”); } private Response putAndGetResponse(Todo todo) { Response res; if (TodoDao.instance.getModel().containsKey( todo.getId())) { res = Response.noContent().build(); } else { res = Response.created(uriInfo.getAbsolutePath()) .build(); } TodoDao.instance.getModel().put(todo.getId(), todo); return res; }

nr. 32/februarie, 2015 | www.todaysoftmag.ro

} @Path(„/todos”) public class TodosResource { @Context UriInfo uriInfo; @Context Request request; @GET @Produces(MediaType.TEXT_XML) public List<Todo> getTodosBrowser() { List<Todo> todos = new ArrayList<Todo>(); todos.addAll(TodoDao.instance.getModel().values()); return todos; } @GET @Path(„count”) @Produces(MediaType.TEXT_PLAIN) public String getCount() { int count = TodoDao.instance.getModel().size(); return String.valueOf(count); } @POST @Produces(MediaType.TEXT_HTML) @Consumes(MediaType.APPLICATION_FORM_URLENCODED) public void newTodo(@FormParam(„id”) String id, @FormParam(„summary”) String summary, @FormParam(„description”) String description, @Context HttpServletResponse servletResponse) throws IOException { Todo todo = new Todo(id, summary); if (description != null) { todo.setDescription(description); } TodoDao.instance.getModel().put(id, todo); servletResponse.sendRedirect(„../create_todo.html”); } @Path(„{todo}”) // Defines that the next path parameter after todos public TodoResource getTodo(@PathParam(„todo”) String id) { return new TodoResource(uriInfo, request, id); } }

În clasa T o d o s R e s o u r c e am utilizat anotația @ PathParam pentru a defini faptul că id este inserat ca

parametru. Rularea aplicației se poate face în mai multe moduri: • În browser, la adresa http://localhost:8080/CRUDRest/ jaxrs/todos/ • Folosind un formular html. Putem introduce datele rulând fișierul create_todo.html <!DOCTYPE html PUBLIC „-//W3C//DTD HTML 4.01 Transitional//EN” „http://www.w3.org/TR/html4/loose.dtd”> <html> <head> <title>Form to create a new resource</title> </head> <body> <form action=”../CRUDRest/jaxrs/todos” method=”POST”> <label for=”id”>ID</label> <input name=”id” /> <br /> <label for=”summary”>Summary</label> <input name=”summary” /> <br /> Description: <TEXTAREA NAME=”description” COLS=40 ROWS=6> </TEXTAREA> <br /> <input type=”submit” value=”Submit” /> </form> </body> </html>

• La adresa, http://localhost:8080/CRUDRest/jaxrs/todos/ count, vom număra item-urile todo

TODAY SOFTWARE MAGAZINE • La adresa, http://localhost:8080/CRUDRest/jaxrs/todos/1, Vom încheia acest articol cu pașii de urmat în generarea unui vom vizualiza todo-ul cu id-ul 1. Pentru un id inexistent vom serviciu web REST: avea o eroare HTTP • Verificarea următoarelor condiții: • Jersey este adăugat proiectului. Putem crea următoarea aplicație client: • JAX-RS API este adăugat proiectului. • A fost creat un model al aplicației și clasele entitate aferente. • Connection pool-ul și sursa de date JDBC au fost create pe serverul Glassfish. • Unitatea de persistență a fost creată și configurată în proiect. • Adnotațiile JAXB au fost adăugate claselor entitate JPA. • Generarea propriu zisă a serviciilor web: • Crearea serviciilor REST din clasele entitate. • Validarea claselor web service generate. • Validarea configurației în fișierul web.xml. Adnotațiile JAXB vor fi adăugate direct claselor entitate JAXB. Serviciile sunt generate ca EJB session facade. Când testăm un serviciu web trebuie să avem în vedere următoarele: • Adresa URL reprezintă corect endpoint-ul serviciului deploiat și adnotațiile metodei. • Cererile GET, PUT, DELETE, sau POST invocă metodele potrivite ale serviciului. • Metodele returnează datele așteptate.

public class Main { public static void main(String[] args) { ClientConfig config = new DefaultClientConfig(); Client client = Client.create(config); WebResource service = client.resource(getBaseURI()); Todo todo = new Todo(„3”, „Blabla”); ClientResponse response = service.path(„jaxrs”) .path(„todos”).path(todo.getId()).accept(MediaType. APPLICATION_XML).put(ClientResponse.class, todo); System.out.println(response.getStatus()); // Return code should be 201 == created resource System.out.println(service.path(„jaxrs”) .path(„todos”).accept(MediaType.TEXT_XML) .get(String.class));

Pași de urmat pentru a dezvolta un client al serviciului web REST: • Asigurarea că proiectul are adăugate toate bibliotecile necesare. • Identificarea ferestrei GUI și verificarea locului unde rezultatele invocării serviciului web vor fi afișate. • Următoarele informații sunt utile la dezvoltarea clientului: URL-ul serviciului, numele pachetului și clasa în care codul client va fi generat. • Invocarea codului în fereastra GUI. Vă dorim lectură plăcută și așteptăm cu interes întrebările voastre!

// Create a Todo Form form = new Form(); form.add(„id”, „4”); form.add(„summary”, „Demonstration of the client lib for forms”); response = service.path(„rest”).path(„todos”) .type(MediaType.APPLICATION_FORM_URLENCODED) .post(ClientResponse.class, form); System.out.println(„Form response „ + response .getEntity(String.class)); System.out.println(service.path(„jaxrs”) .path(„todos”) .accept(MediaType.TEXT_XML).get(String.class)); } private static URI getBaseURI() { return UriBuilder.fromUri( „http://localhost:8080/CRUDRest”).build(); } }

www.todaysoftmag.ro | nr. 32/februarie, 2015

programare

Soluții non-invazive ale tehnologiei în domeniul medical (Kinect)

ste uimitor cât de mult s-a făcut apel la soluții din domeniul tehnologic pentru rezolvarea diferitelor tipuri de probleme care au apărut în ultimii zece ani. Răspunsul la întrebarea “de ce tehnologia?” este cât se poate de evident: trăim într-o perioadă în care totul se rezumă la a lucra cu un volum foarte mare de informații, iar rezultatele trebuie să fie rapide și precise.

Nici domeniul medical nu reprezintă o excepție: specialiștii cer soluții tehnologice pentru a înlocui sau a îmbunătăți vechi procedee existente. De la procesul de analiză a sângelui până la operațiile pe creier, totul este supravegheat și îndrumat de softuri sau dispozitive hardware create special pentru fiecare situație în parte. Investiția materială și intelectuală implicată în dezvoltarea de astfel de soluții este una uriașă, nefiind accesibilă unui simplu programator. Din fericire însă, deși a trecut relativ neobservată până nu demult, piața gadgeturilor oferă foarte multe soluții cu potențial mare, la prețuri relativ reduse. Afirmația mea, cum că această piață a trecut neobservată, nu este întâmplătoare deoarece aproape tot development-ul soft realizat în domeniul gadgeturilor a fost orientat spre gaming sau creat pentru a face mai ușoară viața celui care le folosește. Există tot felul de senzori jucăuși, care mai de care mai interesanți, toți având același scop principal: furnizarea unei experiențe cât mai plăcute utilizatorului, în timp ce acesta își parcurge ”misiunea”, fie că aceasta are loc în mediul virtual ori în lumea reală. Nu o să enumăr sumedenia de gadgeturi care există, ci mă voi opri direct la Microsoft Kinect.

Kinect-ul este un dispozitiv ce vine la pachet cu Xbox (360 sau One) și care este de fapt o cameră video cu un senzor capabil să detecteze mișcările corpului, scopul lui fiind evident industria jocurilor. Cum f unc ț ione ază el de fapt ? Ajutându-se de senzorul care calculează rezultatele furnizate de coliziunea razelor infraroșu cu obiectele din fața dispozitivului, acesta creează o hartă de adâncime. Apoi, cu ajutorul acestei hărți, se identifică cele 20 de puncte ce alcătuiesc scheletul care este folosit pentru reproducerea mișcărilor corpului. Acest senzor detectează mișcări la o distanță cuprinsă între 0.7 - 6 m. Pe cât posibil, lumina din încăpere trebuie să fie una naturală (menționez aici că pentru Kinect One acest aspect mai reprezintă o problemă atât de mare, după cum afirmă cei de la Microsoft). Mai mult decât atât, senzorul este capabil să recunoască un număr de aproximativ 100 de puncte la nivelul feței, un lucru foarte important și valoros, deoarece există foarte puține dispozitive care să ofere un asemenea beneficiu la un preț accesibil. Poate vă întrebați cum am reușit eu să fac legătura între domeniul medical și Microsoft Kinect. Unde este legătura? Povestea mea și a colegilor mei, Rareș Urdea și Bogdan Pop, îndrumați de domnul profesor Dan Mircea Suciu, vă va lămuri nedumerirea. Acum mai bine de un an, având că scop participarea la unul din cele mai prestigioase concursuri din domeniul software destinate studenților și elevilor numit Imagine Cup, am încercat să găsim o soluție câștigătoare. Însă după multe ședințe de brainstorming, încă nu reușeam să găsim ceea ce credeam noi că ne va ajuta să ajungem până în marea finală. Domnul

nr. 32/februarie, 2015 | www.todaysoftmag.ro

profesor, având o experiență reușită din anii precedenți la același concurs, ne-a propus această combinație între Kinect și domeniul medical. Și așa a apărut sMilestone, aplicația medicală care dorește să faciliteze procesul de recuperare a persoanelor ce suferă de paralizii faciale. Mai exact, prin intermediul micilor joculețe din aplicație, se pot înlocui exercițiile ce creează o stare de disconfort pacienților în timpul unei sesiuni de terapie cu jocuri mult mai interactive și mai distractive. Pacientului îi este captată atenția, se pot obține măsurători și statistici mult mai exacte decât prin metodă clasică, iar doctorul poate asista mai mulți pacienți deodată. Dar cel mai important aspect de subliniat este reprezentat de faptul că această soluție este non-invazivă. Folosindu-ne de capacitatea senzorului de a detecta punctele importante la nivelul feței, am creat algoritmi corespondenți exercițiilor făcute de pacient în timpul unei ședințe de recuperare. De exemplu, jocul Snake din aplicația sMilestone permite utilizatorului să controleze șarpele prin două mișcări simple ale gurii: zâmbet - la dreapta, gură deschisă - la stânga. Astfel, în loc ca pacientul să facă aceste exerciții în față unei oglinzi, totul este mult mai captivant ținând cont că totul se bazează pe scoruri și timpi record.

programare Algoritmul care stă în spatele detectării acestor două mișcări este legat de calculul distanței dintre 2 perechi de puncte: 60-64 (colțurile gurii) pentru zâmbet, 62-66 (buza de sus - buza de jos) pentru a desc h i d e g u r a . În momentul în care s e i n iț i a l i z e a z ă jocul, se calculează o constantă, o distanță de bază între cele două perechi de puncte, care reprezintă expresia neutră. Apoi, în funcție de cât de tare se distanțează punctele pereche (aceste distanțe variază în funcție de pacient, deoarece nu toți sunt în același stadiu de recuperare), algoritmul stabilește dacă expresia produsă de pacient este un zâmbet sau o mișcare de deschidere a gurii; astfel, pacientul mișcă șarpele pentru a strânge puncte și a stabili noi scoruri record. Pentru exerciții de genul acesta, după cum spuneam, senzorul și SDK-ul Kinectului ne furniza tot ce aveam nevoie. Însă cea mai mare dificultate pe care am întâmpinat-o alături de colegii mei, a fost să creăm un algoritm capabil să detecteze limba. Așa ceva era aproape de neconceput, mai ales că soluția noastră era una care nu implică atașarea de senzori direct pe pielea pacientului.

TODAY SOFTWARE MAGAZINE După mai multe încercări, am reușit într-un final să concepem un algoritm optim și neașteptat de eficient. Stabilind o limită pentru suprafața ce trebuia procesată, mai exact doar pentru zona gurii, și ajutându-ne de harta de adâncime, în momentul în care pacientul scotea limba afară din gură, reușeam să izolăm vârful limbii și să ne folosim de el pentru a detecta orice mișcare al acestuia. Izolarea vârfului limbii este posibilă datorită proprietății hărții de adâncime, care este creată în funcție de distanță în milimetri a obiectelor față de Kinect. În momentul în care limba este scoasă, vârful acesteia este cel mai apropiat punct față de senzor și de aceea îl putem considera în algoritm a fi limba. (Vezi imaginea de mai jos.)

Imagine Cup. După cum ați putut citi până acum, SDK-ul Kinect-ului furnizează un pachet complet de librării destinate părții de captare a mișcărilor corpului sau feței. De asemenea, acesta deține și suportul pentru partea de recunoaștere a vocii, despre care pot să vă spun că este unul destul de precis; o discuție mai amănunțită despre el ar necesita un alt articol. Partea cea mai importantă ar fi că deocamdată cel mai mare suport îl are in limba engleză, beneficiarul principal pentru care este dezvoltat fiind industria jocurilor, dar este un candidat perfect pentru facilitarea terapiei pacienților ce se află într-un stadiu mai avansat de recuperare (mai exact, se adresează pacienților care pot deja să exerseze pronunția sunetelor/cuvintelor). Cred că v-am făcut deja suficient de curioși pentru a spera că unii dintre voi veți dori să vă implicați în acest domeniu. Nu pot să vă spun decât că aduce foarte multă satisfacție să știi că poți ajuta un om prin ceea ce îți place să faci cel mai mult.

De aici posibilitățile erau nelimitate: pe lângă jocul Dots, care constă într-o minge controlată de limbă ce trebuie să se ferească de alte mingi care se mișcă haotic într-o cutie, sMilestone permite utilizatorului să controleze meniul aplicației cu ajutorul limbii. Acesta este aspectul pe care noi am reușit să îl rezolvăm și care ne-a asigurat un loc printre finaliștii competiției

Mursa Bogdan

mursa.bogdan@yardi.com Software Developer @ Yardi

Objective C

jobs-cluj@yardi.com Yardi Romania

www.todaysoftmag.ro | nr. 32/februarie, 2015

programare

management

Dinamicile adoptării unei mentalități Agile

u câteva luni în urmă am participat la Conferința Scrum de la Berlin, organizată de Scrum Alliance. În cadrul acestei conferințe, am descoperit că există multe organizații care au dedicat foarte mult timp unui proces de schimbare a mentalității. Au adoptat mentalitatea agile ca răspuns la un mediu aflat în continuă schimbare, cu clienți ale căror cerințe se schimbă de la o zi la alta și unde orice timp pierdut poate reprezenta foarte multă muncă în plus, fără ca aceasta să aducă un beneficiu real. Călin-Vlad Gîngă

calin.ginga@isdc.eu

Software developer @ ISDC

nr. 32/2015 | www.todaysoftmag.ro

Atunci când vorbim despre Agile, vorbim despre un mindset, despre capacitatea de a reacționa la schimbări într-un timp cât mai scurt, despre un grup de metodologii bazate pe dezvoltare iterativă și incrementală sau despre strânsa colaborare între membrii unei echipe cu expertiză funcțională diversă. Av â n d d i s c u ț i i c u m a i m u l ț i reprezentanți ai organizațiilor despre care vorbeam mai sus, am observat că fiecare avea un alt set de probleme cu care se confruntau și că nivelul lor de cunoștințe era diferit de la unii la alții. Unele organizații erau la începutul procesului și aveau nevoie de prezentarea unor concepte fundamentale despre ce înseamnă/presupune agile, altele erau în punctul în care aveau o direcție, știau care sunt pașii următori și aveau doar nevoie de sfaturi pentru a fi siguri de direcția în care au pornit. Întrebarea pe care mi-am pus-o este: cum poate un coach agile să găsească modalitatea de transmitere a informațiilor în funcție de punctul în care se află o organizație în cadrul procesului de schimbare? Răspunsul la întrebarea mea a fost dat de Ken Power care a vorbit despre diferite roluri sau dinamici care trebuie studiate atunci când se prezintă aspectele gândirii agile. Organizațiile apelează la ajutorul

unui coach agile și devin la rândul lor clientul acestuia, produsul fiind procesul de adaptare la o nouă gândire. Un coach trebuie să adapteze formatul în care va transmite informația în funcție de nevoile fiecărui client. Aceste roluri sunt în număr de nouă și sunt determinate de orientarea clientului care poate fi spre rezultate sau spre adunarea de cunoștințe. Cele nouă roluri sunt: coach, consilier, facilitator, expert, modelator, partener, observator, profesor și consilier tehnic.

Figura 1

Observator

Scopul observatorului este de a lua parte la toate activitățile de zi cu zi ale echipei, de a observa și comenta situațiile găsite. Se concentrează îndeosebi pe momentele în care membrii echipei interacționează cel mai mult, cum sunt întâlnirile zilnice referitoare la statusul proiectului, ședințele de planificare, retrospectivele, ședințele demonstrative. Pentru a avea o imagine

TODAY SOFTWARE MAGAZINE cât mai clară asupra gradului de coeziune al echipei, observatorul poate lua parte și la activități mai puțin legate de mediul de lucru, cum sunt pauzele de masă sau pauzele de cafea. Prin toate activitățile exemplificate mai sus, observatorul va putea determina cât de bine comunică membrii echipei între ei pentru ca mai apoi să poată identifica și propune soluții pentru potențialele probleme.

Consilier Tehnic

Unul din primele roluri care ne vin în minte atunci când ne gândim la un agile coach este cel de consilier tehnic. În mediul în care noi lucrăm este fundamentală nevoia de a da și de a primi sfaturi. Orice întârziere este de cele mai multe ori cauzată de lipsa unui sfat bun la momentul oportun. Ceea ce diferențiază acest rol de toate celelalte este faptul că poate avea un adevărat impact în momentul în care clientul știe ce dorește să facă, are un plan în minte și are nevoie doar de o opinie secundară. Pentru ca acest tip de relație să funcționeze, clientul trebuie să fie deschis la păreri, să aibă o viziune corectă asupra problemei pe care o întâmpină și să fie dispus să prezinte în detaliu toate soluțiile la care s-a gândit. De partea cealaltă, consilierul tehnic trebuie să fie atent la toate aspectele discuției și să adreseze toate întrebările relevante la momentul oportun. Prin acest exercițiu, deseori, clientul va ajunge la soluția cea mai bună fără a fi nevoie de un sfat clar din partea consilierului. De ceva vreme, acest tip de abordare este folosit în tot mai multe organizații, un exemplu fiind Coaches Clinic, care se bucură de un real succes în cadrul adunărilor scrum organizate de Scrum Alliance. În aceste clinici, o discuție de un sfert de oră este mai mult decât suficientă pentru ca o persoană să găsească o soluție la

o problemă. Dacă după acest timp nu se găsește o soluție, este posibil ca situația să aibă nevoie de un alt rol dintre cele discutate mai sus. Dacă problema este una fundamentală, atunci un profesor sau expert ar putea fi folositor, dacă problema este organizatorică atunci un facilitator ar fi cu adevărat de folos.

Expert

Așa cum îi spune numele, rolul de expert este cel care identifică o problemă și știe și cum să o rezolve. După o analiză amplă a situației acesta va ști toate măsurile care trebuie luate astfel încât totul să meargă bine. Există mai multe modalități de a pune în practică soluțiile propuse. Un exemplu ar putea fi să joace rolul de Scrum Master pe durata unuia sau a mai multor iterații, să facă pair programming cu membrii echipelor sau să aleagă tool-urile care vor fi folosite de echipă. Dat fiind faptul că este un expert într-o anumită zonă, acesta va putea determina cât de urgentă este soluționarea fiecărei probleme în parte. Apoi, va avea capacitatea de a crea un plan de abordare și va putea determina atât direcția cât și primii pași în viitorul organizației. Dacă aceasta se află la început, expertul poate fi chiar parte din echipa care se ocupă de procesul de angajare.

nu fie uitat. Pe toată durata procesului trebuie să mențină o atitudine neutră și să se asigure că toți participanții la discuție au posibilitatea să-și exprime părerile. Pentru ca acest tip de relație să aibă un rezultat cât mai bun clientul trebuie să aibă încredere deplină în facilitator. Lipsa de încredere poate deveni o problemă în cadrul unei tentative de soluționare a unui conflict între două persoane sau în cadrul unui grup de persoane. Dacă ne gândim la metodologia Scrum, facilitatorul poate fi persoana care moderează prima retrospectivă a echipei. Acesta este un punct critic în viața unei echipe agile. Asigurându-se că fiecare participant va avea ocazia să își exprime îngrijorările și principiile, acesta va crea o legătură strânsă în cadrul echipei.

Profesor

La fel ca și în cazul expertului, profesorul are cunoștințe vaste în ceea ce privește prezentarea și descrierea aspectelor agilității. Scopul profesorului este acela de a împărtăși aceste cunoștințe cu întreaga organizație. Modul prin care acesta trebuie să se desfășoare este unul direct, fără multe dezbateri și schimburi de opinie. Profesorul este prezent doar pentru a-și exprima propriile cunoștințe, și nu pentru a da sfaturi sau pentru a analiza situații. Ca modalitate de prezentare, profesorul poate opta pentru seminarii sau Facilitator laboratoare referitoare la aspecte precum Facilitatorul este foarte folositor în practici XP și Scrum sau prezentări față în cadrul organizațiilor care se află la începu- față pentru un rol de Scrum Master, spre tul perioadei de tranziție spre o mentalitate exemplu. agilă. Este acel rol care ajută un grup de indivizi să ajungă la obiective comune și Modelator apoi îi asistă în atingerea acestora. De aseModelatorul este persoana care este menea, prezența unui facilitator poate fi adusă în cadrul unei companii cu scopul benefică atunci când sunt explorate diferi- de a fi un model pentru ceilalți angajați. tele riscuri care pot apărea când un grup Dacă în cazul expertului acesta juca rolul este informat despre o decizie majoră. Scrum Master-ului pentru a se asigura că Datoria unui facilitator este de a crea un lucrurile merg într-o anumită direcție, context și un mediu propice discuțiilor modelatorul va juca acest rol într-un astfel încât scopul principal al acestora să sprint iar apoi cineva va face același lucru

www.todaysoftmag.ro | nr. 32/februarie, 2015

programare Dinamicile adoptării unei mentalități Agile în următoarele sprint-uri. Modelatorul trebuie să își adapteze rolul în funcție de nevoile clientului și singurul scop al său este de a găsi o soluție optimă pe care o va pune în aplicare lăsând clientul să adune cunoștințe de-a lungul timpului. Dacă modelatorul este adus ca parte din echipă, atunci acesta poate să aibă rolul unui programator, tester sau manager. Acesta va reprezenta un exemplu în orice situație.

Consilier

Din punctul de vedere al agilității, coach-ul poate să propună idei de organizare și gestionare în cadrul unei organizații pentru a se ajunge la o asemenea mentalitate.

Partener

Când o persoană este adusă în cadrul unei organizații pentru a fi partener al clientului atunci cele două părți trebuie să pornească de la premisa că sunt implicați împreună în acest proces. Succesul unuia reprezintă succesul celuilalt și eșecul unuia reprezintă eșecul celuilalt. În cadrul unui parteneriat cele două părți vor învăța una de la cealaltă și vor conștientiza împreună riscurile, obiectivele și cultura organizației. Partenerul va fi un stakeholder și va lua parte la toate deciziile. Viziunea celor două părți trebuie să fie compatibilă și întotdeauna vor trebui să ajungă la situații câștig-câștig.

Consilierul este prezent pentru a oferi sfaturi și pentru a prezenta toate opțiunile posibile în cadrul unei discuții. Clientul va trebui să ia deciziile și să fie responsabil de rezultat indiferent care ar fi acesta. Consilierul nu poate fi învinovățit pentru un rezultat negativ la fel cum nici nu poate să i se ofere merite pentru un rezultat pozitiv. Consilierul trebuie să asculte într-un mod activ, să explice problema identificată și să evidențieze toate aspectele care au IDAM Advisory nevoie de o atenție mai mare. În cadrul ISDC există un grup de persoane numit IDAM (ISDC Defined Agile Agile coach Model) implicat în dezvoltarea unei metoProbabil cel mai comun nume al unui dologii agile, bazată pe Scrum, modificată, expert Agile este coach-ul. Acesta este per- modelată și formată pentru a fi eficientă în soana care este chemată într-o organizație mediul, cultura și organizația noastră. pentru a învăța, a ajusta, a prezenta și penUnul dintre cele mai de succes proiecte tru a discuta despre agilitate. În realitate la care lucrăm este IDAM Advisory (conel nu trebuie să învețe nimic. Rolul aces- siliere IDAM) care combină câteva dintre tei persoane este de a sugera soluții după rolurile prezentate mai sus. De cele mai o analiză preliminară. Un coach trebuie multe ori asistăm la ceremonii și activități să scoată clientul din zona de confort iar din cadrul echipelor pentru o perioadă pentru ca acest lucru să funcționeze, este determinată, timp în care observăm și ananecesar preocuparea clientului de a deveni lizăm comportamentul membrilor echipei mai bun. El va oferi suport, dar la finalul și reacția lor la apariția unor probleme, zilei clientul va decide ce să facă și cum să precum și la modul în care oferă soluții. acționeze. După tot acest proces, va oferi Gândindu-ne la aspectele prezentate mai feedback după care procesul începe din sus, aceste activități sunt făcute de un nou. observator.

nr. 32/februarie, 2015 | www.todaysoftmag.ro

În urma acestei analize ascultăm părerile din cadrul echipei, avem discuții fie față în față, fie în grup și împreună găsim soluții pentru problemele identificate. Aceste activități sunt tipice consilierului tehnic. Trecând peste aceste momente în care găsim soluții ajungem la stadiul în care echipele doresc să devină mai bune, mai eficiente și mai responsabile, moment în care au nevoie de intervenția unui coach agile. Cele trei roluri identificate mai sus reprezintă ceea ce avem noi nevoie în cadrul organizației noastre. În acest fel ne putem canaliza energia în rezolvarea adevăratelor probleme și nu petrecem timpul concentrându-ne pe alte activități care sunt reprezentative altor roluri. Având în vedere cele descrise mai sus doresc să revin la principala idee de la începutul articolului și anume abordarea unei mentalități agile în cadrul companiei. Consider că fiecare organizație trebuie să facă o analiză foarte amplă a situației în care se află și să identifice care sunt cu adevărat nevoile sale. Odată ce etapa aceasta este realizată cu succes, se poate apela la un rol care va putea prezenta conceptele agile într-un mod în care va fi folositor organizației, iar investiția va reprezenta un real succes. Un bun coach agile va ști să abordeze orice problemă, adaptându-și demersurile în funcție de situație.

management

programare

Rolul unui Business Analyst într-un proiect de dezvoltare software

esponsabilitățile unui Business Analyst (BA) într-un proiect de dezvoltare software în care se folosește metodologia Agile constituie un subiect foarte răspândit. În cadrul acestui articol vom trata doar o parte din el, încercând să oferim un răspuns la următoarea întrebare: “Care poate fi contribuția unui BA la livrarea unui proiect de dezvoltare software de către o echipă SCRUM?” Pentru a delimita și mai clar subiectul acestui articol, vom încerca să oferim răspunsul Liviu Ştefăniţă Baiu

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

din perspectiva unei echipe din cadrul unei companii IT de outsourcing (servicii externalizate). Această ‘nișă’ de domeniu permite deschiderea unei discuții prin intermediul răspunsului propus de acest articol.

Un BA in echipă? La ce ne folosește?

Aceasta este una dintre cele mai întâlnite reacții ale echipelor SCRUM. Echipa SCRUM are un Product Owner (PO) – de obicei aflat la client –, un Scrum Master (SM), un Manager de proiect (PM) și un backlog. Prin urmare, totul este destul de clar – există ‘obiectul muncii’, sunt prezente rolurile de coordonare și de raportare, există și un responsabil de produs. La ce ne folosește un BA în echipă?

Care este locul unui BA în echipă?

De fapt, în cadrul echipei SCRUM, există deja persoane care îndeplinesc atribuțiile unui BA, astfel rolul și responsabilitățile sunt deja in situ, lipsind doar o personificare a lor. Astfel, un programator senior sau un QA pot să aibă sarcini care ar fi destinate în mod normal unui BA; unele atribuțiuni sunt îndeplinite de către PM sau SM, iar altele de către PO. Astfel am obținut răspunsul pentru ‘locul’ pe care l-ar ocupa un BA in echipă. Însă trebuie să admitem faptul că în cele mai multe situații este dificil pentru o persoană

din exterior să preia responsabilitățile de la membrii unei echipe deja formate. Ce se poate face în această situație? Pentru început, ca oricare nou-venit întro echipă, un BA trebuie să câștige încrederea colegilor. Pentru a putea face asta, trebuie să înțeleagă modul de lucru al echipei din perspectiva relațiilor dintre membrii ei și a proceselor interne. Discuțiile purtate cu membrii seniori ai echipei pentru a înțelege proiectul, studiu individual despre domeniul de activitate al clientului, înțelegerea nevoilor unei organizații care activează în respectivul domeniu, înțelegerea particularităților clientului, alături de atributele clasice ale unui BA (abilități de comunicare, cunoștințe despre metodologiile de lucru, atenția la detalii, etc.), sunt doar câteva dintre mijloacele pe care un BA le poate folosi pentru a câștiga încrederea echipei. Î n a l d o i l e a r â n d , u n BA t r e buie să identifice punctele slabe ale proiectului, acestea fiind cele mai susceptibile pentru îmbunătățiri. Iată câteva dintre cele mai frecvente: • Procesele din cadrul proiectului; • Documentația proiectului (neactualizată sau inexistentă); • Relațiile cu persoanele interesate de rezultatul proiectului (stakeholders);

www.todaysoftmag.ro | nr. 32/februarie, 2015

management Rolul unui Business Analyst într-un proiect de dezvoltare software • Backlog - lista de cerințe ordonată după prioritate; • Problemele care apar cu o frecvență crescută – cerințe neclare, specificații incomplete, desig n de inter faț ă incomplet; • Nivelul de informare al echipei. Modul în care proiectul este înțeles, în ansamblul funcționalităților sale. Ultimul aspect pe care îl vom menționa, dar cu siguranță unul dintre cele mai importante, este atitudinea. O atitudine cooperantă dar fermă, prin care se subliniază faptul că eforturile și cunoștințele echipei sunt apreciate, că există dorința de a ajuta echipa și de a îmbunătăți starea de fapt. Prin urmare, putem concluziona că un BA poate să: • Diminueze presiunile din interiorul echipei prin preluarea unor responsabilități de la SM, PM, programatori sau QA seniori și chiar de la PO; • Îmbunătățească mediul de lucru și utilizarea instrumentelor de lucru.

Care sunt mijloacele pe care le poate folosi un BA pentru a se integra mai rapid în echipă?

Bazându-se pe experiența anterioară, un BA ar trebui să se poată deprinde cu noile instrumente de lucru, sau să propună variante mai bune. Așa cum am menționat anterior, trebuie să ofere variante de îmbunătățire pentru diferite aspecte ale proiectului.

Procesele

Nevoia de îmbunătățire a proceselor este un aspect prezent în foarte multe

companii IT care activează in domeniul outsourcing, mai ales datorită faptului că procesele echipei SCRUM care lucrează într-un proiect externalizat sunt constituite ca un amestec dintre procesele interne ale companiei și procesele din cadrul companiei clientului. Analistul de business (BA) trebuie să înțeleagă motivele care au determinat adoptarea proceselor curente, iar apoi trebuie să propună schimbările care ar aduce valoarea cea mai mare pentru echipă. Astfel efortul de integrare se va diminua, iar echipa și clientul vor căpăta încredere în noul membru. Instrumentele care pot fi folosite în acest caz sunt programe pentru întocmire a diagramelor de proces (ex. MS Visio), suite de aplicații pentru birou (MS Office, Libre Office, Open Office). Îm b u n ăt ăț i r e a p r o c e s e l o r d i n organizația clientului poate fi un obiectiv pentru fazele ulterioare ale proiectului, în momentul în care analistul are o poziție mai solidă și a câștigat un capital de încredere semnificativ.

(ex. Atlassian Confluence, SharePoint, Github, Atlassian Jira, VersionOne). Crearea documentelor se va face în suitele de aplicații menționate anterior. Desigur că pot apărea situații în care documentația de proiect să fie ori suficientă pentru nevoile echipei, ori absentă, dar considerăm că este loc de îmbunătățiri aproape tot timpul.

Documentația de proiect

Backlog

Documentarea specificațiilor este unul dintre aspectele care suportă îmbunătățiri de cel mai multe ori în cadrul unui proiect, din diferite puncte de vedere – al structurii, al actualizărilor, al integrării cu procesele și chiar al accesibilității. Un BA trebuie să analizeze starea curentă și apoi poate propune o soluție de ameliorare, în funcție de nevoile echipei. Exemple de îmbunătățiri: păstrarea documentelor într-un depozit accesibil (fie prin intermediul unei aplicații de versionare, fie virtual – wiki), care să permită referențierea celorlalte instrumente de urmărire a sarcinilor de lucru

nr. 32/februarie, 2015 | www.todaysoftmag.ro

Relația cu stakeholder-ii (persoanele interesate de proiect)

Pentru a putea să amelioreze acest aspect, analistul trebuie să cunoască stakeholder-ii, să identifice și să cadă de comun acord asupra unui plan de comunicare cu aceștia, dar, mai ales, să aibă girul conducerii firmei pentru a gestiona comunicarea. Mijloacele pe care le poate folosi sunt matrici RACI/RASCI (ResponsibleAc c o u nt ab l e - C o n s u l t e d - In f o r m e d / R e s p o n s ib l e - Ac c o unt ab l e - Su p p o r t C o n s u l t e d - In f o r m e d ) , p l a nu r i d e comunicare, la a căror întocmire să participe activ și analistul. Această componentă a proiectului este una sensibilă, fie că este vorba de cerințele pentru produs sau doar cele ale echipei (Product Backlog și Team Backlog), pentru că în aceste elemente se regăsesc în modul cel mai vizibil procedurile și ‘obiceiurile’ vechi ale proiectului. Acest fapt determină rezistența sporită la schimbare, chiar dacă există argumente solide. Există anumite tipuri de argumente care pot fi coroborate pentru a obține acceptarea schimbărilor, și anume: alinierea cu metodologia de lucru, consistența și claritatea cerințelor,

TODAY SOFTWARE MAGAZINE structurarea și îmbunătățirea elementelor detaliilor către echipă este, de asemenea, backlog-ului (Epic – User Story – Task), un pas important. dar și a specificațiilor aferente, sunt câteva exemple în acest sens. Informare Echipa SCRUM trebuie cunoască Problemele care apar cu o frecvență detalii despre proiect, despre produs, dar crescută – cerințe neclare, specificații trebuie să aibă și o imagine de ansamincomplete blu despre schimbările care se petrec în Aceasta este o provocare ‘pozitivă’ pen- organizația clientului și în domeniul de tru analist într-un proiect nou, pentru că activitate al acestuia. Deși nu afectează lipsa de claritate a cerințelor, absența sau direct munca echipei, aceste informații calitatea slabă a specificațiilor sau designu- influențează moralul acesteia, crescând lui sunt situații care permit analistului să nivelul de importanță care se acordă munprezinte soluții rapide și vizibile. cii fiecăruia dintre membrii ei. În același Pentru a oferi soluții acestor probleme, timp, analistul câștigă un capital de încreanalistul are la îndemână o paletă largă de dere prin faptul că oferă aceste informații. aplicații, după cum urmează: Pentru a crește nivelul de informare, • Pe n t r u m a c h e t e ( m o c k - u p s ) analistul are la îndemână o serie de funcționale: Balsamiq, moqups, Just in instrumente, cum ar fi: discuții ad-hoc, Mind; interacțiuni regulate cu membrii echipei • Pentru elemente de design de (în cadrul ceremoniilor SCRUM), prezeninterfață (UI): Photoshop, Paint.Net, tări ocazionale de informare. Gimp. Analistul trebuie să țină cont de convențiile existente legate de culori, de existența unui responsabil de design în organizația clientului sau în cadrul echipei. Una dintre cele mai importante calități ale unui analist este abilitatea de a identifica în mod precis acele cerințe care necesită astfel de detaliere. Prezentarea

adăugând valoare produsului dar și celor două organizații implicate. Așa cum menționam în primele paragrafe, feedback-ul pentru argumentația de mai sus este binevenit și va fi luat în considerare pentru viitoarele articole despre beneficiile pe care le poate aduce un BA într-un proiect de dezvoltare software externalizat care folosește metodologia SCRUM.

Concluzii

Există o largă paletă de tehnici și instrumente care stau la dispoziția unui BA pentru a se integra într-o echipă SCRUM și pentru a-și aduce aportul la succesul proiectului. Folosind abilitățile și instrumentele prezentate mai sus, analistul poate influența atât procesele interne ale echipei, cât și procesele din organizația clientului,

www.todaysoftmag.ro | nr. 32/februarie, 2015

programare

Patru idei pentru îmbunătățirea Software Design-ului

oftware Design se numără printre ultimele trenduri care impresionează domeniul IT. Se pare că în fiecare an apar alte câteva idei de design. Mai întâi au fost design patterns. MVC este modul în care construim aplicații web, în timp ce idei cum ar fi: domain driven design, porturi și adaptoare, microservices se bucură de adopție și interes crescut.

Alexandru Bolboacă

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

Am învățat software design făcând, cu un mentor care a ținut să-mi dea un feedback foarte util, deși uneori enervant. Acest lucru a fost înainte să știu despre design patterns, SOLID principles sau TDD. Prin urmare, înțelegerea mea pornește de la legile de bază ale software design-ului. De aceea, atunci când lucrez cu dezvoltatori, eu sau colegii mei, îi învățăm nu numai design patterns și SOLID principles, dar și cum să gândească designul aplicațiilor. Iată patru idei pe care ar trebui să le iei în considerare atunci când iei o decizie de design pentru a obține software design mai bun:

1. Fiecare decizie de design are avantaje și dezavantaje

Când facilitez exerciții de arhitectură sau design, cum ar fi Architectural Kata,Code Retreats sau unul dintre workshop-urile de software design, le cer participanților să creeze un design, fie scriind cod fie sub formă de diagramă. Apoi discutăm și oferim feedback soluției lor. De multe ori, un participant îmi cere să dau „cea mai bună soluție” pentru problema respectivă. Răspunsul neașteptat este că nu există „cea mai bună soluție”. Realitatea este că orice decizie de software design are avantaje și dezavantaje. Dar la urma urmei, iată o listă succintă a caracteristicilor unui design bun: • Dezvoltare rapidă, • Ușor de schimbat, • Ușor de găsit problemele, • Sigur, • Rapid, • Scalabil, • Reduce șansa de greșeli.

nr. 32/2015 | www.todaysoftmag.ro

Este imposibil să scrii cod care obține un 10/10 pentru toate aceste criterii simultan. De aceea avem sloganul „quick and dirty” în loc de „corect și rapid și scalabil și fără bug-uri și ușor de schimbat și ...”. Întrebarea importantă devine atunci: pentru care criteriu este acceptabil să obții un 8/10, 6/10 sau 4/10, în contextul în care te afli. Acest lucru se traduce în „cea mai potrivită” soluție pentru un anumit context; probabil că nu va arăta precum „cea mai bună soluție” la care te gândeai. Iată o poveste personală pentru a sprijini acest fapt. Când dezvoltam în C#, am descoperit că am putea folosi delegates ca expresii lambda, reducând astfel numărul de linii de cod pe care trebuia să le scriu. Am rezistat tentației deoarece colegii mei ar fi găsit acest cod confuz și ar fi crescut șansa de a face greșeli. Aș fi putut încerca să-i învăț acest mod de a scrie cod, dar nu eram atât de bun la instruirea oamenilor pe atunci. A fost o decizie conștientă pentru binele proiectului. Am două moduri de a identifica avantajele și dezavantajele, astfel încât să obțineți software design mai bun. Ori de câte ori evaluăm soluții potențiale pentru o problemă: 1. Listăm alternativele, avantajele și dezavantajele fiecăreia dintre ele și apoi facem o alegere conștientă pentru una dintre soluții. 2. Experimentăm: începem punerea în aplicare a uneia dintre soluții, fiind gata să aruncăm sau să schimbăm soluția dacă nu este destul de bună.

programare Acest proces nu trebuie să ia mult timp. De obicei, o jumătate de oră sunt mai mult decât suficiente pentru prima opțiune și maxim două ore pentru a doua. După puțină practică, vei începe să faci aceasta în mod automat pentru cele mai multe decizii. Dacă există un lucru pe care îl poți învăța din această lege, acesta ar trebui să fie: Pentru a face software design mai bun, identifică avantajele și dezavantajele soluției pe care o alegi. Întrebarea de reflecție: Care sunt dezavantajele clasei la care lucrezi? Ce ar putea merge prost?

2. Programatorii sunt utilizatorii Software Design-ului Ori de câte ori vorbim despre design în alte domenii decât software-ul, discutăm din punct de vedere orientat către utilizator. Produsele Apple sunt renumite pentru că se concentrează pe experiența unui utilizator cu dispozitivul lui: cum se simte, cum arată, cât de repede răspunde, sunetele pe care le face, etc. . Software design-ul este singurul tip de design care pare a nu avea utilizator. La urma urmei, utilizatorul final nu are nicio idee despre cum funcționează software-ul și nici nu-i pasă. Tot ce le pasă utilizatorilor finali este ca software-ul să funcționeze cum trebuie. Atunci de ce ar trebui să ne pese de structura internă a software-ului? Există motive economice foarte bune pentru a face acest lucru. În cazul în care softwareul nu este ușor de schimbat, dezvoltatorii nu vor putea adăuga caracteristici rapid, ducând la o potențială pierdere a clienților. Atunci când structura software-ului nu este organizată în mod corespunzător, ar putea să apară mai multe bug-uri care necesitând mai multe ore de săpat prin cod pentru a le repara, ar crește costurile de întreținere. Acestea nu sunt probleme noi. Designurile inițiale pentru multe obiecte pe care le folosim acum zilnic au început prin a fi slabe, dar au fost îmbunătățite în timp. Cum? Cheia stă în a asculta feedbackul utilizatorilor. În echipa noastră, Claudia lucrează full-time în timp ce eu lucrez part-time la un produs eHealth. În afară de sarcinile mele de dezvoltare, ajut ca mentor, coach și o ajut cu decizii mai dificile. Una dintre întrebările mele recurente este: „Ce a fost greu de schimbat în ultimele două săptămâni?”. Pe baza acestei întrebări, am îmbunătățit viteza de modificare a codului în zonele unde se schimbă cel mai mult.

TODAY SOFTWARE MAGAZINE Software design-ul are utilizator. Utilizatorul este dezvoltatorul care va trebui să schimbe codul pe care îl scrii. Dacă folosiți collective code ownership (ca majoritatea echipelor Scrum), ar fi bine să luați în considerare user-centric software design (software design orientat către utilizator). Și iată o idee pentru tine: ce zici despre rularea de teste de usability pe software design pentru a reduce costurile de dezvoltare? Pentru a face software design mai bun, analizează-l din punctul de vedere al altor dezvoltatori. Întrebarea de reflecție: Care sunt unele dintre plângerile comune ale colegilor tăi de echipă legate de cod? Ce este dificil să schimbați? Cum ai putea să-l faci mai ușor?

ce face aplicația. Acest lucru duce la reducerea productivității și te obosește. Nu există în acest moment nici un mod definitiv pentru a elimina distanța dintre cunoștințe și cod. Aceasta poate fi însă redusă mult de iterarea prin continuumul numelor definit de JB Rainsberger. Un sfat: veți găsi că este foarte dificil la început, dar devine mai ușor cu exercițiu. Pentru a face software design mai bun, numește clasele, metodele și variabilele cât mai aproape de domeniul de business posibil. Întrebarea de reflecție: Ce face aplicația ta? Care sunt câteva nume specifice businessului? Sunt acestea prezente în cod?

3. Numele contează mult mai mult decât îți imaginezi

Acum 40 de ani, Fred Brooks a scris o carte pentru dezvoltarea de software numit „The Mythical Man Month”. Cartea conține multe constatări esențiale despre dezvoltarea de software și inginerie pe care cei mai mulți oameni care lucrează în industrie nu le știu și nu le aplică pentru că nu au citit cartea. Cea mai importantă idee de design din carte este următoarea: Voi susține că integritatea conceptuală este cel mai important aspect în proiectarea sistemului. Este mai bine să avem un sistem care omite anumite caracteristici anormale și îmbunătățiri, dar care reflectă un set de idei de design, decât de a avea unul care conține multe idei bune, dar independente și necoordonate. - Fred Brooks, The Mythical Man Month

Software-ul este cunoaștere executabilă. De exemplu, când scrii o aplicație de contabilitate, se codifică tot ce știi despre regulile și procedurile de contabilitate. Cum au ajuns aceste cunoștințe în aplicație? Prin preluarea acestora de la specialiști și trecerea prin creierul dezvoltatorilor pentru a le transforma în cod. O observație aparte este că cele două caracteristici care diferențiază dezvoltatorii de restul lumii este că ei înțeleg calculatoarele și pot gândi cu un nivel foarte ridicat de precizie. De aceea nu cred în programarea vizuală făcută de specialiști. Cum învață și își str ucturează cunoștințele oamenii? Prin atribuirea de nume lucrurilor. Dacă te gândești la anii de școală, îți amintești de învățarea despre numere, operații aritmetice, tabla înmulțirii etc..Acestea sunt doar nume date unor concepte, nume care ne ajută să comunicăm unul cu celălalt despre idei complexe. Vă invit să realizați următorul test. Scrieți unele dintre numele claselor, metodelor și variabilelor din codul pe care lucrați. Apoi notați-vă ceea ce face aplicația. Apoi numărați câte dintre aceste nume corespund domeniului de aplicare. Sau întrebați pe cineva care nu știe la ce lucrați să ghicească ce face aplicația doar pe baza listei de nume. În cazul în care au ghicit, atunci vă rog să mă contactați pentru că vreau să învăț de la voi cum faceți. Acest test arată o deconexiune tipică între ceea ce aplicația face și cum își structurează dezvoltatorii cunoștințele în cod. De ce este acest lucru rău? Deoarece creierul trebuie să-și petreacă timp valoros încercând să traducă ceea ce citește către

4. Integritatea conceptuală este principiul pierdut pentru software design bun

Pagina wiki a lui Ward Cunningham pe această temă oferă următoarele exemple de integritate conceptuală: Putem identifica exemple specifice, binecunoscute de Conceptual Integrity? Vă prezint o listă de asemenea exemple specifice, care nu este definitivă: • Unix (bazat pe noțiunea de „dosar” (de exemplu, directoare, dispozitive, sisteme de fișiere, cu named pipes și sockets sunt tot felul de fișiere); • Smalltalk („totul este un obiect”, și micul set de alte principii care îl însoțesc); • SQL („toate datele se află în tabele”, cu chei și constrângeri • Lisp („totul este o listă”); De ce este utilă integritatea conceptuală? Probabil din cauza modului în care creierul nostru funcționează. Memoria

www.todaysoftmag.ro | nr. 32/februarie, 2015

programare Patru idei pentru îmbunătățirea Software Design-ului omenească de lucru se limitează la păstrarea a patru articole în paralel, dar există o metodă de a o păcăli: fiecare element poate fi de fapt un set de concepte înrudite (un așa numit chunk). Când ai de luat decizii de design dificile, cu siguranță ai nevoie să iei în considerare mai mult de patru lucruri în același timp. Ajută dacă sunt similare, deoarece creierul poate să le prelucreze, permițându-ți să iei decizii mai informate de design. Integritatea conceptuală poate fi aplicată la diferite niveluri, de la variabile, metode la clase. De exemplu, să facem următorul test. Notați numele câtorva clase și numele tuturor metodelor lor publice. Arată interfața clasei cuiva care nu știe la ce lucrați și întrebați ce face clasa respectivă. Întrebați-i dacă e ceva ce pare că nu e la locul ei în acea clasă. Dacă ghicesc și totul se potrivește, felicitări: ați realizat integritate conceptuală la nivel de clasă. Acum faceți același exercițiu la nivel de namespace și modul (arătând doar interfața publică a modulului).

La nivel de sistem, lucrurile devin tot mai complexe. Ports and adapters și microservices sunt unele dintre modelele care ușurează integritatea conceptuală la nivel de sistem. Dar nici o soluție nu este perfectă, fiecare dintre ele are dezavantaje . Un avertisment: integritatea conceptuală este foarte greu de obținut, mai greu decât găsirea de nume potrivite. Cu toate acestea, experiența m-a învățat că atunci când reușești, integritatea conceptuală este nu numai foarte utilă, dar și frumoasă. Într-o lume plină de bug-uri și cod urât, frumusețea poate face minuni pentru moralul tău. Pentru a face software design mai bun, străduiește-te să obții integritate conceptuală la nivel de clasă, namespace, modul și de sistem. Întrebarea de reflecție: Ce părți din aplicație au integritate conceptuală? Alege o clasă la care lucrezi; cum o poți aduce mai aproape de integritate conceptuală? Vrei să înveți mai multe despre software design și arhitectură? Ești interesat de

nr. 32/februarie, 2015 | www.todaysoftmag.ro

ultimele practici în industria de IT software precum: DevOps, Microservices, Technical Leadership, Technical Strategy, etc.? Vino pe 28 - 29 Mai, la I T.A.K.E. Unconference să faci parte din comunitatea europeană de software craftsmen și practicieni experimentați. „The not-to-be-missed event” în Europa Centrală și de Est pentru software craftsmanship - http://itakeunconf.com

testare

Programatorii testează? Testerii scriu cod?

upă o experiență de mai mult de nouă ani în industria software pot să spun că am ajuns să fac câte puțin din tot ce oferă acest domeniu. Am început cu un internship unde am făcut testare înainte de a învăța să scriu cod, am fost programator într-o firmă mică unde am făcut totul de la zero, inclusiv dezvoltare de baze de date. Acum ca tester la Betfair, sunt implicată în testarea funcțională cu accent pe automatizare, livrare continuă și testare de performanță.

Raluca Morariu

raluca.morariu@betfair.com Senior QA Engineer @ Betfair

În momentul în care mă gândeam să studiez programarea nu mi-aș fi imaginat care va fi calea mea în acest domeniu. Dar toate lucrurile pe care le-am făcut de-a lungul anilor m-au ajutat să devin bună în rolul actual. Întrebările din titlul ar putea părea familiare majorității și unii dintre voi s-ar putea să aveți chiar opinii puternice în ceea ce privește răspunsurile la aceste întrebări. În ultimii ani au fost numeroase ocazii în care acest subiect a fost adus în discuție și s-au purtat conversații despre împărțirea responsabilităților în ceea ce privește testarea și programarea. În timp ce făceam cercetare pentru acest articol, m-am confruntat cu o multitudine de opinii despre acest subiect. Deși sunt de acord cu unele dintre ele, acest articol reprezintă viziunea mea asupra relației complexe dintre un programator și un tester, din perspectiva unei persoane care a ocupat ambele roluri de-a lungul carierei.

Programatorii testează?

Au trecut vremurile în care un programator se ocupa doar cu scrisul codului, fără a-i păsa de ceea ce se întâmplă după. Sau cel puțin așa ar trebui. Codul pe care îl scriem trebuie să compileze, să ruleze, să poată fi instalat și să funcționeze cât de cât înainte de a-l testa. Cum poate un programator să

fie sigur că codul pe care l-a scris face toate lucrurile enumerate mai sus fără a-l testa? Un programator ar trebui să depună un anumit efort pe partea de testare, fie că vorbim despre scrierea de unit teste, fie că vorbim despre testarea funcțională a codului pe propriul calculator. A înțelege și a vedea cum se comportă codul după ce a fost scris, cum se integrează cu restul produsului duce la creșterea nivelului unui programator. Oricând aveți dubii dacă trebuie să testați codul pe care îl scrieți întrebați-vă un lucru: „Mă simt confortabil să instalez codul în producție fără a fi testat și să îmi asum întreaga responsabilitate pentru defectele care apar?” Programatorii nu ar trebuie să testeze în același fel în care o fac testerii. Cu toate acestea, acest lucru nu înseamnă că nu sunt în măsură să ajute în testare, iar în unele domenii specifice o vor face chiar mai bine decât testeri. Dacă vă întrebați cât de multă testare ar trebui să facă un programator, răspunsul la această întrebare este în funcție de context. Din experiența mea, lista de mai jos este ceea ce un programator ar trebui să facă în termeni de testare înainte de a preda o bucată de cod testerilor: • Codul compilează. • Codul se instalează. • Unit testele sunt scrise.

www.todaysoftmag.ro | nr. 32/februarie, 2015

testare Programatorii testează? Testerii scriu cod? • Testele de bază trec. • S c e n a r i i l e p o z i t i v e p e n t r u funcționalitatea implementată au fost testate. Totodată, după cum cred că știți majoritatea, cu cât un defect este descoperit mai devreme, cu atât este mai ieftin de reparat și cu atât este produsul final mai de calitate.

Testerii scriu cod?

Cred că toată lumea din domeniul software a auzit despre cuvântul „automation”, cel puțin o dată. Cel puțin o parte dintre oamenii care citesc acest articol au făcut sau fac automatizare. De asemenea, ar putea fi unii dintre voi care nu au încercat niciodată să scrie teste automate sau nu doresc să o facă. Nu este nicio problemă să nu vrei să scrii cod, dar tu ar trebui cel puțin să înveți cum să codezi. Nu suntem așa de diferiți când vine vorba de scris cod. Sau cel puțin nu ar trebui să fim. Îmi place să privesc testarea automată tot ca programare, doar cu un set diferit de cerințe. Dacă ceea ce se cere de la un programator este de a scrie cod pentru a implementa o anumită funcționalitate, cerințele pentru un tester sunt de a scrie cod care să testeze acea funcționalitate. Uneori e mai greu să scrii cod, alteori să testezi. Într-o lume ideală, pentru fiecare programator care lucrează la un proiect există pe partea opusă un tester care încearcă sa strice codul, făcându-l astfel mai bun. Din experiența mea, a știi să scrii cod te face un tester mai bun. În primul rând, adaugă valoarea la produsul final prin abilitatea de a rula aceleași teste în repetate

rânduri după efortul inițial de implementare. În al doilea rând, îți oferă o mai bună înțelegere asupra implementării codului și poți descoperi noi modalități de a-l face să crape. Nu în ultimul rând, îți oferă timp în plus pe care îl poți petrece testând . A fi bun pe partea de testare și a învața să scrii cod nu se exclud reciproc. Învățând să codezi poți câștiga o cunoaștere mai aprofundată a arhitecturii, limitările și punctele forte ale unui limbaj de programare precum și alegerile pe care programatorii le fac în implementare. Toate aceste lucruri pot afecta efortul de testare. Evident, ținând cont de experiența mea, ar părea că lucrurile sunt mai degrabă ușor de zis, dar greu de făcut. Dar eu sunt ferm convinsă că testele automate și testerii care scriu cod sunt viitorul în acest domeniu. Fără a merge prea departe, aici sunt câteva lucruri pe care un tester ar trebui să le automatizeze: • Generarea de date de intrare (dacă este cazul), • Testele smoke, • Testele de regression. La prima vedere lista de mai sus nu pare foarte complicat de implementat însă o dată ce ai început, lucrurile se pot duce si mai departe

Concluzii

Deci, nu pare că rolurile se contopesc? În opinia mea, rolul de programator și cel de tester sunt încă roluri diferite și fiecare are propria zonă de expertiză. Dar, o dată cu extinderea echipelor cu abilități variate și cu nevoia de a livra din ce în ce mai repede noi toți trebuie să învățăm unii de la alții, în scopul de a avea cel mai bun

nr. 32/februarie, 2015 | www.todaysoftmag.ro

produs. Ar trebui să avem întotdeauna imaginea de ansamblu în minte, produsul, clienții și când toate încercările eșuează, nu uitați să vorbiți unul cu celălalt.

programare

Aromă IoT: Sensoriada

Andrei Crăciun contact@andreicraciun.com Mobile Developer @ Intel

umea dezvoltării de software are multe ingrediente, iar dezvoltatorii de software preferă arome diferite. O abordare mai ludică ce menține această analogie cu domeniul culinar oferă ocazia relevării unor aspecte specifice pentru lumea Internetului lucrurilor (IoT). Așadar, unul dintre ingredientele cele mai importante este cel al DETECTĂRII (SENSING). Prin adăugarea unei arome MOBILE oricărui produs IoT, soluţia devine una foarte plăcută. Chiar dacă simţul şi mobilitatea ar fi foarte plăcute pentru utilizatorii generali, este greu să găseşti dezvoltatori cărora să le placă ambele arome. Pe de o parte avem volţi, amperi, senzori, dispozitive de acţionare, iar pe de altă parte avem imagini, icon-uri, cicluri de viaţă, uEx. Dar se poate depăși acest impas prin apelul la Sensoriada.Aceasta defineşte un context care încearcă să surmonteze discrepanţa dintre aceste ingrediente, cu unicul scop de a crea aplicaţii mai bune şi în acelaşi timp de a permite dezvoltatorilor să lucreze cu ingredientul lor preferat. “Internetul lucrurilor” (IoT) nu este ceva nou, ci este mai degrabă un concept nou pentru ceea ce obişnuia să fie, cel puţin în ultimul deceniu, casa inteligentă, automatizarea casei, monitorizare inteligentă şi multe altele. În toţi aceşti ani, o caracteristică importantă a rămas cea care definește toate aplicațiile IoT: acestea sunt foarte prezente în vieţile noastre (noi avem o interacţiune directă foarte puternică cu ele şi ele ne afectează viaţa în mod direct). În această cercetare, am pornit de la o problemă simplă, definită după cum urmează. Afişează pe un dispozitiv mobil temperatura din interiorul şi din afara casei, într-o manieră live. Nu ne era permis să facem găuri şi nu exista un loc anume unde trebuia monitorizată temperatura interioară. Din cauza acestor restricţii, singura soluţie era să găsim o soluţie wireless. După părerea noastră, există cel puţin trei moduri (legate de frecvenţă) de a obţine date de la un senzor: live (în direct), real time (în timp real) și hard real time. Live (în direct) înseamnă că obţinem datele suficient de rapid pentru a ne satisface nevoile (pentru a monitoriza temperatura într-un mod vizual, ar trebui să fie suficient). • Hard real time înseamnă că obținem toate datele posibile şi că nu există modificări pe care să le ratăm; sistemele hard real time sunt folosite în situaţii „pe viaţă şi pe moarte”. De exemplu, când se ajustează suspensiile unei maşini într-un tur; De asemenea, proiectele hard real time au

un ciclu de viaţă foarte scurt. • Real time (în timp real) este o frecvenţă între live şi hard real time; În paragrafele anterioare am folosit câţiva termeni care vor fi detaliaţi în continuare. Dintre aceștia selectăm pentru început, senzori şi dispozitive de acţionare. Senzorii sunt aportul de informaţie al unui proiect IoT; ei furnizează datele care sunt stocate, procesate şi analizate de către sistem. Dispozitivele de acţionare sunt uneltele de reacţie. După ce toate datele sunt analizate şi decizia este luată, se lansează de obicei o acţiune pentru un declanşator . De exemplu, un dispozitiv de acţionare poate fi un întrerupător electric care va aprinde o lumină sau va porni un corp de încălzire. De obicei, şi senzorii şi dispozitivele de acţionare sunt conectate la controler-e (microcontroler-e, cipuri, CPU). Un sfat de bună practică pe care l-am primit şi pe care doresc să vi-l împărtăşesc este următorul: într-un proiect, senzorii şi dispozitivele de acţionare nu ar trebui conectate la acelaşi controler, pentru că este mai sigur să avem un controler pentru input (detectare) şi unul pentru rezultat (acţiune). Apoi, prezentarea s-a concentrat pe ciclul de viaţă al unui produs IoT. Există mai multe abordări, dar articolul de faţă va prezenta numai una dintre ele, pe care noi o considerăm ca fiind cea mai relevantă pentru acest proiect. În imaginea de mai jos sunt prezentate patru etape ale acestui ciclu: 1. Măsurarea pe parcursul căreia datele sunt citite de la senzori;

www.todaysoftmag.ro | nr. 32/februarie, 2015

management Aromă IoT: Sensoriada 2. Stocarea (care s-ar fi putut numi Stocare/Transport) este faza în care datele sunt păstrate pentru a fi analizate fie local în mediul pentru sistemele hard real time, fie într-o soluție cloud ; 3. Analizarea este etapa în care toate datele citite sunt procesate şi pe baza acestora sunt decise acţiuni. Pe parcursul acestei etape, interacţiunea cu alte sisteme precum și analiza pot fi vizibile, după cum vor fi în cazul nostru. 4. Reacţia este faza în care acţiunile decise în etapa de analiză sunt executate de obicei de către un nivel de dispozitive de acţionare. În sistemul nostru vom avea un dispozitiv mobil implicat, deci ar trebui să afirmăm că, în general, rolul unui dispozitiv mobil într-un produs IoT se exercită pe parcursul etapelor de Stocare şi Analizare, deoarece dispozitivul este utilizat în principal pentru a vizualiza datele şi pentru a selecta anumite acţiuni care vor fi transmise dispozitivelor de acţionare spre a fi executate în etapa de Reacţie.

conexiunea cu electric imp cloud, ocupându-se de cazurile speciale cum ar fi pierderea conexiunii sau reconectarea. • cloud cache este o aplicaţie pe partea de server care este inerentă într-un sistem de disponibilitate ridicată şi are drept rol principal păstrarea datelor trimise de la ieșire (gateway); clienții se vor conecta direct la această aplicaţie. Procedând în această manieră, pe de o parte nu va mai trebui să ne străduim să facem ieşirea disponibilă în mod global pentru conexiunile iniţiate de client iar, pe de altă parte, putem implementa o politică de eficientizare a energiei la ieşire, deoarece va trebui să trimitem date numai atunci când există modificări şi nu la fiecare cerere a clientului. Din punctul de vedere al aplicaţiei mobile, avem trei elemente principale de design: • Senzor – responsabil de ce este măsurat (ex: temperatură, umiditate, presiune) şi de modul cum sunt furnizate valorile; de asemenea, din cauză că lucrurile evoluează, Senzorii ar trebui să aibă o versiune. • Nodul Senzor ar trebui să ofere: • o modalitate clară de a identifica (ex.: senzorii din bucătărie, senzorii din exterior); • o modalitate de a determina energia rămasă în sistemul energetic (ex.: voltajul bateriei); • o modalitate de a determina acurateţea datelor (ex.: secunde de la ultima actualizare); • o listă a senzorilor ataşaţi nodului. • Furnizor de date – responsabil pentru conectarea la cloud cache și obținerea tuturor datelor legate de nodurile de senzor. Cloud cache furnizează datele drept un JSON. Există mai multe protocoale şi modalităţi de a obţine date dintr-o reţea de senzori, cea mai populară fiind MQTT; totuşi, noi am ales HTTP având sarcina utilă (payload) JSON în primul rând pentru că este suficient pentru sistemul nostru, iar electric imp cloud oferă o modalitate foarte uşoară de a face un conector server HTTP. Am ales JSON drept format sarcina utilă, în primul rând datorită popularităţii sale, popularitate care face ca procesarea sa să fie facilă şi la îndemână. Structura JSON este bazată pe modelul de aplicaţie descris mai sus. Există o gamă de noduri de senzori care au drept elemente: identificarea (“id” care este în prezent un întreg, dar există o întreagă dezbatere pentru a o face un şir), starea energiei (“voltaj”), acuratețe (“secondsAgo”- acum n secunde de la “dată”) şi lista de senzori. Un senzor va avea drept elemente tipul, versiunea şi valorile; ca valoare, senzorul ar putea avea de asemenea alte elemente şi nu există vreo restricţie pentru o singură valoare. Tipul şi versiunea identifică într-o manieră unică tipul senzorului şi influenţează direct modul în care valorile furnizate sunt procesate. Mai jos este un exemplu de câteva date furnizate de sistemul live/ care rulează:

Noi am structurat soluţia aleasă ca o reţea de senzori. Poate că este timpul să detaliem ce este o reţea de senzori. Componentele sale principale sunt: • senzorul – care poate să fie analogic sau digital în funcţie de cum sunt furnizate datele; noi am ales un senzor de temperatură DS18B20 care utilizează protocolul OneWire pentru a comunica; este rezistent la apă şi are o arie de măsurare destul de bună (http://www.seeedstudio.com/depot/One-WireTemperature-Sensor-p-1235.html) • nodul senzor de obicei este dirijat de un microcontroler, este conectat cu senzorul printr-un fir şi în cazul nostru ar trebui să funcţioneze cu baterie şi să aibă un transmiţător wireless ; datorită acestor două cerinţe, noi putem implementa o tactică energetică care să permită o utilizare mai lungă fără a schimba bateriile; noi am ales un Devduino Sensor Node V2 care se bazează pe Arduino și are un modul nRF24L01+ pentru transmiterea de date. (http://www.seeedstudio.com/depot/ DevDuino-Sensor-Node-V2-ATmega-328-AAA-batteryholder-p-1850.html) • ieşirea (the gateway) este un dispozitiv care este întotdeauna { „sensorNodes”:[ pornit; este conectat cu sau fără fir la nodurile de senzori şi { „id”:0, are rolul de a colecta toate datele de la senzori pentru a le face „voltage”:2848, disponibile pentru procesare; alegerea noastră pentru ieşire a „secondsAgo”:247192, „date”:”2015-01-24 07:10:21”, fost un impuls electric la care am conectat un modul îmbu„sensors”:[ nătăţit nRF24L01+ pentru a putea primi pachetele trimise de { „type”:10, la nodurile de senzori; principalul motiv pentru alegerea unui „version”:1, impuls este faptul că are un adaptor WiFi încorporat și de ase„value”:787 } menea gestionează într-un mod transparent pentru dezvoltator ]

nr. 32/februarie, 2015 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE }, {

}

]

}

„id”:1, „voltage”:2892, „secondsAgo”:32, „date”:”2015-01-24 07:10:21”, „sensors”:[ { „type”:10, „version”:1, „value”:2243 } ]

cu procesarea aportului JSON şi cu returnarea unei liste de SensorNode-s, fiecare dintre ele conţinând implementările adecvate ale Sensor-s în funcție de tip şi versiune. Pentru a reuşi, am implementat un mod de configurare a sistemului. Configurarea va gestiona în principal o hartă/rețea între tipul senzor şi numele clasei care se va ocupa de datele pentru acel tip. Aceasta permite cadrului să fie extins de către oricine şi de asemenea să aibă o configurare default de-a gata.

Concluzii

La începutul acestui articol am afirmat că scopul nostru a Din punctul de vedere al Android, modelul Nodului de fost să favorizăm o conexiune mai puternică între ingineri care Senzori este foarte simplu şi include elementele definite mai sus. lucrează în industria IoT , indiferent de ingredientele pe care le preferă. Dacă am realizat sau nu acest lucru prin prima versiune public class SensorNode { public long id; a cadrului (framework-ului), vom vedea în timp, dar considerăm public int voltage; că am făcut câţiva paşi înainte. Odată cu evoluția comunității IoT, public long secondsAgo; public Date date; sperăm că Sensoriada va ajuta la construirea unei sinergii între public List<Sensor> sensors = new dezvoltatori, care nu va mai lăsa loc pentru conflict, ci numai LinkedList<Sensor>(); } pentru armonie şi discuţii constructive. Modelul Senzor este o interfaţă deoarece avem o mare diver- MobOS (Mobile Operating Systems) sitate în funcţie de tipul şi versiunea senzorului. Pentru că această versiune este un sistem read-only, noi doar oferim metode pentru a obţine date într-un mod view şi acesta este motivul principal pentru care avem numai metoda getHumanReadableValue() pentru a obține date. În ceea ce priveşte varianta senzorului, există mai multe valori fixe pentru tip (definit în Sensor.Type enum); Referitor la versiune, clasele implementate ar trebui să aleagă versiunea maximă şi să susţină toate versiunile mai jos de cea aleasă: public interface Sensor { public enum Type { TEMPERATURE(10), HUMIDITY(11), PRESSURE(12); … } }

String getHumanReadableValue(); Type[] getSupportedTypes(); boolean isTypeSupported(Type type); int getMaximumSupportedVersion();

Lumea automotive ne-a învățat că în această industrie lucrurile ar trebui să fie foarte simple. Altfel, testarea este foarte dificilă, iar dacă sistemele IoT nu sunt testate corespunzător, erorile pot avea consecinţe regretabile deoarece, după cum am arătat la începutul acestui articol, sistemele IoT sunt foarte prezente în vieţile noastre şi interacţionează direct. Acestea fiind precizate, noi am dorit ca utilizatorii acestui cadru (framework) să îl poată utiliza într-un mod foarte facil. Mai jos vă oferim un exemplu de cod de utilizare într-o aplicaţie Android clasică : String nodesJson = getSomeHowTheJson(); // DataProvider in the next version List<SensorNode> sensorNodes = SensorNodeUtil. parseSensorNodes(nodesJson); int mySensorNodeIndex = someValue; // String identification in the next version int mySensorIndex = someValue; // byType identification in the next version

Este prima comunitate mobile din Cluj. Ne-am început activitatea în 2012 şi deoarece dorim să creştem şi să devenim mai relevanţi şi mai atrăgători pentru a deservi mai bine comunitatea mobile din Transilvania, a doua ediție a MobOS va fi o versiune îmbunătăţită! A doua ediţie va consta într-o conferinţă de două zile; prima zi dedicată prezentărilor cu tema tehnologiei mobile şi discuţiilor deschise, în timp ce a doua zi va găzdui 4 workshop-uri legate de Android și iOS, atât pentru dezvoltatorii începători cât şi pentru cei avansaţi. Elementele cheie ale conferinţei: • 12 prezentări • 4 workshop-uri • 10+ vorbitori naţionali şi internaţionali • 2 zile întregi în Cluj Napoca– pentru a vă implica în lumea dezvoltării tehnologiei Mobile În 15 Ianuarie 2015, am avut un pre-eveniment de lansare a conferinței, găzduit de Fortech. Pe parcursul acestui eveniment, 2 dintre vorbitorii noştri locali au susţinut o prezentare despre IoT (Internetul lucrurilor) și datorită interesului crescut de care s-a bucurat acest subiect, Andrei Crăciun, inginer software senior la Intel Corporation, a avut iniţiativa de a scrie un articol pentru TSM.

someView.setText(sensorNodes.get(mySensorNodeIndex). sensors.get(mySensorIndex).getHumanReadableValue());

Magia are loc în clasa SensorNodeUtil care este responsabilă www.todaysoftmag.ro | nr. 32/februarie, 2015

programare

Analiza sentimentelor şi complexitatea opiniilor online

acă ai trăi într-o lume unde opinia ta contează, ai încerca să schimbi ceva? Fără îndoială că opiniile sunt o prezență constantă în viața fiecăruia: recomandările, recenziile, sunt doar câteva din mijloacele folosite pentru a influența viitoarele decizii. În era vitezei, când multitudinea opțiunilor te inhibă, opiniile sunt cele ce te pot determina în a lua o decizie rapidă când ești sub lumina reflectorului. Dar să presupunem că am putea evalua totul în termeni de pro sau contra, ar fi deciziile noastre mai corecte? Sau nu e chiar atât de simplu? corectat Cosmin Gabriel Popa cosmin-gabriel.popa@hp.com SA R&D Osprov Team @ HP

Sentiment Analysis sau Opinion Mining este o ramură a domeniului de Natural Language Processing (NLP) ce se ocupă cu studiul opiniilor, sentimentelor, evaluărilor, atitudinilor, emoțiilor și caracteristicele acestora, direcționate spre anumite entități precum produse, organizații, indivizi, evenimente, etc. . Nu a existat un interes deosebit pentru această disciplină înainte de anul 2000, dar odată cu răspândirea aplicațiilor comerciale (online sau offline), perspectiva asupra analizei opiniilor s-a schimbat în mod radical. E și pentru prima dată în istorie când există o bază de date dogmatică consistentă, alcătuită cu ajutorul rețelelor de socializare. Nu e atât de surprinzătoare schimbarea de perspectivă ținând cont de aplicațiile sale în domenii politice, sociologice, economice ș.a. și de popularitatea de care se bucură socializarea online în zilele noastre.

Enunțarea problemei

Să ne întoarcem totuși la întrebarea inițială. Vom lua drept exemplu filmele și o serie de recenzii asupra acestora. Vom împărți astfel opiniile în două categorii, după cum am stabilit inițial: pozitiv (pro) și negativ (contra). Astfel putem enunța întrebarea: dacă ar exista o recenzie negativă despre actorul principal și una

nr. 32/2015 | www.todaysoftmag.ro

pozitivă despre regizor, ai mai viziona filmul? Ai mai avea nevoie de încă o părere despre film? Cum poți determina dacă următoarea opinie va fi una pozitivă sau una negativă? Și cum te-ar putea influența aceasta? Există diferite metode de analiză depinzând de granularitatea cu care se abordează problema: analiza per document (Document Analysis) care determină dacă un întreg document exprimă o opinie pozitivă sau negativă; analiza per propoziție (Sentence Analysis) care stabilește dacă o propoziție este pozitivă, negativă sau neutră; analiza per entitate sau aspect (Entity and Aspect or Feature Analysis) care precizează asupra cărei entități se adresează opinia și polaritatea opiniei.

Soluția

Există două metode de clasificare a opiniilor: aceea prin antrenarea unei rețele neuronale (Supervised Learning) și aceea ce nu implică o astfel de antrenare (Unsupervised Learning). Simplificând analiza la nivelul propoziției presupunând că avem la dispoziție doar documente cu tentă pozitivă sau negativă, vom aborda o soluție prin Supervised Learning cu ajutorul platformei NLTK (Natural Language Toolkit).

programare {python code} from nltk.corpus import movie_reviews positive_ids = movie_reviews.fileids(‚pos’) negative_ids = movie_reviews.fileids(‚neg’) {/python code}

TODAY SOFTWARE MAGAZINE return dict([(word, True) for word in words if word in best_words]) def findBestWords(scores, number): best_vals = sorted(scores.items(), key=lambda w_s: w_s[1], reverse=True)[:number] best_words = set([w for w, s in best_vals])

return best_words După cum se poate observa corpusul de „movie_reviews” {/python code} conține recenzii de filme deja segregate în cele două categorii stabilite inițial. Din acestea vom extrage cuvinte drept informațiile de care vom depinde pe viitor. Tot ce mai rămâne este să le punem cap la cap. Cu informațiile extrase până acum vom antrena rețeaua neuronală reprezentată {python code} positive_data = [movie_reviews.words(fileids=[f]) for de NaiveBayesClassifier. Pentru simplitate vom reveni la platf in positive_ids] forma NTLK utilizând algoritmul său standard. negative_data = [movie_reviews.words(fileids=[f]) for f in negative_ids] {/python code}

{python code} (word_fd, cond_word_fd) = buildFreqDistribution(positive_data, negative_data)

Suntem în punctul unde trebuie să decidem cu ce vor fi reprezentate instanțele în momentul în care vom antrena rețeaua neuronală. Pentru simplitate vom alege drept caracteristică cuvintele cele mai frecvente din corpusul specific. Se implementează astfel o funcție care determină frecvența fiecărui cuvânt pentru cele două categorii, împreună și diferențial.

total_word_count = cond_word_fd[‚positive’].N() + cond_word_fd[‚negative’].N()

{python code} import itertools from nltk import FreqDist, ConditionalFreqDist def buildFreqDistribution(positiveWords, negativeWords): word_fd = FreqDist() cond_word_fd = ConditionalFreqDist() for word in list(itertools.chain(*positiveWords)): word_fd[word.lower()] += 1 cond_word_fd[‚positive’][word.lower()] += 1 for word in list(itertools.chain(*negativeWords)): word_fd[word.lower()] += 1 cond_word_fd[‚negative’][word.lower()] += 1 return (word_fd, cond_word_fd) {/python code}

negative_features = getFeatures(‚negative’, negative_data, best_words)

word_scores = buildWordsScores(word_fd, cond_word_fd, total_word_count) best_words = findBestWords(word_scores, 1000) positive_features = getFeatures(‚positive’, positive_data, best_words)

classifier = NaiveBayesClassifier.train( positive_features + negative_features) classifier.show_most_informative_features(10) {/python code}

Se pare că dispunem acum de un mecanism ce poate determina cu o oarecare precizie dacă o recenzie este pozitivă sau negativă. Să luam spre exemplu următoarea recenzie la un film cu Kevin Costner : „Once again Mr. Costner has dragged out a movie for far longer than necessary. Aside from the terrific sea rescue sequences, of which there are very few I just did not care about any of the characters [...]” O recenzie ce, la prima vedere, pare a fi una negativă.

Bazându-ne pe frecvențele calculate anterior, vom construi un dicționar care va conține scorul fiecărui cuvânt. Funcția „BigramAssocMeasures” calculează relevanța cuvântului respectiv în contextul în care se află acesta, returnând o valoare reprezentativă. {python code} {python code} from nltk import BigramAssocMeasures def buildWordsScores(word_fd, cond_word_fd, total_word_count): word_scores = {} for word, freq in word_fd.items(): positive_score = BigramAssocMeasures. chi_sq(cond_word_fd[‚positive’][word], (freq, cond_word_fd[‚positive’].N()), total_word_count) negative_score = BigramAssocMeasures. chi_sq(cond_word_fd[‚negative’][word], (freq, cond_word_fd[‚negative’].N()), total_word_count) word_scores[word] = positive_score + negative_score return word_scores {/python code}

features = selectBestWords(words_in_review, best_words) print(classifier.classify(features)) {/python code}

Se dovedește a fi pozitivă cu o diferență de scor de 1.4. Dacă adaugăm și restul recenziei : „[...] Most of us have ghosts in the closet, and Costner’s character are realized early on, and then forgotten until much later, by which time I did not care. The character we should really care about is a very cocky, overconfident Ashton Kutcher. The problem is he comes off as a kid who thinks he’s better than anyone else around him and shows no signs of a cluttered closet.”, aceasta reiese a fi negativă cu o diferență de scor de 0.9.

Studiu de caz

Se implementează și funcțiile care vor filtra informațiile releUtilizând algoritmul SVM (Support Vector Machines) în vante pentru antrenarea rețelei neuronale. paralel cu algoritmul NaiveBayesClassifier și testând cei doi algoritmi pe o baza de date ajungând la peste 6 milioane de cuvinte, {python code} def getFeatures(label, data, best_words): am obținut următoarele grafice. Odată cu creșterea numărului de features = [] entități extrase din text și folosit în antrenarea rețelelor neuronale, for feat in data: words = [selectBestWords(feat, best_words), label] se pot observa diferențe de acuratețe generală și de clasificare. features.append(words) return features

def selectBestWords(words, best_words): www.todaysoftmag.ro | nr. 32/februarie, 2015

programare

testare Analiza sentimentelor şi complexitatea opiniilor online diferite metode și diferiți algoritmi ce se pot folosi în Supervised sau Unsupervised Learning, dar soluția cea mai bună este combinarea acestor două mari metode. Desigur o importanță deosebită o poartă bazele de date folosite, metodele implementate, corpusul de test, toate acestea având necesitatea de a corespunde intenției dezvoltatorului. Opiniile cumulate pot determina valoarea unui produs, a unui individ, a unei idei sau a unui eveniment. Cu opinii ești bombardat în fiecare zi pe orice device, pe orice aplicație, pe orice pagină Web, pe orice stradă. În final, contează sau nu părerea ta? Eu zic: Da!

Se poate observa cum precizia algoritmului rămâne constantă și în creștere până la un punct de plafonare în jurul valorii aproximative de : 0.81%. Chiar dacă numărul de features (entități) crește, acuratețea va oscila în jurul valorii de plafonare. Totuși, instabilitatea în cazul algoritmului NaiveBayesClassifier se poate observa mai bine în ultimul grafic. Algoritmul SVM se dovedește a fi mai fiabil în acest caz.

Concluzii

Se pare ca nu e atât de simplu. Am fost păcăliți chiar de propriul nostru algoritm. Totuși, nu există o metodă standardizată de determinare a „sentimentului” degajat de o opinie. Până și prin simplificarea radicală a problemei nu s-a putut ajunge la o acuratețe impresionantă, nici măcar apropiată de 95%. Există

nr. 32/februarie, 2015 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

diverse

Gândirea critică în analiza de business

inci procente dintre oameni gândesc; Zece procente dintre oameni cred că gândesc; restul oamenilor ar prefera să moară decât să gândească. – Thomas A. Edison

În luna noiembrie, 2014, o companie locală din Cluj – Napoca a fost gazda unui eveniment dedicat tester-ilor: Rapid Software Testing. La finalul celor trei zile, timp de o zi, speaker-ul a abordat o temă delicată pentru industria IT, dar importantă pentru analiști și pentru testeri: Gândirea critică. Trainer-ul invitat a fost Michael Bolton (des confundat cu artistul cu același nume), un nume important în disciplina de testare IT. Deși evenimentul a fost organizat pentru tester-i, o bună parte din principii se aplică și pentru analiștii de business. Cea mai mare parte din munca unui analist de business implică gândirea. Gândirea este un reflex natural care definește calitatea muncii noastre și influențează deciziile pe care le luăm. Cu toate acestea, ne confruntăm cu multe situații în care conștientizăm că rezultatul gândirii noastre nu a produs rezultatul așteptat. Motivele pentru care se întâmpla acest lucru sunt strâns legate de faptul că de

cele mai multe ori nu alegem conștient modul de gândire potrivit situației cu care ne confruntăm. Daniel Kahneman a scris în cartea sa (Gândire rapidă, Gândire lentă – original: Thinking, Fast and Slow, Traducător: Dan Crăciun, Editura Publica, 2012) că oamenii au în creierul lor două sisteme de gândire, pe care le-a numit Sistemul 1 și Sistemul 2: • Sistemul 1 (sau sistemul de gândire automată) procesează informații automat și rapid, cu efort scăzut și fără control. • Sistemul 2 (sistemul de gândire controlată) alocă atenție și efort pentru activitățile de gândire complexă. Dacă această scurtă descriere nu a fost suficientă sau convingătoare, imaginați-vă următoarele: Sistemul 1 este cel care ne ajută să reacționăm într-un timp scurt la stimuli exteriori, ne ajută să recunoaștem obiecte sau fețe cunoscute, ne ajută să ne orientăm în spațiu, asociază idei simple care nu au nevoie de procesare complexă.

Reprezentare simplistă a celor două sisteme de gândire descrise de Daniel Kahneman

(De exemplu, pentru întrebarea: “Care este capitala Franței?,” nu trebuie să depunem efort suplimentar, deoarece facem asocierea cu ceea ce am auzit de multe ori). Sistemul 2 este cel care preia controlul asupra gândirii când suntem în situații dificile care cer soluții complexe: calcule complexe, atenție concentrată asupra unei activități pentru o perioadă de timp îndelungată, validarea unui argument logic și multe alte situații asemănătoare.

Ce legătură au cele descrise anterior cu gândirea critică?

În termeni simpli, gândirea critică poate fi definită ca “procesul disciplinat al intelectului de a conceptualiza, aplica, analiza, sintetiza și evalua, într-un mod activ și conștient, informațiile obținute sau generate din observație, experiență, meditație, comunicare ”1 - definiție stabilită de Consiliul Național pentru Excelență în Gândire Critică, 1987. Luând în considerare abilitățile esențiale ale unui analist de business, care au fost abordate extensiv de către numeroși trainer-i și bloguri de profil, gândirea analitică nu oferă suficient suport pentru o gândire calitativă. Gândirea analitică face referire la separarea abstractă a unui întreg în părțile sale componente și pentru a le analiza ulterior individual și in relație unele cu celelalte. În comparație, gândirea critică este gândirea disciplinată, clară, rațională, deschisă la argumente și completată de dovezi clare. Cu alte cuvinte, gândirea critică este specifică Sistemului 2 de gândire așa cum 1 h t t p : / / w w w. c r i t i c a l t h i n k i n g . o r g / p a g e s / defining-critical-thinking/766

www.todaysoftmag.ro | nr. 32/februarie, 2015

diverse Gândirea critică în analiza de business este descris de Daniel Kahneman în cartea sa. Pentru ca un analist de business (în cazul nostru) să fie sigur că ia o decizie care răspunde cel mai bine nevoilor clientului și în același timp păstrează raportul cost/ efort într-un interval optim acesta trebuie să își activeze Sistemul 2 de gândire.

Cum și de ce să activăm „Sistemul 2”?

Conform lui Daniel Kahneman, atunci când un individ trebuie să ofere un răspuns sau o soluție, Sistemul 1 de gândire va produce un răspuns bazat pe experiența anterioară. În unele cazuri, conexiunile create se potrivesc cu situația curentă, dar de cele mai multe ori situațiile noi necesită o analiză amplă. Un analist de business trebuie să își folosească gândirea critică în orice împrejurare. Aceasta abilitate este testată încă de la interviul pentru angajare. În cele mai multe cazuri, interviul presupune multe întrebări prin care reprezentantul angajatorului încearcă să determine o serie de calități necesare poziției de analist. Una din întrebările relevante pentru testarea abilităților de gândire critică poate fi: “Câte mașini trec zilnic printr-o anumită intersecție?” Probabil că prima reacție ar fi să te întrebi dacă ești la interviul potrivit sau eventual chiar să te ridici și să pleci de la interviu. Însă întrebarea este la fel de pertinentă ca oricare alta. Această întrebare scoate în evidență mai multe calități. La o astfel de întrebare, tentația ar fi să faci o căutare pe site-ul Google. Care ar fi însă răspunsul dacă nu poți accesa internetul? Răspunsul nu presupune o formulă matematică elaborată, însă necesită o analiză detaliată și formularea unui algoritm de determinare a numărului. În final, nu contează numărul exact ci modalitatea prin care cel intervievat a ajuns la răspuns. O variantă poate fi: Identificarea intersecției și a zonei din oraș în care se încadrează. Apoi, aproximarea numărului de oameni care locuiesc în zona respectivă. Din numărul estimat, trebuie aproximat numărul de oameni care dețin mașini și care le folosesc zilnic. Din numărul estimat de persoane care dețin mașini numai o parte folosesc intersecția respectivă pentru a ajunge la serviciu sau în alte zone de interes. Numărul rezultat nu va fi numărul real, dar acest detaliu nu este important pentru cel care a adresat întrebarea. Algoritmul poate fi detaliat sau ajustat, dar până la urma va dovedi că acel candidat are capacitatea de a formula un algoritm logic, o gândire statistică și capacitatea de a analiza o situație pe mai multe dimensiuni.

Mai mult, sarcinile unui analist de ce?” „Cum?” Sunt întrebări de bază care business gravitează în jurul procesului de oferă de obicei o imagine mai clară asucolectare a cerințelor din partea clientului. pra unei cerințe. Colectarea cerințelor solicită analistului • Gândește logic concentrarea atenției pentru o perioada • A r g u m e n t e a z ă u n p u n c t îndelungată pentru a înțelege nevoile reale de vedere prin dezvoltarea unui ale clientului. Gândirea critică ajută analisraționament logic. tul în a identifica dacă cerințele exprimate • Folosește argumente valide și de răspund nevoii reale ale clientului. În încredere. același timp, gândirea critică ajută analis• Evită folosirea emoțiilor în tul în identificarea posibilelor provocări gândire. de business care presupun o clarificare din • Fii obiectiv. partea clientului și nu pot fi soluționate • Fii deschis printr-o aplicație. De exemplu, pentru o • Elimină prejudecățile. cerință care este formulată în felul urmă• Fii deschis la idei noi. tor: “Am nevoie de un raport care să îmi • Consideră toate perspectivele afișeze situația produselor vândute în fieînainte de a ajunge la o decizie finală. care lună”, un analist ar trebui să adreseze • Fii dispus să îți reanalizezi punco serie de întrebări, cum ar fi: tele de vedere. • De ce ai nevoie de acest raport? • Fii echilibrat. • Pentru cine este folositor acest • Evaluează raport? • Scop și motivație, • Ce fel de informații trebuie să • Interesul, interogăm? • Faptele, • Ce alte rapoarte avem deja imple• Opiniile celor implicați în mentate? Exista un raport care să afișeze discuție, deja această informație? • Presupunerile, • Care va fi frecvența de utilizare a • Informațiile incorecte sau raportului? incoerente, Întrebările nu se rezumă doar la cele • Informațiile care lipsesc, menționate mai sus. În scurt timp de la • Inconsistența, enunțarea cerinței este posibil să se ajungă • Argumentele, la concluzia că raportul există deja ca parte • Argumentele prezentate, din alt raport sau că frecvența de utilizare • Contraargumentele. nu este mare astfel că prioritatea de implementare nu este critică. Concluzie De ce este importantă gândirea critică Cum putem să ne antrenăm gândirea pentru un analist de business? Este o apticritică? tudine care asigură calitatea. Deși gândirea Ca orice calitate, gândirea critică critică nu garantează cerințe precise și elinu este ceva cu care ne naștem și din minarea subiectivității se apropie foarte acest punct de vedere poate fi antrenată. mult de acest lucru. În măsura în care Gândirea critică nu se dobândește printr- cerințele sunt reale și precise șansele ca un efort de o zi sau o lună ci presupune o rezultatul proiectului să răspundă nevoilor atenție sporită asupra modalității de gân- reale ale clientului sunt foarte mari. Ideea dire. Multe universități din lume pun mare esențială este de a investiga toate variantele accent pe gândirea critică și au incluse în pentru că rezultatul poate fi surprinzător. programele școlare o serie de cursuri prin care ajută studenții să-și formeze această abilitate. Universitatea Anglia Ruskin, una din universitățile de top din Anglia, are inclus în materialul de prezentare al facultății, un ghid pentru dezvoltarea gândirii critice. Acest ghid poate fi folosit cu succes de către oricine. • Adresează multe întrebări: este Răzvan Costa cunoscut faptul ca un analist de business, Razvan.Costa@endava.com trebuie să adreseze multe întrebări, dar aceasta nu înseamnă neapărat că orice Business Analyst @ Endava întrebare este pertinentă. Întrebările „Cine?” „Ce?” “Unde?” „Când?” „De

nr. 32/februarie, 2015 | www.todaysoftmag.ro

programare

TODAY SOFTWARE MAGAZINE

Java 8 Optional nu este doar pentru înlocuirea unei valori null

n Java 8 poți returna un Optional în loc de return null așa cum ai putea să faci în Java 7. Aceasta ar putea sau nu să fie o mare diferenţă în funcţie de frecvenţa cu care tinzi să uiţi să verifici null sau să foloseşti analiza de cod static pentru a verifica referinţele de null. Există totuși un caz care te constrânge mai mult. Acesta constă în a trata Optional ca pe un Stream cu valori 0 sau 1.

Caz simplu de utilizare Optional

Pe vremea lui Java 7, am fi scris ceva de genul:

String text = something(); if (text != null) {

}

(Contained2) x : null) .map(x -> x.list) // could be null .filter(x -> !x.isEmpty()) // could be empty .map(x -> x.get(0)) // could be null .map(x -> x.third); // could be null.

Observaţie: Oracle Java 7 va avea sfârșitul actualizărilor publice Ceea ce obţinem este o serie de reprezentări şi filtre care progreîn aprilie 20151. sează doar dacă valoarea nu este null şi prezentă. Dacă vreo valoare Cu Optional, vei putea scrie în schimb: este nul sau un filtru nu este adevărat, întregul rezultat nu va fi disponibil. Optional text = something(); if (text.isPresent()) {

String text2 = text.get();

Totuşi, dacă eşti paranoic, ai putea scrie: Optional text = something(); if (text != null && text.isPresent()) { String text2 = text.get();

Concluzie

Folosirea lui Optional poate fi o modalitate puternică de a dirija o structură complexă de date într-un mod sigur. Scopul lambda este de a reduce codul boilerplate (care nu necesită multă modificare), Dacă ai multe erori NullPointerException în proiectul tău, iar în acest caz, evită toate verificările sau erorile ce pot apărea. Optional s-ar putea să te ajute, dar altfel nu va fi de prea mult ajutor.

Un exemplu mai complex

Haideţi să luăm în considerare acest exemplu:

Adiţional

Pentru interesul vostru, iată clasele pe care le-am utilizat în exemplul anterior:

static String getFirstSecondThird(Nested nested) { try { return ((Contained2) nested.first.second).get(0).third; } catch (NullPointerException | ClassCastException | IndexOutOfBoundsException ignored) { return null; } }

static class Nested { Contained first; }

Este destul de complicat. În loc să vânezi excepţii, poţi concepe o listă lungă de verificare a condiţiilor, dar este dificil să vezi ceea ce încerci să faci. Optional îți permite să gestionezi toate condiţiile de eroare posibile, fără a prinde excepţii sau a avea if/else imbricate.

static class Contained2 implements IContained2 { List list; }

static Optional getFirstSecondThird(Optional nested) { return nested // could be non-present .map(x -> x.first) // could be null .map(x -> x.second) // could be null // could be another type .map(x -> x instanceof Contained2 ?

static class Contained { IContained2 second; } interface IContained2 { }

static class Data { String third; } Peter Lawrey

peter.lawrey@higherfrequencytrading.com CEO @ Higher Frequency Trading Ltd

1 http://www.oracle.com/technetwork/java/eol-135779.html#Java6-end-public-updates

www.todaysoftmag.ro | nr. 32/februarie, 2015

marketing

Aprofundare a SLA-urilor furnizorilor de servicii cloud

impurile recente stau sub semnul serviciilor cloud. Funcționalități noi ale furnizorilor de cloud se lansează în fiecare zi, aducând cu ele prețuri din ce în ce mai mici. În acest moment, cei mai cunoscuți furnizori de servicii cloud sunt Amazon, Google și Microsoft.

Uitându-ne peste serviciile lor, vom vedea SLA-uri (Acorduri de nivel al serviciilor - Service Level Agreements) care ajung la o disponibilitate de 99,9%, 99,95% sau chiar 99,99%. Acest articol va aborda acordurile SLA ale furnizorilor de servicii cloud, încercând să explice de ce SLA-urile sunt atât de importante, care sunt beneficiile lor și nu în ultimul rând, cât de mulți bani am putea obține înapoi dacă un serviciu cade.

Ce înseamnă un SLA?

”Un acord pentru calitatea serviciilor (SLA) este un contract între un furnizor de servicii (fie intern sau extern) și utilizatorul final care definește nivelul serviciului așteptat de la furnizorul de servicii. SLAurile sunt bazate pe rezultat (output) deoarece scopul lor este să definească anume ceea ce clientul va primi. SLA-urile nu definesc cum este oferit sau furnizat serviciul în sine.” 1 Un SLA este un contract între un furnizor de servicii și client, care specifică ”calitatea” serviciului care va fi furnizat clientului. De exemplu, dacă ne gândim la un serviciu care îți precizează ora exactă, SLA-ul va defini cât timp va fi serviciul în stare de funcționare pe parcursul unui an (99,99%). În plus, SLA-ul definește garanțiile care sunt oferite dacă SLA-ul nu este onorat. De exemplu, dacă serviciul de oră exactă este nefuncțional pentru mai mult de 0,01% pe lună, furnizorul de servicii va reduce 1 https://www.paloaltonetworks.com

costul total de pe factură cu 50%.

Ce zone sunt acoperite?

diferite, vom descoperi că Google oferă o durată de funcționare conform SLA de 99,9 %, Microsoft oferă un SLA cu durata de funcționare de 99,9%, iar Amazon oferă o funcționare de 99,95% prin SLA , cu precizarea că, dacă avem spre utilizare Read Access-Geo Redundant Storage de la Microsoft, putem ajunge chiar și la 99,99%. După cum am putut remarca în exemplul de mai sus, SLA-urile sunt aproape identice, cu diferențe de doar 0.05%.

În funcție de tipul de servicii sau de afacere despre care discutăm, aspectele care pot fi atinse sunt diferite. Este foarte comun pentru un SLA să cuprindă următoarele atribute ale unui serviciu: • Volum, • Viteză, • Capacitate de reacție, • Eficiență, • Calitate. Cum este măsurat serviciul? Această întrebare este foarte imporPrivind din nou la exemplul nostru cu tantă, deoarece fiecare furnizor de servicii serviciul de oră exactă, am putea avea un cloud specifică foarte clar în SLA cum, SLA care spune: ”Serviciul de oră exactă cine și când, în funcție de ce serviciu este funcționează 99,99% din an, timpul de răs- măsurat. puns din momentul în care o cerere ajunge În toate cazurile, durata de funcționare la acest serviciu este de 0.0001 secunde și a serviciului este măsurată intern, de precizia este de 0.00000001 secunde.” către sistemul lor propriu. Acest lucru nu înseamnă că măsurarea nu este reală. SLA-urile pentru Cloud Ea este foarte reală, dar dacă motivul În general, dacă vorbim de furnizorii nefuncționării este un factor extern, cum de servicii cloud și serviciile oferite de ei, ar fi probleme la rețea pe partea clientului, aspectul acoperit de toți este durata de atunci nu mai este problema lor. funcționare. Pe lângă durata de funcționare SLA-ul nu este aplicabil în cazurile în mai sunt și alte aspecte, dar acestea variază care serviciul este utilizat în afara anumiîn funcție de tipul de serviciu. tor limite specifice. De exemplu, SLA-ul Microsoft, Google și Amazon au se aplică numai când numărul de cereri un SLA clar care specifică durata de pe secundă este sub 10 milioane, sau când funcționare pentru fiecare serviciu care există cel puțin două exemple de cerere este furnizat de către ei. Chiar dacă sunt pentru acea folosință. companii diferite, SLA-urile sunt foarte asemănătoare între ele. Garanție De exemplu, dacă ne uităm la serviciAdesea, oamenii presupun în mod eroile de depozitare din cloud, care nu sunt nat că, dacă au un serviciu în cloud care replicate în centre de date sau noduri generează 1000$ per oră, furnizorul le va

nr. 32/februarie, 2015 | www.todaysoftmag.ro

legal asigura acea sumă de bani pe care serviciul ar fi generat-o, chiar și în condițiile unei perioade de nefuncționare. O altă presupunere greșită este că furnizorul de cloud va acoperi toate pierderile generate de o perioadă de nefuncționare. În acest moment, nu cunosc nici un furnizor de cloud sau de servicii care ar acoperi pierderile rezultate în urma unei nefuncționări. Ambele presupuneri sunt nejustificate. Ar putea suna ciudat, dar este normal. În primul rând, este greu să măsori și să calculezi pierderea, iar în al doilea rând, SLA-ul se referă la serviciul pe care îl utilizați și nu la sistemul sau serviciile pe care voi le oferiți pe baza acestuia. Google, Microsoft și Amazon oferă garanții foarte asemănătoare. În funcție de perioada de nefuncționare la sfârșitul lunii, o cantitate specifică de credit servicii este oferită clientului. De exemplu, dacă perioada de funcționare a serviciului a fost sub 99,9%, clientul va primi 25% din costul acelui serviciu pentru acea lună drept credit. Acest credit va fi utilizat pentru a reduce costul facturii din luna următoare. De asemenea, SLA-urile menționează că, dacă un anumit incident sau eveniment provoacă o defecțiune la mai mult decât un singur serviciu cloud, atunci clientul poate trimite o reclamație numai pentru un serviciu care a fost afectat de acest eveniment. De exemplu, dacă un centru de date cade din cauza unei actualizări software și sunt afectate sistemele de stocare, calcul și mesagerie, atunci clientul poate pretinde credit numai pentru un singur serviciu.

Garanțiile Amazon, Google și Microsoft

Haideți să aruncăm o privire asupra garanțiilor care sunt oferite de către acești furnizori de cloud în cazul unei nefuncționări a sistemului lor de depozitare.

Amazon

TODAY SOFTWARE MAGAZINE Google

în furnizorii noștri de cloud care își respectă SLA-urile. Același lucru se întâmplă cu orice furnizor extern. În general, toate SLA-urile oferite de furnizorii de cloud sunt respectate. Cazurile în care există incidente sunt foarte rare și izolate.

Microsoft

Durata de funcționare a serviciului cloud nu coincide cu durata de funcționare a produsului nostru

Un lucru important pe care trebuie să îl luăm în considerare este că atunci când construim un produs pe cloud, timpul de funcționare al sistemului nostru nu este același cu timpul de funcționare al serviciilor cloud. De exemplu, dacă avem un produs care este construit utilizând 20 de servicii din cloud, atunci timpul de funcționare al sistemului nostru va trebui să fie calculat ținând cont de perioada de funcționare a tuturor serviciilor cloud. Dacă fiecare dintre serviciile cloud are o durată de funcționare de 99,9%, atunci perioada de Când și cum primesc creditul? funcționare a sistemului nostru ar putea Toți furnizorii de cloud au mecanisme ajunge la aproximativ 98%. diferite pentru a-și notifica clienții atunci când un serviciu nu funcționează conform Concluzie așteptărilor (pe un web site, folosind un După cum am menționat mai sus, API sau prin email). În toate aceste cazuri, SLA-urile oferite de diferiți furnizori chiar dacă un serviciu este nefuncțional de cloud sunt relativ asemănătoare. Cel mai mult decât se specifică în SLA, clientul mai important lucru este să știm exact ce nu va primi din oficiu (by default) creditul anume acoperă SLA-ul și cum să gestiodespre care am discutat mai sus. năm perioadele de nefuncționare. În momentul în care clienții sunt afectați de un incident, ei trebuie să Referințe înștiințeze furnizorul de cloud și să întoc- Amazon EC2 SLA - aws.amazon.com/ec2/sla/ mească un aviz la nivelul de suport pentru Google SLA - cloud.google.com/storage/sla clienți. Ei trebuie să specifice care anume Microsoft SLA - azure.microsoft.com/en-us/ serviciu a fost afectat și când. Pe baza support/legal/sla/ acestor informații, furnizorul de cloud va verifica sistemul de audit intern și nivelul ratei de eroare în acel interval anumit de timp. Oferta nu este identică 100%, dar este destul de similară. Chiar dacă Google oferă 50% credit de depozitare în cazul unei nefuncționări, nu mi-aș dori să fiu în situația în care durata de funcționare este de numai 90% de exemplu. Creditul oferit pentru o funcționare între 99,xx% și 99% este același. Fiecare ’9’ care este oferit peste 99% este foarte scump și greu de obținut. Acei 9 reprezintă adevărata bătălie și pot face deosebirea dintre un simplu serviciu și un serviciu grozav.

Încredere

Radu Vunvulea

Acesta este cuvântul cheie în lumea furnizorilor de cloud și a clienților lor. Cel mai important lucru este încrederea care există între ei. Noi, clienții, avem încredere

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

www.todaysoftmag.ro | nr. 32/februarie, 2015

marketing

Dezvoltarea Marketingului Intern (MI) în România!

n timp ce unii dintre noi suntem familiarizați cu conceptul de Marketing Intern (MI), rolul acestei secțiuni din strategia de marketing este puternic subestimat în zilele noastre. Vă propunem o vizualizare în patru faze de dezvoltare a MI. Dar este important de specificat că acesta va evolua continuu, odată cu mediul economic.

Adrian Abrudan

adrian.abrudan@loopaa.ro Senior partner & research director @ Loopaa

Faza 1 : MI este… NESEMNIFICATIV

Există piețe și afaceri unde consumatorii nu au putere de negociere. Drept consecință, nu există preocupare pentru marketing în general, cu atât mai mult, nu există preocupare pentru MI deoarece nu are efecte directe asupra afacerii. O altă caracteristică a acestor afaceri este că forța de muncă nu reprezintă o problemă. Putem da un exemplu extrem despre unele organizații bugetare, în care salariul e bun, pe lângă care mai sunt alte beneficii/prime, pozițiile sunt de regulă cu responsabilități mici, reprezentând pentru unii jobul ideal. În același timp, managementul poate fi: numit politic, needucat, fără nici un interes privind opinia sau motivația angajaților, puțin preocupat de beneficiarii serviciilor organizației pe care o conduce pentru ca, de regulă nu exista alternativă/concurență.

Faza a 2-a : MI se referă la…. SATISFACȚIA CLIENȚILOR

Printre cei care au analizat particularitățile MI mulți au concluzionat că acesta are rolul de a crește satisfacția clienților. Aceasta este încă o consecință a acțiunilor de MI chiar dacă în zilele noastre MI are obiective mult mai clar și specific definite.

nr. 32/2015 | www.todaysoftmag.ro

Descrierile inițiale ale conceptului de MI s-au preocupat de satisfacția clienților. Poate cea mai relevantă descriere este cea prezentată în “Marketing for Hospitality and Tourism 3e, Kotler P, Bowen J and Makens J (2003)” care scoate în evidență cinci trăsături esențiale ale MI: • Angajații trebuie să aibă o atitudine orientată spre satisfacția clieților. • Angajații trebuie să înțeleagă bine produsul/serviciul pe care îl oferă. • Angajații trebuie să fie entuziaști când vorbesc de produs sau compania lor. • Trebuie să fie o bună comunicare între management și angajați. • Angajații trebuie să aibă capacitatea să identifice nevoile clienților. În aceasta fază, responsabilitatea MI este încă în mâinile managementului sau a responsabililor de vânzări, în timp ce Resursele Umane (RU) încearcă să acopere necesitățile lor orientate spre vânzări.

Faza a 3-a: MI se referă la… BRANDING

Ce este nou în această fază este faptul că activitățile de MI se concentrează pe a vinde brandul companiei angajaților. MI are ca scop ,,atragerea, dezvoltarea și motivarea și reținerea angajaților calificați’’.

legal Berry &Pasuraman (1991). Acțiunile specifice acestei faze sunt: • Conceptul de MI este un instrument pe care companiile încep să îl folosească în interior pentru a comunica cu angajații. • Educarea angajaților este necesară pentru a cunoaște obiectivele. Toți din companie trebuie să afle obiectivele și cum urmează acestea să fie îndeplinite. • Se vorbește de o cultură internă creată de managerii organizațiilor. Această cultură internă permite angajaților să își exprime creativitatea la nivelul la care rămân responsabili și pot fi controlați. • Managementul schimbării a oferit o creștere a importanței MI pentru că trebuiau comunicate angajaților schimbările, noua poziționare într-un mod cât mai eficient. • Specific acestei faze este conceptul prin care un grup de angajați dintr-o organizație devin CLIENȚI pentru alt grup de angajați din aceeași organizație. Chiar dacă ideea a mai existat în activitățile urmărite pe centre de profit, în acest caz concentrarea MI era asupra creșterii satisfacției clienților interni ai companiei. Angajații au fost implicați și mai mult în branding. Imaginea lor este parte din brandul companiei uneori, ceea ce asigură pe de o parte recunoașterea performanțelor dar și un grad de retenție ridicat.

Faza a 4-a: MI se referă la MOTIVAȚIE

Aceasta este faza în care concurența contează. Când o industrie are sute de poziții cheie descoperite, când nu există oferta de forță de muncă, când programele de reconversie profesională sau universitățile private se străduie

TODAY SOFTWARE MAGAZINE să furnizeze forța de muncă necesară, investiții noi se anunță cu alte mii de joburi deschise, MI primește altă prioritate. Acțiunile de succes de MI se referă în special la o îmbunătățire a motivației angajaților, a relațiilor de muncă, la leadership, team-building care sunt principii de management al RU. Dar recrutarea, motivarea, satisfacția angajaților, retenția sau recomandările de noi angajați devin prioritate ZERO, pentru că altfel se ratează oportunități sau concurența îți poate fura oameni valoroși din echipă. RU devin departamente de guerilla sales, iar headhunting-ul este din ce în ce mai prezent. Ofertarea beneficiilor salariale cer creativitate și ajung să ocupe o cotă importantă în bugetul de personal al companiei. În această fază, înlăturarea unor percepții negative despre unele aspecte ale companiei poate fi de asemenea un obiectiv de MI. De la un anumit nivel RU au nevoie de ajutor în ceea privește creativitatea și conceptele de comunicare internă . Aici vorbim de un mariaj între Marketing și RU. La baza, atât Marketing-ul cât și RU au activități care vizează oamenii. Conceptele de atitudine, motivație, satisfacție pot fi înțelese ușor și aceasta contează mult în stabilirea și atingerea obiectivelor de MI. Lucrurile se desfășoară la alt nivel de exigență. E nevoie de o rată de succes maximă atunci când, de exemplu, se realizează prezentarea companiei unor potențiali angajați, se comunică intern diverse proceduri, se organizează evenimente interne. Ajungând aici, următoarea fază devine și mai provocatoare.

Faza a 5-a: MI se referă la … ENGAGEMENT

În această fază RU iau în calcul efectul muncii în echipă pentru atingerea obiectivelor. Eficiența departamentului de RU ajunge să depindă de engagement, de felul în care se implică și restul angajaților în misiunea lor pentru asigurarea motivației angajaților și asigurarea necesarului de forță de muncă pentru management. Mai multe programe de MI țintesc efectul de echipă în: • Integrarea angajaților noi și coordonarea interfuncțională în departamente; • Implementarea strategiilor de brand sau a celor operaționale; • Valorizarea angajaților și integrarea lor în companie prin acțiuni de creștere a implicării pe departamente din organizație; • Recomandarea candidaților pentru pozițiile libere exploatează relațiile personale ale tuturor angajaților; • Adoptarea unor noi canale de comunicare devine obligatorie pentru creșterea nivelului de implicare a angajaților. În concluzie: Cei mai buni lideri înțeleg ca MI este un proces de business de bază în comunicarea internă. Investesc în MI. Îl transformă într-un avantaj competitiv. Trendurile de comunicare sunt importante. Sunt canalele tale de comunicare responsive pentru diversitatea display-urilor mobile? Folosești materiale video, animații în comunicarea cu angajații? Sunt afișele tale interne suficient de creative? Evenimentele interne sunt surprinzătoare? Sunt angajații tăi ambasadori ai strategiei companiei tale?

www.todaysoftmag.ro | nr. 32/februarie, 2015

management

Gogu la mici - Chelner, micii ăștia mi-au mâncat muștarul! Încercă Gogu o ironie fină, dar nu avu cu cine. - Vă mai aduc muștar? - No, n-ai priceput nimica, spuse înciudat Mișu. Nu muștarul îi problema aici, ci micii. Ia-i înapoi și mai pune-i o țâră pe grătar, că-s cruzi. - Revenind la ale noastre, Gogule, se întorse Mișu spre prietenul lui în timp ce chelnerul lua micii scuzându-se, zi-mi ce să fac. Spun or’ nu spun? Îi mai bine să fiu cinstit sau mai bine îmi apăr pielea? Că până la urmă la asta se reduce toată situația... Gogu se gândi puțin înainte să răspundă. Era ușor să dai sfaturi din afară, dar motivul pentru care colegii reveneau la el era faptul că niciodată nu încuraja pe cineva să facă ceva ce el n-ar fi făcut. Numai că în cazul lui Mișu lucrurile erau parcă și mai complicate. Și totuși... - Auzi, Mișule, ție când îți zice fi-miu că totul merge bine și e super la școală, tu ce faci? - Hă-hă, încerc să aflu ce s-o-ntâmplat de-adevăratelea. Îhm... crezi că așa o să reacționeze și încrâncenatul ăsta de Bernard? N-am văzut client mai cârcotaș ca ăsta. - Adevărul este că și clientul e om, hi-hi, râse Gogu; ignoră rictusul de neîncredere de pe fața lui Mișu și continuă: și el a trecut prin proiecte, știe că viața nu e roz și că nu există proiectul perfect în care toate să se alinieze și să iasă exact cum te aștepți. Dacă-i spui că ‚no problem, everything is perfect’ – zi și tu, sună ca dracu’ – abia atunci începe să se îngrijoreze și să pună întrebări. În mod ciudat, clientul capătă încredere în tine dacă vede că ai curaj să-i spui și despre părțile mai puțin strălucitoare ale proiectului. Evident, trebuie să știi să le împachetezi frumos. Fața lui Mișu sugera nu doar confuzie, ci mai degrabă o zbatere internă însoțită de durere fizică. Mi se sparge capul: dacă îi spui adevărul, ce să mai împachetezi?! Ori îi spui, ori nu... Uff, manager de proiect mi-a trebuit... Gogu citi fața lui Mișu și intui ce se petrecea în mintea uriașului ardelean. Se decise să îl ajute la împachetare: - Dar voi stați bine pe partea de dezvoltare, aveți probleme doar la migrare, nu? - Îhî, da’ alea ne-or da înapoi rău.

nr. 32/februarie, 2015 | www.todaysoftmag.ro

- Nu-i nimic, important e să-i dai posibilitatea de a compara avantaje și dezavantaje. În avans pe partea de dezvoltare, în întârziere pe partea de pregătire migrare. Cu atât mai mult va aprecia avansul. Știi experimentul cu ghetele? întrebă Gogu, continuă însă repede fără să mai aștepte răspuns. Fii atent aici: experimentul se desfășoară în două magazine unde se urmărește vânzarea aceluiași tip de gheată. Într-un magazin, gheata este expusă și alături, vizibil, sunt listate avantajele ei: piele naturală în interior și exterior, talpă groasă din piele, impermeabile, rezistente la mers îndelungat în zăpadă și mai știu eu ce, iar la final, preț x euro, sau ce moneda o fi fost. În celălalt magazin, aceeași gheată și alături, vizibil, aceleași avantaje: piele naturală în interior și exterior, talpă groasă din piele, impermeabile, rezistente la zăpadă, alea-alea dar..., și aici Gogu făcu o pauză teatrală, la final au adăugat: dezavantaj, gheata este disponibilă doar în culorile negru și maro. După care preț x euro, la fel ca în celălalt magazin. Care crezi că s-a vândut mai bine? încheie victorios, cu ochii pe Mișu, așteptând răspunsul evident. Ei? - Ăla cu dezavantaj? Încercă nesigur Mișu marea cu degetul. - Exact, sări Gogu entuziasmat. Dezavantajul nu a făcut decât să întărească, să sublinieze avantajele. Un dezavantaj minor a crescut valoarea calităților, făcând gheata mai apetisantă. Foarte tare, ce zici? Și-ai să vezi, merge chestia asta și în comunicarea cu clientul... - S-au întors micii! apăru în sfârșit și chelnerul. I-am ars puțin, dar măcar acum sunt bine făcuți! - Hmm, se uită Mișu la mici, iar apoi la Gogu, mai apetisant zici?!

Simona Bonghez, Ph.D.

simona.bonghez@confucius.ro Speaker, trainer şi consultant în managementul proiectelor, Owner al Colors in Projects

sponsori