TSM_8_2013_ro

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

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

M AG A Z I N E

Educație.Antreprenoriat.StartupWeekendProvocărileunuilider-parteaIIstoriaIT-uluiClujean(III)Particularităţialeproiectelorinfor-maticeOmniprezențaaplicabilitățiiînecosistemulpersonalProblemearhitecturaleînproiecteLiferaySEOlocalprinintermediulGoogle+Punctedescalabilitatepe“cloud”In-MemoryDatabase-Platformareal-timeSAPHANACodereviewRecenziecarte:JavaPersistencewithJPA

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 do-meniul SAP Gogu

6Educatie.Antreprenoriat.

StartupWeekendEchipa Startup Weekend

7Provocările unui lider

- partea IMartin Mackay

9Istoria IT-ului

Clujean (III)Marius Mornea

11Particularităţi ale

proiectelor informaticeDan Suciu

14Omniprezenta aplicabilitătii

în ecosistemul personalBogdan Nastasa

17Probleme arhitecturale în

proiecte LiferayAlexandra Coldea

20SEO local prin

intermediul Google+Radu Popescu

22Puncte de scalabilitate

pe “cloud” Radu Vunvulea

25In-Memory Database -

Platforma real-time SAP HANA

Horea RațiuVictor Ionescu

28Code reviewMădălin Ilie

32Recenzie carte: Java Persistence with JPA Silviu Dumitrescu

34Managementul echipeiAndreea Pârvu

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

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

39Ecosistemultech-startups din ClujMircea Vădan

40Managementul de personal in domeniul SAPOana Oprean

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

4 nr. 8/2013 | www.todaysoftmag.ro

Salut,

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 review-ul 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 eveni-mentului 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

Ovidiu Măţan, [email protected]

Fondator și CEO alToday Software Magazine

editorial

5www.todaysoftmag.ro | nr. 8/2013

TODAY SOFTWARE MAGAZINE

Redacţia Today Software Magazine

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

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

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

Colaborator marketing: Ioana Fane [email protected]

Colaborator social media: Rodica Manolache [email protected]

Traducător: Cintia [email protected]

Reviewer: Tavi Bolog [email protected]

Reviewer: Adrian Lupei [email protected]

Produs de Today Software Solutions SRL

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

www.todaysoftmag.rowww.facebook.com/todaysoftmag

twitter.com/todaysoftmag

ISSN 2284 – 6352

Copyright Today Software Magazine

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

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

www.todaysoftmag.rowww.todaysoftmag.com

Silviu [email protected]

Consultant Java@ .msg systems Romania

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

Alexandra Coldea [email protected]

Java Developer @ ISDC

Mădălin [email protected]

Java discipline lead@ Endava

Attila-Mihaly [email protected]

Code Wrangler @ UdacityTrainer @ Tora Trading

Andreea Pâ[email protected]

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

Radu [email protected]

Senior Software Engineer@iQuest

Simona Bonghez, [email protected]

Speaker, trainer și consultant în managementul proiectelor,

Owner al Confucius Consulting


QA și Web designer @ Small Footprint

Lista autorilor

Horea Rațiu [email protected]

Director Departament SAP @ .msg systems Romania

Martin [email protected]

CEO @ Neverfail Group.

Dan [email protected]

Director of Delivery@ 3Pillar Global

Bogdan [email protected]

UX/UI Design Lead @ Endava

Dragoș [email protected]

CTO

@ TXTFeedback

Victor Ionescu [email protected]

SAP IT Consultant @ .msg systems Romania

Mircea Vă[email protected]

Co-fondator și coordonator@ Use Together

Oana Oprean [email protected]

Center of Competence Manager@ .msg systems Romania


startup

Educație.Antreprenoriat.StartupWeekend

Sergiu Biriș susține că direcția adop-tată 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.”

AntreprenoriatPentru a susține formarea unui mediu

