Numarul 31 - ianuarie 2015 - Today Software Magazine

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 complexităţii 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?

Convergența documentației într-un proiect software multi-modular: o abordare bazată pe Build Automation Technology on Privacy Day

6 Realizările din 2014 și planurile de viitor ale Today Software Magazin Ovidiu Măţan

8 Evenimente și startup-uri în 2014 Mircea Vădan

10 15 tendințe de Marketing Online și tehnologie pe care nu vrei să le ratezi în 2015 Călin Biriș

12 ACADEMY+PLUS Daniela Buscan

15 Arhitectura software (I) Levente Veres

28 Performanța în echipe distribuite Tiberiu Cifor

32 Cinci sfaturi practice pentru Code Review în Scrum Alexandru Bolboacă

34 Convergența documentației într-un proiect software multimodular Alexandru Albu

38 Clasificare de Text la Scară Largă Cristian Raț

40 Internet of Things în universul Java Dănuț Chindriș

18 JavaFX și comunicarea prin RESTful Web Services

44 Ce sistem de distribuire de mesaje din Azure să folosesc?

Silviu Dumitrescu și Diana Bălan

Radu Vunvulea

22 Competență sau fraudă?

Cristian Șerban

24 Diminuarea complexității 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

L

Ovidiu Măţan

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

a mulți ani !!! Pornim la drum în acest an plini de avânt și dornici să facem față noilor provocări. Una dintre acestea este atingerea unor noi obiective pe care și le-a propus TSM. Ne propunem să lansăm cardul de membru TSM și o pagină online dedicată joburilor. Pentru clienții mobile, vom publica în curând o aplicație dedicată telefoanelor Windows Phone. Proiectăm și organizarea de evenimente noi precum o conferință dedicată experților Java, a cărei lansare se va desfășura probabil în vară.

Mai multe informații despre unele dintre aceste subiecte veți găsi în primul articol din acest număr. Vă mulțumim că ați fost alături de noi și de asemenea mulțumim companiilor partenere pentru suportul acordat. În paginile acestui număr am publicat o serie de articole ce vă îndrumă spre o mai bună organizare în cadrul echipei dintre care menționez: Cinci sfaturi practice pentru Code Review în Scrum, Diminuarea complexității cu TDD și Agile, Convergența documentației într-un proiect software multimodular și Performanța î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 oricărui produs software, așa cum argumentează și articolul Competență sau fraudă?. Continuăm cu o analiză a sistemului de mesaje din Azure, pentru ca la final să vă delectați cu lectura ultimului episod din cea mai longevivă serie TSM dedicată aventurilor lui Gogu.

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

Ovidiu Măţan

Fondator al Today Software Magazine

4

nr. 31/2015 | www.todaysoftmag.ro

Lista autorilor Redacţia Today Software Magazine

Tiberiu Cifor tiberiu.cifor@3pillarglobal.com Engineering Manager @ 3Pillar Global

Fondator / Editor in chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com Graphic designer: Dan Hădărău 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ț

Simona Bonghez, Ph.D.

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 Traducător: Roxana Elena roxana.elena@todaysoftmag.com

Cristian.Rat@Yardi.Com

Editor startups: Mircea Vădan 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 Vădan

mircea.vadan@gmail.com www.clujstartups.com

Diana Bălan

Călin 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

Dănuț 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 parțială sau totală a articolelor din revista Today Software Magazine fără acordul redacției este strict interzisă. www.todaysoftmag.ro www.todaysoftmag.com

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

5

interviu

Realizările din 2014 și planurile de viitor ale Today Software Magazine

2

014 a însemnat o perioadă de maturizare prin creșterea numărului și a calității articolelor publicate. Numeric, aceasta s-a reflectat în numărul crescut de accesări online care a ajuns la 7000 sesiuni/lună și de participanți la evenimentele de lansare care a atins o medie de 70-80 participanți. Momentul maxim a fost la lansarea din septembrie a revistei când s-au înregistrat peste 120 de participanți, iar online în perioada IT Days-ului când am trecut de 10,000 sesiuni / lună.

www.todaysoftmag.ro - 2014 (română)

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 exercițiu de profesionalism în domeniu realizat cu ajutorul Gemini Solutions și agenția de design Subsign.

Finalul anului s-a realizat sub umbrela IT Days unde au fost peste 200 de participanți. Nu am să intru în detalii deoarece am scris despre acesta pe larg în numărul trecut. Menționez doar că pe durata celor trei zile, dacă luăm în considerare și cele două workshop-uri, am avut parte de prezentări de excepție ș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 întâlnit cu cititorii revistei și în București, Timișoara, Brașov, Iași și Târgu-Mureș.

Acestea au fost găzduite de către 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 găzduite 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 spațiu comunității de IT locale.

Noutatea principală în 2014 a fost schimbarea 100% a imaginii

6

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

Este vorba de cardul TSM, o idee care a apărut de mai mult timp, dar care abia acum s-a materializat într-o ofertă concretă.

Cardul TSM se adresează membrilor activi ai comunității de IT românești, celor care doresc să își îmbunătățească în mod constant cunoștințele din domeniu, cărora revista TSM le poate aduce un plus de informații lunar și chiar mai mult. Punctual, cardul TSM vă oferă: A. Revista tipărită – Aceasta va fi livrată lunar, pe durata unui an întreg, la adresa specificată de dvs. prin Poșta Română.

Este un modalitate comodă de a vă asigura lunar o lectură de calitate prin revista tipărită. De altfel, revista tipărită 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 tipări ș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 către Today Software Magazine.

D. Reduceri la evenimentele naționale 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 comunitățile locale cum ar fi: eLearning sau o platformă online dedicată voluntarilor

TODAY SOFTWARE MAGAZINE

și organizațiilor de voluntariat. Cei mai Pagina de joburi activi membri vor fi recompensați prin În luna februarie vom lansa un nou invitații 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 întâmpinarea unei piețe a Prețul de lansare a acestui card este IT-ului foarte dinamică prin anunțuri de de 300 RON + TVA / an și se va putea calitate și care vor fi orientate către nevocomanda curând online sau de astăzi dacă ile acesteia într-un mod mai prietenos ne trimiteți un e-mail la adresa card@ decât alte soluții existente la ora actuală. todaysoftmag.com . Prin acest card vă Încurajăm totodată startup-urile, printrarătați totodată susținerea pentru revista o secțiune dedicată acestora și un preț Today Software Magazine și proiectele sale. redus de publicare a unui anunț. Pagina va evolua în viitor și ne gândim să re-publicăm calendarul online și o secțiune nouă

dedicată training-urilor.

Sperăm că v-am făcut curioși și vă așteptăm online la evenimentele de lansare, să deveniți membri TSM și poate chiar să urmăriți viitoarea pagină de joburi.

Ovidiu Măţan

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

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

7

antreprenoriat

Evenimente și startup-uri în 2014

L

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 așezat.

“Mișcarea browniană,, a inițiativelor de suport pentru startup-uri pare mai clară și îmi permit să cred că de-acum vom intra într-o fază de creștere, în care “actorii” sunt deja relativ cunoscuți și își vor juca rolul în continuare.

În cele ce urmează voi încerca o clasificare în funcție de calibrul și scopul general al acestor inițiative, precum și o menționare a câtorva startup-uri care dintr-un punct de vedere sau altul s-au remarcat în ultimul an.

La capitolul evenimente trebuie să remarcăm apariția câtorva concepte noi, astfel că aproape fiecare lună a fost presărată cu un astfel de eveniment:

la a treia ediție. Dincolo de numărul foarte mare de participanți, 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 creștere graduală a implicării feminine- problemă discutată des în alte ecosisteme mult mai avansate, fiind lansate chiar și fonduri de investiții cu scopul de a sprijini antrepreStartup Pirates Cluj 1 - aflat la noriatului tech feminin; prima ediție în februarie 2014, este un eveniment de o săptămână, cu mentori internaționali și workshop-uri menite să dea participanților o viziune clară asupra Transylvania Demoday3 a cumulat ce înseamnă lean startup. S-au abordat două ediții anul trecut (în aprilie și decemurmătoarele teme: business model, cus- brie) și a constat într-o sesiune de pitch-uri tomer validation, pitching, marketing for de câte 4 minute plus întrebări din partea startups, investments. Practic participanții juriului. Fiecare ediție a strâns în jur de 10 au venit pregătiți 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 poziționat încă de

8

1 http://cluj.startuppirates.org/

3 http://startuptransilvania.ro/demo-day/

2 http://cluj.startupweekend.org/

4 http://www.techsylvania.co/

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

la început ca un eveniment cu perspectivă internațională, tematic fiind centrat pe inovație în tehnologii hardware Vă prezentăm câteva 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 căruia echipele puteau să dezvolte soluții la diverse probleme, bazate de tehnologiile menționate mai sus. O nouă ediție a Techsylvania va avea loc la începutul lunii iunie 2015.

Un eveniment dedicat studenților a fost 3 Day Startup Cluj5. Pe lângă implicarea exclusivă a studenților, acest eveniment se deosebește prin faptul că participanții sunt selectați după o aplicație și un interviu față în față, cu o limită de aproximativ 40 de locuri. Asemănător î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/

TODAY SOFTWARE MAGAZINE ci mai degrabă validarea de business mai ales prin interviuri cu posibili clienți și feedback de la mentori.

În noiembrie a avut loc și IT Days dintre ale cărui track-uri menționăm tema antreprenorială. Astfel pe lângă cele câteva pitch-uri ale startup-urilor, au fost prezentate și proiecte de cercetare din cadrul universităților 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, începând în octombrie are scopul de educa participanții 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 găzduiește meetup-uri de care pot beneficia și alte persoane cu startup-uri sau interesate.

Startup Live Cluj 7 a fost ultimul eveniment din an, desfășurat în strânsă legătură cu Transylvania Demoday. Câteva 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 ediție în Cluj. a urma programul de 4 luni. Acestea au primit spațiu 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ă menționăm explozia de rului. De menționat 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 săptămână din această toamnă aveau acceptate. loc cel puțin 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 Alături de aceste programe, de s-au promovat mai ales prin intermediul menționat este și Startcelerate 12 , o meetup.com. Bineînțeles, e important inițiativa născută în Cluj, dar prezentă mai de menționat și lansările revistei TSM, ales în Marea Britanie și care își propune să în cadrul cărora 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 puțin câteva săptămâni, ar fi trei avut o serie de evenimente de pitching și inițiative de menționat: matching, inclusiv în Cluj, iar pentru viitorul apropiat sunt plănuite 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 săptămâni internaționale: și un format axat pe practici non-formale • CallerQ (“we help sales profesde educație antreprenorială cu scopul de a sionals to increase the efficiency of duce participanții 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 câștigat competiția Telekom Innovation Contest pe România.

• 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 educațional 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 (către Telenav și respectiv Facebook), putem menționa și alte câteva 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 profesioniști în imobiliare”); • HipMenu (“food ordering mobile app”); • Squirrly (“content marketing tool allowing you to optimize content and measure its success.”).

Bineînțeles, pe lângă inițiativele de startup-uri noi, în această primăvară vom avea parte și de alte câteva inițiative serioase de suport al ecosistemului, dar despre ele în articolele următoare.

Mircea Vădan

mircea.vadan@gmail.com www.clujstartups.com

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

9

marketing

15 tendințe de Marketing Online și tehnologie pe care nu vrei să le ratezi în 2015

Y

ou can’t 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

Făcând retrospectiva anului 2014, am văzut câteva tendințe și tehnologii care vor schimba cu siguranță modul în care comunicăm, interacționăm și investim în publicitatea online. Așadar, obiectul articolului va consta în prezentarea a zece tendințe de Marketing Online și cinci tendințe tehnologice pentru acest an și pentru anii care urmează.

mult conținut video pe propriile platforme. Războiul cu YouTube abia a început.

3. Lupta pentru conținut video în Social Media

7. Campaniile Omni channel vor fi tot mai importante

Anul trecut, Facebook a introdus funcționalitatea de auto-play la toate video-urile de pe platformă. În consecință, companiile și publicațiile 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 rețele sociale precum LinkedIn sau Twitter să se lupte pentru mai

În prezent, clienții folosesc între zece și douăzeci de surse de informare înainte să ia o decizie cu privire la ce să cumpere. Căutarea este standard, părerile prietenilor sunt aur curat și experiența oferită de produse și servicii este noul marketing.

Companiile nu-și mai permit să nu investească în Marketing Online, astfel vor folosi tot mai mulți 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 (neplătite) postate de către branduri. Aceasta este o veste Tendințe de Marketing Online pentru 2015 proastă pentru companii.

Ne așteptăm ca în acest an să înceapă căutarea unui “next 1. Prezența pe dispozitivele mobile este un “must have”. big (free) thing”, sau cel puțin businessurile se vor orienta să În România 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. populația țării. În 2014 antreprenorii au realizat că nu pot ignora 40% din potențialii lor clienți și au început să gândească mobile. 5. LinkedIn va deveni și mai mult o platformă de conținut editorial În 2015 ne așteptăm să vedem noi magazine online care să intre de business pe piață direct cu website-uri reponsive. De asemenea, magazinele Ai încercat noua funcționalitate “Create a post”? Este super! online care au deja versiuni de site-uri adaptate dispozitive- Orice utilizator al rețelei sociale LinkedIn poate acum să scrie artilor mobile, se vor orienta înspre a-și dezvolta propriile aplicații cole personale care arată foarte similar cu postările de pe bloguri. mobile.

Când 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 conținut cu brand de calitate opțiune să se implementeze și la paginile de business.

De vreme ce peisajul Social Media devine tot mai aglomerat cu mesaje comerciale dar cu un conținut de slabă calitate, companiile 6. Facebook @ Work deștepte vor investi în diferențierea printr-un conținut 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. Așteptăm clienți noi și poate să-i fidelizeze pe cei existenți. să încercăm o versiune beta.

10

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

TODAY SOFTWARE MAGAZINE

integrată.

8. Companiile vor investi tot mai mult în publicitate pe Social Media Noul algoritm al Facebook-ului forțează companiile să investească în publicitate pe Facebook pentru a ajunge cu mesajele postate la toți fanii paginilor de brand. Făcând acest lucru businessurile vor învăța că reclamele de pe Facebook sunt ușor de creat, foarte bine targetate, ieftine și oferă interacțiuni extra pe gratis.

Aceasta este un târg bun pentru orice brand și în consecință ne așteptăm la tot mai multă publicitate pe Facebook și pe alte rețele sociale.

9. Companiile vor investi mai mult în reclame video Ținând cont că Generația Y nu mai urmărește atât de mult TV și petrece mai mult timp navigând pe internet, marile branduri își vor reprograma o parte din bugetele de reclamă de pe TV în publicitate video online.

Așa 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 către clienții lor. Noi am experimentat anul trecut cu publicitatea video pe Facebook și rezultatele au fost surprinzător de bune, astfel ne așteptăm să vedem mai multe reclame pe monitoare și ecranele smartphoneurilor sau tabletelor noastre.

10. Companiile vor începe se facă retargeting În 2014 am văzut câteva exemple de campanii de retargeting.

Anul acesta ne așteptăm la mai multe retargetări inteligente și mai multe branduri care să apeleze la această tactică. În concluzie, la tendințele în Marketing Online, credem că să nu apară și să fie implementate la noi foarte rapid.

2015 va fi anul comerțului pe mobil, al conținutului de calitate și a reclamelor sociale și video.

14. Beacons Clienții vor fi mai bine țintiți, mai delectați și mai informați 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 informații utile despre clienți și ne dă posibilitatea să facem reclamă contextuală Tendințe tehnologice în 2015 mult mai precisă. Ne așteptăm la noi dezvoltări pentru această tehnologie.

11. Aplicațiile mobile de sănătate ș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 brățările și ceasurile nou apărute nu prea există aplicații dezvoltate și acest lucru nu le face foarte “cool”.

Soluția ar putea veni de la aplicațiile de sănătate. Spre exemplu: ar fi util a avea un ceas care să ne ajute să știm informații vitale despre corpurile noastre.

15. Mașini care se conduc singure

Cea mai importantă știre la CES 2015 a fost despre mașinile care se conduc singure. Audi a trimis un model de test A7 într-o călătorie de la San Francisco până în Las Vegas fără intervenția unui șofer uman. Modelul A7 a ajuns în Las Vegas fără 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ă profităm la maxim Dacă filmele 3D au avut mult succes când toată lumea le-a și să contribuim să fie un an excelent. Bucură-te de el! Fă conexiputut urmări în cinematografe, realitatea virtuală ar putea fi noua unea între puncte și cu siguranță vom vorbi în 2016 despre cum revoluție î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. Plăți cu mobilul

