TSM_8_2013_ro

No. 8 • Februarie 2013 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

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

Educație.Antreprenoriat.

StartupWeekend Provocările unui lider - partea I Istoria IT-ului Clujean (III) Particularităţi ale proiectelor informatice Omniprezența aplicabilității în ecosistemul personal Probleme arhitecturale în proiecte Liferay SEO local prin intermediul Google+ Puncte de scalabilitate pe “cloud” In-Memory Database - Platforma real-time SAP HANA Code review Recenzie carte: Java Persistence with JPA

Managementul echipei Lansarea unui site web - paşii de bază Startup cu bani puțini (II) - Microsoft Bizspark Ecosistemul tech-startups din Cluj Managementul de personal in domeniul SAP Gogu

6 Educatie.Antreprenoriat.

StartupWeekend Echipa Startup Weekend

7 Provocările unui lider - partea I Martin Mackay

9 Istoria IT-ului Clujean (III) Marius Mornea

11 Particularităţi ale proiectelor informatice Dan Suciu

14 Omniprezenta aplicabilitătii în ecosistemul personal Bogdan Nastasa

17 Probleme arhitecturale în proiecte Liferay Alexandra Coldea

20 SEO local prin intermediul Google+ Radu Popescu

22 Puncte de scalabilitate pe “cloud” Radu Vunvulea

25 In-Memory Database Platforma real-time SAP HANA Horea Rațiu Victor Ionescu

28 Code review Mădălin Ilie

32 Recenzie carte: Java Persistence with JPA Silviu Dumitrescu

34 Managementul echipei Andreea Pârvu

36 Lansarea unui site web - paşii de bază Attila-Mihaly Balazs

38 Startup cu bani putini (II) - Microsoft Bizspark Dragoș Andronic

39 Ecosistemul tech-startups din Cluj Mircea Vădan

40 Managementul de personal in domeniul SAP Oana Oprean

41 Gogu Gogu si vaca lui sefu’ Simona Bonghez, Ph.D.

editorial

Salut,

Ovidiu Măţan, PMP

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

Mă bucur că am ajuns la numărul 8 TSM. Îmi amintesc cum, anul trecut pe aceeași vreme pregăteam primul număr cu ajutorul prietenilor și a câtorva cunoscuți. Rugămintea pentru fiecare era să scrie un articol profesionist, în același mod în care cineva ar preda în fața unei clase. Nu a fost un lucru simplu pentru că necesita ieșirea din acea comoditate a week-end-ului și sintetizarea unor idei în așa fel încât cititorul să rămână cu o lecție învățată și poate cu dorința de a-l contacta pe autor pentru mai multe detalii. Nu a fost cazul :). Feedback-ul a fost minim, chiar inexistent, de multe ori rugându-ne de prieteni să ne trimită un feedback; aveam atunci mailing list-ul de vreo sută de persoane al lui Marius. Practic toate acestea ne duc pe partea de educație, de cultura de a face soft, de modul de interacțiune într-o comunitate, de înțelegere că implicarea și feedback-ul fie pozitiv sau negativ aduce valoare. Putem să ne mândrim cu câțiva autori care au scris în multe numere din TSM: Radu Popescu - seria de articole SEO, Simona Bonghez întâmplările lui Gogu, Radu Vunvulea - tehnologii Microsoft, Andreea Pârvu - HR, Tavi Bolog - Java/Agile/Ruby, Marius Mornea - startups/seria Istoria IT-ului Clujean, Mihai Nadăș - SAAS, Andrei Avădănei - seria de articole despre securitate, Attila Balazs - Java/ Php/Good practices. Alături de ei sunt mulți autori aflați la primul articol, iar acest lucru este benefic pentru comunitatea cărora li-i se adresează tocmai din ideea începerii unui dialog. Vom continua să promovăm toate acestea și prin noul site căruia încercăm să-i dăm drumul în curând. Noutatea va fi o interacțiune mai bună între autori și cititori, posibilitatea de a-i urma, design-ul responsive adaptat pentru desktop cât și tablete sau telefoane, posibilitatea de a trimite trimite direct un articol online pentru ca în urma unui review să poate fi publicat în cel mai scurt timp. Idealul este un concept de Pinterest ce conține articole tehnice în loc de poze iar la finalul fiecărei luni cele mai bune articole vor fi publicate în revistă. Un feature la care se lucrează în paralel este punerea revistei în format tipărit la dispoziția celor care nu pot să vina la evenimentul de lansare sau la altele unde TSM este prezent. Acesta va fi realizat prin integrarea cu un sistem de ePayment iar livrarea se va face prin Poșta Română. În lista de noi servicii rămâne publicarea revistei în Apple Newstand. O altă noutate este apariția lunară a revistei.

Numărul 8 cuprinde o serie de articole interesante dintre care menționez, Provocările unui leader scrisă de către CEO-ul Neverfail, Martin Mackay, care prezintă direcțiile pe care conducătorul unei companii trebuie să le aibă în vedere. Particularitățile proiectelor informatice ne arată diferența dintre un proiect clasic și unul software, printre care și posibilitatea de a întârzia un proiect în loc de a crește în cazul în care se adaugă resurse în timpul execuției. Omniprezența aplicabilității în ecosistemul personal ne prezină modul în care trebuie abordate proiectele de UIX. Continuăm cu un articol ce prezintă problemele arhitecturale din proiecte Liferay. SEO prin Google+ este foarte practic în acest număr și prezintă un aspect important pentru orice business local. Cum să facem util Code Review, ce ar trebui să urmărească developer-ul care scrie codul precum și cel care face reviewul sunt subiecte dezbătute pe larg. De asemenea, pornim o serie de articole de recenzie de cărți care debutează în acest număr cu: Java Persistence with JPA. Din aria HR-ului Managementul echipei abordat într-o manieră schematică și Managementul de personal în domeniul SAP. Startup-urile sau crearea acestora sunt stimulate de invitația la evenimentului Startup Week-end Cluj, Lansarea unui site web și prezentarea ecosistemului de tech-startups din Cluj.

Vă dorim o lectură plăcută!

Ovidiu Măţan

Fondator și CEO al Today Software Magazine

4

nr. 8/2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Redacţia Today Software Magazine Fondator / Editor in chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com

Lista autorilor Martin Mackay

Attila-Mihaly Balazs

CEO @ Neverfail Group.

Code Wrangler @ Udacity Trainer @ Tora Trading

mmackay@neverfailgroup.com

dify.ltd@gmail.com

Editor (startups și interviuri): Marius Mornea marius.mornea@todaysoftmag.com Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com Colaborator marketing: Ioana Fane ioana.fane@todaysoftmag.com Colaborator social media: Rodica Manolache rodica.manolache@todaysoftmag.com Traducător: Cintia Damian cintia.damian@todaysoftmag.com

Dan Suciu

Andreea Pârvu

Director of Delivery @ 3Pillar Global

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

andreea.parvu@endava.com

dan.suciu@3pillarglobal.com

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

Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com

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

Today Software Solutions SRL str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag ISSN 2284 – 6352

Speaker, trainer şi consultant în managementul proiectelor,

Dragoș Andronic dragos@txtfeedback.net

Java discipline lead @ Endava

CTO @ TXTFeedback

Alexandra Coldea

Horea Rațiu

Java Developer @ ISDC

Director Departament SAP @ .msg systems Romania

Radu Popescu

Victor Ionescu

alexandra.coldea@isdc.eu

horea.ratiu@msg-systems.com

rpopescu@smallfootprint.com

Bogdan Nastasa UX/UI Design Lead @ Endava

victor.ionescu@msg-systems.com SAP IT Consultant @ .msg systems Romania

Mircea Vădan mircea.vadan@gmail.com

Bogdan.Nastasa@endava.com

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

Simona.bonghez@confucius.ro

Mădălin Ilie

QA şi Web designer @ Small Footprint

Copyright Today Software Magazine

Simona Bonghez, Ph.D.

Owner al Confucius Consulting

Madalin.Ilie@endava.com

Produs de

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

Marius Mornea

Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com

Radu Vunvulea

Co-fondator și coordonator @ Use Together

Oana Oprean oana.oprean@msg-systems.com Center of Competence Manager @ .msg systems Romania

www.todaysoftmag.ro www.todaysoftmag.com

www.todaysoftmag.ro | nr. 8/2013

5

startup

Educație.Antreprenoriat.StartupWeekend Educație

Sub presiunea globală a mișcării startup-urilor și după modelul american, România a intrat și ea de ceva timp în rândul țărilor care promovează pe scară largă educația antreprenorială. Materializată în conferințe și evenimente dedicate startup-urilor, precum și în cursuri teoretice predate elevilor și studenților, promovarea nu aduce totuși efectele scontate.

Sergiu Biriș susține că direcția adoptată este una bună, deși tot el afirmă: „Facem pași importanți prin evenimente și conferințe, însă din păcate nouă ne lipsește și educația antreprenorială pe care ar trebui să o primim de acasă. Suntem crescuți să fim buni angajați, nu antreprenori.”

Antreprenoriat

Pentru a susține formarea unui mediu propice dezvoltării indutriei IT și respectiv a antreprenoriatului informatic, în anul 2012 s-a înființat în Cluj Napoca, IT Cluster. Aceasta este o dovadă a faptului că mediul clujean este unul propice implementării proiectelor de o anvergură comparabilă cu Sillicon Valley.

După cum susține și Marius Ghenea, ceea ce ne lipsește nouă sunt modelele antreprenoriale, oamenii de succes care să fi dovedit că se poate și în România să construim afaceri de milioane de Euro. Și dacă pentru unii acesta este un lucru negativ (lipsa de modele), noi considerăm că acesta ar trebui să fie primul imbold, și cel mai mare de a reuși – dorința de a demonstra că se poate și la noi exact la fel ca și în Sillicon Valley.

6

Startup Weekend

ingredient al unei afaceri de succes, unde Startup Weekend, parte integrantă echipa valorează la fel de mult ca și vizia Kaufman Foundation este una dintre unea, iar mentorii sunt acolo ca să indice mișcările cele mai ample la nivel mondial direcții. care încearcă să ofere participanților săi un mediu de dezvoltare și optimizare a calităților antreprenoriale. Dacă în sălile de Echipa curs, antreprenoriatul rămâne la un nivel Startup Weekend mai mult sau mai puțin teoretic, aici sunt cluj@startupweekend.org reproduse la o scară mica toate condițiile reale ale mediului de afaceri – concurență, presiune, echipă, investitori și piața reală.

Cunoștințele teoretice pe care le găsești aici sunt oferite de mentori a căror școală a fost propria lor afacere și a căror diplomă o reprezintă succesul însuși. Întrebată despre mediul antreprenorial din România , Karen E. Willson, unul dintre membrii consiliului Kaufman Foundation, s-a aratăt plăcut surprinsă la cât de repede evoluează mediul antreprenorial de aici : „Oamenii au început să conștientizeze cât de multe oportunități au prin antreprenoriat și inovație.”

Adunând într-un singur loc Educația și Antreprenoriatul, Startup Weekend formează oamenii de afaceri de mâine, acolo unde ideea nu este cel mai important

nr. 8/2013 | www.todaysoftmag.ro

business

TODAY SOFTWARE MAGAZINE

Provocarile unui lider - partea I

C

ând un nou lider este numit pentru o organizație, schimbarea are loc aproape invariabil, deoarece Consiliul de Administrație a stabilit că acest lucru este necesar pentru a îndeplini potențialul companiei. Aici, în primul dintr-o serie de trei articole, Martin Mackay, recent numit în funcția de CEO al Grupului Neverfail, explorează un cadru pe care il utilizează pentru a răspunde la provocarea schimbărilor de conducere. Al doilea articol va discuta mai în detaliu cele cinci responsabilități-cheie pe care un lider trebuie să le recunoască și ultimul articol va revizui cele șapte comportamente pe care un lider trebuie să le dezvolte.

Așteptările de la un nou lider sunt mari. Toate părțile interesate doresc să vadă schimbări rapide, îmbunătățirea perspectivelor de afaceri și rezultate pe termen scurt. Consiliul care a făcut modificarea vrea să nu dea gres în alegerea sa. Angajatii vor să înțeleagă ce va aduce noul CEO in companie pentru a justifica schimbarea efectuată la nivelul înalt, și, bineînțeles, să înțeleagă foarte repede ce impact va avea asupra lor ca indivizi. Echipa de conducere se va simți aproape sigur incomod și în potențial pericol ( și va avea, probabil, resentimente față de noua sosire). Clienții și partenerii cheie de afaceri pot fi implicați în potentiale revolte provocate de schimbare, în special în cazul în care celor din interiorul procesului li se pare a fi bruscă sau chiar nejustificata. Un clișeu spune că ai doar o singură șansă de a face o prima impresie, dar un clișeu este doar numit ca atare, deoarece este un truism de multe ori repetat. Prin urmare, odata cu sosirea, noul lider trebuie să își stabilească foarte curând, propriul plan de organizare pentru a avea succes. În cele din urmă, importanța este încrederea pe care liderul o poate inspira angajaților care vor determina modul în care mandatul său este validat.

Angajații vor să creadă în viitorul organizației, deoarece aceștia doresc să lucreze pentru o companie de succes - în cazul în care lucrează pentru o companie de succes se vor simți bine cu ei înșiși, vor lucra din greu și cu un angajament crescut; în cele din urmă succesul se va construi pe succes într-un cerc virtuos. Pentru ca angajații să creadă în viitorul organizației au nevoie mai întâi să aibă încredere în liderul lor. Pentru a inspira încredere angajaților, liderul trebuie să fie capabili să creeze planul pentru succes.

E x i s t ă , d e s i g u r, mu lte m o du r i diferite în care un lider poate stabili credibilitatea și aborda procesul de planificare

a schimbării. Comportamentele necesare în vederea stabilirii autenticității, care sta la baza conceptului de leadership de succes, vor fi examinate în ultimul articol din aceasta serie. Aici am stabilit cele cinci componente cheie pentru un astfel de plan, care să funcționeze pe baza experienței mele și pe care le punem în practică, la Neverfail.

Primul pas este de a stabili o viziune pentru afaceri. Imediat conceptul de viziune poate avea un efect foarte negativ dacă ne gândim la afirmații fără sens pline de buzzwords sau ne aducem aminte de dezbateri sterile despre nevoia unei declarații de viziune, a unei declarații de misiune sau ambele și care este diferența dintre cele două. În cele din urmă, viziunea pentru afaceri este critica, deoarece inspiră sens și scop; cu sensul și scopul înglobate în psihicul angajaților angajamentul lor în activitate crește semnificativ și, așa cum am afirmat, implicarea angajatului stă la baza oricărei afaceri de succes. Este o poveste a a doi zidari care lucrau pe un santier. Un vizitatori îl întreabă pe unul dintre ei: „Ce faci?” Acesta raspunde „Cioplesc această bucată de piatră în forma potrivită, astfel va încăpea în peretele ăla de acolo”. Vizitatorul pune aceeași întrebare și celui de-al doilea si el răspunde: „Eu construiesc o catedrală”.

Ce trebuie să facă un lider de succes este să îi inspire pe toți angajații să creadă că sunt parte dintr-o echipa în construirea unei catedrale și, pentru a face acest lucru, are nevoie de o viziune clară a afacerii.

Acest lucru nu ar trebui să fie stabilit în termeni financiari (deși, așa cum vom vedea rezultatele sunt cruciale), ci în termeni mai largi pentru a oferi companiei scopul și direcția, care pot provoca si inspira. În al doilea articol, vom explora modul în care am pus în practică aceasta provocare, la Neverfail.

Al doilea pas este de a defini strategia,

care va ghida activitatea spre realizarea viziunii. Aceasta este, probabil, elementul cel mai important dintre toate: pentru ca viziunea să fie inspiratională,aceasta trebuie să fie atât aspirațională, cât și realizabilă. Pentru a fi realizabilă, trebuie să existe o cale clar definită. Strategia de afaceri este calea clară.

Strategia are în esență trei teme: inovare, intimitatea clientului și excelența o p e r aț i o n a l ă . L i d e r u l t r e b u i e s ă explice modul în care aceste trei teme interacționează, măsurile generale care vor fi luate pe baza acestor teme și modul în care progresele vor fi măsurate. De exemplu, la Neverfail ne-am stabilit strategia noastră de inovare bazata atât pe dezvoltarea produselor noastre și pe îmbunătățirea proceselor interne; am pus intimitatea clientului in centrul afacerii noastre, astfel că planurile noastre de produse sunt stabilite pe baza cererilor clientului (și a pieței), mai degrabă decât o viziune introspectiva; iar procesele noastre sunt remodelate pentru a crea ceea ce noi numim experiență memorabila cu clientul; excelență noastra operațională (în termeni de raportare și măsurare și procese eficiente de backoffice) este deja mare, dar ne concentrăm pe îmbunătățirea acesteia prin introducerea unui nou sistem complet de management al performantei în cadrul companiei, care ne va ajuta să gestionam și să mentinem talentul nostru.

Al treilea pas pe care liderul trebuie să îl facă este de a construi încrederea internă în companie în randul angajaților (și ale altor părți interesate, inclusiv Consiliul). O mare parte din aceasta vine de la comportamentele expuse de lider (și, în al treilea articol din această serie, vom explora aceste comportamente mai în detaliu). Comportamentul cel mai important pe care liderul trebuie să il adopte este autenticitatea. Acest lucru este absolut fundamental, pentru că un lider autentic www.todaysoftmag.ro | nr. 8/2013

7

business

este de încredere, iar încrederea înseamnă implicarea angajaților. Se spune că nu poți “mima sinceritatea” – lipsa unei astfel de autenticități va fi imediat evidentă pentru angajați. Liderul autentic comunică în mod regulat prin canale multiple de mass-media (în Neverfail vom folosi e-mail, Chatter instrumentul de la Salesforce.com - precum și întâlniri periodice în locațiile noastre diferite și întâlniri one-to-one) și comunică în mod constant și cu claritate.

Modelul tradițional al abordării ierarhice de comandă și control nu va fi suficient în lumea de astăzi, angajații sunt mult mai exigenti și nu vor răspunde doar la cererile șefului. În esență, aceștia sunt în căutarea a două lucruri de la liderul lor: ei doresc claritate în ceea ce privește așteptările, performanțele companiei și direcția viitoare și doresc să se simtă ca făcând parte din companie, astfel încât este sa fie evident pentru ei că rolul pe care îl joacă și munca pe care o depun sunt în mod clar relevante pentru îndeplinirea viziunii. În cazul în care liderul poate livra aceste două elemente angajatilor in mediul lor de lucru, atunci va apărea si încrederea internă.

Pentru a echilibra nevoia de încredere internă am ajuns la a patra etapă a procesul de gestionare a schimbărilor de succes: dezvoltarea încrederii externe. Încrederea externă este modul în care piața monetară (clienți, parteneri, analiști și observatori din industrie) vizualizează compania. Proiecția

8

cea mai evidentă a imaginii companiei pe piață este prin intermediul site-ului, dar merge dincolo de aceasta. Este de fapt imaginea pe care compania o are față de partenerii de afaceri, analiștii și, cel mai crucial, cu clienții. Vânzarea bazată pe referințe nu este un concept nou, dar în mod sigur o recomandare venită din partea colegilor într-o organizație este o unealtă generatoare de cereri, mult mai eficientă decât orice campanie de marketing. De obicei aceasta recomandare va veni dintr-o experiență de neuitat cu clientul, în care imaginea companiei și realitatea experienței se potrivesc. La Neverfail am stabilit standarde ridicate cu numele nostru! Trebuie să ne asigurăm că numele nostru se ridică la nivelul așteptărilor, astfel încât aplicatiile critice de business ale clientilor nostri să nu dea greș niciodată.

Deci, cu viziune, strategie, încrederea internă și externă stabilită, am ajuns la elementul final al arhitecturii noastre: rezultatele financiare. Rezultatele financiare sunt absolut cruciale, deoarece acestea sunt o dovadă obiectivă a succesului planului nostru. Cu toate acestea, ceea ce de se întâmplă de obicei este că presiunea din partea acționarilor externi și a Consiliul face ca majoritatea liderilor să se concentreze pe acest lucru și profitul pe termen scurt să devină prioritar, in dauna valorilor cheie construite pe termen lung, care vin din implicarea angajaților și experiențele de

nr. 8/2013 | www.todaysoftmag.ro

