Numarul 23/mai 2014 - Today Software Magazine

Nr. 23 • Mai 2014 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

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

ile

Scrum-ul Perfect: Fata Morgana din Ag Java 8, expresii lambda şi nu numai

Livrarea aplicațiilor mobile de succes Big Data și Social Media: Marea Schimbare Dincolo de API Întreţinerea la zi a sistemelor Linux (I) Platforma OnyBeacon iBeacon Abilitățile sunt mai presus de tehnologie

Procesoare de șabloane pentru dezvoltare web în Java Cum protejăm o idee bună de afaceri Analiza eficientă a scenariilor de utilizare Code Kata 5 reguli simple pentru o campanie eficientă

6 Cluj IT marchează o nouă etapă a dezvoltării sale ca cluster inovativ Paulina Mitrea și Andrei Kelemen

8 How to Web lansează MVP Academy Irina Scarlat

10 Topconf Bucharest 2014 Chris Frei

11 Comunitatea locală în JavaScript se întâlnește la București!

Iunieta Sandu

12 A 5-a ediție de ”mamuți” Agili s-a încheiat la Cluj-Napoca!

Adina Grigoroiu, CAPM

14 Livrarea aplicațiilor mobile de succes Larisa Gota

18 Java 8, expresii lambda şi nu numai Silviu Dumitrescu

21 Qt: Cum m-am îndrăgostit de C++ Ambrus Oszkár

25 Dincolo de API Alpar Torok

28 Întreţinerea la zi a sistemelor Linux (I) Sorin Pânca

31 Modelarea datelor în contextul Big Data Silvia Răusanu

39 Code Kata Tudor Trișcă

35 Analiza eficientă a scenariilor de utilizare Anita Păcurariu

39 Abilitățile sunt mai presus de tehnologie Alexandru Bolboaca și Adrian Bolboaca

41 Scrum-ul perfect: Fata Morgană din Agile Bogdan Mureșan

43 5 reguli simple pentru o campanie eficientă Ruxandra Tereanu

44 Big Data şi Social Media: marea schimbare Diana Ciorba

46 Platforma OnyxBeacon iBeacon Bogdan Oros

49 De-adevăratelea!

Antonia Onaca

51 Procesoare de șabloane pentru dezvoltare web în Java Dănuț Chindriș

55 Cum protejăm o idee bună de afaceri Claudia Jelea

56 Gogu şi sticla de apă Simona Bonghez, Ph.D.

editorial

L

Ovidiu Măţan

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

una aprilie s-a dovedit la fel ca și în ceilalți ani o lună propice pentru scrierea articolelor. Ne bucurăm așadar de interesul crescut al colaboratorilor precum și de cel al cititorilor revistei. Online, am depășit 6,000 de cititori lunar fără a considera revistele în format tipărit distribuite în cadrul diferitelor evenimente și a descărcărilor directe. Ne extindem și aria evenimentelor proprii de lansare, pentru că în afară de Cluj, vom fi prezenți pentru prima oară și în Brașov, după ce cu o lună în urmă a avut loc o lansare în Timișoara. De asemenea, sunt plănuite o nouă lansare în București și una în Iași.

Un subiect care devine din ce în ce mai important inclusiv pentru companiile ce își desfășoară domeniul de activitate exclusiv în zona outsourcing-ului, este reprezentat de startup-uri. Aceast interes este reflectat de numărul mare de evenimente și de programe dedicate acestora. Chiar și în aceste condiții trecerea la dezvoltarea de produse nu este cea mai ușoară, iar eșecul poate descuraja. O abordare diferită este crearea de proiecte culturale sau care pot îmbunătăți viața comunității. Astfel, acestea conțin elementele necesare unui produs comercial de succes și anume popularitate, ușurința în folosire, promovarea folosind rețelele sociale și nu în ultimul rând implementarea cerințelor aplicației. Am să dau și două exemple cunoscute cititorilor revistei, Statui de Daci - statuidedaci.ro realizată de Gemini Solutions precum și aplicațiile dedicate dispozitivelor mobile iOS și Android ale revistei Today Software Magazine. Implementarea fiind făcută de 3Pillar Global și Gemini Solutions. Vă invităm să luați în considerare această direcție și promitem să venim cu un articol dedicat acestui trend.

Tema acestui număr a fost social media iar din această perspectivă vă invităm să citiți Modelarea datelor în contextul Big Data în care analizată denormalizarea datelor, necesară în contextul cloud precum și Big Data şi Social Media: marea translaţie ne arată statistici despre această evoluție. Doresc să menționez o parte din articolele tehnice prezente în acest număr: Java 8, expresii lambda şi nu numai unde veți descoperi ultimele noutăți ale limbajului Java, Qt: Cum m-am îndrăgostit de C++ o redescoperire a C++ în contextul QT, Dincolo de API sau cum putem să ne definim mai bine API-urile, Întreţinerea la zi a sistemelor Linux pentru cei din DevOps, Platforma OnyxBeacon iBeacon ne prezintă unul dintre cele mai actuale tehnologii folosite în comunicarea cu clienții finali iar Procesoare de șabloane pentru dezvoltare web în Java evaluează framework-urile Model View Controller existente pentru Java. O optimizare a modului în care învățăm este propusă în Code Kata și Abilitățile sunt mai presus de tehnologie, iar pentru o mai bună planificare a cerințelor vă invităm să citiți articolul Analiza eficientă a scenariilor de utilizare. Pașii obligatorii și apectele importante ce trebuie luate în considerare pentru o bună lansare a unui produs sunt propuși în Livrarea aplicațiilor mobile de succes și 5 reguli simple pentru o campanie eficientă. La final, doresc să vă propun un articol scris în spiritul Agile Scrum Scrum-ul perfect: Fata Morgană din Agile.

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

Ovidiu Măţan

Fondator al Today Software Magazine

4

nr. 23/Mai, 2014 | www.todaysoftmag.ro

Redacţia Today Software Magazine Fondator / Editor in chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com Editor (startups și interviuri): Marius Mornea marius.mornea@todaysoftmag.com Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com Copyright/Corector: Emilia Toma emilia.toma@todaysoftmag.com Traducător: Roxana Elena roxana.elena@todaysoftmag.com

Lista autorilor Andrei Kelemen

Claudia Jelea

Director executiv @ IT Cluster

Avocat & Consilier in domeniul marcilor

andrei.kelemen@clujit.ro

claudia.jelea@jlaw.ro

@ IP Boutique

Alexandru Bolboaca

Bogdan Mureșan

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

Director of Engineering @ 3Pillar Global

Anita Păcurariu

Ruxandra Tereanu

Business analyst @ Endava

Conversion Analyst @ Betfair

Chris Frei

Sorin Pânca

Organizer @ TopConf

Senior Systems Administrator @ Yardi România

Paulina Mitrea

Larisa Gota

Coordonator of Innovation group @ ClujIT Cluster

QA Engineer @ Small Footprint

alex.bolboaca@mozaicworks.com

anita.pacurariu@endava.com

bogdan.muresan@3pillarglobal.com

ruxandra.tereanu@betfair.com

Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com

frei@topconf.com

sorin.panca@yardi.com

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

Paulina.Mitrea@cs.utcluj.ro

lgota@smallfootprint.com

Tudor Trișcă

Silviu Dumitrescu

Team Lead & Scrum Master @ msg systems România

Line manager @ Accesa

Tudor.Trisca@msg-systems.com

silviu.dumitrescu@accesa.eu

Adina Grigoroiu, CAPM

Ambrus Oszkár

Trainer și consultant @Colors in Projects

Software Engineer @ Accenture

Silvia Răusanu

Alpar Torok

Senior Developer @ ISDC

Functional arhitect @ HP România

Diana Ciorba

Bogdan Oros

Marketing Manager @ Codespring

Co-Fondator @Onyx Beacon

adina.grigoroiu@confucius.ro

silvia.rausanu@isdc.eu

oszkar.ambrus@accenture.com

alpar-istvan.torok@hp.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ă.

diana.ciorba@codespring.ro

bogdan@onyxbeacon.com

www.todaysoftmag.ro www.todaysoftmag.com

www.todaysoftmag.ro | nr. 21/Martie, 2014

5

prezentare

Cluj IT marchează o nouă etapă a dezvoltării sale ca cluster inovativ

L

una aceasta marchează o nouă etapă în eforturile de construcție a unei identități relevante pentru clusterul Cluj IT, dar și o oportunitate de dezvoltare pe o direcție de inovare a membrilor asociației noastre. Proiectul depus anul trecut de către Cluj IT în cadrul apelului deschis POSCCE/ Op.1.3.3 se află în ultima fază a semnării contractului de finanțare și va fi implementat pentru o perioadă de 18 luni după semnare. Este rezultatul unui efort de pregătire de peste un an de zile.

Un proces interesant în această etapă, care merită semnalat aici pentru că marchează maturitatea organizațiilor membre ale cluster-ului nostru, a fost cel de selecție a ideilor de produse inovative cu potențial marchetabil care urmau să fie sprijinite prin acest proiect. În urma evaluării, în contextul grupului „Innovation”, a ideilor de subproiecte propuse de către companii și universități, au fost selectate inițiativele concrete de realizare de produse software inovative înscrise în tematica generală a proiectului, care vor fi dezvoltate până în faza de produs final, cât și un număr de subproiecte finanțabile până în faza de design (adică proiect software complet), pentru a căror continuare, în sensul implementarii și scoaterii pe piață, urmează să se atragă alte finanțări viitoare.

În jurul fiecărui subproiect sunt grupate consorții, formate atât din firme ale cluster-ului cât și din Universități, ca atare odată cu demararea implementării acestui proiect vom proba cu adevărat potențialul de cooperare al membrilor noștri. Totodată proiectul va permite devoltarea unor activități care țintesc spre consolidarea organizațională și extinderea relațiilor între membrii clusterului. Concret, vor fi implementate acțiuni de tip training (pentru resursa umană a companiilor din cluster), vor fi inițiate și desfășurate parteneriate cu alte entități din afara cluster-ului prin participări la conferințe și târguri, vor fi derulate campanii de publicitate și marketing și vor fi finanțate evenimente majore ale organizației noastre (cum ar fi Cluj Innovation Days, ediția 2015).

Foarte important este faptul că proiectul va facilita obținerea de asistență și consultanță pentru consolidarea unor direcții de dezvoltare ale cluster-ului Cluj IT prin care dorim să ne aliniem celor mai înalte standarde de excelență la nivel european. În articolul nostru din numărul 20 al revistei, intitulat „Clusterul ClujIT: Inovare Interdisciplinară și soluții IT avansate pentru o comunitate urbană de avangardă”, în contextul prezentării obiectivelor generale ale Clusterului ClujIT am scos în evidență faptul că, în virtutea unui crez asumat prin însuși statutul asociației ClujIT Cluster, obiectivul cel mai important este oferirea de soluții IT inovative pentru comunitate, bazate pe aport colaborativ de know-how și competențe avansate, chiar de avangardă(!), provenite din toate mediile furnizoare de knowledge și expertiză care sunt atât de bine reprezentate în urbea noastră. În acest

6

nr. 23/Mai, 2014 | www.todaysoftmag.ro

context, am și anunțat pregătirea derulării unuia dintre proiectele majore ale Cluster-ului nostru, anume “Dezvoltarea Inovativă prin Informatizare a Ecosistemului Urban Cluj-Napoca” cunoscut și sub denumirea de „Cluj-Napoca: Next Generation Brained City” - proiect aprobat spre finanțare pe POSCCE/ Op.1.3.3 și care, în momentul de față, așa cum am arătat și mai sus, se află în etapa de finalizare a semnării contractului de finanțare. Prin modul de abordare, acest proiect este menit a genera un areal de viețuire bazat pe conceptul inovativ de comunitate de tip urban ecologic și complet informatizată, consacrată sub paradigma de „networked ecological city”, ceea ce va constitui premisele necesare pentru ca mediul nostru urban să devină un mediu armonios și eco-eficient, în care componentele și nivelurile specifice ale activităților și elementelor caracteristice unui oraș inteligent, sunt armonizate prin intermediul unei informatizări integrative și exhaustive.

Pe fondul problemei, abordarea conceptului central al proiectului pornește de la identificarea a două premise esențiale, care se intercondiționează după cum urmează: (1) comunitățile actuale urbane (cât și rurale, în anumite cazuri) beneficiază pe anumite niveluri de sisteme informatice necorelate și neintegrate în totalitatea lor, aflate în stadii diverse de evoluție și dezvoltate pe o mare varietate de platforme și tehnologii IT; (2) în conditțile prezervării premisei (1) în paradigma curentă, ritmurile de dezvoltare actuale ale comunităților, pe toate componentele, riscă să conducă la evolutii haotice (contrare nevoii de expansiune armonioasă pe toate elementele).

Luându-se în considerare aceste două premise, în vederea soluționării riscului relevat în contextul celei de a doua, un model de dezvoltare pe “layers”, adică straturi intercorelate și comunicante, armonizate prin informatizare coerentă, inovativă și integrativă, constituie paradigma asumată deja prin construcția însăși a proiectului, construcție mulată pe conceptele cele mai avansate de dezvoltare urbană. Menținându-ne la nivelul de conceptualizare a proiectului, consemnăm faptul că întreaga abordare se bazează pe implicarea instrumentului oferit de triunghiul cunoașterii (knowledge triangle), în realizarea – ca target final - a triunghiului sănătății comunităților umane (health triangle), ceea ce garantează dezvoltarea unui mediu de business și viețuire de tip

TODAY SOFTWARE MAGAZINE De fapt, întreaga politică de dezvoltare economică a Uniunii Europene se bazează pe două concepte majore și anume specializare inteligentă (smart specialization) și cluster-izare, în timp ce instrumentele esențiale de atingere a obiectivelor de performanță socioeconomică sunt circumscrise dezvoltării IT&C, digitalizării și tehnologiilor generice-cheie (key enabling technologies). Sperăm ca alinierea României la aceste direcții „Next Generation Brained City”. strategice de dezvoltare, susținute și Noul concept urban vizează o dezvoltare economică suste- financiar, să fie continuată prin măsuri de susținere directă a clusnabilă și eficientă pentru un context de comunitate eco-eficient ter-elor și mediului privat și în actuala perioadă de programare. și profitabil.Întreaga construcție a proiectului este structurată pe șapte niveluri, pe aceste niveluri înscriindu-se subproiectele selectate pentru a fi dezvoltate de grupuri distincte de firme și reprezentanți ai universităților din cluster, anume: (1) nivelul informatizării administrației publice; (2) nivelul rețelelor de transport/trafic; (3) nivelul rețelei medicale; (4) nivelul infrastructurii de utilități (pornindu-se de la nivelul „under-ground” până la nivelul rețelelor aeriene); (5) nivelul rețelei educaționale și culturale; (6) nivelul rețelei entităților economice și de business; (7) nivelul Paulina Mitrea Paulina.Mitrea@cs.utcluj.ro de habitat axat pe conceptul de ”next generation housing”, adică clădiri inteligente aferente conceptului de “smart city”.

Coordonator of Innovation group @ ClujIT Cluster Ținta finală vizată prin intermediul proiectului este perfect convergentă și corelată unui alt obiectiv major al cluster-ului ClujIT, anume realizarea proiectului „Cluj Innovation City”1, având targetul definit pentru un orizont de 15-20 ani, proiect ce Andrei Kelemen andrei.kelemen@clujit.ro are deja sprijinul autorităților locale (Primarie, Consiliu Judetean, Prefectura, ADR NV etc). Iar ca un punct de reper, întreaga Director executiv @ IT Cluster abordare a proiectului vizează targetul definit la nivel european și mondial, având ca orizont anul 2020, privind conceptul de EcoSmart City2.

1 http://www.clujinnovationcity.com/ 2 h t t p : / / s e t i s . e c . e u r o p a . e u / i m p l e m e n t a t i o n / t e c h n o l o g y - r o a d m a p / european-initiative-on-smart-cities http://www.woodsbagot.com/project/langfang-eco-smart-city/ http://www.eco-business.com/news/smart-cities-better-world/ http://www.europeanvoice.com/folder/europescities/230.aspx?gclid=CNmHl4OFlboCFY_ KtAod3TYATw

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

www.todaysoftmag.ro | nr. 23/Mai, 2014

7

eveniment

H

How to Web lansează MVP Academy, program de pre-accelerare pentru startup-urile din regiune

ow to Web lansează MVP Academy, program de pre-accelerare adresat startup-urilor din Europa Centrală şi de Est. În perioada 2 iunie – 22 iulie echipele care dezvoltă produse inovatoare în domeniul tehnologiei pot aplica pentru participarea în program completând formularul de înscriere disponibil online la www.mvpacademy.co.

Startup-urile din Europa Centrală şi de Est sunt renumite pentru talentul lor tehnic, însă nu dispun întotdeauna de cunoştinţele de business necesare pentru a-şi transforma ideile în produse de succes pe piaţa globală. În acest context, How to Web lansează MVP Academy, program de pre-accelerare care le oferă antreprenorilor din regiune cunoştinţele necesare pentru a dezvolta produse de succes la scară globală, pentru a-şi dezvolta afacerile mai rapid şi pentru a profita de oportunităţile existente pe piaţă.

How to Web MVP Academy se va desfăşura în perioada 2 iunie – 22 iulie la TechHub Bucharest şi va reuni 14 echipe cu potenţial din regiune. Pe lângă componenta educaţională, echipele finaliste vor beneficia, pe toată durata programului, de spaţiu de co-working, mentorat, acces la comunitatea tech la nivel internaţional şi conexiuni cu investitori de tip angel, programe de accelerare şi fonduri de investiţii early stage. Astfel, experienţa How to Web MVP Academy va ajuta startup-urile să profite de oportunităţile pe care le au la dispoziţie pentru a-şi transforma produsele în afaceri de succes.

Programul se adresează startup-urilor din domeniul tehnologiei (echipe sau persoane) care au mai puţin de doi ani de activitate, au dezvoltat cel puţin un prototip funcţional al produsului, nu au obţinut până în momentul înscrierii finanţări mai mari de 50.000 EUR şi nu au mai participat la un alt program de accelerare. Produsele dezvoltate trebuie să fie în domeniul software, hardware, internet of things, mobile, robotică, biotech, medtech sau ecommerce. How to Web MVP Academy este un program dezvoltat în parteneriat cu Microsoft, Romtelecom şi Cosmote cu sprijinul Bitdefender, Raiffeisen Bank, Hub:raum şi TechHub Bucharest.

Pe parcursul celor șapte săptămâni ale programului, cele 14 echipe finaliste vor participa la workshop-uri practice şi vor acumula competenţe cheie pentru un startup: noţiuni de business, finanţare, aspecte legale, dezvoltare de produs, storytelling, marketing, dezvoltarea de comunităţi, networking sau pitching. În plus, aceştia vor beneficia de sesiuni de mentorat şi vor avea ocazia să discute în mod direct cu specialişti şi antreprenori consacraţi la nivel local, regional şi internaţional.

Progresul echipelor participante la How to Web MVP Academy va fi monitorizat prin urmărirea unor indicatori cheie pentru performanţă, susţinând astfel creşterea accelerată a acestora. Printre beneficiile de care se vor bucura finaliştii programului se numără accesul la infrastructură tech oferită de companii internaţionale (cloud hosting sau acces gratuit la diferite platforme), acces la spaţiul de co-working, comunitatea şi evenimentele TechHub Bucharest, conexiuni cheie în industrie şi susținere continuă pentru dezvoltarea propriilor startup-uri pe toată durata programului.

How to Web MVP Academy va aduce în faţa echipelor peste

8

nr. 23/Mai, 2014 | www.todaysoftmag.ro

40 de mentori având competenţe relevante pentru etapa de dezvoltare în care se află acestea: fondatori de startup-uri, echipe care au trecut prin programe de accelerare, specialişti în business şi dezvoltare de produs sau investitori early stage. Printre aceştia se numără Jon Bradford (Managing Director, Techstars), Florin Talpeş (Co-fondator şi CEO, Bitdefender), Cosmin Ochişor (Business Development Manager, hub:raum), Gabriel Coarnă (Architect, Evernote Clearly), Adrian Gheară (Co-fondator NeobyteSolutions, business angel şi advisor pentru mai multe startup-uri), Bobby Voicu şi Cristi Badea (Co-Fondatori Mavenhut şi absolvenţi ai programului de accelerare Startup Bootcamp) sau Daniela Neumann (Scrum Master/Change Management idealo internet GmbH). Lista completă a mentorilor care vor ghida paşii echipelor admise în How to Web MVP Academy este disponibilă online la http://mvpacademy.co/ mentors.

Programul se va încheia marţi, 22 iulie, cu Demo Day, eveniment în cadrul căruia echipele îşi vor prezenta produsele şi progresul înregistrat în faţa unui juriu format din investitori de tip angel, fonduri de investiţii early stage şi reprezentanţi ai unora dintre cele mai apreciate programe de accelerare la nivel european.

Astfel, startup-urile vor avea ocazia să obţină finanţări ulterioare şi să îşi continue dezvoltarea şi după finalizarea programului.

Cele 14 echipe finaliste vor participa gratuit la How to Web MVP Academy şi nu vor trebui să cedeze acţiuni în schimbul participării. Înscrierile se realizează online la www.mvpacademy.co, până sâmbătă, 17 mai. Aplicaţiile vor fi evaluate de un juriu de specialitate, luând în considerare echipa şi experienţa acesteia în domeniu, dimensiunea pieţei şi tendinţele din industrie, tracţiunea iniţială, fezabilitatea şi scalabilitatea produsului. Câştigătorii vor fi anunţaţi vineri, 23 mai.

Mediatizarea programului este asigurată de Goal Europe, Netokracija, IT Dogadjadi, Digjitale, Entrepreneur.bg, Newtrend. bg, Adevărul Tech, Forbes România, Wall-Street.ro, Business Cover, Manager Express, Business Woman, Market Watch, Ctrl-D, PC World, Computer World, Gadget Trends, Today Software Magazine, Agora, Yoda.ro, Incont.ro, România Liberă, Zelist Monitor, Comunicatedepresa.ro şi Times New Roman.

Irina Scarlat

irina.scarlat@howtoweb.co Co-Fondator al Akcees @ How To Web

TODAY SOFTWARE MAGAZINE

www.todaysoftmag.ro | nr. 23/Mai, 2014

9

eveniment

Topconf Bucharest 2014

M

Conferinţa internaţională de software, 11- 12 iunie 2014, Bucureşti

anagementul cunoaşterii nu se mai poate imagina fără Internet, fără capacitatea acestuia de a stoca cantităţi enorme de date, de a face schimb de informaţii în legătură cu progresele şi tendinţele, de a stabili contacte şi de a crea relaţii de afaceri.

Dar un schimb intensiv de know-how şi experienţe cere, de asemenea, o familiarizare personală, iar aceasta este ceva ce Internetul singur nu poate să ofere. Din acest motiv, conferinţele tehnice specializate, cum este şi Topconf Bucharest, sunt un factor cheie atunci când vorbim despre un transfer dinamic de know-how peste graniţele tehnice, naţionale şi culturale.

Topconf Bucharest este o conferinţă internaţională care serveşte drept locul de întâlnire numărul 1 pentru dezvoltatorii de software şi specialiştii IT, unde ei pot schimba informaţii despre ultimele progrese, tendinţe actuale şi aspecte importante ale tuturor tehnologiilor software. Topconf Bucharest oferă un mediu propice stabilirii și întăririi de contacte între dezvoltatori, arhitecţi, decidenţi IT şi consultanţi din toată Europa, cât şi din restul lumii.

Varietatea de subiecte la Topconf Bucharest 2014 este la fel de vastă ca şi tehnologiile, întinzându-se de la Securitate la Mobile, de la Agile la Managementul de Proiect şi Dezvoltarea Produsului şi Management. Topconf Bucharest 2014 pavează drumul pentru schimbul de experienţe peste şi dincolo de toate graniţele. Pentru ca specialişti din întreaga lume să participe la un astfel de schimb, ei trebuie să beneficieze de un punct de întâlnire şi de formare a unor legături de afaceri. Topconf Bucharest este locul potrivit pentru această formă de comunicare globală, engleza fiind limba oficială de conferinţă a Topconf Bucharest.

Iată de ce Topconf Bucharest va fi centru lumii software în iunie 2014: • Pre-conferinţă de o zi, cu program tutorial în legătură cu practica; • Două zile de conferinţă principală cu vorbitori extrem de valoroşi despre toate subiectele legate de dezvoltarea Software; Patru track-uri tehnice paralele în ambele zile; • Facilităţi de expunere pentru platforme, instrumente şi programe de instruire suplimentară; • Evenimente şi activităţi oficiale de formare a unor legături de afaceri; • Platformă de comunicare eficientă pentru expozanţi şi sponsori din comunitatea naţională şi internaţională de Software.

Topconf Bucharest 2014, dintr-o privire Eveniment: Conferinţa internaţională IT.

Punct central Tehnologii de dezvoltare şi Project Management ⁄ Agile⁄ Managementul Produsului.

Date importante: 11 – 12 iunie 2014, zile de conferinţă, 10 iunie: Tutoriale, 13 iunie: Seminar Windows Azure.

10

nr. 23/Mai, 2014 | www.todaysoftmag.ro

Website: http:⁄⁄topconf.com⁄bucharest-2014⁄ pentru participanţi, vorbitori, expozanţi şi mass media.

Locaţie: Bucureşti, România – Ramada Parc.

Participanţi: Specialişti IT din România şi din ţările învecinate, din Europa şi de peste ocean.

Caracteristici speciale: • Primul şi unicul eveniment de mare anvergură de acest tip din România; • Largă varietate de subiecte, vorbitori de top din comunitatea mondială de Software; • Platformă de expoziţie; • Program suplimentar (eveniment social) în conformitate cu interesele speciale ale participanţilor.

Subiecte • Siguranţa, • Testarea, • Mobile, • Management de proiect, • Agile şi Lean, • Modern şi de viitor, • Dezvoltarea şi managementul produsului, • Cloud computing, • Experienţa utilizatorului.

Sponsori Qualitance, Bucharest, Romania; Nortal, Romania and Estonia; Microsoft, USA; Nokia, Finland.

Organizat de Topconf OU, Tallinn, Estonia topconf.com Chris Frei

frei@topconf.com Organizer @ TopConf

TODAY SOFTWARE MAGAZINE

startups

Comunitatea locală în JavaScript se întâlnește pe 3 iunie la București!

J

SCamp este primul eveniment dedicat comunității de JavaScript din România. La prima ediție reunește experții JavaScript internaționali și locali, ce vor împărtăși timp de o zi secretele „celui mai popular limbaj de programare web”.

Primul eveniment de webdesign pe care Evensys l-a organizat în toamna anului trecut, Smart Web Conference, a primit un val de aprecieri din partea comunității locale de profesioniști în domeniu, dar și de la practicieni din țări precum Germania, Bulgaria și Ungaria.

Fe e db a c k - u l p o z it i v d i n p a r t e comunității web din România, ne-a determinat ca anul acesta să lansăm prima ediție a evenimentului JSCamp, care să răspundă interesului mare pentru evenimentele pe zona de web design și front- end development.

Prima ediție a evenimentului JSCamp România va avea loc pe 3 iunie, 2014 la JW Marriott Grand Hotel și va cuprinde patru sesiuni de conferințe intensive despre tendințele în web development, studii de caz, tehnologii open- web, metodologii și tool-uri avansate.

Evenimentul se va bucura de prezența a doi dintre cei mai buni specialiști internaționali în JavaScript, Robert Nyman, Technical Evangelist, Mozilla și Vince Allen, Software Engineering Manager, Spotify. Robert Nyman, Mozilla, deține o experiență de 14 ani în front end development, el va susține o prezentare despre noile abordări în web design și experiențele întâlnite în procesele de dezvoltare web. Vince Allen, Spotify, va oferi participanților o prezentare inedită, arătându-le cum poate fi folosit JavaScript într-un mod mai creativ.

Printre ceilalți vorbitori care vor participa la eveniment se regăsesc: Martin Kleppe, Co-fondator și Head of Development în cadrul companei Ubilab, companie care dezvoltă aplicații bazate pe Google Maps API; Sebastian Golasch, Specialist Senior

Manager Software Developer la Deutsche Detalii suplimentare despre eveniment Telekom, de-a lungul timpului a dezvoltat sunt disponibile și pe adresa jscamp.ro aplicații cu JavaScript, PHP și Ruby; Phil Hawksworth, R/Ga, JavaScript developer care este specializat în dezvoltarea site-urilor Web de la sfârșitul anilor ’90; Patrick H. Lauke, Accessibility Consultant, The Paciello Group; Tero Parviainen, Specialist Independent în software cu peste 12 ani de experiență și Kenneth Auchenberg, technical lead la GoToMeeting Free at Citrix.

Prin seria de evenimente dedicate web developer-ilor locali și internaționali pe care le organizăm, ne-am propus să reunim Iunieta Sandu iunieta.sandu@evensys.ro comunitatea specialiștilor în IT și să le oferim noi posibilități de colaborare. JSCamp PR & Marketing Coordinator @ Evensys România va fi despre cele mai noi trenduri în materie de programare web, despre networking și know-how internațional.

www.todaysoftmag.ro | nr. 23/Mai, 2014

11

eveniment

A 5-a ediție de ”mamuți” Agili s-a încheiat la Cluj-Napoca!

Î

n perioada 4-5 aprilie, Colors in Projects, în parteneriat cu Today Software Magazine, au ieșit în întâmpinarea clujenilor pentru a treia oară cu evenimentul ...even mammoths can be Agile.

Ca element de noutate, în cadrul acestei ediții, am avut două stream-uri în paralel, precum și sesiuni World Café. Participanții au putut alege la ce prezentări să asiste, în funcție de subiectul de interes pentru ei. În cadrul primului stream, prezentările s-au axat pe partea ‘hard’ a domeniului Agile, iar în cel de-al doilea, pe zona de ‘soft skills’. În cadrul sesiunilor World Café din cele două stream-uri, participanții au fost invitați la dezbatere, pe teme diferite, alături de speaker-ii de la eveniment, care au moderat cele șase grupuri formate.

