Today Software Magazine N36/2015

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
Aplicaii IoT cu Java ME Embedded 8

Model Driven Design
de la teorie la practic
S batem palma asupra soluiilor
n proiectele software

Techsylvania 2015:
despre Product Managerii din IT
Cu un zmbet nu se face primvar tiina fericirii n organizaii
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
Relaiile la distan chiar pot funciona!
6
Ovidiu Man
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
Clin Biri
17
Arhitectura
Conic
Adrian Bontea
19
S batem palma asupra
soluiilor n proiectele
software
Raluca Radu
21
Model Driven Design
Daniel Donea
26
Ce este de fapt
TDD? (II)
Alexandru Bolboac
28
Fault-Tolerant Microservices
cu Netflix Hystrix
Radu Butnaru
32
Dnu Chindri
35
Relaiile la distan
chiar pot
funciona!
Florin Roman
37
Cu un zmbet nu se face primvartiina fericirii n organizaii
Szilrd Kacs
editorial
Ovidiu Man
ovidiu.matan@todaysoftmag.com
Editor-in-chief
Today Software Magazine
e pregtim de vacane i gndurile ne zboar spre rmuri nsorite sau spre

munii cei umbroi. Vom iei din iureul 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 inspiraie, cnd
ne surprindem c n jocul imaginaiei intr cele mai nstrunice abstraciuni i idei.
Pentru c orict am ncerca, nu ne putem elibera total de latura noastr profesional dei suntem n vacan - aceste idei se pot materializa n proiecte originale de software
sau hardware.De multe ori, credei c aceste proiecte nu sunt realizabile imediat sau
avei ndoieli c pot fi puse n aplicare. De aceea, v invit s le trimitei la adresaidei@
todaysoftmag.compentru a le discuta i analiza. Vom ncerca chiar s punem bazele
unui minicomuniti 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 ediie. Felicitm
organizatorii pentru progresul realizat fa de conferina de anul trecut prin creterea
calitii speakerilor, extinderea pe dou zile a evenimentului i atragerea unui numr
mult mai mare de participani.
Cum sfritul lunii mai i nceputul lunii iunie au fost pline de evenimente, n acest
numr vei gsi o serie de review-uri ale acestora n titluri caUnconference: 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 gsii n revist cu titlulTechsylvania 2015: Minimum Delightful
Product - Interviu cu Rohan Chandran. n ceea ce privetearticolele tehnice, menionm
Arhitectura Conic, o alternativ la folosirea patternuluiLayers.Tot din zona arhitecturii
software v propunemModel Driven Design de la teorie la practic. Din aria de programare am publicat n acest numrFault-Tolerant Microservices cu Netflix Hystrixi
un prim articol de IoT:Aplicaii IoT cu Java ME Embedded 8. V lsm s descoperii i
restul articolelor din acest numr i v doresc o lectur plcut !!!
Ovidiu Man
Fondator al Today Software Magazine
nr. 36/2015 | www.todaysoftmag.ro
Redacia Today Software Magazine

Fondator / Editor in chief: Ovidiu Man
Graphic designer: Dan Hdru
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 Romnia
Adrian Bontea
Ovidiu Deac
Software Craftsman
@ Yardi Romnia
Independent Consultant &

Functional Programming Advisor
@ Ullink
Alexandru Botez
Raluca Radu
alex.bolboaca@mozaicworks.com
adrian.bontea@yardi.com
Traductor: 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
Dnu 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
Szilrd 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
Clin Biri
calin.biris@loopaa.ro
Digital Director
@ Loopaa
ISSN 2284 6352

Ovidiu Man
Editor-in-chief
Copyright Today Software Magazine

Reproducerea parial sau total a articolelor
din revista Today Software Magazine
fr acordul redaciei este strict interzis.
www.todaysoftmag.ro
www.todaysoftmag.com
www.todaysoftmag.ro | nr. 36/iunie, 2015
interviu
m avut plcerea de a realiza un interviu cu Rohan Chandran pe tema product

management-ului la a doua ediie 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 Man
Editor-in-chief
[Ovidiu Man] Produsul Minim

ncnttor (Minimum Delightful Product)
este o idee minunat pentru dezvoltarea noilor produse. V rugm s descriei
aceast idee n cteva cuvinte pentru cititorii notri care nu au putut participa la
Techsylvania.
[Rohan C handran] Exp eriena
Minim ncnttoare este o evoluie a
binecunoscutului concept de Produs
Minim Viabil. De fapt, inteniile sunt exact
aceleai. Totui, eu cred c schimbarea a
dou cuvinte atrage dup sine o schimbare
radical a modului n care l abordm,
deoarece gndurile noastre i aciunile
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 reele
sociale, toate au gsit o potrivire problem
soluie. Facebook a descoperit acordul
produs pia.
Voi construii o Experien, nu un
Produs. Un Produs tinde s fie un set
de funcionaliti pe care le furnizai.
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 emoii. Atunci cnd v conectai
la acel nivel, oamenii vor rspunde la ceea
ce le furnizai i de fapt vor deveni o parte
a procesului de metamorfozare a sa n viziunea final.
Voi aspirai la ncntare, nu doar
Viabilitate. Atunci cnd o avei pe cea din
urm, ai bifat o list de funcionaliti i i
TODAY SOFTWARE MAGAZINE

cerei utilizatorului vostru s valideze dac
acestea au fost bifate. Atunci cnd intii
spre ncntare, creai uimire, minunare,
surpriz, acel sentiment de uau! Vrei ca
utilizatorul vostru s se simt precum un
copil atunci cnd 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 ncnttoare autonom, care s v permit s
validai potrivirea produs-pia prin testarea unor ipoteze specifice pe care le-ai
stabilit. Orice este neesenial ar trebui lsat
la o parte, pn cnd ai stabilit potrivirea
produs pia.
S i cunoti 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 aa: Tu trebuie s
ajungi la oamenii care conteaz, nu s i
numeri pe oamenii la care ajungi. Aceste
cuvinte sunt simple, dar profunde, atunci
cnd eti la nceput. Noi toi tindem s
vedem marile poveti de succes, dar ignorm ct 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 gsit calea spre cretere i
succes n zilele sale de nceput. Cheia lor
i pentru toat lumea, era s neleag
natura bazei lor de utilizatori care erau cu
adevrat angajai, pentru a nelege comportamentul lor i modul n care utilizau
serviciul i s gseasc o cale de a reproduce asta.
Atunci cnd porneti la nceput,
prima provocare este s ai o int clar n
minte. Ai putea s segmentezi dup geografie (dup cum a fcut Uber), sau dup
demografia de vreun fel, dar nu ncercai
s mulumii pe toat lumea. Reinei
c aceasta nu nseamn ntotdeauna c
oamenii din afara segmentului vostru nu
pot participa, dar ei nu sunt ceea ce voi

v-ai stabilit drept int n mod explicit.
De acolo mai departe, este o chestiune de
observare a datelor i de nelegere a angajamentului. S-ar putea s fii surprini
voi credeai c vindei flori soilor 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 vindei ceva, atunci, absolut,
Experiena Minim ncnttoare a voastr
trebuie s includ componenta de monetizare la urma urmelor, aceasta este baza
afacerii voastre. Ceea ce vei dori probabil
s facei aici, este s v concentrai pe o
geografie ngust, cu poate un singur tip
de floare sau aranjament. Voi nu ncercai
s verificai dac oamenii prefer trandafirii sau lalelele voi ncercai s validai
faptul c ei doresc ntr-adevr s utilizeze
serviciul vostru, aa cum l-ai nfiinat. Ai
fcut s fie simplu i ncnttor pentru
ei s comande de la voi i le putei onora
comenzile? Dac ai reuit asta, s adugai
flori diferite, zone geografice diferite i aa
mai departe, este partea cea uoar.
Cum vedei Managementul Produsului

(Product Management) ntr-o lume Agile?
Cum funcioneaz cu ciclurile de dezvoltare
i design?
Arta i tiina 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 ncercm noi s obinem i cum vom
msura succesul; s stabileasc prioritile
fr cruare s defineasc ce este MDE
(experiena ncnttoare minim) i cum
vom reitera de acolo; s permit i s faciliteze orice este necesar pentru a ajuta
toi membrii echipei s livreze ceea ce
nseamn s fie att un om care se pricepe la toate, ct i un conductor pentru
ceilali.
Ceva ponturi pentru conceperea unui
produs ncnttor?
Nu exist o formul magic, dar mai
presus de toate a ncuraja oamenii s se
concentreze pe minim, deoarece, dac l
poi supune pe acesta unor condiii, deja
te afli la jumtatea drumului nspre o
experien ncnttoare. Este cel mai dificil, i de aceea, cel mai important lucru de
fcut. Aceasta, deoarece exist ntotdeauna
mai multe funcionaliti mici i idei care
i imaginezi c vor face produsul tu mai
bun. Dincolo de asta, este esenial s fii cu
adevrat deschis i s nu fii ataat de ideile
tale i apoi s pui utilizatorii s se uite la
experiena pe care le-o oferi de timpuriu.
Mergi n cafenele, n staii de autobuz sau
gri i cere oamenilor feedback. Privete
limbajul lor corporal i nva s citeti
printre rnduri i vei afla foarte repede
dac i-ai ncntat sau nu.
educaie
Retrospectiva unui an la
ACADEMY+PLUS
CADEMY+PLUS se ndreapt spre a doua generaie de studeni. S-a ncheiat

un an plin de activiti care a crescut att noi talente ct i ncrederea celor din
jur pentru un astfel de proiect.
Gloria Csiszer
gloria.csiszer@pitechnologies.ro
Marketing Specialist
@ Pitech+Plus
Aceast metod revoluionar de

