Numarul 36 - Iunie - Today Software Magazine

Nr. 36 • Iunie 2015 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

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

Download from

Windows Store

ix

ix Hystr Fault-Tolerant Microservices cu Netfl Arhitectura Conică

Aplicații IoT cu Java ME Embedded 8 Model Driven Design – de la teorie la practică Să batem palma asupra soluțiilor în proiectele software

Techsylvania 2015: despre Product Managerii din IT Cu un zâmbet nu se face primăvară știința fericirii în organizații

Minimum Delightful Product Interviu cu Rohan Chandran Unconference review: ITAKE Review JS Camp Ce este de fapt TDD? (II) Retrospectiva unui an alternativ la ACADEMY+PLUS Relaţiile la distanţă chiar pot funcţiona!

6 Minimum Delightful Product Interviu cu Rohan Chandran Ovidiu Mățan

8 Retrospectiva unui an la ACADEMY+PLUS Gloria Csiszer

10 Unconference: ITAKE Ovidiu Deac

12 JSCamp 2015 Alexandru Botez

14 Techsylvania 2015 despre Product Manageri-i din IT Călin Biriș

17 Arhitectura Conică Adrian Bontea

19 Să batem palma asupra soluțiilor în proiectele software Raluca Radu

21 Model Driven Design – de la teorie la practică Daniel Donea

26 Ce este de fapt TDD? (II) Alexandru Bolboacă

28 Fault-Tolerant Microservices cu Netflix Hystrix Radu Butnaru

32 Aplicații IoT cu Java ME Embedded 8 Dănuț Chindriș

35 Relaţiile la distanţă chiar pot funcţiona!

Florin Roman

37 Cu un zâmbet nu se face primăvarăștiința fericirii în organizații Szilárd Kacsó

editorial

N

Ovidiu Măţan

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

e pregătim de vacanțe și gândurile ne zboară spre țărmuri însorite sau spre munții cei umbroși. Vom ieși din iureșul cotidian și poate că momentele de relaxare ne vor oferi și ocazia unei perspective mai proaspete și mai noi asupra lucrurilor care ne înconjoară. Poate, avem șansa unor momente de inspirație, când ne surprindem că în jocul imaginației intră cele mai năstrușnice abstracțiuni și idei.

Pentru că oricât am încerca, nu ne putem elibera total de latura noastră profesională deși suntem în vacanță - aceste idei se pot materializa în proiecte originale de software sau hardware. De multe ori, credeți că aceste proiecte nu sunt realizabile imediat sau aveți îndoieli că pot fi puse în aplicare. De aceea, vă invit să le trimiteți la adresa idei@ todaysoftmag.com pentru a le discuta și analiza. Vom încerca chiar să punem bazele unui minicomunități care va fi formată din cei ce trimit astfel de idei sau proiecte.

Techsylvania 2015 care a avut loc la Cluj, a ajuns la a doua ediție. Felicităm organizatorii pentru progresul realizat față de conferința de anul trecut prin creșterea calității speakerilor, extinderea pe două zile a evenimentului și atragerea unui număr mult mai mare de participanți.

Cum sfârșitul lunii mai și începutul lunii iunie au fost pline de evenimente, în acest număr veți găsi o serie de review-uri ale acestora în titluri ca Unconference: ITAKE, JSCamp 2015,Techsylvania 2015 - despre Product Manageri-i din IT, Retrospectiva unui an la Academy Plus. Cu ocazia evenimentului Techsylvania 2015, am realizat un interviu interesant pe care îl găsiți în revistă cu titlul Techsylvania 2015: Minimum Delightful Product - Interviu cu Rohan Chandran. În ceea ce privește articolele tehnice, menționăm Arhitectura Conică, o alternativă la folosirea patternului Layers. Tot din zona arhitecturii software vă propunem Model Driven Design – de la teorie la practică. Din aria de programare am publicat în acest număr Fault-Tolerant Microservices cu Netflix Hystrix și un prim articol de IoT: Aplicații IoT cu Java ME Embedded 8. Vă lăsăm să descoperiți și restul articolelor din acest număr și vă doresc o lectură plăcută !!!

Ovidiu Măţan

Fondator al Today Software Magazine

4

nr. 36/2015 | www.todaysoftmag.ro

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

Lista autorilor Alexandru Bolboacă

Daniel Donea

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

Associate IT Consultant @ msg systems România

Adrian Bontea

Ovidiu Deac

Software Craftsman @ Yardi România

Independent Consultant & Functional Programming Advisor @ Ullink

Alexandru Botez

Raluca Radu

alex.bolboaca@mozaicworks.com

adrian.bontea@yardi.com

Traducător: Roxana Elena roxana.elena@todaysoftmag.com Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com

alexandru.botez@geminisols.ro Web Developer @ Gemini Solutions

Contabil : Delia Mircea delia.mircea@todaysoftmag.com Dănuț Chindriș

Junior Web Developer: Alexandru Diniș alexandru.dinis@todaysoftmag.com

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

daniel.donea@msg-systems.com

ovidiu@agile-bit.com

raluca.radu@betfair.com Product Owner @ Betfair

Szilárd Kacsó

kacso.szilard@happy-employees.eu CEO & Trainer @ Azimut Happy Employees

Tipar realizat de Daisler Print House Gloria Csiszer

Produs de

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

gloria.csiszer@pitechnologies.ro Marketing Specialist @ Pitech+Plus

Florin Roman

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

florin.roman@tss-yonder.com Delivery Manager @ Yonder

Radu Butnaru

rbutnaru@sdl.com Senior Developer @ SDL

Călin Biriș

calin.biris@loopaa.ro Digital Director @ Loopaa

ISSN 2284 – 6352 Ovidiu Măţan

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

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

www.todaysoftmag.ro | nr. 36/iunie, 2015

5

interviu

Minimum Delightful Product Interviu cu Rohan Chandran

A

m avut plăcerea de a realiza un interviu cu Rohan Chandran pe tema product management-ului la a doua ediție a evenimentului dedicat antreprenoriatului Techsylvania. Conceptul descris în prezentarea sa din cadrul evenimentului este Minimul Delightful Product, o modificare subtilă dar cu un mare impact a conceptului binecunoscut de Minimum Viable Product

Ovidiu Măţan

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

6

nr. 36/2015 | www.todaysoftmag.ro

[Ovidiu Mățan] Produsul Minim Încântător (Minimum Delightful Product) este o idee minunată pentru dezvoltarea noilor produse. Vă rugăm să descrieți această idee în câteva cuvinte pentru cititorii noștri care nu au putut participa la Techsylvania.

[Rohan C handran] Exp eriența Minimă Încântătoare este o evoluție a binecunoscutului concept de Produs Minim Viabil. De fapt, intențiile sunt exact aceleași. Totuși, eu cred că schimbarea a două cuvinte atrage după sine o schimbare radicală a modului în care îl abordăm, deoarece gândurile noastre și acțiunile sunt modelate de cuvintele pe care le folosim. Conceptele-cheie aici sunt: Scopul pentru care facem asta este să descoperim potrivirea Produs - Piață.

MySpace, Friendster, Orkut și alte rețele sociale, toate au găsit o potrivire problemă – soluție. Facebook a descoperit acordul produs – piață.

Voi construiți o Experiență, nu un Produs. Un Produs tinde să fie un set de funcționalități pe care le furnizați.

O experiență angajează și cuprinde o

Rohan Chandran Vice President and GM, Mobile Business Unit at Telenav

persoană. Ea spune o poveste și evocă anumite emoții. Atunci când vă conectați la acel nivel, oamenii vor răspunde la ceea ce le furnizați și de fapt vor deveni o parte a procesului de metamorfozare a sa în viziunea finală.

Voi aspirați la Încântare, nu doar Viabilitate. Atunci când o aveți pe cea din urmă, ați bifat o listă de funcționalități și îi

TODAY SOFTWARE MAGAZINE cereți utilizatorului vostru să valideze dacă acestea au fost bifate. Atunci când țintiți spre încântare, creați uimire, minunare, surpriză, acel sentiment de ”uau”! Vreți ca utilizatorul vostru să se simtă precum un copil atunci când descoperă ceva nou.

Lucrul cel mai dificil, cel mai critic este Minimul. Scopul vostru trebuie să fie acela de a crea cea mai mică experiență încântătoare autonomă, care să vă permită să validați potrivirea produs-piață prin testarea unor ipoteze specifice pe care le-ați stabilit. Orice este neesențial ar trebui lăsat la o parte, până când ați stabilit potrivirea produs – piață.

Să îți cunoști publicul pentru un startup este un lucru important. Cum ar trebui un startup să ia în considerare segmentarea publicului?

Am citit ceva acum vreo două zile – franceza mea nu este perfectă, dar se traducea aproximativ așa: ”Tu trebuie să ajungi la oamenii care contează, nu să îi numeri pe oamenii la care ajungi.” Aceste cuvinte sunt simple, dar profunde, atunci când ești la început. Noi toți tindem să vedem marile povești de succes, dar ignorăm cât de mult efort a fost depus pentru a se ajunge acolo. Josh Elman, odinioară de la Twitter, a explicat foarte bine cum Twitter și-a găsit calea spre creștere și succes în zilele sale de început. Cheia lor și pentru toată lumea, era să înțeleagă natura bazei lor de utilizatori care erau cu adevărat angajați, pentru a înțelege comportamentul lor și modul în care utilizau serviciul și să găsească o cale de a reproduce asta.

Atunci când pornești la început, prima provocare este să ai o țintă clară în minte. Ai putea să segmentezi după geografie (după cum a făcut Uber), sau după demografia de vreun fel, dar nu încercați să mulțumiți pe toată lumea. Rețineți că aceasta nu înseamnă întotdeauna că oamenii din afara segmentului vostru nu

pot participa, dar ei nu sunt ceea ce voi v-ați stabilit drept țintă în mod explicit.

De acolo mai departe, este o chestiune de observare a datelor și de înțelegere a angajamentului. S-ar putea să fiți surprinși – voi credeați că vindeți flori soților aventurieri care au nevoie de un buchet în ultimul moment, dar cel mai bun public al vostru s-ar putea să fie format din fiice care trimit flori mamelor lor.

Care ar fi minimul pentru un serviciu online nou care vinde ceva / flori? Ar trebui să încerce monetizarea din Ziua 1?

Dacă vindeți ceva, atunci, absolut, Experiența Minimă Încântătoare a voastră trebuie să includă componenta de monetizare – la urma urmelor, aceasta este baza afacerii voastre. Ceea ce veți dori probabil să faceți aici, este să vă concentrați pe o geografie îngustă, cu poate un singur tip de floare sau aranjament. Voi nu încercați să verificați dacă oamenii preferă trandafirii sau lalelele – voi încercați să validați faptul că ei doresc într-adevăr să utilizeze serviciul vostru, așa cum l-ați înființat. Ați făcut să fie simplu și încântător pentru ei să comande de la voi și le puteți onora comenzile? Dacă ați reușit asta, să adăugați flori diferite, zone geografice diferite și așa mai departe, este partea cea ușoară.

Cum vedeți Managementul Produsului (Product Management) într-o lume Agile?

Cum funcționează cu ciclurile de dezvoltare și design?

Arta și știința Managementului Produsului evoluează. Scopul unui manager de produs într-o lume agile este similar cu scopul unui fondator / CEO de startup.

Acela de a defini contextul pentru echipă – ce încercăm noi să obținem și cum vom măsura succesul; să stabilească prioritățile fără cruțare – să definească ce este MDE (experiența încântătoare minimă) și cum vom reitera de acolo; să permită și să faciliteze orice este necesar pentru a ajuta toți membrii echipei să livreze – ceea ce înseamnă să fie atât un om care se pricepe la toate, cât și un conducător pentru ceilalți.

Ceva ponturi pentru conceperea unui produs încântător?

Nu există o formulă magică, dar mai presus de toate aș încuraja oamenii să se concentreze pe minim, deoarece, dacă îl poți supune pe acesta unor condiții, deja te afli la jumătatea drumului înspre o experiență încântătoare. Este cel mai dificil, și de aceea, cel mai important lucru de făcut. Aceasta, deoarece există întotdeauna mai multe funcționalități mici și idei care îți imaginezi că vor face produsul tău mai bun. Dincolo de asta, este esențial să fii cu adevărat deschis și să nu fii atașat de ideile tale și apoi să pui utilizatorii să se uite la experiența pe care le-o oferi de timpuriu.

Mergi în cafenele, în stații de autobuz sau gări și cere oamenilor feedback. Privește limbajul lor corporal și învață să citești printre rânduri și vei afla foarte repede dacă i-ai încântat sau nu.

www.todaysoftmag.ro | nr. 36/iunie, 2015

7

educație

Retrospectiva unui an la ACADEMY+PLUS

A

CADEMY+PLUS se îndreaptă spre a doua generație de studenți. S-a încheiat un an plin de activități care a crescut atât noi talente cât și încrederea celor din jur pentru un astfel de proiect.

Gloria Csiszer

gloria.csiszer@pitechnologies.ro Marketing Specialist @ Pitech+Plus

8

nr. 36/2015 | www.todaysoftmag.ro

Această metodă revoluționară de învățare și formare profesională în domeniul IT, bazată pe o programă actualizată cerințelor pieței a fost lansată anul trecut în Cluj-Napoca de compania PITECH+PLUS, după semnarea unui parteneriat cu Ecole 42 din Paris. Principalul obiectiv al acestei forme de învățare alternativă este de a descoperi minți strălucite, care pot crea produsele informatice de mâine.

la evenimente conexe și la concursuri în cadrul 3 Day Start-Up, Start-up Weekend, Hackathon la Techsylvania și Open Data Hackathon, unde cinci dintre ei au câștigat premiul Best Hack cu aplicația I need medication.

