TSM_11_2013_1ro by Today Software Magazine

Nr. 11 • Mai 2013 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM are w t f o S

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

hip s n a sm t f a r C

narii e c S i de

loud rdur C a C n î rea are w t f o Testa s tului c e t i a arh i r ă t Bucă

Programare Funcțională în Haskell Trenduri și Big Data Arhitectura extransibila și durabilă Să uităm de modelul Silicon Valley OPTIONSABILITY - O caracteristică discretă a proiectelor IT (un) prieten pentru startup-uri Istoria IT-ului Clujean (V) - Învățături din Junimea SPRE COMUNITATEA IT – via HR

ITCamp 2013 Orchestrarea Testarii Automate Recenzia cărții: RESTful Web Services Cookbook JAVA EE7. Cloud, Web 2.0+ Dezvoltarea de aplicații safety-critical în SCADE Managementul performanței Roller Coaster-ul Imagine Cup Gogu și plinul de benzină

6 Să uităm de modelul Silicon Valley Bogdan Iordache

7 ITCamp 2013 Mihai Tătăran

8 (un) prieten pentru startup-uri Cosmin Mihaiu

10 JAVA EE7. Cloud, Web 2.0+ Silviu Dumitrescu

11 Istoria IT-ului Clujean (V) - Învățături din Junimea Marius Mornea

13 Software Craftsmanship Alexandru Bolboacă și Adrian Bolboacă

16 Din bucătăria arhitectului software - carduri de scenarii

28 OPTIONSABILITY - O caracteristică discretă a proiectelor IT Bogdan Matei

31 Dezvoltarea de aplicații safety-critical în SCADE Hunor Csomortani

34 Trenduri și Big Data Radu Vunvulea

39 Programare Funcțională în Haskell Mihai Maruseac

40 Recenzia cărții: RESTful Web Services Cookbook de Subbu Allamaraju Silviu Dumitrescu

42 SPRE COMUNITATEA IT – via HR Dan Ionescu și Cristina Nicule

45 Managementul performanței

Attila Antal

Andreea Pârvu

19 Arhitectura extransibilă și durabilă

47 Poate da ... poate nu ...

Levente Veres

Antonia Onaca

22 Testarea în Cloud Vlad Zeciu

24 Orchestrarea Testării Automate Lucian Revnic

48 Roller Coaster-ul Imagine Cup Alex Pana

50 Gogu și plinul de benzină Simona Bonghez, Ph.D.

editorial

Ovidiu Măţan, PMP

ovidiu.matan@todaysoftmag.com Fondator și CEO al Today Software Magazine

uzz-ul din ultimele luni este crearea structurilor și a oportunităților pentru dezvoltarea IT-ului și poate mai mult ca oricând apariția unor soluții românești prin stimularea startup-urilor. TSM a fost și rămâne un promotor al acestora dar nu dorim să cădem în extrema cealaltă și să nu vedem pădurea din cauza copacilor. Probabil 90% din zona de IT, exceptând afacerile cu statul român, reprezintă outsourcing realizat pentru companii din exterior. Problema majoră care apare este lipsa IP-ului (intellectual property), respectivele companii putând să își mute centrele de dezvoltare oricând în alt loc. Pe de altă parte, să nu scăpăm din vedere ce au făcut pentru noi companiile de outsourcing și ce pot să facă în continuare. În primul rând ne-au învățat cum se scrie soft comercial, care este nivelul de calitate cerut, 99.999% pentru availability, cum se creează o arhitectură performantă a sistemelor și multe altele. În timp, acestea au fost asimilate de specialiștii români, iar acum noi îi învățăm pe alții. La fel se va întâmpla și cu crearea de produse. Companiile, care până nu demult aveau doar execuția în România, au încredere în noi dorind acum să creăm produsele pentru care ei sunt business owneri. Pe piața de muncă se vede aceasta, iar lipsa de business analiști și de product management nu trece neobservată. Nu sunt mulți, dar vor fi în câțiva ani și vor avea în CV realizări ale unor produse importante. Ei vor ști cum se creează un produs comercial bazat pe business requirements și probabil tot ei vor ajuta lansarea startup-urilor românești. Așadar, pentru a avea la scară largă apariția unor noi startup-uri, este nevoie de o cultură și o experiență la care se poate ajunge doar în timp și cu multă perseverență. Desigur, pot exista excepții, cum am văzut în industria de jocuri sau în cea de divertisment. Incubatoarele de startup-uri și spațiile co-work încep timid să își facă apariția iar noi vom publica începând cu numărul următor o analiză a celor existente. E important ca un nou startup să știe de la început cui să se adreseze pentru finanțare sau suport. Așa cum ne-am așteptat, luna mai este plină de evenimente în zona IT-ului: în 14 Mai vom avea Software architecture workshop organizat de către Arobs și care îl are ca invitat pe Simon Brown; în 16 Mai, tot la Cluj va avea loc a doua ediție a Romanian Testing Community; în 17 Mai .msg systems organizează workshop-ul Java EE 7 susținut de către Silviu Dumitrescu; în 23-24 Mai vom avea ITCamp, cea mai mare conferință pe tehnologii Microsoft din România iar în 30-31 Mai, în București are loc I T.A.K.E. Unconference pentru cei ce doresc să atingă o excelență tehnică. Doresc să menționez și ICT Spring Europe care se va desfășura în 19-20 Iunie, în Luxemburg. Evenimentul va reuni 3,500 de participanți din Europa, iar startup-urile beneficiază de participare gratuită. Acestea vor avea ocazia să își prezinte soluțiile în cadrul evenimentului. Cei care vor doar să participe la eveniment, vor beneficia din partea TSM de o reducere de 50%. Îi rugăm pe cei interesați să ne scrie pe adresa redacției contact@todaysoftmag.com. Numărul 11 TSM vă propune o serie de articole interesante acoperind sfera de interes din acest domeniu. La secțiunea startup-uri articolul Să uităm de modelul Silicon Valley (aka Făt Frumos din Vale și Merele de Siliciu), este o analiză obiectivă a acestui fenomen. În un prieten pentru startup-uri, este vorba de Marius Mocian și suportul acordat de acesta pentru MIRA. Această secțiune este încheiată de căștigătorii din acest an ai Microsoft Imagine Cup care ne povestesc evoluția produsului de la concept la implementarea finală. Software Craftsmanship este un domeniu destul de puțin cunoscut și mă bucur că putem publica un articol pe această temă. Arhitectura software este prezentă prin articolele: Din bucătăria arhitectului software carduri de scenarii și Arhitectura extransibila si durabila (grow form novice to guru). OPTIONSABILITY este un subiect interesant legat de proiectele de IT. Continuăm cu Dezvoltarea de aplicații safety-critical în SCADE și o nouă serie despre Programare Funcțională în Haskell. Primele rezultate ale studiului pentru realizarea unor Best Practice-uri în HR sunt publicate în acest număr în SPRE COMUNITATEA IT – via HR, iar personajul nostru favorit, Gogu este prezent la final în Gogu și plinul de benzină. Vă dorim o lectură plăcută !!!

Ovidiu Măţan

Fondator și CEO al Today Software Magazine

nr. 11/Mai, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Lista autorilor Redacţia Today Software Magazine Fondator / Editor în chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com Editor (startups și interviuri): Marius Mornea marius.mornea@todaysoftmag.com Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com Colaborator social media: Rodica Manolache rodica.manolache@todaysoftmag.com Traducător: Cintia Damian cintia.damian@todaysoftmag.com Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com

Alexandru Bolboaca

Hunor Csomortani

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

Software Developer @ evoline

alex.bolboaca@mozaicworks.com

Bogdan Iordache bogdan.iordache@howtoweb.co este Co-Fondator al How to Web, cel mai important eveniment web din Europa de Est

str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag

IxNovation @ IXIA membru ROSEdu, ARIA

Consultant Java @ .msg systems Romania

Senior Software Engineer @iQuest

Marius Mornea

Adrian Bolboaca

marius.mornea@todaysoftmag.com Fost senior software developer in cadrul Nokia, în prezent fondatorul platformei Mintaka Research

Radu.Vunvulea@iquestgroup.com

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

Dan Ionescu

dan.ionescu@danis.ro

Software Architect @ ISDC

Director Executiv @ Danis Consulting

Cristina Nicule

Mihai Tătăran

mihai@itcamp.ro

cristina.nicule@danis.ro

Microsoft MVP CodeCamp

Consultant @ Danis Consulting

Co-fondator ITCamp

Andreea Pârvu Levente Veres

ISSN 2284 – 6352

mihai.maruseac@gmail.com

Radu Vunvulea

Attila.Antal@isdc.eu

Today Software Solutions SRL

Mihai Maruseac

Silviu Dumitrescu silviu.dumitrescu@msg-systems. com

Attila Antal

Produs de

csmortani.hunor@evoline.ro

Levente.Veres@endava.com

andreea.parvu@endava.com Recruiter în cadrul Endava

Design Lead @ endava

Vlad Zeciu

Alex Pana

Senior QA Engineer @ Small Footprint

internship student @ Tora trading

vzeciu@smallfootprint.com

Simona Bonghez, Ph.D.

simona.bonghez@confucius.ro

Lucian Revnic

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

alex.pana@vertexarmy.org

lucian.revnic@hp.com OO Content Arhitect @ HP Software Cluj

Bogdan Matei

bogdan.matei@3pillarglobal.com Senior Php Developer @ 3Pillar Global

Speaker, trainer şi consultant în managementul proiectelor, Owner al Confucius Consulting

Antonia Onaca

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

www.todaysoftmag.ro | nr. 11/Mai, 2013

startups

Să uităm de modelul Silicon Valley (aka Fat Frumos din Vale și Merele de Siliciu)

cum aproape 60 de ani, William Shockley părăsea Bell Laboratories și deschidea, în 1956, compania Shockley Semiconductor Laboratory în Mountain View, cu convingerea că siliciul, și nu germaniul, este materialul potrivit pentru producerea tranzistoarelor. În 1957, 8 dintre inginerii lui părăseau compania și fondau Fairchild Semiconductor, dintre care doi (Robert Noyce și Gordon Moore) aveau să fondeze ulterior Intel. După aproape 60 de ani, Silicon Valley numără câteva sute de mii de ingineri (dintr-un total de 7 milioane locuitori în Bay Area), sute de firme de investiții și acceleratoare care atrag peste 10 mld USD în investiții anuale (peste 40% din totalul anual al tuturor investițiilor de venture capital din SUA), un sistem educational excepțional ce include Stanford, una dintre cele mai importante 6 universități ale lumii, și aproape toți giganții industriei tech: Intel, Google, Facebook, Apple, Amazon, Qualcomm, Yahoo! etc. Acum aproape o lună, când am ajuns în San Francisco, se desfășura Launch Festival 2013, una dintre ele mai mari conferințe dedicate startupurilor din SF și am făcut un scurt clip.1 România are “un pic” de recuperat. Cu un total de aprox. 80000 ingineri, cu investiții anuale locale ce nu depășesc 10 mil USD (poate chiar mult mai puțin) în 2012, cu un sistem educațional organizat anacronic și ineficient care încă își face treaba datorită unui număr redus de oameni pasionați, cu câteva firme de produs foarte interesante (BitDefender, Avangate etc.) care însă insumează doar 5-10% din exportul total al industriei IT&C (restul fiind outsourcing), nu putem decât să concludem că nu stăm rău ca industrie, dar suntem cu câteva ordine de mărime în urmă. Periodic citesc articole și știri despre cum Bucureștiul, și mai nou Clujul, ba chiar și Măgurele, va deveni un “Silicon Valley de 1 http://www.youtube.com/watch?v=NB1O0bqPa3Q& feature=player_embedded

România”. Păi măi dragilor, dacă ar fi așa simplu, aș face un Silicon Valley și la mine la Turnu Severin. E vreme bună, investitorii pot merge în pauza de masă la ștrandul din Herculane, antreprenorii se pot relaxa pe terasele de la marginea Dunării după o zi de lucru iar pentru programatori avem pește, ieftin și bogat în fosfor. Bănuiesc însă că nimeni nu vorbește serios, ci sunt doar figuri de stil (parabole, hiperbole etc.), o comparație propriu-zisă fiind exclusă. Șansele apariției unui nou Silicon Valley oriunde în lume, inclusiv în SUA, sunt extrem de mici, și cred că ar trebui să învățăm ce avem de învățat și apoi sâ uitâm de modelul Silicon Valley atunci când ne gândim la crearea unui ecosistem tech local. Poate ar trebui să uităm și de modelul New York, unde startupurile tech s-au dezvoltat și datorită industriei locale de advertising. Poate ar trebui să uităm și de modelul Israel, al doilea stat din lume dpdv al numărului de IPO-uri ale companiilor de tehnologie pe bursă din SUA, pentru că industria de tehnologie de acolo a fost creată în primul rând prin finanțarea cercetării în industria de apărare de către stat. Și poate ar trebui să uităm și de modelul Londra, cel mai important centru financiar european, unde industria tehnologiei s-a dezvoltat datorită accesului la mecanismele de finanțare existente. Și aș putea continua cu Boulder, Berlin, Singapore și atâtea alte centre unde tocmai factorii locali, și nu modelele externe, au făcut ca industria să se dezvolte.

nr. 11/Mai, 2013 | www.todaysoftmag.ro

Poate ar trebui să ne uităm cu atenție în oglindă, să ne întrebăm cine suntem și ce putem face cu adevărat perfomant la scara globală a inovației, și să executăm liniștiți vreo 20 de ani, cu mai puține povești despre Făt Frumos din Vale și Merele de Siliciu și cu ochii larg deschiși spre noi. PS: toate gândurile mele bune se îndreaptă spre Comic Con Bucuresti, unde mi-aș fi dorit teribil de mult să fiu.

Bogdan Iordache bogdan.iordache@howtoweb.co este Co-Fondator al How to Web, cel mai important eveniment web din Europa de Est

eveniment

TODAY SOFTWARE MAGAZINE

ITCamp 2013

TCamp este cea mai mare conferință premium pe tehnologii Microsoft organizată în România, care se adresează profesioniștilor implicați în implementări ale tehnologiilor Microsoft și managerilor cu rol decizional, care doresc să fie la curent cu ultimele tehnologii, să-și îmbogățească cunoștințele tehnice și care urmăresc participarea la training-uri cu adevărat eficiente, bazate pe tehnologiile disponibile astăzi. ITCamp este o conferință non-profit, organizată de membri ai comunităților profesionale CodeCamp și ITSpark, având ca și obiective ridicarea nivelului expertizei IT și a cunoștințelor profesioniștilor IT din România, precum și îmbunătățirea imaginii României în afara granițelor noastre. Prima ediție a conferinței ITCamp a avut 21 de sesiuni tehnice și s-a desfășurat pe două track-uri paralele (Dev și ITPro), înregistrând puțin peste 200 de participanți. Conținutul a fost prezentat de speakeri de renume locali și internaționali, printre care Paula Januszkiewicz și Stephen Forte. ITCamp 2012 a făcut trecerea la formatul curent de 3 track-uri (Private & Public Cloud, Development & Mobile și Arhitecture & Best Practices). Cei aproximativ 300 de participanți au asistat la prezentările unor speakeri de renume, cum ar fi Tim Huckaby, Lino Tadros și Martin Kulov. În anii precedenți, majoritatea audienței a fost formată din mid-level și senior developers, precum și team leads și arhitecți.

Ediția din 2013 va continua tradiția, anunțându-se două zile în care dezvoltatorii, profesioniștii IT și arhiecții vor beneficia de 30 de sesiuni tehnice și un open-panel, prezentate de 26 de speakeri locali și internaționali. Între aceștia, patru experți cu titul de Microsoft Regional Director (Richard Campbell, RD si MVP, creatorul unei varietăți de programe multimedia, dintre care amintim .NET Rocks!, RunAs Radio și The Tablet Show; Tim Huckaby, RD și MVP, numit de către presa de specialitate un „pionier al revoluţiei Smart Client”; Martin Kulov, RD și MVP; Ciprian Jichici, RD și MVP), Peter Leeson, CMMI Specialist și 13 alți experți cu titlul Microsoft Most Valuable Professional (MVP), o parte din ei fiind speakeri internaționali (Raffaele Rialdi, Developer Security MVP; Andy Cross, Windows Azure MVP; Tobiasz Koprowski, SQL Server MVP etc.). În zilele premergătoare conferinței ITCamp, se vor organiza o serie de workshop-uri și seminarii, cu durata de o zi sau de două zile. Subiectele

abordate vor fi de nivel avansat, și vor oferi participanților șansa de a pune în practică cele învățate, beneficiind de asistența trainerilor. Taxa de participare la aceste workshop-uri nu este inclusă în prețul conferinței. Imagini, înregistrări video și mai multe detalii despre ITCamp: • http://itcamp.ro/about.cshtml • http://itcamp.ro/past.cshtml (ediții anterioare) • https://www.facebook.com/ITCamp. ro/photos_albums?ref=hl • h t t p s : / / v i m e o. c o m / c h a n n e l s / itcamp2012 (câteva sesiuni din 2012) • h t t p s : / / v i m e o. c o m / c h a n n e l s / itcamp2011 (câteva sesiuni din 2011)

Mihai Tătăran

mihai@itcamp.ro Microsoft MVP CodeCamp Co-fondator ITCamp

www.todaysoftmag.ro | nr. 11/Mai, 2013

startups

un prieten pentru startup-uri

-am cunoscut pe Marius la Cluj-Napoca Business Days în iulie 2012, unde am avut un stand de prezentare a produsului nostru MIRA (www.mirarehab.com). După ce i-am explicat ce face MIRA, Marius a început să cheme lumea la standul nostru și să discute cu noi aspecte business despre produs, spre deosebire de întrebările medicale sau tehnice care eram obișnuiți să răspundem. Am observat imediat interesul lui față de ceea ce dezvoltam, încrederea lui în potențialul pe care MIRA poate să-l aducă kinetoterapiei și a remarcat că aveam nevoie de ajutor în strategia noastră de business pentru a atrage investitori și a transforma MIRA într-o afacere. După Cluj-Napoca Business Days, Marius a ținut legătura cu noi și ne-a invitat să participăm la evenimentele organizate de el săptămânal, OpenCoffee Cluj. Prin el, am făcut cunoștință cu o mulțime de oameni din zona start-up-urilor, persoane care nu doar că au acceptat să ne împărtășească experiențele lor, dar ne-au oferit și sfaturi pentru a mișca business-ul nostru înainte. La mai puțin de o lună de la prima

întâlnire, Marius ne-a trimis un e-mail prin care ne încuraja să aplicăm la Healthbox London Accelerator (www.healthbox.com). Healthbox este un accelerator medical ce avea să înceapă în octombrie în Londra și era probabil cea mai bună opțiune pentru noi să transformăm produsul nostru întru n bu s i n e ss funcțional. Am ascultat sugestia lui și după o lună, am primit oferta să participăm in primul accelerator European orientat pe medicină. Ne-am făcut bagajele, am plecat spre Londra și am format compania cunoscută acum sub numele de MIRA Rehab. Î n Decembrie 2012, Marius ne-a recomandat să aplicăm la Kairos 50. Am as c ult at din nou de e l ș i n e - am calificat la Kairos Global S u m m i t .

nr. 11/Mai, 2013 | www.todaysoftmag.ro

Kairos Global Summit a fost un eveniment în New York în Februarie 2013, unde cele mai inovative 50 de business-uri conduse de studenți au fost chemate să-si prezinte ideile lor la parterul Bursei din New York (New York Stock Exchange). Apreciam foarte mult ajutorul lui Marius și implicarea lui perseverentă în dezvoltarea acestui proiect. Înainte de a-l cunoaște, știam direcția în care ne îndreptam, dar el ne-a ajutat să facem primii pași care au dus la business-ul nostru curent. Rețeaua lui de cunoștințe, ambiția de a vedea creșterea altor companii mici și implicarea lui cu sfaturi pot ajuta orice start-up, pe oricine care are o idee bună, să facă primii pași spre un potențial succes.

LUXEMBOURG

Biz Stone Co-founder, Twitter

Trip HAWKINS Founder of Electronic Arts, CEO, Digital Chocolate

Laura Yecies CEO, SugarSync

Peter Sondergaard Senior Vice President, Research Gartner

JUNE

Ruppert Keeley CEO EMEA, Paypal

Koichiro Tsujino Founder Alex Corporation and developed VAIO, Sony, former President of Google Japon

BRIAN STEVENS CTO, Redhat

Pepe MODER

Global Director fot the Digital Marketing & Communication, Pirelli

MORE SPEAKERS ON

www.ictspring.com

eveniment

JAVA EE7. Cloud, Web 2.0+ (Features, Deltas, Changes)

e-a lungul timpului, în lumea dezvoltatorilor de software, s-au evidenţiat câteva cerinţe fundamentale precum nevoia de distribuţie, tranzacţionalitate sau portabilitate a aplicaţiilor. Limbajul Java a susţinut în permanenţă aceste tendinţe, iar platforma enterprise, este poate modelul cel mai bun de reflectare a lor. Din păcate, implementarea tendinţelor a creat numeroase probleme printre care viteza, securitatea sau încrederea. Partea centrală a versiunii 7 a platformei Java Enterprise este legată de creşterea simplificării, productivităţii şi asigurarea de suport pentru HTML 5. O altă preocupare rezolvată prin această platformă este descărcarea dezvoltatorilor de grija task-urilor legate de infrastructură, prin folosirea containerelor şi abstractizarea accesului la resurse. În versiunea 7 platforma simplifică considerabil API-ul de acces la serviciile container-ului, lărgind domeniul de servicii disponibile. De asemenea, se are în vedere extinderea platformei pentru a cuprinde tehnologiile în dezvoltare din spaţiul web. Workshop-ul despre Java EE 7 este organizat pe trei secţiuni: • Prima va oglindi principalele îmbunătăţiri aduse de Java EE 7. Aceasta înseamnă aducerea în discuţie a problemelor de design sau de implementare existente în versiunile anterioare şi modul în care ele au fost rezolvate. Mai mult, majoritatea componentelor enterprise au suferit modificări datorită evoluţiilor platformei standard precum şi celor din lumea web. Modelul cloud,

care se intenţionează a fi inclus în această versiune, modifică semnificativ. API-ul componentelor EJB sau Servlet, doar ca exemple. • Cea de-a doua va evidenţia tendinţele programării enterprise. Amintitul model cloud, dar şi API-uri noi pentru WebSocket, JSON, utilitare de concurenţă, Java Caching şi batch applications sunt tot atâtea provocări. • Partea a treia va prezenta o aplicaţie care „va rula în nori”. Acoperită exclusiv prin tehnologii Oracle aplicaţia va prezenta facilităţile şi modificările pe care modelul cloud le aduce. O aplicaţie ce „rulează în nori” va avea alte roluri de dezvoltare şi întreţinere decât o aplicaţie enterprise obişnuită. În orice moment intervenţiile din partea auditoriului pentru clarificări şi discuţii sunt binevenite. Sursele bibliografice au fost numeroase, din păcate unele dintre ele contradictorii. Spre exemplu, în acest moment nu este clar când va fi lansată Java EE 7. Termenul estimat iniţial de aprilie 2013 este aproape sigur depăşit. De

nr. 11/Mai, 2013 | www.todaysoftmag.ro

