Se pare ca Oracle a primit aprobarea de la EU pentru a cumpara Sun conform Yahoo! News.

Acum aproximativ un an jumatate ma gandeam sa sustin examenul pentru MySQL Certified Developer. Acum dupa ce am devenit Sun MySQL Certified Developer se pare va voi deveni Oracle MySQL Certified Developer. Si toate acestea fara nici un ban in plus! 🙂

Partea buna este ca vom ajunge sa lucram cu Oracle chiar si fara voia noastra (ok, nu e chiar Oracle, dar e un produs al lor).

A mai trecut un an iar PHP 6 tot nu e aici…

Dar asta nu este tocmai o noutate, este al 4-lea an in care aceasta versiune mult asteptata nu se lanseaza, nu degeaba este numita cea mai asteptata versiune.

Totusi a fost un an bun pentru comunitate, chiar daca Unicode nativ nu exista inca intr-o versiune stabila, acum avem cam toate celelalte noutati asteptate in PHP 5.3, care probabil va mai avea nevoie de cativa ani ca sa devina folosit pe scara larga.

Chiar daca toata lumea astepta in acest an ca Oracle sa intre in forta pe piata de baze de date medii si mici prin achizitia Sun, marind portofoliul deja detinut pe piata enterprise. Se pare ca nu a fost asa, CE inca analizeaza propunerea.

Oricum MySQL nu mai este ce era acum 5-6 ani, cand nimeni nu indraznea sa-l foloseasca pentru produse enterprise, acum MySQL este un produs gata pentru a fi folosit atat pentru proiecte mici cat si pentru produse care necesita muta scalabilitate.

Dar revenind la anul care tocmai s-a incheia, a fost un an plin, chiar si in timp de criza.

De ce se vorbeste atat de “bad code” sau “bad practices”? Pentru ca sunt importante!!!

In ultima vreme am avut parte de o experienta care eu o consider neplacuta, cod necomentat, design slab, oop prost implementat, baze de date neoptimizate si prost proiectate.

Comentarile

