A devenit o traditie pentru mine sa incep retrospectiva anuala cu acest subiect.

PHP 6 este la fel de aproape de lansare cum era si anul precedent, sau acum doi ani, adica lipsit de perspectiva. In 2011, PHP 5.4 a ajuns la RC4 si probabil se va lansa in curand versiunea finala, lucru care inseamna ca inca nu se previzioneaza o data pentru lansarea PHP 6. Dar despre PHP 5.4 cu alta ocazie, este pe lista mea de “TODO” sa vad ce a ajuns in RC4.

Cum in PHP 5.3 cuvintele cheie pentru mine au fost namespaces, Anonymous functions, closures si garbage collector, in PHP 5.4 se pare ca aceste cuvinte cheie vor fi traits, din nou closures si scalar type hinting, alaturi de multe alte noutati.

Cand am scris primul meu blog anual despre PHP 6, lucram in principal la site-uri in romana, de acolo si dorinta mea pentru o versiune care sa suporte in mod nativ aceasta limba sau oricare alta fara nici o modificare. Pe atunci lucram in cea mai mare parte direct cu limbajul, de cele mai multe ori fara sa folosesc un framework . Dar de atunci a trecut mult timp si mutle lucruri s-au schimbat, acum folosesc aproape exclusiv framework-uri si platforme care m-au indepartat de limbaj oferindu-mi o noua perspectiva arhitecturala.

Dupa mai bine de un an in cadrul NCH, am decis ca este timpul pentru o schimbare. Si de data asta este vorba tot de o corporatie venita din state cu o sucursala in Romania. De data asta este vorba de Optaros. Desi nu intentionam sa-mi schimb locul de munca, am dat curs unei invitatii la interviu si pe scurt, am plecat. De mult simteam nevoia sa lucrez din nou pentru clienti externi, dupa experienta NCH unde toate proiectele erau interne, simteam nevoia de o schimbare.

Din nou proiectele sunt si mai mari, cu alte probleme de scalabilitate. Dar cred ca asta face web development-ul atat de interesant, cu cat ai probleme mai mari de scalabilitate, cu atat inseamna ca lucrezi la un proiect mai mare.

Anul trecut cuvintele cheie au fost Linux si Symfony framework. Pentru anul care tocmai s-a incheiat cuvintele cheie probabil au fost: Magento si Drupal.

Dupa o scurta perioada de lucru cu Magento, pot spune ca mi se pare incredibil cum o platforma atat de mare are atat de putina documentatie si de multe ori atat de multa inconsistenta. Este o plaforma foarte complexa cu care poti face foarte multe lucruri, dar cand vine vorba de documentatie, se pare ca abordarea se rezuma la a analiza core-ul. Venind din lumea Symfony, unde exista literalmente carti intregi de documentatie, puse la dispozitie in mod gratuit, mi se pare incredibil cat de putina si descentralizata documentatie este pentru Magento. Dar de asemenea este un subiect pentru un alt blog. Cred ca aici echipa Optaros m-a ajutat destul de mult ca sa inteleg cum sa abordez problemele.

Un alt eveniment important pentru mine acest anul trecut a fost Yahoo! Open Hack Day, eveniment tinut si in Romania in 2011. Nu stiu daca am mai vazut atata entuziasm si energie intr-un singur loc, intr-o singura zi. Pentru mine ca programator a fost o experienta de neuitat, unul din momentele care m-au facut sa-mi aduc aminte de ce am ales aceasta profesie.

In acest an am dat si examenul de certificare pentru PHP 5.3, chiar la inceptului anului. Examenul nu a fost atat de greu cum ma asteptam, desi se pare ca emotiile raman neschimbate. Faptul ca am mai sustinut un examen m-a ajutat mult, incredibil cat de multe lucruri iti aduci aminte cand le recitesti. Anul trecut mi-am propus sa sustin cel putin un examen de certificare pe an, deci trebuie sa incep pregatirile pentru urmatorul examen.

Concluzionand, 2011 a fost un an bun, plin de realizari si provocari, chiar daca nu am bifat foarte multe lucruri pe rezolutia de an, am realizat si multe lucruri care nu erau pe ea. Dar acum este timpul pentru o noua rezolutie de an.

Iar acum va urez un 2012 mai bun si mai plin de realizari! La multi ani!

