printf(" SaltwaterC ");

Ca de obicei, PHP sub Windows reușește prin varii metode să dea cu mucii în fasole. Anumite chestii ar trebui să meargă OOTB în teorie. În practică apar dificultăți.

În primul rând am golit directorul C:\Program Files (x86)\Zend\ZendServer\bin\PEAR de toate mizeriile mai puțin go-pear.phar, din varii motive, oricum era un “fresh install” de Zend Server CE. C:\Program Files pentru cei ce încă trag cu dinții de 32-bit. După care am purces, folosind un shell rulat sub Administrator:

cd C:\Program Files (x86)\Zend\ZendServer\bin
php -dphar.require_hash=0 PEAR\go-pear.phar
pear channel-update pear.php.net
pear upgrade PEAR
pear channel-discover pear.phpunit.de
pear channel-discover components.ez.no
pear channel-discover pear.symfony-project.com
pear install --alldeps phpunit/PHPUnit

PEAR_ENV.reg se generează în C:\Program Files (x86)\Zend\ZendServer\bin. Se adaugă în registru la un simplu dublu click. Rulat sub un simplu user:

C:\Users\SaltwaterC>phpunit
PHPUnit 3.5.11 by Sebastian Bergmann.
 
Usage: phpunit [switches] UnitTest [UnitTest.php]
[...]

Restul e can-can.

Update / Disclaimer: în cazul în care n-am fost suficient de explicit, este vorba de Zend Server Community Edition ca distribuție pe post de purtător de vină. Nu este vorba de PHP / Windows. Dar cum Zend susțin faptul lor că distribuția lor de PHP este “certificată”, “production & development ready”, ca tot omul mă aștept ca anumită funcționalitate să funcționeze fără flotări logice.

Eroarea ține de faptul că o arhivă PHAR are o semnătură ce e fie invalidă, fie lipsește în cazul distribuției respective iar PHP dă un warning și refuză instalarea. Motiv pentru care se aplică la runtime flag-ul phar.require_hash=0. Nu știu dacă e lipsă sau e invalidă, puțin mă interesează. Faptul că installer-ul PEAR din distribuție este vechi a fost doar un bonus. 2008-05-17 – în changelog această dată apare alături de versiunea 1.7.2 pe care o dă Zend “de bună” în ultima versiune, 5.0.4. Scuza că e un pachet comunitar iar dacă nu-mi convine pot să dau $xxxx pentru versiunea comercială nu ține din moment ce Zend se laudă a fi “The PHP Company”. Da, mă deranjează teribil ipocrizia din industria software.

Personal am încetat să mai discut cu cei de la Zend probleme ce țin de anumite alegeri cretine pe care le fac în distribuția lor. Sunt grei de cap și încăpățânați. Singura “victorie” din partea mea a fost includerea unei valori predefinite pentru sendmail_path în distribuția standard. Vezi acest post de prin 2009. Aceasta după ce a trebuit să depun efoturi ca să le explic faptul că /usr/sbin/sendmail este standard pentru toate distribuțiile majore și să mă lupt cu astfel de răspunsuri, după ce ei susțineau sus și tare că nu e nici un bug de configurație faptul că sendmail_path e invalid, deși există n-implementări de MTA ce oferă compatibilitate cu sendmail (personal folosesc postfix, deși postfix pe lângă MTA are și un server SMTP). Ca după aceea să o rezolve până la urmă și să pună un articol pe KB. Îmi este greu să urmăresc logica de a rezolva o problemă pe care inițial susțineai că nu o ai în loc să te ridici de pe curul puturos și să verfici.

Singurul motiv pentru care încă tolerez această distribuție este faptul că oferă pachete binare decente precum update-uri la versiunea de PHP, spre deosebire de anumite distribuții Linux ce au version lock, partea de backports e aproximativ inexistentă, iar un 3rd party oferă mai puțină încredere. Iar ca sysadmin am și altceva de făcut înafară de presupunerea că aș sta să-mi compilez singur serviciile. O fac atunci când nu am alternativă. Chiar și versiunea de PHP din Ubuntu Lucid este jenant configurată, are bug-uri prin ini-uri, etc. Dar măcar ăia nu emit pretenții de distribuție “certificată”.

Având în vedere experiențele proaste cu Zend, slabe șanse să le cumpăr vreodată vreun produs sau să-mi iau “certificare” de la ei din moment ce distribuțiile lor “certificate” nu îndeplinesc un minim nivel al bunului simț.

Aplicaţia de plată este optimizată pentru Internet Explorer.
Vă recomandăm să nu utilizaţi alte browsere, deoarece tranzacţia de plată poate fi întreruptă înainte de finalizare.