propice dezvoltării indutriei IT și respec-tiv a antreprenoriatului informatic, în anul 2012 s-a înființat în Cluj Napoca, IT Cluster. Aceasta este o dovadă a fap-tului 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 nega-tiv (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 demon-stra că se poate și la noi exact la fel ca și în Sillicon Valley.

Startup WeekendStartup Weekend, parte integrantă

a Kaufman Foundation este una dintre mișcările cele mai ample la nivel mondial care încearcă să ofere participanților săi un mediu de dezvoltare și optimizare a calităților antreprenoriale. Dacă în sălile de curs, antreprenoriatul rămâne la un nivel mai mult sau mai puțin teoretic, aici sunt 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 antrepre-norial 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 antre-prenorial 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 for-mează oamenii de afaceri de mâine, acolo unde ideea nu este cel mai important

ingredient al unei afaceri de succes, unde echipa valorează la fel de mult ca și vizi-unea, iar mentorii sunt acolo ca să indice direcții.

EducațieSub 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.

Echipa Startup Weekend

[email protected]



Provocarile unui lider - partea I

Așteptările de la un nou lider sunt mari. Toate părțile interesate doresc să vadă schimbări rapide, îmbunătățirea per-spectivelor 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 condu-cere 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 schim-bare, î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.

Există , des igur, multe mo dur i diferite în care un lider poate stabili credi-bilitatea și aborda procesul de planificare

a schimbării. Comportamentele necesare în vederea stabilirii autenticității, care sta la baza conceptului de leadership de suc-ces, 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 vizi-une poate avea un efect foarte negativ dacă ne gândim la afirmații fără sens pline de buzzwords sau ne aducem aminte de dez-bateri 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 stabi-lit în termeni financiari (deși, așa cum vom vedea rezultatele sunt cruciale), ci în termeni mai largi pentru a oferi compa-niei 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, elemen-tul cel mai important dintre toate: pentru ca viziunea să fie inspiratională,aceasta trebuie să fie atât aspirațională, cât și rea-lizabilă. Pentru a fi realizabilă, trebuie să existe o cale clar definită. Strategia de afa-ceri este calea clară.

Strategia are în esență trei teme: ino-vare, intimitatea clientului și excelența op e r aț i on a l ă . L i d e r u l t re bu 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 produse-lor 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 impor-tant pe care liderul trebuie să il adopte este autenticitatea. Acest lucru este absolut fundamental, pentru că un lider autentic

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.

business


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 ierar-hice 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 vii-toare și doresc să se simtă ca făcând parte din companie, astfel încât este sa fie evi-dent 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 proce-sul 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

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 market-ing. 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 nos-tru! Trebuie să ne asigurăm că numele nostru se ridică la nivelul așteptărilor, astfel încât aplicatiile critice de business ale clien-tilor nostri să nu dea greș niciodată.

Deci, cu viziune, strategie, încrede-rea internă și externă stabilită, am ajuns la elementul final al arhitecturii noastre: rezultatele financiare. Rezultatele financi-are sunt absolut cruciale, deoarece acestea sunt o dovadă obiectivă a succesului pla-nului 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 concen-treze 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

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

Deci, procesul în cinci pași de stabi-lire 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 schim-barea. 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 [email protected]

CEO @ Neverfail Group.

istorie


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

istorie

Am ales ca și punct de pornire efortu-rile 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ă terme-nul de Departament de Calculatoare. Departament prolific, care la doar doi ani de la înființare construiește primul cal-culator cu relee MARICA (1959), urmat de DACCIC-1 (1963) cu tuburi electro-nice ș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ști-Mă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 impor-tantă, 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

ș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 clu-jean. 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 colec-tiv 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 asu-pra 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

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, admi-nistrative ș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 con-tribuit 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ă constru-iască 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.

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.

Marius [email protected]

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



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

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

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

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

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

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

Romanian Association for Better SoftwareComunitate dedicata oamenilor cu experienta din IT indiferent de tehnologie sau specializare.Website: http://www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 193/ Nr. Evenimente: 11

Comunitatea TSMComunitate construita in jurul revistei Today Software Magazine.Website: http://www.todaysoftmag.roData înfiinţării: 06.02.2012 / Nr. Membri: 389 / Nr. Evenimente: 5

Am 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 con-certat 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.

Calendar

Februarie 6Monthly Meetuphttp://www.meetup.com/Tabara-de-Testare-Cluj/

Martie 1-3Startup Weekend - Recomandat TSMhttp://cluj.startupweekend.org/

Joi/săptămânalOpenConnecthttp://www.facebook.com/groups/355893314491424/

Miercuri/bilunarOpenCoffeehttp://www.facebook.com/opencoffeecluj

Comunităţi IT Cluj-Napoca

comunități

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

Menţiuni: Cluj Perl Mongers (www.cluj.pm), ITSpark (http://itspark.ro/default.aspx), CodeCamp (http://www.codecamp.ro/), Cluj Mobile Developers (http://www.meetup.com/Cluj-Mobile-Developers/), CodExpert (http://www.codexpert.ro/), PHPRomania (http://www.phpromania.net/), ARIES (http://www.aries.ro/).

programare



Unul dintre cele mai intens citate rapoarte statistice cu privire la succe-sul proiectelor informatice este Standish Group Chaos Report, care an de an publică rezultate procentuale ce evidenţiază ponde-rea proiectelor finalizate cu succes, a celor eșuate precum și a celor care au întâmpi-nat 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 neres-pectă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

1994 16% 53% 31%

1996 27% 33% 40%

1998 26% 46% 28%

2000 28% 49% 23%

2002 34% 51% 15%

2004 29% 53% 18%

2007 35% 46% 19%

2009 32% 44% 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 infor-matice doar din Statele Unite ale Americii. Pentru 2004 raportul precizează că au fost luate în considerare peste 50000 de pro-iecte din întreaga lume (58% SUA, 27% Europa, 15% rest), cei de la Standish Group International asigurându-ne că s-a respec-tat 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 pro-iect luând în considerare doar criteriile scop, timp și ban. Calitatea produsului sau

Particularităţi ale proiectelor informatice

Unul 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ţi-eze și analizeze principalele aspecte caracteristice proiectelor informatice.

programare

Dan [email protected]

Director of Delivery@ 3Pillar Global


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 expe-rienţ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 gestiona-rea 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ăsurabilDin 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 nece-sar 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 implemen-tarea 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,

autori M. Norris, P. Rigby, M. Payne) care face un experiment chestionând un număr de 44 de experţi în legătură cu numărul de instrucţiuni care apar în codul de mai jos:#define LOWER 0#define UPPER 300#define STEP 20main(){ int fahr; for (fahr=LOWER; fahr<=UPPER; fahr=fahr+STEP) printf(„%4d %6.1 f\n”, fahr, (5.0/9.0*(fahr-32)))}

Răspunsurile acestora cuprind toate numerele între 1 și 9 inclusiv (11 experţi au răspuns 6, alţii 11 au răspuns 9, restul ale-gând ca răspuns un alt număr din interval)! Concluzia este imediată: dacă niște experţi în domeniul software nu reușesc să cadă de acord asupra unei întrebări simple pe baza unui program de 9(!) linii, înseamnă că este de așteptat ca estimările într-un pro-iect software să difere foarte mult de la o persoană la alta, aceste estimări având o

relativ restrânsă legătură cu experienţa acumulată.

O practică uzuală este aceea ca estimările date (atunci când este vorba de estimări de timp și nu în puncte de complexitate) să fie mărite cu 20% de către project manager înainte ca ele să fie transmise către cli-

ent, pentru a se asigura o oarecare “liniște” (deși sunt situaţii în care acest 20% este departe de a fi suficient).

O altă consecinţă directă a acestui aspect o reprezintă dificultatea gestionării schimbărilor într-o echipă de proiect, per-soanele care vor înlocui anumiţi membri ai echipei rareori respectând estimările date de aceștia.

Și pentru ca lucrurile să fie “complete”, pentru multe dintre activităţile estimate este foarte dificil de controlat progresul. Cele mai reprezentative exemple aici sunt activităţile de analiză și proiectare unde putem știi când s-au terminat aceste acti-vităţi, dar nu vom putea specifica dacă la un moment dat ne aflăm la 50% la 75% din activitatea respectivă.

2. Softul este invizibil şi intangibilRezultatul muncii unei echipe ce dez-

voltă un produs informatic este compus dintr-o colecţie de “texte” de diferite tipuri: documente de analiză și proiectare, cod sursă, manuale de utilizare și operare etc. Doar o parte dintre acestea interesează sau au vreo semnificaţie pentru cei care vor uti-liza produsul.

Clientul final tinde să evalueze un pro-dus informatic după ceea ce vede, și ceea

ce vede este în general o interfaţă grafică cu utilizatorul.

Deoarece nu există nimic concret de arătat clientului în faza de analiză a cerin-ţelor, acesta își formează o imagine proprie asupra rezultatului final care de cele mai multe ori nu se potrivește cu produsul dez-voltat. În plus, există tendiţa de a include în cadrul specificaţiilor elemente care repre-zintă mai degrabă dorinţe decât nevoi reale de business. Se ajunge astfel într-un punct caracterizat de un grad ridicat de frustrare, în care echipa de proiect știe că a dezvol-tat conform specificaţiilor funcţionale dar clientul nu poate utiliza aplicaţia finală pentru că nu este ceea ce și-a imaginat că va fi. Acest rezultat poate fi ameliorat prin prezentarea unuia sau mai multor pro-totipuri în fazele timpurii ale dezvoltării produsului, însă clientul nu va face întot-deauna diferenţa între acestea și produsul final crezând că nu s-a depus un efort sem-nificativ între timp, interfaţa cu utilizatorul rămânând aproape neschimbată.

Tot din cauza invizibilităţii softului și implicit a complexităţii acestuia, cerin-ţele iniţiale par foarte ușor de modificat și implementat în cadrul unei aplicaţii.

3. Softul are o complexitate ridicatăFără doar și poate produsele software

au o structură extrem de complexă. Într-o aplicaţie de dimensiuni medii există extrem de multe conexiuni între diverse elemente software care fac aproape imposibilă tes-tarea și validarea completă a acestora. Un exemplu simplu în care folosim nouă condiţii succesive intercalate poate rezulta într-un număr impresionant de căi posibile care trebuie testate fiecare în parte pentru o validare completă. Acest lucru însă ar putea să nu fie realizabil nici într-o săptă-mână, chiar dacă testul fiecărei căi ar dura o secundă. Mai mult, aceste teste ar trebui reluate de fiecare dată când se face o modi-ficare. Prin urmare multe dintre bug-uri persistă o vreme îndelungată (chiar ani de zile) într-o aplicaţie până să fie descoperite sau, mai rău, până să își arate efectele.

După cum se spunea în aceeași carte menţionată anterior, “The Healthy Software Project: a guide to successful development”: “...în cazul proiectelor software aşa numi-tele proceduri de control al calităţii au uneori de-a face mai degrabă cu limitarea defecţiunilor decât cu garantarea calităţii produsului final.“ Și acest lucru a rămas valabil și în 2012, în ciuda tuturor meto-dologiilor moderne de dezvoltare a softului apărute în ultimii ani.

Complexitatea softului este dată și de

programare



numărul de tranziţii și “traduceri” ce tre-buie realizate între fazele ciclului de viaţă al unui produs. Specificaţiile funcţionale (redactate în limbaj natural) sunt transla-tate într-un model de analiză (diagrame vizuale care modelează toate soluţiile posi-bile 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 spe-cifică), care mai apoi este translatat în cod sursă, acesta din urmă fiind translatat într-un model executabil (prin compilare sau interpretare). Tot acest lanţ de translatări, în ciuda faptului că anumite tranziţii sunt automatizate, face procesul de dezvol-tare 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 specifi-care sau analiză până în modelul executabil.

4. Softul este dinamicDinamismul cu care se confruntă pro-

iectele 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 framewok-urilor 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 echi-pei 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 per-sonalului, 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 nive-lul 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 profesio-nală. 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 res-ponsabilitatea î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 frec-vente 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 dezvol-tarea medologiilor Agile care includ acest aspect ca pe o componentă activă a proce-sului de dezvoltare.

ConcluziiAm încercat să evidenţiem unele dintre

aspectele care considerăm că diferenţiază în mod clar proiectele software de alte

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 pro-iect software întârziat nu elimină decalajul ci sporește întârzierea, deoarece capacita-tea de efort a membrilor echipei scade cu o cantitate egală cu efortul de comunicare cu noul membru. Aceste lucruri nu se întâm-plă î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 sof-tului 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, indus-tria 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ă eronat, le acceptăm, trecem cu ușurinţă peste multe dintre aceste erori sau găsim căi de ocolire a lor deoarece avantajele obţi-nute pun în umbră aceste neajunsuri.


Într-un astfel de mediu, o adevarată provocare în aplicabilitate este repre-zentată 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 apa-rate, scopul principal este găsirea unui punct de echilibru astfel încât experiența unui utilizator să fie una naturală.

D e a c e e a e s t e absolut vital ca un proiectant să realizeze un flux de informații și pași, cât mai precis, dar totodată trebuie s ă u r m ă r e a s c ă î n p e r m an e nț ă p ăre -rile utilizatorilor: și anume cum și când se folosește, cum îi influențează, timpul alocat pentru realiza-rea 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 in proiect.

Dacă se dorește scoaterea în evidență a unei proprietăți sau a unei funcționalități, trebuie apelat în fazele timpurii ale rea-lizării aplicației, la câteva concepte de proiectare. În acest mod se poate comu-nica 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 utilizatoru-lui o stare de liniște și o încredere sporită să folosească aplicația respectivă.

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

Omniprezența aplicabilității în ecosistemul personal

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

UIX

Bogdan [email protected]

UX/UI Design Lead @ Endava

www.nastasabogdan.eu



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 multitu-dine 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 impor-tant 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ăs-punsurile 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 folo-sească. 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 proiec-tare 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 repre-zentat de realizarea unor prototipuri care să ofere suport interactiv pentru rafinarea unui anumit flux de pași urmat de utili-zatori 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 â n d d o r e ș t i să cupr inzi această i nte r a c ț iu ne d i nt re aplicație și utilizator, trebuie luat în conside-rare, 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 concep-tele 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 con-siderabil 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 eva-luare 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,


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

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

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 clien-tul 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 sco-pul principal este să se reducă costurile și timpul de imple-

mentare 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.jus-tinmind.com).

