today software magazine n27/2014
DESCRIPTION
Today Software Magazine N27/2014TRANSCRIPT
TSM T O D A YS O F T WA R E
Nr. 27 • Septembrie 2014 • www.todaysoftmag.ro • www.todaysoftmag.com
M AG A Z I N E
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
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
JavaFX în Platforma Java Standard 8
Avantajele folosirii SVG
6Cluj IT Days 2014, www.itdays.ro
Ovidiu Măţan
8Invitație la a III-a ediție a
conferinței Gemini Solutions Foundry
Ovidiu Măţan
9Cu Smilestone la Imagine Cup 2014
Dan Suciu
12Interviu cu Chris Heilmann
de la MozillaOvidiu Măţan
14Visul împlinit al unei școli de
vară - Fortech hiSchool Training Program
Sorina Mone
16How to Web 2014:
un nou începutIrina Scarlat
17Invitaţie la TYPO3 East Europe 2014
Daniel Homorodean
19JavaFX în Platforma
Java Standard 8Silviu Dumitrescu și Diana Bălan
22Avantajele folosirii SVG
(Scalable Vector Graphics)Peter Krejcik
2
25Livrarea continuăDan Danciu
29Detectarea fraudelor cu Titan Florin Măguran
31Pragmatism în programareMihnea Lazăr
34Clean code – FuncțiiRadu Vunvulea
36Integrarea client server cu ajutorulRestKitMihai Fischer
38Cum poți testaconferințe de testareAlexandra Casapu
41Tranziția de laQA la BAMonica Petraru
42Time Dude, un joc3D cross mobile platformLiviu Boar
44Cum “bateți palma” pe un contractClaudia Jelea
46Gogu în șoc... culturalSimona Bonghez, Ph.D.
4 nr. 27/2014 | www.todaysoftmag.ro
Î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ș, pro-gramată 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 expre-sia 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ă pro-iectele 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 evenimen-tele 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 antrepre-noriat ș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, Integrerea 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 lor în managementul proiectelor.
Vă dorim o lectură plăcută !!!
Ovidiu MăţanFondator al Today Software Magazine
Ovidiu Măţ[email protected]
Editor-in-chief Today Software Magazine
editorial
5www.todaysoftmag.ro | nr. 27/septembrie, 2014
Redacţia Today Software Magazine
Fondator / Editor in chief: Ovidiu Mățan [email protected]
Editor (startups și interviuri): Marius Mornea [email protected]
Graphic designer: Dan Hădărău [email protected]
Copyright/Corector: Emilia Toma [email protected]
Traducător: Roxana [email protected]
Reviewer: Tavi Bolog [email protected]
Reviewer: Adrian Lupei [email protected]
Contabil : Delia [email protected]
Produs de Today Software Solutions SRL
str. Plopilor, nr. 75/77Cluj-Napoca, Cluj, [email protected]
www.todaysoftmag.rowww.facebook.com/todaysoftmag
twitter.com/todaysoftmag
ISSN 2284 – 6352
Copyright Today Software Magazine
Reproducerea parțială sau totală a articolelordin revista Today Software Magazine
fără acordul redacției este strict interzisă.
www.todaysoftmag.rowww.todaysoftmag.com
Lista autorilor
Claudia [email protected]
Avocat & Consilier in domeniul marcilor @ Jlaw
Daniel [email protected]
CEO@ Arxia
Simona Bonghez, [email protected]
Speaker, trainer şi consultant în managementul proiectelor,
Owner al Colors in Projects
Sorina [email protected]
Marketing manager@ Fortech
Silviu [email protected]
Consultant Java@ msg systems Romania
Mihai [email protected]
iOS developer@ Dens.io
Irina [email protected]
PR Manager @ How to Web & TechHub Bucharest
Director of Technical Training @ 3Pillar Global
Florin Mă[email protected]
Senior Java Developer@ Betfair
Mihnea Lază[email protected]
Java Developer@ msg systems
Alexandra [email protected]
Software Tester@ Altom Consulting
Monica [email protected]
Senior Business Analyst@ UNIQA Raiffeisen Software Service
Peter Krejcik [email protected]
Web Designer @ Yardi România
Software Architect@ ISDC
Diana Bă[email protected]
Java developer@ Accesa
Ovidiu Măţ[email protected]
Editor-in-chief Today Software Magazine
Liviu [email protected]
2d/3d artist, animator@ REEAnimation
6 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
eveniment
Today Software Magazine vă invită în 25-26 noiembrie la
a doua ediție a Cluj IT Days 2014, www.itdays.ro
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 pre-cum și pe cei mai buni specialiști care au publicat de-a lungul anului în revista noas-tră. 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.
Cartea de altfel se va remarca prin diversitatea subiectelor, având capitole de la startups, leadership, management, proiecte de cercetare, trenduri și până la subiecte tehnice de programare sau testare. Dincolo de această varietate, se impune totuși o tematică principală, subordonată de altfel înseși temei evenimentului care
este despre cum să construim un pro-dus. 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 Java1, având rangul trei pentru Java și doi pentru concurență în rețeaua StackExchange din care face parte și StackOverflow2.
În secțiunea de Trends & Leadership îl avem ca invitat pe Iulian Iuga, CEO
1 vanillajava.blogspot.ro
2 stackexchange.com/users/23121/peter-lawrey
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, un cunoscut colaborator al revistei din perpectiva studiilor de HR realizate asupra comunității de IT clujene va avea ca subiect al prezentării, perspec-tive asupra Leadership-ului românesc.
Silviu Dumitrescu, un colaborator con-secvent al revistei ne va vorbi despre Java 8.
Pe Silvia Răusanu am invitat-o la eve-niment în special pentru vizuinea tehnică
Evenimentul 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 dome-niului î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.
Iulian Iuga
Dan Ionescu
Silviu DumitrescuPeter Lawrey
7www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINE
asupra Big Data și pasiunii ei pentru algo-ritmică și inteligență artificială.
Sergiu Damian este un architect software experimentat, cu o profundă înțelegere a design-ului software, prac-ticilor ș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 outso-urcing a ales să devină un arhitect software independent, ajutând diverși clienți în a-și atinge obiectivele. Activează în diverse comunități IT, oferă asistență studenților și îi învață pe alții despre software architecture.
Andreea Pârvu este absolventă a mas-teratului de Psihologia Resurselor Umane. Demersul ei profesional a debutat în cali-tate de HR Generalist la o companie de logistică - aici descoperind și dezvoltând o pasiune pentru aria de Resurse Umane. Experiența internatională 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știntelor în acest domeniu. În plus, aceast context a avut un impact pozitiv în momentul în care a decis să incerce domeniul IT, ca freelancer. Însă, din 2012, Andreea este Senior Recruiter la Endava - Cluj, una dintre companiile de
IT recunoscută ca având una din cele mai accelerate creșteri pe piața din România.
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ă.
Dr.ing. Bogdan Rus este șef lucrări (lector) în cadrul Universității Tehnice din Cluj-Napoca, Facultatea de Electronică, Telecomunicații și Tehnologia Informației. Devenind din anul 2008 membru al colec-tivului 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 inIn-ternetul viitorului. Rezultatul întregii activități de cercetare a fost validat în diverse articole publicate la conferințe internaționale și reviste de specialitate. Adițional activităților de cercetare, Andrei Bogdan Rus este implicat și în activități didactice cu studenții înscriși la cursurile de licență și masterat.
Zsolt Alfréd Polgár a obț inut diploma de Inginer cu specializarea
Telecomunicații, Master în Tehnici Avansate în Telecomunicații și Doctor în Inginerie Electronică și Telecomunicații de la Universitatea Tehnică din Cluj-Napoca î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 cana-lului, 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.
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 raining-urile de project management, pregătirile pentru certifica-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 de speaker.
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ăţ[email protected]
Editor-in-chief Today Software Magazine
Silvia Răusanu
Sebastian Big
Dr. ing Bogdan Rus
Simona Bonghez
Zsolt Alfréd Polgár
Sergiu Damian
Andreea Pârvu
8 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
Pentru cei interesați, accesul se face pe bază de invitație, iar pentru obținerea acesteia vă invit să accesați site-ul Gemini Solutions Foundry www.gemsfoundry.com. Locul de desfășurare este etajul 34 al Sky Tower, în București, în data de 23 sep-tembrie de la ora 16:30.
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, cu precădere, ideilor de afaceri din dome-niul IT. De-a lungul anilor, compania a sprijinit zeci de inițiative business, devenite adevărate povești de succes. Conform ulti-mului 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 anual având valoarea medie de 500,000 dolari1. Antreprenorii prezenți la eveniment vor avea, de asemenea, posibil-itatea de a-și prezenta ideile de business, într-o sesiune interactivă de pitching. Astfel, în a doua parte a conferinței, vor fi expuse cele mai interesante proiecte ale participanților înscriși.
Theo Nissim
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, inves-titorii, 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-uri-lor 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/
Ceea ce căutăm sunt startup-uri care pot fi scalabile la nivel global, care favorizează schimbarea și revoluția pieței. Noi le vom ajuta să se pregătească pentru investiții și să își dezvolte infrastructura care le va permite să se reintegreze în Silicon Valley, în timp ce își păstrează echipele tehnice în România. Suntem interesați în mod special de dome-nii 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ă suc-ces la scară mondială.
Gemini Foundry Inc, incubator destinat startup-urilor din Romania
Pentru a veni în sprijinul antrepreno-rilor 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 com-panii puternice și competitive la nivel internațional.
Mai mult, Gemini Foundry oferă gra-tuit echipelor acceptate în programul de incubare spațiu de birouri la cheie, aju-tor î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 efec-tuat în cadrul programului de incubare.
eveniment
Invitație la a III-a ediție a conferinței
Gemini Solutions Foundry
Grupul de firme Gemini Solutions împreună cu Gemini Foundry Inc, organizează în data de 23 Septembrie 2014, la București, a treia ediție a Conferintelor 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.
Ovidiu Măţ[email protected]
Editor-in-chief Today Software Magazine
9www.todaysoftmag.ro | nr. 27/septembrie, 2014
Imagine 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.
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 dez-voltate ș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 competitiori 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 regi-uni. 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ţi-uni și a cunoscut diverse formate. În ultimele două ediţii fiecare dintre echipele partici-pante au putut veni cu soluţii în una dintre următoarele categorii: Innovation, World Citizenship și Games.
Premiile puse în joc în acest an, pen-tru 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 pen-tru 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ţi-ile anterioare, în acest an nu a fost anunţată o temă generică la care să se ralieze soluţi-ile prezentate. Practic, oricine avea o idee ce considera că merită să fie dezvoltată și trans-formată într-un produs cu succes și impact pe piaţa globală putea să se înscrie la secţiu-nea care i se părea cea mai potrivită. Evident, având în vedere că Imagine Cup este orga-nizat 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ţiu-nile 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 organi-zare ș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 înce-put 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 cen-trală a viitoarei soluţii. Cu echipa formată
Cu Smilestone la Imagine Cup 2014
concurs
Director of Technical Training @ 3Pillar Global
10 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
Cu Smilestone la Imagine Cup 2014concurs
ș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 tre-cut atât Universitatea Babeș-Bolyai cât și Universitatea Tehnică au organizat astfel de sesiuni, echipele situate pe pri-mele 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 regi-onal. 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ă, cli-enţi potenţiali precis delimitaţi.
• Innovation (50%) – inovaţia e pri-vită 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 credibi-litate cu privire la potenţialul de succes al aplicaţiei.
Participarea României România a avut de-a lungul timpu-
lui o prezenţă la Imagine Cup presărată cu numeroase premii la diverse secţi-uni î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 inte-resante î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 pro-pusă 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 persoa-nele 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 psiho-log Ștefania Budacu. Aceasta colabora la vremea respectivă cu spitalul Floreasca și a auzit de proiectul Mira de la televi-zor. Proiectul Mira era tot o soluţie de
recuperare fizică dar orientată pe mem-brele 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 comuni-care (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 paci-ent 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 pacien-tul să reușească să revină la modul în care comunica sau se mișca înainte de acci-dent 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 deta-lii 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 abili-tăţ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 exer-ciţ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
Standul SMT la Museum of History and Industry (MOHAI), Seattle
11www.todaysoftmag.ro | nr. 27/septembrie, 2014
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 cor-pului ș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ă pro-vocare a constat în posibilitatea detectării mișcărilor limbii atunci când aceasta era scoasă în afara gurii. Nefiind nimic imple-mentat î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 mem-brii 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.
În loc de concluzii...În foarte puţine cuvinte, aceasta a
fost soluţia propusă de România în acest 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 pri-micipalilor 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
că procesul de testare va fi unul compli-cat. Sperăm însă ca și rezultatele să fie pe măsura efortului.
www.3pillarglobal.com
3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world.
Our core competencies include:
ProductStrategy
ProductDevelopment
ProductSupport
Our offerings are business focused, they drive real, tangible value.
La festivitatea de decernare a premiilor
12 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
Am 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 edu-că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 dezvol-tatorilor – 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
Interviu cu Chris Heilmann de la Mozilla
interviu
13www.todaysoftmag.ro | nr. 27/septembrie, 2014
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 conectivi-tatea 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 încor-porat î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 pre-cum documentaț ia 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 mult t imp ajutând voluntarii să comunice și să se auto-reco-
mande î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.
Despre Christian HeilmannChristian 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
6 www.mozilla.org/en-US/contribute
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, expli-câ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. Chris Heilmann
Ovidiu Măţ[email protected]
Editor-in-chief Today Software Magazine
14 nr. 27/2014 | www.todaysoftmag.ro
ce necesită o logistică aparte, oameni dedicați și parteneri cu deschidere.
Astfel că prin eforturile echipei noas-tre de HR, ale unui grup de profesori din cadrul liceului teoretic “Avram Iancu” și ale unor oameni pasionați din Fortech, a fost pus pe roate programul hiSchool Training.
Ce este Fortech hiSchool Training?O inițiativă comună a Fortech și a lice-
ului “Avram Iancu” ce vizează organizarea unor cursuri practice de tip workshop pentru elevii de liceu care au interes înspre zona de IT. Scopul este de a com-pleta cunoștințele dobândite în școală și de a facilita contactul cu mediul real în care elevii vor activa, într-o etapă în care se ia practic decizia de carieră prin alegerea facultății și pregătirea pentru aceasta.
Ne propunem să fim acea organizație care aduce un aport nu doar pentru a aco-peri necesarul de specialiști IT pentru a doua jumatate 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 inves-tit în copiii și tinerii de azi. De asemenea, credem că pentru a excela într-un dome-niu, 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ă se adreseze unei națiuni spunând că fie-care copil trebuie să învețe să programeze pentru că îl învață cum să gândească (i.e. “Code Starts”). Dar avem oameni pasionați în Fortech care și-au luat din timpul lor de muncă pentru a-l dedica unor tineri la fel de pasionați, curioși și în curând în pragul
uneia dintre cele mai importante decizii de viață.
În continuare vom reda jurnalul a 13 zile petrecute împreună cu elevii noștri.
Ziua 1 - Cariere în ITNe cunoaștem ... actual și viitor analist
de business, manager de proiect, pro-gramator, designer. Peste 40 de elevi în Happy Bistro la Fortech, timizi la primul rendez-vous cu “inginerii”. Am povestit despre ce înseamnă o cariera în IT din perspective diferite, care împreună încu-nunează echipa unui proiect: a analistului de business, a project managerului, a pro-gramatorului, a QA-ului, a inginerului de sistem, a designerului.
“Pe majoritatea dintre noi, aceste discuții ne-au motivat și ne-au îndrumat să alegem un drum în IT. Ne-au lărgit ori-zontul, având ocazia să ne formăm o idee despre munca în acest domeniu” spun Alex, Rares, Beatrice și Adina.
Ne-am bucurat nespus când deja la workshop-ul cu nr. 2 a trebuit să suplimen-tăm cu încă o sesiune, întrucât numărul de elevi înscriși depășea numărul maxim de 20 pe care ni-l propusesem pentru urmă-toarele întâlniri. Au urmat așadar primele întâlniri de lucru:
Organizarea 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 compa-nie. 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
educație
Visul împlinit al unei şcoli de vară
- Fortech hiSchool Training Program
Sorina [email protected]
Marketing manager@ Fortech
15www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINE
Ziua 2 – Introducere în OOP
Ziua 3 – Programare web
Ziua 4 – MS Office
Ziua 5 – Bune practici în programare A fost unul dintre cele mai apreci-
ate workshop-uri, întrucat a valorificat experiența practică a programatorilor din Fortech. A fost pentru elevii pasionați de programare o oportunitate inedită de a vedea ce înseamnă un cod “curat”, ce implică refactoring-ul și reutilizarea codu-lui, 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 6 – Managementul timpului
Ziua 7 – Concepte de Agile Ce modalitate mai practică și interac-
tivă 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 con-text de proiect Agile), cum ar fi clarificarea
specificațiilor cu managerul de produs, au fost mai puțin frecvente în rândul elevilor! Sigur că nu putem trage concluzii defini-tive, dar ne-am dat seama că o vârstă mai frageda înseamnă mai puține restricții în gândire și comunicare, curajul de a întreba și lipsa temerilor de a greși. E păcat să nu fie cultivate.
Ziua 8 – Programarea aplicațiilor mobile (iOS și Android)
Ziua 9 – Branding & design grafic Proiectul propus de către noi: brand-
uirea ... 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 10 – Munca în echipă 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 11 – Unelte de muncă colaborativă
Ziua 12 – Testarea și asigurarea calității aplicațiilor software
Ziua 13 – Baze de date, SQL
Retrospectiva – Fortech hiSchool Train-ing, 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 aces-tora .
“Fiul meu este unul dintre elevii de la “Avram Iancu”, care participă la workshop-urile 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 pre-cum IT-ul e de apreciat. Felicitari domnului Văduva, profesorilor de la “Avram” și colab-oratorilor!” (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!
Young spiritMature organizationA shared vision
Join our journey!
www.fortech.ro
TODAY SOFTWARE MAGAZINE
16 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
eveniment
Bucureș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 mar-chează un nou început pentru conferinţă și propune participanţilor un format mai complex. Astfel, evenimentul va aborda teme precum antreprenoriatul în tehno-logie, dezvoltarea de produse cu potenţial disruptiv la nivel global, tendinţe ale indus-triei, 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 transfor-matoare 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 dezvolta-torii 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ă dispo-zitivele 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 programu-lui, acestea vor participa la workshop-uri și sesiuni de mentorat, vor cunoaște inves-titori ș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 par-tener principal al programului.
Rezultatele ediţiei precedente confirmă calitatea programului și impactul pe care acesta îl are asupra dezvoltării startup-uri-lor. 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 repre-zentanţ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 inves-tiţ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 par-ticipanţ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 startup-urile 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/
How to Web 2014: un nou început
Irina [email protected]
PR Manager @ How to Web & TechHub Bucharest
17www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINE eveniment
Despre 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
conţinut.
TYPO3 este un framework CMS extraordinar, construit nemţeşte pentru a oferi excelenţă funcţională, performanţă şi extensibilitate. Puterea lui se vede în spe-cial când ai de implementat portaluri mari, cu flux editorial complex sau soluţii multi-domain, î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 jumatate de oră, pe baza şabloanelor preconstruite.
În Germania, Austria, Elveţia, Olanda şi multe alte ţări, administraţia publică şi uni-versităţ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 înde-lungată, î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 dezvol-tarea 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 usurinţă în editarea conţinutului cum nici o altă plat-forma 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 priv-ind 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 rel-evante î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 geo-grafică. 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 comuni-tăţ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: com-paniile 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 ).
Invitaţie la TYPO3 East Europe 2014
Daniel [email protected]
CEO@ Arxia
18 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: www.transylvania-jug.orgData înfiinţării: 15.05.2008 / Nr. Membri: 586 / Nr. Evenimente: 46
Comunitatea TSMComunitate construită în jurul revistei Today Software Magazine.Website: www.facebook.com/todaysoftmag www.meetup.com/todaysoftmagData înfiinţării: 06.02.2012 /Nr. Membri: 1746/Nr. Evenimente: 22
Cluj Business AnalystsComunitate dedicată analizei de businessWebsite: www.meetup.com/Business-Analysts-ClujData înfiinţării: 10.07.2013 / Nr. Membri: 87 / Nr. Evenimente: 8
Cluj Mobile DevelopersComunitate dedicată tehnologiilor mobileWebsite: www.meetup.com/Cluj-Mobile-DevelopersData înfiinţării: 05.08.2011 / Nr. Membri: 236 / Nr. Evenimente: 15
The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 442 / Nr. Evenimente: 86
Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: www.meetup.com/Cluj-Semantic-WEBData înfiinţării: 08.05.2010 / Nr. Membri: 191/ Nr. Evenimente: 28
Romanian Association for Better SoftwareComunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.Website: www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 248/ Nr. Evenimente: 14
Tabăra de testareComunitate 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.roData înfiinţării: 15.01.2012 / Nr. Membri: 1186/ Nr. Evenimente: 33
Luna 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.
Calendar Septembrie 18 (Cluj)Lansarea numărului 27 a Today Software Magazine www.todaysoftmag.ro
Septembrie 22-23 (București)SmartWebConfsmartwebconf.com
Septembrie 23 (București)A III-a ediție a conferinței Gemini Solutions Foundrywww.gemsfoundry.com
Septembrie 24 (Târgu Mureș)Lansarea numărului 27 a Today Software Magazine împre-ună cu Cluj IT Clusterwww.todaysoftmag.ro
Septembrie 25-26 (București)SEETESTseetest.org
Octombrie 1-2 (Iași)Business Days Iașiwww.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 Worldimworld.ro
Octombrie 10 (Iași)...even mammoths can be Agilefacebook.com/events/820690977965456
Noiembrie 25-26 (Cluj)Cluj IT Daysitdays.ro
Comunităţi IT
comunități management
19www.todaysoftmag.ro | nr. 27/septembrie, 2014
programare
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 respon-sabil cu furnizarea unui serviciu nativ ce include gestiunea ferestrelor, a timer-elor și a suprafețelor. De asemenea, leagă plat-forma JavaFX de sistemul de operare nativ. Mai mult, Glass este responsabil de gestiunea cozii de evenimente. Dacă AWT își gestio-nează propria coadă de evenimente, Glass utilizează coada nativă a sistemului de ope-rare. 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, dia-grame, 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
M-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ă.
JavaFX în Platforma Java Standard 8
management
Diana Bă[email protected]
Java developer@ Accesa
Silviu [email protected]
Java Line Manager@ Accesa
20 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
launch() și suprascrie metoda abstractă start(). Ca bună prac-tică apelul metodei launch() este singurul apel din main()
• Un stage primar ce este vizibil, ca argument al metodei start()
• Avem trei tipuri de aplicații JavaFX:• Aplicații propriu zise, ce folosesc sintaxa Java tradițională
și API-ul JavaFX.• Aplicații FXML. FXML se bazează pe XML și este folosit
pentru a defini interfețe-utilizator în aplicații JavaFX. Cu FXML vom defini layout-uri statice precum formulare, controale sau tabele. Putem construi, de asemenea, layout-uri dinamice prin 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 plat-formă, 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 javafx.application.Application;import javafx.event.ActionEvent;import javafx.event.EventHandler;import javafx.scene.Scene;import javafx.scene.control.Button;import javafx.scene.layout.StackPane;import javafx.stage.Stage;
public class JavaFXApplication extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) {
primaryStage.setTitle(“Hello World!”); Button btn = new Button(); btn.setText(“Say ‘Hello World’”); btn.setOnAction(new EventHandler<ActionEvent>() {
@Override public void handle(ActionEvent event) { System.out.println(“Hello World!”); } }); StackPane root = new StackPane(); root.getChildren().add(btn); primaryStage.setScene(new Scene(root, 300, 250)); primaryStage.show(); }
}
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 plat-forme RIA.
• FXML nu se compilează, de aceea nu este necesar să recom-pilă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,
programare managementJavaFX în Platforma Java Standard 8
21www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINEmanagement
a stage-ului și pentru lansarea aplicației. Una dintre acțiunile importante este dată de secvența următoare:
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.
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” min-Height=”16” minWidth=”69” prefHeight=”16”
prefWidth=”69” fx:id=”label” /> </children></AnchorPane>
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 utili-zator. Numele acestuia trebuie să fie identic cu cel al clasei view fxml.
import java.net.URL;import java.util.ResourceBundle;import javafx.event.ActionEvent;import javafx.fxml.FXML;import javafx.fxml.Initializable;import 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.
22 nr. 27/2014 | www.todaysoftmag.ro
SVG (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, nefi-
ind suportat în totalitate pe browser-e cum ar fi pe Internet Explorer. Însă lucrurile au început să se schimbe…
În articolul meu, voi prezenta pe scurt conceptul SVG și voi discuta despre avan-tajele 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 spe-cial 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 folo-
sind tag-uri le <svg>. . .</svg> .
Atributele de înălțime și lățime ale ele-mentului <svg> definesc înălțimea și lățimea SVG-ului .
• Atributele cx și cy definesc coordo-natele 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 omi-terea 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 elip-tice și dreptunghiuri cu sau fără colțuri rotunjite.
2. Traiectorii (Paths): traiectorii subli-niate 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 valo-rile standard hex sau rgb de 3 sau 6 cifre.
Avantajele folosirii SVG
(Scalable Vector Graphics)
programare
Peter Krejcik [email protected]
Web Designer @ Yardi România
programare
23www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINEprogramare
6. Gradient-uri și pattern-uri (Gradients and patterns): definire de gradient-uri în format CSS3 sau fundaluri bitmap.
7. Secționări, acoperiri și compoziții (Clipping, masking and compositing): folosirea de elemente pentru a contura regi-uni 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-han-
dlers 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 folo-sind 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 folo-sirea SVG-urilor.
Avantajele folosirii SVG-urilor
Sunt scalabileCel mai mare avantaj al graficii vectoriale este posibili-
tatea 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 cre-area 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
un factor foarte important în prezent, deoarece display-urile de mare rezoluție sunt din ce în ce mai des folosite, iar livrarea unui conținut responsive este de dorit.
Ușor de creatCrearea 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).
Ușor de editatSVG-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 caracteris-tici de bază cum ar fi culoarea sau conturul se poate face simplu și rapid.
Objective C
Yardi Romania
24 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
Dimensiuni mai reduseDimensiunea 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 vec-torială: 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ă.
Mai multe detaliiDe 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 com-plexitate
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ânci-mea de culoare.
API bazat pe un DOM accesibilSVG-urile au un DOM, fapt care des-
chide 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 face-o î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 bazate pe documente ser 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.
Request-uri HTTP reduseDacă 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.
SVG-urile pot fi folosite pentru SEOSpre 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 bot-urile 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.
Câteva dezavantaje…Nu ar fi corect să nu amintim aici și
câteva dezavantaje pe care le implică utili-zarea de SVG. Din fericire, sunt puține cele care trebuie amintite:
Dezvoltare complexă Codul SVG care este structurat prin
XML poate fi destul de lung și de complex, dificil de corectat.
Probleme de performanță În cazul folosirii multor animații
complexe, motorul WebKit poate deveni considerabil mai lent.
Nu este suportat complet de browsere mai vechi (Internet Explorer 8 și versiuni mai vechi)
Există însă și soluții prin care se poate extinde suportul oferit de browsere, cum ar fi Raphael.js sau folosirea tehnicii de înlocuire a SVG-urilor cu imagini statice pentru browserele mai vechi.
Utilitatea SVGSă vedem cîteva aplicații practice ale
SVG.
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 requ-est-uri AJAX, input-ul utilizatorilor sau date generate în mod aleatoriu.
Hărți 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 complexeUneori 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ă dese-năm elementele într-un editor grafic și să îl salvăm sub formă de fișier SVG. Acest fapt ne-ar permite să avem un singur element scalabil și să nu ne facem griji în privința controlării mai multor div-uri.
Logo-uriMajoritatea logo-urilor sunt grafice
bazate pe vectori. Prin urmare, de ce nu am putea defini un document SVG ca logo-ul nostru și să îl plasăm oriunde, sca-lându-l ușor la orice dimensiune e nevoie, fără să compromitem calitatea și salvând în același timp și lățimea de bandă?
Jocuri ușoareChiar dacă CANVAS este mai potrivit
pentru redarea de jocuri (jocuri care folo-sesc grafică și animație bazate pe pixeli), SVG ar putea fi o alternativă viabilă pentru jocurile simple, care necesită mai puțină animație pentru personaje și mai mult spațiu pentru afișarea de informațiii ( de exemplu Sudoku).
AD-uri responsiveConținutul AD-ului ar ocupa spațiul
oferit de document și, luând în considerare că CSS și JavaScript-ul sunt permise, majo-ritatea acțiunii ar fi limitată la un singur fișier SVG pe AD
Linkuri utilePrincipii de bază pentru folosirea SVG : http://www.w3schools.com/svg/svg_intro.aspFolosirea 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-ResponsiveSVG Vs Canvas: http://www.sitepoint.com/7-rea-sons-to-consider-svgs-instead-of-canvas/SVG și SEO: http://www.rocketmill.co.uk/exploiting-svg-images-for-seoExemple de SVG: http://www.creativebloq.com/design/examples-svg-7112785
Avantajele folosirii SVG (Scalable Vector Graphics)programare
25www.todaysoftmag.ro | nr. 27/septembrie, 2014
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:
Prioritatea noastră este satisfacția clientu-lui 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 outso-urcing, mediu care este considerabil diferit.
Este mai mult decât continuous de-ployment
Uitându-ne la știrile din mediul IT apar tot mai multe instrumente care să faciliteze accesul în etapa numită livrare în mod con-tinuu. Când voi putea să învăț toate aceste instrumente dintre care menționez câteva precum puppet, chef, varant, Go CI ? Și mai mult, cine ne va pune la dispoziție timp pen-tru a le integra în proiectele noastre care sunt deja în urma față de planificarea managerilor noștri.
Eu cred că trebuie să ne întrebăm ce vom câștiga prin a implementa primul dintre principiile agile, iar răspunsul este feedback. Pentru a ne asigura că recunoaștem valoare așa cum este specificat în primul principiu, trebuie să învățăm ce înțeleg clienții și busi-ness-ul prin valoare, exact la fel cum facem și cu atributele de calitate. De fapt, în acest context valoare este calitate și vice-versa. De ce trebuie să recunoaștem valoarea? Deoarece trebuie să ne dăm seama când am reușit să o atingem sau măcar cât mai avem nevoie până o vom atinge.
Dar de ce afirm toate aceste lucruri?
Pentru că am văzut o mulțime de prezen-tă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 livra-rea continuă ci și oamenii de business. Dar dincolo ce surprind aceste prezentări, ese 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 success î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 FowlerIntegrarea continuă este practică a dez-
voltării software în care membrii unei echipe integrează ceea ce livrează des, de obicei fiecare persoană integrează munca proprie cel puțin o dată pe zi - ceea ce conduce la mai multe inte-grări pe parcursul unei zile.
Continuous Delivery vs. Continuous Deploy-ment, Martin Fowler
Livrarea continuă se referă la ideea că aplicația este în permanent într-o stare în care poate fi pusă în producție. Deployment continuu este de fapt punerea în producție a aplicației la fiecare schimbare de cod, în fiecare zi sau chiar mai des.
Atunci când am citit primul fragment mi-am spus: „Interesant, deployment conti-nuu e mai bun decat livrare continuă!” și acum câțiva ani s-ar putea să fi avut dreptate. Jez Humble a spus la un moment dat că livrarea continuă nu are nevoie de deployment con-tinuu, iar vice-versa nu e neapărat adevărat. Însă acum eu cred că este mai important să fii alături de business, iar utilizarea de deploy-ment continuu doar în mediul de acceptanță nu este suficientă. A acorda businessului dreptul de a pune aplicația în producție este ceea ce înseamnă de fapt livrare continuă. Chiar mai mult, unele companii au diminuat
Software Architect@ ISDC
programareprogramare
26 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
programare
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ă într-o firmă de outsourcing? De cele mai multe ori nu are acces la oamenii din business, în cel mai bun caz poate doar acces limi-tat, 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 într-un 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 atribu-tele 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 tre-cem 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 cosiderat 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 conti-nuă, 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 deployment-ul ș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.
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ă produ-ceam 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 ter-minat și mai departe: terminat - ca și instalat în producție, în mâinile utilizatorilor.
Recent am auzit o prezentare a lui Adrian Cockcroft, ex-archi-tect ș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 într-un 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ă înce-pem 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 creea 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 înseamană calitate pentru busi-ness. Să nu cazi în capcanele comune: ce inț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ștele împreună cu ei într-un mod cuantificabil și construiește mecanisme automate care să verifice
Livrarea continuă
27www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINE
că sistemul 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 paralizie-prin-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 sucese. Așa că pe lângă măsuratorile 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 scrip-turi 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 continuePână în acest punct am descris în principal de ce și cum
adoptarea practicii de livrare continuă ajută o organizație, sau în conextul 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, prio-ritizat 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 pen-tru 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
28 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
funcționa totul corect. Pentru a obține aceast lucru va trebui să versionam totul, nu doar codul, ci și configurările, cerințele funcționale, scripturile de instalare, API-urile, și orice alt-ceva 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 pro-cedura 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 poti 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 deploymentNoi 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 con-struire î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 pipeline-ul pe care îl aveți momentan. Sunt sigur că există unul, încercați să îl vizualizați - folosind kanban boards; vedeți unde se acumu-lează 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 artefac-tele 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 asam-blarea 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 tes-tele 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 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 sublinat î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 fie-care 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
ConcluziiUnii proabil 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 desco-perite sau lecțiile învățate.
programareLivrarea continuă
29www.todaysoftmag.ro | nr. 27/septembrie, 2014
programare
Detectarea fraudelor cu Titan
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 suplimen-tar 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 dife-rite 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 vre-odată (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 gra-phDB nou; proiectul a fost început în 2012 de către Aurelius1 și a fost conceput cu gân-dul 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 vizua-lizarea 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/
Amplificarea recentă a fenomenului jocurilor de noroc online arată că vor exista întotdeauna oameni care vor încerca să ocolească sau să evite complet comporta-mentul 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.
programare
Florin Mă[email protected]
Senior Java Developer@ Betfair
30 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
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/ dezvol-tatori – 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 procesu-lui 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.
Implementarea Spider Am decis să utilizăm Titan împreună cu Cassandra (pentru
persistență) și Elastic Search (pentru indexare/ căutare rapidă). Modul în care am fasonat problema noastră a fost să reprezen-tăm conturile drept noduri (stocând datele de înregistrare drept atribute ale vârfurilor), dar pentru că se cerea o căutare logică cu specificator ambiguu, am trebuit să stocăm atributele în text clar. Acest lucru nu ne-a făcut prieteni cu departamentul de securitate, deoarece ei aveau reguli stricte în legătură cu stocarea datelor per-sonale de identificare în NoSQL, dar a fost un compromis pe care am fost nevoiți să îl facem.
Am folosit fire multiple pentru a popula inițial graficul uti-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
noastre de potrivire impuse de către echipa de fraudă și a crea liniile corespunzătoare. Un exemplu simplu de reprezentare gra-fică 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 date-lor, 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 rezultatelor, stocarea rezultatelor în Cassandra și trimiterea către solicitant a unui mail cu un fișier zip conținând toate fișierele csv cu rezultatele.
ConcluzieÎn general, Titan este un instrument pe care l-aș recomanda
dacă scenariul dumneavoastră de afacere solicită o reprezentare grafică bazată pe java a datelor voastre model și aveți nevoie de traversare rapidă și scalabilitate progresivă. Este un framework amuzant cu care să lucrezi, iar proiectul de patru luni a dovedit că este o soluție fezabilă. Deci concluzia mea este: Betfair + Titan = love!
programareDetectarea fraudelor cu Titan
31www.todaysoftmag.ro | nr. 27/septembrie, 2014
programare
Pragmatismul 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 într-o 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 ”geamu-rilor sparte” în crearea codului. Aceasta se poate referi la o porțiune de cod neimple-mentată, 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 încura-jează 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 codu-lui 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”.
DuplicareDuplicarea 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:
Pragmatism în programare
programare
Mihnea Lază[email protected]
Java Developer@ msg systems
32 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
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.
Îndeajuns de bunAdeseori, în situațiile de realizare a unui proiect
la care s-a acordat timp insuficient, se propune uti-lizarea noțiunea de good-enough software. Această noțiune propune o implicare mai mare a utilizato-rului, 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.
ContracteSocietatea 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 com-portamentului ș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
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 limba-jul de programare ales, cu atât mai bine își poate face munca. Codul realizat cu acest limbaj de programare este scris prin inter-mediul 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
programare
CONFERENCE2014
33www.todaysoftmag.ro | nr. 27/septembrie, 2014
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ă for-mulă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, tre-buie 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 proble-mele 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.
Geanta de cunoștințeOdată 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 pro-gramare 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 per-soane 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:
• 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.
BibliografieThe Pragmatic Programmer: From Journeyman to Master – Andrew Hunt, David Thomashttp://www.manhattan-institute.org/pdf/_atlantic_monthly-broken_win-dows.pdf
34 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
programare
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 ent r u a ad ăuga nou 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 meto-dele î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 impor-tantă 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 exem-plu, 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 lizibi-litatea și documentația codului. Pentru dezvoltatori va fi foarte ușor să înțeleagă ce face codul și ce ar trebui să facă controlul
din spatele acelui IF sau WHERE.
Un singur lucru de făcutDacă 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, trans-formi rezultatul într-un alt tip și te ocupi de cazurile speciale. Fiecare dintre lucru-rile 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 sim-plă, 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țieAcesta poate fi un mecanism care ne
poate spune că funcția face prea multe lucruri. De exemplu, o funcție care pro-cesează 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 SwitchPovestea 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 pen-tru a separa funcțiile. Chiar dacă facem acest lucru, nu va fi ok, deoarece încălcăm principiul unicei responsabilități (Single
Î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.
Clean code – Funcții
35www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINE
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 descriptiveNumele 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 pre-cum 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 des-tul 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țieiCâ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 conține rezultatul conversiei. Aceasta ar putea semnala că metoda face prea multe lucruri – transformări și verificări.
Fără efecte secundareAceasta este situația în care funcția ta
face mai mult decât un singur lucru, dar fără a spune clientului. De exemplu, o metodă READ care citește conținutul unui fișier și apoi îl șterge fără a notifica utiliza-torul. În acest caz, utilizatorul ar trebui să fie înștiințat despre această acțiune sau, cel puțin, ar trebui să știe de ea din momen-tul în care face apelarea - ReadAndDelete (Citește și șterge).
Din cauza acestor efecte secundare, putem avea cuplări temporare. De exem-plu, când funcția GoLeft poate fi apelată numai dacă a fost apelată StartEngine. Ar trebui să vă gândiți la o modalitate de a expune numai metodele care sunt disponibile la un anumit moment, fără a crea cuplări temporare. De exemplu, StartEngine poate returna un obiect care are numai comenzi ca GoLeft, GoRight, etc.
Comandați separarea cereriiO funcție ar trebui să facă numai un
singur lucru. Nu ar trebui să aveți nicio-dată 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 codProducerea 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 ero-nat produs.
Pentru aceste cazuri, proiectarea unei excepții este mai bună și va simplifica munca clienților. În plus, tratarea erorilor va fi 100% separată de logica ta.
Extrageți blocurile try/catchUn cod care conține astfel de blocuri
sunt destul de urâte și lungi. Din această cauză, toate aceste blocuri de cod ar tre-bui să fie extrase în funcții separate. Blocul TRY poate fi pus într-o funcție și blocul CATCH poate fi pus într-o altă funcție.
Nu vă repetațiTot codul care este duplicat ar trebui
extras într-o funcție separată. Nu doar veți reduce numărul de linii de cod, dar vă veți și ușura viața atunci când va fi nevoie să se facă o modificare. Este mai ușor să modi-fici numai o linie de cod decât să cauți și să modifici toate locațiile în care codul este duplicat.
Lucruri mărunteDupă cum puteți vedea, lucrurile
mărunte pot face o mare diferență între o funcție bună și una proastă. Nu este nevoie să faci sau să știi te miri ce nebunii pentru a fi capabil să scrii funcții „fericite”. Ținând cont de aceste recomandări veți putea scrie un software mai bun, care peste 10 ani va fi întreținut mai ușor și cu mai puțini bani.
Radu [email protected]
Senior Software Engineer@iQuest
36 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
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țiuniilor 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ă-si facă mai puține griji pentru cum să trimită request-uri sau să parseze JSON și să mapeze rezul-tatele 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 ase-menea 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 frame-work. 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ă.
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.
ExempluVoi 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 , insta-larea 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://devel-oper.foursquare.com/docs/venues/search.
De aici veți avea nevoie de client ID și client secret, pe care le puțeti 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 setupul și toți pașii ceruți, puteți testa serviciul și observa că în răspunsul serviciul veți avea cam
37www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINE
întodeauna 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”: “4bf58d-d8d48988d1e0931735”, “name”: “Bar”, „pluralName“: “Bars”, “primary”: true, „shortName“: “Bar” } ], “contact”: { “formattedPhone”: “(408) 446-9000”, «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”: “4bf58d-d8d48988d1e0931735”, “name”: “Bar”, „pluralName“: “Bars”, “primary”: true, „shortName“: “Bar” } ], “contact”: { “formattedPhone”: “(650) 321-2161”, «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 codAcum că avem toate piesele la un loc, putem începe să con-
struim 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 valo-riile JSON returnate de catre serviciu.
După ce examinăm un pic JSONul de mai sus, putem crea o clasa Locatie care să extindă NSObject. De dragul simplitaț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 pref-erat 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 = [[RKObjectMan-ager alloc] initWithHTTPClient:client];
arhitectură
TODAY SOFTWARE MAGAZINE
38 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
programare
// setup object mappings RKObjectMapping *venueMapping = [RKObjectMapping mappingForClass:[Venue class]]; [venueMapping addAttributeMappingsFromArray:@[@”name”]]; // register mappings with the provider using a response descriptor RKResponseDescriptor *responseDescriptor = [RKResponseDescriptor responseDescriptorWithMapping:venueMapping method:RKRequestMethodGET path-Pattern:@”/v2/venues/search” keyPath:@»response.venues» statusCodes:[NSIndexSet indexSetWithIndex:200]]; [objectManager addResponseDescriptor:responseDescriptor];}
În metodă, definim baza URLului despre care vorbeam și mai devreme, pentru APIul Forsquare. Toate request-urile vor fi leg-ate de acest URL.
Clasa RKObjectManager definește maparea dintre un atribut JSON și atributul corespunzător din data model. addAttrib-uteMappingsFromArray 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” : cli-entID, @”client_secret” : clientSecret, @”categoryId” : @”4bf58dd8d48988d1e0931735”, @”v” : @”20140118”}; [[RKObjectManager sharedManager] getObjectsAt-Path:@”/v2/venues/search” parameters:queryParams success:^(RKObjectRequestOperation *operation, RKMappingResult *mappingResult) { _venues = map-pingResult.array; [self.tableView reloadData]; } failure:^(RKObjectRequestOperation *operation, NSError *error) { NSLog(@“Din pac-ate nu sunt baruri in zona…’: %@”, error); }];}
@interface MasterViewController () @property (nonatomic, strong) NSArray *venues; @end
@implementation MasterViewController
- (UITableViewCell *)tableView:(UITableView *)ta-bleView cellForRowAtIndexPath:(NSIndexPath *)index-Path{ UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@”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 pre-cum harta și butoanele de navigare, ar trebui să avem o listă ca în imagine, funcțcională, cu barurile din jurul nostru.
RestKit pentru iOS
Mihai [email protected]
iOS developer@ Dens.io
39www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINE
Cum poți testa conferințe de testare
Două 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 majorita-tea 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 oca-zia să mă expun la idei care modelează abordarea mea în testare. Și influența nu apare din faptul că am vorbit cu oameni ‘fai-mosi’. Concepte cum ar fi gândirea critică, testarea exploratorie, euristici, „leaky abstractions”, „game of life”, sisteme “intracta-bile“, 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 oca-zia 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 tes-tare 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 abor-dă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.
evenimente
40 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
evenimente
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 incer-titudine ș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.
Oare cum am ajuns eu să prezint? Răspunsul la întrebarea aceasta nu e unul foarte clar nici pen-
tru mine. Încurajarea de la oamenii din jur cred că a contat. Un coleg
de muncă și apoi Test Managerul cu care lucrez m-au încurajat să 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ă era o ocazie să particip la conferință, cu costuri reduse.
Înainte de prima prezentare pe care am ținut-o, la EuroSTAR în 2013, experiența mea consta în mare parte din reprezentații la serbări școlare de final de an și susținerea lucrării de licență. Mai vorbisem la un eveniment local de testare, dar arătam câteva exerciții de la un atelier la care participasem, deci nu era conținutul meu. În rest nu mai avusesem un public foarte numeros și un cadru formal până atunci (cel puțin din câte îmi amintesc, așa că
dacă am ceva amintiri reprimate, vă rog să-mi înțelegeți omiterea).
Norocul a făcut ca prezentarea mea de la EuroSTAR să fie destul de populară, așa că am mai ținut-o încă o data în aceeași zi, la sesiu-nea numită do-over”, în care se relua pre-zentarea cea mai votată din timpul conferinței. Așa am avut și a doua experiență de vorbit în public la conferințe de testare, în aceeași zi cu
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 oca-
zia 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 pre-zentă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 prezenta-rea 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 repetiții cu orice vrem să spunem. Mi-am dat seama că e folositor să țin cont de asta în unele cazuri când particip la ședințe/discuții și să amân să judec ce a spus o persoană până când am pus între-bările clarificatoare care să mă asigure că era într-adevăr ce vroia să transmită.
Lucrând la prezentări învăț să construiesc argumente puternice Când vreau să afirm ceva într-o prezentare, mă gândesc că fie-
care idee e susceptibilă la diferite reacții ale oamenilor din public. Pentru că nu aș vrea să par superficială și să fiu surprinsă de un contraargument valid (din seria cine ar vrea, și totuși, cui nu i se întâmplă), mă gândesc în ce fel aș putea invalida ipoteza mea și încerc să îmi construiesc argumente pentru diferite feluri de reacții.
Asta mă determină să analizez cât de clară e gândirea mea și să răspund la posibile întrebări din public înaintea prezentării. E un exercițiu bun pentru a-mi contura argumentele pe care le am și pentru a le îmbunătăți.
Îmi amintesc că la una din prezentări încercam să identific motive pentru care nu găsisem în timp util buguri relevante pentru o funcționalitate. Faptul că am pus sub semnul întrebării concluziile mele și am încercat să găsesc contraargumente m-a ajutat să ajung mai în profunzimea situației și să găsesc argumente puternice pentru nevoia de comunicare eficientă și colaborare, pentru euristica de a evidenția în rapoarte și zonele pe care nu le-am acoperit în timpul testării, pentru relevanța cunoașterii informațiilor contextuale care provin din buguri raportate în alte zone decât cele pe care mă concentrez eu, precum și importanța grupării informației în categorii potrivite și accesibile.
Pregătirea prezentărilor mă ajută la clarificarea unor idei Aspectul anterior aduce un alt beneficiu. Căutând să îmi
Cum poți testa conferințe de testare
41www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINE
î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 pro-iectul 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.
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 eve-
nimentele ș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 sen-sul 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 desco-păr doar prezentând din nou.
Ce e interesant pentru public Î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 pro-fund 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.
Alexandra [email protected]
Software Tester@ Altom Consulting
42 nr. 27/2014 | www.todaysoftmag.ro
programare
Dragi 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.
După cum vă puteți imagina cu toții, suportul profesional este luat mereu în considerare în toată industria. Prin sim-pla căutare pe diverse motoare de căutare (cum ar fi Google), termenul ,,business analyst” (analist business) subliniază fap-tul că profesioniștii din acest domeniu sunt la mare căutare. O multitudine de joburi sunt oferite în prezent de către multe com-panii 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 tehno-logia 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?
Am fost întrebați mereu cum poate cineva să treacă de la asigurarea calității la rolul de analist business. De aceea, acest
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 departa-ment. 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 schim-bare”. 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 înce-put prin simpla schimbare a echipelor și a domeniilor. Sunt sigură că fiecare dintre noi și-a abordat în mod inconștient rolul
Tranziția de la QA la BA
diverse
Monica [email protected]
Senior Business Analyst@ UNIQA Raiffeisen Software Service
43www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINEprogramare
de QA (asigurarea calității) ca și un aspi-rant 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ă demon-strez 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 afa-cerii, 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 proble-melor pentru a concepe o soluție care să îndeplinească toate cerințele.
Din punctul meu de vedere, ca specia-list QA (inginer în asigurarea calității), te afli într-o poziție favorabilă pentru a afla mai multe despre domeniul analizei busi-ness. 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 momen-tul 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, metamor-foza 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 busi-ness 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 sta-keholderii (toate părțile implicate) în jurul acestei idei. A fi capabil să tratezi lipsa de precizie, cooperarea și să facilitezi comu-nicarea, 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 busi-ness 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 ana-list 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 busi-ness, 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!
44 nr. 27/2014 | www.todaysoftmag.ro
programare
Time 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 profesio-
niste ș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-oară cu genul lui sau cu orice alt joc. Tot ce trebuie să faci este să îți conduci naveta pe ecran, folosindu-te de un singur deget. Povestea spune că John Q. Dude, aviator și temerar neînfricat al zilelor noastre, ajunge dintr-o greșeală a prietenului lui, profeso-rul Klumsey, într-o preistorie cartoony și deloc “historically accurate”. Avionul, la rândul lui, s-a transformat într-unul rea-lizat 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 dis-pă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 com-binare între grafică 2d, grafică 3d, sunete
și muzică. Avantajul tehnologic și-a spus cuvân-
tul. Pe partea de programare, puternicul engine Unity 3d ne-a permis să profităm
Time Dude, un joc 3D cross
mobile platform
45www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINE
din plin de spațiul 3d și de puterea ter-minalelor 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 audio-vizual, 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 ches-tiunile 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ârste-lor. 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 comen-tariile sfătoase ale personajului principal. Așadar, e jucabil de la pitic la bunic.
Unul dintre punctele forte ale jocu-lui este că reprezintă un produs aparte în nișa lui. În general, arcade flying shooter-ele 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, deci-zii 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 pasi-une investită.
La proiect a început să se lucreze în ianuarie 2014, iar acum, în septembrie se finalizează prima versiune a jocului nos-tru. 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 speci-aliză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 dori-torilor, conținut de calitate.
Liviu [email protected]
2d/3d artist, animator@ ReeaAnimation
46 nr. 27/2014 | www.todaysoftmag.ro
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.
Așa cum probabil știți deja, negocierea contractuală nu presupune neapărat apli-carea 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 prac-tică. 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 parte-
nerul dvs. și să stabiliți punctele principale ale înțelegerii pe care o aveți în plan, pre-cum: aspectele comerciale ce țin de preț și de termenele de plată, care sunt miles-tone-urile, în cât timp trebuie acceptate livrabilele. Celelalte detalii pot fi discu-tate și pe parcursul sau ulterior redactării contractului.
De asemenea, acordați atenție momen-tului când finalizați negocierile asupra elementelor esențiale și “bateți palma”;
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 part-enerului
Î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 proprie-tate 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 (des-tul 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 persona-liza codul sursă al respectivei aplicații și
Claudia [email protected]
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ă.
47www.todaysoftmag.ro | nr. 27/septembrie, 2014
TODAY SOFTWARE MAGAZINEtestare
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 respecti-vul 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
Pentru a nu omite aspecte relevante, nu vă grăbiți când analizați contractul și modificările sau sugestiile făcute de cea-laltă 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 fi negociate până se ajunge la un consens.
La semnareDacă este vorba de un contract impor-
tant, 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 spe-cifice ; datarea corectă a contractului (în special dacă semnarea contractului are loc la distanță – de exemplu, pe e-mail), etc. .
Apelați la specialiștiEste de preferat să beneficiați de aju-
torul specialiștilor încă de la începutul discuțiilor contractuale – avocați specia-lizați dar și contabili, consultanți fiscali. Pentru ca aceștia să vă poată asista cât mai eficient în toate fazele redactării contrac-tului și pe durata negocierilor, trebuie să le oferiți detaliile și instrucțiunile nece-sare, 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ă dezvoltato-rului 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 clau-zele 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.
Iar ca notă de final: ascultați-vă instinctul!
48 nr. 27/septembrie, 2014 | www.todaysoftmag.ro
- Ssiga-ssiga..., zâmbi Gogu la aminti-rea 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, evi-dent 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 nos-tru?! 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ân-gea 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 con-vins, da’ el zicea așa semn c-o înțeles ce i-am spus noi, nu că era de acord. Că dup-aia 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 obiceiu-rilor pe care le-am moștenit și care ne-au înconjurat, a credințelor părinților, rude-lor, prietenilor alături de care am crescut. Iar acestea sunt diferite de experiențele prin care trec oameni din alte părți ale glo-bului. Ș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 supraveghe-torul de sală... ha-ha, mai ții minte că nu pricepeam ce vrea el cu supraveghetorul?!
Dar gata cu gluma acum, treci la stu-diat 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ă sentimen-tul 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
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 peri-oada 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 difi-cilă... Cât despre planificarea strictă, uit-o. Timpul are – pentru ei - o altă semnificație. Propune-le o planficare 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 livra-rea 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 ‚,ghinio-nului’’. 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...
Gogu în şoc... cultural
management
Simona Bonghez, [email protected]
Speaker, trainer and consultant in project management,
Owner of Colors in Projects
powered by
sponsori