Informaticienii și-au dat seama rapid că unele probleme sunt dificil de rezolvat, indiferent de progresele tehnologice ale puterii de calcul. În analiza algoritmilor, notația Big O a devenit cel mai utilizat standard de măsurare a complexității și a fost introdusă în anii ‚70 de Donald Knuth, autorul celebrei cărți: The Art of Computer Programming. În general, notația Big O măsoară scenariul cel mai pesimist pentru modul în care crește timpul de execuție sau consumul de memorie în funcție de dimensiunea datelor de intrare. De exemplu, complexitatea algoritmului GCD este O(log(min(a, b)). Prin comparație, căutarea într-o arie cu n elemente are o complexitate O(n), deoarece numărul de pași - în cel mai rău caz - crește proporțional cu dimensiunea tabloului. Cu toate acestea, extragerea unui element din arie are o complexitate de O(1), presupunând că știm indicele elementului pe care îl căutăm. Programele „Hello world” au o complexitate constantă O(1), iar algoritmii Divide et Impera pot reduce complexitatea lineară O(n) la o complexitate logaritmică O(log n), deoarece nu toate subproblemele vor fi evaluate.

M&A planificate strategic pot ajuta companiile să construiască reziliență, doar că acestea presupun mult mai mult decât executarea unui șir lung de oferte. Achizitorii trebuie să articuleze exact de ce și unde au nevoie de fuziuni și achiziții pentru a aborda probleme și obiective specifice care stau la baza strategiilor lor corporative. În plus, ei trebuie să acorde o gândire atentă cu privire la modul în care intenționează să urmărească aceste procese de M&A programatice și să conceapă inclusiv un plan de afaceri ca atare. Tipurile și metodele fuziunilor și achizițiilor se împart în patru categorii mari. Cea orizontală, verticală, conglomerată și congenerică. În general, indiferent de tip, o companie va achiziționa o altă companie, deoarece factorii săi de decizie cred că va îmbunătăți mersul afacerii fie prin creșterea vânzărilor, scăderea costurilor, fie prin alte moduri.

Accesibilitatea se referă la crearea unui mediu care să fie ușor de utilizat și la îndemâna utilizatorilor, indiferent de abilitățile lor. Aceasta include, printre altele, asigurarea unei experiențe prietenoase pentru persoanele cu deficiențe de vedere, de auz, cu dificultăți de mobilitate sau cu alte tipuri de dizabilități.

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

Ne-am bucurat de lansarea din luna iunie a revistei TSM pe acoperișul sediului celor de la msg systems Romania. Am discutat despre tehnologii și limbajul Java în special alături de invitații noștri:

• Alex Popescu - Senior IT Consultant @ msg systems ,

• Denisa Lupu - Java Software Developer @ msg systems ,

• Paul Trestian - Solutions Architect @ Accesa,

• Ovidiu Mățan (moderator) - Fondator @ Today Software Magazine

Microservicii sau monoliții, arhitecturi serverless sau orientate pe servicii, MACH, blocuri fundamentale ale arhitecturii aplicațiilor Java, containerizare, aplicații 12 factor și altele. Iată o gamă foarte diversificată de soluții pe care le avem la dispoziție și din care este dificil de o ales pe cea optimă., Oricum, o soluție universală care să se potrivească tuturor provocărilor nu există. Atunci apare întrebarea „Contează cu adevărat tipul de arhitectură? ” Este o arhitectură bazată pe microservicii superioară uneia monolitice?

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

Arhitectura proiectului, pe care o vom prezenta mai jos, s-a născut dintr-o inițiativă de cercetare a unui jucător important din sectorul de externalizare a proceselor de business (BPO). Serviciile BPO includ: consultanță, asistență comercială, servicii juridice, vânzări și suport tehnic.

În ultimii ani, SAP a făcut o schimbare majoră în modul în care furnizează soluțiile sale software prin trecerea de la soluțiile on-premises la cele cloud. În mod tradițional, soluțiile SAP au fost oferite clienților prin intermediul instalării software-ului pe propriile lor servere și gestionarea lor internă însă, odată cu creșterea popularității cloudului, dezvoltatorii SAP au identificat oportunitatea de a dezvolta și soluții bazate pe acesta.

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

Acum mulți ani, un coleg consultant olandez m-a recomandat unui business olandez ce avea un centru de dezvoltare în Cluj pentru a face un audit. Nu am avut mare succes în această organizație. Cu totul surprinzător pentru mine, m-au rugat să revin pentru a verifica progresul și a face niște recomandări. Au înțeles că în calitate de auditor le pot oferi doar răspunsuri teoretice. Nu le puteam spune ce să facă sau cum să facă, dar clientul a fost mulțumit cu acest lucru.

Conceptul de arhitectură, prin natura sa, descrie ceva solid, ceva ce oferă îndrumare și structură acolo unde altfel ar exista doar haos și posibilități infinite. Atunci când ne referim la arhitectura software-ului, o percepem ca fiind abordarea optimă pentru implementare - un principiu de ghidare, un cadru sau o bază la care developerii atașează conținut, cod și componente esențiale care permit întregului sistem să funcționeze. Cum putem caracteriza ceva atât de rigid precum arhitectura ca fiind evolutiv?

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