Undeva in ghidul de certificare exista un capitol dedicat pentru “streams”.

O mica parte din asta reprezinta stream-ul de input, output si cel de eroare din PHP. In C/C++ este faimoasa biblioteca stdio.h, insa putina lume stie ca se poate realiza input de la tastatura si in PHP.

Pe scurt, acest lucru se realizeaza cu PHP://STDIN, PHP://STDOUT si PHP://STDERR.

Ca sa nu fie confuz termenul de stream, subiect care ii panicheaza pe multi care studiaza pentru ZCE, el reprezinta un flux de informatie, la fel cum citesti un fisier inter sau extern folosind fopen.

Dar cum un programator intelege cel mai bine din cod, sa trecem la lucruri mai concrete.

Input

Pentru input se foloseste PHP://STDIN.

Un script care citeste de la tastatura este urmatorul:

 1#!/usr/bin/php
 2<?php
 3// initializare stream de input
 4$input = fopen('php://stdin', 'r');
 5
 6// mesaj de intampinare
 7echo 'Scrie "exit" si apoi enter pentru a termina' . PHP_EOL;
 8
 9// citire de la stream
10while($line = fgets($input, 1024)) {
11 // conditie de iesire cu tot cu terminator de rand
12 if($line == 'exit' . PHP_EOL) {
13    echo 'bye bye' . PHP_EOL;
14    break;
15 }
16 // afisare input citit de la tastatura
17 echo 'Ai scris: ' . $line . PHP_EOL;
18}
19
20// inchidere stream
21fclose($input);

Prima linie din cod este speciala pentru Linux/Unix iar utilizatorii de Windows o pot scoate.
Codul de mai sus trebuie pus intr-un fisier, de exemplu testStream.php

Fisierul trebuie sa aiba drept de executie care se poate da cu:

1chmod +x testStream.php

Apoi fisierul poate fi rulat in Linux direct cu:

1$./testStream.php

In Windows trebuie sa fie data calea catre PHP daca nu este inclusa in include path:

1>c:\php\php.exe testStream.php

Este de remarcat ca inputul este cu tot cu “\n” sau “\r\n” de asta la “exit” se testreaza cu tot cu terminator de linie (PHP_EOL). Folosesc PHP_EOL ca sa poata functiona atat pe Linux/Unix cat si pe Windows.

Output

Pentru output se foloseste PHP://STDOUT.

Dar fata de Input, output-ul este mult mai putin relevant. Practic output-ul este cel standard, care se poate realiza si cu echo sau print.

Dar in scop educational sa modificam fisierul de mai sus sa foloseasca si PHP://STDOUT.

 1#!/usr/bin/php
 2<?php
 3// initializare stream de input
 4$input = fopen('php://stdin', 'r');
 5
 6// initializare stream de output
 7$output = fopen('php://stdout', 'w');
 8
 9// mesaj de intampinare
10fwrite($output, 'Scrie "exit" si apoi enter pentru a termina' . PHP_EOL);
11
12// citire de la stream
13while($line = fgets($input, 1024)) {
14 // conditie de iesire cu tot cu terminator de rand
15 if($line == 'exit' . PHP_EOL) {
16    fwrite($output, 'bye bye' . PHP_EOL);
17    break;
18 }
19 // afisare input citit de la tastatura
20 fwrite($output, 'Ai scris: ' . $line . PHP_EOL);
21}
22
23// inchidere stream input
24fclose($input);
25
26// inchidere stream output
27fclose($output);

Practic nu este nici o schimbare in script, doar ca output-ul a fost afisat folosind PHP://STDOUT intr-un mod mai explicit.

Eroare

Un subiect mai interesant decat output-ul este stream-ul de eroare.

Practic el este relevant mai mult in mediul linux, probabil este si in windows dar eu nu stiu cum se poate capta. Daca citesti acest blog si sti cum se poate face asta lasa te rog un comentariu.

Si din nou scriptul va fi modificat ca mesajele de eroare sa foloseasca stream-ul corespunzator. Voi face ca de fiecare data cand sunt introduse mai mult de 5 caractere sa fie afisat un mesaj de eroare (imi pare rau dar nu am mai multa inspiratie acum):

 1#!/usr/bin/php
 2<?php
 3// initializare stream de input
 4$input = fopen('php://stdin', 'r');
 5
 6// initializare stream de output
 7$output = fopen('php://stdout', 'w');
 8
 9// initializare stream de eroare
10$err = fopen('php://stderr', 'w');
11
12// mesaj de intampinare
13fwrite($output, 'Scrie "exit" si apoi enter pentru a termina' . PHP_EOL);
14
15// citire de la stream
16while($line = fgets($input, 1024)) {
17 // conditie de iesire cu tot cu terminator de rand
18 if($line == 'exit' . PHP_EOL) {
19    fwrite($output, 'bye bye' . PHP_EOL);
20    break;
21 }
22
23 if(strlen($line) > 5) {
24    fwrite($err, 'ATENTIE! Inputul mai mare de 5 caractere: ' . $line);
25    continue;
26 }
27
28 // afisare input citit de la tastatura
29 fwrite($output, 'Ai scris: ' . $line . PHP_EOL);
30}
31
32// inchidere stream input
33fclose($input);
34
35// inchidere stream output
36fclose($output);
37
38// inchidere stream eroare
39fclose($err);