De-a lungul acestui prim an, stafful s-a concentrat și pe următoarele generații. La sediul academiei se organizează regulat Coder Dojo pentru copiii de gimnaziu, iar în mai a avut loc prima ediție a campionatului Game of Codes, organizat pentru Programă întregită de activități extra liceeni din diverse orașe, unde timp de 12 După selecția riguroasă, studenților ore aceștia au codat jocuri după reguli și acceptați li s-a pus la dispoziție o plat- cerințe. În toamnă urmează să se organiformă care i-a trecut în doar câteva luni zeze a doua ediție. prin diverse limbaje de programare precum: C, UNIX, PHP și JavaScript. Pe lângă m at e r i a e f e c t i v ă , aceștia au învățat să lucreze pe proiecte ca și la un loc de muncă, având task-uri individuale dar și proiecte de echipă. Studenții și-au descoperit și d e z volt at d ive rs e skill-uri participând

programare

Un ajutor pentru piața de IT Unul dintre obiectivele pe termen lung al ACADEMY+PLUS este să ridice gradul de colaborare între companiile care caută tineri talentați, devenind în timp o sursă de forță de muncă performantă și capabilă care va rezolva această nevoie pe piața de IT. Perioada de vară din fiecare an este dedicată stagiilor obligatorii de practică pentru studenții academiei. Atât PITECH+PLUS, cât și alte companii din Cluj i-au recrutat deja, fie pentru traininguri, ori pe posturi de juniori.

Dive into the pool Lunile iulie, august și septembrie sunt un nou început pentru toți cei care doresc să beneficieze de acest sistem de educație revoluționar și gratuit. În fiecare dintre aceste luni peste 120 de studenți vor petrece zile intense experimentând “piscine”, etapa de selecție în care trebuie să predea zilnic proiecte individuale sau să lucreze împreună cu o echipă la proiecte mai ample. Aceștia vor rezolva practic aceleași cerințe pe care le au și colegii lor din Franța, care s-au înscris la Ecole 42.

TODAY SOFTWARE MAGAZINE

Această etapă este echivalentă cu parcur- din iulie fiind deja ocupată. Cei interesați gerea materiei din cei patru ani de liceu la pot accesa testele de memorie și logică pe un profil de mate-info. Un exemplu fericit candidates.academyplus.ro. din etapa de piscină de anul trecut a fost un student care nu a avut nici un background în informatică și în urma parcurgerii acestor exerciții practice a trecut mai apoi de testul de angajare al unei firme de IT.

Next level: gamification Background-ul divers al comunității formate la etajul trei al sediului academei va fi și mai mult sprijinit din acest an datorită schimbării platformei de învățare de către cei de la Ecole 42, care s-au bazat pe ideea de gamification. Astfel, au fost customizate modulele de formare prin intermediul cărora să crească gradul de flexibilitate și personalizare în conformitate cu pregătirea individuală a fiecărui candidat. Cei cu un nivel mai ridicat pot opta pentru un anumit mix de formare, trecând peste unele nivele. Cu cât vor lucra mai repede și mai bine, vor putea deschide noi proiecte și provocări.

Pentru piscinele din august și septembrie mai sunt câteva locuri disponibile, cea

www.todaysoftmag.ro | nr. 36/iunie, 2015

9

eveniment

Unconference: ITAKE

A

m primit săptămânile trecute de la Today Software Magazine invitația de a participa, la I.T.A.K.E. Așteptam acest eveniment încă din toamnă, de când am discutat la IT Days cu Alex Bolboacă despre conceptul “unconference”, concept care mi s-a părut foarte interesant. Recunosc că am avut o mică reținere având în vedere faptul că se anunța o conferință de “Software craftmanship”, curent cu care nu prea rezonez. Totuși, în program erau și câteva prezentări legate de programarea funcțională și speram să cunosc mai mulți oameni interesați de acest subiect. De aceea, nu am stat pe gânduri și am acceptat imediat.

Locația a fost foarte bună: ultracentral, pentru pretențioși. Conferința s-a desfășurat pe mai multe fire, ceea ce m-a ajutat să mă eschivez de la subiectele care nu mi s-au părut interesante. Dintre “keynote speakers” mi-a plăcut doar Andrea Mocci, care a avut o prezentare despre vizualizarea codului și a felului în care lucrează programatorii. James Lewis și Simon Brown au abordat generalități.

Spre dezamăgirea mea, James Lewis a vorbit despre microservices ca și când ar fi o idee nouă, fără să facă deloc trimitere la sisteme ca Erlang, în care de treizeci de ani se dezvoltă arhitecturi asemănătoare și din

care un programator care scrie microservices ar putea aduna înțelepciune cu sacul.

Cât despre restul prezentărilor, am participat aproape în exclusivitate la cele din aria “hardcore programming”, însă nu am simțit că merita bătut atâta drum.

Repet, nu am participat la celelalte fire ale conferinței. Faptul că s-au desfășurat mai multe prezentări în paralel, a reprezentat un dezavantaj. Se poate să nu îmi fi ales bine prezentările, dar nu am fost impresionat. Cu mici excepții, au cam lipsit momentele “aha!”, momente în care să remarc o idee nouă pe care vorbitorul mi-a transmis-o. Asta nu înseamnă că neglijez

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

10

nr. 36/iunie, 2015 | www.todaysoftmag.ro

munca depusă de prezentatori și nu le apreciez efortul, ci doar că mă așteptam la un alt nivel.

O e xc e pț i e a fo st pre z e nt are a “Monoids. Monoids Everywhere!”, a lui Cyrille Martraire, care ne-a vorbit despre felul în care, în aplicații reale, am putea profita de compozabilitatea oferită de monoizi. A descris în câteva slide-uri monoidul, așa cum e definit în teoria categoriilor și apoi a arătat cum se aplică la codul real, cu care se luptă majoritatea dintre noi. Tema s-a aflat la intersecția dintre DDD și programare funcțională. Nivelul a fost introductiv, fără pretenții prea mari de

la ascultători. S-a pus o problemă interesantă: dacă încercăm să alegem modelele astfel încât să fie monoizi, rezultatul este mai elegant, mai compozabil și mai ușor de folosit. E nevoie de mai multe prezentări de genul acesta, care să scape programarea funcțională de aerul academic pe care îl are în prezent și să ne arate cum am putea profita de tehnicile ei în situații întâlnite de “programatori normali”.

Partea cea mai interesantă al evenimentului a fost, de departe, componenta open space. În ambele zile, a doua jumătate a fost rezervată pentru “open space”. Rețeta e relativ simplă: • Se împarte spațiul existent în N zone de discuții.

• Se împarte timpul în M perioade de câte 30-45min.

• Se face un tabel N * M, “the marketplace” care conține zonele și orele la care acestea sunt libere.

• Se explică regulile jocului în fața participanților: orice se poate alătura oricărei discuții și poate pleca dintr-o discuție atunci când dorește.

• Se completează tabelul cu propunerile de subiecte.

• Fiecare dintre cei care au venit cu propuneri fac o introducere prin care să atragă participanți la discuția respectivă.

• Se dă startul. În 15 minute două treimi dintre cele

42 de slot-uri disponibile pentru ambele după-amieze au fost ocupate. Restul s-a ocupat ulterior. Tabelul s-a umplut cu stickere colorate cu subiecte foarte variate cum ar fi DDD, microservices, Clojure, big data, vim, coaching, programare funcțională, testare, continuous delivery, Scala etc. . O bună parte din merit îi revine moderatorului Mike Sutton, care a reușit să îi mobilizeze pe participanți să vină cu subiecte de discuție.

Definiția pe care o dă Alex Bolboaca open-space-ului și anume “o conferință care constă doar din pauze de cafea” e foarte reușită. Exact asta s-a întâmplat: oameni implicați, discuții aprinse, schimburi de contacte. Au lipsit cu desăvârșire dormitul în banca din spate, cititul mailurilor sau jucatul pe telefon în așteptarea pauzei de țigară. Când informația primită nu justifica timpul consumat, pur și simplu te ridicai și plecai în altă zonă de discuții.

Cei care erau prea obosiți își căutau o canapea sau stăteau la o cafea unde, bineînțeles, pornea o altă discuție ad-hoc. Pe scurt: a fost o experiență excelentă.

Referitor la calitatea prezentărilor din cadrul open-space, unele au fost mai bune, altele mai puțin bune, dar asta e mai puțin important. Important e faptul că discuțiile pornite în jurul subiectelor respective au fost reușite și că lumea a participat activ.

Impresia mea a fost că majoritatea nu a venit cu materiale pregătite. Au desenat la fata locului și au improvizat pe loc. Nu toate discuțiile au fost purtate într-un mod profesionist, nu toți știut să vorbească în public. Dar, din nou, asta nu contează.

Contează faptul că și-au făcut curaj și s-au implicat masiv, lucru care a făcut evenimentul reușit. În concluzie, trebuie să îi felicit pe cei de la Mozaic Works pentru organizare

și, în primul rând, pentru formatul ales.

Fără discuție, a fost un eveniment la care a meritat să merg. Sper că în edițiile viitoare partea open-space va ocupa majoritatea timpului. Eu unul voi încerca să aplic formatul acesta la viitoarele întâlniri ale comunității de programare funcțională.

De asemenea, sper ca organizatorii evenimentelor de IT din Cluj și nu numai, să înțeleagă valoarea unui astfel de format și să avem cât de curând și un unconference local.

Ovidiu Deac

ovidiu@agile-bit.com Independent Consultant & Functional Programming Advisor @ Ullink

www.todaysoftmag.ro | nr. 36/iunie, 2015

11

eveniment

JSCamp 2015

C

ea de-a doua ediție a JSCamp, o conferință JavaScript pentru România și Europa de Est, a avut loc pe data de 2 iunie, în București, la Radisson Blu Hotel.

Evenimentul a fost organizat pentru dezvoltatorii front-end, inginerii și designerii web care au dorit să afle mai multe despre aspecte avansate ale limbajului JavaScript sau să audă despre experiențele unor oameni importanți din industria web. Conferința a fost împărțită în patru sesiuni (câte două discursuri per sesiune), cu subiecte variate care au inclus proiectele open-source, standarde de codare, testarea, experiențele, redarea grafică și chiar web audio. Între sesiuni, au existat pauze de cafea și prânz, în care participanții s-au putut întâlni cu vorbitorii și alți entuziaști JavaScript.

Ziua a început cu Kenneth Auchenberg, directorul tehnic al GoToMeeting Free at Citrix , care a inițiat proiectul RemoteDebug pentru a unifica depanarea la distanță. Prezentarea sa, denumită ”Viitorul instrumentelor DevTools cu RemoteDebug”, a avut ca subiect puterea depanării la distanță, cross-browser-ul DevTools și de ce este nevoie de o interfață comună pentru browser-ele noastre. El consideră că, pentru ca dezvoltatorii să fie mai productivi, este mai întâi nevoie să ne regândim instrumentele de lucru.

A fost urmat de către Sebastiano Armeli, inginer software la Spotify.

12

Acesta a dezvoltat și conceput aplicații utilizând JavaScript, Java, Ruby, dar este foarte pasionat de JavaScript și dezvoltarea web. El este autorul cărții electronice ”MVC se aplică la JavaScript” și al unui jQuery plug-in pentru imagini care se încarcă leneș, numit JAIL. Discursul său, ”Aplicarea standardelor de codare”, a încercat să convingă participanții în legătură cu importanța standardelor de codare și le-a spus ce fel de standarde folosesc la Spotify pentru a le ușura traiul.

Câteva dintre instrumentele și standardele utilizate de Spotify sunt EditorConfig, JSCS, AngularJS style commits, Gulp, Plato, QuickStart, etc. .

După o scurtă pauză de cafea, a doua sesiune a început cu Krasimir Tsonev, un dezvoltator front-end, blogger și orator. El a scris ”Node.js.blueprints” și în prezent lucrează pentru TrialReach, un startup în domeniul sănătății, cu sediul în Londra.

Prezentarea sa a avut titlul ”Meșteșugul

nr. 36/iunie, 2015 | www.todaysoftmag.ro

testării client-side” și a argumentat importanța testelor, deoarece acestea ne permit să extindem și să reutilizăm codul nostru cu ușurință. El consideră că scrierea de teste face ca dezvoltarea software să fie mult mai interesantă și duce la un cod mai bun.

A urmat Felix Palmer. El a intrat in lumea software prin scrierea de jocuri în Flash, are pregătire în fizică și îi face plăcere să combine vizualul cu tehnicul. În prezentarea sa, ”Cum să dezvolți PhotoShop – WebGL nu numai pentru 3D”, el a explicat principiile de bază ale WebGL și a codat în direct câteva tehnici de editare de imagini precum: scalarea,

TODAY SOFTWARE MAGAZINE

decodificarea, rotirea, trucuri simple cu culori, amestecarea, deformarea și efecte pixeli.

După pauza de prânz, Sebastian Cevey, inginer software la The Guardian, a deschis sesiunea a treia. În prezent, el este dezvoltatorul principal al Composer, noul digital-first CMS. Prezentarea sa s-a intitulat ”Bucla reactivă” și el a vorbit despre Virtual DOMs, MVC, data-binding și avantajele utilizării React/Flux.

Cea de-a treia sesiune a fost încheiată de Remy Sharp, favoritul publicului, dacă considerăm aplauzele. El este fondatorul Full Frontal, conferința JavaScipt cu baza în Marea Britanie. Își conduce propria companie de dezvoltare și training, numită Left Logic. De asemenea a construit : jsbin. com, html5demos.com, remote-tilt.com și multe altele. În ”Biții din spatele JS Bin”, el a spus povestea din spatele JS Bin: cum a fost original construit în patru ore, de ce s-a mutat la Node și câteva dintre provocările care apar când rulezi aplicația.

După o altă pauză scurtă de cafea, ultima sesiune a început cu Charlie Robbins, fondator și CEO al Nodejitsu.

El este un pasionat de open-source, autor al multor module Node.js populare, cum ar fi forever, winston, nconf sau node-httpproxy. În prezentarea sa ”Cum să păstrezi

viu codul important”, printre numeroase referințe la Star Wars și ticuri americane, el a vorbit despre experiența sa în construirea proiectelor open-source. Având peste 10 milioane download-uri/lună, el ne-a împărtășit că este înfricoșător să primești atât de multă atenție și că are parte, de asemenea, de mult abuz și negativitate din partea utilizatorilor. Un alt lucru pe care l-a subliniat a fost acela că, atunci când un proiect devine atât de mare, autorul devine într-un fel managerul și are nevoie de ajutorul unei echipe.

