today software magazine n23/2014

TSM T O D A YS O F T WA R E

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

M AG A Z I N E

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ă

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

Scrum-ul Perfect: Fata Morgana din Agile

Java 8, expresii lambda şi nu numai

6Cluj IT marchează o nouă etapă a

dezvoltării sale ca cluster inovativ Paulina Mitrea și Andrei Kelemen

8How to Web lansează

MVP AcademyIrina Scarlat

10Topconf Bucharest 2014

Chris Frei

11Comunitatea locală în

JavaScript se întâlnește la București!Iunieta Sandu

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

la Cluj-Napoca!Adina Grigoroiu, CAPM

14Livrarea aplicațiilor mobile de succes

Larisa Gota

18Java 8, expresii lambda şi nu numai

Silviu Dumitrescu

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

Ambrus Oszkár

25Dincolo de

API Alpar Torok

28Întreţinerea la zi a sistemelor Linux (I)

Sorin Pânca

31Modelarea datelor în contextul Big Data

Silvia Răusanu

39Code Kata Tudor Trișcă

35Analiza eficientă a scenariilor de utilizareAnita Păcurariu

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

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

435 reguli simple pentru o campanie eficientă Ruxandra Tereanu

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

46Platforma OnyxBeacon iBeacon Bogdan Oros

49De-adevăratelea! Antonia Onaca

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

55Cum protejăm o idee bună de afaceriClaudia Jelea

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

http://www.kinectforwindows.org



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

Luna 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 lan-sare î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 cultu-rale 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 promi-tem 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ăţanFondator al Today Software Magazine

Ovidiu Măţ[email protected]

Editor-in-chief Today Software Magazine

editorial

mailto:[email protected]

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

Redacţia Today Software Magazine

Fondator / Editor in chief: Ovidiu Mățan [email protected]

Editor (startups și interviuri): Marius Mornea [email protected]

Graphic designer: Dan Hădărău [email protected]

Copyright/Corector: Emilia Toma [email protected]

Traducător: Roxana [email protected]

Reviewer: Tavi Bolog [email protected]

Reviewer: Adrian Lupei [email protected]

Contabil : Delia [email protected]

Produs de Today Software Solutions SRL

str. Plopilor, nr. 75/77Cluj-Napoca, Cluj, [email protected]

www.todaysoftmag.rowww.facebook.com/todaysoftmag

twitter.com/todaysoftmag

ISSN 2284 – 6352

Copyright Today Software Magazine

Reproducerea parțială sau totală a articolelordin revista Today Software Magazine

fără acordul redacției este strict interzisă.

www.todaysoftmag.rowww.todaysoftmag.com

Lista autorilor

Claudia [email protected]

Avocat & Consilier in domeniul marcilor @ IP Boutique

Adina Grigoroiu, [email protected]

Trainer și consultant @Colors in Projects

Andrei [email protected]

Director executiv@ IT Cluster

Alexandru [email protected]

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

Silviu Dumitrescu [email protected]

Line manager@ Accesa

Chris [email protected]

Organizer@ TopConf

Ambrus Oszkár [email protected]

Software Engineer@ Accenture

Alpar [email protected]

Functional arhitect@ HP România

Sorin Pâ[email protected]

Senior Systems Administrator@ Yardi România

Silvia Ră[email protected]

Senior Developer@ ISDC

Tudor Trișcă[email protected]

Team Lead & Scrum Master@ msg systems România

Anita Pă[email protected]

Business analyst@ Endava

Bogdan Mureș[email protected]

Director of Engineering@ 3Pillar Global

Ruxandra [email protected]

Conversion Analyst@ Betfair

Bogdan [email protected]

Co-Fondator@Onyx Beacon

Diana [email protected]

Marketing Manager@ Codespring

Larisa Gota [email protected]

QA Engineer@ Small Footprint

Paulina [email protected]

Coordonator of Innovation group@ ClujIT Cluster






www.todaysoftmag.ro

twitter.com/todaysoftmag

www.todaysoftmag.ro

www.todaysoftmag.com


prezentare

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 inova-tive 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 sub-proiecte 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, for-mate 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 dez-voltare 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 pre-zentă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 colabo-rativ de know-how și competențe avansate, chiar de avangardă(!), provenite din toate mediile furnizoare de knowledge și exper-tiză care sunt atât de bine reprezentate în urbea noastră. În acest

context, am și anunțat pregătirea derulării unuia dintre proiec-tele 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 ele-mentelor caracteristice unui oraș inteligent, sunt armonizate prin intermediul unei informatizări integrative și exhaustive.

Pe fondul problemei, abordarea conceptului central al proiec-tului 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 totali-tatea 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 evo-lutii 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 comu-nicante, 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 abor-dare 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

Luna 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.

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

cluster inovativ

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

TODAY SOFTWARE MAGAZINE

„Next Generation Brained City”. Noul concept urban vizează o dezvoltare economică suste-

nabilă și eficientă pentru un context de comunitate eco-eficient ș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 tran-sport/trafic; (3) nivelul rețelei medicale; (4) nivelul infrastructurii de utilități (pornindu-se de la nivelul „under-ground” până la nive-lul rețelelor aeriene); (5) nivelul rețelei educaționale și culturale; (6) nivelul rețelei entităților economice și de business; (7) nivelul de habitat axat pe conceptul de ”next generation housing”, adică clădiri inteligente aferente conceptului de “smart city”.

Ț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 are deja sprijinul autorităților locale (Primarie, Consiliu Judetean, Prefectura, ADR NV etc). Iar ca un punct de reper, întreaga abordare a proiectului vizează targetul definit la nivel european și mondial, având ca orizont anul 2020, privind conceptul de Eco-Smart 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-citieshttp://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

De fapt, întreaga politică de dezvoltare economică a Uniunii Europene se bazează pe două con-cepte majore și anume specializare inteligentă (smart specialization) și cluster-izare, în timp ce instru-mentele esențiale de atingere a obiectivelor de performanță socio-economică 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 strategice de dezvoltare, susținute și

financiar, să fie continuată prin măsuri de susținere directă a clus-ter-elor și mediului privat și în actuala perioadă de programare.

Young spiritMature organizationA shared vision

Join our journey!

www.fortech.ro

Paulina [email protected]

Coordonator of Innovation group@ ClujIT Cluster

Andrei [email protected]

Director executiv@ IT Cluster