Călin Biriș

În SUA, oamenii pot folosi Apple Pay și Google Wallet. Se zice că aceste soluții sunt “the next thing” cu privire la plăți. Din păcate, în România încă încercăm să educăm consumatorul să plătească online cu cardul. Așadar, s-ar putea ca plățile cu mobilul

Digital Director @ Loopaa

calin.biris@loopaa.ro

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

11

educație

Tinerii români pasionați de informatică au acces la o metodă inovativă de învățare prin intermediul ACADEMY+PLUS

D

ezvoltarea sectorului IT creează an de an locuri de muncă din ce în ce mai interesante și mai atractive pentru tinerii pasionați de domeniul informaticii. Dar în contextul valului ascendent de angajări din ultimii ani, companiile au început să caute profile din ce în ce mai complexe. În același timp, există și candidați care au înțeles că pentru a se diferenția au nevoie de formule complementare de formare profesională.

Din acest motiv, în ultimii ani, la nivel național au apărut o serie de metode alternative de învățare care oferă candidaților experiența unei specializări 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, atât în SUA cât și în Europa, respectiv România, iar acest gol vine pe de o parte din cifrele de școlarizare, iar pe de altă parte din lipsa unor competențe calibrate cu cerințele pieței.

Dacă ne raportăm la cifre, în România există aproximativ 100.000 de angajați în domeniul IT la nivel național, iar cererea de ocupare în 2014 a fost de 17.148 oferte de muncă pe diverse stadii de specializare în cele mai mari orașe din România - conform ofertelor de muncă publicate de site-urile de specialitate.

Pe fondul acestor constatări, nu trebuie să ignorăm nici faptul că cei mai străluciți dintre absolvenții de liceu sau facultate cu profil tehnic, aleg fie să își continue studiile în afară țării, fie să lucreze pentru companii renumite din străinătate.

Pornind de la aceste premise, anul trecut compania PITECH+PLUS a lansat o metodă revoluționară de învățare și formare profesională în domeniul IT. ACADEMY+PLUS este o școală nouă, bazată pe o programă actualizată cerințelor pieței și, în același timp, utilizând o metodă inovativă de învățare pentru elevi.

Obiectivele școlii sunt să rezolve pe de o parte necesitatea companiilor de IT de a avea angajați capabili să înțeleagă un

12

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

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 abilități de învățare spre zona informaticii.

ACADEMY+PLUS a fost lansată pe piața din România pe baza unui parteneriat cu Școala 42 din Paris. Această din urmă nu este altceva decât o pepinieră de 1000 de elevi/an care învață informatică după reguli dictate de industrie.

Parteneriatul semnat în martie 2014 a pus în mișcare un proiect unic pentru industria de IT din România: lansarea unei școli deschise oricărei persoane pasionate de informatică, finanțată exclusiv de compania clujeană PITECH+PLUS. Admiterea la ACADEMY+PLUS se face în aceeași manieră ca la 42: pre-selecție, check-in – un interviu cu candidații care trec de pre-selecție, piscina – o testare de 28 de zile și go/no go. La finalul celor trei evaluări de 28 de zile, din aproximativ 1200 de înscriși pe platforma de candidatură doar 58 de candidați au obținut 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 dispoziție.

Elevii selectați nu reprezintă un grup omogen de persoane care au aceeași vârstă sau preocupări. Admiterea s-a adresat tuturor celor care sunt pasionați de informatică, iar în afară de rezultatele obținute la testări, echipa care s-a ocupat de recrutare nu a luat în considerare vârsta (decât în cazul minorilor) sau experiențele anterioare. Așadar, printre elevii ACADEMY+PLUS se regăsesc proaspăt absolvenți de liceu, dar și persoane care își doresc o reconversie profesională în domeniul IT.

TODAY SOFTWARE MAGAZINE filiale în alte orașe din România.

Pe termen lung, obiectivele ACADEMY+PLUS sunt să se ridice gradul de colaborare între companiile care caută tineri talentați, să crească standardele de performanță ale industriei și să descopere prin intermediul metodei sale minți strălucite care pot crea produsele informatice de mâine.

Unicitatea acestui proiect se reflectă din mai multe unghiuri.

Pe de o parte, școala în sine reprezintă un micro-mediu organizațional. Elevii au dispoziție un spațiu complet dotat tehnic, o sală de jocuri, săli de brainstorming și profesioniști care le stau la dispoziție având calitatea de mentori și nu aceea de profesori.

Ingredientele psihologice care determină funcționarea acestui întreg ansamblu în absența unui orar, a unor ore de prezență stricte sau a unor condiționări, sunt self-responsibility și dezvoltarea abilităților decizionale. Şcoală pornește de la premisa că există creativitate în IT și le oferă elevilor libertatea să experimenteze în jurul unei comunități pe care și-o creează singuri. În ceea ce privește metoda și programa, există câteva elemente care le particularizează : • Peer-to-peer learning – elevii învață să se evalueze unii pe ceilalți, iar în cele din urmă, obiectivul este ca aceștia să deprindă abilități de analiză.

• Muncă în echipa – atât evaluările, cât și o parte din proiecte se realizează în echipa. În acest mod elevii sunt încurajați să comunice eficient unii cu ceilalți.

• Practică – elevii primesc toate instrumentele necesare pentru a parcurge o problematică, apoi răspund unui exercițiu printr-o aplicație practică.

• Comunitate – elevii sunt ghidați să își creeze propria lor comunitate, cu propriile lor valori.

Pe termen scurt, obiectivele noastre țin de triplarea numărului de elevi în 2015, customizarea de module de formare prin intermediul cărora să crească gradul de flexibilitate și personalizare în conformitate cu pregătirea individuală a fiecărui candidat, astfel încât 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

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

13

comunități

Comunităţi IT

A

nul 2015 ne promite o serie de evenimente de calitate și începem cum altcumva: Lansarea numărului 31 TSM. Vă propunem pentru această lună Mobile Monday în Cluj și evenimentele Taberei de testare din Iași și Timișoara. Un eveniment nou ce va fi inaugurat la începutul acestui an în Cluj este OWASP Cluj-Napoca cărora le dorim succes.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

Website: www.transylvania-jug.org Data înfiinţării: 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 înfiinţării: 06.02.2012 /Nr. Membri: 2068/Nr. Evenimente: 28 Cluj Business Analysts Comunitate dedicată analizei de business Website: www.meetup.com/Business-Analysts-Cluj Data înfiinţării: 10.07.2013 / Nr. Membri: 91 / Nr. Evenimente: 8 Cluj Mobile Developers Comunitate dedicată tehnologiilor mobile Website: www.meetup.com/Cluj-Mobile-Developers Data înfiinţării: 05.08.2011 / Nr. Membri: 264 / Nr. Evenimente: 17 The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software.

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

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

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

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

14

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

Calendar Ianuarie 20 (Cluj) Lansarea numărului 31 al Today Software Magazine www.todaysoftmag.ro Ianuarie 22 (Timișoara) 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 (Iași) 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 (București) 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

Arhitectura software (I)

T

impul trece, știința evoluează, cerințele oamenilor cresc, adaptarea la schimbări în orice domeniu devine cerință de bază. În același timp, așteptările sunt în creștere dacă vine vorba despre calitate, accesibilitate, securitate și nu în ultimul rând cost.

Industria de IT din ultimi ani a adus în discuție necesitatea sau inutilitatea arhitecturii de

Levente Veres

Levente.Veres@endava.com Design Lead @ Endava

software sau arhitecților de software. În articolele ce vor urma doresc să abordăm câteva teme legate de domeniul arhitecturii de software și cel al rolurilor de arhitect software, business, IT etc.

Vom încerca să schițăm un proces de lucru care să ne ajute la crearea unei arhitecturi. Vom aborda cerințele unui document SAD (software architecture document), ce Framework-uri putem aplica (4+1 View model, Togaf, Zachman), uneltele ce se pot folosi și desigur niște noțiuni care țin mai mult de Business, resurse umane şi comunicarea cu alții.

Istoria arhitecturii software

Cuvântul în sine provine din limba latină architectura, adaptat la rândul său din cuvântul grecesc arkhitekton. Acesta este un cuvânt compus din arkhi (lider, șef, cel pe care se poate urma) și cuvântul tekton (constructor, artizan, creator, planificator, maestru în domeniu). În IT primele noțiuni au apărut în ani `60, urmând ca după ani `80 când deja sistemele au ajuns la o complexitatea ce necesita organizare și planificare mai eficientă, dezvoltatorii au început să exploateze avantajele de a planifica intenționat structura soluțiilor în diferite domenii. Au început să definească soluții comune pentru probleme specifice sau repetabile, reutilizabile.

