tsm_11_2013_1ro

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

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

M AG A Z I N E

Bucătăria arhitectului software - Carduri de Scenarii

Testarea în CloudSoftware Craftsmanship

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ă

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

6Să uităm

de modelul Silicon Valley

Bogdan Iordache

7ITCamp

2013Mihai Tătăran

8(un) prieten pentru startup-uri

Cosmin Mihaiu

10JAVA EE7. Cloud,

Web 2.0+Silviu Dumitrescu

11Istoria IT-ului Clujean (V)

- Învățături din Junimea

Marius Mornea

13Software Craftsmanship

Alexandru Bolboacă și Adrian Bolboacă

16Din bucătăria arhitectului

software - carduri de scenariiAttila Antal

19Arhitectura extransibilă și

durabilăLevente Veres

22Testarea în Cloud

Vlad Zeciu

24Orchestrarea Testării

AutomateLucian Revnic

28OPTIONSABILITY - O caracteristică discretă a proiectelor ITBogdan Matei

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

34Trenduri și Big DataRadu Vunvulea

39Programare Funcțională în HaskellMihai Maruseac

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

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

45ManagementulperformanțeiAndreea Pârvu

47Poate da ... poate nu ... Antonia Onaca

48Roller Coaster-ul Imagine CupAlex Pana

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

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

Buzz-ul din ultimele luni este crearea structurilor și a oportunităților pentru dez-voltarea 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ă outsour-

cing 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 com-paniile 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 divertis-ment. 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 [email protected].

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 feno-men. Î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 imple-mentarea 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 publi-cate î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

Ovidiu Măţan, [email protected]

Fondator și CEO alToday Software Magazine

editorial

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

TODAY SOFTWARE MAGAZINE

Redacţia Today Software Magazine

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

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

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

Colaborator social media: Rodica Manolache [email protected]

Traducător: Cintia [email protected]

Reviewer: Tavi Bolog [email protected]

Reviewer: Adrian Lupei [email protected]

Produs de Today Software Solutions SRL

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

www.todaysoftmag.rowww.facebook.com/todaysoftmag

twitter.com/todaysoftmag

ISSN 2284 – 6352

Copyright Today Software Magazine

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

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

www.todaysoftmag.rowww.todaysoftmag.com

Silviu [email protected]

Consultant Java@ .msg systems Romania

Marius [email protected] senior software developerin cadrul Nokia, în prezentfondatorul platformei MintakaResearch

Radu [email protected]

Senior Software Engineer@iQuest

Lista autorilor

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

Mihai Tătă[email protected]

Microsoft MVPCodeCamp

Co-fondator ITCamp

Bogdan [email protected]

este Co-Fondator al How to Web, cel mai important eveniment web din Europa de Est

Alexandru [email protected]

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

Attila Antal [email protected]

Software Architect@ ISDC

Levente Veres [email protected]

Design Lead @ endava

Vlad [email protected]

Senior QA Engineer@ Small Footprint


Senior Php Developer@ 3Pillar Global

Lucian [email protected]

OO Content Arhitect@ HP Software Cluj

Hunor [email protected]

Software Developer@ evoline

Mihai [email protected]

IxNovation @ IXIAmembru ROSEdu, ARIA

Adrian [email protected]

Programmer. Organizational and Technical Trainer and Coach@Mozaic Works

Dan [email protected]

Director Executiv@ Danis Consulting

Cristina [email protected]

Consultant@ Danis Consulting

Andreea Pâ[email protected] în cadrul Endava

Alex [email protected]

internship student@ Tora trading

Simona Bonghez, [email protected]

Speaker, trainer și consultant în managementul proiectelor,

Owner al Confucius Consulting



Să uităm de modelul Silicon Valley

(aka Fat Frumos din Vale și Merele de Siliciu)

startups

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 orga-nizat 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ă, investito-rii 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 mode-lul 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 cer-cetă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.

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.

Acum 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 tranzis-toarelor. Î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.


este Co-Fondator al How to Web, cel mai important eveniment web din Europa de Est



ITCamp 2013

eveniment

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 imagi-nii 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 apro-ximativ 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, majorita-tea 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 dezvol-tatorii, 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 revo-luţ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 prac-tică 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• ht tp s : / / v i m e o. c om / c h an n e l s /

itcamp2012 (câteva sesiuni din 2012)• ht tp s : / / v i m e o. c om / c h an n e l s /

itcamp2011 (câteva sesiuni din 2011)

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

Mihai Tătă[email protected]

Microsoft MVPCodeCamp

Co-fondator ITCamp


startups

un prieten pentru startup-uri

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 îna-inte. 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 într-

un bus iness funcțional. Am ascultat suges-tia lui și după o lună, am pri-mit oferta să participăm in primul accele-rator European o r i e nt a t p e m e d i c i n ă . Ne-am făcut bagajele, am p l e c a t s p r e Londra și am format compa-nia cunoscută a c u m s u b n u m e l e d e MIRA Rehab.

Î n D e c e m b r i e 2012, Marius ne-a recoman-dat să aplicăm la Kairos 50. Am ascultat d i n nou d e e l ș i ne-am c a l i f i c a t l a Kairos Global S u m m i t .

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 pri-mii 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.

L-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ă dis-cute 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

LUX

EMB

OU

RG

www.ictspring.com

Koichiro TsujinoFounder Alex Corporation and developed VAIO, Sony, former

President of Google Japon

Ruppert KeeleyCEO EMEA, Paypal

Pepe MODERGlobal Director fot the Digital

Marketing & Communication, Pirelli

BRIAN STEVENSCTO, Redhat

Peter Sondergaard

Senior Vice President, Research Gartner

Laura YeciesCEO, SugarSync

Trip HAWKINSFounder of Electronic Arts,

CEO, Digital Chocolate

Biz StoneCo-founder, Twitter

ReGISTER NOW

MORE SPEAKERS ON

JUNE

www.ictspring.com



eveniment

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

Partea centrală a versiunii 7 a platfor-mei 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 des-cărcarea dezvoltatorilor de grija task-urilor legate de infrastructură, prin folosirea con-tainerelor ș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 îmbu-nătăţiri aduse de Java EE 7. Aceasta înseamnă aducerea în discuţie a proble-melor 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 concu-renţă, 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 pre-zenta 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 bibliogra-fice au fost numeroase, din păcate unele dintre ele contradictorii. Spre exemplu, în acest moment nu este clar când va fi lan-sată Java EE 7. Termenul estimat iniţial de aprilie 2013 este aproape sigur depășit. De

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 eveni-mente 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 inte-resaţ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

De-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 plat-forma 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.





Istoria IT-ului Clujean (VI)Învățături din Junimea

istorie

Am să încep cu încheierea făcută de Iacob Negruzzi cărții sale: „Amintiri din Junimea”.

„Când privesc înapoi, la viața trecută a Junimii, mă conving pe deplin că o aseme-nea societate nu s-a putut forma decât prin concursul unor împrejurări cu totul deose-bite. A trebuit să se întâlnească într-un oraș de provincie, departe de zgomotul centrului politic, un număr de bărbați tineri, la care plăcerea literaturei și îndeobște a ocupațiilor intelectuale să fie deopotrivă vie. Aceștia au trebuit să fie într-o situație materială inde-pendentă, așa ca să aibă de unde ajuta pe alți tineri lipsiți de mijloace, ce le păreau a avea talent și sârguință. A trebuit ca mem-brii Junimii să-și recunoască deplin meritele unii altora și ca nici un sentiment de invidie, cât de ascuns, să nu turbure seninătatea con-stantă a relațiilor lor. Condusă de asemenea bărbați și în asemenea împrejurări, negreșit că Societatea a putut ține atâta timp, chiar lipsindu-i desăvârșit orice organizare exteri-oară. Dar împrejurări identice nu se vor mai repeta ușor în viața unui popor și de aceea o a doua ediție a unei asemenea societăți va fi poate cu neputință în timpuri viitoare.

Avut-a Junimea merite însemnate? Acel care, ca mine, a fost însuși actor cu greu poate judeca valoarea piesei în care a jucat un rol de căpetenie. Viitorul singur se va rosti cu nepărtinire când noi nu vom mai fi. Totuși, credința mea este că Junimea va păstra o pagină în istoria literaturei române, căci prea am avut noi înșine plăcere la lucră-rile noastre, pentru a nu fi adus mulțumire și folos și publicului celui mare. Vor veni mai târziu alte societăți mai învățate, poate mai active și mai neobosite, însă nu va mai fi nici una care să fi făcut lucrări serioase într-o formă atât de veselă, de plăcută și de neobișnuită.”

Pe lângă valoarea intrinsecă a citatului de mai sus, putem extrage câteva învățături relevante extrapolând la contextul actual al IT-ului clujean. O simplă recitire, în care înlocuim „literatura” cu „IT-ul”, evocă o imagine apropiată de realitatea actuală. Realitate plină atât de asemănări, cât și diferențe față de contextul istoric al Junimii.

