today software magazine n3/2012

47
TO DAY SOFTWARE No. 3 / 2012 www.todaysoftmag.ro MAGAZINE Ediţie Specială Interviu cu Mihai Tătăran Co-fondator ITCamp Cod nativ vs. cod portabil în dezvoltarea aplicaţiilor mobile Metoda de estimare Function Point Managementul Calității Big Data - Reprezentarea datelor Microsoft Kinect - Ghid de programare Tendințele în HR Proiectul CIVITAS – Archimedes IASI Avantajele unui MBA Guice Startup - Hack a server Think iCloud

Upload: sergiucebotari

Post on 31-Jul-2015

74 views

Category:

Documents


6 download

TRANSCRIPT

Page 1: Today Software Magazine N3/2012

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

No. 3 / 2012 • www.todaysoftmag.ro

M AG A Z I N E

Ediţie Specială

Interviu cu Mihai TătăranCo-fondator ITCamp

Cod nativ vs. cod portabil în dezvoltarea aplicaţiilor mobile

Metoda de estimare Function Point

Managementul Calității

Big Data - Reprezentarea datelor

Microsoft Kinect - Ghid de programare

Tendințele în HR

Proiectul CIVITAS – Archimedes IASI

Avantajele unui MBA

Guice

Startup - Hack a server

Think iCloud

Page 2: Today Software Magazine N3/2012
Page 3: Today Software Magazine N3/2012

6Interviu cu Mihai Tătăran

Co-fondator ITCampMarius Mornea

12Cod nativ vs. cod portabil

Ion Ionuț

16Metoda de estimare

Function Point Ionel Mihali

21Managementul calităţii

Eugen Otavă

24Big Data

Cătălin Roman

27Microsoft Kinect

Echipa Simplex

29Tendinţe în HR

Andreea Pârvu

31Proiectul Civitas Arhimede - IaşiSebastian Botiș

33GuiceMădălin Ilie

36Programarea concurentă modernăBéla Tibor Bartha

38Avantajele unui MBASorin Stan

40Startup - Hack a serverMarius Corîci

43Think iCloudZoltán, Pap-Dávid

45GoguSimona Bonghez

Page 4: Today Software Magazine N3/2012

4 nr. 3/2012 | www.todaysoftmag.ro

Editorial

Care este revista ta de programare preferată? Aceeași întrebare se regăsește pe roll-up-ul de participare la ITCamp, cea mai mare conferință pe tehnologii Microsoft din Transilvania. Este un fel de TIFF pentru programatori, fiecare

participant putând alege în funcție de interes una din cele trei prezentări ce se desfășoară în paralel pe durata a două zile. Ne bucurăm că putem fi alături de cei 250 de participanți din anul acesta și promitem să revenim cu impresii. Numărul #3 este de altfel o ediție specială ITCamp și a fost oferită tuturor participanților. Mulțumim organizatorilor pen-tru suportul acordat și de asemenea celor trei sponsori ai revistei: ISDC, Small Footprint și Three Pillar Global.

Odată cu acest număr se marchează intrarea într-o etapă nouă, mai tehnică, menită să detalieze mai multe dintre subiectele articolelor precendente. Menționăm în acest sens articolele despre programarea device-ului Kinect sau Big data. Atingem un subiect la modă prin iCloud, stocarea și sinchronizarea datelor în ecosistemul Apple. Pe partea de dispozitive mobile, un articol interesant este Cod nativ vs. cod portabil unde sunt evidențiate opțiunile pe care le avem pentru dezvoltarea aplicațiilor în funcție de nevo-ile clienților: complexitate, buget sau timpul alocat dezvoltării. Cum estimăm resursele necesare pentru a executa un proiect? Este o întrebare la care se încearcă să se răspundă în articolul Metoda de estimare Function Point. Managementul calității este un subiect important pentru partea de testare a produselor și care a fost acoperit în acest număr. De asemenea, tendințele din HR este un articol care merită citit atât de către angajați, dar și de angajatori pentru a realiza o politică echilibrată de creștere. Revenind la inițiativele locale, prezentăm un proiect dezvoltat 100% de catre o companie clujeană pentru creeare de chioșcuri automate ce permit cumpărarea biletelor de autobuz. Acesta este pus în producție în Iași, iar în paginile revistei gasiți informații despre implementarea proiectu-lui și arhitectura folosită. Un alt proiect românesc este și startup-ul Hack a Server care a început deja să reunească administratorii de sisteme și hackerii într-un scop constructiv, pentru protejarea mai bună a datelor. De ce este bine să ne certificăm? este o întrebare la care încercăm să răspundem în două articole: Avantajele unui MBA și problemele perso-najului din revista: Gogu.

Revista începe să primească suportul comunităților și a companiilor locale iar dacă va face plăcere să o răsfoiți, trimiteți-ne impresiile voastre pe adresa [email protected].

Mulţumesc,

Ovidiu Măţan

fondator Today Software Magazine

Ovidiu Măţan, [email protected]

Coordonates Gemini Solutions Cluj’s team, in the past worked as a Product Manager for Ovi Sync at Nokia, founder of Today Software Magazine.

editorial

Page 5: Today Software Magazine N3/2012

5www.todaysoftmag.ro | nr. 3/2012

Redacţie

Fondator / Editor in chief: Ovidiu Mățan / [email protected] (startups și interviuri): Marius Mornea / [email protected]

Graphic designer: Dan Hădărău / [email protected] marketing: Ioana Fane / [email protected]

Reviewer: Romulus Pașca / [email protected]: Tavi Bolog / [email protected]

Produs de Today Software Solutions

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

www.todaysoftmag.rowww.facebook.com/todaysoftmag

twitter.com/todaysoftmag

ISSN 2284 – 6352

Page 6: Today Software Magazine N3/2012

6 nr. 3/2012 | www.todaysoftmag.ro

Interviu cu Mihai Tătăran Co-organizator ITCamp

note primite după eveniment, iar noi avem patru astfel de oameni”. Focus-ul pe tehno-logii Microsoft provine tocmai din această dorință de a aduce cei mai buni speakeri posibili, iar Microsoft este locul unde relațiile și experiența celor doi fondatori le permit accesul cel mai bun, „Dacă ne-am împrăștia pe mai multe zone [tehnologii] ne-ar fi mai greu să facem asta„.

ITCamp este anul acesta la a doua ediție, experiența de anul trecut putând fi rezumată în: „o conferință pilot, care să fie la nivel național definitorie pentru România în acest moment, pentru teh-nologii Microsoft, iar în timp să devină definitorie pentru Europa Centrala și de Est. Obiectivul l-am atins: au venit peste 200 de participanți, am avut peste 20 de speakeri, cu o distribuție a audienței de peste 50% la nivel senior”. Tocmai acest nivel înalt al pregătirii participanților fiind una din metricile cele mai importante pen-tru calitatea evenimentului, din perspectiva organizatorilor.

Față de anul trecut, ediția curentă a

cunoscut o creștere semnificativă în ceea ce privește numărul și diversitatea vorbito-rilor, totalul ajungând la 34, iar distribuția variind de la nume mari internaționale, pana la vorbitori noi, de pe plan local. Aceste creșteri se datorează atât feedbacku-lui din partea participanților de anul trecut „Da! vrem ITCamp la anul și Da! vrem să fie mai mare”, cât și strategiei pe termen mediu „Să devenim Conferința de tehno-logii Microsoft din Europa Centrala și de Est. Pentru asta trebuie să depășim inclu-siv niște criterii de cantitate [..] speakerii extrem de populari nu vin la conferințe relativ mici, și există un prag psihologic, undeva la 500 de participanți, pe care tre-buie să îl depășim. [..] Iar ca să ai atâția oameni, evident îți trebuie și diversitate de conținut mai mare. Participanții trebuie să poată să aleagă în fiecare slot de timp ceva util pentru ei.”

Iar dacă am ajuns la conținut să ne oprim un pic asupra tematicii și organi-zării prezentărilor din cadrul conferinței. Organizatorii au ales pentru anul acesta să împartă agenda în trei track-uri principale,

Interviul acestui număr diferă față de cele anterioare prin subiectul principal: conferința ITCamp, reprezentată în timpul interviului de Mihai Tătăran, co-fondator al acesteia (alături de Tudor Damian).

Așadar să începem cu introducerea intervievatului nostru: conferința ITCamp 2012 „este o conferință premium pentru specialiști pe tehnologii Microsoft”, iar calificativul „premium”, în viziunea organizatorilor, este împrumutat de la calibrul invitaților, „cei mai buni speakeri pe care putem să îi aducem [..] oameni extrem de cunoscuți, care la conferințele cele mai mari din lume, gen: TechEd sau PDC, ies constant în top 10, ca

interviu

Mihai Tătă[email protected]

Microsoft MVPCo-organizator ITCampAvaelgo

Marius [email protected]

Fost senior software developerin cadrul Nokia, în prezentfondatorul platformei MintakaResearch

un interviu realizat de:

Page 7: Today Software Magazine N3/2012

7www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

față de două, anul trecut, alegerea fiind motivată: „numai din cauză că am avut conținut mult.” Un track este mai exact o forma de organizare, nu neapărat o temă aleasă cu grijă în prealabil, și vrea să însemne că: „în principiu în sala asta, despre asta se va vorbi”, participanții fiind liberi să își aleagă prezentări din oricare track la un moment dat.

Spre deosebire de anul trecut, când tematica track-urilor a fost aleasă din perspectiva publicului țintă: dezvoltatori versus administratori, anul acesta track-urile sunt împărțite în funcție de conținutul efectiv al prezentărilor, pentru că s-a constatat o disproporție mare, numărul dezvoltatorilor dominând audiența (95%). „Primul track este despre Cloud: Public Cloud cu Windows Azure, Office 365; Private Cloud cu colocare, hosting, servere, securitate. Al doilea track este pentru pro-gramare, efectiv scris aplicații.”

Ambele track-uri mai au în comun și faptul că majoritatea speakerilor sunt internaționali sau cu experiență bogată în conferințe, pe când în ultimul track: „am încercat să aducem oameni de la sponsori, care vin cu o experienta foarte adâncă pe un anumit lucru, [..] și pot să vorbească despre un anumit subiect pentru că asta au făcut în ultima vreme”. Această noutate provine și dintr-un obiectiv mai ascuns al organizatorilor și anume: „trebuie să creștem paleta de speakeri care vin la astfel de evenimente și cineva trebuie să facă primul pas”. Prezentatorii vor fi „oameni care nu sunt neapărat obișnuiți să vorbească în public, dar sunt foarte buni programatori sau arhitecți în firma lor”. Având în vedere că la ora actuală există un grup restrâns de oameni cu experiență în acest domeniu, iar cel puțin pe tehnologii Microsoft discutăm de un grup mic, bine coagulat și foarte concentrat în densitatea de MVPs (Most Valuable Professional) și Regional Directors, această deschidere spre împărtășirea experienței și creșterea numărului de speakeri este bine venită. Mai ales că experiența acumulată nu este doar tehnică, ci vine din partea unor oameni care organizează mai multe conferințe, dar și participă frecvent, atât ca speakeri, cât și ca simpli participanți la conferințe internaționale de cel mai înalt nivel.

Pentru că tot am atins subiectul vorbi-tori, să ne oprim un pic asupra invitaților de anul acesta la ITCamp. În primul rând

a crescut numărul, de la 20 la 34, în al doi-lea rând a crescut diversitatea. Dacă anul trecut aveam doi Regional Directors și zece MVPs, anul acesta avem mai mulți din fie-care, dar și categorii noi gen: Community PM, Azure Insiders și experți locali. Înainte de a trece la o descriere individuală, aș dori să lămurim pe scurt ce înseamnă fiecare categorie: începem cu cei mai numeroși (cca. 2500 la nivel mondial), specialiștii într-o singură tehnologie specifică: MVP (Most Valuable Professional); urmați de Regional Directors, care sunt mai cunoscuți și au experiență într-o gamă mult mai largă de tehnologii, practic cunoștințele lor acoperă complet Microsoft Application Platform, prin urmare sunt și mai putini (cca. 150 la nivel mondial); un titlu mai nou: Azure Insider, care denotă un grad și mai ridicat de specializare decât un MVP și este dedicat Azure; iar în ultimul rând Community PM, un angajat al Microsoft care reprezintă interfața dintre companie și comunități, coordonând programele MVP, RD, etc. Mai multe detalii despre ce înseamnă fiecare, cum ajungi și ce benefi-cii ai într-o astfel de poziție vor fi date de către Alessandro Teglia (Community PM) în cadrul conferinței.

Trecând la vorbitori în parte, timpul nu ne va permite să ii prezentăm pe fiecare, așa că vom alege câteva din numele mai cunos-cute pe plan internațional și vom începe, respectând ierarhia în care sunt prezentați și pe site-ul conferinței. Ordinea nu este întâmplatoare: „e clar că noi, gazdele, ne-am pus ultimii și e clar că am încercat să îi punem primii pe cei pe care îi consi-derăm noi cei mai cunoscuți în industrie, nu neapărat cei mai buni [..], dar oameni mai vizibili.”

În primul rând începem cu Tim Huckaby un: „greu din toate punctele de vedere, [..] a fost speaker în keynoteuri cu Bill Gates și Steve Balmer, nu o dată, [..] extrem de cunoscut în zona de consultanță, iar dacă te uiți la un Grey’s Anatomy vezi în sala de operație un ecran cu Microsoft Surface, aplicație făcută de el”. El va vorbi despre Natural User Interface, un pro-iect dezvoltat în parteneriat cu Microsoft Research, și ne va prezenta, în cadrul keynote-ului de la ITCamp, același demo care a fost prezentat în premieră mondială în Israel acuma două luni. Tim a răspuns invitației la un pahar de vin, când Mihai i-a promis o excursie la castelul lui Dracula.

