Exista carti intregi despre optimizare, dar putina lume mentioneaza si momentul cand aceasta ar trebui sa aiba loc.

Sunt cateva viziuni fundamental diferite:

• in timpul dezoltarii
• la finalul ciclului de dezvoltare
• niciodata

Oare care este raspunsul corect? De fapt exista doar mai putin corect sau inadecvat.

In timpul dezoltarii

Acest raspuns are cel mai mare potential sa fie gresit.

Desi este cea mai aplicata metoda si nu ar trebui interpretata ca fiind gresita, aceasta are potentialul de a duce la probleme.

Cand duce la probleme? Cand in loc de optimizare se foloseste micro-optimizare in mod excesiv.

Micro-optimizarea poate avea diferite forme in funtie de modul de dezoltare al proiectelor. Unii prefera sa scrie cod “bulk” sau cod procedural, altii folosesc framework-uri si  ORM-uri. In momentul cand te abati de la regula generala de scriere pentru a face optimizare trebuie sa te gandesti la consecinte. Cel care vine in urma ta probabil o sa inteleaga mai greu ce se petrece acolo, iar daca din asta faci o regula in timp proiectul va deveni indescifrabil.

De exemplu daca folosesti un ORM si incepi sa scri SQL deja piezi scopul ORM-ului. In ORM se fac cativa pasi pentru fiecare interogare:

Constructie interogare obiectual -> Parsare in SQL -> Executie interogare -> Parsare rezultat -> Incarcare obiecte rezultate

vs.

Constructie interogare SQL -> Executie interogare -> Parsare rezultate

Pasii variaza in functie de implementare.

De multe ori pare mai simpla si este in mod sigur mai rapida varianta a doua. Dar de ce se foloseste prima varianta? Pentru avantajele arhitecturii! Se pot pune triggere la accesarea sau setarea de proprietatilor de exemplu.

Un programator matur este cel care scrie un cod “lizibil”, nu doar optim.

La finalul ciclului de dezvoltare

Avantajul este ca nu se fac compromisuri arhitecturale in timpul dezvoltarii.

Asta este in general metoda cea mai buna, pentru ca ai produsul final, dezoltat fara compromisuri si poti sa schitezi punctele care ar trebui sa fie optimizate. In momentul cand ai toate componentele este mult mai usor sa le reorganizezi decat in timpul ciclului de dezoltare cand pot aparea modificari care la randul lor pot duce la replicare de cod de exemplu.

Dezavantajul este ca la final este uneori dificil sa depistezi punctele slabe ale aplicatiei.

Niciodata

In primul rand sa nu existe indoieli, ma refer la proiecte “serioase”.

Este o regula generala care spune ca “hardware-ul este ieftin, programatorii sunt costisitori”. Mai pe larg asta inseamna ca este de multe ori mai simplu sa scalezi o aplicatie folosind hardware decat sa faci compromisuri majore in cod.

Multe firme si proiecte sprijina perspectiva asta. Aplicata corect are avantajul ca va fi un cod organizata bine tot timpul, usor de citit cu foarte putine hack-uri.

Avantajul este la dezvoltare, lipsa hack-urilor face un proiect mai bine organizat (teoretic) si mai usor de extins.

Din pacate se pare ca exista o interpretare diferita: “trebuie sa mearga, nu sa fie perfect”. Unde poate duce asta? Practic este cea mai buna scuza pentru cod mizerabil.

Diferenta majora este ca nu optimizezi, iar codul va arata cel putin la fel de rau ca atunci cand ii faci micro-optimizare.

Concluzie

In general proiectele care au parte de micro-optimizare excesiva, au potential sa fie rescrise destul de des, fie partial ori complet, pentru ca exista o alta regula care spune ca “decat sa repari, de multe ori este mai simplu sa rescrii”. Din pacate aceeasi soarta o au si proiectele care au cod neingrijit.

Un dezavantajul major la calitatea codului este ca ingreuneaza productia, cu alte cuvinte lucuri minore dureaza din ce in ce mai mult pentru a fi realizate.