neuitat ale clienților. La Neverfail abordarea noastră este clară: avem măsurarea riguroasă a performanțelor noastre financiare și ne impunem să lucrăm în conformitate cu planul nostru. Cu toate acestea, credem că vom face acest lucru, ca urmare a punerii în aplicare a primelor patru elemente ale cadrului. Prin urmare, în timp ce performanța financiară este indicatorul nostru de bază, ne vom concentra pe atingerea obiectivelor noastre, asigurându-ne că avem viziune, strategie și încredere din partea tuturor celor interesati.

Deci, procesul în cinci pași de stabilire a unei viziuni, definire a unei strategii, construire a încrederii interne și externe și măsurarea necontenită a progresului prin rezultatele financiare reprezintă un model pentru noul lider de a opera cu schimbarea. Evoluția viitoare în gestionarea schimbărilor de conducere stă în a înțelege responsabilitățile cheie pe care liderul le are; acest lucru va fi subiectul celui de-al doilea articol din această serie.

Martin Mackay

mmackay@neverfailgroup.com CEO @ Neverfail Group.

istorie

Istoria IT-ului Clujean (III) Fondator vs. Pionieri

O

întrebare importantă pentru orice istorie este: cum a început totul? Din păcate, rareori se poate da un răspuns punctual și exact, pentru că istoria are tendința să fie, mai degrabă o desfășurare continuă de evenimente și influențe, de perspective subiective și istorii mai mici și paralele. Pentru IT-ul clujean lucrurile stau în mare măsură la fel.

Am ales ca și punct de pornire eforturile lui Tiberiu Popoviciu, matematician de renume, care în 1957 fondează la Cluj, Institutul de Calcul, o redenumire dată secției de matematică a filialei Academiei Române la Cluj, (prima fondată tot de T. Popoviciu în 1951, iar a doua de către Emil Petrovici în 1948).

De ce am ales 1957? pentru că atunci apare pentru prima dată termenul de Departament de Calculatoare.

Departament prolific, care la doar doi ani de la înființare construiește primul calculator cu relee MARICA (1959), urmat de DACCIC-1 (1963) cu tuburi electronice și tranzistori, iar în 1968 calculatorul DACCIC-200 complet tranzistorizat. Există și certe preocupări didactice, astfel încât T. Popoviciu predă primele cursuri de Limbaje de programare și Mașini de Calcul din țară. Cu toate acestea, la nivel național, Bucureștiul și Timișoara au un ușor avans, iar realizările lui Victor Toma, de la Institutul de Fizică Atomică BucureștiMăgurele, au pus România pe locul 11 mondial în ierarhia țărilor cu dezvoltare în domeniul IT. Din păcate, în 1975, institutul este transferat de sub tutela academiei, fiind preluat de Ministerul Educației Naționale, care reduce numărul de cercetători de la 48 la 6. Acest an va aduce și o pierdere importantă, decesul lui Tiberiu Popoviciu la doar 6 luni de la transferul institutului.

Odată cu activitatea lui T. Popoviciu, axată în mod special pe cercetare, predilecție moștenită de la o puternică mișcare a matematicienilor clujeni de la 1920, condusa de Petre Sergescu; în anii 1960 intră în scenă și institutele de învățământ superior cu rol de formatori

9

și promotori ai IT-ului clujean. În cadrul Institutului Politehnic din Cluj (actuala UTCN), se remarcă eforturile profesorului Liviu Mănduc, care fondează Facultatea de Electromecanică în 1960 și Electrotehnică în1964, iar în 1965 îl numește pe Marius Hăngănuț, profesor de Automatică.

Această numire implică un parteneriat cu un alt actor important, Institutul de Fizică Atomică din Cluj (devenit ITIM în 1977 și INCDTIM în 1999), filială a IFA București condus de Victor Toma. Această alianță a cercetării cu educația, duce la o dezvoltare imediată și accelerată a celei din urmă.

Merită menționat că anul 1965 este și un punct de bifurcație a istoriei IT-ului clujean. Apar două perspective diferite: una a departamentului de Știința Calculatoarelor și una a celui de Automatică. Primul este condus de Ioan Dancea cu al său colectiv format din K. Pusztai, I. A. Leția, O. Negru și I. Ignat, iar al doilea este condus de M. Hăngănuț, împreună cu T. Coloși, C. Feștilă, etc. Segregarea se păstrează și la nivel de colaboratori, primii alegând ITC pentru derularea proiectelor comune, pe când cei de la Automatică întăresc legătura cu Bucureștiul prin IFA și IPA (Institutul de Cercetare în Automatică). Perspectiva asupra educației este completată în anul 1975 odată cu intrarea în scena a UBB Cluj, prin înființarea Centrului de Calcul, condus de G. Moldovean și L. Țâmbulea. Urmează în 1994 redenumirea facultății de matematică la Facultatea de Matematică și Informatică, datorită includerii de specializări dedicate IT. În continuare educația, atât la nivel superior, cât și prin formarea unui liceu tehnic (la propunerea M. Hăngănuț), va prelua rolul de motor al IT-ului clujean

nr. 8/2013 | www.todaysoftmag.ro

până la apariția pieței private în anii 90 și intrarea în perioada „contemporană”.

După cum se vede în cele de mai sus, nu există o singură inițiativă fondatoare a IT-ului clujean, atât datorită predilecției unora către cercetare și a altora spre educație, a unora spre matematică, a altora spre automatică sau știința calculatoarelor, dar și datorită influentelor politice, administrative și alianțelor cu diferite institute de cercetare și educație locale sau naționale. În acest peisaj fragmentat am să îmi permit să renunț la orice tentativă de ierarhizare și îi numesc pionieri, pe toți cei care au contribuit la nașterea și dezvoltarea IT-ului în Cluj, și am să îi privesc ca parte integrantă a aceluiași ecosistem, colaborând direct sau indirect, fiecare reușind să construiască peste ce au făcut cei dinaintea lor, să completeze inițiativele existente și să umple golurile lăsate de schimbarea generațiilor sau modificări administrative și politice.

Succesul actual se datorează acestui mixt între contribuțiile individuale de excepție a câtorva pionieri și inerția pe care au reușit să o imprime celor din jur.

O lecție care poate fi aplicată și acum, în peisajul antreprenorial fragmentat, în care cei cu succes trebuie să înțeleagă nevoia susținerii comunității locale pentru a crea un moment de inerție similar.

Marius Mornea

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

comunități

TODAY SOFTWARE MAGAZINE

Comunităţi IT Cluj-Napoca

A

m să continui inițiativa de numărul trecut și, în loc să discut despre criteriile de ordonare a comunităților de mai jos, am să vorbesc despre ce mă bucură în peisajul local. În acest număr este vorba de OpenConnect, atât ca eveniment, dar mai mult prin atitudinea și viziunea organizatorilor (Mircea, Victor, Florin, etc.). Aceștia îmbină entuziasmul cu spiritul critic, competiția cu construirea pe fundațiile existente și propun tot timpul colaborarea ca element esențial în maturizarea și coagularea inițiativelor disparate într-o formulă capabilă de acțiune, nu doar de discuții și polemici. Deși am mai vorbit toți, chiar și eu, de multe ori, de o reunire a eforturilor și întâlniri între liderii comunităților locale pentru a construi o agendă comună, de când cu efortul concertat al celor de la OpenConnect lucrurile par mai aproape de a se împlini. Evident că punctul lor forte: tinerețea, prin avântul care îi animă, este și punctul lor slab, pentru că nu au încă experiența și constanța care să îi sprijine, dar tocmai de aceea vă rog să îi ajutați și susțineți prin experiența voastră și deschiderea spre colaborare.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java.

Website: http://www.transylvania-jug.org/ Data înfiinţării: 15.05.2008 / Nr. Membri: 518 / Nr. Evenimente: 40 Romanian Testing Community Comunitate dedicată QA. Website: http://www.romaniatesting.ro Data înfiinţării: 10.05.2011 / Nr. Membri: 560 / Nr. Evenimente: 1 GeekMeet Cluj Comunitate dedicată tehnologiilor web.

Website: http://geekmeet.ro/ Data înfiinţării: 10.06.2006 / Nr. Membri: 522 / Nr. Evenimente: 13 (Cluj) Cluj.rb Comunitate dedicată tehnologiilor Ruby.

Website: http://www.meetup.com/cluj-rb/ Data înfiinţării: 25.08.2010 / Nr. Membri: 130 / Nr. Evenimente: 31

Calendar Februarie 6 Monthly Meetup http://www.meetup.com/Tabara-de-Testare-Cluj/ Martie 1-3 Startup Weekend - Recomandat TSM http://cluj.startupweekend.org/ Joi/săptămânal OpenConnect http://www.facebook.com/groups/355893314491424/ Miercuri/bilunar OpenCoffee http://www.facebook.com/opencoffeecluj

The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software.

Website: http://www.agileworks.ro Data înfiinţării: 04.10.2010 / Nr. Membri: 293 / Nr. Evenimente: 17 Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice.

Website: http://www.meetup.com/Cluj-Semantic-WEB/ Data înfiinţării: 08.05.2010 / Nr. Membri: 136/ Nr. Evenimente: 19

Tabara de testare Comunitate dedicată QA. Website: http://www.meetup.com/Tabara-de-Testare-Cluj/ Data înfiinţării: 15.01.2012/Nr. Membri: 133/ Nr. Evenimente: 10

Romanian Association for Better Software Comunitate dedicata oamenilor cu experienta din IT indiferent de tehnologie sau specializare.

Website: http://www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 193/ Nr. Evenimente: 11 Menţiuni: Cluj Perl Mongers (www.cluj.pm), ITSpark (http:// itspark.ro/default.aspx), CodeCamp (http://www.codecamp.

Comunitatea TSM ro/), Cluj Mobile Developers (http://www.meetup.com/ClujComunitate construita in jurul revistei Today Software Magazine. Mobile-Developers/), CodExpert (http://www.codexpert.ro/), Website: http://www.todaysoftmag.ro PHPRomania (http://www.phpromania.net/), ARIES (http:// Data înfiinţării: 06.02.2012 / Nr. Membri: 389 / Nr. Evenimente: 5 www.aries.ro/). www.todaysoftmag.ro | nr. 8/2013

10

programare

TODAY SOFTWARE MAGAZINE

Particularităţi ale proiectelor informatice

U

nul dintre primele lucruri pe care le afli atunci când citeşti un articol sau o carte despre gestiunea proiectelor din IT este acela că proiectele informatice se deosebesc foarte mult de toate celelalte proiecte. Chiar și atunci când subiectul principal este legat de gestiunea proiectelor în general, se fac referiri directe cu privire la ineficienţa anumitor metode atunci când avem de-a face cu proiecte software. Din păcate nu este întotdeauna explicat în ce costau acele deosebiri şi se insistă mai degrabă pe a descrie soluţii, mai mult sau mai puţin eficiente. Articolul de faţă îsi propune să evidenţieze şi analizeze principalele aspecte caracteristice proiectelor informatice.

Dan Suciu

dan.suciu@3pillarglobal.com Director of Delivery @ 3Pillar Global

Unul dintre cele mai intens citate rapoarte statistice cu privire la succesul proiectelor informatice este Standish Group Chaos Report, care an de an publică rezultate procentuale ce evidenţiază ponderea proiectelor finalizate cu succes, a celor eşuate precum şi a celor care au întâmpinat dificultăţi majore până la finalizare.

Criteriile care stau la baza acestui raport sunt foarte simple şi se referă ca scop, timp şi bani, sau mai precis la: • respectarea şi implementarea cerinţelor specificate, • încadrarea în bugetul estimat iniţial şi • respectarea termenelor de livrare agreate.

Proiectele de succes erau considerate acelea care respectau cu brio toate aceste criterii, cele eşuate erau cele care se stopau fără a mai fi finalizate din cauza nerespectării unuia sau mai multor criterii, iar cele finalizate reprezentau proiectele care au fost până la urmă terminate, rezultatul proiectelor fiind implementat cu condiția reevaluări și ajustării în mode semnificativ a unora dintre criterii.

Tabelul următor prezintă câteva dintre rezultatele raportului de-a lungul timpului, începând cu rezultatul “şocant” din 1994, ce relevă o rată de succes extrem de scăzută, şi până aproape de zilele noastre. Şi această statistică vine să confirme existenţa unei diferenţe evidente între proiectele informatice şi celelalte proiecte, un procent

de eşec de 20-30% fiind de neconceput în vreunul dintre celelalte domenii, de la cel al construcţiilor de clădiri sau maşini până la servicii medicale.

An

Succes

Finalizat

Eşec

1996

27%

33%

40%

1994 1998 2000 2002 2004 2007 2009

16% 26% 28% 34% 29% 35% 32%

53% 46% 49% 51% 53% 46% 44%

31% 28% 23% 15% 18% 19% 24%

Desigur că se poate discuta mult pe marginea acestor statistici şi a relevanţei lor. Pentru că “proiect informatic” este un termen care acoperă un spectru destul de larg şi eterogen de proiecte, e neclar ce fel de proiecte au fost luate în considerare. Între anii 1994 şi 2000 de exemplu, s-au studiat în jur de 30000 de proiecte informatice doar din Statele Unite ale Americii.

Pentru 2004 raportul precizează că au fost luate în considerare peste 50000 de proiecte din întreaga lume (58% SUA, 27% Europa, 15% rest), cei de la Standish Group International asigurându-ne că s-a respectat un echilibru între numărul proiectelor mici, medii şi mari. În altă ordine de idei, este destul de restrictiv să măsurăm succesul unui proiect luând în considerare doar criteriile scop, timp şi ban. Calitatea produsului sau www.todaysoftmag.ro | nr. 8/2013

11

programare a serviciului rezultat reprezintă la rândul său un criteriu important. De asemenea, există proiecte care nu au respectat cele trei criterii, dar care au fost considerate de către organizaţiile în care s-au desfăşurat ca fiind de mare success pentru că au atras ulterior noi proiecte importante, după cum există şi proiecte ce au excelat în toate cele trei direcţii însă presiunea exercitată a făcut ca echipa de proiect să se destrame rapid după terminarea proiectului pierzându-se experienţa şi expertiza câştigată în domeniul proiectului respectiv.

După cum se poate observa şi din graficul următor, în 2012 raportul vine cu informaţii agregate pe diferite tipuri de metodologii utilizate în gestionarea proiectelor. Aşa cum era de aşteptat, metodologiile Agile ameliorează simţitor numărul de proiecte eşuate, însă ele nu pot fi aplicate cu success pentru toate tipurile

de proiecte informatice.

Dar ne-am îndepărtat destul de mult de scopul declarat al articolului. Ce am dorit să subliniem până la acest punct este doar că există diferenţe notabile între proiectele informatice şi celelalte tipuri de proiecte şi că aceste diferenţe par a influenţa negativ succesul acestora. În cele ce urmează le vom descrie pe cele mai importante.

1. Softul este nemăsurabil

Din fericire sau din păcate (în funcţie de perspectiva din care privim lucrurile), activitatea de dezvoltare a softului este una creativă. Nu există, aşa cum se întâmplă în cazul altor activităţi, un nomenclator care să precizeze care este timpul uzual necesar pentru implementarea unei ferestre ce conţine, să zicem, două liste derulante, un grid şi două butoane. În ciuda dezvoltării de instrumente sofisticate de generare automată a codului sau de implementarea diverselor biblioteci de clase sau framework-uri, fiecare proiect nou vine cu provocările proprii în ceea ce priveşte creativitatea.

Un exemplu edificator în acest sens este dat în cartea “The Healthy Software Project: a guide to successful development”, (1993,

12

nr. 8/2013 | www.todaysoftmag.ro

autori M. Norris, P. Rigby, M. Payne) care ce vede este în general o interfaţă grafică face un experiment chestionând un număr cu utilizatorul. de 44 de experţi în legătură cu numărul de Deoarece nu există nimic concret de instrucţiuni care apar în codul de mai jos: arătat clientului în faza de analiză a cerin#define LOWER 0 ţelor, acesta îşi formează o imagine proprie #define UPPER 300 #define STEP 20 asupra rezultatului final care de cele mai main() { multe ori nu se potriveşte cu produsul dezint fahr; for (fahr=LOWER; fahr<=UPPER; voltat. În plus, există tendiţa de a include în fahr=fahr+STEP)

printf(„%4d %6.1 f\n”, fahr, cadrul specificaţiilor elemente care repre(5.0/9.0*(fahr-32))) } zintă mai degrabă dorinţe decât nevoi reale Răspunsurile acestora cuprind toate de business. Se ajunge astfel într-un punct numerele între 1 şi 9 inclusiv (11 experţi au caracterizat de un grad ridicat de frustrare, răspuns 6, alţii 11 au răspuns 9, restul ale- în care echipa de proiect ştie că a dezvolgând ca răspuns un alt număr din interval)! tat conform specificaţiilor funcţionale dar Concluzia este imediată: dacă nişte experţi clientul nu poate utiliza aplicaţia finală în domeniul software nu reuşesc să cadă de pentru că nu este ceea ce şi-a imaginat că acord asupra unei întrebări simple pe baza va fi. Acest rezultat poate fi ameliorat prin unui program de 9(!) linii, înseamnă că prezentarea unuia sau mai multor proeste de aşteptat ca estimările într-un pro- totipuri în fazele timpurii ale dezvoltării iect software să difere foarte mult de la o produsului, însă clientul nu va face întotpersoană la alta, aceste estimări având o deauna diferenţa între acestea şi produsul relativ restrânsă legătură cu final crezând că nu s-a depus un efort semexperienţa acumulată. nificativ între timp, interfaţa cu utilizatorul O practică uzuală este rămânând aproape neschimbată. aceea ca estimările date Tot din cauza invizibilităţii softului şi (atunci când este vorba de implicit a complexităţii acestuia, cerinestimări de timp şi nu în ţele iniţiale par foarte uşor de modificat şi puncte de complexitate) să implementat în cadrul unei aplicaţii. fie mărite cu 20% de către project manager înainte ca 3. Softul are o complexitate ridicată ele să fie transmise către cliFără doar şi poate produsele software ent, pentru a se asigura o oarecare “linişte” au o structură extrem de complexă. Într-o (deşi sunt situaţii în care acest 20% este aplicaţie de dimensiuni medii există extrem departe de a fi suficient). de multe conexiuni între diverse elemente O altă consecinţă directă a acestui software care fac aproape imposibilă tesaspect o reprezintă dificultatea gestionării tarea şi validarea completă a acestora. schimbărilor într-o echipă de proiect, per- Un exemplu simplu în care folosim nouă soanele care vor înlocui anumiţi membri ai condiţii succesive intercalate poate rezulta echipei rareori respectând estimările date într-un număr impresionant de căi posibile de aceştia. care trebuie testate fiecare în parte pentru Şi pentru ca lucrurile să fie “complete”, o validare completă. Acest lucru însă ar pentru multe dintre activităţile estimate putea să nu fie realizabil nici într-o săptăeste foarte dificil de controlat progresul. mână, chiar dacă testul fiecărei căi ar dura Cele mai reprezentative exemple aici sunt o secundă. Mai mult, aceste teste ar trebui activităţile de analiză şi proiectare unde reluate de fiecare dată când se face o modiputem ştii când s-au terminat aceste acti- ficare. Prin urmare multe dintre bug-uri vităţi, dar nu vom putea specifica dacă la persistă o vreme îndelungată (chiar ani de un moment dat ne aflăm la 50% la 75% din zile) într-o aplicaţie până să fie descoperite activitatea respectivă. sau, mai rău, până să îşi arate efectele.

După cum se spunea în aceeaşi carte 2. Softul este invizibil şi intangibil menţionată anterior, “The Healthy Software Rezultatul muncii unei echipe ce dez- Project: a guide to successful development”: voltă un produs informatic este compus “...în cazul proiectelor software aşa numidintr-o colecţie de “texte” de diferite tipuri: tele proceduri de control al calităţii au documente de analiză şi proiectare, cod uneori de-a face mai degrabă cu limitarea sursă, manuale de utilizare şi operare etc. defecţiunilor decât cu garantarea calităţii Doar o parte dintre acestea interesează sau produsului final.“ Şi acest lucru a rămas au vreo semnificaţie pentru cei care vor uti- valabil şi în 2012, în ciuda tuturor metoliza produsul. dologiilor moderne de dezvoltare a softului Clientul final tinde să evalueze un pro- apărute în ultimii ani. dus informatic după ceea ce vede, şi ceea Complexitatea softului este dată şi de

