Today Software Magazine N31/2015

Nr. 31 Ianuarie 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
Competen sau fraud?
JavaFX i comunicarea prin RESTful
Web Services
Atacarea complexitii cu TDD i Agile

Cinci Sfaturi practice pentru
Code Review n Scrum
Academy+Plus
Arhitectura software (I)
Clasificare de text la scar larg
Internet of Things n universul Java

Ce sistem de distribuire de
mesaje din Azure s folosesc?
Convergena documentaiei ntr-un
proiect software multi-modular:
o abordare bazat pe Build Automation
Technology on Privacy Day
6
Realizrile din 2014 i
planurile de viitor ale
Today Software Magazin
Ovidiu Man
8
Evenimente i
startup-uri n 2014
Mircea Vdan
10
15 tendine de Marketing Online
i tehnologie pe care
nu vrei s le ratezi n 2015
Clin Biri
12
ACADEMY+PLUS
Daniela Buscan
15
Levente Veres
28
Performana n
echipe
distribuite
Tiberiu Cifor
32
Cinci sfaturi practice pentru
Code Review n Scrum
Alexandru Bolboac
34
Convergena documentaiei
ntr-un proiect software
multimodular
Alexandru Albu
38
Clasificare de Text la Scar Larg
Cristian Ra
40
Dnu Chindri
18
JavaFX i comunicarea prin
RESTful Web Services
44
Ce sistem de distribuire de mesaje
din Azure s folosesc?
Silviu Dumitrescu i Diana Blan
Radu Vunvulea
22
Competen sau
fraud?
Cristian erban
24
Diminuarea complexitii
cu TDD i Agile
Radu Ometita
47
Noi tehnologii n pragul Data Protection Day 2015
Claudia Jelea
49
Gogu i jocul
alternativelor
Simona Bonghez, Ph.D.
editorial
Ovidiu Man
ovidiu.matan@todaysoftmag.com
Editor-in-chief
Today Software Magazine
a muli ani !!! Pornim la drum n acest an plini de avnt i dornici s facem fa
noilor provocri. Una dintre acestea este atingerea unor noi obiective pe care i
le-a propus TSM. Ne propunem s lansm cardul de membru TSM i o pagin
online dedicat joburilor. Pentru clienii mobile, vom publica n curnd o aplicaie dedicat telefoanelor Windows Phone. Proiectm i organizarea de evenimente noi precum
o conferin dedicat experilor Java, a crei lansare se va desfura probabil n var.
Mai multe informaii despre unele dintre aceste subiecte vei gsi n primul articol din
acest numr. V mulumim c ai fost alturi de noi i de asemenea mulumim companiilor partenere pentru suportul acordat.
n paginile acestui numr am publicat o serie de articole ce v ndrum spre o mai
bun organizare n cadrul echipei dintre care menionez: Cinci sfaturi practice pentru Code Review n Scrum, Diminuarea complexitii cu TDD i Agile, Convergena
documentaiei ntr-un proiect software multimodular i Performana n echipe distribuite.
Articolul denumit Arhitectura software deschide seria de articole dedicate acestui subiect
complex care este arhitectura software . Universul Java este reprezentat de dou articole:
Things n universul Java i JavaFX i comunicarea prin RESTful Web Services, articol
aflat n continuarea seriei despre JavaFX. Securitatea este un domeniu de care trebuie s
se in cont n dezvoltarea oricrui produs software, aa cum argumenteaz i articolul
Competen sau fraud?. Continum cu o analiz a sistemului de mesaje din Azure,
pentru ca la final s v delectai cu lectura ultimului episod din cea mai longeviv serie
TSM dedicat aventurilor lui Gogu.
V dorim o lectur plcut !!!
Ovidiu Man
Fondator al Today Software Magazine
nr. 31/2015 | www.todaysoftmag.ro
Lista autorilor
Redacia Today Software Magazine
Tiberiu Cifor
tiberiu.cifor@3pillarglobal.com
Engineering Manager
@ 3Pillar Global
Fondator / Editor in chief: Ovidiu Man

Graphic designer: Dan Hdru
dan.hadarau@todaysoftmag.com
Alexandru Bolboac
alex.bolboaca@mozaicworks.com
Agile Coach and Trainer, with a
focus on technical practices
@Mozaic Works
Radu Ometita
Alexandru Albu
Software engineer
@ Fortech
Senior Developer
@ ISDC
Cristian Ra
Software Developer
@ Yardi
Speaker, trainer and consultant

in project management,
radu.ometita@fortech.ro
alexandru.albu@isdc.eu
Copyright/Corector: Emilia Toma

emilia.toma@todaysoftmag.com
Traductor: Roxana Elena
roxana.elena@todaysoftmag.com
Cristian.Rat@Yardi.Com
Editor startups: Mircea Vdan

mircea.vadan@todaysoftmag.com
simona.bonghez@confucius.ro
Owner of Colors in Projects
Silviu Dumitrescu
Reviewer: Tavi Bolog

tavi.bolog@todaysoftmag.com
silviu.dumitrescu@accesa.eu
Java Line Manager
@ Accesa
Contabil : Delia Coman

delia.coman@todaysoftmag.com
Produs de
Today Software Solutions SRL

str. Plopilor, nr. 75/77
Cluj-Napoca, Cluj, Romania
contact@todaysoftmag.com
www.todaysoftmag.ro
www.facebook.com/todaysoftmag
twitter.com/todaysoftmag
ISSN 2284 6352
Mircea Vdan
mircea.vadan@gmail.com
www.clujstartups.com
Diana Blan
Clin Biri
Java developer
@ Accesa
Digital Director
@ Loopaa
Diana.Balan@accesa.eu
calin.biris@loopaa.ro
Radu Vunvulea
Radu.Vunvulea@iquestgroup.com
Senior Software Engineer
@iQuest
Daniela Buscan
dbuscan@pitechnologies.ro
Account Manager
@ PITECH+CONCEPT
Cristian erban
Levente Veres
Application Security
@ Betfair
Design Lead
@ Endava
Claudia Jelea
Dnu Chindri
Lawyer
@ Jlaw
Java Developer
@ Elektrobit Automotive
Cristian.Serban@betfair.com
claudia.jelea@jlaw.ro
Levente.Veres@endava.com
danut.chindris@elektrobit.com
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. 31/ianuarie, 2015
interviu
Realizrile din 2014 i planurile de viitor ale

014 a nsemnat o perioad de maturizare prin creterea numrului i a calitii articolelor publicate. Numeric, aceasta s-a
reflectat n numrul crescut de accesri online care a ajuns la 7000 sesiuni/lun i de participani la evenimentele de lansare care
a atins o medie de 70-80 participani. Momentul maxim a fost la lansarea din septembrie a revistei cnd s-au nregistrat peste
120 de participani, iar online n perioada IT Days-ului cnd am trecut de 10,000 sesiuni / lun.
www.todaysoftmag.ro - 2014 (romn)
online prin lansarea noului site. Identitatea vizual a revistei a fost

adaptat la trendurile de design actuale, iar partea de back-end
a fost integral rescris, inclusiv partea de administrare. A fost
un exerciiu de profesionalism n domeniu realizat cu ajutorul
Gemini Solutions i agenia de design Subsign.
Finalul anului s-a realizat sub umbrela IT Days unde au fost
peste 200 de participani. Nu am s intru n detalii deoarece am
scris despre acesta pe larg n numrul trecut. Menionez doar c
pe durata celor trei zile, dac lum n considerare i cele dou
workshop-uri, am avut parte de prezentri de excepie i de un
mediu prietenos.
Proiecte pentru 2015

Cardul de membru Today Software Magazine
www.todaysoftmag.com - 2014 (englez)
De-a lungul anului, evenimentele de lansare ale revistei nu

s-au limitat doar la cele din Cluj. Ne-am ntlnit cu cititorii
revistei i n Bucureti, Timioara, Braov, Iai i Trgu-Mure.
Acestea au fost gzduite de ctre sponsori ai revistei dar i organizate mpreun cu colegii de la Gemini Foundation sau Cluj IT
Cluster. Am avut parte de un public minunat i promitem s revenim. n Cluj evenimentele de lansare au fost gzduite ca de obicei
de sponsorii revistei. O noutate fiind multitudinea de noi sedii
inaugurate pentru care lansarea revistei a fost o bun ocazie de
prezentare a noului spaiu comunitii de IT locale.
Noutatea principal n 2014 a fost schimbarea 100% a imaginii
nr. 31/ianuarie, 2015 | www.todaysoftmag.ro
Este vorba de cardul TSM, o idee care a aprut de mai mult

timp, dar care abia acum s-a materializat ntr-o ofert concret.
Cardul TSM se adreseaz membrilor activi ai comunitii de IT
romneti, celor care doresc s i mbunteasc n mod constant cunotinele din domeniu, crora revista TSM le poate
aduce un plus de informaii lunar i chiar mai mult. Punctual,
cardul TSM v ofer:
A. Revista tiprit Aceasta va fi livrat lunar, pe durata
unui an ntreg, la adresa specificat de dvs. prin Pota Romn.
Este un modalitate comod de a v asigura lunar o lectur
de calitate prin revista tiprit. De altfel, revista tiprit va fi
adresat exclusiv membrilor TSM i a celor ce particip la evenimentele de lansare a revistei sau la evenimentele partenere
unde este distribuit.
B. Cartea IT Days 2015 La fel ca i n 2014 vom tipri i
distribui cartea evenimentului.
C. Reduceri importante la evenimentele TSM. Este vorba
de 50% reducere pentru Cluj IT Days i 20% reducere la workshop-urile organizate de ctre Today Software Magazine.
D. Reduceri la evenimentele naionale de IT: primele
astfel de evenimente sunt ...even Mammoths can be Agile unde
posesorii cardului vor primi 20% reducere i Mobos cu 20%
reducere
E. Consultan pentru publicarea de articole n revista
TSM.
F. Realizarea de proiecte comunitare. Cei ce doresc s se
implice n realizarea unor proiecte pentru comunitile locale
cum ar fi: eLearning sau o platform online dedicat voluntarilor
TODAY SOFTWARE MAGAZINE
i organizaiilor de voluntariat. Cei mai Pagina de joburi

activi membri vor fi recompensai prin
n luna februarie vom lansa un nou
invitaii gratuite la diferite evenimente proiect. Este vorba de o pagin de joburi
IT.
ce va fi disponibil doar online cu un link
separat de pe pagina principal. Venim
n acest fel n ntmpinarea unei piee a
Preul de lansare a acestui card este IT-ului foarte dinamic prin anunuri de
de 300 RON + TVA / an i se va putea calitate i care vor fi orientate ctre nevocomanda curnd online sau de astzi dac ile acesteia ntr-un mod mai prietenos
ne trimitei un e-mail la adresa card@ dect alte soluii existente la ora actual.
todaysoftmag.com . Prin acest card v ncurajm totodat startup-urile, printrartai totodat susinerea pentru revista o seciune dedicat acestora i un pre
Today Software Magazine i proiectele sale. redus de publicare a unui anun. Pagina va
evolua n viitor i ne gndim s re-publicm calendarul online i o seciune nou
dedicat training-urilor.
Sperm c v-am fcut curioi i v
ateptm online la evenimentele de lansare,
s devenii membri TSM i poate chiar s
urmrii viitoarea pagin de joburi.
Ovidiu Man
Editor-in-chief
antreprenoriat
Evenimente i startup-uri n 2014
a fel ca n ultimii doi ani, a venit vremea unui review pentru ultimele 12 luni. n general, mi pare c ecosistemul s-a mai aezat.
Micarea brownian,, a iniiativelor de suport pentru startup-uri pare mai clar i mi permit s cred c de-acum vom intra
ntr-o faz de cretere, n care actorii sunt deja relativ cunoscui i i vor juca rolul n continuare.
n cele ce urmeaz voi ncerca o clasificare n funcie de calibrul i scopul

general al acestor iniiative, precum i
o menionare a ctorva startup-uri care
dintr-un punct de vedere sau altul s-au
remarcat n ultimul an.
La capitolul evenimente trebuie s
remarcm apariia ctorva concepte noi,
astfel c aproape fiecare lun a fost presrat cu un astfel de eveniment:
la a treia ediie. Dincolo de numrul foarte

mare de participani, de remarcat a fost c
toate cele patru echipe premiate au fost
conduse de reprezentante ai sexului feminin, fapt ce ar putea nsemna un pas spre
maturizarea ecosistemului i o cretere
gradual a implicrii feminine- problem
discutat des n alte ecosisteme mult mai
avansate, fiind lansate chiar i fonduri de
investiii cu scopul de a sprijini antrepreStartup Pirates Cluj 1 - aflat la noriatului tech feminin;
prima ediie n februarie 2014, este un
eveniment de o sptmn, cu mentori
internaionali i workshop-uri menite s
dea participanilor o viziune clar asupra
Transylvania Demoday3 a cumulat
ce nseamn lean startup. S-au abordat dou ediii anul trecut (n aprilie i decemurmtoarele teme: business model, cus- brie) i a constat ntr-o sesiune de pitch-uri
tomer validation, pitching, marketing for de cte 4 minute plus ntrebri din partea
startups, investments. Practic participanii juriului. Fiecare ediie a strns n jur de 10
au venit pregtii cu ideile de startup, iar startup-uri preselectate din ecosistemul
n timpul evenimentului au lucrat pe dez- clujean.
voltarea ideii lor sub ndrumarea celor 20
de mentori.
n martie am avut parte de binecunoscutul Startup Weekend Cluj2, aflat deja
Techsylvania4 s-a poziionat nc de
1 http://cluj.startuppirates.org/
3 http://startuptransilvania.ro/demo-day/
2 http://cluj.startupweekend.org/
4 http://www.techsylvania.co/
la nceput ca un eveniment cu perspectiv internaional, tematic fiind centrat

pe inovaie n tehnologii hardware V
prezentm cteva exemple de deviceuri ce puteau fi testate la eveniment:
Jawbone, Google Glass, Pebble, Sphero,
Onyx Beacons, Leap Motion, Withings,
EyeTribe Tracker. Un aspect interesant
fiind hackathon-ul aferent, pe wearables
i connected technologies, n cadrul
cruia echipele puteau s dezvolte soluii
la diverse probleme, bazate de tehnologiile menionate mai sus. O nou ediie a
Techsylvania va avea loc la nceputul lunii
iunie 2015.
Un eveniment dedicat studenilor a fost

3 Day Startup Cluj5. Pe lng implicarea
exclusiv a studenilor, acest eveniment se
deosebete prin faptul c participanii sunt
selectai dup o aplicaie i un interviu fa
n fa, cu o limit de aproximativ 40 de
locuri. Asemntor n structur cu alte
evenimente de weekend (pitching, selectare ideilor, formarea echipelor, iar apoi
lucrul efectiv, pitch i jurizare), evenimentul nu-i propune dezvoltarea de MVP-uri,
5 http://cluj.3daystartup.org/

ci mai degrab validarea de business mai
ales prin interviuri cu posibili clieni i
feedback de la mentori.
n noiembrie a avut loc i IT Days

dintre ale crui track-uri menionm tema
antreprenorial. Astfel pe lng cele cteva
pitch-uri ale startup-urilor, au fost prezentate i proiecte de cercetare din cadrul
universitilor ce ar putea deveni la un
moment dat spin-off-uri spre business.
6
Simplon Romania 10 organizat cu

suportul Cluj Cowork, cu o durat de 6
luni, ncepnd n octombrie are scopul de
educa participanii cum s dezvolte un produs i apoi s-l lanseze pe pia, chiar dac
nu au la nceput, nici un fel de experien
tehnic. Practic, este un mix ntre un incubator i o coal de programare, iar prin
orientarea spre comunitate gzduiete
meetup-uri de care pot beneficia i alte
persoane cu startup-uri sau interesate.
Startup Live Cluj 7 a fost ultimul

eveniment din an, desfurat n strns
legtur cu Transylvania Demoday. Cteva
dintre ideile participante au fost incluse i
Spherik Accelerator11 a avut prima
n sesiunea de pitching de la Demoday. perioad de aplicare n noiembrie i astEvenimentul este centrat pe paradigmele fel au fost acceptat 5 startup-uri pentru
lean startups i este la a treia ediie n Cluj. a urma programul de 4 luni. Acestea au
primit spaiu de birouri i i vor fi incluse
De asemenea, dintre evenimentele de ntr-o serie de workshop-uri i sesiuni de
anvergur mai mic dar cu recuren mai mentorat organizate n cadrul acceleratomare, trebuie s menionm explozia de rului. De menionat e c acceleratorul este
meetup-uri axate pe diverse teme legate de non-profit, astfel c n schimbul serviciitehnologie i startup-uri. Astfel c, n fie- lor oferite nu ia equity de la startup-urile
care sptmn din aceast toamn aveau acceptate.
loc cel puin 3 meetup-uri, precum: Agile
Development, Growth Hacking, Bitcoin,
How to Start a Startup Lectures, SpartUP,
UX/UI, Startup Lounge, Mobile Monday8.
Majoritatea lor au avut loc la Cluj Hub i
Alturi de aceste programe, de
s-au promovat mai ales prin intermediul menionat este i Startcelerate 12 , o
meetup.com. Bineneles, e important iniiativa nscut n Cluj, dar prezent mai
de menionat i lansrile revistei TSM, ales n Marea Britanie i care i propune s
n cadrul crora a fost abordat i tema conecteze companiile de IT care au resurse
startup-urilor.
libere cu startup-uri sau investitori ce au
La capitolul programe, deci cu o durat nevoie de acele resurse. n acest sens, au
de cel puin cteva sptmni, ar fi trei avut o serie de evenimente de pitching i
iniiative de menionat:
matching, inclusiv n Cluj, iar pentru viitorul apropiat sunt plnuite altele n mai
multe capitale europene.
n acest ultim an am avut parte i
Tandem by GRASP9 a fost organizat de startup-uri care au fost premiate sau
de Global Romanian Society of Young acceptate n programe de accelerare
Professionals, cu o durat de 8 sptmni internaionale:
i un format axat pe practici non-formale
CallerQ (we help sales profesde educaie antreprenorial cu scopul de a
sionals to increase the efficiency of
duce participanii prin procesul de definire
prospecting and provide analytics to
a conceptului, a modelului de business,
sales managers) a participat n prograpitching i dezvoltarea unui prototip.
mul Krakow Warp sub egida Hub:raum .
6 http://www.itdays.ro
Asiqo (mobile application that
7 http://startuplive.in/cluj-napoca/3
10 http://ro.simplon.co/
8 http://clujstartups.com/#events
11 http://spherikaccelerator.com/
9 http://tandem.mygrasp.org/
12 http://startcelerate.com/
enables brands to interact with their

global audience through advertisements) - ntre timp, nchis, a ctigat
competiia Telekom Innovation Contest
pe Romnia.
Evolso (The dating app giving
power back to the ladies) a participat
n programul de accelerare StartupYard
(Cehia).
ZenQ (ze way to say thank you and
appreaciate your friends) a fost incubat n TechPeaks (Italia) imediat dup
Startup Weekend.
Project Wipe (electronic glasses
that help people with visual disabilities
n orientation and obstacle avoidance)
s-a calificat n final Startup Spotlight (@
HowToWeb).
TeenTrepreneur (virtual financial
educaional game), trecut prin Startup
Pirates i Startup Weekend, va fi incubat n acest an n Watson University
Accelerator (Colorado, SUA).
Dincolo de exit-urile bine cunoscute
- Skobbler si LiveRail (ctre Telenav i
respectiv Facebook), putem meniona i
alte cteva startup-uri ce cresc rapid sau/
i au venit constant:
DollarBird app (smart calendar
app for managing personal finances);
Microstockr (app that helps you
track sales on major microstock photography websites);
TinTag (rechargeable tracking
device for your lost items.) ;
Moqups (Online mockups made
simple);
Onyx Beacon (iBeacon CMS for
retailers RSS Feed.) ;
Rebs (Software specializat pentru
profesioniti n imobiliare);
HipMenu (food ordering mobile
app);
Squirrly (content marketing tool
allowing you to optimize content and
measure its success.).
Bineneles, pe lng iniiativele de
startup-uri noi, n aceast primvar vom
avea parte i de alte cteva iniiative serioase de suport al ecosistemului, dar despre
ele n articolele urmtoare.
Mircea Vdan
mircea.vadan@gmail.com
www.clujstartups.com
marketing
15 tendine de Marketing Online i tehnologie

pe care nu vrei s le ratezi n 2015
ou cant connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will
somehow connect in your future. You have to trust in something - your gut, destiny, life, karma, whatever. This approach has never
let me down, and it has made all the difference in my life. - Steve Jobs
Fcnd retrospectiva anului 2014, am vzut cteva tendine

i tehnologii care vor schimba cu siguran modul n care comunicm, interacionm i investim n publicitatea online. Aadar,
obiectul articolului va consta n prezentarea a zece tendine de
Marketing Online i cinci tendine tehnologice pentru acest an i
pentru anii care urmeaz.
mult coninut video pe propriile platforme. Rzboiul cu YouTube

abia a nceput.
3. Lupta pentru coninut video n Social Media
7. Campaniile Omni channel vor fi tot mai importante
Anul trecut, Facebook a introdus funcionalitatea de auto-play

la toate video-urile de pe platform. n consecin, companiile i
publicaiile au nceput s-i publice video-urile direct pe Facebook.
Acest lucru i-a creat Facebook oportunitatea mare de a vinde
reclam video i pentru branduri. n 2015 vom putea vedea i alte
reele sociale precum LinkedIn sau Twitter s se lupte pentru mai
n prezent, clienii folosesc ntre zece i douzeci de surse

de informare nainte s ia o decizie cu privire la ce s cumpere. Cutarea este standard, prerile prietenilor sunt aur curat
i experiena oferit de produse i servicii este noul marketing.
Companiile nu-i mai permit s nu investeasc n Marketing
Online, astfel vor folosi tot mai muli bani pentru publicitate
4. Companiile se vor orienta i spre alte platforme Social Media.
Dup cum tim i am observat, Facebook i-a schimbat algoritmul pentru newsfeed i a redus foarte mult reach-ul mesajelor
organice (nepltite) postate de ctre branduri. Aceasta este o veste
Tendine de Marketing Online pentru 2015
proast pentru companii.
Ne ateptm ca n acest an s nceap cutarea unui next
1. Prezena pe dispozitivele mobile este un must have.
big (free) thing, sau cel puin businessurile se vor orienta s
n Romnia avem deja 7,5 milioane de utilizatori activi investeasc mai mult n propriile canale de comunicare: blog i
de smartphone-uri, ceea ce reprezint aproximativ 37,5% din newsletter.
populaia rii. n 2014 antreprenorii au realizat c nu pot ignora
40% din potenialii lor clieni i au nceput s gndeasc mobile. 5. LinkedIn va deveni i mai mult o platform de coninut editorial
n 2015 ne ateptm s vedem noi magazine online care s intre de business
pe pia direct cu website-uri reponsive. De asemenea, magazinele
Ai ncercat noua funcionalitate Create a post? Este super!
online care au deja versiuni de site-uri adaptate dispozitive- Orice utilizator al reelei sociale LinkedIn poate acum s scrie artilor mobile, se vor orienta nspre a-i dezvolta propriile aplicaii cole personale care arat foarte similar cu postrile de pe bloguri.
mobile.
Cnd cineva scrie un articol toate conexiunile sale primesc o notificare despre postare. S-ar putea ca n acest an s vedem ca aceast
2. Mai mult coninut cu brand de calitate
opiune s se implementeze i la paginile de business.
De vreme ce peisajul Social Media devine tot mai aglomerat cu
mesaje comerciale dar cu un coninut de slab calitate, companiile 6. Facebook @ Work
detepte vor investi n diferenierea printr-un coninut de calitate.
Facebook a nceput s lucreze la o versiune a platformei sociale
Acest lucru va reprezenta o mare oportunitate pentru ca brandu- adaptat pentru businessuri, care ar putea concura cu Yammer,
rile care au o poveste de spus s arate c Social Media poate aduce Google Groups, LinkedIn sau alte tool-uri colaborative. Ateptm
clieni noi i poate s-i fidelizeze pe cei existeni.
s ncercm o versiune beta.
10
integrat.
8. Companiile vor investi tot mai mult n publicitate pe Social Media