Proiectele nu trebuie mereu optimizate. Dar atunci cand trebuie, copromisurile in materie de arhitectura trebuie sa fie minime.

In week-end navigam intrebandu-ma de ce nu exista inca 3d pe net realizat in JavaScript. O intrebare ridicola intr-o dupamiaza torida.

Intrebarea mea a plecat de la ideea ca prima etapa in evolutia 3d a fost facuta in 2d, practic reprezentarea obiectelor 3d folosind mijloacele 2d existente.

Evident am ajuns usor la primul meu rezultat: un shooter 3d direct in browser folosind JavaScript realizat de Ben Joffe!

Este cel putin impresionant!

In afara de acest raspuns imediat am mai gasit cateva variante de jocuri 3d realizate in JavaScript care nu se foloseasc de facilitati cum ar fi canvas, dar acele rezultate nu sunt foarte impresionante dintr-un motiv simplu: viteza!

Pana la HTML5 viteza de afisare in browser era o problema foarte mare. Este bine cunoscut ca una dintre cele mai incete componente dintr-un browser este DOM, in special in Internet Explorer. Cand vine vorba totusi de canvas se poate vedea o diferenta imensa in bine, multitudinea obiectelor de pe scena nu mai sunt coordonate prin DOM ci pur si simplu afisate intr-un element cu adevarat grafic.

In timp ce deschideam calculatorul azi ma intrebam, oare de ce nu se poate realiza un joc care sa fie macar ca Duke Nukem 3D? Evident, probabil browserul nu o sa devina prea curand o platforma concurenta cu XBOX pentru jocuri dar este normal… Nici nu-mi dau seama cum am ajuns acolo, dar parca ceva din universul meu m-a inpins spre ceva cu adevarat impresionant:

Quake 2 direct in browser, folosind JavaScript!

Initial m-am gandit ca au trisat, au folost WebGL, nu doar popularul canvas 2d. Dar rezultatul este cu adevarat impresionant, iar acest standard probabil va fi disponibil ca specificatie in HTML5, adica se va regasi pe cel putin o parte din browsere.

Chiar daca au folosit GWT, codul final rezultat este JavaScript, deci asa ceva se poate realiza folosind doar JavaScript!

De unde a plecat toata ideea de 3d in browser? Am citit acum aproape 2 ani despre niste eforturi in acest sens, iar acestea se bazau pe VRML. Dar VRML exista ca standard din 1994 si nimic impresionant nu am vazut pana acum. Am chiar si o carte de VRML care se umple de praf in biblioteca. Marele defect este ca nu exista browsere care sa ofere suport nativ.

Noua perspectiva este cu totul inovativa, pentru ca este o punte intre browser si hardware 3d. Deci probabil ca daca vom avea 3d in browser intr-o buna zi, asa va fi realizat!

Lucram eu zilele trecute la un nou joculet in JavaScript pentru sectiunea de jocuri. Ca marea majoritate a programatorilor (cum arata statisticile) si eu folosesc FireFox pentru dezvoltare. Dar cum jocul a ajuns in faza de testare am zis ca e timpul sa vad daca inca mai functioneaza corect in Internet Explorer.

Sa testez in Internet Explorer este o adevarata placere mereu, practic primesti o eroare iar apoi speri ca ai gasit sursa.

Evident a aparut o eroare, una plina de semnificatie ca de obicei:

Unknown runtime error??? WTF??? Daca el nu stie la ce are eroare, eu cum ar trebui sa stiu?

Bucata de cod care genera eroare era:

1canvas.innerHTML = '';

Unde canvas era un o variabila care stoca un document.getElementById(‘canvas’), iar id-ul canvas era de la:

1<table border="0" cellspacing="0" cellpadding="0">
2<tbody id="canvas"></tbody>
3</table>

Pare gresit? ei bine nu este pentru ca in acel moment am inceput sa ma uit la alte jocuri care fac cu succes acelasi lucru, chiar si in IE.

Am incercat si in IE 6, evident aceeasi eroare.

Se pare ca eroarea apare la blocuri cum ar fi table, tbody, p si altele.

