[Title will be auto-generated]

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

No. 14 • August 2013 • www.todaysoftmag.ro • www.todaysoftmag.com

M AG A Z I N E

Load Test folosind Windows AzureScurtă introducere în mediul SAPProvocările unui business analyst în Agile

Project Manager și Business Analyst - un duet care poate face diferența în

outsourcingul românesc

ITC Spring 2013 (II)

Cum invata un artizan software: deliberate practice

Team building (II)

Conferința Romanian Testing Community 2013

Haskell (IV)

IEEE Congress on EvolutionaryComputation, 2013, Cancun

Migrare website MVC 3 și DB în Azure (III)

Istoria IT-ului clujean: Ford și Șincai

WPF – cum stăm cu performanța? Startup Transilvania

6ICT SPRING

EUROPE 2013 (II)Ovidiu Mățan

9Istoria IT-ului

Marius Mornea

10Conferința

Romanian Testing Community

2013Marius Mornea

11Startup

TransilvaniaCristian Dascălu

12Despre finaliștii Romanian

Startup AwardsBogdan Iordache

15Aplicații pentru previziuni

financiare la IEEE Congres on Evolutionary

Computation, 2013, CancunSilvia Răușanu

18Cum învață un artizan soft-

ware: deliberate practiceAlexandru Bolboaca și Adrian Bolboacă

21Scurtă introducere

în mediul SAPVictor Ionescu

23WPF – cum stăm cu

performanța?Daniel Lăcătuș

27Team building (II)Andreea Pârvu

29Provocările unui business analyst în AgileMonica Petraru

32Project Manager și Business Analyst - un duet care poate face diferența în outsourcin-gul românesc Adrian Cighi

34Recenzia cărții: Android Apps with Eclipse de Onur CinarSilviu Dumitrescu

36Load Test folosind Windows Azure Radu Vunvulea

39Programare Funcțională în Haskell (IV)Mihai Maruseac

41Migrare website MVC 3 și DB în Azure (III)Dragoș Andronic

43Design pattern-ulMVVMAndrei Moldovan

45Complicat sau complexSimona Bonghez

4 nr. 14/August, 2013 | www.todaysoftmag.ro

Vremea vacanțelor a început, o parte am fost norocoși și ne-am luat deja concedi-ile așa că putem să ne reluăm plini de elan lucrul la birou. Revenim la proiectele noastre, și sigur aveți o idee despre un produs nou ce ar putea să ne facă viața

mai ușoară, cum ar fi o mică pompă solară care să umfle colacele și bărcuțele copiilor. Vă sugerez să nu abandonați aceste idei și să vă gândiți serios cum s-ar putea realiza. Se întâmplă uneori să avem o idee foarte bună de produs pe care să o vedem în câțiva ani implementată cu succes, din păcate de către altcineva. Este paradoxal faptul că în România avem un grad ridicat de ingeniozitate, că suntem buni în execuția proiectelor, lucru demonstrat prin întreaga industrie de IT orientată spre outsourcing, dar în același timp avem un număr relativ mic de startup-uri, succesul acestora se lăsându-se așteptat. Presupun că în timp toate acestea se vor schimba, iar șansa de succes a noilor veniți este mult mai mare acum față de condițiile de la începutul lui 2000. Trip Hawkins, spunea în cadrul ICT Spring Europe 2013 că inovația trece în fața branding-ului. Industria cu cel mai mare impact în momentul de față este cea mobile iar în cadrul acesteia jocurile împreună cu social media ocupă cel mai mare spațiu în device-urile utilizatorilor. Mai mult, dacă ne uităm la procentul jocurilor indie față de cele produse de marile companii, acestea dominau în prima parte a 2012 cu 68% pentru platformele ios și android. Dacă ar trebui să pornesc un startup astăzi, aș considera și crearea unui joc. Există exemple de succes autohtone pe piața locală, iar suportul acestora pentru noi veniți nu ar trebui să fie o problemă.

Rămânem în sfera indie, iar cea mai mare platformă de finanțare crowdsourcing, dis-ponibilă și din România este IndieGoGo.com. Este cea mai bună modalitate de a valida faptul că prototipul vostru va avea cu adevărat un impact global și de a obține o finanțare.

Proiecte din ce în ce mai mari își găsesc finanțarea în acest mod iar un exemplu recent este Ubuntu Edge, un proiect ce urmărește crearea primului telefon high-end al celor de la Ubuntu. Ținta lor pentru obținerea a 32,000,000$ într-o lună va reprezenta un adevărat succes în ceea ce privește finanțarea crowdsourcing. Nu puteam vorbi despre crowdso-urcing fără a menționa și două platforme locale: multifinantare.ro și crestemidei.ro ce reprezentă o alternativă bună atunci când vorbim de proiecte cu impact național.

În acest număr TSM puteți citi o serie de articole tehnice dintre care enumăr câteva titluri: WPF – cum stăm cu performanța?, Design pattern-ul MVVM. De asemenea se continuă seriile în numerele trecute despre Programare Funcțională în Haskell și Migrare website MVC 3 și DB în Azure. O noutate constă în prezența a două articole, Provocările unui business analyst în Agile și Project Manager și Business Analyst care pun accentul pe rolul unui business analyst-ului în echipă și interacțiunea cu aceasta. Load Test folosind Windows Azure ne propune o modalitate simplă de a realiza un load test sau stress test. SAP reprezintă un domeniu de interes și ne face plăcere să publicăm un prim articol de introducere în SAP. La final, Gogu ne propune să învățăm diferența dintre complicat și complex.

Vă dorim o lectură plăcută !!!

Ovidiu MăţanFondator și CEO al Today Software Magazine

Ovidiu Măţan, [email protected]

Editor-in-chief Today Software Magazine

editorial

5www.todaysoftmag.ro | nr. 14/August, 2013

TODAY SOFTWARE MAGAZINE



Redacţia Today Software Magazine

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

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

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

Copyright/Corector: Emilia Toma [email protected]

Traducător: Roxana [email protected]

Reviewer: Tavi Bolog [email protected]

Reviewer: Adrian Lupei [email protected]

Produs de Today Software Solutions SRL

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

www.todaysoftmag.rowww.facebook.com/todaysoftmag

twitter.com/todaysoftmag

ISSN 2284 – 6352

Copyright Today Software Magazine

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

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

www.todaysoftmag.rowww.todaysoftmag.com

Silviu [email protected]

Consultant Java@ msg systems Romania

Radu [email protected]

Senior Software Engineer@iQuest

Lista autorilor

Alexandru [email protected]

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

Mihai [email protected]

IxNovation @ IXIAmembru ROSEdu, ARIA

Adrian [email protected]

Programmer. Organizational and Technical Trainer and Coach@Mozaic Works

Andreea Pâ[email protected]

Recruiter în cadrul Endava

Simona Bonghez, [email protected]

Speaker, trainer şi consultant în managementul proiectelor,

Owner al Colors in Projects

Bogdan [email protected]

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

Dragoș Andronic [email protected]

CTO@ TXTFeedback

Silvia Ră[email protected]

Software Developer@ ISDC

Victor Ionescu [email protected]

SAP IT Consultant @ msg systems Romania

Daniel Lăcătuș[email protected]

Senior Software Developer@ Accesa

Monica Petraru [email protected]

Senior Business Analyst @ UNIQA Raiffeisen Software Service


Project Manager@ Yonder

Andrei [email protected]

Software Developer@ Business Logic Systems Ltd.

Cristian Dască[email protected]

Cofondator @ Cluj Hub

Marius [email protected]

Inginer interesat şi implicat în diverse activități IT, de la dezvoltare, management, până la educație şi jurnalistică în cadrul Epistemio, UTCN şi TSM


ICT SPRING EUROPE 2013 (II)

evenimente

A doua zi a evenimentului a debutat cu prezentarea lui Jimmy Walles, fondatorul Wikipedia a cărui temă a fost Democrație și internet. Am reținut invitația la un exercițiu de imaginație care sintetizează filozofia Wikipedia: „Imaginați-vă o lume unde fiecare persoană are liber acces la toate cunoștiințelor omenirii”.

Un lucru distractiv, relatat de fondatorul Wikipedia, se referă la China unde au apărut denumiri de mâncăruri ce conțin cuvântul Wikipedia. Nimeni nu a știut inițial cum au apărut, dar s-a dove-dit că în urma căutărilor unor termeni în limba engleză folosind Google, rezultatul începea de multe ori cu cuvântul Wikipedia. Aceasta se întâmpla, deoarece înainte de Olimpiada din Beijing, toate restaurantele își traduceau meniurile în limba engleza. Astfel dacă se căuta, cum se numește această ciupercă în engleză rezulta-tul căutării, începea cu: Wikipedia.

Un aspect interesant menționat de fondatorul Wikipedia este legat de diferențele observate la nivelul țărilor sau comunităților în ceea ce privește tipul sau cantitatea de informație accesate. Astfel

aceleași categorii de articole și statistici legate de accesul la aces-tea. Apar totuși diferențe în popularitatea acestora cum ar fi pop culture in Japonia sau faptul că germanii sunt cei mai curioși în geografie !!!

Revenind la statistici, Wikipedia are până acum 490.000.000 vizitatori unici și bazat pe estimările lor, se va ajunge la 500.000.000 înainte de finalul anului.

Cine scrie în Wikipedia? 87% sunt bărbați din cauză că Wikipedia este destul de tehnică. Se încearcă să se îmbunătățească interfața de editare a articolelor astfel încât să fie mult mai ușor să se editeze un articol. Există un mare număr de doctoranzi printre cei ce scriu articole. Fondurile pentru Wikipedia vin de la fundația Wikimedia, marea majoritate a sumei primite fiind de la publicul larg.

Cum funcționează Wikipedia ? • Wikipedia este o enciclopedie. • NPDV – Wikipedia nu judeca deciziile, • Free licensing – respectarea copyright-ului. Tot conținutul a

fost generat de către colaboratorii Wikipedia. • IAR – no firm rules. Nu se fac lucrurile doar pentru că există

o regulă

Jimmy Wales a continuat cu prezentarea a câtorva cazuri reale în ceea ce priveste folosirea internet-ului în țări cu un nivel mai scăzut de trai. De exemplu în Nigeria, deși este o țară în Africa unde accesul la internet era scăzut, iar lățimea de bandă alocată era foart mică în 2002, tot acest handicap a fost eliminat, iar acum topul celor mai folosite site-uri este similar cu cel de pe alte con-tinente: Google, Facebook, Twitter, Wikipedia, ziare locale. Tot acest proces este mult mai rapid decât și-a închipuit multă lume.

Dacă ne gândim cum va fi lumea peste 20 de ani, remarcăm

În acest articol continuăm relatările de la ICT Spring Europe unde împreună cu colegul meu Marius Mornea am avut plăcerea să participăm. A fost prima delegație TSM în afara țării și am avut ocazia să ne conectăm la pulsul lumii de IT din Europa. Viitorul arată bine și nu m-ar surprinde ca în viitor să asistăm la o redefinire a importanței bătrânului continent în dezvoltarea aplicațiilor

de mâine.



conectivitatea mare la Internet pentru mii de milioane de oameni care nu vor vorbi engleză sau franceză.

Următorul subiect abordat a fost proiectul Wikia. Scopul acestui proiect este să ajute pe toată lumea să își creeze o librărie personală. Utilizitatorii pot să își creeze librăriile lor, nu neapărat academice. Au fost date câteva exemple precum cea a serialul Lost sau Lostpedia, un alt serial unde producătorii l-au folosit pentru a deschide un canal de comunicare cu fanii. Practic oricine își

poate crea wiki-ul său. Vă sugerez să accesați acest site, nu foarte cunoscut. Am găsit multe proiecte interesante precum Logopedia, o enciclopedie ce conține 24.434 de logo-uri de companii.

Trip Hawkins , un alt prezentator care a atras atenția, este lider în Hall of Hame-ul industriei de jocuri. Fondator al Electronics Arts, a jucat un rol important în definirea industriei PC la nivel global. Este de asemenea co-fondator al companiei You Can, care produce jocuri educaționale și oferă consultanță pentru jocuri și companiilor IT precum Kixeye, NativeX sau Extreme Reality 3D. Și-a petrecut întreaga carieră ca pionier al industriei PC-urilor inițial alături de fondatorii Apple, când compania sa nu avea mai mulți de 25 de angajați.

Prezentarea din cadrul ICT Spring care s-a numit “Digital disruption du Jour” a urmărit canibalizarea pieței de jocuri PC de către social networking și de către dispozitivele mobile, antici-pându-se posibila evoluție a acesteia. Apelând la o terminologie originală, gamerii înrăiți care se joacă pe console au fost denumiți balene, iar ce-i care se joacă jocuri sociale: delfini. Asistăm conform

celor spuse de Trip Hawkins la o transformare a balenelor în del-fini. Performanța jocurilor a fost înlocuită de comoditatea rulării acestora pe tablete sau telefoane. De asemenea, dexteritatea nece-sară jocurilor a trecut pe un loc secund față de cumpărarea unor bunuri virtuale. Acestea pot fi schimbate între jucători iar evoluția acestora să le transforme beneficii reale. Ce cumpărăm de fapt? Cumpărăm timp, item-urile primite în schimb ne ajută să trecem mai repede la următorul nivel.

Un punct interesant atins în această prezentare vizează educația. Se anticipează schimbări ale modului în care copii învață în sala de clasă. Copiii de mâine, vor fi dependenți de dispozitivele mobile iar modul de predare va trebui schimbat printr-o folosire mai largă a jocurilor, gamifications, în clase.

Revenind la partea de disruption, s-a făcut o comparație edi-ficatoare în ceea ce privește modul de distribuție a jocurilor. Dacă acum 10 ani, era foarte important modul în care un joc poate ajunge la utilizatorul final în cât mai multe regiuni geografice, acum toate acestea au dispărut, fiind înlocuite de magazinele virtuale de jocuri cum ar fi Apple Store. Descoperirea jocurilor va câștiga în fața distribuției, iar originalitatea va câștiga în fața brand-ului. Conform prezentării lui Trip Hawkins, puțină lume anticipă aceste aspecte. Avantajele față de competiție pot fi create în timp considerându-se:

• originalitatea IP (Intellectual Property),• cultura inovației,• folosirea avantajului date de framework-uri precum:

NativeX, Unity, Extreme Reality 3D.

O încercare de sintetizare a întregii prezentări “Digital disrup-tion du Jour”poate fi materializată în următoarele idei:

1. Trăim într-o era a comodității.2. Ținta trebuie să fie delfinii - jucători ai jocurilor integrate în

social media.3. Aplicațiile de astăzi vor rula mâine în browsere.4. Învățarea foarte bună a gestionării bunurilor virtuale.

Următorul panel a fost Gamification now: how Games are impacting the global Social and Business landscapes ce i-a avut ca invitați pe:

Trip Hawkins - Fondator al Electronic Arts - CEO, Digital Chocolate

www.3pillarglobal.com

3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world.

Our core competencies include:

ProductStrategy

ProductDevelopment

ProductSupport

Our offerings are business focused, they drive real, tangible value.



startups

David Gardner - Co-fondator & General Partner, London Venture Partners

Raphael Goumot - Fondator, CREAgile (moderator)Boris Pfeiffer - Managing Director, Kabam EuropeVolker Hirsch - Global Head of Business Development –

Games, BlackBerry

Relatez principalele idei postate pe contul nostru de Twitter (@todaysoftmag) în timpul desfășurării panel-ului:

- Angry Birds a avut un succes mai mare decât Mickey Mouse;- Japonia este locul de învățat deoarece sunt pionieri în multe

domenii;- Jocurile înseamnă stimulare iar noi nu suntem legume.

Creșterea activității cerebrale se poate face prin jocuri;- Conceptul de gamification este natural și a făcut întotdeauna

parte din viața noastră;- Viitorul jocurilor sunt cele ce durează 30 de secunde, poate 1

minut, chiar și în cazul celor complexe;- În concluzie, jocurile trebuie să fie distractive, dacă nu vor

fi vor rata aspectul de gamification. Caracterele pozitive câștigă întotdeauna.

Încheiem aici relatarea evenimentului. Vom publica în curând și un scurt film realizat din cadrul acestuia. Mulțumim încă odata organizatorilor, Céline TARRAUBE și Kamel AMROUNE pentru invitația la eveniment și oportunitatea de a distribui revista TSM în cadrul acestuia.





Istoria IT-ului clujean: Ford şi Șincai

istorie

Începem cu Henry Ford, responsabil de invenția linei de asamblare, dar mai ales a câtorva politici de HR revoluționare pen-tru perioada în care au apărut. Practic, ca orice om de afaceri, a încercat să crească productivitatea apelând la îmbunătățiri, în primul rând la procesul de fabricație. Într-o industrie nouă (Ford a înființat compania în 1906, la 17 ani de la patentarea motorului pe benzină de către Karl Benz), Ford a opti-mizat timpul de producere a unei mașini de la 12 ore jumătate la o oră și 33 de minute, prin invenția liniei de asamblare mobilă și a conceptului de producție de masă.

Deși aceste inovații i-au permis să crească de la o producție anuală de 18.000 unități, la peste un milion, în doar 10 ani, efectul asupra angajaților a fost unul dezas-truos, rata de demisii fiind foarte mare. Accelerată și de creșterea ponderii proce-selor automate, care scădeau și mai mult cererea de personal. Demisiile constante au crescut foarte mult costurile de angajare, au introdus întârzieri cauzate de cursuri de pregătire și au atins limita de resurse umane a pieței destul de repede.

Soluția a fost simplă, în 1914, Ford a dublat salariul de la 2,5$ la 5$ pe zi, a scăzut cu o oră ziua de lucru la 8 ore și a introdus conceptul de profit-sharing, prin care angajații puteau să își cumpere pro-pria mașină în 4 luni de muncă. În același timp a modificat radical strategiile de angajare, concentrându-se pe achiziția de talente, noile salarii i-au permis să aleagă cei mai buni mecanici din piață. Deși opi-nia publică internațională, de la sindicate la aristocrația europeană, a fost șocată de această abordare și au inventat termenul de „fordism” pentru a descrie strategia de producție de masă, motivată de consume-rism și salarii mult peste media din piață, strategia a dat roade și demisiile au scăzut, productivitatea a crescut, iar costul per mașină a scăzut la nivelul la care cei ce pro-duceau mașinile au devenit și piața țintă. În

scurt timp Ford producea 50% din automo-bilele din SUA, 40% din UK și din 200 de competitori, doar 17 au făcut față strategiei lui Ford.

Acest model de succes bazat pe opti-mizarea eficienței și loializarea talentelor printr-un pachet salarial atractiv, a fost considerat responsabil pentru crearea unei noi clase sociale și a transformat industria auto dintr-o nișă specializată într-una de masă. Problema este că pe termen lung a dus la falimentul celor care nu au adoptat modelul, și la o segregare mai mare a cla-selor sociale în raport cu veniturile. Prin urmare, să arunci cu bani în angajați este o soluție de moment și limitată ca eficiență pe termen lung. Acest lucru poate fi obser-vat și în piața IT locală.

Gheorghe Șincai a ales o altă abor-dare. Reprezentant al Scolii Ardelene, se confrunta cu problema recunoașterii drep-turilor poporului român în Transilvania și a fost unul dintre responsabilii emancipării naționale prin înființarea învățământului românesc. Practic burghezia română tran-silvăneană încearcă la 1791 să capitalizeze pe ultimul deceniu, în care a obținut acces la educație, atât înaltă (Roma și Viena), cât și înființarea de școli locale, prin mișcări politice (vezi eforturile lui Ioan Bob și Inocențiu Micu-Klein, de obținere a drep-turilor în schimbul unirii bisericilor cu Roma) sau revolte (vezi efectele răscoalei lui Horea, Cloșca și Crișan), și să obțină drepturi egale cu celelalte trei națiuni, prin memoriul Supplex Libellus Valachorum.

Citând din Wikipedia: „ izolată prin refuzul rezolvării memorandumului, prea slabă economic și politic pentru a iniția o mișcare revoluționară, burghezia română se concentrează într-o mișcare de emancipare națională pe plan cultural. Se înființează numeroase școli cu pre-dare în limba română ( Gheorghe Șincai1 înființează 300 de școli ), se tipăresc

1 http://ro.wikipedia.org/wiki/Gheorghe_Șincai

calendare, catehisme, manuale, cărți de popularizare a științei, cărți populare pen-tru pătrunderea informației în masele populare largi;”

