printf(" SaltwaterC ");

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.

Ăștia de la MSI fac niște plăci de bază execelente atâta timp cât nu trag nimic la măsea. Din păcate, plăcile precum cea pomenită în titlu au un mod de-a dreptul cretin de a face update la BIOS.

Metode oficiale:

- Iei una bucată startup disk (floppy de ăla), pui imaginea ROM și aplicația de actualizate pe o partiție FAT, butezi în DOS și flash-uiești BIOS-ul. FAIL. N-am chef de floppy – nici n-am mai folosit vreunul de ani buni.

- Pentru cei fără partiții FAT (aka majoritatea în secolul 21), iei una bucată startup disk de Windows 98 sau Windows ME (WTF?!) plus una bucată floppy disk pe care se alfă aplicația de actualizare și imaginea ROM. Butezi de pe startup, actualizezi de pe al doilea disk. FAIL. Double FAIL.

Metode semi-oficiale (nesuportate de MSI):

- Îți faci cont pe forumurile MSI. Este trist pentru că nici măcar nu poți citi thread-urile de update făra cont. Trist și inutil. Există vreo două aplicații ce crează stick-uri USB pentru boot. Una dintre aplicațiile menționate știe chiar live update. Partea jenibilă: îți trebuie o placă MSI în sistem ca să poți face un stick boot-abil. WTF? FAIL.

Metoda subsemnatului:

- În primul rând n-am Windows pe mașina cu pricina și nici nu cred că o să am vreodată. Este strict pentru dezvoltare și altceva înafară de Ubuntu nu a văzut de la geneză și până în prezent. Floppy nu am de gând să îmi pun pentru un f%t%t de BIOS update. Și nici nu am de gând să caut două disk-uri. În plus sunt destul de fragile. Ca să fac un stick boot-abil trebuie să rulez pe o mașina cu placă de bază MSI ceea ce este inutil și enervant. N-o să pun Windows doar pentru că așa vrea dezvoltatorul aplicației respective. Da, actualizările MSI sunt Windows-centric. Aș fi dat multe pentru acel ASUS EZ Flash 2 cu inerfață grafică, accesibil din BIOS. Deși ASUS Update de Windows suge. Vineri a făcut praf un P5B Deluxe – a șters chip-ul, dar a ‘uitat’ să-l mai scrie. După care a refuzat orice interacțiune. Dar măcar suportul din hardware e impecabil. În concluzie a trebuit să fiu inventiv.

Pas 1 : Se ia una bucată UNetbootin. Are atât versiune de Windows cât și versiune de Linux. Pentru Ubuntu se găsește repository PPA, deci instalarea a fost după metoda standard după ce s-a adăugat noul repo în config.

Pas 2: Se ia una bucată stick USB formatat FAT32 și se infige în portul cu pricina. Se lansează UNetbootin. Pentru că pe net se găsesc doar tutoriale complicate despre cum se instalează FreeDOS pe USB, am ales UNetbootin. Are interfața cu dificultate apropiată de nivelul de percepție al unui retard.

Pas 3: se alege ca distribuție FreeDOS din primul drop down (da, nu știe doar Linux) – și versiunea 1.0 (singura disponibilă). Jos se alege drive-ul USB pe care să-l scrie (în cazul în care detectează mai multe) – OK. Ar trebui să downloadeze FreeDOS de pe Web și să-l pună pe stick.

Pas 4: Se desface arhiva în care se gasește imaginea ROM și aplicația de actualizare. Se pun pe stick-ul USB menționat anterior. Reboot.

Pas 5: Se scormonește prin BIOS pentru a putea face USB boot. Opțional se poate sări peste BIOS. F11 în timpul POST ar trebui să arate meniul în care se alege BOOT device-ul. Așa e la P35 Neo2 FR. La altele e Esc în timpul POST.

Pas 6: Se alege opțiunea 3 din meniul FreeDOS. Nu e un meniu standard (pentru cei familiarizați cu FreeDOS) precum cel din imaginea ISO. Opțiunea 3 e un live edition cu highmem suport, blah, blah, blah, yada, yada, yada. Se încarcă FreeDOS, după care se tastează în shell B:. Da, mi-a luat ceva să mă prind de faptul că B: este de fapt drive-ul USB propriu zis. În A: se montează live filesystem-ul FreeDOS.

Pas 7: Se rulează aplicația de actualizare ce primește ca argument fișierul de update. În cazul subsemnatului:

B:\> Afud408.exe A7345IMS.1A0

Se așteaptă până își termină toate mizeriile. Reboot. Ar fi bine ca sistemul să nu crape în timpul update-ului. Exclus OC și alte mizerii. Nu strică un UPS.

După reboot BIOS-ul o să dea un checksum bad la CMOS și e normal pentru că imaginea ROM e diferită. F1 pentru a intra în setup. Se va vedea faptul că s-a instalat ultima versiune și se pot pune vechile opțiuni. Succes.

Din plictiseală sau datorită faptului că în mod repetitiv m-am tot lovit de Zend Server CE printre plimbările mele pe Web, m-am decis să renunț la versiunea implicită ce vine în reopository-ul sistemului de operare de pe mașina de dezvoltare (Ubuntu Hardy) și să pun în schimb Zend Server. Zis și făcut. Țac, țac, țac – zgomot de taste – instalarea a mers ca unsă.

Din păcate, ocazional, dezvolt și aplicații ce au nevoie de acces la funcția mail(), funcție ce altceva înafară de FALSE aka FAIL nu știa să returneze. Verific Postfix-ul – rula de zor. Deci nu era bubă de MTA. NU, nu suport Sendmail. Iau o porție de copypasta de pe php.net, pun totul întrun fișier php, rulez în shell – surpriză:

sh: -t: not found

Mă scarpin cu o mână în cap și cu cealaltă în dos. Ceva îmi pute – și nu era de la a doua mână. Încep să sap pentru a afla ce pește prăjt au făcut cei de la Zend cu php.ini de încearcă să ruleze aplicația ‘-t’. Crăp un output de phpinfo() in Firefox și mă luminez:

sendmail_path Local Value: -t -i Master Value: -t -i

Erm, WTF Zend? Casc vinovatul (/usr/local/zend/etc/php.ini) și caut linia cu pricina ce bine mersi era comentată. Cică în mod implicit ar trebui să fie ‘sendmail -t -i’, dar se pare că opțiunea nu este hardcodată ca atare. Soluția e la mintea cocoșului:

sendmail_path = sendmail -t -i

Restart la Apache2. Merge? Merge. Shell-ul este fericit deasemenea.