Să nu uitam ca în `79 a apărut primul calculator personal (Apple II) care aducea cu el VisiCal (predecesorul lui Excel ). În 1981

apare MS-DOS, iar în 1983 apare Word din bucătăria firmei Microsoft.

Până 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 definește 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 când cunoștințele și teoriile acumulate au început să se aplice în practică. Momentan suntem participanți activi la aplicarea și popularizarea necesității arhitecturilor software și metodologiilor aferente.

Din studiile realizate de IEEE am selectat graficul de mai jos care oferă o vizualizare completă a evoluției 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, apărută în 2012 la Addison-Wesley (autorii

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

15

programare Arhitectura software (I) Scopul Arhitecturii software.

Scopul unei arhitecturi de software poate fi diferit, de la caz la caz în funcție de necesitățile specificațiilor inițiale. Totuși se poate defini un subset de scopuri comune care vizează: 1. Beneficiile care sunt aduse în urma modificărilor.

2. Selectarea motivației principale referitoare la crearea sau schimbarea soluției? (De exemplu, de ce dorim ca noua aplicație de HR să aibă acces la cheltuielile personale din aplicația XYZ).

3. Perspectiva generală asupra structurilor, interacțiunilor cu alte sisteme (high level overview) 4. Componentele, cerințele importante. Acestea vor fi punctele critice care pot avea impact major. De exemplu: securitatea aplicației sau aspectul responsiv al interfeței.

Maturitatea domeniul de arhitectură software

Bass, Clements și Kazman) se definește în următorul format: „Arhitectura este rezultatul unui set de decizii de afaceri și tehnice. Schița (desing) în momentul creării este influențată din mai multe părți, astfel și execuția va fi influențată de schimbări în funcție 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ă definiție din aceeași lucrare este: „Arhitectura software a unei aplicații sau sistem este structura sau structura sistemelor, ce combină elemente de aplicații, proprietățile vizibilității externe a acestor elemente și relația între ele.”

IASA (The Global IT Architect Association) definește noțiunea de IT arhitectură ca: „Arta sau știința schițării (design) și arta de a livra strategie tehnologică utilă.”

Dar arhitectura software poate fi considerată ca un mediu de facilitare de discuții a alegerii unei soluții de aplicații între solicitanții aplicației (business owner, stackeholder) și cei care vor livra, astfel încât să se ia decizii fundamentale de creare de aplicații care pe parcurs vor ajuta ca produsul finit să aibă factori de cerințe satisfăcătoare tuturor. Dintre acești factori menționăm: eficiență de cost, extensibilitate, modularitate, adaptabilitate, scalabilitate, securitate, calitate etc. .

Concluzionând, putem considera arhitectura software ca mediul de definire a structurilor, elementelor și a relațiilor.

16

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

Lista se poate extinde după dorințele fiecăruia, e important ca la final să se răspundă la întrebările: 1. Ce dorește să rezolve arhitectura software?

2. Costurile acesteia? E asumabilă de către beneficiar?

3. Implicațiile personalelor- stackeholder-i, dezvoltatori, designeri, arhitecți, 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 organizațional ce e întreținut de sisteme care la rândul lor sunt compuse din aplicații, hardware, structura de organizație, surse și structuri de informații.

TODAY SOFTWARE MAGAZINE 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 interferența sa cu mediul de afaceri și cu implicațiile sale asupra mai multor sub entități sau firme (Cross Company Boundaries).

2. Arhitectura software, cu scop de definire a designului de aplicație, componente/elemente și relație între componente/ elemente.

3. Arhitectura hardware definește designul de hardware necesar cum ar fi CPU, spațiu de stocare, spațiu de memorie, mediu de transfer de date (Wan, Lan), echipamente conexe (ex.: imprimanta sau echipament de scanare), medii de backup, medii de funcționare (in house, hosted, cloud).

4. Arhitectura organizațională definește relațiile de afaceri (business relations), procese de afaceri (business process), structură organizațională (ierarhizare), roluri și responsabilități, competentele organizaționale (departamentele) și relația lor.

5. Arhitectura informațională definește structura entităților de date, sursa și organizarea acestora, de fapt structura datelor și accesibilitatea eficientă acestora în diferite baze de date.

Sperăm că prin acest prim articol am reușit să vă introducem într-un domeniu complex precum cel al arhitecturii software.

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

17

programare

JavaFX și comunicarea prin RESTful Web Services

Silviu Dumitrescu

O aplicație client poate accesa resurse distribuite aflate la distanță. Există mai multe modalități de accesare a acestor resurse, dar poate cea mai portabilă este cea a serviciilor web. În acest articol vom aduce în discuție serviciile REST (Representational State Transfer), servicii autodescriptive, moderne, cu un API Java ce are evoluție spectaculoasă în ultimele versiuni ale platformei Java Enterprise.

Vom începe prin discutarea unor aspecte arhitecturale, care țin de înțelegerea componentelor ce fac parte dintr-o aplicație distribuită, ce folosește serviciile web.

Java Line Manager @ Accesa

Arhitectura pe două nivele (two tiers)

silviu.dumitrescu@accesa.eu

Diana Bălan

Diana.Balan@accesa.eu Java developer @ Accesa

Această arhitectură are două componente esențiale: A. Aplicația client cu următoarele 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 aplicației cu observația că aceasta poate fi limitată de capacitatea stației client (memorie, CPU) și în plus necesită cod ce trebuie distribuit fiecărui client.

B. Serverul de baze de date.

O aplicație client JavaFX constă din următoarele: • o componentă ce conține fișiere FXML reprezentând front-end-ul, clasele corespunzătoare controller-ului ce execută event handling, o clasă de lansare a aplicației, fișiere CSS precum și clase de formatare; • o componentă ce conține clasele entitate, care sunt mapate tabelelor bazei de date; • o componentă ce conține clasele ce fac operații pe baza de date utilizând componenta anterioară (clase DAO); • JPA, ce este folosit pentru conectarea la baza de date și pentru a efectua mai ușor operațiile pe aceasta; • Avantajele folosirii acestei arhitecturi

18

nr. 31/2015 | www.todaysoftmag.ro

sunt: • Este mult mai extensibilă decât arhitectura pe un nivel.

• Combină într-un singur sistem logica prezentării, logica business și resursa de date.

• Poate avea un client pe orice host atât timp cât acesta este conectat printro rețea la baza de date.

• Are mai puține puncte sensibile, generatoare de erori, decât sistemul pe trei nivele.

diverse

TODAY SOFTWARE MAGAZINE

aflată pe serverul de baze de date; web. Aplicația devine astfel extensibilă și • Componentele vor fi publicate ca interoperabilă cu diferite tipuri de aplicații servicii web; client.

• Serviciile web vor fi dezvoltate utiliExistă două tipuri de servicii web: zând Jersey, care este o implementare a • SOAP (Simple Object Access specificațiilor JAX-RS; Protocol) folosesc mesaje XML ce defi• Vor fi deploy-ate pe un server de nesc arhitectura mesajului și formatele aplicație, spre exemplu Glassfish, și pot acestuia. Aceste sisteme conțin deseori fi consumate folosind HTTP. o descriere a operațiilor oferite de serviciu, scrise în fișierul WSDL (Web Service Așadar, serverul de aplicație va conține Description Language), care este de fapt o colecție de servicii web RESTful, care la un fișier XML. rândul lor vor comunica prin JPA cu ser• RESTful (Representional State verul de baze de date. Serverul de aplicație 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 decât SOAP, nu necesită Arhitectura pe trei nivele (three tiers) three tiers: XML sau definiții WSDL. Se bazează Are următoarea structură: • Permite o utilizare eficientă a pe specificațiile JSR-311, iar Jersey este • Aplicația client. Mult mai puține conexiunii la resursa de date folosind o implementare a acestora. Serviciile resurse sunt necesare pe stația client. Nu connection pooling; REST folosesc W3C și standardele IETF sunt necesare modificări dacă locația • Putem modifica business logic-ul fără (Internet Engineering Task Force): a afecta software-ul clientului; HTTP, XML, URI, MIME. • Este o arhitectură mult mai potrivită pentru scalare și load balancing decât Vom utiliza serviciile REST pentru altele; integrarea prin web și vom utiliza serviciile • Scalarea afectează în primul rând SOAP în aplicații enterprise ce au scenarii middle tier-ul. de integrare care cer calități avansate ale Dezavantajele sunt: serviciilor (QoS) .

• Crește traficul de rețea; Vom alege JAX-RS pentru că serviciile • Este mult mai vulnerabilă la greșeli; sunt mai ușor de consumat pentru multe • Obiectele business trebuie gân- tipuri de clienți, în timp ce permite servedite pentru a gestiona integritatea rului să evolueze și să se scaleze. Clienții tranzacțiilor. 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 Aplicațiile REST sunt simple, lightutilizată frecvent pentru aplicații mari. weight și rapide pentru că: Este cea pe care o vom aduce în discuție în • Resursele sunt identificate prin URI, acest articol și în următoarele articole pe ceea ce furnizează o modalitate de adreaceastă temă. sare globală. În partea următoare vom face o scurtă • O interfață uniformă este folosită trecere în revistă a paradigmei serviciu pentru manipularea resursei. web, ca modalitate prin care clarificăm • Sunt folosite mesaje autodescriptive ideile și pentru cei mai puțin familiarizați sau metadate pentru resurse. cu această paradigmă.

• Interacțiunile 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 aplicației cu implicații asupra fiecărui client. Aceasta poate fi foarte costisitoare și consumatoare de timp.

• Fiecare client necesită o conexiune la resursa de date.

• Restricționează sau complică adăugarea de caching, mirroring, proxy services sau tranzacții securizate.

• Cum logica de business se află la client, întreaga bază de date este expusă în rețea.

Servicii Web

Sunt aplicații ce comunică prin HTTP în WWW. Ele furnizează un standard ce facilitează interoperabilitatea aplicațiilor 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 obține Aplicația pe partea de server de operații complexe. aplicație se descrie astfel: Prin utilizarea serviciilor web o • Va conține business logic-ul pentru a aplicație pe două nivele poate fi modificată efectua operații CRUD pe baza de date la una pe trei nivele, ce poate opera peste bazei de date se schimbă, mai puțin cod este de distribuit stațiilor client; • Serverul de aplicație manipulează cererile mai multor clienți, reduce traficul de date în rețea; • Serverul de baze de date.

REST indică o arhitectură client server fără stare. Un serviciu REST expune o mulțime de resurse ce identifică destinațiile interacțiunilor cu clienții. Resursele sunt identificate prin URI și sunt manipulate de patru operații: PUT, GET, POST și DELETE. Resursele sunt decuplate de reprezentare astfel încât pot fi accesate într-o varietate de formate: HTML, XML, plain text, PDF, JPEG și JSON. Metadatele despre resurse sunt folosite pentru a controla

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

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 interacțiune cu o resursă este stateless, mesajul este public Hello() { așadar self contained. Avem la dispoziție mai multe tehnici de a // TODO Auto-generated constructor stub } trimite starea precum: rescrierea URI-ului, cookie-uri, câmpuri hidden. Starea poate fi inclusă în mesajul de răspuns pentru a crea /** * Retrieves representation of an instance of stări viitoare ale interacțiunii. * Hello Clienții serviciului web, care doresc să folosească aceste * @return an instance of String */ resurse, accesează o anumită reprezentare prin transferarea @GET conținutului aplicației folosind un mic set de metode remote ce @Produces(“text/plain”) public String sayHello() { descriu acțiunea ce trebuie făcută pe resursă. // TODO return proper representation object • GET este folosită pentru a obține 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 răspunde cu date sau cu un status ce indică succesul * @param content representation for the resource * @return an HTTP response with content of the sau eșecul. * 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 acțiunile de update sau delete pot fi făcute } prin POST, de e-xemplu când serviciul este consumat de browsere ce nu suportă PUT sau DELETE). Următoarele mapări pot fi Adnotațiile utilizate sunt: aplicabile pentru PUT sau POST: • Valoarea adnotației @Path este un URI relativ. Clasa Java • Creare = PUT dacă trimitem întreg conținutul 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 căile URI sunt URI-uri cu variatru a crea o resursă subordonată resursei specificate, folosind bile incluse în sintaxa URI algoritmi server-side; • Adnotația @GET este destinată metodei cererii, împre• Update = PUT, dacă modificăm întregul conținut al resurună cu @POST, @PUT, @DELETE, @HEAD și este definită de sei specificate; JAX-RS, corespunzând 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 căreia resursa îi răspunde.

Dezvoltarea unui serviciu web REST cu JAX-RS • Adnotația @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ă ușureze dezvoltarea aplicațiilor ce folosesc arhimite clientului. În cazul exemplului tipul este: text/plain. tectura REST. • Adnotația @Consumes este utilizată pentru a specifica • Utilizează adnotații Java pentru a simplifica dezvoltarea tipul MIME pe care o resursă îl poate consuma și care a fost serviciilor REST. trimis de client.

• Utilizează adnotații runtime, care prin reflecție vor genera clasele helper și artefactele pentru resursă. În Eclipse crearea structurii fișierului se face urmând pașii: Jersey implementează suportul adnotațiilor definit de specificațiile JAX-RS. O arhivă a aplicației Java EE conținând clasele resursăJAXRS vor avea resursele configurate, clasele helper și artefactele generate și resursa expusă clienților prin deploy-ul unei arhive pe serverul de aplicație.

Fie următorul exemplu de fișier ce reprezintă codul clasei resursei root a unui serviciu web REST, ce utilizează adnotații 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

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

Proiectul în care am creat resursa este un Dynamic Web Project în care:

TODAY SOFTWARE MAGAZINE Arhitectura three-tier folosind REST este dată în diagrama următoare:

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 adnotației @Path.

Pașii în generarea unui serviciu web REST sunt: 1. Verificarea următoarelor condiții: • Jersey este adăugat proiectului; • JAX-RS API este adăugat proiectului.

2. Generarea propriu zisă a serviciilor web: • Crearea serviciilor REST; • Validarea claselor web service generate; • Validarea configurației în fișierul web.xml.

Când testăm un serviciu web trebuie să avem în vedere următoarele: • Adresa URL reprezintă corect endpoint-ul serviciului deployat și adnotațiile metodei; • Cererile GET, PUT, DELETE, sau POST invocă metodele potrivite ale serviciului.

• Metodele returnează datele așteptate.

Crearea unui client

Pașii de urmat pentru a dezvolta un client al serviciului web Jersey conține o bibliotecă REST ce poate fi utilizată pentru REST sunt: testarea sau crearea unui client Java.

• Asigurarea că proiectul are adăugate toate bibliotecile Vom crea o Aplication Client Project, cu următorul cod: necesare; • Identificarea ferestrei GUI și verificarea locului unde rezulimport java.net.URI; tatele invocării serviciului web vor fi afișate; • Următoarele informații 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 aplicații mai complexe, care să includă și interacțiunea cu o bază de date.

Vă dorim lectură plăcuta și așteptăm cu interes întrebările voastre!

Diana Bălan, Java Developer la Accesa Silviu Dumitrescu, Java Line Manager la Accesa

} private static URI getBaseURI() {

return UriBuilder.fromUri(“http://localhost:8080/JerseyFirst/”).build(); } }

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

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 începând 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 câte un tricou la primii 20 de participanți 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. Așa că nu mi-a luat mult timp să descopăr o vulnerabilitate și să reușesc să o exploatez în timp util. Am reușit să mă înscriu puțin mai înainte de ora oficială. În următoarea zi m-am prezentat la conferință la intrare, am salutat politicos, mi-am spus numele, colegul m-a cautat pe listă și m-a găsit destul de ușor. Am tras puțin cu ochiul: eram primul 11:58. Perfect.

Uimit puțin, acesta a zis: “Ah tu ești ăla, cum ai reușit?”. La întrebarea mea dacă primesc un tricou, el a răspuns că nu, dar că o să primesc ceva mai bun. În timpul conferinței m-a anunțat public și mi-a înmânat drept premiu cartea “Writing Secure Code” a lui Michael Howard și David LeBlanc.

Puțin dezamăgit, m-am întrebat oare de ce îmi dă mie cartea aceasta. El avea nevoie mai mare de carte, el avea nevoie să învețe să scrie cod mai sigur nu eu.

Dacă deplasăm această întâmplare într-un cadru puțin mai critic cum ar fi de exemplu un site pe Internet unde clienții își pot crea cont și să își depoziteze banii în cont cu scopul de a-i folosi mai târziu, cartea și tricoul de mai devreme se transformă în alte lucruri mai de valoare. În loc de un tricou, atacatorul își dorește să obțină banii clientilor, și primește în loc de o carte, ani de închisoare.

De exemplu, un individ pe nume Alistair Peckover a fost condamnat prima dată la 26 de săptămâni cu suspendare, având 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 execuție după ce și-a cumpărat

22

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

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. Când a primit ultima sentință judecătorul 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 atenția. Adică el ar fi un mare geniu sau un super meseriaș în ale calculatoarelor. Dar dacă ne uitam un pic mai atent la viața lui, vedem că locuia cu părinții 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ă găsească jocuri care au fost scrise de programatori care nu au citit cartea “Writing Secure Code”. Găsea vulnerabilități în ele și le exploata pe bani adevărați. După multe încercări și experiență a devenit un expert în domeniu.

De ce se întâmplă lucrurile astea? Din mai multe motive. Ca să numesc două: pentru că oamenii sunt lacomi și vor să aibă mulți bani, dar și pentru că site-urile sunt scrise de către oameni și este în natura lor să facă greșeli.Vulnerabilitățile de securitate nu sunt altceva decât erori de programare. Programatorii nu au învățat în facultate foarte multe despre vulnerabilități de securitate. Nici product owner-ii nu le cunosc, așa că cer echipelor de dezvoltare să implementeze doar feature-urile dorite de business, cât se poate de repede. Dacă reușesc să livreze înainte de termen primesc bonus! Totuși, oricine poate învăța despre vulnerabilități de securitate dacă are ceva timp la dispoziție.

Noi cei care lucrăm în departamentul de Application Security studiem aceste fascinante vulnerabilități de securitate. Eu le numesc fascinante pentru că multă lume le vede ca fiind ceva magic, ceva ce doar geniile pot înțelege. Dar de fapt oricine le poate vedea și înțelege, este nevoie numai de timp și dedicare. Noi descoperim aceste vulnerabilități în codul scris de programatorii noștri, îi sfătuim cum să le fixeze și îi învățăm cum să le prevină data următoare.

Pentru a îndeplini acest job am implementat un proces pe care unii îl numesc Secure Software Development Lifecycle. În mare acesta constă în următorii pași: 1. Lucrăm împreună cu arhitecții ș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 funcție de funcționalitatea produsului și locul unde va fi folosit.

2. Stăm aproape de echipele de dezvoltare și avem vizibilitate asupra sprint-urilor astfel încât atunci când au de implementat un user story care atinge date sau funcționalitate sensibilă din punct de vedere al securității, programatorii se consultă cu noi și împreună stabilim cum se va implementa corect.

3. Când avem funcționalitatea implementată facem un test de securitate manual, prin care verificăm dacă nu cumva s-au strecurat ceva vulnerabilități.

Astfel ne asigurăm că în producție nu vor fi probleme. Acest test de securitate implică code review, user story review și un penetration test pe toată funcționalitatea nou implementată în sprint-ul curent.

TODAY SOFTWARE MAGAZINE În biroul din România suntem două persoane pe Application Security și avem aproximativ 16 echipe de dezvoltare. Asta înseamnă o grămada de muncă. Așa că am cerut ajutor. Am cerut ajutorul programatorilor spunându-le: ”voi vă cunoașteți cel mai bine codul, voi știți cel mai bine cum funcționează aplicația și voi știți fiecare linie de cod ce face pentru că voi ați scris-o.” După care am continuat: ”avem o propunere pentru voi, noi vă învățăm care sunt vulnerabilitățile posibile și cum să le evitați și voi ne ajutați cu îmbunătățirea securității în produsele la care lucrați.

Așa că acum avem o echipă virtuală de “Security Champions” formată din câte cel puțin un programator din fiecare echipă plus reprezentați din celelalte echipe, cum ar fi QA, DevOps, IT. Ținem în mod regulat conferințe de securitate interne cu prezentări și workshop-uri și deseori invităm și oameni cu expertiză din afara firmei. Noi îi învățăm cum să fie “hackeri”, cum să folosească diferite unelte de securitate cu care să-și testeze produsele, astfel încât să scrie cod care nu poate fi hackuit prea ușor.

Programul de Security Champions este eficient pentru că în acest mod cel puțin o persoană se gândește la aspectele de securitate din cadrul echipei.

Este o situație win-win pentru toată lumea, atât pentru campioni pentru că își dezvoltă skil-uri ninja cât și pentru companie și pentru echipa de security. Așa că acum noi putem pleca pe o insulă exotică și să stăm la plajă, pentru că programatorii noștri scriu cod sigur, iar hackerii nu pot fura bani. Câteodată mai primim un

telefon de la HR care ne informează că încă un developer a trecut la management sau că au angajat alți cinci programatori proaspăt absolvenți de facultate în locul lui și că trebuie să ne întoarcem să îi învățăm să scrie cod sigur.

Referințe 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

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

23

programare

management

Diminuarea complexității cu TDD și Agile

Î

n ultimii ani complexitatea proiectelor a crescut încet până la punctul când modalitățile utilizate în trecut pentru diminuarea sa au devenit ineficiente. În prima parte a articolului vă voi împărtăși motivele pentru care consider complexitatea ca pe un aspect de care ne vom izbi timp îndelungat și despre care cred că va crește standardele a ceea ce înțelegem noi prin software acceptabil.

Radu Ometita

radu.ometita@fortech.ro Software engineer @ Fortech

24

nr. 31/2015 | www.todaysoftmag.ro

Complexitatea este legată în primul rând de legea lui Moore și de creșterea incredibilă a puterii computaționale de care se dispune în prezent. Aceasta le-a permis sistemelor software să înceapă să facă față cu mare ușurință problemei complexității crescute, în ciuda evoluției mai lente a paradigmelor de programare. Chiar și cu apariția procesării multicore abia am început să simțim saltul în complexitatea software-ului când e vorba de programare concurentă. Întrucât legea lui Moore și-a atins platoul și se pare că nimeni nu e dispus să investească în creșterea puterii de procesare a nucleelor individuale (dacă nu chiar în eliminarea puterii pe care o au), ne confruntăm cu dilema dificultății scalării aplicațiilor noastre. Se pare că nu există o soluție facilă pentru această problemă, pe care să o putem aplica menținând în același timp stilul și modelul nostru actual folosit în dezvoltarea de software, potrivit pentru aplicații ce rulează pe un singur nucleu.

Puterea de procesare sporită din ultima decadă a dus la o creștere a așteptărilor cu privire la ceea ce trebuie să facă aplicațiile de business. Una dintre schimbările cele mai interesante remarcate de noi este ca software-ul trebuie să fie tot mai maleabil si ușor de îmbunătățit pentru a ține pasul cu ritmul schimbărilor. Aceasta e probabil principala forță motrice pentru Agile și cauza buclelor de feedback tot mai strânse.

Complexitatea are deci două surse. în primul rând, businessul are nevoie de timpi de răspuns mai scurți la solicitările de modificări, aspect ilustrat de acapararea majorității proiectelor și firmelor de software de către metodologiile Agile. Nu am întâlnit pe nimeni suficient de curajos pentru a încerca o metodologie Waterfall pe un proiect complex în prezent. Pe de altă parte, suntem nevoiți să facem față unor aplicații paralele care cresc semnificativ complexitatea elaborării software-ului din cauza căreia putem vedea această apariție a paradigmelor programării funcționale în majoritatea, dacă nu toate, limbajele principale.

Un cadru (framework) pentru complexitate

Pentru a înțelege de ce par să dea greș fără drept de apel abordările vechi când se aplică unor proiecte foarte dinamice e nevoie de o bună înțelegere a noțiunii 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 abordări. Merită menționat că nu tot ce funcționează 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

TODAY SOFTWARE MAGAZINE Waterfall. Un exemplu de sarcina corespunzătoare acestui nivel ar fi unul ce implică scriere de driver-e pentru dispozitive. Deși soluția poate necesita o experiență extensivă, există o mulțime de Bune Practici pentru a te ghida spre o soluție acceptabilă. Specificațiile nu se vor schimba foarte mult, ele fiind constrânse de interfața 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 constrângeri. Constrângerea unui domeniu complex dă naștere unui domeniu mai puțin complex, iar constrângerea acestuia rezultă unui domeniu simplu.

Desigur, direcția poate fi și inversă (datorita unui eveniment ce proiectează problema în domeniul haotic, o schimbare în specificații, direcție sau toate cele menționate mai sus), caz în care ar trebui să urmăriți cu atenție semnele ce vă permit să încadrați corect problema în domeniul său de complexitate și să o abordați într-un mod potrivit.

Se va prezenta în continuare o scurtă descriere a domeniilor de complexitate, conform definiției Cynefin Framework.

Simplu

Contextele simple sunt caracterizate de faptul că răspunsul 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 făcut într-un singur mod. Aceasta este zona ‘Best Practices’, unde cauzalitatea unei chestiuni este clar înțeleasă.

La acest nivel abordarea unei probleme începe prin evaluarea situației și includerea ei in categoria potrivită. Ulterior se trece la soluționarea 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 puteți considera

un cod pe care-l poate scrie chiar și un copil sau non-programatori.

Complicated/Sofisticat

Întrucât în limba română complicat este apreciat ca sinonimul lui complex, traducerea lui complicated cu sofisticat ar acoperi mai bine definiția dată de Cyenfin Framework acestui nivel de dificultate.

Cynefin Framework utilizează termenul complicated. Domeniul complicated e ceva mai puțin restrictiv decât cel simplu și permite soluții alternative la o problemă.

Acesta e domeniul cunoștințelor experte. Întrucât poți avea mai mult decât un răspuns bun la o întrebare, domeniul e de asemenea unul al Bunelor Practici. Există aici și o legătură cauzală, care este totuși destul de ascunsă vederii de multitudinea soluțiilor posibile și în mod cert nu e la fel de clară ca într-un domeniu simplu.

Pentru problemele din acest domeniu evaluăm prima dată situația și apoi ne bazăm pe experții, care trebuie să efectueze o analiză ale cărei concluzii le utilizăm pentru implementarea soluției agreate.

Această abordare e necesară deoarece nu există o soluție 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 totuși puțină analiză situațională. Un exemplu potrivit ar fi designul unei aplicații CRUD. Aceasta necesită cunoașterea câtorva frameworkuri, baze de date, etc. .Există însă o mulțime de Bune Practici încetățenite care pot fi urmate.

La acest nivel cerințele sunt destul de stabile, permițând utilizarea abordării

Domeniul complex este unul pe care am început să-l întâlnim tot mai des de ceva vreme încoace. La acest nivel primim cerințe care se modifică rapid pentru a răspunde presiunii externe. Orice modificare în specificații va duce la dezvoltarea unei funcționalități, iar implementarea sa ar putea duce la alte schimbări ale cerințelor după analiza efectului pe care îl are ea asupra bazei de utilizatori sau a altor componente ale aplicației. Acesta e domeniul designului emergent și el ne permite să discutăm 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ă câștige teren.

Suntem echipați acum pentru a face față specificațiilor 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. Întrucât abia am început să facem trecerea la ele, le înțelegem prea puțin și tindem să le considerăm doar complicate. Dovadă că lucrurile stau așa sunt încercările de a impune un document cu specificații cât mai exact, apariția unei mulțimi de reguli și regulamente care încearcă să controleze haosul aparent, frustrarea produsă de neînțelegerea modului în care se așteaptă să evolueze sistemele și lipsa controlului asupra mersului lucrurilor. În ciuda tuturor celor de mai sus, sistemele complexe cer experimentări și explorări, pe care trebuie să le includem în planurile noastre pentru a obține rezultatele dorite. În domeniile complexe trebuie să încurajezi experimentarea și explorarea.

Aceasta înseamnă că trebuie să setezi proiectul, aplicația și procesele astfel încât ele să permită eșecuri multiple ieftine în încercarea de a obține rezultatul dorit.

La acest stadiu e vorba despre lansarea unui experiment și evaluarea rezultatelor post-experiment, urmate de integrarea soluției în aplicație în cazul unor rezultate

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

25

programare Diminuarea complexității cu TDD și Agile satisfăcătoare.

Pentru a obține rezultatele dorite trebuie să: • Încurajezi comunicarea în echipă. în acest fel se va putea folosi experiența colectivă în rezolvarea problemelor.

• Creezi bariere. Trebuie stabilit un sistem de constrângeri în interiorul căruia sistemul poate evolua. Cunoașterea acestor constrângeri clarifică ceea ce poate fi modificat și schimbat, ajutând în același timp la diminuarea frustrării generate de ritmul alert al schimbărilor.

• Refolosești soluții. Se încearcă găsirea unor soluții bune, comune mai multor probleme și refolosirea lor în interiorul sistemului. Identificarea acestor soluții oferă o structură mai clară și un set nou de constrângeri pentru problemă, ajutând la mutarea problemei dintr-un context complex într-unul complicat.

Haotic

Domeniul haotic este cel al circumstanțelor excepționale. El apare destul de rar și poate fi deosebit de periculos pentru aplicația și afacerea ta. Haosul ar putea fi cauzat, printre altele, de o eroare mare în modulul de securitate apărută în sistemul tău aflat în funcțiune.

Prima măsură pe care trebuie s-o iei în astfel de circumstanțe este să controlezi daunele. Aceasta înseamnă să închizi serverele, să deconectezi cablurile de rețea, să-ți chemi avocații și orice altceva poate minimiza impactul incidentului.

Ca follow-up la trecerea pe context haotic, presupunând că firma supraviețuiește, pot urma fără rezistență îmbunătățirile proceselor și inovarea, întrucât toată lumea e predispusă în astfel de momente să accepte ușor schimbarea pentru a preveni repetarea unor asemenea evenimente.

Evoluția 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ă măsură de cele complexe.

Metodologia preferată atunci era întrucâtva similară celei Waterfall, care începea să-și arate limitele în contextul creșterii complexității software-ului dezvoltat (presupunând ca a funcționat 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, conducând 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, întrucât toate lumea își vede de treabă, cu rezultate acceptabile, în conformitate cu specificațiile. Problemele apar doar la ora deadline-ului, când se constată ca softul nu e exact cel visat de client și fiecare își găsește o scuză. Procesul Waterfall este confortabil tocmai pentru că nu permite tragerea la răspundere. Nimeni nu răspunde pentru propriile greșeli. Î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ă puțin mai stresantă din partea clientului, dar echipele au fost în măsură să se adapteze mult mai rapid la modificările cerințelor.

Succesul inițial avut cu Agile a condus uneori la delăsare ș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

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

complicate este într-adevăr așa, pentru că în aceste contexte ne putem baza pe cerințe care evoluează încet și conexiuni cauzăefect întrucâtva clare.

Această delăsare a creat un context ce a transformat Agile într-un set de Bune Practici, ducând la relaxarea tuturor sub impresia că înțelegeau Agile. Trebuie doar să ai ‘stand ups’ și retrospectiva sprint-ului și putem uita totul despre forțele care au dus la apariția Agile.

Incidental, același lucru s-a întâmplat cu TDD. Datorită naturii simple sau complicate a proiectelor, TDD a fost redus la cerința de a avea un set de teste ‘unit’ pentru a obține un grad acceptabil de certitudine cu privire la corectitudinea codului tău. Şi a devenit chiar ușor. Trebuie să ai doar (aproape) 100% acoperire. Nu e nevoie să te gândești prea mult la cum structurezi codul de producție sau testare.

Această abordare părea profesională și totul era bine și frumos în lume, până când a intervenit schimbarea…

Nu mai suntem în Kansas

Puteți vedea această schimbare deoarece multe persoane au început să afirme că metoda Agile și TDD și toate acele practici mărunte și drăguțe care ne-au făcut să ne simțim foarte profesionali au început să nu mai funcționeze. Ce se întâmplă?

A apărut 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 înțelegere clară a modelului complexității din spatele nevoilor noastre și presupunând că dacă am face ‘mai mult’ din lucrurile pe care le-am făcut pentru rezolvarea problemelor complicate, ar putea funcționa. Dar așa ceva nu avea cum să funcționeze.

Problemele complexe au natură diferită față de problemele din sfera complicated datorită schimbării în lanțul cauzalității.

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. Eșuezi un

TODAY SOFTWARE MAGAZINE proiect și înveți lecția, stabilești un cod de bune practici care să prevină același lanț cauzal și încerci din nou. Din păcate, natura problemelor complexe nu garantează sub nici o formă că o astfel de abordare ar funcționa, creând o frustrare nemărginită. Î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 puțin instituționalizată, dacă forțele datorită cărora ele funcționează ar fi fost înțelese.

De ce nu mai funcționează practicile TDD?

Să analizăm care este principala problemă pe care oamenii o au cu practica TDD. Dacă aveți o acoperire completă, folosind unit tests ale softului, atunci schimbarea comportamentului softului va determina eșuarea testelor. Câte vor eșua? Depinde de schimbare și de numărul de teste pe care le-ai scris. Rețineți 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ă deși aceste teste trebuie văzute mai mult ca un mijloc de descurajare a schimbării decât ca o verificare a corectitudinii.

Atunci când 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 eșecul să fie ieftine. De ce ar folosi cineva unit tests? Singurul răspuns plauzibil este acela că din cauza celor mai bune practici, care nu se aplică evident domeniilor complexe.

TDD nu a fost inițial despre unit tests.

Accentul, în special pentru un software nou, a fost pus pe testare funcțională (care din punctul meu de vedere este testare funcțională). Aceste teste sunt magice în sensul că ele nu testează unități de cod ci mai degrabă comportamente ale sistemului complet. Mă întreb cum ar putea funcționa acest lucru pentru probleme complexe. Crearea de teste funcționale furnizează barierele de care ai nevoie în dezvoltarea softului dintr-un domeniu complex. Testele sunt uneori denumite specificații executabile.

Testele funcționale nu împiedică schimbări la baza codului, ci mai degrabă încurajează acest aspect. Aceste teste se asigură că acest cod respectă funcționalitatea care a fost convenită până în prezent (problema schimbării frecvente a softului

a fost unul dintre obiectivele TDD, care acum pare să fi fost uitat).

Scrierea testelor înaintea implementării oferă o structură inițială (barieră) a funcțiilor pe care încerci să le implementezi. Natura imprevizibilă a ciclurilor Roșu / Verde / Refactorizare se potrivește ca o mănușă “practicilor emergente”.

Partea de Refactor a ciclului TDD este ceea ce de obicei se amână în cele mai multe echipe, prin urmare avem ’’sprinturi de consolidare’’. Aceasta este o greșeală.

Codul trebuie să fie în cea mai bună formă și extras corespunzător în componente.

Cum poți să faci experimente ieftine dacă codul tău arată ca un bol de spaghete?

Cu siguranță TDD pare că ar fi destul de potrivit pentru domeniul nostru complex. Dar nu poți trata TDD ca un regulament și să îl utilizezi ca atare și să aștepți rezultate în acest domeniu. Este necesar să lucrezi cu TDD, în același timp să fi conștient 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ă Roșu/Verde și în special etapa de Refactor.

Acesta este singurul motiv pentru care codul va fi mai ușor de scris. Nu poate rezolva niciodată toate problemele; dacă apare o schimbare arhitecturală majoră va dura un timp până va fi implementată.

Dacă este un model pentru schimbare sau când apare un model nou, codul tău îl va oglindi precis, iar implementarea experimentelor va deveni mult mai ușoară.

Ce putem spune despre practicile Agile?

De la începuturile lor, practicile Agile s-au făcut pe cod testabil și testat. Dacă folosești un proces Agile și cod netestat înseamnă că nu ești foarte Agile (vezi flaccid scrum), iar proiectul e mai degrabă nou sau se situează în domeniul simplu sau poate complicat.

Una dintre plângerile recente adresate practicilor Agile a sunat în felul următor: ‘programatorii ar trebui să scrie cod și nu să-și piardă timpul în întâlniri standup lipsite de sens’. Aceasta presupune ca aplici procesul aferent unei probleme simple sau complicate, întrucât scrierea de cod o poți face doar dacă știi ce ar trebui să facă acel cod.

Aceasta nu se întâmplă în cazul domeniului complex, care necesită eșecuri ieftine și are cerințele modificate în funcție de succesul sau eșecul diferitelor experimente. Un domeniu complex cere de

asemenea structurarea codului în părți reutilizabile. Cum poți ști că nu scrii cod pentru același tip de funcționalitate ca unul dintre membrii echipei tale în lipsa comunicării în cadrul echipei? În domenii complexe comunicarea ar trebui încurajată puternic; întâlniri zilnice de 20 de minute ale membrilor echipei optimizează procesele, ele micșorând nevoia întreruperilor repetate la intervale aleatorii pe parcursul întregii zile.

Când întâlnirile stand-up se țin doar pentru că sunt prevăzute în regulament și desconsideri problema pe care ele încearcă să o rezolve ele devin cu adevărat o pierdere de vreme.

O altă explicație a eșecului metodelor Agile în cazul domeniilor complexe o reprezintă sesiunea de planificare a sprintului în care trebuie să estimezi timpul necesar implementării unei funcționalități. Întrucât domeniile complexe cer experimentarea cu codul, estimările par întrucâtva contraintuitive (nu poți face previziuni precise despre funcționalități în acest context). Problema acestea nu cred totuși că e una relevantă în practică. Cred mai degrabă ca planificarea sprint-urilor ar trebui să creeze o imagine întrucâtva precisă a punctului actual și al celui pe care dorim să-l atingem până la următoarea întâlnire, obiectiv pe care îl îndeplinește în mod admirabil.

Concluzii

Nu ne mai putem permite să credem în magia cuvintelor sacre precum TDD și Agile. Pe măsură ce crește complexitatea software-ului, întreaga echipă de dezvoltare trebuie să înțeleagă forțele care au dus la apariția TDD și Agile și cum să le aplice în conformitate cu rolurile lor și cu o atenție 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ă aceleași tehnici.

Este acest model precis sau nu? Încă nu știm foarte bine, dar modul în care a fost el primit și utilizat indică niște corelații 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ă înveți în permanență ceva nou, preferabil ceva ce te sperie. Dacă vrei să te alături noii generații de programatori și de paradigme de programare, lasă deoparte plafonarea și începe chiar acum să înveți.

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

27

management

programare

Performanța în echipe distribuite

Ș

Tiberiu Cifor tiberiu.cifor@3pillarglobal.com Engineering Manager @ 3Pillar Global

tim cu toții 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 cunoaște principiile Agile și toată lumea îl implementează. Prin natura jobului am trecut prin multe proiecte, de la cele mai mici până la cele mai mari, de la cele mai ușoare până 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 situații am găsit foarte puține informații despre cum se poate optimiza Scrum lucrând în echipe distribuite, localizate în diferite zone de pe glob, lucrând la același proiect și încercând să aplice aceste principii ce fac din Scrum una dintre cele mai populare metodologii.

Dacă vorbim de succes, față de anii precedenți 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, aveți 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

nr. 31/2015 | www.todaysoftmag.ro

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 întâlnit situația când clientul era localizat în USA și întreaga echipă de dezvoltare era localizată în România, dar am întâlnit și cazuri mai complexe când echipa de dezvoltare era localizată în România dar și în USA, la client. Cred că este una dintre situațiile cel mai greu de gestionat. În continuare, voi prezenta avantajele și dezavantajele unei echipe distribuite. Haideți să aruncam o privire obiectivă asupra avantajelor ce le oferă o echipă distribuită. În primul rând, diferența de fus orar nu trebuie privită ca un impediment( lucru care de obicei se întâmpla) ci trebuie privită ca un avantaj.

De ce? Pentru simplul motiv că atunci când una dintre părțile echipei nu este disponibilă, cealaltă echipă este la muncă, poate să rezolve unele task-uri, eventualele probleme apărute în sistemul din producție și așa mai departe. Dacă aruncam o privire de ansamblu asupra acestei situații observăm că într-adevăr diferența de fus orar este un avantaj pentru ca asigură pe o perioadă foarte mare dintr-o zi prezența suportului. Dacă se lucrează la un proiect care deja se află în producție acest avantaj devine poate și mai important.

Educarea clientului și încrederea în echipă

aici de echipe distribuite iar în cadrul acestor echipe veți fi surprinși să vedeți că fiecare înțelege în felul său rolul pe care îl are în echipă și mai ales responsabilitățile sale. E foarte important ca într-o echipă distribuită aceste roluri și responsabilități să fie clar stabilite încă de la început. Știm foarte bine care sunt principalii jucători într-o echipă ce adoptă Scrum-ul. Dar oare aceasta situație este una ideală tot timpul? Vă spun eu, în majoritatea cazurilor am văzut oameni implicați în dezvoltarea unui produs care pur și simplu nu se regăsesc în actorii aceia cu care suntem toți obișnuiți din Scrum. Un exemplu concret: un client vine și vă spune că el are la dispoziție un Business Analyst care va dori să lucreze cu echipa în toate etapele de dezvoltare ale produsului.

Instinctiv, noi ca manageri poate am ieși la rampă și am încerca să analizăm dacă această poziție de BA se încadrează undeva sau dacă putem să găsim soluții pentru a optimiza Scrum-ul. Ba mai mult, am observat cazuri în care apăreau și anumite conflicte pentru că nu-i așa, în Scrum nu avem nici un BA. Cum se poate rezolva această situație cât mai eficient pentru toată lumea ? De obicei, propunerile mele merg în direcția î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 puțin asupra rolurilor și responsabilităților. De cele mai multe ori, în echipele distribuite, și mai ales acolo unde sunt indivizi implicați în tot procesul de development , pot apărea anumite conflicte atât de la client cât și de la dezvoltator. E oarecum firesc ca unii clienți să încerce să pună în anumite poziții cheie oameni de la ei, oameni care vor dori să dețină controlul la ce se implementează, oameni care vor dori să controleze procesul de dezvoltare. Bineînțeles, din nou apar conflicte. Nu e un lucru rău ca unii clienți să dorească să participe efectiv la dezvoltarea produsului lor, dar trebuie să încercam să abordam aceste probleme directe cu ei și să-i determinăm să înțeleagă că noi în calitate de parteneri ai lor avem mai multă experiență în dezvoltarea unui produs.

Pentru a evita aceste situații neplăcute e foarte important să se precizeze care sunt rolurile și responsabilitățile tuturor oamenilor implicați în acest proces. Cine e responsabil cu adăugarea de Roluri și responsabilități noi task-uri în backlog? Cine trebuie să faciliteze comunicarea în Am întâlnit de-a lungul timpului diferite forme prin care cadrul echipei? Cine este responsabil pentru a conduce discuțiile o echipă funcționa și aici mă refer strict la rolurile și mai ales tehnice? etc. responsabilitățile fiecărui membru din echipă. Nu uitați, vorbim Odată stabilite aceste roluri și responsabilități sunt șanse De obicei pe mai toate proiectele se lucrează cu Scrum sau mai nou cu Kanban. Până aici toate bune și frumoase. Dar v-ați întrebat vreodată cât de bine cunoaște 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 rând unii din clienții cu care lucram nu cunosc foarte bine ce înseamnă Scrum, care sunt principiile de bază și cum anume se aplică. Ba mai mult, dacă lucrăm cu o organizație destul de mare, acolo vom observa că sunt alte roluri și responsabilități. Sigur v-ați lovit de clienții aceia care au manageri de proiect sau care au așa- numiții 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 toți indivizii implicați în proiect.

Mai mult, recomandarea mea este să se definitiveze și o scurta listă de responsabilități pentru fiecare din aceste roluri. Aceste responsabilități vor face puțină lumină și vor nivela unele conexiuni în cadrul echipei astfel încât fiecare dintre oamenii implicați pe proiect vor ști ce au de făcut. Am stabilit că e foarte important să se definitiveze rolurile și responsabilitățile pe proiect, dar ce facem când ne lovim de unii clienți reticenți, care sunt foarte greu de convins asupra acestor aspecte? Răspunsul la aceasta întrebare se reduce la un singur lucru: ÎNCREDERE. În acest punct foarte important, când 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 creșterea încrederii.

E foarte dificil să creștem î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 offerings are business focused, they drive real, tangible value.

www.3pillarglobal.com

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

29

management Performanța î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 veți avea un client fericit. poate ajuta cineva de la client, sau cineva din altă locație, atunci apelează direct la el. Mai mult, încurajați folosirea comunicării Comunicare eficientă directe dacă e posibil, adică telefon, skype sau orice alt mijloc Mulți dintre voi poate vă întrebați câteodată cum putem de apelare directă. E-mail-ul să vina ca ultima soluție. Veți fi să comunicăm mai eficient în cadrul echipei și nu numai. surprinși de rezultatele ce pot apărea 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 același loc, comunicarea vine de la sine, aici în cadrul unei echipe aceste lucruri duc la o comunicare eficientă. Dacă înțelegem puțin distribuite nu mai e așa ușor și trebuie să fim atenți cum putem aceste concepte vom putea să gestionăm mai ușor situații oarerupe acele bariere care se vor ridica vrând-nevrând de-a lungul cum mai tensionate, sau cel puțin vom reuși să aducem mai multă dezvoltării 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 eficienți. O comunicare eficientă mod normal, dacă echipa ar fi într-un singur loc un information implică o comunicare și o abordare cât mai directă prin care radiator poate fi un board din birou vizibil pentru toată lumea. încercăm să rezolvăm orice situație apărută într-un timp cât mai Cum arată acest board când lucrăm î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-ați întâlnit cu situații în care ați simțit pe pie- de rapoarte care sunt generate automat de acel instrument fololea voastră sau ați auzit de la alții, cum că “pierdem prea mult sit de echipă pentru a măsura progresul, de exemplu JIRA. În timpul în conferințe și meeting-uri cu clientul”. În momentul în acest caz, information radiators pot fi: burn down chart, burn up care auziți așa ceva, să știți că cel mai probabil aveți 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 ședințe prin rotație? Am eficientizat un a vedea progresul unui sprint, de exemplu. Mai mult, știți foarte pic? Eu zic că da. Sau de ce să nu avem în fiecare sprint, un om din bine întrebările de genul “cum stăm cu sprintul asta?” sau “sunechipă responsabil cu un asemenea task, acela de a lămuri unele tem on track cu sprintul?”. Răspunsul la aceste întrebări îl poate din requirement-uri. Situațiile pot continua. Ideea este că putem obține oricine, dacă se va uita la unul din aceste rapoarte, care fi eficienți doar prin mici ajustări. sunt sugestiv reprezentate grafic.

Mai mult, înaintea unui release major sau a unui deadline important încercați să adunați toată echipa într-un singur loc. Ce poate fi mai eficient decât să ai toată echipa în același loc să poată comunica față în față? De multe ori e destul de greu să facem acest lucru, mai ales când vorbim de echipe mari. Știm foarte bine că mai sunt și anumite constrângeri de bugete. Acolo unde este posibil vă recomand din toată inima să încercați să adunați echipa într-un singur loc.

Dacă nu este posibil să adunăm întreaga echipă într-o singură locație, încercați în toate conferințele ce le aveți online cu restul membrilor să vă porniți camerele web. Uneori ajută foarte mult să-ți vezi interlocutorul, să observi mimica și expresia fetei persoanei cu care vorbești. Prin acest lucru discuțiile devin mai amicale, mai deschise și cu siguranță o să observați ca devin și Exemplu de Burn down chart: mai eficiente.

Vreau să mai fac o sugestie: încurajați toată lumea din echipă să abordeze direct o persoană care o poate ajuta. Facilitați

Exemplu de Burn up chart:

Sursa: http://www.agilemodeling.com/essays/communication.htm

30

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

Menționam mai sus de “Active listening”. În echipele distribuite acest concept joacă un rol consistent. În mod normal când ascultăm 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 discuție în mod activ, adică toată lumea trebuie să furnizeze întrebări și răspunsuri respectând niște reguli.

Vorbim aici de trei nivele când vine vorba de Active listening: • Internal Listening - participanții sunt doar atenți, și de obicei se întreabă dacă ce se discută îi afectează.

• Focused Listening - participanții arată că sunt interesați de discuție și încearcă să se pună în postura celui care vorbește.

• Global Listening - participanții arată implicare, pun întrebări, critică unele raționamente, sunt respectuoși și arată toate aceste lucruri de obicei prin gesturi și emoții.

TODAY SOFTWARE MAGAZINE În concluzie

Așadar, acest subiect este unul foarte vast și necesită poate multe dezbateri. În acest articol am punctat doar câteva dintre problemele reale cu care poate mulți din voi se confruntă atunci când lucrați în echipe distribuite. Ultimii ani ne-au dovedit că din ce în ce mai multe companii optează pentru echipe cu membri plasați în diferite colțuri ale lumii, din diferite considerente. Acest lucru reprezintă o provocare atât pentru manageri cât și pentru echipa în sine. Felul în care reușesc oamenii să interacționeze, să depășească 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ă mișcare, influențând mecanismele ce În ceea ce privește 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, înțelegere față de interlocutor și pe argumente valide care să stârnească atenția celui cu care discutați pe un anumit topic.

Esențial este ca în calitate de manageri să vă integrați în echipă pentru a nu fi priviți doar ca niște șefi. În acest fel veți contribui mai mult la o comunicare deschisă și mai ales eficientă.

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

31

programare

Cinci sfaturi practice pentru Code Review în Scrum

Î

n fiecare săptămână, la Mozaic Works, în echipa de dezvoltare de produse, descoperim 2 - 3 buguri în produsul la care lucrăm în timpul sesiunii de Code Review. Acest lucru se întâmplă în ciuda faptului că lucrăm într-un mod foarte structurat și aplicăm ATDD și Test First/TDD. Mai mult, dezvoltatorii și liderii tehnici se plâng 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: Discutați guideline-urile cosmetice doar o singură dată

Există două tipuri principale de guideline-uri: • Cosmetice: indentation, spaces vs. tabs, naming policies, curly braces, positioning etc. ; • Tehnice: cum să scrii cod ca să eviți greșelile commune.

Programatorii vor dezbate Guidelineurile Cosmetice ore în șir. Dovada este pe google, dar nu aș căuta „tabs vs. spaces debate” dacă aș avea multe de făcut.

Așadar, Guideline-urile Cosmetice ar trebui să fie discutate o singură dată și introduse în setările IDE. Ne putem obișnui cu scrierea de acolade pe următoarea linie după numele funcției; nu merită să purtăm o dezbatere pe această temă . Însă consistența codului este cea mai importantă și fiecare echipă Scrum trebuie să lucreze după Guideline-uri Cosmetice comune.

Sfatul #2: Pornește cu un număr 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 întâlnite atunci când lucram ca junior developer. Liderii tehnici obișnuiau să copieze principiile Microsoft sau să îi îndrepte pe dezvoltatori către acestea. Deși 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

nr. 31/2015 | www.todaysoftmag.ro

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 ușura testarea automată”), performanță (ex. “folosiți un profiler pentru a măsura timpul de execuție pentru toate query-urile din modulul de raportare”) etc. . Acestea sunt primele guideline-uri: specifice, contextuale și care ajută la evitarea greșelilor comune. Iar aceasta ne duce la ..

Sfatul #3: Îmbunătățește guideline-urile în funcție de greșelile din trecut

Ne aminteam de vremurile în care liderul de echipă ne dădea în prima zi a unui proiect să citim un document de guideline-uri de 20 de pagini. Citirea acestuia consuma mult timp și nu rețineam aproape nimic. Când am ajuns lider tehnic, am decis să îmbunătățesc abordarea. Iată cum: Principiile tehnice sunt în general bazate pe “best practices”; problema cu best practices este că nu toate best practices pot fi aplicate pe toate produsele. Așa că prefer denumirea de “reguli care ajută la evitarea greșelilor comune”. Cum știm care sunt greșelile comune? Simplu, trebuie întâi să le facem. Unii dintre voi probabil vă veți încrunta, dar dacă ești onest cu tine însuți vei realiza că faci destule greșeli. Eu fac destule greșeli, însă am sprijinul colegilor în a fi onest cu mine însumi. Cum ar fi să te bucuri de avantajul greșelilor pe care le faci?

Iată cum funcționează acest ciclu

programare virtuos: Scrie coding guidelines -> Fă code rev iew -> Analizează greș elile -> Îmbunătățește coding guidelines.

Sfatul #4: Folosește diferite tipuri de Code Review

În echipele cu care am lucrat am întâlnit trei tipuri dominante de revizuire de cod: over-the-shoulder, folosind un tool și pair programming. Fiecare are atât avantaje cât și dezavantaje și de aceea se merită să le combinăm.

Scopul revizuirilor de cod este să evităm greșelile sau așa cum le numim în industrie, bug-urile. Un efect secundar ar fi să învățăm citind și discutând codul altcuiva. Prima dificultate cu revizuirea codului în Scrum este să construim disciplina. Dacă ai început de curând să faci code review în Scrum, trebuie să stabilești clar când o să îl faci. Ca de exemplu: o dată pe săptămână sau când un user story este gata. Odată ce ai creat obiceiul de a face code review în Scrum, strategiile pot varia.

De exemplu, la un program foarte complicat, am ajuns să folosesc următoarele tipuri de code review: • Over the shoulder - eu merg câteodată lângă colega mea Claudia și mă uit la codul pe care îl scrie. Și ea face la fel; de fapt, nu îmi este niciodată rușine să îi cer ajutorul când lucrez la un task.

• Programat - în fiecare săptămână, avem o sesiune de o oră de revizuire de cod.

• Pair Programming - când avem un task mai complicat sau ne decidem să încercăm un mod nou de a face lucrurile.

• Ocazional - cam o dată pe lună, mă uit la întâmplare la parți din cod pentru a vedea dacă nu cumva ar fi existat moduri mai bune în care ar fi putut fi scris.

TODAY SOFTWARE MAGAZINE experimentat colegul. Revizuiește conPentru revizuiri de cod în Scrum mai form cu coding guidelines dar și pentru folositoare, urmează aceste reguli: lizibilitate, simplitate, ușurința de schim• Discută guideline-urile cosmetice bare și securitate. Notează-ți problemele doar o dată, și introdu-le în setările IDE. 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ă analizați • Execută revizuiri de cod și notează împreună o parte din codul scris în problemele găsite. timpul sprint-ului. Dă mai departe • Analizează problemele la retrospecrezultatele revizuirii către Scrum Master. tive și îmbunătățește guideline-urile în • Cel puțin o dată la 4 sprint-uri pune funcție de greșelile trecute. un dezvoltator mai experimentat să se • Folosește strategii diferite pentru uite la părți aleatorii ale codului pentru revizuirea codului: Over the shoulder, 30-60’. Concluziile ar trebui să meargă pair programming, planificate, întâmplă(nici o surpriza aici) la Scrum Master. toare, printr-o aplicație specializată.

• Discutați constatările la retrospec• Ai încredere în colegii tăi! tivă. Scrum Master-ul ar trebui să decidă un program, în funcție de numărul 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 tăi

Persoanele care erau lideri tehnici înaintea tranziției la Scrum tind să devină gatekeeper-i. O greșeală tipică este că vor să facă toate revizuirile de cod în Scrum pentru a asigura o calitate înaltă.

Deși 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 curând.

Dezvoltatorii din echipă vor fi slab motivați să își asume responsabilitatea pentru codul pe care îl scriu dacă știu că cineva îl păzește. De asemenea, liderul tehnic riscă să se separe de echipă pentru că el este evident deasupra celorlalți colegi. Încercați să întoarceți lucrurile pe dos și veți obține o echipă funcțională, productivă care învață împreună. Un fost lider tehnic îndrumă și ajută toată lumea să crească prin pair programming, ajutându-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 abilitățile și timpul lor, dezvoltatorii seniori cu soluții inteligente și liderii tehnici cu creșterea fiecărui membru din echipă. Încrederea în colegii tăi va duce echipa la un mod de lucru mult mai eficient.

Noi nu folosim un tool pentru code review. Ne uităm la cod, discutăm, decidem ce îmbunătățiri am putea aduce și le aplicăm cât mai repede cu putință. Cum procedezi într-o echipă mai mare?

Propunem următoarea strategie pentru cei ce revizuiesc cod în Scrum: • Pair programming pe user stories complexe. În cazul în care story-ul a fost complet dezvoltat folosind pair programming, considerăm că este deja revizuit.

• Când un story este gata, revizuiește-l cu un coleg. Nu este necesar să fie mai Sumar

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

33

programare

programare

Convergența documentației într-un proiect software multimodular: o abordare bazată pe Build Automation

D

ocumentele explicative ale produselor software sunt folosite ca manuale de referință pentru proiectanții interfețelor utilizator, pentru programatorii care scriu codul și pentru testerii care se asigură că produsul funcționează corect. Într-o aplicație multimodulară, fiecare componentă este dezvoltată și lansată independent. Păstrarea documentației actualizate pentru fiecare componentă nu este ușoară deoarece nu totul ține doar de redactarea ei, ci și de centralizarea tuturor documentelor în așa fel încât să fie găsite ușor de către persoanele interesate.

Context Alexandru Albu

alexandru.albu@isdc.eu Senior Developer @ ISDC

S copul ar ticolului de față este prezentarea unei abordări pentru simplificarea acestui proces, bazându-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 conține unul sau multe documente scrise în Markdown 4.

Documentele sunt scrise de către programatori, iar acestea pot fi readme-uri5, howto-uri, documentații tehnice6 și altele.

Ce vrem să obținem?

Înainte să începem, va trebui să ne imaginăm cum va arăta soluția finală. Ne dorim o pagină html frontală care să afișeze cele mai recente documente scrise de către 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ă obișnuită.

Ele însoțesc produsul, iar cu ajutorul lor, consumatorii produsului îl pot folosi și înțelege corect.

Prin lansarea artifactelor Maven, fișierele compilate ajung într-un depozit (Repository) de cod structurat. În acest depozit pot ajunge nu doar fișierele compilate, ci și JavaDoc-ul, codul sursă sau un întreg website ce prezintă informații despre dependențele proiectului, informații 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 legăturile spre website-urile fiecărui modul într-o singură pagină html.

Imaginați-vă că pagina html arată în felul următor: <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

nr. 31/2015 | www.todaysoftmag.ro

Acest model presupune prezența fișierelor 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

TODAY SOFTWARE MAGAZINE ![Alternative text] (images/image1.jpg „Text descriptiv”)

După ce website—ul este generat, ne așteptăm să găsim fișierele noastre în directorul target astfel: • [target] • [site] • Readme.html • ReleaseNotes.html • [images] • image1.jpg • image2.jpg

Modulele noastre sunt artifacte Maven, iar abordarea este Cele două fișiere html ar trebui să fie referite în cadrul fișierelor bazată pe Maven Build Lifecycle7. html generate de către plugin. Pentru a realiza acest lucru, avem nevoie să-i comunicăm lui Maven următoarele instrucțiuni: Generarea site-ului unui modul 1. Înainte de a genera website-ul, copiați toate fișierele *.md Generăm site-ul folosind maven-site-plugin8. Folosind doar din src/site/resources în src/site/markdown. Atenție, directorul acest plugin putem genera elementele implicite, cum sunt Project nou poate fi inexistent.

Summary, Project Plugins, Dependencies și altele.

2. Generați website-ul pentru proiect, dar în rezultatul final Cu puțină configurare și ajutor, putem interveni în fluxul noreste de preferat să existe referințe către documentele genemal al plugin-ului. În acest mod putem include fișierele noastre rate pe baza fișierelor Markdown. Avem un fișier Readme.

Markdown ca fișiere html, referite din website-ul generat. md și unul ReleaseNotes.md, deci ar trebui să facă referire la Ca să transformăm fișierele Markdown în html, avem nevoie fișierele Readme.html și ReleaseNotes.html. de doxia-module-markdown ca dependență pentru acest plugin.

3. După ce ați terminat de generat, ștergeți directorul src/ Folosind acesta, procesul de generare al website-ului se uită în site/markdown. Codul trebuie să rămână curat, fără fișiere interiorul directorului src/site/markdown și convertește fiecare duplicate. fișier cu extensia .md într-un fișier html. Începem cu cel de-al doilea punct, prin descrierea referințelor Această etapă poate părea simplă, dar dacă fișierele noastre spre viitoarele fișiere html în cadrul src/site/site.xml: *.md conțin imagini, acestea sunt pur și simplu trecute cu vederea <?xml version=”1.0” encoding=”UTF-8”?> de către plugin. Acest plugin doar copiază conținutul 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 fișierele 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 putând oricând xsd/decoration-1.4.0.xsd DECORATION/1.4.0 „> arunca o privire peste ele. Referirea imaginilor din directorul temă, reclame și alte configurări ale site-ului src/site/resources va funcționa doar în modul offline, deoarece <!---> în urma generării website-ului directorul resources nu va mai fi prezent, iar astfel vom avea parte de referințe defecte către imagini. <body> <!—- meniu pentru documentele programatorilor --> Ideal ar fi să avem toate fișierele Markdown în directorul src/ <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 din images (ca director relativ) deoarece </menu> după generarea website-ului conținutul directorului images este <!-- meniu pentru javadoc, jxr, și altele --> contopit cu celelalte imagini pe care plugin-ul le generează în <menu ref=”reports”/> </body> directorul target/site/images. În concluzie, directorul src al unui modul are următoarea </project> structură: Plugin-ul citește aceste instrucțiuni și generează website-ul în • [src] concordanță. Am adăugat un nou meniu ce referă documentele • [main] – codul sursă noastre.

• [site] Primul și ultimul punct implică manipulare de fișiere, iar • site.xml acest lucru este o sarcină perfectă pentru un task Ant. În Maven • [resources] putem folosi maven-antrun-plugin pe care îl configurăm să exe• Readme.md cute două sarcini: • ReleaseNotes.md • prima execuție creează directorul src/site/markdown și • [images] copiază toate fișierele *.md în interiorul lui. Acest lucru trebuie • image1.jpg făcut înainte de începerea procesului de generare, deci în faza • image2.jpg de pre-site; • cea de-a doua execuție șterge directorul src/site/markdown, În interiorul fișierului Readme.md găsim referințele spre iar acest lucru trebuie făcut 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 fișierul pom.xml rezultat: <project .. >

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

35

programare Convergența documentației într-un proiect software multimodular <dependencies> ... </dependencies> <build> <!—- pregătește fișierele 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}/ src/site/markdown” /> <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}/ src/site/markdown” /> </tasks> </configuration> <goals> <goal>run</goal> </goals> </execution> </executions> </plugin> <!—generatorul de site e legat de sectiunea de raportare --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-site-plugin</artifactId> <version>3.3</version> <dependencies> <dependency> <groupId>org.apache.maven.doxia</groupId> <artifactId>doxia-module-markdown </artifactId> <version>1.5</version> </dependency> </dependencies> </plugin> </build> <reporting> <outputDirectory>${project.build.directory}/site</outputDirectory> <!—configurare pentru alte lucruri legate de

36

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

raportare, cum sunt plugin --> </reporting> </project>

maven-javadoc-plugin, maven-jxr-

Cu ajutorul comenzii mvn site website-ul dorit va fi generat în directorul target/site.

Deploy-ul site-ului unui modul

Următoarea fază în atingerea scopului nostru este să împachetăm website-ul generat într-un fișier jar care să fie încărcat în Maven Repository.

Plugin-ul site știe cum să creeze un fișier jar pe baza fișierelor din directorul target/site. Tot ce trebuie să facem este să apelăm mvn site:jar, dar cu o singură remarcă: faza pre-site este executată doar dacă apelăm mvn site, fără scopul :jar. Pentru a fi siguri că fișierele Markdown sunt luate în considerare chiar și când directorul target este gol sau inexistent, ar trebui să apelăm mvn site site:jar.

Rezultatul este un fișier jar nou, target/module1-site.jar. Ca să putem considera acest pas complet, mai trebuie să încărcăm acest fișier 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 lângă documentațiile modulelor, el poate ține și documente generale, cum ar fi primii pași ai programatorilor care intră pe proiect sau documentații tehnice de ansamblu. Pentru acestea, maven-site-plugin poate fi aplicat folosind aceeași manieră ca și în cazul modulelor.

Pentru a descărca website-urile generate folosim Maven Dependency Plugin10. Acesta ne ajută să obținem artifactele și fișierele *-site.jar încărcate la pasul anterior. Scopul nostru aici este să dezarhivăm toate aceste fișiere în interiorul directorului target/site/modules, iar astfel putem menține structura dorită pentru website.

Pentru a obține arhivele *-site pentru module, toate trebuie declarate ca dependențe ale proiectului resurselor în fișierul pom. xml: <project .. > <dependencies> <!-- module 1 --> <!-- module 2 --> <!-...

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

TODAY SOFTWARE MAGAZINE <!-- antrun pentru a genera html suplimentar din markdown --> <!-- (!)

--> <!-- groovy plugin pentru a executa operții de intrare/ieșire pe disc, explicate în secțiunile --> <!-- (!)

--> <!-- site plugin pentru a genera site-ul proiectului actual --> <plugin> <groupId>org.apache.maven.plugins</groupId> <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 conținutul fiecărui website de modul într-un subdirector separat din cadrul target/site/modules al proiectului resurselor.

Ultima chestiune importantă aici este proiectarea fișierului index.html în așa fel încât el va conține referințe către toate sub-site-urile modulelor. Pentru că modulele noastre sunt versionate, vrem ca proiectul resurselor să-și dea seama singur de căile către sub-site-uri. Dacă facem pagina de index dinamică, putem adăuga foarte ușor un script care populează pagina cu conținutul corespunzător, prin declararea unui vector într-un fișier .js separat, 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> <a href=”modules/module2-1.5-site-jar/ ReleaseNotes.html”>Release Notes</a> </div>

Fișierul nostru modules.js este 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/modules și imprimă numele lor în fișierul /site/config/modules.js, iar în acest fel noi obținem vectorul de căi spre module. Codul poate fi citit mai jos: ... <plugin>

<!—imprimă în config/modules.js numele directoarelor corespunzătoare --> <groupId>org.codehaus.mojo</groupId> <artifactId>groovy-maven-plugin</artifactId> <version>1.5</version> <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:jar în cadrul proiectului resurselor obținem arhiva website-ului dorit. Această arhivă poate fi mai apoi încărcată într-un Server Web HTTP și făcută accesibilă tuturor celor interesați.

Concluzii

Având toate modulele configurate și proiectul resurselor creat, toate comenzile mvn pot fi apelate cu ușurință de către Jenkins CI, iar website-ul final poate fi încărcat pe un Server Web HTTP ca pas post build. De fiecare dată când un modul Codul JavaScript poate utiliza vectorul modules și introduce este lansat, sub-website-ul lui este publicat, iar website-ul princiurmătoarele elemente DOM în pagina index: pal poate fi regenerat. În acest fel ne asigurăm că documentațiile cele mai recente sunt disponibile programatorilor, fără a fi nevoie <div> <h1>module1</h1> de niciun efort sau intervenție suplimentară. Toate acestea sunt <h2>Version 1.3-SNAPSHOT</h2> făcute în spiritul integrării continue. <a href=”modules/module1-1.3-SNAPSHOT-site-jar/ index.html”>About</a> <a href=”modules/module1-1.3-SNAPSHOT-site-jar/ Readme.html”>Readme</a> <a href=”modules/module1-1.3-SNAPSHOT-site-jar/ ReleaseNotes.html”>Release Notes</a> </div> <div> <h1>module2</h1> <h2>Version 1.5</h2> <a href=”modules/module2-1.5-site-jar/

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

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 inteligenței artificiale. Odată cu creșterea numărului 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ă, soluția fiind procesarea lor într-un sistem distribuit.

Cristian Raț

Cristian.Rat@Yardi.Com Software Developer @ Yardi

38

nr. 31/2015 | www.todaysoftmag.ro

Clasificarea este un proces de luare a unei decizii pe baza exemplelor unor decizii corecte, prin urmare este o tehnică de învățare 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ă apartenența 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 același indiferent de algoritmul de clasificare folosit, și este alcătuit din mai multe faze: procesarea datelor, training, testare și ajustare, validare (testare finală), livrare în producție.

Clasificarea textului este de fapt asocierea dintre un text și o categorie de text predefinită. Fiecare cuvânt care apare în document este considerat un atribut al documentului, astfel pentru fiecare document se construiește un vector de atribute, conținând cuvintele din text. Pentru a îmbunătăți 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 dezvoltați mai mulți algoritmi prin care se poate rezolva această problemă de clasificare: Naive Bayes, arbori de decizie, rețele neuronale, regresii logistice ș.a..

Unul dintre cei mai folosiți algoritmi pentru clasificarea textului este Naive Bayes. Naive Bayes este un algoritm de

clasificare probabilistic, deciziile luate de acesta fiind bazate pe probabilități derivate din setul de date preclasificat. În procesul de training sunt analizate relațiile 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ă aparțină unei anumite categorii.

Conform teoriei lui Bayes, probabilitatea ca un eveniment A să apară ținând cont că alt eveniment B a apărut este egală cu probabilitatea că evenimentul B să apară ținând cont că evenimentul A a apărut, înmulțit cu probabilitatea că evenimentul A să apară raportat la probabilitatea apariției evenimentului B.

Astfel aplicat la problema noastră, probabilitatea ca un document să aparțină unei categorii C ținând cont că are în componența vectorul de cuvinte X=(x1, x2, …, xn) este următoarea:

Această formulă este foarte greu de calculat și necesită o putere computațională foarte mare, pentru simplificarea problemei, algoritmul Naive Bayes presupune ca atributele din vectorul X sunt independente (de aici algoritmul își ia numele de

TODAY SOFTWARE MAGAZINE “naiv”), astfel formula devine:

Transformarea textului în vectori de atribute se face cu ajutorul comenzii seq2sparse care creează un fișier 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 număr 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ă. Soluția este procesarea distribuită.

Hadoop este un program care permite procesarea datelor în mod distribuit. Acesta vine cu un sistem de fișiere distribuit pentru stocarea datelor. Hadoop poate scala până la câteva mii de calculatoare, ceea ce ar trebui să fie suficient pentru a rezolva orice problemă de clasificare.

Mahout este o librărie ce conține algoritmi scalabili de clusterizare, clasificare, sau filtrare colaborativă. O mare parte din acești algoritmi implementează paradigma map-reduce și rulează în mod distribuit utilizând Hadoop. Viteza de procesare a algoritmilor din această librărie este diminuată comparativ cu alte alternative atunci când 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 când dimensiunea datelor este foarte mare (mai mult de 1milion de documente folosite pentru training).

Pentru a facilita utilizarea algoritmilor, Mahout pune la dispoziție 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 fișier care conține perechi cheie-valoare și este folosit în programele care implementează paradigma map-reduce.

Pentru a transforma datele noastre într-un SequenceFile folosim comanda seqdirectory:

Împărțirea datelor în date de test și date de training este la fel de ușoară precum pașii anteriori, împărțirea este aleatorie putându-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ă utilizând comenzile următoare: 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 testării pot fi acum evaluate, și dacă e necesar, pentru a obține un rezultat mai bun se pot modifica datele inițiale și se poate repeta procesul, până când acuratețea clasificării este satisfăcătoare.

Clasificarea textului poate avea multe aplicații, dar acum dimensiunea datelor nu mai este o limitare. Hadoop și Mahout pun la dispoziție instrumentele necesare creării unui proces de clasificare care să lucreze cu un număr 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

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

39

programare

programare

Internet of Things în universul Java

E

xperții din domeniul IT au numit 2014 „anul Internet of Things”, acesta fiind unul dintre cele mai fierbinți subiecte ale anului care tocmai s-a încheiat. Titlul atribuit nu este deloc surprinzător dacă luăm în considerare faptul că site-uri importante precum dzone.com, jaxenter.com sau oracle.com au publicat câteva articole pe săptămână despre tehnologiile din sfera Internet of Things, iar blogger-ii nu au scăpat 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 așteptând să vadă lumina tiparului anul acesta.

Toate acestea s-au întâmplat în contextul lansării unei multitudini de noi gadgeturi sau dispozitive inteligente, dar și a numeroase platforme software sau implementări ale unor protocoale mai mult sau mai puțin cunoscute. Mulți împătimiți ai tehnologiei au auzit de produse populare, lansate în ultimii ani, precum Philips Hue sau Nest, însă începând cu 2014 e nevoie de un efort activ să putem ține pasul cu frecvența apariției de noi dispozitive, cum ar fi Sen.se Mother, Fitbit Charge sau SkyBell. IoT influențează din ce în ce mai mult domeniile din viața de zi cu zi, precum sănătatea cu dispozitive care monitorizează pacienții, îngrijire la domiciliu, prin gadgeturi pentru un stil de viață sănătos, transporturi, cu autovehicule conectate, automatizarea locuințelor, industrie etc. . Înainte de a discuta despre modalitățile 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.

Definiții

Internet of Things sau, pe scurt, IoT este un concept dezbătut din ce în ce mai mult în ultimii ani, dar semnificația sintagmei nu este întotdeauna pe deplin înțeleasă.

CASAGRAS (Coordination and support action for global RFID-related activities and standardisation) ne dă o definiție destul de abstractă, care spune despre IoT următoarele: este „o infrastructură de rețea

40

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

globală, care conectează obiectele fizice și virtuale prin intermediul exploatării capturii de date și a capacității de comunicare.

Această infrastructură include dezvoltările existente și viitoare ale rețelelor și ale Internet-ului. Aceasta va pune la dispoziție modalități de identificare a obiectelor, senzori și capacitatea de conectare ca bază pentru dezvoltarea de servicii sau aplicații independente și cooperante. Acestea vor fi caracterizate printr-un grad înalt de autonomie pentru captura de date, transferul evenimentelor, conectivitatea în rețea și interoperabilitate” [1].

Definiția oferită de Stephen Haller de la SAP Research ne ajută să ne creăm o imagine mai concretă asupra Internet of Things, despre care spune că este „o lume unde obiectele fizice sunt integrate omogen în rețeaua informațională și unde aceste obiecte fizice pot deveni participanți activi în procesele business. Serviciile sunt gata să interacționeze cu aceste obiecte inteligente prin intermediul Internet-ului, să interogheze și să-și schimbe starea și orice informație asociată cu ele, luând în considerare securitatea și chestiunile ce țin de intimitate”[2].

O altă explicație este dată de Oracle, care afirmă că „Internet of Things se referă la colectarea și gestionarea cantităților masive de date provenite de la rețelele – 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 mărime al acestor cantități de date, ne putem uita la exemplul echipei de navigație Oracle Team USA, care lucrează cu ambarcațiuni echipate fiecare cu câte 300 de senzori, meniți să furnizeze informații despre o mulțime de parametri, cum ar fi eficacitatea reglajelor pânzelor, tăria și stabilitatea carenei sau tensiunea din catarg. Acești senzori măsoară 3000 de variabile de 10 ori pe secundă, producând 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ă până în 2020 procentul va crește la 40%[4].

Acest titlu descriptiv, care încearcă să surprindă esența următorului mare trend în IT, reprezintă în principiu efortul de a regândi relația noastră cu obiectele pe care le folosim în fiecare zi, dar și a obiectelor între ele. Conform experților, IT-ul se va îndrepta puternic în această direcție. Ca dovadă, mai multe nume sonore ale tehnologiei secolului al XXI-lea, precum Cisco sau Bosch, au întreprins studii pe această temă, ajungând la concluzia că proiectele din sfera IoT vor depăși valoarea economică de 15 trilioane de dolari, până în 2020[5]. De asemenea, analiștii 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, până 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, atât ca platformă ce are la bază Java Virtual Machine, cât și ca limbaj de pro g r am are , c u o comunitate de peste 9 milioane de utilizatori. Facem această distincție î nt re pl at for m ă și limbaj [7] întrucât un dispozitiv care rulează JVM nu este limitat la execuția de aplicații Java; acestea pot fi, în anumite condiții, aplicații scrise cu ajutorul Scala, Clojure etc. . În trecut, programarea dispozitivelor embedded se făcea preponderent în limbaje de nivel scăzut, precum C sau limbaj de asamblare. În acest articol vom încerca să ne facem o părere despre soluțiile propuse de Oracle pentru IoT, companie a cărei implementare a platformei Java se bucură de cea mai mare popularitate printre programatori.

Totuși, î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 aplicații pentru astfel de dispozitive, de la smart card-uri și module wireless, până 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

TODAY SOFTWARE MAGAZINE intermediul căruia contribuie la influența pe care o are Java în sfera Internet of Things.

Viziunea Oracle pentru Java 8 a fost să lanseze, pe lângă 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 Ståhl, vicepreședinte peste product management pentru Java și IoT la Oracle, afirmă în ediția noiembrie/decembrie 2014 a revistei Oracle Java Magazine că, prin lansarea acestor variante ale platformei au „făcut disponibile pe platforme embedded, care au doar câteva sute de KB de memorie, feature-urile cu care programatorii sunt obișnuiți î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 distribuțiilor amintite mai sus, Oracle a încercat să le aducă la un grad cât mai înalt de compatibilitate una cu cealaltă și, în același timp, să le alinieze la Java SE 8.

Pentru aceasta, s-a introdus conceptul de Compact Profiles, dezvoltatorii putând alege între setul complet de API-uri Java SE și alte trei subseturi care au la dispoziție 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). Așa cum vom vedea într-un articol viitor, OSGi joacă un rol important în cadrul eforturilor făcute de Eclipse Foundation pentru implementarea unei stive complete IoT, numită Open IoT Stack for Java. Începând cu Java 8, versiune lansată în prima parte a anului 2014, am văzut că Oracle face eforturi considerabile pentru a aduce la zi varianta Micro Edition (ME) a platformei, lucru ce confirmă implicarea corporației în războiul soluțiilor IoT. Printre îmbunătățirile aduse platformei se numără 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 inteligenți sau gateway-urile embedded. De asemenea, API-urile au fost actualizate pentru a răspunde nevoilor de programare a dispozitivelor țintă. Prin această nouă versiune Java ME, platforma are mult mai multe lucruri în comun cu Java SE, însă funcționalități precum reflection sau expresiile lambda urmează să fie adăugate. Acest aspect este important, întrucât în felul acesta, orice programator Java se va putea implica în proiecte embedded într-un timp scurt, fără a face eforturi considerabile. În 2015, Henrik Ståhl anunță că unii producători de hardware plănuiesc să integreze Java ME în dispozitivele lor, ceea ce va conduce la o mai mare rată de adopție a platformei.

Componentele construite cu soluțiile embedded despre care discutăm, livrate într-un context IoT, dau acces aplicațiilor business la resursele instalate în mediul înconjurător, atât pentru a primi input de la acestea cât și pentru a lansa comenzi. Un astfel de use case este orchestrarea sistemelor eterogene de control a temperaturii și a iluminării într-o clădire. Observăm că abilitatea Java ME de a controla echipamente cum ar fi senzori, valve sau servo-motoare, reprezintă unul dintre aspectele fundamentale ale obținerii unei infrastructuri IoT. Privind lucrurile de la o oarecare distanță, putem observa că arhitectura Java ne permite să creăm aplicații pe verticală, după cum a arătat și Maulin Patel, liderul în soluții de procesare embedded de la Freescale[8]. Întâi colectăm datele de la obiectele inteligente cu Java ME, apoi trecem la Java SE pentru servicii de gateway, iar în final executăm gestiunea și procesarea datelor cu Java EE, în cloud.

Aproape de fiecare dată când se vorbește despre IoT, se aduce în discuție problema securității. Într-un mediu eterogen și deschis precum este o infrastructură Internet of Things, securitatea este esențială, dar greu de obținut. Este de ajuns ca un atacator să aibă acces la una dintre componentele soluției IoT pentru a fi capabil să exploateze posibilele breșe în sistemul defensiv al acesteia. Spre exemplu, în cazul contoarelor inteligente de utilități, cel mai interesat de compromiterea acestor unități poate fi chiar proprietarul locuinței în care au fost instalate. Astfel, potențialul atacator are chiar și acces fizic la echipament, lucru ce ridică întrebări cu privire la nivelele la care trebuie implementate mecanisme de

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

41

testare

programare Internet of Things în universul Java securitate. Acum că am remarcat seriozitatea acestei chestiuni, putem veni cu o veste bună pentru dezvoltatorii IoT din universul Java, întrucât 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 următoare, când vom discuta câteva caracteristici tehnice ale platformei.

Java ME Embedded 8

Platforma dedicată dispozitivelor cu cele mai puține resurse, cum ar fi cardurile, se numește sugestiv, Java Card. Totuși, primul produs din familia Oracle care aduce cu adevărat o contribuție importantă în spațiul IoT este Java ME Embedded 8. Prin urmare, în continuare ne vom concentra atenția asupra acestuia. Înainte de a ne uita la câteva detalii, trebuie să menționăm 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 către dispozitive care au mai puțin de 1 MB de memorie. Astfel, este potrivită pentru „obiecte inteligente” fără interfață grafică, care au timp îndelungat de funcționare și resurse limitate.

Așa cum putem vedea în Figura 1, la baza Java ME Embedded 8 stă mașina virtuală, pe care o găsim 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 menționat 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. Așadar, avem la dispoziție adnotații, generics și multe alte caracteristici Java, familiare tuturor dezvoltatorilor.

Deși s-a realizat o evoluție foarte importantă prin lansarea CLDC 8, s-a reușit menținerea compatibilității binarelor cu versiunea anterioară.

Deasupra fundației pe care o reprezintă CLDC 8 stau mai multe componente definitorii pentru platformă. Una dintre ele este Generic Connection Framework 8 (GCF 8). Așa cum se poate intui, această componentă gestionează problemele de conectivitate. Acest framework este necesar întrucât în spațiul embedded posibilitățile de conectare sunt multiple,

42

iar dispozitivele pe care rulează aplicația noastră au interfețe 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 conectivității GCF 8 expune AccessPoint API. Totodată, GCF 8 vine cu suport pentru IPv6, scăpând dezvoltatorii Java ME Embedded 8 de emoțiile epuizării adreselor IPv4.

Revenind la subiectul securității în lumea Internet of Things, putem da câteva detalii despre modul în care GCF 8 rezolvă această problemă. Java ME Embedded 8 vine echipat cu implementări ale celor mai noi standarde în materie de securitate, printre care se numără 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 rețea ș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ă aplicația, în general cu ciclul de viață al acesteia. Prin intermediul MEEP 8 putem partaja cod între aplicații, putem actualiza componente în sistem sau aplica patch-uri aplicației. Partajarea bibliotecilor – denumite sugestiv, LIBlets – se face tot prin intermediul MEEP 8, contribuind la minimizarea necesarului de memorie și la modularizarea aplicațiilor. În plus, MEEP 8 oferă aplicațiilor posibilitatea de a comunica între ele atât sincron (Inter-MIDlet Communication sau IMC), cât ș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 funcție de situația specifică.

Astfel, încărcarea codului și execuția lui se realizează într-un mediu securizat, întrucât fiecare componentă este asociată unui client, având 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ă aplicațiilor acces la dispozitive periferice, cum ar fi senzori, comutatoare sau LED-uri. Această componentă exista și în versiunile anterioare, însă acum vine cu funcționalități noi, printre care late binding, care permite adăugarea de noi periferice, fără a fi necesară

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

modificarea API-ului.

Alături de aceste blocuri constructive, Java ME Embedded 8 vine cu o multitudine de API-uri, precum cel pentru servicii web sau localizare.

Având toate aceste componente Java ME Embedded la dispoziție, este la îndemâna noastră, a dezvoltatorilor, să construim aplicații embedded, contribuind la spațiul Internet of Things. În ajutorul nostru vine Java ME SDK 8, un toolkit complet creat pentru a întâmpina orice nevoie avem în procesul creării și întreținerii unei aplicații. Acest SDK oferă inclusiv un mediu de emulare, având posibilitatea să ne testăm aplicațiile chiar dacă dispozitivele pe care vor fi distribuite nu sunt disponibile în timpul dezvoltării. De asemenea, putem face debugging atât în modul de emulare, cât și atunci când aplicația rulează pe dispozitiv. Pentru a întregi acest set de unelte, Oracle oferă plugin-uri pentru Netbeans IDE și Eclipse IDE, care încorporează toate funcționalitățile 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 configurația destinată dispozitivelor mobile cu ceva mai multe resurse, cum ar fi smartphone-urile. Pentru Java ME Embedded Client, această configurație a fost restrânsă și optimizată, pentru a se potrivi sistemelor embedded de categorie joasă înspre medie. Deși amprenta acestei configurații este redusă, oferă mare parte din limbajul Java. Astfel, Java ME Embedded Client este destinată obiectelor inteligente cu mai puțin de 10 MB de memorie și fără interfață grafică.

Concluzii

Industria IT autohtonă nu este străină de spațiul Internet of Things, începând să fie lansate produse Made in Romania, precum Pocketo sau Tintag. De asemenea, există companii în România, implicate în proiecte care se integrează în paradigma IoT. De exemplu, regăsim astfel de proiecte la Brașov în domeniul automotive, cu al său concept de connected car. Un alt lucru îmbucurător 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 Brașov.

Un obiectiv important pentru Oracle în ultima perioadă este afirmarea platformei

TODAY SOFTWARE MAGAZINE articolul viitor, când 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 soluțiile IoT. Mai mult decât atât, IoT Picture: http://blog.surveyanalytics.com/2014/09/top-5-infographics-ofcorporația și-a exprimat dorința de a câștiga această bătălie, ast- week-internet-of.html fel încât Java să devină alegerea majorității specialiștilor implicați în astfel de proiecte. Totuși, răspunsul a venit rapid din partea oponenților, existând multe voci care și-au exprimat scepticismul cu privire la potrivirea platformei în sfera IoT. Există multe argumente, atât pro, cât și contra acestei idei, însă un lucru e cert: Dănuț Chindriș Java a străbătut un drum lung pentru a ajunge la gradul actual danut.chindris@elektrobit.com de maturitate, diversitate și aplicabilitate. Eforturile din ultimii ani au dat naștere unei noi familii de produse, care se doveJava Developer @ Elektrobit Automotive desc promițătoare și, mai mult, încep să-și dovedească valoarea în cadrul proiectelor reale IoT. Vom vedea clar acest lucru în

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

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 numărul dispozitivelor conectate la internet crește dramatic în fiecare zi, noi trebuie să găsim diferite mecanisme de comunicare.

Radu Vunvulea

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

44

nr. 31/2015 | www.todaysoftmag.ro

Deoarece nu putem controla când un dispozitiv este conectat la internet și pregătit să primească mesajul nostru, e important să detectăm diferite modalități de a comunica cu el. În acest articol, vom arunca o privire asupra diferitelor sisteme de mesagerie care sunt oferite de către Microsoft Azure.

Pentru fiecare sistem de mesagerie vom încerca să identificăm punctele forte și când ar trebui să îl utilizăm. Odată ce vom fi înțeles fiecare sistem de mesagerie, le vom compara unul câte unul. În finalul acestui articol vom identifica un sistem de mesagerie perfect, care poate fi utilizat în orice situație. Pentru diferite cazuri de utilizare s-ar putea să fie nevoie să folosim sisteme de mesagerie diferite, în funcție de nevoile noastre.

Soluțiile de mesagerie care vor fi discutate în acest articol sunt următoarele: • Azure Storage Queues, • Azure Service Bus Queues, • Azure Service Bus Topics, • Azure Event Hub.

multe mesaje în același șir. Când spun multe, imaginați-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ă depozităm cantități mari de date în șiruri, fără a ne gândi la dimensiunea șirului.

Un alt avantaj al acestui tip de șir este numărul clienților concurenți, care teoretic este nelimitat. Singura limită în acest caz este lățimea de bandă care poate limita numărul clienților concurenți.

Dimensiunea maximă a unui mesaj este de 64 KB, dar în blocuri combinate putem avea mesaje care ajung la 200 GB. Bineînțeles că mai există anumite limitări pe care trebuie să le luăm în considerare. În primul rând, 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 reînnoit, altfel, mesajul va fi șters.

Chiar dacă avem suport pentru capacități de mesagerie de bază precum Azure Storage Queues monitor de înlănțuire și suport lot de date, Acest sistem de mesagerie face parte nu avem suport pentru management de din Azure Storage și ne permite să stocăm stare, detectarea duplicării și suport pentru

TODAY SOFTWARE MAGAZINE tranzacții.

O caracteristică interesantă a Azure Storage Queues este capacitatea de logging.

Utilizatorii au posibilitatea de a activa mecanismul de logging și de a urmări toate acțiunile care au loc în șir. Informațiile precum IP-ul clientului sunt urmărite și stocate drept o soluție de-a gata.

Clienții au posibilitatea de a se uita la mesajele din șir, fără a le șterge sau bloca.

Aceasta înseamnă că, dacă un client se uită la un mesaj, și alți clienți vor putea accesa același mesaj din șir.

Din acest motiv, Azure Storage Queues este foarte eficient când ai nevoie de un sistem de mesagerie care să fie capabil să urmărească toate acțiunile care au loc în șir. Acesta este o soluție 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ă adăugăm un mesaj care deja există în sistem, mesajul nu va fi adăugat.

Acest lucru este grozav când dorim să ne asigurăm că avem mesaje unice în șir.

Mesajele pot fi consumate din șir în două moduri diferite – Peek and Lock (Privește și Blochează) sau Receive and Delete (Primește și Șterge). Ne putem uita la un mesaj dintr-un șir și îl putem face indisponibil pentru restul clienților până când vom confirma că l-am consumat cu succes sau vom anula acțiunea (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 când este nevoie de detectarea duplicatului, suport pentru tranzacții 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 comparație cu Azure Storage Queues și de asemenea un mesaj va fi păstrat î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ă mutăm automat un mesaj într-un șir secundar, dacă acel mesaj expiră sau clientul nu poate consuma un anumit mesaj.

Există suport complet pentru tranzacții, gestionarea unui număr specific de mesaje în aceeași tranzacție. Mai mult decât atât, există suport pentru mesaje multiple de grup în aceeași 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ă livrăm mesajele unul la unul, Azure Service Bus Topics ne permite să livrăm un mesaj la mulți.

Acest lucru înseamnă că noi putem furniza același mesaj la clienți multipli care se numesc subsribers (abonați). 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 asemănătoare cu Azure Service Bus Queues, având câteva funcționalități și posibilități adiționale.

Asemănarea celor două servicii se datorează faptului că ambele sisteme de mesagerie sunt construite pe același sistem de infrastructură de mesagerie broker.

Fiecare temă care este utilizată pentru a trimite mesaje poate avea maxim 2000 de abonați, însemnănd că același mesaj poate fi primit de 2000 de abonați. Acest lucru poate fi foarte util atunci când trebuie să distribuim mesaje către diferite sisteme.

De asemenea, o subscriere poate fi adăugată în timpul de rulare. Nu este nevoie să oprim sistemul sau să recreăm tema.

Odată ce o nouă subscriere a fost creată, toate mesajele noi care sunt trimise către acea temă vor fi primite și de către noua subscriere.

O caracteristică interesantă este suportul filtru. Noi putem atașa un filtru la fiecare subscriere. Acel filtru va permite numai mesajelor care respectă regula filtrului să ajungă la aceeași subscriere

anume. În acest fel, fiecare subscriere poate asculta mesaje specifice.

Ambele sisteme de mesagerie, Azure Service Bus Topics și Queues au capacități 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 subscripție către un alt Service Bus Topic al Queue.

Fiecare mesaj care este trimis printrun Service Bus poate avea o colecție de proprietăți. Proprietățile sunt utilizate atunci când este aplicat un filtru de comandă per subscriere. De asemenea, fiecare subscriere poate avea o acțiune la comandă care este executată atunci când primește un mesaj. Chiar dacă acțiunile care pot fi executate sunt foarte simple, poate fi foarte util în anumite situații – de exemplu, ne este permis să schimbăm numele valorii proprietății.

Datorită proprietăților sale, Azure Service Bus Topics este perfect de utilizat atunci când este nevoie să distribuim un mesaj către mai mulți ascultători. În sistemele în care numărul clienților 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 obișnuit să înghită cantități mari de date într-o perioadă scurtă de timp. Acest sistem este capabil să înghită peste 1 milion de mesaje pe secundă, fără niciun fel de problemă.

Este construit pe conceptul de curgere.

Din această cauză, toate mesajele care plutesc în sistem sunt văzute drept un flux de date. Latența este foarte scăzută ș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 răspunde. Mai mult, fluxul de mesaje poate ajunge la mai mulți clienți în același timp, utilizând conceptul de grup al clienților.

O calitate importantă care poate fi găsită la Azure Service Bus este păstrarea ordinii mesajelor. Aceasta înseamnă că ordinea mesajelor se păstrează. Clienții vor putea să consume mesajele în ordinea în care ele au fost trimise.

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

45

programare Ce sistem de distribuire de mesaje din Azure să folosesc?

Capacitățile sistemului Event Hub pot scala destul de interesant, prin adăugarea de TU multipli (Throughput Units).

Fiecare TU ne permite 1 MB/s pentru intrare și 2 MB/s pentru ieșire. Retenția unui mesaj este de o zi, fiind capabil să le depoziteze până la 7 zile.

Bineînțeles că aceasta vine cu anumite costuri. Caracteristici precum șirul scrisorilor moarte, suport pentru tranzacții sau opțiuni TTL nu pot fi găsite pe Azure Event Hub. Această soluție este perfectă pentru volumuri mari de procesare de mesaje, cum ar fi telemetria sau în cazurile de utilizare IoT.

Care este cea mai bună soluție?

Nu există un răspuns unic la această întrebare. În funcție de nevoile noastre și de cerințe, putem utiliza sisteme diferite de mesagerie. Azure Storage Queues este perfect când este nevoie să depozităm și să gestionăm cantități mari de mesaje, dar, când avem nevoie de mai mult control, Azure Service Bus Queues poate fi o soluție

46

mai bună. Pentru cazurile de utilizare în care avem nevoie să distribuim mesaje mai multor ascultători, 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 fiecăruia. Am văzut 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ă vedeți web site-ul Azure și să descoperiți mai multe despre aceste servicii grozave.

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

legal

TODAY SOFTWARE MAGAZINE

Noi tehnologii - în pragul Data Protection Day 2015

P

e vremuri, Arthur C. Clarke, autorul celebrului roman science fiction “2001 – Odiseea Spațială”, afirma: “Any sufficiently advanced technology is indistinguishable from magic .”

În fiecare zi, suntem uimiți de noi și noi minuni ale științei și tehnicii ce se insinuează și devin parte din viața noastră de zi cu zi. Lucruri precum Internetul Lucrurilor (Internet of Things), tablete, telefoane inteligente, aplicații mobile, drone, soft-uri de analytics, instrumente de online tracking și de geo-localizare, mașini 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 rândul cărora mă înscriu și eu) știrea prin care NASA anunța crearea unui Tricorder1 care să colecteze date medicale despre pacienți și să diagnosticheze eventuale boli, e un prilej de entuziasm. Pentru celebrul Stephen Hawking, ajutat de mulți ani de tehnologie ca să supraviețuiască și să interacționeze cu cei din jur, avântul tehnologic este, totuși, prilej de previziuni sumbre2.

Juriștii nu pot rămâne însă prea mult timp visători în fața magiei noilor tehnologii, din cauza provocărilor legale cu care se confruntă. De multe ori, se pune problema dacă legislația poate ține pasul și dacă / cum ar trebui schimbată pentru a reflecta noile realități. Și cum pe 28 ianuarie se sărbătorește 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 hotărât să încerc să ies din «reveria tehnologică» și să folosesc această bună ocazie pentru a reflecta puțin la câteva dintre tehnologiile noastre favorite care ne pot colecta și folosi datele cu caracter personal în cele mai diverse moduri.

Aplicațiile mobile, tabletele și telefoanele smart “aspiră” masiv date

Protejarea datelor cu caracter personal prelucrate prin intermediul aplicațiilor mobile (app privacy) rămâne un subiect de actualitate și merită atenția crescută a dezvoltatorilor.

Multe aplicații mobile colectează și folosesc date cu caracter personal ale utilizatorilor. Acest lucru implică răspunsul la o serie de întrebări, precum: aplicația este sau nu worldwide, ce informații și date sunt colectate, unde sunt stocate, cum sunt folosite, dacă și cui pot fi dezvăluite, etc. .Având în vedere potențialele riscuri juridice, o politică bine pregătită 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 potențialelor riscuri legale încă din etapele incipiente ale dezvoltării aplicațiilor (de exemplu, înainte de a implementa în aplicație o funcționalitate 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 aplicațiilor mobile, puteți citi în articolul “Dezvoltatorii de aplicații mobile și datele personale. Vreo legătură?“5 publicat în numărul 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 informații și date. Iar cei familiarizați cât de cât cu conceptul de “big data”, probabil știu deja că big data = big business. Unii îndrăznesc chiar să afirme 6 că datele cu caracter personal (chiar în formă anonimizată) pot fi considerate “noul petrol”, având ș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 esențial, fiind instrumente puternice care pot urmări 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 însoțită de un potențial risc de abuz. De aceea, din punct de vedere juridic, activitățile desfășurate 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, Conferința Europeană a ITechLaw.

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

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 amenințare majoră la adresa datelor clienților ș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 folosește tool-urile ce îi sunt puse la dispoziție și la ce date vrea să ofere acces. Însă există anumite reguli și recomandări care trebuie luate în considerare, pentru a se încerca prevenirea riscului de abuz (de exemplu, prin informarea corectă a utilizatorilor despre operațiunile în cadrul cărora le pot fi colectate datele și le poate fi urmărită activitatea online, astfel încât 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 ușoare, 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, fără ca cei vizați să accepte să fie fotografiați sau filmați.

Cum imaginea și vocea unei persoane fizice sunt date cu caracter personal, înțelegem de ce această activitate nu este tocmai în regulă în lipsa acordului persoanei vizate. În raportul său TMT Predictions 20157, Deloitte estimează că veniturile totale ale industriei dronelor se va ridica la 200 - 400 milioane de dolari în 2015 (echivalentul prețului de listă al unui avion mediu de pasageri). Totuși, pe termen scurt și mediu, se pare că folosirea dronelor va fi limitată, un factor-cheie fiind legislația. În 7 http://www2.deloitte.com/global/en/pages/ technology-media-and-telecommunications/articles/tmt-preddrones-high-profile-and-niche.html

48

unele țări, legislație aplicabilă nu există sau este incertă, în altele se aplică încă regulile generale privind avioanele. În România, î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ă (fără construcții cu destinaţia de locuinţă); • Nu au montate pe ele aparatură pentru filmare sau transmisie de date; și • Nu depăşesc câmpul vizual al persoanei care comandă drona de la sol (dar nu mai mult de 150 m distanţă pe orizontală şi 100 m distanţă pe înălţime).

Mașinile care se conduc singure – un coșmar necesar?

Self-driving cars sunt o temă “fierbinte”.

Dar pe lângă 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 mașini.

Cum vor avea permanent o conexiune wireless, mașinile care se conduc singure pot fi urmărite constant. Iar datele de localizare și alte informații colectate prin intermediul unei asemenea mașini pot fi considerate date cu caracter personal ale celor care folosesc aceste mașini. De aceea, întrebări precum Cine ar trebui să dețină sau să controleze datele colectate de aceste mașini? 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 când 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, renunțăm la libertatea de mișcare și devenim urmăriți la fiecare “pas”. În presa din străinătate8 se atrage atenția asupra faptului 8 http://www.theguardian.com/commentisfree/2014/

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

că ar trebui să ne intereseze modul în care aceste mașini sunt dezvoltate în prezent, deoarece - în caz contrar - este posibil ca în viitor să nu fie un simbol al libertății individuale, ci dimpotrivă un mijloc de supraveghere a indivizilor.

Ceea ce ne indică faptul că, până la momentul în care va exista o legislație specifică acestei tehnologii, procedeul Privacy by design pare potrivit pentru a fi aplicat și în cazul mașinilor care se conduc singure, încercând implementarea încă din primele faze ale construcției mașinii.

Iar la final,

Happy Data Protection Day 2015 and … Let’s 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, Ph.D.

simona.bonghez@confucius.ro Speaker, trainer and consultant in project management, Owner of Colors in Projects

- No, în sfârșit... răsuflă Mișu ușurat văzând numele și mai ales fața lui Gogu pe ecranul smartphone-ului. N-apucă însă să zică ceva că șuvoiul vorbelor lui Gogu se dezlănțui prin micul device de parcă se rupsese zăgazul1: - Da’ ce s-a întâmplat, dom’le, de suni ca nebunu’?! Ori crezi că sunt chior și nu văd c-ai sunat de prima dată? Cine-o murit, ce-o explodat, că nu mi-e dat și mie să am o zi de liniște!

O zi, frate, atât 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 tău de fiecare dată când te mai întinzi după el. Ori ești sinucigaș și vrei să-ți rezolv eu problema plecării din sânul 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ă respirația. Te-ai fi așteptat ca Mișu să se repeadă asupra ocaziei și să ia cuvântul, dar se pare că el prevăzuse o asemenea reacție, iar acum aștepta ca „viitura” să se domolească. Și într-adevăr, odată plămânii realimentați, Gogu mai pierdu din avântul inițial. Adaugă doar: - Deci?

Zâmbetul se lăți pe fața lui Mișu: scăpase mult mai ieftin decât își închipuise. Fără să se grăbească deloc, îi povesti lui Gogu problema cu care se confrunta și din cauza căreia insistase să-l găsească, 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ă văd dacă am înțeles, încercă Gogu să sintetizeze informația. Te-a pus Șefu’ să găsești un manager de proiect pentru implementarea cerută de client. Iar tu ai insistat să îi dai răspunsul pe loc, hmm, ceea ce nu e deloc genul de atitudine pe care o adopți 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 cârcă și să-mi asum eu responsabilitatea în cazul unui posibil, chiar probabil eșec. Măi da’ ce băiat deștept te-ai făcut tu peste noapte!

Urmă realimentarea plămânilor. Fața spășită a lui Mișu arăta că era pregătit pentru tot ce era mai rău. Dar ca și data trecută, la capătul celălalt al firului lucrurile se liniștiră. Pentru cine îl cunoștea pe Gogu era evident că acesta intrase în modul de căutare soluții. Ăsta era un alt lucru care îi plăcea lui Mișu la Gogu: invariabil ajungea să se gândească la rezolvări.

Era suficient să îi arăți problema, așa cum îi arăți câinelui bățul. Numai că Gogu nu dă din coadă, gândi Mișu și dădu 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? îndrăzni Mișu să spargă tăcerea.

- Oare, oare!... mă gândeam la Cristina. Este suficient de matură, a dovedit-o în proiectul cu 1

Zăgaz – Baraj, stăvilar (DEX, 2009)

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

49

management Gogu și jocul alternativelor englezii, are experiența lucrului în echipă virtuală și îi și cunoaște deja pe mulți dintre cei cu care va trebui să colaboreze. N-o să-i fie ușor cu clientul, dar asta e, dacă era ușor, o putea face oricine.

Merită o șansă.

Mișu tăcu.

- Ei, zi ceva, insistă Gogu. Până și la viteza ta de reacție, informația tot trebuia să-ți ajungă deja la creier. Pământu’ către Mișu: Alo! Sau crezi că nu e pregătită încă?

Mișu chiar era încurcat: - Da’ io am zis de Tibi... Tibi îi mult mai experimentat.

- Păi da, măi șmechere, da’ dacă te duci iar cu o singură opțiune la Șefu’, iar îi dai de ales între „a face ceva” și alternativa „să nu faci”. Și dacă răspunsul e cu „nu”, iar te dai de ceasul morții. Trebuie să îi dai două variante viabile lui Șefu’, el va cumpăni propunerile și va alege cea mai bună dintre ele. Nu mai riști astfel să pleci de la el fără să rezolvi problema. Mintea umană așa funcționează: compară alternative, opțiuni; 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, fără prea multă experiență, dar dornică să învețe, să demonstreze, să se afirme.

Bla-bla-bla, mai adaugi tu.

- Ce adaug? Bla-bla? Îl luă Mișu peste picior.

- Hai că mă enervezi. ’Nțeles?

- Am ’nțeles, 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 apăsat ultimele cuvinte. Cred că nici nu voi mai avea semnal, deja nu te mai aud, Mișule, alo, alo, ies din zona cu semnal și revin mâine dimineață. Pa. Gogu întrerupse convorbirea, zâmbi în sinea lui și își reluă tacticos meșteritul la bicicletă.

- Tatăăă...

- Ah, nu! Ce-aveți azi cu mine?! Tu ce mai vrei? se întoarse disperat Gogu către fiul lui. Nu mi-e dat azi să mă bucur de ziua frumoasă, de bicicletă, de meșterit, de nimic. Zi, măi, ce mai e?

Numai că fi-su îi știa rolul de morocănos de serviciu și nu îi luă în serios bombănitul teatral. Continuă fără 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 jucăm Assassin’s Creed, mai povestim...

- Poftim? Cum să dormi la Andu, ce tu n-ai casă? Asasini deăia te poți juca cu el și de-acasă. Mai bine ați juca Fifa2014.

50

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

- Ah, bine, atunci sună-mă tu pe la unșpe jumate, doișpe fără un sfert, când vii spre Andu să mă iei. Merci, tata! Copilul făcu încântat stânga-împrejur și plecă fluierând.

Gogu rămase înlemnit când văzu buna dispoziție a copilului își dădu seama de capcană. Era însă prea târziu: 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 târziu. Doamne, ce l-a mai învârtit copilul ăsta pe degete. I-a dat două variante, din care, el, Gogu! a ales-o pe cea mai favorabilă. Ufff! Același mecanism pe care îl explicase câteva minute mai înainte lui Mișu fusese aplicat – cu succes – pe el. Ha! Și îl străfulgeră o idee genială: stai așa, că mâine, în loc să-l întreb pe Șefu’ dacă e de acord să mergem șase oameni la Conferința cu mamuții2, mai bine îi dau două variante: doar șase de la noi din departament sau mai bine îi luăm și pe colegii de la testare, și mergem zece... Ce tare e asta...

2

E vorba de conferința pe teme de managementul proiectelor ...even mammoths can be

Agile, din 6-7 martie 2015, Cluj

sponsori

powered by