Lino Tadros este: „un om foarte tehnic, un pic mai mult decât toți [..] smart în sen-sul cel mai pur al unui programator [..] a fost ani de zile mâna dreaptă a lui Anders Hejlsberg (inventatorul Turbo Pascal, prin-cipal arhitect Borland Delphi și C#)”. El va vorbi mai mult despre aspecte practice legate de dezvoltarea în Windows 8 Metro și Windows Phone.

Alessandro Teglia, deși nu are o intrare dedicată în agendă, va avea alocată o secțiune din keynote în care ne va vorbi despre comunități și rolul evenimentelor gen ITCamp în dezvoltarea acestora.

În ultimul rând am încercat să aflam cine va face parte și ce tematică va fi aco-perită în secțiunea Open Panel, atât din cauză că anul trecut, aceasta a avut mare succes și a fost una dintre cele mai interac-tive și interesante prezentări, dar și pentru că intră în conflict cu prezentarea despre WinRT a lui Rialdi. Conținutul secțiunii este încă indecis, pentru că organizatorii preferă să propună tematica doar după ce au luat pulsul conferinței și au ocazia să includă feedbackul participanților. Cu toate acestea, am fost asigurați că în cazul oricăror conflicte în interesele din agendă, toate conferințele sunt înregistrate și sunt puse la dispoziția participanților, pe site-ul evenimentului. La început doar pentru participanți, iar după șase luni sunt dispo-nibile publicului larg.

Păstrându-ne în zona de tematică și conținut am pornit o discuție despre tehno-logiile prezentate și posibile recomandări asupra conferințelor. Înainte de o discuție specifică, am dorit să filozofăm despre strategia de marketing prin care ITCamp insistă să fie cunoscută ca și o conferință axată pe tehnologii Microsoft, în condițiile în care o privire asupra agendei dezvăluie o gamă mult mai largă de tehnologii și subiecte, unele foarte generice. „Este ade-vărat că avem sesiuni mai puțin tehnice, de project management, proceduri, șamd. Considerăm că și acele cunoștințe fac parte din arsenalul specialiștilor IT”. Dar în rest se dorește evitarea subiectelor generice, deoarece: „riscul cu acestea este să fie puțin prea generaliste și să nu intri prea adânc în probleme.” Cu toate acestea, în condițiile în care un public IT clujean are și importante componente axate pe alte tehnologii (Java, Ruby, PHP), o astfel de poziționare poate speria un număr semnificativ de posibili participanți. „Pierdem clar, la greu, dar

Page 8: Today Software Magazine N3/2012

8 nr. 3/2012 | www.todaysoftmag.ro

asta dorim: să ne focusăm. Eu îmi doresc să am o conferință la care și eu învăț, practic nu considerăm că pierdem, ci ne selectăm participanții” în dorința de a menține nive-lul ridicat al prezentărilor.

Revenind la discuții mai practice: „sta-rurile din punct de vedere buzzword sunt Windows 8, Windows Phone și HTML5. Dar pentru oamenii din audiență, ei fiind seniori peste 50% (asta a fost distribuția anul trecut și tinde spre 60% anul acesta), pentru ei nu este asa important buzzword-ul, pentru ei e mult mai important ce lucrează acum și ce proiecte le vin în următoarele câteva luni. [..] S-ar putea să ne trezim cu o prezență mult mai mare la o sesiune de aplicații foarte solicitate în ASP.NET, chiar dacă este o chestie foarte veche.” Cu toate acestea: „audiența cea mai mare va fi la speakerii cei mai ca lumea, pe care i-am și sugerat”.

Întrebat în ce măsură publicul poate să influențeze conținutul conferinței, gen posibilitatea unei discuții despre topic-uri care nu sunt prezente în agendă, dar sunt de interes, Mihai a ținut să precizeze că speakerii sunt cei care vin cu conținutul, astfel se poate asigura un nivel tehnic ridi-cat al fiecărei prezentări. „Aceștia sunt speakerii pe care ne dorim să îi aducem obligatoriu, și este o listă destul de lungă, din care jumate îi dorim cu orice preț. [..] Noi știm dinainte cu ce o să vină pentru că ei cu asta lucrează în ultima vreme. [..] Ei lucrează pe ceva în funcție de ce este mai interesant, mai nou, și asta dă până la urmă și direcția industriei”. Cu toate acestea pau-zele de câte 30 de minute dintre prezentări și Open Panelul sunt momente bune pen-tru astfel de filozofări așa că participanții sunt încurajați să profite de ele și să interacționeze cu vorbitorii.

O ultimă curiozitate, vizavi de conținut, a fost în ce măsură are șanse ITCamp să conțină lansări de tehnologii noi sau pre-miere mondiale. Surpriza plăcută a fost să aflăm că, deși evenimentele majore sunt gestionate de departamentul de marketing al Microsoft, unii din prezentatori lucrează pe tehnologii care sunt pe cale să se lanseze și au pregătite prezentări, astfel încât, în eventualitatea unui anunț oficial Microsoft ei vor scăpa de sub incidenta NDA-urilor (Non-Disclosure Agreement) și vor putea face scurte prezentări pe tehnologii de

ultimă oră.

Pe măsură ce ne apropriem de final am hotărât să aruncam o privire asupra aspectelor organizatorice, fiind interesați de bucătăria internă a unui astfel de eveni-ment și rețeta succesului.

În primul rând, contează experiența acumulată prin participarea la conferințe de nivel înalt, iar ecosistemul Microsoft stă foarte bine la acest capitol, TechEd fiind o prezenta constantă în calendarul lui Mihai, începând cu 2003 (inițial susținut de Microsoft Academic program, în perioada studenției, apoi ca și participant plătitor, iar din 2011 „fac parte din staff-ul conferinței [..] sunt niște standuri Technical Learning Centers unde răspund la întrebări despre Azure”), atât participant cât și speaker la DevReach și CodeCamp Macedonia, sau doar participant la MVP Summit. Tudor Damian (al doilea co-fondator ITCamp) are un calendar similar. Pe lângă know-how organizatoric aceste conferințe sunt un canal de comunicare de care cei doi profită pentru a invita vorbitori de nivel înalt la ITCamp.

În a l doi lea rând, contează ș i experiența locală pentru a putea sincroniza cunoștințele organizatorice cu cultura și specificul publicului și industriei esteuro-pene. În această direcție sunt importante evenimentele organizate de ei: CodeCamp (Mihai) și ITSpark (Tudor), dar și ce se poate învăța de la conferințe similare din regiune, cel mai important etalon fiind: „DevReach, o conferință premium (cali-tate excelentă în prezentări, diversitate, dar și preț relativ mare pentru o per-soană obișnuită). La DevReach și încet și la ITCamp un participant beneficiază de sesiuni destul de apropiate calitativ de media celor de la TechEd, însa la costuri de 10 ori mai mici. Un alt element foarte important: atât DevReach cât și ITCamp sunt conferințe de comunitate, ceea ce înseamnă, printre altele, că organizatorii nu câștigă bani din ele. Asta ne permite o mare flexibilitate în a face alegerile pe care le con-sideram cele mai bune pentru audiență, fără presiunea de a ieși pe profit.” În momentul de față conferința internațională bulgară „are avantajul că există de mai mult timp și are mai multi participanți (600 de oameni). Al doilea avantaj este că are o companie în spate, pe Telerik, și are obiective clare de

business, plus staff dedicat (patru oameni angajați full-time)”.

O parte importantă a oricărui astfel de eveniment o reprezintă bugetul, așa că pentru început am dorit să aflăm suma la care se ridică, și pe ce anume se cheltuiește acesta: „Bugetul este de zeci de mii de euro și vorbim de peste 30-40 de mii de euro, depinde și de câți participanți se înscriu. Foarte mulți bani se duc pe transport, [..] o altă parte consistentă se duce pe masă și pauza de cafea, adică ceea ce plătim la hotel/restaurant, precum și cazarea spea-kerilor”. Există și activități adiționale, dar care: „reprezintă un cost mic, relativ la tot bugetul” și anume: „un eveniment dedicat speakerilor, organizatorilor și sponsorilor: o cină VIP și o vizită la Dracula Castle, la Bran”. Având în vedere că Mihai nu a menționat nimic de tarifele practicate de speakeri am dorit să aflăm cam la ce sume se ridică: „Fiind un eveniment de comu-nitate, toți speakerii vin gratuit - noi le asigurăm costurile de deplasare și încercăm să ii facem să se simtă bine.”

Următoarea întrebare logică este de unde provin banii pentru a acoperi chel-tuielile de mai sus și cum își gestionează practic bugetul. Mai exact ne interesează proporția între cât acoperă sponsorizările și cât acoperă taxa de participare. „Noi am făcut bugetul bazat pe costurile fixe clare (transportul și cazarea speakerilor) și celelalte costuri relative la numărul de participanți, iar în funcție de asta a ieșit cos-tul pe om, o anumită sumă. Pe care noi am zis clar că nu putem să o cerem și că trebuie să cerem sub, așa că am apelat la sponsori”. Contribuția sponsorilor fiind detaliata astfel: „trebuie nuanțat un pic: sponsori-zări pure sunt cam 33-40%, dar sponsorii trimit și oameni și atunci de fapt 85% din bani vin de la sponsori”. Restul de 15% este acoperit din taxa de participare, care are un rol de responsabilizare și barieră de intrare „și acoperă o parte consistentă [din costul individual], peste jumate din costul pe om.”

Cu alte cuvinte taxa de participare (375 RON) este o sumă rezultată din cheltuie-lile efective, fără a fi raportată la prețul de piață al beneficiilor și calității prezen-tărilor. O astfel de estimare este dificil de făcut pe plan local: „Ne-am uitat și în jur, dar nu avem termen de comparație pentru că DevReach este clar mult mai scump,

Interviu cu Mihai Tătăraninterviu

Page 9: Today Software Magazine N3/2012

9www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

iar pe plan local, tot ce se întâmplă este fie gratis, ceea ce facem noi, fie aproape gratis, organizat de Microsoft din când în când”. Relativ la preturile internaționale, ITCamp este mult mai ieftin decât TechED (care costa 2000+ euro), dar are și mult mai mult conținut, 4 zile ori 12-14 sloturi în paralel; sau o comparație mai potrivită ar fi o conferință de nivel doi (500-1000 participanți), care costă 500-1000 euro și este comparabilă ca și conținut sau cali-brul vorbitorilor. În ambele cazuri nu intră în discuție diferențele de costuri legate de transport.

În speranța că nu abuzăm de subiectul „bani” și răbdarea cititorilor, mai filozofăm un pic despre taxa de intrare și însemnăta-tea ei. Începem prin punerea în balanță a beneficiilor pe care le obții de la un ITCamp, exprimată prin răspunsul organizatorilor la un feedback primit destul de des din comu-nitate: „de ce să dau bani la ITCamp, când pot să ma duc online la TechEd și să mă uit la prezentări gratis? În primul rând că: <<o să ma uit online la prezentări>> este o poveste frumoasă, nu se întâmplă nicio-dată. Pe când dacă iți rezervi timp să mergi la o conferință, timpul respectiv este rezer-vat și ești cu mintea acolo. În al doilea rând, când ești într-o sesiune unde interacțiunea este fizică și ai șansa să vorbești cu alții care au aceeași problemă ca și tine, reții altfel. În al treilea rând faci networking și beneficiul este cu totul altul.”

În continuare, am discutat obiectivul declarat al ITCamp de a creste calitatea conferințelor, conținutului și vorbitorilor: „E o problemă de mentalitate, pe care eu vreau să o schimb: lumea trebuie să dea bani la astfel de activități. Fie că dă persoana, fie că dă firma la care lucrează, este mai puțin important, dar trebuie să fim obișnuiți că nimic nu este gratis pe lumea asta, iar dacă vrei să progresezi ca și specialist și să nu fii deodată cu valul, trebuie să înveți. Iar unul din moduri e să participi la conferințe, și e normal să dai bani pentru asta. Bineînțeles există inițiative gratis și chiar noi facem ITSpark și CodeCamp, și sunt foarte bine-venite și credem foarte mult în ele. Doar că nivelul unui CodeCamp de sâmbăta nu se compară cu nivelul ITCamp.. gratis nu o să poți face calitate niciodată.”

O soluție propusă de mine, inspirată din parteneriatul DevReach/Telerik este: redu-cerea taxei prin atragerea de noi fonduri dintr-un parteneriat similar cu o companie privată. „Am luat în considerare un parte-neriat, dar am zis că facem așa, pentru că

nu vrem să depindem de cineva. În mediul business se schimbă obiectivele și oamenii, iar asta reprezintă un risc.” Organizatorii își doresc păstrarea unei independente financiare, care le permite o independență organizatorică și libertatea de a alege vorbi-torii și subiectele, fără compromisuri: „Nici nu vrem să fim o chestie comercială”.

Pentru că am poposit destul pe aspec-tele economice, cel puțin din perspectiva financiară, am trecut la o ultimă între-bare cu caracter organizatoric: gestiunea conținutului și dozarea lui. Practic ne-am dorit să aflăm în ce măsură variază prezența la prezentări în timpul zilei. „Clar seara nu mai sunt la fel de multi ca dimineața. Același lucru mi se întâmplă și mie când mă duc la TechEd. Stau la 4 prezentări pe zi, iar intre timp mai povestesc cu unul altul. Tocmai de aceea am creat spațiul necesar, și fizic, și în timp ca tu să poți să stai să faci networking. [..] Surpriza anul trecut a fost că pe finalul zilelor aveam destul de mulți oameni în sală.”

Am considerat necesar să ne oprim un pic și asupra publicului și pentru început am vrut să aflăm de ce ITCamp la Cluj: „Mie îmi era mult mai simplu să îl fac în Timișoara, dar nu e piața, nu sunt atâția oameni, nu au de unde să îți vină atâția oameni cum sunt în Cluj”. Următoarea întrebare ar fi ce anume îl motivează pe participant: „Cred că ii un pic din toate, clar îi place să facă parte dintr-o comuni-tate, cred că are șansa să facă networking și efectiv poate are o problemă tehnică de rezolvat. Să nu neglijăm aspectul ăsta. Respectiv exista și tendința pe care o avem să ne comparăm unii cu alții, [..] și dacă nu mergi la astfel de evenimente nu poți să știi cum stai în raport cu ceilalți [..] și de aceea consider că evenimentul este extrem de util pentru a coagula piața forței de muncă, se nasc prietenii, șanse de a colabora”. Dincolo de motivație se ridică o problemă specifică publicului românesc: lipsa de interactivitate din timpul eve-nimentelor. „În toată Europa de est este chestia asta. [..] Toți speakerii care vin știu și încearcă printr-o glumă, fiind relaxați, să creeze o stare de normalitate”. Motivația și atitudinea pasivă sunt genul de subiecte care nasc discuții filozofice interminabile, prin urmare, odată pornită discuția, am trecut în revista: influența caracterului predominant de outsourcing asupra inte-reselor tehnice ale participanților; aspecte culturale legate de educația ca proces con-tinuu; lipsa de motivație în dezvoltarea personală cauzată de inflația de locuri de

muncă în IT; moștenirile epocii industri-ale în care toți aveau un loc de muncă și o normă asigurată; inerția specifică prin care se participă la evenimente trimis de firmă. La final, pentru Mihai, contează că: „cineva și-a dorit ca persoana să vină, fie individul, fie firma, dar pentru mine asta e important, că vine cumva. Mi-as dori ca oamenii să conștientizeze asta singuri, dar e greu, așa că o luăm pas cu pas”. O surpriză plăcută anul trecut a fost că publicul a cerut: „să creștem cantitativ, a fost un feedback foarte clar menționat, să ridicam nivelul sesiu-nilor, ăsta e al doilea feedback important”, dovada clară că „nivelul lor tehnic e bun” și interesul pentru aspectele practice ridicat. Prin urmare organizatorii au crescut anul acesta nivelul și au renunțat la prezentări prea generice, care nu trezesc interesul.

Înainte de încheiere am aruncat o pri-vire în viitor: „În primul rând cu ITCamp, dorim să o poziționăm ca o conferință de reper în regiune. Pe celelalte evenimente mai micuțe vrem să le extindem ca număr de participanți și ca diversitate a spea-kerilor. Necesită foarte mult efort, dar implicând oameni noi, se întâmplă.”

La final am revenit asupra rețetei unei conferințe de succes: „Evident mâncarea și cafeaua sunt foarte importante, dar clar primul este conținutul. Dacă s-a termi-nat cafeaua o mai dregi un pic, dar dacă conținutul este sub așteptări.. e nasol, mai ales că lumea dă un ban și setezi altfel așteptările. [..] Foarte multă lume ne-a întrebat mai direct sau mai puțin direct, câți bani câștigăm noi din conferința asta. Pe mine inițial m-a deranjat, dar apoi mi-am dat seama că este o întrebare per-tinentă. Chiar și sponsorii au zis că dacă ne rămâne și nouă ceva este ok, că până la urmă muncim pentru conferință. Nu.. nu este ok, noi nu vrem să facem bani din asta. Chiar s-a întâmplat la o conferință în toamnă să rămânem cu bani (vreo 500 de dolari), și i-am lăsat pentru ITCamp. Este foarte important, chiar dacă este o conferință pe bani, organizatorii nu câștigă din asta, ba dimpotrivă, pe lângă că inves-tim timp, anul trecut am și cheltuit bani. Anul acesta sperăm să nu cheltuim bani, pentru că înseamnă că nu am planificat bine. Insist foarte mult pe chestia asta, e o chestie de comunitate pe care o facem că putem să o facem, că ne place să o facem și pentru că învățăm și noi foarte mult din ea. Scopul nu sunt banii, dar fac parte din viață și trebuie să plătești la un moment dat.”

Page 10: Today Software Magazine N3/2012

programare

ISDC IS A EUROPEAN IT SERVICES COMPANY WITH PASSION FOR CUSTOMERS, SOLUTIONS, AND TECHNOLOGY.

PHOTO COMPETITION FOR PEOPLE WITH IMAGINATION AND AN OBSESSIVE INTEREST FOR PHOTOGRAPHY | MAY 21 – JUNE 17

<b>A DAY IN THE LIFE OF A SOFTWARE DEVELOPER</b>

Geek, nerd, techie, computer expert, IT specialist, software developer... Different names for smart people with an extreme passion for technology. What is a day in their life like? Capture it in a photo and the most inspired photographer wins:

A BRAND NEW

iPad3!With compliments from ISDC techies!

POPULARITY AWARD: SURPRISE WORTH OF

300 EURO!

Send your photo(s) (according to contest rules) at

[email protected]

Winner selection will take place between 18 – 22 June

Competition is fully covered on Facebook/ISDCTeam

Partner & Judge: Photo Romania

Page 11: Today Software Magazine N3/2012

11www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: http://www.transylvania-jug.org/Data înfiinţării: 15.05.2008 / Nr. Membri: 472 / Nr. Evenimente: 37

Romanian Testing CommunityComunitate dedicată QA.Website: http://www.romaniatesting.roData înfiinţării: 10.05.2011 / Nr. Membri: 453 / Nr. Evenimente: 1

Cluj.rbComunitate dedicată tehnologiilor Ruby.Website: http://www.meetup.com/cluj-rb/Data înfiinţării: 25.08.2010 / Nr. Membri: 103 / Nr. Evenimente: 24

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

Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: http://www.meetup.com/Cluj-Semantic-WEB/Data înfiinţării: 08.05.2010 / Nr. Membri: 112 / Nr. Evenimente: 16

Romanian Association for Better SoftwareComunitate dedicata oamenilor cu experienta din IT indiferent de tehnologie sau specializare.Website: http://www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 126 / Nr. Evenimente: 3

Google Technology User Group Cluj-NapocaComunitate dedicată tehnologiilor Google.Website: http://cluj-napoca.gtug.ro/Data înfiinţării: 10.12.2011 / Nr. Membri: 25 / Nr. Evenimente: 7

Cluj Mobile DevelopersComunitate dedicată tehnologiilor mobile.Website: http://www.meetup.com/Cluj-Mobile-Developers/Data înfiinţării: 08.05.2011 / Nr. Membri: 39 / Nr. Evenimente: 2

Secţiunea comunitate își propune să ţină evidenţa grupurilor de profesioniști relevante pentru industria IT, dar și un calendar de evenimente și întâlniri din acest sector. Pentru început prezentăm principalele iniţiative din mediul local, în timp intenţionând să creștem acest index până ce va conţine toate comunităţile locale, dar și cele naţionale cu prezenţă și activitate pe plan local.

Criteriul ales pentru ordonare este o funcţie dată de numărul de membrii și activitatea grupurilor (evenimente locale) raportate la durata de viată, astfel sperăm să obţinem o ierarhie bazată pe gradul de implicare, atât al organizatorilor, cât și al membrilor.

Calendar

Mai 24 – 27AQTR2012 (2012 IEEE International Conference on Automation, Quality and Testing, Robotics)Contact: http://www.aqtr.ro/

Mai 28 – 29ITCamp 2012Contact: http://itcamp.ro/

Mai 31Workshop: Crosscutting Architectural ConcernsContact: http://www.rabs.ro/events?ee=1

Iunie 2OSOM Event v3.0 – Back to the roots!Contact: http://osom.ro

Iunie 15Eclipse DemoCampContact: http://www.transylvania-jug.org/

Iunie 27Semantic technologies applied to real world applicationsContact: http://www.meetup.com/Cluj-Semantic-WEB/

Menţiuni: Cluj Perl Mongers (www.cluj.pm), GeekMeet

(http://geekmeet.ro/), ITSpark (http://itspark.ro/default.aspx), CodeCamp

(http://www.codecamp.ro/), CodExpert (http://

www.codexpert.ro/), PHPRomania (http://www.

phpromania.net/), ARIES (http://www.aries.ro/)

Comunităţi locale

Page 12: Today Software Magazine N3/2012

12 nr. 3/2012 | www.todaysoftmag.ro

Cod nativ vs. cod portabil în dezvoltarea aplicaţiilor

mobile

Ion Ionuț[email protected]

Software developer entuziast din cadrul firmei Three Pillar Global, domeniile de interes principale fiind Web și Mobile development.

programare

În scurta viaţă a internetului s-a tre-cut iniţial prin era Web 1.0, când tendinţa generală era ca utilizatorii să intre pe un portal unde aveau acces la cât mai multe informații utile. Toată lumea era impresi-onată de faptul că există aceste informații adunate într-un singur loc. Utilizatorilor, în sfârșit, le era satisfăcută nevoia de acces la informații.

A urmat Web 2.0 caracteristic unei noi generații de utilizatori, pentru care accesul la informație era deja un “drept”intangibil, obligatoriu și implicit. Acești utilizatori, refuzând să se mulţumească cu postura persoanei singuratice din fața calculato-rului, au reclamat nevoia stringentă de a socializa în mediul virtual.

Începând cu 2010 a apărut o nouă generație de utilizatori pentru care acce-sul la informație și socializarea virtuală sunt considerate implicite. Aceasta este generația Mobile, generaţie pentru care nu mai era suficient accesul la un calculator conectat la internet, ci era necesar ca acce-sul la informație și socializare să poată avea loc de oriunde și oricând. Pentru aceasta generație mobilitatea nu înseamnă doar a deține un laptop. În plus, tot mai multe dispozitive (tablete, telefoane, televizoare, computer de bord, etc. ) devin “smart”, acest lucru însemnând că utilizatorii nu mai sunt dependenți de un anumit dispo-zitiv particular.

Ținând cont de acest context, în cadrul firmei la care lucrez s-a adoptat o strategie denumită Mobile First, acest lucru însemnând în esenţă că proiecta-rea unui nou sistem informatic începe cu

componenta mobilă a acestuia, arhitec-tura sistemului fiind influenţată direct de această componentă.

Criterii de evaluare

Având în vedere dinamica de pe acest segment precum și multitudinea de dispo-zitive și sisteme de operare, nu vom putea găsi o soluţie universal valabilă în ceea ce privește dezvoltarea de aplicaţii. Decizia în ceea ce privește alegerea unei soluţii optime se ia evaluând o serie de factori cum ar fi:• Avantaje și dezavantaje abordări exis-

tente la un moment dat;• Principalii jucători de pe piață;• Așteptările clienților;• Nevoile și nivelul programatorilor.

În urma evaluării putem trage anumite concluzii legate de cea mai convenabilă soluție.

Despre cele mai importante abordări existente în acest moment, împreună cu avantajele și dezavantajelor lor, vom dis-cuta pe larg în secţiunile următoare. De asemenea, vom face o trecere în revistă a celor mai importanţi jucători pe piaţa dez-voltării soluţiilor mobile.

În ceea ce privește așteptările clienţilor, soluţia propusă este privită prin prisma următoarelor criterii:• Costuri reduse,• Flexibilitate,• Întreţinere ușoară,• Dezvoltare rapidă.

Page 13: Today Software Magazine N3/2012

13www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

Clienții sunt întotdeauna interesați să obțină o valoare cât mai mare pentru prețul pe care îl plătesc. Totodata își doresc să nu se facă rabat de la calitate, iar pro-dusul să fie disponibil pe piață într-un timp cât mai scurt. În plus, se urmărește ca eventualele îmbunătățiri ale sistemelor de operare, ale browser-elor sau apariția unor dispozitive mai performante, cu mai multe opțiuni hardware să afecteze cât mai puțin produsul software existent- pe scurt, se urmărește o întreţinere ușoară. Mai mult decât atât, flexibilitatea este dorită pentru ca extinderea ulterioară a produsului cu noi caracteristici să se petreacă într-o manieră cât mai simplă și rapidă.

În schimb, cei implicați direct în dez-voltarea aplicaţiilor sunt mai degrabă interesaţi de:• Control complet asupra codului,• Eleganţă în dezvoltare,• Creștere profesională.

Cei responsabili de dezvoltarea aplicațiilor, au în general o atitudine mai boemă. Ei sunt interesați să aibă un con-trol cât mai complet al codului sursă, vor fi reticenți la acele unelte de “dezvoltare cumouse-ul” care generează automat cod și care nu sunt suficient de flexibile pen-tru a oferi posibilitatea unor eventuale modificări. Totodată, eleganţa dezvoltării este un alt atu din punctul de vedere al programatorilor. Alegerea unei soluții teh-nice care nu oferă posibilitatea de a învăța și experimenta lucruri noi duce la o anu-mită rodare rezultând invariabil o dorință a programatorilor de a părăsi proiectul. Deși toate acestea par a fi elemente mai puţin importante în contextul discuţiei prezen-tului articol, ele pot determina alegerea uni variante de dezvoltare pe termen lung.

Abordări în dezvoltarea aplicaţiilor mobile

1. Cod nativPrima și cea mai naturală alternativă

este dezvoltarea produsului în cod nativ, prin acesta înţelegând codul sursă compilat și executat direct de procesorul unui dispo-zitiv particular și în multe cazuri dezvoltat de producător special pentru combinația hardware aleasă.

Figura 1 reprezintă schemantic care sunt pașii prin care se trece de la specificaţii

la dezvoltarea de aplicaţii corespunzătoare mai multor platforme mobile distincte.

Platforme, limbaje și cadre de lucru:• Apple iOS - Objective C, Cocoa Touch• Android - Java, Android SDK/ NDK• Windows Phone - C# , .NET

Framework• Blackberry - J2ME/ BB Java NDK

Platformele listate sunt cele mai impor-tante , dar nu sunt singurele. În plus, piața este destul de dinamică în acest sector. De exemplu, Mozilla și-a anunțat intrarea in segment cu un nou concept de sistem de operare pentru platformele mobile, Boot to Gecko, dezvoltat cu standardele HTML5 și CSS adăugate pe un kernel de Linux.

Există o serie de argumente în favoarea utilizării codului nativ în dezvoltarea de aplicaţii precum:• Nivel înalt de performanță;• Cadru de dezvoltare construit de auto-

rul platformei;• Sistem de versionare, simulare, unit tes-

ting și testare automată integrate;• Depanare directă;• Acces complet la API nativ;• Reacție rapidă în caz de probleme ce ţin

de OS/ API;• Comunitate mare de dezvoltatori.

Evident, există și o serie de dezavantaje pe care le presupune codul nativ:• Efort sporit de implementare a acelorași

funcționalități pe platforme diferite;• Nevoia de a avea dezvoltator i

specializați pentru fiecare platformă în parte;

• Costuri mai mari;• Dificultăți de întreţinere a unor ver-

siuni diferite;

• Efort de coordonare a dezvoltării noilor caracteristici;

• Fiecare platformă nouă necesită dezvol-tare de la 0.

2. Cod portabil interpretat/Cod hibrid

Varianta utilizării codului portabil interpretat o numim și cu cod hibrid deoa-rece, în general, există două părți ale unei astfel de soluţii: • o aplicație web - HTML5, CSS,

JavaScript, etc. - capabilă să ruleze în orice browser;

• o aplicație-container nativă, specifică fiecărui dispozitiv, ce conține în esență instanța unui browser modificat astfel încât sa aibă acces la resursele hardware ale dispozitivului și care accesează apli-caţia web (opţional).

Instrumente și limbaje:• PhoneGap (HTML / JS – disponi-

bil pe iOS, Android, WP7, BB, Bada, Symbian, WebOS)

• Adobe AIR (HTML / JS / Action Script - iOS, Android, BB)

• WebWorks (HTML / JS - Blackberry)

Avantaje:• Un singur cod de bază pentru toate

platformele ;• Costuri scăzute de dezvoltare și

întreţinere;• Permite echipei de dezvoltare să se con-

centreze pe logica aplicaţiei;• Exista pe piaţă o diversitate de fra-

me work - u r i Jav as c r ipt : E x t J S , Sproutcore etc;

• Necesită doar competenţe specifice de web development.

Figura 1. Dezvoltarea și instalarea aplicaţiilor folosind cod nativ

Page 14: Today Software Magazine N3/2012

14 nr. 3/2012 | www.todaysoftmag.ro

Dezavantaje:• Performanțe mai slabe;• Acces limitat la funcționalitățile plat-

formei (acces la un subset API oferit de dispozitive) ;

• Proces complex și greoi de depanare;• Noile funcţionalităti introduse de

un dispozitiv vor fi implementate in cadrul aplicaţiei container cu o oare-care inerţie;

• Lipsesc unele controale ale interfeţei utilizator predefinite și sunt dificil de simulat controalele pentru fiecare plat-formă în parte;

• Dependenţa de o terţă parte ce implică o reacţie mai lentă în rezolvarea anumi-tor bug-uri.

3. Cod portabil cu compilare multi-platformă

A treia abordare presupune de

asemenea folosirea unui cod comun, por-tabil, dar și al unui compilator care să știe să interpreteze acest cod și să îl compileze generând cod nativ pentru fiecare plat-formă în parte.

Intrumente și limbajele de programare utilizate:• Corona (LUA → iOS, Android,

Windows Phone• Marmelade (C++ → iOS, Android,

Bada, Symbian)• MonoTouch (C#, .NET → iOS,

Android)• MoSync (JavaScript, HTML5 → C++

iOS, Android)• Verivo (ex-Pyxis Mobile) (visual deve-

lopment tool on middleware machine → iOS, Android, Blackberry)

• Titanium (JavaScript, HTML5 → iOS, Android, BB)

Avantajele și dezavantajele acestei

abordări sunt o combinaţie a precedente-lor două direcţii de dezvoltare a aplicaţiilor mobile.

Avantaje:• Nivel înalt de performanţă;• Un singur cod de bază pentru toate

platformele ;• Procesul de instalare decurge la fel ca și

în cazul aplicaţiilor native.

Dezavantaje:• Dificultăţi în identificarea originii unui

bug;• Imposibilitatea programatorilor de a

avea acces la codul nativ generat;• Este mereu în urmă cu noile apariţii în

materie de tehnologie ;• Bug-urile care apar în platforma SDK

vor influenţa procesul de dezvoltare;• Dependenţa de o terţă parte.

ConcluziiCu siguranţă nu există o variantă

câștigătoare la toate capitolele. În schimb, la momentul luării deciziei, natura și spe-cificitatea aplicaţiei vor dicta direcţia de dezvoltare. În plus, alături de avantajele/dezavantajele prezentate până acum, tabe-lul de mai jos evidenţiază și alte criterii ce pot influenţa luarea unei astfel de decizii.

Când se alege codul nativ?

• Când aplicația este destul de complexă și necesită acces la resursele sistemului de operare (exemplu: citirea, deschide-rea unui fișier, procesarea de imagini etc) ;

• Când contează foarte mult performanța;• Când clientul își dorește ca, de exem-

plu, aplicația de iPhone să arate ca o aplicație de iPhone, cea de Android să arate ca una de Android ș.a.m.d. În acest caz, codul nativ este cea mai bună alegere.Când se alege cod portabil?

• Când este vorba despre o aplicație de dimensiuni reduse;

• Când aplicația nu accesează mulți dintre senzorii sau resursele hardware sepcifice dispozitivelor mobile ;

• Când se așteaptă adăugarea unui set consistent de funcţionalităţi în viitorul apropiat, într-un timp relativ scurt ;

• Când avem la dispoziție un buget redus.

Cod nativ vs. cod portabliprogramare

Figura 2. Dezvoltarea și instalarea aplicaţiilor folo-sind cod portabil interpretat/cod hibrid

Figura 3. Dezvoltarea și instalarea aplicaţiilor folosind cod portabil compilat

Page 15: Today Software Magazine N3/2012

15www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

Când se alege cod compilat multi-platformă?• Când se dorește lansarea unei aplicaţii simultan pe toate market-urile.• Când timpul dedicat dezvoltării este foarte scurt și deadline-ul este critic.• Când nu avem programatori specializaţi pentru fiecare platformă în parte.

Referinţe la produse• Adobe AIR (www.adobe.com/products/air.html) • Corona (www.anscamobile.com) • Marmelade (www.madewithmarmalade.com/) • MonoTouch (xamarin.com/monotouch) • MoSync (http://www.mosync.com/) • PhoneGap (phonegap.com) • Rhomobile (rhomobile.com) • Titanium (www.appcelerator.com/) • Verivo (www.verivo.com) • WebWorks (bdsc.webapps.blackberry.com/html5)

Referinţe la aplicaţii mobile• ***, “Mobile Application Development Strategies”, Uberity White Paper, 2012 (http://www.uberity.com/whitepapers/)• David DeWolf, “Mobile First Strategy” (http://www.threepillarglobal.com/blog/post/what-mobile-first-strategy), Mai, 2011• Michael Enger “The Great Cross-Platform UI Challenge: Titanium vs. PhoneGap vs. Native” (http://blog.thelonelycoder.

com/2012/02/03/the-great-cross-platform-ui-challenge-titanium-vs-phonegap-vs-native/) • Martin Fowler “Cross Platform Mobile”, 2011, (martinfowler.com/bliki/CrossPlatformMobile.html) • Julio Franco, „Mozilla’s Boot 2 Gecko mobile OS hands-on”, Techspot, March, 2012 http://www.techspot.com/news/47747-mozillas-

boot-2-gecko-mobile-os-hands-on.html• Perry Hoe, “Cross Compilation vs. Mobile Native Development Debate”, 2011, (blogs.perficient.com/spark/2011/04/20/

cross-compilation-vs-mobile-native-development-debate/) • Ionuț Ion, “Aplicații mobile native versus aplicații compilate”, TiMoDev ediția 14, Martie, 2012 http://ctrl-d.ro/development/

resurse-development/aplicatii-mobile-native-versus-aplicatii-compilate-ionut-ion-timo-editia-14/• Eric Jackson „Here’s Why Google and Facebook Might Completely Disappear in the Next 5 Years”, Forbes, April, 2012 http://

www.forbes.com/sites/ericjackson/2012/04/30/heres-why-google-and-facebook-might-completely-disappear-in-the-next-5-years/

Page 16: Today Software Magazine N3/2012

16 nr. 3/2012 | www.todaysoftmag.ro

Metoda de estimare Function Point

AplicabilitateÎn paragrafele ce urmează, o să fac o

paralelă cu un domeniu care este destul de familiar pentru fiecare dintre noi și anume cel imobiliar.

Imaginează-ţi că ești un evaluator imo-biliar. Un client iţi cere să faci o evaluare a unui imobil (clădire cu apartamente) deja existent. Care sunt pașii pe care îi urmezi?

Probabil că:• Analizezi scopul/obiectul evaluării• Definești o metodologie de evaluare• Definești o metodă de evaluare• Treci la execuţia evaluării în sine:

■ Iei in considerare o serie de carac-teristici generale ale construcţiei (locaţie, structură de rezistenţă, aco-perișuri, etc.)

■ Ulterior, spargi scopul într-o serie de piese mai mici: apartamentele și la fiecare dintre ele te uiţi la: suprafaţă, finisaje, instalaţii termice și electrice interioare, etc.

• Într-un final, în funcţie de aceste carac-teristici o să acorzi fiecărui apartament un punctaj, suma punctajelor fiind numărul de puncte pe care îl acorzi întregului imobil.

• În funcţie de contextul pieţei imobiliare,

acest punctaj o să fie multiplicat cu valoa-rea de pe piaţa/punct, din care o să rezulte o valoare totală a imobilului.

Probabil că o să te întrebi ce legătură are asta cu productivitatea. Clientul evalu-atorului, adică dezvoltatorul imobiliar, o să știe câte puncte au fost atribuite imobilu-lui, o să știe cât timp și de câţi bani a avut nevoie pentru construirea lui, deci printr-un calcul simplu poate să spună cât îl costă în timp și bani un punct. Dacă aplică acea metodă, adică de a evalua un proiect care planifică să-l dezvolte, o să știe câte puncte va avea, deci implicit va ști cât o să-l coste pentru a-l duce la bun sfârșit.

Scopul metodei FPAAplicarea metodei Analiza Punctelor

Funcţionale (Function Point Analysis - FPA) are ca rezultat, atribuirea unui număr de puncte funcţionale (function points - FP) unui produs software deja dezvoltat, pe baza produsului în sine și/sau a documentaţiei asociate; sau a unui produs care urmează să fie implementat pe baza cerinţelor funcţionale și non-funcționale specificate de către beneficiar/client. Primul caz are ca scop determinarea

Probabil că o să te întrebi, de ce este nevoie de o asemenea metodă, cu un nume așa complicat, atât timp cât experţii (programatori, arhitecţi, ingineri de specificaţi, etc.) în producerea sistemelor informaţionale au deja metodele lor cum ar fi Expert judgement, prin care pot să estimeze cât timp le va lua cu o anumită marjă de eroare să dezvolte un produs sau un modul/componentă dintr-un produs software.

Metoda are ca scop: analiza și îmbunătăţirea productivităţii, estimarea proiectelor, controlul proiectelor, aplicând metoda la diferite momente din procesul de dezvoltare.

Ionel [email protected]

QA Officer, implicat in sistemul de asigurare al calitatii la nivel de proiect si organizatie, cu peste 6 ani de experienta in domeniul informational.

management

Page 17: Today Software Magazine N3/2012

17www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

productivităţii, pe când cel de-al doilea are ca scop estimarea produsului.

Puterea metodei stă în faptul că se axează pe măsurarea cantităţii de funcţio-nalitate cu valoare de business pe care un sistem informaţional o oferă utilizatorului final. Deci, nu o să urmărească metoda tehnică aleasă pentru a implementa funcţionalitatea.

Istoric Metoda are un istoric lung, a fost prima

dată definită în 1979, în “A New Way of Looking at Tools” de către Allan Albrecht la IBM. (vezi: http://wikipedia.org)

Ca urmare, există o serie de organizaţii, unele de nivel naţional, altele internaţional, majoritatea non-profit, care se ocupa cu optimizarea metodei și cu adaptarea ei la cerinţele sistemelor informaţionale actu-ale. În anul 2012, există cinci standarde ISO, pentru această metodă. (vezi:http://en.wikipedia.org/wiki/Function_point ,

http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_ics_browse.htm?ICS1=35&ICS2=80&published=on&withdrawn=on )

Conceptual vorbind, nu există diferenţe între standarde dar există mici diferenţe în tehnicalitatea metodei. De asemenea, un punct funcţional rezultat prin aplicarea unui standard nu poate fi comparat cu unul rezultat prin aplicarea unui alt standard, decât dacă se aplică un factor de conversie, comparaţie/conversie pe care nu o reco-mandăm decât în scop știinţific.

NESMA MethodAm ales să prezint standardul “NESMA

FPA Method: ISO/IEC 24570:2005 ” din motive de familiaritate, si având experienţă cu acest standard.

Metoda are 5 t ipuri de funcţii,

fiecarereprezentând o funcţionalitate sau o parte din modelul de date. Aceste funcţii, sunt o “spargere” a funcţionalităţii aplica-ţiei, dupăregulile FPA și reprezintă cel mai mic nivel de granularitate, până la care se poate merge.

Pașii principali în determinarea numărului de puncte funcţionale sunt:• Colectarea documentaţiei;• Determinarea tipului de numărătoare

(Function Point Count);• Determinarea graniţei (boundary);• Identificarea funcţiilor de date(data

transactions sau data logical files) și determinarea complexităţii lor;

• Identificarea funcţiilor de tip utilizator și determinarea complexităţii lor (user functions sau user transactions);Calcularea numărului de puncte

funcţionale

Colectarea documentaţiei necesarăPentru a determina numărul de puncte

funcţionale al unui sistem informaţional avem nevoie de informaţii care să ne indice:• Structura datelor (Structure). Structura

e caracterizată: ■ prin modelul care descrie structura

datelor (se poate folosi modelul de

date, modelul de domeniu, etc.) – se folosește pentru a determina funcţi-ile de date (data trasactions)

■ elementele care sunt conţinute în modelul de date (capacitatea de a stoca date, tabelele în sine, elemen-tele de date conţinute de tabele) – se folosește pentru a determina comple-xitatea funcţiilor de date

• Modul în care se comportă aplicaţia (Behavior). Behavior-ul se caracteri-zează prin: ■ Modelul care descrie compor-

tamentul aplicaţ iei (exemplu: designfuncţional) – folosit pentru a determina user transactions

■ Flow-ul elementelor de date și logica de procesare folosit pentru a determina complexitatea funcţiilor utilizator

Exemple: Documentele de design functional, design tehnic, arhitectură, modelul de date, aplicaţia în sine.

Determinarea tipului de numărătoare (Point Count)

În funcţie de momentul din ciclul de dezvoltare a sistemului informaţional (Software Development Lifecycle) și nive-lul de detaliu al informaţiilor pe care se baseaza măsurătoarea, se pot alege unul dintre următoarele tipuri:• Metoda indicativă (Indicative function

point count)• Metoda estimativă (Estimated function

point count)• Metoda detaliată (Detailed function

point count)Metodele indicativă și estimativă din

standard, se bazează pe existența unei serii de informaţii minimale despre sistem, în funcţie de care se extrag o serie de func-ţii, peste care se aplică o serie de calcule rezultate din măsurători statistice (care se găsesc în literatura de specialitate sau

Figura 1: Evoluţia metodelor FPA în timp

Figura 2: Tipurile de funcţiiînmetoda FPA

Page 18: Today Software Magazine N3/2012

18 nr. 3/2012 | www.todaysoftmag.ro

Metoda de estimare Function Pointmanagement

diferite baze de date, unele gratis sau con-tra cost). Aceste tipuri sunt utilizate atunci când vrem să măsurăm un proiect/produs software în faza incipientă de dezvoltare; și când documentația e minimă. NESMA are un whitepaper special pe acest topic, pe care îl gasesti la capitolul Referinţe.

Ca orice metodă, are o marjă de eroare, mai ales dacă se folosește un tip mai puţin detaliat cum sunt cele două de mai sus (marjă de eroare care poate să varieze până la 50% pentru metoda indicativă); ca urmare, dacă ești începător cu metoda, per-sonal nu-ţi recomand să aplici aceste două tipuri.

Pentru a înţelege pe deplin această metodă, trebuie să o aplici pe cea detaliată. De aceea, în continuare, am ales să detaliez acest tip de măsurătoare.

Determinarea graniţeiAcest pas din aplicarea metodei vizează

identificarea interacţiunii sistemului numă-rat cu alte sisteme și utilizatori. Se poate face prin analiza diferitor specificaţii teh-nice, interviuri cu utilizatorii, etc.Este un pas important pentru că:• Definește sfera de acţiune a măsurătorii;• Are un rol important în determinarea

ulterioară a tipurilor de tranzacţii;Să ne imaginăm că avem de măsurat

un sistem clasic, care are o bază de date și o interfaţă cu utilizatorul. Sistemul pe care noi îl măsurăm, interacţionează cu un alt sistem, în sensul că folosește date care sunt stocate și menţinute de acel sistem. E important de determinat graniţa, pentru că în acest caz, acele date o să se materi-alizeze într-un tip de tranzactii care o să se numească fișiere de Interfeţe Externe (External Interface Files - EIF).

Identificarea funcţiilor de date (data transactions sau data logical files) și determinarea complexităţii lor

Un data logical file e un grup de date relaţionate logic văzute din punct de vedere al utilizatorului final.

Un data logical file poate fi de două tipuri: Internal logical file și External Interface file.

Un Internal Logical file (ILF) e un data logical file care se caracterizează prin localizarea în tota-litate în interiorul graniţei aplicaţiei numărate, iar datele sunt menţinute de către aplicaţia care intră în scopul măsurătorii

Un External Interface file (EIF) e un data logi-cal file se caracterizeaza localizarea în totalitate în exteriorul aplicaţiei numerate, iar datele conţinute de acestea sunt folosite de către aplicaţia numărată doar pentru referinţe.

Să ne imaginăm un sistem care are ca scop mentenanţa facturilor și a persoanelor fizice sau juridice cu care interacţionează organizaţia care folosește aplicaţia. Pe lângă asta, organizaţia folosește informaţii dintr-un sistem extern care o ajută să determine un anumit grad de risc al clienţilor care o să indice cât credit (reprezentând suma maximă de facturare) poate să acorde unui client în funcţie de gradul de risc. Cel mai probabil aplicaţia va folosi o serie de tabele care va modela modulul de facturare (Tip_Facturi, Facturi, Articole_Facturi, Tip_Persoane, Persoane, Adrese, etc)

Pentru că determinarea de fișierelor logice de date trebuie făcute din punct de vedere al utilizatorului final, în acest caz o să avem două ILF, pe care eu o să le denu-mesc: ILF_Facturi și ILF_Persoane. Datele de risc care sunt “aduse” din sistemul extern

o să fie un EIF. Modul în care o serie de tabele

sunt grupate în unul sau mai multe ILF sau EIF, ţine de gradul de dependenţă logică între tabele. Exemplu: Tabela “Facturi” cel mai probabil e dependentă de tabela: “Tip_Facturi”, deci aceste două tabele o să fie în același ILF.

Pentru mai multe informaţii, legat de dependenţele între tabele, vezi standardul NESMA.

Deci, în exemplul de mai sus, am indentificat trei fișiere logice de date: ILF_Facturi (conţine tabelele de facturi), ILF_Persoane (conţine tabelele de per-soane) , EIF_RiskInfo (conţine datele folosite din sitemul extern).

Complexitatea fișierelor logice de date. Pentru aceasta trebuie să mai defi-nesc trei concepte, și anume: Tip element de date (Data Element Type - DET), Tip înregistrare elemente (Record Element Type - RET) și Tip fișier referenţiat (File Type Referenced - FTR)

Un RET este un subgrup de elemente de date, recunoscut unic de către utilizator în cadrul unui ILF sau EIF. În exemplul nostru un RET ar fi tabela Facturi.

Un FTR este un data function, care este refe-rentiata de către o user transaction. Scopul FTR o să fie mai bine evidenţiat la determinarea comple-xităţii tranzacţiilor utilizator. În exemplul nostru, fiecare dintre acele trei funcţii de date este și un FTR.

Un DET este un câmp unic recunoscut de către utilizator; nu este repetitiv și conţine informaţii dinamice, nu statice. Dacă un câmp este recursiv, atunci este luat în considerare o singură dată. În exemplul nostru, numărul de DET-uri o să fie suma de coloane care le avem în tabele.

Notă: Există o serie de excepţii în metodă, care nu fac parte din scopul acestui articol. Exemple: Nu se numără ca și DET-uri, cheile străine pentru că această informaţie este deja stocată în cheile pri-mare, și nu trebuie să numărăm aceeași informatie de două ori. De asemena, nu se numără tabelele care au ca și scop doar crearea de legături între alte tabele, pentru că metoda are ca regula de bază, numărarea a doar ce are valoare pentru utilizatorul final (în FPA acestea se numesc “key-key entities”)

Revenind la complexitate, funcţiile logice de date determinate, o să aibă urmă-toarele caracteristici:

- ILF_Facturi: RET: 3 (Tip_Facturi, Facturi, Articole_Facturi), DET: presupu-nem că suma de coloane în aceste tabele măsurate o singură dată și luând în consi-derare excepţiile metodei, este 30.

- ILF_Persoane: RET: 3 (Tip_Persoane, Persoane, Adrese), DET: presupunem că suma de coloane în aceste tabele măsurate o singură dată și luând în considerare excepţiile metodei, este 60.

- EIF_RiskInfo – metoda de deter-minare a RET-urilor și DET-urilor este Figura 3. Schema funcţiilor FPA (Sursa: http://portal-management.blogspot.com)

Page 19: Today Software Magazine N3/2012

19www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

identică (iar în practică se pot folosi pentru aceasta descrierea interfeţelor). Să presupu-nem că are RET: 1 și DET: 10.

Complexitatea funcţiilor logice de date este dată de tabela din Figura 4: Mică (Low- L), Medie (Average – A), Mare (High - H).

În exemplul nostru, complexitatea funcţiilor noastre o să fie: ILF_Invoices: Average

ILF_Persons: Average EIF_RiscInfo: Low

Identificarea funcţiilor de tip utili-zator și determinarea complexităţii lor (user functions sau user transactions)

În teoria FPA există 3 tipuri de funcţii utilizator: Intrare Externă (External Inputs - EI), Ieșire externă (External Outputs - EO) și Interogare Externă (External Inquires - EQ). Mai jos, o să dau definiţia fiecăruia și câte un exemplu.

EI este o funcţie identificată unic de către utili-zator care străbate graniţa aplicaţiei dintre exterior spre interior

EO este o funcţie identificată unic de către utilizator care străbate graniţa aplicaţiei dinspre interior spre exterior. De asemenea, un EO vari-ază în mărime și/sau diferite procesări de date este nevoie pentru aceasta. Are drept caracteristică, fap-tul că trebuie să fie văzută ca un proces elementar de către utilizator.

EQ este o funcţie identificată unic de către utilizator, care are o combinaţie input/output. Se caracterizează prin faptul că, partea de output are o mărime fixă și nu suferă mai multe tipuri de proce-sare. Şi acestă funcţie, trebuie să fie văzută de către

utilizator ca fiind elementară

În exemplul nostru, funcţionalitatea de a salva o persoană în sistem este un EI, iar un EO ar fi o funcţionalitate care ne retur-nează lista de persoane pe care o avem în sistem.

Un EQ ar fi funcţionalitatea de căutare după un identificator unic de persoană. Utilizatorul introduce un identificator unic al persoanei (partea de intrare), iar siste-mul returnează o singură persoană (partea de ieșire), care are o mărime fixă pentru că întotdeauna o să ne returneze un Nume, Prenume, Număr de telefon, Adresă, etc .

Complexitatea funcţiilor utilizator.Pentru a determina complexitatea lor,

se iau în calcul două elemente: DET și FTR.Pentru a exemplifica mai bine voi reveni la

exemplul nostru descriind funcţionalitatea care o implementează, care sunt funcţi-ile de tip utilizator și cum se determină complexitatea.

Să ne imaginăm că sistemul nostru implementează următoarea funcţionalitate descrisă în Use Cases:

UC1 . Returnează o listă de Facturi (presupunem că lista are 20 de atribute);

UC2. Oferă posibilitatea de a adăuga o nouă factură în sistem (15 atribute), iar în fereastra de adăugare după alegerea per-soanei, informează despre gradul de risc (1 atribut), care la salvarea facturii se salvează în baza noastră de date, într-una dintre tabelele din ILF_Facturi. Să presupunem că factura noastră o să facă referinţă și la o persoană, de care o leagă;

UC3. Oferă posibilitatea de a căuta după un identificator unic al facturii (1 atribut de intrare și 16 de ieșire);

UC4. Returnează o listă de persoane (30 de atribute);

UC5. Oferă posibilitatea de a adăuga o nouă persoană în sistem (35 de atribute);

UC6. Oferă posibilitatea de a căuta după un Person_id (oferă ca și ieșire, 35 de atribute);

În tabelul de mai sus, determin funcţi-ile utilizator și caracteristicile lor.

Așadar, o să avem următoarele comple-xităţi pentru funcţiile utilizator:

EO_InvoiceList – Average EI_AddInvoice – Average EQ_RiscInfo – Low EQ_SearchInvoiceById – Low EO_Persons – Average EI_AddPerson – Average EQ_SearchByPersonId – AverageComplexitatea funcţiilor utilizator este

dată de tabelele din Figura 5 și Figura 6: Mică (Low- L), Medie (Average – A), Mare (High - H)

Calcularea numărului de function points

Bazat pe tipul tranzacţiei și pe com-plexitatea ei, NESMA propune un număr de function points ,vezi Figura 6 și Figura 7, pentru fiecare tranzacţie, suma lor fiind numărul de function points pe care îl deţine sistemul din exemplul nostru.

Așadar, funcţiile noastre o să aibă aso-

ciate numărul de puncte functionale, astfel:Fișiere logice de date: ILF_Facturi – A: 10 FP ILF_Persons – A: 10 FP EIF_RiscInfo – L: 5 FPFuncţii utilizator: EO_ListăFacturi – A: 5 FP EI_AdaugăFactură – A: 4 FP EQ_RiscInfo – L: 3 FPEQ_CautăFacturăDupăId – L: 3 FP

Figura 4. Complexitate funcţiilor logice de date.

Figura 5. Complexitate EI.

Figura 6. Complexitate EO

Figura 7. Număr FP fișiere logice de date.

Figura 8. Număr FP funcţii utilizator.

Page 20: Today Software Magazine N3/2012

20 nr. 3/2012 | www.todaysoftmag.ro

EO_Persoane – A: 5 FP EI_AdaugăPersoană – A: 4 FPEQ_ CautăPersoanăDupăId – A: 4 FP

Bazat pe informaţiile de mai sus, pro-iectul nostru o să aibă o sumă totală de 53 puncte funcţionale .

Notă: Exemplul de mai sus are doar scop informativ. Deoarece această metodă de numărare are o marjă de eroare, ca orice metodă, literatura de specialitate nu reco-mandă aplicarea ei pentru sisteme care pot să aibă un număr mai mic de 100 puncte funcţionale.

Caracteristicile non-functionaleDupă cum probabil ai observat, în

exemplele de mai sus nu am atins deloc caracteristicile non-functionale, care e clar că au un cuvânt important de spus în deter-minarea unei estimări sau a productivităţii unei echipe. În literatura de specialitate există conceptul de puncte funcţionale nea-justate (unadjusted function point count) și puncte funcţionale ajustate (adjusted func-tion point count). În exemplul de mai sus numărul pe care l-am atribuit aplicaţiei noastre este un număr de puncte funcţio-nale neajustate.

În teoria FPA, există o serie de 14 carac-teristici generale de sistem (general sistem characteristics) care se folosesc pentru a determina numărul de FP care ar trebui să se adauge peste acele puncte funcţionale neajustate pentru a surprinde caracteris-tici non-funcționale; rezultând un număr total de puncte funcţionale ajustate. (vezi NESMA: http://www.nesma.nl/section/fpa/howfpa.htm). Am ales să nu vorbesc în detaliu despre ei în acest articol. În para-grafele care urmează o voi explica de ce. S-a demonstrat în literatura de specialitate că, dacă avem un sistem foarte light, din punct de vedere non-functional, peste a cărui număr de puncte funcţionale neajus-tate aplicăm caracteristici minime pentru el, va avea un număr minim de puncte funcţionale ajustate = numărul de puncte funcţionale neajustate – 35 % puncte func-ţionale neajustate. La fel, dacă sistemul este unul foarte heavy, peste a cărui număr puncte funcţionale neajustate aplicăm caracteristici maxime, va avea un număr maxim de puncte funcţionale ajustate = numărul de puncte funcţionale neajustate + 35 % puncte funcţionalene ajustate.

Să ne gândim practic. Presupunând că avem două sisteme, având un număr

de puncte funcţionale neajustate egal cu 1000 FP. Primul sistem e unul care are o bază de date Access în spate, nu are nevoie de acces concurrent la date, nu trebuie să fie portabil, o să fie folosit de maxim un singur utilizator, deci un sistem foarte sim-plu. Conform cu literatura de specialiate o să aibă un număr de puncte funcţionale ajustate egal cu 650 FP. Cel de-al doilea sistem este unul foarte complex din punct de vedere non-funcțional, trebuie să se implementeze accesul concurrent la date, trebuie să aibă o performanţă bună cu un million de utilizatori simultan, trebuie să fie portabil, deci un sistem complex al cărui caracteristici de sistem am zice că sunt la limita maximă. Conform cu literatura de specialitate acest sistem ar avea un număr de puncte funcţionale ajustate egal cu 1350 FP.

Ca urmare, crezi că ar fi real să spunem că, efortul pentru a implementa cel de-al doilea sistem e doar dublu, faţă de efortul de a implementa primul sistem? Nu prea cred.

Conceptul de puncte funcţionale ajus-tate/neajustate a fost scos din standard-ul ISO la începutul anilor 2000, probabil acesta este motivul.

Dar ce facem cu caracteristicile non-functionale? Dacă le luăm în considerare intră în acțiune următorul pas. Ce facem cu numărul de puncte funcţionale ? Cum îl folosim în cadrul organizaţiei? Îl vom denumi “benchmarking” și va fi explicat în următorul capitol.

BenchmarkingOrice organizaţie care dorește să folo-

sească această metodă ar trebui să aplice metoda în diferite momente de dezvol-tare din Software Development Lifecycle, cel puţin o dată la început (având ca scop estimativ) și o dată la încheierea pro-iectului (având ca scop determinarea productivităţii la nivel de echipă/organiza-ţie). Productivitatea este dată de numărul de ore necesare pentru a dezvolta un punct funcțional. Aplicând metoda la sfârșitul ciclului de dezvoltare, organizaţia își poate crea o bază de date legat de productivita-tea medie per tipuri de sisteme, echipe de dezvoltare, caracteristici non-functionale ale sistemului, tehnologii folosite în dez-voltarea lui. Având această bază de date la dispoziţie și aplicând metoda la înce-putul ciclului de dezvoltare, organizaţia va putea estima un număr de ore pentru

implementarea sistemului. Așadar, trasfor-marea numărului de puncte funcţionale în număr de ore trebuie văzut ca fiind parte dintr-un process continuu de îmbunătăţire a proceselor de estimare și productivitate, în cadrul căruia datele istorice joacă un rol crucial. Precizam mai sus faptul că nu recomand aplicarea mai multor standarde în paralel, acesta este motivul. Pentru a crea o baza de date cu date istorice consistente e indicat să te raportezi la aceeași metodă/standard.

Sub-metode Pentru a fi la zi cu cerinţele

sistemelor actuale, există o serie de “sub-metode” care au ca scop tratarea anumitor cazuri speciale, legate de: metodologia de dezvoltare a sistemelor, tehnologie, tipuri de specificaţii funcţionale, etc . Câteva exemple ar fi:

- “ N 1 3 F PA f o r S o f t w a r e Enhancement (v2.2.1)” - își propune să trateze măsurarea unui număr de enhan-cement function points (EFP), pentru proiectele care au o metodologie de dezvol-tare agilă. Această metodă setează numărul de EFP pentru activităţi de ștergere, modi-ficare, adăugare de funcţionaliate din sistemul numărat.

- “N24 FPA applied to UML and Use Cases(v1.0.1)” - își propune să trateze măsurarea unui număr de puncte funcţi-onale (FP) având ca informaţie de input specificaţii care descriu sistemul în stil UML (Unified Modeling Language) și Use Cases.

- “ N 2 5 F P A f o r Datawarehousing(v1.1.0)” - își propune să trateze măsurarea unui număr de puncte funcţionale (FP) pentru sistemele de data warehouse.

- “N20 FPA în Early Phases (v2.0)” - își propune să trateze măsurarea unui număr de puncte funcţionale (FP) pentru sistemele care sunt în stadii incipiente de dezvoltare.

ConcluziiÎn concluzie, putem considera că

această metodă este una indicată pentru a determina productivitatea si eventualele fluctuaţii în productivitate, pe de o parte, iar pe de altă parte, se poate aplica pentru a face estimări bazate pe productivitate. Metoda și-a dovedit până acum eficiența în cadrul unui număr considerabil de proiecte.

Metoda de estimare Function Pointmanagement QA

Page 21: Today Software Magazine N3/2012

21www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

Managementul Calității Practici recomandate pentru a livra

software de calitate

produsele oferite, modificari rapide ale acestora, servicii personalizate și ușor de întreținut, sisteme integrate și bineînțeles, livrari la prețuri cât mai mici, preferabil imediat.

De câte ori s-a pus în discuție calitatea aplicațiilor software, de fiecare dată am subliniat că testarea software nu reprezintă singura măsură la care trebuie să ne gândim pentru a livra un produs software de cali-tate, așa cum mulți ar putea crede la prima vedere. De altfel, termenii folosiți, QA și testare, nu se suprapun ca semnificație.

Așadar, prima idee/practică reco-mandată este migrarea de la ”mindset-ul” orientat pe controlul calității/testare, spre acela orientat pe asigurarea calității. Testarea pentru calitate nu reprezintă asigurarea ei, ci o metoda de control. Asigurarea calității (QA) este orientată pe procese, în timp ce controlul calității (QC) este orientat pe produs.

Testing-ul ne ajută să câștigăm încre-dere că ceea ce livrăm este așa cum trebuie să fie, că totul funcționează conform specificațiilor și la standardele de calitate propuse, dar pe lângă aceasta, și făcând abstracție de aspectele tehnice, legate de tehnologia aleasă pentru implementare,

de procesele simple și eficiente, buna pla-nificare, comunicarea eficientă și din timp, implicarea clientului, cerințele clare, pre-gătirea/instruirea adecvată a membrilor echipei, sunt de asemenea factori care trebuie considerați pentru succesul proiec-tului și pentru calitatea finală livrată.

Inginerii QA trebuie să își asume rolul de asiguratori ai calității, în toate fazele de dezvoltare a produsului. Aceștia tre-buie să observe practicile care conduc la introducerea de defecte, să analizeze din timp cerințele și procesele, să propună sugestii de îmbunătățire a produsului, să observe cât mai repede eventualele scăpări sau erori, pentru că se știe că un defect de documentație descoprit din vreme, reduce semnificativ costurile asociate cu re-imple-mentarea târzie, dacă presupunem că acesta ar fi fost găsit doar in faza de testare.

Considerând aceste procese, tendința acutală este de migrare spre metodologi-ile de dezvoltare iterative și incrementale Agile, în defavoarea celor mai vechi, de tip secvențial, precum Waterfall.

Standish Group International Inc www.standishgroup.com este un lider bine-cunoscut în domeniul analizei industriei IT, prin colectarea de informații din lumea

Dinamica actuală din industria de dezvoltare software reprezintă o adevărată pro-vocare pentru asigurarea calității. Aceasta se datorează orientării spre livrarea rapidă și frecventă a aplicațiilor (în contextul în care gradul de complexitate al acestora s-a mărit); a numărului mare de utilizatori finali și al așteptărilor tot mai mari ale acestora, al diver-selor medii de operare. Pentru că am amintit de așteptările tot mai mari ale clienților, credem că nu este un secret pentru nimeni faptul că aceștia vor calitate superioară pentru

Eugen Otavă[email protected]

Release Manager Small Footprint

QA

Page 22: Today Software Magazine N3/2012

22 nr. 3/2012 | www.todaysoftmag.ro

reală și prin prezentarea lor în mod siste-matic și statistic. Acesta în ”Chaos Research reports”, a arătat pentru anul trecut, o creștere semnificativă a ratei de succes a proiectelor i.e. 37%, comparativ cu rezul-tatele raportelor din anii precedenti. De asemenea în 2009 procentul era de 32%. Cel mai dramatic raport a fost cel din anul 2004, care arăta că doar 28% din totalul proiectelor, care au făcut parte din studiu, au fost finalizate cu success. Practic, după cum declara și Jim Johnson, chairman-ul Standish Group, raportul pe anul 2011 prezintă rata cea mai mare de success din istoria raportelor Chaos Research. Rata de succes a proiectelor Agile este de trei ori mai mare față de proiectele non-Agile, după cum se arată în ”2011 - Chaos Manifesto – The Standish Group International”. Standish Group înțelege printr-un proiect că a fost finalizat cu succes, dacă a fost livrat la timp,

în bugetul propus, și bineînțeles complet. Statisticile acestora, având la bază proiecte dezvoltate începând cu anul 2002 și până în anul 2012, arată ca în imaginea de mai sus.

Luând în considerare datele statistice de mai sus, putem afirma că acea tendință de a deveni Agile Friendly este una pozitivă. Am fi totuși suprinși să aflăm că încă mai sunt multe companii mari care lucrează după metodologiile secvențiale vechi, sau că sunt altele care pretind ca lucrează Agile, dar încă păstrează principii străine de Agile. Nu vom recurge la descrierea acestor metodologii sau a avantajelor lor, pentru că multe sunt cunoscute, dar și pentru că în numărul trecut a fost pe larg explicat Scrum-ul. Subliniez doar provocarea pe care o aduce adoptarea metodologiilor de tip Agile pentru inginerii QA care au fost instruiți în spiritul tradiționalelor cursuri ISTQB (International Software Testing

Qualifications Board), care susțin bene-ficiile echipelor independente de testare, împărțirea activităților de testare in faze secvențiale, folosirea V-modelului pentru management-ul ciclului de testare, promo-vează scripturile de testare și mai puțin a listelor de verificare, lucruri care nu se prea aplică in Agile etc .

Raportul amintit al The Standish Group, analizează și cauzele proiectelor eșuate și printre primele cauze amintite sunt: cerințe incomplete, neimplicarea clientului, pro-bleme de comunicare etc .

Vom analiza pe scurt problematica cerințelor incomplete. Fară o analiză atentă a cerințelor, riscăm să pierdem timp și bani, implementând soluții incomplete sau chiar eronate. Există o adevărată disciplină în domeniul software pe marginea cerințelor (Requirments Engineering) și implicit cur-suri și certificări pe acestă temă (e.g. http://www.certified-re.de/en/). Probabil acest subiect va putea fi tratat pe larg intr-un arti-col viitor, deoarece este foarte important.

Înainte de prezentarea altor practici recomandate pentru a livra software de calitare, subliniez că a vorbi despre calitate este destul de dificil, atâta vreme cât nu avem o înțelegere comună a conceptului.

Astfel, calitatea se poate măsura prin nivelul de satisfacție al clientului. Unii ar putea spune că, un produs de calitate este acela care răspunde cerințelor clientului, și implicit testarea asigură acest lucru. De acord, dar să nu uităm totuși de o nuanță adusă încă din anii 80’ de modelul Kano, care este o teorie a dezvoltării produsu-lui versus satisfacţia clienţilor. Teoretizat de către profesorul japonez Noriaki Kano (1984), acest model demonstrează că satifacția clienților crește semnificativ în funcție de performanța atributelor pro-dusului, arătând de asemenea că, atunci când sunt oferite caracteristici/compo-nente inovative, care deși nu au fost inițial identificate prin cerințe ca nevoi explicite de către client, odata oferite, acestea aduc valoare și contribuie semnificativ la gradul de satisfacție al clientului.

Acest model oferă o imagine de ansam-blu asupra atributelor produsului care sunt percepute a fi importante pentru satisfacția clienţilor. Modelul Kano se concentrează pe diferenţierea caracteristicilor pro-dusului. Prima arie, delimitată de linia diagonală din reprezentarea grafică de mai jos, reprezintă necesități explicite (scrise sau verbale). A doua arie, a satisfacerii

QAManagementul Calității

Page 23: Today Software Magazine N3/2012

23www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

clienților/utilizatorilor, reprezintă inovația. A treia arie, cea mai semnificativă, reprezintă necesități nedeclarate, așa cum arată curba de jos, din dreapta. Clientul poate să nu știe de ele sau poate să creadă că aceste necesități vor fi automat acoperite.

Modelul Kano poate fi folosit la prioritizarea cerințelor, în funcție de satisfacția clientului, iar pentru aceasta s-au identificat patru categorii: ”Surprinzătoare și încântătoare” (pot diferenția un produs față de competiție), ”Cu cât mai mult, cu atât mai bine” (cresc satisfacția utilizatorului), ”Trebuie să existe” (nu o să crească satisfacția utilizatoru-lui, dar dacă lipsesc, o să producă insatisfacție), ”Mai bine să lipsească” (reprezintă caracteristici care produc insatifacție utilizatorului). Aceasta clasificare poate fi folosită și la împărțirea caracteristicilor în release-uri, spre exemplu, primul release ar trebui să conțină mai ales cerințele de tip ”Trebie să existe”.

Se poate concluziona că, un pas cheie spre creșterea satisfacției clientului, a calității este inovația. Secretul stă în a identificarea acele atribute pe care clientul nu le-a numit explicit, dar care fac diferența. Acestea, odata oferite, pe lângă celelalte, care au fost identificate, cresc satisfacția cli-entului și contribuie ca produsul să se diferențieze de altele de același fel.

ConcluziiAdoptarea principiilor asigurării calității, pe toata durata

de viață a unui produs, nelimitându-ne doar la testare, ca măsură de control a calității produsului reprezintă primul și cel mai important pas.

De asemenea, am prezentat tendința actuală de a folosi o metodologie de dezvoltare software iterativă și incremen-tală de tip Agile, care după cum se arată în rapoartele oferite de către The Standish Group Inc, au o rată a succesului de trei ori mai mare decât metodologia secvențială Waterfall. Am încercat, de asemenea, să subliniez rolul pe care îl au cerințele clare pentru calitatea finală a unui produs, dar și performanța atributelor produsului, caracterul inovativ al acestora, pentru gradul de satisfacție al clientului/utilizato-rului, apelând pentru aceasta la modelul Kano.

Page 24: Today Software Magazine N3/2012

24 nr. 3/2012 | www.todaysoftmag.ro

eBay colectează zilnic 20TB de date generate de utilizatori.

Facebook colectează 20TB zilnic din date genearate de utilizatori și generează încă 10TB din analizele zilnice, de aseme-nea scanează 135TB/zi, iar pentru a oferi serviciul de Insigts prelucrează 15PT de date.

Google procesează 20PT de date pe zi și stochează 5PT zilnic.

E clar că e nevoie nu doar de hardware, dar și de un nou concept software pentru a stoca acest volum de date.

Sistemele RDBMS indiferent de topo-logia de replicare folosită devin copleșite. Apar probleme de scalabilitate, operațiile de scriere se strangulează, join-urile devin și mai lente, apar intârzieri la sincroni-zare. Mai mult decât atât gândiți-vă ce s-ar întâmpla daca se arde o placa de rețea sau crapă un hard-disk. Cu cât există mai mult hardware într-un deployment, cu atât crește rata de defecte hardware. De ase-menea nu putem neglija nici costurile de hardware, curent electric și salariile ingine-rilor de sistem care să fie disponibili 24x7.

Pentru a putea face față volumelor mare de date s-au adoptat sistemele distribuite. Prezentăm în continuare ce stă la baza lor.

În 2000, un anume profesor Eric Brewer

de la University of California, Berkeley, introducea teorema CAP. Spre deosebire de sistemele DBMS care se bazează pe prorietățile ACID, teorema vorbea despre trei atribute cheie ale sistemelor distribu-ite: Consistency, Availability și Partition tolerance.

Consistency se referă la consistența datelor, mai precis, ori cât de mulți clienți ar avea un sistem distribuit, la o operație de citire toți ar primi aceași versiune a datelor.

Availability se referă la faptul că toți clienții acestui sistem distribuit pot în orice moment să scrie și să citească date.

Pa r t i t i o n t o l e r a n c e s i s t e mu l funcționează chiar și atunci când noduri din sistemul distribuit nu sunt disponibile.Aceași teoremă mai spunea un lucru foarte important: este imposibil ca un sistem dis-tribuit să le garanteze pe toate trei. Adică poți să alegi fie C-A, fie A-P ori C-P.

Pornind de la această teoremă s-au dez-voltat câteva tehonologii, unele proprietare, iar altele open-source ce poarta numele de NoSQL.

NoSQL nu spune un „nu” hotarat SQL-ului, ci mai degrabă înseamnă „not only SQL”.

Acestea sunt sisteme cu arhitectură dis-tribuită, datele sunt patiționate redundant

În numărul primul articol al seriei „Big Data” se vorbea despre trendul acestui con-cept în industria software. Acest articol prezintă fundamentele tehnologiilor care fac posibilă stocarea și interogarea acestor volume mari de date.

Pentru a înțelege mai bine care e problema cu Big Data încep cu un mic exemplu. La un moment dat circula pe Internet umătoarea statistică:

Cătălin RomanSoftware Architect la Nokia, [email protected]

Lucrează cu SOA și este pasionat de e-commerce

programare

Big Data Reprezentarea datelor

Page 25: Today Software Magazine N3/2012

25www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

pe mai multe calculatoare. Un astfel de sis-tem se poate scala orizontal adăugând mai multe calculatoare. Defectarea vreunuia dintre ele este tolerată.

Pentru a obține scalabilitate orizon-tală, e nevoie de o puternică toleranță la partițonare, care presupune renunțarea fie la consistență, fie la disponibiliatea servi-ciului. Iar aceasta se obține prin relaxarea abilităților relaționare și slăbirea sau chiar eliminarea tranzacțiilor.

Aceste sisteme sunt optimizate pentru operații de citire și adăugare (append). Comparativ cu RMBS, în afară de stocare, oferă mai puține functionalități, dar în schimb compensează la capitolul scalabi-litate și performanță.

Un l u c r u d e o s e b i t c a r e t r e -buie menționat este că datele nu urmăresc o schema fixă, altfel spus sunt semi-structurate.

Înainte de a detalia acest tip de date, facem o clasificare a sistemelor NoSQL.

Imaginea de mai sus ilustreză cele trei proprietăți ale sistemelor NoSQL. Sistemele RDMS apar în schema doar pentru comparație, în realitate ele nu și-ar avea locul aici.

Dacă în RDBMS modelul de date era cel relaționar, în NoSQL se vorbeste cel mai des despre key-value, column-orien-ted și document-oriented.

Sistemele key-value suportă operațiile de scriere, citire și ștergere, bazându-se pe o cheie primară. Nu există range-query, sau alt tip de „cautare” de date.

Sistemele column-oriented, folosesc în continuare tabele, dar nu oferă join-uri. Acestea stochează datele per coloană, diferit față de sistemele tradiționale unde datele sunt salvate pe rânduri. Un prim beneficiu ar fi viteza de acces la date când avem un tabel cu multe linii și multe coloane. Mai multe detalii puteți găsii aici: http://en.wikipedia.org/wiki/Column-oriented_DBMS

Sistemele document-oriented, sto-chează documente structurate folosing JSON sau XML, tot fară join-uri. Dacă e nevoie de join-uri acestea se implemen-tează în aplicația care are nevoie de ele.

O altă clasificare ar fi chiar după cele 3 proprietati CAP.

Consistent, Available (CA), acestea au probleme cu partiționarea și încearcă să rezolve problema prin replicarea datelor:

• RDBMS (relational) • Vertica (column-oriented) • Aster Data (relational)

• Greenplum (relational)

Consistent, Partition-Tolerant (CP), au provocări cu disponibilatea serviciului, dar în schimb datele sunt consistente în toate nodurile sistemului.

• BigTable (column-oriented/tabular)

• Hypertable (column-oriented/tabular)

• HBase (column-oriented/tabular) • MongoDB (document-oriented) • Terrastore (document-oriented)

• Redis (key-value) • Scalaris (key-value) • MemcacheDB (key-value) • Berkeley DB (key-value)

Available, Partition-Tolerant (AP), serviciul e în permanență disponibil, iar toleranța la defecte este foarte ridicată, dar operațiile de scriere se vor propaga mai lent pe toate nodurile din sistem.

• Dynamo (key-value) • Voldemort (key-value) • Tokyo Cabinet (key-value) • KAI (key-value) • Cassandra (column-oriented/

tabular) • CouchDB (document-oriented) • SimpleDB (document-oriented) • Riak (document-oriented) Propagarea lentă a scriierilor se mai

numește „eventual consistency”. Dacă supunem un sistem AP la concurență mare la scriere, s-ar putea să nu regăsim imediat la citire valoarea pe care tocmai am scris-o. Când avem o aplicație care folosește un astfel de sistem trebuie să fim conștienți de limitările acestuia și să le tratăm la nivel de aplicație.

Alegem un sistem NoSQL și să facem un exercițiu...

Fie un website de anunțuri de mica publicitate, unde utilizatorii pot să-și cre-eze un cont și să posteze anunțuri gratuite. Vizitatorii vor putea filtra anunturile după categorii și locație.

Problema stocării și interogării date-lor poate fi rezolvată relativ ușor cu o bază de date relațională, dar pentru a complica lucrurile, mai adaugăm faptul că portalul are 1.5 milioane de anunțuri noi pe zi, este vorba de craiglist.org. În condițiile de mai sus, se impune alegera unui sistem CAP. Pentru a exersa vom alege MongoDB.

Cu MongoDB, datele sunt stocate în documente în format BSON (Binary JSON) dar pentru reprezentare se folosește JSON. Tabelul de pe pagina următoare prezintă mapparea conceptelor SQL la concepte MongoDB.

În problema noastră avem de-a face cu doua entități sau altfel spus, două tipuri de documente: user și annuncement. Le putem împărții în două colecții, deși nu suntem constrânși.user: {”_id”: ”alice”,”email”: „[email protected]”,„createdOn”: „2012-02-02 12:12:12”,

Page 26: Today Software Magazine N3/2012

26 nr. 3/2012 | www.todaysoftmag.ro

„country”: „DEU”,„city”: „Berlin”} announcement: {„_id”: ObjectId(„9fd9fe0c-ad2f-409b-a8af-fd39b2a414f2”),„author”: „alice”,„createdOn”: „2012-02-02 13:12:12”,„subject”: „Bike for sale”,„description”: „Gorgeus bike for sale.”,„price”: „150”,„contact”: {„phone”: „151-82310373”,„email”: „[email protected]”,}„location”: {„city”: „Berlin”,„postalCode”: „13187”,„country”: „DEU”,}}

Prin exemplele de mai sus tocmai am definit o schemă semi-structurată, prin-cipala caracteristică care se poate observa este denormalizarea datelor.

Pentru a crea un document de tip user executăm:

db.user.insert({_id : „alice”,

email : „[email protected]”, cre-atedOn: „2012-02-02 12:12:12”, country: „DEU”, city: „Berlin”})

Dacă vrem să extragem documentul folosind id-ul:

db.user.findOne({_id: „alice”})

Pentru a extrage toate anunțurile create de alice, vom folosi:

db.announcement.find({author:”alice”})iar dacă vrem doar titlurile anunțurilor:

db.annoucement.find({author:”alice”}, {subject: 1})

Dacă acest tip de interogare e un caz des utilizat, atunci preferăm să fie cât mai rapid, pentru asta vom crea un index pe câmpul autor, folosind:

db.announcement.ensureIndex({author:1})

Pentru a obține toate anunțurile din Berlin vom folosi:

db.announcement.find({location.city=”Berlin”})

Rezultatele acestor interogari vor fi o listă de obiecte tip JSON.

Acestea sunt doar câteva exemple pen-tru a va face o idee despre cum se lucrează cu MongoDB.

Interogăriile au fost executate intr-o consola de tip shell, dar MongoDB are

drivere pentru celele mai populare limbaje de programare incluzand Java, C++, PHP, etc...

Dacă v-am stârnit curiozitatea, www.mongodb.org e principala resursă pen-tru învățare.

O altă resursă centrală pentru a porni la drum este http://nosql-database.org/.

Înainte de alege un sistem NoSQL, trebui să avem în vedere întreg contextul: care e numărul de clienți, care e ponderea scrierilor comparativ cu citirile de date. Care sunt cele două proprietăți CAP prio-ritare și cât sunt de complexe interogările. Cât de des pot apărea tipuri noi de inte-rogări. Odată ce avem răspunsul la aceste întrebări trebuie să cunoaștem în detaliu funcționalitățiile sistemelor candidate. Dar mai multe despre acestea în numerele vii-toare ale revistei...

programareBig Data

Page 27: Today Software Magazine N3/2012

27www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

Microsoft Kinect - Ghid de programare

Partea I - O simplă inițializare

cum anume funcționează.

O inițializare simplă pentru Kinect

kinectSensorChooser.KinectSensor-Changed += new DependencyPropertyChangedEventHandler(kinectSensorChooser_KinectSensorChanged);

KinectSensorChooser este un user control creat pentru exemplele oficiale de dez-voltare a unei aplicații folosind Kinect, incluse în kit-ul de instalare a SDK-ului. Deși opțională, folosirea sa simplifică mult dezvoltarea unei aplicații.

Instrucț iunea de mai sus cre-ează un event handler pentru event-ul KinectSensorChanged, care se declanșează când Kinect-ul începe să se inițializeze, este deconectat sau când starea lui se modifică în orice alt mod. De fapt un senzor Kinect se poate afla în una din cele zece stări predefinite:

1. Connected2. DeviceNotGenuine3. DeviceNotSupported4. Disconnected5. Error6. Initializing7. InsufficientBandwith8. NotPowered9. NotReady10. Undefined

Ceea ce urmărim acum e ca senzorul să fie inițializat și pregătit pentru a transmite date aplicației.

În cazul în care se află într-o altă stare, de exemplu, Disconnected, obiectul KinectSensorChooser va afișa pe ecran un mesaj care înștiințează utilizatorul de starea curentă a senzorului. Deși nu obligatorie, este totuși o funcționalitate utilă, care ar fi trebuit să fie implementată manual dacă nu am fi folosit user control-ul KinectSensorChooser.

KinectSensor old = (KinectSensor)e.OldValue;StopKinect(old);KinectSensor sensor = (KinectSen-sor)e.NewValue;

În cazul în care starea senzorului s-a schimbat, e, argumentul event han-dler-ului păstrează atât senzorul (de tip KinectSensor) vechi, cât și cel nou. E un lucru util, întrucât astfel putem opri vechiul senzor, urmând să lucrăm în continuare cu cel nou.var parameters = new TransformS-moothParameters{ Smoothing = 0.3f, Correction = 0.0f, Prediction = 0.0f, JitterRadius = 1.0f, MaxDeviationRadius = 0.5f

};

Senzorul (sensor) conține atât datele legate de cadrul RGB și de adâncime, cât și datele scheletice ce permit moni-torizarea corpului utilizatorului. Datele scheletice permit o transformare de nete-zire. Transformarea se referă în general la acuratețea cu care sunt monitorizate înche-ieturile și poate fi modificată printr-un set de cinci parametri, cu valori de la 0 la 1:

1. Smoothing2. Correction3. Prediction4. JitterRadius5. MaxDeviationRadiusÎn mod normal, cu cât scheletul uti-

lizatorului e plasat mai precis, cu atât poziționarea acestuia necesită mai mult timp, dând senzația unei întârzieri (lag). Deci acuratețea vine cu un preț și decizia finală rămâne la adresa dezvoltatorului. Pentru o aplicație rapidă, cum ar fi un joc video, un schelet cu o viteză mare de reacție ar fi mai important decât o acuratețe foarte ridicată, în timp ce o aplicație medicală ar

În numărul anterior am discutat despre Kinect, o tehnologie oferită de Microsoft ce poate monitoriza întreg corpul utilizatorilor în timp real. După o scurtă introducere, am inclus o secvență de cod pentru inițializarea device-ului, o inițializare simplă și potrivită pentru o aplicație introductivă, de tip Hello World.

În continuare, vom parcurge secvența de cod în detaliu și vom încerca să explicăm

Echipa [email protected]

programare

Page 28: Today Software Magazine N3/2012

28 nr. 3/2012 | www.todaysoftmag.ro

programare

găsi mai mult folos într-o precizie ridicată decât în timpi foarte scăzuți de răspuns.

sensor.SkeletonStream.Enable(parameters);sensor.DepthStream.Enable(DepthImageFormat.Resolu-tion640x480Fps30);sensor.ColorStream.Enable(ColorImageFormat.RgbReso-lution640x480Fps30);

Configurăm senzorul să transmită date RGB, de adâncime și scheletice.

sensor.AllFramesReady += new EventHandler<AllFramesReadyEventArgs>(sensor_AllFramesReady);

Eventul AllFramesReady al senzoru-lui se activează în momentul în care trei noi cadre (RGB, de adâncime și sche-letic) au fost finalizate și sunt pregătite pentru procesare în aplicație. În continu-are, atașăm event-ului event handler-ul sensor_AllFrameReady.

try{ sensor.Start();}catch (System.IO.IOException){ kinectSensorChooser.AppCon-flictOccurred();

}

Încercăm să pornim senzorul și tratăm eventualele excepții cu ajutorul lui Ki-nectSensorChooser.

if (closing){ return;

}

Odată ce Kinect-ul a trimis trei noi cadre și aplicația a intrat în event handler-ul corespunzător, verificăm dacă senzorul nu a primit comanda de închidere cu puțin timp în urmă, caz în care cadrele trimise sunt inutile și hotărâm să le ignorăm.

Skeleton first = GetFirstSkeleton(e);

if (first == null){ return;

}

Altfel, extragem primul schelet (de tip Skeleton) din argumentul e și ne asigurăm ca nu are valoarea de tip null.

MainCanvas.Children.Clear();Ellipse rightEllipse = new El-lipse();rightEllipse.Fill = Brushes.Red;rightEllipse.Width = 20;

rightEllipse.Height = 20;MainCanvas.Children.Add(rightEllipse);ScalePosition(rightEllipse, first.Joints[JointType.HandRight]);

Secvența de mai sus poziționează o elipsă roșie deasupra mâinii drepte a uti-lizatorului (în canvas-ul MainCanvas) și e un exemplu foarte simplu de folosire a datelor scheletice oferite de Kinect.

Skeleton GetFirstSkeleton(AllFramesReadyEventArgs e){ using (Skeleton-Frame skeletonFrameData = e.OpenSkeletonFrame()) { if (skeletonFrameData == null) { return null; } skeletonFrameData.CopySkeletonDataTo(allSkeletons);

Skeleton first = (from s in all-Skeletons where s.TrackingState == Skel-etonTrackingState.Tracked select s).FirstOrDefault(); return first; }

}

Metoda getFirstSkeleton primește c a a r g u m e n t u n o b i e c t d e t i p AllFramesReadyEventArgs și returnează primul schelet (dintr-un număr de maxim șase – în funcție de câți utilizatori au fost surprinși în cadrul înregistrat de Kinect).private void ScalePosition(FrameworkElement element, Joint joint) { Joint scaledJoint = joint.Scale-To(1280, 720, .3f, .3f); Canvas.SetLeft(element, scaled-Joint.Position.X); Canvas.SetTop(element, scaled-Joint.Position.Y); }

Metoda ScalePosition poziționează un element grafic (argumentul element, de tip FrameworkElement - în cazul nostru, o elipsă roșie transmisă din event handler-ul sensor_AllFramesReady) în funcție de poziția unei încheieturi din scheletul utilizatorului (argumentul joint, de tip Joint – în cazul nostru, mâna dreaptă a utilizatorului).

Un obiect de tip Joint conține date ce descriu o anumită încheietură, date ce conțin și poziția exactă a acesteia în spațiu. Poziția e stocată în joint.Position, un vector format din trei elemente (X,Y,Z),

fiecare conținând o valoare exprimată în metri. Pentru a reprezenta încheietura pe ecran, trebuie mai întâi să-i convertim poziția pe planul XoY din metri în pixeli, motiv pentru care folosim metoda ScaleTo, inclusă în dll-ul Coding4Fun, accesibil la adresa http://c4fkinect.codeplex.com/. E o variantă ușoară de conversie, perfecta pen-tru o aplicație simplă, cum e și cazul acum.

Totuși, conversia se poate realiza și manual, după cum vom vedea în exem-plele din numerele următoare. private void StopKinect(KinectSensor sensor){ if (sensor != null){ if (sensor.IsRunning){ sensor.Stop(); if (sensor.AudioSource != null) { sensor.AudioSource.Stop(); } } }

}

Metoda StopKinect oprește senzorul.private void Window_Closing(object sender, System.ComponentModel.CancelEventArgs e){ closing = true; StopKinect(kinectSensorChooser.Kinect);}

Înainte să închidem aplicația, oprim senzorul.

Pe viitorÎn articolul următor, vom include o

secvență de cod ce afișează întreg scheletul utilizatorului, iar pe parcursul numerelor următoare vom adăuga alte funcționalități utile, cum ar fi decuparea corpului utiliza-torului din cadrul RGB oferit de Kinect, elemente de recunoaștere a gesturilor sau procesarea manuala a datelor de adân-cime obținute de senzor, pentru a urmări anumite parți ale corpului utilizatorului, independent de datele scheletice oferite de Kinect. În plus, vom include un link către proiectul ce va conține funcționalitățile implementate până atunci.

Microsoft Kinect

Page 29: Today Software Magazine N3/2012

29www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

cel mai la îndemână mi-a fost să urmăresc cu atenție ce se întamplă pe piața de IT. Am observat o dispoziție firească a unor procese și sisteme de HR de a evolua spre un scop determinat, deci o tendință! În rândurile de mai jos voi rezuma, din per-spectiva mea câteva tendințe, pe care le consider ca având un impact substantial în evoluția pieței.

Managementul talentelor - un pro-ces complex, ce consta in patru etape importante. Sintentizarea teoretică a pro-cesului ar consta în atragerea, motivarea și dezvoltarea talentelor pentru obținerea unei performanțe ridicate.

Practic, deși, recrutarea și selecția se face într-un ritm alert, nu se pierd din vedere competențele care joacă un rol esențial în crearea profilului candidatului perfect, care să acopere o nevoie de busi-ness, de cele mai multe ori stringentă. În contextul în care talentele sunt scumpe și nu fac referire strict la partea financiară, ci la ceea ce caută într-o companie, este dificil să te poziționezi ca fiind o compa-nie care să fie prima opțiune a angajațiilor pe piață. Un candidat pregătit caută un

mediu organizațional stabil, care să îi valorifice talentul și care să îi ofere o sta-bilitate financiară, în strânsă corelație cu tendințele salariale de pe piață.

Motivarea unui angajat talentat, care are alte zeci de opțiuni pe piață, este o pro-vocare mare pentru fiecare departament sau nivel de management. Rolul depar-tamentului de HR este inxistent dacă nu este susținut întreg procesul de fiecare șef de departament sau de fiecare reprezen-tant al echipei de management. Poveștile de succes din companiile cu un nume pe piața de IT te fac să crezi că se poate. Succesul acestora, din punctul meu de vedere, are legatură nu doar cu asigurarea unui venit consistent, ci și cu alți câțiva factori, uneori uitați. Orice angajat care a ajuns la un nivel de expertiză ridicat caută să i se valorifice talentul cât mai mult posibil. Dați ocazia angajaților talentați să aducă plusul de valoare în companie! Oferiți-le un plan de dezvoltare al carie-rei, care să-i convingă că mediul din care fac parte este cel care contribuie la dez-voltarea abilităților și competențelor lor.

Cât de des v-ați gândit că în felul acesta puteți păstra și motiva talentele ?

D e z v o l t a r e a c o m p e t e n ț e l o r ș i a abilități lor soft . Încerc o clarificare a conceptul de soft, în contextul prezentu-lui articol. În limba română nu este un termen care să-i ofere aceeași semnificație pe care o are în limba engleză. Motiv pen-tru care am preferat păstrarea lui așa, cu explicațiile de rigoare. Î n v i z i u n e a m e a , abilități soft se referă la cele de leadership,

Se vorbește mereu despre tendințe. Până să încep să scriu acest articol, nu am avut curiozitatea să înțeleg în profunzime semnificația acestui cuvânt. Şi cum mereu cea mai bună sursă este dex-ul, am început să citesc simpla și banala explicație prezentată acolo. Tendința înseamnă o dispoziție firească pentru ceva, înclinare, pornire, acțiune conștientă spre un scop determinat. O altă definiție ne spune că tendința reprezintă o evoluție a cuiva într-un anumit sens. Pornind de la această formulare m-am gândit câteva zile care ar fi conexiunea între tendință și domeniul în care lucrez – HR. Şi

Andreea Pâ[email protected]

Recruiter în cadrul Endava și trainer specializat în dezvoltarea abilităților si competenețelor de leadership, comunicare și muncă în echipă

Tendințe în HR

HR

Page 30: Today Software Magazine N3/2012

30 nr. 3/2012 | www.todaysoftmag.ro

Tendințe in HR în 2012HR

comunicare, lucru în cadrul unei echipe, coaching, managementul timpului, etc. Se remarcă o accentuare a dezvoltarii acestor competențe și trecerea peste stereotipul conform căruia specialiștii în IT trebuie doar să dețină abilități tehnice. Până la un anumit nivel poate avea loc o acumulare și/sau o dezvoltare a cunoștintelor despre un limbaj de programare, însă de acolo încolo, se conștientizează din ce în ce mai mult faptul că lipsa abilităților soft poate îngrădi evoluția în carieră. Acest proces de HR este în strânsă concordanță cu ceea ce numim ”career development path”, adică acel drum în carieră care îți oferă un pro-ces organizat de dezvoltare. Ce am observat până acum este că după aproximativ cinci ani de experiență există două direcții spre care se orientează specialiștii IT (am sters se concentrează): (1)direcția tehnică – software architect (am incercat să găsesc o denumire general înțeleasă) și (2) direcția oameni – team leading sau project manage-ment. În cazul al doilea, este lesne de înțeles de ce este nevoie de dezvoltarea, în preala-bil, a unor abilități ce țin de coordonarea unei echipe și a unui proiect. Însă mulți se întreabă care este rolul acestor abilități în primul caz ? Răspunsul este cât se poate de simplu: comunicarea și managementul timpului.

Creșterea salariilor nefundamentată, comparativ cu media celor existente. În general, pe piața de IT există câțiva jucători care au intrat pe piață cu salarii foarte mari pentru a atrage cât mai mulți angajați, cu scopul de a acoperi necesarul pe proiectele dezvoltate. Consecința principală a fost că aceste creșteri au ajuns greu de controlat. Deși există companii cu un mediu sta-bil, care conștientizează faptul că această consecință produce instabilitate, marea majoritate a persoanelor care participă la un interviu de angajare au așteptări financi-are foarte ridicate, dorind creșteri de chiar 100% a salariilor. Paradoxul este că există o serie de companii care se adaptează la aceste expectanțe, pe când altele, pe care le numesc ”normale”, pierd persoane care chiar s-ar potrivi mediului organizațional respectiv.

Ne-am întrebat de nenumărate ori : ce e mai bine ? Să te adaptezi și să intri în peri-oadă de criză sau să îți păstrezi ritmul de creștere și pe termen lung să supraviețuiești

unei piețe aflate în dezechilibru?

Flexibilitatea și adaptarea politicilor de HR pe baza nevoilor business-ului. Este una din tendințele care au inceput să prindă contur încă din 2011. Piaţa, din toate punctele ei de vedere, mai ales cea de IT, este într-o continuă evoluţie. Politicile de HR trebuie să răspundă nevoilor busi-ness-ului. Acestea trebuie să evolueze și să se adapteze mereu pieţei. Singurul aspect care nu îți oferă flexibilitate este partea administrativă, care are la bază un set de reguli general acceptate prin votarea codu-lui muncii.

Când am gândit acest trend, mi-a fugit mintea în primă fază la procesul de recru-tare. Mijloacele clasice de identificare a candidațiilor nu mai au același rezultat precum cel observat în urmă cu cativa ani. Dacă până în urmă cu 3 ani principala sursă de descoperire a candidațiilor erau site-urile deja devenite clasice, în prezent acestea ocupă un loc secund. Adaptarea la nevoile business-ului înseamnă căutarea unor mijloace mai puțin convenționale și identificarea unor instrumente care să per-mită accesul la cele mai bune talente. Mai mult decât atât, nevoile de business sunt în strânsă conexiune cu acceptarea unor termene limită, din ce în ce mai strânse. Deși în HR nu se folosește conceptul de Agile, consider că ar fi benefică o astfel de abordare, în care cerințele și soluțiile sunt facilitate printr-o auto-organizare și eficiența. Această metodologie încurajează adaptarea, planificarea, răspunsul rapid și flexibil de a determina o schimbare. Câteva din principii pot fi ușor adaptat chiar și pe departamentul de HR :

• Interacțiunea între persoane mai presus de procese și instrumente. În limbaj de recruiter se traduce prin construirea unei relații pe termen lung cu candidații. În alte sensuri, văd relevanța acestei interacțiuni inclusiv în tot procesul de managementul performanței: definirea și atingerea unor obiective printr-un proces corect implementat de coaching sau în procesul de dezvoltare al carierei. Cu cât interacționezi mai mult cu un angajat, cu atât îl cunoști mai bine, știi ce îl motivează și ce își dorește.

• Colaborarea cu clienții peste ceea ce înseamnă ”un contract sau o înțelegere scrisă”. Ca departament de HR, clientul tău

este întreaga companie. Clientul identifică o nevoie de recrutare și/sau o nevoie de dezvoltare, iar departamentul de HR, prin diversele sale arii (recrutare și selecție, trai-ning, etc) trebuie să satisfacă aceste nevoi.

• Adaptarea la schimbare. Există numeroase situații în care dacă se pierde pasul schimbărilor din business, munca întregului departament de HR nu va aduce niciodată rezultatele scontate. Un exemplu cât se poate de concret este acela în care, dacă până în urmă cu câțiva ani, principala abilitate a unui recruiter in IT era să poată o serie de competențe pe parcursul unui interviu, acum acesta (am sters este necesar să aibă) trebuie să prezinte o înțelegere cât se poate de bună a business-ul și a tehno-logiilor, pentru a recruta cele mai potrivite persoane.

Investiția în tineri. Implicarea compa-niilor în diverse programe pentru studenți sau proaspăt absolvenți, care încurajează dezvoltarea acestora intr-o piață în care tendința este de ”schimb neorganizat între angajații seniori”. Sunt promovați tinerii cu potențial care, într-o perioadă determinată de timp, aduc suflu proaspăt într-un mediu de lucru. Este demonstrat că tinerii cu vizi-une pot schimba direcția de lucru și de dezvoltare a unei companii. Interesant este că există o tendința de adaptare a culturii organizaționale deja existente la integrarea tinerilor. Din ce în ce mai multe colaborări cu universitățile tehnice și cu organizațiile studențești oferă accesul la studenți de top. Mai mult, aceștia, dacă sunt educați într-un mediu care încurajează angajamentul, se pot atașa de companie și pot aduce rezultate pe termen lung. În partea ves-tică a Europei, numeroase studii susțin că angajatii cărora li se oferă posibilitatea să își dezvolte potențialul și ale căror merite sunt recunoscute, cresc rata retenției într-o companie.

La fel ca în modă, tendințele vin și trec, dar angajații motivați vor rămâne mereu. Ne-am dori ca pe viitor mai multe com-panii de pe piața de IT din Cluj să ia în considerare măcar câteva din tendințele enumerate mai sus, pentru a putea fi obser-vată o evoluție sănătoasă a forței de muncă din acest domeniu.

prezentare

Page 31: Today Software Magazine N3/2012

31www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

31

TODAY SOFTWARE MAGAZINE

Proiectul CIVITAS – Archimedes IAȘI

Proiectul Archimedes este format dintr-un amestec de măsuri inovatoare, integrate și ambițioase pentru un mediu curat, eficiența enegertică, transport urban durabil, și prin urmare, să aibă un impact semnificativ asupra politicilor în materie de energie, de transport și protejarea mediului.

Arobs Transilvania Software a oferit o soluție completă – hardware și software - pentru fluidizarea și crearea unui confort sporit a procesului de eliberare legitimații de călătorie pentru trasnsportul în comun, în municipiul Iași, beneficiar al acestui proiect

Sebastian Botiș[email protected]

Project Manager – CSM, CSPOSpecialized in Agile MethodsArobs Transilvania Software

European.Această soluție constă în reali-zarea unor chioșcuri, de tip “self service”. Într-o lume modernă nu se poate ignora posibilitatea creșterii acestor mijloace de interacțiune între utilizatori și instituțiile care oferă diverse servicii societății în care trăim.

Ce reprezintă un chiosc interactiv?Se poate defini ca fiind un dispozi-

tiv electronic, chiar un minicalculator, cu ajutorul căruia, utilizatorii pot accesa intr-un timp foarte scurt și foarte confortabil, diverse informații sau să beneficieze de diverse servicii oferite de către autoritațile locale sau de prestatorii privați de servicii.

Un pic de istorieIstoria chioșcurilor nu este una foarte

lungă dar nici foarte recenta. În 1977, a fost dezvoltat primul chioșc interactiv, la Universitatea din Illinois de către un stu-dent numit Murray Lappe. Conținutul a fost creat pe un calculator PLATO, iar interacțiunea cu utilizatorii s-a reali-zat folosind un ecran tactil de tip plasmă (inventat de asemenea de aceeași uni-versitate). Scopul inițial al acestui chioșc interactiv a fost facilitarea informării tuturor studenților și vizitatorilor despre diferitele servicii puse la dispoziție de către autoritațile locale.

Însă primul chioșc comercial a fost introdus pe piață mai târziu, în anul 1985 de către o firmă din California, pentru a da posibilitatea utilizatorilor să fie informați în legătură cu stocurile de pantofi, care nu pot fi achiziționați din magazinele dedicate de tip retail.

Ceva mai târziu, în 1991, firma Comdex introduce primul chioșc care are o conexi-une la internet, oferind o aplicație prin care se puteau localiza copiii pierduți.

Tipuri de chioscuri:În zilele noastre, s-a reușit dezvolta-

rea de chioșcuri sub diferite forme, având în același timp și scopuri diferite. Scopul unora este doar de informare, iar altele au ca scop oferirea de servicii. Mai jos amin-tim câteva tipuri de chioșcuri folosite peste tot in lume: informații publice sau turistice, achiziționarea de produse (bilete la film, bilete pentru transportul in comun), reali-zarea și cumpărarea de fotografii, etc.

Au fost amintite doar câteva dintre cele existente iar în acest articol, ne vom îndrepta atenția spre cel ce ofera posibili-tatea de a fluidiza vânzarea legitimațiilor pentru transportul public.

Descrierea soluțieiPlecând de la necesitățile locuitorilor

municipiului Iași, în colaborare cu Primăria Iași și Regia Autonomă de Transport Public Iași, am reușit să formăm in prima faza, o viziune a soluției pentru fluidizarea si modernizarea vânzării legitimațiilor de călătorie pentru transportul public.

Ținând cont că suntem într-o conti-nuă dezvoltare și într-o continuă căutare și extindere a soluțiilor existente, am incercat

prezentare

Page 32: Today Software Magazine N3/2012

32 nr. 3/2012 | www.todaysoftmag.ro

prezentare

ca plecând de la această viziune, să reușim să construim un sistem matur, care să poată deveni în orice moment disponibil pentru adoptarea de noi idei și extinderea funcționalității. În continuare, pentru a asi-gura o prezență indelungată la dispoziția utilizatorilor, un factor important deloc neglijat, a fost și procesul de întreținere a soluției, cât și protejarea contra acte-lor de vandalism, limitând poate, în acest sens, o exprimare mai modernă în ceea ce privește anumite aspecte de ușurința în funcționalitate și aspect.

Descrierea soluției – detaliiPentru a putea acoperi in totalitate

sau în mare parte aceste aspecte, am decis folosirea platformei Microsoft în reali-zarea acestei soluții, folosind modelul client-server.

Aplicația-server expune trei mari apli-catii web prin care se comunica cu baza de date (SQL Server), prin Entity Framework, cât și cu clientul prin expunerea de ser-vicii folosind WCF Data Services (inițial cunoscută sub numele de ADO.NET Data Services) fiind o componenta a .NET Frameworkului.

Prin intermediul serviciilor oferite de către aplicația-server, există posibilitatea de a manipula tipul de legitimații pe care aplicația-client ar trebui să le expună, cât și restricțiile pe care aplicația-client tre-buie să le îndeplinească. În acest fel există posibilitatea de a manipula foarte ușor toate tipurile de legitimații pe care Regia Autonomă de Transport Public le poate modifica și de a introduce altele noi la un moment dat.

Totodată, tot prin intermediul servici-ilor oferite de către aplicația-server, prin intermediul funcțiilor de back office, se poate face o atentă monitorizare a actiu-nilor făcute la nivelul terminalelor, atât a proceselor de vânzare a legitimațiilor cât și supraveghere video permanentă, pentru a reuși să limităm actele de vandalism pre-zente, din păcate, la nivel destul de mare. Având de altfel un sistem de notificare a actelor de vandalism bine pus la punct, spe-răm să reușim să limităm aceste acte pe cât posibil, și să se reușească o disponibilitate online a aparatelor cât mai lungă.

Tot prin intermediul serviciilor și aplicațiilor de back office oferite de către server, se poate face o atentă monitorizare a componentelor hardware, cu care termina-lele de bilete au fost echipate. În acest mod,

se poate optimiza procesul de întreținere, cât și posibilitatea de a reuși remedierea cât mai rapidă a situațiilor special apă-rute, pentru a putea oferi o funcționalitate permanentă.

Aplicația client este prevăzută să ofere cetățenilor acces la serviciile de vânzare legitimații, oferind toata gama de tipuri de legitimații existentă la ora actuală in oferta RATP. Aplicația client a fost dezvoltată folosind tehnologii Microsoft precum WCF (Windows Communication Foundation), WPF (Windows Presentation Floundation) și Entity Framework, în cazul comunicării cu bazele de date.

Modulul client, prin HAL (Hardware Abstraction Layer), realizează o continuă comunicare și monitorizare a tuturor com-ponentelor hardware la nivel de chioșc. Am reușit să dezvoltăm driverele necesare pentru comunicarea cu aceste componente, astfel încât am putut să ne adaptăm tuturor situaților speciale și dorințelor cetățenilor, pentru a oferi o mai bună experiență în operarea acestor terminale de bilete.

Tipuri de legitimatii oferiteCum s-a amintit mai devreme în

articol, beneficiarii acestei aplicații, pot manipula cu foarte mare ușurință orice tip de legitimație, în același timp, putând introduce în orice moment, prin inter-mediul aplicației-server, orice tip nou de legitimații.

Inovația acestui sistem este introducerea posibilitații de a achiziționa legitimații de tip abonament atât persoanelor din Romania cât și persoane-lor din afara țării. Legitimațiile de tip abonament, fiind nomi-nale, am oferit posibilitatea ca toate aceste informații să fie “ascunse” prin utilizarea codurilor QR. Pentru a valida un astfel de abonament, con-trolorii vor avea, în curând, dispozitive pentru a putea citi și valida aceste coduri QR. Mai jos, in figura, se poate vedea o

legitimație de tip abonament.Încă un amănunt de semnalat este fap-

tul că, legitimațiile de tip abonament se adresează atât studenților cât și elevilor, ținându-se cont de perioadele de început și sfârșit ale anului universitar respectiv școlar.

Posibilități de platăUn aspect, deloc de neglijat credem

noi, este legat de înglobarea într-un singur terminal a tuturor modalităților existente de plată. Plata la aceste chioșcuri se poate realiza folosind următoarele modalități: cu monezi – 10 bani și 50 de bani, cu banc-

note – 1 leu, 5 lei, 10 lei si 50 lei, cât și plata cu credit card – visa & mastercard cu cip. Restul se dă, la cererea RATP, doar în monezi. Pe langă monezi, s-a introdus, pentru cazul în care nu sunt monezi dis-ponibile pentru rest sau probleme tehnice la terminal, un cod RATP, prin care clienții îl pot folosi în rețeaua internă RATP de terminale sau își pot recupera banii de la sediul central RATP.

programareProiectul CIVITAS - Archimede Iași

Page 33: Today Software Magazine N3/2012

33www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

33

TODAY SOFTWARE MAGAZINE

Cele mai întâlnite forme de DI sunt următoarele:

• Tipul 1: injectare la nivel de interfață (interface injection)

• Tipul 2: injectare la nivel de metoda (setter injection)

• Tipul 3: injectare la nivel de con-structor (constructor injection)

Ce este Guice?Conform paginii oficiale„Guice diminuează nevoia de a folosi

operatorul new și clase de tip Factory în codul Java. Gândește-te la adnotarea @Inject din Guice ca la noul new. Guice îmbrățișează natura type safe oferită de Java, mai ales când vine vorba de funcționalități introduse în Java 5 precum tipurile generice și adnotările. Te poți gândi la Guice ca la un framework care comple-tează funcționalități lipsă din Java core. Într-o lume ideală, limbajul însuși ar trebui să furnizeze aceste funcționalități, dar până când va apărea un astfel de limbaj, te poți baza pe Guice.”

Dacă ai folosit Spring sau alte

framework-uri de DI, îți sunt cunoscute ideile enumerate mai sus. Vom prezenta în acest articol cum să începi să folosești Guice într-o aplicatie non-web. Vom deta-lia partea web într-un articol viitor.

Guice oferă toate tipurile de injectare enumerate mai sus (field, setter și construc-tor), spre deosebire de Spring spre exemplu care oferă doar tipurile 2 și 3.

Guice vs Spring?Aceasta este una dintre acele discuții

care pot ține la nesfârșit. Precum EJB vs Spring, Struts vs JSF ș.a.m.d. Este o ches-tie de gust. Pot spune un singur lucru însă: dacă ai nevoie doar de DI în aplicația ta folosește Guice. Dimensiunea librariei Guice este foarte mică, este type safe și este mai rapid decât Spring.

Folosind Guice într-o aplicație non-web

Să presupunem că avem o aplicație desktop, iar clasa care conține metoda main se numește Application. Atunci când folosim Guice abordarea este puțin

Dependency Injection-ul (DI) este o formă specializată de Inversion of Control(IoC) – un concept mai larg în care obiectele sunt cuplate la runtime de către o sursă externă – de obicei un container – deseori referit ca și IoC container. Prin DI putem selecta diferite implementări ale dependințelor la runtime, printr-un fisier de configurare spre exemplu, ceea ce constituie un avantaj major atunci cand vine vorba de unit testing. Injectarea obiectelor mock devine foarte simplă ceea ce face foarte ușoară testarea în izolare a aplicației.

Mădălin [email protected]

Cluj Java Discipline LeadEndava

Guice

programare

Page 34: Today Software Magazine N3/2012

34 nr. 3/2012 | www.todaysoftmag.ro

Guiceprogramare

schimbată.Pe lângă lansarea în execuție a aplicației avem nevoie și de o modalitate de a lansa injectarea dependințelor. Pentru a face acest lucru trebuie să declanșăm manual crearea grafului de obiecte care vor fi injectate si abia apoi să continuăm cu logica aplicației. Vom numi clasa responsa-bila pentru aceste două lucruri Bootstrap. Trebuie de asemenea să creăm un Module extinzând clasa AbstractModule. Cităm din Java Doc-ul interfeței Module:

Un modul reunește elemente de confi-gurare, în general legături (binding-uri) de interfețe, care vor fi folosite pentru crearea unui Injector. O aplicație bazată pe Guice este în final compusă din puțin mai mult decât un set de Module și cod de lansare in execuție (bootstrapping code).

Prezentarea codului:

Clasa Bootstrappackage com.insidecoding.guice;import com.google.inject.Guice; import com.google.inject.Injec-tor;/** * Clasa Bootstrap care crează obiectul rădăcină care va declanșa crearea și injectarea * grafului de obiecte */public class Bootstrap {public static void main(String[] args) { Injector injector = Guice.createInjector(new MyModule()); Application app = injector.getInstance(Application.class); app.start(); }}

Interfața Applicationpackage com.insidecoding.guice;public interface Application { /** * Lansează în execuție aplicația curenta */ void start();}

Clasa ApplicationImplpackage com.insidecoding.guice;import com.google.inject.Inject;

public class ApplicationImpl im-plements Application {@Inject private PrintingService ip;public void start() { ip.print(„Hello from guice”); }}

Să presupunem că logica aplicației

este după cum urmează: folosește PrintingService pentru a printa un String, iar serviciul de printare va folosi CachingService pentru a pune in cache acel String. Implementările acestor servicii vor fi injectate in clasa ApplicationImpl și PrintingServiceImpl folosind Guice.

Interfața PrintingServicepackage com.insidecoding.guice;import com.google.inject.Imple-mentedBy;

@ImplementedBy(PrintingServiceImpl.class)public interface PrintingService {/** * Printează un String * @param s */ void print(String s);}

Clasa PrintingServiceImplpackage com.insidecoding.guice;

import javax.inject.Inject;

public class PrintingServiceImpl implements PrintingService {

@Injectprivate CachingService cs;

@Overridepublic void print(String s) { System.out.println(s); cs.cacheIt(s); }

}

Interfața CachingServicepackage com.insidecoding.guice;

import com.google.inject.Imple-mentedBy;

@ImplementedBy(CachingServiceImpl.class)public interface CachingService {

/** * Pune in cache un String * @param s */void cacheIt(String s);}

Clasa CachingServiceImplpackage com.insidecoding.guice;

public class CachingServiceImpl implements CachingService {

@Overridepublic void cacheIt(String s) { System.out.

println(„Caching: „ + s); }}

Clasa MyModulepackage com.insidecoding.guice;

import com.google.inject.Ab-stractModule;

public class MyModule extends Ab-stractModule {

@Overrideprotected void configure() { bind(Application.class).to(ApplicationImpl.class); }}

Codul este destul de simplu si intuitiv. Pentru a compila codul de mai sus aveți nevoie de următoarele librării in classpath:

• aopalliance.jar• guice-3.0.jar• javax.inject.jarDacă arunci o privire atentă in codul

de mai sus o să observi o mică diferență în ceea ce privește injectarea dependințelor: clasa ApplicationImpl folosește adno-tarea com.google.inject.Inject iar clasa PrintingService folosește adnotarea javax.inject.Inject. Aceasta din cauză că Guice 3.0 este compatibil cu JSR-330. Mixarea adnotărilor JSR-330 cu cele din Guice este descurajată, asa că ramânem la @Inject din Guice.

Tipuri de injectareGuice permite 3 tipuri de injectare:• injectarelaniveldecâmp• injectarelaniveldeconstructor• injectarelaniveldemetodăAm văzut în acțiune injectarea la nivel

de câmp în codul de mai sus. Pentru a folosi injectarea la nivel de constructor vom modifica clasa PrintingServiceImpl după cum urmează:

package com.insidecoding.guice;

import javax.inject.Inject;

public class PrintingServiceImpl implements PrintingService {

private CachingService cs;

@Inject public PrintingServiceImpl(CachingService cachingService) { this.cs = cachingService; }

@Override

Page 35: Today Software Magazine N3/2012

35www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

public void print(String s) { System.out.println(s); cs.cacheIt(s); }}

Trebuie menționat că atunci când se folosește injectarea la nivel de câmp Guice va crea constructorul fără nici un argument pentru a instanția obiecte.

Se poate folosi și injectarea la nivel de metodă pentru injectarea parametrilor. Guice va rezolva toate dependințele înainte de invocarea metodei. Metoda poate avea un număr oricât de mare de parametri, iar numele nu are nici un impact asupra injec-tării. Injectarea la nivel de metodă arată ca mai jos:

@Injectpublic void printMe(PrintingService ps) { ps.print(„Printing with Guice method injection”); }

Injectarea constantelorGuice ofera o sintaxă foarte intuitiva

pentru injectarea constantelor:bindConstant().annotatedWith(name).to(value);

Metoda to() poate primi atât o valoare primitivă, cât și String, Enum sau un Class. Sintaxa de mai sus nu oferă însa și type checking la compilare. Guice face conver-sie automată a valorii din metoda to() către tipul valorii adnotate cu name. Haideți să vedem câteva exemple. Presupunem că avem următoarea constantă definită în clasa PrintingServiceImpl:

...public class PrintingServiceImpl implements PrintingService { @Inject @Named(“myConstant”) private String printersNumber; private CachingService cs;

...Pentru a injecta o valoare concreta

variabilei printersNumber folosim în clasa MyModule sintaxa menționată mai sus:@Overrideprotected void configure() { bind(Application.class).to(ApplicationImpl.class); bindConstant().annotatedWith(Names.named(„myConstant”)).to(„345”); }

In cazul de față nu este nevoie de nici o conversie. Daca printersNumber ar fi de tip Integer sau int, Guice ar face conversie

automată de la String la tipul întreg.Ce se întâmplă însă dacă declarăm vari-

abila printersNumber de tip Integer, iar bindingul îl facem la o valoare de tip String.

...public class PrintingServiceImpl implements PrintingService { @Inject @Named(“myConstant”) private Integer printersNumber; private Caching-Service cs; ...@Overrideprotected void configure() { bind(Application.class).to(ApplicationImpl.class); bindConstant().annotatedWith(Names.named(„myConstant”)).to(„exception”);}

Probabil intuiți deja că o sa să primim o excepție. Mai exact com.google.inject.ConfigurationException.

Putem forța și type checking la com-pilare atunci când injectăm constante folosind următoarea sintaxa:bind(Integer.class).annotatedWith(name).toInstance(value);

În acest caz value trebuie sa aibă tipul Integer încă de la compile time – bineînțeles autoboxing-ul va funcționa.

@ImplementedBy vs bind()Se poate observa în codul de mai sus

două modalități de a lega interfețe de implementări:

• anotareainterfețeicu @ImplementedBy

• foloseștemetodabind()methodîntr-un Module pentru a specifica imple-mentarea propriu-zisă: vezi metoda MyModule.configure().

Pentru cazuri simple și interfețe cu o singură implementare poți folosi fără pro-bleme abordarea cu @ImplemenedBy, însă dacă ai nevoie de mai mult control asupra legăturilor dintre interfețe și implemen-tări sau dacă ai mai mult implementări ale unei interfețe folosește abordarea cu bind() method.

ScopingUn lucru important de menționat este

faptul ca Guice returnează implicit o nouă instanță ori de câte ori furnizează o valoare pentru a fi injectată.

Guice oferă următoarele scopuri:• prototype–celimplicit• singleton – caz special eager

singleton

• session(disponibilcapartedinextensia de servlet)

• request(disponibilcapartedinextensia de servlet)

• customAlegerea scopului ar trebui să fie des-

tul de evidentă. Dacă obiectul este statefull, per -application ar fi @Singleton, per-request @RequestScoped, per-session @SessionScoped. Dacă obiectul este stateless și ușor de creat, scoping-ul nu este nece-sar. Guice va returna instanțe noi de fiecare dată.

În codul de mai sus poți trece la single-ton-uri folosind următorul cod: bind(CachingService).to(CachingServiceImpl).in(Scopes.SINGLETON)

Spuneam că există un caz special: eager singleton. Acest tip de inițializare permite construirea obiectelor de tip singleton atunci când aplicația pornește, nu atunci când este nevoie. Îți permite astfel să detec-tezi dintr-un stadiu incipient problemele de inițializare. În funcție de stage-ul aplicației (controlat folosing valori ale enum-ului Stage) există tipuri de inițializări default pentru obiectele singleton. Pentru a forța eager singleton in development stage se folosește următoarea sintaxă: bind(CachingService).to(CachingServiceImpl).asEagerS-ingleton()

@RequestScoped și @SessionScoped vor fi detaliate în articolul pentru web

applications.

Aceasta este doar o introducere in Guice. Poți face mult mai multe lucruri folosind Guice și sperăm ca v-am deschis apetitul pentru a descoperi tot ceea ce oferă. Dacă aveți nevoie de un framework mic și rapid pentru DI, Guice este peste Spring „all the way”.

Page 36: Today Software Magazine N3/2012

36 nr. 3/2012 | www.todaysoftmag.ro

imagina. Avem o mulţime de utilizatori simultan pe un singur server, care așteaptă date. Cum răspundem la atâtea cereri?

Sunt mai multe limbaje de programare care au un răspuns pentru această pro-blemă, dar înainte de a intra în detalii, ar fi bine să vedem un exemplu simplu: cum putem muta o grămadă de cărămizi de la o locaţie la alta?

Cu un singur camion această operaţi-une va dura prea mult timp. Cum putem să facem toată operaţiunea mai rapidă? Putem să adăugăm încă un camion!

În acest fel, transportul este mai rapid, dar vor fi blocaje la locaţia iniţială și de destinaţie. De asemenea, avem nevoie de sincronizarea camioanelor.

Am putea elimina blocajele făcând camioanele independente!

În acest fel, grămada iniţială va fi mutată de două ori mai repede, și camioa-nele se mișcă independent. Putem adăuga oricâte benzi de acest tip, dar timpul de operare pentru un camion încă durează prea mult.

Să încercăm o altă abordare. Ce se întâmplă dacă adăugăm încă două cami-oane, dar de data aceasta cu o întârziere?

În acest fel fiecare camion funcţionează

independent cu puțină coordonare - comu-nică între ei la un anumit nivel.

Putem adăuga încă un camion pentru a obţine un flux mai bun. Fiecare camion are de făcut o sarcină simplă acum, și cu puțină sincronizare ne apropiem de un

Procesoarele noi continuă sa vină. Două nuclee per procesor par să fie depășite, chiar și pe telefonul mobil; GPU-urile se pot folosi pentru operații computaționale și au tot mai multe nuclee, 1500+ mai nou. Cum le folosim pe toate? Care este următorul pas? Cum se poate menţine ritmul de dezvoltare cu progresul hardware -ului?

Pe zi ce trece cloud-urile devin din ce în ce mai mari. Avem de a face cu processing clouds și data clouds; ele pot răspunde la mai multe cereri decât mintea umană își poate

Béla Tibor [email protected]

Software Engineer @ Macadamian

Programare concurentă modernă

programare

Page 37: Today Software Magazine N3/2012

37www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

flux de patru ori mai rapid decât în designul original.

Deci, am îmbunătăţit performanţa prin adăugarea a două camioane concurente la modelul existent.

Metoda de mai sus este doar un mod de a paraleliza procesul, dar putem com-bina cele două modele. Acest model de opt camioane va funcţiona la capacitate maximă:

Acesta este un design concurent vala-bil, chiar dacă numai un camion se mută într-un anumit moment – dar nu avem paralelism.

Să vedem un pic diferenţele dintre con-curenţă și paralelism, sau cel puţin cum le putem defini:

Paralelism• Execuţia simultană de procese• Se fac o mulţime de lucruri

deodată• Comportamentul aplicaţiei este

deterministic

Concurență• Manipularea mai multor lucruri

d e o d at ă pr i n s t r u c tu r are a

procesului• Piesele pot lucra independent,

coordonate doar prin comunicare• Compoziţie nedeterministică a

programelor

Concurenţa oferă o modalitate de a structura o soluţie pentru a rezolva o pro-blemă care poate să fie (dar nu neapărat) paralelizabilă.

Să luăm un alt exemplu:• Design concurent: mouse, tasta-

tură, ecran, unităţi de disc• Design paralel: produsul scalar a

doi vectoriÎn acest exemplu, dispozitivele pot

lucra independent, comunicând cu fluxuri de date, lucrează în paralel, dar nu în mod necesar; pe de altă parte produsul scalar a 2 vectori este un exemplu de design paralel.

În limbajele “vechi” (cum ar fi C / C + +, Java), vom folosi o mulţime de design patterns pentru paralelizare, de exemplu: Double checked locking pattern, Thread pool pattern, Thread-Specific Storage, Scheduler pattern, Active Object… Cele mai multe dintre acestea au ceva în comun: folosesc sincronizarea. Acesta este mai mult un design paralel, dar designul con-curent este un pic diferit.

În 1978, CAR Hoare a publicat cartea sa: Comunicarea Proceselor Secvenţiale (Communicating Sequential Processes). În această carte, el definește un limbaj pen-tru a descrie modelele de interacţiune în sistemul concurent. Aceasta este baza pro-gramării concurente moderne.

Câteva dintre limbajele de progra-mare care implementează acest design: Go,

Erlang, F #, occam, Clojure, SuperPascal, Ada.

Aceste limbaje au în comun:• utilizează comunicarea în loc

de sincronizare directă între threaduri.

• thread-urile sunt înlocuite cu light-weight routines, numite goroutines / procese / 1.

• acestea nu sunt neapărat mapate la thread-urile sistemului de operare, acest lucru înseamnă că runtime -ul poate decide modul în care le gestionează.

• milioane de threaduri se pot exe-cuta în același timp - de exemplu, Go a fost văzut cu 1,3 milioane de goroutines, la un moment dat.

Având o mulţime de rutine lightweigh, înseamnă că runtime-ul poate mapa threaduri reale dacă este nevoie, ceea ce înseamnă că putem folosi atâtea nuclee câte sunt disponibile.

Există câteva alte limbaje care imple-m e n t e a z ă c o n c u r e n ț a c a u n s u

bset:• C#, cu Task Parallel Library.• Obiective C, cu NSOperation și

dispatch queues.• D cu lightweight threads (simplu

numite threads) și mesagerie.• S t a c k l e s s P y t h o n c u

microthread-uri.

În viitorul apropiat, numărul de nuclee poate crește, pentru că am ajuns la frec-venţă maximă de procesor cu tehnologia actuală. Ești pregătit?

Page 38: Today Software Magazine N3/2012

38 nr. 3/2012 | www.todaysoftmag.ro

experiența mai mare in cazul persoanelor din EMBA își spune cuvântul în cadrul discuțiilor și interacțiunilor de la cursuri. PMBA-urile au aceleași materii, dar mai au și module destinate unui anumit dome-niu de studiu precum marketing, finanțe, resurse umane.

MBA-ul nu iți oferă o diplomă care să îți deschidă toate ușile. Angajatorii sunt atenți la rezultatele pe care le-ai avut in trecut, calitățile tale morale si intelectuale sau gradul în care te încadrezi în cultura organizațională.

De ce să fac un MBA, la ce mă ajută?Ai o parere bună despre tine, ai făcut

cam tot ce ai crezut că puteai face și totuși ai impresia că iți scapă ceva în munca coti-diană? Ai persoane pe care le coordonezi și iți iei în serios responsabilitatea de for-mator? Sunt multe lucruri pe care le faci din intuiție, dar parcă ai vrea să le confirmi cu cineva? MBA-ul poate oferi răspunsuri intrebărilor tale.

Cursurile pe care le urmezi îți deschid

mult mai bine perspectivele din care poți să analizezi o situație. De obicei avem o experiență într-un anumit domeniu, să spunem IT, dar o companie mai are și alte fațete: financiar, marketing, HR. În cadrul unei companii de IT din România persoanele au cam același traseu: încep ca și dezvoltator, parcurg mai multe etape pe scara ierarhică până în punctul când ajung manageri. Nu cred că e un secret, avem o părere bună despre noi ca și IT-iști, am performat din punct de vedere tehnic foarte bine, deci ce mare lucru să fii mana-ger? Este cert că ți-ai obișnuit managerii să ai rezultate foarte bune pe vechea poziție, așteptările sunt mari, iar acum trebuie să continui la fel într-un domeniu pe care nu-l cunoști. Îți vine repede ideea adoptării aceleiași metode ca și în cadrul proiectului: să fii agile. Nu merge din prima încercare, lasă că schimbi ceva pe parcurs. Dar dacă-deciziile tale afectează un departament sau o companie intreaga? Dacă cumva compa-nia respectivă este chiar a ta?

Ce este și ce nu este un MBA?MBA-ul este un program care curpinde mai multe cursuri care se întind pe o perioadă

cuprinsă între un an și doi ani. Există trei tipuri de programe: MBA, EMBA (Executive MBA) și PMBA (Proffessional MBA). Persoanele care se înscriu în cadrul MBA-urilor au o experiență de minim 3 ani în câmpul muncii și fac parte din middle management. EMBA-urile se adresează în general persoanelor de peste 35 de ani care sunt pe poziții de top management. Nu prea există o diferență între cele două programe ca și conținut insă Sorin Stan

[email protected]

Chief Strategy OfficerSoftVision

Avantajele unui MBA

management

Page 39: Today Software Magazine N3/2012

39www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

Ce programe există în țară și care sunt costurile?

În țară există aproximativ 14 programe: 7 MBA, 6 EMBA si un PMBA. Unele din-tre ele se mai întrerup și apar altele. Puteți căuta clasamentul făcut anul acesta de Ziarul Financiar și veți vedea care sunt cele mai importante. MBA-ul Româno-Canadian a fost anul acesta evaluat ca fiind cel mai bun din țară și confirm că este într-adevar așa, fiind absolvent anul acesta acolo. Își merită toți banii.

În cazul MBA Romano-Canadian costul a fost de 11,500 de euro pentru 18 cursuri care s-au întins pe un an și jumate. Fiind clujean, am mai avut costuri cu deplasarea. Mai exista și alte programe mai scumpe în țară sau poți să te înscrii în stră-inătate, costurile putând ajunge la 100,000 de euro. Există o dispută în ceea ce privește alegerea unui MBA, în țară sau în exterior, cel din afară fiind văzut ca unul ce iți aduce un prestigiu mai mare. Consider ca și cel local este foarte bun, singurul lucru impor-tant este sa fii serios și să inveți. Un profesor canadian îmi spunea ca noi facem aici exact aceleași materii ca și programul susținut în Canada, doar prețul diferă: acolo este undeva la echivalentul a 80,000 euro.

Am vorbit până acum de costurile vizi-bile. Desigur există și costuri de altă natură ce țin de timpul liber, cel petrecut cu fami-lia și prietenii sau cel destinat muncii tale – el este simțitor afectat. Ca să pun accent pe jumătatea plină a paharului voi spune că începi să devii mult mai eficient în orice faci, inclusiv în munca pe care o depui. Ştiu, sună puțin ciudat să spui că eficientizezi timpul cu cei dragi, dar anumite lucruri cer puțin sacrificiu. Începutul este mai greu, o dată ce ai intrat în ritm simți că totul e nor-mal; când ai câteva săptămâni de pauza ai impresia că ceva nu e in regula.

Cum ești admis?Să zicem că ai trecut de partea cea mai

grea: luarea deciziei de a incepe un MBA. Trebuie să mai treci un pas ca să intri în joc: admiterea. Pentru asta trebuie să iți faci un dosar care cuprinde date despre tine, CV, scrisoare de intenție, scrisori de reco-mandare. Trebuie să treci apoi de un test de tip GMAT. Recomandarea mea este să îl iei în serios, chiar dacă pare destul de ușor la prima vedere. Trebuie să te obișnuiești cu tipul intrebărilor și cu limita de timp în care îl vei da. Eu mi-am luat liber o săptă-mână ca să nu am surprize. L-aș asemăna cu examenul de conducere: nu e greu, dar trebuie sa inveți pentru el.

Cum se desfășoară, ce materii cuprinde, ce profesori ai?

Cursurile sunt în așa fel organizate încât să le poată urma o persoană care lucrează. Exista mai multe combinații: fie în timpul săptămânii după ora 17-18 și în weekend, fie câteva zile consecutiv pe lună. Se primesc niște materiale (suportul de curs, articole, cărți, acces la anumite aplicații) în prealabil, iar la inceput de curs se explică curricula, obiectivele, modul de notare, colaborarea viitoare cu profesorul. Trebuie să subliniez faptul că orice forma de copiat, plagiat sau furt intelectual atrage dupa sine excludrea din cadrul programu-lui. Oricum, se presupune că dacă ai ajuns într-un asemenea cadru, scopul tău este să înveți ceva cu care să rămâi și nicidecum să obții o hârtie pe care să o poți pune în CV.

Materiile sunt axate pe management, finanțe, marketing și resurse umane. La început se pun bazele: general manage-ment, economie, elemente de statistică, dupa care se intră în lucruri mai complexe legate de finanțe, marketing, business internațional. Programul se încheie cu o simulare de business și un proiect de grup. În cadrul lor îți folosești toate cunoștințele acumulate până în acel moment. Un aspect care mi se pare foarte benefic este acela că se pune accent pe munca în grup, nota finală bazandu-se între 40% si 80% pe efortul comun. Profesorii sunt fie români cu experiență în businessul autohton, fie profesori de la facultăți din străinătate. Întrebat fiind care sunt mai buni aș putea spune că romanii excelează la partea teh-nică, în schimb străinii se diferențiază prin stilul de predare, experiența managerială acumulată și transmisă de-a lungul anilor. Cu riscul de a supăra anumite persoane din țară voi spune că ne aflam într-o fază de pionierat în management, 50 de ani de comunism și-au pus amprenta într-un mod semnificativ. Este totuși îmbucurător faptul că tot mai multe persoane vin din exterior unde au văzut cum merg lucrurile sau că tot mai mulți fac un MBA sau lucrează într-o multinațională.

Firmele caută persoane cu MBA? Care este trendul la noi în țară?

Momentan încă nu se pune accent prea mare pe un MBA, însă recruterii sunt atenți la acest aspect, te poziționează mai bine în cadrul filtrării pe care o fac. Trendul este mai clar în București, unde fiind mai multe multinaționale se caută tot mai mult un MBA in CV. La nivelul întregii țări există peste 4200 de absolventi, la finele lui 2011 înscriindu-se 300 de studenîi. În SUA este

aproape obligatoriu sa ai un MBA dacă vrei să ajungi pe o poziție de management. Avansăm și noi, cu puțină răbdare ne apro-piem de acel punct.

MBA in criza economica actualaCriza economică a afectat piața de

MBA estimată la 4.5 milioane euro pe an. Studenții au început să își plătească mai mult din buzunarul propriu studiile, o marjă tot mai mică fiind suportată de com-paniile angajatoare. Din punct de vedere al necesității unui MBA aș spune că acum se justifică mai mult, pentru a putea face diferența fată de concurența în deciziile de business luate.

Experiența personalăCăutam de mai mult timp momentul

potrivit să încep un MBA, dar ca în orice decizie luată trebuie să vină și ziua în care spui: ACUM! Inițial nu eram convins dacă voi putea să îl fac de la Cluj, MBA-ul fiind la București. Am avut sprijin din partea fir-mei și am agreat să vedem cum mă descurc în primele 3 luni. Prima lună a fost mai difi-cilă până am început să mă obișnuiesc cu ritmul, cu Bucureștiul, oamenii, drumurile de două ori pe săptămână, munca de la ser-vici. După doua luni am simțit că situația este sub control și că voi reuși. Totul era calculat cu o lună înainte, îmi știam dru-murile care trebuiau plătite, zilele în care voi dormi în deplasare. Casa mea a deve-nit o simplă cameră de hotel. Ritmul alert a început să mă prindă: azi eram în Cluj, mâine la București, poimâine în delegație. Aproape că pot să spun ca îmi lipsesc zilele acelea. Mi-am făcut prieteni noi, am avut numeroase experiențe. Colegii de la MBA devin persoane din networking-ul tău, unele pe care te poți baza cu adevărat. Am cunoscut oameni extrem de interesanți, din domenii foarte diverse. Cu o parte dintre ei am inceput colaborări.

Mă simt extrem de câștigat după această experiență și voi incheia prin a spune ca a fost cea mai buna decizie pe care am luat-o. M-a schimbat profund, văd lucrurile din mai multe perspective, iar poziția pe care lucrez acum se datoreaza în mare parte stu-diilor pe care le-am acumulat. Recomand cu cea mai mare căldură urmarea unui MBA, îți aduce satisfacții imediate și te dez-voltă ca manager, dar și ca persoană.

Page 40: Today Software Magazine N3/2012

40 nr. 3/2012 | www.todaysoftmag.ro

startups

sunt:S3ntinel, Hack Me If you Can, Hack a

Server, DefCamp.Ce crede despre el? Antrepenor în serie,

îndrăgostit de inteligenţă artificială (vă rog nu-i spuneţi soţiei mele iubite). Un perfec-ţionist perseverent, mereu în căutare de provocări care vor schimba lumea în care trăim. Cred în oameni și echipe adevărate și urăsc că nu reușesc să-mi fac timp pentru a începe blogul personal.

Ce te-a determinat să schimbi direcţia către industria de software?

În afara marilor oportunităţi, sunt genul de om căruia-i plac provocările și fac ce-mi place. Îmi place online-ul și cred că el este viitorul.

Hacking Servers

Ce este Hack a Server?HaS (Hack a Server) este o platformă de

identificare a breșelor și vulnerabilităţilor din aplicaţiile software, bazată pe ceea ce

americanii numesc „Crowd Source”, totul acoperit de anonimitate si confidenţialitate.

Există oameni și comunităţi întregi care iubesc să testeze și să descopere vulne-rabilităţi în aplicaţiile software. Fie ca li se spune black, grey, white hackers, crackers, skiddies sau testeri de penetrare, ei iubesc să găsească breșe și vulnerabilităţi. Fiecare breșă, fiecare vulnerabilitate, pentru ei reprezintă o provocare. Ăsta-i adevărul.

Când sistemul sau serverul de produc-ţie va fi penetrat/compromis în viaţa reală, vă asigur că nu va fi făcut cu intenţii bune în aproape toate cazurile. Credeţi-mă, am fost în situaţia asta cănd platforma noastră a fost „testată” și testată. Mulţumesc Celui de sus că nu ţinem absolut niciun fel de date sensibile pe platformă.

Așa că am avut această idee să con-struim o platforma unde să-i aducem pe cât mai mulţi dintre ei și să fie plătiţi pen-tru ceea ce iubesc cel mai mult să facă: Hacking.

Ca ei să poată avea acces în zona de testare (pe bani reali), „Playground Arena”, întâi trebuie să treacă un test de penetrare. Cu toţii știm că atunci când un sistem este

“Dacă vrei să nu muncești toată viaţa, fă ceea ce iubești cel mai mult” – Confucius . Aceste cuvinte îl descriu cel mai bine pe Marius Corîci. În 2003 a început o afacere în offline înfiinţând compania ITS Group ca și franciză pentru Romstal, cel mai mare retai-ler pentru instalaţii termo-hidro-sanitare din Sud-Est-ul Europei, iar în 2007 a trecut la inteligenţă artificială și a înfiinţat Intelligentics, un grup de de specialiști pentru procesa-rea limbajului natural (NLP – Natural Language Processing).

Cele mai importante proiecte legate de securitate la care lucrează sau este implicat

Marius Corî[email protected]

Antrepenor în serie, îndragostit de inteligenta artificiala

Startup - Hack a server

Page 41: Today Software Magazine N3/2012

41www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

supus testelor de penetrare, cel mai mult, cel mai important lucru, nu-l reprezintă penetrarea în sine ci raportul în care tes-terul explică ce și cum a făcut, precum și soluţiile de acoperire a breșei/vulnerabilită-ţii respective. Raportul de penetrare este cel mai important lucru pentru un CTO, admi-nistrator de sistem, dezvoltator de aplicaţii web iar noi ne focusăm pe reportare.

Testul pe care userii noștri trebuie să-l treacă pentru a avea access (pe bani reali) pentru testarea serverelor din HaS, este la fel ca orice test pe care cineva trebuie să-l dea pentru a obţine diferite certificate de specialist în securitate cum ar fi certifi-catele CPTC, OSPC, CEH, CEPT, CISSP etc. Diferenţa constă în faptul că noi dăm această oportunitate oricui dorește și mai mult, la noi este gratis comparativ cu restul. Prin această testare, vrem să ne asigurăm că CTO, administratorii de sistem sau develo-perii de aplicaţii web, vor primi un Raport de Penetrare care să îndeplinească standar-dele în domeniu.

Cum ţi-a venit ideea pentru Hack a Server?

Mereu spun: rezolvă o problemă, după care construiește un produs. Au fost două ingrediente care combinate m-au adus aici:

Jocurile online: Urăsc jocurile pentru că pot crea dependenţă precum drogurile dacă nu ești ponderat.

Securitatea: Securitatea chiar este o problemă foarte mare, și din ce în ce și mai mare în condiţiile în care trendul este crescător pentru industria online (toate afa-cerile din offline se vor muta și în online).

Așa că într-o zi, fiind cu fica cea mică la doctor și așteptând să intrăm, mă gândeam la „cum aș putea folosi jocul online astfel încât să rezolv o problemă?” Şi atunci m-a trăznit. Da, „trăznit”. Un joc de securitate online, dar altfel decât până la această ora. Folosind „Crowd Sourcing”, și nu puncte ci bani reali. După ce mi-am făcut (acolo pe loc) o idee generală, am sunat un prie-ten care este administrator de sistem, l-am întrebat dacă ar folosi o astfel de platformă și cât ar plăti. Mi-a răspuns că ar folosi și ar plăti în jur la 1000 euro pentru un astfel de serviciu.

Așa a luat naștere HaS. Mai mult, rezolvăm și alte probleme complementare precum „black hackers” pot începe să-și folosească abilităţile în scopuri bune, de ajutorare/consultanţă câștigand bani cin-stit. Mai mult, HaS umple un gol dintre companiile de testare manuală unde preţu-rile pentru astfel de servicii sunt prohibitive pentru companiile cu venituri medii si

medii spre mari (astfel de teste costă de la zeci de mii de dolari în sus). Dacă o tes-tare la o companie specializată costa de la zeci de mii de dolari, probabil, la noi se va încadra undeva la 1000 -2000 de euro (mult mai mic decat salariul brut al unui specia-list în securitate IT). Totul depinde de câte vulnerabilităţi se găsesc pe modulul testat fie că este vorba de un server complet, bază de date, sau aplicaţie web. Deci nu concu-răm cu acest gen de companii de testare manuală ci le completăm.

Construind produsul

Cine lucrează la platforma HaS pentru a o transforma în realitate?

Ştii vorba aia? Viziunea fără execu-ţie, se numește halucinaţie. Am încercat mulţi, am rămas câţiva. Dincolo de viziune, dacă nu aș fi avut echipa, aș fi halucinat în continuare.

Marius Chiş. El este omul cu finanţele și mai mult, primul investitor în platformă. Pe lângă noi doi, am încercat mereu să aduc oameni care întăi să iubească proiectul pentru că sunt genul de om care crede că, „banii reprezintă o consecinţă a unui lucru bine făcut și nu un scop în sine”.

Walle. Cunoscut ca și Andrei Nistor (îmi place să-i zic Walle – cred că urăște nick-ul ăsta), este CTO-ul. Este cel care a făcut cea mai mare parte a proiectului (par-tea de codare), câteodată ajutat și de alţi prieteni ai lui iar de mine din când în când masându-i spatele.

Alexandru Constantinescu. Este omul care m-a impresionat cu determinarea lui. Mi-a trimis un email spunându-mi cât de mult iubește proiectul și că vrea să fie parte din el pe partea de marketing și PR. Am fost mai mult decât bucuros să întâl-nesc oameni care să lucreze „împinși” de proiect/idee care să facă doar ce le place să facă. Mi-a zis că nu este interesat de bani în faza asta, știind ce înseamnă un startup bazat pe bootstrap si leanstartup.

Cosmin Strîmbu. Ultimul dar chiar deloc ultimul, un tip pe care nu l-am întâl-nit încă faţă în faţă nici măcar pe webcam până la ora asta când avem acest interviu. La fel ca și Alexandru, mi-a zis că vrea să fie parte din proiect. Mi-a trimis email că vrea să facă parte din proiect fără să fie plă-tit. I-a plăcut ideea, potenţialul după care echipa. E ciudat nu să nu îl întâlnești dar să facă parte din echipa de bază. Este fron-tend developerul nostru, veriga lipsă care o aveam înainte de apariţia lui. Walle (Andrei Nistor) urăște să scrie frontend. Iubesc

acest gen de oameni conduși de pasiunea pentru ceea ce fac și nu de bani în sine.

Lângă echipă, Andrei Avădănei fonda-torul DefCamp și Ionuţ Gabriel Popescu administrator al celui mai renumit site de hacking în limba română, RST Center, au avut o contribuţie semnificativă. Ei m-au ajutat la fel, din dragoste pentru proiect. Fără ei nu aș fi reușit să strâng o comuni-tate în jurul platformei atât de repede. La ora asta, sunt peste 260 de useri înregistraţi.

Sunt norocos? Da și nu.Norocos pentru ca Ei m-au găsit pe

mine (nu invers) și Ei au găsit și îndrăgit proiectul. Nu, pentru ca am muncit mult să mă fac cunoscut atât eu ca persoană cât și proiectul. Ăsta nu-i noroc, asta-i muncă, muncă grea. În cei peste trei ani petrecuţi până acum în industria online, am întâlnit extrem de mulţi oameni, în schimb doar pe căţiva i-aș recomanda.

Care este modelul de monetizare?Aici putem avea mai multe abordări dar

cel mai simplu, fiind un „market place” o să luăm un procent decent din partea testeri-lor. Companiile plătesc pentru servicii către testeri, iar noi o să luăm o parte din ceea ce plătesc. Preţurile care vrem să le promo-văm vor fi unele care să ducă la o adopţie în masă, adică căt de mici se pot, comparativ cu ce există acum din partea companiilor specializate pe teste de penetrare.

Cine sunt clienţii?Clienţii platformei sunt companii care

vor să-și rezolve problemele de securi-tate informaţională într-un timp scurt și la costuri mici, rezonabile. Companii de software, companii de out sourcing dar și din offline. Spre exemplu, amicul pe care l-am întrebat dacă ar folosi un astfel de ser-viciu, este administrator de sistem la trei mari companii din offline. Cei care decid dacă platforma le este folositoare, sunt oamenii care deţin funcţii sau lucrează ca și CTO, CIO, CISO, administratorii de sistem, administratorii de baze de date, dezvoltatori de aplicaţii web.

Alţi clienţi la care ne așteptăm, sunt specialiștii și cercetătorii din domeniul InfoSecurităţii care vor să-și testeze siste-mele dezvoltate de ei.

Ce facilităţi oferă platforma?HaS este următorul nivel prin care

companiile își rezolvă problemele critice de securitate întrun mod novativ și distractiv bazat pe war game.

Costuri reduse: Ce poate fi mai atrac-tiv pentru o afacere decât puterea a mii de

Page 42: Today Software Magazine N3/2012

42 nr. 3/2012 | www.todaysoftmag.ro

angajaţi la un cost foarte rezonabil?Rapiditate: În câteva minute poţi face

deploy la un server cu cele mai populare sisteme de operare open source. Dacă vrei să folosești un sistem de operare care nu este prins la noi, poţi pune ce sistem vrei pentru că soluţia de virtualizare permite. Cred că sunt 7 click-uri și poţi avea serve-rul „up and running”

Sigură: Testerii noștrii (hackeri, testeri) trebuie să treacă un examen care include și completarea unui Raport de Penetrare pen-tru a putea să folosească platforma.

Securizată: HaS încurajează userii să folosească elemente (emailuri, nickname-uri) care să nu ducă la identificarea lor reală. Inclusiv noi, cei din spatele plat-formei, nu vrem să știm dacă x, y, sau z companie folosește platforma. Asta asigură un grad ridicat de securitate.

Ce features noi pregătiţi?Sunt o groază de feature-uri pe care

vrem să le implementăm. Avem un top 3 features care vrem să le implementăm, dar cel mai bine pentru noi, este să primim propunerile de la utilizatorii care plătesc

pentru acest serviciu. Ei trebuie să decidă ce alte opţiuni doresc implementate. Dacă stau să mă gândesc avem o opţiune care vă ajută pe CTO, administratorii de sistem sau dezvoltatorii de aplicaţii web: Să găsim o cale prin care într-un timp foarte scurt să reușim replicarea/clonarea unei mașini fizice pe platforma noastră fără datele sen-sibile. No, asta da, provocare și cred că o sa o punem pe următoarea iteraţie.

Cum v-aţi propus să penetraţi piaţa?De când am dat drumul la versiunea

Alpha, am iniţiat o serie de evenimente Get Together în diferite orașe ale ţării unde strângem hackeri etici, CTO, administratori de sistem etc și le povestim despre produs într-un cadru relaxat. Mâncarea, băutura și distracţia din partea casei. Facem inclu-siv sesiuni de simulare. Administratorii construiesc sistemele iar hackeri încearcă să le penetreze. Mai mult, avem și premii. Trebuie să fie distractiv, nu? Până acum ast-fel de evenimente am avut la București și la Iași, iar următorul va fi la Cluj-Napoca în 8 iunie la sediul ISDC. Niște oameni minu-naţi. Când le-am spus de eveniment ce și

cum vrem să-l facem, au sărit ca și când erau parte din proiect. Nu mă pot abţine: Iubesc astfel de oameni. Adriana Dunca, specialist marketing și PR la ISDC e minu-nată. Mai multe despre evenimentul Get Together găsiţi pe blogul HaS.

HaS va deveni platforma oficială pentru DefCamp, o conferinţă la nivel de expert pe teme de InfoSecuritate care se va ţine în Cluj-Napoca în 6-8 septembrie la Hotel Napoca.

Partea de virtualizare am facut-o open source astfel încât dacă cineva dorește să-și facă o platforma de testare manuală, să o facă repede și fără costuri. Nu am lansat ofi-cial încă pentru că ne trebuie strategia de răspândire și timpul necesar. Nu vreau doar să o punem sus și gata, Dumnezeu cu mila.

Modulul de virtualizare intenţionăm să-l implementam în facultăţi, astfel încât studenţii care studiază securitatea informa-ţională să o facă într-un mod distractiv.

Acestea sunt câteva direcţii care fac parte din strategia noastră de marketing.

startups programareStartup - Hack a server

Page 43: Today Software Magazine N3/2012

43www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

Zoltán, Pap-Dá[email protected]

Software Engineer @ Macadamian

Think iCloud

Pentru a putea lucra cu iCloud, avem nevoie în primul rând de un App ID con-figurat pentru iCloud. În Xcode, pentru proiect, trebuie să fie activat entitlements, și de asemenea, iCloud trebuie să fie con-figurat pe dispozitivul destinație pentru că applicațiile iCloud nu pot fi testate pe simulator. Pașii detaliați de configurare, nu fac obiectivul acestui articol, detaliile pot fi găsite pe https://developer.apple.com.

Dacă totul este configurat corect, aplicaţia, pe lângă sandbox, poate accesa un director special iCloud pe dispozitiv. Fișierele puse în acest director sunt sin-cronizate automat de iCloud daemon. Conținutul acestui director special se poate acesa la fel ca și orice alt director din sandbox, dar dacă vrem să lucrăm direct cu aceste fișiere, trebuie să ținem cont de faptul că sunt folosite și de iCloud daemon.

Trecerea la iCloudPentru a face obiectele persistente în

iCloud, am putea serializa manual datele

în fișierele din directorul iCloud local prin utilizarea noilor metode NSFileManager sau NSFilePresenter respectiv clasa NSFileCoordinator. După acest moment, sincronizarea se face într-un mod auto-mat. Totuși, acest procedeu este destul de complex și inutil în cele mai multe cazuri, deoarece iOS5 SDK a introdus noi clase performante. În acest fel putem accesa direct obiecte instanțiate, fără a fi nevoie de a lucra cu structuri/fișiere din spatele acestora.

Din punct de vedere al dezvoltatorului, avem trei metode pentru a stoca datele în cloud:

• Key / Value Store este metoda recomandată când vrem să stocăm o cantitate mică de date dintr-un dicționar. Ca un caz concret de aplicație menționăm stocarea setă-rilor aplicației în cloud.

• (NSUbiquitousKeyValueStore e s t e f o a r t e s i m i l a r c u NSUserDefaults)

• S t o c a r e a o b i e c t e -lor în iCloud (UIDocument)• Baze de date î n c l o u d . S e configurarează CoreData pentru a stoca datele în cloud

Apple pune l a d i s p o z i ț i e structuri sim-ple și robuste de lucrul cu date din iCloud.

iCloud este un set de interfeţe și servicii oferite de Apple, pentru schimbul de date între mai multe instanţe ale aplicaţiei care rulează pe dispozitive diferite, într-un mod ușor de utilizat și sigur. Pe lângă faptul că reprezintă o soluție flexibilă pentru un număr mare de probleme, SDK –ul permite un acces simplu și robust din punct de vedere al dezvoltării.

programare

Page 44: Today Software Magazine N3/2012

44 nr. 3/2012 | www.todaysoftmag.ro

Stocarea datelor tip Cheie/ValoareÎ n c a z u l î n c a r e v r e m s ă

stocăm o cantitate mică de date repre-zentate printr-un dicționar putem folosi NSUbiquitousKeyValueStore introdus în iOS5 SDK. Datele pot fi sincronizate deoarece sunt încapsulate în NSString, NSDate, NSNumber, NSData, NSArray sau în NSDictionary. Singura restricție este în ceea ce privește dimensiunea datelor stocate. Pentru fiecare cheie, datele stocate pot avea max 64KB și putem avea până la 256 de intrări, iar combinate, nu trebuie să depășească 64KB în total.

De asemenea avem posibilitatea să pri-mim notificări când datele sunt modificate.

Stocarea obiectelor

Model Controller. Utilizarea documente-lor În iOS5 SDK avem la dispoziție clasa UIDocument, pentru a stoca un obiect în iCloud. UIDocument este, practic, un mo-del de controller (MVC pattern), imple-mentează NSFilePresenter și se sincroni-zează automat de iCloud daemon. Clasele ale căror instanțe vrem să le stocăm în iCloud, trebuie să aiba ca și clasă de bază UIDocument. În continuare, voi numi aceste obiecte, documente. Tot ceea ce trebuie să definim, este modul de seriali-zare/deserializare a datelor, implementând următoarele două metode:

- (BOOL)loadFromContents:(id)con-tents ofType:(NSString *)typeName error:(NSError **)outError- (id)contentsForType:(NSString *)typeName error:(NSError **)outError

Prima metoda primește NSData sau NSFileWrapper (în acest fel se pot citi date dintr-un singur fișier sau din mai multe) și conține deserializarea în modelul intern. A doua metodă conţine deseriali-zarea și trebuie să returneze NSData sau NSFileWrapper. Dacă implementăm NSCoding, implementarea acestor metode este trivială.

Transferarea documentelor din iCloud.Iniţial, directorul iCloud local de pe

device nu conţine documentele pe care vrem să le accesăm. Primul pas care trebuie făcut este obținerea unei referințe către directorul iCloud local.NSURL * storage = [[NSFileMan-ager defaultManager] URLForUbiquityContainerIdentifier:nil];

Dacă valoarea returnată nu este nil, totul este configurat corect și putem să scriem query-uri pentru datele pe care vrem să accesam.

NSMetadataQuery * query = [[NS-MetadataQuery alloc] init];[query setSearchScopes: [NSArray arrayWithObject: NSMetadataQuery-UbiquitousDocumentsScope]]; NSPredicate *pred = [NSPredicate predicateWithFormat: @”%K like ‚EventInfo_*’”, NSMetadataItemFS-NameKey];[query setPredicate:pred];[[NSNotificationCenter default-Center] addObserver:selfselector:@selector(queryDidFinishGathering:)name:NSMetadataQueryDidFinishGatheringNotificationobject:query];[query startQuery];

Tot ceea ce trebuie să facem este să scriem un query, prin specificarea unui pre-dicat pentru filtrarea storage-ului iCloud, și să executăm query-ul. Documentele sunt transferate în directorul iCloud local, și pentru fiecare este inițializat un obiect model. Odată ce obiectele modelului sunt încărcate în memorie, se trimite o notificare. Deoarece totul se desfășoară în fundal, încărcarea documentelor nu blo-chează aplicația. De asemenea putem primi notificări dacă sunt detectate schimbări asupra documentului.

Crearea unui document nouLa crearea unei noi instanțe a unei clase

derivate din UIDocument, trebuie să spe-cificăm la inițializare un URL care indică o locație din directorul local iCloud. La salvarea documentului, datele vor fi trans-ferate în acest fișier.NSURL *ubiquitousPackage = [[self.ubiq URLByAppendingPathComponent:@”Documents”] URLByAppendingPathComponent:fileName]; UserInfo *doc = [[UserInfo alloc] initWithFileURL:ubiquitousPackage];EntityInfo * newEntity = [initWithFileURL:ubiquitousPackage];

[doc saveToURL:[doc fileURL] forSaveOperation:UIDocumentSaveForCreating completionHandler:^(BOOL success) { }];

Stocarea documentelor în iCloud implică faptul că mai multe instanţe ale aplicației pot accesa și modifica același document. Atunci când mai multe instanţe efectuează modificări diferite pe același document, pot apărea inevitabil, conflicte.

Cea mai simplă metodă de a rezolva aceste conflicte, este de a suprascrie instanța pre-cedentă cu instanța din ultima salvare. De asemenea, se pot defini scenarii de rezol-vare ale conflictelor. Pentru a inspecta starea documentului, UIDocument con-ţine o proprietate documentState (există, de asemenea, o notificare pentru cazul în care starea documentului se schimbă - UIDocumentStateChangedNotification).

CoreData și iCloudUn scenariu mai complex este nece-

sitatea de a stoca o bază de date sqlite, în iCloud.

În iOS5, CoreData aduce îmbunătă-ţiri pentru a sprijini integrarea eficientă a bazelor de date SQLite cu iCloud. În locul stocării bazei de date fizice în cloud, doar log-urile de tranzacții discrete (dis-crete transaction log files) sunt stocate în cloud. În acest fel nu este necesar transferul fișierului sqlite la fiecare tranzacție, ajunge doar transferul log-ului de tranzacție. La sincronizare, tranzacțiile sunt executate pe baza de date locală, aceste schimbări putând fi detectate de CoreData. Când vrem să folosim o bază de date sqlite în iCloud, trebuie să avem în vedere urmă-toarele aspecte:

• CoreData trebuie inițializat prin specificarea locației log-urilor tranzacționale (acesta trebuie să fie în directorul iCloud local). Pentru aceasta trebuie specificate la inițializare, valori pentru cheile:

NSPersistentStoreUbiqui

tousContentNameKey și NSPer sistentStoreUbiquitousCon

tentURLKey. Astfel CoreData va ști unde să stocheze aceste loguri pentru tranzacții

• Dacă vrem să ștergem baza de date din cloud, trebuie să ștergem numai logurile.

• Fișierul sqlite trebuie stocat în așa fel încât modificările la el să nu fie sincronizate cu cloud-ul (fie în sandbox-ul aplicației fie în direc-torul iCloud local, într-un director cu terminația: . nosync )

Prin introducerea suportului pentru iCloud în iOS5, Apple deschide noi orizon-turi pentru dezvoltatorii aplicațiilor mobile iOS. De asemenea, iOS SDK este extins astfel încât timpul de trecere la această tehnologie să fie cât mai mic, iar lucrul cu iCloud să se facă într-un mod cât mai transparent.

programare diverseThink iCloud

Page 45: Today Software Magazine N3/2012

45www.todaysoftmag.ro | nr. 3/2012

TODAY SOFTWARE MAGAZINE

Simona Bonghez, [email protected]

Speaker, trainer și consultant în managementul proiectelor, partener al TSP(smartprojects.ro)

“Cred cu tărie în puterea jocului și a metaforei și îmi place la nebunie ca sesiunile mele de training să fie distractive și interactive, în așa fel încât participanţii să acumuleze informaţiile într-o manieră cât mai plăcută…”

Gogu

înțeles și aplicat. Cum ar spune Gogu...„aproape de bun simț”.

Vă invităm să-l urmăriți pe Gogu și să-i trimiteți sugestiile voastre.

Capul lui Gogu abia se mai iţea din marea de CV-uri în care era scufundat pro-prietarul lui; dacă nu l-ai fi auzit pufnind din când în când, nici n-ai fi zis că e acolo.

- Probleme, Gogule?! Ai irosit vreo trei copaci printând toate CV-urile astea, nu era mai simplu să le vizualizezi pe computer?

Ei, lasă Mișule, că te prind eu la prin-ter, să-ţi dau numa’ copaci! gândi Gogu, dar se abţinu să comenteze, să nu-i dea apă la moară. Rămase impasibil și se adânci și mai mult în studiul hărtiilor. Mișu dădu să mai zică ceva, n-ar fi rezistat tentaţiei de a mai învârti puţin cuţitul în rană, dar se opri când îl văzu intrând pe Şefu’:

- Gata, Gogule? Mi-a zis HR-u’ că ţi-a dat CV-urile selectate, tu doar să alegi pro-ject managerii pentru interviu. Câţi avem?

Ei, lasă că îl prind eu și pe HR-u’ ăsta... Ce-o fi azi, că numa’ de șmecheri am parte?! Ii răspunse însă Şefului:

- Mai lasă-mă puţin, mi-au trimis 32 de CV-uri, încerc să reduc interviurile la maxim 10, e ok?

- Dă-i bătaie, mai bine așa decât data trecută când n-am primit nici un CV. E bine că ai mai tăiat din criterii, numai să nu dăm acum în extrema cealaltă și să ne trezim cu unii fără studii, fără experienţă. Da’ nu-mi fac griji, știu că verifici temeinic. Treci pe la mine când ești gata.

Sigur că da, „verifici temeinic” îl îngână Gogu pe Şefu’. Mai citi o dată fraza la care rămasese în CV-ul din faţa lui: „Experienţă considerabilă în proiecte de anvergură, cu rezultate excelente”. Nici că putea fi cineva mai vag de atât – își spuse – câţi ani înseamnă „considerabilă”, ce buget are un proiect „de anvergură” și pe ce bază sunt numite rezultatele „excelente”?! „Training intensiv în managementul proiectelor” – citi el mai departe. Mda, dacă făcea doi bani trainingul ăsta intensiv al tău, dădeai niște detalii clare, nu mă abureai cu „anvergură” și „considerabil”.

- Auzi, Mișule, ăștia toţi zic, care mai de care, că au experienţă și cunoștinţe. Cum pot eu să „verific temeinic” chestia asta? Că nici să-i chem pe toţi la interviu nu pot... Deși ar merita, numai să văd faţa lui Şefu’..

Privirea îi căzu pe: „Certificare PMP obţinută în 2010”.

- PMP-ul ăsta e certificarea aia internaţională de la PMI, nu-i așa?

Realiză subit că îl întrerupse pe Mișu. - Păi eu ce-ţi spuneam frate, iar

întrebi și nu ești atent la răspuns! Că mă și enervezi... Da, măi, e exact certificarea aceea de nu vrei tu să ţi-o iei, mare noroc ai cu Şefu’ ăsta al nostru.

- Mă lași?! O fi la modă să ai o certificare în domeniu, dar asta nu e deloc o garanție a competențelor de manager de proiect. Un examen grilă nu poate fi concludent pentru competentele mele. Un manager de proiect trebuie să știe să aplice cunoștințele teoretice acumulate, să coordoneze echipa, să gestioneze situațiile neprevăzute care apar pe parcursul proiectului... unde intră aspectele astea în examenul pentru certifi-care? Cine le verifică?

- Ești cârcotaș ca de obicei. Ţii minte că ne-a zis Şefu’ că sunt niște condiţii pen-tru eligibilitate, un anumit număr de ore de instruire plus experiență în conducerea proiectelor. Asta nu inseamna, de fapt, ca ai dobândit și niște competențe?

- Ntz! N-aș crede... Rotiţele începură însă să se învârtă: Stai

așa, că n-or fi competenţe, dar măcar cineva a verificat că există cunoștinţe și experienţă. Te pomenești că m-am scos... Luă la mână iar toate CV-urile, le puse la o parte pe cele cu certificare internaţională. Le numără. Erau cinci. Ceea ce înseamnă cinci inter-viuri. Iar la interviu, verifici competenţele, mă rog, atât cât e posibil, iar Şefu’ se pricepe să-i învârtă pe candidaţi la interviu. Mai adaugă încă trei CV-uri care ofereau detalii concrete despre proiecte realizate și experi-enţă acumulată și se declară satisfăcut. Erau opt candidaţi pentru opt interviuri. Si-apoi vedem noi dacă iese ceva. Hai că e bun și PMP-ul ăsta la ceva!

Faceți cunoștință cu Gogu! Gogu este un personaj amuzant, cinic pe alocuri, un introvertit pentru care monolo-

gul interior reprezintă o alternativă la viața reală. Cu ajutorul lui Gogu, analizăm diferite ipostaze din viața managerului de proiect și a echipei sale și sugerăm soluții ușor de

diverse

Page 46: Today Software Magazine N3/2012
Page 47: Today Software Magazine N3/2012

powered by

sponsori