Claudiu Persoiu

Blog-ul lui Claudiu Persoiu


Magia programarii

without comments

Cred că uneori apar momente în viața in care simt nevoia sa impartasesc cateva dintre cele mai bine păstrate secrete ale meseriei.

Iar astazi voi destainui tainele magiei programarii.

Știu ca sunt mulți începători care cred ca programarea consta în a scrie cod și exercițiu, în timp ce alții au impresia ca este vorba doar despre un fel de vraji magice care trebuie incantate ca să faci lucrurile să meargă.

Am decis ca a venit momentul sa rup tăcerea și să clarific lucrurile o dată pentru totdeauna. Dacă nu voi mai scrie prea mult după aceasta postare este pentru ca voi deveni un fugar care încearcă să scape cu viață din ghearele programatorilor care s-au straduit atata timp ca acest secret sa nu iasa la iveala.

Secretul este magia! Vrajile sunt bine ascunse în cărțile de programare, în tutoriale, adanc in cod și mascate de fraze cum ar fi “Refactoring” și “Code compilation”. Toate acestea ca sa iti dea impresia ca programarea e doar ceva foarte dificil de inteles, imposibil chiar pentru afoni, în timp ce secretul stă de fapt in vrajile secrete.

Situatia programarii e similara cu a culturismului. Culturistii merg la sală doar ca să se laude cu muschii lor, toata lumea stie asta. Ei au de fapt muschi pentru ca iau steroizi și prafuri proteice, sala e doar un loc de afisat muschii, nu de facut muschi. Și nu te-au pacalit niciodata, de asta nu mergi la sală.

Si ai observat cum te ia somnul cand citesti documentații oficiale? Este din pricina mecanismelor de protecție pe care le au. Genereaza somnolenta ca sa te lasi pagubas si sa trăiești cu falsa impresie că programarea este plictisitoare.

Din acest motiv unele persoane nu sunt capabile sa inteleaga programarea, de fapt nu cunosc vrajile si cum sa le aplice ca sa facă codul să meargă!

Te-ai întrebat uneori de ce nu toate răspunsurile de pe Stackoverflow funcționează? Unele sunt lăsate de vrajitori ai întunericului, al caror scop este sa sadeasca confuzie printre neinițiați! Doar vrajitorii experți pot combina mai multe răspunsuri de pe Stackoverflow și le pot face sa funcționeze împreună, aplicand magia doar de ei stiuta.

Acesta a fost tot secretul, de asta unii știu programare iar alții nu. În nici un caz nu e vorba ca unii studiaza mai mult și exersează chiar și mai mult și de multe ori mai scriu tot felul de aplicații fără aplicabilitate practica, doar ca sa vadă dacă si cum funcționează un anumit fragment de cod, NU! Este vorba de magie si vraji! Acum ca stii asta, nu mai trebuie sa pierzi atata timp cu tutoriale si cursuri întregi, sau, în cazuri duse la extrem, sa cumperi și să citești cărți!
Pană aici cu notiunile astea prostesti, a venit vremea sa fie demascate!

Iar acum o sa fiu ocupat o vreme: va trebui sa fug pentru a scăpa cu viață de marii magi ai programării!

Poate te întrebi dacă acesta este un pamflet, ei bine… ar putea fi… dar cine sunt eu sa judec?

Written by Claudiu Persoiu

25 June 2020 at 7:12 PM

Posted in Diverse

Tagged with

Magento2 si crudul adevar

without comments

Folosind Magento de ceva timp, pot spune ca platforma s-a schimbat mult de-a lungul timpului și vreau sa impartasesc câteva păreri personale legate de ea.

Cum a invatat Magento 2 din trecut cum sa facă greșeli noi noute

M-am intalnit prima oară cu platforma Magento în 2011, iar, in acel moment, știam despre ea doar că era bazată pe Zend Framework 1 și (în mod evident) ca se ocupă cu e-commerce.

Eu veneam din universul framework-ului Symfony, unde exista documentație din belșug, o comunitate foarte mare, și care avea o implementare solidă. Acestea se intamplau de-abia pe vremea Symfony 1, Symfony 2 de abia aparuse.

Prin comparatie, Magento nu avea aproape deloc documentație, comunitatea era într-un stadiu incipient, și implementarea nu ducea lipsa de bug-uri. Încă din primele zile la noul job am văzut mulți colegi care făceau debugging adanc in Core, eram perplex, eu aproape că nu avusesem niciodată nevoie sa fac debugging în Core-ul de Symfony, darămite să mai găsesc și bug-uri.

Unii pot argumenta ca Symfony este un framework, pe cand Magento este o platforma, iar eu sunt de acord ca acesta este un argument cel puțin la fel de solid ca un porcusor de guinea.

Motivul pentru care s-a ajuns la aceasta situatie e simplu: nu se așteptau ca platforma sa aiba atat de mult success; dar a avut, și motivul a fost simplu – a fost cam singura platforma din universul PHP care fusese construită sa fie modulară, punct! Mai erau și alte platforme, dar în mod sigur nu la fel de versatile, pline de functionalitati și modulare precum Magento.

În perioada următoare au investit mult timp și efort pentru a construi o documentație ampla pentru Magento1, s-au concentrat pe calitate, pe stabilitate imbatabilă, și toate acestea au fost completate cu un suport de excepție oferit partenerilor de tip enterprise!

Te-am prins! Nu, nu au făcut asta! Documentatia pentru M1 a fost mereu sărăcăcioasă și de foarte slabă calitate. Cea mai buna resursa a fost cursul “Fundamentals of Magento Development” de Ben Marks, o carte (despre care nu-mi pot exprima o opinie pentru ca nu am citit-o), niște postări pe bloguri personale și ale companiilor care lucrau cu platforma și, nu în ultimul rand, multe întrebări și răspunsuri pe StackOverflow. Toate acestea au fost combinate cu un suport deosebit de prost pentru clienții enterprise, răspunsuri lente și de o calitate îndoielnică și, peste toate astea, o varietate de bug-uri în Core. Nu era ceva ieșit din comun sa gasesti implementări atipice sau făcute doar pe jumate alături de bug-uri în Core. Dar Core-ul era suficient de simplu, așa ca, folosind doar Xdebug și multă răbdare, totul era mai mult sau mai puțin rezolvabil.

Fix-urile de la suport erau intamplari aproape mitice. Dacă nu aveai chef sa repari un bug, sau pur și simplu nu aveai chef de munca, puteai deschide un ticket și de cele mai multe ori dura cateva zile sau chiar saptamani pana cand primeai un răspuns corespunzător. Până în acel moment, de multe ori problema era deja rezolva și (în unele cazuri) soluția chiar trimisă celor de la suport ca sa poată repara problema si în Core..

Și așa apare Magento 2

Cu povara popularității care a incurajat dezvoltarea Magento 1, Magento 2 a venit sa salveze situatia.

A durat mult timp pana cand Magento 2 a fost gata, și cred ca asta ar putea sa fie în sine o poveste, dar de data aceasta au fost luate unele măsuri pentru a evita problemele pe care le-a avut prima versiune.

Sa vedem unele din probleme platformei:

  • functionalitatea claselor nu puteau fi extinsă decât prin suprascriere;
  • partea de frontend era bazată exclusiv pe framework-ul Prototype.

Existau multe alte probleme, dar cred ca acestea erau printre cele mai relevante.

Și sa vedem cum Magento 2 a reușit sa rezolve toate aceste probleme

Este de bun augur sa începi cu ceva pozitiv, așa ca voi începe cu documentatia, Magento2 avea documentație încă de la început și era atat utilă, cat și bine făcută!

Legat de suprascrierea claselor, au fost implementate două abordări:

  • implementarea a dependency injection (din Symfony);
  • implementarea pluginurilor folosind Interceptor pattern.

Dependency injection ajuta foarte mult la înlocuirea de clase și functionalitati, iar plug-in-urile ajuta la extinderea sau modificarea functionalitatilor printr-o metoda neinvaziva. Înainte de plug-in-uri, doar observerele ofereau posibilitatea de a modifica date într-o maniera neinvaziva, marea problema fiind ca (în multe cazuri) pur și simplu nu erau observere peste tot unde aveai nevoie de ele.

