Aplicațiile actuale sunt fără îndoială sofisticate și se bazează pe o multitudine de tehnologii. În calitate de programatori, noi ne concentrăm mai mult pe partea de implementare a softului, începând cu limbajul de programare, frameworkul sau toolul pe care îl vom folosi. Acest lucru se întâmplă din cauza faptului că programatorii sunt înclinați spre rezolvarea de probleme, iar căutarea unor soluții reprezintă o parte interesantă a jobului. Cu toate acestea, un sistem care nu rezolvă nevoile de business nu este deloc util, indiferent cât de frumos arată sau cât de bine este implementat din punct de vedere arhitectural.

Publicat în Numărul 54 Citeşte mai mult

BDD propune o abordare ce are ca scop reducerea erorilor de înțelegere ale unei specificații în cadrul unei echipe, adesea de neevitat atunci când o informație este transferată de la un stadiu la altul în procesul de dezvoltare software (de la client către business analyst, apoi la programatori și testeri). BDD nu reprezintă o metodologie de dezvoltare software de sine stătătoare (nu încearcă să abordeze toate zonele acestui domeniu vast), astfel că va trebui să fie utilizată în corelație cu alte metodologii, precum Agile, Test Driven Development sau Domain Driven Development.

Publicat în Numărul 54 Citeşte mai mult

Să analizăm Azure Functions din perspectiva programatorului. În acest articol vom scrie o funcţie Azure (Azure Function) care adaugă coordonatele GPS pentru o imagine sub formă de watermark.

Să presupunem că deținem o companie ce activează în domeniul dezvoltării de software. Identificăm o nevoie și o piață de desfacere, după care conturăm o primă idee despre ce putem oferi . În primul rând, trebuie să stabilim dacă ceea ce urmează să dezvoltăm reprezintă un serviciu pe care îl prestăm sau dacă va rezulta un produs propriu, pe care îl vom valorifica în viitor. Astfel, trebuie să aplicăm câteva criterii pentru a putea încadra corect rezultatele în una dintre cele două categorii. Aspectele legate de prestarea de servicii sunt mult mai ușor de evaluat, astfel vom încerca să conturăm criteriile necesare pentru a recunoaște dacă ceea ce producem este un produs, un activ necorporal.

Publicat în Numărul 54 Citeşte mai mult

În procesul de dezvoltare de software, una dintre practicile devenite din ce în ce mai comune, chiar necesare în majoritatea echipelor, este integrarea continuă. În funcție de tehnologie, integrarea continuă se poate realiza în mai multe moduri. În acest articol vom prezenta o soluție la această problemă din punctul de vedere al dezvoltării aplicațiilor mobile pe platforma iOS. Soluția noastră se bazează pe Xcode Server și pe platforma online de distribuție Fabric.IO.

Cu ceva timp în urmă s-a născut un vis. Un vis care a luat naștere din cele mai adânci temeri ale comunității dezvoltatorilor de soft: visul de a livra cu succes un cod pur, curat, de calitate și, cel mai important, LA TIMP. Odată cu creșterea rapidă a comunității IT-iștilor, ideea a început să prindă rădăcini în sufletul dev-ilor și încet, încet, să devină o mișcare, un concept, care astăzi ne domină existența profesională: CONTINUOUS DELIVERY. Voi aborda o notă mai serioasă. Scopul oricărui dev aspirant și ambițios ar trebui să fie următorul: codul scris de tine, rodul muncii tale, trebuie să ajungă pe piață, la utilizatorul final in cel mai scurt timp.

Publicat în Numărul 53 Citeşte mai mult

Salut! Mă numesc Cătălin Beșleagă, m-am născut și am crescut în Dorohoi. Pe la vârsta de 8-9 ani, împreună cu fratele meu, am descoperit ce face comanda format iar mai târziu am descoperit la ce e bun sectorul de boot după ce l-am șters încercând să facem spațiu pe disk. Primul contact cu programarea l-am avut pe la vârsta de 10 ani, la “Clubul Copiilor”, unde am fost inițiat în BASIC. Am terminat Informatica la UBB după care am început un master în Baze de Date. Îmi place să călătoresc și să cunosc culturi diferite, îmi plac plimbările la munte și fotografia, iar de curând mi-am descoperit pasiunea pentru zbor.

În momentul de faţă, dezvoltarea aplicaţiilor web client nu seamănă deloc cu dezvoltarea de acum câţiva ani.Deoarece viteza engine-urilor JavaScript a crescut, așteptările utilizatorilor pentru aplicaţiile care rulează în browser au crescut. Utilizatorii sunt obișnuiţi cu site-uri care au interfeţe de utilizator complexe: Facebook, Gmail sau Google maps. Pentru a putea crea astfel de interfeţe, trebuie să tragem cu ochiul la ceea ce folosesc ceilalţi pentru a rezolva acesta lucru. Alegerea toolurilor, a limbajelor de programare și a librăriilor a explodat în ceea ce privește opţiunile, în ultimii ani, fapt ce a dus la așa-zisa „oboseală JavaScript” ("JavaScript fatigue").

În ultimele articole despre SAP HANA, ( “SAP HANA ca bază de date”, “SAP HANA ca Platformă” și “Căutarea și analiza textelor în SAP HANA” ) am vorbit despre cum poate fi programată baza de date HANA. În acest articol vom vorbi despre diverse tooluri care ne ajută să analizăm o aplicație menită să ruleze pe SAP HANA. Mai exact ne vom axa pe folosirea instrumentelor, specifice HANA, în contextul optimizării accesului la baza de date.

Utilizând SAP HANA, puteţi efectua calcule ale businessului direct pe datele originale în memoria principală, fără necesitatea de a transforma datele. Multe dintre aceste calcule pot fi modelate grafic, ca view-uri de date speciale în SAP HANA Studio, fără a mai fi nevoie de cod. Acest articol prezintă opţiunile de modelare de date în SAP HANA, care sunt inima dezvoltării de aplicaţii in HANA. Datele de business ale unui domeniu sunt memorate (de obicei în forma normalizată) în tabelele din baza de date, care sunt conectate printr-un foreign key (așa-numită entity-relationship model). Cu ajutorul acestui model de date, pot fi create, selectate şi modificate eficient înregistrări unice. Totuşi, dacă accesul la date devine mai dinamic şi mai complex sau dacă anumite analize sau verificări sunt necesare, datele trebuie să fie transformate.