Este un mare mister pentru mine cum se poate ca in fiecare carte si tutorial disponibil (nu doar de PHP) scrie ca acestea nu sunt optionale ci NECESARE si totusi acestea de cele mai multe ori lipsesc cu desavarsire. Zend Studio are un auto-complete forte simplu si eficient, nu trebuie sa scrieti decat “/**” si sa apasati enter, apoi textul care apare trebuie completat. Netbeans la fel, acelasi sistem, la fel de simplu.

Cu toate astea in ultima perioada m-am lovit de mii de linii de cod aproape fara nici un comentariu, rezultatul? Ore intregi pierdute incercad sa urmaresc logica!

De ce se intampla asta? Primul motiv: este plictisitor, un programator vrea sa scrie cod nu povesti, de multe ori pare un timp irosit. Al doilea motiv: totul pare foarte logic in momentul in care este scris, daca este atat de logic si cursiv de ce sa mai pierzi timpul cu povesti? Pentru ca timpul trece, proiectele se schimba, in timp inevitabil, toata logica este data uitarii. Sau un alt motiv, pentru ca vin persoane noi, in firme programatorii vin si pleaca, iar cel care vine nu mai poate urmarii logica cu aceeasi usurinta, de fapt de multe ori este aproape imposibil de urmarit. Am patit chiar si ca autorul codului sa nu o mai poata urmarii dupa o anumita perioada de timp, uneori autorul eram chiar eu.

Dupa parerea mea asta ar trebui sa fie o regula de baza pentru orice firma care se respecta, nici o clasa/metoda/proprietate nu trebuie sa fie necomentata. Timpul priedut acum pentru comentarii este timp castigat mai tarziu cand se face debugging, oprimizare etc.

Design slab

Am vazut la un “mini interviu” on-line o intrebare care suna: “vedeti importanta arhitecturii inainte de a scrie cod?”, imi cer scuze daca nu mai suna la fel ca in anunt. Prima data cand am vazut intrebarea am avut un moment de deja-vu, de multe ori m-am lovit de problema de a scrie cod ca mai apoi sa realizez ca am o abordare gresita.

De multe ori problema asta se rezolva (cel putin aparent) in timp cu experienta. Practic, daca iei un incepator si il pui sa scrie cod, cel mai probabil va avea cateva abordari slabe pana sa aiba una reusita, iar asta nu este de loc anormal, de asta cred ca un incepator ar trebui ghidat inainte de a incepe sa scrie cod, iar codul care urmeaza sa-l scrie sa aiba o logica clara sugerata de un “mentor”.

In cealalta extrema exista “software architects” care folosind UML schematizeaza logica si structurile in diagrame. Cand exista diagrame atunci este mult mai ushor de urmarit intregul proces si intreaga structura a aplicatiei. Un arhitect priceput va putea sa vada problemele posibile care pot aparea inainte de a incepe sa scrie cod, iar cand se incepe implementarea fiecare stie ce are de facut.

OOP-ul se loveste probabil cel mai mult de design-ul slab, in ultima vreme am vazut o multime de clase care nu aveau nici un fel de organizare, erau doar simple invelitori (wrappers) pentru interogari SQL. Asta nu inseamna OOP!

OOP presupune abstractizarea elementelor in clase si obiecte. De exemplu tastatura, aceasta este o clasa care are niste taste (o clasa copil) cu diverse proprietati(litere, cod de tasta, pozitie), niste leduri (alta clasa copil) etc. Repezentarea acestora in baza de date nu are neaparat o legatura atat de stransa cu obiectele cum pare la prima vedere.

Daca folosesti OOP iar ce citesti acum suna bizar, incearca sa faci pe o foaie de hartie o diagram a aplicatiei tale cu obiectele si a legaturilor dintre ele. Daca nu poti, inseamna ca abordarea ta fata de OOP este gresita(sau nu sti sa faci o diagrama 🙂 )!

Toti facem greseli cand vine vorba de OOP, dar asta nu este o scuza sa nu le corectam si sa nu incercam sa facem arhitectura inainte de a scrie cod.

Un design prost de aplicatie poate avea repercusiuni foarte importante financiare. Timpul inseamna bani, iar daca o aplicatie este slaba, nu este bine structurata, timpul pentru debug-ing este mare, schimbarile necesita timp indelungat, redundanta codului este mare, etc., atunci poti fi sigur ca pierzi bani.

O unealta pe care o folosesc uneori este Violet UML Editor, nu este un editor adevarat de UML cum este Rational Rose de exemplu, ci mai degraba o jucarie open source. Cu Violet se pot realiza doar diagrame vizuale, dar ele pot fi utile pentru a structura o aplicatie.

Baze de date

Oare de ce se feresc multi programatori PHP sa invete cu adevarat MySQL? Suna bizar? Este foarte adevarat totusi. Modificarea codului PHP este de multe ori o operatie nu foarte dificil de realizat (ma refer la rescrierea practica a codului), dar un design prost al bazelor de date este de cele mai multe ori mult mai dificil de modificat pentru ca exista riscul sa piezi informatii.

Acum cateva saptamani am facut o diagrama a unei baze de date folosind MySQL Dump si MySQL Workbench. Nu mica mi-a fost surprinderea sa vad tabele care nu aveau chei de legatura cu alte tabele din care proveneau date (nu ma refer la tabele de setari care din punct de vedere logic nu se leaga), apoi sursa datelor era complet pierduta.

O alta problema clasica de incepatori este cand ai o tabela de legatura intre doua tabele cum ar fi categorii si produse, iar cheia este pusa pe un camp cum ar fi “id” care nu are nici o relevanta. O cheie primara se poate pune pe mai multe campuri, de exemplu cheia ar trebui sa fie “id_categorie, id_produs” nu “id”, iar in felul asta se asigura si unicitatea unui produs intr-o categorie folosind restrictia de primary key.

Un alt lucru care nu il inteleg este de ce lumea evita indecsii. Intr-un blog anterior vorbeam pe scurt despre ei, complet insuficient dar totusi sunt foarte importanti. Un index poate micsora semnificativ timpul de cautare intr-o tabela, de la zeci de secunde uneori la sutimi de secunda. O aplicatie prost optimizata din punctul asta de vedere poate avea un timp de raspuns semnificativ mai mare decat este normal.

Framework-uri

Ca sa citez o fraza deja clasica in comunitatea PHP:

All frameworks suck.

iar Laura Thomson are niste motive destul de bune cu care sa sustina asta.

Cineva spunea saptamana trecuta ca motivul pentru codul prost este chiar PHP si modul lui permisiv. Sa fim seriosi, daca luam un limbaj ca C++ are mult mai multe probleme care pot aparea. Imi aduc aminte in facultate cat de slab era codul care il scriam, iar problema nu era limbajul ci nivelul meu de pregatire de atunci. PHP permite abordari de la OPP pana la spaghetti code (OOP, proceduri, closures, label-uri). Faptul ca multi programatori aleg abordarea proasta nu este o problema de limbaj, la fel exita o problema de abordare si in limbaje cum ar fi C++, sau mai bine zis in orice limbaj exista.

De ce sunt mai putine probleme de design in Ruby on Rails de exemplu? Pentru ca este un framework! Eu nu am auzit pe nimeni pana acum sa faca programare web doar in Ruby (exista programatori Ruby, in special pentru aplicatii desktop, dar asta este alta discutie), evident ca apar mai putine probleme cand folosesti un framework. La fel se pot reduce si probleme din PHP folosind un framework consacrat.

Exista zeci sau chiar sute de framework-uri open source pentru PHP. Din acesta exista cateva cu adevarat consacrate, cum ar fi Zend Framework, CakePHP, Symfony, Solar, CodeIgniter etc. Un avantaj major atunci cand se foloseste un framework este ca poti gasi mult mai usor persoane specializate. Un alt avantaj major este ca ai parte de un cod testat si documentat, lucru care este deosebit de dificil de realizat intr-o firma de dimensiuni reduse.

Sau chiar daca se foloseste un framework intern cred ca este utila abordarea unei structuri similare cu un framework consacrat pentru a reduce curba de invatare pentru programatorii noi.

Folosind un framework consacrat de multe ori se reduce timpuri de lucru si timpul de dezvoltare de noi faciltati pentru ca de multe ori acesta sunt incluse, deci pot aparea avantaje economice indirecte (bani), o stucturate mai buna si nu in ultimul rand programatori mai fericiti (cea ce nu sunt eu acum).

Concluzionand:

• stabileste niste reguli interioare pentru cod, nu uita sa pui comentarile pe lista,
• asigura-te ca designul aplicatiei este facut conform unui plan care sa permita scalabilitate si o redundanta minima a codului,
• asigura-te ca baza de date este bine structuata si optimizata,
• ia in calcul folosirea unui framework consacrat fata de un framework intern sau de unul nou conceput.

Folosind aceste reguli simple se vor salva resurse, timp, bani iar programatorii vor fi probabil mai multumiti de rezultate.

O data cu globalizarea, batranul cod ASCII nu mai este potrivit. Ganditi-va ca intr-o buna zi trebuie sa dezvoltati un proiect in germana, rusa sau chiar japoneza, puteti adapta characterset-ul pentru fiecare din aceste limbi sau puteti pur si simplu sa-l dezvoltati folosind Unicode.

Pentru a folosi Unicode cu MySQL se poate folosi UTF-8.

Trebuie sa retineti ca caracterele UTF-8 au o marime variabila si sunt compatibile ASCII. In ASCII 1 caracter = 1B, in UTF-8 1 caracter poate avea intre 1 si 4 B.

Charset si collation UTF-8 pe server

In MySQL tipul caracterelor este dictat de charset.

Pentru a vedea daca este instalat pe server:

1SHOW CHARSET LIKE 'utf8';

sau cu information_schema

1SELECT * FROM `CHARACTER_SETS` WHERE CHARACTER_SET_NAME = 'utf8';

Daca a fost gasit charset-ul atunci putem continua.

Un alt element care apare la charset este collation, acesta se foloseste in comparatii intre string-uri la ordonare.

Pentru a vedea ce “collation” sunt disponibile pe server:

1SHOW COLLATION WHERE CHARSET = 'utf8';

sau cu information_schema

1SELECT * FROM `COLLATIONS` WHERE CHARACTER_SET_NAME = 'utf8';

Collation este in functie de limba in principiu, pentru a putea compara stringuri cu sau fara diacritice de exemplu, sau se mai poate folosi cel “bin” care va face ordonarea in mod binar, adica “A” este mai mare decat “a” de exemplu.

Daca nu se va specifica collation, atunci se va folosi cel marcat ca default.

UTF-8 si baza de date

La crearea unei baze de date se poate specifica charset-ul default care se va folosi la toate tabelele noi la care nu este specificat charset-ul.

De exemplu:

1CREATE DATABASE db_name CHARACTER SET utf8 COLLATE utf8_romanian_ci;

Sau pentru a modifica characterset-ul default la o baza de data deja existenta:

1ALTER DATABASE db_name CHARACTER SET utf8 COLLATE utf8_romanian_ci;

UTF-8, tabelele si coloanele

Pentru a modifica tabelele deja existente se foloseste ALTER TABLE.

Un tabel poate avea un charset si un collation default iar fiecare coloana poate avea propriul charset si collation.

Pentru a vedea mai multe detalii despre un tabel se pot folosi:

1SHOW CREATE TABLE tab;

Pentru a seta un charset pe un table existent:

1ALTER TABLE tab CHARSET = utf8 COLLATE = utf8_romanian_ci;

Pentru a modifica charset-ul pe o coloana de timpul VARCHAR(200) se foloseste:

1ALTER TABLE tab MODIFY c1 VARCHAR(200) CHARSET utf8 COLLATE utf8_romanian_ci;

Marimea stringurilor

O “problema” care poate aparea este legata de marimea unui caracter, acesta poate avea marimea intre 1 si 4B. De asta pentru masurarea unui camp care are un string (cum ar fi un varchar) trebuie folosita CHAR_LENGTH(str) si nu LENGTH().

Un mic exemplu:

1SET @var = 'aşadar';
2SELECT CHAR_LENGTH(@var) AS 'Char', LENGTH(@var) AS 'Length';
3
4// Rezulta: Char = 6 si Length = 7 pentru ca ş ocupa 2B

Dupa ce am sustinut examenul MySQL Certified Developer acum cateva saptamani, dupa cum povesteam intr-un blog anterior, a venit si momentul mult asteptat. Este putin indoita ca a fost fortata in cutia postala, dar diploma a venit! Surprinzator a durat doar doua saptamani, fata de cea de la Zend care a durat  aproape 8.

Numele mi-a fost publicat la cateva zile pe site, dar contul nu am putut sa-l accesez decat dupa ce am primit diploma. Ce este mai ciudat este ca inauntru nu scria parola pentru cont, ci instructiunile pentru a o primi.

In afara de diploma, in plic mai exista instructiuni de folosire pentru logo si contului, si pe langa asta un card cu nume si certificare, care nu inteleg la ce o sa-mi foloseasca.

Iar alta ciudatenie este ca, diploma este semnata de Micheal “Monty” Widenius si Marten Mickos care nu mai lucreaza la Sun MySQL. Evident nu stiu cat de adevarate sunt semnaturile, dar macar cea a lui Ulf Sandberg (VP Service MySQL AB) este reala.

Dar diploma arata foarte bine, si face o pereche buna cu cea Zend. Acum sper sa-mi si foloseasca.