Numarul 27 - septembrie 2014 - Today Software Magazine by Today Software Magazine

Nr. 27 • Septembrie 2014 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

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

JavaFX în Platforma Java Standard 8

Avantajele folosirii SVG

Interviu cu Chris Heilmann de la Mozilla Time Dude, un joc 3D cross mobile platform Cum poți testa conferințe de testare Cum se detectează fraudele folosind Titan Cu Smilestone la Imagine Cup 2014 Tranziția de la QA la BA

Invitație la a III-a ediție a conferinței Gemini Solutions Foundry Livrarea continuă Integrarea client server cu ajutorul RestKit Pragmatism în programare Clean Code – Functions Gogu în șoc ...cultural

6 Cluj IT Days 2014, www.itdays.ro Ovidiu Măţan

8 Invitație la a III-a ediție a conferinței Gemini Solutions Foundry Ovidiu Măţan

9 Cu Smilestone la Imagine Cup 2014 Dan Suciu

12 Interviu cu Chris Heilmann de la Mozilla Ovidiu Măţan

14 Visul împlinit al unei școli de vară - Fortech hiSchool Training Program Sorina Mone

16 How to Web 2014: un nou început

25 Livrarea continuă Dan Danciu

29 Detectarea fraudelor cu Titan Florin Măguran

31 Pragmatism în programare Mihnea Lazăr

34 Clean code – Funcții Radu Vunvulea

36 Integrarea client server cu ajutorul RestKit Mihai Fischer

38 Cum poți testa conferințe de testare

Irina Scarlat

Alexandra Casapu

17 Invitaţie la TYPO3 East Europe 2014

41 Tranziția de la QA la BA

Daniel Homorodean

19 JavaFX în Platforma Java Standard 8 Silviu Dumitrescu și Diana Bălan

22 Avantajele folosirii SVG (Scalable Vector Graphics) Peter Krejcik

Monica Petraru

42 Time Dude, un joc 3D cross mobile platform Liviu Boar

44 Cum “bateți palma” pe un contract Claudia Jelea

46 Gogu în șoc... cultural Simona Bonghez, Ph.D.

editorial

Ovidiu Măţan

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

ncepem luna septembrie cu lansarea oficială a evenimentului anual organizat de revista Today Software Magazine. Este vorba bineînțeles de IT Days 2014, www.itdays.ro, 25-26 noiembrie, Cluj-Napoca, care vă propune o întâlnire cu profesioniștii locali, colaboratorii TSM precum și o serie de invitați speciali din țară și străinătate. Tema generală va fi Cum să construim un produs? aceasta fiind și titlul cărții ce va fi lansată în cadrul evenimentului și distribuită tuturor participanților. Autorii cărții vor fi cei care prezintă în cadrul evenimentului, dând astfel ocazia participanților să citească mai multe detalii despre subiectele preferate. Vă invit să participați la acest eveniment, mai multe informații fiind disponibile în articolul dedicat special IT Days din acest număr. Un alt eveniment important din această lună va fi lansarea din Târgu Mureș, programată să aibă loc în 24 Septembrie. Această lansare este organizată împreună cu cei de la Cluj IT Cluster și găzduită de msg systems. O parte dintre speakeri vor fi locali și din Cluj. Invitat special va fi prof. Horvath de la EIT ICT Lab Budapesta. Asemenea evenimentului de lansare desfășurat la Brașov, cel din Târgu Mureș se dorește a fi expresia dorinței de a promova mai mult oportunitățile românești în cadrul comunității IT din Transilvania. Revenind la revistă, am publicat recent un preview al noului look & feel al revistei. Mulțumim cu această ocazie echipei Subsign, www.subsign.co, pentru designul noului TSM, ale cărei profesionalism și inovație îi recomandă pentru tot ce înseamnă proiectele de web design . Este o echipă tânără din Iași pe care am cunoscut-o cu ocazia evenimentului de lansare de aici. Ne-au surprins de altfel implicarea lor, dorința de a ajuta și de a face lucruri noi. Facem acum o trecere în revistă a articolelor din acest număr. Începem cu evenimentele speciale: IT Days 2014 și Gemini Solutions Foundry la care vă invităm să participați. Tot în această arie se integrează și articolul ce urmărește parcursul echipei Smilestone coordonată de Dan Suciu la competiția Microsoft Imagine Cup din 2014. Ne face plăcere să anunțăm și ediția din acest an a How To Web, cel mai mare eveniment de antreprenoriat și leadership din IT din românia. Articolele tehnice pe care vi le propunem sunt JavaFX în Platforma Java Standard 8 - prezintă evoluția și folosirea JavaFX, Avantajele folosirii SVG (Scalable Vector Graphics), Cum să detectăm tentativele de fraudă folosind Titan, Integrarea client server cu ajutorul RestKit, Clean Code – Functions o continuare a seriei de articole despre cum să scriem un cod curat. Pragmatism în programare pornește de la analogia cu geamurile sparte aplicată menținerii codului existent. Experiență de a vorbi în cadrul unor mari evenimente de testare și o încurajare și pentru alții de a face la fel a fost detaliată în Ce poți învăța din vorbitul în public - experiențele unui tester. De altfel, experiența de tester te poate ajuta să te muți într-un domeniu nou: Tranziția de la QA la BA. De asemenea, pentru acest domeniu, vă recomandăm Primul pas în analiza de business. Încheiem prezentarea conținutului tematic cu menționarea unui nou articol dedicat lui Gogu care semnalează importanța diferențelor culturale în managementul proiectelor. Vă dorim o lectură plăcută !!!

Ovidiu Măţan

Fondator al Today Software Magazine

nr. 27/2014 | www.todaysoftmag.ro

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

Lista autorilor Dan Suciu

dan.suciu@3pillarglobal.com Director of Technical Training @ 3Pillar Global

Daniel Homorodean

daniel.homorodean@arxia.com CEO @ Arxia

Florin Măguran

Irina Scarlat

Senior Java Developer @ Betfair

PR Manager @ How to Web & TechHub Bucharest

Dan Danciu

Mihnea Lazăr

Software Architect @ ISDC

Java Developer @ msg systems

Peter Krejcik

Sorina Mone

florin.maguran@betfair.com

dan.danciu@isdc.eu

irina.scarlat@howtoweb.co

mihnea.lazar@msg-systems.com

Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com Contabil : Delia Coman delia.coman@todaysoftmag.com Produs de

Today Software Solutions SRL str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag ISSN 2284 – 6352

peter.krejcik@yardi.com Web Designer @ Yardi România

simona.bonghez@confucius.ro Speaker, trainer şi consultant în managementul proiectelor, Owner al Colors in Projects

Mihai Fischer

mihai.fischer@gmail.com iOS developer @ Dens.io

Claudia Jelea

Silviu Dumitrescu

Avocat & Consilier in domeniul marcilor @ Jlaw

Consultant Java @ msg systems Romania

claudia.jelea@jlaw.ro

silviu.dumitrescu@msg-systems.com

Alexandra Casapu

Liviu Boar

Software Tester @ Altom Consulting

2d/3d artist, animator @ REEAnimation

alexandra.casapu@altom.ro

monica.petraru@urss.ro Senior Business Analyst @ UNIQA Raiffeisen Software Service

Reproducerea parțială sau totală a articolelor din revista Today Software Magazine fără acordul redacției este strict interzisă.

Marketing manager @ Fortech

Simona Bonghez, Ph.D.

Monica Petraru

sorina.mone@fortech.ro

liviu.boar@reea.net

Diana Bălan

Diana.Balan@accesa.eu Java developer @ Accesa

Ovidiu Măţan

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

www.todaysoftmag.ro www.todaysoftmag.com

www.todaysoftmag.ro | nr. 27/septembrie, 2014

eveniment

Today Software Magazine vă invită în 25-26 noiembrie la a doua ediție a Cluj IT Days 2014, www.itdays.ro

venimentul IT days a fost organizat anul trecut de revista Today Software Magazine ca o încercare de a-i reuni pe aproape toți cei care se implică în dezvoltarea comunității IT locale. Fiecare dintre aceștia sunt animați, dincolo de specificul domeniului în care activează, de interese fundamentale asemănătoare, respectiv eficiență maximă și susținerea comunității IT locale. Conturarea unor principii de bază care să devină repere în dezvoltarea IT-ului local, a fost unul dintre principalele obiective pe care le-a țintit evenimentul. Anul acesta, ne propunem să realizăm încă o ediție a IT Days, impulsionată de același obiectiv al coagulării unor direcții de dezvoltare. Evenimentul care se va desfășura în 25-26 noiembrie va oferi ocazia de a-i întâlni invitați speciali precum și pe cei mai buni specialiști care au publicat de-a lungul anului în revista noastră. Un fapt inedit este proiectul editării cărții Cum să construiești un produs, în care toți cei care vor susține o prezentare în cadrul evenimentul vor avea ocazia să scrie un capitol. Aceasta va fi inclusă în prețul biletului conferinței IT Days 2014, participanții având ocazia să citească mai multe detalii despre domeniile de interes.

este despre cum să construim un produs. Așadar, această carte completează activitatea evenimentului, pentru că se adresează programatorilor, startup-urilor dar și companiilor, propunându-și să aibă rolul unui ghid al creării de produse. Înainte de a prezenta o parte dintre cei ce vor prezenta la IT Days 2014, vom face o recapitulare a IT Days 2013. Evenimentul a fost o ocazie de a-i reuni pe aproape toți cei care se implică în dezvoltarea comunității IT din Cluj: reprezentanți ai businessului local, startup-uri locale, incubatoare de startup-uri, Cluj IT Cluster , cercetători de la Universitatea Tehnică și de la Institutul de Știință și Tehnologie și autoritățile locale prin prezența primarului Emil Boc. Alți doi invitați speciali din Europa : Tine Thygesen, CEO Everplaces și Eduardo Mendez Polo, head of IT Cloud, Telefonica Spain. Ediția 2014 a IT Days, va aduce un specialist Java de top în Cluj. Este vorba de Peter Lawery, deținător al platformei Vanila Java 1, având rangul trei pentru Java și doi pentru concurență în rețeaua StackExchange din care face parte și StackOverflow2.

Iulian Iuga

Accesa, care ne va vorbi despre rețeta sa de succes în ceea ce privește compania pe care o conduce precum și despre viziunea sa asupra evoluției pieței de IT românești.

Dan Ionescu

Dan Ionescu, un cunoscut colaborator al revistei din perspectiva studiilor de HR realizate asupra comunității de IT clujene va avea ca subiect al prezentării, perspective asupra Leadership-ului românesc.

Cartea de altfel se va remarca prin diversitatea subiectelor, având capitole Peter Lawrey Silviu Dumitrescu de la startups, leadership, management, proiecte de cercetare, trenduri și până la subiecte tehnice de programare sau testare. În secțiunea de Trends & Leadership Silviu Dumitrescu, un colaborator conDincolo de această varietate, se impune îl avem ca invitat pe Iulian Iuga, CEO secvent al revistei ne va vorbi despre Java 8. totuși o tematică principală, subordonată 1 vanillajava.blogspot.ro Pe Silvia Răusanu am invitat-o la evede altfel înseși temei evenimentului care 2 stackexchange.com/users/23121/peter-lawrey niment în special pentru viziunea tehnică

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE accelerate creșteri pe piața din România.

Silvia Răusanu Sebastian Big

asupra Big Data și pasiunii ei pentru algoritmică și inteligență artificială.

Sebastian Big este interaction designer, dar de formaţie filozofică şi cu traduceri din Virilio, Baudrillard, Derrida & Stiegler şi un doctorat în Comunicare terminat prematur. El îşi valorifică talentul pe piaţa românească de IT, încercând să pună în valoare metodele sale de clarviziune într-un sistem deocamdată cantonat în factualitatea imediată.

Avansate în Telecomunicații și Doctor în Inginerie Electronică și Telecomunicații de la Universitatea Tehnică din ClujNapoca în 1995, 1996, respectiv în 2002. Din 1996 este angajat la Departamentul de Comunicații al Universității Tehnice din Cluj-Napoca, unde în prezent este conferențiar. Domeniile de cercetare de interes implică tehnici de codare a canalului, tehnici de codare a rețelelor de date, rețele radio, tehnici de comunicații prin cooperare, arhitecturi avansate de rețele de comunicații. El a făcut parte din grupurile de cercetare ale programelor COST 289 și COST 2100, a fost membru al echipelor de cercetare ale proiectelor FP7 4WARD și FP7 CODIV și a fost coordonator local al proiectului FP7 UCONNECT.

Sergiu Damian

Sergiu Damian este un arhitect software experimentat, cu o profundă înțelegere a design-ului software, practicilor și proceselor de dezvoltare și, nu în ultimul rând, al dinamicii umane din echipe. După treisprezece ani petrecuți în diverse roluri în companii locale de outsourcing a ales să Dr. ing Bogdan Rus devină un arhitect software independent, ajutând diverși clienți în a-și atinge obiecDr.ing. Bogdan Rus este șef lucrări tivele. Activează în diverse comunități IT, (lector) în cadrul Universității Tehnice din oferă asistență studenților și îi învață pe Cluj-Napoca, Facultatea de Electronică, alții despre software architecture. Telecomunicații și Tehnologia Informației. Devenind din anul 2008 membru al colectivului UC Labs (Unified Communications Laboratories) din cadrul aceleiași facultăți, Bogdan Rus a participat în proiecte de cercetare internaționale ce aveau ca temă principale tehnici de comunicații în Internetul viitorului. Rezultatul întregii activități de cercetare a fost validat în diverse articole publicate la conferințe Andreea Pârvu internaționale și reviste de specialitate. Andreea Pârvu este absolventă a mas- Adițional activităților de cercetare, Andrei teratului de Psihologia Resurselor Umane. Bogdan Rus este implicat și în activități Activitatea ei profesională a debutat în cali- didactice cu studenții înscriși la cursurile tate de HR Generalist la o companie de de licență și masterat. logistică - aici descoperind și dezvoltând o pasiune pentru aria de Resurse Umane. Experiența internațională ca membru al echipei globale de Talent Management din cadrul unei companii de telecomunicații, a contribuit la dobândirea și îmbunătățirea cunoștințelor în acest domeniu. În plus, acest context a avut un impact pozitiv în momentul în care a decis să încerce Zsolt Alfréd Polgár domeniul IT, ca freelancer. Însă, din 2012, Andreea este Senior Recruiter la Zsolt Alfré d Polgár a obț inut Endava - Cluj, una dintre companiile de diploma de Inginer cu specializarea IT recunoscută ca având una din cele mai Telecomunicații, Master în Tehnici

Simona Bonghez

Simona Bonghez colaborează cu revista TSM prin cunoscuta și amuzantă rubrică dedicată lui Gogu. Dar Simona Bonghez este cunoscută mediului IT românesc în special pentru training-urile de project management, pregătirile pentru certificările PMI, remarcându-se pe plan național drept o profesionistă în tot ce înseamnă managementul proiectelor. Cu o bogată experiență de speaker la conferințele PMI internaționale, Simona ne face plăcerea de a participa la a doua ediție a IT Days 2014 în această calitate.

Am prezentat doar o parte a conferinței IT Days 2014, mai multe detalii puteți găsi pe www.itdays.ro. Vă pregătim multe surprize, inclusiv un workshop de Java Performance și unul de Management.

Ovidiu Măţan

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

www.todaysoftmag.ro | nr. 27/septembrie, 2014

eveniment

Invitație la a III-a ediție a conferinței Gemini Solutions Foundry

rupul de firme Gemini Solutions împreună cu Gemini Foundry Inc, organizează în data de 23 Septembrie 2014, la București, a treia ediție a Conferințelor Foundry, avându-l ca invitat special pe Romain Lavault, partener Partech Ventures. Această ediție a evenimentului aduce un nou investitor important în București pentru startup-urile românești după ce în edițiile anterioare am avut ocazia să îi vedem pe Nicolas El Baze, partener Partech Ventures și pe Romain Niccoli, co-fondator și CTO Criteo, una dintre cele mai importante startup-uri europene. Pentru cei interesați, accesul se face anual având valoarea medie de 500,000 Ceea ce căutăm sunt startup-uri care pot pe bază de invitație, iar pentru obținerea dolari1. Antreprenorii prezenți la eveni- fi scalabile la nivel global, care favorizează acesteia vă invit să accesați site-ul Gemini ment vor avea, de asemenea, posibilitatea schimbarea și revoluția pieței. Noi le vom Solutions Foundry www.gemsfoundry. de a-și prezenta ideile de business, într-o ajuta să se pregătească pentru investiții și să com. Locul de desfășurare este etajul 34 al sesiune interactivă de pitching. Astfel, în a își dezvolte infrastructura care le va permite Sky Tower, în București, în data de 23 sep- doua parte a conferinței, vor fi expuse cele să se reintegreze în Silicon Valley, în timp ce tembrie de la ora 16:30. mai interesante proiecte ale participanților își păstrează echipele tehnice în România. înscriși. Suntem interesați în mod special de domenii precum cel al mobilelor, Internetul obiectelor, big data, domeniul social, comerț electronic, plăți și multe altele. Aștept cu interes să demonstrăm acest model și să ajutăm antreprenorii români să obțină succes la scară mondială.

Gemini Foundry Inc, incubator destinat startup-urilor din Romania Pentru a veni în sprijinul antreprenorilor din mediul IT din România, Gemini Foundry Inc, un incubator destinat exclusiv startup-urilor IT din România, organizează o serie de conferințe ai căror invitați speciali sunt antreprenori și investitori străini, ce activează în companii puternice și competitive la nivel internațional. Theo Nissim Romain Lavault

Romain Lavault, invitatul special al conferinței, este general partner și head of seed/early stage fund la Partech în Paris. Partech Ventures este una dintre cele mai puternice companii de investiții de pe piețele din Statele Unite și Europa. Fondată în 1982, Partech are acum birouri în San Francisco, Paris și Berlin, dispunând de fonduri de peste 650 milioane $ destinate ideilor de afaceri din domeniul IT. De-a lungul anilor, compania a sprijinit zeci de inițiative business, devenite adevărate povești de succes. Conform ultimului articol TechCrunch despre Partech, ultimul fond de investiții creat, Partech VI, conține un fond ventures de 175 milioane de dolari și 40 milioane de dolari alocate pentru un fond seed. Se așteaptă așadar în următorii ani să se realizeze 8-12 investiții de tip seed

Theo Nissim, CEO-ul grupului de firme Gemini Solutions ne-a transmis viziunea sa despre această inițiativă: Am început Gemini Foundry pentru a crea o punte de legătură între tinerii antreprenori români și Silicon Valley, investitorii, mentorii și consilierii săi pentru multe domenii de activitate – juridic, finanțe, marketing, etc. . Grupul Gemini are un ecosistem extins care include lideri experți, îndrumători în aceste domenii. Viziunea noastră este aceea că putem revoluționa piața și reuși să obținem succes prin îndrumarea și accelerarea startup-urilor românești și punerea lor în legătură cu parteneri de afaceri adecvați și membrii ai ecosistemului nostru. 1 t e c h c r u n c h . c o m / 2 0 1 3 / 1 0 / 0 9 / partech-venture-and-seed/

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

Mai mult, Gemini Foundry oferă gratuit echipelor acceptate în programul de incubare spațiu de birouri la cheie, ajutor în managementul afacerii, mentorship tehnic, consultanță financiară și legală, dar și conexiuni cu fonduri de investiții din Silicon Valley. Aceste conexiuni se fac în mod personalizat pentru echipele ce vor prezenta atât ideea lor cât și progresul efectuat în cadrul programului de incubare. Ovidiu Măţan

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

concurs

Cu Smilestone la Imagine Cup 2014

magine Cup este o competiţie anuală IT care se adresează studenţilor și elevilor din întreaga lume. Competiţia este organizată de Microsoft şi are ca scop dezvoltarea de soluţii software care să vizeze cele mai importante probleme ale omenirii şi care au şanse reale de a deveni produse soft comerciale.

Dan Suciu

dan.suciu@3pillarglobal.com Director of Technical Training @ 3Pillar Global

Putem spune fără a greşi că Imagine Cup este cea mai importantă competiţie de acest gen, luând în considerare numărul de ţări şi echipe participante, calitatea soluţiilor dezvoltate şi, nu în ultimul rând, premiile puse în joc. Evoluţia competiţiei este de asemenea interesantă: dacă la prima ediţie, în 2003 au fost înscrişi în total 1000 de competitori din 25 de ţări, anul acesta s-a înregistrat un record de participare cu 358.000 de studenţi înregistraţi reprezentând 190 de ţări sau regiuni. Numărul total de studenţi înscrişi din 2003 fiind de 1.75 milioane!.

Descriere generală

De-a lungul a doisprezece ani de zile, Imagine Cup s-a derulat pe mai multe secţiuni şi a cunoscut diverse formate. În ultimele două ediţii fiecare dintre echipele participante au putut veni cu soluţii în una dintre următoarele categorii: Innovation, World Citizenship şi Games. Premiile puse în joc în acest an, pentru fiecare dintre cele trei categorii, au fost consistente: • Locul 1: 50.000 $ • Locul 2: 10.000 $ • Locul 3: 5.000 $ În plus, câştigătoarele locurilor întâi pentru fiecare dintre categorii urmau să participe la o rundă finală în urma căreia se lua decizia cine va intra în posesia cupei, bonusul fiind o sesiune de mentoring privată cu Bill Gates. Pe lângă cele trei categorii menţionate mai sus au mai fost şi alte întreceri la care echipele se puteau înscrie, însă ele sunt de o mai mică importanţă ca impact sau ca valoare a premiilor puse în joc. În 2014 s-a mai putut concura pentru: Apps For Office Challenge, Visual Studio Online Boost, Windows & Windows Phone Challenge, Brain Games 2.0, Project Blueprint Challenge. În primii unsprezece ani competiţia