Startup-urile din Europa Centrală și de Est sunt renumite pen-tru 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ă antre-prenorilor 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ă, echi-pele finaliste vor beneficia, pe toată durata programului, de spaţiu de co-working, mentorat, acces la comunitatea tech la nivel inter-naţ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 teh-nologiei (echipe sau persoane) care au mai puţin de doi ani de activitate, au dezvoltat cel puţin un prototip funcţional al produsu-lui, 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 acce-lerare. 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 acu-mula competenţe cheie pentru un startup: noţiuni de business, finanţare, aspecte legale, dezvoltare de produs, storytelling, mar-keting, 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 per-formanţă, 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ţio-nale (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ă pen-tru dezvoltarea propriilor startup-uri pe toată durata programului.

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

40 de mentori având competenţe relevante pentru etapa de dez-voltare î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 mentori-lor 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, eve-niment î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 par-ticipă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ţiu-nea 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.

How to Web lansează MVP Academy, program de pre-accelerare adresat startup-urilor din Europa Centrală și de Est. În peri-oada 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.

eveniment

How to Web lansează MVP Academy, program de

pre-accelerare pentru startup-urile din regiune

Irina [email protected]

Co-Fondator al Akcees@ How To Web

http://mvpacademy.co/mentors

http://mvpacademy.co/mentors

http://www.mvpacademy.co

http://www.mvpacademy.co



Managementul 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 ser-veș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 tutu-ror tehnologiilor software. Topconf Bucharest oferă un mediu propice stabilirii și întăririi de contacte între dezvoltatori, arhi-tecţ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 pro-grame de instruire suplimentară;

• Evenimente și activităţi oficiale de formare a unor legături de afaceri;

• Platformă de comunicare eficientă pentru expozanţi și spon-sori din comunitatea naţională și internaţională de Software.

Topconf Bucharest 2014, dintr-o privire

Eveniment:Conferinţa internaţională IT.

Punct centralTehnologii 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.

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.

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

Organizat deTopconf OU, Tallinn, Estoniatopconf.com

eveniment

Topconf Bucharest 2014

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

Chris [email protected]

Organizer@ TopConf



JSCamp 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.

Feedback-u l p oz i t iv d in p ar te comunității web din România, ne-a deter-minat ca anul acesta să lansăm prima ediție a evenimentului JSCamp, care să răspundă interesului mare pentru eveni-mentele 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 des-pre 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 dez-voltare 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 parti-cipa la eveniment se regăsesc:

Martin Kleppe , Co-fondator și Head of Development în cadrul com-panei Ubilab, companie care dezvoltă aplicații bazate pe Google Maps API; Sebastian Golasch, Specialist Senior

Manager Software Developer la Deutsche Telekom, de-a lungul timpului a dezvoltat aplicații cu JavaScript, PHP și Ruby; Phil Hawksworth, R/Ga, JavaScript developer care este specializat în dezvoltarea site-uri-lor 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, techni-cal 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 comunitatea specialiștilor în IT și să le ofe-rim noi posibilități de colaborare. JSCamp România va fi despre cele mai noi tren-duri în materie de programare web, despre networking și know-how internațional.

Detalii suplimentare despre eveniment sunt disponibile și pe adresa jscamp.ro

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

București!

startups

Iunieta [email protected]

PR & Marketing Coordinator @ Evensys



eveniment

Î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 spea-ker-ii de la eveniment, care au moderat cele șase grupuri formate.

Ghidaț i de cei doi moderator 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 speaker-i 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ându-se 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âl-nite î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, incertitu-dine, 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 proiecte-lor Agile, ce impact au aceastea asupra inovației și motivării, precum și despre pro-vocă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.

George Anghelache & Cristian Cazan ne-au încântat cu o altfel de prezentare: imi-tâ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 pen-tru 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 pro-iectului (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 din-tre actorii Agile. Acestea pot apărea pe mai multe niveluri precum: analiză, dezvoltare, testare, leadership, management...

Andrei Doibani ne-a vorbit des-pre cum funcț ioneză procesul de adoptare a metodologiei Agile in indus-triile cu reglementări foarte stricte, dar şi despre abordările hibrid, precum Water-Scrum-Fall.

Izabella Paun şi Danielle Popescu-Abrudan 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 cres-cut, iar echipele au început să colaboreze mai bine.

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

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

Călin Damian ne-a argumentat importanța alegerii instrumentelor potri-vite î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 soft-ware, de asigurare a calității și de suport.

Simona Bonghez a prezentat deciziile luate în proiecte și consecințele lor asu-pra 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 mana-ger de proiect.

Am încheiat cu multe cadouri și sur-prize 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ă Workshop-uri: 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!

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

Adina Grigoroiu, [email protected]

Trainer și consultant @Colors in Projects



Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: www.transylvania-jug.orgData înfiinţării: 15.05.2008 / Nr. Membri: 576 / Nr. Evenimente: 43

Comunitatea TSMComunitate construită în jurul revistei Today Software Magazine.Website: www.facebook.com/todaysoftmagData înfiinţării: 06.02.2012 /Nr. Membri: 1434/Nr. Evenimente: 18

GeekMeet RomâniaComunitate dedicată tehnologiilor web.Website: geekmeet.roData înfiinţării: 10.06.2006 / Nr. Membri: 606 / Nr. Evenimente: 17

Cluj.rbComunitate dedicată tehnologiilor Ruby.Website: www.meetup.com/cluj-rbData înfiinţării: 25.08.2010 / Nr. Membri: 175 / Nr. Evenimente: 40

The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 428 / Nr. Evenimente: 55

Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: www.meetup.com/Cluj-Semantic-WEBData înfiinţării: 08.05.2010 / Nr. Membri: 176/ Nr. Evenimente: 23

Romanian Association for Better SoftwareComunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.Website: www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 239/ Nr. Evenimente: 14

Tabăra de testareUn proiect care își dorește să strângă cât mai mulți oameni care lucrează ca și testeri.Website: tabaradetestare.roData înfiinţării: 15.01.2012 / Nr. Membri: 303/ Nr. Evenimente: 31

Luna 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 Mai 12 (Cluj)Lansarea numărului 23/mai al Today Software Magazinewww.facebook.com/todaysoftmag

Mai 13 (Timişoara)Functional Programming meetuplinkedin.com/groups/FP-meetup-Timisoara-13-mai-4338166.S.5865381911513300994

Mai 15-16 (Cluj)Romanian Testing Conferencewww.romaniatesting.ro

Mai 16 (Cluj)Catalysts Coding Contest contest.catalysts.cc

Mai 17-24 (Cluj)Starceleratecluj.startcelerate.com

Mai 22-23 (Cluj)IT Campwww.itcamp.ro

Mai 29-30 (Bucureşti)I T.A.K.E. Unconference2014.itakeunconf.com

Mai 30 (Braşov)Lansarea numărului 23/mai al Today Software Magazinewww.facebook.com/todaysoftmag

Mai 31 (Cluj)Techsylvania hackaton - recomandarea TSMtechsylvania.co

Iunie 2 (Cluj)Techsylvania conferencetechsylvania.co

Iunie 3 (Bucureşti)JS Campwww.jscamp.ro

Iunie 10-13 (Bucureşti)TopConf 2014topconf.com/bucharest-2014/

Comunităţi IT

comunități

http://www.transylvania-jug.org

http://geekmeet.ro

Cluj.rb

http://www.meetup.com/cluj

http://www.agileworks.ro

http://www.meetup.com/Cluj

http://www.rabs.ro

14 nr. 23/Mai, 2014 | www.todaysoftmag.ro www.todaysoftmag.ro | nr. 21/Martie, 2014

programare

Nu cred că mai există aplicații de suc-ces 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 exem-plu, 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 suc-ces 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 cre-ate 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

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

căutat succesul și l-au găsit, însă există și persoane care au creat 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 anti-cipat 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

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.

Livrarea aplicațiilor mobile de succes

Larisa Gota [email protected]

QA Engineer@ Small Footprint



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 acestei aplicaţii pe toate platformele, fiecare încer-când să egaleze succesul originalului.

De unde începem?Dacă sunteți programatori/ QA

implicați într-un proiect, atunci presupun că detaliile aplicației, schițele, cerințele și specificațiile vă sunt deja cunoscute și astfel aveți deja un avantaj. În caz contrar, citiți în continuare câteva principii simple, menite a vă ajuta să începeți:

• O aplicație pentru dispozitive mobile inteligente trebuie să rezolve o problemă, fie că e o aplicație foarte utilă sau e doar un joc.

• Concentrați-vă pe un singur lucru, dar faceți-l bine. Fiți clari cu privire la ceea ce face aplicația; ar trebui să fie capabilă a se rezuma ca „one-liner”.

• Măsurați-vă propriile abilități și inte-rese pentru a rezolva o problemă de zi cu zi și a o face mai bine, sau cu o mică diferență. Există o mulțime de aplicații create până acum. Nu pierdeți efort și timp clonând ceva ce există deja. Aceasta nu înseamnă desigur că nu puteți îmbunătăți o aplicație deja creată, dar urmăriți să găsiți o nouă soluție pentru aplicație, ceva mai bun, mai distractiv sau care adaugă o nouă dimensiune. Cu alte cuvinte, să aducă de fiecare dată ceva nou.

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 deci-zia a venit în urma unui studiu de piață. Sunt conștientă că dezvoltarea unei astfel de aplicații poate părea o sarcină descura-jantă, 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 bene-ficii ale experienței unei aplicații native.

Cei mai importanți factori, monetiza-rea, performanța, experiența de uti-lizator, securitatea, toate sunt puternic înclinate în favoarea aplicațiilor native. Nu ne permitem să igno-răm acest trend cu ușurință. O parte din ceea ce alimentează această ascensiune a experienței mobile unice : apl icaț i i le native și experiența de ut i l izator atât de bogată asociată cu acestea. Pentru că există o sumă uimitoare în joc, atât Apple cât ș i Google se asigură ca sistemele lor de operare sunt actua-lizate permanent și că sunt compatibile cu cele mai noi, cele mai bune feature-uri de pe piață. Aici apl icaț i i le nat ive câștigă din nou, pen-tru că ele beneficiază de toate actualizările de sistem și inovațiile rapid lansate, într-un mod care pare pur și simplu imposibil aplicațiilor web.

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 idee prea bună. De fapt, cel mai bine e să se înceapă cu una. Credeți sau nu, alegerea primei platforme pe care să se facă dezvoltarea ține mai mult de com-portamentul utilizatorului final și are mai puțin de-a face cu capacitățile fiecărei plat-forme în parte. Până acum iOS și Android au reușit să atingă niveluri remarcabile și fiecare să-și țină aproape nișa proprie de utilizatori. Dacă ați ajuns într-un punct în care nu vă puteți hotărî pe care din ele s-o alegeți prima, atunci dați-mi voie să vă ajut.

De cele mai multe ori iOS se prezintă mai bine ca primă opțiune:

• pentru că Android e un sistem fragmentat, iar dezvoltarea pentru iOS implică mai puțină muncă;

• utilizatorii iOS tind să fie mult mai captivaţi, mai interesați de aplicațiile noi;

• utilizatorii iOS sunt mult mai dispuși să plătească pentru aplicații.

Există însă și situații în care Android pare a fi o opțiune mai bună:

• atunci când ați identificat acea nișă de utilizatori Android dispuși să plă-tească pentru aplicații sau dacă urmăriți distribuirea în cadrul unei companii;

• atunci când nu sunteți siguri că aplicația poate trece de exigențele impuse de Apple;

• atunci când nu vă permiteți costurile

management

http://www.teqarazzi.com/wp-content/

uploads/2013/05/apple-vs-android-vs-windows.png


Livrarea aplicațiilor mobile de succes programare

inițiale necesare pentru dezvoltarea unei aplicații pe iOS (un Mac, cont de progra-mator – necesare doar pentru a începe).

Bineînțeles că toate acestea sunt vala-bile 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 impor-tant să fie la curent cu tot ceea ce e nou. Dacă sunteţi QA, fiţi pregătiţi să vă expri-maţi opiniile, îngrijorările, ideile, dar mai ales să vă puteţi întotdeauna motiva punc-tele de vedere.

Nu copiați elemente de pe alte plat-forme.

Chiar dacă nu vă dați seama de pe-acuma, 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 carac-teristicile 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 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 proba-bil 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 dez-voltată 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, guideline-urile 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 sis-tem î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 utili-zatorul 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 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 utili-zatori 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 pro-

gramatorilor 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ăsi-rea 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 con-ferinţ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 obiecti-vului 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 uti-lizatorilor 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

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

folositoare.• Încercaţi să creaţi un pachet pen-

tru 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 auto-corecta 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 încer-care 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

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

populară cel puţin în cercul vostru de prieteni.

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

Din punctul meu de vedere, cel al unui QA, a crea o aplicaţie de suc-ces înseamnă a crea o aplicaţie robustă, cu o performanţă bună, care încântă, care are un timp de instalare la utiliza-tor 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 utilizato-rii 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ţă

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/

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ţi-lor 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 suc-cesul 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.

Fig. 1 Modelul Kano


Este 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 revis-tei 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 lan-sare 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ţio-nară, prin câteva dintre noile caracteristici introduse. Programată iniţial pentru luna sep-tembrie 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 specta-culoasă 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 programa-rea 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 ori-enta 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 functi-ons) î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 imple-mentate 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 limba-jului 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, sepa-

raţ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


managementprogramare

Silviu [email protected]

Line manager@ Accesa


TODAY SOFTWARE MAGAZINEmanagement

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 inter-faţ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ă, folo-sind 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 void setName(String name) { this.name = name; }

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 + “]”; }

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 fore-ach clasic. Ca parte a API-ului Collections avem noul API java.util.stream ce oferă suport pentru operaţii funcţionale pe stream-uri 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) {

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

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);



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 efec-tuate 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ţă naz-horn). 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ște-rea 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(); } }}

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: [email protected]

