Cum influenteaza rata de adoptie a noilor produse si/sau versiuni de soft dezvoltarea produselor pentru Web si cele de tip client-server?

Din perspectiva unui web developer, suntem restrictionati de serverele pentru care dezvoltam si browserele clientilor. De multe ori compromisurile merg foarte departe de dragul de a satisface o piata mai larga.

PHP

In prezent versiunea stabila de PHP este 5.3.0, totusi folosirea acestei versiuni in productie ar fi o decizie puierila. Versiunea a aparut de putin timp si probabilitatea de a gasi aceasta versiune pe serverele de hosting este foarte mica.

In mod logic o versiune mai potrivita este 5.2.10. Si totusi, daca versiunea 5 a aparut acum aproape 5 ani, de ce un framework popular precum CakePHP inca nu foloseste avantajele aduse de aceasta versiune? Pentru ca pana de curand o buna parte din serverele de shared hosting care aveau suport pentru PHP, aveau inca versiunea 4.

Cum se traduce asta in productie? Daca nu dezvolti produse interne sau pe servere proprii, sau asupra carora ai control, ar trebui sa fi constient ca produsul tau poate ar trebui sa fie compatibil si cu versiuni de PHP mai vechi, iar noile facilitatie nu trebuiesc folosite.

Trist si ridicol dar adevarat.

PHP 5.3 aduce destul de multe facilitati noi, dar pana aceste facilitati vor putea fi folosite in productie probabil vor mai trece cativa ani. Iar pana acestea vor ajunge si in framework-uri probabil si mai mult (de exemplu namespace-urile sunt utile in framework-uri).

MySQL

Versiunea stabila curenta este 5.1.36.  Versiunea 5.x, lansata in 2005 a adus multe facilitati noi, cateva dintre ele sunt: rutine stocate (functii si proceduri), triggere, views, cursori, information schema etc.

Rutinele stocate probabil reprezinta una dintre cele mai mari schimbari. Acestea sunt cel mai cunoscute probabil de la Oracle PL/SQL, desi MySQL le-a implementat dupa standardul ANSI SQL 2003.

Dar pentru ca MySQL 5.0 a stat mult in beta rata de adoptie este si aici foarte scazuta. Din nou, sunt aproape 4 ani de cand a fost lansata versiunea iar ea inca nu este suficient de raspandita.

Concluzia, pur si simplu nu se recomanda folosirea noilor facilitati daca nu vei putea controla serverul.

Browserele si JavaScript

Problema browserelor ii afecteaza atat pe programatori cat si pe designeri.

Probabil cel mai vechi browser folosit pe o scara inca destul de larga este Internet Explorer 6. Acesta a fost lansat in 2001, adica in urma cu 8 ani si este inca folosit de ~30% dintre utilizatori.

In 2001 JavaScript era considerat inca un limbaj de scripting infantil, care era folosit mai mult pentru efecte vizuale simple.

O data cu “descoperire” AJAX in 2005, JavaScript a prins din nou viata. JavaScript nu mai era doar un limbaj folosit pentru efecte vizuale reduse ci era privit ca o tehnologie de viitor.

Browsere cum ar fi FireFox, Opera, Google Chrome sau Safari au facut progrese mari pentru a imbunatatii viteza de executie pentru JavaScript. Pana si Internet Explorer 8 lucreaza mai bine cu JavaScript, dar este departe de a fi la fel de popular ca versiunea 6. Si ca sa fie completa problema Microsoft are o mare problema cu pastrarea compatibilitatii intre produsele sale.

Motivul pentru aceasta problema de adoptie a noilor versiuni Internet Explorer este de fapt sistemul de operare. Cel mai popular sistem de operare de la Microsoft este Windows XP. Acesta avea preinstalat Internet Explorer 6. Avand in vedere ca Windows Vista a intrat mult mai greu pe piata din pricina bug-urilor initiale, problemelor cu driverele, resurselor consumate si a altor probleme, a insemnat ca Windows XP a ramas inca foarte popular. Evident nu toti care folosesc Windows XP utilizeaza IE 6, multi au facut update sau pur si simplu folosesc alt browser. Dar multi dintre utilizatori folosesc acest browser care vine preinstalat.

Apropo de acest aspect, Windows 7 va fi distribuit in Europa fara IE instalat. Sunt foarte curios cum va influenta asta piata browserelor.

