Soluția de moment: downgrade la Firebug 1.4: http://getfirebug.com/releases/firebug/1.4/

PS: Firefox 3.6 sub Hardy amd64 este probabil cea mai instabilă versiune lansată vreodată. Am avut versiuni de Firefox Alpha sau Beta ce erau mai stabile de atât.

Pe alocuri plângerile mele au avut succes. Acum două zile colegii de echipă mă ascultau în timp ce modificam niște chestii, iar involuntar am zis: iar de aici copiez dincolo … touche: “Ce-ai zis mă? Să copiezi?”. Exact ce ziceam mai sus … câteodată și mie îmi vine greu să nu scriu cod prost. Dar eforturile susținute = evoluție. În concluzie am luat linia aceea lungă (un apel înlănțuit de proceduri) și am pus-o într-o nouă metodă.

În concluzie vreo câteva idei, departe de a oferi o imagine completă:

• dacă îți vine să faci copy-paste, fie ele și 3 linii de cod sau una lungă, înseamnă ca ai nevoie de un mic refactor.
• o arhitectură bună, modulară, a aplicației, DRY (și preferabil KISS) compliant, duce la o mentenanță mai ușoară. Pentru a modifica ceva nu este nevoie să cauți toate instanțele aceleiași bucăți de cod.
• dacă acea parte de ‘unknown’ umbrește puterea de a-ți crea arhitectura înainte de a o implementa, atunci orice model repetitiv din cod stă bine într-o metodă separată.
• caută să înțelegi framework-ul pe care îl folosești. De exemplu în dezvoltarea web folosind MVC, nu prea are ce căuta într-un controller o chestie ce ar sta bine într-un helper/bibliotecă, pentru că atunci când este nevoie să fie apelată bucata respectivă din alt controller, fără refactor, o să fie trist. Desigur, excepție fac acele controllere moștenite, dar și acolo este o linie fină între ce se poate moșteni și ce ar trebui să fie apelabil global.
• refactor, OOP, clase, interfețe, ‘design pattern’ (exemplu: singleton) ar trebui să nu fie doar cuvinte într-un vocabular de specialitate.

Știu, nu vreau să fac “carieră” din astfel de post-uri pe blog și nu prea cred că o să mă vedeți vreodată să trimit chestii către http://hackersblog.org/. Sunt preocupat de a proteja, de a-i învăța pe alții cum să se protejeze, și mai puțin de a demonstra vulernabilități. Sunt orientat către ce nu ar trebui să facă aplicația și mai puțin înspre a demonstra cum ajungi acolo. De altel aș prefera ca lumea să nu se ia de ‘junk’-ul de WordPress ce rulează pe blog, sunt prea ocupat pentru a scrie un engine sigur cu un număr echivalent de facilități. Mă rog, va urma un contra-exemplu pentru a susține cele din paragraful anterior.

Povestea începe de la faptul că am avut o mică discuție cu necenzurat despre importanța folosirii unui framework, dar el o susținea pe a lui cu alea 10 kile de cod. Doar pentru ce îți trebuie un framework de 1.25 megi (dimensiunea minimă, maxim 1.49) pentru o aplicație banală? Pai în primul rând bune sunt cele de PHP5 folosind OOP și clase cu auto-load. Poți face multiple instalări folosind aceleași surse ale framework-ului exceptând aplicația în sine. Folosești ce încarci. A da, și ai filtrare implicită. De ce? Pentru că nimeni nu este perfect. Greșeli apar și în codul programatorilor ce au trecut de fazele tatonării. Vorbesc din experiența lucrului și mai mult din experiența lucrului în echipă. Dacă tu ca programator nu o dai de gard, se prea poate să dea altul.

Acu recunosc, am trișat puțin. M-am uitat puțin prin cele 10 kile de cod astfel încât buba a fost oarecum imediată. Dar nu imposibil de descoperit cu puțină răbdare și stil având în vedere regulile simple de URL rewrite, destul de evidente, și faptul că era vorba de un singur parametru vulnerabil. De fapt am reușit 3 in 1: XSS, blind SQLi și disclosure în același input.

A da, a folosi mysql_error() în producție este una dintre cele mai proaste idei. XSS-ul și disclosure-ul au fost posibile prin intermediul acestei funcții magice ce ar trebui folosite doar pentru dezvoltare, nu și pentru producție.

Momentan nu dăm poze, așteptăm să aplice patch-ul trimis .

Paragraful anterior rezumă problema, dacă citim printre rânduri. Problema sub Windows este rularea mai multor procese FastCGI ce să servească pe același port, practic un cluster local cu ’round robin load balance’. Tehnic vorbind – se poate. Dincolo de un simplu FastCGI wrapper cum este spawn-fcgi, proiect de casă al lighttpd, a apărut o versiune nativă de Windows pe forurile respective. De curiozitate am luat sursa, am compilat-o cu MinGW (gcc -O2 -lws2_32 -o spawn-fcgi-win32.exe spawn-fcgi-win32.c) și am început să mă joc. Într-un mod așteptat, suportul pentru PHP FastCGI childs nu funcționează sub Windows, din motive tehnice. De fapt cercetând sursele PHP pentru cgi SAPI (php-src/sapi/cgi/cgi_main.c) partea cu child process este pusă între niște blocuri de preprocesare pentru compilator: #ifndef PHP_WIN32 … #endif ceea ce practic anulează FastCGI Process Manager-ul rudimentar implementat de către echipa de dezvoltare a PHP. Motivele sunt simple: spre deosebire de *NIX, sub Windows nu există conceptul de fork() al proceselor. Ba mai mult, sub *NIX există PHP-FPM(FastCGI Process Manager) ceea ce dă apă la moară și mai mult unei platforme non-Windows pentru PHP. Fanii nginx știu despre ce este vorba.

Vestea bună este faptul că acel spawn-fcgi-win32.exe știe să lanseze mai multe procese ce să servească pe același port TCP. Dă și idei despre cum ar trebui implementat un FastCGI Process Manager sub Windows pentru PHP. Ba mai mult, cum ziceam și în paragraful anterior,  acestea vor servi prin round robin load balance. Această arhitectură multiproces, deși nu se pretează stilului Windows ce este preponderent multithread, rezolvă problemele cu extensiile de PHP ce nu au implementat acel ‘thread safety’, iar clusterul poate să facă uz de o arhitectură SMP, fără a apela la threading.

Acum poate apare întrebarea: de ce mai multe procese FastCGI pentru a procesa scripturile PHP? În primul rând practica ne invață că un ’segmentation fault’ poate să apară oricând, iar în producție nu este faptul cel mai de dorit. Arhitecturile multiproces s-au dovedit a fi cele mai potrivite. Vezi cazul Google Chrome cu 1 proces per tab. În al doilea rând, un proces PHP ce servește cereri FastCGI are o limită de 500 de cereri după care acel proces se închide. Acea limită este codată în sursele PHP (tot în cgi_main.c). Acea limită se poate altera prin ‘environment variables’, și anume prin: PHP_FCGI_MAX_REQUESTS. Problema care se ivește: o limită mare poate duce la probleme de memorie ocupată abuziv (memory leaks). În concluzie, această limită este necesară. Prin design-ul serverului FastCGI al PHP, limita este obligatorie și finită deci este nevoie de un PHP FastCGI Process Manager. Apache are ceva extensii (mod_fastcgi si mod_fcgid, doar mod_fastcgi știe să folosească TCP binding) sau soluția Zend Server: Zend Enabler for Apache, IIS are propriul manager. Piața de web servere de Windows ce întâmplător știu de FastCGI nu se termină aici. Spre exemplu eu folosesc versiunea nativă a nginx sub Windows pentru simplul fapt că folosesc nginx și sub alte platforme. Am o târlă de motive pentru care nginx este trecut în preferințele subsemnatului ca web server excelent. Dar, în același timp, nu pot să mă iau după toate ‘tutorialele’ de PHP FastCGI sub Windows unde ‘php-cgi.exe -b 127.0.0.1:9000′ este suficient pentru a rula. Este suficient până la primul crash sau până la 500 de cereri. În plus, eu ca web developer poate că îmi doresc o soluție complet separată de web server.