asemenea, este interesant de urmărit care dintre specificaţiile iniţiale ale versiunii 7 vor rămâne în această versiune şi care vor fi „postponed” în versiunea 8. Sursele de documentare includ prezentări la evenimente precum JavaOne, articole publicate de presa Oracle, forumuri şi altele. Aplicaţia a fost dezvoltată folosind Oracle Cloud şi, local, WebLogic. Sunt invitaţi să participe toţi cei care au preocupări în acest domeniu sau sunt interesaţi de tendinţele de dezvoltare din lumea enterprise, Java sau alternativ. Specialiştii vor găsi cu siguranţă elemente care să-i provoace la discuţii sau reflecţii. Vă aşteptăm cu toată plăcerea! Silviu Dumitrescu

Silviu Dumitrescu silviu.dumitrescu@msg-systems. com Consultant Java @ .msg systems Romania

istorie

TODAY SOFTWARE MAGAZINE

Istoria IT-ului Clujean (VI)

Învățături din Junimea

m să încep cu încheierea făcută La primul capitol, contextul geografic, polide Iacob Negruzzi cărții sale: tic și economic, par să fie de partea noastră. „Amintiri din Junimea”. Suntem un oraș de provincie, suficient de departe de capitală, cu o generație tânără „Când privesc înapoi, la viața trecută a de iubitori de IT, având o situație financiară Junimii, mă conving pe deplin că o aseme- peste medie (o statistică la nivel național nea societate nu s-a putut forma decât prin plasează IT-ul în top 3 cele mai bine plătite concursul unor împrejurări cu totul deose- domenii, Clujul ocupând poziția secundă, bite. A trebuit să se întâlnească într-un oraș după București). Îndrăznesc să sintetizez de provincie, departe de zgomotul centrului aceste asemănări contextuale sub sintagma politic, un număr de bărbați tineri, la care de infrastructură socială. plăcerea literaturei și îndeobște a ocupațiilor La capitolul diferențe separăm simintelectuale să fie deopotrivă vie. Aceștia au pla asemănare de infrastructură de acele trebuit să fie într-o situație materială inde- împrejurări identice esențiale pomenite de pendentă, așa ca să aibă de unde ajuta pe Negruzzi. Pentru a elimina diferențele este alți tineri lipsiți de mijloace, ce le păreau a necesară însușirea următoarelor învățături. avea talent și sârguință. A trebuit ca memÎn primul rând recunoașterea meritelor brii Junimii să-și recunoască deplin meritele celorlați, fără invidie. Junimea se folosea unii altora și ca nici un sentiment de invidie, de întâlniri foarte dese între membrii ei cât de ascuns, să nu turbure seninătatea con- și de prezența „Convorbirilor Literare”, o stantă a relațiilor lor. Condusă de asemenea unealtă foarte bună pentru a aduna talente, bărbați și în asemenea împrejurări, negreșit a crește voci și a polemiza cu celelalte că Societatea a putut ține atâta timp, chiar centre universitare și culturale ale țării. lipsindu-i desăvârșit orice organizare exteri- Această combinație între comunicare crioară. Dar împrejurări identice nu se vor mai tică intensă în particular și o voce unitară repeta ușor în viața unui popor și de aceea o pentru publicul larg, ajută la uniformia doua ediție a unei asemenea societăți va fi zarea și coagularea societății, permițând poate cu neputință în timpuri viitoare. șlefuirea orgoliilor înainte de expuneAvut-a Junimea merite însemnate? Acel rea publică. Există și la Cluj un efort de care, ca mine, a fost însuși actor cu greu cunoaștere a valorilor individuale printr-o poate judeca valoarea piesei în care a jucat comunicare activă și deschisă între memun rol de căpetenie. Viitorul singur se va brii diferitelor comunități. Revista TSM are rosti cu nepărtinire când noi nu vom mai ca misiune principală întocmai facilitarea fi. Totuși, credința mea este că Junimea va acestei comunicări și creșterea vizibilității păstra o pagină în istoria literaturei române, între profesioniștii din mediul IT local, căci prea am avut noi înșine plăcere la lucră- alături de tot mai multe astfel de inițiative, rile noastre, pentru a nu fi adus mulțumire de la grupări tehnologice, la organizații de și folos și publicului celui mare. Vor veni tip breaslă (vezi Cluj IT cluster). Important mai târziu alte societăți mai învățate, poate este să învățam a echilibra suficient orgoliu, mai active și mai neobosite, însă nu va mai cât să ne conștientizăm propria valoare, dar fi nici una care să fi făcut lucrări serioase nu prea mult, cât să cădem în mândrie și într-o formă atât de veselă, de plăcută și de invidie. Deși programatorii sunt o specie neobișnuită.” destul de orgolioasă, există destule semne de reușită în evitarea fragmentării, izolăPe lângă valoarea intrinsecă a citatului rii și diluarea valorii introdusă de primele de mai sus, putem extrage câteva învățături două. relevante extrapolând la contextul actual al La următoarele două învățături, suntem IT-ului clujean. O simplă recitire, în care încă în stadii incipiente: finanțarea talenteînlocuim „literatura” cu „IT-ul”, evocă o lor aflate la început de drum și atmosfera imagine apropiată de realitatea actuală. veselă și plină de satisfacție. Când ne refeRealitate plină atât de asemănări, cât și rim la finanțare, merită extins înțelesul diferențe față de contextul istoric al Junimii. junimist de ajutor financiar personal,

deoarece în practică acest rol de investitor îl pot juca atât indivizii, cât și companiile. Similar putem extinde înțelesul de tânăr talentat, atât asupra profesioniștilor angajați în diferite companii, cât și asupra antreprenorilor din scena startupurilor. Indiferent de combinațiile posibile ale înțelesurilor de mai sus, prioritară este necesitatea susținerii financiare și accelerarea proceselor de investiții pentru a contracara exodul talentelor către alte surse de finanțare internaționale. Similar modelului junimist, investim în școlarizarea talentelor (intern în companii, iar din perspectiva antreprenorială prin programe publice locale), dar ar merita extrapolat atât la învățământul public (toate nivelele), cât și la programe de investiții în startupuri. Ne punem speranța în noul cluster, în deschiderea tot mai evidentă a companiilor locale spre colaborare și implicare socială, și în cele câteva incubatoare/acceleratoare emergente. La final aleg să vorbesc despre atmosferă și atitudine. Ambele esențiale, atât în opinia lui Negruzzii, cât și a mea personală. Există tensiuni în mediul actual, generate atât de predilecția unora spre outsourcing și toate implicațiile acesteia, de competiția tot mai strânsă pe resurse, cât și de unele discrepanțe între discursul diplomat oficial prietenos și lipsa unor proiecte reale de colaborare între jucătorii principali din piață. Chiar și la nivelul startup-urilor, unde deschiderea spre comunicare și suport mutual este mai mare, există o competiție oscilantă între sănătoasă și uneori doar orgolioasă. Rețeta Junimii condiționează satisfacția finală de plăcerea și veselia cu care se desfășoară activitățile sale. Consider prioritară această rearanjare a valorilor noastre și chiar dacă un mediu de profesioniști IT veseli este ușor utopic, cel puțin plăcerea și împlinirea profesională ar trebui să ocupe primul loc. Marius Mornea

marius.mornea@todaysoftmag.com Fost senior software developer in cadrul Nokia, în prezent fondatorul platformei Mintaka Research

www.todaysoftmag.ro | nr. 11/Mai, 2013

comunități

Comunităţi IT Cluj-Napoca

n acest număr vreau să vă recomand două evenimente din perioada următoare: Romanian Testing Community Conference 2013 – 2nd Edition și IT CAMP 2013. Ambele sunt evenimente anuale și au în comun ambiția de a fi cel mai mare eveniment de profil din România. Din ce am văzut până acum, reușesc și vă recomand cu căldură să participați la două evenimente pline de prezentatori de calibru internațional.

Calendar

Transylvania Java User Group Comunitate dedicată tehnologiilor Java. Website: http://www.transylvania-jug.org/ Data înfiinţării: 15.05.2008 / Nr. Membri: 535 / Nr. Evenimente: 41 Comunitatea TSM Comunitate construită în jurul revistei Today Software Magazine. Website: https://www.facebook.com/todaysoftmag Data înfiinţării: 06.02.2012 / Nr. Membri: 585 / Nr. Evenimente: 9 Romanian Testing Community Comunitate dedicată QA. Website: http://www.romaniatesting.ro Data înfiinţării: 10.05.2011 / Nr. Membri: 593 / Nr. Evenimente: 1 GeekMeet Cluj Comunitate dedicată tehnologiilor web. Website: http://geekmeet.ro/ Data înfiinţării: 10.06.2006 / Nr. Membri: 537 / Nr. Evenimente: 16 Cluj.rb Comunitate dedicată tehnologiilor Ruby. Website: http://www.meetup.com/cluj-rb/ Data înfiinţării: 25.08.2010 / Nr. Membri: 132 / Nr. Evenimente: 34 The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software. Website: http://www.agileworks.ro Data înfiinţării: 04.10.2010 / Nr. Membri: 303 / Nr. Evenimente: 26 Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice. Website: http://www.meetup.com/Cluj-Semantic-WEB/ Data înfiinţării: 08.05.2010 / Nr. Membri: 139/ Nr. Evenimente: 22 Romanian Association for Better Software Comunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare. Website: http://www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 219/ Nr. Evenimente: 12

nr. 11/Mai, 2013 | www.todaysoftmag.ro

Mai 7 AgileWorks Remote Open Space www.meetup.com/The-Cluj-Napoca-Agile-SoftwareMeetup-Group Mai 8 Monthly Meetup #13 www.meetup.com/Tabara-de-Testare-Cluj Mai 9 Lansarea numărului 11 TSM www.todaysoftmag.ro Mai 14 Software architecture and the balance with agility www.arobs.com/architecture-workshop Mai 16-17 Romanian Testing Community Conference 2013 www.romaniatesting.ro Mai 17 JAVA EE7. Cloud, Web 2.0+ msg.info-office-cluj@msg-systems.com Mai 17-19 Startup Live Cluj-Napoca startuplive.in/cluj-napoca/2 Mai 18-19 Asynchronous Master Class codecamp-cluj-mai2013.eventbrite.com Mai 23-24 ITCAMP 2013 itcamp.ro Mai 25 Fun Meetup v2.0 w w w . l i n k e d i n . c o m / g r o u p s / Functional-Programming-in-Romania-4338166 Mai 30-31 I T.A.K.E Unconference București http://itakeunconf.com/

programare

TODAY SOFTWARE MAGAZINE

Software Craftsmanship

ișcarea Software Craftsmanship a prins contur în 2009, ca reacție la ideea că putem reduce temporar calitatea codului pentru a scoate produse mai repede. Promotorii mișcării consideră că dimpotriva, ceea ce trebuie sa îmbunătățim este viteza cu care un programator scrie cod de calitate. Altfel, utilizatorii, clienții și compania care produce software au de suferit: primii din cauza greșelilor introduse în aplicații (bug-uri), iar compania datorită scăderii vitezei de producție a noilor versiuni și a nemulțumirii utilizatorilor. Alexandru Bolboaca

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

Pentru a sprijini nevoia aspiranților la software craftsmanship de a ajunge la acest nivel, promotorii mișcării au recurs la o metaforă bazată pe istoria breslelor și a meșterilor.

Metafora

Adrian Bolboaca

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

În epoca medievală bunurile erau produse manual. Fiecare profesie era structurată în bresle, unde meșteșugarii puteau să se întâlnească, să învețe unii de la ceilalți și să-și apere profesia. Pentru că unele bresle din anumite cetăți controlau foarte bine calitatea produselor, acestea dobândeau faimă. Acesta este motivul pentru care breasla era o instuție închisă; orice meșter ce intra în breaslă trebuia să producă la o anumită calitate. Între breslele dintre diverse orașe era o competiție acerbă, de aceea calitatea produselor creștea constant. Fiecare breaslă avea un statut care reglementa funcționarea internă a sa. De asemenea organizarea breslelor era reglementată prin legi. Pentru a deveni meșter, un tânăr trebuia să treacă câteva etape: să devină ucenic, apoi să devină calfă, să călătorească între cetăți pentru a învăța de la alți meșteri si doar apoi putea să devină și el meșter. Ascensiunea în cadrul breslelor nu era deloc simplă și necesita ani lungi de pregătire. Un tânăr intra în ucenicie încă de la 10-12 ani. Înainte de a intra în ucenicie

tânărului i se testau 2-3 săptămâni aptitudinile. Ucenicia dura în jur de patru ani, timp în care ucenicul era un fel de slugă în casa stăpânului având sarcini de la răsăritul până la apusul soarelui. După terminarea uceniciei, ucenicului i se elibera un certificat de învățare a meșteșugului, care îi permitea să fie angajat drept calfă. După acest moment calfa avea trei opțiuni: să rămână în atelierul meșterului, să se angajeze la alt meșter sau să-și facă timpul de călătorie1. Călătoria avea scopul de a-l ajuta pe calfă să-și însușească mai bine meseria. Timpul obligatoriu de călătorie era de 2-4 ani. După călătorie, calfa trecea un examen de meșter: o proba practică, o lucrare de măiestrie sau capodoperă. Breasla analiza lucrarea pe care o aproba sau o respingea printr-o comisie. Doar după un proces de acceptare în breasla tânărul meșter avea voie să-și deschidă un atelier. Un meșter era un cetățean al orașului în care locuia și putea să participe la deciziile politice ale orașului. În cadrul unei bresle, exista o conducere aleasă. Meșterul cu cea mai mare experiența și cu reputatie imaculată era de obicei conducătorul breslei. Această conducere avea grijă ca breasla să prospere, stabileau standardele de calitate ale produselor și realizau toate actele administrative. 1 http://arheologie.ulbsibiu.ro/publicatii/bibliotheca/ bresle/4%20capitolul%20II.htm

www.todaysoftmag.ro | nr. 11/Mai, 2013

programare Software Craftsmanship Principiile

După cum menționam mai sus, Software Craftsmanship este o abordare in industria de Software Development care accentuează importanța abilităților dezvoltatorilor. Inițiatorii mișcării doresc să ridice standardele profesiilor din industria IT prin aplicarea acestor concepte din epoca medievală. Mișcarea a luat ființă în anul 2009 prin realizarea unui manifest

auto-denumească “Aspiring Software Craftsman”, echivalentul ucenicului din istoria breslelor de meșteșugari. Scopul lor este ca programatorilor să le pese de calitatea produselor, calitate codului și să dorească să învețe continuu. Dupa cum un ucenic lucra de la răsărit până la apus, la fel și un aspiring software craftsman ar trebui să exerseze cât mai mult pentru a-și îmbunătați abilitățile. Astfel au devenit și

Manifestul Software Craftsmanship

Acest manifest este o continuare al “Manifesto for Agile Software Development”, care presupunea existența software-ului funcțional, să putem răspunde rapid la schimbări, valorizarea interacțiunilor între persoanele implicate în dezvoltarea unui software și colab orarea intensivă cu clientul. Software Craftsmanship vrea să completeze “Manifesto for Agile Software Development” prin faptul că nu se dorește doar software funcțional, ci un software creat cu grijă și pricepere. Pe lângă a răspunde schimbării rapid și eficient, adăugăm valoare prin funcționalități importante pentru utilizatori. E important ca nu doar să valorizăm interacțiunea dintre oameni, ci dorim să creăm o comunitate de profesioniști.

mai cunoscute practicile următoare: coding kata, coding dojo, pair-programming, dar a fost inventat și un alt concept: code retreat. Vom reveni la ele în detaliu. Corey Haines este printre primii programatori care a preluat modelul călatoriei ucenicilor și s-a autodenumit “software journeyman”. Ceva mai mult de un an Corey a călătorit în lume cu singurul scop de a învăța lucruri noi de la alți programatori. În timpul călătoriei dorea doar sa aiba unde să doarmă și să aibă ce să mănânce, în schimb dezvolta orice aplicatie era nevoie. După ce și-a încheiat călătoria, Corey a revenit la maestrul său, Robert C. Martin, și i-a povestit ce a învățat, la fel ca în timpul breslelor.

Practici de programare

Spre deosebire de alte profesii, un programator nu are un set de practici Începând cu anul 2009 când a standardizate pe care trebuie neapărat să fost publicat acest manifest, tot mai le învețe. Există desigur practici pe care o mulți programatori au început să se echipă sau alta le folosesc, dar la nivel de

Istorie

nr. 11/Mai, 2013 | www.todaysoftmag.ro

industrie avem foarte puține dovezi despre ce anume ajută și ce nu la dezvoltarea aplicațiilor complexe. Aceasta a fost o problemă pentru Software Craftsmanship, pentru nu poți dezvolta abilitățile programatorilor atunci când nu știi care ar trebui să fie. Inițiatorii mișcării au făcut două lucruri: au selectat câteva practici din experiența unor programatori cu zeci de ani de experiență și au insistat ca fiecare programator sa învețe în continuu în cadrul comunității, în speranța că vor reuși să descopere ce definește profesia. Câteva din aceste practici recomandate pentru orice aspirant software craftsman sunt: testarea automată sub forma unit testing sau test driven development, refactoring continuu, menținerea ‚curățeniei’ codului prin urmarea unor reguli de ‚clean code’, elemente de design și arhitectură, paradigme diferite de programare – object oriented și funcțional și pair programming. Această listă este doar o bază pe care membrii comunităților construiesc. La nivel personal, recomandarea mișcării este ca fiecare programator să încerce să stăpânească aceste practici, să le discute în comunitate și sa le aleagă pe cele care îl ajută cel mai mult în cadrul unui proiect. Mișcarea este uneori criticată pentru această listă de practici. Multe din critici vin ca reacție la afirmațiile lui Robert C. Martin, probabil cel mai vocal promotor al software craftsmanship, care susține cu îndârjire practicile de mai sus. Scopul lui este acela de a defini un standard al profesiei, dar metodele folosite înstrăinează unii programatori interesați de mișcare. În realitate, majoritatea celor care aspiră la craftsmanship sunt persoane pragmatice care preferă să stăpânească toate uneltele meseriei, pentru a le putea selecta pe cele utile la un moment dat.

Moduri de a învăța

O dată ce o listă de practici de programare care trebuie stăpânite sunt definite, programatorii au nevoie de metode de a le învăța. Așa cum arată experiența lui Corey Haines (și nu numai), una din cele mai bune metode de a învăța programare este prin interacțiunea cu comunitatea. În același timp însă, este important ca un programator să își dezvolte și singur abilitățile. Software craftsmanship propune câteva metode de a învăța aceste practici. Coding kata este o metodă împrumutată din arte marțiale și se referă la exersarea unei practici de programare prin

TODAY SOFTWARE MAGAZINE rezolvarea repetată a unei probleme simple folosind acea practică. Există pe web destule probleme documentate în acest scop, la fel cum există înregistrări video ale unor programatori din comunitate care o demonstrează. Cel mai important lucru este ca după fiecare rezolvare, programatorul să se gândească ce l-a încetinit în timpul exercițiului și ce ar trebui să schimbe pentru a elimina această frână. Coding dojo este o altă metodă împrumutată din artele marțiale. Se referă la un exercițiu de grup cu scopul de a transmite cunoștințe între participanți. Grupul va încerca să rezolve o problemă, exersând anumite practici. În forma lui cea mai răspândită, doi programatori scriu cod folosind un proiector pentru ca toată lumea să poată vedea. La un interval de timp (în jur de 7 minute), unul dintre ei este înlocuit de următorul programator din sală. Astfel, prin rotație, toată lumea va scrie cod și va vedea cum scriu cod ceilalți. Code retreat este un alt format, de această dată preluat de la comunități de scriitori. Ideea unui code retreat este de a combina mai multe din elementele dintrun coding dojo sau coding kata într-o singură zi de exersare. Code retreat-urile au loc de obicei sâmbăta și durează toată ziua. Evenimentul este structurat în 6 sesiuni de 45 de minute, separate în retrospective scurte. Regulile sunt simple: în cadrul fiecărei sesiuni, programatorii lucrează în pereche cu scopul de a scrie cod cu anumite constrângeri impuse de facilitator și care facilitează învățarea. După fiecare sesiune, codul scris este șters complet, perechile și constrângerile se schimbă și scrisul de cod reîncepe. Primele code retreat-uri au avut loc în SUA în 2009, urmate foarte curând de România, unde au fost facilitate de Maria

Diaconu și Alexandru Bolboacă în cadrul comunității AgileWorks. Corey Haines a avut un rol foarte important în răspândirea evenimentului în întreaga lume, totul culminând cu “Global Day of Code Retreat” când timp de 24 de ore au loc code retreat-uri non-stop în toată lumea. Adrian Bolboacă este responsabilul pe Europa al acestui eveniment global. În foarte scurt timp aceste practici au fost preluate și de comunitatea de testare, iar acum există testing kata si testing dojo. De asemenea de curând Markus Gärtner a realizat primul test automation retreat. La fel, aceste practici au fost adaptate și pentru arhitectură, apărând architecture kata și architecture retreat. Noi tipuri de exerciții au apărut în timp. Adrian Bolboacă a inventat sesiunea numită “Taking baby steps” cu scopul de a învăța refactoring și a avut succes la conferințe internaționale, în cadrul comunităților și la code retreat-uri. Adrian Bolboacă și Alexandru Bolboacă au inventat sesiunea “Brutal refactoring”, care a fost preluată în întreaga lume. Keith Braithwaite a inventat sesiunea numită “TDD As If You Meant It”, acum preluată în aproape fiecare code retreat. În afara acestor evenimente de comunitate, există și posibilitatea de a învăța prin pair programming. Orice programator ar trebui să poată invita pe un altul la o sesiune privată de exersare. Câțiva programatori fac acest lucru și la distanță; Alexandru Bolboacă a deschis de câțiva ani un “Remote Pair-programming Tour” în acest scop.

Conferințe

iar România se alătură anul acesta prin conferința I. T.A.K.E. Pe 30-31 mai, evenimentul va aduna programatori din întreaga Europă și invitați din SUA cu scopul de a discuta, exersa și învăța împreună aceste practici de programare. Nu doar că toți vorbitorii vor scrie cod, dar și participanții vor programa în cadrul workshop-urilor, concursului kata lounge, dezvoltării unui produs open source într-un format hiper-agil numit “Open Space Software Development” sau în timpul track-ului de unconference organizat sub formatul “Open Space”. Liderii multora din comunitătile europene de software craftsmanship vor participa la conferință ca vorbitori și cu workshop-uri. Acest eveniment deschide tuturor programatorilor din România porțile către nivelul cel mai înalt de cunoștințe despre dezvoltarea de software din Europa.

Concluzie

În concluzie, Software Craftsmanship este o mișcare de amploare internațională, care are la bază ideea că profesia de programator înseamnă putința de a livra cod de calitate sub presiune. Pentru a ajunge acolo, programatorii trebuie sa stăpânească o listă de practici. Pentru a le stăpâni, ei pot exersa singuri și în cadrul comunităților folosind anumite formate specifice de întâlniri. Code retreat-ul este formatul care s-a răspândit cel mai rapid în ultimii ani, culminând cu Global Day of Code Retreat. În România, mișcarea este promovată de comunitatea agile “AgileWorks”, de conferința I T.A.K.E., precum și de programatori pasionați din țară.