Ghidaț i de cei doi mo derator i sprințari, Dan Rădoiu și Adina Grigoroiu, participanții, în număr de peste 200 au avut ocazia să dezbată, împreună cu speakeri locali și internaționali, fiecare împărtășind din experiența proprie.

Au fost alături de noi trei speakeri internaționali: Mihael Nir, Andrea Provaglio și Reiner Kuehn.

Michael Nir ne-a prezentat câteva dintre secretele unui Product Owner de succes (printre acestea numărânduse competențele de Business Analysis), rolul său vital în procesul de dezvoltare organizațională, precum și harta după care trebuie să se ghideze în drumul către excelență.

Andrea Provaglio ne-a povestit despre schimbările culturale majore întâlnite în gestionarea proiectelor bazate pe cunoaștere, precum strategiile și modelele mentale necesare pentru a face față unui nivel ridicat de incertitudine. Am discutat de asemenea despre efemeritate, incertitudine, cunoaștere și nevoia de restructurare a creierului în contextul actual.

Reiner Kuehn ne-a explicat cum și de ce este important să folosim rezervele de timp (slack) în conducerea proiectelor Agile, ce impact au aceastea asupra inovației și motivării, precum și despre provocările folosirii lor într-un mediu în care utilizarea resurselor reprezintă un KPI, iar managerii măsoară progresul în funcție de numărul de caracteristici livrate.

12

George Anghelache & Cristian Cazan ne-au încântat cu o altfel de prezentare: imitând celebrele personaje, Luke Skywalker și Darth Vader, s-au luptat cu săbii laser în provocarea de a transforma galaxia IT conform principiilor Agile. De asemenea, au pus în scenă diferite situații cu care se confruntă un Scrum Master, oferind pentru fiecare dintre acestea soluții pentru îmbunătățirea comunicării și a activităților.

De la Ruxandra Banici am aflat că metoda aleasă pentru conducerea proiectului (fie că vorbim despre Scrum sau alta) trebuie ajustată continuu în funcție de nevoile proiectului, încercând, în același timp, să să schimbăm contextul astfel încât acesta să susțină metoda de bază. Totul se realizează urmând un set clar de principii.

Prin analogii cu exemple din viața de zi cu zi, Oana Oros ne-a adus în atenție câteva lacune ascunse în comunicarea dintre actorii Agile. Acestea pot apărea pe mai multe niveluri precum: analiză, dezvoltare, testare, leadership, management...

Andrei Doibani ne-a vorbit despre c um f unc ț ione ză pro cesu l de adoptare a metodologiei Agile in industriile cu reglementări foarte stricte, dar și despre abordările hibrid, precum Water-Scrum-Fall.

Izabella Paun și Danielle PopescuAbrudan ne-au arătat cum merge afacerea din spatele scenei, cum au colaborat un Delivery Manager împreună cu un Project Manager și cum metoda Agile le-a ajutat să construiască succesul într-o structură extrem de complexă.

Adrian Lupei a expus principiile metodei Kanban. El ne-a explicat cum, prin implementarea Kanban-ului în Bitdefender, procesele de lucru au fost îmbunătățite, vizibilitatea activității a crescut, iar echipele au început să colaboreze mai bine.

Dan Berteanu ne-a provocat la dezbatere adresându-ne întrebarea: care sunt criteriile pe care ne bazăm în luarea deciziilor, atunci când acestea au implicații majore

nr. 23/Mai, 2014 | www.todaysoftmag.ro

de natură etică? Prin aducerea în atenție a două dintre cele mai cunoscute experimente de natură etică – Problema troleului și cea a prizonierului – Dan a reușit să creeze o atmosferă plină de bună dispoziție.

Călin Damian ne-a argumentat importanța alegerii instrumentelor potrivite în procesul de adaptare al organizațiilor la noile cerințe privind puterea de procesare și de stocare, schimbări care au un impact major asupra echipelor de dezvoltare software, de asigurare a calității și de suport.

Simona Bonghez a prezentat deciziile luate în proiecte și consecințele lor asupra evoluției unui proiect. Am aflat de la Simona care sunt punctele cheie de decizie în timpul ciclului de viață al unui proiect, pe ce modele de decizie ne putem baza, dar și care sunt acei factori care influențează procesul de luare a deciziilor al unui manager de proiect.

Am încheiat cu multe cadouri și surprize pentru cei prezenți în sală, apoi am mers cu toții la cocktail în ritm de dans, acompaniați de trupa The Glass Fish (care timp de o ora ne-au încântat cu cover-uri unul mai frumos decât celălalt) dar și de multe baloane colorate însoțite de zâmbete și multă, multă voie bună!

A doua zi au avut loc două Workshopuri: Managementul Conflictelor susținut de Simona Bonghez și Kanban, în practică susținut de Adrian Lupei, ambele depășind numărul limită de participanți.

Vom reveni cu drag și anul viitor în Cluj pentru a patra oară. Vă invităm să accesați imagini din cadrul evenimentului pe pagina noastră de Facebook/Colors in Projects.

Vă așteptăm cu drag la evenimentele noastre din Iași - 10-11 octombrie și Cluj - în primăvara anului viitor!

Adina Grigoroiu, CAPM adina.grigoroiu@confucius.ro Trainer și consultant @Colors in Projects

comunități

TODAY SOFTWARE MAGAZINE

L

Comunităţi IT

una mai și începutul lui iunie este perioada în care au loc de obicei cele mai importante evenimente din prima parte a anului. Vă recomandăm în Cluj concursul pentru programatori Catalyst CC și prima ediție a Techsylvania fără a uita de deja clasicele: IT Camp și Romanian Testing Conference. În București, vă recomandăm I T.A.K.E. Unconference, JS Camp și TopConf iar pe cei din Brașov îi așteptăm la un prim eveniment de lansare a revistei în orașul lor. Dacă nu v-ați făcut deja un plan va propunem să luați în considerare sugestiile de mai jos.

Calendar

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

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

Website: www.facebook.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 1434/Nr. Evenimente: 18 GeekMeet România Comunitate dedicată tehnologiilor web.

Website: geekmeet.ro Data înfiinţării: 10.06.2006 / Nr. Membri: 606 / Nr. Evenimente: 17 Cluj.rb Comunitate dedicată tehnologiilor Ruby.

Website: www.meetup.com/cluj-rb Data înfiinţării: 25.08.2010 / Nr. Membri: 175 / Nr. Evenimente: 40 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: 428 / Nr. Evenimente: 55 Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice.

Website: www.meetup.com/Cluj-Semantic-WEB Data înfiinţării: 08.05.2010 / Nr. Membri: 176/ Nr. Evenimente: 23 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: 239/ Nr. Evenimente: 14 Tabăra de testare Un proiect care își dorește să strângă cât mai mulți oameni care lucrează ca și testeri.

Website: tabaradetestare.ro Data înfiinţării: 15.01.2012 / Nr. Membri: 303/ Nr. Evenimente: 31

Mai 12 (Cluj) Lansarea numărului 23/mai al Today Software Magazine www.facebook.com/todaysoftmag Mai 13 (Timișoara) Functional Programming meetup linkedin.com/groups/FP-meetup-Timisoara-13-mai4338166.S.5865381911513300994 Mai 15-16 (Cluj) Romanian Testing Conference www.romaniatesting.ro Mai 16 (Cluj) Catalysts Coding Contest contest.catalysts.cc Mai 17-24 (Cluj) Starcelerate cluj.startcelerate.com Mai 22-23 (Cluj) IT Camp www.itcamp.ro Mai 29-30 (București) I T.A.K.E. Unconference 2014.itakeunconf.com Mai 30 (Brașov) Lansarea numărului 23/mai al Today Software Magazine www.facebook.com/todaysoftmag Mai 31 (Cluj) Techsylvania hackaton - recomandarea TSM techsylvania.co Iunie 2 (Cluj) Techsylvania conference techsylvania.co Iunie 3 (București) JS Camp www.jscamp.ro Iunie 10-13 (București) TopConf 2014 topconf.com/bucharest-2014/ www.todaysoftmag.ro | nr. 23/Mai, 2014

13

programare

Livrarea aplicațiilor mobile de succes

M

-am gândit în ultima vreme la ceea ce înseamnă să creezi/livrezi o aplicație pentru dispozitive mobile de succes. Competiția pe piața din ziua de azi e atât de acerbă, încât trebuie să creezi nu mai puțin decât cea mai bună aplicație posibilă pentru a rămâne „în joc”. Sunt inginer SQA în lumea mobile de patru ani, deci pentru mine a livra o aplicație bună e cu adevarat foarte important.

Larisa Gota

lgota@smallfootprint.com QA Engineer @ Small Footprint

Nu cred că mai există aplicații de succes pe web care să nu fi fost portate pe mobil. Din 2011, când platforma mobilă a ajuns într-un punct critic, e într-o continuă creștere. Doar pentru a vă da un exemplu, anul trecut numărul de utilizatori ai aplicației Facebook pe dispozitive mobile a crescut peste numărul de utilizatori activi de web1. Nu cred că mai e nevoie să detaliez această știre; cu siguranță toată lumea a aflat asta până acum.

Ce este o aplicaţie de succes?

Pentru mine, ca utilizator, o aplicaţie de succes trebuie să fie utilă, să încânte, să fie uşor de folosit şi, bineînţeles, să fie în topul celor mai bine clasate aplicaţii de pe piaţă. În calitatea mea de QA, aplicaţiile de succes sunt cele care încântă printr-un design plăcut, care au o performanţă bună (rapidă, fluentă) şi nu au bug-uri (pe cât posibil).

Crearea de aplicații utile, inovatoare nu e tocmai o știință exactă și e chiar imposibil de anticipat ce idee v-ar putea aduce faimă, succes și mulți bani. Atât aplicațiile foarte utile, cât și cele create din hobby, sau create pentru cineva care dorește să-şi „piardă” timpul, pot ajunge să fie de mare succes și să fie descărcate de mii de utilizatori. Există o mulțime de exemple de persoane care au căutat succesul și l-au găsit, însă există și persoane care au creat 1 h t t p : / / w w w . b u s i n e s s i n s i d e r . c o m / facebook-mobile-bigger-than-desktop-2013-1

14

nr. 23/Mai, 2014 | www.todaysoftmag.ro

prima aplicație din viața lor, din pasiune sau doar pentru a-și dovedi lor înșiși că sunt în stare s-o creeze. Un exemplu foarte popular este „Angry Birds”, care a devenit un fenomen.

Astăzi găsim aplicaţia pe toate platformele (fie mobile, fie web), filme, jocuri etc. .

Foarte populare în zilele noastre sunt jocurile care ajută utilizatorul “să piardă” vremea într-un mod plăcut, aşa cum este ”Candy Crush Saga”, un joc de care lumea e încă obsedată. Există poveşti cu un sfârşit fericit, pentru dezvolatori precum cei care au creat ”Threes”, “Luckiest Wheel” sau popularul ”2048”, oameni care nu au anticipat succesul aplicaţiilor lor; există însă şi oameni ce nu au putut face faţă presiunii. Probabil cel mai elocvent exemplu este “Flappy Bird”. Dacă nu aţi reuşit până acum să vă jucaţi acest joc (originalul), acum e cam târziu. Dezvoltatorul lui (Dong Nguyen) l-a retras atât din App Store cât şi din Google Play, motivând că viaţa i s-a complicat mult prea tare. El a susţinut că a ajuns să câştige până la 50.000$/zi numai din reclame de tip “in-app”. Intenţionat sau nu, anunţul său (cu privire la retragerea jocului ) a devenit ceva ce poate fi considerat cel mai ingenios act de marketing din istoria magazinelor virtuale de aplicaţii mobile, întrucât numărul lui de descărcări a explodat după postarea anunţului pe site-urile de socializare.

Se găsesc însă acum o grămadă de cópii ale

www.todaysoftmag.ro | nr. 21/Martie, 2014

management

TODAY SOFTWARE MAGAZINE

acestei aplicaţii pe toate platformele, fiecare înclinate în favoarea încercând să egaleze succesul originalului. aplicațiilor native. Nu ne permitem să ignoDe unde începem? răm acest trend cu Dacă sunteți programatori/ QA ușurință. O parte din implicați într-un proiect, atunci presupun ceea ce alimentează că detaliile aplicației, schițele, cerințele și această ascensiune a specificațiile vă sunt deja cunoscute și astfel experienței mobile aveți deja un avantaj. În caz contrar, citiți în u n i c e : apl i c aț i i l e continuare câteva principii simple, menite native și experiența a vă ajuta să începeți: de utilizator atât • O aplicație pentru dispozitive mobile de bogată asociată inteligente trebuie să rezolve o problemă, cu acestea. Pentru fie că e o aplicație foarte utilă sau e doar că există o sumă un joc. uimitoare în joc, • Concentrați-vă pe un singur lucru, at ât Apple cât și dar faceți-l bine. Fiți clari cu privire Google se asigură la ceea ce face aplicația; ar trebui să fie ca sistemele lor de capabilă a se rezuma ca „one-liner”. operare sunt actua• Măsurați-vă propriile abilități și inte- lizate permanent și rese pentru a rezolva o problemă de zi că sunt compatibile cu zi și a o face mai bine, sau cu o mică cu cele mai noi, cele diferență. Există o mulțime de aplicații mai bune featurecreate până acum. Nu pierdeți efort și uri de pe piață. Aici timp clonând ceva ce există deja. Aceasta apl i c aț i i l e n at ive nu înseamnă desigur că nu puteți câștigă din nou, penîmbunătăți o aplicație deja creată, dar tru că ele beneficiază urmăriți să găsiți o nouă soluție pentru de toate actualizările aplicație, ceva mai bun, mai distractiv de sistem și inovațiile sau care adaugă o nouă dimensiune. Cu rapid lansate, într-un alte cuvinte, să aducă de fiecare dată ceva mod care pare pur nou. și simplu imposibil aplicațiilor web.

Mergeți pe aplicații native.

Facebook, LinkedIn și-au schimbat aplicațiile și s-au orientat pe nativ, iar aceasta nu este o întâmplare, căci decizia a venit în urma unui studiu de piață.

Sunt conștientă că dezvoltarea unei astfel de aplicații poate părea o sarcină descurajantă, dar trebuie să știți că atunci când se face comparația și se trage linie, beneficiile dezvoltării unei aplicații hibride de web sunt cu mult depășite de adevăratele beneficii ale experienței unei aplicații native. Cei mai importanți factori, monetizarea, performanța, experiența de utilizator, securitatea, toate sunt puternic

http://www.teqarazzi.com/wp-content/ uploads/2013/05/apple-vs-android-vs-windows.png

Pentru ce plaformă să dezvoltăm prima oară? Alegeți-vă prima platformă cu grijă.

Când vine vorba de crearea aplicațiilor native, dezvoltarea pentru toate platformele deodată nu e o • utilizatorii iOS tind să fie mult mai idee prea bună. De fapt, cel mai bine e să captivaţi, mai interesați de aplicațiile noi; se înceapă cu una. Credeți sau nu, alegerea • utilizatorii iOS sunt mult mai dispuși primei platforme pe care să se facă dezvolsă plătească pentru aplicații. tarea ține mai mult de comportamentul utilizatorului final și are mai puțin de-a Există însă și situații în care Android face cu capacitățile fiecărei platforme în pare a fi o opțiune mai bună: parte. Până acum iOS și Android au reușit • atunci când ați identificat acea nișă să atingă niveluri remarcabile și fiecare de utilizatori Android dispuși să plăsă-și țină aproape nișa proprie de utilizatească pentru aplicații sau dacă urmăriți tori. Dacă ați ajuns într-un punct în care nu distribuirea în cadrul unei companii; vă puteți hotărî pe care din ele s-o alegeți • atunci când nu sunteți siguri că prima, atunci dați-mi voie să vă ajut. aplicația poate trece de exigențele impuse De cele mai multe ori iOS se prezintă de Apple; mai bine ca primă opțiune: • atunci când nu vă permiteți costurile • pentru că Android e un sistem inițiale necesare pentru dezvoltarea unei fragmentat, iar dezvoltarea pentru iOS aplicații pe iOS (un Mac, cont de prograimplică mai puțină muncă; mator – necesare doar pentru a începe). www.todaysoftmag.ro | nr. 23/Mai, 2014

15

programare Livrarea aplicațiilor mobile de succes Bineînțeles că toate acestea sunt valabile doar în cazul în care vă creați propria aplicație. În schimb, dacă lucrați pentru un proiect, atunci mai toate vă sunt aranjate, însă chiar și așa există câteva ponturi bune de luat în calcul, care să vă ajute în final atât pe dumeavoastră, cât și pe client: • Dacă ține de voi cu ce platformă începeți, sfatul meu ar fi să începeți cu cea care vă e mai comodă, cea cu care sunteți deja obișnuiți.

• Urmați guideline-urile și principiile lor şi astfel sigur veți obține o aplicație robustă.

• Chiar dacă aveți schițe foarte bine detaliate, e perfect normal să se devieze puțin de la ele pe parcursul dezvoltării; a crea aplicaţia după cele mai noi designuri e cât se poate de logic.

• Faceți cercetări prima oară să vă asigurați că sunteți la curent cu toate noutățile, pentru că platformele se întrec în a optimiza și scoate versiuni noi în mod constant. Nu vă fie teamă să folosiți elemente noi, ele pot rezolva probleme cheie pentru soluția voastră. Întotdeauna încercați să găsiți cele mai bune soluții din punctul de vedere al utilizatorilor, pentru că în cele din urmă ei vor fi cei ce vor utiliza aplicația pe scară largă.

QA-ul e implicat din ce în ce mai mult în crearea şi stabilirea documentelor cu specificaţii, în estimări, deci e foarte important să fie la curent cu tot ceea ce e nou.

Dacă sunteţi QA, fiţi pregătiţi să vă exprimaţi opiniile, îngrijorările, ideile, dar mai ales să vă puteţi întotdeauna motiva punctele de vedere.

Nu copiați elemente de pe alte platforme.

Chiar dacă nu vă dați seama de peacuma, una din cele mai grele probleme e ”portarea” aplicației de pe o platformă pe alta. Oricât de tentantă e crearea unei aplicații care să arate și să funcționeze la fel pe toate platformele, trebuie să ținem minte că fiecare platformă în parte are caracteristicile ei, așa că e foarte posibil să nu puteți menține totul așa cum vă doriți. Nu încercați să faceți în așa fel încât aplicațiile să arate identic pe toate platformele și în nici un caz nu copiați elemente specifice de pe o platformă pe alta, doar pentru că arată bine. Nu numai că e o experiență proastă pentru utilizatorul obișnuit cu elementele specifice platformei pe care o folosește, dar e foarte probabil ca în final să fiți nevoit să faceți atât de multe compromisuri încât

16

ultima soluție să fie re-crearea aplicației de la zero, iar acesta implică timp, bani şi resurse. De exemplu un ”ActionBar” din Android nu va putea fi înlocuit cu succes de un ”ApplicationBar” din Windows Phone sau ”NavigationBar” pe iOS. Deci, nu e suficientă identificarea elementelor corespondente dintr-o platformă în alta. Întreaga structură trebuie regândită și refăcut designul.

De asemenea, este foarte puțin probabil ca un utilizator să folosească aplicația pe mai multe platforme deodată; dar chiar și asa, odată obișnuit cu un sistem de operare, el se va aștepta ca aplicația să se comporte într-un anume fel. Fiți flexibili și încercați să creați aplicația cât mai flexibil, astfel încât în momentul în care vă apropiați de o livrare și mai sunt încă modificări de făcut, să puteți adăuga orice element în timp util, iar aplicația să poată fi lansată la timp.

Odată ce aţi început dezvoltarea unei aplicaţii, nu trageţi de timp. O creaţi, o testaţi şi o puneţi pe piaţă, altfel riscaţi ca tot ceea ce aţi creat până atunci să devină “învechit” şi tot efortul depus până atunci să fie în zadar, pentru că e nevoie din nou de “ajustări” menite a se supune ultimelor guideline-uri. Am experimentat şi eu o situație asemănătoare, cu o aplicaţie dezvoltată intern, care a primit câte o linie de cod atunci când un programator avea timp liber. Astfel dezvoltarea a durat mai bine de un an, iar principiile, guidelineurile s-au schimbat mult, plus actualizările sistemului de operare au “schimbat mult jocul”, astfel încât munca per total a fost cu mult mai mare decât dacă aplicaţia ar fi fost creată, testată şi pusă pe piaţă cât mai repede. Platformele fac actualizări de sistem în mod constant şi aplicaţia are nevoie de ajustări oricum, fie că e în dezvoltare, fie că e deja pe piaţă (în mentenanţă). În timp ce vă străduiţi să dezvoltaţi aplicaţia pentru următoarea platformă, cea care e deja făcută publică vă poate da informaţii prețioase şi poate îndruma spre ceea ce aveţi de făcut în continuare. Deci vă puteţi baza pe utilizatorii/clienții voştri pentru „feedback” şi pentru a vă face o idee despre cum „stă” aplicaţia voastră.

Nu adăugaţi elemente menite să ajute utilizatorul novice.

E important să se facă o distincţie clară între utilizatorul nou al aplicației și utilizatorul nou al platformei. Trebuie să aveţi în minte utilizatorul final şi să încercaţi să acoperiţi nevoile lui. De exemplu, un gest ”Back” e folosit în Android și pe Windows

nr. 23/Mai, 2014 | www.todaysoftmag.ro

Phone pentru a naviga la un ecran anterior, a închide tastatura virtuală, iar în cazul WP8 navigarea spre aplicația deschisă anterior. Deci adăugarea unor butoane pentru navigare, doar pentru că aplicaţia poate părea mai puţin intuitivă unor utilizatori noi ai platformei, nu e cea mai bună idee. Noi trebuie să credem că aplicaţia va fi folosită de oameni inteligenţi și chiar şi utilizatorii noi ai unei platforme vor ajunge să se obişnuiască cu aplicaţia odată ce se obişnuiesc cu sistemul de operare.

Cum ne facem aplicaţia descoperită?

Această secţiune e dedicată atât programatorilor cât şi inginerilor QA. Aceştia din urmă sunt tot mai mult implicaţi în planificarea proiectului, de la specificaţii până la livrare, deci a şti cum să vă faceți aplicaţia descoperită, vă ajută atât pe voi cât şi pe client. Nu putem însă avea control asupra câtorva aspecte, ca de exemplu găsirea aplicaţiei după o căutare în funcție de recenzii sau recomandări, clasificări, după relaţii şi “cross-sell” sau după aplicaţii în trend, dar există câteva moduri în care am putea modifica aceste cifre într-o oarecare măsură, făcând aplicaţia mai captivantă, pentru că, în cele din urmă, acesta e un cerc vicios: cu cât se depune mai mult efort, cu atât aplicația va avea mai mult succes la public.

Există câteva lucruri discutate la conferinţa Google I/O 2013 ce pot fi aplicate şi altor platforme. În primul rând metadata este foarte importantă: • Titlul: trebuie să fie clar, creativ, intuitiv.

• Descrierea: e indicată precizarea cât mai clar și mai concis posibil a obiectivului propus. E bine să ne asigurăm că toată descrierea încape şi pe ecrane mici.

• Capturi de ecran: acestea trebuie să reflecte cele mai bune caracteristici ale aplicaţiei.

• Video: video preview poate fi una din cele mai convingătoare metode (în cazul în care capturile de ecran nu sunt suficiente).

Gândiţi-vă la utilizatorii vizaţi (desigur dacă aveţi). Recenziile lor pot să vă ajute în graficele de clasament. Nu aţi vrea să fiţi traşi în jos de recenziile negative ale utilizatorilor pe care nici nu i-aţi vizat, deci încercaţi să excludeţi această categorie, în cazul în care aplicaţia nu e menită a fi utilizată de toată lumea.

Există cinci lucruri care pot îmbunătăţi

TODAY SOFTWARE MAGAZINE “O reţetă” a succesului unei aplicaţii mobile

Fig. 1 Modelul Kano

procesul descoperirii aplicaţiei2: • Asiguraţi-vă că aveţi ancore web folositoare.

• Încercaţi să creaţi un pachet pentru aplicaţie cât mai mic (nu v-ați dori ca aplicaţia voastră să fie în topul celor care urmează să fie dezinstalate pentru că spaţiul necesar nu permite instalarea unei alte aplicaţii).

• Evitaţi greşelile intenţionate: de genul celor în titlu – Google Play va autocorecta un cuvânt greşit în motorul său de căutare altfel că aveţi toate şansele ca aplicaţia să nu fie gasită din prima încercare tocmai din acest motiv.

• Creați o buclă virală pentru aplicaţie – de exemplu un clasament pe rețele de socializare; aplicaţia poate deveni populară cel puţin în cercul vostru de prieteni.

2 http://software.intel.com/en-us/blogs/2013/10/25/ how-to-get-your-app-discovered-on-google-play-part-one?1

Din punc tu l meu de vedere, cel al unui QA, a crea o aplicaţie de succes înseamnă a crea o aplicaţie robustă, cu o performanţă bună, care încântă, care are un timp d e i n s t a l a re l a utilizator cât mai lung, recenzii bune şi succes la public. Intenţionat sau nu, aplicaţiile menționate la începutul articolului au ceva în comun: toate urmaresc modelul Kano3. În figura alăturată puteţi observa curba de jos ce arată caracteristicile aplicaţiei la care un utilizator se aşteaptă, dar nu sunt neaparat elemente definitorii. Ideea aplicaţiei poate fi bună, dar ne limităm utilizatorii la folosirea unor elemente de bază. În acest fel nu ne vom face remarcați. Furnizând doar necesarul vom rămâne în pătrăţelul din colţul dreapta jos, lăsându-ne utilizatorii indiferenţi.

Curba din mijloc – Performance/ Linear – reprezintă caracteristicile care au o relaţie liniară cu satisfacţia clienţilor. Altfel spus, cu cât oferim mai mult, cu atât mai fericiţi vor fi clienţii. “Flappy Bird” (originalul) a devenit atât de popular pentru că avea ceva ce cópiilor sale le lipseşte: o performanţă bună şi nivele potrivit de dificile.

Nici măcar aplicaţia din care se presupune că programatorul s-a inspirat nu era atât de bună (“Piou Piou vs. Cactus”).

Curba de sus arată caracteristicile care nu sunt aşteptate de client. Prezenţa lor poate să îmbunătăţească satisfacţia clienţilor foarte mult (de exemplu “Angry Birds” – care are foarte multe detalii încântătoare), dar lipsa lor nu ar fi un lucru foarte rău pentru utilizator (de exemplu “2048” –care nu se remarcă prin detalii grafice).

A şti ce caracteristici acoperă necesităţile utilizatorilor, ce i-ar încânta şi care ar fi cele ce îi lasă indiferenţi vă poate ajuta să vă decideţi asupra căror lucruri să vă canalizați eforturile. Atâta timp cât veţi tinde spre colţul din dreapta sus, veţi avea mari şanse de reușită. Desigur, aşa cum am văzut, norocul are mult de-a face cu succesul unei aplicaţii, însă ceea ce e esenţial să reţinem este că, dacă nu ne cumpărăm bilet de loterie, nu vom şti niciodată cum e să câştigăm premiul cel mare; aşa că nu mai staţi pe gânduri şi începeţi acum.

3 h t t p : / / w w w . s h m u l a . c o m / customer-experience-kano-basics-and-shiny-objects/2208/

www.todaysoftmag.ro | nr. 23/Mai, 2014

17

programare

management

Java 8, expresii lambda şi nu numai

E

Silviu Dumitrescu

silviu.dumitrescu@accesa.eu Line manager @ Accesa

18

nr. 23/Mai, 2014 | www.todaysoftmag.ro

ste primăvară...vremea schimbărilor şi a speranţelor... Oracle contribuie la toate acestea cu o nouă versiune a platformei Java standard. Este vorba de versiunea 8, lansată în martie 2014. Începând cu acest număr al revistei Today Software Magazine doresc să modific stilul articolelor pe care le scriu. Nu pot spune că abandonez ideea recenziilor, care reprezintă o sursă importantă de popularizare a cărţilor valoroase din biblioteca IT, dar voi adăuga şi articole cu un grad mai mare de tehnicitate. Urmăresc prin aceasta ca cititorii revistei să fie „stârniţi” în a descoperi ce este nou şi performant în lumea dezvoltării de aplicaţii software.

Mă bucur foarte mult că acest număr este lansat şi în Braşov şi, deşi este prima lansare aici, sper să fie urmată de multe altele.

Braşovul are un potenţial enorm, iar eu iubesc incredibil acest oraş.

Java SE8 este considerată revoluţionară, prin câteva dintre noile caracteristici introduse. Programată iniţial pentru luna septembrie 2013, lansarea a fost amânată pentru martie 2014. Motivele sunt numeroase, dar ţin în special de corectarea bug-urilor şi de îmbunătăţirea securităţii, mai ales pe parte de client, având ca principal motiv JavaFX. Multe sunt modificările şi adăugările făcute în limbaj, dar probabil cea mai spectaculoasă este introducerea abilităţilor lambda.

Acestea sunt văzute ca un important beneficiu în programarea paralelă. De fapt, eforturile pentru creşterea performanţei în programarea paralelă s-au văzut încă din versiunea 7, introducerea framework-ului Fork-Join este un singur exemplu. În prima parte a articolului mă voi orienta cu precădere spre lambda expresii, în partea finală voi prezenta succint un engine JavaScript nou nouţ, pentru ca în articolele următoare doresc să aduc în discuţie şi alte subiecte legate de Java SE8.

O funcţie lambda (funcţie anonimă) este o funcţie definită şi apelată fără a fi legată de un identificator. Funcţiile lambda sunt o formă de funcţii ,,incuibate” (nested functions) în sensul că permit accesul la variabilele din domeniul funcţiei în care sunt conţinute.

Funcţiile anonime au fost introduse de către Alonzo Church în anul 1936, în teoria sa despre calculele lambda1. În limbajele de programare, funcţiile anonime sunt implementate din anul 1958 ca parte a limbajului Lisp. În unele limbajele orientate pe obiect, precum Java, apar concepte similare, precum clasele anonime. Abia în versiunea 8 a limbajului Java sunt adăugate şi funcţiile anonime.

Alte limbaje, precum C#, JavaScript, Perl, Python, Ruby ofereau demult suport pentru acest concept.

Lambda expresiile ne permit să creăm instanţe ale claselor cu o singură metodă într-un mod mult mai compact.