programare



Ambrus Oszkár [email protected]

Software Engineer@ Accenture

programaremanagement

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

După 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?C++ este unul dintre cele mai folosite

limbaje de programare. Are rădăcini isto-rice 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 dez-voltare 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 inte-grează bine în filosofia limbajului și e practic de folosit.

1 Deși e foarte promiţătoare, în articolul acesta nu dis-cută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 pro-iecte industriale și de scară largă.

Qt, cu elementele sale care comple-mentează deficiențele limbajului C++ și framework-ul său cu adevărat multiplat-formă 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 deve-lopment (RAD), care pot înlocui sau se pot integra în IDE-uri majore, cum ar fi Visual Studio sau Eclipse. Este profund și bine docu-mentat, are o comunitate mare și puternică în spatele lui și este adoptat pe scară largă. Ar fi indicat să-l folosiţi.

O Bibliotecă CuprinzătoareQt aduce o colecție de biblioteci pentru a

satisface toate nevoile de bază în dezvoltarea


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

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 repre-

zentarea 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, manipu-lare SVG, comunicare D-Bus, controale ActiveX și altele.

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

Qt oferă unele extensii de limbă prin intermediul unor macro-uri care sunt prelucrate de către generatorul de cod numit Meta-object Compiler (MOC). Acest lucru aduce o introspecție run-time mai avansată și posibilitatea de a avea anumite meca-nisme speciale în clase care folosesc Qt. Principalul mecanism de acest tip special este comunicarea între obiecte numit signals and slots.

Signals and slots oferă o alternativă mai bună la callback-uri, fiind loosely-coupled și type-safe. Acesta înseamnă că, atunci când se utilizează conexiuni între signals și slots, obiectele nu sunt

conștiente de obiectele conectate la ele. De asemenea aspectul type-safe este garantat prin limitarea conexiunilor bazată pe com-patibilitatea 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 ast-fel 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 conec-tate 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_OBJECTpublic: Counter() { m_value = 0; } int value() const { return m_value; }

public slots: void setValue(int value);

signals: void valueChanged(int newValue);

private: int m_value;};

Versiunea Qt are aceeași stare internă, dar pentru a suporta signals și slots, codul a fost extins cu următoarele:

1 Bazat pe exemplul oficial de la http://qt-project.org/doc/qt-5/signalsandslots.html



• Macroul Q_OBJECT, care este obligatoriu pentru toate cla-sele 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 emit , care emite un signal valueChanged()cu noua valoare ca argument, de fiecare dată când o nouă valoare este asignată.

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

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

b.setValue(48); // a.value() == 12, b.value() == 48

Observați comportamentul mecanismului signals and slots:• Apelarea a.setValue(12) duce la o emitere a signal-ului valueChanged(12), care va declanșa slot-ul setValue() al lui b, adică va apela funcţia respectivă.

• Aceasta rezultă în emiterea de valueChanged() al lui b, dar nu se mai întâmplă nimic, din moment ce nu a fost conectat la nici un alt slot.

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

Managementul ResurselorCele două mecanisme de managementul resurselor din Qt

sunt ownership hierarchy și implicit sharing.Ownership hierarchy constă într-un arbore de obiecte care

se ocupă de distrugerea descendenților. Ori de câte ori un nou obiect moștenind de la QObject este creat pe heap (folosind new), acestuia se poate atribui un părinte QObject, ceea ce va rezulta eventual într-un arbore de obiecte. Ori de câte ori un obiect este distrus din arbore, toți descendenții săi sunt de asemenea distruși.

În următorul fragment de cod obj2 va fi distrus în timpul distrugerii obj1 (notăm, că crearea lui obj2 nu utilizează un

2 Din documentaţia oficială de la http://qt-project.org/doc/qt-5/signalsandslots.html

copy-constructor, căci aceștia sunt privaţi în QObject).QObject *obj1 = new QObject();QObject *obj2 = new QObject(obj1); //this also sets obj1 as the parent of obj2

delete obj1;

Implicit sharing se referă la un mecanism intern folosit mai ales pentru container-e Qt și obiecte de mari dimensiuni. El imple-mentează abordarea copy-on-write, adică copiază doar un pointer la structura de date la fiecare asignare, și copiază întreaga structură de date numai în cazul în care există o operațiune de scriere. Acest lucru garantează că nu sunt create copii redundante a structurilor mari de date, îmbunătățind astfel performanța .

În codul de mai jos se presupune că list1 este o listă foarte mare. Când este creat list2, list1 nu va fi copiat, doar un pointer este copiat în interior, Qt ocupându-se de aceasta în fundal:

// suppose list1 is a very large list of type QList<QString>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 nici o operație de scriere n-a fost efectuată, iar lista mare nu a fost copiată.

Cross-platform și Nativ Qt este cu adevărat cross-platform. Acest lucru înseamnă

un singur codebase și un stream unic de dezvoltare pentru orice număr de platforme suportate. Este nevoie doar de a seta diferite configurații de build pentru a face deployment pe sisteme diferite. Aceasta a fost una dintre cele mai importante motive pentru care Qt a fost ales într-un proiect industrial mare la care am lucrat, deoarece era necesar să fie suportat pe sisteme embedded bazate


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

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ă ele-mente 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 sis-tem de operare independent de platformă, cum ar fi procesarea de fișiere, funcţionalităţi de reţea sau imprimare.

Un API Grozav şi Documentaţie BunăAPI-ul de Qt nu este diferit de cele mai multe binecunos-

cute framework-uri în a fi intuitiv, robust și convenabil. După o oarecare familiarizare, navigarea define ușoară: lucrurile sunt, de obicei, numite cum ne-am aștepta ca ele să fie numite și sunt amplasate în locul în care ne-am aștepta ca ele să fie amplasate.

Documentația API este relevantă și simplă, nu e supraîncăr-cată . Uneori este nevoie de ceva timp pentru a găsi ceea ce căutăm. Dar, în general, aceasta este aprofundată, extensivă, având exemple relevante, frumos organizată și atrăgătore, fiind la linie și, ocazio-nal, chiar mai bună decât cele mai bune sisteme de documentaţie din industrie, cum ar fi MSDN sau documentaţia Java API .

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 dyna-mic linking, adică pur și simplu folosind Qt prin DLL-uri. Licența comercială este destinată pentru cei care doresc să modifice bibli-otecile 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, dove-dind 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-boxExistă 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

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 MultQt 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ă, vom enumera câteva alte domenii în care Qt poate fi o soluție adecvată:

• UI declarativ: framework-ul QtQuick și limbajul QML oferă un mod declarativ de a construi interfețe dinamice cu tranziții și efecte fluide, fiind destinat în special pentru dispozitive mobile. Logica pentru Uiș-uri descrise în acest fel poate fi scris fie în JavaScript sau în cod nativ C++/Qt.

• Scripting: QtScript oferă un framework de scripting, cu posi-bilitatea de a expune părți ale aplicaţiei către mediul de script, inclusiv mecanismul de signals și slots .

• Introspecție run-time mai bună și casting dinamic: prin uti-lizarea tipurilor care moștenesc de la QObject, o 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 obj1obj1.setProperty(”new property”, 2.5);

//d == 2.5double d = obj1.propety(”new property”);

• Pointer-ele smart și managementul sunt de asemenea supor-tate, 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 aseme-nea, 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

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

Lăsând gluma la o parte, aţi investi într-un 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 audi-enţe la conferinţa CloudOpen de anul trecut, vorbind despre cum să creezi o primă com-panie ce oferă servicii cloud și făcea mereu referire la acest aspect. Dacă nu ai API, cei-lalţ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 vir-tute. Ș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 dezvol-tatori 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 drep-tate. De ce să nu fie așa? La urma urmelor, voi sunteţi în competiţie pentru atenţia lor cu alţi furnizori.

Dacă 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 [email protected]

Functional arhitect@ HP România


Dincolo de APIprogramare

API nu sunt deloc ceva nou. Ele au existat de la începutul ani-lor 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 dez-voltatori. Toată lumea a început să le utilizeze și să le aleagă, în defavoarea alternativelor mai complexe. Nu ar fi frumos să ai age-rimea minţii și să anticipezi „următorul REST”?

Mai mult decât API: noAPIEste 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 conside-rate 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 con-ceput 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, faci-litâ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ă potri-virea tiparelor care trebuie făcută, cu atât mai ușor devine să nu

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 vir-tual. 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 tre-buie 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 infor-maţ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, dezvol-tatorul nu trebuie să se concentreze pe „cum”, ci numai pe „ce”.



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 rapideImplementarea 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 compa-tibil 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 com-plex, 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 mode-lul 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?


programare

