Today Software Magazine N11/2013

Nr. 11 Mai 2013 www.todaysoftmag.ro www.todaysoftmag.
com
TSM
are w t f o S
T O D A Y S O F T WA R E MAG A Z I NE
hip s n a sm t f a r C
loud rdur C a C n rea are w t f o Testa s tului c e t i a arh i r t Buc
narii e c S i de
Programare Funcional n Haskell Trenduri i Big Data Arhitectura extransibila i durabil S uitm de modelul Silicon Valley OPTIONSABILITY - O caracteristic discret a proiectelor IT (un) prieten pentru startup-uri Istoria IT-ului Clujean (V) - nvturi din Junimea SPRE COMUNITATEA IT via HR
ITCamp 2013 Orchestrarea Testarii Automate Recenzia crii: RESTful Web Services Cookbook JAVA EE7. Cloud, Web 2.0+ Dezvoltarea de aplicaii safety-critical n SCADE Managementul performanei Roller Coaster-ul Imagine Cup Gogu i plinul de benzin
6 S uitm de modelul Silicon Valley

Bogdan Iordache
28 OPTIONSABILITY - O caracteristic discret a proiectelor IT

Bogdan Matei
7 ITCamp 2013
Mihai Ttran
31 Dezvoltarea de aplicaii safety-critical n SCADE

Hunor Csomortani
8 (un) prieten pentru startup-uri

Cosmin Mihaiu
34 Trenduri i Big Data

Radu Vunvulea
10 JAVA EE7. Cloud, Web 2.0+

Silviu Dumitrescu
39 Programare Funcional n Haskell

Mihai Maruseac
11 Istoria IT-ului Clujean (V) - nvturi din Junimea

Marius Mornea
40 Recenzia crii: RESTful Web Services Cookbook de Subbu Allamaraju

Silviu Dumitrescu
13 Software Craftsmanship
Alexandru Bolboac i Adrian Bolboac
42 SPRE COMUNITATEA IT via HR

Dan Ionescu i Cristina Nicule
16 Din buctria arhitectului software - carduri de scenarii

Attila Antal
45 Managementul performanei
Andreea Prvu
19 Arhitectura extransibil i durabil

Levente Veres
47 Poate da ... poate nu ...

Antonia Onaca
22 Testarea n Cloud
Vlad Zeciu
48 Roller Coaster-ul Imagine Cup

Alex Pana
24 Orchestrarea Testrii Automate

Lucian Revnic
50 Gogu i plinul de benzin

Simona Bonghez, Ph.D.
editorial
Ovidiu Man, PMP
ovidiu.matan@todaysoftmag.com Fondator i CEO al Today Software Magazine
uzz-ul din ultimele luni este crearea structurilor i a oportunitilor pentru dezvoltarea IT-ului i poate mai mult ca oricnd apariia unor soluii romneti prin stimularea startup-urilor. TSM a fost i rmne un promotor al acestora dar nu dorim s cdem n extrema cealalt i s nu vedem pdurea din cauza copacilor. Probabil 90% din zona de IT, exceptnd afacerile cu statul romn, reprezint outsourcing realizat pentru companii din exterior. Problema major care apare este lipsa IP-ului (intellectual property), respectivele companii putnd s i mute centrele de dezvoltare oricnd n alt loc. Pe de alt parte, s nu scpm din vedere ce au fcut pentru noi companiile de outsourcing i ce pot s fac n continuare. n primul rnd ne-au nvat 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 specialitii romni, iar acum noi i nvm pe alii. La fel se va ntmpla i cu crearea de produse. Companiile, care pn nu demult aveau doar execuia n Romnia, au ncredere n noi dorind acum s crem produsele pentru care ei sunt business owneri. Pe piaa de munc se vede aceasta, iar lipsa de business analiti i de product management nu trece neobservat. Nu sunt muli, dar vor fi n civa ani i vor avea n CV realizri 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 romneti. Aadar, pentru a avea la scar larg apariia 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 excepii, cum am vzut n industria de jocuri sau n cea de divertisment. Incubatoarele de startup-uri i spaiile co-work ncep timid s i fac apariia iar noi vom publica ncepnd cu numrul urmtor o analiz a celor existente. E important ca un nou startup s tie de la nceput cui s se adreseze pentru finanare sau suport. Aa cum ne-am ateptat, luna mai este plin de evenimente n zona IT-ului: n 14 Mai vom avea Software architecture workshop organizat de ctre Arobs i care l are ca invitat pe Simon Brown; n 16 Mai, tot la Cluj va avea loc a doua ediie a Romanian Testing Community; n 17 Mai .msg systems organizeaz workshop-ul Java EE 7 susinut de ctre Silviu Dumitrescu; n 23-24 Mai vom avea ITCamp, cea mai mare conferin pe tehnologii Microsoft din Romnia iar n 30-31 Mai, n Bucureti are loc I T.A.K.E. Unconference pentru cei ce doresc s ating o excelen tehnic. Doresc s menionez i ICT Spring Europe care se va desfura n 19-20 Iunie, n Luxemburg. Evenimentul va reuni 3,500 de participani din Europa, iar startup-urile beneficiaz de participare gratuit. Acestea vor avea ocazia s i prezinte soluiile n cadrul evenimentului. Cei care vor doar s participe la eveniment, vor beneficia din partea TSM de o reducere de 50%. i rugm pe cei interesai s ne scrie pe adresa redaciei contact@todaysoftmag.com. Numrul 11 TSM v propune o serie de articole interesante acoperind sfera de interes din acest domeniu. La seciunea startup-uri articolul S uitm de modelul Silicon Valley (aka Ft Frumos din Vale i Merele de Siliciu), este o analiz obiectiv a acestui fenomen. n un prieten pentru startup-uri, este vorba de Marius Mocian i suportul acordat de acesta pentru MIRA. Aceast seciune este ncheiat de ctigtorii din acest an ai Microsoft Imagine Cup care ne povestesc evoluia produsului de la concept la implementarea final. Software Craftsmanship este un domeniu destul de puin cunoscut i m bucur c putem publica un articol pe aceast tem. Arhitectura software este prezent prin articolele: Din buctria 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. Continum cu Dezvoltarea de aplicaii safety-critical n SCADE i o nou serie despre Programare Funcional n Haskell. Primele rezultate ale studiului pentru realizarea unor Best Practice-uri n HR sunt publicate n acest numr 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 plcut !!!
Fondator i CEO al Today Software Magazine
Ovidiu Man
nr. 11/Mai, 2013 | www.todaysoftmag.ro
TODAY SOFTWARE MAGAZINE

Lista autorilor Redacia Today Software Magazine
Fondator / Editor n chief: Ovidiu Man ovidiu.matan@todaysoftmag.com Editor (startups i interviuri): Marius Mornea marius.mornea@todaysoftmag.com Graphic designer: Dan Hdru dan.hadarau@todaysoftmag.com Colaborator social media: Rodica Manolache rodica.manolache@todaysoftmag.com Traductor: Cintia Damian cintia.damian@todaysoftmag.com Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com Produs de
Alexandru Bolboaca Hunor Csomortani
Software Developer @ evoline
alex.bolboaca@mozaicworks.com Agile Coach and Trainer, with a focus on technical practices @Mozaic Works Bogdan Iordache bogdan.iordache@howtoweb.co este Co-Fondator al How to Web, cel mai important eveniment web din Europa de Est Silviu Dumitrescu silviu.dumitrescu@msg-systems. com Consultant Java @ .msg systems Romania
csmortani.hunor@evoline.ro
Mihai Maruseac
mihai.maruseac@gmail.com IxNovation @ IXIA membru ROSEdu, ARIA
Radu Vunvulea
Radu.Vunvulea@iquestgroup.com Senior Software Engineer @iQuest
Marius Mornea
marius.mornea@todaysoftmag.com Fost senior software developer in cadrul Nokia, n prezent fondatorul platformei Mintaka Research
Adrian Bolboaca
adrian.bolboaca@mozaicworks.com Programmer. Organizational and Technical Trainer and Coach @Mozaic Works
Dan Ionescu Attila Antal

Attila.Antal@isdc.eu
dan.ionescu@danis.ro Director Executiv @ Danis Consulting
Today Software Solutions SRL

str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag ISSN 2284 6352
Software Architect @ ISDC
Mihai Ttran
Microsoft MVP CodeCamp
mihai@itcamp.ro
Cristina Nicule
cristina.nicule@danis.ro Consultant @ Danis Consulting
Co-fondator ITCamp
Andreea Prvu Levente Veres

Design Lead @ endava Levente.Veres@endava.com
andreea.parvu@endava.com Recruiter n cadrul Endava
Vlad Zeciu
vzeciu@smallfootprint.com Senior QA Engineer @ Small Footprint
Alex Pana
alex.pana@vertexarmy.org internship student @ Tora trading
Copyright Today Software Magazine

Lucian Revnic

lucian.revnic@hp.com OO Content Arhitect @ HP Software Cluj
simona.bonghez@confucius.ro Speaker, trainer i consultant n managementul proiectelor, Owner al Confucius Consulting
Reproducerea parial sau total a articolelor din revista Today Software Magazine fr acordul redaciei este strict interzis. www.todaysoftmag.ro www.todaysoftmag.com
Bogdan Matei
bogdan.matei@3pillarglobal.com Senior Php Developer @ 3Pillar Global
Antonia Onaca
anto@aha-ha.com de aproape 10 ani trainer, psiholog, consultant sub form de antreprenor, intraprenor i antreprenor din nou
www.todaysoftmag.ro | nr. 11/Mai, 2013
startups
S uitm de modelul Silicon Valley

(aka Fat Frumos din Vale i Merele de Siliciu)
cum aproape 60 de ani, William Shockley prsea Bell Laboratories i deschidea, n 1956, compania Shockley Semiconductor Laboratory n Mountain View, cu convingerea c siliciul, i nu germaniul, este materialul potrivit pentru producerea tranzistoarelor. n 1957, 8 dintre inginerii lui prseau compania i fondau Fairchild Semiconductor, dintre care doi (Robert Noyce i Gordon Moore) aveau s fondeze ulterior Intel. Dup aproape 60 de ani, Silicon Valley numr cteva sute de mii de ingineri (dintr-un total de 7 milioane locuitori n Bay Area), sute de firme de investiii i acceleratoare care atrag peste 10 mld USD n investiii anuale (peste 40% din totalul anual al tuturor investiiilor de venture capital din SUA), un sistem educational excepional ce include Stanford, una dintre cele mai importante 6 universiti ale lumii, i aproape toi giganii industriei tech: Intel, Google, Facebook, Apple, Amazon, Qualcomm, Yahoo! etc. Acum aproape o lun, cnd am ajuns n San Francisco, se desfura Launch Festival 2013 , una dintre ele mai mari conferine dedicate startupurilor din SF i am fcut un scurt clip.1 Romnia are un pic de recuperat. Cu un total de aprox. 80000 ingineri, cu investiii anuale locale ce nu depesc 10 mil USD (poate chiar mult mai puin) n 2012, cu un sistem educaional organizat anacronic i ineficient care nc i face treaba datorit unui numr redus de oameni pasionai, cu cteva 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 dect s concludem c nu stm ru ca industrie, dar suntem cu cteva ordine de mrime n urm. Periodic citesc articole i tiri despre cum Bucuretiul, i mai nou Clujul, ba chiar i Mgurele, va deveni un Silicon Valley de
1 http://www.youtube.com/watch?v=NB1O0bqPa3Q& feature=player_embedded
Romnia. Pi mi dragilor, dac ar fi aa simplu, a face un Silicon Valley i la mine la Turnu Severin. E vreme bun, investitorii pot merge n pauza de mas la trandul din Herculane, antreprenorii se pot relaxa pe terasele de la marginea Dunrii dup o zi de lucru iar pentru programatori avem pete, ieftin i bogat n fosfor. Bnuiesc ns c nimeni nu vorbete serios, ci sunt doar figuri de stil (parabole, hiperbole etc.), o comparaie propriu-zis fiind exclus. ansele apariiei unui nou Silicon Valley oriunde n lume, inclusiv n SUA, sunt extrem de mici, i cred c ar trebui s nvm ce avem de nvat i apoi s uitm de modelul Silicon Valley atunci cnd ne gndim la crearea unui ecosistem tech local. Poate ar trebui s uitm i de modelul New York, unde startupurile tech s-au dezvoltat i datorit industriei locale de advertising. Poate ar trebui s uitm i de modelul Israel, al doilea stat din lume dpdv al numrului de IPO-uri ale companiilor de tehnologie pe burs din SUA, pentru c industria de tehnologie de acolo a fost creat n primul rnd prin finanarea cercetrii n industria de aprare de ctre stat. i poate ar trebui s uitm i de modelul Londra, cel mai important centru financiar european, unde industria tehnologiei s-a dezvoltat datorit accesului la mecanismele de finanare existente. i a putea continua cu Boulder, Berlin, Singapore i attea alte centre unde tocmai factorii locali, i nu modelele externe, au fcut ca industria s se dezvolte.
Poate ar trebui s ne uitm cu atenie n oglind, s ne ntrebm cine suntem i ce putem face cu adevrat perfomant la scara global a inovaiei, i s executm linitii vreo 20 de ani, cu mai puine poveti despre Ft Frumos din Vale i Merele de Siliciu i cu ochii larg deschii spre noi. PS: toate gndurile mele bune se ndreapt spre Comic Con Bucuresti, unde mi-a fi dorit teribil de mult s fiu.
Bogdan Iordache bogdan.iordache@howtoweb.co este Co-Fondator al How to Web, cel mai important eveniment web din Europa de Est
eveniment
ITCamp 2013
TCamp este cea mai mare conferin premium pe tehnologii Microsoft organizat n Romnia, care se adreseaz profesionitilor implicai n implementri ale tehnologiilor Microsoft i managerilor cu rol decizional, care doresc s fie la curent cu ultimele tehnologii, s-i mbogeasc cunotinele tehnice i care urmresc participarea la training-uri cu adevrat eficiente, bazate pe tehnologiile disponibile astzi. ITCamp este o conferin non-profit, organizat de membri ai comunitilor profesionale CodeCamp i ITSpark, avnd ca i obiective ridicarea nivelului expertizei IT i a cunotinelor profesionitilor IT din Romnia, precum i mbuntirea imaginii Romniei n afara granielor noastre. Prima ediie a conferinei ITCamp a avut 21 de sesiuni tehnice i s-a desfurat pe dou track-uri paralele (Dev i ITPro), nregistrnd puin peste 200 de participani. Coninutul a fost prezentat de speakeri de renume locali i internaionali, printre care Paula Januszkiewicz i Stephen Forte. ITCamp 2012 a fcut trecerea la formatul curent de 3 track-uri (Private & Public Cloud, Development & Mobile i Arhitecture & Best Practices). Cei aproximativ 300 de participani au asistat la prezentrile unor speakeri de renume, cum ar fi Tim Huckaby, Lino Tadros i Martin Kulov. n anii precedeni, majoritatea audienei a fost format din mid-level i senior developers, precum i team leads i arhiteci. Ediia din 2013 va continua tradiia, anunndu-se dou zile n care dezvoltatorii, profesionitii IT i arhiecii vor beneficia de 30 de sesiuni tehnice i un open-panel, prezentate de 26 de speakeri locali i internaionali. ntre acetia, patru experi cu titul de Microsoft Regional Director (Richard Campbell, RD si MVP, creatorul unei varieti de programe multimedia, dintre care amintim .NET Rocks!, RunAs Radio i The Tablet Show; Tim Huckaby, RD i MVP, numit de ctre presa de specialitate un pionier al revoluiei Smart Client; Martin Kulov, RD i MVP; Ciprian Jichici, RD i MVP), Peter Leeson, CMMI Specialist i 13 ali experi cu titlul Microsoft Most Valuable Professional (MVP), o parte din ei fiind speakeri internaionali (Raffaele Rialdi, Developer Security MVP; Andy Cross, Windows Azure MVP; Tobiasz Koprowski, SQL Server MVP etc.). n zilele premergtoare conferinei 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 participanilor ansa de a pune n practic cele nvate, beneficiind de asistena trainerilor. Taxa de participare la aceste workshop-uri nu este inclus n preul conferinei. Imagini, nregistrri video i mai multe detalii despre ITCamp: http://itcamp.ro/about.cshtml http://itcamp.ro/past.cshtml (ediii anterioare) https://www.facebook.com/ITCamp. ro/photos_albums?ref=hl h t t p s : / / v i m e o. c o m / c h a n n e l s / itcamp2012 (cteva sesiuni din 2012) h t t p s : / / v i m e o. c o m / c h a n n e l s / itcamp2011 (cteva sesiuni din 2011)
Mihai Ttran
Microsoft MVP CodeCamp
mihai@itcamp.ro
Co-fondator ITCamp
startups
un prieten pentru startup-uri

-am cunoscut pe Marius la Cluj-Napoca Business Days n iulie 2012, unde am avut un stand de prezentare a produsului nostru MIRA (www.mirarehab.com). Dup ce i-am explicat ce face MIRA, Marius a nceput s cheme lumea la standul nostru i s discute cu noi aspecte business despre produs, spre deosebire de ntrebrile medicale sau tehnice care eram obinuii s rspundem. Am observat imediat interesul lui fa de ceea ce dezvoltam, ncrederea lui n potenialul 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 legtura cu noi i ne-a invitat s participm la evenimentele organizate de el sptmnal, OpenCoffee Cluj. Prin el, am fcut cunotin cu o mulime de oameni din zona start-up-urilor, persoane care nu doar c au acceptat s ne mprteasc experienele lor, dar ne-au oferit i sfaturi pentru a mica business-ul nostru nainte. La mai puin de o lun de la prima ntlnire, Marius ne-a trimis un e-mail prin care ne ncuraja s aplicm 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 opiune pentru noi s transformm produsul nostru ntru n bu s i n e ss funcional. Am ascultat sugestia lui i dup o lun, am primit oferta s participm in primul accelerator European orientat pe medicin. Ne-am fcut bagajele, am plecat spre Londra i am format compania cunoscut acum sub numele de MIRA Rehab. n Decembrie 2012, Marius ne-a recomandat s aplicm la Kairos 50. Am as c ult at din nou de e l i n e - am calificat la Kairos Global S u m m i t . Kairos Global Summit a fost un eveniment n New York n Februarie 2013, unde cele mai inovative 50 de business-uri conduse de studeni 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 cunoate, tiam direcia n care ne ndreptam, dar el ne-a ajutat s facem primii pai care au dus la business-ul nostru curent. Reeaua lui de cunotine, ambiia de a vedea creterea altor companii mici i implicarea lui cu sfaturi pot ajuta orice start-up, pe oricine care are o idee bun, s fac primii pai spre un potenial succes.
LUXEMBOURG
JUNE
Biz Stone
Co-founder, Twitter
Founder of Electronic Arts, CEO, Digital Chocolate
Ruppert Keeley
CEO EMEA, Paypal
Trip HAWKINS Laura Yecies

CEO, SugarSync
Koichiro Tsujino
Founder Alex Corporation and developed VAIO, Sony, former President of Google Japon
BRIAN STEVENS
CTO, Redhat Global Director fot the Digital Marketing & Communication, Pirelli
Peter Sondergaard
Senior Vice President, Research Gartner
Pepe MODER
www.ictspring.com
MORE SPEAKERS ON
ReGISTER NOW
www.ictspring.com
eveniment
JAVA EE7. Cloud, Web 2.0+

(Features, Deltas, Changes)
e-a lungul timpului, n lumea dezvoltatorilor de software, s-au evideniat cteva cerine fundamentale precum nevoia de distribuie, tranzacionalitate sau portabilitate a aplicaiilor. Limbajul Java a susinut n permanen aceste tendine, iar platforma enterprise, este poate modelul cel mai bun de reflectare a lor. Din pcate, implementarea tendinelor a creat numeroase probleme printre care viteza, securitatea sau ncrederea. Partea central a versiunii 7 a platformei Java Enterprise este legat de creterea simplificrii, productivitii i asigurarea de suport pentru HTML 5. O alt preocupare rezolvat prin aceast platform este descrcarea dezvoltatorilor de grija task-urilor legate de infrastructur, prin folosirea containerelor i abstractizarea accesului la resurse. n versiunea 7 platforma simplific considerabil API-ul de acces la serviciile container-ului, lrgind domeniul de servicii disponibile. De asemenea, se are n vedere extinderea platformei pentru a cuprinde tehnologiile n dezvoltare din spaiul web. Workshop-ul despre Java EE 7 este organizat pe trei seciuni: Prima va oglindi principalele mbuntiri aduse de Java EE 7. Aceasta nseamn aducerea n discuie a problemelor de design sau de implementare existente n versiunile anterioare i modul n care ele au fost rezolvate. Mai mult, majoritatea componentelor enterprise au suferit modificri datorit evoluiilor platformei standard precum i celor din lumea web. Modelul cloud, care se intenioneaz a fi inclus n aceast versiune, modific semnificativ. API-ul componentelor EJB sau Servlet, doar ca exemple. Cea de-a doua va evidenia tendinele programrii enterprise. Amintitul model cloud, dar i API-uri noi pentru WebSocket, JSON, utilitare de concuren, Java Caching i batch applications sunt tot attea provocri. Partea a treia va prezenta o aplicaie care va rula n nori. Acoperit exclusiv prin tehnologii Oracle aplicaia va prezenta facilitile i modificrile pe care modelul cloud le aduce. O aplicaie ce ruleaz n nori va avea alte roluri de dezvoltare i ntreinere dect o aplicaie enterprise obinuit. n orice moment interveniile din partea auditoriului pentru clarificri i discuii sunt binevenite. Sursele bibliografice au fost numeroase, din pcate unele dintre ele contradictorii. Spre exemplu, n acest moment nu este clar cnd va fi lansat Java EE 7. Termenul estimat iniial de aprilie 2013 este aproape sigur depit. De asemenea, este interesant de urmrit care dintre specificaiile iniiale ale versiunii 7 vor rmne n aceast versiune i care vor fi postponed n versiunea 8. Sursele de documentare includ prezentri la evenimente precum JavaOne, articole publicate de presa Oracle, forumuri i altele. Aplicaia a fost dezvoltat folosind Oracle Cloud i, local, WebLogic. Sunt invitai s participe toi cei care au preocupri n acest domeniu sau sunt interesai de tendinele de dezvoltare din lumea enterprise, Java sau alternativ. Specialitii vor gsi cu siguran elemente care s-i provoace la discuii sau reflecii. V ateptm cu toat plcerea! Silviu Dumitrescu
Silviu Dumitrescu silviu.dumitrescu@msg-systems. com Consultant Java @ .msg systems Romania
10
istorie
Istoria IT-ului Clujean (VI)