Ca sa rezolv totusi problema am folosit in loc de un tbody un div in care adaug elementele iar problema a disparut ca prin minune.

Ce este interesant este ca problema asta nu apare tot timpul pentru un anumit tip de tag!

Multumesc Microsoft pentru mesajele de eroare care sunt atat de pline de logica!

In PHP 5 a fost introdus un nou concept, cel de type hinting. Acesta faciliate permite validarea unui parametru intr-un anumit tip.

Acest tip de validare este unul destul de popular in limbajele obiectuale si cred ca reprezinta un plus pentru modelul obiectual din PHP si mai ales pentru acest limbaj dinamic in sine.

In PHP 5.1 a fost introdusa si validare pentru tipul array.

Sa luam un mic exemplu:

 1class a { }
 2
 3class b { }
 4
 5function testa (a $a) {
 6    echo "Bla bla\n";
 7}
 8
 9testa(new a());
10
11testa(new b());

Rezultatul este:

1Bla bla
2
3Fatal error: Argument 1 passed to testa() must be an instance of a, called in ...

Tare nu?

Tipul pentru care se valideaza poate sa fie o clasa, o clasa abstracta sau chiar o interfata care este mostenita de mai multe clase, cum ar fi:

 1interface inherited { }
 2
 3class a implements inherited { }
 4
 5class b implements inherited { }
 6
 7function testa (inherited $a) {
 8    echo "Bla bla\n";
 9}
10
11testa(new a());
12
13testa(new b());

Iar exemplul de mai sus nu va da nici o eroare.

Din pacate totusi nu exista nici un mod de a valida tipuri primare (sau scalare) de date. Cand a aparut PHP 5.3 au fost niste discutii pe tema asta, dar se pare ca a fost prea tarziu iar patch-ul nu a ajuns in versiunea finala.

Ieri dimineata, in timp ce imi faceam lectura de dimineata la o cana de cafea, ce gasesc pe blog-ul lui Ilia Alshanetsky: Scalar Type Hints are Here! Bine, e putin exagerat, nu sunt tocmai aici dar sunt foarte aproape. Practic sunt in trunchiul de SVN si vor fi publice in viitoarea versiune!

Evident ca si varianta de acum de type hinting nu este tocmai o regula obigatorie a PHP, este mult mai mult o problema de finete.

Pracic se putea oricum face validarea pe un anumit de date primare pana acum, dar totusi:

1function testint($var) {
2     if(!is_int($var)) {
3         trigger_error("Type must be Integer", E_USER_ERROR);
4     }
5     .......
6}

nu este tocmai elegant, fata de:

1function testint(int $var) {
2     ......
3}

Packt Publishing a scos o noua carte despre framework-ul PHP de tip RAD, CodeIgniter versiunea 1.7.  Cartea CodeIgniter 1.7 Professional Development scrisa de Adam Griffiths , are sloganul “become CodeIgniter experts with professional tools, techniques and extended libraries”.

Doar din slogan se vede un ton putin diferit fata de cartea CodeIgniter 1.7 de la Packt Publishing care dupa parerea mea avea mai mult scopul de a arata ce poate face framework-ul CodeIgniter.

Aceasta noua cartea are mai mult scopul de a arata cum poti dezvolta aplicatii profesionale, sau cel putin pana la proba contrarie, stay tuned to find out!

Un argument pentru slogan este si target-ul asa cum este definit in “Who this book is written for”, care contine fraza:

Basic knowledge of CodeIgniter will be helpful.

O fraza periculoasa dupa parerea mea, pentru ca poate speria un incepator, chiar daca in carte se pare ca sunt descrisi toti pasii de la instalarea serverului.

Daca de la prima carte ma asteptam la o prezentare generala, acum sunt curios sa vad daca exemplele sunt mai ample si mai concrete.

Din capitoul mostra se poate vedea ca in care este foarte mult cod. Cat timp este logic cred ca este bine, este de multe ori mai usor sa intelegi din cod, pe care oricum il vei scrie si tu si il poti lua drept exemplu, decat teorie.

Dar mai multe despre aceasta carte dupa ce voi avea ocazia sa o lecturez.

Va urma…