Î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 progra-mele 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, creator de ore suplimentare, atunci când dorim să păstrăm serverele de producție, sau chiar și pe cele de dezvoltare, actual-izate. Deseori, administratorii de sisteme găsesc sisteme care sunt pornite de timp îndelungat și care nu au fost actualizate cu anii. Din punctul de vedere al afacerii, atât timp cât acele sisteme funcționează și își fac datoria, nu contează dacă sunt actu-alizate sau nu. Doar atunci când ceva rău se întâmplă, spre exemplu când baza de date cu utilizatorii și parolele sau alte date valoroase se scurg în mâinile persoanelor neautorizate sau chiar către tot Internetul din cauza unei breșe de securitate, sau când programatorii observă că programele lor au nevoie de o versiune actualizată de pro-grame care e incompatibilă cu versiunea sistemelor de operare folosite pe producție, echipa de conducere grăbește echipa de administrare de sisteme să facă actualizări urgente. Această grabă cauzează în contin-uare instalarea pe sistemele de producție a unor sisteme testate insuficient.

Pentru a simplifica și formaliza pro-cesul de actualizare fără a fi nevoie de achiziția de noi echipamente, noi am atacat problema în doi pași: întâi, am virtualizat stratul aplicației folosind Containere Linux (LxC). Această formă de virtualizare ne-a permis să creăm „mașini virtuale”, fără a pierde din performanța sistemelor sau fără a le supraîncărca cu un strat de simulare a părții fizice, cum se face în cazul VMWare sau KVM de la RedHat sau în cazul Oracle VirtualBox sau XEN; al doilea pas a fost să „virtualizăm” nodurile fizice (calculatoarele fizice) folosind ca sistem de fișiere rădăcină un fișier imagine al unei partiții.

Câștigul în a avea „sistemul de fișiere rădăcină într-un fișier imagine” e că acum

putem înlocui sistemul de fișiere rădăcină cu unul nou doar prin repornirea sistemu-lui; revenirea la sistemul anterior se face de asemenea ușor, doar cu ajutorul unei noi reporniri a sistemului. Un alt câștig al instalării unui sistem de fișiere rădăcină într-un fișier imagine este că sistemul de operare instalat în interiorul fișierului poate fi actualizat și testat eficient pe un sistem de dezvoltare decuplat de producție, pentru ca apoi să poată fi publicat pe toate serverele deodată, automat. Când oricare dintre acele servere trebuie actualizat, este suficientă o repornire a sistemului. Această soluție poate fi întâlnită aproape pe toate sistemele înglobate (embedded systems), unde producătorii publică „fișiere imag-ine” ce pot fi încărcate în router-e, plăci de administrare decuplată (DRAC, iLO, AMT), etc. .

În cazul nostru, am utilizat o distribuție de Linux bazată pe surse - Gentoo Linux. Vă puteți întreba „De ce ar vrea cineva să compileze totul din surse când este extrem de ușor să instalezi pachete binare?”. Când instalează un server, administratorul de sisteme se trezește compilând programe din mai multe surse din varii motive: pachete disponibile prea vechi, nevoia de anumite opțiuni ce pot fi activate sau dezactivate doar la compilare, petice ce trebuie aplicate pentru a rezolva greșeli în program, etc. . Dacă adăugăm la această muncă și munca de actualizare periodică, administratorul se găsește în situația de „a-și câștiga banii cu sudoarea frunții”. Se mai poate întâmpla ca nu doar un anumit program să necesite compilarea din surse, ci și programele de care depinde. Pe o distribuție binară, întâmpinăm multe probleme la compila-rea din surse, una din ele fiind cunoscuta problemă a „iadului dependențelor”, alta

Întreţinerea la zi a sistemelor Linux –

Partea I

Sorin Pâ[email protected]

Senior Systems Administrator@ Yardi România



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 calcula-toarele 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 imag-ine 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 intem-perii ș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 direc-tor (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 direc-torul /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-root-

new.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 particular-izate 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 direc-tor 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țializareGenkernel este un script dezvoltat în cadrul proiectu-

lui 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

[email protected]

Yardi Romania


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

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 dia-grama 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 siste-melor 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 admin-istrare (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

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 tre-bui să încărcați modulul ext2 dacă aveți o imagine de partiție formatată ca ext, ext3 sau ext4):

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 2LABEL=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: grub2-install --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 virtual-izarea 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!

https://github.com/psihozefir/genkernel.git


programare

Silvia Ră[email protected]

Senior Developer@ ISDC

Modelarea datelor în contextul Big

Data

Câ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).

Despre normalizareNormalizarea datelor face parte din pro-

cesul de modelare a datelor pentru crearea unei aplicații. De cele mai multe ori, nor-malizarea este o practică bună din cel puțin două motive: evită problemele de integri-tate î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 modela-rea 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 frag-mentate, 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

când se lucrează cu baze de date relaționale. Mai mult, chiar și lexicul și etimologia susțin această practică: datele fragmentate sunt con-siderate “normale”.

Despre denormalizare Când vine vorba de modelare a date-

lor î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 mode-lare. 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ă obser-vă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, proce-sul de modelare a datelor trebuie să aibă în vedere entitățile pe care le manevrează în mod logic (după care caută), cum ar fi: arti-cole, 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, denorma-lizarea se face doar pentru a servi aplicația – bineînțeles, cu grijă- pentru că denormaliza-rea excesivă poate cauza mai multe probleme decât soluții. Ordinea pașilor în care se dez-voltă 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


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 inte-rogare descriu mai bine metodologia agilă: dacă cerințele funcționale și atributele de calitate nu sunt îndeplinite atunci modi-fică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 nor-malizarea 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 pen-tru problemele de integritate depinde de arhitectura aleasă a aplicației, dar și de “proprietarul” datelor.

Rezolvarea problemelor de integritate la denormalizare

În momentul în care se alege denor-malizarea 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

instrument de extragere-transformare-încărcare (ETL) datele ajung în “depozitul” big data. Având aceste două opțiuni, posi-bilele probleme de integritate se tratează altfel.

În cazul în care datele există doar în sis-temul big data, este necesar un instrument de sincronizare și integrare a datelor care au suferit alterări. Instrumentele care imple-mentează 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 exe-cutată – 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 nor-malizat. Î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 anu-mit standard de performanță și încredere, deci noile modificări trebuie să fie aplicate pe sistemul de big data cât mai repede posi-bil; există, așadar, riscul de a denormaliza excesiv, reducând foarte mult din efortul de calcul din sistemul de big data.

Denormalizarea și join-urileDupă toată pledoaria de mai sus pen-

tru denormalizare, pare lipsit de sens să mai atingem subiectul „join”; denormal-izarea 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 radi-cal opțiunile de modelare/denormalizare. Să luam un exemplu concret, modelul de

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 deri-vate 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 tre-bui 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 sub-scriere 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 normali-zate pentru a oferi utilizatorului entitățile logice. Bineînțeles, denormalizarea com-pletă nu este cea mai bună opțiune pentru a încapsula o relație mare de join many-to-many, după cum am arătat în paragraful precedent. Și pentru a termina într-o nota veselă, conform titlului articolului2: „nor-malization 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-for-sissies.aspx

Modelarea datelor în contextul Big Dataprogramare


Code Kata

Cuvâ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ă coreogra-fie, care pot fi practicate fie singur, fie în perechi.

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 suc-ces 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 dez-volte 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ă inter-nalizarea acestor mișcări și tehnici, astfel încât persoana să le poată adapta diferitor nevoi.

Exersarea Exersarea ca o metodă de învăţare este

ubicuă. Se poate vedea în toate domeniile, nu doar în arte marţiale:

• Cântatul la un instrument muzical,• Îmbunătăţirea performanţei în sport,• Pregătirea pentru un discurs în public,

ș.a. .Incontestabil este o metodă fundamentală

de învăţare. Desigur, depinde de mai mulţi factori, dar cu dedicarea și ghidarea corectă, o persoană poate să exceleze la multe lucruri doar prin exersare.

Memoria ProceduralăMemoria procedurală este un tip de

memorie de termen lung, mai specific, dove-dindu-se eficient în învăţarea bazată pe tehnici. Acest lucru e realizat prin repetarea unui task complex, rezultând astfel într-o îmbunătățire a sistemului neuronal utili-zat pentru a realiza acel task. Psihologii au

început să scrie despre memoria procedurală de peste un deceniu. După multe cercetări, a fost dovedit faptul că doar simpla repe-tare 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ân-dit și abilitatea nouă.

Code KataDave Thomas a fost primul care a intro-

dus ideea de Kata-uri ca tehnică de învăţare în programare. Abordarea este destul de sim-plă: 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 care pot să vină în ajutor în rezolvarea de alte probleme. Kata-ul se poate face și prin adau-garea de alte provocări, cum ar fi anumite limitări: de exemplu, folosirea unui limbaj de programare diferit faţă de cel obișnuit zilnic. Se poate realiza fie individual, fie într-un grup organizat.

Munca de la servici nu înseamnă exersareServiciul poate aduce prea multă presi-

une asupra programatorilor neexperimentaţi: presiunea nevoii de a livra cod de calitate folosind tehnici nefamiliare, care poate duce la frustrări, greșeli, sau lipsa aplicării de „best practices”. Ajutorul din partea mentorilor nu este o permanență: programatorii experimen-taţi sunt ocupaţi cu terminarea task-urilor asignate și nu găsesc timpul necesar de alocat pentru ajutarea creșterii celorlalţi.

Pentru a deveni un programator mai bun este nevoie de exersare. Cât de bună ar fi o trupă de muzică dacă și-ar exersa cântecele

management

Tudor Trișcă[email protected]

Team Lead & Scrum Master@ msg systems România



managementCode Kata

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 KataMultă lume e de părere că sesiunile

de Code Kata se referă la rezolvarea ace-leaș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 pro-cedurală: 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 acelu-iaș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ă.

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

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