m s ncep cu ncheierea fcut La primul capitol, contextul geografic, polide Iacob Negruzzi crii sale: tic i economic, par s fie de partea noastr. Amintiri din Junimea. Suntem un ora de provincie, suficient de departe de capital, cu o generaie tnr Cnd privesc napoi, la viaa trecut a de iubitori de IT, avnd o situaie financiar Junimii, m conving pe deplin c o aseme- peste medie (o statistic la nivel naional nea societate nu s-a putut forma dect prin plaseaz IT-ul n top 3 cele mai bine pltite concursul unor mprejurri cu totul deose- domenii, Clujul ocupnd poziia secund, bite. A trebuit s se ntlneasc ntr-un ora dup Bucureti). ndrznesc s sintetizez de provincie, departe de zgomotul centrului aceste asemnri contextuale sub sintagma politic, un numr de brbai tineri, la care de infrastructur social. plcerea literaturei i ndeobte a ocupaiilor La capitolul diferene separm simintelectuale s fie deopotriv vie. Acetia au pla asemnare de infrastructur de acele trebuit s fie ntr-o situaie material inde- mprejurri identice eseniale pomenite de pendent, aa ca s aib de unde ajuta pe Negruzzi. Pentru a elimina diferenele este ali tineri lipsii de mijloace, ce le preau a necesar nsuirea urmtoarelor nvturi. avea talent i srguin. A trebuit ca memn primul rnd recunoaterea meritelor brii Junimii s-i recunoasc deplin meritele celorlai, fr invidie. Junimea se folosea unii altora i ca nici un sentiment de invidie, de ntlniri foarte dese ntre membrii ei ct de ascuns, s nu turbure senintatea con- i de prezena Convorbirilor Literare, o stant a relaiilor lor. Condus de asemenea unealt foarte bun pentru a aduna talente, brbai i n asemenea mprejurri, negreit a crete voci i a polemiza cu celelalte c Societatea a putut ine atta timp, chiar centre universitare i culturale ale rii. lipsindu-i desvrit orice organizare exteri- Aceast combinaie ntre comunicare crioar. Dar mprejurri identice nu se vor mai tic intens n particular i o voce unitar repeta uor n viaa unui popor i de aceea o pentru publicul larg, ajut la uniformia doua ediie a unei asemenea societi va fi zarea i coagularea societii, permind poate cu neputin n timpuri viitoare. lefuirea orgoliilor nainte de expuneAvut-a Junimea merite nsemnate? Acel rea public. Exist i la Cluj un efort de care, ca mine, a fost nsui actor cu greu cunoatere a valorilor individuale printr-o poate judeca valoarea piesei n care a jucat comunicare activ i deschis ntre memun rol de cpetenie. Viitorul singur se va brii diferitelor comuniti. Revista TSM are rosti cu neprtinire cnd noi nu vom mai ca misiune principal ntocmai facilitarea fi. Totui, credina mea este c Junimea va acestei comunicri i creterea vizibilitii pstra o pagin n istoria literaturei romne, ntre profesionitii din mediul IT local, cci prea am avut noi nine plcere la lucr- alturi de tot mai multe astfel de iniiative, rile noastre, pentru a nu fi adus mulumire de la grupri tehnologice, la organizaii de i folos i publicului celui mare. Vor veni tip breasl (vezi Cluj IT cluster). Important mai trziu alte societi mai nvate, poate este s nvam a echilibra suficient orgoliu, mai active i mai neobosite, ns nu va mai ct s ne contientizm propria valoare, dar fi nici una care s fi fcut lucrri serioase nu prea mult, ct s cdem n mndrie i ntr-o form att de vesel, de plcut i de invidie. Dei programatorii sunt o specie neobinuit. destul de orgolioas, exist destule semne de reuit n evitarea fragmentrii, izolPe lng valoarea intrinsec a citatului rii i diluarea valorii introdus de primele de mai sus, putem extrage cteva nvturi dou. relevante extrapolnd la contextul actual al La urmtoarele dou nvturi, suntem IT-ului clujean. O simpl recitire, n care nc n stadii incipiente: finanarea talentenlocuim literatura cu IT-ul, evoc o lor aflate la nceput de drum i atmosfera imagine apropiat de realitatea actual. vesel i plin de satisfacie. Cnd ne refeRealitate plin att de asemnri, ct i rim la finanare, merit extins nelesul diferene fa de contextul istoric al Junimii. junimist de ajutor financiar personal,
nvturi din Junimea

deoarece n practic acest rol de investitor l pot juca att indivizii, ct i companiile. Similar putem extinde nelesul de tnr talentat, att asupra profesionitilor angajai n diferite companii, ct i asupra antreprenorilor din scena startupurilor. Indiferent de combinaiile posibile ale nelesurilor de mai sus, prioritar este necesitatea susinerii financiare i accelerarea proceselor de investiii pentru a contracara exodul talentelor ctre alte surse de finanare internaionale. Similar modelului junimist, investim n colarizarea talentelor (intern n companii, iar din perspectiva antreprenorial prin programe publice locale), dar ar merita extrapolat att la nvmntul public (toate nivelele), ct i la programe de investiii n startupuri. Ne punem sperana n noul cluster, n deschiderea tot mai evident a companiilor locale spre colaborare i implicare social, i n cele cteva incubatoare/acceleratoare emergente. La final aleg s vorbesc despre atmosfer i atitudine. Ambele eseniale, att n opinia lui Negruzzii, ct i a mea personal. Exist tensiuni n mediul actual, generate att de predilecia unora spre outsourcing i toate implicaiile acesteia, de competiia tot mai strns pe resurse, ct i de unele discrepane ntre discursul diplomat oficial prietenos i lipsa unor proiecte reale de colaborare ntre juctorii principali din pia. Chiar i la nivelul startup-urilor, unde deschiderea spre comunicare i suport mutual este mai mare, exist o competiie oscilant ntre sntoas i uneori doar orgolioas. Reeta Junimii condiioneaz satisfacia final de plcerea i veselia cu care se desfoar activitile sale. Consider prioritar aceast rearanjare a valorilor noastre i chiar dac un mediu de profesioniti IT veseli este uor utopic, cel puin plcerea i mplinirea profesional ar trebui s ocupe primul loc.
Marius Mornea
marius.mornea@todaysoftmag.com Fost senior software developer in cadrul Nokia, n prezent fondatorul platformei Mintaka Research
11
comuniti
Comuniti IT Cluj-Napoca
n acest numr vreau s v recomand dou evenimente din perioada urmtoare: Romanian Testing Community Conference 2013 2nd Edition i IT CAMP 2013. Ambele sunt evenimente anuale i au n comun ambiia de a fi cel mai mare eveniment de profil din Romnia. Din ce am vzut pn acum, reuesc i v recomand cu cldur s participai la dou evenimente pline de prezentatori de calibru internaional.
Calendar
Mai 7 AgileWorks Remote Open Space www.meetup.com/The-Cluj-Napoca-Agile-SoftwareMeetup-Group Mai 8 Monthly Meetup #13 www.meetup.com/Tabara-de-Testare-Cluj Mai 9 Lansarea numrului 11 TSM www.todaysoftmag.ro Mai 14 Software architecture and the balance with agility www.arobs.com/architecture-workshop Mai 16-17 Romanian Testing Community Conference 2013 www.romaniatesting.ro Mai 17 JAVA EE7. Cloud, Web 2.0+ msg.info-office-cluj@msg-systems.com Mai 17-19 Startup Live Cluj-Napoca startuplive.in/cluj-napoca/2 Mai 18-19 Asynchronous Master Class codecamp-cluj-mai2013.eventbrite.com Mai 23-24 ITCAMP 2013 itcamp.ro Mai 25 Fun Meetup v2.0 w w w . l i n k e d i n . c o m / g r o u p s / Functional-Programming-in-Romania-4338166 Mai 30-31 I T.A.K.E Unconference Bucureti http://itakeunconf.com/
Transylvania Java User Group Comunitate dedicat tehnologiilor Java. Website: http://www.transylvania-jug.org/ Data nfiinrii: 15.05.2008 / Nr. Membri: 535 / Nr. Evenimente: 41 Comunitatea TSM Comunitate construit n jurul revistei Today Software Magazine. Website: https://www.facebook.com/todaysoftmag Data nfiinrii: 06.02.2012 / Nr. Membri: 585 / Nr. Evenimente: 9 Romanian Testing Community Comunitate dedicat QA. Website: http://www.romaniatesting.ro Data nfiinrii: 10.05.2011 / Nr. Membri: 593 / Nr. Evenimente: 1 GeekMeet Cluj Comunitate dedicat tehnologiilor web. Website: http://geekmeet.ro/ Data nfiinrii: 10.06.2006 / Nr. Membri: 537 / Nr. Evenimente: 16 Cluj.rb Comunitate dedicat tehnologiilor Ruby. Website: http://www.meetup.com/cluj-rb/ Data nfiinrii: 25.08.2010 / Nr. Membri: 132 / Nr. Evenimente: 34 The Cluj Napoca Agile Software Meetup Group Comunitate dedicat metodelor Agile de dezvoltare software. Website: http://www.agileworks.ro Data nfiinrii: 04.10.2010 / Nr. Membri: 303 / Nr. Evenimente: 26 Cluj Semantic WEB Meetup Comunitate dedicat tehnologiilor semantice. Website: http://www.meetup.com/Cluj-Semantic-WEB/ Data nfiinrii: 08.05.2010 / Nr. Membri: 139/ Nr. Evenimente: 22 Romanian Association for Better Software Comunitate dedicat oamenilor cu experien din IT indiferent de tehnologie sau specializare. Website: http://www.rabs.ro Data nfiinrii: 10.02.2011 / Nr. Membri: 219/ Nr. Evenimente: 12
12
programare
Software Craftsmanship
icarea Software Craftsmanship a prins contur n 2009, ca reacie la ideea c putem reduce temporar calitatea codului pentru a scoate produse mai repede. Promotorii micrii consider c dimpotriva, ceea ce trebuie sa mbuntim este viteza cu care un programator scrie cod de calitate. Altfel, utilizatorii, clienii i compania care produce software au de suferit: primii din cauza greelilor introduse n aplicaii (bug-uri), iar compania datorit scderii vitezei de producie a noilor versiuni i a nemulumirii utilizatorilor.
Alexandru Bolboaca
alex.bolboaca@mozaicworks.com Agile Coach and Trainer, with a focus on technical practices @Mozaic Works
Pentru a sprijini nevoia aspiranilor la software craftsmanship de a ajunge la acest nivel, promotorii micrii au recurs la o metafor bazat pe istoria breslelor i a meterilor.
Metafora
Adrian Bolboaca
adrian.bolboaca@mozaicworks.com Programmer. Organizational and Technical Trainer and Coach @Mozaic Works
n epoca medieval bunurile erau produse manual. Fiecare profesie era structurat n bresle, unde meteugarii puteau s se ntlneasc, s nvee unii de la ceilali i s-i apere profesia. Pentru c unele bresle din anumite ceti controlau foarte bine calitatea produselor, acestea dobndeau faim. Acesta este motivul pentru care breasla era o instuie nchis; orice meter ce intra n breasl trebuia s produc la o anumit calitate. ntre breslele dintre diverse orae era o competiie acerb, de aceea calitatea produselor cretea constant. Fiecare breasl avea un statut care reglementa funcionarea intern a sa. De asemenea organizarea breslelor era reglementat prin legi. Pentru a deveni meter, un tnr trebuia s treac cteva etape: s devin ucenic, apoi s devin calf, s cltoreasc ntre ceti pentru a nva de la ali meteri si doar apoi putea s devin i el meter. Ascensiunea n cadrul breslelor nu era deloc simpl i necesita ani lungi de pregtire. Un tnr intra n ucenicie nc de la 10-12 ani. nainte de a intra n ucenicie
tnrului i se testau 2-3 sptmni aptitudinile. Ucenicia dura n jur de patru ani, timp n care ucenicul era un fel de slug n casa stpnului avnd sarcini de la rsritul pn la apusul soarelui. Dup terminarea uceniciei, ucenicului i se elibera un certificat de nvare a meteugului, care i permitea s fie angajat drept calf. Dup acest moment calfa avea trei opiuni: s rmn n atelierul meterului, s se angajeze la alt meter sau s-i fac timpul de cltorie1. Cltoria avea scopul de a-l ajuta pe calf s-i nsueasc mai bine meseria. Timpul obligatoriu de cltorie era de 2-4 ani. Dup cltorie, calfa trecea un examen de meter: o proba practic, o lucrare de miestrie sau capodoper. Breasla analiza lucrarea pe care o aproba sau o respingea printr-o comisie. Doar dup un proces de acceptare n breasla tnrul meter avea voie s-i deschid un atelier. Un meter era un cetean al oraului n care locuia i putea s participe la deciziile politice ale oraului. n cadrul unei bresle, exista o conducere aleas. Meterul cu cea mai mare experiena i cu reputatie imaculat era de obicei conductorul breslei. Aceast conducere avea grij ca breasla s prospere, stabileau standardele de calitate ale produselor i realizau toate actele administrative.
1 http://arheologie.ulbsibiu.ro/publicatii/bibliotheca/ bresle/4%20capitolul%20II.htm
13
programare
Software Craftsmanship Principiile
Dup cum menionam mai sus, Software Craftsmanship este o abordare in industria de Software Development care accentueaz importana abilitilor dezvoltatorilor. Iniiatorii micrii doresc s ridice standardele profesiilor din industria IT prin aplicarea acestor concepte din epoca medieval. Micarea a luat fiin n anul 2009 prin realizarea unui manifest auto-denumeasc Aspiring Software Craftsman, echivalentul ucenicului din istoria breslelor de meteugari. Scopul lor este ca programatorilor s le pese de calitatea produselor, calitate codului i s doreasc s nvee continuu. Dupa cum un ucenic lucra de la rsrit pn la apus, la fel i un aspiring software craftsman ar trebui s exerseze ct mai mult pentru a-i mbuntai abilitile. Astfel au devenit i industrie avem foarte puine dovezi despre ce anume ajut i ce nu la dezvoltarea aplicaiilor complexe. Aceasta a fost o problem pentru Software Craftsmanship, pentru nu poi dezvolta abilitile programatorilor atunci cnd nu tii care ar trebui s fie. Iniiatorii micrii au fcut dou lucruri: au selectat cteva practici din experiena unor programatori cu zeci de ani de experien i au insistat ca fiecare programator sa nvee n continuu n cadrul comunitii, n sperana c vor reui s descopere ce definete profesia. Cteva din aceste practici recomandate pentru orice aspirant software craftsman sunt: testarea automat sub forma unit testing sau test driven development, refactoring continuu, meninerea cureniei codului prin urmarea unor reguli de clean code, elemente de design i arhitectur, paradigme diferite de programare object oriented i funcional i pair programming. Aceast list este doar o baz pe care membrii comunitilor construiesc. La nivel personal, recomandarea micrii este ca fiecare programator s ncerce s stpneasc aceste practici, s le discute n comunitate i sa le aleag pe cele care l ajut cel mai mult n cadrul unui proiect. Micarea este uneori criticat pentru aceast list de practici. Multe din critici vin ca reacie la afirmaiile lui Robert C. Martin, probabil cel mai vocal promotor al software craftsmanship, care susine cu ndrjire practicile de mai sus. Scopul lui este acela de a defini un standard al profesiei, dar metodele folosite nstrineaz unii programatori interesai de micare. n realitate, majoritatea celor care aspir la craftsmanship sunt persoane pragmatice care prefer s stpneasc toate uneltele meseriei, pentru a le putea selecta pe cele utile la un moment dat.
Manifestul Software Craftsmanship
Acest manifest este o continuare al Manifesto for Agile Software Development, care presupunea existena software-ului funcional, s putem rspunde rapid la schimbri, valorizarea interaciunilor ntre persoanele implicate n dezvoltarea unui software i colab orarea intensiv cu clientul. Software Craftsmanship vrea s completeze Manifesto for Agile Software Development prin faptul c nu se dorete doar software funcional, ci un software creat cu grij i pricepere. Pe lng a rspunde schimbrii rapid i eficient, adugm valoare prin funcionaliti importante pentru utilizatori. E important ca nu doar s valorizm interaciunea dintre oameni, ci dorim s crem o comunitate de profesioniti.
mai cunoscute practicile urmtoare: coding kata, coding dojo, pair-programming, dar a fost inventat i un alt concept: code retreat. Vom reveni la ele n detaliu. Corey Haines este printre primii programatori care a preluat modelul clatoriei ucenicilor i s-a autodenumit software journeyman. Ceva mai mult de un an Corey a cltorit n lume cu singurul scop de a nva lucruri noi de la ali programatori. n timpul cltoriei dorea doar sa aiba unde s doarm i s aib ce s mnnce, n schimb dezvolta orice aplicatie era nevoie. Dup ce i-a ncheiat cltoria, Corey a revenit la maestrul su, Robert C. Martin, i i-a povestit ce a nvat, la fel ca n timpul breslelor.
Moduri de a nva
Spre deosebire de alte profesii, un programator nu are un set de practici ncepnd cu anul 2009 cnd a standardizate pe care trebuie neaprat s fost publicat acest manifest, tot mai le nvee. Exist desigur practici pe care o muli programatori au nceput s se echip sau alta le folosesc, dar la nivel de
Practici de programare
Istorie
O dat ce o list de practici de programare care trebuie stpnite sunt definite, programatorii au nevoie de metode de a le nva. Aa cum arat experiena lui Corey Haines (i nu numai), una din cele mai bune metode de a nva programare este prin interaciunea cu comunitatea. n acelai timp ns, este important ca un programator s i dezvolte i singur abilitile. Software craftsmanship propune cteva metode de a nva aceste practici. Coding kata este o metod mprumutat din arte mariale i se refer la exersarea unei practici de programare prin
14