TODAY SOFTWARE MAGAZINE numărul de tranziţii şi “traduceri” ce trebuie realizate între fazele ciclului de viaţă al unui produs. Specificaţiile funcţionale (redactate în limbaj natural) sunt translatate într-un model de analiză (diagrame vizuale care modelează toate soluţiile posibile ale problemei enunţate în specificaţii), care ulterior este translatat într-un model de proiectare (unde se particularizează modelul de analiză pentru o soluţie specifică), care mai apoi este translatat în cod sursă, acesta din urmă fiind translatat întrun model executabil (prin compilare sau interpretare). Tot acest lanţ de translatări, în ciuda faptului că anumite tranziţii sunt automatizate, face procesul de dezvoltare a softului mult mai vulnerabil la erori umane. Acest lucru este cauzat de greşeli de “traducere” sau prin persistarea erorilor nedescoperită la timp în fazele de specificare sau analiză până în modelul executabil.

4. Softul este dinamic

Dinamismul cu care se confruntă proiectele software se manifestă în trei direcţii relevante. Pe de o parte există atracţia noutăţii tehnologice. Ştim că tehnologia avansează foarte rapid şi an de an apar biblioteci şi framework-uri noi, şi versiuni îmbunătăţite ale limbajelor şi mediilor de dezvoltare. Din punct de vedere al unui project manager, păstrarea framewokurilor iniţiale în care a fost dezvoltat un anumit soft este o condiţie elementară de păstrare a stabilităţii acestui soft. Pe de altă parte nu trebuie ignorată apetenţa echipei pentru a lucra cu ultimele tehnologii (inerent mai instabile şi cu neajunsuri încă nerezolvate sau nediscutate pe forumurile de specialitate). Există un efort constant

şi care nu trebuie neglijat, de păstrare a unui echilibru între stabilitate şi eliminarea unui sentiment de plafonare a echipei de dezvoltare.

A doua direcţie ce conferă dinamism proiectelor software este fluctuaţia personalului, care în domeniul IT este foarte ridicată. O fluctuaţie “sănătoasă” pentru o organizaţie se situează undeva în jurul a 10 procente. Un studiu realizat de Ziarul Financiar arată ca în domeniul IT în România fluctuaţia de personal este la nivelul de 20%, şi ea nu se datorează în principal nivelului de salarizare (cum este în cazul altor domenii) ci diferenţelor de cultură şi a sentimentului de nerealizare profesională. Efectele acestei fluctuaţii, după cum subliniam şi în secţiunea 1, constau în reconsiderarea planificărilor anterioare şi de adaptare a noilor veniţi la proiect. Nu trebuie însă neglijată tendinţa noilor veniţi de a respinge codul scris de predecesorii lor, încercând uneori chiar să îşi asume responsabilitatea înlocuirii complete a acestui cod, acţiune ce conduce la anularea validărilor anterioare. În fine, o dinamică aparte faţă de alte proiecte o au cererile de modificare frecvente venite din partea clientului în diverse faze ale ciclului de viaţă a dezvoltării unui proiect software. Această caracteristică a proiectelor software a condus la dezvoltarea medologiilor Agile care includ acest aspect ca pe o componentă activă a procesului de dezvoltare.

proiecte existente şi care au o contribuţie decisivă în situarea acestor proiecte pe un loc fruntaş în topul eşecurilor pe tipuri de proiecte.

Desigur că alături de dificultăţile de măsurare, invizibilitatea, intangibilitatea, complexitatea, şi dinamismul proiectelor software, există şi alte aspecte specifice. De exemplu, sporirea resurselor într-un proiect software întârziat nu elimină decalajul ci sporeşte întârzierea, deoarece capacitatea de efort a membrilor echipei scade cu o cantitate egală cu efortul de comunicare cu noul membru. Aceste lucruri nu se întâmplă în marea majoritate a proiectelor în care se desfăşoară cu preponderenţă activităţi de rutină.

Scopul articolului nu a fost acela de a emite soluţii de gestionare a particularităţilor, acestea putând contitui subiectul unui viitor articol. Cu siguranţă însă, categoria metodologiilor Agile de dezvoltare a softului are în vedere o bună parte a acestor particularităţi.

Nu dorim să încheiem articolul fără a pune o întrebare firească ce rezultă în urma acestei analize: “Cum se face că, în pofida tuturor acestor neajunsuri, industria software rezistă şi chiar înfloreşte?”

Răspunsul este unul optimist, ce se referă la beneficiile aduse de rezultatele proiectelor software şi a necesităţii acestora. Fără doar şi poate, aplicaţiile software au menirea de a ne face viaţa mai simplă într-o multitudine de aspecte ale vieţii cotidiene. Chiar dacă uneori ele se blochează sau funcţionează Concluzii eronat, le acceptăm, trecem cu uşurinţă Am încercat să evidenţiem unele dintre peste multe dintre aceste erori sau găsim aspectele care considerăm că diferenţiază căi de ocolire a lor deoarece avantajele obţiîn mod clar proiectele software de alte nute pun în umbră aceste neajunsuri.

www.todaysoftmag.ro | nr. 8/2013

13

UIX

Omniprezența aplicabilității în ecosistemul personal

P

uterea de prelucrare a informațiilor cu ajutorul aparatelor de mici dimensiuni, permite să ne desfășurăm eficient activitatea chiar și în afara biroului de lucru. În contextul unei dezvoltări continue a tehnologiilor, capacitatea de stocare și afișare a informațiilor este vizibil îmbunătățită, iar posibilitățile de comunicare între aparate sunt nelimitate.

Bogdan Nastasa

Bogdan.Nastasa@endava.com UX/UI Design Lead @ Endava www.nastasabogdan.eu

14

nr. 8/2013 | www.todaysoftmag.ro

Într-un astfel de mediu, o adevarată provocare în aplicabilitate este reprezentată de satisfacerea oricărei doleanțe a persoanelor care folosesc astfel de aparate.

Bineînțeles că au fost realizate programe software care să suporte sarcinile zilnice (ex: editor de documente, client de email, calendar, etc), dar totul trebuie gândit și realizat astfel încât să nu fi limitat doar la un dispozitiv specific. Îți dorești să poți folosi orice aparat de tip telefon, tabletă, laptop, computerul personal, chiar și televizorul tău inteligent, să-ți îndeplinești sarcinile uzuale (ex: să ții legătura cu prietenii, să citești emailuri, etc). Din păcate, nu toate aparatele vor suporta toate cerințele tale, precum printarea unui document sau a unui email, dar datorită posibilității acestor sisteme de a conlucra, oferind o mobilitate sporită a transferului de informații, vei putea realiza orice sarcină din cele pe care ți le-ai propus. În centrul acestui conglomerat de aparate, scopul principal este găsirea unui punct de echilibru astfel încât experiența unui utilizator să fie una naturală.

De aceea este absolut vital ca un proiectant să realizeze un flux de informații și pași, cât mai precis, dar totodată trebuie să urmărească în permanență părerile utilizatorilor: și anume cum și când se folosește, cum îi influențează, timpul alocat pentru realizarea unei sarcini etc. În funcție de acești pași urmați de utilizatori, proiectantul va putea g ă s i s c ăp ăr i l e d i n proiect.

Dacă se dorește scoaterea în evidență a unei proprietăți sau a unei funcționalități, trebuie apelat în fazele timpurii ale realizării aplicației, la câteva concepte de proiectare. În acest mod se poate comunica mult mai ușor viziunea și se poate vedea cum un anumit design poate avea un impact emoțional asupra utilizatorului. Da, un design bun, un curs perfect și natural de navigare în aplicație, poate crea utilizatorului o stare de liniște și o încredere sporită să folosească aplicația respectivă.

Unul dintre cele mai simple și la îndemână concepte de proiecte o reprezintă desenarea, schițarea viziunii sau a ideii pe hârtie sau în format digital cu ajutorului unei aplicații (ex: Balsamiq, Mockflow,

TODAY SOFTWARE MAGAZINE

Mockingbird). Dacă încă nu ai o idee măreață care să schimbe lumea, stai liniștit și fă primul pas, și anume să ai o multitudine de idei.

Dupa ce ți-ai făcut schițele pentru ideea ta sau a unui proiect deja existent, dar care necesită îmbunătățiri, arată-le unui grup restrâns de prieteni, cunoștințe și culege părerile lor. În urma părerilor exprimate, într-un timp relativ scurt, vei putea să-ți îmbunătățești ideea. Următorul pas este să-ți creionezi etapele pe care trebuie să le parcurgă utilizatorul. Bineînțeles, arată din nou modificările tale la grupul de persoane și ia în considerare din nou părerile lor.

Cred că ai observat deja cât de important este să ții cont de observațiile și comentariile persoanelor care îți testează schițele în această etapă timpurie. În acest fel te va ajuta să-ți realizezi o strategie și să anticipezi lucrurile care pot interveni și

sunt greu de prevăzut în timp. Și dacă încă nu ai realizat, în acest moment ai deja răspunsurile la întrebările tale: Cum va arăta aplicația? Cum va funcționa? Ce fel de experiență vor avea utilizatorii?

Când dorești să realizezi un produs/ funcționalitate nouă, trebuie să te gândești la ce-i va motiva pe utilizatori să o folosească. Când ai raspunsul, trebuie neapărat să-l incluzi în aplicație și să-l faci cât mai vizibil vizitatorilor. Exemplu: dacă aplicația ta strânge fonduri pentru diverse activităti, o parte din profit donează-l pentru o cauză nobilă. Sentimentul creat prin donație îl va ajuta și influența pe utilizator să contribuie chiar mai mult în cadrul aplicației.

Scopul acestui concept de proiectare o reprezintă realizarea rapidă a unei soluții din perspectiva grafică a aplicației (poziționarea elementelor în ecran).

Un alt concept de proiectare este reprezentat de realizarea unor prototipuri care să ofere suport interactiv pentru rafinarea unui anumit flux de pași urmat de utilizatori dar și pentru observarea utilității în folosirea aplicației. Aceste prototipuri se pot realiza cu diverse aplicații printre care enumerăm doar câteva dintre ele: Justinmind, Axure, Invisionapp.

Când dorești s ă c upr i n z i a c e a st ă i nt e r a c ț i u n e d i nt r e aplicație și utilizator, trebuie luat în considerare, asa cum am mai menționat mai devreme în acest articol, impactul emoțional care are loc și asta pentru că se dorește să existe o relație pe termen lung a utilizării

aplicației. Clienții extatici sunt clienții fideli.

Acum că am observat care sunt conceptele folosite, să mergem mai departe și să le vedem în acțiune. Dar înainte de toate trebuie să fim conștienți că și realizarea acestor schițe poate să fie consumatoare de timp, și de aceea este suficient în primă fază să realizăm machete cu o fidelitate scăzută.

Să luăm ca exemplu următoarea schiță, a

unei porțiuni din site-ul www.endava.com.

Timpul de realizare a fost de aproximativ 5 minute, dar cu această schiță, proprietarul site-ului va ști exact unde va fi pozitionat logo-ul companiei, meniul, noutățile, etc.

După ce această etapă este finalizată și aprobată, se va trece la partea grafică cu o fidelitate ridicată. Astfel s-a redus considerabil timpul alocat pentru clarificarea proiectului iar clientul poate să compare schițele cu specificațiile proiectului, având astfel un control sporit și o vizibilitate mai bună a ceea ce se va realiza.

Enumăr câteva metode de a face o evaluare a calității schiței: • C o n s i s t e n ț ă ș i s t a n d a r d Utilizatorii trebuie să fie obișnuiți cu ecranele, situațiile intervenite,

www.todaysoftmag.ro | nr. 8/2013

15

UIX Omniprezența aplicabilității în ecosistemul personal

• • •

texte, butoane, păstrând peste tot convențiile aplicației.

Vizibilitate - Conținutul trebuie să fie accesibil și ușor de înțeles de către utilizatori.

Design minimalist - Ecranele afișate trebuie să conțină doar informații relevante pentru vizitatori.

Mesaje de eroare - Mesajele de eroare trebuie să indice cu exactitate problema întâmpinată și să sugereze o soluție fiabilă.

vom discuta într-un articol viitor. În schițele prezentate mai jos sunt trei variante de machete pentru afișarea site-ului: pe monitorul unui computer personal, pe o tabletă și pe un telefon. Durata medie de realizare a acestor machete a fost de aproximativ 20-30 de minute. În acest moment clientul poate să observe diferențele dintre versiuni, să evalueze și să modifice poziționarea elementelor.

Schițele ajută să se înțeleagă ceea ce va fi implementat și să se determine care este structura fiecărei pagini/secțiuni, iar scopul principal este să se reducă costurile și timpul de implementare a proiectului. În această etapă se pot modifica problemele de design, iar implicarea de către client în dezvoltarea aplicației este îmbunătățită considerabil la fel și comunicarea dintre dezvoltatori, analiști și utilizatori. Menționez că toate schițele prezentate în acest articol au fost realizate cu aplicația Justinmind (www.justinmind.com).

Nevoia de a funcționa pe majoritatea platformelor reprezintă o adevarată provocare de flexibilitate a proiectelor dezvoltate.

Noile aplicații apărute au calitate sporită a experienței utilizatorilor și devin o sursă de inspirație pentru o varietate de produse noi.

Analizăm www.bostonglobe.com, care are implementat un design adaptiv la dimensiunile ecranului pe care este afișat.

Bineînțeles sunt avantaje și dezavantaje ale optării unui design adaptiv, dar acestea le

MONITOR

16

nr. 8/2013 | www.todaysoftmag.ro

TABLETĂ

TELEFON

arhitectură

Probleme arhitecturale în proiecte Liferay

Î

ntr-un mediu de afaceri din ce în ce mai agile, cu tot mai multe companii care concurează pentru aceeaşi cotă de piaţă, posibilitatea de a dezvolta aplicaţii cu multe funcţionalităţi “out of the box”, Liferay este un framework cel puţin interesant.

Acest articol analizează probleme arhitecturale care trebuie adresate la începutul proiectului pentru a obţine un produs flexibil fără ajustări majore ulterioare.

Alexandra Coldea

alexandra.coldea@isdc.eu Java Developer @ ISDC

17

nr. 8/2013 | www.todaysoftmag.ro

Cu Liferay sau fără Liferay

Liferay este un portal open source sub licență GPL, pentru aplicații enterprise. Vine împreună cu multe funcționalități personalizabile: user management, multi-tennant și multilanguage, CMS, integrare cu motoare de reguli („rule engine”), cu motoare de căutare și multe altele „out of the box”.

Funcționeză pe o serie de application servers (printre care JBoss, GlassFish), servlet containers (Tomcat, Jetty, Resin) și cu multe DBMS-uri. Poate fi deployat în cloud. Înainte de începerea oricărui proiect trebuie pusă întrebarea: este într-adevăr nevoie de Liferay? Astfel, dacă e nevoie de un portal complex, o aplicaţie care administrează conţinut mult atunci se potriveşte. Dacă aplicaţia este mare ca dimensiune, dar nu e orientată spre conţinut („content-centric”), Liferay poate să fie util, dar nu e recomandabil. În schimb, dacă aplicaţia este simplă şi manipulează conţinut puţin, atunci Liferay adaugă prea multă complexitate.

Trebuie să se ţină cont şi de faptul că Liferay este un container de portleţi şi nu merită să se folosească pentru aplicaţii web clasice.

Service Builder sau Layer de servicii propriu

Service Builder-ul este un tool dezvoltat de Liferay pentru a automatiza crearea interfeţelor şi claselor folosite de portal și portleţi pentru layer-ele de servicii și acces la date. Se generează codul pentru bean-uri, Persistenţa, Model şi mapările de Spring. Acesta este tool-ul folosit şi de developeri Liferay pentru a genera serviciile din Liferay core. De aceea, a fost îndelung testat şi problemele rezolvate sau cel puţin identificate.

Problemele găsite sunt logate în Jira și sunt publice: http://issues.liferay.com/ browse/LPS. Service Builder-ul asigură tranzacționalitatea serviciilor, are un mecanism de clustering și chiar oferă posibilitatea de a internaționaliza orice entitate cu efort minim.

Totuşi, din punctul de vedere al documentaţiei, Service Builderul beneficiază doar de o pagină de wiki care nu este foarte detaliată. Aceasta înseamnă că, dacă nu întelegi exact ce fac anumite atribute, trebuie să investighezi codul generat pentru a anticipa cum se va comporta. De obicei, nevoia pentru aceste investigații nu poate fi identificată decât în timpul implementării și aceasta înseamnă întârzieri neprevăzute. În schimb, există training-uri organizate de Liferay unde se pot acumula cunoştinţele necesare.

Pe de altă parte, se poate opta pentru dezvoltarea unui layer de servicii propriu. Avantajul este deţinerea controlului

arhitectură Probleme arhitecturale în proiecte Liferay complet asupra codului scris şi posibilitatea definirii documentaţiei proprii. Însă, overhead-ul de a defini două layere – persistență şi servicii – cu interfeţele şi nivelul de abstractizare oferit de Service Builder este foarte mare. Astfel, timpul de implementare și livrare (“time to market”) va fi foarte ridicat.

Totuşi, există unele cazuri în care Service Builder-ul nu este necesar. De exemplu dacă se comunică cu un sistem 3rd party care administrează datele și expune servicii, va fi nevoie doar de apelarea lor. În continuare vom discuta despre proiecte în care se folosește Service Builder-ul.

Decuplarea componentelor aplicaţiei

Ca în orice arhitectură pe layere, componentele trebuie menținute separate, dar decizia asupra nivelului de granularitate la care se separă în artefacte trebuie cântărită cu atenţie pentru că poate aduce o penalizare de performanţă sau poate face codul greu de înteles și menținut.

Figura 1 prezintă împarţirea logică a componentelor dintr-un proiect de Liferay. În mod implicit, Service Builder-ul generează api-ul separat de implementare, într-un folder din WEBINF. Aceasta este modalitatea Ant de structurare a proiectului. Modalitatea Maven este de a-l genera într-un modul separat.

Cât despre împachetarea componentelor, există mai multe modalităti de a face acest lucru, în funcţie de necesităţile proiectului. Pentru cel mai simplu proiect, este suficient să se împacheteze api-ul într-un jar şi portleţii împreună cu implementarea într-un war. Avantajul acestei soluţii e că odată ce contractul e definit implementarea se poate schimba şi i se poate face hot deploy. Teoretic, se poate modifica logica de

Figura 1

18

nr. 8/2013 | www.todaysoftmag.ro

business şi serverul nu trebuie oprit pentru a avea soluţia în producţie. Dar, din păcate, în practică de foarte puţine ori se va întampla să lucrezi un sprint la servicii şi să nu modifici ceva din interfată. Hot deploy-ul este mai mult pentru hot fixes.

Pentru a pastra un “separation of concerns” şi a creşte nivelul de izolare, se poate ca implementarea serviciilor să constituie un modul separat şi să fie deployat ca un jar, aşa cum e prezentat în Figura 2.

Aceasta ar însemna că, dacă la un moment dat clientul se hotărăşte că doreste să stocheze datele într-un mod diferit, trebuie doar înlocuit modulul de implementare.

Dezavantajul este că deploy-ul durează mai mult, fapt care se simte mai ales în timpul development-ului.

Din acest punct de vedere, dacă proiectul este unul mare şi foarte agil, cu un client imprevizibil, cea mai bună soluţie ar fi să se separe implementarea serviciilor într-un modul diferit de la început, dar se renunță la posibilitatea de a deploya hot fixes pe servicii. Pentru development se poate folosi o configurare asemănătoare cu cea din Figura 3, în care acest modul e împachetat împreună cu portleţii într-un war şi astfel se poate face hot deploy şi nu se crează overhead pentru asta.

Un alt aspect care diferă de la proiect la proiect este modul în care portleţii sunt separaţi în plugin-uri. Variaţiile sunt foarte mari: în unul dintre proiectele pe care am lucrat, se folosea un plugin per portlet, pe când în altul exista un singur plug-in pentru toţi portleţii. Fiecare abordare are avantajele şi dezavantajele ei. În prima este foarte uşor să controlezi ce funcţionalităţi pui la dispozitie unui tenant, dar deployul durează mult şi comunicarea inter-pluginuri poate fi costisitoare. A doua este o variantă mai rapidă, tot business-ul fiind la un loc. Dar aceasta din urmă este avantajoasă numai până la un anumit număr de portleți.

Decizia depinde de necesităţile clientului și dimensiunea proiectului.

Când aceasta din urmă începe să crească, funcţionalităţile care au o legătură logică

Figura 2

sau au sens împreună pentru business, ar trebui să fie grupate în acelaşi plugin.

Chiar dacă la începutul proiectului totul este dezvoltat împreună, este posibil ca la un moment dat clientul să vrea să pună la dispoziţie diverşilor tenanţi funcţionalităţi diferite.

