Încep cu un scurt rezumat al articolului precedent: Se dădea o arhitectură „clasică” de web: un portal dezvoltat în ASP.net MVC (3 şi 4) având în spate o bază de date ce rula pe MS SQL server ascunsă de Entity Framework. Aceasta arhitectură trebuia pregatită de „scalare” – trecută pe un sistem ce permitea deservirea unui număr mare de request-uri. După ce am analizat mai multe opţiuni de upgrade a arhitecturii (discursul logic poate fi revăzut în articolul precendet) ne-am decis asupra SQL Azure şi Windows Azure ca platformă de migrare.

În numerele trecute am descoperit lumea pe care Hadoop o formează. O lume în care fișierele de 100GB sau 500GB sunt la ordinea zilei. Acesta ne permite să facem lucruri pe care nu le puteam face până acum. Când? Datele pe care firma noastră le colectează pot să devină o mină de aur. Putând prelucra cantități mari de date, avem posibilitatea să vizualizăm datele într-un mod pe care nu l-am putut face până acuma. Prima întrebare pe care trebuie să o punem când dorim să analizăm datele cu Hadoop este: Ce dorim să analizăm? Răspunsul la această întrebare este important, deoarece trebuie să identificăm ce vrem să facem cu datele, ce informație dorim să analizăm și care este valoarea acestor date.

Articolul din numărul trecut a realizat o trecere în revistă a tipurilor din Haskell, atât a celor preexistente cât și modalităților prin care un programator își poate crea propriile lui tipuri. Continuăm excursia în tărâmul acestui limbaj cu o scurtă prezentare a unei alte caracteristici a sistemului de tipuri, prin evidențierea modului prin care se realizează polimorfismul în acest limbaj: clasele de tipuri. Deși noțiunile de clasă și polimorfism duc imediat cu gândul la programarea orientată pe obiecte, țineți minte că suntem în alt tărâm.

Experienta e bună. Sau nu? Experienţa e bună atâta timp cât trebuie să rezolvi aceleaşi probleme. Experienţa e din păcate ne-bună atunci când ai probleme noi sau ai nevoie de soluţii noi. De ce? Mintea umană gândeşte simplu. Asta e foarte bine atunci când trebuie să reacţionezi repede sau când ai ca scop eficienţa. Ştim totuşi că în ziua de azi ne trebuie şi altceva decât quick and easy. Ne trebuie nou, nemaivăzut, creativ, inovativ, fresh …

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

Gogu îl văzu pe Șefu’ intrând în birou și își înghiți replica. Mișu, cu spatele la ușă, nu remarcă mișcarea și în lipsa oricărui comentariu al lui Gogu, conchise:
- Va să zică, gândești tu că i s-a urcat șefia la cap?!
- Cui i s-a urcat șefia la cap?! întrebă Șefu’. Alo, Șefu’ către Mișu, recepție! Insistă el către un Mișu care înțepenise, doar ochii mijiți către Gogu țipau tăcut a ajutor. Gogu îl ignoră însă și uitându-se la Șefu’ mai puse un lemn pe foc:
- Hai Mișule, nu sta ca ciobanu’ la oi, te-a întrebat Șefu’ ceva! Zâmbi cu drag pe sub mustață, Mișu era incredibil de simpatic în inocența lui și nu se putea abține să nu-l zgândăre. Ochii mijiți ai lui Mișu trecură de la ruga tăcută la reproș mut, iar Gogu izbucni de-a binelea în râs:

În ziua de azi, testerii sunt priviți ca fiind cei care execută munca de rutină, de o dificultate mai ușoară, și ale căror skill-uri tehnice nu sunt atât de puternice pe cât cele ale programatorilor. Există echipe fragmentate, două tabere practic: developeri și testeri. Accentul nu se pune pe comunicare și colaborare, ci se investește efort și energie în acel vechi “battle”, în care fiecare dorește să demonstreze că echipa proprie e mai bună.

Imaginați-vă următoarea situație: o echipă a dezvoltat timp de 6 luni un produs grozav, care se vinde imediat. Utilizatorii își arată pasiunea pentru produs cerând mereu funcționalități noi. Dacă echipa nu livrează noile funcționalități destul de repede, fericirea lor va scădea, poate chiar vor decide să migreze la concurență. Echipa trebuie să livreze rapid.

În ultima perioadă antreprenorii români au la dispoziție din ce în ce mai multe modalități de a-și facilita dezvoltarea unei afaceri. Fie că vorbim despre fonduri nerambursabile, comunități antreprenoriale sau incubatoare de afaceri, aceste programe sunt un ajutor incontestabil, mai ales în fazele incipiente ale dezvoltării companiei.

Articolul din numărul trecut a realizat o scurtă introducere în limbaj prezentând mai mult istoria și beneficiile lui și mult mai puțin elemente de cod propriu-zis. Astăzi, ne apropiem de acest deziderat discutând despre tipurile limbajului. Un lucru absolut definitoriu pentru limbaj este faptul că Haskell are tipare statică: fiecare expresie are un tip cunoscut de la compilare. În plus, nu există conversii implicite între tipuri similare: programatorul va trebui să facă explicit conversiile în locurile în care acestea sunt necesare.

Am ales pentru acest articol o serie de numere: 1957, 7400, 196/17, 27/100000000. Ele descriu traseul de la înființarea primei instituții ITC până la autoorganizarea comunității actuale într-o breaslă. Pe scurt contextul istoric, evoluția și situația actuală.