today software magazine n32/2015

TSM T O D A YS O F T WA R E

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

M AG A Z I N E

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

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ățireaSoftware Design-ului

Gândirea critică în analiza de business

Today Software Magazine a împlinit trei ani !

6Today Software Magazine

împlinește 3 aniOvidiu Măţan

7CLUJ INNOVATION DAYS

2015Andrei Kelemen

8Impactul evenimentelor Startup Weekend la nivel global și local

Cristina Juc și Cristina Tare

9O întâlnire cu știința,

tehnologia și antreprenoriatulOana Călugăr

10How to Web

MVP AcademyIrina Scarlat

12Registrul de biciclete

Diana Silaghi

15Experimentul cu WATCHKIT SDK

Chertes Cristian și Korosi Csongor

18JavaFX și comunicarea prin

RESTful Web Services (II)Silviu Dumitrescu și Diana Bălan

22Soluții non-invazive ale

tehnologiei în domeniul medical Mursa Bogdan

24Dinamicile adoptării unei

mentalități AgileCălin-Vlad Gîngă

2

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

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

33Programatorii testează? Testerii scriu cod?Raluca Morariu

35Aromă IoT: SensoriadaAndrei Crăciun

38Analiza sentimentelor şi complexitatea opiniilor onlineCosmin Gabriel Popa

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

43Java 8 OptionalPeter Lawrey

44Aprofundare a SLA-urilor furnizorilor de servicii cloudRadu Vunvulea

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

47Gogula miciSimona Bonghez, Ph.D.

4 nr. 32/2015 | www.todaysoftmag.ro

Î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ă entu-

ziasmul 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 senti-mentelor ș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ăţanFondator al Today Software Magazine

Ovidiu Măţ[email protected]

Editor-in-chief Today Software Magazine

editorial

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

Redacţia Today Software Magazine

Fondator / Editor in chief: Ovidiu Mățan [email protected]

Graphic designer: Dan Hădărău [email protected]

Copyright/Corector: Emilia Toma [email protected]

Traducător: Roxana [email protected]

Editor startups: Mircea Vă[email protected]

Reviewer: Tavi Bolog [email protected]

Contabil : Delia [email protected]

Produs de Today Software Solutions SRL

str. Plopilor, nr. 75/77Cluj-Napoca, Cluj, [email protected]

www.todaysoftmag.rowww.facebook.com/todaysoftmag

twitter.com/todaysoftmag

ISSN 2284 – 6352

Copyright Today Software Magazine

Reproducerea parțială sau totală a articolelordin revista Today Software Magazine

fără acordul redacției este strict interzisă.

www.todaysoftmag.rowww.todaysoftmag.com

Lista autorilor

Alexandru Bolboacă[email protected]

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

Simona Bonghez, [email protected]

Speaker, trainer and consultant in project management,

Owner of Colors in Projects

Diana Bă[email protected]

Java developer@ Accesa

Silviu [email protected]

Java Line Manager@ Accesa

Andrei [email protected]

Director executiv@ IT Cluster

Oana Călugă[email protected]

Ambassador în România @ Hello Tomorrow

Cristina [email protected]

Organizatoare @ Startup Weekend Cluj



Diana [email protected]

PR Manager@ Registrul de Biciclete

Chertes [email protected]

iOS Developer@ Telenav

Korosi [email protected]


Mursa [email protected]

Software Developer @ Yardi

Călin-Vlad Gîngă[email protected]

Software developer@ ISDC

Liviu Ştefăniţă [email protected]

Senior Business Consultant@ Endava

Raluca [email protected]

Senior QA Engineer @ Betfair

Andrei Cră[email protected]

Mobile Developer@ Intel

Peter [email protected]

CEO@ Higher Frequency Trading Ltd

Răzvan [email protected]

Business Analyst@ Endava

Adrian [email protected]

Senior partner & research director@ Loopaa

Cosmin Gabriel [email protected]

SA R&D Osprov Team@ HP

TODAY SOFTWARE MAGAZINE

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

Today Software Magazine împlinește trei ani

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 aces-tora î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 pro-movarea 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 ingredi-entele 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 reprezen-tat o adaptare la ecosistemul local.

Ingredientele importanteRealizarea conținutului pentru pri-

mul număr a reprezentat o provocare. O mare parte dintre prieteni s-au mobilizat și au contribuit fiecare cu câte un arti-col. 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 perso-nal, 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 compani-ilor 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 impor-tant 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 par-tea 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 arti-cole trimise spre publicare deoarece fiecare știa să se raporteze în planificare la o anu-mită lună.

Nevoia unei calități a exprimării conținutului a reieșit după primul număr. Deși programatorilor nu li se pretinde

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 viitorRecent am lansat cardul TSM pentru

da o șansă comunității să se implice într-un 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!

Î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.

Ovidiu Măţ[email protected]

Editor-in-chief Today Software Magazine

business



CLUJ INNOVATION DAYS 2015

De la cunoaştere la valorile pieţei

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: ofici-ali 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 afa-ceri 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 antre-prenoriatul 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 inter-acţ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 ase-menea 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!

Pregă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.

Andrei [email protected]

Director executiv@ IT Cluster

eveniment



Startup Weekend este un concept creat în America și exportat apoi la nivel global care se axează pe ideea de educație și dez-voltare personală. Organizatorii îți oferă un spațiu , resurse, mentori și, cel mai important, oportunitatea de a întâlni per-soane 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 par-ticipant 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 antrepre-nori ș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 ante-rioare, 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 con-cretizează în următoarele produse.

• în 2012 a luat naștere plat-forma UseTogether- comunitatea axată pe consumul colaborativ;

• în 2013, OmniPaste își propunea să schimbe modul de transfer a datelor ;

• în 2014, echipa 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 crea-tivitate ș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

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. http://startupweekend.org/wp-content/

blogs.dir/1/files/2013/04/Impact-Report-Guide-TEST-42C-4_11.pdf

2. http://cluj.startupweekend.org/2013/03/05/winning-teams-at-star tup-weekend-cluj-2013/

3. http://cluj.startupweekend.org/2014/03/10/winning-teams-swcluj-2014/

4. http://cluj.startupweekend.org/2012/02/23/winning-teams-at-star tup-weekend-cluj-2012/

antreprenoriat

Impactul evenimentelor Startup Weekend

la nivel global și local

Pentru 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.







Hello Tomorrow este o inițiativă glo-bală non-profit unde știința și tehnologia întâlnesc spiritul antreprenorial pentru a construi viitorul.