Interacţiunea dintre componente

O problemă care de cele mai multe ori se pune prea târziu este standardizarea la nivel de proiect a comunicării dintre componente.

Liferay urmărește un Model Driven Architecture, unde Service Builderul acţionează ca un Model Driven Transformation Tool. Deci, layer-ul de servicii este cel responsabil cu transformarea entităților de back-end în entităţi care pot fi folosite de layer-ul de portleţi. Dar, la fel ca portleţii, serviciile pentru entităţile care au valoare de business împreună ar trebui grupate şi aceste grupuri să fie izolate unele de altele.

Aceasta pentru că se poate decide la un moment dat că anumite funcţionalităţi trebuie mutate pe un complet alt environment. De exemplu, într-o aplicaţie care se ocupă cu managementul studenţilor, toate informaţiile referitoare la notele de la examene trebuie mutate într-un „trust center” din motive legale. În aceste condiţii, pentru a face legătura dintre prezentare şi back-end, avem nevoie de servicii compuse, numite wrappere. Figura 4 prezintă această arhitectură.

Comunicarea dintre nivelul de wrappere si nivelul portleţilor se face folosind DTO-uri sau business objects. Layer-ul de servicii expune entităţi de Service Builder şi toate operatiile pe care le face sunt atomice, pentru că totul e într-o tranzacţie.

De aceea, nivelul de granularitate la care serviciile se împart în unităţi funcţionale trebuie cântărit cu grijă pentru a nu scoate din tranzacţii operaţii care ar trebui să fie

TODAY SOFTWARE MAGAZINE schimb, dacă layerul cu wrapper-ul este cel care asigură consistenţa bazei de date, trecerea va fi una dureroasă.

Concluzii

În concluzie, nu există un mod standard de a structura o aplicaţie Liferay, există doar o serie de întrebări care trebuie puse la începutul fiecărui proiect. Cu cât aceste întrebări care standardizează modalităţile de lucru sunt puse mai târziu, cu atât refactorizarea pentru a avea un proiect consistent va fi mai costisitoare, flexibilitatea şi extensibilitatea vor fi afectate.

Figura 3

atomice (ex. ștergerea unui student separată de ştergerea notelor lui). Mai mult, clientul poate să decidă că doreşte să îşi expună business-ul ca un serviciu (Software as a Service). Dacă proiectul e modularizat eficient, logica de business pentru o funcţionalitate e centralizată, această schimbare ar trebui să fie simplă, pentru că Service Builder-ul oferă posibilitatea de a expune servicii REST sau SOAP doar scriind o implementare în layer-ul de servicii. În

Figura 4

WE HIRE

IN GOOD COMPANY PROJECT MANAGER

.NET DEVELOPERS JAVA DEVELOPERS JAVA ARCHITECT .NET ARCHITECT

ISDC.EU/CAREERS

WE DO PROJECTS

OUR CUSTOMERS

ISDC

WITH IMPACT. WE

ARE IMPRESSED

ENGINEERS

DELIVER RESULTS,

BY OUR AWESOME

YOUR

NOT RESOURCES.

TECH TEAMS.

DREAMS!

RALUCA HIREME @ISDC.EU

SIMONA HELLO @ISDC.EU

www.todaysoftmag.ro | nr. 8/2013

19

business

SEO local prin intermediul Google+

A

proximativ 40% din căutările realizate pe dispozitive mobile folosind Google sunt locale. Având în vedere această cifră, există un potenţial foarte mare de creştere a numărului de clienţi locali ai unei afaceri prin optimizarea online locală. Datorită paginilor Google+ for Business afacerile locale îşi pot creşte vizibilitatea online în zona geografică în care activează.

Radu Popescu

rpopescu@smallfootprint.com QA şi Web designer @ Small Footprint

Google+ for Business este un instrument gratuit oferit de către Google, ce se adresează afacerilor mici şi mijlocii. Prin intermediul său, companiile pot atrage clienţi noi din proximitatea lor. Integrarea cu Google+ şi Google Maps îl fac un instrument foarte bun în promovarea online locală. O funcţionalitate cheie este sistemul Zagat. Acesta foloseşte o scară de 30 de puncte prin care oricine poate oferi un rating acelei companii sau serviciilor sale.

Cum ne poate ajuta o pagină Google+ for Business

Pentru a înţelege modul în care Google+ for Business ne poate ajuta, haideţi să luăm un exemplu. Presupunem că tocmai am ajuns în Cluj-Napoca şi dorim să căutăm o anumită cafenea. Accesăm Google şi apoi tastăm “starbucks”. Datorită setărilor de căutare, Google va şti că noi realizăm o căutare locală şi va include în rezultate sale şi câteva detalii de pe pagina Google+ for Business a cafenelei (în caz că aceasta există). În urma căutării, putem vedea că în Cluj-Napoca există această cafenea (Figura 1). Fără pagina Google+ for Business nu am fi ştiut acest lucru pentru că locaţia din

Figura 1

20

nr. 8/2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

Figura 2

oraşul Cluj-Napoca nu deţine un website propriu. În plus vedem şi zona în care se găseşte şi ratingul foarte bun pe care îl are.

O a doua modalitate prin care proprietarii de afaceri locale pot atrage clienţi noi, folosind Google+ for Business, este prin intermediul reţelei sociale Google+. În doar 2 minute putem căuta cazare într-un oraş în care suntem pentru prima dată, folosind butonul “Local” din meniul principal al contului Google+.

Cautăm “hotel 5 stele” (locaţia curentă va fi Cluj-Napoca datorită IP Geolocation), iar rezultatele ne vor prezenta hotelurile de 5 stele din oraş (Figura 2), iar pe baza scorului şi a locaţiei putem alege unde ne cazăm.

Rezultatele locale ale unei căutări se pot modifica în funcţie de review-urile şi rating-ul oferit de către prietenii din profilul Google+. Dacă persoanele din cercurile tale au apreciat un anumit restaurant, acela îţi va fi afişat şi ţie printre primele rezultate.

Practic această integrare între reţeaua socială a Google şi paginile locale oferă nişte recomandări, iar acest lucru poate duce la creşterea constantă a numărului de clienţi.

Pe baza acestor exemple, putem vedea că lipsa unei pagini Google+ for Business va face ca afacerea sau magazinul dumneavoastră să nu apară în aceste căutări locale, pierzând foarte mulţi potenţiali clienţi.

Pentru a putea crea o pagină Google+ for Business vom avea nevoie de un cont Google+. Din meniul acestui cont, vom selecta More şi apoi Pages. În pagina care se va deschide selectăm Create New Page, iar apoi tipul paginii şi anume Local Business or Place.

Paşii următori presupun completarea profilului cu datele necesare, iar mai apoi verificarea sa. Acesta se va face prin intermediul unui cod pe care îl veţi primi prin poştă, la adresa specificată în profil.

Recomandări pentru optimizarea paginii Business

Google+ for

Periodic trebuie să ne asigurăm că informaţiile prezente pe această pagină sunt actualizate. În acest mod evităm situaţiile în care pierdem clienţi din cauza faptului că datele de contact sau adresa nu mai sunt valabile. Pe lângă actualizarea profilului trebuie să avem în vedere şi următoarele elemente pentru a profita la maxim de potenţialul paginii noastre:

• • • • • •

Utilizarea unui număr de telefon fix (având şi prefixul judeţului) ajută algoritmii de căutare la determinarea proximităţii persoanei care caută faţă de locaţia afacerii; Este recomandată folosirea cuvintelor cheie numai în descriere şi categorii. Titlul nu trebuie să conţină cuvinte cheie pentru că acestea pot crea confuzii; Pagina trebuie să conţină cât mai multe fotografii pentru a fi mai atrăgătoare; În rubrica “external website” este de preferat să adăugaţi linkuri spre paginile Contact sau Localizare în locul adresei web a sitului; Îndemnaţi clienţii să ofere review-uri afacerii dumneavoastră pe pagina Google+; Pregătiţi o strategie pentru feedback-ul negativ (în caz că va veni). Acest lucru vă poate ajuta să recâştigaţi un client nemulţumit. www.todaysoftmag.ro | nr. 8/2013

21

programare

Puncte de scalabilitate pe “cloud”

C

loud – un alt buzz word pe care îl auzim aproape în fiecare zi. În momentul de faţă există mai mulţi provideri care oferă acest serviciu: Amazon, Microsoft (Windows Azure), Google, Rackspace.

Radu Vunvulea

Radu.Vunvulea@iquestgroup.com Senior Software Engineer @iQuest, proiectele pe care lucrează sunt de tip LoB, în general folosind ultimele tehnologii Microsoft. Face parte din grupul entuziaștilor, motiv pentru care ii place să fie la curent cu tot ce apare nou in domeniul IT, in special din punct de vedere software.

22

nr. 8/2013 | www.todaysoftmag.ro

Când ne gândim la cloud ce ne vine în minte? Una, două sau mai multe instanţe pe care le ţinem într-un cloud, iar când avem nevoie de mai multe resurse putem să creştem foarte uşor numărul de instanţe. În momentul de faţă un provider de cloud precum Microsoft ne oferă mult mai multe puncte de scalabilitate. În cadrul acestui articol vom vedea prin ce alte moduri putem să creăm o aplicaţie pentru cloud care să fie scalabilă şi să folosească serviciile pe care Windows Azure le pune la dispoziţie.

conţinut precum imagini, CSS, HTML care nu se schimbă în fiecare secundă (la fiecare request în parte). În mod normal în momentul în care observăm că încărcarea pe maşinile noastre este mare vom încerca să creştem numărul de instanţe. Acest lucru poate să fie o soluţie la problema noastră, dar din punct de vedere a costurilor s-ar putea să nu fie cea mai bună.

Chiar dacă vom încerca să facem cache la conţinut pe server (prin IIS sau alte metode), toate request-urile vor ajunge până la maşinile noastre. Din această cauză pentru fiecare request acestea o să fie nevoContent Delivery Network ite să răspundă, consumând resursele pe Să ne imaginăm că avem o aplica- care le avem la dispoziţie. ţie web care conţine foarte mult conţinut În acest caz o soluţie pentru problema static. Prin conţinut static înțelegem orice noastră poate să fie folosirea unor Content

programare Delivery Network (CDN). Prin intermediul acestui serviciu conţinutul static poate să fie cache-uit pe diferite CDN-uri în funcţie de locaţia fizică a clientului.

Toate cererile pentru conţinutul static o să fie rezolvate de către CDN-uri. În mod normal un CDN poate să se ocupe doar de conţinutul static, dar noile versiuni de CDN-uri suportă şi conţinutul dinamic. Acest serviciu este oferit şi de către Windows Azure şi poate să fie integrat cu uşurinţă în aplicaţiile noastre.

Prin folosirea unui mecanism de livrare a conţinutului precum acesta, maşinile care găzduiesc aplicaţia noastă nu vor mai fi lovite la fiecare cerere a unei resurse. În mod automat nivelul de încărcare a acestora va scadea destul de mult.

Cache

Următorul loc în aplicaţie unde putem să introducem foarte uşor un punct de scalabilitate este cache-ul. Ca să evităm să facem nenumărate request-uri la diferite servicii externe sau să recalculăm diferiţi parametri, putem să folosim un mecanism de caching.

TODAY SOFTWARE MAGAZINE

sincronizarea datelor dintre două sau mai multe instanţe de cache este suportată nativ. Aceste setări se pot face înainte să facem deploy la soluţie.

A treia variantă de caching pe care o avem la dispoziţie este prin folosirea unui serviciu dedicat de cache. În acest caz, noi nu trebuie să ne ocupăm deloc de instanţe, această resursă fiind văzută în întregime ca un serviciu.

Folosirea unui mecanism de caching de acest gen ne ia de pe umeri probleme pe care ni le poate pune un mecanism de caching clasic. Probleme precum sincronizarea sau adăugarea unui nou nod de cache dispar în totalitate.

Video stream

Windows Azure oferă acest serviciu în diferite moduri. Avantajul folosirii unui serviciu pentru a face cache la date este în momentul în care avem nevoie să scalăm mecanismul de cache nu trebuie să ne punem problema de achiziţionarea unei maşini, a licenţelor şi sincronizarea acestor noduri. În prezent, când creăm o maşină în Windows Azure putem să specificăm câtă memorie RAM să fie alocată pentru cache. Un alt sistem de caching este prin crearea unor maşini dedicate pentru acest lucru, în care toată memoria RAM va fi alocată pentru caching. În ambele variante,

Până acuma am analizat două probleme clasice care apar în orice aplicaţie web. Dar ce putem face dacă este nevoie să facem stream video. După cum toţii ştim, acest lucru este extrem de costisitor nu doar din punct de vedere a resurselor consumate pe partea de server cât şi a bandei de

internet. În mod normal putem să ajungem să avem maşini dedicate care să se ocupe de streaming video. Iar momentele în care avem foarte mulţi clienţi activi pot să ne pună probleme destul de mari. Pentru aceste cazuri Windows Azure ne vine în ajutor cu un serviciu dedicat pentru acest lucru. Windows Azure Media Services se ocupă în totalitate de streaming-ul video. Începând de la partea de encoding, ajungând la encriptare şi livrare a conţinutului (offline şi online).

Acest serviciu eliberează în totalitate instanţele noastre, care ar fi trebuit să se

ocupe de procesarea şi livrarea acestuia.

Fiind un serviciu dedicat pentru acest lucru, scalabilitatea ne este asigurată din start.

Servicii web

Momentan am văzut trei locuri diferite unde putem să scalăm folosind diferite servicii în cloud fără să fie nevoie să multiplicăm numărul de instanţe a aplicaţiei. În funcţie de tipul de aplicaţie, s-ar putea să expunem diferite servicii web care colectează diferite informaţii de la client.

Ce putem să facem dacă există momente când există un număr prea mare de clienţi care doresc să se conecteze la noi? În mod normal am încerca să alocăm un număr mai mare de instanţe care să se ocupe de acest lucru.

O soluţie pe care Windows Azure ne-o oferă este Service Bus Relay. Prin intermediul acestui serviciu putem să expunem orice serviciu web de tip „fire and forget”.

Toate cererile o să fie stocate sub forma unei cozi de mesaje, iar serviciul nostru o să le poate procesa pe rând. Chiar dacă numărul de cereri creşte extrem de mult, serviciul pe care îl avem expus la clienţi o să fie mereu disponibil.

Windows Azure Service Bus Relay poate să fie integrat cu uşurinţă în aplicaţia noastră. Singura modificare de care este nevoie într-o aplicaţie care foloseşte WCF este modificarea fişierului de configurare.

Comunicare între instanţe

În general când avem o aplicaţie complexă, vom avea diferite tipuri de maşini pe care vor rula componente ale aplicaţiei noastre. Va fi necesar să asigurăm între aceste instanţe un mod de comunicare persistent şi independent de fiecare instanţă în parte.

Putem să încercăm să implementăm un sistem de comunicare prin intermediul unei baze de date sau prin intermediul altei instanţe care să se ocupe doar de acest www.todaysoftmag.ro | nr. 8/2013

23

programare Puncte de scalabilitate pe “cloud” lucru. În momentul în care este nevoie să scalăm, ar fi necesar să ne gândim cum putem să rezolvăm probleme precum sincronizarea instanţelor.

Windows Azure ne vine în ajutor, punând la dispoziţie diferite moduri de trimitere de mesaje. Toate aceste servicii sunt accesate pe baza unui URL şi pot să fie accesate din orice locaţie de pe internet.

Cel mai de bază serviciu, dar care are şi cele mai mici costuri este Windows Azure Queues. Acestă coadă de mesaje ne permite să distribuim mesajele într-un mod foarte simplu, rapid şi ieftin. Dacă este necesar să putem distribui mesajele la mai mulţi consumatori, să avem suport de death-letters sau să putem garanta ordinea mesajelor atunci când lucrăm cu Windows Azure Service Bus Queues şi Windows Azure Service Bus Topics.

Trasmitere de date

O aplicaţie client-server poate să însemne un schimb permanent de date.

De foarte multe ori acest lucru înseamnă expunerea de diferite servicii web prin care clienţii noştri pot să execute query-uri peste o bază de date. În aceste cazuri aplicaţia noastră va trebui să conţină instanţe care expun acest serviciu şi o bază de date (relaţională sau non-relaţională). Pe lângă că este nevoie să ţinem aceste instanţe va

24

nr. 8/2013 | www.todaysoftmag.ro

fi nevoie să ne ocupăm şi de mentenanţa acestor servicii web. În astfel de cazuri ne putem imagina într-un alt mod sistemul nostru. Putem să stocăm şi să expunem datele pe care le avem prin intermediul Windows Azure Table Storage Service. Aceste tabele nonrelaţionale ne permit să stocăm sute de giga de conţinut fără nici un fel de probleme.

Când dorim să folosim o astfel de soluţie ne pot apărea în minte două probleme: ce informaţie poate să acceseze fiecare client şi audit. Prin intermediul unor token-uri pe care le putem genera pentru fiecare client în parte putem să definim la ce conţinut are clientul acces, ce fel de operaţii poate să execute şi cât timp un token este valabil. Acestă funcţionalitate poartă numele de Shared Access Signature şi ne permite să eliminăm din ecuaţie instanţele care trebuie să ofere date clienţilor. Aceste tabele nu trebuie să reprezinte modul în care stocăm noi datele intern, ci datele pe care noi dorim să le oferim clienţilor noştri.

Windows Azure Storage Service suportă în mod nativ audit-ul. Tot ce este necesar este să îl activăm şi să specificăm la ce fel de operaţii dorim să facem audit.

Folosind o astel de soluţie va fi necesar să avem o componentă care se ocupă de generarea şi managmentul acestor token-uri. Nu mai avem nevoie de alte

componenete.

Concluzie

Am analizat diferite modalităţi prin care putem să facem aplicaţia noastră scalabilă. Începând de la diferite sisteme de cache sau de trimitere de mesaje, la servicii care ne permit să facem stream video fară să ne punem problema de alocare de resurse sau de securitate.

Cel mai important lucru pe care trebuie să îl facem când începem să ne gândim la o aplicaţie în cloud este să încercăm să identificăm toate punctele în care putem să scalăm şi să căutam servicii care ne pot oferi acest lucru. În cazul în care diferite funcţionalităţi de care avem nevoie nu le putem găsi deja pe cloud atunci este bine să încercăm să le separăm pe instanţe diferite sau cel puţin pe diferite procese. Astfel încât dacă este nevoie să scalăm, să ne fie mai uşor să creştem numărul de instanţe care se ocupă de o anumită funcţionalitate. În ziua de azi o soluţie cloud înseamnă mai mult decât mai multe maşini pe care rulează aplicaţia noastră împreună cu un load balancer - scalabilitate pe orizontală.

Cloud înseamnă o multitudine de servicii care vin în ajutorul nostru pentru a putea crea aplicaţii mai complexe şi care să scaleze acolo unde avem nevoie.

programare

TODAY SOFTWARE MAGAZINE

In-Memory Database Platforma real-time SAP HANA

D

ezvoltarea soluțiilor de business SAP reprezintă o continuă provocare extinsă pe doua planuri atât la nivel tehnic cât și la acela de cunoaștere al mediului de afaceri. Nevoia de performanță și adaptabilitate ridicată în crearea unui software de business SAP implică inovație, ale cărei rezultate revoluționare deja aplicabile am dori sa le expunem în rândurile ce urmează.

Horea Rațiu

horea.ratiu@msg-systems.com Director Departament SAP @ .msg systems Romania

Victor Ionescu

victor.ionescu@msg-systems.com SAP IT Consultant @ .msg systems Romania

Conceptul In-Memory Database

Volumul de date din cadrul sistemelor de business actuale se află într-o continuă creștere, calitatea datelor este foarte diferită, de la date structurate la cele nestructurate.

Odată cu apariția tehnologiilor Mobile s-a schimbat și modul de acces al datelor astfel încât userii au acces real-time, iar timpul de răspuns trebuie sa fie minimal ( < 1s ). În cazul sistemelor clasice de management al bazelor de date, datorită limitelor tehnologice, încărcarea datelor se face printr-o separare a soluțiilor de data management în procesări transzacționale ( OLTP – Online Transaction Processing ) și analitice ( OLAP - Online application processing ).

Exemplu de In-Memory DB – IMDB • Data rămâne permanent în memorie.

• M e m o r i a p r i n c i p a l ă e s t e ”persistența„ primară.

• Totuși : loggarea se face pe disk/ recuperarea datelor se face tot de pe disk.

• •

Accesul la memoria principală este noua provocare.