Imagine Cup a fost organizată în diferite oraşe răspândite pe întregul glob: Barcelona (2003), São Paulo (2004), Yokohama (2005), Delhi (2006), Seoul (2007), Paris (2008), Cairo (2009), Varşovia (2010), New York (2011), Sidney (2012) şi St. Petersburg (2013). Din acest an Imagine Cup s-a “întors acasă” la Seattle, Washington, acolo unde se afla şi sediul central al Microsoft, oraş care va continua să fie gazda competiţiei şi în următorii ani. Spre deosebire de o bună parte din ediţiile anterioare, în acest an nu a fost anunţată o temă generică la care să se ralieze soluţiile prezentate. Practic, oricine avea o idee ce considera că merită să fie dezvoltată şi transformată într-un produs cu succes şi impact pe piaţa globală putea să se înscrie la secţiunea care i se părea cea mai potrivită. Evident, având în vedere că Imagine Cup este organizat de Microsoft, exista cerinţa minimă ca soluţiile să fie dezvoltate folosind tehnologii Microsoft (însă nu exclusiv). În funcţie de popularitatea competiţiei, în fiecare ţară, se puteau organiza faze locale sau naţionale, având drept scop identificarea unei echipe care să reprezinte ţara respectivă la următorul nivel pe fiecare dintre secţiunile Innovation, World Citizenship şi Games. Următorul nivel era o fază regională unde era selectat un număr fix de soluţii ce urmau să ajungă în finala mondială de la Seattle. Chiar dacă anumite element de organizare şi structură se modifică de la an la an, acestea nu suferă modificări într-un mod fundamental. Vă oferim câteva informații generale: • Un nou sezon Imagine Cup începe de obicei în septembrie/octombrie (la început de an şcolar şi universitar) când fiecare dintre cei care doresc să participe încep să formeze echipe şi să intre în sesiuni de brainstorming pentru a selecta ideea centrală a viitoarei soluţii. Cu echipa formată

www.todaysoftmag.ro | nr. 27/septembrie, 2014

concurs Cu Smilestone la Imagine Cup 2014 şi soluţia cât de cât schiţată, ei se pot înscrie pe site-ul www.ImagineCup.com • Anumite universităţi pot organiza competiţii interne, locale, atunci când din instituţiile respective se înscriu mai multe echipe în competiţie. În trecut atât Universitatea Babeş-Bolyai cât şi Universitatea Tehnică au organizat astfel de sesiuni, echipele situate pe primele 2-3 locuri urmând a se califica la faza naţională. În 2014 acest lucru nu s-a repetat şi s-a început direct cu o fază online, de selecţie a soluţiilor ce urmau să participe la faza naţională (câte trei soluţii pentru fiecare secţiune). Pentru fiecare soluţie echipele participante trebuiau să trimită o documentaţie şi orice materiale (filme, kituri de instalare etc.) care să ajute la o mai bună evaluare (pentru acestă fază soluţia putea fi doar parţial implementată) . • La faza naţională (desfăşurată în acest an în incinta Politehnicii Bucureşti) fiecare dintre echipele calificate au avut ocazia să-şi descrie live soluţia, să facă un demo (10 minute) şi să răspundă la întrebările juriului (în alte 10 minute). • Faza regională a fost din nou una online, materialele menţionate mai sus fiind actualizate şi trimise juriului regional. România intră în regiunea Europa Central şi de Est împreună cu alte peste 20 de ţări. În urma selecţiei, 6 soluţii au fost selectate pentru a merge mai departe la Seattle. • La faza mondială au avut loc timp de două zile două sesiuni de jurizare (una de prezentare, de 10 minute și una hands-on în care fiecare membru al juriului putea petrece 15 minute cu soluţia şi putea să pună întrebări de detaliu) la care s-au prezentat câte 10 echipe la secţiunile Innovation si Games și 14 echipe la secţiunea World Citizenship.

Criteriile de jurizare în acest an au fost următoarele:

• Concept (15%) – problemă/nevoie clar definite, soluţie concis explicată, clienţi potenţiali precis delimitaţi. • Innovation (50%) – inovaţia e privită din mai multe perspective: felul în care a fost rezolvată problema, modul de interfaţă cu utilizatorii, rezolvarea unei probleme fără soluţie în prezent etc. • Execution (20%) – calitatea aplicaţiei software din punct de vedere a interfeţei, vitezei de execuţiei, securităţii etc. • Feasibility (15%) – gradul de credibilitate cu privire la potenţialul de succes al aplicaţiei.

Standul SMT la Museum of History and Industry (MOHAI), Seattle

Participarea României

România a avut de-a lungul timpului o prezenţă la Imagine Cup presărată cu numeroase premii la diverse secţiuni în special la IT Challenge, Embedded Development şi Digital Media, culminând cu câştigarea cupei în anul 2009 de către echipa Sytech din Iaşi. Clujul a fost prezent cu soluţii interesante în special în secţiunea Software Design (considerată până acum doi ani cea mai importantă secţiune, cea a cărui câştigător primea şi cupa imaginaţiei). Una dintre membra echipei participante în 2010 şi 2011, Simplex, a acordat un interviu revistei Today Software Magazine despre soluţia lor prin Mira. O altă echipă din Cluj a reprezentat România şi la finala de la Seattle din acest an. Echipa se numeşte Smile Technology (SMT) şi este formată din trei studenţi ai secţiei Informatică Engleză a Facultăţii de Matematică şi Informatică a Universităţii Babeş-Bolyai: Bogdan Mursa, Rareş Urdea şi Bogdan Pop (în ordine în care apar în imaginea de mai jos) echipă pe care am avut plăcerea să o coordonez. Soluţia propusă de ei, Smilestone, este o aplicaţie ce implementează cu ajutorul unui dispozitiv Kinect o serie de exerciţii utile în procesul de recuperare a limbajului pentru persoanele ce au pierdut capacitatea de a vorbi în urma unui atac cerebral. Ideea soluţiei a venit în urmă cu aproape trei ani când am luat pentru prima dată legătura cu doamna doctor psiholog Ştefania Budacu. Aceasta colabora la vremea respectivă cu spitalul Floreasca şi a auzit de proiectul Mira de la televizor. Proiectul Mira era tot o soluţie de

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

recuperare fizică dar orientată pe membrele superioare şi inferioare. Doamna doctor ne-a explicat atunci că primul pas de recuperare ce trebuie făcut în cazul persoanelor care au suferit o paralizie în urma unui accident vascular cerebral era cel de recuperare a capacităţii de comunicare (termenul menţionat de dânsa atunci a fost demutizare). Pentru acestă etapă însă nu exista nici o soluţie software care să fie non-invazivă. O astfel de soluţie ar fi permis unui pacient să continue exerciţiile de recuperare şi în afara şedinţelor cu medicul, şi astfel să fie scurtată perioada de refacere, care în general este lungă şi anevoioasă. În acest domeniul părerile sunt împărţite: unii medici susţin că rezultatele activităţii de recuperare se văd în fazele timpurii după ce a avul loc atacul cerebral, şi cu cât trece mai mult timp, probabilitatea ca pacientul să reuşească să revină la modul în care comunica sau se mişca înainte de accident scade simţitor. Pe de altă parte există medici care insistă pe faptul că efecte ale recuperării pot să apară brusc şi după 10 ani de zile. Nu dorim să intrăm în detalii de natură medicală şi terapeutică însă merită menţionat faptul că, indiferent de opinii, toţi sunt de acord că timpul petrecut în activităţi de recuperare are o influenţă determinantă în revenirea abilităţilor iniţiale într-un procent ridicat. În acest moment un terapeut petrece în jur de o oră cu un pacient. Existenţa unui software dedicat acestei recuperări ar putea face ca timpul petrecut de pacient în exerciţii de recuperare să crească la trei ore. Un timp de recuperare de trei ori mai mare nu poate face decât să sporească şansele de

TODAY SOFTWARE MAGAZINE reuşită. În plus, Smilestone memorează seturi de date care pot fi extrem de utile unui terapeut pentru a evalua starea curentă, progresul înregistrat şi elementele pe care trebuie insistat în continuare. Microsoft Kinect este un dispozitiv fără de care încercarea de a construi un sistem de recuperare non-invaziv ar fi fost imposibilă. Fiind construit în primul rând ca o interfaţă naturală pentru diferite jocuri, acesta poate detecta părţi ale corpului şi poate determina mişcarea acestor părţi în timp real. Smilestone avea nevoie în special de detectarea mişcărilor muşchilor feţei. Unele dintre funcţionalităţile necesare, cum ar fi detectarea mişcării gurii şi a buzelor, era deja implementată în SDK. Din păcate însă interpretarea acestor mişcări era viciată de faptul că de fiecare dată datele veneau simetrice pe baza unei medii făcute între cele două jumătăţi. O altă provocare a constat în posibilitatea detectării mişcărilor limbii atunci când aceasta era scoasă în afara gurii. Nefiind nimic implementat în acest sens, cei din echipa Smile Technology au implementat un algoritm de la zero care, rafinat în mai multe etape, s-a dovedit a avea o acuratețe foarte bună. Acurateţea de detectare a limbii a fost atât de bună încât unul dintre membrii juriului a sugerat o deviere radicală de la subiectul tratat de Smilestone la dezvoltarea unei interfeţe non-invazivă om-calculator care să permită persoanelor complet paralizate să utilizeze calculatorul folosindu-se exclusiv de mişcările limbii.

La festivitatea de decernare a premiilor

În loc de concluzii...

că procesul de testare va fi unul compliÎn foarte puţine cuvinte, aceasta a cat. Sperăm însă ca şi rezultatele să fie pe fost soluţia propusă de România în acest măsura efortului. an la finala mondială Imagine Cup de la Seattle. Chiar dacă nu a fost unul dintre proiectele premiate, considerăm că are un imens potenţial. Ceea ce s-a realizat până acum este doar un prim pas: am reuşit să construim algoritmi de detectare a principalilor muşchi ai feţei implicaţi în activitatea de recuperare a limbajului. Urmează implementarea unor exerciţii specifice şi găsirea de parteneri ce vor dori să se implice în etapa de testare clinică a sistemului. Spre deosebire de alte exerciţii de recuperare, recuperarea limbajului este complicată şi delicată, de aceea anticipăm

Our core competencies include:

Product Strategy

Product Development

Product Support

3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world. Our oﬀerings are business focused, they drive real, tangible value.

www.3pillarglobal.com

www.todaysoftmag.ro | nr. 27/septembrie, 2014

interviu

Interviu cu Chris Heilmann de la Mozilla

m avut plăcerea de a realiza un interviu cu Chris Heilmann, Principal Developer Evanghelist la Mozilla Developer Network, Londra. Chris va fi unul dintre principalii speakeri la IMWorld 2014, www.imworld, 8-9 octombrie, București. Le poți spune cititorilor noștri câteva cuvinte despre Mozilla Corporation?

Mozilla este o organizație non-profit pentru păstrarea web-ului deschis și gratuit. Aceasta nu înseamnă numai că noi construim un browser și un OS mobil, dar punem suflet ca să apărăm interesul utilizatorului. Webul este pentru toată lumea,

oriunde și scopul lui este să facă lumea mai mică și un loc mai bun pentru a comunica unii cu alții fără griji legate de siguranță sau confidențialitate. De aceea creăm servicii și produse și educăm oamenii despre ce înseamnă să intri online și cum să facă trecerea de la stadiul de consumator la cel de producător. Noi suntem aici pentru a vă ajuta să intrați online fără a trebui să subscrieți la un singur ecosistem închis sau să împărtășiți informații personale în schimbul posibilității de a vorbi cu familia voastră. Firefox OS este ceva despre care nu auzim toată ziua, de fapt, România nici nu se află pe lista locațiilor disponibile. Putem utiliza dispozitivele noastre existente pentru a porni Firefox OS? Cât de ușor pot dezvoltatorii să scrie cod pentru el, căci, după cum știm, este bazat pe HTML5? Scrierea aplicațiilor în HTML5 înseamnă că puteți deja susține Firefox OS (și toate celelalte platforme). Ceea ce face Firefox OS este să vă ofere acces deplin la hardware-ul unui telefon și astfel să faciliteze realizarea unor produse foarte captivante. Gândiți-vă la el drept platforma care îndeplinește promisiunile pe care alte platforme ni le-au făcut atunci când HTML5 a fost prima dată definit. Poți începe să dezvolți o aplicație Firefox OS chiar în browser-ul Firefox – acum se transferă cu App Manager / Web IDE direct în instrumentele dezvoltatorului. De acolo poți porni un dispozitiv simulat pe computerul tău, care servește scopului tău în proporție de 90%. Dacă dezvoltatorii doresc să aibă un dispozitiv pe care să testeze aplicațiile lor, există dispozitivul dedicat dezvoltatorilor – telefonul de referință al dezvoltatorului, Flame1. Acesta se livrează în întreaga lume pentru 170$, incluzând taxele poștale și ambalajul. Este un dispozitiv de nivel mediu care îți permite să simulezi diferite specificații ale telefonului direct pe el. Există o serie video care îți explică cum să faci asta. 1 bit.ly/flamedevice

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Dacă mâine va trebui să creezi ceva pentru promovarea unei comunități culturale locale, ce framework-uri și ce platformă ai folosi? Aceasta depinde foarte mult de comunitate. În Statele Unite, de exemplu, aș utiliza un set de instrumente cu care oamenii sunt obișnuiți. În Mozilla, am adunat instrumente variate2 care să ne ajute. Într-o țară care începe să iasă în evidență, unde conectivitatea reprezintă o problemă mai mare sau comunitatea nu este obișnuită cu realizarea zilnică de aplicații pentru a-și câștiga existența, aș începe pur și simplu prin redarea webIDE-ului încorporat în browser sau chiar aș utiliza producătorul de aplicații3 care permite oricui să își dezvolte primele aplicații fără a fi nevoit să aibă vreun fel de cunoștințe legate de tehnologiile de la bază. Cum vezi evoluția aplicațiilor web mobile versus cele native? Aș paria că aplicațiile web se vor înmulți din ce în ce mai mult în următoarele luni. Studii precum raportul pentru aplicații mobile comscore4 indică faptul că adoptarea aplicațiilor per ansamblu este în declin, iar oamenii le folosesc pe acelea care îi ajută să facă ceva cu webul. Aceasta înseamnă că interfețele de înaltă fidelitate ale aplicațiilor native nu sunt motivul principal pentru care oamenii utilizează o aplicație. Iar aplicațiile web se pot mișca mai rapid și se adaptează mai bine la elemente din hardware care își modifică forma. Editorii de conținut deja se îndepărtează de aplicațiile native, după cum am văzut exemplul The Verge5. Cum poate cineva să se alăture organizației Mozilla drept voluntar și care sunt avantajele principale? Puteți accesa ceea ce vă interesează6 și ați pornit în cursă. Principalul avantaj îl constituie oamenii lângă care veți lucra. Veți întâlni oameni din întreaga lume, veți auzi povești despre cum lucrul la ceva atât de simplu prec um do c ument aț i a sau raportarea unui bug a schimbat viețile oamenilor și le-a dat șansa de a fi angajați de către companii în țările și mediile lor. Și veți vorbi cu experți tehnici și mentori care vă vor ajuta să vă îmbunătățiți abilitățile. Eu sunt unul dintre ei și îmi petrec mu lt t imp ajut ând voluntarii să comunice Chris Heilmann și să se auto-recomande în fața lumii și a oamenilor care până în prezent nu prea i-au luat în serios. Noi toți avem o poveste de spus, iar acestea sunt împărtășite cel mai bine.

el și-a dezvoltat primul web site de la zero în 1997 și și-a petrecut următorii ani lucrând la multe web site-uri mari, internaționale. Apoi și-a petrecut câțiva ani la Yahoo, dezvoltând produse, explicând și instruind oameni, iar acum este la Mozilla. Chris a scris și a contribuit la șase cărți despre dezvoltarea web și a scris multe articole și sute de postări pe blog pentru Ajaxian, Smashing Magazine, Yahoo, Mozilla, Script Junkie și multe altele.

Despre Christian Heilmann

Christian Heilmann și-a dedicat o mare parte din timp pentru a face web-ul mai bun. Provenind din mediul jurnalismului radio, 2 mozilla.github.io/recroom/ 3 appmaker.mozillalabs.com/ 4 w w w . c o m s c o r e . c o m / I n s i g h t s / P r e s s - R e l e a s e s / 2 0 1 4 / 8 / comScore-s-US-Mobile-App-Report-Available-for-Download 5 www.theverge.com/2014/9/2/6096609/welcome-to-verge-2-0

Ovidiu Măţan

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

6 www.mozilla.org/en-US/contribute

www.todaysoftmag.ro | nr. 27/septembrie, 2014

educație

Visul împlinit al unei școli de vară - Fortech hiSchool Training Program

rganizarea unor cursuri practice pentru elevi a fost unul dintre primele repere ale viziunii pentru Fortech cu care am făcut cunoștință la venirea în companie. A rămas pe agenda firmei în anii ce au urmat, până când momentul și condițiile au fost oportune. Mutarea la noul sediu ne-a deschis perspective frumoase pentru astfel de inițiative

Sorina Mone

sorina.mone@fortech.ro Marketing manager @ Fortech

nr. 27/2014 | www.todaysoftmag.ro

ce necesită o logistică aparte, oameni uneia dintre cele mai importante decizii dedicați și parteneri cu deschidere. de viață. În continuare vom reda jurnalul a 13 Astfel că prin eforturile echipei noas- zile petrecute împreună cu elevii noștri. tre de HR, ale unui grup de profesori din cadrul liceului teoretic “Avram Iancu” și Ziua 1 - Cariere în IT ale unor oameni pasionați din Fortech, Ne cunoaștem ... actual și viitor analist a fost pus pe roate programul hiSchool de business, manager de proiect, proTraining. gramator, designer. Peste 40 de elevi în Happy Bistro la Fortech, timizi la primul Ce este Fortech hiSchool Training? rendez-vous cu “inginerii”. Am povestit O inițiativă comună a Fortech și a lice- despre ce înseamnă o cariera în IT din ului “Avram Iancu” ce vizează organizarea perspective diferite, care împreună încuunor cursuri practice de tip workshop pen- nunează echipa unui proiect: a analistului tru elevii de liceu care au interes înspre de business, a project managerului, a prozona de IT. Scopul este de a completa gramatorului, a QA-ului, a inginerului de cunoștințele dobândite în școală și de a sistem, a designerului. facilita contactul cu mediul real în care “Pe majoritatea dintre noi, aceste elevii vor activa, într-o etapă în care se discuții ne-au motivat și ne-au îndrumat ia practic decizia de carieră prin alegerea să alegem un drum în IT. Ne-au lărgit orifacultății și pregătirea pentru aceasta. zontul, având ocazia să ne formăm o idee Ne propunem să fim acea organizație despre munca în acest domeniu” spun Alex, care aduce un aport nu doar pentru a aco- Rareș, Beatrice și Adina. peri necesarul de specialiști IT pentru a doua jumătate a anului 2014 sau pentru 2015, ci pe următorii 10-20 de ani. Credem cu tărie în ideea că pentru a pregăti specialiștii de mâine, trebuie investit în copiii și tinerii de azi. De asemenea, credem că pentru a excela într-un domeniu, oricare ar fi acesta, întâlnirea cu acel domeniu trebuie să se producă cât mai devreme. În acest context, contactul cu modele sau repere veritabile este cel mai valoros. Nu avem un Steve Jobs care să Ne-am bucurat nespus când deja la se adreseze unei națiuni spunând că fie- workshop-ul cu nr. 2 a trebuit să suplimencare copil trebuie să învețe să programeze tăm cu încă o sesiune, întrucât numărul de pentru că îl învață cum să gândească (i.e. elevi înscriși depășea numărul maxim de “Code Starts”). Dar avem oameni pasionați 20 pe care ni-l propusesem pentru urmăîn Fortech care și-au luat din timpul lor de toarele întâlniri. Au urmat așadar primele muncă pentru a-l dedica unor tineri la fel întâlniri de lucru: de pasionați, curioși și în curând în pragul

TODAY SOFTWARE MAGAZINE Ziua 2 – Introducere în OOP

specificațiilor cu managerul de produs, au fost mai puțin frecvente în rândul elevilor! Ziua 3 – Programare web Sigur că nu putem trage concluzii definitive, dar ne-am dat seama că o vârstă mai Ziua 4 – MS Office frageda înseamnă mai puține restricții în gândire și comunicare, curajul de a întreba Ziua 5 – Bune practici în programare și lipsa temerilor de a greși. E păcat să nu A fost unul dintre cele mai apreci- fie cultivate. ate workshop-uri, întrucat a valorificat experiența practică a programatorilor din Ziua 8 – Programarea aplicațiilor mobile Fortech. A fost pentru elevii pasionați de (iOS și Android) programare o oportunitate inedită de a vedea ce înseamnă un cod “curat”, ce implică refactoring-ul și reutilizarea codului, metode de analiză a codului. “Am făcut și jocuri și pagini web și am învățat să ne ținem codul curat”, spun Sergiu, Dragos, Lorand și Ionuț.

Ziua 9 – Branding & design grafic

Ziua 6 – Managementul timpului

Proiectul propus de către noi: branduirea ... Internetului. Au rezultat trei concepte inedite : naming, slogan. Elevii au lucrat cu suita de unelte Adobe pentru design și au prezentat și susținut aceste concepte în ceea ce a fost simularea unui pitch.

Ziua 7 – Concepte de Agile

Ziua 10 – Munca în echipă

Ce modalitate mai practică și interactivă de a învăța o metodologie Agile decât printr-un joc? În cadrul acestui workshop am reluat simularea Scrum Lego City pe care am realizat-o la evenimentul ...even mammooths can be Agile, ediția din 2014. A fost interesant să observăm că greșelile cele mai frecvente care apar la această simulare (și care se întâmplă într-un context de proiect Agile), cum ar fi clarificarea

Este o altă abilitate esențială, cultivată printr-un workshop extrem de interactiv și distractiv. Rezultatul muncii în echipă: câte un material video, conceput, regizat și filmat de către elevi înșiși. Ultimele trei workshop-uri au vizat din nou concepte și dezvoltarea de abilități din sfera tehnică:

Ziua 12 – Testarea și asigurarea calității aplicațiilor software Ziua 13 – Baze de date, SQL Retrospectiva – Fortech hiSchool Training, ediția vară 2014, în cifre: • 50 elevi • 15 traineri din Fortech • 4 traineri din cadrul liceului “Avram Iancu” • 13 workshop-uri • 52 ore petrecute de elevi la Fortech. Mulțumirile noastre pentru susținere merg către colectivul de profesori de la liceul “Avram Iancu” implicați în acest proiect, elevii participanți și părinții acestora . “Fiul meu este unul dintre elevii de la “Avram Iancu”, care participă la workshopurile organizate de Fortech. A venit extrem de încântat acasă de ceea ce a văzut și ce li s-a prezentat în primele zile. E un lucru extraordinar ca o firmă să facă ceva pentru copiii ăștia, iar faptul ca Fortech le deschide ochii într-un domeniu atât de dinamic precum IT-ul e de apreciat. Felicitări domnului Văduva, profesorilor de la “Avram” și colaboratorilor!” (sursa: Ziar de Cluj)

Ce urmează?