In ultima vreme telefoanele “smart phone” si dispozitivele PDA au devenit tot mai populare. Multa lume le foloseste pentru a naviga pe Internet. Deci dupa problema de compatibilitate cu browserele de pe PC, acum apare si problema de compatibilitate cu browserele de pe mobil. De exemplu, telefonul meu a venit cu doua browsere: Internet Explorer si Opera. Internet Explorer pentru mobil este groaznic, asa ca eu folosesc Opera care face o treaba buna.

Problema este ca multe dispozitive PDA/smart phone cu Windows Mobile au doar Internet Explorer in standard, si  revenim la problema anterioara.

Cand vine vorba de Apple cu renumitul iPhone browserul folosit este Safari (si cred ca nu se poate instala alt browser, dar nu sunt sigur ca mai este inca aceasta problema).

Deci atunci cand realizam o interfata sau o aplicatie JavaScript, ar trebuie sa luam in considerare cateva aspecte cum ar fi:

• dispozitiv (ex: PC, PDA, smart phone etc.)
• sistem de operare (ex: Windows, Linux, Mac, Symbian etc.)
• browser cu versiunea aferenta (Internet Explorer 6,7,8; FireFox, Safari, Opera etc.) HTML 5 este aproape aici, dar cand vine vorba de browsere ma intreb cand se va spune cu adevarat despre HTML 5 ca se poate folosi pe scara larga avand in vedere ca peste jumatate din piata in arest moment este dominata de IE 6 si 7.

Eu zic ca o sa fie cam 5 ani…

Sau mai nou Sun MySQL Certified Developer.

Ma batea gandul de aproape un an, dar in ultimele luni m-am decis sa fac si pasul asta. Si cum eram usor lipsit de motivatie, pe site-ul MySQL este un anunt ca pe data de 31 Iulie examenulul nu se va mai da in centrele PersonVUE. Asta a fost toata motivatia de care aveam nevoie.  M-am inarmat cu cartea si am pornit la treaba.

Cartea (MySQL 5.0 Certification Study Guide) nu mai este in totalitate de actualitate, fiind scrisa pentru versinea 5.0 in anul 2005. Totusi trecand peste miciile probleme cu modificarile dintre versiuni, este scrisa foarte bine, foarte explicita si cu multe exemple. Apropo, ce nu scrie in carte nu se cere.

Cartea are doua parti, prima pentru CMDEV iar a doua pentru CMDBA. Cele doua sectiuni mai fac referire una la alta cand este cazul, dar nu este necesara parcurgerea ambelor sectiuni pentru examen.

Dupa doua saptamani de studiu din prima parte m-am prezentat la primul examen (CMDEV I). Poate este doar parerea mea, si recunosc, am devenit comod avand in vedere ca in cea mai mare parte lucrez cu MySQL folosind phpMyAdmin, dar examenul imi pare destul de dificil. La Zend cand ai o intrebare cu raspunsuri multiple ai si numarul raspunsurilor care trebuiesc furnizate. La MySQL nu exista nici o regula in sensul asta, intradevar pot fi unul sau mai multe raspunsuri corecte.

Un alt element de noutate, cel putin pentru mine, la final am primit si scorul, si chiar daca nu a fost aproape de limita… tot mi se pare un pic dezamagitor.

Dupa primul examen, nu am stat mult sa sarbatoresc ca am inceput sa ma pregatesc de partea a doua.

Unii spun ca examenul nu este bine echilibrat, iar eu cred ca au dreptate. In al doilea examen pentru certificare sunt multe elemente de care eu unul doar am auzit, sau le-am folosit cu Oracle. Motivul pentru care nu am apucat sa le folosesc pana acum este simplu: multe servere inca NU au MySQL 5.x! O alta problema este aceea ca phpMyAdmin nu avea nici un fel de suport pentru rutine stocate, triggere etc. Dar din fericire din fericire in MySQL 5.x exista Information Schema, dar desprea asta poate in alt post.

Al doilea examen mie unul mi s-a parut ceva mai intortochiat. Daca primul l-am rezolvat intr-o ora, pe al doilea l-am rezolvat in aproape o ora jumatate (cat timpul alocat). Exemplele sunt destul de mari si trebuie interpretate cu atentie.

Dar intr-un final am reusit!

Din pacate treaba nu merge la fel de usor ca la Zend, acolo pana am ajuns acasa de la examen am primit si siglele (pe e-mail), termenii si conditiile de folosirea a siglelor si am putut sa-mi public profilul pe site.