A venit vremea sa mai public inca un joc facut in JavaScript, de data asta este vorba de Minesweeper.

Prima versiune a jocului a fost facuta initial acum aproximativ un an jumatate, dar intre timp l-am rescris total din pricina problemelor de performanta.

Acesta este cred si ultimul joc care nu il fac folosind canvas din motive de compatibilitate.

Fata de majoritatea jocurilor care au fost facute literalmente peste week-end (exceptia este Puzzle Gd) acesta s-a dovedit un joc putin mai complicat.

Pentru grafica vreau sa ii multumesc (din nou) Cătălinei Radu.

Enjoy!

Inca un motiv pentru care urasc Internet Explorer.

Toate browserele noi au tendinta sa faca cache la campurile de formular de pe o pagina. Pana aici nimic normal, usor enervant, dar nu anormal.

Se da urmatorul exemplu:

 1<select id="select">
 2 <option value=a>a</option>
 3 <option value=b>b</option>
 4 <option value=c>c</option>
 5</select>
 6<script>
 7
 8var checkSelected = function () {
 9 var element = document.getElementById('select');
10 alert(element[element.selectedIndex].value);
11}
12
13// ruleaza dupa onload
14window.onload = checkSelected;
15
16// ruleaza inainte de onload
17checkSelected();
18
19</script>

Se incarca pagina, se selecteaza a treia valoare si apoi se face refresh. Pentru ca nu s-a trimis nici un formular prima impresie este ca rezultatul va fi mereu “a”. Se pare ca nu este tocmai asa:

• FireFox: c c
• Google Chrome: a a
• Internet Explorer: a c

Pot sa inteleg de ce FireFox a ales sa faca cache la valori chiar si daca nu se trimite formularul.

Pot sa inteleg si ca in cazul Google Chrome nu face cache la pagina daca nu s-a trimis formularul.

Dar ca Internet Explorer face cache si il incarca de abea dupa ce a incarcat toata pagina? Asta mi se pare confuz! Adica nu ai varianta sa nu folosesti onload? De ce? Nici macar nu am trimis formularul?

Testul a fost facut pe Internet Explorer 9 si compatibility view la versiunile 7 si 8.

Am inceput sa scriu acest blog in urma cu aproximativ 1 an.

Un subiect mai delicat si de multe ori mai putin abordat de project manageri este relatia intre calitatea codului si timpul de dezvoltare.

Calitatea codului este o problema presanta pentru programatori, o problema cu care ne confruntam aproape zilnic.

In ce masura este asta relevant din punct de vedere economic?

Am construit un grafic incercand sa ilustrez mai bine aceasta problema:

Graficul l-am realizat acum aproximativ un an, cand am inceput sa scriu acest post si nu eram prea sigur de el.

Recent am inceput sa citesc “Clean Code” de Robert C. Martin. Cand citeam primul capitol in drum spre munca am ajuns la “The Cost of Owning a Mess”. Fata de mine care analizam “Code quality” vs “Development time”, in carte este “Productivity vs. time”:

Am fost foarte entuziasmat sa gasesc acest grafic similar. Cu alte cuvinte, daca avem un cod calitativ, timpul necesar pentru dezvoltare va fi mai mic. Cu cat codul este mai neorganizat, cu atat timpul de dezvoltare creste.

O varianta destul de populara pentru a rezolva problema timpului de dezvoltare este rescrierea intregii platforme. Rescrierea unei intregi platforme poate sa nu fie o alegere foarte buna din pricina costurilor. In carte este adus un argument in plus, daca cele doua platforme se dezvolta in paralel acestea pot sa nu se intersecteze niciodata, deci noua platforma sa nu ajunga niciodata in productie. Eu nu am vazut niciodata un plan atat de radical pus in practica fara sa se renunte la vechiul proiect, dar un caz care l-am vazut cu mai multe ocazii este acela cand platforma se reface si desi inceputul este deosebit de promitator si totul este aliniat cu cerintele, iar problemele vechi sunt abordate intr-un mod constructiv, vine un moment cand incep sa apara compromisurile. In general un compromis arhitectural nu vine niciodata singur, o data ce realizezi ca poti face compromisuri, iar echipa nu are remuscari este primul semn ca directia va ajunge sa fie gresita din nou.