Algoritmii de cache/structurile de date sunt cruciale.

Generația actuală de soluții SAP Enterprise

Arhitectura generației actuale de sisteme de business reflectă condițiile tehnologice și evoluția soluțiilor de business : • Database layer: Sistemele de management de baze de date a fost construite pentru a optimiza performanța accesului la harddisk, de exemplu, prin minimizarea citirii în memoria principal a numărului de pagini de disk la procesarea unui query.

• Bu s i n e s s app l i c at i on l ay e r : Software-ul de business a fost construit folosind paradigma procesării secvențiale. Tabelele de baze de date erau aduse din baza de date, procesate rând cu rând, si apoi repuse înapoi în baza de date.

Figura 1 Exemplu de structură a unei BD In-Memory

Figura 2 ilustrează o situație tipică pentru un software de tip enterprise în generația actuală de soluții.

Companiile de mari dimensiuni posedă mai multe sisteme de tip enterprise resource planning (ERP) fiecare cu baza de date proprie pentru datele operaționale.

Datele analitice sunt consolidate într-un enterprise data warehouse și consumate de către business useri cu ajutorul soluțiilor de Business Intelligence (BI).

www.todaysoftmag.ro | nr. 8/2013

25

programare

In-Memory Database - Platforma real-time SAP HANA

Figura 2. Soluție enterprise SAP din generația actuală

progresul tehnologic din ultimii ani. În continuare vom discuta structura interna a platformei, evidenţiind aceste inovaţii care diferenţiază SAP HANA de alte soluţii În aplicațiile financiare și de business, IMDB. diferite tipuri de balanțe totale sunt de obicei persistate sub forma de agregate Interfeţe. SQL Script materializate. În cazul SAP HANA si a salSpre deosebire de un DBMS obişnuit vării datelor în memorie , aceste agregate platforma SAP HANA oferă, pe lângă intermaterializate pot fi eliminate astfel încât faţa SQL standard, şi alte interfeţe precum toate calculele de balanțe și sume necesare SQLScript sau MDX(multidimensional rapoartelor sunt determinate real-time cu expression). Existenţa acestora aduce un o performanță ridicată a documentelor, de plus de flexibilitate platformei şi permite exemplu cele contabile. dezvoltarea de aplicaţii optimizate pentru În situaţia utilizării unui system de procese în timp real.

DBMS classic, necesitatea permanentă de a Odată cu implementarea pe scară tot avea acces la informaţii actualizate conduce mai largă a bazelor de date In-Memory la crearea de tabele adiţionale pentru stoca- este de aşteptat ca şi fenomenul de „Code rea acestor date. În cazul SAP HANA aceste Pushdown” să devină tot mai frecvent întâltabele sunt eliminate, informaţiile necesare nit - acesta presupune migrarea logicii de putând fi calculate în timp real, astfel simplificându-se modelul de date.

Toate modulele SAP alături de release-urile noi sunt si vor fi adaptate pentru

Modul în care revoluționează SAP HANA aplicațiile de business și beneficiile imediate pe care le aduce

Instrucţiunile SQL Script au la bază operaţii SQL standard şi proceduri predefinite. Astfel, din punct de vedere conceptual, SQLScript poate fi asemănat cu procedurile stocate, SQL Script aducând însă îmbunătăţiri semnificative în ceea ce priveşte potenţialul de optimizare al operaţiilor.

Astfel, pentru a fi procesate, procedurile SQLScript sunt compilate într-un plan de execuţie bazat pe limbajul „L” iar mai apoi în limbaj C++ în vederea execuţiei efective.

De asemenea la nivelul „layer”-ului C++ au fost dezvoltate şi o serie de librării menite să uşureze implementarea logicilor de business în cadrul bazei de date.

Exemple de astfel de librării sunt „Business Function Library”(BFL) şi „Predictive analysis library”(PAL).

Paralelism Un alt aspect important de care s-a ţinut cont în dezvoltarea platformei SAP HANA este capacitatea masivă de paralelizare a generaţiei actuale de procesoare multicore.

Astfel, un benchmark1 efectuat de Intel împreună cu SAP pe platforma HANA si utilizând procesoare Intel a relevat o relaţie de natură aproape liniară între creşterea paralelismului(numărului de thread-uri) şi scăderea timpului de execuţie la operaţii pe baza de date.

Secretul din spatele acestor performanţe constă în utilizarea unui „model computa-

Figura 3. Migrarea tuturor aplicațiilor (total sau parțial) pe platforma SAP HANA

platforma In Memory-Database SAP HANA. Datorită succesului avut până acum SAP HANA este contractată și de aplicațiile noi dezvoltate în SAP-ABAP. SAP oferă un road-map incremental care permite companiei sau organizației să exploreze tehnologiile de ultimă oră, Figura 3. Structura interna a platformei tehnice SAP HANA să rețină oportunitățile în scenarii sideby-side, și să fie pregătită pentru rata în business considerate a fi „data-intensive” de ţional” optimizat. Practic, instrucţiunile continuă creștere de a face business. la nivelul aplicaţie la cel al bazelor de date. SQLScript sunt compilate şi reprezentate Interfaţa SQLScript a SAP HANA are rolul sub forma unui „data flow graph” – un graf Platforma tehnică SAP HANA de a veni în întâmpinarea acestui fenomen, aciclic orientat în care fiecare nod al graPlatforma SAP HANA nu se rezumă SQLScript fiind un limbaj dezvoltat de SAP fului reprezintă o transformare ce trebuie la a fi abordarea SAP a conceptului de tocmai cu scopul de a sprijini implemen1 S t u d i u l c o m p l e t : h t t p : / / w w w. i n t e l . c o m / In-Memory Database, ci vine cu o serie de tarea unei logici complexe la nivelui bazei c o n t e n t / w w w / u s / e n / h i g h - p e r f o r m a n c e - c o m p u t i n g / high-performance-computing-xeon-e7-analyze-business-as-it-hapinovaţii menite să folosească la maximum de date. pens-with-sap-hana-software-brief.html

26

nr. 8/2013 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Rezultate

Majoritatea query-urilor au rezultat în timpi de răspuns de sub o secundă, până şi cea mai complexă operaţie, efectuată asupră întregului set de date de cinci ani, încheindu-se în mai puţin de 4 secunde2.

Desigur, ceea ce contează într-un final este modul în care această îmbunătăţire de performanţă este resimţită de enduserii sistemului în mediul productiv. Se vehiculează că migrarea de pe un DBMS obişnuit(cu stocare pe suport magnetic) pe SAP HANA aduce cu sine îmbunătăţiri cu un factor de câteva mii.

Figura 4. Timpi de procesare pentru un set de date de 120 de miliAcest fapt este susţinut şi de declaraţioane de înregistrări. Variaţia timpilor cu creşterea paralelismului ile diverşilor clienţi care au trecut deja prin această etapă: Row store Column Store aplicată asupra setului de date. “[R]eplacing our enterprise-wide Oracle Aplicaţia procesează Număr mare de rânduri, şi sunt Tipurile de operaţii ce pot fi înglobate câte un rând data mart and resulting in over 20,000-times necesare operaţii pe coloane(agregare, în aceste noduri sunt: speed improvement processing our most căutare ş.a.m.d.)

• Operaţii pe mulţimi (agregare, reu- Agregările nu sunt complex freight transportation cost calculaNumăr mare de coloane necesare al tabelei niune, intersecţie), tion . . . our stand-alone mobile applications Coloanele conţin Tabela este parcursă • Instrucţiuni SQL, that were previously running on Oracle are valori distincte, doar pe baza valopotenţialul de rilor din anumite • Script-uri reprezentând operaţii astfel now running on SAP HANA. Our 2,000 compresie a datelor coloane complexe, care nu pot fi modelate fiind redus local sales representatives can now interact sub forma unui „data flow graph”. with real-time data instead and have the Evaluarea performanţei ability to make on-the-fly promotion decisiReprezentarea instrucţiunilor sub Evident, discuţia despre platforma SAP ons to improve sales.” – Nongfu Spring această forma permite o mai bună partiţio- HANA nu poate fi încheiată altfel decât nare a datelor în submulţimi independente, răspunzând la întreabarea „Care este câş“[O]ur internal technical comparison care pot fi procesate în paralel. Utilizarea tigul concret de performanţă obţinut prin demonstrated that SAP HANA outperforms unei asemenea abordări oferă posibilitatea migrarea pe o platformă SAP HANA?” traditional disk-based systems by platformei SAP HANA să profite la maxi- Pentru a cuantifica acest câştig au fost reaa factor of 408,000.” mum de puterea de procesare masivă a lizate nenumărate benchmark-uri, probabil – Mitsui Knowledge Industry Co. Ltd. generaţiei actuale de „multi-core-uri”, astfel cele mai relevante fiind cele desfăşurate în explicându-se şi rezultatele uimitoare obţi- contextul de Data Warehousing.

“With SAP HANA, we see a tremendous nute în benchmarkul Intel. În continuare vor fi prezentate pe scurt opportunity to dramatically improve our rezultatele unui asemenea benchmark rea- enterprise data warehouse solutions, drasColumn/Row Store lizat pe platforma SAP HANA. În cadrul tically reducing data latency and improving Una dintre proprietăţile distinctive ale testului s-a urmărit analiza puterii de pro- speed when we can return query results in 45 SAP HANA este faptul că dispune atât de cesare analitice a SAP HANA în contextul seconds from SAP NetWeaver BW on SAP un model de stocare bazat pe rânduri(row BI real-time.

HANA versus waiting up to 20 minutes for store) cât şi pe coloane(column store).

Testul a fost executat pe un set de date empty results from SAP NetWeaver BW on a Deşi o tabelă este prin definiţie bidi- de 100TB, acestea fiind stocate într-o tabelă traditional disk-based database.” mensională, memoria calculatorului este de fapte cu 100 de miliarde de înregistrări – Shanghai Volkswagen organizată ca o succesiune secvenţială de şi în tabelele de dimensiuni aferente. Setul locaţii. Astfel, decizia de a stoca o tabelă de date reprezintă înregistrările corespunsub forma unei succesiuni de rânduri, zătoare pentru un interval de cinci ani ale respectiv de coloane, poate avea un impact unui modul de SD (Sales&Distribution). semnificativ asupra performanţei aplicaţiei.

Operaţiile alese pentru evaluare sunt de SAP HANA oferă posibilitatea de a natură mixtă, ele acoperiind mare parte din lua această decizie individual pentru fie- activităţile de BI obişnuite: care tabelă, luând în calcul natura acesteia.

• General reporting, Tabelul următor prezintă situaţiile în care • Iterative querying (drill downs), este recomandată utilizare unui „row store”, • Ranking, respectiv a unui „column store”.

• Year-over-year analysis.

Row store

Column Store

Tabelă cu număr redus de rânduri, de ex. tabele de configurare

Operaţii executate pe o singură (sau puţine) coloane

Testul a urmărit atât măsurarea timpului de execuţie al unui query cât şi determinarea throughput-ului (exprimat ca număr de query-uri/oră)

2 Detaliile testului pot fi consultate aici: http:// download.sap.com/download.epd?context=CCBE2C4417A4583A9 6A74DC0E2D820576429CADB38C81772D70FE496C29B362BCB BAB6D377ADC5D7063F40D27A0790298C2238F3F161645E

www.todaysoftmag.ro | nr. 8/2013

27

programare

Code review

C

ode Review-ul este o examinare sistematică a codului sursă. Scopul acestui proces este identificarea și corectarea problemelor trecute cu vederea în faza inițială de scriere a codului, îmbunătățind în același timp calitatea codului cât și abilitățile dezvoltatorilor.

De ce este Code Review-ul important Mădălin Ilie

Madalin.Ilie@endava.com Java discipline lead @ Endava