rezolvarea repetat a unei probleme simple folosind acea practic. Exist pe web destule probleme documentate n acest scop, la fel cum exist nregistrri video ale unor programatori din comunitate care o demonstreaz. Cel mai important lucru este ca dup fiecare rezolvare, programatorul s se gndeasc ce l-a ncetinit n timpul exerciiului i ce ar trebui s schimbe pentru a elimina aceast frn. Coding dojo este o alt metod mprumutat din artele mariale. Se refer la un exerciiu de grup cu scopul de a transmite cunotine ntre participani. Grupul va ncerca s rezolve o problem, exersnd anumite practici. n forma lui cea mai rspndit, 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 urmtorul programator din sal. Astfel, prin rotaie, toat lumea va scrie cod i va vedea cum scriu cod ceilali. Code retreat este un alt format, de aceast dat preluat de la comuniti de scriitori. Ideea unui code retreat este de a combina mai multe din elementele dintrun coding dojo sau coding kata ntr-o singur zi de exersare. Code retreat-urile au loc de obicei smbta i dureaz toat ziua. Evenimentul este structurat n 6 sesiuni de 45 de minute, separate n retrospective scurte. Regulile sunt simple: n cadrul fiecrei sesiuni, programatorii lucreaz n pereche cu scopul de a scrie cod cu anumite constrngeri impuse de facilitator i care faciliteaz nvarea. Dup fiecare sesiune, codul scris este ters complet, perechile i constrngerile se schimb i scrisul de cod rencepe. Primele code retreat-uri au avut loc n SUA n 2009, urmate foarte curnd de Romnia, unde au fost facilitate de Maria Diaconu i Alexandru Bolboac n cadrul comunitii AgileWorks. Corey Haines a avut un rol foarte important n rspndirea evenimentului n ntreaga lume, totul culminnd cu Global Day of Code Retreat cnd 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 curnd Markus Grtner a realizat primul test automation retreat. La fel, aceste practici au fost adaptate i pentru arhitectur, aprnd architecture kata i architecture retreat. Noi tipuri de exerciii au aprut n timp. Adrian Bolboac a inventat sesiunea numit Taking baby steps cu scopul de a nva refactoring i a avut succes la conferine internaionale, n cadrul comunitilor i la code retreat-uri. Adrian Bolboac i Alexandru Bolboac au inventat sesiunea Brutal refactoring, care a fost preluat n ntreaga lume. Keith Braithwaite a inventat sesiunea numit TDD As If You Meant It, acum preluat n aproape fiecare code retreat. n afara acestor evenimente de comunitate, exist i posibilitatea de a nva prin pair programming. Orice programator ar trebui s poat invita pe un altul la o sesiune privat de exersare. Civa programatori fac acest lucru i la distan; Alexandru Bolboac a deschis de civa ani un Remote Pair-programming Tour n acest scop. iar Romnia se altur anul acesta prin conferina I. T.A.K.E. Pe 30-31 mai, evenimentul va aduna programatori din ntreaga Europ i invitai din SUA cu scopul de a discuta, exersa i nva mpreun aceste practici de programare. Nu doar c toi vorbitorii vor scrie cod, dar i participanii vor programa n cadrul workshop-urilor, concursului kata lounge, dezvoltrii 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 comunittile europene de software craftsmanship vor participa la conferin ca vorbitori i cu workshop-uri. Acest eveniment deschide tuturor programatorilor din Romnia porile ctre nivelul cel mai nalt de cunotine despre dezvoltarea de software din Europa.
Concluzie
Conferine
n concluzie, Software Craftsmanship este o micare de amploare internaional, care are la baz ideea c profesia de programator nseamn putina de a livra cod de calitate sub presiune. Pentru a ajunge acolo, programatorii trebuie sa stpneasc o list de practici. Pentru a le stpni, ei pot exersa singuri i n cadrul comunitilor folosind anumite formate specifice de ntlniri. Code retreat-ul este formatul care s-a rspndit cel mai rapid n ultimii ani, culminnd cu Global Day of Code Retreat. n Romnia, micarea este promovat de comunitatea agile AgileWorks, de conferina I T.A.K.E., precum i de programatori pasionai din ar.
Comunitatea de software craftsmanship organizeaz cteva conferine. Cele mai cunoscute sunt n SUA i Londra,
Referine:
http://arheologie.ulbsibiu.ro/publicatii/bibliotheca/bresle/4%20capitolul%20II.htm http://manifesto.softwarecraftsmanship.org http://agilemanifesto.org http://en.wikipedia.org/wiki/Kata_%28programming%29 http://codingdojo.org/cgi-bin/wiki.pl?WhatIsCodingDojo http://coderetreat.org/about http://www.testingdojo.org/tiki-index.php http://blog.adrianbolboaca.ro/2013/04/the-history-of-brutal-refactoring-game/ http://blog.adrianbolboaca.ro/2013/01/the-history-of-taking-baby-steps/ http://www.alexbolboaca.ro/wordpress/articles/how-to-organize-a-code-retreat http://www.alexbolboaca.ro/wordpress/the-remote-pair-programming-tour http://agileworks.ro http://itakeunconf.com
15
arhitectur
Din buctria arhitectului software

carduri de scenarii
etodologia care urmeaz a fi prezentat n acest articol a fost dezvoltat de cei de la SEI (Software Engineering Institute, Carnegie Mellon) i face parte din metodologia ATAM (Architecture Tradeoff Analysis Method). Articolul prezint ntr-o form simplificat aceast metodologie accentnd latura practic.
Cardul de Scenarii
Attila Antal
Attila.Antal@isdc.eu Software Architect @ ISDC
Cardurile de scenarii sunt folosite pentru argumentarea decizilor din diferite puncte de vedere. Cardurile sunt create de arhitectul din proiectul respectiv i sunt distribuite pentru evaluare de ctre membrii decizionali ai echipei, inclusiv de ctre client. Un ablon al cardului de scenarii este prezentat n schema de mai jos. Dup cum se observ cardul are patru zone: Zona cu detalii, unde se introduce un cod relevant al scenariului i o scurt descriere a lui. Zona cu detalii legat de mediu de lucru din punct de vedere arhitectural. Zona cu deciziile care urmeaz s fie luate specific scenariului. Zona cu argumentele arhitecturale, motivul i o diagram simpl care reflect obiectul scenariului.
arhitecturii curente. Acestea fiind: Pucte Sensibile marcate cu cod S1, S2, Puncte de Compromis marcate cu cod T1, T2, Riscuri marcate cu cod R1, R2, Non-riscuri marcate cu cod N1, N2,
Un punct sensibil nseamn o proprietate a unei componente care este critic pentru obinerea 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 poteniale. Non-riscurile sunt menionarea deciziilor arhitecturale bune, n cardul de scenarii au caracter informativ.
Aceste coloane pot conine una sau mai Zona cu deciziile are un cmp de multe valori n foma codificat (menionat explicatii i alte patru de impact asupra deja mai sus). Aceste coduri urmeaz s fie
16

explicate n liste dedicate.
DL2: Logic Configurabil DL3: Logic Bazat pe Rule Engine

Scenario #: DL3 Se va folosi un Rule Engine pentru decizii. Attribute(s) Environment Stimulus Response Architectural decisions Folosirea unui Rule Engine Maintenan pentru baza de reguli Reasoning Flexibilitate n timpul rulrii (Runtime) Cerere de luare decizii dinspre Business Logic. Decizii luate de Rule Engine. Sensitivity Tradeoff S2, S3 S4 T2 R3 N2 Risk Nonrisk
Studiu de caz
Pentru a prezenta ct mai real cum funcioneaz procedeul prin care se gsete o soluie 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 influeneaz rezultatele la anumite calcule. Aceasta i va cere arhitectului proiectului (n acest context fiind vorba de noi) s vin cu nite idei de implementare. Arhitectul, adica noi, vom realiza trei scenarii i l vom trece printr-un procedeu de evaluare i la final ncearcm s gsim soluia cea mai potrivit. S vedem scenariile!
DL1: Logic Hardcodat

Scenario #: DL1 Attribute(s) Environment Stimulus Response Architectural decisions Hardcodare Reasoning Se va folosi o logic de decizie intern, hardcodat. Performance n timpul rulrii (Runtime) Cerere de luare decizii dinspre Business Logic. Decizii luate pe baza logicii interne. Sensitivity Tradeoff Risk Nonrisk S1 R1 N1 Folosind modul de decizie hardcoded se reduce complexitatea i n plus se poate obine performana maxima de executie.
Introducerea n arhitectur a unei Rule Engine aduce flexibilitate i configurabilitate.
Architecture Diagram
Lista Punctelor Sensibile

Code S1 S2 S3 S4 Description Logica de decizie e greu de modificat mai trziu i necesit relansarea produsului n producie. Introduce complexitate n proiect. Necesit expertiz i/sau experien. Comunicarea i planificarea n sync cu echipa care ntreine baza de reguli.
Lista Punctelor de Compromis

Scenario #: DL2 Attribute(s) Environment Stimulus Response Architectural decisions Hardcodare Fiier de Proprieti Reasoning Se va folosi o logic de decizie intern semihardcodat bazat pe anumite atribute configurabile prin intermediul unui fiier de proprietai. Configurability n timpul rulrii (Runtime) Cerere de luare decizii dinspre Business Logic. Decizii luate pe baza logicii interne influenate din exterior. Sensitivity Tradeoff Risk R1 T1 R2 Nonrisk N1 Code T1 T2 Description Trebuie decis dac propriettile vor fi recitite imediat dup modificare sau numai dup relansarea aplicaiei (flexibilate vs. garania calculaiilor ptr. toi). Trebuie ales un Rule Engine portivit.
Lista Riscurilor
Code R1 R2 Description Schimbarea logicii necesit development. Fiind fiierul de proprieti un punct sensibil al sistemului trebuie protejat i asignate roluri specifice modificrii.
Dac logica de decizii se bazeaz pe nite parametri care se pot externaliza, atunci se poate introduce configurabilitate.
Lista Non-Riscurilor
Code N1 N2 Description Este uor de realizat i garanteaz lansarea n timp n productie. Gsit o soluie uoar de lansare a regulilor.
Evaluare
Pentru evaluarea scenariilor vom folosi forma tabelar a unui Utility Tree. Enumerm scenariile de pe carduri dar putem aduga si altele (fr card) i rugm prile participante din partea clientului s dea o not de importan (L low, M medium,
17
arhitectur
Din buctria arhitectului software
H - High). Coloana de dificultate va fi marcat de arhitectul proiectului. n cazul nostru tabela va arta astfel (coloana de importan fiind o presupunere):
Quality Attribute Performan Configurabilitate Flexibilitate Scenario DL1: Logic hardcodat DL2: Logic configurabil DL3: Logic bazat pe Rule Engine Importance Difficulty L H H L M H
punctele sensibile, compromisurile i riscurile. Fiecare card trebuie sa fie evaluat de ctre client sau de ctre 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 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 prilor i de vzut dac ntr-adevr au nevoie de aceast solutie. Dificultatea mare n cazul nostru putnd fi tradus prin: mai scump, timp mai mare de implementare i eventuale costuri de licent i ntreinere. Deci putem pronuna c pn se nate o decizie legat de # DL3 soluia ctigtoare va fi cel de # DL2.
Sumar
Concluziile pe care le putem trage dup citirea acestui articol sunt: Arhitectul trebuie s vin tot timpul cu diferite scenarii pentru o singur problem. Cardul de scenarii este un mediu de prezentare a unei idei i n acelai timp este i mediu pentru a aduce decizii. Cardul de scenarii este prima linie unde vor fi menionate
Throughout the year, ISDC engineers dreams of customers. Only in spring time, we engineer Easter sponge cakes!
PATE FERICIT! FIJNE PAASDAGEN! FROHE OSTERN! !
18
arhitectur
Arhitectura extransibil i durabil (grow form novice to guru)
Levente Veres
Design Lead @ endava
Levente.Veres@endava.com
n zilele de azi dezvoltarea de aplicaii nu se rezum la dezvoltarea de module, la mentenana aplicaiilor dezvoltate acum ani de zile sau la o simpl testare de funcionalitate. Softiti romni au ajuns la nivelul la care nu numai clientul sau dezvoltatorul dorete mai mult, ci i piaa dorete ceva mai mult de la dezvoltatori romni. Clientul ateapt ceva mai preios dect o executare coordonat, ateapt ceva n plus care s l surprind chiar i pe el. Desigur, marea majoritate a programatorilor neglijeaz acest detaliu pe care l contientizeaz doar atunci cnd devin ei nii clieni. Marea majoritate a dezvoltatorilor nu va fi n stare s sacrifice timp i energie adiional ca s ofere ceva n plus. Motive se gsesc, multe personale ct i financiare sau alegerea stagnrii n zona de confort. Articolul de mai jos este adresat tuturor care doresc s ofere ceva n plus fa de cerinele standard, totodat s se pregteasc pentru a deveni cei mai buni n domeniul IT. Desigur fiecare are la dispoziie o cale unic i proprie pentru a atinge nivelul de Arhitect, ceea ce necesit experien de ani de zile. Pentru a defini un Arhitect, fie el din categoria system-software, solution sau business, a folosi cteva cuvinte cheie: dreams (vise), reality (realitate), creation (creare), timeless (inexpirabil). Un arhitect trebuie s ia n considerare ca orice soluie, aplicaie creat de el reflect n realitate visul unui/unor oameni
THE PHILOSOPHY
he dialogue between client and architect is about as intimate as any conversation you can have, because when youre talking about building a house, youre talking about dreams. Robert A. M. Stern i va fi ct de ct posibil o creaie de durat. n cazul n care v-ai regsit mai sus vocaia, putem trece la urmtoarele nivele unde vom discuta succint despre unele aspecte din modul n care transformm un vis n creaie real.
THE SECRET
Care este cheia succesului unei arhitecturi care satisface toate cerinele proiectului? ntrebarea este retoric, dar se poate rspunde la ea. Arhitectura ideal este cea care satisface cele patru criterii de mai sus i este consecvent cu deciziile luate pe durata implementri , totodat nu deviaz de la criteriile de baz propuse n primele etape ale arhitecturi. Dei pare uor de fcut fa celor de mai sus, cu att e mai greu s menii n echilibru creaia din diferite motive cum ar fi decizii manageriale, financiare, schimbri de scopuri sau schimbri de echipe.
THE BUCKET LIST
Pentru a ine totul sub control trebuie s fim contieni c fr o list de to-do nu prea vom putea fi consecveni, ceea ce induce ca arhitectura aleas s nu fie sustenabil. Desigur aceast list are sens numai dac periodic relum i verificm dac mai este actual ceea ce am definit iniial, dac deviaia este prea mare e timpul s regndim dac arhitectura aleas va fi sau nu prea bun. O list de necesitai SMART poate fi urmtoarea:
19
arhitectur
Arhitectura extransibila si durabila (grow form novice to guru) A. Colectarea informaiilor
1. Creai o lista de cerinele funcionale. Exemplu: Dorim o aplicaie care face rezervri de bilete de avion. 2. Creai o lista de cerine non-funcionale Not : Dac nu avei aa ceva de la client, atunci ARHITECTUL are responsabilitatea de a face o lista exemplificat mai jos, care i va ajuta i pe dezvoltatori. Exemplu: Soluia noastr n 30 de milisecunde gsete toate biletele disponibile pentru o anumita rut. Fiecare interogare de baz de date nu dureaz mai mult de 10 milisecunde. Putem deservi 1000 de utilizatori pe minut. Folosim fiecare server de aplicaie cu un grad de ocupare maxim 70%. 3. Creai o list proprie de posibile cerine (definim ct extensibil s fie aplicaia). Exemplu : Dorim n viitorul apropiat s deservim aplicaiile mobile prin servicii web(Restful). 4. Creai o lista despre ateptrile stakeholder-ilor de la soluia propus Exemplu: Directorul economic: reducere cu 10% al costurilor de vnzri Directorul IT: s reduc nemulumirea angajailor cu accesul la sistem Angajai: clieni s-i poat rezerva foarte rapid biletele. Not: lista de mai sus va fi una benefic n final la predarea aplicaiei cnd va fi prezentat aplicaia. Totodat pe parcursul discuiilor i al ideilor de implementare vom nevoile diferiilor stakeholderi. 2. Frizerul ortogonal: S ne orientam ctre ortogonalitate, adic s modularizm soluia. Astfel avem posibilitatea de a crea diferite module i interfee facilitnd testatarea i mentenana produsului. 3. DRY(Dont Repeat Yourself) Uscatul Cel mai cunoscut acronim legat de ideea: un singur rezultat la o singur problem. E important s nu ncercam s repetm codurile, modulele, interfeele care au aceeai funcionalitate. 4. Test it: testul cu oglinda Testabilitatea soluiei este cea mai vital pentru a susine o arhitectur robust, dar totui receptiv la schimbri. E important s decidem pn la ce nivel dorim s testm soluia propus: nivelul micro pentru care vor fi testat fiecare variabil, metod sau clas ori putem s ne orientm ctre o testare macro caz n care ne intereseaz s poat fi testate modulele. 5. FixIt: - un coafor priceput se respect: E bine de creat module care suport modificrile i fix-urile, astfel nct s nu aib impact asupra altor componente. n cazul n care fix-ul aduce modificri asupra mai multor module n acelai timp, e necesar de revizuit planul iniial, dac arhitectura chiar corespunde nevoilor noastre. 6. Cost of changes: plata la frizer arhitectura robust trebuie s suporte schimbri continue, dar n acelai timp preul schimbrilor trebuie s rmn minim. Pentru calculul costului schimbrilor se poate folosi o ecuaie simpl care avertizeaz asupra riscurilor:
Sum( Change[1..n]x Sum(Affected Module[1..m]) ) = Cost of Change
B. Shape it:Frizerul prietenul nostru
1. Slice Taie pe mrimea potrivita Descompune problema n probleme mai mici, funcionalitii mari n sub-funcionaliti ce pot fi rezolvate. alt metod este descompunerea n module/blocuri ce aduc mai aproape de conceptul OOP.
Unde n,m reprezint numrul maxim de schimbri i module. Fiecare schimbare i modul are valoare 1, desigur dac modulele sunt mai complexe putem defini pentru fiecare modul un cost specific. Costul maxim l vom obine pentru cazul n care
20

fiecare schimbare are impact asupra fiecrui modul. D. The Good is the enemy of The Perfect: s tindem la perfecionism Costul ideal este de 30% din costul maxim, costul De fiecare dat s ncercm sa mbuntim codul optim ntre 30% i 70%, iar costul critic peste 70% din existent. costul maxim. S nu ne lsm prad ideilor: mbuntirea nu se pltete, las c rezolvam cndva etc. Exemplu: n cazul a 3 module , unde Modul3 are cost 3, Respect munca ta i a altora. pentru la 2 schimbri avem urmtorul cost: Utilizeaz conceptul Benefits +1, ntotdeauna s aduci ceva n plus fa de ce i s-a cerut. o Change1 x (Module 1 + Module 2) + Change2 PROTOTYPE: crearea de prototipuri ne ajut s fim x (Module1+Module2+Module3) = 1x(1+1) + 1x(1+1+3) =2 +5=7 siguri c suntem pe drumul cel bun o Cost maxim: Change1(Module1 + Module2 + Mod DESENEZ: afiarea grafica a arhitecturii ne aduce ule 3) + Change2x(Module1+Module2+Module3)= 1x(1+1+3)+1(1+1+3)=10 beneficiul vizual al unei analize rapide o Cost Maxim : 10; Cost ideal: 3; Cost critic: 7. Lista de mai sus se poate completa cu multe altele, astfel nct n exemplul dat suntem la limit ntre costul critic i cel s fie una foarte complex i satisfctoare, de fiecare dat ns ideal, cea ce ne informeaz ca ar fi posibil ca arhitectura trebuie luat in considerare BENEFICIUL adus prin introducerea s fie afectat i s aib consecine majore. noilor complexiti. n urmtorul numr al revistei TSM vom identifica nite best C. Focus Point: de reinut practices pentru a crea arhitecturi accesibile ntregii echipe. S verificam calitatea, metrica, redundana modulelor i a claselor; S verificm dac arhitectura aleas sau standardele de aliniere (Togaf, ISO etc) se mai mapeaz pe soluia curent; S introducem puncte de control pentru validarea soluiei si a arhitecturi; S ne amintim de limitele de hardware, reea si a componentelor integrate; S inem minte c resursele sunt limitate (bani, dezvoltatori);
21
QA
Testarea n Cloud
Serviciile oferite de Cloud se mpart n dou mari categorii: SaaS i IaaS SaaS Software as a Service: adic nchirierea de licene software (pe baz de abonament). Mai exact, SaaS reprezint o metod de a furniza acces la licene software i funcionalitilor acestora printr-un serviciu Web-based. Folosirea acestei metode duce la eliminarea nevoi de a instala i rula aplicaia local ceea ce va duce la uurarea mentenanei i a suportului. Exemple de SaaS: CMS, CRM, Email, Virtual Desktop, Communications, Games, etc IaaS Infrastructure as a Service: reprezint nchirierea de resurse hardware (spaiu de stocare, memorie i procesor). Acestea similar cu SaaS, odat externalizate vor aduce o relaxare a mentenanei i a suportului pe local, focusul putnd mutat spre alte detalii. Exemple de IaaS: Virtual Machines, Ser vers, Storage, Load Balancers, Network, etc. n alte variante serviciile oferite de Cloud mai conin de asemenea PaaS i NaaS: PaaS Platform as a Service: nchirierea de platforme complete pentru development ce includ sistemele de operare, mediile de programare, bazele de date i web-serverele NaaS Network as a Ser vice : nchirierea reelei, serviciilor de interconectare, VPN, optimizarea resurselor alocate, amd. Cteva din avantajele oferite de Cloud ar fi mobilitatea, viteza, capacitatea de
n ziua de azi toat lumea vorbete despre Cloud, despre cum s ne mutm activitile pe Cloud, cum s ctigm timp folosind avantajele oferite de acesta. Dar pn 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 clienilor. stocare relativ nelimitat, puterea de procesare i memorie cu mult superioare, lipsa grijilor n ceea ce privete mentenana software i hardware. Alte avantaje pe care un manager le urmrete n mod particular ar putea fi reducerea cheltuielilor cu licenele software i hardware, dimensionarea costurilor n funcie de nevoi i transformarea costurilor de capital n costuri operaionale. Cine ofer aceste servicii? n general companiile mari gen HP, Keynote Systems, Advaltis, Compuware, Load Impact, SOASTA, etc. Acetia se folosesc de serviciile de hardware vndute sau nchiriate de Amazon, Google, Microsoft, etc. nainte s ne mutam testarea n Cloud?
A. Caracteristicile aplicaiei
Cloud-ul ne poate ajuta atunci cnd avem nevoie de conexiuni din diferite locaii geografice cum ar fi un site de socializare sau video-streaming. Testarea firewall-urilor i load-balancerelor implic cheltuieli hardware, software i ntreinerea acestora. n cazul aplicaiilor unde rata de cretere a numrului de utilizatori este imprevizibil sau unde avem multe medii de deployment, Cloudul se arat din nou mai eficient dect abordarea tradiional.
B. Tipurile de teste pe care dorim s le facem