Comunitatea de software craftsmanship organizează câteva conferințe. Cele mai cunoscute sunt în SUA și Londra,

Referințe: http://arheologie.ulbsibiu.ro/publicatii/bibliotheca/bresle/4%20capitolul%20II.htm http://manifesto.softwarecraftsmanship.org http://agilemanifesto.org http://en.wikipedia.org/wiki/Kata_%28programming%29 http://codingdojo.org/cgi-bin/wiki.pl?WhatIsCodingDojo http://coderetreat.org/about http://www.testingdojo.org/tiki-index.php http://blog.adrianbolboaca.ro/2013/04/the-history-of-brutal-refactoring-game/ http://blog.adrianbolboaca.ro/2013/01/the-history-of-taking-baby-steps/ http://www.alexbolboaca.ro/wordpress/articles/how-to-organize-a-code-retreat http://www.alexbolboaca.ro/wordpress/the-remote-pair-programming-tour http://agileworks.ro http://itakeunconf.com

www.todaysoftmag.ro | nr. 11/Mai, 2013

arhitectură

Din bucătăria arhitectului software carduri de scenarii

etodologia care urmează a fi prezentată în acest articol a fost dezvoltată de cei de la SEI (Software Engineering Institute, Carnegie Mellon) și face parte din metodologia ATAM (Architecture Tradeoff Analysis Method). Articolul prezintă într-o formă simplificată această metodologie accentând latura practică.

Cardul de Scenarii Attila Antal

Attila.Antal@isdc.eu Software Architect @ ISDC

Cardurile de scenarii sunt folosite pentru argumentarea decizilor din diferite puncte de vedere. Cardurile sunt create de arhitectul din proiectul respectiv și sunt distribuite pentru evaluare de către membrii decizionali ai echipei, inclusiv de către client. Un șablon al cardului de scenarii este prezentat în schema de mai jos. După cum se observă cardul are patru zone: • Zona cu detalii, unde se introduce un cod relevant al scenariului și o scurtă descriere a lui. • Zona cu detalii legat de mediu de lucru din punct de vedere arhitectural. • Zona cu deciziile care urmează să fie luate specific scenariului. • Zona cu argumentele arhitecturale, motivul și o diagramă simplă care reflectă obiectul scenariului.

arhitecturii curente. Acestea fiind: • Pucte Sensibile marcate cu cod S1, S2, … • Puncte de Compromis marcate cu cod T1, T2, … • Riscuri marcate cu cod R1, R2, … • Non-riscuri marcate cu cod N1, N2, … Un punct sensibil înseamnă o proprietate a unei componente care este critică pentru obținerea unui atribut de calitate. Punctul de compromis e o proprietate care afectează mai multe atribute de calitate sau e un punct sensibil pentru mai multe atribute. Riscurile sunt decizile arhitecturale care pot să cauzeze probleme potențiale. Non-riscurile sunt menționarea deciziilor arhitecturale bune, în cardul de scenarii au caracter informativ.

Aceste coloane pot conține una sau mai Zona cu deciziile are un câmp de multe valori în foma codificată (menționat explicatii și alte patru de impact asupra deja mai sus). Aceste coduri urmează să fie

nr. 11/Mai, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE explicate în liste dedicate.

DL2: Logică Configurabilă

Studiu de caz

DL3: Logică Bazată pe Rule Engine

Pentru a prezenta cât mai real cum funcționează procedeul prin care se găsește o soluție potrivită cu ajutorul cardurilor de scenarii, voi prezenta în continuare un caz ipotetic. Deci, un presupus client are o aplicatie în care în stratul de logică de business vrea să introducă un modul care decide și influențează rezultatele la anumite calcule. Aceasta îi va cere arhitectului proiectului (în acest context fiind vorba de noi) să vină cu niște idei de implementare. Arhitectul, adica noi, vom realiza trei scenarii și îl vom trece printr-un procedeu de evaluare și la final încearcăm să găsim soluția cea mai potrivită. Să vedem scenariile!

DL1: Logică Hardcodată Scenario #: DL1 Attribute(s) Environment Stimulus Response Architectural decisions Hardcodare Reasoning

Scenario #: DL3 Se va folosi un Rule Engine pentru decizii. Attribute(s) Environment Stimulus Response Architectural decisions Folosirea unui Rule Engine Maintenanță pentru baza de reguli

Se va folosi o logică de decizie internă, hardcodată.

Sensitivity

Tradeoff

Risk

Sensitivity Tradeoff S2, S3 S4

Risk

Nonrisk

Introducerea în arhitectură a unei Rule Engine aduce flexibilitate și configurabilitate.

Reasoning

Performance În timpul rulării (Runtime) Cerere de luare decizii dinspre Business Logic. Decizii luate pe baza logicii interne.

Flexibilitate În timpul rulării (Runtime) Cerere de luare decizii dinspre Business Logic. Decizii luate de Rule Engine.

Architecture Diagram

Nonrisk

S1 R1 N1 Folosind modul de decizie “hardcoded” se reduce complexitatea și în plus se poate obține performanța maxima de executie.

Lista Punctelor Sensibile Code S1 S2 S3

Architecture Diagram

Description Logica de decizie e greu de modificat mai târziu și necesită relansarea produsului în producție. Introduce complexitate în proiect. Necesită expertiză și/sau experiență. Comunicarea și planificarea în sync cu echipa care întreține baza de reguli.

Lista Punctelor de Compromis Scenario #: DL2 Attribute(s) Environment Stimulus Response Architectural decisions Hardcodare Fișier de Proprietăți Reasoning

Se va folosi o logică de decizie internă semihardcodată bazată pe anumite atribute configurabile prin intermediul unui fișier de proprietați. Configurability În timpul rulării (Runtime) Cerere de luare decizii dinspre Business Logic. Decizii luate pe baza logicii interne influențate din exterior. Sensitivity Tradeoff

Risk R1

Nonrisk

Code T1 T2

Lista Riscurilor Code R1 R2

Dacă logica de decizii se bazează pe niște parametri care se pot externaliza, atunci se poate introduce configurabilitate.

Description Schimbarea logicii necesită development. Fiind fișierul de proprietăți un punct sensibil al sistemului trebuie protejat și asignate roluri specifice modificării.

Lista Non-Riscurilor Code N1 N2

Architecture Diagram

Description Trebuie decis dacă proprietătile vor fi recitite imediat după modificare sau numai după relansarea aplicației (flexibilate vs. garanția calculațiilor ptr. toți). Trebuie ales un Rule Engine portivit.

Description Este ușor de realizat și garantează lansarea în timp în productie. Găsită o soluție ușoară de lansare a regulilor.

Evaluare

Pentru evaluarea scenariilor vom folosi forma tabelară a unui “Utility Tree”. Enumerăm scenariile de pe carduri dar putem adăuga si altele (fără card) și rugăm părțile participante din partea clientului să dea o notă de importanță (L – low, M – medium, www.todaysoftmag.ro | nr. 11/Mai, 2013

arhitectură Din bucătăria arhitectului software H - High). Coloana de dificultate va fi marcată de arhitectul proiectului. În cazul nostru tabela va arăta astfel (coloana de importanță fiind o presupunere): Quality Attribute

Scenario

Importance Difficulty

Performanță

DL1: Logică hardcodată

Configurabilitate

DL2: Logică configurabilă

Flexibilitate

DL3: Logică bazată pe Rule Engine

punctele sensibile, compromisurile și riscurile. • Fiecare card trebuie sa fie evaluat de către client sau de către reprezentantul tehnic al clientului • Cardurile de scenarii trebuie colectate și catalogate pentru că fac parte din procedeul de luare de decizii și pe de altă parte ele pot fi reutilizate.

L M H

Din tabela de mai sus trebuie selectate cele cu importantă mare, deci: • DL2: Logică configurabilă (H,M) • DL3: Logică bazată pe Rule Engine (H,H) Fiindcă scenariul # DL3 are și dificultate mare avem nevoie de mai multe analize din partea părților și de văzut dacă într-adevăr au nevoie de această solutie. Dificultatea mare în cazul nostru putând fi tradusă prin: mai scump, timp mai mare de implementare și eventuale costuri de licentă și întreținere. Deci putem pronunța că până se naște o decizie legat de # DL3 soluția câștigătoare va fi cel de # DL2.

Sumar

Concluziile pe care le putem trage după citirea acestui articol sunt: • Arhitectul trebuie să vină tot timpul cu diferite scenarii pentru o singură problemă. • Cardul de scenarii este un mediu de prezentare a unei idei și în același timp este și mediu pentru a aduce decizii. • Cardul de scenarii este prima linie unde vor fi menționate

Throughout the year, ISDC engineers dreams of customers. Only in spring time, we engineer Easter sponge cakes!

nr. 11/Mai, 2013 | www.todaysoftmag.ro

PAȘTE FERICIT! FIJNE PAASDAGEN! FROHE OSTERN! !

arhitectură

TODAY SOFTWARE MAGAZINE

Arhitectura extransibilă și durabilă (grow form novice to guru)

he dialogue between client and architect is about as intimate as any conversation you can have, because when you’re talking about building a house, you’re talking about dreams. Robert A. M. Stern

THE PHILOSOPHY

Levente Veres

Levente.Veres@endava.com Design Lead @ endava

În zilele de azi dezvoltarea de aplicații nu se rezumă la dezvoltarea de module, la mentenanţa aplicațiilor dezvoltate acum ani de zile sau la o simplă testare de funcționalitate. “Softiști români” au ajuns la nivelul la care nu numai clientul sau “dezvoltatorul” dorește mai mult, ci și piața dorește ceva mai mult de la “dezvoltatori români”. Clientul așteaptă ceva mai prețios decât o executare coordonată, aşteaptă ceva în plus care să îl surprindă chiar și pe el. Desigur, marea majoritate a programatorilor neglijează acest detaliu pe care îl conștientizează doar atunci când devin ei înșiși clienți. Marea majoritate a dezvoltatorilor nu va fi în stare să sacrifice timp și energie adițională ca să ofere ceva în plus. Motive se găsesc, multe personale cât și financiare sau alegerea stagnării în zona de confort. Articolul de mai jos este adresat tuturor care doresc să ofere ceva în plus faţă de cerințele standard, totodată să se pregătească pentru a deveni cei mai buni în domeniul IT. Desigur fiecare are la dispoziţie o cale unică și proprie pentru a atinge nivelul de Arhitect, ceea ce necesită experiență de ani de zile. Pentru a defini un Arhitect, fie el din categoria system-software, solution sau business, aș folosi câteva cuvinte cheie: dreams (vise), reality (realitate), creation (creare), timeless (inexpirabil). Un arhitect trebuie să ia în considerare ca orice soluție, aplicație creată de el reflectă în realitate visul unui/unor oameni

și va fi cât de cât posibil o creație de durată. În cazul în care v-ați regăsit mai sus vocația, putem trece la următoarele nivele unde vom discuta succint despre unele aspecte din modul în care transformăm un vis în creație reală.

THE SECRET

Care este cheia succesului unei arhitecturi care satisface toate cerințele proiectului? Întrebarea este retorică, dar se poate răspunde la ea. Arhitectura ideală este cea care satisface cele patru criterii de mai sus și este consecventă cu deciziile luate pe durata implementări , totodată nu deviază de la criteriile de bază propuse în primele etape ale arhitecturi. Deși pare ușor de făcut față celor de mai sus, cu atât e mai greu să menții în echilibru creația din diferite motive cum ar fi decizii manageriale, financiare, schimbări de scopuri sau schimbări de echipe.

THE BUCKET LIST

Pentru a ține totul sub control trebuie să fim conștienți că fără o listă de ”to-do” nu prea vom putea fi consecvenți, ceea ce induce ca arhitectura aleasă să nu fie sustenabilă. Desigur această listă are sens numai dacă periodic reluăm și verificăm dacă mai este actual ceea ce am definit inițial, dacă deviația este prea mare e timpul să regândim dacă arhitectura aleasă va fi sau nu prea bună. O listă de necesitați SMART poate fi următoarea:

www.todaysoftmag.ro | nr. 11/Mai, 2013

arhitectură Arhitectura extransibila si durabila (grow form novice to guru) A. Colectarea informațiilor

1. Creați o lista de cerințele funcționale. Exemplu: Dorim o aplicație care face rezervări de bilete de avion. 2. Creați o lista de cerințe non-funcționale Notă: Dacă nu aveți așa ceva de la client, atunci ARHITECTUL are responsabilitatea de a face o lista exemplificată mai jos, care îi va ajuta și pe dezvoltatori. Exemplu: • Soluția noastră în 30 de milisecunde găsește toate biletele disponibile pentru o anumita rută. • Fiecare interogare de bază de date nu durează mai mult de 10 milisecunde. • Putem deservi 1000 de utilizatori pe minut. • Folosim fiecare server de aplicație cu un grad de ocupare maxim 70%. 3. Creați o listă proprie de posibile cerințe (definim cât extensibilă să fie aplicația). Exemplu: Dorim în viitorul apropiat să deservim aplicațiile mobile prin servicii web(Restful). 4. Creați o lista despre așteptările stakeholder-ilor de la soluția propusă Exemplu: • Directorul economic: reducere cu 10% al costurilor de vânzări • Directorul IT: să reducă nemulțumirea angajaților cu accesul la sistem • Angajați: clienți să-și poată rezerva foarte rapid biletele. Notă: lista de mai sus va fi una benefică în final la predarea aplicației când va fi prezentată aplicația. Totodată pe parcursul discuțiilor și al ideilor de implementare vom nevoile diferiților stakeholderi.

B. Shape it:”Frizerul prietenul nostru”

1. Slice – Taie pe mărimea potrivita • Descompune problema în probleme mai mici, funcționalității mari în sub-funcționalități ce pot fi rezolvate. • altă metodă este descompunerea în module/blocuri ce aduc mai aproape de conceptul OOP.

nr. 11/Mai, 2013 | www.todaysoftmag.ro

2. Frizerul ortogonal: • Să ne orientam către ortogonalitate, adică să modularizăm soluția. Astfel avem posibilitatea de a crea diferite module și interfețe facilitând testatarea și mentenanța produsului. 3. DRY(Don’t Repeat Yourself) – Uscatul • Cel mai cunoscut acronim legat de ideea: un singur rezultat la o singură problemă. E important să nu încercam să repetăm codurile, modulele, interfețele care au aceeași funcționalitate. 4. Test it: testul cu oglinda • Testabilitatea soluției este cea mai vitală pentru a susține o arhitectură robustă, dar totuși receptivă la schimbări. • E important să decidem până la ce nivel dorim să testăm soluția propusă: nivelul micro pentru care vor fi testat fiecare variabilă, metodă sau clasă ori putem să ne orientăm către o testare macro caz în care ne interesează să poată fi testate modulele. 5. FixIt: - un coafor priceput se respectă: • E bine de creat module care suportă modificările și fix-urile, astfel încât să nu aibă impact asupra altor componente. • În cazul în care fix-ul aduce modificări asupra mai multor module în același timp, e necesar de revizuit planul inițial, dacă arhitectura chiar corespunde nevoilor noastre. 6. Cost of changes: plata la frizer • arhitectura robustă trebuie să suporte schimbări continue, dar în același timp prețul schimbărilor trebuie să rămână minim. • Pentru calculul costului schimbărilor se poate folosi o ecuație simplă care avertizează asupra riscurilor: Sum( Change[1..n]x Sum(Affected Module[1..m]) ) = Cost of Change

• Unde n,m reprezintă numărul maxim de schimbări și module. • Fiecare schimbare și modul are valoare 1, desigur dacă modulele sunt mai complexe putem defini pentru fiecare modul un cost specific. • Costul maxim îl vom obține pentru cazul în care

TODAY SOFTWARE MAGAZINE fiecare schimbare are impact asupra fiecărui modul. D. The Good is the enemy of The Perfect: să tindem la perfecționism • Costul ideal este de 30% din costul maxim, costul • De fiecare dată să încercăm sa îmbunătățim codul optim între 30% și 70%, iar costul critic peste 70% din existent. costul maxim. • Să nu ne lăsăm pradă ideilor: îmbunătățirea nu se plătește, lasă că rezolvam cândva etc. Exemplu: în cazul a 3 module , unde Modul3 are cost 3, • Respectă munca ta și a altora. pentru la 2 schimbări avem următorul cost: • Utilizează conceptul ”Benefits +1”, întotdeauna să aduci ceva în plus față de ce ți s-a cerut. o Change1 x (Module 1 + Module 2) + Change2 • PROTOTYPE: crearea de prototipuri ne ajută să fim x (Module1+Module2+Module3) = 1x(1+1) + 1x(1+1+3) =2 +5=7 siguri că suntem pe drumul cel bun o Cost maxim: Change1(Module1 + Module2 + Mod• DESENEZĂ: afișarea grafica a arhitecturii ne aduce ule 3) + Change2x(Module1+Module2+Module3)= 1x(1+1+3)+1(1+1+3)=10 beneficiul vizual al unei analize rapide o Cost Maxim : 10; Cost ideal: 3; Cost critic: 7. Lista de mai sus se poate completa cu multe altele, astfel încât În exemplul dat suntem la limită între costul critic și cel să fie una foarte complexă și satisfăcătoare, de fiecare dată însă ideal, cea ce ne informează ca ar fi posibil ca arhitectura trebuie luat in considerare BENEFICIUL adus prin introducerea să fie afectată și să aibă consecințe majore. noilor complexități. În următorul număr al revistei TSM vom identifica niște „best C. Focus Point: de reținut practices” pentru a crea arhitecturi accesibile întregii echipe. • Să verificam calitatea, metrica, redundanța modulelor și a claselor; • Să verificăm dacă arhitectura aleasă sau standardele de aliniere (Togaf, ISO etc) se mai mapează pe soluția curentă; • Să introducem puncte de control pentru validarea soluției si a arhitecturi; • Să ne amintim de limitele de hardware, rețea si a componentelor integrate; • Să ținem minte că resursele sunt limitate (bani, dezvoltatori);

www.todaysoftmag.ro | nr. 11/Mai, 2013

Testarea în Cloud

n ziua de azi toată lumea vorbește despre Cloud, despre cum să ne mutăm activitățile pe Cloud, cum să câștigăm timp folosind avantajele oferite de acesta. Dar până la urmă ce este de fapt acest Cloud și cine are grijă ca totul să meargă bine în interiorul lui? “Cloudul este un mecanism complex format dintr-o multitudine de servicii software și hardware adaptabile la nevoile clienților”.

Serviciile oferite de Cloud se împart în două mari categorii: SaaS și IaaS • SaaS – Software as a Service: adică închirierea de licențe software (pe bază de abonament). Mai exact, SaaS reprezintă o metodă de a furniza acces la licențe software și funcționalităților acestora printr-un serviciu Web-based. Folosirea acestei metode duce la eliminarea nevoi de a instala și rula aplicația local ceea ce va duce la ușurarea mentenanței și a suportului. Exemple de SaaS: CMS, CRM, Email, Virtual Desktop, Communications, Games, etc • IaaS – Infrastructure as a Service: reprezintă închirierea de resurse hardware (spațiu de stocare, memorie și procesor). Acestea similar cu SaaS, odată externalizate vor aduce o relaxare a mentenanței și a suportului pe local, focusul putând mutat spre alte detalii. Exemple de IaaS: Virtual Machines, Ser vers, Storage, Load Balancers, Network, etc. În alte variante serviciile oferite de Cloud mai conțin de asemenea PaaS și NaaS: • PaaS – Platform as a Service: închirierea de platforme complete pentru development ce includ sistemele de operare, mediile de programare, bazele de date și web-serverele • NaaS – Network as a Ser vice: închirierea rețelei, serviciilor de interconectare, VPN, optimizarea resurselor alocate, şamd. Câteva din avantajele oferite de Cloud ar fi mobilitatea, viteza, capacitatea de

stocare relativ nelimitată, puterea de procesare și memorie cu mult superioare, lipsa grijilor în ceea ce privește mentenanța software și hardware. Alte avantaje pe care un manager le urmărește în mod particular ar putea fi reducerea cheltuielilor cu licențele software și hardware, dimensionarea costurilor în funcție de nevoi și transformarea costurilor de capital în costuri operaționale. Cine oferă aceste servicii? În general companiile mari gen HP, Keynote Systems, Advaltis, Compuware, Load Impact, SOASTA, etc. Aceștia se folosesc de serviciile de hardware vândute sau închiriate de Amazon, Google, Microsoft, etc.

Testarea în Cloud

Testarea este o provocare pentru multe proiecte, în special pentru aplicațiile mari unde business-ul și performanța au de suferit condiții “grele” de utilizare. Cantitatea de testcase-uri poate varia de la câteva sute la câteva mii, iar toate acestea necesită resurse semnificative de hardware și timp de execuție. Să nu mai vorbim de numărul mare de resurse umane necesare pentru a putea acoperi aceste nevoi. Cloud-ul vine în întâmpinarea acestor probleme și oferă potențialul de abordare a acestora. Acesta oferă resurse precum virtualizarea hardware-ului în mod eficient, stocare nelimitată și servicii de software și hardware care pot ajuta la reducerea timpului de execuție. Cu toate aceste avantaje, migrarea în Cloud este o operațiune destul de costisitoare, iar uneori nu este neapărat cea mai bună soluție la toate problemele de testare. Așadar ce ar trebui luat în considerare

nr. 11/Mai, 2013 | www.todaysoftmag.ro

înainte să ne mutam testarea în Cloud?

A. Caracteristicile aplicației Cloud-ul ne poate ajuta atunci când avem nevoie de conexiuni din diferite locații geografice cum ar fi un site de socializare sau video-streaming. Testarea firewall-urilor și load-balancerelor implică cheltuieli hardware, software și întreținerea acestora. În cazul aplicațiilor unde rata de creștere a numărului de utilizatori este imprevizibilă sau unde avem multe medii de deployment, Cloudul se arată din nou mai eficient decât abordarea tradițională.

B. Tipurile de teste pe care dorim să le facem Dintre cele mai populare activități de testare pe care le putem face în Cloud: • Stress Testing • Load Testing • Performance Testing • Functional Testing • Compatibility Testing • Browser Performance Testing • Latency Testing Mutarea în Cloud se face de obicei pentru activități ce țin de testarea performanței și simularea unui trafic cât mai apropiat de realitate, distribuit in locații diverse. Aici, Cloudul se remarcă prin adaptabilitate și rapiditate în ceea ce privește rezultatul final.

Pașii de urmat

Așadar după ce am stabilit că ne mutăm în Cloud cu testarea, care ar fi următorii pașii de făcut? În prima fază avem de identificat și stabilit care sunt scenariile pe care un

TODAY SOFTWARE MAGAZINE

utilizator al aplicației le va face. Extragem testcase-urile și trecem la următoarea fază. Aceste două etape sunt sau ar trebui oricum acoperite de la începutul sprintului/ proiectului. Al treilea pas, cel de selecție a Cloud Service Provider-ului, trebuie făcută in concordanta cu specificul aplica si rezultatele pe care dorim să le obținem. De asemenea trebuie ținut cont de serviciile pe care Providerul le furnizează. Lista de Cloud Service Providers fiind una foarte dinamică, trebuie să avem în vedere să nu rămânem în urmă în perioada imediat următoare ținând cont de cerințele și