Tips & TricksPair-programming: munca

în echipă este un factor impor-tant în sesiunile de Code Kata. Acesta trebuie să încurajeze ca învăţarea să se producă în tim-pul implementării pentru că programatorul care nu este la tastatură observă, comentează și întreabă, furnizând un feedback continuu (dar fără dictare, cri-tică sau control).

Finalizarea unui task nu tre-buie forţată. Dacă se pune prea mult accent pe terminarea task-ului, 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 task-ului într-un anumit timp setat.

În timp se va observa că tehnicile de pro-gramare 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 sesi-unii 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 pro-gramatorii să înţeleagă că există mai mult decât o modalitate de a face un anumit lucru și ștergerea codului existent și înce-perea task-ului din nou este câteodată cea mai bună opţiune.

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

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 reasigura-rea faptului că greșelile și eșecul reprezintă un lucru bun.

Încurajarea comunicării. Camera în care se susţine sesiunea de Code Kata tre-buie 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 pro-ces, 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 pen-tru sesiune fiindcă atunci entuziasmul va cădea și programatorii se vor decupla de la întregul proces.

ConcluzieIdeea de pornire atunci când dorești să

iniţiezi sau să participi la o astfel de sesi-une 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 exersa-rea, 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



Analiza eficientă a scenariilor de utilizare

management

Elicitarea 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 utiliza-tori ș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 efici-ente este una dintre cele mai importante responsabilități ale unui analist de busi-ness, 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 scenarii-lor de utilizare permite o descriere pas cu pas a acțiunilor - independente și interco-nectate - 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 inter-mediul 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 sis-temului și pot fi de mai multe tipuri, ca de

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

După ce a pus în evidență actorii, ana-listul identifică activitățile desfășurate de fiecare. Acestea se numesc cazuri de utili-zare (engl. use cases) – și reprezintă modul în care actorii interacționează cu siste-mul pentru a obține valoare de business. Aceste acțiuni trebuie să fie indepen-dente, 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 dome-niul 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 utili-zare al sistemului din perspectiva fiecărui actor. Scenariile de utilizare reprezintă o tehnică foarte puternică de modelare a sce-nariilor de business. Setul complet de actori și de scenarii se mai numește și system’s use case model. Acest model poate fi reprezen-tat fie ca un document scris fie ca diagramă, de regulă ambele, deoarece se pot sur-prinde 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 cazSă presupunem că avem un client al

cărui domeniu de business constă în găzdu-irea de evenimente, de exemplu conferințe, în clădirea proprie.

Clădirea are trei săli de conferință, fie-care 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ță.

Mo m e n t a n , c l i e n t u l m e n ț i n e 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ă proce-deze 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 sim-plitate, 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 capaci-tate, drept pentru care pot avea și prețuri diferite.

Prin urmare, ‘domain knowledge’ ne ajută din nou, întrucât politicile de over-booking intră în discuție.

În orice caz, nu trebuie să facem pre-supuneri, 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 conclu-zionat 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!


Analiza eficientă a scenariilor de utilizaremanagement

Cine sunt actorii? Câțiva dintre ei sunt evidenți: persoanele care fac, confirmă și anulează rezervările și clienții clientului nos-tru 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 nos-tru 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 per-soană 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?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ă înce-pem 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!

El creează un Eveniment pentru clientul său, cu nume și descri-ere ș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 agendă, odată ce acesta a avut loc!

Astfel, noi deducem că evenimentul trebuie să aibă și o dată, deci n-ar avea sens să lăsăm angajații să facă asignări pentru un

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

Fig. 2 – O diagramă rafinată



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, clien-tul 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 sce-nariile 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:

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ă asig-neze 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

î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 prezen-tat 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 spe-cifica 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 dis-ponibile, fie ar reuși, din cauză că nu există politici de overbooking care ar putea anula o rezervare aparent reușită.

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 Fig. 4 – Adăugarea Administratorului



Analiza eficientă a scenariilor de utilizaremanagement

Anita Pă[email protected]

Business analyst@ Endava

cu adevărat un eveniment sau doar îl marcăm ca petrecut astfel încât să nu se mai poată face alte rezervări pentru el? Contează, deoarece ne-ștergerea unui eveniment ne permite să-l marcăm ca încheiat, dar în același timp ne permite să rulăm rapoarte pe acel eveniment (cum ar fi raportul de ne-participare).

Ca de obicei, întrebând clientul, acesta confirmă că de fapt dorește ca evenimentul să rămână în istoricul sistemului și că scenariul ar trebui într-adevăr să fie numit “Închidere eveni-ment”. Fiind închis, nicio rezervare nu poate fi făcută pentru acel eveniment. Totodată, odată închis, evenimentul nu mai poate fi redeschis deoarece închiderea ar trebui făcută doar după ce eve-nimentul s-a petrecut efectiv! Luând aceasta în calcul, îl întrebăm dacă închiderea nu ar trebui cumva să fie o acțiune automată exe-cutată de sistem la data evenimentului (rețineți că am descoperit anterior că pe lângă client, nume și descriere, evenimentul are și o dată).

Clientul aprobă bucuros ideea noastră, și prin urmare:

Fig. 6 – Diagrama use case completă

În sfârșit se pare că avem diagrama completă, cu toate sce-nariile pe care clientul le-a cerut, împreună cu funcționalități de automatizare și administrare.

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 plani-

ficare 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

limitări.• Use case-urile reprezintă un punct de pornire solid în ceea

ce privește strategia de testare a produsului.

Limitările use case-urilor • Diagrama de use case-uri nu reprezintă setul complet de

cerințe funcționale ale sistemului.• Sunt proiecte în care scrierea de user stories e considerată a

fi mai puțin complicată și consumatoare de timp decât scrierea de use cases.

• Deoarece nu există o metodă standard de scriere a use case-urilor, fiecare analist de business trebuie să le creeze în funcție de propria lui viziune asupra cerințelor funcționale.

• Când avem de a face cu proiecte care au scenarii complexe, use case-urile corespunzătoare pot fi dificil de înțeles de către clienți sau utilizatorii finali.

• 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 com-portamentului 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ă des-coperim adevăratele cerințe! Doar prin aplicarea unei analize amănunțite a scenariilor de utilizare putem spera să descoperim modelul domeniului (engl. Domain Model) care stă la baza con-textului și să dezvoltăm un sistem IT aliniat la adevăratele cerințe de business!


TODAY SOFTWARE MAGAZINE management

Abilitățile sunt mai presus de tehnologie

Evoluț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 progra-matorii 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?

Fundamentele tehnologiei nu se schimbă așa multCând a fost inventat unit testing-ul? Test Driven Development?

Folosirea abstracțiilor pentru design ușor de modificat? Principiile SOLID?

Toate par a fi noi. Cărțile despre ele au fost publicate în ultimii zece ani. Dar sunt cu adevărat noi?

Barbara Liskov a avut la QCon 2013 keynote-ul intitulat “The Power of Abstraction”1. În keynote, ea analizează conversațiile inițiale pe care o comunitate mică de programatori le-a avut des-pre design modificabil în anii ‘70. Tot în aceeași perioadă, ea a dat numele unuia din principiile SOLID, “Liskov Substitution Principle”, printr-o remarcă scrisă pe un bulletin board. Acum 40 de ani! 40 de ani au trecut de când unul dintre principiile de bază din designul OOP a fost formulat și pe care milioane de programa-tori îl folosesc de atunci în fiecare zi. 40 de ani de când abstracțiile au fost introduse pentru a permite design ușor de modificat.

Dar poate și alte aspecte din tehnologie sunt revoluționare. Serviciile web sunt o idee nouă, nu? Sau arhitectura REST?

E adevărat că anumite lucruri au trebuit să se întâm-ple pentru ca serviciile web să apară. O nevoie de business. Standardizare. Expansiunea web-ului. Dar, dacă ne uităm atent la serviciile web, ideea de design din spatele lor este următoarea: Compunem funcționalitate complexă din componente mici care fac un lucru bine şi comunică între ele prin mesaje text. Ciudat! Dar această idee a fost enunțată în anii ‘70 în cadrul principiilor de design UNIX2:

“Rule of Modularity: Write simple parts connected by clean interfaces.

Rule of Composition: Design programs to be connected to other programs.

Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.”

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

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 calcu-latoare individuale într-o rețea, capabile doar să comunice prin mesaje (deci mesajele au apărut la început de tot) - ne-a luat mult timp să ne dăm seama cum putem trimite mesaje într-un limbaj de programare într-un mod destul de eficient încât să fie util.”3

“Fiecare obiect ar trebui să aibă un URL”4

Al doilea citat este dintr-o prezentare din 1993. Serviciile REST, într-o propoziție scurtă, acum 20 de ani.

Dacă fundamentele tehnologiei nu se modifică, atunci ce anume se schimbă?

Implementarea devine mai simplăAcum douăzeci de ani, dacă un programator trebuia să imple-

menteze o comunicare între două obiecte pe rețea, reușita acestei operații era condiționată nu numai de multă pricepere ci și de multă magie. O tehnologie (sperăm uitată) numită CORBA era modul standard de a o implementa. Programatorul trebuia să o înțeleagă, să scrie cod într-un anumit mod, să repare problemele care apăreau și multe altele. Un task de acest gen consuma foarte mult timp, în afară de cazul în care programatorul era capabil să vizualizeze octeții care erau transmiși între procese.

Azi, modul standard de a implementa acest task este de a scrie un serviciu web cu o interfață bine definită, un lucru pe care orice programator îl poate implementa în câteva ore (presupunând că funcționalitatea este simplă). Programatorul nu are idee cum se realizează comunicarea între procese (în afara cazului în care vrea să afle), doar că funcționează atunci când codul este scris într-un anumit fel.