Nevoia de a funcționa pe majoritatea platformelor reprezintă o adevarată provo-care 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.

Omniprezența aplicabilității în ecosistemul personal

UIX

MONITOR TABLETĂ TELEFON


arhitectură

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

Cu Liferay sau fără LiferayLiferay 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 multi-language, 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 dez-voltat de Liferay pentru a automatiza crearea interfeţelor și claselor folosite de portal și portleţi pentru layer-ele de ser-vicii ș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 proble-mele 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 bene-ficiază doar de o pagină de wiki care nu este foarte detaliată. Aceasta înseamnă că, dacă nu întelegi exact ce fac anu-mite 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 pro-priu. Avantajul este deţinerea controlului

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.

Alexandra Coldea [email protected]

Java Developer @ ISDC


complet asupra codului scris și posibilitatea definirii documentaţiei proprii. Însă, over-head-ul de a defini două layere – persistență și servicii – cu interfeţele și nivelul de abs-tractizare oferit de Service Builder este foarte mare. Astfel, timpul de implemen-tare ș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 pro-iecte în care se folosește Service Builder-ul.

Decuplarea componentelor aplicaţieiCa în orice arhitectură pe layere, com-

ponentele 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 penali-zare 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 gene-rează api-ul separat de implementare, într-un folder din WEBINF. Aceasta este modalitatea Ant de structurare a proiectu-lui. Modalitatea Maven este de a-l genera într-un modul separat.

Cât despre împachetarea componente-lor, există mai multe modalităti de a face acest lucru, în funcţie de necesităţile pro-iectului. 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 implementa-rea se poate schimba și i se poate face hot deploy. Teoretic, se poate modifica logica de

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 întam-pla 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 imple-mentarea 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ă sto-cheze 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ă proiec-tul 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 ser-vicii. Pentru development se poate folosi o configurare asemănătoare cu cea din Figura 3, în care acest modul e împachetat împre-ună 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 pen-

tru toţi portleţii. Fiecare abordare are avantajele și dezavantajele ei. În prima este foarte ușor să contro-lezi 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ă

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 componenteO 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ţio-nează ca un Model Driven Transformation Tool. Deci, layer-ul de servicii este cel res-ponsabil 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 environ-ment. De exemplu, într-o aplicaţie care se ocupă cu managementul studenţilor, toate informaţiile referitoare la notele de la exa-mene 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 wrap-pere. Figura 4 prezintă această arhitectură. Comunicarea dintre nivelul de wrap-pere 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 ato-mice, 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 Figura 1

Figura 2

Probleme arhitecturale în proiecte Liferay

arhitectură



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

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 apli-

caţie Liferay, există doar o serie de întrebări care trebuie puse la începutul fiecărui proiect. Cu cât aceste întrebări care stan-dardizează modalităţile de lucru sunt puse mai târziu, cu atât refactorizarea pentru a avea un proiect consistent va fi mai costi-sitoare, flexibilitatea și extensibilitatea vor fi afectate.

ISDC.EU/CAREERS

WE DO PROJECTS

WITH IMPACT. WE

DELIVER RESULTS,

NOT RESOURCES.

OUR CUSTOMERS

ARE IMPRESSED

BY OUR AWESOME

TECH TEAMS.

ISDC

ENGINEERS

YOUR

DREAMS! [email protected]

[email protected]

WE HIRE IN GOOD COMPANY

PROJECT MANAGERPROJECT MANAGER

JAVA DEVELOPERSJAVA DEVELOPERS

.NET DEVELOPERS.NET DEVELOPERS

JAVA ARCHITECT JAVA ARCHITECT

.NET ARCHITECT

Figura 3

Figura 4


Google+ for Business este un instru-ment 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 instru-ment foarte bun în promovarea online locală. O funcţionalitate cheie este siste-mul 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

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

business

SEO local prin intermediul Google+

Figura 1


QA și Web designer @ Small Footprint



SEO local prin intermediul Google+

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ă, folo-sind 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 anu-mit 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 dumnea-voastră 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 nece-sare, 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 Google+ for Business

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 tre-buie 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 pro-ximităţ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 dumneavoas-tră 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.

Figura 2


programare

Puncte de scalabilitate pe “cloud”

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.

Content Delivery NetworkSă ne imaginăm că avem o aplica-

ţie web care conţine foarte mult conţinut static. Prin conţinut static înțelegem orice

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 nevo-ite să răspundă, consumând resursele pe care le avem la dispoziţie.

În acest caz o soluţie pentru problema noastră poate să fie folosirea unor Content

Cloud – 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.

programare


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 spe-cial din punct de vedere software.


TODAY SOFTWARE MAGAZINEprogramare

Delivery Network (CDN). Prin inter-mediul 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 dina-mic. 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și-nile 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.

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

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ă sca-lăm mecanismul de cache nu trebuie să ne punem problema de achiziţionarea unei mașini, a licenţelor și sincronizarea aces-tor 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,

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 sincro-

nizarea sau adăugarea unui nou nod de cache dispar în totalitate.

Video streamPâ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, ajun-gâ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 webMomentan am văzut trei locuri dife-

rite unde putem să scalăm folosind diferite servicii în cloud fără să fie nevoie să multi-plică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 colec-tează 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 interme-diul 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 com-

plexă, 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 per-sistent ș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


programarePuncte de scalabilitate pe “cloud”

programare

lucru. În momentul în care este nevoie să scalăm, ar fi necesar să ne gândim cum putem să rezolvăm probleme precum sin-cronizarea 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 con-sumatori, 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 dateO 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 apli-caţ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

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 non-relaţ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 ope-raţ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 nece-sar să avem o componentă care se ocupă de generarea și managmentul acestor token-uri. Nu mai avem nevoie de alte

componenete.

ConcluzieAm analizat diferite modalităţi prin

care putem să facem aplicaţia noastră sca-labilă. Î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 dife-rite 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ă sca-leze acolo unde avem nevoie.


TODAY SOFTWARE MAGAZINEprogramare

Conceptul In-Memory DatabaseVolumul 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 mana-gement 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 pro-cessing ).

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 Enter-prise