Îi provocăm pe cei ambițioși și dor-nici să aducă schimbarea, pe cei care conștientizează problemele a șase domenii distincte cu care se confruntă azi societa-tea, 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.

Scopul nostru: să îi transformăm pe inventatorii din întreaga lume în antrepre-nori de succes, prin accelerarea dezvoltării inovației și prin introducerea ei pe piață.

Ce câștigă cei 30 de semifinaliști?C r e d i b i l i t ate ș i n e t w o r k i n g :

startup-urile va fi puse în contact cu

investitori internaționali, potențiali par-teneri și clienți, precum și alte startup-uri consacrate.

Mentoring: un program de mento-rat 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 vor-bitori 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 cofonda-torul 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 15.000 EUR fiecare, iar marele câștigător va primi 100.000 EUR.

Condiții de aplicare< 250.000 EUR din investiții externe,< 2 ani de la fondare.

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 [email protected], urmărește-ne pe Twitter twitter.com/HT_Cluj și Facebook: facebook.com/HelloTomorrowRomania.

antreprenoriat

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

Credem 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 schim-barea, 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.

Young spiritMature organizationA shared vision

Join our journey!

www.fortech.ro

Oana Călugă[email protected]

Ambassador în România @ Hello Tomorrow


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 extin-derea echipei de dezvoltare a produsului.

“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 networking excelente, printre cele mai bune din România”, a declarat Andras Kapy, Fondator Axosuits.

getFittter Inc., aplicație care oferă utilizatorilor o experiență de antre-nament personalizată, se numără de

asemenea printre echipele care au înregis-trat rezultate excepționale: după absolvirea programului, aceștia au fost acceptați în Health Wildcatters, cel mai apreciat pro-gram 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 înce-put 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.

“MVP Academy a avut o contribuție majoră atât prin faptul că am fost acceptați într-un accelerator valoros din US, cât și prin evoluția foarte bună pe care am avut-o ulte-rior. Mai mult decât atât, programul ne-a ajutat să rafinăm și să cristalizăm anumite idei pe care am avut ocazia să le discutăm și să le evaluăm cu o serie de mentori extrem

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 cunos-cut din Statele Unite. Lifebox (platformă care oferă utilizatorilor oportunitatea de a crea albume de fotografii private cu prie-tenii 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

How to Web MVP Academy

București, 27 ianuarie 2015 – Finanțări în valoare totală de 207.000 EUR... Patru startup-uri admise în programe de accele-rare 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.

antreprenoriat



ale produsului. Iar exemplele pot continua: peste jumă-

tate dintre absolvenții How to Web MVP Academy au adus îmbunătățiri considera-bile 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 dis-ponibil 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 regi-une 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.

Par t ic ip ând l a workshop -ur 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 pre-accelerare How to Web MVP Academy s-a încheiat cu Demo Day, eveniment în cadrul căruia echipele finaliste și-au pre-zentat 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 partici-pante 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 site-ul MVP Academy pentru a fi la curent cu ultimele noutăți.

Irina [email protected]

PR Manager @ How to Web & TechHub Bucharest


Ce este Registrul de BicicletePe 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ă bici-cletă, 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 aseme-nea, î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ă:

Dacă ți se fură bicicleta

1. Intri pe site și schimbi statusul bici-cletei î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 și organele de poliție, acționând ca un cetățean responsabil.

Funcția Transfer

Bineînțeles, bicicleta se poate înstrăina, de exemplu în cazul vânzării, prin funcția de “Transfer” de pe site.

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 sis-teme 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;

Mișcarea “Bike2Work”În toamna anului trecut, împreună

cu JCI Cluj Napoca am demarat mișcarea “Bike 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 nevoile lor și ale companiilor în contextul infrastructurii locale și a siguranței 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.

diverse

Registrul de biciclete

Două 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.

1. Citește-i seria de cadru

3. Introdu caracteristici

4. Aplică un tag de identificare

2. Adaugă poze



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

O idee bună, susținem!

Depinde de implicațiile din partea companiei.

Nu suntem interesați.

Altele.

Ai aprecia efortul companiei tale de a-ți oferi facilități legate de biciclete?

Da.

Nu.

Altele.

Propunerea noastră pentru companiiCum 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, cu implicații directe sau indirecte asupra

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 constată o îmbunătățire a imaginii și a performanțelor companiilor care își încurajează angajații să facă sport.

Avem în acest sens un plan elabo-rat prin care propunem diverse facilități angajaților în vederea încurajării folosirii bicicletei fie în timpul liber, ca o alternativă a mersului la sală, fie ca mijloc de transport la serviciu.

Pentru bicicliștii existenți în companie• autocolante de identif icare a

bicicletelor;• card de reduceri la magazine de

biciclete;• tricouri;• echipament și accesorii personali-

zate cu identitatea companiei;• sisteme alternative de securizare

(trackere GPS).

Pentru cei care nu au încă bicicletă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 bene-ficiu 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 perso-nalizate ale companiei, fie ca biciclete

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

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 înregis-

trare rapidă și alte funcționalități utile;• Diversificarea metodelor de prote-

jare 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.

www.3pillarglobal.com

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

Our core competencies include:

ProductStrategy

ProductDevelopment

ProductSupport

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

Diana [email protected]

PR Manager@ Registrul de Biciclete


Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: www.transylvania-jug.orgData înfiinţării: 15.05.2008 / Nr. Membri: 599 / Nr. Evenimente: 47

Comunitatea TSMComunitate construită în jurul revistei Today Software Magazine.Websites: www.facebook.com/todaysoftmag www.meetup.com/todaysoftmag www.youtube.com/todaysoftmagData înfiinţării: 06.02.2012 /Nr. Membri: 2068/Nr. Evenimente: 28

Cluj Business AnalystsComunitate dedicată analizei de businessWebsite: www.meetup.com/Business-Analysts-ClujData înfiinţării: 10.07.2013 / Nr. Membri: 91 / Nr. Evenimente: 8

Cluj Mobile DevelopersComunitate dedicată tehnologiilor mobileWebsite: www.meetup.com/Cluj-Mobile-DevelopersData înfiinţării: 05.08.2011 / Nr. Membri: 264 / Nr. Evenimente: 17

The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 437 / Nr. Evenimente: 93

Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: www.meetup.com/Cluj-Semantic-WEBData înfiinţării: 08.05.2010 / Nr. Membri: 192/ Nr. Evenimente: 29

Romanian Association for Better SoftwareComunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.Website: www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 251/ Nr. Evenimente: 14

Tabăra de testareComunitate formată din testeri și alți profesioniști din industria IT care, în cadrul unor întâlniri informale lunare, împărtășesc din cunoștințele proprii și învață din experiențele profesionale ale celorlalți membri.Website: www.tabaradetestare.roData înfiinţării: 15.01.2012/Nr. Membri: 1243/ Nr. Evenimente: 107

Suntem î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 .

Calendar Februarie 18 (Cluj)Lansarea numărului 32 al Today Software Magazine www.todaysoftmag.ro

Februarie 19-20 (Cluj)MOBOS - recomandat de TSMhttp://romobos.com/

Februarie 18 (Iași)Open Hack Nightmeetup.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 TSMcolorsinprojects.ro/eveniment-cluj-6-7-martie-2015

Martie 19-20 (Cluj)Cluj Innovation Days - recomandat de TSMhttp://clujinnovationdays.com/

Februarie 28 (Cluj)Selenium Saturdayt 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

Comunităţi IT

comunități


programare

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

Arhitectura unei aplicații WatchDupă cum se poate observa în diagrama

de jos, o aplicație pentru ceasuri este compusă din două parți: o extensie care rulează pe tele-fon și o aplicație care rulează pe iWatch2.

Aplicația pentru ceas conține doar interfața cu utilizatorul - un fișier de tip sto-ryboard ș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/

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 Xcode1. Pentru început, trebuie să aveți insta-

lată 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 ima-ginea 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.

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

Experimentul cu WATCHKIT SDK

Crearea unei aplicații de navigație

Chertes [email protected]


Korosi [email protected]



4. Selectați target-ul Watch app și rulați aplicația. Asigurați-vă că unul din display-urile externe ale simulatorului e selectat.

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.

WatchKitDemo: com.skobbler.WatchKitDemoWatchKitDemo WatchKit Extension: com.skobbler.Watch-KitDemo.watchkitextensionWatchKitDemo 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:

Aplicația WatchKitDemoPrima 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ă configu-reze 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] initWithApplicationGroupIdentifier:@”group.WatchKitDemoGroup” optionalDirectory:nil];

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