Acum cincisprezece ani, scrierea unui mic program cerea cunoștințe despre modul în care este alocată memoria. Acest lucru genera multe zile de investigații pentru erori cu mesaj foarte de “ajutor”, “memory corruption error: #FFFFFF”. Azi, majoritatea programatorilor au uitat despre pointer-i și alocarea dinamică a memoriei, pentru că limbajul de programare și platforma au pre-luat această funcționalitate.

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


Abilitățile sunt mai presus de tehnologie management

Schimbarile din tehnologie sunt rare-ori fundamentale. Cel mai des se modifică implementarea. Iar implementarea devine tot mai simplă în timp. Dar dacă imple-mentarea 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ăspun-suri 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 relati-viste. Server-ele se opresc. Rețelele nu mai funcționează.

Dificultatea fundamentală a progra-mă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 sim-plificat, dificultatea fundamentală a programării a devenit vizibilă. Azi vorbim mai puțin despre comunicarea între servi-cii și mai mult despre design modificabil, pentru că schimbarea face parte din lumea reală. Azi vorbim mai puțin despre aloca-rea de memorie și mai mult despre testare unitară, pentru că toată lumea face greșeli în lumea reală.

Aceasta ne aduce la concluzia:

Abilitățile sunt mai presus de tehnologieTehnologiile se modifică. Dar funda-

mentele 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 progra-marea 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

gata să dea piept cu lumea reală.

Abilități independente de tehnologieAm 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”.

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 teh-

nice 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).

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,

• Î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.

ConcluzieD i f i c u l t a t e a f u n d a m e n t a l ă a

programării a fost întotdeauna de a tra-duce cerințe ambigue în cod foarte precis și rezistent la problemele care pot apărea în lumea reală. Răspunsul la această pro-vocare a fost dezvoltat în ultimii 50 de ani și nu s-a modificat prea mult în timp. Singurul lucru care se modifică este imple-mentarea, 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://itakeun-conf.com sunt organizate cu acest scop. Alătură-te lor și crește-ți cariera ca software craftsman și nu ca viitor manager.

Alexandru [email protected]

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

Adrian [email protected]

Programmer. Organizational and Technical Trainer and Coach@Mozaic Works

http://agileworks.ro/

http://itakeunconf.com/

http://itakeunconf.com/


management

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

Cu 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 scrum-ul 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 proi-ectelor curente, cu prieteni din domeniu şi în acelaşi timp cu multă altă lume în inter-viuri. 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ă dintr-un 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 meeting-ul 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 între-barea “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 sis-temelor aflate deja în producţie. Analizând contextul şi modul de evoluţie al lucrurilor s-a realizat că eficienţa maximă se va pro-duce prin iteraţii de o săptămână. Ceea ce e în regulă. Avem alt client care datorită modu-lui 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 des-tul 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

Bogdan Mureș[email protected]

Director of Engineering@ 3Pillar Global



Scrum-ul perfect: Fata Morgană din Agilemanagement

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 imple-mentat ş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 rezul-tatului 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 con-cluzia că o eficienţă rirdicată este obţinută atunci când clientul trece prin procesul de acceptare în timpul iteraţiei, astfel ca meet-ing-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 suc-ces. 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ându-se 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 segmen-tul 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 concen-trare 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ă pen-tru 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ântu-lui Scrum vine tocmai de la adaptare, de la încercarea unor noi posibilităţi.

În toate aceste situaţii lumea uită rezul-tatul final. În nici un caz nu vreau să spun că modul în care ajungem acolo nu e impor-tant, 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ă, volun-tar 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 mod-elului (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 contex-tul Agile. Este important să ne orientăm concentrarea către Scrum. Este o metodol-ogie care a dat rezultate şi dă în continuare rezultate foarte bune.

www.3pillarglobal.com

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

Our core competencies include:

ProductStrategy

ProductDevelopment

ProductSupport

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



5 reguli simple pentru o campanie eficientă

management

Un 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 trebuie să vă asiguraţi că:

• Baza de date este formată doar din utilizatori care şi-au dat acceptul să primescă comunicari pe email din partea companiei

• Utilizatori care au cumpărat un pro-dus sau un serviciu în ultimele 18 luni

#1. Segmentează-ţi audienţaUna 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/

mesaj (61%) şi buton de call-to-action sau imaginile folosite în email (50%). Alte ele-mente care ce pot fi testate sunt:

• Câmpul de From• Ora din zi la care se trimite Campania• Ziua din săptămână când se trimite

Campania• Landing pageul folosit• Audienţa care primeşte emailul

#3. Defineşte un pattern şi trimite emai-lul 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 reco-mandat 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 mobilStiaţ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 arti-cole sportive va intra în curand în perioada reducerilor. În momentul în care utiliza-torul deschide emailul primit şi e interest de un articol, odată ajuns pe pagina produ-sului, 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 ches-tionar de feedback. Veţi descoperi lucruri noi despre compania dumneavostră.

Ruxandra [email protected]

Conversion Analyst@ Betfair


management

Big Data şi Social Media: marea schimbare

Dintr-o dată, ne dăm sema că unitatea de măsură a date-lor 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 rapideConform informaţiei colectate de IBM într-un raport reali-

zat î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 giga-

byte) de date sunt create zilnic.• 6 miliarde de oameni din 7 miliarde (populaţia curentă glo-

bală) 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).

Legate de diversitate (varietate):• 300 miliarde de unităţi de conţinut sunt distribuite pe

Facebook în fiecare lună.• 400 milioane de tweet-uri sunt trimise zilnic de către circa

200 milioane de utilizatori activi .• 4 miliarde de ore video sunt vizionate pe youtube în fiecare

lună.• Până la finele lui 2014, se estimează că vor exista cca 420

milioane de dizpozitive portabile de monitorizare a sănătăţii.

Legate de viteză (velocitate):• NYSE captează 1 TB de informaţie în fiecare sesiune

tranzacţională.

• 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 instrumen-tele clasice de procesare a datelor. Dacă noi am preluat sintagma din limba engleză, trebuie să notăm ca specialiștii francezi îl tra-duc î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 înce-putul 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 conceptului Big Data în sine. Recent un al 4-lea V a fost atașat definiţiei: veridicitatea. Totodată merită notate și cele trei perspec-tive aplicate conceptului: cea tehnologică, cea de proces și cea de afaceri.

Analizele Social Media şi Big Data Una dintre caracteristicile esenţiale ale Big Data provenite din

social media este că sunt în sau aproape în timp real. Acest aspect 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 într-un anumit loc.

Fiecare trăsătură fundamentală a datelor masive (Big Data) poate fi înţeles ca un parametru pentru analiza cantitativă,

De 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!



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 subse-turilor 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 feno-menelor î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 inte-resant este că putem totodată monitoriza lanţul de distribuţie al datelor.

VeridicitateaPentru 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 genera-torului initial al datelor, scopului pentru care datele sunt emise și reacţiilor receptorilor.

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 repre-zentate de MongoDB, DynamoDB, CouchBase, Cassandra, Redis și Neo4j. În prezent acestea sunt cunoscute ca cele mai perfor-mante 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 indi-catorii 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ăţiCând avem de-a face cu un nivel de ordine cu totul nou, cap-

tarea, 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

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ă, meteo-rologie, 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țiePentru 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).

Diana [email protected]

Marketing Manager@ Codespring


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 infor-maţ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 inte-

riorul unei clădiri.

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.

Cum se auto-identifică un iBeacon?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 iBe-acon-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

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?

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.

Componentele platformei OnyxBeacon

OnyxBeacon iOS SDKiOS 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 protocolu-lui 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 pro-cesarea cerinţelor.

iBeacon 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 cio-colată dintr-un hipermarket?

Platforma OnyxBeacon iBeacon

programare



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

OnyxBeacon backend definește mai multe entităţi flexibile care definesc experienţa utilizatorului final. Fiecare entitate se sca-lează pentru a asigura flexibilitate în definirea conţinutului care va fi oferit utilizatorului Aplicaţiei.

Entităţile OnyxBeacon Backend

Fasciculele aplicaţiei (Application Bundles)Definesc informaţiile necesare și simbolurile de autentificare

cerute pentru o aplicaţie specifică (care implementează SDK) pen-tru a comunica în mod corespunzător cu OnyxBeacon API.

Pot fi definite următoarele proprietăţi:• Nume – Nume Aplicaţie – utilizat pentru a distinge diferi-

tele aplicaţii care utilizează SDK.• Descriere – utilă pentru a adăuga comentarii și date care nu

sunt critice despre aplicaţie.• Identificator – Identificatorul aplicaţiei – acesta trebuie să fie

cel disponibil când aplicaţia a fost publicată în magazinul pentru mobile sau pe perioada procesului de dezvoltare.

• Secret – secretul iniţial pentru aplicaţie, cerut în autentificare.

UUID-urile companieiDefinesc o listă de identificatori de emiţătoare (Beacon) dis-

ponibili, care vor fi mai târziu utilizaţi pentru a identifica în mod unic un emiţător (Beacon).

Pot fi definite următoarele proprietăţi:• Nume - ~ ,• Descriere - ~ ,• Identificatori – un identificator unic (format UUID) utilizat

în conjuncţie cu alte proprietăţi pentru a identifica în mod unic un emiţător (Beacon) – Acesta este necesar.

Emiţătoare (Beacons)Definesc o listă de emiţătoare unice pentru a fi folosite în con-

juncţ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.

Media Utilizată pentru a defini unităţi media oferite utilizatorului

aplicaţiei. În prezent suportă imagini care sunt oferite cu Coupons.