Așadar, Șincai a ales emanciparea prin educația de masă. A luat ceva ce era apa-najul burgheziei și l-a formalizat într-o formă accesibilă maselor, prin elaborarea de manuale fundamentale: Abecedarul, Gramatica, Aritmetica și Catehismul. Această mișcare iluministă va avea ca efect acumularea unei mase critice de intelectuali români ce vor contribui activ la Revoluția de la 1848 și la drumul spre independența românilor din Transilvania.

Eu prefer această abordare, datorită efectelor pozitive pe termen lung asupra întregii populații și privesc admirativ o mână de oameni care au reușit, în condițiile cele mai aspre, să înființeze 300 de școli și să educe un popor întreg. IT-ul clujean are atât resursele, cât și condiții infinit mai pro-pice de a se implica în schimbarea calității educației la nivel de masă și să își rezolve pe termen mediu și lung problema resurselor umane.

Am ales două nume din istorie, pentru a încerca să ofer o soluție unei probleme foarte actuale în IT-ul clujean. Problema discrepanței între cererea mare și oferta scăzută de resurse umane.





eveniment

Exemplul cel mai elocvent este Scott Barber, care a ajuns la conferință total întâmplător (era în zonă, avea o pauză de 2-3 zile între contracte și a trimis un mail comunităților din zonă, oferindu-se voluntar), dar oferea constat feedback, atât în timpul seminariilor, cât și după, atât participanților, dar mai ales vorbitorilor. Tot el mi-a mărturisit ca se bucură de alege-rea făcută, deoarece atmosfera și interesul participanților pentru conținut, plasează conferințele din Cluj în topul lui personal, devansând marile conferințe internaționale supraaglomerate de marketing și vânzători.

Am profitat și noi de această atmosferă deschisă a vorbitorilor și am pus câteva întrebări pentru cititorii noștri:

1. Care ar fi top trei conferințe internaționale care nu trebuie ratate?

2. Numiți top trei surse de informare în domeniul QA.

3. Dintre toate uneltele din rutina zilnică, numiți top trei ca utilizare/uti-litate și, în cazul în care aveți, una mai puțin cunoscută, dar esențială.

4. Care ar fi următoarea paradigmă în testarea software?

Scott Barber1. E x i s t ă

două t ipur i de conferințe:

a. c e l e m a r i , d o m i n a t e d e prezentări ale pro-

duselor noi, orientate mai degrabă pe networking și vânzări. De exemplu: CAST (Conference of the Association for Software Testing) – care va avea loc în August în U.S.A.; sau Let’s Test – care are loc anual în Suedia în mai și în Australia în august și septembrie.

b. cele mici, cu acces bazat doar pe

invitație și un topic foarte bine definit, cu scopul de a rezolva o problemă spe-cifică din testare. Pe acestea din urmă le recomand cu cea mai mare căl-dură. De exemplu: WOPR (Workshop on Performance and Reliability) sau DEWT (Dutch Exploratory Workshop on Testing).2. Blogul AST (Association for Software

Testing) este o foarte bună sursă agregată de informații.

3. MindMap, Lucidchart, Jing și Skype. O unealtă subestimată ar fi SmartDraw.

4. Aproape toate conferințele sunt pline de discuții despre alinierea testării cu obiectivele de business (ex. profitabilita-tea). Eu o numesc Latura de Business a Testării (The Business Side of Testing) și este principala preocupare la nivel înalt a comunității de testări.

Gabor Torok1. G o o g l e

Testing Conference, Selenium Conference, DevOps Day Europe.

2. G ojko – Acceptance TDD – newsletter săptămânal; Google Testing blog.

3. Emacs (cod), Twist (teste), Jenkins, HipChat (Atlassian).

4. NoQa team – evoluția spre elimina-rea distincției între rolul de programator și tester, prin mutarea diferențelor în unelte și procese automatizate.

Stephen Blower1. Te s t B a s h –

Brighton (atmosfera prietenoasă și eveni-mente pre-conferință f o a r t e u t i l e ) ; EuroSTAR; STARWest & STAREast.

2. Oamenii sunt o sursă esențială

de informaț ie : Michael B olton , Miagi-Do blog. Cărțile și interacțiunea d i r e c t ă : m e e t u p s , g a t h e r i n g s (SheffieldTestGathering).

3. Jira, Confluence, TestRail, Twitter. Unealta cea mai importantă și totuși cea mai subestimată este creierul. Eu îl folo-sesc zilnic!

4. TDD + schimbul de informații între diferite roluri în echipele de dezvoltare.

Brîndușa Axon1. ALE – Agile

Lean Europe, Agile Testing Days, Let’s Test, Agile Testing Meetup, Zappers – Meetup.

2. S o f t w a r e Testing Club (ministryoftesting.com), Gojko.net, Michael Bolton, Seth Godin.

3. Mindmap, LeanCanvas, JMeter. Indirect legat de testare Competing Values Framework.

4. Evoluția de la dezvoltarea bazată pe proces la procese axate pe relații între coechipieri cu responsabilități diferite.

Sperăm că și la anul vom fi răsfățați cu același volum mare de conținut de calitate, poate chiar mai mult, în aceeași atmosferă relaxată de familie.

Conferința anuală organizată de RTC (Romanian Testing Community) a crescut de la ediția precedentă la capitolul cel mai important: conținut. De la trei prezentatori la zece, de la o zi cu trei seminarii la două zile, una cu două serii-uri paralele, a câte patru seminarii, și una dedicată celor două sesiuni practice ținute de Paul Gerrard și Andy Harding. Practic anul acesta același

număr de participanți au primit de cinci ori mai mult conținut. Iar schimbul de informații nu s-a limitat la sesiunile de prezentări. Punctul forte al conferinței a fost atmosfera familială și interactivitatea prezentatorilor. În fiecare pauză puteai să ii angajezi în discuții, care de multe ori se lungeau într-o sesiune privată până la următoarea pauză.

Conferința Romanian Testing Community 2013




TODAY SOFTWARE MAGAZINE startup

Probabil că multe companii de soft și-au stabilit o strategie de dezvoltare pe 5-10 ani în avans. Dacă în această strate-gie e inclusă și crearea de produse proprii atunci acest articol cred că va fi de interes.

Vineri, 19 iulie 2013, s-a lansat la Cluj-Napoca programul pentru startup-uri STEP UP. Scopul acestui program este să ajute startup-urile să meargă rapid și lean de la idee la prototip. Să transforme un set de resurse (input): idee, oameni și timp (3 luni) într-un rezultat (output): MVP - pro-totip al produsului propriu. MVP-ul sau minimum viable product-ul este de dorit și foarte posibil să fie atins în 3 luni de zile.

STEP-Up vizeaza să:• Asigure sprijin și continuitate

antreprenorilor după participarea la eve-nimente și competiții start-up.• Aducă mentori și resurse care

să susț ină dezvoltarea echipelor antreprenoriale.• Dezvolte legături financiare pen-

tru start-up-urile din Transilvania cu alte centre și comunități din Europa și America.• Adu c ă l o c a l ” k now - how ” u l

i nte r naț i ona l î n c onst r u i re a ș i poziționarea pe piețe regionale și globale.

Programul STEP-Up include 3 luni de muncă susținută și relevantă asistată, sesiuni de studiu săptămânale cu men-torii și partenerii programului, serii de seminarii cu anteprenori de succes, eveni-mente sociale lunare cu liderii din business din comunitate, interacţiuni frecvente cu fondatorii companiilor și echipele de management, dar și provocări de a învăţa de la persoană la persoană.

Noi am selectat cei mai buni mentori locali și internaţionali, cele mai avantajoase beneficii marginale și am creat legăturile cu cele mai bune reţele de profesioniști din industrie.

Dintre mentorii din cadrul programu-lui STEP UP îi menționăm:

Philipp Kandal - CTO & founder Skobbler,

Dragoș Roua - investitor și antreprenor român,

Kate Lowes - CEO la UK Innovation Group.

Lista completă de mentori este disponibilă pe site-ul programului startuptransilvania.ro

Programul începe la sfârșitul lunii august și se va încheia în noiembrie cu o zi de prezentare în care startup-urile vor arăta rezultatul muncii lor în cadrul unui demo day. Încurajăm companiile locale de soft să participe cu startup-urile interne și să facă un pas semnificativ spre propriile afaceri.

Tot mai mult se vorbește despre nevoia companiilor de soft din România de a trece de la outsourcing la dezvoltarea propriilor produse. Nu se știe cât timp serviciile companiilor de soft locale vor mai fi alese în detrimentul altor companii. Momentan ne avantajează un preț scăzut și o calitate crescută pentru servicii de soft.

Startup Transilvania

Cristian Dască[email protected]

Cofondator @ Cluj Hub


startups

Despre finaliştii Romanian Startup Awards

Despre startupuri si co-fondatorii nominalizati

123ContactForm – fondat acum 5 ani, 123ContactForm a trecut de la cenușăreasa la prințesa în ultimii doi ani. După ce echipa originală (Tudor Bastea și Florin Cornianu) a fost completată cu Adrian Gheară ca investitor, 123ContactForm și-a schimbat interfața, și-a îmbunătățit mone-tizarea și și-a crescut în permanență echipa pânăla 10 “canguri”.

5minutes.to – fondat de Cătălin Zorzini și Iulia David, 5minutes.to a făcut parte din batch-ul de primăvara al Springboard 2012. Interfața ușor de utili-zat i-a adus două nominalizari, pentru cea mai buna aplicație web și cea mai bună experiență de utilizare.

Appscend – finaliști în 2011 la How to Web / Startup Challenge, Sebastian Văduva și echipa au crescut afacerea liniar, an de an. 2012 a părut a fi un an în care și-au propus să scaleze vânzarile, blogul și PR-ul fiind hiper-active. Către finalul anu-lui, startupul a fost acceptat în programul Startup Chile și și-au extins vânzarile către America Latină.

CleverTaxi – lansat în a doua jumă-tate a anului în parteneriat cu Orange, CleverTaxi facilitează comandarea taxiu-lui cu ajutorul telefonului mobil. În ciuda unor mici turbulențe imediat după lansare, CleverTaxi a reușit să creasca (pe o piațaă relativ aglomerată), extinzându-se și in Cluj. Startupul îl are ca angel investor (și uneori programator sef) pe Andrei Pitiș.

Erepublik – 012 a fost un an fără mari știri din partea Erepublik, cu excepția ple-cării co-fondatorului George Lemnaru, ce lucrează de zor la noul său proiect GreenHorseGames. Așteptăm lansarea noii versiuni a Erepublik pentru 2013.

GoodMomming – Pornit de doi antreprenori moldoveni super-activi, GoodMomming a fost lansat în 2012, a vizitat TechCrunch Disrupt, apoi a fost finalist și Runner-up la How to Web 2012 / Startup Spotlight și, spre finalul anului, a fost acceptat la acceleratorul GrowLab. Un an plin de evenimente pozitive, sperăm ca 2013 să fie și mai și.

DocTrackr – deși nu este un startup 100% românesc, DockTrackr, co-fondat de Alex Negrea, a atras atenția datorită investiției primite după absolvirea accelera-torului TechStars Boston – $2M USD de la câteva dintre cele mai importante fonduri de capital din domeniul tech. Îi urăm lui Alex să cheltuie cu grija banii în 2013.

i-Rewind – fondat de Bogdan Manoiu dupa How to Web 2011 (stiți celebrul email cu subiectul “Felicitari – ești bunic !”) si cu Andrei Pitiș (din nou) în rol de business angel / co-fondator a fost lansat în 2012 pe pârtia de la Predeal, în parteneriat cu Orange. Conceptul inovator (i-Rewind te filmează în timp ce cobori pe pârtie și îți face ad-hoc un film personalizat) și echipa experimentată, condusă de entuziastul Bogdan Manoiu, îi face să fie unele dintre cele mai interesante startupuri de urmărit în 2013.

KeenSkim – Încă un one-man-show, KeenSkim este dezvoltat de Tudor Vlad și a absolvit ( Magna cum Laude, aș spune) ediția de vară a Eleven, unul dintre cele două acceleratoare din țara vecină și prie-tenă, Bulgaria. Proiectul a progresat mult în termeni de tehnologie și produs, partea de business mai are timp să crească. Felicitări lui Tudor Vlad, care a prins finala How to Web 2012 / Startup Spotlight, apoi a câștigat Best Pitch la Venture Connect în toamnă, un antreprenor ce își îmbunătățește vizibil abilitățile de business.

Maven hut / S ol i t a i re Aren a – Mavenhut au avut un an plin: au absolvit Startupbootcamp Dublin (am dat și noi o mână de ajutor), a câștigat Best Pitch la How to Web 2012 / Startup Spotlight și au primit o finanțare de €550k de la SOS Ventures, cea mai mare primă rundă de finanțare primită de la Braininent încoace. E greu de crezut, dar acum un an echipa condusă de Bobby Voicu de-abia se forma. Cu siguranță, Mavenhut sunt unul dintre principalii pretendenți la titlul de startupul anului.

RealColors – Echipa Makan Studios a lansat în primăvara o primă aplicație, numită RealColors, ce a fost ulterior pre-zentată de Friday App Review ( emisiune a Android Developers) ca Staff Pick of the Week. Momentan, echipa își pregătește următoarea aplicație și marele come-back în 2013.

Sl i ckF l i ck – fond at de Mar i a Constantinescu, SlickFlick și-a stabilit car-tierul general la Timișoara după o primă

După cum probabil știțti, TheNextWeb premiază cele mai importante startupuri, antreprenori și investitori locali. Pe lista celor 12 se află și România, evenimentul din București fiind co-organizat de Geekcelerator. Voi face în continuare o scurtă analiză a celor nominalizați.



runda de investiții de la mai mulți business angels din UK. Echipa include co-fondatorii NextRoot, firmă ce a dezvoltat Instamap, așadar o echipă experimentată și foarte interesantă.

Tjobs – firma mureșană a avut în 2012 un an liniștit, având ca repere participarea la mai multe competitii de startupuri unde s-au clasat onorabil in finala (Dublin Web Summit, Pioneers Festival, Europas). Tjobs pare foarte interesat de construirea unei imagini in afara Romaniei, dorind probabil să se extindă la nivel internațional. Efortul a fost condus de Andreas Cser, business ange- lul care are un mare merit în ambițiile crescânde ale Tjobs.

Zonga – Începutul anului a adus lansarea Zonga, un serviciu de muzică românesc. Ca utilizator de Zonga sunt foarte încân-tat de experiența din aplicație (cu câteva mici excepții) și admir tenacitatea lui Sergiu Biriș, mai cunoscut de la Trilulilu.ro, care a reușit să aducă la aceeași masă o serie de companii importante din industria muzicii. Later edit: Zonga a făcut apoi un parteneriat interesant de distrbutie cu Vodafone.

Zyway – Zyway este singurul proiect despre care nu știu să vă spun nimic. Proprietate a firmei ieșene ThinSlices, Zyway este încă în faza de lansare.

Despre investitoriDin lista celor 5 investitori propuși pentru a fi votati, unul sin-

gur a fost activ în 2012 și acela este Andrei Pitiș. Ultimele investiții ale lui Vlad Stan și Victor Anastasiu ( prin Seedmoney ) au avut loc în noiembrie 2010 ( Squeeqly ) și vara lui 2011 ( SkinScan ), ultima investiție a lui Andreas Cser este Tjobs ( 2010 ) și ultima investiție a lui Adrian Gheară este 123ContactForm ( 2011 ).

Despre cei neselectatiSummify – Mircea Pasoi și Cristian Strat au avut un început de

an spectaculos, odată cu vânzarea Summify către Twitter. Cifrele tranzacției nu au fost făcute publice, însă chiar și un acqui-hire sună spectaculos în peisajul lipsit de vești al achizițiilor startupu-rilor românesti.

uberVU – Angajarea unui CEO american, două birouri de vânzari deschise în USA și America Latină, o nouă versiune ori-entată către entreprise, acestea au fost cele mai importante repere ale echipei Ubervu, care acum a ajuns la un total de peste 50 de angajați.

Brainient –în 2012 Brainient a ridicat o runda de finantare de $1.8M pentru a-și scala operațiunile de vânzare și a deschis birouri în SUA.

Peter Barta – Discret în legătură cu investițiile sale, Peter a adăugat pe lângă Appscend ( unde este investitor din 2011) și Traderion ( în 2012 ) și teoretic mai există încă 1-2 investiții pe care nu le cunoaștem.

Disclaimer: sunt prieten/amic cu majoritatea celor menționati în acest post, dar nu am nicio legătura financiară cu niciunul dintre ei.

De finalRomanian Startup Awards au generat un val de interes extraor-

dinar, și pare a fi un moment foarte bun de întâlnire a comunității locale, cu toate că este vorba de o competiție de tip Eurovision, unde publicul își votează favoriții din motive ce nu au neaparată legătură cu rezultatele obținute în ultimul an.

Am văzut grupuri de Facebook care iși îndemnau membrii să voteze fondatorii / startupurile / investitorii dintr-o anumită locație geografică (eterna luptă contra Bucureștiului, deh), o adevarată campanie de presa dusă de Mavenhut, și chiar câteva posturi dezinformatoare și trunchiate care analizau startupurile și indicau către favoriții autorului, plus suspiciuni de fraudă ().

Una peste alta, Romanian Startup Awards ramâne un exercițiu interesant și util de promovare a startupurilor românești, sperăm să fie și cât mai relevant.

Bogdan [email protected]

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



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

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

Romanian Testing CommunityComunitate dedicata testerilor.Website: http://www.romaniatesting.roData înfiinţării: 10.05.2011 / Nr. Membri: 626 / Nr. Evenimente: 2

GeekMeet RomâniaComunitate dedicată tehnologiilor web.Website: http://geekmeet.ro/Data înfiinţării: 10.06.2006 / Nr. Membri: 278 / Nr. Evenimente: 17

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

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

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

Romanian Association for Better SoftwareComunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.Website: http://www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 226/ Nr. Evenimente: 12

Tabăra de testareUn proiect care își dorește să strângă cât mai mulți oameni care lucrează ca și testeri.Website: http://tabaradetestare.roData înfiinţării: 15.01.2012 / Nr. Membri: 227/ Nr. Evenimente: 19

Am crezut că nu vor fi suficiente evenimente pentru rubrica de calendar în luna August, dar am avut parte de o surpriză plăcută. Începem seria de evenimente din această lună cu lansarea numărului 14 TSM care va avea loc la sediul msg systems din Cluj-Napoca și unde vom avea parte de un mini-summer party la finalul prezentărilor. Un eveniment important ce va avea loc în

București la finalul lunii august este Agile Learning Europe (ALE) 2013, acesta reprezintă și recomandarea TSM pentru luna august.

Calendar August 5Lansarea numărului 14 TSM (Cluj)www.todaysoftmag.ro

August 7Summer evening on a terrace (Cluj)w w w . m e e t u p . c o m / Ta b a r a - d e - Te s t a r e - C l u j /events/127909542/

August 7Building Startup Communities it-events.ro/events/building-startup-communities-with-brad-feld-and-anca-albu/

August 9International Coworking Day (Cluj)it-events.ro/events/international-coworking-day/

August 17Open Space on Technology in Startups (București)it-events.ro/events/open-space-on-technology-in-startups/

August 18-19Școala de vară – Informatica la Castel (Macea, Arad)it-events.ro/events/scoala-de-vara-informatica-la-castel/

August 19-24Moodle Moot România 2013 (Brașov)it-events.ro/events/oracle-summer-school-2nd-edition/

August 23-25SummerHacks (Timișoara)it-events.ro/events/summerhacks/

August 28-30ALE 2013 (București) - recomandarea TSMale2013.alenetwork.eu

August 29Linked Data Technology Stack (Cluj)www.meetup.com/Cluj-Semantic-WEB/events/115920132/

Joi/săptămânalOpenConnect (Cluj)www.facebook.com/groups/355893314491424/

Miercuri/bilunarOpenCoffee (Cluj)www.facebook.com/opencoffeecluj

Comunităţi IT

comunități


TODAY SOFTWARE MAGAZINE eveniment

Peste 200 de cercetători, profesori, doc-toranzi, cu preponderență din America si Asia, au luat parte la eveniment, pentru a-și prezenta rezultatele, dar și pentru a beneficia de șansa unică de a schimba idei și a începe noi colaborări cu nume celebre din domeniu. Lumea companiilor IT a fost reprezentată aproape imperceptibil, eu fiind proabil sin-gura reprezentantă a industriei – mediul academic conduce detașat în domeniul des-coperirilor prin tehnici si metode specifice IT-ului, fără suportul companiilor de profil, din nefericire.