Din pacate, aceasta abordare a crescut cu mult complexitatea. Dacă în M1 puteai pune un breakpoint și apoi urmareai stacktrace-ul ca sa vezi ce metode modifică ce anume, acum… era pur și simplu mult mai complex, pentru ca fiecare metoda clasa interceptor declanșează mecanismul de plug-in. Fiecare plug-in poate sa declanșeze o acțiune înainte, după, sau în jurul metodei și poate chiar sa prevină metoda din a fi apelată. Atunci cand functioneaza, abordarea este mult mai elegantă, dar atunci cand nu funcționează este mult mai dificil de făcut debugging.

Într-o intorsatura dramatica de situație, nu toate clasele au fost implementate corespunzător în Core. Vezi tu, atunci cand Magento 2 a fost lansat, au fost necesare multe compromisuri, iar multe module din Core a trebuit sa fie “făcute sa mearga” în noul framework. Mai tarziu, cand toata lumea aștepta sa se facă curățenie… momentul nu a mai venit, iar motivul a fost simplu: de ce sa repari Core-ul cand riști să strici compatibilitatea cu modulele deja existente?

Acest lucru i-a făcut pe dezvoltatorii de Core sa sugereze sa folosesti direcția sugerată de ei in ghid, sa nu iei implementarea din Core drept exemplu: fa cum spunem noi, nu cum facem noi.

Frontend-ul a fost reparat și mai bine! Poate unii se întreabă ce este “prototype” și de ce cineva întreg la cap ar alege așa ceva? În vremurile in care Magento 1 a fost creat avea mai mult sens, pentru ca exista o serie intreaga de librării populare, în principal: jQuery, Prototype și MooTools. Erau mult mai multe pe langa acestea trei, dar acestea erau printre cele mai populare. Era un război între jQuery și Prototype, așa cum este in prezent cel dintre React, Angular și Vue. jQuery avea o abordare nouă care părea să semene chiar cu un limbaj nou, în timp ce Prototype a mers pe extinderea capabilitatilor browserului într-o maniera mai discreta. Acum știm cine a castigat, dar pe atunci nu era la fel de evident. Ca o mica nota, și eu eram fan Prototype la vremea respectivă.

Echipa Magento 2 a realizat în timp ca a făcut o gresala si, ca sa o repare, au promis ca vor avea o abordare mai flexibilă. Noua abordare mai flexibilă nu a mai folosit libraria Prototype, iar în locul ei au fost incluse: jQuery, Knockout.js și Require.js, asta doar la nivelul superior, fără sa luăm toate celelalte dependinte in considerare.

Ideea era o mai buna separare între frontend și backend, pentru a putea face o aplicație de frontend complet nouă. Dar, la fel ca mai înainte, acest plan nu a fost finalizat, iar acum este doar un sistem foarte complicat, parțial separat, parțial aplicație “single page” și parțial… “multi page”, implementat folosind o varietate de stiluri. Iar aceasta este doar pe store front, pe store backend este puțin diferit, un sistem mai complex format din fișiere xml, phtml, html și js. Ca backend developer, pot spune sincer ca este mult mai dificil decât înainte sa faci debug (sau doar sa înțeleg cum funcționează părți din frontend).

Poate cea mai dificila parte este cea de generare de griduri folosind XML, debugging-ul poate fi facut doar cu mari dificultati, iar daca gresesti ceva nu primești niciun warning, trebuie sa gasesti clasa care construiește efectiv gridul și sa vezi daca apare acolo vreo excepție, ceea ce nu este deloc o soluție evidenta…

Și, evident, totul este mult mai lent, din pricina noilor “abordări inginerești”. Cand tot codul intermediar este generat, legăturile facute către resursele statice și totul este setat în modul producție, nu este foarte rapid, dar nu este nici groaznic de încet. Dar atunci cand nu ai cache, nu ai făcut deploy la resurse statice, și mai ești și în modul developer, este groaznic de încet, poate dura minute bune pentru a incarca o simpla pagina de produs! Este pur și simplu ridicol! Dacă mă întrebați pe mine, nu este un sistem de operare, sau un joc video, este un magazin virtual, nu exista niciun motiv pentru care sa dureze 5 minute pentru a afișa o pagina, lucru care se intampla chiar si in cazul in care nu ai multe module adiționale instalate.

Trebuie avut în vedere ca Magento 2 nu a venit cu o multitudine de noi functionalitati, majoritatea funcționalitatilor principale erau și în M1, doar ca au fost mai “inginerizate”, asa ca acele 5 minute de generare de cod, generare de legături și alte magii pe care le mai face, nu vin de la adaugarea de functionalitati noi, doar refactorizari ale sistemului vechi.

Magento Cloud

Magento a oferit și o soluție de Cloud, nu știu dacă-l mai oferă, nu-mi pasa prea tare, nimănui nu pare să-i mai pese, în speță pentru ca nu era ce își dorea lumea.

Oamenii vor lucruri simple: ai o aplicație, o urci în nori și începe sa ploua cu bani. Cam asta este tot ce ar trebuie sa fie – mai puține griji.

Demandware, care nu are un core open source, face ceva de acest tip. Nu ai la fel de mult control, dar nu tu te ocupi de website-ul tău, zeii din nori se ocupă (suna mai bine în engleza)! Dezvoltatorul doar dezvolta, lui nu ar trebui să-i pese ce magii fac cei de la operations, pentru ca el nu e ops, el e dev!

Magento Cloud încerca sa facă asta, speranta era ca tu doar trimiti caracatita în norișor și niște ops foarte inteligenți o sa scaleze pentru tine! Dar nu era deloc așa, nu era deloc ușor, si nici rapid. Si, peste toate acestea, au inceput sa apara hosting providers cu soluții specializate pe Magento care făceau o treaba mai buna la scalare decât hostingul oficial, lucru care mi se pare de necrezut.

Dar sa incheiem intr-o nota pozitiva

Sub toate aceste neajunsuri, exista totuși un Core interesant. Sunt o mulțime de functionalitati foarte inteligente care au făcut platforma atat de populara. Acum exista și teste, deci poți face chiar și TDD.

Chiar și cu atatea provocări (supra)inginerești, exista totuși destui programatori pasionați care sunt gata sa le depaseasca.

Sunt și multe unelte dezvoltate de comunitate pentru a acoperi din lipsuri, cum ar fi problema cu numarul foarte mare de fișiere care trebuie generate pentru un model, sau MSP_DevTools care ajuta la debugging pe frontend, sau n98-magerun2 care te ajuta sa lucrezi cu cronuri și multe, multe altele.

Și, nu în ultimul rand, încă sunt mulți programatori straluciti și pasionați care sunt gata să găsească un mod de a dezvolta și scala aplicatii e-Commerce bazate pe Magento pentru a face vanzari încă o zi!

Written by Claudiu Persoiu

31 March 2020 at 4:24 PM

Posted in Magento,PHP

Tagged with , ,

Un pic de PHP, Go, FFI si atmosfera de sarbatori

without comments

Ah, atmosfera de sarbatori…

Inspirat de o postare in Perl Advent, m-am gandit ca ar fi interesant sa vedem un exemplu cu PHP si Go. Vreau sa mentionez ca acest blog este inspirat intr-o buna masura din postarea mentionata anterior.

Sa presupunem ca vrei sa-i urezi cuiva sarbatori fericite folosind viteza limbajului Go, dar aplicatia ta este scrisa in PHP, ce poti face?

In lumea PHP ar fi momentul ideal, deoarece noua versiune PHP 7.4 vine cu “Foreign Function Interface” (FFI pe scurt).

Echipat cu aceasta noua arma, am instalat PHP 7.4 si am trecut la treaba.

Sa incepem cu super incredibila urare din Go, sa creem fisierul “greeting.go”:

package main
 
import (
   "fmt"
)
 
func main() {
   WishMerryChristmas();
}
 
func WishMerryChristmas() {
   fmt.Println("We wish you a Merry Christmas!");
}

Si acum sa-l rulam:

$ go run greeting.go

Ar trebui sa afiseze:

We wish you a Merry Christmas!

Pana aici e super! Este foarte rapid, frumos si tot ce mai trebuie, dar noua ne-ar trebui sa fie un serviciu, deci sa vedem cum o sa arate in acest caz:

package main
 
import (
   "C"
   "fmt"
)
 
func main() {}
 
//export WishMerryChristmas
func WishMerryChristmas() {
   fmt.Println("We wish you a Merry Christmas!")
}

Dupa cum se poate vedea, exista cateva diferente:

  • am importat si libraria “C”,
  • am scos apelul functiei din main()
  • am adaugat un comentariu pentru exportul functiei.

Pentru compilare se ruleaza astfel:

$ go build -o greeting.so -buildmode=c-shared