programareExperimentul cu WATCHKIT SDK



//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) {}];

Aplicația creată este o demonstrație a ceea ce pot face progra-matorii 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.

• WatchKit SDK nu trimite informații în legătură cu orien-tarea ceasului.

Sperăm ca în următoarea versiune a librăriei aceste probleme să poată fi rezolvate.


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

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:

• @lRootElement(namespace = „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 .

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; }

public String getAuthor() { return author;

}

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”)

JavaFX și comunicarea prin RESTful Web Services (II)

programare

Diana Bă[email protected]

Java developer@ Accesa

Silviu [email protected]

Java Line Manager@ Accesa



// the name of the wrapper element

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

private ArrayList<Message> topicList; private String topicDescription;

public voidsetTopicList (ArrayList<Message> topicList) {

this.topicList = topicList; }

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

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 mode-lului anterior și apoi îl vom citi.

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”);

topicList.add(message2);

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

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

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

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

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

// 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 mode-

lele 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.

@XmlRootElementpublic 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() {

diverse


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; }

}

@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 TodosResource 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 Transi-tional//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

programareJavaFX și comunicarea prin RESTful Web Services (II)



• La adresa, http://localhost:8080/CRUDRest/jaxrs/todos/1, vom vizualiza todo-ul cu id-ul 1. Pentru un id inexistent vom avea o eroare HTTP

Putem crea următoarea aplicație client:

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));

// 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(); }}

Vom încheia acest articol cu pașii de urmat în generarea unui serviciu web REST:

• Verificarea următoarelor condiții:• Jersey este adăugat proiectului.• 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 deplo-iat și adnotațiile metodei.

• Cererile GET, PUT, DELETE, sau POST invocă metodele potrivite ale serviciului.

• Metodele returnează datele așteptate.

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 rezul-tatele 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!


programare

Soluții non-invazive ale tehnologiei

în domeniul medical (Kinect)

Nici domeniul medical nu reprezintă o excepție: specialiștii cer soluții tehno-logice 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ă impli-cată în dezvoltarea de astfel de soluții este una uriașă, nefiind accesibilă unui simplu programator.

Din fericire însă, deși a trecut rela-tiv 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 sumede-nia 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 capa-bil să detecteze mișcările corpului, scopul lui fiind evident industria jocurilor.

Cum funcț ionează e l de fapt? Ajutându-se de senzorul care calculează rezultatele furnizate de coliziunea razelor infraroșu cu obiectele din fața dispozitivu-lui, 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 reprodu-cerea 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 apro-ximativ 100 de puncte la nivelul feței, un lucru foarte important și valoros, deoa-rece 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 dom-nul 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

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 interme-diul micilor joculețe din aplicație, se pot înlocui exercițiile ce creează o stare de dis-confort 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 sta-tistici 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 fap-tul că această soluție este non-invazivă.

Folosindu-ne de capacitatea senzorului de a detecta punctele importante la nive-lul 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ă con-troleze șarpele prin două mișcări simple ale gurii: zâmbet - la dreapta, gură des-chisă - 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.

Este 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.



Algoritmul care s t ă î n s p a t e l e 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âm-bet, 62-66 (buza de sus - buza de jos) pentru a des-ch i d e g u r a . În momentul în care se iniț ia l izează jocul, se calcu-lează 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ă punc-tele 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 pen-tru a strânge puncte și a stabili noi scoruri record.