Bun, acum am pus bazele ideei despre cum ar trebui făcut un Process Manager. Una dintre probleme este acel ‘race condition’: dacă toate procesele au aceeași viață, spre exemplu un cluster local de 4 cu limită implicită de 500, atunci acestea se vor termina în modul următor: la cererea 1997 – primul, la cererea 1998 – al doilea, la cererea 1999 – al treilea, la cererea 2000 – ultimul. Dacă process managerul nu se prinde de faptul că nu mai exista cineva care să proceseze ceva.php, atunci web serverul va servi clasica eroare 504 (Gateway Timeout) iar clienții conectați la webserver vor fi nemulțumiți. Acel php-cgi.exe nu oferă o metodă de identificare a faptului că rămâne fără cereri. Nu există în cod suport pentru IPC (Inter Process Communication) cu un manager. În concluzie, după bootstrap, un manager poate doar să monitorizeze clusterul. Nu susțin faptul că nu s-ar putea implementa. Ori, această monitorizare poate avea întârzieri, și pe un server încărcat aceasta nu este de dorit. În concluzie, printr-un algoritm, managerul ar putea mări artificial și temporar viața proceselor 2, 3 și 4 pentru a pune un interval de întârziere și a fi cineva acolo care să servească până monitorul se prinde de faptul că lipsește cineva. Altă idee ar mai fi modificarea pentru Windows a serverului FastCGI ca să suporte respawn (autospawn), înainte de a se închide, deși încă nu am investigat dacă această posibilitate este realizabilă din punct de vedere tehnic. Teoretic ar fi OK, cel puțin din câte mă prind citind despre varii funcții din Windows API. Ar rezolva problema existenței unui child care să servească, in concluzie managerul s-ar transforma în simplu monitor de procese după secvența de bootstrap unde lansează clusterul. Idei am, din păcate n-am mai pus mâna pe C decât ocazional în ultimii 5 ani. Din fericire mai pricep ce e prin codul altora . Ziceam și pe Twitter: De ce nu există un PHP – FastCGI Process Manager sub Windows? Pentru că nimeni nu și-a dat interesul să scrie unul. Posibilităti există!

Ceea ce ne aduce iarăși la WinCache. N-am început degeaba cu el. Unei platforme PHP îi stă bine și cu un opcode cache (PHP accelerator, whatever). Pe lângă PHP din Zend Server – ce vine cu multe jucării de la mama lui, Zend, cred că se poate pune un nginx. Problema acceleratorului și al Cache API-ului ar fi rezolvată. Ba ar fi compatibil codul cu un eventual APC folosit în producție, chiar dacă în teorie, având în vedere soluțiile multiple, se recomandă o bibliotecă abstractă cu drivere pentru varii extensii PHP. Bun, ar zice unii: dar APC ce are? Păi, ultima versiune pusă la dispoziție de unul dintre oamenii ce se ocupă de build-ul de PHP pentru Windows, precum și de dezvoltarea lui, a pus la dispoziție o chestie compatibilă PHP 5.3.x ce din păcate pusă în setup-ul multiproces expus mai devreme duce la crash. Practic din 4 procese, 3 crapă, unul rulează relativ stabil. Contravine ideii de multiproces. XCache deși este excelent, nu foloseste shared memory pentru data cache, deci practic acesta va fi împărțit într-un număr egal cu numărul de procese. Nu știu code cache-ul cum se comportă. WinCache știe doar code cache, dar face uz de shared memory și funcționează bine cu load balancer-ul. În concluzie, cel puțin pe termen scurt WinCache are un rol acolo. Mai mult, WinCache funcționează doar cu versiunile de PHP non-thread-safe, compilate cu Visual C++ 9, și teoretic cu IIS, practic Microsoft a mințit. Funcționează cu nginx fără probleme și de ce nu, cu alte servere.

Altă idee: un server web sub *NIX ar putea folosi un server FastCGI sub Windows. nginx poate să folosească backend-uri multiple, eventual cu load balance între mai multe mașini. Deși încă sunt de părere că PHP sub Windows cam suge datorită faptului că are multe lacune iar majoritatea bibliotecilor ce le integrează provin din *NIX, are un atu: suportul COM/.NET – ceea ce înseamnă că într-o arhitectură existentă se poate adăuga un server Windows cu PHP ce să poată beneficia de anumite SDK-uri comerciale ce se distribuie sub formă de COM.

- Mihai Brehar

- Maria Diaconu

- Aici ar trebui să am un nume, dar am un lapsus în schimb

- Ovidiu Negrean

- Ciprian Stăvar

- Ștefan Rusu (adică subsemnatu’)

- Alex Bolboacă

- Paul Nagy

- Jurgen Appelo

În fine, timpul a fost scurt, au fost ceva probleme cu locația, s-au propus mai multe teme, s-a vorbit în mare parte despre estimări. Am trecut repede la fapte, cu berea în față (am specificat: cadru informal) dar cu atenția spre Agile. Paul în special și restul au oferit câteva informații valoroase:

- estimările se pot face pe task-uri ce nu depind de alte task-uri. Un dezvoltator pricepe mai bine care-i treaba cu dependința.

- este mai ușor să măsori în unități relative comparat cu unități bine stabilite. Exercițiul a constat în faptul că l-a pus pe Mihai Brehar să estimeze distanța dintre ei. Răspuns: 1,5m. Următoarea chestie a fost: pune degetul unde crezi tu că este jumătatea distanței dintre noi. Ochiometric a fost bine, iar dacă treceam la măsurători precise, a doua estimare ar fi mai bună – de unde și povestea cu velocity points. Pe de altă parte acele velocity points sunt valabile pentru o echipă. Schimbi oameni din echipă – ai altă echipă. Ajungem la filosofia Agile – oameni, nu unelte, dar despre asta era vorba în primul rând, nu?

- pentru cei ce vor să estimeze task-urile în timp, Paul a fost ferm: ‘am o veste proastă pentru dezvoltatori – nu puteți’. Se leagă de povestea de mai sus.

-  au fost prezentate mai multe metode de estimare, pe lângă clasicele numere incrementate sau luate ca valori din șirul lui Fibonacci, Alex a prezentat un tabel ceva mai complicat (nu îl pot reproduce, am reținut doar chestia cu numerele la tricouri ), iar Paul a vorbit despre metoda cărților de poker.

- ca idee, este nevoie de date suficiente pentru a face calcule. Ideea este luată oarecum din teoria numerelor mari din statistică. Numerele mici dau statisticile peste cap cu variații mari când ai date puține … dar când ai date multe, situația se schimbă.

- încă o reprezentare grafică a fost o chestie ce arăta partea de ‘known’ și partea de ‘unknown’ ce înconjoară acea zonă. Se leagă de chestiile de mai sus. Scopul este de a trece mai repede de la ‘unknown’ la ‘known’ prin învățare – cu cât înveți mai repede, cu atât mai repede se produce tranziția – și prin feedback.

Pentru că discuția a rămas începută, am schimbat locația datorită micilor probleme pomenite mai sus. Mai multă bere (beer is priceless!) și discuții mai aprinse. Ca niște concluzii: Agile este o filosofie (nimic nou sub Soare aici) ca răspuns celor ce debitează pe această temă. Paul (din nou) a venit cu o completare la idee prin ‘Scrum este un framework’. Ba mai mult, este un framework minimal – dacă scoți din el, se duce naibii totul, dar mai departe pe el se poate construi și personaliza metodologia de lucru. De altfel, cred că Jurgen a spus aceasta, sper să nu atribui greșit citatul/adaptarea, cei ce ‘fac Scrum’ au tot atâtea șanse de a ‘face Scrum’ câte șanse are un programator de a instanția o clasă abstractă. Lucru ce vine în completarea ideii despre Scrum ca framework.

Altă discuție interesantă la bere ce merită menționată a fost motivul pentru care managerii nu trebuie să pună presiune pe dezvoltatori. Din nou Paul la balon – da a fost vedeta serii. Cercul vicios sună/arată cam așa: presiune de la manager catre dezvoltator -> grabă + hack -> cod prost -> maitenance -> mai puțini oameni activi. Ultimele 3 duc la frustrare, buguri care mai departe duc la și la mai multă presiune, iar frustrarea adaugă încă o doză de cod prost și bug-uri.

A doua zi a fost dedicată Code retreat-ului, deși a apărut prin zonă doar Mihai Brehar și mai târziu Ovidiu Negrean. Deși mă simțeam ca după o bătaie cu parul (motiv necunoscut), am luat parte la toate cele trei iterații ce s-au făcut pe problema jocului de poker, problemă pentru care am apelat la PHP ca limbaj și Kohana ca framework pentru simplitatea de a încărca automat clase și a face rapid un prototip. Primele două au fost alături de Mihai unde am exersat varii tehnici (TDD, pair programming), ultima a fost cu Alex. Ultimele două iterații au fost bazate pe TDD. Ca rezumat:

- prima iterație = FAIL. Cică era de așteptat. După 45 minute de pair programming, codul a fost rulat o singură dată și a returnat un simplu 0 – ceea ce nu rezolva prima mână. S-a văzut importanța testelor și ca o paranteză la implementare – folosirea limbajului de business cerut de client (black și white pentru jucători, nu hand1 și hand2).

- a doua iterație, TDD based, nu doar că a fost cu succes, dar am avut și timp de refactoring plus 5 minute de relaxare. Alex a fost prin zonă cu o mână de ajutor deoarece nimeni nu știa cum să facă TDD.