nvare i formare profesional n
domeniul IT, bazat pe o program actualizat cerinelor pieei 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 nvare alternativ este de a descoperi mini strlucite,
care pot crea produsele informatice de
mine.
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 ctigat
premiul Best Hack cu aplicaia I need
medication.
De-a lungul acestui prim an, stafful s-a
concentrat i pe urmtoarele generaii. La
sediul academiei se organizeaz regulat
Coder Dojo pentru copiii de gimnaziu, iar
n mai a avut loc prima ediie a campionatului Game of Codes, organizat pentru
Program ntregit de activiti extra
liceeni din diverse orae, unde timp de 12
Dup selecia riguroas, studenilor ore acetia au codat jocuri dup reguli i
acceptai li s-a pus la dispoziie o plat- cerine. n toamn urmeaz s se organiform care i-a trecut n doar cteva luni zeze a doua ediie.
prin diverse limbaje
de programare precum: C, UNIX, PHP
i JavaScript. Pe lng
m at e r i a e f e c t i v ,
acetia au nvat s
lucreze pe proiecte ca
i la un loc de munc,
avnd task-uri individuale dar i proiecte
de echip. Studenii
i-au descoperit i
d e z volt at d ive rs e
skill-uri participnd
programare
Un ajutor pentru piaa de IT

Unul dintre obiectivele pe termen lung
al ACADEMY+PLUS este s ridice gradul de colaborare ntre companiile care
caut tineri talentai, devenind n timp o
surs de for de munc performant i
capabil care va rezolva aceast nevoie pe
piaa de IT. Perioada de var din fiecare
an este dedicat stagiilor obligatorii de
practic pentru studenii academiei. Att
PITECH+PLUS, ct 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 toi cei care doresc
s beneficieze de acest sistem de educaie
revoluionar i gratuit. n fiecare dintre aceste luni peste 120 de studeni vor
petrece zile intense experimentnd piscine, etapa de selecie n care trebuie s
predea zilnic proiecte individuale sau s
lucreze mpreun cu o echip la proiecte
mai ample. Acetia vor rezolva practic
aceleai cerine pe care le au i colegii lor
din Frana, care s-au nscris la Ecole 42.
Aceast etap este echivalent cu parcur- din iulie fiind deja ocupat. Cei interesai
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 exerciii practice a trecut mai apoi
de testul de angajare al unei firme de IT.
Next level: gamification

Background-ul divers al comunitii
formate la etajul trei al sediului academei va fi i mai mult sprijinit din acest an
datorit schimbrii platformei de nvare
de ctre cei de la Ecole 42, care s-au bazat
pe ideea de gamification. Astfel, au fost
customizate modulele de formare prin
intermediul crora s creasc gradul de flexibilitate i personalizare n conformitate
cu pregtirea individual a fiecrui candidat. Cei cu un nivel mai ridicat pot opta
pentru un anumit mix de formare, trecnd
peste unele nivele. Cu ct vor lucra mai
repede i mai bine, vor putea deschide noi
proiecte i provocri.
Pentru piscinele din august i septembrie mai sunt cteva locuri disponibile, cea
eveniment
Unconference: ITAKE
m primit sptmnile trecute de la Today Software Magazine invitaia de a participa, la I.T.A.K.E. Ateptam acest eveniment
nc din toamn, de cnd am discutat la IT Days cu Alex Bolboac despre conceptul unconference, concept care mi s-a
prut foarte interesant. Recunosc c am avut o mic reinere avnd n vedere faptul c se anuna o conferin de Software
craftmanship, curent cu care nu prea rezonez. Totui, n program erau i cteva prezentri legate de programarea funcional i
speram s cunosc mai muli oameni interesai de acest subiect. De aceea, nu am stat pe gnduri i am acceptat imediat.
Locaia a fost foarte bun: ultracentral, pentru pretenioi. Conferina s-a
desfurat pe mai multe fire, ceea ce m-a
ajutat s m eschivez de la subiectele
care nu mi s-au prut interesante. Dintre
keynote speakers mi-a plcut 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 generaliti.
Spre dezamgirea mea, James Lewis a vorbit despre microservices ca i cnd ar fi o
idee nou, fr s fac deloc trimitere la
sisteme ca Erlang, n care de treizeci de ani
se dezvolt arhitecturi asemntoare i din
care un programator care scrie microservices ar putea aduna nelepciune cu sacul.

Ct despre restul prezentrilor, am
participat aproape n exclusivitate la cele
din aria hardcore programming, ns
nu am simit c merita btut atta drum.
Repet, nu am participat la celelalte fire
ale conferinei. Faptul c s-au desfurat
mai multe prezentri n paralel, a reprezentat un dezavantaj. Se poate s nu mi
fi ales bine prezentrile, dar nu am fost
impresionat. Cu mici excepii, 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 ateptam 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 aplicaii reale, am
putea profita de compozabilitatea oferit
de monoizi. A descris n cteva slide-uri
monoidul, aa cum e definit n teoria categoriilor i apoi a artat cum se aplic la
codul real, cu care se lupt majoritatea dintre noi. Tema s-a aflat la intersecia dintre
DDD i programare funcional. Nivelul a
fost introductiv, fr pretenii prea mari de
la asculttori. S-a pus o problem interesant: dac ncercm s alegem modelele

astfel nct s fie monoizi, rezultatul este
mai elegant, mai compozabil i mai uor de
folosit. E nevoie de mai multe prezentri
de genul acesta, care s scape programarea
funcional de aerul academic pe care l
are n prezent i s ne arate cum am putea
profita de tehnicile ei n situaii ntlnite de
programatori normali.
Partea cea mai interesant al evenimentului a fost, de departe, componenta

open space. n ambele zile, a doua jumtate
a fost rezervat pentru open space. Reeta
e relativ simpl:
Se mparte spaiul existent n N zone
de discuii.
Se mparte timpul n M perioade de
cte 30-45min.
Se face un tabel N * M, the marketplace care conine zonele i orele la care
acestea sunt libere.
Se explic regulile jocului n faa
participanilor: orice se poate altura
oricrei discuii i poate pleca dintr-o
discuie atunci cnd dorete.
Se completeaz tabelul cu propunerile de subiecte.
Fiecare dintre cei care au venit cu
propuneri fac o introducere prin care s
atrag participani la discuia 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
funcional, testare, continuous delivery,
Scala etc. . O bun parte din merit i revine
moderatorului Mike Sutton, care a reuit
s i mobilizeze pe participani s vin cu
subiecte de discuie.
Definiia pe care o d Alex Bolboaca
open-space-ului i anume o conferin
care const doar din pauze de cafea e
foarte reuit. Exact asta s-a ntmplat:
oameni implicai, discuii aprinse, schimburi de contacte. Au lipsit cu desvrire
dormitul n banca din spate, cititul mailurilor sau jucatul pe telefon n ateptarea
pauzei de igar. Cnd informaia primit
nu justifica timpul consumat, pur i simplu
te ridicai i plecai n alt zon de discuii.
Cei care erau prea obosii i cutau o canapea sau stteau la o cafea unde, bineneles,
pornea o alt discuie ad-hoc. Pe scurt: a
fost o experien excelent.
Referitor la calitatea prezentrilor din
cadrul open-space, unele au fost mai bune,
altele mai puin bune, dar asta e mai puin
important. Important e faptul c discuiile
pornite n jurul subiectelor respective au
fost reuite i c lumea a participat activ.
Impresia mea a fost c majoritatea nu a
venit cu materiale pregtite. Au desenat
la fata locului i au improvizat pe loc. Nu
toate discuiile au fost purtate ntr-un mod
profesionist, nu toi tiut s vorbeasc n
public. Dar, din nou, asta nu conteaz.
Conteaz faptul c i-au fcut curaj i s-au
implicat masiv, lucru care a fcut evenimentul reuit.
n concluzie, trebuie s i felicit pe cei
de la Mozaic Works pentru organizare
i, n primul rnd, pentru formatul ales.

Fr discuie, a fost un eveniment la care a
meritat s merg. Sper c n ediiile viitoare
partea open-space va ocupa majoritatea timpului. Eu unul voi ncerca s aplic
formatul acesta la viitoarele ntlniri ale
comunitii de programare funcional.
De asemenea, sper ca organizatorii evenimentelor de IT din Cluj i nu numai, s
neleag valoarea unui astfel de format i
s avem ct de curnd i un unconference
local.
Ovidiu Deac
ovidiu@agile-bit.com
Independent Consultant &
Functional Programming Advisor
@ Ullink
11
eveniment
JSCamp 2015
ea de-a doua ediie a JSCamp, o conferin JavaScript pentru Romnia i Europa de Est, a avut loc pe data de 2 iunie, n
Bucureti, 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 experienele
unor oameni importani din industria
web. Conferina a fost mprit n patru
sesiuni (cte dou discursuri per sesiune),
cu subiecte variate care au inclus proiectele
open-source, standarde de codare, testarea,
experienele, redarea grafic i chiar web
audio. ntre sesiuni, au existat pauze de
cafea i prnz, n care participanii s-au
putut ntlni cu vorbitorii i ali entuziati
JavaScript.
Ziua a nceput cu Kenneth Auchenberg,
directorul tehnic al GoToMeeting
Free at Citrix , care a iniiat proiectul
RemoteDebug pentru a unifica depanarea la distan. Prezentarea sa, denumit
Viitorul instrumentelor DevTools cu
RemoteDebug, a avut ca subiect puterea depanrii 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 nti nevoie s ne
regndim instrumentele de lucru.
A fost urmat de ctre Sebastiano
Armeli, inginer software la Spotify.
12
Acesta a dezvoltat
i conceput aplicaii
utiliznd JavaScript,
Java, Ruby, dar este
foarte pasionat de
JavaScript i dezvoltarea web. El este
autorul crii electronice MVC se
aplic la JavaScript
i al unui jQuery
plug-in pentru imagini care se ncarc
lene, numit JAIL.
Discursul su, Aplicarea standardelor de
codare, a ncercat s conving participanii
n legtur cu importana standardelor
de codare i le-a spus ce fel de standarde
folosesc la Spotify pentru a le uura traiul.
Cteva 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 sntii, cu sediul n Londra.
Prezentarea sa a avut titlul Meteugul
testrii client-side i a argumentat

