De ce fisiere “ini”? Pentru ca sunt mult mai comode! Majoritatea serverelor din lumea *nix au fisiere de configurare de tip “ini” sau “conf”. In lumea PHP preferate sunt fisierele de configurare PHP, care in general sunt array-uri. Nu ar fi mult mai elegant sa fie un fisier ini care sa nu fie imbricat in cod PHP?

Din fericire PHP dispune de doua functii native care pot realiza acest lucru: parse_ini_file si parse_ini_string.

Principiul este foarte simplu, se da un fisier de configurare ini si functia va intoarce un array.

Un mic exemplu:

 1;config.ini
 2
 3[simple]
 4number = 1
 5another = 2
 6fraction = 0.2
 7
 8[escape]
 9path = /usr/bin/php
10url = https://blog.claudiupersoiu.ro
11error = '<a href="%path%">%error%</a>'
12
13[array]
141 = a
152 = b
163 = c

Pentru a parsa fisierul anterior:

1$config = parse_ini_file('config.ini', true);
2var_dump($config);

Parametrul al doilea specifica daca sectiunile vor deveni chei in array. Sincer nu vad in ce moment nu ar fi asta util.

Pare costisitor? De fapt pentru fisierul de mai sus este mai ieftin ca timp sa il parsezi din ini decat sa incluzi un array gata parsat. Diferenta pe calculatorul meu este de ~0.00002.

Dar fisierul de sus nu este tocmai mare, asa ca sa trecem la un fisier ini serios, cum ar fi php.ini. Aici diferenta a fost mai mare in favoarea array-ului care a castigat cu un avantaj de ~0.0003, adica aproximativ jumatate din parsare care a fost ~0.0006.

Avand in vedere ca masina mea este destul de puternica si multe cereri concurente pot adauga un overhead pentru un fisier mare, uneori este util un cache intr-un fisier de configurare.

Din fericire acest lucru este simplu de realizat in PHP.

1$cache = var_export($config, true);
2
3file_put_contents('cache/config.php', "<?php\n\$config = " . $cache . ';');

Acum nu mai trebuie inclus decat fisierul cache/config.php si evident regenerat atunci cand fisierul ini este modificat.

PHP trebuie sa aiba drept de scriere in directorul cache.

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…