Subiectele funcționale abordate la conferință acoperă o gamă foarte variată: biochimie, biologie, medicină, economie, teoria jocurilor, meteorologie, etc. Aplicațiile algoritmilor evolutivi reușesc sa îmbrace experimentele de hibridizare și optimizare a unor metode cunoscute în așteptarea unor descoperiri importante sau, pur și simplu, a unui software performant ce ar micșora numarul erorilor umane ca urmare a interpretărilor – de exemplu, aflarea tipu-lui unei tumori prin analiza unei radiografii. Posedând cunoștințe de bază despre calculul evolutiv, asistarea la prezentările de la CEC aduce noi perspective asupra domeniului, dar și deschide apetitul de cercetare orientată pe aplicabilitate.

Aplicații financiare folosing calcul evolutivAplicațiile financiare din cadrul CEC au

fost orientate în mod exclusiv pe domeniul previzunilor acțiunilor la bursă. Chiar de la începutul prezentărilor, autorii recunoșteau hazardul abordării unei asemenea tema-tici, datorat scepticismului multora asupra existenței unui tipar în fluctuațiile finan-ciare, sau unei linii fine între legalitate și ilegalitate. Ipoteza pieței eficiente (Efficient Market Hypothesis - EMH) încurajează scepticii, susținând că informația este ime-diat disponibilă tuturor participanților, iar prețurile acțiunilor reflectă instant starea curentă a pieței. EMH presupune ca toți participanții la bursă pot obține același câștig, indiferent de experiența lor în dome-niu deoarece prețurile sunt complet aleatorii. Makiel, în „The Efficient Market Hypothesis and Its Critics”, explică cum EMH respinge utilitatea analizei tehnice sau fundamentale – metode de bază încorporate în aplicațiile de acest tip cu o rată de succes ce reușește să aducă îndoială asupra validității EMH. În ultimul timp, investitorii folosesc în mod independent analiza fundamentală, folosind indici macroenomici, cursul valutar, sau analiza tehnică, folosind prețul acțiunilor și volumul tranzacțiilor. Analiza tehnică pe date istorice ale bursei este utilizată în

Ediția 2013 a congresului IEEE Evolutionary Computation (CEC) s-a desfășurat in Mexic, Cancun – un decor cel puțin exotic pentru noi, europenii. Pe lânga locația atrăgătoare, merită precizat și faptul că CEC este una dintre cele mai mari și impor-

tante conferințe, având ca subiect principal calculul evolutiv – dând astfel cel putin două motive pentru participarea la eveniment entuziaștilor metodelor de calcul evolutiv, printre care mă număr și eu.

Aplicații pentru previziuni financiare la

IEEE Congres on Evolutionary

Computation, 2013, Cancun

Silvia Ră[email protected]

Software Developer@ ISDC


evenimentAplicații pentru previziuni financiare la IEEE Congres on Evolutionary Computation

aplicațiile prezentate la CEC 2013, ele diferențiindu-se prin algoritmi de optimi-zare folosiți – programare genetică, căutare tabu. Metodele de optimizare din lucrarile ce fac scopul acestui articol funcționează pe structuri interne, dar toate țintesc spre a răspunde utilizatorului dacă un pachet de acțiuni merită cumpărat sau vândut și ce profit îi va aduce această operațiune.

Previziuni financiare folosind progra-mare genetică

Kampouridis et all. în „Metaheuristics Application on a Financial Forecasting Problem” propune hibridizări peste firul principal al algoritmului unei aplicații ajunse deja la versiunea 8, EDDIE (ED), ce a făcut obiectul cercetării lui pentru mai mulți ani. ED are la bază o versiune a programării genetice ce încearcă să gene-reze strategii optime de tranzacționare. Algoritmul folosește ca date de intrare valorile analizei tehnice aplicate asupra datelor istorice (prețul zilnic de închidere și indici tranzactionali), valorile efective ale prețului pe o perioada delimitată și rezul-tatul clasificării istorice ( 1 – decizia de cumpărare, 0 – decizia de a nu cumpăra).

Indicii analizei tehnice folosiți sunt: „media în mișcare” (MA), „trade break out” (TBR), „filtru” (FLR), „volatilitate” (Vol), „momentum” (Mom), și „media în mișcare pe momentum” (MomMA). Valorile indi-cilor implicați în algoritm sunt calculate pentru un anumit număr de zile, pe termen scurt și pe terment lung. În ED7 valorile de calculare a indicatorilor tehnici erau fixe, 12, respectiv, 50 de zile – aceste perioade fiind preluate direct din modul cotidian de lucru al analiștilor economici. Structura de optimizat a algoritmului este un arbore genetic de decizie constrâns de gramatica următoare:

<arbore> ::= if-then-else <condiție> <arbore> <arbore> | <decizie><condiție> ::= <condiție> “AND” <condiție> | <condiție> “OR” <condiție> | “NOT” <condiție> | <variabilă> <operator relațional> <prag><variabilă> ::= MA12 | MA50 | TBR12 | TBR50 | FLR12 | FLR50 | Vol12 | Vol50 | Mom12 | Mom12 | MomMA12 | MomMA12<operator relațional> ::= < | > | =<prag> ::= numar rațional<decizie> ::= 0 | 1

Un arbore descris de gramatica anteri-oară reprezintă o soluție pentru o decizie tranzacțională pentru un pachet specific de acțiuni. Un set de astfel de decizii este evaluat prin calcularea proporțiilor între deciziile corecte și cele greșite, cu dife-rite ponderi – eroarea într-o decizie de cumpărare având cea mai mare pondere. Algoritmul genetic din ED7 generează arbori dintr-un spațiu de căutare limitat de perioada fixă de aplicare a indicilor tehnici; însă cu ED8 perioadele devin variabile,

deschizând astfel spațiu de căutare și evi-tând o convergență prea rapidă. Rezultatele ED8 au fost raportate a fi promițătoare, dar eficiența căutării a scăzut, de aceea, pentru a menține diversitatea soluțiilor, dar în același timp, pentru a recupera eficiența căutării, meta-euristici de cău-tare au fost implicate în algoritm pentru a optimiza caracteristici punctuale are arbo-rilor: variabilele ce descriu noile perioade de calculare a indicilor tehnici. Simulated annealing (SA) este un algoritm ce permite alegerea unei soluții mai puțin bune cu o anumită probabilitate (pentru evitarea găsirii unui optim local); în ED8, SA se aplică nodurilor limitrofe ale unor arbori aleatorii din populație, modificând peri-oada cu o valoare din intervalul [-10, +10]. Căutarea tabu (TS) este o meta-euristică ce forțează căutarea unei soluții mai bune să nu se întoarcă la soluții vizitate creând din acestea o lista tabu cu o existență limitată; în ED8, TS se aplică în același mod ca SA.

Această aplicație a fost testată față de 10 seturi de date obținute prin finance.yahoo.com. Dacă ED8 era capabil sa ofere în medie o rată a corectitudinii de 0.5735 pentru 10 seturi de date, și pentru cele mai bune soluții 0.75, ED8-SA întoarce 0.5773 pentru aceleași date, iar cea mai bună soluție 0.81; ED8-TS întoarce 0.5591, iar cea mai bună soluție 0.81. Din rezulta-tele tocmai enunțate, îmbunătățirea nu e remarcabilă la nivel de medie, însă inves-titorii care ar folosi aplicația cu siguranță vor cauta cea mai bună soluție, astfel noi hibrizi devin eficace.



Previziuni financiare folosind căutarea tabu

Kuo et all. în „Dynamic Stock Trading System based on Quantum-Inspired Tabu Search Algorithm” vine cu un sistem dina-mic ce e capabil să genereze într-un context real strategii complete – vânzare și cum-părare. Algoritmul de bază al aplicației, o formă nouă pentru căutarea tabu, având concepte împrumutate din fizica cuan-tică, a fost dezvoltat de aceeași echipă. Ideea algoritmului este de a asigna fiecărei soluții posibile o matrice cuantică, fiecare caracteristică a soluției având o valoare din intervalul [0,1] – probabilitatea cuan-tică. Căutarea tabu se traduce în acest context prin actualizarea matricilor tutu-ror soluțiilor prin scăderea ponderilor din matrici pentru caracteristicile din cea mai slabă soluție, respectiv, prin creșterea pon-derilor pentru caracteristicile din cea mai bună soluție. Dinamismul aplicației este dat prin aplicarea conceptului de fereastra

glisantă (sliding window) – seturile de date de antrenament de la o iterație la alta se modfică, în același timp cu seturile de test. Din teoria economică, se aleg din nou indici de analiză tehnică, cu perioade fixe de aplicabilitate per indice. Alegerea unor indici reprezintă o strategie de cumpărare/vânzare, o soluție. O soluție este apreciată prin estimarea profitului în valută și număr de acțiuni. Evaluarea sistemului s-a făcut pe date istorice, în comparație cu alte soluții propuse în trecut. Simulările prezentate în lucrare raportează pentru unele seturi de date un profit maxim de 69.94%, față de doar aproximativ 14% pentru alte imple-mentări pe aceleași date.

Concluzii și alte impresiiCele două aplicații descrise anterior

sunt comparabile doar la nivel de domeniu de aplicabilitate, întrucât prima dintre ele oferă doar un mecanism de suport al deci-ziilor investitorilor, iar cea de-a doua, un

software complex și independent. La nive-lul implementării, cele două se aseamănă prin utilizarea indicilor de analiză tehnică ca suport decizional. Din punct de vedere algoritmic, cele două propuneri suferă la capitolul de dimensionare a spațiului de căutare – Kampouridis îl extinde foarte mult, iar Kuo, aș putea spune, îl ține foarte bine controlat (deși autorii nu intra în deta-lii). Aceste comparații sunt făcute doar cu scopul de a indica diversitatea abordărilor ce poate rezulta în soluții performante, nu ca o recenzie a acestor lucrări foarte apre-ciate de audiență la CEC.

Ca notă de final, de inspirație lirică, par-ticiparea la CEC 2013 a fost o experiență unică prin numărul mare de idei și metode noi prezentate, prin numărul mare de participanți doritori de discuții și dezbateri la nivel algoritmic, prin organizarea demnă de invidiat a organizatorilor, și prin tot exo-ticul oferit de locația conferinței. Asemenea conferințe se organizează anual – următoa-rea ediție CEC 2014 va fi în Beijing, China. Așadar, cercetați!


programare

Modul prin care mișcarea software craf-tsmanship crede că un dezvoltator poate să devină atât de rapid este prin a practica cât mai des, în contexte cât mai diferite, pe platforme și limbaje cât mai diferite. Astfel deliberate practice este foarte strâns legat de orice dezvoltator care se numește “aspiring software craftsman” sau “software craftsman”.

Ce este practica?Practica este un act de repetare a unui