Arhitectura generației actuale de sisteme de business reflectă condițiile teh-nologice ș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.

• Business appl i c ati on l ayer : Software-ul de business a fost con-struit folosind paradigma procesării secvențiale. Tabelele de baze de date erau aduse din baza de date, pro-cesate rând cu rând, si apoi repuse

înapoi în baza de date.

Figura 2 ilustrează o situație tipică pentru un software de tip enterprise în generația actuală de soluții. Companiile de mari dimen-siuni posedă mai multe sisteme de tip enterprise resource planning (ERP) fie-care cu baza de date proprie pentru datele operaționale. Datele analitice sunt conso-lidate într-un enterprise data warehouse și consumate de către business useri cu aju-torul soluțiilor de Business Intelligence (BI).

In-Memory Database - Platforma real-time SAP HANA

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

Director Departament SAP @ .msg systems Romania

Victor Ionescu [email protected]

SAP IT Consultant @ .msg systems Romania

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


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

În aplicațiile financiare și de business, diferite tipuri de balanțe totale sunt de obicei persistate sub forma de agregate materializate. În cazul SAP HANA si a sal-vării datelor în memorie , aceste agregate materializate pot fi eliminate astfel încât toate calculele de balanțe și sume necesare rapoartelor sunt determinate real-time cu o performanță ridicată a documentelor, de exemplu cele contabile.

În situaţia utilizării unui system de DBMS classic, necesitatea permanentă de a avea acces la informaţii actualizate conduce la crearea de tabele adiţionale pentru stoca-rea acestor date. În cazul SAP HANA aceste tabele sunt eliminate, informaţiile necesare putând fi calculate în timp real, astfel sim-plificându-se modelul de date.

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

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ă, să rețină oportunitățile în scenarii side-by-side, și să fie pregătită pentru rata în continuă creștere de a face business.

Platforma tehnică SAP HANAPlatforma SAP HANA nu se rezumă

la a fi abordarea SAP a conceptului de In-Memory Database, ci vine cu o serie de inovaţii menite să folosească la maximum

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

Interfeţe. SQL ScriptSpre deosebire de un DBMS obișnuit

platforma SAP HANA oferă, pe lângă inter-faţa SQL standard, și alte interfeţe precum SQLScript sau MDX(multidimensional expression). Existenţa acestora aduce un plus de flexibilitate platformei și permite dezvoltarea de aplicaţii optimizate pentru procese în timp real.

Odată cu implementarea pe scară tot mai largă a bazelor de date In-Memory este de așteptat ca și fenomenul de „Code Pushdown” să devină tot mai frecvent întâl-nit - acesta presupune migrarea logicii de

business considerate a fi „data-intensive” de la nivelul aplicaţie la cel al bazelor de date. Interfaţa SQLScript a SAP HANA are rolul de a veni în întâmpinarea acestui fenomen, SQLScript fiind un limbaj dezvoltat de SAP tocmai cu scopul de a sprijini implemen-tarea unei logici complexe la nivelui bazei de date.

Instrucţiunile SQL Script au la bază operaţii SQL standard și proceduri predefi-nite. Astfel, din punct de vedere conceptual, SQLScript poate fi asemănat cu procedurile stocate, SQL Script aducând însă îmbu-nă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).

ParalelismUn alt aspect important de care s-a

ţinut cont în dezvoltarea platformei SAP HANA este capacitatea masivă de para-lelizare 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-

ţional” optimizat. Practic, instrucţiunile SQLScript sunt compilate și reprezentate sub forma unui „data flow graph” – un graf aciclic orientat în care fiecare nod al gra-fului reprezintă o transformare ce trebuie

1 S t u d i u l c o mp l e t : h t t p : / / w w w. i nt e l . c o m /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-hap-pens-with-sap-hana-software-brief.html

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

Figura 3. Structura interna a platformei tehnice SAP HANA

Figura 3. Migrarea tuturor aplicațiilor

(total sau parțial) pe platforma SAP HANA

In-Memory Database - Platforma real-time SAP HANAprogramare



aplicată asupra setului de date.Tipurile de operaţii ce pot fi înglobate

în aceste noduri sunt:• Operaţii pe mulţimi (agregare, reu-

niune, intersecţie),• Instrucţiuni SQL,• Script-uri reprezentând operaţii

complexe, care nu pot fi modelate sub forma unui „data flow graph”.

Reprezentarea instrucţiunilor sub această forma permite o mai bună partiţio-nare a datelor în submulţimi independente, care pot fi procesate în paralel. Utilizarea unei asemenea abordări oferă posibilitatea platformei SAP HANA să profite la maxi-mum de puterea de procesare masivă a generaţiei actuale de „multi-core-uri”, astfel explicându-se și rezultatele uimitoare obţi-nute în benchmarkul Intel.

Column/Row StoreUna dintre proprietăţile distinctive ale

SAP HANA este faptul că dispune atât de un model de stocare bazat pe rânduri(row store) cât și pe coloane(column store).

Deși o tabelă este prin definiţie bidi-mensională, memoria calculatorului este organizată ca o succesiune secvenţială de locaţii. Astfel, decizia de a stoca o tabelă sub forma unei succesiuni de rânduri, respectiv de coloane, poate avea un impact semnificativ asupra performanţei aplicaţiei.

SAP HANA oferă posibilitatea de a lua această decizie individual pentru fie-care tabelă, luând în calcul natura acesteia. Tabelul următor prezintă situaţiile în care este recomandată utilizare unui „row store”, respectiv a unui „column store”.

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

Row store Column Store

Aplicaţia procesează câte un rând

Număr mare de rânduri, şi sunt necesare operaţii pe coloane(agregare, căutare ş.a.m.d.)

Agregările nu sunt necesare

Număr mare de coloane al tabelei

Coloanele conţin valori distincte, astfel potenţialul de compresie a datelor fiind redus

Tabela este parcursă doar pe baza valo-rilor din anumite coloane

Evaluarea performanţei Evident, discuţia despre platforma SAP

HANA nu poate fi încheiată altfel decât răspunzând la întreabarea „Care este câș-tigul concret de performanţă obţinut prin migrarea pe o platformă SAP HANA?” Pentru a cuantifica acest câștig au fost rea-lizate nenumărate benchmark-uri, probabil cele mai relevante fiind cele desfășurate în contextul de Data Warehousing.

În continuare vor fi prezentate pe scurt rezultatele unui asemenea benchmark rea-lizat pe platforma SAP HANA. În cadrul testului s-a urmărit analiza puterii de pro-cesare analitice a SAP HANA în contextul BI real-time.

Testul a fost executat pe un set de date de 100TB, acestea fiind stocate într-o tabelă de fapte cu 100 de miliarde de înregistrări și în tabelele de dimensiuni aferente. Setul de date reprezintă înregistrările corespun-zătoare pentru un interval de cinci ani ale unui modul de SD (Sales&Distribution).

Operaţiile alese pentru evaluare sunt de natură mixtă, ele acoperiind mare parte din activităţile de BI obișnuite:• General reporting,• Iterative querying (drill downs),• Ranking,• Year-over-year analysis.

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

RezultateMajoritatea 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 end-userii 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.

Acest fapt este susţinut și de declaraţi-ile diverșilor clienţi care au trecut deja prin această etapă:

“[R]eplacing our enterprise-wide Oracle data mart and resulting in over 20,000-times speed improvement processing our most complex freight transportation cost calcula-tion . . . our stand-alone mobile applications that were previously running on Oracle are now running on SAP HANA. Our 2,000 local sales representatives can now interact with real-time data instead and have the ability to make on-the-fly promotion decisi-ons to improve sales.” – Nongfu Spring

“[O]ur internal technical comparison demonstrated that SAP HANA outperforms traditional disk-based systems by

a factor of 408,000.” – Mitsui Knowledge Industry Co. Ltd.

“With SAP HANA, we see a tremendous opportunity to dramatically improve our enterprise data warehouse solutions, dras-tically reducing data latency and improving speed when we can return query results in 45 seconds from SAP NetWeaver BW on SAP HANA versus waiting up to 20 minutes for empty results from SAP NetWeaver BW on a traditional disk-based database.”

– Shanghai Volkswagen