expectanțele pe care noi le avem. la schimbarea sistemelor de operare, Al patrulea și al cincilea pas, Setup browser-elor; Infrastructure și Leverage Cloud Servers • Mobilitate mare pentru departapresupun stabilirea hardware-ului necesar mentul de testare, acolo unde acesta rulării testelor, calibrarea și optimizarea este distribuit în mai multe locații; aici serverelor din Cloud ca să corespundă testarea va avea un mare avantaj, timpul setup-ului de producție în care aplicația petrecut în sincronizarea environmentnoastră va rula. urilor de test scade la minim. Evident, începem rularea testelor, • R el a x are î n c e e a c e pr ive ște monitorizarea și apoi extragerea rezulmentenanța serverelor de test pentru că tatelor relevante, a rezultatelor care ne trecând pe Cloud, aceasta grija se exterinteresează de fapt pe noi. nalizează și ea Flow-ul pare relativ ușor și simplu din schema de mai sus dar totuși ar fi câteva Dezavantajele mutării in Cloud sfaturi pentru o migrare cu succes. Unul • Configurația inițială presupune niște dintre acestea este costuri pentru mutarea testelor și adapînțelegerea platfortarea acestora la environmentul nou pe mei pe care se va care Cloud-ul le are. De aici se pleacă de muta testarea și a obicei în luarea unei decizii dacă merită configurației acesschimbat modul de testare curent sau nu; teia. Un alt punct • Securitatea de asemenea poate reprede care trebuie ținut zenta încă o problemă pentru anumite cont înainte să ne tipuri de aplicații; mutam în Cloud este • Rezultate diferite provenite din identificarea tipuriacelași testcase datorate schimbării lor de testare ce se performanței environmentului pe care pretează a fi mutate providerul de servicii le poate avea; din interiorul companiei în exterior. Nu Concluzii toate se pretează sau Vedem în jurul nostru tot mai multe merită a fi mutate. companii care oferă servicii de Cloud, în special de storage. Avem și companii oriAvantajele mutării entate spre servicii mai specializate cum in Cloud ar fi testarea. Decizia de a muta testarea în • C o s t u r i Cloud este până la urmă nu doar o decizie reduse odată mutați ce ține de factori tehnici ci și o decizie de în Cloud; scăpăm de ordin financiar. Avantajele pe termen scurt grija întreținerii unui pentru o aplicație mare probabil nu vor fi Cloud privat atât din vizibile, dar în timp cu siguranță acestea se punct de vedere a vor face simțite, investiția fiind amortizată. resurselor hardware Așadar, ne mutăm testarea în Cloud? cât și a resurselor umane implicate în Referințe: acest scop. http://cloudcomputing.sys-con.com • Spațiu de stohttp://wikipedia.org care foarte mare și http://ieeexplore.ieee.org/xpls/abs_all. accesibil de oriunde; jsp?arnumber=5463680 de p e de v ice-ur i mobile dar și PC-uri • Rularea de Vlad Zeciu vzeciu@smallfootprint.com teste automatizate ce au fost inițial înreSenior QA Engineer @ Small Footprint gistrate și verificate local; • Flexibilitatea www.todaysoftmag.ro | nr. 11/Mai, 2013

Orchestrarea Testării Automate

acebook, Google sau Flickr au posibilitatea de a introduce în producție până la 10 versiuni noi de produs pe zi într-un mod transparent utilizatorilor. În lumea eterogenă și agilă din industria IT, dezvoltarea aplicațiilor și a serviciilor devine o provocare atât datorită diversității tehnologiilor și a produselor, cât și datorită numărului acestora.

Lucian Revnic

lucian.revnic@hp.com OO Content Arhitect @ HP Software Cluj

De asemenea, în companiile software mari unde există departamente de Dezvoltare, Testare și IT implicate în procesul de dezvoltare există nevoia de colaborare strânsă. Pentru asigurarea eficienței colaborarea se realizează prin procese și produse standard care, datorită diversității proceselor și produselor utilizate, devine un obiectiv greu de îndeplinit. Metodologia de dezvoltare care accentuează colaborarea între echipele de Dezvoltare, Testare și IT se numește DevOps. Această metodologie presupune definirea echipelor, a proceselor și a produselor folosite astfel încât ciclul de producție al unei versiuni să fie cât mai scurt. În companiile IT românești, care implementează metodologia DevOps, se folosesc adesea soluții specifice, dezvoltate intern, precum scripturi sau diferite utilitare. În cazul proiectelor dezvoltate în regim de outsourcing acestea depind de procesele și/sau produsele impuse de nevoile și posibilitățile clienților. Departamentul și echipamentele IT sunt situate adeseori într-un centru de date la distanță și care este bazat pe servere fizice, virtuale sau cloud.

Prima problemă o constinuie colaborarea între departamentele implicate. Din acest punct de vedere echipa de dezvoltare are, de exemplu, o viziune a calității diferită de viziunea echipei de testare, echipa de testare asupra implementării iar echipa de IT despre produsul dezvoltat și testat de către echipele anterioare. Echipele au nevoie de un limbaj comun pentru comunicarea eficientă. A doua problemă este aceea de integrare și standardizare a proceselor și produselor utilizate atunci când proiectele, produsele sau clienții se schimbă. Pentru că soluțiile inițiale sunt specifice proiectelor existente, acestea trebuie adaptate noilor cerințe. Costul necesar implementării unei integrări noi este semnificativ și trebuie multiplicat în funcție de numărul de produse noi utilizate și de natura lor. Prezentul articol prezintă o abordare a celor două probleme bazată pe o strategie de testare automată. Soluția denumită TAO se dorește să fie aplicabilă în lumea DevOps și reprezintă un exemplu și nu o soluție absolută. De asemenea, exemplele și tehnologiile referite sunt din lumea Java, iar această opțiune e justificată de experiența autorului în acest domeniu IT.

Strategia

Pentru dezvoltarea unei soluții fiabile și scalabile de testare automată, propunem observarea a trei aspecte: mediul de testare, testabilitatea produsului și integrarea continuă

Mediul de Testare

• Complexitatea – mediul de testare

nr. 11/Mai, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE utilizat variază de la un server fizic, localizat în proximitatea programatorului sau a testerului, până la centre de date complexe, bazate pe tehnologii de virtualizare sau cloud. De multe ori mediul de testare este condiționat de costuri sau de disponibilitatea clienților de aici și de provocarea asupra generalității soluției de testare automată. În categoria produselor gratuite intră VMware Player, Oracle VirtualBox, Linux KVM. Dintre soluțiile comerciale de virtualizare cel mai des întâlnite sunt VMware vCenter, Citrix Xen și Microsoft Hyper-V. Când este vorba de tehnologii cloud Amazon EC2 și implementările OpenStack (cum este HP Cloud) sunt liderii. • Controlul – soluția de testare automată trebuie să prezinte capabilități de bază de control al mediului de testare. Este necesar ca sistemul de testare să permită provision-ul mediului de testare prin acțiuni generice: pornire, oprire, configurare pentru cât mai multe tipuri de medii de test. Pentru aplicatiile care nu oferă un modul de instalare silențios, este util ca mediul de testare să permită revenirea la o stare inițială. Aceasta se poate face prin snapshot-uri sau dispozitive de stocare nepersistente(o astfel de funcționalitate este oferită de VMware vCenter)

Figura 2 Instalarea, configurarea și monitorizarea

Figura 3 Serverul de build invocă testete automate

utilizarea modului silențios de instalare/ dezinstalare, dar există și soluții alternative care se pot utiliza; de ex dispozitivele de stocare non persistente menționate mai sus. Sistemul de testare automată trebuie să permită execuția locală sau la distanță de scripturi: Bash, PowerShell, Python, Perl etc. Pentru conectare la distață acesta trebuie să suporte protocoale precum SSH, WMI etc. . • Configurarea - opțiunile de configurare a aplicației. După instalarea aplicației, pasul următor este configurarea aplicației în vederea execuției testelor automate. Pentru injectarea datelor de test și configurarea aplicației se folosesc frecvent opțiuni precum: interfața utilizator, protocoale web (REST, SOAP), fișiere, baze de date. Tehnologiile implicate adeseori în această fază sunt: Selenium, HP UFT (pentru interfața utilizator), Soap-UI (SOAP), Spring, Apache Http Client (REST). • Monitorizare - modalitățile de observare a stării aplicației: interfața utilizator, baza de date, fișiere log.

Sistemul de testare automată trebuie să obțină rezultatele rulării testelor pentru validare și să notifice echipele implicate asupra rezultatelor rulării testelor. Tehnologiile folosite pentru îndeplinirea acestei sarcini sunt de regulă aceleași cu cele menționate în secțiunile de mai sus.

Integrarea Continuă

Integrarea continuă reprezintă o practică de promovare a unei integrări frecvente a codului sursă într-un sistem de control al versiunilor central, build-ul frecvent al aplicației împreună cu rularea testelor unitare. Aceasta practică recomandă existența unui sistem de build eficient, a unei suite de teste unitate, a unui sistem de control al versiunilor și a unui sistem de notificare. • Sistemul de Build – dintre diversitatea sistemelor am identificat Jenkins, Hudson și CruiseControl ca fiind cele mai utilizate în lumea DevOps. • Integrarea – pentru un proces complet este necesară integrarea dintre sistemul de build, testele unitare și produsele utilizare de echipa de testare

Figura 1 Provizionarea mediului de testare

Testabilitatea Produsului

• Instalarea - modul de instalare și dezinstalare. De multe ori aplicațiile permit un mod de instalare silențios. Trebuie identificați parametri (fișiere, regiștrii, baze de date etc.) modificați în procesul de instalare/dezinstalare. Aceasta este importantă pentru că, într-un sistem de testare automat este imperios necesară instalarea/dezinstalarea a diferitelor versiuni ale aplicației. Este recomandată

Figura 4 Arhitectura generică TAO

www.todaysoftmag.ro | nr. 11/Mai, 2013

QA Orchestrarea Testării Automate (HP ALM/QC, Jira, Selenium, HP UFT) precum și conectarea cu mediul de testare. Comunitățile Jenkins/Hudson oferă extensii pentru diferite integrări precum Jira, Selenium, HP UFT, HP ALM/QC dar există și alte soluții. Considerând toate aceste aspectele menționate, o arhitectură generică de testare automată este ilustrat în Figura 4.

Soluția Noastră

fluxuri care acoperă integrări cu tehnologii precum HTTP, LDAP, SSH, WMI, Ant, PowerShell, integrări cu produse precum HP ALM, Jira dar și cu sisteme de virtualizare și cloud cum ar fi VMware vCenter, Hyper-V, Amazon EC2. Utilizatorul are posibilitatea să folosească fluxurile și operațiile oferite sau să-și creeze unele noi, prin crearea de noi fluxuri. Studio este un mediu vizual de dezvoltare care permite crearea de fluxuri folosind structuri și paradigme împrumutate din programarea orientată obiect precum: structuri de date (liste, șiruri), structuri de control (if, case), reutilizare și încapsulare. Fluxurile dezvoltate și testate în Studio sunt publicate într-o bază de date de unde sunt accesibile folosind o componentă web numită Central. De aici, utilizatorul are posibilitatea să planifice rularea fluxurilor, astfel încât acestea să fie executate de exemplu o dată pe noapte, după fiecare build.

Produsul HP Operations Orchestration(OO) automatizează procesele IT utilizând fluxuri și operații de automatizare. Operațiile sunt acțiuni atomice care realizează sarcini specifice precum Remote Command Execution, SSH Command, SQL Query. Fluxurile sunt secvențe de pași interconectați logic, acestea constituind, în parte, câte o instanță a unei operații. Fluxurile reprezintă procese complexe de automatizare cum ar fi: Server Health Check, Provision Environment, Download and Install Application Build. Rezultate În prezent, produsul oferă o librărie Folosind produsul OO am realigratuită cu mai mult de 4000 de operații și zat o suită de fluxuri de automatizare

nr. 11/Mai, 2013 | www.todaysoftmag.ro

grupate sub numele TAO (Test Atomation Orchestration). Soluția rezolvă problema de colaborare între echipele de dezvoltare, testare și IT, printr-un mediu vizual ușor de utilizat și de înțeles de către persoanele cu minimă experiență în limbajele de programare. Problema de integrare între diferitele tehnologii și produse este rezolvată folosind fluxurile și operațiile oferite de către acest produs. În Figura 5 sunt reprezentate câteva fluxuri utilizate folosind HP Operations Orchestration.

Abordări Similare

Există produse similare care oferă funcționalități asemănătoare cu OO dintre care putem enumera: Electric Commander, Microsoft System Center Orchestrator, UC4. Electric Commander reprezintă, prin numărul de integrări și tehnologii DevOps utilizate (sisteme de build, servera de aplicații, produse de testare), un competitor pentru produsul OO. Ambele produse oferă un mediu de dezvoltare vizual a fluxurilor, opțiuni de planificare a rulării acestora și sisteme de raportare și

TODAY SOFTWARE MAGAZINE

Figura 5 Fluxuri HP Operations Orchestration

monitorizare. Pe de altă parte, OO oferă un set de fluxuri mult mai extins pentru provizionare și integrare cu alte produse precum Jira, HP ALM/QC, Amazon EC, HP Server Automation etc.

Viitorul

Următorii noștri pași sunt extinderea fluxurilor TAO care sunt necesare în diferitele scenarii DevOps precum integrarea cu produse de analiză a codului (Sonar) și cu aplicații de provizionare opensource. Ne propunem să creștem gradul de conștientizare a calităților produsului HP Operations Orchestration în general și a soluției TAO în particular prin crearea

unei comunități publice care să înlesnească DevOps Webpage, November 2012. și să încurajeze accesul la fluxurile deja existente.

Referințe HP Operations Orchestration, Official Webpage, Hewlett-Packard, November 2012, H P O p e r at i on s O rc h e s t r at i on , Concepts Guide, Hewlett-Packard, June 2010, Electric Commander, Official Webpage, Electric Cloud, November 2012, Top 10 Virtualization Technology Companies Webpage, Keneth Hess, 2010, Wikipedia, The Free Encyclopedia

www.todaysoftmag.ro | nr. 11/Mai, 2013

management

OPTIONSABILITY O caracteristică discretă a proiectelor IT

Bogdan Matei

bogdan.matei@3pillarglobal.com Senior Php Developer @ 3Pillar Global

privire de ansamblu asupra actualității sociale și profesionale ne relevă o evoluție mai degrabă exponențială, mai ales pe ultimii douăzeci de ani, care face ca astăzi beneficiile și standardele pentru persoana noastră să fie foarte ridicate. Dincolo de schimbările evident perceptibile, dinamica și amploarea acestor evenimente a făcut ca în ultimii ani să aibă loc și o importantă, dar subtilă, schimbare a poziționării accentului: contează realizările, dar, mai mult decât atât, astăzi, contează opțiunile pe care le ai. Dacă mai sunt și domenii în care acest lucru este mai puțin valabil, în IT această concluzie este cât se poate de reală și prezentă. Revenind la proiectele IT, probabil majoritatea, clienți și furnizori de soluții, ar defini o relație de succes când livrarea produsului s-a făcut la timp, în bugetul alocat și a îndeplinit așteptările legate de funcționalitate și calitate. Majoritatea managerilor ar considera că proiectul s-a terminat cu bine și și-ar îndrepta atenția spre o nouă provocare. În realitate însă, perioada imediat următoare livrării este un punct critic, acolo unde oportunitățile apar, atât pentru client (beneficiarul produsului software), cât și pentru furnizor. Scopul acestui articol este să demonstreze de ce este important acest moment, cui îi revine responsabilitatea lui și de ce merită tratat că un scop în sine al proiectului încă din faza inițială a semnării contractului. În general, la modul complet generic, înțelegerea și realizarea unui proiect software adună împreună, ca echipa funcțională, trei părți:

Analizând proiectele de succes și mai detaliat, se constată însă că, dincolo de diferențele de tehnologie, metodologie și de process, succesul lor se datorează unei proprietăți căreia, negăsindu-i un nume definitoriu, i-am spus “optionsability”. Se definește ca proprietatea de a avea și furniza opțiuni. Relația funcțională între părți se transformă puțin și încearcă astfel să anticipeze drumul proiectului:

Cum nehotărârea clientului este un fapt destul de comun iar managementul riguros și pragmatic, componenta tehnică își cunoaște în schimb rolul precis. Dacă pentru obiectiv sau produs toate părțile se îngrijesc consecvent, responsabilitatea pentru “optionsability” revine: ….developerilor și arhitecților ca și o echipă. Subliniez rolul developerilor pentru că un plan bun poate avea o implementare corectă, dar rigidă, iar ei sunt cei care iau această decizie, voluntar

nr. 11/Mai, 2013 | www.todaysoftmag.ro

programare sau imperceptibil. Așadar, la nivel local, are loc construcția unei proprietăți importante a proiectului, fiind un eveniment continuu, atașat fazei dezvoltării proiectului. Ideal ar fi ca și clientul să contureze direcții de deschidere ale unor viitoare opțiuni, dar în practică acest lucru este mai rar ceea ce face ca rolul tehnicienilor cu atât mai important. Și managerii au un rol important, prin atenția continuă pentru menținerea proiectului în timp, buget și functionalitatea cerută. Am definit proprietatea, i-am exprimat durata de viață, am găsit responsabilii, dar de ce este ea importantă și pentru cine? Pentru a răspunde de ce este suficientă o privire mai atentă asupra produselor care se bucură azi de succes: SUVs, smartphones, smart TVs, mobilierul modern (gen Ikea), articolele pentru sport, uneltele de bricolaj etc. și chiar tendințele din IT (Facebook, WhatsApp, iTunes etc). Aspectul unui produs (designul) și calitatea materialelor (sau implementarea) de obicei califică un produs spre atracția și afectivitatea consumatorilor (devin interesați de el), însă cele care construiesc legătura de succes sunt opțiunile pe care produsul le oferă. Uneori opțiunile oferite reușesc singure să decidă asupra succesului. Majoritatea avem sau vom avea copii. După ce am realizat mai multe rateuri la cumpărarea jucăriilor, am constatat că, inclusiv de la vârste mici, alegerile se fac în mod natural după opțiunile disponibile. Nu cred că are rost să detaliez ce opțiuni au Spiderman, Batman, Ironman, eroii din Star Wars și Transformers… În ceea ce privește răspunsul la întrebarea “pentru cine?”, rezultatul este simplu dar surprinzător: pentru toți.

TODAY SOFTWARE MAGAZINE Pentru client, implicat în comunitatea afacerilor, opțiunile sunt mai importante decât realizările în sine, în special în momente de criză, când posibilitățile scad. Un argument în acest sens este evoluția acțiunilor Apple în ultimul an, deși compania a raportat record la profitabilitate. A avea optiuni a ajuns să reprezinte un avantaj mai important decât a avea realizari în sine. Opțiunile sunt pentru afacere un rezervor de siguranță, o margine de flexibilitate, iar pentru proprietarul ei un confort care furnizează sentimentul încrederii și libertății. În sine, aceste detalii pot parea lucruri nesemnificative, însă ele sunt motoarele care produc consecințe în deciziile importante. Prin îndreptarea atenției și dincolo de scopul proiectului, către opțiuni, pe termen scurt este posibil să apară și o creștere a costurilor, datorită necesităților de calificare mai ridicată și a schimbărilor de mentalitate necesare. Această mentalitate de a te gândi la opțiuni, nu implică neapărat implementarea lor, ci doar o pregătire prealabilă, încă din faza concepției tehnice, pentru unele dintre ele - cele mai susceptibile să fie cerute sau avantajoase. Pentru selectarea lor este nevoie de comunicare între părți și o cunoaștere atentă. Pe termen lung însă (peste 1 an), câștigurile sunt incomparabile: • crește eficiența prin reducerea timpului petrecut pentru “reinventarea roții”; • se realizează o bază de cunoștiințe și unelte (re)utilizabile; • scade necesitatea rescrierii proiectelor (coșmarul clienților); • ajută la realizarea mult doritelor “best practice”;

• scade timpul dezvoltărilor, compensate de adaptări și integrare a ceea ce există facut; • integrarea juniorilor sau a noilor veniți se face mai rapid; • estimarile sunt mai precise. Un motiv deloc de neglijat este și cresterea aprecierii clienților, care ajung să se consulte cu tine, să te recomande și să aibă încredere în relația de afaceri avută împreună. În timp, rezultatele gândirii cu “optionsability” se transpun în reputația companiei. Pentru echipa tehnică, avantajele sunt de asemenea considerabile: crește nivelul de profesionalism, cu implicare mai mare inclusiv în contextul de business (developerul se pune mai concret în pielea clientului și caută solutii și posibilități), scrierea de cod devine mai provocatoare. A face o arhitectură flexibilă sau a scrie cod usor de citit, reutilizabil și robust este mai entuziasmant și mai folositor. Odata codul scris astfel se adună o baza reutilizabilă, crește încrederea și se reduce stresul necunoscutelor, estimările sunt o mai mică problemă. Juniorii au de asemenea un model mai bun decât clasicul “încercare-greșeală”. Pentru echipa marketing, opțiunile sunt materie primă de cea mai bună calitate. Luați spre exemplu cele mai cunoscute produse: Coca-Cola, BMW, Audi, Starbucks etc. Aproape că nu se promovează produsele în sine, ci direct opțiunile sau emoții aduse de opțiunile produselor. Opțiunile ajută specialiștii în marketing să conceapă reclame mai atractive și mai eficiente, prin focalizarea mesajelor pe opțiunile pe care oamenii le apreciază cel mai mult, dar, atenție, oferite de produs.

www.todaysoftmag.ro | nr. 11/Mai, 2013

management OPTIONSABILITY - O caracteristică discretă a proiectelor IT Pentru consumatorul final a avea opțiuni este o justificare retorică. Cu cât sunt mai educați, cu atât oamenii realizează importanța optiunilor în detrimentul activelor concrete (bunuri, bani etc.). Opțiunile sunt văzute ca o soluție sau speranță spre eficiență, performanță sau divertisment. Probabil până în acest moment am lămurit aspectele definitorii ale acestei proprietăți, dar ceea ce este mult mai important este punerea în practică. Ca orice schimbare de mentalitate nu cred că este realist de așteptat o aderență imediată și generală la toate persoanele implicate. Această mentalitate necesită mai multă creativitate și pasiune (sau responsabilitate mai ridicată). Întrucât principalii responsabili sunt tehnicienii, adeziunea lor la acest mod de a gândi este determinantă. Ei trebuie să aibă o bună cunoaștere a scopului proiectului, de asemenea și o înțelegere măcar prealabilă a domeniului proiectului, și să-și valorifice competențele tehnice punându-se mai ales în poziția utilizatorilor acelui produs. Trebuie să