Povestea de mai sus este povestea unui proiect pilot. Vom repeta programul cu o noua serie de workshop-uri în această toamnă. Așteptăm cu nerăbdare!

Ziua 11 – Unelte de muncă colaborativă

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

www.todaysoftmag.ro | nr. 27/septembrie, 2014

eveniment

How to Web 2014: un nou început

ucurești, 3 septembrie 2014 – A cincea ediţie internaţională a How to Web, cel mai important eveniment dedicat inovaţiei, antreprenoriatului şi tehnologiei din Europa de Sud-Est, va avea loc pe 20 şi 21 noiembrie în Bucureşti. Având un nou format, conferinţa va aduce în faţa unei audienţe estimate de peste 1000 de persoane profesionişti în tehnologie recunoscuţi la nivel internaţional. În plus, cele mai performante 32 de startup-uri din regiune vor concura pentru premiile în valoare totală de 20.000 USD oferite în cadrul celei de a treia ediţii a competiţiei şi programului de mentorat Startup Spotlight. Ediţia din 2014 a How to Web marchează un nou început pentru conferinţă şi propune participanţilor un format mai complex. Astfel, evenimentul va aborda teme precum antreprenoriatul în tehnologie, dezvoltarea de produse cu potenţial disruptiv la nivel global, tendinţe ale industriei, obţinerea de investiţii sau crearea de jocuri şi va adăuga noi elemente adresate unor categorii specifice de audienţă. Pe scenele How to Web 2014 vor urca şi de această dată personalităţi marcante în domeniul tehnologiei la nivel mondial. Printre invitaţii care au confirmat până în prezent participarea la eveniment se numără: Paul Papadimitriou, expert în revoluţia digitală şi efectele sale transformatoare asupra afacerilor, şi invitat special al celor mai importante evenimente în tehnologie din lume; Chris Chabot, Head of International Developer Relations Twitter, care ajută companiile şi dezvoltatorii să redefinească viitorul prin crearea de conexiuni valoroase între oameni şi prin susținerea proceselor inovative, sau Florian Meissner, Co-Fondator şi CEO EyeEm, care este o platformă pentru noua generaţie de fotografi care utilizează dispozitivele mobile, având peste 10 milioane de utilizatori şi care a obţinut până în prezent finanţări de 6 milioane de dolari.

Între 19 şi 22 noiembrie va avea loc şi cea de a treia ediţie a Startup Spotlight, competiţie şi program de mentorat adresat celor mai bune 32 de echipe din regiune. Pe parcursul celor patru zile ale programului, acestea vor participa la workshop-uri şi sesiuni de mentorat, vor cunoaşte investitori şi reprezentanţi ai fondurilor de investiţii early stage şi ai unora dintre cele mai apreciate programe de accelerare din lume, şi vor intra în competiţia pentru premiile în valoare totală de 20.000 USD oferite de IXIA, care este şi în acest an partener principal al programului. Rezultatele ediţiei precedente confirmă calitatea programului şi impactul pe care acesta îl are asupra dezvoltării startup-urilor. 32 de startup-uri early stage provenind din opt ţări din Europa Centrală şi de Est au participat la Startup Spotlight 2013, au beneficiat de workshop-uri dedicate şi sesiuni de mentorat şi au participat la prezentări de acceleratoare şi paneluri cu investitori. În plus, acestea au avut ocazia să se întâlnească în sesiuni 1 la 1 cu reprezentanţi ai unora dintre cele mai apreciate programe de accelerare europene printre care se numără TechStars, Seedcamp, Oxygen şi Wayra (UK), Rockstart (Olanda), Eleven şi LauncHub (Bulgaria), Startup Bootcamp (prezent în mai multe

ţări europene), TechPeaks (Italia), Startup Wise Guys şi Startup Highway (Estonia), sau Hub:raum (Polonia). După finalizarea programului, 35% dintre echipele finaliste au primit o investiţie, au încheiat un nou parteneriat sau au găsit parteneri strategici care să îi susţină în eforturile lor ulterioare. Startup-urile early stage care dezvoltă produse inovative în domeniul tehnologiei pot aplica online pentru participarea la cea de a treia ediţie Startup Spotlight completând formularul de înscriere disponibil online la http:// startupspotlight.co/getready/ How to Web 2014 va avea loc pe 20 şi 21 noiembrie la Crystal Palace Ballrooms şi va aduce împreună peste 1000 de participanţi din Europa Centrală şi de Est şi profesionişti în domeniul tehnologiei recunoscuţi la nivel mondial. Biletele la eveniment vor fi disponibile în curând pe site-ul http://2014.howtoweb.co/ newbeginnings/. În paralel va avea loc şi cea de a treia ediţie Startup Spotlight, competiţie şi program de mentorat pentru startupurile early stage din regiune care dezvoltă produse în domeniul tehnologiei. Între 19 şi 22 noiembrie, cele 32 de echipe finaliste vor participa la un program de dezvoltare accelerată şi vor cunoaşte investitori, reprezentanţi ai programelor de accelerare şi ai fondurilor de investiţii early stage, precum şi mentori cu experienţă. Aplicaţiile pentru Startup Spotlight sunt deschise şi se realizează prin completarea formularului disponibil online la http:// startupspotlight.co/getready/ Irina Scarlat

irina.scarlat@howtoweb.co PR Manager @ How to Web & TechHub Bucharest

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

eveniment

TODAY SOFTWARE MAGAZINE

Invitaţie la TYPO3 East Europe 2014

conţinut.

espre TYPO3, soluţia entreprise CMS open source care a cucerit Germania, am mai vorbit în paginile Today Software Magazine acum un an, cu prilejul pregătirii primei ediţii a conferinţei “TYPO3 East Europe” precum şi în numărul din august al revistei, când colegul meu Tomiţă Militaru a prezentat TYPO3 Neos, noul CMS care promite să revoluţioneze experienţa editării de

TYPO3 este un framework CMS extraordinar, construit nemţeşte pentru a oferi excelenţă funcţională, performanţă şi extensibilitate. Puterea lui se vede în special când ai de implementat portaluri mari, cu flux editorial complex sau soluţii multidomain, în care o singură instanţă serveşte zeci sau chiar sute de site-uri. Relevant în acest sens este momentul când la ediţia din 2013 a conferinţei “TYPO3 East Europe” cei de la Universitatea din Viena ne-au prezentat configuraţia lor: aproape 1000 de site-uri ţinute pe aceeaşi instanţă TYPO3, cu peste 100 de mii de pagini de conţinut, soluţie gândită astfel încât site-ul unui nou proiect din cadrul universităţii se lansează în jumătate de oră, pe baza şabloanelor preconstruite. În Germania, Austria, Elveţia, Olanda şi multe alte ţări, administraţia publică şi universităţile au adoptat TYPO3 pe scară largă, la fel şi mediul privat precum Lufthansa, Deimler, Bayer şi mulţi alţii. Ca orice platformă cu istorie îndelungată, în peste 15 ani TYPO3 a evoluat continuu şi ultimii ani au fost efervescenţi. Din dorinţa de a găsi soluţia perfectă şi a revoluţiona lumea CMS-urilor, două noi produse s-au alăturat platformei TYPO3 CMS clasică: TYPO3 Flow ( http://flow. typo3.org/ ), un framework pentru dezvoltarea aplicaţiilor, lightweight dar solid, şi

TYPO3 Neos ( http://neos.typo3.org/ ), o platformă CMS construită cu Flow, gândită pentru a oferi o flexibilitate şi o ușurinţă în editarea conţinutului cum nici o altă platforma CMS nu a avut până acum. Dar dincolo de tehnologie TYPO3 înseamnă Comunitate. Totul gravitează în jurul acestei idei, într-o comunitate activă care reuneşte dezvoltatori din întreaga lume, construind împreună, împărtăşind idei şi soluţii. Deviza TYPO3, “Inspiring people to share”, nu e o vorbă în vânt. Am probat încă o dată acest lucru la prima ediţie a “TYPO3 East Europe” ( pe scurt T3EE – www.t3ee.org ) care a avut loc la Cluj în 14-16 noiembrie 2013. S-au adunat peste 100 de participanţi din șapte ţări europene. Au fost două zile pline de prezentări pe subiecte tehnice, showcases, metodologii, bune practici, dezbateri privind dezvoltarea comunităţilor tehnologice. Am mai avut o zi dedicată universităţilor şi studenţilor, cu un workshop organizat împreună cu universităţile clujene şi cele din Viena şi Wuppertal. A fost o ocazie importantă de a participa la dialoguri relevante în urma cărora am câştigat prieteni, relaţii, cunoştinţe tehnice şi convingerea că merită să o facem din nou. În 31 octombrie – 1 noiembrie va avea loc a doua ediţie a “TYPO3 East Europe”. Ne aşteptăm la o participare şi mai largă ca

număr de participanţi şi ca diversitate geografică. Urmărim să aducem cât mai mulţi oaspeţi relevanţi, specialişti care să ne înveţe mai mult decât tehnologie ( care va fi oricum din plin ), să aflăm mai multe despre cum se gândesc şi cum se implementează soluţii performante în vestul Europei, despre metodologii, strategii, mecanisme de cooperare, construcţia şi gestiunea comunităţilor tehnologice. Această paletă largă de subiecte, dar şi diversitatea celor care vin din celelalte părţi ale Europei, fac T3EE semnificativ pentru orice membru al comunităţii IT din Cluj, prin urmare vă invit cu drag să vă înscrieţi pe www.T3EE.org şi aştept să ne vedem în 31 octombrie. TYPO3 East Europe este posibil datorită sponsorilor, în primul rând cei Gold: companiile româneşti Arxia ( www.arxia.com ) şi PWO ( www.pwo.ro ), firmele germane AOE ( www.aoe.com ) şi Jweiland ( www. jweiland.net ) şi suedezii de la Pixelant ( www.pixelant.net ).

Daniel Homorodean

daniel.homorodean@arxia.com CEO @ Arxia

www.todaysoftmag.ro | nr. 27/septembrie, 2014

comunități

Comunităţi IT

una septembrie vor avea loc o serie de conferințe astfel încât spațiul evenimentelor din calendar a devenit foarte mic pentru a le putea enumera pe toate. Vă invităm ca de obicei la evenimentele de lansare a revistei din Cluj dar și la cea din Târgu Mureș. De asemenea, în București au loc în perioada următoare SmartWebConf, Internet & Mobile World și SeeTest iar în Iași vom avea o nouă ediție a ..even mammoths can be Agile, un eveniment care s-a bucurat de un real succes anul acesta în Cluj. Transylvania Java User Group Comunitate dedicată tehnologiilor Java. Website: www.transylvania-jug.org Data înfiinţării: 15.05.2008 / Nr. Membri: 586 / Nr. Evenimente: 46 Comunitatea TSM Comunitate construită în jurul revistei Today Software Magazine. Website: www.facebook.com/todaysoftmag www.meetup.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 1746/Nr. Evenimente: 22 Cluj Business Analysts Comunitate dedicată analizei de business Website: www.meetup.com/Business-Analysts-Cluj Data înfiinţării: 10.07.2013 / Nr. Membri: 87 / Nr. Evenimente: 8 Cluj Mobile Developers Comunitate dedicată tehnologiilor mobile Website: www.meetup.com/Cluj-Mobile-Developers Data înfiinţării: 05.08.2011 / Nr. Membri: 236 / Nr. Evenimente: 15 The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software. Website: www.agileworks.ro Data înfiinţării: 04.10.2010 / Nr. Membri: 442 / Nr. Evenimente: 86 Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice. Website: www.meetup.com/Cluj-Semantic-WEB Data înfiinţării: 08.05.2010 / Nr. Membri: 191/ Nr. Evenimente: 28 Romanian Association for Better Software Comunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare. Website: www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 248/ Nr. Evenimente: 14 Tabăra de testare Comunitate formată din testeri și alți profesioniști din industria IT care, în cadrul unor întâlniri informale lunare, împărtășesc din cunoștințele proprii și învață din experiențele profesionale ale celorlalți membri. Website: www.tabaradetestare.ro Data înfiinţării: 15.01.2012 / Nr. Membri: 1186/ Nr. Evenimente: 33

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

Calendar Septembrie 18 (Cluj) Lansarea numărului 27 a Today Software Magazine www.todaysoftmag.ro Septembrie 22-23 (București) SmartWebConf smartwebconf.com Septembrie 23 (București) A III-a ediție a conferinței Gemini Solutions Foundry www.gemsfoundry.com Septembrie 24 (Târgu Mureș) Lansarea numărului 27 a Today Software Magazine împreună cu Cluj IT Cluster www.todaysoftmag.ro Septembrie 25-26 (București) SEETEST seetest.org Octombrie 1-2 (Iași) Business Days Iași www.businessdays.ro/Evenimente/Iasi-2014/ Octombrie 5 - 2 Noiembrie (online) Cursul Black Box Software Testing altom.training/bbst-foundations/ Octombrie 8-9 (Cluj) Internet & Mobile World imworld.ro Octombrie 10 (Iași) ...even mammoths can be Agile facebook.com/events/820690977965456 Noiembrie 25-26 (Cluj) Cluj IT Days itdays.ro

management

programare

JavaFX în Platforma Java Standard 8

-am uitat la ceas. 21.15, afară e întuneric beznă. Brrr! Vine toama. Cât ține? Enorm... până la primăvară. Pentru zile cețoase și reci, pentru cei care simt nevoia de studiu și perfecționare,voi aduce în atenție un topic nou, neabordat de mine în articolele anterioare, JavaFX. Sper că prin aceasta să trezesc interesul cititorilor revistei pentru această tehnologie, pe care o consider cu adevărat remarcabilă. Silviu Dumitrescu

silviu.dumitrescu@accesa.eu Java Line Manager @ Accesa

Diana Bălan

Diana.Balan@accesa.eu Java developer @ Accesa

Acest articol l-am scris împreuna cu Diana Bălan, Java Developer la Accesa, căreia îi mulțumesc foarte mult pentru idei și suport. Vom începe articolul despre JavaFX cu un mic istoric. JavaFX este urmașa lui F3 (Form Follows Function) ce îl are ca părinte pe Chris Oliver. În 2010 Oracle a anunțat că dezvoltarea lui JavaFX Script language va fi întreruptă, în schimb aceasta se va porta pe Java, formând platforma JavaFX 2. Prin aceasta se puneau bazele ca JavaFX să devină cel mai important mediu pentru aplicații rich client. API-ul JavaFX este rulat de un engine compus din subcomponente. Acesta cuprinde noul engine grafic de înaltă performanță numit Prism, sistemul eficient de windowing numit Glass și un engine media. Glass Windowing Toolkit este responsabil cu furnizarea unui serviciu nativ ce include gestiunea ferestrelor, a timer-elor și a suprafețelor. De asemenea, leagă platforma JavaFX de sistemul de operare nativ. Mai mult, Glass este responsabil de gestiunea cozii de evenimente. Dacă AWT își gestionează propria coadă de evenimente, Glass utilizează coada nativă a sistemului de operare. Glass Toolkit rulează în același fir ca și

aplicația JavaFX. În AWT se crea un fir de execuție paralel cu cel al Javei. O aplicație rich client este o aplicație ce are o interfață care reprezintă backend-ul fără a aglomera astfel interfața utilizator. JavaFX are un set complet de butoane, diagrame, tabele și container-e de layout pe care le folosim pentru a crea interfețe utilizator rich. În plus, putem folosi stiluri CSS. Toate componentele se conectează și afișează date din backend. În general, o aplicație rich client are următoarele caracteristici: • Este o aplicație stand alone executabilă. • Conține o interfață-utilizator ce are controale sau formulare. • Este descărcabilă din desktop sau web. • Se conectează la o bază de date și la un server de backend. • Este independentă față de sistemul de operare. O aplicație JavaFX este o aplicație Java de bază, ce permite feature-uri JavaFX. Codul minim necesar pentru a rula o aplicație JavaFX constă din: • O clasă ce extinde clasa abstractă javafx.application.Application. • O metodă main() ce apelează metoda

www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare JavaFX în Platforma Java Standard 8

primaryStage.setTitle(“Hello World!”); launch() și suprascrie metoda abstractă start(). Ca bună prac- Button btn = new Button(); tică apelul metodei launch() este singurul apel din main() btn.setText(“Say ‘Hello World’”); btn.setOnAction(new • Un stage primar ce este vizibil, ca argument al metodei EventHandler<ActionEvent>() { start() @Override • Avem trei tipuri de aplicații JavaFX: public void handle(ActionEvent event) { • Aplicații propriu zise, ce folosesc sintaxa Java tradițională System.out.println(“Hello World!”); } și API-ul JavaFX. }); • Aplicații FXML. FXML se bazează pe XML și este folosit StackPane root = new StackPane(); pentru a defini interfețe-utilizator în aplicații JavaFX. Cu FXML root.getChildren().add(btn); vom defini layout-uri statice precum formulare, controale sau primaryStage.setScene(new Scene(root, 300, tabele. Putem construi, de asemenea, layout-uri dinamice prin 250)); primaryStage.show(); includerea unui script. } • Aplicații preloader, folosite în procesul de deployment. import javafx.application.Application; import javafx.stage.Stage; public class JavaFXApplication extends Application { @Override public void start(Stage stage) { stage.show(); } public static void main(String[] args) { launch(args); } }

Un stage (javafx.stage.Stage) este un container GUI top level pentru toate obiectele grafice, iar un scene (javafx.scene.Scene) este container-ul de bază. Stage-ul primar este construit de platformă, dar pot fi construite și alte obiecte stage de către aplicație. Obiectele stage trebuie să fie construite și modificate în firul aplicației JavaFX. Articolele individuale care se află în interiorul scenei grafice sunt numite noduri. Fiecare nod este clasificat ca fiind : • Branch sau un părinte, ceea ce înseamnă că poate avea descendenți. • O frunză. Primul nod din arbore este numit rădacină și nu are părinte. Scena grafică este așadar o structură arborescentă. API-ul JavaFX face ca interfața grafică să fie mai ușor de creat, mai ales când sunt implicate efecte vizuale complexe și transformări. API-ul scenei grafice JavaFX este un retained mode, adică el gestionează un model intern al tuturor obiectelor grafice din aplicație. În orice moment el știe ce obiecte să afișeze, ce zone ale ecranului necesită redesenare și cum să fie renderizat în cel mai eficient mod. Aceasta reduce semnificativ cantitatea de cod necesar în aplicație. Îmbunătățim aplicația anterioară prin adăugarea unui buton cu text și al unui container de layout. Butonul va fi un nod frunză, } iar StackPane-ul nod rădăcină. import import import import import import import

javafx.application.Application; javafx.event.ActionEvent; javafx.event.EventHandler; javafx.scene.Scene; javafx.scene.control.Button; javafx.scene.layout.StackPane; javafx.stage.Stage;