2 Detaliile testului pot fi consultate aici: http://download.sap.com/download.epd?context=CCBE2C4417A4583A96A74DC0E2D820576429CADB38C81772D70FE496C29B362BCBBAB6D377ADC5D7063F40D27A0790298C2238F3F161645E

Figura 4. Timpi de procesare pentru un set de date de 120 de mili-

oane de înregistrări. Variaţia timpilor cu creşterea paralelismului


Code review

De ce este Code Review-ul importantSteve McConell prezintă în cartea sa

Code Complete (http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670) câteva argumente foarte bune despre eficiența procesului de Code Review:

Testarea softului în sine are eficacitate limitată – rata medie de detectare a defec-telor este de 25% pentru unit testing, 35% pentru testarea funcțională şi 45% pentru integration testing. În opoziție, eficacitatea Code Review-ului si Design Review-ului este între 55%-60%. Studiile de caz pen-tru revizuirea rezultatelor aplicării Code Review-ului au fost impresionante:• Dintr-o serie de 11 proiecte software

dezvoltate de aceeaşi echipă, primele 5 au fost dezvoltate fără a avea proce-sul de Code Review, iar următoarele 6 au fost dezvoltate folosind şi proce-sul de Code Review-ul. După ce toate cele 11 proiecte au ajuns în producție, primele 5 au avut o rată de 4.5 erori pe 100 de linii de cod. Următoarele 6 au avut doar 0.82 de erori pe 100 de linii de cod. Review-urile au îmbunătățit rata de erori cu 80%.

• Aetna Insurance Company a găsit 82% din erori cu ajutorul Code Review-ului ceea ce le-a permis să scadă şi numărul de resurse alocate dezvoltării cu 20%.

• Proiectul Orbit de la IBM utiliza 11 nivele de review. A fost livrat la timp şi a avut doar 1% din numărul

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 esti-mează că economisesc 25.000$ per review.

Motivele principale pentru care se face Code Review-ul sunt:• Găsirea și fixarea defectelor devreme

în procesul de dezvoltare;• O mai bună înțelegere comună a

codului sursă;• Ajută la menținerea unui nivel

de cons is tenț ă în des ig n ș i implementare;

• Ajută la identificarea defectelor comune în echipă si la reducerea timpului de fixare;

• Ajută la creșterea încrederi i stakeholder-ilor asupra calității pro-cesului de devoltare;

• O înțelegere comună și uniformă a codului ajută și la reducerea impactului în proiect atunci când anumiți membrii ai echipei devin indisponibili;

• O perspectivă nouă. O altă ”pere-che de ochi” crește gradul de obiectivitate. La fel ca și în cazul separării între dezvoltare și testare, Code Review-ul introduce distanța necesară pentru a recunoaște mai

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

Mădălin [email protected]

Java discipline lead@ Endava

programare management



ușor problemele;• M â n d r i e / r e c o m p e n s ă .

Recunoașterea abilităților este o recompensă semnificativă pentru mulți programatori;

• Coeziune mai bună a echipei.

Pentru a înțelege cât de important este să fixăm cat mai multe defecte încă din faza de dezvoltare, aveți mai sus un grafic des-pre costurile unui defect în diferite faze ale produsului:

Ariile principale pe care se concen-trează Code Review-ul:• Unit testing,• Documentarea codului și convenții

de codare,• Tratarea erorilor,• Resource leaks,• Thread Safety,• Structuri de cotrol,• Performanță,• Funcționalitate,• Securitate,• Consistență cu designul și arhitec-

tura existentă• Utilizarea corectă a librăriilor

externe

Roluri și responsabilitățiDezvoltatorul: este persoana care

a scris codul ce urmează a fi revizuit și este cel care inițiază cererea pentru Code Review.

Reviewer/s: sunt persoanele care vor revizui codul și vor raporta problemele găsite devoltatorilor.

La fel ca orice altă abilitate, reviewer-ii devin mai buni făcând foarte multă prac-tică. Iată câteva ponturi care vă vor ajuta să porniți pe drumul cel bun.

Sfaturi pentru Dezvoltarori1. Primul reviewer este chiar autorul

codului i.e. TU2. Creează un checklist cu lucrurile

pe care se focusează cel mai mult procesul de Code Review. O astfel de listă ar trebui să fie destul de sim-plu de făcut. De obicei, se urmăresc ideile cele mai importante din stan-dardele de codare. Pentru că este o listă personală, te poți concentra pe ariile pe care știi că ai cele mai mari probleme și poți omite ariile despre care știi că te descurci foarte bine. Nu doar că vei reduce numărul de probleme găsite, dar vei face proce-sul de review unul foarte scurt, ceea ce va face pe toată lumea fericită.

3. Tu și codul sunteți 2 entități dife-rite. Ține minte că scopul principal al review-ulu este găsirea de pro-bleme și în 99% din cazuri vor fi găsite probleme. Nu lua lucrurile personal. Unii dezvoltatori au un simț al proprietății și un orgoliu foarte mare, ajungând chiar să se identifice cu codul scris.

4. Întelege și acceptă faptul că vei face greșeli. Scopul este să le găsești cât mai devreme și să nu ajungă în producție. Ține minte că doar facând greșeli poți să evoluezi.

5. Indiferent de cât de multe „karate” știi, există mereu cineva care sție mai multe. O astfel de persoană te poate învăța câteva ”mișcări” interesante. Caută și acceptă ideile celorlalți, mai ales când crezi că nu ai nevoie de ele.

6. Nu rescrie cod fără a te consulta și cu echipa. Este o diferență foarte mică între a fixa codul și a rescrie codul. Învață diferența și încearcă

să faci aceste schimbări în cadrul procesului de Code Review. Nu începe să refactorizezi de unul sin-gur 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.

7. 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, plat-formei, sau tool-urilor ca o nouă provocare.

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

9. Nu fi „the guy in the room”. Nu fi persoana care stă în colțul lui și sin-gura 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 pro-cesului de Code Review.

10. Întâlnirile de Code Review nu sunt întâlniri pentru rezolvare proble-melor. Scopul lor nu e să discutăm toate probleme ce există pe proiect, ci doar punctual review-ul aflat în desfășurare.

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

Sfaturi pentru Revieweri1. Critică codul, nu persoanele – fii

blând cu dezoltatorii, nu cu codul. Pe cât posibil comentariile tale ar trebui sa aibă o nuanță pozi-tivă orientate spre îmbunătățirea codului. Încearcă să relaționezi comentariile cu standardele de codare, specificații, constrângeri de performanță, securite, etc.

2. Tratează cu respect și răbdare persoanele care au un nivel de cunoștințe mai scăzut decât al tău. Gândește-te cam cui ai vrea să fii și tu tratat de persoane care au mai multe cunoștințe decât tine și fă și tu la fel cu ceilalți.

3. Adevărata autoritate vine din c u n o șt i nțe , nu d i n p o z iț i a

management


ierarhică. Cunoștințele generează autoritate și autoritatea generează respect. Nu vei fi niciodată respectat dacă spui ”Că așa zic eu!”

4. Întâlnirile de Code Review nu sunt întâlniri pentru rezolvare problemelor.

5. 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 decizii-lor pe care le-ai luat?” încerci să afli informații, nu să acuzi.

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

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

8. 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 dezvolta-tori pentru respectarea calității și mentenabilității codului.

9. Ține minte că mereu există mai mult decât o soluție pentru rezol-varea 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ă.

10. Nu trebuie să te grăbești atunci când faci Code Review, dar trebuie să fii cât mai prompt.

11. Încearcă să nu depășești 200-400 de linii de cod per review session.

12. 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 deo-

sebită asupra părții de securitate, vă

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 proble-melor 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

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-voltatori cât și pentru revieweri. Omisiunile sunt defectele cele mai greu de reparat – clar că nu ai cum să faci review la ceva ce nu există. Un checklist e cel mai simplu mod prin care poți combate asta.

Un alt concept foarte folositor este checklist-ul personal. O persoană face în medie cam aceleași 15-20 de greșeli. Pentru a preveni repetarea, încearcă să ții o listă cu problemele cele mai întâlnite. Aceasta te va ajuta și pe tine ca dezvoltator să îți însușești conceptele respective.