Ziua a fost încheiată de Jan Krutisch, un dezvoltator web liber-profesionist și autor al liv3c0der. Discursul său a fost intitulat ”Tipare JavaScript pentru muzica de dans contemporană” și, cu ajutorul câtorva ritmuri plăcute folosind Web Audio API, el a demonstrat că muzica poate fi codată în direct într-un browser, utilizând JavaScript.

Personal, eu am găsit conferința foarte interesantă. Speakerii și participanții au fost foarte prietenoși și vorbăreți, iar locația a fost, de asemenea, frumoasă și primitoare. De abia aștept următoarea ediție, la care cu siguranță voi participa din nou!

Alexandru Botez

alexandru.botez@geminisols.ro Web Developer @ Gemini Solutions

Our core competencies include:

Product Strategy

Product Development

Product Support

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

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

www.3pillarglobal.com

www.todaysoftmag.ro | nr. 36/iunie, 2015

13

eveniment

Techsylvania 2015 despre Product Manageri-i din IT

C

ând am ajuns la Techsylvania la Casa de Cultură a Studenților, lumea era încă în pauză între paneluri, deși întârziasem puțin. M-am întâlnit cu câțiva colegi din online și am schimbat două vorbe despre eveniment. Aceștia au apreciat mult calitatea conținutului pe care l-au primit în cele două zile și mi-au spus că le-au fost depășite așteptările.

Călin Biriș

calin.biris@loopaa.ro Digital Director @ Loopaa

M-am grăbit să nu ratez panelul.

Pe scenă au intrat: • Christopher Osborne (Booking. com) – Moderator, • Felix Petersen (Amen), • Edin Memisevic (FoodPanda / Rocket Internet), • Gabriel Radic (EatFirst / Rocket Internet), • Rohan Chandran (Telenav).

Speakerii au început să discute despre rolul și calitățile unui Product Manager de succes într-o companie de IT. Mai jos am reprodus dintre răspunsurile lor interesante:

nouă); • în cadrul unei organizații mari, un Product Manager trebuie să construiască inerție și forță gravitațională în jurul ideii pe care dorește să o dezvolte.

Pot să facă acest lucru prin testarea ipotezelor și proiectelor într-o fază incipientă, încercând să obțină feedback bun din rândul potențialilor clienți; • un product manager este “traducător” între CEO și membrii echipei.

Practic trebuie să comunice dorințele ambelor părți pe limba fiecăruia, dândule o formă care să motiveze ambele părți să se implice.

2. Care sunt calitățile unui Product 1. Ce este un Product Manager și ce face Manager? el de fapt?