importana testelor, deoarece acestea ne
permit s extindem i s reutilizm codul
nostru cu uurin. 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 pregtire n fizic i i face
plcere s combine vizualul cu tehnicul. n prezentarea sa, Cum s dezvoli
PhotoShop WebGL nu numai pentru
3D, el a explicat principiile de baz ale
WebGL i a codat n direct cteva tehnici
de editare de imagini precum: scalarea,
decodificarea, rotirea, trucuri simple cu

culori, amestecarea, deformarea i efecte
pixeli.
Dup pauza de prnz, 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 utilizrii React/Flux.
Cea de-a treia sesiune a fost ncheiat
de Remy Sharp, favoritul publicului, dac
considerm aplauzele. El este fondatorul
Full Frontal, conferina 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 Biii 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 cteva dintre provocrile care apar cnd rulezi aplicaia.
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 pstrezi
viu codul important, printre numeroase

referine la Star Wars i ticuri americane,
el a vorbit despre experiena sa n construirea proiectelor open-source. Avnd peste
10 milioane download-uri/lun, el ne-a
mprtit c este nfricotor s primeti
att de mult atenie 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 cnd un
proiect devine att 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 su a fost intitulat Tipare JavaScript pentru muzica de
dans contemporan i, cu ajutorul ctorva
ritmuri plcute folosind Web Audio
API, el a demonstrat c muzica poate fi
codat n direct ntr-un browser, utiliznd
JavaScript.
Personal, eu am gsit conferina foarte
interesant. Speakerii i participanii
au fost foarte prietenoi i vorbrei, iar
locaia a fost, de asemenea, frumoas i
primitoare. De abia atept urmtoarea
ediie, 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 oerings are business focused, they drive real, tangible value.
www.3pillarglobal.com
13
eveniment
Techsylvania 2015 despre Product Manageri-i din IT
nd am ajuns laTechsylvaniala Casa de Cultur a Studenilor, lumea era nc

n pauz ntre paneluri, dei ntrziasem puin. M-am ntlnit cu civa colegi
din online i am schimbat dou vorbe despre eveniment. Acetia au apreciat
mult calitatea coninutului pe care l-au primit n cele dou zile i mi-au spus c le-au
fost depite ateptrile.
Clin Biri
calin.biris@loopaa.ro
Digital Director
@ Loopaa
M-am grbit 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 calitile unui Product Manager de
succes ntr-o companie de IT.
Mai jos am reprodus dintre rspunsurile lor interesante:
nou);
n cadrul unei organizaii mari, un
Product Manager trebuie s construiasc inerie i for gravitaional n
jurul ideii pe care dorete s o dezvolte.
Pot s fac acest lucru prin testarea
ipotezelor i proiectelor ntr-o faz incipient, ncercnd s obin feedback bun
din rndul potenialilor clieni;
un product manager este traductor ntre CEO i membrii echipei.
Practic trebuie s comunice dorinele
ambelor pri pe limba fiecruia, dndule o form care s motiveze ambele pri
s se implice.
2. Care sunt calitile 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 uitm cnd angajm un

regulile jocului i s contientizeze Product Manager?
importana ctigului;
este o persoan plin de resurse;
acesta este un om de vnzri care
are convingeri puternice, pentru a
trebuie s-i vnd proiectele att intern
susine lucrurile n care crede, ns n
ctre membri echipei ct i ctre celelalte
acelai timp, n contradictoriu, este lippri interesate;
sit de ego i nu dorete recunoatere. Eu
Product Manageri-i stabiliesc o
a fi formulat altfel acest punct. Cred c
ierarhie a prioritilor i trebuie s ia
un Product Manager trebuie s fie un
deciziile cu privire la ce s dezvolte
om bun de vnzri, s tie s cumunice
i cnd s dezvolte (o funcionalitate
cu ncredere o idee, dar s fie dispus s
14
negocieze i s accepte opinii diferite;

este important ca un Product
este un bun psiholog, capabil s
Manager s creeze un cadru favorabil
neleag comportamentul uman al
lurii deciziilor n echip i colaborrii
colegilor de echip ct i al clienilor;
ntre membri;
nu i este fric s greeasc. Un
Product Manager bun i asum acest 2. Cum lucrezi cu o echip remote?
risc, nva din greeli i este pregtit s
echip cu membri la distan poate
renceap mereu de la capt;
funciona bine la nivel execuional, cu
are aptitudini tehnice sau cel puin
condiia ca s li se precizeze fiecruia
le nelege;
n mod clar ce s fac;
este o persoan cu care i face pl nu funcioneaz/nu este recomancere s pori o conversaie;
dat aceast metod de lucru pentru
are proiecte de succes anterioare;
startup-uri sau unde este nevoie de
nu uit puterea clienilor 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,
ntrebri din public:
fa n fa;
la final, se specific faptul c soluia
1. Cum trebuie un Product Manager s ofere
poate fi gsit n carteaReWork1.
Speakerii au vorbit din experien i s-a

vzut acest lucru. Am simit dorina s
mai rmn la eveniment, ns n-am reuit
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
ediia urmtoare Techsylvania?
feedback?
un Product Manager nu ofer nicioTimpul a zburat. Nu mi-a venit s cred

dat feedback personal. El nu este eful ct de repede a trecut. Mi-a plcut panelul.
i nu face evaluri 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 situaii, speci- d av id-heinemeier-hanss on-pub978-973-1931-77-7/p d/
ficnd ce funcioneaz i ce nu, oferind EYB260BBM/?ref=ps&emag_click_id=d7e084bdad01994d97e0b1
condiiile soluiei n echip;
0cc7d62e3a
15
comuniti
Comuniti IT
rincipalele evenimente din lunile urmtoare sunt din zona de Meetup-uri. Dei sunt restrnse, creeaz premisele unei mai
bune comunicri cu reprezentanii comunitii locale. Remarcm o cretere binevenit a evenimentelor ce au ca tema principal Java Script. V invitm s participai i s v alturai comunitilor locale.
Transylvania Java User Group

Comunitate dedicat tehnologiilor Java.
Website: www.transylvania-jug.org
Data nfiinrii: 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 nfiinrii: 06.02.2012 /Nr. Membri: 2424/Nr. Evenimente: 32
Cluj Business Analysts
Comunitate dedicat analizei de business
Website: www.meetup.com/Business-Analysts-Cluj
Cluj Mobile Developers
Comunitate dedicat tehnologiilor mobile
Website: www.meetup.com/Cluj-Mobile-Developers
The Cluj Napoca Agile Software Meetup Group
Comunitate dedicat metodelor Agile de dezvoltare software.
Website: www.agileworks.ro
Cluj Semantic WEB Meetup
Comunitate dedicat tehnologiilor semantice.
Website: www.meetup.com/Cluj-Semantic-WEB
Data nfiinrii: 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 nfiinrii: 10.02.2011 / Nr. Membri: 251/ Nr. Evenimente: 14
Tabra de testare
Comunitate format din testeri i ali profesioniti din industria
IT care, n cadrul unor ntlniri informale lunare, mprtesc
din cunotinele proprii i nva din experienele profesionale ale
celorlali membri.
Website: www.tabaradetestare.ro
Data nfiinrii: 15.01.2012/Nr. Membri: 1243/ Nr. Evenimente: 107
16
Calendar
Iunie 18 (Cluj)
Lansarea numrului 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 (Bucureti)
June BucharestJS Meetup
meetup.com/BucharestJS/events/222955233/
Iunie 25 (Timioara)
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)
Romnia digital
ccifer.ro/ro/
Iulie 7 (Cluj)
Top Notch Server-side Javascript
meetup.com/Cluj-JS/events/222611466/
Iulie 16 (Bucureti)
Bucharest Mobile Development Group
meetup.com/Bucharest-Mobile-Development-Meetup/
events/222785583/
Iulie 21 (Braov)
F.7 - The memorable experience - experience design and
gamification
meetup.com/bv-tech/events/219375720/
arhitectur
Arhitectura Conic
niversul este construit pe baza unui plan a crui 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 Romnia
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
aplicaii; reflect politicile din implementarea aplicaiei, abstraciile generale care
guverneaz ntreaga aplicaie; reprezint
conceptele care nu variaz cnd detaliile se
schimb.
Prin opoziie, modulele low level
se refer la partea de detalii. Acestea sunt
mecanismele tehnice generice care susin
modulele high level: logging, OOM, ORM,
e-mail, sms
destul de nefericite.
De zeci de ani folosim Layers pentru a
structura diverse aplicaii. 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
aplicm SOLID, dar de fapt nu o facem. n
cel mai bun caz, putem afirma c am aplicat
SOLI.
Cel puin n lumea .NET, Layers ncalc
DIP prin impunerea unei referine de la
assembly-urile high level ctre 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 cnd Layers nu face acest lucru.
Clean concentreaz cea mai important
parte a implementrii n partea central,
Patternul traditional Layers ncalc DIP externaliznd toate detaliile.
i, din cauza aceasta, implic nite consecine
Principiul care face ca acest model s
17
arhitectur
Arhitectura Conic
funcioneze este numit regula dependenei: Dependentele n mod mult mai natural cnd 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
definiie mult mai pragmatic a DIP.
s vezi pdurea, n ciuda copacilor.
Este vorba numai despre regula dependenei?
Explicarea titlului
Dac v imaginai un model asimetric ce deriv din structura

Dup prerea mea, Cone Architectureeste doar o metafor
Layers clasic, dar care se conformeaz DIP, acesta ar arta cam mai expresiv pentru acest tip de structura software. Da, eu am
aa:
inventat termenul sta.
Este vorba despre dou perspective diferite: dac te uii de
sus, vei vedea nite cercuri concentrice guvernate de regula
dependenei, care afirm c dependenele n cod pot fi orientate
doar spre interior. Acesta este un punct de vedere strict tehnic.
Dar dac priveti structura dintr-o parte, poi s vezi foarte
clar ce vrea s spun DIP prin module high level i module
low level. Poi acum s faci deduci mult mai uor ierarhia straturilor dup nivelul lor de abstracie. Cercurile interioare sunt de
nivel mai nalt dect cele exterioare.
Sgeile reprezint dependine 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 implementrii unei aplicaii. Acesta este centrul aplicaiei
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 aplicaiei, framework-ul de livrare nu este cu nimic mai
special dect 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 ntrzierea deciziilor legate de tehnologii vine n
18
management
S batem palma asupra soluiilor n

