Claudiu Persoiu

Blog-ul lui Claudiu Persoiu


Archive for 16 October 2011

Un nou joc JavaScript – Minesweeper

without comments

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!

Written by Claudiu Persoiu

16 October 2011 at 9:47 AM

Posted in Diverse,JavaScript

Tagged with , ,

Internet Explorer, select tag si onload

without comments

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:

<select id="select">
 <option value=a>a</option>
 <option value=b>b</option>
 <option value=c>c</option>
</select>
<script>

var checkSelected = function () {
 var element = document.getElementById('select');
 alert(element[element.selectedIndex].value);
}

// ruleaza dupa onload
window.onload = checkSelected;

// ruleaza inainte de onload
checkSelected();

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

Written by Claudiu Persoiu

9 October 2011 at 2:09 PM

Calitatea codului si durata de lucru

with one comment

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:

code-quality

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

Written by Claudiu Persoiu

4 October 2011 at 9:48 PM

Posted in Diverse

Tagged with ,