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…

PHP pentru desktop, merita?

PHP este descris pe Wikipedia ca fiind:

PHP: Hypertext Preprocessor is a widely used, general-purpose scripting language that was originally designed for web development to produce dynamic web pages.

Luand in considerare aceste lucruri, aplicatiile se impart in 3 categorii: web, command line si desktop.

Pentru mediul Web, PHP este cel mai popular limbaj open-source (si nu numai).

PHP CLI

PHP CLI (Command Line Interface) mi se pare foarte interesant, chiar daca este cam putin folosit. Multi prefera shell scripting, sau Perl fara nici un motiv real. Eu pot spune ca m-am jucat cu aceasta facilitate si mi-a placut rezultatul.

Framework-uri importante, cum ar fi Zend, Symfony sau Cake PHP se folosesc de PHP CLI pentru a genera proiecte, CRUD sau pentru alte facilitati care se pot folosi cu usurinta in linie de comanda.

In windows linia de comanda nu este tocmai populara, dar in linux este aproape imperativ. Pana la urma ce rost are sa faci un script in shell scripting daca poti sa folosesti un limbaj puternic si cu foarte multe facilitati cum ar fi PHP?

Dar CLI nu se limiteaza doar la linia de comanda, este de mai multe ori folosit pentru cronjob-uri, pipe-uri, socket-servere etc.

PHP-GTK

Cand vine vorba de php si desktop majoritatea se gandeste la PHP-GTK. Ce cred despre proiect? Nu e mort dupa cum scrie si pe site-ul oficial, dar nu este tocmai viu. Motivul? Gtk nu e tocmai simplu. Daca provi din mediul linux probabil nu e asa de dificil, daca insa ai lucrat mai mult pe web, nu e tocmai html… Cu toate acesta exista o comunitate in spate care inca sustine acest proiect.

Cu toate astea iti permite sa construiesti aplicatii desktop in PHP, compatibile cu o gama larga de sisteme de operare.

Dar este totusi o problema, aplicatiile rezultate nu sunt tocmai cod compilat, acestea trebuie sa ruleze folosind o masina virtuala de PHP.  De aici apare problema, cum distribui aplicatia? Daca ai o aplicatie mica, de cateva randuri, sa o distribui impreuna cu masina virtuala este cam complicat… De asemenea codul este vizibil, evident exista metode de a rezolva aceasta problema, dar asta nu este tocmai simplu.

Aceasta este probabil cea mai populara platforma PHP pentru desktop, daca se poate spune asta despre acesst mediu.

Documentatia, destul de stufoasa a fost preluata de la versiunea pt. C++. Nu este la fel de bine finisata cum e manualul oficial PHP de exemplu, dar cred ca este suficienta.

Winbinder

Fata de PHP-GTK are un dezavantaj, nu merge decat pe sisteme de operare MS Windows. Avantajul este ca are un API mult mai simplu. Daca ar fi sa aleg o platforma PHP pentru desktop, probabil Winbinder ar castga. Din pacate este in aceeasi stare, nu e mort dar nici viu. Si acesta se bucura de sprijinul unei comunitati, dar fara rezultate iesite din comun.

Problema cu codul compilat se regaseste si aici, ba mai mult problema legata de distributia platformei este si ea prezenta. Cred cu fermitate ca daca vrei sa dezvolti o aplicatie folosind aceasta platforma, sa o faci sa mearga pe calculatorul tau este cea mai mica problema, sa o faci sa mearga pe calculatorul altcuiva este adevarata problema…

Documentatia este destul de mica, datorita simplitatii API-ului. Dar simplitatea este buna in programare, iar asta inseamna ca poti cu usurinta sa construiesti aplicatii destul de interesante.

Compilatoare

Nu sunt multe, iar majoritatea au probleme pentru ca folosesc versiuni vechi de PHP sau chiar de GTK. Am petrecut multe ore pe Google incercand sa gasesc niste solutii reale dar in zadar.

Principalele compilatoare sunt:

• Bambalam – functioneaza pentru CLI si Winbinder fara probleme. Dar are un dezavantaj important: nu este compatibil decat cu PHP 4.4.4, iar asta cred ca spune tot. Oricum mi se pare cea mai interesanta solutie, din pacate prea veche (ultima versiune a aparut in 2006).
• PriadoBlender – functioneaza bine cu PHP-GTK si CLI, dar este cam instabil. Ultima versiune (beta) a aparut in anul 2007, de atunci nu s-a mai auzit nimic nou. Daca probabil ar mai fi actualizat aceasta versiune ar ajuta mult proiectul PHP-GTK.

Concluzie

Cand vine vorba de Web, totul merge excelent!

PHP in linie de comanda devine tot mai popular si apar tot mai multe unelte!

In mediul desktop este o senzatie de “living dead”… Aceste proiecte nu au murit dar nici nu sunt tocmai in viata. Evident mai sunt si alte solutii PHP pentru desktop pe care nu le-am amintit, dar si ele sunt tot cam in aceeasi situatie. Probabil ar trebui o abordare diferita, mai atractiva pentru dezvoltatorii din mediul web pasionati de acest limbaj.