La MySQL trebuie sa primesc o hartie prin posta (ne electronica) care ar trebui sa ajunga in 4-6 saptamani. Pana atunci nu-mi ramane decat sa astept…

In continuare voi prezenta un mic tutorial despre stocarea fisierelor in baza de date.

Cand avem nevoie de stocarea fisierelor in baza de date? Un scenariu bun este atunci cand fisierele sunt confidentiale.

Dezavantajul principal este viteza de acces, cat timp mai este si o baza de date la mijloc asta va intarzia procesul de regasire/afisare.

Structura bazei de date:

1CREATE TABLE IF NOT EXISTS fisiere (
2  ID int(10) unsigned NOT NULL AUTO_INCREMENT,
3  nume varchar(255) NOT NULL,
4  tip varchar(255) NOT NULL,
5  marime int(11) NOT NULL,
6  fisiere longblob NOT NULL,
7  timp int(11) DEFAULT NULL,
8  PRIMARY KEY (`ID`)
9) ENGINE=MyISAM

Trebuie sa stocam tipul, marimea si continutul fisierului propriuzis. Numele este retinut mai mult pt extensie.

Conectarea la baza de date:

1<?php
2// db.php
3mysql_connect('localhost', 'user', 'parola');
4mysql_select_db('fisiere');
5
6// am omis intentionat tag-ul de inchis pt PHP
7// ca sa am certitudinea ca nu se trimit headere

Fisierul de upload si listare:

In acest fisier se afla adaugare, stergerea si listarea fisierelor din baza de date

  1<?php
  2// legatura la baza de date
  3include('db.php');
  4
  5// mesaj de eroare
  6$errmsg = NULL;
  7
  8// stergerea fisierului din BD
  9if(isset($_GET['del']))
 10{
 11    $qr="DELETE FROM fisiere WHERE ID='".mysql_escape_string($_GET['del'])."'";
 12    if(!mysql_query($qr)) {
 13       $errmsg = 'Fisierul nu a putut fi sters!<br>';
 14    }
 15}
 16
 17// verificam daca a fost trimis un fisier si are diminesiunea mai mare de 0
 18if($_FILES['fisier']['size'] > 0) {
 19
 20   // se citeste continutul fisierului
 21   $content = file_get_contents($_FILES['fisier']['tmp_name']);
 22
 23   // se codeaza cu base64_encode pt a nu aparea probleme la caractere speciale
 24   //si se sparge in bucati
 25   $content = chunk_split(base64_encode($content));
 26
 27   // se introduc datele in baza de date
 28   $qr="INSERT INTO fisiere SET
 29      nume   ='".mysql_escape_string($_FILES['fisier']['name'])."',
 30      tip    ='".mysql_escape_string($_FILES['fisier']['type'])."',
 31      marime ='".mysql_escape_string($_FILES['fisier']['size'])."',
 32      fisiere='".$content."',
 33      timp   ='".time()."'";
 34
 35   // se verifica daca datele au fost inserate cu succes
 36   if(mysql_query($qr)) {
 37      // daca datele au fost stocare cu succes se face refres la pagina
 38      // pentru a evita cazul in care utilizatorul apasa "refresh"
 39      header("Location: ".$PHP_SELF."?ok=1");
 40      exit();
 41   } else {
 42      $errmsg = 'Eroare la upload<br>';
 43   }
 44
 45}
 46?>
 47<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 48"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 49<html xmlns="http://www.w3.org/1999/xhtml">
 50<head>
 51<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
 52<title>Fisiere</title>
 53</head>
 54
 55<body>
 56<?php
 57if($_GET['ok']==1) echo "fisierul a fost incarcat!";
 58// afisaza mesajul de eroare daca acesta exista
 59if($errmsg) echo $errmsg;
 60?>
 61
 62<?php
 63// selecteaza fisierele din BD
 64$qr="SELECT * FROM fisiere ORDER BY timp";
 65$rez=mysql_query($qr);
 66if(mysql_num_rows($rez)>0) {
 67?>
 68<table border="1">
 69   <tr>
 70      <td>ID</td>
 71      <td>Nume</td>
 72      <td>Ora</td>
 73      <td>Descarca</td>
 74      <td>sterge</td>
 75   </tr>
 76   <?php
 77   while($row=mysql_fetch_array($rez)) {
 78   ?>
 79   <tr>
 80      <td><?php echo $row["ID"]; ?></td>
 81      <td><?php echo $row["nume"]; ?></td>
 82      <td><?php echo date("d-m-Y",$row["timp"]); ?></td>
 83      <td><a href="descarca.php?ID=<?php echo $row["ID"]; ?>">descarca fisier</a></td>
 84      <td>
 85        <a href="<?php echo $_SERVER['PHP_SELF']; ?>?del=<?php echo $row["ID"] ?>"
 86            onclick="return confirm('doriti sa stergeti acest fisier?');">
 87          sterge
 88        </a>
 89      </td>
 90    </tr>
 91    <?php } ?>
 92</table>
 93<?php
 94} else {
 95    echo "nu exista fisiere in baza de date!";
 96}
 97?>
 98<br />
 99<br />