CouponsDefinesc conţinutul care va fi oferit utilizatorului finalPot fi definite următoarele proprietăţi:• Nume - ~ ,• Descriere - ~ ,• Mesaj – un mesaj arătat utilizatorului odată ce Cupon-ul

este oferit ,• URL – utilizatorul va fi redirecţionat către acest URL atunci

când face click pe Cuponul servit pe dispozitivul mobil ,

• Media – Imaginea arătată pe cupon.

Perioade de timpDefinesc perioadele de timp utilizate în conjuncţie cu Planurile

și Cupoanele. Un anumit Cupon va fi servit utilizatorului final într-o anume perioadă de timp, pentru un Plan.

Următoarele proprietăţi pot fi definite:• Nume - ~ ,• Descriere - ~,• Cupon – Cuponul care va fi utilizat ,• Start – momentul în care cuponul devine activ,• Stop – momentul când cuponul nu mai este activ .

PlanuriDefinesc Planul de Promiţie pentru un anume Beacon (emi-

ţător). Pot fi create mai multe planuri pentru a cuprinde perioade de timp diferite și ⁄ sau emiţătoare diferite.

Pot fi definite următoarele proprietăţi:• Nume - ~ ,• Descriere - ~ ,• Beacon (emiţător) – emiţătorul pentru care se aplică planul,• Perioada de timp – perioada de timp utilizată (în consecinţă,

ce cupon va fi oferit utilizatorului final).

PromoţiiDefinesc o Promoţie, având mai multe Planuri și o perioadă

de timp în care aceasta este valabilă. Acest fapt oferă o mai mare flexibilitate privind modul în care conţinutul va fi oferit utilizato-rului final.

Pot fi definite următoarele proprietăţi:• Nume - ~ ,• Descriere - ~ ,• Start ⁄ Stop – perioada de timp în care promoţia este valabilă

,• Planuri – planurile disponibile pentru promoţie.

Derularea activităţiiCrearea 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 utiliza-rea secţiunii „Setup Entities”, accesibilă din meniul de sus. Noile elemente create aici vor trebui legate manual odată ce au fost cre-ate, sau prin utilizarea opţiunii „Add new” în timpul definirii lor.

Derularea procesului, cu dependenţele cerute, se poate rezuma la ceea ce urmează: Application Bundles (Fasciculele aplicaţiei)-> Company UUIDs (UUID-urile companiei)-> Beacons(Emiţătoare) -> Media -> Coupons (Cupoane) -> Time Frames (Perioade de timp)-> Plans (Planuri)-> Promotions (Promoţii).

Apeluri API BackendDacă cineva are un backend diferit și dorește să utilizeze

SDK-ul nostru pentru iOS și Android, îi putem pune la dispoziţie apeluri api. Toate apelurile api folosesc metoda POST și sunt efec-tuate utilizând un server URL. Serverul URL poate fi configurat în SDK pentru a indica o adresă diferită de



Platforma OnyxBeacon iBeaconprogramare

https://connect.onyxbeacon.com/api.php

Unităţile de cerere și răspuns sunt obiecte JSON.

Găsirea UUID-urilorLa pornire, SDK va face o cerere pentru a obţine lista UUID-

urilor din proximitate care sunt configurate pentru identificatorii fascicul oferiţi în unitatea de cerere.

• Cerere{ “function”:”getUuids”, “parameters”: { “identifier”: “com.example.app”, “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” }, ... ) }}

• RăspunsRăspunsul este un obiect JSON primit de la server, iar struc-

tura este definită de către dezvoltator.

Metrici utilizator• CerereDicţionarul de informaţii utilizatori este oferit de cheia user-

Metrics 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) utili-zează informaţii despre utilizatorii Facebook pentru alte procesări și analize pe server.

Metrici CuponApelul metrici cupon este specific pentru modulul de market-

ing mobile și poate fi utilizat pentru a notifica backend-ul cu privire la acţiunile utilizatorilor. Informaţiile sunt cuprinse în dicţionarul couponMetrics și are două chei:

• couponid – id-ul conţinutului oferit de backend,• couponaction – una dintre valorile deschise sau tastate este

setată în funcţie de acţiunea utilizatorului, Acest apel poate fi folosit pentru orice tip de conţinut definit

de dezvoltator.• Cerere

