Candybar – ia bomboanele din rezultatele testelor phpunit

Acum aprox. două săptămâni, în timp ce lucram la un repozitoriu hostat privat, mă gândeam ce fain ar fi să pot avea niște badge-uri în readme cum ar fi unul cu build status sau unul cu procentul pentru code coverage. Din păcate serviciile care generează astfel de badge-uri oferă serviciul gratuit doar pentru repozitoarele publice, unele chiar limitate la github.

De fapt informația din care se generează imaginea, e deja disponibilă în xml-ul generat de phpunit când rulezi testele, așa că aș putea la fel de bine să generez eu o imagine și să o pun în readme!

Așa am început proiectul Candybar, care își propune să facă rezultatele testelor cu phpunit mai ușor de digerat și integrat cu alte tool-uri. De fapt, proiectul este o colecție de comenzi, care face fiecare o treabă, și de asemenea puteți adăuga propriile comenzi destul de simplu. Release-ul 0.2, poate să facă următoarele:

    • coverage:badge: generează badge-ul pentru code coverage
    • license:badge: generează badge pentru licență
    • coverage:style: aplică stil la prezentarea html pentru code coverage generată de phpunit (phpunit --coverage-html tests/coverage/html)
    • readme:add-badges: adaugă badge-urile generate în readme

Mai multe detalii despre fiecare comandă puteți afla rulând vendor/bin/candybar help [commandă]

Dacă vreți să scrieți o comandă, copiați clasa ExampleCommand din DevLib/Candybar/Commands într-un folder al aplicației voastre. Va fi necesar să schimbați namespace-ul și argumentele/opțiunile ($arguments și $options) iar logica o implementați în metoda handle().
Odată ce funcționează așa cum doriți și o testați cu phpunit :) o includeți la lista de comenzi în candybar/config.php.

Dacă aveți sugestii, deschideți vă rog un issue pe pagina proiectului.

Imaginea a fost luată de pe saitul cofetăriei Minimal.

Bine v-am găsit

Am lipsit o perioadă destul de mare de pe blog, însă am de gând să scriu din nou.

Mi-am mutat acum blogul pe Amazon Web Services, iar momentan experimentez diverse metode a-mi reduce factura. Cel mai scump serviciu pare-se a fi RDS, dar îmi place ideea de daily snapshots așa că evaluez și alte strategii.

Mi-am pus de asemenea HTTPS, dar de la Cloudflare, care știu că nu e https end-to-end dar totuși mai bun decât deloc.

Am mai publicat făcut câteva gist-uri: unul care te poate ajuta să simulezi eb local dacă folosești Docker/containere și un script php care afișează tot ce-i trimiți în cererea HTTP, un fel de http request bin.

Cel mai simplu mod de a înțelege diferența dintre i++ și ++i

Pe principiul ”omul din greșeli învață”, am să vă propun azi să înțelegem diferența dintre expresia i++ și ++i . Sunt sigur că i++ e nelipsit din utilizarea zilnică și așa devine oarecum expresia de facto pentru a incrementa o variabilă, dar în același timp suntem ”păcăliți” să credem că este echivalentă cu i+1.

Exemplele de mai jos sunt în PHP, însă le puteți adapta foarte ușor la alte limbaje, eliminând în principiu $ din fața numelor variabilelor.

Dacă rulăm următorul cod:

Vom vedea pe ecran: a=0 iar b=2; Ceea ce nu prea are sens nu? De fapt b=2 oarecum e corect deoarece, am pus de două ori ++ pe lîngă i și deci a fost incrementat de două ori.

Hai să mai luăm un caz, o funcție recursivă:

Dacă executăm codul de mai sus, o să observăm că rulează la ifinit, și afișează în continuu ”Sunt la iteratia 1 din 100”. Se pare că în acest caz simbolul local al funcției $i, nu se incrementează. Dar dacă schimbăm codul astfel:

De această dată funcția va rula de 100 de ori.

Deci diferența dintre i++ și ++i e că expresia i++ incrementează valoarea lui i și returnează valoarea ne-incrementată pe când expresia ++i incrementează valoarea lui i și returnează valoarea incrementată.

Înainte să scrii cod…

Cred că o mare parte dintre problemele cu care se confrunta un proiect, în ceea ce privește implementarea, ar putea fi prevăzute și evitate înainte de a scrie vreo linie de cod, dacă s-ar parcurge, cu calm și poate o doză de detașament următorii pași:

Clarifică scopul proiectului