Noul algoritm al Facebook-ului foreaz companiile s investeasc n publicitate pe Facebook pentru a ajunge cu mesajele
postate la toi fanii paginilor de brand. Fcnd acest lucru businessurile vor nva c reclamele de pe Facebook sunt uor de creat,
foarte bine targetate, ieftine i ofer interaciuni extra pe gratis.
Aceasta este un trg bun pentru orice brand i n consecin ne
ateptm la tot mai mult publicitate pe Facebook i pe alte reele
sociale.
9. Companiile vor investi mai mult n reclame video

innd cont c Generaia Y nu mai urmrete att de mult TV
i petrece mai mult timp navignd pe internet, marile branduri
i vor reprograma o parte din bugetele de reclam de pe TV n
publicitate video online.
Aa cum tim, pe internet nu ai nevoie de bugete foarte mari
pentru a putea face publicitate i din acest motiv orice companie
i permite acum s livreze reclame video ctre clienii lor. Noi
am experimentat anul trecut cu publicitatea video pe Facebook
i rezultatele au fost surprinztor de bune, astfel ne ateptm s
vedem mai multe reclame pe monitoare i ecranele smartphoneurilor sau tabletelor noastre.
10. Companiile vor ncepe se fac retargeting

n 2014 am vzut cteva exemple de campanii de retargeting.
Anul acesta ne ateptm la mai multe retargetri inteligente i mai
multe branduri care s apeleze la aceast tactic.
n concluzie, la tendinele n Marketing Online, credem c s nu apar i s fie implementate la noi foarte rapid.
2015 va fi anul comerului pe mobil, al coninutului de calitate i
a reclamelor sociale i video.
14. Beacons
Clienii vor fi mai bine intii, mai delectai i mai informai
Din punct de vedere al marketingului, beacon-urile ofer o
pe orice device sau platform vor folosi.
oportunitate foarte bun pentru a afla mai multe informaii utile
despre clieni i ne d posibilitatea s facem reclam contextual
Tendine tehnologice n 2015
mult mai precis. Ne ateptm la noi dezvoltri pentru aceast
tehnologie.
11. Aplicaiile mobile de sntate i dispozitivele mobile
n acest an credem c marile companii vor scoate n fa i vor

ncuraja consumatorii s cumpere mai multe dispozitive mobile.
Problema este c pentru brrile i ceasurile nou aprute nu prea
exist aplicaii dezvoltate i acest lucru nu le face foarte cool.
Soluia ar putea veni de la aplicaiile de sntate. Spre exemplu:
ar fi util a avea un ceas care s ne ajute s tim informaii vitale
despre corpurile noastre.
15. Maini care se conduc singure
Cea mai important tire la CES 2015 a fost despre mainile

care se conduc singure. Audi a trimis un model de test A7 ntr-o
cltorie de la San Francisco pn n Las Vegas fr intervenia
unui ofer uman. Modelul A7 a ajuns n Las Vegas fr nici un
incident. De asemenea, BMW i Mercedes-Benz fac progrese
mari pentru ca acest vis s se mplineasc.
Suntem siguri c acest an va fi unul memorabil pentru dome12. Realitate virtual
niile IT i Marketing. Depinde numai de noi s profitm la maxim
Dac filmele 3D au avut mult succes cnd toat lumea le-a i s contribuim s fie un an excelent. Bucur-te de el! F conexiputut urmri n cinematografe, realitatea virtual ar putea fi noua unea ntre puncte i cu siguran vom vorbi n 2016 despre cum
revoluie n divertisment. Oculus rift este deja ceva ce orice geek 2015 a fost un an de tehnologii cool i Social Media.
i-ar dori s fie integrat n jocuri video. Tehnologia aceasta este
deja n dezvoltare.
13. Pli cu mobilul
Clin Biri
n SUA, oamenii pot folosi Apple Pay i Google Wallet. Se

zice c aceste soluii sunt the next thing cu privire la pli. Din
pcate, n Romnia nc ncercm s educm consumatorul s
plteasc online cu cardul. Aadar, s-ar putea ca plile cu mobilul
Digital Director
@ Loopaa
calin.biris@loopaa.ro
11
educaie
Tinerii romni pasionai de informatic au acces la o metod

inovativ de nvare prin intermediul ACADEMY+PLUS
ezvoltarea sectorului IT creeaz an de an locuri de munc din ce n ce mai interesante i mai atractive pentru tinerii
pasionai de domeniul informaticii. Dar n contextul valului ascendent de angajri din ultimii ani, companiile au nceput s
caute profile din ce n ce mai complexe. n acelai timp, exist i candidai care au neles c pentru a se diferenia au nevoie
de formule complementare de formare profesional.
Din acest motiv, n ultimii ani, la nivel naional au aprut o
serie de metode alternative de nvare care ofer candidailor
experiena unei specializri specifice ntr-o anumit tehnologie,
fie n domenii conexe, cum ar fi marketing, management, design
sau social media.
n momentul de fa exist un gol n zona de resurse umane
specializate n domeniul IT, att n SUA ct i n Europa, respectiv
Romnia, iar acest gol vine pe de o parte din cifrele de colarizare,
iar pe de alt parte din lipsa unor competene calibrate cu
cerinele pieei.
Dac ne raportm la cifre, n Romnia exist aproximativ
100.000 de angajai n domeniul IT la nivel naional, iar cererea
de ocupare n 2014 a fost de 17.148 oferte de munc pe diverse
stadii de specializare n cele mai mari orae din Romnia - conform ofertelor de munc publicate de site-urile de specialitate.
Pe fondul acestor constatri, nu trebuie s ignorm nici faptul c
cei mai strlucii dintre absolvenii de liceu sau facultate cu profil
tehnic, aleg fie s i continue studiile n afar rii, fie s lucreze
pentru companii renumite din strintate.
Pornind de la aceste premise, anul trecut compania
PITECH+PLUS a lansat o metod revoluionar de nvare i
formare profesional n domeniul IT. ACADEMY+PLUS este o
coal nou, bazat pe o program actualizat cerinelor pieei i,
n acelai timp, utiliznd o metod inovativ de nvare pentru
elevi.
Obiectivele colii sunt s rezolve pe de o parte necesitatea
companiilor de IT de a avea angajai capabili s neleag un
12
proiect nu doar dintr-o perspectiva tehnic, ci i din perspective

manageriale sau de sales i marketing, iar pe de alt parte coala
i propune s creeze o cultur geek culture prin care s atrag
i alte persoane cu abiliti de nvare spre zona informaticii.
ACADEMY+PLUS a fost lansat pe piaa din Romnia pe
baza unui parteneriat cu coala 42 din Paris. Aceast din urm
nu este altceva dect o pepinier de 1000 de elevi/an care nva
informatic dup reguli dictate de industrie.
Parteneriatul semnat n martie 2014 a pus n micare un proiect unic pentru industria de IT din Romnia: lansarea unei coli
deschise oricrei persoane pasionate de informatic, finanat
exclusiv de compania clujean PITECH+PLUS.
Admiterea la ACADEMY+PLUS se face n aceeai manier ca
la 42: pre-selecie, check-in un interviu cu candidaii care trec de
pre-selecie, piscina o testare de 28 de zile i go/no go. La finalul
celor trei evaluri de 28 de zile, din aproximativ 1200 de nscrii
pe platforma de candidatur doar 58 de candidai au obinut go.
n luna noiembrie 2014, a avut loc ceremonia de inaugurare
a colii. n momentul de fa elevii colii nva prin intermediul
proiectelor lansate pe platforma de e-learning pe care o au la
dispoziie.
Elevii selectai nu reprezint un grup omogen de persoane
care au aceeai vrst sau preocupri. Admiterea s-a adresat
tuturor celor care sunt pasionai de informatic, iar n afar de
rezultatele obinute la testri, echipa care s-a ocupat de recrutare nu a luat n considerare vrsta (dect n cazul minorilor) sau
experienele anterioare. Aadar, printre elevii ACADEMY+PLUS
se regsesc proaspt absolveni de liceu, dar i persoane care i
doresc o reconversie profesional n domeniul IT.

filiale n alte orae din Romnia.
Pe termen lung, obiectivele ACADEMY+PLUS sunt s se
ridice gradul de colaborare ntre companiile care caut tineri
talentai, s creasc standardele de performan ale industriei i
s descopere prin intermediul metodei sale mini strlucite care
pot crea produsele informatice de mine.
Unicitatea acestui proiect se reflect din mai multe unghiuri.

Pe de o parte, coala n sine reprezint un micro-mediu
organizaional. Elevii au dispoziie un spaiu complet dotat tehnic, o sal de jocuri, sli de brainstorming i profesioniti care
le stau la dispoziie avnd calitatea de mentori i nu aceea de
profesori.
Ingredientele psihologice care determin funcionarea acestui ntreg ansamblu n absena unui orar, a unor ore de prezen
stricte sau a unor condiionri, sunt self-responsibility i dezvoltarea abilitilor decizionale.
coal pornete de la premisa c exist creativitate n IT i le
ofer elevilor libertatea s experimenteze n jurul unei comuniti
pe care i-o creeaz singuri.
n ceea ce privete metoda i programa, exist cteva elemente
care le particularizeaz :
Peer-to-peer learning elevii nva s se evalueze unii pe
ceilali, iar n cele din urm, obiectivul este ca acetia s deprind
abiliti de analiz.
Munc n echipa att evalurile, ct i o parte din proiecte se realizeaz n echipa. n acest mod elevii sunt ncurajai s
comunice eficient unii cu ceilali.
Practic elevii primesc toate instrumentele necesare
pentru a parcurge o problematic, apoi rspund unui exerciiu
printr-o aplicaie practic.
Comunitate elevii sunt ghidai s i creeze propria lor
comunitate, cu propriile lor valori.
Pe termen scurt, obiectivele noastre in de triplarea numrului
de elevi n 2015, customizarea de module de formare prin intermediul crora s creasc gradul de flexibilitate i personalizare n
conformitate cu pregtirea individual a fiecrui candidat, astfel
nct cei cu un nivel mai ridicat s poat opta pentru un anumit
mix de formare. De asemenea, ne propunem i deschiderea de
Daniela Buscan
dbuscan@pitechnologies.ro
Account Manager
@ PITECH+CONCEPT
13
comuniti
Comuniti IT
nul 2015 ne promite o serie de evenimente de calitate i ncepem cum altcumva: Lansarea numrului 31 TSM. V propunem
pentru aceast lun Mobile Monday n Cluj i evenimentele Taberei de testare din Iai i Timioara. Un eveniment nou ce
va fi inaugurat la nceputul acestui an n Cluj este OWASP Cluj-Napoca crora le dorim succes.
Transylvania Java User Group

Comunitate dedicat tehnologiilor Java.
Website: www.transylvania-jug.org
Data nfiinrii: 15.05.2008 / Nr. Membri: 598 / 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: 2068/Nr. Evenimente: 28
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
14
Calendar
Ianuarie 20 (Cluj)
Lansarea numrului 31 al Today Software Magazine
www.todaysoftmag.ro
Ianuarie 22 (Timioara)
TdT#28 - Cum a fost la EuroSTAR?
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/129617852/
Ianuarie 22 (Iai)
Protractor, end to end testing for AngularJS
meetup.com/Tabara-de-Testare-Iasi/events/218963478/
Ianuarie 26 (Cluj)
Mobile Monday Cluj #15: Mobile game development
meetup.com/Cluj-Mobile-Developers/events/177047022/
Ianuarie 27 (Bucureti)
Intalnirea Clubului Antreprenorilor din ianuarie
m e e t u p . c o m / E n t r e p r e n e u r s C lu b - C lu bu l - A nt re pre n or i l or /
events/219800978/
Ianuarie 29 (Cluj)
OWASP Cluj-Napoca InfoSec Event 2015
owasp.org/index.php/Cluj#tab=Upcoming_events
Februarie 5 (Cluj)
Drupal Cluj Meetup
meetup.com/Drupal-Cluj/
Februarie 10 (Cluj)
UI/UX Cluj Meetup#12
meetup.com/UXUICluj/events/177042112/
programare
impul trece, tiina evolueaz, cerinele oamenilor cresc, adaptarea la schimbri n

orice domeniu devine cerin de baz. n acelai timp, ateptrile sunt n cretere
dac vine vorba despre calitate, accesibilitate, securitate i nu n ultimul rnd cost.
Industria de IT din ultimi ani a adus n discuie necesitatea sau inutilitatea arhitecturii de
Levente Veres
Levente.Veres@endava.com
Design Lead
@ Endava
software sau arhitecilor de software.

n articolele ce vor urma doresc s
abordm cteva teme legate de domeniul
arhitecturii de software i cel al rolurilor de arhitect software, business, IT etc.
Vom ncerca s schim un proces de lucru
care s ne ajute la crearea unei arhitecturi. Vom aborda cerinele unui document
SAD (software architecture document), ce
Framework-uri putem aplica (4+1 View
model, Togaf, Zachman), uneltele ce se pot
folosi i desigur nite noiuni care in mai
mult de Business, resurse umane i comunicarea cu alii.
Istoria arhitecturii software
Cuvntul n sine provine din limba

latin architectura, adaptat la rndul su din
cuvntul grecesc arkhitekton. Acesta este
un cuvnt compus din arkhi (lider, ef, cel
pe care se poate urma) i cuvntul tekton
(constructor, artizan, creator, planificator,
maestru n domeniu).
n IT primele noiuni au aprut n ani `60,
urmnd ca dup ani `80 cnd deja sistemele
au ajuns la o complexitatea ce necesita
organizare i planificare mai eficient,
dezvoltatorii au nceput s exploateze
avantajele de a planifica intenionat structura soluiilor n diferite domenii. Au
nceput s defineasc soluii comune pentru probleme specifice sau repetabile,
reutilizabile.
S nu uitam ca n `79 a aprut primul
calculator personal (Apple II) care aducea cu
el VisiCal (predecesorul lui Excel ). n 1981
apare MS-DOS, iar n 1983 apare Word din

buctria firmei Microsoft.
Pn la finele anilor `90 s-au tot definit

metodologii, teorii, best practice- uri n
diferite domenii din industria IT i structuri comune refolosibile. n 1995, Philippe
Kruchten definete modelul arhitectural de
4+1 View unde descrie vederile (view) :
logical view, development view, process view,
physical view i scenarios (cunoscut i sub
numele de use case view).
Punctul culminant l-au adus anii 2000
cnd cunotinele i teoriile acumulate au
nceput s se aplice n practic. Momentan
suntem participani activi la aplicarea i
popularizarea necesitii arhitecturilor
software i metodologiilor aferente.
Din studiile realizate de IEEE am selectat graficul de mai jos care ofer o vizualizare
complet a evoluiei arhitecturii software.
Ce este Arhitectura software?
Arhitectura software poate fi definit

n termeni generali ca structura de nivel
superior a unui sistem. n cartea Software
Architecture in Practice, Third Edition,
aprut n 2012 la Addison-Wesley (autorii
15
programare
Scopul Arhitecturii software.
Scopul unei arhitecturi de software poate fi diferit, de la caz la

caz n funcie de necesitile specificaiilor iniiale. Totui se poate
defini un subset de scopuri comune care vizeaz:
1. Beneficiile care sunt aduse n urma modificrilor.
2. Selectarea motivaiei principale referitoare la crearea sau
schimbarea soluiei? (De exemplu, de ce dorim ca noua aplicaie
de HR s aib acces la cheltuielile personale din aplicaia XYZ).
3. Perspectiva general asupra structurilor, interaciunilor cu
alte sisteme (high level overview)
4. Componentele, cerinele importante. Acestea vor fi punctele critice care pot avea impact major. De exemplu: securitatea
aplicaiei sau aspectul responsiv al interfeei.
Maturitatea domeniul de arhitectur software
Bass, Clements i Kazman) se definete n urmtorul format:

Arhitectura este rezultatul unui set de decizii de afaceri i
tehnice. Schia (desing) n momentul crerii este influenat din
mai multe pri, astfel i execuia va fi influenat de schimbri n
funcie de mediul din jur pe care arhitectul trebuie s cunoasc.
[An architecture is the result of a set of business and technical
decisions. There are many influences at work in its design, and the
realization of these influences will change depending on the environment in which the architecture is required to perform.]
O alt definiie din aceeai lucrare este: Arhitectura software
a unei aplicaii sau sistem este structura sau structura sistemelor,
ce combin elemente de aplicaii, proprietile vizibilitii externe
a acestor elemente i relaia ntre ele.
IASA (The Global IT Architect Association) definete
noiunea de IT arhitectur ca: Arta sau tiina schirii (design)
i arta de a livra strategie tehnologic util.
Dar arhitectura software poate fi considerat ca un mediu
de facilitare de discuii a alegerii unei soluii de aplicaii ntre
solicitanii aplicaiei (business owner, stackeholder) i cei care
vor livra, astfel nct s se ia decizii fundamentale de creare de
aplicaii care pe parcurs vor ajuta ca produsul finit s aib factori
de cerine satisfctoare tuturor. Dintre aceti factori menionm:
eficien de cost, extensibilitate, modularitate, adaptabilitate,
scalabilitate, securitate, calitate etc. .
Concluzionnd, putem considera arhitectura software ca
mediul de definire a structurilor, elementelor i a relaiilor.
16
Lista se poate extinde dup dorinele fiecruia, e important ca

la final s se rspund la ntrebrile:
1. Ce dorete s rezolve arhitectura software?
2. Costurile acesteia? E asumabil de ctre beneficiar?
3. Implicaiile personalelor- stackeholder-i, dezvoltatori,
designeri, arhiteci, project manager-i, administratori de
sisteme.
4. Planul de arhitectur SAD (Software Architecture
Document) .
Ecosistemul de arhitectur IT
Putem considera c o arhitectura software este ncadrat

ntr-un ecosistem organizaional ce e ntreinut de sisteme care
la rndul lor sunt compuse din aplicaii, hardware, structura de
organizaie, surse i structuri de informaii.

Nivelele de arhitectur din IT se pot structura astfel:
1. Arhitectura de ntreprindere (Enterprise) este compus
din arhitecturile de mai jos, dar are un status mai special prin
interferena sa cu mediul de afaceri i cu implicaiile sale asupra
mai multor sub entiti sau firme (Cross Company Boundaries).
2. Arhitectura software, cu scop de definire a designului de
aplicaie, componente/elemente i relaie ntre componente/
elemente.
3. Arhitectura hardware definete designul de hardware necesar cum ar fi CPU, spaiu de stocare, spaiu de memorie, mediu
de transfer de date (Wan, Lan), echipamente conexe (ex.: imprimanta sau echipament de scanare), medii de backup, medii de
funcionare (in house, hosted, cloud).
4. Arhitectura organizaional definete relaiile de afaceri
(business relations), procese de afaceri (business process), structur organizaional (ierarhizare), roluri i responsabiliti,
competentele organizaionale (departamentele) i relaia lor.
5. Arhitectura informaional definete structura entitilor
de date, sursa i organizarea acestora, de fapt structura datelor
i accesibilitatea eficient acestora n diferite baze de date.
Sperm c prin acest prim articol am reuit s v introducem
ntr-un domeniu complex precum cel al arhitecturii software.
17
programare
JavaFX i comunicarea prin RESTful Web Services
Silviu Dumitrescu
O aplicaie client poate accesa resurse distribuite aflate la distan. Exist mai multe
modaliti de accesare a acestor resurse, dar poate cea mai portabil este cea a serviciilor web. n acest articol vom aduce n discuie serviciile REST (Representational State
Transfer), servicii autodescriptive, moderne, cu un API Java ce are evoluie spectaculoas n ultimele versiuni ale platformei Java Enterprise.
Vom ncepe prin discutarea unor aspecte arhitecturale, care in de nelegerea componentelor ce fac parte dintr-o aplicaie distribuit, ce folosete serviciile web.
Java Line Manager

@ Accesa
Arhitectura pe dou nivele (two tiers)
silviu.dumitrescu@accesa.eu
Diana Blan
Diana.Balan@accesa.eu
Java developer
@ Accesa
Aceast arhitectur are dou componente eseniale:

A. Aplicaia client cu urmtoarele
caracteristici:
Acceseaz direct baza de date i
are dezavantajul c necesit cod ce
trebuie modificat pentru diverse tipuri
de baze de date. Se poate ajunge astfel la un bottleneck n cazul anumitor
cereri de date, care necesit un volum
de trafic important pentru transportul
datelor.
Execut logica aplicaiei cu
observaia c aceasta poate fi limitat
de capacitatea staiei client (memorie,
CPU) i n plus necesit cod ce trebuie
distribuit fiecrui client.
B. Serverul de baze de date.
O aplicaie client JavaFX const din
urmtoarele:
o component ce conine fiiere
FXML reprezentnd front-end-ul, clasele corespunztoare controller-ului ce
execut event handling, o clas de lansare
a aplicaiei, fiiere CSS precum i clase de
formatare;
o component ce conine clasele
entitate, care sunt mapate tabelelor bazei
de date;
o component ce conine clasele ce
fac operaii pe baza de date utiliznd
componenta anterioar (clase DAO);
JPA, ce este folosit pentru conectarea
la baza de date i pentru a efectua mai
uor operaiile pe aceasta;
Avantajele folosirii acestei arhitecturi
18
sunt:
Este mult mai extensibil dect arhitectura pe un nivel.
Combin ntr-un singur sistem
logica prezentrii, logica business i
resursa de date.
Poate avea un client pe orice host
att timp ct acesta este conectat printro reea la baza de date.
Are mai puine puncte sensibile,
generatoare de erori, dect sistemul pe
trei nivele.
diverse
aflat pe serverul de baze de date;

