A mai trecut un an iar PHP 6 nu va veni.

De 2 ani astept PHP 6, cred ca a devenit mai mult un blog traditional cu care sa inchei anul.

PHP 6 nu va mai veni pentru ca trunk-ul a fost abandonat si refacut dintr-unul de 5.3.

In alta ordine de idei PHP 5.3 castiga popularitate. Frameworkuri precum Zend Framework si Symfony pregatesc pentru anul 2011 cate o versiune in 2.0 care va avea nevoie de PHP 5.3+. Chiar si CodeIgniter, un framework traditional PHP 4, va necesita o data cu versiunea 2.0 minim PHP 5.1.6.

Mai mult, certificarea oficiala Zend pentru PHP este mai nou ZCE 5.3, iar aceasta devine destul de populara, chiar daca a fost lansata doar cu cateva luni in urma.

Dar un nou an se incheie si este timpul sa bifam realizariile din rezolutia de anul trecut si sa o scriem pe urmatoarea.

Anul trecut am terminat masterul, cu asta am incheiat mult prea multi ani de scoala decat imi doresc sa calculez. De fapt aceasta este prima iarna cand nu sunt intr-o forma de invatamant, poate de asta mi se pare ca am ceva mai mult timp liber :).

Am schimbat locul de munca, iar cu asta am fost fortat sa folosesc cateva lucruri care erau pe lista de TODO de ceva vreme:

• Linux
• Symfony Framework Linux era un subiect in jurul caruia ma invart inevitabi de destul de multi ani, fara sa-l aprofundez de loc. A fost mereu pe lista mea de “todo”, dar niciodata nu am avut atata rabdare ca sa intru in detalii cu el sau nu am avut continuitate atunci cand am facut-o. Cand am ajuns la noul loc de munca m-am trezit in fata unui calculator cu Ubuntu si un pic de panica m-a cuprins.

Dupa cateva luni am facut un nou pas, pentru prima data in viata mea am fost la un curs profesional. Cursul era organizat de Info Academy. Platit din buzunarul meu si usor suprapus cu programul de lucru. Dar am ajuns la concluzia ca trebuie sa-l fac. Probabil nu suna ca mare lucru, dar pentru mine care sunt in general autodidact a fost destul de ciudat. Acum ca s-a terminat pot spune ca a fost o foarte buna investitie si il recomand.

Undeva pe parcursul cursului mi-am dat seama ca e timpul sa mai fac cate un boot in linux si acasa. Urmatorul pas a fost reconfigurarea boot managerului sa booteze direct in linux. Acum, dupa ce folosesc aproape exclusiv linux, am ajuns la concluzia ca este suficient de user friendly incat sa fie o alternativa reala pentru Windows.

Symfony framework este alt subiect prafuit pe lista de “todo”. Desi am mai abordat CodeIgniter si Zend Framework, de Symfony nici macar nu m-am apropiat pana anul trecut. Se simte diferenta fundamentala de concept dintre ZF si Symfony, iar eu am simtit-o pe pielea mea. Acesta a fost alt motiv de panica pentru mine la noul loc de munca, pana la urma “all frameworks suck”.

Nu este un framework usor de invatat din pricina conceptelor, dar acum sunt de parere ca merita. Ce-mi place cel mai mult la acest framework este generarea de CRUD, care se face foarte usor si totusi este foarte puternica si flexibila. De asemenea flosirea fisierelor YML, care se pare ca au fost preluate de la Ruby on Rails, este o alternativa mult mai buna la fisierele ini care sunt suportate nativ in PHP.

Ca sa concluzionez, 2010 a fost un an bun, cu multe realizari, chiar daca nu am bifat totul pe rezolutia de anul trecut, cred ca am bifat destule.

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

Se pare ca Zend, a lansat o noua varianta a ghidului de certificare pentru ZCE 5.3 (zend certified engineer). Pentru a downloada cel mai simplu este sa mergeti la pagina unde sunt detaliile certificarii, adica aici, iar in dreapta la “DOCUMENTATION” este un link catre aceasta.Documentul PDF spune ca acesta a fost modificat ultima data pe 16 Dec. Nu pun un link catre documentatie pentru ca acesta se poate schimba atunci cand va aparea o noua versiune.

Nu am apucat sa-l “rasfoiesc” dar sunt sigur ca este un pas inainte fata de versiunea anterioara beta.

Oricum acesta este un ghid care nu are scopul sa inlocuiasca manualul ci doar sa indice subiectele de interes.

Pentru mine aceasta certificare face parte din rezolutia pe 2011, sper ca in cel mai rau caz pana la finalul primaverii sa mai adaug un logo la acest blog. 🙂

Mult succes pentru cei care vor sa se pregateasca pentru ZCE 5.3!

De cand a fost lansat PHP 5.3 anul trecut m-am intrebat daca Zend vor introduce si o certificare ZCE aferenta acestei versiuni.

Se pare ca o data cu abandonul versiunii PHP 6 cu ceva timp in urma directia a fost catre o certificare pentru PHP 5.3.

Perioada cred ca nu a fost intamplatoare avand in vedere ca se apropie Zend Con, cea mai mare conferinta PHP.

Ce este nou?

Diferentele de la PHP 5 la PHP 5.3 se gasesc in manual aici.

Cateva mai importante:

• Namespaces
• Late static binding
• Lambda Functions and Closures

Materiale

Programa pentru examen se gaseste pe site-ul Zend.

Dupa ce la certificarea pentru Zend Framework am vazut ca exista un guide complet gratuit pentru membrii inregistrati, ma intrebam de ce nu exista asa ceva si pentru aceasta certificare. Se pare ca acum exista: Zend-PHP-5.3-Study-Guide-v1-3.pdf, in versiune beta! Si este gratuit!

Evident cel mai important material ramane manualul PHP, pentru ca ghidul se foloseste impreuna cu acesta.

Se pare ca nu mai exista mock tests, cum nu au existat nici pentru certificarea de Zend Framework.

Pret

Pretul se pare ca a mai crescut, nu mai este 160$ ci 190$! Pretul oricum ramane unul foarte mic avand in vedere ca un examen la Sun era 200$, iar acum 300$ la Oracle.

Persoanele care au deja o certificare PHP au un discaunt de 20% pana la finalul anului, deci daca esti deja certificat vei plati 152$.

Mult succes!

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.

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.