La primul capitol, contextul geografic, poli-tic și economic, par să fie de partea noastră. Suntem un oraș de provincie, suficient de departe de capitală, cu o generație tânără de iubitori de IT, având o situație financiară peste medie (o statistică la nivel național plasează IT-ul în top 3 cele mai bine plătite domenii, Clujul ocupând poziția secundă, după București). Îndrăznesc să sintetizez aceste asemănări contextuale sub sintagma de infrastructură socială.

La capitolul diferențe separăm sim-pla asemănare de infrastructură de acele împrejurări identice esențiale pomenite de Negruzzi. Pentru a elimina diferențele este necesară însușirea următoarelor învățături.

În primul rând recunoașterea meritelor celorlați, fără invidie. Junimea se folosea de întâlniri foarte dese între membrii ei și de prezența „Convorbirilor Literare”, o unealtă foarte bună pentru a aduna talente, a crește voci și a polemiza cu celelalte centre universitare și culturale ale țării. Această combinație între comunicare cri-tică intensă în particular și o voce unitară pentru publicul larg, ajută la uniformi-zarea și coagularea societății, permițând șlefuirea orgoliilor înainte de expune-rea publică. Există și la Cluj un efort de cunoaștere a valorilor individuale printr-o comunicare activă și deschisă între mem-brii diferitelor comunități. Revista TSM are ca misiune principală întocmai facilitarea acestei comunicări și creșterea vizibilității între profesioniștii din mediul IT local, alături de tot mai multe astfel de inițiative, de la grupări tehnologice, la organizații de tip breaslă (vezi Cluj IT cluster). Important este să învățam a echilibra suficient orgoliu, cât să ne conștientizăm propria valoare, dar nu prea mult, cât să cădem în mândrie și invidie. Deși programatorii sunt o specie destul de orgolioasă, există destule semne de reușită în evitarea fragmentării, izolă-rii și diluarea valorii introdusă de primele două.

La următoarele două învățături, suntem încă în stadii incipiente: finanțarea talente-lor aflate la început de drum și atmosfera veselă și plină de satisfacție. Când ne refe-rim la finanțare, merită extins înțelesul junimist de ajutor financiar personal,