web. Aplicaia devine astfel extensibil i
Componentele vor fi publicate ca interoperabil cu diferite tipuri de aplicaii
servicii web;
client.
Serviciile web vor fi dezvoltate utiliExist dou tipuri de servicii web:
znd Jersey, care este o implementare a
SOAP (Simple Object Access
specificaiilor JAX-RS;
Protocol) folosesc mesaje XML ce defi Vor fi deploy-ate pe un server de
nesc arhitectura mesajului i formatele
aplicaie, spre exemplu Glassfish, i pot
acestuia. Aceste sisteme conin deseori
fi consumate folosind HTTP.
o descriere a operaiilor oferite de serviciu, scrise n fiierul WSDL (Web Service
Aadar, serverul de aplicaie va conine
Description Language), care este de fapt
o colecie de servicii web RESTful, care la
un fiier XML.
rndul lor vor comunica prin JPA cu ser RESTful (Representional State
verul de baze de date. Serverul de aplicaie
Transfer) este mult mai potrivit penGlassfish furnizeaz infrastructura pentru
tru scenarii de baz, cu o integrare
ambele API-uri JPA i JAX-RS.
ad-hoc. Sunt mult mai bine integrate
Avantajele folosirii unei arhitecturi
cu HTTP dect SOAP, nu necesit
Arhitectura pe trei nivele (three tiers)
three tiers:
XML sau definiii WSDL. Se bazeaz
Are urmtoarea structur:
Permite o utilizare eficient a
pe specificaiile JSR-311, iar Jersey este
Aplicaia client. Mult mai puine
conexiunii la resursa de date folosind
o implementare a acestora. Serviciile
resurse sunt necesare pe staia client. Nu
connection pooling;
REST folosesc W3C i standardele IETF
sunt necesare modificri dac locaia
Putem modifica business logic-ul fr
(Internet Engineering Task Force):
a afecta software-ul clientului;
HTTP, XML, URI, MIME.
Este o arhitectur mult mai potrivit
pentru scalare i load balancing dect
Vom utiliza serviciile REST pentru
altele;
integrarea prin web i vom utiliza serviciile
Scalarea afecteaz n primul rnd SOAP n aplicaii enterprise ce au scenarii
middle tier-ul.
de integrare care cer caliti avansate ale
Dezavantajele sunt:
serviciilor (QoS) .
Crete traficul de reea;
Vom alege JAX-RS pentru c serviciile
Este mult mai vulnerabil la greeli; sunt mai uor de consumat pentru multe
Obiectele business trebuie gn- tipuri de clieni, n timp ce permite servedite pentru a gestiona integritatea rului s evolueze i s se scaleze. Clienii
tranzaciilor.
pot alege s consume anumite sau toate
aspectele serviciului i s le combine cu
n pofida dezavantajelor anterior alte servicii web.
enumerate, arhitectura pe trei nivele este
Aplicaiile REST sunt simple, lightutilizat frecvent pentru aplicaii mari. weight i rapide pentru c:
Este cea pe care o vom aduce n discuie n
Resursele sunt identificate prin URI,
acest articol i n urmtoarele articole pe
ceea ce furnizeaz o modalitate de adreaceast tem.
sare global.
n partea urmtoare vom face o scurt
O interfa uniform este folosit
trecere n revist a paradigmei serviciu
pentru manipularea resursei.
web, ca modalitate prin care clarificm
Sunt folosite mesaje autodescriptive
ideile i pentru cei mai puin familiarizai
sau metadate pentru resurse.
cu aceast paradigm.
Interaciunile stateful prin hiperlinkuri sunt bazate pe conceptul de stare
explicit de transfer.
Dezavantajele sunt:
Orice modificare n strategia de
business determin o modificare n
logica aplicaiei cu implicaii asupra
fiecrui client. Aceasta poate fi foarte
costisitoare i consumatoare de timp.
Fiecare client necesit o conexiune la
resursa de date.
Restricioneaz sau complic adugarea de caching, mirroring, proxy
services sau tranzacii securizate.
Cum logica de business se afl la client, ntreaga baz de date este expus n
reea.
Servicii Web
Sunt aplicaii ce comunic prin

HTTP n WWW. Ele furnizeaz un
standard ce faciliteaz interoperabilitatea aplicaiilor software ce ruleaz pe o
varietate de platforme i framework-uri.
Interoperabilitatea i extensibilitatea sunt
date de XML. Ele pot fi combinate ntr-un
mod care pierde cuplarea pentru a obine
Aplicaia pe partea de server de operaii complexe.
aplicaie se descrie astfel:
Prin utilizarea serviciilor web o
Va conine business logic-ul pentru a aplicaie pe dou nivele poate fi modificat
efectua operaii CRUD pe baza de date la una pe trei nivele, ce poate opera peste
bazei de date se schimb, mai puin cod
este de distribuit staiilor client;
Serverul de aplicaie manipuleaz
cererile mai multor clieni, reduce traficul de date n reea;
Serverul de baze de date.
REST indic o arhitectur client server fr stare. Un serviciu REST expune o

mulime de resurse ce identific destinaiile
interaciunilor cu clienii. Resursele sunt
identificate prin URI i sunt manipulate
de patru operaii: PUT, GET, POST i
DELETE.
Resursele sunt decuplate de reprezentare astfel nct pot fi accesate ntr-o
varietate de formate: HTML, XML, plain
text, PDF, JPEG i JSON. Metadatele despre resurse sunt folosite pentru a controla
19
programare
JavaFX i comunicarea prin RESTful Web Services
class Hello {
cache-ul, a detecta erorile de transmitere, a negocia cel mai potri- public
private String name=;
vit format de reprezentare i pentru autentificare sau controlul
/**
accesului.
* Default constructor.
*/
Orice interaciune cu o resurs este stateless, mesajul este
public Hello() {
aadar self contained. Avem la dispoziie mai multe tehnici de a
// TODO Auto-generated constructor stub
}
trimite starea precum: rescrierea URI-ului, cookie-uri, cmpuri
hidden. Starea poate fi inclus n mesajul de rspuns pentru a crea
/**
* Retrieves representation of an instance of
stri viitoare ale interaciunii.
* Hello
Clienii serviciului web, care doresc s foloseasc aceste
* @return an instance of String
*/
resurse, acceseaz o anumit reprezentare prin transferarea
@GET
coninutului aplicaiei folosind un mic set de metode remote ce
@Produces(text/plain)
public String sayHello() {
descriu aciunea ce trebuie fcut pe resurs.
// TODO return proper representation object
GET este folosit pentru a obine date sau pentru a efectua

return Hello World+name;
}
o cerere pe o resurs. Datele returnate de la serviciul web sunt
o reprezentare a resursei cerute.
/**
* PUT method for updating or creating an
PUT este utilizat pentru a crea o noua resurs. Serviciul
* instance of Hello
web poate rspunde cu date sau cu un status ce indic succesul
* @param content representation for the resource
* @return an HTTP response with content of the
sau eecul.
* updated or created resource.
POST este utilizat pentru a modifica resursele sau datele
*/
@PUT
existente.
@Consumes(text/plain)
DELETE este folosit pentru a terge o resurs sau date.
public void putText(String content) {

}
name=content;
n anumite cazuri aciunile de update sau delete pot fi fcute }

prin POST, de e-xemplu cnd serviciul este consumat de browsere ce nu suport PUT sau DELETE). Urmtoarele mapri pot fi
Adnotaiile utilizate sunt:
aplicabile pentru PUT sau POST:
Valoarea adnotaiei @Path este un URI relativ. Clasa Java
Creare = PUT dac trimitem ntreg coninutul unei resurse
se va afla, n cazul exemplului nostru, la calea dat de URI-ul
specificate (URL);
/hello. URI-ul este static, dar putem include i variabile n
Creare = POST, dac trimitem o comand serverului penacesta. Template-urile pentru cile URI sunt URI-uri cu variatru a crea o resurs subordonat resursei specificate, folosind
bile incluse n sintaxa URI
algoritmi server-side;
Adnotaia @GET este destinat metodei cererii, mpre Update = PUT, dac modificm ntregul coninut al resurun cu @POST, @PUT, @DELETE, @HEAD i este definit de
sei specificate;
JAX-RS, corespunznd respectiv metodelor similare HTTP. n
Update = POST, dac cerem serverului s modifice una sau
exemplul nostru , metoda anotat va procesa cererile HTTP
mai multe resurse subordonate resursei specificate.
GET. Comportamentul unei resurse este determinat de metoda
HTTP creia resursa i rspunde.
Dezvoltarea unui serviciu web REST cu JAX-RS
Adnotaia @Produces este utilizat pentru a specifica
JAX-RS este un API Java:
tipul MIME media pe care o resurs l poate produce i l tri Destinat s uureze dezvoltarea aplicaiilor ce folosesc arhimite clientului. n cazul exemplului tipul este: text/plain.
tectura REST.
Adnotaia @Consumes este utilizat pentru a specifica
Utilizeaz adnotaii Java pentru a simplifica dezvoltarea
tipul MIME pe care o resurs l poate consuma i care a fost
serviciilor REST.
trimis de client.
Utilizeaz adnotaii runtime, care prin reflecie vor genera
clasele helper i artefactele pentru resurs.
n Eclipse crearea structurii fiierului se face urmnd paii:
Jersey implementeaz suportul adnotaiilor definit de
specificaiile JAX-RS.
O arhiv a aplicaiei Java EE coninnd clasele resursJAXRS vor avea resursele configurate, clasele helper i artefactele
generate i resursa expus clienilor prin deploy-ul unei arhive pe
serverul de aplicaie.
Fie urmtorul exemplu de fiier ce reprezint codul clasei
resursei root a unui serviciu web REST, ce utilizeaz adnotaii
JAX-RS:
package com.example.ws;
import
import
import
import
import
javax.ws.rs.Consumes;
javax.ws.rs.GET;
javax.ws.rs.PUT;
javax.ws.rs.Path;
javax.ws.rs.Produces;
@Path(/hello)
20
Proiectul n care am creat resursa este un Dynamic Web

Project n care:

Arhitectura three-tier folosind REST este dat n diagrama
urmtoare:
Verificarea serviciului se face la adresa: http://localhost:8080/

JerseyFirst/jaxrs/hello
Acest nume este derivat din valoarea tag-ului <displayname> din web.xml, completat cu valoarea lui <url-pattern> din
<servlet-mapping> (automat generate) i de valoarea adnotaiei
@Path.
Paii n generarea unui serviciu web REST sunt:

1. Verificarea urmtoarelor condiii:
Jersey este adugat proiectului;
JAX-RS API este adugat proiectului.
2. Generarea propriu zis a serviciilor web:
Crearea serviciilor REST;
Validarea claselor web service generate;
Validarea configuraiei n fiierul web.xml.
Cnd testm un serviciu web trebuie s avem n vedere
urmtoarele:
Adresa URL reprezint corect endpoint-ul serviciului
deployat i adnotaiile metodei;
Cererile GET, PUT, DELETE, sau POST invoc metodele
potrivite ale serviciului.
Metodele returneaz datele ateptate.
Crearea unui client
Paii de urmat pentru a dezvolta un client al serviciului web