• acesta trebuie să-și dea seama de La ce ar trebui să ne uităm când angajăm un regulile jocului și să conștientizeze Product Manager? importanța câștigului; • este o persoană plină de resurse; • acesta este un om de vânzări care • are convingeri puternice, pentru a trebuie să-și vândă proiectele atât intern susține lucrurile în care crede, însă în către membri echipei cât și către celelalte același timp, în contradictoriu, este lippărți interesate; sit de ego și nu dorește recunoaștere. Eu • Product Manageri-i stabiliesc o aș fi formulat altfel acest punct. Cred că ierarhie a priorităților și trebuie să ia un Product Manager trebuie să fie un deciziile cu privire la ce să dezvolte om bun de vânzări, să știe să cumunice și când să dezvolte (o funcționalitate cu încredere o idee, dar să fie dispus să

14

nr. 36/2015 | www.todaysoftmag.ro

negocieze și să accepte opinii diferite; • este important ca un Product • este un bun psiholog, capabil să Manager să creeze un cadru favorabil înțeleagă comportamentul uman al luării deciziilor în echipă și colaborării colegilor de echipă cât și al clienților; între membri; • nu îi este frică să greșească. Un Product Manager bun își asumă acest 2. Cum lucrezi cu o echipă remote? risc, învață din greșeli și este pregătit să • echipă cu membri la distanță poate reînceapă mereu de la capăt; funcționa bine la nivel execuțional, cu • are aptitudini tehnice sau cel puțin condiția ca să li se precizeze fiecăruia le înțelege; în mod clar ce să facă; • este o persoană cu care îți face plă• nu funcționează/nu este recomancere să porți o conversație; dată această metodă de lucru pentru • are proiecte de succes anterioare; startup-uri sau unde este nevoie de • nu uită puterea clienților în validarea decizii rapide; ideilor și proiectelor noi. Testează mereu • modalitatea bună de a construi ipotezele; echipe la distanță care să lucreze bine • se raportează mereu la date. împreună este să le oferi ocazia să se cunoască de la început și în persoană, Întrebări din public: față în față; • la final, se specifică faptul că soluția 1. Cum trebuie un Product Manager să ofere poate fi găsită în cartea ReWork1.

Speakerii au vorbit din experiență și s-a văzut acest lucru. Am simțit dorința să mai rămân la eveniment, însă n-am reușit să fac acest lucru. Mă bucură că avem pe scena evenimentelor din Cluj nume din ce în ce mai importante. Oare cine va veni la ediția următoare Techsylvania?

feedback?

• un Product Manager nu oferă nicioTimpul a zburat. Nu mi-a venit să cred dată feedback personal. El nu este șeful cât de repede a trecut. Mi-a plăcut panelul. și nu face evaluări anuale de personal.

1 h t t p : / / w w w. e m a g . r o / r e w o r k - j a s o n - f r i e d Rolul lui este să evalueze situații, speci- d av id-heinemeier-hanss on-pub978-973-1931-77-7/p d/ ficând ce funcționează și ce nu, oferind EYB260BBM/?ref=ps&emag_click_id=d7e084bdad01994d97e0b1 condițiile soluției în echipă; 0cc7d62e3a

www.todaysoftmag.ro | nr. 36/iunie, 2015

15

comunități

Comunităţi IT

P

rincipalele evenimente din lunile următoare sunt din zona de Meetup-uri. Deși sunt restrânse, creează premisele unei mai bune comunicări cu reprezentanții comunității locale. Remarcăm o creștere binevenită a evenimentelor ce au ca tema principală Java Script. Vă invităm să participați și să vă alăturați comunităților locale.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

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

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

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

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

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

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

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

16

nr. 36/iunie, 2015 | www.todaysoftmag.ro

Calendar Iunie 18 (Cluj) Lansarea numărului 36 al Today Software Magazine www.todaysoftmag.ro Iunie 22 (Cluj) JavaScript Cluj Meetup #3 – Typescript for the programmers who like Javascript meetup.com/JavaScript-Cluj/events/222153313/ Iunie 23 (Cluj) Security Cluj Community Launch meetup.com/Security-Cluj-Meetup/events/222809785/ Iunie 24 (București) June BucharestJS Meetup meetup.com/BucharestJS/events/222955233/ Iunie 25 (Timișoara) TdT #33 - Risk Based Testing with Ladislau Szilagyi m e e t u p . c o m / Ta b a r a - d e - Te s t a r e - T i m i s o a r a / events/222661575/ Iunie 27 (Cluj) Youth Innovation Week in Cluj-Napoca eventbrite.com/e/youth-innovation-week-in-cluj-napocatickets-17350442641 Iunie 30 (Cluj) România digitală ccifer.ro/ro/ Iulie 7 (Cluj) Top Notch Server-side Javascript meetup.com/Cluj-JS/events/222611466/ Iulie 16 (București) Bucharest Mobile Development Group meetup.com/Bucharest-Mobile-Development-Meetup/ events/222785583/ Iulie 21 (Brașov) F.7 - The memorable experience - experience design and gamification meetup.com/bv-tech/events/219375720/

arhitectură

Arhitectura Conică

U

niversul este construit pe baza unui plan a cărui simetrie profundă este prezentă în structura interioară a intelectului uman. – Paul Valery Arhitectura Clean este extraordinară! Arhitectura Clean este frumoasă!

Arhitectura Clean este simetrică! Arhitectura Clean este naturală! Arhitectura Clean ar trebui pur și simplu să fie firească!

Adrian Bontea

adrian.bontea@yardi.com Software Craftsman @ Yardi România

Arhitectura Clean este structura care rezultă într-un mod natural în momentul în care se aplică DIP: “High level modules should not depend on low level modules. Both should depend on abstractions” Modulele “high level” reprezintă partea cea mai importantă din implementarea unei aplicații; reflectă politicile din implementarea aplicației, abstracțiile generale care guvernează întreaga aplicație; reprezintă conceptele care nu variază când detaliile se schimbă.

Prin opoziție, modulele “low level” se referă la partea de detalii. Acestea sunt mecanismele tehnice generice care susțin modulele “high level”: logging, OOM, ORM, e-mail, sms…

destul de nefericite.

De zeci de ani folosim Layers pentru a structura diverse aplicații. La fel, de zeci de ani, Layers a fost sinonim cu o structura de calitate – sau aveai Layers, sau aveai BBOM (Big Ball of Mud anti-pattern).

De zeci de ani pretindem că folosim și aplicăm SOLID, dar de fapt nu o facem. În cel mai bun caz, putem afirma că am aplicat SOLI. Cel puțin în lumea .NET, Layers încalcă DIP prin impunerea unei referințe de la assembly-urile high level către cele low level care fac parte din layer-ul de Infrastructură:

Ce este diferit la Clean Architecture?

Ce nu este în regulă cu Layers?

În linii mari, Clean Architecture respecta DIP, pe când Layers nu face acest lucru.

Clean concentrează cea mai importantă parte a implementării în partea centrală, Patternul traditional Layers încalcă DIP externalizând toate detaliile. și, din cauza aceasta, implică niște consecințe Principiul care face ca acest model să www.todaysoftmag.ro | nr. 36/iunie, 2015

17

arhitectură Arhitectura Conică funcționeze este numit regula dependenței: “Dependentele în mod mult mai natural când folosim Clean Architecture. Este cod pot să fie orientate doar spre interior”. Aceasta este de fapt o chiar modelul mental impus de cercurile concentrice care te ajută definiție mult mai pragmatică a DIP. să vezi pădurea, în ciuda copacilor.

Este vorba numai despre regula dependenței?

Explicarea titlului

Dacă vă imaginați un model asimetric ce derivă din structura După părerea mea, Cone Architecture este doar o metaforă Layers clasică, dar care se conformează DIP, acesta ar arăta cam mai expresivă pentru acest tip de structura software. Da, eu am așa: inventat termenul ăsta.

Este vorba despre două perspective diferite: dacă te uiți de sus, vei vedea niște cercuri concentrice guvernate de regula dependenței, care afirmă că dependențele în cod pot fi orientate doar spre interior. Acesta este un punct de vedere strict tehnic.

Dar dacă privești structura dintr-o parte, poți să vezi foarte clar ce vrea să spună DIP prin module “high level” și module “low level”. Poți acum să faci deduci mult mai ușor ierarhia straturilor după nivelul lor de abstracție. Cercurile interioare sunt de nivel mai înalt decât cele exterioare.

Săgețile reprezintă dependințe în cod.

Faptul că reprezentarea Clean Architecture este simetrică, folosind cercuri concentrice, nu este o coincidență. Poate nu este foarte evident, dar această reprezentare ascunde un principiu foarte puternic: toate detaliile sunt doar detalii!

Clean Architecture se concentrează pe cea mai importantă parte a implementării unei aplicații. Acesta este centrul aplicației și acesta este aspectul la care s-a referit DIP sub numele de “high level modules” timp de peste 10 ani. Din punctul de vedere al centrului aplicației, framework-ul de livrare nu este cu nimic mai special decât baza de date sau framework-ul de logare.

Acesta este motivul pentru care Clean Architecture îndreaptă procesul de dezvoltare spre o abordare de tip “domain-out” și pentru care reprezintă un mediu mult mai confortabil și mai natural pentru Domain Driven Design. Acesta este și motivul pentru care întârzierea deciziilor legate de tehnologii vine în

18

nr. 36/iunie, 2015 | www.todaysoftmag.ro

management

Să batem palma asupra soluțiilor în proiectele software

Î

Raluca Radu

raluca.radu@betfair.com Product Owner @ Betfair

ntr-o lume dinamică, în care obiectivele de business se schimbă în funcție de tendințele din domeniu și de mereu fluctuantul interes al consumatorilor, înțelegerea cerințelor de către cei ce le formulează și de către cei care le implementează reprezintă cheia succesului în proiectele de dezvoltare a produselor software. Neînțelegerea, proasta interpretare a cerințelor, implementarea defectuoasă care generează deraierea proiectelor, costuri suplimentare și defecte descoperite prea târziu, au ca rezultat un produs implementat care nu folosește nevoii din care s-a născut. Există prea multe cazuri de funcționalități costisitoare neutilizabile sau care nu-și justifică costul.

Ca o soluție la problema neînțelegerii sau a slabei comunicări a cerințelor de produs, metoda “shake hands” aduce nu un răspuns definitiv ci o cale spre continua îmbunătățire a formulării și comunicării cerințelor și a oferiri soluțiilor viabile pentru a îndeplini aceste cerințe. Avem și alți termeni care să descrie această metodă precum “signing-off ”, “handing-over” sau validarea cerințelor/soluției.

Mulți dintre noi fac asta implicit la fiecare discuție cu stakeholder-ii, însă devine evident în proiectele de mare amploare și cu o mai mare importanță pentru business că aceste metode sunt imperative pentru a beneficia de soluții eficiente. Mai pe scurt devine esențială ajungerea la un acord asupra soluțiilor propuse între cei ce formulează cerințele și cei care le îndeplinesc.

Pentru facilitarea implementării soluției expuse mai sus există mai multe artefacte ce ne oferă suport cum ar fi: “proof of concept”, “prototyping and design”, documente care descriu de exemplu un API (ApplicationPrograming Interface), modele UML a interacțiunilor dintre sisteme, diagrame arhitecturale, etc. . Voi descrie mai jos câteva dintre aceste artefacte folosite și în

proiectele la care am avut norocul să lucrez.

Voi insista asupra beneficiilor comunicării între cei ce formulează cerințele (clienți, stakeholder, product manager-i, product owner-i, business analiști, etc.) și cei ce le implementează (arhitecți, tech leads, delivery manageri, echipe de implementare, echipe SCRUM, etc.).

POC sau Proof of concept reprezintă o demonstrație cu scopul de a verifica faptul că anumite concepte sau teorii au potențial pentru aplicabilitate în lumea reală. O altă terminologie folosită este aceea de “proof of principle”. POC în dezvoltarea de produse software descrie procese distincte cu diferite obiective și diferiți participanți; poate, de asemenea, să ofere soluții parțiale implicând un număr mai mic de utilizatori acționând în roluri de business pentru a stabili dacă un sistem satisface anumite cerințe de produs.

Astfel obiectivul principal al POC-ului este de a găsi soluții la probleme tehnice, cum ar fi modul în care sistemele pot fi integrate sau cum ar fi obținerea de datele printr-o anumită configurare.

Acum câțiva ani lucram pentru o companie de software ce acționa pe piața de

www.todaysoftmag.ro | nr. 36/iunie, 2015

19

management Să batem palma asupra soluțiilor în proiectele software outsourcing, unde un client destul de mare al acestei companii avea nevoie de o funcționalitate complexă ce necesită mai multe echipe de development și mai multe luni de muncă. Pentru a ne asigura că am înțeles corect cerințele am decis să începem un POC cu acordul clienților. A fost un succes, clienții au văzut un prototip al soluției ce urma să le servească scopul, am descoperit lipsuri în cerințe, pe care altfel le-am fi descoperit mult prea târziu în procesul de dezvoltare. Am schimbat chiar părerea clienților cu privire la importanța unor cerințe, iar la altele am renunțat cu totul. POC-ul a ajutat la comunicarea dintre noi și clienți, noi fiind cei care implementăm soluția. Ne-am simțit owner-i pe soluția propusă mai ales având acordul deplin al clienților.

“Prototyping and design” reprezintă crearea de interfețe interactive care să prezinte vizual funcționalități. Este o metodă des folosită atât în lumea online-ului cât și în reprezentarea oricărui produs fie el fizic sau virtual fără a fi totuși necesară construcția per se a acestuia. O aplicație folosită în prototyping este de exemplu Axure, cât despre design, aceasta se face cel mai adesea în Adobe Photoshop. Există pe piață o multitudine de astfel de aplicații, însă indiferent de ele, importanța creării de prototipuri și de designe stă în impactul vizual. Oamenii percep mai bine ceva ce pot să vadă cu proprii ochi, par să înțeleagă mult mai bine, când li se pune în față un model cu care pot interacționa. La fel și

20

clienții sau stakeholderi-i relaționează mult mai bine cu o interfață interactivă care să le permită înțelegerea și vizualizarea a ceea ce urmează să devină produsul în care vor investi. În proiectele la care lucrez, care necesită interfață vizuală, este o practică comună să se utilizeze prototyping pentru a exemplifica și a cere părerea stakeholderilor cu privire la deciziile de produs. Ca Product Owner folosesc acest artefact ori de câte ori pot, pentru a obține o înțelegere cât mai bună a soluției ce urmează a fi implementată, pentru ca stakeholder-ii proiectelor respective să beneficieze de ceea ce au nevoie și pentru ca aceștia să fie mereu la curent cu propunerile de a îmbunătăți produsul (în cazul acesta este vorba despre produsul Betfair).

Fig. 1 Prototyping

Multe alte metode pot fi alese pentru a facilita baterea palmei, “shaking hands” asupra soluțiilor ce vor implementa produsul necesar conform cerințelor. Prin folosirea lor ne putem asigura de o tranziție

nr. 36/iunie, 2015 | www.todaysoftmag.ro

mult mai lină și sănătoasă de la cerințe la produsul final, trecând prin toate procesele de rafinare a cerințelor, de transmitere a acestora și în final de implementare și testare. Atunci când cerințele sunt înțelese și de o parte și de cealaltă în mod uniform și când soluția de implementare e universal acceptată de către părțile implicate, doar atunci poate să existe siguranța că produsul îndeplinește nevoile reale și le satisface printr-o implementare la obiect.

programare

Model Driven Design – de la teorie la practică

A

cest articol oferă o abordare teoretică minimală asupra Designului bazat pe modele (Model Drive Design), dezvoltat printr-o Arhitectura bazată pe Modele (Model Driven Architecture). De asemenea, descrie ce este un Model Conceptual și cum este el legat de Modelul Domeniului/Modelul Problemei. Ulterior, va oferi un exemplu simplu despre cum este creat un Model și manipulat în dezvoltarea software-ului bazat pe Modele.

Daniel Donea

daniel.donea@msg-systems.com Associate IT Consultant @ msg systems România

Primul subiect supus discuției: ce este un model? Conceptul de „Model” cât și modul în care acesta conduce spre o soluție sunt, în continuare, supuse unor discuții. Din acest motiv, există mai multe definiții pentru modele și, de asemenea, există o serie de tipuri de modele (model conceptual, modelul de domeniu, modelul de business, etc.). În acest sens, ar trebui să clarificăm anumite aspecte legate de terminologia formată în jurul conceptului de “Model”.

Concepte Orice software soluționează o problemă a clientului. Această problemă poate fi împărțită în mai multe zone de interes. Pe baza acestor zone de interes, se extrag topicuri (teme) relevante software-ului.

Un domeniu descrie una sau mai multe zone de interes din cadrul unei probleme.

Dacă zona de interes corespunde unor probleme de business, acesta va fi un domeniu de business. În general, se folosește noțiunea de domeniu al problemei, termen de ansamblu, care reflectă una sau mai multe zone de interes. În știința calculatoarelor, modelul domeniului constă în reprezentarea tuturor topicurilor specifice unei probleme / zone de

interes. În fapt, modelul domeniului descrie problema prin separarea ei în subprobleme, în funcție de domeniul de interes. Aceasta se realizează prin extragerea conceptelor cheie ale subproblemelor și legându-le împreună.

La sfârșitul acestui proces, vom vedeam o perspectivă mai ușoară de înțeles a problemei și potențiala ei soluție.

Bazându-ne pe acest model al domeniului, noi descriem modelul conceptual (numit pe scurt “model”) care propune o posibilă soluție a problemei. Modelul conceptual este o abstractizare bazată pe conceptele și relațiile formate din modelul domeniului.

Modelul devine o abstractizare a unui sistem fizic, în care programatorul va descrie diferite entități, atributele lor, relațiile și constrângerile dintre entități. Acesta, de asemenea, creează o perspectivă structurală asupra soluției în care accentul este pus pe ceea ce e important, ignorând detaliile.

Despre Model driven design/model driven architecture Există mai multe păreri legat de ceea ce este Model Driven Design (MDD) și cum ar trebui să arate Model Driven Architecture (MDA). Opinia larg acceptată provine de la Object Management Group (OMG)

www.todaysoftmag.ro | nr. 36/iunie, 2015

21

programare Model Driven Design – de la teorie la practică – un consorțiu de organizații software care dezvoltă și susțin specificații, pentru a îmbunătăți practicile de dezvoltare și implementare a software-ului enterprise.

Acest grup a creat framework-ul conceptual, numit „Model Driven Architecture”, care separă deciziile de business (ceea ce face aplicația), de deciziile orientate pe software (cum face aplicația), folosind „o abordare a specificațiilor de sistem, bazată pe utilizarea modelelor formale”. [1] MDA folosește modele pentru descrierea businessului (funcționalității) soluției, independent de orice constrângere de sistem (decizii orientate către software). În MDA, “Modelele independente de platformă sunt exprimate într-un limbaj de modelare independent de platformă”. Pe scurt, modelul este descris în funcție de specificație, independent de limbajul de programare în care va fi transformat, iar codul sursă propriu-zis este descris o dată cu modelul sau după ce modelul este terminat. Modelul va fi întotdeauna prioritar.

Exemplul oferit în acest articol este influențat de viziunea dată de către cei de la Object Management Group asupra MDA.

Despre Model driven software development

Thomas Stahl descrie Model-driven software development (MDSD) ca fiind : “o alternativă la round-trip engineering. Roundtrip engineering este conceptul de a fi capabili de a face orice fel de schimbare asupra unui model, precum și asupra codului generat de acel model. Modificările sunt propagate bidirecțional și ambele artefacte sunt întotdeauna consistente. Trecerea de la cod la model (inginerie inversă) este deosebit de interesantă în acest context. Model Driven Engineering oferă instrumentele utilizate pentru constrângeri specifice domeniului și realizează verificarea modelului. ”[2] Din acest motiv, Model-driven software development este un mijloc prin care se pot dezvolta aplicații descrise printr-o Model Driven Architecture. Model-driven software development este format din: • Domain-specific modeling language (DSML) – modele și meta-modele – în care relația dintre conceptele dintr-un domeniu, constrângerile și semantică sunt definite (aici se descriu modelele); • Motor de transformare și generatori – pregătește artefacte (cod sursă) într-un proces automatic/semi-automatic (aici se potențială soluție dezvoltată pe modele. generează codul după modele).

Problemă

Produsul final va fi cod descris într-un limbaj specific, care reflectă modelul specificat. Aceasta asigură nu numai consistența conceptuală a arhitecturii, dar și ajută la dezvoltarea funcțională a aplicației. „Capacitatea de a sintetiza artefacte din modele contribuie la asigurarea coerenței între implementarea aplicațiilor și analiza informațiilor asociate cu cerințele funcționale și QoS, cerințe surprinse de către modele.”[3] Există și alte avantaje în folosirea acestui tip de software development.

Un exemplu constă în refolosirea eforturilor precedente.

Modelul conceptual poate fi specific domeniului, dar soluția poate fi inspirată și din alte proiecte, sau la rândul ei, poate să fie sursa de inspirație pentru alte proiecte. Aceasta duce la refolosirea soluțiilor prin transformarea modelului într-un alt model conceptual specific unui alt domeniu. Această abordare este susținută de către OMG și reflectă unul din cele patru principii de la MDA[1].

Acestea sunt piesele pe care se creează aplicații Model Driven.

Pentru a ilustra cum funcționează, vom descrie o Problemă și o

22

nr. 36/iunie, 2015 | www.todaysoftmag.ro

Presupunem următorul scenariu dintr-un domeniu tehnic: Clientul nostru folosește ca Interfață grafică o versiune particularizată a aplicației Eclipse Rich Client Platform (Eclipse RCP). În acestă versiune, denumită “myRCP”, el dorește să ruleze o serie de aplicații, cu diferite scopuri.

Noua noastră aplicație trebuie să ruleze în această versiune particularizată de RCP ca o perspectivă nouă.

Tranzacțiile de business sunt realizate de către un Application server.

Pentru a oferi un framework comun între toate aceste aplicații, clientul myRCP a definit o structură de date care poate să asigure orice fel de necesitate. Această structură de date extinde EObject din Eclipse RCP. Exemplu. – toate obiectele extind MyRCPObject.

Modelul domeniului: Aplicația va rula într-un soft particularizat. Acest soft conține un set propriu de contracte (interfețe) pentru toate Obiectele și oferă un set de instrucțiuni particularizate pentru afișarea elementelor vizuale. Acest software este în continuă schimbare și aplicația noastră trebuie să se schimbe

TODAY SOFTWARE MAGAZINE odată cu ea.

Vom separa funcționalitățile de business (manipularea obiectelor) de funcționalitățile de afișare. Prin aceasta vom crea două componente: componenta RCP și componenta de business.

Componenta RCP va conține orice topic legat de elementele vizuale, managementul acțiuniilor și orice altă interacțiune cu utilizatorul, în timp ce componenta de business se va ocupa de toate topicurile legate de managementul acțiunilor și funcțiilor de business.

Aceste două componente vor comunica prin contractul lor comun - obiectul MyRCPObject.

Modelul Conceptual: fiecare din cele două componente va primi propriul model conceptual (unul sau mai multe, în funcție de nevoie). Acest model se va ocupa de toate topic-urile din domeniul tehnic cât și de domeniul de business al aplicației. În acest fel, modelul nostru poate oferii o perspectivă atât tehnică și funcțională.

Motivație

Interfețele serviciilor de business (comune între RCP și Application Server) vor fi generate, dar funcționalitatea de business va fi scrisă manual.

Ca un rezultat direct, cele două un Limbaje de Modelare Specific Domeniului – GuiDSML și BusinessDSML vor descrie toate modelele aplicației. Aceste modele vor oferi o perspectivă actuală și precisă asupra aplicației.

Descrierea modelelor folosind Xtext Xtext este un framework folosit în dezvoltarea limbajelor de programare și limbajelor specifice domeniilor. Acesta acoperă toate aspectele ce țin de infrastructura unui limbaj: parsere, interpretatoare și compilatoare; de asemenea oferă o integrare completă în Eclipse-IDE. Aduce și o serie de șabloane pentru toate aceste aspecte care în același timp pot fi ușor adaptate la nevoile individuale. [4] Xtext oferă un mod simplu de proiectare a unui limbaj specific domeniului. După ce arhitectul descrie gramatica folosită de către limbajul specific domeniului, xtext va genera un parser.

Acest parser va fi folosit în implementarea descrierii Modelului Conceptual. Programatorul va descrie modelul conceptual în fișierele DSML, folosindu-se de parser-ul generat, concentrânduse numai asupra ceea ce este esențial pentru businessul soluției și nu asupra implementării.

Xtext oferă suport Eclipse și o serie de instrumente folosite în dezvoltarea gramaticilor și a modelelor precum: asistență de conținut, validare și quick-fix, integrare avansată Java, integrare cu alte instrumente Eclipse, etc. .

Folosind parser-ul în definirea modelelor, asigurăm respectarea celor patru principii ale MDA. Exemplu [1]: a. Modelul este descris într-o notație bine definită; b. Sistemul este organizat în jurul unui set de modele care acceptă transformări; c. Existența unui meta-model : gramatica Xtext; d. Xtext este un framework open source.

Componenta RCP este dezvoltată într-un framework personalizat – myRCP. Acest framework definește cum sunt afișate elementele grafice în RCP, împreună cu acținile dintre aceste componente.

Acest lucru ridică unele probleme legate de ciclul de implementare. Orice developer va trebui să învețe acest framework personalizat și (probabil) framework-ul RCP. Pentru a evita acest impediment, vom modela toate elementele din interfața cu utilizatorul.

Descrierea modelului conceptual se va face folosind un Limbaj de Modelare Specific Domeniului (LMSD). Prin acest limbaj utilizatorul va descrie componentele vizuale și comportamentul așteptat. Elementele vor fi conectate cu Obiectele de Business și comportamentele cu Servicii de business. Acest un Limbaj de Modelare Specific Domeniului va fi numit (“GuiDMSL”).

Schimbul de date dintre Application Server și RCP este realizat prin DTO (obiecte de transfer de date). Aceste DTO-uri vor respecta contractul MyRCPObject (așa cum este cerut de către frameworkul myRCP) și va conține datele din Obiectele de Modelul conceptual pentru componenta RCP - GuiDSML business. În acest model conceptual, programatorul va descrie o reprezentare abstractă a componentelor vizuale și a comportamentului așteptat. Aceasta se realizează prin împărțirea perspectivei în editoare și view-uri. Aceste editoare vor conține sub-editoare și/sau elemente de control grafice.

Să luăm următorul exemplu din LDAP Studio (C):

Pentru a reduce sarcina de implementare, DTO-urile, Interfețele serviciilor de business, obiectele de business și relațiile dintre acestea vor fi generate folosind un Limbaj de Modelare Specific Domeniului ) – “BusinessDSML”.