100<form method="post" enctype="multipart/form-data"
101   action="<?php echo $_SERVER['PHP_SELF']; ?>">
102<input type="file" name="fisier" />
103<input type="submit" value="Incarca" />
104</form>
105</body>
106</html>

Descarcarea fisierului:

 1<?php
 2include('db.php');
 3
 4// selectarea fisierului din BD
 5$qr="SELECT * FROM fisiere WHERE ID='".mysql_escape_string($_GET['ID'])."'";
 6$rez=mysql_query($qr);
 7$row=mysql_fetch_array($rez);
 8
 9$size = $row['marime'];
10$type = $row['tip'];
11$name = $row['nume'];
12$fisiere = $row['fisiere'];
13
14// dezactivam compresia pt ca nu aparea erori la afisare
15if(ini_get('zlib.output_compression'))
16ini_set('zlib.output_compression', 'Off');
17
18// fisierul trebuie descarcat de pe server nu din cache
19header("Pragma: public");
20header("Expires: 0");
21header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
22header("Cache-Control: private",false); 
23
24// dimensiunea fisierului
25header("Content-length: ".$size);
26
27// tipul fisierului
28header("Content-Type: ".$type); 
29
30// optional daca dorim sa forteze download-ul
31header("Content-Type: application/force-download");
32
33// numele fisierului cu care va fi salvat pe disk
34header("Content-Disposition: attachment; filename=\"".$name."\";"); 
35
36// transfer binar pt a evita caracterele speciale
37header("Content-Transfer-Encoding: binary");
38
39// decodam continutul fisierului si il afisam
40echo base64_decode($fisiere);
41
42?>

Dupa cum se poate vedea serverul are destul de multe lucruri de facut pentru a afisa un simplu fisier, de asta nu este bine sa fie stocate pe disk toate fisierele, ar fi o risipa de resurse. Pe de alta parte,  fisierele private (cum ar fi cartile digitale sau melodiile) sunt clienti ideali pentru aceasta forma de stocare.

Da, nu e o gluma, chiar exista acest parametru, iar el este sinonim cu –safe-updates.

Cum ii spui clientului mysql ca esti dummy?

1shell>mysql --i-am-a-dummy

Iar pentru sinceritate, clientul mysql nu o sa te lase sa:

• stergi sau sa modifici (DELETE, UPDATE) daca nu ai conditii puse
• afisezi mai mult de 1000 de randuri de inregistrari
• selecturi multiple care necesita procesarea a mai mult de 1 milion de randuri

Uneori este mai sigur sa recunosti ca poti fi putin dummy decat sa o dovedesti…

Da, MySQL va intra sub umbrela Oracle odata cu achizitionarea sa de catre aceasta corporatie.

Achizitionarea nu este directa ci prin intermediul Sun (JAVA) care la randul lor au cumparat MySQL cu ceva timp in urma.

Incepand de pe 20 aprilie 2009 e oficial, Oracle va achizitiona Sun si deci MySQL, asa cum a fost anuntat pe site-ul Sun.

Sunt foarte curios care o sa fie rezultatul, in special ca cele doua SGBD-uri sunt populare in sectoare de piata diferite. Probabil MySQL ar putea profita de experienta Oracle, oricum probabil Oracle nu era interesat atat de interesat de tranzactia cu MySQL cat de tranzactia cu Sun.

Daca ne gandim practic Oracle mananca “cu pofta” toate resursele care le are disponibile, pe cand MySQL este cunoscut pentru consumul redus de resurse. O sa fie foarte ciudat ca aceste opusuri sa faca parte dintr-o singura corporatie.

Oricum, rezultatul este ca Oracle va controla majoritatea pietei de SGBD-uri prin cele doua produse de acest gen care le va dezvolta.