Dintre cele mai populare activiti de testare pe care le putem face n Cloud: Stress Testing Load Testing Performance Testing Functional Testing Compatibility Testing Browser Performance Testing Latency Testing Mutarea n Cloud se face de obicei pentru activiti ce in de testarea performanei i simularea unui trafic ct mai apropiat de realitate, distribuit in locaii diverse. Aici, Cloudul se remarc prin adaptabilitate i rapiditate n ceea ce privete rezultatul final.
Testarea n Cloud
Testarea este o provocare pentru multe proiecte, n special pentru aplicaiile mari unde business-ul i performana au de suferit condiii grele de utilizare. Cantitatea de testcase-uri poate varia de la cteva sute la cteva mii, iar toate acestea necesit resurse semnificative de hardware i timp de execuie. S nu mai vorbim de numrul mare de resurse umane necesare pentru a putea acoperi aceste nevoi. Cloud-ul vine n ntmpinarea acestor probleme i ofer potenialul de abordare a acestora. Acesta ofer resurse precum virtualizarea hardware-ului n mod eficient, stocare nelimitat i servicii de software i hardware care pot ajuta la reducerea timpului de execuie. Cu toate aceste avantaje, migrarea n Cloud este o operaiune destul de costisitoare, iar uneori nu este neaprat cea mai bun soluie la toate problemele de testare. Aadar ce ar trebui luat n considerare
Paii de urmat
Aadar dup ce am stabilit c ne mutm n Cloud cu testarea, care ar fi urmtorii paii de fcut? n prima faz avem de identificat i stabilit care sunt scenariile pe care un
22
utilizator al aplicaiei le va face. Extragem testcase-urile i trecem la urmtoarea faz. Aceste dou etape sunt sau ar trebui oricum acoperite de la nceputul sprintului/ proiectului. Al treilea pas, cel de selecie a Cloud Service Provider-ului , trebuie fcut in concordanta cu specificul aplica si rezultatele pe care dorim s le obinem. 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 rmnem n urm n perioada imediat urmtoare innd cont de cerinele i
expectanele pe care noi le avem. la schimbarea sistemelor de operare, Al patrulea i al cincilea pas, Setup browser-elor; Infrastructure i Leverage Cloud Servers Mobilitate mare pentru departapresupun stabilirea hardware-ului necesar mentul de testare, acolo unde acesta rulrii testelor, calibrarea i optimizarea este distribuit n mai multe locaii; aici serverelor din Cloud ca s corespund testarea va avea un mare avantaj, timpul setup-ului de producie n care aplicaia petrecut n sincronizarea environmentnoastr va rula. urilor de test scade la minim. Evident, ncepem rularea testelor, R el a x are n c e e a c e pr ive te monitorizarea i apoi extragerea rezulmentenana serverelor de test pentru c tatelor relevante, a rezultatelor care ne trecnd pe Cloud, aceasta grija se exterintereseaz de fapt pe noi. nalizeaz i ea Flow-ul pare relativ uor i simplu din schema de mai sus dar totui ar fi cteva Dezavantajele mutrii in Cloud sfaturi pentru o migrare cu succes. Unul Configuraia iniial presupune nite dintre acestea este costuri pentru mutarea testelor i adapnelegerea platfortarea acestora la environmentul nou pe mei pe care se va care Cloud-ul le are. De aici se pleac de muta testarea i a obicei n luarea unei decizii dac merit configuraiei acesschimbat modul de testare curent sau nu; teia. Un alt punct Securitatea de asemenea poate reprede care trebuie inut zenta nc o problem pentru anumite cont nainte s ne tipuri de aplicaii; mutam n Cloud este Rezultate diferite provenite din identificarea tipuriacelai testcase datorate schimbrii lor de testare ce se performanei environmentului pe care preteaz a fi mutate providerul de servicii le poate avea; din interiorul companiei n exterior. Nu Concluzii toate se preteaz sau Vedem n jurul nostru tot mai multe merit a fi mutate. companii care ofer servicii de Cloud, n special de storage. Avem i companii oriAvantajele mutrii entate spre servicii mai specializate cum in Cloud ar fi testarea. Decizia de a muta testarea n C o s t u r i Cloud este pn la urm nu doar o decizie reduse odat mutai ce ine de factori tehnici ci i o decizie de n Cloud; scpm de ordin financiar. Avantajele pe termen scurt grija ntreinerii unui pentru o aplicaie mare probabil nu vor fi Cloud privat att din vizibile, dar n timp cu siguran acestea se punct de vedere a vor face simite, investiia fiind amortizat. resurselor hardware Aadar, ne mutm testarea n Cloud? ct i a resurselor umane implicate n Referine: acest scop. http://cloudcomputing.sys-con.com Spaiu de stohttp://wikipedia.org care foarte mare i http://ieeexplore.ieee.org/xpls/abs_all. accesibil de oriunde; jsp?arnumber=5463680 de p e de v ice-ur i mobile dar i PC-uri Rularea de Vlad Zeciu vzeciu@smallfootprint.com teste automatizate ce au fost iniial nreSenior QA Engineer @ Small Footprint gistrate i verificate local; Flexibilitatea
23
QA
Orchestrarea Testrii Automate
acebook, Google sau Flickr au posibilitatea de a introduce n producie pn la 10 versiuni noi de produs pe zi ntr-un mod transparent utilizatorilor. n lumea eterogen i agil din industria IT, dezvoltarea aplicaiilor i a serviciilor devine o provocare att datorit diversitii tehnologiilor i a produselor, ct i datorit numrului acestora. De asemenea, n companiile software mari unde exist departamente de Dezvoltare, Testare i IT implicate n procesul de dezvoltare exist nevoia de colaborare strns. Pentru asigurarea eficienei colaborarea se realizeaz prin procese i produse standard care, datorit diversitii proceselor i produselor utilizate, devine un obiectiv greu de ndeplinit. Metodologia de dezvoltare care accentueaz colaborarea ntre echipele de Dezvoltare, Testare i IT se numete DevOps. Aceast metodologie presupune definirea echipelor, a proceselor i a produselor folosite astfel nct ciclul de producie al unei versiuni s fie ct mai scurt. n companiile IT romneti, care implementeaz metodologia DevOps, se folosesc adesea soluii specifice, dezvoltate intern, precum scripturi sau diferite utilitare. n cazul proiectelor dezvoltate n regim de outsourcing acestea depind de procesele i/sau produsele impuse de nevoile i posibilitile clienilor. Departamentul i echipamentele IT sunt situate adeseori ntr-un centru de date la distan i care este bazat pe servere fizice, virtuale sau cloud. Prima problem o constinuie colaborarea ntre departamentele implicate. Din acest punct de vedere echipa de dezvoltare are, de exemplu, o viziune a calitii diferit de viziunea echipei de testare, echipa de testare asupra implementrii iar echipa de IT despre produsul dezvoltat i testat de ctre echipele anterioare. Echipele au nevoie de un limbaj comun pentru comunicarea eficient. A doua problem este aceea de integrare i standardizare a proceselor i produselor utilizate atunci cnd proiectele, produsele sau clienii se schimb. Pentru c soluiile iniiale sunt specifice proiectelor existente, acestea trebuie adaptate noilor cerine. Costul necesar implementrii unei integrri noi este semnificativ i trebuie multiplicat n funcie de numrul de produse noi utilizate i de natura lor. Prezentul articol prezint o abordare a celor dou probleme bazat pe o strategie de testare automat. Soluia denumit TAO se dorete s fie aplicabil n lumea DevOps i reprezint un exemplu i nu o soluie absolut. De asemenea, exemplele i tehnologiile referite sunt din lumea Java, iar aceast opiune e justificat de experiena autorului n acest domeniu IT.
Lucian Revnic
lucian.revnic@hp.com OO Content Arhitect @ HP Software Cluj
Strategia
Pentru dezvoltarea unei soluii fiabile i scalabile de testare automat, propunem observarea a trei aspecte: mediul de testare, testabilitatea produsului i integrarea continu
Mediul de Testare
Complexitatea mediul de testare
24

utilizat variaz de la un server fizic, localizat n proximitatea programatorului sau a testerului, pn la centre de date complexe, bazate pe tehnologii de virtualizare sau cloud. De multe ori mediul de testare este condiionat de costuri sau de disponibilitatea clienilor de aici i de provocarea asupra generalitii soluiei de testare automat. n categoria produselor gratuite intr VMware Player, Oracle VirtualBox, Linux KVM. Dintre soluiile comerciale de virtualizare cel mai des ntlnite sunt VMware vCenter, Citrix Xen i Microsoft Hyper-V. Cnd este vorba de tehnologii cloud Amazon EC2 i implementrile OpenStack (cum este HP Cloud) sunt liderii. Controlul soluia de testare automat trebuie s prezinte capabiliti de baz de control al mediului de testare. Este necesar ca sistemul de testare s permit provision-ul mediului de testare prin aciuni generice: pornire, oprire, configurare pentru ct mai multe tipuri de medii de test. Pentru aplicatiile care nu ofer un modul de instalare silenios, este util ca mediul de testare s permit revenirea la o stare iniial. Aceasta se poate face prin snapshot-uri sau dispozitive de stocare nepersistente(o astfel de funcionalitate este oferit de VMware vCenter)
Figura 2 Instalarea, configurarea i monitorizarea
Figura 3 Serverul de build invoc testete automate
utilizarea modului silenios de instalare/ dezinstalare, dar exist i soluii alternative care se pot utiliza; de ex dispozitivele de stocare non persistente menionate mai sus. Sistemul de testare automat trebuie s permit execuia local sau la distan de scripturi: Bash, PowerShell, Python, Perl etc. Pentru conectare la dista acesta trebuie s suporte protocoale precum SSH, WMI etc. . Configurarea - opiunile de configurare a aplicaiei. Dup instalarea aplicaiei, pasul urmtor este configurarea aplicaiei n vederea execuiei testelor automate. Pentru injectarea datelor de test i configurarea aplicaiei se folosesc frecvent opiuni precum: interfaa utilizator, protocoale web (REST, SOAP), fiiere, baze de date. Tehnologiile implicate adeseori n aceast faz sunt: Selenium, HP UFT (pentru interfaa utilizator), Soap-UI (SOAP), Spring, Apache Http Client (REST). Monitorizare - modalitile de observare a strii aplicaiei: interfaa utilizator, baza de date, fiiere log.
Sistemul de testare automat trebuie s obin rezultatele rulrii testelor pentru validare i s notifice echipele implicate asupra rezultatelor rulrii testelor. Tehnologiile folosite pentru ndeplinirea acestei sarcini sunt de regul aceleai cu cele menionate n seciunile de mai sus.
Integrarea Continu
Integrarea continu reprezint o practic de promovare a unei integrri frecvente a codului surs ntr-un sistem de control al versiunilor central, build-ul frecvent al aplicaiei mpreun cu rularea testelor unitare. Aceasta practic recomand existena unui sistem de build eficient, a unei suite de teste unitate, a unui sistem de control al versiunilor i a unui sistem de notificare. Sistemul de Build dintre diversitatea sistemelor am identificat Jenkins, Hudson i CruiseControl ca fiind cele mai utilizate n lumea DevOps. Integrarea pentru un proces complet este necesar integrarea dintre sistemul de build, testele unitare i produsele utilizare de echipa de testare
Figura 1 Provizionarea mediului de testare
Testabilitatea Produsului
Instalarea - modul de instalare i dezinstalare. De multe ori aplicaiile permit un mod de instalare silenios. Trebuie identificai parametri (fiiere, regitrii, baze de date etc.) modificai n procesul de instalare/dezinstalare. Aceasta este important pentru c, ntr-un sistem de testare automat este imperios necesar instalarea/dezinstalarea a diferitelor versiuni ale aplicaiei. Este recomandat
Figura 4 Arhitectura generic TAO
25
QA
Orchestrarea Testrii Automate
(HP ALM/QC, Jira, Selenium, HP UFT) precum i conectarea cu mediul de testare. Comunitile Jenkins/Hudson ofer extensii pentru diferite integrri precum Jira, Selenium, HP UFT, HP ALM/QC dar exist i alte soluii. Considernd toate aceste aspectele menionate, o arhitectur generic de testare automat este ilustrat n Figura 4. fluxuri care acoper integrri cu tehnologii precum HTTP, LDAP, SSH, WMI, Ant, PowerShell, integrri cu produse precum HP ALM, Jira dar i cu sisteme de virtualizare i cloud cum ar fi VMware vCenter, Hyper-V, Amazon EC2. Utilizatorul are posibilitatea s foloseasc fluxurile i operaiile oferite sau s-i creeze unele noi, prin crearea de noi fluxuri. Studio este un mediu vizual de dezvoltare care permite crearea de fluxuri folosind structuri i paradigme mprumutate din programarea orientat obiect precum: structuri de date (liste, iruri), structuri de control (if, case), reutilizare i ncapsulare. Fluxurile dezvoltate i testate n Studio sunt publicate ntr-o baz de date de unde sunt accesibile folosind o component web numit Central. De aici, utilizatorul are posibilitatea s planifice rularea fluxurilor, astfel nct acestea s fie executate de exemplu o dat pe noapte, dup fiecare build. grupate sub numele TAO (Test Atomation Orchestration). Soluia rezolv problema de colaborare ntre echipele de dezvoltare, testare i IT, printr-un mediu vizual uor de utilizat i de neles de ctre persoanele cu minim experien n limbajele de programare. Problema de integrare ntre diferitele tehnologii i produse este rezolvat folosind fluxurile i operaiile oferite de ctre acest produs. n Figura 5 sunt reprezentate cteva fluxuri utilizate folosind HP Operations Orchestration.
Soluia Noastr
Produsul HP Operations Orchestration(OO) automatizeaz procesele IT utiliznd fluxuri i operaii de automatizare. Operaiile sunt aciuni atomice care realizeaz sarcini specifice precum Remote Command Execution, SSH Command, SQL Query. Fluxurile sunt secvene de pai interconectai logic, acestea constituind, n parte, cte o instan a unei operaii. Fluxurile reprezint procese complexe de automatizare cum ar fi: Server Health Check, Provision Environment, Download and Install Application Build. Rezultate n prezent, produsul ofer o librrie Folosind produsul OO am realigratuit cu mai mult de 4000 de operaii i zat o suit de fluxuri de automatizare
Abordri Similare
Exist produse similare care ofer funcionaliti asemntoare cu OO dintre care putem enumera: Electric Commander, Microsoft System Center Orchestrator, UC4. Electric Commander reprezint, prin numrul de integrri i tehnologii DevOps utilizate (sisteme de build, servera de aplicaii, produse de testare), un competitor pentru produsul OO. Ambele produse ofer un mediu de dezvoltare vizual a fluxurilor, opiuni de planificare a rulrii acestora i sisteme de raportare i
26
Figura 5 Fluxuri HP Operations Orchestration
monitorizare. Pe de alt parte, OO ofer un set de fluxuri mult mai extins pentru provizionare i integrare cu alte produse precum Jira, HP ALM/QC, Amazon EC, HP Server Automation etc.
unei comuniti publice care s nlesneasc DevOps Webpage, November 2012. i s ncurajeze accesul la fluxurile deja existente.
Referine
HP Operations Orchestration, Official Webpage, Hewlett-Packard, November 2012, H P O p e r at i on s O rc h e s t r at i on , Concepts Guide, Hewlett-Packard, June 2010, Electric Commander, Official Webpage, Electric Cloud, November 2012, Top 10 Virtualization Technology Companies Webpage, Keneth Hess, 2010, Wikipedia, The Free Encyclopedia
Viitorul
Urmtorii notri pai sunt extinderea fluxurilor TAO care sunt necesare n diferitele scenarii DevOps precum integrarea cu produse de analiz a codului (Sonar) i cu aplicaii de provizionare opensource. Ne propunem s cretem gradul de contientizare a calitilor produsului HP Operations Orchestration n general i a soluiei TAO n particular prin crearea
27
management
OPTIONSABILITY O caracteristic discret a proiectelor IT

privire de ansamblu asupra actualitii sociale i profesionale ne relev o evoluie mai degrab exponenial, mai ales pe ultimii douzeci de ani, care face ca astzi beneficiile i standardele pentru persoana noastr s fie foarte ridicate. Dincolo de schimbrile evident perceptibile, dinamica i amploarea acestor evenimente a fcut ca n ultimii ani s aib loc i o important, dar subtil, schimbare a poziionrii accentului: conteaz realizrile, dar, mai mult dect att, astzi, conteaz opiunile pe care le ai. Dac mai sunt i domenii n care acest lucru este mai puin valabil, n IT aceast concluzie este ct se poate de real i prezent. Revenind la proiectele IT, probabil majoritatea, clieni i furnizori de soluii, ar defini o relaie de succes cnd livrarea produsului s-a fcut la timp, n bugetul alocat i a ndeplinit ateptrile legate de funcionalitate i calitate. Majoritatea managerilor ar considera c proiectul s-a terminat cu bine i i-ar ndrepta atenia spre o nou provocare. n realitate ns, perioada imediat urmtoare livrrii este un punct critic, acolo unde oportunitile apar, att pentru client (beneficiarul produsului software), ct 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 iniial a semnrii contractului. n general, la modul complet generic, nelegerea i realizarea unui proiect software adun mpreun, ca echipa funcional, trei pri: Analiznd proiectele de succes i mai detaliat, se constat ns c, dincolo de diferenele de tehnologie, metodologie i de process, succesul lor se datoreaz unei proprieti creia, negsindu-i un nume definitoriu, i-am spus optionsability. Se definete ca proprietatea de a avea i furniza opiuni. Relaia funcional ntre pri se transform puin i ncearc astfel s anticipeze drumul proiectului:
Bogdan Matei
bogdan.matei@3pillarglobal.com Senior Php Developer @ 3Pillar Global
Cum nehotrrea clientului este un fapt destul de comun iar managementul riguros i pragmatic, componenta tehnic i cunoate n schimb rolul precis. Dac pentru obiectiv sau produs toate prile se ngrijesc consecvent, responsabilitatea pentru optionsability revine: .developerilor i arhitecilor 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
28
programare
sau imperceptibil. Aadar, la nivel local, are loc construcia unei proprieti importante a proiectului, fiind un eveniment continuu, ataat fazei dezvoltrii proiectului. Ideal ar fi ca i clientul s contureze direcii de deschidere ale unor viitoare opiuni, dar n practic acest lucru este mai rar ceea ce face ca rolul tehnicienilor cu att mai important. i managerii au un rol important, prin atenia continu pentru meninerea proiectului n timp, buget i functionalitatea cerut. Am definit proprietatea, i-am exprimat durata de via, am gsit responsabilii, dar de ce este ea important i pentru cine? Pentru a rspunde de ce este suficient o privire mai atent asupra produselor care se bucur azi de succes: SUVs, smartphones, smart TVs, mobilierul modern (gen Ikea), articolele pentru sport, uneltele de bricolaj etc. i chiar tendinele din IT (Facebook, WhatsApp, iTunes etc). Aspectul unui produs (designul) i calitatea materialelor (sau implementarea) de obicei calific un produs spre atracia i afectivitatea consumatorilor (devin interesai de el), ns cele care construiesc legtura de succes sunt opiunile pe care produsul le ofer. Uneori opiunile oferite reuesc singure s decid asupra succesului. Majoritatea avem sau vom avea copii. Dup ce am realizat mai multe rateuri la cumprarea jucriilor, am constatat c, inclusiv de la vrste mici, alegerile se fac n mod natural dup opiunile disponibile. Nu cred c are rost s detaliez ce opiuni au Spiderman, Batman, Ironman, eroii din Star Wars i Transformers n ceea ce privete rspunsul la ntrebarea pentru cine?, rezultatul este simplu dar surprinztor: pentru toi.