proiectele software
Raluca Radu
raluca.radu@betfair.com
Product Owner
@ Betfair
ntr-o lume dinamic, n care obiectivele de business se schimb n funcie de tendinele

din domeniu i de mereu fluctuantul interes al consumatorilor, nelegerea cerinelor de
ctre cei ce le formuleaz i de ctre cei care le implementeaz reprezint cheia succesului n proiectele de dezvoltare a produselor software. Nenelegerea, proasta interpretare a
cerinelor, implementarea defectuoas care genereaz deraierea proiectelor, costuri suplimentare i defecte descoperite prea trziu, au ca rezultat un produs implementat care nu folosete
nevoii din care s-a nscut. Exist prea multe cazuri de funcionaliti costisitoare neutilizabile
sau care nu-i justific costul.
Ca o soluie la problema nenelegerii sau
a slabei comunicri a cerinelor de produs,
metoda shake hands aduce nu un rspuns
definitiv ci o cale spre continua mbuntire
a formulrii i comunicrii cerinelor i a oferiri soluiilor viabile pentru a ndeplini aceste
cerine. Avem i ali termeni care s descrie
aceast metod precum signing-off , handing-over sau validarea cerinelor/soluiei.
Muli dintre noi fac asta implicit la fiecare
discuie 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
soluii eficiente. Mai pe scurt devine esenial
ajungerea la un acord asupra soluiilor propuse ntre cei ce formuleaz cerinele i cei
care le ndeplinesc.
Pentru facilitarea implementrii soluiei
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 interaciunilor dintre sisteme, diagrame arhitecturale, etc. . Voi descrie mai
jos cteva dintre aceste artefacte folosite i n
proiectele la care am avut norocul s lucrez.

Voi insista asupra beneficiilor comunicrii ntre cei ce formuleaz cerinele (clieni,
stakeholder, product manager-i, product
owner-i, business analiti, etc.) i cei ce le
implementeaz (arhiteci, tech leads, delivery
manageri, echipe de implementare, echipe
SCRUM, etc.).
POC sau Proof of concept reprezint o
demonstraie cu scopul de a verifica faptul
c anumite concepte sau teorii au potenial
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 diferii participani; poate, de
asemenea, s ofere soluii pariale implicnd
un numr mai mic de utilizatori acionnd
n roluri de business pentru a stabili dac un
sistem satisface anumite cerine de produs.
Astfel obiectivul principal al POC-ului este
de a gsi soluii la probleme tehnice, cum ar
fi modul n care sistemele pot fi integrate sau
cum ar fi obinerea de datele printr-o anumit configurare.
Acum civa ani lucram pentru o companie de software ce aciona pe piaa de
19
management
S batem palma asupra soluiilor n proiectele software
outsourcing, unde un client destul de
mare al acestei companii avea nevoie de
o funcionalitate complex ce necesit
mai multe echipe de development i mai
multe luni de munc. Pentru a ne asigura
c am neles corect cerinele am decis s
ncepem un POC cu acordul clienilor. A
fost un succes, clienii au vzut un prototip al soluiei ce urma s le serveasc
scopul, am descoperit lipsuri n cerine,
pe care altfel le-am fi descoperit mult
prea trziu n procesul de dezvoltare. Am
schimbat chiar prerea clienilor cu privire
la importana unor cerine, iar la altele am
renunat cu totul. POC-ul a ajutat la comunicarea dintre noi i clieni, noi fiind cei
care implementm soluia. Ne-am simit
owner-i pe soluia propus mai ales avnd
acordul deplin al clienilor.
Prototyping and design reprezint
crearea de interfee interactive care s prezinte vizual funcionaliti. Este o metod
des folosit att n lumea online-ului ct
i n reprezentarea oricrui produs fie el
fizic sau virtual fr a fi totui necesar
construcia per se a acestuia. O aplicaie
folosit n prototyping este de exemplu
Axure, ct despre design, aceasta se face
cel mai adesea n Adobe Photoshop. Exist
pe pia o multitudine de astfel de aplicaii,
ns indiferent de ele, importana crerii de
prototipuri i de designe st n impactul
vizual. Oamenii percep mai bine ceva ce
pot s vad cu proprii ochi, par s neleag
mult mai bine, cnd li se pune n fa un
model cu care pot interaciona. La fel i
20
clienii sau stakeholderi-i relaioneaz mult

mai bine cu o interfa interactiv care s
le permit nelegerea 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 prerea stakeholderilor cu privire la deciziile de produs. Ca
Product Owner folosesc acest artefact ori
de cte ori pot, pentru a obine o nelegere
ct mai bun a soluiei ce urmeaz a fi
implementat, pentru ca stakeholder-ii
proiectelor respective s beneficieze de
ceea ce au nevoie i pentru ca acetia s
fie mereu la curent cu propunerile de a
mbunti 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 soluiilor ce vor implementa produsul necesar conform cerinelor. Prin
folosirea lor ne putem asigura de o tranziie
mult mai lin i sntoas de la cerine la

produsul final, trecnd prin toate procesele
de rafinare a cerinelor, de transmitere a
acestora i n final de implementare i testare. Atunci cnd cerinele sunt nelese i
de o parte i de cealalt n mod uniform i
cnd soluia de implementare e universal
acceptat de ctre prile implicate, doar
atunci poate s existe sigurana c produsul ndeplinete nevoile reale i le satisface
printr-o implementare la obiect.
programare
Model Driven Design

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 Romnia
Primul subiect supus discuiei: ce este un

model? Conceptul de Model ct i modul
n care acesta conduce spre o soluie sunt,
n continuare, supuse unor discuii. Din
acest motiv, exist mai multe definiii 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 clarificm anumite
aspecte legate de terminologia format n
jurul conceptului de Model.
Concepte
Orice software soluioneaz o problem
a clientului. Aceast problem poate fi
mprit 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 folosete noiunea
de domeniu al problemei, termen de ansamblu, care reflect una sau mai multe zone de
interes.
n tiina 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 funcie de domeniul de interes. Aceasta se
realizeaz prin extragerea conceptelor cheie
ale subproblemelor i legndu-le mpreun.
La sfritul acestui proces, vom vedeam o
perspectiv mai uoar de neles a problemei
i poteniala ei soluie.
Bazndu-ne pe acest model al domeniului, noi descriem modelul conceptual
(numit pe scurt model) care propune o
posibil soluie a problemei. Modelul conceptual este o abstractizare bazat pe conceptele
i relaiile formate din modelul domeniului.
Modelul devine o abstractizare a unui
sistem fizic, n care programatorul va descrie
diferite entiti, atributele lor, relaiile i
constrngerile dintre entiti. Acesta, de
asemenea, creeaz o perspectiv structural
asupra soluiei n care accentul este pus pe
ceea ce e important, ignornd detaliile.
Despre Model driven design/model driven

architecture
Exist mai multe preri 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)
21
programare
Model Driven Design de la teorie la practic
un consoriu de organizaii software care dezvolt i susin
specificaii, pentru a mbunti 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 aplicaia), de deciziile orientate pe software (cum face
aplicaia), folosind o abordare a specificaiilor de sistem, bazat
pe utilizarea modelelor formale. [1]
MDA folosete modele pentru descrierea businessului
(funcionalitii) soluiei, independent de orice constrngere de
sistem (decizii orientate ctre software).
n MDA, Modelele independente de platform sunt exprimate ntr-un limbaj de modelare independent de platform. Pe
scurt, modelul este descris n funcie de specificaie, 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 influenat de viziunea dat
de ctre 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. Modificrile sunt propagate bidirecional 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 constrngeri specifice domeniului i realizeaz verificarea
modelului. [2]
Din acest motiv, Model-driven software development este
un mijloc prin care se pot dezvolta aplicaii descrise printr-o
Model Driven Architecture. Model-driven software development
este format din:
Domain-specific modeling language (DSML) modele i
meta-modele n care relaia dintre conceptele dintr-un domeniu, constrngerile i semantic sunt definite (aici se descriu
modelele);
Motor de transformare i generatori pregtete artefacte
(cod surs) ntr-un proces automatic/semi-automatic (aici se potenial soluie 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 consistena
conceptual a arhitecturii, dar i ajut la dezvoltarea funcional
a aplicaiei. Capacitatea de a sintetiza artefacte din modele contribuie la asigurarea coerenei ntre implementarea aplicaiilor
i analiza informaiilor asociate cu cerinele funcionale i QoS,
cerine surprinse de ctre 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 soluia
poate fi inspirat i din alte proiecte, sau la rndul ei, poate s fie
sursa de inspiraie pentru alte proiecte. Aceasta duce la refolosirea
soluiilor prin transformarea modelului ntr-un alt model conceptual specific unui alt domeniu. Aceast abordare este susinut de
ctre OMG i reflect unul din cele patru principii de la MDA[1].
Acestea sunt piesele pe care se creeaz aplicaii Model Driven.
Pentru a ilustra cum funcioneaz, vom descrie o Problem i o
22
Presupunem urmtorul scenariu dintr-un domeniu tehnic:

Clientul nostru folosete ca Interfa grafic o versiune particularizat a aplicaiei Eclipse Rich Client Platform (Eclipse RCP). n
acest versiune, denumit myRCP, el dorete s ruleze o serie de
aplicaii, cu diferite scopuri.
Noua noastr aplicaie trebuie s ruleze n aceast versiune
particularizat de RCP ca o perspectiv nou.
Tranzaciile de business sunt realizate de ctre un Application
server.
Pentru a oferi un framework comun ntre toate aceste aplicaii,
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: Aplicaia va rula ntr-un soft particularizat. Acest soft conine un set propriu de contracte (interfee)
pentru toate Obiectele i ofer un set de instruciuni particularizate pentru afiarea elementelor vizuale. Acest software este
n continu schimbare i aplicaia noastr trebuie s se schimbe

odat cu ea.
Vom separa funcionalitile de business (manipularea obiectelor) de funcionalitile de afiare. Prin aceasta vom crea dou
componente: componenta RCP i componenta de business.
Componenta RCP va conine orice topic legat de elementele
vizuale, managementul aciuniilor i orice alt interaciune cu
utilizatorul, n timp ce componenta de business se va ocupa de
toate topicurile legate de managementul aciunilor i funciilor
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 funcie de
nevoie). Acest model se va ocupa de toate topic-urile din domeniul
tehnic ct i de domeniul de business al aplicaiei. n acest fel, modelul nostru poate oferii o perspectiv att tehnic i funcional.
Motivaie
Interfeele serviciilor de business (comune ntre RCP i

Application Server) vor fi generate, dar funcionalitatea 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 aplicaiei. Aceste modele vor oferi o perspectiv
actual i precis asupra aplicaiei.
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 acelai timp pot fi uor adaptate la
nevoile individuale. [4]
Xtext ofer un mod simplu de proiectare a unui limbaj specific domeniului. Dup ce arhitectul descrie gramatica folosit
de ctre limbajul specific domeniului, xtext va genera un parser.
Acest parser va fi folosit n implementarea descrierii Modelului
Conceptual. Programatorul va descrie modelul conceptual n
fiierele DSML, folosindu-se de parser-ul generat, concentrnduse numai asupra ceea ce este esenial pentru businessul soluiei i
nu asupra implementrii.
Xtext ofer suport Eclipse i o serie de instrumente folosite
n dezvoltarea gramaticilor i a modelelor precum: asisten de
coninut, validare i quick-fix, integrare avansat Java, integrare
cu alte instrumente Eclipse, etc. .
Folosind parser-ul n definirea modelelor, asigurm respectarea celor patru principii ale MDA. Exemplu [1]:
a. Modelul este descris ntr-o notaie bine definit;
b. Sistemul este organizat n jurul unui set de modele care
accept transformri;
c. Existena unui meta-model : gramatica Xtext;
d. Xtext este un framework open source.
Componenta RCP este dezvoltat ntr-un framework personalizat myRCP. Acest framework definete cum sunt afiate
elementele grafice n RCP, mpreun cu acinile dintre aceste
componente.
Acest lucru ridic unele probleme legate de ciclul de implementare. Orice developer va trebui s nvee acest framework
personalizat i (probabil) framework-ul RCP. Pentru a evita
acest impediment, vom modela toate elementele din interfaa 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
ateptat. 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 (aa cum este cerut de
ctre frameworkul myRCP) i va conine 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
ateptat. Aceasta se realizeaz prin mprirea perspectivei n editoare i view-uri. Aceste editoare vor conine sub-editoare i/sau
elemente de control grafice.
S lum urmtorul exemplu din LDAP Studio (C):
Pentru a reduce sarcina de implementare, DTO-urile,