public class JavaFXApplication extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) {

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

Vom crea o aplicație echivalentă folosind FXML. FXML oferă următoarele avantaje: • Fiind bazat pe XML este familiar multor dezvoltatori, în special dezvoltatorilor web și celor care utilizează alte platforme RIA. • FXML nu se compilează, de aceea nu este necesar să recompilăm codul în caz de modificări. • Asigură o structură ușor vizibilă a aplicației. • Când creăm o aplicație JavaFX FXML avem de realizat trei fișiere: • Clasa main, ce conține cod pentru crearea scenei aplicației,

management

TODAY SOFTWARE MAGAZINE

a stage-ului și pentru lansarea aplicației. Una dintre acțiunile prefWidth=”69” fx:id=”label” /> </children> importante este dată de secvența următoare: </AnchorPane> Parent root=null; try { root = FXMLLoader.load(getClass(). getResource(“Sample.fxml”)); } catch (IOException e) { e.printStackTrace(); } stage.setScene(new Scene(root));

Metoda FXMLLoader.load() încarcă ierarhia de obiecte din fișierul de resurse Sample.fxml și o asignează variabilei numite root. Această clasă este Model-ul în pattern-ul MVC. Ultima parte a acțiunii este setarea scenei.

Acest fișier reprezintă View-ul în pattern-ul MVC. Nodul rădăcină este AnchorPane, iar nodurile descendenți sunt Button și Label. Fișierul Sample.java, este fișierul controller al interfeței utilizator. Numele acestuia trebuie să fie identic cu cel al clasei view fxml. import import import import import import

java.net.URL; java.util.ResourceBundle; javafx.event.ActionEvent; javafx.fxml.FXML; javafx.fxml.Initializable; javafx.scene.control.Label;

public class Sample implements Initializable { @FXML private Label label; @FXML private void handleButtonAction(ActionEvent event) { System.out.println(“You clicked me!”); label.setText(“Hello World!”); } @Override public void initialize(URL url, ResourceBundle rb) { // TODO } }

Aplicațiile din acest articol au fost dezvoltate folosind Eclipse Luna, ca proiecte Java Standard în care am inclus pachetul lib\ jfxrt.jar. Vă mulțumim foarte mult pentru răbdarea de a citi articolul și vă așteptăm ca de obicei, cu toată plăcerea la discuții.

Fișierul Sample.fxml, este fișierul în care construim interfața utilizator <?xml version=”1.0” encoding=”UTF-8”?>„ <?import javafx.scene.layout.AnchorPane?> <?import javafx.scene.control.Button?> <?import javafx.scene.control.Label?> <AnchorPane id=”AnchorPane” prefHeight=”200” prefWidth=”320” xmlns:fx=”http://javafx.com/fxml” fx:controller=”henleyclient.Sample”> <children> <Button id=”button” layoutX=”126” layoutY=”90” text=”Click Me!” onAction=”#handleButtonAction” fx:id=”button” /> <Label id=”label” layoutX=”126” layoutY=”120” minHeight=”16” minWidth=”69” prefHeight=”16” www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare

Avantajele folosirii SVG (Scalable Vector Graphics)

VG (Scalable Vector Graphics) se impune drept unul dintre cele mai importante trenduri din domeniul web designului pentru anul 2014. Este recomandat de W3C (World Wide Web Consortium) încă din 2003, dar nu a fost foarte folosit, nefiind suportat în totalitate pe browser-e cum ar fi pe Internet Explorer. Însă lucrurile au început să se schimbe…

Peter Krejcik

peter.krejcik@yardi.com Web Designer @ Yardi România

În articolul meu, voi prezenta pe scurt conceptul SVG și voi discuta despre avantajele practice care recomandă utilizarea SVG în web design.

Ce este SVG?

SVG reprezintă prescurtarea pentru Scalable Vector Graphics, este un format pentru imagini de tip vectorial, bazat pe XML fiind utilizat pentru grafică 2D, care permite interactivitatea și animația. Timp de zece ani, SVG nu a fost folosit la potențialul maxim deoarece nu a beneficiat de suport complet pe Internet Explorer. Lucrurile însă s-au schimbat mult în ultimul timp, iar elemente de SVG sunt folosite acum din ce în ce mai mult, în special pe browser-ele care susțin HTML5. Astăzi, aproape toate browser-ele importante suportă SVG: • Internet Explorer 9+, • Firefox 4+, • Chrome 4+, • Safari 4+, • Opera 9.5+. SVG-urile se pot crea folosind meta-limbajul XML, care utilizează tag-uri asemănătoare cu cele HTML. De exemplu, codul următor generează un cerc alb cu contur negru: <svg height=”100” width=”100”> <circle cx=”100” cy=”100” r=”50” stroke-width=”4” stroke=”#000” fill=”#fff” /> </svg>

Explicarea codului: • Graficul SVG este declarat folosind t ag-ur i le <svg>...</svg> .

nr. 27/2014 | www.todaysoftmag.ro

Atributele de înălțime și lățime ale elementului <svg> definesc înălțimea și lățimea SVG-ului . • Atributele cx și cy definesc coordonatele x și y ale centrului cercului. Dacă cx și cy sunt omise, centrul cercului este automat poziționat pe coordonatele (0,0) • Atributul r definește raza cercului . • Atributele stroke și stroke-width controlează modul în care apare forma figurii pe care vrem să o desenăm. • Atributul fill (umplere) se referă la culoarea din interiorul cercului . Este important de reținut că XML este mult mai strict decât HTML, de aceea omiterea unui tag de încheiere ar putea duce la nevalidarea întregului fișier sau la eroare în generarea SVG-ului. Specificația W3C SVG1.1 definește 14 caracteristici principale: 1. Figuri de Bază (Basic shapes): linii drepte, poligoane, cercuri, figuri eliptice și dreptunghiuri cu sau fără colțuri rotunjite. 2. Traiectorii (Paths): traiectorii subliniate sau colorate care conțin linii drepte sau curbe. 3. Texte (Text): pe traiectoriile drepte sau curbate în orice direcție. 4. Desenarea (Painting): umple figuri sau le conturează folosind culori solide, gradient-uri, modele, transparență și markere (capete de linie cum ar fi săgețile). 5. Culoarea (Color): proprietățile de fill și stroke sunt definite folosind valorile standard hex sau rgb de 3 sau 6 cifre.

TODAY SOFTWARE MAGAZINE 6. Gradient-uri și pattern-uri (Gradients and patterns): un factor foarte important în prezent, deoarece display-urile de definire de gradient-uri în format CSS3 sau fundaluri bitmap. mare rezoluție sunt din ce în ce mai des folosite, iar livrarea unui 7. Secționări, acoperiri și compoziții (Clipping, masking conținut responsive este de dorit. and compositing): folosirea de elemente pentru a contura regiuni care apoi pot fi desenate. 8. Filtre (Filters): efecte aplicate tuturor elementelor din cadrul unui conținut, cum ar fi estomparea, luminozitatea, setarea culorilor. 9. Link-uri (Linking): hyperlink-uri către alte documente. 10. Interactivitate (Interactivity): atașarea de event-handlers folosind JavaScript. 11. DOM Scripting: accesarea și utilizarea elementelor SVG folosind Modelul Document Obiect. 12. Animația (Animation): animații integrate folosind Limbajul Synchronized Multimedia Integration Language (SMIL). 13. Fonturi: simboluri textuale definite într-un fișier SVG, care pot fi folosite ca font standard. 14. Metadata: cuprinde titlurile, descrierile, subiectele, autorii și alte caracteristici ale imaginii SVG. O altă modalitate de a crea SVG-uri este prin a le desena folosind un editor vectorial de grafică , metodă care este de preferat în cazul celor care nu cunosc bine XML sau al celor care vor să creeze elemente de grafică mai complexe. Ne vom referi la aceste instrumente în următoarele rânduri. Acum însă să ne vom concentra asupra motivelor principale pentru care un web designer ar trebui să ia în considerare folosirea SVG-urilor.

Ușor de creat

Avantajele folosirii SVG-urilor

Ușor de editat

Sunt scalabile Cel mai mare avantaj al graficii vectoriale este posibilitatea de a scala imaginile la orice dimensiune fără să pierdem din calitate (exemplificare în imaginea de mai jos). Acesta este motivul principal pentru care SVG este ideal pentru crearea de logo-uri de companii sau alte elemente grafice care necesită multe redimensionări. Orice designer trebuie să acorde atenție capacității de scalabilitate a produsului finit. Totodată, independența rezoluției în cazul graficii scalabile este

Crearea de elemente grafice simple cu XML este foarte ușoară.. Însă ce se întâmplă dacă trebuie să creăm elemente grafice mai complexe? Sunt destul de multe editoare de grafică vectorială user-friendly, care ar putea fi folosite pentru a crea grafică SVG: Adobe Illustrator, Macromedia Freehand, Corel Draw. Există de asemenea și câteva instrumente gratuite, cum ar fi Inkscape, OpenOffice, LibreOffice Draw și svg-edit (instrument online). SVG-urile sunt ușor de editat, fapt care le conferă un mare avantaj față de grafica rasterizată.. Dacă vrem să facem schimbări în grafica vectorială, avem nevoie de un editor de text sau, și mai ușor, putem folosi un instrument de editare grafică vectorială. Important de reținut: componentele în grafica vectorială pot fi manipulate individual, prin urmare, în momentul editării, nu e nevoie să construim totul de la zero. Schimbarea unor caracteristici de bază cum ar fi culoarea sau conturul se poate face simplu și rapid.

Objective C

jobs-cluj@yardi.com Yardi Romania

www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare Avantajele folosirii SVG (Scalable Vector Graphics) Dimensiuni mai reduse

SVG-urile pot fi folosite pentru SEO

Dimensiunea mai mică a fișierelor face ca transferul și încărcarea graficii să fie mult mai rapide. Din acest motiv, mulți preferă să folosească grafica vectorială: imaginea se încarcă mai repede, fără să fie nevoie să aștepțăm până când se încarcă imaginea completă.Chiar dacă dimensiunea imaginii este foarte mare, de obicei vom obține o dimensiune de fișier mult mai mică față de o imagine similară rasterizată.

Spre deosebire de imaginile de tip bitmap, XML prin natura sa poate fi citit automat, prin urmare fișierele SVG pot fi citite, analizate și indexate de către boturile din motoarele de căutare. Google a început indexarea conținuturilor SVG din august 2010 iar rezultatele pot fi găsite în sistemele standard și în căutarea de imagini.

Mai multe detalii De vreme ce vectorii folosesc linii, este mult mai ușor să se creeze o grafică extrem de detaliată. Totodată, ilustrațiile vor apărea mai clare decât pozele de mare rezoluție indiferent unde sunt folosite, de aceea sunt mai ușor de înțeles și arată mai bine și pe hârtie.

Dimensiunea fișierului în funcție de complexitate Imaginile vectoriale sunt fișiere de mici dimensiuni care depind de complexitatea imaginii, de cât de complicate sunt liniile și cât de complexe sunt punctele. Mărimea acestor grafice nu se bazează pe adâncimea de culoare.

API bazat pe un DOM accesibil SVG-urile au un DOM, fapt care deschide numeroase posibilități de a controla imaginea și comportamentul graficii. Este foarte ușor să atașăm event-handlers și să manipulăm elementele așa cum am faceo în cazul unor blocuri HTML. Tot din acest motiv putem inspecta cu ușurință elementele SVG în browser așa cum am face cu oricare alte elemente HTML. Mulțumită accesibilității DOM, putem stiliza elementele grafice în CSS și să le facem interactive cu JavaScript. API-ul bazat pe DOM al SVG oferă și posibilitatea de a crea imagini SVG b azate p e do c umente s er ver-side. Există multe biblioteci JS pe web pentru a controla elementele SVG: D3.js, Raphael, Snap.svg, Processing.js, JSDrawing, PlotKit, SVGWeb și Paper.js.

Uneori trebuie să creăm un element UI mai complex, care e format din mai multe forme de bază, având în vedere în același timp și ca ele să fie responsive. Crearea lor cu ajutorul HTML și CSS ar putea cauza multe probleme (poziționare, masking, layering și probleme legate de stil). O soluție mult mai bună ar fi să desenăm elementele într-un editor grafic și să îl salvăm sub formă de fișier SVG. Acest fapt Câteva dezavantaje… ne-ar permite să avem un singur element Nu ar fi corect să nu amintim aici și scalabil și să nu ne facem griji în privința câteva dezavantaje pe care le implică utili- controlării mai multor div-uri. zarea de SVG. Din fericire, sunt puține cele care trebuie amintite: Logo-uri Majoritatea logo-urilor sunt grafice Dezvoltare complexă bazate pe vectori. Prin urmare, de ce nu Codul SVG care este structurat prin am putea defini un document SVG ca XML poate fi destul de lung și de complex, logo-ul nostru și să îl plasăm oriunde, scadificil de corectat. lându-l ușor la orice dimensiune e nevoie, fără să compromitem calitatea și salvând în Probleme de performanță același timp și lățimea de bandă? În cazul folosirii multor animații complexe, motorul WebKit poate deveni Jocuri ușoare considerabil mai lent. Chiar dacă CANVAS este mai potrivit pentru redarea de jocuri (jocuri care foloNu este suportat complet de browsere mai sesc grafică și animație bazate pe pixeli), vechi (Internet Explorer 8 și versiuni mai SVG ar putea fi o alternativă viabilă vechi) pentru jocurile simple, care necesită mai Există însă și soluții prin care se poate puțină animație pentru personaje și mai extinde suportul oferit de browsere, cum mult spațiu pentru afișarea de informații ar fi Raphael.js sau folosirea tehnicii de (de exemplu Sudoku). înlocuire a SVG-urilor cu imagini statice pentru browserele mai vechi. AD-uri responsive Conținutul AD-ului ar ocupa spațiul Utilitatea SVG oferit de document și, luând în considerare Să vedem câteva aplicații practice ale că CSS și JavaScript-ul sunt permise, majoSVG. ritatea acțiunii ar fi limitată la un singur fișier SVG pe AD

Grafice

Deoarece avantajul principal al SVG-urilor este reprezentarea de forme vectoriale de bază, funcționează foarte bine când sunt utilizate pentru crearea de grafice și infographics-uri. Se pretează atât la crearea de grafice statice pornind de la anumite valori date, cât și graficele “live”, alimentate în mod dinamic de către request-uri AJAX, input-ul utilizatorilor sau date generate în mod aleatoriu.

Request-uri HTTP reduse

Hărți

Dacă SVG-urile sunt incluse direct într-un document HTML cu tag-ul svg, browserul nu trebuie să facă un request pentru a afișa grafica, ca în cazul în care se folosesc imagini cu tag-ul <img>. Acest fapt are ca rezultat o performanță mult mai bună în ceea ce privește încărcarea conținutului pe web.

Hărțile sunt formate din linii și forme exacte. Aceste forme pot fi foarte ușor reprezentate cu ajutorul graficii vectoriale și se pretează acțiunilor precum zoomul pentru mai multe detalii.

Elemente UI complexe

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

Linkuri utile Principii de bază pentru folosirea SVG : http:// www.w3schools.com/svg/svg_intro.asp Folosirea SVG, un ghid practic: http://css-tricks. com/using-svg/ Workflow SVG: http://danielmall.com/articles/ svg-workflow-for-designers/ O colecție de informații SVG: http://css-tricks. com/mega-list-svg-information/ Despre animații SVG: http://24ways.org/2013/ animating-vectors-with-svg/ Responsive SVG :http://demosthenes.info/ blog/744/Make-SVG-Responsive SVG Vs Canvas: http://www.sitepoint.com/7-reasons-to-consider-svgs-instead-of-canvas/ SVG și SEO: http://www.rocketmill.co.uk/ exploiting-svg-images-for-seo Exemple de SVG: http://www.creativebloq.com/ design/examples-svg-7112785

programare

Livrarea continuă

n ultima perioadă suntem bombardați din toate părțile de ideea că trebuie să începem să folosim Continuous Delivery (Livrare Continuă), adică să începem să punem aplicația mai repede în producție și cu frecvență mai mare. Da, într-adevăr, să mergem live cu aplicația în producție de zece ori pe zi e distractiv și cool. Dar atunci de ce am avut nevoie de aşa mulţi ani? Livrarea continuă este menționată încă din primul principiu agil: Dan Danciu

dan.danciu@isdc.eu Software Architect @ ISDC

Prioritatea noastră este satisfacția clientului prin livrarea rapidă și continuă de software valoros. Contează pentru că toată lumea face sau pentru că este distractiv și interesant? Nu aceasta este abordarea corectă. În tot ceea ce facem trebuie să ne asigurăm de ceea ce este corect pentru companie, trebuie să înțelegem ce trebuie făcut și poate cel mai important lucru este cum putem să aducem valoare companiei. Prin acest articol intenționez să prezint de ce este important ca oamenii de business să fie de acord cu livrarea în mod continuu, care sunt diferențele dintre aceasta și alte practici și cum să începem a o realiza. Pe lângă toate cele de mai sus, vor fi observații cu privire la contextul dezvoltatorilor software din outsourcing, mediu care este considerabil diferit.

Pentru că am văzut o mulțime de prezentări, bloguri, filme în ultima vreme care omit întru totul să menționeze că nu doar tu, gurul tehnic, trebuie să înveți ce presupune livrarea continuă ci și oamenii de business. Dar dincolo ce surprind aceste prezentări, este important de subliniat că tu, omul tehnic, poți face ceva pentru a schima lucrurile. Este necesară utilizarea și a practicilor de integrare continuă și deployment continuu pentru a avea succes în practica de livrare continuă, dar de foarte multe ori oamenii folosesc termenul continuous delivery când se referă la continuous deployment, iar mai jos vă voi arăta ce înțeleg eu prin acești termeni.

Continuous Integration, Martin Fowler

Integrarea continuă este practică a dezvoltării software în care membrii unei echipe integrează ceea ce livrează des, de obicei fiecare Este mai mult decât continuous depersoană integrează munca proprie cel puțin o ployment dată pe zi - ceea ce conduce la mai multe inteUitându-ne la știrile din mediul IT apar grări pe parcursul unei zile. tot mai multe instrumente care să faciliteze accesul în etapa numită livrare în mod con- Continuous Delivery vs. Continuous Deploytinuu. Când voi putea să învăț toate aceste ment, Martin Fowler instrumente dintre care menționez câteva Livrarea continuă se referă la ideea că precum puppet, chef, varant, Go CI ? Și mai aplicația este în permanent într-o stare în mult, cine ne va pune la dispoziție timp pen- care poate fi pusă în producție. Deployment tru a le integra în proiectele noastre care sunt continuu este de fapt punerea în producție a deja în urma față de planificarea managerilor aplicației la fiecare schimbare de cod, în fiecare noștri. zi sau chiar mai des. Eu cred că trebuie să ne întrebăm ce vom Atunci când am citit primul fragment câştiga prin a implementa primul dintre mi-am spus: „Interesant, deployment contiprincipiile agile, iar răspunsul este feedback. nuu e mai bun decat livrare continuă!” și acum Pentru a ne asigura că recunoaştem valoare câțiva ani s-ar putea să fi avut dreptate. Jez aşa cum este specificat în primul principiu, Humble a spus la un moment dat că livrarea trebuie să învățăm ce înțeleg clienții și busi- continuă nu are nevoie de deployment conness-ul prin valoare, exact la fel cum facem tinuu, iar vice-versa nu e neapărat adevărat. și cu atributele de calitate. De fapt, în acest Însă acum eu cred că este mai important să context valoare este calitate și vice-versa. De fii alături de business, iar utilizarea de deployce trebuie să recunoaștem valoarea? Deoarece ment continuu doar în mediul de acceptanță trebuie să ne dăm seama când am reușit să o nu este suficientă. A acorda businessului atingem sau măcar cât mai avem nevoie până dreptul de a pune aplicația în producție este o vom atinge. ceea ce înseamnă de fapt livrare continuă. Dar de ce afirm toate aceste lucruri? Chiar mai mult, unele companii au diminuat www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare Livrarea continuă rolul sau chiar îndepărtat întru totul mediul de acceptanță, punând aplicația direct în producție, doar cu o testare minimă din partea developer-ului - ceea ce pentru mine înseamnă că cei doi termeni au fuzionat, motiv pentru care mă simt mai în largul meu să utilizez termenul de livrare continuă.

Feedback în CI/CD

Și totuși, ce ar putea face un dezvoltator care lucrează întro firmă de outsourcing? De cele mai multe ori nu are acces la oamenii din business, în cel mai bun caz poate doar acces limitat, pentru că de cele mai multe ori interacționează cu analiști funcționali. Până recent am crezut că este suficient să faci curățenie în curtea proprie și că atunci când cei din jurul tău vor vedea că modificarea aduce o îmbunătățire, atunci se vor schimba și ei, în consecință îmbunătățind întreaga companie. Și nu este chiar greșit, dar ideea are o capcană: aduce cu adevărat valoare dacă eu îl văd ca un beneficiu? Probabil de multe ori nu suntem oameni tehnici, de multe ori am petrecut ore în șir șlefuind întrun diamant o porțiune de cod care deja funcționa. Util pentru business poate ar fi fost ca acel cod să ruleze deja în producție. Consider că trebuie să întrebăm oamenii din business care sunt valorile pe care ei le urmăresc în luarea deciziilor. De fapt noi facem acest lucru deja atunci când întrebăm despre atributele de calitate. Dacă ai fost la unul din cursurile lui Tom Gilb cu siguranță ești deja convins că primul lucru pe care trebuie să îl faci este să întrebi businessul care sunt primele lor zece valori; și ne vom focaliza asupra soluției care va avea ROI-ul cel mai mare (ROI - return of investment), o vom implementa, după care trecem la următorul, și următorul și tot așa.

Extinderea înțelesului termenului de „terminat”

Urmând practicile agile, în principal utilizând Scrum și Kanban, suntem obișnuiți cu expresia definiție pentru terminat, în engleză definion of done, pentru user stories. Definiția o folosim pentru ca între membrii echipei și stakeholder-ii proiectului să avem aceeași înțelegere asupra a ce trebuie realizat pentru ca un item de pe backlog să fie considerat complet. Îmi aduc aminte că atunci când am început practicarea Scrum credeam că un item complet reprezenta ce trebuia să fac pentru ca un user story să fie acceptat de către Product Owner. După câteva sprinturi am învățat să înțeleg prin terminat tot ce trebuia să fac pentru ca story-ul să ajungă în producție; până la urmă Scrum precizează „la calitatea potențial livrabilă”, lucru care atunci când mă uit în trecut însemna de fapt terminat în contextul integrării continue. Mai târziu, pe lângă eforturile de a practica integrarea continuă, ne-am uitat și la modalități de unificare a deployment-ului aplicațiilor în diferite medii. Era un dezastru total, noi - echipa de dezvoltare nearshoring - eram responsabili pentru deploymentul și stabilitatea aplicației pe mediul de testare și acceptanță, în timp ce echipa de întreținere era responsabilă de infrastructură și deployment în producție.

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

Dar, pe măsură ce timpul a trecut, am început să unificăm procedurile de instalare și de împărțire a responsabilităților între echipe; noi, dezvoltatorii, cream artefactele pentru o versiune a aplicației, adică din instrumentul de integrare continuă produceam artefacte care nu depindeau de mediul în care vor fi puse, în timp ce echipa de întreținere se ocupa de instalare în toate mediile, rezolvând în același timp și configurările care depindeau de mediu. Trebuie să recunosc că nu a fost deloc ușor, am avut „câteva” probleme: de exemplu adăugarea unei noi configurări dar, în cele din urmă, am ajuns să lucrăm mai aproape cu echipa de întreținere, unii ar putea chiar zice că am ajuns să lucrăm împreună. Și așa am reușit să împingem înțelesul termenului terminat și mai departe: terminat - ca și instalat în producție, în mâinile utilizatorilor. Recent am auzit o prezentare a lui Adrian Cockcroft, ex-architect șef la Netflix, în care spunea că pentru ei cod terminat, adică software terminat, e atunci când este retras din producție. Ceea ce înseamnă că responsabilitatea noastră ca implementator nu se termină atunci când am scris codul și acesta a ajuns pe mediul de acceptanță sau chiar producție; ci terminat înseamnă a avea grijă de software pe întreaga lui viață: atunci când îl creăm, atunci când rulează, având grijă să fie în condiții optime de memorie sau CPU, făcând mentenanță, îmbunătățindu-l de fiecare dată când are nevoie, iar la final, atunci când îl retragem din producție întrun mod controlat.

Livrare continuă în gândirea lină

Dacă ne uităm la principile Lean, vom vedea că acestea nu sunt deloc diferite față de ce am prezentat mai sus: utilizarea de iterații, cu incremente mici de la ideea de business la client, folosind feedback-ul din utilizarea produsului și adaptându-l, crescând funcționalitatea în mod organic. La finalul fiecărui ciclu echipa trebuie să livreze un increment, dar trebuie ales cu atenție ce alegem deoarece trebuie să începem cu cel care aduce cea mai multă valoare utilizatorilor. Atunci când este utilizat obținem feedback prin utilizarea unor metrici și învățăm, după care decidem ce urmează să construim. Nu spun că trebuie să astepți câteva săptămâni fără să faci nimic pentru a obține valori realiste în urma măsurătorilor, trebuie să ai munca planificată în avans, dar atunci când gândești funcționalitea trebuie să folosești ceea ce ai învățat de la utilizator. Iar atunci când observi ceva problematic în producție, ceva ce afectează utilizatorii, poți mult mai repede să identifici proactiv, amânând munca mai puțin prioritară și să fixezi problema. Este important să realizăm că expresia de incremente mici nu se referă neapărat la perioada de timp, ci la cantitatea de modificări, cu alte cuvinte trebuie să acorzi atenție la volumul de muncă pe care îl faci în paralel (WIP - work in progress). Un alt principiu al gândirii line este de a crea calitate în tot ceea ce faci, build quality in. Nu vei putea pune în mâinile businessului butonul cel mare și rosu: „Deploy Now!” fără a avea mecanisme automate de a valida calitatea produsului. Iar pentru aceasta va trebui să înțelegi ce înseamnă calitate pentru business. Să nu cazi în capcanele comune: ce înțelegi tu prin calitate nu e neapărat ce businessul înțelege prin ea. Calitatea nu este la fel pentru două produse, chiar și pentru același client. Calitatea costă - așadar identifică pragul la care ea trebuie livrată. Înțelesul calității s-ar putea schimba de-a lungul evoluției sistemului. Așadar mergi la business și întreabă care sunt calitățile pe care și le doresc de la produs, definește-le împreună cu ei într-un mod cuantificabil și construiește mecanisme automate care să verifice că sistemul

TODAY SOFTWARE MAGAZINE

respectă nivelul pentru fiecare atribut de calitate identificat. Important în gândirea lină este și eliminarea surplusului, a muncii în zadar, adică identificarea părților care încetinesc sau îngreunează ritmul de muncă sau a părților care nu aduc valoare sistemului. În momentul în care ai un proces pe care îl urmărești și măsurători prin care să obții feedback și cu ajutorul cărora să înveți, vei putea cu ușurință să identifici care parte a sistemului sau procesului te încetinesc sau te limitează. Odată identificată, este evident că nu merită să acționezi în altă parte, orice îmbunătățire în alte locuri are drept cauză acumularea de și mai multă muncă în zona problematică. Decide cât mai târziu! Pentru a lua decizii bune e nevoie să ai informații detaliate despre domeniul respectiv, ceea ce înseamnă timp, adică bani. În consecință vei dori să amâni momentul luării deciziei până când este cu adevărat critic. Prin aceasta vei reduce riscul de a lucra în zadar, deoarece nu mai este nevoie sau odată cu trecerea timpului informațiile tale asupra problemei s-au modificat. Trebuie însă să avem grijă să nu ajungem la paralizieprin-decizie, deoarece nu avem suficiente informații pentru a lua o hotărâre. După cum am menționat în mai multe rânduri până în acest punct, în Lean este important actul învățării, atunci când luăm decizii sau atunci când prioritizăm. Cu alte cuvinte înseamnă că trebuie să ne uitam la trecut și să învățăm atât din greșeli cât și din succese. Așa că pe lângă măsurătorile pe care le pui pentru aplicație și pentru modul de lucru, organizează mecanisme prin care să asiguri învățarea continuă. Review-ul sprintului, cunoscut și ca demo sau retrospectivele sunt un bun început, deoarece ele asigură feedback pentru produs și respectiv modul de lucru, însă sunt multe altele pe care ai putea să le faci. De exemplu uită-te la eșecurile din producție și organizează post-mortem-uri nu pentru a atribui vina, ci pentru a învăța din greșeli și a nu le repeta. Nu te limita prin a te uita doar în mediul proiectului tău, uită-te la întreaga organizație, la ce se întâmplă în industrie; dar, nu uita: nu face lucrurile doar pentru că și alții le fac, aplică soluții pentru că înțelegi care sunt beneficiile în contextul tău. Pe lângă nevoia de a învăța suntem responsabili și de a transmite și altora ce am învățat. Ultimul aspect dar nu mai puțin important este că în Lean avem nevoie de o echipă cu putere de decizie. O echipă trebuie condusă, nu micro-manageriată pe parcursul întregului proces de implementare; lasă membrii echipei să se organizeze singuri, ai încredere în ei că vor face tot ceea ce este în puterile lor, iar dacă au nevoie de ajutor îl vor cere. Ca manager al echipei fă un pas în spate și asigură-te că există imaginea de ansamblu iar ceea ce face echipa e în concordanță cu planul, vezi care sunt impedimentele echipei, ajută echipa să le conștientizeze și să le înlăture. Așadar, livrarea continuă reprezintă producerea de valoare

pentru business prin software de calitate în cicluri rapide, cu incremente conținând puține modificări, observând efectele modificărilor și utilizând feedback pentru a îmbunătăți produsul și procesul de creare al acestuia. Sunt un mare fan al dezvoltării condusă de testare, folosesc această tehnică de fiecare dată când ajung să codez, indiferent de limbajul de programare pe care îl folosesc: java, nodejs, xquery pentru development pe Marklogic, javascript pentru dezvoltare pe client, sau chiar bash pentru scripturi de instalare – mă axez inițial pe ce vreau să obțin, cum îl voi utiliza, creez metode de testare după care implementez. Dar TDD e doar primul nivel la care putem obține feedback, utilizând livrarea continuă asigurăm un ciclu acțiune -> răspuns la nivel de business, iar pentru a reuși avem nevoie de colaborare între oamenii de business și oamenii tehnici.

Principiile și practicile livrării continue

Până în acest punct am descris în principal de ce și cum adoptarea practicii de livrare continuă ajută o organizație, sau în contextul outsourcing-ului, organizația clientului și a aceluia care dezvoltă software prin crearea unui parteneriat centrat pe câștigul ambelor părți. În această secțiune vom analiza principiile și practicile. În primul și primul rând trebuie să creăm un proces de deployment repetabil, pentru a ne asigura că avem un proces în care să avem încredere. Pentru a obține acest lucru vom începe prin a observa cum o idee de business, o funcționalitate, ajunge la utilizator. Să nu cumva să credem că aceasta se rezumă doar la a alege un story, în a-l implementa și a-l pune în producție. Nu! Trebuie să ne uitam la întregul drum pe care o funcționalitate îl are: din momentul în care ia naștere, cum este definit, prioritizat față de alte funcționalități, cum se alege echipa care îl va implementa, cum se asignează resursele, cum se planifică munca și doar după toate acestea ne uităm la implementare. La început va fi amețitor volumul de informații și haosul care acum va fi aparent. Creează board-uri pentru fiecare stream, în care fiecare pas va reprezenta o coloană, iar cel mai important va fi să urmezi principiile lean și agile. Atunci când ai harta pe care o funcționalitate o străbate pentru a fi implementată, identifică zonele care încetinesc ritmul de muncă de la un stadiu la altul și, mai mult, înțelege de ce. Acestea sunt punctele în care vei dori să acționezi în primul rând. Pentru a le îmbunătăți încearcă să reduci sau elimină ceea ce nu aduce valoare, iar ceea ce rămâne trebuie automatizat – rezultatul va fi o muncă mai rapidă și mai de încredere. Pentru că vom dori să folosim cicluri rapide, prin care să obținem seturi de modificări mai mici, atunci când ceva se strică, vom putea cu ușurință să vedem ce s-a modificat de când funcționa totul corect. Pentru a obține acest lucru va trebui să www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare Livrarea continuă versionăm totul, nu doar codul, ci și configurările, cerințele funcționale, scripturile de instalare, API-urile, și orice altceva ne-am putea gândi; chiar mai mult, ar fi util să putem să relaționăm modificările între ele. Dacă o activitate este dureroasă, atunci cu atât trebuie făcută mai des. Am putea începe cu procedura de deployment, dar nu se limitează doar la aceasta. Gândește-te la problemele ce pot apărea în producție, poți organiza exerciții pentru a repeta procedura de recuperare în diferite scenarii de failure, în acest mod vei putea fi pregătit pentru momentul în care o situație reală va apărea, mai mult, cu timpul vei avea mai multe cunoștințe despre procedură și o vei putea automatiza. După cum cei de la Netflix au făcut cu Chaos Monkey, care oprește aleatoriu noduri în producție și monitorizează stabilitatea sistemului, și mai târziu cu întreaga Symian Army, care oprește instanțe la diferite nivele ale infrastructurii. Cu toate cele menționate mai sus, nu poți spune „gata, am terminat!”. Pentru că toate fac parte dintr-o muncă continuă și trebuie să vezi cum poți îmbunătăți fiecare pas.

Crearea unui pipeline de deployment

Noi suntem doar oamenii tehnici, ce am putea face noi? O dată ce ne-am asigurat că suntem aliniați cu cei din business, că ne orientăm eforturile pe lucrurile care aduc cu adevărat valoare, e nevoie și să creăm suportul pentru tot ce e menționat mai sus. Cu alte cuvinte vom implementa un deployment pipeline. Un deployment pipeline este spargerea procesului de construire în mai mulți pași independenți. În urma fiecărui nou pas creștem încrederea în noua versiune, de obicei cu costul trecerii timpului. Pașii de la început vor găsi majoritatea problemelor, conducând la feedback rapid, iar pașii ulteriori vor folosi tehnici de sondare. Nu vom reuși niciodată să dovedim că un soft nu are bug-uri, dar putem încerca să prindem cât mai multe dintre ele. Recomandarea mea este să începeți prin a identifica pipelineul pe care îl aveți momentan. Sunt sigur că există unul, încercați să îl vizualizați - folosind kanban boards; vedeți unde se acumulează munca, identificați cum este prioritizată munca în aceste locuri, ce tipuri de muncă sunt practicate. Asigurați-vă că dețineți tot ce poate avea trasabilitate: cod, configurări, scripturi de asamblare și instalare, sau chiar artefactele care sunt produse în procesul de asamblare și împachetare. În momentul în care ai toate cele de mai sus, un următor pas ar fi standardizarea deployment-ului: adică compilarea și asamblarea artefactelor o singură dată, după care instalarea lor în oricare dintre medii se face cu aceleași scripturi sau mecanisme. Ceea ce înseamnă că artefactele vor fi independente de mediul de rulare, configurările sunt și ele trasabile, iar construirea și instalarea este automatizată și identică în oricare dintre medii: dev, test, acceptanță, pre-producție și chiar și producție. Acestea ajută deoarece la fiecare pas creștem nivelul de încredere în noua versiune care acum se trece prin pipeline. Ceea ce am putea numi generic: deployment pipeline instance. În paralel putem să ne asigurăm că avem pași automați care să crească nivelul de încredere în calitatea versiunii; și că pașii manuali sunt pe cât posibil spre capătul pipeline-ului. Ai putea începe prin a încerca testarea de acceptanță automată sau testare de integrare a API-urilor expuse și chiar mai multe unit teste. Nu trebuie să acoperi întreaga aplicație de la început, începi cu testele care validează flow-urile critice, după care alte părți cu risc ridicat, încerci să acoperi cât mai mult atât pe verticală cât și pe

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

orizontală în funcție de gradul de risc. Pe lângă aceasta ar fi bine să nu uitam de Continuous Integration, care este prima poartă pe care un build trebuie să o treacă, aici putem crește acoperirea cu unit teste, analiza statică dar cel mai important e să avem marje pe care build-ul trebuie să le treacă. După toate acestea te poți ocupa ca deployment pipeline-ul să fie automatizat: în momentul în care un nou set de modificări este comis în version control, întreaga instanță este pornită, iar în momentul în care un pas a trecut automat vom trece la următorul. După cum am subliniat în mai multe rânduri trebuie identificat ce ne îngreunează procesul pentru a-l putea ameliora. De fapt, munca ta pe pipeline nu se termină niciodată, atunci când ceva pică, vezi care este cauza și dacă ai fi putut să o prinzi mai repede. Adaugă noi pași în pipeline atunci când este nevoie. De asemenea, să nu cumva să îți imaginezi că vei opri toate proiectele din business timp de 6 luni și să lucrezi doar pe acest nou și interesant proiect tehnic. Compania ta trebuie să supraviețuiască, nu există butonul de pauză. Pipeline-ul trebuie construit împreună cu proiectele existente din business, iar la fiecare pas nou adăugat trebuie să se vadă valoarea imediată și să se includă costul în bugetul proiectelor. În ISDC avem IDAM, ISDC Defined Agile Model, suntem un grup de oameni care încearcă să ajute ISDC-ul în calitatea ei de companie precum și echipele de development din ISDC să fie mai bune în ceea ce fac prin urmarea principiilor agile. În urmă cu ceva timp ne-am uitat la cum practicarea livrării continue ar putea ajuta proiectele și pe clienții noștri. Pe lângă recomandările pe care le-am avut, am creat și o imagine, o hartă a practicilor pe care le-am identificat la momentul respectiv. Nu este varianta ideală, nici ce mai bună, de fapt nici măcar o recomandare, ci mai degrabă e un meniu ca la restaurant, din care fiecare trebuie să ne alegem ce avem nevoie în funcție de riscurile pe care le avem, adică ce ne ajută pe noi. Exemplu de continuous delivery pipeline

Concluzii

Unii probabil cred că ceea ce am relatat în acest articol e doar o poveste frumoasă. Eu însă consider că pentru a putea aduce cu adevărat valoare businessului și nu doar frumusețe tehnică, trebuie să fim conștienți de toate acestea. Cu toate acestea, nici un sfat teoretic nu se compară cu experiența practică. Datorită posibilelor diferențe de percepție, promit că voi reveni în unul din numerele următoare pentru a prezenta un caz practic de trecere a unui proiect la continuous delivery. Voi avea ocazia de a expune uneltele folosite și beneficiile obținute și, nu în ultimul rând, care sunt practicile recent descoperite sau lecțiile învățate.

programare

Detectarea fraudelor cu Titan

mplificarea recentă a fenomenului jocurilor de noroc online arată că vor exista întotdeauna oameni care vor încerca să ocolească sau să evite complet comportamentul corespunzător de business și vor încerca să obțină avantaje din acest fapt. Vorbesc în primul rând de impersonificare, de obținerea unor avantaje necinstite de pe urma promoțiilor, a sindicatelor sau simpla încercare de a găsi o scăpare în fluxul de business al sistemului. Florin Măguran

florin.maguran@betfair.com Senior Java Developer @ Betfair

Munca la Betfair m-a învățat că, atunci când dezvolți aplicații cu spectru larg, trebuie să depui 10% (sau mai mult) efort suplimentar pentru a-ți proteja aplicația. Totuși, acest lucru se dovedește adesea a fi insuficient și trebuie să iei măsuri pentru a diminua numărul celor care fraudează. Un astfel de exemplu este încercarea de a concilia conturile noi și de a detecta conturile duplicat. În această fază începe magia. La Betfair folosim diferite mecanisme pentru a realiza acest lucru. Voi vorbi în special despre un instrument pe care noi l-am dezvoltat recent. Se numește Spider, iar slujba sa este să detecteze conturile care au legătură, pe baza datelor utilizate în momentul înregistrării. Acesta folosește un set de reguli de potrivire care combină factori precum neclaritatea (distanța Levenshtein), operațiuni în lanț (egalitate, incluziune, începe/ se sfârșește cu) și alte combinații.

Am ales Titan

Din punct de vedere tehnic, problema pe care încercăm să o rezolvăm este crearea unui grafic al tuturor conturilor create vreodată (reprezentate de noduri) și trasarea unor hotare între conturile care au legătură. Acesta se reduce la o reprezentare grafică și un mecanism pentru a căuta rapid prin toate nodurile. Candidații au fost Neo4J, OrientDB, Dex și Titan. Toate au punctele lor forte și slăbiciuni,

dar în final, noi am ales Titan. Este un graphDB nou; proiectul a fost început în 2012 de către Aurelius1 și a fost conceput cu gândul la scalabilitate și performanță. Este bazat pe Java și câteva dintre caracteristicile sale includ: • Integrare ușoară – este de fapt un artefact maven, un simplu jar pe care îl incluzi în proiectul tău și gata! – îl ai acolo (bineînțeles, trucurile apar mai târziu, când ai nevoie de un comportament specific). • Gratuitate (licență Apache). • TinkerPop stack (deoarece Titan este bazat pe Blueprints API, poți ușor să conectezi TinkerPop stack pentru a facilita lucruri precum fast traversal (traversare rapidă), gremlin shell pentru cercetarea graficelor, rexter pentru vizualizarea graficelor). • Performanță bună când este utilizat cu Cassandra backend (scalabilitate și decuplare). • Accesibilitate ridicată, fără nici un defect și opțiune de scalare orizontală (în comparație cu Neo4J, de exemplu) • ElasticSearch utilizat pentru a indexa nodurile și muchiile (și cum ES este reunit în fascicul, noi putem oricând să scalăm orizontal prin adăugarea mai multor VM) Pentru a completa imaginea, trebuie de 1 thinkaurelius.github.io/titan/

www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare Detectarea fraudelor cu Titan asemenea să menționăm și slăbiciunile lui Titan. Câteva dintre acestea sunt: • Tehnologie nouă (prima versiune în 2012). • Se bazează pe clustering (grupare) – ambele Cassandra și ES funcționează în propriul lor cluster (fascicul), astfel oferindu-vă o abordare diferită a infrastructurii aplicației voastre. • Nu sunt prea mulți utilizatori; suport limitat de la Aurelius (o comunitate semi-activă cu răspunsuri de la creatori/ dezvoltatori – unde chiar dacă răspunsul este prompt, este nevoie de timp pentru a face toate modificările) . Bine, poate că am trișat puțin, deoarece noi deja lucram cu Elastic Search și am vrut să încercăm și Cassandra, dar, per total, Titan este o alegere redutabilă pentru reprezentări grafice și ne satisface nevoile foarte bine. Pe la mijlocul proiectului am descoperit că PayPal a dezvălui într-un comunicat de presă că și ei utilizează Titan pentru a descoperi frauda, deci, din păcate, nu ne putem lăuda că suntem primii care folosesc Titan pentru acest scenariu anume. Totuși, în industria jocurilor, putem afirma cu mândrie că suntem prima companie care își scanează clienții după o multitudine de reguli pentru a preveni și detecta frauda. Singura problemă pe care am întâlnit-o în mijlocul procesului de implementare a fost când am realizat că avem nevoie de o versiune specifică a Elastic Search și am fost obligați să ramificăm codul bază al Titan pentru a reconcilia versiunile.

noastre de potrivire impuse de către echipa de fraudă și a crea liniile corespunzătoare. Un exemplu simplu de reprezentare grafică ar putea fi următoarea imagine (observați lanțurile frumoase când sunt potrivite mai multe conturi):

Una dintre îmbunătățirile performanței pe care le-am făcut și care merită menționată este o opțiune de căutare leneșă, care se bazează pe crearea liniilor în timpul de rulare când se caută noi legături. Dacă ne-am fi decis să creăm un grafic complet în timpul creșterii activității, am fi vorbit de săptămâni de indexare a datelor, ceea ce ar fi fost inacceptabil din punctul de vedere al utilității. Căutarea legăturilor înseamnă în principiu începerea cu numai un nod sursă și adunarea tuturor nodurilor adiacente (ca și un păianjen) până când se atinge un număr maxim predefinit al Implementarea Spider rezultatelor, stocarea rezultatelor în Cassandra și trimiterea către Am decis să utilizăm Titan împreună cu Cassandra (pentru solicitant a unui mail cu un fișier zip conținând toate fișierele csv persistență) și Elastic Search (pentru indexare/ căutare rapidă). cu rezultatele. Modul în care am fasonat problema noastră a fost să reprezentăm conturile drept noduri (stocând datele de înregistrare drept Concluzie atribute ale vârfurilor), dar pentru că se cerea o căutare logică cu În general, Titan este un instrument pe care l-aș recomanda specificator ambiguu, am trebuit să stocăm atributele în text clar. dacă scenariul dumneavoastră de afacere solicită o reprezentare Acest lucru nu ne-a făcut prieteni cu departamentul de securitate, grafică bazată pe java a datelor voastre model și aveți nevoie de deoarece ei aveau reguli stricte în legătură cu stocarea datelor per- traversare rapidă și scalabilitate progresivă. Este un framework sonale de identificare în NoSQL, dar a fost un compromis pe care amuzant cu care să lucrezi, iar proiectul de patru luni a dovedit am fost nevoiți să îl facem. că este o soluție fezabilă. Deci concluzia mea este: Betfair + Titan Am folosit fire multiple pentru a popula inițial graficul uti- = love! lizând date preluate de la Oracle DB, iar apoi ne-am bazat pe Titan pentru a căuta în paralel în Elastic Search pe baza regulilor

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

programare

Pragmatism în programare

Mihnea Lazăr

mihnea.lazar@msg-systems.com Java Developer @ msg systems

ragmatismul ca termen general se referă la abordarea unei sarcini într-o manieră care urmărește aspectul practic și util al abordării, pentru a o face cât mai eficientă. În domeniul programării, acest termen este adesea cunoscut sub numele de bune practici ale programării. Acestea se referă adesea la scrierea unui cod curat și gestionarea codului într-o formă cât mai eficientă, lizibilă, atât pentru persoana care scrie codul, cât și pentru persoanele care vor citi codul în viitor. Articolul de față va prezenta o serie de idei, care au ca scop îmbunătățirea modului de scriere a codului și a modului în care tratăm proiectele la care lucrăm.

Curățenie și geamuri sparte

În interiorul orașelor mari, se observă adesea cum clădiri îngrijite, în stare bună, pot sta adesea exact lângă alte clădiri, aflate întro stare foarte proastă. În urma unor studii făcute asupra vandalismului, a fost elaborată ”teoria geamului spart”, care spune că de la un singur geam spart lăsat nereparat într-o clădire foarte îngrijită, clădirea respectivă poate ajunge în termen de doar câteva luni să fie într-o stare foarte proastă. Respectivul geam spart lăsat nereparat redă locuitorilor din acea clădire, precum și celor din vecinătate, o senzație de abandon, nepăsare, neîngrijire. Așa se mai ajunge la încă un geam spart în scurt timp, care duce la o ușă de la intrare spartă, la graffiti și la probleme structurale mai avansate. Această teorie a fost folosită din anii 80’ în statele americane pentru a reduce rata de vandalitate și a îmbunătăți nivelul de trai al locuitorilor orașelor mari. Aplicată în mediul software, teoria aceasta încurajează evitarea lăsării ”geamurilor sparte” în crearea codului. Aceasta se poate referi la o porțiune de cod neimplementată, la anumite funcționalități lăsate în urmă, sau la o porțiune a unei pagini

web lăsate incompletă. Oricare din acestea, odată cu lansarea și folosirea produsului, vor lăsa un gust amar utilizatorului care va folosi respectivul produs și se va lovi de un zid atunci când va dori să acceseze anumite funcționalități care fie vor funcționa eronat, fie vor produce un crash. Astfel, se încurajează o grijă pentru detaliu în realizarea unui proiect, pentru a nu lăsa astfel de elemente incomplete în urmă. Dacă, din lipsă de timp, se întâmplă să trebuiască să lăsăm anumite funcționalități neterminate pentru a trece la alte sarcini mai urgente, se încurajează să ”baricadăm” geamul lăsat în urmă. Acest lucru se poate realiza prin comentarea codului care altfel ar returna o eroare sau un crash, prin înlocuirea cu dummy-data, hardcodare sau simpla afișare a unui mesaj de ”Under construction”.

Duplicare

Duplicarea codului este o problemă ce apare în orice proiect, uneori datorită unei singure persoane care lucrează pe proiect, alteori datorită mai multor persoane, prin lipsă de comunicare. Câteva ponturi pentru a evita această problemă sunt:

www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare Pragmatism în programare • Documentarea codului, prin comentarii sau documentație; • Comunicarea mersului și a problemelor apărute, fie în formă personală, prin ședințe periodice, fie în mediu virtual, prin descrierea problemelor într-un mediu centralizat; • Implementarea unui comportament generic, reutilizabil pentru mai multe tipuri de obiecte.

Ortogonalitate.

Conceptul de ortogonalitate se referă la împărțirea unei aplicații în componente cât mai independente. Se încearcă evitarea creării unei metode sau clase care se ocupă de prea multe sarcini. În cazul unei metode, fiecare ar trebui să aibă un singur rol, scop sau comportament, iar în cazul unei clase, aceasta ar trebui să se ocupe de un singur tip de comportament sau scop. Atunci când componentele sunt izolate una față de cealaltă, problemele ce apar ulterior sunt detectate mult mai ușor, iar comportamentul lor este mult mai ușor de a fi înțeles și modificat.

CONFERENCE2014

Îndeajuns de bun

Adeseori, în situațiile de realizare a unui proiect la care s-a acordat timp insuficient, se propune utilizarea noțiunea de good-enough software. Această noțiune propune o implicare mai mare a utilizatorului, sau end-user-ului în realizarea de software, pentru a evalua mai în detaliu cât de rafinat dorește acesta ca produsul să fie, în comparație cu cât de repede să fie livrat. Se pot întâmpina cazuri în care utilizatorul să dorească un produs livrat rapid, cu funcționalitățile de bază, la care să se poată aduce schimbări și îmbunătățiri cu timpul.

Contracte

Societatea a trebuit, în ultimii ani, să găsească o formă de a rezolva și de a face cât mai eficiente tranzacțiile desfășurate. Dintre soluțiile găsite pentru aceste lucruri, se pot aplica unele și în scrierea de cod. Una din cele mai bune soluții pentru a asigura o tranzacție eficientă o reprezintă scrierea unui contract bun sau a unor specificații tehnice dezvoltate de către și pentru persoanele tehnice care se ocupă de proiect, opțional cu ajutorul persoanelor din domeniul business care se ocupă de proiect. Acest concept a fost dezvoltat de către Bertrand Meyer, pentru limbajul de programare Eiffel. Este o metodă simplă și puternică ce presupune căderea asupra unui acord și documentarea comportamentului și a obligațiilor modulelor unui proiect, pentru a asigura funcționarea eficientă și corespunzătoare. Astfel, scopul final este de a ajunge la un program care face exact ceea ce se dorește original să facă, nici mai mult, nici mai puțin. Fiecare parte a programului, oricât de mare sau mică, are un scop de îndeplinit. Astfel, aceste scopuri și așteptări pot fi împărțite în următoarele categorii: • Precondiții se referă la datele de intrare. • Postcondiții desemnează datele produse sau acțiunile care se garantează că vor fi efectuate. • Invariante denumesc elementele care se pot modifica în timpul rulării porțiunii de cod din contract, dar care vor avea

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

aceeași valoare după rulare.

Cunoașterea IDE-ului.

Fiecare programator își realizează munca prin intermediul unui limbaj de programare. Cu cât mai bine își cunoaște limbajul de programare ales, cu atât mai bine își poate face munca. Codul realizat cu acest limbaj de programare este scris prin intermediul unui IDE (Integrated development environment). Fiecare IDE oferă o gamă de posibilități pentru asistarea în scrierea de cod. Este astfel de o importanță și utilitate ridicată, să cunoaștem bine mediile de programare în care lucrăm. O cunoaștere bună a IDE-ului poate ușura cu mult sarcinile care trebuie făcute. O primă temă de aprofundare în oricare mediu de programare sunt scurtăturile de la tastatură. A ști să lucrăm într-un IDE fără a folosi mouse-ul îmbunătățește cu mult modul și viteza de lucru. Scurtăturile de bază într-un IDE, care pot elimina nevoile unui mouse, sunt în număr de aproximativ 10 pentru un IDE standard precum Eclipse.

Comunicare

În domeniul programării, comunicarea este un element cheie în munca de zi cu zi. Aceasta se realizează fie cu clienții, fie cu colegii, fie cu mașinăriile, prin scrierea de cod. Este important

TODAY SOFTWARE MAGAZINE să știm să comunicăm cât mai eficient. Aici sunt o serie de idei scurte despre comunicarea în mediul dezvoltării software: • Să ne organizăm ideile înainte de a le comunica. Să formulăm anterior ceea ce dorim să spunem, fie că acest lucru va fi pe cale scrisă, într-o ședintă, sau într-o întrebare adresată colegului de birou. • Să ne cunoaștem publicul. Odată cu ideile formulate, trebuie să avem în vedere și cui sunt adresate ideile respective. În mediul realizării unui proiect, fiecare parte va privi altfel problema adusă în față. Cineva din management, de exemplu, va privi altfel o problemă, și va avea nevoie de explicații diferite decât cineva de pe latura tehnică. • Să ne alegem bine momentul. Pauzele de masă nu sunt întotdeauna un moment bun pentru a discuta despre problemele apărute în proiect. • Să prezentăm într-o manieră agreabilă ceea ce dorim să comunicăm. Dacă apelăm la forma scrisă, să fim siguri că este un mail bine scris, iar dacă este în formă orală, să fie comunicat coerent. • Să ținem cont de feedback. Se poate întâmpla ca răspunsul primit să nu fie ceea ce doream să auzim.

• Limbaje de programare; • Cărți tehnice; • Cărți non-tehnice (management, finanțe, auto-dezvoltare, etc.); • Evenimente, prezentări din domeniu; • Publicații, reviste, site-uri de știri tehnice; • Mentori, pentru a cere sfaturi și sugestii. În acest articol sunt prezentate doar câteva idei asupra îmbunătățirii muncii depuse în domeniul software într-o manieră pragmatică. Sunt idei accesibile, de care este important să ținem cont pentru a ne putea face cât mai bine munca și a avea cât mai multe rezultate bune.

Bibliografie The Pragmatic Programmer: From Journeyman to Master – Andrew Hunt, David Thomas http://www.manhattan-institute.org/pdf/_atlantic_monthly-broken_windows.pdf

Geanta de cunoștințe

Odată cu trecerea timpului, limbajele de programare sunt actualizate, ameliorate sau chiar înlocuite. Fiecare limbaj are propriile sale caracteristici, avantaje și dezavantaje. Proiectele și produsele noi de pe piață cer cunoașterea limbajelor de programare actuale, adaptate nevoilor de performanță actuale. Este astfel necesară menținerea unui bagaj de cunoștințe actualizat periodic. Menținerea unui astfel de portofoliu poate fi comparată cu menținerea unui portofoliu financiar. Astfel avem o serie de idei aplicabile pentru ambele tipuri de portofolii: • Investițiile să fie făcute periodic și constant, pentru a se forma un obicei; • Diversificarea investițiilor. Cu cât cunoștințele unei persoane sunt mai variate, cu atât acea persoană este mai valoroasă; • Echilibrarea investițiilor, între cele sigure, cu dobândă joasă, și cele riscante, cu dobândă ridicată. Tehnologiile noi ar fi investiții riscante, însă în cazul în care ar dobândi popularitate, dacă sunt puține persoane care cunosc o tehnologie nouă, aceste persoane sunt cu atât mai importante pentru un proiect; Revizuire și reactualizare periodică. Odată la câteva luni, în urma analizelor făcute, putem constata dacă investițiile noi mai prezintă potențial de dezvoltare sau dacă sunt altele cu un potențial mai ridicat. Idei de investiții:

www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare

Clean code – Funcții

n ultimul articol din TSM, am descoperit împreună universul codului curat, prin ,,Clean Code” scrisă de Robert C. Martin. Am avut ocazia să aprofundăm subiectul denumirilor și să vedem cât de ușor pot lucrurile mici precum numele funcțiilor sau al variabilelor să îmbunătățească calitatea și lizibilitatea codului însuși.

Astăzi vom plonja mai adânc în Clean Code și vom discuta despre funcții (,,Functions”). Acest mecanism simplu și de bază folosit pentru a scrie programe poate avea un impact nu numai asupra ușurinței cu care poate fi întreținut și extins un program, ci și asupra sănătății mintale a dezvoltatorilor. Nu uitați că metodele lungi vă vor face ochii să lăcrimeze. Imaginați-vă o carte în care toate paragrafele sunt amestecate, mărimea caracterelor este diferită pentru fiecare dintre ele și o parte din ele au 20 de pagini. Cât de ușor ați putea citi această carte? Codul ar trebui să fie scris într-un fel care să ofere oamenilor șansa de a-l citi ca pe o carte, de la început până la sfârșit, în care fiecare logică diferită este grupată separat.

O poveste veselă

Îmi amintesc o dată când a trebuit să extind un cod existent scris de altcineva. Când am deschis soluția am găsit o singură clasă, cu 2 sau 3 metode, care avea în total în jur de 4.000 linii de cod. Estimările mele pentru sarcina aceasta au fost: • 4 zile de restructurare, • 1 z i p e nt r u a a d ău g a n o u a funcționalitate. Managerul meu de proiect de la acea vreme a acceptat această estimare și mi-a dat undă verde pentru a lucra la el. Dar în final, am avut nevoie de 4x mai mult timp pentru a îndeplini sarcina, deoarece metodele în sine erau prea lungi și nu am putut face nimic fără a avea coșmaruri noaptea. Așadar ce putem face pentru a îmbunătăți calitatea dezvoltatorilor și a software-ului nostru din perspectiva funcțiilor/ metodelor?

Să fie scurte

Aceasta este prima și cea mai importantă regulă legată de funcții. Ar trebui să le păstrați cât mai scurte posibil. Explicația este destul de simplă: o funcție scurtă va face mai puțin (numai un singur lucru simplu). În plus de asta, va fi mai ușor de înțeles și de lucrat cu ea. Întrebarea normală care ne vine în minte este ,,Cât de scurte?” 100 de linii? 50 de linii? 10 linii? 5 linii? Din păcate, nu putem avea un număr magic cum ar fi 5 sau 20, pentru că este destul de greu să generalizezi. Lungimea unei metode depinde de factori multipli, cum ar fi convențiile codului. De exemplu, cât de des apeși enter pentru a adăuga o nouă linie (pentru fiecare ‘{‘ sau pentru fiecare afirmație logică și așa mai departe). În general, dacă sfârșești prin a avea o metodă mai lungă de 10 – 15 linii de cod, atunci ar trebui să arunci o privire peste ea ca să vezi de ce este așa de lungă. Este din cauza convențiilor codului sau din cauză că există prea multă logică acolo?

Blocuri și indentare

În legătură cu IF(dacă), ELSE (alt), WHERE (unde), REPEAT (repetare)și alte astfel de funcționalități, nu ai vrea să te trezești cu un IF de 10 linii. Ar fi destul de greu de citit și de înțeles. Pentru astfel de cazuri, ar trebui să extragi controlul (check) într-o funcție diferită și să îl apelezi din comanda IF. Aplicând această regulă, veți avea comenzi ca IF sau WHERE care necesită numai o singură linie de cod. Mai mult, vă veți îmbunătăți lizibilitatea și documentația codului. Pentru dezvoltatori va fi foarte ușor să înțeleagă ce

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

face codul și ce ar trebui să facă controlul din spatele acelui IF sau WHERE.

Un singur lucru de făcut

Dacă citești o funcție lungă, îți dai seama că face mai mult de un lucru acolo. De exemplu, în aceeași funcție deschizi conexiunea DB, execuți o cerere, transformi rezultatul într-un alt tip și te ocupi de cazurile speciale. Fiecare dintre lucrurile acestea ar trebui făcute separat. De aceea o funcție ar trebui să facă numai un singur lucru. Dacă ai nevoie să faci mai mult de un lucru, atunci ar trebui să le împarți în funcții separate. Chiar dacă afirmația este atât de simplă, este destul de dificil să faci asta. Dacă descoperiți într-o funcție părți diferite ale codului care sunt grupate sau dacă puteți extrage o parte din aceasta într-o funcție separată cu un nume care are sens, atunci funcția face mai mult decât un singur lucru.

Un nivel de abstracție per Funcție

Acesta poate fi un mecanism care ne poate spune că funcția face prea multe lucruri. De exemplu, o funcție care procesează o entitate și de asemenea începe să se dividă în interior și să transfere unul dintre câmpurile entității, are mai mult de un nivel de abstracție. Este destul de clar că ar trebui să extragi procesarea în lanț într-o altă funcție. În acest fel, fiecare funcție va avea un singur nivel de abstracție. Comanda Switch Povestea legată de comenzile switch este destul de lungă și vom vorbi despre ea cu altă ocazie. În cazul nostru, ar trebui să extragem logica din fiecare CASE pentru a separa funcțiile. Chiar dacă facem acest lucru, nu va fi ok, deoarece încălcăm

TODAY SOFTWARE MAGAZINE principiul unicei responsabilități (Single Responsibility Principle). Noi ar trebui să înlocuim comanda switch cu polimorfismul. Aceasta este soluția perfectă, dar există cazuri în care o astfel de soluție ar aduce în plus prea multă complexitate. Când este nevoie să folosești o comandă switch, ar trebui să o ascunzi cât de adânc posibil; în Clean Code, recomandarea este în spatele unui factor abstract.

Utilizați denumiri descriptive

Numele unei funcții ar trebui să descrie exact ceea ce face. Nici mai mult, nici mai puțin. De exemplu, o funcție cu nume precum DO, ACTION nu ne ajută prea mult, pentru că nu știm care este scopul lor. Un nume ca, TriggerDoorLock (Declanșează blocare ușă) ne oferă toate informațiile de care avem nevoie pentru a știi ce face aceea funcție. Găsirea unei denumiri bune este destul de dificilă și poate însemna un consum mare de energie. În plus, trebuie să fiți constanți și să încercați să utilizați același model de denumire atunci când există similarități.

Argumentele funcției

Câte argumente ar trebui să aibă o funcție? Cea mai bună valoare este 0, dar acest lucru nu este posibil întotdeauna. De fiecare dată când adăugați un argument nou, gândiți-vă la rolul său. Când ajungeți să aveți mai mult de 3-4 argumente, poate că ceva e greșit. Ar trebui să le revizuiți și să vedeți dacă nu puteți muta funcția într-o altă locație sau să adăugați un alt nivel de abstracție. Opțiunea OUT pentru argumente nu este recomandată întotdeauna și poate semnala că ceva este greșit acolo. De exemplu, metodele TryXXX verifică de obicei dacă poate fi făcută o conversie. Dacă aceasta poate fi efectuată cu succes,

răspunsul este TRUE iar parametrul out va fi 100% separată de logica ta. va conține rezultatul conversiei. Aceasta ar putea semnala că metoda face prea multe Extrageți blocurile try/catch lucruri – transformări și verificări. Un cod care conține astfel de blocuri sunt destul de urâte și lungi. Din această Fără efecte secundare cauză, toate aceste blocuri de cod ar treAceasta este situația în care funcția ta bui să fie extrase în funcții separate. Blocul face mai mult decât un singur lucru, dar TRY poate fi pus într-o funcție și blocul fără a spune clientului. De exemplu, o CATCH poate fi pus într-o altă funcție. metodă READ care citește conținutul unui fișier și apoi îl șterge fără a notifica utiliza- Nu vă repetați torul. În acest caz, utilizatorul ar trebui să Tot codul care este duplicat ar trebui fie înștiințat despre această acțiune sau, cel extras într-o funcție separată. Nu doar veți puțin, ar trebui să știe de ea din momen- reduce numărul de linii de cod, dar vă veți tul în care face apelarea - ReadAndDelete și ușura viața atunci când va fi nevoie să se (Citește și șterge). facă o modificare. Este mai ușor să modiDin cauza acestor efecte secundare, fici numai o linie de cod decât să cauți și să putem avea cuplări temporare. De exem- modifici toate locațiile în care codul este plu, când funcția GoLeft poate fi apelată duplicat. numai dacă a fost apelată StartEngine. Ar trebui să vă gândiți la o modalitate Lucruri mărunte de a expune numai metodele care sunt După cum puteți vedea, lucrurile disponibile la un anumit moment, fără mărunte pot face o mare diferență între o a crea cuplări temporare. De exemplu, funcție bună și una proastă. Nu este nevoie StartEngine poate returna un obiect care să faci sau să știi te miri ce nebunii pentru are numai comenzi ca GoLeft, GoRight, a fi capabil să scrii funcții „fericite”. Ținând etc. cont de aceste recomandări veți putea scrie un software mai bun, care peste 10 ani va Comandați separarea cererii fi întreținut mai ușor și cu mai puțini bani. O funcție ar trebui să facă numai un singur lucru. Nu ar trebui să aveți niciodată metode care să execute o cerere și în același timp o comandă. Aceste două acțiuni trebuie să fie separate întotdeauna, fără excepție.

Preferați excepțiile și nu erorile de cod

Producerea unui cod eronat generează două lucruri în plus de care trebuie să se ocupe dezvoltatorul/ clientul. El trebuie să cunoască harta fiecărui cod greșit și în același timp trebuie să verifice codul eronat produs. Pentru aceste cazuri, proiectarea unei excepții este mai bună și va simplifica munca clienților. În plus, tratarea erorilor

Radu Vunvulea

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

www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare

Integrarea client server cu ajutorul RestKit

n momentul de față există foarte multe servicii web la care te poți conecta pentru a obține date folositoare. De exemplu Instagram, Twitter pentru imagini sau tweeturi sau în cazul meu personal Foursquare, de unde pot obține o listă cu barurile din zonă. În general ai putea să te conectezi direct la servicii de genul acesta cu NSURLRequest sau cu o librărie precum AFNetworking. Aici intervine RestKit, care te scutește de câteva bătăi de cap și parsări de JSON.

Ce este RestKit?

RestKit este un framework Objective-C al cărui scop e ușurarea interacțiunilor cu servicii web de tip RESTful . În linii mari, combină un HTTP request/respone API simplu și ușor de folosit cu un sistem puternic de mapare care reduce mult din boilerplate codeul de care ai avea în mod normal nevoie, atunci când lucrezi cu servici web. Cel mai important aspect a RestKit e ca permite developer-ului să se gândească mai mult cum să-și construiască data modelul și să-și facă mai puține griji pentru cum să trimită request-uri sau să parseze JSON și să mapeze rezultatele la obiecte native.

Ce conține?

RestKit conține un client HTTP care are la bază NSURLConnection și pune la dispoziție o librărie de metode ajutătoare pentru inspecția tipurilor MIME și a status codes. De exemplu, trimiterea datelor dintr-un form constă doar din crearea unui dicționar cu parametri. De asemenea, există și un suport simplu pentru upload-ul de fișiere mari (ex: video). Suportul la nivel de framework pentru schimbarea serverelor și a enviroment-urilor (ex: development, production) este de asemenea oferit. RestKit folosește base URL și resource paths în loc de URL-uri întregi pentru a permite schimbarea rapidă între servere. Un sistem de mapare a obiectelor. Reskit oferă un layer de modelare pentru maparea datelor procesate în obiecte native Cocoa. Nu mai trebuie să-ți faci griji pentru parsarea răspunsului JSON. Maparea obiectelor e făcută cu ajutorul a key-value coding. De asemenea, oferă integrare cu Apple Core Data framework. Acest lucru permite RestKit să păstreze obiecte ce au fost încărcate de pe un server într-o bază de date locală folosită pe post de cache sau baza de date principală sincronizată periodic cu Cloudul. Data base seeding. Când se folosește în cadrul aplicației Core Data, RestKit e capabil să populeze această bază de date locală, lucru care permite upload-area în App Store a unei aplicații cu o bază de date locală deja existentă și funcțională.

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

Integrare cu Rails. RestKit a fost construit la început ca un răspuns Objective-C la Active Resource, dar cum Rails este folosit în general pentru un backend de iOS, era și normal ca RestKit să ofere suport în acest sens.

Exemplu Voi extrage doar partea legată de RestKit din proiectul meu. Pornind de la o aplicație simplă cu o listă, pe care o vrem populată cu locațiile dorite oferite de serviciul de la Foursquare. Aceasta constă din doua view controller-e mai importante, un UITableViewController pentru listă și un UIViewController pentru detaliile fiecărei dintre locații. Nu voi intra în detalii despre cum ar trebui să se facă aceasta sau cum ar trebui să arate, deoarece nu este subiectul articolului. După ce avem proiectul pregătit, sunt două modalități de a adăuga RestKit într-un proiect: CocoaPods sau Git submodule. Din motive de simplitate și rapiditate am ales CocoaPods , instalarea pods-urilor fiind doar câteva linii de comandă în terminal: $ sudo gem install cocoapods $ pod setup $ cd /calea/catre/ProiectulVostruCuBaruriApropiate $ touch Podfile $ [edit] Podfile (using your preferred editor; vim, nano, etc) platform :ios, ‘5.0’ pod ‘RestKit’, ‘~> 0.20.0’ $ pod install

Nu în ultimul rând, înainte de a putea folosi APIul, trebuie să înregistrăm aplicația pe https://foursquare.com/developers/apps. Mai multe detalii despre serviciul folosit găsiți pe https://developer.foursquare.com/docs/venues/search. De aici veți avea nevoie de client ID și client secret, pe care le puteți adăuga în proiect sub formă de macros #define kCLIENTID @»Your Foursquare Client ID» #define kCLIENTSECRET @»Your Foursquare Client Secret»

După ce ați făcut setup-ul și toți pașii ceruți, puteți testa serviciul și observa că în răspunsul serviciul veți avea cam

arhitectură

TODAY SOFTWARE MAGAZINE

întotdeauna un JSON de genul : {

“meta”: { “code”: 200 }, “notifications”: [ { “item”: { “unreadCount”: 3 }, “type”: “notificationTray” } ], “response”: { “confident”: true, “neighborhoods”: [], «venues»: [ { “categories”: [ { “icon”: { “prefix”: “https:// ss1.4sqi.net/img/categories_v2/food/bar_”, “suffix”: “.png” }, “id”: “4bf58dd8d48988d1e0931735”, “name”: “Bar”, „pluralName“: “Bars”, “primary”: true, „shortName“: “Bar” } ], “contact”: { “formattedPhone”: “(408) 4469000”, «phone»: “4084469000”, “twitter”: “jackslongdrinks” }, “hereNow”: { “count”: 0, “groups”: [] }, “id”: “51630409498eedc7dd88e60b”, “location”: { “address”: “20686 Stevens Creek Blvd”, “cc”: “US”, “city”: “Cupertino”, “country”: “United States”, “crossStreet”: “De Anza Blvd”, “distance”: 936, “lat”: 37.32246179607897, “lng”: -122.03470838696346, “postalCode”: “95014”, “state”: “CA” }, “name”: “Jacks Cocktails”, “referralId”: “v-1390061483”, “specials”: { “count”: 0, “items”: [] }, ”stats”: { “checkinsCount”: 3790, “tipCount”: 40, “usersCount”: 1460 }, “verified”: true }, { “categories”: [ { “icon”: { “prefix”: “https:// ss1.4sqi.net/img/categories_v2/food/bar_”, “suffix”: “.png” }, “id”: “4bf58dd8d48988d1e0931735”, “name”: “Bar”, „pluralName“: “Bars”, “primary”: true, „shortName“: “Bar” } ], “contact”: { “formattedPhone”: “(650) 3212161”, «phone»: “6503212161”,

}

]

}

“twitter”: “downtown_coffee” }, “hereNow”: { “count”: 0, “groups”: [] }, “id”: „4dd1580eb3adb047f5024231“, “location”: { “address”: “101 Forest Ave”, “cc”: “US”, “city”: “Palo Alto”, “country”: “United States”, “crossStreet”: “at Alma St.”, “distance”: 17063, “lat”: 37.442086282055726, “lng”: -122.16159119091502, “postalCode”: “94301”, “state”: “CA” }, “name”: “Downtown Coffee”, “referralId”: “v-1390061483”, “specials”: { “count”: 0, “items”: [] }, ”stats”: { “checkinsCount”: 14168, “tipCount”: 118, “usersCount”: 4044 }, “verified”: true

Partea de cod

Acum că avem toate piesele la un loc, putem începe să construim aplicația. Pentru acest articol ne vom lega doar de două componente mari ale RestKit: Network și Object Mapping. Pentru Network, definim baza URL-ului pentru API-ul Forsquare (https://api.foursquare.com) și trimitem/primim mesajele. Pentru Object Mapping vom defini un model pe care îl vom mapa la valorile JSON returnate de către serviciu. După ce examinăm un pic JSONul de mai sus, putem crea o clasa Locatie care să extindă NSObject. De dragul simplității, pentru moment, îi adăugăm o singură proprietate: @interface Venue : NSObject @property (nonatomic, strong) NSString *name; @end

Și importăm clasa nou creată și RestKit în view controller-ul principal. #import <RestKit/RestKit.h> #import “Locatie.h”

Adăugăm o metodă de configuarare a RestKit și una de încărcare a locațiilor într-una din metodele de lifecycle, de preferat viewDidLoad. - (void)viewDidLoad { [super viewDidLoad]; [self configureRestKit]; [self loadVenues]; }

După care creăm și metodele în sine : - (void)configureRestKit { // initialize AFNetworking HTTPClient NSURL *baseURL = [NSURL URLWithString:@»https:// api.foursquare.com»]; AFHTTPClient *client = [[AFHTTPClient alloc] initWithBaseURL:baseURL]; // initialize RestKit RKObjectManager *objectManager = [[RKObjectManager alloc] initWithHTTPClient:client]; www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare RestKit pentru iOS

// setup object mappings RKObjectMapping *venueMapping = [RKObjectMapping mappingForClass:[Venue class]]; [venueMapping addAttributeMappingsFromArray:@ [@”name”]]; // register mappings with the provider using a response descriptor RKResponseDescriptor *responseDescriptor = [RKResponseDescriptor responseDescriptorWithM apping:venueMapping method:RKRequestMethodGET Pattern:@”/v2/venues/search”

path-

keyPath:@»response.venues» statusCodes:[NSIndexSet indexSetWithIndex:200]]; [objectManager addResponseDescriptor:responseDes criptor]; }

În metodă, definim baza URLului despre care vorbeam și mai devreme, pentru APIul Forsquare. Toate request-urile vor fi legate de acest URL. Clasa RKObjectManager definește maparea dintre un atribut JSON și atributul corespunzător din data model. addAttributeMappingsFromArray este o metodă care se poate folosi în cazul în care JSONul și modelul au aceleași chei, în cazul nostru “name”. Pe urmă creăm un RKResponseDescriptor, care descrie o mapare a unui obiect care este aplicabilă unui răspuns HTTP. pathPattern este comparat cu URL-uri pentru care maparea ar trebui folosită. keyPath:@“response.venues” e folosit de RestKit pentru a găsi obiectele pentru locație. - (void)loadVenues { NSString *latLon = @”37.33,-122.03”; // aici putem sa trecem locatia noastra curenta NSString *clientID = kCLIENTID; NSString *clientSecret = kCLIENTSECRET; NSDictionary *queryParams = @{@”ll” : latLon, @”client_id” : clientID, @”client_secret” : clientSecret, @”categoryId” : @”4bf58dd8d48988d1e0931735”, @”v” : @”20140118”}; [[RKObjectManager sharedManager] getObjectsAtPath:@”/v2/venues/search” parameters:queryParams success:^(RKObjectRequestOpe ration *operation, RKMappingResult *mappingResult) { _venues = mappingResult.array; [self.tableView reloadData]; } failure:^(RKObjectRequestOpe ration *operation, NSError *error) { NSLog(@“Din pacate nu sunt baruri in zona…’: %@”, error); }]; } @interface MasterViewController () @property (nonatomic, strong) NSArray *venues; @end

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

@implementation MasterViewController - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { UITableViewCell *cell = [tableView dequeueReusabl eCellWithIdentifier:@”Cell” forIndexPath:indexPath]; Venue *venue = _venues[indexPath.row]; cell.textLabel.text = venue.name; return cell; }

E o librărie folositoare cu care practic am redus tot codul necesar pentru parsare, mapare și încărcare în cele două metode scurte menționate mai sus. De aici putem dezvolta modelul și să avem mai multe atribute. În final, lăsând la o parte detaliile precum harta și butoanele de navigare, ar trebui să avem o listă ca în imagine, funcțională, cu barurile din jurul nostru.

Mihai Fischer

mihai.fischer@gmail.com iOS developer @ Dens.io

evenimente

TODAY SOFTWARE MAGAZINE

Cum poți testa conferințe de testare

ouă conferințe de testare internaționale și destul de cunoscute la care am participat au fost Eurostar în 2012 și 2013 (în Amsterdam și Göteborg) și CAST în 2014 (în New York). Cu experiența de la CAST încă proaspătă, am ajuns la concluzia că a merge la astfel de evenimente e o ocazie bună pentru a avea o experiență benefică.

Când particip la un astfel de eveniment, există șanse mari să mă aflu într-un perimetru cu o densitate mare de oameni pasionați de ceea ce fac, cărora le place testarea, care caută moduri de a-și îmbunătăți munca și care sunt deschiși să împărtășească experiențele lor. Interacțiunea cu astfel de oameni e în majoritatea cazurilor valoroasă. Uneori se ivesc idei pe care încerc să le aplic de cum mă întorc. Alteori influența participării nu e atât de directă. Există și o influență mai subtilă. Ajungând să discut cu oameni pe care îi știam numai de pe Twitter și din line-up-ul conferințelor am ocazia să mă expun la idei care modelează abordarea mea în testare. Și influența nu apare din faptul că am vorbit cu oameni ‘faimosi’. Concepte cum ar fi gândirea critică, testarea exploratorie, euristici, „leaky abstractions”, „game of life”, sisteme “intractabile“, reificare, presupuneri latente, și multe altele sunt prezente. Conferințele sunt un spațiu în care am ocazia să îi provoc și să le pun întrebări oamenilor care vorbesc despre ele și le stăpânesc, pentru a înțelege mai bine și a internaliza semnificația lor. Una din părțile mele preferate este spațiul în care am ocazia să exersez testarea. Există la EuroSTAR un TestLab puternic, cu multe provocări și exerciții din care să aleg, inclusiv sesiuni

practice cu prezentatori. Acolo am încercat să găsesc modele în comportamentul roboților de la Lego, sau al puzzle-urilor de testare exploratorie ale lui James Lyndsay și am testat aplicații open source. Uneori lucrez la ele singură, alteori prefer să colaborez cu oamenii din jurul meu. Am văzut abordări foarte interesante în rezolvarea problemelor. Am văzut cum alții structurează informațiile. Făcând debriefing și rapoarte, am înțeles cum au gândit alții soluții la provocări. La CAST am participat la competiția de testare, un interval de două ore în care scopul era să colaborez cu coechipierii (oameni pe care nu îi știam de dinainte și cu care nu mai lucrasem) pentru a găsi buguri și a crea un raport bun. Așa că, deși în principal spații de socializare, aceste conferințe oferă și contexte în care să exersezi testarea și să înveți din abordările altora. Și EuroSTAR și CAST oferă un atelier de o zi întreagă, care presupune să mă concentrez pe o temă și să o tratez în profunzime. Până acum am participat la sesiuni practice, în care am avut ocazia să îmi pun mintea la contribuție. Discuțiile de la berea de după programul conferinței nu sunt deloc de ignorat. Și nu numai pentru că barurile au bere bună. Pentru mine au fost ocazii bune de a avea discuții degajate în care să cunosc mai bine oamenii cu care împart plăcerea pentru testare. Mi se pare relevant să aflu cum au ajuns alții să testeze, prin ce experiențe au trecut, ce vor să îmbunătățească și ce opinii au. Posibilitățile legate de importanța, contextul și diversitatea muncii pe care o fac devin brusc mult mai multe! Din cele trei participări ale mele, două au fost în rolul de prezentator. Așa că în continuare vreau să împărtășesc câteva din lucrurile folositoare, și uneori total neașteptate, cu care am rămas din acest tip de experiențe și să arăt de ce cred că participarea ca prezentator poate fi mai interesantă decât participarea simplă și fără griji. www.todaysoftmag.ro | nr. 27/septembrie, 2014

evenimente Cum poți testa conferințe de testare Prezentatul la conferințe

Vorbitul în public. Wow. Când e vorba de a-ți da cu părerea, se găsește mereu în jur cineva cu o opinie puternică, care nu se poate abține să-și exprime ideile și să acapareze discuția. Lumea asta e plină de oameni care au ceva de zis. Sau oameni cărora pur și simplu le place să se audă vorbind, care folosesc cuvinte strălucitoare ca să spună...nimic. N-ai vrea să fii unul dintre aceia, nu? Vorbitul în public poate fi despre asta. Poate fi și despre multe altele, după cum am observat din experiențele pe care le-am avut recent. Să vă spun câteva cuvinte despre activitatea mea principală. Eu testez software. Adică dedic mare parte din zi unei activități intelectuale de investigare tehnică și empirică a produsului la care contribui și analizez critic ideile care conduc procesul de dezvoltare software. Da, activitatea mea e parte din procesul de dezvoltare. Pun la îndoială deciziile luate în echipă, ca parte din procesul de design al produsului. Da, activitatea mea e parte din designul produsului. Zona în care operez e în aria ingineriei, fiindcă folosesc euristici ca să produc cea mai bună schimbare în condiții de incertitudine și resurse limitate. Da, activitatea mea ține de inginerie. Produsul activității mele e informație pe care o transmit oamenilor care au putere de decizie și interese în proiect. Pentru mine asta nu sună exact ca descrierea unui om care vorbește des în public. Totuși, m-am descurcat și cel mai miraculos e că am supraviețuit.

prima. Cu și mai mulți oameni în public și așteptări mari. De atunci am mai vorbit de câteva ori și am avut ocazia să experimentez situații noi de fiecare dată. Am avut chiar experiența în care un om din public ațipea în timpul prezentării (doar o singură dată până acum, din fericire). Nu pot spune că am o experiență vastă, însă experiențele pe care le-am avut mi-au dat ocazii destule să învăț lucruri. Câteva lucruri interesante pe care le-am descoperit:

Exprimarea clară nu e trivială

Pentru pregătirea prezentărilor, mi-am făcut un obicei din a ține prezentarea pentru oameni apropiați, într-un mediu asemănător cu cel al prezentării reale. Ideea e să țin prezentarea ca și cum aș fi la conferință. Deși repet în capul meu înainte, sau repet fragmente în fața unor oameni, sau le povestesc rezumatul prezentării, mi-am dat seama că nu e prea asemănătoare experiența cu încercarea să prezint cap-coadă ca și cum aș fi la prezentarea reală. Doar atunci realizez că ceea ce vreau să transmit nu se potrivește cu ceea ce exprim uneori. Exercițiul de forma aceasta mă ajută să îmi dau seama ce idei aș vrea să subliniez mai mult, la ce detalii pot renunța, sau ce detalii lipsesc ca să exprim clar o idee. Pentru ultima prezentare la care am lucrat, am fost uimită de cât de neclare erau concluziile de la final atunci când încercam să le articulez, deși în mintea mea păreau că au sens. Faptul că am descoperit asta înainte de a ține prezentarea la conferință a fost de ajutor. Am avut destul timp să le revizuiesc și să le clarific. Această perspectivă îmi sugerează că poate nu sunt singura care nu se exprimă clar din prima. Nu avem mereu timp pentru Oare cum am ajuns eu să prezint? repetiții cu orice vrem să spunem. Mi-am dat seama că e folositor Răspunsul la întrebarea aceasta nu e unul foarte clar nici pen- să țin cont de asta în unele cazuri când particip la ședințe/discuții tru mine. și să amân să judec ce a spus o persoană până când am pus întreÎncurajarea de la oamenii din jur cred că a contat. Un coleg bările clarificatoare care să mă asigure că era într-adevăr ce vroia de muncă și apoi Test Managerul cu care lucrez m-au încurajat să să transmită. aplic să vorbesc la conferințe de testare. Chiar și după prima oară când nu mi-a fost acceptată aplicația. Îmi surâdea ideea pentru că Lucrând la prezentări învăț să construiesc argumente puternice era o ocazie să particip la conferință, cu costuri reduse. Când vreau să afirm ceva într-o prezentare, mă gândesc că fieÎnainte de prima prezentare pe care am ținut-o, la EuroSTAR care idee e susceptibilă la diferite reacții ale oamenilor din public. în 2013, experiența mea consta în mare parte din reprezentații Pentru că nu aș vrea să par superficială și să fiu surprinsă de un la serbări școlare de final de an și susținerea lucrării de licență. contraargument valid (din seria cine ar vrea, și totuși, cui nu i Mai vorbisem la un eveniment local de testare, dar arătam câteva se întâmplă), mă gândesc în ce fel aș putea invalida ipoteza mea exerciții de la un atelier la care participasem, deci nu era conținutul și încerc să îmi construiesc argumente pentru diferite feluri de meu. În rest nu mai avusesem un public foarte numeros și un reacții. cadru formal până atunci (cel puțin din câte îmi amintesc, așa că Asta mă determină să analizez cât de clară e gândirea mea și dacă am ceva amintiri să răspund la posibile întrebări din public înaintea prezentării. E reprimate, vă rog să-mi un exercițiu bun pentru a-mi contura argumentele pe care le am înțelegeți omiterea). și pentru a le îmbunătăți. Norocul a făcut ca Îmi amintesc că la una din prezentări încercam să identific prezentarea mea de la motive pentru care nu găsisem în timp util buguri relevante EuroSTAR să fie destul pentru o funcționalitate. Faptul că am pus sub semnul întrebării de populară, așa că am concluziile mele și am încercat să găsesc contraargumente m-a mai ținut-o încă o data ajutat să ajung mai în profunzimea situației și să găsesc argumente în aceeași zi, la sesiu- puternice pentru nevoia de comunicare eficientă și colaborare, nea numită do-over”, pentru euristica de a evidenția în rapoarte și zonele pe care nu în care se relua pre- le-am acoperit în timpul testării, pentru relevanța cunoașterii zentarea cea mai votată informațiilor contextuale care provin din buguri raportate în alte din timpul conferinței. zone decât cele pe care mă concentrez eu, precum și importanța Așa am avut și a doua grupării informației în categorii potrivite și accesibile. experiență de vorbit în public la conferințe de Pregătirea prezentărilor mă ajută la clarificarea unor idei testare, în aceeași zi cu Aspectul anterior aduce un alt beneficiu. Căutând să îmi

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Ce e interesant pentru public

întăresc argumentele, lucrez și la clarificarea concluziilor pe care le trag. Nu o singură dată m-am răzgândit în privința ideilor pe care vreau să insist într-o prezentare. Schimbarea de focus mie îmi arată că am înțeles dintr-o altă perspectivă situațiile pe care le-am analizat. Și înțelegerea pe care am dobândit-o o pot folosi pe proiectul pe care lucrez. De exemplu, în prezentarea de la CAST m-am concentrat pe explorarea abilităților pe care le folosesc în testare. Faptul că am analizat felul în care îmi folosesc abilitățile m-a ajutat să devin mai conștientă de interacțiunea dintre ele, care pare mai relevantă decât abilitățile luate individual, atunci când evaluez eficiența în rezolvarea problemelor.

În timp ce lucram la prezentări, mă întrebam uneori dacă va fi interesant ce zic eu pentru cei din sală. Până la urmă, fac o prezentare ca să transmit altora ceva, nu o fac doar pentru mine. Tendința mea până acum a fost să vorbesc mult despre experiențele mele, să spun povești despre cum lucrez eu, despre ce am încercat, ce rezultate am avut și ce am învățat. Momentan cred că dacă lucrul la o prezentare mă duce la o înțelegere mai profundă a ceva legat de cum testez, cum aș putea să abordez problemele pe care vreau să le rezolv, și e bazat pe ceva ce eu am experimentat, există șansa să aibă valoare pentru altcineva. Poate nu în același fel, poate în cu totul alt context. Dar oamenii se lovesc de probleme destul de similare, dacă trăiesc în medii de aceeași natură. Chiar dacă eu nu găsesc soluții, inițiativa de a trata o problemă poate să îi încurajeze pe alții să caute soluții potrivite pentru ei. Așa că întrebarea asta nu mă mai bântuie atâta timp cât tema despre care vreau să vorbesc e de real interes pentru mine și cred că mă poate ajuta pe mine în vreun fel. Euristica pe care o folosesc acum e că orice e de interes profund pentru mine poate să îi intereseze și pe alții. După asta mă ghidez în alegerea temelor și în căutarea de motivație de prezentator. Toate aceste argumente funcționează pentru mine ca să vreau să particip la astfel de evenimente și să prezint. Poate că tu ai găsit sau vei găsi alte lucruri de valoare. Te invit să le împărtășești sau să le cauți.

Motivele pentru care merită să prezinți pot fi multe Aș putea să scriu în detaliu și despre altele: Faptul că fac o prezentare mă motivează să analizez critic evenimentele și deciziile pe care le iau. Faptul că atunci când creez prezentări, lucrez la construirea unor povești convingătoare și consistente. O abilitate pe care o pot folosi și atunci când povestesc despre procesul meu de testare oamenilor din echipă. Deși spun aici „povesti”, nu mă refer la sensul de „invenţii”, ci de „relatări”. Am descoperit că în activitatea mea e folositor să pot oferi o relatare congruentă a ceea ce am făcut și de ce. Prezentând informațiile într-un mod eficient, clar, e mult mai probabil ca aceste informații să ajungă la oamenii care au nevoie de ele și să fie interpretate corespunzător. Vorbind la conferințe de testare îmi exersez această abilitate. Un alt aspect este ocazia de a primi feedback, și deci de a înțelege interpretările și perspectivele altor oameni. Am descoperit și că împărtășirea experiențelor îmi aduce satisfacție pentru că îmi permite să relaționez cu alții. Deși sunt într-o poziție vulnerabilă atunci când vorbesc în fața multor oameni pe care nu îi cunosc, de multe ori ei sunt deschiși să lege propriile experiențe și cunoștințe de subiectul prezentat de mine și asta duce la rezonare mai des decât alienare. Cred că sunt multe alte motive de acest fel. Și pot să le descopăr doar prezentând din nou.

Alexandra Casapu

alexandra.casapu@altom.ro Software Tester @ Altom Consulting

www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare

diverse

Tranziția de la QA la BA

ragi colegi din IT, m-am tot gândit ce lucruri interesante să vă împărtășesc din experiența mea profesională și, din fericire, răspunsul era chiar sub nasul meu: vă voi povesti câteva episoade din viața mea de analist business care ar putea să vă ofere o mai bună înțelegere și un sprijin în munca voastră din prezent.

Monica Petraru

monica.petraru@urss.ro Senior Business Analyst @ UNIQA Raiffeisen Software Service

nr. 27/2014 | www.todaysoftmag.ro

După cum vă puteți imagina cu toții, suportul profesional este luat mereu în considerare în toată industria. Prin simpla căutare pe diverse motoare de căutare (cum ar fi Google), termenul ,,business analyst” (analist business) subliniază faptul că profesioniștii din acest domeniu sunt la mare căutare. O multitudine de joburi sunt oferite în prezent de către multe companii pentru poziția de business analyst, adică cei care funcționează drept o legătură între cei din IT și nevoile de business ale clienților lor. Noi, ca analiști de business, suntem antrenați să înțelegem cum tehnologia poate servi scopurilor în afaceri. În plus, noi, analiștii de business, suntem foarte căutați și în sectorul public și în cel privat. Pe lângă aceste nevoi apar următoarele întrebări: • Ce presupune acest rol ? • Ce aptitudini și experiență sunt necesare? • Care sunt beneficiile contractării față de asumarea unui rol permanent?

articol își propune să ofere răspunsul la această întrebare. La debutul carierei mele, am început să lucrez ca dezvoltator și tester. Mai apoi, mi s-a oferit șansa unei tranziții interesante înspre analiza de business. Primul meu gând pe care vreau să îl discut este doar un antreu. Un analist business senior din echipă m-a abordat într-o zi și a menționat faptul că exista un post liber în departament. Am fost sfătuită să aplic. Drept reacție normală la o posibilă schimbare, mi-am spus: ,,ok, această șansă pare o răsturnare de situație interesantă; ar putea fi un moment bun pentru o schimbare”. După ce m-am gândit bine câteva zile dacă mutarea la analiza de business ar fi într-adevăr o mișcare bună în carieră pentru mine sau nu, am acționat conform sfatului colegului meu și am aplicat pentru această poziție. Ca o consecință imediată, m-am trezit mutându-mă de la o echipă la alta. Bineînțeles, în realitate, procesul de tranziție spre analiza de business nu a înceAm fost întrebați mereu cum poate put prin simpla schimbare a echipelor și a cineva să treacă de la asigurarea calității domeniilor. Sunt sigură că fiecare dintre la rolul de analist business. De aceea, acest noi și-a abordat în mod inconștient rolul

TODAY SOFTWARE MAGAZINE de QA (asigurarea calității) ca și un aspirant la rolul de analist business. În cele ce urmează, aș vrea să descriu ceea ce consider acum ca fiind activitățile fundamentale care m-au ajutat să demonstrez că sunt pregătită pentru a fi un business analyst. La un nivel înalt, tipul QA tinde să se concentreze pe asigurarea faptului că cerințele sau specificațiile au fost corect implementate de către sistem și aceasta nu necesită prea multe rezolvări de probleme. Munca de business analyst înseamnă că trebuie să pătrunzi dedesubturile afacerii, să înțelegi cerințele, să cercetezi cerințele și să lucrezi cu afacerea pentru a identifica cerințele reale, cât și să îți pui în aplicare abilitățile de rezolvare a problemelor pentru a concepe o soluție care să îndeplinească toate cerințele. Din punctul meu de vedere, ca specialist QA (inginer în asigurarea calității), te afli într-o poziție favorabilă pentru a afla mai multe despre domeniul analizei business. Poți participa la ședințele de analiză a cerințelor, care de obicei sunt conduse de către analiști de business sau de către cineva care ocupă acest rol în compania voastră. Dacă este așa, acum este momentul să deveniți un critic al cerințelor. Pe lângă cele menționate mai sus, încercați să înțelegeți ,,cum”-urile și ,,de ce”-urile specificațiilor pe care le vedeți și să învățați ce face diferența dintre o cerință tehnică bună și una slabă. Pur și simplu puneți-vă în locul analistului business și evaluați ceea ce observați. Ținând cont de faptul că există, cu siguranță, analiști de business în compania voastră, ar trebui să luați în considerare șansa de a-i intervieva despre cunoștințele lor, ilustrându-vă scopurile în carieră și aflând mai multe despre acest rol. Discuții

ca și acestea v-ar mări șansa de a vă implica mai mult în procesarea cerințelor sau de a obține informații despre cum funcționează aceasta în organizația voastră. Trecerea bruscă de la asigurarea calității la analiza de business nu pare ceva imposibil. După părerea mea, metamorfoza majoră a gândirii este ceea ce implică o sarcină încheiată. În asigurarea calității, lucrurile sunt considerate a fi încheiate atunci când îndeplinesc toate cerințele (sau cel puțin o submulțime a celor care echipa decide că sunt suficient de bune pentru lansare). În analiza de business, încheierea este mult mai neclară. Ca business analyst, trebuie să ai grijă de o idee sau un concept într-un stadiu echivoc și apoi să induci o definiție sclipitoare a ceea ce înseamnă ,,încheiat” pentru proiectul software. În următorul pas, ca și analist business, slujba ta este să aliniezi toți stakeholderii (toate părțile implicate) în jurul acestei idei. A fi capabil să tratezi lipsa de precizie, cooperarea și să facilitezi comunicarea, este de cea mai mare importanță. Din perspectiva QA (asigurării calității), ai putea proceda într-o manieră similară celei când se găsește un defect care poate sau nu să fie o funcționalitate dorită și trebuie să inițiezi un proces de detectare a cerințelor. Poate oricine să joace rolul unui business analyst? De fapt, nu există o normă strictă. Specialiștii în analiza de business tind să provină dintr-un trecut educațional cu studii economice sau să fi făcut tranziția la acest rol pe baza experiențe tehnice care le-a oferit suficiente cunoștințe în domeniu pentru a se specializa într-o zonă a afacerii. La un moment dat în evoluție sa, un analist business poate să dezvolte o experiență suficientă pentru a preda acele abilități în diverse dimensiuni operaționale sau tipuri de proiecte.

Nu uitați, în calitate de analiști de business, este foarte important să înțelegeți elementele și acțiunile cheie: • Cerințe, • Regulile afacerii, • Funcționalitatea, • Devotamentul, • Scopurile, • Participarea la ședințele de analiză a cerințelor, • Crearea de noi procedee, • Preluarea rolului de legătură, • Acumularea cunoștințelor despre produs. Mult noroc în tranziția spre o carieră în analiza de business!

www.todaysoftmag.ro | nr. 27/septembrie, 2014

programare

Time Dude, un joc 3D cross mobile platform

ime Dude e un full 3d flying shooter, joc care a apărut pentru că o mână de oameni entuziasmați și pasionați de gaming – artiști și programatori- și-au spus “ce-ar fi să facem și noi un joc?”. Ajutați de un engine puternic, softuri profesioniste și entuziasm debordant, ne-am apucat de ceea ce părea cel mai simplu și distractiv mod de a-și petrece timpul: împușcând oameni preistorici caricaturali, dintr-un avion făcut din lemn și paie. Jocul nu necesită experiență anteri- și muzică. oară cu genul lui sau cu orice alt joc. Tot Avantajul tehnologic și-a spus cuvânce trebuie să faci este să îți conduci naveta tul. Pe partea de programare, puternicul pe ecran, folosindu-te de un singur deget. engine Unity 3d ne-a permis să profităm Povestea spune că John Q. Dude, aviator și temerar neînfricat al zilelor noastre, ajunge dintr-o greșeală a prietenului lui, profesorul Klumsey, într-o preistorie cartoony și deloc “historically accurate”. Avionul, la rândul lui, s-a transformat într-unul realizat din paie și lemn, legate cu liane. Cu alte cuvinte, nu ne-a stat în cale logica sau realitatea științifică. Creativ vorbind, cu siguranță Time Dude a fost o provocare: fiind primul joc al proaspăt formatului ReeAction Studios, problemele s-au acumulat rapid și au dispărut aproape la fel de rapid. Time Dude este, cum zic americanii, un “labor of love”. Pasiunea pentru gaming pe care membrii echipei o împărtășesc a însemnat o combinare între grafică 2d, grafică 3d, sunete

nr. 27/2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

din plin de spațiul 3d și de puterea terminalelor mobile. Faptul că e foarte ușor utilizat a dus la editarea rapidă a nivelelor, chiar și de către artiști începători în ale programării. Din punct de vedere audiovizual, s-a lucrat cu Photoshop, 3d Studio Max, Fl Studio și Toon Boom Harmony, toate softuri standard în industrie. Probabil cea mai dificilă parte a fost una pur tehnică și anume transferul fișierelor din softul 3d în engine-ul 3d. Odată rezolvată problema, au apărut chestiunile cele mai mici, inerente unei prime incursiuni în realizarea de jocuri. Mai toate au pornit de la discrepanța dintre artiști, care au viziuni ambițioase și vor cât mai multe feature-uri, cât mai multe poligoane,

rezoluție cât mai mare și de la limitările impuse de faptul că jocul este unul adresat în principal telefoanele mobile și tabletelor. Jocul este unul adresat tuturor vârstelor. Cu toate că împuști omuleți preistorici dintr-un avion, violența grafică este mult diminuată de abordarea hazlie și cât mai simpatică, în spiritul desenelor animate. dacă e să punem la socoteală și comentariile sfătoase ale personajului principal. Așadar, e jucabil de la pitic la bunic. Unul dintre punctele forte ale jocului este că reprezintă un produs aparte în nișa lui. În general, arcade flying shooterele sunt simple, au gameplay “instinctiv”, necesitând mai mult iuțeală de mână decât strategie, și sunt 2d. Noi am mers în direcția opusă: nava nu are o viteză superluminică, permițându-ți să te ferești de proiectilele inamicilor și să îți formezi un minim de strategie ( sunt multe căi alternative, decizii de luat, etc.). Sistemul de upgrade-uri ne-a permis să implementăm puțin Role Playing Gaming în el, prin punctele pe care ești liber să le aloci ori armurii, ori vitezei, ori armelor. Așadar, putem spune că e unic și sperăm că aceasta se va reflecta în multe download-uri, reprezentând o apreciere direct proporțională cu volumul de pasiune investită. La proiect a început să se lucreze în ianuarie 2014, iar acum, în septembrie se finalizează prima versiune a jocului nostru. A fost o perioada de învățare și echipa de bază a fost formată din cinci oameni, dar part time au colaborat mai mulți colegi. Echipa completă: • Programare, Game Design, Management - Nicolae Câmpian • Programare - György Gábor • 3D Art - Vlad Hărșan • 3D Art, Texture - Nagy Attila • Concepts, Textures, Music, SFX, Level Design, Voices - Liviu Boar • Concepts, Textures, Game & Level Design - Barbu Hărșan • Programare - Bogdan Mureșan • Textures, SFX - Cami Cuibuș • Concepts, Textures - Carmen Sava • Concepts, Textures - Illyés Hunor • Concepts, Textures - Vlad Botoș • Additional SFX - Demeter László

Perioada de învățare a fost mai lungă, deoarece școlile din România de la nivel preuniversitar și până la nivel de academic de arte și computer science nu au specializări în acest domeniu, domeniu care ulterior generează venituri mari și le oferă șansa creatorilor de a-și pune în practică visele, prin realizarea acestor jocuri. Time Dude va fi disponibil atât în App Store, cât și în Google Play în jurul datei de 1 octombrie, în funcție de rapiditatea cu care va fi aprobată publicarea. Speram ca numărul mare de utilizatori să ne permită să lucrăm în continuare la noi nivele, noi inamici, noi upgrade-uri, astfel încât să le putem livra periodic doritorilor, conținut de calitate.

Liviu Boar

liviu.boar@reea.net 2d/3d artist, animator @ ReeaAnimation

www.todaysoftmag.ro | nr. 27/septembrie, 2014

testare

Cum “bateți palma” pe un contract

n domeniul IT – ca, de altfel în orice afacere din orice domeniu – vă veți găsi în situația de a semna contracte cu partenerii dumneavoastră : contracte de dezvoltare website, contracte pentru externalizarea software sau pentru dezvoltarea de aplicații. Dar până să ajungeți la momentul semnării uneori trebuie să negociați cu partenerul anumite aspecte ale contractului, pentru a vă concilia interesele. Claudia Jelea

claudia.jelea@jlaw.ro Avocat & Consilier in domeniul marcilor @ Jlaw Claudia este specializată pe aspecte juridice ce implică mediul online, comerțul electronic și IT&C, protecția datelor cu caracter personal și proprietatea intelectuală.

Așa cum probabil știți deja, negocierea contractuală nu presupune neapărat aplicarea unei metode sau formule clasice. De cele mai multe ori, procesul prin care se ajunge la un punct comun și acceptat de ambele părți diferă de la caz la caz. Acest articol punctează câteva sugestii de natură juridică întâlnite mai des în practică. Nu vizează îmbunătățirea tehnicilor și abilităților dvs. de negociator - lăsăm acest aspect pe seama antreprenorilor de succes, scriitorilor avizați și trainerilor de profil.

Elemente-cheie ale înțelegerii Primul pas este să discutați cu partenerul dvs. și să stabiliți punctele principale ale înțelegerii pe care o aveți în plan, precum: aspectele comerciale ce țin de preț și de termenele de plată, care sunt milestone-urile, în cât timp trebuie acceptate livrabilele. Celelalte detalii pot fi discutate și pe parcursul sau ulterior redactării contractului. De asemenea, acordați atenție momentului când finalizați negocierile asupra elementelor esențiale și “bateți palma”;

nr. 27/2014 | www.todaysoftmag.ro

atunci, veți avea un contract obligatoriu pentru părți chiar dacă nu aveți încă un document semnat.

Înțelegeți punctele de vedere ale partenerului

Încercați să înțelegeți care este scopul și interesul partenerului dvs. și ce vrea să dobândească în urma negocierilor. Se întâmplă rar să aveți aceleași scopuri și interese; însă, uneori, s-ar putea să aveți surpriza să constatați că interesele voastre nu sunt neapărat divergente. De exemplu, un dezvoltator software poate accepta să cedeze către clientul său, prin contract, toate drepturile de proprietate intelectuală asupra aplicației create conform instrucțiunilor clientului (și cei mai mulți clienți solicită acest lucru). Pe de altă parte, în practică, există și situații (destul de rare) în care clienții nu își manifestă interesul pentru o cesiune a drepturilor de proprietate intelectuală; acest lucru poate fi în avantajul dezvoltatorului care va prefera să mai poată folosi, modifica sau personaliza codul sursă al respectivei aplicații și

testare pentru alți clienți sau pentru alte scopuri.

Negociați!

Nu acceptați din start explicația clasică “acesta e standardul nostru de contract pe care îl folosim și nu poate fi modificat”, pentru că de cele mai multe ori această replică s-ar putea să fie ea însăși o strategie de negociere a celeilalte părți. Atât timp cât nu există un acord al părților, contractul nu este încheiat și poate să fie negociat pentru protecția propriilor interese. Desigur, nu trebuie omisă realitatea că uneori există un dezechilibru între cât de mult își doresc sau au nevoie părțile să încheie respectivul contract. Totuși, nu presupuneți lipsa de deschidere a celeilalte părți și măcar încercați să negociați clauzele care vă interesează. De asemenea, fiți precauți dacă, pe parcursul negocierii, partenerul dvs. este reticent în a vă oferi informații despre activitatea companiei sau despre asociații sau acționarii acesteia – mai ales în cazul în care aceste informații pot influența executarea contractului și obligațiile pe care părțile și le asumă.

Revizuiți contractul și modificările aduse acestuia atât timp cât aveți nevoie

TODAY SOFTWARE MAGAZINE La semnare Dacă este vorba de un contract important, ideal ar fi să lăsați avocații să se ocupe de procesul semnării. Dar dacă este un contract uzual, vă puteți implica dvs. cu mențiunea să nu omiteți detaliile de bază – de exemplu, să semneze persoana care are autoritatea legală de a semna ; nu orice reprezentant al unei societăți poate semna contracte, în lipsa unei împuterniciri specifice ; datarea corectă a contractului (în special dacă semnarea contractului are loc la distanță – de exemplu, pe e-mail), etc. .

Apelați la specialiști

Este de preferat să beneficiați de ajutorul specialiștilor încă de la începutul discuțiilor contractuale – avocați specializați dar și contabili, consultanți fiscali. Pentru ca aceștia să vă poată asista cât mai eficient în toate fazele redactării contractului și pe durata negocierilor, trebuie să le oferiți detaliile și instrucțiunile necesare, astfel încât să vă înțeleagă interesul de business și punctele la care nu sunteți dispuși să renunțați. De asemenea, aceștia vă pot semnala eventuale riscuri (de exemplu, când clientul solicită dezvoltatorului crearea unui website sau a unei soluții software ce încalcă anumite legi) sau pot încerca să le minimalizeze prin modul în care redactează contractul introducând secțiuni privind răspunderea sau garanțiile oferite. Este util să rețineți faptul că dvs. - nu avocații - luați decizia finală privind clauzele ce se vor regăsi în contract. Avocații vor face recomandări și sugestii, dar dvs. știți cel mai bine care sunt riscurile pe care sunteți dispus să vi le asumați.

Pentru a nu omite aspecte relevante, nu vă grăbiți când analizați contractul și modificările sau sugestiile făcute de cealaltă parte; luați-vă timpul necesar pentru a înțelege toate aspectele și întrebați avocații acolo unde aveți neclarități. Este posibil ca unele aspecte să nu fie discutate încă de la început. În acest caz, ele vor trebui armonizate prin prevederile contractului – iar fiecare dintre părți va propune modificări contractuale care vor Iar ca notă de final: ascultați-vă fi negociate până se ajunge la un consens. instinctul!

www.todaysoftmag.ro | nr. 27/septembrie, 2014

management

Gogu în șoc... cultural - Ssiga-ssiga..., zâmbi Gogu la amintirea vacanței și se lăsă pradă reveriei: mare turcoaz, plajă cu nisip fin, pădure cu pini și soare pe un cer mereu senin. Doamne, zău dacă insula asta nu e paradisul pe pământ... - Ce sâsâi acolo, Gogule, vreo blondă amintire să te bântuie oare? Nu ziceai că ai probleme pe proiectul din Golf? Văd că zâmbești, n-ai treabă... Cuvintele lui Mișu sparseră reveria lui Gogu. - Ce blondă, Mișule, de blonde îmi arde mie?! Da’ uite că mi-am adus aminte de vacanța în Grecia și uite-așa m-a pocnit o idee! Gogu își acompanie ultimele cuvinte de o lovitură zdravănă în frunte, evident cu intenția de a sublinia importanța momentului. - No, lasă Gogule, nu-i musai să te pedepsești amu’, înțeleg eu că problema-i gravă... Da’ zi-mi și mie ce-i cu sâsâitul... și mai ales ce-are a face cu proiectul nostru?! Cu ce te ajuta Grecia la planificarea livrabilelor? - Nu m-ajută la planificare... redeveni Gogu serios, m-ajută însă să înțeleg. Poate. Așa cred... ia fii atent aici: când am ajuns în vacanță, tipa de la agenție ne-a zis să ne relaxăm, să nu ne grăbim că viața pe insulă are propriul ei ritm: ssiga-ssiga, zicea ea, adică încet-încet... - Aha, așa zic grecii la încet: ssiga? - Da. Și la început n-am prea priceput eu ce e cu ssiga-ul ăsta, da’ m-am prins repede: ei nu se grăbeau, frate, cu nimic. Autobuzul pleca numai după ce șoferul termina de fumat țigara, chelneru’ se plângea mereu de treabă, în schimb avea timp să stea de vorbă cu tine despre vrute și nevrute, în general despre ultimul meci din campionatul mondial, frappe-ul venea la juma’ de oră după ce îl comandai, dar toți erau relaxați, calmi... Cam ca tine, așa... Ei, după o săptămână intrasem și eu în ritmul ăsta numai că atunci s-a terminat vacanța... Și ca să ajung la subiect, ideea care m-a trăznit e foarte simplă: cum m-am calmat eu la greci după ce m-am prins că ăsta e felul lor, așa trebuie și acum să înțeleg care e felul celor cu care lucrăm acum, și-atunci lucrurile vor fi mult mai simple. - Hmm... - Cam scurt răspunsul tău, ai putea fi ceva mai detaliat? - Mă gândeam, no... E ca și-atunci când

o venit clientul ăla din Japonia de tot zicea Yes-yes-yes și toți am crezut că l-am convins, da’ el zicea așa semn c-o înțeles ce i-am spus noi, nu că era de acord. Că dupaia a făcut tot cum o vrut el. - Exact, Mișule. La astea le zice diferențe culturale. Noi suntem suma educației pe care am primit-o, a obiceiurilor pe care le-am moștenit și care ne-au înconjurat, a credințelor părinților, rudelor, prietenilor alături de care am crescut. Iar acestea sunt diferite de experiențele prin care trec oameni din alte părți ale globului. Și-atunci e normal ca ei să aibă alte crezuri, alte reacții. - Aha, mai ții minte când am mers cu japonezul la film? Era în fața noastră, în sală, grupul ăla gălăgios de le-ai făcut tu observație... - Ha-ha... și s-a supărat japonezu’, s-a simțit jenat că de ce le-am spus lor direct să facă liniște în loc să raportez la supraveghetorul de sală... ha-ha, mai ții minte că nu pricepeam ce vrea el cu supraveghetorul?! Dar gata cu gluma acum, treci la studiat ce diferențe pot exista între ei și noi, să vedem dacă ne putem descurca mai bine. Trebuie să terminăm planificarea, iar eu tot n-am reușit încă să aflu care sunt zilele lor de vacanță în perioada următoare. - Ce mai planificați, măi băieți? Șefu’ iar apăruse pe nepusă masă, iar cei doi, prinși în febra discuției, nu-l văzuseră. - Iar te furișezi, Șefu’?! Uite, dezbăteam pe tema proiectului din Kuwait, vreau să fac o planificare detaliată, să vadă ce serioși suntem. Numa’ că nu avem toate datele... Cică vacanța din octombrie începe la 70 de zile după Ramadan, dar n-am găsit pe net când e data fixată pentru sfârșitul de Ramadan... - Păi nici nu vei găsi, Gogule, depinde de lună... - În iulie a fost anul acesta. - Nu luna din calendar, luna de pe cer. Și închide gura că îți intră o muscă. Gogu rămăsese într-adevăr cu gura căscată. Cum adică luna de pe cer? Ascultă explicațiile Șefului, dar cumva mintea lui refuza să accepte. Probabil că sentimentul era clar exprimat de fața lui, pentru că Șeful se opri din explicații și adăugă: - Gogule, te auzisem mai devreme cu ssiga-ssiga. Știu conceptul, l-am

nr. 27/septembrie, 2014 | www.todaysoftmag.ro

experimentat. Dar oamenii ăștia cu care vom lucra acum sunt mult-mult mai departe. Și geografic și cultural. Lucrurile pot fi foarte diferite. Nu poți să ieși cu ei la o bere, să clarificați lucrurile, poți ieși maxim la un ceai. Și numai dacă nu e perioada Ramadan-ului, atunci în timpul zilei nu ai voie nici să mănânci, nici să bei. Și chiar dacă ai ieșit la ceai, nu te poți aștepta să îți spună în față dacă ceva nu e bine, căci nu vor să te pună într-o situație dificilă... Cât despre planificarea strictă, uit-o. Timpul are – pentru ei - o altă semnificație. Propune-le o planificare pe săptămâni, în nici un caz pe zile, și adaugă rezerve pentru comunicare și negociere, dublu față de ce suntem noi obișnuiți... Iar ideea ta de a citi mai multe despre obiceiurile, credințele, cultura lor, este excelentă. Vă va ajuta mult în relația cu ei. - Șefu’, tu ai lucrat cu ei, nu-i așa? - Am lucrat, am greșit, am învățat... - Ahhh, spune-ne și nouă ce-ai greșit! Șefu’ zâmbi: Da, eram sigur că vreți s-o aflați pe asta. Păi uite ce s-a întâmplat: am avut ghinion cu niște echipamente care nu ne-au venit la timp și am întârziat cu livrarea soluției la client. - Și s-au supărat din cauza întârzierii? sări repede Gogu. Doar ce ne-ai spus că timpul e văzut altfel la ei... - Nu, Gogule, nu s-au supărat din cauza întârzierii, s-au supărat din cauza ‚,ghinionului’’. Auzi, măi Gogule, râse Șefu’, tu ai o problemă azi: tot rămâi cu gura deschisă. Gogu fusese prins iar pe picior greșit: Cum adică din cauza ‚,ghinionului’’? Ce-au ei cu ghinionul? - Păi tocmai că n-au nimic, la ei nu există ghinion, există doar voia Celui De Sus. Tot ceea ce se întâmplă are un rost, un motiv și nu depinde de noroc sau ghinion. Aici am greșit eu... Iar voi dacă nu vreți să greșiți, treceți înapoi la treabă, că altfel vedeți voi ce înseamnă ghinion...

Simona Bonghez, Ph.D.

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

sponsori