https://directory.apache.org/studio/users-guide/ ldap_browser/tools_ldap_perspective.html

www.todaysoftmag.ro | nr. 36/iunie, 2015

23

programare Model Driven Design – de la teorie la practică Zona principală a aplicației este perspectiva – 1. Fiecare perspectivă conține cel puțin un editor și poate conține și view-uri.

Fiecare editor conține sub-editoare, paragrafe și/sau elemente de control grafice. Fiecare paragraf conține diferite elemente de control grafice.

Modelul trebuie să fie cababil să descrie toate aceste elemente și interacțiunea dintre ele. Cu Xtext noi vom descrie componentele și obiectele de business cu care lucrează.

Să luăm următorul exemplu GuiDSML – Entry editor – 2: {„Descriere pentru o posibilă transformare.”} editor EntryEditor opensIn MainEditor {

title Titles.EntryEditor

behavior EntryEditorBehaviours

businessObject EntryDTO

paragraphs{

submenu DN …

table EntryDescriptionTable

} } {„ Descriere pentru o posibilă transformare.”} Table EntryDescriptionTable { Title Titles.EntryDescriptionTable businessObject EntryDTO.descriptionDTO columns { column AttributeDescription { value descriptionDTO.attributeDescription } column Value { value descriptionDTO.value } }

}

}

deleteField(descriptionDTO.attribute)

Utilizatorul va putea să particularizeze funcționalitatea, folosind un cuvânt cheie custom la sfârșitul descrierii unui buton.

Modelul conceptual pentru componenta de Business - BusinessDSML Acest model conceptual trebuie să descrie toate obiectele de business (cum ar fi Entry și Description) și serviciile de business, cum ar fi deleteField(descriptionsDTO. attributeDescription).

Obiecte de Business: {„Description for possible transformation.”} entity Entry {

description : listof DescriptionEntity; } {„Description for possible transformation.”} entity DescriptionEntity {

attributeDescription : String;

value : String; } {„Description for possible transformation.”} dto EntryDTO link Entry {

link descriptionDTO : listof DescriptionDTO; }

Servicii de Busines:

service

}