Aceasta este metoda de a spune pe o limbă eufemistică: programatorii la care am apelat sunt niște incompetenți ce nu sunt în stare să implementeze un modul de plată și pe alte browsere. Iar cei de la Electrica Furnizare Transilvania Sud cu acel site jenant insistă pe această carte. De parcă toată lumea are Internet Explorer. Sau de parcă toată lumea care-l are chiar vrea să-l folosească.

Wikipedia ne anunță faptul că IE o cam ia la vale de ceva vreme.

Dar evident, niște dinozauri de la Electrica par să nu țină cont de acest aspect. Ba mai mult, tratează problema cu cel mai pur românism, pardon, indiferență, așa cum a fost tratat și mailul subsemnatului trimis prin formularul de contact, în legătură cu acest aspect.

Ultimul cui în grindă este faptul că aplicația de mai sus este scrisă-n PHP, ce între noi fie vorba rulează mai bine sub *nix. Dacă IIS 7.x (nu acel 6.0 folosit de către EFTS) e decent, PHP sub Windows nu mă convinge. Am mai zis-o și o mai zic. Atâta timp cât o să fie valabilă.

Update: am corectat puțin articolul în urma dialogului avut mai jos prin comentarii. Pe scurt, am calmat tonul frustrat abordat inițial, făra a altera complet forma inițială. Nu mai există sentimentul inițial pe care l-am avut atunci când am scris rândurile de mai jos. Până la urmă cei ce se ocupă de partea de comunicare din partea companiei Adobe își iau salariul pe merit din moment ce își “pierd” timpul cu un blog de buzunar ca al meu. Cu toate acestea, aștept rezultatele. Momentan discuția de mai jos rămâne la stadiul de vorbărie, iar eu ca programator nu cred în vorbe ci în software funcțional. De altfel pot trăi fără jocuri Flash pe telefon. Nu intru în sevraj în absența lor. De fapt nu mă joc pe telefon. Afirmația dădea doar o notă de dramatism situației expuse. Experiența web folosind PocketIE, Opera Mobile plus versiunea mobilă a Firefox (codename: Fennec, momentan Alpha stage) lasă de dorit în continuare în unele situații bine determinate unde o mână de CSS + (X)HTML nu pot compensa absența Flash Player. Urarea de la sfârșit rămâne. Înafară de Windows, Flash (încă?) e jale sau nu este deloc.

Era destul de evident faptul că va urma o replică de-a subsemnatului la adresa nesimțirii celor de la Adobe legată de lipsa Flash Player pe iPad. De altfel, ideea a mai fost discutată și de către Cătălin Nicolescu, dar eu iau o abordare diferită a problemei. Doar nu o să mă apuc să fac ‘rant’ pe aceeași temă.

Replica mea către Adobe ar fi: păi bine mă ipocriților, de ce nu plăngeți de faptul că eu pe Windows Mobile n-am Flash Player? Știu că există Flash Lite, dar eu nu l-am văzut rulând pe HTC-ul meu, ce apropo, Ș.T.I.E. multitasking, ca să fac referire și la produsul Apple ce nu mă interesează, dar care a generat discuția. Dacă vă doare atât de mult experiența utilizatorilor a unui X-produs pe web datorita produsului vostru proprietar, de ce nu văd un CAB pus la download ca să pot vedea și eu cum merge fleșul în PocketIE sau Opera Mobile? Sau să mă joc jocuri în fleș?

Nu e nici o diferență între ceea ce face Apple și ceea ce face Adobe. Adobe sunt totuși mai ipocriți. Ca să mă citez: același căcat împachetat altfel. Îi urez Flash-ului ce i-am urat acum câțiva ani: o deschidere mai mare spre platforme diferite, sau o moarte rapidă și foarte dureroasă.

Firebug este o unealtă indispensabilă activităților de dezvoltare web pe care le execut. Din păcate, actualizările se lasă cu urmări câteodată. Precum zice în titlu, am încercat combinația nefericită de mai sus. Buba stă în Firebug: 64 bit Firefox on Linux crashes with Firebug 1.5.0. Am mers pe firul epic al poveștii de pe issue tracker și mi-am resetat preferințele. Crash-ul reapare atunci când se reactivează tab-ul Net sau Console. Din nefericire, echipa Firebug aruncă vina către Ubuntu, desi eu mi-am făcut propriul build personalizat de Firefox, deci problema cred că zace undeva prin ceva bibliotecă livrată cu Ubuntu din moment ce versiunea de Firefox îmi aparține.

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.

M-am săturat de cod prost scris ca de mere pădurețe. Nu mă refer la cod nefuncțional sau cu bug-uri. Mă refer la metodologia copy-paste la care se apelează intensiv din când în când. După care apucă-te și modifică ceva pentru a adăuga chestii noi. M-am săturat de gândire non-DRY datorită căreia apuc să modific în 5 locuri și 3 fișiere pentru a pune o chestie amărâtă care să arate la fel peste tot. În concluzie, pe lângă defularea de mai sus, m-am hotărât să mai dau niște idei.

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.