Interfeele serviciilor de business, obiectele de business i relaiile
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
23
programare
Model Driven Design de la teorie la practic
Zona principal a aplicaiei este perspectiva 1. Fiecare perspectiv conine cel puin un editor i poate conine i view-uri.
Fiecare editor conine sub-editoare, paragrafe i/sau elemente de
control grafice. Fiecare paragraf conine diferite elemente de control grafice.
Modelul trebuie s fie cababil s descrie toate aceste elemente
i interaciunea dintre ele. Cu Xtext noi vom descrie componentele i obiectele de business cu care lucreaz.
S lum urmtorul 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 funcionalitatea, folosind un cuvnt cheie custom la sfritul 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;
}
entity DescriptionEntity {

attributeDescription : String;

value : String;
}
dto EntryDTO link Entry {

link descriptionDTO : listof DescriptionDTO;
}
Servicii de Busines:
service

}
EntryService {
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. Interaciunea dintre componente este descris cu ajutorul unui element behavior, unde Meta-modelul
funcionalitatea businessului va fi dezvoltat.
Acum c am definit limbajul de modelare specific domeniului,
urmtorul pas const n definirea meta-modelului i frameworkBehavior EntryEditorBehaviours {
ului de generare de cod.


Load

Save

customAction changeColorField

customServerAction EntryService.
deleteField(descriptionDTO.attributeDescription)
}
Modelul conceptual descrie comportamentul. Operaiile de

Load i Save sunt comportamente standard i codul generat va
conine o implementare standard. Aceast implementare este
comun tuturor obiectelor de business, iar identificarea obiectelor se face prin DTOs.
Cuvntul customAction descrie o aciune particular RCP.
Aici modelul conceptual prezint un comportament, dar las
sarcina implementrii programatorului. Codul surs final va fi
generat parial i programatorul va primi o definiie de metod
unde el trebuie s decid particularitile implementrii.
Practic, modelul ofer o serie de comportamente comune, iar
dac acestea nu sunt suficiente, las la latitudinea programatorului s defineasc noi aciuni particularizate.
Operaia de deleteField este un apel la componenta de business, care ofer o anumit funcionalitate. Pentru a folosi aceast
funcionalitate, programatorul va lega aciunea la un buton specific. Apelul va fi fcut ctre server, iar rezultatul aciunii va fi vizibil
ntr-o zon specific.
Table EntryDescriptionTable {
. . .
columns {
. . .
}
button buttonName action EntryService.
24
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 ambiguiti 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 cnd 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 poteniale probleme.
Un exemplu dintr-un editor in GuiDSML:
Editor EntryEditor opensIn MainEditor {

Title Titles.EntryEditor

Behavior EntryEditorBehaviours


paragraphs{

}
}
submenu DN
table EntryDescriptionTable
Editorul descris n gramatica meta-modelului

Editor :
editorname=GUI_IDopensIn
EditorComponent=EDITOR_ID{

title title=[Titles::TitleElement]

(behaviorservice=[dm::BusinessService])?

(readOnlyservice=[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 conin un
name i un EditorComponent. Dup ce acolada este deschis,
Xtext ateapt un title. Elementele behavior i readOnly
sunt marcate ca fiind opionale, semnul parantezei.
Folosind gramatica rezultat, xtext genereaz un parser
metamodelul aplicaiei. Acesta verific dac modelele GuiDSML
au fost corect construite, comparndu-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

Pn n acest punct, toate deciziile au fost independente de
platforma de dezvoltare. Aici modelarea ajunge la capt i codul
rezultat este produs.
n acest exemplu, noi folosim unul dintre instrumentele de
generare oferite de ctre 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 ctre elementele DEFINE/ EXPAND. Spre exemplu, definiia 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 fiiere jar i trimise ctre proiectele care le
folosesc. Clasele generate parial sunt generate o singur dat o
nou generare a ntregului model nu va rescrie clasa deja implementat. Aceste clase sunt parial scrise de mn, procesul de
generare a codului surs nu trebuie s suprascrie codul adugat
manual.
Xpand este o soluie bun pentru generarea obiectelor RCP,
dar pentru o abordare mai general, recomand folosirea limbajului Xtend. Este mai flexibil i mai uor 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 schimbri dac este necesar i n funcie de modificarea domeniului
problemei.
Acest articol este doar o prezentare general a unei aplicaii
proiectate folosind dezvoltare software model-driven. Dac fiecare
domeniu problem este diferit, atunci fiecare model conceptual
va fi diferit. Pentru mai multe informaii recomand citirea articolelor din zona de referin i s ncercai unele dintre instrumente
folosite n MDD [8].
Referine
[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/
25
programare
Ce este de fapt TDD?
in cnd n cnd, particip la discuii cu diveri oameni despre ce este de fapt

TDD de fapt. Deoarece am dobndit n timp o anumit cunoatere a acetui
subiect, care se datoreaz nu numai utilizrii, dar i datorit faptului c l explic
altora, am hotrt s scriu acest articol care detaliaz punctul meu de vedere n legtur
cu ce este TDD. Sper c l vei gsi util.
Alexandru Bolboac
alex.bolboaca@mozaicworks.com
Agile Coach and Trainer, with a
focus on technical practices
@Mozaic Works
26
Prezentul articol l continu pe cel din deja testat. Dezvoltatorul poate totui s
numrul trecut al revistei Today Software introduc erori dac problema nu a fost
Magazine pe aceast tem.
neleas 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, rspunsul este nu. Logic este
comportamentul ateptat al soluiei. Cnd s spui:
testele sunt trecute, o alt bucic a proCalitatea designului depinde de
blemei este soluionat. Noi tocmai am abilitile designerului.
creat intenionat o bucat de cod care
TDD n sine nu va produce design
rezolv o problem. Acesta este design.
bun. Produce ntr-adevr design cu anuDar oare este un design bun? Aceasta mite caliti, dar depinde de dezvoltator s
este o discuie interesant. Pentru a rs- duc asta mai departe.
punde la ntrebare, ar trebui s ne uitm
Dar
la calitile designului, pe care TDD ne
oblig s le dezvoltm. Iat dou dintre ele: Cnd se concepe design n TDD?
Testabilitate evident, deoarece codul
Este acum momentul s introducem
este testat.
nc un aspect al designului software.
Rezistena la greeli exist o proba- Scrierea codului nu este suficient; este
bilitate mai mic de a introduce greeli important s structurezi codul ntr-un
atunci cnd modifici codul care a fost anumit mod. Cea mai puin 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 psa, dar acest lucru va
afecta calitile designului.
Atunci cnd 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 calitile sale. Denumirea unei variabile
prin litera a o va face mai puin lizibil dect dac o numim
sumDeBani (amountOfMoney). Adugarea a 10 straturi va
face codul mai dificil de neles dect utilizarea a numai dou
starturi. O clas cu 10 colaboratori este mai dificil de neles dect
o clas cu trei colaboratori.
Cnd lum aceste hotrri? ntotdeauna! Mai precis:
La nceput. De exemplu, utilizarea unui cadru web MVC
nseamn deja s respeci anumite constrngeri legate de structura codului.
Cnd scrii testul: numele clasei supuse testului.
Cnd scrii codul: numele metodelor private, membrii de
prob sau variabile locale.
Cnd reutilizm codul: extragerea unei metode, extragerea
unei clase sau simpla redenumire a ceva.
mbuntirea calitilor 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 puin cnd l reutilizm. Aciunea de a concepe este intenionat: noi ncercm s mbuntim calitile
de design care sunt relevante n contextul nostru (n mod tipic,
modificabilitatea). Incremental mai nseamn, de asemenea, c
soluia crete pas cu pas, prin tierea 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 numr i aa mai departe.
Acest proces este foarte asemntor cu un altul: soluionarea
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 dect o metod de a concepe software ntr-o manier
incremental?
Cititorii mai familiarizai i vor aminti probabil c TDD a
fost adesea discutat n contextul designului emergent. Eu cred
c exist o problem legat de denumirea emergent: muli
dezvoltatori pe care i-am ntlnit au tendina s considere c
design emergent nseamn un design care apare din senin
datorit procesului. Bineneles, aceast accepie poate crea
confuzii. Eu pledez pentru utilizarea termenului incremental
pentru o mai bun descriere a procesului.
Iar aceasta nu e tot

Acest articol s-a concentrat pe utilizarea cea mai comun a
TDD. Lucrurile sunt puin mai complicate, deoarece exist un
numr surprinztor de moduri de a utiliza testele i TDD. Iat
cteva exemple avansate, nici ntr-un caz o list complet:
Eu am utilizat TDD, n trecut, pentru a explora alternative
de design: rezolv aceeai problem cu constrngeri 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 nva lucruri noi. Eu am
folosit TDD cu succes pentru a preda n trecut limbajele de programare unor oameni fr pregtire n domeniu.
TDD poate fi utilizat pentru a explora spaiul problem. De
exemplu, dac lum Game of Life (Jocul vieii) 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 acelai exerciiu i cu aplicaiile de afaceri pe care le dezvolt.
Uneori utilizez TDD pentru a explora potenialele modificri ale
caracteristicilor.
ntr-o alt categorie, TDD As If You Meant It (ca i cum ai
fi vrut asta) este un exerciiu bazat pe TDD dar cu constrngeri
suplimentare care ntrzie toate deciziile legate de structurarea
codului, pentru ct 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 exerciiu intrigant, dar nu l utilizez niciodat n
producie.
ntrebrile i comentariile voastre sunt binevenite; v rog nu
ezitai s i scriei pe alex.bolboaca@mozaicworks.com.
27
programare
Fault-Tolerant Microservices
cu Netflix Hystrix
Radu Butnaru
rbutnaru@sdl.com
Senior Developer
@ SDL
cest articol continu seria destinat solutiilor aplicate intr-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 ctre compania Netflix.
Hystrix ofer o implementare matur a pattern-ului Circuit Breaker, al crui scop este
s reduc impactul defectrilor i al timpilor mari de laten n sisteme distribuite.
Problema
O caracteristic principal a sistemelor construite pe baz de microservicii
este utilizarea unui numr mare de componente distribuite. Pe msur ce numrul
de interaciuni sincrone prin reea crete,
impactul unei defectri a unui serviciu
poate deveni din ce n ce mai sever.
Enumerm cteva din cazurile cele
mai frecvente de comportament anormal
ale unui serviciu:
serviciul nu mai rspunde (serviciul
este oprit sau reeaua nu funcioneaz);
apelul de serviciu dureaz prea mult;
apelul de serviciu returneaz erori.
Fr mecanisme de protecie, erorile
i n mod special timpii mari de laten se
vor propaga ctre clienii serviciului, unde
se va putea ajunge n situaia 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
dependene defecte, dei restul serviciilor
28
de care depinde, funcioneaz corect.
Soluia
Un Circuit Breaker (rom. ntreruptor
de circuit) este folosit pentru a intermedia
operaiile prin reea dintre un client i un
serviciu. Circuit Breaker-ul monitorizeaz
i detecteaz cnd serviciul invocat se
comport anormal, respingnd apelurile
ctre serviciu pn cnd acesta va deveni
funcional din nou. ntorcnd o eroare
imediat, se previne epuizarea resurselor din procesul client. n acelai timp,
se reduce ncrcarea serviciului invocat,

crescnd astfel ansele ca acesta s i revin din condiia defect. ...
n seciunile 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 ctre serviciu prin efectuarea tuturor apelurilor prin intermediul unui Circuit Breaker (aceasta se
realizeaz la nivel de cod prin extinderea de clase Hystrix sau
prin adnotri - detalii n cele ce urmeaz). Circuit Breaker-ul va
intercepta i monitoriza toate apelurile i va aciona n cazul unor
condiii de eroare, efectund tranziiile de stare descrise mai jos.
Starea nchis
n cazul de funcionare normal cnd nu exist condiii de
eroare, Circuit Breaker-ul este n starea nchis. Toate apelurile
sunt transmise n mod transparent ctre 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 urmtoarele condiii drept
protected List<Product> run() throws Exception {
simptome ale unei defectri i le va lua n calcul pentru a decide
// Apel serviciu HTTP
ResponseEntity<Product[]> responseEntity =
ntreruperea circuitului:
restTemplate.getForEntity(
O excepie 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 dect 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 execuia datorit capacitii depite.
Hystrix folosete pool-uri de thread-uri pentru a limita numPentru a invoca clasa comand, ea trebuie instaniat 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 excepii (comportamentul implicit, denumit i fail fast),
opional, 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 excepii

atunci cnd 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 condiia de eroare, atunci

cnd Circuit Breaker-ul se afl n starea deschis, el va permite n
mod periodic cte un apel, la un interval configurabil (implicit, 5
secunde) - aceasta este starea semi-deschis. Dac apelul se efecn cazul n care un anumit tip de eroare este consitueaz cu succes, circuitul se va nchide din nou.
derat comportament ateptat/tratabil (de ex. validri de
logic business), tipul excepiei ntoarse trebuie s fie
Folosire
HystrixBadRequestException. n caz contrar, excepia
Vom prezenta dou modaliti 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.
API Hystrix direct

Pentru a folosi biblioteca Hystrix, trebuie adugat urmtoare
dependin n proiectul Maven:
...
} catch (IllegalArgumentException e) {
// Dac se ntoarce HystrixBadRequestException,
// Circuit Breaker-ul nu se va deschide
throw new HystrixBadRequestException(
Bad request., e);
29
programare
Fault-Tolerant Microservices cu Netflix Hystrix
}
...
Valorile specifice de configurri (timpi de expirare, capacitatea pool-ului de thread-uri, praguri procentuale de eroare, etc.),
pot fi atribuite programatic la momentul instanierii 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 configurri se poate folosi biblioteca Netflix

Archaius.
...
@HystrixCommand(fallbackMethod = defaultProducts)
public List<Product> findAllProducts() {
...
}
public List<Product> defaultProducts() {
return Collections.emptyList();
}
...
Dac se dorete ca un anumit tip de excepie s nu fie considerat simptom al unei defectri, tipul excepiei trebuie menionat
n adnotare:
...
@HystrixCommand(ignoreExceptions = {IllegalArgumentException.class})
...
}
...
Pentru configurri (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 fiierul
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 interfee 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 adugat urmtoarea 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, adugm adnotarea EnableCircuitBreaker pe

clasa principal de configurare Spring Boot:
Monitorizare cu Hystrix Dashboard / Turbine
Hystrix ofer suport pentru vizualizarea i monitorizarea
...
@EnableCircuitBreaker
strii curente a Circuit Breaker-elor prin trimiterea continu de
public class HystrixClientDemoApp {
msurtori ctre o aplicaie web tip panou de comand: Hystrix
...
}
Dashboard2. Pentru scenarii cu servere multiple (cluster) Hystrix
ofer posibilitatea de a trimite msurtorile 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
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 excepii

atunci cnd Circuit Breaker-ul este deschis, trebuie menionat
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
3 https://github.com/Netflix/Turbine

Circuit Breaker nchis
impact mai redus asupra codului de proiect.
Bibliografie
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Circuit Breaker Deschis

Urmtoarele msurtori sunt artate i actualizate n timp
real:
Indicatori privind starea de sntate i volumul de trafic;
Rata de cereri (la nivel de server i cluster);
Procentul de erori i contoare (apeluri cu succes, apeluri
respinse, expirri thread-uri, respingeri din cauza capacitii
pool-ului de thread-uri, erori/excepii) 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 documentaia

necesar interpretrii 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 adnotri, 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
31
programare
Dnu Chindri
n numrul 31 al revistei am fcut o introducere n ceea ce privete subiectul

Internet of Things din perspectiva platformei Java. Aa cum am promis, vom continua aceast discuie prezentnd detaliile crerii 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 - specificaie care definete
un mediu puternic i flexibil pentru sisteme embedded de dimensiuni reduse. Alturi
de acestea, trebuie s remarcm alinierea platformei despre care discutm la Java SE 8.
Java Developer
@ Elektrobit Automotive
Tooling pentru aplicaii ME - Oracle Java ME

SDK 8.1
danut.chindris@elektrobit.com
Aplicaiile Micro Edition pot fi dezvoltate att manual ct i cu ajutorul unui SDK
specializat, cunoscut sub numele Oracle
Java ME SDK 8.1. SDK-ul, distribuia Java
ME, documentaia i orice alte resurse
mai sunt necesare dezvoltrii aplicaiilor
embedded, se gsesc la adresa Oracle destinat platformei.
nainte de a ncepe s dezvoltm
aplicaii embedded, Oracle recomand n
primul rnd instalarea Oracle Java ME
SDK 8.1 - pachet software care la momentul scrierii acestui articol este disponibil
doar pentru sistemul de operare Windows.
Urmtorul pas este descrcarea distribuiei
Java ME Embedded 8 destinat dispozitivului pe care dorim s rulm aplicaiile.
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 pstrarea unei copii
pe sistemul desktop, unde se va executa
dezvoltarea aplicaiilor. Acest ultim pas
nu este obligatoriu, ns este recomandat
pentru cazul n care dezvoltatorul dorete
s execute comenzi pe dispozitiv cu ajutorul AMS CLI (Application Management
System Command Line), prin intermediul
programului Developer Agent.
Prima noastr aplicaie Java ME

Odat ce am instalat SDK-ul i Java
ME, putem s ncepem dezvoltarea unei
aplicaii embedded. Sub forma ei cea mai
simpl, o astfel de aplicaie trebuie s
32
conin o clas care extinde clasa abstract

javax.microedition.midlet.
MIDlet, un fiier manifest i un fiier
JAD (Java Application Descriptor). Am
putea scrie o astfel de aplicaie manual,
fr ajutorul unui IDE, care s automatizeze anumii pai. Acesta este un bun
exerciiu pentru dezvoltatorul care intr
pentru prima dat n contact cu Java ME
Embedded 8. Astfel, ne propunem s
crem o simpl aplicaie, care afieaz n
consol un mesaj la pornirea aplicaiei i
unul la oprirea acesteia.
n primul rnd, crem o clas care
extinde javax.microedition.
midlet.MIDlet, implementnd 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 aceeai manier,

compilm 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
Observm c avem nevoie de biblioteca meep_8.0.jar la compilare,

ntruct aceasta definete clasa abstract
. Aceast bibliotec se gsete n directorul %JAVA_ME_SDK%\lib, unde
%JAVA_ME_SDK% reprezint calea unde a fost instalat SDK-ul.

Mesajul Hello MIDlet este afiat la pornirea MIDlet-ului,
Urmtorul pas l reprezint crearea fiierului manifest, care iar mesajul Goodbye MIDlet la oprirea acestuia, cu ajutorul
trebuie s conin cel puin urmtoarele informaii:
combinaiei 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
Presupunnd c am salvat fiierul manifest cu numele , putem

trece la urmtorul pas, care este crearea arhivei JAR. Aceast
arhiv trebuie s conin clasa compilat i fiierul manifest.
Realizm aceasta lansnd n execuie urmtoarea comand:
jar cfm build\Hello.jar MANIFEST.MF -C classes .
Odat ce am creat fiierul , pentru aceast aplicaie mai avem

nevoie de un singur lucru, i anume descriptorul aplicaiei, cunoscut i sub numele de fiier JAD (Java Application Descriptor).
Acesta se aseamn cu fiierul manifest, coninnd urmtoarele
linii obligatorii:
Rularea aplicaiei pe dispozitiv

O alt modalitate de a rula aplicaia este prin instalarea acesteia pe dispozitivul int. Pentru acest articol am folosit o plcu
de dezvoltare Raspberry PI Model B+, dotat cu un dongle Wi-Fi.
De asemenea, menionm faptul c platforma are deja instalat
un sistem de operare Linux, ceea ce faciliteaz munca noastr cu
acest hardware. Avnd aceast configuraie la ndemn putem
accesa de la distan sistemul Raspberry PI, cu ajutorul unui program precum PuTTY.
Accesm plcua cunoscndu-i IP-ul i un user cu drepturi de root. Odat ce ne-am autentificat, schimbm directorul
curent, pentru a ne situa n directorul bin al distribuiei Java
ME Embedded 8 instalat. Acest lucru este ilustrat n urmtoarea
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
Observm c unul dintre atributele obligatorii ale fiierului

JAD este dimensiunea n bytes a arhivei. Salvm acest fiier cu
numele n acelai director cu arhiva JAR.
Rularea aplicaiei cu un emulator

n acest moment avem o aplicaie Java ME Embedded 8
complet, pe care o putem lansa n execuie. Cea mai simpl
modalitate pentru a face acest lucru este folosirea emulatorului
pe care ni-l pune la dispoziie SDK-ul. Presupunnd c directorul
curent este directorul al proiectului nostru, putem lansa urmtoarea comand:
emulator -Xdevice:EmbeddedDevice1
-Xdescriptor:Hello.jad
Cu ajutorul opiunii -Xdevice specificm numele dispozitivului pe care dorim s rulm aplicaia. EmbeddedDevice
este un dispozitiv emulat, configurat automat n momentul n
care instalm SDK-ul. Prin intermediul celei de-a doua opiuni
prezente n comanda pe care am executat-o -Xdescriptor
specificm locaia i numele descriptorului aplicaiei noastre.
Putem observa rezultatul rulrii aplicaiei n urmtoarea
figur:
Accesarea plcuei de dezvoltare cu PuTTY
Figura ne arat faptul c urmtorul 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 execuie Java
runtime, care permite accesul la AMS. Platforma ascult pe portul
2201 i ne permite s ne conectm de la distan pentru a face
managementul aplicaiilor ME.
nainte de a putea continua, trebuie s nregistrm dispozitivul cu ajutorul aplicaiei Device Connections Manager. De vreme
ce avem instalat SDK-ul, ar trebui s gsim n SysTray o iconi
intitulat Oracle Java(TM) ME SDK 8.1 Device Manager. Fcnd
click pe aceasta, deschidem managerul de conexiuni, unde putem
aduga plcua noastr, pe care o identificm dup IP. Odat ce
am nregistrat dispozitivul, ar trebui s avem n fereastra activ
ceva similar figurii urmtoare:
nregistrarea unui dispozitiv
Aplicaia Hello n emulator
Acum putem instala pe Raspberry PI aplicaia pe care am creato ntr-o seciune anterioar. Avem la dispoziie cteva modaliti
pentru a face aceasta, una dintre ele fiind cu ajutorul utilitarului
Device Selector, care este la dispoziia noastr, bineneles, datorit
33
programare
faptului c am instalat SDK-ul. Deschiznd aceast aplicaie,
observm o list cu toate dispozitivele instalate la momentul
curent. Predefinit, avem la dispoziie trei dispozitive emulate:
EmbeddedDevice1, EmbeddedDevice2 i Qualcomm_IoE_Device.
Alturi de acestea, putem vedea plcua Raspberry PI, pe care
tocmai am nregistrat-o, cu numele EmbeddedExternalDevice1.
Dorim s rulm aplicaia Hello pe acest dispozitiv, aa c facem
click-dreapta i alegem Run JAR or JAD, dup cum este ilustrat
i n figura urmtoare:
Observm faptul c n captura de ecran anterioar este listat i

mesajul care trebuie afiat la distrugerea aplicaiei. Aceasta pentru
c nainte de a face captura am apsat butonul Remove, prezent n
interfaa aplicaiei de management.
Aadar, oricare ar fi modalitatea aleas pentru a rula aplicaii
Java ME Embedded 8 fie pe dispozitive, fie ntr-un emulator,
acesta este un proces relativ facil. Mai exist o cale de a rula
aplicaii 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 urmrit paii crerii, instalrii i rulrii unei aplicaii minimale, efectund manual fiecare
sarcin. Totui, platforma ne pune la dispoziie o serie de unelte
care vin n ntmpinarea nevoilor dezvoltatorilor i intesc sporirea productivitii acestora. ntr-un articol viitor ne propunem
s prezentm procesul dintr-o alt perspectiv, automatizat cu
ajutorul acestor unelte.
Concluzii
Dezvoltarea aplicaiilor Java ME Embedded 8 poate fi un
proces interesant i distractiv, dar uneori dificil i frustrant. Din
pcate, materialele de studiu dedicate Java ME Embedded 8 sunt
puine. Pn n momentul de fa exist o singur carte publicat care abordeaz subiectul dezvoltrii aplicaiilor Java ME
Embedded 8. De asemenea, majoritatea articolelor existente pe
aceast tem au o abordare general, prezentnd n linii mari
trsturile acestei noi platforme. Deocamdat, thread-urile pe
forumuri sunt relativ puine, ns putem observa interesul din ce
n ce mai mare al utilizatorilor, dornici s nvee cum s foloseasc
Rularea aplicaiei pe dispozitiv
noua versiune. Cele mai consistente resurse pe care le avem la
dispoziie sunt ghidurile oficiale compilate de ctre Oracle, care
Alegnd de pe disk fiierul Hello.jad cu ajutorul feres- pot fi descrcate de pe site-ul oficial al platformei.
trei de tip Open care a aprut, platforma lanseaz n execuie
managerul de aplicaii, care instaleaz pachetul nostru software
pe plcu, lucru pe care l putem vedea n urmtoarea captur
de ecran:
Managerul de aplicaii
Faptul c aplicaia noastr Java ME Embedded 8 ruleaz ntradevr pe dispozitiv ni-l demonstreaz consola PuTTY, unde
putem vedea output-ul pornirii i opririi aplicaiei:
Output-ul aplicaiei n consol
34
management
elaiile 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 relaie fie personal, fie profesional, n cadrul aceleiai companii
sau ntr-o regiune nu foarte ndeprtat, necesit un pic de efort. Pentru a crea parteneriate
de calitate, pe termen lung, apelm pur i simplu la aspecte de bun sim, pentru a ne asigura
c toat lumea se ndreapt n aceeai direcie i c ateptrile sunt clare. Totui, 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 relaii pe termen lung
cu clientul este comunicarea. Cu ct aceasta
este mai bun i mai frecvent ntre voi i
client, cu att mai onest i mai deschis
va deveni relaia. n acest fel va fi mai uor
pentru client s rmn mulumit i problemele s fie rezolvate ntr-un interval de timp
rezonabil.
Eticheta privind e-mailul. Atunci cnd

primii un e-mail, ncercai s rspundei la
timp. Iar dac nu putei rspunde cererii n
aceeai zi, atunci confirmai primirea e-mailului i spunei-i celui care l-a trimis pe cnd
poate atepta un rspuns complet. Mai mult,
comunicarea prin e-mail poate fi interpretat
n mod greit mai ales n timpul perioadelor
pline de stres, dac expeditorul i destinatarul nu se cunosc foarte bine. Aa c, din cnd
Fr agende ascunse. Agendele ascunse n cnd, punei mna pe telefon i, pur i simadesea duc la nenelegeri i, n cele din plu, vorbii.
urm, la nencredere.Discutai fiecare idee,
indiferent dac e bun sau rea. Dac e bun,
Sumarizai i recapitulai. Indiferent
va fi apreciat; n caz contrar, v va ajuta s de ct de fr importan ar putea prea o
nelegei unele aspecte de care pn atunci ntlnire sau o convorbire telefonic, odat
nu erai contieni. Doar aa, fiecare dintre terminat ntlnirea vor exista nite pai de
parteneri va obine beneficii.
urmat. Sumarizai i comunicai astfel nct
toat lumea s tie acelai lucru. Chiar dac
Fii proactivi. Meninei-v clienii nu exist pai de urmat, ci doar o recapitulare
informai n manier proactiv n ceea ce a discuiei, este bine s trimitei un e-mail cu
privete orice noutate. Evitai situaia n care aceasta, astfel nct toat lumea s tie acelai
ei trebuie s cear informaia. Astfel, toi cei lucru.
implicai vor fi asigurai de deschiderea i de
natura colaborativ a ambelor pri.
35
management
Fii propriul vostru client.
Familiarizai-v cu afacerea clientului,
nelegei cum funcioneaz aceasta, dinamica pieei lor, precum i provocrile cu
care se confrunt. Nu trebuie s devenii
expert, ns trebuie s vorbii pe aceeai
limb i s nelegei ngrijorrile clientului
dumneavoastr.
Acordai atenie calitii. Pentru a fi

bun n ceea ce facei, trebuie s avei oamenii potrivii n locurile potrivite, procese
adecvate i niciodat s nu v mulumii
cu locul doi sau cu suficient de bine.
ncercai n mod constant s devenii mai
buni i s ducei expertiza ctre nivelul
urmtor. Dac oferii servicii de calitate,
clienii se vor ntoarce la dumneavoastr.
Avei rbdare. Construirea relaii- i, mai important dect att, v vor recolor necesit timp. Ascultai-v clientul. manda cunoscuilor, oferindu-v astfel o
Nu ncercai s v impunei toate ideile bun oportunitate de cretere a afacerii.
dintr-o dat, la nceput, ci facei pai mici,
discutnd punct cu punct, i adaptndu-v
Parteneriate. Dezvoltai o relaie de
limbajul i discuia n funcie de reaci- parteneriat. Aceasta merge dincolo de proile i comportamentul respondentului iectul individual dezvoltat. Dac un client
dumneavoastr.
vede c suntei cu adevrat implicat i c
suntei foarte motivat s l ajutai, atunci va
Fii integru. Dac facei ceea ce ai ncepe s v priveasc nu doar ca un simspus c o s facei, de fiecare dat, fr plu furnizor. Desigur, a deveni parteneri
excepie, atunci vei fi primul pe list atunci implic mai mult dect ceea ce e meniocnd clientul va cuta noi servicii. Nu v nat aici; totui, voi lsa acest subiect pentru
fie team s recunoatei atunci cnd ai alt dat.
fcut o greeal; cerei-v scuze, nvai,
mprtii modul n care plnuii s o
corectai i asigurai-v c nu vei repeta
aceeai greeal de dou ori. Nerespectarea
promisiunilor va duce la o lips de integritate i nu vei reui niciodat s avei o
relaie de ncredere cu clientul dumneavoastr. n schimb, s-ar putea s ajungei
s-l pierdei pe acel client.
36
Fii oameni. ntlnii-v fa n fa.

Comunicnd la distan nu vei dovedi
ntotdeauna c v nelegei ntr-adevr
clientul i c putei s-l ajutai n nfruntarea provocrilor. De aceea este important
ca, mai ales la nceputul relaiei, s v ntlnii fa n fa i s v aliniai ateptrile.
Aceasta este o bun oportunitate de a
nelege mai bine afacerea clientului,
provocrile i obiectivele sale pentru
perioada urmtoare i modul n care
putei cel mai bine s i fii de folos. Totui,
discuiile de afaceri nu vor fi ntotdeauna
de ajutor n ce privete ceea ce gndete
cellalt admitem c exist ntotdeauna
lucruri care nu sunt spuse, mai ales la nceput i dac vrei s v nelegei mai bine
audiena atunci ar fi bine s bei o cafea
sau o bere mpreun, ntr-un cadru informal, cum ar fi un restaurant sau un pub.
Relaiile la distan pot fi cu adevrat
cele mai bune. Fiecare partener i aduce
propriul set de deprinderi n ecuaie, iar
combinaia acestora d natere unui parteneriat puternic. Natura tipului de relaie
poate varia, mergnd de la personal la
cea de afaceri, ns presupune aplicarea
acelorai reguli: niciodat s nu-l subapreciezi pe cellalt i comunicarea este
esenial.
HR
Cu un zmbet nu se face primvartiina fericirii n organizaii
untem tot mai preocupai de fericire. Din perspectiv organizaional, suntem tot mai
contieni de relevana unor angajai fericii: acetia sunt mai productivi, mai satisfcui i mai ataai. n acest sens, observm tot mai multe eforturi pentru a ne mulumi
angajaii. Dar cum oare putem ajunge de la zmbet la fericire organizaional?
Szilrd Kacs
kacso.szilard@happy-employees.eu
CEO & Trainer
@ Azimut Happy Employees
Chiar dac ncepem s vedem ct de

important este s avem angajai fericii,
suntem nc destul de reticeni n faa unui
concept att de abstract precum fericirea,
deoarece ne este greu s evalum dimensiunea acesteia. Vestea bun este c exist studii,
instrumente, scale, validate tiinific care ne
ajut s cuantificm drumul de la zmbet la
fericire organizaional.
angajailor, angajamentul de continuitate ,

cel normativ care poate prezice probabilitatea ca un angajat s prseasc compania.
Deoarece aminteam de importana

cuantificrii fericirii n organizaii, prezentm cteva instrumente tiinifice, pe
care noi le utilizm n procesul de evaluare
al conceptului, pe care ns le aplicm n
funcie de fiecare dimensiune: Utrecht Work
De la zmbet la fericire
Engagement Scale, Job Satisfaction Survey,
Fericirea la locul de munc este mai Organizational Commitment Questionnaire,
mult dect rs i voie bun. Evalum ferici- The Work and Meaning Inventory Scale etc. .
rea angajailor ca fiind un scor compus din
trei concepte:
Nu zmbetul ajut. Ci nite angajai fericii
Implicare- un concept n care accenUn angajat fericit nu este definit doar
tul este pus pe dezvoltarea potenialului printr-un zmbet, ci prin nivele optime ale
angajailor, pentru a-i proteja de efectele implicrii, angajamentului i satisfaciei.
unor posibili factori de stres i pentru a Dar de ce avem nevoie de angajai fericii n
crete productivitatea.
organizaiile noastre? Poate c unul dintre
Satisfacie- este o stare pozitiv care cele mai la ndemn argumente este ROI-ul
rezult din atitudinea angajatului la locul ( Return of Investment) pe care l aduce un
de munc.
program de cretere a fericirii angajailor. n
Angajament- discutm despre trei primul rnd, acesta se resimte cel mai mult la
tipuri de angajament organizaional: cel nivelul costurilor aferente angajrii i pregafectiv, care poate prezice performana tirii unui nou angajat. De aceea, e preferat s
37
HR
Cu un zmbet nu se face primvartiina fericirii n organizaii
punctele forte i de mbuntit
ale echipei.
Aceast prim etap este
urmat de implementare n care propunem i livrm
programe de training, teambuilding, coaching specific
nevoilor identificate n partea
de diagnoz.
Evaluarea i sustenabilitatea programului- evalum
rentabilitatea i progresul
aciunilor noastre, dup care
ne ngrijim de meninerea n
organizaie a comportamentelor deja create.
n concluzie, fericirea nu
se reduce la un zmbet, care
poate fi de multe ori doar unul
dintre semnele sociabilitii.
Doar cteva activiti pentru
amuzamentul i implicarea
angajailor nu ne ajut s ajungem la fericire organizaional.
Instrumentele tiinifice potrivite i un program complex
implementat, pot s aduc
imense beneficii cantitative i
calitative companiei i angainvestim n retenia i angajamentul angajailor.
jailor notri transformnd
n plus, cercetrile au dezvluit o legtur de cauzalitate ntre conceptul abstract de fericire organizaional n ceva concret i
fericirea angajailor, productivitatea i angajamentul lor i ntr-un msurabil. Nu uitai! Cu un zmbetnu se face primvar!
fericit final, satisfacia i loialitatea clienilor firmei. La acest
beneficiu adugm i faptul c angajaii fericii s-au dovedit
a fi cu 10-12% mai productivi dect cei cu o stare mai puin
bun la locul de munc . Avantajele resimite la nivelul companiei
se concretizeaz printr-o rat crescut de retenie i profit adus
companiei.
De la fericire la fericire organizional

Se fac tot mai multe eforturi pentru a crete satisfacia angajailor prin organizarea diferitelor petreceri tematice, activiti de
echip, traininguri, beneficii la birou. ns acestea nu sunt suficiente pentru a ajunge la fericire. Pot aduce zmbete, cel mult..
Este nevoie, n schimb, de o strategie i un program mai complex. Recomandm un program care intete impactul pe termen
lung al fericirii n organizaie i care presupune trei etape:
Diagnoza echipei- unde, cu ajutorul instrumentelor
tiinifice i a diferitelor metode de observare evalum i
msurm diferii indicatori organizaionali, pentru a identifica
38
sponsori
powered by

Today Software Magazine N36/2015

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Today Software Magazine N36/2015

Încărcat de

Drepturi de autor:

Formate disponibile

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

Aplicaii IoT cu Java ME Embedded 8

Minimum Delightful Product Interviu cu Rohan Chandran

e pregtim de vacane i gndurile ne zboar spre rmuri nsorite sau spre

Fondator al Today Software Magazine

nr. 36/2015 | www.todaysoftmag.ro

Redacia Today Software Magazine

Agile Coach and Trainer, with a

Independent Consultant &

Traductor: Roxana Elena

Contabil : Delia Mircea

Junior Web Developer: Alexandru Dini

Tipar realizat de Daisler Print House

Today Software Solutions SRL

ISSN 2284 6352

Copyright Today Software Magazine

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

Minimum Delightful Product Interviu cu Rohan Chandran

m avut plcerea de a realiza un interviu cu Rohan Chandran pe tema product

nr. 36/2015 | www.todaysoftmag.ro

[Ovidiu Man] Produsul Minim

persoan. Ea spune o poveste i evoc