De mentionat este faptul ca aceasta comanda trebuie rulata de fiecare data cand fisierul Go este modificat.

Rezultatul ar trebuie sa fie compus din doua fisiere:
“greeting.so” si “greeting.h”.

Fisierul de header “greeting.h” contine tipurile de date si definitile functiilor. Daca ai mai lucrat cu C, esti probabil familiarizat cu acest fel de fisiere. In mod normal, tot ce trebuie sa mai facem acum este sa importam fisierul header folosind FFI si sa apelam functia!

Pentru asta am creat un fisier cu numele “greeting.php”:

<?php
$ffi = FFI::load("greeting.h");
$ffi->WishMerryChristmas();

Pare suficient de simplu, tot ce trebuie sa mai facem acum este sa-l rulam folosind comanda:

$ php greeting.php 
PHP Fatal error:  Uncaught FFI\ParserException: undefined C type '__SIZE_TYPE__' at line 43 in /home/claudiu/php-go/greeting.php:3
Stack trace:
#0 /home/claudiu/php-go/greeting.php(3): FFI::load()
#1 {main}

Next FFI\Exception: Failed loading 'greeting.h' in /home/claudiu/php-go/greeting.php:3
Stack trace:
#0 /home/claudiu/php-go/greeting.php(3): FFI::load()
#1 {main}
  thrown in /home/claudiu/php-go/greeting.php on line 3

Nu e tocmai urarea la care ma asteptam…

Dupa ce am sapat destul de intens, am gasit asta intr-o pagina de manual:
C preprocessor directives are not supported, i.e. #include, #define and CPP macros do not work.

Din acest motiv, se pare ca nu vom putea folosi fisierul de header, sau cel putin eu nu am gasit o metoda clara.

Partea buna este ca putem folosi FFI::cdef() care permite sa specificam definitia functiilor. Daca te-am pierdut pe drum, ce incerc de fapt sa fac este sa-i spun PHP-ului care sunt definitile funcțiilor pe care vreau sa folosesc din fisierul “greeting.so”.

Noul cod va fi:

<?php
$ffi = FFI::cdef("
void WishMerryChristmas();
", __DIR__ . "/greeting.so");

$ffi->WishMerryChristmas();

Iar daca rulam acum:

$ php greeting.php 
We wish you a Merry Christmas!

Am progresat mult, iar serviciul isi face treaba foarte bine!

Adaugarea unui parametru int

Urarea arata foarte bine si e super rapida, dar ar fi si mai frumos sa putem specifica de cate ori sa o afisam.
Pentru a face asta, trebuie modificata functia din fisierul “greeting.go”, adaugandu-i un parametru cu numarul afisarilor dorite:

//export WishMerryChristmas
func WishMerryChristmas(number int) {
   for i := 0; i < number; i++ {
       fmt.Println("We wish you a Merry Christmas!");
   }
}

Trebuie rulata din nou comanda de compilare ca mai devreme.

In PHP trebuie sa modificam definitia functiei. Pentru a vedea ce trebuie modificat putem sa ne inspiram din fisierul “greeting.h”. Noua definitie a functiei in fisier este:

extern void WishMerryChristmas(GoInt p0);

“GoInt”? Ce magie mai e si asta? Daca ne uitam in fisier gasim urmatoarele definitii:

...
typedef long long GoInt64;
...
typedef GoInt64 GoInt;
...

De unde concluzionam ca GoInt este de fapt un long.

Cu aceste noi descoperiri putem modifica fisierul PHP in:

<?php
 
$ffi = FFI::cdef("
void WishMerryChristmas(long);
", __DIR__ . "/greeting.so");
 
$ffi->WishMerryChristmas(3);

Il rulam din nou si vedem:

$ php greeting.php 
We wish you a Merry Christmas!
We wish you a Merry Christmas!
We wish you a Merry Christmas!

Ah, incepe sa se simta spiritul sarbatorilor!

Adaugarea unui parametru string

Sa afisam o urare de mai multe ori este destul de dragut, dar ar fi mai dragut sa adaugam si un nume.

Noua functie devine:

//export WishMerryChristmas
func WishMerryChristmas(name string, number int) {
   for i := 0; i < number; i++ {
       fmt.Printf("We wish you a Merry Christmas, %s!\n", name);
   }
}

Nu uita sa compilezi, iar apoi vom trece la partea interesanta.

Daca ne uitam in fisierul “greeting.h”, noua definitie a functiei este:

extern void WishMerryChristmas(GoString p0, GoInt p1);

Stim deja ce este GoInt, dar GoString este un pic mai complicat. Dupa mai multe substituiri am ajuns la structura:

typedef struct { char* p; long n } GoString;

Este practic un pointer catre o lista de caractere si o dimensiune.

Asta inseamna ca, in fisierul PHP, noua definitie o sa fie:

$ffi = FFI::cdef("
typedef struct { char* p; long n } GoString;
typedef long GoInt;
void WishMerryChristmas(GoString p0, GoInt p1);
", __DIR__ . "/greeting.so");

p0 si p1 sunt optionali, dar i-am lasat ca sa semene mai mult cu definitia din fisierul de header.
Similar, GoInt este practic un long, dar l-am lasat acolo din acelasi motiv.

Construirea unui GoString din PHP a fost un pic mai complicata. Principala cauza a fost ca nu am gasit un mod sa fac un “char *” si sa-l initializez in acelasi timp. Alternativa mea a fost sa fac un array de “char” si apoi sa-i fac cast, dupa cum urmeaza:

$name = "reader";
$strChar = str_split($name);
 
$c = FFI::new('char[' . count($strChar) . ']');
foreach ($strChar as $i => $char) {
   $c[$i] = $char;
}
 
$goStr = $ffi->new("GoString");
$goStr->p = FFI::cast(FFI::type('char *'), $c);
$goStr->n = count($strChar);
 
$ffi->WishMerryChristmas($goStr, 2);

Sa-l incercam:

$ php greeting.php 
We wish you a Merry Christmas, reader!
We wish you a Merry Christmas, reader!

Succes!

In aceasta faza, mi-ar placea sa mut crearea de GoString intr-o functie separata, de dragul lizibilitatii codului.

Noul cod rezultat este:

$name = "reader";

$goStr = stringToGoString($ffi->new("GoString"), $name);

$ffi->WishMerryChristmas($goStr, 2);

function stringToGoString($goStr, $name) {
    $strChar = str_split($name);

    $c = FFI::new('char[' . count($strChar) . ']');
    foreach ($strChar as $i => $char) {
        $c[$i] = $char;
    }
    
    $goStr->p = FFI::cast(FFI::type('char *'), $c);
    $goStr->n = count($strChar);

    return $goStr;
}

Si acum sa-l incercam:

$ php greeting.php 
We wish you a Merry Christmas, ��!
We wish you a Merry Christmas, ��!

Hopa, nu e tocmai bine… pare ca afisam niste memorie reziduala. Dar de ce?

Cautand in documentatia FFI::new am gasit un al doilea parametru, “bool $owned = TRUE”.

Whether to create owned (i.e. managed) or unmanaged data. Managed data lives together with the returned FFI\CData object, and is released when the last reference to that object is released by regular PHP reference counting or GC. Unmanaged data should be released by calling FFI::free(), when no longer needed.

Asta inseamna ca atunci cand intoarcem rezultatul functiei, GC-ul din PHP dezaloca memoria pentru variabila cu string-ul. Este destul de probabil ca acesta sa fie un bug, dar exista o solutie foarte simpla, trebuie doar sa adaugam “false” la crearea de array:

$c = FFI::new('char[' . count($strChar) . ']', false);

Sa incercam din nou:

$ php greeting.php 
We wish you a Merry Christmas, reader!
We wish you a Merry Christmas, reader!

Si functioneaza!

Concluzie

Poate ca rulatul din PHP a unei librarii scrisa in Go nu este atat de simplu precum importul unui fisier de header, dar cu putina rabdare nu este nici foarte dificil! Marele avantaj este ca librariile scrise in Go, sau in orice alt limbaj de programare care permite acest lucru, pot fi folosite din PHP fara sa mai trebuiasca reimplementarea lor!

Si, încheind pe aceasta nota pozitiva, va urez sarbatori fericite!

Written by Claudiu Persoiu

23 December 2019 at 1:37 PM

Posted in GO,PHP

Tagged with , , ,

Cum sa folosesti Xiaomi Air Conditioning Companion in Home Assistant in doar de 20 pasi usor de urmat!

without comments

Xiaomi Air Conditioning Companion si Home assistant

Pasul 1:

Cumpara un Xiaomi Air Conditioning Companion fara sa te uiti prea in detaliu cat de bine se integreaza cu Home Assistant.

Pasul 2:

Realizeaza ca, în China, priza de 16A este diferita de cea de 10A.

Pasul 3:

Da-ti seama ca nimeni nu vinde in Romania adaptoare de la 10A la 16A pentru China.

Pasul 4:

Cumpara un stecher de 16A din China.

Pasul 5:

Asteapta cam 2 luni sa ajunga din China atat adaptorul cat si dispozitivul.

Pasul 6:

Realizeaza ca nimeni nu vinde nici adaptor pentru priza la schuko.

Pasul 7:

Gaseste singurul comerciant care vinde modul de priza pentru priza chinezeasca, probail din greseala

Pasul 8:

Asteapta sa te caute comerciantul si sa-ti spuna ca dureaza cam o luna sa livreze modulul.

Pasul 9:

Asteapta cam o luna ca sa fie livrat modulul.

Pasul 10:

Instaleaza modulul de priza si stecherul.

Pasul 11:

Conecteaza Xiaomi Air Conditioning Companion la priza si aerul conditionat la Companion pentru prima data.

Pasul 12:

Realizeaza ca Xiaomi Mi Home App a fost updatat intre timp si nu exista niciun tutorial functional care sa-ti arate cum sa obtii parola pentru Home Assistant.

Pasul 13:

Gaseste un mod de a lua parola, dupa multe incercari.

Pasul 14:

Adauga parola de la pasul anterior in Home Assistant si constata ca singurul lucru pe care-l poti face din Home Assistant este sa suni alarma si sa-i schimbi volumul.

Pasul 15:

Gaseste modulul xiaomi_airconditioningcompanion si realizeaza ca de fapt nu aveai nevoie de parola gatewayului.

Pasul 16:

Fa downgrade la Xiaomi Mi Home App si obtine tokenul urmarind instructiunile de la: https://www.home-assistant.io/integrations/vacuum.xiaomi_miio#retrieving-the-access-token

Pasul 17:

Da-ti seama ca nu ai versiunea potrivita de Hass.io pentru a folosi modulul.

Pasul 18:

Migreaza la Hassbian de la Hass.io

Pasul 19:

In sfarsit, instaleaza extensia si seteaza modulul.

Pasul 20:

Singurul lucru care mai ramane de facut este sa te bucuri de confortul oferit de controlatul aerului conditionat de la cativa metri distanta, fara a avea nevoie de telecomanda!

Written by Claudiu Persoiu

13 October 2019 at 7:47 PM

Posted in Diverse

Tagged with

Cum folosesc local Magento2 folosind Docker si Docker Compose

without comments

Nota

Trebuie mentionat ca aceasta solutie este adaptata nevoilor mele, deci exista posibilitatea ca ele sa nu se suprapuna perfect cu nevoile tale. Totusi nu-ti face griji, totul este pe GitHub, asa ca poti lua doar ce ai nevoie.

Vreau sa mai adaug si ca acesta nu este blog de genul “ai folosit total gresit Magento2 cu Docker pana acum, uite cum se face de fapt”, eu doar vreau sa-mi impartasesc experienta. Probabil ca nu este cea mai buna solutie pentru toata lumea, dar cred ca orice persoana interesata de subiect poate gasi ceva util aici.

Intro

De aproape 2 ani folosesc Magento2 in containere Docker. Am facut asta si inainte, dar trebuie sa recunosc ca a fost pentru ca a trebuit, nu pentru ca am vazut calea cea buna, adica avantajele Docker.

Dupa cum probabil ai aflat deja, Magento2 nu este tocmai o aplicatie micuta si usoara, este chiar foarte greoi, lucru vizibil in special in timpul dezvoltarii.

Daca l-am compara cu un VM clasic, cu Docker ai avea in plus:

  • Viteza: cred ca acesta este unul dintre cele mai mari avantaje, poti opri si porni containerele foarte rapid, doar primul build dureaza mai mult, dupa asta totul va fi foarte rapid;
  • Mai putine resurse utilizate: Comparat cu un VM, un container nu trebuie sa includa tot sistemul de operare, in consecinta nu va ocupa mult spatiu pe disc si nu va folosi foarte multa putere de procesare, iar pentru ca nu este un OS intreg nu face toate lucrurile… de OS, in general face doar actiuni legate de serverul relevant.

Dar ce nu primesti in schimb:

  • Curba de invatare: daca nu ai cunostinte de Docker si Docker Compose, o sa fie mai putin intuitiv la inceput;
  • Prima instalare: este mai greu de setat la inceput, iar daca ai folosit VM-uri mult timp o sa ai impresia ca mergi impotriva curentului, dar cu siguranta o sa devina mult mai usor pe termen lung.

Luand cele de mai sus in considerare, vreau sa mentionez ca atunci cand am facut acest setup foloseam un Linux cu 8Gb de RAM. Un coleg chiar mi-a urat succes in a instala Magento2 pe un calculator ultraportabil cu 8Gb de RAM. Nici macar nu era sarcastic, era mai degraba compasiune legata de decizia mea proasta in a-mi alege calculatorul de lucru.

O alta nevoie a fost sa am izolare si configuratii specifice intre proiecte, nu puteam sa instalez un server pe local si gata.

In trecut am folosit Vagrant si VirtualBox, o combinatie foarte buna, foarte usor de folosit (in mare parte). Dar pentru Magento2, am realizat ca avea nevoie de prea multe resurse si calculatorul meu nu facea fata.

Totodata trebuia sa fie si usor de folosit, nu-mi place sa scriu comenzi de 3 cuvinte din memorie, vreau doar sa apas tab de cateva ori si sa se rezolve totul.

Cerintele

Au fost cateva cerinte specifice:

  • nginx config – trebuia sa meraga din prima, iar fisierul de configurare pentru Magento 2 nu e tocmai mic si usor de folosit;
  • SSL – domeniul trebuia sa mearga si cu HTTPS, in mare parte din pricina API-urilor care aveau nevoie de o conexiune HTTPS, chiar daca certificatul nu este valid;
  • bash – comenzile de Magento trebuiau sa fie rulate cu utilizatorul de pe sistemul gazda, nu ca root (asa cum ruleaza in general containerele). Aveam nevoie de asta ca sa nu fie probleme de drepturi intre fisierele generate de mine si cele generate de Magento.
  • xdebug – trebuie sa ruleze out of the box si sa fie usor de integrat cu un IDE.

Implementare si intrebuintare

Magento2 oferea un container Docker pentru dezvoltare. Nu vreau sa spun nimic de el, pentru ca nu era deloc ce imi trebuia.

Sursa mea principala de inspiratie a fost: https://github.com/markoshust/docker-magento. Proiectul s-a schimbat foarte mult in ultimii 2 ani, dar merita sa-i acordati cateva minute.

Punctul de inceput este: https://github.com/claudiu-persoiu/magento2-docker-compose

Fisierele relevante sunt:

  • magento2 – ar trebui sa contina un folder html in care se afla proiectul;
  • dkc_short – poate sa stea oriunde, dar ar trebui adaugat la ~/.bash_profile or ~/.bashrc, acest fisier contine alias-uri si scurtaturi, nu este neaparat necesar dar mie imi face viata mai usoara;
  • docker-compose.yml – contine toate maparile si containerele relevante.

NOTA: Cred ca ar trebui sa mentionez ca in containerul PHP se pot rula comenzi in doua feluri, ca utilizator de sistem sau ca root. Aceasta limitare este datorata modului in care ruleaza containerele in Linux, o sa revin la acest subiect mai tarziu.

Pasul 1:

Ce trebuie facut atunci cand vrei sa rulezi un proiect Magento2 existent:

$ git clone https://github.com/claudiu-persoiu/magento2-docker-compose.git nume_proiect
$ cd nume_proiect
$ git clone calea_catre_repository magento2/html

Pasul 2 (optional):

Copierea alias-urilor in consola bash:

$ cp dkc_short ~/
$ echo ~/dkc_short >> ~/.bash_profile
$ source ~/.bash_profile

NOTE: Daca nu exista fisierul ~/.bash_profile atunci trebuie folosit ~/.bashrc

Pasul 3:

Pornirea containerelor:

$ dkc-up -d

Va dura mai mult prima data, dar de data viitoare va fi mult mai rapid.

Pasul 4:

Instalat dependinte folosind composer:

$ dkc-php-run composer install

Cam asta e tot.

Ce e chestia asta cu dkc?

Dupa cum spuneam, imi place sa folosesc tab cand scriu o comanda, asa ca mi-am adaugat cateva alias-uri care imi permit sa rulez comenzi fara sa tastez tot. De exemplu dkc[tab]p[tab]-[tab] si restul comenzii. Iubesc autocomplete-ul din bash.

Lista de comenzi este foarte simpla:

  • dkc-up -d – pornesc toate containerele in background
  • dkc-down – opresc toate containerele
  • dkc-mag [command] – ruleaza o comanda Magento2
  • dkc-clean – curata cache-ul
  • dkc-php-run – ruleaza o comanda bash in containerul de PHP, cum a fost composer in exemplul anterior. NOTA: aceasta comanda ruleaza ca utilizator de sistem, nu root
  • dkc-exec phpfpm [command] – la fel ca mai sus dar dar ruleaza ca root. In majoritatea cazurilor va fi nevoie doar de comanda de mai sus;
  • dkc-exec [container] [command] – aceasta comanda are nevoie de explicatie mai extinsa:
    • poate sa fie:
      • app – pt serverul Nginx,
      • phpfrm – pentru containerul PHP,
      • db – pentru baza de date,
      • cache sau fpc – pentru cache;
    • aceasta comanda poate sa fie orice se aplica la un container, precum “bash” sau “bash composer”, etc.

Stiu ca toate comenzile par ca mai adauga ceva de invatat, dar in mare parte din timp doar primele 4 sunt necesare.

Cum functioneaza toata magia?

Pai, comenzile de mai sus se pot vedea in fisierul “dkc_short”.

Mai sunt doua repositories de interes:

Repository-urile sunt destul de mici si relativ usor de inteles.

Daca ai nevoie sa modifici ceva, poti face un fork fara grija.

Concluzia

Cam asta e tot ce este de stiut, eu folosesc aceasta configuratie de aproape 2 ani.

Pentru mine functioneaza fara probleme si am putut sa folosesc Magento2 pe un calculator ultraportabil cu 8Gb RAM fara niciun neajuns.

Final (fericit)!

Written by Claudiu Persoiu

29 November 2018 at 3:00 PM

Despre pasiune, programare si sisteme de incalzire

without comments

Nu te lasa pacalit, aceasta postare chiar este despre programare, arhitectura sistemelor, dar si despre un sistem de incalzire.

Daca nu-ti dai seama cum poti vorbi despre programare fara sa folosesti programare, atunci ar trebui sa citesti cartea “The Passionate Programmer” de Chad Fowler, este o carte foarte buna. Povestirile legate de jazz din acea carte m-au inspirat sa scriu aceasta postare.

Povestea incepe intr-un apartament nou dintr-o cladire veche. Sau cel putin, e nou pentru mine.

Cladirea are o centrala proprie, foarte veche si extrem de ineficienta. Dupa o lunga analiza, am decis sa-mi instalez propria centrala de apartament si sa ma deconectez de la sistemul de incalzire al cladirii.

Pana aici nimic deosebit, multa lume face asta, parte pentru confort, parte pentru optimizarea cheltuielilor.

Acestea fiind spuse, aveam un proiect si aveam nevoie de un dev. Sau, cu alte cuvinte, aveam un sistem de incalzire de facut si aveam nevoie de cineva care sa-l construiasca.

Am intrebat in jur de un dev “bun”.

Ca in orice alt domeniu, sunt multi oameni care vin cu solutii proaste. Sunt unii care fac oferte foarte bune, dar nu sunt capabili sa termine lucrarea, sau scriu cod urat care nu este scalabil, sau, si mai rau, imposibil de mentinut.

Avand in vedere ca tot ce stiu despre centrale si sisteme de incalzire este cam ce stie oricine dupa ce a cautat subiectul pe google pentru aproximativ doua ore, am vrut pe cineva in care sa am incredere, asa ca am cautat dev-ul pasionat!

Am avut cateva recomandari. Primul mi-a spus ca trebuie sa-mi pun tevile aproape de travan. Dupa ce l-am convins ca nu vreau ca apartamentul meu sa arate ca o fabrica plina de tevi mi-a spus ca in mod sigur trebuie sa inlocuiasca (cel putin) un calorifer pentru ca nu poate trage o teava prin spatele lui. Aproape ca puteam sa-mi bag toata palma in spatele caloriferului asa ca am concluzionat ca cel care vine trebuie sa fie capabil sa treaca testul de a trage o teava prin spatele caloriferului.

Era evident ca nu era un dev bun. Un bun dev trebuie sa poata lucra cu cerintele, un proiect trebuie sa respecte cat mai multe din cerintele clientului, iar daca nu poate atunci sunt cateva explicatii: nu poate pentru ca nu stie cum sau nu vrea pentru ca stie ca este greu si nu vrea sa se complice. In unele cazuri asta nu este o tragedie, poate este mai ieftin si mai rapid, iar in cazul lui ar fi fost. Din pacate pentru el, eu eram interesat de calitate.

Si apoi a aparut programatorul pasionat. Nu a spus la niciun moment ca este ceva ce nu poate face, era mereu vorba doar de un cost si, poate, de o consecinta. Can lucrezi cu un dev mai, totul legat de ei e mai scump, nu doar munca lor: vor vrea servere mai bune, unelte mai bune si uneori mai mult timp pentru lucruri precum testare si mententanta. Cu alte cuvinte, uneori pretul este mai mare, nu doar pe loc, ci si pe termen lung. Un proiect de calitate necesita timp si bani.

Acesta este rezultatul proiectului meu:

In caz ca nu ai mai vazut un sistem de incalzire pentru un apartament, poate ar trebui sa stii ca, in afara de tevi, nimic altceva nu este neaparat necesar.

Este doar pasiune!

De exemplu: pompa din dreapta jos, este acolo doar ca sa forteze apa sa se miste mai repede prin instalatie. Gandeste-te la ceva de tipul Redis, care va avea un efect benefic asupra sistemului, dar majoritatea sistemelor vor lucra foarte bine fara el. Evident, la un moment dat ar putea chiar avea nevoie de mententanta sau poate creea si probleme, ca aceasta problema din Magento 2: https://github.com/magento/magento2/issues/10002. Orice sistem vine cu pretul lui.

Vasul de expansiune din stanga jos nu era necesar (in sensul in care centrala are deja unul integrat), dar nu este o idee rea sa ai unul in plus. Este ca si cum ai resurse suplimentare (spatiu de stocare suplimentar, ram sau CPU) pe care nu le folosesti, de fapt, in mod constant. Un server nu ar trebui in general sa depaseasca un anumit load, acela este vasul de expansiune al serverului pe care trebuie sa-l iei in considerare.

Filtrul de apa este ca un firewall, ai nevoie de el, este protectia ta, poate marea majoritate a timplui va fi inutil, dar atunci cand vei avea probleme pe instalatie iti va parea bine ca il ai, pentru ca el le va filtra.

Partea buna cu un dev pasionat este ca si alti devi ii inteleg si ii apreciaza munca. Asta este foarte important, indiferent de industria “dev-ului”.

Singurul care a avut ceva de comentat a fost tehnicianul care facea ISCIR-ul. Puteai sa-ti dai seama foarte usor ca nu e pasionat, a vrut sa spuna ceva de rau doar ca sa ma impresioneze pe mine cu expertiza lui.

Din pacate pentru el, a facut niste comentarii foarte ridicole dupa care mi-a facut o oferta de mentenanta. El era consultantul, nu a facut proiectul si nu a vrut sa munceasca la el, dar in mod sigur vrea sa faca un ban din el fara sa depuna niciun fel de efort.

Cred ca o concluzie este ca intre developeri, calitatea si pasiunea transcend industria.

Written by Claudiu Persoiu

8 August 2018 at 8:47 PM

Posted in Diverse,Web stuff

Tagged with

Cartile pentru Zend Certified Engineer 2017

without comments

De curand am trecut examenul pentru Zend Certified Engineer 2017, certificare oferita de Rogue Wave.

Desi experienta este cel mai important lucru pentru o certificare, cartile sunt cel mai bun mod de a-ti largi cunostintele, in opinia mea.

Pentru ca o certificare este ceva foarte specific, nu sunt foarte multe carti relevante disponibile.

Inainte de a incepe, trebuie notat ca cea mai exhaustiva resursa pentru a invata PHP este manualul, intotdeauna trebuie trecut prin toate clasele si functiile care sunt disponibile.

Zend Certified Engineer Exam Study Guide 20$

Am cumparat aceasta carte doar pentru ca am vrut sa-i fac un review si sa-mi castig dreptul de a-mi exprima parerea despre ea.

Acest ghid a fost introdus cu certificarea pentru PHP 5.3 si pe atunci era gratuit. Calitatea cartii s-a imbunatatit continuu intre timp, dar niciodata foarte mult, iar de la un moment nu a mai fost o resursa gratuita.

Am sperat ca in timp o sa devina din ce in ce mai bun, dar nu a fost asa. Este o carte scurta, cu font mare si multe, multe greseli.

Singura parte buna este ca la fiecare capitol exista intrebari. In afara de asta nu este o resursa prea buna si in mod sigur nu valoreaza 20$, probabil 5$ era mai aproape de realitate, avand in vedere ca de la o versiune la alta doar au actualizat-o doar cate putin si doar au adaugat noile schimbari si aditii din limbaj. Nici macar intrebarile nu par sa se schimbe prea mult in timp.

Asa ca daca vei cumpara o singura carte, mai bine sa o cumperi pe urmatoarea.

PHP 7 Zend Certification Study Guide – Andrew Beak – Apress 2017 – 19.99$

Cartea analizeaza in mai mult detaliu toate sectiunile din certificare, are peste 300 de pagini.

Aceasta carte arata mai mult ca o carte de programare decat un ghid. Calitatea cartii este mult mai buna decat cea a ghidului oficial, dar asta nu e dificil daca luam in considerare cat de slaba este calitatea aceluia.

Si in aceasta carte sunt intrebari dupa fiecare capitol, lucru util pentru a-ti testa cunostintele intr-un format apropiat examenului. Totusi intrebarile par un pic mai “blande” decat ghidul, examenul in sine are multe intrebari foarte “tricky”.

Evident acest ghid nu este chiar complet, nu poti avea cu adevarat un ghid care sa trateze absolut toate detaliile intr-o singura carte si, chiar daca ar exista, probabil nu ai avea timp sa o citesti.

Daca vei cumpara o singura carte, recomandarea mea este sa o iei pe aceasta, pentru ca este o carte, nu doar un ghid la nivel foarte inalt (si calitate joasa).

Zend PHP 5 Certification Study Guide, Third Edition – php[architect] – 22$

Daca ai impresia ca am gresit versiunea, ce pot spune? Ai dreptate!

Am vrut sa adaug si aceasta carte la lista pentru ca, pentru mine, a fost cel mai bun ghid de studiu. De-a lungul anilor au fost mai multe ghiduri, dar acesta mi-a placut cel mai mult.

Pentru certificarea de PHP 5 nu exista un ghid oficial de la Zend, doar prima editie din aceasta carte. A fost o carte de programare interesant de citit. Uneori cand vreau sa-mi reamintesc ceva ce nu am mai folosit de multa vreme, sau deloc, citesc capitolul din aceasta carte.

Cand am dat examenul pentru certificarea de PHP 5.5 (pentru ca a trebuit sa le am pe toate), am fost placut surprins sa aflu ca exista o noua versiune a aceastei carti.

Este in esenta aceeasi carte, dar actualizata pentru noua certificare. Poate doar imi place mine stilul de a scrie al lui Davey Shafik.

Cartea imi da senzatia ca e mai plina de informatii, mi se pare ca aduce mai mult cu un ghid de studiu decat cartea precedenta.

Totusi, aceasta carte nu are intrebari si nu mai este de actualitate.

Daca ai timp, poti sa o citesti oricum, eu o consider o carte buna de PHP.

Concluzii

Nu exista prea multe carti pentru aceasta vertificare, dar daca ar trebui sa aleg o singura recomandare, probabil ar fi: “PHP 7 Zend Certification Study Guide” de la Apress.

Din pacate nu prea exista competitie, pentru ca “Zend PHP 5 Certification Study Guide, Third Edition” de la PHP Arch nu mai este de actualitate, iar ghidul oficial pur si simplu nu valoreaza 20$.

Daca seful tau iti cumpara cartile, eu sugerez sa le iei pe toate! Pana la urma costa: 20$ + 19.99$ + 22$ = 61.99$! Nu e rau pentru trei carti de programare!

Written by Claudiu Persoiu

12 June 2018 at 8:44 PM

Posted in PHP

Tagged with , , , ,

De ce este un limbaj ca PHP asa popular?

without comments

Da, PHP este probabil cel mai popular limbaj de programare server side pentru Web in acest moment. Si probabil va ramane asa pentru o vreme indelungata.

Este probabil cel mai bun!

Nu tocmai, dar nu te opri din citit…

De ce este atat de usor de invatat?

In primul rand, datorita sintaxei. Dar motivul pentru care este asa de popular nu este pentru ca ar avea cea mai buna sintaxa! Eu am inteles aproape imediat sintaxa cand am vazut primul exemplu de “hello world”, de ce? Pentru ca am studiat C la scoala, iar persoanele care vin din lumea Java au aceeasi senzatie.

Dar sa vedem cateva limbaje de programare care folosesc aceasta sintaxa: Java, C#, JavaScript, Perl, Go, PHP si, bineinteles, C si C++, adica aproape toate platformele si cam toata piata.

Dar spre deosebire de (majoritatea) limbajelor listate mai sus, este cel mai simplu pentru incepatori! Nu trebuie sa creezi o functie “main”, o clasa sau altceva, incepi direct!

Partea buna este ca poate sa fie atat de complex pe cat vrei sau cat ai nevoie. Acum exista clase si interfete similare cu Java, mostenire orizontala cu “traits”, programare functionala cu closures si functii anonime, generatori, iar, daca esti cu adevarat hipster, pana si goto!

Dar PHP nu suna chiar asa de rau…

Dar trebuie sa amintim un detaliu foarte important: PHP nu a devenit popular datorita caracteristicilor de mai sus, in schimb caracteristicile au aparut datorita popularitatii, chiar si “goto”. Nu inteleg de ce cineva ar adauga goto intr-un limbaj dupa mai bine de 10 ani de existenta, dar asta nu este treaba mea si nici nu este relevant pentru acest subiect.

Limbajul a devenit foarte popular cu versiunile 3 si 4. Pana cand a aparut un model decent de OOP era deja foarte popular! In special acum, de cand cu versiunea PHP 7, cand arata mult mai mult ca un limbaj decent de programare, dar acum 10 ani nu era aceeasi poveste.

Dar node.js probabil il va depasi!

Sigur ca da… va amintiti de Ruby? Python? Si altele…

Daca te gandesti la PHP, are un mare avantaj si dezavantaj totodata, este cat de “stateless” se poate.

Cu PHP ai impresia ca nu stii nimic despre lume, trebuie sa faci bootstrap (initializezi) totul de fiecare data. Avantajul este ca in cazul unui memory leak, in majoritatea cazurilor, este ok. Cand requestul se termina totul se va curata/elibera si nimanui nu-i va mai pasa. Si PHP avea multe memory leak-uri la inceput, pana sa devina foarte popular si nimanui nu parea sa-i pese.

Cand au inceput sa apara cron job-urile si alte procese de lunga durata, abia atunci a devenit o mare problema si a aparut nevoia de garbage collection explicit. Acesta a fost adaugat in versiunea 5.3 care aparut abia in 2009.

In mod normal, un proces care ruleaza continuu nu ar trebui sa fie un dezavantaj, dar morala povestii este ca nu este neaparat nici avantaj.

Nimeni nu va construi urmatorul Google cu el, dar macar niste blog-uri? Sau, si mai bine, niste magazine virtuale?

Nu este capabil de ceva precum motorul de cautare Google, si e ok pentru ca nu a fost facut pentru asta.

Un alt exemplu pentru “nu neaparat cel mai bun castiga” este ca WordPress este cea mai populara platforma de blogging.

Chiar mai mult, lumea foloseste WordPress in tot felul de moduri bizare, practic poti face orice cu el! Si nu ar trebui sa reporosam asta oamenilor care il folosesc, nu e ca si cum te uiti la ce piese sunt in cuptorul cu microunde atunci cand il cumperi, nu-ti doresti decat sa incalzeasca mancarea. Oamenii care forteaza limitele platformei WordPress fac la fel, ei pot sa faca ce au nevoie si nu exista un motiv bun pentru care sa nu o faca.

Ar trebui sa-l folosesc?

Sa luam doua exemple pozitive: Yahoo! si Facebook.

Yahoo! il foloseste de foarte mult timp in unele din produsele sale si, uneori, intr-o combinatie cu alte limbaje de programare.

Facebook l-a folosit de la inceput pentru ca este usor de invatat. Ei au impins limitele limbajului in mai multe randuri prin: HipHop for PHP si, mai recent, Hack, care a reprezentat si cea mai importanta motivatie din spatele PHP 7.

De ce atata deranj pentru un limbaj de programare? Pentru ca este usor de invatat si utilizat!
De obicei, este mai important sa lansezi “acum” decat sa ai ceva “perfect” mai tarziu, mai ales in universul world wide web.

Este un motiv foarte bun pentru care un limbaj care nu este in mod sigur “cel mai bun”, dar este usor de folosit este atat de popular online, in timp ce un limbaj de programare ca C, care este mult mai dificil de invatat, este atat de popular offline.

Cu alte cuvinte, chiar daca PHP nu este cel mai bun, este in general suficient de bun.

Written by Claudiu Persoiu

19 October 2017 at 8:46 PM

Posted in PHP

Tagged with

Ghid de motivare pentru programatori sau cum sa aiba parte de un challenge adevarat

without comments

motivationIT-ul este probabil unul dintre cele mai dinamice domenii de pe piata de locuri de munca, iar oamenii reprezinta o resursa foarte importanta si totodata limitata.

Si totusi oamenii vin si pleaca destul de des, iar cei mai multi se plang de lipsa motivatiei.

Totul se va termina acum cu acest ghid simplu pentru motivarea programatorilor si nu numai!

Programatorii au nevoie de probleme “challenging”, tot timpul spun ca vor lucruri mai noi si mai challenging, nu?

Da-i un challenge adevarat! Pune-l sa obtina specificatii de la un client care nu stie ce vrea, lasa-l sa se chinuie, eventual lasa-l singur, sa simta adrenalina unei provocari adevarate!

Trebuie retinut ca un programator nu este decat un Project Manager reprimat, da-i sansa sa se exprime!

Dar nu trebuie sa te opresti aici, nu exista provocare mai mare decat sa lucrezi la mai multe lucruri in acelasi timp. O idee buna ca sa maresti complexitatea este sa-i dai ocazia sa lucreze la mai multe proiecte in paralel. Da-i ocazia sa aiba mintea ocupata cu lucruri cat mai diferite, diversitatea este mereu buna, nu?

Un secret pentru a exploata diversitatea la potential maxim este sa aiba atributii diferite pe diferite proiecte, poate un proiect care implica management sa alterneze cu unul de mentenanta. Este pacat sa nu aiba parte de suficienta diversitate!

Scrie prea mult cod? Trebuie sa faci ceva in sensul asta! Atunci cand un programator sta concentrat si lucreaza la ceva nu este nimic altceva decat un strigat disperat dupa atentie. Trebuie sa faci ceva ca sa intrerupi cercul acesta vicios, este de datoria ta ca manager sa-l salvezi!

Trebuie sa gasesti un mod sa-l intrerupi: incearca cu cateva sedinte, ajuta mereu. Daca pare dornic sa iasa din sedinta, este doar un semn ca isi doreste sa intre in urmatoarea sedinta!

In timp o sa observi ca oamenii cu cat sunt mai buni la scris cod, cu atat isi doresc mai tare sa nu mai aiba timp sa faca asta. Totusi, nu iti va spune asta, sau, chiar daca iti spune, este doar pentru ca el nu stie ce-si doreste cu adevarat.

Iar pana la urma, daca ii place atat de mult sa scrie cod, poate ar trebui sa-l duci la nivelul urmator si sa-l pui sa si-l testeze singur. Pana la urma, daca el l-a scris, cine altcineva sa stie mai bine cum sa-l testeze?

Mai este un lucru de mentionat legat de cod in contextul unui challenge. Cand vine un programator la interviu, ce spune el de fiecare data este “vreau sa invat lucruri noi”. Cum aplici aceasta dorinta? Simplu, trebuie doar sa-l pui sa faca ceva ce nu stie! Asa ii prezinti ceva ce este nou si challenging in acelasi timp. Este programator PHP? Nu-i nimic, da-i un proiect de Java! Este programator de Java? Nimic mai simplu, da-i un proiect Objective-C! Poate uneori este greu sa gasesti noi tehnologii pe care nu le cunoaste si pe care nu a incercat deja sa le invete, dar fericirea unui programator nu este un lucru usor de obtinut!

Sa nu cazi in greseala da a acorda salarii corelate cu postul, nu-ti face griji, salariul este confidential, nu vorbeste nimeni despre el. In special atunci cand recomanda un prieten, in mod sigur nu o sa se intereseze de salariul care i-a fost oferit acestuia, doar este confidential, ar fi lipsa de etica profesionala sa se intereseze, nu ar trebui sa-ti faci griji in acest sens.

Si, ca tot am mentionat interviuri, poate uneori te gandesti ca procesul de angajare trebuie sa produca rezultate coerente. Nimic mai gresit, de ce este nevoie cu adevarat? Asa cum am spus si mai devreme: Diversitate! Am citit un articol acum ceva vreme despre firme chinezesti care angajeaza femei frumoase pentru a stimula mediul. Mereu trebuie sa gasesti moduri noi de a integra ultimele tendinte, dar daca tu ai doar posturi tehnice deschise, trebuie sa te descurci cu ce ai. Poate te gandesti ca a angaja pe criterii estetice poate fi problematic uneori, mai ales cand sunt posturi tehnice. In acest caz trebuie sa-ti dai seama ca motivarea trebuie gandita si la scara larga. Da, poate unele echipe o sa se adapteze mai greu la acesti noi membri ai echipei, dar daca persoana respectiva o sa se faca remarcata in orice fel, inseamna ca ai facut o treaba buna!

Sa nu uitam de traininguri si conferinte. Cand ai vorbit ultima oara cu un programator si a zis ca nu-si doreste un training sau sa mearga la conferinte de specialitate?

Motivatia trebuie mentinuta, ca orice alta dorinta. Exista doua componente: dorinta pentru ceva si, nu in ultimul rand, lipsa acelui ceva dorit. Daca iti doresti ceva este pentru ca nu il ai inca, nu-i asa?

Daca nu ai inteles deja, solutia este simpla: nu-l lasa sa aiba acel ceva dorit. Vrea un training? Organizeza trainingul, apoi ai grija sa trimiti persoanele care sunt cel mai putin interesate la el. El o sa vada ca se poate, chiar daca nu pentru el.

Poate asta o sa fie uneori un challenge si pentru management, dar cu multa atentie este realizabil! Pastreaza dorinta vie!

Un alt sfat legat de traininguri: pentru a pastra dorinta vie este util sa-l trimiti la traininguri de care nu este interesat, dar de care este interesat altcineva. Asa o sa ai mereu angajati interesati de traininguri si care fac traininguri, dar care sunt motivati in continuare!

Atunci cand munceste nu trebuie sa vada utilitatea muncii lui, este foarte important. Daca o sa o vada, cum o sa mai fie motivat sa continue? E ca si cum urci un munte, de ce sa-l mai motiveze urcarea daca a vazut cat este de sus? Trebuie sa ai grija sa nu-si dea seama unde a ajuns: este bine sa nu aiba acces la statistici ca nu cumva sa aiba un sentiment de finalitate, de tinta atinsa, de tel realizat, cum ar mai putea fi un challenge atunci?

Si nu uita sa nu-i arati incredere, trebuie sa o construiasca singur. Trebuie sa-i dai o tinta si apoi sa o mentii doar o tinta. Intr-adevar, o tinta atinsa provoaca placere si satisfactia muncii, dar oare tu asta iti doresti sa-i oferi? Gandeste-te la asta putin, de fiecare data cand il lauzi pentru munca realizata o sa mai fie motivat? De ce sa incerci sa-l stimulezi sa se autodepasasca cand poti sa-l stimulezi sa atinga o tinta pe care nu o poate atinge. Nu-i arata ca ai incredere in el, lasa-l sa se chinuie, sa simta challenge-ul.

O vorba spune: “drumul cunoscut e cel mai scurt”. Totusi, unii incearca sa automatizeze lucrurile rudimentare. Practic incearca sa scape tocmai de drumul cunoscut. Efectiv, daca il opresti din automatizarea proceselor il ajuti sa ramana ocupat, il ajuti sa aiba o minte ocupata, iar o minte ocupata este o minte activa!

Si, in al doilea rand, cu aceasta abordare il ajuti sa-si mentina locul de munca. Poate el nu-si da seama, dar daca o sa-si piarda utilitatea cand o sa ramana tocmai fara task-urile pe care, pana la urma, le si cunostea atat de bine, pentru ca le-a facut de atatea ori… Programator sau nu, nu trebuie sa-l lasi sa fie inlocuit de un robot!

In al treilea rand este satisfactia drumului cunoscut – nu-l lasa sa deturneze de la el, oricum, la cat este de cunoscut, ar trebui sa fie destul de scurt.

Nu in ultimul rand trebuie sa-l inveti importanta managementului. Trebuie sa vada ca il poti ajuta, ca tu esti cheia catre succesul lui. Ca sa ii arati acest lucru, trebuie mai ales sa ai incredere in tine. Incearca sa organizezi o petrecere fara sa-l chemi. Nimic nu spune mai mult “puteam sa fiu si eu acolo” decat faptul ca nu ai fost acolo.

Un alt mod este sa-ti organizezi o calatorie de afaceri intr-o locatie exotica. Nu-ti face griji, nu este important sa ai efectiv ce sa faci acolo. Cat timp esti acolo, nu uita sa te distrezi, este foarte important sa stie si el asta. Cand o sa fie obositor trebuie sa-ti aduci aminte ca nu faci asta pentru tine, faci asta pentru el si imaginatia lui!

Poate unele sugestii nu functioneaza la toata lumea, dar trebuie sa incerci sa combini cat mai multe pentru a avea parte de un succes real si programatori cu adevar motivati!

Nu incerca sa identifici aceasta lume utopica, pentru ca orice asemanare cu realitatea cotidiana este pur intamplatoare.

Written by Claudiu Persoiu

4 April 2016 at 9:39 PM

Posted in Diverse

Tagged with ,

PHP6, doar o alta poveste… (PHP6 si cartile)

without comments

Gata, razboiul s-a terminat, PHP7 s-a lansat, iar PHP6 va ramane doar o legenda, o poveste a versiunii care nu a existat.

Dupa o vreme nu cred ca se mai astepta nimeni sa apara, au trecut totusi aproape 10 ani, dintr-un total de 20 de ani de viata pentru PHP.

Dar cum se poate ca o versiune atat de asteptata sa nu apara de loc?

Sa incepem cu inceputul, cand, acum aproximativ 10 ani, PHP devenea un limbaj “serios”. Dupa versiunea PHP5, model obiectual avea in sfarsit vizibilitate specifica pentru metode si proprietati, obiectele nu mai erau copiate, ci trimise prin referinta. Aceste facilitati au generat o multitudine de framework-uri obiectuale, care acum erau destinate si mediului enterprise, nu doar pentru site-uri micute.

In tot acest context exista o problema, internationalizarea.

Asa a aparut PHP6, trebuia sa fie un limbaj care sa foloseasca nativ Unicode, mai specific UTF-16. Asa totul se va procesa intr-un format unic si international.

Proiectul a fost pornit si intretinut de Andrei Zmievski. Poate astazi nu multi au auzit de Andrei, dar acum 10 ani era foarte popular pentru proiecte precum Smarty si PHP-GTK.

Dupa cativa ani proiectul a ramas intepenit, iar atunci a aparut PHP5.3. Acesta, desi aducea schimbari importante, nu era o versiune majora pentru ca inca mai era speranta ca intr-o zi va fi un PHP6.

Existau totusi niste oameni plini de speranta! Si mai ales, care au fost gata sa monetizeze speranta!

Fie ca unii au fost autori, iar altii editori, ei stiau un lucru legat de carti (in special de cele tehnice) ca au niste lucruri clare: un public tinta si o perioada in care este relevanta.

Dar sa analizam si niste rezultate.

PHP_6_and_MySQL_5_for_Dynamic_Web_Sites_Visual_QuickPro_GuidePHP 6 and MySQL 5 for Dynamic Web Sites: Visual QuickPro Guide (3rd Edition) (Peachpit Press – 2008) – Larry Ullman

Larry a scris mai multe carti, printre care: “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide (2nd Edition)” si evident “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide”.

Intamplator am avut ocazia sa rasfoiesc toate cele 3 carti, dar nu in ordinea cronologica ci pur intamplator am inceput cu “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide (2nd Edition)”. Ce e interesant este ca similitudinea este izbitoare, practic a pus un 6 in titlu si in rest aproape ca nu a schimbat cartea de loc.

In general toate cartile Visual QuickPro Guide sunt carti pentru incepatori, iar de la o editie la alta lucrurile nu se schimba prea mult, doar se adapteaza.

Professional_PHP6_Wrox_Programmer_to_ProgrammerProfessional PHP6 (Wrox 2009) – Ed Lecky-Thompson, Steven D. Nowicki (Thomas Myer)

Interesant este ca in imagine apar 3 persoane, dar pe Amazon.com si pe Wrox apar doar doua nume, de asta am tinut sa-l trec separat, este vorba de Thomas Myer.

Ma intreb oare daca Thomas Myer a cerut sa dispara, sau a fost scos? E bizar sa ai numele pe o carte dar sa nu apari in lista de autori pe site-ul editurii.

Nu intamplator exista si o “Professional PHP5” – Ed Lecky-Thompson, Heow Eide-Goodman, Steven D. Nowicki, Alec Cove.

PHP_6_MySQL_Programming_for_the_Absolute_BeginnerPHP 6/MySQL Programming for the Absolute Beginner (Cengage Learning PTR – 2008) – Andrew B. Harris

Este intradevar o carte bizara, nu exista un echivalent de PHP5, ba chiar pe site-ul scriitorului nu mai exista alta carte de PHP: .

Exista oare un motiv? In cazul lui Larry Ullman era un alt subiect atins, un alt public tinta, dar in acest caz e doar ciudat, un singur autor, o singura carte de PHP si intr-o versiune fantoma, publicata in 2008.

PHP_6_Fast_and_Easy_Web_DevelopmentPHP 6 Fast and Easy Web Development (Cengage Learning PTR – 2008) – Matt Telles, Julie C. Meloni

Fara prea multa dificultate am gasit si: “PHP Fast & Easy Web Development” – Julie C. Meloni

Ciudatenia acestei carti este ca Matt Telles nu mai are alta carte de PHP, desi are de Python, C# si C++.

Ceva imi spune ca poate el a fost adus doar ca sa actualizeze cartea originala la noul context. Am crezut ca este doar o parere presonala, doar ca la o cautare pe Google am gasit ca este si Technical Reviewer pentru “PHP 6/MySQL Programming for the Absolute Beginner (Cengage Learning PTR)”, carte care a fost prezentata anterior.

Beginning_PHP_6_Apache_MySQL_6_Web_DevelopmentBeginning PHP 6, Apache, MySQL 6 Web Development (Wrox – 2009) – Timothy Boronczyk, Elizabeth Naramore, Jason Gerner, Yann Le Scouarnec, Jeremy Stolz

Cartea originala a fost evident: “Beginning PHP, Apache, MySQL Web Development” – Michael K. Glass, Yann Le Scouarnec, Elizabeth Naramore, Gary Mailer, Jeremy Stolz, Jason Gerner

Au iesit Michael K. Glass si Gary Mailer, iar in locul lor a intrat Timothy Boronczyk.

PHP a fost un limbaj foarte la moda in perioada respectiva, iar PHP6 a fost foarte asteptat.

Cum se poate totusi asta? Cum se poate sa existe atatea carti de la edituri importante pentru un limbaj de programare care nu a existat? Raspunsul este simplu: lacomie.

Exista doua explicatii posibile: ori autorul a incercat sa acapareze piata cu o noua versiune, ori editura a vrut sa forteze nota, in speranta de a capta piata. Probabil speranta era ca in momentul cand ar fi aparut, ar fi avut cartile deja disponibile pentru livrare.

Acesta este un alt motiv pentru care nu era un plan bun ca versiunea PHP NG sa devina PHP6, ar fi insemnat sa apara o versiune de PHP si sa aiba deja o serie de carti scrise, ba chiar scrise de cativa ani.

Pun pariu ca atunci cand s-a votat intre PHP6 si PHP7 erau niste editori plini de speranta.

In continuare, va urez lectura placuta!

Written by Claudiu Persoiu

22 February 2016 at 9:11 PM

Posted in PHP

Tagged with ,