E un pas mare și important, însă tot pe atât de ignorat și ”pus la colț” când vine vorba de detalii tehnice. Eu vin din câmpul dezvoltării și programării de sait-uri  web, și uneori se întâmplă ca clientul să fie foarte încântat de design-ul prezentat și să semneze contractul pe loc. Însă peste câteva săptămâni, aproape de lansare să realizeze că design-ul saitului e total ”afon” de scopul acelui sait. Da da, putem discuta zile în șir și să ajungem la concluzia că scopul unui sait e ”să vândă”, dar chiar ai nevoie de un design plin de briz-briz-uri pentru asta? – vezi Amazon

Așadar, ca programator e esențial să înțelegi scopul proiectului la care lucrezi. Asta te va ajuta să împarți cerințele clientului în versiuni să-ți programezi milestone-urile și desigur data când o versiune stabilă va ieși pe poarta ”laboratorului”.

Eh, da o să fie și proiecte al căror scop va suna așa: ”Sait nou pentru compania X”, ”re-branding pentru agenția Y” – dar dacă proiectul nu are un scop bine definit, poate că nici nu merită investiția de timp. Deci un pont pentru managerii de proiecte: faceți tot posibilul să vă convingeți programatorii că lucrează la ceva important.

Vezi ce au făcut și alții

De multe ori poți avea impresia că ești pus în fața unei probleme unice. Și în 1% din cazuri așa e. Deci pentru o mare parte din cazuri există posibilitatea ca cineva să fi abordat deja aceeași problemă și chiar să o fi rezolvat. Poate cu mici nuanțe dar în definitiv, a găsit o soluție. Acuma nu mă refer aici la chestii ca trimiterea unui newsletter sau crearea unui slideshow. Acesta nu sunt probleme, ci sunt task-uri. Dacă ai înțeles bine scopul proiectului, atunci înseamnă că ai o imagine a formei lui finale, deci de ce să nu vezi cum au abordat alții acest tip de proiecte?

Citește documentația

O mare parte dintre bug-urile cu care se confruntă programatorii, sunt un rezultat al faptului că nu au citit toată documentația. Sau uneori chiar nu au citit-o deloc. De fapt uneori ajung să re-implementeze o funcție care era deja într-o librărie standard. Deci revizuirea documentației, chiar dacă plicticoasă e vitală, înainte de a scrie cod.

Supune design-ul la use-cases

Acest task ar trebui executat de un tester, sau o personană responsabilă de QA, dar dacă nu e nici un ins cu asemenea etichetă prin preajmă, tu ca programator ar trebui să o faci, înainte de a scrie cod. Sfatul meu ar e să o faci oricum.
Când programezi pentru web, un buton în plus sau în minus nu e așa de greu de adăugat, dar ce te faci dacă butonul respectiv trebuie să aibă text în 4 limbi, și cuvântul corespondent din estoniană are 24 de litere :P .  Da, se întâmplă așa des ca design-ul să ignore complet utilizatorul și să se axeze exclusiv pe a ”arăta bine”.

În consecință dacă nu-ți place să re-modelezi HTML și CSS (și mie îmi place tetrisul, dar uneori devine enervant :P ), supune design-ul la use-cases și dacă ceva ”dă cu virgulă” un project manager ar trebui să știe, înainte să începi să scrii cod.

Motoare de template-uri în Javascript

Zilele astea, mai mult de nevoie dar și de curiozitate am căutat un motor de template-uri în javascript. Probabil mulți sunteți familiarizat cu template engine-uri în PHP, cum e Smarty de exemplu. Eh, trebuie să vă spun că niciodată nu mi-au plăcut template engine-urile pentru PHP de vreme ce PHP însăși e un astfel de motor ;) .

Dar template engine-urile în Javascript chiar încep să îmi placă. De ce?

Desigur nu sunt o alegere viabilă pentru un sait pe internet, care trebuie să aibă link-uri către pagini individuale pe care motoarele de căutare să le poată parsa, de vreme ce motoarele de căutare nu înțeleg  javascript. Da googlebot știe să citească și PDF-uri sau SWF-uri dar javascript nu.

Însă cred că sunt cea mai bună alegere pentru un sait într-un intranet, sau unul cu acces limitat la conturi (utilizator/parolă).   Asta pentru că un astfel de engine îți permite să iei doar datele de care are nevoie clientul de pe server, nu și markup-ul iar template-ul să-l iei dintr-un fișier static în timp ce prelucrarea lui și înlocuirea variabilelor se face pe mașina clientului, care e foarte probabil să aibă mai mulți RAMi disponibili decât serverul tău. Și tu ca programator nu mai trebuie să înveți Smarty dacă știi deja PHP/JavaScript.

Partea cea mai bună e că aveți de unde alege, iar unul dintre inițiatorii curentului este chiar John Resig :

Desigur lista ar putea continua, dar acestea sunt cele pe care le iau eu în considerare bazate pe caracteristicile de compilare și caching. Dar sunt curios ce preferințe aveți și voi?