Packt Publishing launched Open Source Awards 2010.

This Open Source award is an online event held by Packt to distinguish excellence among the various projects within the community.

This is a great opportunity to vote for your favorite Open Source software. The main categories are:

• Open Source CMS Award
• Hall of Fame CMS
• Most Promising Open Source Project
• Open Source E-Commerce Applications
• Open Source JavaScript Libraries
• Open Source Graphics Software

You can nominate until November 6! After that voting will take place.

This is a good opportunity to show your gratitude to your favorite open-source software!

So go to Packt Publishing – Open Source Awards 2010 and play your part!

Cand vine vorba de Android si PHP s-a scris mult pe tema PHP for Android.

Conceputul este simplu, Google a lansat Android Scripting Environment (ASE).

ASE este asa cum spune si numele, este un mediu de scripting, iar aplicatiile nu sunt compilate si pot fi modificate de catre utilizator in orice moment.

Peste ASE se instaleaza extensii pentru diferite limbaje cum ar fi: Python, LUA, Perl, JavaScript sau JRuby.

Din pacate nu exista suport oficial pentru PHP din partea Google, dar exista PHP for Android, proiect care permite integrarea PHP CLI cu acest mediu.

Instalarea este foarte simpla si se face direct pe mobil. Pentru a dezolta se poate folosi simulatorul din Android SDK.

Una din probleme este ca o aplicatie nu poate fi impachetata ca APK, deci nu poate fi postata pe Android Market.

Practic asta a fost singura problema ridicata pana acum peste tot, problema care nu mi-se pare tocmai mare avand in vedere facilitatile care sunt disponibile in acest mediu.

Am caut aplicatii facute cu PFA, am gasit foarte putine, am gasit de fapt foarte putine si in alte limbaje folosind ASE. De ce nu sunt atat de dornici utilizatorii sa dezolte? Simplu, din mediu de scripting poti accesa foarte multe facilitati de care dispune telefonul, cum ar fi functia de vibratie de exemplu si cam toate felurile de dialoguri. Este totusi un lucru estential care lipseste in totalitate (cel putin la data cand scriu acest blog), nu exista o interfata grafica, cum ar fi orice fel de fereastra care nu este un dialog.

Deci care este scopul sa pui o aplicatie pe Android Market daca nu exista interfata grafica? Nu cred ca este aproape un motiv cu adevarat consistent in acest punct.

Totusi, ce fac utilizatorii in acest mediu atunci? Pai… Cellbots de exemplu. Practic poti face niste jucarii interesante, dar nu te astepta sa poti face aplicatii adevarate (inca). Un alt proiect a fost trimiterea unui NexusOne in spatiu.

Deci proiectul este interesant, dar nu cred ca are scopul de a dezvolta aplicatii traditionale inca.

De curand am schimbat “batranul” HTC Diamond care rula Windows Mobile 6.1 pe un HTC Desire care ruleaza Android 2.1.

De ce Desire? In principal pentru Android. Exista 3 platforme care dupa parerea mea merita atentie: iPhone, Antroid si Windows Mobile. Mai este si Blackberry dar nu sunt mare fan.

Pe scurt, am ales Android pentru multitudinea de moduri in care poti scrie o aplicatie.

Limbajul naitiv pentru Android este Java, dar pentru programatorii web exista alternative cum ar fi: Titanium, Phonegap, PHP for Android sau Adobe AIR.

Mi-am propus sa exporez aceste tehnologii alternative pentru a vedea cam ce si cat de usor se poate dezvolta cu fiecare dintre ele.

Tot ce pot spune in acest moment este ca prima aplicatie mi-a luat aproape 2 zile sa o construiesc, dar rezultatul este interesant.

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!