O lambda expresie constă: • dintr-o listă de parametri formali, separaţi prin virgulă şi cuprinşi eventual între paranteze rotunde, • săgeata direcţională ->, • un body ce constă dintr-o expresie sau 1 http://en.wikipedia.org/wiki/Lambda_calculus

TODAY SOFTWARE MAGAZINE un bloc de instrucţiuni.

O interfaţă funcţională (functional interface) este orice interfaţă ce conţine doar o metodă abstractă. Din această cauză putem omite numele metodei atunci când implementăm interfaţa şi putem elimina folosirea claselor anonime. În locul lor vom avea lambda expresii. O interfaţă funcţională este anotată cu @ FunctionalInterface. Pentru a înţelege modul în care se lucrează cu lambda expresii am construit un mic exemplu prin care am creat colecţii de obiecte sortate după diverse criterii. Implementarea interfeţei Comparator a fost făcută într-o clasă anonimă, folosind lambda expresii. Implementarea cu lambda expresii a fost posibilă pentru că în versiunea 8 Comparator este anotată cu @ FunctionalInterface.

Elementul de bază al colecţiei este clasa Product, care este o clasă POJO cu getter-i și setter-i. Clasa conţine două implementări anonime ale comparatorului, determinând sortarea crescătoare respectiv descrescătoare a elementelor colecţiei. package model; import java.util.Comparator; public class Product {

private String name;

private int price;

public String getName() { return name; }

public static Comparator<Product> ascendingPrice = (p1, p2) -> {

return p1.getPrice() - p2.getPrice(); };

public static Comparator<Product> descendingPrice = (p1, p2) -> {

return p2.getPrice() - p1.getPrice(); } }

Clasa de test va aduce ceva în plus faţă de o clasă cunoscută până în versiunea 8. Procesarea colecţiei nu se va face cu un foreach clasic. Ca parte a API-ului Collections avem noul API java. util.stream ce oferă suport pentru operaţii funcţionale pe streamuri de elemente. În exemplul nostru vom folosi o interfaţă de bază a acestui API şi anume Consumer, care reprezintă o operaţie ce acceptă un singur argument de intrare şi nu returnează ceva. Cu Consumer vom putea folosi lambda expresii: import java.util.Set; import java.util.TreeSet; import java.util.function.Consumer; import model.Product; public class TestLambda { public static void processProducts( Set<Product> products, Consumer<Product> block) { for (Product p : products) {

block.accept(p); } } public static void main(String[] args) {

public void setName(String name) { this.name = name; }

Product p1 = new Product(); p1.setName(“onion”); p1.setPrice(10); Product p2 = new Product(); p2.setName(“tomato”); p2.setPrice(20);

public int getPrice() { return price; }

public void setPrice(int price) { this.price = price; }

public void printProduct() { System.out.println(this.toString()); } @Override

public String toString() { return “Product [name=” + name + “, price=” +

price + “]”; }

Set<Product> ascendingPriceProducts = new TreeSet<>( Product.ascendingPrice); ascendingPriceProducts.add(p1); ascendingPriceProducts.add(p2); System.out.println(“In ascending order:”); processProducts(ascendingPriceProducts, p -> p.printProduct()); Set<Product> descendingPriceProducts = new TreeSet<>(Product.descendingPrice);

www.todaysoftmag.ro | nr. 23/Mai, 2014

19

programare Java 8, expresii lambda şi nu numai descendingPriceProducts.add(p1); descendingPriceProducts.add(p2); System.out.println(“\nIn descending order:”); processProducts(descendingPriceProducts, p -> p.printProduct()); }

}

Ca urmare a folosirii API-ului stream operaţiile efectuate pe o colecţie pot fi mult mai complexe decât cele ilustrate în exemplu şi anume: filtrarea după un predicat de selecţie, maparea obiectului filtrat, respectiv executarea unei acţiuni pe fiecare obiect mapat. Eu am prezentat doar ultima operaţie. Acestea se numesc operaţii agregat.

Observaţia pe care vreau să o fac codului anterior este că implementarea comparatorului ţine loc de suprascriere a funcţiei equals(), fapt ce poate fi dovedit prin modificarea, în cod, la valori egale a preţului.

Pe lângă lambda expresii, o caracteristică importantă, evident alături de modificările sintactice şi introducerea de API-uri noi, este dezvoltarea engine-ului JavaScript Nashorn (se pronunţă nazhorn). Prin acesta se pot integra script-uri JavaScript în codul Java clasic. Acest engine se bazează pe standardul ECMAScript 262.

Este un engine scris complet de la zero având ca obiectiv creşterea performanţei. Este astfel, complet diferit faţă de engine-ul deja existent Rhino.