Jersey conine o bibliotec REST ce poate fi utilizat pentru REST sunt:
testarea sau crearea unui client Java.
Asigurarea c proiectul are adugate toate bibliotecile
Vom crea o Aplication Client Project, cu urmtorul cod:
necesare;
Identificarea ferestrei GUI i verificarea locului unde rezulimport java.net.URI;
tatele invocrii serviciului web vor fi afiate;
Urmtoarele informaii sunt utile la dezvoltarea clientului:
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.UriBuilder;
URL-ul serviciului, numele pachetului i clasa n care codul
client va fi generat;
import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.ClientResponse;
Invocarea codului n fereastra GUI.
import com.sun.jersey.api.client.WebResource;
import com.sun.jersey.api.client.config.ClientConfig;
import com.sun.jersey.api.client.config.DefaultClientConfig;
public class Main {
public static void main(String[] args) {

ClientConfig config = new DefaultClientConfig();

Client client = Client.create(config);

WebResource service = client.
resource(getBaseURI());
System.out.println(service.
path(jaxrs).path(hello).accept(MediaType.TEXT_
PLAIN).get(ClientResponse.class).toString());
System.out.println(service.path(jaxrs).
path(hello).accept(MediaType.TEXT_PLAIN).
get(String.class));
Vom reveni n numerele viitoare ale revistei cu aplicaii mai

complexe, care s includ i interaciunea cu o baz de date.
V dorim lectur plcuta i ateptm cu interes ntrebrile
voastre!
Diana Blan, Java Developer la Accesa

Silviu Dumitrescu, Java Line Manager la Accesa
}
private static URI getBaseURI() {

return UriBuilder.fromUri(http://localhost:8080/JerseyFirst/).build();
}
}
21
programare
Competen sau fraud?
n urm cu zece ani la universitatea unde eram student s-a organizat o miniconferin de securitate. Pentru a fi mai interesant,
organizatorii au creat i o pagin de nregistrare care urma s fie deschis pentru a accepta nscrieri ncepnd cu ora 12 la o anumit dat. M pasiona domeniul i mi-am dorit s particip. Mi-am dorit s m nscriu printre primii pentru a-mi asigura locul
i mai ales c au promis c dau cte un tricou la primii 20 de participani care se nscriu.
La vremea respectiv eu lucram ca programator angajat full time i deja adunasem ceva ore de lucru n tehnologia folosit pentru
dezvoltarea paginii de nscrieri. Aa c nu mi-a luat mult timp s descopr o vulnerabilitate i s reuesc s o exploatez n timp util. Am
reuit s m nscriu puin mai nainte de ora oficial. n urmtoarea zi m-am prezentat la conferin la intrare, am salutat politicos,
mi-am spus numele, colegul m-a cautat pe list i m-a gsit destul
de uor. Am tras puin cu ochiul: eram primul 11:58. Perfect.
Uimit puin, acesta a zis: Ah tu eti la, cum ai reuit?. La
ntrebarea mea dac primesc un tricou, el a rspuns c nu, dar
c o s primesc ceva mai bun. n timpul conferinei m-a anunat
public i mi-a nmnat drept premiu cartea Writing Secure
Code a lui Michael Howard i David LeBlanc.
Puin dezamgit, m-am ntrebat oare de ce mi d mie cartea
aceasta. El avea nevoie mai mare de carte, el avea nevoie s nvee
s scrie cod mai sigur nu eu.
Dac deplasm aceast ntmplare ntr-un cadru puin mai
critic cum ar fi de exemplu un site pe Internet unde clienii i
pot crea cont i s i depoziteze banii n cont cu scopul de a-i
folosi mai trziu, cartea i tricoul de mai devreme se transform
n alte lucruri mai de valoare. n loc de un tricou, atacatorul i
dorete s obin banii clientilor, i primete n loc de o carte, ani
de nchisoare.
De exemplu, un individ pe nume Alistair Peckover a fost condamnat prima dat la 26 de sptmni cu suspendare, avnd doar
20 de ani n 2009, pentru c a furat 39.000 lire. n 2010 a fost condamnat din nou la 20 de luni cu execuie dup ce i-a cumprat
22
un Porsche i un lingou de aur n valoare de 30.000 lire. n 2012

este din nou condamnat la 3 ani de nchisoare dup ce a furat
46.000 lire. Cnd a primit ultima sentin judectorul i-a spus : I
believe that I will see you again in the future due to your gambling
addiction and the temptation to use your computer skills to cheat,
which will be hard to resist due to your character.
Computer skills to cheat mi-a atras atenia. Adic el ar fi un
mare geniu sau un super meseria n ale calculatoarelor. Dar dac
ne uitam un pic mai atent la viaa lui, vedem c locuia cu prinii
lui i nu lucra nimic, nici cu coala nu era ocupat. Avea tot timpul
din lume, 24 de ore pe zi, s studieze toate site-urile de jocuri i
s gseasc jocuri care au fost scrise de programatori care nu au
citit cartea Writing Secure Code. Gsea vulnerabiliti n ele i
le exploata pe bani adevrai. Dup multe ncercri i experien
a devenit un expert n domeniu.
De ce se ntmpl lucrurile astea? Din mai multe motive. Ca
s numesc dou: pentru c oamenii sunt lacomi i vor s aib
muli bani, dar i pentru c site-urile sunt scrise de ctre oameni
i este n natura lor s fac greeli.Vulnerabilitile de securitate
nu sunt altceva dect erori de programare. Programatorii nu au
nvat n facultate foarte multe despre vulnerabiliti de securitate. Nici product owner-ii nu le cunosc, aa c cer echipelor de
dezvoltare s implementeze doar feature-urile dorite de business,
ct se poate de repede. Dac reuesc s livreze nainte de termen
primesc bonus! Totui, oricine poate nva despre vulnerabiliti
de securitate dac are ceva timp la dispoziie.
Noi cei care lucrm n departamentul de Application Security
studiem aceste fascinante vulnerabiliti de securitate. Eu le
numesc fascinante pentru c mult lume le vede ca fiind ceva
magic, ceva ce doar geniile pot nelege. Dar de fapt oricine le
poate vedea i nelege, este nevoie numai de timp i dedicare. Noi
descoperim aceste vulnerabiliti n codul scris de programatorii
notri, i sftuim cum s le fixeze i i nvm cum s le previn
data urmtoare.
Pentru a ndeplini acest job am implementat un proces pe
care unii l numesc Secure Software Development Lifecycle. n
mare acesta const n urmtorii pai:
1. Lucrm mpreun cu arhitecii i contribuim la designul unui nou produs, nainte ca acesta s intre n faza de
programare
implementare. n aceast faz definim toate controalele i standardele de

securitate care trebuie implementate n
funcie de funcionalitatea produsului i
locul unde va fi folosit.
2. Stm aproape de echipele de dezvoltare i avem vizibilitate asupra
sprint-urilor astfel nct atunci cnd au
de implementat un user story care atinge
date sau funcionalitate sensibil din
punct de vedere al securitii, programatorii se consult cu noi i mpreun
stabilim cum se va implementa corect.
3. Cnd avem funcionalitatea implementat facem un test de securitate
manual, prin care verificm dac nu
cumva s-au strecurat ceva vulnerabiliti.
Astfel ne asigurm c n producie nu
vor fi probleme. Acest test de securitate implic code review, user story
review i un penetration test pe toat
funcionalitatea nou implementat n
sprint-ul curent.

n biroul din Romnia suntem dou
persoane pe Application Security i avem
aproximativ 16 echipe de dezvoltare. Asta
nseamn o grmada de munc. Aa c am
cerut ajutor. Am cerut ajutorul programatorilor spunndu-le: voi v cunoatei
cel mai bine codul, voi tii cel mai bine
cum funcioneaz aplicaia i voi tii fiecare linie de cod ce face pentru c voi ai
scris-o. Dup care am continuat: avem o
propunere pentru voi, noi v nvm care
sunt vulnerabilitile posibile i cum s le
evitai i voi ne ajutai cu mbuntirea
securitii n produsele la care lucrai.
Aa c acum avem o echip virtual de
Security Champions format din cte cel
puin un programator din fiecare echip
plus reprezentai din celelalte echipe,
cum ar fi QA, DevOps, IT. inem n mod
regulat conferine de securitate interne
cu prezentri i workshop-uri i deseori
invitm i oameni cu expertiz din afara
firmei. Noi i nvm cum s fie hackeri,
cum s foloseasc diferite unelte de securitate cu care s-i testeze produsele, astfel
nct s scrie cod care nu poate fi hackuit
prea uor.
Programul de Security Champions este
eficient pentru c n acest mod cel puin o
persoan se gndete la aspectele de securitate din cadrul echipei.
Este o situaie win-win pentru toat
lumea, att pentru campioni pentru c i
dezvolt skil-uri ninja ct i pentru companie i pentru echipa de security. Aa c
acum noi putem pleca pe o insul exotic
i s stm la plaj, pentru c programatorii notri scriu cod sigur, iar hackerii nu
pot fura bani. Cteodat mai primim un
telefon de la HR care ne informeaz c

nc un developer a trecut la management
sau c au angajat ali cinci programatori
proaspt absolveni de facultate n locul lui
i c trebuie s ne ntoarcem s i nvm
s scrie cod sigur.
Referine
1 h t t p : / / w w w. c r a w l e y n e w s . c o . u k /
Broadfield-hacker-jailed-46-000-fraud/story17502872-detail/story.html
2 http://www.amazon.co.uk/Writing-SecureCode-Best-Practices/dp/0735617228/
r e f = s r _ 1 _ 1 ? i e = U T F 8 & q i d = 1 4 2 11 5 8 8 4 1
&sr=8-1&keywords=writing+secure+code
Cristian erban
Cristian.Serban@betfair.com
Application Security
@ Betfair
23
programare
management
Diminuarea complexitii cu
TDD i Agile
n ultimii ani complexitatea proiectelor a crescut ncet pn la punctul cnd

modalitile utilizate n trecut pentru diminuarea sa au devenit ineficiente. n prima
parte a articolului v voi mprti motivele pentru care consider complexitatea ca
pe un aspect de care ne vom izbi timp ndelungat i despre care cred c va crete standardele a ceea ce nelegem noi prin software acceptabil.
Radu Ometita
radu.ometita@fortech.ro
Software engineer
@ Fortech
24
Complexitatea este legat n primul

rnd de legea lui Moore i de creterea
incredibil a puterii computaionale de care
se dispune n prezent. Aceasta le-a permis
sistemelor software s nceap s fac fa
cu mare uurin problemei complexitii
crescute, n ciuda evoluiei mai lente a
paradigmelor de programare. Chiar i
cu apariia procesrii multicore abia am
nceput s simim saltul n complexitatea
software-ului cnd e vorba de programare
concurent.
ntruct legea lui Moore i-a atins
platoul i se pare c nimeni nu e dispus
s investeasc n creterea puterii de
procesare a nucleelor individuale (dac nu
chiar n eliminarea puterii pe care o au), ne
confruntm cu dilema dificultii scalrii
aplicaiilor noastre. Se pare c nu exist o
soluie facil pentru aceast problem, pe
care s o putem aplica meninnd n acelai
timp stilul i modelul nostru actual folosit
n dezvoltarea de software, potrivit pentru
aplicaii ce ruleaz pe un singur nucleu.
Puterea de procesare sporit din ultima
decad a dus la o cretere a ateptrilor cu
privire la ceea ce trebuie s fac aplicaiile
de business. Una dintre schimbrile cele
mai interesante remarcate de noi este ca
software-ul trebuie s fie tot mai maleabil
si uor de mbuntit pentru a ine pasul
cu ritmul schimbrilor. Aceasta e probabil
principala for motrice pentru Agile i
cauza buclelor de feedback tot mai strnse.
Complexitatea are deci dou surse.

n primul rnd, businessul are nevoie de
timpi de rspuns mai scuri la solicitrile
de modificri, aspect ilustrat de acapararea majoritii proiectelor i firmelor de
software de ctre metodologiile Agile. Nu
am ntlnit pe nimeni suficient de curajos
pentru a ncerca o metodologie Waterfall
pe un proiect complex n prezent. Pe de alt
parte, suntem nevoii s facem fa unor
aplicaii paralele care cresc semnificativ
complexitatea elaborrii software-ului din
cauza creia putem vedea aceast apariie
a paradigmelor programrii funcionale
n majoritatea, dac nu toate, limbajele
principale.
Un cadru (framework) pentru

complexitate
Pentru a nelege de ce par s dea gre

fr drept de apel abordrile vechi cnd
se aplic unor proiecte foarte dinamice e
nevoie de o bun nelegere a noiunii de
complexitate i a modului n care poate fi
ea clasificat. Un astfel de model este cel
utilizat de Cynefin Framework, care clasific complexitatea n patru domenii, fiecare
dintre ele cu propriile abordri. Merit
menionat c nu tot ce funcioneaz pentru un domeniu de complexitate se poate
aplica i altuia.
Modul n care se trateaz o problem
din acest punct de vedere este prin aducerea ei de la un domeniu complex la unul

Waterfall. Un exemplu de sarcina corespunztoare acestui nivel ar fi unul ce
implic scriere de driver-e pentru dispozitive. Dei soluia poate necesita o
experien extensiv, exist o mulime
de Bune Practici pentru a te ghida spre o
soluie acceptabil. Specificaiile nu se vor
schimba foarte mult, ele fiind constrnse
de interfaa hardware.
Complex
Surs fig. - quarterview.com/?p=1091
simplu. Dar felul n care transformi o problem complex ntr-una cu un grad mai
redus de dificultate este diferit de modul
n care transformi o problem complicat
ntr-una simpl. n final este vorba de constrngeri. Constrngerea unui domeniu
complex d natere unui domeniu mai
puin complex, iar constrngerea acestuia
rezult unui domeniu simplu.
Desigur, direcia poate fi i invers
(datorita unui eveniment ce proiecteaz
problema n domeniul haotic, o schimbare n specificaii, direcie sau toate cele
menionate mai sus), caz n care ar trebui
s urmrii cu atenie semnele ce v permit
s ncadrai corect problema n domeniul
su de complexitate i s o abordai ntr-un
mod potrivit.
Se va prezenta n continuare o scurt
descriere a domeniilor de complexitate,
conform definiiei Cynefin Framework.
Simplu
Contextele simple sunt caracterizate de

faptul c rspunsul corect la o problem
este evident. Unele exemple de astfel de
contexte ar putea fi scrierea unui Java Bean
sau a ceva care poate fi fcut ntr-un singur mod. Aceasta este zona Best Practices,
unde cauzalitatea unei chestiuni este clar
neleas.
La acest nivel abordarea unei probleme
ncepe prin evaluarea situaiei i includerea
ei in categoria potrivit. Ulterior se trece la
soluionarea ei ntr-un mod prestabilit.
Dac ne referim la programare, problemele de acest gen pot fi sarcini pe care
le poate ndeplini aproape orice persoan
capabil s urmeze o list de verificare
(checklist). Drept exemplu putei considera
un cod pe care-l poate scrie chiar i un

copil sau non-programatori.
Complicated/Sofisticat
ntruct n limba romn complicat

este apreciat ca sinonimul lui complex,
traducerea lui complicated cu sofisticat ar
acoperi mai bine definiia dat de Cyenfin
Framework acestui nivel de dificultate.
Cynefin Framework utilizeaz termenul complicated. Domeniul complicated e
ceva mai puin restrictiv dect cel simplu
i permite soluii alternative la o problem.
Acesta e domeniul cunotinelor experte.
ntruct poi avea mai mult dect un rspuns bun la o ntrebare, domeniul e de
asemenea unul al Bunelor Practici. Exist
aici i o legtur cauzal, care este totui
destul de ascuns vederii de multitudinea
soluiilor posibile i n mod cert nu e la fel
de clar ca ntr-un domeniu simplu.
Pentru problemele din acest domeniu
evalum prima dat situaia i apoi ne
bazm pe experii, care trebuie s efectueze o analiz ale crei concluzii le utilizm
pentru implementarea soluiei agreate.
Aceast abordare e necesar deoarece nu
exist o soluie care e n mod cert cea mai
bun.
n c e p r i v e t e a c t i v i t i l e d e
programare, putem include aici sarcini
repetitive care cer totui puin analiz
situaional. Un exemplu potrivit ar fi
designul unei aplicaii CRUD. Aceasta
necesit cunoaterea ctorva frameworkuri, baze de date, etc. .Exist ns o
mulime de Bune Practici ncetenite care
pot fi urmate.
La acest nivel cerinele sunt destul de
stabile, permind utilizarea abordrii
Domeniul complex este unul pe care

am nceput s-l ntlnim tot mai des de
ceva vreme ncoace. La acest nivel primim
cerine care se modific rapid pentru a rspunde presiunii externe. Orice modificare
n specificaii va duce la dezvoltarea unei
funcionaliti, iar implementarea sa ar
putea duce la alte schimbri ale cerinelor
dup analiza efectului pe care l are ea
asupra bazei de utilizatori sau a altor
componente ale aplicaiei. Acesta e domeniul designului emergent i el ne permite
s discutm despre cauzalitate doar n
retrospectiv.
Din acest punct abordarea Waterfall
va deveni neputincioas datorit buclelor
sale de feedback foarte mari, iar metodologiile Agile ncep s ctige teren.
Suntem echipai acum pentru a face fa
specificaiilor dinamice, aflate ntr-o continu schimbare.
Cea mai mare problem ridicat de
contextele complexe este elementul de
noutate pe care-l aduc n procesele noastre.
ntruct abia am nceput s facem trecerea
la ele, le nelegem prea puin i tindem s
le considerm doar complicate. Dovad
c lucrurile stau aa sunt ncercrile de a
impune un document cu specificaii ct
mai exact, apariia unei mulimi de reguli
i regulamente care ncearc s controleze haosul aparent, frustrarea produs de
nenelegerea modului n care se ateapt
s evolueze sistemele i lipsa controlului
asupra mersului lucrurilor. n ciuda tuturor celor de mai sus, sistemele complexe
cer experimentri i explorri, pe care
trebuie s le includem n planurile noastre
pentru a obine rezultatele dorite.
n domeniile complexe trebuie s
ncurajezi experimentarea i explorarea.
Aceasta nseamn c trebuie s setezi
proiectul, aplicaia i procesele astfel nct
ele s permit eecuri multiple ieftine n
ncercarea de a obine rezultatul dorit.
La acest stadiu e vorba despre lansarea
unui experiment i evaluarea rezultatelor
post-experiment, urmate de integrarea
soluiei n aplicaie n cazul unor rezultate
25
programare
Diminuarea complexitii cu TDD i Agile
satisfctoare.
Pentru a obine rezultatele dorite trebuie s:
ncurajezi comunicarea n echip.
n acest fel se va putea folosi experiena
colectiv n rezolvarea problemelor.
Creezi bariere. Trebuie stabilit un sistem de constrngeri n interiorul cruia
sistemul poate evolua. Cunoaterea acestor constrngeri clarific ceea ce poate fi
modificat i schimbat, ajutnd n acelai
timp la diminuarea frustrrii generate de
ritmul alert al schimbrilor.
Refoloseti soluii. Se ncearc gsirea unor soluii bune, comune mai
multor probleme i refolosirea lor n
interiorul sistemului. Identificarea acestor soluii ofer o structur mai clar
i un set nou de constrngeri pentru
problem, ajutnd la mutarea problemei dintr-un context complex ntr-unul
complicat.
Haotic
Domeniul haotic este cel al

circumstanelor excepionale. El apare destul de rar i poate fi deosebit de periculos
pentru aplicaia i afacerea ta. Haosul ar
putea fi cauzat, printre altele, de o eroare
mare n modulul de securitate aprut n
sistemul tu aflat n funciune.
Prima msur pe care trebuie s-o iei
n astfel de circumstane este s controlezi
daunele. Aceasta nseamn s nchizi serverele, s deconectezi cablurile de reea,
s-i chemi avocaii i orice altceva poate
minimiza impactul incidentului.
Ca follow-up la trecerea pe context haotic, presupunnd c firma supravieuiete,
pot urma fr rezisten mbuntirile
proceselor i inovarea, ntruct toat
lumea e predispus n astfel de momente
s accepte uor schimbarea pentru a preveni repetarea unor asemenea evenimente.
Evoluia practicilor Agile

Debutul
La nceputurile lor, practicile Agile
aveau rolul de a reduce impactul unor probleme ridicate de domeniile complicate i
ntr-o mai mic msur de cele complexe.
Metodologia preferat atunci era ntructva similar celei Waterfall, care ncepea
s-i arate limitele n contextul creterii
complexitii software-ului dezvoltat (presupunnd ca a funcionat vreodat).
Principalele probleme cu Waterfall au
fost specificarea complet a software-ului
folosit n dezvoltarea software i ciclurile
relativ lungi de release. n vreme ce acestea pot da n mod cert rezultate pentru
domeniile simple i complicate, bucla de
feedback mare ar preveni implicarea clientului, conducnd la rescrieri majore ale
softului de la o versiune la alta.
Metoda Waterfall a fost i nc este o
abordare foarte confortabil i intuitiv,
care creeaz un sentiment de securitate
artificial, ntruct toate lumea i vede de
treab, cu rezultate acceptabile, n conformitate cu specificaiile. Problemele apar
doar la ora deadline-ului, cnd se constat
ca softul nu e exact cel visat de client i fiecare i gsete o scuz. Procesul Waterfall
este confortabil tocmai pentru c nu permite tragerea la rspundere. Nimeni nu
rspunde pentru propriile greeli.
n paralel, echipele Agile au nceput
s rezolve probleme cu grad sporit de
complexitate. Ciclurile de feedback mai
scurte au permis o implicare mai mare i
totodat puin mai stresant din partea clientului, dar echipele au fost n msur s
se adapteze mult mai rapid la modificrile
cerinelor.
Succesul iniial avut cu Agile a condus
uneori la delsare i iluzia c procesul e
unul simplu. Pentru domeniile simple i
Young spirit
Mature organization
A shared vision
Join our journey!
www.fortech.ro
26
complicate este ntr-adevr aa, pentru c

n aceste contexte ne putem baza pe cerine
care evolueaz ncet i conexiuni cauzefect ntructva clare.
Aceast delsare a creat un context ce
a transformat Agile ntr-un set de Bune
Practici, ducnd la relaxarea tuturor sub
impresia c nelegeau Agile. Trebuie doar
s ai stand ups i retrospectiva sprint-ului
i putem uita totul despre forele care au
dus la apariia Agile.
Incidental, acelai lucru s-a ntmplat cu TDD. Datorit naturii simple sau
complicate a proiectelor, TDD a fost redus
la cerina de a avea un set de teste unit
pentru a obine un grad acceptabil de
certitudine cu privire la corectitudinea
codului tu. i a devenit chiar uor. Trebuie
s ai doar (aproape) 100% acoperire. Nu
e nevoie s te gndeti prea mult la cum
structurezi codul de producie sau testare.
Aceast abordare prea profesional i
totul era bine i frumos n lume, pn cnd
a intervenit schimbarea
Nu mai suntem n Kansas
Putei vedea aceast schimbare deoarece multe persoane au nceput s afirme

c metoda Agile i TDD i toate acele practici mrunte i drgue care ne-au fcut s
ne simim foarte profesionali au nceput s
nu mai funcioneze. Ce se ntmpl?
A aprut nevoia ca software-ul s
rezolve probleme complexe i pentru
prima dat am avut hardware-ul care
poate s fac acest lucru. Dezavantajul
este c a lipsit o nelegere clar a modelului complexitii din spatele nevoilor
noastre i presupunnd c dac am face
mai mult din lucrurile pe care le-am fcut
pentru rezolvarea problemelor complicate,
ar putea funciona. Dar aa ceva nu avea
cum s funcioneze.
Problemele complexe au natur
diferit fa de problemele din sfera
complicated datorit schimbrii n
lanul cauzalitii.
Putem vedea cauzalitatea doar n
retrospectiv n
probleme complexe. n timp ce
acest lucru pare
clar acum, nu era
evident atunci. Era
ca i ncercarea de
atingere a curcubeului. Euezi un

proiect i nvei lecia, stabileti un cod
de bune practici care s previn acelai
lan cauzal i ncerci din nou. Din pcate,
natura problemelor complexe nu garanteaz sub nici o form c o astfel de
abordare ar funciona, crend o frustrare
nemrginit.
ntr-un mod ironic, practicile Agile i
TDD ar fi putut fi folosite pentru a ajuta
la rezolvarea unor probleme complexe
n forma lor original, mai puin
instituionalizat, dac forele datorit
crora ele funcioneaz ar fi fost nelese.
De ce nu mai funcioneaz practicile

TDD?
S analizm care este principala problem pe care oamenii o au cu practica

TDD. Dac avei o acoperire complet,
folosind unit tests ale softului, atunci
schimbarea comportamentului softului
va determina euarea testelor. Cte vor
eua? Depinde de schimbare i de numrul
de teste pe care le-ai scris. Reinei c n
domeniile simple i complicated unit tests
sunt indicate, deoarece aceste domenii
sunt aproape imune la schimbare i solidificarea codului de baz este o idee bun
dei aceste teste trebuie vzute mai mult
ca un mijloc de descurajare a schimbrii
dect ca o verificare a corectitudinii.
Atunci cnd softul ncearc s rezolve
o problem complex, n special o problem care nu este chiar clar la acest
moment, codul trebuie s fie schimbat
foarte frecvent. Este necesar ca experimentarea i eecul s fie ieftine. De ce ar
folosi cineva unit tests? Singurul rspuns
plauzibil este acela c din cauza celor mai
bune practici, care nu se aplic evident
domeniilor complexe.
TDD nu a fost iniial despre unit tests.
Accentul, n special pentru un software
nou, a fost pus pe testare funcional (care
din punctul meu de vedere este testare
funcional). Aceste teste sunt magice
n sensul c ele nu testeaz uniti de cod
ci mai degrab comportamente ale sistemului complet. M ntreb cum ar putea
funciona acest lucru pentru probleme
complexe. Crearea de teste funcionale
furnizeaz barierele de care ai nevoie n
dezvoltarea softului dintr-un domeniu
complex. Testele sunt uneori denumite
specificaii executabile.
Testele funcionale nu mpiedic
schimbri la baza codului, ci mai degrab
ncurajeaz acest aspect. Aceste teste se asigur c acest cod respect funcionalitatea
care a fost convenit pn n prezent (problema schimbrii frecvente a softului
a fost unul dintre obiectivele TDD, care

acum pare s fi fost uitat).
Scrierea testelor naintea implementrii ofer o structur iniial
(barier) a funciilor pe care ncerci s
le implementezi. Natura imprevizibil a
ciclurilor Rou / Verde / Refactorizare
se potrivete ca o mnu practicilor
emergente.
Partea de Refactor a ciclului TDD este
ceea ce de obicei se amn n cele mai
multe echipe, prin urmare avem sprinturi
de consolidare. Aceasta este o greeal.
Codul trebuie s fie n cea mai bun form
i extras corespunztor n componente.
Cum poi s faci experimente ieftine dac
codul tu arat ca un bol de spaghete?
Cu siguran TDD pare c ar fi destul de potrivit pentru domeniul nostru
complex. Dar nu poi trata TDD ca un
regulament i s l utilizezi ca atare i s
atepi rezultate n acest domeniu. Este
necesar s lucrezi cu TDD, n acelai timp
s fi contient de cauzele ce au dus la crearea sa i ce anume vrea strategia ta de
testare s realizeze. ntotdeauna trebuie s
ai o strategie de testare.
Mai mult, trebuie s nceap s i plac
Rou/Verde i n special etapa de Refactor.
Acesta este singurul motiv pentru care
codul va fi mai uor de scris. Nu poate
rezolva niciodat toate problemele; dac
apare o schimbare arhitectural major
va dura un timp pn va fi implementat.
Dac este un model pentru schimbare sau
cnd apare un model nou, codul tu l va
oglindi precis, iar implementarea experimentelor va deveni mult mai uoar.
Ce putem spune despre practicile Agile?

De la nceputurile lor, practicile Agile
s-au fcut pe cod testabil i testat. Dac
foloseti un proces Agile i cod netestat nseamn c nu eti foarte Agile (vezi
flaccid scrum), iar proiectul e mai degrab
nou sau se situeaz n domeniul simplu sau
poate complicat.
Una dintre plngerile recente adresate
practicilor Agile a sunat n felul urmtor:
programatorii ar trebui s scrie cod i nu
s-i piard timpul n ntlniri standup lipsite de sens. Aceasta presupune ca aplici
procesul aferent unei probleme simple sau
complicate, ntruct scrierea de cod o poi
face doar dac tii ce ar trebui s fac acel
cod.
Aceasta nu se ntmpl n cazul domeniului complex, care necesit eecuri
ieftine i are cerinele modificate n funcie
de succesul sau eecul diferitelor experimente. Un domeniu complex cere de
asemenea structurarea codului n pri

reutilizabile. Cum poi ti c nu scrii cod
pentru acelai tip de funcionalitate ca
unul dintre membrii echipei tale n lipsa
comunicrii n cadrul echipei?
n domenii complexe comunicarea ar
trebui ncurajat puternic; ntlniri zilnice
de 20 de minute ale membrilor echipei
optimizeaz procesele, ele micornd
nevoia ntreruperilor repetate la intervale
aleatorii pe parcursul ntregii zile.
Cnd ntlnirile stand-up se in doar
pentru c sunt prevzute n regulament i
desconsideri problema pe care ele ncearc
s o rezolve ele devin cu adevrat o pierdere de vreme.
O alt explicaie a eecului metodelor Agile n cazul domeniilor complexe o
reprezint sesiunea de planificare a sprintului n care trebuie s estimezi timpul
necesar implementrii unei funcionaliti.
ntruct domeniile complexe cer experimentarea cu codul, estimrile par
ntructva contraintuitive (nu poi face
previziuni precise despre funcionaliti n
acest context). Problema acestea nu cred
totui c e una relevant n practic. Cred
mai degrab ca planificarea sprint-urilor ar
trebui s creeze o imagine ntructva precis a punctului actual i al celui pe care
dorim s-l atingem pn la urmtoarea
ntlnire, obiectiv pe care l ndeplinete n
mod admirabil.
Concluzii
Nu ne mai putem permite s credem

n magia cuvintelor sacre precum TDD i
Agile. Pe msur ce crete complexitatea
software-ului, ntreaga echip de dezvoltare trebuie s neleag forele care au
dus la apariia TDD i Agile i cum s le
aplice n conformitate cu rolurile lor i cu
o atenie permanent.
Avem un model pentru complexitate
care explic de ce apar aceste probleme
i motivele pentru care nu vom putea
replica succesele noastre trecute n prezent
folosind de fiecare dat aceleai tehnici.
Este acest model precis sau nu? nc nu
tim foarte bine, dar modul n care a fost
el primit i utilizat indic nite corelaii
interesante.
Plafonarea datorat succeselor trecute i creeaz tot felul de probleme, la
fel ca i industriei IT. Nu te relaxa prea
mult n lumea ta i ncearc s nvei n
permanen ceva nou, preferabil ceva ce te
sperie. Dac vrei s te alturi noii generaii
de programatori i de paradigme de programare, las deoparte plafonarea i ncepe
chiar acum s nvei.
27
management
programare
Performana n echipe distribuite
Tiberiu Cifor
tiberiu.cifor@3pillarglobal.com
Engineering Manager
@ 3Pillar Global
tim cu toii ca n zilele noastre una dintre cele mai folosite metode sau moduri de
lucru pentru a gestiona echipe de proiect este Agile. Agile se poate implementa
cu succes folosind Scrum, Kanban sau altele. Toat lumea face Agile, toat lumea
cunoate principiile Agile i toat lumea l implementeaz. Prin natura jobului am trecut prin multe proiecte, de la cele mai mici pn la cele mai mari, de la cele mai uoare
pn la unele dintre cele mai grele proiecte. De-a lungul timpului am citit foarte multe
despre Scrum, despre cum se implementeaz i despre principiile lui, best practices, etc.
. n toate aceste situaii am gsit foarte puine informaii despre cum se poate optimiza
Scrum lucrnd n echipe distribuite, localizate n diferite zone de pe glob, lucrnd la
acelai proiect i ncercnd s aplice aceste principii ce fac din Scrum una dintre cele
mai populare metodologii.
Dac vorbim de succes, fa de anii
precedeni se observ un trend ascendent
asupra ratei de succes a proiectelor ce
folosesc Agile, dar nu numai n cazul proiectelor ce folosesc Agile se observa acest
trend. Mai jos, avei o statistica a ultimilor
doi ani:
Proiecte ce folosesc Agile (2012 vs. 2013):
Proiecte ce folosesc V-model (2012 vs. 2013):
Proiecte ce folosesc Waterfall (2012 vs. 2013):
Legenda
28
Sursa: http://www.planittesting.co.nz/
resource/industry-stats-project-outcomesbased-on-primary-methodologies-2013/
Echipe distribuite - avantaje i dezavantaje
Majoritatea echipelor de proiect n

care am lucrat erau distribuite. Am ntlnit
situaia cnd clientul era localizat n USA
i ntreaga echip de dezvoltare era localizat n Romnia, dar am ntlnit i cazuri
mai complexe cnd echipa de dezvoltare
era localizat n Romnia dar i n USA, la
client. Cred c este una dintre situaiile cel
mai greu de gestionat. n continuare, voi
prezenta avantajele i dezavantajele unei
echipe distribuite. Haidei s aruncam o
privire obiectiv asupra avantajelor ce le
ofer o echip distribuit. n primul rnd,
diferena de fus orar nu trebuie privit ca
un impediment( lucru care de obicei se
ntmpla) ci trebuie privit ca un avantaj.
De ce? Pentru simplul motiv c atunci cnd
una dintre prile echipei nu este disponibil, cealalt echip este la munc, poate
s rezolve unele task-uri, eventualele probleme aprute n sistemul din producie
i aa mai departe. Dac aruncam o privire de ansamblu asupra acestei situaii
observm c ntr-adevr diferena de fus
orar este un avantaj pentru ca asigur pe
o perioad foarte mare dintr-o zi prezena
suportului. Dac se lucreaz la un proiect
care deja se afl n producie acest avantaj
devine poate i mai important.
Educarea clientului i ncrederea n echip
aici de echipe distribuite iar n cadrul acestor echipe vei fi

surprini s vedei c fiecare nelege n felul su rolul pe care l
are n echip i mai ales responsabilitile sale. E foarte important
ca ntr-o echip distribuit aceste roluri i responsabiliti s fie
clar stabilite nc de la nceput. tim foarte bine care sunt principalii juctori ntr-o echip ce adopt Scrum-ul. Dar oare aceasta
situaie este una ideal tot timpul? V spun eu, n majoritatea
cazurilor am vzut oameni implicai n dezvoltarea unui produs
care pur i simplu nu se regsesc n actorii aceia cu care suntem
toi obinuii din Scrum. Un exemplu concret: un client vine i
v spune c el are la dispoziie un Business Analyst care va dori
s lucreze cu echipa n toate etapele de dezvoltare ale produsului.
Instinctiv, noi ca manageri poate am iei la ramp i am ncerca
s analizm dac aceast poziie de BA se ncadreaz undeva sau
dac putem s gsim soluii pentru a optimiza Scrum-ul. Ba mai
mult, am observat cazuri n care apreau i anumite conflicte
pentru c nu-i aa, n Scrum nu avem nici un BA. Cum se poate
rezolva aceast situaie ct mai eficient pentru toat lumea ? De
obicei, propunerile mele merg n direcia n care acel BA ar trebui
oarecum s se transforme ntr-un Product Owner, iar dac avem
un Product Owner de ce s nu lucreze mpreun cu el?
Revenim puin asupra rolurilor i responsabilitilor. De cele
mai multe ori, n echipele distribuite, i mai ales acolo unde sunt
indivizi implicai n tot procesul de development , pot aprea anumite conflicte att de la client ct i de la dezvoltator. E oarecum
firesc ca unii clieni s ncerce s pun n anumite poziii cheie
oameni de la ei, oameni care vor dori s dein controlul la ce se
implementeaz, oameni care vor dori s controleze procesul de
dezvoltare. Bineneles, din nou apar conflicte. Nu e un lucru ru
ca unii clieni s doreasc s participe efectiv la dezvoltarea produsului lor, dar trebuie s ncercam s abordam aceste probleme
directe cu ei i s-i determinm s neleag c noi n calitate de
parteneri ai lor avem mai mult experien n dezvoltarea unui
produs.
Pentru a evita aceste situaii neplcute e foarte important s se
precizeze care sunt rolurile i responsabilitile tuturor oamenilor implicai n acest proces. Cine e responsabil cu adugarea de
Roluri i responsabiliti
noi task-uri n backlog? Cine trebuie s faciliteze comunicarea n
Am ntlnit de-a lungul timpului diferite forme prin care cadrul echipei? Cine este responsabil pentru a conduce discuiile
o echip funciona i aici m refer strict la rolurile i mai ales tehnice? etc.
responsabilitile fiecrui membru din echip. Nu uitai, vorbim
Odat stabilite aceste roluri i responsabiliti sunt anse
De obicei pe mai toate proiectele se lucreaz cu Scrum sau
mai nou cu Kanban. Pn aici toate bune i frumoase. Dar v-ai
ntrebat vreodat ct de bine cunoate clientul metodologia
Scrum? Este un aspect foarte important ce va avea un impact
major n dezvoltarea ulterioar a proiectului cu repercusiuni
destul de ample. n primul rnd unii din clienii cu care lucram
nu cunosc foarte bine ce nseamn Scrum, care sunt principiile
de baz i cum anume se aplic. Ba mai mult, dac lucrm cu o
organizaie destul de mare, acolo vom observa c sunt alte roluri
i responsabiliti. Sigur v-ai lovit de clienii aceia care au manageri de proiect sau care au aa- numiii Line Managers. ntrebarea
e cum se muleaz aceste roluri n Scrum?
Este foarte important n momentul n care se creeaz o echip
nou i se ncepe munca la un proiect s se definitiveze nc
de la nceput toate rolurile la toi indivizii implicai n proiect.
Mai mult, recomandarea mea este s se definitiveze i o scurta
list de responsabiliti pentru fiecare din aceste roluri. Aceste
responsabiliti vor face puin lumin i vor nivela unele conexiuni n cadrul echipei astfel nct fiecare dintre oamenii implicai
pe proiect vor ti ce au de fcut. Am stabilit c e foarte important
s se definitiveze rolurile i responsabilitile pe proiect, dar ce
facem cnd ne lovim de unii clieni reticeni, care sunt foarte greu
de convins asupra acestor aspecte? Rspunsul la aceasta ntrebare
se reduce la un singur lucru: NCREDERE.
n acest punct foarte important, cnd se creeaz echipa e
foarte important ca managerul de proiect, cel ce se ocup de
ntreaga echip de dezvoltare s-i intre n rol. Vorbeam de
roluri, nu? Dar care e rolul principal al unui manager de proiect
n aceast etap? Formarea echipei, adoptarea unui proces comun
pentru toat lumea i mai ales creterea ncrederii.
E foarte dificil s cretem ncrederea ntr-un timp scurt, dar
nu e imposibil.
Recomandarea mea pentru a facilita acest lucru, este de a avea
o ntrevedere direct, fa n fa cu clientul i de a discuta toate
aceste aspecte.
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
29
management
Performana n echipe distribuite
foarte mari ca lucrurile s mearg foarte bine n cadrul echipei i comunicarea direct: ai o problem de rezolvat i tii sigur c te
implicit vei avea un client fericit.
poate ajuta cineva de la client, sau cineva din alt locaie, atunci
apeleaz direct la el. Mai mult, ncurajai folosirea comunicrii
Comunicare eficient
directe dac e posibil, adic telefon, skype sau orice alt mijloc
Muli dintre voi poate v ntrebai cteodat cum putem de apelare direct. E-mail-ul s vina ca ultima soluie. Vei fi
s comunicm mai eficient n cadrul echipei i nu numai. surprini de rezultatele ce pot aprea vizavi de comunicare foloComunicarea joac unul dintre cele mai importante roluri ntr-o sind aceast abordare.
echip distribuit. Dac ntr-o echip care se afl localizat n
Active listening, information radiators i negociere- toate
acelai loc, comunicarea vine de la sine, aici n cadrul unei echipe aceste lucruri duc la o comunicare eficient. Dac nelegem puin
distribuite nu mai e aa uor i trebuie s fim ateni cum putem aceste concepte vom putea s gestionm mai uor situaii oarerupe acele bariere care se vor ridica vrnd-nevrnd de-a lungul cum mai tensionate, sau cel puin vom reui s aducem mai mult
dezvoltrii unui produs.
vizibilitate asupra unui status cerut de un manager sau de client.
Dar dac membrii echipei ncep s comunice exagerat de
Information radiators reprezint n mod normal orice ecran
mult, folosind orice oportunitate pentru a comunica orice legat sau tabel care e vizibil tot timpul acolo unde lucreaz echipa. n
de proiect, nu mai suntem eficieni. O comunicare eficient mod normal, dac echipa ar fi ntr-un singur loc un information
implic o comunicare i o abordare ct mai direct prin care radiator poate fi un board din birou vizibil pentru toat lumea.
ncercm s rezolvm orice situaie aprut ntr-un timp ct mai Cum arat acest board cnd lucrm n echipe distribuite? Acest
scurt. Aceasta este o comunicare eficient.
board se transpune n mediul online i este dat de mai multe tipuri
Sunt sigur c v-ai ntlnit cu situaii n care ai simit pe pie- de rapoarte care sunt generate automat de acel instrument fololea voastr sau ai auzit de la alii, cum c pierdem prea mult sit de echip pentru a msura progresul, de exemplu JIRA. n
timpul n conferine i meeting-uri cu clientul. n momentul n acest caz, information radiators pot fi: burn down chart, burn up
care auzii aa ceva, s tii c cel mai probabil avei o problem chart, cumulative flow diagram, velocity chart. Aceste tipuri de
de comunicare. De ce s nu selectam 1-2 membri din echip care grafice i ofer echipei, indiferent unde se afl ea, posibilitatea de
s participe n asemenea edine prin rotaie? Am eficientizat un a vedea progresul unui sprint, de exemplu. Mai mult, tii foarte
pic? Eu zic c da. Sau de ce s nu avem n fiecare sprint, un om din bine ntrebrile de genul cum stm cu sprintul asta? sau sunechip responsabil cu un asemenea task, acela de a lmuri unele tem on track cu sprintul?. Rspunsul la aceste ntrebri l poate
din requirement-uri. Situaiile pot continua. Ideea este c putem obine oricine, dac se va uita la unul din aceste rapoarte, care
fi eficieni doar prin mici ajustri.
sunt sugestiv reprezentate grafic.
Mai mult, naintea unui release major sau a unui deadline
important ncercai s adunai toat echipa ntr-un singur loc. Ce
poate fi mai eficient dect s ai toat echipa n acelai loc s poat
comunica fa n fa? De multe ori e destul de greu s facem
acest lucru, mai ales cnd vorbim de echipe mari. tim foarte bine
c mai sunt i anumite constrngeri de bugete. Acolo unde este
posibil v recomand din toat inima s ncercai s adunai echipa
ntr-un singur loc.
Dac nu este posibil s adunm ntreaga echip ntr-o singur locaie, ncercai n toate conferinele ce le avei online cu
restul membrilor s v pornii camerele web. Uneori ajut foarte
mult s-i vezi interlocutorul, s observi mimica i expresia fetei
persoanei cu care vorbeti. Prin acest lucru discuiile devin mai
amicale, mai deschise i cu siguran o s observai ca devin i
Exemplu de Burn down chart:
mai eficiente.
Vreau s mai fac o sugestie: ncurajai toat lumea din echip
s abordeze direct o persoan care o poate ajuta. Facilitai
Exemplu de Burn up chart:
Sursa: http://www.agilemodeling.com/essays/communication.htm
30
Menionam mai sus de Active listening. n echipele distribuite acest concept joac un rol consistent. n mod normal cnd
ascultm pe cineva o facem n mod pasiv. n metodologia Agile,
programare
acest mod activ de asculta (Active listening) se refer la faptul
c toat lumea este implicat ntr-o discuie n mod activ, adic
toat lumea trebuie s furnizeze ntrebri i rspunsuri respectnd nite reguli.
Vorbim aici de trei nivele cnd vine vorba de Active listening:
Internal Listening - participanii sunt doar ateni, i de obicei se ntreab dac ce se discut i afecteaz.
Focused Listening - participanii arat c sunt interesai de
discuie i ncearc s se pun n postura celui care vorbete.
Global Listening - participanii arat implicare, pun ntrebri, critic unele raionamente, sunt respectuoi i arat toate
aceste lucruri de obicei prin gesturi i emoii.

n concluzie
Aadar, acest subiect este unul foarte vast i necesit poate

multe dezbateri. n acest articol am punctat doar cteva dintre
problemele reale cu care poate muli din voi se confrunt atunci
cnd lucrai n echipe distribuite. Ultimii ani ne-au dovedit c din
ce n ce mai multe companii opteaz pentru echipe cu membri
plasai n diferite coluri ale lumii, din diferite considerente. Acest
lucru reprezint o provocare att pentru manageri ct i pentru
echipa n sine. Felul n care reuesc oamenii s interacioneze, s
depeasc anumite piedici i mai ales s aduc valoare n cadrul
unei echipe de dezvoltare face din ntreaga echip un model de
lucru . Proiectele i metodologiile evolueaz, lumea ce ne nconjoar este ntr-o continu micare, influennd mecanismele ce
n ceea ce privete negocierea, sunt foarte multe lucruri inte- fac dintr-o simpl echip o echip de succes.
resante despre negociere, dintre care cel mai important lucru
este c ntotdeauna negocierea trebuie s se bazeze pe respect,
nelegere fa de interlocutor i pe argumente valide care s strneasc atenia celui cu care discutai pe un anumit topic.
Esenial este ca n calitate de manageri s v integrai n
echip pentru a nu fi privii doar ca nite efi. n acest fel vei
contribui mai mult la o comunicare deschis i mai ales eficient.
31
programare
Cinci sfaturi practice pentru

Code Review n Scrum
n fiecare sptmn, la Mozaic Works, n echipa de dezvoltare de produse, descoperim

2 - 3 buguri n produsul la care lucrm n timpul sesiunii de Code Review. Acest lucru
se ntmpl n ciuda faptului c lucrm ntr-un mod foarte structurat i aplicm ATDD
i Test First/TDD.
Mai mult, dezvoltatoriiiliderii tehnicise plng la noi ori n comunitate ori n timpul
sesiunilor de coaching sau workshopuri despre anumite aspecte ale revizuirilor de cod.
Alexandru Bolboac
alex.bolboaca@mozaicworks.com
Agile Coach and Trainer, with a
focus on technical practices
@Mozaic Works
Sfatul #1: Discutai guideline-urile

cosmeticedoar o singur dat
Exist dou tipuri principale de

guideline-uri:
Cosmetice:indentation, spaces vs.
tabs, naming policies, curly braces, positioningetc. ;
Tehnice: cum s scrii cod ca s evii
greelile commune.
Programatorii vor dezbate Guidelineurile Cosmetice ore n ir. Dovada este
pe google, dar nu a cutatabs vs. spaces debatedac a avea multe de fcut.
Aadar,Guideline-urile Cosmeticear trebui
s fie discutate o singur dat i introduse
n setrileIDE. Ne putem obinui cu scrierea de acolade pe urmtoarea linie dup
numele funciei; nu merit s purtm o
dezbatere pe aceast tem . ns consistena
codului este cea mai important i fiecare
echip Scrum trebuie s lucreze dup
Guideline-uri Cosmeticecomune.
Sfatul #2: Pornete cu un numr minim

de principii derivate din arhitectur
D o c u m e nt e l e l u n g i d e g u i d e line-uri erau des ntlnite atunci cnd

lucram ca junior developer. Liderii tehnici obinuiau s copieze principiile
Microsoft sau s i ndrepte pe dezvoltatori ctre acestea. Dei acestea m ajutau
s scriu cod mai bun, era imposibil s le
in minte pe toate.
Exist un mod mai simplu. O arhitectur bun implic o analiz de risc,
modele de cod i guideline-uri de urmat.
32
Guideline-urile pot fi legate de securitate (

ex.toate datele legate de dosarul pacientului trebuie criptate), testare ( ex.folosim
peste tot dependency injection pentru a
uura testarea automat), performan
(ex.folosii un profiler pentru a msura
timpul de execuie pentru toate query-urile
din modulul de raportare) etc. . Acestea
sunt primele guideline-uri: specifice, contextuale i care ajut la evitarea greelilor
comune.Iar aceasta ne duce la ..
Sfatul #3: mbuntete guideline-urile

n funcie de greelile din trecut
Ne aminteam de vremurile n care

liderul de echip ne ddea n prima zi a
unui proiect s citim un document deguideline-uride 20 de pagini. Citirea acestuia
consuma mult timp i nu reineam aproape
nimic. Cnd am ajuns lider tehnic, am
decis s mbuntesc abordarea. Iat cum:
Principiile tehnice sunt n general
bazate pebest practices;problema cubest
practiceseste c nu toatebest practicespot
fi aplicate pe toate produsele. Aa c prefer
denumirea de reguli care ajut la evitarea
greelilor comune. Cum tim care sunt
greelile comune? Simplu, trebuie nti s
le facem. Unii dintre voi probabil v vei
ncrunta, dar dac eti onest cu tine nsui
vei realiza c faci destule greeli. Eu fac
destule greeli, ns am sprijinul colegilor
n a fi onest cu mine nsumi. Cum ar fi s
te bucuri de avantajul greelilor pe care le
faci?
Iat cum funcioneaz acest ciclu
programare
virtuos:
Scrie coding guidelines -> F code
rev iew -> Analizeaz gre elile ->
mbuntete coding guidelines.
Sfatul #4: Folosete diferite tipuri de

Code Review
n echipele cu care am lucrat am

ntlnit trei tipuri dominante de revizuire
de cod: over-the-shoulder, folosind
untoolipair programming.Fiecare are
att avantaje ct i dezavantaje i de aceea
se merit s le combinm.
Scopul revizuirilor de cod este s evitm greelile sau aa cum le numim n
industrie, bug-urile. Un efect secundar
ar fi s nvm citind i discutnd codul
altcuiva. Prima dificultate cu revizuirea
codului n Scrum este s construim disciplina. Dac ai nceput de curnd s faci
code review n Scrum, trebuie s stabileti
clar cnd o s l faci. Ca de exemplu: o dat
pe sptmn sau cnd un user storyeste
gata. Odat ce ai creat obiceiul de a
facecode reviewn Scrum, strategiile pot
varia.
De exemplu, la un program foarte
complicat, am ajuns s folosesc urmtoarele tipuri decode review:
Over the shoulder- eu merg cteodat
lng colega mea Claudia i m uit la
codul pe care l scrie. i ea face la fel; de
fapt, nu mi este niciodat ruine s i cer
ajutorul cnd lucrez la untask.
Programat - n fiecare sptmn,
avem o sesiune de o or de revizuire de
cod.
Pair Programming- cnd avem un
task mai complicat sau ne decidem s
ncercm un mod nou de a face lucrurile.
Ocazional - cam o dat pe lun, m
uitla ntmplarela pari din cod pentru a vedea dacnu cumva ar fi existat
moduri mai bune n care ar fi putut fi
scris.

experimentatcolegul. Revizuiete conPentru revizuiri de cod n Scrum mai
form cu coding guidelines dar i pentru folositoare, urmeaz aceste reguli:
lizibilitate,simplitate, uurina de schim Discut guideline-urile cosmetice
bare i securitate. Noteaz-i problemele
doar o dat, i introdu-le n setrileIDE.
constatate i d-le mai departe Scrum
ncepe cu un document minim
Master-ului.
de coding guidelines care rezult din
O dat pe sprint, programeaz o sesiarhitectur.
une de 30 cu echipa n care s analizai
Execut revizuiri de cod i noteaz
mpreun o parte din codul scris n
problemele gsite.
timpul sprint-ului. D mai departe
Analizeaz problemele la retrospecrezultatele revizuirii ctre ScrumMaster.
tive i mbuntete guideline-urile n
Cel puin o dat la 4 sprint-uri pune
funcie de greelile trecute.
un dezvoltator mai experimentat s se
Folosete strategii diferite pentru
uite la pri aleatorii ale codului pentru
revizuirea codului:Over the shoulder,
30-60. Concluziile ar trebui s mearg
pair programming, planificate, ntmpl(nici o surpriza aici) la ScrumMaster.
toare, printr-o aplicaie specializat.
Discutai constatrile la retrospec Ai ncredere n colegii ti!
tiv. Scrum Master-ul ar trebui s decid
un program, n funcie de numrul de
probleme identificate. Retrospectiva va
duce la o actualizare a coding guidelines.
Aceast strategie are avantajul c pune
la treab creierele tuturor dezvoltatorilor
nu doar ale liderilor tehnici.
Sfatul #5: Ai ncredere n colegii ti
Persoanele care erau lideri tehnici naintea tranziiei la Scrum tind s devin
gatekeeper-i. O greeal tipic este c vor
s fac toate revizuirile de cod n Scrum
pentru a asigura o calitate nalt.
Dei scopul lor este bun, punerea n
aplicare nu ajut echipa. Un lider tehnic
care insist s valideze singur tot codul
va deveni un bottleneck foarte curnd.
Dezvoltatorii din echip vor fi slab
motivai s i asume responsabilitatea
pentru codul pe care l scriu dac tiu c
cineva l pzete. De asemenea, liderul
tehnic risc s se separe de echip pentru
c el este evident deasupra celorlali colegi.
ncercai s ntoarcei lucrurile pe
dos i vei obine o echip funcional,
productiv care nva mpreun. Un fost
lider tehnic ndrum i ajut toat lumea s
creasc prinpair programming, ajutndu-i
cu sarcini dificile sau oferind minisesiuni
de formare. Dezvoltatorii i asum responsabilitatea pentru codul lor deoarece
i revizuiesc reciproc codul. Toat lumea
are roluri egale, dar toat lumea contribuie
n echip cu ce are mai bun de oferit: programatorii juniori cu abilitile i timpul
lor, dezvoltatorii seniori cu soluii inteligente i liderii tehnici cu creterea fiecrui
membru din echip.
ncrederea n colegii ti va duce echipa
la un mod de lucru mult mai eficient.
Noi nu folosim un tool pentru code

review. Ne uitm la cod, discutm, decidem ce mbuntiri am putea aduce i le
aplicm ct mai repede cu putin.Cum
procedezi ntr-o echip mai mare?
Propunem urmtoarea strategie pentru cei
ce revizuiesc cod n Scrum:
Pair programming pe user storiescomplexe. n cazul n carestory-ula
fost complet dezvoltat folosind pair
programming, considerm c este deja
revizuit.
Cnd un story este gata, revizuiete-l
cu un coleg. Nu este necesar s fie mai Sumar
33
programare
programare
Convergena documentaiei ntr-un

proiect software multimodular:
o abordare bazat pe Build Automation
ocumentele explicative ale produselor software sunt folosite ca manuale de

referin pentru proiectanii interfeelor utilizator, pentru programatorii care
scriu codul i pentru testerii care se asigur c produsul funcioneaz corect.
ntr-o aplicaie multimodular, fiecare component este dezvoltat i lansat
independent. Pstrarea documentaiei actualizate pentru fiecare component nu
este uoar deoarece nu totul ine doar de redactarea ei, ci i de centralizarea tuturor
documentelor n aa fel nct s fie gsite uor de ctre persoanele interesate.
Context
Alexandru Albu
alexandru.albu@isdc.eu
Senior Developer
@ ISDC
S copul ar ticolului de fa este

prezentarea unei abordri pentru simplificarea acestui proces, bazndu-se pe
Build Automation1, care s colecteze i s
publice documentele.
Vom trece mpreun prin procesul de
configurare al artifactelor Apache Maven2,
al serverului Jenkins CI 3, pentru ca n
final vom ajunge la crearea unui proiect ce
regenereaz un website care reflect starea
actual a ntregului proiect, oferind acces
la toate documentele disponibile dintr-un
singur loc.
Studiul nostru de caz este un framework scris n limbajul de programare
Java, care este format din mai multe module
Maven. Fiecare modul conine unul sau
multe documente scrise n Markdown 4.
Documentele sunt scrise de ctre programatori, iar acestea pot fi readme-uri5,
howto-uri,documentaii tehnice6 i altele.
Ce vrem s obinem?
nainte s ncepem, va trebui s ne

imaginm cum va arta soluia final. Ne
dorim o pagin html frontal care s afieze
cele mai recente documente scrise de ctre
programatori pentru modulele lansate.
Livrarea mpreun a release note-urilor
1 http://en.wikipedia.org/wiki/Build_automation
2 http://maven.apache.org/
3 http://jenkins-ci.org/
4 http://en.wikipedia.org/wiki/Markdown
i a altor documente cu produsul software

i JavaDoc reprezint o practic obinuit.
Ele nsoesc produsul, iar cu ajutorul lor,
consumatorii produsului l pot folosi i
nelege corect.
Prin lansarea artifactelor Maven,
fiierele compilate ajung ntr-un depozit
(Repository) de cod structurat. n acest
depozit pot ajunge nu doar fiierele compilate, ci i JavaDoc-ul, codul surs sau un
ntreg website ce prezint informaii despre
dependenele proiectului, informaii despre issue tracking, integrare continu (CI),
echip i multe altele.
Website-ul proiectului este cel mai
important element n atingerea scopului
nostru, pentru c acesta va agrega toate
legturile spre website-urile fiecrui modul
ntr-o singur pagin html.
Imaginai-v c pagina html arat n
felul urmtor:
<div>
<h1>module1</h1>
<a href=modules/module1/index.
html>About</a>
<a href=modules/module1/Readme.html>Readme</a>
<a href=modules/module1/ReleaseNotes.html>Release Notes</a>
</div>
<div>
<h1>module2</h1>
<a href=modules/module2/index.
html>About</a>
<a href=modules/module2/Readme.html>Readme</a>
<a href=modules/module2/ReleaseNotes.html>Release Notes</a>
</div>
5 http://en.wikipedia.org/wiki/README
6 h t t p : / / e n . w i k i p e d i a . o r g / w i k i /
Technical_documentation
34
Acest model presupune prezena

fiierelor referite pe disc, acestea fiind
generate n timpul procesului.
programare
index.html (pagina noastr)
[modules]
[module1]
index.html
Readme.html
ReleaseNotes.html
[module2]
index.html
Readme.html
ReleseNotes.html
Abordare

![Alternative text]
(images/image1.jpg Text descriptiv)
Dup ce websiteul este generat, ne ateptm s gsim

fiierele noastre n directorultargetastfel:
[target]
[site]
Readme.html
ReleaseNotes.html
[images]
image1.jpg
image2.jpg
Modulele noastre sunt artifacte Maven, iar abordarea este

Cele dou fiiere html ar trebui s fie referite n cadrul fiierelor
bazat pe Maven Build Lifecycle7.
html generate de ctre plugin. Pentru a realiza acest lucru, avem
nevoie s-i comunicm lui Maven urmtoarele instruciuni:
Generarea site-ului unui modul
1. nainte de a genera website-ul, copiai toate fiierele *.md
Generm site-ul folosind maven-site-plugin8. Folosind doar
dinsrc/site/resourcesnsrc/site/markdown. Atenie, directorul
acest plugin putem genera elementele implicite, cum suntProject
nou poate fi inexistent.
Summary,Project Plugins,Dependencies i altele.
2. Generai website-ul pentru proiect, dar n rezultatul final
Cu puin configurare i ajutor, putem interveni n fluxul noreste de preferat s existe referine ctre documentele genemal al plugin-ului. n acest mod putem include fiierele noastre
rate pe baza fiierelor Markdown. Avem un fiier Readme.
Markdown ca fiiere html, referite din website-ul generat.
mdi unul ReleaseNotes.md, deci ar trebui s fac referire la
Ca s transformm fiierele Markdown n html, avem nevoie
fiiereleReadme.htmli ReleaseNotes.html.
de doxia-module-markdownca dependen pentru acest plugin.
3. Dup ce ai terminat de generat, tergei directorul src/
Folosind acesta, procesul de generare al website-ului se uit n
site/markdown. Codul trebuie s rmn curat, fr fiiere
interiorul directoruluisrc/site/markdowni convertete fiecare
duplicate.
fiier cu extensia .mdntr-un fiier html.
ncepem cu cel de-al doilea punct, prin descrierea referinelor
Aceast etap poate prea simpl, dar dac fiierele noastre spre viitoarele fiiere html n cadrul src/site/site.xml:
*.md conin imagini, acestea sunt pur i simplu trecute cu vederea <?xml version=1.0 encoding=UTF-8?>
de ctre plugin. Acest plugin doar copiaz coninutul directorului <project xmlns=http://maven.apache.org/DECORATION/1.4.0 xmlns:xsi=http://www.w3.org/2001/XMLsrc/site/resources.
Schema-instance xsi:schemaLocation=http://maven.
De asemenea, noi dorim ca fiierele noastre Markdown s fie apache.org/DECORATION/1.4.0 http://maven.apache.org/
http://maven.apache.org/
accesibile programatorilor i n modul offline, ei putnd oricnd xsd/decoration-1.4.0.xsd
DECORATION/1.4.0 >
arunca o privire peste ele. Referirea imaginilor din directorul
tem, reclame i alte configurri ale site-ului
src/site/resourcesva funciona doar n modul offline, deoarece 
Ideal ar fi s avem toate fiierele Markdown n directorulsrc/ <menu name=Developer documents>
name=Readme href=Readme.html/>
site/resources, referind imaginilie din src/site/resources/ima- <item
<item name=ReleaseNotes href=ReleaseNotes.html/>
ges, fiind mai simplu dinimages(ca director relativ) deoarece </menu>
dup generarea website-ului coninutul directorului imageseste 
contopit cu celelalte imagini pe care plugin-ul le genereaz n
<menu ref=reports/>
</body>
directorul target/site/images.
n concluzie, directorul srcal unui modul are urmtoarea </project>
structur:
Plugin-ul citete aceste instruciuni i genereaz website-ul n
[src]
concordan. Am adugat un nou meniu ce refer documentele
[main] codul surs
noastre.
[site]
Primul i ultimul punct implic manipulare de fiiere, iar
site.xml
acest lucru este o sarcin perfect pentru un task Ant. n Maven
[resources]
putem folosimaven-antrun-plugin pe care l configurm s exe Readme.md
cute dou sarcini:
ReleaseNotes.md
prima execuie creeaz directorul src/site/markdowni
[images]
copiaz toate fiierele *.md n interiorul lui. Acest lucru trebuie
image1.jpg
fcut nainte de nceperea procesului de generare, deci n faza
image2.jpg
de pre-site;
cea de-a doua execuie terge directorul src/site/markdown,
n interiorul fiierului Readme.mdgsim referinele spre
iar acest lucru trebuie fcut dup ce website-ul este generat, deci
imagini:
dup faza de site.
7 http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
8 http://maven.apache.org/plugins/maven-site-plugin/
Mai jos este prezentat fiierulpom.xmlrezultat:

<project .. >
35
programare
Convergena documentaiei ntr-un proiect software multimodular
<dependencies>
...
</dependencies>
<build>
<!- pregtete fiierele Markdown pentru Maven
Site-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>pre-markdown</id>
<phase>pre-site</phase>
<configuration>
<tasks>
<delete dir=${project.basedir}/

src/site/markdown />
<mkdir dir=${project.basedir}/
<copy todir=${project.basedir}/
src/site/markdown>
<fileset dir=${project.basedir}/
src/site/resources includes=**/*.md />
</copy>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
<execution>
<id>post-markdown</id>
<phase>site</phase>
<configuration>
<tasks>
<delete dir=${project.basedir}/
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
<!generatorul de site e legat de
sectiunea de raportare -->
<plugin>
<artifactId>maven-site-plugin</artifactId>
<version>3.3</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.doxia</groupId>
<artifactId>doxia-module-markdown
</artifactId>
</dependency>
</dependencies>
</plugin>
</build>
<reporting>
<outputDirectory>${project.build.directory}/site</outputDirectory>
<!configurare pentru alte lucruri legate de
36
raportare, cum sunt

plugin -->
</reporting>
</project>
maven-javadoc-plugin, maven-jxr-
Cu ajutorul comenzii mvn sitewebsite-ul dorit va fi generat

n directorul target/site.
Deploy-ul site-ului unui modul
Urmtoarea faz n atingerea scopului nostru este s mpachetm website-ul generat ntr-un fiier jar care s fie ncrcat n
Maven Repository.
Plugin-ulsitetie cum s creeze un fiier jar pe baza fiierelor
din directorul target/site. Tot ce trebuie s facem este s apelm mvn site:jar, dar cu o singur remarc: fazapre-siteeste
executat doar dac apelm mvn site, fr scopul :jar. Pentru a
fi siguri c fiierele Markdown sunt luate n considerare chiar i
cnd directorul targeteste gol sau inexistent, ar trebui s apelm mvn site site:jar.
Rezultatul este un fiier jar nou,target/module1-site.jar. Ca s
putem considera acest pas complet, mai trebuie s ncrcm acest
fiier jar n Maven Repository. Acest lucru este posibil cu ajutorul
Maven Deploy Plugin9.
Proiectul resurselor
Scopul acestui proiect este agregarea tuturor resurselor disponibile ntr-un singur website. Pe lng documentaiile modulelor,
el poate ine i documente generale, cum ar fi primii pai ai programatorilor care intr pe proiect sau documentaii tehnice de
ansamblu. Pentru acestea, maven-site-pluginpoate fi aplicat
folosind aceeai manier ca i n cazul modulelor.
Pentru a descrca website-urile generate folosim Maven
Dependency Plugin10. Acesta ne ajut s obinem artifactele i
fiierele *-site.jarncrcate la pasul anterior. Scopul nostru aici
este s dezarhivm toate aceste fiiere n interiorul directorului
target/site/modules, iar astfel putem menine structura dorit
pentru website.
Pentru a obine arhivele *-sitepentru module, toate trebuie
declarate ca dependene ale proiectului resurselor n fiierul pom.
xml:
<project .. >
<dependencies>


<!-...
-->
<dependencies>
<build>
<plugins>
9 http://maven.apache.org/plugins/maven-deploy-plugin/
10 http://maven.apache.org/plugins/maven-dependency-plugin/






<plugin>
<artifactId>maven-dependency-plugin
</artifactId>
<executions>
<execution>
<id>sites-modules</id>
<phase>compile</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<classifier>site</classifier>
<!acesetea sunt importante, aici se
enumer toate artifactele care sunt biblioteci ale
proiectului (module), separate prin virgul (,) -->
<includeArtifactIds>
module1, module2, ...</includeArtifactIds>
<failOnMissingClassifierArtifact>false
</failOnMissingClassifierArtifact>
<outputDirectory>
${project.build.directory}/site/modules
</outputDirectory>
<useSubDirectoryPerArtifact>true
</useSubDirectoryPerArtifact>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Acest plugin va dezarhiva coninutul fiecrui website de

modul ntr-un subdirector separat din cadrul target/site/modulesal proiectului resurselor.
Ultima chestiune important aici este proiectarea
fiieruluiindex.htmln aa fel nct el va conine referine ctre
toate sub-site-urile modulelor. Pentru c modulele noastre sunt
versionate, vrem ca proiectul resurselor s-i dea seama singur
de cile ctre sub-site-uri. Dac facem pagina de index dinamic,
putem aduga foarte uor un script care populeaz pagina cu
coninutul corespunztor, prin declararea unui vector ntr-un
fiier .jsseparat, ca i n exemplul de mai jos:
var modules = [
module1-1.3-SNAPSHOT-site-jar,
module2-1.5-site-jar,
...
];
index.html>About</a>
<a href=modules/module2-1.5-site-jar/
Readme.html>Readme</a>
ReleaseNotes.html>Release Notes</a>
</div>
Fiierul nostrumodules.jseste populat n timpul procesului

de build al proiectului resurselor cu ajutor din partea groovymaven-plugin. Scopul acestuia este acela de a executa un cod
care itereaz prin directoarele din cadrul target/site/modulesi
imprim numele lor n fiierul /site/config/modules.js, iar n
acest fel noi obinem vectorul de ci spre module. Codul poate
fi citit mai jos:
...
<plugin>
<!imprim n config/modules.js numele directoarelor

corespunztoare -->
<groupId>org.codehaus.mojo</groupId>
<artifactId>groovy-maven-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
<![CDATA[
println(==== Creeaz config/modules.js ====);
File modFile = new File(
${project.build.directory}/site/config/modules.js);
BufferedWriter modWriter = new BufferedWriter(
new FileWriter(modFile));
modWriter.writeLine(var modules = [);
new File(
${project.build.directory}/site/modules).eachDir()
{ dir -> modWriter.writeLine( + dir.getName() +
,);
}
modWriter.writeLine(];);
modWriter.close();
]]>
...
</source>
</configuration>
</execution>
</executions>
</plugin>
Prin apelarea mvn site site:jarn cadrul proiectului resurselor

obinem arhiva website-ului dorit. Aceast arhiv poate fi mai
apoi ncrcat ntr-un Server Web HTTP i fcut accesibil tuturor celor interesai.
Concluzii
Avnd toate modulele configurate i proiectul resurselor

creat, toate comenzile mvnpot fi apelate cu uurin de ctre
Jenkins CI, iar website-ul final poate fi ncrcat pe un Server
Web HTTP ca pas post build. De fiecare dat cnd un modul
Codul JavaScript poate utiliza vectorul modulesi introduce este lansat, sub-website-ul lui este publicat, iar website-ul princiurmtoarele elemente DOM n pagina index:
pal poate fi regenerat. n acest fel ne asigurm c documentaiile
cele mai recente sunt disponibile programatorilor, fr a fi nevoie
<div>
<h1>module1</h1>
de niciun efort sau intervenie suplimentar. Toate acestea sunt
<h2>Version 1.3-SNAPSHOT</h2>
fcute n spiritul integrrii continue.
<a href=modules/module1-1.3-SNAPSHOT-site-jar/
index.html>About</a>
Readme.html>Readme</a>
ReleaseNotes.html>Release Notes</a>
</div>
<div>
<h1>module2</h1>
<h2>Version 1.5</h2>
37
programare
programare
Clasificare de Text la Scar Larg
n ultimii ani numeroase probleme precum detectarea fraudelor, detectarea mesajelor nedorite (spam), clasificarea imaginilor, determinarea subiectului unui articol
.a. au fost rezolvate cu ajutorul inteligenei artificiale. Odat cu creterea numrului
de utilizatori de internet, dimensiunea datelor care trebuie procesate devine tot mai
mare, astfel stocarea i procesarea acestora pe un singur server este foarte dificil, soluia
fiind procesarea lor ntr-un sistem distribuit.
Cristian Ra
Cristian.Rat@Yardi.Com
Software Developer
@ Yardi
38
Clasificarea este un proces de luare

a unei decizii pe baza exemplelor unor
decizii corecte, prin urmare este o tehnic
de nvare supervizat, deoarece, pentru
luarea deciziilor are nevoie de un set de
date preclasificat. Prin procesul de training din acest set de date va rezulta care
proprietate a datelor indic apartenena
la o anumit clas i va fi salvat ntr-un
model care va fi folosit pentru clasificarea
datelor noi.
Procesul de construire a unui sistem
de clasificare automat este acelai indiferent de algoritmul de clasificare folosit, i
este alctuit din mai multe faze: procesarea
datelor, training, testare i ajustare, validare (testare final), livrare n producie.
Clasificarea textului este de fapt asocierea dintre un text i o categorie de text
predefinit. Fiecare cuvnt care apare n
document este considerat un atribut al
documentului, astfel pentru fiecare document se construiete un vector de atribute,
coninnd cuvintele din text. Pentru a
mbunti procesul de clasificare se pot
elimina anumite cuvinte care apar foarte
des ntr-un vocabular (ex: i, de, o, un),
sau se pot grupa cuvinte n grupuri de 2-3
numite n-gram-uri.
Au fost dezvoltai mai muli algoritmi
prin care se poate rezolva aceast problem de clasificare: Naive Bayes, arbori
de decizie, reele neuronale, regresii logistice .a..
Unul dintre cei mai folosii algoritmi
pentru clasificarea textului este Naive
Bayes. Naive Bayes este un algoritm de
clasificare probabilistic, deciziile luate de

acesta fiind bazate pe probabiliti derivate
din setul de date preclasificat.
n procesul de training sunt analizate relaiile dintre cuvintele care apar n
documente i categoriile asociate documentelor. Este folosit apoi teorema lui
Bayes pentru a determina probabilitatea
ca o serie de cuvinte s aparin unei anumite categorii.
Conform teoriei lui Bayes, probabilitatea ca un eveniment A s apar innd cont
c alt eveniment B a aprut este egal cu
probabilitatea c evenimentul B s apar
innd cont c evenimentul A a aprut,
nmulit cu probabilitatea c evenimentul A s apar raportat la probabilitatea
apariiei evenimentului B.
Astfel aplicat la problema noastr, probabilitatea ca un document s aparin

unei categorii C innd cont c are n
componena vectorul de cuvinte X=(x1,
x2, , xn) este urmtoarea:
Aceast formul este foarte greu de calculat i necesit o putere computaional

foarte mare, pentru simplificarea problemei, algoritmul Naive Bayes presupune
ca atributele din vectorul X sunt independente (de aici algoritmul i ia numele de

naiv), astfel formula devine:
Transformarea textului n vectori de atribute se face cu ajutorul comenzii seq2sparse care creeaz un fiier SequenceFile de
tip <Text,VectorWritable>:
mahout seq2sparse -i sequencefile -o vectors -wt tfidf
n felul acesta timpul necesar procesului de training este mult

mai mic, dar n cazul n care avem un numr mare de clase i
unul foarte mare de date pentru procesul de training, procesul de
training va dura mult prea mult pentru ca algoritmul s mai aib
vreo utilitate practic. Soluia este procesarea distribuit.
Hadoop este un program care permite procesarea datelor
n mod distribuit. Acesta vine cu un sistem de fiiere distribuit
pentru stocarea datelor. Hadoop poate scala pn la cteva mii
de calculatoare, ceea ce ar trebui s fie suficient pentru a rezolva
orice problem de clasificare.
Mahout este o librrie ce conine algoritmi scalabili de
clusterizare, clasificare, sau filtrare colaborativ. O mare parte
din aceti algoritmi implementeaz paradigma map-reduce i
ruleaz n mod distribuit utiliznd Hadoop. Viteza de procesare
a algoritmilor din aceast librrie este diminuat comparativ cu
alte alternative atunci cnd dimensiunea datelor este mic, dar
Mahout poate scala foarte mult, iar dimensiunea datelor nu este
o problem pentru acesta. De aceea se recomand a se folosi doar
atunci cnd dimensiunea datelor este foarte mare (mai mult de
1milion de documente folosite pentru training).
Pentru a facilita utilizarea algoritmilor, Mahout pune la
dispoziie un utilitar care poate fi executat din linie de comand.
Astfel crearea unui proces scalabil de clasificare automat a textului este mult simplificat.
Primul pas pe care trebuie s-l facem este s transformam
textul n vectori de atribute, dar pentru aceasta trebuie s avem
documentele n format SequenceFile. Un SequeneFile este un
fiier care conine perechi cheie-valoare i este folosit n programele care implementeaz paradigma map-reduce.
Pentru a transforma datele noastre ntr-un SequenceFile
folosim comanda seqdirectory:
mprirea datelor n date de test i date de training este la

fel de uoar precum paii anteriori, mprirea este aleatorie
putndu-se selecta procentul pe care l reprezint datele de test
din datele totale cu ajutorul parametrului --randomSelectionPct:
mahout split -i vectors --trainingOutput
train-vectors --testOutput test-vectors
--randomSelectionPct 40 -ow sequenceFiles
Procesul de training i test se execut utiliznd comenzile

urmtoare:
mahout trainnb -i train-vectors -el -o model
-li labelindex -ow
mahout testnb -i test-vectors -m model -l labelindex
-ow -o rezultate_test
Rezultatele testrii pot fi acum evaluate, i dac e necesar,

pentru a obine un rezultat mai bun se pot modifica datele iniiale
i se poate repeta procesul, pn cnd acurateea clasificrii este
satisfctoare.
Clasificarea textului poate avea multe aplicaii, dar acum
dimensiunea datelor nu mai este o limitare. Hadoop i Mahout
pun la dispoziie instrumentele necesare crerii unui proces de
clasificare care s lucreze cu un numr de milioane de documente, lucru care altfel ar fi fost foarte greu de realizat.
mahout seqdirectory -i datele_initiale -o sequencefile
Objective C
jobs-cluj@yardi.com
Yardi Romania
39
programare
programare
xperii din domeniul IT au numit 2014 anul Internet of Things, acesta fiind unul dintre cele mai fierbini subiecte ale anului
care tocmai s-a ncheiat. Titlul atribuit nu este deloc surprinztor dac lum n considerare faptul c site-uri importante precum dzone.com, jaxenter.com sau oracle.com au publicat cteva articole pe sptmn despre tehnologiile din sfera Internet of
Things, iar blogger-ii nu au scpat nicio ocazie s posteze despre ultimele lor proiecte IoT. Nici editurile nu au fost mai prejos, n 2014
fiind publicate zeci de titluri, multe altele ateptnd s vad lumina tiparului anul acesta.
Toate acestea s-au ntmplat n contextul lansrii unei multitudini de noi
gadgeturi sau dispozitive inteligente, dar i
a numeroase platforme software sau implementri ale unor protocoale mai mult sau
mai puin cunoscute. Muli mptimii
ai tehnologiei au auzit de produse populare, lansate n ultimii ani, precum Philips
Hue sau Nest, ns ncepnd cu 2014 e
nevoie de un efort activ s putem ine
pasul cu frecvena apariiei de noi dispozitive, cum ar fi Sen.se Mother, Fitbit
Charge sau SkyBell. IoT influeneaz din
ce n ce mai mult domeniile din viaa de
zi cu zi, precum sntatea cu dispozitive
care monitorizeaz pacienii, ngrijire la
domiciliu, prin gadgeturi pentru un stil de
via sntos, transporturi, cu autovehicule conectate, automatizarea locuinelor,
industrie etc. .
nainte de a discuta despre modalitile
prin care comunitatea Java i poate face
auzit vocea n sfera Internet of Things,
suntem datori s descriem pe scurt ce
nseamn mai exact IoT.
Definiii
Internet of Things sau, pe scurt, IoT este

un concept dezbtut din ce n ce mai mult
n ultimii ani, dar semnificaia sintagmei
nu este ntotdeauna pe deplin neleas.
CASAGRAS (Coordination and support
action for global RFID-related activities
and standardisation) ne d o definiie destul de abstract, care spune despre IoT
urmtoarele: este o infrastructur de reea
40
global, care conecteaz obiectele fizice i

virtuale prin intermediul exploatrii capturii de date i a capacitii de comunicare.
Aceast infrastructur include dezvoltrile existente i viitoare ale reelelor i ale
Internet-ului. Aceasta va pune la dispoziie
modaliti de identificare a obiectelor, senzori i capacitatea de conectare ca baz
pentru dezvoltarea de servicii sau aplicaii
independente i cooperante. Acestea vor fi
caracterizate printr-un grad nalt de autonomie pentru captura de date, transferul
evenimentelor, conectivitatea n reea i
interoperabilitate [1].
Definiia oferit de Stephen Haller de
la SAP Research ne ajut s ne crem o
imagine mai concret asupra Internet of
Things, despre care spune c este o lume
unde obiectele fizice sunt integrate omogen n reeaua informaional i unde
aceste obiecte fizice pot deveni participani
activi n procesele business. Serviciile sunt
gata s interacioneze cu aceste obiecte
inteligente prin intermediul Internet-ului,
s interogheze i s-i schimbe starea i
orice informaie asociat cu ele, lund n
considerare securitatea i chestiunile ce in
de intimitate[2].
O alt explicaie este dat de Oracle,
care afirm c Internet of Things se refer
la colectarea i gestionarea cantitilor
masive de date provenite de la reelele
aflate ntr-o rapid expansiune de
dispozitive i senzori, procesarea acestor
date i apoi partajarea lor cu alte obiecte
conectate[3]. Pentru a ne da seama care
este ordinul de mrime al acestor cantiti

de date, ne putem uita la exemplul echipei de navigaie Oracle Team USA, care
lucreaz cu ambarcaiuni echipate fiecare
cu cte 300 de senzori, menii s furnizeze
informaii despre o mulime de parametri,
cum ar fi eficacitatea reglajelor pnzelor,
tria i stabilitatea carenei sau tensiunea
din catarg. Aceti senzori msoar 3000 de
variabile de 10 ori pe secund, producnd
500 GB de date neprelucrate pe zi. Un alt
aspect interesant este faptul c n prezent
doar 11% din volumul total de date este
generat de dispozitive, dar IDC estimeaz
c pn n 2020 procentul va crete la
40%[4].
Acest titlu descriptiv, care ncearc s
surprind esena urmtorului mare trend
n IT, reprezint n principiu efortul de a
regndi relaia noastr cu obiectele pe care
le folosim n fiecare zi, dar i a obiectelor
ntre ele. Conform experilor, IT-ul se va
ndrepta puternic n aceast direcie. Ca
dovad, mai multe nume sonore ale tehnologiei secolului al XXI-lea, precum Cisco
sau Bosch, au ntreprins studii pe aceast
tem, ajungnd la concluzia c proiectele
din sfera IoT vor depi valoarea economic de 15 trilioane de dolari, pn n
2020[5]. De asemenea, analitii de la Cisco
afirm c n 2010 existau peste 12.5 miliarde de obiecte conectate la Internet i
estimeaz c vor exista aproximativ 25
miliarde de lucruri inteligente, conectate la Internet, pn la finalul anului 2015.
Pentru anul 2020, previziunea lor este de
programare
50 de miliarde de lucruri[6].
Oracle i Java Embedded
n acest context intr n scen Java,

att ca platform ce are la baz Java
Virtual Machine,
ct i ca limbaj de
pro g r am are , c u
o comunitate de
peste 9 milioane de
utilizatori. Facem
aceast distincie
nt re pl at for m
i limbaj [7] ntruct un dispozitiv
care ruleaz JVM
nu este limitat la
execuia de aplicaii
Java; acestea pot fi, n anumite condiii,
aplicaii scrise cu ajutorul Scala, Clojure
etc. . n trecut, programarea dispozitivelor
embedded se fcea preponderent n limbaje de nivel sczut, precum C sau limbaj
de asamblare.
n acest articol vom ncerca s ne facem
o prere despre soluiile propuse de Oracle
pentru IoT, companie a crei implementare
a platformei Java se bucur de cea mai
mare popularitate printre programatori.
Totui, n articolele viitoare vom privi
mai ndeaproape i caracteristicile altor
proiecte Java pentru IoT, cum ar fi cele din
stiva dezvoltat de Eclipse Foundation.
n ultimii ani, Oracle a investit masiv
ntr-o linie de produse denumite sugestiv
Java Embedded, lucru ce ofer posibilitatea
programatorilor Java s scrie aplicaii
pentru astfel de dispozitive, de la smart
card-uri i module wireless, pn la single board computer-e (SBC), cum ar fi
Raspberry PI. Platformele Java Embedded
sunt principalul lucru pe care Oracle l
ofer dezvoltatorilor embedded i prin

intermediul cruia contribuie la influena
pe care o are Java n sfera Internet of Things.
Viziunea Oracle pentru Java 8 a fost s
lanseze, pe lng Standard Edition (SE),
nc dou variante importante ale platformei, mai exact Oracle Java ME Embedded
8 i Oracle Java SE Embedded 8, la care
se adaug Java Embedded Suite. Henrik
Sthl, vicepreedinte peste product management pentru Java i IoT la Oracle, afirm
n ediia noiembrie/decembrie 2014 a
revistei Oracle Java Magazine c, prin lansarea acestor variante ale platformei au
fcut disponibile pe platforme embedded,
care au doar cteva sute de KB de memorie, feature-urile cu care programatorii
sunt obinuii n Java SE[8].
P r i n l a n s a re a n oi i v e r s iu n i a
distribuiilor amintite mai sus, Oracle
a ncercat s le aduc la un grad ct mai
nalt de compatibilitate una cu cealalt i,
n acelai timp, s le alinieze la Java SE 8.
Pentru aceasta, s-a introdus conceptul de
Compact Profiles, dezvoltatorii putnd
alege ntre setul complet de API-uri Java
SE i alte trei subseturi care au la dispoziie
doar acele API-uri care sunt necesare pentru use case-urile relevante. Un astfel de use
case poate fi rularea unei stive OSGi (Open
Service Gateway initiative). Aa cum vom
vedea ntr-un articol viitor, OSGi joac un
rol important n cadrul eforturilor fcute
de Eclipse Foundation pentru implementarea unei stive complete IoT, numit Open
IoT Stack for Java.
ncepnd cu Java 8, versiune lansat
n prima parte a anului 2014, am vzut c
Oracle face eforturi considerabile pentru a
aduce la zi varianta Micro Edition (ME) a
platformei, lucru ce confirm implicarea
corporaiei n rzboiul soluiilor IoT.
Printre mbuntirile aduse platformei
se numr eficientizarea procesului de
Fig. 1 Privire de ansamblu asupra platformei Oracle Java ME Embedded 8[9]
deployment pe dispozitive de dimensiuni mici, cum ar fi senzorii inteligeni

sau gateway-urile embedded. De asemenea, API-urile au fost actualizate
pentru a rspunde nevoilor de programare
a dispozitivelor int. Prin aceast nou
versiune Java ME, platforma are mult
mai multe lucruri n comun cu Java SE,
ns funcionaliti precum reflection sau
expresiile lambda urmeaz s fie adugate. Acest aspect este important, ntruct
n felul acesta, orice programator Java se
va putea implica n proiecte embedded
ntr-un timp scurt, fr a face eforturi considerabile. n 2015, Henrik Sthl anun c
unii productori de hardware plnuiesc
s integreze Java ME n dispozitivele lor,
ceea ce va conduce la o mai mare rat de
adopie a platformei.
Componentele construite cu soluiile
embedded despre care discutm, livrate
ntr-un context IoT, dau acces aplicaiilor
business la resursele instalate n mediul
nconjurtor, att pentru a primi input de
la acestea ct i pentru a lansa comenzi. Un
astfel de use case este orchestrarea sistemelor eterogene de control a temperaturii i a
iluminrii ntr-o cldire. Observm c abilitatea Java ME de a controla echipamente
cum ar fi senzori, valve sau servo-motoare,
reprezint unul dintre aspectele fundamentale ale obinerii unei infrastructuri
IoT.
Privind lucrurile de la o oarecare
distan, putem observa c arhitectura
Java ne permite s crem aplicaii pe vertical, dup cum a artat i Maulin Patel,
liderul n soluii de procesare embedded de
la Freescale[8]. nti colectm datele de la
obiectele inteligente cu Java ME, apoi trecem la Java SE pentru servicii de gateway,
iar n final executm gestiunea i procesarea datelor cu Java EE, n cloud.
Aproape de fiecare dat cnd se
vorbete despre IoT, se aduce n discuie
problema securitii. ntr-un mediu eterogen i deschis precum este o infrastructur
Internet of Things, securitatea este esenial,
dar greu de obinut. Este de ajuns ca un
atacator s aib acces la una dintre componentele soluiei IoT pentru a fi capabil
s exploateze posibilele bree n sistemul
defensiv al acesteia. Spre exemplu, n cazul
contoarelor inteligente de utiliti, cel mai
interesat de compromiterea acestor uniti
poate fi chiar proprietarul locuinei n care
au fost instalate. Astfel, potenialul atacator
are chiar i acces fizic la echipament, lucru
ce ridic ntrebri cu privire la nivelele la
care trebuie implementate mecanisme de
41
testare
programare
securitate. Acum c am remarcat seriozitatea acestei chestiuni, putem veni cu o veste
bun pentru dezvoltatorii IoT din universul Java, ntruct aceast platform asigur
securitatea datelor pe ntreaga verticalitate
a sistemului implementat. Securitatea este
o caracteristic nglobat n arhitectura
platformei, fiind dezvoltat i actualizat
constant, cu fiecare nou versiune. Vom
reveni cu detalii referitoare la securitatea oferit de Java ME 8 ntr-unul dintre
paragrafele urmtoare, cnd vom discuta
cteva caracteristici tehnice ale platformei.
Java ME Embedded 8
Platforma dedicat dispozitivelor cu

cele mai puine resurse, cum ar fi cardurile,
se numete sugestiv, Java Card. Totui, primul produs din familia Oracle care aduce
cu adevrat o contribuie important n
spaiul IoT este Java ME Embedded 8. Prin
urmare, n continuare ne vom concentra
atenia asupra acestuia. nainte de a ne uita
la cteva detalii, trebuie s menionm Java
ME Embedded const din dou versiuni:
Java ME Embedded i Java ME Embedded
Client.
Java ME Embedded 8 este o platform
ce poate fi folosit de ctre dispozitive care
au mai puin de 1 MB de memorie. Astfel,
este potrivit pentru obiecte inteligente
fr interfa grafic, care au timp ndelungat de funcionare i resurse limitate.
Aa cum putem vedea n Figura 1,
la baza Java ME Embedded 8 st maina
virtual, pe care o gsim sub denumirea
Connected Limited Device Configuration
sau, pe scurt, CLDC 8. Aceast component reprezint un sub-set al Java SE 8,
dedicat dispozitivelor embedded. Dup
cum am menionat mai sus, o dat cu versiunea 8, CLDC reprezint un prim pas
spre o mai bun aliniere cu Java Standard
Edition i totodat un important salt de la
CLDC 1.1.1. Aadar, avem la dispoziie
adnotaii, generics i multe alte caracteristici Java, familiare tuturor dezvoltatorilor.
Dei s-a realizat o evoluie foarte important prin lansarea CLDC 8, s-a reuit
meninerea compatibilitii binarelor cu
versiunea anterioar.
Deasupra fundaiei pe care o reprezint CLDC 8 stau mai multe componente
definitorii pentru platform. Una dintre
ele este Generic Connection Framework 8
(GCF 8). Aa cum se poate intui, aceast
component gestioneaz problemele
de conectivitate. Acest framework este
necesar ntruct n spaiul embedded
posibilitile de conectare sunt multiple,
42
iar dispozitivele pe care ruleaz aplicaia

noastr au interfee variate de comunicare
cu lumea exterioar. Unele pot avea capacitate de conectare prin Wi-Fi, altele de
tip cellular, Bluetooth sau prin cablu. De
asemenea, pentru un control optimizat al
conectivitii GCF 8 expune AccessPoint
API. Totodat, GCF 8 vine cu suport pentru IPv6, scpnd dezvoltatorii Java ME
Embedded 8 de emoiile epuizrii adreselor IPv4.
Revenind la subiectul securitii n
lumea Internet of Things, putem da cteva
detalii despre modul n care GCF 8 rezolv
aceast problem. Java ME Embedded
8 vine echipat cu implementri ale celor
mai noi standarde n materie de securitate,
printre care se numr Transport Layer
Security 1.2 i Datagram Transport Layer
Security 1.2. Astfel, Oracle i asigur pe
utilizatorii platformei de faptul c aceasta
ofer cele mai nalte nivele de criptare la
nivel de reea i autentificare [9].
Un alt bloc constructiv al Java ME 8 este
Micro Edition Embedded Profile 8 (MEEP
8). Aceast component este responsabil
cu definirea modelului, a containerului n
care ruleaz aplicaia, n general cu ciclul
de via al acesteia. Prin intermediul MEEP
8 putem partaja cod ntre aplicaii, putem
actualiza componente n sistem sau aplica
patch-uri aplicaiei. Partajarea bibliotecilor
denumite sugestiv, LIBlets se face tot
prin intermediul MEEP 8, contribuind la
minimizarea necesarului de memorie i la
modularizarea aplicaiilor. n plus, MEEP
8 ofer aplicaiilor posibilitatea de a comunica ntre ele att sincron (Inter-MIDlet
Communication sau IMC), ct i asincron,
printr-un sistem de mesagerie bazat pe
evenimente.
Securitatea este un subiect important
i pentru MEEP 8, deoarece se pot defini
politici de securitate pentru autentificare i
autorizare, n funcie de situaia specific.
Astfel, ncrcarea codului i execuia lui se
realizeaz ntr-un mediu securizat, ntruct fiecare component este asociat unui
client, avnd permisiuni specifice. Acestea
trebuie verificate la fiecare ncercare de
acces.
O component de o importan crucial pentru Java ME Embedded 8 este
Device Access API, care ofer aplicaiilor
acces la dispozitive periferice, cum ar fi
senzori, comutatoare sau LED-uri. Aceast
component exista i n versiunile anterioare, ns acum vine cu funcionaliti noi,
printre care late binding, care permite adugarea de noi periferice, fr a fi necesar
modificarea API-ului.
Alturi de aceste blocuri constructive,
Java ME Embedded 8 vine cu o multitudine de API-uri, precum cel pentru servicii
web sau localizare.
Avnd toate aceste componente
Java ME Embedded la dispoziie, este la
ndemna noastr, a dezvoltatorilor, s
construim aplicaii embedded, contribuind
la spaiul Internet of Things.
n ajutorul nostru vine Java ME
SDK 8, un toolkit complet creat pentru a
ntmpina orice nevoie avem n procesul
crerii i ntreinerii unei aplicaii. Acest
SDK ofer inclusiv un mediu de emulare,
avnd posibilitatea s ne testm aplicaiile
chiar dac dispozitivele pe care vor fi
distribuite nu sunt disponibile n timpul dezvoltrii. De asemenea, putem face
debugging att n modul de emulare, ct
i atunci cnd aplicaia ruleaz pe dispozitiv. Pentru a ntregi acest set de unelte,
Oracle ofer plugin-uri pentru Netbeans
IDE i Eclipse IDE, care ncorporeaz
toate funcionalitile SDK-ului. Vom discuta mai multe detalii i vom exemplifica
modul de utilizare al Java ME SDK 8 ntrunul dintre articolele viitoare.
Java ME Embedded Client este o
implementare CDC (Connected Device
Configuration) care, n principiu, este
configuraia destinat dispozitivelor
mobile cu ceva mai multe resurse, cum
ar fi smartphone-urile. Pentru Java ME
Embedded Client, aceast configuraie a
fost restrns i optimizat, pentru a se
potrivi sistemelor embedded de categorie
joas nspre medie. Dei amprenta acestei configuraii este redus, ofer mare
parte din limbajul Java. Astfel, Java ME
Embedded Client este destinat obiectelor inteligente cu mai puin de 10 MB de
memorie i fr interfa grafic.
Concluzii
Industria IT autohton nu este strin

de spaiul Internet of Things, ncepnd s
fie lansate produse Made in Romania, precum Pocketo sau Tintag. De asemenea,
exist companii n Romnia, implicate n
proiecte care se integreaz n paradigma
IoT. De exemplu, regsim astfel de proiecte
la Braov n domeniul automotive, cu al
su concept de connected car. Un alt lucru
mbucurtor este faptul c au nceput s se
organizeze evenimente despre IoT, unul
dintre acestea fiind ALT Festival, care a
avut loc n noiembrie 2014, la Braov.
Un obiectiv important pentru Oracle n
ultima perioad este afirmarea platformei

articolul viitor, cnd vom atinge, prin exemple concrete, partea
practic a platformei Java ME Embedded 8.
Resurse
[1] CASAGRAS, RFID and the Inclusive Model for the Internet of Things
[2] Stephen Haller, Internet of Things: An Integral Part of the Future Internet,
SAP Research, 2009
[3] The Internet of Things: Manage the Complexity, Seize the Opportunity,
Oracle Corporation, 2014
[4] IDC Digital Universe Study, sponsored by EMC, December 2012
[5] Dzone Research, 2014 Guide to Internet of Things
[6] http://share.cisco.com/internet-of-things.html
[7] Benjamin Evans, Martijn Verburg, The Well-Grounded Java Developer,
Manning, 2013
[8] Java Development for the Internet of Things, Oracle Java Magazine,
November/December 2014 Issue
[9] http://www.oracle.com/technetwork/articles/java/ma14-java-me-embedded-2177659.html
Java n lupta care se d ntre soluiile IoT. Mai mult dect att, IoT Picture: http://blog.surveyanalytics.com/2014/09/top-5-infographics-ofcorporaia i-a exprimat dorina de a ctiga aceast btlie, ast- week-internet-of.html
fel nct Java s devin alegerea majoritii specialitilor implicai
n astfel de proiecte. Totui, rspunsul a venit rapid din partea
oponenilor, existnd multe voci care i-au exprimat scepticismul cu privire la potrivirea platformei n sfera IoT. Exist multe
argumente, att pro, ct i contra acestei idei, ns un lucru e cert:
Dnu Chindri
Java a strbtut un drum lung pentru a ajunge la gradul actual
danut.chindris@elektrobit.com
de maturitate, diversitate i aplicabilitate. Eforturile din ultimii
ani au dat natere unei noi familii de produse, care se doveJava Developer
@ Elektrobit Automotive
desc promitoare i, mai mult, ncep s-i dovedeasc valoarea
n cadrul proiectelor reale IoT. Vom vedea clar acest lucru n
43
programare
Ce sistem de distribuire de
mesaje din Azure s folosesc?
n teorie, trimiterea unui mesaj prin cablu nspre un alt dispozitiv este o sarcin simpl. Dar trimiterea unui mesaj ntr-un mod sigur i de ncredere poate fi o sarcin
dificil. n epoca IoT, n care numrul dispozitivelor conectate la internet crete
dramatic n fiecare zi, noi trebuie s gsim diferite mecanisme de comunicare.
Radu Vunvulea
Radu.Vunvulea@iquestgroup.com
Senior Software Engineer
@iQuest
44
Deoarece nu putem controla cnd

un dispozitiv este conectat la internet i
pregtit s primeasc mesajul nostru, e
important s detectm diferite modaliti
de a comunica cu el.
n acest articol, vom arunca o privire
asupra diferitelor sisteme de mesagerie
care sunt oferite de ctre Microsoft Azure.
Pentru fiecare sistem de mesagerie vom
ncerca s identificm punctele forte i
cnd ar trebui s l utilizm. Odat ce vom
fi neles fiecare sistem de mesagerie, le
vom compara unul cte unul.
n finalul acestui articol vom identifica
un sistem de mesagerie perfect, care poate
fi utilizat n orice situaie. Pentru diferite
cazuri de utilizare s-ar putea s fie nevoie
s folosim sisteme de mesagerie diferite, n
funcie de nevoile noastre.
Soluiile de mesagerie care vor fi discutate n acest articol sunt urmtoarele:
Azure Storage Queues,
Azure Service Bus Queues,
Azure Service Bus Topics,
Azure Event Hub.
multe mesaje n acelai ir. Cnd spun

multe, imaginai-v iruri care pot ajunge
nu la 1 GB, nu la 1TB i nu la 10TB, ci chiar
la un ir de 200TB. De aceea, suntem capabili s depozitm cantiti mari de date
n iruri, fr a ne gndi la dimensiunea
irului.
Un alt avantaj al acestui tip de ir
este numrul clienilor concureni, care
teoretic este nelimitat. Singura limit n
acest caz este limea de band care poate
limita numrul clienilor concureni.
Dimensiunea maxim a unui mesaj este
de 64 KB, dar n blocuri combinate putem
avea mesaje care ajung la 200 GB.
Bineneles c mai exist anumite
limitri pe care trebuie s le lum n
considerare. n primul rnd, chiar dac
dimensiunea irului poate fi foarte extins,
timpul maxim de plecare (Time To Leave
TTL) al unui mesaj este de 7 zile. Aceasta
nseamn c un mesaj trebuie s fie consumat n 7 zile sau rennoit, altfel, mesajul
va fi ters.
Chiar dac avem suport pentru
capaciti de mesagerie de baz precum
Azure Storage Queues
monitor de nlnuire i suport lot de date,
Acest sistem de mesagerie face parte nu avem suport pentru management de
din Azure Storage i ne permite s stocm stare, detectarea duplicrii i suport pentru

tranzacii.
O caracteristic interesant a Azure
Storage Queues este capacitatea de logging.
Utilizatorii au posibilitatea de a activa
mecanismul de logging i de a urmri toate
aciunile care au loc n ir. Informaiile
precum IP-ul clientului sunt urmrite i
stocate drept o soluie de-a gata.
Clienii au posibilitatea de a se uita la
mesajele din ir, fr a le terge sau bloca.
Aceasta nseamn c, dac un client se uit
la un mesaj, i ali clieni vor putea accesa
acelai mesaj din ir.
Din acest motiv, Azure Storage Queues
este foarte eficient cnd ai nevoie de un
sistem de mesagerie care s fie capabil
s urmreasc toate aciunile care au loc
n ir. Acesta este o soluie bun pentru
cazurile de utilizare n care tii c dimensiunea irului va fi mai mare de 80-100 GB.
Pentru irurile mari, acesta poate fi cel mai
bun mecanism de iruri.
dorim s adugm un mesaj care deja

exist n sistem, mesajul nu va fi adugat.
Acest lucru este grozav cnd dorim s ne
asigurm c avem mesaje unice n ir.
Mesajele pot fi consumate din ir n
dou moduri diferite Peek and Lock
(Privete i Blocheaz) sau Receive and
Delete (Primete i terge). Ne putem uita
la un mesaj dintr-un ir i l putem face
indisponibil pentru restul clienilor pn
cnd vom confirma c l-am consumat cu
succes sau vom anula aciunea (putem de
asemenea specifica un timeout o pauz).
Capacitatea de securitate a Azure
Service Bus Queues este mai complex;
noi avem posibilitatea de a controla mai
profund accesul la mesaje.
Pe baza acestor caracteristici, Azure
Service Bus Queues sunt grozave atunci
cnd este nevoie de detectarea duplicatului,
suport pentru tranzacii sau depozitarea
mesajelor pe termen nelimitat.
Azure Service Bus Queues
Azure Service Bus Topics
Acest sistem de mesagerie face parte

dintr-o infrastructur mai complex de
mesagerie oferit de Microsoft i suport
scenarii mai complexe. Din aceast cauz,
vom vedea c dimensiunea unui ir este
limitat la 80GB, dar caracteristicile oferite
de Service Bus Queues sunt mai complexe.
Este important de tiut de la nceput c
aceste dou sisteme de mesagerie sunt construite pe servicii diferite i nu au nimic n
comun. Dimensiunea unui mesaj poate
fi de 256 KB, mai mare n comparaie cu
Azure Storage Queues i de asemenea un
mesaj va fi pstrat n Service Bus pentru o
perioad nelimitat de timp. n plus, exist
suport complet pentru protocolul AMPQ,
caracteristic ce poate fi foarte util pentru
dispozitivele ncorporate.
Exist suport pentru mesajele moarte
(dead lettering), ceea ce ne permite s
mutm automat un mesaj ntr-un ir
secundar, dac acel mesaj expir sau clientul nu poate consuma un anumit mesaj.
Exist suport complet pentru tranzacii,
gestionarea unui numr specific de mesaje
n aceeai tranzacie. Mai mult dect att,
exist suport pentru mesaje multiple de
grup n aceeai sesiune n acest fel ne
putem asigura c un client i va consuma
toate mesajele care fac parte dintr-o sesiune anume. Dac tim ID-ul sesiunii,
putem consuma mesajele din acea sesiune
anume.
O caracteristic interesant a Azure
Service Bus Queues este detectarea dublurilor. Odat ce este activat, putem detecta
mesajele duplicate. n momentul n care
Spre deosebire de Azure Service Bus

Queues care ne permite s livrm mesajele unul la unul, Azure Service Bus Topics
ne permite s livrm un mesaj la muli.
Acest lucru nseamn c noi putem furniza acelai mesaj la clieni multipli care se
numesc subsribers (abonai). Acest sistem
de mesagerie este n fond un sistem ESB
(Enterprise Service Bus), care ne permite
s avem o comunicare de tipul public/
subscrie.
Din perspectiva caracteristicilor,
acestea sunt foarte asemntoare cu
Azure Service Bus Queues, avnd cteva
funcionaliti i posibiliti adiionale.
Asemnarea celor dou servicii se datoreaz faptului c ambele sisteme de
mesagerie sunt construite pe acelai sistem
de infrastructur de mesagerie broker.
Fiecare tem care este utilizat pentru
a trimite mesaje poate avea maxim 2000 de
abonai, nsemnnd c acelai mesaj poate
fi primit de 2000 de abonai. Acest lucru
poate fi foarte util atunci cnd trebuie s
distribuim mesaje ctre diferite sisteme.
De asemenea, o subscriere poate fi adugat n timpul de rulare. Nu este nevoie
s oprim sistemul sau s recrem tema.
Odat ce o nou subscriere a fost creat,
toate mesajele noi care sunt trimise ctre
acea tem vor fi primite i de ctre noua
subscriere.
O caracteristic interesant este
suportul filtru. Noi putem ataa un filtru
la fiecare subscriere. Acel filtru va permite numai mesajelor care respect regula
filtrului s ajung la aceeai subscriere
anume. n acest fel, fiecare subscriere poate

asculta mesaje specifice.
Ambele sisteme de mesagerie, Azure
Service Bus Topics i Queues au capaciti
de trimitere mai departe automat, dar
pentru Topics, acestea sunt mai interesante. Aceasta nseamn c noi putem
trimite mai departe automat un mesaj
dintr-o subscripie ctre un alt Service Bus
Topic al Queue.
Fiecare mesaj care este trimis printrun Service Bus poate avea o colecie
de proprieti. Proprietile sunt utilizate atunci cnd este aplicat un filtru de
comand per subscriere. De asemenea,
fiecare subscriere poate avea o aciune la
comand care este executat atunci cnd
primete un mesaj. Chiar dac aciunile
care pot fi executate sunt foarte simple,
poate fi foarte util n anumite situaii
de exemplu, ne este permis s schimbm
numele valorii proprietii.
Datorit proprietilor sale, Azure
Service Bus Topics este perfect de utilizat atunci cnd este nevoie s distribuim
un mesaj ctre mai muli asculttori. n
sistemele n care numrul clienilor care
ar trebui s primeasc un mesaj se poate
schimba n mod dinamic, Azure Service
Bus Topics poate fi util.
Azure Event Hub
Chiar dac, teoretic, face parte din

Azure Service Bus, Azure Event Hub este
un sistem de mesagerie special care este
obinuit s nghit cantiti mari de date
ntr-o perioad scurt de timp. Acest sistem este capabil s nghit peste 1 milion
de mesaje pe secund, fr niciun fel de
problem.
Este construit pe conceptul de curgere.
Din aceast cauz, toate mesajele care plutesc n sistem sunt vzute drept un flux de
date. Latena este foarte sczut i chiar
dac cantitatea de date care curg este foarte
mare, sistemul este stabil i fiabil.
O caracteristic interesant a acestui
sistem este capacitatea de a naviga ntre
mesajele pe care le-am primit deja. Avem
un concept similar cu un cursor i putem
itera de asemenea i vechile mesaje capacitatea de a rspunde. Mai mult, fluxul de
mesaje poate ajunge la mai muli clieni n
acelai timp, utiliznd conceptul de grup
al clienilor.
O calitate important care poate fi
gsit la Azure Service Bus este pstrarea
ordinii mesajelor. Aceasta nseamn c
ordinea mesajelor se pstreaz. Clienii vor
putea s consume mesajele n ordinea n
care ele au fost trimise.
45
programare
Ce sistem de distribuire de mesaje din Azure s folosesc?
Capacitile sistemului Event Hub pot
scala destul de interesant, prin adugarea de TU multipli (Throughput Units).
Fiecare TU ne permite 1 MB/s pentru
intrare i 2 MB/s pentru ieire. Retenia
unui mesaj este de o zi, fiind capabil s le
depoziteze pn la 7 zile.
Bineneles c aceasta vine cu anumite
costuri. Caracteristici precum irul scrisorilor moarte, suport pentru tranzacii
sau opiuni TTL nu pot fi gsite pe Azure
Event Hub.
Aceast soluie este perfect pentru
volumuri mari de procesare de mesaje,
cum ar fi telemetria sau n cazurile de utilizare IoT.
Care este cea mai bun soluie?
Nu exist un rspuns unic la aceast

ntrebare. n funcie de nevoile noastre i
de cerine, putem utiliza sisteme diferite
de mesagerie. Azure Storage Queues este
perfect cnd este nevoie s depozitm i
s gestionm cantiti mari de mesaje, dar,
cnd avem nevoie de mai mult control,
Azure Service Bus Queues poate fi o soluie
46
mai bun. Pentru cazurile de utilizare n

care avem nevoie s distribuim mesaje
mai multor asculttori, Azure Service Bus
Topic este cel mai bun. Dar pentru volum
mare de procesare a mesajelor, nimic nu se
compar cu Azure Event Hub.
Concluzie
n acest articol ne-am uitat la diferite

sisteme de mesagerie oferite de Azure i
am identificat cele mai importante caracteristici ale fiecruia. Am vzut cele mai
importante cazuri de utilizare n care
putem folosi aceste sisteme i care sunt
punctele lor slabe. n final, a dori s
v invit s vedei web site-ul Azure i s
descoperii mai multe despre aceste servicii grozave.
legal
Noi tehnologii - n pragul Data Protection Day 2015
e vremuri, Arthur C. Clarke, autorul celebrului roman science fiction 2001 Odiseea Spaial, afirma:
Any sufficiently advanced technology is indistinguishable from magic .
n fiecare zi, suntem uimii de noi i noi

minuni ale tiinei i tehnicii ce se insinueaz i devin parte din viaa noastr de zi
cu zi. Lucruri precum Internetul Lucrurilor
(Internet of Things), tablete, telefoane inteligente, aplicaii mobile, drone, soft-uri de
analytics, instrumente de online tracking
i de geo-localizare, maini care se conduc singure (self-driving cars), stocare n
cloud, Google Street View, etc. i fac loc n
vocabularul i, de cele mai multe ori, n obiceiurile noastre.
Pentru unii dintre noi, fani ai serialului
Star Trek (n rndul crora m nscriu i eu)
tirea prin care NASA anuna crearea unui
Tricorder1 care s colecteze date medicale
despre pacieni i s diagnosticheze eventuale boli, e un prilej de entuziasm. Pentru
celebrul Stephen Hawking, ajutat de muli
ani de tehnologie ca s supravieuiasc i
s interacioneze cu cei din jur, avntul
tehnologic este, totui, prilej de previziuni
sumbre2.
Juritii nu pot rmne ns prea mult
timp vistori n faa magiei noilor tehnologii, din cauza provocrilor legale cu care se
confrunt. De multe ori, se pune problema
dac legislaia poate ine pasul i dac / cum
ar trebui schimbat pentru a reflecta noile
realiti.
i cum pe 28 ianuarie se srbtorete
Ziua Datelor cu Caracter Personal3 (numit
1 http://www.nasa.gov/centers/ames/researchpark/
news/partners/2013/scanaduscout.html
2 h t t p : / / w w w. m e d i a f a x . r o / s t i i n t a - s a n a t a t e /
avertismentul-lui-stephen-hawking-inteligenta-artificiala-ar-puteaaduce-sfarsitul-omenirii-13697907
Data Protection Day n Europa sau Privacy

Day n afara Europei), m-am hotrt s
ncerc s ies din reveria tehnologic i
s folosesc aceast bun ocazie pentru a
reflecta puin la cteva dintre tehnologiile
noastre favorite care ne pot colecta i folosi
datele cu caracter personal n cele mai
diverse moduri.
Aplicaiile mobile, tabletele i

telefoanele smart aspir masiv date
Protejarea datelor cu caracter personal prelucrate prin intermediul aplicaiilor

mobile (app privacy) rmne un subiect
de actualitate i merit atenia crescut a
dezvoltatorilor.
Multe aplicaii mobile colecteaz i
folosesc date cu caracter personal ale utilizatorilor. Acest lucru implic rspunsul la
o serie de ntrebri, precum: aplicaia este
sau nu worldwide, ce informaii i date sunt
colectate, unde sunt stocate, cum sunt folosite, dac i cui pot fi dezvluite, etc. .Avnd
n vedere potenialele riscuri juridice, o
politic bine pregtit privind datele cu
caracter personal (Privacy Policy) pentru a
fi acceptat de utilizator, nu este un moft, ci
o necesitate.
n acest context, din ce n ce
mai des se recomand implementarea conceptului Privacy by Design 4
ceea ce presupune luarea n considerare a potenialelor riscuri legale nc
din etapele incipiente ale dezvoltrii
aplicaiilor (de exemplu, nainte de a
implementa n aplicaie o funcionalitate
de geo-localizare).
3 http : / / w w w. c o e . i nt / t / d g h l / s t an d ard s e tt i ng /
dataprotection/Data_protection_day_en.asp
Mai multe detalii despre acest concept

i despre tipurile de date cu caracter personal ce pot fi colectate prin intermediul
aplicaiilor mobile, putei citi n articolul
Dezvoltatorii de aplicaii mobile i datele
personale. Vreo legtur?5publicat n
numrul 21 al Today Software Magazine.
Soft-urile de analytics, instrumentele de

online tracking i geolocalizare
Tehnologia actual produce i faciliteaz

accesul la o cantitate uria de informaii
i date. Iar cei familiarizai ct de ct cu
conceptul de big data, probabil tiu deja
c big data = big business. Unii ndrznesc
chiar s afirme 6 c datele cu caracter
personal (chiar n form anonimizat) pot
fi considerate noul petrol, avnd i un
avantaj: acela c se pot extrage din cele
mai variate surse.
n aceast privin, soft-urile de
analytics, instrumente de online tracking
i de geo-localizare joac un rol esenial,
fiind instrumente puternice care pot urmri
sistematic activitatea utilizatorilor. Sunt
capabile s jongleze cu un volum imens
de date, s le analizeze, s le combine i s
caute tipare n principiu, cu scopul de a le
transforma n valoare pentru companii.
Dar valoarea rezultat din folosirea
acestor date este nsoit de un potenial
risc de abuz. De aceea, din punct de
vedere juridic, activitile desfurate
n e c ore s pu n z tor pr i n i nte r m e d iu l
5 h t t p : / / w w w. t o d a y s o f t m a g . r o / a r t i c l e / 7 8 3 /
dezvoltatorii-de-aplicatii-mobile-si-datele-personale-vreo-legatura
6
n lucrarea Data as a source of value creation -
Analytics Software a lui Christian Ringeling, prezentat la Paris, n

4 http://en.wikipedia.org/wiki/Privacy_by_design
octombrie 2014, Conferina European a ITechLaw.
47
legal
Noi tehnologii - n pragul Data Protection Day 2015
soft-urilor de analytics, a instrumentelor
de online tracking i de geo-localizare pot
prezenta o ameninare major la adresa
datelor clienilor i ale utilizatorilor
din mediul online i, implicit, la adresa
conceptului de data privacy.
De cele mai multe ori, perspectiva
industriei de analytics poate fi c
utilizatorul / clientul este cel care decide
cum folosete tool-urile ce i sunt puse la
dispoziie i la ce date vrea s ofere acces.
ns exist anumite reguli i recomandri
care trebuie luate n considerare, pentru
a se ncerca prevenirea riscului de abuz
(de exemplu, prin informarea corect a
utilizatorilor despre operaiunile n cadrul
crora le pot fi colectate datele i le poate
fi urmrit activitatea online, astfel nct
s poat lua o decizie informat dac
accept sau nu).
Dronele UFO-urile de pe cer
Dronele pot fi comerciale, de supraveghere, dar i drone uoare, de dimensiuni

mici folosite ca hobby.
Toate pot fi intruzive, de vreme ce
majoritatea au montat aparatur pentru filmare sau transmisie de date care le
permite s fac fotografii i videoclipuri
de cele mai multe ori, fr ca cei vizai s
accepte s fie fotografiai sau filmai.
Cum imaginea i vocea unei persoane
fizice sunt date cu caracter personal,
nelegem de ce aceast activitate nu este
tocmai n regul n lipsa acordului persoanei vizate.
n raportul su TMT Predictions 20157,
Deloitte estimeaz c veniturile totale
ale industriei dronelor se va ridica la 200
- 400 milioane de dolari n 2015 (echivalentul preului de list al unui avion mediu
de pasageri). Totui, pe termen scurt i
mediu, se pare c folosirea dronelor va fi
limitat, un factor-cheie fiind legislaia. n
7 http://www2.deloitte.com/global/en/pages/
technology-media-and-telecommunications/articles/tmt-preddrones-high-profile-and-niche.html
48
unele ri, legislaie aplicabil nu exist sau

este incert, n altele se aplic nc regulile
generale privind avioanele.
n Romnia, n principiu, dronele cu
mas maxim la decolare mai mic sau
egal cu 1 kg pot fi folosite liber dac:
Sunt operate ntr-o zon deschis,
nepopulat (fr construcii cu destinaia
de locuin);
Nu au montate pe ele aparatur
pentru filmare sau transmisie de date; i
Nu depesc cmpul vizual al
persoanei care comand drona de la sol
(dar nu mai mult de 150 m distan pe
orizontal i 100 m distan pe nlime).
Mainile care se conduc singure un

comar necesar?
Self-driving cars sunt o tem fierbinte.

Dar pe lng unele avanteje atractive
pe care le prezint (eficien, siguran,
reducerea accidentelor, etc.), ridic i controverse i riscuri privind folosirea datelor
persoanelor care circul cu aceste maini.
Cum vor avea permanent o conexiune
wireless, mainile care se conduc singure
pot fi urmrite constant. Iar datele de
localizare i alte informaii colectate prin
intermediul unei asemenea maini pot
fi considerate date cu caracter personal
ale celor care folosesc aceste maini. De
aceea, ntrebri precum Cine ar trebui s
dein sau s controleze datele colectate
de aceste maini? Ce tip de date sunt stocate? Cui vor putea fi ele transferate i n
ce modalitate? n ce scopuri vor putea
fi folosite? - sunt relevante i ar trebui
luate n considerare atunci cnd se pun n
balan avantajele i dezavantajele acestei
noi tehnologii.
n acest context, este firesc ca opinia public s se ntrebe dac nu cumva
- n schimbul acestor avantaje - de fapt,
renunm la libertatea de micare i devenim urmrii la fiecare pas. n presa din
strintate8 se atrage atenia asupra faptului
8 http://www.theguardian.com/commentisfree/2014/
c ar trebui s ne intereseze modul n care

aceste maini sunt dezvoltate n prezent,
deoarece - n caz contrar - este posibil ca
n viitor s nu fie un simbol al libertii
individuale, ci dimpotriv un mijloc de
supraveghere a indivizilor.
Ceea ce ne indic faptul c, pn la
momentul n care va exista o legislaie specific acestei tehnologii, procedeul Privacy
by design pare potrivit pentru a fi aplicat i
n cazul mainilor care se conduc singure,
ncercnd implementarea nc din primele
faze ale construciei mainii.
Iar la final,
Happy Data Protection Day 2015 and

Lets be private out there!
jun/02/google-driverless-cars-safety-climate-privacy
Claudia Jelea
claudia.jelea@jlaw.ro
Lawyer
@ Jlaw
management
Gogu i jocul alternativelor
simona.bonghez@confucius.ro
Speaker, trainer and consultant
in project management,
Owner of Colors in Projects
- No, n sfrit... rsufl Miu uurat vznd numele i mai ales faa lui Gogu pe ecranul
smartphone-ului. N-apuc ns s zic ceva c uvoiul vorbelor lui Gogu se dezlnui prin
micul device de parc se rupsese zgazul1:
- Da ce s-a ntmplat, domle, de suni ca nebunu?! Ori crezi c sunt chior i nu vd c-ai
sunat de prima dat? Cine-o murit, ce-o explodat, c nu mi-e dat i mie s am o zi de linite!
O zi, frate, att mi-am permis i eu s lipsesc. Motivat. O zi! Iar tu suni de cinci ori ntr-o or.
Cinci! Cinci mii de fulgere i tunete abate-s-ar asupra telefonului tu de fiecare dat cnd te
mai ntinzi dup el. Ori eti sinuciga i vrei s-i rezolv eu problema plecrii din snul omenirii, ceea ce m-ar face extrem de fericit n acest moment...
Probabil c i se terminase aerul, c uvoiul se ntrerupse i se auzi cum Gogu i ajusteaz
respiraia. Te-ai fi ateptat ca Miu s se repead asupra ocaziei i s ia cuvntul, dar se pare c
el prevzuse o asemenea reacie, iar acum atepta ca viitura s se domoleasc. i ntr-adevr,
odat plmnii realimentai, Gogu mai pierdu din avntul iniial. Adaug doar:
- Deci?
Zmbetul se li pe faa lui Miu: scpase mult mai ieftin dect i nchipuise. Fr s se
grbeasc deloc, i povesti lui Gogu problema cu care se confrunta i din cauza creia insistase
s-l gseasc, chiar n ziua lui liber. Avu ns grij s nu mai aduc vorba despre acest aspect,
nu era momentul s provoace iar potopul.
- Las-m s vd dac am neles, ncerc Gogu s sintetizeze informaia. Te-a pus efu
s gseti un manager de proiect pentru implementarea cerut de client. Iar tu ai insistat s i
dai rspunsul pe loc, hmm, ceea ce nu e deloc genul de atitudine pe care o adopi tu n mod
normal; iar el n-a fost de acord cu propunerea ta. Iar acum, runda a doua: vrei s mergi s-l
propui pe Tibi, dar nu mai vrei s-i asumi nici un risc i dai ca disperatu telefoane, s-i iau
eu problema asta din crc i s-mi asum eu responsabilitatea n cazul unui posibil, chiar
probabil eec. Mi da ce biat detept te-ai fcut tu peste noapte!
Urm realimentarea plmnilor. Faa spit a lui Miu arta c era pregtit pentru tot
ce era mai ru. Dar ca i data trecut, la captul cellalt al firului lucrurile se linitir. Pentru
cine l cunotea pe Gogu era evident c acesta intrase n modul de cutare soluii. sta era
un alt lucru care i plcea lui Miu la Gogu: invariabil ajungea s se gndeasc la rezolvri.
Era suficient s i ari problema, aa cum i ari cinelui bul. Numai c Gogu nu d din
coad, gndi Miu i ddu la o parte din minte imaginea unui Gogu n patru labe, fericit s
aib ocazia de-a alerga dup b.
- Oare i veni vreo idee, Gogule? ndrzni Miu s sparg tcerea.
- Oare, oare!... m gndeam la Cristina. Este suficient de matur, a dovedit-o n proiectul cu
1
Zgaz Baraj, stvilar (DEX, 2009)
49
management
Gogu i jocul alternativelor
englezii, are experiena lucrului n echip virtual i i i cunoate
deja pe muli dintre cei cu care va trebui s colaboreze. N-o s-i
fie uor cu clientul, dar asta e, dac era uor, o putea face oricine.
Merit o ans.
Miu tcu.
- Ei, zi ceva, insist Gogu. Pn i la viteza ta de reacie,
informaia tot trebuia s-i ajung deja la creier. Pmntu ctre
Miu: Alo! Sau crezi c nu e pregtit nc?
Miu chiar era ncurcat:
- Da io am zis de Tibi... Tibi i mult mai experimentat.
- Pi da, mi mechere, da dac te duci iar cu o singur
opiune la efu, iar i dai de ales ntre a face ceva i alternativa s nu faci. i dac rspunsul e cu nu, iar te dai de ceasul
morii. Trebuie s i dai dou variante viabile lui efu, el va cumpni propunerile i va alege cea mai bun dintre ele. Nu mai riti
astfel s pleci de la el fr s rezolvi problema. Mintea uman aa
funcioneaz: compar alternative, opiuni; dac i dai lui efu
aceast posibilitate, mintea lui va exploata oportunitatea de a
compara i a alege cea mai bun dintre alternativele prezentate.
Pricepi? Tibi sau Cristina. Tibi mai experimentat, dar cu un proiect dificil deja pe cap, bla-bla-bla, versus Cristina, fr prea mult
experien, dar dornic s nvee, s demonstreze, s se afirme.
Bla-bla-bla, mai adaugi tu.
- Ce adaug? Bla-bla? l lu Miu peste picior.
- Hai c m enervezi. Neles?
- Am neles, Gogule, da dac cumva chestia asta nu ine? C
efu i mai nedus la biseric... Te sun oricum dup ce vorbesc
cu el...
- Nu m mai suna! Gogu silabisi apsat ultimele cuvinte. Cred
c nici nu voi mai avea semnal, deja nu te mai aud, Miule, alo,
alo, ies din zona cu semnal i revin mine diminea. Pa.
Gogu ntrerupse convorbirea, zmbi n sinea lui i i relu
tacticos meteritul la biciclet.
- Tat...
- Ah, nu! Ce-avei azi cu mine?! Tu ce mai vrei? se ntoarse
disperat Gogu ctre fiul lui. Nu mi-e dat azi s m bucur de ziua
frumoas, de biciclet, de meterit, de nimic. Zi, mi, ce mai e?
Numai c fi-su i tia rolul de morocnos de serviciu i nu i
lu n serios bombnitul teatral. Continu fr a fi descurajat de
atitudinea fals neprietenoas:
- A vrea s merg la petrecerea de ziua lui Andu. Ce zici, vii s
m iei pe la 11-12? Sau, ca s nu te mai deranjez, mai bine dorm
la el. Ne mai jucm Assassins Creed, mai povestim...
- Poftim? Cum s dormi la Andu, ce tu n-ai cas? Asasini deia te poi juca cu el i de-acas. Mai bine ai juca Fifa2014.
50
- Ah, bine, atunci sun-m tu pe la unpe jumate, doipe fr

un sfert, cnd vii spre Andu s m iei. Merci, tata! Copilul fcu
ncntat stnga-mprejur i plec fluiernd.
Gogu rmase nlemnit cnd vzu buna dispoziie a copilului
i ddu seama de capcan. Era ns prea trziu: vorba e vorb. i
mai e i fericit c se duce dup el, de parc n-ar fi fost mult mai
normal s vin copilul acas la 9 sau 10 seara cel trziu. Doamne,
ce l-a mai nvrtit copilul sta pe degete. I-a dat dou variante,
din care, el, Gogu! a ales-o pe cea mai favorabil. Ufff! Acelai
mecanism pe care l explicase cteva minute mai nainte lui Miu
fusese aplicat cu succes pe el. Ha! i l strfulger o idee genial: stai aa, c mine, n loc s-l ntreb pe efu dac e de acord s
mergem ase oameni la Conferina cu mamuii2, mai bine i dau
dou variante: doar ase de la noi din departament sau mai bine
i lum i pe colegii de la testare, i mergem zece... Ce tare e asta...
E vorba de conferina pe teme de managementul proiectelor ...even mammoths can be
Agile, din 6-7 martie 2015, Cluj
sponsori
powered by

Today Software Magazine N31/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 N31/2015

Încărcat de

Drepturi de autor:

Formate disponibile

Nr. 31 Ianuarie 2015 www.todaysoftmag.ro www.todaysoftmag.

Competen sau fraud?

JavaFX i comunicarea prin RESTful

Atacarea complexitii cu TDD i Agile

Internet of Things n universul Java

Silviu Dumitrescu i Diana Blan

V dorim o lectur plcut !!!

Fondator al Today Software Magazine

nr. 31/2015 | www.todaysoftmag.ro

Fondator / Editor in chief: Ovidiu Man

Simona Bonghez, Ph.D.

Speaker, trainer and consultant

Copyright/Corector: Emilia Toma

Editor startups: Mircea Vdan

Owner of Colors in Projects

Reviewer: Tavi Bolog

Contabil : Delia Coman

Today Software Solutions SRL

Copyright Today Software Magazine

www.todaysoftmag.ro | nr. 31/ianuarie, 2015

Realizrile din 2014 i planurile de viitor ale

www.todaysoftmag.ro - 2014 (romn)

online prin lansarea noului site. Identitatea vizual a revistei a fost

Proiecte pentru 2015

www.todaysoftmag.com - 2014 (englez)

De-a lungul anului, evenimentele de lansare ale revistei nu

nr. 31/ianuarie, 2015 | www.todaysoftmag.ro

Este vorba de cardul TSM, o idee care a aprut de mai mult