deoarece în practică acest rol de investitor îl pot juca atât indivizii, cât și compani-ile. 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 startup-urilor. Indiferent de combinațiile posibile ale înțelesurilor de mai sus, prioritară este necesitatea susținerii financiare și acce-lerarea proceselor de investiții pentru a contracara exodul talentelor către alte surse de finanțare internaționale. Similar mode-lului junimist, investim în școlarizarea talentelor (intern în companii, iar din per-spectiva 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 startup-uri. 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 atmo-sferă ș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 ofi-cial prietenos și lipsa unor proiecte reale de colaborare între jucătorii principali din piață. Chiar și la nivelul startup-uri-lor, 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 [email protected]

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



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

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

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

GeekMeet ClujComunitate dedicată tehnologiilor web.Website: http://geekmeet.ro/Data înfiinţării: 10.06.2006 / Nr. Membri: 537 / Nr. Evenimente: 16

Cluj.rbComunitate 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 GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: http://www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 303 / Nr. Evenimente: 26

Cluj Semantic WEB MeetupComunitate 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 SoftwareComunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.Website: http://www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 219/ Nr. Evenimente: 12

Î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

Mai 7AgileWorks Remote Open Spacewww.meetup.com/The-Cluj-Napoca-Agile-Software-Meetup-Group

Mai 8Monthly Meetup #13www.meetup.com/Tabara-de-Testare-Cluj

Mai 9Lansarea numărului 11 TSMwww.todaysoftmag.ro

Mai 14Software architecture and the balance with agilitywww.arobs.com/architecture-workshop

Mai 16-17Romanian Testing Community Conference 2013 www.romaniatesting.ro

Mai 17JAVA EE7. Cloud, Web 2.0+ [email protected]

Mai 17-19Startup Live Cluj-Napocastartuplive.in/cluj-napoca/2

Mai 18-19Asynchronous Master Classcodecamp-cluj-mai2013.eventbrite.com

Mai 23-24ITCAMP 2013itcamp.ro

Mai 25Fun 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-31I T.A.K.E Unconference Bucureștihttp://itakeunconf.com/

Comunităţi IT Cluj-Napoca

comunități



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În epoca medievală bunurile erau

produse manual. Fiecare profesie era struc-turată î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ân-deau 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 pro-duselor 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 tre-buia să treacă câteva etape: să devină ucenic, apoi să devină calfă, să călăto-rească î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 aptitu-dinile. 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, ucenicu-lui i se elibera un certificat de învățare a meșteșugului, care îi permitea să fie anga-jat 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 obli-gatoriu 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 con-ducere aleasă. Meșterul cu cea mai mare experiența și cu reputatie imaculată era de obicei conducătorul breslei. Această con-ducere avea grijă ca breasla să prospere, stabileau standardele de calitate ale produ-selor și realizau toate actele administrative.

1 http://arheologie.ulbsibiu.ro/publicatii/bibliotheca/bresle/4%20capitolul%20II.htm

Software Craftsmanship

Miș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.

programare

Alexandru [email protected]

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

Adrian [email protected]

Programmer. Organizational and Technical Trainer and Coach@Mozaic Works


PrincipiileDupă cum menționam mai sus,

Software Craftsmanship este o abordare in industria de Software Development care accentuează importanța abilităților dezvol-tatorilor. 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

Acest manifest este o continu-are al “Manifesto for Agile Software Development”, care presupunea existența software-ului funcțional, să putem răspunde rapid la schimbări, valori-zarea interacțiunilor între persoanele implicate în dezvoltarea unui software ș i colaborarea intensivă cu cl ien-tul. 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 din-tre oameni, ci dorim să creăm o comunitate de profesioniști.

IstorieÎncepând cu anul 2009 când a

fost publicat acest manifest, tot mai mulți programatori au început să se

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

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 pro-gramatori 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 programa-tori. Î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 programareSpre deosebire de alte profesii, un

programator nu are un set de practici standardizate pe care trebuie neapărat să le învețe. Există desigur practici pe care o echipă sau alta le folosesc, dar la nivel de

industrie avem foarte puține dovezi des-pre 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 progra-matori 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, refac-toring 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 mem-brii 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 pro-fesiei, 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ățaO dată ce o listă de practici de progra-

mare 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 pro-gramator să își dezvolte și singur abilitățile.

Software craftsmanship propune câteva metode de a învăța aceste practici.

Coding kata este o metodă împru-mutată din arte marțiale și se referă la exersarea unei practici de programare prin

programare

Manifestul Software Craftsmanship

Software Craftsmanship



rezolvarea repetată a unei probleme sim-ple 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, programato-rul să se gândească ce l-a încetinit în timpul exercițiului și ce ar trebui să schimbe pen-tru a elimina această frână.

Coding dojo este o altă metodă împru-mutată 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 dintr-un 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 retrospec-tive 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ân-direa 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 sesiu-nea 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 inven-tat 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 comu-nitate, există și posibilitatea de a învăța prin pair programming. Orice programa-tor ar trebui să poată invita pe un altul la o sesiune privată de exersare. Câțiva pro-gramatori fac acest lucru și la distanță; Alexandru Bolboacă a deschis de câțiva ani un “Remote Pair-programming Tour” în acest scop.

ConferințeComunitatea de software craftsmans-

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

iar România se alătură anul acesta prin conferința I. T.A.K.E. Pe 30-31 mai, eveni-mentul 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-uri-lor, 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 comuni-tă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 progra-mator î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ă.

Referințe:http://arheologie.ulbsibiu.ro/publicatii/bibliotheca/bresle/4%20capitolul%20II.htm http://manifesto.softwarecraftsmanship.orghttp://agilemanifesto.orghttp://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.phphttp://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-retreathttp://www.alexbolboaca.ro/wordpress/the-remote-pair-programming-tourhttp://agileworks.rohttp://itakeunconf.com


Cardul de ScenariiCardurile de scenarii sunt folosite pen-

tru argumentarea decizilor din diferite puncte de vedere. Cardurile sunt create de arhitectul din proiectul respectiv și sunt distribuite pentru evaluare de către mem-brii 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 arhitectu-

rale, motivul și o diagramă simplă care reflectă obiectul scenariului.

Zona cu deciziile are un câmp de explicatii și alte patru de impact asupra

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 multe valori în foma codificată (menționat deja mai sus). Aceste coduri urmează să fie

Din bucătăria arhitectului software carduri de scenarii

Metodologia 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ă.

arhitectură

Attila Antal [email protected]

Software Architect@ ISDC



explicate în liste dedicate.

Studiu de cazPentru 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 arhi-tectului 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 Se va folosi o logică de decizie internă, hardcodată.

Attribute(s) Performance Environment În timpul rulării (Runtime)Stimulus Cerere de luare decizii dinspre Business Logic.Response Decizii luate pe baza logicii interne.Architectural decisions Sensitivity Tradeoff Risk Nonrisk

Hardcodare S1 R1 N1

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

Architecture Diagram

DL2: Logică Configurabilă

DL3: Logică Bazată pe Rule Engine

Scenario #: DL3 Se va folosi un Rule Engine pentru decizii.

Attribute(s) FlexibilitateEnvironment În timpul rulării (Runtime)Stimulus Cerere de luare decizii dinspre Business Logic.Response Decizii luate de Rule Engine.Architectural decisions Sensitivity Tradeoff Risk Nonrisk

Folosirea unui Rule Engine

S2, S3 T2

Maintenanță pentru baza de reguli

S4R3 N2

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


Lista Punctelor SensibileCode Description

S1 Logica de decizie e greu de modificat mai târziu și necesită relansarea produsului în producție.

S2 Introduce complexitate în proiect.S3 Necesită expertiză și/sau experiență.S4 Comunicarea și planificarea în sync cu echipa care

întreține baza de reguli.

Lista Punctelor de CompromisCode Description

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

T2 Trebuie ales un Rule Engine portivit.

Lista RiscurilorCode Description

R1 Schimbarea logicii necesită development.

R2Fiind fișierul de proprietăți un punct sensibil al sistemului trebuie protejat și asignate roluri specifice modificării.

Lista Non-RiscurilorCode Description

N1 Este ușor de realizat și garantează lansarea în timp în productie.

N2 Găsită o soluție ușoară de lansare a regulilor.

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

Scenario #: DL2

Se va folosi o logică de decizie internă semi-hardcodată bazată pe anumite atribute configurabile prin intermediul unui fișier de proprietați.

Attribute(s) Configurability Environment În timpul rulării (Runtime)Stimulus Cerere de luare decizii dinspre Business Logic.

Response Decizii luate pe baza logicii interne influențate din exterior.

Architectural decisions Sensitivity Tradeoff Risk Nonrisk

Hardcodare R1 N1Fișier de Proprietăți T1 R2

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




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ă

L L

Configurabilitate DL2: Logică configurabilă

H M

Flexibilitate DL3: Logică bazată pe Rule Engine

H 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-ade-văr au nevoie de această solutie. Dificultatea mare în cazul nostru putând fi tradusă prin: mai scump, timp mai mare de implemen-tare ș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.

SumarConcluziile pe care le putem trage după citirea acestui articol

sunt:• Arhitectul trebuie să vină tot timpul cu diferite scenarii pen-

tru 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

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.

Din bucătăria arhitectului software

arhitectură

Throughout the year, ISDC engineers dreams of customers.

Only in spring time, we engineer Easter sponge cakes!

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


TODAY SOFTWARE MAGAZINE arhitectură

THE PHILOSOPHYÎ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 programa-torilor 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 tutu-ror care doresc să ofere ceva în plus faţă de cerințele standard, totodată să se pre-gătească pentru a deveni cei mai buni în domeniul IT. Desigur fiecare are la dis-poziţ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 busi-ness, aș folosi câteva cuvinte cheie: dreams (vise), reality (realitate), creation (creare), timeless (inexpirabil).

Un arhitect trebuie să ia în conside-rare 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 SECRETCare este cheia succesului unei arhi-

tecturi care satisface toate cerințele proiectului? Întrebarea este retorică, dar se poate răspunde la ea. Arhitectura ide-ală 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 sco-puri sau schimbări de echipe.

THE BUCKET LISTPentru 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 suste-nabilă. 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ân-dim dacă arhitectura aleasă va fi sau nu prea bună.

O listă de necesitați SMART poate fi următoarea:

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

The 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

Levente Veres [email protected]

Design Lead @ endava


A. Colectarea informațiilor1. 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ționaleNotă: 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țianoastrăîn30demilisecundegăseștetoatebile-tele disponibile pentru o anumita rută.•Fiecareinterogaredebazădedatenudureazămaimultde 10 milisecunde.•Putemdeservi1000deutilizatoripeminut.•Folosimfiecareserverdeaplicațiecuungraddeocu-pare 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: •Directoruleconomic:reducerecu10%alcosturilordevânzări•DirectorulIT:săreducănemulțumireaangajațilorcuaccesul la sistem•Angajați:cliențisă-șipoatărezervafoarterapidbiletele.

Notă: lista de mai sus va fi una benefică în final la preda-rea 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ăestedescompunereaînmodule/blocuriceaduc mai aproape de conceptul OOP.

2. Frizerul ortogonal: •Săneorientamcătreortogonalitate,adicăsămodula-riză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 •Celmaicunoscutacronimlegatdeideea:unsingurrezultat la o singură problemă. E important să nu încer-cam să repetăm codurile, modulele, interfețele care au aceeași funcționalitate.

4. Test it: testul cu oglinda•Testabilitateasoluțieiesteceamaivitalăpentruasusține o arhitectură robustă, dar totuși receptivă la schimbări.•Eimportantsădecidempânălaceniveldorimsătes-tă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ă:•Ebinedecreatmodulecare suportămodificărileși fix-urile, astfel încât să nu aibă impact asupra altor componente.•Încazulîncarefix-ul aduce modificări asupra mai multor module în același timp, e necesar de revizuit pla-nul inițial, dacă arhitectura chiar corespunde nevoilor noastre.

6. Cost of changes: plata la frizer•arhitecturarobustătrebuiesăsuporteschimbăricon-tinue, dar în același timp prețul schimbărilor trebuie să rămână minim.•Pentrucalcululcostuluischimbărilorsepoatefolosioecuație simplă care avertizează asupra riscurilor:

Sum( Change[1..n]x Sum(Affected Module[1..m]) ) = Cost of Change

•Unden,m reprezintă numărul maxim de schimbări și module.•Fiecareschimbareșimodularevaloare1,desigurdacămodulele sunt mai complexe putem defini pentru fiecare modul un cost specific.•Costulmaxim îlvomobținepentrucazul încare

Arhitectura extransibila si durabila (grow form novice to guru)

arhitectură



fiecare schimbare are impact asupra fiecărui modul.•Costul idealestede30%dincostulmaxim,costuloptim între 30% și 70%, iar costul critic peste 70% din costul maxim.

Exemplu: în cazul a 3 module , unde Modul3 are cost 3, pentru la 2 schimbări avem următorul cost:

o Change1 x (Module 1 + Module 2) + Change2 x (Module1+Module2+Module3) = 1x(1+1) + 1x(1+1+3) =2 +5=7o Cost maxim: Change1(Module1 + Module2 + Mod-ule 3) + Change2x(Module1+Module2+Module3)= 1x(1+1+3)+1(1+1+3)=10

o Cost Maxim : 10; Cost ideal: 3; Cost critic: 7.

În exemplul dat suntem la limită între costul critic și cel ideal, cea ce ne informează ca ar fi posibil ca arhitectura să fie afectată și să aibă consecințe majore.

C. Focus Point: de reținut•Săverificamcalitatea,metrica,redundanțamodulelorși a claselor;•Săverificămdacăarhitecturaaleasăsaustandardelede aliniere (Togaf, ISO etc) se mai mapează pe soluția curentă;•Săintroducempunctedecontrolpentruvalidareasoluției si a arhitecturi;•Săneamintimdelimiteledehardware,rețeasiacom-ponentelor integrate;• Să ținemminte că resursele sunt limitate (bani,dezvoltatori);

D. The Good is the enemy of The Perfect: să tindem la perfecționism•Defiecaredatăsăîncercămsaîmbunătățimcodulexistent.•Sănunelăsămpradăideilor: îmbunătățireanuseplătește, lasă că rezolvam cândva etc.•Respectămuncatașiaaltora.•Utilizeazăconceptul”Benefits+1”, întotdeaunasăaduci ceva în plus față de ce ți s-a cerut.•PROTOTYPE:creareadeprototipurineajutăsăfimsiguri că suntem pe drumul cel bun•DESENEZĂ:afișareagraficaaarhitecturiineaducebeneficiul vizual al unei analize rapide

Lista de mai sus se poate completa cu multe altele, astfel încât să fie una foarte complexă și satisfăcătoare, de fiecare dată însă trebuie luat in considerare BENEFICIUL adus prin introducerea noilor complexități.

În următorul număr al revistei TSM vom identifica niște „best practices” pentru a crea arhitecturi accesibile întregii echipe.


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 repre-zintă 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 elimi-narea 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 deta-lii. Exemple de IaaS: Virtual Machines, Servers, 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: închi-rierea de platforme complete pentru development ce includ sistemele de ope-rare, mediile de programare, bazele de date și web-serverele• NaaS – Network as a Service :

închirierea rețelei, serviciilor de inter-conectare, VPN, optimizarea resurselor alocate, șamd.

Câteva din avantajele oferite de Cloud ar fi mobilitatea, viteza, capacitatea de

stocare relativ nelimitată, puterea de pro-cesare ș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 servi-ciile de hardware vândute sau închiriate de Amazon, Google, Microsoft, etc.

Testarea în CloudTestarea este o provocare pentru multe

proiecte, în special pentru aplicațiile mari unde business-ul și performanța au de sufe-rit 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 neli-mitată ș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 costisi-toare, iar uneori nu este neapărat cea mai bună soluție la toate problemele de testare.

Așadar ce ar trebui luat în considerare

înainte să ne mutam testarea în Cloud?

A. Caracteristicile aplicațieiCloud-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 facemDintre 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 pen-tru 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 urmatAș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

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

QA

Testarea în Cloud



utilizator al aplicației le va face. Extragem testcase-urile și trecem la următoarea fază. Aceste două etape sunt sau ar trebui ori-cum 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 rezul-tatele 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 ime-diat următoare ținând cont de cerințele și

expectanțele pe care noi le avem.Al patrulea și al cincilea pas, Setup

Infrastructure și Leverage Cloud Servers presupun stabilirea hardware-ului necesar rulării testelor, calibrarea și optimizarea serverelor din Cloud ca să corespundă setup-ului de producție în care aplicația noastră va rula.

Evident, începem rularea testelor, monitorizarea și apoi extragerea rezul-tatelor relevante, a rezultatelor care ne interesează de fapt pe noi.

Flow-ul pare relativ ușor și simplu din schema de mai sus dar totuși ar fi câteva sfaturi pentru o migrare cu succes. Unul

dintre acestea este înțelegerea platfor-mei pe care se va muta testarea și a configurației aces-teia. Un alt punct de care trebuie ținut cont înainte să ne mutam în Cloud este identificarea tipuri-lor de testare ce se pretează a fi mutate din interiorul com-paniei în exterior. Nu toate se pretează sau merită a fi mutate.

Avantajele mutării in Cloud• C o s t u r i

reduse odată mutați în Cloud; scăpăm de grija întreținerii unui Cloud privat atât din punct de vedere a resurselor hardware cât și a resurselor umane implicate în acest scop.• Spațiu de sto-

care foarte mare și accesibil de oriunde; de pe device-ur i mobile dar și PC-uri• Ru l are a d e

teste automatizate ce au fost inițial înre-gistrate și verificate local;• Flexibilitatea

la schimbarea sistemelor de operare, browser-elor;• Mobilitate mare pentru departa-

mentul de testare, acolo unde acesta este distribuit în mai multe locații; aici testarea va avea un mare avantaj, timpul petrecut în sincronizarea environment-urilor de test scade la minim.• Relaxare în ceea ce pr ivește

mentenanța serverelor de test pentru că trecând pe Cloud, aceasta grija se exter-nalizează și ea

Dezavantajele mutării in Cloud• Configurația inițială presupune niște

costuri pentru mutarea testelor și adap-tarea acestora la environmentul nou pe care Cloud-ul le are. De aici se pleacă de obicei în luarea unei decizii dacă merită schimbat modul de testare curent sau nu;• Securitatea de asemenea poate repre-

zenta încă o problemă pentru anumite tipuri de aplicații;• Rezultate diferite provenite din

același testcase datorate schimbării performanței environmentului pe care providerul de servicii le poate avea;

ConcluziiVedem în jurul nostru tot mai multe

companii care oferă servicii de Cloud, în special de storage. Avem și companii ori-entate spre servicii mai specializate cum ar fi testarea. Decizia de a muta testarea în Cloud este până la urmă nu doar o decizie ce ține de factori tehnici ci și o decizie de ordin financiar. Avantajele pe termen scurt pentru o aplicație mare probabil nu vor fi vizibile, dar în timp cu siguranță acestea se vor face simțite, investiția fiind amortizată. Așadar, ne mutăm testarea în Cloud?

Referințe:http://cloudcomputing.sys-con.comhttp://wikipedia.orghttp://ieeexplore.ieee.org/xpls/abs_all.

jsp?arnumber=5463680

Vlad [email protected]

Senior QA Engineer@ Small Footprint


QA

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 utili-zate, 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 produ-selor folosite astfel încât ciclul de producție al unei versiuni să fie cât mai scurt.

În companiile IT românești, care imple-mentează metodologia DevOps, se folosesc adesea soluții specifice, dezvoltate intern, precum scripturi sau diferite utilitare. În cazul proiectelor dezvoltate în regim de out-sourcing 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 colabo-rarea între departamentele implicate. Din acest punct de vedere echipa de dezvoltare are, de exemplu, o viziune a calității dife-rită 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 comu-nicarea eficientă.

A doua problemă este aceea de inte-grare ș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 pro-duse 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 teh-nologiile referite sunt din lumea Java, iar această opțiune e justificată de experiența autorului în acest domeniu IT.

StrategiaPentru dezvoltarea unei soluții fiabile

și scalabile de testare automată, propunem observarea a trei aspecte: mediul de tes-tare, testabilitatea produsului și integrarea continuă

Mediul de Testare • Complexitatea – mediul de testare

Facebook, 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.

Orchestrarea Testării Automate

Lucian [email protected]

OO Content Arhitect@ HP Software Cluj



utilizat variază de la un server fizic, loca-lizat în proximitatea programatorului sau a testerului, până la centre de date complexe, bazate pe tehnologii de vir-tualizare 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 pro-duselor 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 auto-

mată 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 dispozi-tive de stocare nepersistente(o astfel de funcționalitate este oferită de VMware vCenter)

Testabilitatea Produsului• Instalarea - modul de instalare și

dezinstalare. De multe ori aplicațiile per-mit 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 nece-sară instalarea/dezinstalarea a diferitelor versiuni ale aplicației. Este recomandată

utilizarea modului silențios de instalare/dezinstalare, dar există și soluții alterna-tive 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 proto-coale precum SSH, WMI etc. .• Configurarea - opțiunile de con-

figurare a aplicației. După instalarea aplicației, pasul următor este configura-rea 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 uti-lizator, 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 impli-cate 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 prac-

tică 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 uni-tare. 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 diversi-tatea sistemelor am identificat Jenkins, Hudson și CruiseControl ca fiind cele mai utilizate în lumea DevOps.• Integrarea – pentru un proces

complet este necesară integrarea din-tre sistemul de build, testele unitare și produsele utilizare de echipa de testare

Figura 1 Provizionarea mediului de testare

Figura 4 Arhitectura generică TAO

Figura 2 Instalarea, configurarea și monitorizarea

Figura 3 Serverul de build invocă testete automate


QA

(HP ALM/QC, Jira, Selenium, HP UFT) precum și conectarea cu mediul de tes-tare. 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 tes-tare automată este ilustrat în Figura 4.

Soluția NoastrăP r o d u s u l H P O p e r a t i o n s

Orchestration(OO) automatizează pro-cesele 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.

În prezent, produsul oferă o librărie gratuită cu mai mult de 4000 de operații și

fluxuri care acoperă integrări cu tehnolo-gii precum HTTP, LDAP, SSH, WMI, Ant, PowerShell, integrări cu produse precum HP ALM, Jira dar și cu sisteme de virtua-lizare și cloud cum ar fi VMware vCenter, Hyper-V, Amazon EC2.

Utilizatorul are posibilitatea să folo-sească 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 împru-mutate 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 exem-plu o dată pe noapte, după fiecare build.

RezultateFolosind produsul OO am reali-

zat o suită de fluxuri de automatizare

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 persoa-nele cu minimă experiență în limbajele de programare.

Problema de integrare între diferitele tehnologii și produse este rezolvată folo-sind fluxurile și operațiile oferite de către acest produs. În Figura 5 sunt reprezen-tate câteva fluxuri utilizate folosind HP Operations Orchestration.

Abordări SimilareExistă 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, ser-vera 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

Orchestrarea Testării Automate



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

ViitorulUrmătorii noștri pași sunt extinderea

fluxurilor TAO care sunt necesare în dife-ritele scenarii DevOps precum integrarea cu produse de analiză a codului (Sonar) și cu aplicații de provizionare open-source. 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ă și să încurajeze accesul la fluxurile deja existente.

ReferințeHP Operations Orchestration, Official

Webpage, Hewlett-Packard, November 2012,

HP Op erat ions Orchest rat ion , 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

DevOps Webpage, November 2012.

Figura 5 Fluxuri HP Operations Orchestration


programaremanagement

OPTIONSABILITY

O caracteristică discretă a proiectelor IT

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 gene-ric, î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 fur-niza 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 pen-tru “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

O 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ă. Bogdan Matei

[email protected]

Senior Php Developer@ 3Pillar Global


TODAY SOFTWARE MAGAZINEprogramare

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ă pen-tru 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, smartpho-nes, 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 cali-tatea 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 succesu-lui. 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 între-barea “pentru cine?”, rezultatul este simplu dar surprinzător: pentru toți.

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 com-pania a raportat record la profitabilitate. A avea optiuni a ajuns să reprezinte un avantaj mai important decât a avea reali-zari în sine. Opțiunile sunt pentru afacere un rezervor de siguranță, o margine de flexibilitate, iar pentru proprietarul ei un confort care furnizează sentimentul încre-derii și libertății. În sine, aceste detalii pot parea lucruri nesemnificative, însă ele sunt motoarele care produc consecințe în deci-ziile importante.

Prin îndreptarea atenției și dincolo de scopul proiectului, către opțiuni, pe ter-men scurt este posibil să apară și o creștere a costurilor, datorită necesităților de cali-ficare 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 suscep-tibile să fie cerute sau avantajoase. Pentru selectarea lor este nevoie de comunicare între părți și o cunoaștere atentă. Pe ter-men lung însă (peste 1 an), câștigurile sunt incomparabile:

• crește eficiența prin reducerea tim-pului petrecut pentru “reinventarea roții”;• se realizează o bază de cunoștiințe și

unelte (re)utilizabile; • scade necesitatea rescrierii proiecte-

lor (coșmarul clienților);• ajută la realizarea mult doritelor

“best practice”;

• scade timpul dezvoltărilor, compen-sate 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 cres-terea 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 (develope-rul 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 entuzi-asmant și mai folositor. Odata codul scris astfel se adună o baza reutilizabilă, crește încrederea și se reduce stresul necunoscu-telor, 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 cunos-cute produse: Coca-Cola, BMW, Audi, Starbucks etc. Aproape că nu se promo-vează 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.



managementOPTIONSABILITY - 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 acti-velor 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 aces-tei 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 responsabi-litate mai ridicată). Întrucât principalii responsabili sunt tehnicienii, adeziunea lor la acest mod de a gândi este determi-nantă. 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 posi-bile 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, adap-tare, 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ă reco-mandare pe care pot s-o dau în acest sens este că implementarea unei soluții software este direct proporțională cu usurința comu-nicarii 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 vor-bind 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 “option-sability” ca al doilea scop nu este aplicabilă tuturor proiectelor! Nu vine ca o rețetă

prestabilită. Ea depinde foarte mult de context, de o analiză obiectivă a câștigurilor și costurilor. Din experiență, ea se pre-tează 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 asu-pra 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.


TODAY SOFTWARE MAGAZINE programare

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 SCADEMediul 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 circui-telor 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 con-trol 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 valo-rile 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 posibili-tatea de a defini propriile tipuri compuse (șiruri, enumerări, structuri) sau a importa tipurideclarateînCsauC++.Lafelesteposibil ș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 abs-tractizare 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ân-geri teoretice în timpul modelării, dar și printr-un pas de verificare a modelului creat. Aceasta din urmă asigură corectitu-dinea 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

Cerinț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 pro-vocare 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ă.

Dezvoltarea de aplicații safety-

critical în SCADE

Hunor [email protected]

Software Developer@ evoline


în mișcare. Setând valori pentru interfețele de intrare se poate verifica starea celei mai mici părți al acestuia: valorile variabile-lor, al fluxurilor de date între operatori și în interiorul acestora, tranzițiile și stările active al automatelor finite.

ExempluDe exemplu, să modelăm o aplicație care controlează un sis-

tem de închidere. Să fie valoarea de intrare starea unui buton de comandă (apăsat sau nu), iar valoarea de ieșire comanda de închi-dere 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:

În celălalt operator modelăm stările sistemului (închis/des-chis), și tranzițiile posibile între aceste stări, cu ajutorul unui automat finit. Condiția de activare a tranzițiilor este valuarea true a variabilei command.

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

Generare de cod CCu ajutorul generatorului de cod KCG putem

transforma modelele create într-un cod C com-pilabil, lipsit de erori low level de programare. Deoarece precondiția generării este un model valid, codul C păstrează calitățile teoretice – sin-cronicitate, determinism – al acestuia.

Integrarea codului se realizează prin apelarea funcțiilor C generate. Se poate crea o clasă wra-pper, 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ă abor-dare 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 sisteme-lor dezvoltate cu ajutorul SCADE.

Operatorul RisingEdge din exemplul precedent este transfor-mată în următoarea funcție C:

/* Playground::RisingEdge */void RisingEdge_Playground( 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;}

AvantajePrin dezvoltarea în SCADE se poate asigura un nivel de

calitate ridicat al aplicației pe tot parcursul procesului de dez-voltare, nefiind necesară folosirea altor instrumente în acest sens. Constrângerile teoretice al sincronicității, aplicate din pri-mul moment, oferă siguranța că rezultatul va face față cerințelor impuse aplicațiilor safety-critical: sistemul va avea o stare bine definită în toate condițiile și va reacționa într-un timp finit, ușor de definit și măsurat. În același timp diagramele sunt suficient de

Dezvoltarea de aplicații safety-critical în SCADEprogramare



auto-explicative ca să reprezinte un mijloc bun de comunicare între participanții în proiect.

DezavantajePunctele forte uneori însă devin și cele

slabe: abordarea grafică cere o atenție mult mai mare în cazul dezvoltării în echipă. În timp ce pentru obiectele textuale avem la dispoziție instrumente mature pentru a îmbina progresul făcut de mai mulți participanți, în cazul diagramelor grafice acest lucru este o provocare continuă, lucru imposibil uneori, și o situație mai bine de evitat.

Din cauza rigurozității limbajului, dependințele dintre fișierele de model sunt mult mai mari: de exemplu, interfețele între operatori trebuie să corespundă în mod exact pentru a avea un model valid, ceea ce necesită o cooperare mult mai strânsă între dezvoltatori.

SCADE ne oferă soluții limitate și de cele mai multe ori foarte greoaie pentru a trata structuri de date foarte mari și com-plexe. La fel, nu este soluția ideală pentru dezvoltarea aplicațiilor care implică efectu-area unor calcule intensive.

ProvocăriCea mai mare provocare la care pro-

gramatorul trebuie să facă față este să se obișnuiască cu abordarea sincronă. Foarte multe constrângeri, care în alte limbaje pot fi impuse numai prin tool-uri separate sau o arhitectură vizată, în SCADE constituie o parte integrantă a limbajului de bază și a mediului de dezvoltare, ruperea acestora fiind imposibilă chiar și în cazuri în care acesta ar fi un lucru dorit.

ConcluziiBazându-se pe un limbaj sincron,

SCADE impune ca însușirile cele mai importante ale aplicațiilor reactive – timp finit de execuție și stări bine definite în toate condițiile – să fie respectate pe tot parcur-sul procesului de dezvoltare. Generatorul de cod certificat facilitează transformarea modelelor create în cod C și integrarea în restul sistemului. Cu toate dezavantajele sale, mediul de dezvoltare SCADE este o soluție matură și potrivită pentru dezvol-tarea aplicațiilor safety-critical.


programare

Î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 clien-tul 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 costi-sitoare - 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

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 scalabili-tatea și modul unic prin care datele sunt procesate și stocate. Pe toată perioada dez-voltă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 moto-rul 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 pen-tru 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

Cu 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 noas-tră, 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.

Trenduri și Big Data

Radu [email protected]

Senior Software Engineer@iQuest


TODAY SOFTWARE MAGAZINEmanagement

precum este astăzi. La început scalabili-tate 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 ase-mănător, care încerca să rezolve aceeași problemă. La ora actuală acesta ajunge să fie un sistem robust care poate să fie folo-sit 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 cos-turi minime.

Stocarea datelor - HDFSModul î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 sto-care 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

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.

1. Management la sub-sisteme 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ân-dit 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 compo-nentele î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, sto-chează 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.

2. Accesul la dateSistemele normale de stocare de fișiere

au ca principal scop stocarea datelor, iar în cazul în care avem nevoie de aceste date

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 tre-buie 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 sis-tem 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 sto-cate, odată ce sunt procesate ajung să fie șterse și niciodată modificate.

3. PortabilitateÎ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ă proprie-tate 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.

4. NameNode și DataNodeDacă analizăm arhitectura unui

astfel de sistem este necesar să introdu-cem în vocabularul nostru doi termeni: NameNode și DataNode. Este un sistem de tip master-slave.

NameNode este „the master” sistemu-lui 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 fișierele, el doar ocupându-se cu maparea fișierelor, știind în fiecare moment locație unde aceste sunt stocate. Odată ce numele a fost rezolvat de către NameNode, acesta va

Figură 1: Ecosistemul Hadoop



programareTrenduri ș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ă compo-nentă 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 checkpoint-uri pentru NameNode.

5. Stocarea datelorToate 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ă

prin NameNode.

6. Structura fișierelorModul î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 hard-link sau soft-link nu sunt suportate de către HDFS.

7. ReplicareDeoarece datele stocate sunt foarte

importante, HDFS ne permite să setăm numărul de copii pe care dorim să le avem pentru fiecare fișier. Acesta se poate seta în momentul în care creăm fișierul sau ori-când după acest moment. NameNode-ul este cel care cunoaște numărul de copii care trebuie să existe pentru fiecare fișier și are grijă ca acesta să existe.

De exemplu când creștem numărul de replicări pe care dorim să le avem pentru un fișier NameNode-ul o să aibă grijă ca toate blocurile de date să fie replicate încă o dată. Treaba NameNode-ului nu se termină în acest moment. De la fiecare bloc în parte acesta primește un semnal de tip „sunt în viață” la un interval specific de timp – heardbeat. În cazul în care unul din blocuri nu trimite acest semnal, NameNode-ul va înceape procedura de recuperare în mod automat.

Modul în care datele se replică este extrem de complex. HDSF trebuie să țină cont de foarte mulți factori. În momentul în care este nevoie să se facă o noua copie, trebuie ținut cont că aceasta acțiune o să consume lățimea de bandă. Din acestă cauză avem un load-balancer care se ocupă de distribuirea datelor în cluster. Există

mai multe opțiuni pentru replicare, una din cele mai des întâlnite este în care 30% din replici să fie pe același nod. Din punct de vedere a ldistribuirii repli-cilor pe rack-uri , doua treimi sunt pe același rack, iar cealaltă parte este pe un rack separat.

Datele dintr-un DateNod pot

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, clien-tul 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.

8. NamespaceNamespace-ul pe care NameNode-ul îl

are este stocat în memorie RAM, putând să fie accesat cu ușurință. Acesta este replicat pe hard disk la intervale foarte bine stabi-lite – numele imaginilor care se scriu pe disk poartă numele de FsImage. Din cauză că copia de pe disk nu este 1 la 1 cu cea din memoria RAM, există un fișier în care sunt scrise toate modificările care se fac asupra structurii fișierelor sau a directoa-relor - EditLog. Prin acest mod în cazul în care se întâmplă ceva cu memoria RAM sau cu NameNode-ul, recuperarea acestuia este simplă și poate să conțină și ultimele modificări.

9. Manipulare date Un lucru extrem de interesant este

modul în care un client poate să creeze un fișier. Inițial, datele nu sunt stocate direct in DataNode, ci într-o locație temporară. Doar în momentul în care există destule date pentru ca o operație de scriere să merite, doar atunci NameNode-ul este notificat și copiază informația in DataNode.

În momentul în care un client dorește să șteargă un fișier, acesta nu este șters fizic din sistem. Fișierul este doar marcat pen-tru ștergere și mutat în directorul trash. În trash este ținută doar ultima copie a fișierului, iar clientul poate să intre în acest director pentru a o recupera. Toate fișierele din trash sunt șterse în mod automat după un anumit interval de timp.

Concluzie În cadrul acestui articol, am pre-

zentat cum a apărut Hadoop, care sunt proprietățile sale principale și modul în care datele sunt stocate. Am văzut ca HDFS este un sistem creat să lucreze cu multe date. Acest lucru îl face extrem de bine și cu costuri minime.

În următorul număr vom vedea cum putem să procesăm această informație.

Figura 2


TODAY SOFTWARE MAGAZINE programare


Istoria a făcut ca limbajele de pro-gramare 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 calculato-rului. Dar foarte puțini știu că paradigma imperativă nu reprezintă decât unul din-tre cele patru modele de calcul inventate de matematicienii ce au pus bazele științei calculatoarelor. Foarte diferite, aceste para-digme 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 mode-lul 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 lim-bajului 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 asam-blarea 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 catego-ria 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 cerce-tarea î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, des-tul de folosit în domenii diverse precum inteligența artificială, securitate, dezvol-tarea aplicațiilor web sau a sistemelor de operare. Multe din noutățile ce au fost introduse în limbaj au ajuns mai târziu și înC++,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 limba-jul 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 pen-tru 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 exem-plu, 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 wherelesser = 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 declara-tiv: 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 impor-tant: 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ă transfor-marea celor mai frecvente erori de runtime și bug-uri în erori de compilare. De exem-plu, 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

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


programare

întors de aceste funcții este verificată. La extrem, s-au creat framework-uri de dez-voltare 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 exte-riorul (citire date, transmitere date, etc), Haskell oferă și el funcții pentru operațiile de intrare-ieșire. Dar, acestea vor fi mar-cate 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 mate-matică: este o structură infinită, dar poate fi reprezentat finit printr-o recurență și când îi scrieți termenii, vă opriți mereu după pri-mii 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ă eva-luarea 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 evi-dent 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 bug-urilor în momentul în care acestea apar.

Codul Haskell poate fi interpretat sau compilat. Se recomandă folosirea sui-tei 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 exe-cutabil 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 identi-tate pentru a se ajunge înapoi la permutarea identitate). De exemplu, pentru permutarea (3 4 2 1 5), răspunsul cău-tat 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).

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ăuga-rea 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 [] = 0length (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 low-level ș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 pen-tru 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 [] = 0sum (x:xs) = x + sum xs

product [] = 1product (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 tre-buie 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):




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 argu-mente actualizat cu rezultatul parțial de până atunci. Diferența între cele 2 poate fi observată și din imaginea următoare.

Alte două pattern-uri importante cap-turate de Haskell sunt map și filter. Le vom ilustra direct prin imaginea următoare și codul următor:

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

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 pro-gramarea 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

în care predicatul devine True.

computeOrder :: [Int] -> IntcomputeOrder perm = fst $ until test f $ f init where l = length perm - 1 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 inter-pretorul ghci:

*Main> computeOrder [3,4,2,1,5] 4

Rezultatul este 4, exact cum ne așteptam. Putem testa să vedem dacă rezul-tatul 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, pro-fită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 [email protected]

IxNovation @ IXIAmembru ROSEdu, ARIA


business

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 compli-cat, 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 deose-bire de SOAP, REST nu necesită parsare de

XML, nu necesită un header de mesaj către și de la service provider. Datorită protoco-lului 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.

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

programare

Recenzia cărții:RESTful Web Services Cookbook

de Subbu Allamaraju





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 dato-rate 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 template-urilor URI este eficientă deoarece conferă dinamicitate unui URI, clienții putând

să-și includă informații adiționale în URI înaintea trimiterii cererii către server.

For m ate l e Atom ș i AtomPub definesc resurse precum entries și feeds, reprezentarea lor și un pro-tocol de operare pe aceste resurse. Serviciile web REST suportă acest tip de for-mat, pe lângă cele anunțate anterior.

De la capitolul 7 încolo autorul prezintă, ceea ce aș numi elemente avan-sate în cadrul serviciilor REST. Primul subiect atins este acela al negocierii conținutului, mai precis indicării preferințelor clien-tului precum: tipurile media suportate, limba, codarea caracterelor, etc. .

Problema folosirii cache-ului este foarte importantă

pentru că bine folosită conduce la scăde-rea î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ă provocare ce conduce la performanță este dată de cereri condiționale. Acestea adresează două pro-bleme: pentru cereri GET ajută clienții și cache-ul să identifice dacă o anumită reprezentare poate fi considerată proas-pătă, iar pentru cereri PUT, POST și DELETE cererile condiționale furnizează controlul concurenței. Controlul concu-rent este implementat în două feluri:

• Concurența pesimistă: clientul blo-când resursa,• Concurența optimistă: prin intro-

ducerea unui token de versiune ce se validează.

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 impor-tante 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 exten-sibilitate și versionare și face referiri la menținerea compatibilităților URI, a

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 din-tre 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

business


Partea idealistă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 finan-ciar imediat, în general pentru patroni de departe. Riscul asupra firmelor rămâne ridi-cat, 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 comuni-tatea 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 par-ticularităţile acestei industrii și unele căi de a se dezvolta. Dorim să contribuim la con-struirea unei comunităţi solide și durabile în Cluj. Iar aici nu este vorba de idealism – firme solide înseamnă afaceri bune, win-win pentru toţi.

Pentru aceasta am demarat “pro-bono” un proiect de cercetare, în care să ne întâl-nim trimestrial, în discuţii de 1-2 ore, cu un grup de oameni de HR din firme de IT clu-jene. Scopul acestor întâlniri dorim să fie:

a. Analiza problemelor cu care se con-fruntă și găsirea de soluţii utile pentru participanţi și firmele lor,

b. Identificarea unor practici manage-riale 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 cerce-tări știinţifice pe care o vom furniza celor interesaţi.

După fiecare întâlnire vom face publice

Multă 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?

HR

SPRE COMUNITATEA IT – via HR

Dan [email protected]

Director Executiv@ Danis Consulting

Cristina [email protected]

Consultant@ Danis Consulting



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 com-portamente 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: fac-torii 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 favori-zează „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 orga-nizaţiilor din IT, urmând ca în întâlnirile

următoare să aprofundăm aceste dezbateri, să intrăm mai în detaliu cu unele subiecte precum: „Care este stilul de conducere cel mai potrivit oamenilor din IT?” sau „Cum reușiţi să construiţi munca în echipă – ade-vărată, cu colaborare, comunicare și ajutor reciproc?”

Ideile cele mai valoroase împărtășite în acest prim workshop le prezentăm în con-tinuare structurate pe câteva capitole mari:

1. Activitatea de dezvoltare a oamenilor din ITÎn acest domeniu există de regulă

abordarea logică: de a interveni pentru dezvoltarea unei anumite arii atunci când se observă, se sesizează o nevoie specifică. Ne-am bucurat să auzim că managementul din companii a ajuns la concluzia că trai-ning-urile pe un anumit subiect – mai ales legat de abilităţi de relaţionare, de lucru în echipă, de comunicare – nu sunt sufi-ciente pentru dezvoltarea sau schimbarea unui anume comportament. iQuest-ul are o serie de exemple clare în această direc-ţie. De asemenea, Accesa a implementat recent un Program de Dezvoltare complex care a ţintit echipa de conducere și eșalonul imediat următor de conducere, program în care s-au combinat activităţi de tip training cu stabilire și implementare de obiective de dezvoltare individualizate, cu asistenţa con-sultanţilor de specialitate.

Acesta este unul dintre principalele motive pentru care de câţiva ani buni încoace și noi, în calitate de companie de consultanţă în domeniul dezvoltării, ne străduim să „propovăduim” programele de dezvoltare și nu doar cursuri, care să con-ţină și alte tipuri de acţiuni (workshop-uri de follow-up, sesiuni de coaching de grup sau individual, proiecte aplicative etc.) și care să fie întinse pe o perioadă mai lungă de timp, în așa fel încât să permită exersarea noilor abilităţi, fixarea lor în context de muncă real.

Pe lângă aceste abordări firești ale pro-cesului de dezvoltare a angajaţilor, în ISDC de exemplu, am descoperit și o abordare mai „altfel”. Oamenii de Resurse umane își asumă o mare parte din activităţile de dezvoltare – conducând training-uri și team-building-uri în interior conform unor sisteme și proce-duri bine stabilite. Fiind aproape de colegii lor, ei pot să intervină și preventiv, nu doar atunci când sunt probleme.

2. Sisteme şi procese de succes în companiile din IT

Sistemele și procesele de Resurse Umane tind să fie percepute de către angajaţii din IT ca birocratice și, ulterior, să fie respinse. Soluţii pentru implementarea cu succes a

unor astfel de instrumente pot fi:• Utilizarea managerilor pentru flexibi-

lizarea unor procese. Dacă conducătorii dintr-o companie (de la diverse nivele) au răspunderea pentru anumite evalu-ări, decizii, intervenţii legate de oameni, atunci sistemele pot fi mai flexibile și mai ușor de implementat.• O altă soluţie este ca sistemele să

decurgă natural din practici curente de succes, pentru a nu avea cum să fie res-pinse. Este și experienţa celor de la ISDC care au nivelul 3 de certificare CMMI, bazându-se pe procesele existente.

Din discuţiile purtate s-a agreat însă fap-tul că implementarea unor sisteme și bune practici mature, se poate realiza cu succes în organizaţii cu oameni maturi în atitudine.

Sperăm ca în întâlnirile următoare să aprofundăm mai mult sistemele de evaluare a performanţelor din diverse companii. De data aceasta, Răzvan Voica de la iQuest ne-a oferit o imagine sintetică a sistemului din compania lui de „career management” – cu scopul de evaluare și dezvoltare a oameni-lor din companie. Este un sistem extrem de interesant și complex în care se pune mult accentul pe responsabilitatea managerilor din companie pentru dezvoltarea angajaţilor. Simplificând, fiecare lider din companie este și un „career manager” pentru un număr de angajaţi. El are responsabilitatea de a-i ghida, pe cei angajaţi, în procesul lor de dezvoltare. De aceea, în cazul managerilor din iQuest, abilităţile de comunicare și cele complexe de coaching sunt extrem de valorizate.

3. Elementele de cultură organizaţională şi cult al muncii în IT

Reprezentanţii companiilor prezenţi la acest workshop recunosc tendinţa pe piaţă spre o mai mare flexibilizare și indepen-denţă a forţei de muncă, însă în același timp, admit că nu sunt încă pregătiţi pentru așa ceva. IT-iștii seniori pot să aprecieze mai mult timpul flexibil, de exemplu la ISDC s-a implementat un sistem de lucru de acasă o dată pe săptămână pentru angajaţii care au peste 6 luni în companie. Cei juniori și nu numai, „până la un anumit moment al cari-erei manifestă nevoia de apartenenţă la un grup / la o comunitate” ceea ce angajarea într-o firmă de IT le poate oferi. Deocamdată, piaţa de IT din Cluj nu este încă suficient de matură pentru a permite unui angajat IT o libertate de genul: atunci când intru într-un proiect să pot avea și libertatea să intru și în alt proiect, al altei companii, în paralel.

Fortech-ul a aplicat o reţetă de cultură organizaţională extrem de deschisă și caldă



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ţio-nală, valori fundamentale – acele lucruri apreciate într-o companie – am ajuns împreună la o concluzie desprinsă din practica celor prezenţi: pentru ca o organi-zaţie din IT să-și asigure stabilitate în timp este mare nevoie în primul rând să-și stabi-lească 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 potri-viţ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 inter-viuri nu le strălucesc ochii când le spunem despre tehnologii, nu sunt oamenii potriviţi pentru noi.”.

4. Actul de conducere în companiile ITUn alt subiect prin care doar am „zgân-

dă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:

„Leadership-ul este crucial in orice organizatie care abordeaza dezvoltarea sis-tematica 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 fondato-rii 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 lideru-lui din vârful companiei și, chiar dacă am găsit stiluri diferite de carismă la compa-nii 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ă.

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

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

– lucruri care sunt importante și valorizate în cultura ISDC-ului.

Răzvan Voica (iQuest) are un backgro-und „vechi” în IT (din 1997), având o diversitate mare de experienţe profesio-nale, inclusiv ca și programator. Din 2011 a ajuns în echipa de management a compa-niei iQuest – unul din jucătorii importanţi pe piaţa IT-ului din Cluj (și nu numai). Recunoaște că această poziţie – de mana-gement î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 pasi-une 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.

HRSPRE COMUNITATEA IT – via HR



Într-un mediu dinamic în care compa-niile 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 indi-catorii 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 perspec-tiva prețului, calității, flexibilității și al relațiilor cu clienții. Managerii au dezvol-tat 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ță ridi-cată, 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ă interpre-tare 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 fir-mei. Această arie are ca funcții importante: recrutare și selecție, evaluare, instruire, motivare și recompensare și partea legis-lativă și administrativă.

Conceptul de resurse umane este o umbrela pentru noțiunea de perso-nal, î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 „mana-gementul 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 impresio-nante care susțin descoperirea potențialului printr-o dezvoltare continuă, personală și profesională.

Este foarte important ca persoa-nele 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 talen-tului. Prin performanță se evaluează obiectivele individuale și ale echipei, care sunt în concordanță cu obiectivele stra-tegice ale companiei. Pentru ca firma să câștige acel avantaj competitiv pe o piață în continuă evoluție trebuie să valorifice talen-tele 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ă poliva-lentă. 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 lite-raturii de specialitate.

L e b a s ( 1 9 9 5 ) c a r a c t e r i z e a z ă 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 tre-buie 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 individu-ale ș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 lua-rea deciziilor strategice.

Managementul perfomanței la nivel operațional se referă la managementul operațiunilor, deoarece se centrează pe atingerea obiectivelor și țintelor depar-tamentelor, de proiect sau ale echipei. Federick Taylor a dezvoltat conceptul de management științific. La începutul ani-lor ’20 General Motors a experimentat acest concept prin introducerea graficului DuPont pentru a susține reorganizarea companiei în structuri descentralizate cu


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

HR



HR

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 com-paniilor 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 filo-zofia japoneză.

Managementul performanței la nivel individual este considerat ca reflectând nivelul de maturitate organizațională. La începutul anilor 1800, Owen a moni-torizat performanța angajații lor ca indivizi ce îndeplineau sarcini ca parte a unui grup. Până după cel de-al doilea război mondial, sistemul de managemen-tul performanței era utilizat mai mult în domeniul administrației publice, militare și fabrici industriale. Începând cu anii 90 managementul performanței individuale a fost reorientat pe două tendințe. Prima însemna creșterea popularității auto-eva-luării performanței, iar a doua tendință alinierea managementului performanței strategic și managementul performanței individuale prin crearea unor noi instru-mente precum Balanced Scorecard, care avea ca obiectiv reflectarea obiectivelor organizaționale în cele individuale.

Fundamentele procesului Managementul performanței are

ca scop creșterea responsabilității de a produce rezultate și de a-și îmbunătăți abilitățile și competențele. În cadrul com-paniei, managementul performanței a fost întotdeauna considerat un aspect pentru managementul resurselor umane pentru atingerea obiectivelor organizaționale, printr-o aliniere cu strategia organizației, valorile și cultura acesteia.

Procesul și InstrumenteleConform acestei figuri fazele proce-

sului de managementul performanței se vor descrie etapele procesului așa cum

se desfășoară el, pe parcursul unui an în companie.

• Definirea celor patru faze ale pro-cesului: (1) Definirea așteptărilor, (2) Evaluarea intermediară, (3) Revizuirea lunară a obiectivelor și (4) Evaluarea finală a performanței.

Procesul de managementul perfomanței are două caracteristici esențiale:

• Accentuarea CE-ului (a rezultate-lor), a CUM-ului (a metodelor prin care rezultatele sunt atinse) si a UNDE-ului (plan de dezvoltare personală, obiective profesionale). • Îmbunătățirea comunicării între

manager și angajat prin crearea unui dialog continuu care să aibă la bază feed-back și coaching.

Elementele procesului de management al performanței

Evaluarea performanței trebuie să reflecte așteptările, iar realizările sunt ori-entate pe obiective și valori. Mai mult decât atât ele trebuie să răspundă așteptărilor clienților.

În continuare voi prezenta modul în care este definită legătura între valorile organizației și procesul de managementul performanței. Valorile care fac parte din

CUM-ul procesului de management al perfomanței reprezintă modalitatea prin care fiecare angajat își îndeplinește sarcinile și își realizează obiectivele. Prezentarea în detaliu a valorilor organizației, semnalează descriu un set de competențe pe care fie-care angajat trebuie să le dezvolte la cel mai înalt nivel.

Luând ca exemplu Inovația ca valoare a unei companii sau manifestarea unui comportament: “suntem intuitivi, curioși, practici și inteligenţi, ceea ce ne oferă posibi-litatea să dezvoltăm noi idei pentru clienţi, afacere și angajaţi. Prin operaţiunile globale pe care le dezvoltăm, încurajăm idei în orice regiune a lumii”. Comportamentul încurajat este “anticipează tendințele viitoare și iden-tifică oportunitățile pe care capitalizează. ”. Cum se măsoară acest comportament pentru fiecare obiectiv? Înseamnă setarea așteptărilor și a modului prin care angajații pot să își îndeplinească obiectivul luând în considerare comportamentele încurajate de acestea.

Cea de-a doua parte a articolului va oferi detalii despre mijloacele procesului de managementul performanței. Până la următorul număr, succes în definirea pro-cesului și a instrumentelor care se potrivesc cel mai bine companiei din care faceți parte.

Figura 1 Fazele procesului de managementul performanței

Figura 2 Procesul de managementul perfomanței


Andreea Pâ[email protected] în cadrul Endava



nu se întâmplă.Suntem foarte motivaţi! Suntem foarte

motivaţi?

Definim motivaţia ca acea energie care ne mobilizează să iniţiem o acţiune și apoi ne face să o menţinem la frecvenţa și inten-sitatea dorite.

Dar ce este motivaţia? În primul rând 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 simţiţi vinovaţi.

Pentru asta vom folosi o definiţie de lucru a motivaţiei:

Motivaţia este acea energie care ne face să considerăm că efortul de a face un anumit lucru este mai mic decât con-secinţele apărute ca urmare a realizării acelui lucru.

Orice acţiune necesită efort. Efortul respectiv trebuie să merite să fie depus. Merită să fie depus atunci când ca urmare a efortului se întâmplă ceva care este mai relevant sau mai important ca beneficiul nedepunerii efortului.

Ei bine, mai este un mic detaliu. Noi știm deja ce e scris mai sus despre moti-vaţie. Dar mai e un mic detaliu legat de consecinţe și de cum ar trebui să fie ele.

Când ne gândim să ne apucăm de sport ne gândim la asta în termeni de toate bene-ficiile pe care le-am obţine dacă am face-o. Asa e? Ne propunem să ne apucăm de sport pentru că viaţa va fi mult mai frumoasă dacă am face-o. Problema este că noi ca oameni nu funcționăm așa.

Vă provoc la un joc. În poza de mai jos este un desen a unui iepure (fiecare figură are o etichetă lingvistică). Întrebarea pe care vă rog să v-o adresaţi este:

Iepurele va fugi mai repede și pe o dis-tanţă mai lungă în care dintre cele două situaţii?

Când este fugărit de un lup fioros sau când are un morcov gustos în faţă?

Răspunsul este că va fugi de lup mai mult și mai repede. Probabil se va porni sa alerge si după morcov însă când va deveni foarte obosit va spune “Nu mi-e atat de foame. Morcovul e acru.”

E bine să nu existe numai lupi, e bine să avem și morcovi după care să alergăm. Dar morcovii singuri nu vor face iepurașul să își zburlească blăniţa pentru foarte mult timp.

Dacă știm asta la nivel teoretic, de ce nu o aplicăm și în practică?

Dacă ne-am stabilit un obiectiv pentru a avea anumite beneficii, haideți să ne gân-dim și la tot ce pierdem sau la consecințele negative care ar rezulta din neîmplinirea acestuia.

Pentru că dimineaţa când trebuie să ne trezim, să ne luăm adidașii și să ne apu-căm de alergat, toate lucrurile bune nu vor părea că fac să merite efortul.

“Da, așa bine mă voi simţi după ce alerg, voi avea energie toată ziua, voi gândi mai limpede, voi fi mai agil, voi fi mai fericit. Da, dar așa de bine e sub pla-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 pla-pumă, 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ă mobili-zează ș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 – DRIVEBF Skinner – Beyond Freedom and

Dignity

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

Poate da ... poate nu ...

Vorbesc 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

HR

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


Imagine Cup este o competiție anu-ală 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 responsabilita-tea 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ță teh-

nologiile 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 teh-nologie 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 pen-tru a construi jocul nostru extraordinar. Aveam un sistem de input funcțional și

un schelet pentru sistemul grafic. Scrisesem de ase-menea un plugin pentru Blender care expor ta 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 pen-tru 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 weekend-uri, 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 constru-

ite 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

în doar două dimensiuni. Lumea jocului va fi plină de tehnologie extraterestră. Puzzle-urile 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 exem-plu, 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 mer-gea proiectul.

UnityOdată ce am găsit ideea generală, a tre-

buit 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 foru-murile 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 propriu-zis. 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

startup

Roller Coaster-ul Imagine Cup



tot ce ne era necesar, inclusiv un editor foarte bun pe care îl puteam folosi să tra-gem 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 sim-plu de conturare pentru a marca cuburile selectate. Acest lucru a fost dezamăgitor deoarece aveam cunoștințele necesare pen-tru 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...

XNAUltima 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 urma să se ocupe de integrarea sistemului de fizică și implementarea logicii jocu-lui, Adrian urma să creeze sistemul grafic

și shader-ele iar Timotei urma să lucreze pe partea de interfață utili-zator și sistemul de intrare (tas-tatură, mouse, Kinect, etc). Am început să dez-voltăm, încetul cu încetul, folosind Skype pentru a comunica zilnic. Ideea jocului s-a s chimbat de-a lungul proiectu-lui. 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 pro-bleme au fost din cauza modului în care era unghiul camerei sau felul în care tex-turile 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 expor-tat fiecare piesă separat (o roată, o șenilă și un corp) iar el le-a folosit pentru a construi robotul ca un sistem de componente simu-late 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 luat-o în legătură cu design-ul jocului.

În aprilie a trebuit să trimitem jocul pentru runda de calificare în ciuda faptu-lui că nu era nici pe aproape gata. Echipa a lucrat toată noaptea dinaintea rundei pen-

tru a crea un demo jucabil, programând non-stop. Am adău-gat funcționalități și am fixat bug-uri fără să clipim. Dimineața devreme am asam-blat împreună câteva înregistrări din joc într-un trailer epic, ce înfățișa un robot c u r a j o s l u p t â n d împotriva unui uni-vers nemilos. Da, da, știm, nu avea nicio

legătură cu jocul nostru, iar judecând după grafică... era un dezastru. Majoritatea tex-turilor 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 [email protected]

internship student@ Tora trading


Gogu îș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

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

Speaker, trainer și consultant în managementul proiectelor,

Owner al Confucius Consulting

diverse

Gogu și plinul de benzină

powered by

sponsori

tsm_11_2013_1ro

Documents