comportament sau de implicare repetitivă într-o activitate în scopul de a se îmbunătăți sau de a o stăpâni, ca în fraza “prin practică devine perfectă” (eng „practice makes per-fect”. Echipele de sport practică pentru a se pregăti pentru jocuri concrete. A cânta la un instrument necesită foarte multă practică. Este o metodă de învățare și de dobândire de experiență. Cuvântul derivă din greces-cul „πρακτική” (praktike), femininul lui „πρακτικός” (praktikos), „pregătit pentru sau realizează o acțiune, practic” și din ver-bul „πράσσω” (prasso),”a dobândi, a înfăptui, efect, realizare”. (Ref http://en.wikipedia.org/wiki/Practice_%28learning_method%29)

Există nenumărate asemănări între sport, muzică și programare. Performanța pe teren, pe scenă sau în producție este un factor esențial pentru succes în aceste domenii. Dar la fel cum un sportiv sau un muzician are nevoie de practică pentru a deveni expert în momentul în care acti-veaza, la fel și un dezvoltator software are nevoie de practică pentru a stăpâni tot mai bine domeniul său.

Problema esențială în industria software este că, spre deosebire de sport sau muzică, un dezvoltator îsi petrece o

proporție prea mare din timp “pe scenă” și prea puțin timp într-un mediu de învățare. Iar aceasta se întâmplă într-un domeniu foarte dinamic, unde schimbarea și nouta-tea este la ordinea zilei. Atunci un aspiring software craftsman trebuie să își aloce timp pentru a se perfecționa. Acesta poate face o investiție, iar în loc să lucreze efectiv 40 de ore pe săptămână, lucrează doar 30, iar restul de timp și-l dedică practicii. Altă opțiune este să aloce timp seara și/sau dimineața în fiecare zi precum și zilele de sâmbată și/sau duminică pentru a învăța lucruri noi.

Dar cum să practicăm? Ei, bine, există un număr de formate consacrate de delibe-rate practice, dar în cele ce urmează ne vom concentra pe următoarele: Coding Kata, Performing Coding Kata, Coding Dojo, Cyber Dojo, Testing Dojo, Coderetreat, Te s t Au tom at i on R e t re at , Pa i r-programming, Pet projects, Coaching.

Coding KataConceptul acestui tip de de practică

este foarte simplu: aflu unde vreau să mă perfecționez și vreau să practic într-un interval scurt de 10 minute – o oră o activi-tate care mă va ajuta să fiu mai bun. Această idee vine tot din artele marțiale, unde un învățăcel trebuie să repete anumite mișcări până este mulțumit de progres și poate să îi arate sensei-ului cum a progresat. Pentru dezvoltatori se aplică același model: acesta repetă rezolvarea aceleiași probleme, în același mod, pentru aceeași perioadă de timp până când consideră că rezolvarea, dar și etapele ei, sunt unele corecte într-un timp foarte scurt.

Un artizan software dorește să prac-tice minim 10 ore pe săptămână, pentru

Mișcarea software craftsmanship promovează ideea că singurul mod în care un dezvoltator poate fi rapid este prin a se comporta rațional în perioade de criză. Această gândire este o reacție la comportamentul de a scrie cod greu de modi-

ficat și de înțeles, practic de a produce datorie tehnică (eng. Technical debt), în momentul în care trebuie să livrezi software într-o perioadă scurtă de timp.

Cum învață un artizan software:

deliberate practice

Alexandru [email protected]

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


Programmer. Organizational and Technical Trainer and Coach@Mozaic Works



că acesta este singura modalitate prin care poate să fie mai rapid și mai eficient.

Tu cât de mult exersezi pe săptămână?

Performing Coding KataUn prezentator scrie cod în fața unei

audiențe pe o tematică prestabilită și într-un interval de timp prestabilit. Acesta trebuie să explice audienței ce face în timp ce progresează. Audiența este rugată să nu intervină decât în cazul în care chiar nu înțeleg ce se întâmplă. Acest gen de exercițiu este foarte intens pentru pre-zentator și poate fi foarte educativ pentru audiență, pentru că cei din audiență pot să învețe lucruri noi văzând cum un coleg de breaslă rezolvă o problemă.

Știu că ai vrea să faci un coding kata. Când il faci?

Coding DojoEste un format ce provine din artele

marțiale și este adaptat pentru dezvolta-tori. Coding dojo este un exercițiu de grup cu scopul de a transmite cunoștințe între participanți. Este propusă o tematica și o perioadă de timp în care grupul va încerca să rezolve o problemă, exersând anumite practici.

O caracteristică esențială a acestui for-mat este ca el să aiba un timp prestabilit de desfășurare și o tematică foarte specifică. O persoană experimentată facilitează această întâlnire, concentrându-se ca regulile să fie aplicate, timpul să fie respectat și scopul convenit al exercițiului să fie păstrat.

Coding dojo randori. Este forma cea mai răspândită, în care doi programatori scriu cod folosind un proiector pentru ca toată lumea să poată vedea. Ei folosesc pair-programming, iar primul care a înce-put sesiunea este înlocuit la un interval de timp (în jur de 5-7 minute), de următorul programator din sală. Perechea celui care pleacă începe să scrie cod, iar cel nou-venit doar observă. După același interval de timp cel care scrie cod se retrage și este înlocuit din nou cu cineva din sală. Se poate face o listă în avans, pentru ca să se știe de fiecare dată cine va fi la rând. Astfel, prin rotație, toată lumea va scrie cod și va vedea cum scriu cod ceilalți.

O variație este ca atunci când cineva din sală are ceva de spus trebuie să meargă la tastatură și să vorbeasca. Astfel nimeni din sală nu are voie să vorbească, decât atunci când scrie cod pe proiector.

Coding dojo mai are o variație: o per-soană foarte experimentată face un coding

kata cu un scop bine nefinit și cu o durată de timp prestabilită (20-30 minute). Apoi audiența este rugată să repete pașii realizați de prezentator. În etapa a doua, în care audiența repetă pașii inițiali, prezentatorul se transformă în facilitator, asigurându-se că scopul exercițiului este păstrat și că regu-lile sunt respectate. Acest format este mult mai aproape de ceea ce se întâmplă când un sensei vrea să arate clasei cum trebuie să realizeze anumite mișcări și apoi îi pune să repete dându-le sugestii continue de îmbunătățire.

Ai aflat unde și când e următorul coding dojo la tine în oraș?

Cyber DojoCyber dojo este o aplicație online cre-

ată de Jon Jagger pe principiile coding dojo. Aceasta permite conectarea în paralel a mai multor persoane sau grupuri, sau accesa-rea individuală a unui server. În aplicația online se poate scrie cod în majoritatea lim-bajelor curente. Aceasta conține un număr destul de mare de probleme care pot să fie rezolvate. Avantajul cyber dojo este ușurința și rapiditatea utilizării. Nu este nevoie de nicio setare pentru un mediu de dezvoltare.

După ce termini de citit acest articol începi să-l folosești, nu? Iată link-ul: http://www.cyber-dojo.com.

Testing DojoDupă ce coding dojo a devenit foarte

popular între programatori, aceleași prin-cipii au fost aplicate pentru ca și testerii să poată învăța unii de la ceilalți. Pentru mai multe detalii accesați http://www.

testingdojo.org.

Ce mai aștepți să participi la un testing dojo?

CoderetreatÎn anul 2009 un grup de programatori

s-au întâlnit la conferința Code Mash în SUA și s-au gândit că ar vrea să aibă un for-mat de o zi întreagă pentru a exersa, spre deosebire de formatul uzual al coding dojo de câteva ore.

Ideea unui code retreat este de a com-bina mai multe din elementele dintr-un coding dojo sau coding kata într-o singură zi de exersare. Code retreat-urile au loc de obicei sâmbăta și durează toată ziua. Evenimentul este structurat în 6 sesiuni de 45 de minute, separate de retrospec-tive scurte. Regulile sunt simple: în cadrul fiecărei sesiuni, programatorii lucrează în pereche cu scopul de a scrie cod cu anumite constrângeri impuse de facilitator și care facilitează învățarea. După fiecare sesiune, codul scris este șters complet, perechile și constrângerile se schimbă și scrisul de cod reîncepe.

România a fost de la bun început foarte activă în acest domeniu, Alexandru Bolboacă și Maria Diaconu fiind doi dintre cei care au ajutat la cristalizarea formatului actual. De asemenea coderetreat-uri sunt organizate în mod uzual în comunitățile AgileWorks din România.

În fiecare an este organizată “Global Day of Coderetreat”, când orașe din întreaga lume sunt invitate să participe la un eve-niment cu același format. Timp de 32 de ore programatori de pe toate continentele învață să devină mai buni prin practică.



Multe dintre orașe comunică prin video conferințe pentru a se cunoaște și pentru a împărtăși învățăturile din acea zi.

Când este următorul coderetreat? Răspunsul este aici: http://coderetreat.org!

Test Automation RetreatUrmând formatul unui coderetreat,

Makus Gärtner a creat această variație unde testerii sunt invitați să participe la 6 sesiuni de 45 de minute pentru a automa-tiza teste pentru o aplicație web. Formatul este încă nou și proaspăt, dar foarte valo-ros. (Ref http://www.shino.de/2012/04/28/coderetreat-goes-testautomation)

Când participi la următorul test auto-mation retreat?

Pair-programmingAceasta este o formă foarte simplă de

practică. Vrei să faci ceva și chemi pe altci-neva să te ajute pentru că încă un punct de vedere este binevenit.

Din experiență putem spune că pair-programming este cea mai rapidă modalitate de învățare. Ai nevoie doar de un alt profesionist care să aiba același interes ca tine. Apoi lucrând împreună amandoi veți învăța foarte multe unul de la celălalt. Este de asemenea și obositor, deci încercați să nu exagerați, dar devine mai ușor de acceptat pe măsură ce crește exeperiența cu această practică.

Pair-programming poate fi făcut chiar și remote.

Tu când ai făcut pair-programming ultima dată?

Pet projectsO modalitate foarte bună de a exersa

este un proiect personal. Orice tehnologie și orice tematică este bienvenită cu o sin-gură condiție: să fii foarte pasionat de ceea ce faci. Un proiect personal ajută pentru că este un mediu real de dezvoltare, dar deci-ziile nu sunt luate de un client sau de un șef, ci chiar de tine. Astfel poți să înveți să iei decizii de arhitectură, de design. Cât de bine este să ai codul curat și alte practici uzuale din lumea artizanilor software.

A începe un proiect personal este foarte simplu. Oricare dintre noi are o idee pe care ar vrea s-o exploreze scriind un program. Așa că trebuie doar să ne alocăm puțin timp pentru a o pune în operă. Adesea se întamplă ca un proiect personal să se trans-forme într-un produs vandabil.

Tu cât timp lucrezi pe luna la proiectul tău personal?

CoachingOrice formă de deliberate practice poate

fi realizată de unul singur, sau sprijinit de un coach tehnic. Când este implicat și un coach tehnic procesul de învățare este accelerat puternic, pentru că feedback-ul continuu și sugestiile concrete, chiar lucrul în sesiuni de pair-programming, sunt facto-rii determinanți pentru o învățare eficientă. Această relație se aseamănă cu relația din-tre învățăcel și sensei în artele marțiale. Oricine poate învăța arte marțiale din cărți, sau de la practicanți puțin experimentați, dar un sensei ajută cu sfaturi pentru a avea un proces rapid și coerent de învățare.

Tu când ai lucrat cu un coach tehnic

ultima dată?

ComunitateParticiparea într-o comunitate de

profesioniști din domeniul de activitate este un alt factor care ajută la îmbunătățirea continuă. Aici puteți cunoaște oameni cu aceleași pasiuni, cu nivele diverse de cunoștințe, dar care au un scop comun: să învețe unii de la ceilalți. Există comunități de programatori, testeri, arhitecți în toate orașele mari din România și din Europa. De asemenea există comunități care se ocupă de un limbaj specific sau o tehnologie spe-cifică, în cazul în care scopul învățării este o tehnologie în sine.

Major itatea evenimentelor din comunitățile locale sunt gratis, acesta fiind un factor în plus pentru a atrage cât mai mulți oameni pasionați din lumea IT și nu numai.

Comunitățile Software Craftsmanship (AgileWorks în România) se concentrează mai curând pe lucrurile fundamentale pe care profesioniștii din lumea software ar trebui să le stăpânească. Membrii acestora au specializări, vârstă sau experiență foarte diverse.

Dacă nu știi deja care sunt comunitățile din orașul tău, dă o căutare pe internet sau pe meetup.com!

ConcluzieUn expert separă abilitățile care sunt

necesare pentru a fi un expert și se concen-trează pe îmbunătățirea acelor abilități în timpul practicii zilnice, adesea prin pairing și ajutat îndeaproape de feedback-ul unui coach. Un alt factor important al deliberate practice stă în practicarea continuă a unei abilități la niveluri tot mai provocatoare cu intenția de a o stăpâni. (Ref Mayer, R. E. (2008). Learning and Instruction. Upper Saddle River, New Jersey: Pearson Education, Inc)

Un lucru este clar, fără practică nu putem deveni experți într-un domeniu atât de vast și dinamic precum industria software. Astfel vă invităm să începeți să practicați acasă sau la serviciu. Iar apoi vă invităm să vă implicați în comunitatea locală prin activități de practică în group. Ce mai așteptați?

Cum învață un artizan software: deliberate practiceprogramare



Astfel, în acest articol ne propunem să analizăm câteva detalii ale produselor respectiv tehnologiei SAP, încercând să răspundem la unele întrebări precum: Ce este SAP de fapt? Care este specificul pro-duselor SAP? Ce anume este “deosebit” la tehnologia SAP și ce presupune dezvoltarea software în acest domeniu?

Soluţii şi clienţi SAPSAP este provider-ul de „enterprise

business software” numărul 1 la nivel glo-bal, având peste 230000 de clienţi și un portofoliu ce acoperă întreg spectrul de produse, de la soluţii enterprise tipice pre-cum Financial/Accounting, HR, Customer Relationship Management și până la unele foarte specifice, așa numitele „Focused Business Solutions”.

O problemă interesantă ar fi cu sigu-ranţă identificarea motivelor pentru care un număr atât de mare de clienţi enterprise aleg SAP. Desigur acestea sunt diverse, ceea ce se spune însă de multe ori, este că cel mai bun promotor al unei soluţii informatice îl reprezintă portofoliul de clienţi și poveștile de succes ale acestora, sau cu alte cuvinte: implementarea unei soluţii IT care reu-șește să eficientizeze procesele de business ale unei companii, reprezintă o dovadă a

calităţii software-ului, fiind adesea și un factor care determină concurenţa din ace-eași branșă să aleagă la rândul ei această soluţie.

Și în cazul soluţiilor SAP, acestă afir-maţie este cât se poate de valabilă, cu atât mai mult cu cât portofoliul SAP cuprinde în exclusivitate soluţii informatice dezvol-tate nu pentru un anumit client, ci pentru o întreagă branșă. În terminologie SAP (dar nu numai) aceste produse sunt numite soluţii „standard“.

Mai mult decât atât, implementarea unei soluţii informatice consacrate în cadrul unui enterprise, spre deosebire de dezvoltarea uneia noi (“from scratch”), poate avea un impact pozitiv și asupra imaginii companiei respective, putând influenţa până și ratingul primit de aceasta ca urmare a unui audit.

Provocări întâlnite în dezvoltarea unei soluţii standard

Având în vedere abordarea SAP, de a nu deservi un anumit client ci mai degrabă o întreagă industrie prin produsele sale, în cele ce urmează vom analiza care sunt pro-vocările de care se lovește un dezvoltator software atunci când urmărește implemen-tarea unei noi soluţii standard, și mai ales

După ce în urma publicării ultimelor articole pe teme SAP ni s-a sugerat din partea cititorilor că o scurtă introducere în mediul SAP ar fi foarte bine venită, am hotărât să urmăm acest sfat inițiind o serie de articole cu scopul de a oferi o

vedere de ansamblu asupra aspectelor care ţin de specificul SAP.

Scurtă introducere în mediul SAP

programare

Victor Ionescu [email protected]

SAP IT Consultant @ msg systems Romania


care este aportul pe care îl aduce platforma tehnică SAP în vederea soluţionării acestor provocări.

Din punct de vedere al funcţionalităţii pe care o va pune la dispoziţie, softul stan-dard trebuie proiectat astfel încât să suporte toate procesele de business tipice ale bran-șei, în același timp făcând însă abstracţie de orice detaliu care este specific doar anumi-tor clienţi.

De aceea, faza de specificare funcţio-nală a noii soluţii standard implică adesea colectarea de informaţii de la clienţi mul-tipli din cadrul domeniului respectiv. Această activitate are ca scop final defini-rea produsului la un nivel de abstractizare suficient de înalt, astfel încât să fie posibilă implementarea acestuia la oricare client din acea branșă.

Prin urmare, specificarea funcţională a produsului reprezintă o activitate de o importanţă majoră, care necesită o foarte bună cunoaștere a business-ului, de ea depinzând în mare parte succesul ulterior al produsului.

Fazele de dezvoltare ale soluţiilor SAPDatorită faptului că o soluţie standard

nu poate fi specificată până în ultimul deta-liu astfel încât ea să poată fi achiziţionată “la cheie” de către un client, orice produs SAP va trece de-a lungul timpului prin două faze distincte: dezvoltarea soluţiei standard și adaptarea soluţiei standard explicit la cerinţele clientului (fază numită de obicei „implementarea” produsului la client)

Cele două faze reprezintă, din punct de vedere al dezvoltării software, două proiecte independente: proiecte de dezvol-tare standard și proiecte client (customer development projects). Prin urmare și un dezvoltator ABAP poate fi la rândul său implicat în două tipuri diferite de proiecte, fiecare având specificul său, astfel încât și skill-setul necesar pentru un dezvoltator ABAP diferă de la un tip de proiect la celă-lalt .

Aspecte tehniceDin punct de vedere tehnic, încă de

la design-time software-ul trebuie să fie proiectat în așa fel încât acesta să permită extinderea proceselor standard acolo unde este cazul, sau definirea acelor detalii care au fost prea specifice pentru a putea fi incluse în soluţia standard, de către fiecare client în parte.

Pentru a putea implementa cerinţele legate de flexibilitate și extensibilitate ale software-ului, e nevoie ca și platforma

tehnică pe baza căreia se dezvoltă noul produs să vină în ajutorul dezvoltatorului, punând la dispoziţia acestuia mecanisme care să facă posibilă implementarea unui produs nu pentru un client, ci pentru o întreagă industrie. Acest lucru este cât se poate de valabil în cazul soluţiilor SAP, platforma tehnică și mediul de dezvoltare fiind gândite de la bun început cu aceste ţeluri în minte.

În cele ce urmează vom prezenta suc-cint câteva din conceptele specifice SAP, care vin tocmai în întâmpinarea proble-melor ce ţin de flexibilitatea produselor standard.

EnhancementsDupă cum am menţionat deja, atunci

când se dezvoltă o soluţie standard, se vor ivi adesea situaţii în care un anumit proces nu poate fi definit în totalitate în cadrul soluţiei standard, fie pentru că anu-mite aspecte nu sunt cunoscute de la acel moment, fie pentru că acestea diferă de la client la client neexistând astfel o solu-ţie „standard” pentru acea situaţie. Astfel apare nevoia pentru un mecanism prin intermediul căruia clientul să aibă posi-bilitatea de a extinde comportamentul sistemului cu funcţionalităţi specifice pro-priului său business, funcţionalităţi care ar fi fost prea specifice pentru a fi incluse în soluţia standard.

În cazul tehnologiei SAP, un exemplu pentru un astfel de mecanism sunt așa numitele „Business Add-Ins”. Un Business Add-In (sau BadI) reprezintă un user exit cu o interfaţă predefinită, integrat în flow-ul soluţiei standard. Prin utilizarea de BadI-uri clientul are posibilitatea să își definească implementări proprii prin care să extindă comportamentul standard al sistemului, și mai mult de atât, să specifice condiţiile (numite de obicei „filtre”) pentru care o implementare să fie executată.

Astfel se oferă posibilitatea unui client să extindă un produs standard cu propria logică de business, aceasta fiind integrată și executată la un moment predefinit în cadrul procesului standard.

Utilizarea conceptului de Business Add-in implică întotdeauna două faze distincte:

• dezvoltatorul soluţiei standard defi-nește Business Add-inul ( interfaţa și filtrul acestuia ) și integrează apelul aces-tui “user exit” în flow-ul soluţiei standard.• fiecare client va avea posibilitatea de

a defini propriile implementări ale BadI-ului, și de a specifica în ce situaţii vor fi

folosite acestea.

În timp ce conceptul în sine ar putea fi implementat fără probleme și utilizând alte tehnologii, ceea ce e deosebit este faptul că limbajul ABAP vine cu un set de instrucţi-uni specifice pentru utilizarea BadI-urilor în aplicaţii ABAP, iar mediul de dezvol-tare SAP pune la dispoziţie tool-uri care ușurează activităţile ce ţin de gestionarea BadI-urilor: definirea BadI-ului, a interfeţei și a filtrelor, adăugarea de noi implementări

GET BADI lr_badi FILTERS iv_entity = lv_filter_value.

CALL BADI lr_badi->do_checks EXPORTING is_key = ls_key iv_lob_cd = lv_lob_cd CHANGING ct_msgtab = lt_msgtab

.

Exemplu de apel al unui Business Add-In.

Implementarea BadI-ului va fi determinată dinamic

la ru time, pe baza valorii filtrului lv_filter_value

Pe lângă Business Add-Ins, platforma SAP mai pune la dispoziţie și o serie de alte mecanisme (Program Exits, Screen Exits, Menu Exit, Business Transaction Events), toate acestea făcând posibilă dezvoltarea de soluţii standard SAP care mai apoi vor putea fi extinse cu ușurinţă de către fiecare client în parte.

CustomizingCustomizing-ul în terminologie SAP

se referă la activitatea prin care un produs SAP este personalizat pentru un anumit client prin ajustarea diverșilor parametri de sistem ai produsului. Customizing-ul este un pas obligatoriu în faza de implementare a unei soluţii SAP la un anumit client.

Figura 1 - Business Add-In: Definirea interfe-

ţei şi apelul BadI-ului în cadrul software-ului SAP

standard, şi adaugarea de implementări de către client

Scurtă introducere în mediul SAPprogramare



Procesul de customizare al unei soluţii SAP include o gamă variată de activităţi de nivele de complexitate diferită:

• începând de la o banală configurare a monedei și valorii TVA-ului folosit într-un anumit sistem

• la configurări de reguli de business de exemplu sub forma unor arbori de decizie, tabele de decizie, ș.a.m.d.

• și până la customizări de natură tehnică, prin care se poate controla în mod dinamic comportamentul sistemului la run-time, de exemplu după principiul de „Dependency injection”

ClientsConceptul de clienţi SAP permite separarea unui sistem SAP

într-o serie de subunităţi logice fiecare astfel de subunitate fiind numită un „client”.

În condiţiile în care adesea este nevoie ca mai multe subunităţi ale unei organizaţii să se folosească de aceeași soluţie SAP, exis-tenţa acestui concept permite reutilizarea aceleași infrastructuri hardware, astfel obţinându-se o diminuare a costurilor de insta-lare, configurare și întreţinere, ale soluţiei SAP.

Între clienţii unui sistem există posibilitatea de a face o sepa-rare atât la nivelul configurării customizării soluţiei SAP de pe sistemul respectiv, dar și a datelor propriu-zise. Astfel în cadrul unui enterprise, mai multe subunităţi pot folosi aceeași soluţie SAP, instalată pe un singur sistem fizic, dar care funcţionează dife-rit în funcţie de client, customizarea fiind specifică fiecărui client în parte. Mergând pe exemplul configurării TVA-ului, o companie multinaţională având filiale în mai multe ţări poate utiliza un sin-gur sistem SAP, asignând filialele din diverse ţări la clienţi diferiţi ai sistemului, pe fiecare client TVA-ul fiind configurat corespun-zător pentru fiecare ţară în parte.

Toate aceste aspecte, împreună cu alte mecanisme și tool-uri specifice SAP, ușurează în mod simţitor job-ul dezvoltatorilor, atunci când accentul în cadrul dezvoltării software se pune în special pe flexibilitatea și posibilitatea de extindere a soluţiei infor-matice implementate.

Enumerarea acestor aspecte nu a avut scopul de a fi una exha-ustivă, rolul ei fiind mai degrabă de a face o scurtă introducere în ceea ce poate fi considerat a fi “specificul SAP”. În articolele următoare, vom detalia acest subiect, prin abordarea altor aspecte ale dezvoltării software SAP, cu accent în special pe diferenţele faţă de alte limbaje și tehnologii.

Figura 2 - Configurare TVA la configurarea modulului SAP SD

Figura 3 - Configurarea unor reguli de business utili-

zând SAP BRF+(Business Rule Framework plus)

Figura 4 - Exemplu tipic de Dependency injection prin specificarea

implementării unei funcţionaliăţi în cadrul unui customizing SAP


Tentația atunci când apare ceva nou, e de a-l face soluția ideală pentru orice problemă. Există o discuție continuă când vine vorba despre alegerea unei tehnologii client Microsoft, dar dacă nu se benefici-ază de avantajele specifice aduse de WPF (data-binding, stilizarea dinamică, ser-viciile media, animații), din motive de performanță o mare parte din dezvoltatori încă aleg WinForms.

Lumea XAML și Binding-ul Modul declarativ a fost un succes în

mediul de dezvoltare web și aceasta a inspi-rat un nou limbaj, bazat pe XML, numit eXtensible Application Markup Language (XAML). XAML are multe avantaje , dar ce merită menționat e că scapă de codul pro-cedural și permite developer-ului sau chiar designer-ului, să descrie modul în care con-troalele arată și interacționează între ele.

View-ul în WPF conține un fișier XAML și unul de code-behind. Dacă e să urmăm pattern-ul MVVM și în design nu s-au facut compromisuri, în code-behind ar trebui să nu fie nimic mai mult decât ce e general automat iar legătura între datele din View și datele din ViewModel ar trebui realizata prin Binding.

Binding-ul este un mecanism puter-nic; el lansează notificările necesare

pentru schimbari în UI automat atunci când reprezentarea datelor din ViewModel se schimbă.

To Blend, or not to BlendÎn mod clar unul din avantajele pe care

le aduce WPF-ul e extensibilitatea când vine vorba de customizare. Fiind cu un pas în fata WinForms-ului dacă vorbim de design, WPF-ul oferă dezvoltatorilor foarte multe posibilități și tehnici să schimbe look and feel-ul controalelor, iar acest lucru stă la baza aplicațiilor rich client moderne cen-trate pe user și modul de interacționare cu el.

Microsoft vine in întâmpinarea lor cu un tool orientat spre design, care are pro-priul build engine și e capabil să creeze applicații WPF separat de Visual Studio. Expression Blend separă puțin rolurile, ofe-rind designerilor posibilitatea de a se focusa pe design, și programatorilor pe partea de cod (presentation logic sau back-end), con-ferind confortul de a nu se bloca unu pe celălalt.

În Blend aplicația e dezvoltată vizual, desenând pur și simplu forme, path-uri și controale pe planșa de lucru, ca mai apoi să fie descris modul de apariție și behavior.

În concluzie, dacă aplicația a fost aleasă să fie dezvoltată în WPF, este clar o nevoie

WPF – cum stăm cu performanța?

Când vine vorba de aplicații client în familia .Net, Windows Presentation Foundation e un nume care apare tot mai des. WPF nu mai e o noutate, el fiind introdus încă din .Net Framework 3.0 dar aduce avantaje pe partea de interfață

grafică care îl fac competitiv.

programare

Daniel Lăcătuș[email protected]

Senior Software Developer@ Accesa



de o interfață complexă, iar Blend aduce un mare ajutor pe această parte.

MVVMModel View ViewModel e un pattern

UI, creeat de Microsoft ca o specializare a pattern-ului Presentation Model (introdus de Martin Fowler). Bazat în mare pe MVC, MVVM se preteaza mediilor de dezvoltare unde platforma de UI suporta event-dri-ven programming, cum ar fi HTML, WPF, Silverlight.

Scopul acestui pattern e de a separa Interfața Grafică (fie ea markup sau cod) - View, de logica de business (backend) - Model. ViewModel-ul e responsabil să facă legătura între cele două, expunând datele din Model în așa fel încât să fie consumate de View, descriind în același timp logica.

MVVM a fost conceput să folosească data binding în WPF, pentru a facilita mai bine separarea de UI, renunțând în marea parte la code behind-ul din View. Avantajele sunt clar vizibile, și ar fi un pattern de urmat în orice aplicație dezvoltată în WPF.

Cu timpul, criticile nu întârzie să apară, iar una vine chiar de la John Gossman, inventatorul MVVM, care arată că aduce un overhead semnificativ dacă avem operații mari la nivel UI. Iar în cazul aplicațiilor mari cu UI complex, fine tuning-ul pe par-tea de View devine tot mai dificil de aplicat.

Controale 3rd party În WPF conceptul de controale stă

la baza structurii UI-ului, și sunt create pentru a obține interfața grafică dorită si ar putea fi refolosite. De-a lungul timpu-lui, au fost provideri care s-au consacrat, și

probabil impus la nivel mondial prin setul de controale de WPF pe care îl oferă.

Controalele 3rd party pot fi pe de o parte o mare provocare / oportunitate pentru cei care doresc să le implementeze, pe de alta parte un mare ajutor pentru o echipă care dorește să implementeze o soluție rapidă la o problemă.

Din nevoia de a nu reinventa roata, pare o opțiune viabilă să achiziționezi un set de controale existent, care a dovedit de-a lungul timpului că îți aduce soluția de care ai nevoie. Printre marii dezvoltatori de controale de WPF se numără Telerik, Infragistics, DevExpress, care oferă o suită destul de diversificată de controale. Nivelul de experiență la care s-a ajuns în dezvolta-rea acestor controale, e de multe ori greu de egalat, și probabil mult mai costisitor, iar prin aceasta persistă pe piața cam de când a aparut WPF-ul.

Una din tentațiile pe care le aduce setul de controale e suportul tehnic de care beneficiezi, contra cost, bineînțeles. Pe lângă documentația disponibilă abundent pe Internet, fiecare provider are un depart-ment tehnic și un mod prin care primești o lămurire la întrebările, nelămuririle și eventualele bug-uri legate de controale.

Dacă vorbim de aplicații industriale, performanța acestor controale este impor-tantă și ea, ele find în mare parte black-box pentru consumatori. Se observă o anumită îngreunare dacă vorbim de un UI consis-tent, iar aceasta poate deveni o problemă.

Poate cel mai “problematic” control din punct de vedere al performanței e DataGrid-ul. Aceasta și din cauză că ține multe date spre a fi afișate. Majoritatea

dezvoltatorilor de controale oferă căi pen-tru a face produsule lor performante. Ce ar trebui avut în vedere în acest sens:

• Virtualizarea: mare parte dintre controalele de grid sunt virtualizate, și dacă nu au un flag în acest sens ce trebuie setat (poate fi făcută pe Row/Column). Hint: nu puneți un DataGrid într-un ScrollViewer, practic pierdeți virtualizarea.• Paginarea: paginarea poate fi făcută

la nivel de UI, având toate datele deja încărcate, dar puteți încerca și un sistem de încărcare de date dinamic, paginat în funcție de View• Încărcarea asyncronă: pe binding

puteti folosi IsAsync = True, pentru că în acest caz încărcarea de date poate dura mai mult, și nu vreți să blocați UI-ul.

Performanța e unul din aspectele cheie ce trebuie avute în vedere când se alege un set de controale, pentru a nu avea o aplicație matură cu un UI bogat, dar așa de înceată încât nimeni nu ar lucra cu ea.

PerformanțaWPF-ul e cunoscut pentru avanta-

jele care de UI pe care le aduce, dar cum rămâne cu performanța? Am avut ocazia să lucrez pe mai multe proiecte WPF, din care două se remarcă pentru timpul de implementare lung și amploarea produsu-lui în sine, unde performanța era una din necesitățile proiectului.

WPF nu a fost creat să fie performant “by design”. Binding-ul e mecanismul care stă la baza WPF-ului, iar pentru realizarea fiecărui binding se ocupă memorie. Când se



ajunge la screen-uri complexe, cu multe controale, în care fiecare subparte e legată de un obiect de date, se observă că exista și un cost pentru toate avantajele sale.

O altă problemă apare la date ierarhice, când se schimbă data context-ul. Propagarea se face descendent pe toate nivelele, și refacerea binding-urilor necesită timp. Acest aspect poate deveni vizibil pentru utilizator, iar o alternativă nu e tot timpul la înde-mână. Din păcate, nu se mai vede un avans al Microsoft spre îmbunătățirea controalelor, dovada stă în faptul că cea mai bună îmbunătățire adusă în direcția aceasta în .Net Framework 4.5 e Virtualizarea la TreeView. Roadmap-ul pentru WPF nu poate fi confirmat decât în linii mari, așa că este neclar care e viitorul pe aceasta directie, ținând cont ca și Silverlight deși promițător la un moment dat, a fost brusc întrerupt.

Se întâlnește destul de des o paralelă între WPF și WinRT, și aceasta nu din motive nefondate. Amândouă au la bază XAML și un API asemănător, dar WinRT a fost gândit în manieră de performanță. A lăsat deoparte bagajul acumulat de WPF și are un API nativ în C++. Din C# (sau javascript) se apelează componen-tele native, iar acest lucru se simte în viteza de reacție.

În SDK-ul de Windows 7 se găsește o suită de programe de profiling, care dau posibilitatea de a analiza la run-time modul în care aplicațiile WPF se comportă și de a analiza ce optimizări se pot face pentru a spori performanța. În această suită se găsesc două componente care merită menționate.

Perforator - analizează modul în care se face rendering-ul aplicației. El afișează un set de grafice care dau posibilitatea de a analiza într-un mod foarte specific maniera în care se face ren-dering-ul fiecărei subpărți a unui screen si de a găsi eventualele probleme. Graficele oferite de Perforator constau în: analiza ratei de refresh, analiza schimbărilor intermediare care folosesc rende-ring-ul software, cel hardware și consumarea memoriei video.

Visual Profiler – prezintă problemele de performantă în contextul modului în care a fost construit layout-ul aplicatiei. Se parcurge ierarhia vizuală, și se vor întâlni obiecte high-level (cum ar fi butoane și TextBlock-uri) dar și cele low-level (cum sunt liniile și elipsele). În loc să descrie problemele de performanță arătând grafice, Visual Profiler descrie problemele folosind repre-zentarea visuală a obiectelor (într-un mod similar cu cel în care funcționează UISpy ).

Comunitatea de dezvoltatori software e tot mai mare, și aceasta duce la o competiție tot mai acerbă între soluțiile software oferite. Cred că până la urmă, totul se va reduce la performanță. Acest criteriu va face diferența între un software utilizabil la scara largă și unul utilizat doar pentru că nu există alternativă. Modul de răspuns a unui program dă factorul de satisfacție necesar, iar utilizatorul începe să fie educat și să ceară tot mai mult în aceasta direcție.

Referintehttp://en.wikipedia.org/wiki/Windows_Presentation_Foundationhttp://en.wikipedia.org/wiki/Model_View_ViewModelhttp://msdn.microsoft.com/en-us/library/cc296376.aspxhttp://msdn.microsoft.com/en-us/library/188ht7d8(v=vs.80).aspxhttp://en.wikipedia.org/wiki/Pareto_principlehttp://msdn.microsoft.com/en-us/library/system.windows.data.binding.isasync.aspx

WPF – cum stăm cu performanța?programare


TODAY SOFTWARE MAGAZINE HR

Din experiența mea de până acum, majoritatea team-building-urilor se orga-nizează în momentul în care apar situații conflictuale în cadrul echipelor. Team buil-ding-ul este văzut întotdeauna ca o soluție în depășirea problemelor, însă motivația care stă la baza deciziei de a implica mem-brii echipei într-un astfel de proiect, ar putea să fie:

• Încurajarea lucrului în echipă înainte de a ieși la iveală un conflict între mem-brii acesteia;• Încurajarea competiției pozitive între

membrii acesteia și susținerea punctelor de vedere multiple, deoarece acestea pot genera idei constructive care pot fi bene-fice proiectului;• Dobândirea de cunoștințe noi despre

abilitățile și cunoștințele celorlați, pen-tru o mai bună împărțire a sarcinilor și pentru o mai bună înțelegere a rolurilor fiecăruia în cadrul echipei; • Înțelegerea procesului de delegare

a sarcinilor, deoarece multe activități de team-building încurajează delegarea responsabilităților, ceea ce va duce la o

eficientizare a muncii în echipă, dar este și un factor important în crearea unui echilibru în cadrul echipei.

Activitățile de team-building pot fi și ele diverse:

1. Învățarea prin joc – desfășurarea unor activități, iar în urma soluționării sarcinii prin joc participanții extrag concluzii care vor duce la învățarea sau înțelegerea aplicării unei comunicări eficiente în cadrul echipei, precum și crearea coeziunii echipei prin câștigarea

Team building (II)

Dacă prima parte a articolului s-a axat mai mult pe definirea a șapte pași de urmat în organizarea unui team-building, partea a doua va fi orientată mai mult spre a înțelege importanța și beneficiile unui program de team-building, precum spre prezen-tarea tipurilor de activități de team-building care există. Așa cum v-ați obișnuit și în acest număr vor fi și exerciții practice pe

care le puteți folosi în a crește coeziunea echipelor pe care le coordonați.

Timp alocat activitate

15 minute/ grup

Total: Nume activitate SCUTUL

Impărțire pe echipe

Grupul este împărțit în echipe

de câte 2 Localizare Indoor / outdoor

Materiale Coala A4 cu instrucțiunile

Pixuri

Obiective Cunoașterea celorlalți membriiDescriere Participanții se împart în grupuri

de câte 2 și discută cele 4 înt-

rebări, apoi desenează aspectele

pe care le consideră reprezenta-

tive pentru cealaltă persoană.

Desenele vor fi prezentate în

final întregului grup împreună

cu explicațiile de rigoare.

Necesar Fiecare participant trebuie să aibă o listă cu întrebări (coală A4)



încrederii celorlalți membri ai echipei; 2. Organizarea de evenimente tematice care

să încurajeze lucrul în echipă. Un bun exemplu sunt competițiile sportive în care membrii echipei învață să concureze unul cu celălalt și în felul acesta vor înțelege că în unele situații concurența poate fi benefică. Alte eve-nimente pot fi evenimentele în care sunt implicați toți angajații companiei, iar cel mai cunoscut exemplu sunt petrecerile de Crăciun.

3. Evenimentele sociale sunt o altă modalitate de a crea coeziunea în echipă. Mediul informal este benefic în procesul de cunoaștere personală a membrilor echipei. Cum menționam în articolul anterior, cu cât persoanele se cunosc mai bine la nivel personal, cu atât procesul de soluționare a unui conflict poate fi mai eficient.

Așadar, sintetizând, beneficiile programelor de team-building sunt mai multe decât intuitive: • Creșterea eficienței lucrului în echipă;• Cunoașterea membrilor echipei la nivel perso-

nal și profesional prin punerea lor în situații diverse;• Creșterea încrederii în membrii echipei;• Dezvoltarea sentimentului de apartanență la

echipă și la companie;• Dobândirea sau îmbunătățirea unor abilități și

cunoștințe;• Crearea unui mediu plăcut în cadrul echipei;• Motivarea membrilor echipei și creșterea sti-

mei de sine;

Cred că sunteți convinși de impactul pozitiv pe care activitățile de team-building le pot avea asupra efiecienti-zării procesului de lucru în echipă, de aceea vă încurajez să investiți și resurse financiare și umane pentru a orga-niza astfel de evenimente cât mai des.

Succes!

Team building (II)HR

Timp alocat activitate 15 minute planificare

30 minute executie – construierea podului15 minute debriefingTotal: 60 minute

Nume activitate

Podul

Împărțire pe echipe

4 echipe (10 membri/ echipa – maxim)

Localizare Indoor / outdoor

Materiale Flipchart/ CartonColi A4Scotch, foarfecă, sfoarăPlastic

ObiectiveColaborare între echipe;Planificarea activităților; Capacitatea de transmitere a informației.

DescriereInstructiuni:Este un exercițiu de lucru în echipă. Scopul fiecărei echipe este acela de a construi o jumătate de pod care să se potrivească perfect cu jumătatea de pod con-struită de echipa cealaltă.Cu resursele pe care le aveţi la dispoziţie, materiale și abilităţi, veţi proiecta și veţi construi jumătatea voastră de pod.Reguli:1. Desemnați un reprezentant prin care veți comunica cu cealaltă echipă. Reprezentanții își vor stabili întâlniri prin intermediul trainerilor, în cadrul carora va discuta des-pre strategia de construcţie, astfel încât să construiți două jumătăți de pod compatibile.2. Reprezentatul va duce de fiecare dată o coală albă cu el și va transmite informaţiile pe care voi îl instruiţi să le transmită. El se va întoarce cu noi informaţii pe care vi le va transmite vouă.3. Reprezentanții nu au voie să ducă la echipe foile de la întâl-niri, ci trebuie să transmită verbal ce s-a stabilit.4. La finalul construcției, uniți cele două jumătăți de pod.5. Podul trebuie să fie suficient de solid astfel încât să susţină o cană plină cu apă.Concluzii:În primul rând vă precizez că a fost un joc de colaborare între echipe, ca între două firme partenere, sau între două departamente.Succesul colaborării constă în a transmite curat informaţiile prin intermediul celor doi reprezentanţi.Apoi, ca orice sarcină de echipă presupunea ca fiecare mem-bru să își aducă contribuţia la atingerea obiectivului final. Erau mai multe etape în drumul către atingerea acestui obiectiv:- Planificarea activităţii: cum utilizaţi materia primă, proiecta-rea podului, distribuirea sarcinilor, cine e responsabil? de ce?, valorificarea abilităţilor membrilor, colaborarea, comunicarea.-Construcţia propriu-zisă, implementarea planului, executarea.Fiecare etapă era dependentă de succesul comunicării cu exte-riorul și în interior.

Necesar Fiecare lider de echipă trebuie să aibă instrucțiunile

Andreea Pâ[email protected] în cadrul Endava



Metodologiile de implementare agile au un impact deosebit asupra disciplinei de analiză de business în general, întrucât aduc în prim - plan o metodă nouă de abor-dare și prioritizare a cerinţelor în cadrul unei echipe de implementare al unui pro-iect IT.

Analiștii de business sunt o compo-nentă vitală a unei echipe IT în Agile pe întreg parcursul derulării proiectului, reprezentând legătura dintre partea tehnică și cea business. Calităţi precum colabora-rea, facilitarea, leadership-ul, coaching-ul, cât și teambuilding-ul devin competenţe necesare, suficiente și esenţiale pentru asi-gurarea livrării cu succes a unui produs IT în final. Împreună cu noile maniere și tră-sături ale procesului de dezvoltare, analiștii de business devin persoane critice în asigu-rarea succesului unei echipe ce abordează o metodologie agilă.

Migrarea de la o perspectivă de abor-dare tradițională a unui proiect la una „agilă” va conduce la o redefinire a roluri-lor funcţionale din cadrul unei echipe de proiect într-o manieră diferită.

Pentru analiștii de business, gestionarea cu succes a unui proiect agil depinde foarte mult de procesul de definire a cerinţelor în

pași mai mici și dezvoltarea unei colaborări mai strânse cu întreaga echipă de-a lungul SDLC –ului proiectului.

În cele ce urmează, acest articol va explora impactul metodologiei de dez-voltare agilă asupra Analizei de Business,. De asemenea identificarea competenţelor necesare și conturarea rolului Analistului de Business pentru a facilita tranziţia de la metodologii tradiţionale la cele Agile, vor reprezenta subiecte de analiză.

Definirea cerinţelor de business în AgileÎntr-o lume agilă, cerinţele software

sunt dezvoltate prin explorarea continuă a nevoilor de business. Acestea sunt colec-tate și rafinate printr-un proces iterativ de planificare, de prezentare a criteriilor de acceptare, de prioritizare și dezvoltare a acestora, precum și de evaluare rezultatelor obţinute. De-a lungul derulării procesu-lui de analiză business, specialiștii acestui domeniu trebuie să se asigure în mod con-stant că toate caracteristicile cerute de clienţi se aliniază cu obiectivele de business ale produsului, mai ales ca acestea evolu-ează și se pot schimba în timp.

Ce înseamnă Analiza de Business în context Agile? Aceasta aduce în prim- plan

Schimbările rapide de piaţă au condus la nevoia companiilor de a scurta timpul de livrare al unui produs și de a fi mai receptivi la expectanţele și doleanţele clienţilor. Metodologiile de dezvoltare agile sunt instrumente necesare, de top, ele reușind să

reprezinte un adevărat suport pentru echipele de dezvoltare a proceselor soft, în dorinţa lor de a se adapta conform noilor tendinţe de pe piaţă.

Provocarile unui business analyst

în Agile

management

Monica Petraru [email protected]

Senior Business Analyst @ UNIQA Raiffeisen Software Service


nevoia creșterii de livrare a valorii de busi-ness către sponsorii si clienţii proiectului / produsului aflat în curs de implementare. Domeniul Analizei de Business Agile res-pectă cu stricteţe valorile și principiile ilustrate în “Agile Manifesto” (www.agile-manifesto.org):

• Valorificăm mult mai mult interac-ţiunea dintre oameni decât cea dintre procese și instrumente.• Target-ul nostru primordial este acela

de a satisface cerinţele clientului nostru prin livrarea continuă a unui software de calitate .• Dezvoltarea produselor de soft repre-

zintă măsura principală de obţinere a progresului.

Rolul Analizei de Business în context agil este acela de a oferi informaţia corectă și necesară echipei de implementare în momentul și în etapa când aceasta este solicitată pentru a asigura o stabilitate a derulării procesului soft.

În context agil, analiștii de business pot beneficia de feedback-ul constant al clien-ţilor atunci când efectuează împreună cu partea de client o recenzie a rezultatelor obţinute în urma efectuării unor iteraţii succesive. Astfel, ei pot executa rafinarea specificaţiilor produsului pentru a se asi-gura de menţinerea coeziunii cu nevoile de business a produsului / proiectului, cât și identificarea și reducerea riscurilor încă din incipitul proiectului / produsului.

Procesele de dezvoltare iterative oferă șansa de a crește gradul de eficienţa în cadrul activităţii de analiză de business. În cadrul metodologiei Waterfall, analiza spe-cificaţiilor are loc înaintea începerii fazei de implementare.

Identificarea factorilor de risc corelată cu dezvoltarea specificaţiilor de business conduc la modificarea sau eliminarea cerin-ţelor, efortul depus în acest sens devenind inutil. Așadar, prin oferirea specificaţiilor de tip just – in – time, scade semnificativ șansa de a reface anumite cerinţe, întrucat doar specificaţiile necesare release-ului pla-nificat vor fi definite în detaliu și ulterior implementate.

Ce înseamnă sa fii un Analist de Busi-ness în AGILE?

Abordarea unor proiecte de com-plexitate ridicată a condus la creșterea importanţei funcţionale a unui analist de business. Rolul acestuia este acela de a crea o viziune a produsului bazându-se pe spe-cificaţiile primite de la toţi stakeholder-ii

implicaţi.Părţiciparea unui Analist de Business

poate fi abordată din mai multe perspective:• În cadrul unor proiecte, nevoia unui

specialist dedicat nu e solicitată. Orice membru al echipei poate al echipei de implementare poate executa activităţi de identificare și prelucrare a cerinţelor.• În cadrul unui mediu mai complex,

analistul de business joacă rolul unui moderator, reușind să-i aducă la un con-sens pe toţi participanţii implicaţi cu scopul de a defini cerinţe clare pentru echipa de dezvoltare.• Responsabilul de produs (engl.

Product owner) / reprezentantul clien-ţilor (engl. “Customer representative”): e însărcinat să ia act de tot ceea ce înseamnă caracteristicile produsului și prioritizarea acestora.• Substitutul responsabilului de produs

când acesta nu este disponibil.• Analistul poate fi definit ca un busi-

ness coach într-un produs / proiect, unde responsabilul de produs este o persoană dedicată, care nu dispune însă de experi-enţa tehnică corespunzătoare sau echipa de implementare nu are cunoștinţele de business necesare.

Unul dintre elementele cheie vitale pentru un analist de business într-un mediu agil este reprezentat de abilitatea de a utiliza feedback-ul pentru a genera meca-nismul schimbării.

Analistul trebuie să revizuiască în mod constant împreună cu toate părţile impli-cate cerinţele și totodată să se asigure că orice modificare a nevoilor de business sunt reflectate cu acurateţe în iteraţiile vii-toare ale produsului.

Calităţile de succes ale unui Analist de Business într-o echipă AGILE

Conform punctelor stipulate în Agile Manifesto, întreaga echipă trebuie să fie extrem de competentă și eficientă în ceea ce privește activitatea ei profesională. Pentru a atinge toate obiectivele de productivitate planificate într-o echipă agilă , analistul de business trebuie sa fie mereu cu un pas

înaintea tuturor. Acesta are datoria de a cunoaște

întreaga viziune și lista de specificaţii a pro-dusului și de a face parte din echipa finală de livrare a produsului. Ei sunt participanți activi, responsabili de planificare, analiză, testare și demo al produsului. Analistul se asigură ca produsul să respecte toate standardele cerinţelor de business. Un alt element primordial în activitatea sa este acela de a defini criteriile strategice pentru finalizarea produsului / proiectului.

În această etapă, calităţi precum nego-cierea, comunicarea și facilitarea sunt esenţiale. Este un moment când analistul are nevoie de capacitatea de a asculta și întelege feedback-ul primit de la toate păr-ţile direct interesate și ulterior de a utiliza aceste informații primite pentru a executa modificările necesare în analiza și prioriti-zarea cerinţelor proiectului / produsului.

Analiștii de business trebuie să posede o capacitate enormă de a înțelege carac-teristicile metodologiei agile pe care o folosesc în munca lor de zi cu zi cu scopul de a gestiona, extrage, analiza, documenta, comunica și valida specificaţiile. În cele ce urmează, se vor aduce în prim – plan o suită de metodologii agile și rolul analistu-lui de business în fiecare dintre acestea.

Analiza de Business în SCRUMÎn Scrum nu se face o referire minu-

ţioasă și exactă asupra activităţilor de analiză de business. Ca un fapt adiacent, multe dintre activităţle specifice analizei de business apar ca etape implicite în Scrum. În acest sens, figura următoare ilustrează ciclul de viată specific în Scrum unde acti-vităţle tipice de analiză de business se vor suprapune:

Provocarile unui business analyst în Agileprogramare



Realizarea și asigurarea mentenanţei backlog-ului produsului reprezintă o acti-vitate majoră a analizei de business. Pentru o clarificare mai specifică, backlog-ul este construit cu ajutorul:

• elementelor de analiză de business organizatională: identificarea lacunelor și capacităților noi, utile pentru a atinge standardele organizaţionale propuse și alinierea acestora la caracteristicile organizației• evaluarea și validarea soluţiei.

În cadrul unui sprint, activităţile de analiză de business se focusează strict pe definirea cerinţelor pentru elementele backlog-ului ce sunt implementate și pe criteriile de acceptare a acestora (“Just – in – time requirements gathering”)

Technicile specifice sunt: • Gestionarea backlog-ului (engl.

“Backlog management”) – prin inter-mediul acestuia se asigură o bună prioritizare a cerinţelor, cât și partea dedicată managementului schimbării.• R e t r o s p e c t i v e l e ( e n g l .

“Retrospectives”) – Analiștii de business trebuie să acorde o atenţie deosebită feed-back-urilor cu privire la cerinţele pe care le oferă echipei și totodată cum și când acestea sunt prevăzute în scopul de a găsi modalităţi de îmbunătăţire a proceselor în care sunt utilizate.

Analiza de Business în Extreme Programming

Pentru a facilita o mai bună întele-gere a acestei metodologii, în figura de mai jos se ilustrează modelul XP:

Această metodologie se concentrează foarte mult pe “value driven develop-ment”, și mai puţin pe activităţi prestate în domeniul analizei de business. Conform modelului XP, rolul clientului este repre-zentat de un grup de oameni care știu exact specificaţiile pe care trebuie să le respecte sistemul.

Totuși există anumite circumstanţe, când modelul XP este aplicat la scară largă sau clienţii nu au o viziune clară a

produsului. În acest caz, apare imperi-oasa nevoie a unui analist de business. Contribuţia acestuia se va materializa prin crearea unei reprezentări grafice de povești (engl. “story mapping”) de - al lungul unui continuum de timp. Aceasta va fi utilizată pentru a identifica riscurile și dependin-ţele între poveștile de utilizator în vederea optimizării valorii livrate de fiecare punere în aplicare a unei povești într-o manieră incrementală.

Competenţele specifice analizei de business pot fi utilizate pentru a asigura că problemele ce stau la bază vor fi abordate într-un mod convenabil pentru majorita-tea actorilor implicaţi în proces, precum și pentru asigurarea criteriilor riguroase de acceptare ce vor fi selectate pentru fiecare user story.

Technicile specifice sunt: • Poveștile utilizatorilor (engl. “User

stories”);• Maparea poveștii (engl. “Story

mappings”);• Descompunerea poveștii (engl.

“Story decompositions”);• E l a b o r a r e a p o v e ș t i i ( e n g l .

“Story elaboration”).

Analiza de Business în KanbanBazându-se pe teoria constrân-

gerilor și totodată pe lean product development, Kanban se axează pe urmă-toarele caracteristici:

• vizualizarea productivităţii,• l imitarea muncii de-a lungul

procesului,• concentrarea strict doar pe cerinţele

ce trebuie implementate,

• n e v o i a u n e i î m b u n ă t ă ţ i r i continue.

Activitătile de analiză de business se caracterizează prin constanţă de-a lungul ciclului de viață al unui proiect. Pentru menţinerea unei ordini a functionalităţi-lor ce trebuie implementate, analiștii de business vor utiliza tehnici de identificare și extragere de noi specificaţii ale produ-sului. Ulterior, prin intermediul metodelor

specifice analizei cerinţelor se vor priori-tiza specificaţiile având la bază valorile de business concret stabilite. Gestionarea lis-tei de cerinţe, cât și identificarea și definirea domeniului de business se vor materializa prin aplicarea technicilor binecunoscute de analiza de business.

În ceea ce privește etapa de planificare și coordonare a task-urilor în metodologia Kanban, se va apela la acorduri privind nivelul serviciilor (engl. “Service Level Agreements”) pentru a menţine tracking-ul enhacement-urilor la care se lucrează momentan. În Kanban, această estimare include planificarea si prioritizarea acti-vităţilor de analiză de business ce au loc înainte de etapa de implementare a func-ţionalităţilor. Astfel, analistul de business se focusează strict pe monitorizarea și pla-nificarea activităţilor, putând face o revizie constantă si rafinare a estimărilor de fie-care dată când o nouă funcţionalitate intră în faza de analiză a ciclului Kanban. Un analist de business extrem de bun va reuși să definească cerinţe noi pentru sistem mult mai repede decât acestea ar putea fi implementate și testate. Acest fapt este util pentru un analist de business, întrucât îl va ajuta la identificarea și gestionarea riscului încă din incipitul proiectului. După cum se poate observa, succesul de piată în econo-mia zilelor noastre depinde foarte mult de promptitudinea răspunsului dat la tendinţa schimbătoare a acesteia. S-a demonstrat faptul că aspiraţiile tradiționale de livrare a produselor nu sunt extrem de prompte în anumite tipuri de business unde se cere o calitate deosebită a produselor ce se doresc a fi livrate.

ConcluziiMetodologiile agile permit echipe-

lor implicate în dezvoltarea produselor să împlinească doleanţele clienţilor prin cre-area unei ambianţe de lucru plăcute unde membrii echipei vor dori să se implice total. Analiștii de business îndeplinesc un rol cheie în cadrul unei echipe agile. Pentru a-și atinge obiectivele cu succes, aceștia trebuie să treacă de la o abordare consacrată de gândire în ceea ce înseamnă analiza de cerinţe. Ca un element adiţio-nal, analiștii trebuie să își îmbunăţească procesul de documentare a specificaţiilor, cât și aprofundarea de noi tehnici pentru managementul eficient al acestora. Întregul succes va depinde în mare măsură de cât de bine vor reacţiona analiștii de business la noile tendinţe de lucru cu specificaţiile, la formarea echipelor și la colaborarea tuturor stakeholder-ilor implicaţi.


management

Project Manager şi Business Analyst

- un duet care poate face diferența în

outsourcingul românesc

Și atunci ce putem face noi, aici, în România?

Ca să putem răspunde la această între-bare ar trebui să ne uităm la principalii factori care influențează alegerea unui fur-nizor de servicii software:

• Calitatea produselor furnizate• Preț• Referințe (Încredere)• Flexibilitate • Resurse • Relații de colaborare• Asemănări culturale• Localizarea

Oare care dintre ei poate face diferența? Cu siguranță unii factori nu pot face diferența - cum ar fi prețul. Nu putem concura pe preț tot timpul pentru că va influența resursele și sustenabilitatea pe termen lung. În ceea ce privește resursele ( profesioniștii de care avem nevoie) ar fi extrem de greu de concurat la nivel canti-tativ cu India sau China doar uitându-ne la diferenta de populație. Și, totuși, există o serie de arii cheie în care nu doar că putem face diferența, dar am putea chiar excela.

Commitmentul pe calitate: este mai mult decât a livra produse de calitate, cu cod bine scris. Presupune garanție oferită clienților încă de dinainte de începerea

proiectelor. “Commitment pe calitate” se leagă de gradul de maturitate al unei companii și înseamnă asumarea calității, a termenelor și a tuturor condițiilor convenite.

Predictibilitatea: înseamnă capacita-tea unei companii de a înțelege clientul, de a fi în măsură să îi creioneze un roadmap viabil, sustenabil și care să îi asigure succe-sul într-un mod convingător.

Customer intimacy: se referă la a înțelege nevoile și afacerea clienților, piața și clienții și la a încerca, prin idei inova-tive, să livrezi cele mai bune soluții. Cum îți dai seama dacă faci o treabă bună? Atunci când clientul te percepe ca pe un consultant de încredere și nu doar ca pe un prestator de servicii, scopul este atins în mare parte.

Rolurile care fac diferențaEste de necontestat necesitatea unei

echipe de proiect valoroase pentru obținerea ambițiilor de mai sus, dar din această echipă se disting două roluri cheie care pot face diferența, în special prin valoarea adăugată. Acestea sunt rolurile de Project Manager și de Business Analyst. Dacă un Project Manager profesionist asi-gură predictibilitatea, un Business Analyst face legătura între problemele clientului și

Lucrez în IT, în software outsourcing, de mai bine de zece ani, și am urmărit dezvol-tarea acestei industrii dinăuntrul ei. Criza financiară și focusul pe eficientizarea costurilor au îndemnat tot mai multe companii să apeleze la outsourcing, trend ce

i-a favorizat dezvoltarea. Cu ce urmări? În primul rând a creat un glob de cristal protec-tor în jurul acestui segment care a continuat să crească organic în ciuda crizei financiare și a înflorit tocmai într-o perioadă în care alte industrii își restrângeau activitatea sau dis-păreau din peisaj. În al doilea rând, a fost acompaniată de o ofertă de muncă mai largă, salarii bune și un mediu de lucru la nivel occidental. Creșterea costurilor face însă ca marja de profit în cazul outsourcing-ului să nu mai fie la fel de mare cum era cu 7-10 ani în urmă și să facă loc astfel concurenței puternice pe cost venite dinspre India sau China.


Project Manager@ Yonder



echipa de dezvoltare și contribuie în mod hotărâtor la obținerea poziției de “trusted advisor” menționat anterior.

Dacă acum câțiva ani companiile căutau Project Manageri cu cunoștinte aprofundate pe domeniul proiectului, suplinind astfel și rolul de BA, schimbările din ultimii ani și profesionalizarea secto-rului au determinat specializarea rolurilor și necesitatea unei poziții de sine stătătoare pe domeniul analizei de business. Mai mult, faptul că metodologiile agile pun focus pe rolul de BA (sau pe specialistul de produs), rolul de Project Manager a evo-luat spre a fi un integrator de echipe, un rol care lucrează cu echipe distribuite pentru a atinge scopul proiectul și în a ține costurile sub control.

Sigur, există voci care spun că există un puternic conflict între cele două roluri, cel de PM și cel de BA. La prima vedere acest conflict este real, deoarece PM-ul gestio-nează bugetul/scopul și resursele, iar BA-ul se ocupă mai mult de detaliile esențiale rezolvării și optimizarii proceselor de busi-ness, care pun presiune pe buget și scop.

Și, totuși, dacă nu există o colabo-rare strânsă între cele două roluri sau dacă unul dintre ele este mai slab există o mare probabilitate să nu fie obținut succe-sul proiectului. Mai mult, pentru că cele doua roluri au anumite responsabilități comune există nevoia unui framework de colaborare.

Există doi mari jucători în stabili-rea direcțiilor pentru cele două roluri:

Project Management Institute (PMI) și International Institute of Business Analysis (IIBA), care au creionat un astfel de model de colaborare.

Dacă luăm principalele faze din pro-iect definite de cele două institute de profil, avem următoarea implicare a celor doua roluri:

• Inițierea proiectului (“Inception”): aici un rol esențial îl are BA-ul pentru că, în această fază se construiește un busi-ness case. Aceasta este etapa în care se ia decizia de “Go - No go”. Tot acum sunt identificate nevoile de business. • Planificarea: rolul de PM este

esențial, deoarece acum se construiește planul de proiect, se alocă resursele necesare, project managerul își definește cele trei zone importante pe care le va monitoriza: scop, buget și timp. • Execuția, monitorizarea și contro-

lul: Ambele roluri trebuie să lucreze în tandem pentru a obține succesul pro-iectului. Dacă PM-ul se concentrează mai mult pe monitorizarea bugetului, a costurilor, timpului, resurselor și a ris-curilor (fiind principalul responsabil pe scopul proiectului), BA-ul pune accent pe funcționalitate, calitate, pe riscurile care vin dinspre partea funcțională, din zona de produs. Totodată, prin deciziile luate de el, se influențează scopul pro-iectului prin schimbări sau defecte găsite în produs. • Încheierea: în această fază există

un efort comun PM și al BA pentru a

obține acceptarea proiectului din partea clientului.

ConcluziiUnul dintre modurile prin care

România se poate remarca pe piața de IT nu este axat pe criterii de cost scăzut, ci prin crearea de valoare adăugată pentru clienți, proces în care cele două roluri descrise mai sus au un aport semnficativ. Project Managerii și Business Analiștii tre-buie să colaboreze pentru un țel comun și anume spre obținerea de soluții inovative care rezolvă problemele de business ale clienților.


business

Dispozitivele mobile pot fi folosite drept clienţi thin într-un browser web, dar în această recenzie vom introduce acele ele-mente care transformă dispozitivele mobile într-o platformă, în care putem dezvolta și rula aplicaţii de sine stătătoare. Partea care nu este cuprinsă în această carte este aceea a dezvoltării clienţilor rich pentru aplicaţii enterprise, care rulează offline sau online, având un modul backend găzduit de un server de aplicaţie.

Prezenta carte, intitulată Android Apps with Eclipse de Onur Cinar, prezintă o tre-cere în revista introductivă despre cum să instalăm, să configurăm și să rulăm aplicaţiile Android. Nu se vor aminti concepte despre Android API sau tehnici de programare, ci este doar un scurt rezumat despre cum să utilizăm Eclipse Android Toolkit (ADT).

După părerea mea ori-cine poate citi această carte. Desigur, unele cunoștinţe generale despre limbajul Java sunt binevenite, dar nu obligatorii. Este, așadar, o carte ușor de citit. După ce au fost făcute toate instală-rile, partea de instalare este descrisă în aproape 40% din carte, urmărirea programe-lor prezentate este ușoara. Tot ce avem de făcut este să copiem în Eclipse codul și

să-l rulăm. Totuși, vă recomand să studiaţi codul. Vă poate oferi soluţii sau exemple de implementare, dar și idei pentru extensii, în munca voastră viitoare.

Cartea este organizată în 10 capitole prezentând diverse aplicaţii. Una dintre ele este “Movie Player”. În această carte toate exemplele sunt dezvoltate folosind Android 2.3.3, probabil cea mai populară versiune de Android, deși a fost lansată în 2011. Găsim în carte și discuţii despre alte versiuni, ultima versiune de Android tra-tată în carte fiind Android 4.0.4, lansată în

Această recenzie este despre un subiect foarte popular în zilele noastre, în lumea dezvoltatorilor de aplicaţie, aplicaţiile Android. Mulţi clienţi, precum aplicaţiile pe dispozitivele mobile, folosesc această platforma.

Recenzia cărții:Android Apps with Eclipse

de Onur Cinar

Silviu [email protected]

Consultant Java@ msg systems Romania

programare



februarie 2012.Așa dupa cum este bine cunoscut, plat-

form Android este proprietate a Google și reprezintă un open standard pentru dispo-zitivele mobile. Statistic vorbind, statistic prezentate în carte, Android deţine 48% din piaţa de aplicaţii pentru dispozitivele mobile.

Android este mai degrabă un software stack complet pentru dispozitive mobile, decât un sistem de operare. Android se bazează pe sistemul de operare Linux și pe Java Virtual Machine pentru aplicaţii utili-zator. Android este format dintr-o mulţime de de componente, ce pot fi accesate atât de platformă cât și de alte aplicaţii. Aceasta permite interoperabilitatea aplicaţiilor.

Cea mai importantă componentă a aplicaţiei Android este activity, care cores-punde unui ecran vizual. Utilizatorul poate interacţiona cu aplicaţia prin intermediul acesteia. O operaţie pe activity este numita intent și poate determina afișarea altor activities. Munca de fundal a unei aplica-ţii este dată de services. Sunt și multe alte componente într-o arhitectură Android, dar las cititorului plăcerea să le găsească în capitolul 2 al cărţii. Platforma Android furnizează modalităţi multiple de stocare a datelor printre care bazele de date SQLite.

Următoarele două capitole, 3 și 4, sunt despre IDE-ul Eclipse și metodele de insta-lare ale acestuia dependent de platformă. După părerea mea, aceia care sunt famili-ari cu IDE-ul Eclipse pot sări aceste două capitole. Pentru ceilalţi este o excelentă modalitate de a deveni experţi în utilizarea

Eclipse-ului.

Capitolul 5 descrie instalarea ADT developer tools, inclusiv a emulatorului Android.

Începând cu capitolul 6 vom utiliza Android Developer Tool. Prima aplicaţie prezentată este “Movie Player”. Tot în acest capitol se discută manifest editor, layout editor și resource editor. Partea finală a capitolului se referă la implementarea cla-selor implicate în proiect.

Capitolul 7 este despre Android Native Development Kit (NDK), care permite dezvoltatorilor să implementeze porţiuni de aplicaţie în cod nativ mașina. NDK fur-nizează biblioteci C, o bibliotecă minimală C++, o bibliotecă Math, o bibliotecă grafica Open GL și multe altele. Capitolul include un ghid de instalare NDK și Sequoyah (plug-in ce furnizează un mediu complet de dezvoltare a aplicaţiilor mobile).

Capitolul 8 extinde proiectul movie pla-yer pentru rularea filmelor în format AVI. Aceasta folosește Android NDK, deoarece bibliotecile AVI vin cu soluţii open source implementate în C/C++.

Ultimele două capitole sunt despre Android scripting. Primul prezintă partea teoretică iar al doilea unele extensii ale pro-iectului “Movie Player”. Android scripting reprezintă este o unealtă la îndemână pen-tru task-uri simple. Script-urile nu trebuie compilate și în consecinţă nici împache-tate sau desfășurate pe server. Cartea de

faţă prezintă Scripting Layer for Android (SL4A), care cuprinde o multitudine de interpretori pentru Android precum Perl, Python, Rhino etc.

Așa după cum am mai afirmat, în spa-tele simplităţii aparente cartea este un ghid atât pentru începători cât și pentru cei care caută soluţii pentru problemele lor de dez-voltare a aplicaţiilor Android.

Ca de obicei spun că sunt intersat în discuţii cu cititorii și de aceea îi invit să le iniţieze sau să ia parte la ele.

Lectură placută!

business


Ce este un load test?Dar ce este de fapt un load test? Scopul

principal pe care un astfel de test îl are este definirea și validarea load-ului maxim pe care un sistem îl poate avea fără ca performanța să scadă simțitor. Chiar dacă dezvoltatorul îți spune că sistemul poate să gestioneze fără nici o problemă 1000 de useri simultan, un load test poate să dovedească contrariul, chiar și pe cele mai simple scenarii.

Există o demarcație foarte subțire între un load test și un stress test. De foarte multe ori un load test se finalizează cu un stress test care are ca scop observarea comportamentului pe care sistemul îl are

în momentul în care load-ul crește peste capacitatea maximă pe care acesta trebuie să o suporte.

Ce ne oferă piața în acest moment?La ora actuală piața este plină de dife-

rite soluții pentru testare automată și pentru rularea load testelor. Produse pre-cum Selenium, LoadStorm sau Neoload domină piața.

Dacă folosim o soluție on-premise tre-buie să fim pregătiți să rezolvăm probleme precum achiziția sau rezervarea resurselor pentru load test. Într-o companie mică va fi greu cumpărarea a 10 servere doar pen-tru a putea rula un load test. În schimb

într-o companie mare, chiar dacă are resurse financiare suficiente, din momentul în care facem o cerere pentru aceste resurse, până în momentul în care o să avem resursele dispo-nibile, poate să treacă o perioadă lungă de timp – uneori chiar să fie prea târziu. Pe lângă acești factori, configurarea fie-cărei mașini și deploy-ul

Într-o lume perfectă m-aș aștepta să pot rula un load test sau un stres test folosind un furnizor de cloud fără să fiu obligat să modific o linie de cod din testele mele.

În cadrul acestui articol vom descoperi cum putem să facem acest lucru folosind un nou serviciu de cloud. Cum o persoană care are cunoștințe zero despre cloud poate să ruleze un load test de 50.000 de useri timp de 24 de ore cu costuri minime, fără să fie obligat să achiziționeze și să configureze 10, 20 de noduri.

Load Test folosind Windows Azure

programare

Radu [email protected]

Senior Software Engineer@iQuest



poate să fie un labirint din care să nu mai găsim ieșirea.

Ce ne propune Microsoft?Pe această piață, extrem de matură a

apărut Microsoft cu o soluție extrem de ingenioasă. Dacă acesta deja are o infra-structură pentru cloud puternică și robustă, de ce să nu ofere posibilitatea de a rula load teste folosind Azure. Deși aceștia nu au prima soluție de acest gen de pe piață, Microsoft are un as în mânecă. Aceștia îți permit să rulezi un load test folosind Azure fără să fie nevoie să faci o configurație în plus. Trebuie să ai doar un cont pe Visual Studio Team Foundation Service (http://tfs.visualstudio.com/), aceasta fiind folosit pentru facturare.

Până acum, un load test se putea face

folosind soluțiile pe care Micosoft ni le pune la dispoziție prin intermediul unui Load Test Ring. Acesta este format dintr-un controller ce controlează testele – Load Test Controller și unul sau mai mulți agenți pe care testele noastre rulează. O arhitectură care are la bază master-slave. Noua versiune

de Visual Studio 2013 ne pune la dispoziție o noua opțiune – în loc să rulăm testele noastre în propriul nostru Load Test Ring putem să le rulăm direct pe Azure, fără nici o configurație în plus. Nu este nevoie să facem deploy la nici o mașină virtuală sau să configurăm diferite servicii.

Load Test Web ServiceLoad Test Web Service este servicul de

pe Azure care ne ajută să facem acest lucru. Prin intermediul acestuia, Visual Studio 2013 încarcă testele noastre pe cloud. În spatele acestui serviciu există un pool de test agents care este folosit pentru a rula testele noastre. Dar acest lucru se întâmplă în spatele scenei, fără ca noi să fim obligați să facem ceva. Toate rezultatele testelor noastre, împreună cu diferiți performance counters ne sunt puse la dispoziție.

Care sunt caracteristicile principale?Înainte să ne uităm peste diferite

funcționalități care sunt suportate, vă propun să aruncăm o privire peste cele mai importate opțiuni suportate în acest moment.

Avem posibilitatea de a defini UI tests și nu numai. Pe lângă posibilitatea de a face record și de a rula teste de UI, putem în orice moment să ne scriem testele noastre specifice și să lovim diferite endpoint-uri. Un endpoint testat nu trebuie să fie doar HTTP sau HTTPS. Putem la fel de bine să testăm un endpoint WCF, REST sau un web service. Singura condiție care există este ca endpoint-ul să fie accesibil de pe internet.

Visual Studio 2013 ne aduce un nou template de proiect – Web Performance and Load Test Project. Acest tip de proiect ne v-a permite să ne definim și să rulăm load teste pe cloud fără nici un fel de probleme.

Cum să cream un load test?Cea mai simplă variantă pentru a crea

un load test pentru o aplicație web este să ne creăm unul sau mai multe teste de tip Web Performance Test. Acest tip de teste pot să fie UI teste, fiind foarte ușor de creat și automatizat. Folosind recorderul de UI care vine odată cu Visual Studio 2013, putem să creăm un Web Performance Test doar în câteva secunde. Un astfel de test poate să fie modificat în orice moment și dacă dorim avem posibilitatea să generăm cod pentru test. Prin această metodă, cei care doresc să scrie cod pentru a modifica un test pot să facă asta foarte ușor. Bineînțeles, funcționalități precum detectarea automată a elementelor dinamice pe care o pagina le are sau parametrizarea diferiților parame-trii este suportat out of the box.

Pentru fiecare test de acest gen putem să avem diferite surse de date, precum o bază de date, un CSV sau un fișier XML. Se pot folosi destul de ușor testele scrise în Selenium de exemplu. Fiecare test poate să apeleze la rândul său alte teste, astfel putem să reutilizăm o mare parte din logica pe care o avem pentru testare.

Până acuma am văzut cum se poate crea unul din testele care pot să fie folosite pentru load test. Cred că este momentul perfect să ne uităm ce ne permite un load test să facem.

Care sunt funcționalitățile de bază?Prima funcționalitate întâlnită în

momentul în care scriem un load test este “thinking time”. Putem să definim diferite profile și intervale de timp prin care să simulăm un utilizator real. De exemplu putem ca după fiecare test să simulăm un delay de X secunde. Avem la îndemână diferite profile de acest gen pe care le putem folosi.

Simularea unui load test se poate face



programare

prin diferite moduri. Avem posibilitatea să rulăm un test de la bun început cu același număr de useri sau să ne definim numă-rul de useri cu cât să crească la fiecare pas. Bineînțeles, de cele mai multe ori este nevoie să rulăm diferite scenarii în același timp. Din această cauză, avem posibilitatea nu doar să specificăm testele pe care dorim să le rulăm și în ce proporție, cât și modul în care aceste teste să ruleze. De exemplu, putem să specificăm de câte ori fiecare test trebuie să ruleze într-un anumit interval de timp sau care este numărul de useri care trebuie să ruleze un anumit test în fiecare moment când load test-ul rulează.

Putem să simulăm diferite browsere pe care clienții le au și diferite tipuri de conexiuni. Dar ceea ce mi se pare cel mai intere-sant este posibilitatea de a adăuga și a accesa nu doar performance counters de pe clienți cât și de pe serverele pe care aplicația noas-tră rulează. În acest mod putem să monitorizăm și să vizualizăm counteri atât de pe clienți cât și de pe server.

Cum să rulăm un load test în cloud?Până în acest moment am văzut care sunt principalele opțiuni

pe care le avem la dispoziție pentru un load test. Dar încă nu am văzut cum putem să rulăm un astfel de test. Tot ce trebuie să facem pentru a putea rula un load test pe cloud este să deschidem Local.testsettings, iar în tab-ul General să selectăm “Run tests using Visual Studio Team Foundation Service”. Da, doar atât este nevoie să facem pentru a putea rula testul pe cloud. Bineînțeles trebuie să fim logați în Visual Studio cu un cont ce este legat la Visual Studio Team Foundation Service.

Care este prețul?În momentul de față acest serviciu este în faza de preview.

Fiecare utilizator are lunar 2000 de minute virtuale pe care le poate folosi pentru load teste. În momentul de față nu există prețurile finale. Dacă aveți nevoie de mai multe puncte pentru load teste nu ezitați să intrați în programul de early adoption fără costuri supli-mentare. O să aveți acces la 200.000 de minute virtuale în fiecare lună pe care le puteți folosi în voie. Acceptarea unui request de acest fel ia foarte puțin (în cazul meu a fost sub 6 ore).

Prima dată când am auzit de minute virtuale m-am întrebat ce sunt acestea. Un minut virtual este egal cu durata load test-ului înmulțit cu numărul de useri.

Odată ce am rulat testele vom avea acces la toate rezultatele incluzând performance counters, testele căzute, mesaje de eroare și diferite diagrame. Toate rezultatele pot să fie exportate într-un Excel care va conține în mod automat diagrame perfecte pentru management și clienți.

Vă invit să încercați noul serviciu din cloud pentru load test. Eu am fost surprins plăcut de acest serviciu și cred că o să ne ușureze munca.

Load Test folosind Windows Azure



Începem cu un set de extensii ale compila-torului ce ne vor permite să fim mai expresivi.{-# LANGUAGE MultiParamTypeClasses #-}{-# LANGUAGE FunctionalDependencies #-}{-# LANGUAGE TypeSynonymInstances #-}{-# LANGUAGE FlexibleInstances #-}

Continuăm cu definițiile tipurilor de date:

type Name = Stringtype Age = Inttype Address = Stringtype PhoneNumber = Integer

newtype NameAgeTable = NAgT [(Name, Age)] deriv-ing Shownewtype NameAddressTable = NAdT [(Name, Address)] deriving Shownewtype NamePhoneTable = NPT [(Name, PhoneNum-ber)] deriving Show

Ne amintim că deriving Show îi spune compilatorului să definească automat câte o metodă show pentru a putea converti tipul de date la String pentru fiecare tip de date.

Populăm cele trei tabele cu valori de test:

nameAge = NAgT [(„Ana”, 24), („Gabriela”, 21), („Mihai”, 25), („Radu”, 24)]nameAddress = NAdT [(„Mihai”, „a random ad-dress”), („Ion”, „another address”)]namePhone = NPT [(„Ana”, 2472788), („Mihai”, 24828542)]

Definim o clasă pentru căutarea după nume în aceste tabele și înrolăm cele 3 tipuri la aceasta. Spre deosebire de deriving, aici va trebui să definim noi metoda. Vom folosi funcția predefinită lookup pentru a căuta într-o listă de perechi.

class SearchableByName t a | t -> a where search :: Name -> t -> Maybe a

instance SearchableByName NameAgeTable Age where search name (NAgT l) = lookup name l

instance SearchableByName NameAddressTable Ad-dress where search name (NAdT l) = lookup name l

instance SearchableByName NamePhoneTable Phone-Number where search name (NPT l) = lookup name l

Cu acest cod putem căuta în fiecare tabelă informații folosind un API comun:

*Main> search „Ion” nameAge Nothing

*Main> search „Mihai” nameAge Just 25

*Main> search „Mihai” nameAddress Just „a random address”

*Main> search „Gabriela” nameAddress Nothing

*Main> search „Ionela” namePhone Nothing

*Main> search „Mihai” namePhone Just 24828542

Aici ne-am oprit data trecută. Astăzi ne vom ocupa de modul în care putem obține informații din toate tabelele (vom simula o operație de join). Vom scrie o funcție getInfo care ne va întoarce vârsta, adresa și numărul de telefon pentru persoanele care au toate valorile trecute în baza de date (sau Nothing altfel). Implementarea la care ne gândim ar fi:

getInfo1 name = case search name nameAge of Just age -> case search name nameAddress of Just address -> case search name namePhone of Just phone -> Just (age, address, phone) Nothing -> Nothing Nothing -> Nothing Nothing -> Nothing

Observați efectul de cascadă al teste-lor: pentru fiecare căutare nouă trebuie să ne deplasăm mai spre dreapta. Din fericire, codul de mai sus poate fi scris și ca:

getInfo2 name = do age <- search name nameAge address <- search name nameAddress phone <- search name namePhone return (age, address, phone)

Pare un stil imperativ și la prima vedere testele de Nothing lipsesc. De fapt, codul este

La finalul articolului trecut reușisem să obținem o aplicație simplă ce permitea căutarea unor informații despre persoane în trei tabele (reprezentate ca liste de perechi). Vom prezenta în continuare codul cu care am terminat articolul trecut.

Programare Funcțională

în Haskell (IV)

programare

Mihai [email protected]

IxNovation @ IXIAmembru ROSEdu, ARIA



în continuare pur funcțional doar că aspec-tul declarativ este mult mai evident: se pune accentul doar pe partea esențială a codului, partea de boilerplate (codul pe care ar trebui să-l scrii în mod repetat înainte de a putea scrie cod util – în cazul nostru codul de testat dacă o valoare este Nothing și întors Nothing înapoi) este ascunsă.

De fapt, mai sus avem mult zahăr sin-tactic. Codul din getInfo2 este rescris de compilator ca:

getInfo3 name = search name nameAge >>= \age -> search name nameAddress >>= \address -> search name namePhone >>= \phone -> Just (age, address, phone)

Observați că de fapt avem de-a face cu o compoziție de funcții similară unei benzi de asamblare. Operatorul >>= ia rezultatul unei funcții și-l trimite funcției următoare. Modul în care am scris codul în TODO este demonstrativ pentru denumirea de pro-grammable semicolon oferită operatorului >>=: funcționează ca ; din limbajele impera-tive doar că are o semantică asociată. Dacă în limbajele imperative ; era doar pentru a separa instrucțiuni, >>= poate încorpora diverse logici în spate. În cazul nostru tes-tează de Nothing și întoarce Nothing dacă este cazul.

De asemenea, observați că return nu are semnificația lui return din C. De fapt, în getInfo2 puteți înlocui return cu Just sau viceversa și veți obține exact același comportament.

Testăm întâi codul scris în toate varian-tele lui

*Main> getInfo1 „Mihai” Just (25,”a random address”,24828542) *Main> getInfo2 „Mihai” Just (25,”a random address”,24828542) *Main> getInfo3 „Mihai” Just (25,”a random address”,24828542) *Main> getInfo3 „Ioana” Nothing

La final de articol vom prezenta și par-tea magică din spate, cea din limbajul de programare care ne permite ca >>= să fie

programmable semicolon. De fapt, totul se bazează pe o anumită clasă de tipuri, una din setul celor care reprezintă șabloane de pro-gramare funcțională.

Vom începe prin a reaminti clasa Functor pe care am prezentat-o în articolul trecut.

class Functor f where fmap :: (a -> b) -> f a -> f b

Dacă mai țineți minte, clasa a fost intro-dusă pentru a putea folosi fmap – operație similară map – pentru elemente ale altor tipuri. Pentru liste fmap este exact map.

Instance Functor [a] where fmap = map

Este evident că vom putea folosi fmap pentru arbori, stive, grafuri, etc. Practic, putem folosi analogia unui container: fmap aplică o funcție pentru toate elementele dintr-un container și le întoarce împache-tate într-un container de aceeași formă. Dar, îl putem folosi și pentru funcții:

*Main Control.Applicative> fmap (+1) (const 3) $ 5 4

*Main Control.Applicative> :t fmap (+1) fst fmap (+1) fst :: Num b => (b, b1) -> b *Main Control.Applicative> fmap (+1) fst $ (2, 5) 3

*Main Control.Applicative> :t fmap show fst fmap show fst :: Show a => (a, b) -> String *Main Control.Applicative> :t fmap show fst (2,3) fmap show fst (2,3) :: String *Main Control.Applicative> fmap show fst (2,3) „2”

Analogia eșuează. Putem privi f din clasa Functor ca pe un context computațional. Operația fmap va modifica acest context. De fapt, dacă ne amintim că funcțiile sunt în forma curry, tipul ne spune că fmap ridică o funcție normală la nivelul unui context computațional/container.

Nu orice tip de date suportă o instanță pentru Functor, există 2 legi din teoria categoriilor ce trebuiesc respectate. Nu voi insista asupra lor întrucât este destul de difi-cil de întâlnit in practică un tip care să nu le respecte.

Mergem la clasa care ne interesează, numită Monad. Tipurile de date listă, Maybe, Either sunt deja înrolate în această clasă.

class Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a

Observați că return este o funcție, nu este un cuvânt cheie al limbajului. Singurul lui scop este să ridice o valoare normală la contextul computațional necesar. Pentru Maybe, return nu este altceva decât con-structorul Just.

Cealaltă funcție este mai importantă. Operatorul >>= pronunțat bind realizează un lucru pe care nu l-am putea face cu fmap: imaginați-vă că avem o funcție care primește o valoare și întoarce un rezultat într-un con-text (de exemplu o funcție care primește o valoare și întoarce o listă de valori). Dacă am face fmap cu această funcție vom obține un context de contexte (listă de liste de valori) deci avem nevoie de o operație suplimentară (în cazul listelor, concat). Operatorul >> este un caz particular al lui >>= (deci definit în termenii lui) care folosește doar pentru înlănțuirea efectelor, nu transmite rezultatul unei expresii mai departe.

Și pentru monade există un set de 4 legi ce trebuiesc satisfăcute dar nu vom insista asupra lor. De fapt, cunoscând doar definițiile pentru Functor și Monad și tipurile esențiale din Haskell putem scrie destul de mult cod fără a avea nevoie de mai multe noțiuni din teoria categoriilor. Dar, dacă sunteti curioși, vă recomand să citiți Typeclassopedia1 al lui Brent Yorgey pentru a vedea ce alte șabloane din programarea funcțională mai pot fi capturate prin inter-mediul claselor de tipuri.

1 http://www.haskell.org/haskellwiki/Typeclassopedia

programareProgramare Funcțională în Haskell (IV)



ContextulSe dădea o arhitectură „clasică” de web:

un portal dezvoltat în ASP.net MVC (3 și 4) având în spate o bază de date ce rula pe MS SQL server ascunsă de Entity Framework.

Aceasta arhitectură trebuia pregati-tată de „scalare” – trecută pe un sistem ce permitea deservirea unui număr mare de request-uri.

După ce am analizat mai multe opţiuni de upgrade a arhitecturii (discursul logic poate fi revăzut în articolul precedent), ne-am decis asupra SQL Azure și Windows Azure ca platforma de migrare.

Migrare web portalulWindows Azure ne pune la dispoziţie o

multitudine de servicii și facilitaţi (de exem-plu service bus, caching, mobile services etc.), însă accesul la aceste servicii ar afecta direct arhitectura sistemului nostru.

Dar în cazul nostru, nu dorim să schim-băm arhitectura ci doar să migrăm unu la unu (în măsura posibilităţilor) arhitectura existentă, chiar dacă aceasta înseamnă că nu vom profita la maxim de facilităţile oferite de Azure.

Aveam de migrat un portal alcătuit din două website-uri de front-end și o familie de directoare virtuale ce conţin servicii.

Cum se traduce aceasta în limbaj Azure?Avem nevoie de un cel puţin un WebRole

– un web role este o mașină virtuală, sau o suită de mașini virtuale (în cazul scalarii) ce găzduiește un website (sau mai multe).

Într-un cuvânt un WebRole e un ser-ver web. Traficul web direcţionat către un WebRole va fi automat împărţit (load balanced) între toate mașinile virtuale ce alcătuiesc WebRole-ul – în felul acesta se realizează scalarea – avem nevoie să servim mai multe request-uri? Mai adăugăm mașini în WebRole.

Restricţia în cadrul unui WebRole e ca toate mașinile virtuale din componenţă să fie „identice” în configuraţie – dacă am început WebRole-ul cu o mașină cu o configuraţie modestă (A) vom putea scala doar adăugând mai multe mașini cu aceeași configuraţie A.

Cum configuraţia mașinilor din Azure va afecta direct costurile de hosting un prim pas important este să analizăm ce configu-raţie este necesară și suficientă pentru a rula website-ul/aplicaţia noastră fără probleme, urmând ca apoi să scalăm sistemul adăugând mașini cu aceeași configuraţie (și guideline – găsiţi configuraţia minimă și scalaţi orizontal – în felul acesta aveţi mai multă flexibilitate și optimizaţi costurile).

Analiza noastră va ţine cont de docu-mentaţia de pe MSDN1, caracteristicile proiectului nostru (dacă am optimizat pen-tru mai multe procesoare, dacă suntem RAM intensive, dacă ne dorim CPU dedicate sau ne descurcăm cu un CPU shared, etc.) și de testele de performanţă pe care le vom face cu diverse configuraţii – în felul acesta vom putea decide în cunoștinţă de cauză.

După ce am ales configuraţia pentru WebRole, suntem pregătiţi de a crea proiec-tul de Azure și WebRole-ul.

1 http://msdn.microsoft.com/en-us/library/win-dowsazure/hh824677.aspx

În articolele precedente am prezentat motivele alegerii lui Windows Azure în faţa altor alternative ca soluţie de scalare. O altă temă a articolelor a fost procesul de migrare al unei baze de date MS SQL în SQL Azure. În articolul curent vom încheia această serie

prin a prezenta cum am migrat portalul web dintr-un IIS on site în cloud-ul Azure.

Migrare website MVC 3 şi DB în

Azure (III)

programare

Dragoș Andronic [email protected]

CTO@ TXTFeedback



programare

Creare proiect AzureMicrosoft ne-a făcut viaţa mai ușoară integrând tot ce

înseamnă Azure direct în Visual Studio. Presupunând că folosim Visual Studio 2012 avem nevoie de SDK-ul Azure2 și suntem gata de pornire.

Deschidem soluţia ce conţine proiectul/proiectele nostre și adăugăm un proiect de tip Windows Azure Cloud Service

Pentru că vom adăuga proiectele deja existente în WebRole vom lăsa proiectul de cloud service gol

urmând să adăugăm proiectele în WebRole direct din Solution Explorer

Definirea structurii de website-uri şi directoare virtualeDupă ce am adăugat primul proiect în WebRole pe următoarele

le vom adăuga modificând direct fișierul de ServiceDefinitions. Acest fișier de configurare va descrie structura de website-uri

și directoare virtuale de pe fiecare mașină așa că în cadrul său vom include:

• Pentru fiecare website vom adăuga o intrare de tip Site – avem nevoie de un nume unic pentru fiecare website și de specificarea unui endpoint – dacă nu dorim nimic special vom lăsa endpoint-ul default (portul 80 și protocolul http).• Pentru fiecare director virtual vom crea un entry de tip

VirtualApplication. Cum un director virtual nu poate exista decât în cadrul unui website, fie punem directoare virtuale într-un website existent (va trebui ca routing-ul website-ului să permită acest lucru) sau creăm un website gol ce îl folosim doar pentru a găzdui toate directoarele virtuale. Noi am ales să creăm un website gol ca și placeholder

Într-un final vom ajunge la o configuraţie de tipul acesta:2 http://www.windowsazure.com/en-us/downloads/

Ultimul pas este publicarea WebRole-ului pe platforma Azure , adică crearea efectivă de mașini virtuale și transferarea codului pe fiecare din aceste mașini. Din nou Microsoft a făcut totul ușor pentru noi (poate prea ușor) și din Visual Studio avem opțiunea de Publish pe proiectul de tip Cloud Service.

Wizard-ul de publicare ne va ajuta să alegem și să ne creăm infrastructura Azure necesară (cloud service + storage account) și să alegem dacă publicam în sistemul de staging (recomandat) sau direct pe production.

Verificare şi validareDacă totul a mers bine și WebRol-ul a fost creat putem accesa

website-ul/website-urile noastre la adresa vizibilă în portalul de administrare (http://manage.windowsazure.com/) – o adresă tip guid.cloudapp.com dacă am publicat pe sistemul de staging, sau o adresă tip webportalulmeu.cloudapp.com dacă am publicat pe production.

Note finale – migrare web portalTooling-ul la dispoziţia noastă este excelent și Microsoft a rea-

lizat o interfaţă de management extrem de ușor de înţeles și folosit pentru Azure.

Cu toate acestea e aproape sigur că vă veţi lovi de o grămadă de obstacole în momentul migrării (particulare arhitecturii/con-textului vostru). De asemenea mai sunt încă multe întrebări la care nu am răspuns (și nici nu am încercat) în cadrul acestui articol (s-a trecut rapid peste logica de decizie „un sigur webrole” vs „mai multe webrole-uri”) așa că dacă doriţi să aflaţi mai multe detalii sau aveţi întrebări specifice, mă puteţi contacta la dragoș(at)txt-feedback.net

Note finale – migrare website MVC 3 + DB în AzureMigrarea în Azure nu a fost fără probleme, însă acum la trei

luni din momentul migrării putem spune că suntem deplini satis-făcuţi de rezultate (și de return on investment).

Majoritatea dificultăţilor au fost de know-how – cum anume traduci o arhitectură standard la un cloud – ce exact se schimba la baza de date, ce exact e un WebRole, de ce configuraţie ai nevoie? MSDN, traing-urile de pe Pluralsight, stackoverflow au ajutat, însă de departe cel mai folositor au fost discuţiile cu specialiști care au mai trecut prin acest tip de proiect.

Mulţumim cu această ocazie lui Radu Vunvulea (iQuest) și lui Zoli Herczeg (Microsoft) care și-au găsit timp în program să stea de vorbă cu noi și să ne răspundă întrebărilor.

Migrare website MVC 3 şi DB în Azure (III)



Model-View-Viewmodel (MVVM) este un design pattern folosit în ingineria software care a fost introdus prima oară de către Microsoft ca o metodă de particularizare a modelului de prezentare introdus de Martin Fowler. De fapt se pare că Microsoft folosea MVVM pentru proiectele dezvoltate intern, precum Microsoft Expression Blend, pe când nucleul platformei WPF era în construcție. Bazat în mare parte pe modelul Model-View-Controller (MVC), acesta se adresează în special dezvoltării interfeței cu utilizatorii a platformelor moderne ((HTML5, Windows Presentat ion Foundation, - WPF, și Silverlight), acolo unde există un dezvoltator orientat special spre acest lucru, având sarcini diferite de ale unui dezvoltator obișnuit care se ocupă în general de logica business și de dezvoltarea interacțiunii cu serverul.

Ca structură, acesta este alcatuit din trei părți esențiale ce pot fi deduse și din denu-mirea design pattern-ului: un Model, un View și un ViewModel. Această structură sea-mană cu cea a MVC-ului, dar oferă în plus ușurința utilizării XAML-ului și a Windows Presentation Foundation, prin cuplarea date-lor cât mai aproape de Model folosind XAML, View Model și orice verificare de date a nivelului Business pentru a valida datele îna-intea afișării acestora pe interfață. Modelul se referă la datele efectiv cu care se lucrează dar și la nivelul de acces la aceste date. Spre exemplu într-un model ar putea fi accesate obiecte care citesc din baza de date informații legate de o anumită persoană. View-urile,

la fel ca și în cazul clasic se referă la partea vizuală care va fi afișată pe interfața grafică, cum ar fi butoanele, ferestrele, graficele și alte controale. Acestea nu conțin partea de logică business. Marele avantaj în acest caz este că un designer poate să se ocupe de partea gra-fică a aplicației lucrând doar cu view-ul, în timp ce logica din spate rămâne neafectată. ViewModel-urile reprezintă niște modele pentru view-uri, mai precis acestea se referă la o abstractizare a view-urilor care servesc și la binding-ul datelor între view și model. Pot fi privite și ca niște aspecte specializate ale Controalelor din design pattern-ul MVC (care acționează ca și data bindgins sau con-verters) în așa fel încât să schimbe informația din formatul modelului în formatul view-ului și să paseze comenzi din view în model. ViewModel-urile expun proprietățile publice, comenzile și abstractizările și au fost asemă-nate cu o stare conceptuală a datelor, spre depsebire de starea reală a datelor din model. Există discuții în ceea ce privește clasa din spatele view-ului. Majoritatea specialiștilor susțin că aceasta ar trebui să conțină doar metoda InitializeComponent() în cazul WPF și Silverlight, însă în anumite cazuri nu se merită mutarea unor metode în viewmodel.

View-ul comunică doar cu ViewModel-ul, în timp ce ViewModel-ul este privit ca un punct intermediar între View și Model. De asemenea, Modelul este singurul care interacționează cu baza de date. Acest model are sens în practică doar dacă se folosește în combinație cu o bază de date. În caz contrar

Orice programator încearcă să fie cât mai ordonat atunci când scrie cod. Fiecare echipă își organizează proiectul în așa fel încât acesta să fie cât mai ușor de întreținut și să poată fi înțeles cu ușurință de membrii noi ai echipei. Această practică poate fi dato-

rată și folosirii design pattern-urilor. Știm că există numeroase astfel de reguli de organizare a codului și că odată aleasă una dintre ele, este greu și costisitor ca aceasta să fie schimbată. Totuși este important ca programatorii să fie la curent cu noile design pattern-uri pentru a putea profita la maxim de avantajele oferite de acestea.

Design pattern-ul MVVM

Andrei [email protected]

Software Developer@ Business Logic Systems Ltd.

arhitectură



obiectele de date precum entitățile din EDMX și Linq nu au logică în acest context. O diagramă a acestui design pattern poate fi observată și in figura de mai jos.

Alte două funcționalități care fac ca acesta să fie atât de des folosit sunt data template-urile și resursele de sistem. Template-urile aplică View-uri asupra obiectelor unui ViewModel. Programatorii pot să le declare în XAML și să lase resur-sele de sistem să localizeze în mod automat iar apoi să aplice acele template-uri la runtime.

Întrucât aceast design pattern poate fi destul de greu de implementat, au fost create câteva platforme care să ajute pro-gramatorii în implementarea lui cum ar fi MVVM Light sau Caliburn. Personal îl recomand pe cel din urmă deoarece oferă avantajul recunoașterii automate a view-ului de către viewmodel, nemaifiind necesară crearea unei clase ajutătoare care să facă acest lucru.

Să luăm un exemplu simplu cu o aplicație care afișează dintr-o bază de date informații despre produse : nume, preț unitar și id. În model va trebui să avem partea de accesare a datelor. Modul în care acestea vor fi accesate rămâne la lati-tudinea programatorului. Această clasă va implementa INotifyPropertyChanged și va conține cele 3 proprietăți, fiecare având pe setter OnPropertyChanged(„Proprietate”) pentru a semnaliza modificarea valo-rii proprietății. Trebuie acordată atenție în mod special numelui proprietății deoarece acesta se transmite ca și string.

ViewModel-ul va conține toată partea de care are nevoie utilizatorul pentru a interacționa cu aplicația. Aici se pot pune sortările, ștergerile din listă sau orice alte operațiuni necesare. În cazul de față doar 2 comenzi, GetProduct și SaveProduct ce vor fi folosite pentru a aduce un obiect din

model în viewmodel și pentru a salva un produs. Acestea sunt de tipul ICommand și au o sintaxă de tipul :

public ICommand SaveProductCommand{ get{ if (_saveProductCommand == null) { _saveProductCommand = new RelayCommand( param => SaveProduct(), param => (CurrentProduct != null)); } return _saveProductCommand; }}

Tot aici apare și clasa RelayCommand, esențială pentru ca MVVM să funcționeze. Aceasta conține o comandă ce va fi execu-tată de alte clase pentru a rula cod în clasa de bază prin invocarea de delegates.

View-ul este partea care definește modul în care va arăta aplicația. De asemenea se vor defini două DataTemplate-uri, unul pentru model și unul pentru viewmodel.

Pentru a porni aplicația mai trebuie adăugate următoarele linii de cod în App.xaml.cs, care crează ViewModel-ul și aso-ciază datacontext-ul ferestrei în viewmodel:

MainWindow app = new MainWindow();ProductViewModel viewModel = new ProductViewModel();

app.DataContext = viewModel;app.Show();

Și totuși când ar trebui să folosim acest model? Deși structura lui este una logică și oferă organizare în cod, acesta nu se pretează pentru orice fel de proiect. Dacă avem de-a face cu un proiect unde nu există o interfață grafică prea complexă nu se prea justifică folosirea MVVM, codul putând fi scris chiar și în code behind. De asemenea unii programatori nu recomandă folosirea acestui pattern dacă nu se dorește realizarea de unit-teste. Întrucât ușurința în scrierea testelor este unul din avantajele acestuia, este de preferat ca acesta să fie folosit doar împreună cu acestea. Este total neproduc-tivă și deci nu este recomandată folosirea unui design pattern într-o aplicație simplă „Hello World!”. Orice dezvoltator software

poate să înțeleagă câteva linii de cod , chiar și dacă sunt scrise dezorganizat. Totuși, pe măsură ce numărul de linii de cod dintr-un program crește, crește și numărul funcționalităților.

Pe lângă dezavantajele amintite mai sus, ar mai fi și faptul că în unele cazuri poate fi dificilă proiectarea viewmodel-ului în așa fel încât să se obțină gradul de generali-tate dorit și de asemenea debug-ul pentru data binding este mai greu de realizat față de metodele clasice care foloseau code behind.

În concluzie MVVM oferă anumite avantaje precum separarea view-ului de logica business și ușurința în scrierea teste-lor unitare, însă programatorii trebuie să fie atenți dacă acest design pattern se pretează sau nu pentru proiectul lor.

arhitecturăDesign pattern-ul MVVM


TODAY SOFTWARE MAGAZINE management

- Îi complex!- Ba nu e complex!- No, ba îi, că avem 12 sisteme de inter-

conectat, dezvoltate pe platforme diferite. Plus că folosim o tehnologie nouă pentru noi...

- Deci e un proiect complicat, nu complex.

Mișu se uită total nedumerit la Gogu. Cumpăni preț de o clipă dacă acesta îl ia peste picior, dar văzând figura serioasă, se limită la a spune, în felul lui molcom:

- Zău, măi Gogule, te iei de cuvinte, complicat, complex, tot aia îi...

Gogu se luă cu mâinile de cap, cum adică să fie tot aia?! Se uită în jur căutând ajutor, dar Șefu’ nu era în zonă. „Cu ce-oi fi greșit, Doamne, de trebuie să le lămuresc eu pe toate?! O să-mi trec în fișa postu-lui : Mama răniților, dă explicații la toți mocofanii, în fiecare zi, în timpul progra-mului și peste, ca fraieru’, fără plată și fără recunoașterea meritelor.” Oftă din toți rărunchii și se aruncă în explicații:

- Nu e tot aia, Mișule, și e bine să cla-rificam. Că de-aia facem management de proiect ca să le știm pe astea și să putem acționa în consecință, să prevenim apariția problemelor. În cazul proiectelor discutăm de doi termeni diferiți: complicat și complex. Atributul de complicat îl primesc proiec-tele în care avem un număr mare de părți sau componente tehnice interconectate,

interdependente. Conexiunile sunt sofis-ticate, avem nevoie de multă atenție în determinarea implicațiilor, avem nevoie de expertiză tehnică considerabilă pentru a putea identifica toate activitatile necesare și a planifica corect un astfel de proiect. Corect?

- Exact. Păi și asta nu înseamnă și complex?

- Nu, doar ce ți-am spus că asta înseamnă complicat. Stai jos și ascultă!

Mișu se așeza imediat și ridica ochii spre Gogu, era numai ochi și urechi.

- Atributul de complex este dat de caracterul de impredictibilitate și este determinat de comportamentul uman. Un proiect complex are – prin definitie – părti și componente care pot interacționa impre-vizibil. Pricepi?

Remarca privirea deloc inteligenta a lui Mișu așa că se redresa imediat:

- Uite niște exemple: lansarea unei rachete spre lună este un proiect complicat, realizarea unui braț de robot care să poată executa operații pe creier, alt exemplu de proiect complicat. Creșterea și educarea unui copil – în schimb – este un demers complex. Acu’ pricepi?

Privirea lui Mișu începea să capete stră-lucire. Da’ tot nu pricepe, gândi Gogu. Cum să-i explic eu ăstuia mai pe înțelesul lui? Mișu dădu glas nedumeririlor:

- No stai. Îi clară treaba cu complicatu’.

Complicat sau complex

Simona Bonghez, [email protected]

Speaker, trainer şi consultant în managementul proiectelor,

Owner al Colors in Projects


Nu trimitem noi oamenii pe lună da’ cele 12 sisteme de legat, plus tehnologia, interfețele..., zicem că ăsta e proiect complicat. Da’ cu complexu’ nu pricep. Ce-avem noi de-a face cu educația copilu-lui?! Asta e ca nuca-n perete – decretă el și se lăsă satisfăcut pe spate. O mișcare total greșită deoarece scaunul cedă neașteptat sub greutatea lui Mișu, iar acesta se trezi întins pe spate pe podea, cu picioarele în aer. Hohotele de râs ale lui Gogu fură declanșate nu atât de poziția hilară cât de grimasa de surpriză totală de pe fața lui Mișu. Îi întinse mâna și îl ridică prietenește.

- Deh, vezi, dacă mă contrazici? Am dat exemplul extrem cu educația doar ca să faci tu un declic mintal, dar văd că te-am dat pe spate! La propriu! Ha-ha... Voiam să subliniez că, spre deose-bire de un proiect complicat, în care granițele proiectului pot fi clar delimitate, în care poți defini ce este în obiectivele proiectului și ce cade în afara obiectivelor acestuia, într-un proiect complex granițele pot deveni permeabile, e posibil ca – pe parcursul proiec-tului – să le redefinești, de mai multe ori, în funcție de implicațiile mediului în care se desfășoară proiectul. Uite un exemplu mai concret: un proiect de schimbare organizațională, în care lucrurile nu sunt complicate deloc, dar în care oamenii reacționează dife-rit, fiecare în funcție de așteptările și de temerile sale. Pot exista piedici incredibile în realizarea proiectului, determinate doar de rezistența la schimbare a personalului din companie. Am văzut într-o lucrare care trata acest subiect o comparație foarte tare: avi-onul era dat exemplu de sistem complicat datorita multitudinii sale de componente, mecanice și eletronice, iar o companie aflată în fața unei posibile restructurări era dată ca exemplu de sistem complex. Și fii atent ce mai ziceau: oamenii încep să reacționeze chiar și la rumoarea unei posibile restructurări, încep să discute, se formează bisericuțe, apar primele puncte de vedere, sistemul deja e în schimbare. Pe când avionul, dacă apare mecanicul cu trusa de scule, cu intenția clară de a interveni în angrenajul avionului, nu va avea nici o reacție. Tare, nu?

Remarcă imediat că se lăsase dus de valul explicațiilor; în jurul lor mai apăruseră câțiva colegi, atrași probabil de căzătura spec-taculoasă a lui Mișu, care ascultau acum cu interes exemplele lui Gogu. Întrebările începură să curgă ca grindina, fiecare dintre ei încercând să catalogheze proiectul în care lucra: era cumva com-plicat sau complex, sau poate ambele.

- Mai dă-ne exemple, Gogule, că nu e foarte clar pentru toată lumea. Și-apoi e preferabil să ai un proiect complicat sau unul complex? Dar dacă e și complicat și complex...

- Mama răniților, mormăi Gogu mai mult pentru el, oarecum încurcat și de faptul că nu prea mai avea exemple. Partea asta cu complexitatea era chiar complexă, sau complicată?! Veni însă și salvarea lui: atras probabil de forfota neobișnuită din birou, își făcu apariția și Șefu’.

- Ce-i aici, fraților? Se împarte ceva gratuit?Gogu dădu să replice, dar se stăpâni; interesul lui era altul

acum, așa că lansă provocarea către Șefu’:- Discutam despre proiecte complicate versus proiecte com-

plexe. Ne ajuți cu vreun exemplu deștept?- Ah, frumos subiect, se entuzismă Șefu’. Așa, ia dă-ți tu ochii

pe spate – gândi Gogu, dar nici prin cap nu-i dădu să-l întrerupă. Șefu’ își lăsă capul puțin într-o parte. Semn de mare concentrare – își continuă Gogu monologul interior, dar era foarte curios de

ce urmare.- Ok, păi vă spun un banc. Complicat versus complex, nu-i

așa?! Uite: un manager de proiect se plimba – își făcea siesta după masa de prânz – pe plajă. Cum mergea el adâncit în gânduri – pla-nifica în minte următoarea întâlnire cu echipa de proiect – dădu cu piciorul în ceva și privind mai atent își dădu seama că e o lampă veche. Ei, că n-oi fi eu ca PM-ul din banc să găsesc duhul din lampă, își zise managerul de proiect, dar se aplecă totuși să ridice obiectul. Și mare îi fu surpriza când, într-adevăr, după ce șterse lampa de nisip, îi apăru în față brusc, cu o pocnitură surdă, un duh. Mă rog, era o arătare ciudată, ca un nor cu forme umane, ca în desene animate. Care îi vorbi: Omule, eu sunt duhul din lampă, bla-bla-bla, probabil știi povestea, zi dorința. Hmm, managerul de proiect era obișnuit să se folosească de orice ocazie, așa că nu stătu mult pe gânduri și-i spuse: Știi, Duhule, eu am un proiect pentru care trebuie să călătoresc permanent între România și Kuwait. Iar zborurile sunt în special zboruri de noapte, mă seacă de puteri, nemaivorbind despre controlul de securitate, așteptarea în aero-port, recuperarea bagajelor... Într-un cuvânt, mi-ar plăcea să am la dispoziție o autostradă suspendată, de-aici și pănâ în Kuwait. Duhul se gândi puțin – probabil vizualiza harta - apoi zise: Măi, ce-mi ceri tu e complicat rău, distanța e enormă, trecem peste continente, avem și mări de traversat, nimeni nu ar putea face o autostradă suspendată pe o asemenea distanță. Altă dorință n-ai? Ușor nemulțumit de calitatea duhului întâlnit, managerul nostr de proiect își mai încercă norocul cu o a doua dorință: Bine, Duhule, ce zici de asta: îmi doresc pe proiectul pe care lucrez, cele șase organizații implicate să conlucreze, să stabilească toate cerințele împreună, să se înțeleagă asupra lor și să nu le schimbe până la sfârșitul proiectului. Duhul căzu puțin pe gânduri, apoi îl întrebă: Auzi, și câte benzi să aibă autostrada aia?

Complicat sau complexmanagement

powered by

sponsori

Comunicăm mai simplu direct prin SMS.Propune un titlu de articol pentru numărul următorsau trimite-ne sugestiile tale.

SMS 0371700018număr cu tarif normal

[Title will be auto-generated]

Documents

Transcript of [Title will be auto-generated]