caute permanent înțelegerea unor posibile evoluții a proiectului, să le sintetizeze în idei care se transpun în implementări clare și ușor gestionabile (citire, utilizare, verificare, monitorizare, reutilizare, adaptare, extindere, (dez)activare). Tehnologic există multiple ajutoare în acest sens, de la „design patterns” la metodologii și procese. „Agile” are o mare contribuție. Cea mai bună, scurtă și concretă recomandare pe care pot s-o dau în acest sens este că implementarea unei soluții software este direct proporțională cu usurința comunicarii ei pe înțelesul părților implicate în acel domeniu. Codul este oglinda unei exprimari ideologice, relative la o cerință sau caracteristică naturală. Metaforic vorbind scrierea unei porțiuni de cod ar trebui făcută precum realizarea unui reportaj asupra unui peisaj. De obicei, peisajele au o construcție închegată și astfel se concepe un proiect. Implementarea proiectelor cu “optionsability” ca al doilea scop nu este aplicabilă tuturor proiectelor! Nu vine ca o rețetă

nr. 11/Mai, 2013 | www.todaysoftmag.ro

prestabilită. Ea depinde foarte mult de context, de o analiză obiectivă a câștigurilor și costurilor. Din experiență, ea se pretează foarte bine proiectelor cu durată de viață mare, cu necesități de actualizare și mentenanță frecvente sau proiectelor de tip fundație pentru alte proiecte. Deciziile asupra opțiunilor pregătite se iau pas cu pas și argumentat, iar confirmarea că drumul este bun se observă prin o stabilitate ridicată a calității proiectului, o ușurare în adaptarea la schimbări și o cunoștință de cauză mai bună asupra implicațiilor.

programare

TODAY SOFTWARE MAGAZINE

Dezvoltarea de aplicații safetycritical în SCADE

Hunor Csomortani

csmortani.hunor@evoline.ro Software Developer @ evoline

erințele impuse de standardele în domeniu fac ca dezvoltarea aplicațiilor critice din punctul de vedere al securității (safety-critical software) să reprezinte o provocare continuă pentru toți participanții în proces. Mediul de dezvoltare SCADE impune rigurozitatea necesară pentru aceste proiecte chiar de la începutul dezvoltării. Bazându-se pe un limbaj sincron, determinist, cu generator de cod C certificat și un set de instrumente care facilitează testarea și verificarea produsului, SCADE permite să ne concentrăm la implementarea cerințelor de nivel înalt, și ne scapă de grija comiterii greșelilor de bază. Articolul propune să facă o scurtă prezentare a mediului de dezvoltare, prezentând avantajele, dezavantajele și provocările la care programatorul trebuie să facă față.

Mediul de dezvoltare SCADE

Mediul de dezvoltare SCADE se bazează pe limbajul Scade, limbaj sincron conceput pentru dezvoltarea sistemelor reactive. Extensia oferită de SCADE acestui limbaj este un mediu de dezvoltare grafică, care permite modelarea aplicației într-un mod foarte asemănător proiectării circuitelor integrate. Dezvoltarea în SCADE înseamnă crearea unor operatori, prezentând funcționalitatea acestora pe diagrame, folosind un set de operatori predefiniți. Diagramele pot fi de tip data flow sau control flow (automate finite), fiind posibilă și combinarea acestor două abordări. Prin legarea operatorilor se creează modelul unei aplicații reactive, menit să fie rulat ciclic, la începutul fiecărui ciclu citind valorile de intrare și calculând valorile de ieșire, luând în considerare și stările interioare al

sistemului. Tipurile de date disponibile sunt cele de bază (int, real, char, bool), având posibilitatea de a defini propriile tipuri compuse (șiruri, enumerări, structuri) sau a importa tipuri declarate în C sau C++. La fel este posibil și folosirea unor operatori importați, a căror funcționalitate este implementată în alte limbaje de programare. Sincronicitatea modelului înseamnă că rezultatele calculate sunt independente de ordinea de execuție, ele având o singură valoare posibilă în cadrul unui ciclu. Astfel concepția de ”timp” poate fi omisă – o abstractizare utilă în cazul sistemelor reactive, având ca rezultat un timp finit de execuție a aplicației, care respectă constrângerile mediului de operare. SCADE impune aceste constrângeri teoretice în timpul modelării, dar și printr-un pas de verificare a modelului creat. Aceasta din urmă asigură corectitudinea designului creat din toate punctele de vedere, având un rol asemănător unui compilator. La capitolul de verificare putem folosi simulatorul pentru a pune modelul creat

www.todaysoftmag.ro | nr. 11/Mai, 2013

programare Dezvoltarea de aplicații safety-critical în SCADE în mișcare. Setând valori pentru interfețele de intrare se poate Operatorul RisingEdge din exemplul precedent este transforverifica starea celei mai mici părți al acestuia: valorile variabile- mată în următoarea funcție C: lor, al fluxurilor de date între operatori și în interiorul acestora, /* Playground::RisingEdge */ tranzițiile și stările active al automatelor finite. void RisingEdge_Playground(

Exemplu De exemplu, să modelăm o aplicație care controlează un sistem de închidere. Să fie valoarea de intrare starea unui buton de comandă (apăsat sau nu), iar valoarea de ieșire comanda de închidere sau deschidere. Primul operator va transforma starea butonului într-o valoare rising edge: true numai în cazul în care starea butonului se schimbă din neapăsat în apăsat. Funcționalitatea poate fi modelată în modul următor:

{

}

inC_RisingEdge_Playground *inC, outC_RisingEdge_Playground *outC) kcg_bool tmp;

if (kcg_cond(outC->init)) { outC->init = kcg_false; tmp = kcg_not(inC->btnPressed); } else { tmp = kcg_not(outC->rem_btnPressed); } outC->isRising = kcg_and(tmp, inC->btnPressed); outC->rem_btnPressed = inC->btnPressed;

Avantaje

Prin dezvoltarea în SCADE se poate asigura un nivel de calitate ridicat al aplicației pe tot parcursul procesului de dezvoltare, nefiind necesară folosirea altor instrumente în acest sens. Constrângerile teoretice al sincronicității, aplicate din priÎn celălalt operator modelăm stările sistemului (închis/des- mul moment, oferă siguranța că rezultatul va face față cerințelor chis), și tranzițiile posibile între aceste stări, cu ajutorul unui impuse aplicațiilor safety-critical: sistemul va avea o stare bine automat finit. Condiția de activare a tranzițiilor este valuarea true definită în toate condițiile și va reacționa într-un timp finit, ușor a variabilei command. de definit și măsurat. În același timp diagramele sunt suficient de

În pasul următor putem lega cei doi operatori, creând modelul aplicației.

Generare de cod C

Cu ajutorul generatorului de cod KCG putem transforma modelele create într-un cod C compilabil, lipsit de erori low level de programare. Deoarece precondiția generării este un model valid, codul C păstrează calitățile teoretice – sincronicitate, determinism – al acestuia. Integrarea codului se realizează prin apelarea funcțiilor C generate. Se poate crea o clasă wrapper, care să reprezinte interfața între funcțiile C și restul aplicației, creând un singur punct de dependență față de codul generat. Această abordare ne permite ca fișierele C să devină obiecte temporare în procesul de build, modelul SCADE preluând rolul de cod sursă. Generatorul este certificat conform mai multor standarde de securitate din industrie: DO-178B (aplicații din domeniul aeronauticii și apărării), EN 50128 (aplicații din domeniul transportul feroviar), IEC 61508 (aplicații din domeniul industriei și energeticii) ș.a.m.d., lucru care facilitează procesul de acceptanță a sistemelor dezvoltate cu ajutorul SCADE.

nr. 11/Mai, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE auto-explicative ca să reprezinte un mijloc Provocări bun de comunicare între participanții în Cea mai mare provocare la care proproiect. gramatorul trebuie să facă față este să se obișnuiască cu abordarea sincronă. Foarte Dezavantaje multe constrângeri, care în alte limbaje pot Punctele forte uneori însă devin și cele fi impuse numai prin tool-uri separate sau slabe: abordarea grafică cere o atenție mult o arhitectură vizată, în SCADE constituie mai mare în cazul dezvoltării în echipă. o parte integrantă a limbajului de bază și În timp ce pentru obiectele textuale avem a mediului de dezvoltare, ruperea acestora la dispoziție instrumente mature pentru fiind imposibilă chiar și în cazuri în care a îmbina progresul făcut de mai mulți acesta ar fi un lucru dorit. participanți, în cazul diagramelor grafice acest lucru este o provocare continuă, lucru Concluzii imposibil uneori, și o situație mai bine de Bazându-se pe un limbaj sincron, evitat. SCADE impune ca însușirile cele mai Din cauza rigurozității limbajului, importante ale aplicațiilor reactive – timp dependințele dintre fișierele de model sunt finit de execuție și stări bine definite în toate mult mai mari: de exemplu, interfețele între condițiile – să fie respectate pe tot parcuroperatori trebuie să corespundă în mod sul procesului de dezvoltare. Generatorul exact pentru a avea un model valid, ceea ce de cod certificat facilitează transformarea necesită o cooperare mult mai strânsă între modelelor create în cod C și integrarea în dezvoltatori. restul sistemului. Cu toate dezavantajele SCADE ne oferă soluții limitate și de sale, mediul de dezvoltare SCADE este o cele mai multe ori foarte greoaie pentru a soluție matură și potrivită pentru dezvoltrata structuri de date foarte mari și com- tarea aplicațiilor safety-critical. plexe. La fel, nu este soluția ideală pentru dezvoltarea aplicațiilor care implică efectuarea unor calcule intensive.

www.todaysoftmag.ro | nr. 11/Mai, 2013

programare

Trenduri și Big Data

u toții am auzit de trenduri. Avem trenduri în muzică, în modă și bineînțeles în IT. Pentru anul 2013, au fost anunțate mai multe trenduri, care la ora actuală fac deja parte din viața noastră. Câți din noi nu am auzit de cloud, machine to machine (M2M) sau NoSQL. Toate acestea sunt trenduri care au pătruns în viața noastră, făcând parte din cotidian. Big Data este un trend care s-a manifestat și anul trecut, menținându-se printre cele mai puternice trend-uri și în acest an. Radu Vunvulea

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

În cadrul următoarei serii de articole doresc să vorbesc despre Hadoop. De ce? Big Data nu există fără Hadoop. Big Data ar fi doar o mulțime de octeți pe care clientul nu ar ști cum să îi proceseze. Clienți au început de mult timp să ceară o modalitate scalabilă prin care să putem procesa datele. În cazul sistemelor clasice, procesarea a 50T de date devine o problemă. Sistemele de calcul pentru indexarea și procesarea acestui volum de date este extrem de costisitoare - nu doar financiar cât și din punct de vedere a timpului.

La ora actuala Hadoop este una (dacă nu chiar cea mai bună) soluție de procesare a unui volum mare de date. Înainte de toate să vedem cum a apărut și cum a ajuns să fiu un sistem care poate să ruleze distribuit pe 40.000 de instanțe fără nici un fel de probleme.

Puțină istorie

În urmă cu câțiva ani (2003-2004), Google a publicat un articol despre modul în care face față la cantitatea imensă de

nr. 11/Mai, 2013 | www.todaysoftmag.ro

date pe care trebuie să o proceseze. Acesta a explicat ce soluție folosește pentru a putea procesa și stoca un volum mare de date. Fiind în era web, iar numărul de site-uri și de date disponibile pe internet era foarte mare - nu doar că era mare, dar creștea amețitor (și continuă să crească), Apache Software Foundation inspirându-se din articolele publicate de către Google, ajută la creare Apache Hadoop. Putem spune că acest articol a devenit standardul pentru stocarea, procesarea și analiza datelor. Doua caracteristici foarte importante pentru care Hadoop este la ora actuală un sistem pe care multe companii îl adoptă pentru procesarea Big Data sunt scalabilitatea și modul unic prin care datele sunt procesate și stocate. Pe toată perioada dezvoltării acestui sistem Hadoop a fost și va rămâne un proiect open-source. La început a fost sprijinit de Yahoo, care avea nevoie de un sistem de indexare pentru motorul de căutare pe care îl au. Acesta sistem ajunge să funcționeze atât de bine încât ajunge să fie folosit de către Yahoo și pentru publicitate. Un lucru extrem de interesant este că Hadoop nu a apărut peste noapte, iar la început nu era un sistem atât de robust

management

TODAY SOFTWARE MAGAZINE

extrem de costisitor, preț și întreținere. HDFS este un sistem care nu are nevoie de hardware special. Rulează fără probleme pe configurații normale, putând fi folosit împreuna cu calculatoarele pe care le avem acasă sau la birou.

pentru a le procesa, acestea ne trimit datele stocate. HDFS este total diferit. Din cauza că lucrează cu cantități de date extrem de mari, modul în care rezolvă această problemă este inovator. Orice sistem am folosi, am avea probleme în momentul în care dorim să transferăm cantități mari de date pentru procesare. HDSF ne permite în schimb să trimitem pe componentele unde datele sunt stocate logica de procesare. Prin acest mecanism, datele de procesat nu mai sunt transferate și doar rezultatul final trebuie să fie trimis mai departe – doar când este nevoie. Într-un astfel de sistem v-ați aștepta la un sistem cu un mecanism de versionare extrem de complex. Un sistem care să ne permite să avem mai multe surse care scriu în același fișier. De fapt HDSF este un sistem de stocare care permite să avem un singur writer și oricâți cititori. Este gândit în acest mod din cauză tipului de date care sunt stocate. Aceste date nu sunt date care se schimbă des, care să necesite modificări. De exemplu log-urile unei aplicații nu vor fi modificate, același lucru se întâmplă și cu datele obținute în urma unui audit. De foarte multe ori datele care ajung să fie stocate, odată ce sunt procesate ajung să fie șterse și niciodată modificate.

1. Management la sub-sisteme

3. Portabilitate

Poate una din cele mai importante proprietăți ale acestui sistem este modul în care orice problemă hardware este privită. De la bun început acest sistem a fost gândit să ruleze pe zeci, sute de instanțe, din această cauză orice problemă hardware care poate să apară nu este privită ca o eroare, ca o excepție de la flow-ul normal. HDFS este un sistem care știe că nu toate componentele înregistrate în sistem vor funcționa. Fiind un sistem care este conștient de acest lucru, este mereu pregătit să detecteze orice problemă apărută și să înceapă procedura de recuperare. Fiecare componentă din sistem, stochează o parte din fișiere, iar fiecare bit stocat, acesta poate să fie replicat într-una sau mai multe locații. HDFS este văzut ca un sistem care este folosit pentru stocare fișierelor care au de la câțiva giga și ajung de dimensiunea câtorva tera. Acest sistem este pregătit pentru a putea distribui un fișier pe una sau mai multe instanțe.

Înainte să vorbim despre arhitectura acestui sistem și modul în care lucrează, aș vrea să discutăm din nou despre o altă proprietate pe care acest sistem o are – portabilitatea. Din această cauză HDSF este un sistem care este folosit nu doar împreună cu Hadoop cât și ca un sistem de stocare a datelor. Cred că această proprietate l-a ajutat să fie atât de răspândit. Din punct de vede software, acesta este scris în Java și poate să ruleze pe orice fel de sistem.

Figură 1: Ecosistemul Hadoop

precum este astăzi. La început scalabilitate era o problemă, în momentul când era nevoie să scaleze mai mult de 10-20 de noduri. Același lucru se întâmpla în ceea ce privește performanța, unde nu excela. Companii precum Yahoo, IBM, Cloudera, Hortonworks au văzut valoarea pe care Hadoop o aduce și au investit în el. Fiecare din aceste companii aveau un sistem asemănător, care încerca să rezolve aceeași problemă. La ora actuală acesta ajunge să fie un sistem robust care poate să fie folosit cu succes. Companii precum Yahoo, Facebook, IBM, ebay, Twitter, Amazon îl folosesc fără nici un fel de problemă. Deoarece în Hadoop datele pot să fie stocate extrem de simplu, iar odată informația procesată ajungă să ocupe foarte puțin spațiu, orice sistem legacy sau orice sistem extrem de mare poate să stocheze datele pe termen lung foarte ușor și cu costuri minime.

Stocarea datelor - HDFS

Modul în care este construit Hadoop este extrem de interesant. Fiecare parte din el este gândită pentru ceva mare, de la sistemul de stocare de fișiere, la modul de procesare sau de scalabilitate. Unul din cele mai importate și interesante componente pe care Hadoop le are este sistemul de stocare a fișierelor - Hadoop Distributed File System (HDFS). În general, când vorbim de sisteme de stocare cu capacități foarte mari, gândul ne zboară la hardware custom care este

4. NameNode și DataNode

Dacă analizăm arhitectura unui astfel de sistem este necesar să introducem în vocabularul nostru doi termeni: NameNode și DataNode. Este un sistem de tip master-slave. NameNode este „the master” sistemului de stocare. Acesta se ocupă de sistemul de stocarea a numelui fiecărui fișier și știe unde poate să fie găsit – maparea fișierelor. Acest sistem nu stochează datele din 2. Accesul la date fișierele, el doar ocupându-se cu maparea Sistemele normale de stocare de fișiere fișierelor, știind în fiecare moment locație au ca principal scop stocarea datelor, iar în unde aceste sunt stocate. Odată ce numele a cazul în care avem nevoie de aceste date fost rezolvat de către NameNode, acesta va www.todaysoftmag.ro | nr. 11/Mai, 2013

programare Trenduri și Big Data redirecta clienții spre DataNode-uri. DataNode reprezintă „slave-urile” care stochează conținutul propriu zis al fișierului. Clienți vor accesa DataNode pentru a putea accesa informația stocată – scriere și citire a datelor. Fiind un sistem care este pregătit pentru ca o componentă să cadă, pe lângă NameNode, avem un Seccondary NameNode. Acestă componentă face în mod automat checkpoint-uri la NameNode, iar în cazul în care se întamplă ceva cu NameNode-ul, această componentă este pregătită să ofere checkpoint-ul pentru a se putea restaura starea pe care NameNode-ul a avut-o înainte să cadă. Trebuie remarcat că Seccondary NameNode nu va prelua niciodată funcția pe care NameNode-ul o are. Acesta nu va rezolva locația unde fișierele sunt stocate. Singurul său scop este de a crea checkpointuri pentru NameNode.

5. Stocarea datelor Toate datele care sunt stocate sunt sub forma fișierelor. Pentru client, un fișier nu este împărțit în mai multe parți, chiar dacă intern acest lucru se întâmplă. Intern, fiecare fișier este împărțit în blocuri care ajung să fie stocate pe unul sau mai multe DataNode-uri. Un fișier foarte mare poate să fie stocat pe 2, 3 sau chiar 20 de noduri. NameSpace-ul controlează acest lucru, putând cere ca block-urile să fie replicate în mai multe locații. În Figura 2 se poate vedea arhitectura acestui sistem. Ceea ce este interesant la această arhitectură este modul în care se lucrează cu fișiere. Datele pe care clienții le accesează nu trec niciodată prin NameNode. Din această cauză, chiar dacă avem un singur NameNode în tot sistemul, odată ce s-a rezolvat locația fișierelor, nici o cerere de la client nu mai trebuie să treacă

Figura 2

prin NameNode.

6. Structura fișierelor

să ajungă să fie mutate automat într-un alt DateNod în cazul în care se detectează că datele nu sunt distribuite uniform. Toate copiile care există pentru un fișier sunt folosite. În funcție de locația de unde se dorește să se acceseze aceste date, clientul vor avea acces la copia care se află cel mai aproape de el. Din această cauză, HDSF este un sistem care știe cum arată rețeaua sa internă – incluzând fiecare DataNode, rack și restul sistemelor.

Modul în care fișierele sunt stocate pentru a putea fi accesate de către clienți este foarte simplu. Clientul își poate defini o structură de directoare și fișiere. Toate aceste date sunt stocate de către NameNode. Acesta este singurul care știe modul în care directoarele și fișierele sunt definite de clienți. Opțiuni precum hardlink sau soft-link nu sunt suportate de către HDFS. 8. Namespace Namespace-ul pe care NameNode-ul îl 7. Replicare are este stocat în memorie RAM, putând să Deoarece datele stocate sunt foarte fie accesat cu ușurință. Acesta este replicat importante, HDFS ne permite să setăm pe hard disk la intervale foarte bine stabinumărul de copii pe care dorim să le avem lite – numele imaginilor care se scriu pe pentru fiecare fișier. Acesta se poate seta în disk poartă numele de FsImage. Din cauză momentul în care creăm fișierul sau ori- că copia de pe disk nu este 1 la 1 cu cea când după acest moment. NameNode-ul din memoria RAM, există un fișier în care este cel care cunoaște numărul de copii care sunt scrise toate modificările care se fac trebuie să existe pentru fiecare fișier și are asupra structurii fișierelor sau a directoagrijă ca acesta să existe. relor - EditLog. Prin acest mod în cazul în De exemplu când creștem numărul de care se întâmplă ceva cu memoria RAM replicări pe care dorim să le avem pentru sau cu NameNode-ul, recuperarea acestuia un fișier NameNode-ul o să aibă grijă ca este simplă și poate să conțină și ultimele toate blocurile de date să fie replicate încă o modificări. dată. Treaba NameNode-ului nu se termină în acest moment. De la fiecare bloc în parte 9. Manipulare date acesta primește un semnal de tip „sunt Un lucru extrem de interesant este în viață” la un interval specific de timp – modul în care un client poate să creeze un heardbeat. În cazul în care unul din blocuri fișier. Inițial, datele nu sunt stocate direct nu trimite acest semnal, NameNode-ul va in DataNode, ci într-o locație temporară. înceape procedura de recuperare în mod Doar în momentul în care există destule automat. date pentru ca o operație de scriere să Modul în care datele se replică este merite, doar atunci NameNode-ul este extrem de complex. HDSF trebuie să țină notificat și copiază informația in DataNode. cont de foarte mulți factori. În momentul În momentul în care un client dorește în care este nevoie să se facă o noua copie, să șteargă un fișier, acesta nu este șters fizic trebuie ținut cont că aceasta acțiune o să din sistem. Fișierul este doar marcat penconsume lățimea de bandă. Din acestă tru ștergere și mutat în directorul trash. cauză avem un load-balancer care se ocupă În trash este ținută doar ultima copie a de distribuirea datelor în cluster. Există fișierului, iar clientul poate să intre în acest mai multe opțiuni director pentru a o recupera. Toate fișierele pentru replicare, din trash sunt șterse în mod automat după una din cele mai un anumit interval de timp. des întâlnite este în care 30% din Concluzie replici să fie pe În cadrul acestui articol, am preacelași nod. Din zentat cum a apărut Hadoop, care sunt punct de vedere a proprietățile sale principale și modul în ldistribuirii replicare datele sunt stocate. Am văzut ca HDFS cilor pe rack-uri , este un sistem creat să lucreze cu multe doua treimi sunt date. Acest lucru îl face extrem de bine și pe același rack, cu costuri minime. iar cealaltă parte În următorul număr vom vedea cum este pe un rack putem să procesăm această informație. separat. Datele dintrun DateNod pot

nr. 11/Mai, 2013 | www.todaysoftmag.ro

programare

TODAY SOFTWARE MAGAZINE

Programare Funcțională în Haskell