Steve McConell prezintă în cartea sa Code Complete (http://www.amazon.com/ Code-Complete-Practical-HandbookConstruction/dp/0735619670) câteva argumente foarte bune despre eficiența procesului de Code Review:

•

de defecte care în mod normal ar fi apărut.

Un studiu realizat la compania AT&T a arătat că după introducerea review-urilor numărul de defecte a scăzut cu 90%, iar productivitatea a crescut cu 14%.

Jet Propulsions Laboratories estimează că economisesc 25.000$ per review.

• Testarea softului în sine are eficacitate limitată – rata medie de detectare a defectelor este de 25% pentru unit testing, 35% pentru testarea funcțională și 45% pentru Motivele principale pentru care se integration testing. În opoziție, eficacitatea face Code Review-ul sunt: Code Review-ului si Design Review-ului • Găsirea și fixarea defectelor devreme este între 55%-60%. Studiile de caz penîn procesul de dezvoltare; tru revizuirea rezultatelor aplicării Code • O mai bună înțelegere comună a Review-ului au fost impresionante: codului sursă; • Dintr-o serie de 11 proiecte software • Ajută la menținerea unui nivel dezvoltate de aceeași echipă, primele d e c on s i s t e nț ă î n d e s i g n ș i 5 au fost dezvoltate fără a avea proceimplementare; sul de Code Review, iar următoarele • Ajută la identificarea defectelor 6 au fost dezvoltate folosind și procecomune în echipă si la reducerea sul de Code Review-ul. După ce toate timpului de fixare; cele 11 proiecte au ajuns în producție, • Ajut ă la creștere a încre der ii primele 5 au avut o rată de 4.5 erori stakeholder-ilor asupra calității prope 100 de linii de cod. Următoarele cesului de devoltare; 6 au avut doar 0.82 de erori pe 100 • O înțelegere comună și uniformă de linii de cod. Review-urile au a codului ajută și la reducerea îmbunătățit rata de erori cu 80%. impactului în proiect atunci când • Aetna Insurance Company a găsit anumiți membrii ai echipei devin 82% din erori cu ajutorul Code indisponibili; Review-ului ceea ce le-a permis să • O perspectivă nouă. O altă ”perescadă și numărul de resurse alocate che de ochi” crește gradul de dezvoltării cu 20%. obiectivitate. La fel ca și în cazul • Proiectul Orbit de la IBM utiliza separării între dezvoltare și testare, 11 nivele de review. A fost livrat la Code Review-ul introduce distanța timp și a avut doar 1% din numărul necesară pentru a recunoaște mai

28

nr. 8/2013 | www.todaysoftmag.ro

management

TODAY SOFTWARE MAGAZINE

7.

8.

să faci aceste schimbări în cadrul procesului de Code Review. Nu începe să refactorizezi de unul singur crezând că ai dreptul să faci asta și că ești cea mai bună persoană din echipă, iar restul sunt niște ignoranți.

Singura constanță este schimbarea.

Fii foarte deschis și acceptă lucrul acesta. Cu atât accepți mai repede, cu atât ești mai fericit. Privește fiecare schimbare a cerințelor, platformei, sau tool-urilor ca o nouă provocare.

Luptă pentru ceea ce crezi, dar acceptă cu grație înfrângerea.

Acceptă faptul ca uneori ideile tale vor fi respinse. Chiar de se dovedește că ai dreptate evită să spui „Ți-am spus eu”.

Nu fi „the guy in the room”. Nu fi persoana care stă în colțul lui și singura dată când se ridică de la birou este atunci când merge să iși ia o cafea sau o cola. O astfel de persoană nu se va integra niciodata într-un mediu colaborativ și îi va foarte greu să accepte remarcile rezultate în procesului de Code Review. Întâlnirile de Code Review nu sunt întâlniri pentru rezolvare problemelor. Scopul lor nu e să discutăm toate probleme ce există pe proiect, ci doar punctual review-ul aflat în desfășurare.

Ajută la menținerea standardelor de codare. Oferă-ți ajutorul pentru a adăuga în standardele de codare lucruri care apar la Code Review dar nu sunt încă trecute și în standardele de codare.

ușor problemele; Sfaturi pentru Dezvoltarori Mândrie/recompensă.

1. Primul reviewer este chiar autorul Recunoașterea abilităților este o codului i.e. TU 9. recompensă semnificativă pentru 2. Creează un checklist cu lucrurile mulți programatori; pe care se focusează cel mai mult • Coeziune mai bună a echipei. procesul de Code Review. O astfel de listă ar trebui să fie destul de simPentru a înțelege cât de important este plu de făcut. De obicei, se urmăresc să fixăm cat mai multe defecte încă din faza ideile cele mai importante din stande dezvoltare, aveți mai sus un grafic desdardele de codare. Pentru că este o pre costurile unui defect în diferite faze ale listă personală, te poți concentra pe produsului: ariile pe care știi că ai cele mai mari 10.

Ariile principale pe care se concenprobleme și poți omite ariile despre trează Code Review-ul: care știi că te descurci foarte bine.

• Unit testing, Nu doar că vei reduce numărul de • Documentarea codului și convenții probleme găsite, dar vei face procede codare, sul de review unul foarte scurt, ceea • Tratarea erorilor, ce va face pe toată lumea fericită.

11.

• Resource leaks, 3. Tu și codul sunteți 2 entități dife• Thread Safety, rite. Ține minte că scopul principal • Structuri de cotrol, al review-ulu este găsirea de pro• Performanță, bleme și în 99% din cazuri vor fi • Funcționalitate, găsite probleme. Nu lua lucrurile • Securitate, personal. Unii dezvoltatori au un • Consistență cu designul și arhitecsimț al proprietății și un orgoliu Sfaturi pentru Revieweri tura existentă foarte mare, ajungând chiar să se 1. Critică codul, nu persoanele – fii • Utilizarea corectă a librăriilor identifice cu codul scris. blând cu dezoltatorii, nu cu codul. externe 4. Întelege și acceptă faptul că vei Pe cât posibil comentariile tale face greșeli. Scopul este să le găsești ar trebui sa aibă o nuanță poziRoluri și responsabilități cât mai devreme și să nu ajungă tivă orientate spre îmbunătățirea Dezvoltatorul: este persoana care în producție. Ține minte că doar codului. Încearcă să relaționezi a scris codul ce urmează a fi revizuit și facând greșeli poți să evoluezi. comentariile cu standardele de este cel care inițiază cererea pentru Code 5. Indiferent de cât de multe „karate” codare, specificații, constrângeri de Review. știi, există mereu cineva care sție performanță, securite, etc.

Reviewer/s: sunt persoanele care vor mai multe. O astfel de persoană 2. Tratează cu respect și răbdare revizui codul și vor raporta problemele te poate învăța câteva ”mișcări” persoanele care au un nivel de găsite devoltatorilor. interesante. Caută și acceptă ideile cunoștințe mai scăzut decât al tău.

La fel ca orice altă abilitate, reviewer-ii celorlalți, mai ales când crezi că nu Gândește-te cam cui ai vrea să fii și devin mai buni făcând foarte multă pracai nevoie de ele. tu tratat de persoane care au mai tică. Iată câteva ponturi care vă vor ajuta să 6. Nu rescrie cod fără a te consulta multe cunoștințe decât tine și fă și porniți pe drumul cel bun. și cu echipa. Este o diferență foarte tu la fel cu ceilalți. mică între a fixa codul și a rescrie 3. Adevărata autoritate vine din codul. Învață diferența și încearcă c u n o ș t i n țe , n u d i n p o z i ț i a •

www.todaysoftmag.ro | nr. 8/2013

29

programare Code review

4.

5.

6.

7.

8.

9.

10.

11.

12.

ierarhică. Cunoștințele generează autoritate și autoritatea generează respect. Nu vei fi niciodată respectat dacă spui ”Că așa zic eu!” Întâlnirile de Code Review nu sunt întâlniri pentru rezolvare problemelor.

Pune întrebări în loc să faci afirmații. O afirmație este de obicei acuzatoare: „Nu ai urmat standardele de codare”, chiar dacă nu este intenționat. Spunând ”Care a fost motivarea din urma deciziilor pe care le-ai luat?” încerci să afli informații, nu să acuzi. Încearcă să eviți ”DE CE”-urile.

Deși este foarte dicifil de cele mai multe ori, evitarea întrebărilor de tip DE CE poate păstra o atmosfera degajată în echipă. O întrebare de tipul „De ce nu ai urmat standardele de codare in cazul asta?” Poate fi ușor reformulată spre „Care au fost motivele pentru care nu ai urmat standardele de codare?”

Laudă persoanele atunci când codul lor e ”ca la carte”. Firea umană este construită să aibă nevoie de cuvinte de încurajare și laude, nu doar de critici. De cele mai multe ori un cuvând de încurajare are un efect mult mai bun decât 100 de critici.

Coding Standards. Orice proces de Code Review trebuie să aibă la bază standardele de codare ale proiectului și/sau organizației. Coding Standard este ca un contract între dezvoltatori pentru respectarea calității și mentenabilității codului. Ține minte că mereu există mai mult decât o soluție pentru rezolvarea unei probleme. Chiar dacă dezvoltatorul a urmat altă soluție față de cea la care te-ai gândit tu, nu înseamnă că soluția este greșită.

Nu trebuie să te grăbești atunci când faci Code Review, dar trebuie să fii cât mai prompt. Încearcă să nu depășești 200-400 de linii de cod per review session.

Nu ești ”Dumnezeul” programării. Nu uita că și tu ai fost în etapa în care acumulai cunoștinte și făceai foarte multe greșeli. Doar pentru că ești reviewer nu înseamnă că ai puteri depline asupra codului și a proiectului.

Security Code Review

Dacă aplicația necesită o atenție deosebită asupra părții de securitate, vă

30

nr. 8/2013 | www.todaysoftmag.ro

recomand www.owasp.org. Există și un document de Code Review foarte bun: https://www.owasp.org/images/2/2e/ OWASP_Code_Review_Guide-V1_1.pdf.

Pentru determinarea severității problemelor găsite în timpul code review-ului vă recomandăm nivele de severitate de mai jos: • Naming Conventions and Coding style = Low, • Control Structures and Logical issues = Medium or High, • Redundant Code = High, • Performance Issues =High, • Security Issues = High, • Scalability Issues= High, • Functional Issues =High, • Error Handling = High, • Reusability = Medium.

Reviewerii ar trebui să se concentreze pe nivelele High și Medium.

Checklist-uri pentru dezvoltatori și reviewer

Description Am luat în considerare potențiale NPEs Codul urmează standardele de codare

Am eliminat orice cod redundant sau clase care nu mai sunt folosite Am eliminat orice hardcodări sau development-only code?

Perfomanța a fost luată în considerare?

Securitatea a fost luată în considerare?

Codul eliberează resursele? (HTTP connections, DB Connections, files, etc)?

Cazurile particulare au fost bine documentate?

La fel orice workaround sau limitare

Codul poate fi înlocuit cu apeluri către componente externe resutilizabile?

Thread safety și posibile deadlocks

Checklist-urile sunt o unealtă foarte bună atunci când vrei să nu omiți anumite aspecte și sunt foarte utile atât pentru dez- Checklist pentru Revieweri voltatori cât și pentru revieweri. Omisiunile Description sunt defectele cele mai greu de reparat – Comentarile sunt comclar că nu ai cum să faci review la ceva ce prehensibile și aduc valore mentenabilității nu există. Un checklist e cel mai simplu mod codului prin care poți combate asta.

Comentariile nu sunt Un alt concept foarte folositor este foarte multe și nici checklist-ul personal. O persoană face în foarte amănunțite de date au medie cam aceleași 15-20 de greșeli. Pentru Tipurile fost generalizate acolo a preveni repetarea, încearcă să ții o listă cu unde a fost posibil problemele cele mai întâlnite. Aceasta te va Tipurile parametriajuta și pe tine ca dezvoltator să îți însușești zate au fost folosite corespunzător conceptele respective.

Excepțiile au fost folosite corespunzător

Checklist pentru Dezvoltatori Description Codul se compilează

Confirmed?

Codul duplicat a fost eliminat

Frameworkurile au fost folosite corespunzător

Codul a fost testat de mine și include unit teste

Clasele de tip comand sunt concentrate pe un singur task

Codul este ordonat (spațiere, greșeli de ortografie, nu există cod comentat, etc)

Unit test-ele există și sunt corecte

Codul include javadoc

Am considerat utilizarea corectă a excepțiilor Am utilizat adecvat logging-ul

Am eliminat importurile nefolosite

Am eliminat warning-urile raporte de Eclipse/ Netbeans/IntelliJ

Confirmed?

JSP-urile nu conțin logică de business

Sunt verificări pentru erorile comune

Potențiale probleme de multi-threading au fost eliminate pe cât posibil Eventuale probeme de securitate au fost adresate Performanța a fost luată în considerare

Confirmed?

TODAY SOFTWARE MAGAZINE Description

Funcționalitate se încadrează în designul/arhitectura curentă

Confirmed?

Codul este unit testable Codul nu folosește nejustificat elemente statice

Codul urmează standardele de codare

Logging-ul a fost folosit corespunzător NPEs și AIOBs

Automatizarea procesului de Code Review Pornind de la un document cu standarde de codare, o parte din procesul de Code Review poate fi automatizat. Asta nu înseamnă că rolul de Reviewer nu mai există. Tool-urile care automatizează Code Review-ul, vor elimina mare parte din problemele legate de styling, convenții de denumire, complexitate ciclomatică a claselor, metodelor, cod duplicat, cât de mult acperă unit testele codul scris, probleme minore de design, etc. Nu pot detecta însă probleme majore de design, arhitectură, funcționalitate care sunt specifice proiectului. Voi prezenta mai jos cele mai folosite tool-uri pentru Java.

PMD

sourceforge.net/.

Folosește analiza statică a codului pentru identifiare bug-urilor din cod. La fel ca si PMD are integrare cu cele mai populare tool-uri de building si IDE-uri.

Checkstyle Pagina oficială: http://checkstyle.sourceforge.net/ Este concentrat în principal pe styling, denumiri, cod duplicate, cod duplicat, etc.

La fel ca și PMD are integrare cu cele mai populare tool-uri de building și IDE-uri.

Code Coverage Pentru a verifica gradul de acoperile al codului cu unit teste cele mai populare tooluri sunt: Jacoco, Cobertura și Clover.

Sonar Sonar este un tool care agregă datele prezentate de toolurile de mai sus și le afișează într-o interfață foarte ușor de folosit, oferind diverse rapoarte, grafice, evoluția codului de-a lungul timpului. Pe lângă toolurile prezentate mai sus, Sonar oferă și multe alte pluginuri care ajută la procesul de Code Review.

Sonar oferă integrare cu cele mai populare IDE-uri și tool-uri de building și oferă suport out-of-the-box pentru Java. Poate fi configurat și pentru alte limbaje de programare precum PHP, C++ sau .NET dar cu puțin mai mult efort.

Aveți în partea de jos a paginii o diagramă care prezintă arhitectura Sonar-ului.

(Server se referă la serverul de Sonar).

Pagina oficială: http://pmd.sourceforge. net/.

Este un analizor de cod sursă.

Detectează variabile neutilizate, probleme de styling, denumire, blocuri goale, complexitte ciclomatică, etc. Are integrare cu tool-urile populare de building: Maven și Ant, precum și cu cele mai populare IDE- Controlarea procesului de Code Review uri: Eclipse, Netbeans.

Până acum am prezentat sfaturi despre ce anume se urmărește într-un proces de Findbugs code review și cum se poate automatiza Pagina oficială: http://findbugs. o parte din code review pentru a permite

Reviewer-ului să se concentreze asupra lucrurilor importante și să nu își piardă timpul verificând cât de lungi sunt liniile de cod sau dacă există spații între operatori și operanzi.

Cum e cel mai bine să urmărim progresul: prin email, printr-un fișier excel, doar discutând, folosind tooluri specilizate?

Deși răspunsul cel mai evident este folosirea tool-urilor specializate, fiecare echipă și proiect are particularitățile sale. De obicei, fiecare echipă își găsește propria mecanică care va avea diverse particularități: • Poți avea o regulă ca nimeni nu dă commit în version control system până când un alt coleg nu face code review la cod.

• Fiecare se poate uita pe toate schimbările care vin în momentul în care face update din version control system.

• Există o persoană per zi/per spint/ per iterație care face review pentru toți ceilalți.

• Formăm echipe de câte două persoane și fiecare face code review la celălalt.

• Avem o echipă dedicată de code review formată doar din persoane cu foarte multă experiență.

Dacă sunteți într-un mediu în care folosiți tool-uri de la Atlassian (JIRA, Confluence, Fisheye), alegerea cea mai evidentă este Crucible datorită integrării cu celelalte produse. În momentul de față cred că este cel mai bun tool pentru monitorizarea procesului de code review. Alte alegeri ar mai fi: Gerrit (dedicat proiectelor ce folosesc Git) sau ReviewBorad.

www.todaysoftmag.ro | nr. 8/2013

31

programare

Recenzie carte: Java Persistence with JPA - dr. Daoqi Yang

D

e-a lungul timpului modul în care erau stocate datele a creat numeroase probleme. În cazul dezvoltatorilor de aplicaţii, acestea privesc interacţiunea cu baza de date, partea de organizare a datelor la nivelul modulului de persistenţă

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

32

nr. 8/2013 | www.todaysoftmag.ro

fiind mai puţin importantă pentru un dezvoltator de soft (ex: schemele relaţionale, ierarhice, reţea, semantice etc).

La nivelul performanţei interacţiunii se puneau două probleme importante: scăderea timpului de răspuns şi creşterea gradului de încredere în datele conţinute în baza de date. Rezolvarea acestora depindea de mulţi factori, de la tipul de bridge folosit pentru conexiune şi până la securitate sau la păstrarea integrităţii.

Pe partea de organizare a datelor, la nivelul modulului de persistenţă, modelul relaţional al bazelor de date s-a impus de-a lungul timpului ca modelul cel mai utilizat.

Introducerea numeroaselor constrângeri teoretice ale acestui model (axiomele lui Armstrong http://en.wikipedia.org/ wiki/Armstrong%27s_axioms) precum şi implementarea multora dintre aceste constrângeri au dus la creşterea încrederii, relativ la integritatea datelor.

Revenim la dezvoltatorii de aplicaţie.

Ei lucrează la modulul aplicaţiei şi acesta trebuia să interacţioneze cu modulul de persistenţă. Au existat numeroase căi de realizare a interacţiunii. Patru tipuri de bridge-uri sunt cunoscute, ca posibilităţi de conectare la o bază de date: JDBC-ODBC Bridge, Native-API Driver, NetworkProtocol Driver şi Java to Database Protocol. Fiecare nou tip aducea un plus în creşterea vitezei de răspuns, a numărului de conexiuni disponibile şi a securităţii.

Nu dorim să insistăm asupra acestora, dar

pentru cei interesaţi putem aprofunda subiectul.

Totuşi, oricât de bună era conexiunea existau şi alte provocări: aceasta trebuia creată, trebuiau făcute cereri prin conexiunea creată, iar serverul de baze de date trebuia să trimită un răspuns, dar şi multe altele. Unele dintre acestea s-au rezolvat.

Spre exemplu, există pool-uri de conexiuni.

Conexiunile nu se recrează ci se refolosesc.

La nivelul softului de aplicaţie o problemă majoră mult timp a fost, de asemenea, SQL injection. Aceasta a cauzat distrugeri însemnate sau replicări nedorite ale bazei de date.

Suntem acum pregătiţi să identificăm utilitatea cărţii “Java Persistence with JPA1” scrisă de dr. Daoqi Yang.

Cartea este o expunere de nivel mediu şi avansat a rolului Java Persistence API (JPA) în dezvoltarea aplicaţiilor standalone (cu acces distribuit sau nu – baza de date fiind locală) sau pur distribuite, ce interacţionează cu baze de date, organizate, în special, după modelul relaţional.

Cum am afirmat mai devreme JPA poate fi folosit şi de către dezvoltatorii de aplicaţii standalone, dar performanţa este cu adevărat evidenţiată pentru aplicaţii distribuite, ce folosesc servere de aplicaţie ca middleware. Este şi cazul dezbătut pe larg în această carte. Aspectele legate de EJB, pe care le-am adus într-o altă recenzie trebuie 1 Outskirts Press, data apariției 31 Martie, 2010, http://www.amazon.com/Java-Persistence-JPA-Daoqi-Yang/ dp/1432755854

business

să fie completate de citirea integrală a materialului acestei cărţi.

Versiunea de JPA avută în vedere este 2.0, care a apărut în anul 2009.

Ideea principală este că orice tabelă este mapată unei clase. Mai precis, o linie a unei tabele reprezintă o instanţiere a unei clase, numită şi entitate. O tabelă este, aşadar, o colecţie de clase. Acest proces de mapare este descris în capitolul “Object Relational Management”.

Adnotaţiile implicate sunt descrise tot aici. Pentru cei care cred că ştiu multe, o întrebare: ştiţi care este utilitatea anotaţiei @SecondaryTable? Desigur, detalii în carte la pagina 56, Capitolul 2.2.11.

Tabelele trebuie apoi relaţionate, iar relaţiile sunt mapate prin strategii speciale: atribute instanţă sau colecţii de instanţe ale claselor ce mapează tabele. Pentru creşterea performanţei trebuie avut în vedere tipul de colecţie folosită pentru maparea relaţiilor sau modul în care este reactualizată colecţia, relativ la modificările din baza de date. Toate acestea sunt descrise în capitolul “Relation Mapping”.

Operaţiile pe baza de date se execută într-un context persistent, gestionat de un container, dacă discutăm de folosirea lui într-un server de aplicaţie. Contextul persistent gestionează stările entităţii. Unele

TODAY SOFTWARE MAGAZINE

dintre operaţii nu se pot executa în oricare dintre stări. Descrierea stărilor şi modalitatea de trecere între ele este facuta în “Entity Lifecycle”.

Putem gestiona accesul concurenţial prin diverse modalităţi de blocare a entităţilor. Blocarea optimistă şi cea pesimistă sunt doar două astfel de modalităţi, descrise amanunţit în “Locking and Concurrency”.

Revin la ideea de performanţă în dezvoltarea unei aplicaţii. Cum am putea să alegem între cele două moduri de gestionare a persitenţei: de către container sau de către aplicaţie (user)?

Un alt aspect favorabil al folosirii entităţilor este acela că datele pe care le stocăm în entităţi sunt practic gestionate intern, in memory. Trebuie să profităm de acest avantaj făcând cât mai multe dintre validări la nivelul middleware-ului. De asemenea, folosirea raţională a cache-ului duce la creşterea performanţei.

O altă importantă facilitate oferită de JPA este posibilitatea moştenirii entităţilor. Entităţile fiind clase sunt supuse regulilor POO, deci şi moştenirii. Partea cea mai interesantă este că clasele entitate derivate pot fi, la rândul lor mapate.

Strategiile de mapare duc la alegerea între păstrarea regulilor Formei Normale 3 sau

Boyce Codd, plata fiind un timp de acces mai mare, sau o tabelă cu câmpuri null, dar timp de acces mai redus.

Ultima şi cea mai importantă parte a materialului prezentat este legat de limbajul de interogare folosit pentru accesul la datele din baza de date. Java Persistence Query Language (JPQL) sau Criteria API sunt cele două variante dezbătute. Ele sunt şi cel mai frecvent utilizate.

Prima foloseşte un limbaj asemănător SQL-ului, cu modificări legate de utilizarea claselor în locul tabelelor. Prin introducerea alias-urilor entităţilor posibilitatea de folosire a SQL injection este aproape complet inhibată.

Cea de-a doua variantă foloseşte un limbaj obiect orientat pur. Dacă mai avem în vedere dependenţa de tip introdusă în Java, acest limbaj elimina practic multe dintre erorile ce pot apărea în faza de rulare.

Pe de-a întregul, expunerea conceptelor teoretice de către autor este însoţită de numeroase exemple şi fragmente de cod, care sunt foarte folositoare în înţelegerea deplină a functionalităţilor JPA. Pâna în acest moment cartea poate fi privită ca un ghid complet de utilizare a framework-ului. Dacă avem în vedere însa şi completările aduse de ultimele capitole, cartea devine o referinţă pentru folosirea best practices sau design patterns.

O întrebare, pentru cei ce posedă cunoştinte mai avansate în acest domeniu: aţi folosit vreodată un “thread local pattern”? Un exemplu edificator este dat în această carte începând cu pagina 319, Capitolul 8.1.5.

Cartea se încheie cu un capitol numit “Resources” care furnizează detalii despre tehnologiile folosite.

Poate singura problemă pe care aţi putea să o aveţi în parcurgerea exemplelor acestei cărţi este dată de folosirea serverului de aplicaţie JBoss, în locul frecvent utilizatului Glassfish. Aceasta poate fi interpretată ca pe o provocare, iar diferenţele de configurare sunt minime, cu siguranţă putând fi realizate de oricare dintre cei cărora li se adresează această recenzie.

Aştept, ca întotdeauna, cu mare plăcere comentarii, păreri şi discuţii pe subiectele abordate în această lucrare.

Lectură placută! www.todaysoftmag.ro | nr. 8/2013

33

HR

Managementul echipei

W

orkshop-ul cu tema Leadership si Management organizat ediția trecută a Today Software Magazine, m-a determinat să abordez încă un subiect legat de echipă, leadership și management, datorită interesului manifestat pentru această temă.

S-au adresat câteva întrebări legate de ce înseamnă să fii lider, dincolo de teoria leadership-ului situațional, care sunt limitele coordonării unei echipe sau s-a insistat asupra diferențelor între lider și manager.

Din acest motiv acest articol va debuta cu o scurtă prezentare a rolurilor și responsabilităților unui lider sau ale unui manager. Cum subliniam și în numărul anterior, liderul este cel care crează o viziune și are acei adepti pentru implementarea ei, iar managerul este persoana orientată mai mult pe partea strategică. Aș vrea să se înțeleagă ideea și să se rămână cu ideea: că o persoană poate fi și lider și manager, iar cu cât diferența este mai mică cu atât impactul asupra echipei este mai mare.

Un lider •

•

•

•

•

34

•

se pot baza. Pentru un impact mai mare asupra creării unui climat bazat pe încredere, încurajează și recompensează fiecare rezultat pozitiv, oferă sprijin în situațiile în care membrii echipei au nevoie, face coaching pentru îmbunătățirea abilităților.

Oferă susținere și ajută: este orientat spre rezolvarea problemelor și oferă suport echipei când este nevoie. Încurajează soluțiile, analizează plusurile si minusurile și implementează soluții.

Scoate ce-i mai bun din membrii echipei: prin feedback constant, coaching și alte instrumente creează mediul propice pentru a-și dezvolta membrii echipei și pentru a le valorifica punctele forte.

Ascultă activ: ascultă cu adevărat, ceea ce înseamnă că este empatic cu gândurile și sentimentele celuilalt, adoptă o atitudine înțelegătoare, nu interpretează, nu judecă, înțelege semnificația intelectuală și afectivă profundă a acestor fapte pentru interlocutor.

•

evaluează rezultatele.

Motivează: selecția, comunicarea, implicarea, consilierea, învățarea și dezvoltarea angajațiilor, concedierea acestora.

Pentru o înțelegere cât mai bună a rolurilor de lider și manager vedeți exemplificarea grafică.

Partea a doua a articolului este orientată spre oferirea unei definiții a etapelor formării echipelor și rolul liderului în fiecare etapă. Este mai mult o prezentare teoretică care definește cele 5 etape ale formării echipei. Fiecare etapă are specificul ei din perspectiva sentimentelor dezvoltate de echipă, înțelegerea regulilor, sarcinilor și a obiectivelor.

Creează viziune: are acea imagine • globală și știe cum să își ghideze echipa înspre atingerea ei și definește normele și comportamentele agreate în cadrul echipei.

Susține și implementează schimbaEtapele formării echipei (Tuckman, rea: este persoana care încurajează • 1965) schimbarea și definește pașii necesari pentru o cât mai bună înțelegere I. Formarea (Forming) a procesului de schimbare.

Caracteristici etapă: E deschis la idei noi: încurajează • Sentimentele membrilor echipei: brainstorming-ul și părerea fiecărui »» Teamă; membru al echipei este importantă. »» Comunicarea în cadrul echipei Implementează ideile noi care aduc este îngreunată de nesiguranța un plus de valoare atât în eficenticu care membrii echipei de zarea muncii cât și în organizarea Un manager: confruntă; internă a echipei, pentru atingerea • Planifică: creează un plan de acțiune »» Grupul nu cunoaște scopul său obiectivelor dorite. bine definit pentru atingerea obiecviitorul; Conduce prin puterea exemplului: tive prin definirea strategiei, a »» Implicare puțină și ineficientă; este important ca liderul să se comtermenelor libere, a politicilor și »» Fiecare persoană caută, prin tatoporte în conformitate cu valorile procedurilor adoptate în organizație. nare să își stabilească identitatea pe care le promovează. Liderul este Are de asemenea un rol important în cadrul grupului; cel care definește comportamenîn planificarea bugetelor. tul și comunicarea în echipă. Cu • Organizează: definește sarcinile și • Reguli și obiective: cât liderul este mai transparent în responsabilitățile, deleagă sarcini, »» Obiectivele sunt în mare parte informațiile transmise către echipă, stabilește relații de conducere și rolul stabilite de către manager iar în decizile pe care le ia, cu atât fiecăruia în ierarhia organizațională. deoarece membrii echipei sunt noi membrii echipei adoptă un compor• Coordonează: definește resursele acestea sunt neclare și neînțelese tament asemănător. necesare: oameni, structuri, timpi fără a ști impactul pe care poate să Are încredere: prin acțiunile pe care de execuție, integrare a proceselor. îl aibă asupra business-ului; le întreprinde, transmite că este o • Controlează: definește standarde de »» Regulile nu sunt stabilite; persoană pe care membrii echipei performanță, măsoară procesele, • Sarcinile: nr. 8/2013 | www.todaysoftmag.ro

programare »» »»

Nu sunt cunoscute de către membrii echipei; Nu sunt înțelese;

TODAY SOFTWARE MAGAZINE

•

Rolul liderului •

explicarea strategiei pentru îndeplinirea obiectivelor.

Transformă situațiile conflictuale în situații favorabile care pot generara idei noi, proceduri, norme de lucru.

Este momentul în care membrii echipei se demotivează și există riscul ca să părăsească echipa sau să aibă un randament scăzut, iar rolul liderului în această situație este de a oferi suport și de a fi orientat spre crearea unității în cadrul echipei.

Creează cadrul în care să faciliteze • comunicarea între membrii echipei. În această etapă este indicat organizarea unui team building cu echipa, pentru a facilita procesul de integrare.

Definește împreună cu membrii echipei regulile de lucru în echipă. Îndrumă și ghidează, explică sarci- III. Normarea (Norming) nile și responsabilitățile postului.

Caracteristici etapă: • Sentimentele membrilor echipei: »» Apare consensul, acceptarea, siguranța; »» Membrii echipei încep să aibă încredere unul în celălalt; »» Se dezvoltă un limbaj comun al echipei; Explică viziunea, obiectivele și strategia.

• Reguli și obiective: Comunicarea este mai mult dinspre »» Obiectivele sunt cunoscute și lider către membrii echipei. înțelese; Deciziile sunt luate de către lider, »» Regulile sunt acceptate, deoarece dar încurajează ideile și părerile fiesunt agreate de comun acord; cărui membru al echipei. »» Procedurile de lucru sunt înțelese și aplicate în activitatea de zi cu zi;

• •

• • •

II. Furtuna (Stroming) •

•

Caracteristici etapă: Sentimentele membrilor echipei: »» Sentimente conflictuale, tensiune; »» C o m p e t i ț i e ș i a p a r i ț i a divergențelor și a resentimentelor; »» C o n f l i c t e î n r e l a ț i i l e interpersonale; »» Neîndeplinirea obiectivelor datorită situațiilor conflictuale; »» Lipsă de încredere; Reguli și obiective: Obiectivele sunt cunoscute, dar membrii echipei încă nu aderă la ele, pentru că încă sunt stabilite de către manager, care are o înțelegere mai mare asupra mediului de business; »» Regulile sunt definite, dar nu sunt respectate; »»

Rolul liderului: • Aplanarea conflictelor care pot apărea între membrii echipei, prin reamintirea regulilor de lucru în cadrul echipei definite în etapa anterioară.

• Este în continuare concentrat pe explicarea sarcinilor de lucru și

Rolul liderului: Normarea sarcinilor de lucru si delegarea lor, deoarece angajații deja ajung la un nivel de înțelegere a fișei postului și sunt mult mai confortabili cu îndeplinirea sarcinilor.

• Riscul în această etapă este determinat de faptul că angajații doresc să îndeplinească cât mai multe sarcini de lucru și uneori au tendința de a se interpune peste activitățile celorlalți.

Rolul liderului este de a delimita clar sarcinile de lucru, printr-o delegare eficientă a lor.

• Motivează și oferă suport echipei.

Este un bun coach pentru dezvoltarea abilităților membrilor echipei și pentru creșterea performanței și randamentului la locul de muncă.

•

IV. Performarea (Performing) •

Caracteristici etapă: Sentimentele membrilor echipei: »» Randament ridicat al membrilor echipei, se obține performanță; »» Membrii echipei creEază un grad de interdependență ridicat și la nivel relațional și funcțional; »» Echipa dezvoltă o identitate

comună, care a fost definită pe baza valorilor individuale ale fiecăruia; •

»»

Reguli și obiective: Membrii echipei știu cum să își îndeplineacă obiectivele și își dedică energia în acest sens;

Rolul liderului: Rolul liderului este unul scăzut; Deleagă sarcinile și acordă încredere membrilor echipei în realizarea sarcinilor; • Utilizează resursele la maximul de potențial, în special cele umane; • •

V. Finalizarea (Finalizing) Este ultima etapă, când echipa se destramă, datorită finalizării unui proiect.

Iar ciclul se reia odată cu implicare în alte proiecte.

Atât în teorie cât și în practică nu există o delimitare în timp a acestor etape, deoarece au fost numeroase situații în care etapele au fost ”arse” mai repede. Rolul liderului este unul critic în implementarea procesului de integrare în echipă și de înțelegere a sarcinilor de lucru print-un ghidaj corespunzător oferit de către acesta.

De ținut minte este că cea mai mare provocare este etapa „furtună” pentru că sunt oamenii au personalităţi foarte diferite, iar conflictul va fi inevitabil, din punctul de vedere al împărţiri puterii şi al autorităţii în echipă. Cred că este etapa în care liderul trebuie să le reamintească constant rolul lor şi că fiecare are roluri diferite în echipă. Este cel care trebuie să îi îndrume şi să le schimbe mentalitatea de conflict în mentalitatea de rezolvare a problemelor.

Normarea şi performarea vor veni de la sine. Fiecare îşi cunoaşte responsabilităţile, există coeziune şi unitate, iar rezultatele vor veni implicit. Rolul liderului va fi unul de monitorizare şi de coordonare a sarcinilor printr-o continuă motivare a membrilor din echipă. Recomandabil este ca liderul să își asume rolul de coordonator și dezvoltator al echipei pentru obținerea rezultatelor dorite.

Succes cu managementul echipelor pe care le coordonati!

Andreea Pârvu

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

www.todaysoftmag.ro | nr. 8/2013

35

programare

Lansarea unui site web - paşii de bază

T

eoretic lansarea unui site web nu poate fi mai simplă: scrii zece linii de HTML , îl salvezi într-un fişier denumit index.html şi gata, ai un sit web. Practic, ca siteul să poate îndeplini scopul pentru care a fost conceput, el trebuie să aibă două

calităţi: • să fie utilizabil, • utilizatorii potenţiali să afle despre existenţa lui.

Attila-Mihaly Balazs dify.ltd@gmail.com

Code Wrangler @ Udacity Trainer @ Tora Trading

Articolul acesta va prezenta paşii de bază necesari pentru atingerea acestor scopuri. Inspiraţia pentru acest articol a venit în timpul lansării site-ului it-events.ro, un calendar central pentru toate evenimentele din domeniul IT de pe teritoriul României.

Site-ul este de folos atât pentru cei care vor să participe la evenimente (pentru că pot să fie notificaţi despre toate evenimentele noi în modul preferat - email, RSS, Facebook, Twitter, Google+) cât şi pentru organizatori care pot să se asigure că evenimentul lor nu se suprapune cu alte evenimente similare şi au acces la un grup de oameni interesaţi. Acestea fiind zise, prezenăm ceea ce este necesar unui site web pentru a avea șanse de succes.

Găzduire

Prima întrebare înaintea lansării unui site web este de obicei ”unde să-l găzduiesc?”. Există o multitudine de opţiuni în funcţie de tehnologia folosită şi bugetul disponibil. Recomandările mele personale sunt: • Instanţa micro de la Amazon EC21 - este gratuit timp de un an şi ai control deplin asupra maşinii virtuale (poţi instala orice software care este necesar pentru serviciul tău). Un alt avantaj sunt setările de securitate care sunt destul de stricte.

Dezavantajul este limita de resurse impuse (un procesor, 30 GB HDD şi 613 MB de RAM) care poate crea probleme în cazul în care mai muţi utilizatori accesează în paralel 1 http://aws.amazon.com/free/

36

nr. 8/2013 | www.todaysoftmag.ro

•

site-ul. Este de recomandată testarea performanţei folosind servicii ca blitz.io2 sau un simplu Apache Bench (ab).

Google App Engine3 - Este o soluţie specializată, nu poate să ruleze platforme generale (cum ar fi Wordpress, Drupal, etc). Pe de altă, parte poate fi folosit foarte uşor pentru site-uri statice. În cazul site-urilor dinamice scrise pentru platforma GAE oferă avantajul scalării uşoare şi a fiabilităţii sporite.

/robots.txt

Este un fişier text care precizează roboţilor de căutare (search engine crawlers) ceare părţi ale site-ului să le parcurgă şi pe care nu. E important de ştiut că respectarea regulilor din acest fişier este pur voluntară, deci să nu vă bazaţi pe el ca şi pe o măsură de securitate. Un robots.txt simplu arată în următorul fel: User-agent: * Allow: /

robots.txt se mai foloseşte şi pentru

2 https://www.blitz.io/ 3 https://developers.google.com/appengine/docs/ quotas

tehnologii

TODAY SOFTWARE MAGAZINE la Google poate fi notificat despre existenţa în varianta gratuită. unui sitemap folosind Google Webmaster Tools amintit la punctul anterior.

Verificarea compatibilităţii site-ului cu

Favicon

specificarea sitemap-ului şi vitezei de parcurgere4 a sitului de către roboţii de căutare.

Similar standardului robots.txt există şi mişcarea de humans.txt5 , dar acesta nu este folosit pe scară largă.

Monitorizare

Există două feluri de monitorizare: monitorizarea faptului că site-ul funcţionează - nu a murit serverul web, baza de date, etc. Există o multitudine de companii care oferă astfel de servicii. Pentru IT-Events.

RO folosesc Pingdom 6 care oferă opţiunea de alertare prin SMS gratis pentru un site • monitorizarea vizitatorilor pe site (de unde vin, ce sisteme de operare folosesc, etc). Pentru acesta folosesc şi recomand Google Analytics 7 .

Totodată recomand adăugarea siteului în Google Webmaster Tools 8 şi verificarea periodică a mesajelor de acolo. GWT oferă alerte şi informaţii despre aspecte care sunt de interes pentru proprietarii site-urilor (viteza de răspuns, adrese care nu puteau fi accesate, conţinut maliţios, etc) •

Sitemaps

Este un fişier care conţine lista tuturor paginilor de pe site. E util în cazul în care robotul de căutare are dificultăţi în găsirea tuturor paginilor de pe site sau conţinutul site-ului se schimbă frecvent. Majoritatea platformelor oferă funcţionalităţi pentru generarea automată a sitemap-urilor, de exemplu pe IT-Events.RO folosesc BWP XML Sitemaps9 .

Nu există o denumire standard pentru sitemap-uri, roboţii de căutare îl descoperă prin robots.txt sau prin înştiinţare directă (”ping”). De exemplu robotul de căutare de 4 h t t p : / / e n . w i k i p e d i a . o r g / w i k i / Robots_exclusion_standard 5 http://humanstxt.org/ 6 https://www.pingdom.com/ 7 http://www.google.com/analytics/ 8 https://www.google.com/webmasters/tools/ 9 h t t p : / / b e t t e r w p . n e t / w o r d p r e s s - p l u g i n s / google-xml-sitemaps/

Favicon este o prescurtare de la ”Favorite Icon” şi reprezintă iconiţa care apare lângă titlul site-ului, în lista siturilor favorite şi aşa mai departe. Ajută la crearea identităţii vizuale a site-ului (subconştientul utilizatorilor învaţă să recunoască site-ul pe baza lui). Un alt avantaj este eliminarea erorilor de 404 (”not found”) din jurnalul (log) server-ului web. Acestea apar pentru că navigatoarele cer această resursă în mod automat la vizitarea unui sit, chiar dacă nu există legătură către el în pagină.

Alte fişiere care sunt descărcate în mod automat (şi pot să rezulte în erori de 404 dacă nu există) sunt: • apple-touch-icon-*.png - imagini folosite de navigator pe platformele Apple (iPad, iPhone) pentru a reprezenta situl dacă este salvat pe ecranul principal (un fel de Favicon cu rezoluţie mai mare). Este util adăugarea lui din acelaşi motive ca şi la favicon: identitate vizuală şi eliminarea erorilor 404.

• crossdomain.xml - folosit de Flash pentru a determina în ce mod poate fi accesat site-ul de Flash de pe alte site-uri. Dacă nu se vrea folosirea conţinutul site-ului de pe alte domenii folosind Flash, se poate adăuga un fişier simplu cu următorul conţinut pentru eliminarea erorilor de 404 din jurnal:

diferite programe de navigare

În funcţie de tipul site-ului, utilizatorii vor folosi diferite programe de navigare (browsers). Este important să verificați că site-ul este afişat la fel şi e funcţional folosind toate variantele pe care vrem să le suportăm. O metodă mai uşoară decât instalarea tuturor programelor este folosirea serviciilor de genul BrowserStack13 sau BrowserLab14 . Un alt lucru important este verificarea codului HTML, dacă el respectă standardele W3C folosind unelte cum ar fi validator.w3.org. Acest lucru este important pentru că tratarea codului non-standard variază de la navigator la navigator şi folosind cod standard reducem probabilitatea ca site-ul să fie afişat în mod diferit de navigatoare diferite.

Îmbunătăţirea vitezei de încărcare

Viteza de încărcare este importantă pentru utilizatori dar şi pentru Google care ia în considerare un site rapid ”mai bun” decât un site lent. Există o multitudine de unelte care pot fi folosite pentru măsurarea vitezei dintre care voi menţiona doar patru: • YSlow15 - este o extensie la Firefox de la Yahoo care analizează situl şi sugerează metode prin care poate fi înbunătăţite viteza de încărcare a paginii.

• mod_pagespeed16 - este o extensie la Apache creat de Google care optimizează conţinutul paginii pentru o viteză mai bună.

• CDN-urile (C ontent Deliver y <?xml version=”1.0” ?> <cross-domain-policy> Network) - ajută prin plasarea </cross-domain-policy> serverelor mai aproape (fizic) de utilizator. Un exemplu bun este Trimiterea email-urilor CloudFare17 .

Trimiterea email-urilor a devenit din • Extensii specifice pentru platforma ce în ce mai complicată în zilele de azi din folosită - de exemplu W3 Total cauza email-urilor nesolicitate (spam).

Cache18 pentru WordPress.

Furnizorii de servicii de email au răspuns prin introducerea unor filtre stricte pentru Concluzii a elimina aceste tipuri de email-uri. Astfel Crearea unui site este foarte uşoară. a devenit dificil crearea email-urilor care să Crearea unui site care să fie uşor de folosit nu fie eliminate de aceste reguli. de utilizatori şi de sisteme automate este Pentru simplitate se pot folosi servicii un proces continuu. O listă mai completă precum MailChimp10 . Dacă vrei să trimiţi de paşi pentru maximizarea impactului email-uri de pe instanţe Amazon EC2, tre- site-ului poate fi găsită la webdevchecklist. buie setate Reverse DNS-ul11 (RDNS) şi com. Merită citită şi discuţia asociată de pe SPF12 . Ca alternativă Amazon oferă SNS HackerNews19 .

13 http://www.browserstack.com/ (Simple Notification Services), dar acesta 14 https://browserlab.adobe.com/en-us/index.html 15 https://addons.mozilla.org/en-us/firefox/addon/ este restricţionat la 1000 de mesaje / lună 10 http://mailchimp.com/ 11 h t t p s : / / a w s - p o r t a l . a m a z o n . c o m / g p / a w s / html-forms-controller/contactus/ec2-email-limit-rdns-request 12 http://stackoverflow.com/questions/6688251/ spf-record-for-amazon-ec2

yslow/ 16 https://developers.google.com/speed/pagespeed/ mod 17 http://www.cloudflare.com/ 18 http://wordpress.org/extend/plugins/w3-total-cache/ 19 http://news.ycombinator.com/item?id=5022523

www.todaysoftmag.ro | nr. 8/2013

37

startups

Startup cu bani puțini (II) - Microsoft Bizspark

C

ând am înfiinţat compania (Ab Mobile Apps) una dintre provocări era să ne asigurăm că pe toate calculatoarele noastre rulează soft licenţiat şi că avem access IDE-urile adecvate. Aceasta însemna: Microsoft Windows, Office şi, programând în .net, Visual Studio. Sfătuit de un prieten care trecuse şi el prin această etapă am dat peste programul Bizspark de la Microsoft, program ce se adresează startup-urile şi profesioniştilor în IT. A trecut un an de când am fost accep- Cine este eligibil pentru Bizspark? taţi în Bizspark şi experienţa de până acum Firmele care: este una cât se poate de pozitivă.

• au mai puţin de 5 ani de activitate, • au venituri anuale mai mici de „Ce înseamnă Microsoft Bizspark?” : 1.000.000 USD, Bizspark este un program Microsoft ce • au ca domeniu de activitate creese adresează firmelor/startupurilor ce crerea de produse şi servicii software. ează produse & servicii, prin care ai acces la Dezvoltarea trebuie făcută (cel puţin un număr (limitat dar suficient) de licenţe parţial) pe tehnologii Microsoft. ale produselor Microsoft, access la resurse cloud (Azure), access la servicii/produse Persoanele fizice autorizate sau dezvolale partenerilor Bizspark la preţuri promo- tatorii individuali care: ţionale (sau gratuit), training şi suport.

• doresc să desvolte un produs/serviciu pe tehnologii Microsoft + doresc Licenţele & pachetele oferite prin prola un moment dat să facă pasul de la gram sunt extrem de variate, schimbadu-se PFA/dezvoltator individual la înfiindestul de des. Pentru un „sneak peak” vă ţarea unei firme. puteţi uita la http://www.microsoft.com/ Bizspark/Offers/Default.aspx Acestea sunt criteriile generale - în Concret ce am luat noi din Bizspark funcţie de ce dezvoltaţi/doriţi să dezvoltaţi (până acum): şi a planurilor voastre de viitor veţi fi accep• Licenţe de Windows 7 şi Windows 8 taţi sau nu în Bizspark - asta va fi decis de • Licenţe de Visual Studio (Ultimate comisia de evaluare a cererii voastre. & Professional) - se poate şi Team Notă: va fi mai uşor să accesaţi Bizspark Foundation Server ca şi firma decât ca şi PFA/dezvoltator • Access la Windows Azure - 1500 ore individual. pe maşina virtual „mică” (sau echivalent) pe lună + 10 free websites Cât durează programul? (ce oferă o viteză acceptabilă). Mai Trei ani – licenţele care le primeşti în multe despre Azure prin Bizspark: timpul programului îţi vor rămâne ţie (fără http://www.windowsazure.com/ alte costuri). Adiţional, la terminarea proen-us/offers/ms-azr-0012p. Încă gramului, vei avea acces la oferte ce îţi vor nu profităm la maxim de Azure permite să cumperi mai multe licenţe (dacă (axându-ne pe cloud-ul Amazon) firma a crescut şi ai nevoie de mai mult așa că nu pot da detalii legate de decât ce îţi oferă Bizspark) cu discount. „suficienta“ resurselor oferite dar urmează să forţăm limitele abona- Cum aplic? mentului Azure în viitorul apropiat https://www.microsoft.com/bizspark/ • Access la Pluralsight (3 luni gratuit). SignUp/default.aspx este locul de porNota: ca şi developer nu pot decât nire. Vezi avea nevoie de un Microsoft să recomand cu căldură Pluralsight account (vechiul Windows Live ID) - cu ca şi resursă de traininguri online - care veţi administra Bizspark - şi de răbcalitatea trainingurilor oferite este în dare să completaţi toate informaţiile cerute general excelentă şi îşi merită toţii de Microsoft. Poate s-a schimbat ceva în banii. ultimul timp dar acum un an când am completat noi cererea de admitere a trebuit să

38

nr. 8/2013 | www.todaysoftmag.ro

dăm detalii despre firmă şi ce exact dorim să dezvoltăm. În momentul în care am avut toate informaţiile cerute, toată procedura a durat maxim 1 oră.

După ce aplicaţi, cererea voastră va fi evaluată de Microsoft România sau un partener Microsoft (dacă aţi ales să aplicaţi nu direct la Microsoft ci la unul din parteneri) şi dacă totul merge bine veţi putea beneficia de tot ce are de oferit Bizspark în cel mai scurt timp.

Cum pot afla mai multe?

Pe net http://www.microsoft.com/ bizspark/Faqs.aspx Vorbind direct cu cei ce se ocupă de Bizspark în România: Zoli Herczeg (Zoli.

Herczeg@microsoft.com) şi Simona Lică (v-silica@microsoft.com)

Impresii personale

Legat de ceea ce este cuprins în program: Dacă sunteţi la început de drum şi dezvoltaţi pe tehnologii Microsoft, pe Azure sau pe Windows Mobile atunci Bizspark e pentru voi. Multe beneficii care cer doar seriozitate din partea voastră - nu cred că puteţi găsi un târg mai bun.

Legat de suport şi de relaţia cu Microsoft România: Au fost câteva probleme legate de unele servicii oferite prin Bizspark (în cazul nostru Azure) care însă s-au rezolvat. Relaţia cu cei de la Microsoft România a fost şi este una plăcută - ţi se răspunde la emailuri şi găseşti pe cineva la telefon dacă întâmpini probleme.

Dragoș Andronic dragos@txtfeedback.net CTO @ TXTFeedback

startups

S

TODAY SOFTWARE MAGAZINE

Ecosistemul tech-startups din Cluj

e simte valul startup-urilor în România, iar în Cluj în 2012 au apărut evenimente de nișă și chiar startup-uri care au obținut finanțare/incubare. În ultimele săptămâni am participat la mai multe discuții despre tech startups, investiții și acceleratoare. Dar toate aceste discuții au fost în cercuri mai restrânse și încă nu am văzut un eveniment sau o întâlnire care să îi strângă pe toți care activează sau sunt interesați în acest subiect. Așa că punând toate aceste informații cap la cap, am abordat subiectul la Open Connect Cluj #6 (al cărui rezumat poate fi găsit aici) cu scopul de a scoate la iveală toate ideile și proiectele care împreună ar putea forma un ecosistem tech-startups mai trainic în Cluj (acum fiind tare subțire).

Părea evident că nimeni nu are o vizi- pentru acceleratoarele la care am aplicat că vorba de workshopuri/traininguri de 3-4 une de ansamblu asupra tuturor acțiunilor, totuși e ceva de proiectul acesta (iar acum ore ținute de cineva cu experiență în tema e un fel de agitație browniană, în care nu se văd rezultatele). Ideal ar fi ca evenimen- respectivă, prezentare, case study și eventuse observă, încă, reguli generale și lucru- tele să aibă loc la destul timp între ele ca să ale exerciții. rile mai au nevoie de timp până să se nu se afecteze negativ sau ca să nu intre în Startup Peer Support – mai des orgastatornicească. Iar inițiativele apar și se concurență prea mult pentru participanți, nizate, dar în cerc mai restrâns, în care mai suprapun în timp și conținut. Repet, resurse. startup-erii se întâlnesc și își prezintă o mi se pare perfect normal pentru început, problemă de care s-au lovit iar împreună dar acum cred că ar trebui să intrăm într-o Valley of death cu ceilalți încearcă să găsească soluții (ideea fază de clarificare și comunicare mai bună E perioada imediat următoare după a fost implementată anul trecut de Florin începând de la ce avem acum, cu speranța SW și SL, în care majoritatea inițiativelor Mureșan și au avut loc mai multe întâlniri că se vor completa reciproc și ecosistemul startup-like mor. De exemplu, din cele 11 sub numele de AntreprenoriCluj.info) va crește din contribuția fiecăruia. idei pe care s-a lucrat la SW Cluj 2012, în Toate acestea în diverse locații în Cluj, (paranteză de clarificare, în accepțiunea viață, vizibilă este doar una (am auzit că dar mai ales în locațiile în care aceste mea, startups = “high growth, technology alte 2-3 încă mai respiră, dar încă nu știu startupuri să crească (nurturing space), oriented companies”) nimic concret). Dacă ar fi existat suport unde să poate să aibă ședințe, să fie organieducațional, mentorat (deci non-finan- zate evenimentele menționate mai sus. Aici Acest ecosistem l-aș analiza din punct ciar), probabil erau mai multe în viată. Și pe intervin Cluj Cowork și Cluj Hub. de vedere al dezvoltării unui startup în această latură nu avem nimic ca program fazele incipiente (early startup life). Aici de suport coerent (fiecare se descurcă cum Early-stage mă refer la tipul de evenimente, pro- poate).

Momentul în care un startup este în grame de care are nevoie un startup și Aici putem interveni noi cu ce avem măsură să între într-un accelerator și de unde ecosistemul poate ajuta până în acum în Cluj, prin mai multe tipuri de aici să decoleze mai departe (bineînțeles momentul decolării (investiție, accelerator, evenimente care există sau sunt în curs de aceasta poate să se întâmple și mai repede, monetizare). planificare: nu există o regula clară). Nu avem [încă] Networking – are loc deja prin Open acceleratoare în România, deci accesul Generarea și pre-validarea ideii Connect, Open Coffee (și alte evenimente este mai greu. Dar se zvonește de câteva (Pre-validare în sensul în care o adevă- de IT dar nu neapărat orientate spre startu- inițiative în acest sens și în 2014 sunt sigur rată validare este dată de existența userilor/ puri), iar în curând se va adăuga și Startup că vom avea cel puțin unul, în carne și clienților, iar în această fază vorbim de Invasion. Aceste evenimente poate fi si oase (adică cu bani și cu spațiu fizic). Nu feedback-ul unor oameni cu experiență locul potrivit de dat feedback pe idei de m-aș mira prea tare dacă ar apărea 3 (sub sau potențiali clienți dar în această fază nu startupuri. diverse forme) până în 2015 (în București, există încă un produs al startup-ului).

Startup Lounge – panel talks, discuții Timisoara și Cluj). Dar un accelerator e al Totuși aș putea considera că sun- și informal drinks după program, va fi doilea pas, până atunci avem primul pas de tem bine acoperiți de Startup Weekend organizat organizat o dată pe lună la Cluj făcut: consolidarea ecosistemului. și Startup Live, ambele având rețele Hub (prima ediție va avea loc în februarie) Există și vor apărea mai multe internaționale în spate (Startup Weekend Startup Education Program – vine în informații/inițiative iar schema aceasta nu și STARTeurope), Clujul devine un punct completarea networking-ului, trecerea la se vrea a fi completă. Sigur există și alte în aceste rețele și deci e pe harta lor. Ce următorul nivel: evenimente educaționale proiecte care pot să completeze schema de avantaje vor fi rămâne de văzut, dar sigur pentru startupuri tech pe teme specifice mai sus pentru a da o vedere de ansamblu sunt. De exemplu, faptul că UseTogether a (ex: growth, finances and investment, mai clară. câștigat SW Cluj în 2012 a fost o dovadă lean development, pitching). Practic ar fi Câteva din cele menționate încă nu au avut loc, ci sunt la nivel de proiectare.

Oricum, primăvara aceasta va fi definitorie.

Mircea Vădan mircea.vadan@gmail.com Co-fondator și coordonator @ Use Together

www.todaysoftmag.ro | nr. 8/2013

39

HR

Managementul de personal in domeniul SAP

D

ezvoltarea profesională în mediul SAP/ABAP, Java vs. ABAP, Talent Management şi cei trei ‘de ce’ legaţi de acest limbaj de programare. Având în vedere că activităţile mele nu coincid cu cele ale unui HR Manager care este responsabil pentru partea de HR “industrial” al unei companii şi nici cu profilul unui Specialist în Recrutare, ideea de a scrie acest articol are la bază situaţiile pe care le întâlnesc în interacţiunea pe care o am zi de zi cu colegii din departamentul de care sunt responsabilă, care în proporţie de 90% sunt dezvoltatori sau consultanţi ABAP .

De ce diferă segmentul SAP/ABAP de celelalte segmente ale IT-ului şi care sunt provocările în zona HR, respectiv a dezvoltării profesionale în această nişă? Sunt câteva idei pe care le veţi regăsi în rândurile care urmează.

De ce ABAP? Fiindcă în momentul de faţă ABAP-ul este unul dintre limbajele de programare care trece printr-o perioadă de maximă ascensiune caracterizată de inovaţie şi schimbări, adaptându-se cu uşurinţă la schimbările care au loc la nivel de business şi tehnologie. ABAP-erii susţin că este momentul în care este mai plăcut ca oricând să experimentezi în ABAP şi salută cu încredere “The Age of HANA – Evolution or Revolution?”.

De ce văd un viitor în ABAP şi recomand cu căldura această nişă IT mai puţin accesibilă publicului larg? Întâlnesc tot mai des situaţii şi discuţii vaste de cele mai multe ori de natură tehnică pe tema Java vs. ABAP şi de fiecare dată ajung la aceeaşi concluzie; dacă există dezinteres pentru acest limbaj de programare, atât de cunoscut şi utilizat la nivel mondial şi ceva mai low profile în România, de ce se discută şi se investeşte totuşi atât de mult timp în rândul programatorilor dezbătând pe această temă – care limbaj de programare este mai interesant? unde există şanse optime de dezvoltare? cine foloseşte cele mai noi şi interesante tehnologii? O veşnică competiţie verbală care de cele mai multe ori se încheie fără a declara un câştigător.

Este destul de simplu, cu ABAP şi cu SAP (mă refer aici la tehnologiile ERP) şansele de dezvoltare profesională cresc vertiginos atât pentru informaticieni cât şi pentru persoanele specializate în alte domenii tehnice sau socio-economice.

Pentru mine ca fost utilizator al platformelor SAP FI, MM, HR… este mai mult decât o oportunitate să lucrez împreună cu cei care stau în spatele acestor arhitecturi facilitând la maximum munca de zi cu zi a clientului şi făcând posibilă folosirea unui

40

singur sistem care să susţină diferitele arii ale unui business. Dacă ERP-ul funcţionează la parametrii optimi înseamnă că relaţia client -> consultant - > developer a funcţionat perfect.

Fiecare a înţeles care sunt nevoile celuilalt, a înţeles care sunt cerinţele business-ului şi a ştiut să le transmită mai departe, colaborarea dintre cele trei părţi funcţionând cu succes.

Totodată am observat o anume deschidere către nou şi necunoscut a celor care se hotărăsc să înceapă o carieră în ABAP fie ei tineri de pe băncile facultăţii sau arhitecţi suprasaturaţi de specificul limbajelor de programare folosite de-a lungul anilor şi a proiectelor aferente, în căutare de inovaţie. În această direcţie se pot observa cu uşurinţă două tendinţe perfect delimitate: cei care nu recunosc ABAP-ul ca fiind un limbaj competitiv de programare şi care refuză din start o colaborare în acest domeniu şi persoanele nonconformiste, care au curiozitatea de a încerca şi de a explora o altă latură a lumii IT. În acest punct îşi intră în rol şi departamentele de HR şi dezvoltare profesională care în strânsă legătură cu managementul de profil al acestei nişe, clădesc următorii ani din cariera viitorilor consultanţi SAP. Este bine de ştiut că primii doi până la trei ani din cariera unui dezvoltator sunt hotărâtori şi formează baza viitorului său profesional în acest domeniu.

Cei care trec cu brio această perioadă vor fi integraţi în echipele internaţionale care susţin şi dezvoltă sistemele ERP ale marilor companii.

Astfel, în zilele noastre, dezvoltarea profesională specifică acestui mediu nu se mai limitează doar la a ajunge un bun programator, ci solicită un specialist în IT cu profunde cunoştinţe tehnice, de comunicare şi o cunoaştere amănunţită a domeniului pentru care dezvoltă, însumând astfel de trei ori mai multe cerinţe decât în anii trecuţi; să nu trecem însă cu vederea nici ridicarea ştachetei în ceea

nr. 8/2013 | www.todaysoftmag.ro

ce priveşte disponibilitatea de a călători pe termen lung, cunoaşterea mai multor limbi străine cât şi gradul de sociabilitate, capacitatea de a negocia şi potenţialul de leadership.

Din punctul meu de vedere deficienţele acestei nişe sunt destul de puţine şi foarte uşor de remediat. Pe de-o parte faptul că la noi în ţară se mai şchiopătează la partea de prezentare a avantajelor programării în ABAP şi a diferitelor modele de consultanţă înspre care se poate îndrepta proaspătul dezvoltator. De asemenea se remarcă la lipsa aproape totală a prezentarii produsului finit şi al avantajelor pe care acesta le oferă utilizatorului final. Pe de altă parte... există undeva comoditatea specifică generaţiei tinere de a se lansa în carieră şi de a-şi clădi viitorul cu tehnologii accesibile, deja cunoscute şi folosite. Să accesezi o zonă nouă înseamnă să ieşi din cutie şi să fii interesat să cunoşti şi altceva. Intereseul de a cunoaşte la rândul lui presupune studiu suplimentar, iar studiul suplimentar presupune interes şi sacrificarea unei părţi din timpul tău liber, aşadar lesne de înţeles de ce majoritatea preferă varianta cea mai simplă. Închei acest articol cu speranţe mari în ceea ce priveşte viitorul Talent Managementului în zona ABAP în Cluj-Napoca.

Ieşiţi din zona de confort, testaţi şi alte tehnologii disponibile în IT în afara celor cu care sunteţi obişnuiţi, surprize plăcute şi neaşteptate există întotdeauna, dar aceasta rămâne să alegem fiecare dintre noi.

Oana Oprean oana.oprean@msg-systems.com Center of Competence Manager @ .msg systems Romania

diverse

Gogu și vaca lui șefu’

Gogu se uită pentru a suta oară la ceas, era deja exasperat, trecuseră două ore fără vreun rezultat palpabil. Avea senzația că băteau câmpii cu grație și de câte ori se apropiau de vreun punct de decizie, invariabil intervenea cineva din vreunul dintre departamentele implicate și dădea toată discuția peste cap. Șefu’ încercase la început să se impună

Simona Bonghez, Ph.D.

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

41

dar erau acolo și șefii celorlalte departamente și la orice încercare a lui, săreau și ei, să nu rămână mai prejos. Inițial scopul principal părea să fie identificarea vinovatului, musai din departamentul altcuiva.

Vânătoarea de vrăjitoare nu păru însă să se soldeze cu vreun rezultat, fiecare departament apărându-se cu îndârjire; salvarea venise în momentul în care cineva menționase o eroare a clientului. Fusese o cotitură esențială în desfășurarea întâlnirii care, din acel moment, se axase pe identificarea tuturor problemelor cauzate de client, de răspunsurile lui, de lipsa de răspunsuri sau de însăși pura existență a lui. Discuția degenerase într-o jeluire monotonă, în care fiecare își plângea de milă și concluziona invariabil vina clientului. Șefu’ era din ce în ce mai tăcut, îngândurat, întunecat.... Într-o ultimă încercare de a finaliza cu oarecare rezultat întâlnirea, se ridică și se oferi să treacă pe flipchart care ar fi pașii următori, cine ce ar trebui să facă și până când. În aceeași tendință de până acum, toate sarcinile au fost puse în cârca clientului, iar Șefu’ declarase încheierea întâlnirii.

Gogu se precipită spre ușă, cu intenția clară de a avea un schimb de păreri cu Șefu’, dar

nr. 8/2013 | www.todaysoftmag.ro

acesta nu părea să mai aibă chef de discuții.

Aruncă peste umăr o singură remarcă, care îl poziționă pe Gogu în bezna cea mai neagră: - Și-apoi om vedea noi ce ne dă vaca...

- Care vacă, ce vrei să... – se trezi Gogu vorbind singur. Ce-are vaca de-a face cu discuția asta aiurea? Uff...

Se duse să-l găsească pe Mișu în speranța deșartă că acesta ar putea să-i explice ce e cu vaca. În câteva minute, tot departamentul lui Gogu era pus la curent cu desfășurarea super-întâlnirii și a magnificelor sale rezultate. Nimeni însă n-avea idee ce caută vaca în propoziție; animalul, așa domestic cum era, reușise să declanșeze o nebunie generală: presupunerile, dar și replicile acide, curgeau: - Vaca e mulsă, nu? Probabil vrea să...

- Să ce? Să mulgă clientul sau poate pe Șefu’ cel mare, hă-hă...

- Poate n-a auzit Gogu bine și nu era vacă, era vacanță sau vacarm, sau poate vacant?!

- Îhîm, și-a vrut să zică să îți iei tu vacanță și să lași locul vacant, că oricum numa’ vacarm faci!

- Inteligentule. Ai glume în program

diverse

Gogu și vaca lui șefu’

azi? Poate s-a gândit la laptele praf și-a vrut să zică că erați toți praf...

- Și care e legătura, mă, cu vaca? Că din câte mi-aduc aminte, vaca nu dă lapte praf!

- Ba da, mă, dac-o arunci din avion. Ho-ho-ho...

- Ce să spun! E răsuflată asta.

- No stați mă, că îi simplu dacă știi contextu’, interveni Mișu. Șefu’ era supărat încă de când o plecat că nu s-a trimis agendă înainte de întâlnire, nu s-o anunțat nici durata, nimic n-o fost planificat. Știți și voi cât de mult ține la chestiile ăstea: Failing to plan is planing to fail – recită Mișu, cam pompos, zicala favorită a Șefului.

- Aha, așa e mă Mișule, că deștept ești, mi-aduc aminte când eram mic la țară, vaca nu stătea la muls dacă nu-i trimiteai înainte agenda...

- Bine că ești tu deștept. No, gândiți-vă și voi, de câte ori nu ne-o zis, agenda e musai de trimis înainte, să știe tot omu’ de ce se duce și ce-o să discute, cât durează și cine participă. Și-ntotdeauna nu trage el o concluzie la fiecare subiect, să nu batem noi câmpii degeaba ci să știm musai care e rezoluția la fiecare subiect. No, dacă aici îi cum zice Gogu, înseamnă că s-o enervat Șefu’ și pe bună dreptate. Că nimic nu s-o făcut ca la carte...

- Și unde-i vaca?! Întrebă Gogu, aproape resemnat. Tu ai dreptate, Mișule, așa se face dacă vrei să ai rezultate concrete în și după o întâlnire, da’ dilema noastră era legată de rumegătoare.

Mai comentaseră unii, mai emiseră păreri, dar era clar că nu se ajungea la o explicație rezonabilă. Șefu’ nu mai reveni în departament, așa că misterul nu se lămuri până la sfârșitul programului.

Gogu își termină treaba și plecă acasă fără să se mai gândească la misterul vacii.

- Tata, ce ne dă nouă vaca?

Gogu înțepeni. Era a doua oară în ziua respectivă când rumegătoarea insolentă apărea în discuții tam-nesam, fără ca el să aibă cea mai vagă idee despre ce e vorba. Se uită încruntat la fi-su care stătea senin în fața lui: nu, n-avea cum să știe de discuția de la servici. Totuși, se vedea clar că savurează momentul, probabil că se vedea că l-a pus pe taică-său în încurcătură. Începe să-mi semene din ce în ce mai mult, gândi Gogu cu satisfacție, dar nu lăsă să se vadă nimic, ba dimpotrivă, se răsti la cel mic: - Ce-ți veni și ție cu vaca asta?! E o întrebare de grădiniță, ori dacă îmi amintesc eu bine – dar corectează-mă dacă greșesc – ultima oară cand am verificat, parcă erai la școală. Mă înșel?

- Măi tata, măi, ți-am pus o întrebare simplă. Dacă nu știi răspunsul, mărturisește că nu știi, asta e, până la urmă nu poți să le știi pe toate, nu-i așa?

Clar că seamănă cu mine, își spuse Gogu, de data asta întrebându-se dacă e un lucru bun. Era clar că trebuia să dea un răspuns. Să fi avut totuși vreo legătură cu vaca șefului? Ntz...

Enervat, încercă răspunsul clasic: - Lapte, carne... ăăă...brânză și unt, căpătă el curaj. Mulțumit?

42

nr. 8/2013 | www.todaysoftmag.ro

- Ha-ha, tata, ntz! Nici măcar nu ești pe-aproape. Vaca ne dă nouă..., luă el tonul de copil de grădiniță și luă o pauză teatrală, ... balegă! Continuă apoi satisfăcut de figura total siderată a tatălui: Că pe-alealalte ni le luăm noi, ea de bună voie nu ne dă decât câ... bălegar, se corectă repede; tatăl lui nu vedea cu ochi buni folosirea unui anumit tip de limbaj.

Gogu însă nici nu-l mai auzea. Asta era, deci, problema lui Șefu’, degeaba așteptăm noi rezultate bune dacă nu suntem proactivi și nu lucrăm împreună cu clientul. Al naibii șef, a naibii rumegătoare...

sponsori

powered by