Checklist pentru DezvoltatoriDescription Con-

firmed?

Codul se compilează

Codul a fost testat de mine și include unit teste

Codul include javadoc

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

Am considerat utilizarea corectă a excepțiilor

Am utilizat adecvat logging-ul

Am eliminat importurile nefolosite

Am eliminat warning-uri-le raporte de Eclipse/Netbeans/IntelliJ

Description Con-firmed?

Am luat în considerare potențiale NPEs

Codul urmează stand-ardele de codare

Am eliminat orice cod redundant sau clase care nu mai sunt folosite

Am eliminat orice hardcodări sau develop-ment-only code?

Perfomanța a fost luată în considerare?

Securitatea a fost luată în considerare?

Codul eliberează resursele? (HTTP connec-tions, DB Connections, files, etc)?

Cazurile particulare au fost bine documentate? La fel orice workaround sau limitare

Codul poate fi înlocuit cu apeluri către compo-nente externe resuti-lizabile?

Thread safety și posi-bile deadlocks

Checklist pentru RevieweriDescription Confirmed?

Comentarile sunt com-prehensibile și aduc valore mentenabilității codului

Comentariile nu sunt foarte multe și nici foarte amănunțite

Tipurile de date au fost generalizate acolo unde a fost posibil

Tipurile parametri-zate au fost folosite corespunzător

Excepțiile au fost fo-losite corespunzător

Codul duplicat a fost eliminat

Frameworkurile au fost folosite corespunzător

Clasele de tip comand sunt concentrate pe un singur task

JSP-urile nu conțin logică de business

Unit test-ele există și sunt corecte

Sunt verificări pentru erorile comune

Potențiale probleme de multi-threading au fost eliminate pe cât posi-bil

Eventuale probeme de securitate au fost adresate

Performanța a fost luată în considerare

Code review

programare



Description Confirmed?

Funcționalitate se încadrează în design-ul/arhitectura curentă

Codul este unit test-able

Codul nu folosește nejustificat elemente statice

Codul urmează stand-ardele de codare

Logging-ul a fost fo-losit corespunzător

NPEs și AIOBs

Automatizarea procesului de Code ReviewPornind de la un document cu stan-

darde 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 cla-selor, 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 proiec-tului. Voi prezenta mai jos cele mai folosite tool-uri pentru Java.

PMDPagina oficială: http://pmd.sourceforge.

net/.Este un analizor de cod sursă.

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

FindbugsPagina oficială: http://f indbugs.

sourceforge.net/.Folosește analiza statică a codului pen-

tru identifiare bug-urilor din cod. La fel ca si PMD are integrare cu cele mai populare tool-uri de building si IDE-uri.

CheckstylePagina oficială: http://checkstyle.sour-

ceforge.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 CoveragePentru a verifica gradul de acoperile al

codului cu unit teste cele mai populare too-luri sunt: Jacoco, Cobertura și Clover.

SonarSonar 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 popu-lare IDE-uri și tool-uri de building și oferă suport out-of-the-box pentru Java. Poate fi configurat și pentru alte limbaje de progra-mare precum PHP, C++ sau .NET dar cu puțin mai mult efort.

Aveți în partea de jos a paginii o dia-gramă care prezintă arhitectura Sonar-ului. (Server se referă la serverul de Sonar).

Controlarea procesului de Code ReviewPână acum am prezentat sfaturi despre

ce anume se urmărește într-un proces de code review și cum se poate automatiza 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 progre-sul: prin email, printr-un fișier excel, doar discutând, folosind tooluri specilizate? Deși răspunsul cel mai evident este folosi-rea 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 schim-bă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ă per-soane ș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 moni-torizarea procesului de code review. Alte alegeri ar mai fi: Gerrit (dedicat proiectelor ce folosesc Git) sau ReviewBorad.


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

La nivelul performanţei interacţiu-nii 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 con-strâ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, Network-Protocol Driver și Java to Database Protocol. Fiecare nou tip aducea un plus în creșterea vitezei de răspuns, a număru-lui 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 conexi-unea 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 ase-menea, 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 inter-acţ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 dis-tribuite, 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

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

programare

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

Silviu [email protected]

Consultant Java@ .msg systems Romania

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 capi-tolul “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ște-rea performanţei trebuie avut în vedere tipul de colecţie folosită pentru maparea relaţiilor sau modul în care este reactua-lizată 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 per-sistent gestionează stările entităţii. Unele

dintre operaţii nu se pot executa în oricare dintre stări. Descrierea stărilor și moda-litatea 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 moda-lităţi, descrise amanunţit în “Locking and Concurrency”.

Revin la ideea de performanţă în dez-voltarea unei aplicaţii. Cum am putea să alegem între cele două moduri de gestio-nare 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 enti-tăţilor. Entităţile fiind clase sunt supuse regulilor POO, deci și moștenirii. Partea cea mai interesantă este că clasele enti-tate 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 limba-jul 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 introduce-rea alias-urilor entităţilor posibilitatea de folosire a SQL injection este aproape com-plet 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 concepte-lor 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 dome-niu: 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 serve-rului de aplicaţie JBoss, în locul frecvent utilizatului Glassfish. Aceasta poate fi interpretată ca pe o provocare, iar dife-renţ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ă!

business


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 vizi-une ș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• 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ă schimba-rea: este persoana care încurajează schimbarea și definește pașii nece-sari pentru o cât mai bună înțelegere a procesului de schimbare.

• E deschis la idei noi: încurajează brainstorming-ul și părerea fiecărui membru al echipei este importantă. Implementează ideile noi care aduc un plus de valoare atât în eficenti-zarea muncii cât și în organizarea internă a echipei, pentru atingerea obiectivelor dorite.

• Conduce prin puterea exemplului: este important ca liderul să se com-porte în conformitate cu valorile pe care le promovează. Liderul este cel care definește comportamen-tul și comunicarea în echipă. Cu cât liderul este mai transparent în informațiile transmise către echipă, în decizile pe care le ia, cu atât membrii echipei adoptă un compor-tament asemănător.

• Are încredere: prin acțiunile pe care le întreprinde, transmite că este o persoană pe care membrii echipei

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 implemen-tează 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 valo-rifica 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.

Un manager:• Planifică: creează un plan de acțiune

bine definit pentru atingerea obiec-tive prin definirea strategiei, a termenelor libere, a politicilor și procedurilor adoptate în organizație. Are de asemenea un rol important în planificarea bugetelor.

• Organizează: definește sarcinile și responsabilitățile, deleagă sarcini, stabilește relații de conducere și rolul fiecăruia în ierarhia organizațională.

• Coordonează: definește resursele necesare: oameni, structuri, timpi de execuție, integrare a proceselor.

• Controlează: definește standarde de performanță, măsoară procesele,

evaluează rezultatele. • Motivează: selecția, comunicarea,

implicarea, consilierea, învățarea și dezvoltarea angajațiilor, concedie-rea acestora.

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

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

Etapele formării echipei (Tuckman, 1965)

I. Formarea (Forming)Caracteristici etapă:

• Sentimentele membrilor echipei: » Teamă; » Comunicarea în cadrul echipei

este îngreunată de nesiguranța cu care membrii echipei de confruntă;

» Grupul nu cunoaște scopul său viitorul;

» Implicare puțină și ineficientă; » Fiecare persoană caută, prin tato-

nare să își stabilească identitatea în cadrul grupului;

• Reguli și obiective: » Obiectivele sunt în mare parte

stabilite de către manager iar deoarece membrii echipei sunt noi acestea sunt neclare și neînțelese fără a ști impactul pe care poate să îl aibă asupra business-ului;

» Regulile nu sunt stabilite;• Sarcinile:

Workshop-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 limi-

tele coordonării unei echipe sau s-a insistat asupra diferențelor între lider și manager.

HR

Managementul echipei

programare



» Nu sunt cunoscute de către mem-brii echipei;

» Nu sunt înțelese;

Rolul liderului• Creează cadrul în care să faciliteze

comunicarea între membrii echi-pei. Î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-nile și responsabilitățile postului.

• Explică viziunea, obiectivele și strategia.