Pentru exerciții de genul acesta, după cum spuneam, senzorul și SDK-ul Kinect-ului ne furniza tot ce aveam nevoie. Însă cea mai mare dificultate pe care am întâm-pinat-o alături de colegii mei, a fost să creăm un algoritm capabil să detecteze limba. Așa ceva era aproape de neconce-put, mai ales că soluția noastră era una care nu implică atașarea de senzori direct pe pielea pacientului.

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 pro-cesată, 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âr-ful 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.)

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 utiliza-torului 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 asi-gurat un loc printre finaliștii competiției

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 cap-tare a mișcărilor corpului sau feței. De asemenea, acesta deține și suportul pen-tru 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ă, benefi-ciarul principal pentru care este dezvoltat fiind industria jocurilor, dar este un can-didat perfect pentru facilitarea terapiei pacienților ce se află într-un stadiu mai avansat de recuperare (mai exact, se adre-sează 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.

Mursa [email protected]

Software Developer @ Yardi

programare

Objective C

[email protected]

Yardi Romania


Dinamicile adoptării

unei mentalități Agile

Cu câteva luni în urmă am participat la Conferința Scrum de la Berlin, organi-zată 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 bene-ficiu real.

Atunci când vorbim despre Agile, vor-bim 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 incre-mentală 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 ai mu 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 pro-cesului ș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ândi-rii agile. Organizațiile apelează la ajutorul

unui coach agile și devin la rândul lor cli-entul acestuia, produsul fiind procesul de adaptare la o nouă gândire. Un coach tre-buie 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

ObservatorScopul observatorului este de a lua

parte la toate activitățile de zi cu zi ale echi-pei, 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

managementprogramare

Călin-Vlad Gîngă [email protected]

Software developer@ ISDC


TODAY SOFTWARE MAGAZINEmanagement

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 pau-zele 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ă identi-fica și propune soluții pentru potențialele probleme.

Consilier TehnicUnul 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 fundamen-tală 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 momen-tul 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 des-chis 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 cea-laltă, 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, cli-entul 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ă pen-tru 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 dis-cutate 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.

ExpertAș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ăsu-rile 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 mem-brii 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 capaci-tatea 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.

FacilitatorFacilitatorul este foarte folositor în

cadrul organizațiilor care se află la începu-tul perioadei de tranziție spre o mentalitate agilă. Este acel rol care ajută un grup de indivizi să ajungă la obiective comune și apoi îi asistă în atingerea acestora. De ase-menea, prezența unui facilitator poate fi benefică atunci când sunt explorate diferi-tele riscuri care pot apărea când un grup este informat despre o decizie majoră. Datoria unui facilitator este de a crea un context și un mediu propice discuțiilor astfel încât scopul principal al acestora să

nu fie uitat. Pe toată durata procesului tre-buie 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 retrospec-tivă 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.

ProfesorLa fel ca și în cazul expertului, profeso-

rul 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 tre-buie 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, profe-sorul poate opta pentru seminarii sau laboratoare referitoare la aspecte precum practici XP și Scrum sau prezentări față în față pentru un rol de Scrum Master, spre exemplu.

ModelatorModelatorul este persoana care este

adusă în cadrul unei companii cu scopul de a fi un model pentru ceilalți angajați. Dacă în cazul expertului acesta juca rolul Scrum Master-ului pentru a se asigura că lucrurile merg într-o anumită direcție, modelatorul va juca acest rol într-un sprint iar apoi cineva va face același lucru


î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.

ConsilierConsilierul 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 responsa-bil 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 pozi-tiv. Consilierul trebuie să asculte într-un mod activ, să explice problema identificată și să evidențieze toate aspectele care au nevoie de o atenție mai mare.

Agile coachProbabil cel mai comun nume al unui

expert Agile este coach-ul. Acesta este per-soana care este chemată într-o organizație pentru a învăța, a ajusta, a prezenta și pen-tru a discuta despre agilitate. În realitate el nu trebuie să învețe nimic. Rolul aces-tei persoane este de a sugera soluții după o analiză preliminară. Un coach trebuie să scoată clientul din zona de confort iar pentru ca acest lucru să funcționeze, este necesar preocuparea clientului de a deveni mai bun. El va oferi suport, dar la finalul zilei clientul va decide ce să facă și cum să acționeze. După tot acest proces, va oferi feedback după care procesul începe din nou.

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

PartenerCând o persoană este adusă în cadrul

unei organizații pentru a fi partener al cli-entului 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.

IDAM AdvisoryÎn cadrul ISDC există un grup de per-

soane numit IDAM (ISDC Defined Agile Model) implicat în dezvoltarea unei meto-dologii agile, bazată pe Scrum, modificată, modelată și formată pentru a fi eficientă în mediul, cultura și organizația noastră.

Unul dintre cele mai de succes proiecte la care lucrăm este IDAM Advisory (con-siliere IDAM) care combină câteva dintre rolurile prezentate mai sus. De cele mai multe ori asistăm la ceremonii și activități din cadrul echipelor pentru o perioadă determinată, timp în care observăm și ana-lizăm comportamentul membrilor echipei și reacția lor la apariția unor probleme, precum și la modul în care oferă soluții. Gândindu-ne la aspectele prezentate mai sus, aceste activități sunt făcute de un observator.

În urma acestei analize ascultăm păre-rile 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 ade-vă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 ade-vă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.

Dinamicile adoptării unei mentalități Agileprogramare programare


Responsabilităț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

din perspectiva unei echipe din cadrul unei companii IT de outsourcing (servicii exter-nalizate). 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 într-o 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 clien-tului, 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 oi l e a r ân d , u n BA t re -buie să identifice punctele slabe ale proiectului, acestea fiind cele mai suscepti-bile pentru îmbunătățiri. Iată câteva dintre cele mai frecvente:

• Procesele din cadrul proiectului;• Documentația proiectului (neactuali-

zată sau inexistentă);• Relațiile cu persoanele interesate de

rezultatul proiectului (stakeholders);

Rolul unui Business Analyst într-un

proiect de dezvoltare software

managementprogramare

Liviu Ştefăniţă [email protected]

Senior Business Consultant@ Endava


• Backlog - lista de cerințe ordonată după prioritate;

• Problemele care apar cu o frecvență crescută – cerințe neclare, specificații incomplete, design 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 subli-niază 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 inte-riorul echipei prin preluarea unor responsabilități de la SM, PM, progra-matori 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.

ProceseleNevoia de îmbunătățire a procese-

lor 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 constitu-ite ca un amestec dintre procesele interne ale companiei și procesele din cadrul com-paniei 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 pen-tru 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 pro-grame pentru întocmire a diagramelor de proces (ex. MS Visio), suite de aplicații pentru birou (MS Office, Libre Office, Open Office).

Îmbu năt ăț i re a pro c e s e l or 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 încre-dere semnificativ.

Documentația de proiectDocumentarea 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 pro-pune 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 instru-mente de urmărire a sarcinilor de lucru

(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 sufici-entă pentru nevoile echipei, ori absentă, dar considerăm că este loc de îmbunătățiri aproape tot timpul.

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

Pentru a putea să amelioreze acest aspect, analistul trebuie să cunoască stake-holder-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 comu-nicarea. Mijloacele pe care le poate folosi sunt matrici RACI/RASCI (Responsible-Accountab l e - C on su l ted - In for med / Responsib le -Accountable -Suppor t -C on su l ted - Infor med ) , p l anu r i d e comunicare, la a căror întocmire să parti-cipe activ și analistul.

BacklogAceastă 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 t ipuri de argu-mente care pot fi coroborate pentru a obține acceptarea schimbărilor, și anume: alinierea cu metodologia de lucru, consistența și claritatea cerințelor,

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



structurarea și îmbunătățirea elementelor backlog-ului (Epic – User Story – Task), dar și a specificațiilor aferente, sunt câteva exemple în acest sens.

Problemele care apar cu o frecvență crescută – cerințe neclare, specificații incomplete

Aceasta este o provocare ‘pozitivă’ pen-tru analist într-un proiect nou, pentru că lipsa de claritate a cerințelor, absența sau calitatea slabă a specificațiilor sau designu-lui sunt situații care permit analistului să prezinte soluții rapide și vizibile.

Pentru a oferi soluții acestor probleme, analistul are la îndemână o paletă largă de aplicații, după cum urmează:

• Pe nt r u m a ch e te ( mo ck - ups ) funcționale: Balsamiq, moqups, Just in Mind;

• Pentru elemente de design de interfață (UI): Photoshop, Paint.Net, 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 iden-tifica în mod precis acele cerințe care necesită astfel de detaliere. Prezentarea

detaliilor către echipă este, de asemenea, un pas important.

InformareEchipa SCRUM trebuie cunoască

detalii despre proiect, despre produs, dar trebuie să aibă și o imagine de ansam-blu despre schimbările care se petrec în organizația clientului și în domeniul de activitate al acestuia. Deși nu afectează direct munca echipei, aceste informații influențează moralul acesteia, crescând nivelul de importanță care se acordă mun-cii fiecăruia dintre membrii ei. În același timp, analistul câștigă un capital de încre-dere prin faptul că oferă aceste informații.

Pentru a crește nivelul de informare, analistul are la îndemână o serie de instrumente, cum ar fi: discuții ad-hoc, interacțiuni regulate cu membrii echipei (în cadrul ceremoniilor SCRUM), prezen-tări ocazionale de informare.

ConcluziiExistă 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 instru-mentele prezentate mai sus, analistul poate influența atât procesele interne ale echipei, cât și procesele din organizația clientului,

adăugând valoare produsului dar și celor două organizații implicate.

Așa cum menționam în primele para-grafe, feedback-ul pentru argumentația de mai sus este binevenit și va fi luat în considerare pentru viitoarele articole des-pre beneficiile pe care le poate aduce un BA într-un proiect de dezvoltare software externalizat care folosește metodologia SCRUM.


Software 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.

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 con-siderare 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 arhitec-tură 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 scri-ind 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.

Este imposibil să scrii cod care obține un 10/10 pentru toate aceste criterii simul-tan. 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: pen-tru 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 con-text; 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 descope-rit că am putea folosi delegates ca expresii lambda, reducând astfel numărul de linii de cod pe care trebuia să le scriu. Am rezis-tat 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ă.

Patru idei pentru îmbunătățirea

Software Design-ului

programare

Alexandru Bolboacă[email protected]

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



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 deza-vantajele 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, discu-tă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ă utilizatori-lor 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 software-ul 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 feedback-ul 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 din-tre î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.

Software design-ul are utilizator. Utilizatorul este dezvoltatorul care va tre-bui să schimbe codul pe care îl scrii. Dacă folosiți collective code ownership (ca majo-ritatea 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 des-pre 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?

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

Software-ul este cunoaștere execu-tabilă. De exemplu, când scrii o aplicație de contabilitate, se codifică tot ce știi despre regulile și procedurile de conta-bilitate. Cum au ajuns aceste cunoștințe în aplicație? Prin preluarea acestora de la specialiști și trecerea prin creierul dezvol-tatorilor 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 calculatoa-rele și pot gândi cu un nivel foarte ridicat de precizie. De aceea nu cred în programa-rea vizuală făcută de specialiști.

Cum învață și îș i structurează cunoștințele oamenii? Prin atribuirea de nume lucrurilor. Dacă te gândești la anii de școală, îți amintești de învățarea des-pre 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 pen-tru 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 struc-turează dezvoltatorii cunoștințele în cod. De ce este acest lucru rău? Deoarece cre-ierul trebuie să-și petreacă timp valoros încercând să traducă ceea ce citește către

ce face aplicația. Acest lucru duce la redu-cerea 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 busi-nessului? Sunt acestea prezente în cod?

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

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 dezvolta-rea 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

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, sis-teme 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 conceptu-ală? Probabil din cauza modului în care creierul nostru funcționează. Memoria

programare


omenească de lucru se limitează la păstra-rea 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 apli-cată 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 micro-services sunt unele dintre modelele care ușurează integritatea conceptuală la nivel de sistem. Dar nici o soluție nu este per-fectă, fiecare dintre ele are dezavantaje .

Un avertisment: integritatea concep-tuală 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 concep-tuală 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

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

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


testare

După 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ță.

Î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 lun-gul anilor m-au ajutat să devin bună în rolul actual.

Întrebările din titlul ar putea părea fami-liare 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 progra-

mator 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 des-pre scrierea de unit teste, fie că vorbim despre testarea funcțională a codului pe propriul cal-culator. 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 nive-lului 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 con-fortabil 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 aces-tea, acest lucru nu înseamnă că nu sunt în măsură să ajute în testare, iar în unele dome-nii 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 ter-meni de testare înainte de a preda o bucată de cod testerilor:

• Codul compilează.• Codul se instalează.• Unit testele sunt scrise.

Programatorii testează?

Testerii scriu cod?

Raluca [email protected]

Senior QA Engineer @ Betfair


• 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 majo-ritatea, 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 „automa-tion”, 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 încer-cat 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 pro-iect 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 abi-litatea de a rula aceleași teste în repetate

rânduri după efortul inițial de implemen-tare. Î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 apro-fundată a arhitecturii, limitările și punctele forte ale unui limbaj de programare pre-cum ș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 dome-niu. 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

ConcluziiDeci, 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 vari-ate ș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

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.

testareProgramatorii testează? Testerii scriu cod?


Lumea dezvoltării de software are multe ingrediente, iar dezvoltatorii de software pre-feră arome diferite. O abordare mai ludică ce menține această analogie cu domeniul culinar oferă ocazia relevării unor aspecte specifice pentru lumea Internetului lucru-

rilor (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 ingre-dientul 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ă, auto-matizarea 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 afec-tează 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ă modi-fică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 ajus-tează 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 frec-

venţă î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, proce-sate ș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 elec-tric 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 pri-mit și pe care doresc să vi-l împărtășesc este următorul: într-un proiect, senzorii și dispo-zitivele 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 conside-răm ca fiind cea mai relevantă pentru acest proiect. În imaginea de mai jos sunt prezen-tate patru etape ale acestui ciclu:

1. Măsurarea pe parcursul căreia datele sunt citite de la senzori;

Aromă IoT: Sensoriada

Andrei Cră[email protected]

Mobile Developer@ Intel

programare


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 proce-sate și pe baza acestora sunt decise acţiuni. Pe parcursul acestei etape, interacţiunea cu alte sisteme precum și analiza pot fi vizi-bile, după cum vor fi în cazul nostru.

4. Reacţia este faza în care acţiunile decise în etapa de ana-liză 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.

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 pen-tru a comunica; este rezistent la apă și are o arie de măsurare destul de bună (http://www.seeedstudio.com/depot/One-Wire-Temperature-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 wire-less ; 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+ pen-tru transmiterea de date. (http://www.seeedstudio.com/depot/DevDuino-Sensor-Node-V2-ATmega-328-AAA-battery-holder-p-1850.html)

• ieșirea (the gateway) este un dispozitiv care este întotdeauna pornit; este conectat cu sau fără fir la nodurile de senzori și are rolul de a colecta toate datele de la senzori pentru a le face disponibile pentru procesare; alegerea noastră pentru ieșire a fost un impuls electric la care am conectat un modul îmbu-nătăţit nRF24L01+ pentru a putea primi pachetele trimise de la nodurile de senzori; principalul motiv pentru alegerea unui impuls este faptul că are un adaptor WiFi încorporat și de ase-menea gestionează într-un mod transparent pentru dezvoltator

conexiunea cu electric imp cloud, ocupându-se de cazurile spe-ciale cum ar fi pierderea conexiunii sau reconectarea.

• cloud cache este o aplicaţie pe partea de server care este ine-rentă î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 ele-mente 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 ele-mente: identificarea (“id” care este în prezent un întreg, dar există o întreagă dezbatere pentru a o face un șir), starea energiei (“vol-taj”), acuratețe (“secondsAgo”- acum n secunde de la “dată”) şi lista de senzori. Un senzor va avea drept elemente tipul, versi-unea ș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 senzo-rului ș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ă: { „sensorNodes”:[ { „id”:0, „voltage”:2848, „secondsAgo”:247192, „date”:”2015-01-24 07:10:21”, „sensors”:[ { „type”:10, „version”:1, „value”:787 } ]

managementAromă IoT: Sensoriada



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

Din punctul de vedere al Android, modelul Nodului de Senzori este foarte simplu și include elementele definite mai sus.

public class SensorNode { public long id; public int voltage; public long secondsAgo; public Date date; public List<Sensor> sensors = new LinkedList<Sensor>();}

Modelul Senzor este o interfaţă deoarece avem o mare diver-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() pen-tru 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ă ver-siunea 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 apli-caţ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

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

Magia are loc în clasa SensorNodeUtil care este responsabilă

cu procesarea aportului JSON şi cu returnarea unei liste de SensorNode-s, fiecare dintre ele conţinând implementările adec-vate 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

fost să favorizăm o conexiune mai puternică între ingineri care lucrează în industria IoT , indiferent de ingredientele pe care le preferă. Dacă am realizat sau nu acest lucru prin prima versiune a cadrului (framework-ului), vom vedea în timp, dar considerăm că am făcut câţiva pași înainte. Odată cu evoluția comunității IoT, sperăm că Sensoriada va ajuta la construirea unei sinergii între dezvoltatori, care nu va mai lăsa loc pentru conflict, ci numai pentru armonie și discuţii constructive.

MobOS (Mobile Operating Systems)

Este prima comunitate mobile din Cluj. Ne-am început acti-vitatea î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.


programare

Analiza sentimentelor şi complexitatea

opiniilor online

Dacă 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ă presupu-nem 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

Sentiment Analysis sau Opinion Mining este o ramură a domeniului de Natural Language Processing (NLP) ce se ocupă cu studiul opiniilor, sentimen-telor, 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ă con-sistentă, 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, sociolo-gice, economice ș.a. și de popularitatea de care se bucură socializarea online în zilele noastre.

Enunțarea problemeiSă 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ă catego-rii, după cum am stabilit inițial: pozitiv (pro) și negativ (contra). Astfel putem enunța întrebarea: dacă ar exista o recen-zie negativă despre actorul principal și una

pozitivă despre regizor, ai mai viziona fil-mul? 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 docu-ment (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țiaExistă 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 ajuto-rul platformei NLTK (Natural Language Toolkit).

programare

Cosmin Gabriel [email protected]

SA R&D Osprov Team@ HP


TODAY SOFTWARE MAGAZINEprogramare programare

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

După cum se poate observa corpusul de „movie_reviews” conține recenzii de filme deja segregate în cele două categorii sta-bilite inițial. Din acestea vom extrage cuvinte drept informațiile de care vom depinde pe viitor.

{python code}positive_data = [movie_reviews.words(fileids=[f]) for f in positive_ids]negative_data = [movie_reviews.words(fileids=[f]) for f in negative_ids]{/python code}

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ă cuvin-tele 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.

{python code}import itertoolsfrom nltk import FreqDist, ConditionalFreqDistdef buildFreqDistribution(positiveWords, negative-Words): 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}

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}from nltk import BigramAssocMeasuresdef 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}

Se implementează și funcțiile care vor filtra informațiile rele-vante pentru antrenarea rețelei neuronale.

{python code}def getFeatures(label, data, best_words): features = [] for feat in data: words = [selectBestWords(feat, best_words), label] features.append(words)return features

def selectBestWords(words, best_words):

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{/python code}

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ă de NaiveBayesClassifier. Pentru simplitate vom reveni la plat-forma NTLK utilizând algoritmul său standard.

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

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

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)

negative_features = getFeatures(‚negative’, negative_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 deter-mina 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ă.

{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 for-gotten 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 cazUtilizând algoritmul SVM (Support Vector Machines) în

paralel cu algoritmul NaiveBayesClassifier și testând cei doi algo-ritmi pe o baza de date ajungând la peste 6 milioane de cuvinte, am obținut următoarele grafice. Odată cu creșterea numărului de entități extrase din text și folosit în antrenarea rețelelor neuronale, se pot observa diferențe de acuratețe generală și de clasificare.



testareprogramare

Se poate observa cum precizia algoritmului rămâne constantă și în creștere până la un punct de plafonare în jurul valorii apro-ximative 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.

ConcluziiSe pare ca nu e atât de simplu. Am fost păcăliți chiar de pro-

priul 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ă

diferite metode și diferiți algoritmi ce se pot folosi în Supervised sau Unsupervised Learning, dar soluția cea mai bună este combi-narea 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 opi-nii 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!

Analiza sentimentelor şi complexitatea opiniilor online


TODAY SOFTWARE MAGAZINEtestare

În luna noiembrie, 2014, o compa-nie 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 impor-tantă 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ân-direa. 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ă rezulta-tul 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ân-dire 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ă.

(De exemplu, pentru întrebarea: “Care este capitala Franței?,” nu trebuie să depunem efort suplimentar, deoarece facem aso-cierea 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 înde-lungată, 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, ana-liza, sintetiza și evalua, într-un mod activ și conștient, informațiile obținute sau generate din observație, experiență, meditație, comu-nicare ”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 ana-litică 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 com-pletată 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

Cinci 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

Gândirea critică în analiza de business

diverse

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



este descris de Daniel Kahneman în car-tea 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ăs-puns 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 împre-jurare. Aceasta abilitate este testată încă de la interviul pentru angajare. În cele mai multe cazuri, interviul presupune multe întrebări prin care reprezentantul anga-jatorului încearcă să determine o serie de calități necesare poziției de analist. Una din întrebările relevante pentru testa-rea 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 potri-vit sau eventual chiar să te ridici și să pleci de la interviu. Însă întrebarea este la fel de pertinentă ca oricare alta. Această între-bare 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ă mate-matică elaborată, însă necesită o analiză detaliată și formularea unui algoritm de determinare a numărului. În final, nu con-tează 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 inte-res. 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 capa-citatea 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 business gravitează în jurul procesului de colectare a cerințelor din partea clientului. Colectarea cerințelor solicită analistului concentrarea atenției pentru o perioada îndelungată pentru a înțelege nevoile reale ale clientului. Gândirea critică ajută analis-tul în a identifica dacă cerințele exprimate răspund nevoii reale ale clientului. În același timp, gândirea critică ajută analis-tul în identificarea posibilelor provocări de business care presupun o clarificare din partea clientului și nu pot fi soluționate printr-o aplicație. De exemplu, pentru o cerință care este formulată în felul urmă-tor: “Am nevoie de un raport care să îmi afișeze situația produselor vândute în fie-care lună”, un analist ar trebui să adreseze o serie de întrebări, cum ar fi:

• De ce ai nevoie de acest raport?• Pentru cine este folositor acest

raport?• Ce fel de informații trebuie să

interogăm?• Ce alte rapoarte avem deja imple-

mentate? Exista un raport care să afișeze deja această informație?

• Care va fi frecvența de utilizare a raportului?

Întrebările nu se rezumă doar la cele menționate mai sus. În scurt timp de la enunțarea cerinței este posibil să se ajungă la concluzia că raportul există deja ca parte din alt raport sau că frecvența de utilizare nu este mare astfel că prioritatea de imple-mentare nu este critică.

Cum putem să ne antrenăm gândirea critică?

Ca orice calitate, gândirea critică nu este ceva cu care ne naștem și din acest punct de vedere poate fi antrenată. Gândirea critică nu se dobândește printr-un efort de o zi sau o lună ci presupune o atenție sporită asupra modalității de gân-dire. Multe universități din lume pun mare accent pe gândirea critică și au incluse în 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ân-dirii critice. Acest ghid poate fi folosit cu succes de către oricine.

• Adresează multe întrebări: este cunoscut faptul ca un analist de business, trebuie să adreseze multe întrebări, dar aceasta nu înseamnă neapărat că orice întrebare este pertinentă. Întrebările „Cine?” „Ce?” “Unde?” „Când?” „De

ce?” „Cum?” Sunt întrebări de bază care oferă de obicei o imagine mai clară asu-pra unei cerințe.

• Gândește logic• A r g u m e n t e a z ă u n p u n c t

de vedere prin dezvoltarea unui raționament logic.

• Folosește argumente valide și de încredere.

• Evită folosirea emoțiilor în gândire.

• Fii obiectiv.• Fii deschis

• Elimină prejudecățile.• Fii deschis la idei noi.• Consideră toate perspectivele

înainte de a ajunge la o decizie finală.• Fii dispus să îți reanalizezi punc-

tele de vedere.• Fii echilibrat.

• Evaluează• Scop și motivație,• Interesul,• Faptele,• Opinii le celor implicați în

discuție,• Presupunerile,• Informați i le incorecte sau

incoerente,• Informațiile care lipsesc,• Inconsistența,• Argumentele,• Argumentele prezentate,• Contraargumentele.

Concluzie De ce este importantă gândirea critică

pentru un analist de business? Este o apti-tudine care asigură calitatea. Deși gândirea critică nu garantează cerințe precise și eli-minarea subiectivității se apropie foarte mult de acest lucru. În măsura în care cerințele sunt reale și precise șansele ca rezultatul proiectului să răspundă nevoilor reale ale clientului sunt foarte mari. Ideea esențială este de a investiga toate variantele pentru că rezultatul poate fi surprinzător.

diverseGândirea critică în analiza de business

Răzvan [email protected]

Business Analyst@ Endava



Î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 OptionalPe vremea lui Java 7, am fi scris ceva de genul:

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

Observaţie: Oracle Java 7 va avea sfârșitul actualizărilor publice în aprilie 20151.

Cu Optional, vei putea scrie în schimb:

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();

Dacă ai multe erori NullPointerException în proiectul tău, Optional s-ar putea să te ajute, dar altfel nu va fi de prea mult ajutor.

Un exemplu mai complexHaideţi să luăm în considerare acest exemplu:

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

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 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 ?

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

(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.}

Ceea ce obţinem este o serie de reprezentări și filtre care progre-sează doar dacă valoarea nu este null și prezentă. Dacă vreo valoare este nul sau un filtru nu este adevărat, întregul rezultat nu va fi disponibil.

ConcluzieFolosirea 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), iar în acest caz, evită toate verificările sau erorile ce pot apărea.

AdiţionalPentru interesul vostru, iată clasele pe care le-am utilizat în

exemplul anterior:

static class Nested { Contained first;}

static class Contained { IContained2 second;}

interface IContained2 {}

static class Contained2 implements IContained2 { List list;}

static class Data { String third;}

Java 8 Optional nu este doar pentru

înlocuirea unei valori null

programare

Peter [email protected]

CEO@ Higher Frequency Trading Ltd


Timpurile 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 ser-viciilor - 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 benefi-ciile lor și nu în ultimul rând, cât de mulți bani am putea obține înapoi dacă un ser-viciu cade.

Ce înseamnă un SLA? ”Un acord pentru calitatea serviciilor

(SLA) este un contract între un furnizor de servicii (fie intern sau extern) și utilizato-rul final care definește nivelul serviciului așteptat de la furnizorul de servicii. SLA-urile sunt bazate pe rezultat (output) deoarece scopul lor este să definească anume ceea ce clientul va primi. SLA-urile nu defi-nesc cum este oferit sau furnizat serviciul în sine.” 1

Un SLA este un contract între un fur-nizor 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? Î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.

Privind din nou la exemplul nostru cu serviciul de oră exactă, am putea avea un SLA care spune: ”Serviciul de oră exactă funcționează 99,99% din an, timpul de răs-puns din momentul în care o cerere ajunge la acest serviciu este de 0.0001 secunde și precizia este de 0.00000001 secunde.”

SLA-urile pentru Cloud În general, dacă vorbim de furnizorii

de servicii cloud și serviciile oferite de ei, aspectul acoperit de toți este durata de funcționare. Pe lângă durata de funcționare mai sunt și alte aspecte, dar acestea variază în funcție de tipul de serviciu.

Microsoft, Google și Amazon au un SLA clar care specifică durata de funcționare pentru fiecare serviciu care este furnizat de către ei. Chiar dacă sunt companii diferite, SLA-urile sunt foarte asemănătoare între ele.

De exemplu, dacă ne uităm la servici-ile de depozitare din cloud, care nu sunt replicate în centre de date sau noduri

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 exem-plul de mai sus, SLA-urile sunt aproape identice, cu diferențe de doar 0.05%.

Cum este măsurat serviciul? Această întrebare este foarte impor-

tantă, deoarece fiecare furnizor de servicii cloud specifică foarte clar în SLA cum, cine și când, în funcție de ce serviciu este măsurat.

În toate cazurile, durata de funcționare a serviciului este măsurată intern, de către sistemul lor propriu. Acest lucru nu înseamnă că măsurarea nu este reală.Ea este foarte reală, dar dacă motivul nefuncționării este un factor extern, cum ar fi probleme la rețea pe partea clientului, atunci nu mai este problema lor.

SLA-ul nu este aplicabil în cazurile în care serviciul este utilizat în afara anumi-tor limite specifice. De exemplu, SLA-ul se aplică numai când numărul de cereri pe secundă este sub 10 milioane, sau când există cel puțin două exemple de cerere pentru acea folosință.

GaranțieAdesea, oamenii presupun în mod ero-

nat că, dacă au un serviciu în cloud care generează 1000$ per oră, furnizorul le va

Aprofundare a SLA-urilor furnizorilor de servicii cloud

marketing legal


TODAY SOFTWARE MAGAZINElegal

asigura acea sumă de bani pe care serviciul ar fi generat-o, chiar și în condițiile unei perioade de nefuncționare. O altă presu-punere 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 cos-tul 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 ser-viciu 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 MicrosoftHaideți să aruncăm o privire asu-

pra 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

Google

Microsoft

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.

Când și cum primesc creditul?Toți furnizorii de cloud au mecanisme

diferite pentru a-și notifica clienții atunci când un serviciu nu funcționează conform așteptărilor (pe un web site, folosind un API sau prin email). În toate aceste cazuri, chiar dacă un serviciu este nefuncțional mai mult decât se specifică în SLA, clientul nu va primi din oficiu (by default) creditul despre care am discutat mai sus.

În momentul în care clienții sunt afectați de un incident, ei trebuie să înștiințeze furnizorul de cloud și să întoc-mească un aviz la nivelul de suport pentru clienți. Ei trebuie să specifice care anume serviciu a fost afectat și când. Pe baza acestor informații, furnizorul de cloud va verifica sistemul de audit intern și nivelul ratei de eroare în acel interval anumit de timp.

ÎncredereAcesta 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

în furnizorii noștri de cloud care își res-pectă 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.

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 servi-ciilor 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 funcționare a sistemului nostru ar putea ajunge la aproximativ 98%.

ConcluzieDupă cum am menționat mai sus,

SLA-urile oferite de diferiți furnizori de cloud sunt relativ asemănătoare. Cel mai important lucru este să știm exact ce anume acoperă SLA-ul și cum să gestio-năm perioadele de nefuncționare.

ReferințeAmazon EC2 SLA - aws.amazon.com/ec2/sla/ Google SLA - cloud.google.com/storage/sla Microsoft SLA - azure.microsoft.com/en-us/support/legal/sla/

Radu [email protected]

Senior Software Engineer@iQuest


Î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.

Faza 1 : MI este… NESEMNIFICATIV Există piețe și afaceri unde consu-

matorii 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

P r i nt r e c e i c a r e au a n a l i z a t 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.

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… BRANDINGCe 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 moti-varea și reținerea angajaților calificați’’.

Dezvoltarea Marketingului Intern (MI)

în România!

marketing legal

Adrian [email protected]

Senior partner & research director@ Loopaa


TODAY SOFTWARE MAGAZINElegal

Berry &Pasuraman (1991).Acțiunile specifice acestei faze sunt:• Conceptul de MI este un instrument

pe care companiile încep să îl folo-sească î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ă cre-ată 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 schim-bă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 pro-gramele de reconversie profesională sau universitățile private se străduie

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 lea-dership, 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, pen-tru 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ă impor-tantă în bugetul de personal al companiei. În această fază, înlăturarea unor percepții negative despre unele aspecte ale compa-niei 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 suc-ces maximă atunci când, de exemplu, se realizează prezentarea companiei unor potențiali angajați, se comunică intern diverse proceduri, se organizează eveni-mente 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 obiec-tivelor. 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 coordo-narea interfuncțională în departamente;

• Implementarea strategiilor de brand sau a celor operaționale;

• Valorizarea angajaților și integra-rea 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 per-sonale ale tuturor angajaților;

• Adoptarea unor noi canale de comunicare devine obligatorie pen-tru 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 com-petitiv. Trendurile de comunicare sunt importante. Sunt canalele tale de comu-nicare responsive pentru diversitatea display-urilor mobile? Folosești mate-riale video, animații în comunicarea cu angajații? Sunt afișele tale interne suficient de creative? Evenimentele interne sunt sur-prinzătoare? Sunt angajații tăi ambasadori ai strategiei companiei tale?


- 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 priete-nul 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 sfa-turi 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 tre-cut 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 zba-tere 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.

- Nu-i nimic, important e să-i dai posibilitatea de a compara avantaje și dezavantaje. În avans pe partea de dezvoltare, în întâr-ziere 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, vizi-bil, 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 evi-dent. 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?!

Gogu la mici

management

Simona Bonghez, [email protected]

Speaker, trainer și consultant în managementul proiectelor,

Owner al Colors in Projects

powered by

sponsori

today software magazine n32/2015

Documents