Pentru client, implicat n comunitatea afacerilor, opiunile sunt mai importante dect realizrile n sine, n special n momente de criz, cnd posibilitile scad. Un argument n acest sens este evoluia aciunilor Apple n ultimul an, dei compania a raportat record la profitabilitate. A avea optiuni a ajuns s reprezinte un avantaj mai important dect a avea realizari n sine. Opiunile sunt pentru afacere un rezervor de siguran, o margine de flexibilitate, iar pentru proprietarul ei un confort care furnizeaz sentimentul ncrederii i libertii. n sine, aceste detalii pot parea lucruri nesemnificative, ns ele sunt motoarele care produc consecine n deciziile importante. Prin ndreptarea ateniei i dincolo de scopul proiectului, ctre opiuni, pe termen scurt este posibil s apar i o cretere a costurilor, datorit necesitilor de calificare mai ridicat i a schimbrilor de mentalitate necesare. Aceast mentalitate de a te gndi la opiuni, nu implic neaprat implementarea lor, ci doar o pregtire prealabil, nc din faza concepiei tehnice, pentru unele dintre ele - cele mai susceptibile s fie cerute sau avantajoase. Pentru selectarea lor este nevoie de comunicare ntre pri i o cunoatere atent. Pe termen lung ns (peste 1 an), ctigurile sunt incomparabile: crete eficiena prin reducerea timpului petrecut pentru reinventarea roii; se realizeaz o baz de cunotiine i unelte (re)utilizabile; scade necesitatea rescrierii proiectelor (comarul clienilor); ajut la realizarea mult doritelor best practice; scade timpul dezvoltrilor, compensate de adaptri i integrare a ceea ce exist facut; integrarea juniorilor sau a noilor venii se face mai rapid; estimarile sunt mai precise. Un motiv deloc de neglijat este i cresterea aprecierii clienilor, care ajung s se consulte cu tine, s te recomande i s aib ncredere n relaia de afaceri avut mpreun. n timp, rezultatele gndirii cu optionsability se transpun n reputaia companiei. Pentru echipa tehnic, avantajele sunt de asemenea considerabile: crete nivelul de profesionalism, cu implicare mai mare inclusiv n contextul de business (developerul se pune mai concret n pielea clientului i caut solutii i posibiliti), scrierea de cod devine mai provocatoare. A face o arhitectur flexibil sau a scrie cod usor de citit, reutilizabil i robust este mai entuziasmant i mai folositor. Odata codul scris astfel se adun o baza reutilizabil, crete ncrederea i se reduce stresul necunoscutelor, estimrile sunt o mai mic problem. Juniorii au de asemenea un model mai bun dect clasicul ncercare-greeal. Pentru echipa marketing, opiunile sunt materie prim de cea mai bun calitate. Luai spre exemplu cele mai cunoscute produse: Coca-Cola, BMW, Audi, Starbucks etc. Aproape c nu se promoveaz produsele n sine, ci direct opiunile sau emoii aduse de opiunile produselor. Opiunile ajut specialitii n marketing s conceap reclame mai atractive i mai eficiente, prin focalizarea mesajelor pe opiunile pe care oamenii le apreciaz cel mai mult, dar, atenie, oferite de produs.
29
management
OPTIONSABILITY - O caracteristic discret a proiectelor IT
Pentru consumatorul final a avea opiuni este o justificare retoric. Cu ct sunt mai educai, cu att oamenii realizeaz importana optiunilor n detrimentul activelor concrete (bunuri, bani etc.). Opiunile sunt vzute ca o soluie sau speran spre eficien, performan sau divertisment. Probabil pn n acest moment am lmurit aspectele definitorii ale acestei proprieti, dar ceea ce este mult mai important este punerea n practic. Ca orice schimbare de mentalitate nu cred c este realist de ateptat o aderen imediat i general la toate persoanele implicate. Aceast mentalitate necesit mai mult creativitate i pasiune (sau responsabilitate mai ridicat). ntruct principalii responsabili sunt tehnicienii, adeziunea lor la acest mod de a gndi este determinant. Ei trebuie s aib o bun cunoatere a scopului proiectului, de asemenea i o nelegere mcar prealabil a domeniului proiectului, i s-i valorifice competenele tehnice punndu-se mai ales n poziia utilizatorilor acelui produs. Trebuie s caute permanent nelegerea unor posibile evoluii a proiectului, s le sintetizeze n idei care se transpun n implementri clare i uor gestionabile (citire, utilizare, verificare, monitorizare, reutilizare, adaptare, extindere, (dez)activare). Tehnologic exist multiple ajutoare n acest sens, de la design patterns la metodologii i procese. Agile are o mare contribuie. Cea mai bun, scurt i concret recomandare pe care pot s-o dau n acest sens este c implementarea unei soluii software este direct proporional cu usurina comunicarii ei pe nelesul prilor implicate n acel domeniu. Codul este oglinda unei exprimari ideologice, relative la o cerin sau caracteristic natural. Metaforic vorbind scrierea unei poriuni de cod ar trebui fcut precum realizarea unui reportaj asupra unui peisaj. De obicei, peisajele au o construcie nchegat i astfel se concepe un proiect. Implementarea proiectelor cu optionsability ca al doilea scop nu este aplicabil tuturor proiectelor! Nu vine ca o reet prestabilit. Ea depinde foarte mult de context, de o analiz obiectiv a ctigurilor i costurilor. Din experien, ea se preteaz foarte bine proiectelor cu durat de via mare, cu necesiti de actualizare i mentenan frecvente sau proiectelor de tip fundaie pentru alte proiecte. Deciziile asupra opiunilor pregtite se iau pas cu pas i argumentat, iar confirmarea c drumul este bun se observ prin o stabilitate ridicat a calitii proiectului, o uurare n adaptarea la schimbri i o cunotin de cauz mai bun asupra implicaiilor.
30
programare
Dezvoltarea de aplicaii safetycritical n SCADE
Hunor Csomortani
Software Developer @ evoline
csmortani.hunor@evoline.ro
erinele impuse de standardele n domeniu fac ca dezvoltarea aplicaiilor critice din punctul de vedere al securitii (safety-critical software) s reprezinte o provocare continu pentru toi participanii n proces. Mediul de dezvoltare SCADE impune rigurozitatea necesar pentru aceste proiecte chiar de la nceputul dezvoltrii. Bazndu-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 concentrm la implementarea cerinelor de nivel nalt, i ne scap de grija comiterii greelilor de baz. Articolul propune s fac o scurt prezentare a mediului de dezvoltare, prezentnd avantajele, dezavantajele i provocrile la care programatorul trebuie s fac fa. sistemului. Tipurile de date disponibile sunt cele de baz (int, real, char, bool), avnd posibilitatea de a defini propriile tipuri compuse (iruri, enumerri, structuri) sau a importa tipuri declarate n C sau C++. La fel este posibil i folosirea unor operatori importai, a cror funcionalitate este implementat n alte limbaje de programare. Sincronicitatea modelului nseamn c rezultatele calculate sunt independente de ordinea de execuie, ele avnd o singur valoare posibil n cadrul unui ciclu. Astfel concepia de timp poate fi omis o abstractizare util n cazul sistemelor reactive, avnd ca rezultat un timp finit de execuie a aplicaiei, care respect constrngerile mediului de operare. SCADE impune aceste constrngeri teoretice n timpul modelrii, dar i printr-un pas de verificare a modelului creat. Aceasta din urm asigur corectitudinea designului creat din toate punctele de vedere, avnd un rol asemntor unui compilator. La capitolul de verificare putem folosi simulatorul pentru a pune modelul creat
Mediul de dezvoltare SCADE
Mediul de dezvoltare SCADE se bazeaz pe limbajul Scade, limbaj sincron conceput pentru dezvoltarea sistemelor reactive. Extensia oferit de SCADE acestui limbaj este un mediu de dezvoltare grafic, care permite modelarea aplicaiei ntr-un mod foarte asemntor proiectrii circuitelor integrate. Dezvoltarea n SCADE nseamn crearea unor operatori, prezentnd funcionalitatea acestora pe diagrame, folosind un set de operatori predefinii. Diagramele pot fi de tip data flow sau control flow (automate finite), fiind posibil i combinarea acestor dou abordri. Prin legarea operatorilor se creeaz modelul unei aplicaii reactive, menit s fie rulat ciclic, la nceputul fiecrui ciclu citind valorile de intrare i calculnd valorile de ieire, lund n considerare i strile interioare al
31
programare
Dezvoltarea de aplicaii safety-critical n SCADE
n micare. Setnd valori pentru interfeele de intrare se poate Operatorul RisingEdge din exemplul precedent este transforverifica starea celei mai mici pri al acestuia: valorile variabile- mat n urmtoarea funcie C: lor, al fluxurilor de date ntre operatori i n interiorul acestora, /* Playground::RisingEdge */ tranziiile i strile active al automatelor finite. void RisingEdge_Playground(
Exemplu
De exemplu, s modelm o aplicaie care controleaz un sistem de nchidere. S fie valoarea de intrare starea unui buton de comand (apsat sau nu), iar valoarea de ieire comanda de nchidere sau deschidere. Primul operator va transforma starea butonului ntr-o valoare rising edge: true numai n cazul n care starea butonului se schimb din neapsat n apsat. Funcionalitatea poate fi modelat n modul urmtor:
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;
Prin dezvoltarea n SCADE se poate asigura un nivel de calitate ridicat al aplicaiei pe tot parcursul procesului de dezvoltare, nefiind necesar folosirea altor instrumente n acest sens. Constrngerile teoretice al sincronicitii, aplicate din prin cellalt operator modelm strile sistemului (nchis/des- mul moment, ofer sigurana c rezultatul va face fa cerinelor chis), i tranziiile posibile ntre aceste stri, cu ajutorul unui impuse aplicaiilor safety-critical: sistemul va avea o stare bine automat finit. Condiia de activare a tranziiilor este valuarea true definit n toate condiiile i va reaciona ntr-un timp finit, uor a variabilei command. de definit i msurat. n acelai timp diagramele sunt suficient de
Avantaje
n pasul urmtor putem lega cei doi operatori, crend modelul aplicaiei.
Cu ajutorul generatorului de cod KCG putem transforma modelele create ntr-un cod C compilabil, lipsit de erori low level de programare. Deoarece precondiia generrii este un model valid, codul C pstreaz calitile teoretice sincronicitate, determinism al acestuia. Integrarea codului se realizeaz prin apelarea funciilor C generate. Se poate crea o clas wrapper, care s reprezinte interfaa ntre funciile C i restul aplicaiei, crend un singur punct de dependen fa de codul generat. Aceast abordare ne permite ca fiierele C s devin obiecte temporare n procesul de build, modelul SCADE prelund rolul de cod surs. Generatorul este certificat conform mai multor standarde de securitate din industrie: DO-178B (aplicaii din domeniul aeronauticii i aprrii), EN 50128 (aplicaii din domeniul transportul feroviar), IEC 61508 (aplicaii din domeniul industriei i energeticii) .a.m.d., lucru care faciliteaz procesul de acceptan a sistemelor dezvoltate cu ajutorul SCADE.
Generare de cod C
32

auto-explicative ca s reprezinte un mijloc Provocri bun de comunicare ntre participanii n Cea mai mare provocare la care proproiect. gramatorul trebuie s fac fa este s se obinuiasc cu abordarea sincron. Foarte Dezavantaje multe constrngeri, care n alte limbaje pot Punctele forte uneori ns devin i cele fi impuse numai prin tool-uri separate sau slabe: abordarea grafic cere o atenie mult o arhitectur vizat, n SCADE constituie mai mare n cazul dezvoltrii n echip. o parte integrant a limbajului de baz i n timp ce pentru obiectele textuale avem a mediului de dezvoltare, ruperea acestora la dispoziie instrumente mature pentru fiind imposibil chiar i n cazuri n care a mbina progresul fcut de mai muli acesta ar fi un lucru dorit. participani, n cazul diagramelor grafice acest lucru este o provocare continu, lucru Concluzii imposibil uneori, i o situaie mai bine de Bazndu-se pe un limbaj sincron, evitat. SCADE impune ca nsuirile cele mai Din cauza rigurozitii limbajului, importante ale aplicaiilor reactive timp dependinele dintre fiierele de model sunt finit de execuie i stri bine definite n toate mult mai mari: de exemplu, interfeele ntre condiiile s fie respectate pe tot parcuroperatori trebuie s corespund n mod sul procesului de dezvoltare. Generatorul exact pentru a avea un model valid, ceea ce de cod certificat faciliteaz transformarea necesit o cooperare mult mai strns ntre modelelor create n cod C i integrarea n dezvoltatori. restul sistemului. Cu toate dezavantajele SCADE ne ofer soluii limitate i de sale, mediul de dezvoltare SCADE este o cele mai multe ori foarte greoaie pentru a soluie matur i potrivit pentru dezvoltrata structuri de date foarte mari i com- tarea aplicaiilor safety-critical. plexe. La fel, nu este soluia ideal pentru dezvoltarea aplicaiilor care implic efectuarea unor calcule intensive.
33
programare
Trenduri i Big Data
u toii am auzit de trenduri. Avem trenduri n muzic, n mod i bineneles n IT. Pentru anul 2013, au fost anunate mai multe trenduri, care la ora actual fac deja parte din viaa noastr. Ci din noi nu am auzit de cloud, machine to machine (M2M) sau NoSQL. Toate acestea sunt trenduri care au ptruns n viaa noastr, fcnd parte din cotidian. Big Data este un trend care s-a manifestat i anul trecut, meninndu-se printre cele mai puternice trend-uri i n acest an.
Radu Vunvulea
Radu.Vunvulea@iquestgroup.com Senior Software Engineer @iQuest
n cadrul urmtoarei serii de articole doresc s vorbesc despre Hadoop. De ce? Big Data nu exist fr Hadoop. Big Data ar fi doar o mulime de octei pe care clientul nu ar ti cum s i proceseze. Clieni au nceput de mult timp s cear o modalitate scalabil prin care s putem procesa datele. n cazul sistemelor clasice, procesarea a 50T de date devine o problem. Sistemele de calcul pentru indexarea i procesarea acestui volum de date este extrem de costisitoare - nu doar financiar ct i din punct de vedere a timpului.
La ora actuala Hadoop este una (dac nu chiar cea mai bun) soluie de procesare a unui volum mare de date. nainte de toate s vedem cum a aprut i cum a ajuns s fiu un sistem care poate s ruleze distribuit pe 40.000 de instane fr nici un fel de probleme.
Puin istorie
n urm cu civa 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 soluie folosete pentru a putea procesa i stoca un volum mare de date. Fiind n era web, iar numrul de site-uri i de date disponibile pe internet era foarte mare - nu doar c era mare, dar cretea ameitor (i continu s creasc), Apache Software Foundation inspirndu-se din articolele publicate de ctre Google, ajut la creare Apache Hadoop. Putem spune c acest articol a devenit standardul pentru stocarea, procesarea i analiza datelor. Doua caracteristici foarte importante pentru care Hadoop este la ora actual un sistem pe care multe companii l adopt pentru procesarea Big Data sunt scalabilitatea i modul unic prin care datele sunt procesate i stocate. Pe toat perioada dezvoltrii acestui sistem Hadoop a fost i va rmne un proiect open-source. La nceput a fost sprijinit de Yahoo, care avea nevoie de un sistem de indexare pentru motorul de cutare pe care l au. Acesta sistem ajunge s funcioneze att de bine nct ajunge s fie folosit de ctre Yahoo i pentru publicitate. Un lucru extrem de interesant este c Hadoop nu a aprut peste noapte, iar la nceput nu era un sistem att de robust
34
management
Figur 1: Ecosistemul Hadoop
precum este astzi. La nceput scalabilitate era o problem, n momentul cnd era nevoie s scaleze mai mult de 10-20 de noduri. Acelai lucru se ntmpla n ceea ce privete performana, unde nu excela. Companii precum Yahoo, IBM, Cloudera, Hortonworks au vzut valoarea pe care Hadoop o aduce i au investit n el. Fiecare din aceste companii aveau un sistem asemntor, care ncerca s rezolve aceeai problem. La ora actual acesta ajunge s fie un sistem robust care poate s fie folosit cu succes. Companii precum Yahoo, Facebook, IBM, ebay, Twitter, Amazon l folosesc fr nici un fel de problem. Deoarece n Hadoop datele pot s fie stocate extrem de simplu, iar odat informaia procesat ajung s ocupe foarte puin spaiu, orice sistem legacy sau orice sistem extrem de mare poate s stocheze datele pe termen lung foarte uor i cu costuri minime.
extrem de costisitor, pre i ntreinere. HDFS este un sistem care nu are nevoie de hardware special. Ruleaz fr probleme pe configuraii normale, putnd fi folosit mpreuna cu calculatoarele pe care le avem acas sau la birou.
pentru a le procesa, acestea ne trimit datele stocate. HDFS este total diferit. Din cauza c lucreaz cu cantiti 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 transferm cantiti mari de date pentru procesare. HDSF ne permite n schimb s trimitem pe componentele unde datele sunt stocate logica de procesare. Prin acest mecanism, datele de procesat nu mai sunt transferate i doar rezultatul final trebuie s fie trimis mai departe doar cnd este nevoie. ntr-un astfel de sistem v-ai atepta 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 acelai fiier. De fapt HDSF este un sistem de stocare care permite s avem un singur writer i orici cititori. Este gndit n acest mod din cauz tipului de date care sunt stocate. Aceste date nu sunt date care se schimb des, care s necesite modificri. De exemplu log-urile unei aplicaii nu vor fi modificate, acelai lucru se ntmpl i cu datele obinute n urma unui audit. De foarte multe ori datele care ajung s fie stocate, odat ce sunt procesate ajung s fie terse i niciodat modificate.
1. Management la sub-sisteme
Poate una din cele mai importante proprieti ale acestui sistem este modul n care orice problem hardware este privit. De la bun nceput acest sistem a fost gndit s ruleze pe zeci, sute de instane, din aceast cauz orice problem hardware care poate s apar nu este privit ca o eroare, ca o excepie de la flow-ul normal. HDFS este un sistem care tie c nu toate componentele nregistrate n sistem vor funciona. Fiind un sistem care este contient de acest lucru, este mereu pregtit s detecteze orice problem aprut i s nceap procedura de recuperare. Fiecare component din sistem, stocheaz o parte din fiiere, iar fiecare bit stocat, acesta poate s fie replicat ntr-una sau mai multe locaii. HDFS este vzut ca un sistem care este folosit pentru stocare fiierelor care au de la civa giga i ajung de dimensiunea ctorva tera. Acest sistem este pregtit pentru a putea distribui un fiier pe una sau mai multe instane.
3. Portabilitate
nainte s vorbim despre arhitectura acestui sistem i modul n care lucreaz, a vrea s discutm 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 ct i ca un sistem de stocare a datelor. Cred c aceast proprietate l-a ajutat s fie att de rspndit. Din punct de vede software, acesta este scris n Java i poate s ruleze pe orice fel de sistem.
4. NameNode i DataNode
Stocarea datelor - HDFS
Modul n care este construit Hadoop este extrem de interesant. Fiecare parte din el este gndit pentru ceva mare, de la sistemul de stocare de fiiere, la modul de procesare sau de scalabilitate. Unul din cele mai importate i interesante componente pe care Hadoop le are este sistemul de stocare a fiierelor - Hadoop Distributed File System (HDFS). n general, cnd vorbim de sisteme de stocare cu capaciti foarte mari, gndul ne zboar la hardware custom care este
Dac analizm arhitectura unui astfel de sistem este necesar s introducem n vocabularul nostru doi termeni: NameNode i DataNode. Este un sistem de tip master-slave. NameNode este the master sistemului de stocare. Acesta se ocup de sistemul de stocarea a numelui fiecrui fiier i tie unde poate s fie gsit maparea fiierelor. Acest sistem nu stocheaz datele din 2. Accesul la date fiierele, el doar ocupndu-se cu maparea Sistemele normale de stocare de fiiere fiierelor, tiind n fiecare moment locaie au ca principal scop stocarea datelor, iar n unde aceste sunt stocate. Odat ce numele a cazul n care avem nevoie de aceste date fost rezolvat de ctre NameNode, acesta va
35
programare
Trenduri i Big Data
redirecta clienii spre DataNode-uri. DataNode reprezint slave-urile care stocheaz coninutul propriu zis al fiierului. Clieni vor accesa DataNode pentru a putea accesa informaia stocat scriere i citire a datelor. Fiind un sistem care este pregtit pentru ca o component s cad, pe lng NameNode, avem un Seccondary NameNode . Acest component face n mod automat checkpoint-uri la NameNode, iar n cazul n care se ntampl ceva cu NameNode-ul, aceast component este pregtit 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 funcia pe care NameNode-ul o are. Acesta nu va rezolva locaia unde fiierele sunt stocate. Singurul su scop este de a crea checkpointuri pentru NameNode. prin NameNode. 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 fiier sunt folosite. n funcie de locaia de unde se dorete s se acceseze aceste date, clientul vor avea acces la copia care se afl cel mai aproape de el. Din aceast cauz, HDSF este un sistem care tie cum arat reeaua sa intern incluznd fiecare DataNode, rack i restul sistemelor.
6. Structura fiierelor
5. Stocarea datelor
Toate datele care sunt stocate sunt sub forma fiierelor. Pentru client, un fiier nu este mprit n mai multe pari, chiar dac intern acest lucru se ntmpl. Intern, fiecare fiier este mprit n blocuri care ajung s fie stocate pe unul sau mai multe DataNode-uri. Un fiier foarte mare poate s fie stocat pe 2, 3 sau chiar 20 de noduri. NameSpace-ul controleaz acest lucru, putnd cere ca block-urile s fie replicate n mai multe locaii. n Figura 2 se poate vedea arhitectura acestui sistem. Ceea ce este interesant la aceast arhitectur este modul n care se lucreaz cu fiiere. Datele pe care clienii le acceseaz nu trec niciodat prin NameNode. Din aceast cauz, chiar dac avem un singur NameNode n tot sistemul, odat ce s-a rezolvat locaia fiierelor, nici o cerere de la client nu mai trebuie s treac
Figura 2
Modul n care fiierele sunt stocate pentru a putea fi accesate de ctre clieni este foarte simplu. Clientul i poate defini o structur de directoare i fiiere. Toate aceste date sunt stocate de ctre NameNode. Acesta este singurul care tie modul n care directoarele i fiierele sunt definite de clieni. Opiuni precum hardlink sau soft-link nu sunt suportate de ctre HDFS. 8. Namespace Namespace-ul pe care NameNode-ul l 7. Replicare are este stocat n memorie RAM, putnd s Deoarece datele stocate sunt foarte fie accesat cu uurin. Acesta este replicat importante, HDFS ne permite s setm pe hard disk la intervale foarte bine stabinumrul de copii pe care dorim s le avem lite numele imaginilor care se scriu pe pentru fiecare fiier. Acesta se poate seta n disk poart numele de FsImage. Din cauz momentul n care crem fiierul sau ori- c copia de pe disk nu este 1 la 1 cu cea cnd dup acest moment. NameNode-ul din memoria RAM, exist un fiier n care este cel care cunoate numrul de copii care sunt scrise toate modificrile care se fac trebuie s existe pentru fiecare fiier i are asupra structurii fiierelor sau a directoagrij ca acesta s existe. relor - EditLog. Prin acest mod n cazul n De exemplu cnd cretem numrul de care se ntmpl ceva cu memoria RAM replicri pe care dorim s le avem pentru sau cu NameNode-ul, recuperarea acestuia un fiier NameNode-ul o s aib grij ca este simpl i poate s conin i ultimele toate blocurile de date s fie replicate nc o modificri. dat. Treaba NameNode-ului nu se termin n acest moment. De la fiecare bloc n parte 9. Manipulare date acesta primete un semnal de tip sunt Un lucru extrem de interesant este n via la un interval specific de timp modul n care un client poate s creeze un heardbeat. n cazul n care unul din blocuri fiier. Iniial, datele nu sunt stocate direct nu trimite acest semnal, NameNode-ul va in DataNode, ci ntr-o locaie temporar. nceape procedura de recuperare n mod Doar n momentul n care exist destule automat. date pentru ca o operaie de scriere s Modul n care datele se replic este merite, doar atunci NameNode-ul este extrem de complex. HDSF trebuie s in notificat i copiaz informaia in DataNode. cont de foarte muli factori. n momentul n momentul n care un client dorete n care este nevoie s se fac o noua copie, s tearg un fiier, acesta nu este ters fizic trebuie inut cont c aceasta aciune o s din sistem. Fiierul este doar marcat penconsume limea de band. Din acest tru tergere i mutat n directorul trash. cauz avem un load-balancer care se ocup n trash este inut doar ultima copie a de distribuirea datelor n cluster. Exist fiierului, iar clientul poate s intre n acest mai multe opiuni director pentru a o recupera. Toate fiierele pentru replicare, din trash sunt terse n mod automat dup una din cele mai un anumit interval de timp. des ntlnite este n care 30% din Concluzie replici s fie pe n cadrul acestui articol, am preacelai nod. Din zentat cum a aprut Hadoop, care sunt punct de vedere a proprietile sale principale i modul n ldistribuirii replicare datele sunt stocate. Am vzut ca HDFS cilor pe rack-uri , este un sistem creat s lucreze cu multe doua treimi sunt date. Acest lucru l face extrem de bine i pe acelai rack , cu costuri minime. iar cealalt parte n urmtorul numr vom vedea cum este pe un rack putem s procesm aceast informaie. separat. Datele dintrun DateNod pot
36
programare
Programare Funcional n Haskell

lan Perlis zicea c un limbaj care nu afecteaz modul n care gndim nu merit cunoscut. Judecnd dup numrul mare de ntrebri pe Stack Overflow corelat cu numrul impresionant de articole, publicaii i postri pe reddit, Slashdot i bloguri, este evident c limbajul Haskell este un limbaj ce merit cunoscut. De fapt, programarea funcional n sine reprezint un domeniu pe care fiecare programator ar trebui s-l cunoasc puin. Istoria a fcut ca limbajele de programare rspndite acum s fie cele din paradigma imperativ. Codul scris de un programator nu este altceva dect un set de instruciuni i ordine date calculatorului. Dar foarte puini tiu c paradigma imperativ nu reprezint dect unul dintre cele patru modele de calcul inventate de matematicienii ce au pus bazele tiinei calculatoarelor. Foarte diferite, aceste paradigme au totui un lucru n comun: conform tezei Church-Turing nici o paradigm nu poate rezolva mai multe probleme dect alta. Cu toate acestea unele programe sunt mai uor de scris ntr-o manier imperativ n timp ce altele sunt mai uor de descris ntr-un limbaj declarativ. Acest lucru este vizibil n nsi preferina programatorilor de azi: dei toate paradigmele au aprut n aproximativ acelai an, faptul c este mult mai simplu de fcut un calculator pe modelul von Neumann a fcut ca cea imperativ s domine lumea limbajelor de programare mult timp. Cu toate acestea, celelalte i-au gsit i ele rolul, n special n inteligena artificial. Utilizarea ndelungat a limbajului LISP, cel mai vechi limbaj de programare, se datoreaz i contribuiei lui John McCarthy i a inteligenei artificiale. Un moment important este dat de publicarea articolului lui John Bachus Poate fi programarea eliberat de stilul von Neumann? Stilul funcional i o algebr a programelor. Acesta aduce la lumin un punct important: programele funcionale se pot compune mult mai uor din asamblarea unor componente testate anterior. Practic, acest articol a produs apariia unor limbaje funcionale noi pe lng LISP. Astfel, n anii 1970 au aprut nu mai puin de 10 limbaje de programare funcionale noi. Dintre acestea, limbajele din categoria ML reprezint un interes major prin dou limbaje: OCaml folosit i n prezent i Miranda. De la aceste limbaje au pornit n anii 1990 i programatorii adunai ntr-un comitet creat special pentru inventarea unui limbaj de programare ce ar trebui vzut ca un standard deschis pentru cercetarea n domeniul limbajelor de programare (nu doar funcionale) i al compilatoarelor: Haskell. Cu timpul Haskell a reuit s ajung un limbaj de programare puternic, destul de folosit n domenii diverse precum inteligena artificial, securitate, dezvoltarea aplicaiilor web sau a sistemelor de operare. Multe din noutile ce au fost introduse n limbaj au ajuns mai trziu i n C++, Java, etc. . Aceast dezvoltare se datoreaz att comunitii create n jurul limbajului (canalul de IRC #haskell de pe Freenode, grup special pe Reddit i Stack Overflow, o mulime de bloguri colectate sptmnal de Haskell Weekly News i bianual de Haskell Communities and Activities Report) ct i facilitii cu care poate fi nvat limbajul folosind resurse online (The Monad Reader, wiki-uri i wikibooks, etc.). Nume celebre din industria IT folosesc n prezent Haskell sau n producie sau pentru dezvoltare local: NASA, Galois, Facebook, Google, Microsoft, Jane Street, etc. Primul interpretor pentru Perl6 a fost scris integral n Haskell. Instrumente pentru validarea automat a programelor sau demonstrarea de teoreme sunt dezvoltate n Haskell (uneori mpreun cu Ocaml). Dar ce are limbajul att de atrgtor? Majoritatea celor care l folosesc se vor lega de dou aspecte: stilul declarativ i garania unei anumite corectitudini a codului. Programele scrise n limbaje funcionale sunt extrem de concise, se pune accentul pe ce ar trebui s fac secvena de cod, nu pe cum ar trebui s fac aceasta. De exemplu, secvena urmtoare sorteaz o list de elemente cu un algoritm de tip quick-sort (se alege mereu drept pivot primul element din lista sortat):
sort [] = [] sort (x:xs) = lesser ++ x:greater where lesser = sort [a | a <- xs, a < x] greater = sort [a | a <- xs, a >= x]
Comparai lungimea acestui cod cu cea a unui program similar scris n limbajul de programare favorit. n mod cert, stilul funcional beneficiaz de aspectul declarativ: codul este mai uor de citit, elemente necunoscute de sintax pot fi deduse din context, corectitudinea este uor de validat. Pentru a veni n ajutorul validrii 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 cercettori au promovat ideea c o folosire corect a tipurilor poate duce la garantarea unui invariant important: dac programul compileaz atunci sunt anse mari ca el s fie corect. De cele mai multe ori acest lucru nu este adevrat n totalitate. De fapt, se ncearc transformarea celor mai frecvente erori de runtime i bug-uri n erori de compilare. De exemplu, limbajul Haskell rezolv problema null-pointer-exception folosind un tip de date special numit Maybe: programatorul va ntoarce valori ncapsulate n acest tip din funciile care pot eua i compilatorul se asigur c orice folosire a rezultatului
37
programare
Programare Funcional n Haskell
ntors de aceste funcii este verificat. La extrem, s-au creat framework-uri de dezvoltare de aplicaii Web n care fiecare ir de caractere are un tip propriu: nu se mai pot confunda poriuni de CSS cu poriuni de HTML i nici nu se mai pot face atacuri clasice de tip SQL Injection sau similare. Un alt avantaj al tiprii statice este faptul c un programator poate cuta o funcie cunoscnd doar tipul acesteia. Exist dou motoare de cutare pentru acest lucru: Hayoo i Hoogle. Ambele vor cuta funcii ncercnd s generalizeze ct mai mult posibil argumentele oferite i s ofere sugestii particulare ct 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 funciile ce vor ajunge n programul final. O calitate important a limbajului o reprezint puritatea. innd cont c orice program trebuie s interacioneze cu exteriorul (citire date, transmitere date, etc), Haskell ofer i el funcii pentru operaiile de intrare-ieire. Dar, acestea vor fi marcate diferit din punct de vedere al tipurilor. Tipul oricrei aciuni 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 funcie ce folosete efecte laterale s nu poat fi chemat dect din funcii ce vor fi marcate ca avnd efecte laterale. Practic, codul este mprit n dou tabere: codul pur funcional pentru prelucrarea de date i codul imperativ pentru interaciunea 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 funciilor pure asigur paralelizarea uoar a codului. Este extrem de simplu pentru un programator s paralelizeze codul scris n Haskell: neavnd efecte laterale funciile pure pot fi apelate n orice ordine i ori de cte ori, rezultatele pot fi memoizate n cache-uri iar cod se poate scrie fr a fi necesare primitivele de sincronizare. Un alt atu important al limbajului este evaluarea lene. Programatorul poate scrie cod ce lucreaz pe date infinite ct timp acestea au o reprezentare finit fiind necesar doar evaluarea unui numr finit al acestora. Gndii-v la un ir de la matematic: este o structur infinit, dar poate fi reprezentat finit printr-o recuren i cnd i scriei termenii, v oprii mereu dup primii 3-4. Dei evaluarea lene permite scrierea de programe circulare i/sau lucrnd cu secvene infinite, uneori aceasta afecteaz analiza programului din punct de vedere al perfomanei. Din fericire, limbajul ofer construcii pentru controlul evalurii fiind astfel posibil ca programatorul s declare c anumii membri sau anumite argumente ale unei funcii s fie evaluate imediat. Pe de alt parte, evaluarea lene asigur evaluarea exact necesar a datelor cerute, irosind ct mai puini cicli de ceas. De fapt, mbinnd toate facilitile limbajului se poate scrie cod declarativ/ funcional avnd aceeai performan cu limbajele clasice C, Java, etc. Avantajul folosirii unui limbaj funcional este evident dac v gndii c un cod declarativ este uor de citit i la 2-3 luni dup scrierea acestuia: e mult mai facil corectarea bugurilor n momentul n care acestea apar. Codul Haskell poate fi interpretat sau compilat. Se recomand folosirea suitei GHC (The Glorious Glasgow Haskell Compiler Collection) mpreun cu Haskell Platform pentru a avea toate beneficiile limbajului i ale unor biblioteci de nivel nalt foarte performante i testate. Suita GHC vine cu un compilator (ghc) i un interpretor (ghci). Interpretorul permite dezvoltarea rapid a aplicaiilor, testarea codului sau a tipului unor expresii, etc. . Compilatorul permite generarea unui executabil avnd aceleai performane cu ale unui cod scris n limbajele clasice. Suita Haskell Platform ofer utilitare de profiling a aplicaiei pentru a optimiza codul ct mai mult posibil. Considernd c am prezentat destule detalii despre limbaj pentru a provoca pasiunea de a-l nva, trecem la noiuni de sintax. La final, n acest articol se va scrie un program ce va rezolva o problem simpl: dndu-se o permutare pentru a i se afla ordinul acesteia (numrul de aplicri ale permutrii asupra permutrii identitate pentru a se ajunge napoi la permutarea identitate). De exemplu, pentru permutarea (3 4 2 1 5), rspunsul cutat este 4: aplicnd (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 permutri presupune mutarea elementului de pe poziia I pe poziia corespunztoare 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 instania lista folosind un generator, ca n [ 1 .. n]. O list din Haskell permite adugarea de elemente doar n fa. Pentru aceasta se folosete operatorul :. Lista vid este reprezentat de []. Elementele unei liste sunt toate de acelai tip. Pentru a accesa un element, putem folosi operatorul !!. Majoritatea funciilor n programarea funcional sunt recursive. Astfel, se poate demonstra corectitudinea codului folosind inducie structural. De exemplu, funcia urmtoare va calcula lungimea unei liste:
length [] = 0 length (x:xs) = 1 + length xs
Prima linie spune c lungimea listei vide este 0. A doua spune c lungimea unei liste formate prin inserarea unui element x n faa unei lista xs este cu 1 mai mare dect lungimea listei xs. Programatorii obinuii cu prile lowlevel i structura compilatoarelor vor spune c recursivitatea consum spaiu pe stiv i c nu este un pattern care ar trebui folosit tot timpul. Pe de alt parte, compilatorul din suita GHC poate realiza transformri asupra funciei astfel nct s se ajung la a folosi recursivitatea de tip coad: fiecare apel recursiv nlocuiete cadrul de stiv al apelului anterior astfel nct rezultatul este ntors direct n funcia apelant. Dac v uitai la cele 2 linii pentru funcia length, vei vedea c exist cte una pentru fiecare constructor al listei. Practic, majoritatea funciilor n programarea funcional pornesc de la deconstruirea tipului de date: se scrie cte o expresie pentru fiecare constructor al tipului n parte. Considerai acum funciile urmtoare. Prima calculeaz suma elementelor dintr-o list, n timp ce a doua calculeaz produsul lor.
sum [] = 0 sum (x:xs) = x + sum xs product [] = 1 product (x:xs) = x * product xs
Dup cum observai, exist un ablon comun urmrit de toate funciile: exist un element iniial pentru cazul n care pornim de la lista vid i o operaie pe care trebuie s o aplicm peste elementul curent i rezultatul apelului recursiv. Practic, avnd aceste dou ingrediente putem mpturi lista ntr-o nou valoare. Acest ablon este capturat de Haskell prin intermediul a dou funcii (diferena fiind dat de direcia n care se realizeaz reducerea):
38

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
Observai c una dintre cele 2 funcii este tail-recursive de la nceput: apelul recursiv se efectueaz cu unul dintre argumente actualizat cu rezultatul parial de pn atunci. Diferena ntre cele 2 poate fi observat i din imaginea urmtoare.
Practic, folosirea abloanelor i funciilor predefinite ajut pentru a scrie mai puin cod (amintii-v principiul DRY) i pentru a ajunge la un cod pentru care este mai uor de demonstrat corectitudinea. n plus, compilatorul poate avea optimizri suplimentare ncorporate pentru aceste funcii speciale. Putem scrie acum cod pentru a aplica o permutare asupra unei liste: pentru fiecare element din permutare ntoarcem elementul de pe poziia respectiv din list (folosind !! pentru a obine elementul i map pentru a efectua operaia pentru toate elementele).
applyPerm :: [Int] -> [Int] -> [Int] applyPerm l p = map (\i -> l !! (i - 1)) p
din until. Pentru stare reinem dou valori ntr-un tuplu: un contor i lista curent, rezultatul permutrilor. Putem testa codul scris de noi n interpretorul ghci:
*Main> computeOrder [3,4,2,1,5] 4
Rezultatul este 4, exact cum ne ateptam. Putem testa s vedem dac rezultatul este corect. Folosim iterate pentru a apela o funcie la infinit, genernd lista [x, f x, f (f x), ...]. Folosim take pentru a lua doar primele elemente dintr-o list. Astfel, profitm 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]]
Avnd aceast funcie, se poate calcula rspunsul problemei folosind funcia until. Aceasta este oarecum echivalenta unei bucle while din programarea imperativ: primete un predicat (funcie ce ntoarce True/ False), o funcie pentru a itera de la o stare la urmtoarea i starea iniial i va ntoarce starea final, n momentul Alte dou pattern-uri importante cap- n care predicatul devine True. turate de Haskell sunt map i filter. Le vom computeOrder :: [Int] -> Int ilustra direct prin imaginea urmtoare i computeOrder perm = fst $ until test f $ f init where codul urmtor: l = length perm - 1
map f [] = [] map f (x:xs) = f x : map f xs filter p [] = [] filter p (x:xs) | p x = x : filter p xs | otherwise = filter p xs test p = snd p == [1 .. l] f (a, list) = (a+1, applyPerm list perm) init = (0, [1 .. l])
n ediia 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, aplicaia din articolul urmtor va fi mai complex dect cea de acum.
Mihai Maruseac
Cum funcioneaz funcia? Pornind de la o permutare perm, vom aplica applyPerm iterativ pentru a modifica starea curent
mihai.maruseac@gmail.com IxNovation @ IXIA membru ROSEdu, ARIA
39
programare
Recenzia crii:
RESTful Web Services Cookbook de Subbu Allamaraju
artea pe care v-o supun ateniei, 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 cuprinztor, iar provocarea vine n a gsi care sunt limitele unui anumit mediu de programare n a le implementa.
Silviu Dumitrescu silviu.dumitrescu@msg-systems.com Consultant Java @ .msg systems Romania
Ghidul conine modalitile de design ale serviciului web REST, att pe partea de client ct i pe cea de server, dar rezolv i probleme de performana, scalabilitate, ncredere i securitate. Prima informaie remarcabil pe care o putei 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. Gndul meu a zburat imediat n termeni comparativi i m-am gndit cnd vom avea i noi, in Romnia, asemenea teze de doctorat pe tematica arhitecturilor soft. Rspunsul este complicat, cu foarte mult munc, m hazardez s afirm c, poate, n zece ani. Viitorul v aparine! Voi reveni, totui, la menirea mea de a v prezenta cartea curent. mprit n patrusprezece capitole i cinci anexe, autorul prezint gradual toate resursele implicate n crearea i consumarea unui serviciu web REST. Organizarea fiecrui capitol este sub forma unor reete, adic se ridic o problem exprimat prin How to... sau When and how..., apoi se dau soluii i n cele din urm se poart discuii. Serviciile web REST au aprut ca o alternativ la serviciile web bazate pe SOAP. Ele folosesc protocolul HTTP, dar nu sunt limitate doar la acestea. Spre deosebire de SOAP, REST nu necesit parsare de
XML, nu necesit un header de mesaj ctre i de la service provider. Datorit protocolului de transport HTTP, REST folosete trei metode de comunicare ntre client i server: GET, pentru obinerea de informaii sigure i idempotente POST , pentru crearea unei noi resurse, pentru modificarea uneia sau mai multor resurse, pentru a rula cereri cu intrri mari sau pentru a executa orice operaii nesigure sau neidempotente, atunci cnd nici o alt metoda HTTP nu pare potrivit PUT, pentru a crea resurse noi doar atunci cnd clienii pot decide asupra URI-ului de resurse, altfel se va utiliza POST DELETE , pentru tergerea unei resurse i nu numai Dac ne referim la entiti i legtura cu un modul de persisten putem avea n vedere folosirea celor patru metode dup urmtorul sablon: GET, pentru interogare PUT, pentru update DELETE, pentru tergere POST, pentru creare Tot la nivelul comunicrii intereseaz modul n care grupm sau combinm resursele. Aceste aciuni au relevan n creterea performanelor i limitarea traficului.
40
business

s-i includ informaii adiionale n URI naintea trimiterii cererii ctre server. Fo r m at e l e At o m i AtomPub definesc resurse precum entries i feeds, reprezentarea lor i un protocol de operare pe aceste resurse. Serviciile web REST suport acest tip de format, pe lng cele anunate anterior. De la capitolul 7 ncolo autorul prezint, ceea ce a numi elemente avansate n cadrul serviciilor REST. Primul subiect atins este acela al negocierii coninutului, mai precis indicrii preferinelor clientului precum: tipurile media suportate, limba, codarea caracterelor, etc. . Problema folosirii cacheului este foarte important pentru c bine folosit conduce la scderea ntrzierilor percepute de utilizator, creterea ncrederii, reducerea costurilor, a ncrcrii benzii i a serverului. Bazat pe frecvena update-urilor se poate fixa o perioad de timp pentru care cache-ul poate servi o reprezentare. O nou provo care ce conduce la performan este dat de cereri condiionale. Acestea adreseaz dou probleme: pentru cereri GET ajut clienii i cache-ul s identifice dac o anumit reprezentare poate fi considerat proaspt, iar pentru cereri PUT, POST i DELETE cererile condiionale furnizeaz controlul concurenei. Controlul concurent este implementat n dou feluri: Concurena pesimist: clientul blocnd resursa, Concurena optimist: prin introducerea unui token de versiune ce se valideaz. Partea urmtoare cuprinde topicuri diverse relativ la o resurs, cum poate ea fi copiat, mutat, fcut undo i multe altele. Capitolul 11 face precizri importante relativ la acestea. Capitolul de securitate, 12, descrie aspectele legate de accesul la resurse, prin autentificare, precum i confidenialitate, integritate, prevenirea accesului clientilor ru intenionai sau neautorizai. Ultimul capitol se refer la extensibilitate i versionare i face referiri la meninerea compatibilitilor URI, a
reprezentrilor XML i JSON, extinderea atom-ilor, samd. Mie materialul mi s-a prut foarte cuprinztor. Citirea lui mi-a ridicat cteva probleme, n special pentru c unele dintre capabiliti 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 fcut au reuit, dar exist nc multe de testat. M adresez de aceea vou, cititorilor, s incercai implementarea n Java EE 6 a tuturor problemelor pe care autorul le ridic n aceast carte. Consider c dac vei reui s parcurgei ntreg materialul i s creai exemple ilustrative, REST nu va mai avea neclariti pentru voi. Atept cu mare plcere orice discuii! Ca de obicei, v doresc lectur plcut, Silviu Dumitrescu
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 reprezentri pe care autorul le descrie sunt: XML, pentru orice reprezentare JSON, pentru orice reprezentare, dar JSON poate oferi performan n parsare faa de XML Formate de date portabile precum: data, timp, numere, valuta Date codate binar precum: filme, audio, foto Erori, sub forma unui text plain sau a unui cod de eroare. Codurile de eroare sunt sunt forma 4xx, pentru erori datorate datelor de intrare ale clientului, i 5xx pentru erori de implementare de pe server sau datorate strii curente Resursele sunt identificate prin URI. Modul n care este construit URI-ul are o importan foarte mare n evitarea ambiguitilor i regsirea resurselor. Autorul descrie multe elemente necesare crerii URI-urilor, dar i unele dintre bunele practici, spre exemplu How to Keep URIs Cool n sectiunea 4.4. Un capitol aparte, capitolul 5, trateaz subiectul link-urilor web. Acestea sunt prezente n reprezentarile XML, JSON, in header-e i la client. Construirea templateurilor URI este eficient deoarece confer dinamicitate unui URI, clienii putnd
41
HR
SPRE COMUNITATEA IT via HR
ult lume i dorete un Silicon Valley la Cluj, cu firme IT ct mai inovative i creative. Clusterul IT intete acolo. n acest prim articol, dintr-o serie de patru, firma Danis Consulting i propune s urmreasc, din perspectiva resurselor umane din aceste firme, cum au evoluat ele, problemele pe care le ntmpin i, mai ales, cum pot s ajung s constituie o comunitate real de care s fim mndri?
Partea idealist
Dan Ionescu
dan.ionescu@danis.ro Director Executiv @ Danis Consulting
Cristina Nicule
cristina.nicule@danis.ro Consultant @ Danis Consulting
O comunitate matur de oameni i firme de IT care se susin reciproc i care i fac pe clienii 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 angajai din firmele IT clujene sunt cea mai critic resurs. Toate firmele se lupt pentru a atrage noi angajai i, aparent, salariul este singurul motivator. Mai sunt i alte incentives: spaii de joac, mese de ping-pong, masajul cervical i alte must-do care i fac extrem de invidioi pe angajaii din alte industrii. Pe de alt parte, inta declarat este de 20.000 de angajai. Se pare c diferena 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 fr acestea IT va rmne doar o surs de ctig financiar imediat, n general pentru patroni de departe. Riscul asupra firmelor rmne ridicat, mai ales cnd lohn-ul ocup o pondere mare n afaceri i este att de imprevizibil. n anul 2015, Cluj-Napoca va fi capitala european a tineretului, iar n 2020 (sperm s fie) i capital cultural. Acestea sunt momente de mare mndrie pentru comunitatea local i sunt i o msur a maturitii
acestei comuniti. Aici apare nevoia de viziune!
Partea concret
Firma Danis Consulting lucreaz de 15 ani n domeniul Dezvoltrii Organizaiilor. Fiindc am avut de-a face cu multe firme din ITC, credem c tim destul de bine particularitile acestei industrii i unele ci de a se dezvolta. Dorim s contribuim la construirea unei comuniti solide i durabile n Cluj. Iar aici nu este vorba de idealism firme solide nseamn afaceri bune, winwin pentru toi. Pentru aceasta am demarat pro-bono un proiect de cercetare, n care s ne ntlnim trimestrial, n discuii de 1-2 ore, cu un grup de oameni de HR din firme de IT clujene. Scopul acestor ntlniri dorim s fie: a. Analiza problemelor cu care se confrunt i gsirea de soluii utile pentru participani i firmele lor, b. Identificarea unor practici manageriale de succes care pot fi mprtite n comunitatea IT, c. Gsirea unor mecanisme de ntrire a comunitii locale IT. Rezultatele discuiilor, dar i o concluzie sintetic final, vor sta la baza unei cercetri tiinifice pe care o vom furniza celor interesai. Dup fiecare ntlnire vom face publice
42

concluziile prin intermediul partenerului nostru media Today Software Magazine. n cadrul lansrii ediiei care conine articolul nostru, vom putea dezbate problemele cu persoanele interesate, la workshop-ul TSM. Fiindc interesul i experiena noastr se leag de modul n care sunt conduse firmele, pe diverse nivele manageriale, am propus o succesiune de tematici pentru ntlnirile grupului: 1. Cum s-au dezvoltat, n Cluj, firmele de IT? Care au fost cele mai bune comportamente ale conductorilor care au favorizat creterea? Dar acelea care au inhibat creterea? Concluziile pot ajuta la dezvoltarea, n continuare, a firmelor din aceast industrie! 2. Care sunt particularitile procesului de conducere n aceste firme, n prezent. De exemplu se poate discuta despre: factorii care creeaz ncredere n manageri, despre conducerea unor echipe de oameni tineri i creativi, despre IQ vs. EQ. Fiind multe subiecte de interes, ne ateptm la dou ntlniri pe aceast tem. 3. Ce ajut i ce frneaz crearea unei comuniti deschise de IT? Cum s-ar putea depi actualele frne care favorizeaz feudalismul acestor firme (fiecare cu interesele proprii, cu multe orgolii, care creeaz o competiie puternic ntre firme, dar nu att de pia). Cum s-ar putea trece spre concepte mai moderne, de exemplu, s ne sprijinim unii pe alii pentru a fi mai atractivi cu toii n faa clienilor? Ne dorim ca aceste ntlniri s fie ct mai puin formale i mai mult dect o ocazie de a face networking. urmtoare s aprofundm aceste dezbateri, unor astfel de instrumente pot fi: s intrm mai n detaliu cu unele subiecte Utilizarea managerilor pentru flexibiprecum: Care este stilul de conducere cel lizarea unor procese. Dac conductorii mai potrivit oamenilor din IT? sau Cum dintr-o companie (de la diverse nivele) reuii s construii munca n echip adeau rspunderea pentru anumite evaluvrat, cu colaborare, comunicare i ajutor ri, decizii, intervenii legate de oameni, reciproc? atunci sistemele pot fi mai flexibile i mai Ideile cele mai valoroase mprtite n uor de implementat. acest prim workshop le prezentm n con O alt soluie este ca sistemele s tinuare structurate pe cteva capitole mari: decurg natural din practici curente de succes, pentru a nu avea cum s fie res1. Activitatea de dezvoltare a oamenilor din IT pinse. Este i experiena celor de la ISDC n acest domeniu exist de regul care au nivelul 3 de certificare CMMI, abordarea logic: de a interveni pentru bazndu-se pe procesele existente. dezvoltarea unei anumite arii atunci cnd se observ, se sesizeaz o nevoie specific. Din discuiile purtate s-a agreat ns fapNe-am bucurat s auzim c managementul tul c implementarea unor sisteme i bune din companii a ajuns la concluzia c trai- practici mature, se poate realiza cu succes n ning-urile pe un anumit subiect mai ales organizaii cu oameni maturi n atitudine. legat de abiliti de relaionare, de lucru Sperm ca n ntlnirile urmtoare s n echip, de comunicare nu sunt sufi- aprofundm mai mult sistemele de evaluare ciente pentru dezvoltarea sau schimbarea a performanelor din diverse companii. De unui anume comportament. iQuest-ul are data aceasta, Rzvan Voica de la iQuest ne-a o serie de exemple clare n aceast direc- oferit o imagine sintetic a sistemului din ie. De asemenea, Accesa a implementat compania lui de career management cu recent un Program de Dezvoltare complex scopul de evaluare i dezvoltare a oamenicare a intit echipa de conducere i ealonul lor din companie. Este un sistem extrem de imediat urmtor de conducere, program n interesant i complex n care se pune mult care s-au combinat activiti de tip training accentul pe responsabilitatea managerilor cu stabilire i implementare de obiective de din companie pentru dezvoltarea angajailor. dezvoltare individualizate, cu asistena con- Simplificnd, fiecare lider din companie este sultanilor de specialitate. i un career manager pentru un numr de Acesta este unul dintre principalele angajai. El are responsabilitatea de a-i ghida, motive pentru care de civa ani buni pe cei angajai, n procesul lor de dezvoltare. ncoace i noi, n calitate de companie de De aceea, n cazul managerilor din iQuest, consultan n domeniul dezvoltrii, ne abilitile de comunicare i cele complexe de strduim s propovduim programele de coaching sunt extrem de valorizate. dezvoltare i nu doar cursuri, care s conin i alte tipuri de aciuni (workshop-uri de 3. Elementele de cultur organizaional i follow-up, sesiuni de coaching de grup sau cult al muncii n IT individual, proiecte aplicative etc.) i care s Reprezentanii companiilor prezeni la fie ntinse pe o perioad mai lung de timp, acest workshop recunosc tendina pe pia n aa fel nct s permit exersarea noilor spre o mai mare flexibilizare i indepenabiliti, fixarea lor n context de munc real. den a forei de munc, ns n acelai timp, Pe lng aceste abordri fireti ale pro- admit c nu sunt nc pregtii pentru aa cesului de dezvoltare a angajailor, n ISDC ceva. IT-itii seniori pot s aprecieze mai de exemplu, am descoperit i o abordare mai mult timpul flexibil, de exemplu la ISDC s-a altfel. Oamenii de Resurse umane i asum implementat un sistem de lucru de acas o o mare parte din activitile de dezvoltare dat pe sptmn pentru angajaii care au conducnd training-uri i team-building-uri peste 6 luni n companie. Cei juniori i nu n interior conform unor sisteme i proce- numai, pn la un anumit moment al cariduri bine stabilite. Fiind aproape de colegii erei manifest nevoia de apartenen la un lor, ei pot s intervin i preventiv, nu doar grup / la o comunitate ceea ce angajarea ntratunci cnd sunt probleme. o firm de IT le poate oferi. Deocamdat, piaa de IT din Cluj nu este nc suficient de 2. Sisteme i procese de succes n companiile matur pentru a permite unui angajat IT o din IT libertate de genul: atunci cnd intru ntr-un Sistemele i procesele de Resurse Umane proiect s pot avea i libertatea s intru i n tind s fie percepute de ctre angajaii din alt proiect, al altei companii, n paralel. IT ca birocratice i, ulterior, s fie respinse. Fortech-ul a aplicat o reet de cultur Soluii pentru implementarea cu succes a organizaional extrem de deschis i cald
Prima ntlnire
Imagine de ansamblu asupra primei ntlniri:
Aceast prim ntlnire a avut ca scop analiza trecutului companiilor din IT pentru a gsi exemple de bune practici (sau de greeli) din care s nvm cu toii. Ne-am dat seama pe parcursul discuiei c era greu s ne meninem la nivelul trecutului, participanii la workshop revenind mereu la situaia 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 triete mai mult n prezent. Astfel, rezultatul acestei prime ntlniri este similar cu deschiderea cutiei Pandorei n sensul pozitiv al sintagmei. Practic, s-au mprtit cteva dintre subiectele interesante care stau la baza succesului organizaiilor din IT, urmnd ca n ntlnirile
43
HR
SPRE COMUNITATEA IT via HR
fa de angajai. Conducerea a manifestat n permanen sinceritate i transparen fa de angajai. Cultura organizaional 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. Discutnd despre cultur organizaional, valori fundamentale acele lucruri apreciate ntr-o companie am ajuns mpreun la o concluzie desprins din practica celor prezeni: pentru ca o organizaie din IT s-i asigure stabilitate n timp este mare nevoie n primul rnd s-i stabileasc clar acel set de valori care descriu personalitatea organizaiei (cum suntem noi, cum e la noi). Apoi, este vital s-i alegi oamenii cu care continui s lucrezi lund n calcul valorile i atitudinile lor, felul lor de a fi. Bineneles c i criteriile tehnice vor fi luate n calcul dar ele trebuie inteligent echilibrate cu cele ce in de personalitatea candidatului. n extrem, participanii la workshop ne-au dat exemple de situaii n care au fost respini candidai 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 potrivii n gndire, n atitudini cu organizaia din care fac parte tind s dea performane mult mai bune dect cei care sunt departe de felul de-a fi al companiei (chiar dac au cunotine tehnice excepionale). n aceast ordine de idei, provocarea oamenilor de Resurse Umane i a managementului din companiile de IT este meninerea acestei coloane vertebrale de valori, indiferent de greutile ntmpinate n momentul actual pe piaa forei de munc din Cluj. Dac oamenilor care vin la noi la interviuri nu le strlucesc ochii cnd le spunem despre tehnologii, nu sunt oamenii potrivii pentru noi.. Leadership-ul este crucial in orice organizatie care abordeaza dezvoltarea sistematica a factorului uman. Ei trebuie s fie implicai s dea mai departe [din modelul lor, din abilitile i atitudinile lor]. Abordnd discuia despre liderii din vrful companiilor de IT care pot fi CEO, Administratori sau chiar fondatorii companiei ne-am dat seama c, de regul, aceast persoan l reprezint pe cel care seteaz standardul companiei i c oamenii cel puin IT-iti romni au nevoie de acest lider care s aib viziunea companiei. Oamenii au nevoie de modele i cred n imagini de succes. Am discutat puin despre importana carismei liderului din vrful companiei i, chiar dac am gsit stiluri diferite de carism la companii diferite, concluzia noastr este c cel puin pentru aceste 4 companii liderul din vrful ei a fost un factor de succes n creterea i stabilitatea companiei. Uneori discursurile atractive i inspiraionale sunt cele care atrag oameni n jurul liderului i coaguleaz culturi organizaionale, alteori structura i consistena n abordarea unui anume tip de business sunt cele care ajut. lucruri care sunt importante i valorizate n cultura ISDC-ului. Rzvan Voica (iQuest) are un background vechi n IT (din 1997), avnd o diversitate mare de experiene profesionale, inclusiv ca i programator. Din 2011 a ajuns n echipa de management a companiei iQuest unul din juctorii importani pe piaa IT-ului din Cluj (i nu numai). Recunoate c aceast poziie de management n domeniul Resurselor Umane a fost dificil i foarte provocatoare pentru el. De cnd este n iQuest a iniiat i dezvoltat foarte multe sisteme i procese interne de management al Resursei Umane de care ar fi n stare s povesteasc cu mndrie i pasiune cteva ore! Cristina Puiu (Accesa), psiholog de profesie, acoper activitatea de Resurse Umane ntr-o companie mai mic dect celelalte 3 prezente la workshop, aflat ns n plin expansiune. Ritmul de cretere al companiei Accesa de la 20 la 60 de angajai, ntr-un singur an a supus-o la provocri importante pe partea de Resurse Umane. Experiena ei n firme de recrutare i selecie, precum i cea n domeniul auto au fcut-o s fac fa cu succes activitii de pn acum.
Participani
Alexandra Bayer (Fortech) a nceput munca n domeniul IT n urm cu 7 ani, cnd a devenit membr a echipei Fortech. Practic, a crescut odat cu compania i a nvat alturi de colegii ei din conducere cum s ctige ncrederea oamenilor din IT: cu argumente logice, concrete, statistici. Profesia de baz de inginer a ajutat-o mult n aceast abordare structurat a activitilor de Resurse Umane. Chiar i acum, cnd n Fortech sunt aproape 300 de angajai, Alexandra se vede ca un ajutor pentru toat compania, ca avnd ochi i urechi pentru toi, dei 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 particular al IT-ului de 3 ani. Atunci cnd povestete despre ceea ce face n ISDC, manifest evident entuziasm i mndrie
4. Actul de conducere n companiile IT

Un alt subiect prin care doar am zgndrit dezbaterile se refer la conductorii potrivii sau de succes n IT. La nivel de companii am ntlnit diverse principii, de ex:
44
HR
Managementul performanei
ntr-un mediu dinamic n care companiile pun din ce n ce mai mult accentul pe dezvoltarea angajailor, n ultimele decenii fiecare organizaie de pe glob a ncercat s defineasc elementele care contribuie la crearea acelui mediu organizaional de succes. Scopul lor este de a determina indicatorii de performan pentru o organizaie cu rezultate ridicate. Cerinele mediului extern foreaz companiile s se adapteze competiiei internaionale i s fie capabile s fie competitive simultan din perspectiva preului, calitii, flexibilitii i al relaiilor cu clienii. Managerii au dezvoltat un interes pentru crearea unei culturi organizaionale orientat spre performan i excelen. Publicaiile de specialitate descriu organizaiile orientate spre performan ridicat (high performance organizations) ca fiind organizaii care au rezultate financiare excepionale, clieni i angajai satisfcui, productivitate ridicat, organizaiile care ncurajeaz inovaia i dezvoltarea abilitilor de leadership. Printr-o studiere mai atent a literaturii de specialitate se pot identifica ns termeni caracteristici fiecrei categorii: dezvoltare financiar sustenabil, orientare pe termene lung, obinerea de rezultate excepionale, care se refer strict la companie ca entitate i la rezultatele acesteia. n 2007, Waal a oferit o definiie pentru organizaiile cu performan ridicat, comparnd performanele financiare i non-financiare ale companiei proprii cu cele din acelai 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 obine un avantaj competitiv n comparaie cu celelalte companii care au acelai domeniu de activitate. Evoluia resurselor umane pe parcursul ultimilor 50 ani este impresionant. De la personal, care se ocupa de partea legislativ: contracte de munc, protecia muncii, dosare de personal ale
pre deosebire de celelalte articole publicate n numerele anterioare, acesta va avea mai multe pri. Prima care va fi tratat n aceste pagini, ofer o definiie a conceptului de managementul performanei i a procesului, dar i a instrumentelor folosite pentru implementarea lui. angajaiilor, la resurse umane. Diferena ntre cele 2 concepte este mai mult dect evident, ncepnd de la o simpl interpretare a noiunilor. Cnd spui resurse umane te gndeti la resurse care pot fi valorificate pentru a se obine rezultate n cadrul firmei. Aceast arie are ca funcii importante: recrutare i selecie, evaluare, instruire, motivare i recompensare i partea legislativ i administrativ. Conceptul de resurse umane este o umbrela pentru noiunea de personal, nglobndu-l i oferindu-i funcii i atribuii noi. Mult vreme prea c acest termen definete cel mai bine tot ceea ce se ntampla n acest departament, ns s-a dovedit a nu fi aa, din simplul motiv c resursele umane sunt ntr-o continu dezvoltare. Termenul care descrie cel mai bine activitatea departamentului este managementul talentului. Acest termen pune accentul pe potenialul uman i pe o strns corelare ntre obiectivele individuale i cele ale companiei. Se vorbete pe lang funciile de resurse umane, de coaching i mentoring. Dou concepte impresionante care susin descoperirea potenialului printr-o dezvoltare continu, personal i profesional. Este foarte important ca persoanele s i imbunteasc aptitudinile i competenele. Aceast redefinire a conceptului de personal, resurse umane i managementul talentului evideniaz o evoluie continu n aceast era tehnologizat. Managementul performanei este n strns corelaie cu managementul talentului. Prin performan se evalueaz obiectivele individuale i ale echipei, care sunt n concordan cu obiectivele strategice ale companiei. Pentru ca firma s ctige acel avantaj competitiv pe o pia n continu evoluie trebuie s valorifice talentele umane pe care le deine. Conceptul de performan, la o simpl analiz a definiiei din dicionar este evideniat ca avnd o natur polivalent. Poate nsemna implementare, adic ndeplinirea unei cerine sau cereri, poate fi definit ca o competen/ abilitate de a face ceva. Pentru o nelegere mai clar a acestei noiuni este nevoie de o aprofundare a literaturii de specialitate. Lebas (1995) caracterizeaz performana ca avnd un impact n viitor. O afacere de succes este cea care i atinge obiectivele definite. Astfel, performana ine att de capabilitate ct i de viitor. Folan (2007) subliniaz trei obiective de guvernare ale performanei, care trebuie analizat de fiecare entitate n limitele mediului n care se decide a se opera. n al doilea rnd performana este legat de unul sau mai multe obiective stabilite de ctre entitatea a crei performan este analizat. i n al treilea rnd performana este redus la caracteristicile relevante i de recunoscut. Managementul strategic al performanei presupune alinierea obiectivelor individuale i a celor de echip cu obiectivele de dezvoltare de afacerii. Acesta urmrete crearea unei culturi a nvrii pentru a dedica resurse i timp mbuntirii performanei organizaiei. Acest concept a fost iniiat abia n secolul XX de ctre Peter Drucker n lucrarea sa Concept of the Corporation. Pn in anii 80 cercetriile s-au orientat spre dou domenii: impactul planificrii strategice asupra performanei firmei i rolul planificrii strategice n luarea deciziilor strategice. Managementul perfomanei la nivel operaional se refer la managementul operaiunilor, deoarece se centreaz pe atingerea obiectivelor i intelor departamentelor, de proiect sau ale echipei. Federick Taylor a dezvoltat conceptul de management tiinific. La nceputul anilor 20 General Motors a experimentat acest concept prin introducerea graficului DuPont pentru a susine reorganizarea companiei n structuri descentralizate cu
45
HR
Managementul performanei
centre de profit. n anii 30 n Frana a fost introdus tabloul de board pentru a monitoriza performana operaional a organizaiilor. Dei majoritarea companiilor franceze l utilizau, acesta a avut o rspndire minim peste hotare. Rdcinile managementului perfomanei din zilele noastre au fost puse de ctre filozofia japonez. Managementul performanei la nivel individual este considerat ca reflectnd nivelul de maturitate organizaional. La nceputul anilor 1800, Owen a monitorizat performana angajaiilor ca indivizi ce ndeplineau sarcini ca parte Figura 1 Fazele procesului de managementul performanei a unui grup. Pn dup cel de-al doilea rzboi mondial, sistemul de managemen- se desfoar el, pe parcursul unui an n CUM-ul procesului de management al tul performanei era utilizat mai mult n companie. perfomanei reprezint modalitatea prin domeniul administraiei publice, militare Definirea celor patru faze ale pro- care fiecare angajat i ndeplinete sarcinile i fabrici industriale. ncepnd cu anii 90 cesului: (1) Definirea ateptrilor, (2) i i realizeaz obiectivele. Prezentarea n managementul performanei individuale Evaluarea intermediar, (3) Revizuirea detaliu a valorilor organizaiei, semnaleaz a fost reorientat pe dou tendine. Prima lunar a obiectivelor i (4) Evaluarea descriu un set de competene pe care fiensemna creterea popularitii auto-evafinal a performanei. care angajat trebuie s le dezvolte la cel mai lurii performanei, iar a doua tendin Procesul de managementul perfomanei nalt nivel. alinierea managementului performanei are dou caracteristici eseniale: Lund ca exemplu Inovaia ca valoare strategic i managementul performanei a unei companii sau manifestarea unui individuale prin crearea unor noi instru Accentuarea CE-ului (a rezultate- comportament: suntem intuitivi, curioi, mente precum Balanced Scorecard, care lor), a CUM-ului (a metodelor prin care practici i inteligeni, ceea ce ne ofer posibiavea ca obiectiv reflectarea obiectivelor rezultatele sunt atinse) si a UNDE-ului litatea s dezvoltm noi idei pentru clieni, organizaionale n cele individuale. (plan de dezvoltare personal, obiective afacere i angajai. Prin operaiunile globale profesionale). pe care le dezvoltm, ncurajm idei n orice Fundamentele procesului mbuntirea comunicrii ntre regiune a lumii. Comportamentul ncurajat Managementul performanei are manager i angajat prin crearea unui este anticipeaz tendinele viitoare i idenca scop creterea responsabilitii de a dialog continuu care s aib la baz feed- tific oportunitile pe care capitalizeaz. produce rezultate i de a-i mbunti back i coaching. . Cum se msoar acest comportament abilitile i competenele. n cadrul compentru fiecare obiectiv? nseamn setarea paniei, managementul performanei a fost ateptrilor i a modului prin care angajaii ntotdeauna considerat un aspect pentru Elementele procesului de management pot s i ndeplineasc obiectivul lund n managementul resurselor umane pentru al performanei considerare comportamentele ncurajate de atingerea obiectivelor organizaionale, Evaluarea performanei trebuie s acestea. printr-o aliniere cu strategia organizaiei, reflecte ateptrile, iar realizrile sunt oriCea de-a doua parte a articolului va valorile i cultura acesteia. entate pe obiective i valori. Mai mult dect oferi detalii despre mijloacele procesului att ele trebuie s rspund ateptrilor de managementul performanei. Pn la clienilor. urmtorul numr, succes n definirea proProcesul i Instrumentele n continuare voi prezenta modul n cesului i a instrumentelor care se potrivesc Conform acestei figuri fazele proce- care este definit legtura ntre valorile cel mai bine companiei din care facei parte. sului de managementul performanei se organizaiei i procesul de managementul vor descrie etapele procesului aa cum performanei. Valorile care fac parte din
Andreea Prvu
andreea.parvu@endava.com Recruiter n cadrul Endava
Figura 2 Procesul de managementul perfomanei
46
HR
Poate da ... poate nu ...
orbesc cu mult lume n ultima vreme i vd c majoritatea dintre noi avem un dorin dar care rmne doar att. Avem cte un vreau s fac sport, vreau s citesc mai mult, vreau sa mannc mai sntos, vreau s m trezesc mai devreme, vreau Ne dorim foarte mult lucrurile respective, ne dorim s ne apucm i s ne inem de ele, suntem foarte motivai i chiar i aa ele De mine! Dac nu exist consecine negative reale sau pe termen scurt, creai-le! E mai greu s spui e foarte cald i bine sub plapum, cred c am s dorm n continuare. dac v ateapt cineva jos n faa blocului. E important s tim c morcovii i lupii nu trebuie s fie neaprat controlai externi sau palpabili. Dac vrei s identificai ce v mobilizeaz i ce v face s perseverai gndii-v i facei o list cu acele lucruri pe care le facei si continuai s le facei. Apoi punei-v ntrebarea de ce le facei, de ce continuai? Vei observa un pattern pe care apoi l vei putea aplica i la celelalte lucruri care ateapt pe list. Dac vrei s tii mai multe despre motivaie i despre cum funcionm noi ca oameni v recomand doua cri absolut excepionale si un TED talk: Daniel Pink DRIVE BF Skinner Beyond Freedom and Dignity
nu se ntmpl. V provoc la un joc. n poza de mai jos Suntem foarte motivai! Suntem foarte este un desen a unui iepure (fiecare figur motivai? are o etichet lingvistic). ntrebarea pe care v rog s v-o adresai este: Definim motivaia ca acea energie care Iepurele va fugi mai repede i pe o disne mobilizeaz s iniiem o aciune i apoi tan mai lung n care dintre cele dou ne face s o meninem la frecvena i inten- situaii? sitatea dorite. Cnd este fugrit de un lup fioros sau Dar ce este motivaia? n primul rnd cnd are un morcov gustos n fa? unul dintre cele mai folosite, dar poate cel mai puin neles concept. tim cum se simte cnd eti motivat, putem recunoate aceea energie. Putem spune cum apare? Cum se menine? 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 apucai s facei acel lucru pe vi-l dorii sau s nu l facei, dar fr s v mai Rspunsul este c va fugi de lup mai simii vinovai. mult i mai repede. Probabil se va porni sa Pentru asta vom folosi o definiie de alerge si dup morcov ns cnd va deveni lucru a motivaiei: foarte obosit va spune Nu mi-e atat de Motivaia este acea energie care ne foame. Morcovul e acru. face s considerm c efortul de a face E bine s nu existe numai lupi, e bine s un anumit lucru este mai mic dect con- avem i morcovi dup care s alergm. Dar secinele aprute ca urmare a realizrii morcovii singuri nu vor face iepuraul s i acelui lucru. zburleasc blnia pentru foarte mult timp. Orice aciune necesit efort. Efortul respectiv trebuie s merite s fie depus. Dac tim asta la nivel teoretic, de ce nu Merit s fie depus atunci cnd ca urmare o aplicm i n practic? a efortului se ntmpl ceva care este mai Dac ne-am stabilit un obiectiv pentru relevant sau mai important ca beneficiul a avea anumite beneficii, haidei s ne gnnedepunerii efortului. dim i la tot ce pierdem sau la consecinele Ei bine, mai este un mic detaliu. Noi negative care ar rezulta din nemplinirea tim deja ce e scris mai sus despre moti- acestuia. vaie. Dar mai e un mic detaliu legat de Pentru c dimineaa cnd trebuie s ne consecine i de cum ar trebui s fie ele. trezim, s ne lum adidaii i s ne apuCnd ne gndim s ne apucm de sport cm de alergat, toate lucrurile bune nu vor ne gndim la asta n termeni de toate bene- prea c fac s merite efortul. ficiile pe care le-am obine dac am face-o. Da, aa bine m voi simi dup ce Asa e? Ne propunem s ne apucm de sport alerg, voi avea energie toat ziua, voi pentru c viaa va fi mult mai frumoas gndi mai limpede, voi fi mai agil, voi fi dac am face-o. Problema este c noi ca mai fericit. Da, dar aa de bine e sub plaoameni nu funcionm aa. pum cu ochii nchii.
V mulumesc i v urez alergare uoar!
Antonia Onaca
anto@aha-ha.com de aproape 10 ani trainer, psiholog, consultant sub form de antreprenor, intraprenor i antreprenor din nou
47
startup
Roller Coaster-ul Imagine Cup

magine Cup este o competiie anual organizat de Microsoft ce promoveaz inovaia i tehnologiile proprii. Echipe de pn la patru studeni, n decursul unui an, accept provocarea de a scrie o aplicaie care s contribuie la Millenium Development Goals. Anul acesta ns, condiia temei a fost revocat, oferindu-ne libertatea de a construi un joc distractiv, care s nu poarte responsabilitatea rezolvrii problemei foametei n rile subdezvoltate. Am amnat participarea la aceast competiie nc din primul an de facultate. Dar acesta era nceputul celui de-al treilea meu an, iar cu doar doi ani rmai pn la absolvire, nu mai aveam muli anul urmtor rmai. Trebuia s fac ceva.
JavaScript
n fiecare an, Microsoft anun tehnologiile dintre care studenii au de ales i pe care sunt nevoii s le foloseasc. Printre cele propuse anul trecut se afl HTML5. Poftim? HTML5 nu este tehnologie Microsoft! i totui 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 urmtoarea lun citind articole de Douglas Crockford i John Resig. Am scris o colecie de experimente care nu vor vedea niciodat lumina zilei. Scopul meu era s construiesc un engine ntreg n JavaScript de la zero. Sistemul de input, grafic, audio, totul. Urma s folosim acest engine pentru a construi jocul nostru extraordinar. Aveam un sistem de input funcional i
un schelet pentru sistemul grafic. Scrisesem de asemenea un plugin pentru Bl e nd e r c are e x p or t a modelele 3D si shader-ele n format JSON. Engine-ul putea ncrca modelele si le putea desena folosind shadere. Funciona i era superb. Asta pn cnd au aprut regulile pentru Microsoft Imagine Cup 2013 , iar HTML5 dispruse 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 abilitile si pasiunea lor, iar mpreun simeam c putem face acest lucru posibil. Nu voiam s facem greeli stupide, aa c ne-am decis s nu scriem nicio linie de cod pn 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, simeam c pentru a face un joc distractiv aveam nevoie de un simulator de fizic. Am nceput s ne ntlnim n weekenduri, s discutm idei de joc i s urmrim alte jocuri asemntoare. Ne doream un joc care s fie simplu (spre deosebire de complex), cu o mecanic uor de neles, i care s conin puzzle-uri creative construite pe baza mecanicilor. Oricare ar fi ideea final, aceasta trebuia s fie distractiv, uor de neles, iar puzzle-urile trebuiau s fie rezolvate folosind creativitate i inteligen. n decursul ctorva sptmni am nceput sa punem totul cap la cap. Jocul nostru urma s aib grafic 3D ntr-o lume 2D. Simulatorul de fizic va funciona de asemenea
n doar dou dimensiuni. Lumea jocului va fi plin de tehnologie extraterestr. Puzzleurile vor necesita folosirea unor abiliti i tehnologii pentru a muta lucruri i a repara interiorul unei nave distruse. Urma s avem cuburi pe care juctorul s le poat muta i folosi pentru a construi aparate cu abiliti i scopuri neobinuite. Spre exemplu, cu reeta potrivit, zece cuburi ar putea fi folosite pentru a construi un dispozitiv ce inverseaz gravitaia. 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 simeam ncreztori i ne plcea direcia n care mergea proiectul.
Unity
Odat ce am gsit ideea general, a trebuit s alegem tehnologia n care o vom implementa. Platformele XBOX i mobile au ieit din ecuaie deoarece nu aveam tehnologia necesar. Aa c am rmas cu PC-ul. Citind un topic interesant pe forumurile Imagine Cup, am descoperit c aveam voie s folosim engine-uri de jocuri ca Unity, sau chiar Unreal, att timp ct foloseam produse Microsoft n procesul de dezvoltare (e.g.: scripturi C# n Unity). Ne-am gndit: Asta e super!. Nefiind nevoie s ne crem propriul engine grafic puteam s ne concentrm pe jocul propriuzis. Aa c fiecare dintre noi ne-am instalat Unity i am nceput s facem tutoriale. Am creat un demo n care o armat de cuburi urmrea cursorul iar cuburile se sprgeau dac erau lovite tare de perete. Unity avea
48
tot ce ne era necesar, inclusiv un editor foarte bun pe care l puteam folosi s tragem din meniul de unelte diferite obiecte pentru a crea jocul. De fapt, era prea mult de tras i prea puin 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 att de complex nct gndul la ct trebuie s nvm pentru a-l putea folosi eficient, ne ddea fiori. Am realizat curnd c versiunea gratuit de la Unity nu avea facilitatea de render targets. Acest lucru nsemna c nu puteam face niciun efect special, nici mcar un efect simplu de conturare pentru a marca cuburile selectate. Acest lucru a fost dezamgitor deoarece aveam cunotinele necesare pentru a implementa efecte, dar engine-ul pur i simplu nu ne lsa. Iar noi sub nicio form nu puteam plti 1500$ pentru asta. Aa c, pentru a doua oar am aruncat totul i am nceput de la zero...
XNA
Ultima noastr alegere a fost XNA (XNAs 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 librrii matematice. n sfrit eram gata s ncepem dezvoltarea jocului nostru. Gsisem ideea de baz i alesesem tehnologia adecvat. Pcat 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 pregtit mediul de lucru (XNA nu merge n mod implicit cu Visual Studio 2012) i ne-am mprit sarcinile ntre noi. Aveam nevoie de un artist iar eu eram cel mai potrivit; Andrei n aprilie a trebuit s trimitem jocul urma s se ocupe de integrarea sistemului pentru runda de calificare n ciuda faptude fizic i implementarea logicii jocului c nu era nici pe aproape gata. Echipa a lui, Adrian urma s creeze sistemul grafic lucrat toat noaptea dinaintea rundei pentru a crea un demo jucabil, programnd non-stop. Am adugat funcionaliti i am fixat bug-uri fr s clipim. Dimineaa devreme am asamblat mpreun cteva nregistrri din joc ntr-un trailer epic, ce nfia un robot curajos luptnd mpotriva unui univers nemilos. Da, da, tim, nu avea nicio
i shader-ele iar Timotei urma s lucreze pe partea de interfa utilizator i sistemul de intrare (tast atur, mous e, Kinect, etc). Am nceput s dezvoltm, ncetul cu ncetul, folosind Skype pentru a comunica zilnic. Ideea jocului s-a s c h i mb at d e - a lungul proiectului. Am adugat un caracter principal n poveste: un robot n form triunghiular care umbl cu ajutorul unor enile i are nite abiliti interesante. Am ncercat cteva stiluri grafice, dar nu am fost mulumii de rezultate. Unele probleme au fost din cauza modului n care era unghiul camerei sau felul n care texturile erau filtrate, dar majoritatea au fost din cauza lipsei mele de experien. Pn la urm, simulatorul de fizic s-a integrat superb cu jocul. Andrei a avut ideea de a simula enilele prin fizic, aa c am exportat fiecare pies separat (o roat, o enil i un corp) iar el le-a folosit pentru a construi robotul ca un sistem de componente simulate fizic. Asta nseamn c atunci cnd robotul se deplaseaz, se rotesc de fapt cele trei roi. Sistemul de fizic folosete fora de frecare dintre roi i enile pentru a face robotul s se mite. Aceasta s-a dovedit a fi cea mai important decizie pe care am luato n legtur cu design-ul jocului.
legtur cu jocul nostru, iar judecnd dup grafic... era un dezastru. Majoritatea texturilor au fost luate rapid de pe Google, iar indicaiile din joc erau afiate cu un font rou 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 puin de-o sptmn nainte de finala naional. Aceasta nsemna c mai aveam cinci zile s facem jocul prezentabil. Am umplut lista de TODO-uri cu o mulime de funcionaliti noi: un nivel secundar, grafic mai bun cu texturi noi, depth of field, o rescriere a interfeei utilizator i multe altele. Cu o zi nainte de final aveam nc lucruri neterminate: depth of fieldul trebuia mbuntit, indicaiile din joc trebuiau i ele mbuntite, meniul nu era finalizat i nc ne lipseau texturi. Ne rmseser 24 de ore pan la prezentare, iar daca experiena ne-a invaat ceva, este c suntem foarte productivi pe ultima sut de metri.
Alex Pana
alex.pana@vertexarmy.org internship student @ Tora trading
49
diverse
Gogu i plinul de benzin

ogu i lu tacticos, ca de obicei tava cu mncare, l cut din ochi pe Miu i i trebuir cteva secunde pn l gsi. Frate, are sta un dar de a se aeza mereu n cel mai ndeprtat col al slii de mese, gndi amuzat pornind spre el. Rspunse la saluturi i se simi oarecum important vznd ci se ntrerupeau din mncat s l salute sau s-i ureze poft bun. Deh, sunt de ceva ani n comelia asta... Se aez satisfcut la mas lng Miu, i zmbi dar realiz instantaneu eroarea major pe care tocmai o comisese. - Uff, Gogule, zi i tu, ce s fac? S taci i s m lai s-mi tihneasc mncarea, asta s faci. Evident, Gogu ddu replica numai n sinea lui, n-ar fi putut s-l amreasc i mai mult pe Miu. i plcea mult tnrul linitit, calm pn i n situaiile 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 multinaional la care lucrau mpreun de ceva timp. Numai eu l mai pot scoate din linitea i calmul lui, chicoti tot n sinea lui Gogu. i for o grimas serioas pe fa i oft a acceptare, pregtindu-se pentru a cel puin zecea oar n ziua respectiv pentru lamentrile lui Miu. - No, vezi Gogule, c pn i pe tine te apuc oftatu. Io ce s mai zc?! mi vine s m duc la efu... Se opri brusc, minile rmseser n aer ateptnd continuarea fluxului verbal pentru a-i urma micarea. opti apsat, aproape suiernd fiecare cuvnt: Gogule, eti un geniu! Se uit ndelung n toate direciile. Zici c-i radar, i spuse Gogu, i se ridic imediat ce l localiz pe efu. Cum privirile i rmseser lipite de masa la care efu i savura linitit prnzul, Miu nu realiz cnd rsturn tava i nici mcar nu ddu vreun semn c ar fi auzit zgomotul tacmurilor care poposir pe gresie. Paharul cu ap se cltin nehotrt iar apoi decise s se verse n direcia unui Gogu rmas cu gura cscat, incapabil s articuleze vreun cuvnt, nenelegnd care este meritul lui n toat povestea. Sri ns n sus, imediat ce apa din cascada improvizat se scurse pe genunchii si. Toat povestea prea ireal, desprins dintr-un film al crui scenariu i era total necunoscut, aa c l urm cu nedisimulat curiozitate pe Miu. Zgomotul tacmurilor i defilarea cu pas apsat al celor doi atrsese i atenia celorlali colegi aa c, pe cnd ajunseser la masa lui efu, toate privirile erau aintite spre ei. - efu, trebuie s m ajui, c nu mai am nici o soluie, tii c deadline-ul i mult prea strns i noi am promis c livrm la timp, dar acum toate resursele sunt luate de proiectul din Anglia. i am tot cerut la tt 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 mbuctura, se uit lung la Miu i spuse: - Poft bun i ie, Miule. Hi-hi, dac replica asta s-a dorit o ironie subtil, hai c i-a ieit, rse Gogu pe sub musta. Evident a fost mult prea subtil pentru Miu sau cel puin pentru starea de surescitare n care
se afla acesta, cci omul nu i iei din ale lui nici mcar o clip. Continu fr s clipeasc mcar: - S ai i mata, efu, ce zici m rezolvi i pe mine cu o resurs extern? Numa dou sptmni, maxim trei. - Miule, zici c eti fulger! Ce e cu viteza i cu logoreea asta, parc n-ai fi tu. Iar tu, Gogule, terge-i rnjetul la de sub musta, ai oameni s-i dai lui Miu? Sau poate ai buget pentru resurse externe, ei? - Care oameni efu, c deja mi-ai luat doi. De un s-i dau mai muli?! nghe Gogu. Se gndi apoi la buget i se prinse imediat c a fost luat peste picior. Hai, mi efu, zu aa, faci mito de noi? - Pi cine-a-nceput, mi biei? De unde bani pentru resurse externe? Mi Miule, 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 prioritile. Asta e, dac buget nu e, nimic nu e... - Numa unu, efu, blgui cu ultimele puteri Miu. Un om, mcar dou sptmni, ct poa s coste?! - Mi Miule, tii poanta cu pictura de benzin? Miu ddu din cap a netiin. Hai c iar i-a luat aerul sftos, urmeaz o lecie, 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 aa c ddu doar din mn a lehamite i continu: - Cic se duce unu la benzinrie i l ntreab pe cel de la pomp: Ct cost o pictur de benzin? Fugi de-aici, domle, nu cost nimic, e zero lei, rspunde acesta. Super, f-mi i mie plinul, pictur cu pictur... Aa i tu Miule, nu e mare lucru o resurs, dar una azi, alte dou mine...
simona.bonghez@confucius.ro Speaker, trainer i consultant n managementul proiectelor, Owner al Confucius Consulting
50
sponsori
powered by

Today Software Magazine N11/2013

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Today Software Magazine N11/2013

Încărcat de

Drepturi de autor:

Formate disponibile

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

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

6 S uitm de modelul Silicon Valley

28 OPTIONSABILITY - O caracteristic discret a proiectelor IT

31 Dezvoltarea de aplicaii safety-critical n SCADE

8 (un) prieten pentru startup-uri

34 Trenduri i Big Data

10 JAVA EE7. Cloud, Web 2.0+

39 Programare Funcional n Haskell

11 Istoria IT-ului Clujean (V) - nvturi din Junimea

40 Recenzia crii: RESTful Web Services Cookbook de Subbu Allamaraju

42 SPRE COMUNITATEA IT via HR

16 Din buctria arhitectului software - carduri de scenarii

19 Arhitectura extransibil i durabil

47 Poate da ... poate nu ...

48 Roller Coaster-ul Imagine Cup

24 Orchestrarea Testrii Automate

50 Gogu i plinul de benzin

Ovidiu Man, PMP

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

Fondator i CEO al Today Software Magazine

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