• Comunicarea este mai mult dinspre lider către membrii echipei.

• Deciziile sunt luate de către lider, dar încurajează ideile și părerile fie-cărui membru al echipei.

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 dato-

rită situațiilor conflictuale; » Lipsă de încredere;

• Reguli și obiective: » Obiectivele sunt cunoscute, dar

membrii echipei încă nu aderă la ele, pentru că încă sunt sta-bilite 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

explicarea strategiei pentru îndepli-nirea 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ă ris-cul 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.

III. Normarea (Norming)Caracteristici etapă:

• Sentimentele membri-lor echipei: » Apare consensul, accep-

tarea, siguranța; » Membrii echipei încep

să aibă încredere unul în celălalt; » Se dezvoltă un limbaj

comun al echipei;

• Reguli și obiective: » Obiectivele sunt cunoscute și

înțelese; » Regulile sunt acceptate, deoarece

sunt agreate de comun acord; » Procedurile de lucru sunt înțelese

și aplicate în activitatea de zi cu zi;

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 conforta-bili cu îndeplinirea sarcinilor.

• Riscul în această etapă este determi-nat 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 dezvol-tarea 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ă încre-

dere 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 des-

tramă, 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 implementa-rea 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 pro-vocare 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 autori-tăţ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 dezvolta-tor al echipei pentru obținerea rezultatelor dorite.

Succes cu managementul echipelor pe care le coordonati!

programare

Andreea Pâ[email protected] în cadrul Endava


Lansarea unui site web - pașii de bază

Articolul acesta va pre-zenta pașii de bază necesari pentru atingerea acestor sco-puri. Inspiraţia pentru acest articol a venit în timpul lan-să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 pen-tru 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 pen-tru 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ăzduirePrima întrebare înaintea lansării unui

site web este de obicei ”unde să-l găzdu-iesc?”. 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 vir-tuale (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/

site-ul. Este de recomandată testa-rea 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 plat-forme 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 fiabili-tăţii sporite.

/robots.txtEste 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

Teoretic 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 site-ul 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 [email protected]

Code Wrangler @ UdacityTrainer @ Tora Trading

programare


TODAY SOFTWARE MAGAZINEtehnologii

specificarea sitemap-ului și vitezei de par-curgere4 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ă.

MonitorizareExistă două feluri de monitorizare:

• monitorizarea faptului că site-ul funcţionează - nu a murit serverul web, baza de date, etc. Există o mul-titudine de companii care oferă astfel de servicii. Pentru IT-Events.RO folosesc Pingdom6 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 Analytics7 . Totodată recomand adăugarea site-ului în Google Webmaster Tools8 și verificarea periodică a mesajelor de acolo. GWT oferă alerte și infor-maţii despre aspecte care sunt de interes pentru proprietarii site-uri-lor (viteza de răspuns, adrese care nu puteau fi accesate, conţinut mali-ţios, etc)

SitemapsEste 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/

la Google poate fi notificat despre existenţa unui sitemap folosind Google Webmaster Tools amintit la punctul anterior.

FaviconFavicon 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ști-entul utilizatorilor învaţă să recunoască site-ul pe baza lui). Un alt avantaj este eli-minarea 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 platfor-mele 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 elimi-narea 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 dome-nii folosind Flash, se poate adăuga un fișier simplu cu următorul con-ţinut pentru eliminarea erorilor de 404 din jurnal:

<?xml version=”1.0” ?><cross-domain-policy></cross-domain-policy>

Trimiterea email-urilorTrimiterea email-urilor a devenit din

ce în ce mai complicată în zilele de azi din cauza email-urilor nesolicitate (spam). Furnizorii de servicii de email au răspuns prin introducerea unor filtre stricte pentru a elimina aceste tipuri de email-uri. Astfel a devenit dificil crearea email-urilor care să nu fie eliminate de aceste reguli.

Pentru simplitate se pot folosi servicii precum MailChimp10 . Dacă vrei să trimiţi email-uri de pe instanţe Amazon EC2, tre-buie setate Reverse DNS-ul11 (RDNS) și SPF12 . Ca alternativă Amazon oferă SNS (Simple Notification Services), dar acesta 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-request12 http://stackoverflow.com/questions/6688251/

spf-record-for-amazon-ec2

în varianta gratuită.

Verificarea compatibilităţii site-ului cu 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 folo-sirea 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ărcareViteza 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 opti-mizează conţinutul paginii pentru o viteză mai bună.

• CDN-urile (Content Deliver y Network) - ajută prin plasarea serverelor mai aproape (fizic) de utilizator. Un exemplu bun este CloudFare17 .

• Extensii specifice pentru platforma folosită - de exemplu W3 Total Cache18 pentru WordPress.

ConcluziiCrearea unui site este foarte ușoară.

Crearea unui site care să fie ușor de folosit de utilizatori și de sisteme automate este un proces continuu. O listă mai completă de pași pentru maximizarea impactului site-ului poate fi găsită la webdevchecklist.com. Merită citită și discuţia asociată de pe HackerNews19 .

13 http://www.browserstack.com/14 https://browserlab.adobe.com/en-us/index.html15 https://addons.mozilla.org/en-us/firefox/addon/

yslow/16 https://developers.google.com/speed/pagespeed/

mod17 http://www.cloudflare.com/18 http://wordpress.org/extend/plugins/w3-total-cache/19 http://news.ycombinator.com/item?id=5022523


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

A trecut un an de când am fost accep-taţi în Bizspark și experienţa de până acum este una cât se poate de pozitivă.

„Ce înseamnă Microsoft Bizspark?” :Bizspark este un program Microsoft ce

se adresează firmelor/startupurilor ce cre-ează produse & servicii, prin care ai acces la un număr (limitat dar suficient) de licenţe ale produselor Microsoft, access la resurse cloud (Azure), access la servicii/produse ale partenerilor Bizspark la preţuri promo-ţionale (sau gratuit), training și suport.

Licenţele & pachetele oferite prin pro-gram sunt extrem de variate, schimbadu-se destul de des. Pentru un „sneak peak” vă puteţi uita la http://www.microsoft.com/Bizspark/Offers/Default.aspx

Concret ce am luat noi din Bizspark (până acum):• Licenţe de Windows 7 și Windows 8• Licenţe de Visual Studio (Ultimate

& Professional) - se poate și Team Foundation Server

• Access la Windows Azure - 1500 ore pe mașina virtual „mică” (sau echi-valent) pe lună + 10 free websites (ce oferă o viteză acceptabilă). Mai multe despre Azure prin Bizspark: http://www.windowsazure.com/en-us/offers/ms-azr-0012p. Încă nu profităm la maxim de Azure (axându-ne pe cloud-ul Amazon) așa că nu pot da detalii legate de „suficienta“ resurselor oferite dar urmează să forţăm limitele abona-mentului Azure în viitorul apropiat

• Access la Pluralsight (3 luni gratuit). Nota: ca și developer nu pot decât să recomand cu căldură Pluralsight ca și resursă de traininguri online - calitatea trainingurilor oferite este în general excelentă și își merită toţii banii.

Cine este eligibil pentru Bizspark?Firmele care:

• au mai puţin de 5 ani de activitate,• au venituri anuale mai mici de

1.000.000 USD,• au ca domeniu de activitate cree-

rea de produse și servicii software. Dezvoltarea trebuie făcută (cel puţin parţial) pe tehnologii Microsoft.

Persoanele fizice autorizate sau dezvol-tatorii individuali care:• doresc să desvolte un produs/servi-

ciu pe tehnologii Microsoft + doresc la un moment dat să facă pasul de la PFA/dezvoltator individual la înfiin-ţarea unei firme.

Acestea sunt criteriile generale - în funcţie de ce dezvoltaţi/doriţi să dezvoltaţi și a planurilor voastre de viitor veţi fi accep-taţi sau nu în Bizspark - asta va fi decis de comisia de evaluare a cererii voastre.

Notă: va fi mai ușor să accesaţi Bizspark ca și firma decât ca și PFA/dezvoltator individual.

Cât durează programul?Trei ani – licenţele care le primești în

