-
Am acest blog de 12 ani.
În 2008, când am început blog-ul, Wordpress era cea mai populară platformă open source pentru blogging.
O dată cu trecerea timpului, au fost descoperite multe probleme de securitate.
Plugin-urile, motorul principal pentru extinderea platformei și motivul principal pentru care era atât de populară, creau îngrijorare din punct de vedere arhitectural.
Astăzi, după toți acești ani și cu toate aceste probleme de arhitectură și de securitate, Wordpress a ajuns sa fie… cea mai populară platformă PHP de pe Internet! Codul vechi este în continuare folosit de ultimele versiuni, iar majoritatea pluginurilor din 2008 sunt încă functionale!
Pe măsură ce a trecut timpul (iar eu am scris din ce în ce mai puțin), a devenit evident că petreceam mai mult timp menținând platforma Wordpress actualizată decât scriind.
Așa că am decis într-un final să migrez la Hugo!
Hugo este un generator de site-uri statice, realizat in Golang. Site-ul construit cu Hugo este static, și (în mod și mai bizar) nu are baze de date, sunt doar fișiere de configurare și de tip Markdown. Așa că rezultă o platformă care aproape că nu mai are nevoie de mentenanță.
Împreună cu noua platformă a venit și o nouă temă, care are un design mai modern și o funcționalitate deosebit de căutată în vremurile noastre: modul de noapte!
Jekyll este probabil cea mai populară platformă pentru generat site-uri statice, dar este făcută cu Ruby așa că am preferat Hugo pentru că template-urile folosesc sintaxa de Go Templates. Este vorba mai mult de gusturi decât de altceva.
Iar cu acest update, vă invit să vă bucurați de acest blog, acum chiar și mai static!
-
Am avut recent o problemă interesantă: accesul meu la un depozit care necesită autentificare a fost invalidat în mod abrupt. Problema în cazul meu a originat de la depozit, dar ar fi putut fi la fel de ușor din cauză că mi-am pierdut credențialele sau altceva similar. Accesul meu urma să fie restabilit în curând. Cum știm cu toții, “în curând” în IT poate dura între cateva minute și dispariția tuturor formelor de viață cunoscute, iar eu trebuia să fac un build până atunci.
Și încă un detaliu, localul meu funcționa în continuare.
Pentru o vreme m-am întrebat de ce funcționează localul meu, dar tu ai citit titlul, deci ai văzut deja motivul, cache-ul meu local era încă valabil.
Am căutat o vreme o metoda usoara de a pune pachetele de pe local la eliminarea care făcea construirea, și există modalități, dar nu intenționam să pierd zile lucrand la o problemă care s-ar putea rezolva oricum înainte sa-mi finalizez eu abordarea.
Soluția a fost foarte simpla:
- trebuie doar făcută o copie a cache-ului local, pentru linux este în mod normal în “~/.composer”;
- trebuie copiata pe serverul de interes intr-o locație preferată (sa zicem /tmp/composer_cache);
- exportam variabila COMPOSER_CACHE_DIR (“export COMPOSER_CACHE_DIR=/tmp/composer_cache”);
- se ruleaza composer in mod normal.
Asta e tot, acum poți folosi cache-ul local pe un server la distanță. Nu este cel mai elegant lucru, dar este un hack rapid foarte util.
-
Cum sa folosesti Xiaomi Air Conditioning Companion in Home Assistant in doar de 20 pasi usor de urmat!
Oct 13, 2019 homeassistantPasul 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!
-
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:
1$ git clone https://github.com/claudiu-persoiu/magento2-docker-compose.git nume_proiect 2$ cd nume_proiect 3$ git clone calea_catre_repository magento2/html
Pasul 2 (optional):
Copierea alias-urilor in consola bash:
1$ cp dkc_short ~/ 2$ echo ~/dkc_short >> ~/.bash_profile 3$ source ~/.bash_profile
NOTE: Daca nu exista fisierul ~/.bash_profile atunci trebuie folosit ~/.bashrc
Pasul 3:
Pornirea containerelor:
1$ dkc-up -d
Va dura mai mult prima data, dar de data viitoare va fi mult mai rapid.
Pasul 4:
Instalat dependinte folosind composer:
1$ 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.
- poate sa fie:
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:
- https://github.com/claudiu-persoiu/magento2-docker-php – containerul phpfpm,
- https://github.com/claudiu-persoiu/magento2-docker-nginx – containerul cu serverul nginx.
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)!
-
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.