- a treia iterație a mers tot pe mâna TDD, am folosit o abordare diferită a problemei (altă echipă). Inițial ne-am propus să rezolvăm problema full house, iar în final am rezolvat și careul deoarece soluțiile erau înrudite în contextul respectiv. De data aceasta am fost creativ și am folosit o metodă matematică ce nu presupune parcurgerea mâinilor, ci calcule. Problema s-a redus la una de rezolvare a unui sistem de clasa a VI-a:

{ 2X + 3Y = 4X + Y

{ 2X + 3Y = X+ 4Y

ce rapid ajunge la X = Y  pe ambele ecuații (două drepte suprapuse, ca reprezentare în plan x0y) de unde și concluzia că soluția este funcțională pentru cele două cazuri (full + careu), deoarece X = Y presupune ‘five of a kind’ cum erau la acele jocuri obosite de poker ce se găseau prin varii baruri. E bună și matematica aceasta la ceva în programare și mi-am adus aminte de ce sunt bune unele modele: dacă sunt demonstrate corect și implementate corect, sunt ‘bug free’ din punct de vedere logic. Excludem erorile de limbaj/runtime.

Pentru că puțini pricep cum se face TDD, iau ca exemplu un feature ce trebuie să returneze -1, 0 sau 1 – folosit și în tratarea cazurilor la jocul de poker (black, tie, white).

- se scrie primul test (am folosit assert($obj->method() == -1);, nu am apelat la PHPUnit)

- se implementează un mock în method (return -1;)

- se rulează testul => OK

- se scriu celelalte teste (assert($obj->method() == 0); și assert($obj->method() == 1);), se rulează și evident, eșuează

- se implementează codul funcțional propriu zis

- se rulează iar testele, iar dacă totul e OK, refactor și teste

Chiar aveam într-o metodă o eroare de logică, TDD a arătat rapid sursa problemei, iar debug-ul a durat 10 secunde. Avantajele sunt clare. Ca idee: TDD se potrivește doar pentru core functionality, nu pentru interfețe. Nu poți testa un capcha sau un CSS pe IE 6 prin TDD. Pentru aplicații ce folosesc baze de date, este nevoie de un mock. În rest, metoda își arată utilitatea. Noapte bună!

Window » Preferences » Team » SVN – iar Client se schimba din JavaHL în SVNKit. Voila – se rezolvă problemele.

Eroarea era ceva de genul:

RA layer request failed
svn: OPTIONS of ‘http://hostname/svn/repository_path/trunk’: Could not resolve hostname `hostname‘: No such host is known (http://hostname)

Acum totul este roz. Setup: Eclipse 3.4.1, Subclipse 1.6.2, Java 1.6.0_13.

Ideea este următoarea: pentru a impune o cheie străina folosind MySQL și InnoDB este nevoie ca structura arborelui să fie corecta și aceasta să convină lui InnoDB. A doua parte este partea spinoasă. Cel mai probabil un arbore corect definit are un lucru esențial ce îi lipsește. Se dă următoarea structură de bază:

CREATE TABLE `trees` (
`id` INT( 11 ) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`parent_id` INT( 11 ) UNSIGNED NOT NULL DEFAULT '1',
`data` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL ,
INDEX ( `parent_id` )
) ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_unicode_ci

Precum se observă schema de date este corectă iar aparent nu pot apărea probleme. Se dă chiar următorul arbore:

1, 0, a
2, 0, b
3, 1, c
4, 1, d
5, 3, e
6, 2, f

Deși (aparent) la prima vedere structural este corect, dacă se rulează interogarea ce ar trebui sa pună constrângerea:

ALTER TABLE `trees` ADD FOREIGN KEY ( `parent_id` ) REFERENCES `trees` (
`id`
) ON DELETE CASCADE ;

o să dea o eroare de MySQL de toată frumusețea, ceva gen:

#1452 - Cannot add or update a child row: a foreign key constraint fails
([...]`, CONSTRAINT `[...]` FOREIGN KEY (`parent_id`)
REFERENCES `trees` (`id`) ON DELETE CASCADE)

Cei cu privirea mai ageră poate că s-au prins de soluție. Nu întâmplător i-am dat valoare implicită 1 lui parent_id, ba chiar mai mult, exemplul dat de mine nu este UN arbore, ci mai mulți arbori stocați în aceeași tabelă. Am dat acest exemplu pentru că am întâlnit de suficiente ori în practică asemenea implementări ce mai încolo îmi dădeau bătăi de cap. Ba chiar am moștenit o astfel de baza de date pentru un proiect. Ceea ce confirmă zicala care spune faptul că web developerii sug la SQL – iar cum sunt și eu în breasla lor mă auto-includ. Dar din când în când, mai există și momente de deșteptare.

Soluția sună cam asa: se face backup la date. Cheile primare nu se salvează, coloana parent_id ce va deveni cheie străina se incrementează cu o unitate dacă este vorba de o implementare precum cea din exemplul meu, dacă nu, atunci se adaptează. Se golește tabela. Se aplică iarăși codul de mai sus pentru crearea cheii străine (ALTER TABLE bla, bla, bla). În mod deloc surprinzător, aceasta va funcționa fără probleme. Nu va mai da eroarea #1452. Dar, pentru a continua, este imperativ ca această înregistrare să se găsească în tabelă:

INSERT INTO `trees` (
`id` ,
`parent_id` ,
`data`
)
VALUES (
'1', '1', 'root'
);

‘root’ nu e musai să fie ‘root’. Poate fi și ‘rădăcină’, dar cum personal scriu mai rar soft pentru România, prefer denumirile în Engleză. Aceasta trebuie să fie rădăcina arborelui. O înregistrare de genul (0, 0, ‘root’) este invalidă, deci nu va putea fi folosită pentru a valida implementarea originală. De aici se pot insera mai departe înregistrările, fără bătăi de cap atâta timp cât se păstrează integritatea relației cheie primară – cheie străină. De altfel, această înregistrare NU trebuie ștearsă. Dacă se șterge, se va șterge automat tot arborele. Este evident … dacă tai un copac de la rădăcina, cade cu totul. Dacă tai doar o creangă, restul copacului nu este afectat. În concluzie, dacă datele sunt manipulate corect, nu pot apărea probleme. Mai departe se poate insera noul arbore:

INSERT INTO `trees` (
`parent_id` ,
`data`
)
VALUES (
1, 'a'
), (
1, 'b'
), (
2, 'c'
), (
2, 'd',
), (
4, 'e'
), (
3, 'f'
);

Se va obține rezultatul dorit inițial. Iar constrângerea își face magia: spre exemplu dacă se șterge (2, 1, ‘a’), atunci automat se vor șterge și (4, 2, ‘c’), (5, 2, ‘d’) și (6, 4, ‘e’) pentru că ierarhic au ca părinte pe (2, 1, ‘a’).

Pentru că tot m-a prins microbul MVC, mai bine zis Kohana, o să dau ca exemplu un model ce tratează din punctul de vedere al aplicației problema de mai sus. Din moment ce în mod implicit Kohana este destul de restrictiv cu manipularea variabilelor, altfel spus chestii ce în mod normal PHP le tratează ca ‘Notice’ în Kohana pot da in ‘Runtime Error’, metodele sunt puțin mai stufoase în sensul că verifică integritatea înainte de a acționa. Exemple asupra a ceea ce am spus mai sus: nu se poate șterge sau actualiza o înregistrare ce este deja ștearsă. În mod normal aceste operații returnează 0, fie ca e vorba de ‘affected rows’ sau de ‘deleted rows’. Cel puțin așa se întâmplă în mod implicit în ambele situații descrise, nu am cercetat dacă este configurabil acest comportament și nici nu am de gând. Kohana prin strictețe impune modele sănătoase de programare ce nu și le însușește orice cocalar ce pune mâna pe PHP pentru faptul că variabilele încep cu $ și a auzit că poate să se simtă și el h4×0r pentru că poate programa ceva. Deci să îi dau bâte cu modelul:

class Tree_Model extends Model {
 
	public function __construct($id = NULL)
	{
		parent::__construct($id);
	}
 
	public function add_child($parent_id, $data)
	{
		$check_record = $this->db->where('id', $parent_id)->get('trees');
 
		if($check_record->count() > 0)
		{
			return $this->db->from('trees')->set(array('parent_id' => $parent_id, 'data' => $data))->insert();
		}
		else
		{
			return false;
		}
	}
 
	public function update_child($id, $parent_id, $data)
	{
		$check_record1 = $this->db->where('id', $id)->get('trees');
		$check_record2 = $this->db->where('id', $parent_id)->get('trees');
 
		if($check_record1->count() === 1 AND $check_record2->count() > 0)
		{
			return $this->db->from('trees')->set(array('parent_id' => $parent_id, 'data' => $data))->where('id', $id)->update();
		}
		else
		{
			return false;
		}
	}
 
	public function delete_child($id)
	{
		$check_record = $this->db->where('id', $id)->get('trees');
 
		if($check_record->count() === 1 AND $id > 1)
		{
			return $this->db->from('trees')->where('id', $id)->delete();
		}
		else
		{
			return false;
		}
	}
 
}

PS: clasa este portabilă și pentru alte baze de date având în vedere faptul că am folosit ‘Database Query Builder’. Mergea si cu ORM, dar prefer o abordare puțin mai directa a problemei. În ORM nu mă mai simt stăpân pe situație. Pentru cârcotași: având în vedere că aceste tipuri de structuri de date nu prea sunt dedicate modificărilor dese, impactul de performanță datorat numărului mărit de interogări pentru a verifică integritatea este minim și merită efortul pentru a face o abordare corectă în loc să se apeleze la reguli mai puțin stricte și a depinde de erorile eventuale returnate de către baza de date (FK constraint error).

Nota: nu pot corecta comportamentul cretin al WordPress pentru a afisa corect apostrof si ghilimele.

Iar acum să trec la articolul pe bune. Ieri și astăzi am răscolit Internet-ul după o chestie ce să imi ofere lista pomenită în titlu. M-au ajuns din urmă zilele în care sunt pus în fața faptului de a dezvolta o asemenea aplicație ce necesită o astfel de listă/astfel de liste. Fie am găsit liste incomplete – mai bine zis un document xls de la Institutul Național de Statistică ce datează de pe vremea lui Pazvante (sau recensământul din 2002, fiecare citește ce vrea) sau lista disponibilă pe Wikipedia ce nu mă coafează din moment ce am observat inadvertențe, fie nu sunt structurate în sensul că orice sat e trecut la orașe. Deși nu am întâlnit o chestie ce să le mulțumească pe toate și anume o listă ce cuprinde și diacritice, lista de față este (relativ) completă.

Am scris un mic script ce a cules listele pomenite mai sus. Le pun la download ca fișier serializat, urmând ca fiecare sa îl convertească în formatul pe care și-l dorește: XML, JSON, SQL, etc. Mai pun și un script obosit ce ia conținutul fișierului și îl trântește în HTML  (cu var_dump() – nu m-am obosit să fac artă).

Download: lista_localitati.zip process_ro_list_output.zip

Introducere

Desi exista o droaie de pachete de astea ce le contin pe toate si au o gramada de arome, pe zi ce trece ajung la concluzia ca un developer serios nu se incurca cu mizerii si isi seteaza singur mediul de dezvoltare a aplicatiilor web. Ma rog, nu toate sunt mizerii, dar majoritatea fie sunt prea stufoase, fie inutile sau inutilizabile fara lucru manual – deci mai bine faci lucru manual din start. Asta in cazul in care nu vrei sa ramai o mimoza pentru tot restul vietii care transpira cand vine vorba sa adauge module noi mediului respectiv, sau pur si simplu sa se blocheze in parametrii de configurare relativ simpli. Nu sustin faptul ca este usor. De altfel patrunderea in tainele configurarii fine necesita timp si multa documentatie citita. Dar macar vreo cateva chestii de baza ar trebui cunoscute. Iar chestiile de baza pornesc cu instalarea.

Propozitie cheie: daca iti este lene sa iti configurezi acest mediu (lucru ce nu se intampla zilnic, iar experienta acumulata este benefica) atunci oare nu iti este lene sa te apuci sa programezi catusi de cat mai mult decat aplicatii gen “hello world”? Pentru a implementa solutii de o complexitate relativ mare ce necesita varii module este nevoie de mult mai multa munca pentru documentare decat pentru a configura un mediu de dezvoltare. In plus, din moment ce nu iti cunosti bine mediul in care ruleaza aplicatiile tale, cum poti avea nesimtirea sa sustii ca ai idee foarte bine ce face propria aplicatie? De unde vei sti ca va functiona corect si este portabila pe alta masina? Intrebarile acestea sunt multe, si nu, nu am de gand sa le transform in intrebari retorice. Raspunsurile sunt mai mult sau mai putin evidente.

O sa structurez acest articol in cativa pasi destul de simplu de urmat. Este ca in cazul in care se construieste o casa: se pleaca de la fundatie, si se termina treaba cu acoperisul. Deci ordinea va respecta logica si bunul simt, cu notiunea ca desi o sa incep cu Apache, MySQL deasemenea poate fi primul pas deoarece baza de date si serverul web nu sunt interdependente. PHP se integreaza cu Apache, deci regulile anterior mentionate indica faptul ca va fi instalat dupa el – aceasta pentru a nu fi nevoit sa faci instalarea PHP de doua ori.

Pasul 1: Instalarea Apache 2.2

In principiu primul pas ar fi verificarea faptului ca nici un alt proces nu asculta pe portul 80 ce in mod uzual este folosit de catre Apache. In mare chestii precum Skype ar trebui inchise inainte de instalare, pentru ca Skype are prostul obicei de a asculta pe porturile tipice HTTP si HTTPS (adica 80 si 443) printre altele. Pentru o solutie generalizata, utilitarul netstat ar trebui sa ofere solutia: Start > Run > cmd.exe iar in chestia aia neagra aka terminal (chestie pe care multi nu o pricep, in concluzie o urasc) se ruleaza urmatoarea linie:

netstat -a -p TCP

ce va returna toate porturile TCP ce sunt active. Daca apare o chestie ce se termina cu :80 in coloana “Local Address” este necesara oprirea aplicatiei ce ocupa acel port. Exemplu de situatie in care instalarea nu va fi cu succes:

Desi in trecut installer-ul oferit de Apache Foundation era destul de trist, sau buildul avea lacune (cea mai notabila: absenta suportului pentru SSL – deci nu se puteau folosi conexiuni criptate prin HTTPS), in prezent situatia s-a schimbat in bine. Nu mai este nevoie de build-uri 3rd party cu tutoriale complicate de instalare. Acest tutorial nu se vrea unul complicat, de unde si prezenta pozelor. Click pe ele pentru a le vedea mai mari. Desigur, anumite categorii de cititori se auto-exclud prin definitie. Desi suportul pentru criptare nu este obligatoriu pentru dezvoltare, este recomandat a-l avea la indemana in eventualitatea de a testa aplicatia cum se comporta in acest context – de altfel foarte recomandat daca se compun cai absolute din aplicatia PHP ce depind de context HTTP/HTTPS.

Pagina proiectului este: http://httpd.apache.org/download.cgi

Ultima versiune la ora actuala este 2.2.11, deci pe parcursul acestui tutorial voi folosi aceasta versiune. De aici se poate lua aceasta versiune folosind un mirror de Romania. Daca serverul este cazut, sau fisierul devine indisponibil, se poate oricand cauta o alternativa urmarind link-ul dat mai sus. In principiu dupa ce download-ul e gata, se executa pachetul ce tocmai a poposit pe disk:

apache_2.2.11-win32-x86-openssl-0.9.8i.msi

De aici instalarea e relativ banala pana la configurarea Server Information:

In principiu pentru o masina de dezvoltare aceste chestii nu sunt relevante, deci poti lasa datele implicite. Pentru un server “de productie” in primul rand n-as recomanda Windows pentru Apache2+PHP si in al doilea rand nu cred ca acesta este locul potrivit pentru a trata acest subiect. Deci ma limitez la dezvoltatori. Bifa pentru “All Users” este puternic recomandata, precum si instalarea ca serviciu. In cazul instalarii ca serviciu, serverul va porni impreuna cu sistemul de operare.

La urmatorul pas, Setup Type, se alege “Custom”. Installer-ul vrea sa faca treaba pentru tine, dar asta nu inseamna ca o va face neaparat asa cum trebuie, sau cum e recomandat. Mai departe, optiunile din lista de chestii ce se pot instala pot fi lasate asa cum sunt. Documentatia este optionala deoarece se poate gasi online. Eu o instalez pentru ca spre deosebire de PHP si MySQL, nu se distribuie o arhiva CHM pe site-ul oficial cu aceasta documentatie. Restul chestiilor sunt recomandate. “Build Headers and Libraries” este necesar doar celor ce fac sporturi extreme, deci nu este cazul de fata.

Aici mai este totusi o chestie de facut. Instalarea acestei stive WAMPP (Windows Apache MySQ PHP Platform) – pun sub acest nume pentru a nu se confunda cu proiectul WAMP ce le impacheteaza pe toate, se poate face imprastiat pe disk, dar ca recomandari acestea ar trebui sa fie tinute in acelasi director, caile de pe disk sa nu contina spatii si sa fie cat mai scurte. In concluzie click pe “Apache HTTP Server 2.2.11″, iar in partea stanga jos e un buton “Change”:

Calea propusa de catre subsemnatul este:

C:\wampp\apache

Nu este obligatorie, este doar o recomandare. Dar folosind aceasta denumire, este suficient de clar ce fel de stiva este instalata.

Se termina restul instalarii ce practic se rezuma la next, install, etc. La sfarsit ar trebui ca serviciul sa porneasca automat, iar jos langa ceas sa fie un panel de control pentru Apache 2.2. Pentru a valida instalarea, cu Web browserul preferat se viziteaza adresa: http://localhost/ iar daca totul e OK, ar trebui sa apara mesajul “It Works!”. Cam atat de la Apache.

Pasul 2: Instalarea PHP 5.2

Trecem la PHP 5.2.6 – ramura stabila 5.2 a PHP. Nu am ales o versiune mai noua (5.2.8 sau 5.2.9-2) pentru simplul motiv ca PHP 5.2.6 are un setup complet, in timp ce versiunile mai noi au o mana de module lipsa. Este drept ca se pot pune cele de la 5.2.6, dar este o munca ce nu va fi pe gustul cuiva ce acum incepe incet-incet sa puna gramada un mediu de dezvoltare. In plus, intre aceste versiuni nu au fost modificari majore. Ca o mica paranteza, PHP 5.3.0 va aduce modificari majore, dar momentan este disponibil doar ca versiune de test. De altfel, idea este sa avem un suport cat mai larg pentru dezvoltarea unei aplicatii. Exceptand cazurile in care nu exista alternative, limitarea la tehnologii vechi nu este de dorit. Oricum, in cazul branch-ului 5.2, de anul trecut si pana in prezent, nu s-a miscat mare lucru. S-a centrat atentia pe 5.3 si pe 6. Deci alegerea 5.2.6 este oarecum justificata.

Pentru ca versiunea este totusi una mai veche, link-ul de download este acesta. Dupa ce ati obtinut fisierul, executata-l. Da, este vorba despre:

php-5.2.6-win32-installer.msi

In continuare, treaba va merge ca pentru majoritatea installer-elor de Windows. Doar la Destination Folder este nevoie de o mica modificare:

si anume faptul ca am folosit calea propusa/recomandata:

C:\wampp\php

pentru a pastra o structura consistenta.

Urmatorul pas este important, nu pentru ca vreau sa ii acord eu importanta, ci pentru ca aici se va alege optiunea de configurare ce va integra PHP cu serverul HTTP. Se alege “Apache 2.2.x Module” nu pentru ca spun eu ci pentru faptul ca versiunea de Apache instalata in acest tutorial este 2.2 (d’oh) si pentru ca alte metode de integrare cu Apache fie sunt lente, fie sunt ceva mai dificile, deci vor fi prezentate intr-un articol viitor.

Pasul urmator presupune oferirea directorului unde se afla fisierul de configurare al Apache 2.2. Installer-ul este suficient de destept astfel incat sa stie sa puna ceea ce trebuie acolo, atata timp cat nu sunt probleme intre scaun si tastatura. Am ales calea precum zice imaginea urmatoare:

si anume:

C:\wampp\apache\conf\

ce respecta conventia anterior facuta.

Pasul urmator presupune alegerea componentelor PHP ce vor fi instalate. Ceea ce propune installer-ul este un setup minim, destul de inutil de altfel. Pentru a beneficia de intreaga putere a PHP este nevoie si de extensiile sale. Astfel, in sectiunea “Program” aleg si “Script Executable”, dar fara inregistrarea extensiei .php pentru a fi executata de catre PHP pe motiv ca atunci cand dau dublu click pe un .php prefer sa se deschida scriptul intr-un editor, in loc sa il ruleze. Oricum, daca este parte a unei aplicatii Web, atunci rularea de catre interpretor va fi inutila din start.

Sectiunea “Extensions” este partea stringenta. De altfel motivul pentru care am ales PHP 5.2.6. Le poti instala pe toate, dar se va incarca mediul in mod inutil. Alta solutie ar fi sa fie incarcate pe masura ce un proiect avanseaza, dar refacerea configuratiei aduce ceva batai de cap si necesita o cunoastere destul de buna a extensiilor. O lista recomandata de catre subsemnatul include: bzip2, bz2_filter, Crack, Curl, domxml, EXIF, Fileinfo, GD2, Gettext, GMP, pecl_http, mcrypt_filter, Multi-Byte String, Mcrypt, Ming, MySQL, MySQLi, OpenSSL, PDO – iar din sectiunea PDO – MySQL si SQLite, mai departe, phar, rar, Sockets, Standard PHP Library – Types Addon, SQLite, ssh2, Tidy, timezonedb, XML-RPC, XSL, zip, zip_filter. Lista este departe de a fi completa si inafara de MySQL si SQLite, alte engine-uri pentru baze de date au fost lasate pe afara, desi exista suport pentru ele. Deasemenea am lasat pe afara extensiile ce ofera suport pentru diverse protocoale, printre care si cele tipice pentru e-mail. La nevoie se pot include. Multe dintre ele se prea poate sa fie inutile pentru proiecte relativ simple.

Sectiunea “Extras” contine doar documentatie, dar nu isi are rostul. Online se gaseste documentatie actualizata, fie direct pe site, fie disponibila ca download. Deci o sa o las ca “debifata”.

Dupa terminarea instalarii, o sa ai un Apache 2.2 integrat cu PHP 5.2. Mai este nevoie totusi de o modificare:

C:\wampp\apache\conf\httpd.conf

contine optiunile de configurare ale Apache. Ce n-a facut installer-ul PHP si trebuie corectat de mana este activarea index.php ca fisier de index. Se cauta urmatorul bloc de configurare:

<IfModule dir_module>
DirectoryIndex index.html
</IfModule>

Acesta se schimba in

<IfModule dir_module>
DirectoryIndex index.php index.html index.htm
</IfModule>

Am adaugat din burta index.htm pentru ca unii folosesc si aceasta extensie pentru fisiere HTML. Restart la Apache. Daca ai lasat optiunile implicite, atunci ai langa ceas acel Apache Monitor ce are butoane pentru Start, Stop, Restart – deci nu este nevoie sa se sape prin managerul de servicii al Windows.

Actualizare: NU apela la butonul Restart dupa instalarea PHP! Am constatat cu stupoare ca aplicand tutorialul meu, desi C:\wampp\php e in %PATH%, doar Stop+Restart il aduc pe calea cea buna. Detalii despre %PATH% mai jos.

In directorul:

C:\wampp\apache\htdocs

se gaseste directory root-ul aplicatiilor Web ce vor fi servite de catre configuratie. Pentru teste, index.html se va redenumi in index.php iar continutul lui va fi schimbat in:

<?php

phpinfo();

dupa care se va accesa din nou adresa: http://localhost/. Ar trebui sa apara informatiile despre PHP si mediul in care ruleaza + informatii despre extensii si configurare.

Ponturi:

1. pentru reconfigurarea PHP este suficienta rularea installer-ului din nou, urmata de apelarea cu incredere la butonul “Change”. Este recomandat ca extensiile instalate de catre installer sa nu fie scoase din setup direct din fisierul de configurare, desi aceasta este posibil. Reconfigurarea este posibila si fara installer, dar nu este de dorit pentru toata lumea.
2. daca apari erori la pornirea Apache (C:\wampp\apache\logs\error.log – contine log-ul de erori) atunci trebuie verificat daca installer-ul PHP si-a pus propria cale in %PATH%. Pentru mai multe detalii apelati la: Environment Variable. %PATH% face parte din aceasta categorie si se poate modifica:

• Windows XP: Properties la My Computer -> Advanced -> Environment Variables
• Windows Vista/Windows 7: Properties la My Computer, e un link “Change Settings” pe acolo, ce va deschide un panou asemanator cu cel din Windows XP. De aici procedura e identica, si anume

 In sectiunea System Variables, exista variabila cu numele Path. Se verifica daca contine calea C:\wampp\php. Daca nu, se adauga acolo. Separatorul de astfel de cai este “;” (fara ghilimele!!!) deci atentie la sintaxa.

Note:

(1) Nu constituie erori de pornire acele “PHP Notice”. Erorile sunt explicite si arata faptul ca anumite biblioteci dinamice nu se pot incarca pentru ca Apache nu le gaseste. Acele biblioteci (dll-uri) ce nu sunt gasite de catre Apache se pot copia intr-un director de sistem gen C:\Windows sau C:\Windows\system32 dar aceasta nu este o optiune prea desteapta. Deasemenea se pot copia si in directorul bin al Apache, dar din nou nu este o optiune desteapta. In fond si la urma urmei exista doua categorii de utilizatori de Windows: cei ce il utilizeaza corect – desi este mai dificil, scuteste utilizatorul de multe probleme clasice pe termen indelungat – si utilizatorii ce il fac praf suficient de repede datorita administrarii extrem de proaste. Nu exista cale de mijloc.

(2) In cazul Windows XP o sa apara “Warnings” in legatura cu bibliotecile suplimentare necesare anumitor extensii (gen libmysql.dll pentru MySQL si MySQLi). Solutii: a) Reboot la OS dupa instalarea Apache+PHP. Sub anumite versiuni de Windows (exemplu: XP, la Vista nu am remarcat datorita problemei descrise mai jos) Apache nu baga in seama un %PATH% modificat – deci este nevoie de un reboot pentru a-l aduce pe calea cea buna. Avand in vedere faptul ca anumite chestii din PHP depind de un environment variable, chestia de mai sus este bine sa fie retinuta. b) copierea dll-urilor cu pricina ce se gasesc in directorul PHP si sunt cerute de catre extensii din directorul bin al Apache. Desi, aceasta optiune este una destul de trista. As zice din barda.

Windows Vista: intamplator astazi m-am lovit de instalarea stivei prezentare in acest articol sub Windows Vista. Din moment ce subsemnatul si Vista suntem certati (pe buna dreptate) detaliul de mai sus mi-a scapat. Pana in prezent, integrarea de fata functioneaza doar sub Windows XP si Windows 7 (Beta si RC). Windows Vista are nevoie de un parametru suplimentar atunci cand se configureaza integrarea dintre Apache 2.2 si PHP 5.2, in rest codul PHP apare in browser in loc sa fie interpretat intr-un mod foarte retard. Problema se mai intalneste si la unele pachete de acestea all-in-one. Sectiunea aceasta ce in mod standard se gaseste la sfarsitul fisierului httpd.conf dupa rularea installer-ului PHP:

#BEGIN PHP INSTALLER EDITS – REMOVE ONLY ON UNINSTALL
PHPIniDir “C:/wampp/php/”
LoadModule php5_module “C:/wampp/php/php5apache2_2.dll”
#END PHP INSTALLER EDITS – REMOVE ONLY ON UNINSTALL

trebuie sa mai contina inca o chestie, deci sa arate astfel pentru Windows Vista:

#BEGIN PHP INSTALLER EDITS – REMOVE ONLY ON UNINSTALL
PHPIniDir “C:/wampp/php/”
LoadModule php5_module “C:/wampp/php/php5apache2_2.dll”
AddType application/x-httpd-php .php
#END PHP INSTALLER EDITS – REMOVE ONLY ON UNINSTALL

Pasul 3: Instalarea MySQL 5.1

In principiu inainte de instalare ar trebui verificat daca nu ruleaza nimic pe portul 3306, adica portul implicit pe care asculta serverul MySQL. Daca nu mai exista o alta instalare de MySQL, atunci slabe sanse. Pentru identificarea precisa, se va folosi metoda prezentata la instalarea Apache.

MySQL 5.1.34 este ultima versiune stabila disponibila la momentul redactarii acestui articol, deci il vom folosi pe acesta. Desi mai exista MySQL 5.0 ca branch stabil, folosit destul de mult in productie (de altfel mai exista si 4.1 prin productie, dar il urasc cu pasiune din motive obiective) totusi am mers pe ultima chestie lansata. Are vreo cateva chestii noi ce in buna parte tin de viteza si de extensibilitate.

Spre deosebire de Apache 2.2 si PHP 5.2, pe pagina oficiala a MySQL exista atat build-uri de 32-bit, cat si build-uri de 64-bit. Primele doua se distribuie oficial doar ca binare de 32-bit. In principiu se recomanda build-ul ce se potriveste cel mai bine platformei, 64-bit in cazul subsemnatului, cu notiunea ca pot apela si la unul de 32-bit. Link-ul de download pentru build-ul pe 32 este acesta, in timp ce pentru cel de 64 este acesta. De acolo se alege “Windows MSI Installer” iar din dreapta link-ul de “Download”. In cazul in care mirror-ul ales automat pentru “Download”este invalid sau are probleme, se poate alege si “Pick a mirror” de unde se alege unul mai apropiat de casa.

Eu am plecat la drum cu:

mysql-5.1.34-winx64.msi

iar utilizatorii unui Windows 32-bit este obligatoriu sa plece la drum cu:

mysql-5.1.34-win32.msi

In rest, instalarea este relativ identica.

In pasul in care installer-ul intreaba de  “Setup Type”, se alege “Custom”. Se va debifa documentatia deoarece este disponibila online. Optional se poate lasa. Eu prefer sa downloadez ultimele arhive cu documentatie ce sunt la zi. In rest, nu mai este nevoie de nimic deoarece optiunile sunt multumitoare. Ce mai trebuie schimbata este calea de instalare, ce va folosi modelul prezentat mai sus in cazul Apache si PHP.

Later Edit: mi-a scapat un mic aspect ce nu l-am mentionat data trecuta, si anume faptul ca serverul se poate instala intr-o locatie iar data storage-ul in alta. Acestea sunt imaginile actualizate:

Se continua instalarea. La aparitia acelor chestii despre MySQL Enterprise, se da “Next” pana in sfarsit se ajunge la ultimul pas:

Bifa aia e importanta, dupa ea se va porni procesul de configurare al serverului MySQL si pe aici unii s-ar putea sa isi prinda urechile.Se continua clasicul click-Next pana configuratorul intreaba despre tipul configurarii:

Urmatoarea alegere este atat de evidenta, incat nu voi pune o poza ce sa o arate. Se va alege “Developer Machine” la server type. Urmatorul pas cere modul de utilizare a bazei de date. Cel implicit, “Multifunctional Database” este potrivit pentru acest tip de instalare. La urmatorul pas despre “InnoDB Tablespace Settings” se lasa optiunile implicite. Presupun ca pe C:\ exista suficient spatiu.

Urmatorul pas presupune setarea numarului de conexiuni concurente. De regula, desi in procesul de dezvoltare sunt rare situatiile in care optiunea implicita, “Decision Support (DSS)/OLAP” ce presupune un numar maxim 20 conexiuni concurente s-ar putea sa fie suficient, subsemnatul foloseste optiunea “Manual Setting” si pune numarul la 50.

Mai departe, la setarile de retea, “Enable TCP/IP Networking” este obligatoriu. Nu este necesara activarea unei exceptii in firewall daca baza de date nu va fi folosita inafara masinii. Eu deschid o gaura in firewall pentru acest port pentru ca se intampla sa accesez o baza de date din exterior. Exista alternativa la TCP/IP si anume “named pipes”, dar aceasta va fi lasata deoparte pe moment. Se justifica alegerea pentru masinile ce ruleaza baze de date impreuna cu aplicatii ce le folosesc, in rest, configurarea este putin mai dificila. Web-ul este gandit ca modular, deci in practica, exceptand o parte a Web hosturilor shared (sau cei ce au bani doar de un VPS/masina dedicata), serverul MySQL va rula pe o masina dedicata, in concluzie TCP/IP va fi singura cale de a comunica cu bazele de date. “Enable Strict Mode” este recomandat de catre installer si de catre subsemnatul.

Urmatorul pas este unul foarte important. O greseala in alegere aici se poate propaga mai departe in optiunile implicite si mai departe in probleme mari. Totul ar fi bine si frumos daca ar exista un singur set de caractere, dar din pacate nu este asa. Iar daca intentionezi sa dezvolti o aplicatie ce va primi altceva inafara de caractere latine si uzuale, este cazul sa pui bifa pe “Best Support For Multilingualism”. Se pot face hack-uri la nivel de cod PHP pentru a putea fi folosit setul de caractere implicit, dar aceasta inseamna ca toate sirurile de caractere ce se indreapta catre baza de date sa treaca prin acel filtru, iar o mica neatentie poate sa duca la ore de debugging inutil. In concluzie, mai bine se lucreaza direct cu UTF8.

Mai departe urmeaza setarile serviciului. Da, este recomandat ca MySQL sa fie instalat deasemenea ca serviciu. Bifa pentru lansare automata iarasi e recomandata. Deasemenea recomand adaugarea directorului bin al MySQL in %PATH%. Trebuie doar o bifa. Eu pun numele serviciului MySQL5.1 pentru ca am un fetis cu consistenta, iar Apache se pune Apache2.2 fara ca sa ma intrebe – deci pastrez ideea. Nu e obligatoriu.

Pasul urmator presupune setarile de securitate. Sub nici o forma nu este recomandata crearea unui “Anonymous Account”. Se recomanda crearea unei parole suficient de puternice pentru utilizatorul root ce este un superuser pentru MySQL. A nu se confunda cu root din *nix – utilizatorii MySQL nu sunt utilizatori de sistem. Serverul are propriul sistem de management al utilizatorilor. Deasemenea nu se recomanda activarea accesului remote pentru root.

Se continua setup-ul si gata si cu MySQL.

Bonus: instalarea phpMyAdmin 3.1

phpMyAdmin este un frontend MySQL popular si destul de bun la ceea ce face. Desi initial nu l-am prea suportat, pe servere la distanta se poate dovedi un aliat puternic. In concluzie este o aditie buna si pentru dezvoltarea locala, desi exista si alte optiuni, recomandate de altfel sa fie la indemana: MySQL Query Browser, MySQL Administrator si MySQL Workbench – scule facute de cei de la MySQL AB – adica Sun – adica Oracle – daca este sa pastrez istoricul cumparaturilor. Mai exista si SQLyog, un frontend ce imbina elemente de Query Browser si de Administrator. Unii prefera in locul lui HeidiSQL – desi acesta din urma stie mai putine.

De aici am luat ultima versiune stabila, si anume 3.1.5. Instalarea este relativ mai complicata decat in cazul chestiilor de mai sus pentru ca este aplicatie PHP si nu am apelat la metoda cea mai usoara, dar am apelat la cea mai comoda pe termen lung. Am downloadat:

phpMyAdmin-3.1.5-all-languages.zip

A urmat extragerea arhivei si redenumirea directorului phpMyAdmin-3.1.5-all-languages din interiorul ei in phpmyadmin. L-am mutat in C:\wampp\. Acesta trebuie sa contina fisierele phpMyAdmin. Daca contine alt director, atunci acela trebuie redenumit in phpmyadmin si mutat in WAMPP. Configurarea phpMyAdmin presupune copierea fisierului config.sample.inc.php in config.inc.php si modificarea lui. Modificari necesare:

• definirea $cfg['blowfish_secret'] cu un sir de caractere arbitrar. Preferabil sa fie cat mai de neinteles. ATENTIE: pentru a nu invalida sintaxa config.inc.php trebuie sa se foloseasca apostrof nu ghilimele pentru a defini sirul blowfish_secret. Conform documentatiei phpMyAdmin acesta are o dimensiune maxima aparenta de 46 caractere. Un generator bun poate fi algoritmul sha1, desi setul de caractere este mai redus decat in cazul in care se foloseste un generator ce sa includa varii caractere speciale. Pentru sha1 apeleaza cu incredere la: http://www.shell-tools.net/index.php?op=hash_sha
• schimbarea $cfg['Servers'][$i]['extension'] din mysql in mysqli. MySQLi aka MySQL Improved > MySQL.

Mai are si alte optiuni, dar nu sunt necesare si nu trebuie schimbate. Documentatia phpMyAdmin le explica pe indelete.

Urmeaza integrarea cu Apache. Desi directorul s-ar fi putut pune pur si simplu in interiorul C:\wampp\htdocs s-ar putea sa incurce pe acolo, sau sa fie sters din greseala. Deci apelarea la un alias este o optiune mult mai recomandata. Mai intai voi prezenta pasii, dupa care voi oferi detalii pentru doi dintre ei. Aici sunt pasii:

1. crearea unui fisier text gol in C:\wampp\apache\conf\extra. Acesta se va numi httpd-phpmyadmin.conf pentru a pastra conventia de nume ce o are Apache pentru fisierele de configurare. Fisierul se va gasi ca download la sfarsitul articolului, alaturi de toate celalte resurse.
2. acest fisier va trebui inclus in config-ul cel mare, si anume C:\wampp\apache\conf\httpd.conf. Se include fisierul anterior creat, chiar dupa lucrurile configurate automat de catre installer-ul PHP (scrie in comentariu, liniile ce incep cu # sunt considerate comentarii). Locul acesta se gaseste la sfarsitul fisierului.
3. restart la Apache.
4. vizitarea adresei http://localhost/phpmyadmin pentru validare.

Continutul lui httpd-phpmyadmin.conf:

Alias /phpmyadmin “C:/wampp/phpmyadmin”

<Directory “C:/wampp/phpmyadmin”>
Options Indexes FollowSymLinks
AllowOverride None
Order deny,allow
Allow from all
DirectoryIndex index.php

<IfModule mod_php4.c>
AddType application/x-httpd-php .php

php_flag magic_quotes_gpc Off
php_flag track_vars On
php_flag register_globals Off
php_value include_path .
</IfModule>

<IfModule mod_php5.c>
AddType application/x-httpd-php .php

php_flag magic_quotes_gpc Off
php_flag track_vars On
php_flag register_globals Off
php_value include_path .
</IfModule>
</Directory>

ATENTIE:  datorita modului retard prin care WordPress inlocuieste ghilimelele cu niste chestii ce seamana cu ele dar sunt inclinate (practic alte caractere), metoda copy-paste a textului de mai sus nu se preteaza fara o curatare a mizeriilor. Se recomanda download-ul fisierului de la sfarsitul articolului.

Includerea fisierului de mai sus in httpd.conf prespune adaugarea la sfarsitul httpd.conf a:

# Include the phpMyAdmin configuration file
Include conf/extra/httpd-phpmyadmin.conf

In principiu cam in aceasta consta o instalare de phpMyAdmin. Fisierul de configurare pentru Apache este inspirat de cel din Debian, desi are vreo cateva chestii noi in el, si vreo cateva chestii scoase. Atentie: nu incerca chestii gen “I know better”, mai ales daca iti vine vreo idee creata sa scoti linia cu “Allow from all”. Apache va refuza sa serveasca directorul.Warning-ul din footer, si anume: “Your PHP MySQL library version 5.0.51a differs from your MySQL server version 5.1.34. This may cause unpredictable behavior.” se poate ignora. Inca n-am intalnit probleme folosint clientul de MySQL 5.0, si nu, nu am avut timp sau chef sa caut sau sa imi compilez unul pentru MySQL 5.1.Va urma.

Niste imagini pe post de dovezi (in cazul 3.1.5 arata la fel, nu am actualizat si imaginea):

Download:

apache_2.2.11-win32-x86-openssl-0.9.8i.msi – installer-ul Apache

php-5.2.6-win32-installer.msi – installer-ul PHP

mysql-5.1.34-winx64.msi – installer-ul 64-bit al MySQL

mysql-5.1.34-win32.msi – installer-ul 32-bit al MySQL

phpMyAdmin-3.1.5-all-languages.zip – release-ul de phpMyAdmin

httpd-phpmyadmin.conf – fisierul de configurare al phpMyAdmin ce il foloseste Apache.

WAMPP-images.zip – imaginile folosite pe parcursul articolului

Recomand totusi sursele oficiale pentru fisierele de mai sus. Le-am pus pentru comoditatea unora cu speranta sa nu fie abuzate, in caz contrar, vor fi scoase de la download, sau voi bana pe cei ce le abuzeaza. Inclin totusi catre a doua varianta.

Documentatie online:

Apache – http://httpd.apache.org/docs/2.2/

PHP – http://www.php.net/manual/en/

MySQL – http://dev.mysql.com/doc/refman/5.1/en/

Manuale:

PHP – http://www.php.net/download-docs.php

MySQL -  http://dev.mysql.com/doc/

Recomand versiunile CHM ale manualelor.

Via Misu …

Cred ca este una dintre cele mai tari colectii de geek jokes … evident … nu le poate pricepe oricine …

Bagand niste clice pe blogu’ lu’ necenzurat am dat de imaginea din figura alaturata. Desi imi vine greu sa cred, daca imaginea este pe bune, atunci nu primeaza la categoria penibil prin cerinta in sine, desi intre noi fie vorba, echipa ReactOS se chinuie de ani de zile sa scoata ceva decent si inca mai au de lucru (mult), in timp ce nenea asta cu pretentii pentru oameni locuitori in tara bananiera asteapta ca pentru un buget de 20-100$ sa se aleaga cu un ‘Windows’ numa bun pentru vanzare. Failing at failing sau prostie².

» Powered by XHTML Video Embed

Introducere

Determinarea MIME Type-ului corect pentru un fisier este o problema esentiala. Nu o sa explic si de ce … daca nu stii de ce, atunci tutorialul acesta iti depaseste nivelul cunostintelor. Atunci cand se face upload la un fisier printr-un form, sau se doreste import-ul unui fisier, se poate intampla ca extensia fisierului sa nu reflecte realitatea sau ca aceasta sa lipseasca cu desavarsire, fapt ce va duce la varii probleme. Array-ul $_FILES ce ia valori in functie de continutul unui form ce are specificat in mod explicit enctype=”multipart/form-data” se prea poate sa nu contina valoarea corecta a mime type-ului pentru $_FILES['file_input_name']['type'] deoarece detectia mime-ului cade pe spinarea browserului iar in majoritatea cazurilor acesta se foloseste de extensia fisierului deci va esua in cazurile descrise mai sus. Este nevoie ca informatia sa fie interpretata citind headerele fisierului si folosindu-ne de mime magic.

PECL si fileinfo

Nu o sa imi pierd timpul sa explic ce e PECL. Google este de mare ajutor. Din pacate in repository-urile Ubuntu/Debian, extensia fileinfo nu este disponibila in mod implicit. Din fericire este disponibila prin intermediul PECL. Acum incepe treaba sa fie paroasa.

In primul rand, este nevoie de una bucata compilator. Exista un pachet ce le face pe toate, deci:

sudo apt-get install build-essential

Bun. Avem compilator, avem PECL (presupun, daca n-ai HTTP server si PHP – citesti degeaba). Pentru build-ul fileinfo mai este nevoie de pachete de development, deci:

sudo apt-get install libmagic-dev php5-dev

ce va instala headerele de development pentru libmagic, phpize si alte chestii. Faceti acum, sau regretati mai tarziu. Acum este timpul sa compilam extensia fileinfo folosind pecl:

sudo pecl install fileinfo

Daca maraie vreo eroare la configure, instalati pachetul de development aferent (pentru cei somnorosi, are sufixul -dev). Daca maraie vreo eroare la compile, imi pare rau, nu va pot ajuta. Pe masina de devel a functionat fara probleme. Daca nu maraie nici o eroare, ar trebui sa indice faptul ca extensia a fost instalata cu succes. Ar trebui sa fie ceva de genul:

Build process completed successfully
Installing ‘/usr/lib/php5/20060613+lfs/fileinfo.so’
install ok: channel://pear.php.net/Fileinfo-1.0.4

Daca ati ajuns pana aici, mai este putin si usor. Extensiile instalate prin intermediul PECL nu sunt incarcate in mod automat, spre deosebire de cele instalate din repository-urile Ubuntu/Debian folosind apt-get sau alternativa (cu mici exceptii, spre exemplu mcrypt.so trebuie incarcat in mod explicit – nenea maintainer a fost cascat). Pentru a mentine ideea si spiritul Debian, incarcarea modulului se va face folosind directorul de fisiere alternative de configurare pentru PHP. Tastati urmatoarele chestii intr-un terminal (da stiu, copy-paste e mai comod):

cd /etc/php5/conf.d/; sudo touch fileinfo.ini; sudo nano fileinfo.ini

Bagati urmatoarea linie in acel fisier:

extension=fileinfo.so

dupa care salvati cu Ctrl+O. Inchideti editorul text folosind Ctrl+X. Nu, nu sunt vim maniac, sa nu aud de el. Acum este timpul sa se dea restart la HTTP server pentru a incarca noua configuratie. Ar trebui sa fie valabil si pentru cei cu GCI/FastCGI (eventual alt HTTP server gen lighttpd), desi subsemnatul e de ala cu Apache 2+PHP5 handler, deci in cazul meu (si al majoritatii):

sudo /etc/init.d/apache2  reload

ce va duce la un graceful restart (aka restart fara downtime) urmat de incarcarea noilor fisiere de configurare. Daca totul e ok, noul modul de PHP ar trebui sa fie incarcat. phpinfo(); ar trebui sa indice acest fapt, atat in lista de fisiere de configurare alternative (cele din /etc/php5/conf.d) cat si prin faptul ca ar trebui sa indice pe undeva in mod explicit faptul ca fileinfo este incarcata.

Utilizarea fileinfo pentru a afla MIME Type

Acum sa trecem la lucruri grele. fileinfo contine niste functii smechere asemanatoare cu fopen. Pentru ubergeeks exista modul orientat obiect de lucru cu ele (php.net/finfo_open explica), dar subsemnatul se multumeste cu trei apeluri procedurale din moment ce nu exista nici un avantaj real in cazul de fata pentru a defini un obiect si a-l distruge dupa ce se afla mime-ul. Pentru cei dornici sa isi implementeze o clasa proprie … este alta poveste. Eu mi-am facut o functie custom ce am inclus-o in API-ul central ce primeste ca parametru calea fisierului si imi returneaza mime-ul in caz de succes sau un cod de eroare pentru debug in caz de esuare. Miezul problemei sta in:

$finfo=finfo_open(FILEINFO_MIME, "/usr/share/misc/magic");
if(!$finfo)
	die("Can't open the fileinfo database.");
$mime=finfo_file($finfo, $fileName);
finfo_close($finfo);

Si cam atat. Succes si spor la treaba.

» Powered by XHTML Video Embed

• suport pentru Jumpcut.
• suport pentru a face override la dimensiunile unificate folosind parametri speciali in structura tag-ului.
• localizare in engleza si romana. Pentru alte limbi o sa am nevoie de voluntari.
• suport pentru videoclipurile high definition de pe YouTube.
• introducerea suportului pentru FLV embedding ce a aparut in branch-ul 0.2.4.x dupa ce dezvoltarea acestei versiuni a inceput.
• design complet nou al aplicatiei. Nu, nu ma refer la interfata ci la modul in care lucreaza. Partea publica a plug-in-ului a fost puternic optimizata deoarece modelul de dezvoltare din v0.1.x/v0.2.x incepuse sa puna probleme. Desi admin-panel-ul poate fi mai lent decat cel din versiunile anterioare, acesta este generat complet dinamic, deci adaugarea unui serviciu nou presupune foarte putin lucru.
• securizare mai buna a anumitor componente.

Problema ID-urilor numerice in PHP desi este una destul de banala, rezolvarea este multipla. De-alungul timpului am testat mai multe chestii, dar doar recent am ajuns la o forma finala care sa ma multumeasca deplin. De ce ID-uri numerice? Pentru ca este foarte usor de lucrat cu ele cand se interactioneaza cu o baza de date. Orice tabela care trebuie sa stocheze in mod unic niste chestii, are o cheie primara. Pana acum cea mai desteapta chestie in materie de chei primare este cheia intreaga care se seteaza cu auto-increment – ceea ce asigura complet unicitatea datelor. Recomandarea ar fi ca auto incrementul sa inceapa de la 0 (chestia asta o sa se lege de ce o sa zic mai jos). Bonus ar fi faptul ca fiecare tabela de acest gen ar trebui sa aiba cheia primara indexata pentru a reduce considerabil timpul de cautare al ei.

Adesea aceste chei primare din baza de date sunt trimise prin intermediul requesturilor de tip GET, deci se vor regasi in componenta URL-ului. Problema se pune atunci cand pe langa acel ID numeric, utilizatorul (in mod intentionat) introduce si altceva pe langa acel ID. Treaba poate sa se imputa de la XSS (Cross Site Scripting) – atunci cand acea cheie se regaseste in pagina, sau la atacuri de tip SQL injection (mai grav).

Desi exista functii native in suportul de MySQL pentru PHP, acestea sunt destul de triste la ID-uri numerice, deci am preferat propria metoda:

function clean_id($id)
{
$id=preg_replace("@[^0-9]@", "", $id);
if (empty($id))
	$id=0;
return $id;
}

Chestia asta de mai sus face vreo doua chestii … prima este aceea ca da strip la tot inputul care nu e numeric. A doua verifica ce a mai ramas, iar daca are valoarea 0 (orice 0 din PHP), atunci returneaza un 0 numeric. Este important acest zero numeric … ziceam ceva mai sus de el … acest zero numeric are grija ca interogarea sa nu dea de o chestie gen <<WHERE id=”>> si sa bubuie o eroare de SQL (care in anumite cazuri … ar putea la randul ei sa divulge alte chestii).

Actualizare:

Datorita observatiei lui AgLiAn am ajuns la concluzia ca functia mea initiala nu rezolva o problema: interger overflow, chestie ce mai departe se traduce in interpretarea ca float de catre PHP – si de unde pot aparea alte probleme. Si pentru ca am mentionat pe undeva mai sus de auto-increment (si acest obicei nu o sa se transforme peste noapte pana la proba contrara ce demonstreaza un obicei prost), functia clean_id(); devine:

function clean_id($id)
{
return abs(intval($id));
}

if ($expression==true)
	$var="value";
else
	$var="other_value";

Am gasit o abordare diferita a problemei operatiilor ternare (chestie care o folosesc de o buna bucata de timp), si anume operatia ternara:

function iif($expression, $returntrue, $returnfalse='')
{
return ($expression ? $returntrue : $returnfalse);
}

function iif($expression, $returntrue, $returnfalse='')
{
if ($expression)
	return $returntrue;
else
	return $returnfalse;
}

if ( ( !preg_match ( "@www@i", $_SERVER['HTTP_HOST'] ) ) && ( preg_match ( "@example\.com@i", $_SERVER['HTTP_HOST'] ) ) )
{
$_urlHead = ( isset( $_SERVER['HTTPS'] ) && strtolower ( $_SERVER['HTTPS'] ) == 'on' ) ? "https://www." : "http://www.";
$_redirURL=$_urlHead . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
header ( "HTTP/1.1 301 Moved Permanently" );
header ( "Location: $_redirURL" );
die();
}

if ( ( preg_match ( "@www@i", $_SERVER['HTTP_HOST'] ) ) )
{
$_urlHead= ( isset ( $_SERVER['HTTPS'] ) && strtolower ( $_SERVER['HTTPS'] ) == 'on' ) ? "https://" : "http://";
$_redirURL=$_urlHead . preg_replace ( "@www\.@i", "", $_SERVER['HTTP_HOST'] ) . $_SERVER['REQUEST_URI'];
header("HTTP/1.1 301 Moved Permanently");
header("Location: $_redirURL");
die();
}

PS: din moment ce acest weekend l-am dedicat programarii (da, inca nu mi-a trecut boala complet, deci nici vorba de iesit/iesit la bere/etc.) in seara aceasta o sa pun si o versiune noua de WLMP custom – update-uri la pachetele continute si diverse imbunatatiri.