Implicit in Linux mesajele de eroare sunt afisate pe ecran, dar sunt scenarii cand este mai relevanta trecerea erorilor intr-un log de exemplu.

Pentru ca mesajele de eroare sa fie redirectionate catre fisier log se foloseste 2>> dupa cum urmeaza:

1$./testStream 2>>testStream.log

Input din PIPE (|)

Sa luam urmatorul scenariu: Exista rezultatul unei procesari anterioare, care contine o serie de adrese email valide dar si unele invalide. Ar trebuie facute doua fisiere: valid.txt cu adrese valide si unul invalid.txt cu adrese invalide. Adresele valide si invalide vor fi trimise catre script cu pipe.

Lista de adrese va fi simulata prin fisierul email.txt:

1valid_addres@yahoo.com
2another_valid@yahoo.co.uk
3invalid@y.c
4good@gmail.com
5invalid addres@hotmail.com
6foo

Scriptul de procesare va fi emailTest.php:

 1#!/usr/bin/php
 2<?php
 3
 4// initializare stream de input
 5$input = fopen('php://stdin', 'r');
 6
 7// initializare stream de eroare
 8$err = fopen('php://stderr', 'w');
 9
10// faza de cazurile anterioare, aici se verifica sfarsitul fisierului
11// pentru ca inputul nu se citeste de la tastatura
12while(!feof($input)) {
13 // fac trim la linie pentru a scapa de eventuali terminatoari de linie
14 $line = trim(fgets($input, 1024));
15
16 // testez adresa de email
17 if(filter_var($line, FILTER_VALIDATE_EMAIL)) {
18    // output-ul se face direct pentru ca acesta este echivalent cu
19    // stream de php://stdout
20    echo $line . PHP_EOL;
21 } else {
22    // adresele invalide sunt scrise directionate catre stream-ul de
23    // php://stderr pentru a fi interceptate ulterior
24    fputs($err, $line . PHP_EOL);
25 }
26}
27
28// inchidere stream input
29fclose($input);
30
31// inchidere stream eroare
32fclose($err);

Pentru a testa voi simula output-ul de adrese de email print comanda cat:

1cat email.txt |./emailTest.php >valid.txt 2>invalid.txt

Acum fisierele valid.txt si invalid.txt din directorul curent sunt populate cu adresele corespunzatoare.

Procesarea de acest fel este foarte utila cand exista procesari mai complexe. Practic este o alternativa la Shell Scripting (linux) sau Batch Scripting (windows), limbaje care nu sunt la fel de flexibile.

Argumente catre script

De multe ori este util sa trimitem direct argumente catre script pentru a avea functionalitate diferita de exemplu.

Diferenta fata de scenariul anterior ar fi ca numele fisierului cu adrese de mail trebuie sa vina ca argument la script.

Argumentele sunt preluate automat in variabila $argv. Este de remarcat ca de fapt primul element din array, adica $argv[0] este chiar numele scriptului!

Exemplul anterior modificat este:

 1#!/usr/bin/php
 2<?php
 3
 4// numaratoarea incepe de la 1 pentru a elimina numele scriptului
 5for ($i = 1; $i < count($argv); $i++) {
 6  // initializare stream de input
 7  $input = fopen($argv[$i], 'r');
 8
 9  // initializare stream de eroare
10  $err = fopen('php://stderr', 'w');
11
12  if(!$input) {
13   continue;
14  }
15
16  // faza de cazurile anterioare, aici se verifica sfarsitul fisierului
17  // pentru ca inputul nu se citeste de la tastatura
18  while(!feof($input)) {
19   // fac trim la linie pentru a scapa de eventuali terminatoari de linie
20   $line = trim(fgets($input, 1024));
21
22   // testez adresa de email
23   if(filter_var($line, FILTER_VALIDATE_EMAIL)) {
24     // output-ul se face direct pentru ca acesta este echivalent cu
25     // stream de php://stdout
26     echo $line . PHP_EOL;
27   } else {
28     // adresele invalide sunt scrise directionate catre stream-ul de
29     // php://stderr pentru a fi interceptate ulterior
30     fputs($err, $line . PHP_EOL);
31   }
32  }
33
34  // inchidere stream input
35  fclose($input);
36
37  // inchidere stream eroare
38  fclose($err);
39}

Pentru a rula fisierul cu argumente:

1$./argTest.php email.txt >valid.txt 2>invalid.txt

In 2008 cand am dat primul examen de certificare erau 22 de ingineri certificati Zend in Romania, eu am devenit numarul 23.

Cu timpul se pare ca mai multa lume a inceput sa se certifice, iar saptamana aceasta numarul100 a fost depasit!

La o filtrare dupa data certificati ZCE PHP am constatat, plin de bucurie, ca web developer-ul cu numarul 100 certificat din Romania este chiar colegul si prietenul meu Emanuel Croitoru, pe care l-am chinuit saptamani intregi cu indemnul: “nu-ti face griji, e simplu”.

Atunci cand a trebuit sa aprofundeze manualul se pare ca nu era chiar atat de simplu. 🙂

Dar pana la urma, determinarea pentru a face pasul acesta este un argument in plus ca un ZCE se straduieste sa fie un web developer bun!

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.

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.