EntryService { {„Description for possible transformation.”} operation deleteField ( {„Information anout inout.”} attributeDescription: String ) : void;

Acesta este o descriere a unui element de control grafic și obiectul de business din spatele lui. Interacțiunea dintre componente este descrisă cu ajutorul unui element behavior, unde Meta-modelul funcționalitatea businessului va fi dezvoltată.

Acum că am definit limbajul de modelare specific domeniului, următorul pas constă în definirea meta-modelului și frameworkBehavior EntryEditorBehaviours { ului de generare de cod.

businessObject EntryDTO

Load

Save

customAction changeColorField

customServerAction EntryService. deleteField(descriptionDTO.attributeDescription) }

Modelul conceptual descrie comportamentul. Operațiile de Load și Save sunt comportamente standard și codul generat va conține o implementare standard. Această implementare este comună tuturor obiectelor de business, iar identificarea obiectelor se face prin DTOs. Cuvântul customAction descrie o acțiune particulară RCP. Aici modelul conceptual prezintă un comportament, dar lasă sarcina implementării programatorului. Codul sursă final va fi generat parțial și programatorul va primi o definiție de metodă unde el trebuie să decidă particularitățile implementării.

Practic, modelul oferă o serie de comportamente comune, iar dacă acestea nu sunt suficiente, lasă la latitudinea programatorului să definească noi acțiuni particularizate.

Operația de deleteField este un apel la componenta de business, care oferă o anumită funcționalitate. Pentru a folosi această funcționalitate, programatorul va lega acțiunea la un buton specific. Apelul va fi făcut către server, iar rezultatul acțiunii va fi vizibil într-o zonă specifică. {„Description for possible transformation.”} Table EntryDescriptionTable { . . . columns { . . . } button buttonName action EntryService.

24

nr. 36/iunie, 2015 | www.todaysoftmag.ro

La baza acestor descrieri de model (DSML) se află un set de meta-modele. “Capacitatea de a analiza, automatiza și transforma modelele necesită un mod clar și lipsit de ambiguități pentru a descrie semantica modelului. Prin urmare, modelele intrinseci trebuie să fie descrise într-un model, pe care îl numim metamodel.“ [1] Meta-modelele noastre (unul pentru Gui și unul pentru Business) vor descrie gramatica (semantica) folosită în construirea modelelor. Astfel, de fiecare dată când un programator descrie un obiect de business, un serviciu, orice element specific limbajului de modelare specific domeniului, rezultatul (modelul) este analizat și compilat pentru a evita potențiale probleme.

Un exemplu dintr-un editor in GuiDSML: Editor EntryEditor opensIn MainEditor {

Title Titles.EntryEditor

Behavior EntryEditorBehaviours

businessObject EntryDTO

paragraphs{

TODAY SOFTWARE MAGAZINE

} }

submenu DN … table EntryDescriptionTable

Editorul descris în gramatica meta-modelului Editor : ‚editor’name=GUI_ID’opensIn ’EditorComponent=EDITOR_ID’{‚

‚title’ title=[Titles::TitleElement]

(‚behavior’service=[dm::BusinessService])?

(‚readOnly’service=[dm::ReadOnly])?

‚businessObject ‚object=[dm::BusinessObject]

‚paragraphs’’{‚ (paragraph+=Paragraph)+ ‚}’

‚}’;

În Xtext noi descriem gramatica specifică tuturor zonelor de interes din modelul domeniului (exemplu: editorul), implicit toate zonele de interes din modelul conceptual. Din exemplul anterior putem deduce faptul că un ‚editor’ trebuie să conțină un name și un EditorComponent. După ce acolada este deschisă, Xtext așteaptă un ‚title’. Elementele behavior și readOnly sunt marcate ca fiind opționale, semnul parantezei.

Folosind gramatica rezultat, xtext generează un parser – metamodelul aplicației. Acesta verifică dacă modelele GuiDSML au fost corect construite, comparându-l cu gramatica descrisă.

Un meta-model poate fi folosit pentru toate modelele descrise în componenta RCP, și un meta-model poate fi folosit pentru toate modelele din componenta Business.

Acest plugin va oferi toate instrumentele necesare pentru descrierea unui model în GuiDSML și BusinessDSML. După ce programatorul termină descrierea conceptuală a modelului (GuiDSML și BusinessDSML) un instrument de generare va crea codul final.

Framework-ul de generare de cod Până în acest punct, toate deciziile au fost independente de platforma de dezvoltare. Aici modelarea ajunge la capăt și codul rezultat este produs. În acest exemplu, noi folosim unul dintre instrumentele de generare oferite de către Eclipse Modeling Framework – Xpand.

Acesta este un limbaj static care generează cod pe baza unor template-uri definite. Vom folosi acest instrument deoarece oferă un set de template-uri care ajută la generarea Obiectelor RCP. Exemplul unui editor: «DEFINE editorTemplate FOR Editor-» «EXPAND DefaultEditor(editorTemplate.name)-» «EXPAND editorTemplate_Vars(editorTemplate.name)-» «EXPAND editorTemplate_Components_BusinessObject (editorTemplate.businessObject)-» «EXPAND editorTemplate_Components_Behaviour (editorTemplate)-» «ENDDEFINE» «DEFINE editorTemplate_Vars(String name) FOR editorTemplate -»

«IF ‚readOnly’ == true-»

private booleanreadOnly = true;

«ENDIF-»

private String editorName = « name »; «ENDDEFINE» «DEFINE DefaultEditor(String name)-» Import staticorg.junit.Assert.*; Import java.io.IOException; Import java.util.HashMap; Import java.util.Map; Import java.util.Set; … public static class « name » { …

«ENDDEFINE»

Codul rezultat care reprezintă editorul este generat în ordinea specificată de către elementele DEFINE/ EXPAND. Spre exemplu, definiția clasei generate: Import staticorg.junit.Assert.*; Import java.io.IOException; Import java.util.HashMap; Import java.util.Map; Import java.util.Set; … public static class EntryEditor { private String editorName = EntryEditor; // template components }

După ce procesul de generare este terminat, clasele generate sunt împachetate în fișiere jar și trimise către proiectele care le folosesc. Clasele generate parțial sunt generate o singură dată – o nouă generare a întregului model nu va rescrie clasa deja implementată. Aceste clase sunt parțial scrise de mână, procesul de generare a codului sursă nu trebuie să suprascrie codul adăugat manual.

Xpand este o soluție bună pentru generarea obiectelor RCP, dar pentru o abordare mai generală, recomand folosirea limbajului Xtend. Este mai flexibil și mai ușor de citit/scris. În practică, fiecare element al unui model conceptual este analizat în detaliu. După un studiu atent și aprofundat al domeniului modelului, modelul conceptual este descris (la un nivel abstract), și, apoi începe crearea de meta-modele. După ce metamodelul este terminat, acesta va fi transmis dezvoltatorilor pentru utilizare. Din acest punct înainte, meta-modelul va suferi schimbări dacă este necesar și în funcție de modificarea domeniului problemei.

Acest articol este doar o prezentare generală a unei aplicații proiectate folosind dezvoltare software model-driven. Dacă fiecare domeniu problemă este diferit, atunci fiecare model conceptual va fi diferit. Pentru mai multe informații recomand citirea articolelor din zona de referință și să încercați unele dintre instrumente folosite în MDD [8].

Referințe [1] An introduction to Model-Driven Architecture (MDA) – Alan W. Brown, Jim Conallen [2] Model-Driven Software Development, (Technology, Engineering, Management)- Thomas Stahl, Markus Volter [3] Towards the Automatic derivation of Malaca Agents using MDE – Inmaculada Ayala, Nercedes Amor and Lidia Fuentes – E.T.S.I. Informatica, Universidad de Malaga [4] Xtext website - http://www.eclipse.org/Xtext/ [5] http://www.omg.org/mda/mda_files/Model-Driven_Architecture.pdf [6] http://ftp.icm.edu.pl/packages/ace/ACE/PDF/GEI.pdf [7] https://eclipse.org/community/images/apacheldap.png [8]mdwhatever.free.fr/index.php/2010/06/model-driven-tools-the-big-list/ www.todaysoftmag.ro | nr. 36/iunie, 2015

25

programare

Ce este de fapt TDD?

D

in când în când, particip la discuții cu diverși oameni despre ce este de fapt TDD de fapt. Deoarece am dobândit în timp o anumită cunoaștere a acetui subiect, care se datorează nu numai utilizării, dar și datorită faptului că îl explic altora, am hotărât să scriu acest articol care detaliază punctul meu de vedere în legătură cu ce este TDD. Sper că îl veți găsi util.

Alexandru Bolboacă

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

26

nr. 36/2015 | www.todaysoftmag.ro

Prezentul articol îl continuă pe cel din deja testat. Dezvoltatorul poate totuși să numărul trecut al revistei Today Software introducă erori dacă problema nu a fost Magazine pe această temă. înțeleasă corect sau dacă testele au fost incorecte.

TDD este o metodă de a concepe (design) Este asta suficient pentru a numi ceea Noi scriem cod pentru a rezolva o ce rezultă din TDD un ”design bun”? Cel problemă și folosim teste pentru a defini mai probabil, răspunsul este nu. Logic este comportamentul așteptat al soluției. Când să spui: testele sunt trecute, o altă bucățică a proCalitatea designului depinde de blemei este soluționată. Noi tocmai am abilitățile designerului. creat intenționat o bucată de cod care TDD în sine nu va produce design rezolvă o problemă. Acesta este design. bun. Produce într-adevăr design cu anuDar oare este un design bun? Aceasta mite calități, dar depinde de dezvoltator să este o discuție interesantă. Pentru a răs- ducă asta mai departe. punde la întrebare, ar trebui să ne uităm Dar… la calitățile designului, pe care TDD ne obligă să le dezvoltăm. Iată două dintre ele: Când se concepe design în TDD? Testabilitate – evident, deoarece codul Este acum momentul să introducem este testat. încă un aspect al designului software.

Rezistența la greșeli – există o proba- Scrierea codului nu este suficientă; este bilitate mai mică de a introduce greșeli important să structurezi codul într-un atunci când modifici codul care a fost anumit mod. Cea mai puțină structurare

programare

Keep Calm and Start playing Dart

pe care o putem face este să scriem întregul cod într-o singură metodă enormă. Computerului nu îi va păsa, dar acest lucru va afecta calitățile designului.

Atunci când face TDD, un programator trebuie să ia multe decizii cu privire la structurarea codului. Aceste decizii se pot referi la utilizarea claselor ( metodelor, variabilelor, membrilor, etc. ), la modul denumirii lucrurilor, la tipologia datelor, la maniera de colaborare a claselor. Toate acestea sunt decizii legate de design, care contribuie la calitățile sale. Denumirea unei variabile prin litera ”a” o va face mai puțin lizibilă decât dacă o numim ”sumăDeBani” (”amountOfMoney”). Adăugarea a 10 straturi va face codul mai dificil de înțeles decât utilizarea a numai două starturi. O clasă cu 10 colaboratori este mai dificil de înțeles decât o clasă cu trei colaboratori.

Când luăm aceste hotărâri? Întotdeauna! Mai precis: La început. De exemplu, utilizarea unui cadru web MVC înseamnă deja să respecți anumite constrângeri legate de structura codului.

Când scrii testul: numele clasei supuse testului.

Când scrii codul: numele metodelor private, membrii de probă sau variabile locale.

Când reutilizăm codul: extragerea unei metode, extragerea unei clase sau simpla redenumire a ceva. Îmbunătățirea calităților designului este un proces continuu.

Nu se limitează la pasul de reutilizare sau la ciclul TDD. Iar acest lucru este în regulă, deoarece, de fapt…

TDD este o metodă pentru design incremental Incremental înseamnă că noi concepem software bucată cu bucată. Se concepe software înainte de a începe ciclurile, în timp ce scriem testul și puțin când îl reutilizăm. Acțiunea de a concepe este intenționată: noi încercăm să îmbunătățim calitățile de design care sunt relevante în contextul nostru (în mod tipic, modificabilitatea). Incremental mai înseamnă, de asemenea, că soluția crește pas cu pas, prin tăierea problemei în felii mai mici.

De exemplu, pentru a rezolva o problemă care are drept input o listă de multe numere, noi pornim de la o listă goală, apoi o listă cu un număr și așa mai departe.

Acest proces este foarte asemănător cu un altul: soluționarea problemelor în general. Tocmai s-a închis cercul. Dacă design înseamnă să rezolvi probleme, iar rezolvarea problemelor se face cel mai bine în mod incremental, atunci cum putem numi mai bine TDD decât o metodă de a concepe software într-o manieră incrementală?

Cititorii mai familiarizați își vor aminti probabil că TDD a fost adesea discutat în contextul ”designului emergent”. Eu cred că există o problemă legată de denumirea ”emergent”: mulți dezvoltatori pe care i-am întâlnit au tendința să considere că ”design emergent” înseamnă un design care apare din senin datorită procesului. Bineînțeles, această accepție poate crea confuzii. Eu pledez pentru utilizarea termenului ”incremental” pentru o mai bună descriere a procesului.

TODAY SOFTWARE MAGAZINE

Iar aceasta nu e tot…

Acest articol s-a concentrat pe utilizarea cea mai comună a TDD. Lucrurile sunt puțin mai complicate, deoarece există un număr surprinzător de moduri de a utiliza testele și TDD. Iată câteva exemple avansate, nici într-un caz o listă completă: Eu am utilizat TDD, în trecut, pentru a explora alternative de design: rezolv aceeași problemă cu constrângeri diferite și compar designurile rezultate. Aceasta este o metodă de design mai complexă, deoarece explorarea alternativelor face parte din procesul general de design.

TDD poate fi utilizat pentru a învăța lucruri noi. Eu am folosit TDD cu succes pentru a preda în trecut limbajele de programare unor oameni fără pregătire în domeniu.

TDD poate fi utilizat pentru a explora spațiul problemă. De exemplu, dacă luăm Game of Life (Jocul vieții) al lui Conway, eu mă întreb: dar dacă universul s-ar schimba? Cum ar fi dacă s-ar schimba timpul? Dar dacă regulile s-ar schimba? etc. Adesea fac același exercițiu și cu aplicațiile de afaceri pe care le dezvolt.

Uneori utilizez TDD pentru a explora potențialele modificări ale caracteristicilor. Într-o altă categorie, TDD As If You Meant It (ca și cum ai fi vrut asta) este un exercițiu bazat pe TDD dar cu constrângeri suplimentare care întârzie toate deciziile legate de structurarea codului, pentru cât mai mult timp posibil. Este probabil cea mai incrementală abordare posibilă, dar poate de asemenea să ducă la un cod care nu face prea multe chiar și după 1-2 ore. Eu îl consider un exercițiu intrigant, dar nu îl utilizez niciodată în producție. Întrebările și comentariile voastre sunt binevenite; vă rog nu ezitați să îți scrieți pe alex.bolboaca@mozaicworks.com.

www.todaysoftmag.ro | nr. 36/iunie, 2015

27

programare

Fault-Tolerant Microservices cu Netflix Hystrix

A

Radu Butnaru

rbutnaru@sdl.com Senior Developer @ SDL

cest articol continuă seria destinată soluțiilor aplicate într-un sistem construit folosind o arhitectură bazată pe Microservicii. Articolul precedent a tratat (Micro)service Discovery cu Netflix Eureka (http://todaysoftmag.ro/ article/1391/micro-service-discovery-cu-netflix-eureka). Articolul curent prezintă biblioteca Java Hystrix, dezvoltată în regim open-source de către compania Netflix.

Hystrix oferă o implementare matură a pattern-ului Circuit Breaker, al cărui scop este să reducă impactul defectărilor și al timpilor mari de latență în sisteme distribuite.

Problema O caracteristică principală a sistemelor construite pe bază de microservicii este utilizarea unui număr mare de componente distribuite. Pe măsură ce numărul de interacțiuni sincrone prin rețea crește, impactul unei defectări a unui serviciu poate deveni din ce în ce mai sever.

Enumerăm câteva din cazurile cele mai frecvente de comportament anormal ale unui serviciu: • serviciul nu mai răspunde (serviciul este oprit sau rețeaua nu funcționează); • apelul de serviciu durează prea mult; • apelul de serviciu returnează erori.

Fără mecanisme de protecție, erorile și în mod special timpii mari de latență se vor propaga către clienții serviciului, unde se va putea ajunge în situația ca resurse de sistem limitate să fie epuizate (de exemplu, pool-ul de thread-uri al serverului web).

Prin escaladarea erorilor, disponibilitatea (engl. availability) sistemului este afectată în mod semnificativ: întregul sistem poate deveni indisponibil din cauzei unei singure dependențe defecte, deși restul serviciilor

28

nr. 36/2015 | www.todaysoftmag.ro

de care depinde, funcționează corect.

Soluția Un Circuit Breaker (rom. Întrerupător de circuit) este folosit pentru a intermedia operațiile prin rețea dintre un client și un serviciu. Circuit Breaker-ul monitorizează și detectează când serviciul invocat se comportă anormal, respingând apelurile către serviciu până când acesta va deveni funcțional din nou. Întorcând o eroare imediată, se previne epuizarea resurselor din procesul client. În același timp, se reduce încărcarea serviciului invocat,

TODAY SOFTWARE MAGAZINE crescând astfel șansele ca acesta să își revină din condiția defectă. ... În secțiunile care urmează, vom analiza implementarea pat- <dependency> <groupId>com.netflix.hystrix</groupId> tern-ului Circuit Breaker din biblioteca Hystrix. <artifactId>hystrix-core</artifactId>

Circuit Breaker-ul Hystrix Să presupunem că un client invocă un serviciu. Clientul va izola toate punctele de acces către serviciu prin efectuarea tuturor apelurilor prin intermediul unui Circuit Breaker (aceasta se realizează la nivel de cod prin extinderea de clase Hystrix sau prin adnotări - detalii în cele ce urmează). Circuit Breaker-ul va intercepta și monitoriza toate apelurile și va acționa în cazul unor condiții de eroare, efectuând tranzițiile de stare descrise mai jos.

Starea Închis În cazul de funcționare normal când nu există condiții de eroare, Circuit Breaker-ul este în starea închis. Toate apelurile sunt transmise în mod transparent către serviciu.

Starea Deschis

<version>1.3.20</version> </dependency> ...

Pentru a proteja un apel de serviciu cu un Circuit Breaker, trebuie extinsă clasa HystrixCommand. Exemplul fictiv de mai jos apelează un serviciu de produse: ... public class FindAllProductsCommand extends HystrixCommand<List<Product>> { private RestTemplate restTemplate; public FindAllProductsCommand( RestTemplate restTemplate) { super(HystrixCommandGroupKey.Factory .asKey(„ProductGroup”)); }

this.restTemplate = restTemplate;

@Override Circuit Breaker-ul consideră următoarele condiții drept protected List<Product> run() throws Exception { simptome ale unei defectări și le va lua în calcul pentru a decide // Apel serviciu HTTP ResponseEntity<Product[]> responseEntity = întreruperea circuitului: restTemplate.getForEntity( • O excepție este returnată (de ex., eroare de conectare sau “http://host/products”, Product[].class); serviciul întoarce codul HTTP 500).

Product[] products = responseEntity.getBody(); • Apelul durează mai mult decât timpul de expirare configureturn Arrays.asList(products); } rat (valoarea implicită este de 1 secundă). } • Pool-ul intern de thread-uri sau semaforul folosit de Hystrix ... pentru apel respinge execuția datorită capacității depășite.

Hystrix folosește pool-uri de thread-uri pentru a limita număPentru a invoca clasa comandă, ea trebuie instanțiată și apoi rul de resurse folosit de o dependență. apelată metoda execute():

Circuitul este întrerupt de îndată ce Hystrix determină că pragul de erori de pe parcursul unei ferestre de timp statistice a fost atins ( implicit, 50% erori pe parcursul unei perioade de timp de 10 secunde). În starea deschis, Circuit Breaker-ul va respinge apeluri prin: • întoarcerea unei excepții (comportamentul implicit, denumit și “fail fast”), • opțional, prin întoarcerea unei valori de fallback (de ex., întoarcerea unui rezultat nul, gol, sau predefinit).

Starea Semi-deschis

... new FindAllProductsCommand(productService).execute(); ...

 Pentru a întoarce un rezultat predefinit în locul unei excepții atunci când Circuit Breaker-ul este deschis, suprascriem metoda getFallback() în implementarea comenzii: ... public class FindAllProductsCommand extends HystrixCommand<List<Product>> { ... @Override protected List<Product> getFallback() { return Collections.emptyList(); } } ...

Pentru a permite recuperarea din condiția de eroare, atunci când Circuit Breaker-ul se află în starea deschis, el va permite în mod periodic câte un apel, la un interval configurabil (implicit, 5 secunde) - aceasta este starea semi-deschis. Dacă apelul se efecÎn cazul în care un anumit tip de eroare este consituează cu succes, circuitul se va închide din nou. derat comportament așteptat/tratabil (de ex. validări de logică business), tipul excepției întoarse trebuie să fie Folosire HystrixBadRequestException. În caz contrar, excepția Vom prezenta două modalități de a integra biblioteca Hystrix va fi tratată ca simptom al unui comportament defectuos. în proiecte: ...

1. Direct folosind API-ul Hystrix - necesită implementarea și public class FindAllProductsCommand extends { invocarea de comenzi Hystrix pentru fiecare apel de serviciu. HystrixCommand<List<Product>> ...

2. Folosind bibliotecile Spring Cloud Netflix și Javanica - o @Override protected List<Product> run() throws Exception { modalitate de a folosi Hystrix cu impact mai redus asupra codutry { lui de proiect, prin adnotarea metodelor ce apelează servicii. // Apel serviciu HTTP

API Hystrix direct Pentru a folosi biblioteca Hystrix, trebuie adăugată următoare dependință în proiectul Maven:

... } catch (IllegalArgumentException e) { // Dacă se întoarce HystrixBadRequestException, // Circuit Breaker-ul nu se va deschide throw new HystrixBadRequestException( “Bad request.”, e); www.todaysoftmag.ro | nr. 36/iunie, 2015

29

programare Fault-Tolerant Microservices cu Netflix Hystrix } ...

}

}

Valorile specifice de configurări (timpi de expirare, capacitatea pool-ului de thread-uri, praguri procentuale de eroare, etc.), pot fi atribuite programatic la momentul instanțierii comenzii.

... new FindAllProductsCommand(HystrixCommand.Setter. withGroupKey(HystrixCommandGroupKey.Factory .asKey(“ProductGroup”)). andCommandPropertiesDefaults( HystrixCommandProperties.Setter() .withCircuitBreakerRequestVolumeThreshold(20) .withCircuitBreakerErrorThresholdPercentage(50) .withExecutionIsolationThreadTimeoutInMilliseconds(1000) .withMetricsRollingStatisticalWindow InMilliseconds(10000) .withMetricsRollingStatistical WindowBuckets(10)) .andThreadPoolPropertiesDefaults( HystrixThreadPoolProperties.Setter() .withCoreSize(10)), restTemplate) .execute(); ...

Alternativ, pentru configurări se poate folosi biblioteca Netflix Archaius.

... @HystrixCommand(fallbackMethod = “defaultProducts”) public List<Product> findAllProducts() { // Apel serviciu HTTP ... } public List<Product> defaultProducts() { return Collections.emptyList(); } ...

Dacă se dorește ca un anumit tip de excepție să nu fie considerat simptom al unei defectări, tipul excepției trebuie menționat în adnotare: ... @HystrixCommand(ignoreExceptions = {IllegalArgumentException.class}) public List<Product> findAllProducts() { // Apel serviciu HTTP ... } ...

Pentru configurări (timpi de expirare, capacitatea pool-ului de thread-uri, praguri procentuale de eroare, etc.), se poate utiSpring Cloud Netflix / Javanica liza mecanismul standard Spring Boot de configurare în fișierul Biblioteca Spring Cloud a fost prezentată în [articolul prece- application.yml: dent din serie](link aici). Spring Cloud este construită pe baza ...

Spring Boot și furnizează interfețe abstracte pentru tehnologia hystrix: command: din stiva open-source Netflix. Suportul pentru Hystrix se bazează findAllProducts: 1 pe biblioteca third-party Javanica . execution: isolation: Pentru a utiliza suportul Spring Cloud Netflix / Javanica, trethread: buie adăugată următoarea dependință în proiectul Maven: timeoutInMilliseconds: 1000 ... <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> <version>1.0.0.RELEASE</version> </dependency> ... ...

circuitBreaker: requestVolumeThreshold: 20 errorThresholdPercentage: 50 metrics: rollingStats: timeInMilliseconds: 10000 numBuckets: 10 threadpool: ProductService: coreSize: 10

În plus, adăugăm adnotarea EnableCircuitBreaker pe clasa principală de configurare Spring Boot: Monitorizare cu Hystrix Dashboard / Turbine Hystrix oferă suport pentru vizualizarea și monitorizarea ... @EnableCircuitBreaker stării curente a Circuit Breaker-elor prin trimiterea continuă de public class HystrixClientDemoApp { măsurători către o aplicație web tip panou de comandă: Hystrix ... } Dashboard2. Pentru scenarii cu servere multiple (cluster) Hystrix oferă posibilitatea de a trimite măsurătorile unui agregator Pentru a proteja un apel de serviciu cu un Circuit Breaker, intermediar: Turbine3, înainte ca acestea să ajungă la Hystrix este suficient să se adauge adnotarea HystrixCommand pe Dashboard. metoda respectivă: Capturile de ecran de mai jos prezintă Hystrix Dashboard: ... @HystrixCommand public List<Product> findAllProducts() { // Apel serviciu HTTP ResponseEntity<Product[]> responseEntity = restTemplate.getForEntity(“http://host/products”, Product[].class); Product[] products = responseEntity.getBody(); return Arrays.asList(products); } ...

Pentru a întoarce un rezultat predefinit în locul unei excepții atunci când Circuit Breaker-ul este deschis, trebuie menționată metoda de fallback în adnotare: 2 https://github.com/Netflix/Hystrix/tree/master/hystrix-dashboard 1 https://github.com/Netflix/Hystrix/tree/master/hystrix-contrib/hystrix-javanica

30

nr. 36/iunie, 2015 | www.todaysoftmag.ro

3 https://github.com/Netflix/Turbine

TODAY SOFTWARE MAGAZINE Circuit Breaker Închis

impact mai redus asupra codului de proiect.

Bibliografie 1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

Circuit Breaker Deschis Următoarele măsurători sunt arătate și actualizate în timp real: • Indicatori privind starea de sănătate și volumul de trafic; • Rata de cereri (la nivel de server și cluster); • Procentul de erori și contoare (apeluri cu succes, apeluri respinse, expirări thread-uri, respingeri din cauza capacității pool-ului de thread-uri, erori/excepții) cumulative pe perioada ferestrei de timp curente (în exemplele de capturi de ecran de mai sus, în ultimele 20 de secunde); • Starea Circuit-breaker-ului; • Procente de timpi de latență pe parcursul ultimului minut; • Statistici despre pool-ul de thread-uri;

Pattern-ul Circuit Breaker5 - autor Martin Fowler Proiectul Hystrix6 Wiki-ul Hystrix7 Proiectul Spring Cloud Netflix8 Proiectul Javanica9 Proiectul Hystrix Dashboard10 Wiki-ul Hystrix Dashboard11 Proiectul Turbine12 Proiectul Archaius13 Prezentare Hystrix JavaOne14 - autor Ben Christensen

5 http://martinfowler.com/bliki/CircuitBreaker.html 6 https://github.com/Netflix/Hystrix

Pe wiki-ul Hystrix Dashboard4 se poate consulta documentația necesară interpretării diagramelor și contoarelor.

7 https://github.com/Netflix/Hystrix/wiki 8 http://cloud.spring.io/spring-cloud-netflix 9 https://github.com/Netflix/Hystrix/tree/master/hystrix-contrib/hystrix-javanica

Concluzie Netflix Hystrix este o implementare matură a pattern-ului Circuit Breaker, configurabilă în detaliu, cu suport solid pentru vizualizare și monitorizare. Bibliotecile Spring Cloud Netflix/ Javanica oferă o alternativă de folosire bazată pe adnotări, cu un 4 https://github.com/Netflix/Hystrix/wiki/Dashboard

10 https://github.com/Netflix/Hystrix/tree/master/hystrix-dashboard 11 https://github.com/Netflix/Hystrix/wiki/Dashboard 12 https://github.com/Netflix/Turbine 13 https://github.com/Netflix/archaius 14 https://speakerdeck.com/benjchristensen/application-resilience-engineering -and-operations-at-netflix-with-hystrix-javaone-2013

www.todaysoftmag.ro | nr. 36/iunie, 2015

31

programare

Aplicații IoT cu Java ME Embedded 8

Î

Dănuț Chindriș

n numărul 31 al revistei am făcut o introducere în ceea ce privește subiectul Internet of Things din perspectiva platformei Java. Așa cum am promis, vom continua această discuție prezentând detaliile creării unui proiect Java ME Embedded 8. Această versiune reprezintă un important pas înainte, odată cu adoptarea CLDC 8 - care este un subset al Java Standard Edition - și MEEP 8 - specificație care definește un mediu puternic și flexibil pentru sisteme embedded de dimensiuni reduse. Alături de acestea, trebuie să remarcăm alinierea platformei despre care discutăm la Java SE 8.

Java Developer @ Elektrobit Automotive

Tooling pentru aplicații ME - Oracle Java ME SDK 8.1

danut.chindris@elektrobit.com

Aplicațiile Micro Edition pot fi dezvoltate atât manual cât și cu ajutorul unui SDK specializat, cunoscut sub numele Oracle Java ME SDK 8.1. SDK-ul, distribuția Java ME, documentația și orice alte resurse mai sunt necesare dezvoltării aplicațiilor embedded, se găsesc la adresa Oracle destinată platformei. Înainte de a începe să dezvoltăm aplicații embedded, Oracle recomandă în primul rând instalarea Oracle Java ME SDK 8.1 - pachet software care la momentul scrierii acestui articol este disponibil doar pentru sistemul de operare Windows.

Următorul pas este descărcarea distribuției Java ME Embedded 8 destinată dispozitivului pe care dorim să rulăm aplicațiile.

Aceasta vine sub forma unei arhive ZIP și trebuie transferată pe dispozitiv - cu ajutorul unui tool cum este PuTTY -, unde urmează să fie instalată. De asemenea, se recomandă păstrarea unei copii pe sistemul desktop, unde se va executa dezvoltarea aplicațiilor. Acest ultim pas nu este obligatoriu, însă este recomandat pentru cazul în care dezvoltatorul dorește să execute comenzi pe dispozitiv cu ajutorul AMS CLI (Application Management System Command Line), prin intermediul programului Developer Agent.

Prima noastră aplicație Java ME Odată ce am instalat SDK-ul și Java ME, putem să începem dezvoltarea unei aplicații embedded. Sub forma ei cea mai simplă, o astfel de aplicație trebuie să

32

nr. 36/2015 | www.todaysoftmag.ro

conțină o clasă care extinde clasa abstractă javax.microedition.midlet.

MIDlet, un fișier manifest și un fișier JAD (Java Application Descriptor). Am putea scrie o astfel de aplicație manual, fără ajutorul unui IDE, care să automatizeze anumiți pași. Acesta este un bun exercițiu pentru dezvoltatorul care intră pentru prima dată în contact cu Java ME Embedded 8. Astfel, ne propunem să creăm o simplă aplicație, care afișează în consolă un mesaj la pornirea aplicației și unul la oprirea acesteia. În primul rând, creăm o clasă care extinde javax.microedition. midlet.MIDlet, implementând metodele : public class Hello extends javax. microedition.midlet.MIDlet { public void startApp() { System.out.println(„Hello MIDlet”); } public void destroyApp(boolean unconditional) { System.out.println( „Goodbye MIDlet”); } }

Pentru a continua în aceeași manieră, compilăm manual clasa pe care tocmai am scris-o, cu o comandă similară celei listată aici: javac -cp %JAVA_ME_SDK%\lib\ meep_8.0.jar -d classes src\ro\ leje\Hello.java

Observăm că avem nevoie de biblioteca meep_8.0.jar la compilare, întrucât aceasta definește clasa abstractă . Această bibliotecă se găsește în directorul %JAVA_ME_SDK%\lib, unde

%JAVA_ME_SDK% reprezintă calea unde a fost instalat SDK-ul.

Mesajul Hello MIDlet este afișat la pornirea MIDlet-ului, Următorul pas îl reprezintă crearea fișierului manifest, care iar mesajul Goodbye MIDlet la oprirea acestuia, cu ajutorul trebuie să conțină cel puțin următoarele informații: combinației de taste Ctrl + C. MIDlet-Name: Hello MIDlet-Version: 1.0 MIDlet-Vendor: Today Software Magazine MIDlet-1: Hello,,ro.leje.Hello MicroEdition-Configuration: CLDC-1.8 MicroEdition-Profile: MEEP-8.0

Presupunând că am salvat fișierul manifest cu numele , putem trece la următorul pas, care este crearea arhivei JAR. Această arhivă trebuie să conțină clasa compilată și fișierul manifest.

Realizăm aceasta lansând în execuție următoarea comandă: jar cfm build\Hello.jar MANIFEST.MF -C classes .

Odată ce am creat fișierul , pentru această aplicație mai avem nevoie de un singur lucru, și anume descriptorul aplicației, cunoscut și sub numele de fișier JAD (Java Application Descriptor).

Acesta se aseamănă cu fișierul manifest, conținând următoarele linii obligatorii:

Rularea aplicației pe dispozitiv O altă modalitate de a rula aplicația este prin instalarea acesteia pe dispozitivul țintă. Pentru acest articol am folosit o plăcuță de dezvoltare Raspberry PI Model B+, dotată cu un dongle Wi-Fi. De asemenea, menționăm faptul că platforma are deja instalat un sistem de operare Linux, ceea ce facilitează munca noastră cu acest hardware. Având această configurație la îndemână putem accesa de la distanță sistemul Raspberry PI, cu ajutorul unui program precum PuTTY. Accesăm plăcuța cunoscându-i IP-ul și un user cu drepturi de root. Odată ce ne-am autentificat, schimbăm directorul curent, pentru a ne situa în directorul bin al distribuției Java ME Embedded 8 instalată. Acest lucru este ilustrat în următoarea captură de ecran:

MIDlet-Name: Hello MIDlet-Version: 1.0 MIDlet-Vendor: Today Software Magazine MIDlet-1: Hello,,ro.leje.Hello MIDlet-Jar-Size: 1076 MIDlet-Jar-URL: Hello.jar MicroEdition-Profile: MEEP-8.0

Observăm că unul dintre atributele obligatorii ale fișierului JAD este dimensiunea în bytes a arhivei. Salvăm acest fișier cu numele în același director cu arhiva JAR.

Rularea aplicației cu un emulator În acest moment avem o aplicație Java ME Embedded 8 completă, pe care o putem lansa în execuție. Cea mai simplă modalitate pentru a face acest lucru este folosirea emulatorului pe care ni-l pune la dispoziție SDK-ul. Presupunând că directorul curent este directorul al proiectului nostru, putem lansa următoarea comandă: emulator -Xdevice:EmbeddedDevice1 -Xdescriptor:Hello.jad

Cu ajutorul opțiunii -Xdevice specificăm numele dispozitivului pe care dorim să rulăm aplicația. EmbeddedDevice este un dispozitiv emulat, configurat automat în momentul în care instalăm SDK-ul. Prin intermediul celei de-a doua opțiuni prezente în comanda pe care am executat-o -Xdescriptor specificăm locația și numele descriptorului aplicației noastre.

Putem observa rezultatul rulării aplicației în următoarea figură:

Accesarea plăcuţei de dezvoltare cu PuTTY

Figura ne arată faptul că următorul pas a fost rularea script-ului u s e r t e s t . s h cu ajutorul comenzii sudo ./usertest.sh. Acest script a lansat în execuție Java runtime, care permite accesul la AMS. Platforma ascultă pe portul 2201 și ne permite să ne conectăm de la distanță pentru a face managementul aplicațiilor ME. Înainte de a putea continua, trebuie să înregistrăm dispozitivul cu ajutorul aplicației Device Connections Manager. De vreme ce avem instalat SDK-ul, ar trebui să găsim în SysTray o iconiță intitulată Oracle Java(TM) ME SDK 8.1 Device Manager. Făcând click pe aceasta, deschidem managerul de conexiuni, unde putem adăuga plăcuța noastră, pe care o identificăm după IP. Odată ce am înregistrat dispozitivul, ar trebui să avem în fereastra activă ceva similar figurii următoare:

Înregistrarea unui dispozitiv

Aplicaţia Hello în emulator

Acum putem instala pe Raspberry PI aplicația pe care am creato într-o secțiune anterioară. Avem la dispoziție câteva modalități pentru a face aceasta, una dintre ele fiind cu ajutorul utilitarului Device Selector, care este la dispoziția noastră, bineînțeles, datorită www.todaysoftmag.ro | nr. 36/iunie, 2015

33

programare Aplicații IoT cu Java ME Embedded 8 faptului că am instalat SDK-ul. Deschizând această aplicație, observăm o listă cu toate dispozitivele instalate la momentul curent. Predefinit, avem la dispoziție trei dispozitive emulate: EmbeddedDevice1, EmbeddedDevice2 și Qualcomm_IoE_Device.

Alături de acestea, putem vedea plăcuța Raspberry PI, pe care tocmai am înregistrat-o, cu numele EmbeddedExternalDevice1.

Dorim să rulăm aplicația Hello pe acest dispozitiv, așa că facem click-dreapta și alegem Run JAR or JADÖ, după cum este ilustrat și în figura următoare:

Observăm faptul că în captura de ecran anterioară este listat și mesajul care trebuie afișat la distrugerea aplicației. Aceasta pentru că înainte de a face captura am apăsat butonul Remove, prezent în interfața aplicației de management.

Așadar, oricare ar fi modalitatea aleasă pentru a rula aplicații Java ME Embedded 8 fie pe dispozitive, fie într-un emulator, acesta este un proces relativ facil. Mai există o cale de a rula aplicații embedded pe dispozitive, cu ajutorul liniei de comandă AMS, prin intermediul utilitarului Developer Agent, însă această metodă este în fază de concept în această versiune a platformei.

Pe parcursul acestui articol am urmărit pașii creării, instalării și rulării unei aplicații minimale, efectuând manual fiecare sarcină. Totuși, platforma ne pune la dispoziție o serie de unelte care vin în întâmpinarea nevoilor dezvoltatorilor și țintesc sporirea productivității acestora. Într-un articol viitor ne propunem să prezentăm procesul dintr-o altă perspectivă, automatizat cu ajutorul acestor unelte.

Concluzii Dezvoltarea aplicațiilor Java ME Embedded 8 poate fi un proces interesant și distractiv, dar uneori dificil și frustrant. Din păcate, materialele de studiu dedicate Java ME Embedded 8 sunt puține. Până în momentul de față există o singură carte publicată care abordează subiectul dezvoltării aplicațiilor Java ME Embedded 8. De asemenea, majoritatea articolelor existente pe această temă au o abordare generală, prezentând în linii mari trăsăturile acestei noi platforme. Deocamdată, thread-urile pe forumuri sunt relativ puține, însă putem observa interesul din ce în ce mai mare al utilizatorilor, dornici să învețe cum să folosească Rularea aplicaţiei pe dispozitiv noua versiune. Cele mai consistente resurse pe care le avem la dispoziție sunt ghidurile oficiale compilate de către Oracle, care Alegând de pe disk fișierul Hello.jad cu ajutorul feres- pot fi descărcate de pe site-ul oficial al platformei. trei de tip Open care a apărut, platforma lansează în execuție managerul de aplicații, care instalează pachetul nostru software pe plăcuță, lucru pe care îl putem vedea în următoarea captură de ecran:

Managerul de aplicaţii

Faptul că aplicația noastră Java ME Embedded 8 rulează întradevăr pe dispozitiv ni-l demonstrează consola PuTTY, unde putem vedea output-ul pornirii și opririi aplicației:

Output-ul aplicaţiei în consolă

34

nr. 36/iunie, 2015 | www.todaysoftmag.ro

management

Relaţiile la distanţă chiar pot funcţiona!

R

elaţiile la distanţă pot avea mult succes. Mai ales în domeniul nostru, în care companii din două regiuni diferite cooperează şi fiecare aduce o calitate specifică în cadrul parteneriatului. Dar o relaţie fie personală, fie profesională, în cadrul aceleiaşi companii sau într-o regiune nu foarte îndepărtată, necesită un pic de efort. Pentru a crea parteneriate de calitate, pe termen lung, apelăm pur şi simplu la aspecte de bun simţ, pentru a ne asigura că toată lumea se îndreaptă în aceeaşi direcţie şi că aşteptările sunt clare. Totuşi, aceste reguli de bun simţ sunt adesea ignorate.

Florin Roman

florin.roman@tss-yonder.com Delivery Manager @ Yonder

Comunică. Unul dintre cele mai importante aspecte ale unei relaţii pe termen lung cu clientul este comunicarea. Cu cât aceasta este mai bună şi mai frecventă între voi şi client, cu atât mai onestă şi mai deschisă va deveni relaţia. În acest fel va fi mai uşor pentru client să rămână mulţumit şi problemele să fie rezolvate într-un interval de timp rezonabil.

Eticheta privind e-mailul. Atunci când primiţi un e-mail, încercați să răspundeţi la timp. Iar dacă nu puteţi răspunde cererii în aceeaşi zi, atunci confirmaţi primirea e-mailului şi spuneţi-i celui care l-a trimis pe când poate aştepta un răspuns complet. Mai mult, comunicarea prin e-mail poate fi interpretată în mod greşit mai ales în timpul perioadelor pline de stres, dacă expeditorul şi destinatarul nu se cunosc foarte bine. Aşa că, din când Fără agende ascunse. Agendele ascunse în când, puneţi mâna pe telefon şi, pur și simadesea duc la neînţelegeri şi, în cele din plu, vorbiţi. urmă, la neîncredere.Discutaţi fiecare idee, indiferent dacă e bună sau rea. Dacă e bună, Sumarizaţi şi recapitulaţi. Indiferent va fi apreciată; în caz contrar, vă va ajuta să de cât de fără importanţă ar putea părea o înţelegeţi unele aspecte de care până atunci întâlnire sau o convorbire telefonică, odată nu eraţi conştienţi. Doar așa, fiecare dintre terminată întâlnirea vor exista nişte paşi de parteneri va obține beneficii. urmat. Sumarizaţi și comunicați astfel încât toată lumea să ştie acelaşi lucru. Chiar dacă Fiţi proactivi. Menţineţi-vă clienţii nu există paşi de urmat, ci doar o recapitulare informaţi în manieră proactivă în ceea ce a discuţiei, este bine să trimiteţi un e-mail cu priveşte orice noutate. Evitaţi situaţia în care aceasta, astfel încât toată lumea să ştie acelaşi ei trebuie să ceară informaţia. Astfel, toţi cei lucru. implicaţi vor fi asiguraţi de deschiderea şi de natura colaborativă a ambelor părţi. www.todaysoftmag.ro | nr. 36/iunie, 2015

35

management Relaţiile la distanţă chiar pot funcţiona!

Fiţi propriul vostru client.

Familiarizaţi-vă cu afacerea clientului, înţelegeţi cum funcţionează aceasta, dinamica pieţei lor, precum şi provocările cu care se confruntă. Nu trebuie să deveniţi expert, însă trebuie să vorbiţi pe aceeaşi limbă şi să înţelegeţi îngrijorările clientului dumneavoastră.

Acordați atenție calității. Pentru a fi bun în ceea ce faceţi, trebuie să aveţi oamenii potriviţi în locurile potrivite, procese adecvate şi niciodată să nu vă mulţumiţi cu locul doi sau cu „suficient de bine”. Încercaţi în mod constant să deveniţi mai buni şi să duceţi expertiza către nivelul următor. Dacă oferiţi servicii de calitate, clienţii se vor întoarce la dumneavoastră.

Aveţi răbdare. Construirea relaţii- Şi, mai important decât atât, vă vor recolor necesită timp. Ascultaţi-vă clientul. manda cunoscuţilor, oferindu-vă astfel o Nu încercaţi să vă impuneţi toate ideile bună oportunitate de creştere a afacerii. dintr-o dată, la început, ci faceţi paşi mici, discutând punct cu punct, şi adaptându-vă Parteneriate. Dezvoltaţi o relaţie de limbajul şi discuţia în funcţie de reacţi- parteneriat. Aceasta merge dincolo de proile şi comportamentul respondentului iectul individual dezvoltat. Dacă un client dumneavoastră. vede că sunteţi cu adevărat implicat şi că sunteţi foarte motivat să îl ajutaţi, atunci va Fiţi integru. Dacă faceţi ceea ce aţi începe să vă privească nu doar ca un simspus că o să faceţi, de fiecare dată, fără plu furnizor. Desigur, a deveni parteneri excepţie, atunci veţi fi primul pe listă atunci implică mai mult decât ceea ce e menţiocând clientul va căuta noi servicii. Nu vă nat aici; totuşi, voi lăsa acest subiect pentru fie teamă să recunoaşteţi atunci când aţi altă dată. făcut o greşeală; cereţi-vă scuze, învăţaţi, împărtăşiți modul în care plănuiţi să o corectaţi şi asiguraţi-vă că nu veţi repeta aceeaşi greşeală de două ori. Nerespectarea promisiunilor va duce la o lipsă de integritate şi nu veţi reuşi niciodată să aveți o relaţie de încredere cu clientul dumneavoastră. În schimb, s-ar putea să ajungeţi să-l pierdeţi pe acel client.

36

nr. 36/iunie, 2015 | www.todaysoftmag.ro

Fiţi oameni. Întâlniţi-vă faţă în faţă.

Comunicând la distanţă nu veţi dovedi întotdeauna că vă înţelegeţi într-adevăr clientul şi că puteţi să-l ajutaţi în înfruntarea provocărilor. De aceea este important ca, mai ales la începutul relaţiei, să vă întâlniţi faţă în faţă şi să vă aliniaţi aşteptările.

Aceasta este o bună oportunitate de a înţelege mai bine afacerea clientului, provocările şi obiectivele sale pentru perioada următoare şi modul în care puteţi cel mai bine să îi fiţi de folos. Totuşi, discuţiile de afaceri nu vor fi întotdeauna de ajutor în ce priveşte ceea ce gândeşte celălalt – admitem că există întotdeauna lucruri care nu sunt spuse, mai ales la început – şi dacă vreţi să vă înţelegeţi mai bine „audienţa” atunci ar fi bine să beţi o cafea sau o bere împreună, într-un cadru informal, cum ar fi un restaurant sau un pub.

Relaţiile la distanţă pot fi cu adevărat cele mai bune. Fiecare partener îşi aduce propriul set de deprinderi în ecuaţie, iar combinaţia acestora dă naştere unui parteneriat puternic. Natura tipului de relaţie poate varia, mergând de la personală la cea de afaceri, însă presupune aplicarea acelorași reguli: niciodată să nu-l subapreciezi pe celălalt şi comunicarea este esenţială.

HR

Cu un zâmbet nu se face primăvarăștiința fericirii în organizații

S

untem tot mai preocupați de fericire. Din perspectivă organizațională, suntem tot mai conștienți de relevanța unor angajați fericiți: aceștia sunt mai productivi, mai satisfăcuţi şi mai ataşaţi. În acest sens, observăm tot mai multe eforturi pentru a ne mulțumi angajații. Dar cum oare putem ajunge de la zâmbet la fericire organizațională?

Szilárd Kacsó

kacso.szilard@happy-employees.eu CEO & Trainer @ Azimut Happy Employees

Chiar dacă începem să vedem cât de important este să avem angajați fericiți, suntem încă destul de reticenți în fața unui concept atât de abstract precum fericirea, deoarece ne este greu să evaluăm dimensiunea acesteia. Vestea bună este că există studii, instrumente, scale, validate ştiinţific care ne ajută să cuantificăm drumul de la zâmbet la fericire organizațională.

angajaților, angajamentul de continuitate , cel normativ care poate prezice probabilitatea ca un angajat să părăsească compania.

Deoarece aminteam de importanța cuantificării fericirii în organizații, prezentăm câteva instrumente științifice, pe care noi le utilizăm în procesul de evaluare al conceptului, pe care însă le aplicăm în funcție de fiecare dimensiune: Utrecht Work De la zâmbet la fericire Engagement Scale, Job Satisfaction Survey, Fericirea la locul de muncă este mai Organizational Commitment Questionnaire, mult decât râs și voie bună. Evaluăm ferici- The Work and Meaning Inventory Scale etc. . rea angajaților ca fiind un scor compus din trei concepte: Nu zâmbetul ajută. Ci niște angajați fericiți • Implicare- un concept în care accenUn angajat fericit nu este definit doar tul este pus pe dezvoltarea potențialului printr-un zâmbet, ci prin nivele optime ale angajaților, pentru a-i proteja de efectele implicării, angajamentului și satisfacției. unor posibili factori de stres și pentru a Dar de ce avem nevoie de angajați fericiți în creşte productivitatea. organizațiile noastre? Poate că unul dintre • Satisfacţie- este o stare pozitivă care cele mai la îndemână argumente este ROI-ul rezultă din atitudinea angajatului la locul ( Return of Investment) pe care îl aduce un de muncă. program de creştere a fericirii angajaţilor. În • Angajament- discutăm despre trei primul rând, acesta se resimte cel mai mult la tipuri de angajament organizaţional: cel nivelul costurilor aferente angajării şi pregăafectiv, care poate prezice performanța tirii unui nou angajat. De aceea, e preferat să www.todaysoftmag.ro | nr. 36/iunie, 2015

37

HR Cu un zâmbet nu se face primăvară- știința fericirii în organizații punctele forte și de îmbunătățit ale echipei.

• Această primă etapă este urmată de implementare în care propunem și livrăm programe de training, teambuilding, coaching specific nevoilor identificate în partea de diagnoză.

• Evaluarea şi sustenabilitatea programului- evaluăm rentabilitatea şi progresul acţiunilor noastre, după care ne îngrijim de menţinerea în organizație a comportamentelor deja create. În concluzie, fericirea nu se reduce la un zâmbet, care poate fi de multe ori doar unul dintre semnele sociabilității.

Doar câteva activități pentru amuzamentul și implicarea angajaților nu ne ajută să ajungem la fericire organizațională.

Instrumentele științifice potrivite și un program complex implementat, pot să aducă imense beneficii cantitative şi calitative companiei şi angainvestim în retenţia şi angajamentul angajaţilor. jaţilor noştri transformând În plus, cercetările au dezvăluit o legătură de cauzalitate între conceptul abstract de fericire organizațională în ceva concret și fericirea angajaților, productivitatea și angajamentul lor și într-un măsurabil. Nu uitați! Cu un zâmbet…nu se face primăvară! fericit final, satisfacția și loialitatea clienților firmei. La acest beneficiu adăugăm şi faptul că angajații fericiți s-au dovedit a fi cu 10-12% mai productivi decât cei cu o stare mai puțin bună la locul de muncă . Avantajele resimţite la nivelul companiei se concretizează printr-o rată crescută de retenţie şi profit adus companiei.

De la fericire la fericire organizțională Se fac tot mai multe eforturi pentru a creşte satisfacţia angajaţilor prin organizarea diferitelor petreceri tematice, activităţi de echipă, traininguri, beneficii la birou. Însă acestea nu sunt suficiente pentru a ajunge la fericire. Pot aduce zâmbete, cel mult..

Este nevoie, în schimb, de o strategie şi un program mai complex. Recomandăm un program care țintește impactul pe termen lung al fericirii în organizație și care presupune trei etape: • Diagnoza echipei- unde, cu ajutorul instrumentelor științifice și a diferitelor metode de observare evaluăm și măsurăm diferiți indicatori organizaționali, pentru a identifica

38

nr. 36/iunie, 2015 | www.todaysoftmag.ro

sponsori

powered by