Voi da doar un mic exemplu de folosire a acestui engine, urmând ca în viitor să prezint mai multe detalii: import javax.script.*; public class EvalScript { public static void main(String[] args) throws Exception { // create a script engine manager ScriptEngineManager factory = new ScriptEngineManager(); // create a Nashorn script engine ScriptEngine engine = factory. getEngineByName(“nashorn”); // evaluate JavaScript statement try { engine.eval(“print(‘Hello, World!’);”); } catch (final ScriptException se) { se.printStackTrace(); } } }

20

nr. 23/Mai, 2014 | www.todaysoftmag.ro

Rulând acest exemplu vom obține la consolă Hello, World!.

Ca ultimă observaţie, am folosit pentru editare Eclipse Kepler iar de pe Marketplace am adus Eclipse Java, 8 Support (for Kepler SR2) JDT, PDE 1.0.0. Aceasta, până va apare Eclipse Luna(probabil în mai). Ca versiune de Java am utilizat jdk 1.8.0_05.

Sper că v-am stârnit interesul pentru Java 8 şi ca de obicei aştept cu mare plăcere discuţiile cu cei interesaţi.

Noile mele date de contact sunt: Silviu.Dumitrescu@accesa.eu

management

programare

Qt: Cum m-am îndrăgostit de C++

D

Ambrus Oszkár

oszkar.ambrus@accenture.com Software Engineer @ Accenture

upă mulţi nervi pierduţi prin toate chichiţele și meandrele C++-ului cu OpenGL și MFC, trecerea la C# şi Java a fost ca o adiere de primăvară. Dar într-o zi cu ploaie şi vânt irlandez, într-un cubicle slab iluminat într-un colț de birou, am dat de Qt și o dată cu el o lume minunată de C++ şi-a deschis porţile, cu revelații noi şi noi de atunci încoace. După ce am trecut la Qt, lucrul cu C++ a devenit o bucurie din nou fiind unul dintre mediile în care lucrez cu cea mai mare plăcere. Dezvoltare este o adevărată experienţă, totul rămânând nativ, rapid și ușor de întreținut în același timp.

De Ce Qt?

Qt, cu elementele sale care complementează deficiențele limbajului C++ și framework-ul său cu adevărat multiplatformă care acoperă practic toate necesitățile de bază, rezolvă ambele probleme, asigurând o dezvoltare foarte plăcută și curată. Astfel a devenit Qt standardul de-facto de framework de dezvoltare C++.

Qt e un framework UI și de aplicații cuprinzător. Are un API consistent și curat. Furnizează un mecanism robust de comunicare între obiecte. Este cu adevărat multi-platformă, dar în acelaşi timp reușește să ofere toate funcţionalităţile de nivel scăzut necesare și comportamentele UI native ale sistemelor de operare pe care le sprijină.

Oferă, de asemenea, un set de instrumente de dezvoltare pentru rapid application development (RAD), care pot înlocui sau se pot integra în IDE-uri majore, cum ar fi Visual Studio sau Eclipse. Este profund și bine documentat, are o comunitate mare și puternică în spatele lui și este adoptat pe scară largă. Ar fi indicat să-l folosiţi.

1 Deşi e foarte promiţătoare, în articolul acesta nu discutăm despre noua specificaţie C++11, deoarece – asemena lui Scott Myers, autorul cărţii Efficient C++ , a afirmat odată că avem nevoie de câţiva ani să stabilim cum se poate folosi cel mai eficient şi avem nevoie de experienţă semnificativă pentru a introduce noile elemente în proiecte industriale şi de scară largă.

O Bibliotecă Cuprinzătoare

C++ este unul dintre cele mai folosite limbaje de programare. Are rădăcini istorice puternice și încă este unul dintre cele mai populare limbaje, mai ales acolo unde eficienţa şi performanţa sunt aspecte cheie.

E folosit în medii industriale și în sisteme embedded sau de înaltă performanță, în dezvoltare de aplicaţii, şi multe alte domenii.

C++ e rapid, eficient, multi-paradigmatic, compatibil cu limbajul C, în același timp suportând funcţionalităţi moderne. La aceste calități o adăugăm și pe aceea de a fi simultan un limbaj low-level și high-level.

Există totuși unele probleme. Pe de o parte, limbajul în sine este deseori prea greoi1, flexibilitatea se mai diminuează într-o complexitate adăugată, care cauzează probleme legate de pointere, demonstrând că limbajul nu e chiar multi-platformă. Pe de altă parte, pentru a dezvolta aplicații, avem nevoie de un framework potrivit care se integrează bine în filosofia limbajului și e practic de folosit.

Qt aduce o colecție de biblioteci pentru a satisface toate nevoile de bază în dezvoltarea

www.todaysoftmag.ro | nr. 23/Mai, 2014

21

programare Qt: Cum m-am îndrăgostit de C++ de aplicații. Desigur, cum este cazul cu orice alt framework, Qt nu a fost gândit să satisfacă orice capriciu al oricărui dezvoltator din lume, dar acoperă, practic, tot asemenea un framework general.

Qt are un set de biblioteci numit QtCore, care acoperă, după cum sugerează și numele, un set de funcționalități de bază. Fără a oferi o enumerare exhaustivă, acest pachet de bază include următoarele: • un mediu de aplicație cu event loop şi un sistem de evenimente; • un sistem GUI care este unul dintre cele mai puternice aspecte al Qt. • container-e cu template-uri, cum ar fi listă, coadă, vector și dicţionar. Acestea oferă o alternativă perfectă la container-ele STL, aducând mecanisme de iterare atât în stil Java cât în stil STL, precum și conversie la tipurile corespunzătoare din STL. • clase de management al resurselor; • un sistem model-view pentru decuplarea datelor de reprezentarea vizuală, bazat pe un set de clase abstracte; • un framework de threading, care există şi a fost apreciat de mult timp; • prelucrare de stringuri și expresii regulate; • funcționalități de sistem de operare, cum ar fi procesare de fișiere, printare, funcţionalităţi de rețea și setări de sistem. În plus, există o serie de alte pachete, cele mai multe dintre ele fiind mature și bogate în feature-uri în domeniile respective.

Aceste domenii includ procesare XML, capacități multimedia, suport de baze de date SQL, unit testing, OpenGL, integrare WebKit, biblioteci şi instrumente de internaționalizare, manipulare SVG, comunicare D-Bus, controale ActiveX și altele.

Signals and Slots: un mecanism inovativ de comunicare între obiecte

sunt conştiente de obiectele conectate la ele. De asemenea aspectul type-safe este garantat prin limitarea conexiunilor bazată pe compatibilitatea dintre argumentele de signals și slots.

Un signal e emis atunci când un eveniment trebuie să fie anunțat. Un signal e de fapt o funcţie fără body.

Slot-urile sunt funcţii regulate care sunt apelate ca răspuns la un signal.

Conexiunea este configurată prin intermediul unui apel QObject::connect(), care permite să fie conectate numai acele signals și slots care au argumente compatibile, garantând astfel că totul e type-safe. Obiectele nu sunt conștiente de semnalele la care slot-urile lor sunt înscrise, nici de slot-urile care sunt conectate la semnalele lor, asigurând astfel loose coupling.

Mai jos găsiţi un exemplu1 despre cum o clasă C++ “normală” poate fi extinsă pentru a suporta signals and slots și modul în care se realizează acest comportament.

Declaraţia minimală C++: class Counter { public: Counter() { m_value = 0; } int value() const { return m_value; } void setValue(int value); private: int m_value; };

Extinderea cu elemente specifice Qt: #include <QObject> class Counter : public QObject { Q_OBJECT public: Counter() { m_value = 0; } int value() const { return m_value; }

Qt oferă unele extensii de limbă prin intermediul unor slots: macro-uri care sunt prelucrate de către generatorul de cod public void setValue(int value); numit Meta-object Compiler (MOC). Acest lucru aduce o introspecție run-time mai avansată și posibilitatea de a signals: void valueChanged(int newValue); avea anumite mecanisme speciale în clase care folosesc Qt. Principalul mecanism de acest tip special este comunicarea private: int m_value; între obiecte numit signals and slots. }; Signals and slots oferă o alternativă mai bună la callback-uri, Versiunea Qt are aceeași stare internă, ​​dar pentru a suporta fiind loosely-coupled și type-safe. Acesta înseamnă că, atunci signals și slots, codul a fost extins cu următoarele: când se utilizează conexiuni între signals şi slots, obiectele nu 1 Bazat pe exemplul oficial de la http://qt-project.org/doc/qt-5/signalsandslots.html

22

nr. 23/Mai, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE • Macroul Q_OBJECT , care este obligatoriu pentru toate clasele care doresc să utilizeze signals şi slots.

• Moștenire de la QObject, care este, de asemenea, necesar pentru signals şi slots și pentru multe dintre caracteristicile Qt oferite, cum ar fi proprietățile dinamice, managementul ierarhic al obiectelor ierarhic sau o introspecție run-time mai bună.

• Macroul signals, care definește un signal care poate fi utilizat pentru a notifica lumea exterioară de modificări.

• Macroul public slots, care declară un slot care poate fi folosit pentru a trimite semnale către el.

Aceste macro-uri speciale sunt preluate de către generatorul de cod MOC care generează clasele și funcțiile corespunzătoare care realizează toate mecanismele specifice Qt.

Slot-urile trebuie implementate de către dezvoltatorul aplicației. Mai jos este o posibilă implementare al slot-ului Counter::setValue(): void Counter::setValue(int value) { if (value != m_value) { m_value = value; emit valueChanged(value); } }

Se poate vedea apelul e m i t , care emite un signal În următorul fragment de cod obj2 va fi distrus în timpul valueChanged() cu noua valoare ca argument, de fiecare distrugerii obj1 (notăm, că crearea lui obj2 nu utilizează un dată când o nouă valoare este asignată. copy-constructor, căci aceştia sunt privaţi în QObject).

Mai jos aveţi un exemplu de un fragment de cod despre utilizarea a două obiecte Counter , a și b , în care signal-ul valueChanged() al obiectului a este conectat la slot-ul setValue() al obiectului b :

QObject *obj1 = new QObject(); QObject *obj2 = new QObject(obj1); //this also sets obj1 as the parent of obj2 delete obj1;

Counter a, b; QObject::connect(&a, &Counter::valueChanged, &b, &Counter::setValue); a.setValue(12); // a.value() == 12, b.value() == 12

Implicit sharing se referă la un mecanism intern folosit mai ales pentru container-e Qt și obiecte de mari dimensiuni. El implementează abordarea copy-on-write, adică copiază doar un pointer la structura de date la fiecare asignare, și copiază întreaga structură b.setValue(48); // a.value() == 12, b.value() == 48 de date numai în cazul în care există o operațiune de scriere. Acest lucru garantează că nu sunt create copii redundante a structurilor Observați comportamentul mecanismului signals and slots: mari de date, îmbunătățind astfel performanța .

• Apelarea a.setValue(12) duce la o emitere a sigÎn codul de mai jos se presupune că list1 este o listă foarte nal-ului valueChanged(12) , care va declanșa slot-ul mare. Când este creat list2, list1 nu va fi copiat, doar un setValue() al lui b, adică va apela funcţia respectivă. pointer este copiat în interior, Qt ocupându-se de aceasta în • Aceasta rezultă în emiterea de valueChanged() al lui fundal: b, dar nu se mai întâmplă nimic, din moment ce nu a fost // suppose list1 is a very large list of type conectat la nici un alt slot.

QList<QString>

În diagrama1 de mai sus este arătat modul în care conexiunile sunt formate între diferite obiecte, ca rezultat al apelelor funcției connect():

QList<QString> list2 = list1; QString str1 = list2[100];

Când list2[100] este citit, acesta va fi, de fapt, exact aceeași locație de memorie ca list1[100], din moment ce Managementul Resurselor nici o operație de scriere n-a fost efectuată, iar lista mare nu a Cele două mecanisme de managementul resurselor din Qt fost copiată. sunt ownership hierarchy şi implicit sharing.

Ownership hierarchy constă într-un arbore de obiecte care Cross-platform și Nativ se ocupă de distrugerea descendenților. Ori de câte ori un nou Qt este cu adevărat cross-platform. Acest lucru înseamnă obiect moştenind de la QObject este creat pe heap (folosind un singur codebase și un stream unic de dezvoltare pentru orice new ), acestuia se poate atribui un părinte QObject , ceea ce număr de platforme suportate. Este nevoie doar de a seta diferite va rezulta eventual într-un arbore de obiecte. Ori de câte ori configurații de build pentru a face deployment pe sisteme diferite. un obiect este distrus din arbore, toți descendenții săi sunt de Aceasta a fost una dintre cele mai importante motive pentru care asemenea distruşi.

Qt a fost ales într-un proiect industrial mare la care am lucrat, 2 Din documentaţia oficială de la http://qt-project.org/doc/qt-5/signalsandslots.html

deoarece era necesar să fie suportat pe sisteme embedded bazate www.todaysoftmag.ro | nr. 23/Mai, 2014

23

programare Qt: Cum m-am îndrăgostit de C++ pe Linux, precum și PC-uri Windows.

Sistemele de operare majore suportate sunt Microsoft Windows, Linux și Mac OS X. Alte sisteme include, printre altele, Android , Solaris şi HP UX. Executabile generate sunt cu adevărat native. Qt utilizează elemente GUI native și API-urile de nivel scăzut ale platformelor pe care le suportă, așa cum se arată în imaginea de mai jos. Pentru dezvoltatori aceasta oferă o încapsulare a funcţionalităţilor de sistem de operare independent de platformă, cum ar fi procesarea de fișiere, funcţionalităţi de reţea sau imprimare.

suport specifice Qt, sau compilarea fișierelor UI. Integrarea Visual Studio are unele limitări, dar cu excepția unor paşi suplimentari care trebuie să fie făcute manual, este în cea mai mare parte bine realizat, debugging-ul fiind şi el funcţional.

Și Mult Mai Mult

Qt a crescut mult, devenind o platformă atât pentru desktop cât și pentru dezvoltarea mobilă, în scenarii de la uzul personal până la software-ul industrial sau embedded. Ca atare, serveşte multe nevoi, toate acestea neputând fi cuprinse în cadrul acestui articol. Cu toate acestea, având în vedere o descriere mai întreagă, Un API Grozav şi Documentaţie Bună vom enumera câteva alte domenii în care Qt poate fi o soluție API-ul de Qt nu este diferit de cele mai multe binecunos- adecvată: cute framework-uri în a fi intuitiv, robust și convenabil. După o • UI declarativ: framework-ul QtQuick și limbajul QML oarecare familiarizare, navigarea define uşoară: lucrurile sunt, oferă un mod declarativ de a construi interfețe dinamice cu de obicei, numite cum ne-am aștepta ca ele să fie numite și sunt tranziții și efecte fluide, fiind destinat în special pentru disamplasate în locul în care ne-am aștepta ca ele să fie amplasate. pozitive mobile. Logica pentru Uiş-uri descrise în acest fel Documentația API este relevantă și simplă, nu e supraîncărpoate fi scris fie în JavaScript sau în cod nativ C++/Qt. cată . Uneori este nevoie de ceva timp pentru a găsi ceea ce căutăm.

• Scripting: QtScript oferă un framework de scripting, cu Dar, în general, aceasta este aprofundată, extensivă, având exemple posibilitatea de a expune părți ale aplicaţiei către mediul de relevante, frumos organizată și atrăgătore, fiind la linie și, ocazioscript, inclusiv mecanismul de signals şi slots . nal, chiar mai bună decât cele mai bune sisteme de documentaţie • Introspecție run-time mai bună şi casting dinamic: din industrie, cum ar fi MSDN sau documentaţia Java API . prin utilizarea tipurilor care moştenesc de la QObject , o

Licenţa : Open Source și Comercială

Qt oferă mai multe tipuri de licențe, cele mai importante două fiind LGPL și cea comercială. LGPL poate fi folosit pentru dynamic linking, adică pur și simplu folosind Qt prin DLL-uri. Licența comercială este destinată pentru cei care doresc să modifice bibliotecile Qt și nu doresc să facă aceste modificări publice.

Fiabilă și robustă

Qt nu este un framework recent. A fost pe piaţă practic de două decenii, fiind folosit pe scară largă atât într-un mediu personal cât şi în cel industrial. Stă la baza lui KDE, al doilea cel mai popular mediu desktop pe Linux, de mai mult de cincisprezece ani, dovedind stabilitate prin milioane de utilizatori. A fost folosit de o mare varietate a jucătorilor industriali și în multe domenii de aplicare, crescând până la un nivel la care poate fi numit cu încredere stabil, matur și robust.

Qt aduce, de asemenea, “binding”-uri la un număr de limbi în afară de C++, cum ar fi Python, Java, C#, Ruby și altele. Astfel, Qt este atât de apreciat, încât a apărut nevoia de a-l folosi şi din alte limbaje.

Instrumente Out-of-the-box Există un set de instrumente care este furnizat împreună cu Qt pentru a accelera procesul de dezvoltare.

Acestea includ următoarele : • Qt Creator, un IDE simplu care acceptă diferite configurații de build și are un suport puternic pentru debugging de cod Qt; • Qt Designer, un editor GUI grafic, care poate fi integrat şi în alte IDE-uri; • Qt Linguist, un manager de texte internaționalizate care pot fi ușor manipulate în Qt; • Qt Assistant, o aplicație de Help care include documentația API Qt , dar poate fi, de asemenea, integrat în aplicațiile proprii, pentru a oferi un sistem de Help.

Există, de asemenea, unele instrumente de linie de comandă pentru compilarea proiectelor Qt, pentru generarea de clase de

24

nr. 23/Mai, 2014 | www.todaysoftmag.ro

introspecție run-time mai bună ne stă la dispoziţie, precum și un casting dinamic mai rapid.

• Un mecanism pentru proprietăți dinamice: proprietăți pot fi setate și citite printr-un nume string, fără ca acestea să fi fost declarate în clasa obiectului. Un exemplu este prezentat mai jos:

QObject obj1; //adds a new property to obj1 obj1.setProperty(”new property”, 2.5); //d == 2.5 double d = obj1.propety(”new property”);

• Pointer-ele smart și managementul sunt de asemenea suportate, chiar și dincolo de ceea ce C++11 a introdus între timp .

• Împachetarea (bundling-ul) de resurse este posibil pentru a putea a furniza resurse, cum ar fi imagini, într-un pachet binar.

Acesta nu este o reclamă

Fără îndoială, există dezavantaje la Qt. La dezvoltarea exclusiv pentru platforma Windows, o soluție bazată pe .NET ar putea fi mai la îndemână pentru unii. Qt a ajuns să fie un framework destul de mare, aşa că ar putea fi un pic mai greu a-l folosi. De asemenea, există uneori probleme cu driver-ele de baze de date și cu threading-ul. Apoi, pot apărea probleme atunci când îl vom utiliza la o scară largă, de altfel ca în cazul oricărui framework.

Dar avantajele depășesc dezavantajele cu mult. Putem găsi întotdeauna soluţii la probleme cu ajutorul unor forumuri sau cercetând documentaţia API. Din păcate, m-am îndepărtat de Qt deja de câteva luni bune.

Dar odată am avut nevoie să verific ceva despre modelul MVC în general, și m-am gândit că descrierea mecanismului de modele şi view-uri al Qt ar putea clarifica unele chestiuni. Și într-adevăr, oprindu-mă cu o privire rapidă în documentația Qt API a fost nu numai absolut util pentru lucruri chiar ne-legate de Qt, dar m-a umplut de bucurie și de nostalgie după acele momente când m-am afundat în lumea Qt atât de minunată.

programare

Dincolo de API

D

acă nu ai API, nu exişti.

Am putea nuanța această afirmație categorică afirmând că fără API nu exişti în cloud, pentru a lansa apoi interogația: oare poţi exista în afara cloud-ului, în zilele

noastre?

Probabil gândiţi: frumoasă compilare de cuvinte în vogă pentru a începe articolul. Vă mulţumesc! Şi sper ca restul articolului să fie la fel de atrăgător sau mai puţin respingător, în Alpar Torok

alpar-istvan.torok@hp.com Functional arhitect @ HP România

funcţie de preferinţa dumneavoastră pentru cuvinte la modă.

Lăsând gluma la o parte, aţi investi întrun startup care ignoră cloud-ul şi nu are API? Eu ştiu că nu aş face-o. Giganţii din software sunt de acord.

Mai trebuie să mărturisesc şi faptul că ideea aceasta nu mi-a venit mie. Prima dată am auzit-o de la Mac Devine, CTO al Cloud Services la IBM. Acesta era în faţa unei audienţe la conferinţa CloudOpen de anul trecut, vorbind despre cum să creezi o primă companie ce oferă servicii cloud şi făcea mereu referire la acest aspect. Dacă nu ai API, ceilalţi nu pot utiliza date de la tine şi nu pot să interacţioneze cu tine, adică este ca şi cum nu ai exista.

Mai auzim multe şi despre noul stil de IT şi puterea dezvoltatorilor. Este într-adevăr o perioadă grozavă pentru a fi dezvoltator.

Toată puterea de decizie este transferată, iar dezvoltatorii au mult mai multe de spus în legătură cu tehnologia care este utilizată.

Acest lucru a mers atât de departe încât se transmite acum şi în mediile de enterprise.

Unele organizaţii au dus aceasta deja până la extrem, permiţând dezvoltatorilor să facă schimbări şi să le introducă în producţie de mai multe ori pe zi, după cum doresc.

Dar ce înseamnă aceasta, în realitate? Este de fapt chiar simplu. Trebuie să ai API-uri bune. Chiar foarte bune. Tipul de API pe care ceilalţi pur şi simplu să nu poată rezista să nu le utilizeze. Bineînţeles, ajută şi dacă serviciul tău este valoros de asemenea, dar indiferent cât este el de valoros, de precis şi demn de încredere, dacă este greu să dezvolţi folosind API, dezvoltatorii, având toată puterea de decizie, vor decide să nu îl utilizeze, sau, şi mai rău, nici nu îl vor observa. V-aţi speriat deja? Ar trebui. Acea documentaţie lungă pentru care aţi alocat atât de mult timp ca să o scrieţi şi să o întreţineţi, nu va ajuta. Toată lumea ştie că dezvoltatorii sunt făpturi leneşe, până într-atât încât consideră aceasta o virtute. Şi acesta este numai încă un exemplu al puterii lor. Ei nu vor citi toată documentaţia voastră, de fapt, se poate ca ei să citească cel mult primul paragraf, sau numai titlurile şi să se aştepte ca să o poată încerca imediat şi să o înţeleagă imediat. Iar dacă nu pot, vor trece mai departe, pentru că ei sunt dezvoltatori foarte deştepţi, cu experienţă şi putere, iar dacă nu pot înţelege API în cinci minute, voi aţi făcut ceva greşit. Şi ştiţi ceva? Au dreptate. De ce să nu fie aşa? La urma urmelor, voi sunteţi în competiţie pentru atenţia lor cu alţi furnizori.

www.todaysoftmag.ro | nr. 23/Mai, 2014

25

programare Dincolo de API API nu sunt deloc ceva nou. Ele au existat de la începutul anilor 2000 şi chiar mai înainte de asta, dacă luăm în considerare nu numai web API. Vă puteţi gândi la altceva decât la REST atunci când vă gândiţi la API? Nu prea mulţi oameni mai fac acest lucru. Iar motivul este că acestea erau perturbatoare. Simplitatea lor i-a atras pe dezvoltatori. Toată lumea a început să le utilizeze şi să le aleagă, în defavoarea alternativelor mai complexe. Nu ar fi frumos să ai agerimea minţii şi să anticipezi „următorul REST”?

Mai mult decât API: noAPI

Este foarte atrăgător să inovezi prin simpla prefixare a unei tehnologii cu negaţia „no”. SQL este o tehnologie a trecutului?

Vine NoSQL să ne salveze! Este tot ca SQL, dar diferită. Atunci, de ce nu noAPI? De ce să nu luăm API cu caracteristicile lor cele mai bune, dar să le facem mai uşor de utilizat? Să oferim ceva care de asemenea să facă posibilă manipularea şi consumul de date şi servicii, dar care să fie mai uşor de înţeles pentru un dezvoltator. Nu este o API, este o noAPI. De cele mai multe ori, nu ne mai pasă de particularităţile unei API; nu implementăm totul. Avem language bindings. Este o îmbunătăţire, dar este suficient? Toată lumea preferă să le utilizeze, sunt logice, dar la sfârşitul zilei, language bindings nu sunt nimic mai mult decât reutilizare de cod. Reutilizarea codului este bună, dar, pentru uşurinţa utilizării, putem face mai mult. Soluţia există, şi a existat de ceva vreme; de fapt, s-ar putea să o ştiţi deja şi să o fi utilizat fără să vă gândiţi.

Domain Specific Languages (DSL) – (Limbajele Specifice Domeniului) se potrivesc de minune la aceasta. Ele sunt considerate a fi o formă de API în sensul tradiţional. DSL este un termen pe care îl folosim pentru a descrie un limbaj de programare conceput cu o anume problemă în minte, spre deosebire de limbajele de programare pentru scopuri generale, cu care suntem obişnuiţi.

Scopul său este să semene foarte mult cu domeniul respectiv, facilitând gândirea şi rezolvarea de probleme în acel domeniu. Regular expression sunt un limbaj specific domeniului. Le folosim deoarece este mult mai uşor decât să implementăm aceeaşi funcţionalitate într-un limbaj cu scop general. Cu cât este mai complexă potrivirea tiparelor care trebuie făcută, cu atât mai uşor devine să nu

26

nr. 23/Mai, 2014 | www.todaysoftmag.ro

implementezi ceva tradiţional. Deoarece limbajul este apropiat de domeniu, este uşor de utilizat.

Să analizăm un exemplu în care oferim un DSL în loc de API. Să presupunem că dorim să configurăm un VM într-un mediu virtual. Un VM simplu, fără şabloane, fără OS instalat. Implementarea pentru această operație ar putea arăta aşa: #!java // [...] backingFile = new VMDiskBackingFile(„/path/to/ some/file/in/data/store”) bakingFile.setThinProvisioned(true) disk = new Disk(backingFile) disk.setParavirtalization(true) disk.setSizeGB(16) VMService.createDisk(disk) vm = new VirtualMachine() vm.setRamGB(2) vm.setDisk(disk) VMService.createVM(vm) vm = VMService.getVM(vm.getName()) VMService.startVM(vm) // [...]

Se impun anumite observaţii. În primul rând, aţi putea spune că interfaţa API furnizată, pe care o utilizăm, ar putea fi mai bine concepută. Cu siguranţă poate fi îmbunătăţită. Realitatea este, totuşi, că este obişnuit să vezi API ca acestea şi nu e uşor să le îmbunătăţeşti, cât timp le păstrezi modulare, rapide şi generice. În al doilea rând, sunt multe lucruri pe care dezvoltatorul trebuie să le reţină. Să creeze fişierul înainte de disc şi discul înainte de VM. E important de menționat: trebuie să obţii înapoi informaţiile despre VM înainte de a-l putea porni. Eu unul, nu am încredere în mine că voi reţine toate acestea, deci, ce putem face?

Să luăm în considerare următoarele: #! vm { disk : 2.GB, backigFile „/path/to/some/file/ in/data/store” { thinProvisioned }, ram: 2.GB, power: on }

Să presupunem că aveţi mai mulţi furnizori pentru interfaţa voastră virtuală: primul cu API din primul exemplu; al doilea, cu DSL din al doilea exemplu. Pe care l-aţi prefera?

Aţi observat cea mai importantă diferenţă? Cu DSL, dezvoltatorul nu trebuie să se concentreze pe „cum”, ci numai pe „ce”.

TODAY SOFTWARE MAGAZINE Aceasta este o mare uşurare; îi permite minţii să se concentreze mult mai bine. Este ca şi cum ţi-ar citi mintea.

Dacă consideraţi că este prea mult efort şi că nu merită, rămâneţi cu mine în partea a treia (şi cea finală) a articolului. Este mai uşor decât credeţi.

Timpuri noi, instrumente moderne şi implementări rapide

Implementarea unui DSL poate părea intimidantă la început.

Dar vă prezentăm mai întâi un mod simplu de a-l implementa.

JVM este casa multor limbaje de programare, pe lângă Java.

Unii susţin că este şi mai important decât limbajul în sine. Groovy este unul dintre aceste limbaje. Este un limbaj de scripting, cu o sintaxa compatibilă cu Java, probabil denumit astfel numai din cauză că JavaScript era luat. Majoritatea codului Java este compatibil cu Groovy, dar nu orice cod Groovy este compatibil cu Java. Şi aici lucrurile devin ciudate. El poate să fie atât de diferit încât programatorii Java nici măcar să nu îl recunoască. De fapt, poate fi atât de exotic, încât este greu de recunoscut chiar şi faptul că este Groovy.

Să fim cinstiţi, Groovy este un limbaj de programare groaznic pentru multe lucruri. Este foarte bun pentru implementarea DSL. Se spune pe website-ul lor că suportă DSL, dar este aproape ca şi cum întregul limbaj ar fi fost conceput numai pentru acest scop unic.

Partea bună este că se integrează dintr-o bucată cu Java, aşa că poţi oricând să implementezi parte din ceea ce vrei în Java, dacă doreşti, şi să foloseşti Groovy numai pentru DSL. Aria de acoperire a modelului de programare meta Groovy depăşeşte cuprinsul acestui articol. Are într-adevăr o curbă de învăţare, dar nu este excesiv de dificil, odată ce începi să te deprinzi cu el. Partea bună este că e productiv dacă lucrezi cu el; făcând cea mai mare parte de muncă, deci, curba de învăţare merită.

Ca un bonus în plus, DSL devine subansamblu al Groovy.

Aceasta înseamnă că poţi oricând să amesteci Groovy în DSL dacă vrei. Obţii date şi structuri de control în DSL pe gratis. Există câteva proiecte grozave care implementează DSL cu Groovy. Unul dintre preferatele mele este Gradle, care implementează un DSL pentru compilarea și asamblarea proiectelor. Este destul de complex, dar un exemplu foarte bun pentru o implementare.

La un nivel înalt, DSL este utilizat pentru a crea un model al

domeniului în faza iniţială de configurare când DSL este executat.

Apoi, lucrul specific domeniului se execută numai după ce modelul este complet. Aceasta permite execuţiei să decidă în legătură cu ceea ce trebuie făcut, ştiind tot ce trebuie realizat. În exemplul de mai devreme, aceasta ar însemna că serviciul cunoaşte configuraţia completă şi particularităţile VM înainte ca aceasta să înceapă să fie creată. Mai există încă multe alte modalităţi grozave şi rapide de a implementa DSL. Cele mai multe limbaje de programare dinamice pot fi utilizate într-o oarecare măsură.

Nu mai este necesar să începi implementarea unui DSL prin implementarea unui parser. data viitoare când este nevoie de o API, veţi lua în considerare noAPI?

www.todaysoftmag.ro | nr. 23/Mai, 2014

27

programare

Întreţinerea la zi a sistemelor Linux – Partea I

Î

Sorin Pânca

sorin.panca@yardi.com Senior Systems Administrator @ Yardi România

28

nr. 23/Mai, 2014 | www.todaysoftmag.ro

n acest articol, care e structurat în mai multe părți, se va analiza problema menținerii sistemului de pe serverele Linux actualizat. Deseori, când se începe administrarea serverelor unei afaceri incipiente, echipa de administratori de sisteme găsește o instalare de servere în centrul de calcul axată în jurul unor servere instalate cu programele necesare și configurate haotic de prima echipă de programatori doar cu scopul „să meargă”. Acești programatori fac atât muncă de dezvoltare cât și administrare de sisteme, care este cunoscută în termenii IT internaționali ca DevOps (Development and Operations).

Această situație reprezintă un obstacol, rădăcină într-un fișier imagine” e că acum creator de ore suplimentare, atunci când putem înlocui sistemul de fișiere rădăcină dorim să păstrăm serverele de producție, cu unul nou doar prin repornirea sistemusau chiar și pe cele de dezvoltare, actual- lui; revenirea la sistemul anterior se face izate. Deseori, administratorii de sisteme de asemenea ușor, doar cu ajutorul unei găsesc sisteme care sunt pornite de timp noi reporniri a sistemului. Un alt câștig al îndelungat și care nu au fost actualizate instalării unui sistem de fișiere rădăcină cu anii. Din punctul de vedere al afacerii, într-un fișier imagine este că sistemul de atât timp cât acele sisteme funcționează și operare instalat în interiorul fișierului își fac datoria, nu contează dacă sunt actu- poate fi actualizat și testat eficient pe un alizate sau nu. Doar atunci când ceva rău sistem de dezvoltare decuplat de producție, se întâmplă, spre exemplu când baza de pentru ca apoi să poată fi publicat pe toate date cu utilizatorii și parolele sau alte date serverele deodată, automat. Când oricare valoroase se scurg în mâinile persoanelor dintre acele servere trebuie actualizat, este neautorizate sau chiar către tot Internetul suficientă o repornire a sistemului. Această din cauza unei breșe de securitate, sau când soluție poate fi întâlnită aproape pe toate programatorii observă că programele lor sistemele înglobate (embedded systems), au nevoie de o versiune actualizată de pro- unde producătorii publică „fișiere imaggrame care e incompatibilă cu versiunea ine” ce pot fi încărcate în router-e, plăci sistemelor de operare folosite pe producție, de administrare decuplată (DRAC, iLO, echipa de conducere grăbește echipa de AMT), etc. . administrare de sisteme să facă actualizări În cazul nostru, am utilizat o distribuție urgente. Această grabă cauzează în contin- de Linux bazată pe surse - Gentoo Linux. uare instalarea pe sistemele de producție a Vă puteți întreba „De ce ar vrea cineva să unor sisteme testate insuficient. compileze totul din surse când este extrem Pentru a simplifica și formaliza pro- de ușor să instalezi pachete binare?”. Când cesul de actualizare fără a fi nevoie de instalează un server, administratorul de achiziția de noi echipamente, noi am atacat sisteme se trezește compilând programe problema în doi pași: întâi, am virtualizat din mai multe surse din varii motive: stratul aplicației folosind Containere Linux pachete disponibile prea vechi, nevoia (LxC). Această formă de virtualizare ne-a de anumite opțiuni ce pot fi activate sau permis să creăm „mașini virtuale”, fără a dezactivate doar la compilare, petice ce pierde din performanța sistemelor sau fără trebuie aplicate pentru a rezolva greșeli în a le supraîncărca cu un strat de simulare a program, etc. . Dacă adăugăm la această părții fizice, cum se face în cazul VMWare muncă și munca de actualizare periodică, sau KVM de la RedHat sau în cazul Oracle administratorul se găsește în situația de VirtualBox sau XEN; al doilea pas a fost să „a-și câștiga banii cu sudoarea frunții”. Se „virtualizăm” nodurile fizice (calculatoarele mai poate întâmpla ca nu doar un anufizice) folosind ca sistem de fișiere rădăcină mit program să necesite compilarea din un fișier imagine al unei partiții. surse, ci și programele de care depinde.

Pe o distribuție binară, întâmpinăm multe Câștigul în a avea „sistemul de fișiere probleme la compilarea din surse, una din

TODAY SOFTWARE MAGAZINE ele fiind cunoscuta problemă a „iadului dependențelor”, alta fiind înlocuirea componentelor de care depinde sistemul (python, perl) cu versiuni nesuportate. Concluzia e că cel mai bine e să construim tot sistemul din surse folosind metode de automatizare cum este „portage”, managerul de pachete de la Gentoo (care seamănă cu sistemul „ports” din FreeBSD).

CONFIGURAȚIA SISTEMULUI

În această primă parte a articolului, vom analiza sistemul gazdă, neavând în vizor container-ele virtualizate sau calculatoarele simulate.

Când am proiectat imaginea sistemului de fișiere rădăcină a sistemului gazdă, cunoscută și sub numele de fișierul imagine rădăcină al „nodului fizic”, am observat că ea trebuie să satisfacă câteva cerințe: • trebuie doar să furnizeze un mediu unde putem rula LxC, KVM și, la un moment dat, OpenStack - care momentan nu e suportat pe alte sisteme decât Ubuntu și RedHat- precum și Docker. Am ales să folosim KVM pentru a rula câteva instanțe de Windows Server; • schema de partiționare trebuie să conțină doar două partiții: o partiție de tip EFI pentru a conține încărcătorul de sistem de operare - Grub v2, care e capabil să acceseze direct imagini de partiții, după ce-și creează un dispozitiv autoreferențiat (loop device); a doua partiție care va conține cel puțin un fișier imagine de unde va porni sistemul; • partiția EFI va fi montată în directorul /boot/loader; • sistemul de stocare gazdă va folosi GPT ca metodă de partiționare, nu MBR, pentru a permite folosirea unui dispozitiv de stocare gazdă (dispozitiv RAID) mai mare de 2 TB; • pe partiția gazdă (cea care conține fișierul imagine rădăcină) orice alte date vor fi stocate într-un director „data”; • partiția gazdă va fi montată în directorul /hostpart.

• partițiile vor fi etichetate și montate folosind eticheta: partiția EFI va fi etichetată cu „EFI-BOOT”, iar partiția gazdă și cu date va fi etichetată „hostpart”; /data0 va fi o legătură simbolică spre /hostpart/data.

• un sistem de stocare distribuit va rula pe toate nodurile fizice pentru a furniza o soluție de stocare rezistentă la intemperii și distribuită; nu vom folosi soluțiile de stocare oferite de OpenStack (deoarece nu este suportat pe Gentoo la data scrierii

acestui articol), ci vom folosi XtreemFS; fiecare nod va juca rolul tuturor celor trei componente ale lui XtreemFS - server director (DIR), server de metadate și catalog al duplicării (MRC) și dispozitiv de stocare obiecte (OSD); • sistemul de stocare distribuită va putea fi accesat în directorul /warehouse pe toate sistemele fizice și pe toate sistemele virtuale interesate; • fișierul imagine rădăcină va fi numit „hn-root.img”; • fișierul imagine rădăcină actualizat va fi numit „hn-rootnew.img”; • fișierul imagine rădăcină vechi va fi numit „hn-root-old. img”; • dacă pe partiția gazdă există un fișier numit „system-revert”, sistemul va redenumi fișierul hn-root.img la hn-root-broken. img și hn-root-old.img la hn-root.img și va porni imaginea rădăcină veche; • toată procesarea de imagini de fișiere se întâmplă în timpul fazei de initrd din procesul de pornire; • în momentul în care imaginea partiției rădăcină este rulată pe un server, trebuie aplicate câteva configurări particularizate pentru acel server: numele sistemului, adresa de rețea, chei ssh, identitate puppet, etc.; pentru a nu introduce aceste modificări manual pentru fiecare server nou sau la fiecare actualizare de imagine a partiției rădăcină. Am creat artizanal un script ce introduce aceste modificări bazându-se pe date stocate într-un „registru de stare” care este un simplu director cu câteva „fișiere de stare” stocat pe sistemul de stocare distribuit.

Mai jos este diagrama partițiilor sistemului gazdă și a fișierului imagine rădăcină:

Diagrama fazei initrd a procesului de inițializare

Genkernel este un script dezvoltat în cadrul proiectului Gentoo, care ajută utilizatorii să-și compileze nucleele (kernels); Acesta ar putea să funcționeze și în alte distribuții, nu doar în Gentoo. Dacă doriți o distribuție binară care asigură

Objective C

jobs-cluj@yardi.com Yardi Romania

www.todaysoftmag.ro | nr. 23/Mai, 2014

29

programare Întreţinerea la zi a sistemelor Linux – Partea I cu atât va dura mai mult publicarea pe toate serverele, iar cu cât e mai mică, cu atât se va umple mai repede. Apoi instalați o distribuție de Linux la alegere; de îndată ce instalarea e terminată, creați o imagine a acelei partiții folosind utilitarul dd; a se observa că directorul /boot se află în interiorul acestei partiții, astfel încât nucleul și initramfs vor fi accesate de grub după ce s-a creat un „dispozitiv grub2 autoreferențiat” (grub2 loop device), care e diferit de dispozitivul autoreferențiat /dev/ loop0 al nucleului; 5. Recompilați nucleul utilizând genkernel; dacă doriți doar să generați un initramfs compatibil, puteți să folosiți comanda genkernel initramfs în locul comenzii de compilare completă genkernel --menuconfig all; 6. În directorul /boot, fișierul „kernel” trebuie să fie o legătură simbolică spre fișierul ce conține efectiv nucleul, iar fișierul „initramfs” trebuie să fie o legătură simbolică spre fișierul ce conține efectiv initramfs; 7. Montați undeva fișierul imagine cu mount -o loop și în fișierul /boot/loader/grub/grub.cfg, creați o nouă intrare în meniul Grub (imaginea din textul articolului este formatată ca reiserfs, astfel încât s-a adăugat modulul pentru reiserfs; va trebui să încărcați modulul ext2 dacă aveți o imagine de partiție formatată ca ext, ext3 sau ext4):

compatibilitatea cu Gentoo și permite genkernel să ruleze nativ, puteți încerca Sabayon Linux sau Calculate Linux, două distribuții bazate de asemenea pe Gentoo. Pentru a putea inițializa sistemul direct din imaginea de partiție rădăcină, am modificat fișierul din genkernel default/linuxrc și am adăugat logica descrisă în diagrama de mai sus. Puteți clona genkernel-ul modificat de pe github, la adresa https://github.com/psihozefir/genkernel.git.

De asemenea, scriptul de inițializare care trebuie să curețe fișierul imagine hn-root.img de fișierele și configurările nedorite, va fi disponibil pe github în curând. Între timp, puteți curăța fișierul manual. Scopul acestui script e de a facilita înlocuirea sistemelor imagine cu un fișier imagine dintr-o singură sursă pe toate serverele fără a cauza confuzie în rețeaua și aplicațiile de administrare (precum Nagios sau Icinga, sau panourile de administrare ale sistemelor) din centrul de calcul.

Pentru a instala un sistem într-o imagine de partiție rădăcină, putem urma următorii pași .Această procedură va șterge complet dispozitivul de stocare al sistemului, deci faceți copii de rezervă înainte de a vă apuca de treabă: 1. Folosind parted, creați o nouă etichetă GPT dacă nu ați partiționat deja utilizând GPT serverul; acest pas va distruge toate datele existente pe dispozitivul de stocare; 2. Creați o partiție minusculă pentru a găzdui încărcătorul de sistem de operare Grub2 (128 MB), formatați-o cu FAT32 sau FAT16, dacă utilitarul mkfs se plânge de dimensiunea tabelei de alocare a fișierelor. Apoi etichetați-o „EFI-BOOT” (a se observa capitalizarea); 3. Creați o a doua partiție care să umple restul de spațiu de stocare și formatați-o cu orice sistem de fișiere Linux (se recomandă BTRFS); 4. Pe un alt sistem (care poate fi o stație de lucru), creați o partiție de 15 GB. Aceasta poate fi mai mare sau mai mică, depinde de necesitățile dumneavoastră, dar cu cât e mai mare

30

nr. 23/Mai, 2014 | www.todaysoftmag.ro

menuentry ‘GNU/Linux in a file’ { insmod part_gpt insmod fat insmod reiserfs insmod ext2 insmod gzio set root=’hd0,gpt2’ loopback loop ($root)/hn-root.img echo “Loading Linux…” linux (loop)/boot/kernel root=/dev/ram0 real_root=/hn-root.img raw_loop_root_host_ partition=LABEL=hostpart ro }

echo “Loading initial ramdisk…” initrd (loop)/initramfs

8. Editați /etc/fstab și ștergeți tot conținutul fișierului, apoi adăugați următoarele linii: LABEL=EFI-BOOT /boot/loader vfat noauto,noatime 1 2 LABEL=hostpart /hostpart auto noatime 0 1

9. Demontați fișierul și copiați-l pe sistemul destinație; instalați grub pe dispozitivul de stocare al serverului: grub2install --target=x86_64-efi --boot-directory=/boot/loader --efi-directory=/boot/loader; va trebui să utilizați chroot de pe un stick USB cu Live Linux (System Rescue CD, de exemplu) pentru a putea instala grub, însă această procedură e în afara scopului acestui articol.

Un alt câștig al utilizării fișierelor imagine e că face posibilă schimbarea distribuțiilor Linux extrem de facilă. Doar copiați un fișier hn-root.img ce conține altă distribuție de Linux și ați terminat! În partea a doua din articol se va prezenta sistemul de stocare distribuită XtreemFS, iar în partea a treia, se va analiza virtualizarea sistemelor (folosind LxC și KVM) și aplicațiilor (utilizând Docker). Când openStack va fi disponibil în una dintre imaginile noastre,se va realiza a patra parte, în care vom expune detalii despre modul în care noi vom folosi OpenStack.

Configurația descrisă este momentan în construcție, iar unele componente nu sunt create încă. Deci, rămâneți pe fir!

programare

Modelarea datelor în contextul Big Data

C

Silvia Răusanu

silvia.rausanu@isdc.eu Senior Developer @ ISDC

ând cineva spune “modelare de date”, se gândește automat la baze de date relaționale și la procesul de normalizare a datelor, a treia formă normală, etc. . Acest mod de gândire demonstrează o practică bună, înseamnând că semestrele de baze de date din facultate au avut efect asupra operațiilor de gândire și de lucru cu datele. Însă, din facultate și până acum, lucrurile s-au schimbat pentru că nu mai auzim la fel de mult despre baze de date relaționale, deși acestea sunt folosite în continuare cu preponderență în aplicații. Acum “big data” este la modă, dar este și o situație pe care tot mai multe aplicații trebuie să o abordeze: volumul, viteza, varietatea și complexitatea datelor (conform definiției Gartner pentru big data). În acest articol vom aborda dualitatea conceptelor de normalizare și denormalizare în contextul big data, din prisma experienței mele cu MarkLogic (o platformă pentru aplicații big data).

când se lucrează cu baze de date relaționale.

Mai mult, chiar și lexicul și etimologia susțin această practică: datele fragmentate sunt considerate “normale”.

Despre normalizare

Când vine vorba de modelare a datelor în contextul big data (în mod special MarkLogic), nu mai există o formă universal recunoscută în care trebuie încadrate datele, dimpotrivă, conceptul de schemă nu se mai aplică. Totuși, suportul oferit de platformele big data pentru date nestructurate nu este echivalent cu omisiunea pasului de modelare. Datele brute trebuie analizate dintr-un punct de vedere diferit în acest context, mai exact, din punctul de vedere al necesitaților aplicației, făcând astfel baza de date folosită orientată spre aplicație. Dacă ar fi să observăm operația cea mai frecventă – citire – s-ar putea spune că orice aplicație este o aplicație de căutare; din acest motiv, procesul de modelare a datelor trebuie să aibă în vedere entitățile pe care le manevrează în mod logic (după care caută), cum ar fi: articole, informații despre utilizator, specificații pentru mașini, etc. . În timp ce normalizarea ,,sparge” datele brute pentru a respecta protocolul, fără a lua în considerare nevoile funcționale, denormalizarea se face doar pentru a servi aplicația – bineînțeles, cu grijă- pentru că denormalizarea excesivă poate cauza mai multe probleme decât soluții. Ordinea pașilor în care se dezvoltă o aplicație bazată pe date normalizată pare că respectă metodologia cascadă: odată ce modelul de date s-a stabilit, se începe lucrul la modelele de interogare și indiferent de performanța obținută, ajustările se fac

Normalizarea datelor face parte din procesul de modelare a datelor pentru crearea unei aplicații. De cele mai multe ori, normalizarea este o practică bună din cel puțin două motive: evită problemele de integritate în situații de alterare a datelor (inserare, actualizare, ștergere) și evită înclinația față de orice model de interogare. În articolul “Denormalizare pentru viteză și profit”1, apare o comparație foarte interesantă între modelarea datelor și filozofie: principiul lui Descartes vast acceptat (inițial) de separare a minții de trup seamănă foarte bine cu procesul de normalizare – separarea datelor; eroarea lui Descartes a fost să despartă (filozofic) două părți care mereu au fost împreună. În același mod, după normalizare, datele trebuie aduse înapoi împreună de dragul aplicației; datele, care au fost inițial împreună, au fost fragmentate, iar acum trebuie recuplate – pare cel puțin redundant, dar este abordarea cea mai folosită din ultimele decenii, mai ales

1 Todd Hoff, Scaling Secret #2: Denormalizing Your Way to Speed and Profit, http://highscalability.com/ scaling-secret-2-denormalizing-your-way-speed-and-profit

Despre denormalizare

www.todaysoftmag.ro | nr. 23/Mai, 2014

31

programare Modelarea datelor în contextul Big Data

asupra interogării, poate asupra indecșilor din baza de date, dar nu asupra modelului.

Având o bază de date denormalizată, relația dintre modelul de date și modelele de interogare descriu mai bine metodologia agilă: dacă cerințele funcționale și atributele de calitate nu sunt îndeplinite atunci modificările se pot efectua și pe date pentru a îmbunătăți interogările până când se obține rezultatul dorit.

Toate argumentele care au făcut normalizarea atât de celebră rămân valide, însă platformele big data au dezvoltat instrumente pentru a păstra integritatea datelor și pentru a depăși alte probleme.

Sistemele pentru big data sunt mult mai ușor scalabile pentru volume mari de date (atât pe orizontală cât și pe verticală), ceea ce face ca problema excesului de volum generat de denormalizare să fie ignorată; în plus, volumul extra ajută la îmbunătățirea performanței căutărilor. Rezolvarea pentru problemele de integritate depinde de arhitectura aleasă a aplicației, dar și de “proprietarul” datelor.

instrument de extragere-transformareîncărcare (ETL) datele ajung în “depozitul” big data. Având aceste două opțiuni, posibilele probleme de integritate se tratează altfel. În cazul în care datele există doar în sistemul big data, este necesar un instrument de sincronizare și integrare a datelor care au suferit alterări. Instrumentele care implementează map-reduce sunt cel mai des folosite deoarece sunt eficiente și rulează pe hardware de bază. Astfel de procese de sincronizare pot fi declanșate fie imediat după ce modificarea originală a fost executată – când modificările nu sunt foarte dese și nu există posibilitatea de a genera o interblocare (dead-lock); când modificările sunt efectuate mai des, este recomandat un job ce rulează periodic, la intervale de timp prestabilite.

Când datele originale sunt într-o bază de date relaționale, efortul de menținere a integrității datelor este susținut de sistemul original de stocare - care trebuie sa fie normalizat. În această situație trebuie investit mult și în ETL pentru a reface structura logica a datelor. Chiar dacă libertatea pe care o oferă acest instrument este foarte mare, aplicațiile trebuie să respecte un anumit standard de performanță și încredere, deci noile modificări trebuie să fie aplicate pe sistemul de big data cât mai repede posibil; există, așadar, riscul de a denormaliza excesiv, reducând foarte mult din efortul de calcul din sistemul de big data.

Rezolvarea problemelor de integritate la denormalizare Denormalizarea și join-urile În momentul în care se alege denormalizarea datelor este clar că se merge pe centru de date orientat spre aplicație, însă aceasta reprezintă doar sursa de date cu care aplicația comunică direct, nu sursa originală a datelor sau “proprietarul” datelor. Pentru sistemele de big data, sunt două opțiuni: fie datele trăiesc doar în baza de date big data, fie au ca sursă inițială o bază de date relațională și cu ajutorul unui

32

După toată pledoaria de mai sus pentru denormalizare, pare lipsit de sens să mai atingem subiectul „join”; denormalizarea este o soluție pentru a evita un join de dimensiuni mari - suntem în context big data, până la urmă. Însă atributele calității, sursele multiple de date și respectarea protocoalelor externe pot reduce radical opțiunile de modelare/denormalizare.

Să luam un exemplu concret, modelul de

nr. 23/Mai, 2014 | www.todaysoftmag.ro

business pentru abonamentele periodice la articolele din anumite ziare cărora adăugăm și dimensiunea modelului de lucru: 45 de milioane de articole și 9 miliarde de relații articol-utilizator. Fiecare utilizator își poate face abonamente la anumite ziare pe perioade limitate de timp (doar câteva ediții); așadar condițiile de join sunt derivate din „potrivirea” între identificatorul ziarului și titularul abonamentului, precum și perioada abonamentului care să includă articolele publicate în acest interval. De ce este nepotrivită denormalizarea în acest scenariu? Modelul pentru articol ar trebui să conțină denormalizate informațiile despre toți utilizatorii care au acces la el aceasta ar însemna o poluare a entității, dar și efortul de calcul suplimentar pe partea de ETL sau map-reduce, ceea ce ar putea degrada valoarea aplicației. Pe de altă parte, modificările efectuate pe perioada de subscriere pentru un anume utilizator poate crea alterarea a milioane de articole, și aceasta ar genera un proces de reconstruire a consistenței situației abonamentelor... în cele din urma.

Concluzie

În contextul big data, cea mai bună opțiune de modelare de date rămâne denormalizarea - aplicațiile moderne au nevoie de viteză mare de răspuns, nu merită să pierdem timp (de execuție) să punem la loc, împreună, datele normalizate pentru a oferi utilizatorului entitățile logice. Bineînțeles, denormalizarea completă nu este cea mai bună opțiune pentru a încapsula o relație mare de join many-tomany, după cum am arătat în paragraful precedent. Și pentru a termina într-o nota veselă, conform titlului articolului2: „normalization is for sissies” (normalizarea este pentru naivi), iar denormalizarea e soluția.

2 Pat Helland, Normalization is for Sissies, http://blogs. msdn.com/b/pathelland/archive/2007/07/23/normalization-is-forsissies.aspx

management

Code Kata

C

uvântul Kata provine din artele marţiale: este traducerea japoneză a cuvântului formă.

Kata e folosit pentru a descrie şabloane de mişcare detaliate, de o anumită coreografie, care pot fi practicate fie singur, fie în perechi.

Tudor Trișcă

Tudor.Trisca@msg-systems.com Team Lead & Scrum Master @ msg systems România

Poate să descrie şi alte acţiuni din artele marţiale cum ar fi training-ul, lupte simulate detaliate şi altele.

Kata-urile erau metode de învăţare si de training prin care tehnicile de luptă de succes erau conservate şi transmise mai departe.

Practicarea Kata permitea unui grup de persoane să activeze într-o luptă folosind o tehnică sistematică, spre deosebire de o mulţime de indivizi într-o manieră haotică.

Principalul avantaj al folosirii Kata-urilor în arte marţiale este transmiterea de tehnici dovedite şi practicarea lor într-o manieră repetitivă. Aceasta ajută novicele să-şi dezvolte abilităţile de executare a acestor tehnici şi mişcări într-un mod natural ca şi un reflex.

Pentru a atinge acest nivel, ideea nu este acţionarea sistematică, ci mai degrabă internalizarea acestor mişcări şi tehnici, astfel încât persoana să le poată adapta diferitor nevoi.

început să scrie despre memoria procedurală de peste un deceniu. După multe cercetări, a fost dovedit faptul că doar simpla repetare a unui task nu asigură achiziţia unei noi abilităţi. Comportamentul trebuie să se schimbe într-un un rezultat al acelei repetiţii.

Dacă schimbarea comportamentală se poate observa, atunci se poate spune că s-a dobândit şi abilitatea nouă.

Code Kata

Dave Thomas a fost primul care a introdus ideea de Kata-uri ca tehnică de învăţare în programare. Abordarea este destul de simplă: un Code Kata este o simplă problemă de programare, intenţia fiind să fie uşor rezolvată iar şi iar, tinzând spre perfecţiune. Ideea este să ajute programatorul să rezolve problema oferită într-un mod mai bun de fiecare dată când se încearcă, în timp ce subconştientul învaţă perechi de probleme/soluţii detaliate Exersarea care pot să vină în ajutor în rezolvarea de alte Exersarea ca o metodă de învăţare este probleme. Kata-ul se poate face şi prin adauubicuă. Se poate vedea în toate domeniile, nu garea de alte provocări, cum ar fi anumite doar în arte marţiale: limitări: de exemplu, folosirea unui limbaj de • Cântatul la un instrument muzical, programare diferit faţă de cel obişnuit zilnic.

• Îmbunătăţirea performanţei în sport, Se poate realiza fie individual, fie într-un grup • Pregătirea pentru un discurs în public, organizat. ş.a. .

Incontestabil este o metodă fundamentală Munca de la servici nu înseamnă exersare de învăţare. Desigur, depinde de mai mulţi Serviciul poate aduce prea multă presifactori, dar cu dedicarea şi ghidarea corectă, une asupra programatorilor neexperimentaţi: o persoană poate să exceleze la multe lucruri presiunea nevoii de a livra cod de calitate doar prin exersare. folosind tehnici nefamiliare, care poate duce la frustrări, greşeli, sau lipsa aplicării de „best Memoria Procedurală practices”. Ajutorul din partea mentorilor nu Memoria procedurală este un tip de este o permanență: programatorii experimenmemorie de termen lung, mai specific, dove- taţi sunt ocupaţi cu terminarea task-urilor dindu-se eficient în învăţarea bazată pe asignate şi nu găsesc timpul necesar de alocat tehnici. Acest lucru e realizat prin repetarea pentru ajutarea creşterii celorlalţi. unui task complex, rezultând astfel într-o Pentru a deveni un programator mai bun îmbunătățire a sistemului neuronal utili- este nevoie de exersare. Cât de bună ar fi o zat pentru a realiza acel task. Psihologii au trupă de muzică dacă şi-ar exersa cântecele www.todaysoftmag.ro | nr. 23/Mai, 2014

33

management Code Kata Dacă vrei să faci Code Kata-uri, ele trebuie să fie provocatoare. Repetarea nu va ajuta dacă creierul nu este captivat.

Creierul trebuie provocat pentru a stimula şi a crea noi căi neuronale.

Tips & Tricks

doar când ar fi pe scenă? Ce fel de calitate ar aduce o piesă de teatru dacă actorii ar primi scenariul doar cu o oră înainte de spectacol?

Cum să nu faci Code Kata

Multă lume e de părere că sesiunile de Code Kata se referă la rezolvarea aceleaşi probleme în acelaşi fel. Acest lucru va avea ca efect probabil învăţarea doar unor scurtături în IDE-ul folosit. Cum menţionam anterior despre memoria procedurală: doar simpla repetare a unui task nu asigură dobândirea unei noi abilităţi.

Comportamentul trebuie să se schimbe devenind un rezultat al acelei repetiţii.

Ca şi cum mersul pe jos în fiecare zi nu te face un maestru al mersului pe jos, şi condusul maşinii zilnic nu te face un şofer superior, la fel nici rezolvarea aceluiaşi set de probleme de programare iar şi iar nu te va face un maestru al programării. Repetarea aceluiaşi lucru iar şi iar fără creşterea nivelului de provocare rezultă doar în complacerea minţii cu activitatea respectivă.

34

Pair-programming: munca în echipă este un factor important în sesiunile de Code Kata.

Acesta trebuie să încurajeze ca învăţarea să se producă în timpul implementării pentru că programatorul care nu este la tastatură observă, comentează şi întreabă, furnizând un feedback continuu (dar fără dictare, critică sau control).

Finalizarea unui task nu trebuie forţată. Dacă se pune prea mult accent pe terminarea taskului, programatorii vor începe să compromită calitatea codului pe care îl scriu. Acest lucru se întâmplă în mediile de producţie în care se aplică prea multă presiune pe viteză în schimbul calităţii. Dacă ţinta sesiunilor de Code Kata este ca programatorii să fie mai rapizi, ei trebuie lăsaţi să exerseze fără sentimentul de presiune al completării taskului într-un anumit timp setat. În timp se va observa că tehnicile de programare devin din ce în ce mai naturale şi rezultatul final va consta în programare mai rapidă şi calitatea codului mai ridicată.

Asigurarea faptului că la sfârşitul sesiunii codul se şterge. Se porneşte cu ideea că există întotdeauna mai multe metode în rezolvarea unei probleme şi acest lucru e adevărat mai cu seamă în programare.

Dacă vei ruga zece programatori să rezolve o anumită problemă, de cele mai multe ori vei obţine zece implementări diferite.

Dar care e cea mai bună soluţie dintre ele?

Probabil nici una, cea mai bună soluţie fiind adeseori o combinaţie dintre câteva sau toate implementările sau poate chiar o soluţie cu totul diferită. Scopul ar fi ca programatorii să înţeleagă că există mai mult decât o modalitate de a face un anumit lucru şi ştergerea codului existent şi începerea task-ului din nou este câteodată cea mai bună opţiune.

Ajutarea perechilor de programatori să contribuie în mod egal. Perechile de programatori care participă la sesiunea de Code Kata trebuie observate şi ajutate să

nr. 23/Mai, 2014 | www.todaysoftmag.ro

se trateze între ei ca membri egali. Este de obicei dificil când există o pereche ce conţine un senior şi un junior, dar e important ca acele contribuţii rezultate să fie egale.

Această sesiune nu este una de mentoring.

Stricteţea legată de timp. Din când în când, tendinţa este să se mai lase puţin timp pentru dezvoltare. Aceasta este din cauză că se pune prea mult accent pe terminarea task-ului, ceea ce nu trebuie să constituie o prioritate. Programatorii trebuie să fie reasiguraţi de faptul că nu este vorba de finalizarea task-urilor; odată ce acest lucru este înţeles, ei nu vor mai cere timp în plus.

Menţinerea sesiunii distractivă, dar intensă. Niciodată nu strică puţină muzică de fundal (dar să nu distragă atenţia), iniţierea de discuţii, recompense, orice este nevoie pentru a scoate programatorii din monotonie. E importantă concentrarea asupra eliminării anxietăţilor şi reasigurarea faptului că greşelile şi eşecul reprezintă un lucru bun. Încurajarea comunicării. Camera în care se susţine sesiunea de Code Kata trebuie să fie tot timpul zgomotoasă, plină de discuţii, schimb de idei, dar toată această activitate timpul trebuie orientată spre task-ul de rezolvat. Dacă în cameră e linişte şi programatorii sunt decuplaţi de la proces, atunci ceva nu merge bine.

Găsirea de Code Kata-uri provocatoare, dar nu inaccesibile: A nu se face greşeala de a se selecta un task prea complex pentru sesiune fiindcă atunci entuziasmul va cădea şi programatorii se vor decupla de la întregul proces.

Concluzie

Ideea de pornire atunci când doreşti să iniţiezi sau să participi la o astfel de sesiune de Code Kata este faptul că scopul unei Kata nu este acela de a ajunge la un răspuns corect. Tot ce contează sunt cunoştiinţele acumulate pe parcurs. Scopul este exersarea, nu soluţia.

Referinţe „Code Katas”, Bart Bakker, 2014 „Code Kata”, Joao M. D. Moura, 2014 „Using Code Kata practice sessions to become a better developer”, Kirsten, UVd, 2013 „Performing Code Katas”, Micah Martin, Kelly Steensma, 2013 „Why I Don’t Do Code Katas” John Sonmez, 2013 „Code Katas: Practicing Your Craft”, 2011 „Code Kata – Improve your skills thrugh deliberate practice”, 2013

management

TODAY SOFTWARE MAGAZINE

Analiza eficientă a scenariilor de utilizare

E

licitarea cerințelor funcționale este un subiect frecvent vehiculat printre analiștii de business, dar întrebarea cea mai comună este: ‘De unde apar de fapt aceste cerințe?’ Este destul de complicat să înțelegem și să colectăm cerințele funcționale ale unui sistem în condițiile în care explicațiile clienților sunt de regulă ambigue, variate și lipsite de terminologie tehnică.

Dar cum reușim să identificăm și să documentăm toate funcționalitățile cerute, rolurile implicate și acțiunile acestora?

Răspunsul este destul de simplu – trebuie să facem analiza scenariilor de utilizare (engl. use case analysis) pentru a reuși să stabilim contractele dintre sistem și utilizatori și să rafinăm cazurile de utilizare ale sistemului pentru a obține o viziune cât mai organizată și mai completă.

Scrierea de scenarii de utilizare eficiente este una dintre cele mai importante responsabilități ale unui analist de business, deoarece oferă cerințelor funcționale obținute obiectivitate crescută, permițând o reprezentare adecvată a funcționalităților și a comportamentului produsului. Opusă reprezentării textuale, modelarea scenariilor de utilizare permite o descriere pas cu pas a acțiunilor - independente și interconectate - făcute de actorii definiți.

Odată scrise, scenariile de utilizare devin livrabile de uz larg, fiind utile mai multor participanți la procesul de livrare al unui produs software, precum: beneficiarii, analiștii de business, echipele de dezvoltare și testare, autorii tehnici, designerii UI/ UX, arhitecții software și chiar și cei din management.

Ce și cum…?

Pentru a avea un punct de pornire solid în ceea ce privește colectarea cerințelor funcționale ale unui produs, analistul de business trebuie să întrebe mai întâi cine va folosi sistemul, cine va obține valoare prin interacționarea cu el sau cine își va atinge un obiectiv de business prin intermediul acestor interacțiuni. Răspunsul este - ACTORII – anume persoanele sau produsele software care fac uz de sistem.

Este recomandat să atribuim un nume și o scurtă descriere fiecărui actor, pentru a evita confuziile, suprapunerea de roluri și/ sau ambiguitatea. Actorii sunt externi sistemului și pot fi de mai multe tipuri, ca de

exemplu actorii principali ai unui scenariu, actorii secundari, sub-sisteme sau componente ale sistemului în cauză.

După ce a pus în evidență actorii, analistul identifică activitățile desfășurate de fiecare. Acestea se numesc cazuri de utilizare (engl. use cases) – și reprezintă modul în care actorii interacționează cu sistemul pentru a obține valoare de business.

Aceste acțiuni trebuie să fie independente, având bineînțeles nume și descrieri scurte. Analistul trebuie să fie conștient că printe aceste activități va regăsi scenariile principale, sau pozitive (engl. happy day scenarios), scenariile alternative și cazurile de eroare și doar înțelegând profund domeniul de business va putea să le identifice și să le clasifice corect. Totodată, pentru a obține scenarii de utilizare reale, trebuie să acordăm atenție pre și post condițiilor aferente.

Prin urmare, scenariile de utilizare sunt nucleul unui produs software, întrucât descriu comportamentul și modul de utilizare al sistemului din perspectiva fiecărui actor. Scenariile de utilizare reprezintă o tehnică foarte puternică de modelare a scenariilor de business. Setul complet de actori și de scenarii se mai numește și system’s use case model. Acest model poate fi reprezentat fie ca un document scris fie ca diagramă, de regulă ambele, deoarece se pot surprinde nivele de detalii diferite. Actorii sunt reprezentați ca oameni, scenariile de utilizare ca elipse, iar relațiile prin săgeți, orientate dinspre actor înspre scenariu.

Studiu de caz

Să presupunem că avem un client al cărui domeniu de business constă în găzduirea de evenimente, de exemplu conferințe, în clădirea proprie.

Clădirea are trei săli de conferință, fiecare cu capacitatea de a acomoda 100, 150 și respectiv 200 de persoane. Clientul oferă servicii complete clienților săi, care includ:

• Închirierea uneia sau a mai multor săli de conferință; • Promovarea evenimentelor clienților; • Menținerea unei liste cu rezervări; • Menținerea listelor cu rezervări confirmate/anulate; • Menținerea rezervărilor neonorate și neanulate în prealabil; • Asigurarea că nu se vor face rezervări în afara capacității sălilor de conferință.

Momentan, clientul menține informațiile folosind documente simple și dorește o soluție web care să-l ajute să își automatizeze serviciile.

Așadar, cum ar trebui să procedeze un analist de business pentru a înțelege cerințele funcționale efective ale produsului?

Puțin ‘domain knowledge’ în ceea ce privește organizarea de evenimente ar ajuta, deoarece ar evidenția faptul că, de regulă, sălile pot fi partajate prin pereți falși astfel încât numărul de incinte devine variabil, în funcție de context. Pentru simplitate, să presupunem că de această dată nu este cazul.

Totodată, la o primă vedere, ne putem da seama că sălile nu au aceeași capacitate, drept pentru care pot avea și prețuri diferite.

Prin urmare, ‘domain knowledge’ ne ajută din nou, întrucât politicile de overbooking intră în discuție. În orice caz, nu trebuie să facem presupuneri, ci să formulăm întrebări despre toate aceste situații, în momentul în care ne vin în minte!

Astfel, în exemplul nostru, i-am adresat clientului un set de întrebări și am concluzionat că numărul de săli este fix (nu există posibilitatea să partajăm sălile dinamic), nu există politici de overbooking și într-adevăr, sălile au prețuri diferite pe care clientul dorește să le modifice, și voila, o cerință ascunsă – managementul prețurilor sălilor!

www.todaysoftmag.ro | nr. 23/Mai, 2014

35

management Analiza eficientă a scenariilor de utilizare Cine sunt actorii? Câțiva dintre ei sunt evidenți: persoanele care fac, confirmă și anulează rezervările și clienții clientului nostru care trebuie să poată închiria sălile.

Dar este într-adevăr așa? Haideți să-l întrebăm pe client și să vedem! În momentul în care începem să întrebăm, ce credeți – se pare că totuși clienții clientului nostru nu folosesc niciodată sistemul, deoarece acesta nu pune la dispoziție mijloace de plată electronică, drept urmare este unul dintre angajații clientului nostru cel care prin intermediul sistemului va asocia efectiv săli de conferință clienților finali.

Așa că, actorii propriu-ziși sunt persoanele care participă (prin intermediul rezervărilor) la evenimente și angajații clientului.

Este foarte important să dăm acestor actori nume adecvate folosind termeni din domeniu! Nu am dori să numim o persoană care participă la aceste evenimente - Chef - care ar fi un nume potrivit pentru o aplicație destinată restaurantelor. Așadar, dacă întrebăm clientul, vom concluziona că el de regulă se referă la aceste persoane ca fiind Participanți – iar un actor s-ar numi Participant. În regulă! Acum să vedem ce nume ar trebui să dăm angajaților care fac asignarea sălilor de conferințe pentru Participanți? Tot clientul nostru ne spune că ar trebui să îi numim Angajați – prin urmare o persoană s-ar numi Angajat.

După ce punem totul cap la cap, încercăm să facem o diagramă simplă, care să descrie aceste fapte, vezi Fig. 1

Deci cum vi se pare?

Fig. 1 – Prima încercare de a ce scenarii de utilizare

Primul lucru pe care-l identificăm este lipsa parității! Avem un scenariu ‘Asignează sala Participantului’ dar ne lipsește cel de ‘De-asignează sala de la Participant’.

Dar, surpriză! Când îl întrebăm pe clientul nostru despre acest scenariu, el spune că nu înțelege la ce anume ne referim!

Acesta este un pas important pentru noi, însemnând că începem să avem o înțelegere mai profundă asupra domeniului! După ce întrebăm clientul despre cum anume gestionează asignările de săli pentru clienții care au plătit, ne spune că nu face aceasta așa cum am presupus!

Fig. 2 – O diagramă rafinată El creează un Eveniment pentru clientul său, cu nume și descriere și asignează o sală la acel eveniment. Și mai mult, niciodată nu face o de-asignare de sală, ci pur și simplu șterge evenimentul din Astfel, noi deducem că evenimentul trebuie să aibă și o dată, agendă, odată ce acesta a avut loc! deci n-ar avea sens să lăsăm angajații să facă asignări pentru un

36

nr. 23/Mai, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE eveniment care s-a întâmplat deja!

Clientul ne confirmă imediat că avem dreptate! Încă o încercare de a face diagrama use case, produce rezultatul din Fig. 2. Încă nu suntem mulțumiți de problema anterioară de paritate.

Dar fiind analiști de business experimentați știm un lucru: Utilizatorii fac greșeli! Așa că, folosind documente simple, clientul nostru nu era conștient de faptul că există într-adevăr o cerință funcțională ascunsă :“De-asignarea sălilor de la un eveniment” care se întâmplă implicit prin simpla suprascriere sau ștergere a unui rând dintr-un table din document. În orice caz, din moment ce construim o soluție IT dedicată, trebuie să existe explicit scenariile de utilizare prin care Angajații pot să corecteze asignările eronate la săli.

Așa că, insistăm și clientul acceptă. Prin urmare:

întrebare la care doar clientul poate răspunde (dar nu o va face de la sine, fiind datoria noastră de analiști de business să-l întrebăm!)

Desigur, clientul ne răspunde că oricine ar trebui să poată să participe!

Prin urmare, Administratorul nu ar trebui să asigneze și roluri de Participant, deoarece oricine are acest rol din start, vezi Fig. 4!

Uitându-ne la diagrama scenariilor de utilizare, încercăm să ne dăm seama dacă am acoperit toate cazurile bazate pe informațiile inițiale oferite de client și ceva ne lipsește – evidențierea absențelor pentru rezervările neanulate în prealabil!

Clientul vrea să știe dacă cineva a făcut o rezervare la care nu s-a prezentat, fără să fi anulat rezervarea în prealabil. Ce bine ar fi dacă am avea o formă de a diferenția persoanele care s-au prezentat de cele care nu s-au prezentat!

Acum observăm că scenariul ‘Confirmă rezervarea’ e lipsit de sens. Ce anume înseamnă să confirmi o rezervare? Se confirmă că locul tău pe scaun e rezervat pentru tine și nu-l vei pierde sau se confirmă că tu vei participa efectiv?

Clientul ne clarifică că intenția acestui scenariu ar fi de a specifica că cineva chiar s-a prezentat la un eveniment dat. În acest caz scenariul ar trebui redenumit “Confirmă participarea” în loc de “Confirmă rezervarea” și ar trebui să aparțină Angajatului, nu Participantului. Confirmarea unei rezervări nu are sens deoarece rezervarea unui loc fie nu ar reuși, din cauză că nu sunt locuri disponibile, fie ar reuși, din cauză că nu există politici de overbooking care ar putea anula o rezervare aparent reușită.

Fig. 3 – O diagramă mai complexă

Bineînțeles, nu vrem să intrăm în astfel de detalii decât atunci când este cazul, dar totuși trebuie să analizăm și problema definirii tipurilor de utilizatori autorizați în sistem! E un subiect generic, dar de regulă trebuie să existe un Administrator care poate să asigneze roluri altor persoane.

Așadar, e destul de simplu să plasăm pe diagramă și Administratorul care asignează rolurile Administrator și Angajat celorlaltor persoane, iar întrebarea care apare acum este: Cum se creează Participanții? Aceasta, ca și altele de până acum, e o

Fig. 4 – Adăugarea Administratorului

Fig 5 – O diagramă mai realistă

Așadar, vom analiza dacă acum acoperim toate scenariile de utilizare cerute inițial de client: • Participanții pot face și anula rezervări; • Angajații pot confirma rezervările, putând totodată să facă diferența între cei care au participat și cei care nu; • Angajații pot crea evenimente și pot asigna sau de-asigna săli pentru aceste evenimente; • Angajații pot șterge evenimente; • Administratorul poate atribui și revoca rolurile de Angajat și Administrator.

Ceea ce ne lipsește este capacitatea cuiva, probabil a Angajatului, de a vedea un raport de ne-participare care să arate persoanele care nu s-au prezentat deși nu și-au anulat în prealabil rezervările. Îl întrebăm pe client și el confirmă! Așadar, avem nevoie de un scenariu de utilizare și pentru asta!

Totodată, cum rămâne cu ștergerea unui eveniment? Ștergem www.todaysoftmag.ro | nr. 23/Mai, 2014

37

management Analiza eficientă a scenariilor de utilizare cu adevărat un eveniment sau doar îl marcăm ca petrecut astfel limitări. încât să nu se mai poată face alte rezervări pentru el? Contează, • Use case-urile reprezintă un punct de pornire solid în ceea deoarece ne-ștergerea unui eveniment ne permite să-l marcăm ca ce privește strategia de testare a produsului. încheiat, dar în același timp ne permite să rulăm rapoarte pe acel eveniment (cum ar fi raportul de ne-participare).

Limitările use case-urilor Ca de obicei, întrebând clientul, acesta confirmă că de fapt • Diagrama de use case-uri nu reprezintă setul complet de dorește ca evenimentul să rămână în istoricul sistemului și că cerințe funcționale ale sistemului. scenariul ar trebui într-adevăr să fie numit “Închidere eveni• Sunt proiecte în care scrierea de user stories e considerată a ment”. Fiind închis, nicio rezervare nu poate fi făcută pentru acel fi mai puțin complicată și consumatoare de timp decât scrierea eveniment. Totodată, odată închis, evenimentul nu mai poate fi de use cases. redeschis deoarece închiderea ar trebui făcută doar după ce eve• Deoarece nu există o metodă standard de scriere a use casenimentul s-a petrecut efectiv! Luând aceasta în calcul, îl întrebăm urilor, fiecare analist de business trebuie să le creeze în funcție dacă închiderea nu ar trebui cumva să fie o acțiune automată exede propria lui viziune asupra cerințelor funcționale. cutată de sistem la data evenimentului (rețineți că am descoperit • Când avem de a face cu proiecte care au scenarii complexe, anterior că pe lângă client, nume și descriere, evenimentul are și use case-urile corespunzătoare pot fi dificil de înțeles de către o dată). clienți sau utilizatorii finali.

Clientul aprobă bucuros ideea noastră, și prin urmare: • Relațiile <<extends>> și <<includes>> folosite în diagramele use case în UML sunt complicat de înțeles și de interpretat, creând confuzie sau ducând la utilizare incorectă.

Concluzii

În concluzie, analiza scenariilor de utilizare este extrem de importantă în sine, indiferent de livrabilele sale, care, bineînțeles sunt și ele extrem de valoroase. Este evident de ce livrabilele sunt valoaroase pentru că ele reprezintă esența funcționalității și comportamentului sistemului, fiind utilizate de o gamă foarte diversă de persoane de la analistul de business, arhitect, utilizator și așa mai departe pentru orice etapă, de la descrierea sistemului până la validarea arhitecturii. Dar de ce este însuși actul de a realiza analiza scenariilor de utilizare important? Pentru că ne permite o descompunere metodică a cerințelor de nivel înalt într-o înțelegere profundă și tot mai îndetaliată a domeniului care ne ajută să desFig. 6 – Diagrama use case completă coperim adevăratele cerințe! Doar prin aplicarea unei analize amănunțite a scenariilor de utilizare putem spera să descoperim În sfârșit se pare că avem diagrama completă, cu toate sce- modelul domeniului (engl. Domain Model) care stă la baza connariile pe care clientul le-a cerut, împreună cu funcționalități de textului și să dezvoltăm un sistem IT aliniat la adevăratele cerințe automatizare și administrare. de business!

Dar, să nu uitam de cerința noastră ascunsă: Managementul prețurilor sălilor! Întrebând clientul, acesta ne spune ca prețurile se modifică foarte rar și nu dorește momentan implementarea acestui scenariu de utilizare în sistem!

Prezentăm diagrama noastră completă clientului, care este foarte mulțumit de rezultat!

Avantajele use case-urilor • Use case-urile sunt cerințe funcționale reale ale sistemului.

• Use case-urile oferă o acoperire foarte bună a actorilor implicați și a nevoilor lor specifice de la produs.

• Scenariile descrise cu ajutorul use case-urilor pot ajuta analistul de business să obțină acceptanță din partea clienților.

• Use case-urile sunt de mare ajutor în activitățile de planificare a proiectului, dacă discutăm despre planuri de release sau prioritizare.

• Use case-urile reprezintă o bază solidă pentru estimări de cost și complexitate.

• Use case-urile reprezintă un mijloc de comunicare între beneficiarii produsului, deoarece conțin actorii și scenariile critice de business.

• Scenariile de business se pot investiga în profunzime pe baza use case-urilor și se pot descoperi scenarii alternative sau

38

nr. 23/Mai, 2014 | www.todaysoftmag.ro

Anita Păcurariu

anita.pacurariu@endava.com Business analyst @ Endava

TODAY SOFTWARE MAGAZINE

management

Abilitățile sunt mai presus de tehnologie

E

voluția profesională a unui dezvoltator software parcurge de obicei următoarele etape: programator junior, programator senior, lider tehnic sau de echipă, uneori arhitect și apoi manager. Această cale este paradoxală: cariera care începe prin a scrie cod se transformă în a nu mai scrie deloc cod. De altfel, cum ai putea să te ții la curent cu toate noutățile care apar în fiecare an în tehnologie?

O nouă schemă a evoluției mult mai interesantă pentru programatorii pasionați, a ieșit la suprafață în anii recenți. Acest articol își propune să evidențieze tocmai aceste noi tipuri de evoluție ilustrate de programatori care încă scriu cod și îi pot ajuta pe alții chiar la 40, 50 sau 60 de ani. Robert C. Martin. Michael Feathers.

Rebecca Wirfs-Brock. De ce sunt ei diferiți? Cum pot să se țină la zi cu schimbările din tehnologie?

Dar serviciile REST? Expunerea resurselor folosind un set limitat de operații oferit de protocolul http? Cu siguranță, această idee a apărut în ultimii ani. Sugestive sunt în acest sens opiniile lui Alan Kay, unul din fondatorii Object Oriented Programming, a avut de spus despre această paradigmă:

“M-am gândit la obiecte ca fiind celule biologice și/sau calculatoare individuale într-o rețea, capabile doar să comunice prin Fundamentele tehnologiei nu se schimbă așa mult mesaje (deci mesajele au apărut la început de tot) - ne-a luat mult Când a fost inventat unit testing-ul? Test Driven Development? timp să ne dăm seama cum putem trimite mesaje într-un limbaj de Folosirea abstracțiilor pentru design ușor de modificat? Principiile programare într-un mod destul de eficient încât să fie util.”3 SOLID? Toate par a fi noi. Cărțile despre ele au fost publicate în ultimii “Fiecare obiect ar trebui să aibă un URL”4 zece ani. Dar sunt cu adevărat noi?

Barbara Liskov a avut la QCon 2013 keynote-ul intitulat “The Al doilea citat este dintr-o prezentare din 1993. Serviciile Power of Abstraction”1. În keynote, ea analizează conversațiile REST, într-o propoziție scurtă, acum 20 de ani. inițiale pe care o comunitate mică de programatori le-a avut desDacă fundamentele tehnologiei nu se modifică, atunci ce pre design modificabil în anii ‘70. Tot în aceeași perioadă, ea a anume se schimbă? dat numele unuia din principiile SOLID, “Liskov Substitution Principle”, printr-o remarcă scrisă pe un bulletin board. Acum 40 Implementarea devine mai simplă de ani! 40 de ani au trecut de când unul dintre principiile de bază Acum douăzeci de ani, dacă un programator trebuia să impledin designul OOP a fost formulat și pe care milioane de programa- menteze o comunicare între două obiecte pe rețea, reușita acestei tori îl folosesc de atunci în fiecare zi. 40 de ani de când abstracțiile operații era condiționată nu numai de multă pricepere ci și de au fost introduse pentru a permite design ușor de modificat. multă magie. O tehnologie (sperăm uitată) numită CORBA era Dar poate și alte aspecte din tehnologie sunt revoluționare. modul standard de a o implementa. Programatorul trebuia să o Serviciile web sunt o idee nouă, nu? Sau arhitectura REST? înțeleagă, să scrie cod într-un anumit mod, să repare problemele

E adevărat că anumite lucruri au trebuit să se întâm- care apăreau și multe altele. Un task de acest gen consuma foarte ple pentru ca serviciile web să apară. O nevoie de business. mult timp, în afară de cazul în care programatorul era capabil să Standardizare. Expansiunea web-ului. Dar, dacă ne uităm atent la vizualizeze octeții care erau transmiși între procese. serviciile web, ideea de design din spatele lor este următoarea: Azi, modul standard de a implementa acest task este de a scrie Compunem funcționalitate complexă din componente mici care fac un serviciu web cu o interfață bine definită, un lucru pe care orice un lucru bine și comunică între ele prin mesaje text. Ciudat! Dar programator îl poate implementa în câteva ore (presupunând că această idee a fost enunțată în anii ‘70 în cadrul principiilor de funcționalitatea este simplă). Programatorul nu are idee cum se design UNIX2: realizează comunicarea între procese (în afara cazului în care vrea să afle), doar că funcționează atunci când codul este scris într-un “Rule of Modularity: Write simple parts connected by clean anumit fel. interfaces.

Acum cincisprezece ani, scrierea unui mic program cerea Rule of Composition: Design programs to be connected to other cunoștințe despre modul în care este alocată memoria. Acest lucru programs. genera multe zile de investigații pentru erori cu mesaj foarte de Rule of Separation: Separate policy from mechanism; separate “ajutor”, “memory corruption error: #FFFFFF”. Azi, majoritatea interfaces from engines. programatorilor au uitat despre pointer-i și alocarea dinamică a Rule of Parsimony: Write a big program only when it is clear by memoriei, pentru că limbajul de programare și platforma au predemonstration that nothing else will do.” luat această funcționalitate.

1 http://www.infoq.com/presentations/programming-abstraction-liskov 2 http://www.catb.org/esr/writings/taoup/html/ch01s06.html

3 http://www.purl.org/stefan_ram/pub/doc_kay_oop_en 4 https://www.youtube.com/watch?v=oKg1hTOQXoY, min. 43:00

www.todaysoftmag.ro | nr. 23/Mai, 2014

39

management Abilitățile sunt mai presus de tehnologie Schimbarile din tehnologie sunt rareori fundamentale. Cel mai des se modifică implementarea. Iar implementarea devine tot mai simplă în timp. Dar dacă implementarea se simplifică, de ce avem în continuare probleme în dezvoltarea de aplicații?

Suntem față în față cu lumea reală

Definiția noastră pentru arhitectură este “când programarea se întâlnește cu lumea reală”. Codul este pur, repetabil, de încredere. Calculatorul nu dă două răspunsuri diferite la aceeași întrebare, decât dacă este programat să o facă.

Lumea reală este diferită. Nu toată lumea folosește același format de dată, calendar sau alfabet. Ora se schimbă în funcție de fusul orar și la viteze relativiste. Server-ele se opresc. Rețelele nu mai funcționează.

Dificultatea fundamentală a programării a fost întotdeauna de a traduce cerințe ambigue în cod foarte precis, rezistent la surprizele din lumea reală.

Dar, pentru mulți ani, această dificultate fundamentală a fost ascunsă sub detalii de implementare. Programatorii aveau destule probleme legate de alocarea de memorie și comunicarea pe rețea încât era dificil să se pună fața în față cu lumea reală. De aceea, mulți erau protejați de ea.

O dată ce implementarea s-a simplificat, dificultatea fundamentală a programării a devenit vizibilă. Azi vorbim mai puțin despre comunicarea între servicii și mai mult despre design modificabil, pentru că schimbarea face parte din lumea reală. Azi vorbim mai puțin despre alocarea de memorie și mai mult despre testare unitară, pentru că toată lumea face greșeli în lumea reală.

Aceasta ne aduce la concluzia:

gata să dea piept cu lumea reală.

Abilități independente de tehnologie

Am menționat în articol câteva abilități independente de tehnologie. Am compilat aici o listă care nu are cum să fie completă, dar credem că este un început bun: Funcționalități ale limbajelor de programare: • Paradigma Object Oriented, • Paradigma funcțională, • Limbaje dinamice, • Sisteme de tipuri “strong” și “weak”.

Abilitățile sunt mai presus de tehnologie

Tehnologiile se modifică. Dar fundamentele programării nu s-au modificat în ultimii douăzeci de ani. Probabil că nu se vor modifica dramatic în următorii zece ani. Dacă vrei să fii în contact cu programarea ani buni de-acum înainte, precum Robert C. Martin, Michael Feathers sau Rebecca Wirfs-Brock, iată ce trebuie să faci: Stăpânește fundamentele programării și abilitățile asociate, nu doar tehnologia în care lucrezi azi.

Acest lucru nu înseamnă ca poți ignora platforma pe care o folosești, ci să înțelegi că este doar o unealtă care te ajută să îți faci treaba: traducerea cerințelor ambigue în cod ușor de modificat, funcțional, precis și

40

nr. 23/Mai, 2014 | www.todaysoftmag.ro

Design software: • Principiile SOLID, • “The four elements of simple design”, • Principiile de design UNIX, • Design patterns OOP, • Pattern-uri de integrare, • Și multe altele.

Programare paralelă: • Resurse “shared”, • Mecanisme de sincronizare, • Moduri de a evita deadlocks, • Pattern-uri de concurență.

Validare: • Testare automată: Piramida testelor.

Structurarea testelor pentru aplicații mari.

• Testarea unitară: Principii. Stub-uri și mock-uri.

• Design by Contract, • Code review, • Pair programming, • (da, este un skill).

Arhitectură: • Gestiunea riscurilor, • Comunicarea constrângerilor tehnice către persoane non-tehnice, • Comunicarea cu dezvoltatorii, • Stiluri de arhitectură: SOA, REST, etc. , • (multe altele).

Refactoring: • Identificarea code smells, • Refactoring manual, • Refactoring folosind unelte automate, • Scrierea de scripturi de refactoring (ex. în vim).

• Înțelegerea rapidă a codului, fără a-l citi prea mult.

Aceste abilități sunt independente de tehnologie. O dată ce le stăpânești, le vei putea folosi într-o tehnologie complet nouă. Aceste abilități îți vor permite să îți crești cariera, indiferent de modificările din tehnologie.

Concluzie

Dificultatea fundamentală a programării a fost întotdeauna de a traduce cerințe ambigue în cod foarte precis și rezistent la problemele care pot apărea în lumea reală. Răspunsul la această provocare a fost dezvoltat în ultimii 50 de ani și nu s-a modificat prea mult în timp.

Singurul lucru care se modifică este implementarea, de obicei devenind mai ușoară.

Stăpânirea fundamentelor programării și a abilităților asociate sunt cel mai bun pariu pentru a crește o carieră independentă de modificările viitoare din tehnologie. Mantra “Abilitățile sunt presus de tehnologie” nu înseamnă că nu trebuie să cunoști tehnologia, doar că pe perioade mai lungi abilitățile sunt mai importante.

Dacă vrei să mergi pe această cale, nu ești singur. Comunitățile de software craftsmanship din orașul tău pot să ajute (de exemplu comunitățile Agile Works din România – http://agileworks.ro) și conferințe de craftsmanship precum I TAKE Unconference – http://itakeunconf.com sunt organizate cu acest scop.

Alătură-te lor și crește-ți cariera ca software craftsman și nu ca viitor manager.

Alexandru Bolboaca

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

Adrian Bolboaca

Lucrul cu codul dificil de modificat: • Scrierea de teste de caracterizare pe cod existent, • Modificarea minimală a codului la repararea unui bug sau adăugarea unei funcționalități,

adrian.bolboaca@mozaicworks.com Programmer. Organizational and Technical Trainer and Coach @Mozaic Works

management

Scrum-ul perfect: Fata Morgană din Agile sau momentul în care trendul bate logica.

C

Bogdan Mureșan

bogdan.muresan@3pillarglobal.com Director of Engineering @ 3Pillar Global

u ceva timp în urmă, un coleg de-al meu a scris un articol foarte interesant despre “Best Practices In Agile Methodologies”. Titlul te anunță că articolul conține un set de reguli care te-ar transforma instant în cea mai agilă persoană de pe planetă. Dar am descoperit cu mare plăcere că de fapt, în practică, aceste reguli sunt mai mult nişte direcţii şi adaptări la mii de situaţii diferite. Acel articol m-a făcut cumva conştient de următoarea situaţie: de câte ori aţi auzit pe cineva spunând: “În proiectul curent noi implementăm scrumul ca la carte”? Este ca şi cum ar zice cineva “am o viaţă perfectă”. Se întâmplă foarte rar şi nu pe Pamânt.

Lucrez bazat pe principiile Scrum deja de opt ani. Am fost implicat în câteva proiecte în acest timp şi, totodată, am avut plăcerea de a discuta cu multă lume şi în afara proiectelor curente, cu prieteni din domeniu şi în acelaşi timp cu multă altă lume în interviuri. Nu-mi aduc aminte să fi spus cineva vreodată că lucrează bazat pe un Scrum ca la carte. Întotdeauna ceva lipsea. Putea fi vorba despre unul din meeting-urile zilnice pe care echipa decidea să nu-l mai ţină dintrun motiv întemeiat. Putea să aibă legătură cu rolul product owner-ului care nu este niciodata bine definit: câteodată îl regăsim în organizaţia clientului, dar după două săptămani de lucru cu el ne dorim cu ardoare să nu-l fi găsit vreodată. Câteodată îl regăsim în organizaţia noastră, foarte bine pregătit, ştiind bine ce are de făcut, dar parcă tot avem o strângere mică de inimă din cauză că nu face parte din echipa clientului, cum ar zice teoria. Altădată poate fi vorba de meetingul retrospectiv pe care, pentru motive bune sau rele, echipa a decis să-l ţină o dată la două iteraţii, şi din nou nu e ca la carte. Voi prezenta trei situaţii în care schimbările nu creează complicații , din contră fiind condiții ale succesului.

Primul exemplu are legatură cu lungimea iteraţiei. Dacă luăm trei echipe diferite având iteraţii cu lungimi de o săptămână, două săptămâni, trei săptămâni şi adresăm oricăruia dintre membrii echipelor întrebarea “Care e lungimea iteraţiei voastre? ”, în toate cele trei cazuri, răspunsul va fi

invariabil: “Ştiu că nu e un Scrum ca la carte, noi lucrăm cu iteraţii de x săptămâni”. Pe forumuri sunt multe dezbateri privind acest aspect al perioadei de livrare, dar ideea de bază ar trebui să fie aceeaşi, şi anume că totul are legătură cu periodicitatea cu care livrăm nu cu lungimea perioadei de livrare în sine.

Cea mai importantă piesă din acest angrenaj e contextul. În unul dintre proiectele noastre, clientul schimbă priorităţile mai ceva decât Liga 1 antrenorii, fiind bazat pe nevoile sistemelor aflate deja în producţie. Analizând contextul şi modul de evoluţie al lucrurilor s-a realizat că eficienţa maximă se va produce prin iteraţii de o săptămână. Ceea ce e în regulă. Avem alt client care datorită modului său de operare şi organizare e capabil să ne dea specificaţii şi priorităţi pe următoarele trei săptămâni, adoptând această lungime pentru iteraţii. Așadar avem două contexte de lucru total diferite, două soluţii diferite şi rezultate bune în ambele cazuri. Concluzia este că până la urmă totul se reduce la analiza contextului, la soluţia optimă pentru acel context sau într-un cuvânt totul se reduce la adaptare. Regulile sunt grozave ca bază de pornire, dar din acel moment adaptarea e esenţială.

O altă situaţie pe care am întâlnit-o destul de des are legatură cu meeting-urile de final de iteraţie. În mod normal avem două meeting-uri la sfârşitul fiecărei iteraţii: un meeting de validare al iteraţiei şi un meeting retrospectiv. Bazat pe faptul că 63% din datele statistice sunt numere aleatorii, se poate

www.todaysoftmag.ro | nr. 23/Mai, 2014

41

management Scrum-ul perfect: Fata Morgană din Agile afirma cu exactitate că 80% din persoanele cu care am vorbit nu sunt mulţumite de felul în care se termină iteraţiile. Această nemulțumire se poate explica fie din cauza faptului că numele meeting-ului e greşit (pentru că eticheta e foarte importantă în zilele noastre nu-i aşa?), fie din cauza unor probleme mărunte cum ar fi: nu este un meeting adevărat de validare deoarece clientul este cel care parcurge ce s-a implementat şi demo-ul nu este făcut de echipă.

Mult prea concentrată pe notaţii, lumea uită care este scopul final al acestor meeting-uri: analiza lucrului efectuat, prezentarea rezultatului către părţile interesate (imposibil să nu găsim pe cineva interesat de rezultatul muncii noastre căruia să-i putem prezenta rezultatul), planificarea a ceea ce a rămas nefăcut şi îmbunătăţirea procesului. Am trecut prin proiecte unde s-a ajuns la concluzia că o eficienţă rirdicată este obţinută atunci când clientul trece prin procesul de acceptare în timpul iteraţiei, astfel ca meeting-ul de validare de la sfârşit nu-şi mai are rostul. De asemenea, am întâlnit proiecte unde retrospectiva asupra întregului proces era facută o dată la trei iteraţii. Contextul a fost cel care a dictat, cazurile fiind de succes. Vă sugerez o mică idee nebunească: dacă facem meeting-ul retrospectiv doar de dragul de a bifa un alt subpunct din lista scrum-ului ideal şi nu folosim în mod real informaţia obţinută pentru a îmbunătăţi procesul, nu este sfârşitul lumii dacă nu-l mai facem. Economisim timpul şi facem ceva ce poate fi mai util în acest context.

Cel mai “controversat” exemplu mi-a venit în minte cu ocazia unei discuţii interne cu colegii. A pornit de la întrebarea: cum integrăm procesul de testare în iteraţie?

La o mică analiză a ceea ce s-a întâmplat

sau ce se întâmplă în proiectele cunoscute, mi-au venit în minte tot atâtea abordări câte proiecte: în unele proiecte estimările story-urilor includeau partea de testare; în altele, partea de testare era decuplată de story-ul în sine, dar era parte integrantă din iteraţie, cu estimare proprie, efectuânduse după terminarea fiecărui task; în altele, partea de testare era decuplată de story şi era planificată pentru iteraţia următoare; în altele partea de testare avea segmentul ei special la sfârşitul iteraţiei, într-o scurtă perioadă de stabilizare a iteraţiei curente; probabil aş mai putea enumera multe alte moduri care diferă între ele în puncte mai mult sau mai puţin importante.

Destul de des perioada de stabilizare de la sfârşitul iteraţiei survine după o aşa numită îngheţare a dezvoltării efective și concentrare doar asupra corectării erorilor. Am auzit în acelaşi timp destule opinii care spun că nu există aşa ceva, că perioada de îngheţare este o aberaţie. Dacă pentru lungimea iteraţiei posibilităţile sunt cumva reduse la seria 1-2-3 săptămâni în acest caz putem avea câte echipe, atâtea particularizări. Ceea ce este mai important este că fiecare poate fi corectă în contextul dat. Sunt momente când ne-am dori cheia universală pentru această ecuaţie deoarece găsirea soluţiei corecte pentru contextul dat poate fi anevoioasă, dar dacă am avea şablonul universal unde ar mai fi distracţia?

Cuvântul Agile, ce apare în faţa cuvântului Scrum vine tocmai de la adaptare, de la încercarea unor noi posibilităţi. În toate aceste situaţii lumea uită rezultatul final. În nici un caz nu vreau să spun că modul în care ajungem acolo nu e important, din contră, dar înainte să hotărâm că ceea ce facem nu ne aduce fericirea din

cauză că un proces nu este urmat 100% ca la carte, am putea să ne răspundem la nişte întrebări: echipa lucrează bine împreună? livrează ce şi-a propus să livreze la timp? clientul este fericit cu rezultatele muncii echipei? De multe ori răspunsul la aceste întrebări este ignorat şi în faţa lui primează trendul, un Scrum ideal la care visăm cu toţii, şi care în contextul dat nu este atins. Şi bineînţeles mai intervine şi natura umană care este dramatic rezistentă la schimbare.

Majoriatatea oamenilor preferă, voluntar sau involuntar, calea ușoară, calea cu care sunt obişnuiţi şi uită exact esenţa a ceea ce înseamnă Agile: adaptare. În mod logic, dacă răspunsul la întrebările de mai sus ar fi da şi nu am şti că totul în lumea aceasta gravitează mai nou în jurul modelului (dezbate, planifică, acţionează, întâlneşte-te zilnic ca să-ţi confirmi că acţionezi, arată, pune bine deoparte în catastif învăţămintele şi repetă iar în cicluri de x săptămâni) atunci toată lumea ar fi fericită. Toţi ar fi împăcaţi că fac ceea ce trebuie, că işi fac treaba corect, ceea ce de fapt înseamnă mii de soluții corecte diferite în mii de contexte diferite.

Concluzia a tot ceea ce am expus mai sus este că nu ar trebui să ne fie frică să ne adaptăm pentru că, aşa cum ziceam, aceasta înseamnă de fapt Agile. Fugim cu îndârjire după un Scrum ca la carte şi nu-i nimic rău în asta. Dar sub nicio formă nu trebuie să ne agăţăm cu disperare de acest trend şi să uităm că Scrum vine în contextul Agile. Este important să ne orientăm concentrarea către Scrum. Este o metodologie care a dat rezultate şi dă în continuare rezultate foarte bune.

Our core competencies include:

Product Strategy

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

42

nr. 23/Mai, 2014 | www.todaysoftmag.ro

Product Development

Product Support

management

TODAY SOFTWARE MAGAZINE

U

5 reguli simple pentru o campanie eficientă

n raport din 2013 arată că 77% dintre consumatori preferă să primească un email în detrimentul unul mesaj în social media sau un SMS. În 2014, o campanie de emailuri cu un conţinut de marketing solid poate fi o unealtă puternică, generatoare de revenue.

Înainte de a planifica orice campanie mesaj (61%) şi buton de call-to-action sau trebuie să vă asiguraţi că: imaginile folosite în email (50%). Alte ele• Baza de date este formată doar din mente care ce pot fi testate sunt: utilizatori care şi-au dat acceptul să • Câmpul de From primescă comunicari pe email din partea • Ora din zi la care se trimite Campania companiei • Ziua din săptămână când se trimite • Utilizatori care au cumpărat un proCampania dus sau un serviciu în ultimele 18 luni • Landing pageul folosit • Audienţa care primeşte emailul

#1. Segmentează-ţi audienţa

Una dintre cele mai frecvente greşeli în email marketing este trimiterea aceluiaşi mesaj către toţi abonaţii. Clienţii sunt diferiţi deci şi aria lor de interese e diferintă.

Aceştia pot fi segmentaţi după: • Produsele preferate / cumpărate • Suma cheltuită în medie pe o comandă / Suma totală cheltuită într-o lună • Interesul acordat emailurilor tale • Experientele avute până acum cu compania ta (pozitive & negative) În funcţie de criteriile de mai sus puteţi genera un mesaj personalizat şi targetat pe interesele clientului.

#2. Testează

Cel mai testat element al unui email este Subject line-ul (75%), urmat de conţinut/

#3. Defineşte un pattern şi trimite emailul la aceiaşi oră

După ce în faza de testare aţi aflat care e momentul optim din săptămânâ şi din zi pentru a trimite o campanie, este recomandat să rămâneţi consistenţi. Evident in funcţie de perioada si sezonul din an, ora şi ziua se pot schimba.

#4. Adaptează-ti layoutul pentru mobil

Stiaţi că 75% dintre utilizatorii de smartphone vor şterge emailul primit dacă acesta nu are layoutul adaptat pentru mobil? De asemenea emailurile deschise de pe un smartphone le-a depasit pe cele deschise pe un PC in 2013.

De aceea e important ca newsletterul dumneavostră să fie optimizat pentru toate deviceurile. Optimizarea se poate face pornind de la layout si continunând cu

conţinutul şi link-urile inserate în email.

#5. Personalizează emailul cât şi user journeyul din spatele lui

Cand planificaţi o campanie de email marketing, faceţi un pas in spate si priviţi campania per ansamblu.

Să presupunem că un magazin de articole sportive va intra în curand în perioada reducerilor. În momentul în care utilizatorul deschide emailul primit şi e interest de un articol, odată ajuns pe pagina produsului, mesajul din email trebuie reiterat. Se pot crea inclusiv landing pageuri speciale care să uşureze şi să scurteze procesul de cumpărare.

Odată bifate regulile de mai sus nu uitaţi de cea mai importantă regulă şi anume să cereţi feedback clienţilor dumneavostră!

Selectaţi-vă clienţii cei mai ataşaţi de brand şi trimiteţi-le un email cu un chestionar de feedback. Veţi descoperi lucruri noi despre compania dumneavostră.

Ruxandra Tereanu

ruxandra.tereanu@betfair.com Conversion Analyst @ Betfair

www.todaysoftmag.ro | nr. 23/Mai, 2014

43

management

Big Data şi Social Media: marea schimbare

D

e când platformele social media s-au răspândit în viaţa noastră de zi cu zi, volumul de date schimbat prin intermediul acestora a crescut vertiginos. Scriem texte ce descriu o idee, o părere, un fapt; încărcăm imagini şi materiale video; ne manifestăm preferinţele folosind câteva butoane simple (“like”, “favorite”, “follow”, “share”, “pin” etc.); acceptăm în reţea oameni pe care îi ştim foarte bine în viaţa reală şi oameni pe care nu i-am întâlnit niciodată, probabil nici nu îi vom întâlni … Totul apare în reţea aproape în timp real!

Dintr-o dată, ne dăm sema că unitatea de măsură a datelor manevrate într-o perioadă de timp anume ajunge la ordinul de exabyte. Această masă de date nu este doar mare în volum, dar este şi extreme de diversă şi se mişcă cu viteze incredibile.

Informaţia conţinută este relativ incomensurabilă. Cert este că Facebook, Twitter, Pinterest pot vedea când ne îndrăgostim, în ce stare suntem, unde ne aflăm şi alte comportamente sau stări pe care decidem să le arătăm. Întrebarea este: ce putem face cu această cantitate masivă de date create prin intermediul social media?

Fapte rapide

Conform informaţiei colectate de IBM într-un raport realizat în baza unor surse furnizate de Mc Kinsey Global Institute, Twitter, Cisco, EMC, SAS, MEPTEC, QAS – merită să acordăm atenţie următoarelor fapte: Legate de volum: • Facebook ingerează aproximativ de 500 de ori mai multe date zilnic decât New York Stock Exchange (NYSE).

• Twitter stochează cel puţin de 12 ori mai multe date zilnic decât NYSE. • Se estimează că cca. 2.5 quintilioane byte (23 trilioane gigabyte) de date sunt create zilnic.

• 6 miliarde de oameni din 7 miliarde (populaţia curentă globală) au telefoane celulare.

• Se estimează că circa 40 zettabyte (43 trilioane gygabyte ) de date vor fi create până în 2020 (de 300 de ori mai mult decât în 2005).

• Maşinile moderne au aproape 100 senzori ce monitorizează parametric precum nivelul comnbustibilului şi presiunea în roţi.

• Până în 2016 se preconizează existent a cca. 18.9 miliarde de conexiuni de reţea (cca 2.5 conexiuni de persoană pe glob) .

Legate de veridicitate: • 1 din 3 conducători de afaceri nu au încredere în informaţia folosită pentru luarea deciziilor.

• 27 % din respondeţii studiului nu ştiau cât din datele lor erau inexacte.

Ce înseamnă de fapt “Big Data”?

La prima vedere putem descrie “Big Data” ca seturi foarte mari şi foarte complexe, imposibil sau greu de gestionat cu instrumentele clasice de procesare a datelor. Dacă noi am preluat sintagma din limba engleză, trebuie să notăm ca specialiştii francezi îl traduc în prezent cu sintagma “grosses données” (“date mari” “big data”) sau “données massives” (“date masive” massive data) sau chiar şi “datamasse” (datamasă) precum “biomasă”. Noutatea conceptului şi limitele neclare ale definiţiei împiedică oarecum adaptarea locală a termenului. În 2012, Gartner (care a conturat oarecum termenul la începutul anilor 2000) a actualizat definiţia astfel: “Big data înseamnă informaţii de mare volum, mare viteză şi/sau mare varietate ce necesită noi forme de procesare pentru a facilita luarea deciziilor, descoperirea semnificaţiilor şi optimizarea proceselor.”

Definiţia de mai sus conturează dimensiunile Big Data – cei 3V – volum, viteză, varietate. Totuşi, ceea ce este de reţinut din această formulare este că deschide perspective multiple asupra Legate de diversitate (varietate): conceptului Big Data în sine. Recent un al 4-lea V a fost ataşat • 300 miliarde de unităţi de conţinut sunt distribuite pe definiţiei: veridicitatea. Totodată merită notate şi cele trei perspecFacebook în fiecare lună. tive aplicate conceptului: cea tehnologică, cea de proces şi cea de • 400 milioane de tweet-uri sunt trimise zilnic de către circa afaceri.

200 milioane de utilizatori activi .

• 4 miliarde de ore video sunt vizionate pe youtube în fiecare Analizele Social Media şi Big Data lună.

Una dintre caracteristicile esenţiale ale Big Data provenite din • Până la finele lui 2014, se estimează că vor exista cca 420 social media este că sunt în sau aproape în timp real. Acest aspect milioane de dizpozitive portabile de monitorizare a sănătăţii. oferă analizei exploratorii o perspectivă largă legat de ceea ce se întâmplă sau ce este pe cale să se întâmple la un moment dat întrLegate de viteză (velocitate): un anumit loc.

• NYSE captează 1 TB de informaţie în fiecare sesiune Fiecare trăsătură fundamentală a datelor masive (Big Data) tranzacţională. poate fi înţeles ca un parametru pentru analiza cantitativă,

44

nr. 23/Mai, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE calitativă şi exploratorie.

• Volumul - Există două tipuri de date pe care platformele social media le colectează: structurate şi nestructurate. În plus, sursa de colectare variază: HTM (human to machine), MTM (machine to machine) sau prin senzori. Pentru specialiştii în ştiinţe sociale, masa totală a datelor le permite definirea mai multor clase, mai multor criterii şi rafinarea seturilor şi subseturilor de analize.

• Varietatea - Formatul datelor variază de la documente text, tabele la date video, date audio şi multe altele. Acest fapt creşte complexitatea analizei datelor; în consecinţă, modelele statistice vor fi de asemenea ajustate pentru a obţine informaţii viabile.

• Viteza - este un aspect cheie în analiza tendinţelor şi a fenomenelor în timp real. Cu cât datele sunt generate. Distribuite şi înţelese mai rapid, cu atât pot dezvălui mai mulă informaţie.

Analizând viteza de propagare a unui anumit set de date, putem distinge impactul potențial al informaţiei conţinute asupra unui grup social specific dintr-un teritoriu definit. Un alt aspect interesant este că putem totodată monitoriza lanţul de distribuţie al datelor.

Veridicitatea

Pentru analistul de date experimentat este esenţială capacitatea de a evalua conformitatea, acurateţea şi sinceritatea datelor supuse analizei. Aici discuţia se poartă în jurul responsabilităţii generatorului initial al datelor, scopului pentru care datele sunt emise şi reacţiilor receptorilor.

tendințe și de a emite previziuni, de a gestiona riscuri de toate tipurile (comercial, de asigurare, industrial, natural) și fenomene diverse (sociale, politice, religioase, etc.). În geodinamică, meteorologie, medicină și alte domenii exploratorii – de la big data se așteaptă o îmbunătățire a modului în care procesele se desfășoară și în care se interpretează datele.

Marea translație

Pentru a răspunde la întrebarea noastră inițială, cel mai bun lucru pe care îl putem face cu masa de date este de a o EXPLORA. Pe cât de simplă pare la prima vedere, afirmația de mai sus are un impact puternic asupra modului în care vedem analiza datelor din viitorul apropiat. Modelul migrează de la cel tradițional în care planificăm, colectăm și abia apoi analizăm datele la un nou model în care colectăm toate datele posibile și abia apoi încercăm să identificăm tiparele (patterns) semnificative.

Noul model de analiză are riscurile proprii, dar deschide totodată calea către o nouă generație de analiști de date și oameni de știință în acest domeniu. În acesată ordine de idei, consider migrarea de la un model la altul ca rezultatul major al impactului pe care social media l-a avut până acum asupra modului în care percepem datele masive (big data).

Managementul Big Data

Una din cele mai mari provocări a momentului de faţă este construirea instrumentelor şi sistemelor cu care să gestionăm Big Data. Deoarece livrarea informaţiilor în timp real sau aproape în timp real este una din trăsăturile cheie ale analizei datelor masive, cercetările urmăresc să pună bazele unor sisteme de management al bazelor de date capabile să corespundă noilor cerinţe.

Tehnologiile în curs de dezvoltare cuprind următoarele: Stocare: Pentru stocarea şi recuperarea datelor, dezvoltările NoSQL care sunt în prezent baza sistemelor actuale sunt reprezentate de MongoDB, DynamoDB, CouchBase, Cassandra, Redis şi Neo4j. În prezent acestea sunt cunoscute ca cele mai performante baze de date de documente, key value, coloane, grafice şi distribuite.

Software: Setul Apache Hadoop include Cloudera, HortonWorks şi MapR. Obiectivul principal al acestora este de a extinde utilizarea platformelor big data către o gamă de utilizatori mai diversă şi voluminoasă. În al doilea rând, aceste tehnologii se concentrează pe creşterea fiabilităţii platformelor de date masive, pe îmbunătăţirea capacităţii de a le gestiona şi de a controla indicatorii de performanţă.

Explorarea datelor şi descoperirea cunoştinţelor: explorarea şi descoperirea analitică a datelor masive este un subiect fierbinte din domeniul cercetării şi inovării. Un avans major a fost făcut de Datameer, Hadapt, Karmasphere, Platfora sau Splunk.

Oportunităţi

Când avem de-a face cu un nivel de ordine cu totul nou, captarea, stocarea, cercetarea, distribuirea, analiza şi vizualizarea datelor trebuie redefinită. Perspectiva gestionării datelor masive sunt enorme și de nebănuit!

Adeseori este pomenită posibilitatea de a explora informațiile distribuite în media, de a obține cunoștințe și de a evalua, analiza

Diana Ciorba

diana.ciorba@codespring.ro Marketing Manager @ Codespring

www.todaysoftmag.ro | nr. 23/Mai, 2014

45

programare

Platforma OnyxBeacon iBeacon

i

Beacon este un termen popular printre dezvoltatorii de aplicații mobile în prezent. Un dispozitiv iOS cu cel puţin iOS 7 instalat sau un dispozitiv Android, cel puţin de versiunea 4.4, este capabil să pornească aplicaţii de pe dispozitivele din apropiere. Este în principal folosit pentru poziţionarea în spaţii interioare, vi-l puteţi imagina drept un GPS complementar, deoarece poate să ofere informaţii cu privire la locul în care se află utilizatorul, în interior: este în apropierea raionului de pantofi sau se uită la insula de ciocolată dintr-un hipermarket? iBeacon funcţionează pe Bluetooth Low Energy, cunoscut drept Smart BLE. Câteva dintre aplicaţiile potenţiale ar fi: 1. dispozitivele specifice iBeacon ar putea trimite notificaţii despre obiectele din apropiere care sunt de vânzare sau informaţii despre produsele la care se uită clienţii.

2. Plăţile s-ar realiza prin mobil în loc de NFC. 3. Furnizarea de informaţii valoroase în timp ce te afli în interiorul unei clădiri.

seama de context şi de care clientul ar putea avea nevoie atunci când se află într-o anumită locaţie.

Acum, cine este OnyxBeacon şi care este rolul nostru în acest ecosistem?

Să luăm un exemplu tipic al unui caz de utilizare iBeacons.

Mihai este manager al unui lanţ de vânzare en detail de produse electronice. Geanina este o clientă a lanţului de magazine. Ea are aplicaţia pe mobil a lanţului respectiv de magazine pe iPhone-ul său 5S. Ea se află într-un anume magazin şi permite aplicaţiei sale pe mobil să îi monitorizeze locaţia din interiorul magazinului (ea se uită la un televizor Sony). Mulţumită tehnologiei iBeacon, Mihai îi poate oferi Geaninei oferte relevante pentru istoria ei de cumpărături şi locaţia sa curentă (de exemplu, un discount pentru televizorul Sony la care ea se uită). Şi acesta este doar un exemplu.

Suntem un startup din Cluj care a fost fondat pentru că dorim să ajutăm dezvoltatorii de mobile să îmbunătăţească experienţa utilizatorilor lor. Noi dezvoltăm propriile noastre emiţătoare, care sunt compatibile cu iBeacon şi pot fi folosite de către companii în magazinele lor pentru a permite caracteristici de proximitate în aplicaţiile lor. Pe lângă asta, am dezvoltat şi software-ul pentru a-i ajuta pe dezvoltatorii de mobile să utilizeze această tehnologie. În primul rând avem iOS şi Android SDKs, pe care dezvoltatorii de mobile le pot utiliza pentru a profita de funcţionalitatea emiţătorului. De asemenea am dezvoltat şi un cloud backend, care este utilizat pentru managementul Beacon, planificarea avansată a disponibilităţii conţinutului şi acces API. Aplicaţiile mobile pot integra SDK pentru a spori suportul pentru emiţătoare şi backend API.

Cum se auto-identifică un iBeacon?

Componentele platformei OnyxBeacon

Un dispozitiv iBeacon se identifică printr-o combinaţie de trei valori care pot fi personalizate:UUID (128 bit), major şi minor (câte 16 bit fiecare). În exemplul pe care l-am avut mai sus, UUID ar fi un identificator pentru reţeaua de magazine, majorul ar putea identifica numărul magazinului, iar minorul ar putea identifica o locaţie anume din interiorul magazinului (punctul de intrare în magazin, un anumit raion sau punctul de ieşire). Semnalul pe care îl emite iBeacon-ul îţi permite să calculezi distanţa aproximativă de la smartphone şi să afli unde se află utilizatorul în interiorul unei locaţii.

Există probleme de confidenţialitate în ceea ce priveşte iBeacon-urile?

Una dintre cele mai importante concepţii greşite despre iBeacon-uri este aceea că ele pot să te urmărească. Acest lucru nu este corect. Singurul lucru pe care dispozitivele îl fac este să emită un semnal pentru a informa aplicaţia în legătură cu proximitatea.

Ele furnizează date despre locaţia interioară în care te afli, cu o precizie mai mare decât un GPS. Acesta este un avantaj pentru că pune la dispoziţia clientului informaţii specifice relevante, care ţin

46

nr. 23/Mai, 2014 | www.todaysoftmag.ro

OnyxBeacon iOS SDK iOS OnyxBeacon SDK permite dezvoltatorilor iOS să adauge suport pentru iBeacons şi OnyxBeacon backend în aplicaţiile lor, oferind utilizatorilor experienţa iBeacon. SDK este uşor de integrat şi utilizat; cu numai câţiva paşi, aplicaţia va începe să primească notificaţii de la OnyxBeacon backend. iOS OnyxBeacon SDK acoperă prelucrarea protocolului iBeacon, managementul iBeacon, gestionarea notificaţiilor, comunicarea cu OnyxBeacon backend şi expune apeluri simple pentru primirea notificaţiilor, gata de utilizat şi de a fi prezentate utilizatorilor. iOS SDK este oferit în forma unei aplicaţii mostră care conţine următoarele module: • librăria OnyxBeacon – conţine logica pentru gestionarea Beacons, Coupons, Beacon management.

• Sample App – o aplicaţie care arată cum să integrezi librăria şi să utilizezi interfeţele oferite de librărie.

• AFNetworking – o librărie terţă, parte utilizată pentru procesarea cerinţelor.

TODAY SOFTWARE MAGAZINE • cadru Facebook – utilizat în aplicaţia mostră pentru a obţine informaţii despre utilizator.

• Media – Imaginea arătată pe cupon.

Perioade de timp

OnyxBeacon backend defineşte mai multe entităţi flexibile Definesc perioadele de timp utilizate în conjuncţie cu Planurile care definesc experienţa utilizatorului final. Fiecare entitate se sca- şi Cupoanele. Un anumit Cupon va fi servit utilizatorului final lează pentru a asigura flexibilitate în definirea conţinutului care va într-o anume perioadă de timp, pentru un Plan. fi oferit utilizatorului Aplicaţiei.

Următoarele proprietăţi pot fi definite: • Nume - ~ , Entităţile OnyxBeacon Backend • Descriere - ~, • Cupon – Cuponul care va fi utilizat , Fasciculele aplicaţiei (Application Bundles) • Start – momentul în care cuponul devine activ, Definesc informaţiile necesare şi simbolurile de autentificare • Stop – momentul când cuponul nu mai este activ . cerute pentru o aplicaţie specifică (care implementează SDK) pentru a comunica în mod corespunzător cu OnyxBeacon API. Planuri Pot fi definite următoarele proprietăţi: Definesc Planul de Promiţie pentru un anume Beacon (emi• Nume – Nume Aplicaţie – utilizat pentru a distinge diferi- ţător). Pot fi create mai multe planuri pentru a cuprinde perioade tele aplicaţii care utilizează SDK. de timp diferite şi ⁄ sau emiţătoare diferite.

• Descriere – utilă pentru a adăuga comentarii şi date care nu Pot fi definite următoarele proprietăţi: sunt critice despre aplicaţie.

• Nume - ~ , • Identificator – Identificatorul aplicaţiei – acesta trebuie să fie • Descriere - ~ , cel disponibil când aplicaţia a fost publicată în magazinul pentru • Beacon (emiţător) – emiţătorul pentru care se aplică planul, mobile sau pe perioada procesului de dezvoltare.

• Perioada de timp – perioada de timp utilizată (în consecinţă, • Secret – secretul iniţial pentru aplicaţie, cerut în autentificare. ce cupon va fi oferit utilizatorului final).

UUID-urile companiei

Promoţii

Definesc o listă de identificatori de emiţătoare (Beacon) disDefinesc o Promoţie, având mai multe Planuri şi o perioadă ponibili, care vor fi mai târziu utilizaţi pentru a identifica în mod de timp în care aceasta este valabilă. Acest fapt oferă o mai mare unic un emiţător (Beacon). flexibilitate privind modul în care conţinutul va fi oferit utilizatoPot fi definite următoarele proprietăţi: rului final.

• Nume - ~ , Pot fi definite următoarele proprietăţi: • Descriere - ~ , • Nume - ~ , • Identificatori – un identificator unic (format UUID) utilizat • Descriere - ~ , în conjuncţie cu alte proprietăţi pentru a identifica în mod unic • Start ⁄ Stop – perioada de timp în care promoţia este valabilă un emiţător (Beacon) – Acesta este necesar. , • Planuri – planurile disponibile pentru promoţie.

Emiţătoare (Beacons)

Definesc o listă de emiţătoare unice pentru a fi folosite în conjuncţie cu alte entităţi şi pentru a oferi date utilizatorului final.

Pot fi definite următoarele proprietăţi: • Nume - ~ , • Descriere - ~ , • UUID – un UUID definit pentru companie în pasul anterior, • Major ⁄ Minor – proprietăţi care ajută la definirea unui emiţător (Beacon) unic. Mai multe emiţătoare (Beacons) pot avea acelaşi UUID, dar necesită o combinaţie unică Major ⁄ Minor • Latitudine ⁄ Longitudine ⁄ Altitudine – utilizate pentru a defini locaţia finală a unui emiţător (Beacon), odată instalat.

Derularea activităţii

Crearea elementelor necesare unei promoţii necesită ca alte elemente să fi fost definite, sau să fie definite pe loc. O derulare tipică va urma ordinea de mai sus, definind fiecare element pe rând. Administratorii elementelor permit administratorului să definească noi elemente „din zbor” în interiorul altor elemente.

Pentru aceasta, faceţi click pe butonul „Add new” din partea dreaptă. Elementele mai pot fi create de asemenea şi prin utilizarea secţiunii „Setup Entities”, accesibilă din meniul de sus. Noile elemente create aici vor trebui legate manual odată ce au fost create, sau prin utilizarea opţiunii „Add new” în timpul definirii lor.

Derularea procesului, cu dependenţele cerute, se poate Media rezuma la ceea ce urmează: Application Bundles (Fasciculele Utilizată pentru a defini unităţi media oferite utilizatorului aplicaţiei)-> Company UUIDs (UUID-urile companiei)-> aplicaţiei. În prezent suportă imagini care sunt oferite cu Coupons. Beacons(Emiţătoare) -> Media -> Coupons (Cupoane) -> Time Frames (Perioade de timp)-> Plans (Planuri)-> Promotions Coupons (Promoţii).

Definesc conţinutul care va fi oferit utilizatorului final Pot fi definite următoarele proprietăţi: Apeluri API Backend • Nume - ~ , Dacă cineva are un backend diferit şi doreşte să utilizeze • Descriere - ~ , SDK-ul nostru pentru iOS şi Android, îi putem pune la dispoziţie • Mesaj – un mesaj arătat utilizatorului odată ce Cupon-ul apeluri api. Toate apelurile api folosesc metoda POST şi sunt efeceste oferit , tuate utilizând un server URL. Serverul URL poate fi configurat în • URL – utilizatorul va fi redirecţionat către acest URL atunci SDK pentru a indica o adresă diferită de când face click pe Cuponul servit pe dispozitivul mobil , www.todaysoftmag.ro | nr. 23/Mai, 2014

47

programare Platforma OnyxBeacon iBeacon https://connect.onyxbeacon.com/api.php

Metrici Cupon

Apelul metrici cupon este specific pentru modulul de marketing mobile şi poate fi utilizat pentru a notifica backend-ul cu privire Găsirea UUID-urilor la acţiunile utilizatorilor. Informaţiile sunt cuprinse în dicţionarul La pornire, SDK va face o cerere pentru a obţine lista UUID- couponMetrics şi are două chei: urilor din proximitate care sunt configurate pentru identificatorii • couponid – id-ul conţinutului oferit de backend, fascicul oferiţi în unitatea de cerere.

• couponaction – una dintre valorile deschise sau tastate este • Cerere setată în funcţie de acţiunea utilizatorului, { Acest apel poate fi folosit pentru orice tip de conţinut definit “function”:”getUuids”, “parameters”: de dezvoltator. { • Cerere “identifier”: “com.example.app”, Unităţile de cerere şi răspuns sunt obiecte JSON.

}

}

“installid”: “device identifier string”

• Răspuns [‘uuid1’, ‘uuid2’]

Răspunsul conţine o gamă de UUID-uri de proximitate pentru care aplicaţia ar trebui să monitorizeze regiunile.

Solicitarea conţinutului pentru emiţătoare {

}

• Solicitare “function”:”getContentForBeacons”, “parameters”: { “identifier”: “com.example.app”, “installid”: “device identifier string” “beacons”: ( { “uuid”: “uuid1”, “major”: “majornumber”, “minor”: “minornumber” }, { “uuid”: “uuidn”, “major”: “majornumber”, “minor”: “minornumber” }, ... ) }

{

“function”:”setMetrics”, “parameters”: { “identifier”: “com.example.app”, “installid”: “device identifier string” “couponMetrics”: { “couponid”: “cid”, “couponaction”: “opened” } }

Vom lua parte la Techsylvania, conferinţa organizată la hackathon, unde vom avea emiţătoarele noastre şi SDK-urile pe care le puteţi utiliza pentru a oferi experienţe deosebite utilizatorilor de mobile.

• Răspuns Răspunsul este un obiect JSON primit de la server, iar structura este definită de către dezvoltator.

Metrici utilizator • Cerere Dicţionarul de informaţii utilizatori este oferit de cheia userMetrics din dicţionarul de parametri. {

}

“function”:”setMetrics”, “parameters”: { “identifier”: “com.example.app”, “installid”: “device identifier string” “userMetrics”: { “userkey”: “uservalue”, ... } }

Informaţia despre utilizator trimisă înapoi la backend este specifică pentru dezvoltator. Aplicaţia mostră (Sample App) utilizează informaţii despre utilizatorii Facebook pentru alte procesări şi analize pe server.

48

nr. 23/Mai, 2014 | www.todaysoftmag.ro

Bogdan Oros bogdan@onyxbeacon.com Co-Fondator @Onyx Beacon

HR

TODAY SOFTWARE MAGAZINE

De-adevăratelea!

A

vem așteptări de la noi să fim ființe raționale. Poate cu câteva excepții. Dar cu siguranță avem așteptări ca ceilalți să fie niște ființe raționale. Aceasta este cel mai vizibil în mediul organizațional. Oamenii trebuie să se comporte rațional, logic, rezonabil. Ne așteptăm ca noi, dar mai ales ceilalți să analizeze situațiile obiectiv, să decidă rațional cursul de acțiune și apoi să îl implementeze așa cum a fost decis. Ne așteptăm să fim niște mașini de calcul care folosesc algoritmi predictibili, corecți și care operează fără erori.

Ne aștepăm la toate acestea de la colegii noștri, de la oamenii din echipă, de la lideri, de la clienți, de fapt de la toată lumea.

Input complet de informație, stocare curată, procesare obiectivă/rațională și output complet.

Nu voi intra în tot ceea ce înseamnă partea cognitivă. Îmi aduc aminte că numai introducerea a fost o materie de un an la Psiho. Voi prezenta doar câteva aspecte care ar trebui să ne facă să ne re-gândim la felul în care gândim de fapt. Cred că dacă reușim să vedem cum operăm de fapt vom ajunge să operăm mult mai bine decât dacă continuăm să pretindem că suntem mașini de calcul raționale.

Putem începe de la faptul că realitatea nu va fi niciodată percepută obiectiv.

Simpla percepție a realității distorsionează datele chiar și numai pentru a le stoca. Ca să putem stoca datele pentru a le accesa mai târziu trebuie să le conectăm de alte date.

Când percepem, o facem folosind niște filtre care aleg ce date vor să stocheze pentru ca apoi să le transforme în date stocabile (gen 1001001). Acesta este doar începutul pentru că pe măsură ce datele stau stocate, ele de fapt interacționează cu alte date, se schimbă, se șterg sau chiar creează date noi.

Apoi,în momentul când căutăm și folosim datele respective, când le extragem, ele sunt din nou modificate, accesate selectiv și tot așa. Nu avem nici o șansă să percepem, stocăm sau să accesăm date curate.

Gândiți-vă dacă ar trebui să programăm pe un asemenea sistem. Ei bine, o facem de fapt zi de zi. În continuare, vă voi expune doar o fracțiune din toate acestea. Vom prezenta câteva dintre Distorsiunile Cognitive. Sunt multe, doar că le vom aborda pe acelea care ne fac viața în organizații dificilă. Pentru o

lista mai extinsa vă invit să dați un search cu ”wikipedia list of cognitive biases” .

Având în vedere că a fost luna martie, în multe organizații s-au derulat evaluarile de performanță (quarterly performance reviews). Acele situatii în care liderii și oamenii din echipă se întâlnesc ca să dezbată performanța. Sistemele de performanță au ele suficiente probleme la cum sunt construite, însă aceasta e cea mai mică dintre ele. Haideți să trecem peste ea și să presupunem, de dragul dezbaterii, că sunt în regulă.

Problema cea mai mare este că ele sunt folosite de oameni și pentru oameni.

Aici începe o nouă listă de alte probleme.

Sistemele respective sunt proiectate pornind de la asumpția raționalității și obiectivității umane. Principiul este că dacă colectăm date despre performanță și discutăm despre ele, atunci totul e în regulă.

Dar starea de fapt este alta. Oamenii implicați în acel proces vor veni cu următoarele reguli de procesare și operare încorporate în sistem denumite distorsiuni cognitive.

Distorsiunile cognitive sunt tendințe de a gândi într-un anumit fel. Ele reprezintă o tendință spre deviații sistematice.

D i n p e rs p e c t iv a c e lu i c are d ă feedback-ul: 1. Cea mai evidentă eroare în acțiunile de performance review este legată de ce ne amintim (adică informația cu care operăm pe parcursul sesiunii de feedback).

Fundamental attribution error presupune tendința de a atribui pentru comportamentele unei persoane prepodenrent cauze interne (legate de persoană) în același timp minimizând efectul factorilor contextuali sau situaționali. Mai specific, atunci când

cineva are o performanță crescută sau scăzută, vom avea tendința să presupunem că acea performanță este datoarată caracteristicilor personale (personalitate, motivație, amibiție, intenție, atitudine, competență), diminuând impactul perceput al contextului sau chiar al norocului. Acest lucru se vede cel mai bine în limbajul folosit pe parcursul unei evaluări, el fiind plin de diferite conjugări ale verbului a fi. (”te rog să fii mai responsabil pe viitor”, ”nu ai fost proactiv când ai lucrat pe proiectul x”).

Negativity effect se referă la tendința oamenilor, atunci când evaluează cauzele unui comportament al unei persoane pe care nu o plac, să lege cauzele pentru comportamentele pozitive de context și cauzele comportamentelor negative de trăsături.

Negativity bias, în completare, se referă la tendința de a ne aduce aminte mai ușor de amintiri neplăcute, erori, deviații.

Observation selection bias presupune tendința de a observa lucruri pe care nu le-am observat anterior și a presupune că frecvența acestora a crescut, ajungem în faza în care în discursul sesiunii de feedback încep să apară cuvinte precum întotdeauna pe lângă verbul a fi. Sună familiar?

2. Confirmation bias se referă la tendința de a căuta, interpreta și a ne aminti informații care tind să confirme ceea ce credem deja. Astfel fiecare dintre părți va avea amintiri foarte diferite cu privire la ce s-a întâmplat în trecut.

3. Empathy gap care se referă la tendința de a subestima influența sau intensitatea emoțiilor (a noastre sau ale celor din jur).

Această superputere pe care ne-o atribuim ne duce să presupunem că felul în

www.todaysoftmag.ro | nr. 23/Mai, 2014

49

HR De-adevăratelea! care ne simțim în acel moment sau felul în care simțim față de persoana din fața noastră nu va influența percepția pe care o avem asupra performanței. Acest lucru ne face să considerăm percepția noastră ca fiind statistic semnificativă sau obiectivă, lăsând foarte puțin loc pentru păreri diferite.

4. Un efect interesant este dat de hot hand fallacy care se referă la eroarea de a crede că persoanele care au avut succes (performanță) în trecut, au o șansă mai mare de a avea succes (performanță) în prezent. Putem să ne uităm și la opusul acestei distorsiuni – performanță scăzută trecut/prezent , combinând această distorsiune cu cea de confirmation vă las pe voi să o detectați în sala unde se discută performanța.

Din perspectiva celui care primește feedback-ul: 1. Avem tendința de a supra-raporta caracteristici sau comportamente dezirabile și de a sub-raporta caracteristici sau comportamente nedezirabile (social desirability bias) aspect care influențează ambele parți ale baricadei în situația de performance review.

2. Pe lângă acest tip de distorsiune avem și Lake Wobegon effect care ne face să supraestimăm calitățile dezirabile (în număr, intensitate sau nivel) și să subestimăm cele nedezirabile atunci când ne comparăm cu alții.

3. Self serving bias adaugă la cele de mai sus tendința de a ne asuma mai multă răspundere pentru succese decât pentru eșecuri precum și tendința de a evalua informații ambigue într-un fel în care este benefic pentru imaginea noastră.

4. Egocentric bias ne duce la a ne aminti trecutul într-un mod care ne este benefic- ne aducem aminte de succese ca fiind mai mari și mai dificile decât au fost. Acesta împreună cu spottlight effect (tendința de a supraestima măsura în care cei din jur sunt atenți și observă propriile comportamente) ne face să ne fie destul de dificil să lucrăm cu aceeași informație.

50

False consensus bias se referă la tendința oamenilor de a supraestima gradul de acord al celorlalți cu părerea proprie ajunge să aducă în discurs exprimări de genul toți cred asta, toți au observat, toți sunt de acord.

Illusion of transparency ne duce la supraestimarea abilității personale sau a celorlalți de a ne cunoaște/înțelege cum funcționăm.

Lista este foarte lungă și vă invit să evitați google effect atunci când o citiți pe toată.

Având în vedere toate acestea, pe mine personal nu mă miră că e necesar așa un efort fantastic în completarea activităților de quarterly review la timp. Eu aș avea cu siguranță tendința fie să procrastinez, fie să percep toată activitatea ca fiind inutilă . Înainte să închei vă mai dau trei distorsiuni la care să vă gândiți, mai ales când vă aduceți aminte de acest articol: Bias blind spot este tendința de a ne vedea ca fiind mai puțin biased decât cei din jur și de a vedea mai ușor distorsiunile la ceilalți.

Conservatism (Bayesian) este tendința de a ne schimba foarte puțin părerile atunci când ni se prezintă informații noi.

Mai adăugăm la lista noastră și reactance care se referă la tendința de face sau a gândi exact pe dos față de ceea ce se cere/ așteaptă doar pentru a menține percepția că libertatea noastră de a alege/independența noastră nu sunt atinse.

Ce putem face în legătură cu toate acestea? Singurul lucru este să știm și să ținem minte că evaluarea performanțelor nu are nici o legatură cu ”cine are dreptate”.

Adevărul este că nimeni nu are dreptate și e ok, pentru că nu despre aceasta e vorba.

Atunci când o facem ne uităm în trecut, dar o facem doar pentru a vedea ce ”schimbăm sau menținem” în viitor. Accentul în discuția despre performanță este pe ”ce avem nevoie” (fie că suntem lideri sau nu) pentru ca pe viitor performanța să fie la nivelul dorit într-un fel în care ambele părți găsesc procesul ca fiind unul plăcut și în același timp construiesc o relație pozitivă.

Cadrul prin care ne uităm la evaluarea performanțelor este: ce s-a întâmplat

nr. 23/Mai, 2014 | www.todaysoftmag.ro

în trecut, ce menținem din ce s-a întâmplat în trecut, ce schimbăm și cum arată schimbare și de ce avem nevoie ca schimbarea și menținerea să se producă.

Deși vina sau rușinea ne dau iluzia că am câștigat argumentarea, nu ne ajută deloc. Chiar dacă cealaltă parte a cedat argumentelor noastre, nu înseamnă că ceva se va schimba pe viitor. Consecințele emoțiilor de vină sau rușine creează doar comportamente de neputință, retragere, apărare. Oamenii trebuie să se simtă empowered pentru ca pe viitor lucrurile să meargă mai bine.

Deși reprezintă o permanență, distorsiunile cognitive nu vor putea provoca atâtea daune pentru că acolo unde operează, nu va mai fi un conținut relevant.

Antonia Onaca

anto@aha-ha.com de aproape 10 ani trainer, psiholog, consultant sub formă de antreprenor, intraprenor și antreprenor din nou

programare

TODAY SOFTWARE MAGAZINE

Procesoare de șabloane pentru dezvoltare web în Java

Î

n multe dintre proiectele informatice întâlnite avem de-a face cu situaţii în care trebuie să procesăm text, să generăm rapoarte, scripturi sau cod sursă. Adeseori, aceste probleme pot fi rezolvate cu ajutorul unor unelte numite procesoare de șabloane. Totuși, cel mai des întâlnit scenariu pentru utilizarea procesoarelor de şabloane este acela al dezvoltării de aplicaţii web, unde s-a observat nevoia separării logicii aplicaţiei de prezentare. În cazul aplicaţiilor web dezvoltate cu tehnologii Java, standardul pentru partea de prezentare a fost mult timp JavaServer Pages, care are trăsăturile unui procesor de șabloane. Marele neajuns al acestei tehnologii este posibilitatea inserării de business logic în codul de prezentare. Astfel, avem posibilitatea să inserăm în documentul JSP scriptlets sau chiar blocuri de cod Java. Deși acest lucru ne poate ajuta în anumite situații, codul devine în mod rapid mai complex și greu de întreținut. Mai mult decât atât, această practică încalcă principiul design pattern-ului MVC. Din cauza neajunsurilor de acest gen, JSP a pierdut teren semnificativ în favoarea altor procesoare de şabloane, care sunt folosite în tot mai multe proiecte, sporind productivitatea dezvoltatorilor şi calitatea produselor. Proiectele despre care vom discuta ne ajută să creăm cu ușurință conținut dinamic, combinând șabloanele cu modelul de date, pentru a produce documente rezultat. Șabloanele sunt scrise într-un limbaj de templating, iar documentele rezultate pot reprezenta orice fel de text formatat.

Pe lângă procesoarele deja consacrate, cum ar fi Apache Velocity sau FreeMarker, în ultimii ani a fost lansată o varietate de noi produse de acest gen, care oferă funcţionalităţi diverse. În continuarea acestui articol vom analiza patru produse disponibile gratuit pentru uz comercial, încercând să realizăm o comparaţie a acestora.

Velocity Template Language

Apache Velocity se bucură de un limbaj de scripting propriu, numit Velocity Template Language (VTL), care este puternic şi flexibil. Autorii Velocity anunţă cu mândrie că flexibilitatea produsului lor este limitată doar de creativitatea utilizatorului. VTL a fost creat cu scopul de a oferi cea mai simplă şi curată cale pentru a încorpora conţinut dinamic într-o pagină web.

Velocity foloseşte referinţe pentru a îngloba conţinut dinamic în paginile web, iar unul dintre tipurile de referinţe este reprezentat de către variabile. Acestea pot referi obiecte definite în codul Java sau pot primi valori chiar în interiorul paginii web, prin intermediul unei declaraţii VTL. O astfel de instrucţiune începe cu un caracter #, după cum putem observa în exemplul următor: #set( $magazineUrl = ”http://www.todaysoftmag.com/” )

Integrarea cu Spring MVC

Când ne gândim la dezvoltarea unei aplicaţii web cu ajutorul tehnologiilor Java, unul dintre primele lucruri pe care le facem este să alegem un framework MVC. Practica ne-a arătat că Spring MVC este unul dintre cele mai populare framework-uri web, iar în acest articol vom analiza utilizarea procesoarelor de şabloane din perspectiva integrării cu acesta. Pentru a ilustra anumite trăsături ale fiecărui procesor prezentat, vom dezvolta o aplicaţie web simplă, ce va fi compusă din două pagini: una care afișează o listă de produse și alta care afișează detaliile unui produs.

Spring MVC are suport nativ pentru procesorul de șabloane despre care discutăm, și în consecință integrarea acestora este un proces simplu. Presupunând că folosim Maven pentru crearea proiectului, alegem arhetipul maven-archetype-webapp din grupul org.apache.maven.archetypes. Fără a enumera toate dependințele Maven necesare, menționăm totuși că avem nevoie de artefactele velocity și velocity-tools din grupul org.apache.velocity. Codul sursă al proiectului exemplu poate fi descărcat de la următoarea adresă: https:// springvelocity.googlecode.com/svn/trunk.

D up ă c e am d e cl ar at î n w e b . x m l s e r v l et - u l DispatcherServlet care va gestiona toate request-urile și am definit fișierul servlet-context.xml cu toate elementele specifice Spring, putem declara bean-urile pentru lucrul cu Velocity. În primul rând, avem nevoie de un bean cu id-ul velocityConfig, căruia îi vom transfera calea relativă la care se vor găsi șabloanele pentru paginile aplicației:

Apache Velocity

<property name=”resourceLoaderPath” value=”/WEB-INF/ views/”/>

Spring MVC şi procesoarele de şabloane

Velocity (http://velocity.apache.org/) este un proiect distribuit sub licenţă Apache Software License, care se bucură de o mare popularitate printre dezvoltatorii de aplicaţii Java. Deşi este utilizat de cele mai multe ori în context web, nu suntem limitaţi să folosim produsul doar pentru acest tip de proiecte. Poate fi utilizat fie ca un utilitar de sine stătător pentru generare de cod sursă şi rapoarte, fie ca o componentă integrată în alte sisteme.

Asemeni altor procesoare de şabloane, Velocity a fost proiectat astfel încât designerii web să poată lucra în paralel cu programatorii Java. Astfel, Velocity ne ajută să despărțim codul Java de codul paginilor web, oferind o alternativă viabilă tehnologiei JSP.

Apoi, declarăm un view resolver, care primește mai multe proprietăți. Clasa care va determina tipul acestui bean trebuie să implementeze interfața ViewResolver și are ca principal rol găsirea view-urilor după nume. Cea mai interesantă proprietate a acestui bean este layoutUrl. Aceasta reprezintă numele șablonului care va stabili layout-ul general: <property name=”layoutUrl” value=”layout.vm”/>

De asemenea, Velocity are capacitatea de a face caching șabloanelor folosite, lucru specificat prin proprietatea cache.

Acum că am configurat aplicația astfel încât partea de vizualizare să fie reprezentată prin șabloane Velocity, putem să vedem cum arată aceste șabloane. Partea cea mai interesantă a șablonului www.todaysoftmag.ro | nr. 23/Mai, 2014

51

programare Procesoare de șabloane pentru dezvoltare web în Java care determină layout-ul general este prezența variabilei speciale $screen_content. Aceasta va conține la runtime rezultatul procesării șablonului corespunzător view-ului returnat de controller-ul Spring MVC. În cazul aplicației noastre există un singur controller, care poate returna fie view-ul list, fie view-ul details. Șablonul corespunzător view-ului list este list.vm și are următorul conținut: <ul> #foreach($product in $products) <li><a href=”/product/${product.id}”>${product.name}</ a></li> #end </ul>

BSD. Asemănător proiectului Apache Velocity, FreeMarker oferă funcţionalităţi complexe care vin în întâmpinarea nevoilor dezvoltatorilor de aplicaţii web. Acesta a fost proiectat pentru generarea eficientă a paginilor HTML, însă posibilităţile utilizării tool-ului nu se opresc aici. Aşa cum afirmă creatorii proiectului, acesta este un produs software generic pentru generarea de text, aceasta însemnând orice de la HTML la cod sursă.

FreeMarker Template Language

Pentru descrierea şabloanelor, FreeMarker ne pune la dispoziţie un limbaj puternic de templating, numit FreeMarker Template Language. FTL ne permite definirea de expresii, funcţii şi macroÎn blocul de mai sus observăm cum iterăm o colecție și cum acce- uri în cadrul şabloanelor pe care le scriem. De asemenea, ne este săm proprietățile obiectelor din model cu ajutorul VTL. pusă la dispoziţie o bibliotecă bogată cu directive predefinite, care ne dau posibilitatea să iterăm colecţii de date, să includem alte Avantaje și dezavantaje şabloane şi multe altele. În continuare, prezentăm un exemplu de Fiind unul dintre cele mai cunoscute proiecte în materie apel al unei directive FTL, care asignează o valoare unei variable: de template processing, Velocity beneficiază de susținerea unei <#assign magazineUrl = ”http://www.todaysoftmag.com/“> comunități bine stabilite. De asemenea, documentația de pe siteul oficial este generoasă și există multe articole, care răspund la Observăm că în limbajul de templating specific FreeMarker, diverse întrebări. În plus, în decursul timpului au fost publicate directivele predefinite se apelează folosind sintaxa <#numedicâteva cărți dedicate proiectului Apache Velocity. Dacă aceste rectiva parametri>, iar macro-urile se apelează cu ajutorul resurse nu sunt de ajuns, există un mailing list cu o arhivă bogată, sintaxei <@macro parametri>. Expresiile se scriu astfel: la care ne putem abona. ${expresie}.

Există o varietate de aspecte care ne pot convinge să utilizăm acest produs în următorul nostru proiect: Velocity este un proce- Integrarea cu Spring MVC sor robust, flexibil şi bogat în funcţionalităţi. Există dezvoltatori La fel ca în cazul Apache Velocity, FreeMarker beneficiază de care afirmă că acesta ar fi cel mai puternic tool de acest tip de pe suport pentru integrarea cu Spring MVC chiar din partea creatoripiaţă. lor framework-ului web. Astfel, distribuția Spring MVC ne oferă o Un alt plus al acestui proiect este faptul că, pe lângă Velocity implementare de ViewResolver, dar şi o bibliotecă cu macroEngine, are în componență o serie de subproiecte: Tools (unelte uri pentru binding support şi form handling. și elemente de infrastructură, folositoare pentru dezvoltarea de Folosind aceeași modalitate pentru a crea o aplicație Spring aplicații web și nu numai), Anakia (transformare de documente MVC + FreeMarker ca în cazul Apache Velocity, remarcăm că XML), Texen (generare de text), DocBook Framework (creare de singurele modificări pe care trebuie să le efectuăm sunt în fișierul documentație), DVSL (Declarative Velocity Style Language – trans- de configurare Spring și în șabloane. De fapt, vom vedea că acest formări XML). lucru este valabil și atunci când ne vom ocupa de proiectele Când vine vorba despre suport pentru IDE-uri, Velocity Thymeleaf și Rythm. De asemenea, trebuie să remarcăm că avem beneficiază de o serie de plugin-uri dezvoltate de membri ai nevoie să declarăm în fișierul de configurare Maven dependința comunităţii. Aceste plugin-uri sunt dedicate unor IDE-uri precum freemarker din grupul org.freemarker. Codul sursă al Eclipse, NetBeans, IntelliJ IDEA, ca să le amintim doar pe cele mai proiectului exemplu poate fi descărcat de la următoarea adresă: populare. Multe dintre acestea oferă evidenţierea sintaxei şi chiar https://springfreemarker.googlecode.com/svn/trunk. autocompletion. La dezvoltarea exemplului prezentat în acest artiÎn servlet-context.xml înlocuim bean-ul de configucol am folosit Velocity Edit pentru Eclipse. rare și bean-ul cu rol de view resolver. Cel mai interesant aspect al Așa cum am arătat într-un paragraf anterior, integrarea cu acestor elemente XML este proprietatea cu cheia auto_import, Spring MVC este facilă. De asemenea, distribuţia Spring MVC care ne permite să importăm în toate fișierele noastre FTL macroconţine o bibliotecă de macro-uri pentru binding support şi form urile definite în fișierul spring.ftl, oferit de către distribuția handling, unelte valoroase pentru dezvoltarea de aplicații web.

Spring MVC. Acestea sunt accesibile prin intermediul alias-ului Deși este cel mai popular template engine în universul Java, spring: Apache Velocity nu a mai beneficiat de niciun release din noiem- <prop key=”auto_import”>/spring.ftl as spring</prop> brie 2010, când s-a lansat versiunea 1.7 a nucleului proiectului.

Proiectul este încă activ, însă comunitatea pare a fi mulțumită cu Șablonul corepunzător view-ului list este reprezentat de fișierul funcționalitățile deja implementate și încă nu există un release list.ftl. Partea notabilă a acestuia este prezentată în continuare: <#include „header.ftl” /> planificat. <h2>Products</h2> Velocity este un proiect la care s-a contribuit intens, devenind <ul> products as product> un produs complex, intimidant pentru noii utilizatori. Sintaxa este <#list <li><a href=”/product/${product.id}”>${product.name}</ oarecum greoaie, iar scrierea de template-uri fără ajutorul unui a></li> </#list> IDE care să suporte sintaxa VTL poate fi un coşmar. </ul>

FreeMarker

<#include „footer.ftl” />

În acest template observăm cum se poate include FreeMarker 1 este un produs matur, distribuit sub licenţă conținutul altui șablon, cum putem itera o colecție 1 http://freemarker.org/ de obiecte și cum scriem o expresie FTL.

52

nr. 23/Mai, 2014 | www.todaysoftmag.ro

management Avantaje și dezavantaje

Proiectul FreeMarker se bucură de o documentație cuprinzătoare, site-ul oficial oferind un manual bogat, din care atât programatorii, cât și designerii pot extrage multă informație utilă.

De asemenea, există un mailing list pentru discuții, însă utilizatorii sunt încurajați să ceară ajutor pe Stack Overflow, punând întrebări marcate cu tag-ul ”freemarker”. Deși FreeMarker este un template engine popular, până în prezent s-a publicat o singură carte dedicată acestuia.

FreeMarker oferă un limbaj de templating complet și relativ ușor de înțeles. Se poate spune că acest procesor de șabloane se bate de la egal la egal cu Velocity, fiind un produs matur, gata să fie integrat în proiecte enterprise. Merită menționat că, asemeni proiectului prezentat anterior, FreeMarker oferă mecanisme de caching al șabloanelor.

Pe pagina oficială există o listă cu o serie de plugin-uri pentru diverse medii de programare. Pentru exemplul prezentat în acest articol am folosit plugin-ul care face parte din JBoss Tools Project pentru Eclipse. Acesta oferă evidențierea sintaxei, indicatori pentru erorile de sintaxă, code completion pentru numele de macro-uri și de proprietăți ale bean-urilor. Trebuie să remarcăm că plugin-urile disponibile pentru FreeMarker nu sunt la fel de puternice precum cele scrise pentru Apache Velocity. De fapt, plugin-ul dedicat NetBeans nu pare să funcționeze pentru versiunea 7 a acestuia, deși pe site este indicat că suportă versiunile mai mari sau egale cu 6.

La fel ca în cazul Apache Velocity, FreeMarker se integrează ușor cu Spring MVC. Așa cum am văzut într-o secțiune anterioară, Spring MVC oferă atât o implementare pentru ViewResolver, cât şi o bibliotecă cu macro-uri pentru binding support şi form handling.

Proiectul este destul de activ, cea mai recentă versiune fiind 2.3.20, publicată în iunie 2013.

Am văzut că proiectul prezintă cam aceleași plusuri precum procesorul de șabloane prezentat înaintea lui și putem spune că și la capitolul minusuri se aseamănă. Fiind un proiect la care se lucrează de ani buni, a devenit complex, apărând uneori ca dificil de stăpânit pentru noii utilizatori.

Thymeleaf

Thymeleaf2 este o bibliotecă Java distribuită sub versiunea 2.0 a licenței Apache, având ca scop principal crearea de șabloane într-un mod elegant. Cel mai potrivit use case pentru Thymeleaf este generarea de documente XHTML / HTML5 în context web. Totuși, acest tool poate fi folosit și în medii offline, fiind capabil să proceseze documente XML. Creatorii Thymeleaf ne oferă un modul pentru integrarea cu Spring MVC, care ne dă posibilitatea să folosim acest produs pentru stratul de vizualizare al aplicațiilor noastre web, fiind astfel un substituent pentru JSP. Thymeleaf este bazat pe seturi de trăsături numite dialecte. Distribuția standard vine cu dialectele Standard și SpringStandard, care ne permit să creăm așa-numite natural templates. Acestea pot fi afișate corect de către browser, chiar dacă le accesăm ca fișiere statice. Astfel, aceste documente pot fi privite ca niște prototipuri. Dacă avem nevoie de alte funcționalități decât cele predefinite, Thymeleaf ne dă posibilitatea să ne creăm propriile noastre dialecte. Un dialect oferă funcționalități cum ar fi evaluarea expresiilor sau iterarea colecțiilor.

Nucleul Thymeleaf este construit în jurul unui motor 2 http://www.thymeleaf.org/

TODAY SOFTWARE MAGAZINE de procesare DOM, care este o implementare proprie, de înaltă performanță. Cu ajutorul acestui mecanism realizează o reprezentare a șabloanelor în memorie, iar apoi efectuează procesări pe baza configurației curente și a setului de date pus la dispozițe, traversând nodurile.

Standard Dialect și SpringStandard Dialect

Aceste două dialecte au aceeași sintaxă, marea diferență între ele fiind așa-numitul expression language folosit. Dacă dialectul Standard folosește OGNL, StandardSpring are integrat Spring Expression Language. De asemenea, dialectul SpringStandard are o serie de mici adaptări pentru a utiliza mai bine anumite funcționalități oferite de Spring. Notația pe care o folosește Thymeleaf în șabloanele sale poate fi observată în exemplul următor: <a href=”#” th:href=”@{‚http://todaysoftmag.com/tsm/ en/’}” th:text=”${websiteTitle}”>Today Software Magazine</a>

Atunci când șablonul de mai sus este procesat cu Thymeleaf, acesta evaluează expresiile reprezentate ca valori ale atributelor situate în spațiul de nume th și înlocuiește valorile atributelor clasice HTML cu rezultatul procesării.

Pentru a putea beneficia de validarea documentului, trebuie să declarăm spațiul de nume astfel: <html xmlns:th=”http://www.thymeleaf.org”>

Integrarea cu Spring MVC

Așa cum am menționat, Thymeleaf ne oferă un modul pentru integrarea cu Spring MVC, disponibil atât pentru Spring 3 cât și pentru Spring 4. Pentru a beneficia de acesta, pentru exemplul nostru am adăugat în pom.xml dependința thymeleaf-spring3 din grupul org.thymeleaf. Codul sursă al proiectului exemplu poate fi descărcat de la următoarea adresă: https://springthymeleaf.googlecode.com/svn/trunk.

Avantaje și dezavantaje

Thymeleaf este un proiect care atrage tot mai mulți utilizatori, dar și programatori care contribuie la dezvoltarea acestuia.

Site-ul oficial ne oferă o varietate de resurse pentru a ne familiariza cu acest produs. Mai mult decât atât, documentația existentă ne prezintă și cum putem extinde Thymeleaf cu propriile noastre dialecte. Pe lângă aceste tutoriale, avem la dispoziție articole pe diverse teme, un forum pentru utilizatori și un tutorial interactiv.

Deși la momentul scrierii acestui articol nu există cărți dedicate acestui proiect, putem găsi numeroase articole despre Thymeleaf.

De asemenea, avem la dispoziție și documentațiile Javadoc pentru API-urile thymeleaf și thymeleaf-spring.

Acest procesor de șabloane vine cu o filosofie diferită față de de Velocity și FreeMarker, lucru ce se poate observa și în sintaxa dialectelor Standard și SpringStandard. Thymeleaf pune mare accent pe conceptul de natural templating, care oferă posibilitatea creării de prototipuri statice.

O dată cu lansarea versiunii 2.0 a motorului Thymeleaf, mecanismul de procesare a șabloanelor a fost înlocuit, sporind performanțele acestuia. De asemenea, există și un sistem de caching al șabloanelor. În ce privește integrarea cu mediile de programare, există un plugin pentru Eclipse care oferă autocompletion. Din păcate, nu există suport și pentru alte IDE-uri.

Asemeni proiectelor despre care am discutat până acum, integrarea cu Spring MVC este ușor de obținut, întrucât autorii www.todaysoftmag.ro | nr. 23/Mai, 2014

53

programare Procesoare de șabloane pentru dezvoltare web în Java Thymeleaf au creat un modul special pentru aceasta.

Proiectul beneficiază de lansări frecvente, versiunea curentă fiind 2.12.RELEASE. Aceasta este disponibilă publicului din decembrie 2013.

Thymeleaf oferă o gamă largă de funcționalități, însă testele arată că procesarea șabloanelor este mai lentă decât în cazul unora dintre competitorii săi.

Rythm

Rythm3 este un procesor de șabloane pentru aplicații Java distribuit sub licență Apache, versiunea 2.0, descris de autorul său ca fiind un produs cu scop general, ușor de folosit și foarte rapid. Asemeni altor procesoare de șabloane, putem procesa cu ajutorul acestuia documente HTML, XML, scripturi SQL, cod sursă, email-uri sau orice alt text formatat. Rythm a fost inspirat din proiectul .Net Razor, datorită sintaxei sale simple și elegante. În aceiași termeni laudativi, autorul pretinde că preocuparea numărul unu a proiectului este experiența utilizator. De la API până la sintaxa șabloanelor, produsul este caracterizat prin simplitate. De asemenea, produsul a fost proiectat astfel încât utilizarea acestuia să fie cât mai facilă pentru programatorii Java.

Rythm poate opera în două moduri: dev (development) și prod (production). Astfel, în modul dev șabloanele sunt reîncărcate de fiecare dată când sunt modificate, pentru a scurta timpul de dezvoltare; pe de altă parte, în modul prod acestea sunt încărcate o singură dată, pentru sporirea performanței.

Unul dintre minusurile proiectului Rythm este faptul că momentan nu oferă niciun plugin pentru medii integrate de dezvoltare. Astfel, deși sintaxa acestuia este cât se poate de prietenoasă, nu avem asistență din partea IDE-ului preferat pentru scrierea șabloanelor, un aspect important pentru mulți dezvoltatori.

Rythm permite inserarea de cod Java în cadrul unui șablon, acesta fiind unul dintre aspectele care ne-au îndemnat să renunțăm la JSP în favoarea altor procesoare de șabloane. Așadar, vedem acest lucru ca pe un minus al proiectului.

Performanțe

Există prea puține teste relevante pentru determinarea performanței procesoarelor de șabloane prezentate în acest articol, însă în continuare vom prezenta rezultatele unor astfel de studii.

Folosind tool-ul de benchmarking disponibil la adresa https:// github.com/greenlaw110/template-engine-benchmarks am obținut următoarele rezultate pentru 10000 de Sintaxa procesorului de șabloane request-uri: Rythm folosește caracterul special @ pentru a introduce toate • Velocity: 3.8 secunde, elementele de sintaxă. Acest lucru este exemplificat în blocul de • FreeMarker: 4.8 secunde, cod prezentat în continuare: • Thymeleaf: 43.2 secunde, • Rythm: 3 secunde. @for (product: products) { <li><a href=”/product/@product.getId()”>@product.getName()</a></li> }

Un alt test (disponibil la adresa h t t p : / / w w w . slideshare.net/jreijn/comparing-templatePentru a putea utiliza în template obiecte adăugate modelu- enginesjvm), în care Rythm nu a fost inclus, arată că Velocity lui de date în controller-ul Spring, trebuie să folosim următoarea și FreeMarker au avut performanțe aproape identice, în timp ce notație: Thymeleaf a fost, din nou, printre cele mai lente procesoare.

Astfel, Rythm pare a fi cel mai rapid template engine dintre cele @args java.util.List<ro.cdv.model.Product> products despre care am discutat în acest articol, Velocity și FreeMarker Integrarea cu Spring MVC își dispută locurile al doilea și al treilea, în timp ce Thymeleaf a Pentru integrarea cu Spring MVC avem la dispoziție o biblio- obținut cel mai slab timp. tecă de clase third-party, disponibilă ca artefact Maven sub id-ul spring-webmvc-rythm și grupul com.ctlok. Având Concluzii această dependință în proiect, putem declara bean-urile necesare Deși am văzut că proiectele prezentate ne pun la dispoziție în servlet-config.xml. Una dintre proprietățile bean-ului funcționalități similare, în urma acestei discuții putem trage rythmConfigurator este mode, cu ajutorul căreia putem specifica câteva concluzii. Atât Velocity, cât și FreeMarker sunt produse în ce mod rulăm aplicația: dev sau prod. Codul sursă al proiectului consacrate, care și-au dovedit valoarea în multe proiecte de sucexemplu poate fi descărcat de la următoarea adresă: https://sprin- ces, oferind performanță decentă. Pe de altă parte, Thymeleaf grythm.googlecode.com/svn/trunk. și Rythm sunt proiecte mai tinere, care vin cu o filosofie nouă, adaptată trendurilor în dezvoltarea web. Spre exemplu, Thymeleaf Avantaje și dezavantaje excelează la capitolul natural templating, în timp ce Rythm oferă Spre deosebire de Velocity și FreeMarker, Rythm procesează o sintaxă curată, ușor de înțeles atât pentru programatori, cât și șabloanele, transformându-le în bytecode Java. Datorită acestui pentru webmaster-i. Putem concluziona că alegerea unui template lucru, la runtime, procesarea acestora este foarte rapidă, plasând engine depinde, în primul rând, de proiectul pentru care avem acest proiect alături de cele mai rapide procesoare de șabloane din nevoie de acesta, fiecare dintre procesoarele despre care am discuuniversul Java. tat meritând să fie luat în considerare.

Deși nu este la fel de vastă precum a celorlalte produse prezentate, documentația proiectului este cuprinzătoare, permițându-ne să deprindem abilitățile necesare dezvoltării de aplicații web cu ajutorul Rythm Template Engine. Pe site-ul proiectului există o serie de tutoriale, atât pentru programatori, cât și pentru webmasDănuț Chindriș danut.chindris@elektrobit.com ter-i, iar cu ajutorul instanței Fiddle dedicate putem scrie șabloane Rythm și vedea rezultatul imediat. Fiind un proiect relativ tânăr, Java Developer @ Elektrobit Automotive comunitatea din jurul lui nu este încă dezvoltată.

3 http://rythmengine.org/

54

nr. 23/Mai, 2014 | www.todaysoftmag.ro

legal

TODAY SOFTWARE MAGAZINE

Cum protejăm o idee bună de afaceri

M

ulți dintre dumneavoastră ați visat să fiți antreprenori. Și poate, într-o zi, ați avut o idee grozavă pentru o afacere. Așa că ați făcut un parteneriat cu unul sau mai mulți amici pricepuți în domeniul respectiv și … ați creat un start-up.

Antreprenor și start-up sunt două cuvinte în vogă. Se folosesc insistent la mai toate conferințele și întâlnirile de profil, unde se subliniază că orice start-up trebuie gândit în detaliu şi în perspectivă - de la concept, modele de afaceri, finanţare, dezvoltare și până la cum să folosiți SEO și social media – totul, în scopul obţinerii succesului. Dar mult prea rar se pune accent pe importanța unei componente juridice solide a strategiei inițiale a startup-ului – începând cu alegerea formei legale potrivite, cu înregistrarea, protejarea și exploatarea drepturilor de proprietate intelectuală și continuând cu asistența specializată pe zona contractuală, etc. .

Poate nu știți, dar orice afacere deține (sau ar trebui să dețină, pentru a fi viabilă) un portofoliu cu măcar câteva elemente minime de proprietate intelectuală, dintre care enumerăm : un nume de domeniu www, un nume comercial, un logo, o marcă (poate chiar una neînregistrată), knowhow-ul, secretele comerciale ce îi conferă un avantaj competitiv. În plus, în funcție de tipul activității desfășurate, proprietatea intelectuală poate avea elemente din ce în ce mai sofisticate: drepturi de autor pentru programe de calculator, aplicații mobile, grafică sau pentru jocuri video, drepturi asupra unor baze de date, licențe, brevete de invenții, etc. .

Luate în ansamblu lor, toate aceste instrumente reprezintă unul dintre bunurile cele mai de preț ale start-up-ului și nu trebuie deloc neglijate; ba, dimpotrivă, trebuie protejate, sporindu-li-se în acest fel valoarea. Afacerea dvs. capată un potențial mai ridicat de succes atunci când portofoliul de proprietate intelectuală este unul valoros. Iar valoarea acestuia – atât pentru investitorii cărora le prezentați ideea pe care intenționați să o implementați, cât și pentru potențialii parteneri comerciali - este dată inclusiv de modul în care elementele portofoliului sunt protejate.

Așadar, apare întrebarea legitimă: ce

măsuri pot lua antreprenorii pentru a-și proteja ideea de afaceri și portofoliul de proprietate intelectuală, atunci când încep demersurile pentru obținerea unor surse de finanțare, având în vedere că ideile de afaceri în sine nu sunt protejate de lege prin drept de autor (așa cum se crede uneori, în mod greșit)?

De cele mai multe ori, în cadrul unui pitch, se are în vedere începerea unor discuții pentru a stabili toate aspectele unui eventual parteneriat (finanțare de la un business angel, joint-venture, etc.). Implicit, va fi necesară o dezvăluire de informaţii privind ideea de afacere în sine, eventuale elemente-cheie de proprietate intelectuală ce stau la baza respectivei afaceri, etc.

– informații care ar trebui să rămână confidențiale și care nu ar trebui să fie folosite fără acord. În scenariul optimist, după aceasta etapă de “pețire”, puteți avea un “mariaj” de succes concretizat într-un contract în care se vor detalia, printre altele, implementarea proiectului, aspectele financiare (inclusiv pretențiile financiare ale investitorului sau ale partenerului comercial) și cele privind exploatarea proprietății intelectuale. Dar, pentru scenariul pesimist în care respectivul parteneriat nu se materializează, este recomandabil să vă luați măsurile potrivite ca să vă protejați informațiile pe care le dezvăluiți.

Puteți face acest lucru, printre altele, prin încheierea unui acord de confidenţialitate (în engleză, Non-Disclosure Agreement – NDA) înainte de începerea discuțiilor.

Din punctul de vedere al imaginii, un NDA poate trimite un semnal pozitiv de încredere în propriile idei, privind faptul că luați în serios afacerea și planul de afaceri.

Un NDA ar trebui să prevadă - cât mai exact - care sunt datele, informaţiile şi documentele confidenţiale pe care le dezvăluiți, cât și obligațiile destinatarului și răspunderea sa contractuală în cazul în care se încalcă obligația de confidențialitate, etc.

Desigur, trebuie găsită justa cale de mijloc între dorința legitimă de a vă proteja ideea de afaceri și disponibilitatea investitorului de a semna un NDA; există cazuri frecvente în care potențialii investitori sau parteneri comerciali refuză să semneze un NDA (din diverse motive). Unii dintre ei și-au stabilit ca principiu să nu semneze un NDA, iar alții acceptă să semneze doar atunci când se înaintează în discuții și doar dacă sunt interesați să accepte parteneriatul sau să vă acorde finanțarea.

Principiul de care trebuie să țineți seama este că oricât de atractivă poate fi perspectiva colaborării cu un finanțator, întotdeauna lucrurile pot lua o turnură nedorită. De aceea, ar trebui să luați în considerare, în special în etapa negocierilor, semnarea unui NDA, chiar dacă uneori acest lucru poate părea nerealist din punctul de vedere al investitorului sau al partenerului comercial.

Iar când acest principiu nu poate fi pus în practică, gândiți-vă la cât de generoși ar trebui să fiți cu informația ce vi se solicită – informația este bunul dvs. cel mai de preț și, odată dezvăluită, s-ar putea să vă pierdeți avantajul competitiv. Și în acest caz, abilitatea dvs. și a consultantului dvs. de a pune corect problema în fața investitorului, poate fi soluția de ieșire din impas.

Un business solid nu se poate clădi în lipsa unor instrumente legale folosite corect și eficient – cu ajutorul potrivit atunci când este nevoie, de exemplu, prin pregătirea unui NDA acoperitor. Așadar, nu tratați cu ușurință acest aspect pentru că vă poate costa doar … o (idee de) afacere.

Claudia Jelea

claudia.jelea@jlaw.ro ro.linkedin.com/in/claudiajelea Avocat & Consilier in domeniul marcilor @ IP Boutique

www.todaysoftmag.ro | nr. 23/Mai, 2014

55

management

Gogu şi sticla de apă

G

ogu înșurubă tacticos capacul sticlei de apă plată, se asigură că e bine închis, mai strânse odată, total inutil, dar se vedea că face toate acestea cu mintea în altă parte. Mișu îl văzu căzut pe gânduri și se gândi, probabil, că e numai bună ocazia să se ia de el, că doar de mult nu se mai războiseră verbal și n-ar fi vrut să-și iasă din mână:

- Hooo, brrrr… zise el destul de tare, privindu-l intens pe Gogu. Acesta însă nu reacționă, așa că Mișu repetă, de data aceasta ceva mai tare: - Hooo, brrrr… oprește! Rămăsese dezamăgit de faptul că era total ignorat de Gogu și căută cu privirea, ușor dezorientat, sprijin de la colegi. Observă că toată lumea se uita la el cu interes și i se aprinse beculețul: - No, deci m-ai auzit, dar nu catadicsești să mă bagi în seamă. Oare nu îi ăsta un semn de lipsă de respect? De ce faci tu asta, Gogule?

- De trei ori Trăiască și o dată Ura, de-aia, răspunse Gogu abia reținându-și zâmbetul. De 1 Mai muncitoresc sau – ca să fiu mai precis – ca să îți dau ție ocazia de a folosi cuvinte complicate, să ți se îmbârlige limba în gură: ia, cum ai zis?

Ca-ta-dic-sești?!

- Bine că ești tu șmecher și ție nu ți se îmbârligă nimic în creier, răbufni Mișu, dar o făcu molcom și fără nici o urmă de supărare. Că nici n-are ce să se îmbârlige, adăugă mai încet apoi, fără nici o trecere, întrebă ce-l durea, de fapt, pe el: - Ia zi, pe unde îți rătăceau gândurile, că păreai plecat pe câmpii... Și nu prea ne permitem acum, după plecarea intempestivă a lui Dan. - Mda, la asta mă gândeam. Ne cam zdruncină plecarea asta a lui, e singurul care știe toate dedesubturile pentru proiectul ăsta nou. Și n-avem nimic documentat, toată experiența proiectelor anterioare e înșurubată bine în mintea lui... și cam atât.

Ba poate mai găsești ceva în Inbox/Outbox doar că asta n-are cum să ne ajute prea mult. La ce ajută să acumulezi experiență dacă nu poți să o împărtășești celorlalți?

Mă rog, la ce ajută organizației, că pe tine, personal, e evident că te ajută.

- Ce-ajută și ce n-ajută, măi băieți, despre ce e vorba în propoziție? Ca de obicei, Șefu’ apăruse fără să-l simtă cineva.

- Șefu’ trebuie să renunți la intrările astea ‚undercover’, fără să fii băgat în seamă și fără să ne fi anunțat...

56

- Sigur, data viitoare îmi pun niște clopoței. Ia ziceți, care-i baiu’?

- No, nu-i nici un bai, Șefu’, da’ ne gândeam noi...

- Adică eu, preciză Gogu.

- Tu, eu, noi adică, continuă Mișu imperturbabil, cum faci să păstrezi în departament, sau în companie, experiența și cunoștințele acumulate în proiectele anterioare.

- Aha, înțeleg că ați vorbit cu echipa lui Dan și n-ați obținut mare lucru.

- Ceva, ceva am obținut, dar nu multe lucruri concrete. Problema e că fiecare dintre ei e acum implicat în alte proiecte, Dan a plecat, iar noi nu avem niciun document care să ne ajute. E practic ca și când am lua totul de la zero.

Gogu mârâi supărat: - E cam enervant. Toți am tras din greu și toți vom continua acum să tragem din greu. Șefu’, orice ai zice mata, asta sună a prostie...

- Nu e prostie, Gogule, e semn că evoluăm și vrem să facem lucrurile mai bine.

Am dat de o problemă, hai să o rezolvăm: să vedem ce facem cu cunoștințele acumulate.

E clar că ele sunt ale celui care lucrează și trece prin situații specifice. Sunt experiențe personale care, în timp, îl ajută - pe cel care le recunoaște și le înțelege – să devină din ce în ce mai bun, mai competent. Firma devine și ea din ce în ce mai bună, fiind recunoscută ca suma competențelor individuale. Odată cu creșterea firmei, ea va dori – așa cum vrem noi acum – să securizeze cât mai mult din experiența câștigată astfel încât să nu mai depindă de fiecare individ în parte.

- Păi s-o facem atunci, se grăbi Gogu, ce ne oprește?

- Hooo, brrrr... , interveni Mișu. Nu e chiar așa simplu, Gogule. Ia spune, tu știi să mergi pe bicicletă?

- Neuronii tăi sunt pe biciclete, plecați în cursă, unu’ nu ți-o rămas acasă. Ce-ți veni cu bicicletele acum?

- Știi, ori nu știi? Răspunde.

- Știu.

nr. 23/Mai, 2014 | www.todaysoftmag.ro

- No atunci, explică tu în scris cum faci asta, în special partea cu menținutul echilibrului, iar eu promit să mânc documentul, încheie Mișu triumfător.

- Mănânc, îl corectă Gogu, dar între timp i se învârteau rotițele. Putea evident să descrie cum te urci pe bicicletă, cum te dai jos de pe bicicletă, cum te ridici după ce ai căzut...

- Mânc, mănânc, tot aia. No, poți ori ba?

- Păi și-atunci ce? Nu mai facem nimic?

Se rățoi Gogu încurcat, căutând sprijin la Șefu’.

- Într-adevăr, dacă lucrurile ar fi fost simple, le-am fi rezolvat demult, nu-i așa?

Cunoștințele și experiența sunt ca apa, dacă n-o îmbuteliezi, se scurge. Problema noastră este să găsim sticla în care să strângem apa asta, râse Șefu’. Parțial am rezolvat: avem planurile de proiect, avem rapoartele de progres de care ne ajutăm – de multe ori – și în proiectele următoare.

Mai rămâne acum să vedem cum îmbuteliem mersul pe bicicletă. Numai că nici nu e simplu de explicat și nici oamenii nu sunt dornici să o facă. Până la urmă, acesta este diferențiatorul lor, iar îmbuteliatul’ îi face mai ușor de înlocuit.

- Hmm, nu e foarte plăcut gândul... se trezi Gogu vorbind, adăugă însă repede: din punct de vedere individual.

- Ceea ce înseamnă că trebuie găsită soluția de compromis care să ajute și compania și individul. Firmele de succes au rezolvat, nu ne rămâne decât să rezolvăm și noi. După cum ziceam, Gogule, e o problemă de evoluție, nu de prostie.

- Mda, prostie ar fi însă s-o lăsăm așa și data viitoare să fim în aceeași situație...

Simona Bonghez, Ph.D.

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

sponsori

powered by