O solutie partiala cred ca este desemnarea unui arhitect care sa stabileasca cursul dezolvarii, persoana care sa managerieze proiectul si sa nu-l lase sa scape de sub control.

O alta perspectiva este ca un bug cu cat este mai vechi cu atat va fi mai greu de rezolvat. De fapt, calitatea codului este un factor mai relevant. Cu cat un cod este mai bine scris cu atat este mai usor de inteles si modificat. Ca o actiune directa este de preferat sa existe un “conding standard”.

Problema cu un “coding standard” este ca nu orice programator este gata sa-l imbratiseze. In general programatorii seniori au tendinta sa faca lucrurile asa cum sunt obisnuiti. Nici un standard nu este perfect, dar chiar si imperfect, daca se regaseste in intreg codul, calitatea acestuia creste considerabil pentru ca te astepti la o anumita abordare, nu trebuie sa o ghicesti.

Morala este: aveti grija de cod si o sa aveti mai mult timp liber, pana la urma viata e scurta, nu merita sa o petreci facand debugging. 🙂

In ultima saptamana am vrut sa fac o mica aplicatie pentru mobil (Android). Initial am vrut sa o fac folosind Titanium, platforma cu care m-am mai jucat si am fost placut impresionat.

Totusi dupa ce am descarcat compilatorul si am facut prima aplicatie am avut o surpriza, aplicatia “Hello world” avea aproximativ 5M. Cum s-a ajuns la marimea asta? Simplu, Titanium compileaza aplicatile in cod nativ dar nu exista o metoda clara prin care sa determine ce API-uri sunt folosite, asa ca va introduce minimul necesar pentru toate functionalitatile. Perspectiva de o aplicatie care trece de 5M nu m-a incantat asa ca am inceput sa caut alternative.

Mi-am instalat Phonegap, am vrut sa fac un joc si cu aceasta plaforma de mult timp, dar avand in vedere ca nu are o instalare la fel de eleganta ca Titanium nu m-a incantat. Am facut o aplicatie “Hello world” si surpriza… ~200k! O dimensiune rezonabila pentru mine.

Evident exista o explicatie, Phonegap ofera acces la multe facilitati cum ar fi: accelerometru, camera sau contacte, dar nimic pe partea de prezentare. Partea de prezentare este facuta exclusiv prin HTML, CSS si JavaScript.

Intreagul proiect Phonegap se bazeaza pe faptul ca platformele importante au nativ un “web view” care poate parsa o pagina web.

In plus, pentru ca proiectul nu este la fel de “elegat” ca Titanium poti adauga facilitati destul de usor. De exemplu pentru Android exista un numar decent de proiecte care adauga facilitati in plus pentru platforma. Modul de incarcare al lor nu e foarte dificil dar nici plug & play. Practic sunt module de Java pentru Android care au si un API care poate fi apelat din “web view”. Acesta poate sa fie un avantaj, pentru ca exista multa lume care scrie module suplimentare care nu trebuie sa fie neaparat in “core”.

Pentru aplicatii simple care fac listari sau afisaza informatii, platforma este o alternativa interesanta, mai ales ca exista o serie intreaga de framework-uri JavaScript si CSS pentru formatare, cum ar fi: jQTouch, jQuery Mobile sau XUI. Platforma este foarte buna pentru a impacheta aplicatii de acest fel. De exemplu daca ai o aplicatie HTML pentru mobil si vrei sa-i adaugi functionalitate nativa in plus si sa o distribui compilata, Phonegap face o treaba buna.

Pe de alta parte chiar daca poti accesa de exemplu butonul de meniu, nu poti construi un meniu nativ.

Concluzionand, este o platforma cu o abordare complet diferita fata de Titanium. Daca Titanium se bazeaza pe faptul ca aplicatia va ajunge cod nativ cu API-uri native, cu tot codul scris in JavaScript, iar web view este una din optiuni, abordarea PhoneGap este ca toata prezentarea sa fie exclusiv in web view folosind HTML(5) + CSS si doar cateva API-uri specifice dispozitivelor care nu pot fi accesate din browser si nu sunt legate de prezentare sa fie expuse, cum ar fi vibratia, butoanele, etc. Avand in vedere aceste lucruri nu cred ca se poate face o comparatie reala intre platforme, doar programatorul poate decide care este abordarea de care are nevoie.