lan Perlis zicea că un limbaj care nu afectează modul în care gândim nu merită cunoscut. Judecând după numărul mare de întrebări pe Stack Overflow corelat cu numărul impresionant de articole, publicații și postări pe reddit, Slashdot și bloguri, este evident că limbajul Haskell este un limbaj ce merită cunoscut. De fapt, programarea funcțională în sine reprezintă un domeniu pe care fiecare programator ar trebui să-l cunoască puțin. Istoria a făcut ca limbajele de programare răspândite acum să fie cele din paradigma imperativă. Codul scris de un programator nu este altceva decât un set de instrucțiuni și ordine date calculatorului. Dar foarte puțini știu că paradigma imperativă nu reprezintă decât unul dintre cele patru modele de calcul inventate de matematicienii ce au pus bazele științei calculatoarelor. Foarte diferite, aceste paradigme au totuși un lucru în comun: conform tezei Church-Turing nici o paradigmă nu poate rezolva mai multe probleme decât alta. Cu toate acestea unele programe sunt mai ușor de scris într-o manieră imperativă în timp ce altele sunt mai ușor de descris într-un limbaj declarativ. Acest lucru este vizibil în însăși preferința programatorilor de azi: deși toate paradigmele au apărut în aproximativ același an, faptul că este mult mai simplu de făcut un calculator pe modelul von Neumann a făcut ca cea imperativă să domine lumea limbajelor de programare mult timp. Cu toate acestea, celelalte și-au găsit și ele rolul, în special în inteligența artificială. Utilizarea îndelungată a limbajului LISP, cel mai vechi limbaj de programare, se datorează și contribuției lui John McCarthy și a inteligenței artificiale. Un moment important este dat de publicarea articolului lui John Bachus Poate fi programarea eliberată de stilul von Neumann? Stilul funcțional și o algebră a programelor. Acesta aduce la lumină un punct important: programele funcționale se pot compune mult mai ușor din asamblarea unor componente testate anterior. Practic, acest articol a produs apariția unor limbaje funcționale noi pe lângă LISP. Astfel, în anii 1970 au apărut nu mai puțin de 10 limbaje de programare funcționale