{ “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 hack-athon, unde vom avea emiţătoarele noastre și SDK-urile pe care le puteţi utiliza pentru a oferi experienţe deosebite utilizatorilor de mobile.

Bogdan [email protected]

Co-Fondator@Onyx Beacon


TODAY SOFTWARE MAGAZINE HR

De-adevăratelea!

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ă realita-tea 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 fil-tre 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ă perce-pem, 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 mar-tie, în multe organizații s-au derulat evaluarile de performanță (quarterly per-formance 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 discu-tă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.

Din p ersp ec t iva ce lu i care 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 ope-răm pe parcursul sesiunii de feedback). Fundamental attribution error pre-supune tendința de a atribui pentru comportamentele unei persoane pre-podenrent cauze interne (legate de persoană) în același timp minimi-zâ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ă presupu-nem 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 noro-cului. Acest lucru se vede cel mai bine în limbajul folosit pe parcursul unei evaluări, el fiind plin de diferite conju-gări ale verbului a fi. (”te rog să fii mai responsabil pe viitor”, ”nu ai fost pro-activ 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 com-portamentelor 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 atri-buim ne duce să presupunem că felul în

Avem 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, rezo-nabil. 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.



De-adevăratelea! HR

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 obiec-tivă, 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ă dis-torsiune 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 dezi-rabile ș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ă subes-timă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.

False consensus bias se referă la tendința oamenilor de a supraestima gra-dul 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 distor-siuni 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 reac-tance 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 ”schim-bă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 evalua-rea performanțelor este: ce s-a întâmplat

în trecut, ce menținem din ce s-a întâmplat în trecut, ce schimbăm şi cum arată schim-bare ş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ță, distorsi-unile cognitive nu vor putea provoca atâtea daune pentru că acolo unde operează, nu va mai fi un conținut relevant.

Antonia [email protected] aproape 10 ani trainer, psiholog, consultant sub formă de antreprenor, intraprenor și antreprenor din nou


TODAY SOFTWARE MAGAZINE programare

Î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, standar-dul 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 docu-mentul 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 sem-nificativ î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.

Spring MVC şi procesoarele de şabloaneCâ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 sim-plă, ce va fi compusă din două pagini: una care afișează o listă de produse și alta care afișează detaliile unui produs.

Apache VelocityVelocity (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 uti-lizat 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 programato-rii Java. Astfel, Velocity ne ajută să despărțim codul Java de codul paginilor web, oferind o alternativă viabilă tehnologiei JSP.

Velocity Template LanguageApache 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 pro-dusului 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 reprezen-tat de către variabile. Acestea pot referi obiecte definite în codul Java sau pot primi valori chiar în interiorul paginii web, prin inter-mediul 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 MVCSpring 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 enu-mera 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 proiectu-lui exemplu poate fi descărcat de la următoarea adresă: https://springvelocity.googlecode.com/svn/trunk.

După ce am declarat în w e b . x m l ser v let-u l DispatcherServlet care va gestiona toate request-urile și am definit fișierul servlet-context.xml cu toate elemen-tele specifice Spring, putem declara bean-urile pentru lucrul cu Velocity. În primul rând, avem nevoie de un bean cu id-ul velo-cityConfig, căruia îi vom transfera calea relativă la care se vor găsi șabloanele pentru paginile aplicației:

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

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 vizua-lizare să fie reprezentată prin șabloane Velocity, putem să vedem cum arată aceste șabloane. Partea cea mai interesantă a șablonului

Procesoare de șabloane pentru dezvoltare web în Java

https://springvelocity.googlecode.com/svn/trunk

https://springvelocity.googlecode.com/svn/trunk


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 contro-ller-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>

În blocul de mai sus observăm cum iterăm o colecție și cum acce-săm proprietățile obiectelor din model cu ajutorul VTL.

Avantaje și dezavantajeFiind unul dintre cele mai cunoscute proiecte în materie

de template processing, Velocity beneficiază de susținerea unei comunități bine stabilite. De asemenea, documentația de pe site-ul oficial este generoasă și există multe articole, care răspund la diverse întrebări. În plus, în decursul timpului au fost publicate câteva cărți dedicate proiectului Apache Velocity. Dacă aceste resurse nu sunt de ajuns, există un mailing list cu o arhivă bogată, la care ne putem abona.

Există o varietate de aspecte care ne pot convinge să utilizăm acest produs în următorul nostru proiect: Velocity este un proce-sor robust, flexibil și bogat în funcţionalităţi. Există dezvoltatori care afirmă că acesta ar fi cel mai puternic tool de acest tip de pe piaţă.

Un alt plus al acestui proiect este faptul că, pe lângă Velocity Engine, are în componență o serie de subproiecte: Tools (unelte și elemente de infrastructură, folositoare pentru dezvoltarea de aplicații web și nu numai), Anakia (transformare de documente XML), Texen (generare de text), DocBook Framework (creare de documentație), DVSL (Declarative Velocity Style Language – trans-formări XML).

Când vine vorba despre suport pentru IDE-uri, Velocity beneficiază de o serie de plugin-uri dezvoltate de membri ai comunităţii. Aceste plugin-uri sunt dedicate unor IDE-uri precum Eclipse, NetBeans, IntelliJ IDEA, ca să le amintim doar pe cele mai populare. Multe dintre acestea oferă evidenţierea sintaxei și chiar autocompletion. La dezvoltarea exemplului prezentat în acest arti-col am folosit Velocity Edit pentru Eclipse.

Așa cum am arătat într-un paragraf anterior, integrarea cu Spring MVC este facilă. De asemenea, distribuţia Spring MVC conţine o bibliotecă de macro-uri pentru binding support și form handling, unelte valoroase pentru dezvoltarea de aplicații web.

Deși este cel mai popular template engine în universul Java, Apache Velocity nu a mai beneficiat de niciun release din noiem-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 funcționalitățile deja implementate și încă nu există un release planificat.

Velocity este un proiect la care s-a contribuit intens, devenind un produs complex, intimidant pentru noii utilizatori. Sintaxa este oarecum greoaie, iar scrierea de template-uri fără ajutorul unui IDE care să suporte sintaxa VTL poate fi un coșmar.

FreeMarkerFreeMarker1 este un produs matur, distribuit sub licenţă 1 http://freemarker.org/

BSD. Asemănător proiectului Apache Velocity, FreeMarker oferă funcţionalităţi complexe care vin în întâmpinarea nevoilor dezvol-tatorilor 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 LanguagePentru 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-uri în cadrul șabloanelor pe care le scriem. De asemenea, ne este pusă la dispoziţie o bibliotecă bogată cu directive predefinite, care ne dau posibilitatea să iterăm colecţii de date, să includem alte șabloane și multe altele. În continuare, prezentăm un exemplu de apel al unei directive FTL, care asignează o valoare unei variable:

<#assign magazineUrl = ”http://www.todaysoftmag.com/“>

Observăm că în limbajul de templating specific FreeMarker, directivele predefinite se apelează folosind sintaxa <#numedi-rectiva parametri>, iar macro-urile se apelează cu ajutorul sintaxei <@macro parametri>. Expresiile se scriu astfel: ${expresie}.

Integrarea cu Spring MVCLa fel ca în cazul Apache Velocity, FreeMarker beneficiază de

suport pentru integrarea cu Spring MVC chiar din partea creatori-lor framework-ului web. Astfel, distribuția Spring MVC ne oferă o implementare de ViewResolver, dar și o bibliotecă cu macro-uri pentru binding support și form handling.

Folosind aceeași modalitate pentru a crea o aplicație Spring MVC + FreeMarker ca în cazul Apache Velocity, remarcăm că singurele modificări pe care trebuie să le efectuăm sunt în fișierul de configurare Spring și în șabloane. De fapt, vom vedea că acest lucru este valabil și atunci când ne vom ocupa de proiectele Thymeleaf și Rythm. De asemenea, trebuie să remarcăm că avem nevoie să declarăm în fișierul de configurare Maven dependința freemarker din grupul org.freemarker. Codul sursă al proiectului exemplu poate fi descărcat de la următoarea adresă: https://springfreemarker.googlecode.com/svn/trunk.

În servlet-context.xml înlocuim bean-ul de configu-rare și bean-ul cu rol de view resolver. Cel mai interesant aspect al acestor elemente XML este proprietatea cu cheia auto_import, care ne permite să importăm în toate fișierele noastre FTL macro-urile definite în fișierul spring.ftl, oferit de către distribuția Spring MVC. Acestea sunt accesibile prin intermediul alias-ului spring:

<prop key=”auto_import”>/spring.ftl as spring</prop>

Șablonul corepunzător view-ului list este reprezentat de fișierul list.ftl. Partea notabilă a acestuia este prezentată în continuare:<#include „header.ftl” /><h2>Products</h2><ul><#list products as product><li><a href=”/product/${product.id}”>${product.name}</a></li></#list></ul><#include „footer.ftl” />

În acest template observăm cum se poate include conținutul altui șablon, cum putem itera o colecție de obiecte și cum scriem o expresie FTL.

Procesoare de șabloane pentru dezvoltare web în Java programare

https://springfreemarker.googlecode.com/svn/trunk


TODAY SOFTWARE MAGAZINEmanagement

Avantaje și dezavantajeProiectul FreeMarker se bucură de o documentație cuprin-

ză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 dedi-cată 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 pen-tru 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, indica-tori 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, plu-gin-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.

ThymeleafThymeleaf2 este o bibliotecă Java distribuită sub versi-

unea 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 integra-rea 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 stan-dard 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/

de procesare DOM, care este o implementare proprie, de înaltă performanță. Cu ajutorul acestui mecanism reali-zează 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 DialectAceste 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 Maga-zine</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 cla-sice 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 MVCAșa cum am menționat, Thymeleaf ne oferă un modul pen-

tru 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 thyme-leaf-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 dezavantajeThymeleaf este un proiect care atrage tot mai mulți utiliza-

tori, dar și programatori care contribuie la dezvoltarea acestuia. Site-ul oficial ne oferă o varietate de resurse pentru a ne familia-riza 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

https://springthymeleaf.googlecode.com/svn/trunk



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.

RythmRythm3 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ă preocupa-rea 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.

Sintaxa procesorului de șabloaneRythm folosește caracterul special @ pentru a introduce toate

elementele de sintaxă. Acest lucru este exemplificat în blocul de cod prezentat în continuare:

@for (product: products) {<li><a href=”/product/@product.getId()”>@product.get-Name()</a></li>}

Pentru a putea utiliza în template obiecte adăugate modelu-lui de date în controller-ul Spring, trebuie să folosim următoarea notație:

@args java.util.List<ro.cdv.model.Product> products

Integrarea cu Spring MVCPentru integrarea cu Spring MVC avem la dispoziție o biblio-

tecă de clase third-party, disponibilă ca artefact Maven sub id-ul spring-webmvc-rythm și grupul com.ctlok. Având această dependință în proiect, putem declara bean-urile necesare în servlet-config.xml. Una dintre proprietățile bean-ului rythmConfigurator este mode, cu ajutorul căreia putem specifica în ce mod rulăm aplicația: dev sau prod. Codul sursă al proiectului exemplu poate fi descărcat de la următoarea adresă: https://sprin-grythm.googlecode.com/svn/trunk.

Avantaje și dezavantajeSpre deosebire de Velocity și FreeMarker, Rythm procesează

șabloanele, transformându-le în bytecode Java. Datorită acestui lucru, la runtime, procesarea acestora este foarte rapidă, plasând acest proiect alături de cele mai rapide procesoare de șabloane din universul Java.

Deși nu este la fel de vastă precum a celorlalte produse prezen-tate, 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 webmas-ter-i, iar cu ajutorul instanței Fiddle dedicate putem scrie șabloane Rythm și vedea rezultatul imediat. Fiind un proiect relativ tânăr, comunitatea din jurul lui nu este încă dezvoltată.

3 http://rythmengine.org/

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 dez-voltare. 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țeExistă 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-ben-chmarks am obținut următoarele rezultate pentru 10000 de request-uri:

• Velocity: 3.8 secunde,• FreeMarker: 4.8 secunde,• Thymeleaf: 43.2 secunde,• Rythm: 3 secunde.

Un alt test (disponibil la adresa h t t p : / / w w w .slideshare.net/jreijn/comparing-template-enginesjvm), în care Rythm nu a fost inclus, arată că Velocity și FreeMarker au avut performanțe aproape identice, în timp ce Thymeleaf a fost, din nou, printre cele mai lente procesoare.

Astfel, Rythm pare a fi cel mai rapid template engine dintre cele despre care am discutat în acest articol, Velocity și FreeMarker își dispută locurile al doilea și al treilea, în timp ce Thymeleaf a obținut cel mai slab timp.

ConcluziiDeși am văzut că proiectele prezentate ne pun la dispoziție

funcționalități similare, în urma acestei discuții putem trage câteva concluzii. Atât Velocity, cât și FreeMarker sunt produse consacrate, care și-au dovedit valoarea în multe proiecte de suc-ces, oferind performanță decentă. Pe de altă parte, Thymeleaf și Rythm sunt proiecte mai tinere, care vin cu o filosofie nouă, adaptată trendurilor în dezvoltarea web. Spre exemplu, Thymeleaf excelează la capitolul natural templating, în timp ce Rythm oferă o sintaxă curată, ușor de înțeles atât pentru programatori, cât și pentru webmaster-i. Putem concluziona că alegerea unui template engine depinde, în primul rând, de proiectul pentru care avem nevoie de acesta, fiecare dintre procesoarele despre care am discu-tat meritând să fie luat în considerare.

Dănuț Chindriș[email protected]

Java Developer @ Elektrobit Automotive

programareProcesoare de șabloane pentru dezvoltare web în Java

https://springrythm.googlecode.com/svn/trunk

https://springrythm.googlecode.com/svn/trunk


TODAY SOFTWARE MAGAZINE legal

Mulț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 tre-buie 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 start-up-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ă), know-how-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 bunu-rile 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 porto-foliul 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 ele-mentele 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 dis-cuț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 respec-tivul 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ţiali-tate (î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 încre-dere î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 mij-loc între dorința legitimă de a vă proteja ideea de afaceri și disponibilitatea investi-torului 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 negoci-erilor, 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 soli-cită – 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 investi-torului, 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.

Cum protejăm o idee bună de afaceri

Claudia [email protected] ro.linkedin.com/in/claudiajelea

Avocat & Consilier in domeniul marcilor @ IP Boutique


management

Gogu şi sticla de apă

Gogu î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 dezorien-tat, 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 oca-zia 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 intempes-tivă a lui Dan.

- Mda, la asta mă gândeam. Ne cam zdruncină plecarea asta a lui, e singurul care știe toate dedesubturile pentru proiec-tul ă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, des-pre 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...

- 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ân-deam 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 din-tre 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ă evo-luă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 indivi-duale. 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.

- No atunci, explică tu în scris cum faci asta, în special partea cu menținutul echili-brului, 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 îmbute-liem 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 com-pania ș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 pro-blemă 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, [email protected]

Speaker, trainer and consultant in project management,

Owner of Colors in Projects

powered by

sponsori

today software magazine n23/2014

Documents