timpul programului îţi vor rămâne ţie (fără alte costuri). Adiţional, la terminarea pro-gramului, vei avea acces la oferte ce îţi vor permite să cumperi mai multe licenţe (dacă firma a crescut și ai nevoie de mai mult decât ce îţi oferă Bizspark) cu discount.

Cum aplic?https://www.microsoft.com/bizspark/

SignUp/default.aspx este locul de por-nire. Vezi avea nevoie de un Microsoft account (vechiul Windows Live ID) - cu care veţi administra Bizspark - și de răb-dare să completaţi toate informaţiile cerute de Microsoft. Poate s-a schimbat ceva în ultimul timp dar acum un an când am com-pletat noi cererea de admitere a trebuit să

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 par-tener 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.aspxVorbind direct cu cei ce se ocupă de

Bizspark în România: Zoli Herczeg ([email protected]) și Simona Lică ([email protected])

Impresii personaleLegat de ceea ce este cuprins în

program:Dacă sunteţi la început de drum și dez-

voltaţ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 nos-tru 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.

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.

Dragoș [email protected]

CTO

@ TXTFeedback

startupsstartups


TODAY SOFTWARE MAGAZINEstartups

Părea evident că nimeni nu are o vizi-une de ansamblu asupra tuturor acțiunilor, e un fel de agitație browniană, în care nu se observă, încă, reguli generale și lucru-rile mai au nevoie de timp până să se statornicească. Iar inițiativele apar și se mai suprapun în timp și conținut. Repet, mi se pare perfect normal pentru început, dar acum cred că ar trebui să intrăm într-o fază de clarificare și comunicare mai bună începând de la ce avem acum, cu speranța că se vor completa reciproc și ecosistemul va crește din contribuția fiecăruia.

(paranteză de clarificare, în accepțiunea mea, startups = “high growth, technology oriented companies”)

Acest ecosistem l-aș analiza din punct de vedere al dezvoltării unui startup în fazele incipiente (early startup life). Aici mă refer la tipul de evenimente, pro-grame de care are nevoie un startup și unde ecosistemul poate ajuta până în momentul decolării (investiție, accelerator, monetizare).

Generarea și pre-validarea ideii(Pre-validare în sensul în care o adevă-

rată validare este dată de existența userilor/clienților, iar în această fază vorbim de feedback-ul unor oameni cu experiență sau potențiali clienți dar în această fază nu există încă un produs al startup-ului).

Totuși aș putea considera că sun-tem bine acoperiți de Startup Weekend și Startup Live, ambele având rețele internaționale în spate (Startup Weekend și STARTeurope), Clujul devine un punct în aceste rețele și deci e pe harta lor. Ce avantaje vor fi rămâne de văzut, dar sigur sunt. De exemplu, faptul că UseTogether a câștigat SW Cluj în 2012 a fost o dovadă

pentru acceleratoarele la care am aplicat că totuși e ceva de proiectul acesta (iar acum se văd rezultatele). Ideal ar fi ca evenimen-tele să aibă loc la destul timp între ele ca să nu se afecteze negativ sau ca să nu intre în concurență prea mult pentru participanți, resurse.

Valley of deathE perioada imediat următoare după

SW și SL, în care majoritatea inițiativelor startup-like mor. De exemplu, din cele 11 idei pe care s-a lucrat la SW Cluj 2012, în viață, vizibilă este doar una (am auzit că alte 2-3 încă mai respiră, dar încă nu știu nimic concret). Dacă ar fi existat suport educațional, mentorat (deci non-finan-ciar), probabil erau mai multe în viată. Și pe această latură nu avem nimic ca program de suport coerent (fiecare se descurcă cum poate).

Aici putem interveni noi cu ce avem acum în Cluj, prin mai multe tipuri de evenimente care există sau sunt în curs de planificare:

Networking – are loc deja prin Open Connect, Open Coffee (și alte evenimente de IT dar nu neapărat orientate spre startu-puri), iar în curând se va adăuga și Startup Invasion. Aceste evenimente poate fi si locul potrivit de dat feedback pe idei de startupuri.

Startup Lounge – panel talks, discuții și informal drinks după program, va fi organizat organizat o dată pe lună la Cluj Hub (prima ediție va avea loc în februarie)

Startup Education Program – vine în completarea networking-ului, trecerea la următorul nivel: evenimente educaționale pentru startupuri tech pe teme specifice (ex: growth, finances and investment, lean development, pitching). Practic ar fi

vorba de workshopuri/traininguri de 3-4 ore ținute de cineva cu experiență în tema respectivă, prezentare, case study și eventu-ale exerciții.

Startup Peer Support – mai des orga-nizate, dar în cerc mai restrâns, în care startup-erii se întâlnesc și își prezintă o problemă de care s-au lovit iar împreună cu ceilalți încearcă să găsească soluții (ideea a fost implementată anul trecut de Florin Mureșan și au avut loc mai multe întâlniri sub numele de AntreprenoriCluj.info)

Toate acestea în diverse locații în Cluj, dar mai ales în locațiile în care aceste startupuri să crească (nurturing space), unde să poate să aibă ședințe, să fie organi-zate evenimentele menționate mai sus. Aici intervin Cluj Cowork și Cluj Hub.

Early-stageMomentul în care un startup este în

măsură să între într-un accelerator și de aici să decoleze mai departe (bineînțeles aceasta poate să se întâmple și mai repede, nu există o regula clară). Nu avem [încă] acceleratoare în România, deci accesul este mai greu. Dar se zvonește de câteva inițiative în acest sens și în 2014 sunt sigur că vom avea cel puțin unul, în carne și oase (adică cu bani și cu spațiu fizic). Nu m-aș mira prea tare dacă ar apărea 3 (sub diverse forme) până în 2015 (în București, Timisoara și Cluj). Dar un accelerator e al doilea pas, până atunci avem primul pas de făcut: consolidarea ecosistemului.

Există și vor apărea mai multe informații/inițiative iar schema aceasta nu se vrea a fi completă. Sigur există și alte proiecte care pot să completeze schema de mai sus pentru a da o vedere de ansamblu mai clară.

Câteva din cele menționate încă nu au avut loc, ci sunt la nivel de proiectare. Oricum, primăvara aceasta va fi definitorie.

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

Ecosistemul tech-startups din Cluj

Mircea Vă[email protected]

Co-fondator și coordonator

@ Use Together


HR

De ce diferă segmentul SAP/ABAP de celelalte segmente ale IT-ului și care sunt provocările în zona HR, respectiv a dez-voltă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 busi-ness și tehnologie. ABAP-erii susţin că este momentul în care este mai plăcut ca ori-câ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 reco-mand 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 progra-mare 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 platfor-melor 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

singur sistem care să susţină diferitele arii ale unui business. Dacă ERP-ul funcţio-nează 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 busi-ness-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 deschi-dere 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 arhi-tecţi suprasaturaţi de specificul limbajelor de programare folosite de-a lungul anilor și a proiectelor aferente, în căutare de ino-vaţ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 dome-niu ș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 dezvol-tare 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 dez-voltator 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ă, însu-mâ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

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 fap-tul că la noi în ţară se mai șchiopătează la partea de prezentare a avantajelor progra-mă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 prezenta-rii 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 accesi-bile, 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 stu-diu 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.

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

Managementul de personal in domeniul SAP

Oana Oprean [email protected]

Center of Competence Manager

@ .msg systems Romania

diverse


Gogu și vaca lui șefu’

dar erau acolo și șefii celorlalte departa-mente ș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 vinova-tului, 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; sal-varea 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 identifi-carea 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 clientu-lui, 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

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 mag-nificelor 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

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 departamen-tele implicate și dădea toată discuția peste cap. Șefu’ încercase la început să se impună

diverse

Simona Bonghez, [email protected]

Speaker, trainer și consultant în managementul proiectelor,

Owner al Confucius Consulting


diverse

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 pla-nificat. Ș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 drep-tate, 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 departa-ment, 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 rume-

gă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ăs-punsul, 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 între-bâ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?

- 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 pro-activi și nu lucrăm împreună cu clientul. Al naibii șef, a naibii rumegătoare...

Gogu și vaca lui șefu’

powered by

sponsori

TSM_8_2013_ro

Documents

Transcript of TSM_8_2013_ro