noi. Dintre acestea, limbajele din categoria ML reprezintă un interes major prin două limbaje: OCaml folosit și în prezent și Miranda. De la aceste limbaje au pornit în anii 1990 și programatorii adunați într-un comitet creat special pentru inventarea unui limbaj de programare ce ar trebui văzut ca un standard deschis pentru cercetarea în domeniul limbajelor de programare (nu doar funcționale) și al compilatoarelor: Haskell. Cu timpul Haskell a reușit să ajungă un limbaj de programare puternic, destul de folosit în domenii diverse precum inteligența artificială, securitate, dezvoltarea aplicațiilor web sau a sistemelor de operare. Multe din noutățile ce au fost introduse în limbaj au ajuns mai târziu și în C++, Java, etc. . Această dezvoltare se datorează atât comunității create în jurul limbajului (canalul de IRC #haskell de pe Freenode, grup special pe Reddit și Stack Overflow, o mulțime de bloguri colectate săptămânal de Haskell Weekly News și bianual de Haskell Communities and Activities Report) cât și facilității cu care poate fi învățat limbajul folosind resurse online (The Monad Reader, wiki-uri și wikibooks, etc.). Nume celebre din industria IT folosesc în prezent Haskell sau în producție sau pentru dezvoltare locală: NASA, Galois, Facebook, Google, Microsoft, Jane Street, etc. Primul interpretor pentru Perl6 a fost scris integral în Haskell. Instrumente pentru validarea automată a programelor sau demonstrarea de teoreme sunt dezvoltate în Haskell (uneori împreună cu Ocaml). Dar ce are limbajul atât de atrăgător? Majoritatea celor care îl folosesc se vor lega de două aspecte: stilul declarativ și garanția

unei anumite corectitudini a codului. Programele scrise în limbaje funcționale sunt extrem de concise, se pune accentul pe ce ar trebui să facă secvența de cod, nu pe cum ar trebui să facă aceasta. De exemplu, secvența următoare sortează o listă de elemente cu un algoritm de tip quick-sort (se alege mereu drept pivot primul element din lista sortată): sort [] = [] sort (x:xs) = lesser ++ x:greater where lesser = sort [a | a <- xs, a < x] greater = sort [a | a <- xs, a >= x]

Comparați lungimea acestui cod cu cea a unui program similar scris în limbajul de programare favorit. În mod cert, stilul funcțional beneficiază de aspectul declarativ: codul este mai ușor de citit, elemente necunoscute de sintaxă pot fi deduse din context, corectitudinea este ușor de validat. Pentru a veni în ajutorul validării corectitudinii programului, Haskell are tipare statice: fiecare expresie are un tip cunoscut de la compilare. În plus, nu există conversii implicite între tipuri similare: programatorul va trebui să facă explicit conversiile în locurile în care acestea sunt necesare. Unii cercetători au promovat ideea că o folosire corectă a tipurilor poate duce la garantarea unui invariant important: dacă programul compilează atunci sunt șanse mari ca el să fie corect. De cele mai multe ori acest lucru nu este adevărat în totalitate. De fapt, se încearcă transformarea celor mai frecvente erori de runtime și bug-uri în erori de compilare. De exemplu, limbajul Haskell rezolvă problema null-pointer-exception folosind un tip de date special numit Maybe: programatorul va întoarce valori încapsulate în acest tip din funcțiile care pot eșua și compilatorul se asigură că orice folosire a rezultatului

www.todaysoftmag.ro | nr. 11/Mai, 2013

programare Programare Funcțională în Haskell întors de aceste funcții este verificată. La extrem, s-au creat framework-uri de dezvoltare de aplicații Web în care fiecare șir de caractere are un tip propriu: nu se mai pot confunda porțiuni de CSS cu porțiuni de HTML și nici nu se mai pot face atacuri clasice de tip SQL Injection sau similare. Un alt avantaj al tipării statice este faptul că un programator poate căuta o funcție cunoscând doar tipul acesteia. Există două motoare de căutare pentru acest lucru: Hayoo și Hoogle. Ambele vor căuta funcții încercând să generalizeze cât mai mult posibil argumentele oferite și să ofere sugestii particulare cât mai elocvente. După un timp, se ajunge la a programa ca și cum s-ar rezolva un puzzle uriaș în care piesele sunt date de funcțiile ce vor ajunge în programul final. O calitate importantă a limbajului o reprezintă puritatea. Ținând cont că orice program trebuie să interacționeze cu exteriorul (citire date, transmitere date, etc), Haskell oferă și el funcții pentru operațiile de intrare-ieșire. Dar, acestea vor fi marcate diferit din punct de vedere al tipurilor. Tipul oricărei acțiuni cu efecte laterale este IO. Dacă din Maybe se puteau scoate valorile încapsulate, acest lucru nu mai este posibil în cazul IO. Asta face ca orice funcție ce folosește efecte laterale să nu poată fi chemată decât din funcții ce vor fi marcate ca având efecte laterale. Practic, codul este împărțit în două tabere: codul pur funcțional pentru prelucrarea de date și codul imperativ pentru interacțiunea cu exteriorul. Această separare face ca Haskell să fie considerat de Simon Peyton Jones – unul dintre creatorii limbajului – ca fiind cel mai bun limbaj de programare imperativ. Segregarea efectelor laterale și a funcțiilor pure asigură paralelizarea ușoară a codului. Este extrem de simplu pentru un programator să paralelizeze codul scris în Haskell: neavând efecte laterale funcțiile pure pot fi apelate în orice ordine și ori de câte ori, rezultatele pot fi memoizate în cache-uri iar cod se poate scrie fără a fi necesare primitivele de sincronizare. Un alt atu important al limbajului este evaluarea leneșă. Programatorul poate scrie cod ce lucrează pe date infinite cât timp acestea au o reprezentare finită fiind necesară doar evaluarea unui număr finit al acestora. Gândiți-vă la un șir de la matematică: este o structură infinită, dar poate fi reprezentat finit printr-o recurență și când îi scrieți termenii, vă opriți mereu după primii 3-4. Deși evaluarea leneșă permite scrierea

de programe circulare și/sau lucrând cu secvențe infinite, uneori aceasta afectează analiza programului din punct de vedere al perfomanței. Din fericire, limbajul oferă construcții pentru controlul evaluării fiind astfel posibil ca programatorul să declare că anumiți membri sau anumite argumente ale unei funcții să fie evaluate imediat. Pe de altă parte, evaluarea leneșă asigură evaluarea exactă necesară a datelor cerute, irosind cât mai puțini cicli de ceas. De fapt, îmbinând toate facilitățile limbajului se poate scrie cod declarativ/ funcțional având aceeași performanță cu limbajele clasice C, Java, etc. Avantajul folosirii unui limbaj funcțional este evident dacă vă gândiți că un cod declarativ este ușor de citit și la 2-3 luni după scrierea acestuia: e mult mai facilă corectarea bugurilor în momentul în care acestea apar. Codul Haskell poate fi interpretat sau compilat. Se recomandă folosirea suitei GHC (The Glorious Glasgow Haskell Compiler Collection) împreună cu Haskell Platform pentru a avea toate beneficiile limbajului și ale unor biblioteci de nivel înalt foarte performante și testate. Suita GHC vine cu un compilator (ghc) și un interpretor (ghci). Interpretorul permite dezvoltarea rapidă a aplicațiilor, testarea codului sau a tipului unor expresii, etc. . Compilatorul permite generarea unui executabil având aceleași performanțe cu ale unui cod scris în limbajele clasice. Suita Haskell Platform oferă utilitare de profiling a aplicației pentru a optimiza codul cât mai mult posibil. Considerând că am prezentat destule detalii despre limbaj pentru a provoca pasiunea de a-l învăța, trecem la noțiuni de sintaxă. La final, în acest articol se va scrie un program ce va rezolva o problemă simplă: dându-se o permutare pentru a i se afla ordinul acesteia (numărul de aplicări ale permutării asupra permutării identitate pentru a se ajunge înapoi la permutarea identitate). De exemplu, pentru permutarea (3 4 2 1 5), răspunsul căutat este 4: aplicând (3 4 2 1 5) peste (1 2 3 4 5) vom ajunge la (3 4 2 1 5), apoi la (2 1 4 3 5), (4 3 1 2 5) și înapoi la (1 2 3 4 5) (aplicarea unei permutări presupune mutarea elementului de pe poziția I pe poziția corespunzătoare din permutare).

nr. 11/Mai, 2013 | www.todaysoftmag.ro

Vom reprezenta o permutare folosind o listă a numerelor de la 1 la n. În Haskell, [1, 2, 3] reprezintă lista primelor 3 numere. Pentru a avea un cod generic, putem instanția lista folosind un generator, ca în [ 1 .. n]. O listă din Haskell permite adăugarea de elemente doar în față. Pentru aceasta se folosește operatorul :. Lista vidă este reprezentată de []. Elementele unei liste sunt toate de același tip. Pentru a accesa un element, putem folosi operatorul !!. Majoritatea funcțiilor în programarea funcțională sunt recursive. Astfel, se poate demonstra corectitudinea codului folosind inducție structurală. De exemplu, funcția următoare va calcula lungimea unei liste: length [] = 0 length (x:xs) = 1 + length xs

Prima linie spune că lungimea listei vide este 0. A doua spune că lungimea unei liste formate prin inserarea unui element x în fața unei lista xs este cu 1 mai mare decât lungimea listei xs. Programatorii obișnuiți cu părțile lowlevel și structura compilatoarelor vor spune că recursivitatea consumă spațiu pe stivă și că nu este un pattern care ar trebui folosit tot timpul. Pe de altă parte, compilatorul din suita GHC poate realiza transformări asupra funcției astfel încât să se ajungă la a folosi recursivitatea de tip coadă: fiecare apel recursiv înlocuiește cadrul de stivă al apelului anterior astfel încât rezultatul este întors direct în funcția apelantă. Dacă vă uitați la cele 2 linii pentru funcția length, veți vedea că există câte una pentru fiecare constructor al listei. Practic, majoritatea funcțiilor în programarea funcțională pornesc de la deconstruirea tipului de date: se scrie câte o expresie pentru fiecare constructor al tipului în parte. Considerați acum funcțiile următoare. Prima calculează suma elementelor dintr-o listă, în timp ce a doua calculează produsul lor. sum [] = 0 sum (x:xs) = x + sum xs product [] = 1 product (x:xs) = x * product xs

După cum observați, există un șablon comun urmărit de toate funcțiile: există un element inițial pentru cazul în care pornim de la lista vidă și o operație pe care trebuie să o aplicăm peste elementul curent și rezultatul apelului recursiv. Practic, având aceste două ingrediente putem “împături” lista într-o nouă valoare. Acest șablon este capturat de Haskell prin intermediul a două funcții (diferența fiind dată de direcția în care se realizează reducerea):

TODAY SOFTWARE MAGAZINE foldr f e [] = e foldr f e (x:xs) = f x (foldr f e xs) foldl f e [] = e foldl f e (x:xs) = foldl f (f e x) xs

Observați că una dintre cele 2 funcții este tail-recursive de la început: apelul recursiv se efectuează cu unul dintre argumente actualizat cu rezultatul parțial de până atunci. Diferența între cele 2 poate fi observată și din imaginea următoare.

Practic, folosirea șabloanelor și funcțiilor predefinite ajută pentru a scrie mai puțin cod (amintiți-vă principiul DRY) și pentru a ajunge la un cod pentru care este mai ușor de demonstrat corectitudinea. În plus, compilatorul poate avea optimizări suplimentare încorporate pentru aceste funcții speciale. Putem scrie acum cod pentru a aplica o permutare asupra unei liste: pentru fiecare element din permutare întoarcem elementul de pe poziția respectivă din listă (folosind !! pentru a obține elementul și map pentru a efectua operația pentru toate elementele). applyPerm :: [Int] -> [Int] -> [Int] applyPerm l p = map (\i -> l !! (i - 1)) p

Având această funcție, se poate calcula răspunsul problemei folosind funcția until. Aceasta este oarecum echivalenta unei bucle while din programarea imperativă: primește un predicat (funcție ce întoarce True/ False), o funcție pentru a itera de la o stare la următoarea și starea inițială și va întoarce starea finală, în momentul Alte două pattern-uri importante cap- în care predicatul devine True. turate de Haskell sunt map și filter. Le vom computeOrder :: [Int] -> Int ilustra direct prin imaginea următoare și computeOrder perm = fst $ until test f $ f init where codul următor: l = length perm - 1 map f [] = [] map f (x:xs) = f x : map f xs filter p [] = [] filter p (x:xs) | p x = x : filter p xs | otherwise = filter p xs

test p = snd p == [1 .. l] f (a, list) = (a+1, applyPerm list perm) init = (0, [1 .. l])

Cum funcționează funcția? Pornind de la o permutare perm, vom aplica applyPerm iterativ pentru a modifica starea curentă

din until. Pentru stare reținem două valori într-un tuplu: un contor și lista curentă, rezultatul permutărilor. Putem testa codul scris de noi în interpretorul ghci: *Main> computeOrder [3,4,2,1,5] 4

Rezultatul este 4, exact cum ne așteptam. Putem testa să vedem dacă rezultatul este corect. Folosim iterate pentru a apela o funcție la infinit, generând lista [x, f x, f (f x), ...]. Folosim take pentru a lua doar primele elemente dintr-o listă. Astfel, profităm de evaluarea leneșă pentru a calcula doar elementele necesare. *Main> take 5 $ iterate (flip applyPerm [3, 4, 2, 1, 5]) [1..5] [[1,2,3,4,5],[3,4,2,1,5],[2,1,4,3,5],[4,3,1,2, 5],[1,2,3,4,5]]

În ediția viitoare vom prezenta mai multe elemente legate de sintaxa Haskell: modul prin care se pot defini tipuri noi și modul în care acestea pot fi folosite. În mod cert, aplicația din articolul următor va fi mai complexă decât cea de acum.

Mihai Maruseac

mihai.maruseac@gmail.com IxNovation @ IXIA membru ROSEdu, ARIA

www.todaysoftmag.ro | nr. 11/Mai, 2013

programare

Recenzia cărții: RESTful Web Services Cookbook de Subbu Allamaraju

artea pe care v-o supun atenţiei, intitulată „RESTful Web Services Cookbook” de Subbu Allamaraju, arhitect la Yahoo, face parte dintr-o categorie specială. Ea prezintă un ghid complet pentru scrierea şi consumarea serviciilor web REST, într-un mod independent de limbaj. Aceasta constituie o mare provocare. Din punct de vedere al conceptelor introduse este un material cuprinzător, iar provocarea vine în a găsi care sunt limitele unui anumit mediu de programare în a le implementa. Silviu Dumitrescu silviu.dumitrescu@msg-systems.com Consultant Java @ .msg systems Romania

nr. 11/Mai, 2013 | www.todaysoftmag.ro

Ghidul conţine modalităţile de design ale serviciului web REST, atât pe partea de client cât şi pe cea de server, dar rezolvă şi probleme de performanţa, scalabilitate, încredere şi securitate. Prima informaţie remarcabilă pe care o puteţi afla din această carte a fost că în anul 2000 Roy Fielding a introdus un stil arhitectural cunoscut sub numele de Representational State Transfer (REST) în teza sa de doctorat „Architectural Styles and the Design of Network Based Software Architectures”. Gândul meu a zburat imediat în termeni comparativi şi m-am gândit când vom avea şi noi, in România, asemenea teze de doctorat pe tematica arhitecturilor soft. Răspunsul este complicat, cu foarte multă muncă, mă hazardez să afirm că, poate, în zece ani. Viitorul vă aparține! Voi reveni, totuși, la menirea mea de a vă prezenta cartea curentă. Împărțită în patrusprezece capitole şi cinci anexe, autorul prezintă gradual toate resursele implicate în crearea şi consumarea unui serviciu web REST. Organizarea fiecărui capitol este sub forma unor rețete, adică se ridică o problemă exprimată prin „How to...” sau „When and how...”, apoi se dau soluții şi în cele din urmă se poartă discuții. Serviciile web REST au apărut ca o alternativă la serviciile web bazate pe SOAP. Ele folosesc protocolul HTTP, dar nu sunt limitate doar la acestea. Spre deosebire de SOAP, REST nu necesită parsare de

XML, nu necesită un header de mesaj către şi de la service provider. Datorită protocolului de transport HTTP, REST folosește trei metode de comunicare între client şi server: • GET, pentru obținerea de informații sigure şi idempotente • POST, pentru crearea unei noi resurse, pentru modificarea uneia sau mai multor resurse, pentru a rula cereri cu intrări mari sau pentru a executa orice operații nesigure sau neidempotente, atunci când nici o altă metoda HTTP nu pare potrivită • PUT, pentru a crea resurse noi doar atunci când clienții pot decide asupra URI-ului de resurse, altfel se va utiliza POST • DELETE, pentru ștergerea unei resurse şi nu numai Dacă ne referim la entități şi legătura cu un modul de persistență putem avea în vedere folosirea celor patru metode după următorul sablon: • GET, pentru interogare • PUT, pentru update • DELETE, pentru ștergere • POST, pentru creare Tot la nivelul comunicării interesează modul în care grupăm sau combinăm resursele. Aceste acțiuni au relevanță în creșterea performanțelor şi limitarea traficului.

business

Dupa cum stim, oricare dintre metode poate fi Consumer sau Producer. În plus, fiecare dintre metode își poate impune tipul de resursă pe care îl produce sau consuma. Alegerea tipului de resursă este dificilă. Principalele tipuri de reprezentări pe care autorul le descrie sunt: • XML, pentru orice reprezentare • JSON, pentru orice reprezentare, dar JSON poate oferi performanță în parsare fața de XML • Formate de date portabile precum: data, timp, numere, valuta • Date codate binar precum: filme, audio, foto • Erori, sub forma unui text plain sau a unui cod de eroare. Codurile de eroare sunt sunt forma 4xx, pentru erori datorate datelor de intrare ale clientului, şi 5xx pentru erori de implementare de pe server sau datorate stării curente Resursele sunt identificate prin URI. Modul în care este construit URI-ul are o importanță foarte mare în evitarea ambiguităților şi regăsirea resurselor. Autorul descrie multe elemente necesare creării URI-urilor, dar şi unele dintre bunele practici, spre exemplu „How to Keep URIs Cool” în sectiunea 4.4. Un capitol aparte, capitolul 5, tratează subiectul link-urilor web. Acestea sunt prezente în reprezentarile XML, JSON, in header-e şi la client. Construirea templateurilor URI este eficientă deoarece conferă dinamicitate unui URI, clienții putând

TODAY SOFTWARE MAGAZINE să-și includă informații adiționale în URI înaintea trimiterii cererii către server. Fo r m at e l e At o m ş i AtomPub definesc resurse precum entries şi feeds, reprezentarea lor şi un protocol de operare pe aceste resurse. Serviciile web REST suportă acest tip de format, pe lângă cele anunțate anterior. De la capitolul 7 încolo autorul prezintă, ceea ce aș numi elemente avansate în cadrul serviciilor REST. Primul subiect atins este acela al negocierii conținutului, mai precis indicării preferințelor clientului precum: tipurile media suportate, limba, codarea caracterelor, etc. . Problema folosirii cacheului este foarte importantă pentru că bine folosită conduce la scăderea întârzierilor percepute de utilizator, creșterea încrederii, reducerea costurilor, a încărcării benzii şi a serverului. Bazat pe frecvența update-urilor se poate fixa o perioadă de timp pentru care cache-ul poate servi o reprezentare. O nouă provo care ce conduce la performanță este dată de cereri condiționale. Acestea adresează două probleme: pentru cereri GET ajută clienții şi cache-ul să identifice dacă o anumită reprezentare poate fi considerată proaspătă, iar pentru cereri PUT, POST şi DELETE cererile condiționale furnizează controlul concurenței. Controlul concurent este implementat în două feluri: • Concurența pesimistă: clientul blocând resursa, • Concurența optimistă: prin introducerea unui token de versiune ce se validează.

reprezentărilor XML şi JSON, extinderea atom-ilor, samd. Mie materialul mi s-a părut foarte cuprinzător. Citirea lui mi-a ridicat câteva probleme, în special pentru că unele dintre capabilități nu le testasem pentru Java. În acest moment nu știu care dintre cele discutate în carte nu pot fi suportate de serverul Glassfish. Majoritatea testelor pe care le-am făcut au reușit, dar există încă multe de testat. Mă adresez de aceea vouă, cititorilor, să incercați implementarea în Java EE 6 a tuturor problemelor pe care autorul le ridică în această carte. Consider că dacă veți reuși să parcurgeți întreg materialul şi să creați exemple ilustrative, REST nu va mai avea neclarități pentru voi. Aștept cu mare plăcere orice discuții! Ca de obicei, vă doresc lectură plăcută, Silviu Dumitrescu

Partea următoare cuprinde topicuri diverse relativ la o resursă, cum poate ea fi copiată, mutată, făcută undo şi multe altele. Capitolul 11 face precizări importante relativ la acestea. Capitolul de securitate, 12, descrie aspectele legate de accesul la resurse, prin autentificare, precum şi confidențialitate, integritate, prevenirea accesului clientilor rău intenționați sau neautorizați. Ultimul capitol se referă la extensibilitate şi versionare şi face referiri la menținerea compatibilităților URI, a www.todaysoftmag.ro | nr. 11/Mai, 2013

SPRE COMUNITATEA IT – via HR

ultă lume îşi doreşte un Silicon Valley la Cluj, cu firme IT cât mai inovative şi creative. Clusterul IT ţinteşte acolo. În acest prim articol, dintr-o serie de patru, firma Danis Consulting îşi propune să urmărească, din perspectiva resurselor umane din aceste firme, cum au evoluat ele, problemele pe care le întâmpină şi, mai ales, cum pot să ajungă să constituie o comunitate reală de care să fim mândri?

Partea idealistă Dan Ionescu

dan.ionescu@danis.ro Director Executiv @ Danis Consulting

Cristina Nicule

cristina.nicule@danis.ro Consultant @ Danis Consulting

nr. 11/Mai, 2013 | www.todaysoftmag.ro

O comunitate matură de oameni şi firme de IT care se susţin reciproc şi care îi fac pe clienţii din toată lumea să se uite cu interes la Cluj pare un vis. Un vis frumos. A mai existat cineva care spunea “I have a dream!” - Martin Luther King. Care este realitatea IT acum în Cluj? Cei circa 9.000 de angajaţi din firmele IT clujene sunt cea mai critică resursă. Toate firmele se luptă pentru a atrage noi angajaţi şi, aparent, salariul este singurul motivator. Mai sunt şi alte “incentives”: spaţii de joacă, mese de ping-pong, masajul cervical şi alte must-do care îi fac extrem de invidioşi pe angajaţii din alte industrii. Pe de altă parte, ţinta declarată este de 20.000 de angajaţi. Se pare că diferența dintre ce este acum şi comunitatea de construit este destul de mare. Evident că este necesară o viziune şi o doză mare de idealism, dar fără acestea IT va rămâne doar o sursă de câştig financiar imediat, în general pentru patroni de departe. Riscul asupra firmelor rămâne ridicat, mai ales când lohn-ul ocupă o pondere mare în afaceri şi este atât de imprevizibil. În anul 2015, Cluj-Napoca va fi capitala europeană a tineretului, iar în 2020 (sperăm să fie) şi capitală culturală. Acestea sunt momente de mare mândrie pentru comunitatea locală şi sunt şi o măsură a maturităţii

acestei comunităţi. Aici apare nevoia de viziune!

Partea concretă

Firma Danis Consulting lucrează de 15 ani în domeniul Dezvoltării Organizaţiilor. Fiindcă am avut de-a face cu multe firme din ITC, credem că ştim destul de bine particularităţile acestei industrii şi unele căi de a se dezvolta. Dorim să contribuim la construirea unei comunităţi solide şi durabile în Cluj. Iar aici nu este vorba de idealism – firme solide înseamnă afaceri bune, winwin pentru toţi. Pentru aceasta am demarat “pro-bono” un proiect de cercetare, în care să ne întâlnim trimestrial, în discuţii de 1-2 ore, cu un grup de oameni de HR din firme de IT clujene. Scopul acestor întâlniri dorim să fie: a. Analiza problemelor cu care se confruntă şi găsirea de soluţii utile pentru participanţi şi firmele lor, b. Identificarea unor practici manageriale de succes care pot fi împărtăşite în comunitatea IT, c. Găsirea unor mecanisme de întărire a comunităţii locale IT. Rezultatele discuţiilor, dar şi o concluzie sintetică finală, vor sta la baza unei cercetări ştiinţifice pe care o vom furniza celor interesaţi. După fiecare întâlnire vom face publice

TODAY SOFTWARE MAGAZINE concluziile prin intermediul partenerului nostru media Today Software Magazine. În cadrul lansării ediţiei care conţine articolul nostru, vom putea dezbate problemele cu persoanele interesate, la workshop-ul TSM. Fiindcă interesul şi experienţa noastră se leagă de modul în care sunt conduse firmele, pe diverse nivele manageriale, am propus o succesiune de tematici pentru întâlnirile grupului: 1. Cum s-au dezvoltat, în Cluj, firmele de IT? Care au fost cele mai bune comportamente ale conducătorilor care au favorizat creşterea? Dar acelea care au inhibat creşterea? Concluziile pot ajuta la dezvoltarea, în continuare, a firmelor din această industrie! 2. Care sunt particularităţile procesului de conducere în aceste firme, în prezent. De exemplu se poate discuta despre: factorii care creează încredere în manageri, despre conducerea unor echipe de oameni tineri şi creativi, despre IQ vs. EQ. Fiind multe subiecte de interes, ne aşteptăm la două întâlniri pe această temă. 3. Ce ajută şi ce frânează crearea unei comunităţi deschise de IT? Cum s-ar putea depăşi actualele frâne care favorizează „feudalismul” acestor firme (fiecare cu interesele proprii, cu multe orgolii, care creează o competiţie puternică între firme, dar nu atât de piaţă). Cum s-ar putea trece spre concepte mai moderne, de exemplu, să ne sprijinim unii pe alţii pentru a fi mai atractivi cu toţii în faţa clienţilor? Ne dorim ca aceste întâlniri să fie cât mai puţin formale şi mai mult decât o ocazie de a face networking.

Prima întâlnire Imagine de ansamblu asupra primei întâlniri: Această primă întâlnire a avut ca scop analiza trecutului companiilor din IT pentru a găsi exemple de bune practici (sau de greşeli) din care să învăţăm cu toţii. Ne-am dat seama pe parcursul discuţiei că era greu să ne menţinem la nivelul trecutului, participanţii la workshop revenind mereu la situaţia din prezent. Ulterior, ne-am dat seama că este posibil ca acest artefact să fie, din nou, ceva foarte specific industriei IT – un domeniu dinamic, în permanenţă schimbare şi care trăieşte mai mult în prezent. Astfel, rezultatul acestei prime întâlniri este similar cu „deschiderea cutiei Pandorei” în sensul pozitiv al sintagmei. Practic, s-au împărtăşit câteva dintre subiectele interesante care stau la baza succesului organizaţiilor din IT, urmând ca în întâlnirile

următoare să aprofundăm aceste dezbateri, unor astfel de instrumente pot fi: să intrăm mai în detaliu cu unele subiecte • Utilizarea managerilor pentru flexibiprecum: „Care este stilul de conducere cel lizarea unor procese. Dacă conducătorii mai potrivit oamenilor din IT?” sau „Cum dintr-o companie (de la diverse nivele) reuşiţi să construiţi munca în echipă – adeau răspunderea pentru anumite evaluvărată, cu colaborare, comunicare şi ajutor ări, decizii, intervenţii legate de oameni, reciproc?” atunci sistemele pot fi mai flexibile şi mai Ideile cele mai valoroase împărtăşite în uşor de implementat. acest prim workshop le prezentăm în con• O altă soluţie este ca sistemele să tinuare structurate pe câteva capitole mari: decurgă natural din practici curente de succes, pentru a nu avea cum să fie res1. Activitatea de dezvoltare a oamenilor din IT pinse. Este şi experienţa celor de la ISDC În acest domeniu există de regulă care au nivelul 3 de certificare CMMI, abordarea logică: de a interveni pentru bazându-se pe procesele existente. dezvoltarea unei anumite arii atunci când se observă, se sesizează o nevoie specifică. Din discuţiile purtate s-a agreat însă fapNe-am bucurat să auzim că managementul tul că implementarea unor sisteme şi bune din companii a ajuns la concluzia că trai- practici mature, se poate realiza cu succes în ning-urile pe un anumit subiect – mai ales organizaţii cu oameni maturi în atitudine. legat de abilităţi de relaţionare, de lucru Sperăm ca în întâlnirile următoare să în echipă, de comunicare – nu sunt sufi- aprofundăm mai mult sistemele de evaluare ciente pentru dezvoltarea sau schimbarea a performanţelor din diverse companii. De unui anume comportament. iQuest-ul are data aceasta, Răzvan Voica de la iQuest ne-a o serie de exemple clare în această direc- oferit o imagine sintetică a sistemului din ţie. De asemenea, Accesa a implementat compania lui de „career management” – cu recent un Program de Dezvoltare complex scopul de evaluare şi dezvoltare a oamenicare a ţintit echipa de conducere şi eşalonul lor din companie. Este un sistem extrem de imediat următor de conducere, program în interesant şi complex în care se pune mult care s-au combinat activităţi de tip training accentul pe responsabilitatea managerilor cu stabilire şi implementare de obiective de din companie pentru dezvoltarea angajaţilor. dezvoltare individualizate, cu asistenţa con- Simplificând, fiecare lider din companie este sultanţilor de specialitate. şi un „career manager” pentru un număr de Acesta este unul dintre principalele angajaţi. El are responsabilitatea de a-i ghida, motive pentru care de câţiva ani buni pe cei angajaţi, în procesul lor de dezvoltare. încoace şi noi, în calitate de companie de De aceea, în cazul managerilor din iQuest, consultanţă în domeniul dezvoltării, ne abilităţile de comunicare şi cele complexe de străduim să „propovăduim” programele de coaching sunt extrem de valorizate. dezvoltare şi nu doar cursuri, care să conţină şi alte tipuri de acţiuni (workshop-uri de 3. Elementele de cultură organizaţională şi follow-up, sesiuni de coaching de grup sau cult al muncii în IT individual, proiecte aplicative etc.) şi care să Reprezentanţii companiilor prezenţi la fie întinse pe o perioadă mai lungă de timp, acest workshop recunosc tendinţa pe piaţă în aşa fel încât să permită exersarea noilor spre o mai mare flexibilizare şi indepenabilităţi, fixarea lor în context de muncă real. denţă a forţei de muncă, însă în acelaşi timp, Pe lângă aceste abordări fireşti ale pro- admit că nu sunt încă pregătiţi pentru aşa cesului de dezvoltare a angajaţilor, în ISDC ceva. IT-iştii seniori pot să aprecieze mai de exemplu, am descoperit şi o abordare mai mult timpul flexibil, de exemplu la ISDC s-a „altfel”. Oamenii de Resurse umane îşi asumă implementat un sistem de lucru de acasă o o mare parte din activităţile de dezvoltare – dată pe săptămână pentru angajaţii care au conducând training-uri şi team-building-uri peste 6 luni în companie. Cei juniori şi nu în interior conform unor sisteme şi proce- numai, „până la un anumit moment al cariduri bine stabilite. Fiind aproape de colegii erei manifestă nevoia de apartenenţă la un lor, ei pot să intervină şi preventiv, nu doar grup / la o comunitate” ceea ce angajarea întratunci când sunt probleme. o firmă de IT le poate oferi. Deocamdată, piaţa de IT din Cluj nu este încă suficient de 2. Sisteme şi procese de succes în companiile matură pentru a permite unui angajat IT o din IT libertate de genul: atunci când intru într-un Sistemele şi procesele de Resurse Umane proiect să pot avea şi libertatea să intru şi în tind să fie percepute de către angajaţii din alt proiect, al altei companii, în paralel. IT ca birocratice şi, ulterior, să fie respinse. Fortech-ul a aplicat o reţetă de cultură Soluţii pentru implementarea cu succes a organizaţională extrem de deschisă şi caldă www.todaysoftmag.ro | nr. 11/Mai, 2013

HR SPRE COMUNITATEA IT – via HR faţă de angajaţi. Conducerea a manifestat în permanenţă „sinceritate şi transparenţă faţă de angajaţi. Cultura organizaţională a crescut frumos pe bază de principii stabilite atunci, la începutul firmei.”. De asemenea, un alt element distinctiv al Fortech-ului a fost selectarea oamenilor foarte buni din punct de vedere tehnic. Discutând despre cultură organizaţională, valori fundamentale – acele lucruri apreciate într-o companie – am ajuns împreună la o concluzie desprinsă din practica celor prezenţi: pentru ca o organizaţie din IT să-şi asigure stabilitate în timp este mare nevoie în primul rând să-şi stabilească clar acel set de valori – care descriu „personalitatea” organizaţiei („cum suntem noi, cum e la noi”). Apoi, este vital să-ţi alegi oamenii cu care continui să lucrezi luând în calcul valorile şi atitudinile lor, felul lor de a fi. Bineînţeles că şi criteriile tehnice vor fi luate în calcul dar ele trebuie inteligent echilibrate cu cele ce ţin de personalitatea candidatului. În extremă, participanţii la workshop ne-au dat exemple de situaţii în care au fost respinşi candidaţi extrem de buni tehnic, dar incompatibili din punct de vedere al atitudinilor, al caracterului, al modului de abordare a problemelor cu ceea ce se valoriza în companie. Oamenii potriviţi în gândire, în atitudini cu organizaţia din care fac parte tind să dea performanţe mult mai bune decât cei care sunt departe de felul de-a fi al companiei (chiar dacă au cunoştinţe tehnice excepţionale). În această ordine de idei, provocarea oamenilor de Resurse Umane şi a managementului din companiile de IT este menţinerea acestei „coloane vertebrale” de valori, indiferent de greutăţile întâmpinate în momentul actual pe piaţa forţei de muncă din Cluj. „Dacă oamenilor care vin la noi la interviuri nu le strălucesc ochii când le spunem despre tehnologii, nu sunt oamenii potriviţi pentru noi.”.

„Leadership-ul este crucial in orice organizatie care abordeaza dezvoltarea sistematica a factorului uman. Ei trebuie să fie implicaţi să dea mai departe” [din modelul lor, din abilităţile şi atitudinile lor]. Abordând discuţia despre liderii din vârful companiilor de IT – care pot fi CEO, Administratori sau chiar fondatorii companiei – ne-am dat seama că, de regulă, această persoană îl reprezintă pe cel care setează standardul companiei şi că oamenii – cel puţin IT-işti români – au nevoie de acest lider care să aibă viziunea companiei. Oamenii au nevoie de modele şi cred în imagini de succes. Am discutat puţin despre importanţa carismei liderului din vârful companiei şi, chiar dacă am găsit stiluri diferite de carismă la companii diferite, concluzia noastră este că – cel puţin pentru aceste 4 companii – liderul din vârful ei a fost un factor de succes în creşterea şi stabilitatea companiei. Uneori discursurile atractive şi inspiraţionale sunt cele care atrag oameni în jurul liderului şi coagulează culturi organizaţionale, alteori structura şi consistenţa în abordarea unui anume tip de business sunt cele care ajută.

4. Actul de conducere în companiile IT

Raluca Pop (ISDC) este de profesie psiholog şi are o experienţă în Resurse Umane de 13 ani, iar în domeniul particular al IT-ului de 3 ani. Atunci când povesteşte despre ceea ce face în ISDC, manifestă evident entuziasm şi mândrie

Un alt subiect prin care doar am „zgândărit” dezbaterile se referă la conducătorii potriviţi sau de succes în IT. La nivel de companii am întâlnit diverse principii, de ex:

Participanţi Alexandra Bayer (Fortech) a început munca în domeniul IT în urmă cu 7 ani, când a devenit membră a echipei Fortech. Practic, a crescut odată cu compania şi a învăţat alături de colegii ei din conducere cum să câştige încrederea oamenilor din IT: cu argumente logice, concrete, statistici. Profesia de bază de inginer a ajutat-o mult în această abordare structurată a activităţilor de Resurse Umane. Chiar şi acum, când în Fortech sunt aproape 300 de angajaţi, Alexandra se vede ca un ajutor pentru toată compania, ca având „ochi şi urechi” pentru toţi, deşi devine din ce în ce mai dificil la această dimensiune a companiei.

nr. 11/Mai, 2013 | www.todaysoftmag.ro

– lucruri care sunt importante şi valorizate în cultura ISDC-ului. Răzvan Voica (iQuest) are un background „vechi” în IT (din 1997), având o diversitate mare de experienţe profesionale, inclusiv ca şi programator. Din 2011 a ajuns în echipa de management a companiei iQuest – unul din jucătorii importanţi pe piaţa IT-ului din Cluj (şi nu numai). Recunoaşte că această poziţie – de management în domeniul Resurselor Umane – a fost dificilă şi foarte provocatoare pentru el. De când este în iQuest a iniţiat şi dezvoltat foarte multe sisteme şi procese interne de management al Resursei Umane de care ar fi în stare să povestească cu mândrie şi pasiune câteva ore! Cristina Puiu (Accesa), psiholog de profesie, acoperă activitatea de Resurse Umane într-o companie mai mică decât celelalte 3 prezente la workshop, aflată însă în plină expansiune. Ritmul de creştere al companiei Accesa – de la 20 la 60 de angajaţi, într-un singur an – a supus-o la provocări importante pe partea de Resurse Umane. Experienţa ei în firme de recrutare şi selecţie, precum şi cea în domeniul auto au făcut-o să facă faţă cu succes activităţii de până acum.

TODAY SOFTWARE MAGAZINE

Managementul performanței

pre deosebire de celelalte articole publicate în numerele anterioare, acesta va avea mai multe părți. Prima care va fi tratată în aceste pagini, oferă o definiție a conceptului de managementul performanței și a procesului, dar și a instrumentelor folosite pentru implementarea lui.

Într-un mediu dinamic în care companiile pun din ce în ce mai mult accentul pe dezvoltarea angajaților, în ultimele decenii fiecare organizație de pe glob a încercat să definească elementele care contribuie la crearea acelui mediu organizațional de succes. Scopul lor este de a determina indicatorii de performanță pentru o organizație cu rezultate ridicate. Cerințele mediului extern forțează companiile să se adapteze competiției internaționale și să fie capabile să fie competitive simultan din perspectiva prețului, calității, flexibilității și al relațiilor cu clienții. Managerii au dezvoltat un interes pentru crearea unei culturi organizaționale orientată spre performanță și excelență. Publicațiile de specialitate descriu organizațiile orientate spre performanță ridicată (high performance organizations) ca fiind organizații care au rezultate financiare excepționale, clienți și angajați satisfăcuți, productivitate ridicată, organizațiile care încurajează inovația și dezvoltarea abilităților de leadership. Printr-o studiere mai atentă a literaturii de specialitate se pot identifica însă termeni caracteristici fiecărei categorii: dezvoltare financiară sustenabilă, orientare pe termene lung, obținerea de rezultate excepționale, care se referă strict la companie ca entitate și la rezultatele acesteia. În 2007, Waal a oferit o definiție pentru organizațiile cu performanță ridicată, comparând performanțele financiare și non-financiare ale companiei proprii cu cele din același domeniu de activitate pe o perioadă lungă de timp, cuprinsă între 5 și 10 ani. Astfel o companie competitivă pe piață dezvoltă o strategie durabilă prin care va obține un avantaj competitiv în comparație cu celelalte companii care au același domeniu de activitate. Evoluția resurselor umane pe parcursul ultimilor 50 ani este impresionantă. De la „personal”, care se ocupa de partea legislativă: contracte de muncă, protecția muncii, dosare de personal ale

angajațiilor, la „resurse umane”. Diferența între cele 2 concepte este mai mult decât evidentă, începând de la o simplă interpretare a noțiunilor. Când spui resurse umane te gândești la resurse care pot fi valorificate pentru a se obține rezultate în cadrul firmei. Această arie are ca funcții importante: recrutare și selecție, evaluare, instruire, motivare și recompensare și partea legislativă și administrativă. Conceptul de resurse umane este o umbrela pentru noțiunea de personal, înglobându-l și oferindu-i funcții și atribuții noi. Multă vreme părea că acest termen definește cel mai bine tot ceea ce se întampla în acest departament, însă s-a dovedit a nu fi așa, din simplul motiv că „resursele umane” sunt într-o continuă dezvoltare. Termenul care descrie cel mai bine activitatea departamentului este „managementul talentului”. Acest termen pune accentul pe potențialul uman și pe o strânsă corelare între obiectivele individuale și cele ale companiei. Se vorbește pe langă funcțiile de resurse umane, de ”coaching” și ”mentoring”. Două concepte impresionante care susțin descoperirea potențialului printr-o dezvoltare continuă, personală și profesională. Este foarte important ca persoanele să își imbunătățească aptitudinile și competențele. Această redefinire a conceptului de personal, resurse umane și managementul talentului evidențiază o evoluție continuă în această era tehnologizată. Managementul performanței este în strânsă corelație cu managementul talentului. Prin performanță se evaluează obiectivele individuale și ale echipei, care sunt în concordanță cu obiectivele strategice ale companiei. Pentru ca firma să câștige acel avantaj competitiv pe o piață în continuă evoluție trebuie să valorifice talentele umane pe care le deține. Conceptul de performanță, la o

simplă analiză a definiției din dicționar este evidențiat ca având o natură polivalentă. Poate însemna ”implementare”, adică îndeplinirea unei cerințe sau cereri, poate fi definit ca o “competență”/ abilitate de a face ceva. Pentru o înțelegere mai clară a acestei noțiuni este nevoie de o aprofundare a literaturii de specialitate. Lebas (1995) caracterizează performanța ca având un impact în viitor. O afacere de succes este cea care își atinge obiectivele definite. Astfel, performanța ține atât de capabilitate cât și de viitor. Folan (2007) subliniază trei obiective de guvernare ale performanței, care trebuie analizată de fiecare entitate în limitele mediului în care se decide a se opera. În al doilea rând performanța este legată de unul sau mai multe obiective stabilite de către entitatea a cărei performanță este analizată. Și în al treilea rând performanța este redusă la caracteristicile relevante și de recunoscut. Managementul strategic al performanței presupune alinierea obiectivelor individuale și a celor de echipă cu obiectivele de dezvoltare de afacerii. Acesta urmărește crearea unei culturi a învățării pentru a dedica resurse și timp îmbunătățirii performanței organizației. Acest concept a fost inițiat abia în secolul XX de către Peter Drucker în lucrarea sa « Concept of the Corporation». Până in anii ’80 cercetăriile s-au orientat spre două domenii: impactul planificării strategice asupra performanței firmei și rolul planificării strategice în luarea deciziilor strategice. Managementul perfomanței la nivel operațional se referă la managementul operațiunilor, deoarece se centrează pe atingerea obiectivelor și țintelor departamentelor, de proiect sau ale echipei. Federick Taylor a dezvoltat conceptul de management științific. La începutul anilor ’20 General Motors a experimentat acest concept prin introducerea graficului DuPont pentru a susține reorganizarea companiei în structuri descentralizate cu

www.todaysoftmag.ro | nr. 11/Mai, 2013

HR Managementul performanței centre de profit. În anii ’30 în Franța a fost introdus “tabloul de board” pentru a monitoriza performanța operațională a organizațiilor. Deși majoritarea companiilor franceze îl utilizau, acesta a avut o răspândire minimă peste hotare. Rădăcinile managementului perfomanței din zilele noastre au fost puse de către filozofia japoneză. Managementul performanței la nivel individual este considerat ca reflectând nivelul de maturitate organizațională. La începutul anilor 1800, Owen a monitorizat performanța angajațiilor ca indivizi ce îndeplineau sarcini ca parte Figura 1 Fazele procesului de managementul performanței a unui grup. Până după cel de-al doilea război mondial, sistemul de managemen- se desfășoară el, pe parcursul unui an în CUM-ul procesului de management al tul performanței era utilizat mai mult în companie. perfomanței reprezintă modalitatea prin domeniul administrației publice, militare • Definirea celor patru faze ale pro- care fiecare angajat își îndeplinește sarcinile și fabrici industriale. Începând cu anii 90 cesului: (1) Definirea așteptărilor, (2) și își realizează obiectivele. Prezentarea în managementul performanței individuale Evaluarea intermediară, (3) Revizuirea detaliu a valorilor organizației, semnalează a fost reorientat pe două tendințe. Prima lunară a obiectivelor și (4) Evaluarea descriu un set de competențe pe care fieînsemna creșterea popularității auto-evafinală a performanței. care angajat trebuie să le dezvolte la cel mai luării performanței, iar a doua tendință Procesul de managementul perfomanței înalt nivel. alinierea managementului performanței are două caracteristici esențiale: Luând ca exemplu Inovația ca valoare strategic și managementul performanței a unei companii sau manifestarea unui individuale prin crearea unor noi instru• Accentuarea CE-ului (a rezultate- comportament: “suntem intuitivi, curioşi, mente precum Balanced Scorecard, care lor), a CUM-ului (a metodelor prin care practici şi inteligenţi, ceea ce ne oferă posibiavea ca obiectiv reflectarea obiectivelor rezultatele sunt atinse) si a UNDE-ului litatea să dezvoltăm noi idei pentru clienţi, organizaționale în cele individuale. (plan de dezvoltare personală, obiective afacere şi angajaţi. Prin operaţiunile globale profesionale). pe care le dezvoltăm, încurajăm idei în orice Fundamentele procesului • Îmbunătățirea comunicării între regiune a lumii”. Comportamentul încurajat Managementul performanței are manager și angajat prin crearea unui este “anticipează tendințele viitoare și idenca scop creșterea responsabilității de a dialog continuu care să aibă la bază feed- tifică oportunitățile pe care capitalizează. produce rezultate și de a-și îmbunătăți back și coaching. ”. Cum se măsoară acest comportament abilitățile și competențele. În cadrul compentru fiecare obiectiv? Înseamnă setarea paniei, managementul performanței a fost așteptărilor și a modului prin care angajații întotdeauna considerat un aspect pentru Elementele procesului de management pot să își îndeplinească obiectivul luând în managementul resurselor umane pentru al performanței considerare comportamentele încurajate de atingerea obiectivelor organizaționale, Evaluarea performanței trebuie să acestea. printr-o aliniere cu strategia organizației, reflecte așteptările, iar realizările sunt oriCea de-a doua parte a articolului va valorile și cultura acesteia. entate pe obiective și valori. Mai mult decât oferi detalii despre mijloacele procesului atât ele trebuie să răspundă așteptărilor de managementul performanței. Până la clienților. următorul număr, succes în definirea proProcesul și Instrumentele În continuare voi prezenta modul în cesului și a instrumentelor care se potrivesc Conform acestei figuri fazele proce- care este definită legătura între valorile cel mai bine companiei din care faceți parte. sului de managementul performanței se organizației și procesul de managementul vor descrie etapele procesului așa cum performanței. Valorile care fac parte din

Andreea Pârvu

andreea.parvu@endava.com Recruiter în cadrul Endava

Figura 2 Procesul de managementul perfomanței

nr. 11/Mai, 2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

Poate da ... poate nu ...

orbesc cu multă lume în ultima vreme şi văd că majoritatea dintre noi avem un dorință dar care rămâne doar atât. Avem câte un “vreau să fac sport”, “vreau să citesc mai mult”, “vreau sa manânc mai sănătos”, “vreau să mă trezesc mai devreme”, “vreau … “ Ne dorim foarte mult lucrurile respective, ne dorim să ne apucăm şi să ne ţinem de ele, suntem foarte motivaţi şi chiar şi aşa ele

nu se întâmplă. Vă provoc la un joc. În poza de mai jos Suntem foarte motivaţi! Suntem foarte este un desen a unui iepure (fiecare figură motivaţi? are o etichetă lingvistică). Întrebarea pe care vă rog să v-o adresaţi este: Definim motivaţia ca acea energie care Iepurele va fugi mai repede şi pe o disne mobilizează să iniţiem o acţiune şi apoi tanţă mai lungă în care dintre cele două ne face să o menţinem la frecvenţa şi inten- situaţii? sitatea dorite. Când este fugărit de un lup fioros sau Dar ce este motivaţia? În primul rând când are un morcov gustos în faţă? unul dintre cele mai folosite, dar poate cel mai puţin înţeles concept. Știm cum se simte când eşti motivat, putem recunoaşte aceea energie. Putem spune cum apare? Cum se menţine? Nu vă voi povesti despre motivatie pentru că e un subiect complex şi cu multe aspecte. Vă pot spune însă un truc despre cum să vă apucaţi să faceţi acel lucru pe vi-l doriţi sau să nu îl faceţi, dar fără să vă mai Răspunsul este că va fugi de lup mai simţiţi vinovaţi. mult și mai repede. Probabil se va porni sa Pentru asta vom folosi o definiţie de alerge si după morcov însă când va deveni lucru a motivaţiei: foarte obosit va spune “Nu mi-e atat de Motivaţia este acea energie care ne foame. Morcovul e acru.” face să considerăm că efortul de a face E bine să nu existe numai lupi, e bine să un anumit lucru este mai mic decât con- avem şi morcovi după care să alergăm. Dar secinţele apărute ca urmare a realizării morcovii singuri nu vor face iepuraşul să îşi acelui lucru. zburlească blăniţa pentru foarte mult timp. Orice acţiune necesită efort. Efortul respectiv trebuie să merite să fie depus. Dacă ştim asta la nivel teoretic, de ce nu Merită să fie depus atunci când ca urmare o aplicăm şi în practică? a efortului se întâmplă ceva care este mai Dacă ne-am stabilit un obiectiv pentru relevant sau mai important ca beneficiul a avea anumite beneficii, haideți să ne gânnedepunerii efortului. dim și la tot ce pierdem sau la consecințele Ei bine, mai este un mic detaliu. Noi negative care ar rezulta din neîmplinirea ştim deja ce e scris mai sus despre moti- acestuia. vaţie. Dar mai e un mic detaliu legat de Pentru că dimineaţa când trebuie să ne consecinţe şi de cum ar trebui să fie ele. trezim, să ne luăm adidaşii şi să ne apuCând ne gândim să ne apucăm de sport căm de alergat, toate lucrurile bune nu vor ne gândim la asta în termeni de toate bene- părea că fac să merite efortul. ficiile pe care le-am obţine dacă am face-o. “Da, aşa bine mă voi simţi după ce Asa e? Ne propunem să ne apucăm de sport alerg, voi avea energie toată ziua, voi pentru că viaţa va fi mult mai frumoasă gândi mai limpede, voi fi mai agil, voi fi dacă am face-o. Problema este că noi ca mai fericit. Da, dar aşa de bine e sub plaoameni nu funcționăm aşa. pumă cu ochii închişi.

De mâine!” Dacă nu există consecinţe negative reale sau pe termen scurt, creați-le! E mai greu să spui “e foarte cald şi bine sub plapumă, cred că am să dorm în continuare.” dacă vă aşteaptă cineva jos în faţa blocului. E important să ştim că morcovii şi lupii nu trebuie să fie neapărat controlaţi externi sau palpabili. Dacă vreţi să identificaţi ce vă mobilizează şi ce vă face să perseveraţi gândiţi-vă şi faceţi o listă cu acele lucruri pe care le faceţi si continuaţi să le faceţi. Apoi puneţi-vă întrebarea “de ce le faceţi, de ce continuaţi?” Veţi observa un pattern pe care apoi îl veţi putea aplica şi la celelalte lucruri care aşteaptă pe listă. Dacă vreţi să ştiţi mai multe despre motivaţie şi despre cum funcţionăm noi ca oameni vă recomand doua cărţi absolut excepţionale si un TED talk: Daniel Pink – DRIVE BF Skinner – Beyond Freedom and Dignity

Vă mulţumesc şi vă urez alergare uşoară!

Antonia Onaca

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

www.todaysoftmag.ro | nr. 11/Mai, 2013

startup

Roller Coaster-ul Imagine Cup

magine Cup este o competiție anuală organizată de Microsoft ce promovează inovația și tehnologiile proprii. Echipe de până la patru studenți, în decursul unui an, acceptă provocarea de a scrie o aplicație care să contribuie la Millenium Development Goals. Anul acesta însă, condiția temei a fost revocată, oferindu-ne libertatea de a construi un joc distractiv, care să nu poarte responsabilitatea rezolvării problemei foametei în țările subdezvoltate. Am amânat participarea la această competiție încă din primul an de facultate. Dar acesta era începutul celui de-al treilea meu an, iar cu doar doi ani rămași până la absolvire, nu mai aveam mulți “anul următor” rămași. Trebuia să fac ceva.

JavaScript

În fiecare an, Microsoft anunță tehnologiile dintre care studenții au de ales și pe care sunt nevoiți să le folosească. Printre cele propuse anul trecut se află HTML5. Poftim? HTML5 nu este tehnologie Microsoft! Și totuși era acolo, pe site-ul oficial. Iar noi puteam folosi JavaScript și WebGL pentru a construi un joc 3D incredibil de portabil. Mi-am petrecut următoarea lună citind articole de Douglas Crockford și John Resig. Am scris o colecție de experimente care nu vor vedea niciodată lumina zilei. Scopul meu era să construiesc un engine întreg în JavaScript de la zero. Sistemul de input, grafică, audio, totul. Urma să folosim acest engine pentru a construi jocul nostru extraordinar. Aveam un sistem de input funcțional și

un schelet pentru sistemul grafic. Scrisesem de asemenea un plugin pentru Bl e nd e r c are e x p or t a modelele 3D si shader-ele în format JSON. Engine-ul putea încărca modelele si le putea desena folosind shadere. Funcționa și era superb. Asta până când au apărut regulile pentru Microsoft Imagine Cup 2013, iar HTML5 dispăruse de pe lista de tehnologii disponibile. În momentul acela invitasem deja doi colegi de facultate și buni prieteni: Timotei Dolean și Adrian Soucup, împreună cu un vechi prieten din liceu: Andrei Grigoriu pentru a forma echipa VertexArmy. Aveam încredere în abilitățile si pasiunea lor, iar împreună simțeam că putem face acest lucru posibil. Nu voiam să facem greșeli stupide, așa că ne-am decis să nu scriem nicio linie de cod până nu punem la punct toate aspectele jocului. Pentru început, trebuia să alegem între o grafică 3D sau una 2D. Grafica 2D este mult mai greu de desenat, iar grafica 3D introduce o nouă dimensiune în logica jocului. De asemenea, simțeam că pentru a face un joc distractiv aveam nevoie de un simulator de fizică. Am început să ne întâlnim în weekenduri, să discutăm idei de joc și să urmărim alte jocuri asemănătoare. Ne doream un joc care să fie simplu (spre deosebire de complex), cu o mecanică ușor de înțeles, și care să conțină puzzle-uri creative construite pe baza mecanicilor. Oricare ar fi ideea finală, aceasta trebuia să fie distractivă, ușor de înțeles, iar puzzle-urile trebuiau să fie rezolvate folosind creativitate și inteligență. În decursul câtorva săptămâni am început sa punem totul cap la cap. Jocul nostru urma să aibă grafică 3D într-o lume 2D. Simulatorul de fizică va funcționa de asemenea

nr. 11/Mai, 2013 | www.todaysoftmag.ro

în doar două dimensiuni. Lumea jocului va fi plină de tehnologie extraterestră. Puzzleurile vor necesita folosirea unor abilități și tehnologii pentru a muta lucruri și a repara interiorul unei nave distruse. Urma să avem cuburi pe care jucătorul să le poată muta și folosi pentru a construi aparate cu abilități și scopuri neobișnuite. Spre exemplu, cu rețeta potrivită, zece cuburi ar putea fi folosite pentru a construi un dispozitiv ce inversează gravitația. Un singur cub ar putea fi folosit pentru a construi o rampă scurtă peste o groapă, iar un altul se va putea transforma într-o sursă de energie pentru un dispozitiv deja existent. Cuburile urmau să fie complet identice. Ne simțeam încrezători și ne plăcea direcția în care mergea proiectul.

Unity

Odată ce am găsit ideea generală, a trebuit să alegem tehnologia în care o vom implementa. Platformele XBOX și mobile au ieșit din ecuație deoarece nu aveam tehnologia necesară. Așa că am rămas cu PC-ul. Citind un topic interesant pe forumurile Imagine Cup, am descoperit că aveam voie să folosim engine-uri de jocuri ca Unity, sau chiar Unreal, atât timp cât foloseam produse Microsoft în procesul de dezvoltare (e.g.: scripturi C# în Unity). Ne-am gândit: ”Asta e super!”. Nefiind nevoie să ne creăm propriul engine grafic puteam să ne concentrăm pe jocul propriuzis. Așa că fiecare dintre noi ne-am instalat Unity și am început să facem tutoriale. Am creat un demo în care o armată de cuburi urmărea cursorul iar cuburile se spărgeau dacă erau lovite tare de perete. Unity avea

TODAY SOFTWARE MAGAZINE

tot ce ne era necesar, inclusiv un editor foarte bun pe care îl puteam folosi să tragem din meniul de unelte diferite obiecte pentru a crea jocul. De fapt, era prea mult de tras și prea puțin de scris script-uri. Nu că scripturile nu ar fi fost folositoare sau destul de puternice, ci faptul că erau doar pe locul doi ca importanță în Unity. Totodată, engine-ul era atât de complex încât gândul la cât trebuie să învățăm pentru a-l putea folosi eficient, ne dădea fiori. Am realizat curând că versiunea gratuită de la Unity nu avea facilitatea de „render targets”. Acest lucru însemna că nu puteam face niciun efect special, nici măcar un efect simplu de conturare pentru a marca cuburile selectate. Acest lucru a fost dezamăgitor deoarece aveam cunoștințele necesare pentru a implementa efecte, dar engine-ul pur și simplu nu ne lăsa. Iar noi sub nicio formă nu puteam plăti 1500$ pentru asta. Așa că, pentru a doua oară am aruncat totul și am început de la zero...

XNA

și shader-ele iar Timotei urma să lucreze pe partea de interfață utilizator și sistemul de intrare (tast atură, mous e, Kinect, etc). Am început să dezvoltăm, încetul cu încetul, folosind Skype pentru a comunica zilnic. Ideea jocului s-a s c h i mb at d e - a lungul proiectului. Am adăugat un caracter principal în poveste: un robot în formă triunghiulară care umblă cu ajutorul unor șenile și are niște abilități interesante. Am încercat câteva stiluri grafice, dar nu am fost mulțumiți de rezultate. Unele probleme au fost din cauza modului în care era unghiul camerei sau felul în care texturile erau filtrate, dar majoritatea au fost din cauza lipsei mele de experiență. Până la urmă, simulatorul de fizică s-a integrat superb cu jocul. Andrei a avut ideea de a simula șenilele prin fizică, așa că am exportat fiecare piesă separat (o roată, o șenilă și un corp) iar el le-a folosit pentru a construi robotul ca un sistem de componente simulate fizic. Asta înseamnă că atunci când robotul se deplasează, se rotesc de fapt cele trei roți. Sistemul de fizică folosește forța de frecare dintre roți și șenile pentru a face robotul să se miște. Aceasta s-a dovedit a fi cea mai importantă decizie pe care am luato în legătură cu design-ul jocului.

Ultima noastră alegere a fost XNA („XNA’s Not an Acronym”). Acesta este un framework simplu peste DirectX și ne-a oferit tot ceea ce aveam nevoie: un nivel de abstractizare complet, cu unelte și librării matematice. În sfârșit eram gata să începem dezvoltarea jocului nostru. Găsisem ideea de bază și alesesem tehnologia adecvată. Păcat că ne-a luat cinci luni să ajungem aici... Ne-am configurat un repository de Git (împreună cu un front-end numit ”Gitlab”) pe serverul nostru, ne-am pregătit mediul de lucru (XNA nu merge în mod implicit cu Visual Studio 2012) și ne-am împărțit sarcinile între noi. Aveam nevoie de un artist iar eu eram cel mai potrivit; Andrei În aprilie a trebuit să trimitem jocul urma să se ocupe de integrarea sistemului pentru runda de calificare în ciuda faptude fizică și implementarea logicii jocului că nu era nici pe aproape gata. Echipa a lui, Adrian urma să creeze sistemul grafic lucrat toată noaptea dinaintea rundei pentru a crea un demo jucabil, programând non-stop. Am adăugat funcționalități și am fixat bug-uri fără să clipim. Dimineața devreme am asamblat împreună câteva înregistrări din joc într-un trailer epic, ce înfățișa un robot curajos luptând împotriva unui univers nemilos. Da, da, știm, nu avea nicio

legătură cu jocul nostru, iar judecând după grafică... era un dezastru. Majoritatea texturilor au fost luate rapid de pe Google, iar indicațiile din joc erau afișate cu un font roșu groaznic și aproape imposibil de citit. Cel mai probabil simulatorul de fizică împreună cu grafica 3D au fost piesele de rezistență care ne-a trimis în finală. Am primit vestea calificarii noastre cu mai puțin de-o săptămână înainte de finala națională. Aceasta însemna că mai aveam cinci zile să facem jocul prezentabil. Am umplut lista de TODO-uri cu o mulțime de funcționalități noi: un nivel secundar, grafică mai bună cu texturi noi, „depth of field”, o rescriere a interfeței utilizator și multe altele. Cu o zi înainte de finală aveam încă lucruri neterminate: „depth of field”ul trebuia îmbunătățit, indicațiile din joc trebuiau și ele îmbunătățite, meniul nu era finalizat și încă ne lipseau texturi. Ne rămăseseră 24 de ore pană la prezentare, iar daca experiența ne-a invațat ceva, este că suntem foarte productivi pe ultima sută de metri.

Alex Pana

alex.pana@vertexarmy.org internship student @ Tora trading

www.todaysoftmag.ro | nr. 11/Mai, 2013

diverse

Gogu și plinul de benzină

ogu își luă – tacticos, ca de obicei – tava cu mâncare, îl căută din ochi pe Mișu și îi trebuiră câteva secunde până îl găsi. Frate, are ăsta un dar de a se așeza mereu în cel mai îndepărtat colț al sălii de mese, gândi amuzat pornind spre el. Răspunse la saluturi și se simți oarecum important văzând câți se întrerupeau din mâncat să îl salute sau să-i ureze poftă bună. Deh, sunt de ceva ani în coșmelia asta... Se așeză satisfăcut la masă lângă Mișu, îi zâmbi dar realiză instantaneu eroarea majoră pe care tocmai o comisese. - Uff, Gogule, zi și tu, ce să fac? Să taci și să mă lași să-mi tihnească mâncarea, asta să faci. Evident, Gogu dădu replica numai în sinea lui, n-ar fi putut să-l amărească și mai mult pe Mișu. Îi plăcea mult tânărul liniștit, calm până și în situațiile cele mai critice, cu vorba molcomă și cu un puternic accent ardelenesc pe care nu și l-a pierdut nici în anii de facultate și nici ulterior în compania multinațională la care lucrau împreună de ceva timp. Numai eu îl mai pot scoate din liniștea și calmul lui, chicoti – tot în sinea lui – Gogu. Își forță o grimasă serioasă pe față și oftă a acceptare, pregătindu-se – pentru a cel puțin zecea oară în ziua respectivă – pentru lamentările lui Mișu. - No, vezi Gogule, că până și pe tine te apucă oftatu’. Io ce să mai zîc?! Îmi vine să mă duc la Șefu’... Se opri brusc, mâinile rămăseseră în aer așteptând continuarea fluxului verbal pentru a-și urma mișcarea. Șopti apăsat, aproape suierând fiecare cuvânt: Gogule, ești un geniu! Se uită îndelung în toate direcțiile. Zici că-i radar, își spuse Gogu, și se ridică imediat ce îl localiză pe Șefu’. Cum privirile îi rămăseseră lipite de masa la care Șefu’ își savura liniștit prânzul, Mișu nu realiză când răsturnă tava și nici măcar nu dădu vreun semn că ar fi auzit zgomotul tacâmurilor care poposiră pe gresie. Paharul cu apă se clătină nehotărât iar apoi decise să se verse în direcția unui Gogu rămas cu gura căscată, incapabil să articuleze vreun cuvânt, neînțelegând care este meritul lui în toată povestea. Sări însă în sus, imediat ce apa din cascada improvizată se scurse pe genunchii săi. Toată povestea părea ireală, desprinsă dintr-un film al cărui scenariu îi era total necunoscut, așa că îl urmă cu nedisimulată curiozitate pe Mișu. Zgomotul tacâmurilor și defilarea cu pas apăsat al celor doi atrăsese și atenția celorlalți colegi așa că, pe când ajunseseră la masa lui Șefu’, toate privirile erau ațintite spre ei. - Șefu’, trebuie să mă ajuți, că nu mai am nici o soluție, știi că deadline-ul îi mult prea strâns și noi am promis că livrăm la timp, dar acum toate resursele sunt luate de proiectul din Anglia. Și am tot cerut la tătă lumea, dar nimeni nu m-ajută iar io sunt disperat, martor mi-i și Gogu... se întoarse teatral spre acesta din urmă. Șefu’, imperturbabil, își termină de mestecat îmbucătura, se uită lung la Mișu și spuse: - Poftă bună și ție, Mișule. Hi-hi, dacă replica asta s-a dorit o ironie subtilă, hai că ți-a ieșit, râse Gogu pe sub mustață. Evident a fost mult prea subtilă pentru Mișu sau cel puțin pentru starea de surescitare în care

nr. 11/Mai, 2013 | www.todaysoftmag.ro

se afla acesta, căci omul nu își ieși din ale lui nici măcar o clipă. Continuă fără să clipească măcar: - Să ai și mata, Șefu’, ce zici mă rezolvi și pe mine cu o resursă externă? Numa’ două săptămâni, maxim trei. - Mișule, zici că ești fulger! Ce e cu viteza și cu logoreea asta, parcă n-ai fi tu. Iar tu, Gogule, șterge-ți rânjetul ăla de sub mustață, ai oameni să-i dai lui Mișu? Sau poate ai buget pentru resurse externe, ei? - Care oameni Șefu’, că deja mi-ai luat doi. De un’ să-i dau mai mulți?! îngheță Gogu. Se gândi apoi la buget și se prinse imediat că a fost luat peste picior. Hai, măi Șefu’, zău așa, faci mișto de noi? - Păi cine-a-nceput, măi băieți? De unde bani pentru resurse externe? Măi Mișule, știi că suntem la minim de buget, singura ta șansă este să renegociezi termenul. Nu putem să le facem pe toate deodată, iar compania zice că acum altele sunt prioritățile. Asta e, dacă buget nu e, nimic nu e... - Numa’ unu’, Șefu’, bâlgui cu ultimele puteri Mișu. Un om, măcar două săptămâni, cât poa’ să coste?! - Măi Mișule, știi poanta cu picătura de benzină? Mișu dădu din cap a neștiință. Hai că iar și-a luat aerul sfătos, urmează o lecție, nu putea Șefu’ să rateze o întreagă sală de masă ca audiență, își zise Gogu și își trase un scaun să stea mai comod. Șefu’ se încruntă pentru o secundă dar era prea dornic să spună povestea așa că dădu doar din mână a lehamite și continuă: - Cică se duce unu’ la benzinărie și îl întreabă pe cel de la pompă: Cât costă o picătură de benzină? Fugi de-aici, dom’le, nu costă nimic, e zero lei, răspunde acesta. Super, fă-mi și mie plinul, picătură cu picătură... Așa și tu Mișule, nu e mare lucru o resursă, dar una azi, alte două mâine...

Simona Bonghez, Ph.D.

simona.bonghez@confucius.ro Speaker, trainer şi consultant în managementul proiectelor, Owner al Confucius Consulting

sponsori